Re: Updated Sourceware infrastructure plans

[Frank Ch. Eigler via Gcc]

Hi -

> Would it be possible for gitsigur to support signing commits with ssh
> keys as well as gpg? Git supports this, and it's much easier for
> everybody than having to set up gpg. [...]

It would save some effort, but OTOH plenty of people have gpg keys
too, and the common desktop key agents support both.

> We already need an SSH key on sourceware.org to push to Git, so all
> those public keys could be treated as trusted (via git config
> gpg.ssh.allowedSignersFile). [...]

One difference is that gitsigur aims to prevent impersonation, by
tying the recorded committer to a designated set of keys for that
committer.  The git builtin ssh-signing gadget doesn't attempt this.
But maybe just a small matter of wrapping might do the job.

Filed https://sourceware.org/bugzilla/show_bug.cgi?id=31670 .

> I'm already signing my GCC commits that way, without needing to use
> gpg or gitsigur:

Great, keep it up!  Nothing has been stopping people from signing
their commits any way they like, including even more complex ways like
sigstore.  gitsigur verification is not enabled (even in permissive
mode) at all for gcc at this time.

> commit 7c2a9dbcc2c1cb1563774068c59d5e09edc59f06 [r14-10008-g7c2a9dbcc2c1cb]
> Good "git" signature for jwak...@redhat.com with RSA key
> SHA256:8rFaYhDWn09c3vjsYIg2JE9aSpcxzTnCqajoKevrUUo

Thanks, this will help test a prototype later on.

- FChE

Re: adacore git-hooks - daemon-mode email vs. systemd-logind linger

[Frank Ch. Eigler via Gcc]

Hi, Joel -

> [...]  Thinking more long term, I think there are talks about using
> a more comprehensive system for source and contribution management,
> similar to products such as GitLab or GitHub. [...]

