Re: chromium browser wywraca się

[Łukasz Krotowski]

2016-01-05 14:15 GMT+01:00 Paweł Gołaszewski :
> Zrobiłem upgrade z ready, jest jeszcze gorzej:
> $ chromium-browser
> [1:1:0105/141318:FATAL:credentials.cc(316)] Check failed:
> !ProcUtil::HasOpenDirectory(proc_fd).

Wygląda na to, że z jakiegoś powodu w tym miejscu zostaje otwarty (w
sensie open fd) katalog /etc/OpenCL/vendors (u mnie pusty). Dlaczego?
Nie mam pojęcia. Szybki grep po źródłach wskazywałby na to, że ffmpeg
coś psuje ale jest za późno i chromium to tak wielki program, że to
tylko zgadywanie.

W każdym razie usunięcie/zmiana nazwy vendors powoduje, że chromium
uruchamia się poprawnie.
Pozdr.,
Ł.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: chromium browser wywraca się

[Łukasz Krotowski]

W dniu 13 stycznia 2016 03:20 użytkownik Łukasz Krotowski
<lukasz.krotow...@gmail.com> napisał:
> 2016-01-05 14:15 GMT+01:00 Paweł Gołaszewski <bl...@pld-linux.org>:
>> Zrobiłem upgrade z ready, jest jeszcze gorzej:
>> $ chromium-browser
>> [1:1:0105/141318:FATAL:credentials.cc(316)] Check failed:
>> !ProcUtil::HasOpenDirectory(proc_fd).

Jeszcze wyjaśnienie, ten kod powyżej przegląda /proc/self/fd pod kątem
otwartych katalogów. Jeśli są wywraca program ze zrzutem stosu. Można
sprawdzić w takim przypadku (bo proces działa do czasu Ctrl-C) że
jedyny katalog widoczny w /proc//fd to właśnie
/etc/OpenCL/vendors.

> Wygląda na to, że z jakiegoś powodu w tym miejscu zostaje otwarty (w
> sensie open fd) katalog /etc/OpenCL/vendors (u mnie pusty). Dlaczego?
> Nie mam pojęcia. Szybki grep po źródłach wskazywałby na to, że ffmpeg
> coś psuje ale jest za późno i chromium to tak wielki program, że to
> tylko zgadywanie.
>
> W każdym razie usunięcie/zmiana nazwy vendors powoduje, że chromium
> uruchamia się poprawnie.
> Pozdr.,
> Ł.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Błędy w crossmingw32-runtime na ftp.

[Łukasz Krotowski]

Cześć,
w th leży sobie obecnie crossmingw32-runtime wersja 3.20. Niestety
ta wersja powoduję, że najprostsze nawet programy:

#include stdio.h
int main() {printf(Hello world!\n);}

zbudowane z tą wersją pakietu kończą uruchomienie na (wpis
z Event logu):

Faulting application test.exe, version 0.0.0.0, faulting module test.exe,
version 0.0.0.0, fault address 0x8fff.

Podobnie z resztą pod Wine.

Podbiłem wersję w git do 3.20.2 w której to już nie występuje. Czy mogę
prosić o przemielenie i wrzucenie na ftp?
Pozdrawiam.,
Łukasz
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: Łatki do równoległego dm-crypt.

[Łukasz Krotowski]

Hej,

W dniu 27 lipca 2013 17:11 użytkownik Jan Rękorajski napisał:
 Na LINUX_3_9 nie ma sensu. Daj od razu na master.

OK, wrzuciłem. Przetestowałem na naszym 3.10 lokalnie
zaktualizowanym do 3.10.4 (oczywiście --without vserver). Wydaję
się być wszystko w porządku.
Pozdr.,
Łukasz
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: Brak oczekiwania na dyski w initrd.

[Łukasz Krotowski]

Cześć,
być może czegoś nie rozumiem w geninitrd ale nie wiem jak to miałoby
pomóc, ale po kolei:

W dniu 19 lipca 2013 12:23 użytkownik Arkadiusz Miśkiewicz
ar...@maven.pl napisał:
 Może coś w stylu (nietestowane, u mnie problem nie występuje niestety):

 Index: functions
 ===
 --- functions   (wersja 12710)
 +++ functions   (kopia robocza)
 @@ -104,6 +104,25 @@
 return 0
  }

 +# waits for specified device until device is found or timeout happens
 +wait_for_device() {
 +   local dev=$1
 +   local timeout=$2
 +   local i
 +
 +   # default = 10s
 +   [ -z $timeout ]  timeout=5
   ^^^ miało być 10s nie 5s
 +   i=0
 +   while [ $i -lt $(( timeout * 10 )) ]; then
  ^^
do zamiast then
 +
 +   [ -e $dev ]  return 0
 +
 +   i=$(( i + 1 ))
 +   usleep 0.1
 ^^^ usleep ma parametr w usek więc 1/10 sek to 10
 +   done
 +   return 1
 +}
 +
  # resolve /dev/dm-0 to lvm2 node
  # which they got from blkid program fs was specifed as UUID= in fstab
  dm_lvm2_name() {
 Index: geninitrd
 ===
 --- geninitrd   (wersja 12710)
 +++ geninitrd   (kopia robocza)
 @@ -1515,6 +1515,8 @@
  initrd_gen_tuxonice
  initrd_gen_suspend

 +wait_for_device $rootdev
 +

I tego nie rozumiem. Jeśli dobrze odczytuje pacha to (po poprawkach
jak wyżej) spowoduje oczekiwanie na dyski przy generowaniu
initrd. Jeśli dobrze rozumiem zamysł to wait_for_device powinna
zostać dodana do linuxrc i wywołana gdzieś na początku (przed
skanem /proc/partitions), prawda?

  # clean up env
  add_linuxrc -'EOF'
  if [ ! $DEBUGINITRD ]; then

Pozdr.,
Łukasz
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Łatki do równoległego dm-crypt.

[Łukasz Krotowski]

Cześć,
od jakiegoś czasu używam łatek z równoległym dm-crypt [1]
z powodów opisanych min. tu [2] (w skrócie, nie mam AES-NI,
mam za to cztery stosunkowo wolne rdzenie i szybkie dyski
w macierzy). W przypadku gdzie ma to znaczenie liniowy
odczyt z urządzenia dm-crypt po zastosowaniu łatek na naszym
3.9 skoczył do granicy sprzętu. Tam gdzie nie ma to znaczenia
(laptop, dość szybki Core 2 duo + dysk nie SSD) nie widzę
żadnego spowolnienie / innych kłopotów.

Zatem pytanie, czy są jakieś przeciwwskazania, żebym wrzucił
te łatki do naszego jajka (na razie na LINUX_3_9) w postaci
domyślnie _wyłączonego_ bconda?

Pozdrawiam,
Łukasz

[1] 
http://people.redhat.com/mpatocka/patches/kernel/dm-crypt-paralelizace/current/
[2] http://www.saout.de/pipermail/dm-crypt/2012-July/002582.html
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Brak oczekiwania na dyski w initrd.

[Łukasz Krotowski]

Cześć,
po zmianie jądra na 3.9 z 3.7 restart z wygenerowanym initrd kończył się
paniką z powodu braku root device. Wynika to z tego że z jakiegoś powodu
(zakładam, że ważnego) 3.9 chce koniecznie resetować SATA na starcie:

$ dmesg
...
[1.137889] ata4: SATA link down (SStatus 0 SControl 300)
[1.137974] ata3: SATA link down (SStatus 0 SControl 300)
[1.304443] ata2: softreset failed (device not ready)
[1.304491] ata2: applying PMP SRST workaround and retrying
[1.304550] ata1: softreset failed (device not ready)
[1.304599] ata1: applying PMP SRST workaround and retrying
[1.471041] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[1.471114] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[1.481719] ata1.00: ATA-8: WDC WD10EFRX-68JCSN0, 01.01A01, max UDMA/133
[1.481763] ata1.00: 1953525168 sectors, multi 16: LBA48 NCQ (depth
31/32), AA
[1.481809] ata1.00: SB600 AHCI: limiting to 255 sectors per cmd
[1.482434] ata2.00: ATA-8: WDC WD10EFRX-68JCSN0, 01.01A01, max UDMA/133
[1.482477] ata2.00: 1953525168 sectors, multi 16: LBA48 NCQ (depth
31/32), AA
[1.482522] ata2.00: SB600 AHCI: limiting to 255 sectors per cmd
[1.482842] ata1.00: SB600 AHCI: limiting to 255 sectors per cmd
[1.482884] ata1.00: configured for UDMA/133

Wygląda to na jakąś poprawkę dla southbridge AMD SB600. Sam reset
trochę trwa (trochę to pewnie  1,5 sek).

Niestety nasz linuxrc (nie ma znaczenia czy z udev czy nie) próbuje od
razu złożyć macierz (md raid1) a na niej lvm na którym jest root device.
Co kończy się oczywiście brakiem urządzeń fizycznych i paniką.

Moja lokalna poprawka to dorzucenie do linuxrc usleep 2 sek:
$ cat linuxrc
...
mkdir /dev/pts
mkdir /dev/shm
usleep 200
mount -t sysfs none /sys
mount -t tmpfs run /run

Co powoduje, że jądro ma wystarczająco dużo czasu na reset SATA
i odpowiednie dyski dla macierzy są znajdowane.

Pominąłem jakiś parametr / obejście w geninitrd czy po prostu jest to
błąd geninitrd?

Pozdrawiam,
Łukasz

PS Podobne zachowanie opisane jest np. tu:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707286
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: packages: crossmingw32-zlib/crossmingw32-zlib-shared.patch, crossmingw32-zl...

[Łukasz Krotowski]

W dniu 15 marca 2010 20:26 użytkownik Artur Frysiak
wi...@pld-linux.org napisał:
 Standardowa nazwa dll dla zlib to zlib1.dll

Mingw nazywa ją zlib-1.dll, w dokumentacji jest zlib1.dll. Obie nazwy
są IMO lepsze
niż z.dll. Zatem ode mnie +1.

 Mam odpowiednią łatę, która buduje dll tak jak jest to zrobione w
 win32/Makefile.gcc.
 Można się właściwie zastanowić nad użyciem tego właśnie makefile do
 budowania całego pakietu.

Jak autotools działają to dałbym sobie spokój. ;)
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: Optymalizacja w jack-audio-connection-kit.

[Łukasz Krotowski]

W dniu 19 grudnia 2009 22:03 Fryderyk Dziarmagowski napisał:
 On Sat, 19 Dec 2009 15:06:52 +0100
 Łukasz Krotowski lukasz.krotow...@gmail.com wrote:

 Witam,
 mam zamiar podbić wersję JACK-a. Jednak jest tam wątpliwa łatka
 ustawiająca CFLAGS (z resztą wątpliwe, np. -fprefetch-loop-arrays
 lub -funroll-all-loops) wewnątrz configure. Podobnie samo configure
 z JACK-a próbuje zgadywać odpowiednie CFLAGS (znowu wątpliwe,
 np. -march=k8 zamiast -march=x86-64).

 W obecnej wersji łatka nakłada się ale flagi z configure nie są używane
 do kompilacji. Nie używane też są żadne wstawki assemblerowe
 zależne od SIMD (przynajmniej na pierwszy rzut oka).

 USE_DYNSIMD luke

Przetestowałem, wydaje się działać i na x86_64 jak i na i686. Włączone.

 Najchętniej wyrzuciłbym łatkę i wyłączył (czyt. nie włączał) mechanizm
 zgadywania w configure odpowiednich flag -- po to jest makro optflags
 aby go używać.

 Jakieś przeciwwskazania? Coś mi umknęło?

 optymizacje mocniejsze od domyślnych używanych w dystrybucji nie
 prowadzą w przypadku jacka do poprawy (przyśpieszenia??) jego działania.

Tak podejrzewałem, wyciąłem wszystko co jest w specu i zignorowałem
zgadywanki z configure. Commitnąłem -- dzięki za uwagi.
Pozdr.,
Ł. Krotowski
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Optymalizacja w jack-audio-connection-kit.

[Łukasz Krotowski]

Witam,
mam zamiar podbić wersję JACK-a. Jednak jest tam wątpliwa łatka
ustawiająca CFLAGS (z resztą wątpliwe, np. -fprefetch-loop-arrays
lub -funroll-all-loops) wewnątrz configure. Podobnie samo configure
z JACK-a próbuje zgadywać odpowiednie CFLAGS (znowu wątpliwe,
np. -march=k8 zamiast -march=x86-64).

