discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Debian and Ubuntu packages - 2015/06/03


From: Alessandro Sangiuliano
Subject: Re: Debian and Ubuntu packages - 2015/06/03
Date: Wed, 8 Jul 2015 11:22:37 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0

Thanks Ivan!

Il 07/07/2015 18:53, Ivan Vučica ha scritto:
On Thu, Jun 4, 2015 at 12:48 PM, Philippe Roussel <address@hidden> wrote:
On Thu, Jun 04, 2015 at 11:15:41AM +0000, Ivan Vučica wrote:
>
> The build currently breaks within gnustep-base. I have a patch from
> November for Source/Additions/GSObjCRuntime.m and Source/NSException.m, but
> it's hacky. Plus, I fear touching such low-level files. I'll eventually
> send this out for review, after I go once more through it, and after I
> rebase the patch on latest -base.

On recent distributions I had to remove the objc/ include folder
coming from gcc for gnustep-base to compile otherwise it correctly
found libobjc2 but used gcc's libobjc headers. I guess something could
be done on gnustep-base makefile but I didn't take the time to check.

I've now hacked a fake package, clangy-libobjc, that removes GCC's libobjc by conflicting with it, and 'providing' it.
  https://bitbucket.org/ivucica/gnustep-ubuntu/commits/a3c848edd2f4f82c976488d99f383418b743487f?at=default
  latest version: https://bitbucket.org/ivucica/gnustep-ubuntu/src/52ae6eb10f06d445b71bc7df9db04717293999cd/docker/build.sh?at=default

This got the build process rolling. :-)
 
ps : nice work on your build system

It's still unfinished, but now the Docker-based build actually works \o/

You end up with a clang-built, libobjc2-using gnustep-make and gnustep-base .deb packages.

Remaining issues:
- It's still using libobjc2 from GNUstep's Subversion repository, and not the one in David's repository on Github, but you do end up with Debian packages. (I think that means it's out of date, but I didn't get around to fixing this.)
- Some steps execute at the wrong time. For example, fake package that gets rid of GCC's libobjc should not be built every time your 'docker run' a build. And not all package installation preparatory steps are run early; they are not properly split out of the 'main' gnustep-ubuntu scripts so they cannot run separately.
- Some steps are only necessary due to bugs in Docker or Ubuntu. (e.g. rebuilding pam)
- .deb for David's libobjc should be the one claiming the conflict with GCC's libobjc. (I'll have to dig into cmake to get that to happen.)
- Some packages are built only as binary packages: these are clangy-libobjc and libobjc. This means this approach is *not* useful for uploading to an Ubuntu PPA. (What will probably happen is that I'll try to hack together an alternative process that uses GCC and GCC's libobjc, and not clang.)
- You can't specify your GPG key. One of the preparatory steps involves generating a one-day-expiry, low-bitcount throwaway GPG key.
- Sadly, I'm too unfamiliar with Docker, so I didn't get 'bind mounting' to work. This means you don't get .debs nor source packages put into a neat folder on your host machine; you have to dig into the container to get them out.

Good news is: I've copied libobjc, gnustep-make and gnustep-base packages to host machine, installed them, and then compiled gnustep-gui on the host machine.

So building .debs should come down to:
- checkout the mercurial repo
- enter docker/ folder inside the repo
- sudo ./docker-produce.sh
- sudo ./run-build.sh every time you want to produce a build
- once done, optionally delete the docker container (list with: docker ps --all, remove with: docker rm <container_name>)
- once done, optionally delete the docker images (list with: docker images, remove with: docker rmi <image_name>)

Those who want to try, https://bitbucket.org/ivucica/gnustep-ubuntu


_______________________________________________
Discuss-gnustep mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnustep


reply via email to

[Prev in Thread] Current Thread [Next in Thread]