Re: GCC 10.1 Release Candidate available from gcc.gnu.org
Hi,
> The first release candidate for GCC 10.1 is available from
>
> https://gcc.gnu.org/pub/gcc/snapshots/10.1.0-RC-20200430/
> ftp://gcc.gnu.org/pub/gcc/snapshots/10.1.0-RC-20200430
>
> and shortly its mirrors. It has been generated from git revision
> r10-8080-g591d857164c37cd0bb96da2a293148e01f280e0f.
I believe either the snapshot should have been cut as 10.0.1-RC-20200430, as was
the case w/ the first GCC 9 RC, or gcc/BASE-VER should have been updated to have
10.1.0 in it just after making a release branch (in which case the instructions
in branching.html should be updated too)? Right now an attempt to build this
first RC using the Gentoo Portage tooling fails on the following sanity check,
which makes sense to me:
local actual_version=$(< "${S}"/gcc/BASE-VER)
if [[ "${GCC_RELEASE_VER}" != "${actual_version}" ]] ; then
eerror "'${S}/gcc/BASE-VER' contains '${actual_version}', expected
'${GCC_RELEASE_VER}'"
die "Please set 'TOOLCHAIN_GCC_PV' to '${actual_version}'"
fi
Not a major issue, of course, and could be easily fixed locally.
Re: GCC 10.1 Release Candidate available from gcc.gnu.org
On 4/30/20 11:21 PM, Jakub Jelinek via Gcc wrote: The first release candidate for GCC 10.1 is available from https://gcc.gnu.org/pub/gcc/snapshots/10.1.0-RC-20200430/ ftp://gcc.gnu.org/pub/gcc/snapshots/10.1.0-RC-20200430 What about naming these 10.1.0-rc1? and shortly its mirrors. It has been generated from git revision r10-8080-g591d857164c37cd0bb96da2a293148e01f280e0f. Can we also use proper git tags for it please? Thanks, Martin
Re: GCC 10.1 Release Candidate available from gcc.gnu.org
On Fri, May 01, 2020 at 09:23:33AM +0200, Martin Liška wrote: > On 4/30/20 11:21 PM, Jakub Jelinek via Gcc wrote: > > The first release candidate for GCC 10.1 is available from > > > > https://gcc.gnu.org/pub/gcc/snapshots/10.1.0-RC-20200430/ > > ftp://gcc.gnu.org/pub/gcc/snapshots/10.1.0-RC-20200430 > > What about naming these 10.1.0-rc1? This is naming that has been used for year, I just keep forgetting what exact -r argument to pass for the RCs, and the RC and date part come from the script. Due to the versioning conventions, BASE-VER can't be 10.1.0 yet, because there is no release, but the filenames in this case contain RC. > > and shortly its mirrors. It has been generated from git revision > > r10-8080-g591d857164c37cd0bb96da2a293148e01f280e0f. > > Can we also use proper git tags for it please? Is it worth it? RCs are something of interest just for the week at most and then forgotten, the releases is what matters and that is properly tagged (including signing). Jakub
Re: Not usable email content encoding
On Thu, 2020-04-23 at 15:14 -0600, Tom Tromey wrote: > > > > > > "Segher" == Segher Boessenkool writes: > > Segher> My point was that this should *never* be part of patches, already. > > FWIW, I use a few scripts so that I can keep ChangeLogs as files. > That's what I do when working on gdb. > > https://github.com/tromey/git-gnu-changelog > > This is easier on the whole, IME, because it means there is no extra > manual step before pushing. Right. And that's really my goal here -- eliminate the manual steps. Ideally I want to be able to git am; git push on a good patch. Manual steps for good patches need to be excised from the workflow. The ChangeLog file is a major problem in that regard. > > Of course, better would be to remove ChangeLogs entirely (including not > putting anything like them into a commit message), because they are > largely not useful and are just make-work. Again IMNSHO -- I know there > are some folks who read them, but I basically never have since switching > to git. I read them less and less. At this point I think I read them to see if a particular patch in my queue has already been applied. Otherwise I'm using the git info. jeff
Re: Not usable email content encoding
On Fri, 2020-04-24 at 22:01 +0200, Martin Jambor wrote: > Hi, > > On Fri, Apr 24 2020, Segher Boessenkool wrote: > > Hi! > > > > On Fri, Apr 24, 2020 at 05:48:38PM +0200, Thomas Koenig wrote: > > > > Of course, better would be to remove ChangeLogs entirely (including not > > > > putting anything like them into a commit message), because they are > > > > largely not useful and are just make-work. > > > > > > I disagree. I find them quite useful. > > > > For what? And, can that be provided some other way? > > I often have a look at them when reviewing a patch. It is great when > they clearly indicate whether a change is some form of restructuring or > a functional change and broadly speaking what it is. Then I just know > what to look for. > > I also find writing them useful as it forces me to go through every > patch one last time before submitting it :-) If you spend some time > configuring your text editor and git, the boilerplate stuff can be > generated automatically. Agreed on all the points above. I can't count how many patches I've written through the years, then got to the ChangeLog step and realized that further work was needed. > > I do not think this can be provided in any other way that would not > resemble a ChangeLog. I do support the effort to put them into commit > messages only though (and then perhaps generate the files from that). That's where I lean as well. I could also live with the ChangeLog being generated by a commit hook and the like. Ultimately it's the manual steps in applying patches that I want to eliminate from our workflows and the ChangeLog file consistently results in the need for manual intervention. jeff
All Kinds Of High Quality Patches With Factory Rate+Fastest Turnaround Time
ANH Digitizing (Embroidery, Custom Patches, Screen Printing, Graphics Art Work and All you need) We ANH DIGITIZING mainly produce Custom Embroidery Patch more than 15 years of experience.Without middleman and directly factory price. Custom Patches: 1. Embroidered Patches 2. Chenille Patches 3. Leather Patches 4. Iron Patches 5. Bullion Patches 6. Name Patches 7. Printed Patches 8. Woven Patches 9. PVC Patches And all type of which you need… Welcome to email us and get the best price ASAP. Thank you! Best Regards, Mark Sloan anhdigitiz...@gmail.com www.anhdigitizing.com
Re: Not usable email content encoding
Hi, On Fri, May 01 2020, Jeff Law wrote: > On Fri, 2020-04-24 at 22:01 +0200, Martin Jambor wrote: >> Hi, >> >> On Fri, Apr 24 2020, Segher Boessenkool wrote: >> > Hi! >> > >> > On Fri, Apr 24, 2020 at 05:48:38PM +0200, Thomas Koenig wrote: >> > > > Of course, better would be to remove ChangeLogs entirely (including not >> > > > putting anything like them into a commit message), because they are >> > > > largely not useful and are just make-work. >> > > >> > > I disagree. I find them quite useful. >> > >> > For what? And, can that be provided some other way? >> >> I often have a look at them when reviewing a patch. It is great when >> they clearly indicate whether a change is some form of restructuring or >> a functional change and broadly speaking what it is. Then I just know >> what to look for. >> >> I also find writing them useful as it forces me to go through every >> patch one last time before submitting it :-) If you spend some time >> configuring your text editor and git, the boilerplate stuff can be >> generated automatically. > Agreed on all the points above. I can't count how many patches I've > written through the years, then got to the ChangeLog step and realized > that further work was needed. I can relate to that :-) > >> >> I do not think this can be provided in any other way that would not >> resemble a ChangeLog. I do support the effort to put them into commit >> messages only though (and then perhaps generate the files from that). > That's where I lean as well. I could also live with the ChangeLog being > generated by a commit hook Please note that this would change the commit hash from what the author had on their computer, which would be a bit unfortunate. But generating them along with the "Daily bump" seems like a nice alternative. Thanks, Martin > and the like. Ultimately it's the manual steps in > applying patches that I want to eliminate from our workflows and the ChangeLog > file consistently results in the need for manual intervention. > > jeff
gcc-9-20200501 is now available
Snapshot gcc-9-20200501 is now available on https://gcc.gnu.org/pub/gcc/snapshots/9-20200501/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 9 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-9 revision cb2c76c8b156c6d8541ddb3aa894568a2de3b02b You'll find: gcc-9-20200501.tar.xzComplete GCC SHA256=1568a6ea138b9cf5ab13c325cc5b49055c511fb979653cf9ae9211263e232dce SHA1=b2991084eb583087f22ebbc3a2c29c8986b6 Diffs from 9-20200425 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-9 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.
