Re: [gentoo-dev] MANPATH handling in ebuilds

2017-01-19 Thread Mike Gilbert 
On Thu, Jan 19, 2017 at 8:45 AM, Gilles Dartiguelongue  wrote:
> Le mercredi 04 janvier 2017 à 21:12 +, Wolfgang Mueller a écrit :
>> is definitely not set when executing cron scripts like that. I
>> deleted all mandoc.db files and waited for them to be regenerated.
>> Only
>> the one in /usr/share/man was generated, which means that makewhatis
>> fell back to the defaults since MANPATH was empty.
>>
>> Just as I am composing this mail, the cron script that had `source
>> /etc/profile' in it before makewhatis ran, and all the databases are
>> there.
>>
>> Bottom line: MANPATH is not available in cron scripts.
>
> Could you open a bug report on https://bugzilla.gentoo.org/, I think
> this could be a very long standing bug.

It's debatable whether this is a "bug" or not; I don't think it really is.

crontab(1p) says this:

   Upon execution of a command from a crontab entry,  the  implementa‐
   tion shall supply a default environment, defining at least the fol‐
   lowing environment variables:

   HOME  A pathname of the user's home directory.

   LOGNAME   The user's login name.

   PATH  A string representing a search path  guaranteed  to  find
 all of the standard utilities.

   SHELL A  pathname  of  the command interpreter. When crontab is
 invoked as specified by this volume of POSIX.1‐2008,  the
 value shall be a pathname for sh.

If a script executed by cron needs additional env vars, it should
probably source /etc/profile or /etc/profile.env itself.

Re: [gentoo-dev] MANPATH handling in ebuilds

2017-01-19 Thread Gilles Dartiguelongue 
Le mercredi 04 janvier 2017 à 21:12 +, Wolfgang Mueller a écrit :
> is definitely not set when executing cron scripts like that. I
> deleted all mandoc.db files and waited for them to be regenerated.
> Only
> the one in /usr/share/man was generated, which means that makewhatis
> fell back to the defaults since MANPATH was empty.
> 
> Just as I am composing this mail, the cron script that had `source
> /etc/profile' in it before makewhatis ran, and all the databases are
> there.
> 
> Bottom line: MANPATH is not available in cron scripts.

Could you open a bug report on https://bugzilla.gentoo.org/, I think
this could be a very long standing bug.

-- 
Gilles Dartiguelongue 

signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] MANPATH handling in ebuilds

2017-01-04 Thread Wolfgang Mueller 
> I have only tested this manually with run-parts, so I shall put it in
> cron.hourly right now and report back later.

MANPATH is definitely not set when executing cron scripts like that. I
deleted all mandoc.db files and waited for them to be regenerated. Only
the one in /usr/share/man was generated, which means that makewhatis
fell back to the defaults since MANPATH was empty.

Just as I am composing this mail, the cron script that had `source
/etc/profile' in it before makewhatis ran, and all the databases are
there.

Bottom line: MANPATH is not available in cron scripts.

-- 
Wolfgang Mueller / vehk.de / GPG 0xc543cfce9465f573


signature.asc
Description: PGP signature

Re: [gentoo-dev] MANPATH handling in ebuilds

2017-01-04 Thread Wolfgang Mueller 
> You shouldn't call those tools inside ebuild. If the build system is
> doing that, patch it out. In fact, I'm surprised sandbox doesn't catch
> this as an attempt to write outside allowed paths.

Okay, I shall remove any calls to database creation and just alert the
user.

> Are you sure this happens in cron.daily entries as well? I'd say cron
> should be respecting profile environment one way or another.

For man-db it does not matter, since it does not use MANPATH to get
the right directories (instead uses /etc/man_db.conf). I am quite sure
it happens to me with mdocml (without sourcing /etc/profile in the
cron.daily script it ignores gcc's and binutils' man pages). I have only
tested this manually with run-parts, so I shall put it in cron.hourly
right now and report back later. fwiw printing env to a file from a
cron.daily script run manually with run-parts results in an environment
without MANPATH set. Presumably because it is not a login shell, and
/etc/profile is not sourced.

-- 
Wolfgang Mueller / vehk.de / GPG 0xc543cfce9465f573


signature.asc
Description: PGP signature

Re: [gentoo-dev] MANPATH handling in ebuilds

2017-01-04 Thread Michał Górny 
On Wed, 4 Jan 2017 16:45:56 +
Wolfgang Mueller  wrote:

> While working on an mdocml ebuild, I noticed that a call to `makewhatis'
> for mdocml or the corresponding `mandb' call for sys-apps/man-db does
> not create entries for gcc's or binutils' man pages. This is because
> the MANPATH environment is suppressed in ebuilds. I asked about this
> in #gentoo-dev-help, but did not get an answer as to why MANPATH is
> suppressed.

You shouldn't call those tools inside ebuild. If the build system is
doing that, patch it out. In fact, I'm surprised sandbox doesn't catch
this as an attempt to write outside allowed paths.

> What's the best way to handle with this in ebuilds (and the
> corresponding cron.daily entries)? Sourcing /etc/profile seems like
> a terrible hack to me. For what it's worth, sys-apps/man-db does not
> alert the user that gcc and binutils (and /usr/local/share/man) will be
> missing from apropos entries.

Are you sure this happens in cron.daily entries as well? I'd say cron
should be respecting profile environment one way or another.

-- 
Best regards,
Michał Górny



pgpfDE3s5eLRO.pgp
Description: OpenPGP digital signature

[gentoo-dev] MANPATH handling in ebuilds

2017-01-04 Thread Wolfgang Mueller 
Hi,

While working on an mdocml ebuild, I noticed that a call to `makewhatis'
for mdocml or the corresponding `mandb' call for sys-apps/man-db does
not create entries for gcc's or binutils' man pages. This is because
the MANPATH environment is suppressed in ebuilds. I asked about this
in #gentoo-dev-help, but did not get an answer as to why MANPATH is
suppressed.

What's the best way to handle with this in ebuilds (and the
corresponding cron.daily entries)? Sourcing /etc/profile seems like
a terrible hack to me. For what it's worth, sys-apps/man-db does not
alert the user that gcc and binutils (and /usr/local/share/man) will be
missing from apropos entries.

See also my mail on gentoo-user about this:
https://archives.gentoo.org/gentoo-user/message/83293ea8876e5a8c80cfde4240d392c2

-- 
Wolfgang Mueller / vehk.de / GPG 0xc543cfce9465f573


signature.asc
Description: PGP signature