Re: problem w/dhcpcd vs libsupc++.a on sparc?

2020-04-21 Thread Roy Marples

On 21/04/2020 00:02, John D. Baker wrote:

On Mon, 20 Apr 2020, r...@marples.name wrote:


Anyway the patch linked below should fix this.
https://roy.marples.name/cgit/dhcpcd.git/patch/?id=1dc1fce7ae7b4c106a8eb631ed92ab1ed8e86bbc

I'm waiting for feedback on a few more issues, so hopefully you can
clarify the patch works before I import a fixed dhcpcd.


The patch appears only to be for the 'dhcpcd' in -current.  The version
of 'dhcpcd' in netbsd-9 is rather different in that area.

Building sparc-current again and will test soon.  Need equivalent patch
for 'dhcpcd' in netbsd-9.


Sorry, I thought it was -current.
Here is patch for netbsd-9:
https://roy.marples.name/cgit/dhcpcd.git/commit/?h=dhcpcd-8&id=ff78692ef3e74f8f7de2883db541de915c295e07

Roy


Re: problem w/dhcpcd vs libsupc++.a on sparc?

2020-04-21 Thread Roy Marples

On 21/04/2020 09:07, Roy Marples wrote:

On 21/04/2020 00:02, John D. Baker wrote:

On Mon, 20 Apr 2020, r...@marples.name wrote:


Anyway the patch linked below should fix this.
https://roy.marples.name/cgit/dhcpcd.git/patch/?id=1dc1fce7ae7b4c106a8eb631ed92ab1ed8e86bbc 



I'm waiting for feedback on a few more issues, so hopefully you can
clarify the patch works before I import a fixed dhcpcd.


The patch appears only to be for the 'dhcpcd' in -current.  The version
of 'dhcpcd' in netbsd-9 is rather different in that area.

Building sparc-current again and will test soon.  Need equivalent patch
for 'dhcpcd' in netbsd-9.


Sorry, I thought it was -current.
Here is patch for netbsd-9:
https://roy.marples.name/cgit/dhcpcd.git/commit/?h=dhcpcd-8&id=ff78692ef3e74f8f7de2883db541de915c295e07 


I've submitted a pullup for netbsd-9 with a more fixes thanks to mrg@ and nick@
Hopefully Martin can address it soon!

-current and pkgsrc have already been fixed.

Roy


Automated report: NetBSD-current/i386 build failure

2020-04-21 Thread NetBSD Test Fixture
This is an automatically generated notice of a NetBSD-current/i386
build failure.

The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host,
using sources from CVS date 2020.04.21.13.57.12.

An extract from the build.sh output follows:


/tmp/bracket/build/2020.04.21.13.57.12-i386/src/sys/arch/xen/xen/xbdback_xenbus.c:1218:37:
 error: request for member 'nr_segments' in something not a structure or union
req->nr_segments = (uint8_t)rin64->nr_segments;
 ^~
--- xen_intr.o ---
--- xbdback_xenbus.o ---

/tmp/bracket/build/2020.04.21.13.57.12-i386/src/sys/arch/xen/xen/xbdback_xenbus.c:1221:32:
 error: request for member 'indirect_grefs' in something not a structure or 
