On Mon, 06 Dec 2021 17:59:05 +0100, Jeremie Courreges-Anglas wrote:
> Without looking at the possible fixes I think we should annotate why we
> disabled libtextstyle. ok?
OK millert@
- todd
On Mon, May 17 2021, Todd C. Miller wrote:
> On Mon, 17 May 2021 07:56:22 -0600, "Todd C. Miller" wrote:
>
>> The crash does not happen when I build cbmc manually (outside of
>> ports), only when I build it from within the ports tree.
>
> The crash only happens when output is to a terminal but TER
On Fri, 10 Sep 2021 09:36:50 -0600, "Todd C. Miller" wrote:
> This cannot go in until post-7.0 due to a change where bison 3.8
> now declares yyerror for POSIX compatibility as:
>
> void yyerror(const char *msg);
>
> This may conflict with yyerror() as defined by the .y file, leading
> to buil
This cannot go in until post-7.0 due to a change where bison 3.8
now declares yyerror for POSIX compatibility as:
void yyerror(const char *msg);
This may conflict with yyerror() as defined by the .y file, leading
to build errors. For example, old code may return int instead of
void or declar
On Sun, Jun 06, 2021 at 04:09:09PM -0600, Todd C. Miller wrote:
> On Sun, 06 Jun 2021 21:56:40 +0200, Theo Buehler wrote:
>
> > On Wed, Apr 28, 2021 at 07:21:44PM -0600, Todd C. Miller wrote:
> > > Another port I'd like to update needs a newer version of bison that
> > > we provide so I've updated
On Sun, 06 Jun 2021 21:56:40 +0200, Theo Buehler wrote:
> On Wed, Apr 28, 2021 at 07:21:44PM -0600, Todd C. Miller wrote:
> > Another port I'd like to update needs a newer version of bison that
> > we provide so I've updated to the lastest version.
>
> The bison update broke the build of graphics/
On Wed, Apr 28, 2021 at 07:21:44PM -0600, Todd C. Miller wrote:
> Another port I'd like to update needs a newer version of bison that
> we provide so I've updated to the lastest version.
The bison update broke the build of graphics/cfdg on sparc64 and thus
likely on all other base-gcc arches.
The
On Mon, 17 May 2021 07:56:22 -0600, "Todd C. Miller" wrote:
> The crash does not happen when I build cbmc manually (outside of
> ports), only when I build it from within the ports tree.
The crash only happens when output is to a terminal but TERM is
unset or is set to a value not present in the t
On Tue, 11 May 2021 23:10:31 +0200, Christian Weisgerber wrote:
> Stuart Henderson:
>
> > Updated diff below, there were some missing library deps and I've enabled
> > building a debug package. My build is still running, so far I've run
> > into errors in these which seem related:
> >
> > - devel
I believe all the neccesary changes are now committed to build
things with bison 3.7.x.
- todd
On Wed, 12 May 2021 16:53:36 +0200, Christian Weisgerber wrote:
> I'm unable to reproduce this on amd64 or i386. bison runs successfully
> and provides a litany of warnings that are colorized when the output
> goes to a tty.
Interesting, I wonder what difference in the environment causes this.
I
Todd C. Miller:
> That's odd, I was just now able to reproduce it on amd64 without
> any difficulty:
>
> bison -y -v $flags -pyyansi_c --defines=ansi_c_y.tab.h parser.y -o
> ansi_c_y.tab.cpp
> parser.y:36.22-27: warning: POSIX Yacc does not support string literals [
>
> at which point it dumps
On Tue, 11 May 2021 23:52:01 +0200, Christian Weisgerber wrote:
> No, I dropped the --without-libtextstyle-prefix for testing purposes
> and the bison executable is linked with libtextstyle.so.0.1. I can't
> reproduce the segfault.
That's odd, I was just now able to reproduce it on amd64 without
Todd C. Miller:
> > > - devel/cbmc: repeatable bison segfault, seems related to
> > > curses/libtextstyle.
> > I can't reproduce this on amd64.
>
> That's because I disabled use of libtextstyle in later bison diffs :-)
No, I dropped the --without-libtextstyle-prefix for testing purposes
and the
Todd disabled textstyle support in later diffs which sidestepped this
--
Sent from a phone, apologies for poor formatting.
On 11 May 2021 22:15:32 Christian Weisgerber wrote:
Stuart Henderson:
Updated diff below, there were some missing library deps and I've enabled
building a debug package
On Tue, 11 May 2021 23:10:31 +0200, Christian Weisgerber wrote:
> Stuart Henderson:
>
> > Updated diff below, there were some missing library deps and I've enabled
> > building a debug package. My build is still running, so far I've run
> > into errors in these which seem related:
> >
> > - devel
Stuart Henderson:
> Updated diff below, there were some missing library deps and I've enabled
> building a debug package. My build is still running, so far I've run
> into errors in these which seem related:
>
> - devel/cbmc: repeatable bison segfault, seems related to curses/libtextstyle.
I can
On Tue, 11 May 2021 20:25:20 +0200, Christian Weisgerber wrote:
> bison.info incorporates bison.help, which is regenerated from the
> newly built bison executable. We need to break that dependency.
Right, I wasn't sure that it was OK to do that.
> That's simple enough that we can do it in Makef
Christian Weisgerber:
> > > Hmm, why does bison.info get rebuilt anyway? GNU software ships
> > > with a pre-built .info file included. Maybe we can just disable
> > > the regeneration?
> >
> > I was unsuccessful in doing that, though I'm sure someone with more
> > automake knowledge could. Ju
Todd C. Miller:
> > Hmm, why does bison.info get rebuilt anyway? GNU software ships
> > with a pre-built .info file included. Maybe we can just disable
> > the regeneration?
>
> I was unsuccessful in doing that, though I'm sure someone with more
> automake knowledge could. Just touching the ap
On Sun, 09 May 2021 12:01:08 +0100, Stuart Henderson wrote:
> > net/olsrd,-gui
> - https://github.com/OLSR/olsrd/pull/87
Fixed by the following. Not sure if bumping REVISION for both is
necessary.
- todd
Index: net/olsrd/Makefile
===
On Sun, 09 May 2021 12:01:08 +0100, Stuart Henderson wrote:
> > lang/verilator
> - probably just wants updating, there are several commits in
> https://github.com/verilator/verilator/search?q=bison&type=commits
There's a simple upstream fix for this.
- todd
Index: lang/verilator/Makefile
=
On Sun, 09 May 2021 13:57:25 +0200, Marc Espie wrote:
> I'm pretty sure splint is dead.
>
> we're talking about a year of breakage with no-one giving a fuck.
I've made a PR to fix this upstream, we'll see if anyone is there...
https://github.com/splintchecker/splint/pull/26
- todd
On 2021/05/09 07:21, Todd C. Miller wrote:
> On Sun, 09 May 2021 12:01:08 +0100, Stuart Henderson wrote:
>
> > Your fix is ok:
> > > devel/cbmc
> >
> > Fixing/Fixed:
> > > x11/qt5/qtwebkit (committed)
> > > devel/electron (testing)
>
> Thanks!
>
> > Remaining:
> >
> > > devel/spl
On Fri, 30 Apr 2021 22:22:36 +0200, Christian Weisgerber wrote:
> Hmm, why does bison.info get rebuilt anyway? GNU software ships
> with a pre-built .info file included. Maybe we can just disable
> the regeneration?
I was unsuccessful in doing that, though I'm sure someone with more
automake kn
On Sun, 09 May 2021 12:01:08 +0100, Stuart Henderson wrote:
> Your fix is ok:
> > devel/cbmc
>
> Fixing/Fixed:
> > x11/qt5/qtwebkit (committed)
> > devel/electron (testing)
Thanks!
> Remaining:
>
> > devel/splint
> seems still broken upstream;
> https://github.com/splintchecker/s
On Sun, May 09, 2021 at 12:01:08PM +0100, Stuart Henderson wrote:
> > devel/splint
> seems still broken upstream;
> https://github.com/splintchecker/splint/issues/20
I'm pretty sure splint is dead.
we're talking about a year of breakage with no-one giving a fuck.
On 2021/05/01 09:40, Stuart Henderson wrote:
> On 2021/04/30 13:08, Todd C. Miller wrote:
> > On Fri, 30 Apr 2021 08:42:03 -0600, "Todd C. Miller" wrote:
> >
> > > This is due to a change in bison where it now includes the generated
> > > header file. Using --defines=foo.h instead of just -d fixe
On 2021/04/30 13:08, Todd C. Miller wrote:
> On Fri, 30 Apr 2021 08:42:03 -0600, "Todd C. Miller" wrote:
>
> > This is due to a change in bison where it now includes the generated
> > header file. Using --defines=foo.h instead of just -d fixes that
> > problem, though you'd also need to comment o
"Todd C. Miller":
> Another port I'd like to update needs a newer version of bison that
> we provide so I've updated to the lastest version.
>
> The only problem I encountered is that makeinfo in base is old and
> doesn't understand some of these new-fangled directives. They
> appear to just be
On Fri, 30 Apr 2021 08:42:03 -0600, "Todd C. Miller" wrote:
> This is due to a change in bison where it now includes the generated
> header file. Using --defines=foo.h instead of just -d fixes that
> problem, though you'd also need to comment out the bit that used
> to move the header file around
On Fri, 30 Apr 2021 11:09:23 +0100, Stuart Henderson wrote:
> - devel/cbmc: repeatable bison segfault, seems related to curses/libtextstyle
> .
>
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0 0x0296d2c05573 in delay_output (ms=54) at /src/checkout/openbsd-src-c
> vs/lib/l
On 2021/04/28 19:21, Todd C. Miller wrote:
> Another port I'd like to update needs a newer version of bison that
> we provide so I've updated to the lastest version.
>
> The only problem I encountered is that makeinfo in base is old and
> doesn't understand some of these new-fangled directives. T
On Thu, Apr 29, 2021 at 09:44:31AM +0200, Marc Espie wrote:
> On Thu, Apr 29, 2021 at 08:30:40AM +0100, Stuart Henderson wrote:
> > I don't say it often as it usually makes sense to do a targetted build
> > instead, but this could do with a test in bulk. I'll run one on i386, it
> > will take a few
On Thu, Apr 29, 2021 at 08:30:40AM +0100, Stuart Henderson wrote:
> I don't say it often as it usually makes sense to do a targetted build
> instead, but this could do with a test in bulk. I'll run one on i386, it
> will take a few days.
>
> I've tried updating bison past 3.4 before but bailed for
I don't say it often as it usually makes sense to do a targetted build
instead, but this could do with a test in bulk. I'll run one on i386, it
will take a few days.
I've tried updating bison past 3.4 before but bailed for some reason, it
might have been a problem with some port using it, or i
Another port I'd like to update needs a newer version of bison that
we provide so I've updated to the lastest version.
The only problem I encountered is that makeinfo in base is old and
doesn't understand some of these new-fangled directives. They
appear to just be cosmetic anyway.
- todd
Inde
Rafael Sadowski:
> Straightforward update to the latest stable version.
> I don't know if this is supposed to go in before 6.4. To many consumers
> so I think someone should put that in a bulk build.
>
> -DISTNAME=bison-3.0.5
> +DISTNAME=bison-3.1
No problems in an amd64 bulk build.
--
Straightforward update to the latest stable version.
Test results:
492 tests were successful.
23 tests were skipped.
I don't know if this is supposed to go in before 6.4. To many consumers
so I think someone should put that in a bulk build.
Best regards,
Rafael
Index: Makefile
===
On 2015/04/25 19:53, Ingo Feinerer wrote:
> Update of devel/bison to 3.0.4
http://marc.info/?l=openbsd-ports&m=141458551032391&w=2
http://marc.info/?l=openbsd-ports&m=139523796003321&w=2
http://marc.info/?l=openbsd-ports&m=135064096202325&w=2
http://marc.info/?l=openbsd-ports&m=135088177109860&w=2
Update of devel/bison to 3.0.4
(another update in my journey to have a recent math/octave):
- Removal of all patches
(patch-configure can probably disappear but please double check
patch-data_m4sugar_m4sugar_m4 and patch-src_output_c)
- configure checks for Java and cannot be disabled via a sw
On Fri, Oct 19, 2012 at 09:33:23AM +0200, Landry Breuil wrote:
> On Thu, Oct 18, 2012 at 06:50:09PM -0400, Brad Smith wrote:
> > On Thu, Oct 18, 2012 at 05:26:54PM -0500, Amit Kulkarni wrote:
> > > 1) patch-configure is not needed as configure contains
> > > LT{LIBINTL,LIBLIBICONV} in theere. upst
On 2012/10/19 09:33, Landry Breuil wrote:
> On Thu, Oct 18, 2012 at 06:50:09PM -0400, Brad Smith wrote:
> > On Thu, Oct 18, 2012 at 05:26:54PM -0500, Amit Kulkarni wrote:
> > > 1) patch-configure is not needed as configure contains
> > > LT{LIBINTL,LIBLIBICONV} in theere. upstream seems to have ta
On Thu, Oct 18, 2012 at 06:50:09PM -0400, Brad Smith wrote:
> On Thu, Oct 18, 2012 at 05:26:54PM -0500, Amit Kulkarni wrote:
> > 1) patch-configure is not needed as configure contains
> > LT{LIBINTL,LIBLIBICONV} in theere. upstream seems to have taken care of
> > this. i might be wrong here. plea
On Thu, Oct 18, 2012 at 5:50 PM, Brad Smith wrote:
> On Thu, Oct 18, 2012 at 05:26:54PM -0500, Amit Kulkarni wrote:
>> 1) patch-configure is not needed as configure contains
>> LT{LIBINTL,LIBLIBICONV} in theere. upstream seems to have taken care of
>> this. i might be wrong here. please review
>
On Thu, Oct 18, 2012 at 05:26:54PM -0500, Amit Kulkarni wrote:
> 1) patch-configure is not needed as configure contains
> LT{LIBINTL,LIBLIBICONV} in theere. upstream seems to have taken care of this.
> i might be wrong here. please review
> 2) patch-src_output_c is partly modified. the later part
1) patch-configure is not needed as configure contains LT{LIBINTL,LIBLIBICONV}
in theere. upstream seems to have taken care of this. i might be wrong here.
please review
2) patch-src_output_c is partly modified. the later part of this patch needs
review.
per landry@ new x11/qgis needs newer bis
This is based on what Rui Reis submitted here earlier this month.
I'm currently running a full package build with this on i386.
Overriding the GNU m4 check and substituting our m4 will cause the
regression tests to blow up. I haven't looked further into this.
Index: Makefile
On Sun, 9 Oct 2005 00:04:19 +0200
Marc Espie <[EMAIL PROTECTED]> wrote:
> On Sat, Oct 08, 2005 at 10:19:28PM +0100, Rui Reis wrote:
> > The following diff updates the old bison port to 2.1.
> > http://www.openbsd-pt.com/ports/bison-08102005.diff
> >
> > It works fine for me on i386 and sparc.
> >
On Sat, Oct 08, 2005 at 10:19:28PM +0100, Rui Reis wrote:
> The following diff updates the old bison port to 2.1.
> http://www.openbsd-pt.com/ports/bison-08102005.diff
>
> It works fine for me on i386 and sparc.
>
> please test and comment.
> Rui Reis
When I look at our ports INDEX, I see ~50 po
The following diff updates the old bison port to 2.1.
http://www.openbsd-pt.com/ports/bison-08102005.diff
It works fine for me on i386 and sparc.
please test and comment.
Rui Reis
51 matches
Mail list logo