discuss-gnustep
[Top][All Lists]
Advanced

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

Re: Debian12 repository.


From: Hugo Melder
Subject: Re: Debian12 repository.
Date: Mon, 30 Oct 2023 08:07:32 +0100


the separation of docs bin dev etc would be nice but I have no clue on how to separate the files except by hand. is there a make install-binary, install-docs etc?

The Debian tooling is quite good at doing this. I based my Debian configuration on the official Debian packages which are quite polished.


Im using "make DESTDIR=tempdir  install" and then run my own script which adds a control file and packages it into a deb file. Straightforward and simple. I never found any easy to use working tools which didn't do another million things you don't know about and often don't work. What I found was mostly outdated stuff.

Yep I agree with you. It took me a long time to figure out how pbuilder, debuild, and the building pipeline works, and it is still not a great experience to use.

That said, I think we should still use it as there are so much nuances one has to consider when manually constructing a deb package.

As far as renaming goes, well the packages in debian are so far outdated and seem no longer maintained that we should try to get a newer version into debian at some point.  But im not sure on how that process works . It might fail due to non support of gcc and maybe some platforms (such as RiscV because even clang fails to install currently). 

The main issue here is ABI breakage, and remaining packages depending on gnustep* where we do not have replacements for.

Are you interested in a quick video conference where I can introduce you to the work I have done with the official Debian tooling? You can also show me your approach :)

Maybe we can work on this together.


--
Andreas

On Sonntag, Okt. 29, 2023 at 9:58 PM, Hugo Melder <admin@hugomelder.com> wrote:
Nice!

A few things to consider:
- Separation of binaries, headers, doc, and debug symbols according to Debian package guidelines
- Renaming of projects to avoid naming-conflicts with the GNUstep packages in the Debian repository
- CI/CD

Are you using the Debian tooling? It would be nice to have support for gui in tools-packaging, which aims to use GitHub actions to automatically build releases, and snapshots.

AOn 29. Oct 2023, at 20:31, Andreas Fink <afink@list.fink.org> wrote:

My repo for debian12  is now ready for testing under amd64 architecture.

You can test it by pasting the two lines as following into your shell


wget http://repo.gnustep.ch/key.asc  --output-file=/etc/apt/trusted.gpg.d/repo.gnustep.ch.asc
echo "deb http://repo.gnustep.ch/debian/ bookworm-alpha gnustep-alpha"  > /etc/apt/sources.list.d/gnustep.ch.list


I call this an alpha release
Once all remaining little things are ironed out, it will go into "gnustep" instead of "gnustep-alpha"

the following packages have been built

gnustep-base-1.29.0_amd64.deb
gnustep-corebase-0.2.1_amd64.deb
gnustep-make-2.9.1_amd64.deb
libdispatch-5.10.0_amd64.deb
libiconv-1.17.0_amd64.deb
libobjc2-2.1.0_amd64.deb
gnustep-back-0.30.0_amd64.deb
gnustep-gui-0.30.0_amd64.deb

Feel free to test and report any issues.

Issues I have already found:

 warnings appear in the current gnustep-base because the definition of methods is twice in the header file
removing one of them (they are the same) gets rid of the warning

/usr/include/GNUstep/Foundation/NSRegularExpression.h:120:1: warning: multiple declarations of method 'initWithPattern:options:error:' found and ignored [-Wduplicate-method-match]
- (id) initWithPattern: (NSString*)aPattern
^
/usr/include/GNUstep/Foundation/NSRegularExpression.h:114:1: note: previous declaration is here
- (id) initWithPattern: (NSString*)aPattern


/usr/include/GNUstep/Foundation/NSIndexPath.h:101:1: warning: multiple declarations of method 'item' found and ignored [-Wduplicate-method-match]
- (NSInteger) item;
^
/usr/include/GNUstep/Foundation/NSIndexPath.h:84:1: note: previous declaration is here
- (NSInteger) item;
^


also gnustep-core test is failing in the area of date & time which has something to do with the language settings.


CFDateFormatter/basic.m:
Failed test:     basic.m:38 ... Default format for de_DE locale is EEEE, d. MMMM y HH:mm but got EEEE, d. MMMM y 'um' HH:mm

in german you can say on "31.12.2023 at 23:59" where the german "um" is "at" in english.
But  "31.12.2023 23:59" is also correct. just a shorter form. I prefer the later but I'm not 100% sure what the "correct" way would be if you want to be 1:1 compatible to how MacOS does it.

Failed test:     basic.m:42 ... Absolute time can be formatted using full date style.
Failed test:     basic.m:57 ... Absolute time can be formatted using no date style.
Failed test:     basic.m:63 ... Absolute time gotten for 20050403 02:01 vorm.

this is a bit odd. "vorm." means vormittag (before noon). like "AM" . However german uses 24h date and time so nobody would write 08:00 vorm or 07:00 nachm. because 08:00 and 19:00 would be the correct way in german.

Failed test:     basic.m:65 ... Absolute time for 20050403 02:01 vorm. is 315612000.000000

this is probably related the other way around


CFLocale/bridge.m:
Failed file:     bridge.m aborted without running all tests!

CFLocale/create.m:
Failed test:     create.m:20 ... en_ES_PREEURO is stored as es_ES@currency=ESP

no idea what a PREEURO is ;-)
spanish Pesetas?

--- Running tests in CFNumber ---

CFNumber/bridge.m:
Failed file:     bridge.m aborted without running all tests!
--- Running tests in CFNumberFormatter ---

CFNumberFormatter/format.m:
Failed test:     format.m:32 ... SInt8 formatted correctly
--- Running tests in CFPropertyList ---

CFPropertyList/openstep.m:
Failed test:     openstep.m:61 ... OpenStep property list read correctly.


On 29 Oct 2023, at 11:42, Hugo Melder <admin@hugomelder.com> wrote:



On 29. Oct 2023, at 11:25, Andreas Fink <afink@list.fink.org> wrote:

Hello all

I'm working on setting up a debian repository wtih a up to date build of debian12 and ubuntu22 for amd64 and arm64 architectures.
My current repo installs all on /usr/local/ but for proper system wide use /usr should be used as prefix instead.

so I use

export PREFIX="/usr"

cmake ... -DCMAKE_INSTALL_PREFIX=${PREFIX} ...


and 

./configure --prefix=${PREFIX}

Is this for gnustep-base or gnustep-make?
Only configuring gnustep-make correctly is enough:

dh_auto_configure -- \
   --with-layout=debian \
--enable-native-objc-exceptions \
  --enable-objc-arc \
--prefix=/usr \
  --with-runtime-abi=gnustep-2.0 \
  --with-library-combo=ng-gnu-gnu \
  LDFLAGS="-fuse-ld=lld -L/usr/lib/$(DEB_HOST_MULTIARCH)" SHELLPROG=/bin/bash GNUMAKE=make


https://github.com/gnustep/tools-packaging is our repo for aggregating the new GNUstep 2.0 Debian package configuration files and build scripts.
This is currently only non-gui, but I am open to contributions :)

This draft (https://github.com/gnustep/tools-packaging/pull/4) adds automatic building in phases using the isolated pbuilder build tool.




reply via email to

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