Can we remove FREEBSD_TEMPLATE from devel/subversion now?
Or at least not make it the default. I have never understood why this was the default anyway. FreeBSD committers will most likely build from source and can add that flag if they want. As default it becomes the option for people installing from packages and they can't remove that template for all of their non-FreeBSD work. Now that we have switched to git it seems even more so that it should not be the default. Or is there some way to remove/change that template after installing from the package that I am missing. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 788 2246 (DoD#0082)(eNTP) | what's for dinner. IM: da...@vex.net, VoIP: sip:da...@druid.net
armv7 target (on aarch64 HW) and poudriere-based emulators/mame link failure vs. success based on the number of cores
On a HoneyComb (16 cores) I did a bulk -a targetting armv7 that had emulators/mame fail as unable to allocate during a link. Linking by default use slightly more threads than the freebsd cpu count. The HoneyComb had 64 GiByte of RAM and over 12 MiByte of swap partitioning set up. The swap was never used during the bulk -a examples. On a MACCHIATObin Double Shot (4 cores) with nearly identical media booted, attempting to build emulators/mame worked fine. (I did not try a bulk -a: it would take far too long for my time preferences.) (I've also gotten a report of success building on a RPi4B, also 4 cores.) The HoneyComb failure looks to me like like hitting the process size limitations for armv7, something that did not happen on the MACCHIATObin Double Shot or RPi4B (fewer cores). It looks to me like 32-bit architectures (such as armv7) should possibly have the multi-threaded link disabled by default for FreeBSD unless ports are adjusted to disable multi-threaded individually. (I do not claim that mame is the only example of such an issue in the bulk -a --or on systems with even more cores. It just happens to be an example that I noticed.) For reference: # uname -apKU FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #12 main-n249019-0637070b5bca-dirty: Tue Aug 31 02:24:20 PDT 2021 root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400032 1400032 # cd /usr/ports/ # ~/fbsd-based-on-what-commit.sh branch: main merge-base: b0c4eaac2a3aa9bc422c21b9d398e4dbfea18736 merge-base: CommitDate: 2021-09-07 21:55:24 + b0c4eaac2a3a (HEAD -> main, freebsd/main, freebsd/HEAD) security/suricata: Add patch for upstream locking fix n557269 (--first-parent --count for merge-base) BUT: a rust 1.55 was in use on the HoneyComb as a test for another issue, at least fore the second bulk -a run that then tried to see what would no longer fail when targeting armv7. (Note: The HoneyComb is busy doing a bulk -a targeting aarch64 now.) Side notes . . . I'll note that the HoneyComb can do a from-scratch bulk -a targeting armv7 in less time than the official FreeBSD servers do (via amd64). A specific exxample was a bulk -a completed in somewhat under 87.25 hours, building 26995 ports successfully. (Not that I configure and operate in a configuration matching official FreeBSD serves. I allow a huge load average: 16 builds with ALLOW_MAKE_JOBS defined and have a large swap partitioning for a 64 GiByte machine (for in case of an unfortunately combination of overlapping huge builds). Mostly this is likely due to having the lang/gcc* (and such) build via a full bootstrap on amd64 targeting armv7. The native-toochain cross-build use does not help after the first part of such a build. Note: I do not normally do bulk -a or build rust or build mame. The activity is experimental and a test of the HoneyComb. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Re: Can't build a working package for texlive-texmf
On 2021-04-20 10:44 a.m., D'Arcy Cain wrote: > On 2021-04-20 9:05 a.m., Mateusz Piotrowski wrote: >> On 20/04/2021 14:36, D'Arcy Cain wrote: >>> I guess my next step is to install gdb and build pkg with symbols >>> unless someone can point me to an easy answer. >> >> Just a note: you may have a debugger already installed as >> /usr/bin/lldb. Also, pkg, in contrast to other binaries, is not >> stripped, so the chances are that you are not going to have to rebuild >> anything. > > You are correct. I have run it and found that it fails in the function > pkg_parse_archive. It calls pkg_parse_manifest and on return it does a > comparison and then jumps to a call to __stack_chk_fail. > > It still smells like a size issue but I am not sure how to fix it. The > package installs on the ports server with "make clean package install" > and the client machine has more memory than it. The ports server has > 2GB and the client has 8GB. Five months later and I still have this issue. This morning I tried installing the package from the FreeBSD repository and I have the same problem with that one. Can anyone suggest anything else that I can try? -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 788 2246 (DoD#0082)(eNTP) | what's for dinner. IM: da...@vex.net, VoIP: sip:da...@druid.net
Re: Can we remove FREEBSD_TEMPLATE from devel/subversion now?
Yes, please +1 Van: D'Arcy Cain Datum: 19 september 2021 10:51 Aan: freebsd-po...@freebsd.org Onderwerp: Can we remove FREEBSD_TEMPLATE from devel/subversion now? Or at least not make it the default. I have never understood why this was the default anyway. FreeBSD committers will most likely build from source and can add that flag if they want. As default it becomes the option for people installing from packages and they can't remove that template for all of their non-FreeBSD work. Now that we have switched to git it seems even more so that it should not be the default. Or is there some way to remove/change that template after installing from the package that I am missing. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 788 2246 (DoD#0082)(eNTP) | what's for dinner. IM: da...@vex.net, VoIP: sip:da...@druid.net
security/metasploit: package ... is not in GOROOT
Hi,
I'm trying to create an portupdate for metasploit. The created patch is
working fine and the new metasploit works, but when starting metasploit I
get some warnings:
[...]
[!] The following modules could not be loaded!..|
[!]
/usr/local/share/metasploit/modules/auxiliary/scanner/msmail/exchange_enum.go
[!]
/usr/local/share/metasploit/modules/auxiliary/scanner/msmail/onprem_enum.go
[!]
/usr/local/share/metasploit/modules/auxiliary/scanner/msmail/host_id.go
[!] Please see /home/marco/.msf4/logs/framework.log for details.
[...]
Checking framework.log reveals that:
[...]
/usr/local/share/metasploit/modules/auxiliary/scanner/msmail/exchange_enum.go:8:2:
package metasploit/module is not in GOROOT
(/usr/local/go/src/metasploit/module)
/usr/local/share/metasploit/modules/auxiliary/scanner/msmail/exchange_enum.go:9:2:
package msmail is not in GOROOT
(/usr/local/go/src/msmail)
[...]
So metasploit is searching in /usr/local/go while the go modules are
installed in /usr/local/share/metasploit/modules.
I added "USES=go", "SHEBANG_LANG=go" and the relative paths to
"SHEBANG_FILES", but it keeps giving the warnings. The Makefile so
far is:
[...]
# Created by: Yonatan
PORTNAME= metasploit
PORTVERSION=6.1.6
CATEGORIES= security
MAINTAINER= tana...@gmail.com
COMMENT=Exploit-Framework for Penetration-Testing
LICENSE=BSD3CLAUSE
LICENSE_FILE= ${WRKSRC}/COPYING
RUN_DEPENDS=nmap:security/nmap \
${PYTHON_PKGNAMEPREFIX}requests>=0:www/py-requests@${PY_FLAVOR}
\
rubygem-activerecord52>=5.2.2:databases/rubygem-activerecord52 \
rubygem-activesupport52>=5.2.2:devel/rubygem-activesupport52 \
rubygem-actionpack52>=5.2.2:www/rubygem-actionpack52 \
rubygem-bcrypt>=0:security/rubygem-bcrypt \
rubygem-bson>=0:devel/rubygem-bson \
rubygem-bundler>=0:sysutils/rubygem-bundler \
rubygem-jsobfu>=0:www/rubygem-jsobfu \
rubygem-json>=0:devel/rubygem-json \
rubygem-metasm>=0:devel/rubygem-metasm \
rubygem-metasploit-aggregator>=0:security/rubygem-metasploit-aggregator \
rubygem-metasploit-concern>=0:security/rubygem-metasploit-concern \
rubygem-metasploit-credential>=0:security/rubygem-metasploit-credential \
rubygem-metasploit_data_models>=0:security/rubygem-metasploit_data_models \
rubygem-metasploit-model>=0:security/rubygem-metasploit-model \
rubygem-metasploit-payloads>=2.0.24:security/rubygem-metasploit-payloads \
rubygem-metasploit_payloads-mettle>=1.0.2:security/rubygem-metasploit_payloads-mettle
\
rubygem-msgpack>=0:devel/rubygem-msgpack \
rubygem-network_interface>=0:net/rubygem-network_interface \
rubygem-rubyntlm>=0:net/rubygem-rubyntlm \
rubygem-nokogiri>=0:textproc/rubygem-nokogiri \
rubygem-packetfu>=0:net/rubygem-packetfu \
rubygem-pcaprub>=0:net/rubygem-pcaprub \
rubygem-pg>=0:databases/rubygem-pg \
rubygem-railties52>=5.2.2:www/rubygem-railties52 \
rubygem-recog>=0:security/rubygem-recog \
rubygem-openssl-ccm>=0:security/rubygem-openssl-ccm \
rubygem-octokit>=0:net/rubygem-octokit \
rubygem-redcarpet>=0:textproc/rubygem-redcarpet \
rubygem-patch_finder>=0:devel/rubygem-patch_finder \
rubygem-puma>=0:www/rubygem-puma \
rubygem-thin>=0:www/rubygem-thin \
rubygem-sinatra>=0:www/rubygem-sinatra \
rubygem-warden>=0:devel/rubygem-warden \
rubygem-em-http-request>=0:www/rubygem-em-http-request \
rubygem-tzinfo-data>=0:devel/rubygem-tzinfo-data \
rubygem-sshkey>=0:security/rubygem-sshkey \
rubygem-bit-struct>=0:devel/rubygem-bit-struct \
rubygem-windows_error>=0:devel/rubygem-windows_error \
rubygem-xmlrpc>=0:net/rubygem-xmlrpc \
rubygem-pdf-reader>=0:print/rubygem-pdf-reader \
rubygem-ruby-macho>=0:devel/rubygem-ruby-macho \
rubygem-dnsruby>=0:dns/rubygem-dnsruby \
rubygem-mqtt>=0:net/rubygem-mqtt \
rubygem-net-ldap>=0:net/rubygem-net-ldap \
rubygem-net-ssh>=0:security/rubygem-net-ssh \
rubygem-ed25519>=0:security/rubygem-ed25519 \
rubygem-bcrypt_pbkdf>=0:security/rubygem-bcrypt_pbkdf \
rubygem-ruby_smb>=0:net/rubygem-ruby_smb \
rubygem-rex-arch>=0:security/rubygem-rex-arch \
rubygem-rex-bin_tools>=0:security/rubygem-rex-bin_tools \
rubygem-rex-core>=0:security/rubygem-rex-core \
rubygem-rex-encoder>=0:security/rubygem-rex-enco
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 +-+ games/abuse_sdl | 0.8 | 0.9.0 +-+ 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: Can we remove FREEBSD_TEMPLATE from devel/subversion now?
On 19/09/2021 8:02 pm, Ronald Klop wrote: Yes, please +1 Van: D'Arcy Cain Datum: 19 september 2021 10:51 Aan: freebsd-po...@freebsd.org Onderwerp: Can we remove FREEBSD_TEMPLATE from devel/subversion now? Or at least not make it the default. I have never understood why this was the default anyway. FreeBSD committers will most likely build from source and can add that flag if they want. As default it becomes the option for people installing from packages and they can't remove that template for all of their non-FreeBSD work. Now that we have switched to git it seems even more so that it should not be the default. Or is there some way to remove/change that template after installing from the package that I am missing. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 788 2246 (DoD#0082) (eNTP) | what's for dinner. IM: da...@vex.net, VoIP: sip:da...@druid.net A bugzilla issue being created with a proposed patch would be great, thanks!
