mageslayer / paludis-gentoo-patches Goto Github PK
View Code? Open in Web Editor NEWUnofficial Gentoo patches for Paludis package manager
License: GNU General Public License v2.0
Unofficial Gentoo patches for Paludis package manager
License: GNU General Public License v2.0
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.
exherbo/master
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/eapi8gentoo/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.If anyone has thoughts or questions please share them. We are unsure at the moment how many people would be affected.
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.
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.
Corresponding Gentoo bug https://bugs.gentoo.org/655976
Create a separate overlay repo for user's to try this fork.
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.
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
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:
--datarootdir
automatically passed by econf
--disable-static
automatically passed by econf
doconfd
not influenced by insopts
doenvd
not influenced by insopts
doheader
not influenced by insopts
doinitd
not influenced by exeopts
dosym -r
for relative symlinksfetch+
notation in SRC_URI
to override fetch restrictionmirror+
notation in SRC_URI
to override mirror restrictionhasq
bannedhasv
banneduseq
bannedIDEPEND
as host-based-only post-install-time dependency variable, mimicking what BDEPEND
is for DEPEND
- can probably be merged into RDEPEND
PATCHES
does not allow options any longerPROPERTIES
is append by default instead of overwriteRESTRICT
is append by default instead of overwritetest_network
as new PROPERTIES
value for network support during the test phaseunpack
dropped support for 7-zip
, LHA
and RAR
formatsupdates
filenames need no longer follow the nQ-yyyy
schemeusev
accepts optional second parameter to override output valuepkg_*
phases set working directory to an empty (but existing) directoryStarting today I get this when updating:
Deciding: 6 restarts, 22112 steps, 1 metadata (1 gentoo)
Error:
Paludis bug http://paludis.exherbo.org/trac/ticket/1347
Corresponding Gentoo bug
https://bugs.gentoo.org/show_bug.cgi?id=658268
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?
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.
it fails during configure
The upstream bug is here: http://paludis.exherbo.org/trac/ticket/1369
Paludis bug http://paludis.exherbo.org/trac/ticket/1363
Corresponding Gentoo bug https://bugs.gentoo.org/658270
RUBY_TARGETS="ruby24 -ruby25"
completely breaks paludis
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.)
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?
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
Corresponding Gentoo bug
https://bugs.gentoo.org/show_bug.cgi?id=658274
Looks like compatible licensed implementation is a reference one.
See https://github.com/BLAKE2/BLAKE2
See "$ grep -R WHIRLPOOL *" for inspiration
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
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.
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.
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.
Currently "cave resolve" does not suggest --reinstall-dependents-of as possible completion.
To be fixed.
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)
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
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.
this is error when running cave resolve llvm -1zx:
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:
!!! 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
* 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.
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+
.
Corresponding Gentoo bug
https://bugs.gentoo.org/show_bug.cgi?id=658276
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
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)
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.