mageslayer / paludis-gentoo-patches Goto Github PK

Unofficial Gentoo patches for Paludis package manager

License: GNU General Public License v2.0

CMake 1.80% Shell 10.23% C++ 85.17% M4 0.15% Python 0.79% Ruby 1.21% Vim Script 0.25% C 0.22% Hack 0.15% Dockerfile 0.03%

paludis-gentoo-patches's People

Contributors

Stargazers

Watchers

Forkers

l29ah ionic prototype99 konstantindjairo negril bqv abatyiev

paludis-gentoo-patches's Issues

symbols={split,compress} breaks media-sound/teamspeak-client

paludis splits and compresses debug symbols using objcopy, such as:

objcopy --only-keep-debug [--compress-debug-sections] ts3client_linux_amd64 /path/to/debugging/symbols/ts3client_linux_amd64
objcopy --add-gnu-debuglink=/path/to/debugging/symbols/ts3client_linux_amd64 ts3client_linux_amd64

This seems to break some binaries, such as the binary shipped in media-sound/teamspeak-client.

For this binary, after running both commands leads to such breakage:

./ts3client_linux_amd64: ./ts3client_linux_amd64: no version information available (required by ./ts3client_linux_amd64)
./ts3client_linux_amd64: ./ts3client_linux_amd64: no version information available (required by ./ts3client_linux_amd64)
./ts3client_linux_amd64: ./ts3client_linux_amd64: no version information available (required by ./ts3client_linux_amd64)
./ts3client_linux_amd64: ./ts3client_linux_amd64: no version information available (required by ./ts3client_linux_amd64)
./ts3client_linux_amd64: ./ts3client_linux_amd64: no version information available (required by ./ts3client_linux_amd64)
./ts3client_linux_amd64: ./ts3client_linux_amd64: no version information available (required by ./ts3client_linux_amd64)
./ts3client_linux_amd64: ./ts3client_linux_amd64: no version information available (required by ./ts3client_linux_amd64)
./ts3client_linux_amd64: ./ts3client_linux_amd64: no version information available (required by ./ts3client_linux_amd64)
./ts3client_linux_amd64: ./ts3client_linux_amd64: no version information available (required by ./ts3client_linux_amd64)
./ts3client_linux_amd64: ./ts3client_linux_amd64: no version information available (required by ./ts3client_linux_amd64)
./ts3client_linux_amd64: ./ts3client_linux_amd64: no version information available (required by ./ts3client_linux_amd64)
./ts3client_linux_amd64: ./ts3client_linux_amd64: no version information available (required by ./ts3client_linux_amd64)
./ts3client_linux_amd64: ./ts3client_linux_amd64: no version information available (required by ./ts3client_linux_amd64)
./ts3client_linux_amd64: ./ts3client_linux_amd64: no version information available (required by ./ts3client_linux_amd64)
./ts3client_linux_amd64: ./ts3client_linux_amd64: no version information available (required by ./ts3client_linux_amd64)
./ts3client_linux_amd64: ./ts3client_linux_amd64: no version information available (required by ./ts3client_linux_amd64)
./ts3client_linux_amd64: ./ts3client_linux_amd64: no version information available (required by ./ts3client_linux_amd64)
./ts3client_linux_amd64: ./ts3client_linux_amd64: no version information available (required by ./ts3client_linux_amd64)
./ts3client_linux_amd64: ./ts3client_linux_amd64: no version information available (required by ./ts3client_linux_amd64)
./ts3client_linux_amd64: ./ts3client_linux_amd64: no version information available (required by ./ts3client_linux_amd64)
./ts3client_linux_amd64: ./ts3client_linux_amd64: no version information available (required by ./ts3client_linux_amd64)
./ts3client_linux_amd64: ./ts3client_linux_amd64: no version information available (required by ./ts3client_linux_amd64)
./ts3client_linux_amd64: ./ts3client_linux_amd64: no version information available (required by ./ts3client_linux_amd64)
./ts3client_linux_amd64: symbol lookup error: ./ts3client_linux_amd64: undefined symbol: , version

Also, ldd produces a pretty strange ouput:

./ts3client_linux_amd64: ./ts3client_linux_amd64: no version information available (required by ./ts3client_linux_amd64)
./ts3client_linux_amd64: ./ts3client_linux_amd64: no version information available (required by ./ts3client_linux_amd64)
./ts3client_linux_amd64: ./ts3client_linux_amd64: no version information available (required by ./ts3client_linux_amd64)
./ts3client_linux_amd64: ./ts3client_linux_amd64: no version information available (required by ./ts3client_linux_amd64)
./ts3client_linux_amd64: ./ts3client_linux_amd64: no version information available (required by ./ts3client_linux_amd64)
./ts3client_linux_amd64: ./ts3client_linux_amd64: no version information available (required by ./ts3client_linux_amd64)
./ts3client_linux_amd64: ./ts3client_linux_amd64: no version information available (required by ./ts3client_linux_amd64)
./ts3client_linux_amd64: ./ts3client_linux_amd64: no version information available (required by ./ts3client_linux_amd64)
./ts3client_linux_amd64: ./ts3client_linux_amd64: no version information available (required by ./ts3client_linux_amd64)
./ts3client_linux_amd64: ./ts3client_linux_amd64: no version information available (required by ./ts3client_linux_amd64)
./ts3client_linux_amd64: ./ts3client_linux_amd64: no version information available (required by ./ts3client_linux_amd64)
./ts3client_linux_amd64: ./ts3client_linux_amd64: no version information available (required by ./ts3client_linux_amd64)
./ts3client_linux_amd64: ./ts3client_linux_amd64: no version information available (required by ./ts3client_linux_amd64)
./ts3client_linux_amd64: ./ts3client_linux_amd64: no version information available (required by ./ts3client_linux_amd64)
./ts3client_linux_amd64: ./ts3client_linux_amd64: no version information available (required by ./ts3client_linux_amd64)
./ts3client_linux_amd64: ./ts3client_linux_amd64: no version information available (required by ./ts3client_linux_amd64)
./ts3client_linux_amd64: ./ts3client_linux_amd64: no version information available (required by ./ts3client_linux_amd64)
./ts3client_linux_amd64: ./ts3client_linux_amd64: no version information available (required by ./ts3client_linux_amd64)
./ts3client_linux_amd64: ./ts3client_linux_amd64: no version information available (required by ./ts3client_linux_amd64)
./ts3client_linux_amd64: ./ts3client_linux_amd64: no version information available (required by ./ts3client_linux_amd64)
./ts3client_linux_amd64: ./ts3client_linux_amd64: no version information available (required by ./ts3client_linux_amd64)
./ts3client_linux_amd64: ./ts3client_linux_amd64: no version information available (required by ./ts3client_linux_amd64)
./ts3client_linux_amd64: ./ts3client_linux_amd64: no version information available (required by ./ts3client_linux_amd64)
	linux-vdso.so.1 (0x00007ffd899ce000)

I remember this working in the past, so something must have changed.

Crucially, not the --only-keep-debug step (i.e., the splitting and compression part) is breaking the binary, but linking the debug symbols file to the actual binary (for use by debuggers).

I don't know what causes this exactly. Since I remember it to work, my initial suspicion was that the version of binutils changed, triggering this behavior.

However, I reproduced the issue successfully with an older binutils version and while newer ones seem to issue more diagnostics warnings, they don't seem to change the outcome.

The base line could be a more recent glibc version here - i.e., that such a modified binary worked with older glibc (and GNU ld) versions, but now fails on more recent ones like 2.32. I cannot easily downgrade glibc on my ~amd64 machine, but I still have an amd64 machine with an older glibc version that I can use to test.

Edit: this is a problem that only shows up with paludis. Portage doesn't break the binary even with FEATURES="compressdebug splitdebug nostrip" (though, frankly, I'd have to debug it to figure out if it's even trying to split the symbols from these prebuilt binary files in the first case.)

genkernel fork to support paludis?

Looks like recent genkernel no longer works separately from portage.
It requires modules rebuild made for portage.

Old genkernel-3.4.49.2 still works though.

Add Ionic as a maintainer?

Hi @MageSlayer

Since this has been quiet some time, maybe it's worth adding @Ionic as a maintainer so the project keeps moving? At first glance it seems dead, at this point, but those PRs are just waiting, and the eapi8 branch is close

paludis will not build with boost-1.78

ake[2]: *** No rule to make target '/usr/lib64/libboost_python39.so.1.78.0', needed by 'python/libpaludispython_3.0.so.300.0.0'. Stop.

Looks like compatible licensed implementation is a reference one.
See https://github.com/BLAKE2/BLAKE2

See "$ grep -R WHIRLPOOL *" for inspiration

sys-devel/gcc:8.4.0 fails to build with sys-devel/gcc:9.3.0 (other combinations unknown)

I'm unable to build sys-devel/gcc-8.4.0-r1 with the system compiler set to sys-devel/gcc-9.3.0-r2.

It actually completes src_compile just fine, but then tries to rebuild a few things in src_install (which is also true with portage) and fails:

make[2]: Entering directory '/var/tmp/paludis/sys-devel-gcc-8.4.0-r1/work/build/libcc1'
/bin/bash ./libtool --tag=CXX   --mode=compile x86_64-pc-linux-gnu-g++ -std=gnu++98 -DHAVE_CONFIG_H -I. -I/var/tmp/paludis/sys-devel-gcc-8.4.0-r1/work/gcc-8.4.0/libcc1  -I /var/tmp/paludis/sys-devel-gcc-8.4.0-r1/work/gcc-8.4.0/libcc1/../include -I /var/tmp/paludis/sys-devel-gcc-8.4.0-r1/work/gcc-8.4.0/libcc1/../libgcc -I ../gcc -I/var/tmp/paludis/sys-devel-gcc-8.4.0-r1/work/gcc-8.4.0/libcc1/../gcc    -W -Wall  -fvisibility=hidden -march=native -mtune=native -Wall -pipe -g3 -ggdb3 -gdwarf-4 -fno-omit-frame-pointer -O2 -MT findcomp.lo -MD -MP -MF .deps/findcomp.Tpo -c -o findcomp.lo /var/tmp/paludis/sys-devel-gcc-8.4.0-r1/work/gcc-8.4.0/libcc1/findcomp.cc
libtool: compile:  x86_64-pc-linux-gnu-g++ -std=gnu++98 -DHAVE_CONFIG_H -I. -I/var/tmp/paludis/sys-devel-gcc-8.4.0-r1/work/gcc-8.4.0/libcc1 -I /var/tmp/paludis/sys-devel-gcc-8.4.0-r1/work/gcc-8.4.0/libcc1/../include -I /var/tmp/paludis/sys-devel-gcc-8.4.0-r1/work/gcc-8.4.0/libcc1/../libgcc -I ../gcc -I/var/tmp/paludis/sys-devel-gcc-8.4.0-r1/work/gcc-8.4.0/libcc1/../gcc -W -Wall -fvisibility=hidden -march=native -mtune=native -Wall -pipe -g3 -ggdb3 -gdwarf-4 -fno-omit-frame-pointer -O2 -MT findcomp.lo -MD -MP -MF .deps/findcomp.Tpo -c /var/tmp/paludis/sys-devel-gcc-8.4.0-r1/work/gcc-8.4.0/libcc1/findcomp.cc  -fPIC -DPIC -o .libs/findcomp.o
x86_64-pc-linux-gnu-g++: /var/tmp/paludis/sys-devel-gcc-8.4.0-r1/work/build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by x86_64-pc-linux-gnu-g++)

