Re: [gentoo-dev] Re: News item: Upgrading Apache from 2.2 to 2.4

[Aaron W. Swenson]

On 2016-01-17 19:18, Dirkjan Ochtman wrote:
> Second attempt!
> 
> ===
> 
> Title: Upgrading Apache from 2.2 to 2.4
> Author: Dirkjan Ochtman 
> Content-Type: text/plain
> Posted: 2016-01-17
> Revision: 1
> News-Item-Format: 1.0
> Display-If-Installed: www-servers/apache
> 
> With the 2.4 branch released by upstream almost 4 years ago, stable
> Gentoo systems will soon be upgraded from apache 2.2 to apache 2.4.
> When upgrading, chances are some configuration changes have to be
> made. Upstream has a handy guide:
> 
> https://httpd.apache.org/docs/2.4/upgrading.html
> 
> For more information on all the new features, start here:
> 
> https://httpd.apache.org/docs/trunk/new_features_2_4.html
> 
> ===
> 
> A bit more concise and less personal. Better?
> 
> Cheers,
> 
> Dirkjan
> 

I think the use of "chances" here depresses the importance of
configuration changes.

This is debatable, but I think it should be "there are some
configuration changes that must be made."

Primarily in regards to the Order directive being (re)moved to an
optional module.


signature.asc
Description: Digital signature

Re: [gentoo-dev] Re: News item: Upgrading Apache from 2.2 to 2.4

