# Mark Squirrelmail pkg/port as broken in 12.0 and 12.1



## byrnejb (Jan 30, 2020)

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:


```
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.


----------



## talsamon (Jan 30, 2020)

See PR 240328. There is a update patch.


----------



## SirDice (Jan 31, 2020)

byrnejb said:


> 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.


Bugs need to be reported on bugzilla, not here. 






						FreeBSD Bugzilla Main Page
					






					bugs.freebsd.org


----------



## byrnejb (Jan 31, 2020)

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.


----------



## SirDice (Jan 31, 2020)

byrnejb said:


> 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? 









						Chapter 13. Dos and Don'ts
					

A list of common dos and don'ts that are encountered during the FreeBSD porting process




					www.freebsd.org
				











						Chapter 15. Order of Variables in Port Makefiles
					

Order of Variables in FreeBSD Port Makefiles




					www.freebsd.org


----------



## byrnejb (Jan 31, 2020)

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?


----------



## SirDice (Jan 31, 2020)

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?


----------



## byrnejb (Jan 31, 2020)

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.


----------



## talsamon (Jan 31, 2020)

PR 240328 is comitted.


----------



## SirDice (Feb 3, 2020)

byrnejb said:


> 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?


----------



## byrnejb (Feb 3, 2020)

I have no preference.  Just do one or the other.  Doing nothing is the problem.


----------

