September 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] 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] 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] 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] 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] Download BIG data in %post script. What do you think?
by Cristian Morales Vega 05 Oct '12

05 Oct '12

I got this https://build.opensuse.org/request/show/135388 What do you think? It actually solves a real problem: the model of having a copy of everything in our servers doesn't scale. Specially with big game data. Problems I can think of: - You don't have control over the external servers. Somebody could modify the files there add hack into users machines. - No information about the files is stored in the RPM database. It's impossible to verify the integrity of the installed package. - It just looks bad, ugly and fragile. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

5 6

[opensuse-packaging] Quilt refresh options
by Togan Muftuoglu 01 Oct '12

01 Oct '12

Hi, According to Packaging Patch Guidelines at <http://en.opensuse.org/openSUSE:Packaging_Patches_guidelines> use of quilt is exampled as follows quilt ref --s --d -p1 However neither the man page nor the quilt refresh -h provides the options --s and --d It would be nice to know what they are suppose to mean Thanks Togan -- 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] SuSEconfig is gone
by Andreas Jaeger 29 Sep '12

29 Sep '12

FYI, a colleague of mine just did these changes: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I think one of our oldest scripts in our SuSE Linux/SUSE Linux/openSUSE and SUSE Linux Enterprise history is now finally gone: /sbin/SuSEconfig R.I.P. https://fate.suse.com/100011 https://build.opensuse.org/request/show/135139 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I think we have fixed all the packages that used SuSEconfig and will blacklist it now in rpmlint, 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 9

[opensuse-packaging] Suggestion: Add READMEs for version control access
by Andreas Jaeger 27 Sep '12

27 Sep '12

I've added now a README.packaging.txt to the packages aaa_base and rpmlint to point out which files are unter version control and how to update. If you have a package that is basically maintained in a version control system, I suggest you add some information for packagers in a similar way. For reference, this is the README from aaa_base: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This package should use just the content of the git tree. If you need to make changes, you have the following options: * Make them in git and update the package from git (you can send merge request if you don't have write access) * Create a patch, add the patch to the package and let one of the aaa_base packagers commit it for you The online repository is at: http://gitorious.org/opensuse/aaa_base For building the package from git run the service directly: osc service disabledrun Note that aaa_base.spec and aaa_base.changes are not part of the git repo. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I'm also interested in better ideas to point out the version control relationship, 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

2 2

[opensuse-packaging] "osc mr" gives "Too few arguments" error
by Joseph Mulloy 26 Sep '12

26 Sep '12

I keep running into this issue when I try to update packages in 12.2. I'm following the instructions on the wiki (http://en.opensuse.org/openSUSE:Package_maintenance), but when I get to the "osc mr" step I get a "Too few arguments" error. This is extremely frustrating as this error message is not at all helpful and I'm following the instructions on the wiki. Does anyone know what the problem is? This used to work for me. I'm running "osc mr" from the package directory of my branch. I'm running openSUSE 12.1 with the latest updates installed. jdmulloy@silicon:~/OBS/home:jdmulloy:branches:openSUSE:12.2:Update/branding-openSUSE.openSUSE_12.2_Update> osc mr -m 'Fixed KDM theme for users upgrading from <= 12.1 (bnc#781687)' Too few arguments. jdmulloy@silicon:~/OBS/home:jdmulloy:branches:openSUSE:12.2:Update/branding-openSUSE.openSUSE_12.2_Update> Joseph Mulloy jdmulloy(a)gmail.com -- 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] graphics : exiftool
by Greg Freemyer 26 Sep '12

26 Sep '12

I see that graphics : exiftool was SR'ed 5 weeks ago to have a perl-Image-ExifTool sub-project in the specfile. That is making it very redundant to devel:languages:perl : perl-Image-ExifTool which has similar sub-package structure. The D:L:P version is the devel project for factory and I happen to have issued a SR to it today to make it slightly more recent than the one in graphics. How do we merge those 2 packages and quit doing the work twice? Greg -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 1

[opensuse-packaging] spec-cleaner and Python 'TODO' tasks
by Nelson Marques 26 Sep '12

26 Sep '12

Hi all, I did a small patch (under review) for spec-cleaner the other day (for my own convenience, as between Unity, MATE and Cinnamon it's over 100 packages); I've taken a small look into the TODO file on Gitorious[1] and I was thinking in throwing some more effort regarding the Python tasks for spec-cleaner. I will transcribe them here: * replace %py_ver with %python_version * replace %py_sitedir with %python_sitearch (user might want to change this to %python_sitelib if the package is noarch) print a warning if %py_libdir is found * kill (or just print a warning?) if %py_requires is found: if it's a python module, nothing is needed. If it's not, plain python Requires is what we want. Anyone (Coolo?) confortable with Python Packaging can confirm/comment or suggest that those are the right approaches so I can implement them for Vincent to review? NM -- 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] Build fails because of gzipped symbolic link for SLE11 products
by Johannes Meixner 26 Sep '12

