Re: Subpackages: Update
Hello. It seems that subpackaging of alsa-plugins (audio/alsa-plugins) has been reverted. What is the post-processing when such switching takes place? Might need pkg delete -f -g alsa-plugins-\* because it causes file conflicts? poudriere leaves a subpackage in the package repository. Will these be included by poudriere-pkgclean? I have not yet confirmed anything about them. Since poudriere is building qt5-webengine :) Regards.
Re: Call for help: moving manpages to share/man
On Sun, Jan 21, 2024 at 1:19 PM Gleb Popov wrote:
>
> Ahoy there fellow porters!
>
> portmgr@ is currently working on switching the directory into which
> man pages are installed from "${PREFIX}/man" to "${PREFIX}/share/man".
> It is quite a tedious process, as you might imagine.
> ...
It's been a month since the initial call was made. Despite the fact
that the separate branch approach didn't really work out, the process
of moving manpages to share/man is still ongoing. I'd like to thank
everyone who sent me PRs and plain patches - they were all integrated
into the main branch and all were helpful for our cause.
Still, there is a lot more to process, so I'm making another call for
help, hopefully more concrete this time.
moin@ created a list of problematic ports [1] along with MAINTAINER
field, so you can quickly find if any of your ports need fixing. In
this list "failed" ports are confirmed to be broken if we change the
default mandir prefix in the framework. The "skipped" ports may
probably be dependent on the "failed" ones, so it is better to deal
with "failed" first.
We have an established ways to fix Autotools and CMake-based ports:
- Autotools ports are generally identified by the presence of
GNU_CONFIGURE=yes knob. To fix such a port one should add
GNU_CONFIGURE_MANPREFIX=${PREFIX}/share knob and fix pkg-plist.
- CMake already defaults to a correct mandir location, so CMake ports
usually have some patching that replaces share/man with man. To fix
such ports it is sufficient to remove that patching and then again fix
the plist.
We don't yet care of Meson ports (although it also should be as simple
as the Autotools case). Feel free to skip them for now.
Finally, there are ports with homegrown ad-hoc build systems. There is
no general way to fix them.
When making a mandir-converting change remember to put "Approved by:
portmgr (blanket)" tag into the commit message. This also means that
if you're fixing someone else's port, you don't need to wait for a
maintainer timeout (although it might be still a good idea to wait for
the feedback if the port in question is complex or the change itself
is big).
Thanks in advance to everyone who will help us in this quest.
[1] https://people.freebsd.org/~bofh/dropzone/manprefix-fail.maintainer.txt
Re: Subpackages: Update
On Tue, Feb 20, 2024, at 3:24 PM, Luca Pizzamiglio wrote: > Hi Dan. > > The list of subpackages is available via `make -V SUBPACKAGES` > Probably, the dependencies should also be split by subpackages, when this is > the case. `make -V *_DEPENDS.subpkgname` provides the dependencies > > I can write directly in the github issue some of those things, for reference > > Best regards, > pizzamig Thank you. >From what I can tell, this won't break anything on FreshPorts - rather, >subpackages seem to be additional information. It also seems like FreshPorts >could be easily amended to include that information. i.e. what subpackages >exist for this port? What DEPENDS exist for each subpackage? Anything which >can be extracted by `make -V` is easy for FreshPorts. The parsing of packagesite.yaml by FreshPorts would not be affected - the subpackages will still point back to the origin (e.g. foo/bar): the subpacakges will just magically appear on the right FreshPorts page. Cheers -- Dan Langille d...@langille.org
KSH Alignment
Hi, Would there be any interest in either replacing shells/pdksh with shells/ksh as our default ksh dependency? Or Uses/ksh.mk to select a default ksh for ports? The reason I ask is, shells/ksh has its lineage from the original AT&T ksh (shells/ksh93) and is being actively developed (see shells/ksh-devel). shells/ksh upstream is also the ksh imported into and used by CDE (x11/cde*). My position is, I'd prefer a Uses/ksh.mk. If people are interested, I'm willing to put this task on my todo list. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0
Re: KSH Alignment
On 23/02/24 16:54, Cy Schubert wrote: Hi, Would there be any interest in either replacing shells/pdksh with shells/ksh as our default ksh dependency? Or Uses/ksh.mk to select a default ksh for ports? The reason I ask is, shells/ksh has its lineage from the original AT&T ksh (shells/ksh93) and is being actively developed (see shells/ksh-devel). shells/ksh upstream is also the ksh imported into and used by CDE (x11/cde*). My position is, I'd prefer a Uses/ksh.mk. If people are interested, I'm willing to put this task on my todo list. Hi, As long as there is no compatibilities issues, having a well maintained ksh version makes a lot of sense. pdksh wasn't update for ages and afaik, has no active developer. As the shells/pdksh maintainer you have my blessing. Cheers -- rodrigo
Re: KSH Alignment
In message <787339cd-48e4-49bf-b96e-77aab06ce...@freebsd.org>, Rodrigo Osorio w rites: > This is a multi-part message in MIME format. > > On 23/02/24 16:54, Cy Schubert wrote: > > Hi, > > > > Would there be any interest in either replacing shells/pdksh with > > shells/ksh as our default ksh dependency? Or Uses/ksh.mk to select a > > default ksh for ports? > > > > The reason I ask is, shells/ksh has its lineage from the original AT&T ksh > > (shells/ksh93) and is being actively developed (see shells/ksh-devel). > > shells/ksh upstream is also the ksh imported into and used by CDE > > (x11/cde*). > > > > My position is, I'd prefer a Uses/ksh.mk. If people are interested, I'm > > willing to put this task on my todo list. > > > > > Hi, > As long as there is no compatibilities issues, having a well > maintained ksh version makes a lot of sense. > pdksh wasn't update for ages and afaik, has no active developer. > > As the shells/pdksh maintainer you have my blessing. I'll put together a phabricator review over the next while to add Mk/Uses/ksh.mk. We'll probably need an exp-run too. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0
Re: Call for help: moving manpages to share/man
On 2024-02-23 02:29, Gleb Popov wrote:
On Sun, Jan 21, 2024 at 1:19 PM Gleb Popov wrote:
Ahoy there fellow porters!
portmgr@ is currently working on switching the directory into which
man pages are installed from "${PREFIX}/man" to "${PREFIX}/share/man".
It is quite a tedious process, as you might imagine.
...
It's been a month since the initial call was made. Despite the fact
that the separate branch approach didn't really work out, the process
of moving manpages to share/man is still ongoing. I'd like to thank
everyone who sent me PRs and plain patches - they were all integrated
into the main branch and all were helpful for our cause.
Still, there is a lot more to process, so I'm making another call for
help, hopefully more concrete this time.
moin@ created a list of problematic ports [1] along with MAINTAINER
field, so you can quickly find if any of your ports need fixing. In
this list "failed" ports are confirmed to be broken if we change the
default mandir prefix in the framework. The "skipped" ports may
probably be dependent on the "failed" ones, so it is better to deal
with "failed" first.
Thank you for all your hard work so far!
In an effort to eliminate duplicate work. I'd like to announce my intention
to tackle all of x11. I'd also like to mention pr(1) 276759 addresses
the the one port of mine that's in the list.
Thanks again!
--Chris
We have an established ways to fix Autotools and CMake-based ports:
- Autotools ports are generally identified by the presence of
GNU_CONFIGURE=yes knob. To fix such a port one should add
GNU_CONFIGURE_MANPREFIX=${PREFIX}/share knob and fix pkg-plist.
- CMake already defaults to a correct mandir location, so CMake ports
usually have some patching that replaces share/man with man. To fix
such ports it is sufficient to remove that patching and then again fix
the plist.
We don't yet care of Meson ports (although it also should be as simple
as the Autotools case). Feel free to skip them for now.
Finally, there are ports with homegrown ad-hoc build systems. There is
no general way to fix them.
When making a mandir-converting change remember to put "Approved by:
portmgr (blanket)" tag into the commit message. This also means that
if you're fixing someone else's port, you don't need to wait for a
maintainer timeout (although it might be still a good idea to wait for
the feedback if the port in question is complex or the change itself
is big).
Thanks in advance to everyone who will help us in this quest.
[1] https://people.freebsd.org/~bofh/dropzone/manprefix-fail.maintainer.txt
Unmaintained FreeBSD ports which are out of date
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-240223 +-+ emulators/wine-devel| 9.1 | 9.3 +-+ 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!
Re: KSH Alignment
On 2024-02-23 08:30, Cy Schubert wrote: In message <787339cd-48e4-49bf-b96e-77aab06ce...@freebsd.org>, Rodrigo Osorio w rites: This is a multi-part message in MIME format. On 23/02/24 16:54, Cy Schubert wrote: > Hi, > > Would there be any interest in either replacing shells/pdksh with > shells/ksh as our default ksh dependency? Or Uses/ksh.mk to select a > default ksh for ports? > > The reason I ask is, shells/ksh has its lineage from the original AT&T ksh > (shells/ksh93) and is being actively developed (see shells/ksh-devel). > shells/ksh upstream is also the ksh imported into and used by CDE > (x11/cde*). > > My position is, I'd prefer a Uses/ksh.mk. If people are interested, I'm > willing to put this task on my todo list. > > Hi, As long as there is no compatibilities issues, having a well maintained ksh version makes a lot of sense. pdksh wasn't update for ages and afaik, has no active developer. As the shells/pdksh maintainer you have my blessing. I'll put together a phabricator review over the next while to add Mk/Uses/ksh.mk. We'll probably need an exp-run too. Looking forward to it. Thanks for volunteering to do this. --Chris
Re: Multiple new R ports
Hi Nuno, > On 22 Feb 2024, at 11:43, Nuno Teixeira wrote: > > I did take a look at review and noticed that TEST_DEPENDS are not used > and that could means that test target works without any depends or > ports are not tested at all. > My curiosity is what do you think about the importance (or not) to > have testunit feature working on R ports? > > I maintain a couple R ports and testunit revealed some errors that > upstream fixed. > Maybe this testunit subject could be apply to all ports that have that > feature. > Thanks for the info. I’m going through the ports and making sure test targets can be run. I’ll update the diff when I’m done. einar
