Work in progress

Work in progress

[Adolf Belka]

[-- Attachment #1: Type: text/plain, Size: 132 bytes --]

Hi all,

For information I am working on the following updates:-

gettext
gmp
go
gperf
grep
libmpc
mpc
mpd
zstd


Regards,

Adolf.

Re: Work in progress

[Adolf Belka]

[-- Attachment #1: Type: text/plain, Size: 5535 bytes --]

Hi All,

I had failures with building libcap-2.25 with the new gperf. From the 
fail messages I can see that the libcap build calls gperf and is finding 
unknown type names in the response.

I have seen that Matthias has updated libcap and submitted the patch.

I will wait till the updated libcap is merged and then redo my gperf 
build and see if that solves the problem. Until then I have excluded 
gperf from my current builds.

Here is the log output from building libcap with gperf updated from 
3.0.4 (2009) to 3.1 (2017).

Apr  5 13:45:53: Building libcap libcap-2.25.tar.xz checksum OK
+ cd /usr/src/lfs
+ make -f libcap LFS_BASEDIR=/usr/src install
====================================== Installing libcap-2.25 ...
Install started; saving file list to /usr/src/lsalr ...
# Prevent a static library from being installed
cd /usr/src/libcap-2.25 && sed -i '/install.*STALIBNAME/d' libcap/Makefile
cd /usr/src/libcap-2.25 && make
make[1]: Entering directory '/usr/src/libcap-2.25'
make -C libcap all
make[2]: Entering directory '/usr/src/libcap-2.25/libcap'
=> making cap_names.list.h from 
/usr/src/libcap-2.25/libcap/../libcap/include/uapi/linux/capability.h
perl -e 'while ($l=<>) { if ($l =~ /^\#define[ \t](CAP[_A-Z]+)[ 
\t]+([0-9]+)\s+$/) { $tok=$1; $val=$2; $tok =~ tr/A-Z/a-z/; print 
"{\"$tok\",$val},\n"; } }' 
/usr/src/libcap-2.25/libcap/../libcap/include/uapi/linux/capability.h | 
fgrep -v 0x > cap_names.list.h
gcc -O2 -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -fPIC 
-I/usr/src/libcap-2.25/libcap/../libcap/include/uapi 
-I/usr/src/libcap-2.25/libcap/../libcap/include _makenames.c -o _makenames
./_makenames > cap_names.h
gcc -O2 -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Dlinux -Wall 
-Wwrite-strings -Wpointer-arith -Wcast-qual -Wcast-align 
-Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline 
-Wshadow -g  -fPIC -I/usr/src/libcap-2.25/libcap/../libcap/include/uapi 
-I/usr/src/libcap-2.25/libcap/../libcap/include -c cap_alloc.c -o 
cap_alloc.o
gcc -O2 -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Dlinux -Wall 
-Wwrite-strings -Wpointer-arith -Wcast-qual -Wcast-align 
-Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline 
-Wshadow -g  -fPIC -I/usr/src/libcap-2.25/libcap/../libcap/include/uapi 
-I/usr/src/libcap-2.25/libcap/../libcap/include -c cap_proc.c -o cap_proc.o
gcc -O2 -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Dlinux -Wall 
-Wwrite-strings -Wpointer-arith -Wcast-qual -Wcast-align 
-Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline 
-Wshadow -g  -fPIC -I/usr/src/libcap-2.25/libcap/../libcap/include/uapi 
-I/usr/src/libcap-2.25/libcap/../libcap/include -c cap_extint.c -o 
cap_extint.o
gcc -O2 -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Dlinux -Wall 
-Wwrite-strings -Wpointer-arith -Wcast-qual -Wcast-align 
-Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline 
-Wshadow -g  -fPIC -I/usr/src/libcap-2.25/libcap/../libcap/include/uapi 
-I/usr/src/libcap-2.25/libcap/../libcap/include -c cap_flag.c -o cap_flag.o
perl -e 'print "struct __cap_token_s { const char *name; int index; 
};\n%{\nconst struct __cap_token_s *__cap_lookup_name(const char *, 
unsigned int);\n%}\n%%\n"; while ($l = <>) { $l =~ s/[\{\"]//g; $l =~ 
s/\}.*// ; print $l; }' < cap_names.list.h | gperf --ignore-case 
--language=ANSI-C --readonly --null-strings --global-table 
--hash-function-name=__cap_hash_name 
--lookup-function-name="__cap_lookup_name" -c -t -m20  > _caps_output.gperf
gcc -O2 -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Dlinux -Wall 
-Wwrite-strings -Wpointer-arith -Wcast-qual -Wcast-align 
-Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline 
-Wshadow -g  -fPIC -I/usr/src/libcap-2.25/libcap/../libcap/include/uapi 
-I/usr/src/libcap-2.25/libcap/../libcap/include -include 
_caps_output.gperf -c cap_text.c -o cap_text.o
In file included from <command-line>:
./_caps_output.gperf:71:80: error: unknown type name 'size_t'
    71 | gperf_case_strncmp (register const char *s1, register const 
char *s2, register size_t n)
| ^~~~~~
./_caps_output.gperf:96:53: error: unknown type name 'size_t'
    96 | __cap_hash_name (register const char *str, register size_t len)
       |                                                     ^~~~~~
./_caps_output.gperf:200:55: error: unknown type name 'size_t'
   200 | __cap_lookup_name (register const char *str, register size_t len)
       | ^~~~~~
./_caps_output.gperf:200:1: error: conflicting types for '__cap_lookup_name'
   200 | __cap_lookup_name (register const char *str, register size_t len)
       | ^~~~~~~~~~~~~~~~~
./_caps_output.gperf:33:29: note: previous declaration of 
'__cap_lookup_name' was here
    33 | const struct __cap_token_s *__cap_lookup_name(const char *, 
unsigned int);
       |                             ^~~~~~~~~~~~~~~~~
make[2]: *** [Makefile:63: cap_text.o] Error 1
make[2]: Leaving directory '/usr/src/libcap-2.25/libcap'
make[1]: *** [Makefile:12: all] Error 2
make[1]: Leaving directory '/usr/src/libcap-2.25'
make: *** [libcap:75: /usr/src/log/libcap-2.25] Error 2

On 05/04/2021 13:36, Adolf Belka wrote:
> Hi all,
>
> For information I am working on the following updates:-
>
> gettext
> gmp
> go
> gperf
> grep
> libmpc
> mpc
> mpd
> zstd
>
>
> Regards,
>
> Adolf.
>
-- 
Sent from my laptop

Re: Work in progress

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 5724 bytes --]

Hi,

It looks like cap_text.c is missing to include stddef.h. That is where size_t is defined.

I just merged the libcap, so you can give this another try.

Best,
-Michael

> On 5 Apr 2021, at 15:44, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
> 
> Hi All,
> 
> I had failures with building libcap-2.25 with the new gperf. From the fail messages I can see that the libcap build calls gperf and is finding unknown type names in the response.
> 
> I have seen that Matthias has updated libcap and submitted the patch.
> 
> I will wait till the updated libcap is merged and then redo my gperf build and see if that solves the problem. Until then I have excluded gperf from my current builds.
> 
> Here is the log output from building libcap with gperf updated from 3.0.4 (2009) to 3.1 (2017).
> 
> Apr  5 13:45:53: Building libcap libcap-2.25.tar.xz checksum OK
> + cd /usr/src/lfs
> + make -f libcap LFS_BASEDIR=/usr/src install
> ====================================== Installing libcap-2.25 ...
> Install started; saving file list to /usr/src/lsalr ...
> # Prevent a static library from being installed
> cd /usr/src/libcap-2.25 && sed -i '/install.*STALIBNAME/d' libcap/Makefile
> cd /usr/src/libcap-2.25 && make
> make[1]: Entering directory '/usr/src/libcap-2.25'
> make -C libcap all
> make[2]: Entering directory '/usr/src/libcap-2.25/libcap'
> => making cap_names.list.h from /usr/src/libcap-2.25/libcap/../libcap/include/uapi/linux/capability.h
> perl -e 'while ($l=<>) { if ($l =~ /^\#define[ \t](CAP[_A-Z]+)[ \t]+([0-9]+)\s+$/) { $tok=$1; $val=$2; $tok =~ tr/A-Z/a-z/; print "{\"$tok\",$val},\n"; } }' /usr/src/libcap-2.25/libcap/../libcap/include/uapi/linux/capability.h | fgrep -v 0x > cap_names.list.h
> gcc -O2 -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -fPIC -I/usr/src/libcap-2.25/libcap/../libcap/include/uapi -I/usr/src/libcap-2.25/libcap/../libcap/include _makenames.c -o _makenames
> ./_makenames > cap_names.h
> gcc -O2 -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Dlinux -Wall -Wwrite-strings -Wpointer-arith -Wcast-qual -Wcast-align -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline -Wshadow -g  -fPIC -I/usr/src/libcap-2.25/libcap/../libcap/include/uapi -I/usr/src/libcap-2.25/libcap/../libcap/include -c cap_alloc.c -o cap_alloc.o
> gcc -O2 -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Dlinux -Wall -Wwrite-strings -Wpointer-arith -Wcast-qual -Wcast-align -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline -Wshadow -g  -fPIC -I/usr/src/libcap-2.25/libcap/../libcap/include/uapi -I/usr/src/libcap-2.25/libcap/../libcap/include -c cap_proc.c -o cap_proc.o
> gcc -O2 -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Dlinux -Wall -Wwrite-strings -Wpointer-arith -Wcast-qual -Wcast-align -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline -Wshadow -g  -fPIC -I/usr/src/libcap-2.25/libcap/../libcap/include/uapi -I/usr/src/libcap-2.25/libcap/../libcap/include -c cap_extint.c -o cap_extint.o
> gcc -O2 -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Dlinux -Wall -Wwrite-strings -Wpointer-arith -Wcast-qual -Wcast-align -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline -Wshadow -g  -fPIC -I/usr/src/libcap-2.25/libcap/../libcap/include/uapi -I/usr/src/libcap-2.25/libcap/../libcap/include -c cap_flag.c -o cap_flag.o
> perl -e 'print "struct __cap_token_s { const char *name; int index; };\n%{\nconst struct __cap_token_s *__cap_lookup_name(const char *, unsigned int);\n%}\n%%\n"; while ($l = <>) { $l =~ s/[\{\"]//g; $l =~ s/\}.*// ; print $l; }' < cap_names.list.h | gperf --ignore-case --language=ANSI-C --readonly --null-strings --global-table --hash-function-name=__cap_hash_name --lookup-function-name="__cap_lookup_name" -c -t -m20  > _caps_output.gperf
> gcc -O2 -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Dlinux -Wall -Wwrite-strings -Wpointer-arith -Wcast-qual -Wcast-align -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline -Wshadow -g  -fPIC -I/usr/src/libcap-2.25/libcap/../libcap/include/uapi -I/usr/src/libcap-2.25/libcap/../libcap/include -include _caps_output.gperf -c cap_text.c -o cap_text.o
> In file included from <command-line>:
> ./_caps_output.gperf:71:80: error: unknown type name 'size_t'
>    71 | gperf_case_strncmp (register const char *s1, register const char *s2, register size_t n)
> | ^~~~~~
> ./_caps_output.gperf:96:53: error: unknown type name 'size_t'
>    96 | __cap_hash_name (register const char *str, register size_t len)
>       |                                                     ^~~~~~
> ./_caps_output.gperf:200:55: error: unknown type name 'size_t'
>   200 | __cap_lookup_name (register const char *str, register size_t len)
>       | ^~~~~~
> ./_caps_output.gperf:200:1: error: conflicting types for '__cap_lookup_name'
>   200 | __cap_lookup_name (register const char *str, register size_t len)
>       | ^~~~~~~~~~~~~~~~~
> ./_caps_output.gperf:33:29: note: previous declaration of '__cap_lookup_name' was here
>    33 | const struct __cap_token_s *__cap_lookup_name(const char *, unsigned int);
>       |                             ^~~~~~~~~~~~~~~~~
> make[2]: *** [Makefile:63: cap_text.o] Error 1
> make[2]: Leaving directory '/usr/src/libcap-2.25/libcap'
> make[1]: *** [Makefile:12: all] Error 2
> make[1]: Leaving directory '/usr/src/libcap-2.25'
> make: *** [libcap:75: /usr/src/log/libcap-2.25] Error 2
> 
> On 05/04/2021 13:36, Adolf Belka wrote:
>> Hi all,
>> 
>> For information I am working on the following updates:-
>> 
>> gettext
>> gmp
>> go
>> gperf
>> grep
>> libmpc
>> mpc
>> mpd
>> zstd
>> 
>> 
>> Regards,
>> 
>> Adolf.
>> 
> -- 
> Sent from my laptop
> 

Re: Work in progress

[Adolf Belka]

[-- Attachment #1: Type: text/plain, Size: 6392 bytes --]

Hi Michael,

On 06/04/2021 12:21, Michael Tremer wrote:
> Hi,
> 
> It looks like cap_text.c is missing to include stddef.h. That is where size_t is defined.
> 
> I just merged the libcap, so you can give this another try.

I just found a bug entry in Gentoo from 2017 for the same issue I found of gperf-3.1 with libcap-2.25
Apparently gperf is called in the makefile to generate a hash table lookup and if gperf is not available libcap falls back to using a plain list of cap names, so it is not essential to use gperf.

I just checked and the gperf call is no longer in the makefile for libcap-2-49 so the new libcap version should solve things.
I will retry the build and let you know how it goes.

Thanks and regards,
Adolf.
> 
> Best,
> -Michael
> 
>> On 5 Apr 2021, at 15:44, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>
>> Hi All,
>>
>> I had failures with building libcap-2.25 with the new gperf. From the fail messages I can see that the libcap build calls gperf and is finding unknown type names in the response.
>>
>> I have seen that Matthias has updated libcap and submitted the patch.
>>
>> I will wait till the updated libcap is merged and then redo my gperf build and see if that solves the problem. Until then I have excluded gperf from my current builds.
>>
>> Here is the log output from building libcap with gperf updated from 3.0.4 (2009) to 3.1 (2017).
>>
>> Apr  5 13:45:53: Building libcap libcap-2.25.tar.xz checksum OK
>> + cd /usr/src/lfs
>> + make -f libcap LFS_BASEDIR=/usr/src install
>> ====================================== Installing libcap-2.25 ...
>> Install started; saving file list to /usr/src/lsalr ...
>> # Prevent a static library from being installed
>> cd /usr/src/libcap-2.25 && sed -i '/install.*STALIBNAME/d' libcap/Makefile
>> cd /usr/src/libcap-2.25 && make
>> make[1]: Entering directory '/usr/src/libcap-2.25'
>> make -C libcap all
>> make[2]: Entering directory '/usr/src/libcap-2.25/libcap'
>> => making cap_names.list.h from /usr/src/libcap-2.25/libcap/../libcap/include/uapi/linux/capability.h
>> perl -e 'while ($l=<>) { if ($l =~ /^\#define[ \t](CAP[_A-Z]+)[ \t]+([0-9]+)\s+$/) { $tok=$1; $val=$2; $tok =~ tr/A-Z/a-z/; print "{\"$tok\",$val},\n"; } }' /usr/src/libcap-2.25/libcap/../libcap/include/uapi/linux/capability.h | fgrep -v 0x > cap_names.list.h
>> gcc -O2 -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -fPIC -I/usr/src/libcap-2.25/libcap/../libcap/include/uapi -I/usr/src/libcap-2.25/libcap/../libcap/include _makenames.c -o _makenames
>> ./_makenames > cap_names.h
>> gcc -O2 -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Dlinux -Wall -Wwrite-strings -Wpointer-arith -Wcast-qual -Wcast-align -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline -Wshadow -g  -fPIC -I/usr/src/libcap-2.25/libcap/../libcap/include/uapi -I/usr/src/libcap-2.25/libcap/../libcap/include -c cap_alloc.c -o cap_alloc.o
>> gcc -O2 -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Dlinux -Wall -Wwrite-strings -Wpointer-arith -Wcast-qual -Wcast-align -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline -Wshadow -g  -fPIC -I/usr/src/libcap-2.25/libcap/../libcap/include/uapi -I/usr/src/libcap-2.25/libcap/../libcap/include -c cap_proc.c -o cap_proc.o
>> gcc -O2 -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Dlinux -Wall -Wwrite-strings -Wpointer-arith -Wcast-qual -Wcast-align -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline -Wshadow -g  -fPIC -I/usr/src/libcap-2.25/libcap/../libcap/include/uapi -I/usr/src/libcap-2.25/libcap/../libcap/include -c cap_extint.c -o cap_extint.o
>> gcc -O2 -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Dlinux -Wall -Wwrite-strings -Wpointer-arith -Wcast-qual -Wcast-align -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline -Wshadow -g  -fPIC -I/usr/src/libcap-2.25/libcap/../libcap/include/uapi -I/usr/src/libcap-2.25/libcap/../libcap/include -c cap_flag.c -o cap_flag.o
>> perl -e 'print "struct __cap_token_s { const char *name; int index; };\n%{\nconst struct __cap_token_s *__cap_lookup_name(const char *, unsigned int);\n%}\n%%\n"; while ($l = <>) { $l =~ s/[\{\"]//g; $l =~ s/\}.*// ; print $l; }' < cap_names.list.h | gperf --ignore-case --language=ANSI-C --readonly --null-strings --global-table --hash-function-name=__cap_hash_name --lookup-function-name="__cap_lookup_name" -c -t -m20  > _caps_output.gperf
>> gcc -O2 -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Dlinux -Wall -Wwrite-strings -Wpointer-arith -Wcast-qual -Wcast-align -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline -Wshadow -g  -fPIC -I/usr/src/libcap-2.25/libcap/../libcap/include/uapi -I/usr/src/libcap-2.25/libcap/../libcap/include -include _caps_output.gperf -c cap_text.c -o cap_text.o
>> In file included from <command-line>:
>> ./_caps_output.gperf:71:80: error: unknown type name 'size_t'
>>     71 | gperf_case_strncmp (register const char *s1, register const char *s2, register size_t n)
>> | ^~~~~~
>> ./_caps_output.gperf:96:53: error: unknown type name 'size_t'
>>     96 | __cap_hash_name (register const char *str, register size_t len)
>>        |                                                     ^~~~~~
>> ./_caps_output.gperf:200:55: error: unknown type name 'size_t'
>>    200 | __cap_lookup_name (register const char *str, register size_t len)
>>        | ^~~~~~
>> ./_caps_output.gperf:200:1: error: conflicting types for '__cap_lookup_name'
>>    200 | __cap_lookup_name (register const char *str, register size_t len)
>>        | ^~~~~~~~~~~~~~~~~
>> ./_caps_output.gperf:33:29: note: previous declaration of '__cap_lookup_name' was here
>>     33 | const struct __cap_token_s *__cap_lookup_name(const char *, unsigned int);
>>        |                             ^~~~~~~~~~~~~~~~~
>> make[2]: *** [Makefile:63: cap_text.o] Error 1
>> make[2]: Leaving directory '/usr/src/libcap-2.25/libcap'
>> make[1]: *** [Makefile:12: all] Error 2
>> make[1]: Leaving directory '/usr/src/libcap-2.25'
>> make: *** [libcap:75: /usr/src/log/libcap-2.25] Error 2
>>
>> On 05/04/2021 13:36, Adolf Belka wrote:
>>> Hi all,
>>>
>>> For information I am working on the following updates:-
>>>
>>> gettext
>>> gmp
>>> go
>>> gperf
>>> grep
>>> libmpc
>>> mpc
>>> mpd
>>> zstd
>>>
>>>
>>> Regards,
>>>
>>> Adolf.
>>>
>> -- 
>> Sent from my laptop
>>
> 

Re: Work in progress

[Adolf Belka]

[-- Attachment #1: Type: text/plain, Size: 6922 bytes --]

Hi all,

On 06/04/2021 14:43, Adolf Belka wrote:
> Hi Michael,
>
> On 06/04/2021 12:21, Michael Tremer wrote:
>> Hi,
>>
>> It looks like cap_text.c is missing to include stddef.h. That is where size_t is defined.
>>
>> I just merged the libcap, so you can give this another try.
>
> I just found a bug entry in Gentoo from 2017 for the same issue I found of gperf-3.1 with libcap-2.25
> Apparently gperf is called in the makefile to generate a hash table lookup and if gperf is not available libcap falls back to using a plain list of cap names, so it is not essential to use gperf.
>
> I just checked and the gperf call is no longer in the makefile for libcap-2-49 so the new libcap version should solve things.
> I will retry the build and let you know how it goes.
>
The build of gperf-3.1 went without any problems with libcap-2.49

The only think I found was that there was a message "Changes in libcap-2.49 check rootfile!" and there were a lot of lines with +usr/share/gocode/src/kernel.org/pub/linux/libs/security/libcap.....


A patch for the update of gperf will be submitted shortly.

Regards,

Adolf.

> Thanks and regards,
> Adolf.
>>
>> Best,
>> -Michael
>>
>>> On 5 Apr 2021, at 15:44, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>>
>>> Hi All,
>>>
>>> I had failures with building libcap-2.25 with the new gperf. From the fail messages I can see that the libcap build calls gperf and is finding unknown type names in the response.
>>>
>>> I have seen that Matthias has updated libcap and submitted the patch.
>>>
>>> I will wait till the updated libcap is merged and then redo my gperf build and see if that solves the problem. Until then I have excluded gperf from my current builds.
>>>
>>> Here is the log output from building libcap with gperf updated from 3.0.4 (2009) to 3.1 (2017).
>>>
>>> Apr  5 13:45:53: Building libcap libcap-2.25.tar.xz checksum OK
>>> + cd /usr/src/lfs
>>> + make -f libcap LFS_BASEDIR=/usr/src install
>>> ====================================== Installing libcap-2.25 ...
>>> Install started; saving file list to /usr/src/lsalr ...
>>> # Prevent a static library from being installed
>>> cd /usr/src/libcap-2.25 && sed -i '/install.*STALIBNAME/d' libcap/Makefile
>>> cd /usr/src/libcap-2.25 && make
>>> make[1]: Entering directory '/usr/src/libcap-2.25'
>>> make -C libcap all
>>> make[2]: Entering directory '/usr/src/libcap-2.25/libcap'
>>> => making cap_names.list.h from /usr/src/libcap-2.25/libcap/../libcap/include/uapi/linux/capability.h
>>> perl -e 'while ($l=<>) { if ($l =~ /^\#define[ \t](CAP[_A-Z]+)[ \t]+([0-9]+)\s+$/) { $tok=$1; $val=$2; $tok =~ tr/A-Z/a-z/; print "{\"$tok\",$val},\n"; } }' /usr/src/libcap-2.25/libcap/../libcap/include/uapi/linux/capability.h | fgrep -v 0x > cap_names.list.h
>>> gcc -O2 -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -fPIC -I/usr/src/libcap-2.25/libcap/../libcap/include/uapi -I/usr/src/libcap-2.25/libcap/../libcap/include _makenames.c -o _makenames
>>> ./_makenames > cap_names.h
>>> gcc -O2 -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Dlinux -Wall -Wwrite-strings -Wpointer-arith -Wcast-qual -Wcast-align -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline -Wshadow -g  -fPIC -I/usr/src/libcap-2.25/libcap/../libcap/include/uapi -I/usr/src/libcap-2.25/libcap/../libcap/include -c cap_alloc.c -o cap_alloc.o
>>> gcc -O2 -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Dlinux -Wall -Wwrite-strings -Wpointer-arith -Wcast-qual -Wcast-align -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline -Wshadow -g  -fPIC -I/usr/src/libcap-2.25/libcap/../libcap/include/uapi -I/usr/src/libcap-2.25/libcap/../libcap/include -c cap_proc.c -o cap_proc.o
>>> gcc -O2 -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Dlinux -Wall -Wwrite-strings -Wpointer-arith -Wcast-qual -Wcast-align -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline -Wshadow -g  -fPIC -I/usr/src/libcap-2.25/libcap/../libcap/include/uapi -I/usr/src/libcap-2.25/libcap/../libcap/include -c cap_extint.c -o cap_extint.o
>>> gcc -O2 -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Dlinux -Wall -Wwrite-strings -Wpointer-arith -Wcast-qual -Wcast-align -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline -Wshadow -g  -fPIC -I/usr/src/libcap-2.25/libcap/../libcap/include/uapi -I/usr/src/libcap-2.25/libcap/../libcap/include -c cap_flag.c -o cap_flag.o
>>> perl -e 'print "struct __cap_token_s { const char *name; int index; };\n%{\nconst struct __cap_token_s *__cap_lookup_name(const char *, unsigned int);\n%}\n%%\n"; while ($l = <>) { $l =~ s/[\{\"]//g; $l =~ s/\}.*// ; print $l; }' < cap_names.list.h | gperf --ignore-case --language=ANSI-C --readonly --null-strings --global-table --hash-function-name=__cap_hash_name --lookup-function-name="__cap_lookup_name" -c -t -m20  > _caps_output.gperf
>>> gcc -O2 -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Dlinux -Wall -Wwrite-strings -Wpointer-arith -Wcast-qual -Wcast-align -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline -Wshadow -g  -fPIC -I/usr/src/libcap-2.25/libcap/../libcap/include/uapi -I/usr/src/libcap-2.25/libcap/../libcap/include -include _caps_output.gperf -c cap_text.c -o cap_text.o
>>> In file included from <command-line>:
>>> ./_caps_output.gperf:71:80: error: unknown type name 'size_t'
>>>     71 | gperf_case_strncmp (register const char *s1, register const char *s2, register size_t n)
>>> | ^~~~~~
>>> ./_caps_output.gperf:96:53: error: unknown type name 'size_t'
>>>     96 | __cap_hash_name (register const char *str, register size_t len)
>>>        | ^~~~~~
>>> ./_caps_output.gperf:200:55: error: unknown type name 'size_t'
>>>    200 | __cap_lookup_name (register const char *str, register size_t len)
>>>        | ^~~~~~
>>> ./_caps_output.gperf:200:1: error: conflicting types for '__cap_lookup_name'
>>>    200 | __cap_lookup_name (register const char *str, register size_t len)
>>>        | ^~~~~~~~~~~~~~~~~
>>> ./_caps_output.gperf:33:29: note: previous declaration of '__cap_lookup_name' was here
>>>     33 | const struct __cap_token_s *__cap_lookup_name(const char *, unsigned int);
>>>        |                             ^~~~~~~~~~~~~~~~~
>>> make[2]: *** [Makefile:63: cap_text.o] Error 1
>>> make[2]: Leaving directory '/usr/src/libcap-2.25/libcap'
>>> make[1]: *** [Makefile:12: all] Error 2
>>> make[1]: Leaving directory '/usr/src/libcap-2.25'
>>> make: *** [libcap:75: /usr/src/log/libcap-2.25] Error 2
>>>
>>> On 05/04/2021 13:36, Adolf Belka wrote:
>>>> Hi all,
>>>>
>>>> For information I am working on the following updates:-
>>>>
>>>> gettext
>>>> gmp
>>>> go
>>>> gperf
>>>> grep
>>>> libmpc
>>>> mpc
>>>> mpd
>>>> zstd
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Adolf.
>>>>
>>> -- 
>>> Sent from my laptop
>>>
>>

Re: Work in progress

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 7340 bytes --]

Hello,

> On 7 Apr 2021, at 15:01, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
> 
> Hi all,
> 
> On 06/04/2021 14:43, Adolf Belka wrote:
>> Hi Michael,
>> 
>> On 06/04/2021 12:21, Michael Tremer wrote:
>>> Hi,
>>> 
>>> It looks like cap_text.c is missing to include stddef.h. That is where size_t is defined.
>>> 
>>> I just merged the libcap, so you can give this another try.
>> 
>> I just found a bug entry in Gentoo from 2017 for the same issue I found of gperf-3.1 with libcap-2.25
>> Apparently gperf is called in the makefile to generate a hash table lookup and if gperf is not available libcap falls back to using a plain list of cap names, so it is not essential to use gperf.
>> 
>> I just checked and the gperf call is no longer in the makefile for libcap-2-49 so the new libcap version should solve things.
>> I will retry the build and let you know how it goes.
>> 
> The build of gperf-3.1 went without any problems with libcap-2.49

Perfect. I have already merged this patch.

> The only think I found was that there was a message "Changes in libcap-2.49 check rootfile!" and there were a lot of lines with +usr/share/gocode/src/kernel.org/pub/linux/libs/security/libcap.....

Yes, this is because it found a Go compiler. I have disabled this because we do not need a Go version of this library:

  https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=7f6d6e19c9a5499321fd7a18ad66d38dad892b01

> A patch for the update of gperf will be submitted shortly.
> 
> Regards,
> 
> Adolf.
> 
>> Thanks and regards,
>> Adolf.
>>> 
>>> Best,
>>> -Michael
>>> 
>>>> On 5 Apr 2021, at 15:44, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
>>>> 
>>>> Hi All,
>>>> 
>>>> I had failures with building libcap-2.25 with the new gperf. From the fail messages I can see that the libcap build calls gperf and is finding unknown type names in the response.
>>>> 
>>>> I have seen that Matthias has updated libcap and submitted the patch.
>>>> 
>>>> I will wait till the updated libcap is merged and then redo my gperf build and see if that solves the problem. Until then I have excluded gperf from my current builds.
>>>> 
>>>> Here is the log output from building libcap with gperf updated from 3.0.4 (2009) to 3.1 (2017).
>>>> 
>>>> Apr  5 13:45:53: Building libcap libcap-2.25.tar.xz checksum OK
>>>> + cd /usr/src/lfs
>>>> + make -f libcap LFS_BASEDIR=/usr/src install
>>>> ====================================== Installing libcap-2.25 ...
>>>> Install started; saving file list to /usr/src/lsalr ...
>>>> # Prevent a static library from being installed
>>>> cd /usr/src/libcap-2.25 && sed -i '/install.*STALIBNAME/d' libcap/Makefile
>>>> cd /usr/src/libcap-2.25 && make
>>>> make[1]: Entering directory '/usr/src/libcap-2.25'
>>>> make -C libcap all
>>>> make[2]: Entering directory '/usr/src/libcap-2.25/libcap'
>>>> => making cap_names.list.h from /usr/src/libcap-2.25/libcap/../libcap/include/uapi/linux/capability.h
>>>> perl -e 'while ($l=<>) { if ($l =~ /^\#define[ \t](CAP[_A-Z]+)[ \t]+([0-9]+)\s+$/) { $tok=$1; $val=$2; $tok =~ tr/A-Z/a-z/; print "{\"$tok\",$val},\n"; } }' /usr/src/libcap-2.25/libcap/../libcap/include/uapi/linux/capability.h | fgrep -v 0x > cap_names.list.h
>>>> gcc -O2 -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -fPIC -I/usr/src/libcap-2.25/libcap/../libcap/include/uapi -I/usr/src/libcap-2.25/libcap/../libcap/include _makenames.c -o _makenames
>>>> ./_makenames > cap_names.h
>>>> gcc -O2 -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Dlinux -Wall -Wwrite-strings -Wpointer-arith -Wcast-qual -Wcast-align -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline -Wshadow -g  -fPIC -I/usr/src/libcap-2.25/libcap/../libcap/include/uapi -I/usr/src/libcap-2.25/libcap/../libcap/include -c cap_alloc.c -o cap_alloc.o
>>>> gcc -O2 -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Dlinux -Wall -Wwrite-strings -Wpointer-arith -Wcast-qual -Wcast-align -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline -Wshadow -g  -fPIC -I/usr/src/libcap-2.25/libcap/../libcap/include/uapi -I/usr/src/libcap-2.25/libcap/../libcap/include -c cap_proc.c -o cap_proc.o
>>>> gcc -O2 -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Dlinux -Wall -Wwrite-strings -Wpointer-arith -Wcast-qual -Wcast-align -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline -Wshadow -g  -fPIC -I/usr/src/libcap-2.25/libcap/../libcap/include/uapi -I/usr/src/libcap-2.25/libcap/../libcap/include -c cap_extint.c -o cap_extint.o
>>>> gcc -O2 -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Dlinux -Wall -Wwrite-strings -Wpointer-arith -Wcast-qual -Wcast-align -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline -Wshadow -g  -fPIC -I/usr/src/libcap-2.25/libcap/../libcap/include/uapi -I/usr/src/libcap-2.25/libcap/../libcap/include -c cap_flag.c -o cap_flag.o
>>>> perl -e 'print "struct __cap_token_s { const char *name; int index; };\n%{\nconst struct __cap_token_s *__cap_lookup_name(const char *, unsigned int);\n%}\n%%\n"; while ($l = <>) { $l =~ s/[\{\"]//g; $l =~ s/\}.*// ; print $l; }' < cap_names.list.h | gperf --ignore-case --language=ANSI-C --readonly --null-strings --global-table --hash-function-name=__cap_hash_name --lookup-function-name="__cap_lookup_name" -c -t -m20  > _caps_output.gperf
>>>> gcc -O2 -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Dlinux -Wall -Wwrite-strings -Wpointer-arith -Wcast-qual -Wcast-align -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline -Wshadow -g  -fPIC -I/usr/src/libcap-2.25/libcap/../libcap/include/uapi -I/usr/src/libcap-2.25/libcap/../libcap/include -include _caps_output.gperf -c cap_text.c -o cap_text.o
>>>> In file included from <command-line>:
>>>> ./_caps_output.gperf:71:80: error: unknown type name 'size_t'
>>>>     71 | gperf_case_strncmp (register const char *s1, register const char *s2, register size_t n)
>>>> | ^~~~~~
>>>> ./_caps_output.gperf:96:53: error: unknown type name 'size_t'
>>>>     96 | __cap_hash_name (register const char *str, register size_t len)
>>>>        | ^~~~~~
>>>> ./_caps_output.gperf:200:55: error: unknown type name 'size_t'
>>>>    200 | __cap_lookup_name (register const char *str, register size_t len)
>>>>        | ^~~~~~
>>>> ./_caps_output.gperf:200:1: error: conflicting types for '__cap_lookup_name'
>>>>    200 | __cap_lookup_name (register const char *str, register size_t len)
>>>>        | ^~~~~~~~~~~~~~~~~
>>>> ./_caps_output.gperf:33:29: note: previous declaration of '__cap_lookup_name' was here
>>>>     33 | const struct __cap_token_s *__cap_lookup_name(const char *, unsigned int);
>>>>        |                             ^~~~~~~~~~~~~~~~~
>>>> make[2]: *** [Makefile:63: cap_text.o] Error 1
>>>> make[2]: Leaving directory '/usr/src/libcap-2.25/libcap'
>>>> make[1]: *** [Makefile:12: all] Error 2
>>>> make[1]: Leaving directory '/usr/src/libcap-2.25'
>>>> make: *** [libcap:75: /usr/src/log/libcap-2.25] Error 2
>>>> 
>>>> On 05/04/2021 13:36, Adolf Belka wrote:
>>>>> Hi all,
>>>>> 
>>>>> For information I am working on the following updates:-
>>>>> 
>>>>> gettext
>>>>> gmp
>>>>> go
>>>>> gperf
>>>>> grep
>>>>> libmpc
>>>>> mpc
>>>>> mpd
>>>>> zstd
>>>>> 
>>>>> 
>>>>> Regards,
>>>>> 
>>>>> Adolf.
>>>>> 
>>>> -- 
>>>> Sent from my laptop

Work in progress

[Matthias Fischer]

[-- Attachment #1: Type: text/plain, Size: 190 bytes --]

Hi,

"as time goes by", currently working on:

cmake => 3.20.0
json-c => 0.15
libcap => 2.49
libcap-ng => 0.8.2
libpcap => 1.10.0
tcpdump => 4.99.0
linux => 6.21-rc17

Best,
Mat- ;-) -thias

Re: Work in progress

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 356 bytes --]

Hi,

> On 1 Apr 2021, at 08:51, Matthias Fischer <matthias.fischer(a)ipfire.org> wrote:
> 
> Hi,
> 
> "as time goes by", currently working on:
> 
> cmake => 3.20.0
> json-c => 0.15
> libcap => 2.49
> libcap-ng => 0.8.2
> libpcap => 1.10.0
> tcpdump => 4.99.0
> linux => 6.21-rc17

What is the last one?

> 
> Best,
> Mat- ;-) -thias

Re: Work in progress

[Matthias Fischer]

[-- Attachment #1: Type: text/plain, Size: 299 bytes --]

On 01.04.2021 11:59, Michael Tremer wrote:
>> ...
>> linux => 6.21-rc17
> What is the last one?
> 

Look at the calender...

01000001 01110000 01110010 01101001 01101100 00101100 00100000 01000001
01110000 01110010 01101001 01101100

I thought of your chrismas message and couldn't resist... ;-)

Re: Work in progress

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 443 bytes --]

Oh lol :)

> On 1 Apr 2021, at 12:34, Matthias Fischer <matthias.fischer(a)ipfire.org> wrote:
> 
> On 01.04.2021 11:59, Michael Tremer wrote:
>>> ...
>>> linux => 6.21-rc17
>> What is the last one?
>> 
> 
> Look at the calender...
> 
> 01000001 01110000 01110010 01101001 01101100 00101100 00100000 01000001
> 01110000 01110010 01101001 01101100
> 
> I thought of your chrismas message and couldn't resist... ;-)
> 
> 
> 

