Dear Factory contributors and packagers,
As openSUSE 12.2 is frozen and Factory is 'open to go wild' again, I
would like to announce that the packaging guidelines have some
extensions (not really new) that will be stricter enforced than they
used to be.
Currently a common rule to be 'ignored' or packagers are not aware is
around the topics of:
- .Changes entries
- Patches
First, the .changes entry (rpm changelog) surves two purposes:
- News for the user
- History tracking of packaging changes (often referenced in bugs to
verify if a user has the latest packaging bugfixeS).
A simple "Update to version x.y.z" is, as before, not accepted. There
should be some buzz around the update for the user; some major reasons
to the upgrade should be listed
Changes on the package itself should be mentioned in a way that any
other contributor to the same package can follow traces of why
something is the way it is. Commonly, Added (build)dependencies are
interesting to be seen, special hacks to make something work in a
particular way [..]: Always consider that package maintenance is a
distributed task and various contributors need to be able to step up
at will.
Patches:
The rules about patches are listed at
http://en.opensuse.org/openSUSE:Packaging_Patches_guidelines .
Most prominent is likely the mentioning of the patches life cycle,
which forces you to mention additions and removals of patches in the
changelog. As history shows, this can be helpful if a patch got
removed, and later a regression is reported; finding out when a patch
was removed can be crucial in reconstructing feature sets (including
contacting the contributor that dropped it.. which is easily extracted
from the .changes if listed)
The main appeal is to the devel project maintainers / reviewers, to
keep out for those rules, to live according to them, as it is
frustrating for everybody if a package needs to be declined by the
Factory Review team:
- The dev prj maintainer is the one getting the 'decline' (as it was
usually a forwarded request), which often leaves the 'fixing' to the
devel project maintainers, where the 'originator' of the fix would
have been willing to actually do that...
And the Factory Review team also prefers to see complying submissions
to having to reject SRs... reject is not fun for anybody!
Looking forward to many more SRs to accept!
Dominique / DimStar
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
All,
I sent the httrack package to security a couple weeks ago. It builds,
but with a few rpmlint issues.
I thought I would clean up the one about the shared library needing to
be split out to its own package.
I've tried to do that in home:gregfreemyer:branches:security > httrack
The diff is:
https://build.opensuse.org/package/rdiff?opackage=httrack&oproject=security…
I've tried multiple ways to call ldconfig.
But my build always fails with:
[ 218s] libhttrack2.x86_64: E: library-without-ldconfig-postin
(Badness: 300) /usr/lib64/libhtsjava.so.2.0.46
[ 218s] libhttrack2.x86_64: E: library-without-ldconfig-postin
(Badness: 300) /usr/lib64/libhttrack.so.2.0.46
[ 218s] This package contains a library and provides no %post
scriptlet containing a
[ 218s] call to ldconfig.
The spec file currently has:
===
%post
/sbin/ldconfig /usr/lib64
%postun
/sbin/ldconfig /usr/lib64
===
I've tried the basic versions as well.
==
%post -p /sbin/ldconfig
%postun -p /sbin/ldconfig
==
%post
/sbin/ldconfig
%postun
/sbin/ldconfig
==
Can anyone tell me what's going on?
Thanks
Greg
--
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 looking for new maintainers for these two packages:
devel:libraries:c_c++/libgsasl
This is the GNU SASL library. It's used by a few packages, is alive
upstream with a nice maintainer. I only touched this package because
another packages I was working on was using it, and inherited from
maintenance this way. But I really don't look at it, so I feel it
could do with more love.
hardware/festival
This is a speech synthesis system. I'm not quite sure how much it's
still used; it used to be a dependency for GNOME accessibility (which
is why I somehow became maintainer, I guess), but it's not used there
anymore.
I'm happy to give magical powers to anyone willing to take over those
packages :-)
Cheers,
Vincent
--
Les gens heureux ne sont pas pressés.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
With the upcoming release of Horde 5 Groupware,
I am going to replace all horde-related framework packages in
server:php:applications with their 2.0 counterparts and all horde apps
with their horde 5 versions.
I won't maintain horde 4 in server:php:applications any further, apart
from security related updates in released and maintained opensuse
versions. I will probably stage/bootstrap these upgrades in a separate
repo first.
This will mostly affect users of SLES 11 and SLES 11 SP1 who used
server:php:applications as their source repository for Horde 4 apps.
If there is anything to discuss first, please answer to this list.
- --
Ralf Lang
Linux Consultant / Developer
Tel.: +49-170-6381563
Mail: lang(a)b1-systems.de
B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iEYEARECAAYFAlCJJmcACgkQCs1dsHJ/X7ADQACfbRB+tnLkhx3Z2S8gJ0EMGKwJ
LzMAnAmIcpPD/ICDXD8XoBJUv6TFj+cE
=dU34
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
8 years
2
3
by Cristian Morales Vega
The following packages have been failing to build on Factory for more
than 30 days. This is a reminder for anybody that could be interested
in any of them. Any package failing to build for more than 100 days
will be dropped from openSUSE.
- libgcj43 Fails for 277 days: undefined reference to `__cxa_call_unexpected'
- elilo Fails for 92 days: undefined reference to
`__stack_chk_fail_local' (New upstream version 3.14 available)
- opensuse-manuals_ru Fails for 86 days: java 1.7 breaks it
- selinux-policy Fails for 74 days: error(s) encountered while parsing
configuration (Different changes in devel project (since 6 months))
- libgcj41 Fails for 47 days: java test cases...
- compiz Fails for 44 days: kwin changes
- kdegraphics3 Fails for 42 days: gphoto update (Current sources were
declined: request 138654)
- xerces-j2-bootstrap Fails for 33 days: temporary failure
- hawk Fails for 33 days: cannot load such file --
gettext/tools/rgettext (rails 2 vs rails 3?)
- python-tagpy Fails for 33 days: taglib update
- rubygem-webyast-time Fails for 31 days: Missing partial
shared/online_help (Different changes in devel project (since 23
days))
- ccscript3 Fails for 30 days: undefined reference to `main' (Request
139531 to network:telephony)
- iscsitarget Fails for 30 days: kernel 3.6
This is a test. Please give some feedback. Anything to improve? Did
this email actually helped you?
The email was sent BCC to the package maintainers I could identify. I
couldn't identify one clear one for ccscript3 and sent it to the
latest .changes entry.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Looking at our packaging policies, I see nobody nobody currently
taking care of it and no real process to change them and make those
changes known.
So, I'd like to propose the following:
* Introduce a simple process for changing the policies, e.g.:
- send an email to opensuse-packaging with a proposal for change
- discuss change
- if change gets accepted by packagers and reviewers:
+ update the wiki pages
+ send an email to opensuse-announce about the change (we can also
collect a couple of smaller changes and only send this out once
a while)
* I suggest to form a small team that guides the process and decides
if there is no consensus - and better formulates the process.
Any better ideas?
Who likes to join the team and help shaping the packaging policies?
Andreas
--
Andreas Jaeger aj(a){suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi,
For sometime I have been trying to get racket [1] to build and after a
long fight I manage to get it building and working on openSUSE 12.1 and
Factory but for some reason I can't figure out why it fails to build for
openSUSE 12.2
Help is appreciated as I intent to submit it to devel:languages:misc and
hopefully into factory
Togan
[1] <http://www.racket-lang.org/>
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Dear all,
I could use some input for a progam I packaging at the moment, which requires
two system variables to run.
1. path to binaries
The documentation says, that /usr/local/program/bin/ needs to be in the PATH -
variable.
That shouldn't be needed, if those binaries are installed into "/usr/bin" by
the package.
If that doesn't work, I'll use links from "/usr/bin/"
2. path to libraries
Looks like this is needed:
MYLIBPATHVAR is required to point to the library of the program in
"/usr/lib/program/lib/" or "/usr/share/program/lib/"
How do I introduce a new system wide environment variable - available for all
users?
3. Compiler options for optimization
to improve the performance of the program, the compiler could get some
performance settings like
-O3 -mtune=corei7 -march=corei7
etc. to get the full capability for calculations (sse4.2).
How does that effect the packaging? Do I need to splitt off a -SSE3/4 package
and how does that work?
Could somebody point me to some wiki page / sample package to see how to
achieve that?
You'll see the package in obs
https://build.opensuse.org/package/show?package=radiance&project=home%3Alum…
cheers,
Denny
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
All,
I think Requires and BuildRequires are disjoint / independent.
I have a package that has about 20 Requires. I'd like to have a
%check section for it, but I'll need all those requires at build time
as well to do that.
Is there a clean solution?
Thanks
Greg
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
