opensuse / libzypp Goto Github PK

View Code? Open in Web Editor NEW

114.0 19.0 79.0 280.83 MB

ZYpp Package Management library

Home Page: http://doc.opensuse.org/projects/libzypp/HEAD/

License: Other

CMake 1.77% C++ 97.65% Python 0.01% Shell 0.17% Max 0.14% C 0.22% JavaScript 0.02% Dockerfile 0.02%

hacktoberfest

libzypp's People

Contributors

Stargazers

Watchers

libzypp's Issues

Downloader_test fails on non-x86 architectures

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?

Is here any code examples?

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!

Provide cmake OPTION to enable autodoc builds when doing "make all"

Hi,

it would be nice to have a cmake OPTION that enables building doc/autodoc/ when doing "make all".

Mike

Install FindZypp.cmake -> /usr/<lib>/cmake/LibZypp/LibZyppConfig.cmake

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.

Undefined order of calling dtors may cause segfault

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().

QUESTION: Is there a convenient API for upgrading to a higher Leap version?

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

failure to refresh repositories with GnuPG 2.1.23

zypper fails to refresh repositories with GnuPG 2.1.23 (only). This is new behavior with 2.1.23.

Combination tested:

openSUSE Leap 42.3
security:privacy/openSUSE_Leap_42.3
gpg2-2.1.23 from 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.

BUILD, ERROR: "xsltproc" returned non-zero exit status 5

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.

Is libzypp build possible using make -jX with X>1
Seems documentation build phase make external access (vhost.sourceforge.net, docbook.sourceforge.net, etc..), is a build Cmake option available, NOT to use external sites?
(using only local resources)
3)Our cmake build options include
-DCMAKE_BUILD_TYPE=Release
-DENABLE_BUILD_DOCS=OFF
-DENABLE_BUILD_TRANS=OFF
-DENABLE_BUILD_TESTS=OFF
-DENABLE_USE_THREADS=ON
-DDISABLE_AUTODOCS=ON

according to me, with such option, docs should NOT be build, why xsltproc, still be used and
internet server probed?

DigestReport does not provide repository; impossible to fix YaST2 bug until it does

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.

Do not forbid rpm to handle %posttrans scriptlets

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.

zypp/Digest.cc: DEPRECATEDIN_1_1_0(void OPENSSL_config(const char *config_name))

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

cannot ignore requires from systemCheck

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

cannot build with gcc 4.5.3

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?

stderr can be a macro

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.

Many libzypp unit test failures on Fedora

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.

libzypp assumes rpmdb is in Berkeley DB format (rh#1766128)

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 in zypp/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.

Please make the include dir path configurable

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

FTBFS for mipsel

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)

FTBFS (possibly because of cpp-8)

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

Confused when a package is installed in x86_64 and i686 on Fedora

Zypper on Fedora stumbles when a package is installed in x86_64 and i686 versions. Instead of installing both updates, it tries to replace the x86_64 version with the i686 version.

See this screenshot:

The upper part is "zypper dist-upgrade", the lower part is "dnf distro-sync".

needreboot file and needreboot.d are in the wrong place

This configuration files are in the wrong place: /var/lib/zypp instead of /etc/zypp. Please change them to the correct location.

reserved identifier violation

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?

Fixing the signature check for installation sources

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.

The function call “context.repoInfo().asUserString()” provides an empty string.
The item “repoInfo” is received by the variable “info” of the constructor for the class “Downloader”. Where is this object created?

Fix several typos in output messages (and comments)

The Debian lintian system discovered several typos in the built library, thus in upstream code.

http://anonscm.debian.org/cgit/collab-maint/libzypp.git/tree/debian/patches/1003_fix-typos-in-output-messages.patch

Add %bcond_without mediabackend_tests to avoid nginx/FastCGI BuildRequires...

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

Is it possible to abort a zypper command with a Python hook ?

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

run fail on glibc-2.28

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

Binary incompatible change when using libsolv-0.7

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

https://bugzilla.opensuse.org/show_bug.cgi?id=1115469

Compilation error reported by GCC7

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>(); }

FTBFS against GCC 5 on Debian

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.

build/doc/autodoc/libzypp.doxytag missing with CMake 3.14.0

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

Please provide man pages for zypp-NameReqPrv and zypp-CheckAccessDeleted

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

CacheMap must track the device id not the mount path

libzypp/zypp/ZConfig.cc

Line 700 in 2513a02

typedef std::map<Pathname,MultiversionSpec> SpecMap;

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.

Misleading indentation on couple of places

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

always call pool_setdisttype (libsolv)

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

[1] openSUSE/libsolv@86a8d25

libzypp fails to build with RPM 4.14 Alpha

/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 ); }
                                   ^~~~~~

Make Helix repo support optional

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

Provide cmake OPTION to enable translation file builds when doing "make all"

Hi,

it would be good to have a cmake OPTION that includes the po/ subdirectory in "make all" builds.

Thanks,
Mike

libzypp tests failing with `-Wp,-D_GLIBCXX_ASSERTIONS` compiler flag

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.

Provide cmake OPTION to enable test builds when doing "make all"

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.

Add zchunk support

Testrepo supporting zchunk should be here. The repomd.xml there contains the header-size and header-checksum of the .zck files.

17.12.0 -> 17.14.0, Build failing with boost-1.70

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

feature request: vendor provided repo dir

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.

Feature request: flag for submodules in MountPoint

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. :-)

Package download speed, any way to improve it?

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

Add estimated time of arrival indication to zypper

Ancient bug https://bugzilla.opensuse.org/show_bug.cgi?id=463318 was in danger of being autoclosed; reopening it here.

build failed with boost 1.56

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

create RepoMediaAccess::async_provideFile and CommitPackageCache::async_get

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.

set CURL_HTTP_VERSION_2TLS with curl >= 7.47.0

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

Fixup! Give posttrans script a parameter of 0

This is wrong according to rpm-software-management/rpm@ab069ec

Originally posted by @Jellyfrog in #168 (comment)

opensuse / libzypp Goto Github PK

libzypp's People

Contributors

Stargazers

Watchers

Forkers

libzypp's Issues

Recommend Projects

Recommend Topics

Recommend Org