(Yeah, but I wouldn't count on any of that in the medium term.)


> [...] That's why I tend to think that, for the moment,
> I'd go the simplest route overall: In this case, I think the simplest
> is to just have a way to disable the daemon mode, and just have
> the users wait. In the vast majority of cases, the wait will be
> a few seconds. Even with a patch-series of a 100 patches, it would
> mean a 1min40s wait. Very bearable.

Right. the EMAIL_DELAY_IN_SECONDS time of 5s could be reduced to 1s,
or even 0.


- FChE

Re: Updated Sourceware infrastructure plans

[Frank Ch. Eigler via Gcc]

Hi -

> [...]  I suggest that a basic principle for such a system is that it
> should be *easy* to obtain and maintain a local copy of the history
> of all pull requests.  That includes all versions of a pull request,
> if it gets rebased, and all versions of comments, if the system
> allows editing comments.  A system that uses git as the source of
> truth for all the pull request data and has refs [...]

Do you know of a system with these characteristics?

- FChE

adacore git-hooks - daemon-mode email vs. systemd-logind linger

[Frank Ch. Eigler via Gcc]

Hi, Joel -

As a part of more security review on sourceware, I had recently
experimented with systemd logind's KillUserProcesses=yes option.  It
turns out that this nuked one aspect adacore hooks' post-receive
processing, which create a background process to slowly dribble out
emails.

I restored KilledUserProcesses=no for now, but I'd really like to set
that back.  That means the hooks would have to change.  Here are a
couple of options:

- just send the emails immediately, without the daemon stuff; if the
  delays are there to try to sequentialize them, consider instead
  getting the hooks to emit Message-Id:/In-Reply-To:/Date: headers to
  let MUA's sort properly at reception
  
- invoke the email sending wrapped in a "systemd-run --user"
  deferred execution gadget, including a "sleep XXX" if you must
  keep time-hope-based sequencing

- move email stuff entirely out of the hooks; these repos are "public
  property" anyhow, and we can put cron jobs in place elsewhere to
  trigger email notifications about commits; heck, they could run the
  hook code itself later, just feed it retrospective git-hook lines

- FChE

Re: Sourceware mitigating and preventing the next xz-backdoor

[Frank Ch. Eigler via Gcc]

Hi -

>This is very true, however a few words of caution: IME this is a
>maintainability nightmare. Fixing patches that forgot to regenerate,
>regenerating on rebase, confirming everything is up-to-date before
>merge, etc etc. It can be handled, I have, but it was painful and
>time-consuming.The hardest part was ensuring everyone was actually
>running the "right" version of Auto* [...]

One way to make the nightmare into a light hassle is to let developers
commit auto* hand-written inputs with or without Complete Properly
refreshed generated bits, and let a maintainer or bot (but I repeat
myself) periodically regenerate the derived auto* content.

- FChE

Re: Sourceware mitigating and preventing the next xz-backdoor

[Frank Ch. Eigler via Gcc]

Hi -

> In Autotools, `make dist` produces a tarball that contains many
> files not present in the source respoitory, it includes build system
> core files and this fact was used for the xz attack. In contrast,
> for newer build systems the "release tarball" is purely a snapshot
> of the source repository: there is no `cmake dist`, and `meson dist`
> is essentially `git archive` [...]

For what it's worth, not every auto* using project uses "make dist" to
build their release tarballs.  If they can get over the matter of
including auto*-generated scripts being located in the source repo,
then indeed a "git archive" is sufficient.  Several of the projects I
work on do just this.  (As a bonus, that makes the git repos immediately
buildable by developers, without need to re-auto* anything.)

- FChE

[wwwdocs] tweak for sourceware account request alias

[Frank Ch. Eigler]

diff --git a/htdocs/gitwrite.html b/htdocs/gitwrite.html
index 0c146aba44d2..c89cdb8fb2ef 100644
--- a/htdocs/gitwrite.html
+++ b/htdocs/gitwrite.html
@@ -36,7 +36,7 @@ be sponsored by an existing maintainer (someone with "write 
after approval"
 is not sufficient).
 
 If you already have an account on sourceware.org / gcc.gnu.org, ask
-overse...@gcc.gnu.org to add access to the GCC repository.
+admin-reque...@sourceware.org to add access to the GCC repository.
 Include the name of your sponsor and CC: them.
 Otherwise use https://sourceware.org/cgi-bin/pdw/ps_form.cgi;>this form,

Re: Checks that autotools generated files were re-generated correctly

[Frank Ch. Eigler via Gcc]

Martin Jambor  writes:

> [...]  I have inherited Martin Liška's buildbot script that checks
> that all sorts of autotools generated files, mainly configure scripts,
> were re-generated correctly when appropriate.  [...]

The gccadmin account on sourceware already does some daily routine git
commits ("Daily bump.").  You could decide to delegate regeneration of
the configury to the same service.  It could run on a scheduled basis
rather than the commit hook, if people are angsty about that.

It would use designated master auto* tool versions.  None of the
developers would have to struggle keeping them matched: just commit the
inputs.  Or if they commit regenerated versions but with an oddball
auto* version, the sourceware bot could fix that later.

- FChE

Re: Hundreds of gcc.dg/guality failures on both 14 and 13.1 branches

[Frank Ch. Eigler via Gcc]

Hi -

Hi -

> (CC Frank, the fedrawhide builder doesn't seem to include guality.exp,
> do you know why?)

Good question.  The gcc.log testsuite file appears to be truncated as
it arrived into bunsen.  The test does appear to be running on the
bot.  Maybe the gcc's own dg* log processing scripts are messing
something up, before bunsen ever gets a chance to grab them. :(

- FChE

Re: urgent - Google Cloud public subnet blacklisted by gcc.org

[Frank Ch. Eigler via Gcc]

Federico Iezzi via Gcc  writes:

> [...]
> It seems like the GCC frontend/WAF have blacklisted the entire subnet
> used by Google Cloud for Internet access.
> [...]
> $ curl ifconfig.me
> 35.234.162.99

This has been unblocked.  We sometimes must block large subnets when
abusive traffic comes from there.

- FChE

Re: Toolchain Infrastructure project statement of support

[Frank Ch. Eigler via Gcc]

Hi -

> [...]  To be specific, gcc steering committee and glibc FSF stewards
> have announced the decision for their projects [...]

I may be missing something.  All I've seen so far were some of the
leaders of some of the projects being joint signatories to a letter on
overseers@.  As far as I'm aware, that is not how any of these
projects make or announce **project decisions** with/to their
respective constituencies.


> I am not aware of any opposition from maintainers of libabigail or
> cygwin or any other active sourceware based project over moving
> either, but I haven't had any links to those projects, so I may be
> uninformed.

Indeed.  The onus is obviously on the shoulders of the proponents of
this proposal to convince each sourceware guest project to consent to
move.  If you wish to frame any dissent as "blocking full migration",
then I'd say the job of convincing everyone just has not been up to
par.  Perhaps it was the wrong goal all along.


- FChE

Re: Toolchain Infrastructure project statement of support

[Frank Ch. Eigler via Gcc]

Hi -

> [...]  Given that the current sourceware admins have decided to
> block migration of all sourceware assets to the LF IT [...]

If you're trying to say that projects have not unanimously shown
interest in moving infrastructure to LF IT, just say that.  Don't
blame overseers.

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.

- FChE

Re: The GNU Toolchain Infrastructure Project

[Frank Ch. Eigler via Gcc]

Hi -

> [...] Where was a statement from key members of the GNU Toolchain
> projects -- the people who actually use the services and
> infrastructure on a day to day basis for their participation in the
> GNU Toolchain projects -- asking for an alternative proposal? When
> were they allowed to participate in the preparation of the
> "Sourceware" proposal, supposedly for their benefit?  [...]

This echoes a question asked during the Cauldron session.  I believe
it was during the second half, whose Zoom recording is for some reason
still not published.  Could you ask Jeremy to fix that please?

Anyway, to try to recount what I said then: the SFC proposal is
independent of the various guest projects.  It does not pretend to
speak for any of them.  It does not impose any changes on them.  All
the guests are just as welcome to come, stay, and leave, as they have
always been.  For this reason, it was not necessary to draw a
stakeholder map and conduct years-long negotiations behind the scenes.
Everyone has been invited to advise, in public, since August 30.


- FChE

Re: The GNU Toolchain Infrastructure Project

[Frank Ch. Eigler via Gcc]

Hi -

> [...]  As for the rest, it really is a question on whether all of
> sourceware will in the end be migrated over to LF, it's for the
> remaining projects to decide.  If we indeed have all projects on
> board [...]

"we" do not.  That option was taken off the table weeks ago.  For that
matter, I have not seen -any- project decisionmaking bodies formally
announce to/with their developer communities that they wished to move
away, only a few individuals who propose that this be done.

- FChE

Re: The GNU Toolchain Infrastructure Project

[Frank Ch. Eigler via Gcc]

Hi -

> [...] so that we continue to have them involved in the technical
> direction of GNU toolchain infrastructure?  [...]

"continue"?  If the nature & degree of involvement we had so far in
the LF/GTI process is representative of the future, I'm not sure I can
in good faith ask anyone to fund our time on that.  Given that you are
listed as a TAC member, yet admitted being unclear on some details of
the proposal itself, perhaps we're in the same boat.

I cannot speak for the toolchain development community -- and have no
idea who honestly can -- but I suspect that some of the numerous
outstanding questions are material to their eventual decisionmaking on
moving their project to a new host - or staying.

- FChE

Re: The GNU Toolchain Infrastructure Project

[Frank Ch. Eigler via Gcc]

Hi -

> [...] Or alternatively, "sourceware overseers" could become a body
> that maintains sourceware and is able to get funding through SFC for
> its activities?

Great idea -- and this is roughly what's happening.  This "body"
consisting of key individuals has invited other folks interested in
helping with or helping guide the upkeep of shared sourceware
infrastructure to join us.

- FChE

Re: The GNU Toolchain Infrastructure Project

[Frank Ch. Eigler via Gcc]

Hi -

> > I'm afraid I don't understand then what the point of comparing to LLVM
> > with respect to competitiveness or freedom was.  AIUI, infrastructure
> > is an enabler, not really a competitive differentiator.
>
> I suppose that's a difference in our perception then.  I think of
> infrastructure as an accelerator and not just an enabler, which
> makes it a serious competitive differentiator.

Okay, we'd love to hear ideas for infrastructure changes that would
result in accelerating your work as developers.


- FChE

Re: The GNU Toolchain Infrastructure Project

[Frank Ch. Eigler via Gcc]

Hi -

> > > I don't see a risk to freedom.  The GNU toolchain is quite underfunded
> > > compared to llvm/clang and IMO it's a major risk to maintain status quo on
> > > that front.  The GTI opens new avenues for funding aspects of the GNU
> > > toolchain without affecting its core governance.
> > 
> > What aspects of the gnu toolchain are open to being funded via the
> > LF/GTI proposal, -other than- the vast majority of the funds being
> > redirected to its own managed services infrastructure?
> 
> This current proposal is limited to infrastructure, which has ever-growing
> needs.

I'm afraid I don't understand then what the point of comparing to LLVM
with respect to competitiveness or freedom was.  AIUI, infrastructure
is an enabler, not really a competitive differentiator.


> Do you think the current proposal is not an upgrade to what we
> currently have?

I don't know.  I am not under the impression that infrastructure is
holding back development on any of these projects.  Further, I suspect
that if the communities were given a choice to direct the sponsors'
generous donations toward new development type work, they may well
prefer that.  Is that possibility on offer?


- FChE

Re: The GNU Toolchain Infrastructure Project

[Frank Ch. Eigler via Gcc]

Hi -

> > > [...] I think the LF proposal is the best long term way forward for
> > > the GNU toolchain projects to remain competitive *and* Free. [...]
> > 
> > Can you elaborate what risks in terms of competitiveness or freedom
> > you foresee with the status quo?  This is the first I recall hearing
> > of this concern.
> 
> I don't see a risk to freedom.  The GNU toolchain is quite underfunded
> compared to llvm/clang and IMO it's a major risk to maintain status quo on
> that front.  The GTI opens new avenues for funding aspects of the GNU
> toolchain without affecting its core governance.

What aspects of the gnu toolchain are open to being funded via the
LF/GTI proposal, -other than- the vast majority of the funds being
redirected to its own managed services infrastructure?

- FChE

Re: The GNU Toolchain Infrastructure Project

[Frank Ch. Eigler via Gcc]

Hi -

> [...] I think the LF proposal is the best long term way forward for
> the GNU toolchain projects to remain competitive *and* Free. [...]

Can you elaborate what risks in terms of competitiveness or freedom
you foresee with the status quo?  This is the first I recall hearing
of this concern.


- FChE

Re: Rust frontend patches v2

[Frank Ch. Eigler via Gcc-patches]

Hi -


> 12K 0004-gccrs-Add-link-cases-testsuite.patch
> 356K0005-gccrs-Add-general-compilation-test-cases.patch
> 132K0006-gccrs-Add-execution-test-cases.patch
> 4.0K0007-gccrs-Add-gcc-check-target-check-rust.patch
> 656K0008-gccrs-Add-the-Rust-front-end-AST-data-structures.patch
> 112K0009-gccrs-Add-Lexer-for-Rust-front-end.patch
> 504K0010-gccrs-Add-Parser-for-Rust-front-end.patch
> 200K0011-gccrs-Add-expansion-pass-for-the-Rust-front-end.patch
> 204K0012-gccrs-Add-name-resolution-pass-to-the-Rust-front-end.patch
> 476K0013-gccrs-Add-second-intermedite-representation-called-H.patch
> [...]

Just curious whether a human reviewer expected to read through this
much content?  If not, and if this structure is only for machine /
bisecting purposes, maybe they're not worth also emailing.

- FChE

Re: Rust frontend patches v2

[Frank Ch. Eigler via Gcc-rust]

Hi -


> 12K 0004-gccrs-Add-link-cases-testsuite.patch
> 356K0005-gccrs-Add-general-compilation-test-cases.patch
> 132K0006-gccrs-Add-execution-test-cases.patch
> 4.0K0007-gccrs-Add-gcc-check-target-check-rust.patch
> 656K0008-gccrs-Add-the-Rust-front-end-AST-data-structures.patch
> 112K0009-gccrs-Add-Lexer-for-Rust-front-end.patch
> 504K0010-gccrs-Add-Parser-for-Rust-front-end.patch
> 200K0011-gccrs-Add-expansion-pass-for-the-Rust-front-end.patch
> 204K0012-gccrs-Add-name-resolution-pass-to-the-Rust-front-end.patch
> 476K0013-gccrs-Add-second-intermedite-representation-called-H.patch
> [...]

Just curious whether a human reviewer expected to read through this
much content?  If not, and if this structure is only for machine /
bisecting purposes, maybe they're not worth also emailing.

- FChE
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: [PATCH] contrib: use sphinx-build from a venv

[Frank Ch. Eigler via Gcc-patches]

Hi -

> > The gccadmin team can do this kind of thing without overseer/root
> > privileges, or indeed so can any local shell-privileged user.
> 
> Yeah, I said I didn't want to install it that way without overseer
> approval, as pip won't keep the packages up to date the way dnf
> installations do.

Indeed, but that's your own preference/responsibility and does not
affect the system, so no overseer oversight is necessary.

> > (That said, rhel8 includes sphynx 1.7.6 - are you sure that's
> > not satisfactory?)
> 
> That's a different package (full text search engine), what's needed
> here is python3-sphinx.

# rpm -q python3-sphinx
python3-sphinx-1.7.6-2.el8.noarch


- FChE

Re: [PATCH] contrib: use sphinx-build from a venv

[Frank Ch. Eigler via Gcc-patches]

Hi -

> CCing overseers and Frank.
> Can you please help me with that?

> > Can please a maintainer install the package from pip?
> > Something like:
> > virtualenv /home/gcc/venv && /home/gcc/venv/bin/pip install Sphinx
> > or a similar location?

The gccadmin team can do this kind of thing without overseer/root
privileges, or indeed so can any local shell-privileged user.

(That said, rhel8 includes sphynx 1.7.6 - are you sure that's
not satisfactory?)

- FChE

Mailing list reconfiguration: VERP Sender: header affected

[Frank Ch. Eigler via Gcc]

Hi -

I made an experimental configuration change on sourceware/gcc.gnu.org
yesterday that had unforeseen effects on some mailing list
subscribers.  We turned on VERP (variable envelope return paths) on
outgoing mail from mailman, in order to assist tracking mail delivery
problems.  This changes the Sender: field that allows precise handling
of bounces, but interferes with filtering on that field.

If you use Sender:-based filtering for sorting your incoming email
stream, I suggest switching to observing List-Id: instead, or else
using a regexp/substring style of Sender: matching.

We're not sure we're keeping the new configuration yet.  It's
performing well.  With either of the two changes, you would be
immunized against change even if we return to the previous
configuration sometime.  I'm sorry about the inconvenience!

- FChE

Re: Security vulnerabilities affects core API authorization of gnu.org

[Frank Ch. Eigler via Gcc]

Hi -

> Does gnu.org has a bug bounty program or reporting bugs reward policy?

You are not talking to gnu.org, you are talking to gcc.gnu.org admins.
Maybe see webmast...@gnu.org.
I am not aware of any sort of bug bounty in either site.

- FChE

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

[Frank Ch. Eigler via Gcc]

Hi -

> Not the issue of wasted resources including the list server processing 
> and sending the messages intended to my address, bandwidth and all the 
> network equipment involved on the way, and finally the local mail server 
> receiving and dispatching the message to `procmail'.  It all does not come 
> for free.

FWIW, I'd estimate the incremental infrastructure cost of sending
these messages, over not sending these messages, at pretty close to
zero.  The most valuable part is human attention time, which could
make it worthwhile to reduce spamminess.

- FChE

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

[Frank Ch. Eigler via Gcc]

Hi -

> I think irker is broken for a different reason (freenode not allowing 
> #glibc access from accounts not authenticated with NickServ; not sure if 
> that's global configuration or specific to #glibc).

That's probably the +r mode flag on the channel.  Nuke that.

- FChE

Re: List user branches on git web

[Frank Ch. Eigler via Gcc]

Hi -

> > https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=heads;h=refs/users/marxin/heads
> 
> Apparently such page does not list user branches.

I believe this is because of unusual gcc git conventions, where the
refs/heads/ and refs/users/heads/ directories are distinct.  I believe
have gitweb expose those via the config knob extra-branch-refs, which
can also be set via .git/config.

> So a redirection from
> https://gcc.gnu.org/git-branches/marxin/heads/slp-function-v4

... if the above is done, then this probably is not necessary.

- FChE

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

[Frank Ch. Eigler via Gcc]

Hi -

> Would it be reasonable to have the mailing list split into more than
> one, that is at least the original covering the trunk, and then one
> or more for branches?  [...]

(This matter is for the gcc community to decide.  Overseers do not
control git/mailing list traffic policy.)


- FChE

Re: sign_and_send_pubkey: signing failed: agent refused operation

[Frank Ch. Eigler via Gcc]

Hi -

> ~/.ssh/known_hosts exists and ~/.ssh is rwx only by the owner.
> Everything works fine if I add my key by running ssh-add.  What's
> not so great is the errors I get when I forget to do that: "agent
> refused operation?"

Yeah, there is something odd on your side.  Maybe your ssh client is
unable to find the right private key - maybe it's named non-default?
If so, add it to your .ssh/config

   Host gcc.gnu.org sourceware.org
   IdentifyFile ~/.ssh/id_XYZ

> It just feels like too much of a coincidence that I started having
> these problems only after the recent server upgrade.  [...]

I'm afraid it does look like a coincidence.

- FChE

Re: sign_and_send_pubkey: signing failed: agent refused operation

[Frank Ch. Eigler via Gcc]

Hi -

> git pull from the GCC and Glibc repos is failing for me with the error
> below.  It worked fine last week and I haven't made any changes to my
> ssh keys.

And are you logging in from the same workstation with access to the same
set of ssh private keys?

> Is this a transient glitch or has something changed recently that I
> need to make some adjustments for?

I know of nothing relevant that has changed on the sourceware side.

> sign_and_send_pubkey: signing failed: agent refused operation
> mse...@gcc.gnu.org: Permission denied (publickey).
> fatal: Could not read from remote repository.

The usual advice is to run   % ssh -vv gcc.gnu.org alive
and report the ssh level error.

"agent refused operation" sounds like a problem on the client end.


- FChE

Re: rsync access to mailing list archives

[Frank Ch. Eigler via Gcc]

Hi -

> Would it be possible to provide this feature for the current archives,
> too?  [...]

rsync now makes available the master .mbox files for every mailing
list hosted on sourceware:

   rsync gcc.gnu.org::gcc-mbox

This includes historical ezmlm era files as well as the new.

- FChE

Re: Stability of pipermail ml archive URLs

[Frank Ch. Eigler via Gcc]

Hi -

> >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.


> 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.  Spam/malware
that gets through can sit in multiple locations unless we clean it out
in the proper thorough manner, through the entire pipeline (which
starts with the mbox files).  Not super keen on building much
complexity that operates on all the intermediate results and html
files.


- FChE

Re: Stability of pipermail ml archive URLs

[Frank Ch. Eigler via Gcc]

Hi -

> 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.

- FChE

Re: Stability of pipermail ml archive URLs

[Frank Ch. Eigler via Gcc]

Hi -

> 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.

Argh, that is a problem, sorry.  We get mailman to regenerate web
archives for example in the case of spam that has gone through.  Our
recipe has been to delete the spam from the apropriate .mbox, but this
does renumber things.

The big vs. little numbers are probably an accidental function of
whether the email .mbox files were processed chronologically or not.
I'll tweak the mrefresh script to make sure it's chronological; that
should avoid gross jumps like that.  I believe gcc-patches just wasn't
regenerated for spam removal whereas others have.  There should not be
gross jumps in the future, except we'll have to regenerate everything
one more time. :-(

Small jumps though --- darn, we'd have to do something else with spam
in the mbox, maybe replace it somehow in situ with something else.  Or
catch it so quickly that subsequent URLs aren't archived anywhere
important.

It would be good to have another way of making permanent URLs for
individual messages in mailing list archives.

- FChE

Re: Not usable email content encoding

[Frank Ch. Eigler via Gcc]

Hi -

> *Nothing* should touch changelog files :-)  They should be generated from the
> VCS.  IMHO of course.

IMHO: the VCS should be the changelog.

- FChE

Re: blacklisted after announce on GNU cauldron ?

[Frank Ch. Eigler via Gcc]

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.

- FChE

Re: Not usable email content encoding

[Frank Ch. Eigler via Gcc]

Hi -

> > A number of lists I'm on switched to our current style of minging a
> > year or two ago, because gmail users were not receiving mail, because
> > gmail was rejecting the mail.
> 
> I find that unconvincing, because even googlegroup email lists don't 
> mangle From: from sender domains that are now mangled by sourceware.org 
> :-/

It turns out receiving mail FROM google-groups mail is itself
sometimes at risk because it fails to do this From: mangling, and its
ARC/DKIM re-signature of mail requires even more software to process
and bless.  (Its current behaviour on some groups-gmail lists I'm on
are DMARC non-compliant.)

> Can we please switch it off?  It's not like we really had a problem
> before the switch to mailman.

We have offered some first-hand evidence that there were problems,
just they were worked on by people in the background.


- FChE

Re: subversion status on gcc.gnu.org

[Frank Ch. Eigler via Gcc]

Hi -

> There's update SVN to GIT map file:
> https://drive.google.com/file/d/1DMuFDu476stLdMxKSaDzv4c81rhMAGEI/view?usp=sharing

Updated.

- FChE

Re: Not usable email content encoding

[Frank Ch. Eigler via Gcc]

Hi -


> [...]
>  I am fairly sure it breaks `git am' too, requiring a `From' override in 
> the change description for author attribution in patch application to work 
> reliably (I tend to work on my outbox when applying my own patches, so I 
> avoid this issue, but I am sure the issue will hit someone sooner or 
> later).

That part is at least pretty easy: use
  git format-patch --from "Real Name git "
which will then force a second fake From: header into the body of
the commit email, where git-am can find it.

> This is all silly, requiring the SMTP envelope sender to match the `From' 
> header breaks even the most basic e-mail mechanisms like the use of a 
> `.forward' file.  [...]

Unfortunately naive .forward based forwarding looks exactly like faked
or spam email to a third party MTAs.


> How come the Linux kernel people who do e-mail patch management on a
> vastly larger scale than we do, both in terms of traffic and the
> number of mailing list subscribers, can get away without all these
> odd quirks in their list server management?  [...]

I'm not sure, but their mails tend to be laden with a vast number of
Cc:'s, which bypass mailing list reflectors.


- FChE

Re: subversion status on gcc.gnu.org

[Frank Ch. Eigler via Gcc]

Hi -

Courtesy of a lovely httpd RewriteMap-basd hack courtesy of Martin, we
have all the svn r# redirects working, and faster than before.

- FChE

Re: subversion status on gcc.gnu.org

[Frank Ch. Eigler via Gcc]

Hi -

> > > https://gcc.gnu.org/r2000
> > > maps to a search and you get thousands of hits for SVN: r2000**
> > 
> > The gcc git svn-rev alias handles that (and also handles release and other
> > branches) using approx.
> > git log --all --grep="From-SVN: r$rev\b" | head -n 1 | awk '{print $2}'
> > where $rev is 2000 in your case.

I'll look into fixing the forwarding regexp.

> Btw. what about statically generated database (files) which can be
> used for redirection?  I'm sending an example and I have a script
> that can generate any file content.

I don't think we will require something that elaborate.

- FChE

Re: mailman customization

[Frank Ch. Eigler via Gcc]

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.  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#.

- FChE

Re: subversion status on gcc.gnu.org

[Frank Ch. Eigler via Gcc]

Hi -

> [...]
> On a related note, contribute.html has a link to 
> https://gcc.gnu.org/viewcvs/gcc/trunk/contrib/check_GNU_style.sh?view=markup
> and gcc-4.8/changes.html has a linkto
> https://gcc.gnu.org/viewcvs/trunk/libgfortran/libgfortran.h?content-type=text%2Fplainview=co
> which are broken now.  

They could be rewritten into gitweb queries too:

https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=contrib/check_GNU_style.sh
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libgfortran/libgfortran.h

Care to try writing the necessary httpd mod_rewrite runes?

- FChE

Re: subversion status on gcc.gnu.org

[Frank Ch. Eigler via Gcc]

Hi -

> Thanks for working on this!!!  However, I still see at least one issue
> in the following bugzilla entry:
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94123#c4
> 
> The first two git style links work, but the last one which points
> to the SVN revision doesn't.  Is that a bug in the actual url that
> bugzilla added or can we handle these too?

We can/do handle the last one too.  httpd mod_rewrite is powerful.

- FChE

Re: Spam, bounces and gcc list removal

[Frank Ch. Eigler via Gcc]

Hi -

> > since the change to the new list management, there has been
> > an uptick of spam getting through. Spam is bounced by my ISP,
> > and this just resulted in a warning that there were too many
> > bounces and that I would get removed from the list unless I
> > confirmed it (which I then did).
> This has now happened a second time, and this question

For my reference, could you forward one of these spams & bounces to me?

> > So, a request: Could the overseers either install more effective
> > spam protection for the list as a whole (preferred)

Heh, if only it were that easy!  Spam filtering was and is distinct
from mailing list processing, and as you know it's a constant arms
race.  We're working hard to make the new installation of spamassassin
as discriminating as possible.  We're also working on the workflow to
clean the web archives of spam that got through.

> > or relax the limit on bounces?

OK, there are a couple of settings over at:
https://gcc.gnu.org/mailman/admin/gcc/bounce
that law and we can think about, but I'd like
to see the messages in question to figure out what happened.


- FChE

subversion status on gcc.gnu.org

[Frank Ch. Eigler via Gcc]

Hi -

Both svn: and ssh+svn: now work for your archeological needs.
Further, URLs such as

https://gcc.gnu.org/viewcvs?rev=279160=gcc=rev
https://gcc.gnu.org/r123456

are mapped to gitweb searches that try to locate the matching
From-SVN: rABCDEF commit.  This way, historical URLs from bugzilla
should work.

If you badly need something else subversionish, please let me know.

- FChE

Re: Not usable email content encoding

[Frank Ch. Eigler via Gcc]

Hi -

> 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.

- FChE

Re: Not usable email content encoding

[Frank Ch. Eigler via Gcc]

Hi, Jim -

> [gerrit etc.]

Good points.

> [...]  We need to think about setting up easier ways for people to
> submit patches, rather than trying to fix all of the MUAs and MTAs
> in the world.

Another related point.  We are comingling email as a communication
medium AND a commit transport medium.  For the former, as in patch
review / RFC, one may not require a form of the patch that is finally
committable to master, so the exact From: etc. may not matter.  For
the latter, attachments are more bullet-proof.

- FChE

Re: Not usable email content encoding

[Frank Ch. Eigler via Gcc]

Hi -

> > The From: header rewriting for DMARC participants is something sourceware
> > is doing now.
> 
> Out of curiousity, is this rewriting you are talking about the cause for a
> lot of mails showing up as "From: GCC List" rather than their real senders?
> This has become very annoying recently.

Yes, for emails from domains with declared interest in email
cleanliness, via DMARC records in DNS.  We have observed mail
-blocked- at third parties, even just days ago, when we failed to
sufficiently authenticate outgoing reflected emails.

AIUI, all this effort is driven by wanting to defeat not just spammers
but also real security problems like phishing enabled by forgery,
including specifically the From: header.

- FChE

Re: Not usable email content encoding

[Frank Ch. Eigler via Gcc]

Hi -

> [...]  You're talking about rewriting or adding headers (where the
> former is Real Bad, no matter what DMARC wants to impose), but the
> suggestion is based on not rewriting the body.  If the body
> (including attachtments) is rewritten any way then that simply is a
> bug. [...]

We're mixing two things.

The From: header rewriting for DMARC participants is something sourceware
is doing now.

The Content-Transfer-Encoding: change is done by intermediate MTA's
whose identity is unknown.  (I don't believe this behaviour is
forbidden by RFCs, but even if it were, we may have no way of fixing
the mystery MTA.)


- FChE

Re: Not usable email content encoding

[Frank Ch. Eigler via Gcc]

Hi -

> > The key here is to realize that the raw message is not what you get
> > back from the mailing list reflector, and also not the raw message
> > that was sent by the sender.  In this day of mta intermediaries,
> > proxies, reflectors, it may be time to revisit that suggestion.
> 
> But these largely are new problems.  It used to work flawlessly.

I understand that's frustrating.  But these workflows were counting on
literally unspecified behaviours not changing, or outright standards
violations continuing.

> Patch reencoding problems go back to the redhat.com changes last
> November (I understand the responsible vendor is working on a fix,
> but I'm not up-to-date on the current developments).

This one is a standards-compliant reencoding.  Even if mimecast (?)
stops doing it, we can't be sure nothing else will.

> Since the sourceware.org Mailman migration, the From: header is being
> rewritten, without any compelling reason.  I certainly do not do any
> DMARC checking here, so the rewriting does not benefit me.

It benefits you because more and more email services are rejecting or
interfering with mail that is not clean enough.  If you want to
receive mail reliably, or send and have confidence that it is
received, clean mail benefits you.


- FChE

Re: Not usable email content encoding

[Frank Ch. Eigler via Gcc]

Hi -

> > Are you trying to copy from the raw message representation?
> 
> Everyone trying to work with a patch (instead of just the email) always
> is working with the raw message.  Just  patch < mbox  or  git-am mbox
> for example.
> 
> https://gcc.gnu.org/contribute.html says
>   It is strongly discouraged to post patches as MIME parts of type
>   application/whatever, disposition attachment or encoded as base64 or
>   quoted-printable.
> 
> (which many people still do not follow, making reviewing their patches
> much harder than needed).

The key here is to realize that the raw message is not what you get
back from the mailing list reflector, and also not the raw message
that was sent by the sender.  In this day of mta intermediaries,
proxies, reflectors, it may be time to revisit that suggestion.

Attachments seem to survive unmolested better than mail email bodies,
for example.  And MUAs can undo some of the unexpected transformations
in the main body.

- FChE

Re: Not usable email content encoding

[Frank Ch. Eigler via Gcc]

Hi -

> I noticed some emails reaching gcc-patc...@gcc.gnu.org use the following 
> quoting:
> It's probably related to the following email tag:
> Content-Transfer-Encoding: quoted-printable

This is not something that the mailing list system does.  This
content-transfer-encoding comes from the original email (as evident in
the /var/lib/mailman/archives/private/gcc-patches.mbox/gcc-patches.mbox
file).

- FChE

Re: GCC bugzilla: REST API

[Frank Ch. Eigler via Gcc]

Hi -

> I'm working on a script that will catch the missing email into
> Bugzilla that are triggered by git commits mentioning a PR.
> For that I would need the enablement of REST API that was enabled
> in previous bugzilla instance.

I believe this should work now.  Thanks to Joseph Myers for
pointing out that we were missing some more perl modules.
Fought with koji & etc. awhile and now bugzilla's checksetup.pl
is happy all around.

- FChE

Re: GCC bugzilla: REST API

[Frank Ch. Eigler via Gcc]

Hi -

> I'm working on a script that will catch the missing email into
> Bugzilla that are triggered by git commits mentioning a PR.
> For that I would need the enablement of REST API that was enabled
> in previous bugzilla instance.

Just for clarity, which REST API was this?  Have a test URL we can
useto smoke-test?

- FChE

Re: text/x-* attachments strippe

[Frank Ch. Eigler]

Hi -

Thanks for the kind words.

> Could this have gone a bit smoother? Yes.  More collaborative? Maybe.

We tried: the plan to migrate to mailman was included by reference
from the systemwide announcement blast two weeks ago:
https://sourceware.org/sourceware-wiki/MigrationStatus/

We continue to welcome advice & help.

- FChE

Re: gcc-10-20200308 is now available

[Frank Ch. Eigler]

Hi -

> Is it expected that
> https://gcc.gnu.org/pub/gcc/snapshots/10-20200308/sha512.sum is not
> present?
> There is a sha512.sum file in previous snapshot dirs.

system & per-user cron job items have not been brought forward
en masse.  Copied a relevant one over now
(/sourceware/infra/bin/make-sha /var/ftp/pub)

- FChE

Re: gcc mailing list is not being archived

[Frank Ch. Eigler]

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.

- FChE

Re: GCC Bugzilla (and other) timeouts

[Frank Ch. Eigler]

Hi -

> > Bugzilla and httpd are very slow, but I haven't had any git timeouts.
> > If you're using anonymous access that gets throttled more aggressively
> > than authenticated access (using git+ssh:// for the protocol).

Yeah, we're aware of reduced performance lately.  Suspecting one disk
is on the fritz, which doesn't help.  The switchover to the new server
can't happen soon enough - next week or two.

- FChE

Re: GCC wwwdocs move to git done

[Frank Ch. Eigler]

Hi -

Thanks - good job with moving this to git!

> Note 1: someone with the right access needs to create the symlink 
> /sourceware/git/gcc-wwwdocs.git -> 
> /sourceware/projects/gcc-home/wwwdocs.git (and anything else needed for 
> anonymous git access to that repository).

Done.

- FChE

Re: GCC wwwdocs move to git done

[Frank Ch. Eigler]

Hi -

Thanks - good job with moving this to git!

> Note 1: someone with the right access needs to create the symlink 
> /sourceware/git/gcc-wwwdocs.git -> 
> /sourceware/projects/gcc-home/wwwdocs.git (and anything else needed for 
> anonymous git access to that repository).

Done.

- FChE

Re: ChangeLog's: do we have to?

[Frank Ch. Eigler]

siddhesh wrote:

> [...]  We had discussed making addition of ChangeLog entries into the
> commit message mandatory but the issue there is that commit logs
> cannot be (or more precisely, should not be) modified after they're
> pushed so errors in ChangeLog entries will remain.  [...]

In such a rare case, it would be possible to add a subsequent commit
that carries the corrected text, but no other changes (--allow-empty).
Or even revert the previous patch, then re-commit with a fixed text.
Watch out for "perfect is the enemy of the good" syndrome here (as in
the svn-git conversion).

- FChE

Re: So what's the status of the Git migration?

[Frank Ch. Eigler]

esr wrote:

> [...]
>> Another year; another release; and still no sign of progress on the git
>> migration.
> [...]
> The current issue - and, I think, the last major one - is that there are
> over 150 nid-branch deletes to be resolved.

Is there a mandate that this conversion be Perfect?

How harmful would it be to retain some ambiguity / imperfection in the
resulting git repo, considering that the svn repo can stick around
indefinitely as a historical reference?

- FChE

Re: Bugzilla timing out

[Frank Ch. Eigler]

Hi -

> Many copies of a 5 MB message have apparently been timing out in 
> sourceware's spam processing, resulting in sourceware repeatedly accepting 
> the message while the sender's mail server also times out (sooner) and 
> keeps resending it. [...]

Thanks for the pointer.  I tightened up some of the timeouts / parallelism
associated with spam filtering.

- FChE

Re: Bugzilla timing out

[Frank Ch. Eigler]

Hi -

> Thanks for looking into it.  I'm still (or again) seeing very
> poor responsiveness.  Right now, bringing up an existing bug
> takes an entire minute.

There has been quite a burst in activity on sourceware.org over the
last few hours.  Will look further into why, but quite a bit of it may
be anti-spam processing.

https://sourceware.org/grafana/index.html#/dashboard/file/default.json

- FChE

Re: Bugzilla timing out

[Frank Ch. Eigler]

Hi -

On Tue, Jan 23, 2018 at 11:26:42AM +0100, Richard Biener wrote:
> [...]
> > OK, we reworked some of the database routine maintenance workload,
> > e.g., a nightly cleanup pass that was quite likely excessive, and
> > will keep monitoring.
> 
> With all such administrative workloads keep in mind that "night" might
> be "day" in another timezone ;)

Sure, but there are only one or two of you ne'erdowells on the wrong
side of the planet. :-)

- FChE

Re: Bugzilla timing out

[Frank Ch. Eigler]

Hi -

> Problems are still occurring for me; Bugzilla gives me 504 Gateway
> Time-outs when I try to access it tonight...

OK, we reworked some of the database routine maintenance workload,
e.g., a nightly cleanup pass that was quite likely excessive, and
will keep monitoring.


- FChE

Re: Bugzilla timing out

[Frank Ch. Eigler]

msebor wrote:

> I'm having trouble bringing up bugs or updating them.  Has anyone else
> noticed Bugzilla (and/or other services running on gcc.gnu.org) being
> very slow or timing out?

One failed disk in the server has been replaced yesterday.  Please let
us know if problems persist or reoccur.

- FChE

Re: Call for volunteers: GCC Bugzilla account approval

[Frank Ch. Eigler]

David Edelsohn  writes:

> [...]
> Because of SPAM, the GCC Community had to disable the creation of new
> accounts.  We need a few dedicated, reliable individuals who can
> review account requests and manage the process of authorizing Bugzilla
> accounts.  [...]

It would to have y'all also figure out what "review" consists of: what
degree of vetting do you expect?  If it's nothing but "copy data into
web form, hit POST", then maybe this role isn't worth being filled by
a human being.

- FChE

Re: using C++ STL containers in GCC/gfortran source code

[Frank Ch. Eigler]

Pedro Alves  writes:

> [...]
> malloc will fail, new will throw bad_alloc, and GCC will abort and
> maybe generate a core dump, instead of gracefully printing
> something like:
>cc1: out of memory allocating  bytes ...
> and existing with error status.

Consider having the main() function catch bad_alloc etc. and print
prettier error messages than the builtin uncaught-exception aborter?

- FChE

Re: git server is stuck

[Frank Ch. Eigler]

The cron-based svn-to-git script running under bernie's account on
gcc.gnu.org is still stuck/spinning, even after a restart.  I am
planning to suspend it later tonight, until y'all can figure out what's
going on.

- FChE

Re: Who played with the GCC Bugzilla git repo?

[Frank Ch. Eigler]

Frédéric Buclin  writes:

> Someone played with the GCC Bugzilla git repo last week with no real reason:
> Author: root 
> Date:   Fri Oct 7 15:28:43 2016 +
> snap-data
> [...]

That was little old me, with the reason being to conserve local changes
with version control.

> Looks like the goal was to drop all CSS and JS files in data/assets/.

No, I believe there was some other sourceware-oriented customization in
there, but I forget the details.

> [...]  Moreover, this means that the GCC Bugzilla git repo is no
> longer in sync with the upstream Bugzilla git repo, because the one
> who played with git also committed my local changes (I didn't do it
> for a reason). I can no longer view my local changes, nor can I easily
> sync both repos with a fast-forward merge (I think). [...]

That's just a matter of tracking upstream bugzilla on one branch, and
the sourceware installation of bugzilla on another branch, and merging
from the former into the latter periodically.  I renamed "5.0" to
"5.0-sourceware", and recreated the "5.0" branch to assist this.

- FChE

Re: Repository for the conversion machinery

[Frank Ch. Eigler]

joseph wrote:

> Thanks, here are further authors map additions for new committers.
> [...]
> avieira = Andre Vieira 
> [...]

FWIW, I thought at one point the consensus was that the mailmap would
expand only to $use...@gcc.gnu.org rather than $userid@$organization,
esp. considering the case where there is no single $organization that
accurately covers the whole contribution timespan of the given $userid.

- FChE

Re: Repository for the conversion machinery

[Frank Ch. Eigler]

Jason Merrill  writes:

> [...]  gcc.gnu.org already refuses git connections fairly frequently
> due to overloading [...]

With the corresponding reduction in cpu load from svn users, plus the
ready adjustability of those xinetd thresholds, please don't let that
hold you back.

- FChE

Re: Deprecating basic asm in a function - What now?

[Frank Ch. Eigler]

jwakely.gcc wrote:

> [...] (When we switched Fedora to using GCC 6, with C++14 enabled by
> default, dozens and dozens of C++ packages failed to compile,
> because even in 2016 nobody had ever tried to compile them with
> C++11 features enabled.)

And one shouldn't blame those that choose to stick with CXXFLAGS=-std=c++98
instead of porting their code, which after all is working & stable.

- FChE

Re: gnu-gabi group

[Frank Ch. Eigler]

mark wrote:

> [...]
>> [...]
>> >> Having a local gnu-gabi group on sourceware.org would be better IMHO.
>> > +1
>> +1
>
> Great. I'll ask overseers to create a mailinglist. [...]

Done [1] [2].  If y'all need a wiki too, just ask.

[1] gnu-g...@sourceware.org
[2] https://sourceware.org/ml/gnu-gabi/

- FChE

Re: http access to ftp://gcc.gnu.org

[Frank Ch. Eigler]

Hi -

> > [...]  Please see http://gcc.gnu.org/ftp/ .
> Got 403:

Thanks, fixed.

- FChE

http access to ftp://gcc.gnu.org

[Frank Ch. Eigler]

Hi -

At the request of tbsaunders, we're experimenting with
provinding http[s] access to parts of the ftp://gcc.gnu.org/
contents.  Please see http://gcc.gnu.org/ftp/ .

- FChE

Re: Repository for the conversion machinery

[Frank Ch. Eigler]

Hi -

> [...]
> >- rewrite history - use some totally arbitrary, and quickly outdated,
> >internet identity

> I think this is main reason why @gnu.org or @gmail.com style addresses 
> are preferred over employer addresses when there's > 1 address on file.

That makes sense, but how many people are in cagney's shoes (with more
than one non-gcc.gnu.org email address in their commit history)?  It
sounds like they should all be canonicalized to u...@gcc.gnu.org.

- FChE

Re: Repository for the conversion machinery

[Frank Ch. Eigler]

>> cagney = Andrew Cagney 
> cag...@gnu.org?

Good point.  The email identities of people change over time; forcing
a single arbitrary one to label all contributions is at best imprecise
and at worse a miscrediting.  (This is one way in which the impersonal
use...@gcc.gnu.org aliases work better.)

- FChE

Re: svn timeouts

[Frank Ch. Eigler]

pmatos wrote:

 Am I the only one regularly getting svn timeouts lately?
 svn: E210002: Unable to connect to a repository at URL
 'svn://gcc.gnu.org/svn/gcc/trunk'
 svn: E210002: Network connection closed unexpectedly

Hard to be sure unless you can supply a timestamp so we can go log
hunting.  But each svn service acceptance is limited by load average
and concurrent # of clients per IP address; once started, they are
limited by cpu (1800s)  memory (5G) consumption.  Those look like
generous limits, so that may or may not be what you hit.

- FChE

Re: Offer of help with move to git

[Frank Ch. Eigler]

Joseph Myers jos...@codesourcery.com writes:

 [...]
 FWIW, Jason's own trial conversion with reposurgeon got up to at least 
 45GB memory consumption on a 32GB repository.

(The host sourceware.org box has 72GB.)

- FChE

Re: [website, changes] (was: Re: warning about const multidimensional array as function parameter)

[Frank Ch. Eigler]

Hi -

  thank you, I tried creating an account, but it said: Unknown action 
  newaccount.
 Frank, do you know what the problem might be?

Yes, this facility was temporarily disabled, as a load-shedding
measure.  I'll turn it back on for a few hours.


- FChE

ssl support for https://gcc.gnu.org/

[Frank Ch. Eigler]

Hi -

Thanks to help from Lisa Marie Maginnis li...@fsf.org, we now have a
valid ssl/tls certificate for gcc.gnu.org, so the web server now makes
https://gcc.gnu.org/* files available.  Please let me/overseers know if
you see any problems.

One complication is the use of literal link ref=http://gcc.gnu.org/FOO;...
type data inside many of the web pages, including the front page.  These
should be switched to something like  link ref=/FOO to make them work
both with http and https.

- FChE

Re: GCC Wiki, struggling to make a new user

[Frank Ch. Eigler]

Hi -

 I'm trying to create a new account for the GCC wiki using the
 account creation page at:
   http://gcc.gnu.org/wiki/HomePage?action=newaccount
 but things are not going well.
 
 I fill in the form and click create account. After thinking for a
 while the page returns a Gateway Error. [...]

This mirrors the symptoms of other sourceware-hosted moinmoin wikis
that had been overrun with spam users.  We cleaned a bunch of them off
of glibc the other day, basically removing all but the
trusted-editors, and things are much faster.  (Legitimate non-editor
users can create new users, or email to restore their purged info.)

Are y'all interested in the same treatment for the gcc wiki?


- FChE

Re: git mirror hasn't been updated for 8 hours

[Frank Ch. Eigler]

Hi -

There appears to have been a problem with bernie's cron-based
git-svn-fetch job, due to a corrupted (emptied) .git/svn/.cache/XXX.db
file.  With that file removed, the cron job is running again.  A
little bit extra logging was added to help pinpoint the cause next
time.

- FChE

Re: Report on the bounded pointers work

[Frank Ch. Eigler]

Yury Gribov y.gri...@samsung.com writes:

[...]
 [mudflap] never reached a point where interoperability across objects with
 and without mudflap instrumentation worked

 Could you add more details? E.g. I don't see how mudflap
 interoperability is different from AdressSanitizer which seems to be
 state of the art.

My sense is that asan and mudflap are comparable with respect to
support of interoperation between instrumented and uninstrumented
code.  The trick is how to handle pointers arriving from the latter.
libmudflap handled this issue in two ways: by attempting to intercept
all heap allocations from libraries (at the glibc/dlsym level), and by
heuristics for recognizing addresses that might have come from
unintercepted static/auto allocations.  The former is tricky and was
an uphill battle trying to catch everything, so in practice heuristics
were almost always necessary.

(There are of course many differences.  They have different tradeoffs
as to speed versus memory-consumption - asan is hard-coded in the
opposite direction than libmudflap's (configurable) default.  asan's
multi-threading support may be superior.  mudflap's tuning/features
were not completed.  asan sports more recent developers.)

- FChE

Re: Warning about __DATE__ and __TIME__

[Frank Ch. Eigler]

Gerald Pfeifer ger...@pfeifer.com writes:

 To make it easier to reproduce builds of software and entire GNU/Linux 
 distributions, RMS had the idea of adding a warning to GCC that warns 
 about the use of __DATE__ and __TIME__. [...]

How about instead adding a --time=X option to gcc (cpp?) instead,
so that someone interested in reproducing a build can rerun gcc with
the original --time value?  (gcc -grecord-gcc-switches could emit
the then-current timestamp to enable this.)

- FChE

Re: Vandalised wiki page

[Frank Ch. Eigler]

Hi -

  Looking at http://gcc.gnu.org/wiki/RecentChanges shows that the GCC wiki
  is being spammed a lot. Somebody should employ some kind of spam protection.

Several other sourceware-hosted moin wikis have adopted a group-ACL-based
protection, which has eliminated the problem.  This involves maintaining
a special wiki page that lists approved editors (and is editable by those
editors).  If you're interested in trying this, please send me an initial
list of editor WikiNames.

