Re: NeXT GNU Homage Project Work

[Ivan Vučica]

On Tue, Nov 17, 2015 at 8:05 PM, H. Nikolaus Schaller <hns@goldelico.com> wrote:

Am 17.11.2015 um 18:48 schrieb Liam Proven <lproven@gmail.com>:

> While it is a good thing that there are OSes that have a working
> current version of the GNUstep environment, I submit that,
> increasingly, Linux means the Debian family, and for most people,
> specifically Ubuntu. It is the easiest to install, the easiest to
> update, the most rich and complete and widely-supported free OS that
> exists.
>
> *That* is what should be the #1 priority to support well with GNUstep.
>
> The answer to the problem "I can't install GNUstep on Ubuntu or
> Debian" is _not_ "install FreeBSD instead". It's not "install
> $ANY_OTHER_OS".
>
> It's to have current, working packages for Debian and to get them
> included in the Debian OS so that they are also available to
> downstream projects such as Ubuntu.

Here I would even prioritize:
#1 is have up-to-date and working Debian packages repo (with
cross-compiled arm-linux-armhf and arm-linux-i86) on gnustep.org
so that a simple /etc/apt/sources.list entry suffices.

Then installation instructions could be very simple: set up Debian on
some machine, add a line to /e/a/s.l and apt-get update + apt-get install gnustep.
It should also be easy to provide the headers and source file packages to natively
compile on some Debian machine.

I'm on-and-off working on this. If I gave up on compiling with clang and libobjc2, I would have this running. Alternatively, if I gave up on providing correct source packages, I would be done with this.

I have a process for building working binary packages, inside docker containers.

I have a process for building source and binary packages for things other than libobjc2, outside docker containers.

This is available in https://bitbucket.org/ivucica/gnustep-ubuntu/

Output of the gcc-compiled, gcc-runtime-based process from May 2014, built on Canonical's server farm:

https://launchpad.net/~ivucica/+archive/ubuntu/gnustep

Attempt at building libobjc2 on Canonical's server farm from November 2015:

https://launchpad.net/~ivucica/+archive/ubuntu/throwaway-20151115-2

I hope to work on the build process more this weekend. I believe it's a matter of:

- listing all the build-deps for libobjc2 https://bitbucket.org/ivucica/gnustep-ubuntu/src/3e85ac1f61/phases/16-pack-libobjc2.sh#16-pack-libobjc2.sh-70

- be completely sure that the build process for libobjc2 uses clang (it seems like it will: https://launchpadlibrarian.net/226602228/buildlog_ubuntu-trusty-amd64.libobjc2_1.7.0-1~git1444655167_BUILDING.txt.gz)

>
> I'm not saying Ubuntu is perfect. It's not. But it's the leading
> distro, it offers all the major desktops, it has official remixes with
> Unity, KDE, GNOME 3, Maté, Xfce and LXDE, and it does have (horribly
> outdated) GNUstep packages in its repos.

A very old wish is that similarly to "apt-get install lxde" or  "apt-get install xfce4" it
should be as simple as "apt-get install gnustep" to get a fully (pre)configured desktop.

This is the end-goal of my efforts: provide Debian packages (including source packages) which will deploy a pre-configured, usable session onto your machine. Then, use these packages to remaster a live CD.

Current non-goal: upstreaming packages into Debian and Ubuntu. The packages are prepared by an automated process that does not maintain changelogs. They also don't seem to be prepared according to the method Debian developers usually do it. (Namely: automation is, by design, rebuilding the debian/ folder; instead I should be treating it as something version-controlled.)

Another current non-goal: building for anything other than i386/amd64. I don't see a reason why it wouldn't build, but things are going slowly as-is.

A quick reminder:

- these days, gnustep-make knows how to package itself into a Debian package

- these days, gnustep-make knows how to package other software (including gnustep-base, gnustep-gui, gnustep-back and various applications) into a Debian package

The main thing that's preventing me from regularly releasing packages is -- I want to automate this, and I want to automate this right.