In that case, lets go with accepted if make -VIGNORE shows no error :)

In D19244#412377, @arrowd wrote:

We have 546 haskell ports, and only 37 of them aren't getting deprecated. You want me to add a variable to 509 ports instead of 37? What's the problem with adding and then removing a variable?

Looks fine to me. Please ask for an exp-run before landing, to be o the save side.

Looks good to me if the maintaine accepts/timeouts.

In D19136#409263, @kai wrote:

In D19136#409262, @tcberner wrote:

The whole thing looks a bit abandonware-y...

astro/wmsun has a new home at https://github.com/window-maker/dockapps/tree/master/wmsun (which is also related in some way to https://www.dockapps.net/wmsun) but there's the latest version 1.05.

It might be possible that the current astro/wmsun is a fork that has ceased now. When comparing the ChangeLog files of the GitHub repo (https://github.com/window-maker/dockapps/blob/master/wmsun/ChangeLog) and in the currently used tarball there are some differences:

Github repo:

• flawless continuation from 1.03 up to 1.05
  
  Source tarball:
• jumps from 1.03 to 1.10 with some remarks about the different upstream sources
  
  AFAIK there would be two options: a) Rename the port to astro/wmsun-fork (or similar) and deprecate it b) switch to 1.05 from the GH repository and increase PORTEPOCH
  
  What do you think about it?

The whole thing looks a bit abandonware-y...

Looks good to me.

exp-run of 0.74: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235609

Looks good to me.

Lgtm

There is 0.74 now.. let me update...

Looks good to me.

You need to add kde:5 to uses to be able to USE_KDE :)

Moin moin

Moin moin

Is there a need for multiple django versions? That is, would it not be possible to simply upgrade to 2.1 and call it a day?

Committed with the change to use DISTVERSIONSUFFIX instead of setting DISTNAME.

Looks good to me.

In D18833#404045, @mat wrote:

I think the helpfullness of a helper decreases with the number of existing helpers.
The idea of helpers is to have a few that you can remember and use without having to think about them.
This is getting to be a pretty specific edge case, and I feel the ports tree does not gain much with this.

grep'ing the ports tree for CMAKE_DISABLE_FIND_PACKAGE, I think that before adding this, it would be nice if people actually used the existing helpers, like CMAKE_BOOL_* first.

In D18840#403614, @duchateau.olivier_gmail.com wrote:

Make Gtk3 default flavor is bad idea, because its support is not good shape. There are lots of warnings due to deprecated methods. Moreover import of exo (from Xfce project) is very old too (taken from 0.10.x branch, upstream needs to use the 0.12.x branch, it is compatible with both version).

libfm-gtk should probalby start as an svn cp of libfm.

@arrowd looks good.

Rename to CMAKE_DISABLE_FIND_ON/OFF

p.s. I will also add this to cmake.mk afterwards to handle the non-option cases.

In D18833#402044, @adamw wrote:

I don't feel the greatest about the opt_CMAKE_DISABLE name. It implies that it disables a feature, similar to opt_CONFIGURE_ENABLE. Can it be named something that's more specific to what it does? opt_CMAKE_DISABLE_DEP, opt_CMAKE_DISABLE_PACKAGE something like that?

We could simply call it <opt>_CMAKE_DISABLE_FIND_PACKAGE_<ON/OFF> which would be the most accurate name, but, also the most tedious to write :D -- If you have no objections to the length of it, I will go with that.

Looks good to me.

100% less .warning