Request for developers + info for mirror admins
Hello. EN: Since Ac has reached stable state we now need to maintain it for some time. That means we need... ok, I need more than 5+ people working on AC-branch. Unfortunately I'll not pay you for your work :( To make maintaining a bit easier UTF specs will be allowed on AC-branch and in updates tree (go and thanks blues for that if you want). However please do not use UTF on AC-branch yet. Wait for iso images arrival (next week). If you are doing some updates on HEAD, please do them on AC-branch too (and vice versa). You'll make Ac live a bit longer :) Now about Ac 2.1. Yes, there will be one (I hope) and it would be nice to release it ASAP. Therefore I'm looking for people who will agree to prepare following things for Ac 2.1: - backport of modular xorg 7.2 - Gnome 2.18 - beryl/compiz - GCC 4.1.x - kernel 2.6.21 + related stuff like netfilter - newer glibc (a big question here because it will be death sentence for i386, I didn't decided yet if that will happen) - any other newest hottest stuff you would like to see in Ac, but stable releases only Things above will need new branch (AC-devel?) and also new builders. So if you can run Ac 2.1 builder, let me know. They're not needed yet, but they will be needed in the future. First thing that should be accomplished is GCC 4.1.x. Now promised info for ftp mirror admins. All packages in Ac main tree will be signed. That means that whole contents of Ac will be retransfered to all mirrors. Signing should be done in next few days. PL: Poniewaz Ac jest juz oficjalnie stabilne musimy go przez jakis czas utrzymywac. Potrzeba do tego... dobra, ja potrzebuje aby na AC-branch pracowalo wiecej niz 5+ osob. Niestety nie bede w stanie placic tym, ktorzy zechca pracowac nad Ac. Aby troszke ulatwic zycie spece w UTF beda dozwolone na AC-branch i w drzewku updates (kto chce, moze za to podziekowac bluesowi). Prosze jednak nie konwertowac jeszcze calego AC-branch na UTF. Poczekajmy az iso trafia na ftp. Jezeli robisz jakis update na HEAD, prosze, zrob go tez na AC-branch (i vice versa). Dzieki temu Ac pozyje chwilke dluzej. A teraz o Ac 2.1. Tak, bedzie taka wersja (mam nadzieje) i bylo by milo aby wyszla ona najszybciej jak to mozliwe. Dlatego tez poszukuje osob, ktore zgodza sie przygotowac nastepujace rzeczy dla Ac 2.1: - backport modularnego xorg 7.2 - Gnome 2.18 - beryl/compiz - GCC 4.1.x - kernel 2.6.21 i okolice (netfilter) - nowsze glibc (tutaj wielki znak zapytania bo bedzie to oznaczac kasacje architektury i386, jeszcze nie zdecydowalem czy to nastapi) - inne nowiutkie, swiezutkie oprogramowanie, ktore chcial bys miec w Ac, tylko stabilne wersje Powyzsze rzeczy beda wymagaly nowego brancha (AC-devel?) jak i nowych builderow. Dlatego tez jezeli masz sprzet, ktory moglby pracowac za builder dla Ac 2.1, daj znac. Nie sa potrzebne od zaraz, ale w przyszlosci beda. Pierwsza rzecza jaka powinna zostac przygotowana jest GCC 4.1.x. A teraz obiecano info dla administratorow mirrorow. Wszystkie paczki w glownym drzewku Ac zostana podpisane. To oznacza, ze cala zawartosc Ac zostanie ponownie przetranferowana na wszystkie mirrory. Podpisywanie pakietow bedzie mialo miejsce w najlblizszych dniach. M. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SOURCES: rpm-macros.java - do not use internal dependency generator
On Wed, Apr 04, 2007 at 01:02:45PM +0200, glen wrote: Author: glen Date: Wed Apr 4 11:02:45 2007 GMT Module: SOURCES Tag: HEAD Log message: - do not use internal dependency generator +# rpm itself doesn't recognize .jar and .class +%define _use_internal_dependency_generator 0 So it cannot be used on any package containing ELF files. External generators cannot properly mark file colours. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SOURCES: rpm-macros.java - do not use internal dependency generator
On Apr 10, 2007, at 2:38 PM, Jakub Bogusz wrote: On Wed, Apr 04, 2007 at 01:02:45PM +0200, glen wrote: Author: glen Date: Wed Apr 4 11:02:45 2007 GMT Module: SOURCES Tag: HEAD Log message: - do not use internal dependency generator +# rpm itself doesn't recognize .jar and .class +%define _use_internal_dependency_generator 0 So it cannot be used on any package containing ELF files. External generators cannot properly mark file colours. Correct. AFAIK, rpm-4.4.8 classifies (by suffix, not perfect) .jar and .class files: Here's lib/rpmfc.c code: ... /* XXX all files with extension .jar are java archives for now. */ else if (_suffix(s, .jar)) ftype = Java archive file; /* XXX all files with extension .class are java class files for now. */ else if (_suffix(s, .class)) ftype = Java class file; 73 de Jeff ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SOURCES: rpm-macros.java - do not use internal dependency generator
On Tuesday 10 April 2007, Jeff Johnson wrote:
On Apr 10, 2007, at 2:38 PM, Jakub Bogusz wrote:
On Wed, Apr 04, 2007 at 01:02:45PM +0200, glen wrote:
Author: glen Date: Wed Apr 4 11:02:45
2007 GMT
Module: SOURCES Tag: HEAD
Log message:
- do not use internal dependency generator
+# rpm itself doesn't recognize .jar and .class
+%define _use_internal_dependency_generator 0
So it cannot be used on any package containing ELF files.
External generators cannot properly mark file colours.
yes. that was just there to get it started ;)
Correct.
AFAIK, rpm-4.4.8 classifies (by suffix, not perfect) .jar and .class
appears that (at least rpm 4.4.2) calls rpmfcSCRIPT for each file.
could rpmbuild invoke the requires/provider script only once passing (in STDIN)
all the file from the same class.
it could speedup the packaging stage. for example script for pythondeps is able
to cache $PYVER:
$ time rpmbuild --short-circuit --define '_source_payload w9.gzdio' -bb
--define 'clean %{nil}' smart.spec
[...]
real0m13.337s
user0m5.130s
sys 0m2.790s
and after changing just to PYVER=2.4:
$ time rpmbuild --short-circuit --define '_source_payload w9.gzdio' -bb
--define 'clean %{nil}' smart.spec
real0m7.877s
user0m1.750s
sys 0m0.670s
--
glen
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SOURCES: rpm-macros.java - do not use internal dependency generator
On Apr 10, 2007, at 5:22 PM, Elan Ruusamäe wrote:
On Tuesday 10 April 2007, Jeff Johnson wrote:
On Apr 10, 2007, at 2:38 PM, Jakub Bogusz wrote:
On Wed, Apr 04, 2007 at 01:02:45PM +0200, glen wrote:
Author: glen Date: Wed Apr 4 11:02:45
2007 GMT
Module: SOURCES Tag: HEAD
Log message:
- do not use internal dependency generator
+# rpm itself doesn't recognize .jar and .class
+%define _use_internal_dependency_generator 0
So it cannot be used on any package containing ELF files.
External generators cannot properly mark file colours.
yes. that was just there to get it started ;)
Correct.
AFAIK, rpm-4.4.8 classifies (by suffix, not perfect) .jar and .class
appears that (at least rpm 4.4.2) calls rpmfcSCRIPT for each file.
could rpmbuild invoke the requires/provider script only once
passing (in STDIN) all the file from the same class.
it could speedup the packaging stage. for example script for
pythondeps is able to cache $PYVER:
$ time rpmbuild --short-circuit --define '_source_payload w9.gzdio'
-bb --define 'clean %{nil}' smart.spec
[...]
real0m13.337s
user0m5.130s
sys 0m2.790s
and after changing just to PYVER=2.4:
$ time rpmbuild --short-circuit --define '_source_payload w9.gzdio'
-bb --define 'clean %{nil}' smart.spec
real0m7.877s
user0m1.750s
sys 0m0.670s
Yep. Major reworking would need to be done to batch entries however.
What needs to be established first is the reliability and usefulness
of per-interpreter dependency
extraction. There's hardly a need to speed up extraction for seldom
used unreliable functionality.
73 de Jeff
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
