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 shellwget http://repo.gnustep.ch/key.asc --output-file=/etc/apt/trusted.gpg.d/repo.gnustep.ch.ascecho "deb http://repo.gnustep.ch/debian/ bookworm-alpha gnustep-alpha" > /etc/apt/sources.list.d/gnustep.ch.listI call this an alpha releaseOnce all remaining little things are ironed out, it will go into "gnustep" instead of "gnustep-alpha"the following packages have been builtgnustep-base-1.29.0_amd64.debgnustep-corebase-0.2.1_amd64.debgnustep-make-2.9.1_amd64.deblibdispatch-5.10.0_amd64.deblibiconv-1.17.0_amd64.deblibobjc2-2.1.0_amd64.debgnustep-back-0.30.0_amd64.debgnustep-gui-0.30.0_amd64.debFeel 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 fileremoving 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:mmin 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.000000this is probably related the other way aroundCFLocale/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=ESPno 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 allI'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 useexport 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=makehttps://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.