Page MenuHomeFreeBSD

Add CentOS packages and mark nss as patched
AbandonedPublic

Authored by dbn on Jan 11 2018, 6:33 PM.

Details

Reviewers
tijl
Group Reviewers
Linux Emulation
portmgr
mono
Summary

Commit message:

Add CentOS packages

 - add the following packages:
   - libicu
   - libunwind
   - lttng-ust
   - userspace-rcu (aka urcu)
 - fix pkg-plist for CentOS 7:
   - alsa-plugins-oss
   - alsa-plugins-pusleaudio
   - openssl
Test Plan

Diff Detail

Repository
rP FreeBSD ports repository
Lint
Lint Skipped
Unit
Unit Tests Skipped

Event Timeline

Hmm, I don't know if my suggestion is wise and/or practical (so sorry in advance ๐Ÿ˜… )
Because I saw linux-version of a port I maintain (lttng-ust), it just came to my mind that "can we have such ports via FLAVORs of the native port?"
How do you think about this?

Hmm, I don't know if my suggestion is wise and/or practical (so sorry in advance ๐Ÿ˜… )
Because I saw linux-version of a port I maintain (lttng-ust), it just came to my mind that "can we have such ports via FLAVORs of the native port?"
How do you think about this?

Although it is possible, I think it is cleaner to keep the ports separate due to the differences (and consistency with the existing linux ports). I think a better fit for FLAVORS would be CentOS 6 vs 7 ports, but even then there are many differents (such as version, distinfo) that make it less practical.

In D13869#291343, @dbn wrote:

Hmm, I don't know if my suggestion is wise and/or practical (so sorry in advance ๐Ÿ˜… )
Because I saw linux-version of a port I maintain (lttng-ust), it just came to my mind that "can we have such ports via FLAVORs of the native port?"
How do you think about this?

Although it is possible, I think it is cleaner to keep the ports separate due to the differences (and consistency with the existing linux ports). I think a better fit for FLAVORS would be CentOS 6 vs 7 ports, but even then there are many differents (such as version, distinfo) that make it less practical.

Thanks for the explanation.
Yeah it kinda makes sense now that I look at it from the point of view you are looking at.
Actually I think there are functionalities we can have as "Working properly" in a Linux port while it can be "Not working" in FreeBSD (or other way around ๐Ÿ˜… ), So we can claim even the maintenance approach can be different. So yeah being separated makes more sense for these cases.

There are some failures in the exp-run. Alll relating to missing distinfo where the package is no longer hosted upstream. I'll submit an additional review to fix those issues.

Since thse errors above appears to me to be a preexisting error I don't think it is a blocker for this review.

dbn edited the summary of this revision. (Show Details)
dbn edited the test plan for this revision. (Show Details)
dbn added a subscriber: emulation.

bump rpm version for failing packages.

dbn edited the summary of this revision. (Show Details)
dbn edited the test plan for this revision. (Show Details)

Fix missing pkg-plist. Exp-run now passes

I think this patch is ready to ship. Any comments or approvals?

Can you explain why you need the new libraries?

dbn retitled this revision from Add CentOS packages, unbreak MASTER_SITES and fix nss to Add CentOS packages and mark nss as patched.
dbn edited the summary of this revision. (Show Details)
dbn edited the test plan for this revision. (Show Details)

Update diff due to recent commits.

Pending work:

  • Tidy up the patch for vuxml (i.e. revert from this patch).
  • Check if the changes to EPEL break any of these new ports (they did not depend on setting SUBDIR).
In D13869#296333, @tijl wrote:

Can you explain why you need the new libraries?

We (mono@) need these libraries for our upcoming linux-dotnet ports (see https://reviews.freebsd.org/D13870).

dbn edited the test plan for this revision. (Show Details)

Fix patch for:

  • vuxml entry (ow committed)
  • use SUBDIR for EPEL (per commit)

I believe this patch is ready for committing.

dbn added a reviewer: mono.

I think I committed everything.

All changes committed, thank you :-)

I'm cross posting an issue with the dotnet runtime, which was the reason this patch was created. Not sure where the source of the issue is yet.

https://reviews.freebsd.org/D13870

I've double checked and the issue does not appear to be with this revision. We'll work on the issue in https://reviews.freebsd.org/D13870 and if there is an issue relating to these Linux ports we'll report back.

In D13869#299136, @dbn wrote:

I've double checked and the issue does not appear to be with this revision. We'll work on the issue in https://reviews.freebsd.org/D13870 and if there is an issue relating to these Linux ports we'll report back.

+1