Page MenuHomeFreeBSD

[WIP] drm ports: move
ClosedPublic

Authored by jmd on Nov 25 2018, 2:58 AM.
Tags
None
Referenced Files
Unknown Object (File)
Tue, Dec 17, 5:48 PM
Unknown Object (File)
Thu, Dec 12, 7:32 PM
Unknown Object (File)
Tue, Dec 10, 12:41 PM
Unknown Object (File)
Tue, Dec 10, 10:31 AM
Unknown Object (File)
Wed, Dec 4, 7:09 PM
Unknown Object (File)
Mon, Dec 2, 12:49 PM
Unknown Object (File)
Sun, Dec 1, 12:43 PM
Unknown Object (File)
Sat, Nov 30, 10:05 AM

Details

Summary
  • move from stable/next/devel to 11.2, 12.0, 13.0 specific ports
  • add a bleeding edge wip port
  • wip port does not build as base is missing the lkpi changes under review
  • add to MOVED
  • add UPDATING entry
Test Plan

poudriere tested on 11.2, 12.0, HEAD - except for wip which misses lkpi changes to base

Diff Detail

Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

Hi!
Apologies for being nitpicky, see inline comments.
I'm also not 100% sure if it's OK to have '.' in the middle of a ports name. I couldn't see anything about it in the porters handbook, but please double check.

MOVED
10644–10645

Might be phabricator, but this looks like a newline in the wrong place.

UPDATING
17–19

If we're basing fbsd11.2 on drm-next and fbsd12.0 on 4.16 (what's now drm-devel) this should probably change.

graphics/drm-fbsd11.2-kmod/Makefile
4

I think we should base this on drm-next-kmod (4.11) instead.

graphics/drm-fbsd12.0-kmod/Makefile
4

I think this should be based on drm-devel-kmod

graphics/drm-fbsd13.0-kmod/Makefile
4 ↗(On Diff #51082)

I thought we would keep drm-devel-kmod for current? Then once 13 is branched, we can copy drm-devel at that time and create fbsd13.0.

I created the necessary git branches to point these ports to. It would be good if we could let 11.2 use 4.11 so we can scrap 4.9 all together (and thus remove some legacy code from lkpi).

Now we have these branches:
drm-v4.11-fbsd11.2 for drm-fbsd11.2-kmod
drm-v4.16-fbsd12.0 for drm-fbsd12.0-kmod

Adding a freebsd version suffix to a git branch indicates that the branch is locked to a specific freebsd release.
For current, they stay the same (drm-vX.YY)

I'm not sure we should update -wip until it can build against head. We're still waiting for patches for 4.18 to be committed.

jmd marked 2 inline comments as done.Nov 25 2018, 7:44 PM

Concerning the versioning: this was intentional. I want to have one move commit that just moves the current status to the new nomenclature followed by individual commits to bring these ports to whatever versions we want them at. That'd allow us, in worst case, to individually revert changes if there are problems.

Concerning the ports names - will check, I didn't see anything in the handbook on first glance and portlint didn't complain either.

MOVED
10644–10645

Good catch, thanks. This probably happened somewhere along the pipeline.

graphics/drm-fbsd13.0-kmod/Makefile
4 ↗(On Diff #51082)

With the introduction of wip, it gets mighty confusing if there is a devel and wip, I think. Maybe drm-fbsdhead-kmod? It's a mouthful...

graphics/drm-fbsd13.0-kmod/Makefile
4 ↗(On Diff #51082)

How about drm-current-kmod for the stable-ish branch and drm-devel-kmod for bleeding edge?

Renamed drm-fbsd13.0-kmod to drm-current-kmod as per offline discussion.
Added more conflicts/updated them for -legacy-
Fixed line break
Updated MOVED/UPDATING

jmd marked 4 inline comments as done.Nov 27 2018, 3:18 AM
jmd added inline comments.
UPDATING
17–19

As discussed - move first.

I'm not sure we should update -wip until it can build against head. We're still waiting for patches for 4.18 to be committed.

It's probably a good idea to wait with this until it builds.

graphics/drm-current-kmod/Makefile
19–20

I think you should do

CONFLICT_INSTALL=   foo bar \
                    baz

instead of appending to the variable.

jmd marked an inline comment as done.

Remove wip port for now.

Update dates.

Everything looks good now.

Remember to do the moves using svn mv :) .

graphics/drm-kmod/Makefile
27–30

When we update the versons, we can probably remove this. If you run that old FreeBSD versions, you are kind of on your own.

This revision is now accepted and ready to land.Dec 9 2018, 11:11 AM

Got committed in r487117 - apparently didn't trigger a close.