Bug 253514

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>
Status: New ---    
Severity: Affects Some People CC: dewayne
Priority: --- Flags: bugzilla: maintainer-feedback? (acm)
Version: Latest   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
a typescript of a failed build none

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 freebsd_committer 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.