December 2011 - openSUSE Packaging - openSUSE Mailing Lists

[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