|Summary:||[NEW PORT] devel/py-llfuse: Python bindings for the low-level FUSE API|
|Product:||Ports & Packages||Reporter:||Niklaas Baudet von Gersdorff <me>|
|Component:||Individual Port(s)||Assignee:||Kurt Jaeger <pi>|
|Severity:||Affects Only Me||CC:||koobs, me, pi, python, rakuco|
|Priority:||---||Keywords:||easy, feature, patch, patch-ready|
|Bug Depends on:|
|Bug Blocks:||203760, 207715|
Description Niklaas Baudet von Gersdorff 2015-10-14 06:21:02 UTC
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/
Comment 1 Kubilay Kocak 2015-10-14 06:31:02 UTC
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
Comment 2 Kubilay Kocak 2015-10-14 06:31:43 UTC
Also: * Strip trailing slash from pkg-descr: WWW: URL :)
Comment 3 Niklaas Baudet von Gersdorff 2015-10-15 10:45:01 UTC
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.
Comment 4 Niklaas Baudet von Gersdorff 2015-10-15 10:46:49 UTC
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.
Comment 5 Kubilay Kocak 2015-10-15 11:48:23 UTC
@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!
Comment 6 Niklaas Baudet von Gersdorff 2015-10-15 12:40:21 UTC
(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.
Comment 7 Niklaas Baudet von Gersdorff 2015-10-15 13:16:28 UTC
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.
Comment 8 Niklaas Baudet von Gersdorff 2015-10-19 11:04:19 UTC
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.
Comment 9 Martin Wilke 2015-12-05 09:34:40 UTC
Comment 10 Raphael Kubo da Costa 2016-03-05 13:13:37 UTC
miwi, are you still working on this? The patch looks ready to be committed.
Comment 11 Kubilay Kocak 2016-03-05 13:46:02 UTC
@Raphael, this issue is currently assignee-timeout (3 months), it is open to re-assign Also, latest upstream version is 0.43
Comment 12 Martin Wilke 2016-03-05 14:05:49 UTC
Hi, meh i forgot about that pr. Will take care of it tomorrow. Sorry about that!
Comment 13 Niklaas Baudet von Gersdorff 2016-03-07 17:15:20 UTC
(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?
Comment 14 Raphael Kubo da Costa 2016-03-13 11:39:50 UTC
(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.
Comment 15 Raphael Kubo da Costa 2016-03-13 11:40:48 UTC
(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.
Comment 16 Kurt Jaeger 2016-03-20 11:26:07 UTC
Upstream is now at 1.0.
Comment 17 Kurt Jaeger 2016-03-20 11:42:37 UTC
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.
Comment 18 Kurt Jaeger 2016-03-20 12:02:50 UTC
Raised issue upstream for type mismatch, see https://bitbucket.org/nikratio/python-llfuse/issues/87/type-mismatch-causes-build-failure-on
Comment 19 Niklaas Baudet von Gersdorff 2016-03-21 21:37:05 UTC
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.
Comment 20 Kurt Jaeger 2016-03-22 04:47:49 UTC
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.
Comment 21 commit-hook 2016-03-22 05:13:56 UTC
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 <firstname.lastname@example.org> 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
Comment 22 Kurt Jaeger 2016-03-22 05:19:22 UTC
Comment 23 commit-hook 2016-03-22 05:35:59 UTC
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
Comment 24 commit-hook 2016-03-22 07:26:10 UTC
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
Comment 25 Niklaas Baudet von Gersdorff 2016-03-22 14:49:42 UTC
Great. Thanks for committing!