Page MenuHomeFreeBSD

devel/ffcall: updated to 1.13, take maintainership
ClosedPublic

Authored by ultima on Jun 30 2017, 5:39 PM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, Dec 4, 6:04 PM
Unknown Object (File)
Mon, Nov 25, 6:12 PM
Unknown Object (File)
Sat, Nov 23, 11:06 PM
Unknown Object (File)
Nov 22 2024, 10:40 PM
Unknown Object (File)
Nov 20 2024, 9:36 PM
Unknown Object (File)
Nov 20 2024, 2:37 PM
Unknown Object (File)
Nov 16 2024, 6:00 PM
Unknown Object (File)
Nov 14 2024, 1:33 AM
Subscribers

Details

Summary
  • Updated to 1.13
  • New maintainer Jov <amutu@amutu.com>
  • License changed to GPLv2+

Changelog: https://lists.freebsd.org/pipermail/freebsd-ports/2017-June/109211.html

PR\: 220250
Sumitted by\: Jov <amutu@amutu.com> (maintainer)
Reviewed by\: lifanov (mentor), matthew (mentor)
Approved by\: lifanov (mentor), matthew (mentor)
Differential Revision\: https://reviews.freebsd.org/DXXXXX

Test Plan

portlint:
WARN: Makefile: for new port, make $FreeBSD$ tag in comment section empty, to make SVN happy.
0 fatal errors and 1 warning found.

poudriere:
103i386
103amd64
110i386
110amd64
12i386
12amd64

Diff Detail

Repository
rP FreeBSD ports repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

The maintainer is planning on changing the name to libffcall after the update.

  • Changed hardcoded portname to ${PORTNAME}

Is there a reason for removing BROKEN_* stuff?
Did something change that would make the port work
on these platforms or did the submitter test it, etc.?

Is there a reason for removing BROKEN_* stuff?
Did something change that would make the port work
on these platforms or did the submitter test it, etc.?

Yes, it was fixed upstream. https://lists.freebsd.org/pipermail/freebsd-ports/2017-June/109211.html

Also, I couldn't find a good changelog to use in the url, I am going to add that post as the changelog as it is informative about the updates.

This looks good to me as it is, but why not do the proposed rename at the same time?

This revision is now accepted and ready to land.Jul 1 2017, 5:30 PM

This looks good to me as it is, but why not do the proposed rename at the same time?

I think it is better to keep the rename and depends change commit together but separated with an update commit because it is two different types of commits. Would it have been okay to roll it into into one commit?

This revision was automatically updated to reflect the committed changes.
head/devel/ffcall/Makefile
26–28

This could probably be:

@${STRIP_CMD} ${STAGEDIR}${PREFIX}/lib/*.so