Re: subversion status on gcc.gnu.org
On 4/2/20 2:26 PM, Jakub Jelinek via Gcc wrote:
On Thu, Apr 02, 2020 at 02:19:10PM +0200, Georg-Johann Lay wrote:
Am 20.03.20 um 18:37 schrieb 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&root=gcc&view=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.
This does not work as expected. For example,
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.
Jakub
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.
Martin
svn-to-git-mapping.tar.bz2
Description: application/bzip
Re: subversion status on gcc.gnu.org
On Fri, Apr 03, 2020 at 10:38:17AM +0200, Martin Liška wrote:
> > 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.
> >
> > Jakub
> >
>
> 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.
That can work too, but do we want a directory with 280156 files? One way is
to split the number into halves and have files like whatever/280/151 (and
deal specially with the revisions < 1000 where it would use whatever/0/123 ).
Or it can be a database query.
Jakub
Re: subversion status on gcc.gnu.org
On 4/3/20 10:54 AM, Jakub Jelinek wrote:
On Fri, Apr 03, 2020 at 10:38:17AM +0200, Martin Liška wrote:
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.
Jakub
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.
That can work too, but do we want a directory with 280156 files?
It's not ideal :) Maybe a modern linux filesystem will not suffer so much?
Oversees people can tell what they want.
One way is
to split the number into halves and have files like whatever/280/151 (and
deal specially with the revisions < 1000 where it would use whatever/0/123 ).
That would be possible.
Or it can be a database query.
I can imagine a simple sqlite file that can be queried.
Basically all is possible.
Martin
Jakub
Re: subversion status on gcc.gnu.org
On 4/3/20 11:23 AM, Martin Liška wrote:
On 4/3/20 10:54 AM, Jakub Jelinek wrote:
On Fri, Apr 03, 2020 at 10:38:17AM +0200, Martin Liška wrote:
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.
Jakub
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.
That can work too, but do we want a directory with 280156 files?
It's not ideal :) Maybe a modern linux filesystem will not suffer so much?
Oversees people can tell what they want.
One way is
to split the number into halves and have files like whatever/280/151 (and
deal specially with the revisions < 1000 where it would use whatever/0/123 ).
That would be possible.
Or it can be a database query.
I can imagine a simple sqlite file that can be queried.
Basically all is possible.
Martin
Jakub
I've got it, we want to use:
http://httpd.apache.org/docs/trunk/rewrite/rewritemap.html#dbm
which allows using a map file with additional index. There's svn-to-git.txt
file:
https://drive.google.com/file/d/1xZ7TwvqcV6zErup920OLhb09tePgSJHQ/view?usp=sharing
that should be transformed by:
$ httxt2dbm -i svn-to-git.txt -o svn-to-git.map
Martin
Re: text/x-* attachments stripped (was: Re: gcc ML archive: text/x-patch attachments no longer shown inline (was:Re: Mailing list stripping off attachments))
On 3/9/20 11:25 AM, Jakub Jelinek wrote: On Mon, Mar 09, 2020 at 10:46:31AM +0100, Tobias Burnus wrote: Hi Thomas, hi Overseers I can confirm that those are stripped off! I did sent an email with three attachments: * test.txt (text/plain) * test.diff (text/x-diff) * the company's disclaimer The attachment with 'text/x-diff' MIME was removed :-( See: https://gcc.gnu.org/pipermail/fortran/current/054078.html A different mail archiver is now used it seems. For the mails before the sourceware move, one can access the old one too, e.g. https://gcc.gnu.org/legacy-ml/gcc-bugs/2020-03/ is the old one vs. https://gcc.gnu.org/pipermail/gcc-bugs/2020-March/ I've been using the gcc-bugs mail archive all the time in the past, but I'm afraid pipermail at least in current configuration is significant step back and I'll likely just use my mailbox from now on. Some reasons: 1) the by date monthly list of mails used to be ordered newest to oldest mails first, now it is oldest to newest, so when dealing with new stuff one has to always scroll down 2) the dates and times of mails used to be shown (date as a section in the list, times in the left column), now there is nothing, so without clicking something it is hard to guess how exactly old it is 3) the columns were nicer (date, subject left justified, email right justified, now there are no columns) 4) some headers were shown, now there is nothing 5) emails used to be sanitized against harvesters, now they aren't 6) there used to be a Raw text URL to grab the raw email, now there is nothing Jakub Hello. I agree with Jakub that the listed feature were nicer about the previous mail list archiver. On the other hand, I agree that we want to use something more recent that is support and under some development. That said, we did we decide to use mailman-2.1 which is a legacy release that can be shortly out of support? Have you consider using version 3.3.0? I'm willing to customize the mail archiver, it should be quite simple. Would it be possible to apply local patches for a RHEL package that's install on the system? Thanks, Martin
mailman customization
Hello.
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:
- by date sorting will be done in reverse order
- default link of e.g. https://gcc.gnu.org/pipermail/gcc-patches/2020-April/
will
point to sorting by date
- email date is added to the listing
Further changes would be possible but I'll need a cooperation from oversees
people.
Thanks,
Martin
diff --git a/Mailman/Archiver/HyperArch.py b/Mailman/Archiver/HyperArch.py
index 4469193..2e186ff 100644
--- a/Mailman/Archiver/HyperArch.py
+++ b/Mailman/Archiver/HyperArch.py
@@ -637,7 +637,7 @@ class HyperArchive(pipermail.T):
FILEMODE = 0660
VERBOSE = 0
-DEFAULTINDEX = 'thread'
+DEFAULTINDEX = 'date'
ARCHIVE_PERIOD = 'month'
THREADLAZY = 0
diff --git a/Mailman/Archiver/HyperDatabase.py b/Mailman/Archiver/HyperDatabase.py
index 2475d47..3566425 100644
--- a/Mailman/Archiver/HyperDatabase.py
+++ b/Mailman/Archiver/HyperDatabase.py
@@ -71,7 +71,7 @@ class DumbBTree:
def __sort(self, dirty=None):
if self.__dirty == 1 or dirty:
self.sorted = self.dict.keys()
-self.sorted.sort()
+self.sorted.sort(reverse = self.path.endswith('date'))
self.__dirty = 0
def lock(self):
diff --git a/templates/en/archidxentry.html b/templates/en/archidxentry.html
index f9bb57a..365e836 100644
--- a/templates/en/archidxentry.html
+++ b/templates/en/archidxentry.html
@@ -1,3 +1,5 @@
+%(datestr)s
+
%(subject)s
%(author)s
Re: mailman customization
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: mailman customization
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? Thank you, Martin - FChE
Re: mailman customization
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: mailman customization
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.
Question about the testresults mailing list
Hi, I have a question about the gcc-testresults mailing list, that is I see everyone using: [releases/gcc-9 revision 02a201f71:0f58d3b54:0e66150084aa217811a5c45fb15e98d7ed3e8839] or [master revision 63b2923dc6f:0c89e976db9:1c16f7fc903c1c1c912faf7889b69d83429b7b2e what is the first 2 hashes, I cant make sens out of it? Thanks Bernd.
Re: Question about the testresults mailing list
On Fri, 3 Apr 2020 at 18:45, Bernd Edlinger wrote: > > Hi, > > I have a question about the gcc-testresults mailing list, > that is I see everyone using: > > [releases/gcc-9 revision > 02a201f71:0f58d3b54:0e66150084aa217811a5c45fb15e98d7ed3e8839] > > or > > [master revision > 63b2923dc6f:0c89e976db9:1c16f7fc903c1c1c912faf7889b69d83429b7b2e > > what is the first 2 hashes, I cant make sens out of it? See contrib/gcc_update, which sets that string: revision=`$GCC_GIT log -n1 --pretty=tformat:%p:%t:%H`
Re: Question about the testresults mailing list
On 4/3/20 7:50 PM, Jonathan Wakely wrote: > On Fri, 3 Apr 2020 at 18:45, Bernd Edlinger wrote: >> >> Hi, >> >> I have a question about the gcc-testresults mailing list, >> that is I see everyone using: >> >> [releases/gcc-9 revision >> 02a201f71:0f58d3b54:0e66150084aa217811a5c45fb15e98d7ed3e8839] >> >> or >> >> [master revision >> 63b2923dc6f:0c89e976db9:1c16f7fc903c1c1c912faf7889b69d83429b7b2e >> >> what is the first 2 hashes, I cant make sens out of it? > > See contrib/gcc_update, which sets that string: > > revision=`$GCC_GIT log -n1 --pretty=tformat:%p:%t:%H` > ah, you mean my workflow was wrong, git pull configure make test gcc_testresults? what is your workflow? Thanks Bernd.
Re: Question about the testresults mailing list
On 4/3/20 7:50 PM, Jonathan Wakely wrote: > On Fri, 3 Apr 2020 at 18:45, Bernd Edlinger wrote: >> >> Hi, >> >> I have a question about the gcc-testresults mailing list, >> that is I see everyone using: >> >> [releases/gcc-9 revision >> 02a201f71:0f58d3b54:0e66150084aa217811a5c45fb15e98d7ed3e8839] >> >> or >> >> [master revision >> 63b2923dc6f:0c89e976db9:1c16f7fc903c1c1c912faf7889b69d83429b7b2e >> >> what is the first 2 hashes, I cant make sens out of it? > > See contrib/gcc_update, which sets that string: > > revision=`$GCC_GIT log -n1 --pretty=tformat:%p:%t:%H` > and for dummies like me, what is %p %t and %H ?
Re: Question about the testresults mailing list
On Fri, 3 Apr 2020 at 18:55, Bernd Edlinger wrote: > > > > On 4/3/20 7:50 PM, Jonathan Wakely wrote: > > On Fri, 3 Apr 2020 at 18:45, Bernd Edlinger wrote: > >> > >> Hi, > >> > >> I have a question about the gcc-testresults mailing list, > >> that is I see everyone using: > >> > >> [releases/gcc-9 revision > >> 02a201f71:0f58d3b54:0e66150084aa217811a5c45fb15e98d7ed3e8839] > >> > >> or > >> > >> [master revision > >> 63b2923dc6f:0c89e976db9:1c16f7fc903c1c1c912faf7889b69d83429b7b2e > >> > >> what is the first 2 hashes, I cant make sens out of it? > > > > See contrib/gcc_update, which sets that string: > > > > revision=`$GCC_GIT log -n1 --pretty=tformat:%p:%t:%H` > > > > and for dummies like me, > > what is %p %t and %H ? git help log
Re: Question about the testresults mailing list
On Fri, 3 Apr 2020 at 18:54, Bernd Edlinger wrote: > > On 4/3/20 7:50 PM, Jonathan Wakely wrote: > > On Fri, 3 Apr 2020 at 18:45, Bernd Edlinger wrote: > >> > >> Hi, > >> > >> I have a question about the gcc-testresults mailing list, > >> that is I see everyone using: > >> > >> [releases/gcc-9 revision > >> 02a201f71:0f58d3b54:0e66150084aa217811a5c45fb15e98d7ed3e8839] > >> > >> or > >> > >> [master revision > >> 63b2923dc6f:0c89e976db9:1c16f7fc903c1c1c912faf7889b69d83429b7b2e > >> > >> what is the first 2 hashes, I cant make sens out of it? > > > > See contrib/gcc_update, which sets that string: > > > > revision=`$GCC_GIT log -n1 --pretty=tformat:%p:%t:%H` > > > > ah, you mean my workflow was wrong, > git pull > configure > make > test > gcc_testresults? > > what is your workflow? Using contrib/gcc_update isn't required.
Re: Question about the testresults mailing list
On 4/3/20 7:57 PM, Jonathan Wakely wrote: > On Fri, 3 Apr 2020 at 18:54, Bernd Edlinger wrote: >> >> On 4/3/20 7:50 PM, Jonathan Wakely wrote: >>> On Fri, 3 Apr 2020 at 18:45, Bernd Edlinger wrote: Hi, I have a question about the gcc-testresults mailing list, that is I see everyone using: [releases/gcc-9 revision 02a201f71:0f58d3b54:0e66150084aa217811a5c45fb15e98d7ed3e8839] or [master revision 63b2923dc6f:0c89e976db9:1c16f7fc903c1c1c912faf7889b69d83429b7b2e what is the first 2 hashes, I cant make sens out of it? >>> >>> See contrib/gcc_update, which sets that string: >>> >>> revision=`$GCC_GIT log -n1 --pretty=tformat:%p:%t:%H` >>> >> >> ah, you mean my workflow was wrong, >> git pull >> configure >> make >> test >> gcc_testresults? >> >> what is your workflow? > > Using contrib/gcc_update isn't required. > I wonder if I should return to using the snapshot files. I am currently the only one testing armv7-gnueabihf modulo I'm using cortex-a9 I use a very slow custom device, it uses 5 days for bootstrap®testing. But it works, and it is stress-testing the linux as well as producing test results. So in order to make the test results comparable I publish with others, would it be good have different archs use the same revision, by default, which would be the one picked once a week for the snapshots? or does anyone test the snapshots and publish the results for differnt archs using the snapshot instead of arbitrary versions ? Of course using git it is rather simple to update to any version. What do you think? Bernd.
Re: Question about the testresults mailing list
On 4/3/20 7:56 PM, Jonathan Wakely wrote: > On Fri, 3 Apr 2020 at 18:55, Bernd Edlinger wrote: >> >> >> >> On 4/3/20 7:50 PM, Jonathan Wakely wrote: >>> On Fri, 3 Apr 2020 at 18:45, Bernd Edlinger wrote: Hi, I have a question about the gcc-testresults mailing list, that is I see everyone using: [releases/gcc-9 revision 02a201f71:0f58d3b54:0e66150084aa217811a5c45fb15e98d7ed3e8839] or [master revision 63b2923dc6f:0c89e976db9:1c16f7fc903c1c1c912faf7889b69d83429b7b2e what is the first 2 hashes, I cant make sens out of it? >>> >>> See contrib/gcc_update, which sets that string: >>> >>> revision=`$GCC_GIT log -n1 --pretty=tformat:%p:%t:%H` >>> >> >> and for dummies like me, >> >> what is %p %t and %H ? > > git help log > done. But why do we use parent hash and tree hash, that does just look confusing? Bernd.
Re: Question about the testresults mailing list
On Fri, 3 Apr 2020 at 19:40, Bernd Edlinger wrote: > > > > On 4/3/20 7:56 PM, Jonathan Wakely wrote: > > On Fri, 3 Apr 2020 at 18:55, Bernd Edlinger > > wrote: > >> > >> > >> > >> On 4/3/20 7:50 PM, Jonathan Wakely wrote: > >>> On Fri, 3 Apr 2020 at 18:45, Bernd Edlinger wrote: > > Hi, > > I have a question about the gcc-testresults mailing list, > that is I see everyone using: > > [releases/gcc-9 revision > 02a201f71:0f58d3b54:0e66150084aa217811a5c45fb15e98d7ed3e8839] > > or > > [master revision > 63b2923dc6f:0c89e976db9:1c16f7fc903c1c1c912faf7889b69d83429b7b2e > > what is the first 2 hashes, I cant make sens out of it? > >>> > >>> See contrib/gcc_update, which sets that string: > >>> > >>> revision=`$GCC_GIT log -n1 --pretty=tformat:%p:%t:%H` > >>> > >> > >> and for dummies like me, > >> > >> what is %p %t and %H ? > > > > git help log > > > > done. > But why do we use parent hash and tree hash, that does just > look confusing? I don't think they're very useful in this context.
Re: subversion status on gcc.gnu.org
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
gcc-8-20200403 is now available
Snapshot gcc-8-20200403 is now available on https://gcc.gnu.org/pub/gcc/snapshots/8-20200403/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 8 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-8 revision b445ceec81ba3f4afad8c3ead1e58f14f1c2e146 You'll find: gcc-8-20200403.tar.xzComplete GCC SHA256=3f02b4a442a7b3f53d66cd2cace703a1a799122fc5bcf97c3869e1e9870df8bf SHA1=bdd219c6a3eb0c64be9581346ce0a6d4477266ea Diffs from 8-20200327 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-8 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: subversion status on gcc.gnu.org
On 4/3/20 10:19 PM, Frank Ch. Eigler wrote:
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.
Well, I still believe we want to use the map file. Reason is that
the gitweb redirection can't deal with SVN revision that don't belong
to trunk.
Thanks,
Martin
- FChE