W obecnej wersji łatka nakłada się ale flagi z configure nie są używane
do kompilacji. Nie używane też są żadne wstawki assemblerowe
zależne od SIMD (przynajmniej na pierwszy rzut oka).

Najchętniej wyrzuciłbym łatkę i wyłączył (czyt. nie włączał) mechanizm
zgadywania w configure odpowiednich flag -- po to jest makro optflags
aby go używać.

Jakieś przeciwwskazania? Coś mi umknęło?
Pozdr.,
Ł. Krotowski
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: packages: Mesa/Mesa.spec - missing BR

[Łukasz Krotowski]

Witam,

 +BuildRequires: OpenGL-glut-devel

zbyt pospiesznie commitnąłem. Ale zanim cofnę spytam.
Budowanie dem z Mesy wymaga nagłówków Gluta. U nas
to są osobne pakiety które wymagają nagłówków OpenGL
do zbudowania. Czyli jest pętla w zależnościach.

Jakieś pomysły jak to rozwiązać? Mogę oczywiście cofnąć
ostatniego commita ale może warto coś z tym zrobić?

Pozdrawiam,
Ł. Krotowski
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: Duże obciążenie CPU przez najnowszy xserver

[Łukasz Krotowski]

W dniu 20 listopada 2008 19:51 użytkownik Michał Łukaszek napisał:
 2008/11/19 Łukasz Krotowski [EMAIL PROTECTED]:

 Co zeznaje:
 $ glxinfo | grep direct

 Nie rozumiem jaki miałby wpływ brak direct renderingu.

Brak DRI wpływa również mocno na sterownik 2D. Bez DRI nie jest
używany CP (command processor) tylko MMIO. Co może
powodować dziwne zachowanie (ścieżki MMIO są zazwyczaj
gorzej przetestowane). Na mojej starej karcie użycie MMIO
powodowało np. hardlock.

Ale skoro to inny problem... ;)
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: Duże obciążenie CPU przez najnowszy xserver

[Łukasz Krotowski]

W dniu 19 listopada 2008 20:10 użytkownik Michał Łukaszek napisał:
 8
  8045 root  20   0  327M 32420  6236 R 96.0  1.7  3:51.50
 /usr/bin/X -br -nolisten tcp :0 vt5 -auth /var/run/xauth/A:0-UE7Aol
 8

 96 procent obciążenia CPU przez X powoduje, że wiatrak w moim laptopie
 wyje niemiłosiernie.
 Myślałem, że to być może przez compiza, więc dla testów wróciłem do
 kwin, ale jest bez zmian.

 Czy ktoś to może potwierdzić? Jak temu zaradzić?

Co zeznaje:
$ glxinfo | grep direct

Sprawdź też czy nie masz jakiegoś oczywistego błędu w /var/log/Xorg.0.log
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: SPECS: boost.spec - use user-defined CXXFLAGS

[Łukasz Krotowski]

W dniu 16 listopada 2008 11:06 użytkownik Tomasz Pala
[EMAIL PROTECTED] napisał:
 On Sat, Nov 15, 2008 at 19:16:18 +0100, Łukasz Krotowski wrote:

 I to jest do poprawki przez unset CC/CXX/CFLAGS/CXXFLAGS/... na początku
 %build.

 To jest spora rewolucja, naprawdę masz ochotę podjąć taką decyzję? IMO -1.

 Rewolucja? Poprawienie niedopatrzenia.

Rewolucja. Zmienia sposób budowania tak na oko 3/4 paczek.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: SPECS: boost.spec - use user-defined CXXFLAGS

[Łukasz Krotowski]

W dniu 16 listopada 2008 15:05 użytkownik Pawel Golaszewski
[EMAIL PROTECTED] napisał:
 On Sun, 16 Nov 2008, Łukasz Krotowski wrote:
  I to jest do poprawki przez unset CC/CXX/CFLAGS/CXXFLAGS/... na
  początku %build.
  To jest spora rewolucja, naprawdę masz ochotę podjąć taką decyzję?
  IMO -1.
  Rewolucja? Poprawienie niedopatrzenia.
 Rewolucja. Zmienia sposób budowania tak na oko 3/4 paczek.

 Udowodnij :P

# grep '^%configure' *.spec | wc -l
5328
# ls -1 *.spec | wc -l
13336

Przesadziłem, 2/5.

 Na moje krzywe oko to jakoś nie dotknie specjalnie niczego. A buildy będą
 bardziej deterministyczne.

Albo czegoś dotknie i buildy będą bardziej deterministyczne albo nie
dotknie niczego i nic się nie zmieni. ;)

Z resztą nieważne. Jak dla mnie nie warto tego dotykać. Albo komuś
zależy i wie co robi ustawiając takie flagi. Albo nie zauważa się nawet
takiej możliwości. Wyłączenie jakieś funkcjonalności tylko po to aby
zaraz robić obejścia (np. na DISTCC) IMO nie ma większego sensu. Ale
jak tam sobie chcecie.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: SPECS: boost.spec - use user-defined CXXFLAGS

[Łukasz Krotowski]

W dniu 16 listopada 2008 22:42 użytkownik Tomasz Pala
[EMAIL PROTECTED] napisał:
 On Sun, Nov 16, 2008 at 19:51:26 +0100, Łukasz Krotowski wrote:
 Udowodnij :P

 # grep '^%configure' *.spec | wc -l
 5328
 # ls -1 *.spec | wc -l
 13336

 Przesadziłem, 2/5.

 Udowodnij przynajmniej 1% z nich, że bierze coś ze środowiska builderów.

Nie. Bo niby jak mam coś udowodnić skoro nigdy nie miałem styczności
z builderami PLD. Co więcej, nigdy specjalnie mnie one nie obchodziły.

Dla mnie EOD, nie mam czasu na role Advocatus Diaboli w dyskusji.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: SPECS: boost.spec - use user-defined CXXFLAGS

[Łukasz Krotowski]

W dniu 15 listopada 2008 02:51 użytkownik Przemyslaw Iskra
[EMAIL PROTECTED] napisał:
 On Fri, Nov 14, 2008 at 11:32:53AM +0100, lkrotowski wrote:

 - use user-defined CXXFLAGS

 -%{__sed} -i 's/optimizationspeed : -O3/optimizationspeed : 
 %{rpmcxxflags} -fPIC/' tools/build/v2/tools/gcc.jam
 +%{__sed} -i s/optimizationspeed : -O3/optimizationspeed : 
 ${CXXFLAGS:-%rpmcxxflags} -fPIC/ tools/build/v2/tools/gcc.jam

 user może sobie zdefiniować CXXFLAGS poprzez
 --define rpmcxxflags -moje -flagi -są -lepsze,

 w PLD buildy mają być niezależne od środowiska

Nie są, zobacz sobie w co rozwija się makro %configure w naszym RPM-ie.
Z resztą tutaj jest spora niespójność ale większość softu (używającego
autotools) buduje się z uwględnieniem flag użytkownika.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: SPECS: boost.spec - use user-defined CXXFLAGS

[Łukasz Krotowski]

W dniu 15 listopada 2008 14:18 użytkownik Jakub Bogusz
[EMAIL PROTECTED] napisał:
 On Sat, Nov 15, 2008 at 11:39:06AM +0100, Łukasz Krotowski wrote:
 Nie są, zobacz sobie w co rozwija się makro %configure w naszym RPM-ie.

 Po to, żeby można było przekazać ze speca.

Faktycznie oznacza to coś więcej.

 Z resztą tutaj jest spora niespójność ale większość softu (używającego
 autotools) buduje się z uwględnieniem flag użytkownika.

 I to jest do poprawki przez unset CC/CXX/CFLAGS/CXXFLAGS/... na początku
 %build.

To jest spora rewolucja, naprawdę masz ochotę podjąć taką decyzję? IMO -1.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: makro dla rpmbuild

[Łukasz Krotowski]

W dniu 13 października 2008 11:06 użytkownik Bart. [EMAIL PROTECTED] napisał:
 Wiec ja patrze na to od tej strony osoby nie programujacej biegle.
 Łatka jest dostepna na forum ale np. program jest udostepniany wersjami.
 Czyli na faktyczna naprawe bedzie trzeba poczekac ... .

 Prosciej i wygodniej dla mnie wrzucic teraz taki warunek do speca ze gdy boost
 jest w wersji 1.36 to ma ja zaaplikowac.

 Bcond w tym momencie dziala nieprzyjaznie bo blokuje budowanie sie pakietu w 
 wersji starszej/nowszej.

 To w zasadzie taka propozycja byla i w zasadzie wiem jak ten patch poprawic
 tylko myslalem ze taki feature przyspieszylby poprawianie.

Eeetam, tylko skomplikujesz speca. Wrzuć po prostu łatkę dla 1.36 a przy
podbiciu wersji podbijający ma obowiązek sprawdzić czy łatka dalej jest
zasadna.

Btw: co poprawiasz w Boost?
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: KiCAD : kicad.spec

[Łukasz Krotowski]

W dniu 27 września 2008 14:29 użytkownik Daniel Dawid Majewski napisał:
 Bardzo proszę o ewentualne podbicie wersji :
 http://sourceforge.net/projects/kicad
 Wersja w cvs jest z 4.10.2007, tymczasem najnowsza wersja jest z
 25.08.2008 r.

Zrobione, wydaje się 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: KiCAD : kicad.spec

[Łukasz Krotowski]

W dniu 27 września 2008 17:58 użytkownik Łukasz Krotowski napisał:
 W dniu 27 września 2008 14:29 użytkownik Daniel Dawid Majewski napisał:
 Bardzo proszę o ewentualne podbicie wersji :
 http://sourceforge.net/projects/kicad
 Wersja w cvs jest z 4.10.2007, tymczasem najnowsza wersja jest z
 25.08.2008 r.

 Zrobione, wydaje się działać.

Dodałem bibliotekę elementów i pliki dokumentacji. Znowu: wydaję się
działać. Ale prawdę powiedziawszy, nie używałem nigdy kicad więc
nie wiem na pewno czy działa.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Wersje libdvdread/libdvdnav

[Łukasz Krotowski]

Witam,
czy jest jakiś powód dla którego używamy w PLD tak starych
wersji ww. bibliotek zamiast cały czas rozwijanych z
mplayerhq.hu?
Pozdr.,
Ł. Krotowski
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: fluxbox

[Łukasz Krotowski]

W dniu 4 września 2008 12:31 użytkownik Pawel Dlugosz
[EMAIL PROTECTED] napisał:
 Dzięki, jak ktoś używa fluxboksa
 to niech da znać jak to działa.

Działa dobrze. Gdzieś po drodze fbsetbg przestał używać feh
i musiałem doinstalować WindowMakera (wmsetbg) ale poza tym
działa ok.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: fluxbox

[Łukasz Krotowski]

W dniu 5 września 2008 21:56 Łukasz Krotowski napisał:
 W dniu 4 września 2008 12:31 użytkownik Pawel Dlugosz
 [EMAIL PROTECTED] napisał:
 Dzięki, jak ktoś używa fluxboksa
 to niech da znać jak to działa.

 Działa dobrze. Gdzieś po drodze fbsetbg przestał używać feh
 i musiałem doinstalować WindowMakera (wmsetbg) ale poza tym
 działa ok.

Wystarczyło zmusić fbsetbg aby użył feh (czasami warto czytać
dokumentację ;) ):
$ wpsetters=feh fbsetbg ...
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: xorg xserver do testowania

[Łukasz Krotowski]

14-12-07, Łukasz Maśko [EMAIL PROTECTED] napisał:
 Dnia czwartek, 13 grudnia 2007, Łukasz Krotowski napisał:
 [...]
  Spróbuj Option AccelMethod EXA, do XAA już chyba nikt się nie dotyka.
  Ponadto sprawdź opcje Option MigrationHeuristic greedy i
  Option EXAOptimizeMigration true. Wszystko w sekcji Device. Dwie
  ostatnie mogą znacznie poprawić wydajność EXA ale mogą też coś popsuć.

 Niestety, nie działa: w logach dostaję następującą informacje:

 (WW) NVIDIA(0): Option AccelMethod is not used
 (WW) NVIDIA(0): Option MigrationHeuristic is not used
 (WW) NVIDIA(0): Option EXAOptimizeMigration is not used

 Grafika to NVidia GeForce4 Go M64 (laptop), sterowniki nvidia-legacy2.

