[Bug admin/31881] binutils-gdb Git repository is flooded by automatic commits
https://sourceware.org/bugzilla/show_bug.cgi?id=31881 --- Comment #25 from Rostislav Krasny --- Hi Nick, I still think this patch could be made simpler. Please consider and comment my message at 2024-08-02. In short, any kind of tarball (release, snapshot, nightly, etc.) should be made with the bfd/version.h already generated from Git repository ONLY. Then bfd/version.h should never be regenerated from within any tarball, i.e. no other method of generation should ever be used. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31800] New: src-release.sh recursively changes permissions of everything in to 0777
https://sourceware.org/bugzilla/show_bug.cgi?id=31800 Bug ID: 31800 Summary: src-release.sh recursively changes permissions of everything in to 0777 Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: rostiprodev at gmail dot com Target Milestone: --- After running this script permissions of all files and directories (including files of Git repo and the root directory of the project) are changed to 0777, i.e. everything is open for everybody for any read-write operation. This is not good, not secure and must never be done. The src-release.sh script does it by the following line: chmod -R og=u . || chmod og=u `find . -print` Please remove this line. The src-release.sh works properly without that line and doesn't change permissions of files or directories. In case a particular file must have special permissions you can change those permissions in the Git repository. Git always stores file permissions of all BLOB (file) and TREE (directory) object in the appropriate TREE objects that point to (have) them. For more information read: [1] https://git-scm.com/book/en/v2/Git-Internals-Git-Objects#_tree_objects [2] https://adamj.eu/tech/2023/01/31/git-add-remove-execute-permissions/ I found this issue in the "binutils-2_42-branch" Git branch but it exists in master and in some older branches as well. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31800] src-release.sh recursively changes permissions of everything in to 0777
https://sourceware.org/bugzilla/show_bug.cgi?id=31800 Rostislav Krasny changed: What|Removed |Added CC||rostiprodev at gmail dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31800] src-release.sh recursively changes permissions of everything in to 0777
https://sourceware.org/bugzilla/show_bug.cgi?id=31800 --- Comment #2 from Rostislav Krasny --- Hi Nick, The "core.sharedRepository" configuration property of Git allows to override user’s umask value for all tracked files and their directories in the Git repository, i.e. how they are created in the Git worktree. For more information about that configuration property please read https://git-scm.com/docs/git-config#Documentation/git-config.txt-coresharedRepository The src-release.sh script also generates some additional files during preparation of release tarballs. For those additional files umask could be set in the beginning of the src-release.sh itself. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31800] src-release.sh recursively changes permissions of everything in to 0777
https://sourceware.org/bugzilla/show_bug.cgi?id=31800 --- Comment #3 from Rostislav Krasny --- In case you can't guarantee the "core.sharedRepository" configuration property was set properly before the src-release.sh was ran you can, in addition to setting umask in its beginning, also set the "core.sharedRepository" Git configuration property near the umask command and right after that run 'git reset --hard'. You can also add some check that there is no uncommitted changes before the 'git reset --hard' is actually run. Maybe this is the best solution. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31800] src-release.sh recursively changes permissions of everything in to 0777
https://sourceware.org/bugzilla/show_bug.cgi?id=31800 --- Comment #5 from Rostislav Krasny --- Created attachment 15549 --> https://sourceware.org/bugzilla/attachment.cgi?id=15549&action=edit formatted patch with the fix -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31800] src-release.sh recursively changes permissions of everything in to 0777
https://sourceware.org/bugzilla/show_bug.cgi?id=31800 --- Comment #6 from Rostislav Krasny --- The 'git reset --hard' works not stable. Sometimes it changes permissions according to umask or to the git configuration, sometimes it doesn't. So I made another fix. I've attached a formatted patch with my fix. Please review and merge it. I tested it on my Fedora 40. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31800] src-release.sh recursively changes permissions of everything in to 0777
https://sourceware.org/bugzilla/show_bug.cgi?id=31800 --- Comment #8 from Rostislav Krasny --- (In reply to Nick Clifton from comment #7) > > There is just one thing though, in order to accept it we either need it > signed with a Developer Certificate of Origin or else you need to complete a > copyright assignment to the FSF. How to do it? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31800] src-release.sh recursively changes permissions of everything in to 0777
https://sourceware.org/bugzilla/show_bug.cgi?id=31800 --- Comment #9 from Rostislav Krasny --- Created attachment 15559 --> https://sourceware.org/bugzilla/attachment.cgi?id=15559&action=edit formatted patch with the optimized fix This is the final patch. Please use it instead of the previous. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31800] src-release.sh recursively changes permissions of everything in to 0777
https://sourceware.org/bugzilla/show_bug.cgi?id=31800 --- Comment #10 from Rostislav Krasny --- Meanwhile I've made an optimized version of the patch. In the first version I calculated the new octal number of permissions and called the printf(1) again and again, for each file and directory in the loop. But there are only two possible values, so now I calculate those two values before the loop one time and then just use them in the loop. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31800] src-release.sh recursively changes permissions of everything in to 0777
https://sourceware.org/bugzilla/show_bug.cgi?id=31800 --- Comment #11 from Rostislav Krasny --- (In reply to Rostislav Krasny from comment #8) > (In reply to Nick Clifton from comment #7) > > > > There is just one thing though, in order to accept it we either need it > > signed with a Developer Certificate of Origin or else you need to complete a > > copyright assignment to the FSF. > > How to do it? Answering my own question by a link to the email you sent in the binutils mailing list in 2022 and I just didn't know about: https://sourceware.org/pipermail/binutils/2022-October/123680.html So I ran 'git commit -s --amend' and after that made another final patch, just to add the Signed-off-by line. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31800] src-release.sh recursively changes permissions of everything in to 0777
https://sourceware.org/bugzilla/show_bug.cgi?id=31800 Rostislav Krasny changed: What|Removed |Added Attachment #15549|0 |1 is obsolete|| Attachment #15559|0 |1 is obsolete|| --- Comment #12 from Rostislav Krasny --- Created attachment 15560 --> https://sourceware.org/bugzilla/attachment.cgi?id=15560&action=edit formatted patch with the optimized fix with DCO Signed DCO -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31800] src-release.sh recursively changes permissions of everything in to 0777
https://sourceware.org/bugzilla/show_bug.cgi?id=31800 --- Comment #15 from Rostislav Krasny --- (In reply to Nick Clifton from comment #14) > Hi Rostislav, > > Thanks for the updated patch and the DCO. I have now applied your patch > to the sources. Thank you too for accepting my first contribution in the project. I made a small improvement of the new src-release.sh and going to attache an additional patch. Before this additional patch the src-release.sh script can't be ran again and again without manually deleting all untracked files that src-release.sh created in the previous run. With this patch the check of uncommitted changes looks for changes of the tracked files only, i.e. any new file is not taken into account in this check. Such files are removed a few lines later by the 'git clean -fdx' command that also prints their names. I think this is better and more consistent behavior. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31800] src-release.sh recursively changes permissions of everything in to 0777
https://sourceware.org/bugzilla/show_bug.cgi?id=31800 --- Comment #16 from Rostislav Krasny --- Created attachment 15566 --> https://sourceware.org/bugzilla/attachment.cgi?id=15566&action=edit additional improvement -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31800] src-release.sh recursively changes permissions of everything in to 0777
https://sourceware.org/bugzilla/show_bug.cgi?id=31800 Rostislav Krasny changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #17 from Rostislav Krasny --- Reopened only to draw attention to the second patch. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31800] src-release.sh recursively changes permissions of everything in to 0777
https://sourceware.org/bugzilla/show_bug.cgi?id=31800 --- Comment #19 from Rostislav Krasny --- Thank you Nick! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug admin/31881] New: binutils-gdb Git repository is flooded by automatic commits
https://sourceware.org/bugzilla/show_bug.cgi?id=31881 Bug ID: 31881 Summary: binutils-gdb Git repository is flooded by automatic commits Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: admin Assignee: unassigned at sourceware dot org Reporter: rostiprodev at gmail dot com Target Milestone: --- There are many daily automatic commits that continuously change one single line with definition of the BFD_VERSION_DATE in the bfd/version.h file. There are also many daily automatic commits with a similar change in the gdb/version.in file (in a past, probably before the GDB repository was merged with the Binutils repository). Maybe there are/were other such daily automatic commits that I just missed. All these automatic commits flooded the binutils-gdb Git repository and made it hard to follow the commit history. Also the Git repository itself is too big now (993MB) and going to be even bigger just because of such automatic commits. Each such commit makes at least three new objects in Git repository: new BLOB object, new TREE object and new COMMIT object. Let's make some math. Right now there are 146243 commits in all branches. In all those commits there are 7 automatic daily commits of bfd/version.h and 9149 automatic daily commits of gdb/version.in, i.e. about 13.86% of all commits of all times are those automatic daily commits and this is too much! The bfd/version.h file has the following explanation: /* The date below is automatically updated every day by a bot. During development, we include the date in the tools' version strings (visible in 'ld -v' etc.) because people build binutils from a variety of sources - git, tarballs, distro sources - and we want something that can easily identify the source they used when they report bugs. The bfd version plus date is usually good enough for that purpose. During development, this date ends up in libbfd and libopcodes sonames because people naturally expect shared libraries with the same soname to have compatible ABIs. We could bump the bfd version on every ABI change, but that's just another thing contributors and maintainers would need to remember. Instead, it's much easier for all if the soname contains the date. This is not perfect but is good enough. In releases, the date is not included in either version strings or sonames. */ Let's check the "variety of sources": distro sources, tarballs and git. I use Fedora 40 and it seems like it has release versions of Binutils and GDB, because I don't see the BFD_VERSION_DATE value in neither version string nor sonames: $ ld -v GNU ld version 2.41-37.fc40 $ gdb --version | head -n 1 GNU gdb (Fedora Linux) 14.2-2.fc40 $ ls -l libopcodes* libbfd* -rwxr-xr-x. 1 root root 1292336 May 3 03:00 libbfd-2.41-37.fc40.so -rwxr-xr-x. 1 root root 882512 May 3 03:00 libopcodes-2.41-37.fc40.so I think the majority of other Linux distributions use release versions of Binutils and of GDB or locally patched release versions as well as Fedora. Even LFS instructs their users to build binutils and GDB from the release tarballs. So the "distro sources" seems to be not relevant. The other possibility is tarballs. I doubt anybody makes tarballs manually or by their own custom script, because there is the src-release.sh script that makes tarballs of any particular part of the binutils-gdb Git repository. But this script makes release tarballs, i.e. tarballs that don't use the BFD_VERSION_DATE in version or sonames, as explained in the bfd/version.h file. So this possibility is also not relevant. And the last possibility is Git repository used directly. I think this possibility is relatively rare, at least outside of the project itself. I think the the above explanation in the bfd/version.h file is relevant only or mostly for those who build directly from the Git repository, i.e. developers, contributors and other enthusiasts. In case you want to support BFD_VERSION_DATE for those who build from the Git repository directly the value of the BFD_VERSION_DATE or the whole bfd/version.h file could be generated by the by the "configure" script according to the last commit. Generating the whole bfd/version.h file and not saving it in Git repo could be even better because otherwise there will be uncommitted change of tracked file. You can also save that value in the UNIX time format instead, i.e. more precisely. You can also use something like BFD_VERSION_HASH instead or additionally and put the hash of the last commit there. Please consider a fix like the above. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug admin/31881] binutils-gdb Git repository is flooded by automatic commits
https://sourceware.org/bugzilla/show_bug.cgi?id=31881 Rostislav Krasny changed: What|Removed |Added CC||rostiprodev at gmail dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug admin/31881] binutils-gdb Git repository is flooded by automatic commits
https://sourceware.org/bugzilla/show_bug.cgi?id=31881 --- Comment #4 from Rostislav Krasny --- (In reply to Nick Clifton from comment #3) > > I do like the idea of the configure file generating the bfd/version.h file > automatically however, so if someone wants to write a potential patch that > would be great. The /configure script is generated from the /configure.ac file, right? Then the fix should be done in the /configure.ac and not directly in the /configure script? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug admin/31881] binutils-gdb Git repository is flooded by automatic commits
https://sourceware.org/bugzilla/show_bug.cgi?id=31881 --- Comment #5 from Rostislav Krasny --- What exact command is used to generate the /configure script from the /configure.ac file? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug admin/31881] binutils-gdb Git repository is flooded by automatic commits
https://sourceware.org/bugzilla/show_bug.cgi?id=31881 --- Comment #8 from Rostislav Krasny --- Created attachment 15596 --> https://sourceware.org/bugzilla/attachment.cgi?id=15596&action=edit patch Please try this patch. It has changes in the configure.ac file only. The generated configure script is also stored in Git repository but it is usually updated by a separate commit, so it's not part of this patch and should be generated separately. I tested it with locally built autoconf 2.69 using "~/local/autoconf-2.69/bin/autoreconf -i" command. Difference between the newly generated configure script and its version in the master branch was an addition of the embedded shell code only. Additionally I made yet another temporary commit (not part of this patch) and tested generation of the bfd/version.h with "./src-release.sh binutils" command that calls the configure script internally. Anyone who don't use releases and build directly from Git repo also run this script, so it should work for them as well. A few words how I made it. I'm not familiar with the autoconf, so I asked ChatGPT how can I add an embedded shell code into the generated configure script. It suggested to use either AC_CONFIG_COMMANDS_PRE or AC_CONFIG_COMMANDS and it forgot about AC_CONFIG_COMMANDS_POST. I decided to use AC_CONFIG_COMMANDS_PRE, i.e. the bfd/version.h file is generated by the configure script at the very beginning. Hope this decision was right. I use current format of the BFD_VERSION_DATE for compatibility but I suggest to change it in a future to something more precise. The change should be done in the "--date=format:%Y%m%d" part of the git log command, according to strftime(3) I also changed the first sentence of the comment in the now generated the bfd/version.h, so please check my English too. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug admin/31881] binutils-gdb Git repository is flooded by automatic commits
https://sourceware.org/bugzilla/show_bug.cgi?id=31881 --- Comment #9 from Rostislav Krasny --- > Well to be precise, it is the bfd/configure.ac file that ought to contain > the code to generate the version.h file. (Since the top level configure.ac > file is shared with the gcc project, and that project does not know or care > about the bfd/ sub-directory). Missed this and when trying to move the added AC_CONFIG_COMMANDS_PRE from the top level configure.ac into the bfd/configure.ac it makes more changes and in more files, after running "~/local/autoconf-2.69/bin/autoreconf -i". Probably because versions of other tools are still different in my Fedora 40. For example: -# generated automatically by aclocal 1.15.1 -*- Autoconf -*- +# generated automatically by aclocal 1.16.5 -*- Autoconf -*- -# Makefile.in generated by automake 1.15.1 from Makefile.am. +# Makefile.in generated by automake 1.16.5 from Makefile.am. Please fix my patch and test it in a clear environment. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug admin/31881] binutils-gdb Git repository is flooded by automatic commits
https://sourceware.org/bugzilla/show_bug.cgi?id=31881 --- Comment #10 from Rostislav Krasny --- The general idea of my patch is adding the AC_CONFIG_COMMANDS_PRE block into the configure.ac file that then adds the appropriate shell code into the generated configure script. That shell code should later generate the removed (in my original patch) bfd/version.h file with the right value of BFD_VERSION_DATE. The only difficulty for me is finding the right place in the right configure.ac to add the AC_CONFIG_COMMANDS_PRE block into. When I asked to fix my original patch I actually asked about that right place of the AC_CONFIG_COMMANDS_PRE block. Unfortunately I'm not familiar with the autotools and also don't have a clean environment with right versions of other tools that are used during generation of the configure script. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug admin/31881] binutils-gdb Git repository is flooded by automatic commits
https://sourceware.org/bugzilla/show_bug.cgi?id=31881 --- Comment #13 from Rostislav Krasny --- (In reply to Nick Clifton from comment #11) > Created attachment 15616 [details] > Proposed patch > > Sorry for dropping this. > > I have uploaded a revised version of your patch which: > > 1. Moves the configure.ac alterations into the bfd/configure.ac > 2. Adds support for running the configure script in a build directory > that is separate from the source directory (which is encouraged for > building the binutils). > > I have tested the patch locally and it works for me, but I would like > you to have a look over it first, before I commit it. I can't review changes in the *.am and *.in files because I'm not familiar with them. I saw you've added "cd $srcdir ;" before "git log". That's seems to be right and in my original patch I missed the fact that before making a build the configure scripts are ran from a separate directory that could be outside of the git worktree. The last question is: will the bfd/configure script be ran by the src-release.sh script only or also by a user who want to build from an already created tarball? In case of an already created tarball that part of the bfd/configure script should not be ran because the bfd/version.h is already created during creation of the tarball and also because there is no Git repo available. If the bfd/configure us always running I propose to change this line: VERSION_DATE=$(cd $srcdir ; git log -1 --format=%cd --date=format:%Y%m%d) into that line: VERSION_DATE=$(cd $srcdir && git rev-parse --is-inside-work-tree > /dev/null 2>&1 && git log -1 --format=%cd --date=format:%Y%m%d) And then generate the bfd/version.h file only if the $VERSION_DATE is not empty. For more information about the 'git rev-parse --is-inside-work-tree' command read `man git-rev-parse` or https://git-scm.com/docs/git-rev-parse -- You are receiving this mail because: You are on the CC list for the bug.
[Bug admin/31881] binutils-gdb Git repository is flooded by automatic commits
https://sourceware.org/bugzilla/show_bug.cgi?id=31881 --- Comment #14 from Rostislav Krasny --- (In reply to Andreas Schwab from comment #12) > That won't work with a snapshot. Is it the same to what I tried to fix in my previous message? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug admin/31881] binutils-gdb Git repository is flooded by automatic commits
https://sourceware.org/bugzilla/show_bug.cgi?id=31881
--- Comment #18 from Rostislav Krasny ---
(In reply to Nick Clifton from comment #17)
> Created attachment 15626 [details]
> Proposed patch
>
> Hi Guys,
>
> OK, what do you think of this version ?
>
> It incorporates Rostilav's suggested change, along with extra code to
> generate a date if building from a source tarball rather than repository
> sources
Hi Nick,
Why to generate the VERSION_DATE and the version.h file if building from a
source tarball? Isn't any source tarball created by the src-release.sh script?
If any source tarball created by the src-release.sh it already contains the
generated version.h file with properly generated VERSION_DATE from the last
commit in the Git repo. I think in case of source tarball the configure script
should not try to generate the version.h again because it already exist.
In case there is a reason to generate version.h again my following commend is
about how it's done. This line in your patch assumes the date could always be
found in the very first line of the change log file:
VERSION_DATE=$(head -1 $srcdir/ChangeLog.git | cut -b 1-10 | sed -e s/-//g)
But what if it's not first? What do you think about changing that code into the
following one?
VERSION_DATE=$(grep -m 1 -Po '^\d{4}-\d{2}-\d{2}(?=\s+)' $srcdir/ChangeLog.git
| sed s/-//g)
I also don't see the ChangeLog.git file anywhere in the Git repo of binutils.
Did you mean ChangeLog file?
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug admin/31881] binutils-gdb Git repository is flooded by automatic commits
https://sourceware.org/bugzilla/show_bug.cgi?id=31881
--- Comment #20 from Rostislav Krasny ---
(In reply to Nick Clifton from comment #19)
> > If any source tarball created by the src-release.sh it already contains
> > the generated version.h file with properly generated VERSION_DATE from
> > the last commit in the Git repo. I think in case of source tarball the
> > configure script should not try to generate the version.h again because
> > it already exist.
>
> Yes - this is what should happen.
Ok. Then what is the reason of generating VERSION_DATE from ChangeLog.git or
from the current date? If this is done in case of a snapshot version, how that
snapshot version is made? Isn't it a regular tarball created by the
src-release.sh script sometime between official releases?
I just thought only three cases of the configure script being running are
possible: [1] building directly from the Git repo, [2] making a tarball
(release/snapshot/whatever) by the src-release.sh script from the Git repo, and
[3] building (release/snapshot/whatever) from a tarball previously created in
case 2. Only in cases 1 and 2 the configure script needs to generate version.h
and the $VERSION_DATE value, and in case 3 it should do nothing about version.h
and $VERSION_DATE because version.h is already existing in the tarball. Right?
> > This line in your patch assumes the date could always be found in
> > the very first line of the change log file:
> >
> > VERSION_DATE=$(head -1 $srcdir/ChangeLog.git | cut -b 1-10 | sed -e s/-//g)
>
> True - the assumption might be true most of the time, but you are
> correct - the code should not rely upon it.
>
> > What do you think about changing that code into the following one?
> >
> > VERSION_DATE=$(grep -m 1 -Po '^\d{4}-\d{2}-\d{2}(?=\s+)'
> > $srcdir/ChangeLog.git | sed s/-//g)
>
> Much better. The uploaded new patch includes this change.
Ok
> > I also don't see the ChangeLog.git file anywhere in the Git repo
> > of binutils. Did you mean ChangeLog file?
>
> No - the ChangeLog.git file is created as part of the binutils
> release process, so it should always be present in release tarballs,
> but absent from the git repository.
Ok
> I also found that the "git rev-parse --is-inside-work-tree" does not work
> as desired. If run outside of a repository it returns a fatal error and
> stops the rest of the scriptlet from running. So I have replaced it with
> a test for the .git directory at the top level of the source tree. Which
> I think should always work.
Does the configure script have 'set -e' somewhere? I didn't find it. Otherwise
why the configure script stops in this case?
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug admin/31881] binutils-gdb Git repository is flooded by automatic commits
https://sourceware.org/bugzilla/show_bug.cgi?id=31881 --- Comment #22 from Rostislav Krasny --- (In reply to Nick Clifton from comment #21) > > Ok. Then what is the reason of generating VERSION_DATE from ChangeLog.git or > > from the current date? > > These methods are meant to handle the case where the sources are not in a > clone of the repository and not from a release tarball. Besides the snapshots mentioned below are there any other cases of not release tarballs? > > If this is done in case of a snapshot version, how > > that snapshot version is made? Isn't it a regular tarball created by the > > src-release.sh script sometime between official releases? > > Yes - in fact there is now a script on Sourceware that creates snapshots > each time a commit is applied to the repository. I suppose that the script that creates the snapshot tarballs has an access to the Git repository of binutils-gdb project? If it has, could that script generate the bfd/version.h file with the value of the BFD_VERSION_DATE taken from the Git repository? Then any snapshot will have the bfd/version.h already generated and the configure script will not have to do it again without any access to the Git repository. In other words let's generate the bfd/version.h during creation of any tarball (snapshot, release, whatever) or during a direct build from the Git repository only. Build from any tarball should NEVER deal with this task and should get the bfd/version.h already located in the tarball. It will make the shell code that finds the value of BFD_VERSION_DATE much simpler because it will find it in the Git repo only and not in other less reliable places like $srcdir/ChangeLog.git -- You are receiving this mail because: You are on the CC list for the bug.
[Bug admin/31881] binutils-gdb Git repository is flooded by automatic commits
https://sourceware.org/bugzilla/show_bug.cgi?id=31881 --- Comment #23 from Rostislav Krasny --- Hi, Is there any update regarding this ticket? -- You are receiving this mail because: You are on the CC list for the bug.
