Looking for a committer
Hello, I'm looking for a port committer to take a look at the following port: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253782 signature.asc Description: This is a digitally signed message part.
Re: Need some guidance on port Makefile with stage-qa errors
On Wednesday, February 17, 2021 10:19:51 AM EST Gleb Popov wrote: > Could it be that this file is actually a symlink? In this case you have to > fix its target. I just checked and that file is a normal file and show as being a byte-compiled root@114amd64-development:~ # ls -lh /wrkdirs/usr/ports/www/py-adblock/work- py37/stage/usr/local/lib/python3.7/site-packages/adblock/__pycache__/ __init__.cpython-37.pyc -rw-r--r-- 1 root wheel 374B Feb 18 13:06 /wrkdirs/usr/ports/www/py- adblock/work-py37/stage/usr/local/lib/python3.7/site-packages/adblock/ __pycache__/__init__.cpython-37.pyc root@114amd64-development:~ # file /wrkdirs/usr/ports/www/py-adblock/work-py37/ stage/usr/local/lib/python3.7/site-packages/adblock/__pycache__/ __init__.cpython-37.pyc /wrkdirs/usr/ports/www/py-adblock/work-py37/stage/usr/local/lib/python3.7/ site-packages/adblock/__pycache__/__init__.cpython-37.pyc: python 3.7 byte- compiled signature.asc Description: This is a digitally signed message part.
Re: Need some guidance on port Makefile with stage-qa errors
Bumping this hoping someone could give some guidance on how to resolve this. On Sat, Feb 13, 2021 at 10:52 PM Adam Jimerson wrote: > Hello, > > I'm working on making a new port and I have the Makefile and everything > mostly > done, but currently it is failing on stage-qa when ran through poudriere > testport. The error that I get is as follows: > > Error: 'lib/python3.7/site-packages/adblock/__pycache__/ > __init__.cpython-37.pyc' is referring to /wrkdirs/usr/ports/www/py-adblock/ > work-py37/stage > > The Makefile I'm working on is available at > https://git.sr.ht/~vendion/freebsd-ports/tree/master/item/www/py-adblock/Makefile > at this point I'm stumped and > could use some pointers as to what I'm doing wrong. I've tried a few > different > things including using `--root` instead of --prefix and changing the > values > that I pass in, but every other thing I have tried as either resulted in > the > same error or the lib/python3.7/site-packages/adblock directory not > getting > added to the stage directory. ___ 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"
Need some guidance on port Makefile with stage-qa errors
Hello, I'm working on making a new port and I have the Makefile and everything mostly done, but currently it is failing on stage-qa when ran through poudriere testport. The error that I get is as follows: Error: 'lib/python3.7/site-packages/adblock/__pycache__/ __init__.cpython-37.pyc' is referring to /wrkdirs/usr/ports/www/py-adblock/ work-py37/stage The Makefile I'm working on is available at https://git.sr.ht/~vendion/freebsd-ports/tree/master/item/www/py-adblock/Makefile at this point I'm stumped and could use some pointers as to what I'm doing wrong. I've tried a few different things including using `--root` instead of --prefix and changing the values that I pass in, but every other thing I have tried as either resulted in the same error or the lib/python3.7/site-packages/adblock directory not getting added to the stage directory. signature.asc Description: This is a digitally signed message part.
Re: Building a port with poudriere that depends on a cargo crate that needs net access
On Wednesday, February 10, 2021 2:37:14 PM EST Matthew D. Fuller wrote: > In this case, x-ref > https://github.com/addr-rs/addr/issues/6 > so apparently there's some way to point it at a manually pre-fetched > list. Thanks that did the trick, I was able to pull down a copy of a list and have it being patched in so it is available during the build stage. signature.asc Description: This is a digitally signed message part.
Building a port with poudriere that depends on a cargo crate that needs net access
I'm trying to make a port that depends on a number of cargo crates, both
direct and indirect dependencies, one of these crates needs network access to
build. The crate in question is psl (https://crates.io/crates/psl).
When building the port with `poudriere testport` the build fails with the
following errors:
error: proc-macro derive panicked
--> /wrkdirs/usr/ports/www/py-adblock/work-py37/python-adblock-0.4.2/cargo-
crates/psl-0.4.1/src/list.rs:6:10
|
6 | #[derive(Psl, Copy, Clone, Eq, PartialEq, Ord, PartialOrd, Hash, Debug,
Default)]
| ^^^
|
= help: message: failed to download the list: failed to lookup address
information: hostname nor servname provided, or not known
error[E0599]: no method named `domain` found for struct `List` in the current
scope
--> /wrkdirs/usr/ports/www/py-adblock/work-py37/python-adblock-0.4.2/cargo-
crates/psl-0.4.1/src/list.rs:28:20
|
7 | pub struct List;
| method `domain` not found for this
...
28 | match List.domain(input) {
|^^ method not found in `List`
|
= help: items from traits can only be used if the trait is implemented and
in scope
note: `Psl` defines an item `domain`, perhaps you need to implement it
--> /wrkdirs/usr/ports/www/py-adblock/work-py37/python-adblock-0.4.2/cargo-
crates/psl-0.4.1/src/lib.rs:48:1
|
48 | pub trait Psl {
| ^
error[E0599]: no method named `suffix` found for struct `List` in the current
scope
--> /wrkdirs/usr/ports/www/py-adblock/work-py37/python-adblock-0.4.2/cargo-
crates/psl-0.4.1/src/list.rs:51:20
|
7 | pub struct List;
| method `suffix` not found for this
...
51 | match List.suffix(input) {
|^^ method not found in `List`
|
= help: items from traits can only be used if the trait is implemented and
in scope
note: `Psl` defines an item `suffix`, perhaps you need to implement it
--> /wrkdirs/usr/ports/www/py-adblock/work-py37/python-adblock-0.4.2/cargo-
crates/psl-0.4.1/src/lib.rs:48:1
|
48 | pub trait Psl {
| ^
error: aborting due to 3 previous errors
I'm guessing the first error "failed to download the list: failed to lookup
address information: hostname nor servname provided, or not known" is the
source of the other 2 errors.
If I enter the build jail and run the build command directly from /wrkdirs/
usr/ports/www/py-adblock/work-py37/python-adblock-0.4.2 the crate builds
without issues which seems to imply that poudriere's testport command is
blocking the network request (probably for a good reason).
I'm sure something like this has come up before, but is
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
> 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.
Question on figuring out category for new port
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? signature.asc Description: This is a digitally signed message part.
Re: Any ports committers able to review a new port request
Hi, Yes I will be fixing that in a new patch. The yadm tool has seen a new update just the other day so I'll merge this patch and the update into one ticket and skip messing with having to bump the PORTREVISION for that port. On Mon, Aug 10, 2020 at 2:43 PM Kurt Jaeger wrote: > Hi! > > > > A few months ago I opened a bug report to add a new port > textproc/py-j2cli > > > (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245783) that I > will be the > > > maintainer of. This will be an optional runtime dependency of > sysutils/yadm > > > to allow for Jinja2 template files. > > > > Committed, thanks! > > Btw, will you fix the patch in > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245593 > > ? > > -- > 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"
Any ports committers able to review a new port request
Hello, A few months ago I opened a bug report to add a new port textproc/py-j2cli (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245783) that I will be the maintainer of. This will be an optional runtime dependency of sysutils/yadm to allow for Jinja2 template files. signature.asc Description: This is a digitally signed message part.
Re: Running tests in ports Makefiles?
On Tuesday, April 7, 2020 11:35:38 AM EDT Adam Weinberger wrote: > Optional tests should never be run during a normal build. There is a > "do-test:" target for that purpose. Can you fold the test suite into > that target? Yeah it would be completely possible to use that target for the tests, and thanks for pointing that out as I don't see it listed under Section 5.13.3.12 of the Porter's Handbook [0]. I just didn't know if this was common place to do so with FreeBSD ports. The only thing I have to compare it with is Arch Linux's build system where if a packages PKGBUILD file defines a `check` function [1] then it is called during the build process automatically. I know comparing apples to oranges, hence why I wanted to know what is commonplace/acceptable here. [0]: https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/ makefile-options.html [1]: https://wiki.archlinux.org/index.php/Creating_packages#check() signature.asc Description: This is a digitally signed message part.
Running tests in ports Makefiles?
Hello all, Hopefully a quick question, is it common place in the ports tree to run tests for the software being ported in the Makefile or should we just expect/ encourage upstream to do tests for FreeBSD and leave it at that? I ask because one of the ports that I am maintaining is written in Go, uses the standard test suite that is built into the Go tool chain which means no additional dependencies to be able to add this only a slightly longer build time, currently `make package` takes 27.8 seconds on a system with a 16 CPU cores and 32 Gb ram. signature.asc Description: This is a digitally signed message part.
Re: Pkg repository is broken...
On 3/7/20 6:56 AM, Michael Gmelin wrote: > > I worked around the situation locally by setting ALTABI > on `pkg update': > > # ALTABI=FreeBSD:12.0:amd64 pkg update -f > > This allowed me to run > > # pkg upgrade > > without any issues, so I assume none of the about 30 packages I updated > contained a wrong ABI/architecture. > > I verified this by checking: > > # pkg query "%q" | sort | uniq -c >112 FreeBSD:12:* >219 FreeBSD:12:amd64 > > Note that you could also export ALTABI to the environment or set it > in /usr/local/etc/pkg.conf, but I figured that I might forget it in > there. > > Also, it seems like none of my packages were affected and not setting > it on `pkg upgrade' meant that pkg checks for that (at least that's > what I assume it does) and therefore I won't have to deal with > different ABIs in my installed packages later. > > All of this should be really temporary anyway and hopefully be resolved > soon. > > Cheers, > Michael > I'm not screaming either, figured it wouldn't really help speed up fixing things and that the right people were already working on fixing it. I am also still getting this on 12.1-RELEASE, but the ALTABI work around worked for me. signature.asc Description: OpenPGP digital signature
