Solved Q/A tests fail, even though port builds, installs and works

I'm just finished making a port for SOGo (groupware). It builds and installs, and works. Although I haven't tested it thoroughly yet, I'm confident it works well. The OpenBSD port patches were the secret to my success, and that porter has been running it for weeks with no issues.

The make check-plist has no errors. The portlint -AC has no errors, one warning which is a false positive.

However, when I put DEVELOPER=yes in my /etc/make.conf, it produces the following error:
Code:
====> Compressing man pages (compress-man)
===> Staging rc.d startup script(s)
===>  Installing ldconfig configuration file
====> Running Q/A tests (stage-qa)
Error: 'GNUstep/Local/Library/Frameworks/SOGo.framework/Versions/2/sogo/libSOGo.so.2.2.14' is referring to /usr/ports/www/sogo/work/stage
*** Error code 1

Stop.
make: stopped in /usr/ports/www/sogo
It doesn't fail without DEVELOPER=yes.

How can I fix this please?
 
That error comes from the ports staging qa tests file /usr/ports/Mk/Scripts/qa.sh.

If you look at the paths() test starting on line 112, it is searching through each of the files in your PLIST to ensure they don't have the staging directory hard coded in them. In your case, it found a file which did, which is a problem since this will not be the final installed location.

You need to work out why the libSOGo.so.2.2.14 file is referencing the stage directory and fix it.
 
Thanks for the links woodsb02, however, they didn't help me much. I understand the staging process, but Idon't know ehat goes on under the hood to create linkage etc to a certain path.

What is strange is that after installing my port, it works. And libSOGo.so.2.2.14 is mission critical to SOGo working (at all). So basically, if the system can't find that library, SOGo shouldn't work at all. Which brings the question: why is Q/A complaining.

Below is the output of an ls command after installing the port (without DEVELOPER=yes):

Code:
[root@sogo /]# ls -l /usr/local/GNUstep/Local/Library/Frameworks/SOGo.framework/Versions/2/sogo/
total 702   
lrwxr-xr-x  1 root  wheel  10  1 Feb 02:03 SOGo@ -> libSOGo.so   
lrwxr-xr-x  1 root  wheel  12  1 Feb 02:03 libSOGo.so@ -> libSOGo.so.2   
lrwxr-xr-x  1 root  wheel  17  1 Feb 02:03 libSOGo.so.2@ -> libSOGo.so.2.2.14   
-rwxr-xr-x  1 root  wheel  1740400  1 Feb 02:03 libSOGo.so.2.2.14*   
[root@sogo /]#

I'm not too familiar with Makefile's and stage building. Can you please point me to some documentation that can help me understand what is going on.

The pkg-plist does not refer to /usr/ports/www/sogo/work/stage.

After running make in the www/sogo directory, the staeg files seem fine to me:

Code:
[root@sogo /usr/ports/www/sogo]# ls -l work/stage/usr/local/GNUstep/Local/Library/Frameworks/SOGo.framework/Versions/2/sogo/
total 702
lrwxr-xr-x  1 root  wheel  10  2 Feb 04:36 SOGo@ -> libSOGo.so
lrwxr-xr-x  1 root  wheel  12  2 Feb 04:36 libSOGo.so@ -> libSOGo.so.2
lrwxr-xr-x  1 root  wheel  17  2 Feb 04:36 libSOGo.so.2@ -> libSOGo.so.2.2.14
-rwxr-xr-x  1 root  wheel  1740400  2 Feb 04:36 libSOGo.so.2.2.14*

Is it possible the /usr/ports/Mk/Scripts/qa.sh is expecting a canonical (full) path link, as opposed to a relative symlink?
 
Look at the strings contained in the libSOGo.so.2.2.14 shared library, for example with strings(1). I bet that you'll find that one of the strings contains the offending path that refers to the stage directory. Why it is there I can only guess but the build system of the software in question is probably expecting that the software is always installed directly on the system (/usr/local) and staging breaks this assumption.
 
As kpa said, the problem is that the string /usr/ports/www/sogo/work/stage is contained within the library file libSOGo.so.2.2.14.

If you run make clean after you have installed your port, does the program still run fine? I suspect the program was only working because the stage directory still contained the necessary files.
 
As kpa said, the problem is that the string /usr/ports/www/sogo/work/stage is contained within the library file libSOGo.so.2.2.14.

If you run make clean after you have installed your port, does the program still run fine? I suspect the program was only working because the stage directory still contained the necessary files.

Yes, it runs fine after make clean. I have used the strings command, and you're right, it is in the output. The output of strings makes no sense to me, but I'm getting closer I guess. What I noticed is that it's not pointing to a file, it's pointing to a directory. Below is the relevant part of the strings output:

Code:
...
initWithCoder:
@24@0:8@16
NSCoding
beginContentAccess
discardContentIfPossible
endContentAccess
isContentDiscarded
NSDiscardableContent
/usr/ports/www/sogo/work/stage/usr/local/GNUstep/Local/Library/Frameworks
r^@16@0:8
frameworkEnv
frameworkPath
frameworkVersion
frameworkClasses
NSFramework_SOGo
SOGoProductLoader
EOBitmaskQualifier
...

What's strange is that aside from the installed port working, the other libs are fine. And the port I made that's a dependency of SOGo (SOPE) is made by the same devs. It has no issues, even with DEVELOPER=yes.

Where do I go from here, is there any flags I can pass in my Makefile to tell it it is staged. Is this what stripping is for?
 
I just noticed that I am suppposedly stripping already. (No obvious puns please)

I already have:

Code:
CONFIGURE_ARGS=  --disable-debug --enable-strip
 
Nope, adding the following to my post-stage section had no positive effect:

Code:
${STRIP_CMD} ${STAGEDIR}${PREFIX}/GNUstep/Local/Library/Frameworks/SOGo.framework/Versions/2/sogo/libSOGo.so.2.2.14
 
One option would be to ignore the warning that is given with DEVELOPER=yes. It is not stopping you from building or installing the port, it is just warning you that it might not work because the library appears to reference the staging directory.

It really depends on why that incorrect string is in the library file (whether it will use it or if it is just referencing where it was installed but won't use it). If it works, maybe it is ok to ignore the warning?
 
One option would be to ignore the warning that is given with DEVELOPER=yes. It is not stopping you from building or installing the port, it is just warning you that it might not work because the library appears to reference the staging directory.

It really depends on why that incorrect string is in the library file (whether it will use it or if it is just referencing where it was installed but won't use it). If it works, maybe it is ok to ignore the warning?

Yes, I think it is a false positive in the stage-qa test. However, it is treated as an error, not a warning.

I'm just learning how to port, these are my first two I've created. I was told it must pass portlint -AC, make check-plist and with DEVELOPER=yes. Maybe I took it too seriously. Anyways, if it doesn't have to build with DEVELOPER=yes, then I will proceed to test on other versions / architectures.

At this stage, should I submit it. How to do go about getting it into ports tree?
 
The stripping is not a problem I think. The --enable-strip does that before it gets to do-install.
 
To confirm they are stripped, run the file(1) command on the library. It will report if it is stripped or unstripped.

As for this stage-qa error, I recommend sending an email to ports@freebsd.org, explaining that the library in your port contains the stage directory in the binary file (confirmed by strings(1)) and as such fails the stage-qa check. Explain that it seems to work fine once installed (even after a make clean), and if anyone can recommend a way to investigate if this is a problem and resolve it. More ports developers follow that mailing list than these forums, so you might get a better response.

How to submit a new port is also explained by the Porter's Handbook:
https://www.freebsd.org/doc/en/books/porters-handbook/porting-submitting.html

I recommend submitted the bug report for the new port before emailing the ports mailing list. That way you can reference the new port and people can investigate themselves with all the details. You can always modify the bug report if you improve the port once getting feedback.
 
Make sure you have followed the Do's and Don'ts section of the Porter's Handbook as close as possible.

When submitting the bug report, title it "[NEW PORT] category/portname".

Also, I have found the ports mailing list works best if, as you have done with this forum thread, you ask a targeted question, rather than a broad "here's my port, is anything outstanding?"
 
Thanks woodsb02. I will follow your suggestions as soon as I have time. I'm still busy with migrating my server on a colocation. Getting a working up-to-date SOGo was instrumental to that. Hopefully soon I'll have time to test other FreeBSD versions / architectures.
 
Last edited by a moderator:
OK, so I've resumed development of this port. Whilst I ignored the stage-qa myself, knowing it to be a false-positive, ports-mgmt/poudriere does not want to ignore it.

I can confirm the file is being stripped:

Code:
# file work/stage/usr/local/GNUstep/Local/Library/Frameworks/SOGo.framework/Versions/Current/sogo/libSOGo.so.2.3.2
work/stage/usr/local/GNUstep/Local/Library/Frameworks/SOGo.framework/Versions/Current/sogo/libSOGo.so.2.3.2: ELF 64-bit LSB shared object, x86-64, version 1 (FreeBSD), dynamically linked, stripped

As can be seen below, the strings command shows that only one path is referring to stage directory. The rest are referring to the proper prefix path. So the GNUstep-make or SOGo code is doing something unusual by referring to the stage directory within the output lib.

Code:
# strings work/stage/usr/local/GNUstep/Local/Library/Frameworks/SOGo.framework/Versions/Current/sogo/libSOGo.so.2.3.2 | grep "/usr/local"
/usr/local/GNUstep/System/Library/Libraries/sogo
/usr/ports/www/sogo/work/stage/usr/local/GNUstep/Local/Library/Frameworks
/usr/local/etc/sogo/debconf.conf
/usr/local/etc/sogo/sogo.conf
/usr/local/GNUstep/Local/Library/SOGo/libSOGoNSUserDefaults.so.1

To re-iterate, the sogod service runs perfectly, even after a make clean.
 
I'm very interested in trying out your port and help figure out the remaining issues. Where can I find your repo or patches?

Edit: found your github and apparently the port is in the official tree now. Thanks for your efforts.
 
Would you mind posting here what Kurt did to the GNUstep Makefiles to get this to work? It might be helpful for future people having this issue that come across this thread.
 
Well, I'll try my best. It's not a straight forward solution. I took what Kurt did for granted. But here are the relevant patches to the port www/sogo. It would probably take a short lecture from Kurt to explain how it was solved (well, perhaps it should be called a workaround).

From my understanding, he copied some global GNUstep-make stuff into the sogo project and hacked around the bad behaviour of GNUstep-make.

The solution can be found in the following files:
/usr/ports/www/sogo/files/patch-Main_GNUmakefile.preamble
/usr/ports/www/sogo/files/patch-SoObjects_SOGo_GNUmakefile
/usr/ports/www/sogo/files/patch-SoObjects_SOGo_instance-framework.make
/usr/ports/www/sogo/files/patch-SoObjects_SOGo_master-framework.make
/usr/ports/www/sogo/files/patch-Tests_Unit_GNUmakefile
/usr/ports/www/sogo/files/patch-Tools_GNUmakefile.preamble

NOTE: Some of these patches may fix other, unrelated build issues that I missed in my patches.

Code:
$ cat www/sogo/files/patch-Main_GNUmakefile.preamble
--- Main/GNUmakefile.preamble.orig  2015-09-16 18:41:29 UTC
+++ Main/GNUmakefile.preamble
@@ -22,4 +22,4 @@ $(SOGOD)_TOOL_LIBS += \
  -lNGObjWeb  \
  -lNGMime -lNGLdap  \
  -lNGStreams -lNGExtensions -lEOControl \
-  -lDOM -lSaxObjC
+  -lDOM -lSaxObjC -lSBJson

$ cat www/sogo/files/patch-SoObjects_SOGo_GNUmakefile
--- SoObjects/SOGo/GNUmakefile.orig  2015-09-16 18:41:36 UTC
+++ SoObjects/SOGo/GNUmakefile
@@ -203,7 +203,8 @@ ifneq ($(FHS_INSTALL_ROOT),)
 GNUSTEP_HEADERS=$(DESTDIR)$(FHS_INSTALL_ROOT)/include
 endif
 GNUSTEP_TARGET_LDIR=sogo
-include $(GNUSTEP_MAKEFILES)/framework.make
+
+include master-framework.make
 include $(GNUSTEP_MAKEFILES)/library.make
 include $(GNUSTEP_MAKEFILES)/tool.make
 -include GNUmakefile.postamble

$ cat www/sogo/files/patch-SoObjects_SOGo_master-framework.make
--- SoObjects/SOGo/master-framework.make.orig  2015-09-23 03:38:31 UTC
+++ SoObjects/SOGo/master-framework.make
@@ -0,0 +1,30 @@
+#
+#  framework.make
+#
+#  Makefile rules to build GNUstep-based frameworks.
+#
+#  Copyright (C) 2002 Free Software Foundation, Inc.
+#
+#  Author:  Nicola Pero <nicola@brainstorm.co.uk>
+#
+#  This file is part of the GNUstep Makefile Package.
+#
+#  This library is free software; you can redistribute it and/or
+#  modify it under the terms of the GNU General Public License
+#  as published by the Free Software Foundation; either version 3
+#  of the License, or (at your option) any later version.
+#   
+#  You should have received a copy of the GNU General Public
+#  License along with this library; see the file COPYING.
+#  If not, write to the Free Software Foundation,
+#  51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+
+ifeq ($(GNUSTEP_INSTANCE),)
+include $(GNUSTEP_MAKEFILES)/Master/framework.make
+else
+
+ifeq ($(GNUSTEP_TYPE),framework)
+include instance-framework.make
+endif
+
+endif

$ cat www/sogo/files/patch-Tests_Unit_GNUmakefile
--- Tests/Unit/GNUmakefile.orig 2015-09-16 18:41:31 UTC
+++ Tests/Unit/GNUmakefile
@@ -35,7 +35,10 @@ $(TEST_TOOL)_CPPFLAGS += \
  -Wall -D_GNU_SOURCE -I../../SOPE/ -I../../SoObjects/ -I../../UI/
 ADDITIONAL_LIB_DIRS += \
-  -L../../SoObjects/SOGo/SOGo.framework/Versions/Current/sogo -L../../SOPE/NGCards/obj -L../../SOPE/GDLContentStore/obj -lSOGo -lNGMime -lNGCards -lGDLContentStore -lNGExtensions -lSBJson -lobjc \
+  -L../../SoObjects/SOGo/SOGo.framework/Versions/Current/sogo -L../../SOPE/NGCards/obj -L../../SOPE/GDLContentStore/obj \
+  -lSOGo -lNGMime -lNGCards -lGDLContentStore -lNGExtensions \
+  -lSBJson -lGDLAccess -lNGObjWeb -lNGStreams -lEOControl -lDOM \
+  -lNGLdap -lobjc \
  -L/usr/local/lib  -lSaxObjC \
  -Wl,-rpath,../../SoObjects/SOGo/SOGo.framework/Versions/Current/sogo -Wl,-rpath,../../SOPE/NGCards/obj -Wl,-rpath,../../SOPE/GDLContentStore/obj
 ADDITIONAL_LDFLAGS += -Wl,--no-as-needed

$ cat www/sogo/files/patch-Tools_GNUmakefile.preamble
--- Tools/GNUmakefile.preamble.orig  2015-09-16 18:41:31 UTC
+++ Tools/GNUmakefile.preamble
@@ -13,4 +13,5 @@ ADDITIONAL_LIB_DIRS += \
  -L../SoObjects/SOGo/SOGo.framework/sogo -lSOGo \
  -L../SOPE/GDLContentStore/$(GNUSTEP_OBJ_DIR)/ -lGDLContentStore \
  -L../SOPE/NGCards/$(GNUSTEP_OBJ_DIR)/ -lNGCards \
-  -lEOControl -lNGStreams -lNGMime -lNGExtensions -lNGObjWeb
+  -lEOControl -lNGStreams -lNGMime -lNGExtensions -lNGObjWeb \
+  -lGDLAccess -lDOM -lSaxObjC -lNGLdap -lSBJson

The file patch-SoObjects_SOGo_instance-framework.make.txt had to be uploaded since it's too large to paste. Also, I had to rename it with file extension ".txt", since the forum software requires it.
 

Attachments

  • patch-SoObjects_SOGo_instance-framework.make.txt
    34.1 KB · Views: 358
Back
Top