Eee, binarna nVidia. No to musisz pomęczyć nVidię.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: xorg xserver do testowania

[Łukasz Krotowski]

13-12-07, Łukasz Maśko [EMAIL PROTECTED] napisał:
 Z przykrością muszę stwierdzić, że nowa wersja nadal jest niestabilna po
 włączeniu w KDE wykorzystania cieni i przezroczystości. Objawia się to
 losowymi wywrotkami, a w logach ląduje komunikat typu:

 Backtrace:
 0: /usr/bin/Xwrapper(xf86SigHandler+0x7e) [0x80c514a]
 1: /lib/libc.so.6 [0xb7d6f1c8]
 2: /usr/lib/xorg/modules//libxaa.so [0xb7168926]
 3: /usr/bin/Xwrapper [0x8160048]
 4: /usr/bin/Xwrapper(CompositeGlyphs+0x94) [0x8148679]
 5: /usr/bin/Xwrapper [0x814fa18]
 6: /usr/bin/Xwrapper [0x814b1af]
 7: /usr/bin/Xwrapper [0x813f248]
 8: /usr/bin/Xwrapper(Dispatch+0x2bc) [0x808688b]
 9: /usr/bin/Xwrapper(main+0x495) [0x806f015]
 10: /lib/libc.so.6(__libc_start_main+0xe3) [0xb7d5a3d3]

Spróbuj Option AccelMethod EXA, do XAA już chyba nikt się nie dotyka.
Ponadto sprawdź opcje Option MigrationHeuristic greedy i
Option EXAOptimizeMigration true. Wszystko w sekcji Device. Dwie
ostatnie mogą znacznie poprawić wydajność EXA ale mogą też coś popsuć.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: Co z tym PLD? (fwd z discuss)

[Łukasz Krotowski]

01-10-07, Bartosz Świątek [EMAIL PROTECTED] napisał:
 01-10-07, Cezary Krzyzanowski [EMAIL PROTECTED] napisał(a):
 
  Dnia 01-10-2007, Pn o godzinie 17:10 +0200, Kamil Dziedzic pisze:
   Dnia poniedziałek 01 październik 2007, Cezary Krzyzanowski napisał:
Dnia 01-10-2007, Pn o godzinie 16:42 +0200, Kamil Dziedzic pisze:
 A jaka grafika? ATI?
   
Nvidia.
   
   Model? Bo ja jakoś nigdy nie miałem problemów.
 
  00:0d.0 VGA compatible controller: nVidia Corporation GeForce 6100
  nForce 430 (rev a2) (prog-if 00 [VGA])
 
  Zaznaczam, że karta działała sprawnie przez ostatni rok bodajże.

 I teraz masz do niej oczywiście xorg-driver-video-nvidia-legacy2?

A dlaczego legacy? Ten model wspierają nowe sterowniki.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: Co z tym PLD? (fwd z discuss)

[Łukasz Krotowski]

01-10-07, Cezary Krzyzanowski [EMAIL PROTECTED] napisał:
 AAAa..na łeb można dostać. Wszystko super że dobrze mam, ale mi X-y się
 wieszają non-stop :)

Cofnij profilaktycznie xserver do 1.3. Wersja 1.4 jest jakaś niedorobiona.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: Co z tym PLD? (fwd z discuss)

[Łukasz Krotowski]

01-10-07, Remigiusz Enleth Marcinkiewicz [EMAIL PROTECTED] napisał:
 Dnia poniedziałek 01 października 2007, Łukasz Krotowski napisał:
  01-10-07, Cezary Krzyzanowski [EMAIL PROTECTED] napisał:
   AAAa..na łeb można dostać. Wszystko super że dobrze mam, ale mi X-y się
   wieszają non-stop :)
 
  Cofnij profilaktycznie xserver do 1.3. Wersja 1.4 jest jakaś niedorobiona.

 Mało powiedziane. Wydanie-niewypał, RM poprzesuwał kupę *blockerów* na 1.4.1,
 niekompilowanie bądź sypanie się połowy sterowników skwitował przez i tak
 nikt ich nie używa, a dziwaczne problemy ze sterownikami Intela (przez to
 nadal siedzę na 1.3) zostawił bez żadnego komentarza, jakby ich nie było. Ot,
 naciskał na termin ustalony z góry, mimo że był nierealny i wyszło jak
 wyszło... Omijać, czekać na 1.4.1, powinno być używalne.

Można powalczyć. ;) Ja mam aktualnie najnowszy git z gałęzi no-pci-rework z
łatami ze SPEC-a PLD + dodatkowo łatą na zdarzenia klawiatury ([1]). Działa
lepiej niż wydany 1.4 (tyle, że no żadna sztuka).

[1] git://81c28ffd2b13a83770eadcfd7829d35d319d637f
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: sqlite3 3.5.0

[Łukasz Krotowski]

14-09-07, Jakub Bogusz [EMAIL PROTECTED] napisał:
 On Fri, Sep 14, 2007 at 05:06:36PM +0200, Michal Salaban wrote:
  wywalające się testy:
  bind-4.4 bind-4.5 printf-1.7.6 printf-1.8.6 printf-1.9.7 tcl-1.6

 Jeden z testów tcl wykłada się od dawna (od chwili przejścia na tcl
 8.5), a z nowymi wersjami sqlite przychodzą nowe wykładające się testy.

Ot, postęp. ;)
BP NMSP
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: UWAGA użytkownicy driverów nvidia (w tym legacy)

[Łukasz Krotowski]

12-09-07, Andrzej Krzysztofowicz [EMAIL PROTECTED] napisał:
 Arkadiusz Miskiewicz wrote:
  Sterowniki binarne nvidia oraz fglrx nie współpracują z xserverem 1.4, który
  to pluto przerzucił do main :(
 
  Pozostaje kwestia jak to odkręcić...

 Zrobic osobny xserver-compat-nvidia.spec ?
 ;P

Eee, a nie wystarczy `X -ignoreABI` (patrz np. [1]).

[1] http://www.phoronix.com/scan.php?page=news_itempx=NjAxNQ
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: Inkscape

[Łukasz Krotowski]

11-09-07, Marcin Kurzyna [EMAIL PROTECTED] napisał:
 On Tuesday 11 September 2007 18:59:31 Patryk Zawadzki wrote:

  Tak wygląda przezroczystość :/
  Any ideas?

 znane, nierozwiązane
 http://lists.pld-linux.org/mailman/pipermail/pld-users-pl/2007-July/066775.html

 marcin

U mnie działa wyśmienicie. *)

*) Ale ja mam Ac (plus trochę Th, np. xorg i gtk+2) z gcc 3.4.6 (waniliowy).
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: [th] Czy dziala BillardGL?

[Łukasz Krotowski]

01-09-07, Bart [EMAIL PROTECTED] napisał:
 Prosze o sprawdzenie czy u was BillardGL dziala po zbudowaniu z HEAD.

 Na moim Radeonie 9550 i otwartych sterownikach mam czarny ekran oraz
 zmiane rozdzielczosci.
 Czy u was tez tak jest?

U mnie nie do końca th ale xorg z head, Mesa z head, Radeon X700 i działa.
Spróbuj może:

$ LIBGL_DEBUG=verbose BillardGL -w

lub nowych sterowników bezpośrednio z
git://anongit.freedesktop.org/git/mesa/mesa

PS. foobillard jest lepszy. ;)
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: SPECS: monotone.spec - TODO

[Łukasz Krotowski]

13-07-07, Pawel Golaszewski [EMAIL PROTECTED] napisał:
 On Thu, 12 Jul 2007, Łukasz Krotowski wrote:
   Author: bluesDate: Thu Jul 12 20:39:32 2007 GMT
   Module: SPECS Tag: HEAD
    Log message:
   - TODO
  
   +# TODO:
   +# - subpackage with init-scripts
  Co masz na mysli pisząc subpackage with init-scripts? Jakie to mają być
  skrypty startowe jak to nie jest demon tylko narzędzie stricte
  klienckie?

 Czy nie jest możliwe tutaj postawienie servera centralnego, który będzie
 składował dane i umożliwiał scentralizowaną wymianę zmian?

Jest to możliwe ale mtm działa jako serwer (uruchamiany przez mtn serve)
dla pojedynczej bazy (repo). Założenie, że jedna baza obsługuje wszystkie
projekty jest mocno naciągane. W ogóle mtn nie był pisany z myślą o
centralnym serwerze -- patrz http://www.venge.net/mtn-wiki/MasterRepository

 Nawet jeżeli to jest stricte rozproszone, bez centralnego serwera to, żeby
 była możliwa sieciowa wymiana informacji to coś musi nasłuchiwać na
 jakimśtam porcie...

Oczywiście (na 4691 z resztą). Ale w mtn nie mówi się raczej o centralnym
repo, raczej o centralnej gałęzi. A czy ściągasz ją od Ziutka czy Stefka to
już nieistotne. W dokumentacji monotone jest bardzo prosty tutorial --
polecam przeczytać, tam łatwo zobaczyć że idea centralnego serwera jest
w poprzek monotone.

   +# - database format is changing - migrate and regenerate options has
   to be run.
 
  I jak to sobie wyobrażasz? W monotone bazy (repozytoria) są normalnymi
  plikami użytkowników -- mogą być dosłownie wszędzie. To nie jest
  narzędzie typu serwer.

 To były wnioski, które dawno temu sobie zapisałem w pliku i teraz
 tylko zrobiłem commit.

 Mówię tutaj o centralnym rozwiązaniu dla samej dystrybucji. Tak samo jak
 na przykład cvs - też może być wszędzie, ale dostarczamy jakieś
 pudełkowe rozwiązanie. Tu można mieć przecież podobnie.

Tak, tylko nie widzę tej konfiguracji która by była dobra OOTB. Może dałoby
się coś ugrać jeśli w skryptach dałoby się włączyć tylko mtn serve dla dowolnej
bazy w jakimś pre-definiowanym katalogu. Ale tak obsłużymy tylko ,,centralny
serwer'' mtn. A bazy deweloperów i tak trzeba będzie uaktualniać ręcznie.

Nie wiem czy to ma w ogóle sens -- używam mtn już od jakiegoś czasu i
specjalny centralny serwer nie jest potrzebny.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: SPECS: monotone.spec - TODO

[Łukasz Krotowski]

13-07-07, Pawel Golaszewski [EMAIL PROTECTED] napisał:
 On Fri, 13 Jul 2007, Łukasz Krotowski wrote:
 Author: bluesDate: Thu Jul 12 20:39:32 2007 
 GMT
 Module: SPECS Tag: HEAD
  Log message:
 - TODO

 +# TODO:
 +# - subpackage with init-scripts
Co masz na mysli pisząc subpackage with init-scripts? Jakie to mają
być skrypty startowe jak to nie jest demon tylko narzędzie stricte
klienckie?
   Czy nie jest możliwe tutaj postawienie servera centralnego, który
   będzie składował dane i umożliwiał scentralizowaną wymianę zmian?
  Jest to możliwe ale mtm działa jako serwer (uruchamiany przez mtn serve)
  dla pojedynczej bazy (repo). Założenie, że jedna baza obsługuje
  wszystkie projekty jest mocno naciągane.

 Ale nie jest błędne.

 To zależy od zwyczajów lub stylu pracy: Niektórzy lubią mieć wszystko w
 izolowanych bazach, a inni robią jedną i wszystkie projekty wrzucają w
 nią. Ja wiem, że monotone zaleca ten pierwszy sposób, ale to zależy od
 wielu czynników.

DGCC. Btw: Linus przy okazji jakiegoś wykładu o gicie o KDE-owcach (oni
IIRC trzymają wszystkie projekty w jednej bazie) powiedział, że są ,,ugly 
stupid''. ;)

 Poza tym - i tak jak uruchomisz proces nasłuchujący to obsługuje on jedną
 fizycznie bazę, więc rozwiązanie dystrybucyjne dla większej ilości baz nie
 jest możliwe...

Eee, portów ci u nas dostatek. ;)

 [ciach]
  Ale tak obsłużymy tylko ,,centralny serwer'' mtn. A bazy deweloperów i
  tak trzeba będzie uaktualniać ręcznie.

 Niekoniecznie - też da radę :)

Jedyne co mi przychodzi na myśl to:
a) dedykowane miejsce dla deweloperów na bazy w PLD plus własne skrypty
do ich tworzenia,
b) find /home/users -type f -exec file ... ;)
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: SPECS: monotone.spec - TODO

