Re: [gentoo-user] repoint virtual/rust to rust instead of rust-bin
On Tue, Jul 21, 2020 at 6:29 PM Neil Bothwick wrote: > > You have emerged rust-145 from testing but portage wants to install > virtual/rust-1.44.1 from stable. This looks like a keywording issue. > > Are you running stable or testing? Do you have anything rust-related in > package.accept_keywords? > No, nothing in /etc/portage/* System is testing/~amd64. However, qlop shows the last rust-bin installed was actually 1.38, whereas my memory was that it was 1.44, so i have mixed up two different systems. I can't see anything in roots history that would have caused the issue. FWIW if i mask dev-lang/rust-bin it wants to [ebuild UD ] dev-lang/rust-1.44.1:stable/1.44::gentoo [1.45.0:stable/1.45::gentoo] USE="-clippy -debug -doc -libressl (-miri) -nightly -parallel-compiler -rls -rustfmt -system-bootstrap -system-llvm -wasm" ABI_X86="(64) -32 (-x32)" CPU_FLAGS_X86="sse2" LLVM_TARGETS="AMDGPU (X86) -AArch64 -ARM -BPF -Hexagon -Lanai -MSP430 -Mips -NVPTX -PowerPC -RISCV -Sparc -SystemZ -WebAssembly -XCore" 0 KiB [ebuild UD ] virtual/rust-1.44.1::gentoo [1.45.0::gentoo] ABI_X86="(64) -32 (-x32)" 0 KiB No idea what's pulling in rust-1.44.1 # emerge -pv --depclean virtual/rust Calculating dependencies... done! virtual/rust-1.45.0 pulled in by: dev-util/cbindgen-0.14.3 requires >=virtual/rust-1.37.0, =virtual/rust-1.45.0 mail-client/thunderbird-68.10.0 requires >=virtual/rust-1.34.0, =virtual/rust-1.45.0 www-client/firefox-78.0.2 requires >=virtual/rust-1.41.0, =virtual/rust-1.45.0 Added the following to package.mask and world will update without complaint dev-lang/rust-bin
[gentoo-user] Simple replacement for "getmail"?
I've been using "getmail" for years to pull down email from multiple
popmail accounts and pass the emails to procmail for processing. It's
being masked because of hard-coded python 2.7 dependancy. "fetchmail"
looks promising. The stable version net-mail/fetchmail-6.4.1 also
requires python 2.7 *IF THE "tk" FLAG IS SET*.
PYTHON_COMPAT=( python2_7 )
PYTHON_REQ_USE="tk"
Version 6.4.6 says...
PYTHON_COMPAT=( python3_{6,7,8} )
PYTHON_REQ_USE="tk"
...and agin it seems to only be required if built with "tk" flag. Once
fetchmail version 6.4.6 is marked stable, python should not be a problem,
and I don't expect to build with the "tk" flag anyways.
Would "fetchmail" work as a drop-in replacement for getmail here? Are
there any better, simpler solutions?
--
Walter Dnes
I don't run "desktop environments"; I run useful applications
Re: [gentoo-user] Re: dns/bind-tools 9.14 -> 9.16 pulling in 17 new dependencies?!
On Wed, Jul 22, 2020 at 02:29:48AM -, Grant Edwards wrote > On 2020-07-22, Walter Dnes wrote: > > > > According to news item > > https://www.gentoo.org/support/news-items/2020-06-24-xorg-server-dropping-default-suid.html > > > > * xorg-server will no longer be "suid" *BY DEFAULT* > > * that means *THE DEFAULT* is to require a logind server like systemd > > or elogind > > > > The news item also says... > > > >> Users who do not wish to use logind interface or have rare hardware > >> that does not use KMS and because of that, require root privileges > >> to operate, can manually re-enable 'suid' and disable 'elogind' USE > >> flags in order to preserve the previous behavior. > > Yes, that's what I did months ago, and everything worked fine with > Xorg using the "suid" flag and without consolekit or elogind -- until > this morning, when pam refused to upgrade unless I set the elogind USE > flag. The news item said that to retain old behaviour you need to do *BOTH* - set x11-base/xorg-server suid (which I did in package.use) - set "-elogind" (which I did in USE in make.conf) BTW, I have pam totally masked out... [i660][root][~] cat /etc/portage/package.mask/package.mask sys-apps/pv sys-auth/pambase sys-libs/pam virtual/pam Years ago, back when pam was default on the Gentoo install, it was to many users what HAL was to Dale, causing problems galore. The root of the problem was that pam provided "enhanced security" for some apps by changing to a different config file for the app, using different config specs. You could run "man " and do all the Google searches you wanted, but you always ended up with instructions for configuring the "un-pam-ified" version, not the "pam-ified" version. "Everything you know is wrong". So I fell into the habit of removing pam right after installation. And the reason I mask out "sys-apps/pv" is because too many times when I want to run "emerge -pv " I did "emerge pv " which has a *TOTALLY* different meaning. -- Walter Dnes I don't run "desktop environments"; I run useful applications
Re: [gentoo-user] Re: dns/bind-tools 9.14 -> 9.16 pulling in 17 new dependencies?!
On Wed, Jul 22, 2020 at 02:29:48AM -, Grant Edwards wrote: > Yes, that's what I did months ago, and everything worked fine with > Xorg using the "suid" flag and without consolekit or elogind -- until > this morning, when pam refused to upgrade unless I set the elogind USE > flag. Look at REQUIRED_USE in sys-auth/pambase ebuild [1]: REQUIRED_USE="?? ( consolekit elogind systemd )" I.e., "zero or one of `consolekit`, `elogind`, or `systemd` must be set, but not several". [2] Run `quse -Ip sys-auth/pambase | grep -E 'consolekit|elogind|systemd'` to check the USE-flags with which you're asking Portage to build pambase. [1] https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-auth/pambase/pambase-20200618.ebuild#n19 [2] https://devmanual.gentoo.org/ebuild-writing/variables/index.html#eapi-5 -- Ashley Dixon suugaku.co.uk 2A9A 4117 DA96 D18A 8A7B B0D2 A30E BF25 F290 A8AA signature.asc Description: PGP signature
[gentoo-user] Re: dns/bind-tools 9.14 -> 9.16 pulling in 17 new dependencies?!
On 2020-07-22, Walter Dnes wrote:
> On Tue, Jul 21, 2020 at 04:00:21PM -, Grant Edwards wrote
>>
>> Before I can try that, I apparently have to enable the elogind USE
>> flag because of somthing else that changed since I sync'ed yesterday.
>>
>> That only requires 6 new packages (two of them are
>> acct-{user,group}/polkitd, so it's only 4 new "real" packages. Of
>> course every self-respecting package needs to install at least one new
>> programming language -- this time it's dev-lang/spidermonkey. :/
>>
>> Sheesh.
>
> According to news item
> https://www.gentoo.org/support/news-items/2020-06-24-xorg-server-dropping-default-suid.html
>
> * xorg-server will no longer be "suid" *BY DEFAULT*
> * that means *THE DEFAULT* is to require a logind server like systemd
> or elogind
>
> The news item also says...
>
>> Users who do not wish to use logind interface or have rare hardware
>> that does not use KMS and because of that, require root privileges
>> to operate, can manually re-enable 'suid' and disable 'elogind' USE
>> flags in order to preserve the previous behavior.
Yes, that's what I did months ago, and everything worked fine with
Xorg using the "suid" flag and without consolekit or elogind -- until
this morning, when pam refused to upgrade unless I set the elogind USE
flag.
--
Grant
Re: [gentoo-user] Re: dns/bind-tools 9.14 -> 9.16 pulling in 17 new dependencies?!
On Tue, Jul 21, 2020 at 09:30:07PM -0400, Walter Dnes wrote: > According to news item > https://www.gentoo.org/support/news-items/2020-06-24-xorg-server-dropping-default-suid.html > > * xorg-server will no longer be "suid" *BY DEFAULT* > * that means *THE DEFAULT* is to require a logind server like systemd > or elogind > > The news item also says... > > > Users who do not wish to use logind interface or have rare hardware > > that does not use KMS and because of that, require root privileges > > to operate, can manually re-enable 'suid' and disable 'elogind' USE > > flags in order to preserve the previous behavior. However, please > > note that this is heavily discouraged to run X server as root due > > to security reasons. The 'suid' USE flag will remain as optional > > opt-in for the need of legacy hardware. > > I've set "x11-base/xorg-server glamor suid udev xorg" in package.use > and "-elogind" in make.conf, and no additional packages are required. I > used to start with USE="-*" but I don't do that anymore. Instead I use > > USE="10bit X apng ffmpeg jpeg opengl png szip truetype x264 x265 xorg threads > webp -acl -arping -berkdb -bindist -caps -cracklib -crypt -elogind -filecaps > -gallium -gdbm -graphite -iconv -introspection -ipc -iptables -ipv6 -libav > -libglvnd -llvm -manpager -nls -openmp -pam -pch -sendmail -tcpd -udev -udisks > -unicode -xinerama" There was a big argument about it over on Gentoo-Dev. It essentially reduced to the point that although most Gentoo users are still going to want "suid" (in the absence of systemd/elogind or another fancy login manager), Portage should provide good, non-anti-pattern, secure defaults for _new_ users, however much of an inconvenience it may be for existing users who run X with `startx`. I generally agree with them on this point; "suid" is horribly outdated, however ubiquitous (especially for minimalist systems). https://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg89536.html -- Ashley Dixon suugaku.co.uk 2A9A 4117 DA96 D18A 8A7B B0D2 A30E BF25 F290 A8AA signature.asc Description: PGP signature
Re: [gentoo-user] Re: dns/bind-tools 9.14 -> 9.16 pulling in 17 new dependencies?!
On Tue, Jul 21, 2020 at 04:00:21PM -, Grant Edwards wrote
>
> Before I can try that, I apparently have to enable the elogind USE
> flag because of somthing else that changed since I sync'ed yesterday.
>
> That only requires 6 new packages (two of them are
> acct-{user,group}/polkitd, so it's only 4 new "real" packages. Of
> course every self-respecting package needs to install at least one new
> programming language -- this time it's dev-lang/spidermonkey. :/
>
> Sheesh.
According to news item
https://www.gentoo.org/support/news-items/2020-06-24-xorg-server-dropping-default-suid.html
* xorg-server will no longer be "suid" *BY DEFAULT*
* that means *THE DEFAULT* is to require a logind server like systemd
or elogind
The news item also says...
> Users who do not wish to use logind interface or have rare hardware
> that does not use KMS and because of that, require root privileges
> to operate, can manually re-enable 'suid' and disable 'elogind' USE
> flags in order to preserve the previous behavior. However, please
> note that this is heavily discouraged to run X server as root due
> to security reasons. The 'suid' USE flag will remain as optional
> opt-in for the need of legacy hardware.
I've set "x11-base/xorg-server glamor suid udev xorg" in package.use
and "-elogind" in make.conf, and no additional packages are required. I
used to start with USE="-*" but I don't do that anymore. Instead I use
USE="10bit X apng ffmpeg jpeg opengl png szip truetype x264 x265 xorg threads
webp -acl -arping -berkdb -bindist -caps -cracklib -crypt -elogind -filecaps
-gallium -gdbm -graphite -iconv -introspection -ipc -iptables -ipv6 -libav
-libglvnd -llvm -manpager -nls -openmp -pam -pch -sendmail -tcpd -udev -udisks
-unicode -xinerama"
--
Walter Dnes
I don't run "desktop environments"; I run useful applications
[gentoo-user] Re: dns/bind-tools 9.14 -> 9.16 pulling in 17 new dependencies?!
On 2020-07-21, Grant Edwards wrote: > On 2020-07-21, Peter Humphrey wrote: >> On Tuesday, 21 July 2020 15:47:25 BST Neil Bothwick wrote: >> >>> Sync, re-emerge bind-tools and try again. The man pages are now >>> downloaded as a separate tarball, so Sphinx and deps are not longer >>> needed. >> >> And lo! 17 packages were removed by depclean! > > Before I can try that, I apparently have to enable the elogind USE > flag because of somthing else that changed since I sync'ed > yesterday. That only requires 6 new packages [...] After that, X wouldn't start... another half-hour of googling and experimentation... switch my 'x' alias from using 'xinit' to 'startx', and now X is working again. ... and emerge --depclean removes all of the sphinx packages along with Babel, jinja, and a few others! So, I gained back the ground I lost yesterday to bind-tools, but lost some ground to elogind et alia. -- Grant
[gentoo-user] Re: dns/bind-tools 9.14 -> 9.16 pulling in 17 new dependencies?!
On 2020-07-21, Peter Humphrey wrote:
> On Tuesday, 21 July 2020 15:47:25 BST Neil Bothwick wrote:
>
>> Sync, re-emerge bind-tools and try again. The man pages are now
>> downloaded as a separate tarball, so Sphinx and deps are not longer
>> needed.
>
> And lo! 17 packages were removed by depclean!
Before I can try that, I apparently have to enable the elogind USE flag
because of somthing else that changed since I sync'ed yesterday.
That only requires 6 new packages (two of them are
acct-{user,group}/polkitd, so it's only 4 new "real" packages. Of
course every self-respecting package needs to install at least one new
programming language -- this time it's dev-lang/spidermonkey. :/
Sheesh.
--
Grant
Re: [gentoo-user] Re: dns/bind-tools 9.14 -> 9.16 pulling in 17 new dependencies?!
On Tuesday, 21 July 2020 15:47:25 BST Neil Bothwick wrote: > Sync, re-emerge bind-tools and try again. The man pages are now > downloaded as a separate tarball, so Sphinx and deps are not longer > needed. And lo! 17 packages were removed by depclean! -- Regards, Peter.
Re: [gentoo-user] Re: dns/bind-tools 9.14 -> 9.16 pulling in 17 new dependencies?!
On Tue, 21 Jul 2020 15:03:41 - (UTC), Grant Edwards wrote: > > The man pages are now downloaded as a separate tarball, so Sphinx > > and deps are not longer needed. > > Wow, that's impressive service! One nit-picking, whiney post on the > mailing list and the "problem" gets fixed in a matter of hours. :) Give some credit to the person that suggested including pre-compiled man pages, whoever that was... -- Neil Bothwick How do you know when it's time to tune your bagpipes? pgpFbzhAgwltf.pgp Description: OpenPGP digital signature
[gentoo-user] Re: dns/bind-tools 9.14 -> 9.16 pulling in 17 new dependencies?!
On 2020-07-21, Neil Bothwick wrote: > On Tue, 21 Jul 2020 13:08:16 - (UTC), Grant Edwards wrote: > >> > These are build-only dependencies so "emerge --depclean" can remove >> > them after you install bind-tools. >> >> Except it doesn't. I did an "emerge --depclean" after updating >> bind-tools, and sphinx et al were not removed. > > Sync, re-emerge bind-tools and try again. I will as soon as yesterday's emerge -auvND finishes. Chromium got updated, and that build time is measured in days rather than minutes. > The man pages are now downloaded as a separate tarball, so Sphinx > and deps are not longer needed. Wow, that's impressive service! One nit-picking, whiney post on the mailing list and the "problem" gets fixed in a matter of hours. :) -- Grant
Re: [gentoo-user] Re: dns/bind-tools 9.14 -> 9.16 pulling in 17 new dependencies?!
On Tue, 21 Jul 2020 13:08:16 - (UTC), Grant Edwards wrote: > > These are build-only dependencies so "emerge --depclean" can remove > > them after you install bind-tools. > > Except it doesn't. I did an "emerge --depclean" after updating > bind-tools, and sphinx et al were not removed. Sync, re-emerge bind-tools and try again. The man pages are now downloaded as a separate tarball, so Sphinx and deps are not longer needed. -- Neil Bothwick SITCOM: Single Income, Two Children, Oppressive Mortgage pgp4NwdiMzCRb.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Re: dns/bind-tools 9.14 -> 9.16 pulling in 17 new dependencies?!
On 2020-07-21 13:08:16, Grant Edwards wrote: > On 2020-07-20, Michael Orlitzky wrote: > > > These are build-only dependencies so "emerge --depclean" can remove them > > after you install bind-tools. > > Except it doesn't. I did an "emerge --depclean" after updating > bind-tools, and sphinx et al were not removed. > The logic (and documentation) is incomprehensible to me, but this behavior depends on --with-bdeps and some related arguments to emerge.
[gentoo-user] Re: dns/bind-tools 9.14 -> 9.16 pulling in 17 new dependencies?!
On 2020-07-20, Michael Orlitzky wrote: > These are build-only dependencies so "emerge --depclean" can remove them > after you install bind-tools. Except it doesn't. I did an "emerge --depclean" after updating bind-tools, and sphinx et al were not removed. -- Grant
Re: [gentoo-user] repoint virtual/rust to rust instead of rust-bin
When you sorted out the mentioned keywording issues: To tell portage to ignore rust-bin as a valid dependency for virtual/rust simply put "dev-lang/rust-bin" in your "/etc/portage/pckage.mask" Franz On Tue Jul 21 17:49:12 2020, Adam Carter wrote: > I've unmerged rust-bin, emerged rust (v1,45), then re-emerged virtual/rust > but if i run a world update it still wants to pull rust-bin back in; > > # emerge -avuD --tree world > > These are the packages that would be merged, in reverse order: > Calculating dependencies... done! > [ebuild UD ] virtual/rust-1.44.1::gentoo [1.45.0::gentoo] ABI_X86="(64) > -32 (-x32)" 0 KiB > [ebuild N ] dev-lang/rust-bin-1.44.1:stable::gentoo USE="-clippy > -doc -rustfmt" ABI_X86="(64) -32 (-x32)" CPU_FLAGS_X86="sse2" 0 KiB > > How do I clear this? > >
Re: [gentoo-user] Local mail server
On Monday, 20 July 2020 18:25:28 BST Michael Orlitzky wrote: > On 2020-07-20 12:39, antlists wrote: > > On 20/07/2020 15:55, Peter Humphrey wrote: > >> fatal: in parameter smtpd_relay_restrictions or > >> smtpd_recipient_restrictions, specify at least one working instance of: > >> reject_unauth_destination, defer_unauth_destination, reject, defer, > >> defer_if_permit or check_relay_domains --->8 > If you don't specify one of those restrictions in one of those places, > your mail server is an open relay. Postfix doesn't let you do that. > > One of them is set by default; smtpd_relay_restrictions end with > defer_unauth_destination on new installs. That command doesn't appear in my main.cf. I ended up adding the following to main.cf: --- # Allow connections from trusted networks only. smtpd_client_restrictions = permit_mynetworks, reject # Don't talk to mail systems that don't know their own hostname. smtpd_helo_restrictions = reject_unknown_helo_hostname # Don't accept mail from domains that don't exist. smtpd_sender_restrictions = reject_unknown_sender_domain smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination # Block clients that speak too early. smtpd_data_restrictions = reject_unauth_pipelining --- Those came from http://www.postfix.org/SMTPD_ACCESS_README.html. I don't know what use the page https://wiki.gentoo.org/wiki/Postfix is: it hasn't helped me at all. As usual, though, the kind people on this list certainly have! Thank you all. -- Regards, Peter.
Re: [gentoo-user] repoint virtual/rust to rust instead of rust-bin
On Tue, 21 Jul 2020 17:49:12 +1000, Adam Carter wrote: > I've unmerged rust-bin, emerged rust (v1,45), then re-emerged > virtual/rust but if i run a world update it still wants to pull > rust-bin back in; > > # emerge -avuD --tree world > > These are the packages that would be merged, in reverse order: > Calculating dependencies... done! > [ebuild UD ] virtual/rust-1.44.1::gentoo [1.45.0::gentoo] > ABI_X86="(64) -32 (-x32)" 0 KiB > [ebuild N ] dev-lang/rust-bin-1.44.1:stable::gentoo USE="-clippy > -doc -rustfmt" ABI_X86="(64) -32 (-x32)" CPU_FLAGS_X86="sse2" 0 KiB > > How do I clear this? You have emerged rust-145 from testing but portage wants to install virtual/rust-1.44.1 from stable. This looks like a keywording issue. Are you running stable or testing? Do you have anything rust-related in package.accept_keywords? -- Neil Bothwick Nostalgia isn't what it used to be. pgptzIzm_uFDR.pgp Description: OpenPGP digital signature
[gentoo-user] repoint virtual/rust to rust instead of rust-bin
I've unmerged rust-bin, emerged rust (v1,45), then re-emerged virtual/rust but if i run a world update it still wants to pull rust-bin back in; # emerge -avuD --tree world These are the packages that would be merged, in reverse order: Calculating dependencies... done! [ebuild UD ] virtual/rust-1.44.1::gentoo [1.45.0::gentoo] ABI_X86="(64) -32 (-x32)" 0 KiB [ebuild N ] dev-lang/rust-bin-1.44.1:stable::gentoo USE="-clippy -doc -rustfmt" ABI_X86="(64) -32 (-x32)" CPU_FLAGS_X86="sse2" 0 KiB How do I clear this?
