Re: Toolchain Infrastructure project statement of support

[Christopher Faylor via Gcc]

On Sun, Oct 23, 2022 at 11:01:34AM -0600, Jeff Law wrote:
>On 10/23/22 10:07, Siddhesh Poyarekar wrote:
>>>If you're trying to suggest that overseers, contrary to our repeated
>>>public statements, wish to block all migration, that is untrue and you
>>>will need to retract this.
>>
>>Here's a more precise statement: Two of the overseers are leaders of
>>projects hosted on sourceware and three overseers (including those two)
>>have stated clearly on multiple occasions that transitioning to LF IT
>>is off the table, effectively announcing their decision on behalf of
>>projects they lead.  It is hence clear that the overseers have
>>effectively blocked full migration of sourceware to LF IT.
>
>They can make those decisions for the projects they lead.  But making
>the decision or setting criteria for other projects is highly
>unreasonable.

This is not, IMO, helping.

On Thu, Oct 13, 2022 at 02:25:29PM -0400, Christopher Faylor wrote:
>We'd like to assure the communities that, when and if any individual
>project formally expresses the decision of their developers to transfer
>their services, we'll endeavor to make the move as smooth as possible.
>Those projects that wish to stay will continue to receive the best
>services that the overseers can offer, with the ongoing assistance of
>Red Hat, the SFC, and, when relevant, the FSF tech team.

We can't help move anyone without first establishing some kind of
criteria.  The only reasonable criteria is a formal request from the
project being moved.

As an exercise in human psychology, these insinuations of anticipated
unhelpfulness *can* eventually be a self-fullfilling prophecy, though.

i.e., if you really do not *want* any help with any transitions of
projects then, just keep implying, despite evidence to the contrary,
that we might be unreasonable jerks.

Re: Toolchain Infrastructure project statement of support

[Christopher Faylor via Gcc]

vv

On Sun, Oct 23, 2022 at 06:19:33PM -0300, Alexandre Oliva wrote:
>It doesn't smell good, however, that Sourceware has been prevented from 
>presenting its own
>expansion plans and proposals at the Cauldron.  I wish it too gets a chance to 
>extend their offer.
>There's no basis for a rational decision in refusing to listen to 
>alternatives; it comes across to
>me as acknowledgment that a weaker proposal wishes to prevail by denying 
>others any consideration.

^^^

Re: Toolchain Infrastructure project statement of support

[Christopher Faylor via Gcc]

On Sun, Oct 23, 2022 at 05:17:40PM -0400, Siddhesh Poyarekar wrote:
>On 2022-10-23 16:57, Christopher Faylor wrote:
>> On Thu, Oct 13, 2022 at 02:25:29PM -0400, Christopher Faylor wrote:
>> > Re: https://sourceware.org/pipermail/overseers/2022q4/018981.html
>> > 
>> > On Wed, Oct 12, 2022 at 12:43:09PM -0400, Carlos O'Donell wrote:
>> > > The GNU Toolchain project leadership supports the proposal[1] to move the
>> > > services for the GNU Toolchain to the Linux Foundation IT under the 
>> > > auspices of
>> > > the Toolchain Infrastructure project (GTI) with fiscal sponsorship from 
>> > > the
>> > > OpenSSF and other major donors.
>> > 
>> > Noted, however, a list of signatories does not automatically confer
>> > authority over any particular project.  Any participation from
>> > overseers in moving projects to different infrastructure will require
>> > clear approval from the individual projects themselves.
>> > 
>> > Also, the FSF, being the existing fiscal sponsor to these projects,
>> > surely needs to review the formal agreements before we sunset our
>> > infrastructural offerings to glibc, gcc, binutils, and gdb and hand
>> > control of the projects' infrastructure over to a different entity.
>> > 
>> > We'd like to assure the communities that, when and if any individual
>> > project formally expresses the decision of their developers to transfer
>> > their services, we'll endeavor to make the move as smooth as possible.
>> > Those projects that wish to stay will continue to receive the best
>> > services that the overseers can offer, with the ongoing assistance of
>> > Red Hat, the SFC, and, when relevant, the FSF tech team.
>> 
>> On Sun, Oct 23, 2022 at 09:27:26AM -0400, Siddhesh Poyarekar wrote:
>> > Given that the current sourceware admins have decided to block migration of
>> > all sourceware assets to the LF IT, I don't have a stake on how they'd like
>> > to handle this for sourceware.  I could however, as a member of TAC (and as
>> > member of projects that have agreed to migrate to LF IT, i.e. gcc and 
>> > glibc),
>> > discuss with others the possibility of specific community volunteers being
>> > given some amount of access to manage infrastructure.
>> 
>> Stop spreading FUD.  The "we" in my statement above, from October 13,
>> included fche, mjw, and myself.  You have no reason to be confused on
>> this subject.
>> 
>
>Nope, I'm not spreading FUD, in fact that statement of yours is perfectly
>consistent with what I've said: the blocker at the moment is that the
>sourceware overseers have refused to hand over the server *in its entirety*
>to LF IT, not that any projects themselves have refused to move their
>services to LF IT.  I don't doubt that the overseers will help in smooth
>migration for projects that eventually state that they wish to move over.

Your initial implication was that the unreasonable overseers would hold
all projects hostage on our current infrastructure.   Now you've "clarified"
that point by implying that we've been approached to transfer the server
"in its entirety" to the LF and have unreasonably refused.

Both of those are FUD.  You're either intentionally trying to muddy the
waters or you're just confused.  I'd submit that in either case you should
just think about shutting up.  You have no special authority to speak for
the GTI TAC and your increasingly hostile messages are not helping anyone.

Re: Toolchain Infrastructure project statement of support

[Christopher Faylor via Gcc]

On Thu, Oct 13, 2022 at 02:25:29PM -0400, Christopher Faylor wrote:
>Re: https://sourceware.org/pipermail/overseers/2022q4/018981.html
>
>On Wed, Oct 12, 2022 at 12:43:09PM -0400, Carlos O'Donell wrote:
>>The GNU Toolchain project leadership supports the proposal[1] to move the
>>services for the GNU Toolchain to the Linux Foundation IT under the auspices 
>>of
>>the Toolchain Infrastructure project (GTI) with fiscal sponsorship from the
>>OpenSSF and other major donors.
>
>Noted, however, a list of signatories does not automatically confer
>authority over any particular project.  Any participation from
>overseers in moving projects to different infrastructure will require
>clear approval from the individual projects themselves.
>
>Also, the FSF, being the existing fiscal sponsor to these projects,
>surely needs to review the formal agreements before we sunset our
>infrastructural offerings to glibc, gcc, binutils, and gdb and hand
>control of the projects' infrastructure over to a different entity.
>
>We'd like to assure the communities that, when and if any individual
>project formally expresses the decision of their developers to transfer
>their services, we'll endeavor to make the move as smooth as possible.
>Those projects that wish to stay will continue to receive the best
>services that the overseers can offer, with the ongoing assistance of
>Red Hat, the SFC, and, when relevant, the FSF tech team.

On Sun, Oct 23, 2022 at 09:27:26AM -0400, Siddhesh Poyarekar wrote:
>Given that the current sourceware admins have decided to block migration of
>all sourceware assets to the LF IT, I don't have a stake on how they'd like
>to handle this for sourceware.  I could however, as a member of TAC (and as
>member of projects that have agreed to migrate to LF IT, i.e. gcc and glibc),
>discuss with others the possibility of specific community volunteers being
>given some amount of access to manage infrastructure.

Stop spreading FUD.  The "we" in my statement above, from October 13,
included fche, mjw, and myself.  You have no reason to be confused on
this subject.

Re: Toolchain Infrastructure project statement of support

[Christopher Faylor via Gcc]

On Tue, Oct 18, 2022 at 11:17:15AM -0400, Siddhesh Poyarekar wrote:
>That is not true, Mark.  Your objections and questions have been answered at
>every stage, privately as well as publicly.

Actually, going back through this thread, I see outstanding
questions/issues raised by Mark, Frank, Alexandre Oliva, Jon Corbet, and
Andrew Pinski.

Re: Toolchain Infrastructure project statement of support

[Christopher Faylor via Gcc]

Re: https://sourceware.org/pipermail/overseers/2022q4/018981.html

On Wed, Oct 12, 2022 at 12:43:09PM -0400, Carlos O'Donell wrote:
>The GNU Toolchain project leadership supports the proposal[1] to move the
>services for the GNU Toolchain to the Linux Foundation IT under the auspices of
>the Toolchain Infrastructure project (GTI) with fiscal sponsorship from the
>OpenSSF and other major donors.

Noted, however, a list of signatories does not automatically confer
authority over any particular project.  Any participation from 
overseers in moving projects to different infrastructure will require
clear approval from the individual projects themselves.

Also, the FSF, being the existing fiscal sponsor to these projects,
surely needs to review the formal agreements before we sunset our
infrastructural offerings to glibc, gcc, binutils, and gdb and hand
control of the projects' infrastructure over to a different entity.

We'd like to assure the communities that, when and if any individual
project formally expresses the decision of their developers to transfer
their services, we'll endeavor to make the move as smooth as possible. 
Those projects that wish to stay will continue to receive the best
services that the overseers can offer, with the ongoing assistance of
Red Hat, the SFC, and, when relevant, the FSF tech team.

Re: The GNU Toolchain Infrastructure Project

[Christopher Faylor via Gcc]

On Thu, Oct 06, 2022 at 10:02:19PM +0200, Mark Wielaard wrote:
>...But it would be really nice to hear directly from the Linux
>Foundation and the OpenSSF about what exactly they are proposing, which
>parts of the proposal are mandatory, which can be mixed and matched,
>and how they see this working together with Sourceware becoming a
>Software Freedom Conservancy member project.

Indeed.

The silence from the proponents of this project is puzzling.  I wonder
if this means there are more non-public negotiations going on somewhere,
leaving the community out of the loop.

cgf

Re: The GNU Toolchain Infrastructure Project

[Christopher Faylor via Gcc]

On Tue, Oct 04, 2022 at 01:17:14PM -0400, Siddhesh Poyarekar wrote:
>On 2022-10-04 13:10, Christopher Faylor wrote:
>> On Tue, Oct 04, 2022 at 09:46:08AM -0400, Siddhesh Poyarekar wrote:
>> > I made and shared this copy to dispel any further false speculation of
>> > scope creep of the GTI proposal.
>> 
>> Who is doing the false speculation?  Do you have a mailing list link?
>> It would be interesting to know who's got it wrong.
>
>Mark asked upthread if content on gnu.org is also going to be migrated over
>based on sharing of meeting minutes on the gnu.org domain.

I think you mean:

>>On Sun Oct 2 20:47:49 GMT 2022, Mark Wielaard wrote:
>This does raise the question if you are also proposing migrating
>non-sourceware services for projects like the websites of various of
>the GNU projects on www.gnu.org or the release archives at the GNU ftp
>server (and mirrors) those projects use.

Reading the meeting logs (I wasn't there and left this project shortly
after the meeting) I don't see anything that directly answers Mark's
question.  So, to me, this seems like an innocent request for
clarification rather than an attempt to push a false speculation.

There's no need to go down this rabbit hole, though.  Thanks for
clarifying.

cgf

Re: The GNU Toolchain Infrastructure Project

[Christopher Faylor via Gcc]

On Tue, Oct 04, 2022 at 09:46:08AM -0400, Siddhesh Poyarekar wrote:
>I made and shared this copy to dispel any further false speculation of
>scope creep of the GTI proposal.

Who is doing the false speculation?  Do you have a mailing list link?
It would be interesting to know who's got it wrong.

Re: Separate commit mailing lists for trunk/branches possible?

[Christopher Faylor]

