Re: [gentoo-dev] News item: Apache "-D PHP5" needs update to "-D PHP"

[Michael Orlitzky]

On 01/04/2016 12:49 PM, Rich Freeman wrote:
> 
> My understanding (which could be wrong) is that this update will break
> things even if the user never runs eselect php afterwards.  I can't
> tell you the last time I touched the php eselect module, because major
> updates to php are rare.
> 

I was going to say "no, everything should keep working" but I decided to
test a fresh upgrade before sticking my foot in my mouth. Now I know
what people are complaining about.

If you've never touched 70_mod_php5.conf, portage will remove it when
you upgrade eselect-php. That does break an existing installation until
you've run `eselect php...` and munged -DPHP5 to -DPHP. What I intended
was for 70_mod_php5.conf to stick around until you've had a chance to
deal with the configuration change. In that case everything keeps
working until after you've run eselect.

I may be able to fix that by simply including the old 70_mod_php5.conf
for backwards compatibility.

[gentoo-dev] Re: News item: Apache "-D PHP5" needs update to "-D PHP"

[Kristian Fiskerstrand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 01/04/2016 01:26 AM, Sebastian Pipping wrote:
> Hi!
> 
> 
> Better late then never.  Posting 72 hours from now the earliest as
>  advised by GLEP 42.  Feedback welcome as usual.

Do you have any timeline in place for the change happening in tree (in
particular for stable users).

> 
> Without updating APACHE2_OPTS, websites could end up serving PHP 
> code (include configuration files with passwords) unprocessed to 
> website visitors!
> 

Such a change should really be avoided if possible. Would it be
possible to have a conditional approach where either one can be used,
or maybe set the new variable/defin if the old one is used?

- -- 
Kristian Fiskerstrand
Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJWijA1AAoJECULev7WN52F/aQH/0JxIUbwzpXsY3canje+A/oo
IsfgksJIZOq3cRZNwNvnE+BBMyuQlGaJ6auuIp+er9VNwjYk2Qiq7tzAanEdVeq9
A6h+eWYu/jTI57op9n7h5k6Jy7fMU1G/YfH6KfDHaoV/mIZFjpTND3v97OvB+uAc
6jt0234PYHjFsSwyOnYZ3/p+P9GELAhGAQQWaDhh5RDdKPfpEULiVpniWbnbTFBq
evQ2dKRw6cifBfyUYcLsGstdtPsqzbjETNOeWSNLwgMMpCh7xViaTnJ1T+9rqK1L
9Jb1+xCuy7Nj6T4mbZZaDZXuGdJm9KgpzplpRR1ivv0FudwgHAbFJ8QyykjvOMA=
=KViT
-END PGP SIGNATURE-

[gentoo-portage-dev] Re: [PATCH v3] emerge: Add --autounmask-only parameter (bug 570672)

[Alexander Berntsen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Ta! After testing it a bit, I pushed it as
51f100e42753d6ffd3a24dfcb2ff8af0aa34966e.

I hope to see more patches from you! :-]

- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJWiku5AAoJENQqWdRUGk8BWJUQANaYBTWRy1FTqSsBdJDlMEzr
RlLhQYtTucNC7WOjxhZXjRLqUqalNZ99G9dOMmFnMrf8GVd8He3xbNmUCCPDQtWL
3mIRwXq3yD7+y2mMm5iL+vEJw7J2XcXLG58LhJdoLvKrMmkUkaZ/4JYgWnooevPF
ZMnIocUv39cD9IBQGt0iBjM+sK62wfMEwHJiO+x6c9x2ljs0Tckb8mxr/ScSug2f
tVpQQCqlNNxtEHnQHjjBUjtqyJ09HyvUB90aY52Bcw6smF+fvg+CXs3GuKIzCrPD
yc9VZssiDRuezU8096S8hGMuYxWHydTuQQOg4cek8TK8VNV6Ro/9AFQNxXbt/9vC
tMsCzZSc5WiiExR/wqhfcje6BHKIXPjH5cTHv7YB3Kf42+JvC5hXdkRTFG9TT0Y4
5pJf841r/M9AFRk8ETeutPLjRqhBYR4BimqTjWywp3j3iI7PpUGm5Pm7htoY4X2Z
iEC4PoUaIkxneTXghl6P16xJwhy/w0dfTX768Bu3rvxiyr03VoVcJUWjBqtC2eLp
Cki8K/rh/tiFzUWULRqg9btS78jO+PmSnm/q/AfgZ6J13BgLNmLEuW/+tApoVhd7
feX8Mnrhqw0hB1lkqW9tw3h0sQsgCNUpxK7KUWczlrKV1wTfrMckAuCksb0cGr9o
9RfLxDqpf4Qr/hcAgRKa
=2kcS
-END PGP SIGNATURE-

Re: [gentoo-dev] News item: Apache "-D PHP5" needs update to "-D PHP"

[Lars Wendler]

Hi Sebastian,

to be honest I was very upset when I first stumbled upon this problem.
And yes I only found about it when my apache webserver started to
deliver php source code instead of the real sites.
Doing such a change without getting in contact with me as apache
maintainer before the change was done is very... eh... impolite at best.

Kind regards
Lars

On Mon, 4 Jan 2016 01:26:28 +0100 Sebastian Pipping wrote:

>Hi!
>
>
>Better late then never.  Posting 72 hours from now the earliest as
>advised by GLEP 42.  Feedback welcome as usual.
>
>
>===
>Title: Apache "-D PHP5" needs update to "-D PHP"
>Author: Sebastian Pipping 
>Content-Type: text/plain
>Posted: 2016-01-04
>Revision: 1
>News-Item-Format: 1.0
>Display-If-Installed: app-eselect/eselect-php[apache2]
>
>With >=app-eselect/eselect-php-0.8.1, to enable PHP support
>for Apache 2.x file /etc/conf.d/apache2 no longer
>needs to read
>
>  APACHE2_OPTS=". -D PHP5"
>
>but
>
>  APACHE2_OPTS=". -D PHP"
>
>, i.e. without "5" at the end.  This change is related to
>unification in context of the advent of PHP 7.x.
>
>With that change, guard "" in file
>/etc/apache2/modules.d/70_mod_php.conf
>has a chance to actually pull in PHP support.
>
>Without updating APACHE2_OPTS, websites could end up serving
>PHP code (include configuration files with passwords)
>unprocessed to website visitors!
>
>
>The origin of this news item is:
>https://bugs.gentoo.org/show_bug.cgi?id=569042
>===
>
>
>Best
>
>
>
>Sebastian
>



-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39

Attention! New gpg key! See (self signed server cert for now)
http://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html


pgpbxIWSGPW86.pgp
Description: Digitale Signatur von OpenPGP

[gentoo-dev] Re: News item: Apache "-D PHP5" needs update to "-D PHP"

[Rich Freeman]

On Mon, Jan 4, 2016 at 3:41 AM, Kristian Fiskerstrand  wrote:
>
> On 01/04/2016 01:26 AM, Sebastian Pipping wrote:
>> Hi!
>>
>>
>> Better late then never.  Posting 72 hours from now the earliest as
>>  advised by GLEP 42.  Feedback welcome as usual.
>
> Do you have any timeline in place for the change happening in tree (in
> particular for stable users).

++

In particular we should avoid both of these scenarios:
1. Stable users make a change now which breaks their existing config
(because the change isn't deployed to stable yet).
2. Stable users get the news item today, and the change six months
later after they've forgotten about it.

I'm not sure whether either applies in this case.

-- 
Rich

[gentoo-portage-dev] [PATCH] repoman: filter out duplicate dependencies in error messages

[Mike Frysinger]

Some packages list the same atom multiple times (e.g. behind diff USE
flags).  If one of them throws an error, we end up listing it more than
once, and the output can get verbose/useless.
---
 pym/repoman/scanner.py | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/pym/repoman/scanner.py b/pym/repoman/scanner.py
index d1c10d7..94ada90 100644
--- a/pym/repoman/scanner.py
+++ b/pym/repoman/scanner.py
@@ -704,13 +704,22 @@ class Scanner(object):
 
# we have some 
unsolvable deps
# remove ! 
deps, which always show up as unsatisfiable
-   atoms = [
+   all_atoms = [

str(atom.unevaluated_atom)
for 
atom in atoms if not atom.blocker]
 
# if we emptied 
out our list, continue:
-   if not atoms:
+   if not 
all_atoms:
continue
+
+   # Filter out 
duplicates.  We do this by hand (rather
+   # than use a 
set) so the order is stable and better
+   # matches the 
order that's in the ebuild itself.
+   atoms = []
+   for atom in 
all_atoms:
+   if atom 
not in atoms:
+   
atoms.append(atom)
+
if 
self.options.output_style in ['column']:

self.qatracker.add_error(mykey,

"%s: %s: %s(%s) %s"
-- 
2.6.2

[gentoo-dev] Change in Gentoo ZFS packaging policy

[Richard Yao]

I have had ClusterHQ's partial stable ABI in Gentoo's packaging since
December (which helped to shake out bugs) and have just done another
update of it with various bug fixes, including many from HEAD.

Some might notice that merging a pull request that isn't fully reviewed
is a fairly big departure from the rigorous vetting that I did on
patches to ensure that every update was absolutely bug free. I had a
good span of about 3 years without Gentoo specific regressions that I
can recall.

While I did my best to avoid introducing regressions in Gentoo's ZoL
packaging, the /dev/zfs ABI has been unstable. That allowed for
potential upgrade pains such as 0.6.2 -> 0.6.3 where those with
mismatched modules and userspace code had problems. All ZoL packaging in
Gentoo has been marked as "testing" because of it. The partial stable
ABI presents offers an opportunity to change this such that users will
have the option of either stable packages (well tested and vetted) or
testing packages (vetted by me and pushed out for the community to vet
further).

In specific, the partial stable ABI should allow the following functions
to work whenever mismatches occur, provided that both the userland and
kernel code are mismatched using versions after the transition has taken
place:

- zpool import
- zpool iostat
- zpool tryimport
- zpool export
- zpool list
- zpool get
- zpool status
- zfs mount
- zfs umount
- zfs clone
- zfs snapshot
- zfs rollback
- zfs destroy
- zfs create
- zfs list
- zfs get
- zfs set
- zfs inherit
- zfs send
- zfs recv (part of stable API, but not ABI in the current code, plan to
resolve in the future)
- zfs bookmark
- zfs hold
- zfs release

It also provides convenient functions to control these operations
through libzfs_core. The man pages are a draft from a few months ago,
but include all of the non-zpool commands. This will be rectified in the
near future so that all functions are thoroughly documented.

After consulting with a few others, I decided in December to transition
Gentoo to this now in the belief that the long term benefits outweigh
the short term pain of the transition. Specifically, I want to exchange
all of the pain the /dev/zfs ABI being unstable will cause over years
for a brief period of pain now.

Having any pain at all is not ideal, but this is the first time we have
had a plan to ensure that this will be the last time (for the subset I
mentioned, things outside of it will likely be added in the future based
on need/importance).

Doing an update today to fix the regressions that were reported has
given me the opportunity to reflect on how I have handled things since
the December update. At present, I am working on multiple things and
while it is hard to keep track of every issue, I would like to minimize
the amount of pain that occurs during this transition. My plan is to
complete the transition by marking things stable 2 weeks after I stop
hearing reports of regressions.

If there are any regressions I have missed, I would like to hear about
them. Please contact me in #zfsonlinux on the freenode IRC network so
that I can resolve it ASAP. That way the regression can cut in line in
my queue and be handled faster than the regressions I missed prior to
the December code push.

Having said that, those on other distributions are welcome to the code
and to contact me about issues (please ping through freenode for the
fastest response). It can be found on github:

https://github.com/ryao/zfs/commits/gentoo-zfs-0.6.5.3-release
https://github.com/ryao/spl/commits/gentoo-spl-0.6.5.3-release

Tarballs of patches can be found here:

http://dev.gentoo.org/~ryao/dist/zfs-0.6.5.3-patches-p1.tar.xz
SHA256: 765a66adf67d0a3ae6a699561b98a5158d464e3b6ed413a72bdbbe6e6252ba66
SHA1: 56079ecd2543c44191cd747ce28a28a2bab8c064
MD5: 0a92dae487f507616e0850ee9760932f

http://dev.gentoo.org/~ryao/dist/spl-0.6.5.3-patches-p0.tar.xz
SHA256: 8e652d41eba421720bcecee99077d3f3c375153809426011f04a2c64aa181ca7
SHA1: 50cf449d7ba1772b967446bad7c12ac29fee7b6c
MD5: 6d3c2fe3bfff26f575120aac623f8dda

The ZFS shortlog:

AndCycle (1):
  Obey arc_meta_limit default size when changing arc_max

Benjamin Albrecht (1):
  Activate LVM volume groups before looking for zpools.

Brian Behlendorf (15):
  Fix maybe uninitialized
  Follow 0/-E convention for module load errors
  Fix --enable-linux-builtin
  Use large stacks when available
  Either _ILP32 or _LP64 must be defined
  Fix zfsctl_lookup_objset() deadlock
  Change zfs_snapshot_lock from mutex to rw lock
  Set 'zfs_expire_snapshot=0' to disable auto-unmount
  Hold the zfs_snapentry_t before dispatch
  Handle block pointers with a corrupt logical size
  Handle damaged blk_birth in dsl_deadlist_insert()
  Fix vdev_queue_aggregate() deadlock
  Fix zfs_vdev_aggregation_limit bounds checking
  Fix ztest truncated cache file
  Fix z_xattr_lock/z_teardown_lock inversion

Chunwei Chen (11):
  Fix fail path in 

Re: [gentoo-portage-dev] [PATCH] repoman: filter out duplicate dependencies in error messages

[Brian Dolbec]

On Mon,  4 Jan 2016 16:30:30 -0500
Mike Frysinger  wrote:

> Some packages list the same atom multiple times (e.g. behind diff USE
> flags).  If one of them throws an error, we end up listing it more
> than once, and the output can get verbose/useless.
> ---
>  pym/repoman/scanner.py | 13 +++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/pym/repoman/scanner.py b/pym/repoman/scanner.py
> index d1c10d7..94ada90 100644
> --- a/pym/repoman/scanner.py
> +++ b/pym/repoman/scanner.py
> @@ -704,13 +704,22 @@ class Scanner(object):
>  
>   # we
> have some unsolvable deps # remove ! deps, which always show up as
> unsatisfiable
> -
> atoms = [
> +
> all_atoms = [ str(atom.unevaluated_atom)
>   for
> atom in atoms if not atom.blocker] 
>   # if
> we emptied out our list, continue:
> - if
> not atoms:
> + if
> not all_atoms: continue
> +
> + #
> Filter out duplicates.  We do this by hand (rather
> + #
> than use a set) so the order is stable and better
> + #
> matches the order that's in the ebuild itself.
> +
> atoms = []
> + for
> atom in all_atoms:
> +
> if atom not in atoms:
> +
> atoms.append(atom) +
>   if
> self.options.output_style in ['column']:
> self.qatracker.add_error(mykey, "%s: %s: %s(%s) %s"


I immediately want to say REJECT!, REJECT!, REJECT!,...

I just spent a marathon week working on stage2 of the repoman rewrite.

I have all the checks and vcs related code in 2 plugin systems.  I have
to move the vcs plugins to their final destination path still (minor
move)

I am going to start cleaning up the commits, do some rebasing and
unifying of them all now that I have it split up and working.  Still
some more testing/debugging to do.

Hopefully be the end of this week it'll be ready for review and merge
soon.

If this is applied to current repoman, it may cause some rebase hell.

 https://github.com/dol-sen/portage/tree/repoman

That is the repoman branch with the individualized checks that run in 3
small loops in scanner.py now.  There is no code in scanner that does
any checks.  Those are all in pym/repoman/modules/scan/*/*.py.  Some
modules contain several different files and class definitions.  There
are a bunch of new ones that I created from the code that still
remained in scanner.py's _scan_ebuilds().  I'll push the changes to teh
main gentoo portage repo's repoman branch once I have it cleaned up.

I would much prefer you re-base your patch on the rewrite code.

I will make a wiki page for the module definition requirements, with a
section on the vcs system as well.  But the modules are quite simple,
only small changes from the initial code split we did already.  So new
modules are easy to create and add in to the sequence of checks to
perform.  You just have to be careful where you insert checks.  As the
dynamic_data used and updated by the modules varies as it progresses
through the sequence.  I have yet to document the data changed/required
by each of the modules.  But they are quite clear looking at the code.



-- 
Brian Dolbec 

Re: [gentoo-dev] Re: News item: Apache "-D PHP5" needs update to "-D PHP"

[Kristian Fiskerstrand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 01/04/2016 09:41 AM, Kristian Fiskerstrand wrote:
> On 01/04/2016 01:26 AM, Sebastian Pipping wrote:
>> Hi!



> 
> Such a change should really be avoided if possible. Would it be 
> possible to have a conditional approach where either one can be 
> used, or maybe set the new variable/defin if the old one is used?
> 

Maybe I'm thinking things too difficult, why not just define both -D
PHP and -D PHP5 in the transition period and suggest this config for
any change?

- -- 
Kristian Fiskerstrand
Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJWinPkAAoJECULev7WN52FFkYH/2f9v5dnKeS4nX3mP+ZnzwkY
YpV2W0l8WNN1ZHfM4nsf/zKPw7eJqYFFryaYYtiNebvN37SpjaqdCrn78l1/mJYI
JfKH6Aj7QNi3LuGR0B30yKhDMF6Q5Yu56rtXuweHCdX25zOoTkQAQ8S5n9OOLORP
DP4J0hgc+HQZrMkZMUZGTrToFX91ffQazE/e/ryXROCNO/g8vZBpbCbTC6PuSpMp
z5foF2sD4cfcccvVf0vG4NKwIhFqYPZkvMM8/yYbuj61ZGGf0HtCXBpK4fNLgQKc
nKqVUzKY69YY76oi2sS+GDmEPQohCMTzSdhQztNXGKrTmzz5tccVnqCMlLd8kn4=
=0KpH
-END PGP SIGNATURE-

Re: [gentoo-dev] News item: Apache "-D PHP5" needs update to "-D PHP"

[Michał Górny]

On Mon, 4 Jan 2016 11:45:37 +0100
Lars Wendler  wrote:

> to be honest I was very upset when I first stumbled upon this problem.
> And yes I only found about it when my apache webserver started to
> deliver php source code instead of the real sites.
> Doing such a change without getting in contact with me as apache
> maintainer before the change was done is very... eh... impolite at best.

Well, if this is the common outcome, then I dare say it's very bad,
at least. Gentoo was never the distribution people could seriously
consider stable, and it not uncommon for breakages like this to happen.
But still, it's very bad if an upgrade is going to suddenly cause
webserver to disclose script sources rather than running it.

While of course the sole fact that this can happen is a complete
disastrous design failure, we can't really do much about it or cause
people to stop using such misdesigned software. Nevertheless, I think
it would be reasonable to at least try to reduce the intentional
breakage to bare minimum.

Therefore, I think you should really work on some kind of backwards
compatibility for people using '-D PHP5' that would prevent those kind
of issues at least for some migration period. With big fat warnings for
people who run it.

-- 
Best regards,
Michał Górny



pgp8HDjnMlmDF.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: News item: Apache "-D PHP5" needs update to "-D PHP"

[Kristian Fiskerstrand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 01/04/2016 02:30 PM, Kristian Fiskerstrand wrote:
> On 01/04/2016 09:41 AM, Kristian Fiskerstrand wrote:
>> On 01/04/2016 01:26 AM, Sebastian Pipping wrote:
>>> Hi!
> 
> 
> 
> 
>> Such a change should really be avoided if possible. Would it be 
>> possible to have a conditional approach where either one can be 
>> used, or maybe set the new variable/defin if the old one is
>> used?
> 
> 
> Maybe I'm thinking things too difficult, why not just define both
> -D PHP and -D PHP5 in the transition period and suggest this config
> for any change?
> 

And while at it, in additional to news item, this should likely follow
a few version upgrades as elog messages before actually being
implemented anywhere

- -- 
Kristian Fiskerstrand
Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJWin+hAAoJECULev7WN52FNGYIAIK5xZEaBvUzR9YCyzSphnI/
ymh6i+wUnzcCjX4TYpC5c05yp3nzLTXvKsaNFuMos43ZqhjTG6hny72waIZ5RRmM
KI1XORRItoOHiat6xuYrOg8S9vf881AJnS/w6XhRVkL1MrtGLrUbV2De/5Z7V1PU
3j0M702inkbPHoV3JfRv97ZZmupazCSj7rfrrwcvUFqjKFZNFU4zK76rAwRXYfSk
ZKC7MSAx6lfhcNmy8boUoFMnFwyimkI06hN8ZhaosexkSYqT5HeOUMrX2bpKtXF/
69Ky3bd8Vs8/f9WTqtjf3GJC/iBs1/gpxgSu7/hpy69yFoffLE9VsKe1xHSd3n4=
=C5MO
-END PGP SIGNATURE-

Re: [gentoo-portage-dev] [PATCH] repoman: filter out duplicate dependencies in error messages

[Zac Medico]

On 01/04/2016 01:30 PM, Mike Frysinger wrote:
> + # Filter out 
> duplicates.  We do this by hand (rather
> + # than use a 
> set) so the order is stable and better
> + # matches the 
> order that's in the ebuild itself.
> + atoms = []
> + for atom in 
> all_atoms:
> + if atom 
> not in atoms:
> + 
> atoms.append(atom)
> +

Alternative implementation using OrderedDict which has O(1) average
complexity for containment checks, rather than O(N):

atoms = OrderedDict()
for atom in all_atoms:
atoms.setdefault(atom, atom)
atoms = list(atoms)

-- 
Thanks,
Zac

Re: [gentoo-dev] News item: Apache "-D PHP5" needs update to "-D PHP"

[Michael Orlitzky]

On 01/04/2016 08:40 AM, Michał Górny wrote:
> 
> Therefore, I think you should really work on some kind of backwards
> compatibility for people using '-D PHP5' that would prevent those kind
> of issues at least for some migration period. With big fat warnings for
> people who run it.
> 

I wasn't able to come up with something that worked on apache-2.2 and
was backwards-compatible or failed "off."

The apache module name for PHP changed with php-7.0. This forces a big
change in 70_mod_php.conf, and a corresponding change in eselect-php
(which must be run once before anything will work). The problem is to
come up with an apache-2.2 config that works for new 5.6 users, 5.6 ->
7.0 eselect switchers, and new 7.0 users. Someone always gets screwed.

If anyone has a concrete idea that works better, it's not too late to
change it.

Re: [gentoo-dev] Re: News item: Apache "-D PHP5" needs update to "-D PHP"

[Brian Evans]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 1/4/2016 3:41 AM, Kristian Fiskerstrand wrote:
> On 01/04/2016 01:26 AM, Sebastian Pipping wrote:
>> Hi!
> 
> 
>> Better late then never.  Posting 72 hours from now the earliest
>> as advised by GLEP 42.  Feedback welcome as usual.
> 
> Do you have any timeline in place for the change happening in tree
> (in particular for stable users).
> 
> 
>> Without updating APACHE2_OPTS, websites could end up serving PHP
>>  code (include configuration files with passwords) unprocessed to
>>  website visitors!
> 
> 
> Such a change should really be avoided if possible. Would it be 
> possible to have a conditional approach where either one can be
> used, or maybe set the new variable/defin if the old one is used?
> 
> 

The problem is really two-fold with the new eselect-php.

For future compatibility (to not have this happen again with say
PHP8), the PHP team changed the symlink created by eselect to be
libphp.so instead of the current libphp${MAJOR}.so.

The user must also reselect with `eselect php set X`, even for the
current PHP versions and not just 7.

mjo explored the option of "Define PHP" but
that is apache-2.4+ only.

If we wanted a "compatibility" layer, it would be the same section
repeated until 2.4 was the only version available.  That might confuse
users even more.

Brian
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iQIcBAEBAgAGBQJWioraAAoJENH3ge/59KO2wNUQAKThJz1QBjOvOmi0ClluVxt8
Lt0fbibQXIgZScJy5zqeOwX3EAUDqBST8sonNhJ8uQT4qbU8gwdYK6vhoDbJS0sX
oNzbdwxumSwNBsi4UCl/D0Dj+XefgIyvmgGBZ0RA8t0x8Ls3uQB6DWI1f36Z3wAs
ULqJc38+d1e5pmNu3jpc5tvG2ybvaVVGbWmNiOI8rafFV12KIsRMDHdDCG4DpkQD
bmWLYTv44Nt5nSY2wmLQQAV57kB2PsaaT0qlQciVhKiqOUA+qlmI0dtM3LLSNitK
dqKWNj7WTQFBM1SLHXD0s4CQk9XhFB9E07zelcB5zuC9XeYj1mbrn9aEtfl5lfVs
hHHJQ97MG3u/XwPTHY04J6wfoaQW4dwaQd74Pz48qJ2DqSW9HV8UTS2enF5cuZok
mFfd+xexHvcz45jyz83BtXM4mRWdHBDdy/3fYEvN12wVgU4hQcjDTKKPwpO3Btsb
uyCar+SgoHoRIEQhfDytnT0Idte2GifCysPq7hG12j+efwT7pt0XXk+TZQaH/opZ
FWRzOvjXZXd41M3RQ7H5D+KXrKV3uY4mE41rceEUXrw9PQrueg6Cw5ujK/opawrv
a8qonCtx7LZrEzYLagCYEBDPdgvxHWzIBb0vdgYoRVzSRwoJiAA66dbRuqC7s34G
JM84VqrtPsaCktCq6vw3
=/gh0
-END PGP SIGNATURE-

Re: [gentoo-dev] News item: Apache "-D PHP5" needs update to "-D PHP"

[Peter Stuge]

Michael Orlitzky wrote:
> If anyone has a concrete idea that works better, it's not too late to
> change it.

Add code to init script and service file to check the config before
starting the program, and react if PHP5 is still set.


//Peter

Re: [gentoo-dev] Eclass assisted multilib dependent cache updates

[Alexis Ballier]

On Sat, 02 Jan 2016 16:54:31 +0100
Gilles Dartiguelongue  wrote:

> Hello all,
> 
> while working on bug #518422, I found out that while eclass calls the
> relevant cache updates it has no idea whether or not it is called in a
> multilib context or not.

Hmm... what's the problem here ?
What you seem to call "not a multilib context" is a multilib build with
only one ABI. That's one of the points of inheriting the
multilib eclasses.

> Imho, this leads to avoidable human errors where one thinks eclass
> will take care of lib dependent caches, which it does, but not for all
> enabled ABIs which could lead to reduced functionality for non-native
> ABIs.
> 
> While it seems reasonable to call multilib_foreach_abi
> gnome2_pkg_postinst for multilib enabled ebuilds, it is still not
> ideal as it will call a lot of functions for no good reason. On the
> other hand, checking environment variable set by multilib eclasses
> does not seem like a robust solution.
> 
> Is there any reasonable way to make phase functions aware of if they
> are running in a multilib enabled ebuild to adjust their behavior ?


Per the above, 'multilib_foreach_abi' seems just fine. Is there a real
problem with it?

Re: [gentoo-dev] Re: News item: Apache "-D PHP5" needs update to "-D PHP"

[Peter Stuge]

Kristian Fiskerstrand wrote:
> Maybe I'm thinking things too difficult, why not just define both -D
> PHP and -D PHP5 in the transition period and suggest this config for
> any change?

Because it mostly just defers the problem.

If the desire is to move away from PHP5 then I would suggest to force
a failure when starting Apache, if PHP5 is defined when PHP is required.

Ie. fail closed.

I can be talked into supporting the idea to only print a warning when
PHP5 is set and to not fail (no source served) for some period of
time until which the forced failure starts, if PHP5 is still set.

Don't fail open, fail closed. Since manual interaction is required
some people will forget or overlook it, and will get a failure.

I would introduce the failure right away, but maybe a warning will
make some happy who would otherwise have gotten a failure.


//Peter

Re: [gentoo-dev] Re: News item: Apache "-D PHP5" needs update to "-D PHP"

[Rich Freeman]

On Mon, Jan 4, 2016 at 9:20 AM, Kristian Fiskerstrand  wrote:
>
> And while at it, in additional to news item, this should likely follow
> a few version upgrades as elog messages before actually being
> implemented anywhere
>

I don't want to be too prescriptive with the solutions.  However,
clearly /some/ kind of orderly transition is necessary.  News before,
an elog, etc.  And that news needs to be timely - not 12 months before
stable mysteriously breaks one day, unless it is safe to make the
change before the update.  I'd leave it up to the maintainer to decide
whether it is more work to coordinate the timing around all the
communications or to have a more graceful transition so that the
timing isn't as critical.

-- 
Rich

Re: [gentoo-dev] News item: Apache "-D PHP5" needs update to "-D PHP"

[Hanno Böck]

On Mon, 4 Jan 2016 01:26:28 +0100
Sebastian Pipping  wrote:

> Better late then never.  Posting 72 hours from now the earliest as
> advised by GLEP 42.  Feedback welcome as usual.

afaics this only affects users using the mod_php variant of PHP and not
any fcgid or fpm solution. I think this should be mentioned.

-- 
Hanno Böck
http://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42

Re: [gentoo-dev] News item: Apache "-D PHP5" needs update to "-D PHP"

[Peter Stuge]

Michael Orlitzky wrote:
> >> If anyone has a concrete idea that works better, it's not too late to
> >> change it.
> > 
> > Add code to init script and service file to check the config before
> > starting the program, and react if PHP5 is still set.
> 
> Which init script?

For Apache.

> It's only "bad" to have PHP5 set if the user has installed
> >=eselect-php-0.8.1, and run it at least once.

So pkg_postinst for >=eselect-php-0.8.1 should say something, but
ideally also the invocation - but I don't know if eselect-php is also
code or only data managed by eselect?


> You don't want to e.g. kill working php-5.x installations for people
> who have apache keyworded ~arch.

IMO that would be a much lesser evil than serving source in another
case, as long as it is clear how to unkill (sed s,PHP5,PHP,) the setup.


//Peter

Re: [gentoo-dev] News item: Apache "-D PHP5" needs update to "-D PHP"

[Brian Evans]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 1/4/2016 11:43 AM, Michael Orlitzky wrote:
> On 01/04/2016 11:11 AM, Peter Stuge wrote:
>> 
>> So pkg_postinst for >=eselect-php-0.8.1 should say something,
>> but ideally also the invocation - but I don't know if eselect-php
>> is also code or only data managed by eselect?
> 
> The pkg_postinst is already there. The eselect-php routines are
> bash code so theoretically we can do anything we want. How do
> people feel about making eselect-php spit out a warning every time
> the apache2 module is messed with?

Perhaps grep for -DPHP5 or if -DPHP is missing in the conf.d and shout
then as part of the "eselect php set apache2 X"?

Brian
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iQIcBAEBAgAGBQJWiqoTAAoJENH3ge/59KO2XRUP/RFybVPuCNtCDEPclsKWp5AI
rvejArURHwk8hu+OjITLb/0UxYM5VwXN9fOrSkxJ3lsVErNlxfeaLc0UYYh/1qnd
WeofmCq7yx0enOe0+szcY877reca5yfPzPs3ChB+a4+PpVAIuD7quL0lcuhs/NMJ
S9Hoex5mOmmd82jeXdZlvZZzLHxLhsnWwTjDQhmnCL9mkHbx2u1+07et7Wdxd8Gu
Td4O9tiAvp/5KQ3Dmw2P2BQPBbZc0EYqGG/Aghw02dDHp+jq5snVRXCdg/z1L61j
VXPblbNBRY9wA96k0vu6aqGRWGuj66rBHcF3DH8A9+o0LY/8eh9v56n7UGg2LfE8
5GEgfT4yY7d5DYEikWKLc56iOy754auh0UbXC+5IaAK8PfIOcMBFG1AgvEqZY+VU
pXBF7yh1QxaAtsYBjKX8X+DuCr9549vjSsMKtUFN+mCz1cLi1KX9OxtCvVQMJUnM
zx5mK8JNFoKlA/kINERsa//swICDgJ2aN4GX64YV+tnfsrZrM1YSJxHIjiEE7Q1m
Pd3v/0CFMra5snYEMdk8qoYQ7ITQdmsM0vM93OgqBYmaNrEZlNG5T+seMpPxv+lD
BhT8R7W2mDqKShljjm31nzp4FG/30z8DymeBn+JVWxHbdy5IqUlaYa5egpWk1vip
qw0h5uqKkkv6BKwXI8sp
=60JD
-END PGP SIGNATURE-

Re: [gentoo-dev] News item: Apache "-D PHP5" needs update to "-D PHP"

[Rich Freeman]

On Mon, Jan 4, 2016 at 12:21 PM, Brian Evans  wrote:
>
> On 1/4/2016 11:43 AM, Michael Orlitzky wrote:
>> On 01/04/2016 11:11 AM, Peter Stuge wrote:
>>>
>>> So pkg_postinst for >=eselect-php-0.8.1 should say something,
>>> but ideally also the invocation - but I don't know if eselect-php
>>> is also code or only data managed by eselect?
>>
>> The pkg_postinst is already there. The eselect-php routines are
>> bash code so theoretically we can do anything we want. How do
>> people feel about making eselect-php spit out a warning every time
>> the apache2 module is messed with?
>
> Perhaps grep for -DPHP5 or if -DPHP is missing in the conf.d and shout
> then as part of the "eselect php set apache2 X"?
>

My understanding (which could be wrong) is that this update will break
things even if the user never runs eselect php afterwards.  I can't
tell you the last time I touched the php eselect module, because major
updates to php are rare.



-- 
Rich

Re: [gentoo-dev] Eclass assisted multilib dependent cache updates

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 02/01/16 10:54 AM, Gilles Dartiguelongue wrote:
> Hello all,
> 
> while working on bug #518422, I found out that while eclass calls
> the relevant cache updates it has no idea whether or not it is
> called in a multilib context or not.
> 
> Imho, this leads to avoidable human errors where one thinks
> eclass will take care of lib dependent caches, which it does, but
> not for all enabled ABIs which could lead to reduced
> functionality for non-native ABIs.
> 
> While it seems reasonable to call multilib_foreach_abi 
> gnome2_pkg_postinst for multilib enabled ebuilds, it is still not
> ideal as it will call a lot of functions for no good reason. On
> the other hand, checking environment variable set by multilib
> eclasses does not seem like a robust solution.
> 
> Is there any reasonable way to make phase functions aware of if
> they are running in a multilib enabled ebuild to adjust their
> behavior ?
> 

By "phase functions" here, I assume that you are referring to phase
functions exported by the eclass?  In that particular case, AFAIK,
they are never called in a multilib context by default, rather they
are only called within a multilib context when explicitly called
within a multilib_foreach_abi.

Back to the issue at hand, though, likely there would be a way to
leverage 'multilib_is_native_abi' to filter out cases when you don't
want certain things to run.  To do this properly for non-multilib
ebuilds you'll need to make sure that your conditionals won't crash
out if multilib_is_native_abi is undefined, though -- could be a
messy hack...  It would probably make more sense to rearrange the
function(s) internally and perhaps provide two (one for
multilib-build, one not) if the plan is to support ebuilds that
inherit multilib-build AND ebuilds that don't, from the same eclass.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlaKnfMACgkQAJxUfCtlWe0xxQD/S0+QJMqm0qulSR4DAZb4J0uu
RPF53KqIPkuvE0VnL14BAJWscEDyB4Pt9JOEjoiYwNelfDV0frwsgEQVvZu1Ol7Y
=pZVV
-END PGP SIGNATURE-

Re: [gentoo-dev] News item: Apache "-D PHP5" needs update to "-D PHP"

[Michael Orlitzky]

On 01/04/2016 11:11 AM, Peter Stuge wrote:
>
> So pkg_postinst for >=eselect-php-0.8.1 should say something, but
> ideally also the invocation - but I don't know if eselect-php is also
> code or only data managed by eselect?

The pkg_postinst is already there. The eselect-php routines are bash
code so theoretically we can do anything we want. How do people feel
about making eselect-php spit out a warning every time the apache2
module is messed with?


>>
>> Which init script?
> 
> For Apache.
> 
>> You don't want to e.g. kill working php-5.x installations for people
>> who have apache keyworded ~arch.
> 
> IMO that would be a much lesser evil than serving source in another
> case, as long as it is clear how to unkill (sed s,PHP5,PHP,) the setup.
> 

It wouldn't be that simple; at the very least, those people would have
to keyword eselect-php, upgrade it, run it, and fix their config. To do
that properly would make eselect-php a dependency of the new apache, and
that's wrong.

Re: [gentoo-dev] News item: Apache "-D PHP5" needs update to "-D PHP"

[Michael Orlitzky]

On 01/04/2016 12:11 AM, Jeroen Roovers wrote:
> 
>> Without updating APACHE2_OPTS, websites could end up serving
>> PHP code (include configuration files with passwords)
>> unprocessed to website visitors!
> 
> That would mean there is an additional (local) security problem.
> 

All PHP applications are written by the sort of people who will tell you
to put a config file in the public DocumentRoot, and that's not easy to
fix as the system administrator. Those virtual hosts should really
really really really really be wrapped in  statements.