union
xbdi->xbdi_in_gntref = rin64->indirect_grefs[0];
--- kern-GENERIC ---
--- ichsmb.o ---
/tmp/bracket/build/2020.04.21.13.57.12-i386/tools/bin/nbctfconvert -g -L 
VERSION ichsmb.o
--- icp_pci.o ---
#   compile  GENERIC/icp_pci.o
/tmp/bracket/build/2020.04.21.13.57.12-i386/tools/bin/i486--netbsdelf-gcc 
-msoft-float -mno-mmx -mno-sse -mno-avx -mindirect-branch=thunk 
-mindirect-branch-register -ffreestanding -fno-zero-initialized-in-bss 
-fno-delete-null-pointer-checks -O2 -fno-omit-frame-pointer -fstack-protector 
-Wstack-protector --param ssp-buffer-size=1 -fno-strict-aliasing -fno-common 
-std=gnu99 -Werror -Wall -Wno-main -Wno-format-zero-length -Wpointer-arith 
-Wmissing-prototypes -Wstrict-prototypes -Wold-style-definition -Wswitch 
-Wshadow -Wcast-qual -Wwrite-strings -Wno-unreachable-code -Wno-pointer-sign 
-Wno-attributes -Wextra -Wno-unused-parameter -Wold-style-definition 
-Wno-sign-compare --sysroot=/tmp/bracket/build/2020.04.21.13.57.12-i386/destdir 
-Di386 -I. 
-I/tmp/bracket/build/2020.04.21.13.57.12-i386/src/sys/external/bsd/acpica/dist 
-I/tmp/bracket/build/2020.04.21.13.57.12-i386/src/sys/external/bsd/libnv/dist 
-I/tmp/bracket/build/2020.04.21.13.57.12-i386/src/sys/../common/lib/libx86emu 
-I/tmp/bra
 cket/build/2020.04.21.13.57.12-i386/src/sys/../common/lib/libc/misc 
-I/tmp/bracket/build/2020.04.21.13.57.12-i386/src/sys/../common/include 
-I/tmp/bracket/build/2020.04.21.13.57.12-i386/src/sys/arch 
-I/tmp/bracket/build/2020.04.21.13.57.12-i386/src/sys -nostdinc -DCOMPAT_UTILS 
-DDIAGNOSTIC -DCOMPAT_44 -D_KERNEL -D_KERNEL_OPT -std=gnu99 
-I/tmp/bracket/build/2020.04.21.13.57.12-i386/src/sys/lib/libkern/../../../common/lib/libc/quad
 
-I/tmp/bracket/build/2020.04.21.13.57.12-i386/src/sys/lib/libkern/../../../common/lib/libc/string
 
-I/tmp/bracket/build/2020.04.21.13.57.12-i386/src/sys/lib/libkern/../../../common/lib/libc/arch/i386/string
 -D_FORTIFY_SOURCE=2 
-I/tmp/bracket/build/2020.04.21.13.57.12-i386/src/sys/external/isc/atheros_hal/dist
 
-I/tmp/bracket/build/2020.04.21.13.57.12-i386/src/sys/external/isc/atheros_hal/ic
 
-I/tmp/bracket/build/2020.04.21.13.57.12-i386/src/sys/external/bsd/common/include
 
-I/tmp/bracket/build/2020.04.21.13.57.12-i386/src/sys/external/bsd/common/include
 -I/tmp/
 bracket/build/2020.04.21.13.57.12-i386/src/sys/external/bsd/drm2/include 
-I/tmp/bracket/build/2020.04.21.13.57.12-i386/src/sys/external/bsd/drm2/include 
-I/tmp/bracket/build/2020.04.21.13.57.12-i386/src/sys/external/bsd/drm2/include/drm
 
-I/tmp/bracket/build/2020.04.21.13.57.12-i386/src/sys/external/bsd/common/include
 
-I/tmp/bracket/build/2020.04.21.13.57.12-i386/src/sys/external/bsd/drm2/dist/include
 
-I/tmp/bracket/build/2020.04.21.13.57.12-i386/src/sys/external/bsd/drm2/dist/include/drm
 
-I/tmp/bracket/build/2020.04.21.13.57.12-i386/src/sys/external/bsd/drm2/dist/uapi
 -I/tmp/bracket/build/2020.04.21.13.57.12-i386/src/sys/external/bsd/drm2/dist 
-D__KERNEL__ -DCONFIG_BACKLIGHT_CLASS_DEVICE=0 
-DCONFIG_BACKLIGHT_CLASS_DEVICE_MODULE=0 -DCONFIG_DRM_FBDEV_EMULATION=1 
-DCONFIG_FB=0 
-I/tmp/bracket/build/2020.04.21.13.57.12-i386/src/sys/../common/include 
-I/tmp/bracket/build/2020.04.21.13.57.12-i386/src/sys/external/bsd/libnv/dist 
-I/tmp/bracket/build/2020.04.21.13.57.12-i386/src/sys/external
 /bsd/drm2/i915drm 
-I/tmp/bracket/build/2020.04.21.13.57.12-i386/src/sys/external/bsd/drm2/dist/drm/i915
 -DCONFIG_DRM_I915_FBDEV=1 -DCONFIG_DRM_I915_PRELIMINARY_HW_SUPPORT=0 
-DCONFIG_DRM_FBDEV_EMULATION=1 
-I/tmp/bracket/build/2020.04.21.13.57.12-i386/src/sys/external/bsd/drm2/include/radeon
 -I/tmp/bracket/build/2020.04.21.13.57.12-i386/src/sys/external/bsd/drm2/radeon 
-I/tmp/bracket/build/2020.04.21.13.57.12-i386/src/sys/external/bsd/drm2/dist/drm/amd/include
 
-I/tmp/bracket/build/2020.04.21.13.57.12-i386/src/sys/external/bsd/drm2/dist/drm/radeon
 
-I/tmp/bracket/build/2020.04.21.13.57.12-i386/src/sys/external/bsd/drm2/dist/drm/nouveau
 
-I/tmp/bracket/build/2020.04.21.13.57.12-i386/src/sys/external/bsd/drm2/dist/drm/nouveau/include
 
-I/tmp/bracket/build/2020.04.21.13.57.12-i386/src/sys/external/bsd/drm2/dist/drm/nouveau/include/nvkm
 
-I/tmp/bracket/build/2020.04.21.13.57.12-i386/src/sys/external/bsd/drm2/dist/drm/nouveau/nv

Automated report: NetBSD-current/i386 build success

2020-04-21 Thread NetBSD Test Fixture
The NetBSD-current/i386 build is working again.

The following commits were made between the last failed build and the
successful build:

2020.04.21.14.26.15 jdolecek src/doc/CHANGES,v 1.2676
2020.04.21.14.29.00 jdolecek src/doc/CHANGES,v 1.2677
2020.04.21.14.51.06 jdolecek src/sys/arch/xen/include/xenring.h,v 1.5
2020.04.21.15.04.12 christos src/sys/ufs/ffs/ffs_subr.c,v 1.52

Logs can be found at:


http://releng.NetBSD.org/b5reports/i386/commits-2020.04.html#2020.04.21.15.04.12


Aquantia AQC100 issues

2020-04-21 Thread Andrius V
Hi,

Recently I received Asus XG-C100F SFP+ network controller based on
Aquantia AQC100. Though, it's currently supported by aq(4) driver, I
believe it should be relatively easy to add. I tried to blindly add
the device to the list and even made it work, unfortunately with some
caveats. To make work I need to boot into the system first and
physically reattach the cable (I am using DAC). Even if cable is
attached and system boots, media type is not recognized and reports as
if link is missing, unless I physically reattach it. After that it
properly configures and dhcpcd assigns IP address. I can successfully
access the network. Any ideas why I need to reattach the cable?

Another issue likely unrelated to the driver itself since I had
similar issues previously: if integrated gigabit ethernet is
configured during boot as well and I am trying to put it down
(ifconfig re0 down), aq0 also stops "working" along with it and I
can't find the way to make it work besides reboot and making sure re0
is not configured (similar issue I had without vte0 and axen0,
including much slower transfer speed for axen0, if both working at the
same time). By that I mean that I can't reach network (even if
configuration seems correct). ifconfig aq0 down/up or dhcpcd
release/renew doesn't help, usually it just reassigns to some internal
IP.