[Łukasz Krotowski]

2007/7/12, blues [EMAIL PROTECTED]:
 Author: bluesDate: Thu Jul 12 20:39:32 2007 GMT
 Module: SPECS Tag: HEAD
  Log message:
 - TODO

 +# TODO:
 +# - subpackage with init-scripts

Co masz na mysli pisząc subpackage with init-scripts? Jakie to mają być
skrypty startowe jak to nie jest demon tylko narzędzie stricte klienckie?

 +# - database format is changing - migrate and regenerate options has to be 
 run.

I jak to sobie wyobrażasz? W monotone bazy (repozytoria) są normalnymi
plikami użytkowników -- mogą być dosłownie wszędzie. To nie jest narzędzie
typu serwer.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: nast.spec

[Łukasz Krotowski]

07-07-07, Bartosz Świątek [EMAIL PROTECTED] napisał:
 07-07-07, Grzesiek Pycia [EMAIL PROTECTED] napisał(a):
  teraz się chyba załączył :)
 

 Zbliżamy się do końca. Teraz mi tylko powiedz co to ma oznaczać
 %{__autoconf}
 %{__libtoolize}
 ?
 Dlaczego taka kolejność?

Kolejność rzeczywiście zła.

 Dlaczego nie ma wywołania intltoolize,
 aclocal, autoheader, automake?

A z tej listy to wszystko jest używane? Bo np. Makefile.am w źródłach
nie widzę (podobnie configure.in). Nie wystarczy autoheader?
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: SPECS: scummvm.spec - 0.10.0 - nasm doesn't work - separated plugi...

[Łukasz Krotowski]

2007/6/22, wolf [EMAIL PROTECTED]:
 Author: wolf Date: Fri Jun 22 18:17:15 2007 GMT
 Module: SPECS Tag: HEAD
  Log message:
 - 0.10.0
 - nasm doesn't work

Tylko raportuję, że na Ac nasm działa ok (tj. scalery hq2x i hq3x kompilują się
i działają dobrze).
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: SPECS: crossmingw32-boost.spec - dll deps, cosmetics

[Łukasz Krotowski]

2007/6/17, qboosh [EMAIL PROTECTED]:
 Author: qboosh   Date: Sat Jun 16 23:05:45 2007 GMT
 Module: SPECS Tag: HEAD
  Log message:
 - dll deps, cosmetics

  Files affected:
 SPECS:
crossmingw32-boost.spec (1.5 - 1.6)

  Diffs:

 
 Index: SPECS/crossmingw32-boost.spec
 diff -u SPECS/crossmingw32-boost.spec:1.5 SPECS/crossmingw32-boost.spec:1.6
 --- SPECS/crossmingw32-boost.spec:1.5   Sat Jun 16 20:09:28 2007
 +++ SPECS/crossmingw32-boost.spec   Sun Jun 17 01:05:40 2007
 @@ -4,11 +4,11 @@
  Summary(pl.UTF-8): Biblioteki C++ Boost - wersja skrośna dla Mingw32
  Name:  crossmingw32-%{realname}
  Version:   1.34.0
 -%define_fver   %(echo %{version} | tr . _)
 +%definefver%(echo %{version} | tr . _)
  Release:   1
  License:   Boost Software License and others
  Group: Libraries
 -Source0:   http://dl.sourceforge.net/boost/%{realname}_%{_fver}.tar.bz2
 +Source0:   http://dl.sourceforge.net/boost/%{realname}_%{fver}.tar.bz2
  # Source0-md5: ed5b9291ffad776f8757a916e1726ad0
  Patch0:%{name}-win.patch
  URL:   http://www.boost.org/
 @@ -63,6 +63,9 @@
  Summary:   %{realname} - DLL libraries for Windows
  Summary(pl.UTF-8): %{realname} - biblioteki DLL dla Windows
  Group: Applications/Emulators
 +Requires:  crossmingw32-bzip2-dll
 +Requires:  crossmingw32-zlib-dll
 +Requires:  wine
^^^
Sprzeciw. Wymaganie wine uniemożliwia zainstalowanie tych bibliotek na
systemie innym niż x86. A mi się często te dllki przydają do budowania
aplikacji win32 na amd64. Rozumiem, że chodzi Ci o /usr/share/wine ale to
chyba lekki overkill.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: SPECS: crossmingw32-boost.spec - dll deps, cosmetics

[Łukasz Krotowski]

17-06-07, Jakub Bogusz [EMAIL PROTECTED] napisał:
 On Sun, Jun 17, 2007 at 02:24:26PM +0200, Łukasz Krotowski wrote:
  2007/6/17, qboosh [EMAIL PROTECTED]:
 [...]
   +Requires:  crossmingw32-bzip2-dll
   +Requires:  crossmingw32-zlib-dll
   +Requires:  wine
  ^^^
  Sprzeciw. Wymaganie wine uniemożliwia zainstalowanie tych bibliotek na
  systemie innym niż x86. A mi się często te dllki przydają do budowania
  aplikacji win32 na amd64. Rozumiem, że chodzi Ci o /usr/share/wine ale to
  chyba lekki overkill.

 Do budowania wystarczają *.dll.a, które są w głównym pakiecie, nie
 wymagającym wine.

Skrót myślowy. Do budowania tak (choć można do i386-mingw32-g++ podać
bezpośrednio dllki -- też sobie radzi). Ale już do uruchomienia (tj.
uruchomienia nie pod wine tylko kopiując program na serwer z win32) nie.
Ale, prawdę mówiąc, --nodeps i --force nie jest niczym starszym w tym
przypadku a pewnie masz rację i _w obrębie PLD_ te dllki przydają się tylko
z wine. Więc nvm.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: SPECS: crossmingw32-boost.spec - dll deps, cosmetics

[Łukasz Krotowski]

17-06-07, Bartosz Taudul [EMAIL PROTECTED] napisał:
 On Sun, Jun 17, 2007 at 02:34:27PM +0200, Łukasz Krotowski wrote:
  bezpośrednio dllki -- też sobie radzi). Ale już do uruchomienia (tj.
  uruchomienia nie pod wine tylko kopiując program na serwer z win32) nie.
 BTW, czy wine nie przestało jakiś czas temu szukać dll-ek w tym katalogu?

Chyba masz rację -- w prostym teście wine nie znajduje bibliotek w
/usr/share/wine/windows/system. Pomaga przeniesienie do
~/.wine/drive_c/windows/system. Co za tym idzie warto by zastanowić się
gdzie w takim razie wrzucać dllki z crossmingw32-*-dll.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: [Th/x86_64] xen, lvm itd

[Łukasz Krotowski]

14-06-07, Andrzej Nakonieczny
[EMAIL PROTECTED] napisał:
 Od kilku dni próbuję zainstalować i skonfigurować Th na x86_64.
 Instalacja wykonana była z RescueCD (x86_64), całość zrobiona na LVM.
 System jednak nie wstał czego się spodziewałem. Wprowadziłem więc
 poprawki na geninitrd zaproponowane na pld-devel-en (sub: geninitrd 8385
 patches and comments), poszedł nieco dalej ale wywalił się na fsck.
 Usunięcie (zmiana nazwy binarki) fsck pomogła choć to nie jest
 rozwiązanie. Czy ktoś ma pomysł jak to poprawnie rozwiązać?

Używasz może udev?
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: SPECS: Tktable.spec - pl

[Łukasz Krotowski]

2007/5/24, qboosh [EMAIL PROTECTED]:
  %if %{_libdir} != %{_ulibdir}
  mv $RPM_BUILD_ROOT%{_libdir}/%{name}%{version} $RPM_BUILD_ROOT%{_ulibdir}
 +# FIXME: this shouldn't be done
  ln -sf %{_libdir}/lib%{name}%{version}.so 
 $RPM_BUILD_ROOT%{_ulibdir}/lib%{name}%{version}.so
  %endif

 [...]

  %if %{_libdir} != %{_ulibdir}
 +# FIXME: this shouldn't be done
  %{_ulibdir}/lib*%{version}.so
  %endif

Dlaczego ,,shouldn't''? I czy masz jakiś lepszy pomysł? I nie, rozwiązanie
takie jak w tk.spec (gdzie na amd64 trzeba dodawać symlink ręcznie
aby zechciało działać) nie jest lepsze.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: [SPEC] Blender

[Łukasz Krotowski]

17-05-07, Daniel Mróz [EMAIL PROTECTED] napisał:

Prośba do szczęśliwych posiadaczy Th (gcc 3.4) o sprawdzenie czy SPEC z
załącznika (wraz z poprawionym patchem) się kompilują. Dziękuję za uwagę i
pomoc.


A posiadacz Ac z gcc 3.4 wystarczy. Bo jeśli tak to nie buduje się na amd64
(linker nie znajduje -lX11). Wystarczy jednak drobna poprawka (patrz załącznik)
i śmiga. Chociaż są jakieś problemy z GUI (nieaktywne okna są czarne).


blender.spec.patch
Description: Binary data
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: [SPEC] Blender

[Łukasz Krotowski]

18-05-07, Bartosz Świątek [EMAIL PROTECTED] napisał(a):
 18-05-07, Łukasz Krotowski [EMAIL PROTECTED] napisał(a):
  17-05-07, Daniel Mróz [EMAIL PROTECTED] napisał:
   Prośba do szczęśliwych posiadaczy Th (gcc 3.4) o sprawdzenie czy SPEC z
   załącznika (wraz z poprawionym patchem) się kompilują. Dziękuję za uwagę i
   pomoc.
 
  A posiadacz Ac z gcc 3.4 wystarczy. Bo jeśli tak to nie buduje się na amd64
  (linker nie znajduje -lX11). Wystarczy jednak drobna poprawka (patrz 
  załącznik)
  i śmiga. Chociaż są jakieś problemy z GUI (nieaktywne okna są czarne).

 Nie wiem czy jest sens sprawdzania tego na gcc 3.4.x. Ani AC ani TH
 takiego gcc nie wspierają. AC 2.1 też nie będzie, więc po co zawracać
 sobie głowę kolejną bzdurą ? Są ważniejsze rzeczy do zrobienia w PLD.

Jeśli pozwolisz, o kompilatorze którego używam na swoich maszynach
będę decydował ja.

A tak przy okazji, czarne okna to niedorobiony domyślny styl GUI -- po
przełączeniu na inny i drobnej konfiguracji już wszystko jest ok.
Wyrenderorowałem sobie prościutką scenę w internalu -- śmiga.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: [SPEC] Blender

[Łukasz Krotowski]

18-05-07, Bartosz Świątek [EMAIL PROTECTED] napisał(a):
 18-05-07, Łukasz Krotowski [EMAIL PROTECTED] napisał:
  18-05-07, Bartosz Świątek [EMAIL PROTECTED] napisał(a):
   18-05-07, Łukasz Krotowski [EMAIL PROTECTED] napisał(a):
17-05-07, Daniel Mróz [EMAIL PROTECTED] napisał:
 Prośba do szczęśliwych posiadaczy Th (gcc 3.4) o sprawdzenie czy SPEC 
 z
 załącznika (wraz z poprawionym patchem) się kompilują. Dziękuję za 
 uwagę i
 pomoc.
   
A posiadacz Ac z gcc 3.4 wystarczy. Bo jeśli tak to nie buduje się na 
amd64
(linker nie znajduje -lX11). Wystarczy jednak drobna poprawka (patrz 
załącznik)
i śmiga. Chociaż są jakieś problemy z GUI (nieaktywne okna są czarne).
  
   Nie wiem czy jest sens sprawdzania tego na gcc 3.4.x. Ani AC ani TH
   takiego gcc nie wspierają. AC 2.1 też nie będzie, więc po co zawracać
   sobie głowę kolejną bzdurą ? Są ważniejsze rzeczy do zrobienia w PLD.
 
  Jeśli pozwolisz, o kompilatorze którego używam na swoich maszynach
  będę decydował ja.

 Oczywiście, że pozwolę i jeśli przeczytasz mój poprzedni post z
 nastawieniem innym niż on mnie atakuje to zrozumiesz o co mi
 dokładnie chodziło. Mianowicie miałem na myśli, że nie ma potrzeby
 martwić się o to gcc dla całego PLD, więc i patche na tą są raczej
 zbędne - buildery i tak takiego gcc nie posiadają. A jeśli używasz coś
 co nie jest oficjalnie przez PLD wspierane, to jest to twoja prywatna
 sprawa i błędy z tym związane też są twoimi prywatnymi (nie mają co
 szukać na tej liście).

