Poudriere broken!!!

[Einar Bjarni Halldórsson]

Hi,

I’m using poudriere-devel and it’s completely broken now

The web UI looks modern and actually works. Safari always had a problem not 
updating with info about ongoing builds, that’s fixed now.
How am I supposed to work with something like this, when I’ve gotten used to 
the old UI?!? I’m starting a petition to bring back the old broken poudriere UI!

Only joking, I love the new UI. Great work!

einar

Re: Proposed ports deprecation and removal policy

[Dag-Erling Smørgrav]

Florian Smeets  writes:
> Ports can be removed immediately if one of the following conditions is met:
>
> - Upstream distfile is no longer available from the original
>   source/mirror (Our and other distcaches e.g. Debian, Gentoo, etc do
>   not count as "available")

Strong disagree, give the maintainer a chance to find an alternate
mirror or self-host.

> - Upstream WWW is unavailable: deprecate, remove after 3 months

That's the opposite of immediate removal

> - BROKEN for more than 6 months

Agree but that's hardly immediate

> - has known vulnerabilities that weren’t addressed in the ports tree
>   for more than 3 months

Agree but that's hardly immediate

DES
-- 
Dag-Erling Smørgrav - d...@freebsd.org

Re: Proposed ports deprecation and removal policy

[Cy Schubert]

In message <864jdrzcov@ltc.des.dev>, =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?
= w
rites:
> Florian Smeets  writes:
> > Ports can be removed immediately if one of the following conditions is me=
> t:
> >
> > - Upstream distfile is no longer available from the original
> >   source/mirror (Our and other distcaches e.g. Debian, Gentoo, etc do
> >   not count as "available")
>
> Strong disagree, give the maintainer a chance to find an alternate
> mirror or self-host.

+1

>
> > - Upstream WWW is unavailable: deprecate, remove after 3 months
>
> That's the opposite of immediate removal
>
> > - BROKEN for more than 6 months
>
> Agree but that's hardly immediate
>
> > - has known vulnerabilities that weren=E2=80=99t addressed in the ports t=
> ree
> >   for more than 3 months
>
> Agree but that's hardly immediate
>
> DES
> --=20
> Dag-Erling Sm=C3=B8rgrav - d...@freebsd.org
>


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX: Web:  https://FreeBSD.org
NTP:   Web:  https://nwtime.org

e^(i*pi)+1=0

Re: Proposed ports deprecation and removal policy

[Xin LI]

On Wed, Feb 28, 2024 at 11:22 AM Florian Smeets  wrote:

> Dear ports community,
>
> as the removal of ports is a recurring source of friction and dispute we
> would like to add a ports removal and deprecation policy to the porters
> handbook.
>
> We tried to find a sensible middle ground between too fast removal and
> keeping unmaintained and abandoned upstream software in our ports tree
> forever.
>
> When can or should ports be deprecated or removed?
>
> This policy should give some guidance on when ports can or should be
> removed. In general ports should not be removed without reason but if a
> port blocks progress it should be deprecated and subsequently removed.
> In general, if a ports blocks progress for some time it will be removed
> so that progress can be made. For more details see below.
>
>
> Ports can be removed immediately if one of the following conditions is met:
>
> - Upstream distfile is no longer available from the original
> source/mirror (Our and other distcaches e.g. Debian, Gentoo, etc do not
> count as "available")
>

I have no objection with removing a port if upstream all died and nobody
cared, but removing them "immediately" seems to be too harsh and not
friendly for smaller software vendors.  For example, bzip2 got their domain
name stolen, but the project didn't really die and continued at
sourceware.org.  Please give the maintainer some time (e.g. by marking the
port as DEPRECATED with a timeout time, maybe two weeks, maybe a month or
even 3 months).


> - Upstream WWW is unavailable: deprecate, remove after 3 months
>

Could you please explain why upstream WWW would warrant a removal?  (I
think removing the WWW= entry if the website is compromised or is no longer
available is perfectly fine, but why remove the port itself?)


