On 12/15/20 12:58 AM, Joseph Myers wrote:
Maybe change the script to use /sourceware/snapshot-tmp/gcc (which has
rather more space) instead of /tmp?
Jakub can you please do it?
Thanks,
Martin
On Mon, 14 Dec 2020, Martin Liška wrote:
> On 12/11/20 7:26 PM, Jakub Jelinek wrote:
> > When running it manually it just completed without problems.
> > So, no idea what happened.
>
> Morning.
>
> Unfortunately, today we have similar problem. Master was bumped, but
> not any of the release bran
On Fri, 11 Dec 2020, Martin Liška wrote:
> On 12/11/20 2:17 PM, Rainer Orth wrote:
> > Rainer Orth writes:
> >
> > > I noticed that gcc/DATESTAMP isn't updated any longer after this
> > > Friday. I doubt this is intentional...
> >
> > This has happened again tonight...
> >
> > Rainer
> >
On Mon, Dec 14, 2020 at 11:02:44AM +0100, Andreas Schwab wrote:
> On Dez 14 2020, Martin Liška wrote:
>
> > On 12/11/20 7:26 PM, Jakub Jelinek wrote:
> >> When running it manually it just completed without problems.
> >> So, no idea what happened.
> >
> > Morning.
> >
> > Unfortunately, today we h
On Dez 14 2020, Martin Liška wrote:
> On 12/11/20 7:26 PM, Jakub Jelinek wrote:
>> When running it manually it just completed without problems.
>> So, no idea what happened.
>
> Morning.
>
> Unfortunately, today we have similar problem. Master was bumped, but
> not any of the release branches:
Pe
On 12/14/20 10:23 AM, Jakub Jelinek wrote:
On Mon, Dec 14, 2020 at 10:21:15AM +0100, Martin Liška wrote:
On 12/14/20 10:05 AM, Jakub Jelinek wrote:
Note, last night r11 DATESTAMP bump actually succeeded, it was the other
branches that failed.
I know.
So please try to output the script output
On Mon, Dec 14, 2020 at 10:21:15AM +0100, Martin Liška wrote:
> On 12/14/20 10:05 AM, Jakub Jelinek wrote:
> > Note, last night r11 DATESTAMP bump actually succeeded, it was the other
> > branches that failed.
>
> I know.
>
> So please try to output the script output to a log. So that we can anal
On 12/14/20 10:05 AM, Jakub Jelinek wrote:
Note, last night r11 DATESTAMP bump actually succeeded, it was the other
branches that failed.
I know.
So please try to output the script output to a log. So that we can analyze
for the next time.
Thanks,
Martin
On Mon, Dec 14, 2020 at 09:59:22AM +0100, Martin Liška wrote:
> On 12/11/20 7:26 PM, Jakub Jelinek wrote:
> > When running it manually it just completed without problems.
> > So, no idea what happened.
>
> Morning.
>
> Unfortunately, today we have similar problem. Master was bumped, but
> not any
On 12/11/20 7:26 PM, Jakub Jelinek wrote:
When running it manually it just completed without problems.
So, no idea what happened.
Morning.
Unfortunately, today we have similar problem. Master was bumped, but
not any of the release branches:
commit c5853240cdae1e727a65d1300e05307e5197bc69 (ori
On Fri, Dec 11, 2020 at 07:04:28PM +0100, Martin Liška wrote:
> On 12/11/20 2:17 PM, Rainer Orth wrote:
> > Rainer Orth writes:
> >
> > > I noticed that gcc/DATESTAMP isn't updated any longer after this
> > > Friday. I doubt this is intentional...
> >
> > This has happened again tonight...
> >
On 12/11/20 2:17 PM, Rainer Orth wrote:
Rainer Orth writes:
I noticed that gcc/DATESTAMP isn't updated any longer after this
Friday. I doubt this is intentional...
This has happened again tonight...
Rainer
Thanks for heads up. I'm aware of it and I don't see reason why (running
Rainer Orth writes:
> I noticed that gcc/DATESTAMP isn't updated any longer after this
> Friday. I doubt this is intentional...
This has happened again tonight...
Rainer
--
-
Rainer Orth, Center for Biotechno
On Tue, Nov 10, 2020 at 09:23:09AM +0100, Martin Liška wrote:
> On 11/9/20 11:09 PM, Jakub Jelinek wrote:
> > So I think either new_update must be raising an exception, or returning
> > None for some reason.
> > Bet we want to add logging for that exception, as well as for it returning
> > None and
On 11/9/20 11:09 PM, Jakub Jelinek wrote:
So I think either new_update must be raising an exception, or returning
None for some reason.
Bet we want to add logging for that exception, as well as for it returning
None and inside of it perhaps even more detailed logging on where it
returned None.
On Mon, Nov 09, 2020 at 08:57:48AM +0100, Martin Liška wrote:
> On 11/6/20 8:59 PM, Jakub Jelinek wrote:
> > I think I'll work with Martin early next week to think about further spots
> > to add logging, so we narrow down where it is still called and where it
> > isn't.
>
> Hello.
>
> I'm suggest
On 11/6/20 8:59 PM, Jakub Jelinek wrote:
I think I'll work with Martin early next week to think about further spots
to add logging, so we narrow down where it is still called and where it
isn't.
Hello.
I'm suggesting to use the following extra logging.
Martin
>From a39631f6515b60ae2a3c8de0129
Iain Sandoe via Gcc wrote:
Jakub Jelinek via Gcc wrote:
On Fri, Nov 06, 2020 at 08:56:25PM +0100, Richard Biener wrote:
Darwin: Darwin 20 is to be macOS 11 (Big Sur).
So, I'm afraid it must fail or bypass this code path somewhere earlier
in the hooks.
Is that maybe already known to the r
Jakub Jelinek via Gcc wrote:
On Fri, Nov 06, 2020 at 08:56:25PM +0100, Richard Biener wrote:
Darwin: Darwin 20 is to be macOS 11 (Big Sur).
So, I'm afraid it must fail or bypass this code path somewhere earlier
in the hooks.
Is that maybe already known to the repo when it is on some rebase
On Fri, Nov 06, 2020 at 08:56:25PM +0100, Richard Biener wrote:
> >Darwin: Darwin 20 is to be macOS 11 (Big Sur).
> >So, I'm afraid it must fail or bypass this code path somewhere earlier
> >in the hooks.
>
> Is that maybe already known to the repo when it is on some rebased user
> branch?
I
On November 6, 2020 8:45:55 PM GMT+01:00, Jakub Jelinek via Gcc
wrote:
>On Tue, Nov 03, 2020 at 06:26:58PM +, Joseph Myers wrote:
>> On Mon, 2 Nov 2020, Jakub Jelinek via Gcc wrote:
>>
>> > It isn't that easy (because update_version_git checks the gcc trunk
>and
>> > so I had to insert a sh
On Tue, Nov 03, 2020 at 06:26:58PM +, Joseph Myers wrote:
> On Mon, 2 Nov 2020, Jakub Jelinek via Gcc wrote:
>
> > It isn't that easy (because update_version_git checks the gcc trunk and
> > so I had to insert a sh invocation in which I've tweaked it), but it worked,
> > thanks. But something
On Mon, 2 Nov 2020, Jakub Jelinek via Gcc wrote:
> It isn't that easy (because update_version_git checks the gcc trunk and
> so I had to insert a sh invocation in which I've tweaked it), but it worked,
> thanks. But something is really wrong with the hooks, as the gcc-cvs mail
> for the trunk dai
On Mon, Nov 02, 2020 at 09:37:56PM +0100, Martin Liška wrote:
> > writing to ./gcc/testsuite/ChangeLog
> > empty group "()" found:"* tree-vect-slp.c (): Update backedges in
> > single-node cycles."
> > Traceback (most recent call last):
> >File "../gcc-changelog/git_update_version.py", lin
On 11/2/20 8:43 PM, Jakub Jelinek wrote:
On Mon, Nov 02, 2020 at 08:14:22PM +0100, Rainer Orth wrote:
I noticed that gcc/DATESTAMP isn't updated any longer after this
Friday. I doubt this is intentional...
=== Working on: master ===
branch pulled and checked out
74 revisions since last Daily
On Mon, Nov 02, 2020 at 08:14:22PM +0100, Rainer Orth wrote:
> I noticed that gcc/DATESTAMP isn't updated any longer after this
> Friday. I doubt this is intentional...
=== Working on: master ===
branch pulled and checked out
74 revisions since last Daily bump
writing to ./libstdc++-v3/ChangeLog
26 matches
Mail list logo