A) Daniel chciał test na 3.4.
B) Łatka którą posłałem jest ortogonalna do kompilatora (scons na amd64
szuka libX11.so w /usr/X11R6/lib zamiast w /usr/X11R6/lib64).
C) Ale czy ja zgłaszam jakieś błędy? Nie. Po prostu opisuje wyniki testu.
D) Czy ty chcesz mi delikatnie zasugerować, że nie mogę takiego testu
wykonać i odpisać dlatego, że w PLD nie ma już gcc 3.4?
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: [SPEC] Blender

[Łukasz Krotowski]

18-05-07, Bartosz Świątek [EMAIL PROTECTED] napisał:
  D) Czy ty chcesz mi delikatnie zasugerować, że nie mogę takiego testu
  wykonać i odpisać dlatego, że w PLD nie ma już gcc 3.4?

 Znowu włączył Ci się jakiś agresor. Nie chce po prostu, żeby
 niepotrzebne łatki trafiły do CVSu, a przecież przesłałeś taką łatkę i
 Daniel mógł to potraktować jako zachętę do jej zamieszczenia. Nie
 potraktuje ? To bardzo dobrze, ale wolę dmuchać na zimne. AFAIR nigdy
 nie było gcc 3.4 w PLD. Przewijało się kiedyś 3.4.5 w ac-ready, ale do
 main to takie cuda nigdy nie trafiły.
 Dla mnie EOT.

Ech. Dlaczego niepotrzebne? Ta łata to podbicie wersji wraz z
zaznaczeniem, że można kompilować na 3.4 w górę (oprócz tego
poprawka do tłumaczenia).

Wymóg gcc można wyrzucić (nie widzę powodu, ale dlaczego nie).
W mojej wersji /usr/X11R6/%{_lib} zmienić na %{_x_libraries} -- będzie
niezależne od prefiksu X11 (tak przy okazji: zmienił się dla xorg?).
I zupełnie dobrze będzie pasować na HEAD. Jakby jeszcze ktoś(TM)
na Th sprawdził.

Co do 3.4.5 -- chyba nawet w ready nie było, widziałem tylko w test.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: SPECS: liberation-fonts-ttf.spec (NEW) - init

[Łukasz Krotowski]

2007/5/15, wolvverine [EMAIL PROTECTED]:
 Author: wolvverine   Date: Tue May 15 03:30:54 2007 GMT
 Module: SPECS Tag: HEAD
  Log message:
 - init

  Files affected:
 SPECS:
liberation-fonts-ttf.spec (NONE - 1.1)  (NEW)

Jak to ma się do speca: fonts-TTF-RedHat-liberation.spec?
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: PLDWWW: Repositories

[Łukasz Krotowski]

29-04-07, Łukasz Jernaś [EMAIL PROTECTED] napisał(a):
 Dnia niedziela, 29 kwietnia 2007, Bartosz Taudul napisał:
  On Sun, Apr 29, 2007 at 02:30:49AM +0200, Łukasz Krotowski wrote:
   Nie tyle zdechła co skończyła się wnioskiem, że svn wniósłby więcej
   kłopotów niż pożytku w SPEC-ach.
 
  Jaki znowu wniosek? Po prostu jak zwykle wszystko się rozlazło po kościach.
  Jak to w PLD. Jakby Ktoś (TM) po prostu przerzucił SPECS do svn-a
  i zablokował w cvs-ie, to, wiadomo, były by krzyki i płacze, ale i tak
  by wszyscy używali svn-a.

 A co z git? ;

 BP, PPNMSP

Wiem, że to miał być żart. Ale, IMO, git (czy my preciousss Monotone) spisałby
się znacznie lepiej jako repo dla SPEC-y niż svn. Tylko, że krzyków i płaczu
byłoby pewnie więcej. ;)
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: PLDWWW: Repositories

[Łukasz Krotowski]

29-04-07, Bartosz Taudul [EMAIL PROTECTED] napisał(a):
 On Sun, Apr 29, 2007 at 02:30:49AM +0200, Łukasz Krotowski wrote:
  Nie tyle zdechła co skończyła się wnioskiem, że svn wniósłby więcej
  kłopotów niż pożytku w SPEC-ach.
 Jaki znowu wniosek? Po prostu jak zwykle wszystko się rozlazło po kościach.
 Jak to w PLD. Jakby Ktoś (TM) po prostu przerzucił SPECS do svn-a
 i zablokował w cvs-ie, to, wiadomo, były by krzyki i płacze, ale i tak
 by wszyscy używali svn-a.

IIRC chodziło o zarządzanie gałązkami. Z resztą w SPEC-ach commity są
głównie per plik. A svn lepiej działa gdy commitujesz per zmiana. Tzn.
jeśli zmiany są per plik to nie ma żadnego zysku z przejścia na svn.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: PLDWWW: Repositories

[Łukasz Krotowski]

29-04-07, Paweł Sikora [EMAIL PROTECTED] napisał(a):
 On Sunday 29 of April 2007 16:25:51 Łukasz Krotowski wrote:
  29-04-07, Łukasz Jernaś [EMAIL PROTECTED] napisał(a):
   Dnia niedziela, 29 kwietnia 2007, Bartosz Taudul napisał:
On Sun, Apr 29, 2007 at 02:30:49AM +0200, Łukasz Krotowski wrote:
 Nie tyle zdechła co skończyła się wnioskiem, że svn wniósłby więcej
 kłopotów niż pożytku w SPEC-ach.
   
Jaki znowu wniosek? Po prostu jak zwykle wszystko się rozlazło po
kościach. Jak to w PLD. Jakby Ktoś (TM) po prostu przerzucił SPECS do
svn-a i zablokował w cvs-ie, to, wiadomo, były by krzyki i płacze, ale
i tak by wszyscy używali svn-a.
  
   A co z git? ;
  
   BP, PPNMSP
 
  Wiem, że to miał być żart. Ale, IMO, git (czy my preciousss Monotone)
  spisałby się znacznie lepiej jako repo dla SPEC-y niż svn.

 poniewaz?

Lokalne repo. Prostota w tworzeniu lokalnych, roboczych branchy, podpisane
commity, cherry picking.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: PLDWWW: Repositories

[Łukasz Krotowski]

29-04-07, Mariusz Mazur [EMAIL PROTECTED] napisał:
 Dnia niedziela, 29 kwietnia 2007, Łukasz Krotowski napisał:
  Wiem, że to miał być żart. Ale, IMO, git (czy my preciousss Monotone)
  spisałby się znacznie lepiej jako repo dla SPEC-y niż svn. Tylko, że
  krzyków i płaczu byłoby pewnie więcej. ;)

 Ja byłbym za gitem, gdyby nie fakt, że git praktycznie nie ma user interfejsu.
 W pracy pracuję na darcsie, bo jak się zastanowiłem w końcu co jest
 przyjemniejsze w użytkowaniu -- git, czy darcs, to mi wyszło, że z gitem bym
 się męczył.

Mam bardzo podobne odczucia, tylko zamiast darcs używam monotone.
Głównie dlatego, że monotone jest napisane w języku dla mnie naturalnym
a w Haskellu ledwie potrafię wyskrobać hello world. :)

 Ale sama koncepcja użycia distributed scma (oczywiście zezwalającego także na
 pracę z centralnym repo; git zezwala) jest warta rozważenia.

A są jakieś które nie mają push/pull (lub odpowiedników)?

 Tylko znowu --
 ktoś by musiał przejrzeć wszystkie sensowne, ocenić, które się nadają i
 opisać jak się z tego korzysta.

Ano.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: PLDWWW: Repositories

[Łukasz Krotowski]

29-04-07, Mariusz Mazur [EMAIL PROTECTED] napisał:
 Dnia niedziela, 29 kwietnia 2007, Paweł Sikora napisał:
  ja nie widze w przeniesieniu problemu. nikt nie musi tego robic sam
  w calosci. wystarczy przestawic cvs na read-only i kazdy kto bedzie
  potrzebowal jakis pakiet, to go przeniesie do svn-u.

 To jest akurat (a) bez sensu i (b) najmniejszy problem, bo jak się raz napisze
 jakiś kawałek skryptu do przenoszenia, to się go od razu odpali na całym
 repo. Tylko pierw trza napisać.

Eee, a Tailor by się nie nadał? Gorzej pewnie z automatyką.
___
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

[Łukasz Krotowski]

2007/4/28, Kamil Dziedzic [EMAIL PROTECTED]:
 Co robię nie tak?

 # builder -ba -r AC-branch X11-driver-nvidia.spec
 (blablablabla)
 + cd usr/src/nv/
 + ln -sf Makefile.kbuild Makefile
 + cat
 +  Makefile
 +  EOF
 + mv nv-kernel.o nv-kernel.o.bin
 + compile
 + [ -r /usr/src/linux/config-smp ]
 + exit 1
 błąd: Błędny status wyjścia z /var/tmp/rpm-tmp.14944 (%build)

Było już na liście, przeczytaj wątek ,,AC, kernel.spec -r 2_6_20
i budowanie pakietów okołokernelowych'' i zrob sobie odpowiednie
symlinki.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: PLDWWW: Repositories

[Łukasz Krotowski]

28-04-07, Artur Flinta [EMAIL PROTECTED] napisał:
 Bartosz Taudul wrote:
  Jak kloczek wróci do PLD ;

 Se jaja z kloczka robisz a ja się poważnie pytam :) Była jakiś czas temu
 dyskusja o migracji i zdechła.

Nie tyle zdechła co skończyła się wnioskiem, że svn wniósłby więcej
kłopotów niż pożytku w SPEC-ach.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

DevIL-devel: zaleznosci

[Łukasz Krotowski]

Witam,
w DevIL.spec jest co następuje:
#v+
%package devel
Summary:DevIL devel files
Summary(pl.UTF-8):  Nagłółwki DevIL
Group:  Development/Libraries
Requires:   %{name} = %{version}-%{release}
Requires:   lcms-devel
Requires:   libjpeg-devel
Requires:   libmng-devel
Requires:   libpng-devel
Requires:   libtiff-devel
# libILUT additionally: SDL-devel, allegro-devel, OpenGL-GLU-devel
#v-
Dzieki czemu, po zainstalowaniu DevIL-devel mamy niepełną
funkcjonalność. Może jednak dodać te zależności (albo wydzielić
pod-pakiet dla ILUT -- choć to mniej mi się podoba)?
Pozdrawiam,
Łukasz Krotowski
___
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

[Łukasz Krotowski]

10-04-07, Marcin Król [EMAIL PROTECTED] napisał:
 - GCC 4.1.x

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)?
___
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

[Łukasz Krotowski]

10-04-07, Marcin Król [EMAIL PROTECTED] napisał(a):
  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

Otóż, różnica między 3.3 a 3.4 jest wystarczająco duża aby się z Tobą nie
zgodzić. I o ile 3.3 jest już w tej chwili (Boost) dla mnie problemem to
3.4 spisuje się bardzo dobrze jako podstawowy kompilator. I pewnie nie
zmienię tego do czasu wyjścia gcc 4.3 (IMO wtedy gcc4 będzie już
wystarczająco pewne).

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).

 - gdy Ac juz faktycznie wyzionie ducha, latwiej bedzie z gcc 4.1 w Ac
 przeskoczyc na Th, czy nawet na nastepna wersje

To jest lepszy argument. Z resztą właśnie tego się spodziewałem. Tylko
dlaczego Ac a nie Th stable 1. ;)
___
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

[Łukasz Krotowski]

10-04-07, Marcin Król [EMAIL PROTECTED] napisał(a):
  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?

Były bardzo poważne zmiany. 4.0 to włączenie gałęzi tree-ssa a co za tym
idzie lepsze możliwości optymalizacyjne (np. autowektoryzacja). Do tego
gomp i inne. I właśnie dlatego u siebie czekam z gcc4 aż ,,ochłonie'' (oraz
do ustabilizowania się mingw - ale to zupełnie inna historia).

Inna sprawa, że moje ,,ochłonie'' może oznaczać że ,,cały świat już od dawna
tego używa''. ;)

Chodziło mi tylko o to, że nie było wielu zmian we front-endzie C++ (ten był
mocno zmieniony z 3.3 na 3.4) a co za tym idzie liczba problemów z
kompilacją nie powinna być duża na 3.4.
___
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

[Łukasz Krotowski]