26 Sep '12

Hello, in Printing/ghostscript-fonts/ghostscript-fonts.spec I have --------------------------------------------------------------------------- %install ... # Provide a link to make the Ghostscript fonts also appear in the directory # /usr/share/fonts/ where applications (including X11) search for fonts. # A usr/share/fonts/ sub-directory does not exist in the buildroot: install -d -m 755 %{buildroot}%{_datadir}/fonts ln -s ../ghostscript/fonts %{buildroot}%{_datadir}/fonts/ghostscript . . . %files std ... %{_datadir}/fonts/ghostscript --------------------------------------------------------------------------- For all openSUSE products this works and I get in the binary RPMs the link that I like to have (to fix bnc#778879): /usr/share/fonts/ghostscript -> ../ghostscript/fonts But for SLE11 SLE_11_SP1 and SLE_11_SP2 build fails with: ------------------------------------------------------------------------ [ 61s] + /usr/sbin/Check [ 61s] lrwxrwxrwx 1 abuild abuild 23 Sep 26 13:44 /var/tmp/ghostscript-fonts-9.05-build//usr/share/fonts/ghostscript.gz -> ../ghostscript/fonts.gz . . . [ 61s] + /usr/lib/rpm/brp-symlink [ 61s] ERROR: link target doesn't exist (neither in build root nor in installed system): [ 61s] /usr/share/fonts/ghostscript.gz -> /usr/share/ghostscript/fonts.gz ------------------------------------------------------------------------ It seems /usr/sbin/Check changes both the symbolic link and its target to *.gz and this does of course not exist which is detected then by /usr/lib/rpm/brp-symlink. Is there something wrong with how I make the link in the spec file or is this a bug in /usr/sbin/Check (or elsewhere)? Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- 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] Building a single package to support 2 major versions of a dependency
by Darin Perusich 25 Sep '12

25 Sep '12

Hello All, I wasn't sure if this was a build service or packaging issue so I've sent this to both lists. Recently the PostgreSQL package in server:database:postgresql was repackaged to support having both versions 9.1 and 9.2 installed on the same system. This is introducing a problem for PG modules like orafce, pgsql_fdw, and others which when built the resulting libraries were installed in /usr/lib/postgresql. The new packaging lay defines those libdirs as /usr/lib/postgresql91 and /usr/lib/postgresl92. I'm looking for approaches to handle this, hopefully without having lots of duplication. The first approach would be what Debian does, create separate packages for each PG version and rename the packages to postgresql91-orafce and postgresql92-orafce respectively. Another thought is to keep a single package in OBS but setup the spec to create packages for each PG version and name it accordingly postgresql91-orafce and postgresql92-orafce. I don't know if this is possible or how you'd trigger the build but what about having 2 spec's for the package, one that builds for each version? Thoughts? -- Later, Darin -- 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] GStreamer dependencies change in Factory
by Dimstar / Dominique Leuenberger 25 Sep '12

25 Sep '12

Hi all, as announced earlier and as a dependency to GNOME 3.6, we submitted GStreamer 1.0 to Factory, as package name gstreamer. In the past, gstreamer-0_10 provided a virtual symbol gstreamer and gstreamer-0_10-devel provided gstreamer-devel. They were conveniance provides, which had to be removed, as they would; for obvious reasons clash with the actual package called gstreamer and gstreamer-devel. So, if you get a "Nothing provides gstreamer-devel" (which is currently possible, as gstreamer 1.0 is in review mode towards Factory), that means you should switch to use gstreamer-0_10-devel (or, even better pkgconfig(gstreamer-0.10), then you don't have to worry about the actual package names). Or, as an even better solution, get your package up to GStreamer 1.0 (likely discussion with upstreams are needed). There is a rather extensive 'how to port to GStreamer 1.0' documentation available; a bunch of APIs got sanitized and unsane ones have been removed... Hope to have you informed before you wasted all your spare time you don't have on trying to figure out what is going on. Best regards, Dominique / DimStar -- 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] RFC - packaging and changelogs
by Nelson Marques 22 Sep '12

22 Sep '12

