Re: [gentoo-user] Getting maximum space out of a hard drive
On Fri, 26 Aug 2022 06:26:39 -0500 Dale wrote: > I looked at something called ITX but they have only one PCIe slot > usually. That's not enough. I'd like to have two 6 or 8 port SATA > cards. Then balance the drives on each. I think some of the through > put is shared so the more drives on it, the slower it can be. I'd > like to have two such cards. 12 or 16 drives should be enough to last > a while. Part of me wants to do RAID but not sure about that. Yet. > I think I'm just going to go with ATX since it has several PCIe > slots. Usually, an ITX mainboard will feature a PCIe slot /and/ additional onboard SATA connectors. So you might be fine with an 8port controller card and the onboard connections. However, even if you want 16 SATA connections on one PCIe card, you can buy that. Broadcom SAS 9201-16i is one example. If that is enough bandwidth-wise will depend on your PCIe slot and the drives you're going to attach. I don't see any reason to do hardware raid these days, just a HBA and software raid (zfs or other solutions) should be fine. Everything just my 2¢ here, of course... cu Gerrit
Re: [gentoo-user] Re: python, my nemesis
On Mon, 20 Sep 2021 17:19:55 - (UTC) Grant Edwards wrote: > In my experience, it will almost definitely be less work to > reinstall --- usually a _lot_ less work. Well, after getting portage updated, everything else updated fine over night unattendedly. In this case, this was definitely less work for me than doing a reinstall. cu Gerrit
Re: [gentoo-user] python, my nemesis
On Mon, 20 Sep 2021 16:20:58 +0100 Michael wrote: > > Well, yeah, your mileage may vary. > Quite, if you can get your existing installation to only run a > minimal number of rebuilds to arrive at an upgraded toolchain, then > the benefit of reinstalling wouldn't be there. This could have been > the case on an average year, when python deprecations didn't > accelerate and EAPI didn't change. If however you end up tying up > yourself in knots with subsequent python upgrades and difficult to > resolve conflicts, then the pain Vs gain calculus changes. I was already wondering why so many things happened during the (comparatively) short time I didn't watch. Looks like people have been in lockdown with plenty of time to come around with new things. Fortunately, the base installation I have to update doesn't contain many applications (e.g., no X involved). Everything sits on an NFS server with ZFS below it, so it is quite easy to do snaphots and go back and forth between them, and we have plenty to CPU power to rebuild things. OTOH, the orchestration to have the setup re-done in a fully automated way is still under development, so I definitely wanted to try updating before really starting over. cu Gerrit
Re: [gentoo-user] python, my nemesis
On Mon, 20 Sep 2021 16:17:17 +0100 Neil Bothwick wrote: > > Well, this was the suggested way to go, see > > https://www.gentoo.org/support/news-items/2021-05-05-python3-9.html > That news item is about going from 3.8 to 3.9, you are on 3.7. Yes and no. It started with --- Display-If-Installed: dev-lang/python:3.7 Display-If-Installed: dev-lang/python:3.8 --- So my impression was I might find myself in a similar situation with 3.7. > I'd try > removing the -* items are trying again. Same issue (actually, I tried that first and only found the news item after this didn't work). But I think I fixed most issues now (see my previous posts). Thank you for taking time to look into this. cu Gerrit
Re: [gentoo-user] python, my nemesis
On Mon, 20 Sep 2021 10:34:16 -0400 Michael Orlitzky wrote: > > Well, this was the suggested way to go, see > > https://www.gentoo.org/support/news-items/2021-05-05-python3-9.html > It was only suggested for a period of about three weeks: Uh, yes, another thing I overlooked. I should get more sleep, I guess. :) Thanks for pointing this out! cu Gerrit
Re: [gentoo-user] python, my nemesis
On Mon, 20 Sep 2021 16:41:17 +0200 Arve Barsnes wrote: > This is because your gentoolkit installed version has no support for > python 3.9. Yes, I must have been overlooking this all the time. That's why I came here first (more/better eyes on the issue :-). > You might be able to include gentoolkit in your emerge > command, or you might need to build portage with python 3.8 support as > well as 3.9. This type of problem might crop up for several other > packages as you try to get python updated. emerge -p1vUD @world lists about 200 ports to rebuild now, without showing any other issues ahead. I'll go for it (and keep my fingers crossed ;-). Thank you for your support. cu Gerrit
Re: [gentoo-user] python, my nemesis
On Mon, 20 Sep 2021 15:29:30 +0100 Michael wrote: > With a year old system you should question if reinstalling your > system after a back up of configuration and data files would be a > smarter approach. If you *must* upgrade your current installation > for learning or as an experiment, then this is something which has > been done before. I know. I'm a happy Gentoo user for more than 20 years now. However, this is the master installation for a diskless setup providing the baseline for more than a dozen servers. Of course, I can still reinstall but this would be more work than just one machine + a few config files. As one year is not too terribly old (imho) and this looked like something that might be easily solved, I decided to ask for advice here first. > Personally, I'd back up /home /etc and world file, plus any databases > or websites if stored under /var/, then untar the latest stage 3 > tarball and update @system and @world. Just extracting stage3 over everything that is already there? > Overall it should be a *much* > faster approach to allow you to bring your installation up to date. Well, yeah, your mileage may vary. cu Gerrit
Re: [gentoo-user] python, my nemesis
On Mon, 20 Sep 2021 16:31:59 +0200 Gerrit Kuehn wrote: > This looks like portage is blocked by itself... so how to solve this > one? Well, I simply installed the new virtual packages manually and used "--nodeps" on portage itself afterwards... and here we are. Looks like new portage will update the rest of my system without any issue now (at least it says so when checking with -p), so here we go. Still no idea why this was blocking so hard, though. cu Gerrit
Re: [gentoo-user] python, my nemesis
On Mon, 20 Sep 2021 09:18:23 -0400 Michael Orlitzky wrote: > With our package manager written in python, you often need old python > stuff to build the new python stuff, and disabling the old python > stuff will throw a wrench into that. Even in situations where > technically some upgrade path exists, the complexity of the python > dependencies often means that the package manager will give up before > it finds the solution unless the solution is obvious. By tweaking > those variables, you make the solution less obvious to it. I took out the extra settings and solved a few conflicts manually. I'm down to this now: --- ~ # emerge -p --oneshot sys-apps/portage --verbose-conflicts These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] acct-group/portage-0 [ebuild N ] acct-user/portage-0 [ebuild U ] sys-apps/portage-3.0.20-r6 [3.0.4-r1] PYTHON_TARGETS="python3_9* (-python3_10)" !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: sys-apps/portage:0 (sys-apps/portage-3.0.20-r6:0/0::gentoo, ebuild scheduled for merge) USE="(ipc) native-extensions rsync-verify xattr -apidoc -build -doc -gentoo-dev (-selinux) -test" ABI_X86="(64)" PYTHON_TARGETS="python3_9 (-pypy3) (-python3_10) -python3_8" pulled in by sys-apps/portage (Argument) (sys-apps/portage-3.0.4-r1-3:0/0::gentoo, installed) USE="(ipc) native-extensions rsync-verify xattr -apidoc -build -doc -gentoo-dev (-selinux) -test" ABI_X86="(64)" PYTHON_TARGETS="python3_7 (-pypy3) -python3_6 -python3_8 -python3_9" pulled in by sys-apps/portage[python_targets_python3_7(-),-python_single_target_pypy3(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-)] required by (app-portage/gentoolkit-0.5.0:0/0::gentoo, installed) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="python3_7 (-pypy3) -python3_6 -python3_8" --- This looks like portage is blocked by itself... so how to solve this one? cu Gerrit
Re: [gentoo-user] python, my nemesis
On Mon, 20 Sep 2021 09:18:23 -0400 Michael Orlitzky wrote: > > --- > > ~ # cat /etc/portage/package.use/py > > */* PYTHON_TARGETS: -* python3_9 python3_8 > > */* PYTHON_SINGLE_TARGET: -* python3_9 > > --- > You should probably not mess with these variables until after your > system is 100% updated and consistent. And even then, probably not. > > With our package manager written in python, you often need old python > stuff to build the new python stuff, and disabling the old python > stuff will throw a wrench into that. Even in situations where > technically some upgrade path exists, the complexity of the python > dependencies often means that the package manager will give up before > it finds the solution unless the solution is obvious. By tweaking > those variables, you make the solution less obvious to it. Well, this was the suggested way to go, see https://www.gentoo.org/support/news-items/2021-05-05-python3-9.html But also when trying "emerge -1vUD @world" (be it with or without the package.use settings), I get stuck in conflicts (mostly on perl and setuptools). perl issues would probably resolve once I have EAPI8 support, i.e. get new portage. cu Gerrit
[gentoo-user] python, my nemesis
Hi, I'd like to update a system that is about 1 year old. I have python3.7 and python 3.8 installed, 3.7 is the default. After updating the repo, it was suggested to update portage first (probably useful to support new EAPI versions). I read about updating to python 3.9, so I created --- ~ # cat /etc/portage/package.use/py */* PYTHON_TARGETS: -* python3_9 python3_8 */* PYTHON_SINGLE_TARGET: -* python3_9 --- as suggested. However, there are still collisions (and I don't really understand them): --- ~ # emerge -p --oneshot sys-apps/portage These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] acct-group/portage-0 [ebuild N ] acct-user/portage-0 [ebuild U ] sys-devel/automake-1.16.4 [1.16.1-r1] USE="-test%" [ebuild NS] dev-lang/python-3.9.6_p2 [2.7.18-r2, 3.7.8-r2, 3.8.5] USE="sqlite* -verify-sig%" [ebuild U ] dev-python/certifi-10001-r1 [10001] PYTHON_TARGETS="python3_8* python3_9* (-python3_10)" [ebuild U ] dev-python/setuptools-57.4.0-r2 [46.4.0-r3] PYTHON_TARGETS="python3_8* python3_9* (-python3_10)" [ebuild N ] dev-python/toml-0.10.2 USE="-test" PYTHON_TARGETS="python3_8 python3_9 (-pypy3) (-python3_10)" [ebuild U ] dev-python/setuptools_scm-6.0.1-r1 [4.1.2-r1] PYTHON_TARGETS="python3_8* python3_9* (-python3_10)" [ebuild N ] dev-python/charset_normalizer-2.0.4 USE="-test" PYTHON_TARGETS="python3_8 python3_9 (-pypy3) (-python3_10)" [ebuild U ] dev-python/idna-3.2 [2.10-r1] PYTHON_TARGETS="python3_8* python3_9* (-python3_10)" [ebuild R] dev-python/PySocks-1.7.1-r1 PYTHON_TARGETS="python3_8* python3_9* (-python3_10)" [ebuild U ] dev-python/urllib3-1.26.6 [1.25.10-r1] PYTHON_TARGETS="python3_8* python3_9* (-python3_10)" [ebuild U ] dev-python/requests-2.26.0 [2.24.0-r1] PYTHON_TARGETS="python3_8* python3_9* (-python3_10)" [ebuild U ] app-portage/gemato-16.2 [15.2] PYTHON_TARGETS="python3_8* python3_9* (-python3_10)" [ebuild U ] sys-apps/portage-3.0.20-r6 [3.0.4-r1] PYTHON_TARGETS="python3_8* python3_9* (-python3_10)" !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: sys-apps/portage:0 (sys-apps/portage-3.0.20-r6:0/0::gentoo, ebuild scheduled for merge) USE="(ipc) native-extensions rsync-verify xattr -apidoc -build -doc -gentoo-dev (-selinux) -test" ABI_X86="(64)" PYTHON_TARGETS="python3_8 python3_9 (-pypy3) (-python3_10)" pulled in by sys-apps/portage (Argument) (sys-apps/portage-3.0.4-r1-3:0/0::gentoo, installed) USE="(ipc) native-extensions rsync-verify xattr -apidoc -build -doc -gentoo-dev (-selinux) -test" ABI_X86="(64)" PYTHON_TARGETS="python3_7 (-pypy3) -python3_6 -python3_8 -python3_9" pulled in by sys-apps/portage[python_targets_python3_7(-),-python_single_target_pypy3(-),-python_single_target_python3_6(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-)] required by (app-portage/gentoolkit-0.5.0:0/0::gentoo, installed) USE="-test" ABI_X86="(64)" PYTHON_TARGETS="python3_7 (-pypy3) -python3_6 -python3_8" [...] --- Plus many similar ones on packages like setuptools, gemato etc. I don't see how to get out of this vicious circle, any hints? cu Gerrit
Re: [gentoo-user] root on nfs and multiple ip addresses
On Wed, 17 Mar 2021 15:59:01 +0800 William Kenworthy wrote: > I have been moving away from fixed IP's using scripts to > update via dynamic DNS (which is why two IP numbers per MAC are > problematic). Joost was probably not suggesting the use of static IPs here, he was suggesting to fix a certain MAC to a certain IP employing dhcp (or I didn't understand properly what you both are talking about here ;-). > Interestingly, dhcp issues the same IP addresses consistently to both > the boot process and OS. While stopping the OS requesting an address > is easy enough ... the question is why is that necessary. Google > shows a number of recommendations and howtos saying to do just that > but it seems a "kludge". Did you make sure that the two IPs are issued to the same MAC? I don't have much experience with the ISC server, but I'd think this should not happen. Just a wild guess: does the client update its time (by running ntpclient or similar) during boot so it might think different about the age of its dhcp lease than the server? cu Gerrit
Re: [gentoo-user] ssmtp - localmail
On Thu, 26 Nov 2020 00:20:52 -0700 the...@sys-concept.com wrote: > Aliases for TO: addresses would normally need to be set in > /etc/aliases, but SSMTP doesn't read this! Instead, you need to edit > /etc/mail.rc and add a line such as alias root > root Concerning root: Can't you just put root=yourn...@youremail.com in your ssmtpd.conf? cu Gerrit
Re: [gentoo-user] ssmtp - localmail
On Thu, 26 Nov 2020 00:20:52 -0700 the...@sys-concept.com wrote: > According to: > https://wiki.webevaluation.nl/sending_e-mail_with_ssmtp > ssmtp has no local e-mail so it can not send cron output to > /var/mail/user The manpage here says --- It does not do aliasing, which must be done either in the user agent or on the mail-hub. Nor does it honor .forwards, which have to be done on the recieving host. It especially does not deliver to pipelines. --- > > But from posting at: > https://unix.stackexchange.com/questions/69133/where-is-the-setting-for-sending-email-to-a-system-user-with-ssmtp > > Aliases for TO: addresses would normally need to be set in > /etc/aliases, but SSMTP doesn't read this! Instead, you need to edit > /etc/mail.rc and add a line such as alias root > root > > Can anybody verify it? Not right now, but what do you try to achieve? You can set email destination for cron with MAILTO= in your crontab, if sending mails from cron is your problem. cu Gerrit
Re: [gentoo-user] gentoo and kickstart files
On Sun, 22 Nov 2020 10:12:47 + Neil Bothwick wrote: > ISTR someone was working on an Ansible playbook to automate > installation. One of these? https://github.com/stefangweichinger/ansible-gentoo https://github.com/grizz/ansible-gentoo https://github.com/agaffney/ansible-gentoo_install cu Gerrit
Re: [gentoo-user] Disabling ssh password login on all accounts?
On Tue, 11 Aug 2020 06:21:26 -0400 "Walter Dnes" wrote: > # To disable tunneled clear text passwords, change to no here! > #PasswordAuthentication yes > > Is that correct? If not, what is the correct setting to change? You might also want to set to "No" the following ones: ChallengeResponseAuthentication UsePAM cu Gerrit
Re: [gentoo-user] Joining PDF files together.
On Thu, 9 Jul 2020 13:31:36 + Alan Mackenzie wrote: > Would somebody please suggest to me an appropriate package to do this > with. I use ImageMagick for joining pages scanned with xsane: convert page1 page2 pages.pdf Note that especially for pdf files, tools like pdftk or pdfjam will probably produce better results. However, (x)sane usually produces very large pdf files. So you may receive better end results creating separate png files with sane and then join these (using ImageMagick as shown above). cu Gerrit
Re: [gentoo-user] old kernel on Gentoo
On Sun, 21 Jun 2020 10:31:08 + Raffaele BELARDI wrote: > What about the rest of the system, in particular GCC and the C > libraries? Do you manage to build the 3.x kernel with up to date > system or do you need to ''freeze'' some packages? 3.2 required an older gcc for me. I think 5.x and 6.x worked fine (if memory serves me well). As gcc comes slotted, it is not too hard to have them all installed in parallel. cu Gerrit
Re: [gentoo-user] old kernel on Gentoo
On Wed, 17 Jun 2020 16:52:49 + Raffaele BELARDI wrote: > I might need to build and run an old 3.x kernel on a Desktop PC for > some very specific tests. Would Gentoo be a good solution? I see that > currently gentoo-sources only includes 4.x and 5.x sources. There is still 3.x in the vanilla-sources. I've been using (manually backported) 3.2 vanilla kernels with recent Gentoo at least up to somewhen 2018. HTH cu Gerrit
Re: [gentoo-user] $$ORIGIN in NEEDED.ELF.2
On Wed, 20 May 2020 10:55:58 +0200 Gerrit Kuehn wrote: > NEEDED.ELF.2: $: bad substitution I found and patched an "$$ORIGIN" statement in the original cmake project. However, according to https://bugs.gentoo.org/542796 my impression is that this should have been handled by portage? cu Gerrit
[gentoo-user] $$ORIGIN in NEEDED.ELF.2
Hello, One of my homemade ebuilds complains after installation about NEEDED.ELF.2: $: bad substitution Indeed, NEEDED.ELF.2 contains "$ORIGIN" and "$$ORIGIN" in multiple places which is probably causing this. However, I cannot find where this originates from. Any ideas where to look? cu Gerrit
Re: [gentoo-user] libXp-1.0.3 emerge issue
On Tue, 19 May 2020 08:20:41 +0200 Gerrit Kuehn wrote: > I looked into other X lib ebuilds like libXext-1.3.4.ebuild. This is > installing 32bit libs into the correct directory, but it looks not > different to me. I updated my ebuild to using EAPI=7 and xorg-3 > (instead of the original EAPI=5 and xorg-2), but it still insists on > using lib32 paths. For the record: I found that the profile of the system was still set to 17.0 where it should have been on 17.1. This causes SYMLINK_LIB to be set to "yes" which then makes multilib.eclass use lib32 instead of lib paths. After setting the profile to 17.1 (where it should have been in the first place), everything works as expected now. cu Gerrit
Re: [gentoo-user] libXp-1.0.3 emerge issue
On Mon, 18 May 2020 18:48:56 +0200 Gerrit Kuehn wrote: > USE="-static-libs" ABI_X86="32%* (64%*) (-x32)" > > I'm not familiar with the ABI flags (is there any documentation on > that, Google doesn't come up with anything useful for me right now?). > What does the "%" mean, and how would I turn off 32bit completely? I think I made some progress on this and found that my old ebuilds install and search libs in "lib32" paths (see --libdir setting below): --- >>> Configuring source >>> in /var/tmp/portage/x11-misc/printproto-1.0.5-r2/work/printproto-1.0.5 ... * abi_x86_32.x86: running multilib-minimal_abi_src_configure * econf: updating printproto-1.0.5/config.guess with /usr/share/gnuconfig/config.guess * econf: updating printproto-1.0.5/config.sub with /usr/share/gnuconfig/config.sub /var/tmp/portage/x11-misc/printproto-1.0.5-r2/work/printproto-1.0.5/configure --prefix=/usr --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --disable-dependency-tracking --disable-silent-rules --docdir=/usr/share/doc/printproto-1.0.5-r2 --htmldir=/usr/share/doc/printproto-1.0.5-r2/html --libdir=/usr/lib32 --enable-shared --disable-static --- From https://wiki.gentoo.org/wiki/Project:AMD64/Multilib_layout I understand that 32bit libs should go to /lib and /usr/lib, not to lib32 anymore. I guess this may be the root cause for my ebuild issues?! I see the same with the libXp ebuild: --- >>> Configuring source >>> in /var/tmp/portage/x11-libs/libXp-1.0.3/work/libXp-1.0.3 ... * abi_x86_32.x86: running multilib-minimal_abi_src_configure * econf: updating libXp-1.0.3/config.guess with /usr/share/gnuconfig/config.guess * econf: updating libXp-1.0.3/config.sub with /usr/share/gnuconfig/config.sub /var/tmp/portage/x11-libs/libXp-1.0.3/work/libXp-1.0.3/configure --prefix=/usr --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --disable-dependency-tracking --disable-silent-rules --docdir=/usr/share/doc/libXp-1.0.3 --htmldir=/usr/share/doc/libXp-1.0.3/html --with-sysroot=/ --libdir=/usr/lib32 --disable-selective-werror --enable-shared --disable-static --- This probably makes it look into /usr/lib32 for dependent 32bit libraries like libXau and so on that it complains about not finding them later. Indeed, these are to be found in /usr/lib, not /usr/lib32. But why doesn't emerge (or multilib-minimal_abi_src_configure) know about this and doesn't "do the right thing"? I looked into other X lib ebuilds like libXext-1.3.4.ebuild. This is installing 32bit libs into the correct directory, but it looks not different to me. I updated my ebuild to using EAPI=7 and xorg-3 (instead of the original EAPI=5 and xorg-2), but it still insists on using lib32 paths. Any further hints would be really appreciated. cu Gerrit
Re: [gentoo-user] libXp-1.0.3 emerge issue
On Mon, 18 May 2020 11:29:43 -0400 Jack wrote: > Since you suggest this might be related to multilib, is this the > configuration for 32 bit or 64 bit? Assuming you are primarily 64 > bits, which packages have 32 bit versions enabled? If it is the 32 > bit version failing, can you disable it? I made a makeshift solution meanwhile by removing the multilib parts in the ebuild. Without them, everything compiles just fine, and I do get 32bit and 64bit libraries?! I'm only interested in the 64bit version, actually, as my software links against these libs. I didn't enable 32bit for anything explicitely, but the standard flags for libXp are USE="-static-libs" ABI_X86="32%* (64%*) (-x32)" I'm not familiar with the ABI flags (is there any documentation on that, Google doesn't come up with anything useful for me right now?). What does the "%" mean, and how would I turn off 32bit completely? > > This is somehow caused by multilib settings, I guess. Just untar'ing > > the archive and doing configure/make works fine. It appears as if > > just the ebuild went unhappy. It looks like this: > Note the ebuild itself isn't failing, it's the ./configure stage > failing to find something it needs. If a manual ./configure > succeeds, it's using some different settings compared to as run by > the ebuild. Check the exact ./configure line being run, and possible > see if it was run twice in the full build log, once each for 32 bit > and 64 bits. There is /var/tmp/portage/x11-libs/libXp-1.0.3/work/libXp-1.0.3-abi_x86_32.x86/config.log (so obviously the 32bit part is causing the trouble) which says the error is caused by $PKG_CONFIG --exists --print-errors "x11 >= 1.6 xext xextproto xau printproto" However, this must be something 32bit specific. Running --- pkg-config --exists --print-errors "x11 >= 1.6 xext xextproto xau printproto" --- on the commandline works just fine. cu Gerrit
[gentoo-user] libXp-1.0.3 emerge issue
Hello,
I keep a "private" overlay with d deprecated libXp and printproto ports
I need for existing software to link against. This used to work fine
until switching profiles to 17. Now printproto still emerges fine,but
with libXp it stops at configure stage with
---
[...]
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
checking for XPRINT... no
configure: error: Package requirements (x11 >= 1.6 xext xextproto xau
printproto) were not met:
No package 'x11' found
No package 'xext' found
No package 'xau' found
Package 'xau', required by 'printproto', not found
Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.
Alternatively, you may set the environment variables XPRINT_CFLAGS
and XPRINT_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
!!! Please attach the following file when seeking support:
!!!
/var/tmp/portage/x11-libs/libXp-1.0.3/work/libXp-1.0.3-abi_x86_32.x86/config.log
* ERROR: x11-libs/libXp-1.0.3::cds failed (configure phase):
* econf failed
*
* Call stack:
* ebuild.sh, line 125: Called src_configure
* environment, line 3238: Called xorg-2_src_configure
* environment, line 4250: Called
autotools-multilib_src_configure
* environment, line 672: Called
multilib-minimal_src_configure
* environment, line 2406: Called multilib_foreach_abi
'multilib-minimal_abi_src_configure'
* environment, line 2639: Called
multibuild_foreach_variant '_multilib_multibuild_wrapper'
'multilib-minimal_abi_src_configure'
* environment, line 2336: Called _multibuild_run
'_multilib_multibuild_wrapper' 'multilib-minimal_abi_src_configure'
* environment, line 2334: Called
_multilib_multibuild_wrapper 'multilib-minimal_abi_src_configure'
* environment, line 551: Called
multilib-minimal_abi_src_configure
* environment, line 2400: Called multilib_src_configure
* environment, line 2864: Called
autotools-utils_src_configure
* environment, line 712: Called econf
'--docdir=/usr/share/doc/libXp-1.0.3' '--enable-shared'
'--disable-static' '--disable-selective-werror'
*phase-helpers.sh, line 681: Called __helpers_die 'econf
failed'
* isolated-functions.sh, line 112: Called die
* The specific snippet of code:
* die "$@"
---
This is somehow caused by multilib settings, I guess. Just untar'ing
the archive and doing configure/make works fine. It appears as if just
the ebuild went unhappy. It looks like this:
---
# Copyright 1999-2017 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
EAPI=5
XORG_MULTILIB=yes
inherit xorg-2
DESCRIPTION="X.Org Xp library"
RESTRICT="primaryuri"
KEYWORDS="alpha amd64 arm arm64 hppa ia64 ~mips ppc ppc64 ~s390 ~sh
sparc x86 ~ppc-aix ~amd64-fbsd ~x86-fbsd ~amd64-linux ~arm-linux ~x86-linux
~ppc-macos ~x64-macos ~x86-macos ~sparc-solaris ~sparc64-solaris ~x64-solaris
~x86-solaris ~x86-winnt"
IUSE=""
RDEPEND=">=x11-libs/libX11-1.6.2[${MULTILIB_USEDEP}]
>=x11-libs/libXext-1.3.2[${MULTILIB_USEDEP}]
>=x11-libs/libXau-1.0.7-r1[${MULTILIB_USEDEP}]
>=x11-misc/printproto-1.0.5-r1[${MULTILIB_USEDEP}]"
DEPEND="${RDEPEND}"
---
Any ideas how to fix this properly (apart from having upstream to not
require libXp in the first place)?
cu
Gerrit
Re: [gentoo-user] Is Gentoo dead?
On Wed, 6 May 2020 22:39:39 -0500 Dale wrote: > If you enjoy using Gentoo, or if you don't, if you skip this thread, > you won't be missing a whole lot. I don't recall any breaking news > or life saving tips in it. ROFL What a nice comment to read when starting my day. Thanks! ;-) cu Gerrit
Re: [gentoo-user] zoom?
On Wed, 25 Mar 2020 11:51:33 + Jorge Almeida wrote: > Did someone try to install zoom? (relevant to many people during the > current crisis) > > https://support.zoom.us/hc/en-us/articles/204206269-Installing-Zoom-on-Linux > > I downloaded an archive (cannot find the URL again; the site is that > bad) and the directory doesn't even contain a REDME...) I was wondering, too. However, I just unpacked the .tar archive I downloaded to /opt/zoom and started zoomlinux. Works for me (I guess my system already had all needed libs installed). cu Gerrit
