Hi,
In CrossToolchain:avr, I see avr-gcc-* and cross-avr-gcc. What is the
difference? What is correct naming? (I suppose the last one).
What guidelines/rules should I follow to create CrossToolchain subproject
for yet unsupported arch?
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
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
Since we moved to systemd completely, I suggest that newly added files
will contain service files - and not init scripts anymore.
So, please only add service files to new packages and if you change your
init file, consider using a service file and dropping the init file,
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
All,
I'm about to submit 6 new small packages: libevt, libevtx, libregf,
libmsiecf, liblnk, libvshadow.
My basic question is what devel project I should send these to and if
I should leave them as 6 discrete projects, or maybe try to combine
them somehow.
I've thought about just pushing all 6 to devel:libraries If that is
a good choice let me know.
== details
All of them are from the same upstream author and have the same
structure, all hosted at the same place etc.
The specfiles are all very similar. For each one there is a c library
created, a python bindings sub-package and a end-user tools
sub-package (eg. evttools, etc.) with a couple simple tools each.
My use case is a security tool that uses the python bindings of all 6,
so in theory I could put them there, but it seems like the wrong place
to me, but the "tools" sub-projects would all actually qualify as
security tools for a forensic examiner. (I already have 15 or 20
forensic tools in the security project, so maybe it is time for me to
create a security:dfir sub-project and just put everything in there?)
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 all and Stanislav,
This week I've tried to implement auto requires/provides for erlang
modules. One of the issues is wx-rpm-stuff specific to openSUSE.
erlang does have wx-bindings package (it is allowed to compile some
C/C++ code and load as build-in functions) and this way its spec
contains disabling of internal dependency generator (and this disables
fileattrs stuff). I can overcome it, and I do understand that there
are strong reasons to implement this specific stuff controlling
different ABI.
However, internal dependency generator is enabled by default in rpm
4.10 and it seems to be powerful tool. Are there plans to adapt
'libwxfoo(variant)' syntax to IDG? Can find-wx-* stuff be implemented
as suse specific patch to /usr/lib/rpm/elfdeps tool?
--
With best regards,
Matwey V. Kornilov
http://0x2207.blogspot.com
xmpp:0x2207@jabber.ru
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi,
Sometimes I want to build a package on my machine, outside obs. The
"build" script worked fine for this, until I upgraded to 12.3. I had to
adapt the sl12.3.conf in /usr/lib/build/configs (libgcc%{gcc_version}
--> gcc%{gcc_version}) but that is no problem. No I am stuck with the
following message:
[ 6s] expanding package dependencies...
[ 9s] Use of uninitialized value within %packs in hash element at
/usr/lib/build/expanddeps line 199.
[ 9s] Use of uninitialized value in concatenation (.) or string at
/usr/lib/build/expanddeps line 199.
[ 9s] Use of uninitialized value within %packs in exists at
/usr/lib/build/expanddeps line 200.
[ 9s] Use of uninitialized value within %packs in hash element at
/usr/lib/build/expanddeps line 199.
[ 9s] Use of uninitialized value in concatenation (.) or string at
/usr/lib/build/expanddeps line 199.
[ 9s] Use of uninitialized value within %packs in exists at
/usr/lib/build/expanddeps line 200.
[ 9s] unsupported url for 'insserv':
This is the result of executing (as root):
build foo.spec
Can someone help, or should I file a bug report?
Thanks,
Cor
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi,
Should there be a general review policy for the obs users who have the
maintainer rights for package/group. I guess there is one for the
opensuse-review team maybe we should have it also for those who are
accepting packages to the devel projects as well.
The reason is I had a declination with a comment why I have not
explained use of %ghost macro in a spec file, but a person who would
have reviewed the rpm buildlogs for the package would realize the fact
that rpmlint gives the following error.
non-ghost-in-var-run (Badness: 1000)
And the mentioning %ghost in changes file in IMHO is nonsense as the
issue has nothing to the with the package but packaging itself and from
the end users point of is just cosmetic.
So maybe it is a good idea to have a document describing what is
required/recommended in the #sr review
Togan
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
During the process of developing my app (used internally) I discovered
a bug in Net-SNMP and provided the fix, which has been accepted.
http://sourceforge.net/p/net-snmp/patches/1240/
The trouble is that our company is reluctant to install stuff that
doesn't come directly from the vendor (even though they will install
_my_ app).
Whats the process for getting an up-stream patch back-ported
into a new package version for SUSE/SLES?
TIA
Fulko
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org