Mailing List Archive

On Mon, Jul 20, 2020 at 02:39:48PM -0000, Grant Edwards wrote:
> During my regular update, I see that net-dns/bind-tools is upgrading
> from 9.14 to 9.16, and that's triggering the installation of _17_ new
> packages (all apparently related to sphinx and Babel).
>
> Is this sort of dependency bloat really necessary?
>
> The "doc" flag for bind-tools is not set, so why does it demand that
> sphinx be installed?

Sphinx is required (BDEPEND [1]) to build the man page, as commented in the
ebuild [2]:

# sphinx required for man-page and html creation
BDEPEND="${PYTHON_DEPS}
dev-python/sphinx
virtual/pkgconfig"

> Does bind-tools really need packages like sphinxcontrib-qthelp,
> sphinxcontrib-applehelp, sphinxcontrib-jsmath, sphinxcontrib-htmlhelp?

All of these are unfortunate consequences of Sphinx's hefty dependency list [3].
It seems that as the manual pages are installed with the package (regardless of
the `doc` USE-flag), there is no way of mitigating this dependency bloat with
the bind-tools 9.16 series. Hopefully this can be addressed by the developers in
future.

[1] https://devmanual.gentoo.org/general-concepts/dependencies/#build-dependencies
[2] https://gitweb.gentoo.org/repo/gentoo.git/tree/net-dns/bind-tools/bind-tools-9.16.4.ebuild#n39
[3] https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-python/sphinx/sphinx-3.1.2.ebuild#n23

--

Ashley Dixon
suugaku.co.uk

2A9A 4117
DA96 D18A
8A7B B0D2
A30E BF25
F290 A8AA

On Mon, 20 Jul 2020 15:52:56 +0100, Ashley Dixon wrote:

> > Does bind-tools really need packages like sphinxcontrib-qthelp,
> > sphinxcontrib-applehelp, sphinxcontrib-jsmath,
> > sphinxcontrib-htmlhelp?
>
> All of these are unfortunate consequences of Sphinx's hefty dependency
> list [3]. It seems that as the manual pages are installed with the
> package (regardless of the `doc` USE-flag),

That's to be expected, the doc flag is supposed to control the
installation of extra documentation.

> there is no way of
> mitigating this dependency bloat with the bind-tools 9.16 series.
> Hopefully this can be addressed by the developers in future.

Including the man page in the files directory would avoid this, although
I don't know if this is considered good practice.


--
Neil Bothwick

Man and mouse are alike, both end up in pussy :)

On Mon 20 Jul 2020 16:20:47 GMT, Neil Bothwick wrote:
> Including the man page in the files directory would avoid this, although
> I don't know if this is considered good practice.

Perhaps adding a man use flag which enabled by default?

--
Alarig

On Mon, 20 Jul 2020 17:31:04 +0200, Alarig Le Lay wrote:

> > Including the man page in the files directory would avoid this,
> > although I don't know if this is considered good practice.
>
> Perhaps adding a man use flag which enabled by default?

i don't think that's the issue. The problem is that the man pages are not
included in the upstream package, only the source for them. So if you
want to be able to RTFM, you need a load of dependencies.


--
Neil Bothwick

"Daddy, what does formatting drive 'C' mean?

On Mon, Jul 20, 2020 at 04:36:05PM +0100, Neil Bothwick wrote:
> i don't think that's the issue. The problem is that the man pages are not
> included in the upstream package, only the source for them. So if you
> want to be able to RTFM, you need a load of dependencies.

Perhaps a solution from upstream would be to distribute a simplified groff man
page with the program, and then the package managers could enable the
documentation requiring Sphinx only when the `doc` flag is set.

It seems like pre-9.16 versions distributed a lot of basic man pages for all the
various tools [1]. These have disappeared in recent versions.

$ find bind-9.14.12/ -regextype sed -regex "^.*[a-zA-Z][^0-9]*\.[0-9]$" -type f

bind-9.14.12/bin/dnssec/dnssec-dsfromkey.8
bind-9.14.12/bin/dnssec/dnssec-verify.8
bind-9.14.12/bin/dnssec/dnssec-importkey.8
bind-9.14.12/bin/dnssec/dnssec-keygen.8
bind-9.14.12/bin/dnssec/dnssec-revoke.8
bind-9.14.12/bin/dnssec/dnssec-cds.8
bind-9.14.12/bin/dnssec/dnssec-signzone.8
bind-9.14.12/bin/dnssec/dnssec-keyfromlabel.8
bind-9.14.12/bin/dnssec/dnssec-settime.8
bind-9.14.12/bin/delv/delv.1
bind-9.14.12/bin/tests/system/checkconf/dnssec.3
bind-9.14.12/bin/tests/system/checkconf/dnssec.2
bind-9.14.12/bin/tests/system/checkconf/dnssec.1
bind-9.14.12/bin/tests/system/statschannel/traffic.expect.5
bind-9.14.12/bin/tests/system/statschannel/traffic.expect.6
bind-9.14.12/bin/tests/system/statschannel/traffic.expect.2
bind-9.14.12/bin/tests/system/statschannel/traffic.expect.4
bind-9.14.12/bin/tests/system/statschannel/traffic.expect.1
bind-9.14.12/bin/tests/system/addzone/ns2/redirect.db.1
bind-9.14.12/bin/tests/system/addzone/ns2/redirect.db.2
bind-9.14.12/bin/tests/system/addzone/ns1/redirect.db.1
bind-9.14.12/bin/tests/system/addzone/ns1/redirect.db.2
bind-9.14.12/bin/tests/system/addzone/ns3/redirect.db.1
bind-9.14.12/bin/tests/system/addzone/ns3/redirect.db.2
bind-9.14.12/bin/confgen/ddns-confgen.8
bind-9.14.12/bin/confgen/rndc-confgen.8
bind-9.14.12/bin/named/named.conf.5
bind-9.14.12/bin/named/named.8
bind-9.14.12/bin/python/dnssec-checkds.8
bind-9.14.12/bin/python/dnssec-keymgr.8
bind-9.14.12/bin/python/dnssec-coverage.8
bind-9.14.12/bin/dig/host.1
bind-9.14.12/bin/dig/dig.1
bind-9.14.12/bin/dig/nslookup.1
bind-9.14.12/bin/check/named-checkzone.8
bind-9.14.12/bin/check/named-checkconf.8
bind-9.14.12/bin/tools/named-journalprint.8
bind-9.14.12/bin/tools/mdig.1
bind-9.14.12/bin/tools/dnstap-read.1
bind-9.14.12/bin/tools/named-rrchecker.1
bind-9.14.12/bin/tools/nsec3hash.8
bind-9.14.12/bin/tools/arpaname.1
bind-9.14.12/bin/tools/named-nzd2nzf.8
bind-9.14.12/bin/plugins/filter-aaaa.8
bind-9.14.12/bin/nsupdate/nsupdate.1
bind-9.14.12/bin/pkcs11/pkcs11-keygen.8
bind-9.14.12/bin/pkcs11/pkcs11-tokens.8
bind-9.14.12/bin/pkcs11/pkcs11-list.8
bind-9.14.12/bin/pkcs11/pkcs11-destroy.8
bind-9.14.12/bin/rndc/rndc.conf.5
bind-9.14.12/bin/rndc/rndc.8
bind-9.14.12/isc-config.sh.1

$ find bind-9.16.4/ -regextype sed -regex "^.*[a-zA-Z][^0-9]*\.[0-9]$" -type f

bind-9.16.4/bin/tests/system/checkconf/dnssec.3
bind-9.16.4/bin/tests/system/checkconf/dnssec.2
bind-9.16.4/bin/tests/system/checkconf/dnssec.1
bind-9.16.4/bin/tests/system/statschannel/traffic.expect.5
bind-9.16.4/bin/tests/system/statschannel/traffic.expect.6
bind-9.16.4/bin/tests/system/statschannel/traffic.expect.2
bind-9.16.4/bin/tests/system/statschannel/traffic.expect.4
bind-9.16.4/bin/tests/system/statschannel/traffic.expect.1
bind-9.16.4/bin/tests/system/addzone/ns2/redirect.db.1
bind-9.16.4/bin/tests/system/addzone/ns2/redirect.db.2
bind-9.16.4/bin/tests/system/addzone/ns1/redirect.db.1
bind-9.16.4/bin/tests/system/addzone/ns1/redirect.db.2
bind-9.16.4/bin/tests/system/addzone/ns3/redirect.db.1
bind-9.16.4/bin/tests/system/addzone/ns3/redirect.db.2

[1] https://downloads.isc.org/isc/bind9/9.14.12/bind-9.14.12.tar.gz

--

Ashley Dixon
suugaku.co.uk

2A9A 4117
DA96 D18A
8A7B B0D2
A30E BF25
F290 A8AA

On 2020-07-20 11:31, Alarig Le Lay wrote:
> On Mon 20 Jul 2020 16:20:47 GMT, Neil Bothwick wrote:
>> Including the man page in the files directory would avoid this, although
>> I don't know if this is considered good practice.
>
> Perhaps adding a man use flag which enabled by default?
>

The return-on-investment is too low, since we'd have to hack every
upstream build system to support it, and almost everyone wants the man
pages anyway. They're tiny, and the package is often unusable without them.

These are build-only dependencies so "emerge --depclean" can remove them
after you install bind-tools. In a source-based distro, you should
probably just get comfortable with having a million build tools
installed though.

On 2020-07-20, Michael Orlitzky <mjo@gentoo.org> 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

On 2020-07-21 13:08:16, Grant Edwards wrote:
> On 2020-07-20, Michael Orlitzky <mjo@gentoo.org> 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.

On Tue, 21 Jul 2020 13:08:16 -0000 (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

On 2020-07-21, Neil Bothwick <neil@digimed.co.uk> wrote:
> On Tue, 21 Jul 2020 13:08:16 -0000 (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

On Tue, 21 Jul 2020 15:03:41 -0000 (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?

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.

On 2020-07-21, Peter Humphrey <peter@prh.myzen.co.uk> 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

On 2020-07-21, Grant Edwards <grant.b.edwards@gmail.com> wrote:
> On 2020-07-21, Peter Humphrey <peter@prh.myzen.co.uk> 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

On Tue, Jul 21, 2020 at 04:00:21PM -0000, 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 <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

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

On 2020-07-22, Walter Dnes <waltdnes@waltdnes.org> wrote:
> On Tue, Jul 21, 2020 at 04:00:21PM -0000, 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

On Wed, Jul 22, 2020 at 02:29:48AM -0000, 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

On Wed, Jul 22, 2020 at 02:29:48AM -0000, Grant Edwards wrote
> On 2020-07-22, Walter Dnes <waltdnes@waltdnes.org> 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 <appname>" 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 <appname>" I did "emerge pv <appname>" which
has a *TOTALLY* different meaning.

--
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

On Tuesday, 21 July 2020 16:23:35 BST 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!

And woe! Sphinx is pulled back in again by llvm today. :(

# less $(equery w llvm)
RDEPEND
--->8
$(python_gen_any_dep '
dev-python/sphinx[${PYTHON_USEDEP}]
doc? ( dev-python/recommonmark[${PYTHON_USEDEP}] )
')"

So it doesn't even depend on the doc USE flag.

--
Regards,
Peter.

On 2020-07-22, Ashley Dixon <ash@suugaku.co.uk> wrote:
> On Wed, Jul 22, 2020 at 02:29:48AM -0000, 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]

Right. Contrary to what the news article says, you can not just enable
'suid' on xorg-server and run without consolekit/elogind/systemd.

--
Grant

On 2020-07-22, Walter Dnes <waltdnes@waltdnes.org> wrote:

>> >> 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)

Except starting yesterday, pam no longer allows that.

> BTW, I have pam totally masked out...

I used to run without pam, but something required it a while back.

Maybe I should look into removing pam again.

--
Grant

On Wed, Jul 22, 2020 at 01:25:01PM -0000, Grant Edwards wrote
> On 2020-07-22, Ashley Dixon <ash@suugaku.co.uk> wrote:
> > On Wed, Jul 22, 2020 at 02:29:48AM -0000, 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".
>
> Right. Contrary to what the news article says, you can not just enable
> 'suid' on xorg-server and run without consolekit/elogind/systemd.

I'm doing that right now, so yes it does work. Please re-read Ashley
Dixon's post... "zero or one of". I have zero of them set.

--
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

On Wed, Jul 22, 2020 at 09:46:34AM +0100, Peter Humphrey wrote
>
> So it doesn't even depend on the doc USE flag.
>
Strange. On my system...

==================================================================

USE="-doc" emerge -pv llvm

[i660][root][~] USE="-doc" emerge -pv llvm

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild N ] sys-devel/llvm-common-10.0.0::gentoo 117,974 KiB
[ebuild N ] sys-devel/llvm-10.0.0:10::gentoo USE="libffi ncurses -debug -doc -exegesis -gold -libedit -test -xar -xml -z3" LLVM_TARGETS="AMDGPU BPF NVPTX (X86) -AArch64 -ARC -ARM -AVR -Hexagon -Lanai -MSP430 -Mips -PowerPC -RISCV -Sparc -SystemZ -WebAssembly -XCore" 173 KiB

====================================================================

USE="doc" emerge -pv llvm

These are the packages that would be merged, in order:

Calculating dependencies... done!

emerge: there are no ebuilds built with USE flags to satisfy ">=media-libs/gd-2.0.34:=[fontconfig,jpeg,png,truetype,zlib]".
!!! One of the following packages is required to complete your request:
- media-libs/gd-2.3.0::gentoo (Change USE: +fontconfig)
(dependency required by "media-gfx/graphviz-2.42.3::gentoo" [ebuild])
(dependency required by "dev-python/sphinx-3.0.4::gentoo[doc]" [ebuild])
(dependency required by "sys-devel/llvm-10.0.0::gentoo[doc]" [ebuild])
(dependency required by "llvm" [argument])

====================================================================

It looks like "doc" is set somewhere in one of...

- make.conf
- package.use
- your profile
- default inherited by the llvm ebuild

I've just added "-doc" to USE in make.conf. It's now up to...

USE="10bit X apng ffmpeg jpeg opengl png szip truetype x264 x265 xorg threads webp -acl -arping -berkdb -bindist -caps -cracklib -crypt -doc -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 <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications