Hey,
Dominique and I are currently wondering what to do wrt libexecdir for
evolution-data-server. Should we leave it unchanged (so files will be in
/usr/lib) or should we change it to /usr/lib/evolution-data-server?
If the latter, is there any reason this is not done automatically?
Also, hrm, would rpmlint have ways to warn about packages that put
binaries in libdir instead of libexecdir? (I can find a few of them here
with a grep)
Vincent
--
Les gens heureux ne sont pas pressés.
--
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 compile project called wflogs.
Project ->
https://build.opensuse.org/package/show?package=wflogs&project=home%3Adoiggl
Last log ->
https://build.opensuse.org/package/live_build_log?arch=x86_64&package=wflog…
spec file ->
https://build.opensuse.org/package/view_file?file=wflogs.spec&package=wflog…
I have a link to another project called wfnetobjs too (no wfnetobjs rpm
installed yet)
Last set of wflog errors:
configure: error: wfnetobjs-incdir: no directory found, use configure
option
error: Bad exit status from /var/tmp/rpm-tmp.w8AYXU (%build)
RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.w8AYXU (%build)
System halted.
Can someone assist me to compile this package please.
1. I think Ive got to install wfnetobjs rpm but dont know to set that in
the spec file.
2. Also I got to do the configure bit with a call like (but unsure how to
set in the spec file)
# ./configure --with-wfnetobjs-libdir=/usr/include/wallfire/
help appreciated.
Cheers Glenn
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
Hi,
Milestone 4 is out and Milestone 5 is going to be released
next week. But there is a catch: Germany (and a lot of the
western world) has holidays either friday or monday
(or both in the case of Germany).
So while I moved the release data of Milestone 5 to friday
next week, this only means we will still take a couple of
packages on april, 6th - but the big majority of packages
needs to be submitted by tomorrow.
With 274 diffs in devel projects, that is a lot to submit.
So please take care not to miss the deadline.
Note that M5 will bring a new Xorg and a new kernel - and a lot
of people have vacation around the holidays, so if you don't
make it, there won't be time for extra hand holding.
And for those that keep wondering about milestones: Milestone 5
is the last release before we head into feature freeze. After it
I only allow leaf packages to be updated - including a text freeze
for all of it.
Milestone 6 is then the first "Beta" - i.e. a milestone after
feature freeze, so Milestone 5 will traditionally be the worst,
please don't make it even worse.
For details of your forgotten devel project: http://tinyurl.com/factory-status
Greetings, Stephan
--
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 get a kernel that will be patched, then obs to to compile
it to generate a .rpm and I need some assistance.
- Its based on kernel 2.6.33.x , so Ive set up a link to the sources of
the package kernel-source of project Base:Kernel.
Details are: <link project='Base:Kernel' package='kernel-source'
cicount='copy'/>
Questions:
- What does the BuildRequires line need so kernel-source-2.6.33.x gets
installed (e.g kernel-source-2.6.33-6.2.src.rpm) ?
- How can the patch be applied ? , its in patch.bz2 format
Project ->
https://build.opensuse.org/package/show?package=r4testdot33&project=home%3A…
Assistance appreciated.
Thanks Glenn
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
Hi list,
todays situation is as follows: libpng12-0 package has two
subpackages, namely libpng3 and libpng-devel. The first one
contains compatibility stuff and seems to be deprecated,
as Christian Rodrígez pointed out yet, so only libpng-devel
is relevant nowdays. libpng3 will be removed from libpng12-0
package.
libpng-devel contains versioned and unversioned stuff, for example
/usr/bin/libpng-config -> libpng12-config
/usr/bin/libpng12-config
/usr/include/libpng12
/usr/include/libpng12/png.h
/usr/include/libpng12/pngconf.h
/usr/include/png.h -> libpng12/png.h
etc.
While we are going to have libpng14-14 with 1.4 branch in addition to
libpng12-0 I am forced to rework this package a bit. We propose
(together with sbrabec) the following:
The pair of main packages containing shared libraries will be
libpng12-0 and libpng14-14 installable in parallel and independently
from other four packages of course.
There will be another pair of packages, libpng12-devel and
libpng14-devel with versioned files (thanks to Jan Engelhardt to
pointing this out). These packages will require libpng12-0 or
libpng14-14 respectively.
The last pair of packages form libpng12-compat-devel and
libpng14-compat-devel containing the common files, like
/usr/bin/libpng-config, /usr/include/png.h, etc. symlinks
and man-pages (maybe we should have -doc package here?). These
packages will require libpng12-devel and libpng14-devel
respectively. BOTH will obsolete and provide libpng-devel symbol
and BOTH will conflict with otherproviders(libpng-devel).
Prefer: libpng14-compat-devel implies:
1. applications using 1.2 version only (-lpng12, etc.) should
require libpng12-devel,
2. applications not checking for libpng version and failing with 1.4
branch should require libpng12-compat-devel,
3. applications building against 1.4 can depend on libpng-devel the
same way as they do till now.
With Prefer: libpng12-compat-devel in prjconf situation would be dual.
One of questions is, if we should Prefer: libpng14-compat-devel or
Prefer: libpng12-compat-devel in openSUSE 11.3.
You can see packages in home:pgajdos:libpng14-14, I am using the
latter Prefer: there. You can notice that spec files for both branches
are the same except for
-%define minor 2
-%define micro 43
+%define minor 4
+%define micro 1
%define branch %{major}%{minor}
-Name: libpng%{branch}-0
+Name: libpng%{branch}-%{branch}
What do you think? Any comments, suggestions, ...?
Petr
Hi, I'm planning to move lilypond from openSUSE:Factory:Contrib to
multimedia:apps and to submit it to factory, to enable multimedia:apps
and factory rosegarden4 to require it. I'm making this announcement
because I've maintainer rights in multimedia:apps and don't want to
unwittingly abuse my privilege. I will wait until Wednesday before doing
this and when it's accepted into factory will disable the factory build
in contrib and delete the binaries leaving only 11.2 and 11.1 available.
Any comments welcome.
Regards
Dave P
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
Hi, I asked how to go about moving lilypond to factory on the packaging list and it was suggested that I ask on this list as well as a
submit request. I've made submit request id 35916 already and here are my reasons :-
I maintain contrib lilypond and multimedia:apps rosegarden4,rosegarden4 should "Require: lilypond" but because lilypond resides in contrib
I can only recommend it in rosegarden because a new user might not have the contrib repo enabled. Lilypond used to be part of the main
distribution and I belive it was moved to contrib due to lack of maintainer. I'm also not sure which devel project it should go to, it's a
musical notation printing program, so I have submitted it from contrib.
See also http://bugzilla.novell.com/show_bug.cgi?id=546120#c6
Thanks
Dave P
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
Hi, I maintain contrib lilypond and multimedia:apps rosegarden,
rosegarden should Require: lilypond but because lilypond resides in
contrib I can only Recommend it in rosegarden because a new user might
not have the contrib repo enabled. Lilypond used to be part of the main
distribution and I belive it was moved to contrib due to lack of maintainer.
How do I go about moving lilypond back to factory? I'm also not sure
which devel project it should go to, it's a musical notation printing
program.
See also http://bugzilla.novell.com/show_bug.cgi?id=546120#c6
Thanks
Dave P
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
Hi all !
Because of bnc#567435 (duplicated symbols in vbox kernel modules) we have to
split kernel packages for virtualbox-ose. Well and this is already done (in
Virtualization repo
https://build.opensuse.org/package/show?package=virtualbox-
ose&project=Virtualization), but we also decide to clean up a spec file a
little. This is also already done, but package needs testing.
We also decide to move virtualbox-ose to Virtualization repo where it belongs.
Just a notice : backported will be only last stable product (11.2 today)
I will switch devel directory from Virtualization:VirtualBox to Virtualization
next week + and I will try to push all changes to Factory. (I want to hit
Milestone 5)
Suggestions how to improve virtualbox-ose.spec in Virtualization repo are
welcome. Preferred way is through the submitrequest :)
bye!
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
Hello,
following up the discussion on upstart and init scripts I'd
like to propose a new policy on shell scripting.
Shell scripting policy
----------------------
/bin/sh can be only expected to support the SUSv3 Shell Command
Language, this allows dash, ksh, and bash to become /bin/sh.
Init scripts should use /bin/sh, but may use /bin/bash with
proper justification, e.g. not just for using ==, [[ ]], or echo
-e which are easily replaced by SUSv3 compliant constructs.
New packages containing scripts using /bin/sh must be tested with
dash as /bin/sh (dash -n/checkbashisms.pl may aid debugging but
are not sufficient by themselves). Any errors should be fixed and
reported upstream.
The rpm specfiles and scriptlets use bash and a GNU userland by
default (I think everything else would be a pain to fix because
of the many bashisms and GNUisms in specfiles).
Rationale
---------
* Choice and diversity are good: the ulimate goal would be to
allow any SUSv3 compatible shell in openSUSE (currently ksh93,
bash, and dash) to be used as /bin/sh
* Quality and Correctness: /bin/sh is not /bin/bash, using other
shells may expose bugs, corner cases etc.
* Speed: bash is slow, allowing scripts to run on other shells
such as dash or ksh93 may lead to speedups in certain
situations
* Portability: allow the re-use of scripts written for openSUSE
on other OS
What other distros are doing
----------------------------
Fedora does not seem to have a policy on shell scripts, according
to the Debian policy handbook (which also applies to Ubuntu)
/bin/sh can only be assumed to support the SUSv3 Command Language
whith three exceptions, those are support of echo -n, test -a/-o
and local. Note that this is not entirely correct, echo -n, test
-a/-o are as XSI extensions part of the SUSv3 just not POSIX.
Implementation
--------------
The implementation of this policy could happen gradually over
time assisted by a new rpmlint check which uses dash -n and
checkbashisms.pl.
In my opinion %_buildshell should point to /bin/bash, simply
because fixing all the bashisms and gnuisms (pushd, popd, ==
etc.) in specfiles would be too much work.
Building packages with dash as /bin/sh may expose bugs in
build systems which will need to be fixed upstream. However,
since Debian and Ubuntu have been doing this for some time, many
issues are likely to be resolved already and there is pressure on
upstream maintainers to fix their scripts.
In the long term /bin/sh could default to dash, choosing ksh93
and bash should remain a possibility through the use of
update-alternatives.
Finally, here is a rough estimate on the scale of the issue:
* on February 22nd the Factory OSS Repository (i586/i686/noarch)
contained 8002 binary packages
* there are 4065 /bin/sh scripts (267 of which are init scripts)
in 1092 packages, furthermore there are 3481 /bin/sh rpm
scriptlets in 1488 packages
* checkbashisms.pl shows warnings for 794 scripts (100 of which
are init scripts) in 372 packets (note that checkbashisms.pl is
not very reliable)
* dash -n leads shows syntax errors in 356 scripts (16 of which
are init scripts) in 111 packages (haowever this does not
detect all errors)
Comments, Suggestions?
--
Guido Berhoerster
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
