On Wed, 18 Mar 2020, Frank Ch. Eigler via Gcc wrote:
> > Out of curiousity, is this rewriting you are talking about the cause for a
> > lot of mails showing up as "From: GCC List" rather than their real senders?
> > This has become very annoying recently.
>
> Yes, for emails from domains with dec
Hi Frank,
> > I am fairly sure it breaks `git am' too, requiring a `From' override in
> > the change description for author attribution in patch application to work
> > reliably (I tend to work on my outbox when applying my own patches, so I
> > avoid this issue, but I am sure the issue will h
On Tue, 7 Apr 2020, Christopher Faylor wrote:
> >Can we please switch it off? It's not like we really had a problem before
> >the switch to mailman.
>
> You can't really make statements like this which imply that you are
> aware of "problems" on sourceware when you're not a sourceware
> adminis
On Tue, 7 Apr 2020, Christopher Faylor wrote:
> >In a way that's amusing and just reinforces my p.o.v. that DMARC is
> >bollocks.
>
> Not that it means anything but I agree 100%.
>
> It's like whoever made the "standard" just said "to hell with mailing
> lists".
Maybe they just didn't know of
On Tue, 14 Apr 2020, Christopher Faylor wrote:
> >I think that means that dmarc_moderation_action: "Munge From" can
> >simply be switched off then (at least I don't see which other headers
> >e.g. gcc@ is rewriting that would cause DMARC to scream; and if there
> >are any, then it would be better
On Wed, 15 Apr 2020, ζδΌζ via Gcc wrote:
> I am trying to add a library into gcc source code tree. The gcc source
> have used libtool 2.2.7a 1.1334. but I cannot find the version.
It is "libtool (GNU libtool 1.3134 2009-11-30) 2.2.7a" AFAICT, that is
1.3134 rather than 1.1334. I take it there
On Wed, 13 May 2020, Rainer Orth wrote:
> > I'm in favour of requiring 1.5.3 or later, so 1.6 would be OK for me.
>
> If we go beyond 1.5.x, we need to go all the way up to 1.6.2: 1.6 and
> 1.6.1 have an ugly bug that can miss timeouts, causing tests to hang
> indefinitely until one manually kill
Hi Rainer,
> > Versions 1.6 and 1.6.1 seem ubiquitous and coincidentally earlier this
> > very week I have been chasing a phenomenon with Expect's `wait' semantics
> > causing a reliable hang in remote testing if `ssh' to the target board
> > stops responding for whatever reason. I have come
On Thu, 14 May 2020, Rob Savoye wrote:
> Personally, I tried to find funding to refactor DejaGnu in Python,
> since Tcl is unmaintained too, but nobody was interested.
Thank you for your contribution to DejaGnu over the years and for your
input on this occasion.
However it does not appear t
On Thu, 14 May 2020, Rob Savoye wrote:
> Right now working through patches is probably more important. :-)
> There's zero patches on the DejaGnu savannah site, so I'd ask anybody to
> submit them so I don't have to dig them out of email archives.
I have reposted the single patch I have had out
On Sat, 16 May 2020, Rob Savoye wrote:
> > Overall perhaps a patch management system might be good having to make
> > chasing patches easier, such as patchwork, and we already use Git, so we
>
> As an old GNU project, we're required to use what the FSF prefers,
> which is on savannah. https:/
On Tue, 26 May 2020, Rob Savoye wrote:
> I processed the patch backlog for DejaGnu, and have gone through the
> bug list. It'd be nice if somebody could try master with a more complex
> environment, etc... if I'm going to push out a release. For cross
> testing all I have is a PI and QEMU.
I'l
On Tue, 26 May 2020, Rob Savoye wrote:
> > I'll run some RISC-V remote GCC/GDB testing and compare results for
> > DejaGnu 1.6/1.6.1 vs trunk. It will take several days though, as it takes
> > many hours to go through these testsuite runs.
>
> That'd be great. I'd rather push out a stable r
[cc-ing Joel as the originator, and ]
On Tue, 9 Jun 2020, Jacob Bachmeyer wrote:
> >> I ran a quick bisection and the culprit turned out to be:
> >>
> >> ba60272a5ac6f6a7012acca03f596a6ed003f044 is the first bad commit
> >> commit ba60272a5ac6f6a7012acca03f596a6ed003f044
> >> Author: Jacob Bachme
On Sun, 12 Jul 2020, Maciej W. Rozycki wrote:
> I don't think we have a way to redirect the reference to `__GI_memset'.
Additionally, I need to mention that where `libgcc.a' has been built at
`-O0', RV32 `ld.so' fails linking due to unresolved `malloc' and `free'
references from numerous `lib
On Tue, 14 Jul 2020, Richard Biener wrote:
> > > Arguably this might probably be called a deficiency in libgcc, however
> > > the objects are built with `-fexceptions -fnon-call-exceptions'
> >
> > I consider that broken. It doesn't make any sense to build a lowlevel
> > runtime library like lib
16 matches
Mail list logo