I've ruled out the usual culprits, like binutils plugins, gold and LTO (I personally use neither).

The same build succeeds (same USE flags, same system compiler, same C(XX)FLAGS and LDFLAGS) just fine with portage, so I guess that something within paludis must trigger the issue.

Nothing in the toolchain eclass does LD_PRELOAD or LD_LIBRARY_PATH magic, as far as I can tell, so I have no idea why this older libstdc++.so would be loaded to be used with the system compiler when building this file.

More debugging is necessary here, but I currently don't have the time for that. Writing this up as a bug report for future reference.

Wildcard package spec support

When trying to use cave on my system, which has extensive configs, i see errors like:

$ cave resolve -x paludis                                                                                                                                                                                   
cave@1674740539: [WARNING portage_environment.dodgy] Use of Portage configuration files will lead to sub-optimal performance and loss of functionality. Full support for Portage configuration formats is not guarant
eed; issues should be reported via trac.

Error:
  * In program cave resolve -x paludis:
  * When making environment from specification '':
  * When creating PortageEnvironment using config root '':
  * When loading '/etc/portage/package.accept_keywords':
  * When loading '/etc/portage/package.accept_keywords/overlay':
  * When parsing user package dep spec '*/*::qt':
  * When parsing generic package dep spec '*/*::qt':
  * Wildcard '*' not allowed (paludis::PackageDepSpecError)

I would remove wildcards from my config, but that would be most of my config!

How hard would it be to add support for these?

unsymlink-lib with paludis based systems

Gentoo is moving to profiles 17.1 which required lib and lib64 is be real directories and to eliminate the lib symlink to lib64 and lib32. The unsymlink-lib program does not work properly on paludis based Gentoo systems. The issue appears to be in vardb, where paludis appear to have recorded the physical file location instead or the logical file locations according to Gentoo. Any idea of what to do?