> - BROKEN for more than 6 months
>

I think if a port won't build on any of the official FreeBSD.org
package cluster, the port is marked BROKEN with a deprecation period of 6
months (personally I think it's too long, 3 months should be the maximum).

This should include ports that are IGNORED for all supported platforms and
conditionally broken with all supported defaults: they should have correct
dependency and are able to build in at least one poudriere environment.


> - has known vulnerabilities that weren’t addressed in the ports tree for
> more than 3 months
>

I think this is somewhat too vague.  Known to whom?  Registered at
cve.mitre.org?  In vuxml?

Probably something like: if vuxml thinks the port is vulnerable, then it's
marked FORBIDDEN immediately with a 3 month timeout (personally I think 2
weeks would be the maximum) by some automated script, and after the set
time of being FORBIDDEN, the port is eligible for immediate removal.


> A port can be deprecated and subsequently removed if:
>
> - Upstream declared the version EOL or officially stopped development.
> DEPRECATED should be set as soon as the planned removal date is know.
> (It is up to the maintainer if they want to remove the port immediately
> after the EOL date or if they want keep the port for some time with
> backported patches. Option two is *not* possible without backporting
> patches, see vulnerable ports) The general suggestion is that EOL
> versions should not stay in the ports tree for more than 3 months
> without justification.
> - The port does not adapt to infrastructure changes (i.e. USE_STAGE,
> MANPREFIX, compiler updates, etc.) within 6 months. Ports should be set
> to DEPRECATED after 3 months and can be removed after 6
>
>
> Reasons that do not warrant removal of a port:
>
> - Software hasn’t seen a release in a long time
> - Upstream looks inactive for a long time
>

IMHO, a lot of "friction" comes from lack of communication and not port
getting removed themselves.

For example, one of my port gets marked as DEPRECATED because a dependency
was deprecated and scheduled for removal after 1 month, without any email
telling me so (the port doesn't have a lot of releases and there isn't any
release during that "parole" month), and it gets removed after that.  So in
order to know there is an ongoing deprecation of the port, I as a port
maintainer would have to either watch the directory for any changes, or
read all ports-git commit messages or at least a filtered version of it,
and that's burdensome and inefficient use of developer time at best.

What I would love to see happen is that, when a port gets marked as
DEPRECATED, there is an automated system that sends me notification with
something like:

ACTION REQUESTED: X new ports you maintain is marked as DEPRECATED

or, if it's just one port:

ACTION REQUESTED: category/port is marked as DEPRECATED and will be removed
on 1 month

Hello,

This is a friendly notification from FreeBSD port deprecation bot.  In the
latest scan the following ports you maintain are marked as DEPRECATED:

Port name | Removal date
category/port | 2024-03-30
..

and that email gets sent every 7 days until the port is removed or 

Merge access review + QT6 update best practices

[henrichhartzer]

Hi everyone,

I have two requests for help.

First one is that I updated one of my ports, but I don't have merge access. 
Would appreciate it if someone can review. Ideally would merge to main + 
backport to quarterly. If there's something missing in the report that should 
be there, please let me know!

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277386

Second is for net-im/telegram-desktop that has no maintainer. It was working 
great for me until a QT6 update (6.6.1->6.6.2). Surprisingly, even with that 
minor of a bump, Telegram Desktop quit launching. I'm not sure if that's normal 
for QT6 or not.

I can easily contribute a patch to update it, forcing a new package version 
release, but it seems like there might be a better practice to link this to QT6 
updates where it's automatically rebuilt when they are updated.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277366

One simple option might be to backport the latest version in main to quarterly, 
which would force a rebuild, presumably with the latest QT6. I still don't know 
if that's ideal, however.

Thank you for your thoughts and insights.

Truly,

-Henrich

Re: Proposed ports deprecation and removal policy

[Miroslav Lachman]

On 29/02/2024 20:26, Xin LI wrote:

[...]

Could you please explain why upstream WWW would warrant a removal?  (I 
think removing the WWW= entry if the website is compromised or is no 
longer available is perfectly fine, but why remove the port itself?)


- BROKEN for more than 6 months


I think if a port won't build on any of the official FreeBSD.org 
package cluster, the port is marked BROKEN with a deprecation period of 
6 months (personally I think it's too long, 3 months should be the maximum).


This should include ports that are IGNORED for all supported platforms 
and conditionally broken with all supported defaults: they should have 
correct dependency and are able to build in at least one poudriere 
environment.


- has known vulnerabilities that weren’t addressed in the ports tree
for
more than 3 months


I think this is somewhat too vague.  Known to whom?  Registered at 
cve.mitre.org ?  In vuxml?


Probably something like: if vuxml thinks the port is vulnerable, then 
it's marked FORBIDDEN immediately with a 3 month timeout (personally I 
think 2 weeks would be the maximum) by some automated script, and after 
the set time of being FORBIDDEN, the port is eligible for immediate removal.


Even ports of large projects, or projects on which hundreds or thousands 
of other ports depend, have had an unresolved security issue for much 
longer. For example, Python had an unpatched bug for over a month. 
Removing such a port after 2 weeks does more harm than good.
Each user can check the pkg audit and decide for themselves if the 
security issue affects their environment and whether to 
install/retain/uninstall such a package. Removing ports for whatever 
reason after 2 weeks is useless.


In general, I would like to see removal time frames taken not strictly 
from the date of discovering the technical or security problem, but with 
respect to quarterly branches. A lot of users use quarterly - for 
stability - and then are unpleasantly surprised that a port has been 
removed without seeing any warning. And if somebody finds a way to 
revert it, it will probably get reverted  after the next quarter, again 
more harm than good.




A port can be deprecated and subsequently removed if:

- Upstream declared the version EOL or officially stopped development.
DEPRECATED should be set as soon as the planned removal date is know.
(It is up to the maintainer if they want to remove the port immediately
after the EOL date or if they want keep the port for some time with
backported patches. Option two is *not* possible without backporting
patches, see vulnerable ports) The general suggestion is that EOL
versions should not stay in the ports tree for more than 3 months
without justification.
- The port does not adapt to infrastructure changes (i.e. USE_STAGE,
MANPREFIX, compiler updates, etc.) within 6 months. Ports should be set
to DEPRECATED after 3 months and can be removed after 6


Reasons that do not warrant removal of a port:

- Software hasn’t seen a release in a long time
- Upstream looks inactive for a long time


IMHO, a lot of "friction" comes from lack of communication and not port 
getting removed themselves.


+1

For example, one of my port gets marked as DEPRECATED because a 
dependency was deprecated and scheduled for removal after 1 month, 
without any email telling me so (the port doesn't have a lot of releases 
and there isn't any release during that "parole" month), and it gets 
removed after that.  So in order to know there is an ongoing deprecation 
of the port, I as a port maintainer would have to either watch the 
directory for any changes, or read all ports-git commit messages or at 
least a filtered version of it, and that's burdensome and inefficient 
use of developer time at best.


What I would love to see happen is that, when a port gets marked as 
DEPRECATED, there is an automated system that sends me notification with 
something like:


ACTION REQUESTED: X new ports you maintain is marked as DEPRECATED

or, if it's just one port:

ACTION REQUESTED: category/port is marked as DEPRECATED and will be 
removed on 1 month


Hello,

This is a friendly notification from FreeBSD port deprecation bot.  In 
the latest scan the following ports you maintain are marked as DEPRECATED:


Port name     | Removal date
category/port | 2024-03-30
...

and that email gets sent every 7 days until the port is removed or the 
issue is fixed.  Or a bug is created and assigned to the maintainer, etc.


I also remember one case that annoyed me a lot - unequal treatment of 
ports that should have been removed due to deprecated dependencies, but 
some were removed "immediately" and others worked for about another 
year. Yes, these were Python 2.7 dependent ports, where someone was very 
actively removing ports that required Python 2.7 as a build dependency. 
Chromium wasn't removed, but Iridium was, yet it

Re: emulators/mame: Increasing option granularity woes

[Alastair Hogge]

On 2024-02-27 14:24, Gleb Popov wrote:
> On Tue, Feb 27, 2024 at 5:43 AM Alastair Hogge  wrote:
>>
>> however, I do not know how that translates to Makefile
>> targets, like do-install-NON_USER_FACING_OPT-on. Currently the Makefile
>> target is of the ".if somecond FOO= .else BAR= .endif" form.
> 
> I'm afraid you'd still have to write
> 
> post-install:
> .if ${PORT_OPTIONS:MFOO} || ${PORT_OPTIONS:MBAR}
> ...
> .endif
> 
> for optionalizing targets.

Thanks.

Re: Proposed ports deprecation and removal policy

[Tomoaki AOKI]

On Thu, 29 Feb 2024 09:43:38 -0800
Cy Schubert  wrote:

> In message <864jdrzcov@ltc.des.dev>, =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?
> = w
> rites:
> > Florian Smeets  writes:
> > > Ports can be removed immediately if one of the following conditions is me=
> > t:
> > >
> > > - Upstream distfile is no longer available from the original
> > >   source/mirror (Our and other distcaches e.g. Debian, Gentoo, etc do
> > >   not count as "available")
> >
> > Strong disagree, give the maintainer a chance to find an alternate
> > mirror or self-host.
> 
> +1

+1 about this point, too.
Silly service providers changes their brand and domain, WITH THEIR
USERS FORCIBLY INCLUDING.

This immediately causes original upstream URI unavailable, even though
actual project DOES NOT AT ALL CHANGES.

And more importantly, some users dislikes such a domain name policy and
switch service provider. Of course, this causes original upstream URI
dissappear.


> 
> >
> > > - Upstream WWW is unavailable: deprecate, remove after 3 months
> >
> > That's the opposite of immediate removal
> >
> > > - BROKEN for more than 6 months
> >
> > Agree but that's hardly immediate
> >
> > > - has known vulnerabilities that weren=E2=80=99t addressed in the ports t=
> > ree
> > >   for more than 3 months
> >
> > Agree but that's hardly immediate
> >
> > DES
> > --=20
> > Dag-Erling Sm=C3=B8rgrav - d...@freebsd.org
> >
> 
> 
> -- 
> Cheers,
> Cy Schubert 
> FreeBSD UNIX: Web:  https://FreeBSD.org
> NTP:   Web:  https://nwtime.org
> 
>   e^(i*pi)+1=0


-- 
Tomoaki AOKI

Unmaintained FreeBSD ports which are out of date

[portscout]

Dear port maintainers,

The portscout new distfile checker has detected that one or more
unmaintained ports appears to be out of date. Please take the opportunity
to check each of the ports listed below, and if possible and appropriate,
submit/commit an update. Please consider also adopting this port.
If any ports have already been updated, you can safely ignore the entry.

An e-mail will not be sent again for any of the port/version combinations
below.

Full details can be found at the following URL:
http://portscout.freebsd.org/po...@freebsd.org.html


Port| Current version | New version
+-+
cad/ifcopenshell| 0.6.0   | 
blenderbim-240301
+-+
databases/clickhouse| 22.1.3.7| 
v24.2.1.2248-stable
+-+
devel/tinygo| 0.19.0  | v0.31.1
+-+
math/wxmaxima   | 23.12.0 | 
version-24.02.2
+-+


If any of the above results are invalid, please check the following page
for details on how to improve portscout's detection and selection of
distfiles on a per-port basis:

http://portscout.freebsd.org/info/portscout-portconfig.txt

Reported by:portscout!