Updates to Eclipse Plugin packaging guidelines
by Andrew Overholt
Hi,
I have a few updates to the Eclipse Plugin packaging guidelines. They
include some clarifications, typos, and updates for Eclipse 3.4.x. The
only bit of real substance is modifying the template to note how we're
using the dropins mechanism for plugin installation in 3.4.x and above.
I've attached a diff 'cause I don't think I can commit it. Can someone
else?
Thanks,
Andrew
15 years
LGPLv2.1 vs. LGPLv2
by Chuck Anderson
I see that the Licensing page [1] treats LGPLv2 and LGPLv2.1 as the
same, with a short name of "LGPLv2". Also, rpmlint complains about
LGPLv2.1 in spec files. Why is this?
I'm packaging a program [2] that uses 2.1 in the README/COPYING and 2
in the source code headers. I've received clarification on the
license from the author as LGPLv2.1+, but now I wonder if it makes any
difference since the spec tag would be the same in either case.
[1] http://fedoraproject.org/wiki/Licensing
[2] https://bugzilla.redhat.com/show_bug.cgi?id=465897
15 years
Packaging Javadocs for subpackages
by Brennan Ashton
I have been trying to package a java package called:
jeuclid
that has these subpackages:
jeuclid-mathviewer
jeuclid-fop
feuclid-cli
Do I create
jeuclid-javadocs
jeuclid-mathviewer-javadocs
jeuclid-fop-javadocs
feuclid-cli-javadocs
or just
jeuclid-javadocs
--Brenan Ashton
15 years
f11 build error
by Gregory Hosler
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi all,
not sure if this is the correct fedora mailing list or not to bring this up on...
I came across a build error on X64, in F-11
I have been seeing this exact bug report my other distso users that have been building my
package on other distro x64 platforms, and so far I do not know what the solution might be.
When i do a libtool build on a library, I am seeing the following:
/bin/sh ../libtool --tag=CC --mode=link gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
- -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic
- -Wno-pointer-sign -funsigned-char -shared -fpic -fPIC -o libgyachi.so gytreeview.o
gy_config.o gyachi_lib.o parsecfg.o theme_support.o sound_plugin.o plugins.o -lgtk-x11-2.0
- -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo
- -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lltdl
- -lX11 -lpthread
libtool: link: gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
- -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wno-pointer-sign
- -funsigned-char -fpic -fPIC -o libgyachi.so gytreeview.o gy_config.o gyachi_lib.o
parsecfg.o theme_support.o sound_plugin.o plugins.o -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0
- -lgio-2.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo -lpango-1.0 -lfreetype
- -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lltdl -lX11 -lpthread
/usr/lib/gcc/x86_64-redhat-linux/4.3.2/../../../../lib64/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
collect2: ld returned 1 exit status
ld is not treating this as a shared library, rather it is treating this as a main program.
Anyone else see this ?
any ideas as to what i'm doing wrong, or what I might do to fix this ?
For what it's worth, this exact package, and this exact libtool line builds correctly on
F-10 and ALL other earlier revs (F-9, F-8, F-7, F-6, etc. etc...) on X64 (and other
platforms...)
If this is not the right mailing list to bring this up on, please point me at a more
proper list!
:)
All the best,
- -Greg
- --
+---------------------------------------------------------------------+
Please also check the log file at "/dev/null" for additional information.
(from /var/log/Xorg.setup.log)
| Greg Hosler ghosler(a)redhat.com |
+---------------------------------------------------------------------+
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFJIYs/404fl/0CV/QRAqRCAKCw2hw4PTPirHnfJz9NcPFy3faiCACgsR8Z
gBLp0kciNEYhcd+QuJLiGHU=
=QNrm
-----END PGP SIGNATURE-----
15 years
Questions about dependencies in rpm packages
by Olivier Bourdon
Hello
I have been using this wonderfull Fedora distro since FC2 and I am
currently using FC8 migrating soon to
FC10 as soon as it becomes official at the end of the month
One thing just started puzzling me is when I look at the list of
dependencies of say BackupPC
rpm -qp --requires BackupPC-3.0.0-3.fc8.noarch.rpm | sort | uniq -c |
sort -n | tail
1 rsync
1 /usr/bin/perl
1 /usr/sbin/useradd
1 /usr/sbin/usermod
2 chkconfig
2 perl(Archive::Zip)
2 perl(Compress::Zlib)
2 perl(XML::RSS)
3 initscripts
5 /bin/sh
why are some of these duplicated ?
I can guess from the src.rpm file for initscripts that this comes from
the lines:
Requires(preun): initscripts, chkconfig
Requires(post): initscripts, chkconfig, %{_sbindir}/usermod
Requires(postun): initscripts
but what about /bin/sh ??
Furthermore using a specific formating string like
rpm -q -p --qf '[%{REQUIRENAME} %|REQUIREFLAGS?{%{REQUIREFLAGS:depflags}
%{REQUIREVERSION}}:{}|\n]' BackupPC-3.0.0-3.fc8.noarch.rpm
what should be the format string to potentially get the "differences"
between all expressed dependencies
Tried several choices but without much success
Thanks for your time & help
15 years
BuildRequires: /lib/ld-linux.so.2 + mock
by Jussi Lehtola
Hi,
I'm packaging the open64 compiler, see
https://bugzilla.redhat.com/show_bug.cgi?id=470830 .
The problem I'm facing is that the prebuilt compiler
needs /lib/ld-linux.so.2 to operate. The package builds fine in mock for
rawhide and f9 x86_64, but fails for x86_64 f8, epel4 and epel5 with the
error
ERROR: Bad build req: No Package Found for /lib/ld-linux.so.2. Exiting.
Is this a bug in mock or should I formulate the dependency in another
way? One way would of course be BR: glibc.i386 but that is not good
since glibc.i686 is installed on modern systems...
--
Jussi Lehtola <jussi.lehtola(a)iki.fi>
15 years
*.h files in a directory under %{_libdir}?
by Mary Ellen Foster
Yesterday, there was a bug report on pl (SWI Prolog), a package that I
co-maintain (https://bugzilla.redhat.com/show_bug.cgi?id=471071), and
I'm not sure what to do about it.
I guess SWI assumes that it will be installed with all of its
libraries and related files into a single directory structure, not
following the normal LSB file layout. In the pl-devel package at the
moment, the libraries etc. are under %{_libdir}/pl-%{version}, and
this directory also ends up as the "PLBASE", but the include files are
in their LSB-approved place under /usr/include/pl.
What is the best way to respond to this? I assume it's not encouraged
to put *.h files into %{_libdir}, but on the other hand, breaking
upstream assumptions like this isn't great either. PLBASE is
documented as "the home directory of SWI-Prolog", but I'm not sure if
it's actually guaranteed anywhere that .h files will be in this
directory.
Suggestions welcome!
MEF
--
Mary Ellen Foster -- http://homepages.inf.ed.ac.uk/mef/
Informatik 6: Robotics and Embedded Systems, Technische Universität München
and ICCS, School of Informatics, University of Edinburgh
15 years