Paludis cannot handle /etc/portage/profile/package.use.force been a directory

  * In program cave resolve -c world:
  * When adding targets from commandline:
  * When parsing user package dep spec 'world':
  * When parsing generic package dep spec 'world':
  * When loading profiles '/var/db/repos/gentoo/profiles/default/linux/amd64/17.1' '/etc/portage/profile' for repository 'gentoo':
  * When using directory '/etc/portage/profile':
  * When adding profile directory '/etc/portage/profile:
  * When loading specised use file '/etc/portage/profile/package.use.force:
  * In file '/etc/portage/profile/package.use.force': Error reading file: 'Error reading from fd 3: Is a directory' (paludis::SafeIFStreamError) (paludis::ConfigFileError)```

The directory is empty in this profile though, so removing this directory helps.

new llvm.org eclass breaks unpack in paludis on llvm related packages

this is error when running cave resolve llvm -1zx:

Unpacking from llvmorg-12.0.0.tar.gz ... [ ok ]

Unpacking llvm-12.0.0-manpages.tar.bz2 to /var/tmp/paludis/sys-devel-llvm-12.0.0/work
tar jxf /usr/portage/distfiles/llvm-12.0.0-manpages.tar.bz2 --no-same-owner
Unpacking llvm-gentoo-patchset-12.0.0-1.tar.xz to /var/tmp/paludis/sys-devel-llvm-12.0.0/work
xz -dc /usr/portage/distfiles/llvm-gentoo-patchset-12.0.0-1.tar.xz | strip_tar_corruption | tar xf - --no-same-owner

Error:

In program cave perform install --hooks --managed-output --output-exclusivity with-others =sys-devel/llvm-12.0.0:12::gentoo --destination installed --replacing =sys-devel/llvm-12.0.0:12::installed --x-of-y 1 of 1:
When installing 'sys-devel/llvm-12.0.0:12::gentoo' replacing { 'sys-devel/llvm-12.0.0:12::installed' }:
When running an ebuild command on 'sys-devel/llvm-12.0.0:12::gentoo':
Install failed for 'sys-devel/llvm-12.0.0:12::gentoo' (paludis::ActionFailedError)

!!! ERROR in sys-devel/llvm-12.0.0::gentoo:
!!! In llvm.org_src_unpack at line 3706
!!! 0|0

!!! Call stack:
!!! * llvm.org_src_unpack (/var/tmp/paludis/sys-devel-llvm-12.0.0/temp/loadsaveenv:3706)
!!! * src_unpack (/var/tmp/paludis/sys-devel-llvm-12.0.0/temp/loadsaveenv:5309)
!!! * ebuild_f_unpack (/usr/libexec/paludis/2/src_unpack.bash:47)
!!! * ebuild_main (/usr/libexec/paludis/ebuild.bash:675)
!!! * main (/usr/libexec/paludis/ebuild.bash:698)

diefunc: making ebuild PID 1639911 exit with error
die trap: exiting with error.

Unpack fails on the following code in loadsaveenv in temp:
if [[ -n ${LLVM_PATCHSET} ]]; then
local IFS='|';
grep -E -r -L "^Gentoo-Component:.(${components[]})" "${WORKDIR}/llvm-gentoo-patchset-${LLVM_PATCHSET}" | xargs rm;
_paludis_pipestatus="${PIPESTATUS[*]}";
[[ -z "${_paludis_pipestatus//[ 0]/}" ]] || diefunc "${FUNCNAME:-$0}" "$LINENO";
fi

EAPI=7 support

Corresponding Gentoo bug https://bugs.gentoo.org/655976

Reorganizing branches

Pretext

From talking with @Ionic, we came to the conclusion that we would like to clean up the branches to ease rebasing against exherbo master as upstream.

To have a starting point I wrote down my ideas so we can collect thoughts as we didn't reach a conclusion on details like names yet.

Concept

create a new branch at 0c63784 called exherbo/master
pull master from exherbo
use the existing patches we collected and rebase on top of exherbo/master similar to what I have done in negril/gentoo/feature/eapi7, negril/gentoo/feature/eapi7-test-base, negril/gentoo/feature/eapi7-test-updates and negril/gentoo/feature/eapi8
use those development branches as basis for a "live" branch called gentoo/testing where we collect those for end user usage. This might see frequent rebasing and/or merging, hence breakage of the git history, which we are willing to accept as we have to make frequent changes in the intermediate future trying to fix a lot of things.
send finalized changes to exherbo upstream

If anyone has thoughts or questions please share them. We are unsure at the moment how many people would be affected.

Note

There is a helper commit in negril/gentoo/wip/bugfix/limit_ci to avoid unneeded runs of the exherbo ci that we need to remove at some point.

Build failure w/ `USE=python`

The upstream bug is here: http://paludis.exherbo.org/trac/ticket/1369

Phase overrides in recursive inherit calls applied in wrong order

media-libs/phonon-vlc currently fails to build with paludis:

Checking 'phonon-backend-vlc-0.11.3.tar.xz'... ok                                                                                                                                 
>>> Running ebuild phase killold as root:root...                                                                                                                                  
>>> Starting builtin_killold                                                                                                                                                      
>>> Done builtin_killold                                                                                                                                                          
>>> Completed ebuild phase killold                                                       
>>> Running ebuild phases init saveenv as paludisbuild:paludisbuild...                                                                                                            >>> Starting builtin_init
>>> Done builtin_init                                                                                                                                                             
>>> Starting builtin_saveenv                                                                                                                                                      
>>> Done builtin_saveenv                                                                                                                                                          
>>> Completed ebuild phases init saveenv                                                                                                                                          
>>> Running ebuild phases loadenv setup saveenv as root:root...                                                                                                                   
>>> Starting builtin_loadenv                                                                                                                                                      
>>> Done builtin_loadenv                                                                                                                                                          
>>> Starting pkg_setup                                                                                                                                                            
>>> Done pkg_setup                                                                                                                                                                
>>> Starting builtin_saveenv                                                                                                                                                      
>>> Done builtin_saveenv                                                                                                                                                          
>>> Completed ebuild phases loadenv setup saveenv                                                                                                                                 
>>> Running ebuild phases loadenv unpack saveenv as paludisbuild:paludisbuild...                                                                                                  
>>> Starting builtin_loadenv                                                             
>>> Done builtin_loadenv                                                                                                                                                          >>> Starting src_unpack                                                                                                                                                           
>>> Unpacking phonon-backend-vlc-0.11.3.tar.xz to /var/tmp/paludis/media-libs-phonon-vlc-0.11.3-r1/work                                                                           
xz -dc /usr/portage/distfiles/phonon-backend-vlc-0.11.3.tar.xz | strip_tar_corruption | tar xf - --no-same-owner                                                                  
>>> Done src_unpack                                                                                                                                                               
>>> Starting builtin_saveenv                                                             
>>> Done builtin_saveenv                                                                                                                                                          
>>> Completed ebuild phases loadenv unpack saveenv                                       
>>> Running ebuild phases loadenv prepare saveenv as paludisbuild:paludisbuild...
>>> Starting builtin_loadenv                                                                                                                                                      
>>> Done builtin_loadenv                                                                                                                                                          
>>> Starting src_prepare                                                                 
>>> Done src_prepare                                                                     
>>> Starting builtin_saveenv                                                                                                                                                      
>>> Done builtin_saveenv                                                                                                                                                          
>>> Completed ebuild phases loadenv prepare saveenv                                                                                                                               
>>> Running ebuild phases loadenv configure saveenv as paludisbuild:paludisbuild...      
>>> Starting builtin_loadenv                                                             
                                                                                         
Error:                                                                                                                                                                            
  * In program cave perform install --hooks --managed-output --output-exclusivity with-others =media-libs/phonon-vlc-0.11.3-r1:0::gentoo --destination installed --replacing =medi
a-libs/phonon-vlc-0.11.2:0::installed --x-of-y 15 of 19:                                                                                                                          
  * When installing 'media-libs/phonon-vlc-0.11.3-r1:0::gentoo' replacing { 'media-libs/phonon-vlc-0.11.2:0::installed' }:                                                        
  * When running an ebuild command on 'media-libs/phonon-vlc-0.11.3-r1:0::gentoo':                                                                                                
  * Install failed for 'media-libs/phonon-vlc-0.11.3-r1:0::gentoo' (paludis::ActionFailedError)                                                                                   
                                                                                                                                                                                  
>>> Done builtin_loadenv                                                                                                                                                          
>>> Starting src_configure                                                                                                                                                        
                                                                                                                                                                                  
!!! ERROR in media-libs/phonon-vlc-0.11.3-r1::gentoo:                                                                                                                             
!!! In cmake_src_configure at line 1505                                                                                                                                           
!!! FATAL: cmake_src_prepare has not been run                                                                                                                                     
                                                                                                                                                                                  
!!! Call stack:                                                                                                                                                                   
!!!    * cmake_src_configure (/var/tmp/paludis/media-libs-phonon-vlc-0.11.3-r1/temp/loadsaveenv:1505)                                                                             
!!!    * src_configure (/var/tmp/paludis/media-libs-phonon-vlc-0.11.3-r1/temp/loadsaveenv:4092)                                                                                   
!!!    * ebuild_f_configure (/usr/libexec/paludis/2/src_configure.bash:54)               
!!!    * ebuild_main (/usr/libexec/paludis/ebuild.bash:675)                                                                                                                       !!!    * main (/usr/libexec/paludis/ebuild.bash:698)                                                                                                                              
                                                                                                                                                                                  
diefunc: making ebuild PID 16812 exit with error                                                                                                                                  
die trap: exiting with error.                                                                                                                                                     
                                                                                         
Failed install to / for media-libs/phonon-vlc-0.11.3-r1:0::gentoo replacing 0.11.2:0::installed

The error message is clear, but the same ebuild builds successfully with portage.

Looking at the loadsaveenv file, it's clear what happens:

src_prepare () 
{ 
    xdg_src_prepare "$@"
}

portage's `environment file looks like this:

