openSUSE Packaging April 2011

packaging@lists.opensuse.org

51 participants
38 discussions

[opensuse-packaging] Right usage of libexecdir?

by Vincent Untz

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

10 years

[opensuse-packaging] RPMLINT warning: W: non-etc-or-var-file-marked-as-conffile /srv/www/htdocs/*

by Ralf Lang

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

10 years, 1 month

[opensuse-packaging] FTLibrary.h not in ftgl-devel

by Javier Llorente

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

10 years, 1 month

[opensuse-packaging] Need help with a rejected license mmlibs glew

by Dave Plater

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

10 years, 1 month

[opensuse-packaging] Need cmake help for openCOLLADA

by Dave Plater

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

10 years, 1 month

[opensuse-packaging] What is an "undefined-non-weak-symbol" and how is it fixed?

by Dave Plater

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

10 years, 1 month

[opensuse-packaging] updated boinc-client

by Sascha Manns

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

10 years, 1 month

[opensuse-packaging] What is supposed to be in the License: field

by Dave Plater

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

10 years, 1 month

[opensuse-packaging] netcdf package

by Filipe Pires Alvarenga Fernandes

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

10 years, 1 month

[opensuse-packaging] "Good spec" guidelines for new packages in Build Service

by Jan Matejek

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

10 years, 1 month

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

openSUSE Packaging April 2011