Created attachment 162013 [details] py-llfuse.shar I ported this, next to devel/py-dugong, as a dependency of net/s3ql. --- Python-LLFUSE is a set of Python bindings for the low level FUSE API. It requires at least FUSE 2.8.0 and supports both Python 2.x and 3.x. It runs under Linux, OS-X, FreeBSD and NetBSD. WWW: https://bitbucket.org/nikratio/python-llfuse/
Hi Niklass, thanks for your submission. On initial review: * Use CHEESESHOP for MASTER_SITES (it handles fetching things from PyPI for you * Python packages can/should have 'python' added as a secondary CATEGORIES * Use the exact upstream setup.py description= field for COMMENT where its suitable. In this case "Python bindings for the low-level FUSE API" * Add LICENSE_FILE=/path/to/license if one exists in the WRKSRC (extracted tarball) Please also provide QA results as attachments to this issue: * portlint -AC output * poudriere testport (or bulk -t) output If the above identify any issues, please address them (where appropriate and not a false positive), and update your patch (shar) Tip: Set DEVELOPER=yes in /etc/make.conf if you haven't already
Also: * Strip trailing slash from pkg-descr: WWW: URL :)
Created attachment 162062 [details] py-llfuse.shar, updated version after comments #1 and #2 I addressed all the issues you mentioned and updated the shar file. `portlint -AC` looks fine. There are some warnings when `poudriere testport`. I will mention them in my next upload when uploading the entire output of testport.
Created attachment 162063 [details] Output of `poudriere testport`with 4 warnings `poudriere testport` looks fine but it generates 4 warnings. I don't know python at all. Shall I forward the issues to the maintainer upstream? --- cc -DNDEBUG -O2 -pipe -fstack-protector -fno-strict-aliasing -fPIC -I/usr/local/include/python3.4m -c src/llfuse/capi.c -o build/temp.freebsd-10.1-RELEASE-p22-amd64-3.4/src/llfuse/capi.o -I/usr/local/include/fuse -D_FILE_OFFSET_BITS=64 -DFUSE_USE_VERSION=28 -Wall -Wextra -Wconversion -Wno-sign-conversion -DLLFUSE_VERSION="0.41.1" -Wno-unused-but-set-variable -Wno-maybe-uninitialized -DHAVE_STRUCT_STAT_ST_ATIMESPEC warning: unknown warning option '-Wno-unused-but-set-variable'; did you mean '-Wno-unused-const-variable'? [-Wunknown-warning-option] warning: unknown warning option '-Wno-maybe-uninitialized'; did you mean '-Wno-uninitialized'? [-Wunknown-warning-option] In file included from src/llfuse/capi.c:13: src/llfuse/capi_freebsd.c:22911:23: warning: implicit conversion loses integer precision: 'ssize_t' (aka 'long') to 'int' [-Wshorten-64-to-32] __pyx_v_ret = extattr_set_file(__pyx_v_cpath, __pyx_v_cnamespace, __pyx_v_cname, __pyx_v_cvalue, __pyx_v_len_); ~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ src/llfuse/capi_freebsd.c:23423:37: warning: comparison of integers of different signs: 'Py_ssize_t' (aka 'long') and 'size_t' (aka 'unsigned long') [-Wsign-compare] __pyx_t_3 = ((__pyx_v_ret == __pyx_v_bufsize) != 0); ~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~ 4 warnings generated.
@Niklaas, They are compiler warnings, so you *can* report them upstream. Don't forget to let them know which compiler version generated these warnings. They may or may not fix the code itself, but may set compiler arguments to turn certain warnings off. Please set maintainer-approval (+) on the patch you are happy to have committed, it's our way of knowing 'its ready' Thanks again for your contribution!
(In reply to Kubilay Kocak from comment #5) Thanks again for all your help. I am more than happy to contribute to the ports collection and help the FreeBSD community. I'll inform upstream about the warnings.
Created attachment 162065 [details] Shar file Sorry, I realised that somehow an additional tab made it into the Makefile. This is an update of the shar file.
Created attachment 162203 [details] Shar file I realised that I uploaded the wrong version of the shar file that contains a stupid typo. Eventually, this should be fine now. The output of testport remains the same.
Take.
miwi, are you still working on this? The patch looks ready to be committed.
@Raphael, this issue is currently assignee-timeout (3 months), it is open to re-assign Also, latest upstream version is 0.43
Hi, meh i forgot about that pr. Will take care of it tomorrow. Sorry about that!
(In reply to Kubilay Kocak from comment #11) ... whereas the version of the port is 0.41.1. Shall I upgrade the port? Or was the maintainer approval to check whether I haven't forgot about it?
(In reply to Niklaas Baudet von Gersdorff from comment #13) > (In reply to Kubilay Kocak from comment #11) > > ... whereas the version of the port is 0.41.1. > > Shall I upgrade the port? Or was the maintainer approval to check whether I > haven't forgot about it? The "maintainer-feedback+" flag just indicates that you as the port maintainer has approved this patch. It also shows this bug in the "Ports: Maintainer Approved" saved search in Bugzilla, which is helpful for committers to see that a patch is ready to be landed. You can update to 0.41.1 if you want, but I don't think it is required. With that said, your LICENSE in the Makefile needs to be updated. "LGPL" is not defined in bsd.licenses.db.mk, looking at the source code you need "LGPL20+" instead.
(In reply to Raphael Kubo da Costa from comment #14) > The "maintainer-feedback+" flag just indicates that you as the port > maintainer has approved this patch. It also shows this bug in the "Ports: > Maintainer Approved" saved search in Bugzilla, which is helpful for > committers to see that a patch is ready to be landed. Sorry, I meant the "maintainer-approval+" flag.
Upstream is now at 1.0.
Created attachment 168421 [details] shar-1.0 attached is the port, updated to 1.0, portlint is fine, testbuilds on 11a, 10.2a+i, 9.3a are all fine. Submitter: please approve or comment.
Raised issue upstream for type mismatch, see https://bitbucket.org/nikratio/python-llfuse/issues/87/type-mismatch-causes-build-failure-on
Kurt, thanks. I don't have the resources to testport on current, but I testported on 10.2 and it's fine. Testport on 9.3 is just running, but it should be fine too. It's one of the first ports I made, so I guess you're much more experienced, but I noticed two things: 1. You omitted LICENSE_FILE. Is this for some reason? 2. You also removed the strip command, so I get a warning in stage-qa. In case that's all right, please shortly comment why. For me to learn for the next port. Thanks for correcting the other minor issues in the Makefile.
I changed the license from LGPL to LGPL20+, which is one of the licenses in bsd.licenses.db.mk, so LICENSE_FILE is not needed. I assume that matches the license the author wants to apply (but I'm not a lawyer 8-) You're right about the strip, I re-added the STRIP.
A commit references this bug: Author: pi Date: Tue Mar 22 05:13:30 UTC 2016 New revision: 411634 URL: https://svnweb.freebsd.org/changeset/ports/411634 Log: New port: devel/py-llfuse Python-LLFUSE is a set of Python bindings for the low level FUSE API. It requires at least FUSE 2.8.0 and supports both Python 2.x and 3.x. It runs under Linux, OS-X, FreeBSD and NetBSD. WWW: https://bitbucket.org/nikratio/python-llfuse PR: 203759 Submitted by: Niklaas Baudet von Gersdorff <niklaas@kulturflatrate.net> Changes: head/devel/Makefile head/devel/py-llfuse/ head/devel/py-llfuse/Makefile head/devel/py-llfuse/distinfo head/devel/py-llfuse/files/ head/devel/py-llfuse/files/patch-src_llfuse.c head/devel/py-llfuse/files/patch-src_xattr.h head/devel/py-llfuse/pkg-descr
Committed, thanks!
A commit references this bug: Author: pi Date: Tue Mar 22 05:35:22 UTC 2016 New revision: 411635 URL: https://svnweb.freebsd.org/changeset/ports/411635 Log: devel/py-llfuse: fix STRIP_CMD PR: 203759 Pointy-hat to: pi Changes: head/devel/py-llfuse/Makefile
A commit references this bug: Author: pi Date: Tue Mar 22 07:25:37 UTC 2016 New revision: 411638 URL: https://svnweb.freebsd.org/changeset/ports/411638 Log: devel/py-llfuse: Another attempt to fix STRIP PR: 203759 Submitted by: jbeich Changes: head/devel/py-llfuse/Makefile
Great. Thanks for committing!