Created attachment 251606 [details] using portmaster, this is the failure error
this affects both sysutils/android-file-transfer 4.2 and 4.2.1 on both FreeBSD 14.0-STABLE and FreeBSD 14.1-RELEASE the error occurs during the attemp to install the port, but the install process cannot find the Python file: /usr/ports/sysutils/android-file-transfer/work/.build/python/aftl.cpython-311.so I know little about Python so I have no idea where to look for this failure. I hope someone can shed some light on this problem since it has been a problem here for me for a couple of weeks. Thanks in advance. .
Poudriere can't build too, same error: install: /wrkdirs/usr/ports/sysutils/android-file-transfer/work/.build/python/aftl.cpython-311.so: No such file or directory But there is a file in this directory: /wrkdirs/usr/ports/sysutils/android-file-transfer/work/.build/python/aftlNone # file /wrkdirs/usr/ports/sysutils/android-file-transfer/work/.build/python/aftlNone /wrkdirs/usr/ports/sysutils/android-file-transfer/work/.build/python/aftlNone: ELF 64-bit LSB shared object, x86-64, version 1 (FreeBSD), dynamically linked, for FreeBSD 14.0 (1400097), stripped In the post-install-PYTHON-on target: ${INSTALL_LIB} ${BUILD_WRKSRC}/python/aftl${PYTHON_EXT_SUFFIX}.so Maybe can install "aftlNone" to PYTHONPREFIX_SITELIBDIR but don't know what should its name. Try and test it and let me know. And a workaround (I know python a little): you can disable python-option.
Thank you, Udvari! Taking away the Python option allowed it to build using portmaster. I hope that this missing feature will not impact the operation of android-file-transfer. Remain to be seen -- needs some testing. Thanks again.
Created attachment 252005 [details] git patch Hi. I managed to solve the compilation issue with python... It is basically due to a newer version of cmake. The patch in attachment contains the necessary patches to make everything compile again. :-)
(In reply to gatekeeper from comment #4) Great work! In patch-python_FindPythonLibsNew.cmake there are some indentation modification (for example the first change of return()). Are they important?
OK, let me check that... I basically just took 1-to-1 the latest FindPythonLibsNew.cmake file, as it contains some fixes that allow the program to compile - this new file is reflected in the patch, and therefore you see some indentation issues. I can check if I can make the patch smaller, and/or fix indentation issues...
Sorry for the delay in the reply. I have now looked into the file; basically this is what happen - I have replaced the FindPythonLibsNew.cmake file with the newest version (note, not from the android-file-transfer project, but from the original project hosting the FindPythonLibsNew - which has same copyright, it is just more recent). The later version works flawlessly with the current version of cmake, that is why I just replaced and created the patch as-is. NOTE - I have compiled the project using poudriere on all the current three major platforms without problems (13.3, 14.0 and 14.1). As for the new indentation - I am mostly sure that it is not relevant. However, if I fix the indentation to match the android-file-transfer version, then this file will diverge for newer versions of FindPythonLibsNew, as the indentation was added upstream (in the FindPythonLibsNew repo). There are several ways forward - 1. either I track down exactly which changes made the program compile and provide a minimal patch; 2. just take the FindPythonLibsNew as-it-is since it is the same as the original developer of that file, or; 3. fix indentation to match the current android-file-transfer project. In my opinion, I think that option 2 would be better, as it makes a FindPythonLibsNew file match its latest version. What do you think? I have also noticed that the project currently has no maintainer - if it is OK, I can take ownership of this :-)
Why don't you update to 4.3? Did you try it? If it builds and works then doesn't need patch :) "if it is OK, I can take ownership of this" Of course :)
OK, awesome. I will try to update the program to version 4.3. Currently I am not so happy because my tests shows that although the program compiles, it is very buggy and is not really working properly. I tried connecting an Android phone and, although aft-mtp-mount does see the phone and can mount it, when I try to access the contents of the phone, the app becomes very unstable. I even had to reboot because (most likely) fusefs crashed? Maybe I can cross check against Linux, to eliminate any potential error related to the phone. Also, the app supports QT5, and I am not sure about the status related to QT6. Most likely the app would require different flavors for both qt versions. But I need to check if it even compiles under QT6. Finally, i think that there must be some issue with the Makefile, because since it compiles with python, it should have a python version prefix, i guess? The weird thing is that it is compiling with poudriere, but when I issue "make" in the /usr/ports subfolder, without poudriere, it again fails to compile! But now the reason is that (I suppose) I have two python versions installed 3.9 and 3.11, and the compilation under Ninja discovers python3.9 (which is the system default), but the ports system is somehow expecting to find/use version 3.11...? So, this needs to be checked also...
Created attachment 252112 [details] git patch This current patch includes the following: - update to android-file-transfer v4.3 - disabled building PYTHON by default. NOTE: it can still be built manually through enabling it manually with "make config"; Why did I disable it? because I think that this should not be compiled by default - the python library part should be made available through a separate package, e.g. py39-android-file-transfer-linux, or py311-android-file-transfer-linux. I welcome criticism on this decision :-) - FUSE is now disabled by default. Like python, it can still be compiled manually (make config). The issue here (see comment #9) is that the project warns that libusb is broken, in particular for Fuse, as it uses partial read/writes. Since using MTP+Fuse led to crashed my system, I disable this option by default. Could even be considered to be fully disabled until it is supported upstream...? - I have disabled the libusb debug option in the code. this makes the software much more clean and usable in the command line. I have tested the cli tool and it works fine. - In FindPythonLibsNew.cmake, I am now only changing what absolutely needs to be changed, making the patch smaller and more maintainable - After all these changes, I have tested building the port with poudriere in 13.3, 14.0 and 14.2 (all current major three releases) - all looks good - I have fixed one portlint error, but portlint still complains about the following: FATAL: PLIST_FILES: files cannot contain %%FOO%% variables. Use make variables and logic instead WARN: Makefile: new ports should not set PORTREVISION. 1 fatal error and 1 warning found. Please advise if this is OK. In particular the PLIST_FILES is what is currently in the main branch (i.e. is already failing portlint...)
(In reply to gatekeeper from comment #10) It seems okay, agree with your suggestions. Small notes: - remove PORTREVISION - please check "portfmt -D Makefile" and "portclippy Makefile" (parts of ports-mgmt/port-fmt) - you can change %%PYTHON_SITELIBDIR%% to ${PYTHON_SITELIBDIR} and %%PYTHON_EXT_SUFFIX%% to ${PYTHON_EXT_SUFFIX} in Makefile. The %%....%% form is used in pkg-plist. - where is files/patch-python_FindPythonLibsNew.cmake from? Did you obtain from Debian? Great work! (I used this port some years ago and I found it buggy too. Now I'm using a small FTP-server application on phone.)
Created attachment 252121 [details] git patch Nice! Thank you for the hints - I did not know about portfmt and portclippy. These are certainly very useful and I will take them into consideration in the future :-) As for the FindPythonLibsNew.cmake file, I took it from here: https://github.com/pybind/pybind11/blob/master/tools/FindPythonLibsNew.cmake (Another alternative to running an ftp server is using fusefs-jmtpfs; maybe you can give it a try; for me it worked great out-of-the-box and it runs really smoothly, i.e. is not unstable)
(In reply to gatekeeper from comment #12) "As for the FindPythonLibsNew.cmake file" Why don't you copy from py311-pybind11 package? It's a dependency already. You can put it into post-extract target (${CP}...).
(In reply to Zsolt Udvari from comment #13) That is a really nice idea, but there are some issues with that. When running with poudriere, I cannot get the file at the post-extract stage; tried to find the file with poudriere interactive mode, and apparently that dependency it is not yet available at that stage. If I try at pre-build stage instead, poudriere compiles properly since I can copy the file, but I run into another (nasty) problem. I forgot to mention in my previous posts that I needed to fix the FindPythonLibsNew.cmake file to cover the case when the package is compiled locally with make, e.g. under /usr/ports; Now, copying the file in the pre-build stage makes poudriere happy, but when you go to /usr/ports/sysutils/android-file-transfer and issue a make manually, you get a compiler error (at least on my system that has python 3.9 and 3.11 installed). Why? Because I forgot to mention something in my previous posts... We still need to fix the FindPythonLibsNew.cmake in the following way: replace PYTHON_EXECUTABLE with Python_EXECUTABLE. Note the latter variable is the one that Uses/python.mk provides. This fix is necessary for cmake to know exactly which python version should be compiled for, not just that the system default.. Since my system has 3.9 per default but ports expects to compile with the latest (i.e. 3.11), then the wrong library version is compiled which results in an error. For poudriere all is well since, I guess, only a single python version is placed in the container while compiling and therefore all goes well.. Now... this probably means that the pybuild11 package contains a bug - since the ports build system uses Python_EXECUTABLE instead of PYTHON_EXECUTABLE, I guess that any other port that requires FindPythonLibsNew.cmake will have a problem... I am not sure how to deal with this problem and, if the issue is fixed directly in pybuild311 what are the possible consequences for all other ports that might depend on this... Maybe the owner of the pybuild11 could have a look? For now, I guess that having the patch as I provided is the safest way to compile the android-file-transfer (both with poudriere and with local build) and not cause too many issues elsewhere? Note: I also tried to get a patch that would run after the $(CP) from pybuild11, but could not make it work, since before applying the patch the file should have been copied already. Since copying works at the pre-build, it is too late to apply patches :-( Also note - maybe it is a good option to disable PYTHON altogether, as I propose, since it really makes less sense to get a python library from this package; IMHO, a new port should be created, that provides py39-android-file-transfer, py311-android-file-transfer, etc... But in that case, anyhow, the same issue will occur with the FindPythonLibsNew.cmake file Any suggestions on how to handle this? BTW - thanks for all the help and hits - I am learning quite a lot along the way :-)
Hi. Are there any additional comments/suggestions, or is it OK to approve the current patch proposal? Thanks :-)
(In reply to gatekeeper from comment #15) Sorry, I forgot it. "Also note - maybe it is a good option to disable PYTHON altogether, as I propose, since it really makes less sense to get a python library from this package; IMHO, a new port should be created, that provides py39-android-file-transfer, py311-android-file-transfer, etc..." I think it would be the best solution. The python library should be an another package. And IMHO should remove entire python from this port (doesn't need python-option).
(In reply to Zsolt Udvari from comment #16) OK, let me try to do that. I will remove the python dependency on this port and create a new one named py-android-file-transfer. Short question about process, though: should I create a new bug report for the new port, or can I just create the py-android-file-transfer and bundle with the current patch (i.e. one patch to rule them all :-))? Again, thanks a lot for your time and help!
I think the py-android-file-transfer port isn't important. Update this port and if you've time and lust create the python binds. If someone miss this port (s)he can create too :)
Created attachment 252233 [details] git patch In this patch, I have removed the Python compilation, as suggested. I have also removed the dependency to (lib)readline, as the program was compiling with a stub before anyways...
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=437113a921358bf4903d84921ced729d173ec2c6 commit 437113a921358bf4903d84921ced729d173ec2c6 Author: gatekeeper <tiago.gasiba@gmail.com> AuthorDate: 2024-07-23 04:56:41 +0000 Commit: Zsolt Udvari <uzsolt@FreeBSD.org> CommitDate: 2024-07-23 05:03:26 +0000 sysutils/android-file-transfer: update to 4.3 Submitter takes maintainership. Remove Python option because this port install files under PYTHON_SITELIBDIR (must use pyXY prefix). Disable libusb debug option in code: this makes the software much more clean and usable in the command line. Pet portfmt. PR: 279895 sysutils/android-file-transfer/Makefile | 49 +++++++++------------- sysutils/android-file-transfer/distinfo | 6 +-- .../patch-mtp_backend_libusb_usb_Context.cpp (new) | 11 +++++ 3 files changed, 33 insertions(+), 33 deletions(-)
Committed, thanks!