lives
AbandonedPublic
Actions

Authored by yuri on Nov 19 2017, 5:34 PM.

Details

Reviewers

tcberner
adamw

Summary

Tarball was re-organized by the upstream, the top build directory was moved
to a deeper location. I reviewed all patches, left the needed ones.

I verified that it works. Particularly, there are child projects
in the same tarball that all work. Child packages for them will
be created later.

Diff Detail

Repository

rP FreeBSD ports repository

Lint

No Lint Coverage

Unit

No Test Coverage

Build Status

Buildable 12865
Build 13127: arc lint + arc unit

Event Timeline

yuri created this revision.Nov 19 2017, 5:34 PM

Herald added a subscriber: mat. · View Herald TranscriptNov 19 2017, 5:34 PM

Harbormaster completed remote builds in B12865: Diff 35462.Nov 19 2017, 5:34 PM

tcberner added inline comments.Nov 19 2017, 9:06 PM

graphics/libprojectm/files/patch-src_libprojectM_CMakeLists.txt
26	^ there's `USES=pathfix`, you can check whether that one already catches the pkgconfig fix
graphics/libprojectm/files/patch-src_libprojectM_NativePresetFactory_CMakeLists.txt
7	^ remove this find_library call completely, and use the comment below
16	use `${CMAKE_DL_LIBS}` and upstream it :D (together with the dropped find_library) [1] https://cmake.org/cmake/help/latest/variable/CMAKE_DL_LIBS.html

yuri marked 3 inline comments as done.Nov 19 2017, 10:12 PM

yuri added inline comments.

graphics/libprojectm/files/patch-src_libprojectM_CMakeLists.txt
26	This place is about config.inp.in -> config.inp.in.sample renaming. I moved it out into files/ from the Makefile.
graphics/libprojectm/files/patch-src_libprojectM_NativePresetFactory_CMakeLists.txt
16	This is hosted on SourceForge. Based on my experience, it's much harder to upstream anything when it is hosted on SourceForge. I will try though.
16	Sadly, projectM doesn't accept bug reports: https://sourceforge.net/projects/projectm/ So there's no obvious way to upstream it.

Harbormaster completed remote builds in B12875: Diff 35478.Nov 19 2017, 10:13 PM

tcberner added inline comments.Nov 19 2017, 10:14 PM

graphics/libprojectm/files/patch-src_libprojectM_NativePresetFactory_CMakeLists.txt
16	https://github.com/projectM-visualizer/projectm/issues

yuri marked 4 inline comments as done.Nov 19 2017, 10:18 PM

yuri added inline comments.

graphics/libprojectm/files/patch-src_libprojectM_NativePresetFactory_CMakeLists.txt
16	This looks like a fork. I asked them about their relationship.

yuri marked 2 inline comments as done.Nov 19 2017, 10:18 PM

I got that url from
https://sourceforge.net/p/projectm/code/ci/master/tree/
under

Help

Report issues on GitHub

In D13158#274091, @tcberner wrote:
I got that url from
https://sourceforge.net/p/projectm/code/ci/master/tree/

Ok then, reporting to them.

Upstreamed: https://github.com/projectM-visualizer/projectm/pull/21

Here also the bumping is needed:
graphics/projectm-libvisual
multimedia/qmmp
multimedia/qmmp-qt5

The first one will likely be broken because it is its sub-project.

Bumped PORTREVISIONs of ports depending on libprojectM: multimedia/qmmp multimedia/qmmp-qt5 graphics/projectm-libvisual multimedia/lives

Harbormaster completed remote builds in B12879: Diff 35482.Nov 20 2017, 1:25 AM

yuri retitled this revision from graphics/libprojectm: Update to 2.1.0 to graphics/libprojectm: Update to 2.1.0; Bumped PORTREVISIONs of multimedia/qmmp, multimedia/qmmp-qt5, graphics/projectm-libvisual, multimedia/lives.Nov 20 2017, 1:26 AM

In D13158#274095, @yuri wrote:

Here also the bumping is needed:
graphics/projectm-libvisual
multimedia/qmmp
multimedia/qmmp-qt5

The first one will likely be broken because it is its sub-project.

For shlib-ver bumps, you only need to bump it if it goes from ".so.n" to ".so.(n+m)". Not for ".so.x.n" to ".so.x.(n+m)" .

But it does not hurt to be save :)

graphics/libprojectm/files/patch-src_libprojectM_CMakeLists.txt
9	^CMAKE_DL_LIBS?
18	^CMAKE_DL_LIBS?

Harbormaster completed remote builds in B13061: Diff 35781.Nov 25 2017, 9:10 PM

yuri marked 2 inline comments as done.Nov 25 2017, 9:11 PM

In D13158#275975, @tcberner wrote:

For shlib-ver bumps, you only need to bump it if it goes from ".so.n" to ".so.(n+m)". Not for ".so.x.n" to ".so.x.(n+m)" .

But it does not hurt to be save :)

Actually, it is not really exactly that. You need to bump when the .so's soname changes. Most of the time, it is only the first number, but some time, it can be more:

$ readelf -d /usr/local/lib/libtheora.so|grep SONAME
 0x000000000000000e SONAME               Library soname: [libtheora.so.0]
$ readelf -d /usr/local/lib/perl5/5.24/mach/CORE/libperl.so|grep SONAME
 0x000000000000000e SONAME               Library soname: [libperl.so.5.24]

In D13158#276600, @mat wrote:
In D13158#275975, @tcberner wrote:

For shlib-ver bumps, you only need to bump it if it goes from ".so.n" to ".so.(n+m)". Not for ".so.x.n" to ".so.x.(n+m)" .

But it does not hurt to be save :)

Actually, it is not really exactly that. You need to bump when the .so's soname changes. Most of the time, it is only the first number, but some time, it can be more:
$ readelf -d /usr/local/lib/libtheora.so|grep SONAME
 0x000000000000000e SONAME               Library soname: [libtheora.so.0]
$ readelf -d /usr/local/lib/perl5/5.24/mach/CORE/libperl.so|grep SONAME
 0x000000000000000e SONAME               Library soname: [libperl.so.5.24]