Re: Apache2 rev bump for OpenSSL update

[Daniel J. Luke]

On Mar 10, 2016, at 3:36 PM, Ryan Schmidt  wrote:
>>> but I'm not sure how to programmatically understand the coding style of a 
>>> given portfile.
>> 
>> It's possible (we load and execute portfiles today).
>> 
>> It would probably be easier if portfiles more consistently kept to key/value 
>> style (or if we didn't use tcl as our parser).
> 
> I don't see how we could possibly change away from tcl at this point.

I guess I'm not making myself clear.

We currently parse portfiles. If we could take the parsed version and write it 
back out, we could reliably do something over many ports. The fact that we 
currently use tcl as the parser isn't entirely relevant (other than it being a 
bunch of work that no one is volunteering for to change that).

We could probably make things easier by setting up some (new) constraints on 
portfiles to make this easier. You're clearly in favor of the arbitrary 
expressiveness of the current way things work, though. I would favor doing 
everything we can to make the Portfile syntax more declarative in all but 
unusual cases.

> If we balk at manually examining 300 portfiles to see if they're already been 
> revbumped for the openssl update, nobody is going to manually examine 10,000 
> portfiles to make them conform to a different parser.

As with everything we release, if it were implemented we would do a 'good 
enough' version and fix things that were broken as people found them (worse is 
better).

Do you have another idea to help automate this? Keeping track of metatdata 
about ports and the dependency tree is something that MacPorts should be able 
to do and we shouldn't have to expect every maintainer to do manually. 

>> distributing software that has known security bugs is a problem.
> 
> We'll have to agree to disagree.

:( tragedy of the commons.

> Most of the complexity comes from supporting more than one version. 
> Supporting more than two versions is no more difficult.

If there were fewer versions, it might not be unduly-burdonsome to just have 
individual portfiles for each version (especially if it solved other problems). 
Of course, there may be some other approach to reducing portfile duplication 
that would leave more simple/structured portfiles that would be easy to 
mass-update (I haven't spent any time thinking about it).

-- 
Daniel J. Luke



___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Apache2 rev bump for OpenSSL update

[Ryan Schmidt]

On Mar 10, 2016, at 2:27 PM, Daniel J. Luke  wrote:
> 
> On Mar 10, 2016, at 3:18 PM, Ryan Schmidt  wrote:
>>> The general problem is something we should address.
>>> 
>>> (a 'compatibility version' we store for ports and make part of the 
>>> dependency engine? a better 'revbump a bunch of ports tool'? something 
>>> else?)
>>> 
>>> We should have a way to reliably force rebuilds
>> 
>> We do: increase the revision.
>> 
>> If you mean we should have a reliable way to programmatically increase the 
>> revision of a port, maybe,
> 
> reliably programmatically increasing the revision is one possible solution to 
> the actual problem (which is "I need to force any ports that depend on my 
> port to rebuild.")
> 
> Today, we do that by increasing the revision of all affected ports (manually, 
> or with some help from a script).
> 
>> but I'm not sure how to programmatically understand the coding style of a 
>> given portfile.
> 
> It's possible (we load and execute portfiles today).
> 
> It would probably be easier if portfiles more consistently kept to key/value 
> style (or if we didn't use tcl as our parser).

I don't see how we could possibly change away from tcl at this point. If we 
balk at manually examining 300 portfiles to see if they're already been 
revbumped for the openssl update, nobody is going to manually examine 10,000 
portfiles to make them conform to a different parser.


 e.g. the php port is definitely a special case.
>>> 
>>> (and is otherwise problematic since it has us distributing versions of php 
>>> that no longer have upstream support)
>> 
>> I don't consider that a problem.
> 
> distributing software that has known security bugs is a problem.

We'll have to agree to disagree. The unsupported php ports print a message that 
they're unsupported. Someone installing an old php port despite those messages 
must really want that version, for example in order to test and perhaps update 
an old web site designed with that version. Removing the old php subports from 
MacPorts just wastes the user's time as the user is forced to manually locate 
and figure out how to patch and compile the old version.


>> The php web site also still distributes versions of php that they no longer 
>> support. In any case it does not relate to the discussion at hand.
> 
> http://php.net/downloads.php lists 7.0.4, 5.6.19, and 5.5.33 (older releases 
> are still there, but with the disclaimer "listed for archival purposes only").

http://museum.php.net

> We can split the thread if you want to discuss further. You're right that 
> it's only tangentially related (the port would be less complicated if it 
> didn't have to support as many php versions).

Not substantially. Most of the complexity comes from supporting more than one 
version. Supporting more than two versions is no more difficult.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Apache2 rev bump for OpenSSL update

[Daniel J. Luke]

On Mar 10, 2016, at 3:18 PM, Ryan Schmidt  wrote:
>> The general problem is something we should address.
>> 
>> (a 'compatibility version' we store for ports and make part of the 
>> dependency engine? a better 'revbump a bunch of ports tool'? something else?)
>> 
>> We should have a way to reliably force rebuilds
> 
> We do: increase the revision.
> 
> If you mean we should have a reliable way to programmatically increase the 
> revision of a port, maybe,

reliably programmatically increasing the revision is one possible solution to 
the actual problem (which is "I need to force any ports that depend on my port 
to rebuild.")

Today, we do that by increasing the revision of all affected ports (manually, 
or with some help from a script).

> but I'm not sure how to programmatically understand the coding style of a 
> given portfile.

It's possible (we load and execute portfiles today).

It would probably be easier if portfiles more consistently kept to key/value 
style (or if we didn't use tcl as our parser).

>>> e.g. the php port is definitely a special case.
>> 
>> (and is otherwise problematic since it has us distributing versions of php 
>> that no longer have upstream support)
> 
> I don't consider that a problem.

distributing software that has known security bugs is a problem.

> The php web site also still distributes versions of php that they no longer 
> support. In any case it does not relate to the discussion at hand.

http://php.net/downloads.php lists 7.0.4, 5.6.19, and 5.5.33 (older releases 
are still there, but with the disclaimer "listed for archival purposes only").

We can split the thread if you want to discuss further. You're right that it's 
only tangentially related (the port would be less complicated if it didn't have 
to support as many php versions).

-- 
Daniel J. Luke



___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Apache2 rev bump for OpenSSL update

[Ryan Schmidt]

On Mar 10, 2016, at 2:15 PM, Daniel J. Luke  wrote:

> On Mar 10, 2016, at 2:05 PM, Ryan Schmidt  wrote:
>>> That's probably safe, but I don't think there is a compelling reason to try 
>>> and only revbump the minimal set of ports (better to have some needless 
>>> rebuilds/downloads of binary archives than to have mysteriously broken 
>>> ports).
>> 
>> You can't programmatically revbump safely,
> 
> with existing tool(s).
> 
>> because in ports with subports you have to manually determine which 
>> subport(s) to revbump and how to do so.
> 
> The general problem is something we should address.
> 
> (a 'compatibility version' we store for ports and make part of the dependency 
> engine? a better 'revbump a bunch of ports tool'? something else?)
> 
> We should have a way to reliably force rebuilds

We do: increase the revision.

If you mean we should have a reliable way to programmatically increase the 
revision of a port, maybe, but I'm not sure how to programmatically understand 
the coding style of a given portfile.


>> e.g. the php port is definitely a special case.
> 
> (and is otherwise problematic since it has us distributing versions of php 
> that no longer have upstream support)

I don't consider that a problem. The php web site also still distributes 
versions of php that they no longer support. In any case it does not relate to 
the discussion at hand.


>> So if you're manually examining all ports that depend on openssl, you can 
>> run an "svn log" on them to see if any commits after r146162 updated the 
>> version or revision.
> 
> ick.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Apache2 rev bump for OpenSSL update

[Daniel J. Luke]

On Mar 10, 2016, at 2:05 PM, Ryan Schmidt  wrote:
>> That's probably safe, but I don't think there is a compelling reason to try 
>> and only revbump the minimal set of ports (better to have some needless 
>> rebuilds/downloads of binary archives than to have mysteriously broken 
>> ports).
> 
> You can't programmatically revbump safely,

with existing tool(s).

> because in ports with subports you have to manually determine which 
> subport(s) to revbump and how to do so.

The general problem is something we should address.

(a 'compatibility version' we store for ports and make part of the dependency 
engine? a better 'revbump a bunch of ports tool'? something else?)

We should have a way to reliably force rebuilds

> e.g. the php port is definitely a special case.

(and is otherwise problematic since it has us distributing versions of php that 
no longer have upstream support)

> So if you're manually examining all ports that depend on openssl, you can run 
> an "svn log" on them to see if any commits after r146162 updated the version 
> or revision.

ick.
 
-- 
Daniel J. Luke



___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Apache2 rev bump for OpenSSL update

[Ryan Schmidt]

On Mar 10, 2016, at 12:04 PM, Daniel J. Luke wrote:
> On Mar 10, 2016, at 12:46 PM, Rainer Müller wrote:
>> On 2016-03-10 16:34, Ryan Schmidt wrote:
 The longer we wait, the harder it will be to catch these.
 Should we rev-bump all dependents of OpenSSL now?
>>> 
>>> Those that haven't already had their version or revision increased since 
>>> the openssl update, yes, I would say. 
>> 
>> That is difficult to determine now. To find that out requires going
>> through the list of dependents manually...
>> 
>> I will assume all ports with commits since the OpenSSL update in r146162
>> either already got a rev-bump or a version upgrade, so they do not need
>> it anymore:
> 
> That's probably safe, but I don't think there is a compelling reason to try 
> and only revbump the minimal set of ports (better to have some needless 
> rebuilds/downloads of binary archives than to have mysteriously broken ports).

You can't programmatically revbump safely, because in ports with subports you 
have to manually determine which subport(s) to revbump and how to do so. e.g. 
the php port is definitely a special case. So if you're manually examining all 
ports that depend on openssl, you can run an "svn log" on them to see if any 
commits after r146162 updated the version or revision.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Apache2 rev bump for OpenSSL update

[Daniel J. Luke]

On Mar 10, 2016, at 12:46 PM, Rainer Müller  wrote:
> On 2016-03-10 16:34, Ryan Schmidt wrote:
>>> The longer we wait, the harder it will be to catch these.
>>> Should we rev-bump all dependents of OpenSSL now?
>> 
>> Those that haven't already had their version or revision increased since the 
>> openssl update, yes, I would say. 
> 
> That is difficult to determine now. To find that out requires going
> through the list of dependents manually...
> 
> I will assume all ports with commits since the OpenSSL update in r146162
> either already got a rev-bump or a version upgrade, so they do not need
> it anymore:

That's probably safe, but I don't think there is a compelling reason to try and 
only revbump the minimal set of ports (better to have some needless 
rebuilds/downloads of binary archives than to have mysteriously broken ports).

-- 
Daniel J. Luke



___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Apache2 rev bump for OpenSSL update

[Rainer Müller]

On 2016-03-10 16:34, Ryan Schmidt wrote:
>> The longer we wait, the harder it will be to catch these.
>> Should we rev-bump all dependents of OpenSSL now?
> 
> Those that haven't already had their version or revision increased since the 
> openssl update, yes, I would say. 

That is difficult to determine now. To find that out requires going
through the list of dependents manually...

I will assume all ports with commits since the OpenSSL update in r146162
either already got a rev-bump or a version upgrade, so they do not need
it anymore:

---

# Find ports
for p in $(port -q echo depends_lib:openssl); do
c=$(svn log -r146162:HEAD $(port file $p) |grep -v '^---' |wc -l);
if [ $c -eq 0 ]; then
echo $p;
fi;
done > openssl-revbump.txt

# Rev-bump ports
xargs ./rev-bump.sh < openssl-revbump.txt

# Verify result
svn diff $(xargs port file < openssl-revbump.txt)

---

Committed in r146517.

For future reference, I attached the rev-bump.sh script.

Rainer


rev-bump.sh
Description: Bourne shell script
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Apache2 rev bump for OpenSSL update

[Ryan Schmidt]

On Mar 10, 2016, at 09:14, Rainer Müller  wrote:
> 
>> On 2016-03-03 02:40, Ryan Schmidt wrote:
>> I consider it the responsibility of the committer who updated the
>> openssl port to the version that changed its library ABI to revbump
>> the ports that link with it, regardless of maintainer status. It
>> should have been done at the same time that openssl was updated of
>> course. I'm not working on it so someone else is welcome to do it.
> 
> I still see related errors such as this one:
> 
> $ sudo gem install
> ERROR:  Loading command: install (LoadError)
>dlopen(/opt/local/lib/ruby2.0/2.0.0/x86_64-darwin14/openssl.bundle, 9):
> Symbol not found: _SSLv2_client_method
>  Referenced from:
> /opt/local/lib/ruby2.0/2.0.0/x86_64-darwin14/openssl.bundle
>  Expected in: /opt/local/lib/libssl.1.0.0.dylib
> in /opt/local/lib/ruby2.0/2.0.0/x86_64-darwin14/openssl.bundle -
> /opt/local/lib/ruby2.0/2.0.0/x86_64-darwin14/openssl.bundle
> ERROR:  While executing gem ... (NoMethodError)
>undefined method `invoke_with_build_args' for nil:NilClass
> 
> 
> The longer we wait, the harder it will be to catch these.
> Should we rev-bump all dependents of OpenSSL now?

Those that haven't already had their version or revision increased since the 
openssl update, yes, I would say. 

> Is it already too late and we fix them case-by-case?

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Apache2 rev bump for OpenSSL update

[Rainer Müller]

On 2016-03-03 02:40, Ryan Schmidt wrote:
> I consider it the responsibility of the committer who updated the
> openssl port to the version that changed its library ABI to revbump
> the ports that link with it, regardless of maintainer status. It
> should have been done at the same time that openssl was updated of
> course. I'm not working on it so someone else is welcome to do it.

I still see related errors such as this one:

$ sudo gem install
ERROR:  Loading command: install (LoadError)
dlopen(/opt/local/lib/ruby2.0/2.0.0/x86_64-darwin14/openssl.bundle, 9):
Symbol not found: _SSLv2_client_method
  Referenced from:
/opt/local/lib/ruby2.0/2.0.0/x86_64-darwin14/openssl.bundle
  Expected in: /opt/local/lib/libssl.1.0.0.dylib
 in /opt/local/lib/ruby2.0/2.0.0/x86_64-darwin14/openssl.bundle -
/opt/local/lib/ruby2.0/2.0.0/x86_64-darwin14/openssl.bundle
ERROR:  While executing gem ... (NoMethodError)
undefined method `invoke_with_build_args' for nil:NilClass


The longer we wait, the harder it will be to catch these.
Should we rev-bump all dependents of OpenSSL now?
Is it already too late and we fix them case-by-case?

Rainer
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Apache2 rev bump for OpenSSL update

[Daniel J. Luke]

On Mar 3, 2016, at 7:29 PM, Marius Schamschula  wrote:
> I have not had any luck getting php-fpm to work with apache24-devel, though 
> it works nicely with nginx.

I've been using php-fpm (compiled outside of macports) with apache 2.4 
(compiled outside of macports) for some time, and it works fine.
-- 
Daniel J. Luke



___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Apache2 rev bump for OpenSSL update

[Jim Jagielski]

As a macports maintainer myself, as well as someone who is on the Apache httpd 
project itself, I volunteer to help out with this. 

--
Jim Jagielski
Brief? Mobile

> On Mar 3, 2016, at 7:29 PM, Marius Schamschula  wrote:
> 
> I agree that it’s time to do something about apache. The ticket bellow is 
> four years old, and I added myself to the CCs 21 months ago…
> 
> As someone that has used apache 2.4.x since 2012 (my old hmug.org builds), 
> and under MacPorts as apache24-devel for over two years (although I’m down to 
> a single machine using it, and I may end up replacing it with nginx), it 
> boggles my mind that Apple has been shipping apache 2.4.x with OS X since 
> Yosemite, and MacPorts is still stuck at 2.2.x.
> 
> Using apache24-devel with php is somewhat complicated, as building the 
> php-apache2handler against apache24-devel requires me to maintain my own 
> branch of php, as php-apache2handler forces apache2 to be installed. Having 
> apache24 would make this easier for others. I have not had any luck getting 
> php-fpm to work with apache24-devel, though it works nicely with nginx.
> 
> Of course, all my Linux and FreeBSD machines use apache 2.4.x, and I like 
> consistency in server setup.
> 
> On Mar 3, 2016, at 5:54 PM, Bradley Giesbrecht  wrote:
> 
 On Mar 3, 2016, at 12:09 AM, Juan Manuel Palacios  
 wrote:
> On Mar 3, 2016, at 3:35 AM, Ryan Schmidt  wrote:
> On Mar 3, 2016, at 00:18, Juan Manuel Palacios  wrote:
> 
> Apache 2 rev-bumped, cf. r146274.
> 
> On a side note, and if I may in this same thread, do we have any policy 
> for not moving the Apache 2.4 port out of “dev”?  Not too sure when it 
> became the recommended release series by the ASF, but it certainly isn’t 
> dev any longer.
 
 There's a ticket you can read. We can't just replace the current apache2 
 port with the current apache24-devel port because it also changes the 
 directory layout.
>> 
>>> 
>>> Yeah, that I understand, we keep versioned ports for other packages too, 
>>> e.g. mysql55, mysql56, mysql57, and other examples. And we don’t replace 
>>> one with the other for a myriad of reasons.
>> 
>> With versioned apache24 modules like apache24-mod_python27.
>> 
>>> So we could deprecate the apache24-devel port and create apache24, maybe 
>>> even also deprecating apache2 and eventually replacing it with apache22, 
>>> which needless to say would be compatible with the former, and would live 
>>> on in parallel to apache24, just as mysql55 does to mysql56, etc.
>>> 
>>> You have a URL for that ticket that you mention?
>> 
>> https://trac.macports.org/ticket/35824
>> 
>> —
>> Brad
>> 
>> ___
>> macports-dev mailing list
>> macports-dev@lists.macosforge.org
>> https://lists.macosforge.org/mailman/listinfo/macports-dev
> 
> Marius
> --
> Marius Schamschula
> 
> 
> 
> 
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Apache2 rev bump for OpenSSL update

[Marius Schamschula]

I agree that it’s time to do something about apache. The ticket bellow is four 
years old, and I added myself to the CCs 21 months ago…

As someone that has used apache 2.4.x since 2012 (my old hmug.org builds), and 
under MacPorts as apache24-devel for over two years (although I’m down to a 
single machine using it, and I may end up replacing it with nginx), it boggles 
my mind that Apple has been shipping apache 2.4.x with OS X since Yosemite, and 
MacPorts is still stuck at 2.2.x.

Using apache24-devel with php is somewhat complicated, as building the 
php-apache2handler against apache24-devel requires me to maintain my own branch 
of php, as php-apache2handler forces apache2 to be installed. Having apache24 
would make this easier for others. I have not had any luck getting php-fpm to 
work with apache24-devel, though it works nicely with nginx.

Of course, all my Linux and FreeBSD machines use apache 2.4.x, and I like 
consistency in server setup.

On Mar 3, 2016, at 5:54 PM, Bradley Giesbrecht  wrote:

>> On Mar 3, 2016, at 12:09 AM, Juan Manuel Palacios  wrote:
>>> On Mar 3, 2016, at 3:35 AM, Ryan Schmidt  wrote:
 On Mar 3, 2016, at 00:18, Juan Manuel Palacios  wrote:
 
 Apache 2 rev-bumped, cf. r146274.
 
 On a side note, and if I may in this same thread, do we have any policy 
 for not moving the Apache 2.4 port out of “dev”?  Not too sure when it 
 became the recommended release series by the ASF, but it certainly isn’t 
 dev any longer.
>>> 
>>> There's a ticket you can read. We can't just replace the current apache2 
>>> port with the current apache24-devel port because it also changes the 
>>> directory layout. 
> 
>> 
>> Yeah, that I understand, we keep versioned ports for other packages too, 
>> e.g. mysql55, mysql56, mysql57, and other examples. And we don’t replace one 
>> with the other for a myriad of reasons.
> 
> With versioned apache24 modules like apache24-mod_python27.
> 
>> So we could deprecate the apache24-devel port and create apache24, maybe 
>> even also deprecating apache2 and eventually replacing it with apache22, 
>> which needless to say would be compatible with the former, and would live on 
>> in parallel to apache24, just as mysql55 does to mysql56, etc.
>> 
>> You have a URL for that ticket that you mention?
> 
> https://trac.macports.org/ticket/35824
> 
> —
> Brad
> 
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev

Marius
--
Marius Schamschula




___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Apache2 rev bump for OpenSSL update

[Bradley Giesbrecht]

> On Mar 3, 2016, at 12:09 AM, Juan Manuel Palacios  wrote:
>> On Mar 3, 2016, at 3:35 AM, Ryan Schmidt  wrote:
>>> On Mar 3, 2016, at 00:18, Juan Manuel Palacios  wrote:
>>> 
>>> Apache 2 rev-bumped, cf. r146274.
>>> 
>>> On a side note, and if I may in this same thread, do we have any policy for 
>>> not moving the Apache 2.4 port out of “dev”?  Not too sure when it became 
>>> the recommended release series by the ASF, but it certainly isn’t dev any 
>>> longer.
>> 
>> There's a ticket you can read. We can't just replace the current apache2 
>> port with the current apache24-devel port because it also changes the 
>> directory layout. 

> 
> Yeah, that I understand, we keep versioned ports for other packages too, e.g. 
> mysql55, mysql56, mysql57, and other examples. And we don’t replace one with 
> the other for a myriad of reasons.

With versioned apache24 modules like apache24-mod_python27.

> So we could deprecate the apache24-devel port and create apache24, maybe even 
> also deprecating apache2 and eventually replacing it with apache22, which 
> needless to say would be compatible with the former, and would live on in 
> parallel to apache24, just as mysql55 does to mysql56, etc.
> 
> You have a URL for that ticket that you mention?

https://trac.macports.org/ticket/35824

—
Brad

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Apache2 rev bump for OpenSSL update

[Daniel J. Luke]

On Mar 3, 2016, at 11:42 AM, Juan Manuel Palacios  wrote:
> I’m sure there’s a lot of people running Apache 2.2 whose systems (probably 
> highly customized configurations) would break if we did that without some 
> kind of transition, because it’d definitely be a backwards-incompatible change

we don't really do anything generally to help people update configs for ports 
when the config format changes. Keeping old versions of stuff around forever 
isn't really a good solution (apache22 is OK for now, but once upstream stops 
releasing security updates for it, we're doing a dis-service to our users if we 
keep it around).

Anyone using macports-provided software to provide critical services can't 
blindly do 'port upgrade outdated' anyway.

>> If there is, I think it's reasonable to have apache2 be the upstream 
>> recommended apache 2 (2.4.x)
> 
> But this would not be possible without the backwards incompatible change, 
> because even if we introduce apache22, the plain apache2 would move from 2.2 
> to 2.4, which I don’t think we should do, at least not without some kind of 
> transition.

If someone is willing to put the effort in to maintain it, I'm not opposed - 
but I don't think we need to do more than have some port notes with a reference 
to the upstream "upgrading to 2.4" docs.

Creating a bunch of 'dead end' ports may "keep things working" for users at the 
expense of not letting them know they're running old/outdated versions of 
things.

-- 
Daniel J. Luke



___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Apache2 rev bump for OpenSSL update

[Juan Manuel Palacios]

> On Mar 3, 2016, at 12:03 PM, Daniel J. Luke  wrote:
> 
> On Mar 3, 2016, at 11:26 AM, Juan Manuel Palacios  wrote:
>> The approach I suggested wouldn’t change layout in any way. apache2 would be 
>> obsoleted and replaced by apache22, which would be the exact same port as 
>> the previous apache2. Parallel to that, apache24-devel would be obsoleted 
>> and replaced by apache24, which again would be the exact same port as the 
>> one it’s replacing. This would create suite of Apache ports similar to what 
>> we now have for MySQL, i.e. mysql51, mysql55, mysql56, etc.
> 
> I don't think there's a compelling need to keep apache22 around.

I’m sure there’s a lot of people running Apache 2.2 whose systems (probably 
highly customized configurations) would break if we did that without some kind 
of transition, because it’d definitely be a backwards-incompatible change

> 
> If there is, I think it's reasonable to have apache2 be the upstream 
> recommended apache 2 (2.4.x)

But this would not be possible without the backwards incompatible change, 
because even if we introduce apache22, the plain apache2 would move from 2.2 to 
2.4, which I don’t think we should do, at least not without some kind of 
transition.


- jmpp

> 
> I would just remove apache24-devel and upgrade the apache2 port to 2.4.x
> 
>> So both ports would essentially just be renamed, preserving everything about 
>> them. Do you guys see a problem with that? I could do it if you don’t….
> 
> -- 
> Daniel J. Luke
> 
> 
> 

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Apache2 rev bump for OpenSSL update

[Daniel J. Luke]

On Mar 3, 2016, at 11:26 AM, Juan Manuel Palacios  wrote:
> The approach I suggested wouldn’t change layout in any way. apache2 would be 
> obsoleted and replaced by apache22, which would be the exact same port as the 
> previous apache2. Parallel to that, apache24-devel would be obsoleted and 
> replaced by apache24, which again would be the exact same port as the one 
> it’s replacing. This would create suite of Apache ports similar to what we 
> now have for MySQL, i.e. mysql51, mysql55, mysql56, etc.

I don't think there's a compelling need to keep apache22 around.

If there is, I think it's reasonable to have apache2 be the upstream 
recommended apache 2 (2.4.x)

I would just remove apache24-devel and upgrade the apache2 port to 2.4.x

> So both ports would essentially just be renamed, preserving everything about 
> them. Do you guys see a problem with that? I could do it if you don’t….

-- 
Daniel J. Luke



___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Apache2 rev bump for OpenSSL update

[Juan Manuel Palacios]

> On Mar 3, 2016, at 11:08 AM, Ryan Schmidt  wrote:
> 
>> 
>> On Mar 3, 2016, at 9:21 AM, Daniel J. Luke  wrote:
>> 
>> On Mar 3, 2016, at 3:05 AM, Ryan Schmidt  wrote:
>>> On Mar 3, 2016, at 00:18, Juan Manuel Palacios  wrote:
 
 Apache 2 rev-bumped, cf. r146274.
 
 On a side note, and if I may in this same thread, do we have any policy 
 for not moving the Apache 2.4 port out of “dev”?  Not too sure when it 
 became the recommended release series by the ASF, but it certainly isn’t 
 dev any longer.
>>> 
>>> There's a ticket you can read. We can't just replace the current apache2 
>>> port with the current apache24-devel port because it also changes the 
>>> directory layout.
>> 
>> I think it's a mistake to tie upgrading the apache port to 2.4.x and 
>> changing the layout (we could just do a simple version bump with the current 
>> port + make modifications to any apache modules that need them and tackle 
>> changing the layout separately).
> 
> Yes I think you've said that before. I don't disagree at this point, but I'm 
> not working on this issue right now. Someone else is welcome to.

The approach I suggested wouldn’t change layout in any way. apache2 would be 
obsoleted and replaced by apache22, which would be the exact same port as the 
previous apache2. Parallel to that, apache24-devel would be obsoleted and 
replaced by apache24, which again would be the exact same port as the one it’s 
replacing. This would create suite of Apache ports similar to what we now have 
for MySQL, i.e. mysql51, mysql55, mysql56, etc.

So both ports would essentially just be renamed, preserving everything about 
them. Do you guys see a problem with that? I could do it if you don’t….


-jmpp
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Apache2 rev bump for OpenSSL update

[Ryan Schmidt]

> On Mar 3, 2016, at 9:21 AM, Daniel J. Luke  wrote:
> 
> On Mar 3, 2016, at 3:05 AM, Ryan Schmidt  wrote:
>> On Mar 3, 2016, at 00:18, Juan Manuel Palacios  wrote:
>>> 
>>> Apache 2 rev-bumped, cf. r146274.
>>> 
>>> On a side note, and if I may in this same thread, do we have any policy for 
>>> not moving the Apache 2.4 port out of “dev”?  Not too sure when it became 
>>> the recommended release series by the ASF, but it certainly isn’t dev any 
>>> longer.
>> 
>> There's a ticket you can read. We can't just replace the current apache2 
>> port with the current apache24-devel port because it also changes the 
>> directory layout.
> 
> I think it's a mistake to tie upgrading the apache port to 2.4.x and changing 
> the layout (we could just do a simple version bump with the current port + 
> make modifications to any apache modules that need them and tackle changing 
> the layout separately).

Yes I think you've said that before. I don't disagree at this point, but I'm 
not working on this issue right now. Someone else is welcome to.


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Apache2 rev bump for OpenSSL update

[Daniel J. Luke]

On Mar 3, 2016, at 3:05 AM, Ryan Schmidt  wrote:
> On Mar 3, 2016, at 00:18, Juan Manuel Palacios  wrote:
>> 
>> Apache 2 rev-bumped, cf. r146274.
>> 
>> On a side note, and if I may in this same thread, do we have any policy for 
>> not moving the Apache 2.4 port out of “dev”?  Not too sure when it became 
>> the recommended release series by the ASF, but it certainly isn’t dev any 
>> longer.
> 
> There's a ticket you can read. We can't just replace the current apache2 port 
> with the current apache24-devel port because it also changes the directory 
> layout.

I think it's a mistake to tie upgrading the apache port to 2.4.x and changing 
the layout (we could just do a simple version bump with the current port + make 
modifications to any apache modules that need them and tackle changing the 
layout separately).

-- 
Daniel J. Luke



___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Apache2 rev bump for OpenSSL update

[Juan Manuel Palacios]

Yeah, that I understand, we keep versioned ports for other packages too, e.g. 
mysql55, mysql56, mysql57, and other examples. And we don’t replace one with 
the other for a myriad of reasons.

So we could deprecate the apache24-devel port and create apache24, maybe even 
also deprecating apache2 and eventually replacing it with apache22, which 
needless to say would be compatible with the former, and would live on in 
parallel to apache24, just as mysql55 does to mysql56, etc.

You have a URL for that ticket that you mention?

> On Mar 3, 2016, at 3:35 AM, Ryan Schmidt  wrote:
> 
> On Mar 3, 2016, at 00:18, Juan Manuel Palacios  wrote:
>> 
>> Apache 2 rev-bumped, cf. r146274.
>> 
>> On a side note, and if I may in this same thread, do we have any policy for 
>> not moving the Apache 2.4 port out of “dev”?  Not too sure when it became 
>> the recommended release series by the ASF, but it certainly isn’t dev any 
>> longer.
> 
> There's a ticket you can read. We can't just replace the current apache2 port 
> with the current apache24-devel port because it also changes the directory 
> layout. 

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Apache2 rev bump for OpenSSL update

[Ryan Schmidt]

On Mar 3, 2016, at 00:18, Juan Manuel Palacios  wrote:
> 
> Apache 2 rev-bumped, cf. r146274.
> 
> On a side note, and if I may in this same thread, do we have any policy for 
> not moving the Apache 2.4 port out of “dev”?  Not too sure when it became the 
> recommended release series by the ASF, but it certainly isn’t dev any longer.

There's a ticket you can read. We can't just replace the current apache2 port 
with the current apache24-devel port because it also changes the directory 
layout. 
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Apache2 rev bump for OpenSSL update

[Bradley Giesbrecht]

Done in:
https://trac.macports.org/changeset/146276
https://trac.macports.org/changeset/146277

Regards,
Bradley Giesbrecht (pixilla)




> On Mar 2, 2016, at 7:03 PM, Bradley Giesbrecht  wrote:
> 
> All the mysql ports with the exception of mysql5 are revbumped by 
> incrementing the revision_client var just after the version number in the 
> Portfile.
> 
> $ port echo name:^\(mariadb[0-9.-]*\|percona\|mysql5[0-9]*\)$
> mariadb 
> mariadb-10.0
> mariadb-10.1
> mysql5  
> mysql51 
> mysql55 
> mysql56 
> mysql57 
> percona 
> 
> I can do it, is this the openssl revision to reference in the commit message?
> https://trac.macports.org/changeset/146162
> 
> 
> Regards,
> Bradley Giesbrecht (pixilla)
> 
> 
> 
> 
>> On Mar 2, 2016, at 5:42 PM, Juan Manuel Palacios  wrote:
>> 
>> True enough. I’ll at least take care of the Apache 2 port in a bit if no one 
>> beats me to it, and I’ll see what can be done for the MySQL ports.
>> 
>>> On Mar 2, 2016, at 9:10 PM, Ryan Schmidt  wrote:
>>> 
>>> On Mar 2, 2016, at 7:32 PM, Juan Manuel Palacios  wrote:
 
> On Mar 2, 2016, at 9:00 PM, Ryan Schmidt  wrote:
> 
> On Mar 2, 2016, at 14:10, Juan Manuel Palacios  wrote:
>> 
>> Hey Ryan,
>> 
>> The Apache 2 port is failing a reload with the "Symbol not found: 
>> _SSLv2_client_method” error (Referenced from: 
>> /opt/local/apache2/modules/mod_ssl.so\n  Expected in: 
>> /opt/local/lib/libssl.1.0.0.dylib) due to the recent OpenSSL update, 
>> which removed SSLv2.
>> 
>> Shouldn’t we rev bump the Apache 2 port to force a rebuild against the 
>> new OpenSSL?
> 
> And all the other ports that link with openssl. 
 
 Indeed, but I aint maintainer ;)
 
 I got Apache to work simply by forcing a rebuild against new OpenSSL.
>>> 
>>> 
>>> I consider it the responsibility of the committer who updated the openssl 
>>> port to the version that changed its library ABI to revbump the ports that 
>>> link with it, regardless of maintainer status. It should have been done at 
>>> the same time that openssl was updated of course. I'm not working on it so 
>>> someone else is welcome to do it.
>>> 
>>> 
>>> 
>> 
>> ___
>> macports-dev mailing list
>> macports-dev@lists.macosforge.org
>> https://lists.macosforge.org/mailman/listinfo/macports-dev
> 

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Apache2 rev bump for OpenSSL update

[Juan Manuel Palacios]

Apache 2 rev-bumped, cf. r146274.

On a side note, and if I may in this same thread, do we have any policy for not 
moving the Apache 2.4 port out of “dev”?  Not too sure when it became the 
recommended release series by the ASF, but it certainly isn’t dev any longer.

> On Mar 2, 2016, at 10:38 PM, Juan Manuel Palacios  wrote:
> 
> Yeah, that’s the one!
> 
>> On Mar 2, 2016, at 10:33 PM, Bradley Giesbrecht  wrote:
>> 
>> All the mysql ports with the exception of mysql5 are revbumped by 
>> incrementing the revision_client var just after the version number in the 
>> Portfile.
>> 
>> $ port echo name:^\(mariadb[0-9.-]*\|percona\|mysql5[0-9]*\)$
>> mariadb 
>> mariadb-10.0
>> mariadb-10.1
>> mysql5  
>> mysql51 
>> mysql55 
>> mysql56 
>> mysql57 
>> percona 
>> 
>> I can do it, is this the openssl revision to reference in the commit message?
>> https://trac.macports.org/changeset/146162
>> 
>> 
>> Regards,
>> Bradley Giesbrecht (pixilla)
>> 
>> 
>> 
>> 
>>> On Mar 2, 2016, at 5:42 PM, Juan Manuel Palacios  wrote:
>>> 
>>> True enough. I’ll at least take care of the Apache 2 port in a bit if no 
>>> one beats me to it, and I’ll see what can be done for the MySQL ports.
>>> 
 On Mar 2, 2016, at 9:10 PM, Ryan Schmidt  wrote:
 
 On Mar 2, 2016, at 7:32 PM, Juan Manuel Palacios  wrote:
> 
>> On Mar 2, 2016, at 9:00 PM, Ryan Schmidt  wrote:
>> 
>> On Mar 2, 2016, at 14:10, Juan Manuel Palacios  wrote:
>>> 
>>> Hey Ryan,
>>> 
>>> The Apache 2 port is failing a reload with the "Symbol not found: 
>>> _SSLv2_client_method” error (Referenced from: 
>>> /opt/local/apache2/modules/mod_ssl.so\n  Expected in: 
>>> /opt/local/lib/libssl.1.0.0.dylib) due to the recent OpenSSL update, 
>>> which removed SSLv2.
>>> 
>>> Shouldn’t we rev bump the Apache 2 port to force a rebuild against the 
>>> new OpenSSL?
>> 
>> And all the other ports that link with openssl. 
> 
> Indeed, but I aint maintainer ;)
> 
> I got Apache to work simply by forcing a rebuild against new OpenSSL.
 
 
 I consider it the responsibility of the committer who updated the openssl 
 port to the version that changed its library ABI to revbump the ports that 
 link with it, regardless of maintainer status. It should have been done at 
 the same time that openssl was updated of course. I'm not working on it so 
 someone else is welcome to do it.
 
 
 
>>> 
>>> ___
>>> macports-dev mailing list
>>> macports-dev@lists.macosforge.org
>>> https://lists.macosforge.org/mailman/listinfo/macports-dev
>> 
> 
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Apache2 rev bump for OpenSSL update

[Juan Manuel Palacios]

True enough. I’ll at least take care of the Apache 2 port in a bit if no one 
beats me to it, and I’ll see what can be done for the MySQL ports.

> On Mar 2, 2016, at 9:10 PM, Ryan Schmidt  wrote:
> 
> On Mar 2, 2016, at 7:32 PM, Juan Manuel Palacios  wrote:
>> 
>>> On Mar 2, 2016, at 9:00 PM, Ryan Schmidt  wrote:
>>> 
>>> On Mar 2, 2016, at 14:10, Juan Manuel Palacios  wrote:
 
 Hey Ryan,
 
 The Apache 2 port is failing a reload with the "Symbol not found: 
 _SSLv2_client_method” error (Referenced from: 
 /opt/local/apache2/modules/mod_ssl.so\n  Expected in: 
 /opt/local/lib/libssl.1.0.0.dylib) due to the recent OpenSSL update, which 
 removed SSLv2.
 
 Shouldn’t we rev bump the Apache 2 port to force a rebuild against the new 
 OpenSSL?
>>> 
>>> And all the other ports that link with openssl. 
>> 
>> Indeed, but I aint maintainer ;)
>> 
>> I got Apache to work simply by forcing a rebuild against new OpenSSL.
> 
> 
> I consider it the responsibility of the committer who updated the openssl 
> port to the version that changed its library ABI to revbump the ports that 
> link with it, regardless of maintainer status. It should have been done at 
> the same time that openssl was updated of course. I'm not working on it so 
> someone else is welcome to do it.
> 
> 
> 

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Apache2 rev bump for OpenSSL update

[Ryan Schmidt]

On Mar 2, 2016, at 7:32 PM, Juan Manuel Palacios  wrote:
> 
>> On Mar 2, 2016, at 9:00 PM, Ryan Schmidt  wrote:
>> 
>> On Mar 2, 2016, at 14:10, Juan Manuel Palacios  wrote:
>>> 
>>> Hey Ryan,
>>> 
>>> The Apache 2 port is failing a reload with the "Symbol not found: 
>>> _SSLv2_client_method” error (Referenced from: 
>>> /opt/local/apache2/modules/mod_ssl.so\n  Expected in: 
>>> /opt/local/lib/libssl.1.0.0.dylib) due to the recent OpenSSL update, which 
>>> removed SSLv2.
>>> 
>>> Shouldn’t we rev bump the Apache 2 port to force a rebuild against the new 
>>> OpenSSL?
>> 
>> And all the other ports that link with openssl. 
> 
> Indeed, but I aint maintainer ;)
> 
> I got Apache to work simply by forcing a rebuild against new OpenSSL.


I consider it the responsibility of the committer who updated the openssl port 
to the version that changed its library ABI to revbump the ports that link with 
it, regardless of maintainer status. It should have been done at the same time 
that openssl was updated of course. I'm not working on it so someone else is 
welcome to do it.



___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Apache2 rev bump for OpenSSL update

[Ryan Schmidt]

On Mar 2, 2016, at 14:10, Juan Manuel Palacios  wrote:
> 
> Hey Ryan,
> 
> The Apache 2 port is failing a reload with the "Symbol not found: 
> _SSLv2_client_method” error (Referenced from: 
> /opt/local/apache2/modules/mod_ssl.so\n  Expected in: 
> /opt/local/lib/libssl.1.0.0.dylib) due to the recent OpenSSL update, which 
> removed SSLv2.
> 
> Shouldn’t we rev bump the Apache 2 port to force a rebuild against the new 
> OpenSSL?

And all the other ports that link with openssl. 
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Apache2 rev bump for OpenSSL update

[Juan Manuel Palacios]

Hey Ryan,

The Apache 2 port is failing a reload with the "Symbol not found: 
_SSLv2_client_method” error (Referenced from: 
/opt/local/apache2/modules/mod_ssl.so\n  Expected in: 
/opt/local/lib/libssl.1.0.0.dylib) due to the recent OpenSSL update, which 
removed SSLv2.

Shouldn’t we rev bump the Apache 2 port to force a rebuild against the new 
OpenSSL?
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev