Open Strahinja opened 10 months ago
Alpine Linux is based on the musl library and GNUstep has not been tested much on that. it seems that there a big differences. As for this specific issue with NSCalendar it depends on whether your system provides libICU and if so in which version. If you want to improve support for musl based system this is great. We are ready to accept patches.
I have the package icu-73.2-r2
and the related -dev
, -data-full
and -libs
packages with the same version.
If you want to improve support for musl based system this is great. We are ready to accept patches.
Although I am not experienced with Objective-C, like I said, I will see what I can do and report my progress here. I would very much like to see Alpine support GNUstep.
By the way, I have observed that Void Linux (which has musl as an option) seems to use GCC instead of Clang.
Update: The file Headers/GNUstepBase/GSConfig.h has #define GS_USE_ICU 1
.
Update 2: I have inserted a NSLog
line to the dateFromString
method in Source/NSDateFormatter.m:
date = udat_parse (internal->_formatter, text, textLength, &pPos, &err);
NSLog(@"err = (%d)", err);
if (U_SUCCESS(err))
result =
[NSDate dateWithTimeIntervalSince1970: (NSTimeInterval)(date / 1000.0)];
which gives in the file Tests/tests.log:
2023-12-03 18:01:05.228 era[22392:22392] err = (9)
The number 9 is associated with U_PARSE_ERROR
in ICU.
Update 3: It appears that the locale setting is to blame for failed NSCalendar
tests. When I export LC_ALL=C
, all of the NSCalendar
tests pass. I believe this could be due to the NSCalendar
test testing the date parsing using the date in English, while using a non-English locale (in this case, Serbian, sr_RS.UTF-8
):
date = [dateFormatter dateFromString:@"22 Nov 1969 08:15:00 Z"];
Update 4: Calling setlocale(LC_ALL, "C")
doesn't seem to help here. The only way I can get NSCalendar
tests to succeed is to set LC_ALL
override externally, ie. to call make check
like this:
$ LC_ALL=C make check
With https://github.com/gnustep/libs-base/pull/357 applied (and the resultant libs-base
installed), the make check
results are:
8276 Passed tests
1354 Failed tests
36 Dashed hopes
1 Skipped set
1 Failed file
Update/note: As a follow up on the Void Linux using GCC/vanilla libobjc instead of Clang/libobjc2, I tried recompiling under stock gcc-objc
, libobjc
and g++
. The results:
9563 Passed tests
46 Dashed hopes
16 Skipped sets
1 Failed file
(the failed file is the same as for Clang/libobjc2, base/NSStream/socket.m). What's kind of important is that libs-gui
fails to compile even with that combo (GCC/vanilla libobjc), in the same manner as Clang/libobjc2: linker for some reason fails to link libobjc, even with -lobjc near the end of the command line:
gcc -shared-libgcc -pthread -fexceptions -rdynamic -o GSspell.service/./GSspell \
./obj/GSspell.obj/GSspell.m.o -L../Source/./obj -L../Model/./obj -L/home/strajder/GNUstep/Library/Libraries -L/usr/local/lib -L/usr/lib -licui18n -licuuc -licudata -L/usr/lib -lpng16 -lgnustep-gui -lpng -ltiff -lz -ljpeg -lm -lgnustep-base -lobjc -lm
/usr/lib/gcc/x86_64-alpine-linux-musl/12.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: ../Source/./obj/libgnustep-gui.so: undefined reference to `__gnustep_objc_personality_v0'
/usr/lib/gcc/x86_64-alpine-linux-musl/12.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: ../Source/./obj/libgnustep-gui.so: undefined reference to `__objc_ivar_offset_NSGraphicsContext.methods'
/usr/lib/gcc/x86_64-alpine-linux-musl/12.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: ../Source/./obj/libgnustep-gui.so: undefined reference to `__objc_ivar_offset_NSView._window'
etc.
Next failing test is from NSURL
:
Failed test: (2023-12-03 19:05:24.886 +0100) test00.m:102 ... NSURLConnection synchronous load returns a response
Update: Before that,
Running base/NSStream/socket.m...
[...]
2023-12-03 19:35:34.850 socket[32113:32113] Got 2 on 0x7fe45db7be28
2023-12-03 19:35:34.850 socket[32113:32113] Got 16 on 0x7fe45db7be28
2023-12-03 19:35:34.850 socket[32113:32113] Close 0x7fe45db7be28
/usr/local/bin/gnustep-tests: line 405: 32113 Грешка сегментације ( . ./TestInfo > /dev/null 2>&1; $RUN_CMD )
Failed file: socket.m aborted without running all tests!
Where "Грешка сегментације" means "Segmentation fault". Full tests.log attached.
@Strahinja just for your information, I do run GNUstep on Alpine Linux. I fixed support for its musl platform in make some time ago. Best is that you use all compiled from source, use the gcc runtime and see if you replicate my environment. Later we can check if and how Alpine provides its packages. I need to disable iconv for building base, I have issues having it recognized, even if installed. This is not fatal though. Be sure to install GNU tar, we are not compatible with BusyBox options: base installs, gui not without it.
However, I am unable to run test on this 3.18 laptop. I have another run and will report back.
test: base/GSMime: unknown operand
--- Running tests in base/Functions ---
/System/Tools/gnustep-tests: line 744: declare: not found
/System/Tools/gnustep-tests: line 749: TESTMAP[NSByteSwapping]=NSByteSwapping.m: not found
/System/Tools/gnustep-tests: line 749: TESTMAP[NSGeometry1]=NSGeometry1.m: not found
test: =: argument expected
I have a laptop with 3.17 Alpine and which was not updated since a while and there whole gnustep, including GUI work and GUi app runs. I remember having fixed things well enough.
First, I update whole gnustep but not Alpine..I will report back.
However, I am unable to run test on this 3.18 laptop. I have another run and will report back.
test: base/GSMime: unknown operand --- Running tests in base/Functions --- /System/Tools/gnustep-tests: line 744: declare: not found /System/Tools/gnustep-tests: line 749: TESTMAP[NSByteSwapping]=NSByteSwapping.m: not found
I recompiled everything using GCC/vanilla libobjc, and your advice (--disable-iconv
for libs-base
, also I already use GNU tar) and everything seems to run fine (except Gorm, more about that below). Possibly important is that I have mksh, compiled from source, set as my interactive shell. Also:
$ apk list -I | grep -E '(objc|^g\+\+)'
g++-13.2.1_git20231014-r0 x86_64 {gcc} (GPL-2.0-or-later AND LGPL-2.1-or-later) [installed]
gcc-objc-13.2.1_git20231014-r0 x86_64 {gcc} (GPL-2.0-or-later AND LGPL-2.1-or-later) [installed]
libobjc-13.2.1_git20231014-r0 x86_64 {gcc} (GPL-2.0-or-later AND LGPL-2.1-or-later) [installed]
With that, I was able to run gnustep-tests:
$ GNUSTEP_MAKEFILES=/usr/local/share/GNUstep/Makefiles gnustep-tests Tests
The resulting tests.log is attached. I haven't applied here my fix for localized date tests, so those tests fail too. What is surprising to me is that there are more failing tests, in contrast to the previous results.
The build system seems so fragile with all the numerous ways to set up the build environment. For example, on my other machine I use umask 027, and it messes with the installation process. /rant
I was, however, able to compile, install and run apps-gworkspace
, apps-projectcenter
and gap
(most of the apps seem to work fine). Question: is the preferences window in Terminal supposed to have images in the top toolbar?
About Gorm, it compiles and installs fine, but when I run
$ Gorm
Error relocating /usr/local/lib/libGormCore.so.0: IBSelectionChangedNotification: symbol not found
Error relocating /usr/local/lib/libGormCore.so.0: IBWillCloseDocumentNotification: symbol not found
Error relocating /usr/local/lib/libGormCore.so.0: IBWillBeginTestingInterfaceNotification: symbol not found
Error relocating /usr/local/lib/libGormCore.so.0: IBDidBeginTestingInterfaceNotification: symbol not found
Error relocating /usr/local/lib/libGormCore.so.0: IBWillEndTestingInterfaceNotification: symbol not found
Error relocating /usr/local/lib/libGormCore.so.0: IBDidEndTestingInterfaceNotification: symbol not found
Error relocating /usr/local/lib/libGormCore.so.0: IBInspectorDidModifyObjectNotification: symbol not found
Error relocating /usr/local/lib/libGormCore.so.0: __objc_class_name_IBInspector: symbol not found
Error relocating /usr/local/lib/libGormCore.so.0: __objc_class_name_IBInspector: symbol not found
Error relocating /usr/local/lib/libGormCore.so.0: __objc_class_name_IBInspector: symbol not found
Error relocating /usr/local/lib/libGormCore.so.0: __objc_class_name_IBInspector: symbol not found
Error relocating /usr/local/lib/libGormCore.so.0: __objc_class_name_IBInspector: symbol not found
Error relocating /usr/local/lib/libGormCore.so.0: __objc_class_name_IBInspector: symbol not found
Error relocating /usr/local/lib/libGormCore.so.0: __objc_class_name_IBInspector: symbol not found
Error relocating /usr/local/lib/libGormCore.so.0: __objc_class_name_IBInspector: symbol not found
Error relocating /usr/local/lib/libGormCore.so.0: __objc_class_name_IBInspector: symbol not found
Error relocating /usr/local/lib/libGormCore.so.0: __objc_class_name_IBInspector: symbol not found
Error relocating /usr/local/lib/libGormCore.so.0: __objc_class_name_IBInspector: symbol not found
and so on.
Update:
$ cd /usr/local/lib
$ ls -l libGorm*
lrwxrwxrwx 1 root root 71 Dec 6 06:33 libGormCore.so -> ./GNUstep/Frameworks/GormCore.framework/Versions/Current/libGormCore.so
lrwxrwxrwx 1 root root 67 Dec 6 06:33 libGormCore.so.0 -> ./GNUstep/Frameworks/GormCore.framework/Versions/0/libGormCore.so.0
lrwxrwxrwx 1 root root 71 Dec 6 06:33 libGormCore.so.0.0.1 -> ./GNUstep/Frameworks/GormCore.framework/Versions/0/libGormCore.so.0.0.1
lrwxrwxrwx 1 root root 28 Dec 6 06:33 libGormObjCHeaderParser.so -> libGormObjCHeaderParser.so.0
lrwxrwxrwx 1 root root 32 Dec 6 06:33 libGormObjCHeaderParser.so.0 -> libGormObjCHeaderParser.so.0.0.1
-rwxr-xr-x 1 strajder strajder 149432 Dec 6 06:32 libGormObjCHeaderParser.so.0.0.1
It seems that libGormObjCHeaderParser.so.0.0.1 is installed with the incorrect ownership (regular user!). Other libraries seem installed like that as well, for example libgnustep-base.so.1.29.0, libgnustep-gui.so.0.30.0, libInterfaceBuilder.so.1.1.0 etc. So I did
# cd /usr/local
# chown -R root:root .
still, libGormCore.so.0.0.1 is the only one with relocation problems.
Suggestion: Perhaps use the standard utility install to install files with the correct ownership and permissions?
Terminal does not have images in its preference bar. So it is fine as you see it.
on 3.18 Alpine, I stop at the build of gui with mysterious shell errors. If a library is installed with your user permissions and run things as user, it shouldn't be a cause of problems (although, generally, it is an issue). I don't know which install we use, maybe again GS supposes some standard install vs. busy box install.
I'll try to set up a "clean", default Alpine environment in an emulator and check if there any Busybox-related issues not present on my mksh-using system later. I'll report what I find out here.
Using GCC/vanilla libobjc (packages gcc-objc
, libobjc
and g++
) in a freshly installed Alpine Linux v3.18 system (activated repositories: v3.18/main
, v3.18/community
, edge/testing
), I managed to build and install, in order:
tools-make
libs-base
libs-gui
libs-back
apps-gorm
apps-gworkspace
gap
My observations:
Libraries and executables are installed with the regular user as owner. When I used the command
$ doas make messages=yes >make-gorm.log 2>&1
I noticed things like:
Making install for framework GormCore...
(cd .; \
tar cfX - /usr/local/share/GNUstep/Makefiles/tar-exclude-list \
GormCore.framework) \
| (cd /usr/local/lib/GNUstep/Frameworks; tar xf -)
(using tar to install files?!)
Then, all the install commands are using arguments similar to:
/usr/bin/install -c -p -m 644 GormViewEditor.h GormCore.framework/Versions/0/Headers/GormViewEditor.h
this command doesn't set ownership. When I use a command like:
$ touch test.file
$ doas /usr/bin/install -c -p -m 644 test.file /usr/include/test.file
$ ls -l /usr/include/test.file
-rw-r--r-- 1 strajder strajder 0 Dec 6 19:11 /usr/include/test.file
whereas the following explicit form works:
$ doas /usr/bin/install -c -p -m 644 -o root -g root test.file /usr/include/test.file
$ ls -l /usr/include/test.file
-rw-r--r-- 1 root root 0 Dec 6 19:11 /usr/include/test.file
so the fix for the incorrect ownership set by GNUstep make would be to add -o root
and -g root
to all invocations of install.
On 6 Dec 2023, at 18:27, Страхиња Радић @.***> wrote:
I noticed things like: Making install for framework GormCore... (cd .; \ tar cfX - /usr/local/share/GNUstep/Makefiles/tar-exclude-list \ GormCore.framework) \ | (cd /usr/local/lib/GNUstep/Frameworks; tar xf -)
(using tar to install files?!) Then, all the install commands are using arguments similar to: /usr/bin/install -c -p -m 644 GormViewEditor.h GormCore.framework/Versions/0/Headers/GormViewEditor.h
this command doesn't set ownership. When I use a command like: $ touch test.file $ doas /usr/bin/install -c -p -m 644 test.file /usr/include/test.file $ ls -l /usr/include/test.file -rw-r--r-- 1 strajder strajder 0 Dec 6 19:11 /usr/include/test.file
whereas the following explicit form works: $ doas /usr/bin/install -c -p -m 644 -o root -g root test.file /usr/include/test.file $ ls -l /usr/include/test.file -rw-r--r-- 1 root root 0 Dec 6 19:11 /usr/include/test.file
so the fix for the incorrect ownership set by GNUstep make would be to add -o root and -g root to all invocations of install.
There's no fix, because there's nothing wrong: the correct owner to install stuff as (when doing a build from source) is normally the user doing the installing. When you build and install from source you are normally building a private/personal copy of the system, which is quite different from installing a package.
That being said, gnustep-make does support installing as a non-standard user/group ...
When you want to install stuff as a different user, you can specify the user by defining INSTALL_AS_USER=xxx before running make. If you are doing that, you would usually also want to define INSTALL_AS_GROUP=xxx to install with a non-standard group too.
NB. The INSTALL_AS_USER and INSTALL_AS_GROUP settings may also be used inside a make file. That's for cases where you (as developer of some software) know that you want to have it installed as a particular user, or where you want to set a default user to have it installed as.
There's no fix, because there's nothing wrong: the correct owner to install stuff as (when doing a build from source) is normally the user doing the installing.
Perhaps it is semantics. To be precise, on Busybox systems using OpenDoas the installation of programs compiled from source, by GNUstep make, isn't applying correct ownership - that's unexpected/undesired. From the above simple test I made, it seems that, in contrast with GNU install and/or sudo, with Busybox' install and/or OpenDoas that isn't the case: the user and group aren't changed.
When you want to install stuff as a different user, you can specify the user by defining INSTALL_AS_USER=xxx before running make. If you are doing that, you would usually also want to define INSTALL_AS_GROUP=xxx to install with a non-standard group too.
Than that is the fix for the above unexpected behavior. Thanks.
We have something interesting here between A.pine 3.17 and Alpine 3.18. I have two laptops with 3.17. Both build and install fine up to standard user applications, including Gorm, which runs fine.
As an example, my R40 has:
make:
./configure --with-layout=gnustep --prefix=/GNUstep
base:
./configure --with-libiconv-include=/usr/include/gnu-libiconv
after I have installed:
I can't run tests because of these errors:
test: base/GSMime: unknown operand
--- Running tests in base/Functions ---
/GNUstep/System/Tools/gnustep-tests: line 744: declare: not found
/GNUstep/System/Tools/gnustep-tests: line 749: TESTMAP[NSByteSwapping]=NSByteSwapping.m: not found
/GNUstep/System/Tools/gnustep-tests: line 749: TESTMAP[NSGeometry1]=NSGeometry1.m: not found
test: =: argument expected
/GNUstep/System/Tools/gnustep-tests: line 749: TESTMAP[NSPathUtilities]=NSPathUtilities.m: not found
test: NSGeometry1: unknown operand
/GNUstep/System/Tools/gnustep-tests: line 749: TESTMAP[NSZone]=NSZone.m: not found
test: NSGeometry1: unknown operand
/GNUstep/System/Tools/gnustep-tests: line 749: TESTMAP[class_hierarchy]=class_hierarchy.m: not found
test: NSGeometry1: unknown operand
/GNUstep/System/Tools/gnustep-tests: line 749: TESTMAP[clsCreate]=clsCreate.m: not found
test: NSGeometry1: unknown operand
/GNUstep/System/Tools/gnustep-tests: line 749: TESTMAP[runtime]=runtime.m: not found
test: NSGeometry1: unknown operand
/GNUstep/System/Tools/gnustep-tests: line 876: syntax error: bad substitution
make[1]: *** [GNUmakefile:64: check] Error 2
test: base/GSMime: unknown operand --- Running tests in base/Functions --- /GNUstep/System/Tools/gnustep-tests: line 744: declare: not found /GNUstep/System/Tools/gnustep-tests: line 749: TESTMAP[NSByteSwapping]=NSByteSwapping.m: not found
Yes, this happens because the gnustep-tests script is assuming GNU Bash (thus Bash should be mentioned as a hard requirement, at least for using those scripts, unless the scripts are rewritten to support other shells - POSIX sh compatibility should be sufficient). The shebang is #!/bin/bash
, and, for example, the declare
builtin is not POSIX. As a result, Busybox ash (the default shell in Alpine) cannot interpret the script. Can you do
# apk add bash
and check again if it works?
# apk add bash
and check again if it works?
I just checked on 3.18, I have bash installed, /bin/bash exists, yet I can't run make check.
Update on 3.18 status, compared to my previous attempts, I am able to compile base, gui and back. No longer strange issues.
I cannot run tests as on 3.17.
However I am unable to run GUI apps, I get this issue:
2023-12-11 16:21:40.917 Ink[22440:22440] NSApplication.m:316 Assertion failed in initialize_gnustep_backend. Can't load object file from backend at path /System/Library/Bundles/libgnustep-back-030.bundle Ink: Uncaught exception NSInternalInconsistencyException, reason: NSApplication.m:316 Assertion failed in initialize_gnustep_backend. Can't load object file from backend at path /System/Library/Bundles/libgnustep-back-030.bundle
I just checked on 3.18, I have bash installed, /bin/bash exists, yet I can't run make check.
This sounds as if the script is somehow (alias? Makefile?) forcibly run through non-Bash shell. For example:
$ ash
$ cat <<! >test.bash
#!/bin/bash
declare -A arr
!
$ chmod 755 test.bash
$ ./test.bash
$ bash test.bash
$ ash test.bash
test.bash: 2: declare: not found
$ sh test.bash
test.bash: 2: declare: not found
Or, Bash might silently accept non-POSIX functionality if /bin/sh is a link to /bin/bash, and the build system is relying on that nonstandard behavior.
If the script is already assuming Bash, it might be better to replace the (hypothetical) sh gnustep-tests
with bash gnustep-tests
, if not just a simple path_to_script/gnustep-tests
.
On 11 Dec 2023, at 16:22, Riccardo @.***> wrote:
apk add bash
and check again if it works? I just checked on 3.18, I have bash installed, /bin/bash exists, yet I can't run make check. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>
I think this may be a bug in the gnustep-make configure script. It looks like it tries to find bash, but falls back to /bin/sh Please try reconfiguring/reinstalling gnustep-make now that you have bash installed. If that fixes it, we can figure out how best to fix the configure script to abort or to warn if bash is not found.
I think this may be a bug in the gnustep-make configure script. It looks like it tries to find bash, but falls back to /bin/sh Please try reconfiguring/reinstalling gnustep-make now that you have bash installed. If that fixes it, we can figure out how best to fix the configure script to abort or to warn if bash is not found.
You are right, I had to be more convincing when configuring... Did a clean configure, installed and it worked. I will retry on 3.17 too.
Now tests results are:
9564 Passed tests 52 Dashed hopes 16 Skipped sets 4 Failed tests
base/NSDateFormatter/general.m:
Failed test: (2023-12-11 16:58:08.152 +0000) general.m:65 ... Output has the same format as Cocoa.
base/NSNumberFormatter/basic10_4.m: Failed test: (2023-12-11 17:00:26.788 +0000) basic10_4.m:158 ... positive prefix is set correctly for currency style Failed test: (2023-12-11 17:00:26.788 +0000) basic10_4.m:162 ... prefix and suffix used properly Failed test: (2023-12-11 17:00:26.789 +0000) basic10_4.m:167 ... negativeFormat used for -ve number
Now tests results are:
9564 Passed tests 52 Dashed hopes 16 Skipped sets 4 Failed tests
base/NSDateFormatter/general.m: Failed test: (2023-12-11 16:58:08.152 +0000) general.m:65 ... Output has the same format as Cocoa.base/NSNumberFormatter/basic10_4.m: Failed test: (2023-12-11 17:00:26.788 +0000) basic10_4.m:158 ... positive prefix is set correctly for currency style Failed test: (2023-12-11 17:00:26.788 +0000) basic10_4.m:162 ... prefix and suffix used properly Failed test: (2023-12-11 17:00:26.789 +0000) basic10_4.m:167 ... negativeFormat used for -ve number
This might have a similar cause to the bug with formatting dates: the tests are expecting English locale settings, while not explicitly setting English locale, and are done with the non-English locale settings in the environment. Can you try rerunning tests after setting LANG
/LC_ALL
to en_US
?
This might have a similar cause to the bug with formatting dates: the tests are expecting English locale settings, while not explicitly setting English locale, and are done with the non-English locale settings in the environment. Can you try rerunning tests after setting
LANG
/LC_ALL
toen_US
?
I have LANG set to C.UTF-8 and LC_ALL empty. I set LANG to en_US as you suggest and rerun tests, but I get the same 4 failures.
with Richard yesterday we worked on a check for bash - it is non-requiredso non-developers can continue without. However on run of a test an explicative error is shown. The test-suite has a hard-requirement on bash.
I am able to build and run apps on Apline 3.18. Thus I took the time to upgrade one of my two 3.17 systems to 3.18, rebuilt gnustep and all runs fine, including backend, I was missing libXmu dev files and due to internal headers, this causes some strange things in back. Solved.
So the core of the original point remains: some tests failing for locale and similar.
@rmottola I found out what is most likely executing /bin/sh - it is make itself. The GNU make documentation states that if the shell is not set in the variable SHELL
, it defaults to /bin/sh. So it would be worth trying to explicitly set SHELL=/bin/bash
in the GNUmakefile itself.
To summarize, there are multiple issues (I'm not sure if I should open separate "issues" here on Github for them). I think that this particular Bash-related issue happens when /bin/sh is not a link to /bin/bash. (At least it seems to on your system, I haven't experienced it myself. In the freshly installed Alpine 3.18 in the emulator, with installed GNU Bash in /bin/bash and /bin/sh being a link to /bin/busybox, the base/Functions
tests run correctly without any issues.)
I'm trying to get GNUstep working on Alpine Linux v3.18. Currently,
libs-gui
can't compile on my system, so I was instructed to checklibs-base
first.The first thing I did was run
doas make uninstall
in every component built so far, uninstallgcc-objc
,libobjc
andg++
. I then builttools-make
,libobjc2
, then rebuilttools-make
withmake clean
, then running the old make script again:before proceeding to build
libs-base
and rungmake check
(I figured out that GNUstep make needs to be called as gmake on my own). UPDATE: This depends on whether the packagemake
from theedge
orv3.18
branch is used. The version fromedge
has /usr/bin/gmake along with /usr/bin/make, while the version fromv3.18
doesn't -- it has only /usr/bin/make.This was the summary of tests:
The first issue was GNUTLS, which failed tests until I changed the path to certtool to be the absolute one. Like that, I have the following results of
gmake check
:(I have no idea how the number of passed tests is smaller, I am building on my desktop and laptop separately, and I copied the previous results from my comment a couple of days back, so that might explain it.)
UPDATE: The issue with GNUTLS seems to have resolved itself somehow (?) (reverting the patch, doing
make clean
, rebuilding and runningmake check
doesn't make the GNUTLS tests fail), so no patch is needed for that.The first failed check out of the rest was about
NSCalendar
. By inserting the call toNSLog
I was able to print out the obtained date components:they are:
What can be done here to investigate this further? I don't have experience with Objective-C.