Hi,
You may have noticed: I added libtool as buildrequire to many
packages. Now that I'm through with my list, I would like to remove
libtool from the projconfig. After that you need to buildrequire
libtool if you need it otherwise the package will fail, but unless
something slipped this should not be the case for any package
in factory.
Next stop: automake
Greetings, Stephan
--
Sent from openSUSE
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
To revive the discussion about pom2spec :-)
I was playing with it and it is exactly the kind of pragmatism one is
missing when dealing with Java. Nice work Pascal.
I remember there where a few topics open when Pascal presented it in the
mailing list.
- Naming
while org.apache.maven.doxia.doxia-sink-api is already long, do you
think it makes sense to prefix this with java- or jar- ? (like rubygems-
do). I do think the whole groupId artifactId is the better way, but I am
not sure if in all cases it would be needed. May be one could specify a
shorter way (java-doxia-sink-api) in the command line, when ambiguity is
not likely. Requires and Provides would still work using the Provides:
java(org.apache.maven.doxia:doxia-sink-api) kind of string.
- Provides.
Right now it uses something like
java(org.apache.maven.doxia:doxia-sink-api). I just want to point out
that fedora is already using mvn(org.apache.maven.doxia:doxia-sink-api).
Do we want to interoperate across them?
Other points:
- Binaries. For example:
$ mkdir org.scala-tools.sbt.sbt-launch
$ cd org.scala-tools.sbt.sbt-launch
$ pom2spec
call again and specify the exact version, one of:
- 0.7.1
- 0.7.2
$ pom2spec 0.7.2
In this case, the built rpm misses the %{_bindir}/sbt which is just a
call to java -Xmx512M -jar $longdir/sbt-launch.jar "$@"
It would be a nice feature to tell pom2spec something like -bin sbt and
it could create the script automatically.
- One question... how is the classpath supposed to work? I see some
.classpath files put together to the jars, but empty.
- Why an artifact like Vaadin creates 2 rpms for the binary and 2 for
the sources?
Wrote:
/space/packages/rpms/noarch/com.vaadin.vaadin-6.7.2-6.7.2-0.noarch.rpm
Wrote:
/space/packages/rpms/noarch/com.vaadin.vaadin-6.7.2-6_7_2-6.7.2-0.noarch.rpm
Wrote:
/space/packages/rpms/noarch/com.vaadin.vaadin-6.7.2-sources-6.7.2-0.noarch.rpm
Wrote:
/space/packages/rpms/noarch/com.vaadin.vaadin-6.7.2-6_7_2-sources-6.7.2-0.noarch.rpm
--
Duncan Mac-Vicar P. - http://www.suse.com/
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix
Imendörffer, HRB 16746 (AG Nürnberg)
Maxfeldstraße 5, 90409 Nürnberg, Germany
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi,
over the years, I've collected a bunch of great fonts in my home
repository. However, it seems we don't have a consistent naming schema
for fonts.
Although the Packaging Guidelines[1] links to the old Wiki[2], the
information therein is printed in red and I'm not sure how useful is
this nowadays.
This has some interesting effects. If you search for fonts like this:
# zypper se font
you will get _some_ but not all. For example, the popular Linux
Libertine and DejaVu fonts are not listed. A user has to _know_ the
name. IMHO this is not very intuitive and userfriendly.
On the other side, we have lots of fonts which are very inconsistently
named. Here are some examples:
farsifonts
fonts-arabic
freefont
gnu-unifont
indic-fonts
intlfonts-ttf
xorg-x11-fonts
From a usability perspective, it would be very convenient to have a
consistent naming schema with a specific prefix (or suffix), for
example a "-fonts" suffix.
Ubuntu has the prefix "ttf-" for their packages:
http://packages.ubuntu.com/search?suite=natty§ion=all&arch=any&searchon…
Fedora has the suffix "-fonts" for their packages:
https://admin.fedoraproject.org/pkgdb/acls/list/*-fonts*?_csrf_token=b27215…
Another issue: Do we have a special repository dedicated only to fonts?
I couldn't find any... Do you think this is useful?
What do you think?
--------
[1] http://en.opensuse.org/openSUSE:Packaging_guidelines
[2]
http://old-en.opensuse.org/Packaging/Fonts_Policy#Package_layout_for_fonts
--
Gruß/Regards,
Thomas Schraitle
----------------------------------------------------------------------
SUSE LINUX Products GmbH (o<
Maxfeldstrasse 5 /\\ Documentation Specialist
90409 Nuernberg, Germany _\_v http://www.suse.comhttp://lizards.opensuse.org/author/thomas-schraitle/
SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild,
Felix Imendörffer, HRB 21284 (AG Nürnberg)
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi,
We have for a long time a warning in the post-build-checks, that is
obviously greatly ignored, so I plan to make it fatal. I'm talking about
e.g.
WARNING: berkeleydb: /usr/share/doc/packages/berkeleydb/LICENSE already
packaged in package berkeleydb-manual
WARNING: berkeleydb: /usr/share/doc/packages/berkeleydb/README already
packaged in package berkeleydb-manual
In the end it doesn't matter to rpm if a file is installed by one or two
rpms as long as there is no conflict. But a) such conflicts easily
arise during package update and b) if you review the WARNINGs there are
just too many cases where this is a bug (people "splitting out" -lang
packages and still package the translation in the main package). There
are 3930 of such duplicated files in 72 packages and I rather have these
72 packages fixed.
The only problem there is (and very likely the reason this WARNING is
not an ERROR): packages conflicting on rpm level are fine to package
files twice - think of branding-upstream vs branding-openSUSE. So we
need to work on this before we can make this fatal. And this will also
be the way to signal that you planned to package the file twice: use
a rpm conflict.
Greetings, Stephan
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hello Mates,
atm we have the boinc-client in the network Project.
Sadly i haven't enough time to maintain that in future. So i'm trying to sell
it via this list. If you have interest to continue the maintainance just
answer in that thread.
If no new maintainer was found until 30.11.11 i'm thinking about to remove the
package from the project and propose to use the original Linux Installer from
the Project Site.
Have a lot of fun
Sascha
--
Sincerly yours
Sascha Manns
Community &Support Agent
open-slx GmbH
http://www.open-slx.de
This mail is written with Balsam Professional 12.1
First of all sorry for screwing up the mail thread. (I had a crash in my
e-mail client that forced me to copy-and-paste the messages from the web.)
> Filipe
>
> The best thing to find out what is going wrong would be to:
> - "osc build" on your own machine
> - once the error is reached, you can "osc chroot" and get in the build
> root, change to /home/abuild/rpmbuild/BUILD/* and check the content of
> config.log for specific errors related to this.
>
> Hope that helps. If not, just ask, and I'll try to walk with you through
> it (you can also find me on irc / freenode as dimstar)
>
> Dominique
Thanks a lot for the "osc chroot"! Sometimes I feel that using osc (and
OBS) is like driving an alien space ship, full of nice features, but I
cannot read the manual ;-).
I think I found the problem and I'm fixing it right now. I based on
Fedora packages and they rename H5pubconf.h to H5pubconf-32.h and
H5pubconf-64.h respectively. However, I forgot to add a sed line to
change the inside of the file as well.
"sed -i -e s/H5pubconf.h/H5pubconf-64.h/
${RPM_BUILD_ROOT}%{_includedir}/H5public.h"
I'm testing this right now. Thanks again.
Thanks again for showing me the way to do this myself, Filipe.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi,
This is probably a simple thing that I cannot see due to my ignorance at
packaging, but just updated the hdf5 to its 1.8.8 version and that broke
netcdf 1.4.3, I get the following error:
checking hdf5.h usability... no
checking hdf5.h presence... no
checking for hdf5.h... no
configure: error: NetCDF-4 requires HDF5, but hdf5.h cannot be found.
Although, hdf5.h exists and the hdf5-devel *does* install it. Also, I do
know that netcdf 1.4.3 *is* compatibly with hdf5 1.8.8.
Can anyone help my find where my mistake is?
Thanks, Filipe.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi packaging,
I want to know how to include two or more compressed packages as
source in specfile.
I know I can use Source0, Source1, blabla...but normally Source0+ is
.desktop, AUTHOR and etc.
I saw choqok does so, but indeed the second package is some part of
the first like:
choqok-1.2.tar.bz2 extracts to choqok-1.2, choqok-lang.tar.bz2
extracts to choqok-1.2/po/
Now I want to include packages of different directory like:
/usr/share/icons and /home/marguerite/bin
Can I able to do that? how can I switch between them later using
popd/pushd or other commands?
please write in simple and plain english with such examples...it's
really advanced knowledge for a newbie&girl.
Thx.
Marguerite
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi,
I'm trying to update the hdf5 package to its latest version (1.8.8).
I've branched it here:
https://build.opensuse.org/package/show?package=hdf5&project=home%3Aocefpaf…
and I'm having issues with the rpmlint Warnings and Error at the end
of this e-mail.
I have a some questions regarding the rpmlint: (Please bear in mind
that I not a skilled packager nor a programmer.)
1) I notice that other distro (e.g. Fedora do not pacth for those warnings)
2) How bad are those errors below? They need to be patched or is there
a way around?
3) I do not have the skills to pacth those, in this case who should I
approach for help?
Thanks, for the attention, Filipe
RPMLINT:
I: Function call uses possibly exploitable format stringsW: hdf5
format-security h5import.c:1497, 1507
I: Program is using implicit definitions of functions getting
pointers or implemented by macros. These functions need to use their
correct prototypes to allow correct argument passing on e.g. x86_64 .
- Implicit memory/string functions need #include <string.h>. -
Implicit *printf functions need #include <stdio.h>. - Implicit
*printf functions need #include <stdio.h>. - Implicit *read*
functions need #include <unistd.h>. - Implicit *recv* functions
need #include <sys/socket.h>.W: hdf5 implicit-pointer-decl
H5LTanalyze.c:2004
I: Program returns random data in a functionE: hdf5
no-return-in-nonvoid-function H5LTanalyze.l:187E: hdf5
no-return-in-nonvoid-function dt_arith.c:3473E: hdf5
no-return-in-nonvoid-function h5diff_common.c:72
I: Program returns random data in a functionE: hdf5
no-return-in-nonvoid-function H5LTanalyze.l:187E: hdf5
no-return-in-nonvoid-function dt_arith.c:3473E: hdf5
no-return-in-nonvoid-function h5diff_common.c:72
ps: hdf5 is in important package for scientific data storage, it is
important (at least in my view) that an important distro like opensuse
offer its latest version.
*****************************************************
Filipe Pires Alvarenga Fernandes, PhD Candidate
School of Marine Science and Technology
University of Massachusetts at Dartmouth
706 Rodney French Blvd., New Bedford, MA 02744
Email: falvarengafernandes(a)umassd.edu
ocefpaf(a)gmail.com
http://ocefpaf.tiddlyspot.com/
*****************************************************
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org