Mark Squirrelmail pkg/port as broken in 12.0 and 12.1

The current Squirrelmail port for 12.0 and 12.1 does not work with any flavour of php7. There is supposed to be a patch but this has not been incorporated into the port. I have a php73 version working that was installed last spring but I cannot install a new site using the current packages. They all result in these warnings being thrown and one cannot proceed past the login:

Code:
Warning: session_set_cookie_params(): Cannot change session cookie parameters when session is active in /usr/local/www/squirrelmail/functions/global.php on line 476

Warning: Cannot modify header information - headers already sent by (output started at /usr/local/www/squirrelmail/functions/global.php:476) in /usr/local/www/squirrelmail/functions/i18n.php on line 468

Warning: Cannot modify header information - headers already sent by (output started at /usr/local/www/squirrelmail/functions/global.php:476) in /usr/local/www/squirrelmail/functions/global.php on line 569

Warning: session_regenerate_id(): Cannot regenerate session id - headers already sent in /usr/local/www/squirrelmail/src/redirect.php on line 86

Consequently, the Squirrelmail port should be marked as broken so that people do not spend several days running down why a package that works on 12.0p5 does not work on 12.0p12.

EDIT - I have since determined that the SM package running on 12.0p5 is in fact running on a FreeBSD-11 jail hosted on a 12.0p5 system.
 
The bug is reported. A patch has been produced. Neither of these facts change that the port itself remains broken and unusable. A situation which should be either noted or fixed, but not left in limbo as is the present case.
 
Neither of these facts change that the port itself remains broken and unusable. A situation which should be either noted or fixed, but not left in limbo as is the present case.
In order for a port to be marked as BROKEN a patch must be applied to the port. See where I'm going here?

 
BROKEN is reserved for ports that currently do not compile, install, deinstall, or run correctly. Use it for ports where the problem is believed to be temporary.
. . .
For instance, use BROKEN when a port:
  • . . .
  • has runtime issues on systems where it is supposed to run fine.
Are you saying that this port is NOT broken?
 
No, that BROKEN line needs to be added to the port's Makefile. In order to get it added to the Makefile a patch needs to be made. But to fix the issue a patch needs to be committed too. So, either way, a patch needs to be committed. Doesn't it make more sense to actually commit the fix then?
 
I am afraid that the logic which says that a port that self-evidently does not work should not be marked as broken escapes me. If the port is not being maintained; and the patch, which has been available since last September, is not going to be added in the immediate future; then why would one wish to distribute it as if everything is just fine, only for the users to find out the hard way that it is not?

Either commit the patch and update the port, or mark the port as broken, I do not care which. One or the other should be done now. I can do neither. But, it is ridiculous that peoples' time is considered to be of such little value that it considered perfectly ok to distribute software that is known to be unusable without at least providing some sort of heads-up about the problem; And then to quibble about whether or not people should be told simply beggars the imagination.
 
I am afraid that the logic which says that a port that self-evidently does not work should not be marked as broken escapes me.
That's not what I said.

Situation 1) Add BROKEN to Makefile, submit patch, maintainer approval, commit patch.
Situation 2) Actually fix the issue. Submit patch, maintainer approval, commit patch.

Both situations require a patch to be made, a maintainer that needs to approve it and the patch to be committed. So, which of these 2 situations would you prefer?
 
Back
Top