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
I just updated filesystems:ntfs-3g_ntfsprogs to have a new SONAME (83 -> 84)
Do I need to add a Obsoletes: statement?
Greg
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hello,
I am a developer of open source games and I would like to see them in
various Linux distributions.
These games are Plee the Bear http://www.stuff-o-matic.com/ptb/
and Andy's Super Great Park http://www.stuff-o-matic.com/asgp/
Both are available under the GPL 2 and CC by-sa licenses. The source
code is available on their respective websites.
Would you accept to package these games for OpenSUSE ?
Best regards,
Julien Jorge
Stuffomatic
P.S.: I am not registered on the mailing list so please CC me in your
responses.
--
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'm going to update some PEAR packages from server:php:applications .
Do we have a better way of defining dependencies other than inspecting
the bundled package.xml and then updating the spec file? The Packaging
PHP page [1] is silent on this topic.
I know we a nice gem2rpm helper for Ruby packages and something
similar for PEAR modules would be quite nice.
Robert
[1]: https://en.opensuse.org/openSUSE:Packaging_PHP
--
http://robert.muntea.nu/
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Dear sirs,
Our company is software developer.
Our software is proprietary RDF database.
We would like to include our software package in the official Linux distribution repository.
What do we need for this? A special license? Should we open source codes?
Best regards, Dmitry
Head of Department system administration
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
All,
I need to have a pre-compile test that only runs if it is a local
build. How do I do that?
== details
I maintain one package (python-plaso) that comes with a optional
pre-compile test module to verify that for 6 specific libraries the
latest available libraries are installed prior to building.
It's a python script that looks on the Internet for the latest
available tarballs for the 6 libraries.
LIBYAL_URLS = {
'libevt': 'https://googledrive.com/host/0B3fBvzttpiiSYm01VnUtLXNUZ2M/',
'libevtx': 'https://googledrive.com/host/0B3fBvzttpiiSRnQ0SExzX3JjdFE/',
'liblnk': 'https://googledrive.com/host/0B3fBvzttpiiSQmluVC1YeDVvZWM/',
'libmsiecf': 'https://googledrive.com/host/0B3fBvzttpiiSVm1MNkw5cU1mUG8/',
'libregf': 'https://googledrive.com/host/0B3fBvzttpiiSSC1yUDZpb3l0UHM/',
'libvshadow': 'https://googledrive.com/host/0B3fBvzttpiiSZDZXRFVMdnZCeHc/',
}
I maintain all 6 of those too, so when I build python-plaso locally,
I'd like it to bark if those are out of date.
Alternatively, there are about 25 similarly structured libraries
(libyal - yet another library). What would need to be done for the
auto-version checker for factory to notice there is a new tarball and
put in my routine factory status email? (That may already work, the
download tarballs being hosted on a googledrive is something that just
started a few months ago and I am just now updating the DL_URL fields
in my spec files.
Greg
--
Greg Freemyer
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Why does rpmlint consider 0~20130416 older than 0.0.0+20130128 ?
Does RPM/zypper have the same logic?
Is there some way to do a rename (Obsoletes / Provides) to move from
0.0.0 versioning to 0 versioning?
== details
I've got a package that has been in 12.2 and 12.3 named as: ewftools
v0.0.0+20120813. It is currently in factory as v0.0.0+20130113
It's part of a library toolset known as libyal. (about 20 libyal
packages in factory now).
When the rest of the libyal packages were created post 12.3 they were
versioned like libyal-tools v0~20130416, so I'm trying to update the
libewf package to create a libewf-tools package that will supersede
the old ewftools package
Thus I added:
Obsoletes: ewftools <= 0.0.0+20130128
Provides: ewftools = %{version}
But rpmlint is complaining:
libewf-tools.i586: W: self-obsoletion ewftools <= 0.0.0+20130128
obsoletes ewftools = 0~20130416
Greg
--
Greg Freemyer
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hello all,
openSUSE 13.1 Milestone 4 will be released next week, on
Thursday 08 August 2013.
Please submit your packages before Friday afternoon (UTC time) to make
sure they will get included in this release. Leaf packages submitted
during the week-end might also get accepted on Monday.
For a quick overview of the openSUSE Roadmap, please see:
http://en.opensuse.org/Roadmap
Thanks,
--
openSUSE Roadmap Reminder
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org