Community Packages

Please read this before reporting a bug:
http://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#50135 - [gnustep-make] make install installs files to /usr/sbin/

Attached to Project: Community Packages
Opened by DJ Lucas (DJ_Lucas) - Saturday, 23 July 2016, 19:35 GMT
Last edited by Sergej Pupykin (sergej) - Friday, 29 July 2016, 17:06 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Sergej Pupykin (sergej)
Architecture x86_64
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description: package function in PKGBUILD files no longer honors our on-disk symlinks while in the fakeroot environment. Not sure if that is strictly a bug, it probably shouldn't have worked before, but it is clearly a change in behavior. I've only now started investigating the cause thinking this was a fakeroot regression. I've been through the config files and find nothing obvious was changed in the GNUStep.conf, but the GNUSTEP*ADMIN_TOOLS dirs need to be set to /usr/bin, which fixes the --with-gnustep configure argument for step packages (both in fakeroot and out).

Additional info:
* package version(s)
gnustep-make-2.6.8-1

Steps to reproduce:

Please bear with me as this is long...

With gnustep-pmake-2.6.7-1:

[pkguser@server3 sogo]$ makepkg -s
==> Making package: sogo 3.1.4-1 (Fri Jul 22 13:07:19 CDT 2016)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
-> Downloading SOGo-3.1.4.tar.gz...

<snip>

-> Compressing package...
==> Leaving fakeroot environment.
==> Finished making: sogo 3.1.4-1 (Fri Jul 22 13:09:52 CDT 2016)
[pkguser@server3 sogo]$ ls -l pkg/sogo/usr/
total 12
drwxr-xr-x 2 pkguser pkguser 4096 Jul 22 13:09 bin
drwxr-xr-x 5 pkguser pkguser 4096 Jul 22 13:09 include
drwxr-xr-x 5 pkguser pkguser 4096 Jul 22 13:09 lib
[pkguser@server3 sogo]$ cd src/SOGo-3.1.4
[pkguser@server3 SOGo-3.1.4]$ make DESTDIR=$PWD/dest install
This is gnustep-make 2.6.7. Type 'make print-gnustep-make-help' for help.

<snip>

Making install for tool sogo-slapd-sockd...
Installing tool sogo-slapd-sockd...
Making install for tool sogo-ealarms-notify...
Installing tool sogo-ealarms-notify...
Making install in Tests/Unit ...
Skipping installation of test tools...
[pkguser@server3 SOGo-3.1.4]$ ls -l dest/usr/
total 12
drwxr-xr-x 5 pkguser pkguser 4096 Jul 22 13:13 include
drwxr-xr-x 4 pkguser pkguser 4096 Jul 22 13:13 lib
drwxr-xr-x 2 pkguser pkguser 4096 Jul 22 13:13 sbin
[pkguser@server3 SOGo-3.1.4]$

Same procedure with gnustep-make-2.6.8-1:

[pkguser@server3 sogo]$ makepkg
==> Making package: sogo 3.1.4-1 (Sat Jul 23 13:08:57 CDT 2016)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...

<snip>

==> Leaving fakeroot environment.
==> Finished making: sogo 3.1.4-1 (Sat Jul 23 13:11:31 CDT 2016)
[pkguser@server3 sogo]$ ls -l pkg/sogo/usr/
total 12
drwxr-xr-x 5 pkguser pkguser 4096 Jul 23 13:11 include
drwxr-xr-x 5 pkguser pkguser 4096 Jul 23 13:11 lib
drwxr-xr-x 2 pkguser pkguser 4096 Jul 23 13:11 sbin
[pkguser@server3 sogo]$


After fixing the configuration file shipped with GNUStep-Make-2.6.8:

[pkguser@server3 temp]$ sudo sed 's@/usr/sbin@/usr/bin@' -i.bak /etc/GNUstep/GNUstep.conf
[pkguser@server3 temp]$ diff -u /etc/GNUstep/GNUstep.conf.bak /etc/GNUstep/GNUstep.conf
--- /etc/GNUstep/GNUstep.conf.bak 2016-07-23 14:03:07.487296880 -0500
+++ /etc/GNUstep/GNUstep.conf 2016-07-23 14:03:40.528180445 -0500
@@ -77,7 +77,7 @@
# Administrator can use get installed. Important: this
# should not be in the PATH of normal users.
# Traditionally it is /usr/GNUstep/System/Tools/Admin.
-GNUSTEP_SYSTEM_ADMIN_TOOLS=/usr/sbin
+GNUSTEP_SYSTEM_ADMIN_TOOLS=/usr/bin

