Re: rpcbind does not honor -h flag

[Борис Самородов]

01.09.2012 18:42, Kurt Jaeger пишет:

Hi!


  Please file a PR against rc ASAP.



http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/117711



Looks like Matteo Riondato had created a patch for the problem in 2008:

http://people.freebsd.org/~matteo/diff/117711rpcbind.diff

but he never received any feedback from Carlos Eduardo Monti to see if
the patch fixed the problem.



I don't know if the patch will apply to the current FreeBSD rpcbind
code, give it a try and submit a follow up to the PR.


In the current form the patch fails in rpcbind.c on 9.1-RC1.

There are two problems with the current rpcbind.c.

1) It seems to be that even if some -h is given, the
rpcbind code uses some SUN-RPC trickery around the /etc/netconfig
file to open sockets for localhost in v4 and v6.

Is it required to bind to localhost according to the RPC spec ?

2) And it opens some dynamic ports for other uses -- anybody has an
idea why this is necessary ? Is there an requirement for this in the spec ?

Below is an example of both issues.

root rpcbind2134  4  udp6   *:*   *:*
root rpcbind2134  5  stream /var/run/rpcbind.sock
root rpcbind2134  6  udp6   *:111 *:*
root rpcbind2134  7  udp6   *:924 *:*
root rpcbind2134  8  tcp6   *:111 *:*
root rpcbind2134  9  udp4   *:111 *:*
root rpcbind2134  10 udp4   *:645 *:*
root rpcbind2134  11 tcp4   *:111 *:*

Here's rpcbind started with -h myip:

root rpcbind2195  4  udp6   *:*   *:*
root rpcbind2195  5  stream /var/run/rpcbind.sock
root rpcbind2195  6  udp6   ::1:111   *:*
root rpcbind2195  7  udp6   *:1013*:*
root rpcbind2195  8  tcp6   ::1:111   *:*
root rpcbind2195  9  udp4   127.0.0.1:111 *:*
root rpcbind2195  10 udp4   myip:111*:*
root rpcbind2195  11 udp4   *:634 *:*
root rpcbind2195  12 tcp4   127.0.0.1:111 *:*
root rpcbind2195  13 tcp4   myip:111*:*

One can see two dynamic udp ports opened (one v4, one v6).

I might be naive, but from what I understand, it should not open
that many sockets, but only like this:

root rpcbind2195  10 udp4   myip:111*:*
root rpcbind2195  13 tcp4   myip:111*:*

If this naive 'spec' is correct, would a patch to do just this and
nothing more be OK ?


Patches are always welcome. But please read RPCBIND(8) first.

Thanks for your time!
--
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

[patch] mmap() MAP_TEXT implementation (to use for shared libraries)

[Svatopluk Kraus]

Hi,

  I found out that while the running excecutables and a dynamic linker
are protected against writing (ETXTBSY), the loaded shared libraries
are not protected. The libraries are mapped by mmap() in dynamic
linker (rtld) and there is no way how to set VV_TEXT flag on the
libraries vnodes in mmap() code.

  In linux compability code \compat\linux\linux_misc.c, linux_uselib()
sets VV_TEXT flags on a library vnode. In Solaris, MAP_TEXT flag
exists which informs mmap() that the mapped region will be used
primarily for executing instructions (for better MMU utilization).
With these on mind, I propose to implement MAP_TEXT option in mmap()
and in case that underlying object is a vnode, set VV_TEXT flag on it.

  I already have implemented it and with rtld map_object() patch it
works fine for me (of course). The rtld patch looks easy, however I'm
not sure about mmap patch.

  After some investigation, it looks that VV_TEXT once set on a vnode
remains set until last reference on the vnode is left. So, I don't
bother with VV_TEXT unset in munmap() to be consistent. The
executables and dynamic linker are activated in kernel, so VV_TEXT is
set before activation and cleared if something failed. Shared library
activation is done in dynamic linker (i.e., in userland). It's done in
steps and mmaping the library is one from them. So, I think that
VV_TEXT can be set in mmap() just after everything is finished
successfully.

  The patch itself is implemented in vm_mmap_vnode(). If I want to set
VV_TEXT flag on a vnode, I need an exclusive lock. In current code,
the exclusive lock flag is (mis)used as a flag for
vnode_pager_update_writecount() call. (I hope that I didn't miss
something.) So, the patch is bigger slightly.

  I defined the MAP_TEXT flag in extented flags sections. However, I'm
feeling the relation to MAP_STACK flag, but not sure if and when
reserved flags (in other flags section) can be re-used.

   Svata


  Index: libexec/rtld-elf/map_object.c
===
--- libexec/rtld-elf/map_object.c   (revision 239770)
+++ libexec/rtld-elf/map_object.c   (working copy)
@@ -199,7 +199,8 @@
data_prot = convert_prot(segs[i]-p_flags);
data_flags = convert_flags(segs[i]-p_flags) | MAP_FIXED;
if (mmap(data_addr, data_vlimit - data_vaddr, data_prot,
- data_flags | MAP_PREFAULT_READ, fd, data_offset) == (caddr_t) -1) {
+ data_flags | MAP_PREFAULT_READ | MAP_TEXT, fd, data_offset) ==
+   (caddr_t) -1) {
_rtld_error(%s: mmap of data failed: %s, path,
rtld_strerror(errno));
goto error1;
Index: sys/vm/vm_mmap.c
===
--- sys/vm/vm_mmap.c(revision 239770)
+++ sys/vm/vm_mmap.c(working copy)
@@ -1258,10 +1258,13 @@
struct mount *mp;
struct ucred *cred;
int error, flags, locktype, vfslocked;
+   int writeable_shared;

mp = vp-v_mount;
cred = td-td_ucred;
-   if ((*maxprotp  VM_PROT_WRITE)  (*flagsp  MAP_SHARED))
+   flags = *flagsp;
+   writeable_shared = ((*maxprotp  VM_PROT_WRITE)  (flags  
MAP_SHARED));
+   if (writeable_shared || ((flags  MAP_TEXT) != 0))
locktype = LK_EXCLUSIVE;
else
locktype = LK_SHARED;
@@ -1271,7 +1274,6 @@
return (error);
}
foff = *foffp;
-   flags = *flagsp;
obj = vp-v_object;
if (vp-v_type == VREG) {
/*
@@ -1294,7 +1296,7 @@
return (error);
}
}
-   if (locktype == LK_EXCLUSIVE) {
+   if (writeable_shared) {
*writecounted = TRUE;
vnode_pager_update_writecount(obj, 0, objsize);
}
@@ -1337,6 +1339,14 @@
error = ENOMEM;
goto done;
}
+   /*
+* If MAP_TEXT is announced, set VV_TEXT so no one can write
+* to the executable.
+*/
+   if ((flags  MAP_TEXT) != 0) {
+   ASSERT_VOP_ELOCKED(vp, vv_text);
+   vp-v_vflag |= VV_TEXT;
+   }
*objp = obj;
*flagsp = flags;

Index: sys/sys/mman.h
===
--- sys/sys/mman.h  (revision 239770)
+++ sys/sys/mman.h  (working copy)
@@ -91,6 +91,7 @@
  */
 #defineMAP_NOCORE   0x0002 /* dont include these pages in a 
coredump */
 #defineMAP_PREFAULT_READ 0x0004 /* prefault mapping for reading */
+#defineMAP_TEXT 0x0008 /* map code segment */
 #endif /* __BSD_VISIBLE */

 #if __POSIX_VISIBLE = 199309
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to 

Re: [patch] mmap() MAP_TEXT implementation (to use for shared libraries)

[Andriy Gapon]

on 03/09/2012 13:35 Svatopluk Kraus said the following:
 After some investigation, it looks that VV_TEXT once set on a vnode
 remains set until last reference on the vnode is left.

There was an idea to turn VV_TEXT flag into a v_text counter.
Maybe something like that would be useful indeed?

-- 
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

[CFT] hwpmc support for Intel Ivy Bridge

[Fabien Thomas]

Hi,

Find a patch that add Intel  Ivy Bridge support to hwpmc(9).
The patch also support offcore RSP token for Sandy Bridge.
Note: No uncore support.

Tested on:
Intel(R) Xeon(R) CPU E3-1265L V2 @ 2.50GHz (2494.35-MHz K8-class CPU)
Origin = GenuineIntel  Id = 0x306a9  Family = 6  Model = 3a  Stepping = 9

http://people.freebsd.org/~fabient/patch-hwpmc_ivy_bridge_head

cd /usr/src  patch -p0  patch-hwpmc_ivy_bridge_head 
and rebuild world.


Fabien

Re: [patch] mmap() MAP_TEXT implementation (to use for shared libraries)

[Konstantin Belousov]

On Mon, Sep 03, 2012 at 12:35:08PM +0200, Svatopluk Kraus wrote:
 Hi,
 
   I found out that while the running excecutables and a dynamic linker
 are protected against writing (ETXTBSY), the loaded shared libraries
 are not protected. The libraries are mapped by mmap() in dynamic
 linker (rtld) and there is no way how to set VV_TEXT flag on the
 libraries vnodes in mmap() code.
 
   In linux compability code \compat\linux\linux_misc.c, linux_uselib()
 sets VV_TEXT flags on a library vnode. In Solaris, MAP_TEXT flag
 exists which informs mmap() that the mapped region will be used
 primarily for executing instructions (for better MMU utilization).
 With these on mind, I propose to implement MAP_TEXT option in mmap()
 and in case that underlying object is a vnode, set VV_TEXT flag on it.
 
   I already have implemented it and with rtld map_object() patch it
 works fine for me (of course). The rtld patch looks easy, however I'm
 not sure about mmap patch.
 
   After some investigation, it looks that VV_TEXT once set on a vnode
 remains set until last reference on the vnode is left. So, I don't
 bother with VV_TEXT unset in munmap() to be consistent. The
 executables and dynamic linker are activated in kernel, so VV_TEXT is
 set before activation and cleared if something failed. Shared library
 activation is done in dynamic linker (i.e., in userland). It's done in
 steps and mmaping the library is one from them. So, I think that
 VV_TEXT can be set in mmap() just after everything is finished
 successfully.
This is right, the object reference counter is also used as
VV_TEXT counter. It is somewhat unaccurate, but in practice does
not cause issues.

 
   The patch itself is implemented in vm_mmap_vnode(). If I want to set
 VV_TEXT flag on a vnode, I need an exclusive lock. In current code,
 the exclusive lock flag is (mis)used as a flag for
 vnode_pager_update_writecount() call. (I hope that I didn't miss
 something.) So, the patch is bigger slightly.
 
   I defined the MAP_TEXT flag in extented flags sections. However, I'm
 feeling the relation to MAP_STACK flag, but not sure if and when
 reserved flags (in other flags section) can be re-used.
 
Svata
 
 
   Index: libexec/rtld-elf/map_object.c
 ===
 --- libexec/rtld-elf/map_object.c (revision 239770)
 +++ libexec/rtld-elf/map_object.c (working copy)
 @@ -199,7 +199,8 @@
   data_prot = convert_prot(segs[i]-p_flags);
   data_flags = convert_flags(segs[i]-p_flags) | MAP_FIXED;
   if (mmap(data_addr, data_vlimit - data_vaddr, data_prot,
 -   data_flags | MAP_PREFAULT_READ, fd, data_offset) == (caddr_t) -1) {
 +   data_flags | MAP_PREFAULT_READ | MAP_TEXT, fd, data_offset) ==
 + (caddr_t) -1) {
I am not sure that we shall mark all segments mappings with MAP_TEXT.
I understand the logic of the change, since we do not want data segment
to be changed under us. Still, having MAP_TEXT for non-text segments looks
strange.

   _rtld_error(%s: mmap of data failed: %s, path,
   rtld_strerror(errno));
   goto error1;
 Index: sys/vm/vm_mmap.c
 ===
 --- sys/vm/vm_mmap.c  (revision 239770)
 +++ sys/vm/vm_mmap.c  (working copy)
 @@ -1258,10 +1258,13 @@
   struct mount *mp;
   struct ucred *cred;
   int error, flags, locktype, vfslocked;
 + int writeable_shared;
 
   mp = vp-v_mount;
   cred = td-td_ucred;
 - if ((*maxprotp  VM_PROT_WRITE)  (*flagsp  MAP_SHARED))
 + flags = *flagsp;
 + writeable_shared = ((*maxprotp  VM_PROT_WRITE)  (flags  
 MAP_SHARED));
 + if (writeable_shared || ((flags  MAP_TEXT) != 0))
   locktype = LK_EXCLUSIVE;
   else
   locktype = LK_SHARED;
 @@ -1271,7 +1274,6 @@
   return (error);
   }
   foff = *foffp;
 - flags = *flagsp;
   obj = vp-v_object;
   if (vp-v_type == VREG) {
   /*
 @@ -1294,7 +1296,7 @@
   return (error);
   }
   }
 - if (locktype == LK_EXCLUSIVE) {
 + if (writeable_shared) {
   *writecounted = TRUE;
   vnode_pager_update_writecount(obj, 0, objsize);
   }
 @@ -1337,6 +1339,14 @@
   error = ENOMEM;
   goto done;
   }
 + /*
 +  * If MAP_TEXT is announced, set VV_TEXT so no one can write
 +  * to the executable.
 +  */
 + if ((flags  MAP_TEXT) != 0) {
 + ASSERT_VOP_ELOCKED(vp, vv_text);
 + vp-v_vflag |= VV_TEXT;
 + }
I do not think we want to set VV_TEXT for device vnodes.

   *objp = obj;
   *flagsp = flags;
 
 Index: sys/sys/mman.h
 ===
 --- sys/sys/mman.h(revision 239770)
 +++ sys/sys/mman.h(working copy)
 @@ -91,6 +91,7 @@
   */
  #define  

[head tinderbox] failure on sparc64/sparc64

[FreeBSD Tinderbox]

TB --- 2012-09-03 18:01:51 - tinderbox 2.9 running on freebsd-current.sentex.ca
TB --- 2012-09-03 18:01:51 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE 
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC  amd64
TB --- 2012-09-03 18:01:51 - starting HEAD tinderbox run for sparc64/sparc64
TB --- 2012-09-03 18:01:51 - cleaning the object tree
TB --- 2012-09-03 18:01:51 - cvsupping the source tree
TB --- 2012-09-03 18:01:51 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca 
/tinderbox/HEAD/sparc64/sparc64/supfile
TB --- 2012-09-03 18:03:28 - building world
TB --- 2012-09-03 18:03:28 - CROSS_BUILD_TESTING=YES
TB --- 2012-09-03 18:03:28 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-09-03 18:03:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-09-03 18:03:28 - SRCCONF=/dev/null
TB --- 2012-09-03 18:03:28 - TARGET=sparc64
TB --- 2012-09-03 18:03:28 - TARGET_ARCH=sparc64
TB --- 2012-09-03 18:03:28 - TZ=UTC
TB --- 2012-09-03 18:03:28 - __MAKE_CONF=/dev/null
TB --- 2012-09-03 18:03:28 - cd /src
TB --- 2012-09-03 18:03:28 - /usr/bin/make -B buildworld
 World build started on Mon Sep  3 18:03:29 UTC 2012
 Rebuilding the temporary build tree
 stage 1.1: legacy release compatibility shims
 stage 1.2: bootstrap tools
 stage 2.1: cleaning up the object tree
 stage 2.2: rebuilding the object tree
 stage 2.3: build tools
 stage 3: cross tools
 stage 4.1: building includes
 stage 4.2: building libraries
 stage 4.3: make dependencies
 stage 4.4: building everything
[...]
/src/secure/usr.bin/ssh/../../../crypto/openssh/mux.c:758: error: 'Forward' has 
no member named 'handle'
/src/secure/usr.bin/ssh/../../../crypto/openssh/mux.c: In function 
'process_mux_close_fwd':
/src/secure/usr.bin/ssh/../../../crypto/openssh/mux.c:854: error: void value 
not ignored as it ought to be
/src/secure/usr.bin/ssh/../../../crypto/openssh/mux.c:858: warning: implicit 
declaration of function 'channel_cancel_lport_listener'
/src/secure/usr.bin/ssh/../../../crypto/openssh/mux.c: In function 'muxclient':
/src/secure/usr.bin/ssh/../../../crypto/openssh/mux.c:2104: error: 
'SSHMUX_COMMAND_CANCEL_FWD' undeclared (first use in this function)
/src/secure/usr.bin/ssh/../../../crypto/openssh/mux.c:2104: error: (Each 
undeclared identifier is reported only once
/src/secure/usr.bin/ssh/../../../crypto/openssh/mux.c:2104: error: for each 
function it appears in.)
*** Error code 1

Stop in /src/secure/usr.bin/ssh.
*** Error code 1

Stop in /src/secure/usr.bin.
*** Error code 1

Stop in /src/secure.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2012-09-03 18:58:17 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2012-09-03 18:58:17 - ERROR: failed to build world
TB --- 2012-09-03 18:58:17 - 2620.73 user 477.97 system 3386.84 real


http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: pkgng suggestion: renaming /usr/sbin/pkg to /usr/sbin/pkg-bootstrap

[Tijl Coosemans]

On 01-09-2012 21:40, Matthew Seaman wrote:
 On 01/09/2012 18:43, Tijl Coosemans wrote:
 In this scenario the ports tree needs to keep support for older releases,
 but that's a consequence of the fact that there's only one ports tree for
 all releases. Somewhere in between the ports and the various releases there
 has to be some form encapsulation, not just for pkg, but for all the tools
 used by the ports tree. Given how the ports tree currently encapsulates
 both the old and new pkg tools I don't see how supporting multiple versions
 of pkgng would be a problem because presumably the difference between pkgng
 versions is going to be much smaller than the difference between the old
 and new tools.
 
 New functionality already in the process of development will entail
 making non-backwards compatible changes to the DB schema.  If we're tied
 to supporting a version of pkgng bundled with a release, that's going to
 make rolling out such changes much harder.
 
 On the other hand, if pkgng is in ports, then we can release a new
 version and simultaneously publish new package sets (incorporating
 the update to pkgng) from the repositories which will have been built
 using the updated DB schema.

But you cannot update the pkgng repo on the release DVDs.

And also, there's no such thing as simultaneous. After you've updated the
port it takes days even weeks for the package build cluster to rebuild
package sets for all branches and all architectures (think powerpc,
sparc64) and then it takes even more time for the ftp mirrors to pick up
the new set from the master ftp and it takes even more time for a user to
actually update his ports/packages (months to years). During all this
time there can be a difference in version (possibly several versions)
between the pkgng in ports, the pkgng of the official repositories and
the pkgng version that is currently installed on the user's system.

 The ports tree doesn't track the versioning of the base system, and it
 makes perfect sense to me that tools for dealing with the ports should
 follow changes to ports rather than changes to the base.

How about the following:

If you can guarantee that the pkg port can always be built and installed
from ports no matter what version of pkg is currently installed, then the
ports tree only needs to support the version of pkg that is currently in
the tree.

Guaranteeing that the pkg port can always be built probably means it
should set a flag in its Makefile (e.g.BUILDING_PKG) that causes
bsd.port.mk to not use pkg at all until after installation (so it cannot
do conflicts checking for instance). During installation the port also
updates the local pkg registry such that after installation bsd.port.mk
can register the package with the new pkg version.

Special-casing the pkg port this way effectively creates a bootstrap in
the ports tree itself (instead of having a pkg-bootstrap tool in base or
during FreeBSD installation).

Similarly, for package users, pkg should always be able to update itself
from a remote repo no matter what version is currently installed. jhb's
idea of putting pkg in a self extracting script in a fixed location of a
package repo is probably the most flexible. This creates a bootstrap in
every pkg repo.

And then you can put pkg with a pkg repo on FreeBSD release media as
well, such that packages (including pkg) can be installed during and
after installation without needing an internet connection. If there is
an internet connection and the user wants to install packages from a
remote repo, the pkg on the release media can fetch and install pkg from
the repo and then that pkg can be used to install other packages.

I'd be ok with this. The ports tree only has to support one version of
pkgng, there's no separate bootstrap tool, release media are nicely
self-contained and no matter how outdated a user's installed packages
are he can always update using either ports or packages.



signature.asc
Description: OpenPGP digital signature

Re: [CFT] hwpmc support for Intel Ivy Bridge

[Baptiste Daroussin]

On Mon, Sep 03, 2012 at 02:04:21PM +0200, Fabien Thomas wrote:
   Hi,
 
 Find a patch that add Intel  Ivy Bridge support to hwpmc(9).
 The patch also support offcore RSP token for Sandy Bridge.
 Note: No uncore support.
 
 Tested on:
 Intel(R) Xeon(R) CPU E3-1265L V2 @ 2.50GHz (2494.35-MHz K8-class CPU)
 Origin = GenuineIntel  Id = 0x306a9  Family = 6  Model = 3a  Stepping = 9
 
 http://people.freebsd.org/~fabient/patch-hwpmc_ivy_bridge_head
 
 cd /usr/src  patch -p0  patch-hwpmc_ivy_bridge_head 
 and rebuild world.
 
 
 Fabien

World building, I'll keep you in touch

Is there any particulat testing, I can do other than using the new world?

regards,
Bapt


pgpXny9k2ry4B.pgp
Description: PGP signature

recent update seems to break portupgrade

[AN]

FreeBSD FBSD10 10.0-CURRENT FreeBSD 10.0-CURRENT #18 r240078: Mon Sep  3 
17:41:46 EDT 2012 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL  amd64


# cat /etc/make.conf
OVERRIDE_LINUX_BASE_PORT=f10
QT4_OPTIONS= QGTKSTYLE

# added by use.perl 2012-04-04 01:11:13
PERL_VERSION=5.14.2
MALLOC_PRODUCTION=yes
WITH_PKGNG=no

I just tried to do a portupgrade and received the following on the command 
line.  I compiled my system (world and ports from source).  Portupgrade 
worked earlier today before I upgraded to r240078.


# portupgrade -va
---  Session started at: Mon, 03 Sep 2012 22:51:25 -0400
/usr/ports/Mk/bsd.openssl.mk, line 109: warning: /usr/local/sbin/pkg 
which -qo /usr/local/lib/libcrypto.so returned non-zero status
/usr/ports/Mk/bsd.openssl.mk, line 109: warning: /usr/local/sbin/pkg 
which -qo /usr/local/lib/libcrypto.so returned non-zero status
/usr/ports/Mk/bsd.openssl.mk, line 109: warning: /usr/local/sbin/pkg 
which -qo /usr/local/lib/libcrypto.so returned non-zero status
/usr/ports/Mk/bsd.openssl.mk, line 109: warning: /usr/local/sbin/pkg 
which -qo /usr/local/lib/libcrypto.so returned non-zero status
/usr/ports/Mk/bsd.openssl.mk, line 109: warning: /usr/local/sbin/pkg 
which -qo /usr/local/lib/libcrypto.so returned non-zero status

** Port directory not found: www/ff_nightly
/usr/ports/Mk/bsd.openssl.mk, line 109: warning: /usr/local/sbin/pkg 
which -qo /usr/local/lib/libcrypto.so returned non-zero status
/usr/ports/Mk/bsd.openssl.mk, line 109: warning: /usr/local/sbin/pkg 
which -qo /usr/local/lib/libcrypto.so returned non-zero status

^C

Not sure what is going on, I guess it is related to pkg:

# whereis pkg
pkg: /usr/sbin/pkg /usr/local/man/man8/pkg.8.gz /usr/src/usr.sbin/pkg
[root@FBSD10 ~]# ls -l /usr/sbin/pkg
-r-xr-xr-x  1 root  wheel  16256 Sep  3 13:55 /usr/sbin/pkg

If I do not want to use pkg do I need an entry in /etc/src.conf?  How do 
you disable pkg?  How do I run portupgrade now?

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: recent update seems to break portupgrade

[Bryan Drewery]

On 9/4/2012 2:14 AM, AN wrote:
 FreeBSD FBSD10 10.0-CURRENT FreeBSD 10.0-CURRENT #18 r240078: Mon Sep  3
 17:41:46 EDT 2012 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL  amd64
 
 # cat /etc/make.conf
 OVERRIDE_LINUX_BASE_PORT=f10
 QT4_OPTIONS= QGTKSTYLE
 
 # added by use.perl 2012-04-04 01:11:13
 PERL_VERSION=5.14.2
 MALLOC_PRODUCTION=yes
 WITH_PKGNG=no


*Defining* WITH_PKGNG enables it. This is very common with ports
infrastructure. Remove this from your make.conf to not use pkgng.

 
 I just tried to do a portupgrade and received the following on the
 command line.  I compiled my system (world and ports from source). 
 Portupgrade worked earlier today before I upgraded to r240078.
 
 # portupgrade -va
 ---  Session started at: Mon, 03 Sep 2012 22:51:25 -0400
 /usr/ports/Mk/bsd.openssl.mk, line 109: warning: /usr/local/sbin/pkg
 which -qo /usr/local/lib/libcrypto.so returned non-zero status
 /usr/ports/Mk/bsd.openssl.mk, line 109: warning: /usr/local/sbin/pkg
 which -qo /usr/local/lib/libcrypto.so returned non-zero status
 /usr/ports/Mk/bsd.openssl.mk, line 109: warning: /usr/local/sbin/pkg
 which -qo /usr/local/lib/libcrypto.so returned non-zero status
 /usr/ports/Mk/bsd.openssl.mk, line 109: warning: /usr/local/sbin/pkg
 which -qo /usr/local/lib/libcrypto.so returned non-zero status
 /usr/ports/Mk/bsd.openssl.mk, line 109: warning: /usr/local/sbin/pkg
 which -qo /usr/local/lib/libcrypto.so returned non-zero status
 ** Port directory not found: www/ff_nightly
 /usr/ports/Mk/bsd.openssl.mk, line 109: warning: /usr/local/sbin/pkg
 which -qo /usr/local/lib/libcrypto.so returned non-zero status
 /usr/ports/Mk/bsd.openssl.mk, line 109: warning: /usr/local/sbin/pkg
 which -qo /usr/local/lib/libcrypto.so returned non-zero status

This is not a portupgrade problem.

These errors are a problem with bsd.port.mk. I've been meaning to write
up a patch for a while now and get to bapt for testing. If he doesn't
get to it first, I'll get one submitted soon.

 ^C
 
 Not sure what is going on, I guess it is related to pkg:
 
 # whereis pkg
 pkg: /usr/sbin/pkg /usr/local/man/man8/pkg.8.gz /usr/src/usr.sbin/pkg
 [root@FBSD10 ~]# ls -l /usr/sbin/pkg
 -r-xr-xr-x  1 root  wheel  16256 Sep  3 13:55 /usr/sbin/pkg
 
 If I do not want to use pkg do I need an entry in /etc/src.conf?  How do
 you disable pkg?  How do I run portupgrade now?
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


-- 
Regards,
Bryan Drewery
bdrewery@freenode/EFNet
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org