10-04-07, Bartosz Świątek [EMAIL PROTECTED] napisał(a):
  Otóż, różnica między 3.3 a 3.4 jest wystarczająco duża aby się z Tobą nie
  zgodzić. I o ile 3.3 jest już w tej chwili (Boost) dla mnie problemem to
  3.4 spisuje się bardzo dobrze jako podstawowy kompilator. I pewnie nie
  zmienię tego do czasu wyjścia gcc 4.3 (IMO wtedy gcc4 będzie już
  wystarczająco pewne).

 Pozwolę się nie zgodzić. Używałem na Ac gcc 3.4.5 - wynik nie był
 zadawalający, fakt ze działa lepiej niż 3.3 ale nie wszystko się a)
 kompilowało b) działało stabilnie po kompilacji.

Ciekawe rzeczy piszesz, z czym miałeś problem (poważnie pytam,
chętnie dowiem się o problemach w kompilatorze - lepiej teraz niż
na tydzień przed deadlinem)?

 Zupełnie inaczej gcc 4.1.2 - które jest naprawde bardzo fajne. W gcc
 4.1.2 działają już dobrze optymalizacje kodu - nie mówiąc już, że
 kernel budowany na gcc4 jest o niebo szybszy niż taki budowany na gcc
 3.4. Dla mnie gcc 4.1.2 w Ac 2.1 jest bardzo dobrym pomysłem.

Ależ wiem, i w ogólności zgadzam się. Mój pech polega na tym, że nie łapię
się do ,,ogólności''. Choć gcc4 używam. Na mikro-kontrolerach. ;)
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: nast.spec

[Łukasz Krotowski]

01-04-07, Grzesiek Pycia [EMAIL PROTECTED] napisał(a):
  A coś na temat speca, obleci?

Nie bardzo (choć jest lepiej):

1) Nie buduje się na amd64 z powodu wieku config.sub -
trzeba przegenerować (__libtoolize - pamiętaj o BR).

2) Masz jakiś powód aby stosować ułamkowy release?

3) Polskie opisy nie są w UTF-8 (to mniejszy problem) i
są zupełnie niegramatyczne. Aha ang. sniffer to po polsku
też sniffer a ang. analyzer to po polsku analizator. Lepiej
by już było bez nich.

Łatki są OK.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: nast.spec

[Łukasz Krotowski]

02-04-07, Łukasz Krotowski [EMAIL PROTECTED] napisał(a):
 01-04-07, Grzesiek Pycia [EMAIL PROTECTED] napisał(a):
   A coś na temat speca, obleci?

 Nie bardzo (choć jest lepiej):

 1) Nie buduje się na amd64 z powodu wieku config.sub -
 trzeba przegenerować (__libtoolize - pamiętaj o BR).

 2) Masz jakiś powód aby stosować ułamkowy release?

 3) Polskie opisy nie są w UTF-8 (to mniejszy problem) i
 są zupełnie niegramatyczne. Aha ang. sniffer to po polsku
 też sniffer a ang. analyzer to po polsku analizator. Lepiej
 by już było bez nich.

4) Jeśli dajesz BR: pakiet-devel to R: pakiet jest zazwyczaj
zbędne.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: nast.spec

[Łukasz Krotowski]

27-03-07, Grzesiek Pycia [EMAIL PROTECTED] napisał(a):
  I skoro program używa autotools
  do budowania to może zrób coś więcej niż %configure (patrz: makra
  %{__auto*}.
 ... własciwie tak bardzo nie używa autotools lol

Używa autoconfa, a nie używa automake (właśnie obejrzałem źródła).
W takim razie przegenerować configure autoconfem nie zaszkodzi a
automake wyrzuć z BR. No i oczywiście biblioteki statyczne.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: nast.spec

[Łukasz Krotowski]

26-03-07, Grzesiek Pycia [EMAIL PROTECTED] napisał:
 Mam prośbe/pytanie co trzaba by zrobić żeby był on PLD like:)

Tak na pierwszy rzut oka po co %{org_name}, lepiej wpisz nazwę do
tagu Name i używaj %{name}. I skoro program używa autotools
do budowania to może zrób coś więcej niż %configure (patrz: makra
%{__auto*}.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: mingw64, wine64...

[Łukasz Krotowski]

23-03-07, Paweł Sikora [EMAIL PROTECTED] napisał(a):
 1). crossmingw dla visty...

 na poczatku zwalo sie to mingw64, ale jak sie okazalo, ze api visty
 jest zasadniczo 32-bitowe ( tak jak obecnych windowsow ) z mikroskopijnymi
 64-bitowymi dodatkami, to zdecydowano, ze przemianuja target na
 x86_64-pc-mingw32. aktualne binutilsy to juz obsluguja, a latka do gcc
 dodajaca obsluge 64-bitowego m$abi bedzie na dniach ukonczona.

 w zwiazku, ze zbieznoscia api i nazw {i386,x86_64}-pc-ming32 mysle,
 ze korzystnie bedzie wrzucic do crossmingw32-{binutils,gcc} budowanie
 takze wersji x86_64-pc-mingw32. chcialbym uniknac tworzenia specy *-mingw64,
 bo te nie odzwierciedlaja platfromy ( moze kiedys pojawi sie windows
 z 64-bitowym api i wtedy bedziemy uzywac x86_64-pc-mingw64 ).

 co wy na to?

Jeśli piszesz o Viscie to masz na myśli Vistę x86 czy Vistę x64_86?
Bo mam wrażenie, że mylisz pojęcia (Vista to nie 64-bitowy Windows).

 2). wine64...

 moze jest ktos na biezaco z listami wine-a i wie cos o ich planach
 w zwiazku z vista? co prawda w configure widnieje --enable-win64,
 ale nie za bardzo rozumiem co to ma niby budowac?

Wine pozwalające uruchamiać programy dla Windows x64_86. Na razie
głównie nie 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: mingw64, wine64...

[Łukasz Krotowski]

23-03-07, Paweł Sikora [EMAIL PROTECTED] napisał(a):
 On Friday 23 of March 2007 22:00:27 Łukasz Krotowski wrote:
  23-03-07, Paweł Sikora [EMAIL PROTECTED] napisał(a):
   1). crossmingw dla visty...
  
   na poczatku zwalo sie to mingw64, ale jak sie okazalo, ze api visty
   jest zasadniczo 32-bitowe ( tak jak obecnych windowsow ) z
   mikroskopijnymi 64-bitowymi dodatkami, to zdecydowano, ze przemianuja
   target na
   x86_64-pc-mingw32. aktualne binutilsy to juz obsluguja, a latka do gcc
   dodajaca obsluge 64-bitowego m$abi bedzie na dniach ukonczona.
  
   w zwiazku, ze zbieznoscia api i nazw {i386,x86_64}-pc-ming32 mysle,
   ze korzystnie bedzie wrzucic do crossmingw32-{binutils,gcc} budowanie
   takze wersji x86_64-pc-mingw32. chcialbym uniknac tworzenia specy
   *-mingw64, bo te nie odzwierciedlaja platfromy ( moze kiedys pojawi sie
   windows z 64-bitowym api i wtedy bedziemy uzywac x86_64-pc-mingw64 ).
  
   co wy na to?
 
  Jeśli piszesz o Viscie to masz na myśli Vistę x86 czy Vistę x64_86?

 oczywiscie, ze viste x86_64. dlatego pisalem o x86_64-pc-mingw...

Zmyliłeś mnie tą Vistą ale już rozumiem. Argument o API ma mały sens tj.
API musi być takie jakie jest aby zachować wsteczną kompatybilność. Jeśli
ktoś (jak rozumiem okolice gcc i mingw) uznał, że lepszą nazwą będzie
x86_64-pc-mingw32 to ich sprawa.

Co do nazewnictwa SPEC-y i pakietów: to jakie nazwy proponujesz dla gcc
dla Win32 i Win64? Spec, specem ale jak miałyby nazywać się pakiety?
IMO należało by dowiedzieć się jak Danny Smith zechce nazwać mingw dla
Win 64 i tak nazwać pakiety. Tylko, biorąc pod uwagę np. stanowisko
Dannego nt. gcc4, może się okazać, że mingw64 na razie jest niezdatne
do użytku.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: mingw64, wine64...

[Łukasz Krotowski]

23-03-07, Paweł Sikora [EMAIL PROTECTED] napisał(a):
 On Friday 23 of March 2007 22:53:26 Łukasz Krotowski wrote:
  Co do nazewnictwa SPEC-y i pakietów: to jakie nazwy proponujesz dla gcc
  dla Win32 i Win64?

 i386-pc-mingw32 i x86_64-pc-mingw32.

  Spec, specem ale jak miałyby nazywać się pakiety?

 obie wersje binarek chetnie bym widzial w paczkce crossmingw32-gcc.

Ok, jeśli obie binarki mają być w jednym pakiecie to czemu nie.

  IMO należało by dowiedzieć się jak Danny Smith zechce nazwać mingw dla
  Win 64 i tak nazwać pakiety. Tylko, biorąc pod uwagę np. stanowisko
  Dannego nt. gcc4, może się okazać, że mingw64 na razie jest niezdatne
  do użytku.

 nie znam stanowiska Dannego nt. gcc4, ale wiem, ze Kai Tietz bazujac
 na dokumentacji m$ wlasnie konczy implementacje x86_64-pc-mingw32
 dla cc4. nawet juz udalo mu sie zbudowac c,c++ i odpalic na win64.

Stanowisko Dannego jest takie, że gcc4 na win32 ma tyle regresji, że jest
na razie niezdatne do użytku. Może 4.2 będzie jeśli sobie poradzą z wyjątkami
w dllkach (Dwarf2 też). I w ogóle z dllkami.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: mplayer.spec : AC-branch to nie TH

[Łukasz Krotowski]

2007/3/18, Daniel Dawid Light-I Majewski [EMAIL PROTECTED]:
 Może mały log coś opisze :
 -
 $ builder -b AC-branch --with directfb osd svga  mplayer.spec

$ ./builder -r AC-branch --with directfb osd svga  mplayer.spec
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: wine.spec upgrade

[Łukasz Krotowski]

2007/3/17, Łukasz 'LCF' Jagiełło [EMAIL PROTECTED]:
 Czy to duży problem żeby standardowo patchować źródła wine-a takim
 patchem:
 [ciach patch]

 Zmiana niewielka, ale umożliwia płynną grę w WoW-a z użyciem opengl-a. Nie
 wiadomo czemu, ale nadal nie została włączona do głównego drzewka.

Widać Alexandre uznał, że to hack dla jednej aplikacji i do mainline się nie
nadaje (z resztą ta łatka tak właśnie wygląda). IMO można najwyżej dorobić
bconda - choć i w tym nie jestem pewien.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

[Ac] SPECS: tk na amd64

[Łukasz Krotowski]

Witam,
używając (package require tk) tk z Ac (z HEAD chyba też) na amd64
dostaję błąd o nieznalezionej bibliotece  /usr/lib/tk8.4/../libtk8.4.so.0.0.
Dlatego, że ta biblioteka jest w /usr/lib64 a /usr/lib/tk8.4/pkgIndex.tcl
szuka w /usr/lib. Rozwiązaniem jest oczywiście symlink. Pewnie można
też zmienić pkgIndex.tcl - ale to jest bardziej kłopotliwe.

Podobny problem miałem robiąc speca do tile. Tam wrzuciłem
symlinka do pakietu i śmiga. Może warto zrobić odpowiednią poprawkę
i w tk (nie dodałem sam bo nie chcę grzebać na AC-branch w nieswoich
specach - nie wiem czy rozwiązanie jest ok)?

Pozdrawiam,
Łukasz Krotowski
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Pytanie o %ifarch

[Łukasz Krotowski]

Witam,
mam sytuację, że w specu (konkretnie tile) tworzę symlinka w przypadku
gdy istnieje /usr/lib64 (lub ogólnie _libdir != /usr/lib). Później w sekcji
%files mam na x86 ostrzeżenie o zduplikowanym pliku. Pomyślałem, że
mogę wyrzucić duplikat za pomocą %ifarch.

No i teraz mam dwa pytania:
1) Czy to rozwiązanie jest ok? Czy może znacie jakieś lepsze?
2) Jakie architektury mam podać po %ifarch aby wyłapać wszystkie
przypadki gdy _libdir != /usr/lib - czy x8664 wystarczy?

Pozdrawiam,
Łukasz Krotowski
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: Pytanie o %ifarch

