October 2012 - openSUSE Packaging - openSUSE Mailing Lists

[opensuse-packaging] Packaging Guideline enforcement
by Dominique Leuenberger a.k.a DimStar 10 Sep '13

10 Sep '13

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

29 105

[opensuse-packaging] ldconfig - I'm frustrated
by Greg Freemyer 20 Mar '13

20 Mar '13

All, I sent the httrack package to security a couple weeks ago. It builds, but with a few rpmlint issues. I thought I would clean up the one about the shared library needing to be split out to its own package. I've tried to do that in home:gregfreemyer:branches:security > httrack The diff is: https://build.opensuse.org/package/rdiff?opackage=httrack&oproject=security… I've tried multiple ways to call ldconfig. But my build always fails with: [ 218s] libhttrack2.x86_64: E: library-without-ldconfig-postin (Badness: 300) /usr/lib64/libhtsjava.so.2.0.46 [ 218s] libhttrack2.x86_64: E: library-without-ldconfig-postin (Badness: 300) /usr/lib64/libhttrack.so.2.0.46 [ 218s] This package contains a library and provides no %post scriptlet containing a [ 218s] call to ldconfig. The spec file currently has: === %post /sbin/ldconfig /usr/lib64 %postun /sbin/ldconfig /usr/lib64 === I've tried the basic versions as well. == %post -p /sbin/ldconfig %postun -p /sbin/ldconfig == %post /sbin/ldconfig %postun /sbin/ldconfig == Can anyone tell me what's going on? Thanks Greg -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

12 33

[opensuse-packaging] Packages looking for volunteers: festival, libgsasl
by Vincent Untz 07 Dec '12

07 Dec '12

Hi, I'm looking for new maintainers for these two packages: devel:libraries:c_c++/libgsasl This is the GNU SASL library. It's used by a few packages, is alive upstream with a nice maintainer. I only touched this package because another packages I was working on was using it, and inherited from maintenance this way. But I really don't look at it, so I feel it could do with more love. hardware/festival This is a speech synthesis system. I'm not quite sure how much it's still used; it used to be a dependency for GNOME accessibility (which is why I somehow became maintainer, I guess), but it's not used there anymore. I'm happy to give magical powers to anyone willing to take over those packages :-) Cheers, Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

7 18

[opensuse-packaging] WARNING: Incompatible upgrades incoming for Horde 5 Groupware and Libraries
by Ralf Lang 14 Nov '12

14 Nov '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, With the upcoming release of Horde 5 Groupware, I am going to replace all horde-related framework packages in server:php:applications with their 2.0 counterparts and all horde apps with their horde 5 versions. I won't maintain horde 4 in server:php:applications any further, apart from security related updates in released and maintained opensuse versions. I will probably stage/bootstrap these upgrades in a separate repo first. This will mostly affect users of SLES 11 and SLES 11 SP1 who used server:php:applications as their source repository for Horde 4 apps. If there is anything to discuss first, please answer to this list. - -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: lang(a)b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCJJmcACgkQCs1dsHJ/X7ADQACfbRB+tnLkhx3Z2S8gJ0EMGKwJ LzMAnAmIcpPD/ICDXD8XoBJUv6TFj+cE =dU34 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 3

[opensuse-packaging]
by Cristian Morales Vega 05 Nov '12

05 Nov '12

The following packages have been failing to build on Factory for more than 30 days. This is a reminder for anybody that could be interested in any of them. Any package failing to build for more than 100 days will be dropped from openSUSE. - libgcj43 Fails for 277 days: undefined reference to `__cxa_call_unexpected' - elilo Fails for 92 days: undefined reference to `__stack_chk_fail_local' (New upstream version 3.14 available) - opensuse-manuals_ru Fails for 86 days: java 1.7 breaks it - selinux-policy Fails for 74 days: error(s) encountered while parsing configuration (Different changes in devel project (since 6 months)) - libgcj41 Fails for 47 days: java test cases... - compiz Fails for 44 days: kwin changes - kdegraphics3 Fails for 42 days: gphoto update (Current sources were declined: request 138654) - xerces-j2-bootstrap Fails for 33 days: temporary failure - hawk Fails for 33 days: cannot load such file -- gettext/tools/rgettext (rails 2 vs rails 3?) - python-tagpy Fails for 33 days: taglib update - rubygem-webyast-time Fails for 31 days: Missing partial shared/online_help (Different changes in devel project (since 23 days)) - ccscript3 Fails for 30 days: undefined reference to `main' (Request 139531 to network:telephony) - iscsitarget Fails for 30 days: kernel 3.6 This is a test. Please give some feedback. Anything to improve? Did this email actually helped you? The email was sent BCC to the package maintainers I could identify. I couldn't identify one clear one for ccscript3 and sent it to the latest .changes entry. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

7 12

[opensuse-packaging] Packaging Policies - and how to change them: A proposal
by Andreas Jaeger 03 Nov '12

03 Nov '12

Looking at our packaging policies, I see nobody nobody currently taking care of it and no real process to change them and make those changes known. So, I'd like to propose the following: * Introduce a simple process for changing the policies, e.g.: - send an email to opensuse-packaging with a proposal for change - discuss change - if change gets accepted by packagers and reviewers: + update the wiki pages + send an email to opensuse-announce about the change (we can also collect a couple of smaller changes and only send this out once a while) * I suggest to form a small team that guides the process and decides if there is no consensus - and better formulates the process. Any better ideas? Who likes to join the team and help shaping the packaging policies? 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

6 8

[opensuse-packaging] Help needed to figure out what is missing
by Togan Muftuoglu 03 Nov '12

03 Nov '12

Hi, For sometime I have been trying to get racket [1] to build and after a long fight I manage to get it building and working on openSUSE 12.1 and Factory but for some reason I can't figure out why it fails to build for openSUSE 12.2 Help is appreciated as I intent to submit it to devel:languages:misc and hopefully into factory Togan [1] <http://www.racket-lang.org/> -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 6

[opensuse-packaging] setting a system variable and compiler options
by Denny Beyer 03 Nov '12

03 Nov '12

Dear all, I could use some input for a progam I packaging at the moment, which requires two system variables to run. 1. path to binaries The documentation says, that /usr/local/program/bin/ needs to be in the PATH - variable. That shouldn't be needed, if those binaries are installed into "/usr/bin" by the package. If that doesn't work, I'll use links from "/usr/bin/" 2. path to libraries Looks like this is needed: MYLIBPATHVAR is required to point to the library of the program in "/usr/lib/program/lib/" or "/usr/share/program/lib/" How do I introduce a new system wide environment variable - available for all users? 3. Compiler options for optimization to improve the performance of the program, the compiler could get some performance settings like -O3 -mtune=corei7 -march=corei7 etc. to get the full capability for calculations (sse4.2). How does that effect the packaging? Do I need to splitt off a -SSE3/4 package and how does that work? Could somebody point me to some wiki page / sample package to see how to achieve that? You'll see the package in obs https://build.opensuse.org/package/show?package=radiance&project=home%3Alum… cheers, Denny -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

5 4

[opensuse-packaging] libtorrent-rasterbar (0.16.5) examples fail to build with boost 1.49
by Mariusz Fik 03 Nov '12

03 Nov '12

Hi, I wanted to update libtorrent-rasterbar package in devel:libraries:c_c++. Libray is building fine but examples fail: [ 24s] Making all in examples [ 24s] make[1]: Entering directory `/home/abuild/rpmbuild/BUILD/libtorrent-rasterbar-0.16.5/examples' [ 24s] g++ -DPACKAGE_NAME=\"libtorrent-rasterbar\" -DPACKAGE_TARNAME=\"libtorrent-rasterbar\" -DPACKAGE_VERSION=\"0.16.5\" -DPACKAGE_STRING=\"libtorrent-rasterbar\ 0.16.5\" -DPACKAGE_BUGREPORT=\"arvid(a)cs.umu.se\" -DPACKAGE_URL=\"http://www.libtorrent.org\" -DPACKAGE=\"libtorrent-rasterbar\" -DVERSION=\"0.16.5\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_PTHREAD=1 -DHAVE_BOOST=1 -DHAVE_BOOST_SYSTEM=1 -DHAVE_GETHOSTBYNAME=1 -DHAVE_GETHOSTBYNAME_R=1 -DGETHOSTBYNAME_R_RETURNS_INT=1 -DHAVE_LIBRT=1 -DNDEBUG=1 -DTORRENT_USE_OPENSSL=1 -DHAVE_PYTHON=\"2.7\" -DHAVE_BOOST_PYTHON=1 -DHAVE_LINUX_FIEMAP_H=1 -DBOOST_ASIO_HASH_MAP_BUCKETS=1021 -DBOOST_EXCEPTION_DISABLE=1 -DBOOST_ASIO_ENABLE_CANCELIO=1 -DBOOST_ASIO_DYN_LINK=1 -DTORRENT_BUILDING_SHARED=1 -I. -ftemplate-depth-50 -I../include -Os -I/usr/include -fmessage-length=0 -O2 - Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -fvisibility=hidden -fno-strict-aliasing -fvisibility-inlines-hidden -c -o client_test.o client_test.cpp [ 24s] client_test.cpp: In function 'int main(int, char**)': [ 24s] client_test.cpp:1645:28: warning: ignoring return value of 'int scanf(const char*, ...)', declared with attribute warn_unused_result [-Wunused-result] [ 24s] client_test.cpp:1761:25: warning: ignoring return value of 'int scanf(const char*, ...)', declared with attribute warn_unused_result [-Wunused-result] [ 24s] /bin/sh ../libtool --tag=CXX --mode=link g++ -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -fvisibility=hidden -fno-strict-aliasing -fvisibility-inlines-hidden -lboost_system-mt -L/usr/lib64 -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -lrt -o client_test client_test.o ../src/libtorrent-rasterbar.la -lGeoIP -lrt -lpthread [ 24s] libtool: link: g++ -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -fvisibility=hidden -fno-strict-aliasing -fvisibility-inlines-hidden -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -o .libs/client_test client_test.o -L/usr/lib64 ../src/.libs/libtorrent-rasterbar.so -lboost_system-mt -lssl -lcrypto -lGeoIP -lrt -lpthread -Wl,-rpath -Wl,/usr/lib64 [ 25s] client_test.o: In function `libtorrent::block_info::peer() const': [ 25s] /home/abuild/rpmbuild/BUILD/libtorrent-rasterbar-0.16.5/examples/../include/libtorrent/torrent_handle.hpp:120: undefined reference to `boost::asio::ip::address_v4::address_v4(boost::array<unsigned char, 4ul> const&)' [ 25s] /home/abuild/rpmbuild/BUILD/libtorrent-rasterbar-0.16.5/examples/../include/libtorrent/torrent_handle.hpp:120: undefined reference to `boost::asio::ip::address::address(boost::asio::ip::address_v4 const&)' [ 25s] client_test.o: In function `basic_endpoint': [ 25s] /usr/include/boost/asio/ip/basic_endpoint.hpp:91: undefined reference to `boost::asio::ip::detail::endpoint::endpoint(boost::asio::ip::address const&, unsigned short)' [ 25s] client_test.o: In function `libtorrent::block_info::peer() const': [ 25s] /home/abuild/rpmbuild/BUILD/libtorrent-rasterbar-0.16.5/examples/../include/libtorrent/torrent_handle.hpp:117: undefined reference to `boost::asio::ip::address_v6::address_v6(boost::array<unsigned char, 16ul> const&, unsigned long)' [ 25s] /home/abuild/rpmbuild/BUILD/libtorrent-rasterbar-0.16.5/examples/../include/libtorrent/torrent_handle.hpp:117: undefined reference to `boost::asio::ip::address::address(boost::asio::ip::address_v6 const&)' [ 25s] client_test.o: In function `basic_endpoint': [ 25s] /usr/include/boost/asio/ip/basic_endpoint.hpp:91: undefined reference to `boost::asio::ip::detail::endpoint::endpoint(boost::asio::ip::address const&, unsigned short)' [ 25s] client_test.o: In function `handle_alert(libtorrent::session&, libtorrent::alert*, std::multimap<std::string, libtorrent::torrent_handle, std::less<std::string>, std::allocator<std::pair<std::string const, libtorrent::torrent_handle> > >&, std::set<libtorrent::torrent_handle, std::less<libtorrent::torrent_handle>, std::allocator<libtorrent::torrent_handle> >&, int*, boost::unordered::unordered_set<libtorrent::torrent_status, boost::hash<libtorrent::torrent_status>, std::equal_to<libtorrent::torrent_status>, std::allocator<libtorrent::torrent_status> >&, std::vector<libtorrent::torrent_status const*, std::allocator<libtorrent::torrent_status const*> >&, bool&)': [ 25s] /home/abuild/rpmbuild/BUILD/libtorrent-rasterbar-0.16.5/examples/client_test.cpp:949: undefined reference to `boost::asio::ip::address::from_string(char const*, boost::system::error_code&)' [ 25s] client_test.o: In function `basic_endpoint': [ 25s] /usr/include/boost/asio/ip/basic_endpoint.hpp:91: undefined reference to `boost::asio::ip::detail::endpoint::endpoint(boost::asio::ip::address const&, unsigned short)' [ 25s] client_test.o: In function `operator==': [ 25s] /usr/include/boost/asio/ip/basic_endpoint.hpp:193: undefined reference to `boost::asio::ip::detail::operator==(boost::asio::ip::detail::endpoint const&, boost::asio::ip::detail::endpoint const&)' [ 25s] /usr/include/boost/asio/ip/basic_endpoint.hpp:193: undefined reference to `boost::asio::ip::detail::operator==(boost::asio::ip::detail::endpoint const&, boost::asio::ip::detail::endpoint const&)' [ 25s] /usr/include/boost/asio/ip/basic_endpoint.hpp:193: undefined reference to `boost::asio::ip::detail::operator==(boost::asio::ip::detail::endpoint const&, boost::asio::ip::detail::endpoint const&)' [ 25s] /usr/include/boost/asio/ip/basic_endpoint.hpp:193: undefined reference to `boost::asio::ip::detail::operator==(boost::asio::ip::detail::endpoint const&, boost::asio::ip::detail::endpoint const&)' [ 25s] /usr/include/boost/asio/ip/basic_endpoint.hpp:193: undefined reference to `boost::asio::ip::detail::operator==(boost::asio::ip::detail::endpoint const&, boost::asio::ip::detail::endpoint const&)' [ 25s] client_test.o: In function `boost::asio::ip::basic_endpoint<boost::asio::ip::tcp>::address() const': [ 25s] /usr/include/boost/asio/ip/basic_endpoint.hpp:180: undefined reference to `boost::asio::ip::detail::endpoint::address() const' [ 25s] /usr/include/boost/asio/ip/basic_endpoint.hpp:180: undefined reference to `boost::asio::ip::detail::endpoint::address() const' [ 25s] client_test.o: In function `main': [ 25s] /home/abuild/rpmbuild/BUILD/libtorrent-rasterbar-0.16.5/examples/client_test.cpp:1343: undefined reference to `boost::asio::ip::address::address(boost::asio::ip::address_v4 const&)' [ 25s] /home/abuild/rpmbuild/BUILD/libtorrent-rasterbar-0.16.5/examples/client_test.cpp:1343: undefined reference to `boost::asio::ip::address::address(boost::asio::ip::address_v4 const&)' [ 25s] /home/abuild/rpmbuild/BUILD/libtorrent-rasterbar-0.16.5/examples/client_test.cpp:1339: undefined reference to `boost::asio::ip::address_v4::address_v4(unsigned long)' [ 25s] /home/abuild/rpmbuild/BUILD/libtorrent-rasterbar-0.16.5/examples/client_test.cpp:1340: undefined reference to `boost::asio::ip::address_v4::address_v4(unsigned long)' [ 25s] client_test.o: In function `__static_initialization_and_destruction_0': [ 25s] /usr/include/boost/asio/error.hpp:247: undefined reference to `boost::asio::error::get_netdb_category()' [ 25s] /usr/include/boost/asio/error.hpp:249: undefined reference to `boost::asio::error::get_addrinfo_category()' [ 25s] /usr/include/boost/asio/error.hpp:251: undefined reference to `boost::asio::error::get_misc_category()' [ 25s] client_test.o: In function `posix_tss_ptr': [ 25s] /usr/include/boost/asio/detail/posix_tss_ptr.hpp:42: undefined reference to `boost::asio::detail::posix_tss_ptr_create(unsigned int&)' [ 25s] collect2: error: ld returned 1 exit status [ 25s] make[1]: *** [client_test] Error 1 [ 25s] make[1]: Leaving directory `/home/abuild/rpmbuild/BUILD/libtorrent-rasterbar-0.16.5/examples' [ 25s] make: *** [all-recursive] Error 1 [ 25s] error: Bad exit status from /var/tmp/rpm-tmp.GFxL96 (%build) I'm not sure about the cause. Do we need first update boost to newer version? Any hints? -- Pozdrawiam / Best regards, Mariusz Fik openSUSE Community Member GPG: 5FCE 7241 B3B9 32FD 455B C30E 42D6 6C88 9E83 7C3D

2 1

[opensuse-packaging] Is there a macro for both BuildRequires and Requires?
by Greg Freemyer 03 Nov '12

03 Nov '12

All, I think Requires and BuildRequires are disjoint / independent. I have a package that has about 20 Requires. I'd like to have a %check section for it, but I'll need all those requires at build time as well to do that. Is there a clean solution? Thanks Greg -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 2

[opensuse-packaging] RFC: Guidelines change for lua packaging
by Togan Muftuoglu 02 Nov '12

02 Nov '12

Hi, For background information, which describes the current packaging situation in build-service. please see the following mail <http://lists.opensuse.org/opensuse-buildservice/2012-09/msg00144.html> This is a revised version of a previously mailed RFC to this mailinglist <http://lists.opensuse.org/opensuse-packaging/2012-09/msg00214.html> and still needs refinement. Where appropriate, comments of other people are included in the main document, and where necessary comments are included within the ==NOTE== marks. Therefore contributions in enhancing the document is kindly requested. Thanks Togan 1) The main development should be taking place in devel:languages:lua and therefore devel:languages:misc should be droped as the devel repo for Factory. ==NOTE=== Dominique Leuenberger suggested this effort could be started by populating the packages (preferably as links to openSUSE:Factory, where they are already pushed). Any package that made it into devel:languages:lua should get a changedevelrequest to have the official devel repo follow the new package. ===================== 2) various lua packages that are scattered around the OBS should be developed in devel:languages:lua ==NOTE== That means contacting the maintainers of such packages and ask for moving there package(s) to devel:languages:lua project ========== * Guidelines for Lua packages * Macros are already defined by the lua and lua51 packages in devel:languages:lua # RPM macros for Lua # The major.minor version of Lua %lua_version %(lua -e 'print(_VERSION)' | cut -d ' ' -f 2) ==NOTE== In Ludwig Nussel suggested to compute this once at build time when installing the macros, rather then having rpm evaluate this macro every time ======= # compiled modules should go here %lua_archdir %{_libdir}/lua/%{lua_version} # pure Lua modules should go here %lua_noarchdir %{_datadir}/lua/%{lua_version} * Addon packages Lua add-on packages should generally follow the naming scheme of lua(version)-PKG_NAME -- e.g. Currently main lua packages provided by openSUSE are as follows lua ------ providing version 5.2 lua51 ------ providing version 5.1 lua50 ------ providing version 5.0 lua51-luafilesystem -- tobe used with lua version 5.1 lua-luafilesystem -- tobe used with lua version 5.2 ===NOTE== Unfortunately this itself brings the problem with the next version of lua coming into play say 5.3. Therefore a better way of naming the main lua packages is needed in order to prevent renaming process in the future ===== * Development Packages Some lua modules provide some C parts for extending the module should the user chooses to enhance the module. Hence the name development package, and these packages should have devel suffix added to the package name lua(version)-PKG_NAME-devel Example lua51-luafilesystem-devel * Documentation packages Taking account of the rpmlint warning regarding huge documentation, or the package is just documentation then naming should be lua(version)-PackageName-doc and should be installed to %_defaultdocdir /usr/share/doc/packages/lua-{PKG_NAME}-doc/* * Packaging tools * Many upstream Lua developers use LuaRocks to distribute their modules. Therefore we probably should be finding a way to integrate luarocks in our build system and possibly provide a packaging mechanism similar to py2pack of python -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 2

[opensuse-packaging] How to detect package's version in specfile?
by Marguerite Su 01 Nov '12

01 Nov '12

Hi, all I have to detect xulrunner-devel version in specfile. but I got a problem: the version in `rpm -q --qf='%{version}' xulrunner-devel` will be overridden by the "Version: " in specfile itself. any ideas? or has anybody successfully detected a Tumbleweed? I know it's not possible so that I have to detect xulrunner version. Marguerite -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 8

[opensuse-packaging] New rpmlint checks for /etc/conf.d and systemd directories
by Andreas Jaeger 31 Oct '12

31 Oct '12

Since SuSEconfig is dead now, I'm blacklisting the whole directory /etc/conf.d in rpmlint. Also, I'm adding a check to rpmlint for the directories /etc/modules- load.d and /etc/tmpfiles.d since those should contain only user files, system wide configuration is in /usr/lib/modules-load.d and /usr/lib/tmpfiles.d. How shall we handle /etc/systemd ? Currently systemd installs some files into it - is it the only package doing so and thus should we add an rpmlintrc allowing it in systemd as an exception? Or any better ideas to handle it? 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

6 11

[opensuse-packaging] Re: Factory report (was: "")
by Cristian Morales Vega 29 Oct '12

29 Oct '12

On 29 October 2012 10:45, Raymund Will <rw(a)suse.de> wrote: > Hi Cristian, > > Cristian Morales Vega wrote on 2012-10-27T12:46:29 +0100: >> The following packages have been failing to build on Factory for more >> than 30 days. This is a reminder for anybody that could be interested >> in any of them. Any package failing to build for more than 100 days >> will be dropped from openSUSE. > [...] >> This is a test. Please give some feedback. Anything to improve? > [...] > > Maybe > - add a meaningful "Subject"? Yes, my fault. > - lower initial warning threshold from 30 to, say, 7 -- without analysis, > to allow "catching" the offender, especially when nothing changed > in the packet itself. Would somebody consider 7 days too annoying? > - analysis might be worthwhile after 30 days > - dropping should happen more than 8 days from initial warning and never > be "automatic", or is this only a "threat"? (Some packages should simply > never be dropped -- having a previous build of 'elilo' is much better > than none at all!) The "100 days" part comes from this message from Coolo (http://lists.opensuse.org/opensuse-factory/2012-10/msg00262.html). - It's not something new. Not documented anywhere but apparently has been done for some time - It's not automatic, as shown by the fact that the list includes packages that have been failing for way longer. So take it as an approximation. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 0

[opensuse-packaging] Rpmlint warnings or false positives
by Togan Muftuoglu 28 Oct '12

28 Oct '12

Hi, In clean up process of librep package of X11:windowmanagers, rpmlint produces these warnings The branched package lives in <https://build.opensuse.org/package/show?package=librep&project=home%3Atogan…> ''' librep.x86_64: W: shlib-policy-nonversioned-dir /usr/share/rep librep.x86_64: W: shlib-policy-nonversioned-dir /usr/lib64/rep librep.x86_64: W: shlib-policy-nonversioned-dir /usr/share/doc/packages/librep Your shared library package contains non-versioned directories. Those will not allow to install multiple versions of the package in parallel. librep.x86_64: W: shlib-policy-excessive-dependency librep.so.16 Your package starts with 'lib' as part of its name, but also contains binaries that have more dependencies than those that already required by the libraries. Those binaries should probably not be part of the library package, but split into a seperate one to reduce the additional dependencies for other users of this library. ''' I guess the warning is caused by the package name being librep as the versioned package is build from the sources and has the name librep16 Since I want to submit the package into factory, are these warnings false positives, as I hope them to be ? Or if not any help is appreciated Thanks Togan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 1

[opensuse-packaging] Does OBS support nosrc RPM?
by Andrey Borzenkov 25 Oct '12

25 Oct '12

Is it possible to download sources when RPM rebuild is triggered? Or must sources always be included in package? In this case it is external FTP resource, no GIT repository or other SCM. Thank you -andrey -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 1

[opensuse-packaging] Dependency resolution problem
by Nanuk Krinner 22 Oct '12

22 Oct '12

Hi, I'm working on the project systemsmanagement:chef and have a problem where I need help. Every package builds against openSUSE 12.2 in the build service. But when I try to build rubygem-chef-solr from the project locally (with 'osc build x86_64 openSUSE_12.2') or install it I get the following error: #:~/work/packaging/systemsmanagement:chef/rubygem-chef-solr> osc build x86_64 openSUSE_12.2 Building rubygem-chef-solr.spec for openSUSE_12.2/x86_64 Getting buildinfo from server and store to /home/nanuk/work/packaging/systemsmanagement:chef/rubygem-chef-solr/.osc/_buildinfo-openSUSE_12.2-x86_64.xml Getting buildconfig from server and store to /home/nanuk/work/packaging/systemsmanagement:chef/rubygem-chef-solr/.osc/_buildconfig-openSUSE_12.2-x86_64 buildinfo is broken... it says: unresolvable: nothing provides rubygem(1.9.1:net-ssh-multi:1.1) >= 1.1.0 needed by rubygem-chef But I can build rubygem-chef and rubygem-net-ssh-multi locally. When I try to install rubygem-chef, it fails with same error as does rubygem-chef-solr. But I can install rubygem-net-ssh-multi (and other packages) from the repository. I don't understand why everything works within the build service, but I can't install from the repository. There might be a problem in the project config or in one of the spec files, but don't see it. Does anybody what is wrong here? Thanks in advance, Nanuk -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 1

[opensuse-packaging] How to avoid installation of a package?
by Ilya Chernykh 18 Oct '12

18 Oct '12

I got an error: file /usr/share/idl conflicts between attempted installs of omniORB-4.1.4-1.73.i586 and libIDL-2-0-0.8.14-13.5.i586 I added -libIDL to the buildrequires but I still get the same error. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

5 5

[opensuse-packaging] python installing modules to /usr/local by default - good or bad?
by Jan Matejek 16 Oct '12

16 Oct '12

Fellow packagers and pythonistas, i'd like to notify you about a proposed change to the way Python installs its packages, and give you a chance to object before it is put into effect. This has nothing to do with the "versioned python" proposal. TL;DR version: Currently, python is configured to install packages into /usr/local/lib/pythonX.Y/site-packages, unless you specify "--prefix=/usr". This mimicks autotools behavior, but diverges from upstream. If there are no significant objections, I'm going to restore the default behavior where "/usr" is the default prefix. Packages installed in /usr/local will still be recognized, it just won't be the default install location anymore. Detailed version: While investigating possible solutions to bnc#658604 (python user install scheme broken, [1]), i came to revisit the decision to make SUSE's python install modules into /usr/local by default. A little background: this feature came to be as a response to a pair of bugs, bnc#149809 [2] and bnc#149843 [3]. The original reporter argues that /usr/local is the right place for locally-installed software and that Python should not deviate from customary (i.e. autotools) behavior in this regard. Python should auto-recognize modules installed in the /usr/local hierarchy, and for consistency and convenience's sake, should install in there by default as well. The former request is reasonable, and back then i thought that the latter is reasonable as well. (also, back then i wasn't on the job for very long, i made the change, didn't tell anyone about it and broke about a million of other people's packages. oh those were the days. sorry again if you were affected.) Six years later, i still think it's the right thing to do, but i don't think we should actually be doing it. Arguments basically boil down to one of Python's core principles, "practicality beats purity". But for completeness, here's what i came up with. For installing to /usr/local: + it's what FHS tells us, with some good reasoning (read-only /usr and so on) + it's what autotools do + the /usr hierarchy remains untainted by files outside of rpm's control + and conversely, the user has all of her site-local packages in /usr/local, not mingled with "managed" installations (unlike e.g. Perl, Python has no official mechanism for separating "site" packages and "vendor" packages. this provides such distinction) Against: - AFAIK, we're the only ones doing it - upstream python doesn't recognize the distinction and there is no support for it in the libraries - to expand on that point, there is no "right" place to patch this behavior in - a correct patch for the new behavior wouldn't be too complex, but it would not be upstreamable. No patch is better than one patch. - modules don't like to be installed in locations they can't query through python's sysconfig methods - third-party python packagemanagers/installers might not recognize our intentions and would need to be patched separately Also, i'm not really aware of anyone reaping any benefits from our current config. So, if you have anything good to say about the way we do it now, here is your chance. I'll wait until next week, and if no significant objections are raised, i'll push this change into Factory. m. [1] "Python distutils setup does not allow user installation of Python packages" https://bugzilla.novell.com/show_bug.cgi?id=658604 [2] "python path does not contain /usr/local" https://bugzilla.novell.com/show_bug.cgi?id=149809 [3] "Python's site-packages should contain a directory in /usr/local" https://bugzilla.novell.com/show_bug.cgi?id=149843 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

6 10

[opensuse-packaging] BoF announce: Secure Boot for next openSUSE: Monday October 22, 10:00 - room L2
by Frederic Crozat 16 Oct '12

16 Oct '12

Hi all, I'm planning to do a BoF about Secure Boot for next openSUSE, to discuss: - requirements for implementing Secure Boot - various tasks which are needed in the various components of the distribution - paperwork I've reserved one slot 10:00 - 11:00, room L2, on Monday October 22 Warning, the point of this BoF is not to discuss about if Secure Boot is bad or good, but to make sure we have next openSUSE distro installable on Secure Boot system. -- Frederic Crozat <fcrozat(a)suse.com> SUSE -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 0

[opensuse-packaging] New fdupes and %fdupes behavior in Factory
by Michal Vyskocil 16 Oct '12

16 Oct '12

Hi all, the fdupes package got a new switch -p/--permissions, where it won't mark files with different ownership and security bits as duplicates (bnc#784670). I've already took the time, upgrade it to the latest 1.5.0-PR2 and adopted all patches from Debian. There is one difference - we have a patch sorts the output according filename, but upstream sorts according mtime and I did not port our patch. But I don't thing it will cause any troubles. There's a pending request for Factory https://build.opensuse.org/request/show/138347 https://bugzilla.novell.com/show_bug.cgi?id=784670 Regards Michal Vyskocil

1 0

[opensuse-packaging] RFC: Lua packaging guidelines
by Togan Muftuoglu 15 Oct '12

15 Oct '12

Hi, I have mailed packaging mailing list earlier <http://lists.opensuse.org/opensuse-packaging/2012-09/msg00123.html> regarding packaging guidelines for Lua packaging which probably did not get enough attention. Following a mail to the opensuse-buildservice regarding lua packages development <http://lists.opensuse.org/opensuse-buildservice/2012-09/msg00144.html> I would like to propose the following packaging guidelines for Lua since the projct does not have one. 1) The main development should be taking place in devel:languages:lua and therefore devel:languages:misc should be droped as the devel repo for Factory. 2) various lua packages that are scattered around the OBS should be developed in devel:languages:lua Guidelines for Lua packages Macros are already defined by the lua and lua51 packages in devel:languages:misc # RPM macros for Lua # The major.minor version of Lua %lua_version %(lua -e 'print(_VERSION)' | cut -d ' ' -f 2) # compiled modules should go here %lua_archdir %{_libdir}/lua/%{lua_version} # pure Lua modules should go here %lua_noarchdir %{_datadir}/lua/%{lua_version} * Addon packages Lua add-on packages should generally follow the naming scheme of lua(version)-PKG_NAME -- e.g. lua51-luafilesystem -- tobe used with lua version 5.1 lua-luafilesystem -- tobe used with lua version 5.2 * Development Packages Development packages should have devel suffix added to the package name lua(version)-PKG_NAME-devel Example lua51-luafilesystem-devel * Documentation packages If a package has huge documentation or is just a doc package then naming should be lua(version)-PackageName-doc and should be installed to %_defaultdocdir /usr/share/doc/packages/lua-{PKG_NAME}-doc/* Many upstream Lua developers use LuaRocks to distribute their modules. Therefore we probably should be finding a way to integrate luarocks in our build system and possibly provide a packaging mechanism similar to py2pack of python Comments will be appreciated Togan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

5 9

[opensuse-packaging] Process for changing the Packaging Guidelines
by Andreas Jaeger 15 Oct '12

15 Oct '12

After discussion on the packaging mailing list, let's move forward as follows with changing the packaging guidelines: For changing of the packaging policies, we will use the following simple process: Changing of packaging policy: * send an email to the mailing list with a proposal for change. Add to the subject the tag "RFC: Guidelines change" * discuss the change * if the change gets accepted by packagers and reviewers, update the wiki pages. Acceptance means: No strong objections within 14 days of the postings. * if the change can be algorithmically enforced, a rpmlint check is proposed. * the packaging guidelines team will send a monthly email to opensuse-announce and opensuse-packaging mailing lists to announce changes to the policy (only if there are changes to be announced) * the packaging guidelines team will support the process and make a decision in case of conflicts. The packaging guidelines team consists of Dominique Leuenberger, Sascha Peilicke, Dirk Müller, Andreas Jaeger, Ludwig Nussel, Togan Muftuoglu, Michal Vyskocil. You can reach the team on the opensuse-packaging mailing list. Btw. this is documented now on http://en.opensuse.org/openSUSE:Packaging_guidelines_change_process 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

1 0

[opensuse-packaging] Project config changes of openSUSE:Factory
by Stephan Kulow 12 Oct '12

12 Oct '12

Hi, Just to avoid suprise build failures for you: I did some changes to the project config that will affect many builds, but at least no package in factory should fail due to this as I prepared this in several staging projects and also submitted fixes early: 1. We switched from libpng14 to libpng15 default, Petr submitted patches to many packages already and we think we're ready for it. 2. I removed 4 packages from default install in build environment: sysvinit-tools netcfg login udev Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 2

[opensuse-packaging] Are there any plans to shrink the image size, so the iso image can be placed onto dvd media
by doiggl＠velocitynet.com.au 12 Oct '12

12 Oct '12

Hello, It looks like the size of the dvd builds are increasing, for example: 4693426176 Oct 10 02:20 openSUSE-DVD-Build0050-x86_64.iso 4722786304 Oct 11 03:05 openSUSE-DVD-x86_64-Build0061-Media.iso 4713349120 Oct 12 03:13 openSUSE-DVD-x86_64-Build0066-Media.iso The later builds I had trouble burning to dvd, example: # wodim -v -dao dev=/dev/sr0 driveropts=burnfree openSUSE-DVD-x86_64-Build0066-Media.iso TOC Type: 1 = CD-ROM scsidev: '/dev/sr0' devname: '/dev/sr0' scsibus: -2 target: -2 lun: -2 Linux sg driver version: 3.5.27 Wodim version: 1.1.11 Driveropts: 'burnfree' SCSI buffer size: 64512 Device type : Removable CD-ROM Version : 5 Response Format: 2 Capabilities : Vendor_info : 'TSSTcorp' Identification : 'CDDVDW TS-L633C ' Revision : 'AS01' Device seems to be: Generic mmc2 DVD-R/DVD-RW. Current: 0x0011 (DVD-R sequential recording) Profile: 0x0015 (DVD-R/DL sequential recording) Profile: 0x0016 (DVD-R/DL layer jump recording) Profile: 0x002B (DVD+R/DL) Profile: 0x001B (DVD+R) Profile: 0x001A (DVD+RW) Profile: 0x0014 (DVD-RW sequential recording) Profile: 0x0013 (DVD-RW restricted overwrite) Profile: 0x0012 (DVD-RAM) Profile: 0x0011 (DVD-R sequential recording) (current) Profile: 0x0010 (DVD-ROM) Profile: 0x000A (CD-RW) Profile: 0x0009 (CD-R) Profile: 0x0008 (CD-ROM) Profile: 0x0002 (Removable disk) Using generic SCSI-3/mmc DVD-R(W) driver (mmc_mdvd). Driver flags : SWABAUDIO BURNFREE Supported modes: PACKET SAO Drive buf size : 1406976 = 1374 KB Beginning DMA speed test. Set CDR_NODMATEST environment variable if device communication breaks or freezes immediately after that. FIFO size : 12582912 = 12288 KB Track 01: data 4495 MB Total size: 5162 MB (511:25.86) = 2301440 sectors Lout start: 5162 MB (511:27/65) = 2301440 sectors Current Secsize: 2048 HINT: use dvd+rw-mediainfo from dvd+rw-tools for information extraction. Blocks total: 2298496 Blocks current: 2298496 Blocks remaining: -2944 wodim: WARNING: Data may not fit on current disk. wodim: Notice: Most recorders cannot write CD's >= 90 minutes. wodim: Notice: Use -ignsize option to allow >= 90 minutes. wodim: Notice: Use -overburn option to write more than the official disk capacity. wodim: Notice: Most CD-writers do overburning only on SAO or RAW mode. Are there any plans to shrink the image size, so the iso image can be placed onto dvd media ? Thanks Glenn -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 0