|Summary:||security/greenbone-security-assistant: Build fails on 12.2-stable|
|Product:||Ports & Packages||Reporter:||jau|
|Component:||Individual Port(s)||Assignee:||Jose Alonso Cardenas Marquez <acm>|
|Severity:||Affects Some People||CC:||dewayne|
Description jau 2021-02-14 18:02:51 UTC
Created attachment 222441 [details] a typescript of a failed build Greenbone-security-assistant build fails on FreeBSD-12.2-stable. Find a typescript of a failed build attached.
Comment 1 dewayne 2021-02-14 20:31:47 UTC
Hi Jan, as an FYI. I've successfully built greenbone-security-assistant on 12.2-STABLE #0 r368820M: Wed Jan 6 00:20:53 AEDT 2021, both i386 and amd64. However I did remove doxygen from RUN_DEPENDS and used gcc10 as the compiler. I'm unsure whether it was gvm or greenbone that failed to build on older i386's CPUTYPES like c3-2 or pentium3 due to the requirement for sse2. (doxygen is a monster to build as it pulls in a lot of packages).
Comment 2 Jose Alonso Cardenas Marquez 2021-02-14 20:40:58 UTC
(In reply to dewayne from comment #1) Why don't use packages (pkg) instead of compile it from ports? it could be better than compile these ports on old machine
Comment 3 dewayne 2021-02-14 22:38:16 UTC
Fair question. We build: - for specific targets where we specify the CPUTYPE - with a focus on security, we can ensure that the required options are chosen. Sometimes maintainers tweak the defaults options, so we explicity use SET/UNSET all options because reproducibility is important and infrequently a maintainer turns on/off previous default settings. - using "unusual" compiler and linker directives ;) A port maintainer typically chooses from one of these paradigms: . enable all options (ie defaults) for wide test coverage and/or the availability of a full feature-set; . enable some options that they use or deem most useful, as that is what they use/support; . other maintainers default to very few options leaving the choice to the user. As you might guess, the freedom to customise is important as it enables the application of a consistent paradigm. I used packages extensively when we started with FreeBSD (around 2.2.5 -2.2.8), as our experience grew so did ensuring that our understanding of client needs, which is met by rolling our own (packages). This is a real gift that the ports infrastructure continues to provide, from which we (all) benefit :) Old equipment? Sometimes a client will refuse to upgrade their hardware because they just want it to continue to function (typically when hands-on Directors are technically naive). One client continues to use a VIA C3-2 (from 2005) which FreeBSD (and we) support. Let me know if I haven't answered - why? :)
Comment 4 dewayne 2021-02-14 22:45:48 UTC
(In reply to jau from comment #0) Jan, I think your problem is that yarn is trying to pull https://registry.yarnpkg.com/@babel/core/-/core-7.10.4.tgz when I'm internet connected, I can access the file. Take a close look at your attachment to this PR. I suspect that you may have a resolution or access problem? I'd try putting the core-7.10.4 file where "yarn -offline" expects it. greenbone uses yarn though I have no idea what or why it does what it does. I'd suggest that this bug should be assigned to www/yarn if you need help.