From: Matthias Klose <doko@ubuntu.com>
To: Vladimir Mezentsev <vladimir.mezentsev@oracle.com>,
binutils@sourceware.org
Subject: Re: Getting ready for the 2.39 branch/release
Date: Thu, 23 Jun 2022 14:50:32 +0200 [thread overview]
Message-ID: <9e8dcef8-48c0-446c-0aae-55cc52dc102c@ubuntu.com> (raw)
In-Reply-To: <663e1bb9-a211-2857-a381-dd68f0fdb0bc@oracle.com>
On 23.06.22 01:00, Vladimir Mezentsev via Binutils wrote:
>
>
> On 6/22/22 12:35, Matthias Klose wrote:
>> On 21.06.22 13:09, Nick Clifton via Binutils wrote:
>>> Hi Guys,
>>>
>>> It is time to think about the next GNU Binutils release.
>>>
>>> Ideally I would like to make the release at the end of July
>>> which will be 6 months on from the 2.38 release. Unfortunately
>>> I am on vacation for two weeks in the middle of July (11-22) so
>>> either:
>>>
>>> 1. Someone else volunteers to make the 2.39 release.
>>>
>>> 2. I create the branch early (eg Saturday June 25) but then
>>> release late (eg Saturday July 30) and the global maintainers
>>> get to approve patches for the branch.
>>>
>>> This does not give much time for people to get new features
>>> into the sources before the branch is cut...
>>>
>>> 3. I create the branch in a couple of week's time (eg Fri Jul 8)
>>> and then release early in August (eg Sat Aug 6) and again I
>>> ask the global maintainers for help in approving patches for
>>> the branch.
>>>
>>> Thoughts ?
>>
>> Debian and Ubuntu are using the current trunk for the releases in development.
>> There's currently one issue that I'm aware of:
>>
>> https://bugs.debian.org/1013244
>>
>> just asked the Debian mips porters about it.
>>
>> As I understand, some minor gprofng configuration issues are being worked on.
>
> gprofng has these bugs:
>
> ID Product Comp Assignee▲ Status▲ Resolution Summary
> 29131 binutils gprofng vladimir.mezentsev@oracle.com UNCO No rule to
> make target 'gprofng.1', needed by 'all-am'. Stop. For arm
>
> I cannot reproduce 29131.
I added some information to the bug report. This is only seen when cross
building. Cross building from a git snapshot doesn't have the generated man
pages checked in, but man_MANS has them added unconditionally. Maybe make the
definition of man_MANS conditional on BUILD_MAN as well?
That should not be an issue for releases, because the generated man pages are
included in the release tarball (maybe Nick needs to update the release script
for the newly added man pages?).
Matthias
next prev parent reply other threads:[~2022-06-23 12:50 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-21 11:09 Nick Clifton
2022-06-22 6:36 ` Jan Beulich
2022-06-22 19:35 ` Matthias Klose
2022-06-22 23:00 ` Vladimir Mezentsev
2022-06-23 12:50 ` Matthias Klose [this message]
2022-06-23 10:07 ` Nick Clifton
2022-06-23 13:07 ` Matthias Klose
2022-06-23 15:43 ` Nick Clifton
2022-06-23 23:02 ` Hans-Peter Nilsson
2022-06-24 10:01 ` Nick Clifton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9e8dcef8-48c0-446c-0aae-55cc52dc102c@ubuntu.com \
--to=doko@ubuntu.com \
--cc=binutils@sourceware.org \
--cc=vladimir.mezentsev@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).