This reverts commit 86caec1be1.
In this commit tests were re-enabled, but without correctly testing whether it could.
When a package builds it doesn't mean the tests are actually run. This is often seen when it says that 0 tests were run.
Typically this is because the test runner was invoked incorrectly.
By re-enabling the tests, a false impression is generated that the package is tested while in fact it isn't. Furthermore, the Python 3.5
package broke because the tests are invoked incorrectly.
cc @abbradar
This should make merge conflicts easier to
handle. "gnustep" prefix has been removed to
make thing simpler. So "gnustep_make" is now
"make" within the gnustep scope.
Packaging some basic GNUstep apps: GWorkspace and SystemPreferences.
Unfortunately, GWorkspace doesn't work well, because gdomap, gdnc, gpbs
are not started. Also, there is some issue with fonts not being found.
Cleaning up. Adding GNUstep package builder for abstracting out GNUstep
compilation specifics (with thanks to GitHub user lethalman).
The rules for using build_gnustep_package are as simple: any
GNUstep-based package that the package being compiled depends upon are
to be put in [deps] (this is used for setting up a buildEnv), while
other dependencies are put into [buildInputs] as usual.
Removing gnustep-startup (not needed anymore). Adding Gorm and
ProjectCenter applications (these mostly work, provided the environment
is set up manually).
Packing gnustep libs separately, with no use of gnustep-startup. Also,
fixed a bug in WindowMaker package (some imaging dependencies were not supplied).
Adding new library: gnustep-startup, which packages the core
libraries necessary for GNUstep: gnustep-make, gnustep-base,
gnustep-gui, gnustep-backend.
See #11567.
Furthermore, it renames pythonPackages.dbus to pythonPackages.dbus-
python as that's the name upstream uses.
There is a small rebuild but I couldn't figure out the actual cause.