Dear all, ChangeLog formats are not the same across the project; some projects are more demanding, others aren't; I've seen a royal mess in many, I've found others way to strict and speaking for myself, I find it very uncool that we can workout an update on package in 10 minutes and wast 4 or 5 times more with the changelogs (entries in .changes) than doing the technical update. Now it would be nice that all the packaging gurus out there could get some time during OSC and probably make a BoF or some discussion about trying to bring a unified procedure accross the project. Honestly if we want people to get in the workflow or help us out, I find that hard to accomplish when the technical details take way much less to do perform than the changelog entries. So, please whoever has the power to change things and work towards this, please take the lead so that if one can help, it doesn't has to follow different ways of working; If you want to increase the precision of the changelogs, cool, if you want to make it more 'loose' nice... A few situations to consider: 1. A package that hasnt been updated for a few releases: + making tens of entries, so that they get squashed in the bottom sounds uncool; + if you want precision on changelogging, then remove that squash and lets us use 100 lines or more in the changelog entry, otherwise don't ask for precision. 2. Format and documentation: + Just consider documenting the whole process so that we can learn to make the entries project wide; If this means that 99% of people will face more picking situations, then too bad. But we need this stuff sorted. We can't have personal reviews taking the heat all by themselves without being able to refer to a unified method/documentation. Honestly consider this seriously and someone make a stand and raise a crusade to provide people the tools/guidance they need. So far it's hillarious to fix/upgrade/update a package in a few minutes, and then waste countless hours with the changelog. Some people may like to masturbate while writting changelogs, I don't... specially because for the vast majority of the cases, the NEWS file does provide exactly a duplicate of the entries... For the defenders of 'rpm -q --changelog'; sure it's nice in runtime, but if the package is properly packaged, then you should have NEWS on documentation... Which ends up being pretty much the same. This is just a personal concern, which probably others may share. If I have to improve this and learn this stuff, I only want to do it once, not for all bloody projects out there... If old habbits have to die, then they better die once and for all. NM -- 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] [RFC] gpg-upstream-keys: Build time source GPG signature verification
by Stanislav Brabec 21 Sep '12

21 Sep '12

Hallo. I wrote a simple tool that provides build time GPG signature verification. It could prevent need for tarball contents verification and still being safe. Submit reviewers will just review changes in the spec files and patches, and especially verifies, that GPG verification command is not removed without rationale. How it is done: gpg-upstream-keys package collects signatures valid for verification of particular packages sources: gpg-upstream-key-*.key: Contains approved signing keys. gpg-upstream-keys.packages: Defines mapping package -> signing keys There is a tool for simple key extraction and verification and macro for simple integration to spec files. Prepare new signing key before first use: gpg-upstream-keys-tool --verbose [--package=PACKAGE] --prepare ID It will tell you how to edit gpg-upstream-keys.packages and gpg-upstream-keys.spec. Usage in packages would be straightforward: BuildRequires: gpg-upstream-keys %prep %gpg_verify %{S:1} %setup -q Note: %{S:1} is the signature, not the tarball. Here is a proof of concept and two upstream-signed packages: https://build.opensuse.org/project/show?project=home%3Asbrabec%3Abranches%3… Simple man page is added. Comments are welcome. Proposed policy: Package updates will be straightforward, as long as the same signing key is used. Reviewers should make special attention to submit that contain "-%gpg_verify" in the changes log. Any addition to gpg-upstream-keys should be carefully verified. Any change in gpg-upstream-keys would need to be double-verified. Problems: How to solve key expiration? Probably accept expired keys to prevent unexpected future failures. How to solve key expiration extension? Probably provide a way to re-import keys by trusted user. How to solve key revocation? Probably extend the tool to not accept revoked keys. But later it is a complicated task. Not only that the keys package would need update, but also all packages that contain revoked signatures would need update, otherwise the build fails. On the other hand, keeping the key in the ring is a security risk: The previous version signature before revocation time may be OK, but next version may be malicious. (And GPG does not implement trusted time stamps.) I did not found a way, how to prevent following warning: gpg: WARNING: Using untrusted key! (I do not want to use web of trust, but instead of it fully trust all keys in the locally stored read-only keyring.) -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec(a)suse.cz Lihovarská 1060/12 tel: +49 911 7405384547 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 To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 4

[opensuse-packaging] Python modules
by Nelson Marques 21 Sep '12

21 Sep '12

Hi all, I've submitted a new package to devel:languages:python, python-beautifulsoup4 after consulting the maintainer from python-beautifulsoup. Currently python-beautifulsoup requires Python >= 2.6, and this includes Python 3. For the Python 3 builds, there's some wizardry required to convert a few bits of code, which suggests a new package from the same source, since it's a sweet package for either Python2 or Python3. I don't really care if Python 2 is slowly disappearing. What would be best to proceed on this and how to differentiate the packages ? Any help will be most welcome. NM -- 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] baselibs / -32bit packages
by Nelson Marques 20 Sep '12

20 Sep '12

Hi, I need to create a -32bit package for one of my packages; Anyone can give me a quick example on how to do this? (this is for my infinality freetype package) NM -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 3

[opensuse-packaging] Re: [opensuse-factory] Moving forward with systemd
by Cristian Rodríguez 20 Sep '12

20 Sep '12

El 20/09/12 10:02, Frederic Crozat escribió: > build kernel with autofs4 built-in (systemd will modprobe it anyway, but > we could save some boot time by not having to do so). Ok, we need to bug kernel developers with this.. ;) >> Related to this : daemons must run with PrivateTemp set to true and see >> a way to provide exclusive temporary directories to users in a sensible >> manner such as pam_mktemp (?) or similar. > > Must is a bit hard for PrivateTmp, I'd suggest "should". Yeah, we probably need an script that checks the binary AND the linked libraries for usage of mkstemp(3) mkdtemp(3), mktemp(3), tempnam(3), tmpfile(3), tmpnam(3) functions and tell us if we really need that. -- 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] Question about release numbers in branched packages
by Andrey Borzenkov 19 Sep '12

19 Sep '12

I am new to openSUSE packaging workflow so please bear with me. When I branch some package, it gets release number based on revision of parent package; later release number is incremented with each commit/rebuild, so if I install branched package it will come newer than parent. Is it correct? Now after I submit changes to parent package and it is accepted - will release number of parent package automatically compare newer than my local branch once it is available from official repository? On other systems I had to locally extend release number to make sure it will update "upstream" package it is based on, but will be overwritten if upstream gets updated. How does it work in openSUSE? Related question is for package version bump. If I update package branch to new version and submit it - is it ensure that package from official repository will come newer than my local build? 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] Building a package with older version
by openSUSE user 19 Sep '12

19 Sep '12

Hi, all. Tell me, please, how can I build locally a package with an older version of build dependent package (older than in the repository) with "osc"? Interest options: a) The old version of a depended package is available in some repository, b) The old version of a depended package is available only locally, on HDD. Best regards. -- 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 Nelson Marques 18 Sep '12

18 Sep '12

Hi, I'm trying to integrate MATE with openSUSE, and I believe most of the stuff is actually done; I'm just struggling with mate-screensaver (keyring and PAM ?) which fails big time... I've taken a look at the GNOME 2 packages and made actually some advancemente, but I'm still getting no results... /var/log/messages spits out the following : Sep 18 19:55:37 mantis mate-screensaver-dialog: gkr-pam: unlocked login keyring Sep 18 19:55:37 mantis mate-screensaver-dialog: pam_unix2(mate-screensaver:auth): conversation failed Sep 18 19:55:39 mantis mate-screensaver-dialog: gkr-pam: unlocked login keyring Sep 18 19:55:39 mantis mate-screensaver-dialog: pam_unix2(mate-screensaver:auth): conversation failed The packages are on X11:MATE. by any means, can someone help me? I don't really understand much of PAM and there's something here I can't beat all by myself :/ NM -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 2

[opensuse-packaging] ncurses maintainers please help fix "presage" package.
by Marguerite Su 18 Sep '12

18 Sep '12

Hi, packagers, I'm preparing for fcitx 4.2.6 updates in home:csslayer:fcitx repository. And I found something unbelievable about ncurses-devel: https://build.opensuse.org/package/show?package=presage&project=home%3Acssl… In this "presage" package, I can't build "presage-demo" package for openSUSE: [ 62s] [137/306] preinstalled libncurses5-5.9-12.5.1 [ 62s] [138/306] installing libncurses6-5.9-12.5.1 [ 78s] [267/306] installing ncurses-devel-5.9-12.5.1 [ 111s] checking for initscr in -lcurses... no [ 111s] configure: WARNING: curses library not found. curses demo programs will not be built. [ 111s] checking curses.h usability... yes [ 111s] checking curses.h presence... yes [ 111s] checking for curses.h... yes But the same BuildRequires works in Fedora. The related presage code in src/tools/presageDemo.cpp 129:3 is: // curses initscr(); noecho(); cbreak(); keypad(stdscr, TRUE); clear(); refresh(); disclaimer(); So where's "initscr" function goes in our ncurses? Thanks in advance Marguerite -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 16

[opensuse-packaging] local package does not override global package
by Olaf Hering 18 Sep '12

18 Sep '12

In devel:languages:ocaml I changed the BuildRequires in the ocaml-findlib package from 'ocaml-camlp4-devel' to 'camlp4' to make it compatible with the binary names within sles11*. The new ocaml-camlp4-devel package provides and obsoletes camlp4. Now the buildservice has trouble to understand that ocaml-camlp4-devel from the same project provides camlp4.rpm, instead it wants to use the older standalone camlp4.rpm as shipped with 11.4 and 12.1. obs/devel:languages:ocaml/ocaml-findlib $ obs r -v openSUSE_11.4 i586 unresolvable: nothing provides ocaml = 3.12.0-2.1 needed by camlp4 openSUSE_11.4 x86_64 unresolvable: nothing provides ocaml = 3.12.0-2.1 needed by camlp4 openSUSE_12.1 i586 unresolvable: nothing provides ocaml = 3.12.0-11.1.2 needed by camlp4 nothing provides ocaml(Arg) = 877340141c0babb58b3aaef2f5b70fc9 needed by camlp4 openSUSE_12.1 x86_64 unresolvable: nothing provides ocaml = 3.12.0-11.1.2 needed by camlp4 nothing provides ocaml(Arg) = 877340141c0babb58b3aaef2f5b70fc9 needed by camlp4 I can certainly add a conditional BuildRequires, but: How can this be fixed properly? Olaf -- 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] No upstream changelog available
by Nelson Marques 18 Sep '12

