Hi,
I just thought that using "CONFIGURE_STYLE = autoreconf" rather than 'autoconf'
and adding "AUTORECONF = ./autogen.sh" could remove 'do-gen:' block,
like textproc/liblrdf.
I don't think "MODULES = lang/python" is not required.
And adding 'CONFIGURE_ENV += LIBS="-lc++ -lc++abi -lpthread"' coul
On 2021/10/30 14:09, Landry Breuil wrote:
> I've tried various things in our Makefile.inc, but using LDFLAGS_NODIST
> / CFLAGS_NODIST generally ends up with a broken libintl/textdomain
> detection, so i went with a patch that is similar to the freebsd one so
> that LDFLAGS/paths dont leak to _sysco
k...@intricatesoftware.com:
> The FreeBSD folks did an in-depth analysis of why jdk
> 1.8 and 11 fail to build with llvm13. You can read about
> it here:
>
> https://github.com/freebsd/freebsd-ports/commit/3822416493c
Tagged pointers strike again!
> I don't have an llvm13 system setup yet so I'
On 2021/10/30 14:25, Nam Nguyen wrote:
> Here is a diff incorporating sthen@'s feedback and tj@'s feedback to add
> a comment about mirroring.
>
> Stuart Henderson writes:
>
> > On 2021/10/28 22:36, Nam Nguyen wrote:
> >> I prepared a release tarball from a checkout:
> >> install groff for tbl an
Here is a diff incorporating sthen@'s feedback and tj@'s feedback to add
a comment about mirroring.
Stuart Henderson writes:
> On 2021/10/28 22:36, Nam Nguyen wrote:
>> I prepared a release tarball from a checkout:
>> install groff for tbl and nroff
>> install autoconf-archive, autoconf and autom
On 2021/10/30 23:00, Omar Polo wrote:
> Stuart Henderson writes:
>
> > On 2021/10/30 20:26, Omar Polo wrote:
> >> Hello ports,
> >>
> >> Here's another attempt at updating devel/scons. The third time is the
> >> charm, right? :D
> >>
> >> Attaching:
> >>
> >> - a tarball for a "new" devel/sc
Unfortunately I don't have the time/interest to maintain this package
any longer. Attached is a diff to remove me as maintainer.
Thanks.
Index: sysutils/glances//Makefile
===
RCS file: /cvs/ports/sysutils/glances/Makefile,v
retrievin
Stuart Henderson writes:
> On 2021/10/30 20:26, Omar Polo wrote:
>> Hello ports,
>>
>> Here's another attempt at updating devel/scons. The third time is the
>> charm, right? :D
>>
>> Attaching:
>>
>> - a tarball for a "new" devel/scons2: it's the current scons ports with
>>REVISION and M
On 2021/10/30 20:26, Omar Polo wrote:
> Hello ports,
>
> Here's another attempt at updating devel/scons. The third time is the
> charm, right? :D
>
> Attaching:
>
> - a tarball for a "new" devel/scons2: it's the current scons ports with
>REVISION and MAINTAINER dropped and HOMEPAGE switche
Le Sat, Oct 30, 2021 at 08:14:22PM +0100, Stuart Henderson a écrit :
> (for those that didn't see the start of this, landry was hitting E2BIG
> because the shell command line was too long with all the damn modules
> on something he was porting..)
>
> On 2021/10/30 19:41, Stuart Henderson wrote:
>
Le Sat, Oct 30, 2021 at 07:41:20PM +0100, Stuart Henderson a écrit :
> On 2021/10/30 19:40, Stuart Henderson wrote:
> > On 2021/10/30 19:53, Marc Espie wrote:
> > > Actually, my "yep" was just we should do things that way, the patch
> > > is broken.
> > >
> > > But go does things backwards by asse
(for those that didn't see the start of this, landry was hitting E2BIG
because the shell command line was too long with all the damn modules
on something he was porting..)
On 2021/10/30 19:41, Stuart Henderson wrote:
> > > -. endfor
> > > +MODGO_SETUP_WORKSPACE = ln -sf ${WRKSRC} ${WRKDIR}/${MOD
Oops, did not read carefully, thx for correcting.
hth anyway,
cheers,
Eric.
On Sat, Oct 30, 2021 at 5:24 PM Frederic Cambus wrote:
>
> On Tue, Oct 26, 2021 at 11:48:40AM +, Eric Auge wrote:
> > diff attached, all ok?
>
> What sthen@ was suggesting is to add a @comment marker instead of remov
On 2021/10/30 18:10, Marc Espie wrote:
> I think the most reasonable solution is this:
Makes sense. We should probably rename it from MODGCC4/GCC49_ARCHS sometime!
> Index: gcc4.port.mk
> ===
> RCS file: /cvs/ports/infrastructure/mk/
On 2021/10/30 19:40, Stuart Henderson wrote:
> On 2021/10/30 19:53, Marc Espie wrote:
> > Actually, my "yep" was just we should do things that way, the patch
> > is broken.
> >
> > But go does things backwards by assembling DISTFILES with modern syntax
> > and then parsing it back in MODGO_SETUP_W
On 2021/10/30 19:53, Marc Espie wrote:
> Actually, my "yep" was just we should do things that way, the patch
> is broken.
>
> But go does things backwards by assembling DISTFILES with modern syntax
> and then parsing it back in MODGO_SETUP_WORKSPACE
>
> here's a (somewhat) saner way to do things
sthen@ suggested that checking whether resolvd is running is better
than whether it was enabled, so I adjusted the patch for that. I also
now check for the existence of /usr/sbin/rcctl instead of $OS = OpenBSD,
since that is more consistent with the things in this section do.
(also fixed an acc
Actually, my "yep" was just we should do things that way, the patch
is broken.
But go does things backwards by assembling DISTFILES with modern syntax
and then parsing it back in MODGO_SETUP_WORKSPACE
here's a (somewhat) saner way to do things
Index: go.port.mk
==
Hello,
Here are minor updates to py-ldap0 and web2ldap. Tested against ldapd,
OpenLDAP, and FreeIPA, no issues seen.
Changelogs:
https://web2ldap.de/changes-1.6.html#r1.6.16
https://gitlab.com/ae-dir/python-ldap0/-/compare/v1.3.1...v1.4.0
Thanks,
Lucas
diff 6f38aca17c71f57cb04b60e685af1fee1a08e6
Due to changes to the work laptop I'm a new openconnect user and it
turns out it's not too tough to support resolvd in openconnect with a
couple new functions in vpnc-script. I don't have any idea if this is
the best way to detect if resolvd is in use, but it seems to work in my
one test case.
No
On Tue, Oct 26, 2021 at 11:48:40AM +, Eric Auge wrote:
> diff attached, all ok?
What sthen@ was suggesting is to add a @comment marker instead of removing
the entry for share/terminfo/a/alacritty+common.
On top of what he mentioned, this ensures that nobody reintroduces the line
accidentally
I think the most reasonable solution is this:
Index: gcc4.port.mk
===
RCS file: /cvs/ports/infrastructure/mk/gcc4.port.mk,v
retrieving revision 1.14
diff -u -p -r1.14 gcc4.port.mk
--- gcc4.port.mk27 Apr 2019 21:26:35 -
We disabled the checksum check because it was rather expensive, but actually
we also store timestamps in packing-lists
This is a first draft at a better check. What this does:
- compare the fs timestamp with the packing-list timestamp. This should be
very cheap in most cases, since we're already i
On Sat, Oct 30, 2021 at 03:53:20PM +0200, Paco Esteban wrote:
> On Sat, 30 Oct 2021, Remi Locherer wrote:
>
> > Hi Paco,
> >
> > On Sat, Oct 30, 2021 at 01:52:04PM +0200, Paco Esteban wrote:
> > > Hi ports@,
> > >
> > > I just found out that productivity/vdirsyncer was not working because
> > >
Diff below updates notmuch to 0.34, which brings some new features:
https://git.notmuchmail.org/git?p=notmuch;a=blob;f=NEWS;h=d08183bf30eb696f7fafeb74ad8050972aefac4d;hb=HEAD
For now notmuch is build *without* the optional new s-expression based
query parser. Reason is that this feature relies on
On Sat, 30 Oct 2021, Remi Locherer wrote:
> Hi Paco,
>
> On Sat, Oct 30, 2021 at 01:52:04PM +0200, Paco Esteban wrote:
> > Hi ports@,
> >
> > I just found out that productivity/vdirsyncer was not working because
> > one of its dependencies (devel/py-click-threading) was broken.
> >
> > Here's a
On Sat, 30 Oct 2021, Stuart Henderson wrote:
> On 2021/10/30 13:52, Paco Esteban wrote:
> > Hi ports@,
> >
> > I just found out that productivity/vdirsyncer was not working because
> > one of its dependencies (devel/py-click-threading) was broken.
>
> I'm OK with the update, but any more info on
On Sat, 2021-10-30 at 15:33 +0200, Peter Hessler wrote:
> The build system seems to expect aarch64 to be arm-64, and treats armhf
> as 32bit. Update the Makefile(s) and patch to reflect this.
>
> No REVISION because it doesn't build on aarch64, and this shouldn't
> affect any other arch.
>
> Bui
The build system seems to expect aarch64 to be arm-64, and treats armhf
as 32bit. Update the Makefile(s) and patch to reflect this.
No REVISION because it doesn't build on aarch64, and this shouldn't
affect any other arch.
Build error:
http://build-failures.rhaalovely.net/aarch64/2021-10-22/jav
The FreeBSD folks did an in-depth analysis of why jdk
1.8 and 11 fail to build with llvm13. You can read about
it here:
https://github.com/freebsd/freebsd-ports/commit/3822416493c
In llvm13 the 'this' pointer was annotated with alignment:
https://github.com/llvm/llvm-project/commit/0aa0458f142
On 2021/10/30 13:52, Paco Esteban wrote:
> Hi ports@,
>
> I just found out that productivity/vdirsyncer was not working because
> one of its dependencies (devel/py-click-threading) was broken.
I'm OK with the update, but any more info on the breakage? It's working
for me on a 7.0 box and I don't
Le Sat, Oct 30, 2021 at 11:05:51AM +0200, Landry Breuil a écrit :
> Le Sat, Oct 30, 2021 at 10:27:46AM +0200, Landry Breuil a écrit :
> > Le Sat, Oct 30, 2021 at 10:20:18AM +0200, Landry Breuil a écrit :
> > > Le Sat, Oct 30, 2021 at 09:51:34AM +0200, Landry Breuil a écrit :
> > > > Hi,
> > > >
>
Hi ports@,
I just found out that productivity/vdirsyncer was not working because
one of its dependencies (devel/py-click-threading) was broken.
Here's a patch that updates deve/py-click-threading to its latest
version (0.5.0), which fixes the bug and another one that updates
productivity/vdirsync
On Sat, Oct 30, 2021 at 10:45:16AM +0200, Jeremie Courreges-Anglas wrote:
> On Fri, Oct 29 2021, Daniel Dickman wrote:
> > So I guess ONLY FOR ARCHS didn’t help here?
>
> That's right. make dump-vars output is used even if the port is
> disabled, so a broken RUN_DEPENDS matters. Maybe this port
Le Sat, Oct 30, 2021 at 10:27:46AM +0200, Landry Breuil a écrit :
> Le Sat, Oct 30, 2021 at 10:20:18AM +0200, Landry Breuil a écrit :
> > Le Sat, Oct 30, 2021 at 09:51:34AM +0200, Landry Breuil a écrit :
> > > Hi,
> > >
> > > i dunno if something should be fixed in the python build system (is it
>
On Fri, Oct 29 2021, Daniel Dickman wrote:
> So I guess ONLY FOR ARCHS didn’t help here?
That's right. make dump-vars output is used even if the port is
disabled, so a broken RUN_DEPENDS matters. Maybe this port could
use MODULES=gcc4?
> would never have thought about needing it here.
>
>> On
Le Sat, Oct 30, 2021 at 10:20:18AM +0200, Landry Breuil a écrit :
> Le Sat, Oct 30, 2021 at 09:51:34AM +0200, Landry Breuil a écrit :
> > Hi,
> >
> > i dunno if something should be fixed in the python build system (is it
> > *necessary* to point at /usr/local/lib for libpython3.8.so ?), but i
> >
Le Sat, Oct 30, 2021 at 09:51:34AM +0200, Landry Breuil a écrit :
> Hi,
>
> i dunno if something should be fixed in the python build system (is it
> *necessary* to point at /usr/local/lib for libpython3.8.so ?), but i
> think there's something definitely wrong somewhere. That probably
> accounts f
Hi,
this feels like a huge can of worms, but might aswell put it here in the
open..
/usr/local/lib/python3.8/_sysconfigdata__openbsd7_.py sets various
vars (LDFLAGS, BLDSHARED, LDSHARED, PY_CORE_LDFLAGS, PY_LDFLAGS) that
contains '-L/usr/local/lib/ -L/usr/obj/ports/Python-3.8.12/Python-3.8.12
-L
39 matches
Mail list logo