- FChE

Re: Vandalised wiki page

[Frank Ch. Eigler]

Hi -

On Fri, Aug 23, 2013 at 04:06:22PM +0100, Jonathan Wakely wrote:
 [...]
 (Assuming we want to go down the ACL route.)

Done! :-)

  Is there an easy way to revert a spam change to a page? I don't see one.
 Doh, found it in the more actions dropdown.

(It's only accessible there to admin moin users.)

- FChE

Re: Could we start accepting rich-text postings on the gcc lists?

[Frank Ch. Eigler]

Hi -

On Sat, Nov 24, 2012 at 12:58:33PM -0500, Daniel Berlin wrote:
 [...]
 I'd love to see data on this.  As others have pointed out, almost
 every other open source project accepts html email. [...]
 Do you have reason to believe our existing spam detection solution
 will start to fail massively when presented with html email? [...]

Yes.  I run a similar spamassassin setup at home as sourceware's, and
it routinely lets through spam that is disguised in HTML.  That is
after all trivial to do - font size=1 color=white or somesuch gunk.
Annoyingly, the spam's hidden bayes-countering filler goo shows up in
its full html-to-text glory in a text-based MUA.

 After all, if most of the HTML email is spam, something being HTML
 email is a great signal for it.

Dunno about most, but an uncomfortable amount is right.


 [...]
 Note that *we* are currently rejecting multipart/alternative if it
 contains text/html, even if it contains text/plain.
 This is fairly obnoxious.

See above.  Spam filtering on HTML bodies is not very effective,
unless one's a gmail.  There is no mechanical way to ensure that the
multipart alternative text/plain is equivalent -- and if it were,
then it could just have been sent as is in the first place (were it
not for MUA intransigence).


- FChE

Re: GCC 4.7.2: Mudflap linker errors

[Frank Ch. Eigler]

bd satish bdsat...@gmail.com writes:

 [...]
 The following piece of code, gives undefined references to
 __real_malloc, __real_free, etc.:
 Compiled with:
 g++ -fmudflap references.cc -lmudflap

 /lib64/libmudflap.a(mf-runtime.o): In function `__mfu_check':
 ../libmudflap/mf-runtime.c:912: undefined reference to `__real_malloc'
 [...]

According to libmudflap/mf-impl.h, since you're using ordinary
archives rather than shared libraries (-fPIC) these __real_FOO
functions are expected to be provided by the linker:

   (1) The static method involves a list of -wrap=foo flags being passed to
   the linker, which then links references to foo to the symbol
   __wrap_foo, and links references to __real_foo to the symbol foo.
   When compiled without -DPIC, libmudflap.a contains such __wrap_foo
   functions which delegate to __real_foo functions in libc to get their
   work done.

So, something appears wrong with this wrapping mechanism in your case.
Can you rerun g++ with -v to see how the linker is invoked?  Perhaps
there is something missing for the C++ static-linking case.


- FChE

Re: GCC stack backtraces

[Frank Ch. Eigler]

Basile Starynkevitch bas...@starynkevitch.net writes:

 [...]  If Ian's DWARF reader is simple enough (since suited for a
 single purpose), it might be helpful to avoid yet another external
 library dependency for GCC. [...]