On Fri, Jul 17, 2020 at 07:05:48PM +0100, Maciej W. Rozycki wrote:
> As you have probably been well-aware the amount of traffic sent to the 
> mailing list has grown dramatically since the switch 
>to GIT.  Last month alone I received over 13000 messages, which accounted 
>for ~18.5% of all my incoming traffic.  And right now another mailbomb has 
>been in progress; since midnight I have received over 3700 messages so 
>far.
>
> Most of this stuff is vendor branch stuff I find completely uninteresting 
>to me and which from my point of view is a waste of resources.  I could 
>filter it to /dev/null via `procmail', but that would still be a waste.

Actually, it seems like a procmail rule would solve your problem.

Re: Stability of pipermail ml archive URLs

[Christopher Faylor via Gcc]

On Thu, May 07, 2020 at 02:23:30PM -0500, Segher Boessenkool wrote:
>On Thu, May 07, 2020 at 11:48:18AM +0200, Thomas Schwinge wrote:
>>By the way, the public-inbox software
>>(), as recently mentioned in a
>>different thread discussing deficiencies of Mailman's Pipermail, also
>>does support this:
>>
>>(random example).  (I have not yet really looked into that software
>>myself, but from the little I read about it, it seems conceptually
>>simple, "easy", good.)
>>
>>If there's sufficient interest (users) and commitment (overseers), we
>>could install this on sourceware, in addition to what we've currently
>>got?
>
>I would very much like this.  *All* of the problems with the current
>mail archive, as well as all of the problems with the one we had
>before, do not exist with public-inbox.
>
>(It probably has problems all of its own, of course ;-) )

It's been suggested many times both before we rolled out the new
sourceware and after.

I'm not a real fan of the interface but at least it's being supported.
It's just not supported in RHEL 8 right now, as far as I know.

To reiterate our current philosophy: We're trying to use supported
software on sourceware and not have to roll our own and worry about
keeping track of upstream fixes and security issues.

Re: Stability of pipermail ml archive URLs

[Christopher Faylor]

On Thu, May 07, 2020 at 01:56:04PM -0400, Frank Ch. Eigler wrote:
>>>I was thinking we might be able to trick pipermail (the web archiver
>>>component) to simply name the message web urls after some function of
>>>the message-id instead of the sequence number.  Will give this a try
>>>very shortly.
>>
>>I just want to go on record as saying that I think this is a bad idea.
>>We can fix this problem simply without redesigning pipermail.
>
>If the idea requires more than a dozenish lines of code, then I agree
>it's not worth doing.  "redesigning" - indeed no thanks.

I'd call a major change to the way that mailman archives files a
"redesign".

>>The problem that we're seeing is caused by a script that I wrote to
>>migrate ezmlm to mailman.  The fix for the problem is "Don't run that
>>script".
>
>Yeah, but that is the official mailman2 method for this.

One recommended method is to edit the mbox file and leave the message
around but blank and then regenerate the archive.  But, that could cause
renumbering issues.

They also mention what I'm suggesting - edit the mbox and html files and
leave the content blank.  You'd have to be careful not to step on incoming
email in that scenario, of course.

https://wiki.list.org/DOC/How%20can%20I%20remove%20a%20post%20from%20the%20list%20archive%20or%20remove%20an%20entire%20archive%3F

The above mentions that the message would be in three places which are
easily editable.  There is also prev and next links which apparently
live in a database but there are scripts available to fix that too.

Spam used to be in multiple places when we were running ezmlm.  It never
occurred to me that we needed to modify ezmlm to deal with the issue.  I
used to get rid of viruses using a "mlzap" script that hit the right
files.  That technique should work here too.

OTOH, maybe we should just give up on mailman2 and move to something
more modern even if we can't use dnf to install it on RHEL.  I'm surely
not a fan of mailman2.  If we have to do head-standing to get it to work
the way we want then maybe we should just move on and forget that we
said we wanted to use something "stable".

Re: Stability of pipermail ml archive URLs

[Christopher Faylor via Gcc]

On Thu, May 07, 2020 at 06:14:55AM -0400, Frank Ch. Eigler wrote:
>>Such a service is not currently available on sourceware, but it'd be
>>possible to implement: as messages come in, you'd build a database
>>mapping from the Message-ID header to "current Mailman's Pipermail
>>URL".
>
>I was thinking we might be able to trick pipermail (the web archiver
>component) to simply name the message web urls after some function of
>the message-id instead of the sequence number.  Will give this a try
>very shortly.

I just want to go on record as saying that I think this is a bad idea.
We can fix this problem simply without redesigning pipermail.  The
problem that we're seeing is caused by a script that I wrote to migrate
ezmlm to mailman.  The fix for the problem is "Don't run that script".

But, if we are going to make this level of change to pipermail we might
as well go wild and just implement all of the other things that people
want and forget about our supposed desire to use "supported" software.
Changing pipermail to use message-id's rather than sequence numbers
negates the argument that we want to be standard since we likely won't
be able to get this change in upstream.  I doubt that mailman2
developers will want to consider this major a change in a product that
is supposedly close to EOL.

cgf

Re: Stability of pipermail ml archive URLs

[Christopher Faylor]

On Thu, May 07, 2020 at 11:48:18AM +0200, Thomas Schwinge wrote:
>On 2020-05-06T10:44:46-0400, "Frank Ch.  Eigler via Gcc"
> wrote:
>>>Can pipermail provide stable URLs at all?  We really need those, we
>>>reference those in commit messages, other mails, bugzilla etc.
>
>>It would be good to have another way of making permanent URLs for
>>individual messages in mailing list archives.
>
>Look up by Message-ID?
>, for
>example.  See , etc.  The
>idea is that for all practical purposes, Message-IDs are "sufficiently
>unique".  (Compare conceptually to the Git SHA-1 hashes.)

IMO, we're making way too big a deal out of this.  The message archives
are changing because we are resequencing them.  Mailman doesn't, AFAIK,
take it upon itself to randomly renumber them.  fche and cgf have been
renumbering them when we remove spam.

If we stopped doing that there would be no issue.

When we were using ezmlm, I was careful not to remove message files when
dealing with spam.  We haven't been that careful with mailman and, so,
we're seeing problems.

If we just changed the way that we deal with spam to keep the message
around but blank it out, we wouldn't have this problem.

In addition, when I was migrating the mail archives from ezmlm to mailman
I came across a number of cases where the same message-id was used in
two messages.  Possibly it was someone just bouncing email or maybe
it was something else.

Maybe it's a corner case but we wouldn't have to worry about this at all
if we just used mailman's current numbering and didn't ever take it upon
ourselves to rescan the archives.

cgf

Re: Stability of pipermail ml archive URLs

[Christopher Faylor]

On Wed, May 06, 2020 at 09:54:06PM +0700, Arseny Solokha wrote:
>may I also chime in with a related (to some extent), even though a separate
>issue? It seems URL rewriting rules designed to replace old-style
>
>  https://gcc.gnu.org/ml//current
>
>URLs pointing to monthly digests to current ones
>
>  https://gcc.gnu.org/pipermail///date.html#end
>
>broke with onset of May. I mean, if I type
>
>  https://gcc.gnu.org/ml/gcc/current
>
>I still get
>
>  https://gcc.gnu.org/pipermail/gcc/2020-April/date.html#end
>
>(note 2020-April) instead.

This is not related in any way.

I'll fix this.  Apparently my cron job didn't fire.

cgf

Re: Stability of pipermail ml archive URLs

[Christopher Faylor]

On Wed, May 06, 2020 at 04:11:39PM +0200, Jakub Jelinek wrote:
>Hi!
>
>Last week after sending status report mails to gcc mailing list,
>I've opened the web archive and copied the URLs of those status reports
>https://gcc.gnu.org/pipermail/gcc/2020-April/232267.html
>https://gcc.gnu.org/pipermail/gcc/2020-April/232268.html
>and checked them into gcc-wwwdocs git
>c3162d9e711d3e32935c17d1451c63839d702019 revision.
>But today people are complaining that those links don't work anymore
>and those mails have
>https://gcc.gnu.org/pipermail/gcc/2020-April/000504.html
>https://gcc.gnu.org/pipermail/gcc/2020-April/000505.html
>URLs instead.
>Martin Jambor also said he has posted a URL into the archive
>https://gcc.gnu.org/pipermail/gcc/2020-February/231851.html
>which is now instead
>https://gcc.gnu.org/pipermail/gcc/2020-February/232205.html
>Looking around, the last two months of gcc now have very small
>numbers, but e.g. on gcc-patches the mails have very high numbers like
>545238.html.  Can pipermail provide stable URLs at all?  We really
>need those, we reference those in commit messages, other mails, bugzilla
>etc.

I'll bet this is due to rebuilding the archive after removing spam.

Maybe we need to revisit how that's done.

cgf

Re: blacklisted after announce on GNU cauldron ?

[Christopher Faylor via Gcc]

On Thu, Apr 23, 2020 at 06:39:54PM +0100, Jonathan Wakely wrote:
>On Thu, 23 Apr 2020 at 18:02, Jonathan Wakely  wrote:
>>On Thu, 23 Apr 2020 at 16:46, Christopher Faylor wrote:
>>>All of the above is handled by whomever is responsible for the gcc web
>>>pages.  It would be nice if someone fixed those links.
>>
>>Yes, removing the broken subcription form on gcc.gnu.org/lists.html is
>>on my TODO list, but gcc-10 work is higher priority.
>
>Patch submitted for approval now:
>https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544461.html

Thanks!

cgf

Re: blacklisted after announce on GNU cauldron ?

[Christopher Faylor via Gcc]

On Thu, Apr 23, 2020 at 05:13:13PM +0200, Olivier Hainque wrote:
>Hi Frank,
>
>> On 23 Apr 2020, at 16:34, Frank Ch. Eigler  wrote:
>> 
>> Hi -
>> 
 A re-subscription attempt to the gcc mailing list just
 failed, expectedly I guess.
>> 
>> I see no sign in the logs of Olivier being banned in any form.  Please
>> resubscribe online and forward complete failure symptoms if you
>> believe this is still happening.
>
>Thanks for your feedback!
>
>I managed to subscribe again by going through the gcc
>list specific info page :-)
>
>My previous attempts were issued from
>
>  https://gcc.gnu.org/lists.html#subscribe
>
>Subscribing from there doesn't work and leads
>to a page which provides instructions which don't work
>either.
>
>From there I thought the coincidence was troubling.
>
>There is actually a FAQ link on the instructions page,
>which I just checked, and ... it directs to a 404 page:
>
>  https://sourceware.org/pipermail/index.html#faqs
>
>I'll try to re-subscribe to gcc-patches now.

All of the above is handled by whomever is responsible for the
gcc web pages.  It would be nice if someone fixed those links.

Re: Not usable email content encoding

[Christopher Faylor]

It seems like this discussion doesn't have to be cc'ed to overseers.  At
the very least it doesn't need to be cc'ed *twice* as someone who
apparently doesn't understand that gcc.gnu.org == sourceware.org has
cc'ed overseers in both domains.

So, I'd appreciate it if you all would please drop overseers from future
replies in this thread.  The overseers mailing list doesn't need to be
involved in discussions on what gcc does with ChangeLogs.

Please edit your cc list.

Thank you.

Re: Not usable email content encoding

[Christopher Faylor]

On Tue, Apr 14, 2020 at 10:38:12PM +0100, Maciej W. Rozycki wrote:
>Therefore I'd be happy to participate in testing a solution for
>disabling `From' munging for `p=none' domains.

I can't speak for fche but I have a limited amount of time for any
computer activity right now.  A pinched nerve in my neck makes typing
difficult.

However, as a first step, please subscribe to test-l...@sourceware.org.
If we do any tinkering it will be there.  I'll try to play with settings
in the next few days.

I think we can bounce email which seems to be html.  As I'm sure you all know,
we used to do that on server1.  Then we switched to stripping the html
attachment if there was a text component to the email.  At the time, I don't
think I had the slightest notion that there would be ramifications for DMARC.

Is this something that needs to be voted on?  I don't care either way.  I think
fche would probably not mind letting html through.

Do other mailing lists have policies about this?  Is it a given that all of the
technical mailing lists would be ok with sending text-only?  I know it greatly
confuses cygwin users but many of them are not that technical.

cgf

Re: Not usable email content encoding

[Christopher Faylor]

On Mon, Apr 13, 2020 at 10:53:06PM +, Michael Matz wrote:
>On Mon, 13 Apr 2020, Christopher Faylor wrote:
>>On Wed, Apr 08, 2020 at 04:15:27PM -0500, Segher Boessenkool wrote:
>>>On Wed, Apr 08, 2020 at 01:50:51PM +, Michael Matz wrote:
>>>>On Wed, 8 Apr 2020, Mark Wielaard wrote:
>>>>>Earlier versions of Mainman2 had some issues which might accidentally
>>>>>change some headers.  But the latest fixes make this possible.  It is
>>>>>how the FSF handles DMARC for various GNU mailinglists (by NOT
>>>>>modifying the headers and body and passing through the DKIM
>>>>>signatures):
>>>>>https://lists.gnu.org/archive/html/savannah-hackers-public/2019-06/msg00018.html
>>>>
>>>>Oh, that would be nice to have at sourceware.org.  Please?  :-)
>>>
>>>Yes, please please please, can we have this?
>>
>>In case it isn't obvious, we are already running the latest available
>>version of mailman 2.
>
>I think that means that dmarc_moderation_action: "Munge From" can
>simply be switched off then (at least I don't see which other headers
>e.g.  gcc@ is rewriting that would cause DMARC to scream; and if there
>are any, then it would be better to disable those as well.  Same with
>any potential body rewriting that might still happen).

