[wwwdocs] tweak for sourceware account request alias
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,
RFC PATCH: contrib/test_summary mode for submitting testsuite results to bunsen
Hi -
The gcc-testresults mailing list is a well-established place to plop
snippets of testsuite results. It's an okay way to archive and
distribute overall counts, but it's not machine readable, and it's way
incomplete (lacks .log content, a lot of metadata, barely meaningfully
searchable) for trying to understand why something failed.
A few years ago, our team @ RH built the bunsen system to serve as a
structured repository for dejagnu (and other) testsuite types. [1] An
instance running here [2] has been collecting data from the sourceware
buildbots and individuals (hi iains!) for years. It convers all the
toolchain pieces and then some, including gcc. It features machine
readable indexing, cross-referenced test case browsing, regression
analysis, old data aging, and many other capabilities. (It even has a
piece that extracts data from the gcc-testresults@ mailing list
archives, but there's too little there to bother. [4])
This patch attempts to make it easy for gcc developers who use the
contrib/test_summary script today to opt in to contributing their
results to a bunsen server (defaulting to the sourceware one [2]).
The prerequites are:
- git
- the bunsen t-upload-git-push script [3], feel free to grab just that
into your $PATH
- sourceware account with bunsendb commit access [ask on
admin-reque...@sourceware.org]
- pretty much nothing else - specifically, gcc commit access is not
necessary!
Here's how it looks when it's run after a random small gcc build/test:
.../contrib/test_summary -h
[...]
-b: instead of emailing, push test logs into a bunsen git repo
-bg REPO: specify the bunsen git repo to override default
-bt TAG: specify the bunsen git commit tag to override default
.../contrib/test_summary -b | env PATH=$BUNSEN/INST/bin:$PATH sh -x
+ echo master
+ echo basepoints/gcc-15-3524-ga523c2ba5862
+ echo a523c2ba58621c3630a1cd890d6db82879f92c90
+ echo git://gcc.gnu.org/git/gcc.git
+ find . -name '*.log' -o -name '*.sum' -o -name '.bunsen.*'
+ t-upload-git-push ssh://sourceware.org/git/bunsendb.git/
fche/gcc/x86_64-20240913-1516
ec57fb8ee928e341d1f0d1b09c1d571fb590bd2b refs/tags/fche/gcc/x86_64-20240913-1516
And here's what that dataset looks like on bunsen a few minutes later:
https://builder.sourceware.org/testrun/ec57fb8ee928e341d1f0d1b09c1d571fb590bd2b
If this is of any interest, I'd be glad to hack on this script further
to make it acceptable.
[1] https://sourceware.org/bunsen/
[2] https://builder.sourceware.org/testruns/
[3] https://sourceware.org/git/?p=bunsen.git;a=blob;f=bin/t-upload-git-push
[4]
https://sourceware.org/git/?p=bunsen.git;a=blob;f=bin/t-sourceware-mails-import
diff --git a/contrib/ChangeLog b/contrib/ChangeLog
index 9b36caf02bb1..def8dd8a8a73 100644
--- a/contrib/ChangeLog
+++ b/contrib/ChangeLog
@@ -1,3 +1,9 @@
+2024-09-13 Frank Ch. Eigler
+
+ * test_summary: Add -b (bunsen) mode to report all test results
+ into a https://sourceware.org/bunsen/ system instead of emailing
+ extracts.
+
2024-08-01 Thomas Schwinge
* gcc_update (files_and_dependencies): Update for
diff --git a/contrib/test_summary b/contrib/test_summary
index 5760b053ec27..867ada4d6b81 100755
--- a/contrib/test_summary
+++ b/contrib/test_summary
@@ -39,6 +39,9 @@ if test x"$1" = "x-h"; then
should be selected from the log files.
-f: force reports to be mailed; if omitted, only reports that differ
from the sent.* version are sent.
+ -b: instead of emailing, push test logs into a bunsen git repo
+ -bg REPO: specify the bunsen git repo to override default
+ -bt TAG: specify the bunsen git commit tag to override default
_EOF
exit 0
fi
@@ -57,6 +60,9 @@ fi
: ${filesuffix=}; export filesuffix
: ${move=true}; export move
: ${forcemail=false}; export forcemail
+: ${bunsen=false};
+: ${bunsengit=ssh://sourceware.org/git/bunsendb.git/};
+: ${bunsentag=`whoami`/gcc/`uname -m`-`date +%Y%m%d-%H%M`};
while true; do
case "$1" in
-o) filesuffix=.sent; move=false; : ${mailto=nobody}; shift;;
@@ -64,10 +70,30 @@ while true; do
-p) prepend_logs=${prepend_logs+"$prepend_logs "}"$2"; shift 2;;
-i) append_logs=${append_logs+"$append_logs "}"$2"; shift 2;;
-m) mailto=$2; forcemail=true; shift 2;;
+ -b) bunsen=true; shift;;
+ -bg) bunsengit=$2; shift 2;;
+ -bt) bunsentag=$2; shift 2;;
-f) unset mailto; forcemail=true; shift;;
*) break;;
esac
done
+if [ "x$bunsen" = "xtrue" ]; then
+gitsrcdir=`dirname "$0"` # this script, contrib/test_summary
+gitsrcdir=`dirname "$gitsrcdir"` # and the parent directory
+if [ -d "$gitsrcdir/.git" ]; then # is this a git-hosted source tree?
+# gather basic build metadata for sourceware-buildbot-style .bunsen
data
+gitbranch=`cd "$
Re: GCC wwwdocs move to git done
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: [PATCH] PR c/53702: Fix -Wunused-local-typedefs with nested functions
Hi - > This is OK. You should have write-after-approval access. Overseers, > please add user meadori to group gcc. Done. - FChE
Re: Unreviewed build/libgcc, mudflap patches
Hi - On Mon, Jun 27, 2011 at 01:32:30PM +0200, Rainer Orth wrote: > [...] > Support libmudflap on Solaris (PR libmudflap/38738) > http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01446.html Looks good to me, thanks for taking a look at the area. - FChE
Re: Unreviewed build/libgcc, mudflap patches
Hi - > >> http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01446.html > > Looks good to me, thanks for taking a look at the area. > > Could you also comment on the open questions in the submission so > mudflap support on Solaris can be improved further? Sure. Transcribing: > One generic issue came up with the port: enabling or disabling > libmudflap depends on a factor (linker support for --wrap/-z wrap) > that is best checked dynamically, thus doesn't really seem to belong > at the toplevel. Is there any precedent for performing such a test > in the target library and enabling or disabling depending on the > outcome? [...] I don't know. > It seems the failures fall into only a few categories. It's > probably best to analyse and fix those before checking in the patch. > Where should we continue discussing the failures? Here or rather in > the PR? Separate PRs would be best. - FChE
Re: Improve Solaris mudflap support (PR libmudflap/49550)
Hi, Rainer - > > It addresses a couple of testsuite failures: > > [...] > > where the registration of __iob has been done automatically by the > > compiler. I avoid this problem by not registering stdin, stdout, and > > stderr separately on Solaris. OK. > > * Some tests were failing while calling unregister in munmap. It turned > > out that there had been no corresponding mmap registration before. > > This occurs because Solaris has mmap64 for largefile-aware programs > > instead. Fixed by wrapping mmap64, too. What I don't know is if > > mmap64 needs to be added to MFWRAP_SPEC in gcc.c? I believe so. > > If so, I'd rather do it by adding some MFWRAP_OS_SPEC to avoid > > having to duplicate the whole spec in the Solaris config > > headers. Why would solaris have to duplicate MFWRAP_SPEC if mmap64 is added to the default gcc.c one? > > * As noted in the last patch, the getmntent signature differs in > > Solaris. This patch implements a wrapper for the Solaris version. OK. > > * libmudflap.cth/pass37-frag.c would fail like this: > > Investigating with -trace-calls reveals that all registrations and > > unregistrations of errno are for the same address, which is wrong for > > multithreaded programs which access errno via an accessor function. > > To enable that, needs to be included with _REENTRANT > > defined. It turned out that it suffices to do this in mf-hooks3.c. OK. > > * libmudflap.c/heap-scalestress.c always timed out on my SPARC test > > system: on a 1.2 GHz UltraSPARC-T2, it takes > > > > real8:47.06 > > user 43.12 > > sys 8:03.77 > > > > which is way over the limit. On my laptop (1.6 GHz Core i7), it takes > > > > real 37.35 > > user 5.06 > > sys 32.23 > > > > I've divided SCALE by 10 to account for this. OK; I'm surprised by the order-of-magnitude performance difference between the machines though. > > * I've replaced all the __FreeBSD__ && ... tests in > > libmudflap.c/pass-stratcliff.c with appropriate autoconf macros, and > > also define MIN which can be missing. OK. > > * libmudflap.c/pass47-frag.c originally failed like this: > > With this patch (and the next), I get almost clean testsuite results on > > sparc-sun-solaris2.11 (both multilibs): OK. - FChE
Re: Improve Solaris mudflap support (PR libmudflap/49550)
Hi, Rainer - > >> > If so, I'd rather do it by adding some MFWRAP_OS_SPEC to avoid > >> > having to duplicate the whole spec in the Solaris config > >> > headers. > > > > Why would solaris have to duplicate MFWRAP_SPEC if mmap64 is added to > > the default gcc.c one? > > I assumed that you wanted to keep the default generic, and meant to > separate target specific additions from the generic part. I don't have a strong opinion on this, but if you add mmap64 to the default, there need be no target-specific additions for solaris, right? So we can delay the decision to another day. > [...] > I could either commit the current version with the MFWRAP_SPEC addition > and work from there, or wait until those failures are understood and > fixed, too. Committing now would be fine, assuming no regressions on a primary platform. - FChE
Re: More mudflap fixes for Solaris < 11
Hi, Rainer - > When testing libmudflap on Solaris 8, 9, and 10 with GNU ld, I found a > couple of testsuite failures: > [...] > Ok for mainline? Yes, thank you! - FChE
Re: Define [CD]TORS_SECTION_ASM_OP on Solaris/x86 with Sun ld
Hi, Rainer - On Mon, Jul 11, 2011 at 06:34:27PM +0200, Rainer Orth wrote: > [...] > On the other hand, there's the question why tree-mudflap.c tries to > create a constructor with a non-default priority on a platform with > SUPPORTS_INIT_PRIORITY == 0 or at all [...] For the "at all" part, I believe the intent was to make it more likely that mudflap-tracked literals be tracked early enough so that other constructors would find them already available for checking. - FChE
ping Re: RFC PATCH: contrib/test_summary mode for submitting testsuite results to bunsen
Hi -
(ping)
commit 23c3100e992029994f33eb4a1465570b476c1df4 (HEAD -> master)
Author: Frank Ch. Eigler
Date: Mon Sep 23 18:03:31 2024 -0400
contrib/test_summary: Add bunsen uploading mode
This makes it easy for someone to push gcc dejagnu/autoconf test
results to a bunsen [1] system, as an alternative or supplement to
sending a subset by email to . Bunsen
allows minimum-infrastructure archiving, indexing, and analysis of
test results.
% contrib/test_summary -b
echo 'master' > .bunsen.source.gitbranch &&
echo 'basepoints/gcc-15-3524-ga523c2ba5862' > .bunsen.source.gitdescribe &&
echo 'a523c2ba58621c3630a1cd890d6db82879f92c90' > .bunsen.source.gitname &&
echo 'git://gcc.gnu.org/git/gcc.git' > .bunsen.source.gitrepo &&
(find . -name '*.log' -o -name '*.sum' -o -name '.bunsen.*' |
t-upload-git-sh 'ssh://sourceware.org/git/bunsendb.git/'
'fche/gcc/x86_64-pc-linux-gnu/x86_6pc-linux-gnu/20240923-1817')
Commit access to the sourceware bunsen database [2] is available on
request [3], so uploads automatically show up in the web interface
[4], but one may also operate a private copy of the system to use it
entirely locally. A unique tag name is generated from one's userid,
the gcc host/target triplets, and a timestamp, but these defaults may
be overridden with contrib/test_summary options. The git
commit/tag/push machinery is wrapped into a tiny "t-upload-git-push"
shell script, which may be downloaded from bunsen.git into your $PATH.
[1] https://sourceware.org/bunsen/
[2] https://sourceware.org/git/bunsendb.git
[3]
[4] https://builder.sourceware.org/testruns/
https://inbox.sourceware.org/bunsen/20240913201848.gc25...@redhat.com/
ChangeLog:
* Makefile.tpl, Makefile.in: Add bunsen-report.log target.
contrib/ChangeLog:
* test_summary: Add -b (bunsen) mode to report all test results
into a https://sourceware.org/bunsen/-like system instead of
emailing extracts.
Signed-Off-By: Frank Ch. Eigler
diff --git a/Makefile.in b/Makefile.in
index 966d60454960..8c352f7a2956 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -2852,6 +2852,11 @@ mail-report-with-warnings.log: warning.log
chmod +x $@
echo If you really want to send e-mail, run ./$@ now
+bunsen-report.log:
+ $(srcdir)/contrib/test_summary -b >$@
+ chmod +x $@
+ echo If you really want to send to bunsen, run ./$@ now
+
# Local Vim config
$(srcdir)/.local.vimrc:
diff --git a/Makefile.tpl b/Makefile.tpl
index da38dca697ad..9816fcd6f5b2 100644
--- a/Makefile.tpl
+++ b/Makefile.tpl
@@ -1034,6 +1034,11 @@ mail-report-with-warnings.log: warning.log
chmod +x $@
echo If you really want to send e-mail, run ./$@ now
+bunsen-report.log:
+ $(srcdir)/contrib/test_summary -b >$@
+ chmod +x $@
+ echo If you really want to send to bunsen, run ./$@ now
+
# Local Vim config
$(srcdir)/.local.vimrc:
diff --git a/contrib/test_summary b/contrib/test_summary
index 5760b053ec27..b4a9c92b753e 100755
--- a/contrib/test_summary
+++ b/contrib/test_summary
@@ -39,6 +39,10 @@ if test x"$1" = "x-h"; then
should be selected from the log files.
-f: force reports to be mailed; if omitted, only reports that differ
from the sent.* version are sent.
+ -b: instead of emailing, push test logs into a bunsen git repo
+ -bg REPO: specify the bunsen git repo to override default
+ -bi TAG1: specify the bunsen tag prefix (user name)
+ -bt TAG2: specify the bunsen tag suffix (build name)
_EOF
exit 0
fi
@@ -57,6 +61,10 @@ fi
: ${filesuffix=}; export filesuffix
: ${move=true}; export move
: ${forcemail=false}; export forcemail
+: ${bunsen=false};
+: ${bunsengit=ssh://sourceware.org/git/bunsendb.git/};
+: ${bunsentag1=`whoami`};
+: ${bunsentag2=gcc/`grep ^host= config.log | tr -d "'" | cut -f2 -d=`/`grep
^tget= config.log | tr -d "'" | cut -f2 -d=`/`date +%Y%m%d-%H%M`};
while true; do
case "$1" in
-o) filesuffix=.sent; move=false; : ${mailto=nobody}; shift;;
@@ -64,10 +72,31 @@ while true; do
-p) prepend_logs=${prepend_logs+"$prepend_logs "}"$2"; shift 2;;
-i) append_logs=${append_logs+"$append_logs "}"$2"; shift 2;;
-m) mailto=$2; forcemail=true; shift 2;;
+ -b) bunsen=true; shift;;
+ -bg) bunsengit=$2; shift 2;;
+ -bi) bunsentag1=$2; shift 2;;
+ -bt) bunsentag2=$2; shift 2;;
-f) unset mailto; forcemail=true; shift;;
*) break;;
esac
done
+if [ "x$bunsen" = "xtrue" ]; then
+gitsrcdir=`dirname "$0"` # this script, contrib/test_summary
Re: RFC PATCH: contrib/test_summary mode for submitting testsuite results to bunsen
Hi - > [...] > I pretty much only use `contrib/test_summary` via the > `mail-report.log` target in the top-level Makefile; maybe add a > `bunsen` target to the top-level Makefile, too, to simplify invoking > it? Something like this: ? diff --git a/Makefile.in b/Makefile.in index 966d60454960..41651e7592d2 100644 --- a/Makefile.in +++ b/Makefile.in @@ -2852,6 +2852,14 @@ mail-report-with-warnings.log: warning.log chmod +x $@ echo If you really want to send e-mail, run ./$@ now +bunsen-report.log: + if test x'$(BOOT_CFLAGS)' != x''; then \ + BOOT_CFLAGS='$(BOOT_CFLAGS)'; export BOOT_CFLAGS; \ + fi; \ + $(srcdir)/contrib/test_summary -b >$@ + chmod +x $@ + echo If you really want to send to bunsen, run ./$@ now + # Local Vim config $(srcdir)/.local.vimrc: diff --git a/Makefile.tpl b/Makefile.tpl index da38dca697ad..e2c3f6bf6ca5 100644 --- a/Makefile.tpl +++ b/Makefile.tpl @@ -1034,6 +1034,14 @@ mail-report-with-warnings.log: warning.log chmod +x $@ echo If you really want to send e-mail, run ./$@ now +bunsen-report.log: + if test x'$(BOOT_CFLAGS)' != x''; then \ + BOOT_CFLAGS='$(BOOT_CFLAGS)'; export BOOT_CFLAGS; \ + fi; \ + $(srcdir)/contrib/test_summary -b >$@ + chmod +x $@ + echo If you really want to send to bunsen, run ./$@ now + # Local Vim config $(srcdir)/.local.vimrc:
Re: RFC PATCH: contrib/test_summary mode for submitting testsuite results to bunsen
Hi, HP -
> I'd love for (something like) gcc-testresults@ to be usefully
> searchable (it can be done but... lacks), so please allow me:
Certainly!
> > +: ${bunsengit=ssh://sourceware.org/git/bunsendb.git/};
> > +: ${bunsentag=`whoami`/gcc/`uname -m`-`date +%Y%m%d-%H%M`};
>
> That uname -m looks like it's an assumption that the report is
> for a 1) native build that is 2) the same machine as where the
> git push should happen and 3) all run the same OS. Also, my
> local account-name may be completely different than what's
> needed in the tag. Looks like there's a side-question for
> account names for the bunsendb when you don't have a sourceware
> account (are rules needed)? Anyway, please parametrize. [...]
OK, the shell script is parametrized more.
wdyt about this version?
commit 23c3100e992029994f33eb4a1465570b476c1df4 (HEAD -> master)
Author: Frank Ch. Eigler
Date: Mon Sep 23 18:03:31 2024 -0400
contrib/test_summary: Add bunsen uploading mode
This makes it easy for someone to push gcc dejagnu/autoconf test
results to a bunsen [1] system, as an alternative or supplement to
sending a subset by email to . Bunsen
allows minimum-infrastructure archiving, indexing, and analysis of
test results.
% contrib/test_summary -b
echo 'master' > .bunsen.source.gitbranch &&
echo 'basepoints/gcc-15-3524-ga523c2ba5862' > .bunsen.source.gitdescribe &&
echo 'a523c2ba58621c3630a1cd890d6db82879f92c90' > .bunsen.source.gitname &&
echo 'git://gcc.gnu.org/git/gcc.git' > .bunsen.source.gitrepo &&
(find . -name '*.log' -o -name '*.sum' -o -name '.bunsen.*' |
t-upload-git-push 'ssh://sourceware.org/git/bunsendb.git/'
'fche/gcc/x86_64-pc-linux-gnu/x86_64-pc-linux-gnu/20240923-1817')
Commit access to the sourceware bunsen database [2] is available on
request [3], so uploads automatically show up in the web interface
[4], but one may also operate a private copy of the system to use it
entirely locally. A unique tag name is generated from one's userid,
the gcc host/target triplets, and a timestamp, but these defaults may
be overridden with contrib/test_summary options. The git
commit/tag/push machinery is wrapped into a tiny "t-upload-git-push"
shell script, which may be downloaded from bunsen.git into your $PATH.
[1] https://sourceware.org/bunsen/
[2] https://sourceware.org/git/bunsendb.git
[3]
[4] https://builder.sourceware.org/testruns/
https://inbox.sourceware.org/bunsen/20240913201848.gc25...@redhat.com/
ChangeLog:
* Makefile.tpl, Makefile.in: Add bunsen-report.log target.
contrib/ChangeLog:
* test_summary: Add -b (bunsen) mode to report all test results
into a https://sourceware.org/bunsen/-like system instead of
emailing extracts.
Signed-Off-By: Frank Ch. Eigler
diff --git a/Makefile.in b/Makefile.in
index 966d60454960..8c352f7a2956 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -2852,6 +2852,11 @@ mail-report-with-warnings.log: warning.log
chmod +x $@
echo If you really want to send e-mail, run ./$@ now
+bunsen-report.log:
+ $(srcdir)/contrib/test_summary -b >$@
+ chmod +x $@
+ echo If you really want to send to bunsen, run ./$@ now
+
# Local Vim config
$(srcdir)/.local.vimrc:
diff --git a/Makefile.tpl b/Makefile.tpl
index da38dca697ad..9816fcd6f5b2 100644
--- a/Makefile.tpl
+++ b/Makefile.tpl
@@ -1034,6 +1034,11 @@ mail-report-with-warnings.log: warning.log
chmod +x $@
echo If you really want to send e-mail, run ./$@ now
+bunsen-report.log:
+ $(srcdir)/contrib/test_summary -b >$@
+ chmod +x $@
+ echo If you really want to send to bunsen, run ./$@ now
+
# Local Vim config
$(srcdir)/.local.vimrc:
diff --git a/contrib/test_summary b/contrib/test_summary
index 5760b053ec27..b4a9c92b753e 100755
--- a/contrib/test_summary
+++ b/contrib/test_summary
@@ -39,6 +39,10 @@ if test x"$1" = "x-h"; then
should be selected from the log files.
-f: force reports to be mailed; if omitted, only reports that differ
from the sent.* version are sent.
+ -b: instead of emailing, push test logs into a bunsen git repo
+ -bg REPO: specify the bunsen git repo to override default
+ -bi TAG1: specify the bunsen tag prefix (user name)
+ -bt TAG2: specify the bunsen tag suffix (build name)
_EOF
exit 0
fi
@@ -57,6 +61,10 @@ fi
: ${filesuffix=}; export filesuffix
: ${move=true}; export move
: ${forcemail=false}; export forcemail
+: ${bunsen=false};
+: ${bunsengit=ssh://sourceware.org/git/bunsendb.git/};
+: ${bunsentag1=`whoami`};
+: ${bunsentag2=gcc/`grep ^host= config.log | tr -
Re: RFC PATCH: contrib/test_summary mode for submitting testsuite results to bunsen
Hi - > Regarding functionality, perfect enough AFAICT. I was going to > make a nitpick comment about comments with full sentences and > all that GNU...but better be consistent with the rest of the > file. Thanks! I don't mind addressing even nitpicks, while awaiting word from someone who can approve a push to the contrib/ dir. - FChE
Re: [PATCH] contrib: use sphinx-build from a venv
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
Re: [PATCH] contrib: use sphinx-build from a venv
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: Rust frontend patches v2
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