18 Sep '12

One of the crap things about Cinnamon is that there's no changelog available from upstream; The Debian packages from upstream have no changelog also beyond the 'update to version x.y.z'... what should I write in the changelog ? NM --- Artigo 21 - Direito à Resistência Todos têm o direito de resistir a qualquer ordem que ofensa os seus direitos, liberdades e garantias e de repelir pela força qualquer agressão, quando não seja possível recorrer à autoridade pública. Constituição da Républica Portuguesa -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 7

[opensuse-packaging] Marketing Jur�dico | Newsletter Inrise Consultoria | Edi��o 27 | Ano 05
by Inrise RH 18 Sep '12

18 Sep '12

1 0

[opensuse-packaging] package versioning
by Nelson Marques 18 Sep '12

18 Sep '12

Dear all, I have a simple question; Let's imagine we have a package 'foobar'; which the latest stable release is 1.0. Someone decides to to update to git snapshot and uses a version based on the date, for example: 20121017, where the NEVRA goes into something like: Name: foobar Epoch: 0 Version: 20121017 Release: 0 Arch: noarch Now after two years of git snapshotting we get an official release, lets say, 1.1; Would it normal to suppose that version wise: 20121017 > 1.1 Eventually my guess was that we should enforce Epoch to get back into track and make sure 1.1 would replace the former packages; If I understood correctly it is not wise to use Epoch within openSUSE and it should be banned... So... How do we get this update going ? This is just an hipotetical case, though I can remember of few examples currently in production, which don't for this case; I'm mainly interesting in knowing how to deal with this in openSUSE. Thanks. NM -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 5

[opensuse-packaging] required perl modules not included in package Requires
by Olaf Hering 17 Sep '12

17 Sep '12

Is there a reason why the required modules of a perl script are not encoded in the Requires of a package? In the example below I would expect a Requires: perl(Data::Dumper) to be included in inst-source-utils to pull in all required packages to actually run the script. Olaf root@carron:~/X # sed -n '/^[[:blank:]]*use[[:blank:]].*::/p' /usr/bin/createpatch use Data::Dumper; use File::stat; use File::Temp qw/ tempdir /; use Time::localtime; use Getopt::Long; root@carron:~/X # rpm -qf /usr/bin/createpatch inst-source-utils-2012.2.3-0.5.1 root@carron:~/X # rpm -qf --requires /usr/bin/createpatch gpg2 recode rpmlib(VersionedDependencies) <= 3.0.3-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1 /bin/bash /bin/sh /usr/bin/perl rpmlib(PayloadIsLzma) <= 4.4.6-1 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

7 8

[opensuse-packaging] Adding openSUSE 12.2 repository for devel:languages:pascal
by Kirill Kirillov 15 Sep '12

15 Sep '12

Hello, all Could you please add openSUSE 12.2 repository in openSUSE Build Service - devel:languages:pascal project. It is needed by 'hedgewars' game, which aggregates 'fpc' package from this repository, so for now this game cannot be built for oS 12.2 due to this fact. Thanks. -- Kirill Kirillov <>< -- 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] Conflicting C and C++ declarations?
by Ilya Chernykh 15 Sep '12

15 Sep '12

What should I do? [ 49s] ./main.h:38:15: error: previous declaration of 'char** environ' with 'C++' linkage [ 49s] In file included from util.cpp:45:0: [ 49s] /usr/include/unistd.h:546:15: error: conflicts with new declaration with 'C' linkage https://build.opensuse.org/package/rawlog?arch=x86_64&package=xxdiff&projec… -- 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] Sub packaging or extra
by Togan Muftuoglu 15 Sep '12

15 Sep '12

Hi, It is a general question actually, but what is the recommended approach when one is packaging more then one source package? I have a main package with its' source file and then small source packages that would enhance the main package and some of them have different licenses in relation to the main source. These small packages do need the main package as otherwise they are useless. Currently I am inclined to create sub packages so when eventually the package goes in to Factory, I don't have to submit X number of packages but only one ;). However, experience has taught me as well when the package is maintained for different releases then there are lots of if/else/endif blocks going on and with these sub-packages it means more work to keep them building and functioning as the spec file itself becomes big. On the other hand if I create separate packages that would mean I need to submit each one separately and still need to maintain for the different releases. It probably is a taste issue, but would like to hear others' thoughts as well 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] vdr, lirc, dvb looking for new maintainer
by Ludwig Nussel 14 Sep '12

14 Sep '12

Hi, Due to lack of hardware I no longer actually use lirc nor vdr so I shouldn't be maintaining the packages anymore either. I hardly invested any time in those packages the last years but still had no complaints. So either noone uses them either or the software is just perfect :-) Anyone willing to take over maintainership? cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 11