It can't be switched off if we strip html attachments.

>I would offer help testing that this doesn't cause delivery issues, e.g. 
>on some test email list, but it seems none of my domains is DMARC-infected 
>:-/

Nevertheless, offers of help are appreciated (and rare).  :-)

cgf

Re: Not usable email content encoding

[Christopher Faylor]

On Wed, Apr 08, 2020 at 04:15:27PM -0500, Segher Boessenkool wrote:
>On Wed, Apr 08, 2020 at 01:50:51PM +, Michael Matz wrote:
>>On Wed, 8 Apr 2020, Mark Wielaard wrote:
>>>Earlier versions of Mainman2 had some issues which might accidentally
>>>change some headers.  But the latest fixes make this possible.  It is
>>>how the FSF handles DMARC for various GNU mailinglists (by NOT
>>>modifying the headers and body and passing through the DKIM
>>>signatures):
>>>https://lists.gnu.org/archive/html/savannah-hackers-public/2019-06/msg00018.html
>>
>>Oh, that would be nice to have at sourceware.org.  Please?  :-)
>
>Yes, please please please, can we have this?

In case it isn't obvious, we are already running the latest available
version of mailman 2.

Re: Not usable email content encoding

[Christopher Faylor via Gcc]

On Tue, Apr 07, 2020 at 03:56:09PM +, Michael Matz wrote:
>In a way that's amusing and just reinforces my p.o.v. that DMARC is 
>bollocks.

Not that it means anything but I agree 100%.

It's like whoever made the "standard" just said "to hell with mailing
lists".

Re: Not usable email content encoding

[Christopher Faylor via Gcc]

On Tue, Apr 07, 2020 at 03:13:53PM +, Michael Matz wrote:
>Can we please switch it off?  It's not like we really had a problem before 
>the switch to mailman.

You can't really make statements like this which imply that you are
aware of "problems" on sourceware when you're not a sourceware
administrator.

We actually were munging the From on the old server and we were getting
an increasing number of complaints to postmaster that people weren't
receiving mail.

Re: mailman customization

[Christopher Faylor]

On Fri, Apr 03, 2020 at 11:54:20AM -0400, Frank Ch. Eigler wrote:
>> I believe we can quite easily customize mailman 2.1 to match our needs.
>> The biggest challenge I see is a proper testing as I don't see it easy
>> to set up a local mailman instance. I've got a patch that changes:
>
>I suppose we can do some local RPM respins - as long as these changes
>are small and rare.  Even with a deadish upstream, distro reporting
>would be nice, at least at the centos/fedora point (?), as a reference
>place to stash the patch and get us a bug#.

I don't think most of the patch would be acceptable upstream since it
changes default behavior without any way to revert it.

Re: mailman customization

[Christopher Faylor]

On Fri, Apr 03, 2020 at 05:58:51PM +0200, Martin Liška wrote:
>On 4/3/20 5:54 PM, Frank Ch. Eigler wrote:
>>Hi -
>>
>>>I believe we can quite easily customize mailman 2.1 to match our needs.
>>>The biggest challenge I see is a proper testing as I don't see it easy
>>>to set up a local mailman instance. I've got a patch that changes:
>>
>>I suppose we can do some local RPM respins - as long as these changes
>>are small and rare.
>
>That would be great. Should I create a git repo where we'll stack these 
>changes?
>
>> Even with a deadish upstream, distro reporting
>>would be nice, at least at the centos/fedora point (?), as a reference
>>place to stash the patch and get us a bug#.
>
>Can you please do it for me as I don't have any experience with Fedora
>packaging?

If you're volunteering to maintain your patch, perhaps you should try
learning how to do that?

Re: Can we please have the old mailing list back

[Christopher Faylor]

On Wed, Apr 01, 2020 at 10:29:58PM +0200, Bernd Edlinger wrote:
>PS: I have a discovered a very serious problem with the mailing lists
>that must be fixed by our overseers.
>
>As an example please look at this one:
>https://marc.info/?l=gdb-patches&m=158571308379946&w=2
>
>you see this:
>
>-- next part --
>A non-text attachment was scrubbed...
>Name: 0001-Fix-range-end-handling-of-inlined-subroutines.patch
>Type: text/x-patch
>Size: 10992 bytes
>Desc: not available
>URL: 
>
>
>So there are two serious problems here:
>
>1.  there is a single point of failure, if sourceware.org goes down the
>attachment is lost.

sourceware.org has been in operation for 20+ years.  There's lots of
stuff relying on it so it isn't going anywhere.  And, the patch is going
to be in lots of inboxes.  And, if sourceware.org goes down then the
main gdb and gcc source code repositories will also be unavailable.
But, of course, there will be hundreds of copies of that too.

But, then, none of that matters since the "scrubbing" means that the
patch is not offered inline in the *sourceware archives*.  You still see
the patch in your inbox.  So, as Joseph Myers noted, it's a mystery why
marc.info is reporting that.

If you want another source for your patch you can find it here:

http://sourceware-org.1504.n7.nabble.com/PATCH-0-2-Line-table-is-stmt-support-td613080i20.html#a619775

It also has a download link but it's from nabble.com.  So, you can rest
easy knowing that there is more than one place for people to find your
patch if sourceware.org goes down.

>@overseeers: PLEASE STOP IMMEDIATELY THAT SCRUBBING
>
>can you act now, or do you need a CVE number first ?

On Thu, Apr 02, 2020 at 05:35:09AM +0200, Bernd Edlinger wrote:
>Regarding the overseers, they repeatedly spoke up on this list,
>but all the time they use an e-mail that bounces.
>I'd call that impolite.  If you know how to reach them, please
>make them aware of this issue, because it is a security relevant
>issue.  Seriously.

overseers is a mailing list.  You can send email to it @ either the
gcc.gnu.org or sourceware.org domains.  It will be read by the small
number of *volunteers* who keep the site running at no cost to you.

But, all of this is, as I and others have noted, a non-issue for
sourceware.org / gcc.gnu.org.  If you do send email there you will be
told that.  By me.

Re: Can we please have the old mailing list back

[Christopher Faylor]

On Wed, Apr 01, 2020 at 09:57:05PM -0700, Unidef Defshrizzle wrote:
>We can setup a command line interface, maybe using CURSES, I mean GUIs are
>fun, but Jesus Christ they’re full of surprises

Command line interface to what?

You can read email using whatever interface your want.  Archives are
obviously going to be web-formatted.

Re: Can we please have the old mailing list back

[Christopher Faylor]

On Sat, Mar 28, 2020 at 06:46:54PM +, Maciej W. Rozycki wrote:
>I think being software developers we are in this comfortable position
>that we can actually make changes to software ourselves if we find
>problems or usability issues... 
>
>For example I found it useful on a couple of occasions to be able to
>retrieve the original message verbatim from the archive, when the
>message didn't reach my mailbox for one reason or another.  That might
>be via a web page, or better yet a list server command.  If the new
>archiver is missing this feature, then I think the way to move forward
>is to propose a change to add it to the archiver, which would solve the
>actual problem on one hand while keeping the life of our volunteer IT
>people easy enough on the other.

I know you said "if" but you *can* download all of the mbox-formatted
email for a given period using mailman archiver.  It's a standard
feature that has been discussed, I think, in this thread.  It may not be
as convenient as the download raw text hack that was added to the old
archiver but it is usable - especially if you're a software developer.

cgf

Re: Can we please have the old mailing list back

[Christopher Faylor]

On Fri, Mar 27, 2020 at 07:00:59AM +0100, Bernd Edlinger wrote:
>PS: I would CC you, Christopher Faylor, but your email address is
>"cgf-use-the-mailinglist-ple...@gnu.org", so whatever I send there
>would not reach you.

Well duh?  Not being cc'ed is the literal point of the email address.

Anyway, no one ever said that mhonarc was unavailable on CentOS 8.  We
are using the archiver that's built into mailman which required very
little effort to get up and running.  It's in use on scores, if not
hundreds of sites around the web.

What I asked was if there was a public-inbox rpm available.

Anyway, since this is entirely a volunteer effort on my part and every
daytime hour I spend working on it costs me money, I'm going to go with
the answer "I don't have the time/don't want to" as the response to "Why
don't you do X"

If people want to get a collection going and offer to pay for some
improvements/changes to sourceware then I, personally, would consider
spending more time on it.  Or maybe another overseer will jump in and
offer to convert the system to majordomo or something.

Re: Can we please have the old mailing list back

[Christopher Faylor]

On Wed, Mar 25, 2020 at 09:34:16PM +0100, Dmitry Mikushin wrote:
>Maybe the best form of question is: Could the Overseer be so kind to
>release the dump of the original old mailing list on any free public file
>server?

The old archives are still available via their old URLs, e.g.,
https://gcc.gnu.org/ml/gcc/2016-02/ .

Re: Can we please have the old mailing list back

[Christopher Faylor]

On Wed, Mar 25, 2020 at 09:29:03PM +0100, Bernd Edlinger wrote:
>-On 3/25/20 7:55 PM, Christopher Faylor wrote:
>> On Wed, Mar 25, 2020 at 04:23:02PM +0700, Arseny Solokha wrote:
>>> I believe the canonical place for the "Linux suff" mailing lists these days 
>>> is
>>> lore.kernel.org, powered by public-inbox[1]. ISTM that software can address 
>>> most
>>> if not all needs of those involved in GCC development and even has NNTP 
>>> support,
>>> though I've no idea whether it could be an acceptable solution from the
>>> overseers' perspective.
>>>
>>> [1] https://public-inbox.org/public-inbox.git
>> 
>> The overseers are trying hard to use only software that can be installed
>> via the RHEL packaging system so as not to duplicate the mistake that
>> kept us dependent on poorly supported mail software.  Is there a
>> public-inbox rpm package for RHEL or CentOS?
>> 
>> FWIW, this particular overseer is is also pretty exhausted from the
>> effort of moving sourceware to a new system + new software and would not
>> relish the effort involved in getting all of this moved to new software.
>> 
>
>Honestly this is not about blaming you at all.
>
>I do not quite understand what is the exact software which
>was used previously?
>
>what is the exact problem that prevents it from being used any longer?
>
>Which software is being used now?
>
>Why is gcc-patc...@gcc.gnu.org, gcc@gcc.gnu.org.  and fort...@gcc.gnu.org
>even this e-mail thread visible
>on marc.info: https://marc.info/?l=gcc&m=158512515107459&w=2
>but not gdb-patches ?
>
>Could you add a link to https://marc.info/?l=gcc-patches
>https://marc.info/?l=gcc
>https://marc.info/?l=gcc-fortran
>note the unsystematic name gcc-fortran, the list is fort...@gcc.gnu.org
>
>There is no gcc-help on marc.info
>There is https://marc.info/?l=gcc
>but there is no gdb-patches
>
>what needs to be done to host those lists on marc.info as well?
>
>What needs to be done to host these lists on spinics for instance,
>or what else exists that can be used to search the messages?

marc.info is an independent site that is not associated with
sourceware.org.  We don't control it.  If you have questions about their
site then ask them.

The mailing list software is all easily discernible by investigating
email headers and via google but someone else answered your questions
later in this thread.

Re: Can we please have the old mailing list back

[Christopher Faylor]

On Wed, Mar 25, 2020 at 04:23:02PM +0700, Arseny Solokha wrote:
>I believe the canonical place for the "Linux suff" mailing lists these days is
>lore.kernel.org, powered by public-inbox[1]. ISTM that software can address 
>most
>if not all needs of those involved in GCC development and even has NNTP 
>support,
>though I've no idea whether it could be an acceptable solution from the
>overseers' perspective.
>
>[1] https://public-inbox.org/public-inbox.git

The overseers are trying hard to use only software that can be installed
via the RHEL packaging system so as not to duplicate the mistake that
kept us dependent on poorly supported mail software.  Is there a
public-inbox rpm package for RHEL or CentOS?

FWIW, this particular overseer is is also pretty exhausted from the
effort of moving sourceware to a new system + new software and would not
relish the effort involved in getting all of this moved to new software.

cgf

Re: Not usable email content encoding

[Christopher Faylor]

On Wed, Mar 18, 2020 at 11:30:22PM -0400, Christopher Faylor wrote:
>On Wed, Mar 18, 2020 at 06:44:15PM -0400, Frank Ch. Eigler wrote:
>>> N.B. the CC list has got too big and is causing posts to this thread
>>> to be held for moderator approval.
>>
>>Ah, can cycle through the lists and raise that limit.
>>The default 10 is too low.
>
>Didn't you have to lower that limit for outpost, fche?
>
>I believe it used to be 10 for server1 too, though, fwiw.

