Pushing cmake 2.6 to F9
by Orion Poplawski
I've gotten a request to update cmake to 2.6 in F-9. Does anyone have
any objections? There can be some slight incompatibilities, but are
generally easily fixed.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
15 years, 10 months
cvs make new source
by Pierre-Yves Chibon
Dear all,
I just would like to know if I am the only one facing this problem:
>$make new-sources FILES="guake-0.3.1.tar.gz"
>Checking : guake-0.3.1.tar.gz on
>https://cvs.fedoraproject.org/repo/pkgs/upload.cgi...
>ERROR: could not check remote file status
>make: *** [new-sources] Error 255
Thanks
Regards,
Pierre
15 years, 10 months
Java guidelines questions
by Jerry James
I have some questions about the Java packaging guidelines with respect
to native libraries [1]. JNI using packages must put the JAR and .so
in %{_libdir}/%{name}, and use System.load() with a full path instead
of using System.loadLibrary(). I guess this is for multilib
situations, so you can have multiple JARs, each pointing to the
correct .so. Since that full path can start with either /usr/lib or
/usr/lib64, how have others generated that full path?
Wouldn't it be better to have a single JAR in /usr/share/java, and
choose the correct path with the os.arch system property (which,
annoyingly, is "amd64" with OpenJDK and "x86_64" with gcj on my
machine)? We have to pass a full path to System.load() anyway, so I
don't see the advantage of having the JAR under %{_libdir} in that
case. Has there been any thoughts around providing a Fedora-specific
JAR to hide the details of native library loading? (Maybe
"Fedora.loadLibrary()"?)
Also, I know how to generate a .so with GCJ using aot-compile-rpm.
How is this supposed to work for applications? Say I have a JAR file
with a main method, and a wrapper script to invoke it in %{_bindir}.
On a system that uses GCJ primarily, does that wrapper script do the
right thing (invoke the gcj-compiled code)?
Finally, does anybody know why "gcj --target-help" sends this to stderr?
cc1: warning: command line option
"-fbootclasspath=./:/usr/share/java/libgcj-4.3.0.jar" is valid for
Java but not for C
References:
[1] https://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_file
Thanks,
--
Jerry James
http://loganjerry.googlepages.com/
15 years, 10 months
cannot cvs tag (permission denied)
by Neal Becker
I've been away for 2 weeks. I tried to do cert update, I have a new .fedora-upload-ca.cert dated 8/20.
I get:
make tag build
cvs tag -c mercurial-1_0_2-1_fc10
Permission denied (publickey).
cvs [tag aborted]: end of file from server (consult above messages if any)
15 years, 10 months
GNUstep filesystem layout discussion
by Michel Salim
What
===
GNUstep is a Obj-C-based framework, similar to Mac OS X's Cocoa
State of GNUstep in Fedora
================
GNUstep has long been excluded from Fedora due to its non-standard
filesystem layout. Recently, however, its support for being installed
under the FHS layout has improved. gnustep-make is now in Fedora.
There are some problems with the current layout used by Fedora; see
below.
Other distributions
===========
Debian and its derived distributions have the complete GNUstep stack
already packaged. The file system layout they adopted seem to be a
flattened FHS layout.
Current problems
==========
OpenStep/GNUstep/Cocoa allow for application bundles: self-contained
directories that is treated by the application launcher (openapp in
GNUstep) as applications. In GNUstep terminology, a "flattened"
layout, such as used in Debian, makes the application bundles
platform-specific. In an unflattened layout, however, such as used by
default when using the GNUstep layout (as opposed to the FHS layout
that we are constrained to use in Fedora), fat binaries are possible:
binaries are stored under a directory specifying their platform.
for instance:
Hello.app
\--- i386
| \--- hello
\--- x86_64
\--- hello
This seems more desirable, in that it will allow an unmodified
'openapp' launcher to work on multilib systems: the default
application path is /usr/lib/GNUstep/Applications, regardless of
whether %{_libdir} is /usr/lib or /usr/lib64.
The problem, right now, is that GNUstep tools are currently installed
in /usr/bin/<arch>. Which conflicts with util-linux-ng, where
/usr/bin/<arch> is an executable wrapper around 'setarch <arch>'.
We would need to settle on our GNUstep layout, before the rest of
GNUstep can be packaged. The main options right now seem to be:
- FHS, flattened (like Debian). We would need to override GNUstep-make
to install under %{_libdir} rather than %{_prefix}/lib. It will
require a customized openapp to handle multilib systems
- FHS, unflattened (like our current gnustep-make). Works well with
multilib. We need to decide where to put GNUstep tools: Axel suggests
/usr/bin/GNUstep/<arch>. Base libraries currently go in
/usr/lib/<arch>, and are probably fine there. Moving them to
/usr/lib/GNUstep/<arch> might cause confusion as the higher-level
frameworks are installed there.
- Pure GNUstep layout. Everything goes in /usr/GNUstep
Thoughts? Once we come up with a consensus I'll probably start a page
on the Wiki. Anyone interested in joining a GNUstep SIG?
Regards,
--
Michel Salim
http://hircus.jaiku.com/
15 years, 10 months
Banshee Orphanage Spree
by Nigel Jones
Hi all,
As I no longer use banshee it seems pointless to try and maintain such a
large package. In addition there are several upstream weirdnesses that
drove me nuts (such us distributing libraries privately) that started
causing weird conflicts with other packages.
All-in-all if you use them and care enough to maintain them, I'd really
recommend it.
The packages are:
* banshee
* ipod-sharp
* libipoddevice
* podsleuth
Banshee has a nasty bug in F-8 (which I intend to file) which makes it
provide ndesk-dbus-glib, and it should be possible to upgrade to 1.2.0
for F-8 now (although it's so late in the cycle it may not be worth it).
Don't forget to take the bugs too!
- Nigel
--
Nigel Jones <dev(a)nigelj.com>
15 years, 10 months
Cannot create update
by Adrian Reber
I created an update for grip-3.2.0-22.fc9 and got a 500 (Internal Error)
When I am now trying to create it again I get
grip-3.2.0-22.fc9 update already exists!
but I cannot find it anywhere. Would be great if someone could take a
look at it. Thanks.
Adrian
15 years, 10 months
