For the library packaging policy as discussed previously this is an
example on how to fix an offending package. We take the example of
curl, as we have (ick) compat-curl2 and compat-curl3 packages alread,
which is a mess.
Curl currently is split into curl providing the /usr/bin/curl binrary
and the /usr/lib64/libcurl.so.X library and a curl-devel package with
development files.
The library packaging policy forces you to split off a libcurl4 package
with just the libcurl.so.4* shared libraries.
The library packaging policy forces you to rename curl-devel to
either libcurl-devel or libcurl4-devel if you want to support development
with different curl versions. We choose not to and rename it to
libcurl-devel which will depend on libcurl4 for this version.
For the renaming you need a proper Provides: curl-devel and Obsoletes:
curl-devel dependency for update to work. The split off of libcurl4
does not require anything special as shared lib requirements will take
care of what is necessary.
[Yes, I've started on the above, no need to do it for curl, but please
consider fixing your package early if you ever had the need to provide
compat-* packages and fix your package the next time you touch it
otherwise]
Thanks,
Richard.
--
Richard Guenther <rguenther(a)suse.de>
Novell / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
Hello,
I'm wondering what is the status of SPC. Which is the latest revision?
On the page [*] I have 2 links on pdf version (rev 1.0) and html version (rev
1.1), the last contains only Part 1, that seems odd to me.
[*] http://developer.novell.com/wiki/index.php/SUSE_Package_Conventions
--
Regards, Nikolay Derkach
Hello,
How to make -32bit compatibility packages on x86_64 system with build? I
haven't found this in documentation, but I was told to use --baselibs option.
How should I configure baselibs?
--
Regards, Nikolay Derkach
Just wondering whether this is a package problem, or something else.
Problem: the figures/pictures are not shown in the help manual when
khelpcenter is used to display the help pages. When yelp is used the figures
are there.
I have a gnome/gtk based application. It comes with help pages that are
located in: /opt/gnome/share/gnome/help/gramps/C/
As I use the nl version the help manual is stored
at: /opt/gnome/share/gnome/help/gramps/nl
In this directory there is:
# /opt/gnome/share/gnome/help/gramps/nl> ls
figures gramps.xml
With many pictures/figures in the figures directory. Somehow all seems well.
But when running the gtk/gnome application gramps in kde and ask it to show
me the help manual, it's shown incomplete (no figures).
Is this a packaging problem? Did I miss a kde configuration setting when
package gramps (build server home:rbos)???
--
Richard Bos
Without a home the journey is endless
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
Hi,
someone is testing my package for gramps on openSUSE-10.3 As I don't have
10.3 installed yet I can't test it myself. When installing the package, yast
complains that there is "no provider for /bin/sh". What can be the reason
for this? Is there anything to be updated to the package for opensuse-10.3?
The specfile is locate at:
http://build.opensuse.org/package/show?package=gramps&project=home%3Arbos
--
Richard Bos
We are borrowing the world of our children,
It is not inherited from our parents.
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
This is a patch against filelist-10.3 to verify that (parts of) the
proposed library packaging policy are followed. It's non-fatal right now
as nearly every package fails it :P
A few examples:
> ~/bin/filelist-10.3 /work/built/dists/all/x86_64/packs-x86_64/libelf
... checking filelist
libelf: "/usr/lib64/libelf.so" is not allowed in a non-devel package
WARNING: Your package would fail here!
libelf: "/usr/lib64/libelf.so.0" should be in a lib package with the
.so version 0 appended, like libelf0
libelf: "/usr/lib64/libelf.so.0.8.9" should be in a lib package with the
.so version 0 appended, like libelf0
> ~/bin/filelist-10.3
/work/built/dists/all/x86_64/packs-x86_64/libapparmor
... checking filelist
libapparmor: "/lib64/libapparmor-2.0-45.so.1" should be in a lib package
with the
.so version 1 appended, like libapparmor1
libapparmor: "/lib64/libapparmor.so.1" should be in a lib package with the
.so version 1 appended, like libapparmor1
libapparmor: "/lib64/libimmunix.so.1" should be in a lib package with the
.so version 1 appended, like libapparmor1
libapparmor: "/usr/lib64/libapparmor.so" is not allowed in a non-devel
package
WARNING: Your package would fail here!
But of course we also have conforming packages!
> ~/bin/filelist-10.3 /work/built/dists/all/x86_64/packs-x86_64/libapr1
... checking filelist
Can we enable this in BETA now and STABLE soon?
Thanks,
Richard.
--
Richard Guenther <rguenther(a)suse.de>
Novell / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex
Hi,
why can't i compile a program in 32bit mode on 10.2 on a x86_64 machine/machine?
Here's a simple testcase:
build:~# cat test.c
int main(void) {
return 0;
}
build:~# gcc -m32 -o test test.c
/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld: skipping incompatible /usr/lib64/gcc/x86_64-suse-linux/4.1.2/libgcc.a when searching for -lgcc
/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld: cannot find -lgcc
collect2: ld returned 1 exit status
build:~#
So it seems that a libgcc.a for 32bit is missing?
build:~# find / -iname "*libgcc*"
/lib/libgcc_s.so.1
/usr/src/linux-2.6.18.2-34/arch/mips/lib/libgcc.h
/usr/lib64/gcc/x86_64-suse-linux/4.1.2/libgcc_eh.a
/usr/lib64/gcc/x86_64-suse-linux/4.1.2/libgcc_s.so
/usr/lib64/gcc/x86_64-suse-linux/4.1.2/libgcc.a
/lib64/libgcc_s.so.1
/installed-pkg/libgcc41-32bit
/installed-pkg/libgcc41
build:~#
If i try the same on 10.1 it all works fine because on 10.1 i have libgcc.a for
32bit mode:
# on 10.1
build:/# rpm -qf /usr/lib64/gcc/x86_64-suse-linux/4.1.0/32/libgcc.a
gcc-4.1.0-25
build:/#
Is it a bug in the gcc package or is it my fault?
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
Hi,
for a few weeks now openSUSE Factory has a binutils which
supports -Bsymbolic-functions. This option causes global symbol references
inside a shared object to be resolved locally if that is possible, e.g. if a
shared library calls within one of its functions another exported function
that is defines itself, then that one is encoded via a local relative jump,
rather than going through the complicated and slow ELF semantics.
This does break if an application is interposing a symbol, e.g. tries to
replace one of the libraries public functions by one it defines by its own
and expects the library to call the one the application provides.
This is however rare and usually even is an unintended symbol clash.
So, whats the advantage?
of course that depends on the library type: C++ benefits a lot more than plain
C libraries.
I've tested it however successfully against small c libraries (e.g.) ncurses
or dbus-1 as well as big c++ libraries (libzypp, boost, libstdc++,qt3).
For e.g. ncurses it resulted in a 1.2% disk space saving and roughly 25%
reduced relocation time (granted, its only measurable via
LD_DEBUG=statistics). For qt3, it results in a 38% relocation time
improvement and a 5.5% disk space saving.
So, in short: if you know what you're doing, then use
$LDFLAGS=-Wl,-Bsymbolic-functions
Dirk
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
Hello,
I am trying to update Banshee's spec file to use the new GConf schemas
macros [1] that Stanislav has come up with for 10.3, but am having some
problems.
I'm no packaging guru, and am finding it a little confusing. This may
stem from the fact that Banshee has many different .schema files to
install in each of its packages.0
I have %gconf_schemas_prereq at the top of the spec file and %
find_gconf_schemas in my %install section. I think this is correct, but
what I am unsure of is what to do for %files in each of the packages I
am creating. Each package may have multiple .schema files to install,
for example:
%files plugins-default
%defattr(-,root,root)
%{sysconfdir}/gconf/schemas/banshee-plugin-audioscrobbler.schemas
%{sysconfdir}/gconf/schemas/banshee-plugin-metadatasearcher.schemas
%{sysconfdir}/gconf/schemas/banshee-plugin-mmkeys.schemas
%{sysconfdir}/gconf/schemas/banshee-plugin-notificationarea.schemas
Any clarification would be very helpful.
Thanks & Regards,
Aaron
[1] http://en.opensuse.org/SUSE_Build_Tutorial/GConf_scritplets
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org