Re: Scripts / utils for maintaining ports?
Hello, I maintain only a few ports, although some of them (the GCC ports) are very complex and time consuming to take care of. A few months ago, I found myself having much less time to maintain ports, so I made heavier use of automation. The most time consuming part for me usually is testing the ports. I solved the issue using cirrus. Using https://github.com/lsalvadore/freebsd-ports/blob/lang/gcc12-devel/.cirrus.yml I can test my changes to port $category/$port by simply committing them to a branch named $category/$port and pushing it on GitHub. Of course, if I need some more special testing I can edit the .cirrus.yml file. The testing results are probably not as good as with poudriere, but they are good enough. This strategy is particularly efficient with low efforts ports such as the GCC -devel ports that are updated every week and do not break often: with a cron job I automatically update the Makefiles and distinfo files and I push the branches. Then everything is tested while I sleep/work/drive etc. and I only need to check the testing results to see if I commit the changes or something is broken. Almost always the tests succeed and thus I can commit the update with only a few minutes of actual human work. If you also want to try playing with cirrus, keep in mind that the free plan now has some limitations. Moreover, I fear heavy ports could not be tested that way due to limits in resources. If you can afford it, using a VPS would probably be more efficient. But the free cirrus plan is good enough for small ports. Cheers, Lorenzo Salvadore Sent from Proton Mail mobile Messaggio originale Il 1 Dic 2023, 01:25, Pat Maddox ha scritto: > According to portscout, there are three individual maintainers who each > maintain 1000+ ports: https://portscout.freebsd.org/index-total.html I'm > trying to wrap my head around how someone could do that. They have to use > some utils to pull that off. Are those tools publicly available, either as > packages, or scripts in a repo somewhere? I am gradually developing a bit of > tooling to maintain my own collection of ports: > https://patmaddox.com/dir?ci=3d33b5b2dd2ebe39&name=ports/maintain Perhaps one > day it will evolve to a point where it's generally useful and shareable. In > the mean time, I would love to know how people are efficiently maintaining > multiple ports: particularly those folks maintaining 1000+. Maybe I can just > do what they do instead of re-constructing this myself. Pat
Setting of DEFAULT_VERSIONS of php and poudriere's ports compilation woes in my setup
Hi,
I am following the git repository for ports and using poudriere to compile
those.
Today I stumbled over:
20231125:
AFFECTS: users of lang/php81
AUTHOR: b...@freebsd.org
The default version of PHP has been switched from 8.1 to 8.2.
[…]
I had had the following definition for default php version in my poudriere
make.conf:
DEFAULT_VERSIONS+= php=81 […]
Now, I *removed* 'php=81' from DEFAULT_VERSIONS and ended up with the following
errors from poudriere:
Warning: (local/wpm): Error: local/wpm depends on nonexistent origin
'lang/php8.2-extensions';
Please contact maintainer of the port to fix
this.
Warning: (mail/roundcube@php8.2): Error: Invalid FLAVOR 'php8.2' for
mail/roundcube
Error: Fatal errors encountered gathering ports metadata
Understandable to me because all relevant ports are named as 'php82'...
I do have that local port local/wpm defined as follows:
[…]
RUN_DEPENDS+=
php${PHP_DEFAULT}-extensions>0:${PORTSDIR}/lang/php${PHP_DEFAULT}-extensions
RUN_DEPENDS+=
roundcube-php${PHP_DEFAULT}>0:${PORTSDIR}/mail/roundcube@php${PHP_DEFAULT}
[…]
Adding 'DEFAULT_VERSIONS+= php=82 […]' to my poudriere make.conf resolves this
issue.
It looks like $PHP_DEFAULT in port definition without 'DEFAULT_VERSIONS+=
php=82' in make.conf translates to an erroneous 'php8.2' and runs into errors.
Whereas the explicit definition of 'DEFAULT_VERSIONS+= php=82' in make.conf is
resulting in a $PHP_DEFAULT translating to 'php82' which successfully compiles
those ports without complaints.
I really don't understand what I am doing wrong. And I would appreciate if
someone could explain it to me.
Thanks in advance and regards,
Michael
Re: Setting of DEFAULT_VERSIONS of php and poudriere's ports compilation woes in my setup
On 02/12/23 21:37, Michael Grimm wrote:
Hi,
I am following the git repository for ports and using poudriere to compile
those.
Today I stumbled over:
20231125:
AFFECTS: users of lang/php81
AUTHOR: b...@freebsd.org
The default version of PHP has been switched from 8.1 to 8.2.
[…]
I had had the following definition for default php version in my poudriere
make.conf:
DEFAULT_VERSIONS+= php=81 […]
Now, I *removed* 'php=81' from DEFAULT_VERSIONS and ended up with the following
errors from poudriere:
Warning: (local/wpm): Error: local/wpm depends on nonexistent origin
'lang/php8.2-extensions';
Please contact maintainer of the port to fix
this.
Warning: (mail/roundcube@php8.2): Error: Invalid FLAVOR 'php8.2' for
mail/roundcube
Error: Fatal errors encountered gathering ports metadata
Understandable to me because all relevant ports are named as 'php82'...
I do have that local port local/wpm defined as follows:
[…]
RUN_DEPENDS+= php${
}-extensions>0:${PORTSDIR}/lang/php${PHP_DEFAULT}-extensions
RUN_DEPENDS+=
roundcube-php${PHP_DEFAULT}>0:${PORTSDIR}/mail/roundcube@php${PHP_DEFAULT}
[…]
Adding 'DEFAULT_VERSIONS+= php=82 […]' to my poudriere make.conf resolves this
issue.
It looks like $PHP_DEFAULT in port definition without 'DEFAULT_VERSIONS+=
php=82' in make.conf translates to an erroneous 'php8.2' and runs into errors.
Whereas the explicit definition of 'DEFAULT_VERSIONS+= php=82' in make.conf is
resulting in a $PHP_DEFAULT translating to 'php82' which successfully compiles
those ports without complaints.
I really don't understand what I am doing wrong. And I would appreciate if
someone could explain it to me.
AFAIK to depend on php components younshould leverage USES=php, and
define the actual required modules in USE_PHP.
If your port only works with some PHP versions you should list the
unsupported ones in IGNORE_WITH_PHP.
Depending on php-extensions is not really good practice, since what is
actually installed by it depends on options. It really is just a
convenience metaport for final users.
Anyway PHP_DEFAULT is defined in the framework Makefiles, so to use that
variable you need to put it after ".include ". But I
don't think that's the best strategy, you'd be better off leveraging
USES=php and flavorizing your port, using PHP_VER.
Not many live examples in the ports tree, but maybe you can find some
inspiration in some of these Makefiles:
databases/pear-DoctrineDBAL/Makefile
devel/php-composer/Makefile
Hope this information helps.
--
Guido Falsi
aarch64: sysutils/cpu-x@ncurses got SIGSEGV during its initial print_activecore
Note: This is from my own poudriere-devel based build of: sysutils/cpu-x@ncurses gdb reports from the cpu-x.core that was generated: Core was generated by `cpu-x'. Program terminated with signal SIGSEGV, Segmentation fault. Address not mapped to object. #0 0x2acc3a04 in __strtok_r (s=0x1 , delim=delim@entry=0x203f9e "]", last=) at /usr/main-src/lib/libc/string/strtok.c:60 60 c = *s++; (gdb) bt #0 0x2acc3a04 in __strtok_r (s=0x1 , delim=delim@entry=0x203f9e "]", last=) at /usr/main-src/lib/libc/string/strtok.c:60 #1 strtok (s=, delim=delim@entry=0x203f9e "]") at /usr/main-src/lib/libc/string/strtok.c:98 #2 0x002271bc in common_sighandler (signum=11, need_stop=true) at /wrkdirs/usr/ports/sysutils/cpu-x/work-ncurses/CPU-X-4.5.3/src/main.c:685 #3 0x27df981c in handle_signal (actp=actp@entry=0x24b520e0, sig=sig@entry=11, info=info@entry=0x24b52150, ucp=ucp@entry=0x24b521a0) at /usr/main-src/lib/libthr/thread/thr_sig.c:301 #4 0x27df8eb8 in thr_sighandler (sig=11, info=0x24b52150, _ucp=0x24b521a0) at /usr/main-src/lib/libthr/thread/thr_sig.c:244 #5 #6 0x0022e850 in print_activecore (win=0x26de3f714390, data=0x24b52980) at /wrkdirs/usr/ports/sysutils/cpu-x/work-ncurses/CPU-X-4.5.3/src/tui_ncurses.c:595 #7 ntab_cpu (win=0x26de3f714390, info=..., data=0x24b52980) at /wrkdirs/usr/ports/sysutils/cpu-x/work-ncurses/CPU-X-4.5.3/src/tui_ncurses.c:664 #8 0x0022d09c in start_tui_ncurses (data=data@entry=0x24b52980) at /wrkdirs/usr/ports/sysutils/cpu-x/work-ncurses/CPU-X-4.5.3/src/tui_ncurses.c:117 #9 0x00226ba8 in main (argc=, argv=) at /wrkdirs/usr/ports/sysutils/cpu-x/work-ncurses/CPU-X-4.5.3/src/main.c:858 # ldd -a `which cpu-x` /usr/local/bin/cpu-x: libm.so.5 => /lib/libm.so.5 (0x516dbd5000) libintl.so.8 => /usr/local/lib/libintl.so.8 (0x516f604000) libthr.so.3 => /lib/libthr.so.3 (0x516ea4f000) libexecinfo.so.1 => /usr/lib/libexecinfo.so.1 (0x516ff9c000) libncursesw.so.9 => /lib/libncursesw.so.9 (0x5170cc2000) libtinfow.so.9 => /lib/libtinfow.so.9 (0x51715f3000) libcpuid.so.16 => /usr/local/lib/libcpuid.so.16 (0x5172ab8000) libpci.so.3 => /usr/local/lib/libpci.so.3 (0x517203c000) libstatgrab.so.10 => /usr/local/lib/libstatgrab.so.10 (0x5172de8000) libdevstat.so.7 => /lib/libdevstat.so.7 (0x5173c8b000) libc.so.7 => /lib/libc.so.7 (0x5175986000) /lib/libm.so.5: libc.so.7 => /lib/libc.so.7 (0x5175986000) /usr/local/lib/libintl.so.8: libc.so.7 => /lib/libc.so.7 (0x5175986000) /lib/libthr.so.3: libc.so.7 => /lib/libc.so.7 (0x5175986000) /usr/lib/libexecinfo.so.1: libelf.so.2 => /lib/libelf.so.2 (0x51747b4000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x51750e8000) libc.so.7 => /lib/libc.so.7 (0x5175986000) /lib/libncursesw.so.9: libtinfow.so.9 => /lib/libtinfow.so.9 (0x51715f3000) libc.so.7 => /lib/libc.so.7 (0x5175986000) /lib/libtinfow.so.9: libc.so.7 => /lib/libc.so.7 (0x5175986000) /usr/local/lib/libcpuid.so.16: libc.so.7 => /lib/libc.so.7 (0x5175986000) /usr/local/lib/libpci.so.3: libz.so.6 => /lib/libz.so.6 (0x5176aee000) libc.so.7 => /lib/libc.so.7 (0x5175986000) /usr/local/lib/libstatgrab.so.10: libdevstat.so.7 => /lib/libdevstat.so.7 (0x5173c8b000) libthr.so.3 => /lib/libthr.so.3 (0x516ea4f000) libc.so.7 => /lib/libc.so.7 (0x5175986000) /lib/libdevstat.so.7: libkvm.so.7 => /lib/libkvm.so.7 (0x5177a46000) libc.so.7 => /lib/libc.so.7 (0x5175986000) /lib/libelf.so.2: libc.so.7 => /lib/libc.so.7 (0x5175986000) /lib/libgcc_s.so.1: libc.so.7 => /lib/libc.so.7 (0x5175986000) /lib/libz.so.6: libc.so.7 => /lib/libc.so.7 (0x5175986000) /lib/libkvm.so.7: libelf.so.2 => /lib/libelf.so.2 (0x51747b4000) libc.so.7 => /lib/libc.so.7 (0x5175986000) For reference: # uname -apKU FreeBSD CA72-16Gp-ZFS 15.0-CURRENT FreeBSD 15.0-CURRENT #121 main-n266749-ed31b3f4a146-dirty: Wed Nov 29 17:55:51 PST 2023 root@CA72-16Gp-ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 155 155 # ~/fbsd-based-on-what-commit.sh -C /usr/ports/ 6ec8e3450b29 (HEAD -> main, freebsd/main, freebsd/HEAD) devel/sdts++: Mark DEPRECATED Author: Muhammad Moinur Rahman Commit: Muhammad Moinur Rahman CommitDate: 2023-10-21 19:01:38 + branch: main merge-base: 6ec8e3450b29462a590d09fb0b07ed214d456bd5 merge-base: CommitDate: 2023-10-21 19:01:38 + n637598 (--first-parent --count for merge-base) === Mark Millard marklmi at yahoo.com
Re: aarch64: sysutils/cpu-x@ncurses got SIGSEGV during its initial print_activecore
On Dec 2, 2023, at 23:16, Mark Millard wrote: > Note: This is from my own poudriere-devel based build of: > sysutils/cpu-x@ncurses > > gdb reports from the cpu-x.core that was generated: > > Core was generated by `cpu-x'. > Program terminated with signal SIGSEGV, Segmentation fault. > Address not mapped to object. > #0 0x2acc3a04 in __strtok_r (s=0x1 address 0x1>, delim=delim@entry=0x203f9e "]", last=) at > /usr/main-src/lib/libc/string/strtok.c:60 > 60 c = *s++; > (gdb) bt > #0 0x2acc3a04 in __strtok_r (s=0x1 address 0x1>, delim=delim@entry=0x203f9e "]", last=) at > /usr/main-src/lib/libc/string/strtok.c:60 > #1 strtok (s=, delim=delim@entry=0x203f9e "]") at > /usr/main-src/lib/libc/string/strtok.c:98 > #2 0x002271bc in common_sighandler (signum=11, need_stop=true) at > /wrkdirs/usr/ports/sysutils/cpu-x/work-ncurses/CPU-X-4.5.3/src/main.c:685 > #3 0x27df981c in handle_signal (actp=actp@entry=0x24b520e0, > sig=sig@entry=11, info=info@entry=0x24b52150, ucp=ucp@entry=0x24b521a0) at > /usr/main-src/lib/libthr/thread/thr_sig.c:301 > #4 0x27df8eb8 in thr_sighandler (sig=11, info=0x24b52150, > _ucp=0x24b521a0) at /usr/main-src/lib/libthr/thread/thr_sig.c:244 > #5 > #6 0x0022e850 in print_activecore (win=0x26de3f714390, > data=0x24b52980) at > /wrkdirs/usr/ports/sysutils/cpu-x/work-ncurses/CPU-X-4.5.3/src/tui_ncurses.c:595 > #7 ntab_cpu (win=0x26de3f714390, info=..., data=0x24b52980) at > /wrkdirs/usr/ports/sysutils/cpu-x/work-ncurses/CPU-X-4.5.3/src/tui_ncurses.c:664 > #8 0x0022d09c in start_tui_ncurses (data=data@entry=0x24b52980) at > /wrkdirs/usr/ports/sysutils/cpu-x/work-ncurses/CPU-X-4.5.3/src/tui_ncurses.c:117 > #9 0x00226ba8 in main (argc=, argv=) > at /wrkdirs/usr/ports/sysutils/cpu-x/work-ncurses/CPU-X-4.5.3/src/main.c:858 > > # ldd -a `which cpu-x` > /usr/local/bin/cpu-x: > libm.so.5 => /lib/libm.so.5 (0x516dbd5000) > libintl.so.8 => /usr/local/lib/libintl.so.8 (0x516f604000) > libthr.so.3 => /lib/libthr.so.3 (0x516ea4f000) > libexecinfo.so.1 => /usr/lib/libexecinfo.so.1 (0x516ff9c000) > libncursesw.so.9 => /lib/libncursesw.so.9 (0x5170cc2000) > libtinfow.so.9 => /lib/libtinfow.so.9 (0x51715f3000) > libcpuid.so.16 => /usr/local/lib/libcpuid.so.16 (0x5172ab8000) > libpci.so.3 => /usr/local/lib/libpci.so.3 (0x517203c000) > libstatgrab.so.10 => /usr/local/lib/libstatgrab.so.10 (0x5172de8000) > libdevstat.so.7 => /lib/libdevstat.so.7 (0x5173c8b000) > libc.so.7 => /lib/libc.so.7 (0x5175986000) > /lib/libm.so.5: > libc.so.7 => /lib/libc.so.7 (0x5175986000) > /usr/local/lib/libintl.so.8: > libc.so.7 => /lib/libc.so.7 (0x5175986000) > /lib/libthr.so.3: > libc.so.7 => /lib/libc.so.7 (0x5175986000) > /usr/lib/libexecinfo.so.1: > libelf.so.2 => /lib/libelf.so.2 (0x51747b4000) > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x51750e8000) > libc.so.7 => /lib/libc.so.7 (0x5175986000) > /lib/libncursesw.so.9: > libtinfow.so.9 => /lib/libtinfow.so.9 (0x51715f3000) > libc.so.7 => /lib/libc.so.7 (0x5175986000) > /lib/libtinfow.so.9: > libc.so.7 => /lib/libc.so.7 (0x5175986000) > /usr/local/lib/libcpuid.so.16: > libc.so.7 => /lib/libc.so.7 (0x5175986000) > /usr/local/lib/libpci.so.3: > libz.so.6 => /lib/libz.so.6 (0x5176aee000) > libc.so.7 => /lib/libc.so.7 (0x5175986000) > /usr/local/lib/libstatgrab.so.10: > libdevstat.so.7 => /lib/libdevstat.so.7 (0x5173c8b000) > libthr.so.3 => /lib/libthr.so.3 (0x516ea4f000) > libc.so.7 => /lib/libc.so.7 (0x5175986000) > /lib/libdevstat.so.7: > libkvm.so.7 => /lib/libkvm.so.7 (0x5177a46000) > libc.so.7 => /lib/libc.so.7 (0x5175986000) > /lib/libelf.so.2: > libc.so.7 => /lib/libc.so.7 (0x5175986000) > /lib/libgcc_s.so.1: > libc.so.7 => /lib/libc.so.7 (0x5175986000) > /lib/libz.so.6: > libc.so.7 => /lib/libc.so.7 (0x5175986000) > /lib/libkvm.so.7: > libelf.so.2 => /lib/libelf.so.2 (0x51747b4000) > libc.so.7 => /lib/libc.so.7 (0x5175986000) > > > For reference: > > # uname -apKU > FreeBSD CA72-16Gp-ZFS 15.0-CURRENT FreeBSD 15.0-CURRENT #121 > main-n266749-ed31b3f4a146-dirty: Wed Nov 29 17:55:51 PST 2023 > root@CA72-16Gp-ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72 > arm64 aarch64 155 155 > > # ~/fbsd-based-on-what-commit.sh -C /usr/ports/ > 6ec8e3450b29 (HEAD -> main, freebsd/main, freebsd/HEAD) devel/sdts++: Mark > DEPRECATED > Author: Muhammad Moinur Rahman > Commit: Muhammad Moinur Rahman > CommitDate: 2023-10-21 19:01:38 + > branch: main > merge-base: 6ec8e3450b29462a590d09fb0b07ed214d456bd5 > merge-base: CommitDate: 2023-10-21 19:01:38 + > n637598 (--first-parent --count for merge-base) > Hmm. On thinking about it, the output: # cpu-x CPU-X:core.c:301: failed to call libcpuid (CPUID instruction is not supported) CPU-X:core.c:1478: failed to find chipset vendor and model CPU-X:core.c:1480: failed to find graphic card vendor and model CPU-X:core.c:2260: failed to retrieve CPU temperature (fallback mode) that als