src_prepare () 
{ 
    ecm_src_prepare "$@"
}

Looking at ecm.eclass, we see that it's inheriting xdg.eclass, so paludis's behavior looks correct.

However, portage behaves differently in such a situation, due to this change from 2009(!): gentoo/portage@06d4433

This changed the phase override behavior in a subtle way from stack-down to stack-up. paludis still uses the stack-up mechanism.

Unfortunately, it's undocumented in which order EXPORT_FUNCTIONS and recursive inherit calls are processed. PMS doesn't specify it.

Hence, the only authority seems to be portage's implementation, which we'll have to match.

Change in gentoo tree breaking paludis

Starting today I get this when updating:

Deciding: 6 restarts, 22112 steps, 1 metadata (1 gentoo)

Error:

In program cave resolve --resume-file /tmp/resume_file -c -km -Km -Cs -P / -Si -Rn installed-packages:
When resolving and adding dependencies recursively:
When adding dependencies for 'sys-apps/paludis:0::(install_to_slash)' with 'sys-apps/paludis-9999:0::paludis-gentoo-overlay':
When handling dependency '>=dev-libs/boost-1.41.0:=[python,%PYTHON_USEDEP-HAS-BEEN-REMOVED%]':
When finding slots for '>=dev-libs/boost-1.41.0:=[python,%PYTHON_USEDEP-HAS-BEEN-REMOVED%]':
When determining resolvents for '>=dev-libs/boost-1.41.0:=[python,%PYTHON_USEDEP-HAS-BEEN-REMOVED%]':
When finding best version in each slot from packages matching >=dev-libs/boost-1.41.0:=[python,%PYTHON_USEDEP-HAS-BEEN-REMOVED%] with filter all matches filtered through installed at root /:
Name '%PYTHON_USEDEP-HAS-BEEN-REMOVED%' is not a valid choice name with prefix (paludis::ChoiceNameWithPrefixError)

paludis will not build with boost-1.70.0

it fails during configure

Executable stripping broken with file-5.33+

Paludis bug http://paludis.exherbo.org/trac/ticket/1363
Corresponding Gentoo bug https://bugs.gentoo.org/658270

Bash associative arrays (i.e., hashes) break paludis's loadsaveenv

Updating net-misc/geoipupdate, I ran into this issue:

/var/tmp/paludis/net-misc-geoipupdate-4.3.0/temp/loadsaveenv: line 458: github.com%2Fstretchr%2Fobjx%2F@v%2Fv0.1.0.zip: syntax error: invalid arithmetic operator (error token is ".com%2Fstretchr%2Fobjx%2F@v%2Fv0.1.0.zip")

and indeed, the file contains this:

