Releasing 2.4.3

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Releasing 2.4.3

Rainer Müller-4
Hello,

according to our milestone on Trac, there is nothing left to be fixed or
backported to the release-2.4 branch for MacPorts 2.4.3.

The ChangeLog was already updated and reflects the changes this release
will contain:
https://github.com/macports/macports-base/blob/release-2.4/ChangeLog

See also the full details in the commit log and corresponding tickets:

https://github.com/macports/macports-base/compare/v2.4.2...release-2.4
https://trac.macports.org/milestone/MacPorts%202.4.3

If nobody objects, I am going to tag a new release on Tuesday and
prepare tarballs.

Should I wait with publishing the update over selfupdate until we also
have installer packages ready?

Rainer
Reply | Threaded
Open this post in threaded view
|

Re: Releasing 2.4.3

Eric A. Borisch-2
[Sending from the correct address this time]

I'd still like to see the opportunistic (via libarchive / bsdtar) compression (pull request #45) integrated at some point; with modern machines and their soldered-down storage, it's all the more useful.

Shall I open a ticket in trac as a feature request for 2.5?

On Mon, Apr 9, 2018 at 5:15 PM, Rainer Müller <[hidden email]> wrote:
Hello,

according to our milestone on Trac, there is nothing left to be fixed or
backported to the release-2.4 branch for MacPorts 2.4.3.

The ChangeLog was already updated and reflects the changes this release
will contain:
https://github.com/macports/macports-base/blob/release-2.4/ChangeLog

See also the full details in the commit log and corresponding tickets:

https://github.com/macports/macports-base/compare/v2.4.2...release-2.4
https://trac.macports.org/milestone/MacPorts%202.4.3

If nobody objects, I am going to tag a new release on Tuesday and
prepare tarballs.

Should I wait with publishing the update over selfupdate until we also
have installer packages ready?

Rainer

Reply | Threaded
Open this post in threaded view
|

Re: Releasing 2.4.3

Ryan Schmidt-24

On Apr 9, 2018, at 22:43, Eric A. Borisch wrote:

> I'd still like to see the opportunistic (via libarchive / bsdtar) compression (pull request #45) integrated at some point; with modern machines and their soldered-down storage, it's all the more useful.

Sure, but this thread is about 2.4.3, a bugfix release. New features won't go into a bugfix release.


> Shall I open a ticket in trac as a feature request for 2.5?

A ticket already exists for that feature: https://trac.macports.org/ticket/36560

Reply | Threaded
Open this post in threaded view
|

Re: Releasing 2.4.3

Ryan Schmidt-24
In reply to this post by Rainer Müller-4

On Apr 9, 2018, at 17:15, Rainer Müller wrote:

> If nobody objects, I am going to tag a new release on Tuesday and
> prepare tarballs.

Please merge my other two commits from this ticket:

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

My first commit, which you merged, was buggy and needed fixing.


> Should I wait with publishing the update over selfupdate until we also
> have installer packages ready?

Sure?


Reply | Threaded
Open this post in threaded view
|

Re: Releasing 2.4.3

Mojca Miklavec-2
In reply to this post by Rainer Müller-4
On 10 April 2018 at 00:15, Rainer Müller wrote:
>
> If nobody objects, I am going to tag a new release on Tuesday and
> prepare tarballs.

In case you didn't do the tagging yet, I would suggest cherry-picking
also the commit which adds "size ..." to checksums. While this is not
strictly a bugfix, if we want maintainers to add this field, we should
at least generate it automatically.

Mojca
Reply | Threaded
Open this post in threaded view
|

Re: Releasing 2.4.3

Ryan Schmidt-24
In reply to this post by Ryan Schmidt-24

On Apr 10, 2018, at 12:07, Ryan Schmidt wrote:

> On Apr 9, 2018, at 17:15, Rainer Müller wrote:
>
>> If nobody objects, I am going to tag a new release on Tuesday and
>> prepare tarballs.
>
> Please merge my other two commits from this ticket:
>
> https://trac.macports.org/ticket/55492
>
> My first commit, which you merged, was buggy and needed fixing.

Do you want to merge this performance enhancement too:


macports_util: Optimize lshift and lunshift

https://github.com/macports/macports-base/commit/cf998981c078c9804f1f8e0ce245796278876474


And these bugfixes:


port: Add missing -N flag to usage

https://github.com/macports/macports-base/commit/80d65609e11fc0b32f0f5f86e0696d9e244f7707


port: Remove misleading [privopts] from usage

https://github.com/macports/macports-base/commit/f166b4809f88ddbb7fe77a495d5159fc87f764a4


reclaim: Split distfile into filename and disttag

https://github.com/macports/macports-base/commit/3ad97625cc57d26e333dcdf06dc0d932f002056a


Update copyright year

https://github.com/macports/macports-base/commit/fa20ccb51e64fb2773125a1e5bd392a2fe322c90


Update Apple developer site URL in readme

https://github.com/macports/macports-base/commit/9f7ffde631117650b96641595f626512409a3cbb


Add link to Guide to readme

https://github.com/macports/macports-base/commit/a3e250224da7667b4970f381878d5cd9c7fc6df2


HACKING: Add links to the MacPorts Guide

https://github.com/macports/macports-base/commit/d7fd81a85065c29092e71743716004ba0eb578b2


reclaim.tcl: don't ask for partial removal

https://github.com/macports/macports-base/commit/3578400bf5f593c92b1bc412a45776fe55c0db78


port mirror: Respect special license NoMirror

https://github.com/macports/macports-base/commit/fae17c2c7b97f2c6b8d9ab527ef6776b93353a00


tests: Avoid bogus error message during test runs

https://github.com/macports/macports-base/commit/4c11f3bea113e305776751e98d5236e34175a972


tests: Fix test failure due to missing SVN command

https://github.com/macports/macports-base/commit/ea77eb50b06f009629afb95321f0d5cd932c070b


tests: Remove non-existing constraint from test

https://github.com/macports/macports-base/commit/0745d2d4efcbe082e13828f31c2c594c2be0a0a4


tests: Avoid using network in port1.0 unit tests

https://github.com/macports/macports-base/commit/521e0143893f89c35f084205f9230fbd24e30165


The three commits for using MacPorts svn on newer macOS versions to fix fetch failures:

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


The two commits for using MacPorts git on newer macOS versions to fix fetch failures:

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


Fix trace mode when using ccache-devel:

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


Add size to default checksums:

https://github.com/macports/macports-base/commit/95a153e6a4bff8b99502806960c916a2b5d20504


Correct default value of distpath in docs

https://github.com/macports/macports-base/commit/b7e7fe52d7e6450181232ee635597fff56722c69


Don't allow non-integer epoch or revision

https://github.com/macports/macports-base/commit/387cd8ca7c7a54a38ea24fc1d698444720dfa8eb


Remove lint check for non-integer revision, epoch

https://github.com/macports/macports-base/commit/dcf6a81c69556b0c03b508122f176f01f9d8da1e


Reply | Threaded
Open this post in threaded view
|

Re: Releasing 2.4.3

Rainer Müller-4
In reply to this post by Ryan Schmidt-24
On 2018-04-10 19:07, Ryan Schmidt wrote:

>
> On Apr 9, 2018, at 17:15, Rainer Müller wrote:
>
>> If nobody objects, I am going to tag a new release on Tuesday and
>> prepare tarballs.
>
> Please merge my other two commits from this ticket:
>
> https://trac.macports.org/ticket/55492
>
> My first commit, which you merged, was buggy and needed fixing.

Thanks for noticing. I cherry-picked the other two commits now.

https://github.com/macports/macports-base/commit/47d219119281a5f574ee6298c9e731293bca464e

https://github.com/macports/macports-base/commit/a98fe3b89fba99f8bb873663f85a04831718583b

>> Should I wait with publishing the update over selfupdate until we also
>> have installer packages ready?
>
> Sure?

New releases could be made available via selfupdate immediately. Old
installers will already always selfupdate to the latest version
automatically, so the the result is the same anyway when using on older
installer.

Building package installers is the most time-consuming operation in our
release process. Therefore I was asking whether it is actually worth to
wait for them to appear before releasing to selfupdate.

However, for 2.4.3, Joshua will tag the release instead, as he is also
going to build installers right away.

Rainer
Reply | Threaded
Open this post in threaded view
|

Re: Releasing 2.4.3

Ryan Schmidt-24
I am not comfortable releasing a version of MacPorts that includes a MacPorts gcc in the default compiler list (which 2.4.3 now does) without having answered the new-vs-old ABI question satisfactorily. I believe releasing that will lead to the libstdc++ mismatch crashes that were the reason why we previously strongly prohibited the use of MacPorts gcc for C++ code:

https://lists.macports.org/pipermail/macports-dev/2018-March/037829.html

I had hoped Jeremy H would weigh in, but I don't think he has yet.

Or did we reach a consensus on how we would handle this, and I've forgotten?

Reply | Threaded
Open this post in threaded view
|

Re: Releasing 2.4.3

Ryan Schmidt-24
In reply to this post by Rainer Müller-4

On Apr 10, 2018, at 12:44, Rainer Müller wrote:

> Building package installers is the most time-consuming operation in our
> release process. Therefore I was asking whether it is actually worth to
> wait for them to appear before releasing to selfupdate.

I am rebuilding our installer creation process to hopefully make this much easier for MacPorts 2.5 and later.

Reply | Threaded
Open this post in threaded view
|

Re: Releasing 2.4.3

Rainer Müller-4
In reply to this post by Ryan Schmidt-24
On 2018-04-10 19:39, Ryan Schmidt wrote:

>
> On Apr 10, 2018, at 12:07, Ryan Schmidt wrote:
>
>> On Apr 9, 2018, at 17:15, Rainer Müller wrote:
>>
>>> If nobody objects, I am going to tag a new release on Tuesday and
>>> prepare tarballs.
>>
>> Please merge my other two commits from this ticket:
>>
>> https://trac.macports.org/ticket/55492
>>
>> My first commit, which you merged, was buggy and needed fixing.
>
> Do you want to merge this performance enhancement too:

At some point we should make a cut and not add many changes in the last
minute...

I do not want to delay 2.4.3 any longer to finally release the fix for
the broken trace mode on High Sierra.

I would save reviewing and backporting of these fixes for a 2.4.4 soon
after.

Rainer
Reply | Threaded
Open this post in threaded view
|

Re: Releasing 2.4.3

Ryan Schmidt-24

On Apr 10, 2018, at 12:54, Rainer Müller wrote:

>
> On 2018-04-10 19:39, Ryan Schmidt wrote:
>>
>> On Apr 10, 2018, at 12:07, Ryan Schmidt wrote:
>>
>>> On Apr 9, 2018, at 17:15, Rainer Müller wrote:
>>>
>>>> If nobody objects, I am going to tag a new release on Tuesday and
>>>> prepare tarballs.
>>>
>>> Please merge my other two commits from this ticket:
>>>
>>> https://trac.macports.org/ticket/55492
>>>
>>> My first commit, which you merged, was buggy and needed fixing.
>>
>> Do you want to merge this performance enhancement too:
>
> At some point we should make a cut and not add many changes in the last
> minute...

Well I can't force you to merge them.


> I do not want to delay 2.4.3 any longer to finally release the fix for
> the broken trace mode on High Sierra.

I don't want to release 2.4.3 with the libstdc++ ABI issue unanswered. I believe it will cause problems.


> I would save reviewing and backporting of these fixes for a 2.4.4 soon
> after.

Reply | Threaded
Open this post in threaded view
|

Re: Releasing 2.4.3

Rainer Müller-4
On 2018-04-10 20:26, Ryan Schmidt wrote:
>
> On Apr 10, 2018, at 12:54, Rainer Müller wrote:
>>
>> At some point we should make a cut and not add many changes in the last
>> minute...
>
> Well I can't force you to merge them.

I cannot stop you either... I am just afraid that by merging changes in
the last minute we are likely to introduce problems we did not think of
before. Not all changes in backported commits can be applied cleanly as
master and release-2.4 diverged, so they might need to be modified.

The decision whether to merge them or not would be by Joshua now, as he
is going to tag the release.

>> I do not want to delay 2.4.3 any longer to finally release the fix for
>> the broken trace mode on High Sierra.
>
> I don't want to release 2.4.3 with the libstdc++ ABI issue unanswered. I believe it will cause problems.

Then we should revert this change for 2.4.3 and we have one more reason
to go for a 2.4.4 release.

Rainer
Reply | Threaded
Open this post in threaded view
|

Re: Releasing 2.4.3

Ken Cunningham


On 2018-04-10, at 11:47 AM, Rainer Müller wrote:

I don't want to release 2.4.3 with the libstdc++ ABI issue unanswered. I believe it will cause problems.

Then we should revert this change for 2.4.3 and we have one more reason
to go for a 2.4.4 release.

Rainer


I would have like to set libgcc to ABI4 mode, at least on PPC, to fix this forever, but Jeremy felt this was undesirable. Perhaps we might still consider doing that, though, at least on PPC.

Two other easy options: 

1. add the required *ABI=0 flag by default to all cxx builds on PPC. This would be completely fine I believe. More desirable.


2. wait for builds to fail to link (they will, on 10.6 to 10.8 and PPC if the linking doesn't work, as we have all seen) then add the cxx11 PortGroup as we do now when we see this failure. Less desirable.



or revert it if you want, and we can do it some day in the future.

Best,

ken


Ken
Reply | Threaded
Open this post in threaded view
|

Re: Releasing 2.4.3

Ryan Schmidt-24

On Apr 10, 2018, at 13:55, Ken Cunningham wrote:

> On 2018-04-10, at 11:47 AM, Rainer Müller wrote:
>>>
>>> I don't want to release 2.4.3 with the libstdc++ ABI issue unanswered. I believe it will cause problems.
>>
>> Then we should revert this change for 2.4.3 and we have one more reason
>> to go for a 2.4.4 release.
>>
>> Rainer
>
>
> I would have like to set libgcc to ABI4 mode, at least on PPC, to fix this forever, but Jeremy felt this was undesirable. Perhaps we might still consider doing that, though, at least on PPC.
>
> Two other easy options:
>
> 1. add the required *ABI=0 flag by default to all cxx builds on PPC. This would be completely fine I believe. More desirable.

And then after MacPorts 2.4.3 release, revbump any ports that were built with *ABI=1, and add to them an invocation of macports_version and vercmp to ensure they're being rebuilt by 2.4.3 or later.


> 2. wait for builds to fail to link (they will, on 10.6 to 10.8 and PPC if the linking doesn't work, as we have all seen) then add the cxx11 PortGroup as we do now when we see this failure. Less desirable.

Mixing libc++ and libstdc++ results in a link failure. Mixing old libstdc++ and new libstdc++ did not previously result in a link failure; it resulted in a runtime crash which was difficult to diagnose and attribute to this problem. That was back before gcc5. I don't know things have changed.

Reply | Threaded
Open this post in threaded view
|

Re: Releasing 2.4.3

Ken Cunningham

On 2018-04-10, at 12:02 PM, Ryan Schmidt wrote:

>
> On Apr 10, 2018, at 13:55, Ken Cunningham wrote:

> Mixing libc++ and libstdc++ results in a link failure. Mixing old libstdc++ and new libstdc++ did not previously result in a link failure; it resulted in a runtime crash which was difficult to diagnose and attribute to this problem. That was back before gcc5. I don't know things have changed.
>

Mixing the old libstdc++ and the new libstdc++ usually results in a std::c++11__::something link failure, from what I have seen.

I have never seen a runtime crash, although I haven't been doing this for years and years like some of you.

Anyway, less desirable option, to be sure.

Best,

Ken
Reply | Threaded
Open this post in threaded view
|

Re: Releasing 2.4.3

Ryan Schmidt-24
In reply to this post by Rainer Müller-4
On Apr 10, 2018, at 13:47, Rainer Müller wrote:

> On 2018-04-10 20:26, Ryan Schmidt wrote:
>>
>> On Apr 10, 2018, at 12:54, Rainer Müller wrote:
>>>
>>> At some point we should make a cut and not add many changes in the last
>>> minute...
>>
>> Well I can't force you to merge them.
>
> I cannot stop you either... I am just afraid that by merging changes in
> the last minute we are likely to introduce problems we did not think of
> before. Not all changes in backported commits can be applied cleanly as
> master and release-2.4 diverged, so they might need to be modified.

I'm not going to merge them, because I don't know how, and don't have the energy to attempt to learn how to do so, given the zillion other things I'm trying to do right now.

I proposed a list of commits to backport for 2.4.3 back in December. You've merged those now; thank you, but it's now 4 months later. I don't want another 4 months to go by before we bring the other critical fixes we've already committed to master to our users. The use of MacPorts git and svn on older systems spring to mind as pretty important fixes for older systems.


> The decision whether to merge them or not would be by Joshua now, as he
> is going to tag the release.

Reply | Threaded
Open this post in threaded view
|

Re: Releasing 2.4.3

Rainer Müller-4
On 2018-04-10 21:06, Ryan Schmidt wrote:
> I'm not going to merge them, because I don't know how, and don't have the energy to attempt to learn how to do so, given the zillion other things I'm trying to do right now.

This is even documented:
https://trac.macports.org/wiki/WorkingWithGit#cherrypick

> I proposed a list of commits to backport for 2.4.3 back in December. You've merged those now; thank you, but it's now 4 months later. I don't want another 4 months to go by before we bring the other critical fixes we've already committed to master to our users. The use of MacPorts git and svn on older systems spring to mind as pretty important fixes for older systems.

I do not want to wait months for a release either. I think that the long
time between releases is mainly caused by our release process.

I cannot sign package installers. As long as we insist on having them
for each and every release, I am not in the position to cut a full
release anyway.

So, what are we going to do? I already proposed not to wait for .pkg
installers and just release to selfupdate whenever the release is ready.

Rainer
Reply | Threaded
Open this post in threaded view
|

Re: Releasing 2.4.3

Rainer Müller-4
In reply to this post by Ryan Schmidt-24
On 2018-04-10 19:39, Ryan Schmidt wrote:
> Do you want to merge this performance enhancement too:

[...]

> And these bugfixes:

I assigned this to the MacPorts 2.4.4 milestone, so we do not forget
about them:

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

Rainer
Reply | Threaded
Open this post in threaded view
|

Re: Releasing 2.4.3

Joshua Root-8
In reply to this post by Ryan Schmidt-24
On 2018-4-11 03:49 , Ryan Schmidt wrote:
>
> On Apr 10, 2018, at 12:44, Rainer Müller wrote:
>
>> Building package installers is the most time-consuming operation in our
>> release process. Therefore I was asking whether it is actually worth to
>> wait for them to appear before releasing to selfupdate.
>
> I am rebuilding our installer creation process to hopefully make this much easier for MacPorts 2.5 and later.

Building them is really not all that time-consuming.

- Josh