Hi all,
as you know I wrote a post about Fedora Packaging Guidelines [1]. I was
working on it during last three weeks (but a little, so it takes a long time
:)) and nowadays I'm ready to import a Fedora's content to en.opensuse.org
wiki. Now it is on pack.suse.cz [2]. I also checked that none of that page
conflicts with an existing content on openSUSE wiki, so it can be imported
easily.
Tom Callaway [3] from RedHat confirms me that a Guidelines are under Open
Publication License [4] and we can use it for SUSE without restrictions. He
was also interested on future collaboration and offers some meeting on
LinuxTag - it would be nice if anyone from SUSE will be ready to start a
discussion.
Before import I'd like to ask:
Which pages should be excluded for openSUSE? Some pages seems that they are
not interesting for SUSE (like Packaging:OldJPackagePolicy [5],
Packaging:SugarActivities [6]). Import it, or don't?
Second one is how to edit the text and adapt it for SUSE? Change the existing
text or leave it and add a SUSE specifics to the beginning or end of page (as
suggests Vladimir)? The second way should help us with synchronizing of
changes.
After that I'll add a warning [7] on the beginning of every page to prevent
that some users will use those guidelines and ask for help with editing ;-)
[1] http://lists.opensuse.org/opensuse-packaging/2009-02/msg00043.html
[2] http://pack.suse.cz/mvyskocil/fedora-packaging-guidelines/
[3] https://fedoraproject.org/wiki/TomCallaway
[4] http://fedoraproject.org/wiki/Legal/Licenses/OPL
[5] http://fedoraproject.org/wiki/Packaging:OldJPackagePolicy
[6] http://fedoraproject.org/wiki/Packaging:SugarActivityGuidelines
[7] http://en.opensuse.org/Template:Warning1
Best regards
Michal Vyskocil
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
Hi,
the new module-init-tools, which will appear in Factory soon, deprecated
/etc/modprobe.conf(.local) and only uses /etc/modprobe.d/*.conf
configuration files (files without the .conf suffix are still read, but
cause a warning). I tried to find and fix packages that install modprobe
config files, but in case I missed some, the fix is simple:
change /etc/modprobe.d/$name to /etc/modprobe.d/50-$name.conf.
Also, mkinitrd should be updated to not copy /etc/modprobe.conf* if it's
not there.
Michal
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
Hi:
There is a very common inconsistency in packages that include *.pc
files, some do Requires: pkg-config while some others dont, I think we
need to decide to either do require it or not, and raise an error when
this policy is violated..
what you think ? should it be required or not ?
My vote is that pkgconfig is a build dependecy only, and hence -devel
packages should not require pkgconfig.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
Well, just that.
Sometimes I find a -devel package requires another one, why? I do that
when the pkg-config file has a "Requires: XXX" and rpmlint complains
the same isn't in the RPM spec file, but normally I also don't see why
the .pc file has such an entry.
One case that makes sense is if the library is statically compiled and
depends on another library, but that's no the common case. So, to know
when I have to fix a .pc file (that should use Requires.private
instead of Requires if the problem are static librariries) and when I
must follow what it says... in which case a -devel package should
depend on another one? With shared libraries I can't think of any
valid case...
P.S. ...no, right now I don't have any example, it's something I have
seen sometimes in the past and somehow I'm asking now.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
The OBS defines a cross-distribution macro, info_del, to call
install-info --delete
%info_del(:-:) test -x /sbin/install-info -a ! -f
%{?2}%{?!2:%{_infodir}}/%{1}%ext_info && /sbin/install-info --quiet
--delete --info-dir=%{?2}%{?!2:%{_infodir}}
%{?2}%{?!2:%{_infodir}}/%{1}%ext_info \
%{nil}
The important part is the "! -f %{?2}%{?!2:%{_infodir}}/%{1}%ext_info"
that makes sure it is called in postun and no in preun.
The problem is that the 06-check-installtest script executes all the
{pre,post}[un] scriptlets without really uninstalling the package so,
when executing info_del, "%{?2}%{?!2:%{_infodir}}/%{1}%ext_info" still
exists and the test fails.
All the docs in the wiki, even those that use the openSUSE specific
macro instead of info_del, use the macros unconditionally and always
in post and postun, never in preun. Fedora, instead, uninstalls in
preun and only when the package is going to be removed, not in
upgrades.
Since 06-check-installtest executes all the scriplets like an
upgrade, the Fedora way works.
So, options:
Use the macros as the openSUSE wiki says:
%post -n %{name}
%info_add %{name}.info
%postun -n %{name}
%info_del %{name}.info
...needs fixing 06-check-installtest or info_del
OR
Use the Fedora way:
%post -n %{name}
%info_add %{name}.info
%preun -n %{name}
if [ $1 -eq 0 ] ; then
%info_del %{name}.info
fi
In any case... preun or postun? install-info needs the file to remove
it from the index? And, if it should be called only in upgrades,
shouldn't be
%post -n %{name}
if [ $1 -eq 1 ] ; then
%info_add %{name}.info
fi
%preun -n %{name}
if [ $1 -eq 0 ] ; then
%info_del %{name}.info
fi
?
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
Hello Friends,
ATM i'm get an Error:
nothing provides libicudata.so.40 needed by libboost_regex1_38_0,
nothing provides libicui18n.so.40 needed by libboost_regex1_38_0,
nothing provides libicuuc.so.40 needed by libboost_regex1_38_0
What is the libicu* Library?
--
Sincereley yours
Sascha Manns
openSUSE Marketing Team
openSUSE Build Service
openSUSE Features Screening Team
Web: http://saschamanns.gulli.to
Project-Blog: http://lizards.opensuse.org/author/saigkill
Private-Blog: http://saschasbacktrace.blogspot.com
Hello,
I cannot maintain the package pstoedit.
Currently it does not build in Factory because:
-------------------------------------------------------------
dynload.cpp:141:6: error: #elif with no expression
make[1]: *** [dynload.lo] Error 1
-------------------------------------------------------------
I have no time at all to look at it
(regardless how little effort it might be to fix it).
Perhaps one of kde-maintainers(a)suse.de gnome-maintainers(a)suse.de
or sbrabec(a)novell.com could maintain it because they need it:
$ whatdependson pstoedit
- autotrace (sbrabec(a)novell.com)
- koffice2 (kde-maintainers(a)suse.de)
$ whatdependson -R pstoedit
- inkscape [pstoedit=3.45-2.41]
$ maintainer inkscape
gnome-maintainers(a)suse.de
FYI:
"whatdependson" is an internal Suse/Novell tool
"whatdependson package" shows build dependencies i.e. for which
other packages is the package needed to build the other packages.
"whatdependson -R package" shows run-time dependencies i.e. which
other packages require the package to be installed so that
the other packages work o.k.
Kind Regards
Johannes Meixner
--
SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
AG Nuernberg, HRB 16746, GF: Markus Rex
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
At "Hints" the policy says: "There is no need to have a binary package
that matches the source package name. In fact, you should avoid
renaming the source package for different versions as we prefer to
only have a single package version in the source repository."
Thinking about this, isn't better to rename the source package?
a) Renaming the package allows to have multiple versions in the source
repository... but you are still free to have only one, whatever the
name is.
b) There isn't too much flexibility at naming the debug packages, the
name always is <source_package_name>-debug*. Renaming also the source
package you allow the debug packages of two library versions with
different sonames to be also installed at the same time.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
Hi,
http://en.opensuse.org/Packaging/Shared_Libraries, in the Best
Practices section, says "Shared libraries are not executable".
We all agree with that? Doesn't really matters, I ask just because
sometimes I have got patches submitted changed, because 99% of my
/usr/lib files are executable and because ldd still gives this pretty
warning: "ldd: warning: you do not have execution permission for
`/usr/lib64/libxvidcore.so.4'".
I'm not really sure about when, how or who wrote the Shared Library
Naming and Packaging Policy... so, I should really follow the "Shared
libraries are not executable" advice?
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
Hi,
Milestone2 is currently uploading to the mirrors, so it's a good
time to discuss briefly the goals for milestone 3.
In my timeline (http://www.suse.de/~coolo/opensuse_11.2/) the next
steps are:
04 Jun: Toolchain Freeze
07 Jun-30 Jun: Milestone 3
Milestone 3 has a corridor and not a deadline because I want to be
flexible when to release it. If milestone 2 is too broken in detail,
milestone 2 will be early, but not earlier than it works. And the
later we get in the corridor, the more package updates I block to
get some kind of in between freeze.
You might have experienced this too with Milestone 2 - we could
have spent way more time rebuilding the distribution to get everything
in, but I decided case by case what's left to fix before the milestone.
So if you have fixed something you feel important, then submit your
package and don't wait for random deadlines. Factory can be installed
every day and the early milestones are mere snapshots that work good
enough to be released for more detailed testing.
Milestone 2 was about getting gcc4.4 in, if you have some large scale
change in the making that fits the corridor, then please let me know,
so we make sure milestone 3 has the change. If you don't talk to me,
I will continue picking what I see coming submitted to factory (the
earlier we are, the more I pick of course).
Greetings, Stephan
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org