Re: Help needed with USE_GITHUB
On 6/12/22 01:56, Michael Gmelin wrote: The key is correcting the typo in PORTNAME: gingko => ginkgo Thanks for spotting that typo. That was indeed the problem. Cheers Philipp
WARN: Makefile: possible use of absolute pathname "/usr/bin/xxx"
Hello, I'm trying to find a variable to silince portlint warning like, e.g.: WARN: Makefile: possible use of absolute pathname "/usr/bin/clang
Re: WARN: Makefile: possible use of absolute pathname "/usr/bin/xxx"
... but I can't find one like LOCALBASE==/usr/local Is there one like it Thanks, Nuno Teixeira Nuno Teixeira escreveu no dia domingo, 12/06/2022 à(s) 15:42: > Hello, > > I'm trying to find a variable to silince portlint warning like, e.g.: > WARN: Makefile: possible use of absolute pathname "/usr/bin/clang > > > >
ZFS ccache optimization
Hello, I will start using ccache with poudriere for may test builds and I'm asking if there is any zfs tweaks/optimization that improve read/write ccache speed? Thanks, Nuno Teixeira
Re: sysutils/lsof: help!
Am 11.06.22 um 16:20 schrieb Larry Rosenman: > greetings, > I'm having trouble getting anyone to care about lsof anymore. If anyone > can help fix these merge conflicts, I'd be most > appreciative, and will merge and make a new FreeBSD release as soon as we get > it fixed: > https://github.com/lsof-org/lsof/pull/184 Hi Larry and Damjan, I have manually merged the pull request into the lsof-4.95.0. But I'm not sure how to best submit the result, since it seems your forked repository is still at 4.94.0 and while I could create a pull request at the official lsof repository, it would make the full set of changes appear to have come from me. The patched sources can be fetched from my GitHub repository: https://github.com/stesser/lsof/ I have verified that lsof built from these sources leasd to a working lsof binary. All current patches can be removed from the port. One remark: there have been a lot of changes from Error() to Exit(1) (or other parameters), these seem to be the main reason that the patch did not apply anymore. I have changed a number of Error() to Exit(1) in other parts of the affected source files - these should be checked before commit. On a kernel built with D34184 and D34323 applied I get output like this: COMMAND PID USER FD TYPEDEVICE SIZE/OFF NODE NAME bash3313 se txt VREG 3086741924,1296883289 937256 864387 /usr/local/bin/bash (system/usr/local) bash3313 se ctty VCHR 1,229 0t0485 /dev/pts/0 (devfs) bash3313 se cwd VDIR 1269308102,3936804361 50 131584 /usr/git/src (system/usr/git) Best regards, STefan 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 OpenPGP_signature Description: OpenPGP digital signature
Re: sysutils/lsof: help!
On 06/12/2022 3:29 pm, Stefan Esser wrote: Am 11.06.22 um 16:20 schrieb Larry Rosenman: greetings, I'm having trouble getting anyone to care about lsof anymore. If anyone can help fix these merge conflicts, I'd be most appreciative, and will merge and make a new FreeBSD release as soon as we get it fixed: https://github.com/lsof-org/lsof/pull/184 Hi Larry and Damjan, I have manually merged the pull request into the lsof-4.95.0. But I'm not sure how to best submit the result, since it seems your forked repository is still at 4.94.0 and while I could create a pull request at the official lsof repository, it would make the full set of changes appear to have come from me. The patched sources can be fetched from my GitHub repository: https://github.com/stesser/lsof/ I have verified that lsof built from these sources leasd to a working lsof binary. All current patches can be removed from the port. One remark: there have been a lot of changes from Error() to Exit(1) (or other parameters), these seem to be the main reason that the patch did not apply anymore. I have changed a number of Error() to Exit(1) in other parts of the affected source files - these should be checked before commit. On a kernel built with D34184 and D34323 applied I get output like this: COMMAND PID USER FD TYPEDEVICE SIZE/OFF NODE NAME bash3313 se txt VREG 3086741924,1296883289 937256 864387 /usr/local/bin/bash (system/usr/local) bash3313 se ctty VCHR 1,229 0t0485 /dev/pts/0 (devfs) bash3313 se cwd VDIR 1269308102,3936804361 50 131584 /usr/git/src (system/usr/git) Best regards, STefan 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? Damjan, Can you update your repo and incorporate this in? I'd love to make a upstream release. -- Larry Rosenman http://people.freebsd.org/~ler Phone: +1 214-642-9640 E-Mail: l...@freebsd.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106 signature.asc Description: OpenPGP digital signature
Re: sysutils/lsof: help!
Am 12.06.22 um 22:48 schrieb Larry Rosenman: > On 06/12/2022 3:29 pm, Stefan Esser wrote: [...] >> On a kernel built with D34184 and D34323 applied I get output >> like this: >> >> COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME >> bash 3313 se txt VREG 3086741924,1296883289 937256 864387 >> /usr/local/bin/bash (system/usr/local) >> bash 3313 se ctty VCHR 1,229 0t0 485 >> /dev/pts/0 (devfs) >> bash 3313 se cwd VDIR 1269308102,3936804361 50 131584 >> /usr/git/src (system/usr/git) >> >> Best regards, STefan >> >> 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). But I did not have time to test the kernel patches beyond that they actually provide the information required for lsof and that the system shows not signs of instability or other issues. I'd appreciate if another developer performed an independent review, but if this does not happen within the next few days I might commit the two patch sets. Best regards, STefan OpenPGP_signature Description: OpenPGP digital signature
ccache 3.x legacy ported but not 4.x
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
Re: ccache 3.x legacy ported but not 4.x
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
Re: Please do not deprecate ports-mgmt/synth and lang/gcc6-aux
"Bojan Petrovic" writes: > c) to this, I can only offer to take maintainership of ports-mgmt/synth > and lang/gcc6-aux. I haven't maintained a FreeBSD port before, so I > must admit I cannot estimate how much effort it would require on my > side. I only have a hunch that these ports will be slow-moving targets, > and will not require too much maintenance effort. d) Maybe port synth rewrite in C [1] or gcc9-aux [2] from DragonFly. Disclaimer: I've never used (d)synth myself, so feel free to ignore. [1] https://github.com/DragonFlyBSD/DragonFlyBSD/tree/master/usr.bin/dsynth https://github.com/DragonFlyBSD/dsynth (unfinished portable version) [2] https://github.com/DragonFlyBSD/DeltaPorts/tree/master/ports/lang/gcc9-aux https://sting.dragonflybsd.org/dports/logs/lang___gcc9-aux.log