[Daniel Campbell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 01/17/2016 10:18 AM, Dirkjan Ochtman wrote:
> Second attempt!
> 
> ===
> 
> Title: Upgrading Apache from 2.2 to 2.4 Author: Dirkjan Ochtman
>  Content-Type: text/plain Posted: 2016-01-17 
> Revision: 1 News-Item-Format: 1.0 Display-If-Installed:
> www-servers/apache
> 
> With the 2.4 branch released by upstream almost 4 years ago,
> stable Gentoo systems will soon be upgraded from apache 2.2 to
> apache 2.4. When upgrading, chances are some configuration changes
> have to be made. Upstream has a handy guide:
> 
> https://httpd.apache.org/docs/2.4/upgrading.html
> 
> For more information on all the new features, start here:
> 
> https://httpd.apache.org/docs/trunk/new_features_2_4.html
> 
> ===
> 
> A bit more concise and less personal. Better?
> 
> Cheers,
> 
> Dirkjan
> 

Looks excellent!

- -- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWnOVvAAoJEAEkDpRQOeFwz48QAMmRq40+TZhvekUuDnFfDP4c
0cl4p9gWvKNVpesuQf7fR8CZ13mHiu1JyHzgmb03Rk3WTbE4LiFj8uUz6p/fLoDk
8F2Zn7ZypXIw5GWZvWzw7BVx69NHF5hMLJMAJq5kj42LwGBewcYHRWaT1mPan3pb
4EtT9Mr8MJe4hp6RcRqSauJ0+TX12TZhv1y07SaWGoDAqUBpu+Iny8r/ObsQciql
nEbRQfOAQvg9vd5vxJsMqVvTrY9Q8h7TZ+iEUDWDWD7FGdVEbXbJZ3QQ1WqK+R4K
v2Jup+I2MD8fe2R9cXQzdh/vh4vrmSmsh7g1UScXeHRtO8ADRYy3ssCav+4RMBQ9
Cs9Q6iLnkvCrKsiHfpNTfcvx4hYrlzOIpFZHYJ3N6+Yafw5v17H3EE3qgtbIbZFL
B2UDDQ14CSjYo/oIG6DLBmgTIXidFHv4PljCgwB2sV3Gnh/Rk2zeDoil0JVNG8WB
weycIKebgcRlk5eWlz+iLKn+1DonPfaSkTxG+v0hRETEV9xd0XeTuT57QkMckXaz
h/R7XKe3KhMbb641tBOjZmRWZAJLUiRjgcqY+ztUj2hHZj2kXkpy1eLC0/PSvCFr
30dk+REHrM8pkQochK+EmmTelFPibUvEuANMU2ZMGdh0W/Mm/je75HGa2VRNP8o1
8Po3JXLXD4Qgng+N6Cx0
=TtSV
-END PGP SIGNATURE-

Re: [gentoo-dev] Herd up for grabs: xbox

[Alexis Ballier]

On Sun, 17 Jan 2016 17:47:54 +0100
Michał Górny  wrote:


> media-tv/kodi: 
> media-tv/xbmc: 

you can add video herd for these two if vapier is ok with that i think

Re: [gentoo-portage-dev] dead emerge processes and/or lockfiles

[Joshua Kinard]

On 01/17/2016 15:01, Zac Medico wrote:
> On 01/17/2016 09:06 AM, Brian Dolbec wrote:
>>
>> I've read in several forum posts lately about emerge not running and
>> the problem comes down to dead emerge processes and remaining lockfiles.
>>
>> Perhaps we should make an emaint module to search for and fix these.
>> It should be easy enough.
> 
> It would be nicer if we fixed whatever issue(s) cause the emerge
> processes to hang up. How would the emaint module distinguish a "good"
> emerge process from a "bad" one? I suppose you could strace it to see if
> it has any activity.
> 

I've been playing around with Gentoo/FreeBSD and have been noticing that emerge
is leaving orphaned processes behind on that platform.  Seems to be
ecompressdir getting hung up.  emerge itself just moves on, but after I
accumulated ~5 of those stuck ecompressdir processes in a single run, I kill
-9'ed them all.  Didn't see side-effects similar to what's described in the
original post, but the way to detect this issue might be to look for orphaned
children processes lacking a parent PID, then reap them.

--J

Re: [gentoo-dev] Herd likely up for grabs: net-im

[Amadeusz Żołnowski]

Michał Górny  writes:
> Packages currently in herd along with their other maintainers:
> [...]
>
> net-im/ejabberd  : 

I have not much knowledge about erlang stuff, but I will take ejabberd
if noone else wants. Co-maintainers are welcome.

-- Amadeusz Żołnowski


signature.asc
Description: PGP signature

[gentoo-dev] [RFD] Adopt-a-package, proxy-maintenance, and other musings

[NP-Hardass]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

With all of the unclaimed herds and unclaimed packages within them, I
started to wonder what will happen after the GLEP 67 transition
finally comes to fruition.  This left me with some concerns and I was
wondering what the community thinks about them, and some possible
solutions.

There is a large number of packages from unclaimed herds that, at this
time, look like they will not be claimed by developers.  This will
likely result in a huge increase in maintainer-needed packages (and
subsequent package rot).  This isn't to say that some of these
packages weren't previously in a "maintainer-needed" like state, but
now, they will explicitly be there.

A possible approach to reducing this is to adopt some new policies.

The first of which is an "adopt-a-package" type program.  In
functionality, this is no different than proxy-maintenance, however,
this codifies it into an explicit policy whereby users are encouraged
to step and take over a package.  This obviously requires a greater
developer presence in the proxy-maint project (or something similar),
but, personally, I think that a stronger dev presence in proxy-maint
would be better for Gentoo as a whole.

The second policy change would be that maintainer-needed packages can
have updates by anyone while maintaining the standard "you fix it if
you break it" policy.  This would extend to users as well.  With the
increased ease that users can contribute via git/github, they should
be encouraged to contribute and have their efforts facilitated to ease
contributions to whatever packages they desire (within the
maintainer-needed category).

Similar to the concept of a "bugday," coupled with above, an
"ebuildday" where users and devs get together so users can learn to
write ebuilds and for devs to work together to maintain packages that
usually fall outside their normal workload could prove beneficial to
the overall health of Gentoo packaging.

Once again, these are just some random musings inspired by recent
events on the dev ML, and thought it might be worth discussing.
I've cc'd proxy-maint as a lot of this discussion is likely to involve
them, and would like them to put in their official opinion as well.


- -- 
NP-Hardass
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWnc1RAAoJEBzZQR2yrxj7WMYQALdOH13N+N0hCuDrCKcFwhp1
GjosbY2ZQsqVL8WX46K8I+Kr9EV/JD1LWfB5S24YMANFgk+iAHJUlDebKmbIOUek
JiT1eRG8LrIJE3VWfMtJxMfPxzkYEPf+Ew3DXBADekhtWbIb3Ha9hWYGgD/gZ2UN
vY0xDBU2oXuJjoSTYwfdbVXG950CgiEfI+QtaeHaMihdqR/ZB7WcHXx788EnnXeA
Q9M3JtNbRyLL7UI7XeVzxN7A+ODhN3highYXELdImHR5fZh2T7sm1Limvev5lgaU
uiugUMnFbDISqiWLSPFbTaJBwrl0tyqa9hjYnhP9LLj8zIXLe/PN+8hQ7Et8aq8w
hRUr6ntm++4HFD2TKySZ4So09yntb+xapeFIM4UjTvN6Tfy2gUyTnpzDdsAlBoHt
zhExBzidA+g1syCY5LrMkndP+8iKDDbUlPkMtfldf2XBMXu5jFBfUXKoZRFC9P27
XOqneJHcBEjocjvcmnu4BeUz0+Nu3jRpQuGj35hNLTsFyG7Dh9Qw1eJ0mDnCm2PZ
YrWWw2Z7nJGKsStwI3Ox6HIeXHuiFGup4XfveC0jE/ggZcK+E9jrkXDbwc9sOPYg
WRMsgCHFHke1YgPhOxHA1RSE0bZv5j9CYkJx8piif8c0p1HkPUj93r3zgpycfSRi
35R7+OKBC4AQeIIoCBXI
=5UdF
-END PGP SIGNATURE-

[gentoo-portage-dev] [PATCH] repoman: fix _here_doc_re to handle file redirection

[Zac Medico]

This suppresses "Unquoted Variable" warnings for sys-apps/portage ebuilds
where a here-doc is used to generate repos.conf:

  ebuild.minorsyn   6
   sys-apps/portage/portage-2.2.8-r2.ebuild: Unquoted Variable on line: 496
   sys-apps/portage/portage-2.2.20.1.ebuild: Unquoted Variable on line: 290
   sys-apps/portage/portage-2.2.23.ebuild: Unquoted Variable on line: 290
   sys-apps/portage/portage-2.2.24.ebuild: Unquoted Variable on line: 290
   sys-apps/portage/portage-2.2.25.ebuild: Unquoted Variable on line: 290
   sys-apps/portage/portage-2.2.26.ebuild: Unquoted Variable on line: 294
---
 pym/repoman/checks/ebuilds/checks.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/pym/repoman/checks/ebuilds/checks.py 
b/pym/repoman/checks/ebuilds/checks.py
index 7bab8e4..c752fcf 100644
--- a/pym/repoman/checks/ebuilds/checks.py
+++ b/pym/repoman/checks/ebuilds/checks.py
@@ -920,7 +920,7 @@ def checks_init(experimental_inherit=False):
for k, kwargs in _eclass_info.items(
 
 
-_here_doc_re = re.compile(r'.*\s<<[-]?(\w+)$')
+_here_doc_re = re.compile(r'.*<<[-]?(\w+)\s*(>\s*\S+)?$')
 _ignore_comment_re = re.compile(r'^\s*#')
 
 
-- 
2.4.10

[gentoo-dev] Re: [RFD] Adopt-a-package, proxy-maintenance, and other musings

[Duncan]

NP-Hardass posted on Tue, 19 Jan 2016 00:44:49 -0500 as excerpted:

> "adopt-a-package" type program.  In functionality, this is no different
> than proxy-maintenance, however, this codifies it into an explicit
> policy whereby users are encouraged to step and take over a package. 
> This obviously requires a greater developer presence in the proxy-maint
> project (or something similar),
> but, personally, I think that a stronger dev presence in proxy-maint
> would be better for Gentoo as a whole.

That gave me the idea of a maintainer-needed eclass.  When packages are 
set to maintainer-needed, they can simply inherit this eclass and add 
whatever function to the pkg_postinst, that will add a message that will 
in effect say "adopt-me please", probably printing a proxy-maintainer 
invitation URL to go to for more information.

Talking about pkg_postinst messages, unless I missed it there's no simple 
way to add a one ATM, without coding up the whole function, making it 
problematic for eclasses, etc.  For EAPI-7, what about either a helper 
function that can be called, or an array variable that can be simply 
added to, that simply adds the supplied message to a list of messages 
printed at pkg_postinst time, and of course an appropriate 
default_pkg_postinst to go along with it?  Then ebuilds and eclasses can 
call this helper or set this var in whatever phase they need to, and the 
message will be printed at pkg_postinst time without having to worry 
about setting up your own pkg_postinst or stepping on anything 
pkg_postinst related setup elsewhere.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman