April 2011 - openSUSE Packaging - openSUSE Mailing Lists

[opensuse-packaging] Right usage of libexecdir?
by Vincent Untz 25 May '11

25 May '11

Hey, Dominique and I are currently wondering what to do wrt libexecdir for evolution-data-server. Should we leave it unchanged (so files will be in /usr/lib) or should we change it to /usr/lib/evolution-data-server? If the latter, is there any reason this is not done automatically? Also, hrm, would rpmlint have ways to warn about packages that put binaries in libdir instead of libexecdir? (I can find a few of them here with a grep) Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

6 9

[opensuse-packaging] RPMLINT warning: W: non-etc-or-var-file-marked-as-conffile /srv/www/htdocs/*
by Ralf Lang 02 May '11

02 May '11

Hi folks, while packaging horde4 I noticed the rpmlint warning horde4.noarch: W: non-etc-or-var-file-marked-as-conffile /srv/www/htdocs/horde4/config/conf.php.dist If config files are allowed to live in /var (where web apps used to live in old times) why are they not allowed in /srv ? -- Ralf Lang Linux Consultant / Developer B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

5 12

[opensuse-packaging] FTLibrary.h not in ftgl-devel
by Javier Llorente 01 May '11

01 May '11

Hi list-mates, I'm trying to compile OpenCASCADE 6.5.0 and I'm getting ../../../src/OpenGl/OpenGl_FontMgr.cxx:4:23: fatal error: FTLibrary.h: No such file or directory compilation terminated. OpenCASCADE.spec has "BuildRequires: ftgl-devel." I have seen that that package doesn't provide FTLibrary.h. Is it a packaging bug? Thanks, -- Javier Llorente

2 3

[opensuse-packaging] Need help with a rejected license mmlibs glew
by Dave Plater 30 Apr '11

30 Apr '11

Not wanting to have to submit again and again, glew was rejected by licensedigger. It had " ; Other uncritical OpenSource License" in every license field and I've removed that but it still has "BSD3c(or similar) ; GPLv2" the output from licencecheck is : glew-1.5.8/src/glewinfo.c: BSD (2 clause) glew-1.5.8/src/visualinfo.c: UNKNOWN glew-1.5.8/src/glew.c: BSD (2 clause) glew-1.5.8/include/GL/glew.h: BSD (2 clause) MIT/X11 (BSD like) glew-1.5.8/include/GL/glxew.h: BSD (2 clause) MIT/X11 (BSD like) glew-1.5.8/include/GL/wglew.h: BSD (2 clause) glew-1.5.8/auto/src/glewinfo_wgl.c: *No copyright* UNKNOWN glew-1.5.8/auto/src/glxew_head.h: *No copyright* UNKNOWN glew-1.5.8/auto/src/glew_tail.h: *No copyright* UNKNOWN glew-1.5.8/auto/src/glew_init_tail.c: *No copyright* UNKNOWN glew-1.5.8/auto/src/khronos_license.h: UNKNOWN glew-1.5.8/auto/src/glew_head.h: *No copyright* UNKNOWN glew-1.5.8/auto/src/glew_init_gl.c: *No copyright* UNKNOWN glew-1.5.8/auto/src/glewinfo_tail.c: *No copyright* UNKNOWN glew-1.5.8/auto/src/glew_str_wgl.c: *No copyright* UNKNOWN glew-1.5.8/auto/src/glxew_tail.h: *No copyright* UNKNOWN glew-1.5.8/auto/src/glew_str_head.c: *No copyright* UNKNOWN glew-1.5.8/auto/src/glew_utils.c: BSD (2 clause) glew-1.5.8/auto/src/glew_utils.h: BSD (2 clause) glew-1.5.8/auto/src/wglew_tail.h: *No copyright* UNKNOWN glew-1.5.8/auto/src/glew_init_wgl.c: *No copyright* UNKNOWN glew-1.5.8/auto/src/mesa_license.h: MIT/X11 (BSD like) glew-1.5.8/auto/src/glewinfo_head.c: *No copyright* UNKNOWN glew-1.5.8/auto/src/glew_license.h: BSD (2 clause) glew-1.5.8/auto/src/glewinfo_glx.c: *No copyright* UNKNOWN glew-1.5.8/auto/src/wglew_head.h: *No copyright* UNKNOWN glew-1.5.8/auto/src/glew_str_tail.c: *No copyright* UNKNOWN glew-1.5.8/auto/src/glewinfo_gl.c: *No copyright* UNKNOWN glew-1.5.8/auto/src/glew_str_glx.c: *No copyright* UNKNOWN glew-1.5.8/auto/src/glew_head.c: *No copyright* UNKNOWN glew-1.5.8/auto/src/glew_init_glx.c: *No copyright* UNKNOWN glew-1.5.8/auto/lib/OpenGL/Spec.pm: *No copyright* UNKNOWN glew-1.5.8/auto/bin/make_header.pl: UNKNOWN glew-1.5.8/auto/bin/make_init.pl: UNKNOWN glew-1.5.8/auto/bin/make_info_list.pl: UNKNOWN glew-1.5.8/auto/bin/make.pl: UNKNOWN glew-1.5.8/auto/bin/fix_OML_sync_control.sh: UNKNOWN glew-1.5.8/auto/bin/make_list.pl: UNKNOWN glew-1.5.8/auto/bin/make_struct_fun.pl: UNKNOWN glew-1.5.8/auto/bin/update_ext.sh: UNKNOWN glew-1.5.8/auto/bin/update_registry.sh: UNKNOWN glew-1.5.8/auto/bin/parse_spec.pl: UNKNOWN glew-1.5.8/auto/bin/make_str.pl: UNKNOWN glew-1.5.8/auto/bin/make_def_var.pl: UNKNOWN glew-1.5.8/auto/bin/make_info.pl: UNKNOWN glew-1.5.8/auto/bin/make_struct_var.pl: UNKNOWN glew-1.5.8/auto/bin/make_def_fun.pl: UNKNOWN glew-1.5.8/auto/bin/make_html.pl: UNKNOWN Thanks Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

2 4

[opensuse-packaging] Need cmake help for openCOLLADA
by Dave Plater 30 Apr '11

30 Apr '11

I've a problem with my cmake openCOLLADA build when using multiple jobs, one lib wants to link to another that hasn't finished building/linking yet. Being a hacker at heart I'm trying to add this to the CMakeLists.txt of the lib that can't find the other : find_package(lib/libOpenCOLLADABaseUtils) WHILE(libOpenCOLLADABaseUtils_FOUND) I'm still going over commands and syntax, I don't know how to invert "libOpenCOLLADABaseUtils_FOUND" yet or if this method will even work. openCOLLADA takes a long time to build and if I build it on my system one of the libs hogs my system to the point of it freezing for at least 20 minutes, so I can only do this and go away for a while and come back to find that it's failed. Doesn't fair well with hacking. Please help. Thanks Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

2 4

[opensuse-packaging] What is an "undefined-non-weak-symbol" and how is it fixed?
by Dave Plater 30 Apr '11

30 Apr '11

A Fedora packager is basing his openCOLLADA on mine and during his review rpmlint picked up "undefined-non-weak-symbol"s in one of the libraries. This seems like something that I should fix and possibly something that our rpmlint needs to check for. This is what shows it up, rpmlint doesn't : ldd -r /usr/lib64/libbuffer.so undefined symbol: _ZN6Common4ftoaEfPc (/usr/lib64/libbuffer.so) undefined symbol: _ZN6Common4dtoaEdPcb (/usr/lib64/libbuffer.so) linux-vdso.so.1 => (0x00007fffe5d37000) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f7017757000) libm.so.6 => /lib64/libm.so.6 (0x00007f7017500000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f70172e9000) libc.so.6 => /lib64/libc.so.6 (0x00007f7016f7c000) /lib64/ld-linux-x86-64.so.2 (0x00007f7017ca3000) I assume this has to do with the two undefined symbols in libbuffer.so : # c++filt _ZN6Common4ftoaEfPc _ZN6Common4dtoaEdPcb Common::ftoa(float, char*) Common::dtoa(double, char*, bool) The closest match I can find in the sources are from libftoa's (also part of openCOLLADA) Commondtoa.h and Commonftoa.h : /* Copyright (c) 2009 NetAllied Systems GmbH This file is part of Common libftoa. Licensed under the MIT Open Source License, for details please see LICENSE file or the website http://www.opensource.org/licenses/mit-license.php */ #ifndef __COMMON_DTOA_H__ #define __COMMON_DTOA_H__ #include <stdlib.h> namespace Common { /** The minimum size of the buffer, passed to dtoa.*/ static const size_t DTOA_BUFFERSIZE = 30; /** Returns the number of bytes written in to the buffer. @param buffer The buffer the string representation of the number will be written to. Its size must be at least DTOA_BUFFERSIZE. @param doublePrecision If set to true, up to 16 significant digits are written, otherwise 6*/ int dtoa(double f, char* buffer, bool doublePrecision = false); } #endif // __COMMON_DTOA_H__ I won't paste it's brother Commonftoa.h but the package is at : https://build.opensuse.org/package/show?package=openCOLLADA&project=home%3A… If you want to see the Fedora review : https://bugzilla.redhat.com/show_bug.cgi?id=694287 Thanks Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

13 34

[opensuse-packaging] updated boinc-client
by Sascha Manns 29 Apr '11

29 Apr '11

Hello Mates, i've just updated boinc-client to 6.10.58. I have now the following RPMLINT Issues: * shared-lib-calls-exit /usr/lib/libboinc_graphics2.so.6.10.58 exit(a)GLIBC_2.0 * shared-lib-calls-exit /usr/lib/libboinc_api.so.6.10.58 exit(a)GLIBC_2.0 * binary-or-shlib-calls-gethostbyname /usr/bin/boinc-client * binary-or-shlib-calls-gethostbyname /usr/lib/libboinc.so.6.10.58 That issues are confusing me: * preun-without-%stop_on_removal-preun /etc/init.d/boinc-client * postun-without-%restart_on_update /etc/init.d/boinc-client * postun-without-%insserv_cleanup /etc/init.d/boinc-client These issues should'nt visible, because i'm already using these macros. Maybe anyone can help solving this issues? cu Sascha -- Sincerely Yours Sascha Manns open-slx Community & Support Agent openSUSE Membership Comitee openSUSE Marketing Team Web: http://saigkill.homelinux.net German Community Portal: http://community.open-slx.de -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

3 8

[opensuse-packaging] What is supposed to be in the License: field
by Dave Plater 29 Apr '11

29 Apr '11

Now that an automatic license check is done on packages submitted to factory there is one more twist to accepting and forwarding to openSUSE:Factory. One particular package from multimedia:libs libkate had "|BSD3c ; Other uncritical OpenSource License" in the license field and was rejected for having "||Other uncritical OpenSource License" so I removed it ran "licensecheck --verbose -r libkate-0.3.8" and only saw this (apart from a GNU header in ltmain.sh) : Use, distribution and reproduction of this library is governed by a BSD style source license included with this source in the file 'COPYING'. Please read these terms before distributing. */ so I left ||BSD3c. This has been declined as well and it feels like my community unpaid workload has increased ten fold. I'm not sure that I will accept anymore third party submissions to multimedia:libs or apps as there is no clear indication why libkate was declined the second time and I see that at least another package has a license problem which I can't fix without clear guidelines on what is supposed to be in the license field. Looking at another package submitted, it has "License: GNU General Public License version 2 or later (GPL v2 or later)" in the spec file. If I had worked on this package I would have altered it to "||License: GPLv2+" but now I'm not even sure about that. Do I give up or is the information that "License digger" uses publicly available? Dave P | -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

2 4

[opensuse-packaging] netcdf package
by Filipe Pires Alvarenga Fernandes 29 Apr '11

29 Apr '11

Hi, The official netcdf package at OBS (I guess it is maintained at devel:libraries:c_c++ ) is lacking some crucial compiling flags for environmental scientists. # need curl :: These allows data access over the internet, essential for climate scientists --enable-dap --disable-dap-remote-tests # need hdf5 :: This makes netcdf-4 actually netcdf-4, the current configuration is still netcdf-3 --enable-netcdf-4 --enable-ncgen4 # not essential --enable-extra-example-tests I maintain netcdf 4.1.2 here: https://build.opensuse.org/package/show?package=netcdf&project=home%3Aocefp… However, I do not believe my version is OK for official release, since I'm and amateur packager. Also, I compile the static library (most numerical ocean models need that), and that is removed from the official package. I would like to see those flags above in the official packages and an upgrade to version 4.1.2 if possible. This would certainly expand the use of that important library. I tried to branch, do that on my own, and submit the diff back, but devel:libraries:c_c++ does not have hdf4 nor curl. Thanks, Filipe. ***************************************************** Filipe Pires Alvarenga Fernandes, PhD Candidate School of Marine Science and Technology University of Massachusetts at Dartmouth 706 Rodney French Blvd., New Bedford, MA 02744 Email: falvarengafernandes(a)umassd.edu ocefpaf(a)gmail.com http://ocefpaf.tiddlyspot.com/ ***************************************************** -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

4 7

[opensuse-packaging] "Good spec" guidelines for new packages in Build Service
by Jan Matejek 29 Apr '11

29 Apr '11

Dne 26.4.2011 15:20, Sascha Peilicke napsal(a): > On Tuesday 26 April 2011 14:52:10 you wrote: >> Dne 26.4.2011 14:44, Sascha Peilicke napsal(a): >>> On Tuesday 26 April 2011 14:27:35 you wrote: >>>> State of submit-request #68231 was changed by matejcik: >>>> new -> declined >>>> >>>> Comment: >>>> please use %files -f INSTALLED_FILES when you can use --record-rpm, >>>> >>>> instead of listing files by hand. >>> >>> This is not a valid decline reason as this allow to build Python packages >>> that work acros distros, because --record-rpm isn't available >>> everywhere. However, >> >> This is a valid reason because it's not a well-written spec. > Do we have some public docs on what we currently consider a well-written spec > with regards to Python packages? i don't think we have a doc on what we consider a well-written spec in general, but we do have packaging guidelines and this spec is not following its spirit too well. I'd say it's more a case of using common sense - when you use --record-rpm, don't discard the result. General packaging guidelines have nothing to say on explicitness of file lists (which is probably a mistake that should be fixed), but i think we can agree that being overly explicit is not good for maintainability. >> (perhaps guidelines for "good" specs vary between our teams? in that >> case, we should have some kind of discussion about what is and isn't >> appropriate for public repositories - or is there some kind of definite >> guideline published on wiki or anywhere?) > Ok, seems like we don't. > >> Also, if we care about cross-distro compatibility, a valid reason for >> decline would be using "--record-rpm" at all because it would break the >> build on other distros. > Yep, and I'd say this is reasonable as this is a major reason for using the > Build Service. Personally, I make sure that (most) of my Python packages work > on every distro (well, except the DEB-based ones currently) we offer. just thought of something: when building Python packages in buildservice, they're built with our python that does have --record-rpm capability. And because it only matters at build-time, it should be valid to use it for cross-distro packages. Or does this work differently? > Currently this isn't all too visible as we only enable a limited set for > devel:languages:python and I don't have the balls to enable more distros > because a lot of packages need love there :-) > >>> instead of explicitly listing each and every file, the following would >>> suffice: >>> >>> %files >>> %defattr(-,root,root,-) >>> %{python_sitearch}/* >> >> true. i would argue that this is still bad practice - in this particular >> case, file listing should be this: >> >> %defattr(-,root,root,-) >> %{python_sitearch}/enthought >> %{python_sitearch}/Traits-%{version}-py*.egg-info >> %{python_sitearch}/Traits-%{version}-py*-nspkg.pth > > You are right, but egg-info stuff isn't always generated and most of the time > there's no relation between the package name and what ends up in > %{python_sitearch}. This is an issue for auto-generating packages (e.g. with > py2pack), therefore I tend to favor the first approach (even if it is messy). Maybe there should be a guideline to use your py2pack unless there is reason to do it manually. How do your autogenerated packages handle updating? > > BTW. For py2pack, I currently use the following spec template: > https://github.com/saschpe/py2pack/blob/master/py2pack/templates/opensuse.s… > > If you agree, we may continue this discussion on opensuse-packaging. yes, let's. regards m. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

2 3

[opensuse-packaging] help with package setup
by Robert Schweikert 28 Apr '11

28 Apr '11

Hi, Working on making the openNebula package more usable and am looking at their setup guide to figure out what can be done by the package automatically at install time. One step that is described in the setup guide is the generation of an ssh key. I am wondering whether this is a step I can/should do during package install or not? If this should be created during install would sudo oneadmin ssh-keygen -q be the proper way to go about this? Where "oneadmin" is the user account created for the OpenNebula administrator. Should this user be treated as a system account, i.e. use '-r' on the useradd command? Are there specific rules I need to follow? Thanks, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead rschweikert(a)novell.com rschweikert(a)ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

2 1

[opensuse-packaging] /usr/php5/PEAR/data permissions 0640 - pear package files with data role unreadable by web server
by Ralf Lang 27 Apr '11

27 Apr '11

Hi, following the discussions in [opensuse-packaging] RPMLINT warning: W: non-etc- or-var-file-marked-as-conffile /srv/www/htdocs/ I figured different ways of deploying web apps in a more FHS-like way. I discovered a problem and I am not sure how to resolve it. php5 PEAR is shipped in 11.4 and factory with /usr/php5/PEAR/data as the base dir for files with the data role. It is shipped as root/root, 0640. Thus data can not be read by software which runs as, say, wwwrun:www. How can I work around this? -- Ralf Lang Linux Consultant / Developer B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

1 0

[opensuse-packaging] cmake arguments and quotes conversion
by Adam Mizerski 22 Apr '11

22 Apr '11

Hi, I have problem with passing arguments to cmake. In spec in %build section I have: cmake -G "Unix Makefiles" -DCMAKE_BUILD_TYPE=Release \ -DCMAKE_C_FLAGS_RELEASE="%{optflags} -DNDEBUG" \ -DCMAKE_CXX_FLAGS_RELEASE="%{optflags} -DNDEBUG" As I tried locally on my machine (just normal, not osc build) it works as expected. But when running in osc build it is converted to: cmake -G 'Unix Makefiles' -DCMAKE_BUILD_TYPE=Release \ '-DCMAKE_C_FLAGS_RELEASE=-fbla -fbla -fbla -f... -DNDEBUG' \ '-DCMAKE_CXX_FLAGS_RELEASE=-fbla -fbla -fbla -f... -DNDEBUG' (that's how it looks like in compilation log) and it's not working. The build type is changed to Release, but flags are unchanged. Is it bug in cmake or osc build? What to do with that? Thanks for any help. -- Adam "etamPL" Mizerski

3 3

[opensuse-packaging] Re: qt3 in KDE:KDE3 patching fails
by Robert Xu 21 Apr '11

21 Apr '11

On Thu, Apr 21, 2011 at 16:42, Will Stephenson <wstephenson(a)suse.de> wrote: > On Thursday 21 Apr 2011 21:21:25 Robert Xu wrote: >> On Thu, Apr 21, 2011 at 05:28, Will Stephenson <wstephenson(a)suse.de> wrote: >> > On Wednesday 20 April 2011 17:23:11 Robert Xu wrote: >> >> > Is this the binary-incompatible patch to Qt 3 I read about on the >> >> > trinity list? >> >> >> >> Yes, the patch to Qt3. Not sure about the binary incompatibility though. >> > >> > I checked, it's binary compatible. I'm interested to know why those >> > extra methods on QObject are needed though - can you point me to any >> > uses of them? >> > >> > Will >> >> It adds in two functions that allow the use of object list objects >> instead of pointers to them. > > Yeah, I read that in the patch. > >> Also, it prevents bad pointer accesses. > > Hmm. Not sure about that. (IIRC) > >> The Trinity Qt wrapper - TQtinterface, makes use of these objects. > > Where do I find the TQtinterface code that uses these? > > Will > In KDE SVN: branches/trinity/dependencies/tqtinterface for the Qt3 version and Qt4 version... well, there is websvn at http://svn.trinitydesktop.org/websvn/listing.php?repname=Trinity&path=%2Fex… but no anonsvn atm. You can ask Timothy Pearson (kb9vqf) on freenode - #trinity-desktop he's usually there. -- Robert Xu + Linux is awesome; don't doubt what it can do + rxu(a)lincomlinux.org -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

1 0

[opensuse-packaging] Re: qt3 in KDE:KDE3 patching fails
by Robert Xu 21 Apr '11

21 Apr '11

I keep sending from the wrong email address... >_> On Apr 20, 2011, at 10:34, Will Stephenson <wstephenson(a)suse.de> wrote: > On Wednesday 20 Apr 2011 16:15:15 Robert Xu wrote: >> On Wed, Apr 20, 2011 at 04:43, Philipp Thomas <pth(a)suse.de> wrote: >>> * Robert Xu (rxu(a)lincomlinux.org) [20110418 21:57]: >>>> The problem is this patch works perfectly fine, until we get openSUSE >>>> 11.3+, where it thinks this patch is not a regular file. >>> >>> Look at the patch itself and you'll see that it tries to patch qglobal.h >>> twice, once via its symlink and then at the end of the patch the >>> qglobal.h file the symlink in include/ points to. If you remove the >>> first patch it should all be OK. >>> >>> Philipp >> >> That works, thanks! Now to sr this... > > Is this the binary-incompatible patch to Qt 3 I read about on the trinity > list? > Yes, the patch to Qt3. Not sure about the binary incompatibility though. -- Robert Xu + Linux is awesome; don't doubt what it can do + rxu(a)lincomlinux.org -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

2 3

[opensuse-packaging] Question about a self test
by Greg Freemyer 21 Apr '11

21 Apr '11

All, I'm packaging a python program that has an included self test. If I manually build, install, test on my workstation, the test runs to completion. If I try it online at OBS, I get a failure. What do I need to have in the specfile for it to run? The specfile code is: === %build export CFLAGS="%{optflags}" python setup.py build cd test python test_pyrit.py === I also tried to call the self test at the end of the install stanza. Same results. The log shows: === + cd test + python test_pyrit.py Traceback (most recent call last): File "test_pyrit.py", line 41, in <module> import cpyrit.config ImportError: No module named cpyrit.config error: Bad exit status from /var/tmp/rpm-tmp.3DeLZI (%build) === Thanks Greg -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

3 3

[opensuse-packaging] Re: qt3 in KDE:KDE3 patching fails
by Robert Xu 20 Apr '11

20 Apr '11

Same with this one ._. On Apr 20, 2011, at 10:38, Philipp Thomas <pth(a)suse.de> wrote: > >* Robert Xu (rxu(a)lincomlinux.org) [20110420 16:16]: > >Now to sr this... > >Wait for my sr as I've also refreshed all patches that needed it so that >they apply without offset. > Ok. -- Robert Xu + Linux is awesome; don't doubt what it can do + rxu(a)lincomlinux.org -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

1 0

[opensuse-packaging] qt3 in KDE:KDE3 patching fails
by Robert Xu 20 Apr '11

20 Apr '11

Hi all, Having some strange problems with a patch... Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.SdnSSg + umask 022 + cd /usr/src/packages/BUILD + cd /usr/src/packages/BUILD + rm -rf qt-x11-free-3.3.8b + /usr/bin/gzip -dc /usr/src/packages/SOURCES/qt-x11-free-3.3.8b.tar.gz + /bin/tar -xf - + STATUS=0 + '[' 0 -ne 0 ']' + cd qt-x11-free-3.3.8b + /bin/chmod -Rf a+rX,u+w,g-w,o-w . + echo 'Patch #200 (qt-3.3.8c.diff):' Patch #200 (qt-3.3.8c.diff): + /usr/bin/patch -s -p0 --fuzz=0 + /bin/cat /usr/src/packages/SOURCES/qt-3.3.8c.diff File include/qglobal.h is not a regular file -- can't patch 1 out of 1 hunk ignored -- saving rejects to file include/qglobal.h.rej File include/qobject.h is not a regular file -- can't patch 1 out of 1 hunk ignored -- saving rejects to file include/qobject.h.rej error: Bad exit status from /var/tmp/rpm-tmp.SdnSSg (%prep) The problem is this patch works perfectly fine, until we get openSUSE 11.3+, where it thinks this patch is not a regular file. I was able to patch it manually as well. Any pointers? You can see my problems at home:bravoall1552:branches:KDE:KDE3/qt3... -- later, Robert Xu -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

3 4

[opensuse-packaging] Trying to create a zypper "virtualenv"
by R. Tyler Croy 20 Apr '11

20 Apr '11

Python users might be more familiar with what I'm talking about here. Basically I'm trying to see if it's possible to use zypper in a non-root, i.e. local directory. I've been working on this script: https://gist.github.com/922881 Which actually seems to kind of almost get things set up for me correctly, but there are some packages which don't seem to play nice with the `--root` option (terminfo is the first that breaks when I install the 'ruby' package) Am I missing something or is this simply not possible? For development and testing I really would like to create these lightweight environments layered on top of my home directory, instead of using a plethora of chroot environments. Any ideas? :/ Cheers - R. Tyler Croy -------------------------------------- Code: http://github.com/rtyler Chatter: http://identi.ca/agentdero http://twitter.com/agentdero

2 1

[opensuse-packaging] d:l:php/php5 patch always declined because of "bad link"
by Ralf Lang 18 Apr '11

18 Apr '11

Hi, I twice added a patch to the d:l:php/php5 package which adds a default config, preventing a lot of warning clutter in recent php5 installs. Both times, after the normal delay, the sr'ed patch was declined once by coolo and once by elvigia because of "bad link". Can you tell me how I can make it last longer (read: until accepted) or patch it in yourself? -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: lang(a)b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

3 5

[opensuse-packaging] Re: commit jpeg8 for openSUSE:Factory
by Dimstar / Dominique Leuenberger 15 Apr '11

15 Apr '11

Hello community, Just saw this commit on the ml and thought I wanted to raise an issue/question with this one (there are others doing the same) It's also not this commit introducing it, just that I happen to see it here... again... and I have time now :) > -%package -n libjpeg8-devel > +%package -n libjpeg%{major}-devel Wasn't there once the agreement that the -devel package does not follow the sonum bumps? so sonum in the packagename for libs is only interesting because it allows us to install the libs in parallel, something which the -devel package here intentionally 'denies' us from doing using Conflicts: anyhow. Why not just go and call it libjpeg-devel, which would also be more straight forward for packagers, relying on it. I think it's useless to update all spec files just becuase jpeg (or any other lib for that matter) bumps it soname and becomes ABI incompatible.. as long as they are API compat, a rebuild is all it takes. Habing '8' in this case in the packagename for the devel will force us to go and replace all BuildRequires: libjpeg8-devel with libjpeg9-devel. This is actually also noted down like this in our packaging guidelines, see: http://en.opensuse.org/openSUSE:Shared_library_packaging_policy#Package_Name Best regards, Dominique -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

8 14

[opensuse-packaging] On Python packages naming
by Sascha Peilicke 15 Apr '11

15 Apr '11

Hi guys, currently most Python packages in the Build Service are inconsistently named. For instance, upstream 'pyenchant' is named python-enchant, 'Cheetah' is named python-cheetah. There are plenty of other examples. I'd like to propose a different scheme (much like our Ruby and Perl packages): * Python application packages are named like $UPSTREAM_NAME * Python libraries are named python-$UPSTREAM_NAME Upstream names means what is found on PyPi (pypi.python.org) PyPi names make the most sense as upstream projects names clash sometimes, PyPI names are unique. Here are some examples: * 'bpython' stay 'bpython' as it is an app * 'IPython' would become 'ipython', as this is the PyPi package name (not the app name) * 'python-enchant' becomes 'python-pyenchant' * 'python-cheetah' becomes 'python-Cheetah' * 'python-twitter' becomes 'python-python-twitter' While the last example doesn't look too fancy, this generally has huge advantages. First of all users now have a clue what to search for. More importantly, there's a clear dependency between package name and upstream name, which helps a lot for automatic spec file generation (BuildRequires/Requires). For some newer packages, this seem to have happened already. I'd suggest that when a new upstream version for a 'broken' package is available, an entirely new package (with correct name) is added and the old one obsoleted. Python applications should also Provide: python-$UPSTREAM_NAME to be compatible with the above scheme. As an example, I added the package 'python-pyenchant' to devel:languages:python, that obsoletes/provides the older 'python-enchant'. -------------------------------------------------------------------------------- Regarding BuildRequires/Requires, we may even want to adopt the Perl package scheme. For the package 'python-py2pack' this would look like: BuildRequires: python-devel BuildRequires: python(Jinja2) >= 2.5 BuildRequires: python(argparse) Requires: python(Jinja2) >= 2.5 Requires: python(argparse) This needs some tool support, off course. -- Mit freundlichen Grüßen, Sascha Peilicke http://saschpe.wordpress.com

5 8

Fwd: [opensuse-packaging] Re: On Python packages naming
by Nelson Marques 15 Apr '11

15 Apr '11

---------- Forwarded message ---------- From: Nelson Marques <nmo.marques(a)gmail.com> Date: Fri, Apr 15, 2011 at 7:49 PM Subject: Re: [opensuse-packaging] Re: On Python packages naming To: Jan Matejek <jan.matejek(a)novell.com> Hi, As far as I understood and it was pointed to me, python extensions, modules, bindings and friends are to be packaged as python-$whatever, while user applications are not to follow that and to be packaged by their name. I would love to see a more friendlier solution, but I don't find the current way also too complex... as long as the packager knows what he is packaging it should be cake... Yeah, I know the nasty RPMLINT warning, but that can either be worked with rpmlint or it really doesn't hurt to be ignored. Most people will be aware of it's meaning and will why it's there (a user application). It will be far more complicated to identify python modules/extensions following other ways... By the way, I might be wrong, but isn't PyEnchant already a part of python or python-xml ? NM On Fri, Apr 15, 2011 at 7:27 PM, Jan Matejek <jan.matejek(a)novell.com> wrote: > Dne 15.4.2011 17:02, Sascha Peilicke napsal(a): >> >> On Friday 15 April 2011 16:13:49 İsmail Dönmez wrote: >>> >>> On Friday, April 15, 2011 04:13:00 PM Andreas Jaeger wrote: >>>> >>>> On Friday, April 15, 2011 03:46:34 PM Sascha Peilicke wrote: >>>>> >>>>> Hi guys, >>>>> >>>>> currently most Python packages in the Build Service are inconsistently >>>>> named. For instance, upstream 'pyenchant' is named python-enchant, >>>>> 'Cheetah' is named python-cheetah. There are plenty of other examples. >>>>> I'd like to propose a different scheme (much like our Ruby and Perl >>>>> packages): >>>>> >>>>> * Python application packages are named like $UPSTREAM_NAME >>>>> * Python libraries are named python-$UPSTREAM_NAME >>>> >>>> Sascha, what are other projects like Debian, Ubuntu and Fedora doing? >>>> Let's talk with other rpm based distros on whether we can implement the >>>> same scheme - this make cross-distribution building much saner... >>> >>> This is a good idea, python-python-twitter looks really counter-intuitive >>> though, maybe there should be an exception if the package already has a >>> python- prefix. >> >> Yeah, if it's 'python-' we may want to drop that prefix. This seems to be >> the >> case for our Perl and Ruby packages, too. > > +1 to this > -- > To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org > For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org > > -- Nelson Marques /* As cicatrizes lembram-nos de onde estivemos, mas não ditam para onde vamos */ -- Nelson Marques /* As cicatrizes lembram-nos de onde estivemos, mas não ditam para onde vamos */ -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

1 0

[opensuse-packaging] multimedia:apps coriander links to DISCONTINUED:openSUSE:11.1 coriander
by Dave Plater 14 Apr '11

14 Apr '11

I just had a submit request to multimedia:apps coriander which had a broken link to "DISCONTINUED:openSUSE:11.1 coriander", the submitters package was also linked to "DISCONTINUED:openSUSE:11.1 coriander". I deleted mmaps coriander and used osc copypac from the submitters home project to recreate mmapps coriander and because it was there before, recreated the mmapps link. Can somebody enlighten me as to why coriander is linked to DISCONTINUED:openSUSE:11.1? Thanks Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

2 4

[opensuse-packaging] File locations question
by Togan Muftuoglu 13 Apr '11

13 Apr '11

Hi, I am maintainting shorewall packages in security:netfilter and with the recent shorewall package locations of some files have gained flexibility Quoting from the release notes "Distributions have different philosophies about the proper file hierarchy. Two issures are particularly contentious: - Executable files in /usr/share/shorewall*. These include; getparams compiler.pl wait4ifup shorecap ifupdown - Perl Modules in /usr/share/shorewall/Shorewall. To allow distributions to designate alternate locations for these files, the installers (install.sh) now support the following environmental variables: LIBEXEC -- determines where in /usr getparams, compiler.pl, wait4ifup, shorecap and ifupdown are installed. Shorewall and Shorewall6 must be installed with the same value of LIBEXEC. The listed executables are installed in /usr/${LIBEXEC}/shorewall*. The default value of LIBEXEC is 'share'. LIBEXEC is recognized by all installers and uninstallers. PERLLIB -- determines where in /usr the Shorewall perl modules are installed. Shorewall and Shorewall6 must be installed with the same value of PERLLIB. The modules are installed in /usr/${PERLLIB}/Shorewall. The default value of PERLLIB is 'share/shorewall'. PERLLIB is only recognized by the Shorewall and Shorewall6 installers and the same value must be passed to both installers. " Now in terms of the LIBEXEC, I am planning to place them under /usr/lib/shorewall. However I a not sure what to do with the perl modules so I need help in defining what ${PERLLIB} should be. Thanks Togan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

3 2

[opensuse-packaging] gettext.so: undefined symbol: Perl_pad_sv
by Robert Xu 11 Apr '11

11 Apr '11

Hi all, For some reason, any package that is using gettext (or perl-Gettext, still trying to figure out which) is failing with the following error: gettext.so: undefined symbol: Perl_pad_sv These two bugs probably have something to do with it. http://bugs.gentoo.org/show_bug.cgi?id=343405 https://bugzilla.redhat.com/show_bug.cgi?id=518896 Anyone else getting encumbered by this problem? I am building off the latest openSUSE:Factory on a local instance of OBS. -- Robert Xu + Linux is awesome; don't doubt what it can do + rxu(a)lincomlinux.org -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

3 2

[opensuse-packaging] rpmlint - non-utf8-spec-file ?
by Per Jessen 08 Apr '11

08 Apr '11

What does this mean: RPMLINT report: =============== jfsutils.src: W: non-utf8-spec-file /tmp/rpmlint.jfsutils-1.1.15-1.src.rpm.zuUJ47/jfsutils.spec The character encoding of the spec file is not UTF-8. Convert it for example using iconv(1). The spec file contains only US-ASCII, I've checked. What does rpmlint know that I don't? -- Per Jessen, Zürich (14.6°C) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

4 6

[opensuse-packaging] blog post series started for rpmlint and brp warnings / errors
by Dominique Leuenberger a.k.a DimStar 08 Apr '11

08 Apr '11

Hi everybody, We know them all and some of us get frustrated by them: lints and brp checks aborting our builds, even though make and make install perfectly passed through (well, one correction here already: APPARENTLY perfectly passed). I do not argue against the checks at all and I think they are a good thing (tm). But sometimes they can be a little bit cryptic and most of the time require work. so I started a series of blog posts (2 so far) which try to address them. Please bare with me, I'm no hard core crack coder, but I will try to summarize the usual causes and solutions to a problem. Not in every case will the provided solution fit and if you're not sure about correctness in your package: discuss the matter with upstream. Anyway, once you produce a patch, you should always make sure upstream gets it too. So what were the blog posts about so far? Part 1: how to fix brp and rpmlint warnings ? today: Expression compares a char* pointer with a string literal http://dominique.leuenberger.net/blog/?p=151 Part 2: how to fix brp and rpmlint warnings ? today: I: Program causes undefined operation (likely same variable used twice and post/pre incremented in the same expression) http://dominique.leuenberger.net/blog/?p=178 As noted on the first entry, i will gladly take recommendations for which errors you would like to see an entry. I will try to write them up, likely 1 or 2 per week (I am actually not that much of a writer... 0 Hope the series is useful to you... If it saves you a few minutes here and there, then it is. Best regards, Dominique -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

5 5

[opensuse-packaging] data has a longer lifetime than libraries that read the data;What package should own the data directory?
by Paul Elliott 07 Apr '11

07 Apr '11

I have also asked this question on debian-mentors; I thought I would get an opensuse perspective as well. I am working on packaging the Swiss Ephemeris. The Swiss Ephemeris uses a single directory to hold all its data. (Settable by the programmer, so a private directory can be used.) Call this directory the slush fund of data. I want to encourage different programs to share data in one big installed directory, so that different astrology programs do not all have their own private copies of this data. Which is the same. And a large user of space. The upstream has assured me that this data will always be downward compatable, so that if new data formats are ever introduced that old versions of the libraries can not read, new file names will be used for that data, so that old libraries will never try to open files that they can not understand. Any particular data file could be needed or not needed, installed or not installed depending on what is being done. Except for a few short files that should always be there, but they might need to be upgraded with new versions. My problem is: "What package should own the slush fund?" It should not be the library, because when the library upgrades most of the data does not become invalid. Would not want to delete and reinstall all the data at this point. Should not be the package for any particular file, because that package may not be needed hence not installed. Must I create one special essentially imortal package to own the "slush fund"? -- Paul Elliott 1(512)837-1096 pelliott(a)BlackPatchPanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117

1 0

[opensuse-packaging] distro independant rpms and debs for distro independant data?
by Paul Elliott 07 Apr '11

07 Apr '11

This question concerns both the OBS and packaging so I am sending to both lists. I am currently working on packaging the Swiss Ephemeris http://www.astro.com/swisseph/ I am currently at the planning scheming and experimentation stage. First I will do the library. But then there is the data. The data is about 60 files not all of which will be wanted by all people. There may be ways of grouping but I am not sure. Perhaps one rpm per file. The Web page says: > For this extended timespan the ephemeris requires 32 Mbytes of ephemeris > files. It would be a shame if this had to repeat for each distro. There may be other projects with even more data. This data is distro and architecture independent. I understand that there should be different rpm per distro because different distros link libraries differently and do other details differently. There could be rpm version dependencies. Perhaps one distro can not understand rpms from another distro as raw data. My question is this is there a lowest common denominator rpm format that can represent pure data (and a few text licensing files) and be understood by all distros? How would you get the build service to produce such rpms? After you produced them how would you get the build service to serve them for all rpm based distros? Same question for debs and the debian based distros? Unrelated question: a while back OBS debian binary repositories were debian compatible but the source repositories were not. Is this still true? -- Paul Elliott 1(512)837-1096 pelliott(a)BlackPatchPanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117

5 4

[opensuse-packaging] Some headers not found
by Ilya Chernykh 06 Apr '11

06 Apr '11

Hi! I have a package that uses cmake. It uses SDL, Ogre and other libraries. But when compiling it cannot find libraries which are located not in the main include dir (/usr/include), but one or two levels deeper, i.e. in /usr/include/SDL, /usr/include/OGRE, /usr/include/OGRE/Terrain . I was able to add explicit links to some headers, but when a header located in /usr/include/OGRE/Terrain calls another header in the same directory I do not know what to do. Is there a more simple way to make the compiler to know where to search for headers? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

4 5

[opensuse-packaging] confused by e2fsprogs versions
by Greg Freemyer 05 Apr '11

05 Apr '11

All, I have a patch for e2fsprogs 1.41.14 I want to package / test. I see 1.41.14 in the opensuse 11.4 standard repo. But since I'm wanting to build this for factory, I also look there, but I only find a 1.41.11 version and its not in the main repo. Just the filesystems repo. I can link branch the one in 11.4 easy enough, but what I'm see makes no sense to me. http://software.opensuse.org/search?q=e2fsprogs&baseproject=openSUSE%3A11.4… http://software.opensuse.org/search?q=e2fsprogs&baseproject=openSUSE%3AFact… Thanks for clarification Greg -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

7 8

[opensuse-packaging] Is there a good sample Kernel Module package?
by Greg Freemyer 05 Apr '11

05 Apr '11

All, I need to package a kernel module targeting factory. I've tried in the past with some small success, but I never found a good reference module to base my specfile etc. off of. Can anyone recommend one? (Or do I need to sent this to the opensuse-kernel list?) Thanks Greg -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

2 1

[opensuse-packaging] dropping licenses
by Stephan Kulow 04 Apr '11

04 Apr '11

Hi, The licenses package is 300KB on the live cd and the only files linked into are gpl licenses - in addition it's very unclear if links to licenses are really ok. So I submitted a fix for all packages in factory I could find using licenses - for some I had to include a license. The licenses package will soon disappear, so please review and forward the requests. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

4 4

[opensuse-packaging] Buildservice problem?
by Stefan Seyfried 03 Apr '11

03 Apr '11

Hi, is there a maintenance window? Where was it announced (so that I could subscribe to the feed)? How long will it take? Generally there seems to be nothing like a status page for openSUSE services. Would be genuinely useful. -- Stefan Seyfried "Dispatch war rocket Ajax to bring back his body!" -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

4 4

[opensuse-packaging] A .desktop file uses icon from another package
by Ilya Chernykh 02 Apr '11

02 Apr '11

Hi! I have a question. I want to a package which heavily uses icons from another one. But the OBS system does not allow to built it: it says "icon file not installed" even though the dependency on a package that contains the necessary icon is included. What can I do to successfully install this package? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

6 7

[opensuse-packaging] Python 3.2 build problems
by Dave Plater 01 Apr '11

01 Apr '11

I'm busy fighting with the python3-base-3.2 build, which seems to be unpredictable atm, due to blender (against the protests of distro packagers) switching to that version. The 11.4 x86_64 build fails in devel:languages:python:Factory but all the others succeed, I've had varying build results by linking home:plater:blender python3-base to home:plater:blender python3 and devel:languages:python:Factory python3, when linked to devel:languages:python:Factory python3 it mimics the devel build but when linked to home:plater:blender python3 I've had complete build failures and all x86_64 failures with i586 successes with a fresh untouched branched python3 after only adding a fedora conditional for BuildRequires first. I understand that the build service servers aren't 100% in fact the connection was down again a few moments ago and up again now, I don't know if this has any effect that can cause such build behaviour? It also builds differently on my local x86_64 11.4 system using rpmbuild. As it stands now, I've added a few build requirements which seemed to be missing and have experienced an i586 failure due to -pg and -fomit-frame-pointer being incompatible and redefining $RPM_OPT_FLAGS omitting -fomit-frame-pointer (without diving into gcc) can this cause problems? It looks like I've a successful build atm but only after changing a few build options. Here is the diff with comments: %build # use rpm_opt_flags +# Redefine opt flags due to error: -pg and -fomit-frame-pointer are incompatible +export RPM_OPT_FLAGS="-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g" export OPT="$RPM_OPT_FLAGS" #export OPT="-O0 -g" @@ -201,10 +210,12 @@ --docdir=%{_docdir}/python \ --enable-ipv6 \ --with-fpectl \ - --enable-shared + --enable-shared \ + --with-cxx-main=%{_bindir}/c++ configure started asking for a c++ compiler LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH \ - make %{?_smp_mflags} profile-opt + make %{?_smp_mflags} This is the change that had the most effect on the build succeeding. +# profile-opt %check # test_file fails in autobuild env - "stdin.seek(-1)" wrongly succeeds. probably an issue with autobuild's stdin @@ -244,10 +255,10 @@ # cleanup parts that don't belong for so in _md5 _sha1 _sha256 _sha512; do - rm $RPM_BUILD_ROOT%{sitedir}/lib-dynload/$so.* + rm -f $RPM_BUILD_ROOT%{sitedir}/lib-dynload/$so.* _md5 and _sha1 don't exist, I haven't checked the others but when I see things missing that existed before I get worried. done for dir in curses dbm sqlite3 tkinter; do - rm -r $RPM_BUILD_ROOT%{sitedir}/$dir + rm -rf $RPM_BUILD_ROOT%{sitedir}/$dir done # install site-specific tweaks @@ -277,7 +288,7 @@ # move idle config into /etc install -d -m 755 ${RPM_BUILD_ROOT}/etc/idle3 -( +( cd ${RPM_BUILD_ROOT}/%{sitedir}/idlelib/ for file in *.def ; do mv $file ${RPM_BUILD_ROOT}/etc/idle3/ I use kwrite for spec files and it saves in UTF8 also removes trailing white spaces. I would appreciate expert help with this after which python3-3.2 could hopefully be ready for tumbleweed, blender is about to be 2.57 RC1 and will be released in about a month, the current blender in 11.4 is beta plus svn and would have been newer if the switch to python 3.2 hadn't happened. I think blender is the main consumer of python3 along with a couple of gnome apps. Thanks Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

2 5

[opensuse-packaging] Re: [obs submit-request 65647] openSUSE:Factory/perl-File-Slurp: declined by saschpe
by Stephan Kulow 01 Apr '11

01 Apr '11

Donnerstag, 31. März 2011 sent speilicke : > State of submit-request #65647 was changed by saschpe: > > new -> declined > > Comment: > description is >400 lines, too long :-) > Where is a limit documented? Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

3 4