[gentoo-user] meson build woes
6/lib/mesonbuild/dependencies/data
copying mesonbuild/dependencies/data/CMakeLists.txt ->
/var/tmp/portage/dev-util/meson-0.54.2/work/meson-0.54.2-python3_6/lib/mesonbuild/dependencies/data
copying mesonbuild/dependencies/data/CMakeListsLLVM.txt ->
/var/tmp/portage/dev-util/meson-0.54.2/work/meson-0.54.2-python3_6/lib/mesonbuild/dependencies/data
copying mesonbuild/dependencies/data/CMakePathInfo.txt ->
/var/tmp/portage/dev-util/meson-0.54.2/work/meson-0.54.2-python3_6/lib/mesonbuild/dependencies/data
warning: build_py: byte-compiling is disabled, skipping.
* python3_7: running distutils-r1_run_phase distutils-r1_python_compile
python3.7 setup.py build -j 6
Traceback (most recent call last):
File "setup.py", line 24, in
from setuptools import setup
ImportError: cannot import name 'setup' from 'setuptools' (unknown location)
* ERROR: dev-util/meson-0.54.2::gentoo failed (compile phase):
* (no error message)
*
* Call stack:
* ebuild.sh, line 125: Called src_compile
* environment, line 2949: Called distutils-r1_src_compile
* environment, line 1219: Called _distutils-r1_run_foreach_impl
'distutils-r1_python_compile'
* environment, line 447: Called python_foreach_impl
'distutils-r1_run_phase' 'distutils-r1_python_compile'
* environment, line 2557: Called multibuild_foreach_variant
'_python_multibuild_wrapper' 'distutils-r1_run_phase'
'distutils-r1_python_compile'
* environment, line 2056: Called _multibuild_run
'_python_multibuild_wrapper' 'distutils-r1_run_phase'
'distutils-r1_python_compile'
* environment, line 2054: Called _python_multibuild_wrapper
'distutils-r1_run_phase' 'distutils-r1_python_compile'
* environment, line 846: Called distutils-r1_run_phase
'distutils-r1_python_compile'
* environment, line 1210: Called distutils-r1_python_compile
* environment, line 1079: Called esetup.py 'build' '-j' '6'
* environment, line 1600: Called die
* The specific snippet of code:
* "${@}" || die "${die_args[@]}";
*
* If you need support, post the output of `emerge --info
'=dev-util/meson-0.54.2::gentoo'`,
* the complete build log and the output of `emerge -pqv
'=dev-util/meson-0.54.2::gentoo'`.
* The complete build log is located at
'/var/log/portage/dev-util:meson-0.54.2:20200822-053930.log'.
* For convenience, a symlink to the build log is located at
'/var/tmp/portage/dev-util/meson-0.54.2/temp/build.log'.
* The ebuild environment file is located at
'/var/tmp/portage/dev-util/meson-0.54.2/temp/environment'.
* Working directory: '/var/tmp/portage/dev-util/meson-0.54.2/work/meson-0.54.2'
* S: '/var/tmp/portage/dev-util/meson-0.54.2/work/meson-0.54.2'
[ebuild U ] dev-util/meson-0.54.2 [0.52.1] USE="(-test)"
PYTHON_TARGETS="python3_6 python3_7* -python3_8"
Portage 2.3.89 (python 3.6.11-final-0,
default/linux/amd64/17.1/desktop/plasma/systemd, gcc-9.3.0, glibc-2.31-r6,
5.6.7-gentoo x86_64)
=
System Settings
=
System uname:
Linux-5.6.7-gentoo-x86_64-AMD_FX-tm-8120_Eight-Core_Processor-with-gentoo-2.6
KiB Mem:16454628 total, 1436496 free
KiB Swap: 122934612 total, 122899796 free
Timestamp of repository gentoo: Fri, 21 Aug 2020 17:45:01 +
Head commit of repository gentoo: 67f6485c888473f54f63e2d5eeda5bb7db105a1b
sh bash 5.0_p18
ld GNU ld (Gentoo 2.33.1 p2) 2.33.1
app-shells/bash: 5.0_p18::gentoo
dev-java/java-config: 2.2.0-r4::gentoo
dev-lang/perl:5.30.3::gentoo
dev-lang/python: 2.7.18-r1::gentoo, 3.6.11-r2::gentoo,
3.7.8-r2::gentoo, 3.8.5::gentoo
dev-util/cmake: 3.16.5::gentoo
dev-util/pkgconfig: 0.29.2::gentoo
sys-apps/baselayout: 2.6-r1::gentoo
sys-apps/sandbox: 2.18::gentoo
sys-devel/autoconf: 2.13-r1::gentoo, 2.69-r4::gentoo
sys-devel/automake: 1.11.6-r3::gentoo, 1.16.1-r1::gentoo
sys-devel/binutils: 2.33.1-r1::gentoo
sys-devel/gcc:8.3.0-r3::gentoo, 9.2.0-r2::gentoo, 9.3.0-r1::gentoo
sys-devel/gcc-config: 2.3.1::gentoo
sys-devel/libtool:2.4.6-r6::gentoo
sys-devel/make: 4.2.1-r4::gentoo
sys-kernel/linux-headers: 5.4-r1::gentoo (virtual/os-headers)
sys-libs/glibc: 2.31-r6::gentoo
Repositories:
gentoo
location: /usr/portage
sync-type: rsync
sync-uri: rsync://rsync.au.gentoo.org/gentoo-portage
priority: -1000
sync-rsync-verify-max-age: 24
sync-rsync-verify-metamanifest: yes
sync-rsync-extra-opts:
sync-rsync-verify-jobs: 1
PacMan_Private
location: /usr/local/portage
masters: gentoo
priority: 0
ABI="amd64"
ABI_X86="64"
ACCEPT_KEYWORDS="amd64"
ACCEPT_LICENSE="*"
ACCEPT_PROPERTIES="*"
ACCEPT_RESTRICT="*"
ADA_TARGET="gnat_2018"
ALSA_CARDS="ali5451 als4000 ati
Re: [gentoo-user] [OT] Persistent empty window
On Sat, 22 Aug 2020 23:15:51 +0100, Peter Humphrey wrote: > > It's Knotes, I do that from time to time. If you right-click on the > > right hand edge of the note, you'll get a menu that includes a remove > > option. > > Thank you Neil and Michael. So it proved. > > What an obscure "feature." Not that obscure, click anywhere but where you meant to and it's staring you in the face :) -- Neil Bothwick I'm not closed minded, you're just wrong. pgpj27kQ5vYul.pgp Description: OpenPGP digital signature
Re: [gentoo-user] [OT] Persistent empty window
On Saturday, 22 August 2020 20:00:00 BST Neil Bothwick wrote: > On Sat, 22 Aug 2020 16:46:13 +0100, Peter Humphrey wrote: > > Today I went to paste a word into a Konsole instance, but missed, so > > that it appeared in an otherwise blank, frameless, yellowish, 3" square > > window on the desktop. I can't raise the window, nor tab to it, it > > doesn't show up in 'ps au', it survives a reboot, it seems not to be > > connected with the paste buffer, and I just can't identify it. > > It's Knotes, I do that from time to time. If you right-click on the right > hand edge of the note, you'll get a menu that includes a remove option. Thank you Neil and Michael. So it proved. What an obscure "feature." -- Regards, Peter.
Re: [gentoo-user] tips on running a mail server in a cheap vps provider run but not-so-trusty admins?
On Sat, Aug 22, 2020 at 04:15:38AM +, Caveman Al Toraboran wrote: > ‐‐‐ Original Message ‐‐‐ > On Saturday, August 22, 2020 12:10 AM, Grant Taylor > wrote: > > > There is some nebulous area around what that actually means. But the > > idea is that the receiving server believes, in good faith, that it has > > committed the message to persistent storage. Usually this involves > > writing the message to disk, probably via a buffered channel, and then > > issued system calls to ask the OS to flush the buffer to disk. > > just to double check i got you right. due to > flushing the buffer to disk, this would mean that > mail's throughput is limited by disk i/o? > > or did i misunderstand? > > i sort of feel it may suffice to only save to > disk, and close fd. then let the kernel choose > when to actually store it in disk. When an M.T.A. encounters mail, the content of the mail will first exist in the M.T.A.'s local memory, in a buffer. Before sending an "OK" to the sending server, it should first make an attempt to write it to disk, through an fwrite (stdio) or write (POSIX) call. At that point, it is, in theory, the kernel's choice if and when it is _actually_ written to disk, but if one of the aforementioned functions return a success code, the M.T.A. has done its bit, and can consider the message "safely stored". -- Ashley Dixon suugaku.co.uk 2A9A 4117 DA96 D18A 8A7B B0D2 A30E BF25 F290 A8AA signature.asc Description: PGP signature
Re: [gentoo-user] sys-apps/systemd is blocking app-emulation/docker-19.03.12
On Sat, Aug 22, 2020 at 09:48:00PM +0200, Hogren wrote:
> These are the packages that would be merged, in order:
>
> Calculating dependencies... done!
> [ebuild N ] app-emulation/docker-19.03.12::gentoo USE="container-init
> overlay seccomp -apparmor -aufs -btrfs -device-mapper -hardened" 0 KiB
> [blocks B ] sys-apps/systemd[-cgroup-hybrid(+)]
> ("sys-apps/systemd[-cgroup-hybrid(+)]" is blocking
> app-emulation/docker-19.03.12)
>
> Total: 1 package (1 new), Size of downloads: 0 KiB
> Conflict: 1 block (1 unsatisfied)
>
> * Error: The above package list contains packages which cannot be
> * installed at the same time on the same system.
>
> (sys-apps/systemd-245.5:0/2::gentoo, installed) pulled in by
> sys-apps/systemd required by @selected
>
> (app-emulation/docker-19.03.12:0/0::gentoo, ebuild scheduled for merge)
> pulled in by
> app-emulation/docker
systemd is not blocking Docker; Docker is blocking systemd. From the ebuild
(gentoo.git/app-emulation/docker/docker-19.03.12.ebuild):
RDEPEND="
${COMMON_DEPEND}
!sys-apps/systemd[-cgroup-hybrid(+)]
[...]
I.e., "block systemd unless the `cgroup-hybrid` flag is set". The `(+)` suffix
means that the flag is assumed to be enabled if it does not exist [1]. For your
particular case (systemd v. 245.5), this suffix is irrelevant.
Just re-emerge systemd with USE="cgroup-hybrid" and see if that helps.
Ashley.
[1]
https://devmanual.gentoo.org/general-concepts/dependencies/#use-dependency-defaults
--
Ashley Dixon
suugaku.co.uk
2A9A 4117
DA96 D18A
8A7B B0D2
A30E BF25
F290 A8AA
signature.asc
Description: PGP signature
[gentoo-user] sys-apps/systemd is blocking app-emulation/docker-19.03.12
Hello world !
I suppose this problem is really easy to solve for many people here. But
I failed to deal with it !
I had systemd and docker since a long time.
For the first time, I can't make an update of my system.
Recently, I tried to run "emerge --newuse --update --autounmask-write
--deep --with-bdeps=y @world". I see the problem. I unmerged docker. I
run again the precedent command.
All was right.
So, I try to emerge docker : "emerge --verbose app-emulation/docker"
This is the output :
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild N ] app-emulation/docker-19.03.12::gentoo
USE="container-init overlay seccomp -apparmor -aufs -btrfs
-device-mapper -hardened" 0 KiB
[blocks B ] sys-apps/systemd[-cgroup-hybrid(+)]
("sys-apps/systemd[-cgroup-hybrid(+)]" is blocking
app-emulation/docker-19.03.12)
Total: 1 package (1 new), Size of downloads: 0 KiB
Conflict: 1 block (1 unsatisfied)
* Error: The above package list contains packages which cannot be
* installed at the same time on the same system.
(sys-apps/systemd-245.5:0/2::gentoo, installed) pulled in by
sys-apps/systemd required by @selected
(app-emulation/docker-19.03.12:0/0::gentoo, ebuild scheduled for
merge) pulled in by
app-emulation/docker
For more information about Blocked Packages, please refer to the following
section of the Gentoo Linux x86 Handbook (architecture is irrelevant):
https://wiki.gentoo.org/wiki/Handbook:X86/Working/Portage#Blocked_packages
Anyone can help me ?
Thank you !
Hogren
Re: [gentoo-user] [OT] Persistent empty window
On Sat, 22 Aug 2020 16:46:13 +0100, Peter Humphrey wrote: > Today I went to paste a word into a Konsole instance, but missed, so > that it appeared in an otherwise blank, frameless, yellowish, 3" square > window on the desktop. I can't raise the window, nor tab to it, it > doesn't show up in 'ps au', it survives a reboot, it seems not to be > connected with the paste buffer, and I just can't identify it. It's Knotes, I do that from time to time. If you right-click on the right hand edge of the note, you'll get a menu that includes a remove option. -- Neil Bothwick I'm not closed minded, you're just wrong. pgpWZRPzD7SAU.pgp Description: OpenPGP digital signature
Re: [gentoo-user] [OT] Persistent empty window
On Saturday, 22 August 2020 16:46:13 BST Peter Humphrey wrote: > Afternoon all, > > Today I went to paste a word into a Konsole instance, but missed, so that it > appeared in an otherwise blank, frameless, yellowish, 3" square window on > the desktop. I can't raise the window, nor tab to it, it doesn't show up in > 'ps au', it survives a reboot, it seems not to be connected with the paste > buffer, and I just can't identify it. > > Anyone have a clue? It's the software equivalent to hardware post-its®. You should be able to right click on it and edit/delete it, but you may need to unlock the desktop Plasma widgets first. I think these software post-its are called "Popup Notes". signature.asc Description: This is a digitally signed message part.
[gentoo-user] [OT] Persistent empty window
Afternoon all, Today I went to paste a word into a Konsole instance, but missed, so that it appeared in an otherwise blank, frameless, yellowish, 3" square window on the desktop. I can't raise the window, nor tab to it, it doesn't show up in 'ps au', it survives a reboot, it seems not to be connected with the paste buffer, and I just can't identify it. Anyone have a clue? -- Regards, Peter. Gentoo testing system, openrc-0.42.1 gcc 10.2.0, sys-kernel/gentoo-sources 5.7.12 QT 5.15.0, KDE frameworks 5.73.0, KDE plasma 5.19.4 KDE apps 20.08.0 incl KMail 5.15.0 (20.08.0), akonadi 20.04.3 dev-db/mariadb-10.4.13, net-libs/webkit-gtk-3.0.4-r302 x11-drivers/xf86-video-amdgpu 19.1.0 dev-libs/amdgpu-pro-opencl-19.30.838629
[gentoo-user] USE="-libglvnd" ignored
I just updated my secondary machine. No mention of "libglvnd" in
package.use...
[i3][root][~] grep libglvnd /etc/portage/package.use/*
"Disabled" in make.conf...
[i3][root][~] grep libglvnd /etc/portage/make.conf
USE="X apng fmpeg introspection jpeg opengl openmp png szip truetype x264 x265
xorg threads vala -acl -arp -arping -berkdb -bindist -bles -caps -chatzilla
-cracklib -crypt -elogind -filecaps -gallium -gdbm -gmp-autoupdate -graphite
-gstreamer -iconv -ipc -iptables -ipv6 -jemalloc3 -libav -libglvnd -llvm
-manpager -nls -pam -pch -roaming -sendmail -spell -tcpd -udev -udisks -unicode
-upower -xinerama"
But libglvnd is still pulled in as a hard dependency...
[i3][root][~] emerge -pv --depclean media-libs/libglvnd
Calculating dependencies... done!
media-libs/libglvnd-1.3.2 pulled in by:
media-libs/mesa-20.0.8 requires
>=media-libs/libglvnd-1.2.0-r1[X,abi_x86_64(-)]
x11-base/xorg-server-1.20.8-r1 requires media-libs/libglvnd[X]
>>> No packages selected for removal by depclean
Packages installed: 583
Packages in world:80
Packages in system: 43
Required packages:583
Number to remove: 0
If it's really a hard dependency, then why pretend in the ebuilds that
it's optional?
[i3][root][~] grep libglvnd /usr/portage/media-libs/mesa/mesa-20.0.8.ebuild
+classic d3d9 debug +dri3 +egl +gallium +gbm gles1 +gles2 +libglvnd
+llvm
libglvnd? (
>=media-libs/libglvnd-1.2.0-r1[X?,${MULTILIB_USEDEP}]
!libglvnd? (
libglvnd? ( usr/lib/libGLX_mesa.so.0.0.0 )
$(meson_use libglvnd glvnd)
if ! use libglvnd; then
[i3][root][~] grep libglvnd
/usr/portage/x11-base/xorg-server/xorg-server-1.20.8-r1.ebuild
IUSE="${IUSE_SERVERS} debug +elogind ipv6 libressl +libglvnd minimal selinux
suid systemd +udev unwind xcsecurity"
CDEPEND="libglvnd? (
media-libs/libglvnd[X]
!!x11-drivers/nvidia-drivers[-libglvnd(-)]
!libglvnd? ( >=app-eselect/eselect-opengl-1.3.0 )
if ! use libglvnd; then
--
Walter Dnes
I don't run "desktop environments"; I run useful applications
Re: [gentoo-user] tips on running a mail server in a cheap vps provider run but not-so-trusty admins?
‐‐‐ Original Message ‐‐‐ On Saturday, August 22, 2020 12:19 AM, Grant Taylor wrote: > > i was thinking (and still) if such relay-by-relay delivery increases > > probability of error by a factor of n (n = number of relays in the > > middle). e.g. probability of accidental silent mail loss is if one, > > or more, accidentally said "yes got it!" but actually didn't. i.e.: > > It definitely won't be a factor of n, where n is the number of relays. why? since relays are in series, and since each relay trusts next relay's "yup got it!", then error rate should add up for every extra step. no?
Re: [gentoo-user] tips on running a mail server in a cheap vps provider run but not-so-trusty admins?
‐‐‐ Original Message ‐‐‐ On Saturday, August 22, 2020 12:10 AM, Grant Taylor wrote: > There is some nebulous area around what that actually means. But the > idea is that the receiving server believes, in good faith, that it has > committed the message to persistent storage. Usually this involves > writing the message to disk, probably via a buffered channel, and then > issued system calls to ask the OS to flush the buffer to disk. just to double check i got you right. due to flushing the buffer to disk, this would mean that mail's throughput is limited by disk i/o? or did i misunderstand? i sort of feel it may suffice to only save to disk, and close fd. then let the kernel choose when to actually store it in disk.
Re: [gentoo-user] tips on running a mail server in a cheap vps provider run but not-so-trusty admins?
‐‐‐ Original Message ‐‐‐ On Friday, August 21, 2020 11:37 PM, Grant Taylor wrote: > SMTP may not be the best, but I do think that it has some merits. > Merits that the previously mentioned HTTP/2 alternative misses. not a major point but just to clarify a thing. i think it's unfair to look at SMTP as a single thing that compares against HTTP*. because while HTTP* is a single-ish thing, SMTP is several things. i.e. SMTP is at least 2 parts: 1. resource exchange layer where people are defined as some kind of URL (e.g. n...@dom.zone) and attachments are base64-ed text balls referred to by some numbers in RFC822. This part overlaps with HTTP*. let's call this "RESXCH_SERVER". 2. the part where it defines how to process the exchanged resources (e.g. safe storage, routing, etc). this part is beyond HTTP*'s scope, and is the "web app" scope. let's call this "RESUSE_SERVER" of course, email still doesn't work with those 2 parts, because you need a way to get mails to your email client, so you end up using POP or IMAP. now, this --itself-- is also two parts: 1. resource exchange layer to send resources to users. which also overlaps with HTTP* (again). let's call this "RESXCH_CLIENT". 2. the part where it defines how the mail client to treat the resources. let's call this "RESUSE_CLIENT". > Why add an additional protocol to the stack? > > TCP / SMTP is two layers. > > TCP / HTTP / $Email-protocol-de-jure is three layers. > > UDP / HTTP / $Email-protocol-de-jusre is three layers. > > Why introduce an additional layer? i disagree. i think this is more like it about the current email system: RESXCH_SERVER / RESUSE_SERVER / RESXCH_CLIENT / RESUSE_CLIENT it's 4 different layers to exchange mail between people. but if we plug HTTP* in the mix, it because only 3 different layers: HTTP* / RESUSE_SERVER / HTTP* / RESUSE_CLIENT and it is even nicer for when HTTP* is plugged, because it is also the protocol used for most of internet's traffic (web browsing). so basically total expected number of protocols/layers used in the universe, per second, will be much less if we, on planet earth, use a mail system that uses HTTP* instead of RESXCH_*.
