Adding CPE information
Hello, It seems recently some committers are working to add CPE information to many ports. I don't know why it started. But if it is intended to add CPE information to all (or most of ) ports, isn't it better to modify ports framework so CPE intormation is added to each ports by default? --- Yasuhiro Kimura
Re: Adding CPE information
On 14/10/21 13:07, Yasuhiro Kimura wrote: Hello, It seems recently some committers are working to add CPE information to many ports. I don't know why it started. But if it is intended to add CPE information to all (or most of ) ports, isn't it better to modify ports framework so CPE intormation is added to each ports by default? AFAIK that's already in the tree. The framework tries to extrapolate CPE information from PORTNAME and other variables. Unluckily most of the time it is actually impossible to get correct information and some other variables with the correct details, which are not necessarily logical or in any way connected with the information already present) need to be added by hand after manual discovery. -- Guido Falsi
Re: Adding CPE information
On Thu, Oct 14, 2021 at 3:24 PM Guido Falsi wrote: > > On 14/10/21 13:07, Yasuhiro Kimura wrote: > > Hello, > > > > It seems recently some committers are working to add CPE information > > to many ports. I don't know why it started. But if it is intended to > > add CPE information to all (or most of ) ports, isn't it better to > > modify ports framework so CPE intormation is added to each ports by > > default? > > AFAIK that's already in the tree. The framework tries to extrapolate CPE > information from PORTNAME and other variables. > > > Unluckily most of the time it is actually impossible to get correct > information and some other variables with the correct details, which are > not necessarily logical or in any way connected with the information > already present) need to be added by hand after manual discovery. That's correct. The CPE support in the portstree is in Mk/Uses/cpe.mk since 2014. The current attempt (chkcpe) is to add CPE_VENDOR and if needed CPE_PRODUCT to as many ports as possible. The problem is that CPE_VENDOR is a non deterministic value and often multiple choice. So when you see a commit that adds CPE_VENDOR then this is only the last part of the whole workflow. http://github.com/decke/chkcpe -- Bernhard Froehlich http://www.bluelife.at/
Re: Adding CPE information
From: Guido Falsi Subject: Re: Adding CPE information Date: Thu, 14 Oct 2021 14:58:04 +0200 >> It seems recently some committers are working to add CPE information >> to many ports. I don't know why it started. But if it is intended to >> add CPE information to all (or most of ) ports, isn't it better to >> modify ports framework so CPE intormation is added to each ports by >> default? >> > > AFAIK that's already in the tree. The framework tries to extrapolate > CPE information from PORTNAME and other variables. Yes, but it isn't enabled by default. You need to add 'USES=cpe` to Makefile if you want to add CPE information to specific port. What I proposed is to change framework so CPE information is added to all ports without adding 'USES=cpe' to Makefile of each port. > Unluckily most of the time it is actually impossible to get correct > information and some other variables with the correct details, which > are not necessarily logical or in any way connected with the > information already present) need to be added by hand after manual > discovery. I understand manual work is required to set the value of related variables correctly. But it is always necessary whether we add CPE information by changing framework of we do it by adding 'USES=cpe' to Makefile of each port. And assuming that it is intended to add CPE information to all ports, I think the former requires less work volume than the latter. --- Yasuhiro Kimura
Re: Adding CPE information
On Thu, Oct 14, 2021 at 3:44 PM Yasuhiro Kimura wrote: > > From: Guido Falsi > Subject: Re: Adding CPE information > Date: Thu, 14 Oct 2021 14:58:04 +0200 > > >> It seems recently some committers are working to add CPE information > >> to many ports. I don't know why it started. But if it is intended to > >> add CPE information to all (or most of ) ports, isn't it better to > >> modify ports framework so CPE intormation is added to each ports by > >> default? > >> > > > > AFAIK that's already in the tree. The framework tries to extrapolate > > CPE information from PORTNAME and other variables. > > Yes, but it isn't enabled by default. You need to add 'USES=cpe` to > Makefile if you want to add CPE information to specific port. What I > proposed is to change framework so CPE information is added to all > ports without adding 'USES=cpe' to Makefile of each port. > > > Unluckily most of the time it is actually impossible to get correct > > information and some other variables with the correct details, which > > are not necessarily logical or in any way connected with the > > information already present) need to be added by hand after manual > > discovery. > > I understand manual work is required to set the value of related > variables correctly. But it is always necessary whether we add CPE > information by changing framework of we do it by adding 'USES=cpe' to > Makefile of each port. And assuming that it is intended to add CPE > information to all ports, I think the former requires less work volume > than the latter. No, that does not work because valid CPE entries only exist if the software product was mentioned in a CVE or the CPE entry was reserved which is a rare case. -- Bernhard Froehlich http://www.bluelife.at/
Re: Adding CPE information
From: Bernhard Fröhlich Subject: Re: Adding CPE information Date: Thu, 14 Oct 2021 15:58:01 +0200 > No, that does not work because valid CPE entries only exist if the software > product was mentioned in a CVE or the CPE entry was reserved which is > a rare case. In short, my assumption is wrong. Then my proposal is surely pointless. Sorry for noise. --- Yasuhiro Kimura
FreeBSD ports you maintain which are out of date
Dear port maintainer, The portscout new distfile checker has detected that one or more of your 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. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed 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 +-+ databases/go-pgweb | 0.11.7 | v0.11.9 +-+ games/chessx| 1.5.6 | 1.5.7 +-+ sysutils/google-compute-engine-oslogin | 20191018.00 | 20211013.00 +-+ sysutils/hfsexplorer| 0.23.1 | hfsexplorer-2021.10.9 +-+ 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!
Request for Data
Greetings, I'm looking for anybody that's using poudriere + qemu bsd-user to build ports for some private deployment or other reason. So, if you could send me a private note that includes: (1) A list of direct ports you are interested in (I can work out the dependencies) (2) A list of architectures (3) Any additional data I'm trying to get qemu bsd-user upstreamed. It's taking a while, and causing a number of changes that I need to plow into our qemu-bsd-user fork until I can get things upstreamed. I'd like to have some set of ports that are known working now so that there's no regressions as the requested changes from upstream are integrated into our fork. Also, if anybody is interested in helping with any of these tasks, please let me know. Thanks for your time! Warner
Re: Poudriere bulk "Deleting foo-1.2.3.pkg: no longer needed"
On 10/11/2021 9:53 AM, tech-lists wrote: Hi, On Sun, Oct 10, 2021 at 04:15:32PM -0400, J David wrote: We use a staged approach to building packages with poudriere, with several "bulk" commands, because some ports we rarely need take an incredibly long time to build. (Mainly languages, like rust, clang, and gcc.) [snip] Basically, "bulk -f" seems to have started preemptively deleting any existing package that isn't specifically listed in the given file or required by a port that is listed. So much for building things in stages! This wasn't the case previously, and I can't find any flags that control this behavior on the man page. Is this intentional? Is there a way to get it not to do that? (Short of modifying our build scripts not to use -f anymore.) I build in stages too, as there are some huge ports that don't play nice in a bulk build but build fine when invoked in the form poudriere -j jailname port_category/portname. I don't think it's intentional. I'm seeing the same behaviour in poudriere-devel on stable/13 (poudriere-devel is poudriere-devel-3.3.99.20210907_1) https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259085 explains it and has a workaround. Sorry for the trouble. I've been busy and haven't had a chance to update the port yet. I did add a MUTUALLY_EXCLUSIVE_BUILD_PACKAGES list that I need to push to the port too that should help with the root cause of the multiple bulk -f. That one depends on a queue rework which I don't have time to support at the moment but it's coming. -- Bryan Drewery