_GOMODULE_GOSUM_REVERSE_MAP=([github.com%2Fstretchr%2Fobjx%2F@v%2Fv0.1.0.zip]="github.com/stretchr/objx/@v/v0.1.0.zip" [github.com%2Fspf13%2Fpflag%2F@v%2Fv1.0.5.mod]="github.com/spf13/pflag/@v/v1.0.5.mod" [github.com%2Fpmezard%2Fgo-difflib%2F@v%2Fv1.0.0.mod]="github.com/pmezard/go-difflib/@v/v1.0.0.mod" [github.com%2Fstretchr%2Fobjx%2F@v%2Fv0.1.0.mod]="github.com/stretchr/objx/@v/v0.1.0.mod" [github.com%2Fdavecgh%2Fgo-spew%2F@v%2Fv1.1.1.mod]="github.com/davecgh/go-spew/@v/v1.1.1.mod" [github.com%2Fkr%2Fpretty%2F@v%2Fv0.2.0.zip]="github.com/kr/pretty/@v/v0.2.0.zip" [github.com%2Fpmezard%2Fgo-difflib%2F@v%2Fv1.0.0.zip]="github.com/pmezard/go-difflib/@v/v1.0.0.zip" [github.com%2Fdavecgh%2Fgo-spew%2F@v%2Fv1.1.0.mod]="github.com/davecgh/go-spew/@v/v1.1.0.mod" [gopkg.in%2Fcheck.v1%2F@v%2Fv0.0.0-20161208181325-20d25e280405.mod]="gopkg.in/check.v1/@v/v0.0.0-20161208181325-20d25e280405.mod" [gopkg.in%2Fcheck.v1%2F@v%2Fv1.0.0-20190902080502-41f04d3bba15.zip]="gopkg.in/check.v1/@v/v1.0.0-20190902080502-41f04d3bba15.zip" [github.com%2Fstretchr%2Ftestify%2F@v%2Fv1.5.0.zip]="github.com/stretchr/testify/@v/v1.5.0.zip" [gopkg.in%2Fyaml.v2%2F@v%2Fv2.2.7.mod]="gopkg.in/yaml.v2/@v/v2.2.7.mod" [github.com%2Fkr%2Fpretty%2F@v%2Fv0.2.0.mod]="github.com/kr/pretty/@v/v0.2.0.mod" [github.com%2Fgofrs%2Fflock%2F@v%2Fv0.7.1.mod]="github.com/gofrs/flock/@v/v0.7.1.mod" [github.com%2Fkr%2Ftext%2F@v%2Fv0.1.0.zip]="github.com/kr/text/@v/v0.1.0.zip" [github.com%2Fmaxmind%2Fgeoipupdate%2F@v%2Fv4.0.2+incompatible.zip]="github.com/maxmind/geoipupdate/@v/v4.0.2+incompatible.zip" [github.com%2Fgofrs%2Fflock%2F@v%2Fv0.7.1.zip]="github.com/gofrs/flock/@v/v0.7.1.zip" [github.com%2Fstretchr%2Ftestify%2F@v%2Fv1.4.0.mod]="github.com/stretchr/testify/@v/v1.4.0.mod" [github.com%2Fdavecgh%2Fgo-spew%2F@v%2Fv1.1.1.zip]="github.com/davecgh/go-spew/@v/v1.1.1.zip" [github.com%2Fpkg%2Ferrors%2F@v%2Fv0.9.0.mod]="github.com/pkg/errors/@v/v0.9.0.mod" [github.com%2Fkr%2Ftext%2F@v%2Fv0.1.0.mod]="github.com/kr/text/@v/v0.1.0.mod" [github.com%2Fstretchr%2Ftestify%2F@v%2Fv1.4.0.zip]="github.com/stretchr/testify/@v/v1.4.0.zip" [github.com%2Fpkg%2Ferrors%2F@v%2Fv0.9.1.zip]="github.com/pkg/errors/@v/v0.9.1.zip" [gopkg.in%2Fyaml.v2%2F@v%2Fv2.2.7.zip]="gopkg.in/yaml.v2/@v/v2.2.7.zip" [gopkg.in%2Fcheck.v1%2F@v%2Fv1.0.0-20190902080502-41f04d3bba15.mod]="gopkg.in/check.v1/@v/v1.0.0-20190902080502-41f04d3bba15.mod" [github.com%2Fstretchr%2Ftestify%2F@v%2Fv1.5.1.zip]="github.com/stretchr/testify/@v/v1.5.1.zip" [github.com%2Fstretchr%2Ftestify%2F@v%2Fv1.5.0.mod]="github.com/stretchr/testify/@v/v1.5.0.mod" [gopkg.in%2Fyaml.v2%2F@v%2Fv2.2.2.zip]="gopkg.in/yaml.v2/@v/v2.2.2.zip" [github.com%2Fstretchr%2Ftestify%2F@v%2Fv1.5.1.mod]="github.com/stretchr/testify/@v/v1.5.1.mod" [github.com%2Fkr%2Fpty%2F@v%2Fv1.1.1.mod]="github.com/kr/pty/@v/v1.1.1.mod" [gopkg.in%2Fyaml.v2%2F@v%2Fv2.2.2.mod]="gopkg.in/yaml.v2/@v/v2.2.2.mod" [github.com%2Fpkg%2Ferrors%2F@v%2Fv0.9.1.mod]="github.com/pkg/errors/@v/v0.9.1.mod" [github.com%2Fspf13%2Fpflag%2F@v%2Fv1.0.5.zip]="github.com/spf13/pflag/@v/v1.0.5.zip" [github.com%2Fpkg%2Ferrors%2F@v%2Fv0.9.0.zip]="github.com/pkg/errors/@v/v0.9.0.zip" )

This comes from the go-module eclass:

# @ECLASS-VARIABLE: _GOMODULE_GOSUM_REVERSE_MAP
# @DESCRIPTION:
# Mapping back from Gentoo distfile name to upstream distfile path.
# Associative array to avoid O(N*M) performance when populating the GOPROXY
# directory structure.
declare -A -g _GOMODULE_GOSUM_REVERSE_MAP

So far, luckily, go-module is the only location using associative arrays, so the breakage is still pretty contained.

It's still a showstopper and I'm not sure how to fix this.

The main issue is that paludis uses set to dump out all variables (in builtin_saveenv.bash for EAPI 0, builtin_saveenv.bash for exheres 0 and source_functions.bash), which works, but doesn't include extended attributes.

We should probably use declare -p instead to more correctly export the data.

I did run into some pretty big problem when doing so about three months ago, but I can't remember all specifics.

One issue was that the loadsaveenv file is loaded back in a shell function via source. declare and typeset typically make variables local to the function iff called in a function, so if we just load back the data returned by declare -p, everything will be gone once the function terminates.

To counter this, I mangled all declare calls to always include -g and insert the variables into global scope.

If I remember correctly, this created another set of problems. Mainly with read-only variables which can't be re-set. Filtering out read-only variables indefinitely would be a bad idea, though, for obvious reasons. One approach that works might be to filter out read-only variables if they are already set in global scope. Will have to test this some rainy day.

Gentoo overlay repo

Create a separate overlay repo for user's to try this fork.

tensorflow-1.13.1 ebuild causing dependency issues

The latest tensorflow-1.13.1 ebuild causes the following illogical blockages on cudnn.
cudnn-7.4.2.24 as well as nvidia-cuda-toolkit-10.0.130 are installed. This combination should be allowed by the tensorflow ebuild.