[Łukasz Krotowski]

17-03-07, Jakub Bogusz [EMAIL PROTECTED] napisał(a):
 Nie wystarczy. W ogóle nie %ifarch, tylko
 %if %{_lib} != lib

Dzięki. Tak poprawiłem speca.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: xorg-driver-video-nvidia-9631.spec

[Łukasz Krotowski]

07-03-01, Bartosz Świątek [EMAIL PROTECTED] napisał(a):
 07-03-01, Lukasz Glebicki [EMAIL PROTECTED] napisał(a):
  Zrobiłem speca, który pozwala na używanie driverów w wersji 9631 na th.
  Działa. Pozostaje tylko kwestia jego nazwy i opisów. Zanim wrzucę do CVS, to
  proszę o propozycję nazwy speca.
  To moje:
  xorg-driver-video-nvidia-96xx.spec
  xorg-driver-video-nvidia-legacy-96xx.spec
 

 Głupie to. Może teraz kaźda wersja programu będzie miała nowego speca
 ? %{name}-%{version}.spec ? :) Od czego są branche ?

A puścisz z obu gałęzi zlecenie na buildery? Równie dobrze mógłbyś wywalić
legacy w ogóle i wrzucić to do gałęzi.

A propos nazwy: xorg-driver-video-nvidia-nv28 (bo to najnowszy z chipsetów
odrzuconych przez 97xx). Albo może xorg-driver-video-nvidia-nv2x.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: xorg-driver-video-nvidia-9631.spec

[Łukasz Krotowski]

07-03-01, Bartosz Świątek [EMAIL PROTECTED] napisał(a):
 07-03-01, Łukasz Krotowski [EMAIL PROTECTED] napisał(a):
  07-03-01, Bartosz Świątek [EMAIL PROTECTED] napisał(a):
   07-03-01, Lukasz Glebicki [EMAIL PROTECTED] napisał(a):
Zrobiłem speca, który pozwala na używanie driverów w wersji 9631 na th.
Działa. Pozostaje tylko kwestia jego nazwy i opisów. Zanim wrzucę do 
CVS, to
proszę o propozycję nazwy speca.
To moje:
xorg-driver-video-nvidia-96xx.spec
xorg-driver-video-nvidia-legacy-96xx.spec
   
  
   Głupie to. Może teraz kaźda wersja programu będzie miała nowego speca
   ? %{name}-%{version}.spec ? :) Od czego są branche ?
 
  A puścisz z obu gałęzi zlecenie na buildery? Równie dobrze mógłbyś wywalić
  legacy w ogóle i wrzucić to do gałęzi.
 
  A propos nazwy: xorg-driver-video-nvidia-nv28 (bo to najnowszy z chipsetów
  odrzuconych przez 97xx). Albo może xorg-driver-video-nvidia-nv2x.

 Obecnie mamy spece xorg-driver-video-nvidia.spec i
 xorg-driver-video-nvidia-legacy.spec
 więc branch w każdym z nich to pryszcz ! Poza tym builder Th przyjmuje
 zlecenia z _KAŻDEGO_ brancha, więc znowu problemu nie ma.

Ok, źle dobrałem argument. Arka z ftpem jest znacznie lepszy. ;)

 (...)Problem
 pojawia się natomiast przy upgradzie paczek. Będziesz pamietał, żeby
 do zwyklego legacy nie pchać jakiś tam nv2x ? Bo ja nie mam zamiaru
 zaprzątać sobie tym głowy.

A tego nie rozumiem. W tej chwili jak update'ujesz legacy to z serii 71xx.
A nvdia z najnowszego. Teraz dojdzie tylko legacy- z serii 96xx.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

SPECS: crossmingw32-gcc - propagowanie wyjatkow C++ z bibliotek dll

[Łukasz Krotowski]

Witam,
powyższe, czyli propagowanie wyjątków C++ z bibliotek dll, w aktualnym
crossmingw32-gcc (Ac, 3.4.6, 4.1.2), nie działa. Jeśli dobrze rozumiem
związane jest to z tym, że w źródłach z mingw.org są zmiany nie wrzucone
do mainline. Przebudowanie z tych źródeł (ostatniego 3.4.5) z drobnymi
zmianami w configure działa.

Aktualnie mam mocno pokiereszowanego speca z takim gcc. Teraz pytanie,
czy w PLD uznaliście, że takie traktowanie wyjątków to cecha a nie błąd?
Czy też może warto, żebym doprowadził speca do porządku (jak tylko mi
czas pozwoli) i wrzucił na jakąś gałąź w CVS (np. MINGW_ORG)?

Uprzedzam też pytanie - próbowałem przenieść zmiany z mingw.org na
gcc 3.4.6. Ale nie mam teraz tyle czasu, żeby to zrobić porządnie. A wersja
4.x.x leży w ogóle poza zakresem mojego zainteresowania.
Pozdrawiam,
Łukasz Krotowski
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: SPECS: crossmingw32-gcc - propagowanie wyjatkow C++ z bibliotek dll

[Łukasz Krotowski]

07-02-21, Paweł Sikora [EMAIL PROTECTED] napisał:
 On Wednesday 21 of February 2007 17:01:30 Łukasz Krotowski wrote:
  Witam,
  powyższe, czyli propagowanie wyjątków C++ z bibliotek dll,

 tak naprawde, to w c++ nie ma czegos takiego jak biblioteka,
 czy propagowanie wyjatkow miedzy bibliotekami.
 nie ma tez zadnego oficjalnego abi w sferze wyjatkow c++
 i wszystko lezy w detalach implementacji kompiliatora.

Ok, czyli kompilator crossmingw32-gcc w PLD jest skopany (IMO). Ja się tylko
pytam czy mam go poprawiać (też IMO). Nie zrozum mnie źle. Ja zasadniczo
niczego nie zarzucam PLD. Miałem problem - usługa Win32 (też nie ma w
standardzie ;) ) którą pisałem kończyła się bez słowa - jak się okazało
podałem puste wyrażenie regularne. Znalazłem problem, poprawiłem. A teraz
pytam się, czy ktoś jest zainteresowany poprawką.

A napisałem na grupę dlatego, że widzę, że spec jest konsekwentnie rozwijany
bez zwrócenia uwagi na taką sytuację. Więc albo nikt tego nie zauważył albo
nikomu nie jest to potrzebne. Lub też podjęto decyzję aby trzymać się źródeł
z gcc.gnu.org.

A Ty mi tutaj o standardzie... Wedle standardu nawet pthread nie możesz użyć
bo tracisz pojęcie obserwowalności. ;) Skrócę ew. dyskusję, tak wiem, że w
C++0x będą wątki a nie będzie bibliotek dynamicznych.

 w skrocie - nie rob tak jesli nie chcesz miec problemow :)

W skrócie - pisz na [EMAIL PROTECTED] Bo wyjątkami z bibliotek dll
rzucają np. konstruktory boost::thread lub boost::regex. A Boost.Thread IIRC
nie może być zlinkowana statycznie.

  w aktualnym crossmingw32-gcc (Ac, 3.4.6, 4.1.2), nie działa.

 czyzby to?
 http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00133.html

Nie, to jest Dwarf2 - eksperymentalna obsługa wyjątków w mingw. Stabilna
opiera się na SJLJ. Ale jakbyś znalazł odpowiednią łatkę to chętnie obejrzę
(nie jestem na bieżąco z listami gcc).
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: AC i spece w UTF-8

[Łukasz Krotowski]

07-02-13, Arkadiusz Miskiewicz [EMAIL PROTECTED] napisał:
 Można testować rpma z Ac-branch, rel 40. Powinien umieć to i owo
 skonwertować.

Zarówno na unikodowym terminalu jak i na ISO-8859-2 działa dobrze w
pobieżnym teście (`rpm -qi kazehakase` z HEAD).
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: gcc 4.1.2 vs 4.2 in Th

[Łukasz Krotowski]

07-02-09, Marcin 'Qrczak' Kowalczyk [EMAIL PROTECTED] napisał(a):
 Z http://gcc.gnu.org/gcc-4.2/changes.html wynika, że w 4.2 nie ma na
 razie nic nadzwyczajnego.

Poza OpenMP.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: [Ac] Stery Nv

[Łukasz Krotowski]

07-01-31, Marcin Król [EMAIL PROTECTED] napisał(a):
  albo zrobić kolejną
  paczkę z Legacy i utrzymywać dwie, dla zabytków i dla wykopalisk.

 Tak trzeba by zrobic, ale wtedy bedzie problem. Seria 96xx nie jest juz 
 (chyba)
 rozwijana. Pierwszy bug security i paczce mozemy podziekowac. Rozwijane sa
 legacy (71xx) i aktualne 97xx.

A skąd ten wniosek? IMO NVidia wspiera trzy linie sterowników 71, 96 i HEAD.
Nawet jeśli na stronie sterowników nie jest to jeszcze zaznaczone to na forum
wątek o 9631 (legacy) jest potraktowany na równi z 71 i 97.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: [Ac] Stery Nv

[Łukasz Krotowski]

07-01-31, Marcin Król [EMAIL PROTECTED] napisał(a):
  01:00.0 VGA compatible controller: nVidia Corporation NV28 [GeForce4 Ti
  4200 Go AGP 8x] (rev a1)

 Hm. Z ciekawosci wlasnie sprawdzilem strone nvidii i ta karta jest wymieniona
 jako wspierana przez sterowniki 97xx.

 Seria 97xx wspiera: http://www.nvidia.com/object/IO_18897.html
 Lecay (71xx) wspiera: 
 http://www.nvidia.com/object/1.0-7184_supported_products.html

Strona nVidii wydaję się być mocno nieaktualna - popatrz na README do
aktualnych sterowników [1].

[1] 
http://us.download.nvidia.com/XFree86/Linux-x86/1.0-9746/README/appendix-a.html
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

SPECS: nexuiz, nexuiz-data

[Łukasz Krotowski]

Witam,
jeśli można pomarudzę w kwestiach formalnych:

1) Nexuiz to gra a nie ,,silnik do strzelaniny w pierwszej osobie''. Silnik
nazywa się albo darkplaces albo nexuizengine. Co więcej, Nexuiz to raczej
właśnie dane bo początkowo silnik był tworzony zupełnie niezależnie. Z
resztą nadal można użyć darkplaces jako bazy dla Quake'a (make release
zamiast make nexuiz).

2) - require same data version - nieprawda, można użyć danych z 2.2.3 a jako
silnika np. najnowszej bety z [1].

Proponowałbym raczej nexuiz z danymi i R: nexuiz-engine bez numeru wersji.

Pozdrawiam,
Łukasz Krotowski

[1] http://icculus.org/twilight/darkplaces/files/
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: Re: [SPECS] tilda up to 0.9.4

[Łukasz Krotowski]

07-01-22, Bartosz Świątek [EMAIL PROTECTED] napisał(a):

To ja bym jednak nalegał na kilka własnych speców byśmy mogli
podziwiać Twój kunszt etc. etc. blablabla biurokratyczny szmelc. Ok
? Bo rzeczywiście, +w za pierdółki to nawet darekr nie dostał.


Proszę bardzo. Tylko problem jest taki, że niewielu rzeczy używam
dla których nie ma specy w PLD. No ale coś się znajdzie, np. flamerobin.

Zatem, prosze o uwagi (kunsztu tam może za dużo nie ma, ale działa).


flamerobin.spec
Description: Binary data
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: Re: [SPECS] tilda up to 0.9.4

[Łukasz Krotowski]

07-01-22, Łukasz Krotowski [EMAIL PROTECTED] napisał(a):

Zatem, prosze o uwagi (kunsztu tam może za dużo nie ma, ale działa).


Wrrróć. Niepotrzebnie przenosiłem dokumentacje, teraz jest dobrze.


flamerobin.spec
Description: Binary data
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

[SPECS] tilda up to 0.9.4

[Łukasz Krotowski]

Witam,
nowa wersja tildy (i nic więcej, tylko podbicie wersj),
proszę o cvs ci.
Pozdrawiam,
Łukasz Krotowski


tilda.spec.patch
Description: Binary data
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: [SPECS] tilda up to 0.9.4

[Łukasz Krotowski]

07-01-21, Bartosz Świątek [EMAIL PROTECTED] napisał(a):
 Tak poza tematem. Ile Ty już tego nam poprzesyłałeś. Bo powoli lepiej
 pamietam Twoje nazwisko od swojego... Jak masz tego już troche to może
 postaramy sie o jakieś +w dla Ciebie ?

