On 5/28/14, 2:43 PM, Tom Lane wrote:
> Peter Eisentraut writes:
>> What they want is that you use
>> %name-prefix "base_yy"
>> instead of
>> %name-prefix="base_yy"
>> That makes the warning go away.
>
> Oh really!?
>
>> The %something=something syntax is not documented anywhere, so it lo
Peter Eisentraut writes:
> What they want is that you use
> %name-prefix "base_yy"
> instead of
> %name-prefix="base_yy"
> That makes the warning go away.
Oh really!?
> The %something=something syntax is not documented anywhere, so it looks
> like it worked more or less by accident. We
On 5/21/14, 12:29 PM, Tom Lane wrote:
> Vik Fearing writes:
>> I'm getting some more of these, including some I thought you had fixed.
>> Bison 3.0.2 on current head.
>
> I didn't do anything to suppress those warnings:
>
>> gram.y:172.1-13: warning: deprecated directive, use ‘%name-prefix’
Vik Fearing writes:
> On 05/21/2014 12:29 PM, Tom Lane wrote:
>> I didn't do anything to suppress those warnings:
>>> gram.y:172.1-13: warning: deprecated directive, use â%name-prefixâ
>>> [-Wdeprecated]
>>> %name-prefix="base_yy"
>>> ^
>> because it's hard to see how that's anythi
On 05/21/2014 12:29 PM, Tom Lane wrote:
> Vik Fearing writes:
>> I'm getting some more of these, including some I thought you had fixed.
>> Bison 3.0.2 on current head.
> I didn't do anything to suppress those warnings:
>
>> gram.y:172.1-13: warning: deprecated directive, use ‘%name-prefix’
>> [-W
Vik Fearing writes:
> I'm getting some more of these, including some I thought you had fixed.
> Bison 3.0.2 on current head.
I didn't do anything to suppress those warnings:
> gram.y:172.1-13: warning: deprecated directive, use â%name-prefixâ
> [-Wdeprecated]
> %name-prefix="base_yy"
> ^^^
I'm getting some more of these, including some I thought you had fixed.
Bison 3.0.2 on current head.
<>
Writing postgres.bki
Writing schemapg.h
Writing postgres.description
Writing postgres.shdescription
gram.y:172.1-13: warning: deprecated directive, use ‘%name-prefix’
[-Wdeprecated]
%name-pre
Andres Freund writes:
> On 2013-07-29 08:02:49 -0400, Tom Lane wrote:
>>> It looks like our choices are (1) teach configure to enable
>>> -fno-aggressive-loop-optimizations if the compiler recognizes it,
>>> or (2) back-port commit 8137f2c32322c624e0431fac1621e8e9315202f9.
>>>
>>> I am in favor o
On 2013-07-29 08:02:49 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-07-29 07:11:13 -0400, Stephen Frost wrote:
> >> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >>> The bottom line was:
> >>> It looks like our choices are (1) teach configure to enable
> >>> -fno-aggressive-loop-optimizat
On Tue, Jul 30, 2013 at 3:56 AM, Noah Misch wrote:
> Agreed. Let's stick an "Updates OS packages daily, regularly acquiring
> bleeding-edge upstream releases" note on the buildfarm status page
FWIW, I added "[updated daily]" to the OS version field.
I haven't changed other configuration yet, wi
On Mon, Jul 29, 2013 at 11:05:52AM -0400, Tom Lane wrote:
> Andrew Dunstan writes:
> > On 07/29/2013 10:28 AM, Marti Raudsepp wrote:
> >> Hmm? Anchovy is upgrading automatically to newest Arch Linux packages
> >> daily.
> >> I assumed that's a good thing -- the purpose of build farm is to test
>
* Andrew Dunstan wrote:
I'm toying with the idea of a check_upgrade mode for the buildfarm
client where it wouldn't do a git pull, but would report changes if the
build result was different from the previous result. You'd run this
immediately after pulling new changes into your OS. Other, bright
On Mon, Jul 29, 2013 at 11:45 AM, Andrew Dunstan wrote:
>
> On 07/29/2013 02:26 PM, Marti Raudsepp wrote:
>>>
>>> I'm toying with the idea of a check_upgrade mode for the buildfarm client
>>> where it wouldn't do a git pull, but would report changes if the build
>>> result was different from the p
On Mon, Jul 29, 2013 at 4:05 PM, Tom Lane wrote:
> I can see both sides of this. It's definitely nice to get early warning
> when toolchain changes create new problems for Postgres, but it's not
> clear that the buildfarm is the best way to get such notifications.
Perhaps something as simple as
On 07/29/2013 02:26 PM, Marti Raudsepp wrote:
I'm toying with the idea of a check_upgrade mode for the buildfarm client
where it wouldn't do a git pull, but would report changes if the build
result was different from the previous result. You'd run this immediately
after pulling new changes into
On Mon, Jul 29, 2013 at 9:15 PM, Andrew Dunstan wrote:
> There has to be something between "set in stone and never changes" and
> "auto-updates everything every 24 hours" that would suit us.
Well sure I could change the update frequency. But again, it seems
like delaying the inevitable.
> I'm to
On 07/29/2013 11:05 AM, Tom Lane wrote:
Andrew Dunstan writes:
On 07/29/2013 10:28 AM, Marti Raudsepp wrote:
Hmm? Anchovy is upgrading automatically to newest Arch Linux packages daily.
I assumed that's a good thing -- the purpose of build farm is to test
PostgreSQL in various different real-
On Mon, Jul 29, 2013 at 5:53 PM, Andres Freund wrote:
> Both the
> gcc 4.8 and the bison 3.0 problems are things the project needs to know
> about
Perl 5.18 too:
http://www.postgresql.org/message-id/2825.1370226...@sss.pgh.pa.us
Marti
--
Sent via pgsql-hackers mailing list (pgsql-hackers@pos
Andrew Dunstan writes:
> On 07/29/2013 10:28 AM, Marti Raudsepp wrote:
>> Hmm? Anchovy is upgrading automatically to newest Arch Linux packages daily.
>> I assumed that's a good thing -- the purpose of build farm is to test
>> PostgreSQL in various different real-life environments? Arch Linux is
>
On 2013-07-29 10:52:10 -0400, Tom Lane wrote:
> Andres Freund writes:
> > FWIW cherry-picking bf66bfb4cd726b6ddab3fe2718648f65a7106149 and
> > e58f3181fdaacc91d4cc1bd98a4a8ad7d286544c fixes the issue for me
> > (After fixing trivial conflicts in the latter).
>
> I've already spent more time on th
On 2013-07-29 10:46:41 -0400, Andrew Dunstan wrote:
>
> On 07/29/2013 10:28 AM, Marti Raudsepp wrote:
> >Hi,
> >
> >>On 07/29/2013 01:05 AM, Tom Lane wrote:
> >>>Buildfarm member anchovy has been failing for the last couple of days,
> >>>evidently because its owner just couldn't wait to adopt biso
Andres Freund writes:
> FWIW cherry-picking bf66bfb4cd726b6ddab3fe2718648f65a7106149 and
> e58f3181fdaacc91d4cc1bd98a4a8ad7d286544c fixes the issue for me
> (After fixing trivial conflicts in the latter).
I've already spent more time on this than I wanted to, but just for
the archives' sake: neit
On 07/29/2013 10:28 AM, Marti Raudsepp wrote:
Hi,
On 07/29/2013 01:05 AM, Tom Lane wrote:
Buildfarm member anchovy has been failing for the last couple of days,
evidently because its owner just couldn't wait to adopt bison 3.0,
which is all of 3 days old.
Hmm? Anchovy is upgrading automatica
Hi,
> On 07/29/2013 01:05 AM, Tom Lane wrote:
>> Buildfarm member anchovy has been failing for the last couple of days,
>> evidently because its owner just couldn't wait to adopt bison 3.0,
>> which is all of 3 days old.
Hmm? Anchovy is upgrading automatically to newest Arch Linux packages daily.
On 2013-07-29 08:44:56 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-07-29 08:17:46 -0400, Tom Lane wrote:
> >> I'm not excited about breaking code in order to fix optimization bugs
> >> that are purely hypothetical (and for which there's no particular reason
> >> to believe that the
On 07/29/2013 01:05 AM, Tom Lane wrote:
Buildfarm member anchovy has been failing for the last couple of days,
evidently because its owner just couldn't wait to adopt bison 3.0,
which is all of 3 days old. The failures look like
Reminder to buildfarm animal owners: if you upgrade software pl
Andres Freund writes:
> On 2013-07-29 08:17:46 -0400, Tom Lane wrote:
>> I'm not excited about breaking code in order to fix optimization bugs
>> that are purely hypothetical (and for which there's no particular reason
>> to believe that the proposed change would fix them anyway). If we were
>> s
On 2013-07-29 08:17:46 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-07-29 08:02:49 -0400, Tom Lane wrote:
> >> If we turn off the optimization, that will fix any other cases as well,
> >> no? So why would we risk breaking third-party code by back-porting the
> >> struct declaration
Andres Freund writes:
> On 2013-07-29 08:02:49 -0400, Tom Lane wrote:
>> If we turn off the optimization, that will fix any other cases as well,
>> no? So why would we risk breaking third-party code by back-porting the
>> struct declaration changes?
> The -fno-agressive-loop thingie afaics only
On 2013-07-29 08:02:49 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-07-29 07:11:13 -0400, Stephen Frost wrote:
> >> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >>> The bottom line was:
> >>> It looks like our choices are (1) teach configure to enable
> >>> -fno-aggressive-loop-optimizat
Andres Freund writes:
> On 2013-07-29 07:11:13 -0400, Stephen Frost wrote:
>> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>>> The bottom line was:
>>> It looks like our choices are (1) teach configure to enable
>>> -fno-aggressive-loop-optimizations if the compiler recognizes it,
>>> or (2) back-port c
On 2013-07-29 07:11:13 -0400, Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > Stephen Frost writes:
> > > However, I comment on this mainly because anchovy has had issues with
> > > 9.1 and older for some time, which looks like an issue with GCC 4.8.0.
> > > Did you happen to res
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > However, I comment on this mainly because anchovy has had issues with
> > 9.1 and older for some time, which looks like an issue with GCC 4.8.0.
> > Did you happen to resolve or identify what is happening there..?
>
> Yeah, we kno
Stephen Frost writes:
> However, I comment on this mainly because anchovy has had issues with
> 9.1 and older for some time, which looks like an issue with GCC 4.8.0.
> Did you happen to resolve or identify what is happening there..?
Yeah, we know about that:
http://www.postgresql.org/message-id/
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Buildfarm member anchovy has been failing for the last couple of days,
[...]
> I'm thinking we should apply this to all supported branches, in case
> somebody gets the idea to build an older branch with bleeding-edge
> tools. Any objections?
Certainl
Buildfarm member anchovy has been failing for the last couple of days,
evidently because its owner just couldn't wait to adopt bison 3.0,
which is all of 3 days old. The failures look like
cubeparse.y:42.1-13: warning: deprecated directive, use '%name-prefix'
[-Wdeprecated]
%name-prefix="cube_y
36 matches
Mail list logo
