How to apply port patch

G

gulli

Hi experts,

could anyone help with port patches please? I am not able to patch any ports by portmaster. I know that here is more thread about it but still no clue. Is there any specific manuall procedure? Could you describe how pathces of ports are working please? Thank you in advance.

FreeBSD 12.2-STABLE
Code: 
portmaster /usr/ports/devel/meson

===>>> Currently installed version: meson-0.57.1_1
===>>> Port directory: /usr/ports/devel/meson

===>>> Gathering distinfo list for installed ports

===>>> Launching 'make checksum' for devel/meson in background
===>>> Gathering dependency list for devel/meson from ports
===>>> Initial dependency check complete for devel/meson


===>>> Starting build for devel/meson <<<===

===>>> All dependencies are up to date

===>  Cleaning for meson-0.58.1
===>  License APACHE20 accepted by the user
===>   meson-0.58.1 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by meson-0.58.1 for building
===>  Extracting for meson-0.58.1
=> SHA256 Checksum OK for meson-0.58.1.tar.gz.
===>  Patching for meson-0.58.1
===>  Applying FreeBSD patches for meson-0.58.1 from /usr/ports/devel/meson/files
====>   IGNORING patchfile patch-mesonbuild_backend_backends.py.orig
Ignoring previously applied (or reversed) patch.
1 out of 1 hunks ignored--saving rejects to mesonbuild/compilers/mixins/clang.py.rej
===>  FAILED Applying FreeBSD patch-mesonbuild_compilers_mixins_clang.py.bak
===> Cleanly applied FreeBSD patch(es)  patch-mesonbuild_backend_backends.py.bak
===> FAILED to apply cleanly FreeBSD patch(es)  patch-mesonbuild_compilers_mixins_clang.py.bak
*** Error code 1
 
by gitup ports

Code: 
# gitup ports
# Scanning local repository...
# Host: git.freebsd.org
# Port: 443
# Proxy Host: de.xy.net
# Proxy Port: 9400
# Repository Path: /ports.git
# Target Directory: /usr/ports
# Have: ef4bd749780b5797afacd35f3db1db9c00bc4ce2
# Want: 53f89f4af9bb4ac2addeeb6114cefbcaa7076872
# Branch: main
# Action: pull
 * /usr/ports/audio/mpg123/Makefile
 * /usr/ports/audio/mpg123/distinfo
 * /usr/ports/audio/mpg123/pkg-plist
 * /usr/ports/net-p2p/deluge-cli/Makefile
 + /usr/ports/net-p2p/deluge-cli/files/patch-deluge_i18n_util.py
 * /usr/ports/science/afni/Makefile
 * /usr/ports/science/afni/distinfo
 * /usr/ports/science/afni/files/patch-crorden_dcm2niix__console_makefile
 * /usr/ports/science/afni/pkg-plist
 - /usr/ports/devel/git/work-default
gitup: prune_tree: cannot stat() /usr/ports/devel/git/work-default/git-2.31.1/RelNotes: No such file or directory
Code: 
# gitup ports
# Scanning local repository...
# Host: git.freebsd.org
# Port: 443
# Proxy Host: de.xy.net
# Proxy Port: 9400
# Repository Path: /ports.git
# Target Directory: /usr/ports
# Have: 53f89f4af9bb4ac2addeeb6114cefbcaa7076872
# Want: 53f89f4af9bb4ac2addeeb6114cefbcaa7076872
# Branch: main
# Done.
 
