opensuse / libzypp Goto Github PK
View Code? Open in Web Editor NEWZYpp Package Management library
Home Page: http://doc.opensuse.org/projects/libzypp/HEAD/
License: Other
ZYpp Package Management library
Home Page: http://doc.opensuse.org/projects/libzypp/HEAD/
License: Other
Please see:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777980
The FTBFS against gcc 5 was report for libzypp 14.29.1-2. I will do a test build for latest upstream release during today (hopefully) and report back, if that issue has been resolved already.
Is there a way to abort zypper command with a hook like this (/usr/lib/zypp/plugins/commit/example.py):
#!/usr/bin/env python
#
# zypp plugin
#
import os
import sys
from zypp_plugin import Plugin
class MyPlugin(Plugin):
def COMMITBEGIN( self, headers, body ):
if True:
self.ack()
else:
sys.stderr.write('Abort\n')
sys.exit(1)
plugin = MyPlugin()
plugin.main()
I would like to point out that identifiers like "_PL
" and "_Report
" do not fit to the expected naming convention of the C++ language standard.
Would you like to adjust your selection for unique names?
Hi,
it would be nice to have a cmake OPTION that enables building doc/autodoc/ when doing "make all".
Mike
Hello!
I'm in doubt should I report this issue against libzypp
or zypper
, but it was introduced by this commit in libzypp
.
The problem is that there are the _theGlobalLock
static object in libzypp/zypp/ZYppFactory.cc
and the God
global object in zypper/src/Zypper.cc
. The order of their initialisation is undefined, and that's OK. But the order of calling their dtors is also undefined. If God
is destroyed first, everything is fine, but if _theGlobalLock
is destroyed first, dtor of God
tries to call _theGlobalLock.reset()
that is already unavailable.
As this issue is caused by undefined behavior, it is hard to reproduce. To be honest, I don't know, can it be reproduced on GNU systems or not, but we have zypper
ported to FreeBSD (with numerous modifications to make it possible), and it always segfaults after exit()
.
Error message:
/home/abuild/rpmbuild/BUILD/libzypp-16.3.1/zypp/sat/SolvableType.h: In member function 'bool zypp::sat::SolvableType<Derived>::isKind() const':
/home/abuild/rpmbuild/BUILD/libzypp-16.3.1/zypp/sat/SolvableType.h:66:65: error: expected primary-expression before '>' token
bool isKind() const { return satSolvable().isKind<TRes>(); }
^
/home/abuild/rpmbuild/BUILD/libzypp-16.3.1/zypp/sat/SolvableType.h:66:67: error: expected primary-expression before ')' token
bool isKind() const { return satSolvable().isKind<TRes>(); }
This is wrong according to rpm-software-management/rpm@ab069ec
Originally posted by @Jellyfrog in #168 (comment)
...so that less packages trigger a rebuild of libzypp. As libzypp in return is an (indirect) buildrequire of yast and installation-images, any additional buildrequire increases the chance of a rebuild of all these.
Releasemanager asked for it.
Spec/CMake files need to be adapted (or we figure out how the _multibuild stuff works and if it also solves the issue)
libzypp should use HTTP2 if available, that can be achived by setting CURL_HTTP_VERSION_2TLS
"CURL_HTTP_VERSION_2TLS
Attempt HTTP 2 over TLS (HTTPS) only. libcurl will fall back to HTTP 1.1 if HTTP 2 can't be negotiated with the HTTPS server. For clear text HTTP servers, libcurl will use 1.1. (Added in 7.47.0)"
zypper fails to refresh repositories with GnuPG 2.1.23 (only). This is new behavior with 2.1.23.
Combination tested:
home:AndreasStieger:branches:security:privacy/gpg2
zypper ref -f
(any)..zypper ref -f 14
Forcing raw metadata refresh
Retrieving repository 'update-test' metadata
File 'repomd.xml' from repository 'update-test' is signed with an unknown key ''. Continue? [yes/no] (no):
The GnuPG version seems to operate normally otherwise, but something in the behavior or output changed to break the zypper/libzypp scenario.
/root/hudson/workspace/zypp/head/20-libzypp/checkout/zypp/Digest.cc: In member function ‘bool zypp::Digest::P::maybeInit()’:
/root/hudson/workspace/zypp/head/20-libzypp/checkout/zypp/Digest.cc:108:28: warning: ‘void OPENSSL_config(const char*)’ is deprecated [-Wdeprecated-declarations]
OPENSSL_config(NULL);
^
In file included from /usr/include/openssl/bn.h:31,
from /usr/include/openssl/asn1.h:24,
from /usr/include/openssl/objects.h:916,
from /usr/include/openssl/evp.h:27,
from /root/hudson/workspace/zypp/head/20-libzypp/checkout/zypp/Digest.cc:16:
/usr/include/openssl/conf.h:92:1: note: declared here
DEPRECATEDIN_1_1_0(void OPENSSL_config(const char *config_name))
Check and fix..
i cannot get libzypp to build on my gentoo box, straight off git.
When i strip extern "C" from zypp/xml/Node.cc and zypp/xml/Parser.cc it builds correctly. Otherwise i get "error: template with C linkage" messages on those files.
( https://github.com/yoshi314/libzypp/commit/1657f1532ba7898ee063fe1b2e049db584a5bb78 is the aforementioned modification)
Since my knowledge of C++ is limited, i'd prefer to pose a question on what potential harm does such a change make? Maybe i have something wrong with my setup?
Hi,
when building libzypp on a recent Debian unstable, I get the below FTBFS:
cd /<<PKGBUILDDIR>>/obj-x86_64-linux-gnu/zypp && /usr/bin/g++ -DHAVE_PIPE2 -DHAVE_UDEV -DLOCALEDIR=\"/usr/share/locale\" -DTEXTDOMAIN=\"zypp\" -DVERSION=\"17.6.1\" -DWITH_LIBPROXY_SUPPORT -DZYPP_DLL -D_FILE_OFFSET_BITS=64 -Dzypp_EXPORTS -I/<<PKGBUILDDIR>> -I/<<PKGBUILDDIR>>/obj-x86_64-linux-gnu -I/usr/include/rpm -I/usr/include/x86_64-linux-gnu -I/usr/include/libxml2 -I/<<PKGBUILDDIR>>/obj-x86_64-linux-gnu/zypp -g -O2 -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fno-strict-aliasing -fPIC -g -rdynamic -Wall -Wl,-as-needed -Wp,-D_GLIBCXX_ASSERTIONS -std=c++11 -fvisibility-inlines-hidden -Woverloaded-virtual -Wnon-virtual-dtor -Werror=format-security -g -O2 -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fno-strict-aliasing -fPIC -g -rdynamic -Wall -Wl,-as-needed -Wp,-D_GLIBCXX_ASSERTIONS -std=c++11 -fvisibility-inlines-hidden -Woverloaded-virtual -Wnon-virtual-dtor -O3 -DZYPP_NDEBUG -fPIC -DZYPP_BASE_LOGGER_LOGGROUP=\"zypp\" -o CMakeFiles/zypp.dir/InstanceId.cc.o -c /<<PKGBUILDDIR>>/zypp/InstanceId.cc
[ 44%] Building CXX object zypp/CMakeFiles/zypp.dir/KeyManager.cc.o
cd /<<PKGBUILDDIR>>/obj-x86_64-linux-gnu/zypp && /usr/bin/g++ -DHAVE_PIPE2 -DHAVE_UDEV -DLOCALEDIR=\"/usr/share/locale\" -DTEXTDOMAIN=\"zypp\" -DVERSION=\"17.6.1\" -DWITH_LIBPROXY_SUPPORT -DZYPP_DLL -D_FILE_OFFSET_BITS=64 -Dzypp_EXPORTS -I/<<PKGBUILDDIR>> -I/<<PKGBUILDDIR>>/obj-x86_64-linux-gnu -I/usr/include/rpm -I/usr/include/x86_64-linux-gnu -I/usr/include/libxml2 -I/<<PKGBUILDDIR>>/obj-x86_64-linux-gnu/zypp -g -O2 -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fno-strict-aliasing -fPIC -g -rdynamic -Wall -Wl,-as-needed -Wp,-D_GLIBCXX_ASSERTIONS -std=c++11 -fvisibility-inlines-hidden -Woverloaded-virtual -Wnon-virtual-dtor -Werror=format-security -g -O2 -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fno-strict-aliasing -fPIC -g -rdynamic -Wall -Wl,-as-needed -Wp,-D_GLIBCXX_ASSERTIONS -std=c++11 -fvisibility-inlines-hidden -Woverloaded-virtual -Wnon-virtual-dtor -O3 -DZYPP_NDEBUG -fPIC -DZYPP_BASE_LOGGER_LOGGROUP=\"zypp\" -o CMakeFiles/zypp.dir/KeyManager.cc.o -c /<<PKGBUILDDIR>>/zypp/KeyManager.cc
[ 45%] Building CXX object zypp/CMakeFiles/zypp.dir/KeyRing.cc.o
cd /<<PKGBUILDDIR>>/obj-x86_64-linux-gnu/zypp && /usr/bin/g++ -DHAVE_PIPE2 -DHAVE_UDEV -DLOCALEDIR=\"/usr/share/locale\" -DTEXTDOMAIN=\"zypp\" -DVERSION=\"17.6.1\" -DWITH_LIBPROXY_SUPPORT -DZYPP_DLL -D_FILE_OFFSET_BITS=64 -Dzypp_EXPORTS -I/<<PKGBUILDDIR>> -I/<<PKGBUILDDIR>>/obj-x86_64-linux-gnu -I/usr/include/rpm -I/usr/include/x86_64-linux-gnu -I/usr/include/libxml2 -I/<<PKGBUILDDIR>>/obj-x86_64-linux-gnu/zypp -g -O2 -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fno-strict-aliasing -fPIC -g -rdynamic -Wall -Wl,-as-needed -Wp,-D_GLIBCXX_ASSERTIONS -std=c++11 -fvisibility-inlines-hidden -Woverloaded-virtual -Wnon-virtual-dtor -Werror=format-security -g -O2 -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fno-strict-aliasing -fPIC -g -rdynamic -Wall -Wl,-as-needed -Wp,-D_GLIBCXX_ASSERTIONS -std=c++11 -fvisibility-inlines-hidden -Woverloaded-virtual -Wnon-virtual-dtor -O3 -DZYPP_NDEBUG -fPIC -DZYPP_BASE_LOGGER_LOGGROUP=\"zypp\" -o CMakeFiles/zypp.dir/KeyRing.cc.o -c /<<PKGBUILDDIR>>/zypp/KeyRing.cc
/<<PKGBUILDDIR>>/zypp/KeyManager.cc: In member function 'std::__cxx11::list<std::__cxx11::basic_string<char> > zypp::KeyManagerCtx::Impl::readSignaturesFprsOptVerify(const zypp::filesystem::Pathname&, const zypp::filesystem::Pathname&, bool*)':
/<<PKGBUILDDIR>>/zypp/KeyManager.cc:162:32: error: expected ';' before 'signatures'
id = id.substr( id.size()-16 )
^
;
signatures.push_back( std::move(id) );
~~~~~~~~~~
make[3]: *** [zypp/CMakeFiles/zypp.dir/build.make:1886: zypp/CMakeFiles/zypp.dir/KeyManager.cc.o] Error 1
make[3]: *** Waiting for unfinished jobs....
make[3]: Leaving directory '/<<PKGBUILDDIR>>/obj-x86_64-linux-gnu'
make[2]: *** [CMakeFiles/Makefile2:1086: zypp/CMakeFiles/zypp.dir/all] Error 2
make[2]: Leaving directory '/<<PKGBUILDDIR>>/obj-x86_64-linux-gnu'
make[1]: *** [Makefile:166: all] Error 2
make[1]: Leaving directory '/<<PKGBUILDDIR>>/obj-x86_64-linux-gnu'
make: *** [/usr/share/cdbs/1/class/makefile.mk:77: debian/stamp-makefile-build] Error 2
The build system uses g++ 8.2.0. Might this be its cause?
Thanks for any feedback,
Mike
Please provide man pages for zypp-NameReqPrv and zypp-CheckAccessDeleted.
Quoting the Debian lintian tool:
N:
N: Each binary in /usr/bin, /usr/sbin, /bin, /sbin or /usr/games should
N: have a manual page
N:
N: Note that though the man program has the capability to check for several
N: program names in the NAMES section, each of these programs should have
N: its own manual page (a symbolic link to the appropriate manual page is
N: sufficient) because other manual page viewers such as xman or tkman
N: don't support this.
N:
N: If the name of the man page differs from the binary by case, man may be
N: able to find it anyway; however, it is still best practice to make the
N: case of the man page match the case of the binary.
N:
N: If the man pages are provided by another package on which this package
N: depends, lintian may not be able to determine that man pages are
N: available. In this case, after confirming that all binaries do have man
N: pages after this package and its dependencies are installed, please add
N: a lintian override.
N:
N: Refer to Debian Policy Manual section 12.1 (Manual pages) for details.
N:
N: Severity: normal, Certainty: possible
N:
N: Check: manpages, Type: binary
N:
N: upstream has been notified about the lack of man pages for libzypp tools
O: libzypp-bin: binary-without-manpage usr/bin/zypp-CheckAccessDeleted
N: upstream has been notified about the lack of man pages for libzypp tools
O: libzypp-bin: binary-without-manpage usr/bin/zypp-NameReqPrv
Alternatively, if those executables are not to be executed by users but rather used internally, consider putting them into the {libexecdir} path instead of the {bindir} path.
Greets,
Mike
The tool “zypper 1.14.5” displays the message “Warning: File 'repomd.xml' from repository '…' is signed with an unknown key ''.” on my system.
I tried to clarify this questionable software situation already in a forum (without a final solution so far).
I have taken another look at involved source files in the hope to get an explanation for a misssing information.
Ancient bug https://bugzilla.opensuse.org/show_bug.cgi?id=463318 was in danger of being autoclosed; reopening it here.
Currently libzypp collects %posttrans
scriptlets when installing packages and handles them by itself instead letting rpm to run them in the end of transaction as desired. There is at least one case when this breaks correct upgrade procedure.
Consider upgrading rpm itself, when the new version is linked to new db version, which breaks backwards compatibility. To deal with this, %posttrans
scriptlet removing old rpm database is added to the package. So old version of rpm
installs all new packages including rpm, executes %posttrans
and terminate correctly. Next time the new rpm
is run, which re-creates the database using new stroage format and then operates correctly.
When using zypper
for such upgrade, old version of rpm
is run to upgrade a single package breaking compatibility, but the %posttrans
scriptlet execution is delayed. Then new rpm
is executed to upgrade next package, but it fails because it's unable to open the database (in old format). The upgrade procedure aborts.
The obvious solution is to run %posttrans
scriptlet when it is intended to run — after completion of rpm transaction.
After
dba170d
zypp::sat::LookupAttr::iterator::dip_equal(detail::CDataiterator const&, detail::Dataiterator const&) const
exposes the type from libsolv-0.7, i.e. detail::CDataIterator changes from _DataIterator to s_DataIterator
At the moment, tests are not built and run when "make all" is issued. The test builds have to be triggered by "make ctest".
It would be handy if an cmake configure option existed that would enable test builds and runs as part of the "all" make rule.
Hi,
ZYpp is a great package manager, and I truly admire the work you folks do, but ZYpp is perhaps the slowest package manager at downloading packages as it doesn't support using aria2c to download them (although I know it once did) and it doesn't have support for multiple package downloads at once and it doesn't, at least by default, use delta RPMs. I'm presently using Tumbleweed and trying upgrade from 20180606 to 20180613 and it seems like it's going to take > 13 hours just to download the 4.6 GB packages in this upgrade. My net is capable of 5 MB/s downloads, but now I'm stuck at ~50-100KB/s as an average download speed.
My question is, essentially, can this be improved? Or is this a feature that very few care about and hence what I'm asking is likely to fall on deaf ears?
Thanks for your time,
Brenton
The Debian lintian system discovered several typos in the built library, thus in upstream code.
Hi!
I'm trying to build libzypp for mipsel architecture on Debian (tried both jessie with gcc 4.9.2 and stretch with gcc 6.3.0). Compilation fails because of standard macro _mips
defined by compiler, that expands in zypp/Arch.cc.
Example of macro expansion:
% cat test.c
#define DEF_BUILTIN(A) \
namespace { static inline const IdString & _##A () { static IdString __str(#A); return __str; } } \
const Arch Arch_##A( _##A() )
DEF_BUILTIN( noarch );
DEF_BUILTIN( mips );
DEF_BUILTIN( mipsel );
DEF_BUILTIN( mips64 );
DEF_BUILTIN( mips64el );
#undef DEF_BUILTIN
% mipsel-linux-gnu-gcc -E test.c -o test
% cat test
# 1 "test.c"
# 1 "<built-in>"
# 1 "<command-line>"
# 31 "<command-line>"
# 1 "/usr/mipsel-linux-gnu/include/stdc-predef.h" 1 3
# 32 "<command-line>" 2
# 1 "test.c"
namespace { static inline const IdString & _noarch () { static IdString __str("noarch"); return __str; } } const Arch Arch_noarch( _noarch() );
namespace { static inline const IdString & 1 () { static IdString __str("mips"); return __str; } } const Arch Arch_mips( 1() );
namespace { static inline const IdString & _mipsel () { static IdString __str("mipsel"); return __str; } } const Arch Arch_mipsel( _mipsel() );
namespace { static inline const IdString & _mips64 () { static IdString __str("mips64"); return __str; } } const Arch Arch_mips64( _mips64() );
namespace { static inline const IdString & _mips64el () { static IdString __str("mips64el"); return __str; } } const Arch Arch_mips64el( _mips64el() );
As you can see, _mips
expands to 1
.
Compiler info:
% mipsel-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=mipsel-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc-cross/mipsel-linux-gnu/6/lto-wrapper
Target: mipsel-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 6.3.0-18' --with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-6 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm --disable-libsanitizer --disable-libquadmath --enable-plugin --enable-default-pie --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-mipsel-cross/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-mipsel-cross --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-mipsel-cross --with-arch-directory=mips --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libgcj --enable-multiarch --enable-multilib --with-arch-32=mips32r2 --with-fp-32=xx --with-madd4=no --with-lxc1-sxc1=no --enable-targets=all --with-arch-64=mips64r2 --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=mipsel-linux-gnu --program-prefix=mipsel-linux-gnu- --includedir=/usr/mipsel-linux-gnu/include
Thread model: posix
gcc version 6.3.0 20170516 (Debian 6.3.0-18)
Unable to have a success build using boost-1.70
;--------------------------------------------------------------------------------------------------------------
-- The C compiler identification is GNU 9.1.0
-- The CXX compiler identification is GNU 9.1.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Building for SUSE
-- Libraries will be installed in /usr/lib
-- Header files will be installed in /usr/include
-- Config files will be installed in /etc
-- Performing Test CC_FORMAT_SECURITY
-- Performing Test CC_FORMAT_SECURITY - Failed
-- Performing Test CXX_FORMAT_SECURITY
-- Performing Test CXX_FORMAT_SECURITY - Failed
-- Looking for pipe2
-- Looking for pipe2 - found
-- Writing spec file...
-- I hate you rpm-lint...!!!
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - not found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- May use threads.
-- rpm found: includes in /usr/include, library in /usr/lib/librpm.so (suspect 4.x)
-- Found Boost 1.70.0 at /usr/lib/cmake/Boost-1.70.0
-- Requested configuration: QUIET REQUIRED COMPONENTS program_options;unit_test_framework;thread
-- Found boost_headers 1.70.0 at /usr/lib/cmake/boost_headers-1.70.0
-- Found boost_program_options 1.70.0 at /usr/lib/cmake/boost_program_options-1.70.0
-- libboost_program_options.a
-- Adding boost_program_options dependencies: headers
-- Found boost_unit_test_framework 1.70.0 at /usr/lib/cmake/boost_unit_test_framework-1.70.0
-- libboost_unit_test_framework.a
-- Adding boost_unit_test_framework dependencies: headers
-- Found boost_thread 1.70.0 at /usr/lib/cmake/boost_thread-1.70.0
-- libboost_thread.a
-- Adding boost_thread dependencies: headers
-- Boost found.
-- Found Boost components:
program_options;unit_test_framework;thread
-- boost found: includes in , library in
-- Found Gettext: /usr/bin/msgmerge (found version "0.20.1")
-- Found Gettext:
-- Found CURL: /usr/lib/libcurl.so (found version "7.63.0")
-- Found LibXml2: /usr/lib/libxml2.so (found version "2.9.9")
-- Found ZLIB: /usr/lib/libz.so (found version "1.2.11")
-- Found LibSolv: /usr/lib/libsolv.so
-- Found LibSolv_ext: /usr/lib/libsolvext.so
-- Found LibSolv: /usr/include /usr/lib/libsolv.so;/usr/lib/libsolvext.so
-- Found gpgme-config at /usr/bin/gpgme-config
-- Found gpgme v1.13.1, checking for flavours...
-- Found flavour 'vanilla', checking whether it's usable...yes
-- Found flavour 'pthread', checking whether it's usable...yes
-- Usable gpgme flavours found: vanilla pthread
-- Found libcrypto: /usr/lib/libcrypto.so
-- Found OpenSSL: /usr/lib/libssl.so
-- Looking for udev_enumerate_new
-- Looking for udev_enumerate_new - not found
-- Could NOT find Udev (missing: UDEV_LIBRARY UDEV_INCLUDE_DIR USABLE_UDEV)
-- hal not found
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.2")
-- Checking for one of the modules 'libproxy-1.0'
-- doxygen is not available. Can't build the documentation.
-- soname: 1712.0.0
-- version: 17.12.0
-- Writing pkg-config file...
-- FindZypp.cmake will be installed in /usr/share/cmake/Modules
-- zypp.conf will be installed in /etc/zypp
-- needreboot will be installed in /etc/zypp/
-- systemCheck will be installed in /etc/zypp
-- Configuring done
-- Generating done
;--------------------------------------------------------------------------------------
compilation start to fail....
;--------------------------------------------------------------------------------------
[ 88%] Built target zypp
[ 88%] Linking CXX executable zypp-pubkey
/usr/bin/ld: CMakeFiles/zypp-pubkey.dir/zypp-pubkey.cc.o: in function boost::program_options::typed_value<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, char>::xparse(boost::any&, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&) const': /usr/include/boost/program_options/detail/value_semantic.hpp:184: undefined reference to
boost::program_options::validate(boost::any&, std::vector<std::__cxx11::basic_string<char, std::char_traits, std::allocator >, std::allocator<std::__cxx11::basic_string<char, std::char_traits, std::allocator > > > const&, std::__cxx11::basic_string<char, std::char_traits, std::allocator >*, int)'
/usr/bin/ld: CMakeFiles/zypp-pubkey.dir/zypp-pubkey.cc.o: in function boost::program_options::error_with_option_name::~error_with_option_name()': /usr/include/boost/program_options/errors.hpp:124: undefined reference to
vtable for boost::program_options::error_with_option_name'
/usr/bin/ld: CMakeFiles/zypp-pubkey.dir/zypp-pubkey.cc.o: in function non-virtual thunk to boost::wrapexcept<boost::program_options::invalid_option_value>::~wrapexcept()': zypp-pubkey.cc:(.text._ZN5boost10wrapexceptINS_15program_options20invalid_option_valueEED1Ev[_ZN5boost10wrapexceptINS_15program_options20invalid_option_valueEED1Ev]+0x4f): undefined reference to
vtable for boost::program_options::error_with_option_name
...........................
....
;--------------------------------------------------------------------------------------
same compilation context is working fine with boost-1.69
I am unable to, consitenly, build libzypp (17.14.0), many time returned error is:
;-------------------------------------------------
make[1]: *** Waiting for unfinished jobs....
a2x: ERROR: "xsltproc" --stringparam callout.graphics 0 --stringparam navig.graphics 0 --stringparam admon.textlabel 1 --stringparam admon.graphics 0 "/usr/etc/asciidoc/docbook-xsl/manpage.xsl" "/home/jmp/rpmbuild/BUILD/libzypp-17.14.0/build/doc/zypp-NameReqPrv.1.xml" returned non-zero exit status 5
make[2]: *** [doc/CMakeFiles/zypp-NameReqPrv.1_Target.dir/build.make:61: doc/zypp-NameReqPrv.1] Error 1
make[2]: Leaving directory '/home/jmp/rpmbuild/BUILD/libzypp-17.14.0/build'
;-------------------------------------------------
seems related to a make -j option (we have 28 processors, so we set it to 28),
setting -j1 seems to make build successful.
according to me, with such option, docs should NOT be build, why xsltproc, still be used and
internet server probed?
I'm trying to build libzypp 17.1.1 with rpm 4.14 and openssl 1.1 and while it builds, a lot of the unit tests fail:
Executing(%check): /bin/sh -e /var/tmp/rpm-tmp.f56pJn
+ umask 022
+ cd /builddir/build/BUILD
~/build/BUILD/libzypp-17.1.1/tests ~/build/BUILD/libzypp-17.1.1
+ cd libzypp-17.1.1
+ pushd tests
+ LD_LIBRARY_PATH=/builddir/build/BUILDROOT/libzypp-17.1.1-1.fc28.x86_64/usr/lib64:
+ ctest .
Test project /builddir/build/BUILD/libzypp-17.1.1/tests
Start 1: CredentialManager_test
1/77 Test #1: CredentialManager_test ........... Passed 0.03 sec
Start 2: CredentialFileReader_test
2/77 Test #2: CredentialFileReader_test ........ Passed 0.01 sec
Start 3: MediaProducts_test
3/77 Test #3: MediaProducts_test ............... Passed 0.01 sec
Start 4: MetaLinkParser_test
4/77 Test #4: MetaLinkParser_test ..............***Exception: Child aborted 0.22 sec
Start 5: Arch_test
5/77 Test #5: Arch_test ........................ Passed 0.01 sec
Start 6: Capabilities_test
6/77 Test #6: Capabilities_test ................***Exception: Child aborted 0.32 sec
Start 7: CheckSum_test
7/77 Test #7: CheckSum_test .................... Passed 0.02 sec
Start 8: ContentType_test
8/77 Test #8: ContentType_test ................. Passed 0.00 sec
Start 9: CpeId_test
9/77 Test #9: CpeId_test ....................... Passed 0.02 sec
Start 10: Date_test
10/77 Test #10: Date_test ........................ Passed 0.01 sec
Start 11: Dup_test
11/77 Test #11: Dup_test ......................... Passed 0.02 sec
Start 12: Digest_test
12/77 Test #12: Digest_test ...................... Passed 0.01 sec
Start 13: Deltarpm_test
13/77 Test #13: Deltarpm_test ....................***Exception: Child aborted 0.36 sec
Start 14: Edition_test
14/77 Test #14: Edition_test ..................... Passed 0.02 sec
Start 15: ExtendedPool_test
15/77 Test #15: ExtendedPool_test ................ Passed 0.05 sec
Start 16: Fetcher_test
16/77 Test #16: Fetcher_test .....................***Exception: Child aborted 0.83 sec
Start 17: FileChecker_test
17/77 Test #17: FileChecker_test ................. Passed 0.13 sec
Start 18: Flags_test
18/77 Test #18: Flags_test ....................... Passed 0.01 sec
Start 19: InstanceId_test
19/77 Test #19: InstanceId_test ..................***Exception: Child aborted 0.22 sec
Start 20: KeyRing_test
20/77 Test #20: KeyRing_test ..................... Passed 0.23 sec
Start 21: Locale_test
21/77 Test #21: Locale_test ...................... Passed 0.01 sec
Start 22: Locks_test
22/77 Test #22: Locks_test .......................***Exception: Child aborted 0.23 sec
Start 23: MediaSetAccess_test
23/77 Test #23: MediaSetAccess_test .............. Passed 1.06 sec
Start 24: PathInfo_test
24/77 Test #24: PathInfo_test .................... Passed 0.02 sec
Start 25: Pathname_test
25/77 Test #25: Pathname_test .................... Passed 0.01 sec
Start 26: PluginFrame_test
26/77 Test #26: PluginFrame_test ................. Passed 6.03 sec
Start 27: PoolQuery_test
27/77 Test #27: PoolQuery_test ...................***Exception: Child aborted 0.23 sec
Start 28: ProgressData_test
28/77 Test #28: ProgressData_test ................ Passed 0.01 sec
Start 29: PtrTypes_test
29/77 Test #29: PtrTypes_test .................... Passed 0.01 sec
Start 30: PublicKey_test
30/77 Test #30: PublicKey_test ................... Passed 0.05 sec
Start 31: RWPtr_test
31/77 Test #31: RWPtr_test ....................... Passed 0.00 sec
Start 32: RepoInfo_test
32/77 Test #32: RepoInfo_test ....................***Exception: Child aborted 1.38 sec
Start 33: RepoManager_test
33/77 Test #33: RepoManager_test .................***Exception: Child aborted 0.38 sec
Start 34: RepoStatus_test
34/77 Test #34: RepoStatus_test .................. Passed 0.01 sec
Start 35: ResKind_test
35/77 Test #35: ResKind_test ..................... Passed 0.01 sec
Start 36: ResStatus_test
36/77 Test #36: ResStatus_test ................... Passed 0.01 sec
Start 37: Selectable_test
37/77 Test #37: Selectable_test ..................***Exception: Child aborted 0.25 sec
Start 38: SetRelationMixin_test
38/77 Test #38: SetRelationMixin_test ............ Passed 0.00 sec
Start 39: SetTracker_test
39/77 Test #39: SetTracker_test .................. Passed 0.00 sec
Start 40: StrMatcher_test
40/77 Test #40: StrMatcher_test .................. Passed 0.01 sec
Start 41: Target_test
41/77 Test #41: Target_test ......................***Exception: Child aborted 0.31 sec
Start 42: Url_test
42/77 Test #42: Url_test ......................... Passed 0.02 sec
Start 43: UserData_test
43/77 Test #43: UserData_test .................... Passed 0.00 sec
Start 44: Vendor_test
44/77 Test #44: Vendor_test ......................***Exception: Child aborted 0.29 sec
Start 45: Vendor2_test
45/77 Test #45: Vendor2_test .....................***Exception: Child aborted 0.23 sec
Start 46: Glob_test
46/77 Test #46: Glob_test ........................ Passed 0.01 sec
Start 47: Sysconfig_test
47/77 Test #47: Sysconfig_test ...................***Exception: Child aborted 0.27 sec
Start 48: String_test
48/77 Test #48: String_test ...................... Passed 0.02 sec
Start 49: InterProcessMutex_test
49/77 Test #49: InterProcessMutex_test ........... Passed 7.02 sec
Start 50: InterProcessMutex2_test
50/77 Test #50: InterProcessMutex2_test .......... Passed 6.02 sec
Start 51: ProductFileReader_test
51/77 Test #51: ProductFileReader_test ...........***Exception: Child aborted 0.23 sec
Start 52: RepoFileReader_test
52/77 Test #52: RepoFileReader_test .............. Passed 0.01 sec
Start 53: RepoindexFileReader_test
53/77 Test #53: RepoindexFileReader_test ......... Passed 0.01 sec
Start 54: HistoryLogReader_test
54/77 Test #54: HistoryLogReader_test ............***Exception: Child aborted 0.40 sec
Start 55: RepomdFileReader_test
55/77 Test #55: RepomdFileReader_test ............***Exception: Child aborted 0.21 sec
Start 56: PatchesFileReader_test
56/77 Test #56: PatchesFileReader_test ...........***Exception: Child aborted 0.32 sec
Start 57: inidict_test
57/77 Test #57: inidict_test .....................***Exception: Child aborted 0.30 sec
Start 58: iniparser_test
58/77 Test #58: iniparser_test ...................***Exception: Child aborted 0.22 sec
Start 59: WebpinResultFileReader_test
59/77 Test #59: WebpinResultFileReader_test ......***Exception: Child aborted 0.30 sec
Start 60: DUdata_test
60/77 Test #60: DUdata_test ...................... Passed 0.08 sec
Start 61: ExtendedMetadata_test
61/77 Test #61: ExtendedMetadata_test ............***Exception: Child aborted 0.24 sec
Start 62: MirrorList_test
62/77 Test #62: MirrorList_test ..................***Exception: Child aborted 1.38 sec
Start 63: PluginServices_test
63/77 Test #63: PluginServices_test .............. Passed 0.02 sec
Start 64: RepoLicense_test
64/77 Test #64: RepoLicense_test ................. Passed 0.10 sec
Start 65: RepoSigcheck_test
65/77 Test #65: RepoSigcheck_test ................ Passed 0.50 sec
Start 66: RepoVariables_test
66/77 Test #66: RepoVariables_test ............... Passed 0.02 sec
Start 67: YUMDownloader_test
67/77 Test #67: YUMDownloader_test ...............***Exception: Child aborted 0.25 sec
Start 68: Downloader_test
68/77 Test #68: Downloader_test ..................***Exception: Child aborted 0.30 sec
Start 69: IdString_test
69/77 Test #69: IdString_test .................... Passed 0.01 sec
Start 70: LookupAttr_test
70/77 Test #70: LookupAttr_test ..................***Exception: Child aborted 0.30 sec
Start 71: Pool_test
71/77 Test #71: Pool_test ........................***Exception: Child aborted 0.32 sec
Start 72: Queue_test
72/77 Test #72: Queue_test ....................... Passed 0.01 sec
Start 73: Map_test
73/77 Test #73: Map_test ......................... Passed 0.01 sec
Start 74: Solvable_test
74/77 Test #74: Solvable_test ....................***Exception: Child aborted 0.26 sec
Start 75: SolvParsing_test
75/77 Test #75: SolvParsing_test .................***Exception: Child aborted 0.30 sec
Start 76: WhatObsoletes_test
76/77 Test #76: WhatObsoletes_test ............... Passed 0.03 sec
Start 77: WhatProvides_test
77/77 Test #77: WhatProvides_test ................***Exception: Child aborted 0.27 sec
61% tests passed, 30 tests failed out of 77
Total Test time (real) = 32.93 sec
The following tests FAILED:
4 - MetaLinkParser_test (Child aborted)
6 - Capabilities_test (Child aborted)
13 - Deltarpm_test (Child aborted)
16 - Fetcher_test (Child aborted)
19 - InstanceId_test (Child aborted)
22 - Locks_test (Child aborted)
27 - PoolQuery_test (Child aborted)
32 - RepoInfo_test (Child aborted)
33 - RepoManager_test (Child aborted)
37 - Selectable_test (Child aborted)
41 - Target_test (Child aborted)
44 - Vendor_test (Child aborted)
45 - Vendor2_test (Child aborted)
47 - Sysconfig_test (Child aborted)
51 - ProductFileReader_test (Child aborted)
54 - HistoryLogReader_test (Child aborted)
55 - RepomdFileReader_test (Child aborted)
56 - PatchesFileReader_test (Child aborted)
57 - inidict_test (Child aborted)
58 - iniparser_test (Child aborted)
59 - WebpinResultFileReader_test (Child aborted)
61 - ExtendedMetadata_test (Child aborted)
62 - MirrorList_test (Child aborted)
67 - YUMDownloader_test (Child aborted)
68 - Downloader_test (Child aborted)
70 - LookupAttr_test (Child aborted)
71 - Pool_test (Child aborted)
74 - Solvable_test (Child aborted)
75 - SolvParsing_test (Child aborted)
77 - WhatProvides_test (Child aborted)
Errors while running CTest
error: Bad exit status from /var/tmp/rpm-tmp.f56pJn (%check)
Bad exit status from /var/tmp/rpm-tmp.f56pJn (%check)
RPM build errors:
Child return code was: 1
Full scratch build log: libzypp-17.1.1-fc28-scratch-build.log.txt
Koji scratch build task (where all the logs are): https://koji.fedoraproject.org/koji/taskinfo?taskID=24301064
OBS build package: https://build.opensuse.org/package/show/home:Pharaoh_Atem:Zypper_Fedora/libzypp
Note that this is also failing with libzypp 16.15.6 (which is why I attempted to upgrade to 17.1.1 to fix it): https://koji.fedoraproject.org/koji/taskinfo?taskID=24293904
Both versions are supposed to be OpenSSL 1.1 compatible, but they don't seem to be.
Hi,
it would be good to have a cmake OPTION that includes the po/ subdirectory in "make all" builds.
Thanks,
Mike
Hi,
with the next release of libsolv, the function pool_setdisttype will always be provided (not only if MULTI_SEMANTICS was True at build time).
As it could be possible that libsolv has been compiled with other distro default (i.e. on Debian), libzypp will fail if the disttype will not explicitly be set before using libsolv symbols.
For reference see [1]
Mike
I'm working on updating boost to version 1.56 in openSUSE Factory (new packages are in devel:libraries:c_c++ / boost). Currently libzypp build is failed, see https://build.opensuse.org/build/home:Dmitry_R:boost/openSUSE_Factory/x86_64/libzypp/_log
I'm guessing that https://bugzilla.opensuse.org/show_bug.cgi?id=500134 is still valid, but I'm reopening it here in the hopes of getting more attention. Please refer to the original bug report for details.
on openSUSE at least we have number of repos that are default and pretty much fixed. So instead of putting them in /etc, generated by some product file it would be easier if some package could provide them. The package would need to put the default repo definitions in /usr. Enabling/disabling could be handled with symlinks in /etc, similar to what systemd does.
That would help a lot with e.g. JeOS which has to duplicate the information which repos to add. Would also help on dist upgrades as repos would change automatically when the package gets updated.
We have this bug in the YaST team (see the screenshot attached there). The suggested solution is to simply not list btrfs subvolumes in that "Disk Usage" list. For generating the list we are using zypp::DiskUsageCounter::detectMountPoints()
. For each entry in that list we can check a flag (Hint_growonly
) to know if that entry is an btrfs snapshot.
Would you find reasonable to also have a flag to identify btfs subvolumes? Not only for the sake of our particular bug, but in general subvolumes add more noise than information to the space calculation.
If you are willing to include such functionality I can try to create a pull request. But beware I'm a Ruby developer not having touched C++ for ages, so better check my code twice. :-)
said methods should use an async future wrapped result to allow many simultaneous gets managed at the application level. These should support callbacks for notification of error/complete.
This is to overcome unparallelized download limitations which slow down zypper updates via either slow package downloads or per connection limits. It is quite often the case downloads do not saturate available bandwidth. Yet downloading a set of package urls or increasing connections for each download (both approaches have pros/cons depending on package sizes and number of packages to download) with aria2/curl can easily perform the task in parallel.
For many media handlers, these futures would be immediately available. For remote (Curl, CIFS, NFS - in decreasing order of priority), it should be optional to allow parallel downloads.
This would require a poll-based reactor which each media handler cooperates with to perform with async, lazy evaluation, or simply wrapping the current implementation in a future otherwise. Curl supports parallel downloads trivially.
zypper could then, in download.cc, perform the async operations - perhaps in another thread, or perhaps using something like boost::context to jump around ala greenthreads. Either it could be done by filling the package cache and not changing the big for-loop over the package dos, or it could install packages (in complying with heap/in-advance) as they finish their downloads in reaction to callbacks (overall least wait time to user).
I've long meant to have a hand in doing but I simply have a hard time managing the number of classes involved in this and zypper... x2 with all those PIMPLs. Let me know if there's anything I can help short of cracking out the implementation. I really think we can save alot of users and developers time here.
This configuration files are in the wrong place: /var/lib/zypp
instead of /etc/zypp
. Please change them to the correct location.
I'm integrating GNOME Software's distribution upgrade feature into Leap. I need implement PackageKit's zypp backend to upgrade Leap. Do I need manually replace the version number in repo url and "dup" the system? Is there any other convenient way for this?
Thanks
When building libzypp and Zypper for Fedora, it fails to build because Fedora's libsolv doesn't have Helix repo support. As far as I can tell, SUSE does not use the helix repo format, nor does it use rug
anymore.
I'm hesitant to ask for libsolv to have support for this repo format added to libsolv when it's not really used anymore. Could libzypp and Zypper be modified so that they don't require it (and it can be enabled with a compile time flag, if needed)?
When doing a scratch build of libzypp with the unit tests enabled, there are several unit tests that fail.
The failure report is as follows:
81% tests passed, 14 tests failed out of 73
Total Test time (real) = 39.77 sec
The following tests FAILED:
5 - Capabilities_test (Failed)
12 - Deltarpm_test (Failed)
17 - InstanceId_test (Failed)
20 - Locks_test (Failed)
25 - PoolQuery_test (Failed)
31 - RepoManager_test (Failed)
39 - Target_test (Failed)
59 - ExtendedMetadata_test (Failed)
62 - DUdata_test (Failed)
66 - LookupAttr_test (Failed)
67 - Pool_test (Failed)
70 - Solvable_test (Failed)
71 - SolvParsing_test (Failed)
73 - WhatProvides_test (Failed)
Errors while running CTest
Full build log for x86_64 attached: libzypp-16.4.3-build.log.txt
Other build logs are viewable from Fedora Koji.
I read the code of zypper. But it is way too complex to understand. I am trying to make a simple GUI to show and upgrade Tumbleweed snapshots. Would like to know functions that provide zypper dup
feature. Thanks!
/builddir/build/BUILD/libzypp-16.15.2/zypp/target/rpm/RpmHeader.cc:14:10: fatal error: rpm/ugid.h: No such file or directory
#include <rpm/ugid.h>
^~~~~~~~~~~~
...
/builddir/build/BUILD/libzypp-16.15.2/zypp/target/rpm/BinHeader.cc:21:17: error: conflicting declaration 'typedef int32_t rpm_count_t'
typedef int32_t rpm_count_t;
^~~~~~~~~~~
In file included from /usr/include/rpm/rpmio.h:16:0,
from /usr/include/rpm/rpmlib.h:13,
from /builddir/build/BUILD/libzypp-16.15.2/zypp/target/rpm/librpm.h:25,
from /builddir/build/BUILD/libzypp-16.15.2/zypp/target/rpm/BinHeader.cc:12:
/usr/include/rpm/rpmtypes.h:29:18: note: previous declaration as 'typedef uint32_t rpm_count_t'
typedef uint32_t rpm_count_t;
^~~~~~~~~~~
/builddir/build/BUILD/libzypp-16.15.2/zypp/target/rpm/BinHeader.cc: In constructor 'zypp::target::rpm::HeaderEntryGetter::HeaderEntryGetter(headerToken_s* const&, rpmTag&)':
/builddir/build/BUILD/libzypp-16.15.2/zypp/target/rpm/BinHeader.cc:82:7: error: '::headerGetEntry' has not been declared
{ ::headerGetEntry( h_r, tag_r, hTYP_t(&_type), &_val, &_cnt ); }
^~~~~~~~~~~~~~
/builddir/build/BUILD/libzypp-16.15.2/zypp/target/rpm/BinHeader.cc:82:7: note: suggested alternative: 'headerIsEntry'
{ ::headerGetEntry( h_r, tag_r, hTYP_t(&_type), &_val, &_cnt ); }
^~~~~~~~~~~~~~
headerIsEntry
/builddir/build/BUILD/libzypp-16.15.2/zypp/target/rpm/BinHeader.cc:82:35: error: 'hTYP_t' was not declared in this scope
{ ::headerGetEntry( h_r, tag_r, hTYP_t(&_type), &_val, &_cnt ); }
^~~~~~
For building libzypp against a multi-arch distro (like Debian), it is required that the header files can be installed in an architecture-specific include directory (e.g. /usr/include//).
The patch below provides this functionality:
http://anonscm.debian.org/cgit/collab-maint/libzypp.git/tree/debian/patches/1001_configurable-include-dir.patch
From RH#1766128:
In libzypp-17.14.0 and upstream as of today, libzypp assumes that rpmdb has a file named
Packages
in several places inzypp/target/rpm/RpmDb.cc
.
As of rpm >= 4.13, this is not a valid assumption.
There is some work going on to replace BDB in Fedora's RPM with one of the other backends for the RPMDB (likely the upcoming SQLite backend, but who knows?). It'd be great if the zypp stack was no longer assuming there was a specific rpmdb type.
A method named stderr
is defined here. That's not a problem with glibc, but in some other libc implementations stderr
can be defined as a macro. E. g. in Solaris libc it is a macro that expands to (&__iob[2])
, that results in compilation error declaration of '__iob' as array of references
. Renaming this method, e. g. to stdErr
, will make the code more portable.
GCC detect quite some places where indentation is misleading. Maybe it's a potential bug:
/home/marxin/Programming/libzypp/zypp/CpeId.cc: In function ‘bool zypp::{anonymous}::matchWildcardedString(std::__cxx11::string, std::__cxx11::string)’:
/home/marxin/Programming/libzypp/zypp/CpeId.cc:848:4: warning: this ‘else’ clause does not guard... [-Wmisleading-indentation]
else
^~~~
/home/marxin/Programming/libzypp/zypp/CpeId.cc:850:6: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘else’
src.erase( 0, 1 );
^~~
/home/marxin/Programming/libzypp/zypp/sat/Solvable.cc: In member function ‘std::__cxx11::string zypp::sat::Solvable::lookupStrAttribute(const zypp::sat::SolvAttr&, const zypp::Locale&) const’:
/home/marxin/Programming/libzypp/zypp/sat/Solvable.cc:143:2: warning: this ‘for’ clause does not guard... [-Wmisleading-indentation]
for ( Locale l( lang_r ); l; l = l.fallback() )
^~~
/home/marxin/Programming/libzypp/zypp/sat/Solvable.cc:147:4: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘for’
s = ::solvable_lookup_str_lang( _solvable, attr.id(), 0, 0 );
^
/home/marxin/Programming/libzypp/zypp/base/StrMatcher.cc:208:7: warning: this ‘if’ clause does not guard... [-Wmisleading-indentation]
if ( ! string_r )
^~
/home/marxin/Programming/libzypp/zypp/base/StrMatcher.cc:210:2: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘if’
return ::datamatcher_match( _matcher.get(), string_r );
^~~~~~
Thanks
Martin
With CMake 3.14, the file build/doc/autodoc/libzypp.doxytag ist not found and the installation breaks.
See for example:
https://build.opensuse.org/package/live_build_log/openSUSE:Factory:Staging:L/libzypp/standard/x86_64
Some hints are given in a merge request:
https://build.opensuse.org/request/show/687545
The two tests cases in Downloader_test
use x86-based baseline data, and thus kde-10.3-71.i586.pat
and kde-10.3-71.i586.pat.gz
will not be found on architectures on compatible with i586 (so anything different than iX86, x86_64, and x32).
Would it be possible to either add more test data for other architectures, or otherwise enable Downloader_test
only on x86-based architectures?
to reproduce
echo requires:zypper >> /etc/zypp/systemCheck
zypper rm zypper
actual result:
Solution 1: ignore the warning of a broken system (requires:zypper)
Solution 2: keep zypper-1.13.40-17.2.x86_64
but option 1 actually does not work.
It should at least give a hint that editing /etc/zypp/systemCheck would help
I use selfbuilded zypper and libzepp with glibc-2.28 and gcc-6.4.0
When i run zypper i got
double free or corruption (out)
Aborted (core dumped)
In gdb:
Program received signal SIGABRT, Aborted.
0xf7fd3059 in __kernel_vsyscall ()
(gdb) bt
#0 0xf7fd3059 in __kernel_vsyscall ()
#1 0xf75b0e20 in __libc_signal_restore_set (set=0xffffd220) at ../sysdeps/unix/sysv/linux/internal-signals.h:84
#2 __GI_raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:48
#3 0xf75b2007 in __GI_abort () at abort.c:79
#4 0xf75f541c in __libc_message (action=do_abort, fmt=<optimized out>) at ../sysdeps/posix/libc_fatal.c:181
#5 0xf75fcecd in malloc_printerr (str=str@entry=0xf771f23c "double free or corruption (out)") at malloc.c:5336
#6 0xf75ff383 in _int_free (av=0xf77797c0 <main_arena>, p=0x8212228 <vtable for __cxxabiv1::__vmi_class_type_info+36>, have_lock=<optimized out>) at malloc.c:4264
#7 0xf780586a in operator delete(void*) () from /usr/lib/libstdc++.so.6
#8 0xf7b5cdd1 in deallocate (this=<optimized out>, __p=<optimized out>) at /usr/include/c++/6.4.0/ext/new_allocator.h:110
#9 _M_destroy (__a=<synthetic pointer>, this=<optimized out>) at /usr/include/c++/6.4.0/bits/basic_string.tcc:889
#10 _M_dispose (__a=<synthetic pointer>, this=<optimized out>) at /usr/include/c++/6.4.0/bits/basic_string.h:2780
#11 std::string::reserve (this=0x821326c <SourceDownloadOptions::_defaultDirectory>, __res=33) at /usr/include/c++/6.4.0/bits/basic_string.tcc:951
#12 0xf7dc9755 in zypp::filesystem::Pathname::_assign (this=0x821326c <SourceDownloadOptions::_defaultDirectory>, name_r="/var/cache/zypper/source-download")
at /usr/src/debug/libzypp-17.3.1-1.3.10.i386/zypp/Pathname.cc:37
#13 0x080796c5 in Pathname (name_r=0x81d6b60 "/var/cache/zypper/source-download", this=0x821326c <SourceDownloadOptions::_defaultDirectory>) at /usr/include/zypp/Pathname.h:56
#14 __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535)
at /usr/src/debug/zypper-1.11.22+master.20180625103952.3.g3375f81-1.2.15.i386/src/source-download.cc:26
#15 _GLOBAL__sub_I__ZN21SourceDownloadOptions17_defaultDirectoryE () at /usr/src/debug/zypper-1.11.22+master.20180625103952.3.g3375f81-1.2.15.i386/src/source-download.cc:484
#16 0x081bb81b in __libc_csu_init ()
#17 0xf7592464 in __libc_start_main (main=0x8077d20 <main(int, char**)>, argc=2, argv=0xffffd744, init=0x81bb7d0 <__libc_csu_init>, fini=0x81bb830 <__libc_csu_fini>,
rtld_fini=0xf7fe5430 <_dl_fini>, stack_end=0xffffd73c) at ../csu/libc-start.c:264
#18 0x08079d21 in _start ()
The cmake module for Zypp currently gets installed to
/usr/share/cmake/Modules/FindZypp.cmake
However, this breaks compliancy with cmake's packaging howto [1]. Package modules are not supposed to be installed into /usr/share/cmake[-]/.
The correct installation path and filename is:
/usr/lib/cmake/Zypp/ZyppConfig.cmake
Also the ZyppCommon.cmake file should be stored in that very same folder.
Greets,
Mike
Updated 2018-05-28: Corrected the installation path.
Line 700 in 2513a02
If YaST changes the /mnt (e.g. user goes back and selects/mounts a different partition for upgrade) then the first read values stay unchanged.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.