# This is where System resources get installed. This directory will
# contain a lot of executable code since *step traditionally likes to
@@ -113,7 +113,7 @@
GNUSTEP_NETWORK_ADMIN_APPS=/usr/lib/GNUstep/Applications
GNUSTEP_NETWORK_WEB_APPS=/usr/lib/GNUstep/WebApplications
GNUSTEP_NETWORK_TOOLS=/usr/bin
-GNUSTEP_NETWORK_ADMIN_TOOLS=/usr/sbin
+GNUSTEP_NETWORK_ADMIN_TOOLS=/usr/bin
GNUSTEP_NETWORK_LIBRARY=/usr/lib/GNUstep
GNUSTEP_NETWORK_HEADERS=/usr/include
GNUSTEP_NETWORK_LIBRARIES=/usr/lib
@@ -125,7 +125,7 @@
GNUSTEP_LOCAL_ADMIN_APPS=/usr/lib/GNUstep/Applications
GNUSTEP_LOCAL_WEB_APPS=/usr/lib/GNUstep/WebApplications
GNUSTEP_LOCAL_TOOLS=/usr/bin
-GNUSTEP_LOCAL_ADMIN_TOOLS=/usr/sbin
+GNUSTEP_LOCAL_ADMIN_TOOLS=/usr/bin
GNUSTEP_LOCAL_LIBRARY=/usr/lib/GNUstep
GNUSTEP_LOCAL_HEADERS=/usr/include
GNUSTEP_LOCAL_LIBRARIES=/usr/lib
[pkguser@server3 temp]$ cd sogo
[pkguser@server3 sogo]$ rm -rf pkg/ src/ sogo-3.1.4-1-x86_64.pkg.tar.xz
[pkguser@server3 sogo]$ makepkg
==> Making package: sogo 3.1.4-1 (Sat Jul 23 14:05:27 CDT 2016)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...

<Snip>

==> Leaving fakeroot environment.
==> Finished making: sogo 3.1.4-1 (Sat Jul 23 14:07:29 CDT 2016)
[pkguser@server3 sogo]$ ls pkg/sogo/usr/
bin include lib
[pkguser@server3 sogo]$ cd src/SOGo-3.1.4
[pkguser@server3 SOGo-3.1.4]$ make DESTDIR=$PWD/dest install
This is gnustep-make 2.6.8. Type 'make print-gnustep-make-help' for help.
Running in gnustep-make version 2 strict mode.

<Snip>

[pkguser@server3 SOGo-3.1.4]$ ls dest/usr/ -l
total 12
drwxr-xr-x 2 pkguser pkguser 4096 Jul 23 14:09 bin
drwxr-xr-x 5 pkguser pkguser 4096 Jul 23 14:09 include
drwxr-xr-x 4 pkguser pkguser 4096 Jul 23 14:09 lib


In short, I don't know why gnustep-make-2.6.7 worked for all this time despite the broken configuration, I'd actually like to understand how it worked (or more appropriately, why it doesn't now), but 2.6.8 has revealed that it was actually broken. The paths should never be /usr/sbin on Arch. Additionally, the GNUStep.conf file should be in the backup array. Not sure if it should be a configuration file or not, as this is the only step project I use. The correct fix is probalby a bit more involved, but this is suitable (at least for my use case):

Thanks.
This task depends upon

Closed by  Sergej Pupykin (sergej)
Friday, 29 July 2016, 17:06 GMT
Reason for closing:  Fixed
Comment by Doug Newgard (Scimmia) - Sunday, 24 July 2016, 06:34 GMT
What, exactly, are you running when you run "make"?
Comment by DJ Lucas (DJ_Lucas) - Sunday, 24 July 2016, 10:23 GMT
Wow, I've only now realized my error in troubleshooting this. I was quite obviously in a hurry. The first line of the description (concerning symlinks) is incorrect and should be ignored. My apologies. Fortunately, the rest still applies (in a slightly different manor). In my original report, I was just showing all three examples, i.e.: that there is a difference between what happens when using makepkg and what happens when doing plain make (for which there shouldn't be). My error in troubleshooting is that GNUSTEP_SYSTEM_ADMIN_TOOLS="/usr/bin" was supplied in the PKGBUILD for the make install line (and I had forgotten about it being there for the Arch version of that PKGBUILD, which led to me incorrectly thinking the problem was fakeroot or symlinks). In short, poor troubleshooting. Thanks for making me look at it again! :-)

That said, while the variable override obviously doesn't work anymore with 2.6.8, and is still a regression from 2.6.7 that should be looked at, it really isn't all that important. The underlying problem is still the same. The configure script is supplied with incorrect configuration when using --with-gnustep because we have the *ADMIN_TOOLS directories set to /usr/sbin (which is a symlink) in the default config. The override never should have been necessary, but has been there since at least 2012 (before I even started using the sogo package). I could just as easily move the files after install and make the PKGBUILD work fine (that was the suggested workaround for the user who reported the problem in the sogo package), but the configure command should have worked by default. Also, the file is a configuration file and should be backed up and not overwritten on upgrade. Luckily, my mess of example output still applies, and the 'fix', while incorrectly derived, is still applicable.

Loading...