Bug 254751

Summary: devel/e2fsprogs-libss: fails to build with /bin/sh: compile_et: not found
Product: Ports & Packages Reporter: Felix Palmen <felix>
Component: Individual Port(s)Assignee: freebsd-ports-bugs (Nobody) <ports-bugs>
Status: Open ---    
Severity: Affects Only Me CC: bjk, kaduk-fbsd, mandree
Priority: --- Flags: bugzilla: maintainer-feedback? (kaduk-fbsd)
Version: Latest   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
poudriere build log
none
workaround for build error
none
Add option for kerberos support from MIT krb5
felix: maintainer-approval? (bjk)
use local compile_et in build mandree: maintainer-approval? (kaduk-fbsd)

Description Felix Palmen 2021-04-03 22:08:05 UTC
Created attachment 223795 [details]
poudriere build log

FreeBSD 13.0-RC5, building with poudriere for i386, building fails with this:

===>  Building for e2fsprogs-libss-1.46.2
(cd /wrkdirs/usr/ports/devel/e2fsprogs-libss/work/e2fsprogs-1.46.2/lib/ss && compile_et ss_err.et &&  /usr/bin/sed -i.bak -f /usr/ports/devel/e2fsprogs-libss/files/fix-ss_err.h.sed ss_err.h)
/bin/sh: compile_et: not found
*** Error code 127

Full poudriere log attached.

Trying to fix this myself, I found I can build and use compile_et from inside the source tree itself, which leads to the next problem: libcom_err is required.

This is part of e2fsprogs package, which *depends* on e2fsprogs-libss.
Comment 1 Felix Palmen 2021-04-03 22:12:18 UTC
Created attachment 223796 [details]
workaround for build error

I made it build successfully with this patch, but I think it's the wrong thing to do. libcom_err.so will still be installed by e2fsprogs and yet be linked here…
Comment 2 Benjamin Kaduk freebsd_committer 2021-04-25 03:14:13 UTC
Thanks for the report.
The compile_et that I was expecting to be used is /usr/bin/compile_et, which is only built conditionally on MK_KERBEROS_SUPPORT.
Since January 2020 (0ce9d0af5b7fdfde335c753cb3310650a9d31d09) MK_KERBEROS_SUPPORT is forced off when KERBEROS itself is off, so if you are disabling either in your environment then this behavior for the port build is unsurprising.

I will take a look at what the best option is; it may well just be marking the port as not usable when /usr/bin/compile_et is not available.
Comment 3 Felix Palmen 2021-04-25 11:34:05 UTC
Aha! Thanks for the pointer.
I had no idea compile_et is related to kerberos. Indeed, I build my base without kerberos and use MIT krb5 from ports. Will have a look whether compile_et is provided there…

Would this also solve the other problem I came across (circular dependency around libcom_err)? Or did I misunderstand something there?
Comment 4 Benjamin Kaduk freebsd_committer 2021-04-25 20:11:56 UTC
(In reply to Felix Palmen from comment #3)

> I had no idea compile_et is related to kerberos. Indeed, I build my base without kerberos and use MIT krb5 from ports. Will have a look whether compile_et is provided there…

MIT krb5 does have a compile_et script in its build (bourne shell and awk), and it's in the pkg-plist for the FreeBSD port, so I think it should be suitable for this purpose.

> Would this also solve the other problem I came across (circular dependency around libcom_err)? Or did I misunderstand something there?

I think so -- despite the name being for a "common error-reporting library", there are quite a number of libcom_err implementations around, including from the major kerberos implementations.
Comment 5 Felix Palmen 2021-04-27 13:35:53 UTC
Created attachment 224472 [details]
Add option for kerberos support from MIT krb5

Ok, this enabled me to have a better solution for my usecase. I tried to support heimdal from ports as well, but unfortunately, this doesn't install compile_et. Another option would be to also support the in-tree tools, but this would require more change, because right now, the included libcom_err is installed with sysutils/e2fsprogs, so this would create the circular dependency again…
Comment 6 Matthias Andree freebsd_committer 2021-06-03 14:58:07 UTC
Created attachment 225529 [details]
use local compile_et in build

If it's solely about building the e2fsprogs-libss port, we might leverage the shipped lib/et/compile_et, as proposed in this patch.

This would require tests of its users and a PORTREVISION bump if applied, which my patch does not currently do.