Hello!
I would like to discuss here one aspect of our changelog policy.
Unlike other distributions, we have an unusual rule for our RPM changelogs
(.changes file): when updating to the new version, we must process an upstream
changelog and copy the most important things to RPM changelog. I would like to
discuss this policy and its problems and benefits.
When this policy became effective, I have heard about two reasons for doing it:
1. Maintainer who does the update is aware of the changes in upstream.
2. We have easily accessible information about upstream changes.
As for the first plus, yes: Maintainer is really pretty well aware of all the
information because he not only reads the changelog, but he also spents a great
amount of time copying it, pasting it, trying to shrink it as most as possible,
reformatting it and so one. I do not want to speak for other packagers (their
stories might follow), but I have spent countless hours tweaking my scripts for
automagical processing the changelogs and although it saved me loads of time,
it is the only thing I regularly have to fix manually during my otherwise
automatical perl module updates. It is boring and IMHO completely useless work
that costs us lots of time that we could spend on hacking something useful.
As for the second plus, I am not aware that anyone uses this information. AFAIK
we have no tool to present it to our users in a neat way. It is even not a part
of the package metadata, so if you want to get it, you must get the complete
package - and if you got the package, you can equally easily see upstream
changelog with the same information, that you could get from the changelog.
Sure, you might say that we should use RPM changelogs just for the most
important changes to save our users time of searching for them. But a brief
look at our packages shows that we are not doing it and usually we even cannot
do it - how to pick up the most important changes from 30 minor bugfixes? How
to pick them from a loads of new features in a new major version? We can either
duplicate the changelog (usually unfeasible) or randomly pick up some news
(this is my most usual choice) to make our policy happy.
In fact, when you are interested in upstream changes, in almost every case it
is more useful to take a look to upstream changelog because it is complete and
better structured. When you are interested in specfile changes instead, you
cannot just read them, you have to skip tons of useless information from
upstream changelog - in fact, even when there is no upstream changelog, it
would be better to maintain some as a patch than to pollute RPM changelog with
a noise.
I think that we spent countless hours of time working on something that no one
is interested in. Even its very presence might be annoying in some cases.
Should we really continue doing it? Would not be better to just go back several
years and start to do it like others do it?
Reference:
http://en.opensuse.org/SUSE_Package_Conventions/Changelogs#11.4_Sourcecode_…
Anicka
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
Hi,
We just got 7 packages in GNOME:Factory that broke because the
project.diff files don't apply anymore: the packages were all updated in
Factory. It's not the first time it happens, and I'm sure each time it
happens, the person doesn't think it will break anything. But sometimes
it does :/
Don't get me wrong: I'm really happy to see people contributing to the
packages the GNOME team maintains, and especially when it comes to
cleaning up things -- it makes the world a better place. But it'd be
really nice to submit all updates to GNOME:Factory first. I think
Mozilla:Factory was hit by this issue in the past too, and I'd guess
other projects too.
So, please, think about the pain that people feel when they have to
handle those manual merges, and use the devel projects.
Thanks,
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
Hi,
I compared a Fedora Packaging Guidelines [1] and SUSE Packaging Convetions [2]
and I think that Fedora documentation is really better than we provide. It's
not only about amount of information, but mainly in structure of it. For
example if we want to read about License policy in SUSE and start on Packaging
page [3] - how can user get from this page to equivalent of Licensing
guidelines [4]? Fedora way is Packaging -> Packaging/Guidelines ->
Packaging/LicensingGuidelines
Or another example - is really necessary talk about BuildService account on
packaging cookbooks of KDE[5] or Java[6]? In fact with this structure, where
they exists outside Packaging/ it makes a sense, but it's really necessary?
If we want to help a community to participate on openSUSE (for example
packaging in Contrib) we also need a better documentation than we have.
So main questions are:
- how could be Packaging/ maintained (eg. we would have a Docbook original
somewhere and convert it to wiki as SUSE packaging conventions [2])?
- how could we structure existing information to be more readable and useful
for community?
- what is missing, or unclear and needs to be improved?
(- and who will do this all ;-))
[1] http://fedoraproject.org/wiki/Packaging:Guidelines
[2] http://en.opensuse.org/Packaging/SUSE_Package_Conventions
[3] http://en.opensuse.org/Packaging/
[4] https://fedoraproject.org/wiki/Packaging/LicensingGuidelines
[5] http://en.opensuse.org/KDE/Packaging/Cookbook
[6] http://en.opensuse.org/Java/Packaging/Cookbook
Regards
Michal Vyskocil
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
When we freeze our package versions, new upstream translations are not
updated any more. Some of our products have a long life cycle. It would
be nice to get translations updated from upstream with a minimal effort.
It's the purpose of translation-update-upstream: new package and tool.
It's now in Factory and first 94 packages are waiting for submit review.
FAQ
===
Q: How it works?
A: It features an updater: a simple tool to update the translation
during initial phase of compilation, and the translation collection
tool, which collects new or changed strings from one or more upstream
resources (versions, branches) using the configuration file (it's called
manually outside Build Service and the result is submitted).
Q: How you can add its support?
A: Edit your spec file: Simply add translation-update-upstream to
BuildRequires and call translation-update-upstream as a first action of
build after %setup. Then you need to configure
translation-update-upstream to point to the correct upstream resources.
For more see the translation-update-upstream package HOWTO and the
source package.
Q: Why is this needed? Don't we get translations in upstream tarballs
already?
A: Our packages freeze few months before openSUSE release and then they
are maintained for years in SLE. Providing a way to backport
translations into frozen versions is very welcome.
Q: Why a new package? Isn't translation-update sufficient?
A: It is sufficient for translations provided in-house. In case of
upstream translations, our translators have no control over the
translation. We need a way to override upstream mistakes or errors. But
translation-update package overrides everything already done forcing
back the upstream version.
Q: Why to do in compile time?
A: It is possible to do the same in using the translation override
directory. But it has few disadvantages:
- It would introduce strict packaging policy:
- No translation fixes in spec files would be possible.
- All translation fixes would be done via translation override
package.
- Increases installations size.
We do this only for translations provided in-house.
Q: Shouldn't it be better to push translations and fixes upstream?
A: In general, yes. But most upstream maintainers care just about the
latest stable branch. Who will care about GNOME 2.12 translation in
upstream five years from now on?
Q: Why not use bundle-lang package?
A: You don't know source of each particular string in the bundle-lang.
It may come from upstream, from a fix, from a patch. Only upstream one
may be replaced by the update tool.
In fact, translation-update-upstream works well with bundle-lang
package. translations from the build process may get into the
bundle-lang package, if the current processes defines so.
Q: Does it replace po tarballs in spec files?
A: Only those that come from upstream. But it may be technically
possible to define Novell LCN as an additional data source.
Q: Does it provide 100% translation?
A: No, it does not. Only strings that were present and translated in any
of newer upstream versions can be provided. Making them 100% complete
still may require translators' action.
Q: Why we need to pollute openSUSE, if this feature is interesting only
for SLE?
A: Such large change cannot be done in late beta or rc phase. It must be
ready as soon as possible, only translation data file updates will have
to be done in the rc phase.
Q: What translation files do we have?
A: We have:
- translations from upstream (in tarball)
- translations of strings in patches (e. g. in gnome-patch-translation)
- fixes for upstream translations (provided by our testers or Novell LCN
team and added in patches or additional tarballs)
Now we will have also:
- backported upstream translations
Q: Isn't it best to modify OBS to support this?
A: No:
- The tool has to have access to network.
- String collecting may require manual intervence in case of upstream
errors.
Q: Wouldn't it be better to modify %setup?
A: No:
- It would bring additional "magical" divergence from upstream.
- Things may need tuning (e. g. for non-standard po directories)
Q: Why not just pick upstream translations and put them in tarball?
A: It needs to be handled manually per package.
translation-update-upstream is a more sophisticated tool: It searches in
all equal or later branches in the upstream SVN and merges everything
usable in the old version automatically, once it is set up.
Q: Do I need to call autoreconf?
A: No, you don't. translation-update-upstream patches configure as well.
Q: Does it run during each build?
A: Only fast string merge runs during each build. It It uses pre-built
tarball in translation-update-upstream and leaves following traces in
the build log:
Updating or.po using translation-update-upstream.
Upstream string collect and compare needs several hours. It is started
manually outside Build Service time after time.
Q: It would perhaps add something extra to OBS, preferable onyl for SLE,
but if I build the package locally with rpmbuild it wouldn't affect
anything.
A: No. Both use the same rpmbuild. Anything in macros affects all
packages. It's cleaner to behave consistently, even at cost of one
additional line.
Q: It fails. What to do now?
A: You can see following failures:
can't open ./../foo: No such file or directory at /usr/bin/intltool-extract line 212.
xgettext: error while opening "../foo" for reading: No such file or directory
Most of them are upstream bugs: They forgot to package some files from
their repositories resp. they based their translation on an
auto-generated file.
It can be considered as a bug, which can be fixed by adding a proper
file to the tarball, dropping from POTFILES.in resp. using a proper
source file.
Upstream should be able to find such bugs by "make distcheck".
Q: What is the relation to gnome-patch-translation.
A: gnome-patch-translation provides patches from SuSE specific stuff in
patches. translation-update-upstream provides translation for upstream
things. You can use both tools in a single package. Just call
translation-update-upstream first, then gnome-patch-translation-prepare.
Transition info:
If the submit conflicts with your work, feel free to disapprove it and
do it on your own or let me know. The project.diff is really simple.
References (restricted access):
Feature #301344: Wants a better way to update translations
bnc#377971: describes that translation-update packages are always
overwriting original translations.
--
Best Regards / S pozdravem,
Stanislav Brabec
software developer
---------------------------------------------------------------------
SUSE LINUX, s. r. o. e-mail: sbrabec(a)suse.cz
Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747
190 00 Praha 9 fax: +420 284 028 951
Czech Republic http://www.suse.cz/
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
Hey,
I was wondering... Right now, we do something like:
%doc README AUTHORS ChangeLog NEWS
in all packages.
However, we certainly forget about some of those files and we also
include empty files there (by accident).
Would a macro that helps with this be a good idea? It could work like
this:
+ in %install
%find_package_doc
cat %{name}.package_doc >> %{name}.lst
+ and then %files:
%files -f %{name}.lst
%find_package_doc would look for the common files (README, AUTHORS,
MAINTAINERS, ChangeLog, NEWS, COPYING, COPYING.LIB, TODO, etc.) by
checking their existence and checking they're not empty. And it would
output what it finds in %{name}.package_doc.
It could take additional arguments if people want to check for
additional filenames or ignore some specific files.
Opinion?
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
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
Just an advice for whoever is packaging inkscape. It should be possible
in the spec file just to make BuildRequires: libwpg-devel and inkscape
could have a capacity to open WPG (WordPerfect Graphics) file-format.
Libwpg will not be such a huge dependency since it basically does not
depend on anything but libstdc++ on runtime and OpenOffice.org already
uses it, so it is surely installed on ~90% of our installations.
Cheers
Fridrich
(BTW, also libwpg upstream maintainer :) )
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iEYEARECAAYFAkmmuyUACgkQu9a1imXPdA+P9QCeLfCFFfbH/OfvLRm6xAHF7bQo
q94AoILBBFgia2b6GrDalLlyOv4+gEBS
=RQ4F
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
Hello Mates,
actually im working on the Packes libatlas3 and kde4-skrooge (Project:
home:saigkill).
RPMLint says:
libatlas3.x86_64: E: devel-file-in-non-devel-package (Badness: 50)
/usr/lib64/libatlas.so
libatlas3.x86_64: E: devel-file-in-non-devel-package (Badness: 50)
/usr/lib64/libcblas.so
libatlas3.x86_64: E: devel-file-in-non-devel-package (Badness: 50)
/usr/lib64/libf77blas.so
This i don't understand. I thought, that only *.h Files included in -
devel Package. And here RPMLint would like to move the so's to devel.
Anyone understand this?
--
Sincereley yours
Sascha Manns
openSUSE Marketing Team (Weekly News)
openSUSE Build Service
Web: http://saschamanns.gulli.to
Blog: http://lizards.opensuse.org/author/saigkill
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
Hi everybody...
I guess -packaging might be the best list to ask for this.
Situation:
We have libproxy in factory. libsoup depends on it. libproxy is enhanced with several plugins, which are installed by using 'Supplemnts:packageand()
tags. (package openSUSE:Factory/libproxy)
Everything works fine (so far)... now the tricky part:
libsoup exists as libsoup-32bit package (for compatibility).
It requires libproxy, thus it was created as baselib -> libproxy0-32bit
Not the real problem: how to get all the plugins also installed together with libprox0-32bit? And how to have their Supplements: tag correctly
updated?
Example:
libproxy0-gnome has
Supplements: packageand:libproxy0:gconf2)
which results that libproxy0-gnome-32bit should get
supplements: packageand(libproxy0-32bit:gconf2-32bit)
Any tricks on how to achieve this ?
Dominique
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
Aloha all,
I have been having issues for quite some time now trying to package my
beloved bongo on >=11.0.
It goes fine on 10.3 but on anything newer I get:
+ exit 0
... checking for files with abuild user/group
... running 00-check-install-rpms
... installing all built rpms
Preparing packages for installation...
bongo-snapshot-debuginfo-0.4.0svn1009-1.1
bongo-snapshot-debugsource-0.4.0svn1009-1.1
libbongo-snapshot-import-0.4.0svn1009-1.1
bongo-snapshot-data-0.4.0svn1009-1.1
libbongo-snapshot-0.4.0svn1009-1.1
python-bongo-snapshot-0.4.0svn1009-1.1
libbongo-snapshot-dev-0.4.0svn1009-1.1
bongo-snapshot-0.4.0svn1009-1.1
chown: invalid user: `bongo'
bongo-snapshot-mta-0.4.0svn1009-1.1
bongo-snapshot-web-0.4.0svn1009-1.1
... running 01-check-debuginfo
... testing for empty debuginfo packages
... running 02-check-gcc-output
... testing for serious compiler warnings
(using /usr/lib/build/checks-data/check_gcc_output)
(using //.build.log)
E: bongo-snapshot 64bit-portability-issue
src/libs/cal/bongo-cal-object.c:262
E: bongo-snapshot 64bit-portability-issue
src/libs/cal/bongo-import-tz.c:41
E: bongo-snapshot 64bit-portability-issue
src/libs/msgapi/msgcollector.c:435
My spec file has:
%pre
#Add the bongo user & group
/usr/sbin/groupadd -r bongo 2> /dev/null || :
/usr/sbin/useradd -r -g bongo -s /bin/false -c "Bongo Mail daemon"
-d /etc/bongo bongo 2> /dev/null || :
%post
#Ensure that the data directory has the correct ownership permissions
chown -R bongo /var/bongo
%fillup_only bongo
%preun
%{stop_on_removal} bongo
%postun
%{insserv_cleanup}
Is this correct?
Many thanks for your help.
Andy
--
Andrew Wafaa, openSUSE Member: FunkyPenguin.
openSUSE: Get It, Discover It, Create It at http://www.opensuse.org
awafaa(a)opensuse.org | http://www.wafaa.eu
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
Package: kde4-skrooge
Project: home:saigkill
Hello Mates,
the last build was suceeded, but now i'm see an expansions Error. Has
anyone an idea, how to fix it?
--
Sincereley yours
Sascha Manns
openSUSE Marketing Team (Weekly News)
openSUSE Build Service
Web: http://saschamanns.gulli.to
Blog: http://lizards.opensuse.org/author/saigkill
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org