Can I get someone to look at ports/265712?
It's an easy-to-fix bug with python it from working with user-local pip-based installs, but it's gone two weeks without maintainer response.
Where are samba41{4.5.6.7}?
I went to install Samba, could only see net/samba412 and net/samba413. 4.12 was EOL 2021-09-20. 4.13 was EOL 2022-03-21. Where are the ports for supported versions of Samba?
How do I depend on a port regardless of its flavor?
I'm working on a port that depends on a port which is flavored. If I do this: RUN_DEPENDS= foo:devel/foo That works because the lack of version spec means the LHS is a file to look for, and /usr/local/bin/foo will be installed regardless of flavor. But I need to also specify a version spec. However, if I do this: RUN_DEPENDS= foo>=1.2:devel/foo That only works if the default flavor is installed. If one of the non-default flavors is installed, the Ports System doesn't find it and tries to build the port. Similarly, pkg thinks I need to install the default flavor. The flavors aren't part of a framework like Python, so I don't have a set of variables I can use to construct a universal pkg name. How do I add a version-limited dependency on a flavored port?
bdb5 is EOL, but still the default version?
I get errors like this in audit logs: db5-5.3.28_8: Tag: expiration_date Value: 2022-06-30 db5-5.3.28_8: Tag: deprecated Value: EOLd, potential security issues, maybe use db18 instead But BDB_DEFAULT=5? If db5 is EOL and vulnerable, why not bump the default version to 18? FWIW, the only consumer of that port I have is devel/apr1, and it says BDB_USES=bdb:5+
Re: lang/rust is super slow to build
On 2022-12-12 11:27, Pat Maddox wrote: Using poudriere, lang/rust is at 2 hours and counting on my 10-core i9 w/ 128 gigs of RAM. Does that sound right? It seems extremely slow to me, but this is my first time building it. That sounds typical. You can use ccache and tmpfs to speed it up a little bit, but both rust and llvm are computationally massive. Even worse, poudriere doesn't need to build it. If you aren't changing its options there's no functional difference between building it locally and installing from the public pkg repo. Poudriere does have the ability to install from pkgs, but there is a 2-year-old bug that prevents that feature from working correctly. I recommend everyone comment on issue #822 on the freebsd/poudriere github[1] and explain how much of a pain it is that poudriere doesn't have sane behaviour wrt dependencies. Maybe if enough people comment it will spur a fix. 1: https://github.com/freebsd/poudriere/issues/822
Re: lang/rust is super slow to build
On 2022-12-13 8:38, Christoph Brinkhaus wrote: Am Tue, Dec 13, 2022 at 07:55:11AM -0800 schrieb Mel Pilgrim: Even worse, poudriere doesn't need to build it. If you aren't changing its options there's no functional difference between building it locally and installing from the public pkg repo. Poudriere does have the ability to install from pkgs, but there is a 2-year-old bug that prevents that feature from working correctly. The developmenmt version poudriere-devel has got the feature to download the packages specified in some configuration file. Disclaimer: I have not used it because I can like with the packaged software. I have used it. Both -b branch and PACKAGE_FETCH_*. The feature you mention does indeed download pkgs. But, as is documented in issues on the project, the bug makes poudriere delete the pkgs it just fetched and queue up builds instead.
Re: lang/rust is super slow to build
On 2022-12-13 14:18, Xin LI wrote: IMHO the ports collection should provide and use prebuilt packages of compilers (LLVM, GCC, Rust, etc.) built from the FreeBSD packages builder, and ports framework (possibly also the base system) should be changed to use prebuilt packages by default, unless a) user requested to build everything from source, or b) no binary package is available for the platform combination, like a Tier-2 platform. The source ports for compilers should have all optimizations (like PGO, LTO, etc.) enabled by default, and require reasonably modern (perhaps newer than Sandy Bridge) processor features by default. It has this ability. If you set PACKAGE_FETCH_BLACKLIST, it will never download pkgs for the pkgname globs listed. If you set PACKAGE_FETCH_WHITELIST, it will download pkgs for only those pkgname globs listed. The suggested value in poudriere.conf is even "gcc* rust llvm*".
Re: How do I depend on a port regardless of its flavor?
On 2022-12-13 19:34, Tatsuki Makino wrote: Mel Pilgrim wrote on 2022/12/12 02:52: But I need to also specify a version spec. However, if I do this: RUN_DEPENDS= foo>=1.2:devel/foo That only works if the default flavor is installed. If one of the non-default flavors is installed, the Ports System doesn't find it and tries to build the port. Similarly, pkg thinks I need to install the default flavor. The flavors aren't part of a framework like Python, so I don't have a set of variables I can use to construct a universal pkg name. How do I add a version-limited dependency on a flavored port? Is this simply about the following? RUN_DEPENDS= foo>=1.2:devel/foo@nondefaultflavor No, that makes the port depend on that specific flavor. I need to allow any flavor to be installed. The majority of the Python module is like this. Yes and, per my original post, this is about depending on a port that doesn't have such a framework around it. For example, let's say I have a run dependency on postfix. It has six flavors: # pkg search -qL pkg-name mail/postfix$ postfix-sqlite-3.7.3_1,1 postfix-sasl-3.7.3_1,1 postfix-pgsql-3.7.3_1,1 postfix-3.7.3_1,1 postfix-ldap-3.7.3_1,1 postfix-mysql-3.7.3_1,1 As all six flavors will provide what is needed in this example situation, there is no reason to limit which one the user can install. If I have this: RUN_DEPENDS= postfix>=3.7.3:mail/postfix and the user has, say, postfix-sqlite-3.7.3_1,1 installed, then the Ports System will think the dependency isn't met and try to build mail/postfix. Pkg will similarly not see postfix-sqlite-3.7.3_1,1 as a viable dependency due to the pkgname mismatch, try to install postfix, and fail on the conflict. However, if I have this: RUN_DEPENDS= postfix:mail/postfix and user has postfix-sqlite-3.7.3_1,1 installed, the Ports System will see that as meeting the depedency because the lack of version spec reduces the check to seeing if "postfix" is a file. Since all flavors of postfix install that program, all of them meet it. But now I can't specify a version restriction. So, in this specific example, the question becomes: What format does the RUN_DEPENDS line need to take to declare that any flavor of postfix will meet the requirement so that the user can install any flavor they want either via Ports or pkg? I'm asking because, given this problem was created by the FLAVORS implementation modifying pkgname, it must be just a matter of outdated documentation that the Porter's Handbook doesn't say how to handle this case. I mean, no one would be mad enough to choose that approach and not update the dependency solver(s) to handle it, right?
Re: How do I depend on a port regardless of its flavor?
On 2022-12-16 16:03, Tatsuki Makino wrote: Mel Pilgrim wrote on 2022/12/17 06:49: I'm asking because, given this problem was created by the FLAVORS implementation modifying pkgname, it must be just a matter of outdated documentation that the Porter's Handbook doesn't say how to handle this case. is there any way to know the FLAVOR of postfix or other pre-installed stuff? No, that's the point I've been getting at: it needs to work regardless of the flavor installed. [Makefile example snipped] If that fails, it need to use other methods. Using the same flavors as postfix, OPTIONS to choose postfix flavor or split into m@ster and sl@ve... No, that is making it flavor-specific. It just changes the dependency to whatever is installed at build time, not creating a dependency that will work with an as-yet-unknown flavour. We appear to be miscommunicating about this. The port that depends on the flavoured post cannot know ANYTHING about which flavor is or will be installed. Not only is that knowledge is entirely outside the port's baliwick, it isn't even knowable yet. The user needs to be able to swap out the flavor at will via pkgs and still have this dependency work without manual intervention. I'm not sure how else to phrase this, so if this still isn't clear please do say so.
Is there a way to find out which git commit the pkg.freebsd.org repos were built on?
I asked this a long time ago, back when FreeBSD was still on Subversion, and the answer back then was "not really". Has that changed? What I need is the ability to retrieve the output of git log -1 --format=%h run against the ports tree clone was used to build what is currently in the pkg.freebsd.org repos.
Can security/ca_root_nss be retired?
Given /usr/share/certs exists for all supported releases, is there any reason to keep the ca_root_nss port?
Re: Can security/ca_root_nss be retired?
On 2023-01-19 4:08, Tomoaki AOKI wrote: On Thu, 19 Jan 2023 03:13:48 -0800 Mel Pilgrim wrote: Given /usr/share/certs exists for all supported releases, is there any reason to keep the ca_root_nss port? If everyone in the world uses LATEST main only, yes. But the assumption is clearly nonsense. Basically, commits to main are settled a while before MFC to stable branches, and MFS to releng branches needs additional settling days. If any certs happened to be non-reliable, this delay can cause, at worst, catastorphic scenario. If updates to certs are always promised to be "MFC after: now" and committed to ALL SUPPORTED BRANCHES AT ONCE, I have no objection. If not, keeping ca_root_nss port and updated ASAP with upstream should be mandatory. If ca_root_nss delivered the certs in the same format, sure, but that monolithic file makes installing private CAs a hassle. I wonder if the script secteam uses to update the trust store in the src tree could be turned into a periodic script that automatically updates the trust store? Side-step the release engineering delay entirely by turning trust store updates into a user task.
Re: Can security/ca_root_nss be retired?
On 2023-01-19 14:09, Tomoaki AOKI wrote: On Thu, 19 Jan 2023 05:58:12 -0800 Mel Pilgrim wrote: I wonder if the script secteam uses to update the trust store in the src tree could be turned into a periodic script that automatically updates the trust store? Side-step the release engineering delay entirely by turning trust store updates into a user task. With the approach, how can we avoid man-in-the-middle attack or something? By using the root trust store already on the system. Ports framework has checksum to avoid it, unless local admins intentionally disable it. The distinfo check only asserts that what the user downloaded is very likely the same as what the maintainer downloaded. The makesum target enables SSL peer verification during the fetch phase, so ultimately the MitM-mitigation in the Ports System is just the root trust store. Maybe adding a script to *Check if /usr/local/share/certs/ca-root-nss.crt is updated or not. *Extract individual certs from ca-root-nss.crt and update trust store. *Record current timestamp and hash of ca-root-nss.crt for next run. into ca-root-nss port, which can be run from cron or by hand, is needed? Since that would only need to be run after the port gets updated, it makes sense to me that it should be part of the port's install process. Is there a technical reason why the port can't, during the post-install target, create in /usr/local/share/certs/trusted and /usr/local/etc/ssl/certs the same structure as the in-base trust store?
How do I determine the ABI string used by pkg?
I need to determine the ABI string pkg uses on a given system, and need to do so when there are no pkgs installed. I've read through libpkg/pkg_elf.c and I can see how it's reading ELF headers from well-known files. That's all easy enough to replicate, but I'm a bit stuck on how it's determining the arch string for x86. How/When does pkg decide to use FreeBSD:13:amd64 instead of FreeBSD:13:x86:64? Can I safely assume one or the other?
Re: How do I determine the ABI string used by pkg?
On 2023-03-07 9:09, Dan Langille wrote: Baptiste Daroussin wrote on 3/6/23 2:56 AM: On Wed, Mar 01, 2023 at 11:50:13PM -0800, Mel Pilgrim wrote: I need to determine the ABI string pkg uses on a given system, and need to do so when there are no pkgs installed. pkg config ABI pkg config ALTABI When run in a freshly-created jail: [r730-01 dvl ~] % sudo jexec empty_tester root@:/ # pkg config ABI FreeBSD:13:amd64 root@:/ # pkg config ALTABI freebsd:13:x86:64 root@:/ # Mel: I think this is what you wanted to get? Your freshly-created jail has pkg installed. `pkg config ABI` only works if pkg has been bootstrapped. Getting the ABI string with just the /usr/sbin/pkg stub available is another thing entirely, even though that stub program necessarily has the code to determine the ABI string. I ended up writing a small program that replicates the ELF-divining logic in pkg and prints the value of ABI. IMO the stub should have the `pkg config ABI` functionality added to it, but I'm probably alone in thinking that would be useful.
Re: How do I determine the ABI string used by pkg?
On 2023-03-07 19:56, Tatsuki Makino wrote: Hello. Are you still saying that you are creating another program that does not rely on the pkg command? Then again, let's look at elf_tables.h. It would be necessary to have such a conversion table. Yeah basically. It pulls the pkg source as a build dependency and includes what it needs from there. It's a hack, though. All that's needed to obviate it entirely would be for the unbootstrapped `pkg -N -vv` to have functional parity with its bootstrapped counterpart, and that's slated for my next pet-project time slot.
Re: security/portsentry removal
On 2023-04-01 10:14, Andrea Venturoli wrote: Hello. I switched from Q1 to Q2 port tree today and was surprised to see this port gone. I try to avoid complaining, but it was marked deprecated on Feb 26 and removed on Mar 30: I agree that a software that was abandoned in 2003 or so should go away, but I believe this time window was too short, as those of us using quarterly ports didn't even see the deprecation notice. I don't think postponing the deprecation for two days would have had any big drawback... In any case, enough of that. Can anyone suggest something equivalent in the port tree? Have a look at fail2ban. It's design intent is monitoring running services, but really it's just a set of log file regex filters. Anything that logs network activity can feed it.
Re: security/portsentry removal
On 2023-04-08 0:47, Andrea Venturoli wrote: On 4/8/23 04:56, Mel Pilgrim wrote: Can anyone suggest something equivalent in the port tree? Have a look at fail2ban. It's design intent is monitoring running services, but really it's just a set of log file regex filters. Anything that logs network activity can feed it. Hello and thanks for answering. In fact I'm already using fail2ban for "running" services. Portsenty is a bit different, in that it's conceived to listen on ports used by non-running services. I.e. Got a SMTP server? Let fail2ban check its logs. No? Let portsentry listen on port 25. I thought about writing regexes for fail2ban to check if ipfw denied access to ports where portsentry used to listen. So far it's the best idea I've come up with, but I hoped for something simpler (i.e. more close to how portsentry worked). That's exactly what I suggest. IME dropping/ignoring packets to closed ports slows scanners down enough as it is, and the result is the same: they just see a non-responsive host. But completeness, peace of mind, etc. FWIW, you can still build and use portsentry either extratree or copy the port to your local category.
pkg check -ad, llvm10 is missing a required shared library
llvm10 and/or pkg seems to be broken in an odd way: # pkg check -ad Checking all packages: 100% llvm10 is missing a required shared library: libcxxrt.so.1 llvm10 is missing a required shared library: libc.so.7 llvm10 is missing a required shared library: libthr.so.3 llvm10 is missing a required shared library: libm.so.5 llvm10 is missing a required shared library: libncurses.so.8 This is on 12.2-p9. Why is llvm10 adding explicit dependencies for base shlibs? Why does pkg check -ad think they're missing?
Re: pkg check -ad, llvm10 is missing a required shared library
On 2021-08-09 14:53, George Mitchell wrote:
On 8/9/21 4:36 PM, Philipp Ost wrote:
[...]
# pkg check -Bdna
[...]
Checking all packages: 100%
llvm10 is missing a required shared library: libcxxrt.so.1
llvm10 is missing a required shared library: libc.so.7
llvm10 is missing a required shared library: libthr.so.3
llvm10 is missing a required shared library: libm.so.5
llvm10 is missing a required shared library: libncurses.so.8
llvm11 is missing a required shared library: libcxxrt.so.1
llvm11 is missing a required shared library: libc.so.7
llvm11 is missing a required shared library: libthr.so.3
llvm11 is missing a required shared library: libm.so.5
llvm11 is missing a required shared library: libncurses.so.8
llvm12 is missing a required shared library: libcxxrt.so.1
llvm12 is missing a required shared library: libc.so.7
llvm12 is missing a required shared library: libthr.so.3
llvm12 is missing a required shared library: libm.so.5
llvm12 is missing a required shared library: libncurses.so.8
[...]
My guess is that this is a pkg problem (or perhaps a pkg database
problem). It can be "fixed" by recompiling and reinstalling
llvm{10,11,12}. I've just been ignoring it since the message is
clearly nonsensical and there appear to be no operational problems
with llvm when I ignore them. It would be nice to get it fixed,
though. -- George
But libc and libthr are used in a huge number of ports. Why does this
only happen with these three llvm ports and not, say, every port written
in C? I should have dozens of ports claiming libc, libthr, libutil,
libcrypto, etc are missing shared libraries, but it's just this one.
Also, rebuilding and reinstalling llvm didn't fix it for me.
Re: pkg check -ad, llvm10 is missing a required shared library
On 2021-08-09 18:47, Tatsuki Makino wrote: Tatsuki Makino wrote on 2021/08/10 07:48: pkg-1.17.1/libpkg/pkg_elf.c has function filter_system_shlibs. However, that function is a static function. Since pkg-check doesn't seem to pass any other such function, pkg check -B will add the system library to the database. This is probably a mistake. readelf -d /usr/local/llvm10/lib/liblldb.so.10.0.1 returns the following RUNPATH. 0x001d RUNPATH Library runpath: [$ORIGIN/../lib:$ORIGIN/../../../../lib:/usr/local/lib] I think it's used to create a value that requires /usr/local/llvm10/../../../../lib/libc.so.7 instead of /lib/libc.so.7 when the shlib_list_from_rpath function in pkg-1.17.1/libpkg/elfhints.c is executed. It seems that /usr/local/llvm10/../../../../lib is not a target of filter_system_shlibs. This is also still my prediction. :) Thanks for digging into this. btw, you're doubled-up on the list CC (both ports@ and freebsd-ports@), trimmed here.
How do I depend on a python port without caring about flavor
I need to add a dependency to a port, but the dependency uses python.
My port doesn't use python itself, it just needs a python-using pkg
installed. But when I try to depend on that package with a line like this:
RUN_DEPENDS+= py-certbot>=0:security/py-certbot
I get a poudriere error like this:
Error: local/basecfg dependency on security/py-certbot has wrong PKGNAME
of 'py-certbot' but should be 'py38-certbot'
This works:
RUN_DEPENDS+= py${PYTHON_DEFAULT:S/.//}-certbot>=0:security/py-certbot
but that's definitely a kludge. The Porter's Handbook hints at using
PYTHON_PKGNAMEPREFIX or PYTHON_SUFFIX, but neither of those gets defined
unless I add USES+=python to local/basecfg and that's not correct either.
So how do I *officially* tell the ports system to just install
security/py-certbot with whatever is the current default flavour?
Re: How do I depend on a python port without caring about flavor
On 2021-08-19 0:28, Mel Pilgrim wrote: I need to add a dependency to a port, but the dependency uses python. My port doesn't use python itself, it just needs a python-using pkg installed. But when I try to depend on that package with a line like this: RUN_DEPENDS+= py-certbot>=0:security/py-certbot I get a poudriere error like this: Error: local/basecfg dependency on security/py-certbot has wrong PKGNAME of 'py-certbot' but should be 'py38-certbot' Also, I would point out that this error indicates something was able to figure out the correct PKGNAME based on the default flavour. Since it can do that, why not have ports automatically choose the default flavour when a port lists an unflavoured dependency on a flavoured port? Is there a technical reason to not assume the default flavour if one isn't specified?
Re: Call for participation
Count me in On 2021-09-02 7:43, Warner Losh wrote: Greetings, As teased on twitter, now that summer is over, it's a good time to start working on the next steps with git. When we moved to git, we knew a number of things would come in phase 2 since phase 1 was limited to moving away from subversion and to git. Now's the time for phase 2. The deferred items included better CI pipelines, better integration with popular hosting sites like github and gitlab, a look at the tools we have today and how they fit together, and a bunch of other items that were less well defined. I've spent the last several months looking at the different practices in open source, looking at our tools, etc. We have bits and pieces of many of these items, but are missing some glue between what we have. Other areas need more extensive work. To coordinate this work, I'll be leading a team to look at what we can do in the short term, the medium term and where we think we want to be in the long term. I plan on having bi-weekly meetings to discuss different issues that come up, to coordinate work and experiments and to give some structure to encouragement for progress to be made. This will be a collaborative effort between the developers and the user community that contributes patches to any part of FreeBSD (the base, ports and docs). If you are interested in participating, please drop me a line. We'll have a core office hours to talk about this soon, and I'd like to start discussions with those that are interested before hand, as well as invite people to participate in the office hours. After that, we'll have a kick off meeting that's open to everybody who can respectfully contribute. Looking forward to hearing from you. Warner
How do I depend on a flavoured PHP port? The Handbook is wrong??
I'm trying to add a dependency on a flavoured PHP application, but the
Porter's Handbook (section 7.3.1) instructions don't work. It says to
just add "@${PHP_FLAVOR}" but that's an empty variable.
I can't add php:flavors to the USES line because that then requires this
port be flavoured as if it were itself a PHP application (it's not, it's
just a metaport).
Adding "php" to USES works, but adds an unnecessary lang/php?? dependency.
What I need is the PHP counterpart to python:env, but I can't seem to
find it?
Why no flavor_USES helper?
The flavors helpers like flavor_RUN_DEPENDS are super useful, but I need
to modify USES based on flavor, and find that there is no helper for it.
That is, I'd like to be able to do this:
flavor1_USES= alice
flavor2_USES= bob
Instead of:
.if ${FLAVOR} == flavor1
USES+= alice
.elif ${FLAVOR} == flavor2
USES+= bob
.endif
At a glance, it looks like all that's needed is adding USES to
_FLAVOR_HELPERS_APPEND[1]. What am I missing?
1: Mk/bsd.port.mk, line 1525 as of bed4073e0
Re: Why no flavor_USES helper?
On 2021-09-06 1:16, Baptiste Daroussin wrote: On Sun, Sep 05, 2021 at 10:39:29AM -0700, Mel Pilgrim wrote: The flavors helpers like flavor_RUN_DEPENDS are super useful, but I need to modify USES based on flavor, and find that there is no helper for it. Besause USES are loader 100 lines earlier, meaning only USES are already processed when we expand the helper. Without getting to far in the technical details, USES and FLAVORS are basically expanded at the moment, in pre and post section, meaning one had to decide either we should allow USES to define flavors, or we should allow USES helpers. Is this why there odd race conditions between USES and FLAVORS where, for example, if I have a FLAVOR that does USES+=pgsql and WANT_PGSQL, the corresponding postgresqlN-* ports aren't added to *_DEPENDS?
Re: Why no flavor_USES helper?
On 2021-09-06 6:40, Baptiste Daroussin wrote:
On Mon, Sep 06, 2021 at 06:33:29AM -0700, Mel Pilgrim wrote:
On 2021-09-06 1:16, Baptiste Daroussin wrote:
On Sun, Sep 05, 2021 at 10:39:29AM -0700, Mel Pilgrim wrote:
The flavors helpers like flavor_RUN_DEPENDS are super useful, but I need to
modify USES based on flavor, and find that there is no helper for it.
Besause USES are loader 100 lines earlier, meaning only USES are already
processed when we expand the helper.
Without getting to far in the technical details, USES and FLAVORS are basically
expanded at the moment, in pre and post section, meaning one had to decide
either we should allow USES to define flavors, or we should allow USES helpers.
Is this why there odd race conditions between USES and FLAVORS where, for
example, if I have a FLAVOR that does USES+=pgsql and WANT_PGSQL, the
corresponding postgresqlN-* ports aren't added to *_DEPENDS?
I don't know, neither heard of that specific case, but it could be, if so, that
sound like a bug in pgsql.mk, I am interesting in an example that show this
behaviour.
I use an overlay with poudriere as part of a deployment system. Part of
it is ports-mgmt/superpkg, which uses FLAVORS to represent different
server profiles. It's mostly a series of lines like this:
.if ${FLAVOR} == mognet
USES+= ds hwtools hyve mailbox mx ns webbase zfstools
Which in turn references Mk/Uses files in the overlay. The one where I
hit this apparent race condition is Mk/Uses/mailbox.mk which adds
PostgreSQL server and contrib RUN_DEPENDS with these lines:
USES+= pgsql phpenv
WANT_PGSQL= contrib server
.include "${PORTSDIR}/Mk/Uses/pgsql.mk"
Without that .include line, the postgres RUN_DEPENDS don't get added.
It's something specific to pgsql.mk. The phpenv.mk file, a php analog
to python:env, gets included from this file. In another overlaid USES
file, I have USES+=python:env and that also works fine.
Re: Why no flavor_USES helper?
On 2021-09-06 8:14, Mel Pilgrim wrote: It's something specific to pgsql.mk. The phpenv.mk file, a php analog to python:env, gets included from this file. In another overlaid USES file, I have USES+=python:env and that also works fine. I was mistaken on this last part due to error masking by a port Makefile. My apologies for wasting your time. The issue appears to be USES added from within a Uses file don't get processed. Setting USES+= pgsql python:env phpenv from with a port Makefile works fine even if FLAVOR-conditional code does it. Doing the same from with a Uses file doesn't result in those added USES getting included.
Re: How do I depend on a flavoured PHP port? The Handbook is wrong??
On 2021-09-06 17:35, Tatsuki Makino wrote:
Mel Pilgrim wrote on 2021/09/04 09:36:
I'm trying to add a dependency on a flavoured PHP application, but the Porter's Handbook
(section 7.3.1) instructions don't work. It says to just add "@${PHP_FLAVOR}"
but that's an empty variable.
I can't add php:flavors to the USES line because that then requires this port
be flavoured as if it were itself a PHP application (it's not, it's just a
metaport).
Adding "php" to USES works, but adds an unnecessary lang/php?? dependency.
What I need is the PHP counterpart to python:env, but I can't seem to find it?
The RUN_DEPENDS+= near line 271 of Mk/Uses/php.mk seems to always be executed.
It would be an excessive dependency if PHP was used as a script just for
building.
That's what this is about, isn't it? :)
It's for a metaport that wants to add a flavored PHP port to
RUN_DEPENDS; but yes, needing PHP as a BUILD_DEPEND would probably be
another example.
Strange errors from poudriere-pkgclean
Hacking about in the ports tree tonight and I got this: # # poudriere pkgclean -n -a -j pas-releng-12 -p preprod -O localports -f /usr/local/etc/poudriere.d/build-list [...] [00:01:28] Calculating ports order and dependencies [00:01:28] Error: compute_deps_pkg failed to lookup pkgname for audio/timidity++ processing package timidity++-emacs-2.15.0 from audio/timidity++-emacs -- Is SUBDIR+=timidity++ missing in audio/Makefile and does the port provide the '' FLAVOR? [00:01:28] Error: compute_deps_pkg failed to lookup pkgname for audio/timidity++ processing package timidity++-motif-2.15.0 from audio/timidity++-motif -- Is SUBDIR+=timidity++ missing in audio/Makefile and does the port provide the '' FLAVOR? [00:01:28] Error: compute_deps_pkg failed to lookup PKGNAME for audio/timidity++ processing package timidity++-emacs-2.15.0 [00:01:28] Error: compute_deps_pkg failed to lookup pkgname for audio/timidity++ processing package timidity++-slang-2.15.0 from audio/timidity++-slang -- Is SUBDIR+=timidity++ missing in audio/Makefile and does the port provide the '' FLAVOR? [00:01:28] Error: compute_deps_pkg failed to lookup pkgname for audio/timidity++ processing package timidity++-gtk-2.15.0 from audio/timidity++-gtk -- Is SUBDIR+=timidity++ missing in audio/Makefile and does the port provide the '' FLAVOR? [00:01:28] Error: compute_deps_pkg failed to lookup PKGNAME for audio/timidity++ processing package timidity++-slang-2.15.0 [00:01:28] Error: compute_deps_pkg failed to lookup PKGNAME for audio/timidity++ processing package timidity++-motif-2.15.0 [00:01:28] Error: compute_deps_pkg failed to lookup pkgname for audio/timidity++ processing package timidity++-xskin-2.15.0 from audio/timidity++-xskin -- Is SUBDIR+=timidity++ missing in audio/Makefile and does the port provide the '' FLAVOR? [00:01:28] Error: compute_deps_pkg failed to lookup PKGNAME for audio/timidity++ processing package timidity++-gtk-2.15.0 [00:01:28] Error: compute_deps_pkg failed to lookup PKGNAME for audio/timidity++ processing package timidity++-xskin-2.15.0 [00:01:28] Error: compute_deps_pkg failed to lookup pkgname for audio/timidity++ processing package timidity++-xaw-2.15.0 from audio/timidity++-xaw -- Is SUBDIR+=timidity++ missing in audio/Makefile and does the port provide the '' FLAVOR? [00:01:28] Error: compute_deps_pkg failed to lookup PKGNAME for audio/timidity++ processing package timidity++-xaw-2.15.0 [00:01:32] Error: compute_deps_pkg failed to lookup pkgname for textproc/reflex processing package vile-9.8u from editors/vile -- Is SUBDIR+=reflex missing in textproc/Makefile and does the port provide the '' FLAVOR? [00:01:32] Error: compute_deps_pkg failed to lookup pkgname for textproc/reflex processing package xvile-9.8u from editors/xvile -- Is SUBDIR+=reflex missing in textproc/Makefile and does the port provide the '' FLAVOR? [00:01:32] Error: compute_deps_pkg failed to lookup pkgname for lang/tolua++ processing package stratagus-2.4.2_1 from games/stratagus -- Is SUBDIR+=tolua++ missing in lang/Makefile and does the port provide the '' FLAVOR? [00:01:32] Error: compute_deps_pkg failed to lookup pkgname for lang/tolua++ processing package wyrmgus-5.0.1 from games/wyrmgus -- Is SUBDIR+=tolua++ missing in lang/Makefile and does the port provide the '' FLAVOR? [00:01:32] Error: compute_deps_pkg failed to lookup pkgname for lang/tolua++ processing package cegui-0.8.7_17 from graphics/cegui -- Is SUBDIR+=tolua++ missing in lang/Makefile and does the port provide the '' FLAVOR? [00:01:33] Error: compute_deps_pkg failed to lookup pkgname for audio/timidity++ processing package ja-mypaedia-fpw-package-1.0.7_10 from japanese/mypaedia-fpw-package -- Is SUBDIR+=timidity++ missing in audio/Makefile and does the port provide the '' FLAVOR? [00:01:33] Error: compute_deps_pkg failed to lookup pkgname for audio/timidity++ processing package ja-timidity++-slang-2.15.0 from japanese/timidity++-slang -- Is SUBDIR+=timidity++ missing in audio/Makefile and does the port provide the '' FLAVOR? [00:01:33] Error: compute_deps_pkg failed to lookup PKGNAME for audio/timidity++ processing package ja-timidity++-slang-2.15.0 [00:01:34] Error: compute_deps_pkg failed to lookup pkgname for graphics/png++ processing package nn-insight-1.0.5_1 from misc/nn-insight -- Is SUBDIR+=png++ missing in graphics/Makefile and does the port provide the '' FLAVOR? [00:01:35] Error: compute_deps_pkg failed to lookup pkgname for net/p5-NetPacket processing package netleak-0.1a_2 from net-mgmt/netleak -- Is SUBDIR+=p5-NetPacket missing in net/Makefile and does the port provide the '' FLAVOR? [00:01:35] Error: compute_deps_pkg failed to lookup PKGNAME for net/p5-NetPacket processing package netleak-0.1a_2 [00:01:35] Error: compute_deps_pkg failed to lookup pkgname for net/p5-NetPacket processing package p5-Net-Analysis-0.41_1 from net/p5-Net-Analysis -- Is SUBDIR+=p5-NetPacket missing in net/Makefile and does the
Re: Strange errors from poudriere-pkgclean
On 2021-09-07 13:59, Bryan Drewery wrote: On 9/6/2021 8:43 PM, Mel Pilgrim wrote: Hacking about in the ports tree tonight and I got this: # # poudriere pkgclean -n -a -j pas-releng-12 -p preprod -O localports -f /usr/local/etc/poudriere.d/build-list What files are in the localports overlay? Something from that is confusing the SUBDIR list for the categories. I suspect that you have audio/something in your overlay but no audio/Makefile with SUBDIR listings for the added things. The overlay doesn't have an audio dir in it, just ports-mgmt and dns.
Re: How do I depend on a flavoured PHP port? The Handbook is wrong??
On 2021-09-12 5:56, Harry Schmalzbauer wrote:
I can't remember if this still is undocumented... and if I already
reported that this is missing to be documented.
Also can't remember where I found that it can look like this, most
likely underneith ports/Mk:
.if ${PORT_OPTIONS:MGITT}
RUN_DEPENDS= git:${PORTSDIR}/devel/git@tiny
.endif
That would be git:devel/git@tiny, but knowing the flavour ahead of time
is exactly what isn't the case here.
Clarification on MOVED entries when flavouring a port
I'm flavouring a port. The pkg name will change when upgrading from unflavoured to flavoured because the flavoured version will have a PKGNAMESUFFIX. Does this require a MOVED entry? The PKGNAMESUFFIX is based on default-versions so the "default" flavour is whatever the current default version is. If I need a MOVED entry, do I make the entry with the current default version?
Can a committer look at ports/258359?
Maintainer timeout. It's a tiny bug fix in Mk/Uses/go.mk that doesn't require any knowledge of the Go language.
Can a committer look at ports/258650 and 258651?
I'd like these to get into the tree in time for 2021Q4.
What to do with the "Created by" header comments?
In a port I recently submitted, I included the "# Created by: ..." line at the top of the Makefile I had seen in other ports. When the port was committed, that line was excluded. Should I strip this line from ports I maintain as I update them, or let it sit until a committer does a tree-wide removal?
Running php-composer as part of a build process
I'm porting a PHP application that uses composer[1] to download and manage what effectively becomes locally-bundled contrib. Doing this during the build process isn't an option because it creates a nightmare of licensing and version management. Also, composer needs internet access and can be configured to do other things, like code compliance and unit tests. Can I run something like composer from the post-install target? Is it reasonable to assume internet access is available during port/pkg install? 1: https://getcomposer.org/
Re: Bringing back lang/python27 with few modules?
On 2021-11-18 0:43, Eugene Grosbein wrote: 17.11.2021 17:16, Rene Ladan wrote: On Wed, Nov 17, 2021 at 12:37:07AM -0800, Maxim Sobolev wrote: P.S. AFAIK our documented criteria for removing a port is when one of the following is true: o Port lacks maintaintership; o Port has issues building on supported releases; o Port clearly has no users/use; o Port has some serious security issues. The lang/python27 did not belong to either of those bins, IMHO. "Unmaintained upstream" is also a criterion, and Python 2.7 fits there. This is bad criterion for open source software and should not be considered without other reasons like "unfetchable" or "has known critical vulnerabilities". It very likely has known critical vulnerabilities. For example, CVE-2021-3177 is a potential RCE bug in Python 3.x. It was officially fixed upstream, and the backported fix is found in Python 2.7 LTS contracts.
pkg alias commands missing after upgrading to 1.17.5
After upgrading pkg from 1.17.4 to 1.17.5, all of the command line aliases appear to have been removed? With pkg 1.17.4: # pkg alias ALIASARGUMENTS all-depends 'query %dn-%dv' annotations 'info -A' build-depends'info -qd' cinfo'info -Cx' comment 'query -i "%c"' csearch 'search -Cx' desc 'query -i "%e"' download 'fetch' iinfo'info -ix' isearch 'search -ix' prime-list 'query -e '%a = 0' '%n'' prime-origins'query -e '%a = 0' '%o'' leaf 'query -e '%#r == 0' '%n-%v'' list 'info -ql' noauto 'query -e '%a == 0' '%n-%v'' options 'query -i "%n - %Ok: %Ov"' origin 'info -qo' provided-depends 'info -qb' rall-depends 'rquery %dn-%dv' raw 'info -R' rcomment 'rquery -i "%c"' rdesc'rquery -i "%e"' required-depends 'info -qr' roptions 'rquery -i "%n - %Ok: %Ov"' shared-depends 'info -qB' show 'info -f -k' size 'info -sq' unmaintained 'query -e '%m = "ports@FreeBSD.org"' '%o (%w)'' runmaintained'rquery -e '%m = "ports@FreeBSD.org"' '%o (%w)'' With pkg-1.17.5: # pkg alias ALIASARGUMENTS # pkg leaf pkg: unknown command: leaf For more information on available commands and options see 'pkg help'.
Re: pkg alias commands missing after upgrading to 1.17.5
On 2021-12-03 2:56, Baptiste Daroussin wrote: On Fri, Dec 03, 2021 at 02:28:58AM -0800, Mel Pilgrim wrote: With pkg-1.17.5: # pkg alias ALIASARGUMENTS # pkg leaf pkg: unknown command: leaf For more information on available commands and options see 'pkg help'. I don't know what happened in your case, but I cannot reproduce. Do you have any diagnostic steps I can do to figure out what happened? I fetched a fresh copy of pkg-1.17.5~d6f9535722.pkg from the public repo and installed it using pkg-static, but that didn't fix the problem. I can at least confirm this only happens on one particular system. I have 15 systems all using the same private pkg repo, and only one has this problem.
Re: pkg alias commands missing after upgrading to 1.17.5
On 2021-12-03 5:25, Baptiste Daroussin wrote: On Fri, Dec 03, 2021 at 05:11:06AM -0800, Mel Pilgrim wrote: On 2021-12-03 2:56, Baptiste Daroussin wrote: On Fri, Dec 03, 2021 at 02:28:58AM -0800, Mel Pilgrim wrote: With pkg-1.17.5: # pkg alias ALIASARGUMENTS # pkg leaf pkg: unknown command: leaf For more information on available commands and options see 'pkg help'. I don't know what happened in your case, but I cannot reproduce. Do you have any diagnostic steps I can do to figure out what happened? I fetched a fresh copy of pkg-1.17.5~d6f9535722.pkg from the public repo and installed it using pkg-static, but that didn't fix the problem. I can at least confirm this only happens on one particular system. I have 15 systems all using the same private pkg repo, and only one has this problem. it means on the system with this issue, someone touched /usr/local/etc/pkg.conf The aliases are set there, the original file is stored at the following place: /usr/local/etc/pkg.conf.sample Ya I found that about 10 seconds after sending my last email. But it raises another question: The non-default pkg.conf had been on the system since August 2021, but alias commands like pkg leaf worked on 1.17.4. Why does 1.17.5 require pkg.conf define the aliases?
Re: mail/postfix and mail/postfix-current missing on www.freebsd.org ports section
On 2021-12-17 4:20, Michael Grimm via freebsd-questions wrote: Hi, I noticed today that mail/postfix and mail/postfix-current are missing on https://www.freebsd.org/cgi/ports.cgi?query=%5Epostfix+&stype=all&sektion=all They are there as postfix-sasl and postfix-current-sasl. That page has a bug with flavours such that it does not list the port with the default/first flavour. This is more obvious with the postfixadmin ports, which are listed with php80, not the default, php74.
Local ports [Was: Re: mail/postfix and mail/postfix-current missing on www.freebsd.org ports section]
On 2021-12-19 8:33, Roger Marquis wrote: On a similar note: is anyone is maintaing a local/custom port in Poudriere or know where that might be documented? I do. I have a private repo in $PORTSDIR/local. It's checked out on top of a poudriere ports tree and connected to the build system with: VALID_CATEGORIES+= local in make.conf. You'll also want: /local/* in $PORTSDIR/.git/info/exclude to avoid poudriere ports -u complaining about a dirty tree. I tried using the overlays feature, but it has race conditions with the shorthand mechanisms that make complex port skeletons easy to maintain.
Re: Local ports [Was: Re: mail/postfix and mail/postfix-current missing on www.freebsd.org ports section]
On 2021-12-27 9:29, Muhammad Moinur Rahman wrote: That’s one way of doing it but preferred way is a bit different as the upstream is modified and there might be merge conflicts while updating the tree. You have to use poudriere-devel and the overlay feature. So let’s say that I have a private repos of ports in github. Adding /local/* to .git/info/exclude avoids the presence of /local causing merge conflicts. As previously stated, overlays have race conditions with Ports features, making them unusable if an overlaid port has a complex Makefile.
How to port a PHP application that uses Composer?
Composer is a github-centric dependency management tool for PHP applications. It works very well on its own, but I'm having trouble figuring out how to integrate it with pkg building. The composer workflow is: 1. Clone the PHP application repo, which has a composer.json file 2. Download composer.phar and run `php composer.phar ...` 3. Composer examines composer.json and downloads dependencies from other github repos 4. Composer creates an autoloader script that does all of the require calls for the dependencies The problem is that download and autoloader script part. If I ran it as part of the pkg building process, there's a fetch-extract race as it needs network access, but also a file extracted from the distfile. If I left it to user config, the autoloader script creation will change a file managed by pkg. So how do I do this? Can a composer-using PHP application be ported?
Re: How to port a PHP application that uses Composer?
On 2022-05-16 20:14, Peter Beckman wrote: PHP is an interpreted language, Unless there are compiled portions, there is no porting necessary. There are many reasons to port a PHP application. Bringing in extensions and tracking those dependencies, for example. I've also seen a bunch of applications that need patches to shell commands because they assume Linuxisms that don't work on FreeBSD. How does the "application" run? Is it just a directory that is configured as a root directory for a webserver? Web and command-line Consider that it is something the installer needs to do, or build the package as a deterministic set of packages already installed. Yes, that's exactly the point I'm stuck on. The fetch-extract-fetch and toe-stepping problems mentioned in my original email came from me trying to solve this either way: "If I ran [composer] as part of the pkg building process, there's a fetch-extract race as it needs network access, but also a file extracted from the distfile. If I left it to user config, the autoloader script creation will change a file managed by pkg."
Re: How to port a PHP application that uses Composer?
On 2022-05-17 9:09, Stefan Esser wrote: Am 17.05.22 um 06:19 schrieb Mel Pilgrim: On 2022-05-16 20:14, Peter Beckman wrote: [...] Consider that it is something the installer needs to do, or build the package as a deterministic set of packages already installed. Yes, that's exactly the point I'm stuck on. The fetch-extract-fetch and toe-stepping problems mentioned in my original email came from me trying to solve this either way: "If I ran [composer] as part of the pkg building process, there's a fetch-extract race as it needs network access, but also a file extracted from the distfile. You can override the do-fetch target with a more complex sequence of commands. Those have network access and you could extract the required json file to some temporary location to let the composer do its job. WRKDIR doesn't exist until the extract phase, and with this approach Composer would need to do all of its work during the fetch phase. Is it okay to create WRKDIR early? Also, would doing this interfere with commands that batch-download distfiles, such as those used by poudriere?
Ports System not matching upstream build, causes broken builds
I'm working on a port of rbsec/sslscan (github), but running into an issue where the Ports System is invoking gmake in a way that doesn't match what the upstream Makefile does. The software has two build options: build a dynamic-linked version against the system OpenSSL library, or build a static-linked version against a bundled copy of OpenSSL 1.1.1-stable. `gmake` gets you the dynamic version, `gmake static` gets you the static version. Simple enough, so I put this in the port Makefile: OPTIONS_DEFINE= STATIC STATIC_USES_OFF=ssl STATIC_ALL_TARGET=static The port does call the static target as expected, but something is going terribly wrong and the result is polluted CFLAGS and LDFLAGS. An example is the cc invocation to build the sslscan binary itself. Below is that call for each of direct/port and static/dynamic build, with line-breaks added for ease of comparison: Direct static build: # gmake static cc -o sslscan -Wall -Wformat=2 -Wformat-security -Wno-deprecated-declarations -pie -z relro -z now -L/tmp/scratch/sslscan/openssl/ -D_FORTIFY_SOURCE=2 -fstack-protector-all -fPIE -std=gnu11 -I/tmp/scratch/sslscan/openssl/include/ -I/tmp/scratch/sslscan/openssl/ -DVERSION=\"2.0.15-static\" sslscan.c -lssl -lcrypto -lz -lpthread Port build with STATIC on: # make cc -o sslscan -Wall -Wformat=2 -Wformat-security -Wno-deprecated-declarations -fstack-protector-strong -pie -z relro -z now -L/usr/local/lib -L/usr/local/ssl/lib -L/usr/local/opt/openssl/lib -L/opt/local/lib -pie -z relro -z now -L/poudriere/ports/default/security/sslscan/work/sslscan-2.0.15/openssl/ -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -fstack-protector-all -fPIE -std=gnu11 -I/usr/local/include -I/usr/local/ssl/include -I/usr/local/ssl/include/openssl -I/usr/local/opt/openssl/include -I/opt/local/include -I/opt/local/include/openssl -D_FORTIFY_SOURCE=2 -fstack-protector-all -fPIE -std=gnu11 -I/poudriere/ports/default/security/sslscan/work/sslscan-2.0.15/openssl/include/ -I/poudriere/ports/default/security/sslscan/work/sslscan-2.0.15/openssl/ -DVERSION=\"2.0.15-static\" sslscan.c -lssl -lcrypto -lz -lpthread Direct dynamic build: # gmake cc -o sslscan -Wall -Wformat=2 -Wformat-security -Wno-deprecated-declarations -pie -z relro -z now -L/usr/local/lib -L/usr/local/ssl/lib -L/usr/local/opt/openssl/lib -L/opt/local/lib -D_FORTIFY_SOURCE=2 -fstack-protector-all -fPIE -std=gnu11 -I/usr/local/include -I/usr/local/ssl/include -I/usr/local/ssl/include/openssl -I/usr/local/opt/openssl/include -I/opt/local/include -I/opt/local/include/openssl -DVERSION=\"2.0.15\" sslscan.c -lssl -lcrypto Port build with STATIC off: # make cc -o sslscan -Wall -Wformat=2 -Wformat-security -Wno-deprecated-declarations -Wl,-rpath,/usr/local/lib -fstack-protector-strong -pie -z relro -z now -L/usr/local/lib -L/usr/local/ssl/lib -L/usr/local/opt/openssl/lib -L/opt/local/lib -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -fstack-protector-all -fPIE -std=gnu11 -I/usr/local/include -I/usr/local/ssl/include -I/usr/local/ssl/include/openssl -I/usr/local/opt/openssl/include -I/opt/local/include -I/opt/local/include/openssl -DVERSION=\"2.0.15\" sslscan.c -lssl -lcrypto Why is the port doing this and what bits of Makefile do I need to add to the skeleton to make it behave correctly?
