Re: Question on figuring out category for new port
On 8/02/2021 2:28 pm, Adam Jimerson wrote:
On Sunday, February 7, 2021 9:05:31 PM EST Kubilay Kocak wrote:
www/py-adblock [1] as its primary use will be in and for browsers (in
this case qutebrowser (also in www)
Thanks for your input, that was my main thinking as well as to why it might go
under the www category.
You're welcome
One may consider adding 'net' as a secondary if it can be used outside
the browser (www) context (say like a pihole thingy)
Interesting thought, I don't see why other programs/projects wouldn't be able
to also use this port as it basically adds python bindings around the already
existing rust API exposed by the project.
I suppose the question then is, are there any non browser consumers for
this software that already exist?
I'd just stick it in www until such time as one or more appears, adding
'net' to CATEGORIES (secondary/virtual) when they do.
[1] noting the "canonical" and registered PyPI name from this project is
'adblock' not 'python-adblock' (the repo name)
Yeah I already figured that the port should have the "py-" prefix in the name to
follow the FreeBSD naming convention for python ports, even though the name is
not consistent between the repo and PyPI. Thus the port would be "py-adblock"
in the ports tree as well as follow the naming convention for the python
flavors "py36-", "py37-" when packaged.
Yep, use PKGNAMEPREFIX=${PYTHON_PKGNAMEPREFIX}, and setting
USES=python: to the supported python versions range
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Question on figuring out category for new port
On Sunday, February 7, 2021 9:05:31 PM EST Kubilay Kocak wrote: > www/py-adblock [1] as its primary use will be in and for browsers (in > this case qutebrowser (also in www) Thanks for your input, that was my main thinking as well as to why it might go under the www category. > One may consider adding 'net' as a secondary if it can be used outside > the browser (www) context (say like a pihole thingy) Interesting thought, I don't see why other programs/projects wouldn't be able to also use this port as it basically adds python bindings around the already existing rust API exposed by the project. > [1] noting the "canonical" and registered PyPI name from this project is > 'adblock' not 'python-adblock' (the repo name) Yeah I already figured that the port should have the "py-" prefix in the name to follow the FreeBSD naming convention for python ports, even though the name is not consistent between the repo and PyPI. Thus the port would be "py-adblock" in the ports tree as well as follow the naming convention for the python flavors "py36-", "py37-" when packaged. signature.asc Description: This is a digitally signed message part.
Re: Question on figuring out category for new port
On 7/02/2021 1:58 pm, Adam Jimerson wrote: Hello so I was wanting to make a new port for python-adblock (https://github.com/ArniDagur/python-adblock) so it can be added as a dependency of www/qutebrowser but I'm not quite sure what is the correct category for such a port. I can easily see it falling under net, net-mgmt, or www although I'm thinking since it is browser related it would fall under www. I wanted to run this by the list to see which would be the better option. Would www be the best option here? www/py-adblock [1] as its primary use will be in and for browsers (in this case qutebrowser (also in www) Previous adblock related ports have also been in www/: https://www.freshports.org/www/adblock/ https://www.freshports.org/www/xpi-adblock_plus https://www.freshports.org/www/xpi-uBlock_origin/ https://www.freshports.org/www/ziproxy/ One may consider adding 'net' as a secondary if it can be used outside the browser (www) context (say like a pihole thingy) [1] noting the "canonical" and registered PyPI name from this project is 'adblock' not 'python-adblock' (the repo name) ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Handling directory ownership in pkg-plist
On 2021-02-07 12:19, Chris Rees wrote:
Afternoon,
On 7 February 2021 19:05:26 GMT, Chris wrote:
On 2021-02-07 02:18, Chris Rees wrote:
Hi Chris,
Thamks for the reply.
On 7 February 2021 03:57:03 GMT, Chris
wrote:
On 2021-02-06 13:34, Chris Rees wrote:
Hi all,
Resurrecting audio/ampache-resurrect, and I have @owner www/@group
www above
all
of the WWWDIR files, and they are correctly owned. However, the
directories
under
it are all still owned by root:wheel, and if I explicitly add them
all with
@dir
pkg then complains about not being able to find them.
Would it be unacceptable to just have @exec chown -R www:www
%D/%%WWWDIR%%
at the bottom?
Yes. By way of pre-install:
You'll probably get a complaint unless you use: ${CHOWN}
Perhaps I was unclear- I'm referring to pkg-plist, so there is no
${CHOWN}
there.
The exact proposed line is
@postexec chown -R www:www %D/%%WWWDIR%%
I was wondering what the 'proper' way to do this was.
I'm wondering why it's not enough to create a post-extract that doesn't
something
like
cd ${WRKSRC}/some/dir && ${CHOWN} -R ${WWUSER}:${WWGROUP} .
Then the ports framework would create an appropriate pkg-plist based on
that.
A
make -DBATCH makeplist would generate your target pkg-plist.
I'm paraphrasing, as I don't have your Makefile. But I've needed to
perform
tasks
like myself. Out of curiosity. What does a make -DBATCH makeplist
generate?
Does
the output provide the necessary clues to create a pkg-plist you're
interested in?
CHOWN can't be used in the Makefile as you need root.
make makeplist used after CHOWN does nothing different- it appears not to
notice
that they have different owners.
But what of the pkg-plist for www/kanboard? It has the clues you need for
setting the
pkg-plist. The ports framework will honor the perms set within it. eg;
@owner %%KANBOARD_USERNAME%%
@group %%KANBOARD_GROUPNAME%%
%%WWWDIR%%/.htaccess
%%WWWDIR%%/ChangeLog
%%WWWDIR%%/LICENSE
%%WWWDIR%%/app/.htaccess
%%WWWDIR%%/app/Action/Base.php
%%WWWDIR%%/app/Action/CommentCreation.php
...
Just change the leader to the @user and @group to your desired names in your
pkg-plist. Save it to your port. Done. :-)
There is nothing documented on this that I can find, so I'll commit the
@postexec line.
Chris
--Chris
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Bind9 security upgrade
On Sun, Feb 07, 2021 at 04:54:49PM -0800, Mark Millard wrote: > > Did you rebuild dialog4ports after: > > 20210105: > Nope. Make in ports seems to update about every bit of software involved. It never occured to me that dialog4ports needs to be updated separately. > An incorrectly built dialog4ports will show > /usr.lib/libdialog.so.8 instead. That's what I have. Now to rebuild dialog4ports. Thank you! bob prohaska > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > > ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Bind9 security upgrade
> On arm64 (Pi3) under > FreeBSD pelorus.zefox.org 13.0-ALPHA3 FreeBSD 13.0-ALPHA3 #2 > stable/13-c256281-gc415d0df47f: Fri Feb 5 08:09:12 PST 2021 > bob at pelorus.zefox.org > :/usr/obj/usr/freebsd-src/arm64.aarch64/sys/GENERIC-MMCCAM arm64 > it looks like dialog4ports is out of whack. It doesn't > display in the usual way, the dialog box is outlined by > characters such as ^@^@^@^@^@^@^@^ across the top > and < down the left margin. The background color varies, > parts white, green and black. The display is distorted > both on the HDMI console and in an X window on the system. > It's equally but differently addled on a RaspiOS xterm. > > Worse yet, when selecting , it dumps core and fails > to save changes. That's a real troublemaker. Is there > a simple way to omit docs from the build without using > dialog4ports? > Did you rebuild dialog4ports after: 20210105: ncurses installation has been modified to only keep the widechar enabled version. Incremental build is broken for that change, so it requires a clean build. ? Even if you did: Unfortunately, they did not make such an UPDATING note for libraries that use ncurses when they updated those to avoid the dependency on the now-missing ncurses material: QUOTE author John Baldwin 2021-02-02 01:09:33 + committer John Baldwin 2021-02-02 01:11:49 + commit 0b7f1af804f06a285717b490bef80e24648adcbe (patch) treee35db81ed51f71ccc1afc82c7cd04e8bb2fb8860 parent 7787e7eed9d2a43fb6eb6040f1b495995a2f (diff) downloadsrc-0b7f1af804f06a285717b490bef80e24648adcbe.tar.gz src-0b7f1af804f06a285717b490bef80e24648adcbe.zip Bump shared library versions after ncurses bump in 13. A few shared libraries in the base system link against ncurses. An upgrade from a 12.x host to 13 results in ABI breakage for existing binaries since the newer versions of these libraries link against the newer ncurses while the binary itself links against the older ncurses. For example, dialog4ports built on 12.x sometimes crashes on 13 since it depends on libdialog which links against ncurses internally. MFC after: 3 days Reviewed by:kib, delphij Differential Revision: https://reviews.freebsd.org/D28448 . . . diff --git a/ObsoleteFiles.inc b/ObsoleteFiles.inc index 29cf25e152e6..696243470b14 100644 --- a/ObsoleteFiles.inc +++ b/ObsoleteFiles.inc @@ -36,6 +36,17 @@ # xargs -n1 | sort | uniq -d; # done +# 20210201: bump shared libraries which link against ncurses +OLD_LIBS+=lib/libedit.so.7 +OLD_LIBS+=usr/lib/libdialog.so.8 . . . END QUOTE So now there is a /usr.lib/libdialog.so.9 instead and a correctly built dialog4ports will show it in the ldd output: # ldd `which dialog4ports` /usr/local/bin/dialog4ports: libncursesw.so.9 => /lib/libncursesw.so.9 (0x402a1000) libm.so.5 => /lib/libm.so.5 (0x4033a000) libdialog.so.9 => /usr/lib/libdialog.so.9 (0x403a5000) libc.so.7 => /lib/libc.so.7 (0x40408000) An incorrectly built dialog4ports will show /usr.lib/libdialog.so.8 instead. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Question on figuring out category for new port
> How is the blocking achieved ? Does it hook into the DNS lookups ? > Does it parse webpages/javascript and detect patterns ? Does it > use IP blacklists ? > > www sounds ok, or DNS, if it's DNS-based. net, if it uses IP blacklists. This port is just a python wrapper around Brave browser's adblock library which just looks like is uses rulesets similar to what Adblock Plus, Ublock Origin and other such tools use. I doubt that it does any DNS lookups (which is why I didn't consider that category), and Qutebrowser added this as a dependency to be more flexible than their current host based filtering. signature.asc Description: This is a digitally signed message part.
Re: Bind9 security upgrade
On Sat, Feb 06, 2021 at 03:39:56PM -0800, bob prohaska wrote: > > Manual deinstall of both defective ports followed by reinstall > of lang/perl5.32 seems to have done the trick. Now dns/bind916 > is compiling. Fingers crossed 8-) > Fixing my mangled perl installation was only step one. Two new hurdles have emerged: First, the default config includes docs (distinct from man pages) which drags in a vast sea of dependencies, some quite large (gs, for example). Turning docs off allowed armv7 to finish building successfully in short order. On arm64 (Pi3) under FreeBSD pelorus.zefox.org 13.0-ALPHA3 FreeBSD 13.0-ALPHA3 #2 stable/13-c256281-gc415d0df47f: Fri Feb 5 08:09:12 PST 2021 b...@pelorus.zefox.org:/usr/obj/usr/freebsd-src/arm64.aarch64/sys/GENERIC-MMCCAM arm64 it looks like dialog4ports is out of whack. It doesn't display in the usual way, the dialog box is outlined by characters such as ^@^@^@^@^@^@^@^ across the top and < down the left margin. The background color varies, parts white, green and black. The display is distorted both on the HDMI console and in an X window on the system. It's equally but differently addled on a RaspiOS xterm. Worse yet, when selecting , it dumps core and fails to save changes. That's a real troublemaker. Is there a simple way to omit docs from the build without using dialog4ports? Thanks for reading, and all the help so far! bob prohaska ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Handling directory ownership in pkg-plist
Afternoon,
On 7 February 2021 19:05:26 GMT, Chris wrote:
>On 2021-02-07 02:18, Chris Rees wrote:
>> Hi Chris,
>>
>> Thamks for the reply.
>>
>> On 7 February 2021 03:57:03 GMT, Chris
>wrote:
>>> On 2021-02-06 13:34, Chris Rees wrote:
Hi all,
Resurrecting audio/ampache-resurrect, and I have @owner www/@group
>>> www above
all
of the WWWDIR files, and they are correctly owned. However, the
>>> directories
under
it are all still owned by root:wheel, and if I explicitly add them
>>> all with
@dir
pkg then complains about not being able to find them.
Would it be unacceptable to just have @exec chown -R www:www
>>> %D/%%WWWDIR%%
at the bottom?
>>> Yes. By way of pre-install:
>>> You'll probably get a complaint unless you use: ${CHOWN}
>>
>> Perhaps I was unclear- I'm referring to pkg-plist, so there is no
>${CHOWN}
>> there.
>>
>> The exact proposed line is
>>
>> @postexec chown -R www:www %D/%%WWWDIR%%
>>
>> I was wondering what the 'proper' way to do this was.
>I'm wondering why it's not enough to create a post-extract that doesn't
>
>something
>like
>cd ${WRKSRC}/some/dir && ${CHOWN} -R ${WWUSER}:${WWGROUP} .
>Then the ports framework would create an appropriate pkg-plist based on
>that.
>A
>make -DBATCH makeplist would generate your target pkg-plist.
>
>I'm paraphrasing, as I don't have your Makefile. But I've needed to
>perform
>tasks
>like myself. Out of curiosity. What does a make -DBATCH makeplist
>generate?
>Does
>the output provide the necessary clues to create a pkg-plist you're
>interested in?
CHOWN can't be used in the Makefile as you need root.
make makeplist used after CHOWN does nothing different- it appears not to
notice that they have different owners.
There is nothing documented on this that I can find, so I'll commit the
@postexec line.
Chris
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Some success; some problems with x11/nvidia-driver-460.39_1
On 07/02/2021 16:05, David Wolfskill wrote: > On those same laptops, however, I get panices running head (either > main-n244659-689561d40322 or main-n244663-f6e8256a965d). As I was > unable to get crash dumps, I took screenshots; they are available at > https://www.catwhisker.org/~david/FreeBSD/ports/nvidia-driver/head_panics/ The crash is because a part of extra-patch-src_nvidia-modeset_nvidia-modeset-freebsd.c needs to be applied even for 460.039, but now the patch file is applied only for earlier versions. The needed part modifies nvkms_alloc_ref_ptr function. I guess that the patch needs to be split in two. P.S. The maintainer is CC-ed. -- Andriy Gapon ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Handling directory ownership in pkg-plist
On 2021-02-07 02:18, Chris Rees wrote:
Hi Chris,
Thamks for the reply.
On 7 February 2021 03:57:03 GMT, Chris wrote:
On 2021-02-06 13:34, Chris Rees wrote:
Hi all,
Resurrecting audio/ampache-resurrect, and I have @owner www/@group
www above
all
of the WWWDIR files, and they are correctly owned. However, the
directories
under
it are all still owned by root:wheel, and if I explicitly add them
all with
@dir
pkg then complains about not being able to find them.
Would it be unacceptable to just have @exec chown -R www:www
%D/%%WWWDIR%%
at the bottom?
Yes. By way of pre-install:
You'll probably get a complaint unless you use: ${CHOWN}
Perhaps I was unclear- I'm referring to pkg-plist, so there is no ${CHOWN}
there.
The exact proposed line is
@postexec chown -R www:www %D/%%WWWDIR%%
I was wondering what the 'proper' way to do this was.
I'm wondering why it's not enough to create a post-extract that doesn't
something
like
cd ${WRKSRC}/some/dir && ${CHOWN} -R ${WWUSER}:${WWGROUP} .
Then the ports framework would create an appropriate pkg-plist based on that.
A
make -DBATCH makeplist would generate your target pkg-plist.
I'm paraphrasing, as I don't have your Makefile. But I've needed to perform
tasks
like myself. Out of curiosity. What does a make -DBATCH makeplist generate?
Does
the output provide the necessary clues to create a pkg-plist you're
interested in?
Chris
--Chris
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Handling directory ownership in pkg-plist
On 2021-02-07 02:18, Chris Rees wrote:
Hi Chris,
Thamks for the reply.
On 7 February 2021 03:57:03 GMT, Chris wrote:
On 2021-02-06 13:34, Chris Rees wrote:
Hi all,
Resurrecting audio/ampache-resurrect, and I have @owner www/@group
www above
all
of the WWWDIR files, and they are correctly owned. However, the
directories
under
it are all still owned by root:wheel, and if I explicitly add them
all with
@dir
pkg then complains about not being able to find them.
Would it be unacceptable to just have @exec chown -R www:www
%D/%%WWWDIR%%
at the bottom?
Yes. By way of pre-install:
You'll probably get a complaint unless you use: ${CHOWN}
Perhaps I was unclear- I'm referring to pkg-plist, so there is no ${CHOWN}
there.
The exact proposed line is
@postexec chown -R www:www %D/%%WWWDIR%%
I was wondering what the 'proper' way to do this was.
I almost listed that as well. But it's been a couple years, and I couldn't
remember exactly how it looked. A look around to refresh my memory seems
to reveal that the pkg-plist for www/kanboard provides what you're looking
for eg; @owner && @group
Hope that helps, and good luck! :-)
Chris
--Chris
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
dtrace support: vim exits with SIGILL
I'm not sure if this is a bug or if I'm using an unsupported setup. In case anyone runs into a similar problem, here's why my vim stopped working. Package builder: poudriere jail 12.2-RELEASE amd64 Package consumer running vim: Ancient PC running 12.2-RELEASE amd64 The root cause of the problem is that the poudriere jail was built with CPUTYPE=znver1 instead of stock FreeBSD. Initial symptoms: vim crashes with illegal instruction. It turns out the crash is actually in libperl.so.5.32. Throwing gdb at perl: Program received signal SIGILL, Illegal instruction. 0x0008005ce435 in dtrace_dof_init () at /usr/src/cddl/contrib/opensolaris/lib/libdtrace/common/drti.c:138 138 if (dof->dofh_ident[DOF_ID_MAG0] != DOF_MAG_MAG0 || Current instruction is: => 0x0008005ce435 <+165>: vmovq (%rax),%xmm0 Turning off option DTRACE fixes perl. vim still crashes because ruby also uses dtrace (port offers no option to disable dtrace). Disabling RUBY in vim finally fixes the problem. It seems /usr/lib/dtrace/drti.o from the poudriere jail is included in perl/ ruby. I'm not familiar with dtrace probes. So I'm not sure if there is a fix short of disabling dtrace or not mixing CPUTYPE. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Can I have at least an acknowledgement of my question on PR 242529 this time?
I've asked several times in the past few months, most recently on IRC, what I can or should do to move https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242529 forward, and have yet to get any answer (or even just an acknowledgement of my question), and I'm at a loss about what to do next. Should I give up on the whole idea? ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Some success; some problems with x11/nvidia-driver-460.39_1
With the update of x11/nvidia-driver from 460.39 to 460.39_1, it now builds and works on a couple of laptops, running either stable/12 (stable/12-n232662-e8eded55f23) or stable/13 (stable/13-n244485-6136a10e355a). On those same laptops, however, I get panices running head (either main-n244659-689561d40322 or main-n244663-f6e8256a965d). As I was unable to get crash dumps, I took screenshots; they are available at https://www.catwhisker.org/~david/FreeBSD/ports/nvidia-driver/head_panics/ They look like lock-ordering issues to me -- but that should be considered a semi-educated guess (at best). Quite unrelated to the above (as far as I can tell), except that it also involves an issue with x11/nvidia-driver: a desktop mini-tower that had been building/updating x11/nvidia-driver-440 every week running stable/12 ... did not do so well attempting to build the port during its kernel build (by virtue of PORTS_MODULES=x11/nvidia-driver in /etc/src.conf) this morning -- it nearly finished, then failed to find a file where it was expected during the "Registering installation" phase: | ... | > Compressing man pages (compress-man) | ===> Installing for nvidia-driver-460.39_1 | ===> Registering installation for nvidia-driver-460.39_1 | pkg-static: Unable to access file /common/ports/x11/nvidia-driver/work/stage/common/local/share/vulkan/icd.d/nvidia_icd.json:No such file or directory | pkg-static: Unable to access file /common/ports/x11/nvidia-driver/work/stage/common/local/share/vulkan/implicit_layer.d/nvidia_layers.json:No such file or directory | *** Error code 1 | | Stop. | make[1]: stopped in /common/ports/x11/nvidia-driver | *** Error code 1 | | This machine has the specification (in /etc/make.conf): PORTSDIR=/common/ports I re-created the observed issue by trying to update/install x11/nvidia-driver using portmaster (in its default "clean everything before and after" mode). I did this in a script(1) invocation, and have copied the resulting typescript to https://www.catwhisker.org/~david/FreeBSD/ports/nvidia-driver/stable_12_staging_error/nvidia_build.txt Peace, david -- David H. Wolfskill da...@catwhisker.org Donald Trump held the office of President of the US as he incited his Putsch. See https://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Ports with version numbers going backwards: databases/db
** The following ports have a version number that sorts before a previous one ** For many package tools to work correctly, it is of utmost importance that version numbers of a port form a monotonic increasing sequence over time. Refer to the FreeBSD Porter's Handbook, 'Package Naming Conventions' for more information. Tools that won't work include pkg_version, portupgrade and portaudit. A common error is an accidental deletion of PORTEPOCH. Please fix any errors as soon as possible. The ports tree was updated at Sun Feb 7 2021 12:30:00 UTC. - *databases/db* : db-1.16 < db-1.14,2 | r564587 | nc | 2021-02-07 02:03:25 + (Sun, 07 Feb 2021) | 2 lines | | databases/db: Update to 1.16 | ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Bind9 security upgrade
On 2/6/21 9:05 PM, DutchDaemon - FreeBSD Forums Administrator wrote: On 06/02/2021 20:53, bob prohaska wrote: perl5-5.32.0_1 perl5.30-5.30.3_1 The former is correct; no idea where the latter comes from; Perl 5.30 usually looks like 'perl5-5.30.0'. Older version follow that notation (perl5-5.26.2). Manual install? Hello. Going sideway here, but I've seen this on several boxes (mostly 11.4/amd64; maybe also 11.2/amd64, but I'm not sure). All of them are using portupgrade to manage ports; all of them had only perl5.32 installed, but 5.30 was pulled in by a "portupgrade -R something". Unfortunately I hadn't the time to investigate, so I just issued "pkg delete -f perl\*" and reinstalled 5.32. bye av. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Handling directory ownership in pkg-plist
Hi Chris,
Thamks for the reply.
On 7 February 2021 03:57:03 GMT, Chris wrote:
>On 2021-02-06 13:34, Chris Rees wrote:
>> Hi all,
>>
>> Resurrecting audio/ampache-resurrect, and I have @owner www/@group
>www above
>> all
>> of the WWWDIR files, and they are correctly owned. However, the
>directories
>> under
>> it are all still owned by root:wheel, and if I explicitly add them
>all with
>> @dir
>> pkg then complains about not being able to find them.
>>
>> Would it be unacceptable to just have @exec chown -R www:www
>%D/%%WWWDIR%%
>> at the bottom?
>Yes. By way of pre-install:
>You'll probably get a complaint unless you use: ${CHOWN}
Perhaps I was unclear- I'm referring to pkg-plist, so there is no ${CHOWN}
there.
The exact proposed line is
@postexec chown -R www:www %D/%%WWWDIR%%
I was wondering what the 'proper' way to do this was.
Chris
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
vscode vs vscodium (a lot of vs).
Hello Ports, I look at editors/vscode and I it surprising me that the base is the Microsoft version: SHA256 (vscode/microsoft-vscode-1.52.1_GH0.tar.gz) = 4a2b4e3500bff73503322fc3a68099ec4151d3e800cf2bb6e9478f2e94637b6a SIZE (vscode/microsoft-vscode-1.52.1_GH0.tar.gz) = 11792551 On the vscodium website we can read: "Microsoft’s vscode source code is open source (MIT-licensed), but the product available for download (Visual Studio Code) is licensed under this not-FLOSS license and contains telemetry/tracking. According to this comment from a Visual Studio Code maintainer: When we [Microsoft] build Visual Studio Code, we do exactly this. We clone the vscode repository, we lay down a customized product.json that has Microsoft specific functionality (telemetry, gallery, logo, etc.), and then produce a build that we release under our license. When you clone and build from the vscode repo, none of these endpoints are configured in the default product.json. Therefore, you generate a “clean” build, without the Microsoft customizations, which is by default licensed under the MIT license" So I would like to know whiich code base is used to build editors/vscode. I'm really happy with my vim IDE configuration bur everybody talk about vscode and I would like to try it without being tracked by Microsoft. Thanks for your time and your answer. -- Jacques Foucry ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Question on figuring out category for new port
Hi! > Hello so I was wanting to make a new port for python-adblock > (https://github.com/ArniDagur/python-adblock) so it can be added as a > dependency of www/qutebrowser but I'm not quite sure what is the correct > category for such a port. I can easily see it falling under net, net-mgmt, or > www although I'm thinking since it is browser related it would fall under www. > > I wanted to run this by the list to see which would be the better option. > Would www be the best option here? How is the blocking achieved ? Does it hook into the DNS lookups ? Does it parse webpages/javascript and detect patterns ? Does it use IP blacklists ? www sounds ok, or DNS, if it's DNS-based. net, if it uses IP blacklists. -- p...@opsec.eu+49 171 3101372Now what ? ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
FreeBSD ports you maintain which are out of date
Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/po...@freebsd.org.html Port| Current version | New version +-+ audio/logitechmediaserver-lazysearch| 3.6.5 | 3.6.7 +-+ lang/gnatcross-binutils-aarch64 | 2.27| 2.36.1 +-+ sysutils/lxterminal | 0.3.2 | 0.4.0 +-+ x11/lxpanel | 0.9.3 | 0.10.1 +-+ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Reported by:portscout! ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