What version of net/gitup? I would remove /usr/ports/* and run a fresh checkout. Something seems to be wrong as it's not correctly updating certain files.
 
Hello SirDice again,

could you help me pls with another little issue? I am not able to install libglvnd port:


Installing libglvnd-1.3.3...
pkg-static: libglvnd-1.3.3 conflicts with mesa-libs-20.2.3 (installs files into the same place). Problematic file: /usr/local/include/EGL/egl.h

Could be installed by portmaster -o graphics/libglvnd graphics/mesa-libs ?

I am not sure whether I can replace port mesa-libs with libglvnd. I went throught freshport.org, but it seems that these ports are different. Is there in freshport.org any comment/description how to know that one port can be replaced by another port?

Thank you in advance.
 
gulli said:
Installing libglvnd-1.3.3...
pkg-static: libglvnd-1.3.3 conflicts with mesa-libs-20.2.3 (installs files into the same place). Problematic file: /usr/local/include/EGL/egl.h
Click to expand...
Annoying thing. My solution: Remove both ports first (also if installed: nvidia-drivers); Only when both (mesa-libs and libglvnd) aren't installed mesa-libs can be build (and that installs libglvnd as a brand new dependency).

But: Deinstalling mesa-libs will probably deinstall a lot of other applications, so that's an expensive way to go from ports: You've got to build many ports again (or use cached package files - or an own package server with your own compiled packages (that's how I did it)). My experience: If you're going with portmaster (or just make commands in the ports tree), it makes sense to rebuild all packages from time to time; I've got no clue if another tool would be able to handle that situation.

Maybe downloading both packages from an up to date package server, and installing both packages in one go could do the trick, too… But that's not doing it with ports.
 
thanks for reply jmos

I simply tried make reinstall mesa-libs and it is working, libglvnd was installed as you said.
 
gulli said:
I simply tried make reinstall mesa-libs and it is working, libglvnd was installed as you said.
Click to expand...
I'm confused: Even compiling mesa-libs tries to install libglvnd first, and in my case the result of that was your message above… I couldn't do a "make reinstall". But fine as it worked for you ;)
 
yes, I was suprised that reinstall worked.

I have last problem with port linux-c7-libsndfile, see below, this vulnerabilities are there a long time, is there any other procedure how to update this ports (except make DISABLE_VULNERABILITIES=yes)? Why are vulnerable ports so long vulnerable, mostly were ports vulnerabilities fixed in days..? (sorry for stupid question)


===> linux-c7-libsndfile-1.0.25_6 has known vulnerabilities:
linux-c7-libsndfile-1.0.25_6 is vulnerable:
libsndfile -- multiple vulnerabilities
CVE: CVE-2017-14634
CVE: CVE-2017-12562
CVE: CVE-2017-8365
CVE: CVE-2017-8363
CVE: CVE-2017-8362
CVE: CVE-2017-8361
WWW: https://vuxml.FreeBSD.org/freebsd/2b386075-1d9c-11e8-b6aa-4ccc6adda413.html

libsndfile -- out-of-bounds reads
CVE: CVE-2017-17457
CVE: CVE-2017-17456
CVE: CVE-2017-14246
CVE: CVE-2017-14245
WWW: https://vuxml.FreeBSD.org/freebsd/30704aba-1da4-11e8-b6aa-4ccc6adda413.html

libsndfile -- out-of-bounds read memory access
CVE: CVE-2017-6892
WWW: https://vuxml.FreeBSD.org/freebsd/004debf9-1d16-11e8-b6aa-4ccc6adda413.html

libsndfile -- multiple vulnerabilities
CVE: CVE-2017-7742
CVE: CVE-2017-7741
CVE: CVE-2017-7586
CVE: CVE-2017-7585
WWW: https://vuxml.FreeBSD.org/freebsd/5a97805e-93ef-4dcb-8d5e-dbcac263bfc2.html
 
You know that you are supposed to read /usr/ports/UPDATING ?
20210617:
AFFECTS: users of graphics/mesa-libs
AUTHOR: kbowling@FreeBSD.org

Some libraries from mesa-libs are now provided by libglvnd while
others were renamed. When building outside poudriere make sure to
remove mesa-libs first in order to avoid conflict with libglvnd.

For portmaster users:
# pkg delete -f mesa-libs
# portmaster -a

For portupgrade users:
# pkg delete -f mesa-libs
# portupgrade -a
Click to expand...
 
monwarez said:
You know that you are supposed to read /usr/ports/UPDATING ?
Click to expand...
oh, shit... libGL.so is installed by a few other ports... One workaround that I noticed is frankly symlinking, but I still haven't untangled which way those are supposed to go, which file to be 'source', and which is supposed to be 'destination'. Do it incorrectly, and you'll have a train wreck on your hands. I'm grateful for ZFS snapshotting to bail me out. Just how are we supposed to get the Gallium stack working under FreeBSD when we have this house of cards in the graphics libs stack?
 
monwarez said:
You know that you are supposed to read /usr/ports/UPDATING ?
Click to expand...
Code: 
root@vacallinehae ~>  pkg delete -f mesa-libs
[…]
Installed packages to be REMOVED:
        mesa-libs: 20.2.3_1
[…]
Proceed with deinstalling packages? [y/N]: y
[vacallinehae] [1/1] Deinstalling mesa-libs-20.2.3_1...
[vacallinehae] [1/1] Deleting files for mesa-libs-20.2.3_1: 100%
root@vacallinehae ~>  portmaster -a
===>>> Gathering distinfo list for installed ports

===>>> Starting check of installed ports for available updates

===>>> All ports are up to date

root@vacallinehae ~>

That tip would left me behind with dozens broken dependencies in my package system. And fixing this by installing mesa-libs again will set mesa-libs as non automatic installed (can also be fixed; pkg check -d would be nice to reinstall mesa-libs, but won't help: that's a pkg, not a ports solution). Having (even temporary) broken dependencies in a package system never was a acceptable solution to me. If you're on a playground that may be okay, but on a live system…
 
I don't have that problem, but if I did I would do this:
pkg delete -f mesa-libs
portmaster graphics/mesa-libs

And portmaster and I would be on our merry way. With what information you've given me.

I normally would re-run the initial command by scrolling up and let portmaster start the build over.
 
I don't see where it is says to reinstall it ?
After removing it, pkg upgrade will automatically installing the newer version as dependency.
It should be the same for portupgrade/portmaster, and if it cannot do that then that just mean that portupgrade/portmaster are just a bad idea.
If you want to build everything yourself, the only ways should be in a controlled environment like poudriere or synth.
I don't understand why you says not a port solutions, portmaster is using pkg, so stop saying that you don't use pkg

Even in the ports tree pkg is used
Code: 
# Used by scripts and users to install a package from local repository.
# Poudriere -i uses this, please keep.
.if !target(install-package)
.if defined(FORCE_PKG_REGISTER)
_INSTALL_PKG_ARGS=    -f
.endif
.if defined(INSTALLS_DEPENDS)
_INSTALL_PKG_ARGS+=    -A
.endif
install-package:
    @if [ -f "${WRKDIR}/pkg/${PKGNAME}${PKG_SUFX}" ]; then \
        _pkgfile="${WRKDIR_PKGFILE}"; \
    else \
        _pkgfile="${PKGFILE}"; \
    fi; \
    ${PKG_ADD} ${_INSTALL_PKG_ARGS} $${_pkgfile}
.endif

Having (even temporary) broken dependencies in a package system never was a acceptable solution to me
Click to expand...
Little bit ironic of someone that build each package in an unknown environment. Do you known that there is some package that will add optional
feature at configuration time if it detects that some libraries are installed ? And thus may be broken after your remove those libraries ?
 
monwarez said:
Little bit ironic of someone that build each package in an unknown environment. Do you known that there is some package that will add optional
feature at configuration time if it detects that some libraries are installed ? And thus may be broken after your remove those libraries ?
Click to expand...
Dependency hell in a nutshell...
Trihexagonal: This is why you don't go mixing ports and packages like you just did...
 
monwarez said:
[…] if it cannot do that then that just mean that portupgrade/portmaster are just a bad idea.
If you want to build everything yourself, the only ways should be in a controlled environment like poudriere or synth.
Click to expand...
So you're a fan of poudriere/synth, and dislike portupgrade/portmaster. That's okay, but I strongly disagree to your statements.
monwarez said:
I don't understand why you says not a port solutions, portmaster is using pkg, so stop saying that you don't use pkg
Click to expand...
By default portmaster compiles all packages from source, and doesn't fetch any pre-build package file. But of course: In the end the compiled port will be installed as a package.
monwarez said:
Little bit ironic of someone that build each package in an unknown environment.
Click to expand...
I'm someone who builds "each package in an unknown environment"? You know anything about my setup? Maybe I'm misunderstanding something…
 
I would advice to use synth or poudriere. It gives me "clean" results.
Portmaster works but you have to be carefull.
In make.conf you could place:
Code: 
OPTIONS_SET+=OPENGL
OPTIONS_SET+=VIDEO_OPENGL
OPTIONS_UNSET+=GLESV2
 
astyle said:
Dependency hell in a nutshell...
Click to expand...

Exactly. I'm using ports only, but for some reason it happens to me every now and then. A dependency check will report that, say, never-heard-of-lib.so is missing so you will have to find the port that installs it. It's not difficult to keep your installation consistent with these two commands:
Code: 
# pkg check -d
Checking all packages: 100%
py38-numpy is missing a required shared library: libblas.so.2
# find /usr/ports -name pkg-plist -depth 3 -exec grep libblas.so {} +
/usr/ports/math/lapack/pkg-plist:%%BLAS%%lib/libblas.so
/usr/ports/math/lapack/pkg-plist:%%BLAS%%lib/libblas.so.%%SVERSION%%
/usr/ports/math/lapack/pkg-plist:%%BLAS%%lib/libblas.so.%%VER%%[/cmd]
 
jmos said:
...
I'm someone who builds "each package in an unknown environment"? You know anything about my setup? Maybe I'm misunderstanding something…
Click to expand...
Well of course I don't known your setup, but the fact that your setup cannot detect a missing installed port (like mesa-libs) it tells me that it does not handle the dependency as pkg does. So how do you ensure that each package are built in a clean environment ? And how does your tooling didn't detect that the live system was missing a package ?
 
astyle said:
Dependency hell in a nutshell...
Trihexagonal: This is why you don't go mixing ports and packages like you just did...
Click to expand...
Will you fix my machines for me, pretty please? I taught myself to use ports in 2005, back when I didn't think the Handbook applied to PC-BSD, and this is the first time I've ever had to ask someone to help me...

Because that is exactly what I've done on every machine, as previously documented and I never have to ask questions like that.
 
Some ports/packages are conflicting like ImageMagick6 & ImageMagick7. And we have to live with it.
Mainly it's because they install the same files in the same directories.
I would give mesa-libs with its glxgears preference above other packages.
It is currently unclear for me what is conflicting with mesa-libs.
 
Yesterday I posted this shot of my terminal emulator with portmaster ready to run the www/youtube_dl build:

portmaster_waits.jpg

That shows it wants devel/meson which has the dependency of graphics/mesa-libs.

Here is a shot of youtube_dl running right now downloading astyle's favorite genre of music video:
bluegrass.jpg

So I just finished doing this last night.

I wish I could outline it step-by-step, but it was so run-of-the-mill everyday use of ports, normal problem solving from experience that to be perfectly honest I don't even remember.

But it wasn't anything hard to figure out and did it without consulting /usr/ports/UPDATING.


That experience came hard, too, don't think it didn't.
But it was well worth it and what you'll be missing out on if you don't use ports.
 
monwarez said:
the fact that your setup cannot detect a missing installed port (like mesa-libs) it tells me that it does not handle the dependency as pkg does
Click to expand...
Oh, pkg detects this. But not portmaster (man portmaster: "manage your ports" - not: "manage your packages"). I just tried to show that in this case reading/usr/ports/UPDATING may also not help. (But as always: I found my solution.) The unknown environment was a 10 days old FreeBSD 13.0-p2 jail with clean defaults, and installed as described in the handbook.
 
can anyone help with this please?


FreshPorts - VuXML

===> linux-c7-libsndfile-1.0.25_6 has known vulnerabilities:
linux-c7-libsndfile-1.0.25_6 is vulnerable:
libsndfile -- multiple vulnerabilities
CVE: CVE-2017-14634
CVE: CVE-2017-12562
CVE: CVE-2017-8365
CVE: CVE-2017-8363
CVE: CVE-2017-8362
CVE: CVE-2017-8361
WWW: https://vuxml.FreeBSD.org/freebsd/2b386075-1d9c-11e8-b6aa-4ccc6adda413.html

libsndfile -- out-of-bounds reads
CVE: CVE-2017-17457
CVE: CVE-2017-17456
CVE: CVE-2017-14246
CVE: CVE-2017-14245
WWW: https://vuxml.FreeBSD.org/freebsd/30704aba-1da4-11e8-b6aa-4ccc6adda413.html

libsndfile -- out-of-bounds read memory access
CVE: CVE-2017-6892
WWW: https://vuxml.FreeBSD.org/freebsd/004debf9-1d16-11e8-b6aa-4ccc6adda413.html

libsndfile -- multiple vulnerabilities
CVE: CVE-2017-7742
CVE: CVE-2017-7741
CVE: CVE-2017-7586
CVE: CVE-2017-7585
WWW: https://vuxml.FreeBSD.org/freebsd/5a97805e-93ef-4dcb-8d5e-dbcac263bfc2.html
 
You must log in or register to reply here.
Back
Top