Re: sysutils/lsof: help!

[Stefan Esser]

Am 13.06.22 um 03:01 schrieb Damjan Jovanovic:
> >> PS: A patch that applies the ZFS fixes to sysutils/lsof can be
> >>     fetched from:
> >>
> >>     https://people.freebsd.org/~se/ports/lsof-port-zfs-patch.diff
> 
> >
> > Thanks, Stefan.
> >    What will it take to get those 2 differential reviews in to the 
> system?
> 
> Hi Larry,
> 
> I have marked D34184 and D34323 as accepted, since these patches could
> be applied without conflicts (except for the version updates in param.h).
> 
> 
> 
> No no no!
> 
> DO NOT accept D34323, lsof should be patched to use the superior 
> implementation
> in D34756.

I was adding a comment that you may want to close the abandoned revision,
but was surprised to notice that I could close it as well, and have done
that to avoid future confusion ...


I had looked at D34756, but had only seen the patch to update the nfs4 ACL
access functions in sys/ufs/ufs/acl.h.

Looking again I see that there are a lot of other patches in the history of
that review.

Is there an easy way to fetch them all in one go, or do they have to be
individually fetched and applied?

> Sorry I've been busy, I'll try update 
> https://github.com/lsof-org/lsof/pull/184
>  to use it soon.

OK, as reported the patches work after resolving the conflicts and with
D34323 applied to the kernel sources.

I think that the fork in https://github.com/stesser/lsof/ could be a base
for your update of the pull request for D34576, since it at least resolves
the issues the pull request had.

Best regards, STefan


OpenPGP_signature
Description: OpenPGP digital signature

Re: Please do not deprecate ports-mgmt/synth and lang/gcc6-aux

[Bojan Petrovic]

Hello Jan,

On Mon, Jun 13, 2022, at 3:15 AM, Jan Beich wrote:
> d) Maybe port synth rewrite in C [1] or gcc9-aux [2] from DragonFly.

I probably didn't convey it clearly enough in my email, my primary concern
is that all support for Ada will be completely removed. Porting dsynth
would surely be a better option than losing synth completely, I agree. Your
second suggestion would be the best solution I think. OpenBSD had an even
newer GCC (10) ported recently[1]. As I said, I currently don't have enough
time to try and port a newer GCC myself, but keeping gcc6-aux alive could
be a stopgap measure.

Regards,
Bojan

[1] https://groups.google.com/g/comp.lang.ada/c/MsxZ01xAT2k

Re: Please do not deprecate ports-mgmt/synth and lang/gcc6-aux

[Bojan Petrovic]

On Mon, Jun 13, 2022, at 10:08 AM, Bojan Petrovic wrote:

> OpenBSD had an even newer GCC (10) ported recently.

Sorry, I meant NetBSD.

Regards,
Bojan

Differences between ports build and poudriere

[Paul Armstrong]

I'm a new porter and have run into a weird situation I'm having trouble 
resolving. Any assistance would be appreciated.

On my server, science/libtensorflow1 does not attempt to download anything.
However, I'm getting regular mail from pkg-fallout@ saying that this is 
happening on the main build servers and I'm at a loss as to why that might be. 
This is quite possibly bazel related, although the concerning file is listed in 
the Makefile for pre-fetching.

grep rules_closure Makefile
GH_TUPLE=   bazelbuild:rules_closure:308b05b2:bazelbuild_rules_closure \

Here's the relevant snippet from pkg-fallout:
WARNING: Download from 
https://storage.googleapis.com/mirror.tensorflow.org/github.com/bazelbuild/rules_closure/archive/308b05b2419edb5c8ee0471b67a40403df940149.tar.gz
 failed: class java.net.ConnectException Can't assign requested address 
(connect failed)
WARNING: Download from 
https://github.com/bazelbuild/rules_closure/archive/308b05b2419edb5c8ee0471b67a40403df940149.tar.gz
 failed: class java.net.ConnectException Can't assign requested address 
(connect failed)
ERROR: An error occurred during the fetch of repository 
'io_bazel_rules_closure':
  java.io.IOException: Error downloading 

Environment:
FreeBSD 13.0p11
Poudriere 3.3.7_1

Command:
poudriere bulk -j 13-0 -p $port_tree science/libtensorflow1

poudriere.conf:
ZPOOL=zroot
ZROOTFS=/poudriere
FREEBSD_HOST=https://download.freebsd.org
RESOLV_CONF=/etc/resolv.conf
BASEFS=/usr/local/poudriere
USE_PORTLINT=yes
USE_TMPFS=no
MAX_MEMORY=16
DISTFILES_CACHE=/usr/ports/distfiles
BAD_PKGNAME_DEPS_ARE_FATAL=yes
ALLOW_NETWORKING_PACKAGES="photoprism"
PARALLEL_JOBS=4
SAVE_WRKDIR=yes
ALLOW_MAKE_JOBS=yes

make.conf:
DEVELOPER=yes
MAKE_JOBS_NUMBER=4

Any ideas on differences between poudriere and the build cluster which might 
impact this? I'm a bit stumped.

I have tried turning off ALLOW_NETWORKING_PACKAGES, still didn't cause the 
error.

Thanks,
Paul

Re: Differences between ports build and poudriere

[Tatsuki Makino]

Hello.

Using the network is only allowed during the fetch phase.
However, there is also something that sometimes tries to download during the 
build phase.
(e.g. audio/libamrnb)
It can sometimes be avoided by copying the distfiles to the proper location.
The build cluster logs show...
> ERROR: no such package '@io_bazel_rules_closure//closure': 
> java.io.IOException: Error downloading 
> [https://storage.googleapis.com/mirror.tensorflow.org/github.com/bazelbuild/rules_closure/archive/308b05b2419edb5c8ee0471b67a40403df940149.tar.gz,
>  
> https://github.com/bazelbuild/rules_closure/archive/308b05b2419edb5c8ee0471b67a40403df940149.tar.gz]
>  to 
> /wrkdirs/usr/ports/science/libtensorflow1/work/bazel_out/bef36fd36dd6cc1e25be0c1e2af46c35/external/io_bazel_rules_closure/308b05b2419edb5c8ee0471b67a40403df940149.tar.gz:
>  Can't assign requested address (connect failed)
line, so the following port-extract target may help... maybe :)

post-extract:
${CP} ${_DISTDIR}/bazelbuild-rules_closure-308b05b2_GH0.tar.gz \

${WRKDIR}/bazel_out/bef36fd36dd6cc1e25be0c1e2af46c35/external/io_bazel_rules_closure/308b05b2419edb5c8ee0471b67a40403df940149.tar.gz

Regards.

Re: Differences between ports build and poudriere

[Daniel Engberg]

Hi,

You might want to have a look at what Gentoo does, it's 2.x but it seems 
to work the same with 1.x


https://gitweb.gentoo.org/repo/gentoo.git/tree/sci-libs/tensorflow/tensorflow-2.8.0.ebuild

Best regards,
Daniel

Re: ccache 3.x legacy ported but not 4.x

[Kubilay Kocak]

On 13/06/2022 11:02 am, Derek Schrock wrote:

On Sun, Jun 12, 2022 at 07:46:41PM EDT, Nuno Teixeira wrote:

Hello,

I've started to use ccache with poudriere again passed some years now and
I've noticed that we still use ccache legacy 3.x version.

Any special reason or imcompatibility for no updating to 4.x version?

Thanks,

Nuno Teixeira


You might want to follow this.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234971



I have a working WIP port updating ccache to the latest versions, tested 
with ports / base builds without issue so far for a few months.