Wbrew pozorom nie tak wiele, trochę dziwnych rzeczy typu kazehakase,
monotone-viz, foobillard, root-tail. Coś, kiedyś przy xorg robiłem. Zaznaczam,
że nie przysłałem nigdy własnego speca. Ostatnio głównie narzekam,
że coś nie działa. ;)

Co do +w, jeśli tylko chcecie, to chętnie - będę mógł drobiazgi wrzucać
bezpośrednio.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: Chce th bo jest nowsze

[Łukasz Krotowski]

07-01-16, Adam Gołębiowski [EMAIL PROTECTED] napisał(a):
   a konkretnie? Bo zabrzmiało to jakby co najmniej się sytem nie podnosił.
   Strzelam, że chodzi o problemu z odmountowaniem rootfs przy kładzeniu
   systemu? Też bym chętnie to widział.
 
  Bo się nie podnosi - szczegóły w [1].

 no tak, ale to _tylko_ z udev są takie jaja. Swoją droga jaki jest
 status tej łatki?

Ano udev, ale już się przyzwyczailem. A co do łatki, jak widzisz,
trwają ustalenia co powinna robić.

  Hmm, to może coś z obsługą sprzętu nie działa. A nie mógłbyś mi
  zbudować kernel-vanilla-smp dla Ac na amd64 z linii 2.6.19. Jeśli
  nadal miałbym problem mógłbym marudzić na LKML. A na razie
  jedyna maszyna amd64, do której mam dostęp, oopsuje mi przy
  budowaniu jądra.

 http://212.244.191.139/~builder/kernel-vanilla/

 budowane z kernel-vanilla.spec:LINUX_2_6_19

Dzięki.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: Chce th bo jest nowsze

[Łukasz Krotowski]

  Kwestia do ustalenia brzmi - dlaczego start_udev na początku rc.sysinit nie
  tworzy odpowiednich urządzeń skoro lvm dla rootfs już wystartował z initrd?
 
  Zmiana kolejności nie jest tu poprawnym rozwiązaniem.
 
 Kwestia do ustalenia:
 czy lvm ma jakies odzwierciedlenie w /proc lub /sys bo ja nie zauwazylem.
 Jesli nie to start_udev chyba automagicznie tego nie zrobi (o ile nie
 zrobi sie manualnej konfiguracji udeva)

Można coś wnioskować z /proc/partitions, z obecności narzędzi do lvm, z
obecności modułów w pamięci. Jeśli te warunki są spełnione moża gdzieś
(nie wiem czy akurat w start_udev, może po prostu wcześniej w rc.sysinit)
wywołać vgscan. Pewnie wtedy ponowny start lvm byłby zbędny.

Podobnie chyba z kończeniem pracy. Jeśli pewne warunki są spełnione (np.
są narzędzia do lvm i wpis w fstab wskazuje rootfs na /dev/mapper/*) można
przyjąć, że rootfs jest na lvm. I deaktywować grupę w dwóch etapach.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: Chce th bo jest nowsze

[Łukasz Krotowski]

 Podobnie chyba z kończeniem pracy. Jeśli pewne warunki są spełnione (np.
 są narzędzia do lvm i wpis w fstab wskazuje rootfs na /dev/mapper/*) można
 przyjąć, że rootfs jest na lvm. I deaktywować grupę w dwóch etapach.

Jeszcze jedno. Może się tak zdarzyć, że rootfs jest na lvm a ten jest na raid
(md). Dowód, że tak się może zdarzyć stoi metr ode mnie. ;)  Wtedy
mdadm --stop też nie bardzo pasuje. Tyle, że automagiczne wykrywanie takiej
sytuacji może być nużące. A i problem nie jest palący (ot, jakieś komunikaty).
Może do zamykania systemu dać konfigurację w /etc/sysconfig/system i przestać
się tym przejmować.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: Chce th bo jest nowsze

[Łukasz Krotowski]

07-01-16, Daniel Mróz [EMAIL PROTECTED] napisał(a):
   No, ale Ac jest teraz chyba bardziej unstable niż Th :)  Od wielu
   dni żadnych aktualizacji, a to co jest nie działa najlepiej.
  Konkrety?
 Jeśli chodzi o desktop, to np.:
 [ciach]
 itd. itp.

Z rzeczy nie do końca desktopowych:
- root na lvm nie jest dobrze obsługiwane przez rc-scripts,
- aktualne jądro (2.6.16) na amd64 u mnie, przy próbie kompilacji
czegoś większego robi ups i panikuje. Na athlon działa ok.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: Chce th bo jest nowsze

[Łukasz Krotowski]

07-01-16, Adam Gołębiowski [EMAIL PROTECTED] napisał(a):
  Z rzeczy nie do końca desktopowych:
  - root na lvm nie jest dobrze obsługiwane przez rc-scripts,

 a konkretnie? Bo zabrzmiało to jakby co najmniej się sytem nie podnosił.
 Strzelam, że chodzi o problemu z odmountowaniem rootfs przy kładzeniu
 systemu? Też bym chętnie to widział.

Bo się nie podnosi - szczegóły w [1].

  - aktualne jądro (2.6.16) na amd64 u mnie, przy próbie kompilacji
  czegoś większego robi ups i panikuje. Na athlon działa ok.

 soa #1 - Ac, 2.6.16 i buduje ślicznie. Oprócz tego, że buduje sobie
 paczki (dla i686 i dla amd64), to dodatkowo na tej maszynie stoi builder
 th.

Hmm, to może coś z obsługą sprzętu nie działa. A nie mógłbyś mi
zbudować kernel-vanilla-smp dla Ac na amd64 z linii 2.6.19. Jeśli
nadal miałbym problem mógłbym marudzić na LKML. A na razie
jedyna maszyna amd64, do której mam dostęp, oopsuje mi przy
budowaniu jądra.

[1] 
http://lists.pld-linux.org/mailman/pipermail/pld-devel-pl/2007-January/138611.html
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

[Ac] tetex i zaleznosc od kpathsea

[Łukasz Krotowski]

Witam,
#v+
  29:tetex # [ 83%]
/usr/bin/texhash[77]: kpsewhich: not found
  30:kpathsea   # [ 86%]
#v-

Czy przypadkiem w tetex.spec nie przydałby się PreReq: kpathsea?
Pozdrawiam,
Łukasz
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: [Ac] tetex i zaleznosc od kpathsea

[Łukasz Krotowski]

Z resztą podobnie w sgml-common.spec:
#v+
   1:sgml-common [  3%]
/var/tmp/rpm-tmp.6114[10]: /usr/bin/xmlcatalog: not found
error: %post(sgml-common-0.6.3-5.noarch) scriptlet failed, exit status 127
...
   6:libxml2-progs  # [ 17%]
#v-
PreReq: libxml2-progs.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: [Ac] tetex i zaleznosc od kpathsea

[Łukasz Krotowski]

07-01-13, Andrzej Krzysztofowicz [EMAIL PROTECTED] napisał:
 Jako rozwiazanie dorazne dla Ac ?
Aha.

 Bo w rpm-ie z HEAD i tak PreReq nie dziala i trzeba wymyslic cos innego...
A nie jest tak, że w nowym rpm-ie PreReq będzie tożsame z Requires?
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: [Ac] tetex i zaleznosc od kpathsea

[Łukasz Krotowski]

07-01-13, Andrzej Krzysztofowicz [EMAIL PROTECTED] napisał(a):
 Tu chyba raczej nalezaloby z kpathsea wydzielic podpakiet (-doc ?)
 wymagajacy tetexa. Czy moze jest on jeszcze do czegos potrzebny?

Masz rację, nie zauważyłem, że pliki dokumentacji wymagają tetexa
(a właściwie to tylko tetex-dirs-fonts, czy może czegoś nie widzę).
Rzeczywiście raczej należy wydzielić podpakiet.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: [Ac] tetex i zaleznosc od kpathsea

[Łukasz Krotowski]

07-01-13, Andrzej Krzysztofowicz [EMAIL PROTECTED] napisał(a):
 A to wyglada mi na blad poldka. Bo rpm powinien po zaleznosciach
 zainstalowac to we wlasciwej kolejnosci.

Hmm... z poldka:
Executing rpm --upgrade -vh --root / --noorder...

--noorder ?!
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: [RFC] rc-scripts + rootfs na lvm + udev

[Łukasz Krotowski]

07-01-08, Tomasz Mateja [EMAIL PROTECTED] napisał(a):
 Obecna kolejność wykonywania operacji w rc.sysinit nie pozwala na
 posiadanie rootfs na lvm. W momencie startu udev-a nie wie on nic o
 urządzeniach w /dev/mapper i

 show Checking root filesystem; started
 initlog -c fsck -C -T -a $fsckoptions /

 wykonuje sie przed składaniem lvm-a.
 można sobie z tym poradzić ręcznie konfigurując udev-a lub wylączajac
 fsck w fstabie a gdyby lvm startowal zaraz po udevie to byłoby bardziej
 plug'n'play :)

Wyłączenie fsck to jest zły pomysł (fs może nie chcieć wstać bez fsck).
Raczej trzeba uruchomić lvm przed fsck. Posłałem (31.12) list z
propozycją łatki która, ,,u mnie 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: [RFC] rc-scripts + rootfs na lvm + udev

[Łukasz Krotowski]

07-01-08, Tomasz Mateja [EMAIL PROTECTED] napisał(a):
 Łukasz Krotowski wrote:
  07-01-08, Tomasz Mateja [EMAIL PROTECTED] napisał(a):
  Obecna kolejność wykonywania operacji w rc.sysinit nie pozwala na
  posiadanie rootfs na lvm. W momencie startu udev-a nie wie on nic o
  urządzeniach w /dev/mapper i
 
  show Checking root filesystem; started
  initlog -c fsck -C -T -a $fsckoptions /
 
  wykonuje sie przed składaniem lvm-a.
  można sobie z tym poradzić ręcznie konfigurując udev-a lub wylączajac
  fsck w fstabie a gdyby lvm startowal zaraz po udevie to byłoby bardziej
  plug'n'play :)
 
  Wyłączenie fsck to jest zły pomysł (fs może nie chcieć wstać bez fsck).
  Raczej trzeba uruchomić lvm przed fsck. Posłałem (31.12) list z
  propozycją łatki która, ,,u mnie działa''.
 rozumiem że o tego maila chodzi:
 http://lists.pld-linux.org/mailman/pipermail/pld-devel-pl/2006-December/138456.html

 Problem ten sam ale nie chodzi o to żeby dopisać vgscan przed fsck tylko
 przenieść sekcję Scanning for LVM volume groups przed fsck, a może w
 zależności od tego gdzie leży rootfs wykonać lub nie (jeśli rootfs jest
 na lvm to moduły będą już załadowane) vgscan - odpalanie bezwarunkowe
 nie ma sensu.

U mnie ma bardzo duży sens. ;) A poważnie, po prostu nie grzebałem nigdy
w rc-scripts i tylko ilustrowałem problem.
___
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

[Łukasz Krotowski]

Summa summarum potrzeba dwóch pakietów legacy.
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

Re: SPECS: kdelibs.spec - libloader reworked (i hope), release 5.

[Łukasz Krotowski]

07-01-05, Arkadiusz Miskiewicz [EMAIL PROTECTED] napisał(a):
 W API qt/libstdc++ nie ma funkcji których można by użyć zamiast boosta?

W libstdc++ nie, w Qt tak (QDir/QFile/QRegExp). Rzeczywiście trochę
szkoda Boosta na KDE. ;)
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl

[Ac] rc-scripts + LVM

[Łukasz Krotowski]

Witam,
najpierw środowisko:
Ac, root na LVM2 z jfs, udev.

Teraz problem:
przy starcie systemu fsck.jfs nie jest w stanie sprawdzić / dlatego że
odpowiednie pliki w /dev jeszcze nie istnieją. Wyłączenie fsck na starcie
powoduje, że drobna awaria (pii... sterownik ATI) i Alt+SysRq SUB po
restarcie nie pozwala zamontować /.

Rozwiązałem to przez zmianę rc.sysinit - załączam łatkę. Zakładam, że można
tą łatkę nieco ,,upiększyć'' ale niestety nie znam się na rc-scripts.
Polecam uwadze kogoś bardziej obeznanego.
Pozdrawiam,
Łukasz Krotowski


rc.sysinit.patch
Description: Binary data
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl