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
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
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
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
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
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
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
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
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