Re: build fails with libblacklist
On Thu, Dec 31, 2015 at 11:30:12PM +0900, Rin Okuyama wrote:
> Building release fails with libblacklist:
Same here.
> % ./build.sh -U -j16 tools release
> ...
> --- libblacklist.so.0.0 ---
> # build lib/libblacklist.so.0.0
> rm -f libblacklist.so.0.0
> /var/build/tools/bin/x86_64--netbsd-gcc -Wl,-x -shared
> -Wl,-soname,libblacklist.so.0 -Wl,--warn-shared-textrel
> -Wl,-Map=libblacklist.so.0.map --sysroot=/var/build/dest/amd64 -o
> libblacklist.so.0.0 -Wl,-rpath,/lib -L=/lib -Wl,--whole-archive
> libblacklist_pic.a -Wl,--no-whole-archive -lpthread
>
> /var/build/tools/lib/gcc/x86_64--netbsd/4.8.5/../../../../x86_64--netbsd/bin/ld:
> cannot find -lpthread
> collect2: error: ld returned 1 exit status
> *** [libblacklist.so.0.0] Error code 1
> nbmake[7]: stopped in /var/build/src/external/bsd/blacklist/lib
>
> The attached patch fixes this problem.
I haven't tried it but it guess will work around the problem. But I don't
think it is the correct fix.
> (But why the absence of libpthread cannot be detected by DPADD macro?)
The problem is that "LIBPTHREAD" is documented in "bsd.README" but is
not set to anything as far as I can tell:
tron@lyssa:/usr/src/external/bsd/blacklist/lib>cvs diff -u
cvs diff: Diffing .
Index: Makefile
===
RCS file: /cvsroot/src/external/bsd/blacklist/lib/Makefile,v
retrieving revision 1.5
diff -u -r1.5 Makefile
--- Makefile30 Dec 2015 17:57:20 - 1.5
+++ Makefile1 Jan 2016 12:25:37 -
@@ -16,3 +16,8 @@
MLINKS+=libblacklist.3 blacklist_sa_r.3
.include
+
+print-stuff:
+ @echo "1:${DPADD}"
+ @echo "2:${LIBPTHREAD}"
+
tron@lyssa:/usr/src/external/bsd/blacklist/lib>make print-stuff
1: /usr/src/external/bsd/blacklist/lib/shlib_version
2:
I'm still investigating why it is not set. The problem is however not
specific to "external/bsd/blacklist". This variable isn't set anywhere
as far as I can tell:
tron@lyssa:/usr/src/external/gpl3/gcc/lib/libtsan>cvs diff -u
cvs diff: Diffing .
Index: Makefile
===
RCS file: /cvsroot/src/external/gpl3/gcc/lib/libtsan/Makefile,v
retrieving revision 1.2
diff -u -r1.2 Makefile
--- Makefile7 Jan 2015 03:49:13 - 1.2
+++ Makefile1 Jan 2016 12:27:12 -
@@ -65,3 +65,7 @@
DPADD+= ${LIBSTDCXX} ${LIBPTHREAD}
.include
+
+print-stuff:
+ @echo "1:${DPADD}"
+ @echo "2:${LIBPTHREAD}"
tron@lyssa:/usr/src/external/gpl3/gcc/lib/libtsan>make print-stuff
1: /usr/src/external/gpl3/gcc/lib/libtsan/shlib_version
2:
This library is just the only place where this causes a build problem
due to the ordering.
Kind regards
--
Matthias Scheler https://zhadum.org.uk/
HEADS UP: Postfix 2.11.6 imported
Hello,
I've imported Postfix 2.11.6 into NetBSD-current today. It builds and works
fine under NetBSD/amd64. Please submit a bug report with "send-pr" in
category "bin" if you find any problems.
Here is a list of the changes since version 2.11.4:
- Preparation for OpenSSL 1.2 API changes
- The sender_dependent_relayhost_maps feature ignored the relayhost setting
in the case of a DUNNO lookup result. It would use the recipient domain
instead.
- The default TLS settings no longer enable export-grade ciphers, and no
longer enable the SSLv2 and SSLv3 protocols. These ciphers and protocols
have little if any legitimate use today, and have instead become a
vehicle for downgrade attacks.
Kind regards
--
Matthias Scheler https://zhadum.org.uk/
signature.asc
Description: PGP signature
HEADS UP: Postfix 2.11.3 imported
Hello,
I've imported Postfix 2.11.3 into NetBSD-current today. It builds and works
fine under NetBSD/amd64. Please submit a bug report with send-pr in
category bin if you find any problems.
Here is a list of the major changes since version 2.11.1:
- Fix for DMARC implementations based on SPF policy plus DKIM Milter. The
PREPEND access/policy action added headers ABOVE Postfix's own Received:
header, exposing Postfix's own Received: header to Milters (protocol
violation) and hiding the PREPENDed header from Milters. PREPENDed headers
are now added BELOW Postfix's own Received: header and remain visible to
Milters.
- The Postfix SMTP server logged an incorrect client name in reject messages
for check_reverse_client_hostname_access and
check_reverse_client_hostname_{mx,ns}_access. They replied with the verified
client name, instead of the name that was rejected.
- The TLS client logged that an anonymous TLS connection was Untrusted,
instead of Anonymous.
- Fix for configurations that prepend message headers with Postfix access
maps, policy servers or Milter applications. Postfix now hides its own
Received: header from Milters and exposes prepended headers to Milters,
regardless of the mechanism used to prepend a header. This fix reverts
a partial solution that was released on October 13, 2014, and replaces
it with a complete solution.
Kind regards
--
Matthias Scheler https://zhadum.org.uk/
pgpcr7CcLwUO6.pgp
Description: PGP signature
Re: Removing openldap?
On Thu, Oct 02, 2014 at 10:25:38AM -0400, Thor Lancelot Simon wrote: openldap is used by postfix, sshd and amd. There is also pam-ldap in pkgsrc that we might want to import into base. All this is only using the client part of openldap. I would support removing the server parts of openldap but wonder whether this would actually reduce maintenance burden. We have never built the server, only the libraries and CLI tools. Kind regards -- Matthias Scheler https://zhadum.org.uk/
Re: gpt fails to compile as tool on amd64
On Fri, Oct 03, 2014 at 09:24:25AM +0200, Kurt Schreiner wrote: with -current source updated some minutes ago: Same here. Kind regards -- Matthias Scheler https://zhadum.org.uk/
Re: Removing openldap?
On Thu, Oct 02, 2014 at 09:37:36PM +0200, Hauke Fath wrote: On Thu, 02 Oct 2014 22:56:56 +0400, Aleksej Saushev wrote: openldap is used by postfix, sshd and amd. There is also pam-ldap in pkgsrc that we might want to import into base. All this is only using the client part of openldap. I'd like better intergration of LDAP with at least PAM and NSS modules. Yes, but Thomas' point (which I support) is that unless _you_ commit to doing it, it's not going to happen any time soon. But it already works. I'm writting this e-mail from a NetBSD/amd64 LDAP client. It is true that I have to use the NSS module and PAM from pkgsrc. But at least the auto mounter from base works out of the box: tron@lyssa:~cat /etc/amd.conf # Automounter configuration for lyssa.zhadum.org.uk [global] auto_attrcache = 1 ldap_base = dc=zhadum,dc=org,dc=uk ldap_hostports = zhadum.org.uk ldap_proto_version = 3 nfs_proto = udp search_path= /etc/amd unmount_on_exit= yes [ /home ] map_name = amd.home map_type = ldap [ /share ] map_name = amd.share map_type = ldap [ /scratch ] map_name = amd.scratch map_type = ldap [ /volumes ] map_name = volumes map_type = file And I wouldn't particular appreciate to lose this feature. Kind regards -- Matthias Scheler https://zhadum.org.uk/
Re: installboot broken on NetBSD/amd64?
On Fri, Sep 19, 2014 at 10:33:59AM +0200, Martin Husemann wrote: On Fri, Sep 19, 2014 at 09:25:52AM +0100, Matthias Scheler wrote: tron@lyssa:~#installboot -v /dev/rwd0a /usr/mdec/bootxx_ffsv1 installboot: Opening file system `/dev/rwd0a' read-write: Device busy This is fallout from the wedges auto-configuration changes. I'll submit a PR. You should be able (in this particular case) to identify the dk device corresponding to wd0a and use that instead, but for some other uses of installboot (think rwd0c on architectures with MBR support) no such workaround will be available. Thanks, but I don't need a workaround urgently. The old bootblock works fine for now. Kind regards -- Matthias Scheler https://zhadum.org.uk/
Re: cvs update stopped by missing file or directory
On Tue, Jul 22, 2014 at 12:57:36PM +, Thomas Mueller wrote: I tried to update source tree but was stopped by cvs [update aborted]: cannot open directory /cvsroot/src/external/mit/lua/src: No such file or directory Is something temporarily missing at the server end, or did something get screwed at my end? I had the same problem yesterday. The repository was changed in an unsafe manner after a CVS import into the wrong directory. The easiest way to fix this is to remove src/external/mit/lua in your CVS checkout and run cvs update again. Kind regards -- Matthias Scheler https://zhadum.org.uk/
More documentation related build failures
Hello, current builds still fail for me: # install docinstall /src/tools/bin/x86_64--netbsd-install -U -M /export/scratch/tron/obj/destdir.amd64/METALOG -D /export/scratch/tron/obj/destdir.amd64 -h sha256 -N /src/NetBSD-current/src/etc -c -p -r -o root -g wheel -m 444 sysman1.png /export/scratch/tron/obj/destdir.amd64/usr/share/doc/reference/ref3/sysman/sysman1.png x86_64--netbsd-install: sysman1.png: stat: No such file or directory *** [docinstall] Error code 1 nbmake[7]: stopped in /src/NetBSD-current/src/share/doc/psd/05.sysman 1 error It seems that these files are missing from src/share/doc/psd/05.sysman. Kind regards -- Matthias Scheler https://zhadum.org.uk/
HEADS UP: Postfix 2.11.1 imported
Hello, I've imported Postfix 2.11.1 into NetBSD-current today. It builds and works fine under NetBSD/amd64. Please submit a bug report with send-pr in category bin if you find any problems. Here is a list of the major changes since version 2.10.3: - Support for PKI-less TLS server certificate verification with DANE (DNS-based Authentication of Named Entities) where the CA public key or the server certificate is identified via DNSSEC lookup. This requires a DNS resolver that validates DNSSEC replies. The problem with conventional PKI is that there are literally hundreds of organizations world-wide that can provide a certificate in anyone's name. DANE limits trust to the people who control the target DNS zone and its parent zones. - A new postscreen_dnsbl_whitelist_threshold feature to allow clients to skip postscreen tests based on their DNSBL score. This can eliminate email delays due to after 220 greeting protocol tests, which otherwise require that a client reconnects before it can deliver mail. Some providers such as Google don't retry from the same IP address, and that can result in large email delivery delays. - The recipient_delimiter feature now supports different delimiters, for example both + and -. As before, this implementation recognizes exactly one delimiter character per email address, and exactly one address extension per email address. - Advanced master.cf query/update support to access service attributes as name = value pairs. For example to turn off chroot on all services use postconf -F '*/*/chroot = n', and to change/add a -o name=value setting use postconf -P 'smtp/inet/name = value'. This was developed primarily to allow automated tools to manage Postfix systems without having to parse Postfix configuration files. Kind regards -- Matthias Scheler https://zhadum.org.uk/ pgpNUNQIffTVO.pgp Description: PGP signature
Re: build failure amd64 -current
On Wed, May 28, 2014 at 01:37:45PM -0700, B Harder wrote: [...] # link amd/amd /usr/src/obj/tooldir.NetBSD-6.99.43-amd64/bin/x86_64--netbsd-gcc --sysroot=/usr/src/obj/destdir.amd64 -o amd am_ops.o amd.o amfs_auto.o amfs_generic.o amfs_direct.o amfs_error.o amfs_host.o amfs_link.o amfs_linkx.o amfs_nfsl.o amfs_nfsx.o amfs_program.o amfs_root.o amfs_toplvl.o amfs_union.o amq_sub r.o amq_svc.o autil.o clock.o conf.o get_args.o info_exec.o info_file.o info_ndbm.o info_passwd.o info_sun.o info_union.o map.o mapc.o mntfs.o nfs_prot_svc.o nfs_start.o nfs_subr.o ops_cdfs.o ops_efs.o ops_mfs.o ops_nfs.o ops_nfs3.o ops_nullfs.o ops_pcfs.o ops_tfs.o ops_tmpfs.o ops_udf.o ops_ufs.o ops_umapf s.o ops_unionfs.o opts.o readdir.o restart.o rpc_fwd.o sched.o srvr_amfs_auto.o srvr_nfs.o sun_map.o sun_map_parse.o sun_map_tok.o conf_parse.o conf_tok.o info_hesiod.o info_ldap.o info_nis.o -Wl,-rpath-link,/usr/src/obj/destdir.amd64/lib -L=/lib -lldap -lrpcsvc -L/usr/src/external/bsd/am-utils/lib/libamu /obj -lamu --- dependall-crypto/external --- --- dependall --- --- dependall --- --- dependall-bin --- dependall === crypto/external/bsd/openssl/bin --- dependall --- --- dependall-external --- --- dependall-acpica --- --- dependall --- --- dependall --- --- dependall-am-utils --- --- dependall-amq --- dependall === external/bsd/am-utils/bin/amq --- dependall-amd --- /usr/obj/tooldir.NetBSD-6.99.43-amd64/bin/../lib/gcc/x86_64--netbsd/4.8.3/../../../../x86_64--netbsd/bin/ld: conf.o: bad reloc symbol index (0x1b883 = 0x65) for offset 0xd0850fc085ff in section `.text' Works for me(TM) This could be related to the OpenLDAP update that I imported today. But after Matthew Green fixed the GCC 4.8.3 problems a full build works fine for me (even with USE_SSP set to yes). Kind regards -- Matthias Scheler https://zhadum.org.uk/
Re: gd packages fails to build under NetBSD/amd64 current
On Sun, Mar 23, 2014 at 07:55:05PM +, Matthias Scheler wrote:
So, no more xx, but somehow the substitution to ${PKGCONFIG_REQUIRES}
hasn't happened for me...
Finally : I needed
cd /usr/src/external/mit/xorg/lib/fontconfig/src make distclean
to get rid of the fontconfig.pc file, so it gets rebuilt. make clean
isn't enough. Now:
Name: Fontconfig
Description: Font configuration and customization library
Version: 2.11.0
Requires:
Requires.private:
Libs: -Wl,-rpath,${libdir} -L${libdir} -lfontconfig
Libs.private: -lexpat -lfreetype
Cflags: -I${includedir} -I/usr/X11R7/include/freetype2
-I/usr/X11R7/include
So ryoon's patches are all that is needed...
I get this:
tron@lyssa:/usr/pkgsrc/graphics/gd#cat /usr/X11R7/lib/pkgconfig/fontconfig.pc
prefix=/usr/X11R7
exec_prefix=${prefix}
libdir=${prefix}/lib
includedir=${prefix}/include
sysconfdir=@sysconfdir@
localstatedir=@localstatedir@
PACKAGE=
confdir=@baseconfigdir@
cachedir=@fc_cachedir@
Matthew Green has fixed this.
The first part still doesn't look right and the gd package still
fails to detect fontconfig.
This seems to be a problem with pkgsrc which I'm currently fixing.
Kind regards
--
Matthias Scheler https://zhadum.org.uk/
Re: gd packages fails to build under NetBSD/amd64 current
On Sun, Mar 23, 2014 at 05:53:39PM +, Matthias Scheler wrote:
I cannot build pkgsrc/graphics/gd on my NetBSD/amd64 system using
current with native X11 from today:
checking for deflate in -lz... yes
checking libpng-config script... /usr/pkg/bin/libpng-config, cflags:
-I/usr/pkg/include/libpng16, libs: -Wl,-R/usr/pkg/lib -L/usr/pkg/lib -lpng16
checking for FcInit in -lfontconfig... no
configure: error: fontconfig support requested, but not found
*** Error code 1
Is anybody else seeing this?
I think I found the cause /usr/X11R7/lib/pkgconfig/fontconfig.pc
looks broken:
prefix=/usr/X11R7
exec_prefix=${prefix}
libdir=${prefix}/lib
includedir=${prefix}/include
sysconfdir=@sysconfdir@
localstatedir=@localstatedir@
PACKAGE=
confdir=@baseconfigdir@
cachedir=@fc_cachedir@
Name: Fontconfig
Description: Font configuration and customization library
Version: 2.11.0
Requires: xx
Requires.private: xx
Libs: -Wl,-rpath,${libdir} -L${libdir} -lfontconfig
Libs.private: -lexpat -lfreetype
Cflags: -I${includedir} -I/usr/X11R7/include/freetype2 -I/usr/X11R7/include
/usr/X11R7/lib/pkgconfig/pthread-stubs.pc doesn't look correct as well.
Kind regards
--
Matthias Scheler https://zhadum.org.uk/
Re: NetBSD current native xorg's freetype2.pc
On Sun, Mar 23, 2014 at 08:17:40AM +0900, Ryo ONODERA wrote: freetype2.pc (pkg-config) of NetBSD current native xorg has wrong xx string in its flags. And it causes build error with pkgsrc packages that use freetype2. With following patch, I can build firefox etc. (Patches in http://mail-index.netbsd.org/tech-pkg/2014/03/22/msg012810.html are also needed for pkgsrc.) Thanks a lot. I've committed your patch. Kind regards -- Matthias Scheler https://zhadum.org.uk/
Re: gd packages fails to build under NetBSD/amd64 current
On Sun, Mar 23, 2014 at 06:34:09PM +, Patrick Welche wrote:
This is fixed by ryoon's patch in
http://mail-index.netbsd.org/current-users/2014/03/22/msg024499.html
Seems broken in a different way:
Requires: @PKGCONFIG_REQUIRES@
Requires.private: @PKGCONFIG_REQUIRES_PRIVATELY@
So, no more xx, but somehow the substitution to ${PKGCONFIG_REQUIRES}
hasn't happened for me...
Finally : I needed
cd /usr/src/external/mit/xorg/lib/fontconfig/src make distclean
to get rid of the fontconfig.pc file, so it gets rebuilt. make clean
isn't enough. Now:
Name: Fontconfig
Description: Font configuration and customization library
Version: 2.11.0
Requires:
Requires.private:
Libs: -Wl,-rpath,${libdir} -L${libdir} -lfontconfig
Libs.private: -lexpat -lfreetype
Cflags: -I${includedir} -I/usr/X11R7/include/freetype2 -I/usr/X11R7/include
So ryoon's patches are all that is needed...
I get this:
tron@lyssa:/usr/pkgsrc/graphics/gd#cat /usr/X11R7/lib/pkgconfig/fontconfig.pc
prefix=/usr/X11R7
exec_prefix=${prefix}
libdir=${prefix}/lib
includedir=${prefix}/include
sysconfdir=@sysconfdir@
localstatedir=@localstatedir@
PACKAGE=
confdir=@baseconfigdir@
cachedir=@fc_cachedir@
Name: Fontconfig
Description: Font configuration and customization library
Version: 2.11.0
Requires:
Requires.private:
Libs: -Wl,-rpath,${libdir} -L${libdir} -lfontconfig
Libs.private: -lexpat -lfreetype
Cflags: -I${includedir} -I/usr/X11R7/include/freetype2 -I/usr/X11R7/include
The first part still doesn't look right and the gd package still
fails to detect fontconfig.
Kind regards
--
Matthias Scheler https://zhadum.org.uk/
Re: 82599EB 10-Gigabit not detected
On Thu, Mar 20, 2014 at 10:26:25AM +0100, 6b...@6bone.informatik.uni-leipzig.de wrote: You could try to get your card to work by changing the array ixgbe_vendor_info_array in src/sys/dev/pci/ixgbe/ixgbe.c. You add an entry for your card with the correct PCI device it it might just work. The reported device-id is: Ethernet controller [0200]: Intel Corporation 82599EB 10-Gigabit SFP+ Network Connection [8086:154d] (rev 01) I will test to change the array. Please let us know whether that made the card work for you. Thank you for your efforts You are welcome. Kind regards -- Matthias Scheler https://zhadum.org.uk/
Re: libgomp not protecting local variables: variable length buffer for past few days
On Tue, Mar 04, 2014 at 10:08:19AM -0800, B Harder wrote: Yes, I have USE_SSP=yes in /etc/mk/conf. cc1: warnings being treated as errors /usr/src/external/gpl3/gcc.old/dist/libgomp/task.c: In function 'GOMP_task': /usr/src/external/gpl3/gcc.old/dist/libgomp/task.c:79:1: error: not protecting local variables: variable length buffer *** [task.pico] Error code 1 nbmake[6]: stopped in /usr/src/external/gpl3/gcc.old/lib/libgomp That should be fixed now. Kind regards -- Matthias Scheler https://zhadum.org.uk/
Re: RTL8168G
On Mon, Dec 16, 2013 at 05:44:34PM -0600, Jonathan A. Kollasch wrote: On Sun, Dec 15, 2013 at 09:57:59AM -0600, Jonathan A. Kollasch wrote: I ported the changes in FreeBSD SVN r257305 that add support for RTL8168G. This works except for the RX path. When I netboot; an unpatched NetBSD re(4) works for TX and RX. Any ideas? Jonathan Kollasch This (attached) patch works. I'm completely aware it's uncommittable as it it is. FreeBSD's re(4) driver now supports RX on these chips: http://lists.freebsd.org/pipermail/svn-src-head/2014-February/055784.html Kind regards -- Matthias Scheler https://zhadum.org.uk/
Re: librumphijack build failure
On Sat, Jan 18, 2014 at 04:31:39PM -0800, B Harder wrote: I'm building via: ./build.sh -x -j2 distribution from up-to-the-minute sources, and it's been failing consistently... Are you setting USE_SSP to yes in /etc/mk.conf? Yes, I am. That is what triggered the build failure. I've fixed the problem now: http://mail-index.netbsd.org/source-changes/2014/01/18/msg050976.html Kind regards -- Matthias Scheler http://zhadum.org.uk/
Re: librumphijack build failure
On Sat, Jan 18, 2014 at 06:07:50PM +, Matthias Scheler wrote: On Thu, Jan 16, 2014 at 02:03:48PM -0800, B Harder wrote: Is anybody else experiencing this ? Yes. I'm building via: ./build.sh -x -j2 distribution from up-to-the-minute sources, and it's been failing consistently... Are you setting USE_SSP to yes in /etc/mk.conf? I believe that I have fixed this problem now. Kind regards -- Matthias Scheler http://zhadum.org.uk/
HEADS UP: Postfix 2.10.3 imported
Hello, I've imported Postfix 2.10.3 into NetBSD-current today. It builds and works fine under NetBSD/amd64. Please submit a bug report with send-pr in category bin if you find any problems. Here is a list of the major changes since version 2.10.2: - Future proofing against OpenSSL library API changes. When support for a bug workaround is removed from OpenSSL, the corresponding named bit in tls_disable_workarounds will be ignored instead of causing existing Postfix configurations to fail. - The postconf '-#' option reset prior options instead of adding to them. - Correct an error in MULTI_INSTANCE_README Makefile example. - Correct an error in SASL_README PostgreSQL example. - Correct a malformed error message in conf/post-install. Kind regards -- Matthias Scheler http://zhadum.org.uk/ pgpXCRn9V13Zl.pgp Description: PGP signature
Re: READ ME: updating mpc, mpfr, and eventually gmp
On Sun, Dec 15, 2013 at 11:34:39AM +, Thomas Mueller wrote: My /etc/mk.conf is geared to pkgsrc, I don't see anything relevant to building the system. If you encapsulate the pkgsrc settings in a block like this ... .if defined(BSD_PKG_MK) [...] .endif ... you can be sure that they don't affect the base system build. Kind regards -- Matthias Scheler http://zhadum.org.uk/
Re: READ ME: updating mpc, mpfr, and eventually gmp
On Mon, Dec 16, 2013 at 12:49:23PM +, Thomas Mueller wrote: clean out the tools directory means to remove the -T directory, i.e. ../tooldir.amd64.llvm in your case. That's what I first thought, but I was beginning to wonder if I need to do a new cvs checkout or update after deleting entire source tree. I've removed the tooldir before, but no recent success. What file-system are you using for the /tmp on your build machine? There have been bugs in tmpfs which have been recently fixed. So if you are using tmpfs please try without. Kind regards -- Matthias Scheler http://zhadum.org.uk/
Re: RTL8168G
On Sun, Dec 15, 2013 at 11:17:00AM -0600, Jonathan A. Kollasch wrote: On Sun, Dec 15, 2013 at 09:57:59AM -0600, Jonathan A. Kollasch wrote: I ported the changes in FreeBSD SVN r257305 that add support for RTL8168G. This works except for the RX path. When I netboot; an unpatched NetBSD re(4) works for TX and RX. Any ideas? Jonathan Kollasch For complete posterity; patch attached. The Linux driver uploads a new firmware to an 8169G. And if that doesn't happen the chip doesn't seem to work. NetBSD 6.1_STABLE, Debian 7.0 and Ubuntu 12.04 LTS all can bring the card up but not receive packets. Ubuntu 13.04 (and 13.10) work after the firmware (which is part of the Linux kernel tree) has been uploaded. Your BIOS might upload the firmware in case of a netboot but not in case of a normal boot. Kind regards -- Matthias Scheler http://zhadum.org.uk/
Re: IPv6 connectivy problems, with tcpdump
On Thu, Oct 10, 2013 at 02:10:13PM +0200, Reinoud Zandijk wrote: Could you please take a look at the trace and/or give me some pointers as how to debug this? Is this a problem at my ISP provided modem? Or is it upstream my ISP ? The tcpdump is at: http://pastebin.com/3MPg6qnE Can you please provide a .pcap packet capture file created e.g. with tcpdump -w ipv6.pcap ...? Kind regards -- Matthias Scheler http://zhadum.org.uk/
Re: emacs-24.3: test request
On Mon, Sep 09, 2013 at 08:48:02AM +0100, Matthias Scheler wrote:
On Mon, Sep 09, 2013 at 12:20:07AM +0200, Rhialto wrote:
On Mon 09 Sep 2013 at 02:07:46 +0400, Valery Ushakov wrote:
and I think it has to be reverted, since you can't do g/c if you don't
know all roots.
On the other hand, is there any official documentation that says that
what emacs is doing is allowed?
The exact behaviour of the environment vector is not very documented.
And there are lot of implementations with various incorrect behaviours
like putenv(3) on older version of NetBSD.
If the garbage collection code causes problems it should be removed.
On a second thought I think that emacs is indeed broken. The scrubbing
of the environment is not the only problem it can trigger. If it sets
environ to its own array and calls e.g. setenv(3) it can also
trigger this case in src/lib/libc/stdlib/_env.c if the new environment
vector is full.
/* Allocate a new environment array. */
if (environ == allocated_environ) {
[...]
} else {
free(allocated_environ);
allocated_environ = NULL;
allocated_environ_size = 0;
[...]
}
So by the time emacs restores the original pointer libc might have
freed the memory it points to.
emacs should be fixed.
Kind regards
--
Matthias Scheler http://zhadum.org.uk/
Re: emacs-24.3: test request
On Mon, Sep 09, 2013 at 09:03:29AM +0100, Matthias Scheler wrote:
On the other hand, is there any official documentation that says that
what emacs is doing is allowed?
The exact behaviour of the environment vector is not very documented.
And there are lot of implementations with various incorrect behaviours
like putenv(3) on older version of NetBSD.
If the garbage collection code causes problems it should be removed.
On a second thought I think that emacs is indeed broken. The scrubbing
of the environment is not the only problem it can trigger. If it sets
environ to its own array and calls e.g. setenv(3) it can also
trigger this case in src/lib/libc/stdlib/_env.c if the new environment
vector is full.
/* Allocate a new environment array. */
if (environ == allocated_environ) {
[...]
} else {
free(allocated_environ);
allocated_environ = NULL;
allocated_environ_size = 0;
[...]
}
So by the time emacs restores the original pointer libc might have
freed the memory it points to.
Looking at emacs's code it seems to carefully avoid that by creating
a large enough environment vector and copying all the contents.
I think the problem can be avoided by never scrubbing the environment
within calls to getenv(3). I'm currently testing such a change.
Kind regards
--
Matthias Scheler http://zhadum.org.uk/
Re: emacs-24.3: test request
On Mon, Sep 09, 2013 at 11:05:20AM +0100, Matthias Scheler wrote:
On Mon, Sep 09, 2013 at 09:03:29AM +0100, Matthias Scheler wrote:
On the other hand, is there any official documentation that says that
what emacs is doing is allowed?
The exact behaviour of the environment vector is not very documented.
And there are lot of implementations with various incorrect behaviours
like putenv(3) on older version of NetBSD.
If the garbage collection code causes problems it should be removed.
On a second thought I think that emacs is indeed broken. The scrubbing
of the environment is not the only problem it can trigger. If it sets
environ to its own array and calls e.g. setenv(3) it can also
trigger this case in src/lib/libc/stdlib/_env.c if the new environment
vector is full.
/* Allocate a new environment array. */
if (environ == allocated_environ) {
[...]
} else {
free(allocated_environ);
allocated_environ = NULL;
allocated_environ_size = 0;
[...]
}
So by the time emacs restores the original pointer libc might have
freed the memory it points to.
Looking at emacs's code it seems to carefully avoid that by creating
a large enough environment vector and copying all the contents.
I think the problem can be avoided by never scrubbing the environment
within calls to getenv(3). I'm currently testing such a change.
I've committed a fix earlier:
- Forwarded message from Matthias Scheler t...@netbsd.org -
Module Name:src
Committed By: tron
Date: Mon Sep 9 10:21:28 UTC 2013
Modified Files:
src/lib/libc/stdlib: _env.c
Log Message:
Don't scrub the environment unless we are going to change it. This should
prevent crashes in applications which carefully and manually construct
a temporary environment and later restore the original environment
like Emacs 24.
Problem reported by Thomas Klausner on pkgsrc-users mailing list.
To generate a diff of this commit:
cvs rdiff -u -r1.7 -r1.8 src/lib/libc/stdlib/_env.c
- End forwarded message -
I would appreciate if somebody who could reproduce the original problem
could try this fix.
Kind regards
--
Matthias Scheler http://zhadum.org.uk/
Re: emacs-24.3: test request
On Mon, Sep 09, 2013 at 09:30:43PM +0200, Thomas Klausner wrote: On Mon, 9 Sep 2013 18:04:44 +0100 Matthias Scheler t...@zhadum.org.uk wrote: cvs rdiff -u -r1.7 -r1.8 src/lib/libc/stdlib/_env.c [...] I would appreciate if somebody who could reproduce the original problem could try this fix. Before: $ emacs Makefile Fatal error 11: Segmentation fault Backtrace: 0x812b70b XSetWMNormalHints+0x22016 at emacs 0x81114d2 XSetWMNormalHints+0x7ddd at emacs 0x812a149 XSetWMNormalHints+0x20a54 at emacs 0x812a222 XSetWMNormalHints+0x20b2d at emacs Segmentation fault (core dumped) After: it works. So it helps, thanks! Thanks for handling this so promptly! Works for me too. Thanks for debugging this, Valeriy, and for fixing this, Matthias! Thanks for testing it so quickly. I'm going to submit a pullup request as well. Kind regards -- Matthias Scheler http://zhadum.org.uk/
HEADS UP: Postfix 2.9.7 imported
Hello, I've imported Postfix 2.9.7 into NetBSD-current today. It builds and works fine under NetBSD/i386. Please submit a bug report with send-pr in category bin if you find any problems. Here is a list of changes since version 2.9.5: - Thanks to OpenSSL documentation, the Postfix 2.9.0..2.9.5 SMTP client and server used an incorrect procedure to compute TLS certificate PUBLIC-KEY fingerprints (these may be used in the check_ccert_access and in smtp_tls_policy_maps features). Support for certificate PUBLIC-KEY finger prints was introduced with Postfix 2.9; there is no known problem with the certificate fingerprint algorithms available since Postfix 2.2. Specify tls_legacy_public_key_fingerprints = yes temporarily, pending a migration from configuration files with incorrect Postfix 2.9.0..2.9.5 certificate PUBLIC-KEY finger prints, to the correct fingerprints used by Postfix 2.9.6 and later. - Bugfix (introduced: Postfix 2.0): when myhostname is not listed in mydestination, the trivial-rewrite resolver may log do not list in both mydestination and . The fix is to re-resolve a domain-less address after adding $myhostname as the surrogate domain, so that it pops out with the right address-class label. Reported by Quanah Gibson-Mount. - Bugfix (introduced: Postfix 2.3): don't reuse TCP connections when smtp_tls_policy_maps is specified. TLS policies may depend on the remote destination, but the Postfix 2.11 SMTP connection cache client does not distinguish between different destinations that resolve to the same IP address. Victor Duchovni. Found during Postfix 2.11 code maintenance. - Bugfix (introduced: Postfix 2.2): don't reuse TCP connections when SASL authentication is enabled. SASL passwords may depend on the remote SMTP server hostname, but the Postfix 2.11 SMTP connection cache client does not distinguish between different hostnames that resolve to the same IP address. Found during Postfix 2.11 code maintenance. Kind regards -- Matthias Scheler http://zhadum.org.uk/ pgpAmYWDwkIn1.pgp Description: PGP signature
Re: amd64 build is broken - makefs
On Tue, Aug 06, 2013 at 11:42:37AM -0700, Paul Goyette wrote: With sources updated on 2013-08-06 at 18:20:00 UTC (about 90 minutes ago) # link makefs/makefs cc -O -I. -I/test-bed/tools/include/nbinclude -I/test-bed/tools/include -I/test-bed/tools/include/nbinclude -I/test-bed/tools/include/compat -I/test-bed/src/tools/compat -DHAVE_NBTOOL_CONFIG_H=1 -D_FILE_OFFSET_BITS=64 -I/test-bed/src/tools/makefs/../../usr.sbin/makefs -I/test-bed/src/sbin/mknod -I/test-bed/src/usr.sbin/mtree -DMAKEFS -I/test-bed/src/sys/fs/cd9660 -I/test-bed/src/sys/ufs/chfs -DV7FS_EI -I/test-bed/src/sys/fs/v7fs -I/test-bed/src/sbin/newfs_v7fs -I/test-bed/src/sbin/fsck -DMSDOS_EI -I/test-bed/src/sys/fs/msdosfs -I/test-bed/src/sbin/newfs_msdos -I/test-bed/src/sys/fs/udf -I/test-bed/src/sbin/newfs_udf -I/test-bed/src/sbin/fsck -o makefs cd9660.lo chfs.lo ffs.lo v7fs.lo msdos.lo udf.lo getid.lo makefs.lo misc.lo pack_dev.lo spec.lo walk.lo cd9660_strings.lo cd9660_debug.lo cd9660_eltorito.lo cd9660_write.lo cd9660_conversion.lo iso9660_rrip.lo cd9660_archimedes.lo chfs_mkfs.lo ffs_alloc.lo ffs_balloc.lo ffs_bswap.lo ffs_subr.lo ffs_tables.lo ufs_bmap.lo buf.lo mkfs.lo v7fs_endian.lo v7fs_superblock.lo v7fs_superblock_util.lo v7fs_inode.lo v7fs_inode_util.lo v7fs_datablock.lo v7fs_dirent.lo v7fs_io.lo v7fs_file.lo v7fs_file_util.lo v7fs_io_user.lo main.lo v7fs_estimate.lo v7fs_populate.lo mkfs_msdos.lo msdosfs_fat.lo msdosfs_conv.lo msdosfs_vfsops.lo msdosfs_lookup.lo msdosfs_denode.lo msdosfs_vnops.lo udf_create.lo udf_write.lo udf_osta.lo -L/test-bed/tools/lib -lnbcompat -lz udf.lo: In function `udf_makefs': udf.c:(.text+0x1ded): undefined reference to `snprintb' Same here for NetBSD/i386. Kind regards -- Matthias Scheler http://zhadum.org.uk/
Porting an OpenBSD ethernet driver
Hello, has anybodu a guide for porting an OpenBSD ethernet driver (in my case vmx(3))? I'm struggling because OpenBSD's arp management seems to be quite different. Kind regards -- Matthias Scheler http://zhadum.org.uk/