Another annoying thing about mailman is this double inclusion of the
same address in the Cc.

cgf

Re: Not usable email content encoding

[Christopher Faylor]

On Wed, Mar 18, 2020 at 06:44:15PM -0400, Frank Ch. Eigler wrote:
>> N.B. the CC list has got too big and is causing posts to this thread
>> to be held for moderator approval.
>
>Ah, can cycle through the lists and raise that limit.
>The default 10 is too low.

Didn't you have to lower that limit for outpost, fche?

I believe it used to be 10 for server1 too, though, fwiw.

cgf

Re: gcc mailing list is not being archived

[Christopher Faylor]

On Mon, Mar 09, 2020 at 10:10:31AM -0400, Frank Ch. Eigler via Overseers wrote:
>Hi -
>
>> one more point: The gcc mailing list including this discussion is
>> currently not being archived, the last message is from 2020-03-06.
>
>Found & fixed a permission problem with the mailmnan archives.
>Let's see if this one makes it in now.

I'll repopulate the archive with the missing messages when I have the
chance.

cgf

Re: GCC wwwdocs move to git done

[Christopher Faylor]

On Wed, Oct 09, 2019 at 09:37:54AM -0400, Christopher Faylor wrote:
>The binary is 20 years old and, somehow, the source code used to build
>it seems to have disappeared.

Sorry. Not 20 years:

-rwxr-xr-x. 1 root root 574221 Mar 22  2013 /usr/local/bin/mhc

cgf

Re: GCC wwwdocs move to git done

[Christopher Faylor]

On Wed, Oct 09, 2019 at 01:25:30PM +0100, Iain Sandoe wrote:
>Jonathan Wakely  wrote:
>
>>On Wed, 9 Oct 2019 at 01:28, Joseph Myers wrote:
>>>I've done the move of GCC wwwdocs to git (using the previously posted and
>>>discussed scripts), including setting up the post-receive hook to do the
>>>same things previously covered by the old CVS hooks, and minimal updates
>>>to the web pages dealing with the CVS setup for wwwdocs.
>>
>>Thanks, Joseph.
>
>+1
>
>I would like to be able to preview changes to the website by using it
>from a local
>webserver.  I realise that individual pages can be viewed in a
>browser / validated
>by uploading - but it would be nice to check connectivity etc.
>
>At the moment, I can’t identify the “mhc” program that is used in
>preparing the text
>(and too many unrelated hits from searches).

I think it's the "metahtml" processor:

https://ftp.gnu.org/gnu/metahtml/

The binary is 20 years old and, somehow, the source code used to build
it seems to have disappeared.

Re: Please block seu...@linux.vnet.ibm.com from gcc-regression

[Christopher Faylor]

On Tue, Apr 19, 2016 at 04:30:45PM +, Joseph Myers wrote:
>On Tue, 19 Apr 2016, Bill Schmidt wrote:
>
>> We're sorry for the problems.  Bill was updating our scripts to enable the
>> gcc-6-branch for testing, and unfortunately things went massively wrong.
>> This has been shut down, and we're taking several precautions to ensure
>> nothing like this happens again.  There should be no further bad messages
>> after the ones on Sunday, so once those are cleared up it should be safe to
>> re-enable the sending email address.
>
>Overseers, the messages are still coming through (e.g. 
>), so we 
>still need the block until the mail queue in question has emptied.

This email address has been blocked.

cgf

Re: Account creation disabled on GCC Bugzilla

[Christopher Faylor]

On Wed, Oct 22, 2014 at 11:56:19AM -0400, Jason Merrill wrote:
>What should I tell a user who wants to create an account?

That they should follow the instructions and contact overseers.

Re: Remove spam in GCC mailing list

[Christopher Faylor]

On Sat, Dec 28, 2013 at 08:40:07PM +0900, Tae Wong wrote:
>You want to send a mail to python-dev at python dot org.
>
>The spam still exists in gcc-bugs mailing list:
>http://gcc.gnu.org/ml/gcc-bugs/2013-08/msg00689.html
>http://gcc.gnu.org/ml/gcc-bugs/2013-08/msg00759.html
>http://gcc.gnu.org/ml/gcc-bugs/2013-08/msg00776.html
>http://gcc.gnu.org/ml/gcc-bugs/2013-08/msg01181.html
>http://gcc.gnu.org/ml/gcc-bugs/2013-08/msg01586.html
>http://gcc.gnu.org/ml/gcc-bugs/2013-09/msg01513.html
>http://gcc.gnu.org/ml/gcc-bugs/2013-09/msg01946.html
>http://gcc.gnu.org/ml/gcc-bugs/2013-09/msg01947.html
>http://gcc.gnu.org/ml/gcc-bugs/2013-09/msg02011.html
>
>There's no reason that the gcc-bugs mailing list can post bug reports directly.
>
>Please delete spam messages from gcc-bugs.

These messages are, AFAIK, pointless.  I'm not aware of anyone working
as a spam removal service.  I am one of the admins for gcc.gnu.org and I
sure as @#$* am not paid enough to do this.  I do spend a lot of my time
trying to make sure that spam doesn't get through and that's the limit
of what I'm willing to do.

I'd think that a lot of this thread (especially the launchpad part)
is off-topic for this mailing list.

cgf

Re: RFC: Add zlib source to src CVS resposity

[Christopher Faylor]

On Tue, Nov 02, 2010 at 10:25:50AM +1030, Alan Modra wrote:
>On Mon, Nov 01, 2010 at 05:13:44PM +, Nick Clifton wrote:
>>   * We have to make sure that zlib will build on all of the
>> hosts that we care about.  Should the situation arise
>> where the zlib does not build on a particular host, and
>> the zlib maintainers are not interested in making it
>> build there, then it will be down to us to fix it.  Or
>> else abandon compression support on that host.
>
>This would mean we need to keep machinery to conditionally compile
>in compressed debug support, removal of said support being HJ's stated
>reason for importing zlib.
>
>I'm against importing zlib into binutils, and I think we should keep
>support of compressed debug sections conditional, to avoid potential
>bootstrap problems or circular dependencies.

FWIW, I agree.  I think that having to keep zlib up-to-date wrt
potential security issues or other serious bugs is a burden that we
shouldn't take on.  Shouldn't we be trying to use any system shared
libraries for these types of things specifically so that the vendor
can handle problems for us?

cgf

Re: How to update my SSH authorized_keys on gcc.gnu.org?

[Christopher Faylor]

On Tue, Feb 23, 2010 at 09:27:35AM -0800, H.J. Lu wrote:
>On Tue, Feb 23, 2010 at 9:22 AM, Andreas Schwab  wrote:
>> "H.J. Lu"  writes:
>>
>>> Is there a way to update my SSH authorized_keys on gcc.gnu.org?
>>
>> See .
>>
>
>It doesn't work for me:
>
># ssh sourceware.org replacekey  < authorized_keys
>Permission denied(publickey,gssapi-with-mic).

That would imply that you are not using the right ssh key to access
sourceware.  You (of course?) need to be able to access the system to
execute the replacekey command.

cgf

[[webmaster] New contact address for ftp.fu-berlin.de]

[Christopher Faylor]

- Forwarded message from Holger Weiss  
-

Hello,

ftp.fu-berlin.de is listed as a mirror of the gcc.gnu.org FTP site on
 with Felix von Leitner's e-mail
address.  As Felix is no longer a contact for our site, could you please
replace his address with ?

Thank you, Holger


- End forwarded message -

Re: Please block henry2000 from the wiki

[Christopher Faylor]

On Thu, Feb 26, 2009 at 04:08:03PM -0500, Daniel Berlin wrote:
>If you want to help admin the wiki, I am more than happy to make you a
>super user.
>That goes for Steven, etc.

Wait.  Are we talking about giving people root access on sourceware
just to clean up a wiki?  Hopefully this is not the case.

cgf

Re: REMOVE ME PLEASE

[Christopher Faylor]

On Fri, Dec 26, 2008 at 04:26:29PM -0500, duane agate wrote:
> COULD YOU PLEASE REMOVE ME FROM THIS EMAIL LIST? SOMEONE LISTED ME AS A 
> JOKE! NOT SURE WHAT A GCC EVEN IS.. MY EMAIL ADDRESS IS; 
> corvet...@comcast.net. THANKS.

There is no one with your email address subscribed to gcc.gnu.org.

Look at the header of one of the messages you are receiving.  It will
contain a List-Unsubscribe field.  Send email to that email address and
you will be able to unsubscribe.

If you have problems with this see:
http://gcc.gnu.org/lists.html

and

http://sourceware.org/lists.html#unsubscribe-full

Re: Please, do not use the merged revisions log as the commit message when merging

[Christopher Faylor]

On Fri, Sep 05, 2008 at 01:34:08PM -0500, John Freeman wrote:
> Christopher Faylor wrote:
>> On Sun, Aug 17, 2008 at 03:01:03PM -0500, John Freeman wrote:
>>   
>>> Daniel Berlin wrote:
>>>
>>> 
>>>> It's listed on the wiki that explains how to maintain branches :)
>>>> 
>>> I had no idea such a wiki even existed.  It would really help future 
>>> contributors, I'm sure, if, perhaps during copyright assignment, there 
>>> were some sort of "introduction" process that clearly communicated 
>>> policies.  Thank you for the heads up.
>>> 
>>
>> But, you did do it again, just a little while ago.
>>   
>No, I didn't.  I have made one commit in the past week, with a
>one-liner log message.  This morning I used Mr.  Lopez-Ibanez's advice
>in his earlier post, number 148771,

I don't know what post number 148771 is (it's 2008, we can use URLs
these days) but

>entitled "broken svn commit logs and how to fix them" and changed the
>log message for revision 139145.  I haven't done a merge since the last
>time this issue came up.

I'm not making this up:

Subject: Bug 31754
Date: Fri, 05 Sep 2008 14:39:56 -
To: gcc-bugzilla
From: jfreeman

Author: jfreeman
Revision: 139145
Modified property: svn:log

Modified: svn:log at Fri Sep  5 14:39:56 2008
---=
---
--- svn:log (original)
+++ svn:log Fri Sep  5 14:39:56 2008
@@ -1,19740 +1,1 @@
-Merged revisions 136194,136196,136200,136209,136215-136217,136221-136222,1=
36229,136235-136239,136242,136247,136249,136251-136254,136266,136273,136276=
-136277,136280,136282-136283,136291-136297,136301-136304,136308,136311,1363=
14-136315,136319-136323,136329,136331,136344,136348,136351,136355,136359-13=
6360,136362,136372,136374,136376-136378,136383,136386,136389,136395,136406,=
136416,136421,136423,136425,136427-136428,136431,136433-136435,136437-13643=
8,136485-136486,136491,136494,136497-136498,136503,136506,136513,136517-136=
518,136532,136534,136536-136537,136539-136542,136544-136547,136551,136554-1=
36555,136561-136563,136566-136569,136574,136576,136578,136580,136583,136585=
,136590,136596,136600-136602,136604-136605,136609,136615,136617,136619,1366=
32,136636,136639,136641,136645,136647-136651,136653-136655,136657-136658,13=
etc.

This exhibited the same bounce behavior that we saw last time.

Re: Please, do not use the merged revisions log as the commit message when merging

[Christopher Faylor]

On Sun, Aug 17, 2008 at 03:01:03PM -0500, John Freeman wrote:
> Daniel Berlin wrote:
>
>> It's listed on the wiki that explains how to maintain branches :)
>>   
> I had no idea such a wiki even existed.  It would really help future 
> contributors, I'm sure, if, perhaps during copyright assignment, there were 
> some sort of "introduction" process that clearly communicated policies.  
> Thank you for the heads up.

But, you did do it again, just a little while ago.

Please stop doing that!  You're swamping gcc.gnu.org and causing unnecessary
work for me.

I will be instituting some safeguards against this kind of mail-bombing going
forward but, nevertheless, this really should not be a common occurrence.

cgf

Re: Official GCC git repository

[Christopher Faylor]

On Sun, Aug 17, 2008 at 06:30:57PM +0200, Gerald Pfeifer wrote:
>On Thu, 27 Mar 2008, Andreas Schwab wrote:
>>> I've been waiting until I had the time to rewrite my import with proper
>>> author names.  Does anyone have a correspondence file mapping the login
>>> name to Author?
>> I have a list that is about 4 months old.  Should be pretty complete.
>
>Cute.  How about adding this to the GCC repository in some file parallel
>to our MAINTAINERS file?  Something like MAINTAINERS.logins or so?
>
>On Thu, 27 Mar 2008, Samuel Tardieu wrote:
>> I also think adding the Real Name is nice.
>> 
>> Maybe we should also consider adding the login as an additional field
>> in the MAINTAINERS file, as AFAIK every MAINTAINERS as a @gcc.gnu.org
>> address.
>
>That would be an alternative.  It would increase the width of MATINAINERS
>above 80 characters, and I'm not sure how much of an issue that would be.

