October 2012 - openSUSE Packaging - openSUSE Mailing Lists

[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