On Sat, Jan 22, 2022 at 02:24:51AM +0100, Marc Espie wrote:
> Or we can automate this with something like this:
I have updated Devel::PPPort in base and it works for me. Two ports
have ppport.h in a different location. There this diff has no
effect. All other ports in my test setup work fine wi
On Tue, Feb 08, 2022 at 01:59:51PM +, Stuart Henderson wrote:
> > > I think we should start updating Devel::PPPort in base. Then we
> > > can regenerate other ppport.h in base and ports. Note that some ports
> > > need newer Devel::PPPort than we have now. So updating seems
> > > unavoidable
> > I think we should start updating Devel::PPPort in base. Then we
> > can regenerate other ppport.h in base and ports. Note that some ports
> > need newer Devel::PPPort than we have now. So updating seems
> > unavoidable.
I do worry a bit that if we regenerate in ports, that some ports might
On Mon, Feb 07, 2022 at 08:11:55PM +0100, Alexander Bluhm wrote:
> On Tue, Jan 25, 2022 at 12:26:05PM -0800, Andrew Hewus Fresh wrote:
> > On Tue, Jan 25, 2022 at 09:20:55PM +0100, Alexander Bluhm wrote:
> > > On Tue, Jan 25, 2022 at 12:05:48PM -0800, Andrew Hewus Fresh wrote:
> > > > On Tue, Jan 2
On Tue, Jan 25, 2022 at 12:26:05PM -0800, Andrew Hewus Fresh wrote:
> On Tue, Jan 25, 2022 at 09:20:55PM +0100, Alexander Bluhm wrote:
> > On Tue, Jan 25, 2022 at 12:05:48PM -0800, Andrew Hewus Fresh wrote:
> > > On Tue, Jan 25, 2022 at 06:45:12PM +0100, Alexander Bluhm wrote:
> > > > On Tue, Jan 2
On Tue, Jan 25, 2022 at 09:20:55PM +0100, Alexander Bluhm wrote:
> Plans for new Perl are good to hear. Thanks for updating it regualry.
One thing that's blocking me on that is the "vendorlib" patch over on
tech@[1] and the related patch on ports@[2]. I think it's a good idea,
but haven't gotten
On Tue, Jan 25, 2022 at 09:20:55PM +0100, Alexander Bluhm wrote:
> On Tue, Jan 25, 2022 at 12:05:48PM -0800, Andrew Hewus Fresh wrote:
> > On Tue, Jan 25, 2022 at 06:45:12PM +0100, Alexander Bluhm wrote:
> > > On Tue, Jan 25, 2022 at 05:13:01PM +0100, Alexander Bluhm wrote:
> > > > On Sat, Jan 22,
On Tue, Jan 25, 2022 at 12:05:48PM -0800, Andrew Hewus Fresh wrote:
> On Tue, Jan 25, 2022 at 06:45:12PM +0100, Alexander Bluhm wrote:
> > On Tue, Jan 25, 2022 at 05:13:01PM +0100, Alexander Bluhm wrote:
> > > On Sat, Jan 22, 2022 at 02:24:51AM +0100, Marc Espie wrote:
> > > > Or we can automate th
On Tue, Jan 25, 2022 at 06:45:12PM +0100, Alexander Bluhm wrote:
> On Tue, Jan 25, 2022 at 05:13:01PM +0100, Alexander Bluhm wrote:
> > On Sat, Jan 22, 2022 at 02:24:51AM +0100, Marc Espie wrote:
> > > Or we can automate this with something like this:
> > >
> Our Devel::PPPort is too old. We sh
On Tue, Jan 25, 2022 at 05:13:01PM +0100, Alexander Bluhm wrote:
> On Sat, Jan 22, 2022 at 02:24:51AM +0100, Marc Espie wrote:
> > Or we can automate this with something like this:
> >
> > Index: perl.port.mk
> > ===
> > RCS file: /cv
On Sat, Jan 22, 2022 at 02:24:51AM +0100, Marc Espie wrote:
> Or we can automate this with something like this:
>
> Index: perl.port.mk
> ===
> RCS file: /cvs/ports/infrastructure/mk/perl.port.mk,v
> retrieving revision 1.32
> diff -u
On Sat, Jan 22, 2022 at 02:24:51AM +0100, Marc Espie wrote:
> Or we can automate this with something like this:
I didn't try this, but it seems OK to me. I'll leave the final OK to
sthen though as I would think it most likely to break things for him.
(AFAIU new versions are not supposed to cause
Or we can automate this with something like this:
Index: perl.port.mk
===
RCS file: /cvs/ports/infrastructure/mk/perl.port.mk,v
retrieving revision 1.32
diff -u -p -r1.32 perl.port.mk
--- perl.port.mk12 Dec 2021 19:25:39 -
btw, bumping the library version for libperl is a safer way of triggering
those updates than revision bumps; the latter are subject to a build
timing problem, you have to hope that the ports build machines are
running a version of base built with the updated perl.
On 2022/01/21 18:27, Alexander Bl
On Fri, Jan 21, 2022 at 08:39:34AM -0800, Andrew Hewus Fresh wrote:
> On Fri, Jan 21, 2022 at 04:34:13PM +0100, Marc Espie wrote:
> > So I don't really think perl requires any change.
> >
> > Possibly hacking a bit on ports that use an outdated version of ppport.h
>
> Updating ppport.h seems reaso
On Fri, Jan 21, 2022 at 04:34:13PM +0100, Marc Espie wrote:
> On Fri, Jan 21, 2022 at 02:12:25PM +0100, Alexander Bluhm wrote:
> > Hi,
> >
> > Since clang 13 each Perl or Perl XS module compile spits out a lot
> > of -Wcompound-token-split-by-macro warnings. E.g. p5-Net-SSLeay
> > produces 3882 w
On Fri, Jan 21, 2022 at 02:12:25PM +0100, Alexander Bluhm wrote:
> Hi,
>
> Since clang 13 each Perl or Perl XS module compile spits out a lot
> of -Wcompound-token-split-by-macro warnings. E.g. p5-Net-SSLeay
> produces 3882 warnings generated. You cannot spot anything useful.
> The problem is bu
This change would require a revision bump for all Perl XS ports
Otherwise loading the .so module fails.
$ perl -MNet::SSLeay
SSLeay.c: loadable library and perl binaries are mismatched (got handshake key
0xec0, needed 0xf00)
On Fri, Jan 21, 2022 at 02:12:25P
Hi,
Since clang 13 each Perl or Perl XS module compile spits out a lot
of -Wcompound-token-split-by-macro warnings. E.g. p5-Net-SSLeay
produces 3882 warnings generated. You cannot spot anything useful.
The problem is burried deeply in the Perl macros and copied to
everywhere.
If we compile Perl
19 matches
Mail list logo
