Bug 214277 - sysutils/fusefs-rar2fs: BROKEN since GOOGLE_CODE upstream removed.
Summary: sysutils/fusefs-rar2fs: BROKEN since GOOGLE_CODE upstream removed.
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Jason E. Hale
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-11-06 18:34 UTC by Niclas
Modified: 2017-01-18 00:51 UTC (History)
2 users (show)

See Also:


Attachments
Switch to GITHUB, use AUTOTOOLS, update and cleanup (2.60 KB, patch)
2016-11-18 22:15 UTC, Niclas
no flags Details | Diff
Update to 1.23.1 (2.66 KB, patch)
2016-12-31 19:54 UTC, Jason E. Hale
no flags Details | Diff
Update to 1.23.1 (v2) (4.14 KB, patch)
2017-01-05 12:59 UTC, Jason E. Hale
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Niclas 2016-11-06 18:34:11 UTC
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).
Comment 1 Niclas 2016-11-18 22:15:30 UTC
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?
Comment 2 Niclas 2016-12-30 01:18:52 UTC
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?
Comment 3 Jason E. Hale freebsd_committer 2016-12-30 16:36:38 UTC
(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.
Comment 4 Niclas 2016-12-31 04:19:42 UTC
(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?
Comment 5 Jason E. Hale freebsd_committer 2016-12-31 04:47:53 UTC
(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.
Comment 6 Niclas 2016-12-31 05:40:18 UTC
(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.
Comment 7 commit-hook freebsd_committer 2016-12-31 17:41:51 UTC
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
Comment 8 Jason E. Hale freebsd_committer 2016-12-31 19:54:42 UTC
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.
Comment 9 Niclas 2017-01-01 02:56:54 UTC
(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.
Comment 10 Jason E. Hale freebsd_committer 2017-01-01 03:08:58 UTC
(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.
Comment 11 Niclas 2017-01-01 03:37:09 UTC
(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?
Comment 12 Jason E. Hale freebsd_committer 2017-01-01 03:57:32 UTC
(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.
Comment 13 Niclas 2017-01-02 05:01:20 UTC
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.
Comment 14 Jason E. Hale freebsd_committer 2017-01-02 16:48:39 UTC
(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.
Comment 15 Niclas 2017-01-03 14:57:55 UTC
(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"?
Comment 16 Jason E. Hale freebsd_committer 2017-01-03 15:53:02 UTC
(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.
Comment 17 Jason E. Hale freebsd_committer 2017-01-05 12:59:36 UTC
Created attachment 178544 [details]
Update to 1.23.1 (v2)

Updated patch to test if archivers/libunrar5 was built with -DOPENSSL_AES
Comment 18 Niclas 2017-01-07 21:19:27 UTC
(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.
Comment 19 Jason E. Hale freebsd_committer 2017-01-08 02:01:07 UTC
(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.
Comment 20 Niclas 2017-01-08 10:27:13 UTC
(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?
Comment 21 Jason E. Hale freebsd_committer 2017-01-08 12:18:27 UTC
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.
Comment 22 commit-hook freebsd_committer 2017-01-16 23:43:03 UTC
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
Comment 23 commit-hook freebsd_committer 2017-01-16 23:45:08 UTC
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
Comment 24 Jason E. Hale freebsd_committer 2017-01-16 23:50:40 UTC
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!
Comment 25 Niclas 2017-01-17 10:19:07 UTC
(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.
Comment 26 Jason E. Hale freebsd_committer 2017-01-18 00:51:39 UTC
(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.