Work in progress

[Matthias Fischer]

[-- Attachment #1: Type: text/plain, Size: 281 bytes --]

Hi,

just in short - FYI - and to avoid duplicate work:

monit	=>	5.27.1
dhcpcd	=>	9.3.2
bind	=>	9.11.24
knot	=>	3.0.2

These are running here already - I just hadn't the time to push them
yet. There is simply too much going on at work, little - or no - time left.

Best,
Matthias

Re: Work in progress

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 724 bytes --]

Hello Matthias,

Thank you for your email. Good to know.

If you have some free time left, could you have a look at Ghostscript for me?

Some of my print jobs are getting stuck because “gs” freezes and consumes 100% CPU until I kill it. Maybe that is fixed in the next release.

Best,
-Michael

> On 21 Nov 2020, at 10:33, Matthias Fischer <matthias.fischer(a)ipfire.org> wrote:
> 
> Hi,
> 
> just in short - FYI - and to avoid duplicate work:
> 
> monit	=>	5.27.1
> dhcpcd	=>	9.3.2
> bind	=>	9.11.24
> knot	=>	3.0.2
> 
> These are running here already - I just hadn't the time to push them
> yet. There is simply too much going on at work, little - or no - time left.
> 
> Best,
> Matthias

Re: Work in progress

[Matthias Fischer]

[-- Attachment #1: Type: text/plain, Size: 975 bytes --]

Hi Michael,

On 23.11.2020 12:29, Michael Tremer wrote:
> Hello Matthias,
> 
> Thank you for your email. Good to know.
> 
> If you have some free time left, could you have a look at Ghostscript for me?
> 
> Some of my print jobs are getting stuck because “gs” freezes and consumes 100% CPU until I kill it. Maybe that is fixed in the next release.

Update to 9.53.3 is compiling on 'next' without seen errors. I will
check the rootfile before pushing. "Work in progress..." ;-)

Best,
Matthias

> Best,
> -Michael
> 
>> On 21 Nov 2020, at 10:33, Matthias Fischer <matthias.fischer(a)ipfire.org> wrote:
>> 
>> Hi,
>> 
>> just in short - FYI - and to avoid duplicate work:
>> 
>> monit	=>	5.27.1
>> dhcpcd	=>	9.3.2
>> bind	=>	9.11.24
>> knot	=>	3.0.2
>> 
>> These are running here already - I just hadn't the time to push them
>> yet. There is simply too much going on at work, little - or no - time left.
>> 
>> Best,
>> Matthias
> 

Re: Work in progress

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 1141 bytes --]

Hello,

> On 25 Nov 2020, at 17:09, Matthias Fischer <matthias.fischer(a)ipfire.org> wrote:
> 
> Hi Michael,
> 
> On 23.11.2020 12:29, Michael Tremer wrote:
>> Hello Matthias,
>> 
>> Thank you for your email. Good to know.
>> 
>> If you have some free time left, could you have a look at Ghostscript for me?
>> 
>> Some of my print jobs are getting stuck because “gs” freezes and consumes 100% CPU until I kill it. Maybe that is fixed in the next release.
> 
> Update to 9.53.3 is compiling on 'next' without seen errors. I will
> check the rootfile before pushing. "Work in progress..." ;-)

Thank you!

> 
> Best,
> Matthias
> 
>> Best,
>> -Michael
>> 
>>> On 21 Nov 2020, at 10:33, Matthias Fischer <matthias.fischer(a)ipfire.org> wrote:
>>> 
>>> Hi,
>>> 
>>> just in short - FYI - and to avoid duplicate work:
>>> 
>>> monit	=>	5.27.1
>>> dhcpcd	=>	9.3.2
>>> bind	=>	9.11.24
>>> knot	=>	3.0.2
>>> 
>>> These are running here already - I just hadn't the time to push them
>>> yet. There is simply too much going on at work, little - or no - time left.
>>> 
>>> Best,
>>> Matthias
>> 
> 

Re: Work in progress

[Matthias Fischer]

[-- Attachment #1: Type: text/plain, Size: 1389 bytes --]

On 25.11.2020 21:49, Michael Tremer wrote:
> Hello,
> 
>> On 25 Nov 2020, at 17:09, Matthias Fischer <matthias.fischer(a)ipfire.org> wrote:
>> 
>> Hi Michael,
>> 
>> On 23.11.2020 12:29, Michael Tremer wrote:
>>> Hello Matthias,
>>> 
>>> Thank you for your email. Good to know.
>>> 
>>> If you have some free time left, could you have a look at Ghostscript for me?
>>> 
>>> Some of my print jobs are getting stuck because “gs” freezes and consumes 100% CPU until I kill it. Maybe that is fixed in the next release.
>> 
>> Update to 9.53.3 is compiling on 'next' without seen errors. I will
>> check the rootfile before pushing. "Work in progress..." ;-)

Done => https://patchwork.ipfire.org/patch/3680/

> Thank you!

You're welcome! ;-)

But no guarantee - its building without errors, but I couldn't test this...

>> 
>> Best,
>> Matthias
>> 
>>> Best,
>>> -Michael
>>> 
>>>> On 21 Nov 2020, at 10:33, Matthias Fischer <matthias.fischer(a)ipfire.org> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> just in short - FYI - and to avoid duplicate work:
>>>> 
>>>> monit	=>	5.27.1
>>>> dhcpcd	=>	9.3.2
>>>> bind	=>	9.11.24
>>>> knot	=>	3.0.2
>>>> 
>>>> These are running here already - I just hadn't the time to push them
>>>> yet. There is simply too much going on at work, little - or no - time left.
>>>> 
>>>> Best,
>>>> Matthias
>>> 
>> 
> 

Work in progress

[Matthias Fischer]

[-- Attachment #1: Type: text/plain, Size: 328 bytes --]

Hi,

FYI:

Just building:
squid 4.12

At work:
gnutls 3.6.14
gmp 6.2.0
borgbackup 1.1.13

Just in case that someone is working at these updates, too.

Unfortunately I'm not 100% sure about the gmp-rootfiles for the
different architectures. Otherwise I would upload these updates within
the next days.

Opinions?

Best,
Matthias

Re: Work in progress

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 730 bytes --]

Hello,

Thank you for looking at those packages.

Are you aware that GnuTLS has a security vulnerability? It would be nice if you could look at this one as soon as possible.

> On 9 Jun 2020, at 16:24, Matthias Fischer <matthias.fischer(a)ipfire.org> wrote:
> 
> Hi,
> 
> FYI:
> 
> Just building:
> squid 4.12
> 
> At work:
> gnutls 3.6.14
> gmp 6.2.0
> borgbackup 1.1.13
> 
> Just in case that someone is working at these updates, too.
> 
> Unfortunately I'm not 100% sure about the gmp-rootfiles for the
> different architectures. Otherwise I would upload these updates within
> the next days.

Send questions to the list if you are unsure :)

-Michael

> 
> Opinions?
> 
> Best,
> Matthias

Re: Work in progress

[Matthias Fischer]

[-- Attachment #1: Type: text/plain, Size: 1112 bytes --]

Hi,

On 10.06.2020 10:35, Michael Tremer wrote:
> Hello,
> 
> Thank you for looking at those packages.

They "just came into my view..." And some more. Right now I'm waiting
for dhcpcd 9.1.2 ("...is around the corner").

> Are you aware that GnuTLS has a security vulnerability? It would be nice if you could look at this one as soon as possible.

Updates done.

All compiled without errors on current 'next' / x86_64.

>> ...
>> Unfortunately I'm not 100% sure about the gmp-rootfiles for the
>> different architectures. Otherwise I would upload these updates within
>> the next days.
> 
> Send questions to the list if you are unsure :)

As far as I could see, there were no errors on my last build -
nevertheless I couldn't built them on ARM hardware, so it would be nice
if someone could check.

I don't know why, but for the last patchset (gnutls 3.6.14 and gmp
6.2.0) I only got one mail for 1/2 in the list. Somehow patch 2/2 (gmp
6.2.0) got stuck!? On patchwork, they're both ok.

Best,
Matthias

> 
> -Michael
> 
>> 
>> Opinions?
>> 
>> Best,
>> Matthias
>