! dev-libs/cudnn
Reasons: target (installed-packages::installed), restarted because of sci-libs/tensorflow-1.13.1:0::installed, sci-libs/tensorflow-1.13.1:0::installed
Unsuitable candidates:
* dev-libs/cudnn-6.0:0::gentoo
Did not meet =dev-libs/cudnn-7.0*, use existing if same, installing to / from sci-libs/tensorflow-1.13.1:0::installed
Did not meet =dev-libs/cudnn-7.1*, use existing if same, installing to / from sci-libs/tensorflow-1.13.1:0::installed
Did not meet =dev-libs/cudnn-7.4*, use existing if same, installing to / from restarted because of sci-libs/tensorflow-1.13.1:0::installed (and 1 more)
* dev-libs/cudnn-7.0.5-r1:0::gentoo
Did not meet =dev-libs/cudnn-7.1*, use existing if same, installing to / from sci-libs/tensorflow-1.13.1:0::installed
Did not meet =dev-libs/cudnn-7.4*, use existing if same, installing to / from restarted because of sci-libs/tensorflow-1.13.1:0::installed (and 1 more)
* dev-libs/cudnn-7.1.4:0::gentoo
Did not meet =dev-libs/cudnn-7.0*, use existing if same, installing to / from sci-libs/tensorflow-1.13.1:0::installed
Did not meet =dev-libs/cudnn-7.4*, use existing if same, installing to / from restarted because of sci-libs/tensorflow-1.13.1:0::installed (and 1 more)
* dev-libs/cudnn-7.4.1.5:0::gentoo
Did not meet =dev-libs/cudnn-7.0*, use existing if same, installing to / from sci-libs/tensorflow-1.13.1:0::installed
Did not meet =dev-libs/cudnn-7.1*, use existing if same, installing to / from sci-libs/tensorflow-1.13.1:0::installed
* dev-libs/cudnn-7.4.2.24:0::gentoo
Did not meet =dev-libs/cudnn-7.0*, use existing if same, installing to / from sci-libs/tensorflow-1.13.1:0::installed
Did not meet =dev-libs/cudnn-7.1*, use existing if same, installing to / from sci-libs/tensorflow-1.13.1:0::installed
* dev-libs/cudnn-7.5.0.56:0::gentoo
Did not meet =dev-libs/cudnn-7.0*, use existing if same, installing to / from sci-libs/tensorflow-1.13.1:0::installed
Did not meet =dev-libs/cudnn-7.1*, use existing if same, installing to / from sci-libs/tensorflow-1.13.1:0::installed
Did not meet =dev-libs/cudnn-7.4*, use existing if same, installing to / from restarted because of sci-libs/tensorflow-1.13.1:0::installed (and 1 more)

Environment variables in ebuilds

I have been having problems with sys-libs/ncurses-5.9-r101:5 for a while now, but worked around it by simply skipping the installation. The relevant bug is actually ancient and fixed with portage. (Cf. #545532)

The fix for that particular bug relied on the CONFIG_SHELL environment variable in the ncurses ebuild. This seems to get lost during the call to econf.

A similar thing now happens with sci-libs/fftw-3.3.6_p2. Here pkg_setup sets the variable MULTIBUILD_VARIANTS, but somehow it gets lost and so the build fails with:

>>> Starting src_configure

!!! ERROR in sci-libs/fftw-3.3.6_p2::gentoo:
!!! In multibuild_foreach_variant at line 3427
!!! MULTIBUILD_VARIANTS need to be set

!!! Call stack:
!!! * multibuild_foreach_variant (/var/tmp/paludis/sci-libs-fftw-3.3.6_p2/temp/loadsaveenv:3427)
!!! * src_configure (/var/tmp/paludis/sci-libs-fftw-3.3.6_p2/temp/loadsaveenv:4556)
!!! * ebuild_f_configure (/usr/libexec/paludis/2/src_configure.bash:54)
!!! * ebuild_main (/usr/libexec/paludis/ebuild.bash:675)
!!! * main (/usr/libexec/paludis/ebuild.bash:698)

sys-libs/ncurses-5.9-r101:5 build fails

I have been having problems with sys-libs/ncurses-5.9-r101:5 for a while now, but worked around it by
simply skipping the installation. The relevant bug is actually ancient and fixed with portage. (Cf. #545532)
The fix for that particular bug relied on the CONFIG_SHELL environment variable in the ncurses ebuild.
This seems to get lost during the call to econf.

Originally created in #12

Command line arg --reinstall-dependents-of is not picked by bash completion

Currently "cave resolve" does not suggest --reinstall-dependents-of as possible completion.
To be fixed.

e_repository_TEST_6 takes almost twice as long as upstream

So, on my machine it used to be 50s and after rebasing on this code base I see it timing out with 90s.
I will might take a look why it is that at some point.
More to let you know, than real issue for me.

Recent GLSA support

Currently paludis emits following when using $ cave resolve --lazy security :

cave@1531747299: [WARNING e.package_dep_spec.slot_not_allowed] In thread ID '18226':
  ... In program cave resolve --lazy security:
  ... When adding targets from commandline:
  ... When adding set target 'security':
  ... When building security or insecurity package set:
  ... When parsing security advisory '/var/paludis/repositories/portage/metadata/glsa/glsa-201805-02.xml':
  ... When handling GLSA '201805-02' from '/var/paludis/repositories/portage/metadata/glsa/glsa-201805-02.xml':
  ... When parsing elike package dep spec 'dev-lang/python:2.7':
  ... When parsing generic package dep spec 'dev-lang/python:2.7':
  ... Slot dependencies not safe for use here

News 2.0 support

See http://paludis.exherbo.org/trac/ticket/1352 for details and preliminary patch.
Corresponding Gentoo bug https://bugs.gentoo.org/show_bug.cgi?id=658272

TODO:
Refactor using VersionSpec object instead of raw string.

Initial implementation made by torotil
d707421

new changes to /etc/portage/profile/make.profile break paludis

Hans de Graaff <[email protected]) (2019-07-17)

Temporary RUBY_TARGETS for bug 688976

RUBY_TARGETS="ruby24 -ruby25"

completely breaks paludis

2974 steps to decide cave resolve bash

on commit 3fa0653 of https://github.com/negril/paludis/commits/gentoo/build/ bash takes 2974 steps to decide

`laptopfadsjfadfadsf /etc/paludis # cave resolve bash
Done: 2974 steps, 1207 metadata (1207 gentoo)

These are the actions I will take, in order:

r app-shells/bash:0::gentoo 5.1_p16-r6 to ::installed replacing 5.1_p16-r6
-afs -bashlogger -examples -mem-scramble net nls -plugins (readline) -verify-sig build_options: symbols=split -dwarf_compress -optional_tests -trace work=tidyup
Reasons: target, app-admin/perl-cleaner-2.31:0::installed, sys-apps/portage-3.0.61-r1:0::installed, sys-kernel/dracut-060_pre20240104-r2:0::installed
10.01 MBytes to download

Total: 1 reinstalls, 10.01 MBytes to download

Executing pretend actions: 1 of 1

No unread news items found
laptopfadsjfadfadsf /etc/paludis # `

firefox-66-r1 fails to build

firefox-66.0-r1 will not compile with paludis. It compiles fine with portage. The failure comes at the start of the compile phase showing an autoconf issue. The real issue is that we are getting corruption in the PATH assignment is various config files. The source of the problem is loadsaveenv file in the temp directory which shows
PATH=$' \E[32;01m*\E[0m Will use LLVM slot 8!\n/usr/lib/llvm/8/bin:/var/tmp/paludis/www-client-firefox-66.0-r1/temp//python3.6/bin:/usr/libexec/paludis/utils/0:/usr/libexec/paludis/utils/1:/usr/libexec/paludis/utils/2:/usr/libexec/paludis/utils/3:/usr/libexec/paludis/utils/4:/usr/libexec/paludis/utils/5:/usr/libexec/paludis/utils/6:/usr/libexec/paludis/utils:/usr/bin:/usr/sbin:/bin:/sbin:/usr/lib/llvm/8/bin:/usr/lib/llvm/7/bin:/usr/lib/llvm/6/bin:/usr/lib/llvm/5/bin:/usr/lib/llvm/4/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/opt/vmware/bin:/opt/cuda/bin:/opt/cuda/libnvvp'

The \E[32;01m*\E[0m Will use LLVM slot 8!\n string should not be there and if manually removed before config phase the build completes.

doins -r fails on symbolic links with spaces in file name

Example reproducer: =media-libs/alsa-ucm-conf-1.2.6.3 (Note that this ebuild is EAPI=8, so it won't be readable unless using my patched paludis version for now - it can easily be downgraded to EAPI=7 since it does not use any new features.)

�[36m>>>�[0m Starting src_install
ln: failed to create symbolic link '/var/tmp/paludis/media-libs-alsa-ucm-conf-1.2.6.3/image/usr/share/alsa/ucm2/conf.d/simple-card/Librem 5 Devkit.conf' -> '': No such file or directory

!!! ERROR in media-libs/alsa-ucm-conf-1.2.6.3::gentoo:
!!! In /usr/libexec/paludis/utils/doins at line 91
!!! doins returned error 2

!!! Call stack:
!!!    * paludis_die_or_error_func (/usr/libexec/paludis/die_functions.bash:82)
!!!    * main (/usr/libexec/paludis/utils/doins:91)

diefunc: making ebuild PID 2033 exit with error
ln: failed to create symbolic link '/var/tmp/paludis/media-libs-alsa-ucm-conf-1.2.6.3/image/usr/share/alsa/ucm2/conf.d/tegra/ASUS Google Nexus 7 ALC5642.conf' -> '': No such file or directory

!!! ERROR in media-libs/alsa-ucm-conf-1.2.6.3::gentoo:
!!! In /usr/libexec/paludis/utils/doins at line 91
!!! doins returned error 2

!!! Call stack:
!!!    * paludis_die_or_error_func (/usr/libexec/paludis/die_functions.bash:82)
!!!    * main (/usr/libexec/paludis/utils/doins:91)

diefunc: making ebuild PID 2033 exit with error
ln: failed to create symbolic link '/var/tmp/paludis/media-libs-alsa-ucm-conf-1.2.6.3/image/usr/share/alsa/ucm2/conf.d/tegra/Acer Iconia Tab A500 WM8903.conf' -> '': No such file or directory

!!! ERROR in media-libs/alsa-ucm-conf-1.2.6.3::gentoo:
!!! In /usr/libexec/paludis/utils/doins at line 91
!!! doins returned error 2

!!! Call stack:
!!!    * paludis_die_or_error_func (/usr/libexec/paludis/die_functions.bash:82)
!!!    * main (/usr/libexec/paludis/utils/doins:91)

diefunc: making ebuild PID 2033 exit with error
ln: failed to create symbolic link '/var/tmp/paludis/media-libs-alsa-ucm-conf-1.2.6.3/image/usr/share/alsa/ucm2/conf.d/tegra/Compal PAZ00.conf' -> '': No such file or directory

!!! ERROR in media-libs/alsa-ucm-conf-1.2.6.3::gentoo:
!!! In /usr/libexec/paludis/utils/doins at line 91
!!! doins returned error 2

!!! Call stack:
!!!    * paludis_die_or_error_func (/usr/libexec/paludis/die_functions.bash:82)
!!!    * main (/usr/libexec/paludis/utils/doins:91)

diefunc: making ebuild PID 2033 exit with error
die trap: exiting with error.

Cause unknown, needs debugging. Will figure it out.

Affects EAPI=4+.

EAPI=8 support

Every few years, paludis breaks.

This is one of those times.

EAPI 8 has been released and is getting used now, which means that paludis will just silently ignore those ebuilds.

As usual, mgorny released an ultimate guide to EAPI 8.

The changes look mostly managable, although the IDEPEND feature needs invasive work similar to the BDEPEND feature (and even that one was never properly implemented to take cross compiling into account, rather merged with normal dependencies).

Checklist: