In r422140 sysutils/fusefs-rar2fs was marked BROKEN since GOOGLE_CODE is no more. On the old google page (http://code.google.com/p/rar2fs/) there is a link to the new Github page (https://github.com/hasse69/rar2fs).
Created attachment 177156 [details] Switch to GITHUB, use AUTOTOOLS, update and cleanup Since the port doesn't seem to get updated I tried my luck with it (first attempt compiling without a guide). It seems to build fine. I wanted to update libunrar to 5.4.5 as well, but the libunrar port is 3.x.x and I guess I shouldn't update libunrar4 to 5.x.x. Should I make a new libunrar5 port, how would I keep fusefs-rar2fs and libunrar5 in sync if I did and is it okay to mostly copy the Makefile from another port?
So, this port hasn't been properly updated in 4.5 years, it has been broken for 3.5 months, I made this PR soon to be 2 months ago and I thought myself some basics of the ports system/poudriere/making a diff in svn and uploaded a patch over 1 month ago. Some kind of answer would have been nice after watching this thread almost every day since. Just to know that someone has recognized it more than changing it from new to open. Is there something I should do differently or should I just keep waiting?
(In reply to Niclas from comment #1) Sorry, I got side-tracked with other things and was trying to decide what to do about libunrar because it is silly to have 3 versions of it in the ports tree. From my testing, all the ports that currently use version 3.x will work with 5.x. That and it might be better to just make it a slave port of archivers/unrar. But all of these ports are maintained by different people, so some coordination needs to be done here. For the sake of expediency, it would probably be best for now to repocopy archivers/libunrar4 -> archivers/libunrar5, update that, and mark archivers/libunrar4 DEPRECATED. Then, other ports that use archivers/libunrar can migrate to libunrar5 and then we can get rid of the old 3.x version as well. I'll put some effort into it this week. I already have updates close to being ready, it's just more of a logistics thing at this point.
(In reply to Jason E. Hale from comment #3) Sounds great. So you would rather wait until the archivers/libunrar situation is cleared up before updating sysutils/fusefs-rar2fs than make it work now and update it again at a later stage when the rest is done? The diff I've provided still uses libunrar4 and builds fine in Poudriere on 11.0, 10.3 and 9.3 on amd64 and works at least as well as the old port for me. Also, rar2fs needs the unrar source code to build, is there a way in the ports system to grab that from the archivers/libunrar port that it uses instead of specifying it with its own download link?
(In reply to Niclas from comment #4) > Sounds great. So you would rather wait until the archivers/libunrar situation is cleared up before updating sysutils/fusefs-rar2fs than make it work now and update it again at a later stage when the rest is done? If it's all the same to you, I'd rather get archivers/libunrar5 in first, so we're not mucking about with this port a second time. If I just do a repocopy of libunrar4, then it shouldn't take too long since I won't have to get approvals from 3 people. > Also, rar2fs needs the unrar source code to build, is there a way in the ports system to grab that from the archivers/libunrar port that it uses instead of specifying it with its own download link? Yes, that's the plan. Use the ports system to only extract/patch the libunrar5 source (BUILD_DEPENDS= ${NONEXISTENT}:archivers/libunrar5:patch), then point the rar2fs configure to libunrar5's WRKSRC.
(In reply to Jason E. Hale from comment #5) Works just fine for me. As I said I've been building my own so I was mostly thinking of others that might want to use it and haven't been able to for some time. I'm still pretty new to ports/compiling but since the current maintainer seem to be AWOL, I might be interested in helping out. At least I can make PRs and test when updates come out and help with some basic maintenance. Otherwise I thank you and wish you good luck.
A commit references this bug: Author: jhale Date: Sat Dec 31 17:41:18 UTC 2016 New revision: 430146 URL: https://svnweb.freebsd.org/changeset/ports/430146 Log: Reset maintainership of ports belonging to <joris@vandalon.nl> No known ports activity since 2012; multiple PR timeouts since then Note: archivers/libunrar4 will soon be deprecated by upcoming archivers/libunrar5 sysutils/fusefs-rar2fs has a pending update [1] and potentially a new maintainer PR: 214277 [1] Changes: head/archivers/libunrar4/Makefile head/audio/mp3c/Makefile head/sysutils/fusefs-rar2fs/Makefile
Created attachment 178423 [details] Update to 1.23.1 Niclas, I've added archivers/libunrar5 in r430150. Please try the update I've attached that is designed to build with libunrar5. I've done build tests with all supported versions of FreeBSD (i386, anyways) and it seems fine. I've also reset maintainer, so if you are interested in maintaining this, it's yours.
(In reply to Jason E. Hale from comment #8) poudriere testport on archivers/libunrar5 fails to build using a 11.0 amd64 jail with: strlist.o: could not read symbols: Bad value c++: error: linker command failed with exit code 1 (use -v to see invocation) gmake[1]: *** [makefile:136: lib] Error 1 gmake[1]: Leaving directory '/wrkdirs/usr/ports/archivers/libunrar5/work/unrar' ===> Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to the maintainer. *** Error code 1 All I did was update the ports tree and tried to build.
(In reply to Niclas from comment #9) Yeah, I just got the pkg-fallout reports. Could you try adding CXXFLAGS+=-fPIC to the libunrar5 Makefile? Unfortunately, I don't have an amd64 box to test on.
(In reply to Jason E. Hale from comment #10) Builds fine with CXXFLAGS+=-fPIC. Going to install on a system and try it out. Should I report back just if it works or should I try it for a day or two to see it's not doing anything funny?
(In reply to Niclas from comment #11) You're probably more familiar with its usage than I am. If you feel like it's working properly (or not), just report the results here. No rush.
Tested the port and it wouldn't work. Every time I tried to open a folder with unpacked rars the mount would unmount. I tried building a simpler version of libunrar5 without the extra files, make args and liba and that seems to work. At least I can access the files.
(In reply to Niclas from comment #13) Ah, I see what the problem is. If libunrar5 is built with the OPENSSL_AES option enabled, we also need to pass -DOPENSSL_AES to the rar2fs CFLAGS since it is using the unrar source to build. Otherwise it segfaults.
(In reply to Jason E. Hale from comment #14) Okay... I guess rar2fs should only be built with OPENSSL_AES if libunrar is. Should this be set in bsd.port.pre.mk to check how archivers/libunrar5 was built and do the same? As I've said, I'm new to all of this and can't really find any good documentation on how to figure things like this out. If I just want to check if it works should I just add "CFLAGS= -DOPENSSL_AES"?
(In reply to Niclas from comment #15) Yeah, if libunrar5 is built with the OPENSSL_AES option, rar2fs needs to add -DOPENSSL_AES to its internal UNRAR_CXXFLAGS, but if you just want to test for now, you can add 'CFLAGS+= -DOPENSSL_AES' to the rar2fs Makefile. I'll come up with some sort of check to see if libunrar5 was built with the option. The easiest would probably be to use pkg query. pkg query '%Ok %Ov' libunrar5 | grep '^OPENSSL_AES' | cut -f 2 -d ' ' This will give the state of the option (on/off). From there, we can set the flag by testing the state of the option.
Created attachment 178544 [details] Update to 1.23.1 (v2) Updated patch to test if archivers/libunrar5 was built with -DOPENSSL_AES
(In reply to Jason E. Hale from comment #17) Tested with and without -DOPENSSL_AES and it seems to work fine. Only problem would be if someone builds libunrar5 without -DOPENSSL_AES and have already installed rar2fs or installs rar2fs from pkg-ng. Might be useful to write a post-install warning.
(In reply to Niclas from comment #18) We can't always help if people do silly things. If you change the options of a dependency, everything that depends on it should technically be rebuilt. There are many other cases in the ports tree where if you change an option in a dependency, the ports that depend on it won't work without rebuilding them. We can't always stop people from shooting themselves in the foot, but since it is recommended these days to use synth or poudriere to build packages and upgrade that way, it mostly eliminates the possibility of this scenario happening. I feel comfortable committing as-is. Now, if you would like to be set as the maintainer of rar2fs, let me know. If not, I'll take it so it doesn't get left to ports@, but I'd rather have someone who uses it on a regular basis be the maintainer.
(In reply to Jason E. Hale from comment #19) I did use poudriere and it did rebuild rar2fs. But when I used that as a repo and upgraded my system pkg-ng noticed the change in libunrar5 and reinstalled it but did not reinstall rar2fs. If that is expected behaviour I'm fine with that. Just wanted to take note of it if it wasn't. I'd be happy to help, and since I am looking to make a bug report or two on rar2fs I will be interested to having it up to date. By now you should have probably noticed my weaknesses with ports/building but maintainer-ship is mostly keeping the port reasonably up to date and answering PRs as I understand it. Is there someone I can talk to about this port and the ports system in general to get a bit more useful in the future?
Pkg didn't update it because the versions were the same. If version 1 of my patch was already in the ports tree, version 2 would have required a PORTREVISION bump. Any user that may have rar2fs installed now will have the old version. Since you are testing uncommitted patches, you will have to force the update. Maintaining a port requires little more than what you're doing now. The Porter's Handbook and the documentation in the ports tree itself (CHANGES and the files in the Mk directory) should be your first resource. You can certainly ask questions on the freebsd-ports mailing list or on IRC. Committers will give pointers in PRs if needed. We just ask that some QA is done with portlint and poudriere.
A commit references this bug: Author: jhale Date: Mon Jan 16 23:42:08 UTC 2017 New revision: 431712 URL: https://svnweb.freebsd.org/changeset/ports/431712 Log: Update to 1.23.1 Unbreak fetch (project moved to Github) Take maintainership for now PR: 214277 (based on) Submitted by: Niclas <zappe_1337@hotmail.com> MFH: 2017Q1 (blanket) Changes: head/sysutils/fusefs-rar2fs/Makefile head/sysutils/fusefs-rar2fs/distinfo head/sysutils/fusefs-rar2fs/files/ head/sysutils/fusefs-rar2fs/files/patch-configure.ac head/sysutils/fusefs-rar2fs/pkg-descr
A commit references this bug: Author: jhale Date: Mon Jan 16 23:44:21 UTC 2017 New revision: 431714 URL: https://svnweb.freebsd.org/changeset/ports/431714 Log: MFH: r431712 Update to 1.23.1 Unbreak fetch (project moved to Github) Take maintainership for now PR: 214277 (based on) Submitted by: Niclas <zappe_1337@hotmail.com> Approved by: ports-secteam (blanket) Changes: _U branches/2017Q1/ branches/2017Q1/sysutils/fusefs-rar2fs/Makefile branches/2017Q1/sysutils/fusefs-rar2fs/distinfo branches/2017Q1/sysutils/fusefs-rar2fs/files/ branches/2017Q1/sysutils/fusefs-rar2fs/pkg-descr
I've committed the update and taken maintainership for now. If you have any interest in maintaining in the future, Niclas, let me know since I really don't use this. I'll try to keep it updated nevertheless. Thanks for helping with the testing!
(In reply to Jason E. Hale from comment #24) Sorry if I wasn't clear. I'd be happy to take maintainership of the port. Would it be easy to change the e-mail address at a later time? This is an old "junk" address that isn't regularly monitored.
(In reply to Niclas from comment #25) It's not a big deal to change maintainer email addresses. We do need the maintainer's email address to match the one used for their Bugzilla account (which can be easily changed too), however. That way we know that the PRs are coming from the maintainer and don't get unnecessarily delayed. Why don't you submit the next update and I'll pass it to you then. That will give you time to arrange whatever email address you want to use for FreeBSD. If you have any more questions, you can email me directly at jhale@FreeBSD.org since this is going beyond the scope of this PR.