Re: SPECS: k3b.spec - added BR: growisofs = 5.10 - added BR: dvd+rw-t...
On Sunday 02 April 2006 23:26, Sławomir Paszkiewicz wrote: Cytowanie Arkadiusz Miskiewicz [EMAIL PROTECTED]: Zacznijmy używać Suggest (w Th). W AC po staremu czyli bez takich numerów jak wymuszanie R na wszystko zwłaszcza, że k3b jest używalne bez takich narzędzi. Ok, to cofne, ale IMO k3b wtedy jest kulawy troszke... Hmm, Suggest? No ja mam TH i mi nie zasugerowal tego, jak to uzywac? Pomęcz misia by zaimplementował obsługę w poldku. -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: SPECS: dosbox.spec - 0.65
--- Andrzej Krzysztofowicz [EMAIL PROTECTED] wrote:
Bartosz Taudul wrote:
On Sun, Apr 02, 2006 at 01:22:53PM +0200, Jakub Bogusz wrote:
-Patch0:%{name}-hq2x.patch
-Patch1:%{name}_coreswitch.patch
Funkcjonalność dodawana przez te dwie łaty nie jest już potrzebna?
Jak ktoś potrzebuje, to niech sobie zrobi. Nie jest to nic krytycznego.
Nowa polityka?
Proponuje umiescic te metode postepowania w pld-devel-hints.
;P
Polityka jest zła. Doprowadza do sytuacji, gdzie łaty niezaakceptowane
przez autorów programów zalegają cvs doprowadzając do stagnacji
rozwoju pakietu. *Dodatkowe* funkcjonalności powinny być wyłączone
przez bcond by default, a brak aktywnego ich utrzymywania ze strony
dodającego powinien być traktowany jako sygnał do ich usunięcia.
Mając taką politykę, nie popadlibyśmy w home_etc czy przypadki w
których tylko jedna osoba (czytaj qboosh) posiada umięjętności w
rozwijaniu pakietu.
--
Fryderyk Dziarmagowski
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: SPECS: k3b.spec - added BR: growisofs = 5.10 - added BR: dvd+rw-t...
Dnia Sun, 02 Apr 2006 22:45:05 +0300, Fryderyk Dziarmagowski [EMAIL PROTECTED] napisał: - dodałeś R: a nie BR - wycofaj tą bzudrę co żeś ją dodał Ja dodałem? Czytaj uważnie i zwracaj uwage, do kogo kierujesz maile. [EMAIL PROTECTED] -- Fear leads to anger, anger leads to hate, hate leads to suffering Yoda ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
splashutils 1.1.9.10
Witam,
Przez parę ostatnich tygodni ostro walczyłem z fbsplashem... Za cholerę nie
chciało to ruszyć. Konkretniej to coś się pokazywało, ale najważniejszego -
czyli obrazka - nie było widać.
Po długich bojach okazało się, że splashutils jest zdeecydowanie za
stare (0.9.cośtam). Ściągnąłem z CVSa - poprawiło się, tylko że wygenerowane
initrd powodowały oopsowanie kernela :-/
W załączniku podsyłam makefile.patch dla ostatnich splashutils - 1.1.9.10.
Mógłby ktoś to wrzucić i podbić wersję? U mnie dopiero te splashutils
zaskutkowały prawidłowym działaniem wszystkich elementów...
Pozdrawiam,
--
Jacek Osiecki [EMAIL PROTECTED] GG:3828944
Poglądy polityczne mają takie znaczenie w sejmie jak upierzenie u krokodyla
(c) Tomasz Olbratowski 2004diff -Nur splashutils-1.1.9.10.orig/Makefile splashutils-1.1.9.10/Makefile
--- splashutils-1.1.9.10.orig/Makefile 2005-09-29 01:40:24.0 +0200
+++ splashutils-1.1.9.10/Makefile 2006-04-02 20:20:31.0 +0200
@@ -8,8 +8,6 @@
#
PKG_VERSION = 1.1.9.10
-DEBUG = false# set to true to prevent stripping
-K_SHARED = false # set to true if you want to link to a shared
klibc
QUIET= true
CC = gcc
@@ -17,7 +15,6 @@
JPEGSRC?= libs/jpeg-6b
LPNGSRC ?= libs/libpng-1.2.8
-ZLIBSRC ?= libs/zlib-1.2.3
FT2SRC ?= libs/freetype-2.1.9
prefix =
@@ -30,26 +27,13 @@
INSTALL_DATA = ${INSTALL} -m 644
INSTALL_SCRIPT = ${INSTALL_PROG}
-ifeq ($(strip $(K_SHARED)),true)
- K_LDFLAGS = -shared
-else
- K_LDFLAGS = -static
-endif
-
-ifeq ($(strip $(QUIET)),true)
- Q = @
- OUTPUT = /dev/null
-else
- Q =
- OUTPUT = /dev/stdout
-endif
+OUTPUT = /dev/stdout
ROOT = $(shell pwd)
# flags for the kernel utils
-K_CFLAGS = -w -ffunction-sections -fdata-sections $(MISCINCS) \
- -I$(ROOT)/$(ZLIBSRC) -I$(ROOT)/$(FT2SRC)/include
-I$(ROOT)/linux/include -I$(ROOT)/linux/include2 \
- -DWITH_ERRLIST -DTARGET_KERNEL
-DTT_CONFIG_OPTION_BYTECODE_INTERPRETER
+K_CFLAGS = -I$(FT2SRC)/include -I/usr/include -ffunction-sections \
+-fdata-sections -DTARGET_KERNEL
-DTT_CONFIG_OPTION_BYTECODE_INTERPRETER
PNGDEFS = -DPNG_NO_WRITE_TIME -DPNG_NO_FLOATING_POINT_SUPPORTED
-DPNG_NO_WRITE_SUPPORTED -DPNG_NO_READ_iTXt \
-DPNG_LEGACY_SUPPORTED -DPNG_NO_PROGRESSIVE_READ
-DPNG_NO_MNG_FEATURES -DPNG_NO_CONSOLE_IO \
@@ -62,10 +46,9 @@
K_DEPS =
# flags for the user utils
-CFLAGS = -Wall -g
LDLIBS = -ljpeg -lm
LDFLAGS =
-INCLUDES = -I$(ROOT)/linux/include -I/usr/include/freetype2
+INCLUDES = -I/usr/linux/include -I/usr/include/freetype2
OBJS = splash.o parse.o render.o image.o cmd.o common.o daemon.o list.o
effects.o
# checks whether an opton is set in config.h
@@ -88,16 +71,12 @@
endif
ifeq ($(call config_opt,CONFIG_PNG),true)
- K_LDLIBS += $(LPNGSRC)/libpng.a $(ZLIBSRC)/libz.a
+ K_LDLIBS += $(LPNGSRC)/libpng.a -lz
K_DEPS += libpng
LDLIBS += -lpng -lz -lm
endif
-ifeq ($(strip $(DEBUG)),true)
- STRIP = true
-else
STRIP = strip --strip-all -R .comment -R .note
-endif
KOUT = kernel
dotg= \e[32;01m*\e[0m
@@ -120,38 +99,21 @@
$(SP_UTIL): $(OBJS)
@$(call info,LD,$@)
- $(Q)$(CC) $+ $(LDLIBS) -o $@
- $(Q)$(CC) $+ $(LDLIBS) -static -o [EMAIL PROTECTED]
-
-linux:
- @if [ ! -e $(ROOT)/linux ]; then \
- ln -s /lib/modules/`uname -r`/source/ $(ROOT)/linux; \
- fi
+ $(CC) $+ $(LDLIBS) -o $@
+ $(CC) $+ $(LDLIBS) -static -o [EMAIL PROTECTED]
kdir:
@if [ ! -d $(ROOT)/$(KOUT) ]; then \
mkdir $(ROOT)/$(KOUT) ; \
fi
-zlib: config.h
- @cd $(ZLIBSRC) ; \
- if [ ! -e ./Makefile ]; then \
- $(call info,CONF,zlib) ; \
- CC=$(KLCC) CFLAGS=$(K_CFLAGS) \
- ./configure $(OUTPUT); \
- sed -i 's#^CFLAGS=\(.*\)#CFLAGS=\1 $(K_CFLAGS)#' Makefile ; \
- fi ; \
- if ! make -q CC=$(KLCC) libz.a; then $(call info,MAKE,zlib) ; fi ; \
- make CC=$(KLCC) libz.a $(OUTPUT)
-
-libpng:zlib config.h
+libpng:config.h
@cd $(LPNGSRC) ; \
if [ ! -e ./Makefile ]; then \
$(call info,CONF,libpng) ; \
cp scripts/makefile.linux Makefile $(OUTPUT); \
sed -i -e '/^CFLAGS/ { N ; s#^CFLAGS=.*#CFLAGS=$(K_CFLAGS)
$(PNGDEFS)# ; P ; D }' \
- -e 's#^ZLIBINC=.*#ZLIBINC=$(ZLIBSRC)#' \
- -e 's#^ZLIBLIB=.*#ZLIBLIB=$(ZLIBSRC)#' Makefile ; \
+ Makefile; \
fi ; \
if ! make -q CC=$(KLCC) libpng.a; then $(call info,MAKE,libpng) ; fi ; \
make CC=$(KLCC) libpng.a $(OUTPUT)
@@ -180,29 +142,28 @@
if ! make -q CFLAGS=$(K_CFLAGS) library; then $(call
info,MAKE,freetype2) ; fi ; \
make CFLAGS=-c $(K_CFLAGS) library $(OUTPUT)
-splash_kern:
Re: splashutils 1.1.9.10
Dnia Mon, 03 Apr 2006 10:19:49 +0300, Jacek Osiecki [EMAIL PROTECTED] napisał: U mnie dopiero te splashutils zaskutkowały prawidłowym działaniem wszystkich elementów... Looknę na to po południu. Powiedz mi - czy przez zadziałało rozumiesz, że odpaliłeś splash silent z initrd? Mi się udało odpalić fbsplasha, ale z initramfs, a i tak od momentu, gdy ruszają rc-skrypty, debug wrzucany jest do framebufora nadpisując powoli tapetę. Jajko 2.6.15-1 [EMAIL PROTECTED] -- Fear leads to anger, anger leads to hate, hate leads to suffering Yoda ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: stbr (ac)
20:23 @RMF STBR: kernel24-net-e100.spec, kernel24-net-e1000.spec, ians.spec Poszlo. Jakie naglowki 2.4 sa teraz na builderach? 2.4.32-4 M. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: SPECS: dosbox.spec - 0.65
Fryderyk Dziarmagowski wrote:
--- Andrzej Krzysztofowicz [EMAIL PROTECTED] wrote:
Bartosz Taudul wrote:
On Sun, Apr 02, 2006 at 01:22:53PM +0200, Jakub Bogusz wrote:
-Patch0: %{name}-hq2x.patch
-Patch1: %{name}_coreswitch.patch
Funkcjonalność dodawana przez te dwie łaty nie jest już potrzebna?
Jak ktoś potrzebuje, to niech sobie zrobi. Nie jest to nic krytycznego.
Nowa polityka?
Proponuje umiescic te metode postepowania w pld-devel-hints.
;P
Polityka jest zła. Doprowadza do sytuacji, gdzie łaty niezaakceptowane
przez autorów programów zalegają cvs doprowadzając do stagnacji
rozwoju pakietu. *Dodatkowe* funkcjonalności powinny być wyłączone
przez bcond by default, a brak aktywnego ich utrzymywania ze strony
dodającego powinien być traktowany jako sygnał do ich usunięcia.
Mając taką politykę, nie popadlibyśmy w home_etc czy przypadki w
których tylko jedna osoba (czytaj qboosh) posiada umięjętności w
rozwijaniu pakietu.
Zgoda. Ale jesli chcemy porzucic dotychczas obowiazujace zasady. to trzeba
by sprecyzowac nowe i uzyskac w tej sprawie koncensus. W przeciwnym razie
bedziemy zaraz mieli:
- ping-ponga, bo ktos stwierdzi, ze te w/w funkcjonalnosc jest jednak
potrzebna i, stosujac dokladnie te sama zasade, cofnie speca do poprzedniej
wersji.
- kernel bez iptables (bo do najnowszej wersji jadra nie ma latki z
netfiltrem)
- zanikniecie wielu pozytecznych zmian w pakietach, ktorych autorzy z zasady
olewaja poprawki
- brak chetnych do poprawiania bledow (bo po co, skoro bede musial w
nieskonczonosc konserwowac swoje poprawki)
IMO Bartek powinien cofnac zmiane do czasu sprecyzowania odpowiednich zasad;
chyba, ze prosil autorow o aktualizacje latek, a ci sprawe olali...
BTW, to raczej temat na pld-discuss juz sie zrobil...
--
===
Andrzej M. Krzysztofowicz [EMAIL PROTECTED]
phone (48)(58) 347 14 61
Faculty of Applied Phys. Math., Gdansk University of Technology
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: splashutils 1.1.9.10
On Mon, 3 Apr 2006, [EMAIL PROTECTED] wrote: Dnia Mon, 03 Apr 2006 10:19:49 +0300, Jacek Osiecki [EMAIL PROTECTED] napisał: U mnie dopiero te splashutils zaskutkowały prawidłowym działaniem wszystkich elementów... Looknę na to po południu. Powiedz mi - czy przez zadziałało rozumiesz, że odpaliłeś splash silent z initrd? Tak. Udało się zarówno z użyciem initrd, jak i z wkompilowaniem splasha w sam kernel (czyli zamiast do /boot/initrd-fbsplash-emergence, do /usr/src/linux/usr/initramfs_data.cpio.gz) - pojawia się minimalnie wcześniej. Mi się udało odpalić fbsplasha, ale z initramfs, a i tak od momentu, gdy ruszają rc-skrypty, debug wrzucany jest do framebufora nadpisując powoli tapetę. Coś takiego mi się działo przy testach gdy odpalałem z init=/bin/bash :) Natomiast ja zrobiłem tak: 1. własny kernel, skompilowany vaniliowy 2.6.16 z nałożonymi fbsplash i vesa-tng, ew. z wkompilowanym splashem do kernela, 2. Zmiana w skryptach startowych - zamiana S98fbsplash na S01fbsplash: przecież chodzi o to, żeby ten splash się pojawiał jak najwcześniej... Jeszcze nie mogę uporać się z progress barem: gdy testuję komendę splash_util --vc=0 -t emergence -m s -p 12345 - to ładnie pokazuje się progress bar, natomiast gdy wrzucę takie komendy w /etc/rc.d/init.d/* to progress bar w ogóle się nie pokazuje ani tym bardziej nie przesuwa... Pozdrawiam, -- Jacek Osiecki [EMAIL PROTECTED] GG:3828944 Poglądy polityczne mają takie znaczenie w sejmie jak upierzenie u krokodyla (c) Tomasz Olbratowski 2004___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: SPECS: dosbox.spec - 0.65
On Mon, Apr 03, 2006 at 10:27:48AM +0200, Andrzej Krzysztofowicz wrote: IMO Bartek powinien cofnac zmiane do czasu sprecyzowania odpowiednich zasad; chyba, ze prosil autorow o aktualizacje latek, a ci sprawe olali... W tym przypadku on sam te łaty wcześniej dodał. Pytałem się tylko dlatego, że zabrakło komentarza przy usunięciu. -- Jakub Boguszhttp://qboosh.cs.net.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
ftp - indeksy
Indeksy poldeka są do poprawienia. ac ftp://ftp.ac.pld-linux.org/dists/ac/PLD/i686/PLD/RPMS/ (type=pndir) poldek:/all-avail upgrade kdebluetooth-1.0-0.beta1.6 Przetwarzanie zależności... kdebluetooth-1.0-0.beta1.5 zostanie zastąpiony przez kdebluetooth-1.0-0.beta1.6 kdebluetooth-1.0-0.beta1.6 zaznaczył mpeg4ip-libs-1.4.1-2 (wł. libsdp.so.0) Zaznaczono 2 pakiety do instalacji (1 zaznaczony pośrednio), 1 do usunięcia: I kdebluetooth-1.0-0.beta1.6 D mpeg4ip-libs-1.4.1-2 R kdebluetooth-1.0-0.beta1.5 Need to get 2.0MB of archives (2.0MB to download). After unpacking 6.0MB will be used. Retrieving ac::kdebluetooth-1.0-0.beta1.6.i686.rpm... błąd: vfff: /dists/ac/PLD/i686/PLD/RPMS/kdebluetooth-1.0-0.beta1.6.i686.rpm: nie ma takiego pliku (odpowiedź serwera: Failed to open file.) Wystąpiły błędy podczas instalacji poldek:/all-avail -- # Piotr Czapski # http://piotr.czapski.info # petec(at)pld-linux.org ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: splashutils 1.1.9.10
Tak. Udało się zarówno z użyciem initrd, O - to ciekawe. I po prostu wrzuciłeś zawartość tego, co generuje splash_geninitramfs do initrd i ruszyło? Bez żadnych bajerów? Czy wywołujesz na siłe w linuxrc /sbin/splash_helper? Coś takiego mi się działo przy testach gdy odpalałem z init=/bin/bash :) U mnie init=/sbin/initng Natomiast ja zrobiłem tak: 1. własny kernel, skompilowany vaniliowy 2.6.16 z nałożonymi fbsplash i vesa-tng, ew. z wkompilowanym splashem do kernela, Cięciwa mówi, że w naszym jajku vesa-tng nie ma. Ja odpalam na standardowym vesafb, na radeonfb jeszcze mi się nie udało. 2. Zmiana w skryptach startowych - zamiana S98fbsplash na S01fbsplash: przecież chodzi o to, żeby ten splash się pojawiał jak najwcześniej... Hm, to mi wygląda, jakbyś nie odpalał splasha podczas bootowania kernela, ale dopiero jak ruszą rc-skrypty? Masz splash silent zanim pojawi się Powered by PLD Linux Distribution ? Zaraz w momencie, gdy normlanie pokazuje się pingwinek przy inicjalizacji fb? Ja odnoszę wrażenie, że odpalasz to w userspace, a nie w kernel jak powinno być. Jeszcze nie mogę uporać się z progress barem: gdy testuję komendę splash_util --vc=0 -t emergence -m s -p 12345 - to ładnie pokazuje się progress bar, natomiast gdy wrzucę takie komendy w /etc/rc.d/init.d/* to progress bar w ogóle się nie pokazuje ani tym bardziej nie przesuwa... Nic mi o tym nie wiadomo. Tak daleko jeszcze nie zaszedłem :D Zdroofka [EMAIL PROTECTED] -- Fear leads to anger, anger leads to hate, hate leads to suffering Yoda ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: ftp - indeksy
Indeksy poldeka są do poprawienia. Poprawie jak tylko dojade do roboty, bo teraz musze juz zmykac. M. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: splashutils 1.1.9.10
On Mon, 3 Apr 2006, [EMAIL PROTECTED] wrote: Tak. Udało się zarówno z użyciem initrd, O - to ciekawe. I po prostu wrzuciłeś zawartość tego, co generuje splash_geninitramfs do initrd i ruszyło? Bez żadnych bajerów? Czy wywołujesz na siłe w linuxrc /sbin/splash_helper? Aha - tu mamy małe nieporozumienie :) Ja nie używam initrd, tzn. używam obecnie - tylko i wyłącznie do fbsplasha. Coś takiego mi się działo przy testach gdy odpalałem z init=/bin/bash :) U mnie init=/sbin/initng No to nie wiem - może initng jakoś gorzej współpracuje z framebufferem, w każdym razie sytuację gdy komunikaty po chamsku wycinały linijki z obrazka miałem tylko przy init=/bin/bash. Inna sprawa, że to chyba tylko kwestia dorzucenia paru plików do PLDowego intird, prawda? No i w razie czego można właśnie wbudować initrd na żywca do kernela, wtedy chyba można użyć PLDowego initrd bez żadnych modyfikacji... Ale nie dam głowy, na initrd się nie znam :) Natomiast ja zrobiłem tak: 1. własny kernel, skompilowany vaniliowy 2.6.16 z nałożonymi fbsplash i vesa-tng, ew. z wkompilowanym splashem do kernela, Cięciwa mówi, że w naszym jajku vesa-tng nie ma. Ja odpalam na standardowym vesafb, na radeonfb jeszcze mi się nie udało. Ja użyłem vesa-tng w ramach poszukiwania przyczyny problemów. Teraz zostało, bo mogę sobie ustawić przy kompilacji kernela defaultowe odświeżanie i głębię kolorów. Poza tym odnoszę wrażenie że działa bez porównania szybciej od zwykłego framebuffera - na starym FB otwarcie pliku lessem i przewijanie w te i wewte było bardzo uciążliwe, na vesafb-tng działa całkiem przyzwoicie. 2. Zmiana w skryptach startowych - zamiana S98fbsplash na S01fbsplash: przecież chodzi o to, żeby ten splash się pojawiał jak najwcześniej... Hm, to mi wygląda, jakbyś nie odpalał splasha podczas bootowania kernela, ale dopiero jak ruszą rc-skrypty? Masz splash silent zanim pojawi się Powered by PLD Linux Distribution ? Zaraz w momencie, gdy normlanie pokazuje się pingwinek przy inicjalizacji fb? Ja odnoszę wrażenie, że odpalasz to w userspace, a nie w kernel jak powinno być. Pojawia mi się jeden komunikat z ACPI, a potem mryg i już jest tylko splash. Przerzuciłem S98 na S01 wtedy, gdy nie mogłem sobie poradzić z initrd i stwierdziłem że niech chociaż ten splash się pojawia nieco wcześniej... Sprawdzę jak dokładnie to wygląda - przerzucę S01fbsplash na S98fbsplash. Ale to dopiero jak wrócę do domu, bo tam laptok grzecznie czeka ;) Pozdrawiam, -- Jacek Osiecki [EMAIL PROTECTED] GG:3828944 Poglądy polityczne mają takie znaczenie w sejmie jak upierzenie u krokodyla (c) Tomasz Olbratowski 2004___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: SPECS: k3b.spec - added BR: growisofs = 5.10 - added BR: dvd+rw-t...
On Sunday 02 April 2006 23:47, Arkadiusz Patyk wrote:
wywala
[...]
To może zrobić paczkę bez plików, a zawierająca odpowiednie R: do dvd?
pozdrawiam
--
Łukasz Głębicki mail/rot13:[EMAIL PROTECTED] PLD/Linux Team
gg:246267Linux Registered User #318551 blekot:{irc,skype}
Student of Warsaw University of Technology, Faculty of Mechatronics
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: splashutils 1.1.9.10
Dnia Mon, 03 Apr 2006 12:07:34 +0300, Jacek Osiecki [EMAIL PROTECTED] napisał: Aha - tu mamy małe nieporozumienie :) Ja nie używam initrd, tzn. używam obecnie - tylko i wyłącznie do fbsplasha. To teraz jestem skołowany. Czyli - masz na stałe wszystkie sterowniki wkompilowane w jajo, a w initrd masz *tylko i wyłacznie* bitmapę i helpera z fbsplasha? Ale w initrd, czy w initramfs? Bo mi sie wydaje, że strzeliłeś splsh_geninitramfs i podpinasz to jako parametr initrd=/boot/costam przy bootowaniu jajka - tak ? Ale nie dam głowy, na initrd się nie znam :) No tak właśnie się obawiam i dlatego nie możemy się dogadać :D Ja użyłem vesa-tng w ramach poszukiwania przyczyny problemów. Teraz zostało, bo mogę sobie ustawić przy kompilacji kernela defaultowe odświeżanie i głębię kolorów. Poza tym odnoszę wrażenie że działa bez porównania szybciej od zwykłego framebuffera - na starym FB otwarcie pliku lessem i przewijanie w te i wewte było bardzo uciążliwe, na vesafb-tng działa całkiem przyzwoicie. Hm - oblookam to i może wrzucę łatę na naszego kernela, jak Bóg i cięciwa pozwolą. Pojawia mi się jeden komunikat z ACPI, a potem mryg i już jest tylko splash. No! Czyli odpalasz fbsplasha już na poziomie kernela zaraz przy starcie. Teraz kwestia kluczowa. Czytaj uważnie i nie pomyl terminologii :D Uwaga: Jeżeli dobrze zrozumiałem powyższą uwagę, to masz wzsystkie potrzebne sterowniki wkompilowane w jądro i nie potrzebujesz żadnych initrd/initramfs żeby sytem wystartował? Tak? Teraz tworzysz sobie obraz, z tapetami i z /sbin/splash_helper i podajesz jako parametr initrd=/boot/obraz, czy gdzie tam ten obraz zrobiłeś, i wtedy masz splasha przy starcie. Moim zdaniem, jeżeli Tobie pojawia się splash po *jednym* czy bardzo niewielu komunikatach, to jest to *initramfs*, który podawany jest tym samym parametrem, ale jest innego formatu i jest montowany *wcześniej*, znacznie wcześniej, więc możliwe, że widzisz jeden lub bardzo mało komunikatów, zanim ząłączy się tapeta splasha. *Initrd* załącza się ciut później, bo salwie komunikatów z plusem '+' na początku, w większości insmod, co jest charakterystycznie i jeżeli byś ruszał fbsplasha z initrd, to właśnie wtedy powinien się załączyć, czyli chwilę później i sporo komunikatów dalej, niż *initramfs*. Sposób, żeby to sprawdzić, jest prosty. Obraz initrd jesteś w stanie zamontować, a initramfs trzeba wypakować. *Initrd* Jeżeli masz obraz spakowany (w razie potrzeby daj rozszrezenie gz), to trzeba go najpierw rozpakować (a geninitd domyślnie pakuje), a potem zamontować: mkdir -p /tmp/initrd mount -o loop /boot/obraz_rozpakowany /tmp/initrd Jeżeli się nie powiedzie, znaczy, że masz initramfs Więc kluczowe pytanie jest, czy to tak na prawdę jest initrd, czy initramfs i ja się skłaniam ku temu drugiemu, bo w taki sposób udało mi się fbsplasha bez problemu uruchomić (wszystkie potrzebne moduły satycznie wlinkowane i initramfs z tapetą i helperem, wygenreowany przez splash_geninitramfs i wywołany przez parametr initrd=/boot/fbslash.cpio.gz) Przerzuciłem S98 na S01 wtedy, gdy nie mogłem sobie poradzić z initrd i stwierdziłem że niech chociaż ten splash się pojawia nieco wcześniej... Tutaj nie do końca rozumiem, o co loto, ale podjerzewam, że chodzi o magiczny numerek w kolejności odpalania SysV? Splash potem jest nieważny i jes userspace i da się go odpalić, nawet bez łatek na jajo. Więc to tam jest drobiazg. Ważne jest, żeby dało się jakoś na defautlowym jaju PLD odpalić splashe. [EMAIL PROTECTED] P.S. Sry za toporność, szczególnie części z initrd/initramfs, ale to jest *kluczowe* dla rozwikłania tej zagadki :D -- Fear leads to anger, anger leads to hate, hate leads to suffering Yoda ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: splashutils 1.1.9.10
On Mon, 3 Apr 2006, [EMAIL PROTECTED] wrote: Dnia Mon, 03 Apr 2006 12:07:34 +0300, Jacek Osiecki [EMAIL PROTECTED] napisał: Aha - tu mamy małe nieporozumienie :) Ja nie używam initrd, tzn. używam obecnie - tylko i wyłącznie do fbsplasha. To teraz jestem skołowany. Czyli - masz na stałe wszystkie sterowniki wkompilowane w jajo, Wszystkie sterowniki, które są niezbędne do wystartowania filesystemu z dysku - czyli filesystem dla / oraz sterownik IDE/SCSI/SATA. a w initrd masz *tylko i wyłacznie* bitmapę i helpera z fbsplasha? Tak. Ale w initrd, czy w initramfs? Bo mi sie wydaje, że strzeliłeś splsh_geninitramfs i podpinasz to jako parametr initrd=/boot/costam przy bootowaniu jajka - tak ? O, o - właśnie to :) No widzisz, ja nawet nie rozróżniam initrd od initramfs :) No question I don't use initrd Ale nie dam głowy, na initrd się nie znam :) No tak właśnie się obawiam i dlatego nie możemy się dogadać :D Figures... :) Pojawia mi się jeden komunikat z ACPI, a potem mryg i już jest tylko splash. No! Czyli odpalasz fbsplasha już na poziomie kernela zaraz przy starcie. Bingo :) Teraz kwestia kluczowa. Czytaj uważnie i nie pomyl terminologii :D Uwaga: Jeżeli dobrze zrozumiałem powyższą uwagę, to masz wzsystkie potrzebne sterowniki wkompilowane w jądro i nie potrzebujesz żadnych initrd/initramfs żeby sytem wystartował? Tak? Dokładnie. W modułach są tylko zabawki, typu dźwięk, drm, inne filesystemy niż /. Teraz tworzysz sobie obraz, z tapetami i z /sbin/splash_helper i podajesz jako parametr initrd=/boot/obraz, czy gdzie tam ten obraz zrobiłeś, i wtedy masz splasha przy starcie. Tak. Moim zdaniem, jeżeli Tobie pojawia się splash po *jednym* czy bardzo niewielu komunikatach, to jest to *initramfs*, który podawany jest tym samym parametrem, ale jest innego formatu i jest montowany *wcześniej*, znacznie wcześniej, więc możliwe, że widzisz jeden lub bardzo mało komunikatów, zanim ząłączy się tapeta splasha. Ano właśnie. Więc kluczowe pytanie jest, czy to tak na prawdę jest initrd, czy initramfs i ja się skłaniam ku temu drugiemu, bo w taki sposób udało mi się fbsplasha bez problemu uruchomić (wszystkie potrzebne moduły satycznie wlinkowane i initramfs z tapetą i helperem, wygenreowany przez splash_geninitramfs i wywołany przez parametr initrd=/boot/fbslash.cpio.gz) Tak. Natomiast co istotne, można sobie wrzucić initramfs bezpośrednio do kernela - i wtedy nie będzie problemu z tym że w initrd potrzebne są inne rzeczy. Za 2h będę w domu, to sprawdzę czy na pewno mi się pojawi splash bez initrd=/boot/splash_initramfs - i dam znać. Pozdrawiam, -- Jacek Osiecki [EMAIL PROTECTED] GG:3828944 Poglądy polityczne mają takie znaczenie w sejmie jak upierzenie u krokodyla (c) Tomasz Olbratowski 2004___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: splashutils 1.1.9.10
Dnia Mon, 03 Apr 2006 17:17:40 +0300, Jacek Osiecki [EMAIL PROTECTED] napisał: O, o - właśnie to :) No widzisz, ja nawet nie rozróżniam initrd od initramfs :) No question I don't use initrd Aaaarrrggghhh - aleś zamiesznaia narobił chopie :D Ja tu cięciwie truje cztery litery, a tu wychodzi, że nie ma o co...no łe - no to tak to ja też potrafię ;p Natomiast co istotne, można sobie wrzucić initramfs bezpośrednio do kernela - i wtedy nie będzie problemu z tym że w initrd potrzebne są inne rzeczy. Za 2h będę w domu, to sprawdzę czy na pewno mi się pojawi splash bez initrd=/boot/splash_initramfs - i dam znać. Nie testowałem, ale IMHO powinno ruszyć bez parametru initrd, jeżeli masz wkompilowane w kernel. Natomiast pojawiają się problemy ze zrobieniem tego 'the right' way. Bo z jednej strony można by wkompilowywać przy budowaniu PLD-owego jajka jakiegoś fbsplasha na stałe, ale: 1. bez możliwości konfiguracji, czyli ustalmy jeden, PLD-owy fbsplash i on jest na stałe w jajku 2. nie jestem przekonany, czy initramfs + initrd da się naraz uruchomić (czyli najpierw initramfs tylko do fbsplasha, a potem initrd do reeszty) 3. musielibyśmy uruchamiać system zawsze z vesafb, a to jest evil(TM) Ad2. Let me rephraze that - w zasadzie jestem przekonany, że tego się nie da zrobić, bo initramfs spełnia rolę initrd, więc nie sądze, żeby dało się najpierw 'oszukać' jajko, że mamy wkompilwany obraz initramfs, a za chwilę wołać moduły z initrd. W zasadzie EOT w tym miejscu i jesteśmy back to square one. [EMAIL PROTECTED] -- Fear leads to anger, anger leads to hate, hate leads to suffering Yoda ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Ruby-gnome2 i pango
On 4/3/06, Tomasz Wittner [EMAIL PROTECTED] wrote: Oba się budują, gnome-art się uruchamia i coś tam działa. Mam nadzieję, że sobie teraz poradzisz. Ja sobie poradziłam jeszcze zanim napisałam na tą listę. Zgłosiłam konkretne miejsce gdzie coś jest nie tak na FTP. Czy ktoś coś z tym zrobi czy nie (skoro spec jest ok, to może puści zlecenia przebudowania pakietu na FTP?) mnie już nie robi różnicy. -- Pozdrawiam, Liliana Write your code as if the person maintaining it is a homicidal maniac who knows where you live. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: splashutils 1.1.9.10
On Mon, 3 Apr 2006, [EMAIL PROTECTED] wrote: Dnia Mon, 03 Apr 2006 17:17:40 +0300, Jacek Osiecki [EMAIL PROTECTED] napisał: O, o - właśnie to :) No widzisz, ja nawet nie rozróżniam initrd od initramfs :) No question I don't use initrd Aaaarrrggghhh - aleś zamiesznaia narobił chopie :D Ja tu cięciwie truje cztery litery, a tu wychodzi, że nie ma o co...no łe - no to tak to ja też potrafię ;p No widzisz, tylko że u mnie dopiero przy splashutils 1.1.9.10 ruszyło - wcześniej dostawałem kernel panic... W każdym razie sorry za zamieszanie :( - i wtedy nie będzie problemu z tym że w initrd potrzebne są inne rzeczy. Za 2h będę w domu, to sprawdzę czy na pewno mi się pojawi splash bez initrd=/boot/splash_initramfs - i dam znać. Nie testowałem, ale IMHO powinno ruszyć bez parametru initrd, jeżeli masz wkompilowane w kernel. I jakoś nie do końca ruszyło... Ale już chyba nie mam sił więcej próbować :-/ Natomiast pojawiają się problemy ze zrobieniem tego 'the right' way. Bo z jednej strony można by wkompilowywać przy budowaniu PLD-owego jajka jakiegoś fbsplasha na stałe, ale: 1. bez możliwości konfiguracji, czyli ustalmy jeden, PLD-owy fbsplash i on jest na stałe w jajku 2. nie jestem przekonany, czy initramfs + initrd da się naraz uruchomić (czyli najpierw initramfs tylko do fbsplasha, a potem initrd do reeszty) 3. musielibyśmy uruchamiać system zawsze z vesafb, a to jest evil(TM) No tak - biorąc to wszystko pod uwagę to szanse na fbsplash firmowo w PLD są raczej nikłe. Co nie zmienia faktu, że zdecydowanie trzeba podnieść splashutils do tej wersji którą podrzuciłem - bo jak ktoś będzie chciał sobie użyć fbsplasha to obecne narzędzia tylko go doprowadzą do rozpaczy (tak jak mnie ;) Pozdrawiam, -- Jacek Osiecki [EMAIL PROTECTED] GG:3828944 Poglądy polityczne mają takie znaczenie w sejmie jak upierzenie u krokodyla (c) Tomasz Olbratowski 2004___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: SPECS: k3b.spec - added BR: growisofs = 5.10 - added BR: dvd+rw-t...
Dnia 02-04-2006, nie o godzinie 23:10 +0200, Sławomir Paszkiewicz napisał(a): Cytowanie Arkadiusz Patyk [EMAIL PROTECTED]: On Sun, 02 Apr 2006 21:37:26 +0300, you wrote: Dnia Sun, 02 Apr 2006 22:32:29 +0300, Arkadiusz Patyk [EMAIL PROTECTED] napisał: a ja nie mam nagrywarki DVD tylko CDR i po co mi te programy w systemie z k3b? Paczki w PLD budowane są z najszerszą funkcjonalnością, jaka jest możliwa, a potem w miarę możliwości dzielone na podpaczki. Jak nie chcesz mieć tego w systemie, to zbuduj sobie z odpowiednimi przełacznikami. [...] Ale dodanie tego R do budowania nie powoduje, że się zmienia funkcjonalność k3b. Ja mam k3b budowane bez tego R a mogę nagrywać DVD. Jak ktoś ma k3b i problemy z nagrywaniem DVD w k3b to może: 1. wpisać w google: k3b nagrywanie dvd 2. zobaczyć w opcjach k3b - programy, że są jakieś niewykryte programy i moze je uzupełnić. Zgoda na dodanie tego R żeby instalowany k3b miał większą funkcjonalność IMO pociągała by za sobą (jako logiczne następstwa takiego myślenia) dodanie do np. apacha R na wszystkie jego moduły, żeby miał najszerszą funkcjonalność... BPMSPANC -- Pozdrawiam Krystian T errare humanum est... ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
buildlogs.pld-linux.org: Fatal error: Maximum execution time of 30 seconds
Kiedyś dawało się znaleźć ca co drugiego interesującego buildloga (część gdzieś ginęła - akurat ta część, której najbardziej potrzebowałem) - teraz, jedyne co udaje mi się znaleźć, to Fatal error: Maximum execution time of 30 seconds exceeded in /home/services/httpd/html/pld-buildlogs/index.php on line 820 -- Tomasz Wittner ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: splashutils 1.1.9.10
On Monday 03 April 2006 09:19, Jacek Osiecki wrote:
[...]
Dodałem patcha do repo, dzieki. Aktualnie czeka mnie boot i sprawdzenie
fbsplasha z kernelem-preempt-2.6.16.1 z vesafb-tng.
Nie zmienialem initrd, splash sie odpali jako pierwszy z rc-scripts.
pozdrawiam
--
Łukasz Głębicki mail/rot13:[EMAIL PROTECTED] PLD/Linux Team
gg:246267Linux Registered User #318551 blekot:{irc,skype}
Student of Warsaw University of Technology, Faculty of Mechatronics
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: budowanie btsco.spec - wywala sie
Dnia wtorek, 4 kwietnia 2006 00:19, Michał Panasiewicz napisał:
make: Entering directory `/usr/src/linux-2.6.14.7'
make: Leaving directory `/usr/src/linux-2.6.14.7'
+ /usr/bin/make -C /usr/src/linux modules CC=athlon-pld-linux-gcc
CPP=athlon-pld-linux-gcc -E M=/home/users/adi/rpm/BUILD/btsco-0.4/kernel
O=/home/users/adi/rpm/BUILD/btsco-0.4/kernel
make: Entering directory `/usr/src/linux-2.6.14.7'
CC [M] /home/users/adi/rpm/BUILD/btsco-0.4/kernel/btsco.o
/bin/sh: scripts/basic/fixdep: not found
make[2]: *** [/home/users/adi/rpm/BUILD/btsco-0.4/kernel/btsco.o] Error
127
make[1]: *** [_module_/home/users/adi/rpm/BUILD/btsco-0.4/kernel] Error
2
make: *** [modules] Error 2
make: Leaving directory `/usr/src/linux-2.6.14.7'
błąd: Błędny status wyjścia z /var/tmp/rpm-tmp.67477 (%build)
Patch z załącznika powinien załatwić sprawę.
--
Łukasz Maśko GG: 2441498_o)
Lukasz.Masko(at)ipipan.waw.pl ICQ: 146553537/\\
Registered Linux User #61028 JID: [EMAIL PROTECTED] _\_V
Index: btsco.spec
===
RCS file: /cvsroot/SPECS/btsco.spec,v
retrieving revision 1.3
diff -u -r1.3 btsco.spec
--- btsco.spec 3 Dec 2005 10:39:19 - 1.3
+++ btsco.spec 3 Apr 2006 22:31:09 -
@@ -102,23 +102,32 @@
if [ ! -r %{_kernelsrcdir}/config-$cfg ]; then
exit 1
fi
- rm -rf include
- install -d include/{linux,config}
- ln -sf %{_kernelsrcdir}/config-$cfg .config
- ln -sf %{_kernelsrcdir}/include/linux/autoconf-$cfg.h include/linux/autoconf.h
- ln -sf %{_kernelsrcdir}/include/asm-%{_target_base_arch} include/asm
- ln -sf %{_kernelsrcdir}/Module.symvers-$cfg Module.symvers
- touch include/config/MARKER
+ install -d o/include/linux
+ ln -sf %{_kernelsrcdir}/config-$cfg o/.config
+ ln -sf %{_kernelsrcdir}/Module.symvers-$cfg o/Module.symvers
+ ln -sf %{_kernelsrcdir}/include/linux/autoconf-$cfg.h o/include/linux/autoconf.h
+%if %{with dist_kernel}
+ %{__make} -C %{_kernelsrcdir} O=$PWD/o prepare scripts
+%else
+ install -d o/include/config
+ touch o/include/config/MARKER
+ ln -sf %{_kernelsrcdir}/scripts o/scripts
+%endif
# patching/creating makefile(s) (optional)
%{__make} -C %{_kernelsrcdir} clean \
RCS_FIND_IGNORE=-name '*.ko' -o \
- M=$PWD O=$PWD \
+ SYSSRC=%{_kernelsrcdir} \
+ SYSOUT=$PWD/o \
+ M=$PWD O=$PWD/o \
%{?with_verbose:V=1}
%{__make} -C %{_kernelsrcdir} modules \
CC=%{__cc} CPP=%{__cpp} \
- M=$PWD O=$PWD \
+ SYSSRC=%{_kernelsrcdir} \
+ SYSOUT=$PWD/o \
+ M=$PWD O=$PWD/o \
%{?with_verbose:V=1}
+
for mod in *.ko; do
mod=$(echo $mod | sed -e 's#\.ko##g')
mv $mod.ko ../$mod-$cfg.ko
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
anoncvs ;)
Testowo zostal udostepniony anoncvs. Więc - w razie padu cvsa, a także do anonimowego korzystania - powinno wsio działać ;) adres: :pserver:[EMAIL PROTECTED]:/cvsroot synchronizuje się z opóźnieniem, wiec najaktualniejsze zmiany mogą nie byc dostępne, ale.. pracujemy nad tym ;) -- Andrzej 'The Undefined' Dopierała UNIX Linux administrator, Adam Mickiewicz University WMiI PLD Linux Developer HomePage: http://andrzej.dopierala.name/ JID: [EMAIL PROTECTED] e-mail: [EMAIL PROTECTED] ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
AC: branching - update
Under http://ep09.pld-linux.org/~arekm/ac-branch.txt there is a list of packages which will be branched from specified revision from HEAD (branching will be done by date). The list prepared by arekm is no longer valid because some newer packages were moved to main. Also there is no actual list ATM because some packages will be moved to main in next few days. If nothing bad will happen branching will be done this weekend (april 8-9th) based on contents of main Ac tree. Branching will not be done by date as arekm wrote but by auto-ac tags from which packages in main were built. Please do not send anything to ready tree after april 6th. Also do not move any packages from ready to main after this point. Some specs already have AC-branch - these will not be touched. Thats still true. Some will be deleted on HEAD (these which are obsolete in Th like X11.spec). I'm not thinking about this right now. Anyone want to help with this when branching will be finished? AC builders (ac-ready) will be blocked to allow AC-branch builds only. Thats still true. M. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