Applied patch:
diff --git a/sys/dev/pci/if_aq.c b/sys/dev/pci/if_aq.c
index 02bbffbad31..caf6c81d4d0 100644
--- a/sys/dev/pci/if_aq.c
+++ b/sys/dev/pci/if_aq.c
@@ -1142,6 +1142,10 @@ static const struct aq_product {
enum aq_media_type aq_media_type;
aq_link_speed_t aq_available_rates;
 } aq_products[] = {
+   { PCI_VENDOR_AQUANTIA, PCI_PRODUCT_AQUANTIA_AQC100,
+ "Aquantia AQC100 10 Gigabit Network Adapter",
+ AQ_MEDIA_TYPE_FIBRE, AQ_LINK_ALL
+   },
{ PCI_VENDOR_AQUANTIA, PCI_PRODUCT_AQUANTIA_AQC107,
  "Aquantia AQC107 10 Gigabit Network Adapter",
  AQ_MEDIA_TYPE_TP, AQ_LINK_ALL
diff --git a/sys/dev/pci/pcidevs b/sys/dev/pci/pcidevs
index 4baa7573e4e..55e33a0a164 100644
--- a/sys/dev/pci/pcidevs
+++ b/sys/dev/pci/pcidevs
@@ -1289,6 +1289,7 @@ product APPLE INTREPID2_GMAC  0x006b  Intrepid 2 GMAC
 product APPLE BCM5701  0x1645  BCM5701

 /* Aquantia Corp. */
+product AQUANTIA AQC1000x00b1  AQC100 10 Gigabit
Network Adapter
 product AQUANTIA AQC1070x07b1  AQC107 10 Gigabit
Network Adapter
 product AQUANTIA AQC1080x08b1  AQC108 5 Gigabit Network Adapter
 product AQUANTIA AQC1090x09b1  AQC109 2.5 Gigabit
Network Adapter

Regards,
Andrius V


Re: Aquantia AQC100 issues

2020-04-21 Thread Andrius V
Mistyped in my original email: "Though, it's currently supported by
aq(4) driver" ->  "Though, it's currently not supported by aq(4)
driver"

On Wed, Apr 22, 2020 at 1:18 AM Andrius V  wrote:
>
> Hi,
>
> Recently I received Asus XG-C100F SFP+ network controller based on
> Aquantia AQC100. Though, it's currently supported by aq(4) driver, I
> believe it should be relatively easy to add. I tried to blindly add
> the device to the list and even made it work, unfortunately with some
> caveats. To make work I need to boot into the system first and
> physically reattach the cable (I am using DAC). Even if cable is
> attached and system boots, media type is not recognized and reports as
> if link is missing, unless I physically reattach it. After that it
> properly configures and dhcpcd assigns IP address. I can successfully
> access the network. Any ideas why I need to reattach the cable?
>
> Another issue likely unrelated to the driver itself since I had
> similar issues previously: if integrated gigabit ethernet is
> configured during boot as well and I am trying to put it down
> (ifconfig re0 down), aq0 also stops "working" along with it and I
> can't find the way to make it work besides reboot and making sure re0
> is not configured (similar issue I had without vte0 and axen0,
> including much slower transfer speed for axen0, if both working at the
> same time). By that I mean that I can't reach network (even if
> configuration seems correct). ifconfig aq0 down/up or dhcpcd
> release/renew doesn't help, usually it just reassigns to some internal
> IP.
>
> Applied patch:
> diff --git a/sys/dev/pci/if_aq.c b/sys/dev/pci/if_aq.c
> index 02bbffbad31..caf6c81d4d0 100644
> --- a/sys/dev/pci/if_aq.c
> +++ b/sys/dev/pci/if_aq.c
> @@ -1142,6 +1142,10 @@ static const struct aq_product {
> enum aq_media_type aq_media_type;
> aq_link_speed_t aq_available_rates;
>  } aq_products[] = {
> +   { PCI_VENDOR_AQUANTIA, PCI_PRODUCT_AQUANTIA_AQC100,
> + "Aquantia AQC100 10 Gigabit Network Adapter",
> + AQ_MEDIA_TYPE_FIBRE, AQ_LINK_ALL
> +   },
> { PCI_VENDOR_AQUANTIA, PCI_PRODUCT_AQUANTIA_AQC107,
>   "Aquantia AQC107 10 Gigabit Network Adapter",
>   AQ_MEDIA_TYPE_TP, AQ_LINK_ALL
> diff --git a/sys/dev/pci/pcidevs b/sys/dev/pci/pcidevs
> index 4baa7573e4e..55e33a0a164 100644
> --- a/sys/dev/pci/pcidevs
> +++ b/sys/dev/pci/pcidevs
> @@ -1289,6 +1289,7 @@ product APPLE INTREPID2_GMAC  0x006b  Intrepid 2 
> GMAC
>  product APPLE BCM5701  0x1645  BCM5701
>
>  /* Aquantia Corp. */
> +product AQUANTIA AQC1000x00b1  AQC100 10 Gigabit
> Network Adapter
>  product AQUANTIA AQC1070x07b1  AQC107 10 Gigabit
> Network Adapter
>  product AQUANTIA AQC1080x08b1  AQC108 5 Gigabit Network 
> Adapter
>  product AQUANTIA AQC1090x09b1  AQC109 2.5 Gigabit
> Network Adapter
>
> Regards,
> Andrius V


build failure in libz

2020-04-21 Thread Thomas Klausner
Hi!

I'm running a userland from 2020-04-12/amd64 when NetBSD built fine for me.

When I try building NetBSD-current now, it fails in libz with:


#   compile  libz/infback.o
gcc -O2   -std=gnu99-Wall -Wstrict-prototypes -Wmissing-prototypes 
-Wpointer-arith -Wno-sign-compare  -Wsystem-headers   -Wno-traditional   
-Wa,--fatal-warnings  -Wreturn-type -Wswitch -Wshadow -Wcast-qual 
-Wwrite-strings -Wextra -Wno-unused-parameter -Wno-sign-compare -Werror   -fPIE 
-fstack-protector -Wstack-protector   --param ssp-buffer-size=1
-I/usr/src/common/dist/zlib  -D_FORTIFY_SOURCE=2 -c -
Wno-error=implicit-fallthrough   /usr/src/common/dist/zlib/infback.c -o 
infback.o
/usr/src/common/dist/zlib/infback.c: In function ‘inflateBackInit_’:
/usr/src/common/dist/zlib/infback.c:69:12: error: ‘struct inflate_state’ has no 
member named ‘wnext’; did you mean ‘next’?
 state->wnext = 0;
^
next
/usr/src/common/dist/zlib/infback.c: In function ‘inflateBack’:
/usr/src/common/dist/zlib/infback.c:481:25: warning: this statement may fall 
through [-Wimplicit-fallthrough=]
 state->mode = LEN;
 ^
/usr/src/common/dist/zlib/infback.c:483:9: note: here
 case LEN:
 ^~~~
*** Error code 1


And

/usr/src/common/dist/zlib/inflate.c: In function 'inflateMark':
/usr/src/common/dist/zlib/inflate.c:1559:47: error: 'struct inflate_state' has 
no member named 'back'
 return (long)(((unsigned long)((long)state->back)) << 16) +
   ^~
/usr/src/common/dist/zlib/inflate.c:1561:44: error: 'struct inflate_state' has 
no member named 'was'; did you mean 'last'?
 (state->mode == MATCH ? state->was - state->length : 0));
^~~
last

I don't see a mail about this from the build bots, and I don't see any
relevant changes between April 12 and today (about an hour ago) that'd
explain it.

Any ideas?
 Thomas



Re: build failure in libz

2020-04-21 Thread Chavdar Ivanov
On Tue, 21 Apr 2020 at 23:42, Thomas Klausner  wrote:
>
> Hi!
>
> I'm running a userland from 2020-04-12/amd64 when NetBSD built fine for me.
>
> When I try building NetBSD-current now, it fails in libz with:
>
>
> #   compile  libz/infback.o
> gcc -O2   -std=gnu99-Wall -Wstrict-prototypes -Wmissing-prototypes 
> -Wpointer-arith -Wno-sign-compare  -Wsystem-headers   -Wno-traditional   
> -Wa,--fatal-warnings  -Wreturn-type -Wswitch -Wshadow -Wcast-qual 
> -Wwrite-strings -Wextra -Wno-unused-parameter -Wno-sign-compare -Werror   
> -fPIE -fstack-protector -Wstack-protector   --param ssp-buffer-size=1
> -I/usr/src/common/dist/zlib  -D_FORTIFY_SOURCE=2 -c -
> Wno-error=implicit-fallthrough   /usr/src/common/dist/zlib/infback.c -o 
> infback.o
> /usr/src/common/dist/zlib/infback.c: In function ‘inflateBackInit_’:
> /usr/src/common/dist/zlib/infback.c:69:12: error: ‘struct inflate_state’ has 
> no member named ‘wnext’; did you mean ‘next’?
>  state->wnext = 0;
> ^
> next
> /usr/src/common/dist/zlib/infback.c: In function ‘inflateBack’:
> /usr/src/common/dist/zlib/infback.c:481:25: warning: this statement may fall 
> through [-Wimplicit-fallthrough=]
>  state->mode = LEN;
>  ^
> /usr/src/common/dist/zlib/infback.c:483:9: note: here
>  case LEN:
>  ^~~~
> *** Error code 1
>
>
> And
>
> /usr/src/common/dist/zlib/inflate.c: In function 'inflateMark':
> /usr/src/common/dist/zlib/inflate.c:1559:47: error: 'struct inflate_state' 
> has no member named 'back'
>  return (long)(((unsigned long)((long)state->back)) << 16) +
>^~
> /usr/src/common/dist/zlib/inflate.c:1561:44: error: 'struct inflate_state' 
> has no member named 'was'; did you mean 'last'?
>  (state->mode == MATCH ? state->was - state->length : 0));
> ^~~
> last
>
> I don't see a mail about this from the build bots, and I don't see any
> relevant changes between April 12 and today (about an hour ago) that'd
> explain it.
>
> Any ideas?

When I get something like this, I usually 'make cleandir' in
/usr/[x]src and wipe the obj directory. This usually sorts things out.

I see similar error in my log from the 11th of April:

...
/home/sysbuild/src/tools/binutils/../../external/gpl3/binutils.old/dist/bfd/archive.c:860:30:
error: lvalue required as left operand of assignment
   bfd_is_thin_archive (abfd) = (strncmp (armag, ARMAGT, SARMAG) == 0);



Obviously a different place, but I did the above and my next build
completed fine, even if there was no cvs changes between the faulty
and the successful build, only the above action...

>  Thomas
>
Chavdar


-- 



panic: LOCKDEBUG: Mutex error: mutex_vector_enter,514: spin lock held

2020-04-21 Thread Paul Ripke
On -current as of ~yesterday, in a 1CPU amd64 qemu boot, I'm seeing:

Waiting for duplicate address detection to finish...
Starting dhcpcd.
dhcpcd-9.0.1 starting
unknown option:
[  17.0102686] wm0: link state UP (was UNKNOWN)
wm0: carrier acquired
unknown option:
[  17.1710186] pid 122 (dhcpcd), uid 35: exited on signal 11 (core not dumped, 
err = 1)
dhcpcd_fork_cb: truncated read 0 (expected 4)
/etc/rc.d/dhcpcd exited with code 1
Building databases: dev[  19.2211655] Mutex error: mutex_vector_enter,514: spin 
lock held

[  19.2211655] lock address : 0x81765a40 type :   spin
[  19.2211655] initialized  : 0x80a2690f
[  19.2211655] shared holds :  0 exclusive:  1
[  19.2211655] shares wanted:  0 exclusive:  0
[  19.2211655] relevant cpu :  0 last held:  0
[  19.2211655] relevant lwp : 0x80a57f71c2c0 last held: 0x80a57f71c2c0
[  19.2211655] last locked* : 0x80a24843 unlocked : 0x80a268e7
[  19.2211655] owner field  : 0x00010600 wait/spin:0/1

[  19.2211655] panic: LOCKDEBUG: Mutex error: mutex_vector_enter,514: spin lock 
held
[  19.2211655] cpu0: Begin traceback...
[  19.2211655] vpanic() at netbsd:vpanic+0x178
[  19.2211655] snprintf() at netbsd:snprintf
[  19.2211655] lockdebug_more() at netbsd:lockdebug_more
[  19.2211655] mutex_enter() at netbsd:mutex_enter+0x3c7
[  19.2211655] vmem_rehash_all() at netbsd:vmem_rehash_all+0x13a
[  19.2211655] workqueue_worker() at netbsd:workqueue_worker+0xe1
[  19.2211655] cpu0: End traceback...

Seems consistent between attempts.

Known? Meanwhile, I'll re-sync and try again.

BTW: the dhcpcd SEGV & errors seem to be another issue.

-- 
Paul Ripke
"Great minds discuss ideas, average minds discuss events, small minds
 discuss people."
-- Disputed: Often attributed to Eleanor Roosevelt. 1948.


daily CVS update output

2020-04-21 Thread NetBSD source update


Updating src tree:
P src/common/dist/zlib/CMakeLists.txt
P src/common/dist/zlib/ChangeLog
P src/common/dist/zlib/FAQ
P src/common/dist/zlib/INDEX
U src/common/dist/zlib/Makefile
P src/common/dist/zlib/Makefile.in
P src/common/dist/zlib/README
P src/common/dist/zlib/adler32.c
P src/common/dist/zlib/configure
P src/common/dist/zlib/crc32.h
P src/common/dist/zlib/gzclose.c
P src/common/dist/zlib/gzlib.c
P src/common/dist/zlib/gzread.c
P src/common/dist/zlib/inffast.h
P src/common/dist/zlib/inffixed.h
P src/common/dist/zlib/inflate.h
P src/common/dist/zlib/inftrees.h
P src/common/dist/zlib/make_vms.com
P src/common/dist/zlib/treebuild.xml
P src/common/dist/zlib/trees.h
P src/common/dist/zlib/zconf.h.cmakein
P src/common/dist/zlib/zconf.h.in
P src/common/dist/zlib/zlib.3
P src/common/dist/zlib/zlib.3.pdf
P src/common/dist/zlib/zlib.map
P src/common/dist/zlib/zlib.pc.cmakein
P src/common/dist/zlib/zlib.pc.in
P src/common/dist/zlib/zlib2ansi
P src/common/dist/zlib/amiga/Makefile.pup
P src/common/dist/zlib/amiga/Makefile.sas
P src/common/dist/zlib/contrib/README.contrib
P src/common/dist/zlib/contrib/ada/buffer_demo.adb
P src/common/dist/zlib/contrib/ada/mtest.adb
P src/common/dist/zlib/contrib/ada/read.adb
P src/common/dist/zlib/contrib/ada/readme.txt
P src/common/dist/zlib/contrib/ada/test.adb
P src/common/dist/zlib/contrib/ada/zlib-streams.adb
P src/common/dist/zlib/contrib/ada/zlib-streams.ads
P src/common/dist/zlib/contrib/ada/zlib-thin.adb
P src/common/dist/zlib/contrib/ada/zlib-thin.ads
P src/common/dist/zlib/contrib/ada/zlib.adb
P src/common/dist/zlib/contrib/ada/zlib.ads
P src/common/dist/zlib/contrib/ada/zlib.gpr
P src/common/dist/zlib/contrib/amd64/amd64-match.S
P src/common/dist/zlib/contrib/asm686/README.686
P src/common/dist/zlib/contrib/asm686/match.S
P src/common/dist/zlib/contrib/blast/Makefile
P src/common/dist/zlib/contrib/blast/README
P src/common/dist/zlib/contrib/blast/blast.c
P src/common/dist/zlib/contrib/blast/blast.h
U src/common/dist/zlib/contrib/blast/test.pk
U src/common/dist/zlib/contrib/blast/test.txt
P src/common/dist/zlib/contrib/delphi/ZLib.pas
P src/common/dist/zlib/contrib/delphi/ZLibConst.pas
P src/common/dist/zlib/contrib/delphi/readme.txt
P src/common/dist/zlib/contrib/delphi/zlibd32.mak
U src/common/dist/zlib/contrib/dotzlib/DotZLib.build
U src/common/dist/zlib/contrib/dotzlib/DotZLib.chm
P src/common/dist/zlib/contrib/dotzlib/DotZLib.sln
U src/common/dist/zlib/contrib/dotzlib/LICENSE_1_0.txt
P src/common/dist/zlib/contrib/dotzlib/readme.txt
P src/common/dist/zlib/contrib/gcc_gvmat64/gvmat64.S
P src/common/dist/zlib/contrib/infback9/README
P src/common/dist/zlib/contrib/infback9/infback9.c
P src/common/dist/zlib/contrib/infback9/infback9.h
P src/common/dist/zlib/contrib/infback9/inffix9.h
P src/common/dist/zlib/contrib/infback9/inflate9.h
P src/common/dist/zlib/contrib/infback9/inftree9.c
P src/common/dist/zlib/contrib/infback9/inftree9.h
P src/common/dist/zlib/contrib/inflate86/inffas86.c
P src/common/dist/zlib/contrib/inflate86/inffast.S
P src/common/dist/zlib/contrib/iostream/test.cpp
P src/common/dist/zlib/contrib/iostream/zfstream.cpp
P src/common/dist/zlib/contrib/iostream/zfstream.h
P src/common/dist/zlib/contrib/iostream2/zstream.h
P src/common/dist/zlib/contrib/iostream3/README
P src/common/dist/zlib/contrib/iostream3/TODO
P src/common/dist/zlib/contrib/iostream3/test.cc
P src/common/dist/zlib/contrib/iostream3/zfstream.cc
P src/common/dist/zlib/contrib/iostream3/zfstream.h
P src/common/dist/zlib/contrib/masmx64/bld_ml64.bat
P src/common/dist/zlib/contrib/masmx64/gvmat64.asm
P src/common/dist/zlib/contrib/masmx64/inffas8664.c
P src/common/dist/zlib/contrib/masmx64/inffasx64.asm
P src/common/dist/zlib/contrib/masmx64/readme.txt
U src/common/dist/zlib/contrib/masmx86/bld_ml32.bat
P src/common/dist/zlib/contrib/masmx86/inffas32.asm
P src/common/dist/zlib/contrib/masmx86/match686.asm
U src/common/dist/zlib/contrib/masmx86/readme.txt
P src/common/dist/zlib/contrib/minizip/Makefile
P src/common/dist/zlib/contrib/minizip/Makefile.am
P src/common/dist/zlib/contrib/minizip/MiniZip64_Changes.txt
P src/common/dist/zlib/contrib/minizip/MiniZip64_info.txt
P src/common/dist/zlib/contrib/minizip/configure.ac
P src/common/dist/zlib/contrib/minizip/crypt.h
P src/common/dist/zlib/contrib/minizip/ioapi.c
P src/common/dist/zlib/contrib/minizip/ioapi.h
P src/common/dist/zlib/contrib/minizip/iowin32.c
P src/common/dist/zlib/contrib/minizip/iowin32.h
P src/common/dist/zlib/contrib/minizip/make_vms.com
P src/common/dist/zlib/contrib/minizip/miniunz.c
P src/common/dist/zlib/contrib/minizip/miniunzip.1
P src/common/dist/zlib/contrib/minizip/minizip.1
P src/common/dist/zlib/contrib/minizip/minizip.c
P src/common/dist/zlib/contrib/minizip/minizip.pc.in
P src/common/dist/zlib/contrib/minizip/mztools.c
P src/common/dist/zlib/contrib/minizip/mztools.h
P src/common/dist/zlib/contrib/minizip/unzip.c
P src/common/dist/zlib/contrib/minizip/unzip.h
P src/common/dist/zlib/contrib/minizip/zip.c
P src/