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
As per https://bugzilla.novell.com/show_bug.cgi?id=793541 it seems
CodeAnalyst needs a new maintainer. Any volunteer?
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi:
I will no longer maintain fix or otherwise care about the "at" daemon,
starting now because I would rather devout my time testing and improving
systemd.timer(5)
So it is now up for grabs.
that's all ;)
--
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
This time I didn't report the new problems. Simply we are in Christmas and
people is less active. But just in case somebody feels like fixing something,
here is the list.
In any case the list is too long,
We have six build failures because sblim-sfcb removed its /etc/init.d/sfcb file
to use only Systemd and those packages restart the service in the scriplets.
Then there are also a few C# failures. And the classic failures from the
kernel update.
Name Devel Project Bug report Status
- selinux-policy security:SELinux bnc#789160 Fails for 136 days: error(s) encountered while parsing configuration (Request 145734 to openSUSE:Factory)
- hawk network:ha-clustering:Factory bnc#789165 Fails for 95 days: cannot load such file -- gettext/tools/rgettext (rails 2 vs rails 3?) (Request 146273 to openSUSE:Factory)
- psi network bnc#789178 Fails for 85 days: error: 'OtrlMessageAppOps' has no member named 'notify' (Different changes in devel project (since 15 days))
- gnome-do-plugins GNOME:Apps bnc#789193 Fails for 85 days: Type `FlickrNet.FoundUser' does not contain a definition for `Username'
- qutim KDE:Distro:Factory bnc#789195 Fails for 85 days: libotr update
- f-spot GNOME:Apps bnc#789196 Fails for 85 days: The type or namespace name `Licenses' could not be found
- pcsc-asedriveiiie-usb security:chipcard bnc#793542 Fails for 52 days: /usr/lib/udev/rules.d/*.rules not found
- ksymoops Base:System bnc#793544 Fails for 47 days: #error config.h must be included before this header
- excalibur Java:packages bnc#793551 Fails for 47 days: error: method checkPackage in class Component cannot be applied
- postgresql server:database:postgresql bnc#793553 Fails for 45 days: timezone package needed for timezone (Different changes in devel project (since 3 months))
- libzypp-bindings zypp:Head bnc#793554 Fails for 45 days: test suite fails
- webyast-base YaST:Web bnc#793558 Fails for 40 days: No such file or directory - /var/lib/polkit-1/ (Request 146369 to openSUSE:Factory)
- libimobiledevice mobile:synchronization:FACTORY bnc#796133 Fails for 25 days: Overriding final methods is not allowed
- compiz X11:Compiz bnc#789161 Fails for 19 days: kwin 4.10
- mono-tools Mono:Factory Fails for 18 days: error CS1061: Type `Mono.Cecil.Cil.ExceptionHandler' does not contain a definition for `FilterEnd' (Different sources in devel project (since about 1 month))
- nant Mono:Factory Fails for 18 days: missing framework mono
- gnome-do GNOME:Apps Fails for 18 days: error CS0012: The type `Do.Platform.Linux.IConfigurable' is defined in an assembly
- gbrainy GNOME:Apps Fails for 18 days: error CS1729: The type `Mono.CSharp.Report' does not contain a constructor
- docky GNOME:Apps Fails for 18 days: Assuming assembly reference `Mono.Cairo
- libvirt-cim Virtualization Fails for 18 days: /etc/init.d/sfcb: No such file or directory (Systemd port)
- sblim-cmpi-ssh_service_profile systemsmanagement:wbem Fails for 18 days: /etc/init.d/sfcb: No such file or directory (Systemd port)
- sblim-cmpi-power_supply_profile systemsmanagement:wbem Fails for 18 days: /etc/init.d/sfcb: No such file or directory (Systemd port)
- sblim-cmpi-fan_profile systemsmanagement:wbem Fails for 18 days: /etc/init.d/sfcb: No such file or directory (Systemd port)
- sblim-cmpi-ethport_profile systemsmanagement:wbem Fails for 18 days: /etc/init.d/sfcb: No such file or directory (Systemd port)
- sblim-cmpi-boot_control_profile systemsmanagement:wbem Fails for 18 days: /etc/init.d/sfcb: No such file or directory (Systemd port)
- smuxi GNOME:Apps Fails for 18 days: error CS0305: Using the generic type `System.Action<T>' requires `1' type argument(s) (New upstream version 0.8.10.12100 available)
- perl-Sys-Virt Virtualization Fails for 17 days: libvirt >= 1.0.0 is required
- atspiuiasource Mono:Factory Fails for 17 days: Warning as Error: Assuming assembly reference `WindowsBase
- uiadbus Mono:Factory Fails for 17 days: Warning as Error: Assuming assembly reference `WindowsBase
- uiaatkbridge Mono:Factory Fails for 17 days: Warning as Error: Assuming assembly reference `WindowsBase
- uiautomationwinforms Mono:Factory Fails for 17 days: Warning as Error: Assuming assembly reference `WindowsBase
- xerces-j2-bootstrap openSUSE:Factory Fails for 13 days: the typical java one
- python-nose devel:languages:python Fails for 10 days: assert 'test_timeout' in log
- haveged security Fails for 10 days: failing test suite (Request 146266 to openSUSE:Factory)
- ImageMagick graphics Fails for 10 days: failing test suite
- calibre Documentation:Tools Fails for 9 days: /etc/bash_completion.d/calibre not found (Different changes in devel project (since 3 days))
- bundle-lang-gnome-extras openSUSE:Factory Fails for 9 days: dia graphs are missing
- libwebkit3 openSUSE:Factory Fails for 9 days: Installed (but unpackaged) file(s) found:
- _product:openSUSE-ftp-livetree-gnome-i586 Fails for 9 days: outdated lists
- _product:openSUSE-ftp-livetree-gnome-x86_64 Fails for 9 days: outdated lists
- kernel-vanilla openSUSE:Factory Fails for 8 days: worker ran out of disc space (Request 146394 to openSUSE:Factory)
- gstreamer-0_10-plugins-bad multimedia:libs Fails for 8 days: error: expected ')' before '__attribute__'
- iscsitarget hardware Fails for 8 days: Kernel 3.7
- hdjmod hardware Fails for 8 days: Kernel 3.7 (Request 146314 to openSUSE:Factory)
- ndiswrapper hardware Fails for 8 days: Kernel 3.7
- virtualbox Virtualization Fails for 8 days: Kernel 3.7
- xtables-addons security:netfilter Fails for 8 days: Kernel 3.7 (Request 146265 to openSUSE:Factory)
- coreutils-testsuite openSUSE:Factory Fails for 8 days: broken spec
- cogl GNOME:Factory Fails for 8 days: compiling docu fails (libxml?)
- ibus M17N Fails for 8 days: compiling docu fails (libxml?)
- installation-images system:install:head Fails for 7 days: no such package: libnl-*
- libdlm network:ha-clustering:Factory Fails for 7 days: Unknown build failure
- gdome2 GNOME:Apps Fails for 7 days: Unknown build failure
- yast2-installation YaST:Head Fails for 7 days: Unknown build failure
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hello everyone,
as you know, we're recently formed a team that will take care of the
packaging guidelines and introduced a small process to change them:
http://en.opensuse.org/openSUSE:Packaging_guidelines_change_process
I would like to start discussion about Common Lisp and create Lisp
packaging related rules.
The first version of it you can find there:
http://en.opensuse.org/openSUSE:Packaging_Lisp
(please discuss here before edit something in wiki)
I don't know how many Lisp developers we have, but I invite everybody
to find and create most interesting, correct and optimal packaging
rules for openSUSE distribution.
Alex
--
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,
I just filed an SR for "up-imapproxy" against server:mail. This is an
updated and enhanced version of the specfile as original created by
upstream and modified by Peer Heinlein of Heinlein Support.
I'd like to have the server there to gradually improve the packaging
up to distribution quality and submit it. I'm open to instead mentor
newcomer maintainers on this package if they want to try. Some of the
additions to the startup script (which should become a systemd file at
some point) should go upstream if possible. But not before 2013 ;)
rlang@rl-desktop:~/obs/home:ralflangb1:branches:home:pheinlein/up-imapproxy>
osc sr server:mail up-imapproxy
Warning: failed to fetch meta data for 'server:mail' package
'up-imapproxy' (new package?)
created request id 146437
- --
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/
iEYEARECAAYFAlDbQJgACgkQCs1dsHJ/X7APQACg144jaB4y+r0hXGejqWFrty4v
ozgAnRefZ7dF9X+Jw4vv6xvo+PyFE2YT
=0LcO
-----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
Hi,
I'd like to submit a trivial mr to fix bnc #780243 [1].
I've looked at the maintenance docs from [2] but I am missing a step.
I've branched the package and have my own 12.2_Update repo, but the
fixes are in the devel:languages:python repo.
Do I just manually sync the sources between the devel repo and my
update repo or is there another way?
Thanks,
Robert
[1]: https://bugzilla.novell.com/show_bug.cgi?id=780243
[2]: http://en.opensuse.org/openSUSE:Package_maintenance
--
Sent from my (old) computer
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi all,
during compilation of the changes in packaging wiki, I have found one
unclear thing, which resulted in the removal of
Category:Packaging_documentation from two pages. But the fault belongs
to us, because we did not make clear the following
Category:Packaging_documentation is the **official** one and should be
added only as a result of the review here on a list. The current
phrasing
"""
Each page should have a
[[Category:Packaging documentation]]
"""
is confusing. I dislike the naming of the category as well. At the moment we have
two mostly overlapped packaging categories.
Category:Packaging documentation with 34 pages
http://en.opensuse.org/Category:Packaging_documentation
Category:Packaging with 38
http://en.opensuse.org/Category:Packaging
The Category documentation is intended to be the official and reviewed
one, but I consider the naming extremly confusing. For that reason, I
propose following
1. Create Category:Packaging_guidelines - this makes the purpose of the
category clear
2. Document this category is the **official** one - on Category
description page, either on guidelines change page
3. Put things, are reviewed to the category
I'm afraid only Lua guidelines can be moved, atm
4. Request the addition of things from _documentation to _guidelines
this will be long-term process, because for a sanity of us, only few
pages should be reviewed on this ML
5. Once finished, drop the _documentation category
BTW: I'm volunteer for the category moving process, but it will be
better if it can be requested by interested people.
Waiting on your feedback
Michal Vyskocil