[opensuse-factory] Dist Meeting 2006-09-14: Proposed Agenda
Here're the current agenda items. Any comments? Anything you like us to look at? * Java for Distribution building We're currently building java-1_4_2-sun and the suggestion was to switch to java-1_5_0-sun. * Building distribution for i386/x86-64 with -mtune=generic -mtune=generic is the default in the compiler. If someone uses -march=abc and no -mtune then the tune setting will be based on -march, and perhaps overriding the mtune=generic. -mtune=i686 is equivalent to -mtune=generic. Sooo, for x86-64 we should be fine (simply don't add anything), for i586 we might want to add an explicit -mtune=generic. * umask ("hard coded value in /etc/profile vs. pam_umask.so", see also "man pam_umask") Questions - Remove value from /etc/profile and store in a config file: - Use /etc/login.defs not only for creation of home directory, but also for login - Use pam_umask.so or use .profile parser solution? - Should YaST2 allow/provide umask value per user or only global? User is able to set a value with chfn -m umask=XXX Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Le mercredi 13 septembre 2006 09:52, Andreas Jaeger a écrit :
Here're the current agenda items. Any comments? Anything you like us to look at?
* Java for Distribution building
We're currently building java-1_4_2-sun and the suggestion was to switch to java-1_5_0-sun.
* Building distribution for i386/x86-64 with -mtune=generic
-mtune=generic is the default in the compiler. If someone uses -march=abc and no -mtune then the tune setting will be based on -march, and perhaps overriding the mtune=generic. -mtune=i686 is equivalent to -mtune=generic. Sooo, for x86-64 we should be fine (simply don't add anything), for i586 we might want to add an explicit -mtune=generic.
i use suse 64bits since a couple of release and one thing i notice it's slower than the 32 bits and slower than other 64 bits distribution (fedora and mandrake) don't know if you use tuning option when you build...
* umask ("hard coded value in /etc/profile vs. pam_umask.so", see also "man pam_umask") Questions - Remove value from /etc/profile and store in a config file: - Use /etc/login.defs not only for creation of home directory, but also for login - Use pam_umask.so or use .profile parser solution? - Should YaST2 allow/provide umask value per user or only global? User is able to set a value with chfn -m umask=XXX
Andreas
To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Wed, Sep 13, 2006 at 09:59:44AM -0400, Marc Collin wrote:
i use suse 64bits since a couple of release and one thing i notice it's slower than the 32 bits and slower than other 64 bits distribution (fedora and mandrake)
Slower in doing exactly what? Robert -- Robert Schiele Dipl.-Wirtsch.informatiker mailto:rschiele@gmail.com "Quidquid latine dictum sit, altum sonatur."
Marc Collin <collinm@laboiteaprog.com> writes:
i use suse 64bits since a couple of release and one thing i notice it's slower than the 32 bits and slower than other 64 bits distribution (fedora and mandrake)
don't know if you use tuning option when you build...
We do build with -O2. Such a speed difference is interesting and I would be interested in the cause, Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Le mercredi 13 septembre 2006 11:04, Andreas Jaeger a écrit :
Marc Collin <collinm@laboiteaprog.com> writes:
i use suse 64bits since a couple of release and one thing i notice it's slower than the 32 bits and slower than other 64 bits distribution (fedora and mandrake)
don't know if you use tuning option when you build...
We do build with -O2. Such a speed difference is interesting and I would be interested in the cause,
Andreas
minimum to be done: -march=x86-64 i think x86 64 bits have minimum sse2 -mfpmath=sse2 -msse2 -funroll-all-loops -fomit-frame-pointer -ffast-math could be nice if more optimization can be done --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Am Mittwoch, 13. September 2006 20:57 schrieb Marc Collin:
minimum to be done: -march=x86-64
i think x86 64 bits have minimum sse2
-mfpmath=sse2
-msse2 -funroll-all-loops Make sure you read http://funroll-loops.org/ - what exactly do you measure?
Greetings, Stephan --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Le mercredi 13 septembre 2006 15:59, Stephan Kulow a écrit :
Am Mittwoch, 13. September 2006 20:57 schrieb Marc Collin:
minimum to be done: -march=x86-64
i think x86 64 bits have minimum sse2
-mfpmath=sse2
-msse2 -funroll-all-loops
Make sure you read http://funroll-loops.org/ - what exactly do you measure?
time to start, time to run function..... when i created some program in C for a company i used often something similar to.... g++ -O2 -funroll-all-loops -fomit-frame-pointer -ffast-math -march=x86-64 -mfpmath=sse program_name.cpp -o program_name i get about 10% faster then the standard syntax.... without change my code..... --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Marc Collin wrote:
Le mercredi 13 septembre 2006 15:59, Stephan Kulow a écrit :
Am Mittwoch, 13. September 2006 20:57 schrieb Marc Collin:
-funroll-all-loops
Make sure you read http://funroll-loops.org/ - what exactly do you measure?
time to start, time to run function.....
when i created some program in C for a company i used often something similar to....
g++ -O2 -funroll-all-loops -fomit-frame-pointer -ffast-math -march=x86-64 -mfpmath=sse program_name.cpp -o program_name
i get about 10% faster then the standard syntax....
I have run benchmarks which suggest -funroll-all-loops makes things up to 10% SLOWER. Read that again. SLOWER. gcc man page says: -funroll-all-loops Unroll all loops, even if their number of iterations is uncertain when the loop is entered. This usually makes programs run more slowly. -funroll-all-loops implies the same options as -fun- roll-loops, It all depends on the code and the gcc version. And we do not want to go down this road to optimization madness. If you really want to optimize code, make sure it is using efficient algorithms. Regards, Carl-Daniel --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Wed, Sep 13, 2006 at 04:46:30PM -0400, Marc Collin wrote:
time to start, time to run function.....
when i created some program in C for a company i used often something similar to....
g++ -O2 -funroll-all-loops -fomit-frame-pointer -ffast-math -march=x86-64 -mfpmath=sse program_name.cpp -o program_name
i get about 10% faster then the standard syntax....
Compared to what? Measured on what sort of algorithms? I'l try to explain why your suggestion does not really make sense: - -funroll-all-loops unrolls even loops where performance gains are at least questionable. On the other hand loop unrolling can always lead to cache thrashing and thus slowing down code in the average case. - -fomit-frame-pointer is on for -O2 on plattforms where it does not hurt debugging anyways. On the other plattforms it makes debugging practically impossible. - -ffast-math is critical (as mentioned already in another mail) because it makes the compiler violate standards. - -march=x86-64 --- What do you expect from that except cluttering the command line? - -mfpmath=sse is default anyway on x86-64. As a conclusion the only thing that does make sense here is -O2 which is used anyway. As a general rule of thumb: Never use an "optimization" if not _both_ of the following conditions hold true: 1. You know exactly what (side) effects your "optimization" does provide. 2. You can _prove_ by numbers that the "optimization" does provide a _significant_ benefit in a _typical_ use case. Robert -- Robert Schiele Dipl.-Wirtsch.informatiker mailto:rschiele@gmail.com "Quidquid latine dictum sit, altum sonatur."
Hello, Marc Collin schrieb:
-ffast-math
Note that this requires a carefully written program otherwise it may not work reliably. From reading *@gcc.gnu.org and from the manpage ("This option should never be turned on by any -O option since it can result in incorrect output for programs which depend on an exact implementation of IEEE or ISO rules/specifications for math functions.") I think one should be really careful with this option. For my calculations, I don't dare it to use it - better 1% slower and correct than (potentially) 100% wrong and 1% faster.* For non-number crunching programs I would even be more careful. Tobias *In similar regard: Using GCC gfortran compiled Netlib LAPACK [SUSE's lapack.rpm] with the Intel Fortran Compiler (ifort) versus using the Intel Math Kernel Library mit ifort: With one of my programs the speedup was around one percent. [Ok, with one program: ifort compiled is 20% faster than gfortran compiled.] --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Marc Collin <collinm@laboiteaprog.com> writes:
Le mercredi 13 septembre 2006 11:04, Andreas Jaeger a écrit :
Marc Collin <collinm@laboiteaprog.com> writes:
i use suse 64bits since a couple of release and one thing i notice it's slower than the 32 bits and slower than other 64 bits distribution (fedora and mandrake)
don't know if you use tuning option when you build...
We do build with -O2. Such a speed difference is interesting and I would be interested in the cause,
Andreas
minimum to be done: -march=x86-64
This is the default for x86-64 ;-)
i think x86 64 bits have minimum sse2
-mfpmath=sse2
This is written in the ABI, no need to add it.
-msse2
Same here.
-funroll-all-loops
This might be slower in some cases.
-fomit-frame-pointer
This is part of the ABI, no need to do it ;-)
-ffast-math
You will break applications this way. Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Andreas Jaeger schrieb:
* Java for Distribution building
We're currently building java-1_4_2-sun and the suggestion was to switch to java-1_5_0-sun.
java-1_5_0-sun for x86_64 does not include a Mozilla plugin. It will work with Konqueror and Opera because they don't need the Java plugin for Java applet support, but it will not work with Mozilla based browsers. This should not block the switch IMHO, but be prepared for complaints nevertheless. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Andreas Hanke <andreas.hanke@gmx-topmail.de> writes:
Andreas Jaeger schrieb:
* Java for Distribution building
We're currently building java-1_4_2-sun and the suggestion was to switch to java-1_5_0-sun.
java-1_5_0-sun for x86_64 does not include a Mozilla plugin.
It will work with Konqueror and Opera because they don't need the Java plugin for Java applet support, but it will not work with Mozilla based browsers.
This should not block the switch IMHO, but be prepared for complaints nevertheless.
We would still deliver both - the question is which to use for building by default... Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Am Mittwoch, 13. September 2006 17:04 schrieb Andreas Jaeger:
We would still deliver both - the question is which to use for building by default...
If you compile a java program using java 1.4.2 it's running also with java 1.5.0. If you compile it with java 1.5.0 it will not run with java 1.4.2. So what's worth to deliver both, when nothing works with with 1.4.2 when it's build with 1.5.0. For my own, I can't switch to 1.5.0, there are a lot of SAP-servers (AIX and SUSE) at work I have to write Java modules and I also can't switch to 1.5.0 on my knightsoft-net Webserver, it needs to much memory for the small vserver. -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ | http://packman.links2linux.de/ Manfred | http://www.knightsoft-net.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Manfred Tremmel <Manfred.Tremmel@iiv.de> writes:
Am Mittwoch, 13. September 2006 17:04 schrieb Andreas Jaeger:
We would still deliver both - the question is which to use for building by default...
If you compile a java program using java 1.4.2 it's running also with java 1.5.0. If you compile it with java 1.5.0 it will not run with java 1.4.2. So what's worth to deliver both, when nothing works with with
Thanks, didn't know that.
1.4.2 when it's build with 1.5.0.
You could still install both on your system...
For my own, I can't switch to 1.5.0, there are a lot of SAP-servers (AIX and SUSE) at work I have to write Java modules and I also can't switch to 1.5.0 on my knightsoft-net Webserver, it needs to much memory for the small vserver.
Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Le jeudi 14 septembre 2006 04:06, Andreas Jaeger a écrit :
Manfred Tremmel <Manfred.Tremmel@iiv.de> writes:
Am Mittwoch, 13. September 2006 17:04 schrieb Andreas Jaeger:
We would still deliver both - the question is which to use for building by default...
If you compile a java program using java 1.4.2 it's running also with java 1.5.0. If you compile it with java 1.5.0 it will not run with java 1.4.2. So what's worth to deliver both, when nothing works with with
Thanks, didn't know that.
1.4.2 when it's build with 1.5.0.
You could still install both on your system...
For my own, I can't switch to 1.5.0, there are a lot of SAP-servers (AIX and SUSE) at work I have to write Java modules and I also can't switch to 1.5.0 on my knightsoft-net Webserver, it needs to much memory for the small vserver.
Andreas
javac Usage: javac <options> <source files> where possible options include: -source <release> Provide source compatibility with specified release -target <release> Generate class files for specific VM version theses options can be usefull --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Am Donnerstag, 14. September 2006 17:49 schrieb Marc Collin:
javac Usage: javac <options> <source files> where possible options include:
-source <release> Provide source compatibility with specified release -target <release> Generate class files for specific VM version
Ok, when "-target 1.4" is used to build the packages, I don't have anything against building the packages with java 1.5.0. Would be bad not to be able to user jdbc drivers or anything else with gcj or Sun's java 1.4.2. -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ | http://packman.links2linux.de/ Manfred | http://www.knightsoft-net.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Manfred Tremmel wrote:
Am Donnerstag, 14. September 2006 17:49 schrieb Marc Collin:
javac Usage: javac <options> <source files> where possible options include:
-source <release> Provide source compatibility with specified release -target <release> Generate class files for specific VM version
Ok, when "-target 1.4" is used to build the packages, I don't have anything against building the packages with java 1.5.0. Would be bad not to be able to user jdbc drivers or anything else with gcj or Sun's java 1.4.2.
I don't understand what you mean. For your own code, just use -source 1.4 -target 1.4 For third party jars, make sure they support the 1.4.2 JVM. cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <pascal.bleser@skynet.be> <guru@unixtech.be> _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFFCa83r3NMWliFcXcRAsMOAJ9eoL5j/coDgf2CNi/q3H1+kHG+KwCgkq/F n/dcUSQSc2n9wlu7Hu7gYDY= =lsLF -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Am Donnerstag, 14. September 2006 21:36 schrieb Pascal Bleser:
Manfred Tremmel wrote:
Ok, when "-target 1.4" is used to build the packages, I don't have anything against building the packages with java 1.5.0. Would be bad not to be able to user jdbc drivers or anything else with gcj or Sun's java 1.4.2.
I don't understand what you mean.
What I mean is, when SUSE switches to build all the delivered java packages with java 1.5.0 without backwardcompatibility, they will not work with gcj or Sun's java 1.4.2, what (as I've understood) should be allready be part of the next release.
For your own code, just use -source 1.4 -target 1.4
Right, but when SUSE itselve doesn't do this, I will not be able to start a delivered tomcat, Eclipse, with 1.4.2 and all the libs (my /usr/share/java directory is full of jar files which are part of the SUSE distribution) wouldn't be useable with gcj or Sun's java 1.4.2. My hope is to get a *open* java for a *open*SUSE. I don't think Sun's java will be open in near future, it's a process starting with the next version, but will take a while, and maybe the wind changes inbetween. So I hope, gcj + classpath could replace Sun java, so we shouldn't build walls creating with getting incompatible jar-files. -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ | http://packman.links2linux.de/ Manfred | http://www.knightsoft-net.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Manfred Tremmel wrote:
Am Donnerstag, 14. September 2006 21:36 schrieb Pascal Bleser:
Manfred Tremmel wrote:
Ok, when "-target 1.4" is used to build the packages, I don't have anything against building the packages with java 1.5.0. Would be bad not to be able to user jdbc drivers or anything else with gcj or Sun's java 1.4.2. I don't understand what you mean.
What I mean is, when SUSE switches to build all the delivered java packages with java 1.5.0 without backwardcompatibility, they will not work with gcj or Sun's java 1.4.2, what (as I've understood) should be allready be part of the next release.
Oh, right ! Sorry, now I'm in the right context ;) Yes, indeed, that's correct. Generally, the policy is: - - if it uses annotations, generic, autoboxing or other 1.5 features, use 1.5 target (default) - - if it doesn't use a 1.5 feature, use -source 1.4 -target 1.4 That's how it's being done for almost every java OSS project out there. If you don't need JSE 5 features, build in 1.4 compliance mode.
For your own code, just use -source 1.4 -target 1.4
Right, but when SUSE itselve doesn't do this, I will not be able to start a delivered tomcat, Eclipse, with 1.4.2 and all the libs (my /usr/share/java directory is full of jar files which are part of the SUSE distribution) wouldn't be useable with gcj or Sun's java 1.4.2.
Yes, sorry, I missed the point.
My hope is to get a *open* java for a *open*SUSE. I don't think Sun's java will be open in near future, it's a process starting with the next version, but will take a while, and maybe the wind changes inbetween. So I hope, gcj + classpath could replace Sun java, so we shouldn't build walls creating with getting incompatible jar-files.
gcj+classpath can already "replace" a lot of Sun's JVM/JDK if you don't take Swing into account. cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <pascal.bleser@skynet.be> <guru@unixtech.be> _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFFCcz4r3NMWliFcXcRAgFMAJ4yxbFH1QAnUYyuZlkJDvDvto1dwwCgkTT6 7RlnlRk0flMD+WnHArcpkpc= =fw8G -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Am Donnerstag, 14. September 2006 23:43 schrieb Pascal Bleser:
gcj+classpath can already "replace" a lot of Sun's JVM/JDK if you don't take Swing into account.
I know. I've started using gcj + classpath in the 10.0 beta phase, a lot of bugreports I've written concern on this. There are some more problems than only swing, but I was astonished, how far it allready is. -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ | http://packman.links2linux.de/ Manfred | http://www.knightsoft-net.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Thu, Sep 14, 2006 at 11:02:30PM +0200, Manfred Tremmel wrote:
For your own code, just use -source 1.4 -target 1.4
Right, but when SUSE itselve doesn't do this, I will not be able to start a delivered tomcat, Eclipse, with 1.4.2 and all the libs (my /usr/share/java directory is full of jar files which are part of the SUSE distribution) wouldn't be useable with gcj or Sun's java 1.4.2.
If we manage to deliver openSUSE on all relevant platforms with an 1.5 (compatible) java, I actually wouldn't mind that the jars are incompatible with 1.4.2. 1.5 has been around for a while, 1.6 is about to come out, and I don't think we should wait with the move to the admittedly incompatible 1.5 language features until Sun decides to drop support for 1.4.2 altogether. However (big however!) I have also to care about the platforms for which no Sun java exists, so I am sceptical about the switch as well. But the only way to find out what will really break is to start building the stuff with java 1.5 on the platforms where it is available.
My hope is to get a *open* java for a *open*SUSE. I don't think Sun's java will be open in near future, it's a process starting with the next version, but will take a while, and maybe the wind changes inbetween. So I hope, gcj + classpath could replace Sun java, so we shouldn't build walls creating with getting incompatible jar-files.
That's a different can of worms ;-) While Sun java is a black box to us, we can (within tight resource and also knowledge constraints on my part) fix gcj/gij/classpath so that it can deal with 1.5-compiled jars. (I'm actually not even sure that it plainly doesn't work, but I'll have to check first before making any statements here.) And then there are other free jvms which we might want to check out. Any input on them would be greatly appreciated, btw. cheers, Sonja -- Sonja Krause-Harder (skh@suse.de) Research & Development SUSE Linux Products GmbH --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sonja Krause-Harder wrote:
On Thu, Sep 14, 2006 at 11:02:30PM +0200, Manfred Tremmel wrote:
For your own code, just use -source 1.4 -target 1.4 Right, but when SUSE itselve doesn't do this, I will not be able to start a delivered tomcat, Eclipse, with 1.4.2 and all the libs (my /usr/share/java directory is full of jar files which are part of the SUSE distribution) wouldn't be useable with gcj or Sun's java 1.4.2.
If we manage to deliver openSUSE on all relevant platforms with an 1.5 (compatible) java, I actually wouldn't mind that the jars are incompatible with 1.4.2. 1.5 has been around for a while, 1.6 is about to come out, and I don't think we should wait with the move to the admittedly incompatible 1.5 language features until Sun decides to drop support for 1.4.2 altogether.
However (big however!) I have also to care about the platforms for which no Sun java exists, so I am sceptical about the switch as well. But the only way to find out what will really break is to start building the stuff with java 1.5 on the platforms where it is available.
Yeah, well, there's no substantial point in building 1.5 bytecode if the source code doesn't use features from JSE 5 (generics, annotations, autoboxing). Almost every Java OSS project I know of tries hard to be compliant with 1.4 and sometimes even 1.3 (e.g. even Spring Framework 2.0 works with 1.3, and god knows it's a hell of a cool framework with tons of features). The annoyance wrt packaging is that you have to know whether to pass - -source 1.4 -target 1.4 or not, but the minimum JRE major version is always documented, for each project. Most Java OSS projects still only use 1.4 features in their source code. The push towards JSE 1.5 comes mostly through EJB3/JPA (that requires JSE/JDK 1.5). Generally speaking, wide-spread adoption of new JVM/JDK major versions is very slow though, mostly because of EJB container vendors (e.g. IBM just released a 1.5 capable Websphere a few months ago) and, well, you can't just replace all those production servers easily ;)
My hope is to get a *open* java for a *open*SUSE. I don't think Sun's java will be open in near future, it's a process starting with the next version, but will take a while, and maybe the wind changes inbetween. So I hope, gcj + classpath could replace Sun java, so we shouldn't build walls creating with getting incompatible jar-files.
That's a different can of worms ;-) While Sun java is a black box to us, we can (within tight resource and also knowledge constraints on my part) fix gcj/gij/classpath so that it can deal with 1.5-compiled jars. (I'm actually not even sure that it plainly doesn't work, but I'll have to check first before making any statements here.) And then there
As long as the source code doesn't use features from 1.5, it will work great (given the current caveats of GNU Classpath, e.g. Swing support not being complete). As an example, Tomcat 5.5 still runs with 1.4 (needs a few additional jars though). "Fixing gcj/classpath so that they can deal with 1.5-compiled jars" would mean at the very least adding generics, annotations and autoboxing bytecode support into gcj (the compiler), as well as kaffe, sablevm or cocoavm (the runtime(s)). The point about the incompatibility is really the bytecode (obviously): the new features of 1.5 come with new bytecode instructions, and those are not supported by 1.4 JVMs - unless using retroweaver (http://retroweaver.sourceforge.net/), but I can't comment on that, never tried it myself.
are other free jvms which we might want to check out. Any input on them would be greatly appreciated, btw.
I can put you in contact with Dalibor Topic (Kaffe lead), Mark Wielaard (GNU Classpath lead) and possibly others in that realm, I've got good contacts with them (FOSDEM) - besides the fact that they are really nice people. I'm sure they'd be interested in hearing about that ;) IMHO the "problem" with GCJ, GNU Classpath, Kaffe, CacaoVM, SableVM etc.. is that they are highly interdependent and we'd need to release updates at regular intervals, especially for GNU Classpath, at least in the Build Service. Then we would be able to build more and more packages with GCJ/GNU Classpath instead of using the Sun javac, as a lot of progress is being made with every GNU Classpath release. cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <pascal.bleser@skynet.be> <guru@unixtech.be> _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFFCdYfr3NMWliFcXcRAhPyAJ9d68CoJGAN1jN3aD7TCkFOxts4vgCdFcFP uMyRbmCZSLFEtMYaYT2QSYg= =54XJ -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Fri, Sep 15, 2006 at 12:22:23AM +0200, Pascal Bleser wrote:
Yeah, well, there's no substantial point in building 1.5 bytecode if the source code doesn't use features from JSE 5 (generics, annotations, autoboxing).
Agreed.
"Fixing gcj/classpath so that they can deal with 1.5-compiled jars" would mean at the very least adding generics, annotations and autoboxing bytecode support into gcj (the compiler), as well as kaffe, sablevm or cocoavm (the runtime(s)).
I was under the impression that at least the gcc community is already working on that. "Fixing" gcj thus need not mean implementing the stuff myself, but also providing bugreports and testcases etc., which we wouldn't come up with if we just stay with the status quo. With free projects there's at least a possibility for us to help. -- Sonja Krause-Harder (skh@suse.de) Research & Development SUSE Linux Products GmbH --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sonja Krause-Harder wrote:
On Fri, Sep 15, 2006 at 12:22:23AM +0200, Pascal Bleser wrote:
Yeah, well, there's no substantial point in building 1.5 bytecode if the source code doesn't use features from JSE 5 (generics, annotations, autoboxing).
Agreed.
"Fixing gcj/classpath so that they can deal with 1.5-compiled jars" would mean at the very least adding generics, annotations and autoboxing bytecode support into gcj (the compiler), as well as kaffe, sablevm or cocoavm (the runtime(s)).
I was under the impression that at least the gcc community is already working on that. "Fixing" gcj thus need not mean implementing the stuff myself, but also providing bugreports and testcases etc., which we wouldn't come up with if we just stay with the status quo. With free projects there's at least a possibility for us to help.
Yes, totally, testing and providing bugs/reports is great help. IMO the Build Service is a good platform for that, in order to provide the latest builds of GCJ, GNU Classpath, ... for SUSE Linux, and possibly for other distributions as well (maybe the current Fedora maintainers would be interested in sharing the efforts). As those projects are still evolving a lot, and make significant leaps with each release, the distribution is not well suited as it is almost immune to feature upgrades (of packages). - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <pascal.bleser@skynet.be> <guru@unixtech.be> _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFFCk4xr3NMWliFcXcRAgYdAKCEGFcx7yu9Ixv4w4nRz9gn+5GiKgCfehWg hsNotPqco99rQFDKtv6J8qo= =wuBi -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andreas Jaeger wrote:
Manfred Tremmel <Manfred.Tremmel@iiv.de> writes:
Am Mittwoch, 13. September 2006 17:04 schrieb Andreas Jaeger:
We would still deliver both - the question is which to use for building by default... If you compile a java program using java 1.4.2 it's running also with java 1.5.0. If you compile it with java 1.5.0 it will not run with java 1.4.2. So what's worth to deliver both, when nothing works with with
Thanks, didn't know that.
It's not quite correct though. You can build with 1.5.0 or 1.6.0 but tell the java compiler to use the souce compatibility level of 1.4.x javac -source 1.4 ... Of course, if you do that, you cannot use the new language features of 1.5 (annotations, generics).
1.4.2 when it's build with 1.5.0.
You could still install both on your system...
Right.
For my own, I can't switch to 1.5.0, there are a lot of SAP-servers (AIX and SUSE) at work I have to write Java modules and I also can't switch
You can use the 1.5 (or 1.6) compiler and compile for 1.4.x (see above).
to 1.5.0 on my knightsoft-net Webserver, it needs to much memory for the small vserver.
The same bytecode uses more RAM when running with 1.5 than with 1.4 ? oO But still, I think having both is the better approach. cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <pascal.bleser@skynet.be> <guru@unixtech.be> _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFFCa7Ur3NMWliFcXcRAtVPAKC2w9CkteOrfa0yJLkPTn1HNh2mVwCfayRZ p/qL+zBtFeGmjFNAZd1CF+Q= =2Id8 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Am Donnerstag, 14. September 2006 21:34 schrieb Pascal Bleser:
Andreas Jaeger wrote:
to 1.5.0 on my knightsoft-net Webserver, it needs to much memory for the small vserver.
The same bytecode uses more RAM when running with 1.5 than with 1.4 ?
The virtual machine needs more RAM to start, so I don't have enough space left for my own servlets. I've rent the smalest version of the VServer which is very limited in ram (in the FAQ the provider says it's to small for tomcat, I never could belive it ;-) ). Using java 1.5 I can watch two generated pages, the third one ends with a out of memory entry in the logfils. Using java 1.4.2 it works stable without a problem, even with high loads. -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ | http://packman.links2linux.de/ Manfred | http://www.knightsoft-net.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Manfred Tremmel wrote:
Am Donnerstag, 14. September 2006 21:34 schrieb Pascal Bleser:
Andreas Jaeger wrote:
to 1.5.0 on my knightsoft-net Webserver, it needs to much memory for the small vserver. The same bytecode uses more RAM when running with 1.5 than with 1.4 ?
The virtual machine needs more RAM to start, so I don't have enough space left for my own servlets. I've rent the smalest version of the VServer which is very limited in ram (in the FAQ the provider says it's to small for tomcat, I never could belive it ;-) ). Using java 1.5 I can watch two generated pages, the third one ends with a out of memory entry in the logfils. Using java 1.4.2 it works stable without a problem, even with high loads.
http://java.sun.com/j2se/1.5.0/docs/guide/vm/gc-ergonomics.html Just start the 1.5 JVM with - -Xmx64m and you will have the same heap size as the default heap size on 1.4 Tiger (1.5) is definitely faster than 1.4 (even with 1.4 bytecode, it's really the JVM that's faster), it should just be a matter of configuring the maximum heap size (and possibly the thread stack size (-Xss)), as the defaults have changed (see URL above). If you use the 1.5 JVM, you should really try out Tomcat 5.5, it has vast improvements, if you don't already use that version now. As a replacement for Tomcat, Winstone should have lower demands in terms of resources: http://winstone.sourceforge.net/ (dual-license LGPL/CDDL; it supports servlet 2.5, AJP, vhosting, SSL, JNDI, clustering, etc... - for JSP support, you must add Tomcat's Jasper, but that's documented) Jetty should be memory-friendlier than Tomcat as well: http://jetty.mortbay.org/ Though it's perfectly fine to run Tomcat with just 64MB. We've got JIRA running in production (around 80 users, overall) with Tomcat and 64MB. (but I'm afraid we're drifting into off-topicness, sorry for the noise, but could be helpful information to others) cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <pascal.bleser@skynet.be> <guru@unixtech.be> _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFFCdDNr3NMWliFcXcRAhzlAKCfziFCPHTjUB6kRmV8m3eEnRL2gACdGsra Gf0CA6QKtq8TJoKs3SHvDTQ= =rrfZ -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Am Donnerstag, 14. September 2006 23:59 schrieb Pascal Bleser:
Manfred Tremmel wrote:
Am Donnerstag, 14. September 2006 21:34 schrieb Pascal Bleser:
Andreas Jaeger wrote:
to 1.5.0 on my knightsoft-net Webserver, it needs to much memory for the small vserver.
The same bytecode uses more RAM when running with 1.5 than with 1.4 ?
The virtual machine needs more RAM to start, so I don't have enough space left for my own servlets. I've rent the smalest version of the VServer which is very limited in ram (in the FAQ the provider says it's to small for tomcat, I never could belive it ;-) ). Using java 1.5 I can watch two generated pages, the third one ends with a out of memory entry in the logfils. Using java 1.4.2 it works stable without a problem, even with high loads.
http://java.sun.com/j2se/1.5.0/docs/guide/vm/gc-ergonomics.html
Just start the 1.5 JVM with -Xmx64m and you will have the same heap size as the default heap size on 1.4
Sorry, you've understand something wrong, the RAM is very limited! Using -Xmx31m works, using -Xmx30m is to less to start tomcate and -Xmx32m is to much to get it stable run (even a simple ls fails because of missing ram).
Tiger (1.5) is definitely faster than 1.4 (even with 1.4 bytecode, it's really the JVM that's faster), it should just be a matter of configuring the maximum heap size (and possibly the thread stack size (-Xss)), as the defaults have changed (see URL above).
If you use the 1.5 JVM, you should really try out Tomcat 5.5, it has vast improvements, if you don't already use that version now.
I belive it, but the knightsoft-net servier is the only one I can decide, what's installed, all the intranet-servers I'm developing for I can't so I'll try to get the same base. My framework I've created for my website is also the backround for all other developments.
As a replacement for Tomcat, Winstone should have lower demands in terms of resources: http://winstone.sourceforge.net/ (dual-license LGPL/CDDL; it supports servlet 2.5, AJP, vhosting, SSL, JNDI, clustering, etc... - for JSP support, you must add Tomcat's Jasper, but that's documented)
Jetty should be memory-friendlier than Tomcat as well: http://jetty.mortbay.org/
Ok, I think I should take a look on this two alternates.
Though it's perfectly fine to run Tomcat with just 64MB. We've got JIRA running in production (around 80 users, overall) with Tomcat and 64MB.
Hey, I'm doing my performance tests on a i486/66 with 24 MByte RAM, Java 1.3 with Apache + JServ (SUSE 7.3). It's a good motivation to invest some time in optimising the code, when you work with such a server ;-) -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ | http://packman.links2linux.de/ Manfred | http://www.knightsoft-net.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Onsdag 13 september 2006 15:52 skrev Andreas Jaeger:
Here're the current agenda items. Any comments? Anything you like us to look at?
* Java for Distribution building
We're currently building java-1_4_2-sun and the suggestion was to switch to java-1_5_0-sun.
Hmmm.. I run 64bit. And my homebanking doesn't work with Java 1.5.0 (i586) and Firefox (also 32bit). Works fine with java-i586-1.4.2 though. On 32bit SUSE the homebanking works fine with java 1.5.0. Always been a mystery to me. But if no java 1.4.2 is supplied I'd have to run 32bit again or get Java 1.4.2 from SUN and install it manually. Just something to think about - in general I have little idea how much requires java 1.5.0 and how much stuff will only work with 1.4.2. Another thing I'm interested in is the rt2500 driver issue. On your list of features for 10.2 you mentioned fixing that. From what I hear that driver is still very buggy and little or no development is going on upstream. On top of that I hear the driver won't run at all on smp-kernel. Fortunately I don't have that chipset - I have have bcm4306 which has it's own issues - just interested in the topic since very many people seem to have that chipset. Don't know if that topic is big enough for the meeting. Martin --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Martin Schlander <suse@linuxin.dk> writes:
Onsdag 13 september 2006 15:52 skrev Andreas Jaeger:
Here're the current agenda items. Any comments? Anything you like us to look at?
* Java for Distribution building
We're currently building java-1_4_2-sun and the suggestion was to switch to java-1_5_0-sun.
Hmmm.. I run 64bit. And my homebanking doesn't work with Java 1.5.0 (i586) and Firefox (also 32bit). Works fine with java-i586-1.4.2 though. On 32bit SUSE the homebanking works fine with java 1.5.0. Always been a mystery to me.
But if no java 1.4.2 is supplied I'd have to run 32bit again or get Java 1.4.2 from SUN and install it manually. Just something to think about - in general I have little idea how much requires java 1.5.0 and how much stuff will only work with 1.4.2.
We're just speaking about the java for *building* the distribution. We would still deliver both, Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Le mercredi 13 septembre 2006 11:05, Andreas Jaeger a écrit :
We're just speaking about the java for *building* the distribution. We would still deliver both,
Andreas
i hope java 1.5 will be default, more and more program need it, faster program start java 1.6 is suppose to go out in december does suse will include it? --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Marc Collin <collinm@laboiteaprog.com> writes:
Le mercredi 13 septembre 2006 11:05, Andreas Jaeger a écrit :
We're just speaking about the java for *building* the distribution. We would still deliver both,
Andreas
i hope java 1.5 will be default, more and more program need it, faster program start
java 1.6 is suppose to go out in december does suse will include it?
That's too late, check the roadmap, Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Martin Schlander <suse@linuxin.dk> writes:
[...] Another thing I'm interested in is the rt2500 driver issue. On your list of features for 10.2 you mentioned fixing that. From what I hear that driver is still very buggy and little or no development is going on upstream. On top of that I hear the driver won't run at all on smp-kernel. Fortunately I don't have that chipset - I have have bcm4306 which has it's own issues - just interested in the topic since very many people seem to have that chipset. Don't know if that topic is big enough for the meeting.
No, this is something off-topic for the meeting - but should be looked at nevertheless, Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Hello, Andreas Jaeger írta:
Here're the current agenda items. Any comments? Anything you like us to look at?
* Java for Distribution building
We're currently building java-1_4_2-sun and the suggestion was to switch to java-1_5_0-sun.
Could PPC get a bit more Java support? Both IBM and Sun have Java for PPC, but none of them are included in openSUSE, just v1.4.2 IBM in SLES (if I remember well, I just deleted my SLES accidentally with factory :-) ). Bye, CzP --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Peter Czanik <pczanik@fang.fa.gau.hu> writes:
Hello,
Andreas Jaeger írta:
Here're the current agenda items. Any comments? Anything you like us to look at?
* Java for Distribution building
We're currently building java-1_4_2-sun and the suggestion was to switch to java-1_5_0-sun.
Could PPC get a bit more Java support? Both IBM and Sun have Java for PPC, but none of them are included in openSUSE, just v1.4.2 IBM in SLES (if I remember well, I just deleted my SLES accidentally with factory :-) ).
Not sure why sun java is not included but we cannot include IBM Java in openSUSE, Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Am Donnerstag, 14. September 2006 10:04 schrieb Andreas Jaeger:
Not sure why sun java is not included but we cannot include IBM Java in openSUSE,
Why? -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ | http://packman.links2linux.de/ Manfred | http://www.knightsoft-net.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Manfred Tremmel <Manfred.Tremmel@iiv.de> writes:
Am Donnerstag, 14. September 2006 10:04 schrieb Andreas Jaeger:
Not sure why sun java is not included but we cannot include IBM Java in openSUSE,
Why?
No redistribution rights, Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
On Wed, Sep 13, 2006 at 09:28:04PM +0200, Peter Czanik wrote:
Could PPC get a bit more Java support? Both IBM and Sun have Java for PPC,
There's a Sun java for ppc? Do you have a link to that? Sonja -- Sonja Krause-Harder (skh@suse.de) Research & Development SUSE Linux Products GmbH --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sonja Krause-Harder wrote:
On Wed, Sep 13, 2006 at 09:28:04PM +0200, Peter Czanik wrote:
Could PPC get a bit more Java support? Both IBM and Sun have Java for PPC,
There's a Sun java for ppc? Do you have a link to that?
There isn't, AFAIK. On PPC you must use IBM's. The MacOSX/PPC JVM is ported by Apple, not by Sun. cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <pascal.bleser@skynet.be> <guru@unixtech.be> _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFFCa0pr3NMWliFcXcRAifwAJ9oq0rX2mlFd2aRyx5R79l37RnnNACeNBqd 5D2RzSIVIa0jbzpm7hDMrss= =oSkG -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hello, Sonja Krause-Harder wrote:
Could PPC get a bit more Java support? Both IBM and Sun have Java for PPC,
There's a Sun java for ppc? Do you have a link to that?
Found it here: http://www.ppczone.org/news.php?id=271 Which has a link to http://java.sun.com/j2se/embedded/ Personally I never tried it, but got positive feedback from Gentoo developers. Bye, -- CzP http://peter.czanik.hu/ --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Thu, Sep 14, 2006 at 10:43:50PM +0200, Peter Czanik wrote:
Found it here: http://www.ppczone.org/news.php?id=271 Which has a link to http://java.sun.com/j2se/embedded/
Interesting and well hidden, I wouldn't have looked for it in the embedded section (though given the use of ppc linux in that area it makes sense of course). I'll look at it, and its license, maybe we can include it. cheers, Sonja -- Sonja Krause-Harder (skh@suse.de) Research & Development SUSE Linux Products GmbH --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Wed, Sep 13, 2006 at 03:52:43PM +0200, Andreas Jaeger wrote:
* Java for Distribution building
We're currently building java-1_4_2-sun and the suggestion was to switch to java-1_5_0-sun.
Please let's do that, and as soon as possible so that we've got enough time to fix the fallout (if any). Daniel, what do you think? cheers, Sonja -- Sonja Krause-Harder (skh@suse.de) Research & Development SUSE Linux Products GmbH --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sonja Krause-Harder wrote:
On Wed, Sep 13, 2006 at 03:52:43PM +0200, Andreas Jaeger wrote:
* Java for Distribution building
We're currently building java-1_4_2-sun and the suggestion was to switch to java-1_5_0-sun.
Please let's do that, and as soon as possible so that we've got enough time to fix the fallout (if any). Daniel, what do you think?
cheers, Sonja
JPackage still uses 1.4.2 for the upcoming 1.7 version and I think we should too. What advantage would using 1.5.0 for building have? I don't really see any. When a package needs Java >= 1.5.0 it's always possible to use java-1.5.0-devel as a BuildRequirement. Using -source 1.4 -target 1.4 would make 1.4.2 compatible class files -- granted ... but it would be necessary to adjust every java spec file but the ones that need Java >= 1.5.0 ... Cheers, - -- Daniel Bornkessel Tel: +49 911 740 53 161 Novell :: SUSE R&D :: Internal Tools / Java Packaging ______________________________________________________________________ Key fingerprint = 9012 D34F D3E1 FB50 BF89 FD04 8E19 8831 FFBB 7369 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iQCVAwUBRQ5PMo4ZiDH/u3NpAQI+GwP/WrGH6sJQLdszIgB/4r77WumA3MNJjshS pZSx3Sq5OKobcp4PZZyRDDhSI8GkyCvRj35ik62MOdPazq/QjR98UWPovUjMZdIh jU9az9ZhXfN/u5tJp28BGtJKugdP8h3wrMgOR0zZ3SxPR5jU+3k/XUtiAdMv6ZpW bomG3aU6P6Q= =b8Gs -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Thu 14 Sep 2006 01:52:43 NZST +1200, Andreas Jaeger wrote:
* umask ("hard coded value in /etc/profile vs. pam_umask.so", see also "man pam_umask")
SUSE forgot the pam_umask man page for 10.1...
Questions - Remove value from /etc/profile and store in a config file: - Use /etc/login.defs not only for creation of home directory, but also for login - Use pam_umask.so or use .profile parser solution?
Parsing profiles looks messy to me. Also, it would need to work for tcsh too, which might be questionable.
- Should YaST2 allow/provide umask value per user or only global? User is able to set a value with chfn -m umask=XXX
Any user is free too chose whatever uamsk they want by setting it in their shell's login script, therefore no point putting it into yast. A global default for users might be handy - also for whether new users should be in a "users" group or their own each. What has been annoying me for almost a decade is that Linux (any distro I bet) doesn't hack a umask of 077 for root. I hope there is no argument over why that should be default. Stubbornly been there, nothing but trouble that way so I gave it up. Volker -- Volker Kuhlmann is list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
participants (14)
-
Andreas Hanke -
Andreas Jaeger -
Carl-Daniel Hailfinger -
Daniel Bornkessel -
Manfred Tremmel -
Marc Collin -
Martin Schlander -
Pascal Bleser -
Peter Czanik -
Robert Schiele -
Sonja Krause-Harder -
Stephan Kulow -
Tobias Burnus -
Volker Kuhlmann