I don't think adding YA place that has to be updated when things change
is a good idea.  If this is a script that runs on gcc.gnu.org then you
should be able to get the full name with a minimal amount of effort
using a getpw* function.

cgf

Re: Please, do not use the merged revisions log as the commit message when merging

[Christopher Faylor]

On Sat, Aug 16, 2008 at 02:35:08PM +0200, Manuel L?pez-Ib??ez wrote:
>Dear GCC devs,
>
>Please do *not* use the full logs of the merged revisions as the
>commit message of a merge. Apart from making the output of svn log
>useless, commits messages are parsed are tracked for PR numbers, the
>commit message is added to the bugzilla page of the PR and people
>subscribed to the relevant PR in bugzilla are notified of the commit.
>Therefore a single merge of many revisions would result in a flood of
>mails sent for no good reason and they make a mess of the bugzilla
>page.
>
>I am sure many of you have been hit by this recently. Please, let's
>try to avoid this.

If that isn't a good enough reason, doing this completely swamps
gcc.gnu.org as it valiantly attempts to send all of the above email.
This resulted in a load average of 24 on the system last night and kept
me awake until 2:30AM trying to stabilize things.

cgf

Re: gcc will become the best optimizing x86 compiler

[Christopher Faylor]

On Tue, Jul 29, 2008 at 04:14:49PM +1000, Ben Elliston wrote:
>> Since there is no libc mailing list, I thought that the gcc list is the 
>> place to contact the maintainers of libc. Am I on the wrong list? Or are 
>> there no maintainers of libc?
>
>See:
>  http://sources.redhat.com/glibc/
>
>You want the libc-alpha list, I think.

I think libc-help is a more likely place to start.

cgf

Re: GCC 4.2.4 Released

[Christopher Faylor]

[Reply-to set]
Please remove gcc-announce from your responses to this thread.

I'm getting tired of rejecting all of the non-announce email.

cgf

On Fri, May 23, 2008 at 10:21:52AM -0700, Joe Buck wrote:
>On Fri, May 23, 2008 at 09:03:26AM -0400, Paul M. Dubuc wrote:
>> I have been trying to find a list of bugs that have been fixed in this 
>> release without any success.  How do I find this information about a 
>> given release?
>
>Others have suggested reading ChangeLog files, but there's a better way.
>
>Visit http://gcc.gnu.org/bugzilla/query.cgi (the search form for GCC's
>bug database).
>
>For Target:, select 4.2.4.
>For Status:, select RESOLVED.
>For Resolution:, select FIXED.
>
>Click Search.
>
>You'll get a list of 24 bugs.
>
>If you just want to see the most serious bugs, also select Priority: P1.
>You then get 5 bugs: 33819, 33916, 34825, 34950, and 35265.
>

Re: Official GCC git repository

[Christopher Faylor]

On Wed, Apr 23, 2008 at 05:14:42PM -0400, Christopher Faylor wrote:
>On Wed, Apr 23, 2008 at 08:09:57PM +0200, Samuel Tardieu wrote:
>>>>>>> "Christopher" == Christopher Faylor <[EMAIL PROTECTED]> writes:
>>
>>Christopher> After consultation with Dan, I have set things up on
>>Christopher> gcc.gnu.org so that the git repository is updated every
>>Christopher> time an email message is received from the gcc-cvs
>>Christopher> mailing list.
>>
>>Christopher> We'll be monitoring the system to see if there is a load
>>Christopher> hit.  If so, we'll probably drop back to Dan's original
>>Christopher> method.
>>
>>It looks like the GIT repository hasn't been synced since yesterday.
>>
>
>Yes:
>
>Apr 23 20:41:28 sourceware error: invalid object 
>6c380017b3c68b8efc917ae3447e62b0fd76b009
>Apr 23 20:41:28 sourceware fatal: git-write-tree: error building trees; the 
>index is unmerged?
>Apr 23 20:41:28 sourceware write-tree: command returned error: 128
>
>What fun!

In case it isn't obvious, I don't know how to fix this.

cgf

Re: Official GCC git repository

[Christopher Faylor]

On Wed, Apr 23, 2008 at 08:09:57PM +0200, Samuel Tardieu wrote:
>>>>>> "Christopher" == Christopher Faylor <[EMAIL PROTECTED]> writes:
>
>Christopher> After consultation with Dan, I have set things up on
>Christopher> gcc.gnu.org so that the git repository is updated every
>Christopher> time an email message is received from the gcc-cvs
>Christopher> mailing list.
>
>Christopher> We'll be monitoring the system to see if there is a load
>Christopher> hit.  If so, we'll probably drop back to Dan's original
>Christopher> method.
>
>It looks like the GIT repository hasn't been synced since yesterday.
>

Yes:

Apr 23 20:41:28 sourceware error: invalid object 
6c380017b3c68b8efc917ae3447e62b0fd76b009
Apr 23 20:41:28 sourceware fatal: git-write-tree: error building trees; the 
index is unmerged?
Apr 23 20:41:28 sourceware write-tree: command returned error: 128

What fun!

cgf

Re: Official GCC git repository

[Christopher Faylor]

After consultation with Dan, I have set things up on gcc.gnu.org so that
the git repository is updated every time an email message is received
from the gcc-cvs mailing list.

We'll be monitoring the system to see if there is a load hit.  If so,
we'll probably drop back to Dan's original method.

cgf

[ADMINISTRIVIA] lost email

[Christopher Faylor]

I wanted to let everyone know that sourceware.org/gcc.gnu.org/cygwin.com
experienced an email outage for a while starting at 2006/10/15 04:43 GMT
to about 2006/10/15 18:46 GMT.  During that time some email was lost.

This was due to a typo that I added to one of the email filters to
attempt to ward off some pending stock spam.

Not all email was lost but, if you sent email to a mailing list and
it has not yet appeared, then you are probably affected and will have
to resend your mail.

I apologize for this inconvenience.

If you feel that you must reply to this message, please note that the
distribution list is large and that the reply-to has been sent to the
overseers mailing list since it is unlikely that any response to this
message would be appropriate for all of the mailing lists mentioned
in the To field.

cgf

Re: Google group for generic System V Application Binary Interface

[Christopher Faylor]

On Thu, Sep 28, 2006 at 08:09:15PM +0100, Dave Korn wrote:
>Haven't had to suffer through an htDig session in a looong time now.

We haven't used htDig on sourceware for a few months now.

It's mnogosearch these days.

cgf

Re: Notes of the libgcc-math BOF at the summit.

[Christopher Faylor]

On Fri, Jun 30, 2006 at 02:57:19PM +0200, Richard Guenther wrote:
>Issues of providing both standard conforming and target optimized
>math runtimes for GCC were discussed.

Thanks for posting this.  Since I wasn't able to attend the summit this
year, I really appreciate seeing summaries like this.

cgf

ADMINISTRIVIA about Re: "Free as in Freedom"

[Christopher Faylor]

I thought I should point out that this thread has hit the "too many recipients"
spam blocking rule at gcc.gnu.org so there are a number of messages from various
people (but mostly from Alexander) which are not making it to the mailing list.

cgf

Re: "Free as in Freedom"

[Christopher Faylor]

On Sun, Jun 25, 2006 at 05:02:41PM -0700, Alexander Verhaeghe wrote:
>Quote Jan-Benedict Glaw "So please shut up now."
>
>Quite friendly I must say, it's the german way I suppose of handling
>things?
>
>To Jan-Benedict Glaw I WON'T SHUT UP because of "Free as in Freedom"!

However, you have been told quite clearly what the site policy is.  None
of the mailing lists at gcc.gnu.org are intended to be rant lists so you
really do have to stop sending this type of email since it is off-topic
for every list that you are using.

If you can't stop yourself, then steps will be taken to block you from
sending email here.

Re: mingw32 subtle build failure

[Christopher Faylor]

On Thu, Jun 01, 2006 at 11:58:31AM +0530, Ranjit Mathew wrote:
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA1
>
>Christopher Faylor wrote:
>> On Wed, May 31, 2006 at 11:37:51PM +0200, FX Coudert wrote:
>>> And I forgot to ask: who the heck is supposed to set USE_MINGW_MSYS?  
>>> (grep is soo sloow on my win32 machine)
>> 
>> For the record, I don't do Msys.  Please don't cc me about msys problems.
>
>I think he CC-ed you on the message because you seem to be
>the one who added the conditional code using USE_MINGW_MSYS
>to libiberty/pex-win32.c:
>
>  http://gcc.gnu.org/ml/gcc-cvs/2005-09/msg00557.html

Fair enough.  The USE_MINGW_MSYS conditional is for people who want to
make an Msys aware version of the pex* functions.  I included it because
when I volunteered to work on these function, I thought that it was a
requirement, so I reluctantly added features to deal with Msys.  Then I
was told that it wasn't necessary.  So, rather than nuke my changes, I
added a conditional.  It's likely to have bit-rotted by now.

Again, I request that you all not cc me on this thread any further.

cgf

Re: mingw32 subtle build failure

[Christopher Faylor]

On Wed, May 31, 2006 at 11:37:51PM +0200, FX Coudert wrote:
>And I forgot to ask: who the heck is supposed to set USE_MINGW_MSYS?  
>(grep is soo sloow on my win32 machine)

For the record, I don't do Msys.  Please don't cc me about msys problems.

cgf

Re: Problem with pex-win32.c

[Christopher Faylor]

On Tue, Mar 14, 2006 at 04:56:21PM -0800, Mark Mitchell wrote:
>Mark Mitchell wrote:
>>As a test case, I'd recommend the latest code I posted.  If a MinGW
>>application tries to open CONOUT$ with CreateFile, it gets
>>INVALID_HANDLE_VALUE, so the OS doesn't seem to think the console is
>>available.
>
>I should have said "in a Cygwin xterm" somewhere in that sentence; it
>can of course open CONOUT$ from a console window.

And, if it can't open CONOUT$ in cygwin's xterm, that's a bug...

cgf

Re: Problem with pex-win32.c

[Christopher Faylor]

On Tue, Mar 14, 2006 at 07:59:22PM +, Paul Brook wrote:
>On Tuesday 14 March 2006 19:46, Ross Ridge wrote:
>> Dave Korn writes:
>> >I don't understand why you think Mark's code needs to search the PATH or
>> >append '.exe', when it invokes CreateProcess that does all that for you?
>>
>> I've already answered that question: "subtle differences in the other
>> behaviours could cause problems."  The search behaviour and extension
>> handling of CreateProcess() is actually quite a bit different than
>> of MSVCRT's spawn functions.  Also, because of the way he uses
>> CreateProcess(), Mark's code as it is now won't search the PATH.
>>
>> >> Is this really worth it?  Could this whole problem be solved by you
>> >> switching to rxvt?  Maybe the only problem is that your xterm is broken.
>> >
>> >  Nothing is "broken".  The problem is that Cygwin applications run in
>> >a slightly special environment, where there may not be a console attached
>> >to the shell window.
>>
>> Arguably, not having a console window attached a shell window is broken
>> in the Cygwin environment.
>
>How exactly do you suggest implementing this? I'm fairly sure the cygwin 
>people have concluded this is impossible.

No, we haven't.  We have, in fact, gone to great lengths to try to ensure
that a console is always attached to a tty/pty.

>>>This is not a problem for cygwin apps, but it can be for
>>>non-cygwin-aware apps launched from inside cygwin's 'special'
>>>environment that may assume that the standard win32 assumptions hold.
>>
>>So, in general you can't expect any Win32 console application to work
>>correctly in such a enviroment.  Why should Mark expect a Win32 console
>>version gcc to be any different?  Hmm...  maybe that's best solution,
>>Mark should be using a "native" Cygwin version of gcc and tools.
>
>By implication you're saying that you shouldn't able to use gcc from
>any GUI environment.  Cygwin isn't any different to any other process
>(eg.  Eclipse) that want to run and capture the output of "commandline"
>applications.

It is entirely possible that programs which look at their stdin/stdout
will be confused when running under a cygwin pty but they should not,
in theory, be confused if they try to detect if they have a console
attached because there *should* be an invisible console attached to
any process running in a pty.

cgf

Re: Problem with pex-win32.c

[Christopher Faylor]

On Sun, Mar 12, 2006 at 09:43:12PM -0800, Mark Mitchell wrote:
>Mark Mitchell wrote:
>
>> What cygcheck output would be helpful?  I've never run cygcheck until
>> just now, and it seems to have lots of options.
>
>By the way, I don't see any reason to suspect that there's a Cygwin bug.
> The situation is:
>
>1. A Cygwin xterm does not have an associated console.

ptys are supposed to have invisible consoles associated with them.  Since
xterm uses an invisible console I still don't see why there should be
a console popup.

This still sounds like a cygwin problem to me.

cgf

Re: Problem with pex-win32.c

[Christopher Faylor]

On Sun, Mar 12, 2006 at 09:16:47PM -0800, Mark Mitchell wrote:
>Christopher Faylor wrote:
>
>> I don't see any reason why cygwin should be causing a console window to
>> flash when spawn is used.
>> 
>> Maybe this is something that should be pursued in the Cygwin list.  The
>> test cases will be useful but please also provide cygcheck output - as
>> an attachment, please.
>
>What cygcheck output would be helpful?  I've never run cygcheck until
>just now, and it seems to have lots of options.

The options as suggested at http://cygwin.com/problems.html .

cgf

Re: Problem with pex-win32.c

[Christopher Faylor]

On Sun, Mar 12, 2006 at 03:27:02PM -0500, Ross Ridge wrote:
>Mark Mitchell wrote:
>>Cygwin Xterm
>>
>>parent spawn: Pops up DOS window.
>>parent nostd: No output from child.
>>parent std:   Works.
>>
>>DOS Console
>>===
>>parent spawn: Works.
>>parent nostd: No output from child.
>>parent std:   No output from child.
>
>This is what I got using your code and Cygwin rxvt:
>
>Cygwin rxvt
>===
>parent spawn: Works.
>parent nostd: No output from child.
>parent std:   Works.
>
>I wasn't able to test it with xterm, I don't have an X server handy,
>but it looks your problem is with xterm, not gcc.

I don't see any reason why cygwin should be causing a console window to
flash when spawn is used.

Maybe this is something that should be pursued in the Cygwin list.  The
test cases will be useful but please also provide cygcheck output - as
an attachment, please.

cgf

Re: Request to become moderator of crossgcc mailing list

[Christopher Faylor]

[Note that reply-to is set to sourcemaster to prevent any further pollination
in the gcc mailing list]
On Sun, Feb 26, 2006 at 09:14:12AM -0800, Dan Kegel wrote:
>The crossgcc mailing list really needs some moderator lovin'.  e.g.  an
>address on the crossgcc mailing list is bouncing, and needs removal.

It would help if you mentioned what the address is.  FWIW, ezmlm is
supposed to detect bouncing email and remove addresses automatically.
However, if the mail is bouncing directly back to senders then the only
way we know to remove it is if someone sends the headers on to
postmaster.

>Worse, the blurb at the bottom of each post has needed updating for the
>last four years or so.

I've removed the (indirect) reference to Bill Gatliff's site.

>I seem to be one of the main players on that list these days, and I'm
>willing.  Any chance I could become a moderator of the crossgcc list?

I'd have to check with the other administrators of this site but, in the
meantime, please forward the bouncing email to postmaster so that we can
unsubscribe the person with the email problems.

Btw, I do follow the crossgcc list and correct any obvious problems.  I missed
the fact that the trailer referred to an obsolete web site, however.

cgf

Re: GCC mailing list archive search omits results after May 2005

[Christopher Faylor]

On Tue, Dec 13, 2005 at 11:03:12PM -0500, Hans-Peter Nilsson wrote:
>On Tue, 13 Dec 2005, DJ Delorie wrote:
>>>Summary of the thread: it's known about and may never be fixed, but
>>>alternative searchable archives exist (gmane, nabble, probably others
>>>like marc and mail-archive too).
>>
>>Could we put in a google search box on the archive pages at least, to
>>stop confusing people?
>
>Technically feasible but politically sensitive.  Considering that links
>on readings.html to sites that provide some software that's
>non-free-by-FSF-definition is forbidden, I'd like to know if that'd be
>allowed, and I'd want that answer straight from the GNU's mouth (so
>please don't start discussing it among just-subscribers-to-this-list
>and anyway don't CC me if you do).  SC?

I asked about this a couple of years ago and, IIRC, the SC said no.

cgf

Re: New SVN Wiki page

[Christopher Faylor]

On Fri, Oct 28, 2005 at 06:01:52PM +0200, Gerald Pfeifer wrote:
>On Fri, 28 Oct 2005, Christopher Faylor wrote:
>> I just updated the cvs/svn shell on gcc.gnu.org.  It now has the ability
>> to add a v2 key to the system:
>> 
>>   ssh gcc.gnu.org 'updatekey' < ~/.ssh/id_rsa.pub
>> 
>> This will add the id_rsa.pub to the authorized_keys file on gcc.gnu.org.
>> It will, of course, only work if you are already able to access the
>> system.
>
>That's really, really cool.  Thanks!

You're welcome!

Since we have better control of the connection to gcc.gnu.org now, are
there any other things like this which would be useful to add, like
maybe a

  ssh gcc.gnu.org "mirror-repo"

or something?

cgf

Re: New SVN Wiki page

[Christopher Faylor]

On Fri, Oct 28, 2005 at 01:30:13AM +0200, Giovanni Bajo wrote:
>Mike Stump <[EMAIL PROTECTED]> wrote:
>
>>> Uhm, I'm not sure how to explain this without being too pedantic.
>>> Does this
>>> sound clearer?
>>
>> This tool tracks each individual change (fine-grained) and will never
>> reapply an already applied change.
>>
>> I think that is a high level answer, and completely answers the
>> question to people that have the question, while doing as little as
>> possible to confuse someone that doesn't even have the question.
>> Anyone doing merges should have the question and understand the
>> answer.
>>
>> Or, you can say it merges in N-1 to N, when one requests a merge of
>> N.  A totally different way of expressing the same thing, and conveys
>> the same information.
>>
>> Sound reasonable?
>
>Thanks for the suggestion, I have incorporated this into the Wiki page, I hope
>it's clearer now.

I just updated the cvs/svn shell on gcc.gnu.org.  It now has the ability
to add a v2 key to the system:

  ssh gcc.gnu.org 'updatekey' < ~/.ssh/id_rsa.pub

This will add the id_rsa.pub to the authorized_keys file on gcc.gnu.org.
It will, of course, only work if you are already able to access the
system.

Should the wiki be updated to reflect this change?

As a meta-issue, maybe we should actively promote that people update
their keys and eventually turn off the v1 keys entirely?

cgf

Re: CVS access to the uberbaum tree

[Christopher Faylor]

On Mon, Oct 17, 2005 at 10:56:01AM -0700, Jim Wilson wrote:
>Peter Barada wrote:
>>Does the uberbaum tree exist on savanna, or is it only on
>>sources.redhat.com?  If so, what is the procedure for accessing it?
>
>I would not recommend use of uberbaum.  There are some old-time 
>ex-Cygnus hackers that use it, because it gives an environment familiar 
>to the one we used inside Cygnus.  For everyone else, it probably causes 
>more problems than it solves.
>
>uberbaum exists only on sourceware.org.  It is a symlink tree that tries 
>to make two CVS repositories look like one.  Because it is a fake tree, 
>you can not use it for checking in patches.  You can only use it for 
>checkouts.  Because few people use it, when it breaks, it may be a while 
>before it is fixed.  Personally, I find it easier to just check out the 
>different trees and then create a local symlink tree.

Actually, I use uberbaum to check in changes to gcc, gdb, and cygwin.

If there was breakage then it would be fixed like any other problem in
the repository - send email to overseers.

Using it is pretty straightforward - /cvs/uberbaum is the root.

However, since gcc is moving to subversion, it doesn't make any sense to
get used to using it right now.

cgf

Re: Update on GCC moving to svn

[Christopher Faylor]

On Sat, Oct 08, 2005 at 08:47:19PM -0400, Daniel Berlin wrote:
>Angela, you said you had a good solution to the restricted shell problem
>(IE the need to allow both cvs server and svnserve to run).

?  I wrote a script which seems to work for providing a restricted shell.
Does Angela have something similar?

cgf

Re: Cross GCC on Cygwin

[Christopher Faylor]

On Mon, Oct 03, 2005 at 09:32:53PM +0100, Ivan Novick wrote:
>I would subscribe to the MinGW list as this is a key technology to  
>making cygwin/windows cross compiling work
>
>http://www.mingw.org/

If you're using Cygwin, then the *cygwin* list (see
http://cygwin.com/lists.html) is where you'd discuss things.  MinGW is a
different kettle of fish.

>>On Oct 1, 2005, at 4:41 AM, Brian Rose wrote:
>>
>>>I am an embedded software developer and I am interested in using  
>>>GCC as a
>>>cross-compiler on the Cygwin/Windows platform. I would like to  
>>>know which lists I should subscribe to in order to discuss this  
>>>effort.
--
Christopher Faylor  spammer? -> [EMAIL PROTECTED]
Cygwin Co-Project Leader[EMAIL PROTECTED]
TimeSys, Inc.

Re: Cross Compiler Unix - Windows

[Christopher Faylor]

WHY are you resurrecting this discussion?

On Mon, Sep 19, 2005 at 03:30:37PM +0200, Gerald Pfeifer wrote (after a 2+ week 
delay):
>On Fri, 2 Sep 2005, Christopher Faylor wrote:
>>Huh?  What does "Red Hat" have to do with anything?  "Red Hat" doesn't
>>provide the tools.  Cygwin is a volunteer effort.
>
>According to http://cygwin.com/license.html (and the link from there)
>Red Hat does provide tools for some set of users at least:
>
>Red Hat sells a special Cygwin License for customers who are unable to
>provide their application in open source code form.  For more
>information, please see: http://www.redhat.com/software/cygwin/

Uh, yeah.  I wonder who wrote those words.

Ok.  Yes.  Red Hat does sporadically and half-heartedly sell the Cygwin
tools.  However no one, prior to this had mentioned Red Hat.  We're in a
free-software forum which was talking about Cygwin so the correct
supposition is that we're not talking to the 2 Red Hat Cygwin customers
here.  We're talking to people who have accessed Cygwin via the
cygwin.com web site.  That site is maintained by volunteers (mainly me).
The software is provided free of charge from the cygwin site, not by
Red Hat, like any other free software project out there.

Conflating Red Hat policy with the free software distribution used by
99.99% of cygwin users is not useful.

cgf

Re: PING [4.1 regression, patch] build i686-pc-mingw32

[Christopher Faylor]

On Mon, Jul 25, 2005 at 05:33:19PM -0400, Christopher Faylor wrote:
>On Mon, Jul 25, 2005 at 05:23:54PM -0400, DJ Delorie wrote:
>>>Maybe one solution would be to patch pex-win32 for mingw so that it
>>>could understand '#!' style shell scripts?  That would at least allow
>>>bootstrapping.
>>
>>That would be wonderful, and that's exactly the right place to put it
>>too.  I'm assuming I can persuade one of you to do that?  ;-)
>>
>>I'm going to define pex-win32.c as being within the realm of the mingw
>>maintainership (if you hadn't assumed that already).
>
>I'd be happy to implement this.  I'd like to get Danny's opinion on this
>first, though, in case I missed something.

With DJ's (private) approval, I've checked in a fix to implement this.
Sorry for the long delay.

cgf

Re: Any plan to support Windows/x86-64?

[Christopher Faylor]

On Tue, Sep 13, 2005 at 12:26:43PM -0400, Ross Ridge wrote:
>> Is there any plan to support Windows/x86-64?
>
>I haven't heard of anyone wanting to work on such a port.
>
>> What are needed for the port?
>
>What you'ld need for any OS port.  GCC needs to support the Windows
>x64 ABI, you need a suitable runtime library, and you need a suitable
>assembler and linker.
>
>I'm not sure how close the Windows x64 ABI is to the x86-64 ABI, but it
>seems to be a fair bit different.  Porting MinGW should be the simplest
>way to get a suitable runtime library, though maybe you'ld want to use
>a newer version of the Microsoft C runtime libary.  Using binutils as
>the assembler and linker is pretty much a given, but they'd need to be
>ported to support the Windows x64 PE32+ PECOFF, if they don't already.

FWIW, the most recent Cygwin snapshot (which will soon be Cygwin 1.5.19)
works fairly well on Windows 64 so it is possible to have a linux-like
environment on Windows 64 if someone wanted to develop there.  It's
probably easier to just develop on Linux using a cross compiler, though.

Porting MinGW is definitely the way to go.  It will be a major effort to
get Cygwin working as a true 64-bit app.

cgf

Re: Cross Compiler Unix - Windows

[Christopher Faylor]

On Tue, Aug 30, 2005 at 10:19:36AM +0300, Kai Ruottu wrote:
>Dave Korn wrote:
>>>What becomes to Cygwin and MinGW, the same attitude as followed with
>>>Linux, that "producing any apps for Windoze should happen only on
>>>Windoze, or that when one does it on some other host, it still should
>>>happen just like on Windoze!", is totally weird to me.
>>
>>It seems weird to me too.  Especially considering that at least one of
>>the main cygwin developers builds everything on linux with a
>>linux-x-windows toolchain.  So perhaps you have misunderstood the
>>situation with cygwin; cross-development is certainly possible, and
>>_intended_ to be possible.  It certainly isn't any kind of policy to
>>_deliberately_ make development only possible on native hosts.
>
>Recommending Cygwin for 'ordinary users' as the preferred place for
>building GNU apps for Windoze, sounds weird.  Just as doing the same
>with MinGW/MSYS.  The developers can have Linuces etc.  better
>platforms available and may require to produce everything for Linux
>etc.  first and for Windoze too...  Only building can be enough, no
>very hard testing or debugging in order to get the application to work
>is expected...

So, you think that when people need to build windows apps, the
"recommendation" should be that people should buy a linux box, put their
sources on the linux box, figure out where to get or how to build a
cross compiler, build the sources, and then figure out how to transfer
the sources to the windows platform.

The alternative is to install Cygwin or MSYS and then just build your
sources without worrying about linux, cross compilers, or how to transfer
software to/from windows.

Ever heard of Occam's razor?

>This is quite the same as recommending people to build their own sport
>cars from Volkswagens in garages instead of doing this in car factories
>because only real Porches will be built in factories.  People keep
>their self-built cars there so of course these must be built there.  Or
>something...

I have no idea what this analogy is trying to say but, again, recommending
to people that they go out of their way not to build on the platform that
they are targetting is clearly not the most straightforward or foolproof
plan.

>If one wants to produce tens of binutils, GCCs etc.  GNU stuff for the
>Windoze host, the native Windoze shouldn't be the recommendation.  Not
>at least when the recommendation comes from Red Hat or from any other
>Linux company.  If Red Hat delivers the Cygwin tools for only the
>Windoze host, what else this is than a recommendation to use Windoze
>instead of their own Linux for the Windoze target development?

Huh?  What does "Red Hat" have to do with anything?  "Red Hat" doesn't
provide the tools.  Cygwin is a volunteer effort.  The fact that you can
build cross compilers from some other system to windows doesn't mean
that Cygwin is at fault for not providing the cross compilers.  The
whole *point* of Cygwin is to provide a linux-like environment for
Windows.

The fact that I do build the cygwin release on linux doesn't mean that
I'd recommend doing this to every person who wants to compile stuff for
Windows.
--
Christopher Faylor  spammer? -> [EMAIL PROTECTED]
Cygwin Co-Project Leader[EMAIL PROTECTED]
TimeSys, Inc.

Re: 4.2 Project: "@file" support

[Christopher Faylor]

On Thu, Aug 25, 2005 at 11:00:50AM -0400, DJ Delorie wrote:
>> FWIW, I should note that GCJ already has support for @file
>> style list of input files:
>> 
>>   http://gcc.gnu.org/onlinedocs/gcj/Input-and-output-files.html
>> 
>> and has had it for quite some time now.
>
>DJGPP and Cygwin hosted programs will never see these options, because
>the runtime has already expanded them if appropriate.
>
>Which means your documentation is *wrong* for those platforms; for
>them, *any* command line option is legal in @file.

Unless the @file contains a file that begins with a '\@' that got passed
on to gcc, presumably.  I guess that would mean that you'd need to do
some complicated quoting to actually pass a file beginning with '@' to
gcc.

cgf

Re: [patch] Fix i386-mingw32 build failure

[Christopher Faylor]

On Thu, Aug 25, 2005 at 04:00:53PM -0400, DJ Delorie wrote:
>> So, should it default to finding an executable on the path first and
>> then look for MinGW/MSYS versions of the program if it can't find
>> the executable on the path?
>
>Hmmm... 99% of the cases will be "#!/bin/sh" anyway.  What's the
>"right" shell to run for that in MinGW?  If you can detect MinGW[*],
>and check the right MinGW places first, that's probably the best
>solution.
>
>[*] I'm thinking of an #ifdef in libiberty, nothing fancy.

The problem is that there's MinGW and there's MSYS.  MSYS is a Cygwin
fork that many MinGW people use as a build environment.  I can detect
that the compiler is a MinGW compiler but I can't necessarily detect, at
compile time, that MSYS is being used.  I can detect this at runtime,
though, but that means building in MSYS awareness iff pex-win32.o is
being built for MinGW.  I guess that can't really hurt.

cgf

Re: [patch] Fix i386-mingw32 build failure

[Christopher Faylor]

On Thu, Aug 25, 2005 at 02:59:24PM -0400, DJ Delorie wrote:
>pex-win32 is used by both MinGW and generic "winnt" targets, so I'd
>say keeping it generic is preferred, but if MinGW can be detected, add
>those checks too.

So, should it default to finding an executable on the path first and
then look for MinGW/MSYS versions of the program if it can't find
the executable on the path?

cgf

Re: [patch] Fix i386-mingw32 build failure

[Christopher Faylor]

On Thu, Aug 11, 2005 at 02:20:04PM -0400, Christopher Faylor wrote:
>On Wed, Aug 10, 2005 at 05:30:03PM -0400, DJ Delorie wrote:
>>> Well, it's stopping a real fix for the MinGW build failure being made.
>>> Adding #! support to libiberty won't work because the problem scripts
>>> have MSYS/Cygwin paths for the shell (eg. "/bin/sh") that aren't likely
>>> to be valid to plain Windows.
>>
>>DJGPP solves this thusly:
>>
>>  /* If INTERP is a Unix-style pathname, like "/bin/sh", we will try
>> it with the usual extensions and, if that fails, will further
>> search for the basename of the shell along the PATH; this
>> allows to run Unix shell scripts without editing their first line.  */
>
>That was the technique I am in the process of using, too.
>
>Hmm.  You know, I probably should just steal the code from DJGPP...

I am nearly ready to commit this patch but I went overboard and had it
search in mingw and MSYS locations for the program to run (i.e.,
"/bin/sh").  Then it occurred to me that maybe this was a little too
"product specific" for something like libiberty.

So, the question is, should pex-win32.c encapsulate specific knowledge
about MinGW and MSYS?  Or should I yank out that code and just search
for "sh" along the path?

FWIW, finding the appropriate directories for MinGW and MSYS requires
using a few of WindowsRoutinesForQueryingStuff.

cgf

Re: [patch] Fix i386-mingw32 build failure

[Christopher Faylor]

On Wed, Aug 10, 2005 at 05:30:03PM -0400, DJ Delorie wrote:
>> Well, it's stopping a real fix for the MinGW build failure being made.
>> Adding #! support to libiberty won't work because the problem scripts
>> have MSYS/Cygwin paths for the shell (eg. "/bin/sh") that aren't likely
>> to be valid to plain Windows.
>
>DJGPP solves this thusly:
>
>  /* If INTERP is a Unix-style pathname, like "/bin/sh", we will try
> it with the usual extensions and, if that fails, will further
> search for the basename of the shell along the PATH; this
> allows to run Unix shell scripts without editing their first line.  */

That was the technique I am in the process of using, too.

Hmm.  You know, I probably should just steal the code from DJGPP...

cgf

Re: [patch] Fix i386-mingw32 build failure

[Christopher Faylor]

On Wed, Aug 10, 2005 at 11:41:30AM -0700, Mark Mitchell wrote:
>However, by the time I write this, I see that DJ -- who is a right
>person to answer to talk about the purpose of libiberty -- thinks #! is
>a good idea.  So, consider me the loyal opposition; let's get on with
>the fix you and DJ like.  :-)

Not to beat a dead horse, but this was all decided two weeks ago between
DJ as the libiberty/configury maintainer and Danny Smith and I as the
windows maintainers.  So, I would submit that the right people had
already made the decision.  I wouldn't have volunteered to make a change
to libiberty without DJ's blessing of the idea.

I'm building a compiler now to check out my changes.

cgf

Re: [patch] Fix i386-mingw32 build failure

[Christopher Faylor]

On Wed, Aug 10, 2005 at 10:38:26AM -0700, Mark Mitchell wrote:
>Daniel Jacobowitz wrote:
>>On Wed, Aug 10, 2005 at 10:05:26AM -0700, Mark Mitchell wrote:
>>
>>>Christopher Faylor wrote:
>>>
>>>
>>>>This would conflict with my proposed changes to pex-win32.c .  It seems
>>>>like getting '#!' functioning on mingw would be a better solution than
>>>>relying on $(LN) on mingw.
>>>
>>>FWIW, I'm opposed to the "#!" change to MinGW.  It just seems hackish to 
>>>me, and it means that we'll pay an additional cost on all normal uses of 
>>>pex-* on MinGW, even after the compiler is installed.
>>
>>
>>Not if it's implemented after CreateProcess fails, we won't.  I don't
>>think your argument applies.
>
>Good point!
>
>I still think it's a bad solution, though; it's imposing special 
>semantics for process execution in libiberty, rather than the normal 
>ones that you would expect from the OS.

Aren't the pex* functions designed to provide a uniform interface where
"uniform" means "like unix"?

cgf

[ADMINISTRIVIA] email screw up at sourceware.org/gcc.gnu.org/cygwin.com

[Christopher Faylor]

I just accidentally deleted qmail's outgoing queue on sourceware,
thinking that I was actually deleting the queue on a new, improved
system which will be coming on line soon.  This caused all outgoing
email to be deleted.

The majority of people affected were spammers but I'm sure that people
from all of the active mailing lists were affected as well, although
there should be a limited number of those people.

This should only affect people who hadn't yet gotten the latest email
message as of the time of my screw-up, which was at 8/9/2005 19:16 GMT.
So, if you were unlucky enough to have email in the queue prior to that,
it's gone now.  Email subsequent to that time should still be ok.

I don't know of any way to recover the lost email so, if this matters to
you, please check the archives of your mailing list to see if you lost
anything.

I apologize for the inconvenience.  That was two stupid mistakes today.  I
guess I shouldn't be doing any sysadmin stuff right now.

Note that I've set the reply-to of this message to the overseers mailing
list since I don't think this is an issue which is of general interest to
all of the mailing lists that I've cc'ed.

cgf

Re: [patch] Fix i386-mingw32 build failure

[Christopher Faylor]

On Tue, Aug 09, 2005 at 09:33:19AM +0200, Paolo Bonzini wrote:
>>Can someone with approval privilege over the build system look at this, 
>>and OK it? (it's a very simple patch)
>
>I must apologize for the delay in handling this.  This alternative patch 
>avoids that mingw is hardcoded in the makefiles.  FWIW, it is also even 
>smaller,
>
> 3 files changed, 19 insertions(+), 12 deletions(-)
>
>vs.
>
> 1 files changed, 25 insertions(+), 10 deletions(-)
>
>:ADDPATCH build:
>
>I have only tested it on Linux, can you give it a try?  Ok if FX's 
>testing succeeds?
>
>2005-08-09  Paolo Bonzini  <[EMAIL PROTECTED]>
>
>   * config.build (build_have_sh_scripts): Default to yes,
>   set to no for mingw32.
>   * configure.ac (build_have_sh_scripts): AC_SUBST it.
>   * Makefile.in (stamp-as, stamp-collect-ld, stamp-nm): If
>   build_have_sh_scripts is false, rely on $(LN).
>   * configure: Regenerate.

This would conflict with my proposed changes to pex-win32.c .  It seems
like getting '#!' functioning on mingw would be a better solution than
relying on $(LN) on mingw.

I haven't gotten around to implementing this in libiberty because I've
been on vacation but I should have time to do this this week, if it is
still desirable.

cgf

Re: [patch] Fix i386-mingw32 build failure

[Christopher Faylor]

On Sat, Aug 06, 2005 at 01:37:44PM +0200, FX Coudert wrote:
>PING ** 2
>
>Attached patch fixes PR bootstrap/22259 (right now, a simple ./configure 
>&& make build fails on i386-mingw32). It creates a special case for 
>in-tree as, collect-ld and nm scripts: since mingw32 cannot spawn shell 
>scripts, it copies $(ORIGINAL_AS_FOR_TARGET), $(ORIGINAL_LD_FOR_TARGET) 
>and $(ORIGINAL_NM_FOR_TARGET) in the tree.
>
>There has been discussion on whether this is the best way to do things
>(see thread from 
>http://gcc.gnu.org/ml/gcc-patches/2005-07/msg01193.html), but nobody 
>suggested another patch that actually makes build possible on 
>i386-mingw32. And, from what I have understood, none of the mingw 
>maintainers have anything against the patch, but they can't approve it.
>
>Can someone with approval privilege over the build system look at this, 
>and OK it? (it's a very simple patch)

Did you read all of the discussion about this the last time this came
up?  The consensus seemed to be that this was not the way to fix the
problem.  I suggested that modifying pex-* functions to understand #!
scripts might be the best way to deal with this.

I will do this eventually, but if you want to take a crack at it,
please feel free.

cgf

Re: Mailing list archive header wrong for fortran

[Christopher Faylor]

On Wed, Jul 27, 2005 at 12:14:38PM +0200, Gerald Pfeifer wrote:
>On Wed, 27 Jul 2005, Steven Bosscher wrote:
>> Jack Howarth pointed out to me that when you look at the archives for
>> the [EMAIL PROTECTED] list at http://gcc.gnu.org/ml/fortran/current/,
>> you get this header:
>> 
>> This is the mail archive of the [EMAIL PROTECTED] mailing list for the 
>> Fortran 95 project.
>> 
>> Note the [EMAIL PROTECTED]  This should of course be
>> [EMAIL PROTECTED]  Who can fix this?
>
>[EMAIL PROTECTED] should be able to help.

I'm fixing this now.

cgf

Re: PING [4.1 regression, patch] build i686-pc-mingw32

[Christopher Faylor]

On Mon, Jul 25, 2005 at 05:23:54PM -0400, DJ Delorie wrote:
>>Maybe one solution would be to patch pex-win32 for mingw so that it
>>could understand '#!' style shell scripts?  That would at least allow
>>bootstrapping.
>
>That would be wonderful, and that's exactly the right place to put it
>too.  I'm assuming I can persuade one of you to do that?  ;-)
>
>I'm going to define pex-win32.c as being within the realm of the mingw
>maintainership (if you hadn't assumed that already).

I'd be happy to implement this.  I'd like to get Danny's opinion on this
first, though, in case I missed something.

cgf

Re: PING [4.1 regression, patch] build i686-pc-mingw32

[Christopher Faylor]

On Mon, Jul 25, 2005 at 04:48:45PM -0400, DJ Delorie wrote:
>> Presumably, people with blanket write privs and people responsible for
>> the build machinery.
>
>Yup, that's them.
>
>I did a little historical digging on this item, and the original
>trigger was http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00280.html
>where Paolo needed to switch from symlinks to hardlinks for toplevel
>bootstrapping.  So, I think we've confused the issue enough that we
>may be making bad decisions (or at least *I* am confused and may make
>bad decisions ;).
>
>Paolo, could you go back and think about the bootstrapping problem
>from MinGW's perspective?
>
>Danny, could you summarize which build features MinGW supports?  (I
>assume cp and $(SHELL) but not symlinks, hardlinks, or #!).  DJGPP and
>Cygwin shouldn't be a problem here; they both support symlinks and #!
>but I don't think they support hardlinks.

For shell commands, the MSys build environment supports pretty much
everything that Cygwin does, which would be everything currently in that
makefile rule.  The problem is that when gcc executes, it uses
(eventually) the unadulterated Windows CreateProcess call which does not
understand cygwin/MSys symlinks or '#!' shell scripts or any other type
of shell script.  It would understand a .bat or .cmd file, but adding
.bat or .cmd file processing to Makefile.in is probably not something
that we want to do.

Hard links would be supported by everything since Windows understands
hard links at the OS level and Cygwin/MSys can create them (in some
cases).  They aren't a generic solution, however, as the makefile rule
demonstrates.

Maybe one solution would be to patch pex-win32 for mingw so that it
could understand '#!' style shell scripts?  That would at least allow
bootstrapping.  It wouldn't be useful generic pure-windows installation,
but presumably a user wouldn't have to worry about that because
everything would be installed correctly.

cgf

Re: PING [4.1 regression, patch] build i686-pc-mingw32

[Christopher Faylor]

On Mon, Jul 25, 2005 at 03:37:55PM +0200, Fran?ois-Xavier Coudert wrote:
>Coming back to this topic.
>
>Nobody has answered to one of my questions: if the mingw/cygwin
>maintainers can't approve such a patch, who can?

Presumably, people with blanket write privs and people responsible for
the build machinery.

cgf

Re: PING [4.1 regression, patch] build i686-pc-mingw32

[Christopher Faylor]

On Wed, Jul 20, 2005 at 11:10:49PM -0400, DJ Delorie wrote:
>>Wouldn't that mean that 'cp' is a valid fallback even for non-GNU lds?
>
>We don't know what *else* a non-gnu linker/assembler might need.

I guess what I'm trying to get at here is some feeling for whether the
shell script method is there to work around a known problem or if it
is just working around a potential problem which might occur on some
theoretical platform which insists that its ld must be run from a
specific location.

But I guess it's no more than idle curiousity.

cgf

Re: PING [4.1 regression, patch] build i686-pc-mingw32

[Christopher Faylor]

On Wed, Jul 20, 2005 at 10:58:05PM -0400, DJ Delorie wrote:
>> Is that actually true, though?  Doesn't GNU ld try to locate files
>> relative to its invoked path?
>
>Sometimes, for sysroots and ldscripts.  I wouldn't expect MinGW (or
>any native linker) to use this feature.  GCC usually passes ld
>whatever path specifications it needs.

Wouldn't that mean that 'cp' is a valid fallback even for non-GNU lds?

>> Since we know that mingw uses GNU ld couldn't we prewire this action
>> into configure by default and avoid the need for this kind of
>> system-specific behavior in the makefile?
>
>A thought occurs to me... we *know* how to build build-system
>executables, like gen*.exe.  Why can't we have small C programs that
>know where as/ld are, know how to exec them portably (libiberty), etc?
>That gives us the functionality of symlinks even on platforms like
>MinGW that support neither symlinks nor shell scripts, without the
>nasty side effects of using cp or symlinks.
>
>Heck, it can even search $PATH for us.

That sounds like a good idea to me.

cgf

Re: PING [4.1 regression, patch] build i686-pc-mingw32

[Christopher Faylor]

On Wed, Jul 20, 2005 at 10:25:06PM -0400, DJ Delorie wrote:
>> Except that "cp" is already used as a fallback for when "ln" doesn't
>> work.  If the tool is likely not to work after a "cp" then shouldn't the
>> fallback condition be to always create a shell script (or .bat file)?
>
>One could argue that, in the case with ln/cp, we *know* we're dealing
>with GNU tools which don't care where they are, but in the case with a
>system (i.e. third party) tool, we don't know, hence the script.

Is that actually true, though?  Doesn't GNU ld try to locate files
relative to its invoked path?

Is there a non-GNU ld out there which needs to reference things relative
to its path?

>There's also the complexity of locating a utility in $PATH, which may
>even change between configure and make.
>
>IMHO for MinGW, we (1) know that we're using GNU tools, and (2)
>realize we have an exceptional situation wrt the build system.  I
>think this justifies an exception test in that snippet of code.

I hate seeing this kind of system exception in code.  As much as I like
MinGW, this is one of the things that bugs me about it.  Adding
window-isms to code can be like a creeping fungus.

Danny Smith said this:

>I just configure using --with-as=/path/to/original-as-for-target and I
>don't run into the problem.

Since we know that mingw uses GNU ld couldn't we prewire this action
into configure by default and avoid the need for this kind of
system-specific behavior in the makefile?

cgf

Re: PING [4.1 regression, patch] build i686-pc-mingw32

[Christopher Faylor]

On Tue, Jul 19, 2005 at 04:21:04PM -0400, Daniel Jacobowitz wrote:
>On Tue, Jul 19, 2005 at 04:14:04PM -0400, Christopher Faylor wrote:
>>Ok.  Given that 'cp' was an acceptable fallback in the original version
>>of the above script, I wonder why 'cp' wasn't used instead of creating
>>a shell script wrapper.
>
>Because it is desirable to leave the tools where they were:

Except that "cp" is already used as a fallback for when "ln" doesn't
work.  If the tool is likely not to work after a "cp" then shouldn't the
fallback condition be to always create a shell script (or .bat file)?

cgf

Re: PING [4.1 regression, patch] build i686-pc-mingw32

[Christopher Faylor]

On Tue, Jul 19, 2005 at 10:03:14PM +0200, FX Coudert wrote:
>>I'd prefer that Danny review this but neither of us has the right to
>>approve this patch.
>
>Well, then, who has the right to approve such a patch?
>
>>However, it seems like you're adding extra stuff to the Makefile where
>>it is already trying to do the right thing if $(LN) fails.  Couldn't LN
>>just be declared as "cp" for mingw or, alternatively, couldn't it be
>>defined as some failing command so that the cp in the failing condition
>>would be invoked?
>
>Well, perhaps I wasn't clear enough on what is the problem:
>
>-  case "$<" in \
>-./*) ;; \
>-../*) \
>-   echo $(LN) $< as$(exeext); \
>-   $(LN) $< as$(exeext) || cp $< as$(exeext) ;; \
>-*) echo '#!$(SHELL)' > as; echo 'exec $< "$$@"' >> as ; \
>-   chmod +x as ;; \
>+  case "$(build)" in \
>+*mingw32*) \
>+  cp $< as$(exeext) ;; \
>+*) \
>+  case "$<" in \
>+./*) ;; \
>+../*) \
>+  echo $(LN) $< as$(exeext); \
>+  $(LN) $< as$(exeext) || cp $< as$(exeext) ;; \
>+*) echo '#!$(SHELL)' > as; echo 'exec $< "$$@"' >> as ; \
>+  chmod +x as ;; \
>+  esac \
>
>The cases with ./*) and ../*) already well handled, and just kept "as 
>is" when $(build) is mingw32. The $(LN) command succeeds, that's not the 
>problem.
>
>Only the remaining case, which creates a shell script, fails on mingw32. 
>The shell script is spawned to call the assembler, which fails. Only 
>real win32 executables can be spawned.

Ok.  Given that 'cp' was an acceptable fallback in the original version
of the above script, I wonder why 'cp' wasn't used instead of creating a
shell script wrapper.

cgf

Re: PING [4.1 regression, patch] build i686-pc-mingw32

[Christopher Faylor]

On Tue, Jul 19, 2005 at 11:07:33AM +0200, FX Coudert wrote:
>PING. Could one of the mingw/cygwin maintainers review this patch? Or 
>can someone else do it?
>
>http://gcc.gnu.org/ml/gcc-patches/2005-07/msg00086.html

I'd prefer that Danny review this but neither of us has the right to
approve this patch.

However, it seems like you're adding extra stuff to the Makefile where
it is already trying to do the right thing if $(LN) fails.  Couldn't LN
just be declared as "cp" for mingw or, alternatively, couldn't it be
defined as some failing command so that the cp in the failing condition
would be invoked?

cgf

Re: successful build on i686-pc-cygwin

[Christopher Faylor]

On Sat, May 07, 2005 at 04:44:44PM +0100, Dave Korn wrote:
>Original Message
>>From: J?rgen Havsberg Seland
>>Sent: 06 May 2005 23:30
>
>>additional information: Important to mount all binary folders with the
>>-X option, as otherwise command-lines will be too long, for instance:
>>
>>mount -f -X c:/cygwin/bin /bin
>>
>>Important: This also goes for the executables built, so having your
>>objdir inside a mount with cygexec enabled is required.
>
>Strange that, I didn't have any similar trouble.  Did you unpack the
>source into a directory that had a fairly long path name to start with?

It could also be an environment variable problem.  Too many environment
variables could overflow the windows enviroment buffer unless you use
"-X".

cgf

Re: Write after approval - processed by "None".

[Christopher Faylor]

On Fri, Mar 11, 2005 at 09:54:09PM -0500, Ian Lance Taylor wrote:
>James E Wilson writes:
>
>> On Fri, 2005-03-11 at 17:48, Ian Lance Taylor wrote:
>> > All true, but I want to note that the preferred non-GNU name is
>> > sourceware.org.
>> 
>> What about the trademark status?  Last I heard, the trademark holder had
>> asked us to stop using the name.  That is when and why the machine got
>> renamed away from sourceware.org.  I have been careful not to use the
>> sourceware name since.  The sourceware.org name was kept for
>> convenience, but wasn't supposed to be advertised.  Did this trademark
>> issue ever get resolved?
>
>Back in 1997, they asked Cygnus to stop using the term sourceware to
>describe Cygnus's products.  I can't remember whether Cygnus changed
>the machine name from sourceware.cygnus.com to sources.cygnus.com, or
>whether the change happened after the Red Hat purchase.

It happened after the Red Hat purchase.

cgf