[opensuse-packaging] Why this package fails without even starting build?
by Ilya Chernykh 13 Sep '12

13 Sep '12

https://build.opensuse.org/package/show?package=xxdiff&project=home%3AAnsus… -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 3

[opensuse-packaging] plan for 12.3 - multiple Python runtimes
by Jan Matejek 13 Sep '12

13 Sep '12

fellow openSUSErs, with the advent of Python 3 and still almost unnoticeable decline of Python 2, i have come to a realization that the way we separate them into "python" and "python3" is less than ideal. The granularity of this can be often too coarse (you can't run two apps requiring two different python2 versions, unless they are specifically packaged and bring their own python runtime package), and too fine at the same time (there are already packages that don't actually care whether they run in python 2 or 3) In the spirit of fixing what ain't broken, I humbly propose a grand plan: let's turn "python" into "python2.7", "python3" into "python3.3", and tinker with Provides until it all works just fine. Then, as a last step, symlink /usr/bin/python into /etc/alternatives and let the users pick whichever runtime they like better. This would probably go better if broken into several phases. My current idea is this: Phase 1: - rename "python" to "python2.7", providing "python = 2.7" - rename "python3" to "python3.3", providing "python3 = 3.3" - install the update-alternatives symlink Impact: - Unsure of what would happen on package upgrade. Would we need Obsoletes/Provides combo for this? Perhaps we'd have to create the metapackages outlined in the following phases at this point already. Phase 2: - unify RPM macros - python3 will have %py_(something) macros as well as %py3_(something) macros, the %py3_ versions being aliases to the %py_ versions - make python2.7 provide "python2 = 2.7" instead of "python = 2.7" - make a "python" meta-package requiring, at this time, python2 - each pythonX.Y package now only installs /usr/bin/pythonX.Y binary, python2 and python3 are alternatives for python2.Y and python3.Y respectively, and python is an alternative for either python2, python3, or a specific version. I don't know update-alternatives too well - is this even viable? Impact: - this should mark a clear upgrade path for each of the python variants and for the systemwide "default python" as well - at this phase, i would like to make it possible to build a package for any python (2 or 3 or 50) from the same specfile. i'm not sure that these outlined steps are enough, though. Originally I thought that every python would provide "python = X.Y" and the packages could select which "Requires: python" to pick through package or project meta. But that would result in a horrible breakage, and we need "python" as a separate package for upgrading in any case. We could use "python(abi)" symbol for this, or do the same just with "python-devel"? Any other options? Phase 3A: - when python 3.4 comes out, introduce a new package "python3.4", new meta-package "python3" requiring "python3.4", and corresponding alternatives Impact: - This is the other difficult one. What about lifetime of the pythonX.Y packages? What happens with old systems on perpetual-upgrade? Such as tumbleweed - will the old python runtimes rot there forever-and-ever, or can we force uninstall at some point? Perhaps "Obsoletes: python3 < 3.x" in the "python3" metapackage? Which versions do we support? The newest and the most popular, probably? I know we do something similar with gcc, how does it work there? Phase 3B: - steal and improve Debian's python-central (or however they call it these days) - designate /usr/lib/python-central or something similar for packages that don't want to depend on a specific python runtime version - introduce %post/%postun scriptlet macros for packages that would compile bytecode in /usr/lib/python-central for all known python runtimes on the system, and for pythons so that they compile every package for their versions. This is now actually fully supported by upstream, we can have as many different versions of bytecode for the -same- .py file as we want. Impact: - package can specify "Requires: python" and Just Work(tm) from now until eternity, or until it runs into a deprecated API. Or specify a range of pythons it wants to support - by the time we get here, I'm sure RPM will allow that ;e) With a limited ABI in python3, this can even work for arch-based packages across python minor versions. Phase 4: - when we decide to switch to python3 system-wide, make "python" require "python3" instead of "python2", change default alternative, and be done with it Impact: - breakage of packages still incompatible at that time. that will help us see what needs fixing and what needs to explicitly specify that it wants python2. Somewhere in this is lurking a possibility of supporting different python runtimes such as Jython, Cython, PyPy and whatever else crops up. That's neat, too. Thanks for your attention. Comments, questions? regards m. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

7 11

[opensuse-packaging] So I packaged up darcs; now what do I do with it?
by Damien Radtke 13 Sep '12

13 Sep '12

Darcs is a version control system written in Haskell, and in order to learn more about packaging, I decided to try and package it up. As luck would have it, I now have a fully packaged version sitting in my home repository: https://build.opensuse.org/package/show?package=darcs&project=home%3Akog13 It has build dependencies on packages in devel:languages:haskell and devel:languages:haskell:next, but the program itself can be used for more than Haskell development. So my question comes in several parts: 1) Where would the ideal place to submit this package be? Is it too late to get it in one of the default repos for 12.2, or would Packman be better? 2) Am I correct in thinking that the repos holding build dependencies (in this case, the haskell development repos) aren't necessary to be subscribed to when a user installs it? 3) What are some things to keep in mind when trying to submit new packages to a repository? I'm pretty new at this, so any help or advice is welcome. Thanks, ~Damien -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