OTOH, DWARF is not a stationary target, so one should consider the
benefits of offloading forseeable future maintenance too to specialist
F/OSS projects.

- FChE

Re: New GCC takes 19x as long to compile my program (compared to old GCC), plus void** patch suggestion

[Frank Ch. Eigler]

Elmar Krieger el...@cmbi.ru.nl writes:

 [...]  I really didn't expect that RedHat and Google both mess up
 GCC with their modifications, so I'll report it to them instead ;-)

That's not a fair characterization of the features' costs/benefits.

- FChE

Re: The Extension to ELF

[Frank Ch. Eigler]

Ian Lance Taylor i...@google.com writes:

 [...]
 ELF is designed to permit fast program loading at runtime, and to
 permit fast linking.  Changing symbol and relocation values to take
 general expressions works against that goal.
 [...]

It may interest you to know that, for an older Cygnus project (mep),
we implemented a facility called computed/complex relocations, as an
ELF extension.  This is a way of encoding general symbol/arithmetic
expressions to be evaluated at link time and substituted into the
binary output.  (It may be similar to the vms-alpha ETIR facility.)

This has been merged into gnu binutils some time ago, though is not
widely known, and only used by a single cgen-based gas port.  See the
OBJ_COMPLEX_RELC conditionals in gas/*, the BSF_*RELC/STT_RELC logic
in bfd/*.

- FChE

Re: The Extension to ELF

[Frank Ch. Eigler]

Hi -

On Wed, Aug 08, 2012 at 06:23:52AM -0700, Ian Lance Taylor wrote:
 [...]
  This has been merged into gnu binutils some time ago, though is not
  widely known, and only used by a single cgen-based gas port.  See the
  OBJ_COMPLEX_RELC conditionals in gas/*, the BSF_*RELC/STT_RELC logic
  in bfd/*.
 
 Thanks, I was trying to remember that.
 
 It is perhaps also worth noting that the IEEE-695 object file format
 supports arbitrary expressions in a number of different ways,
 including for relocation calculations.  The format is not widely used
 today, for more or less that reason.

It is quite different from ELF for sure.  One certainly wouldn't want
to use such a complex-relocation facility unnecessarily - when the
hard-coded normal ones will do the job.  But if you need something
more, and are willing to pay the longer linking time (than what?),
it's worth considering.


- FChE

Re: The Extension to ELF

[Frank Ch. Eigler]

Fumiaki Isoya iso...@gmail.com writes:

 It may interest you to know that, for an older Cygnus project (mep),
 we implemented a facility called computed/complex relocations, as an
 ELF extension.  This is a way of encoding general symbol/arithmetic
 expressions to be evaluated at link time and substituted into the
 binary output.  [...]

 Did you write some compiler language to evaluate that feature?

No.  Software for this particular was mainly coded in assembly, and
the assembly language / instruction set were itself very
configurable(!), so relocations had to be general.  If this capability
is useful for a higher-level language, a binding would have to be
created, and the arch gas/binutils would have to start generating the
info.

 How is the idea of adopting it as the standard format of GNU Hurd?

I have no opinion on this.  Note though that these complex relocations
are encoded within a standard ELF file (merely using separate
relocation-type and symbol-type codes).  There is no need for an
OS/kernel to support it, since all the action takes place within the
assembler and linker.

- FChE

Re: Function parameter debug info at -O0

[Frank Ch. Eigler]

Senthil Kumar Selvaraj senthil_kumar.selva...@atmel.com writes:

 [...]
 The following program, when compiled with -O0 -g3 (x86_64 target, but
 doesn't seem to matter), shows wrong values for p (function parameter)
 when debugging. [...]

This sounds like http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51358.

- FChE