openSUSE Packaging May 2009

packaging@lists.opensuse.org

31 participants
23 discussions

[opensuse-packaging] Import of Fedora Packaging Guidelines

by Michal Vyskocil

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

11 years, 10 months

[opensuse-packaging] /etc/modprobe.* changes

by Michal Marek

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

11 years, 11 months

[opensuse-packaging] Packages that Requires: pkg-config

by Cristian Rodríguez

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

11 years, 11 months

[opensuse-packaging] When a -devel package should require another -devel package?

by Cristian Morales Vega

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

12 years

[opensuse-packaging] Incompatibility between info_del macro and 06-check-installtest post-build-check

by Cristian Morales Vega

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

12 years

[opensuse-packaging] Expansion Error: libicudata

by Sascha 'saigkill' Manns

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

12 years

[opensuse-packaging] pstoedit still needs new maintainer

by Johannes Meixner

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

12 years

[opensuse-packaging] Another shared library policy doubt: renaming the source package.

by Cristian Morales Vega

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

12 years

[opensuse-packaging] Shared libraries are not executable

by Cristian Morales Vega

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

12 years

[opensuse-packaging] About next milestone

by Stephan Kulow

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

12 years

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

openSUSE Packaging May 2009