7 7

[opensuse-packaging] Where do screenshots come from?
by Greg Freemyer 12 Sep '12

12 Sep '12

All, I recently packaged httrack and I see on http://software.opensuse.org/search?q=httrack there is a screenshot. I'm just curious where that came from. Greg -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 3

[opensuse-packaging] SLE11 and libgomp
by Claudio Freire 11 Sep '12

11 Sep '12

Hi. Another issue with SLE11 I cannot find information about. I have a package that requires libgomp, but a specific version of it. All other opensuse versions work by BuildRequiring "libgomp.so.1(GOMP_2.0)". But SLE11 doesn't seem to get the hint. Thing is, the build log[0] says libgomp46 is being installed, which ought to be right (libgomp45 works). But somehow, it isn't. I could find the gcc packages in OBS for openSUSE, to try to see what may be wrong with the BuildRequires, and in fact that's how I came up with that buildreq. But not for SLE. Any idea guys? [0] https://build.opensuse.org/package/live_build_log?arch=x86_64&package=octav… -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 5

[opensuse-packaging] Packaging Guidelines documentation in need of TLC
by Togan Muftuoglu 11 Sep '12

11 Sep '12

Hi, I was going to update couple of lua packages but I could not found any relevant information of lua packaging in <http://en.opensuse.org/openSUSE:Packaging_guidelines>. Now Fedora has a draft documentation at <http://fedoraproject.org/wiki/PackagingDrafts/Lua> and Debian has <http://pkg-lua.alioth.debian.org/policy.html> But the problem is not limited lua only, as currently openSUSE has no packaging policy for Lisp, Haskel, R. So looks like the documentation is neeeding TLC (Tender Love Care) if the goal is to have a higher packaging quality (ie. well documented patches and etc) Togan -- 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] python-bindings ?
by Greg Freemyer 10 Sep '12

10 Sep '12

All, I was looking at the upstream sample specfile for one of my packages (libewf) and it has a python bindings sub-package that I don't currently have. The sample has: %files python %defattr(644,root,root,755) %doc AUTHORS COPYING NEWS README %{_libdir}/python*/site-packages/*.la %{_libdir}/python*/site-packages/*.so I don't think I've ever packaged a .la file, so it seems I should exclude that. Is that right? Greg -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 7

[opensuse-packaging] Problem building an appliance
by Ilya Chernykh 07 Sep '12

07 Sep '12

When trying to build an appliance in Suse Studio I receive the following message: === Nothing provides package libxine1-codecs which is needed by package providing libxine1-codecs Remove providing libxine1-codecs === The entire "providing libxine1-codecs" is bold as a package name. When I click to remove it does nothing and the error message remains. No selected package has "xine" in name. I wonder what should I do to bypass this error. -- 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] Architecture question (noarch or i586/x86_64?)
by Karl Ove Hufthammer 06 Sep '12

06 Sep '12

Dear list members, I’m creating my first package, but I’m not sure if it should be considered noarch or i586/x86_64, and the documentation varies on the exact definition of noarch. Basically, my package *is* architecture-neutral, as the exact same package should work on all architectures, without any need for recompiling. Some features of this package: – Contains no binary (compiled) executable files. – Does contain a no-binary executable file – a shell script, which *uses* other binaries, like grep and awk and coreutils stuff. – Contains *data* files that are ‘built’. So, should it be considered noarch (rpmlint thinks so) or i586/x86_64? This is the package (and I’d appreciate any comments, as this is my first package): https://build.opensuse.org/package/show?package=ordbanken&project=home%3Ahu… -- Karl Ove Hufthammer http://huftis.org/ Jabber: karl(a)huftis.org -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

7 9

[opensuse-packaging] Dangling symblink warnings
by Togan Muftuoglu 06 Sep '12

06 Sep '12

Hi, I am trying to use rc* symlink for systemd services as outlined in <http://lists.opensuse.org/opensuse-factory/2012-07/msg00066.html> for Factory builds rctargets="shorewall shorewall-lite shorewall6 shorewall6-lite" for i in $rctargets; do %if 0%{?suse_version} > 1220 ln -sf /sbin/service %buildroot%_sbindir/rc${i} %else ln -sf %_initddir/${i} %buildroot%_sbindir/rc${i} %endif done but I am getting these warnings " shorewall6-lite.noarch: W: dangling-symlink /usr/sbin/rcshorewall6-lite /sbin/service horewall6.noarch: W: dangling-symlink /usr/sbin/rcshorewall6 /sbin/service shorewall.noarch: W: dangling-symlink /usr/sbin/rcshorewall /sbin/service shorewall-lite.noarch: W: dangling-symlink /usr/sbin/rcshorewall-lite /sbin/service The target of the symbolic link does not exist within this package or its file based dependencies. Verify spelling of the link target and that the target is included in a package in this package's dependency chain." How can I fix this warning as /sbin/service is in aaa_base Thanks Togan -- 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] spec-cleaner breaking SLES build compatibility?
by Greg Freemyer 05 Sep '12

05 Sep '12

All, I noticed that security:srm was failing to build for OS 12.2. As part of doing the trivial clean up to make it work I ran spec-cleaner. It made this change in the install section: -make DESTDIR=$RPM_BUILD_ROOT install +%make_install Now srm in my home project no longer builds for SLES. The relevant error is "line 23: fg: no job control" Is that expected? Should I worry that in fixing OS 12.2 to build I broke SLES? My version of the project is at: https://build.opensuse.org/package/show?package=srm&project=home%3Agregfree… Greg -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

5 7

[opensuse-packaging] To %make_install or to %makeinstall (spec-cleaner)
by Joop Boonen 05 Sep '12

05 Sep '12

Hi all, I have been using spec cleaner for while. What I notice it that it uses macro %make_install instead of %makeinstall. Both macros are OK for openSUSE but the first one breaks the build for SLE. <quote> + %make_install /var/tmp/rpm-tmp.59594: line 45: fg: no job control </quote> I wonder if this should be fixed, in either spec-cleaner (use%makeinstall in stead of %make_install) or in the buildserver (add macro %make_install for SLE)? Regards, Joop. See also: https://bugzilla.novell.com/show_bug.cgi?id=712171 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

9 12

[opensuse-packaging] Не знаю что делать
by Соболевская Галюся 04 Sep '12

04 Sep '12

Хай ты симпотяжка, если скучно и есть желание подружиться заходь ко мне на страничку http://demsac.org/media.php -- 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] Changes in the openSUSE Review team
by Andreas Jaeger 01 Sep '12

01 Sep '12

The review of packages to openSUSE Factory and the released openSUSE distributions have been done in the past by an SUSE internal team. Sascha Peilicke, who's currently on paternal leave, did the vast majority of reviews in the past months. We have now properly formed a review team and started discussing our guidelines and best practices. We created a couple of wiki pages to describe what we are doing (use http://en.opensuse.org/openSUSE:Factory_submissions). If you like to reach the review team directly, please send an email to review(a)opensuse.org. In general, policy discussions and changes will happen on the opensuse-packaging mailing list. The team currently consists of Andreas Jaeger, Berthold Gunreben, Craig Gardner, Dominique Leuenberger, Lars Vogdt, Marcus Rückert, Michal Vyskocil, Rüdiger Oertel, Sascha Peilicke. We'd like to grow the team slowly over time with packagers that have shown good review and packaging skills. Our goal is to document our guidelines - and do a good review to improve the quality of openSUSE's packages. If we err, please tell us - we cannot know everything and might sometimes be too cautious if we do not understand what and why something gets changed. 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

8 15

[opensuse-packaging] updating desktop files?
by Greg Freemyer 01 Sep '12

01 Sep '12

All, Someone packaging a SLES version of httrack advised this should work in the specfile without patching the code: %suse_update_desktop_file WebHTTrack-Websites Network WebBrowser %suse_update_desktop_file WebHTTrack Network WebBrowser httrack in the security repo currently has the below patch instead. When I try the above in the httrack version in my home project (home:gregfreemyer:Tools-for-forensic-boot-cd), it fails to build. Is there an openSUSE way to handle this in the specfile and not with a patch? ============ --- html/server/div/WebHTTrack.desktop 2011-07-16 20:07:20.000000000 -0500 +++ html/server/div/WebHTTrack.desktop.orig 2011-07-16 20:03:59.000000000 -0500 @@ -1,9 +1,9 @@ [Desktop Entry] Version=1.0 Type=Application -Categories=Network; +Categories=Network;WebBrowser; Terminal=false Name=WebHTTrack Website Copier Comment=Copy websites to your computer Exec=webhttrack -Icon=/usr/share/httrack/icons/webhttrack.xpm +Icon=webhttrack --- html/server/div/WebHTTrack-Websites.desktop 2011-07-16 20:02:26.000000000 -0500 +++ html/server/div/WebHTTrack-Websites.desktop.orig 2011-07-16 20:04:28.000000000 -0500 @@ -1,9 +1,9 @@ [Desktop Entry] Version=1.0 Type=Application -Categories=Network; +Categories=Network;WebBrowser; Terminal=false Name=Browse Mirrored Websites Comment=Browse Websites Mirrored by WebHTTrack Exec=webhttrack browse -Icon=/usr/share/httrack/icons/webhttrack.xpm +Icon=webhttrack Greg -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 3