The hppa port is now moved out of ports.

[Carlos O'Donell]

Joseph,

The hppa port is now in libc.

The disassembly of the shared libraries appears identical.

The hppa port doesn't depend on any other ports ports
so no #includes needed adjusting.

The hppa port uses the preferred sysdeps/unix/sysv/linux/hppa/nptl.

The move ChangeLog entry was added to the top-level ChangeLog
indicating that hppa now uses that top-level ChangeLog.

There are no more ports left in ports.

Is there any other next step (other than fixing
up more of the hppa port)?

Cheers,
Carlos.

[Joseph S. Myers]

Post by Carlos O'Donell
Joseph,
The hppa port is now in libc.
The disassembly of the shared libraries appears identical.

Good ... since I was a bit concerned about any possible effects from the
removal of trailing whitespace in the long-double-fcts setting (see
<https://sourceware.org/ml/libc-ports/2013-06/msg00004.html> and
<https://sourceware.org/ml/libc-ports/2013-05/msg00070.html>).

Post by Carlos O'Donell
Is there any other next step (other than fixing
up more of the hppa port)?

Well, removing ports/README, leaving the directory containing just
ChangeLog files. But, yes, fixing all the hppa issues from
<https://sourceware.org/glibc/wiki/PortStatus> (all of which except the
bits needing checking against the ABIs of old binaries should be very
quick to fix).

[Carlos O'Donell]

Post by Joseph S. Myers

Post by Carlos O'Donell
Joseph,
The hppa port is now in libc.
The disassembly of the shared libraries appears identical.

Good ... since I was a bit concerned about any possible effects from the
removal of trailing whitespace in the long-double-fcts setting (see
<https://sourceware.org/ml/libc-ports/2013-06/msg00004.html> and
<https://sourceware.org/ml/libc-ports/2013-05/msg00070.html>).

The disassembly is identical given some local patches I still have
and still get applied to gentoo and debian.

In practice it only matters that long-double-fcts is equal to exactly
"yes", but "no" or "no " is never used anywhere to make lists of
functions or ojbects or anything of that nature.

Post by Joseph S. Myers

Post by Carlos O'Donell
Is there any other next step (other than fixing
up more of the hppa port)?

Well, removing ports/README, leaving the directory containing just
ChangeLog files. But, yes, fixing all the hppa issues from
<https://sourceware.org/glibc/wiki/PortStatus> (all of which except the
bits needing checking against the ABIs of old binaries should be very
quick to fix).

Done. I've removed README, and updated all ChangeLog.* for machines
which were moved to libc proper with the normal header you were
using. I've carried out the final update to ports/ChangeLog to
indicate README is removed and ports is no longer in use.

Please feel free to add stronger wording or another README that
says "Not in use." I think we're done with the source tree.

I have updated the website to say:

* New port discussions should be on libc-alpha.

* Use libc-ports to highlight cross-port issues so maintainers
need not pay close attention to libc-alpha.

* After the 2.19 release the ports add-on was merged back into
core project and is no longer used.

Cheers,
Carlos.

[Joseph S. Myers]

Post by Carlos O'Donell
* Use libc-ports to highlight cross-port issues so maintainers
need not pay close attention to libc-alpha.

I thought the conclusion was not to do that (that I was the only person
suggesting repurposing libc-ports like that), but developers not updating
all ports have the responsibility to draw attention to that fact and
update <https://sourceware.org/glibc/wiki/PortStatus> when checking in the
patch that only updates some ports.

[Carlos O'Donell]

Post by Joseph S. Myers

Post by Carlos O'Donell
* Use libc-ports to highlight cross-port issues so maintainers
need not pay close attention to libc-alpha.

I thought the conclusion was not to do that (that I was the only person
suggesting repurposing libc-ports like that), but developers not updating
all ports have the responsibility to draw attention to that fact and
update <https://sourceware.org/glibc/wiki/PortStatus> when checking in the
patch that only updates some ports.

So what did we decide we were going to do with libc-ports?

Once I answer that question I can go back and update the website
with the correct information.

Cheers,
Carlos.

[Joseph S. Myers]

Post by Carlos O'Donell

Post by Joseph S. Myers

Post by Carlos O'Donell
* Use libc-ports to highlight cross-port issues so maintainers
need not pay close attention to libc-alpha.

I thought the conclusion was not to do that (that I was the only person
suggesting repurposing libc-ports like that), but developers not updating
all ports have the responsibility to draw attention to that fact and
update <https://sourceware.org/glibc/wiki/PortStatus> when checking in the
patch that only updates some ports.

So what did we decide we were going to do with libc-ports?

I believe we decided to stop using libc-ports altogether.

[Carlos O'Donell]

Post by Joseph S. Myers

Post by Carlos O'Donell

Post by Joseph S. Myers

Post by Carlos O'Donell
* Use libc-ports to highlight cross-port issues so maintainers
need not pay close attention to libc-alpha.

I thought the conclusion was not to do that (that I was the only person
suggesting repurposing libc-ports like that), but developers not updating
all ports have the responsibility to draw attention to that fact and
update <https://sourceware.org/glibc/wiki/PortStatus> when checking in the
patch that only updates some ports.

So what did we decide we were going to do with libc-ports?

I believe we decided to stop using libc-ports altogether.

You have a better memory than I so I trust that.

The website has been updated to reflect this.

Thanks for the review.

Cheers,
Carlos.

[Roland McGrath]

I've added some deprecation header text to the ports/ChangeLog* files that
lacked it. I've then moved ports/ChangeLog* to ChangeLog.old-ports* so
that there is no longer a ports/ subdirectory at all. Huzzah.

I think we should now discontinue use of the libc-ports mailing list.
The mailing list configuration should be left around at least as much
as is required to keep the archives accessible on the web. Beyond
that, I think we should now ask overseers to change it either so that
mailing libc-ports bounces or so that libc-ports just redirects to
libc-alpha. Objections?


Thanks,
Roland

[Carlos O'Donell]

Post by Roland McGrath
I've added some deprecation header text to the ports/ChangeLog* files that
lacked it. I've then moved ports/ChangeLog* to ChangeLog.old-ports* so
that there is no longer a ports/ subdirectory at all. Huzzah.
I think we should now discontinue use of the libc-ports mailing list.
The mailing list configuration should be left around at least as much
as is required to keep the archives accessible on the web. Beyond
that, I think we should now ask overseers to change it either so that
mailing libc-ports bounces or so that libc-ports just redirects to
libc-alpha. Objections?

No objections from me.

The website is already updated to indicate libc-ports is now historical
like libc-hacker.

Cheers,
Carlos.