December 2011 - openSUSE Packaging - openSUSE Mailing Lists

[opensuse-packaging] namespace for system users?
by Ludwig Nussel 11 Feb '12

11 Feb '12

Hi, There's a request to add a system user 'tor': https://build.opensuse.org/request/show/96531 There is no name space separation between system users and actual logins. So especially for short names like the above there is a chance that it could collide with an already existing user name on some system. Having a system service running with the uid of an actual user isn't desirable. So what about mandating an extra prefix or suffix to (new) system user names like 'daemon' or 'service'? Ie in the above example the user name would be 'tor-daemon' or 'tor-service' instead of 'tor'. Other thoughts? 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

8 11

[opensuse-packaging] don't understand the new licenses
by Sascha Manns 10 Jan '12

10 Jan '12

Hello mates, i'm trying to build a new packageversion. The old Licenses Field was "GPLv3 or later". If i'm going to: http://license.opensuse.org/ and place GPLv3 there, the Site proposes to use "GPL-3". If i'm placing this into the Licenses Field i become: kvirustotal-lang.noarch: W: invalid-license GPL-3 kvirustotal.x86_64: W: invalid-license GPL-3 kvirustotal.src: W: invalid-license GPL-3 The specified license string is not recognized. Please refer to http://license.opensuse.org/ for the list of known licences and their exact spelling. But why this false? Does anyone knows more? Wish all a happy X-Mas Sascha -- Sincerly yours Sascha Manns Community &Support Agent open-slx GmbH http://www.open-slx.de (Business) http://saigkill.homelinux.net (Private) This mail is written with Balsam Professional 12.1

5 6

[opensuse-packaging] Is there a quick way to test all Requires are in factory?
by Greg Freemyer 10 Jan '12

10 Jan '12

All, More than once I have submitted something to factory that didn't have all the requires and buildrequires pieces already there. Is there a simple test I can run on the package to verify that before I submit a new package? In this specific case, I want to submit security -- log2timeline. I've been slowly submitting all the pre-reqs and I think I finally have everything in factory. 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 21

[opensuse-packaging] Submitting multiple changes against phpunit packages
by Robert Munteanu 05 Jan '12

05 Jan '12

Hi, I've branched server:php:applications to https://build.opensuse.org/project/packages?project=home%3Arobert_munteanu%… and updated a couple of packages, fixing https://bugzilla.novell.com/show_bug.cgi?id=734936 . These packages are in a dependency tree, and I'm not sure how to submit requests for them. Should I start with the leaves and once they are accepted submit the parents, or should I submit them all at once and mention that they should be reviewed/merged together? Thanks, Robert -- Sent from my (old) computer -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 1

Re: [opensuse-packaging] %if 0%{?suse_version} >= 1210 not working?
by Lutz Thuns 02 Jan '12

02 Jan '12

Am 07.12.2011 05:50, schrieb Cristian Rodríguez: > Use > 1140 instead ;-) Guess what? ;) Doesn't work either. I've changed to the following: %if 0%{?suse_version} <= 1140 %patch0 -p1 %endif %patch1 -p1 %patch2 -p1 %patch4 -p1 %patch5 -p1 %if 0%{?suse_version} > 1140 %patch6 -p1 %endif So patch0 should affect all releases from including 11.4 and downwards. patch6 should affect all releases above 11.4. Again, patch6 is only applied in Factory, not 12.1. Maybe the build target has a wrong suse_version? https://build.opensuse.org/package/show?package=lxdm&project=home%3AlOtz100… --- Lutz Thuns openSUSE member (lOtz1009) LXDE team -- 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] Global SRPM Centos compatibility: _docdir issues
by H. David Ross 31 Dec '11

31 Dec '11

I'm attempting to build an RPM for a more recent version of the global tag suite than currently available for Centos 6.x, using SRPMs from https://build.opensuse.org/package/show?package=global&project=openSUSE%3AF… OBS Global Project . Several minor issues related to the _docdir macro generate build/rpmlint errors. It wouldn't be difficult to hack the spec/config info allowing the build to complete. This my first venture in to RPM development/troubleshooting. I'd rather make a small contribution toward "draining the swamp" than snuff a few alligator hatch-lings. The issues are: * Makefile.am (top directory of source tree) has: gtagsdir = ${datadir}/doc/packages/global * global.spec assumes %{_docdir} = %{_datadir}/doc/packages * CentOS does not appear to define %{_docdir}, dispite a few references to it in other macros * %{_docdir} is listed in OpenSuse Packaging Guidelines, but not in guidelines any other Distro Builds fail in %install, because the %{_docdir} is empty or substituting %{_datadir} file source/destination paths are not symmetric relative to the build/buildroot. Comments/suggestions about reporting/correcting cross-distro discrepancies would be appreciated. If difference can be mapped through macros it might be useful to collect and distribute them. david -- View this message in context: http://old.nabble.com/Global-SRPM-Centos-compatibility%3A-_docdir-issues-tp… Sent from the opensuse-packaging mailing list archive at Nabble.com. -- 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] Re: [opensuse-buildservice] %clean section in rpm packages in OBS
by Joop Boonen 23 Dec '11

23 Dec '11

Hi Nelson, This sounds great. Does anyone know if a wiki page will be created / updated about how spec files should look like? As I look at your reply, I'm thinking about SLE(S|D)10 and maybe even SLE(S|D)11 they won't be handling a missing %clean correctly as their rpm is 4.4.2. So I wonder if it's a good idea to remove %clean now? Regards, Joop. On Fri, December 23, 2011 11:25 pm, Nelson Marques wrote: > With RPM 4.9+ you no longer require the %clean section, it's done > automatically. There's the new %check section amongst other things... > Newer versions of RPM shouldn't require either the > %defattr(-,root,root,-) as they should be doing it by default... and > if things are like in Fedora, the BuildRoot should be handled > automatically also (not sure if implemented on OBS). > > NM > > 2011/12/23 Joop Boonen <joop.boonen(a)boonen.org>: >> All, >> >> I have a question lately I see spec files that have been changed with >> the >> remark (cf. specfile guidelines). >> >> The %clean section has been removed for example, this doesn't feel right >> to me. >> >> Does anyone know something about the cf. specfile guidelines? >> Did I miss something? >> >> Regards, >> >> Joop. >> >> >> -- >> To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org >> To contact the owner, e-mail: opensuse-buildservice+owner(a)opensuse.org >> > > > > -- > Nelson Marques > > /* http://www.marques.so > Â nmo.marques(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

2 2

[opensuse-packaging] remove libtool from prjconfig
by Stephan Kulow 22 Dec '11

22 Dec '11

Hi, You may have noticed: I added libtool as buildrequire to many packages. Now that I'm through with my list, I would like to remove libtool from the projconfig. After that you need to buildrequire libtool if you need it otherwise the package will fail, but unless something slipped this should not be the case for any package in factory. Next stop: automake Greetings, Stephan -- Sent from openSUSE -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 7

[opensuse-packaging] Check in review delay: Vacation Christmas and New Year`s Eve 2011/2012
by Lars Vogdt 20 Dec '11

20 Dec '11

Dear Packagers, during the time from the 24th Dec 2011 until 08th Jan 2012 (Christmas/New Year´s Eve) many teams and departments inside the SUSE Linux Products GmbH will be on vacation or can only offer limited services. This affects also the "autobuild-team" you might know as reviewers for your packages submitted to Factory (and other released distributions). While some of us are still in the office to get the most annoying and security bugs fixed and out to you as our customers, most of us are using this period to spend some time aside of computers and with their friends and families. As result, packages in openSUSE:Factory might stay a bit longer in the "review" state as you can expect in normal times. Please be not so angry with us in this case - just do the same and use this time for regeneration and preparation for the upcoming openSUSE year. We wish you and your families a Merry Christmas and a Happy New Year! Ah: and remember to have a lot of fun! ;-) Lars -- Lars Vogdt <Lars.Vogdt(a)suse.com> - OPS Engineering Services Teamlead - SUSE Linux Products GmbH - GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer Maxfeldstraße 5, 90409 Nuernberg, Germany - HRB 16746 (AG Nuernberg) -- 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] Obsoleted %suse_update_desktop_file
by Stephan Kulow 20 Dec '11

20 Dec '11

Hi, Over the last couple of days I reworked update-desktop-files not to rely on an explicit %suse_update_desktop_file call. Instead Factory will have an additional brp script that trims the translations from .desktop files. So: if you can live with an rpmlint warning on older distributions (I submited a rpmlint with the warning gone for factory), you can skip the macro now if you call it without options. The most useful option of the macro should be the -n option now, as this one will mark the .desktop file with translate=false, which then also skips the trimming. There is one problem with removing the buildrequires on update-desktop-files though: this package includes rpm provide triggers for mimehandler(), so don't remove the buildrequire if you have MimeType= in your .desktop file. Or we move that triggers to a package always installed in factory. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

6 19

[opensuse-packaging] what fixes needed to resolve build failure
by doiggl＠velocitynet.com.au 17 Dec '11

17 Dec '11

Hello How can this error be fixed - see[1] spec file - see[2] full log - see[3] Thanks Glenn [1] In file included from ../../../libCAdata/src/Module.h:6:0, from ../../../libCAdata/src/CaProfileWriter.h:35, from opdata_handler.cpp:34: ../../../libCAdata/src/Function.h: In member function 'bool CA_Function::compares(const CA_Function&, wchar_t*, size_t) const': ../../../libCAdata/src/Function.h:179:42: warning: variable 'aend2' set but not used [-Wunused-but-set-variable] mv -f .deps/OpreportXMLHandler.Tpo .deps/OpreportXMLHandler.Plo mv -f .deps/opxmldata_handler.Tpo .deps/opxmldata_handler.Plo mv -f .deps/opdata_handler.Tpo .deps/opdata_handler.Plo make[5]: Leaving directory `/home/abuild/rpmbuild/BUILD/CodeAnalyst-3_1_4_0230-Public/src/ca/libs/libopdata' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/home/abuild/rpmbuild/BUILD/CodeAnalyst-3_1_4_0230-Public/src/ca/libs/libopdata' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/abuild/rpmbuild/BUILD/CodeAnalyst-3_1_4_0230-Public/src/ca/libs' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/abuild/rpmbuild/BUILD/CodeAnalyst-3_1_4_0230-Public/src/ca' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/abuild/rpmbuild/BUILD/CodeAnalyst-3_1_4_0230-Public/src' make: *** [all-recursive] Error 1 error: Bad exit status from /var/tmp/rpm-tmp.HBFEDO (%build) [2]-spec file https://build.opensuse.org/package/rawlog?arch=x86_64&package=CodeAnalyst&p… [3]log file https://build.opensuse.org/package/view_file?file=CodeAnalyst.spec&package=… -- 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] RPMLINT: Badness exceeds threshold - unsure why
by David Lemke 17 Dec '11

17 Dec '11

I'm not sure what needs to be done to reduce the badness of this package. Maybe I'm just not seeing something, or maybe I have failed to grasp some concept, or maybe *shrug*... Anything to set me on the path to success would be greatly appreciated! ------ cut ------ Preparing packages for installation... gelide-0.1.5.git20111210-13.1 ... running 01-check-debuginfo ... testing for empty debuginfo packages ... running 02-check-gcc-output ... testing for serious compiler warnings (using /usr/lib/build/checks-data/check_gcc_output) (using //.build.log) ... running 03-check-binary-kernel-log ... running 04-check-filelist ... checking filelist ... running 05-check-invalid-requires ... running 06-check-installtest ... testing for pre/postinstall scripts that are not idempotent ... running 08-check-permissions ... testing for modified permissions ... running 09-check-packaged-twice ... running 10-check-lanana ... running 12-check-libtool-deps ... testing devel dependencies required by libtool .la files (can be skipped by "skip-check-libtool-deps" anywhere in spec) ... running 13-check-invalid-provides ... running 14-check-gconf-scriptlets ... testing GConf scriptlet presence ... running 99-check-remove-rpms ... removing all built rpms (order: reverse gelide) RPMLINT report: =============== (none): E: badness 30100 exceeds threshold 1000, aborting. [ 385.000533] SysRq : Power Off [ 386.558475] Power down. ----- cut ----- https://build.opensuse.org/package/rawlog?arch=x86_64&package=gelide&projec… -- 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] RFC: Enforce PrivateTmp in systemd units
by Cristian Rodríguez 16 Dec '11

16 Dec '11

Hi: Pretty much every week, security bugs pop up about race conditions in handling temporary files in software, this places a burden on maintenance which currently has a solution when using systemd, the PrivateTmp setting, that when set to true the daemon will be started with a private /tmp namespace, which is inaccessible to other processes outside the namespace. Pretty much every single package with the exception of X and a few others can benefit from this. Advantages: - Every single daemon has its own tmp space, safely handled by the kernel, other processes can no longer sniff there - If the process in question crashes or goes away in any form, the namespace is cleaned up automatically. -Disadvantages: - There may still be some bugs. - The quirks mentioned here http://www.linux-archive.org/development-discussions-related-fedora-devel-l… https://fedoraproject.org/wiki/Features/ServicesPrivateTmp proposal is to ask the security team to evaluate this feature and switch the default in systemd. -- 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] format_spec_file service
by Stephan Kulow 16 Dec '11

16 Dec '11

Hi, I'm testing a new version of the format_spec_file service (you can find the sources on github's openSUSE project) and this results in submit requests of mine to: - remove #norootforbuild - remove duplicated group and license from sub packages - patch license field to apply to spdx.org (where I can, this needs to improve and is in discussion with legal how to handle the corner cases) - split buildrequires in single lines (I'll try to keep two adjacent buildrequire lines sorted). That should be what I changed, but just so you don't get afraid :) Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

8 41

[opensuse-packaging] What's the new SPDX name for a Public Domain license?
by Greg Freemyer 16 Dec '11

16 Dec '11

All, I don't see basic "Public Domain" in the SPDX list. So how do we designate it? In my specific case, the license reads: ============================================= Public Domain Software Simson L. Garfinkel Naval Postgraduate School Release Date: May 2010 The software provided here is released by the Naval Postgraduate School, an agency of the U.S. Department of Navy. The software bears no warranty, either expressed or implied. NPS does not assume legal liability nor responsibility for a User's use of the software or the results of such use. Please note that within the United States, copyright protection, under Section 105 of the United States Code, Title 17, is not available for any work of the United States Government and/or for any works created by United States Government employees. ===================================================================== Thanks Greg -- 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] RFC: Browser independent provides (fate#313084)
by Michal Vyskocil 16 Dec '11

16 Dec '11

Hi all, I got a bug about icedtea-web is not installed by default https://bugzilla.novell.com/show_bug.cgi?id=737105 I am sure that instead of relying on patterns, the problem can be solved very easily in icedtea-web package itself Supplements: packageand($BROWSER:java-openjdk) will push the package when browser and JRE is installed. However what is the $BROWSER? To my suprise we have 8(!) different browsers in Factory atm. But maintaing a list of several changing (security team might decide 8 more or less unmaintained browsers is too much) Supplements does not sound sexy for me, so I wrote a FATE#313084 Universal rpm symbol for browsers https://features.opensuse.org/313084 In short I propose add 1.) One common symbol for all browsers 'browser', 'browser-plugin', or 'browser(plugin)' 2.) Rendering engine specific one 'gecko' or 'browser(gecko)', 'webkit' and 'presto' Please share your opinion here or in the FATE. Thanks Michal Vyskocil

2 1

[opensuse-packaging] New request "declined" handling in OBS
by Adrian Schröter 16 Dec '11

16 Dec '11

I want to inform you about a planned change regarding request declined handling. It was raised as blocking issue that the request creator may not see a rejection (request set to "declined" state by target). While we send out mails by default via hermes, it may get missed. Also the pull model is not really accessable here. So we decided to follow other systems like github, where you have to act on declined requests. This means: 1) We show request on the "my work" webui page and on "osc my rq". 2) To get rid of these requests on that page you have basically three options: * revoke: You accept that this was the wrong way basically * superseded: You submitted an newer improved version * reopen: You disagree and ask back to take the request as it is. However this means that suddenly older "declined" requests will pop up at your place. You can see how this looks alike on the stage instance: https://build.opensuse.org/stage/home/my_work The new webui also offers to revoke or to re-open the request again. The osc in openSUSE:Tools:Unstable is supporting this as well and also offers to "supersede" requests in declined state when you submit a request. We consider also to change all requests from "declined" to "revoked" during deployment, so only new requests will popup. Please tell us your opinion about this change. thanks adrian -- Adrian Schroeter SUSE Linux Products GmbH email: adrian(a)suse.de -- 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] need link to project for building a Broadcom wireless driver
by doiggl＠velocitynet.com.au 15 Dec '11

15 Dec '11

Hello, Is there a project I could use to make a branch of, and use to build this driver [1] Can you send me a link to the project. Ta Glenn [1] Broadcom's wireless driver version 5.100.82.112 http://www.broadcom.com/support/802.11/linux_sta.php http://www.broadcom.com/docs/linux_sta/hybrid-portsrc_x86_32-v5_100_82_112.… http://www.broadcom.com/docs/linux_sta/hybrid-portsrc_x86_64-v5_100_82_112.… http://www.broadcom.com/docs/linux_sta/README.txt -- 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] Python 2 and Python 3 compatibility packaging
by todd rme 15 Dec '11

15 Dec '11

There are already some rough guidelines when dealing with python 3 packages, such as appending python3- to the beginning of the package name. However, these guidelines, as far as I have seen do not deal with one important case. Many python packages currently put files in /usr/bin or /usr/share. These files usually have not identifier linking them to particular python versions, which means that the same files are installed by both python 2 and python 3 versions of the package. This leads to a conflict between python 2 and python 3 packages, one this does not seem to be properly addressed by current packages. I see several solutions to this problem, all of which have benefits and drawbacks: 1. Add python version information to the beginning of the file name. For example, /usr/bin/sip becomes /usr/bin/python3-sip or /usr/bin/python3.2-sip. This has the benefit that it doesn't require any significant changes to current packaging. It has the disadvantage that anything looking for /usr/bin/sip will not find this file. Another disadvantage is that, as far as I have been able to find, python does not have a built-in way to do this, which would mean that the files have to be manually renamed. This is ugly and could potentially break things that are looking for specific file names, as well as making tab-completion on the command line less predictable. There is also a question of what would happen when python 2 support is ended, and a question of whether this would happen with python 3 packages or both python 2 and python 3 packages. 2. Add python version information at the end of the file name. So /usr/bin/sip becomes /usr/bin/sip-3 or /usr/bin/sip-3.2. This has similar issues to 1, but makes tab completion easier at the cost of making it unclear whether 3.2 is the version of sip or the version of python. 3. Create a new subdirectory in /usr/bin for python3 files. So for example /usr/bin/sip becomes /usr/bin/python3/sip or /usr/bin/python3.2/sip. This would require changing the path to include this directory. It has the advantage that the files in /usr/bin, which should be earlier in the path, should have priority. It also has the advantage that python has a built-in way to set what directory is used. It also means the file names will remain the same, so nothing will break. Python could also be patched to default to this directory so the install scriptlets would not need to be changed (although the files list scriptlets still would). 4. Create a new directory in %{python3_sitearch). So for example /usr/bin/sip becomes /usr/lib[64]/python3.2/bin/sip. This requires much more radical changes to how python files are handled, and it would be possible to have python2 files do the same. This has the advantage, however, of being more future-proof (i.e. python 4) and would allow multiple versions of the same python abi to be included (i.e. 3.2 and 3.3). Path priority issues could be solved by making sure /usr/lib[64]/python/bin is first in the path. This currently symlinks to /usr/lib[64]/python2, but simply by changing that /usr/lib[64]/python3 the python3 versions of the files would automatically become the defaults. It would also be easy for users to change by putting one ahead in their per-user path. Personally I am leaning towards option 4. I think this is cleaner, more future-proof, and would make it easier to install multiple python versions in parallel (such as 3.2 and 3.3), but would be more work up-front. It is also a major change from the upstream defaults. However, only doing this with python3 packages not python2 ones would mean that it would mean only a handful of packages would need changes at this point, since there are only a few python3 packages. Other python3 packages could be set up this was when they are first created. What are everyone elses' thoughts on this? It is probably a good idea to get this worked out before a major push to start getting python 3 versions of packages. -Todd -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

7 44

[opensuse-packaging] More spec files in one package
by Josef Reidinger 14 Dec '11

14 Dec '11

Hi, I need two spec files to properly build documentation ( don't ask me reason, but upstream need compile binary againts installed library to generate documentation for it), so I create two spec files and second one required already built first ( I don't want to create two packages in BS as tarball is quite big), but it looks only one is processed. How can I process both? source: https://build.opensuse.org/package/show?package=clanlib&project=home%3Ajrei… Thanks Josef -- 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] RFC: Fonts Repo and Renaming Questions
by Thomas Schraitle 14 Dec '11

14 Dec '11

Hi, thanks to Darix, we have a M17N:fonts repository now! :) I've copied the first LinuxLibertine font from the M17N repo into M17N:fonts and renamed it according to the packaging guidelines: LinuxLibertine -> linux-libertine-fonts I've looked in our openSUSE Wiki and found a page about how to rename a package[1]. Basically, it's just adding the Provides and Obsolete keywords to the spec file. However, before I proceed further, maybe someone can answer my questions? 1. Can anybody confirm the mentioned URL[1] is still the correct way to do it? 2. Current version of Linux Libertine is 5.1.3. Which one is the correct line and why: a) Obsoletes: LinuxLibertine < 5.1.3 b) Obsoletes: LinuxLibertine < %{version} 3. Is the URL about replacing a package by another[2] an option in regards to fonts? 4. Anything else that should be observed? Thanks! :) ------ [1] http://en.opensuse.org/openSUSE:Package_dependencies#Renaming_a_package [2] http://en.opensuse.org/openSUSE:Package_dependencies#Replace_a_package_by_a… -- Gruß/Regards, Thomas Schraitle ---------------------------------------------------------------------- SUSE LINUX Products GmbH (o< Maxfeldstrasse 5 /\\ Documentation Specialist 90409 Nuernberg, Germany _\_v http://www.suse.com http://lizards.opensuse.org/author/thomas-schraitle/ SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (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

3 6

[opensuse-packaging] Shutter near by release
by Sascha Manns 13 Dec '11

13 Dec '11

Hello mates, now i have a strange Error. In my tar.bz Source i have inside /share/shutter/resources/icons some content to install. So my way was: 1.) %{__install} -d -m 755 %{buildroot}%{_datadir}/%{name} 2.) %{__cp} -pfr share/%{name}/* %{buildroot}%{_datadir}/%{name} After packaging it looks good. Shutter starts, but he doesn't find a file. Datei �/usr/share/shutter/resources/icons/sel_window_tooltip.svg� konnte nicht ge�ffnet werden: And really if i'm going to that location all content are present. But not the needed sel__windows_tooltip.svg. It is in the Source but i can't find it in the Package. Maybe anyone knows more? Project: X11:Utilities/shutter -- Sincerly yours Sascha Manns Community &Support Agent open-slx GmbH http://www.open-slx.de This mail is written with Balsam Professional 12.1

1 1

[opensuse-packaging] %prep and %setup query
by doiggl＠velocitynet.com.au 13 Dec '11

13 Dec '11

Hello, How can I correct this error[1] The tar file contains [2] Spec file see [3] Thanks Glenn [1] Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.P5nauL + umask 022 + cd /home/abuild/rpmbuild/BUILD + cd /home/abuild/rpmbuild/BUILD + rm -rf cacti-0.8.7i + /usr/bin/gzip -dc /home/abuild/rpmbuild/SOURCES/cacti-0.8.7i-PIA-3.1.tar.gz + /bin/tar -xf - + STATUS=0 + '[' 0 -ne 0 ']' + cd cacti-0.8.7i /var/tmp/rpm-tmp.P5nauL: line 32: cd: cacti-0.8.7i: No such file or directory [2] tar file cacti-0.8.7i-PIA-3.1.tar partial list: # tar -tvf cacti-0.8.7i-PIA-3.1.tar | head drwxr-xr-x roman/users 0 2011-12-12 13:14 cacti-0.8.7i-PIA-3.1/ -rw-r--r-- roman/users 10006 2011-12-12 12:56 cacti-0.8.7i-PIA-3.1/graph_templates_inputs.php drwxr-xr-x roman/users 0 2011-12-12 12:56 cacti-0.8.7i-PIA-3.1/cli/ -rw-r--r-- roman/users 5759 2011-12-12 12:56 cacti-0.8.7i-PIA-3.1/cli/poller_data_sources_reapply_names.php -rw-r--r-- roman/users 11403 2011-12-12 12:56 cacti-0.8.7i-PIA-3.1/cli/add_device.php -rw-r--r-- roman/users 5350 2011-12-12 12:56 cacti-0.8.7i-PIA-3.1/cli/poller_graphs_reapply_names.php -rw-r--r-- roman/users 33 2010-12-05 08:11 cacti-0.8.7i-PIA-3.1/cli/.htaccess -rw-r--r-- roman/users 5100 2011-12-12 12:56 cacti-0.8.7i-PIA-3.1/cli/data_template_associate_rra.php -rw-r--r-- roman/users 18738 2011-12-12 12:56 cacti-0.8.7i-PIA-3.1/cli/add_graphs.php -rw-r--r-- roman/users 4461 2011-12-12 12:56 cacti-0.8.7i-PIA-3.1/cli/rebuild_poller_cache.php . . . [3]Spec file location and %prep content: https://build.opensuse.org/package/view_file?file=cacti-PA.spec&package=cac… . %prep %setup -q -n cacti-%{version} %patch0 -p1 #%patch1 -p1 %patch2 -p1 #%patch3 -p1 . -- 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] Why this .ymp file does not open in Yast?
by Ilya Chernykh 13 Dec '11

13 Dec '11

When trying to open this file in Firefox it suggests gedit instead of Yast: http://download.opensuse.org/repositories/KDE:/KDE3/openSUSE_12.1/KDE3-DEFA… But for other .ymp files it correctly suggests Yast. Where could be the problem? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 4

[opensuse-packaging] S3QL Package - can I help?
by Nikolaus Rath 13 Dec '11

13 Dec '11

Hello, I noticed that the S3QL OpenSUSE package at https://build.opensuse.org/package/show?package=s3ql&project=filesystems lags far behind the upstream version and has also failed to build for quite some time. Is there anything I can do (as the upstream developer) to help getting this fixed? I'm not familiar with either OpenSUSE or RPM packaging (long-time Debian user), but I'd be happy to assist in any way I can. Best, -Nikolaus -- »Time flies like an arrow, fruit flies like a Banana.« PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 10

[opensuse-packaging] What can I do to resolve these items in a RPMLINT report
by doiggl＠velocitynet.com.au 12 Dec '11

12 Dec '11

Hello, What can I do to resolve these items in a RPMLINT report [1] Thanks Glenn [1]https://build.opensuse.org/package/live_build_log?arch=x86_64&package=cac… RPMLINT report: =============== (none): E: badness 10000 exceeds threshold 1000, aborting. cacti.noarch: E: suse-filelist-forbidden (Badness: 10000) /usr/share/cacti/lib/functions.php.orig is not allowed in SUSE Your package installs files or directories in a location that have previously been blacklisted. Please have a look at the particular file and see if the SUSE Packaging Guidelines propose a better place on where to install the file or not install it at all. cacti.noarch: W: non-executable-script /usr/share/cacti/scripts/unix_processes.pl 0644L /usr/bin/perl cacti.noarch: W: non-executable-script /usr/share/cacti/cli/add_data_query.php 0644L /usr/bin/php cacti.noarch: W: non-executable-script /usr/share/cacti/scripts/3com_cable_modem.pl 0644L /usr/bin/perl cacti.noarch: W: non-executable-script /usr/share/cacti/scripts/ping.pl 0644L /usr/bin/perl cacti.noarch: W: non-executable-script /usr/share/cacti/cli/data_template_associate_rra.php 0644L /usr/bin/php cacti.noarch: W: non-executable-script /usr/share/cacti/cli/add_graphs.php 0644L /usr/bin/php cacti.noarch: W: non-executable-script /usr/share/cacti/scripts/diskfree.pl 0644L /usr/bin/perl cacti.noarch: W: non-executable-script /usr/share/cacti/scripts/loadavg.pl 0644L /usr/bin/perl cacti.noarch: W: non-executable-script /usr/share/cacti/scripts/unix_users.pl 0644L /usr/bin/perl cacti.noarch: W: non-executable-script /usr/share/cacti/scripts/diskfree.sh 0644L /bin/sh cacti.noarch: W: non-executable-script /usr/share/cacti/cli/analyze_database.php 0644L /usr/bin/php cacti.noarch: W: non-executable-script /usr/share/cacti/scripts/weatherbug.pl 0644L /usr/bin/perl cacti.noarch: W: non-executable-script /usr/share/cacti/cli/add_graph_template.php 0644L /usr/bin/php cacti.noarch: W: non-executable-script /usr/share/cacti/cli/add_perms.php 0644L /usr/bin/php cacti.noarch: W: non-executable-script /usr/share/cacti/scripts/loadavg_multi.pl 0644L /usr/bin/perl cacti.noarch: W: non-executable-script /usr/share/cacti/cli/add_device.php 0644L /usr/bin/php cacti.noarch: W: non-executable-script /usr/share/cacti/scripts/webhits.pl 0644L /usr/bin/perl cacti.noarch: W: non-executable-script /usr/share/cacti/scripts/linux_memory.pl 0644L /usr/bin/perl cacti.noarch: W: non-executable-script /usr/share/cacti/cli/add_tree.php 0644L /usr/bin/php cacti.noarch: W: non-executable-script /usr/share/cacti/scripts/query_unix_partitions.pl 0644L /usr/bin/perl cacti.noarch: W: non-executable-script /usr/share/cacti/scripts/unix_tcp_connections.pl 0644L /usr/bin/perl This text file contains a shebang or is located in a path dedicated for executables, but lacks the executable bits and cannot thus be executed. If the file is meant to be an executable script, add the executable bits, otherwise remove the shebang or move the file elsewhere. cacti.noarch: W: non-etc-or-var-file-marked-as-conffile /usr/share/cacti/include/config.php A file not in /etc or /var is marked as being a configuration file. Please put your conf files in /etc or /var. cacti.src:93: W: macro-in-comment %{prefix} There is a unescaped macro after a shell style comment in the specfile. Macros are expanded everywhere, so check if it can cause a problem in this case and escape the macro with another leading % if appropriate. cacti.noarch: W: incorrect-fsf-address /usr/share/doc/packages/cacti/LICENSE The Free Software Foundation address in this file seems to be outdated or misspelled. Ask upstream to update the address, or if this is a license file, possibly the entire file with a new copy available from the FSF. cacti.noarch: W: htaccess-file /usr/share/cacti/cli/.htaccess cacti.noarch: W: htaccess-file /usr/share/cacti/rra/.htaccess You have individual apache configuration .htaccess file(s) in your package. Replace them by a central configuration file in /etc/, according to the web application packaging policy for your distribution. cacti.noarch: W: files-duplicate /usr/share/cacti/cli/.htaccess /usr/share/cacti/rra/.htaccess cacti.noarch: W: backup-file-in-package /usr/share/cacti/lib/functions.php.orig You have a file whose name looks like one for backup files, usually created by an editor or resulting from applying unclean (fuzzy, or ones with line offsets) patches. 2 packages and 0 specfiles checked; 1 errors, 28 warnings. -- 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] Hi, what if I packaged a non-free package?
by Marguerite Su 12 Dec '11

12 Dec '11

I recently make a package libspotify in my home repo. Depending on it and my another package projectM, I successfully packaged the real full version of Clementine with every feature ON. I want to submit my Clementine, but if so I have to submit libspotify first. So my question is: 1. What License should I use? I know if I just write "Commercial" it will be surely rejected by SUSE team. 2. Which repo should I submit it to? devel:openSUSE:Nonfree? Here's my package: https://build.opensuse.org/package/show?package=libspotify&project=home%3AM… Here's spotify's Term of Use license: http://developer.spotify.com/en/libspotify/terms-of-use-non-us/ And another quesion is, in my package, it seems static libraries are everywhere, So I can't use *-devel-static mentioned in WIKI, I just use "Provides: libspotify10-static = %{version}" in specfile, Is it acceptable? -- 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] Appliance does not build in susestudio
by Ilya Chernykh 11 Dec '11

11 Dec '11

Hi! I am trying to build an appliance in Suse Studio. First two builds went well but then the build started to take more than 4 hour after which it simply disappears without even an error message. I do not remember what I did and I found no possibility to revert the changes :-( -- 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] Enhancement packaging policy / gobject introspection bindings
by Dimstar / Dominique Leuenberger 10 Dec '11

10 Dec '11

Hi Packagers and maintainers, As many of you are surely already aware, a bunch of libraries bring with them gobject-introspection based bindings to other languages (*.typelib and *.gir files in your packages). So far we packaged the *.typelib together with the shared library, which seemed logical at first, but is 'slightly' wrong. An example: A shared library can change its soname without the need of the binding being changed (ABI change, but API stayed compatible for example). So the binding would update the .typelib file, pointing to the new soname based library. Now, having the .typelib in the shared library package actually causes a conflict on file-level if two library version would need to be installed (for whatever reason). So the suggestion is to do the same as Debian does (slightly changed) and split the .typelib in their own sub-packages. Our proposal is to name those sub-packages in this form: typelib-<typeversion>-<gi-namespace>-<version> (all dots to be replaced with _) typelib: literal: identifier to group them all together and have them easy findable typeversion: the gi-repository is installed in a versioned directory (currently %{_libdir}/gi-repository-1.0) which indicates this can change. Files will conflict as long as they are in the same version only, so we 'split' this on a packaging level. gi-namespace: The namespace of the binding package. This is the name of the typelib file. without the 'version' part version: the version of the binding. An example: clutter installs the file(s) %{_libdir}/gi-repository-1.0/Clutter-1.0.typelib, so this is to be split in a package called: typelib-1_0-Clutter-1_0 (properly capitalized) As clutter installs a bunch of more typelib files, the same rule as with the libs is to be applied: are they kept in sync with their version? If so, they can go in the same package. Otherwise they need to be split in further packages. As the .typelib files themselves also have dependencies (to either other .typelib files and/or to an actual shared library) I wrote a dep-scanner for those yesterday that will add dependencies as needed. This will make sure that all works smoothly together. What does everybody think about this? Is this the way to go forward? 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

4 4

[opensuse-packaging] Permisson denied in %{_docdir}?
by Sascha Manns 09 Dec '11

09 Dec '11

Hello mates, i'm just asking about a little thing in my shutter package. I have in my %install # create a Folder in docdir and move all relevant content to it %{__install} -d -m 644 %{buildroot}%{_docdir}/%{name} %{__cp} -pfr share/doc/%{name}/* %{buildroot}%{_docdir}/%{name} %{__cp} %{S:1} %{buildroot}%{_docdir}/%{name} The buildlog says: + /usr/bin/install -d -m 644 /home/abuild/rpmbuild/BUILDROOT/shutter-0.88.1-19.1.i386/usr/share/doc/packages/shutter + /bin/cp -pfr share/doc/shutter/COPYING share/doc/shutter/README /home/abuild/rpmbuild/BUILDROOT/shutter-0.88.1-19.1.i386/usr/share/doc/packages/shutter /bin/cp: cannot stat `/home/abuild/rpmbuild/BUILDROOT/shutter-0.88.1-19.1.i386/usr/share/doc/packages/shutter/COPYING': Permission denied /bin/cp: cannot stat `/home/abuild/rpmbuild/BUILDROOT/shutter-0.88.1-19.1.i386/usr/share/doc/packages/shutter/README': Permission denied Have i misunderstood anything? cu Sascha -- Sincerly yours Sascha Manns Community &Support Agent open-slx GmbH http://www.open-slx.de This mail is written with Balsam Professional 12.1

3 3

[opensuse-packaging] pom2spec
by Duncan Mac-Vicar P. 08 Dec '11

08 Dec '11

To revive the discussion about pom2spec :-) I was playing with it and it is exactly the kind of pragmatism one is missing when dealing with Java. Nice work Pascal. I remember there where a few topics open when Pascal presented it in the mailing list. - Naming while org.apache.maven.doxia.doxia-sink-api is already long, do you think it makes sense to prefix this with java- or jar- ? (like rubygems- do). I do think the whole groupId artifactId is the better way, but I am not sure if in all cases it would be needed. May be one could specify a shorter way (java-doxia-sink-api) in the command line, when ambiguity is not likely. Requires and Provides would still work using the Provides: java(org.apache.maven.doxia:doxia-sink-api) kind of string. - Provides. Right now it uses something like java(org.apache.maven.doxia:doxia-sink-api). I just want to point out that fedora is already using mvn(org.apache.maven.doxia:doxia-sink-api). Do we want to interoperate across them? Other points: - Binaries. For example: $ mkdir org.scala-tools.sbt.sbt-launch $ cd org.scala-tools.sbt.sbt-launch $ pom2spec call again and specify the exact version, one of: - 0.7.1 - 0.7.2 $ pom2spec 0.7.2 In this case, the built rpm misses the %{_bindir}/sbt which is just a call to java -Xmx512M -jar $longdir/sbt-launch.jar "$@" It would be a nice feature to tell pom2spec something like -bin sbt and it could create the script automatically. - One question... how is the classpath supposed to work? I see some .classpath files put together to the jars, but empty. - Why an artifact like Vaadin creates 2 rpms for the binary and 2 for the sources? Wrote: /space/packages/rpms/noarch/com.vaadin.vaadin-6.7.2-6.7.2-0.noarch.rpm Wrote: /space/packages/rpms/noarch/com.vaadin.vaadin-6.7.2-6_7_2-6.7.2-0.noarch.rpm Wrote: /space/packages/rpms/noarch/com.vaadin.vaadin-6.7.2-sources-6.7.2-0.noarch.rpm Wrote: /space/packages/rpms/noarch/com.vaadin.vaadin-6.7.2-6_7_2-sources-6.7.2-0.noarch.rpm -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- 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] Another perl packaging question
by Greg Freemyer 07 Dec '11

07 Dec '11

All, I've been struggling to figure out a dependency issue with perl::IO::Compress. I have I think I finally understand it, but I want to ask before I branch perl itself and do a SR! In the D:L:P perl specfile it says: Provides: perl-Compress-Zlib perl-Compress-Raw-Zlib Obsoletes: perl-Compress-Zlib perl-Compress-Raw-Zlib Provides: perl-IO-Zlib perl-IO-Compress-Base perl-IO-Compress-Zlib Obsoletes: perl-IO-Zlib perl-IO-Compress-Base perl-IO-Compress-Zlib Note that all the component pieces of perl-IO-Compress are shown as provided, but the overall package itself is not in the list. That agrees with: http://perldoc.perl.org/index-modules-I.html. I have a package that has a requires perl(IO::Compress) and it is failing to install because of that. So my question is if the above list should have perl-IO-Compress added to it. Or should the requires statement in my package be changed to require all the component pieces of IO::Compress instead of just the overall package. To me updating the provides list seems right. 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 9

[opensuse-packaging] Packaging libraries that are intended to be static?
by David Lemke 07 Dec '11

07 Dec '11

I'm building a package that includes this library: http://www.lonesock.net/soil.html This library is "meant to be used as a static library", so, I'm wondering if I should package it separately or not? I read the following, but still feel uncertain about what to do: http://en.opensuse.org/openSUSE:Shared_library_packaging_policy Thanks! ~D -- 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] Java OBS project key signing is expired
by Bruno Friedmann 07 Dec '11

07 Dec '11

Key: E38C29BC4276E0B9 Name: Java OBS Project <Java(a)build.opensuse.org> Finger Print: 9711921972E27C87BBC1BA89E38C29BC4276E0B9 Created: 01/22/08 Expires: 04/01/10 (The key is expired.) Please recreate it ps : for openjdk 1.7 there's no icewebtea -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch openSUSE Member & Ambassador GPG KEY : D5C9B751C4653227 irc: tigerfoot -- 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] Help with a perl module specfile
by Greg Freemyer 06 Dec '11

06 Dec '11

All, I have a package that is not building with the recent factory changes to not allow duplicate files: project=home:gregfreemyer:Tools-for-forensic-boot-cd package=perl-Image-ExifTool The error is: ERROR: /usr/share/man/man1/exiftool.1.gz is packaged in both exiftool and perl-Image-ExifTool, and the packages do not conflict I mean for it to be in the exiftool sub-package, but not in the main package perl-Image-ExifTool. Can someone tell me what I'm doing wrong? The relevant part of the specfile is: ======================== %prep %setup -q -n %{cpan_name}-%{version} %build %{__perl} Makefile.PL INSTALLDIRS=vendor %{__make} %{?_smp_mflags} %check %{__make} test %install %perl_make_install %perl_process_packlist %perl_gen_filelist # remove exiftool and exiftool.1.gz from the file list sed -i '/\/exiftool$/d;/\/exiftool.1$.gz$\?/d;' %{name}.files %clean %{__rm} -rf %{buildroot} %files -n exiftool %defattr(644,root,root,755) %attr(755, root, root) %{_bindir}/exiftool %doc %{_mandir}/man1/exiftool.1.gz %files -f %{name}.files %defattr(644,root,root,755) ExifTool.spec README xmp2exif.args xmp2gps.args xmp2iptc.args %doc Changes ExifTool_config README html %{perl_vendorlib}/File/RandomAccess.pm %{perl_vendorlib}/Image/ExifTool/* %doc %{_mandir}/man3/* ================================== Thanks Greg -- Greg Freemyer Head of EDD Tape Extraction and Processing team Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer CNN/TruTV Aired Forensic Imaging Demo - http://insession.blogs.cnn.com/2010/03/23/how-computer-evidence-gets-retrie… The Norcross Group The Intersection of Evidence & Technology http://www.norcrossgroup.com -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 5

[opensuse-packaging] Problem commiting a java -spec file
by Johannes Weberhofer 06 Dec '11

06 Dec '11

Inserting "Prefer: -java-1_6_0-sun java-1_6_0-openjdk" in a spec file results in the following error while commiting: error: line 23: Unknown tag: Prefer: -java-1_6_0-sun java-1_6_0-openjdk ERROR: source_validator failed: None Any ideas how to solve this issue? Best regards, Johannes -- Johannes Weberhofer Weberhofer GmbH, Austria, Vienna -- 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] source service, correct revision from SVN
by Lutz Thuns 06 Dec '11

06 Dec '11

Hi, I'm packaging fatsort in my OBS project [1]. Therefore I'm using a source service which generates a .tar from SVN. <param name="versionprefix">0.9.15</param> sets me the correct main version, but regarding the revision, I receive a file called fatsort-0.9.15.rev247.tar.gz (notice the "rev"). If I don't use the versionprefix, the file is called fatsort-247.tar.gz Is there any possibility to ger rid of "rev", so that I receive a fatsort-0.9.15.247.tar.gz ? I've asked that on the English forums [2] a few weeks ago, maybe anybody here knows an answer. Thanks. [1] https://build.opensuse.org/package/show?package=fatsort&project=home%3AlOtz… [2] http://forums.opensuse.org/english/other-forums/development/open-build-serv… -- Lutz Thuns openSUSE member (lOtz1009) LXDE team -- 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] python-mongo and python-pymongo in devel:languages:python
by Adam Mizerski 05 Dec '11

05 Dec '11

Hi, There are two identical packages in devel:languages:python: python-mongo and python-pymongo. They have the same sources and a bit different spec files. According to http://en.opensuse.org/openSUSE:Packaging_Python#Naming_policy the right one is python-pymongo. Please clean it up. Thanks. -- Adam Mizerski

1 0

[opensuse-packaging] %if 0%{?suse_version} >= 1210 not working?
by Lutz Thuns 05 Dec '11

05 Dec '11

Hi, I want to patch lxdm, to make it use the new location of the default OS wallpaper. Therefore I've added to the spec: > %if 0%{?suse_version} < 1210 > %patch0 -p1 > %endif [...other patches...] > %if 0%{?suse_version} >= 1210 > %patch6 -p1 > %endif This is working for Factory build target. For 12.1 build target it's not working. Patch0 is applied, but patch6 not. Also the original > %if 0%{?suse_version} >= 1210 > Recommends: gnome-control-center-user-faces > %endif is working for Factory only but not for 12.1 What am I doing wrong here? -- Lutz Thuns openSUSE member (lOtz1009) LXDE team -- 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] (In)Consistent Font Package Names
by Thomas Schraitle 04 Dec '11

04 Dec '11

Hi, over the years, I've collected a bunch of great fonts in my home repository. However, it seems we don't have a consistent naming schema for fonts. Although the Packaging Guidelines[1] links to the old Wiki[2], the information therein is printed in red and I'm not sure how useful is this nowadays. This has some interesting effects. If you search for fonts like this: # zypper se font you will get _some_ but not all. For example, the popular Linux Libertine and DejaVu fonts are not listed. A user has to _know_ the name. IMHO this is not very intuitive and userfriendly. On the other side, we have lots of fonts which are very inconsistently named. Here are some examples: farsifonts fonts-arabic freefont gnu-unifont indic-fonts intlfonts-ttf xorg-x11-fonts From a usability perspective, it would be very convenient to have a consistent naming schema with a specific prefix (or suffix), for example a "-fonts" suffix. Ubuntu has the prefix "ttf-" for their packages: http://packages.ubuntu.com/search?suite=natty&section=all&arch=any&searchon… Fedora has the suffix "-fonts" for their packages: https://admin.fedoraproject.org/pkgdb/acls/list/*-fonts*?_csrf_token=b27215… Another issue: Do we have a special repository dedicated only to fonts? I couldn't find any... Do you think this is useful? What do you think? -------- [1] http://en.opensuse.org/openSUSE:Packaging_guidelines [2] http://old-en.opensuse.org/Packaging/Fonts_Policy#Package_layout_for_fonts -- Gruß/Regards, Thomas Schraitle ---------------------------------------------------------------------- SUSE LINUX Products GmbH (o< Maxfeldstrasse 5 /\\ Documentation Specialist 90409 Nuernberg, Germany _\_v http://www.suse.com http://lizards.opensuse.org/author/thomas-schraitle/ SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (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

11 19

[opensuse-packaging] Re-Enable publish flag for openSUSE_Factory LibreOffice:Unstable
by Bruno Friedmann 03 Dec '11

03 Dec '11

We are actually in the situation where LibreOffice for 12.1 is > to LibreOffice:Unstable for openSUSE_Factory Publish flag is disable https://build.opensuse.org/project/repositories?project=LibreOffice%3AUnsta… So could it be re-enable or binaries wiped out. -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch openSUSE Member & Ambassador GPG KEY : D5C9B751C4653227 irc: tigerfoot -- 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] About packaging twice
by Stephan Kulow 02 Dec '11

02 Dec '11

Hi, We have for a long time a warning in the post-build-checks, that is obviously greatly ignored, so I plan to make it fatal. I'm talking about e.g. WARNING: berkeleydb: /usr/share/doc/packages/berkeleydb/LICENSE already packaged in package berkeleydb-manual WARNING: berkeleydb: /usr/share/doc/packages/berkeleydb/README already packaged in package berkeleydb-manual In the end it doesn't matter to rpm if a file is installed by one or two rpms as long as there is no conflict. But a) such conflicts easily arise during package update and b) if you review the WARNINGs there are just too many cases where this is a bug (people "splitting out" -lang packages and still package the translation in the main package). There are 3930 of such duplicated files in 72 packages and I rather have these 72 packages fixed. The only problem there is (and very likely the reason this WARNING is not an ERROR): packages conflicting on rpm level are fine to package files twice - think of branding-upstream vs branding-openSUSE. So we need to work on this before we can make this fatal. And this will also be the way to signal that you planned to package the file twice: use a rpm conflict. Greetings, Stephan -- 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] Release override
by Jean Delvare 02 Dec '11

02 Dec '11

Does anybody know if it's possible to override the Release: field of a spec file on rpmbuild's command line? I naively tried rpmbuild --define "Release 1" blah.spec but it did not work. -- Jean Delvare Suse L3 -- 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] Problem with download service
by Josef Reidinger 01 Dec '11

01 Dec '11

Hi, I pack package and try use new _service ability. It is here: https://build.opensuse.org/package/files?package=bullet&project=games Problems: 1) build failed with missing file. What I do wrong? ( I see no error output and on local build it work ) 2) show params looks broken, as it show nothing 3) when I try drag and drop I expect that icon after drop down will be aligned ( try just drag icon and move to right few pixels ) 4) When I try run service now. it shows two message ( I click once ) Files could not be expanded: service in progress Service execution got triggered Z) related issue, I want to use in verification service upstream checksum, but it is in SHA1. So I create sr that enhance service, but I see no response - https://build.opensuse.org/request/show/92988 Thanks Josef -- Josef Reidinger Software Engineer Appliance Department SUSE LINUX, s. r. o. Lihovarska 1060/12 190 00 Praha 9 Czech Republic jreidinger(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

2 2