sys/dev/amr build error with Clang
Hey, Baldie: /usr/src/sys/modules/amr/../../dev/amr/amr.c:970:1: error: function 'amr_periodic' is not needed and will not be emitted [-Werror,-Wunneeded-internal-declaration] amr_periodic(void *data) ^ 1 error generated. *** [amr.o] Error code 1 Stop in /usr/src/sys/modules/amr. ___ 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: UFS journal error on 10.0-CURRENT
2012/8/30 Jakub Lach jakub_l...@mailplus.pl: Yes, if I would answer 'yes' to using journal, there would be unexpected free inodes (?) or something like that in syslog and inconsistencies if full fsck would be performed. That's normally the case, yes, but not here. Basically if I have answered 'yes' to using journal, fs would always be marked 'clean' regardless of state. I solved it this way, thanks to a tip from Doug White: 1. tunefs -j disable /dev/ada0s1f 2. fsck -y /usr 3 mount /usr ; rm /usr/.sujournal ; umount /usr 4 tunefs -j enable /dev/ada0s1f 5 reboot Step 3 is required because tunefs gets confused when you enable a journal and an (old) journal is already present. Either I should add this somewhere to the Handbook/an article, or fsck(_ufs) should be made more intelligent... Regards, René ___ 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
rpcbind does not honor -h flag
Hi All, I've it at 9.1-PRERELEASE and I've got a chance to test at CURRENT. It's the same (mind a line with udp4 *:768 at sockstat info): - % sockstat -4l | grep rpcbind % grep rpcbind /etc/rc.conf.local rpcbind_flags=-h 192.168.119.6 rpcbind_enable=YES % sudo /etc/rc.d/rpcbind start Starting rpcbind. % sockstat -4l | grep rpcbind root rpcbind4265 9 udp4 127.0.0.1:111 *:* root rpcbind4265 10 udp4 192.168.119.6:111 *:* root rpcbind4265 11 udp4 *:768 *:* root rpcbind4265 12 tcp4 127.0.0.1:111 *:* root rpcbind4265 13 tcp4 192.168.119.6:111 *:* % uname -a FreeBSD bsam.wart.ru 10.0-CURRENT FreeBSD 10.0-CURRENT #31 r239793: Wed Aug 29 03:00:30 SAMT 2012 b...@bsam.wart.ru:/usr/obj/usr/src/sys/BBX i386 - -- 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
Re: rpcbind does not honor -h flag
On Fri, Aug 31, 2012 at 1:05 AM, Борис Самородов b...@passap.ru wrote: Hi All, I've it at 9.1-PRERELEASE and I've got a chance to test at CURRENT. It's the same (mind a line with udp4 *:768 at sockstat info): - % sockstat -4l | grep rpcbind % grep rpcbind /etc/rc.conf.local rpcbind_flags=-h 192.168.119.6 rpcbind_enable=YES % sudo /etc/rc.d/rpcbind start Starting rpcbind. % sockstat -4l | grep rpcbind root rpcbind4265 9 udp4 127.0.0.1:111 *:* root rpcbind4265 10 udp4 192.168.119.6:111 *:* root rpcbind4265 11 udp4 *:768 *:* root rpcbind4265 12 tcp4 127.0.0.1:111 *:* root rpcbind4265 13 tcp4 192.168.119.6:111 *:* % uname -a FreeBSD bsam.wart.ru 10.0-CURRENT FreeBSD 10.0-CURRENT #31 r239793: Wed Aug 29 03:00:30 SAMT 2012 b...@bsam.wart.ru:/usr/obj/usr/src/sys/BBX i386 This is a generic rc(5) bug: $ sudo env rpcbind_flags=-6 /etc/rc.d/rpcbind restart Stopping rpcbind. Waiting for PIDS: 509. Starting rpcbind. $ ps auxww | grep rpcbind root 776 0.6 0.0 14056 1844 ?? Ss1:07AM 0:00.02 /usr/sbin/rpcbind gcooper 778 0.0 0.0 16196 1660 1 S+1:07AM 0:00.00 grep rpcbind $ sudo env rpcbind_flags=-6 /etc/rc.d/rpcbind restart rc_flags = rc_flags = Stopping rpcbind. Waiting for PIDS: 801. rc_flags = Starting rpcbind. $ sudo env sshd_flags=blahblahblah /etc/rc.d/sshd restart rc_flags = rc_flags = Stopping sshd. Waiting for PIDS: 613. rc_flags = Starting sshd. $ ps auxww | grep sshd root 861 0.0 0.0 28728 3668 ?? Is1:11AM 0:00.00 /usr/sbin/sshd root84730 0.0 0.0 47812 4040 ?? Is Wed09AM 0:00.15 sshd: gcooper [priv] (sshd) gcooper 84732 0.0 0.0 47812 4028 ?? IWed09AM 0:02.73 sshd: gcooper@pts/0 (sshd) root88236 0.0 0.0 47812 4040 ?? Is8:43AM 0:00.16 sshd: gcooper [priv] (sshd) gcooper 88238 0.0 0.0 47812 4028 ?? S 8:43AM 0:02.29 sshd: gcooper@pts/1 (sshd) root88262 0.0 0.0 47812 4040 ?? Is8:46AM 0:00.10 sshd: gcooper [priv] (sshd) gcooper 88264 0.0 0.0 47812 4028 ?? S 8:46AM 0:00.80 sshd: gcooper@pts/2 (sshd) gcooper 863 0.0 0.0 16196 1668 1 S+1:11AM 0:00.01 grep sshd $ uname -a FreeBSD bayonetta.local 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #13 r239292M: Wed Aug 15 02:42:48 PDT 2012 gcooper@bayonetta.local:/usr/obj/store/freebsd/stable/9/sys/BAYONETTA amd64 Please file a PR against rc ASAP. Thanks, -Garrett ___ 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: rpcbind does not honor -h flag
On Fri, Aug 31, 2012 at 1:14 AM, Garrett Cooper yaneg...@gmail.com wrote: On Fri, Aug 31, 2012 at 1:05 AM, Борис Самородов b...@passap.ru wrote: Hi All, I've it at 9.1-PRERELEASE and I've got a chance to test at CURRENT. It's the same (mind a line with udp4 *:768 at sockstat info): - % sockstat -4l | grep rpcbind % grep rpcbind /etc/rc.conf.local rpcbind_flags=-h 192.168.119.6 rpcbind_enable=YES % sudo /etc/rc.d/rpcbind start Starting rpcbind. % sockstat -4l | grep rpcbind root rpcbind4265 9 udp4 127.0.0.1:111 *:* root rpcbind4265 10 udp4 192.168.119.6:111 *:* root rpcbind4265 11 udp4 *:768 *:* root rpcbind4265 12 tcp4 127.0.0.1:111 *:* root rpcbind4265 13 tcp4 192.168.119.6:111 *:* % uname -a FreeBSD bsam.wart.ru 10.0-CURRENT FreeBSD 10.0-CURRENT #31 r239793: Wed Aug 29 03:00:30 SAMT 2012 b...@bsam.wart.ru:/usr/obj/usr/src/sys/BBX i386 This is a generic rc(5) bug: ... Please file a PR against rc ASAP. Grr... that's right. /etc/defaults/rc.conf overwrites anything set in the environment. Please ignore the previous email. And FWIW, rpcbind doesn't in fact bind to specific addresses like you claim: $ sockstat -4 | grep rpcbind root rpcbind1060 9 udp4 127.0.0.1:111 *:* root rpcbind1060 10 udp4 192.168.20.2:111 *:* root rpcbind1060 11 udp4 *:974 *:* root rpcbind1060 12 tcp4 127.0.0.1:111 *:* root rpcbind1060 13 tcp4 192.168.20.2:111 *:* Thanks, -Garrett ___ 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: rpcbind does not honor -h flag
31.08.2012 12:34, Maxim Konovalov пишет: Please file a PR against rc ASAP. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/117711 I see. Thanks. -- 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
Re: sys/dev/amr build error with Clang
On 2012-08-31 09:34, deeptec...@gmail.com wrote: /usr/src/sys/modules/amr/../../dev/amr/amr.c:970:1: error: function 'amr_periodic' is not needed and will not be emitted [-Werror,-Wunneeded-internal-declaration] The one call to get the callout to amr_periodic() started seems to have been commented out in r239912: http://svnweb.freebsd.org/base/head/sys/dev/amr/amr.c?r1=239912r2=239911pathrev=239912 If the function isn't necessary anymore, it could just be deleted, or #ifdef'd out. ___ 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: sys/dev/amr build error with Clang
Dimitry Andric wrote: The one call to get the callout to amr_periodic() started seems to have been commented out in r239912: http://svnweb.freebsd.org/base/head/sys/dev/amr/amr.c?r1=239912r2=239911pathrev=239912 If the function isn't necessary anymore, it could just be deleted, or #ifdef'd out. I don't use amr, so I personally don't care whether the use of the function was accidentally commented out or whether the function was accidentally left unused. But on a side-note, to a programmer not familiar with the driver, that case seems like a case of the use was accidentally commented out. ___ 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: sys/dev/amr build error with Clang
On Aug 31, 2012, at 2:43 AM, Dimitry Andric dimi...@andric.com wrote: On 2012-08-31 09:34, deeptec...@gmail.com wrote: /usr/src/sys/modules/amr/../../dev/amr/amr.c:970:1: error: function 'amr_periodic' is not needed and will not be emitted [-Werror,-Wunneeded-internal-declaration] The one call to get the callout to amr_periodic() started seems to have been commented out in r239912: http://svnweb.freebsd.org/base/head/sys/dev/amr/amr.c?r1=239912r2=239911pathrev=239912 If the function isn't necessary anymore, it could just be deleted, or #ifdef'd out. Fixed in r239939. Thanks for the report. Scott ___ 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: make package fails in chroot: tar: getvfsbyname failed: No such file or directory
On Thu, Aug 30, 2012 at 4:34 PM, Konstantin Belousov kostik...@gmail.com wrote: On Thu, Aug 30, 2012 at 04:07:48PM +0200, Bernhard Fr?hlich wrote: On Mon, Aug 20, 2012 at 2:31 PM, Konstantin Belousov kostik...@gmail.com wrote: On Mon, Aug 20, 2012 at 01:42:31PM +0200, Bernhard Fr?hlich wrote: On Sun, Aug 19, 2012 at 10:01 PM, Tim Kientzle t...@kientzle.com wrote: On Aug 19, 2012, at 12:17 PM, Garrett Cooper wrote: On Sun, Aug 19, 2012 at 9:45 AM, Tim Kientzle t...@kientzle.com wrote: On Aug 12, 2012, at 6:20 AM, Paul Schenkeveld wrote: Hi, I have a wrapper script that builds packages in a chroot environment which happily runs on release 6 thru 9 and earlier 10 but fails with: tar: getvfsbyname failed: No such file or directory on a recent -CURRENT. libarchive does do an initial getvfsbyname() when you ask it to traverse a directory tree so that it can accurately handle later requests about mountpoints and filesystem types. This code is admittedly a little intricate. The problem most likely is the fact that all mountpoints are exposed via chroot, thus, if it's checking to see if a mountpoint exists, it may exist outside of the chroot. I reviewed the code to refresh my memory. Some of what I said before was not quite right. Libarchive's directory traversal tracks information about the filesystem type so that clients such as bsdtar can efficiently skip synthetic filesystems (/dev or /proc) or network filesystems (NFS or SMB mounts). The net effect is something like this: For each file: stat() or lstat() or fstat() the file look up dev number in an internal cache if the dev number is new: fstatfs() the open fd to get the FS name getvfsbyname() to identify the FS type Unless there's a logic error in libarchive itself, this would suggest that somehow fstatfs() is returning a filesystem type that getvfsbyname() can't identify. Paul: What filesystem are you using? What does mount show? Does it work outside the chroot? I also see the same on the redports.org build machines. It builds within a jail there which is completely on a tmpfs. Interestinly everything is fine with a 10-CURRENT/amd64 jail but it breaks in a 10-CURRENT/i386 jail. Both are running on the same 10-CURRENT/amd64 which is around 2 months old. https://redports.org/buildarchive/20120814130205-56327/ Try this. Is it possible that this requires the host system to be quite new? The commit in HEAD seems to doesn't help in my case. Host is 9-stable from Jun 27 and jail is 10-current from a few days ago. Doh, the fix was in kernel, and I merged the change back to stable only on August 27. Running HEAD world on stable is not supported anyway. I've updated the host to a recent 9-stable and it works like a charm now. Thanks for fixing it! -- Bernhard Froehlich http://www.bluelife.at/ ___ 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
On Thu, Aug 30, 2012 at 01:02:06PM -1000, Doug Barton wrote: On 08/30/2012 07:32 AM, John Baldwin wrote: On Thursday, August 30, 2012 1:10:24 pm Chris Rees wrote: On 30 Aug 2012 18:03, John Baldwin j...@freebsd.org wrote: I agree with John on all counts here. Further, the idea of a self-installing package, at least for the pkg stuff itself, addresses the issue that someone else brought up about how to handle installation of pkg by the installer for a new system. I like the idea of also providing a self-installing package, and it seems really easy to do, so I'll try to see what I can do in this area I'll wrote a PoC in 5 minutes which looks pretty good, this could also be a very simple and easy way to integrate into bsdinstaller. I'll do work in that direction. Still it doesn't solve the problem of boostrapping pkgng in a fresh new box, because the user may not know where to download the pkg-setup.sh. regards, Bapt pgpOWePQoBvBB.pgp Description: PGP signature
Re: rpcbind does not honor -h flag
31.08.2012 12:14, Garrett Cooper пишет: Please file a PR against rc ASAP. Can someone file a PR on the matter? (ENOTIME for me) Thanks! -- 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
Re: rpcbind does not honor -h flag
Please file a PR against rc ASAP. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/117711 -- Maxim Konovalov ___ 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: [CFT] Some updates to libc/rpc (second try)
On Thu, Aug 30, 2012 at 02:37:17AM -0700, Garrett Cooper wrote: Detailed description of mistakes in these files and correct implementation: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/165710 A developer at $work (Isilon) developed a slightly simpler patch than that based on our custom 7.x sources recently to deal with concurrency issues in netconfig. I'll talk with a couple people to see whether or not the solution can be contributed back [after some polishing -- maybe -- and further testing]. Can you post changes and corrected bugs in getnetconfig.c and getnetpath.c in your (your $work) implementation. This is the list of changes and corrected bugs in my implementation: 1. __nc_error() does not check return value from malloc() and can pass NULL pointer to thr_setspecific(). 2. setnetconfig() has a race condition with reference counter when several threads call this function and only one thread successfully opened database file, while other threads failed in this function. If that one thread called endnetconfig(), then it can keep cached data in memory, but all threads will not have opened handles. 3. getnetconfig() should return entries from /etc/netconfig file in the same order as they are specified according to netconfig(5). If several threads call getnetconfig() using different handlers, then entries for each handler will be returned in random order. 4. getnetconfig() has a race condition that can cause NULL pointer dereference when several threads call this function using one handler. 5. getnetconfig() allows to continue to get entries if database file has invalid format, because it does not remember previous state. 6. endnetconfig() has a race condition with reference count and can keep cached data, while all handlers are closed. 7. getnetconfigent() uses getnetconfig() and has the same mistakes, also this function duplicates code from getnetconfig(). 8. getnetconfig() and getnetconfigent() use too much memory for entry data, each entry require ~1 kbytes of memory, while usually only 50 bytes is needed. 9. parse_ncp() incorrectly parses flags in netconfig entry and allows wrong combinations of flags, it does not allow spaces before entry, does not check number of elements in each netconfig entry, does not allow empty lines. 10. nc_sperror() is not optimal. 11. dup_ncp() is not optimal, allocates more memory than was used in the original structure, call strcpy() several times instead of calling memcpy() one time. 12. setnetpath() is not optimal, e.g. it calls setnetconfig() and then calls endnetconfig(). 13. getnetpath() uses getnetconfig() and getnetconfigent() and has the same mistakes. 14. getnetpath() has race conditions when several threads call this function using one handler, as a result there are memory leaks and not synchronized access with modifications to data if the NETPATH environment variable is set. 15. _get_next_token() is too complex, incorrectly understand \-sequences. 16. All functions do not specify error code in all possible cases, so nc_sperror() and nc_perror() functions are useless. Difference between netconfig.c vs getnetconfig.c and getnetpath.c: 1. __nc_error() was corrected, but its implementation is the same, this is a standard implementation for thread-specific data handling. nc_perror() was taken from getnetconfig.c, it cannot be written in other way. 2. Some errors messages were taken from getnetconfig.c. 3. New nc_parse() (old parse_ncp()) was corrected and optimized a bit, it just parses white space separated fields in a string. 4. Some variables and macro variables names were taken from getnetconfig.c. 5. All other functions and data structures were rewritten. Additionally I corrected libc/include/reentrant.h, getnetconfig.3, and getnetpath.3. ___ 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: sys/dev/amr build error with Clang
On Friday, August 31, 2012 5:13:01 am deeptec...@gmail.com wrote: Dimitry Andric wrote: The one call to get the callout to amr_periodic() started seems to have been commented out in r239912: http://svnweb.freebsd.org/base/head/sys/dev/amr/amr.c?r1=239912r2=239911pathrev=239912 If the function isn't necessary anymore, it could just be deleted, or #ifdef'd out. I don't use amr, so I personally don't care whether the use of the function was accidentally commented out or whether the function was accidentally left unused. But on a side-note, to a programmer not familiar with the driver, that case seems like a case of the use was accidentally commented out. No, read the diff more closely. The call to timeout() to start the timer was already commented out before. That goes back to r65245 (12 years ago). Similar drivers don't use a periodic timer, so it can probably just be removed. The reason for the new Clang warning is that the old timeout(9) API passes the function pointer to untimeout(), whereas callout_stop() just accepts a pointer to the callout structure. -- John Baldwin ___ 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: [CFT] Some updates to libc/rpc (second try)
On Friday, August 31, 2012 7:06:53 am Andrey Simonenko wrote: On Thu, Aug 30, 2012 at 02:37:17AM -0700, Garrett Cooper wrote: Detailed description of mistakes in these files and correct implementation: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/165710 A developer at $work (Isilon) developed a slightly simpler patch than that based on our custom 7.x sources recently to deal with concurrency issues in netconfig. I'll talk with a couple people to see whether or not the solution can be contributed back [after some polishing -- maybe -- and further testing]. Can you post changes and corrected bugs in getnetconfig.c and getnetpath.c in your (your $work) implementation. There is a thread on threads@ with patches to make the API thread-safe that I believe came from Isilon. It was posted in the last week or so, so it should be easy to find in the archives. -- John Baldwin ___ 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
On Friday, August 31, 2012 5:59:10 am Baptiste Daroussin wrote: On Thu, Aug 30, 2012 at 01:02:06PM -1000, Doug Barton wrote: On 08/30/2012 07:32 AM, John Baldwin wrote: On Thursday, August 30, 2012 1:10:24 pm Chris Rees wrote: On 30 Aug 2012 18:03, John Baldwin j...@freebsd.org wrote: I agree with John on all counts here. Further, the idea of a self-installing package, at least for the pkg stuff itself, addresses the issue that someone else brought up about how to handle installation of pkg by the installer for a new system. I like the idea of also providing a self-installing package, and it seems really easy to do, so I'll try to see what I can do in this area I'll wrote a PoC in 5 minutes which looks pretty good, this could also be a very simple and easy way to integrate into bsdinstaller. I'll do work in that direction. Still it doesn't solve the problem of boostrapping pkgng in a fresh new box, because the user may not know where to download the pkg-setup.sh. I do think that is something bsdinstall should be able to handle, and I would certainly want bsdinstall to include a dialog that says do you want to install the package manager? -- John Baldwin ___ 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
On Fri, Aug 31, 2012 at 08:10:50AM -0400, John Baldwin wrote: On Friday, August 31, 2012 5:59:10 am Baptiste Daroussin wrote: On Thu, Aug 30, 2012 at 01:02:06PM -1000, Doug Barton wrote: On 08/30/2012 07:32 AM, John Baldwin wrote: On Thursday, August 30, 2012 1:10:24 pm Chris Rees wrote: On 30 Aug 2012 18:03, John Baldwin j...@freebsd.org wrote: I agree with John on all counts here. Further, the idea of a self-installing package, at least for the pkg stuff itself, addresses the issue that someone else brought up about how to handle installation of pkg by the installer for a new system. I like the idea of also providing a self-installing package, and it seems really easy to do, so I'll try to see what I can do in this area I'll wrote a PoC in 5 minutes which looks pretty good, this could also be a very simple and easy way to integrate into bsdinstaller. I'll do work in that direction. Still it doesn't solve the problem of boostrapping pkgng in a fresh new box, because the user may not know where to download the pkg-setup.sh. I do think that is something bsdinstall should be able to handle, and I would certainly want bsdinstall to include a dialog that says do you want to install the package manager? -- John Baldwin ___ freebsd-po...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org Of course this is being worked on by dteske@ on his bsdconfig scripts, so yes in anycase the bsdinstaller will end up with a boostrap dialog to install pkgng. regards, Bapt pgp8QUPqB2WF5.pgp Description: PGP signature
Re: [CFT] Some updates to libc/rpc (second try)
On Fri, Aug 31, 2012 at 08:12:09AM -0400, John Baldwin wrote: On Friday, August 31, 2012 7:06:53 am Andrey Simonenko wrote: On Thu, Aug 30, 2012 at 02:37:17AM -0700, Garrett Cooper wrote: Detailed description of mistakes in these files and correct implementation: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/165710 A developer at $work (Isilon) developed a slightly simpler patch than that based on our custom 7.x sources recently to deal with concurrency issues in netconfig. I'll talk with a couple people to see whether or not the solution can be contributed back [after some polishing -- maybe -- and further testing]. Can you post changes and corrected bugs in getnetconfig.c and getnetpath.c in your (your $work) implementation. There is a thread on threads@ with patches to make the API thread-safe that I believe came from Isilon. It was posted in the last week or so, so it should be easy to find in the archives. Thank you for this information. I checked the logic of their changes. Making all data per-thread is wrong from my point of view. 1. Several threads can call getnetconfig() using the same handler obtained by setnetconfig(). If each thread has own FILE pointer, then some getnetconfig() will crash a program since fgets() will be called for NULL FILE pointer. 2. One thread can get handler by setnetconfig() and pass this handler to another thread and getnetconfig() will crash a program. This is the similar mistake, but getnetconfig() is not called in parallel. 3. Each thread has to open netconfig(5) database, parse its content every time for each getnetconfig() call since data is not cached. This is slow. There is one per-thread value, it is error code of the last failed function, this value cannot be kept in handler, since nc_perror() and nc_sperror() do not have handler argument. Since printing error is expected in the same thread when getnetconfig() failed (for example), I think this is Ok. If error is print in another thread, then we simply will not see correct error message, but program will not be crashed. I just commented only per-thread idea of data in getnetconfig.c, I do not compare my implementation, since their patch does not correct any other mistake described and corrected in my PR. ___ 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
On 31 Aug 2012 13:15, John Baldwin j...@freebsd.org wrote: On Friday, August 31, 2012 5:59:10 am Baptiste Daroussin wrote: On Thu, Aug 30, 2012 at 01:02:06PM -1000, Doug Barton wrote: On 08/30/2012 07:32 AM, John Baldwin wrote: On Thursday, August 30, 2012 1:10:24 pm Chris Rees wrote: On 30 Aug 2012 18:03, John Baldwin j...@freebsd.org wrote: I agree with John on all counts here. Further, the idea of a self-installing package, at least for the pkg stuff itself, addresses the issue that someone else brought up about how to handle installation of pkg by the installer for a new system. I like the idea of also providing a self-installing package, and it seems really easy to do, so I'll try to see what I can do in this area I'll wrote a PoC in 5 minutes which looks pretty good, this could also be a very simple and easy way to integrate into bsdinstaller. I'll do work in that direction. Still it doesn't solve the problem of boostrapping pkgng in a fresh new box, because the user may not know where to download the pkg-setup.sh. I do think that is something bsdinstall should be able to handle, and I would certainly want bsdinstall to include a dialog that says do you want to install the package manager? Putting aside my previous emotional red herring, this is a great idea; I don't see how it's different from a base binary, but OK. I don't see the need to be prompted-- it's not like the base system doesn't have other larger amounts of software that is useless to many. Can't it just go in? Chris ___ 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: Script to set/unset automatic status in PKGNG database
On Aug 30, 2012, at 11:56 PM, Matthew Seaman matt...@freebsd.org wrote:
On 30/08/2012 22:44, John Nielsen wrote:
After dialog(1) exits the script has a list of packages to mark as
automatic. Is there a non-SQL way to efficiently get the inverse?
I.e. the set { all_packages - new_automatic_package_list } ?
Use pkg query - it is really quite powerful. This shows all
non-autoremove packages as name-version:
pkg query -e '%a == 0' '%n-%v'
and this shows the port origin for all autoremove packages:
pkg query -e '%a == 1' '%o'
Thanks. I know about pkg query (and in fact my script uses something very much
like that to get the initial list of automatic packages). What I was trying to
do was get a list of packages installed but not in another list. The other list
represents _future_ automatic packages but not necessarily what is in the
database now.
In any case, I worked around it but first unsetting all packages and then
setting the user-selected list back to automatic.
JN
___
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: rpcbind does not honor -h flag
On Fri, Aug 31, 2012 at 3:42 AM, Борис Самородов b...@passap.ru wrote: 31.08.2012 12:34, Maxim Konovalov пишет: Please file a PR against rc ASAP. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/117711 I see. Thanks. 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. Scot ___ 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: Plugins support in pkgng
Marin Atanasov Nikolov dna...@gmail.com wrote: This is just to share with you that soon after the official 1.0 release of pkgng we now have basic plugins support in pkgng's development branch. [...] It's not perfect or covering everything, but it will give you a quick start though :) How about the ability to add new commands to pkg? For example something like pkg cutleaves via plugins would be cool. ___ 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: Plugins support in pkgng
On Fri, Aug 31, 2012 at 06:27:09PM +0300, Vitaly Magerya wrote: Marin Atanasov Nikolov dna...@gmail.com wrote: This is just to share with you that soon after the official 1.0 release of pkgng we now have basic plugins support in pkgng's development branch. [...] It's not perfect or covering everything, but it will give you a quick start though :) How about the ability to add new commands to pkg? For example something like pkg cutleaves via plugins would be cool. I think 'pkg autoremove' already does this. Glen pgp0yGjjJnPwV.pgp Description: PGP signature
Re: UFS journal error on 10.0-CURRENT
That's normally the case, yes, but not here. Are you saying that if using journal, inconsistencies in 'clean' fs are expected? Basically I'm saying that apparently here journal does nothing after enabling it. Usually after really hard power dip, I need to manually fsck as all symptoms of unclean fs are apparent. Maybe disabling; fsck; removing journal file; and reenabling it could fix it too? Yes, I'm afraid of it... -- View this message in context: http://freebsd.1045724.n5.nabble.com/UFS-journal-error-on-10-0-CURRENT-tp5739231p5739669.html Sent from the freebsd-current mailing list archive at Nabble.com. ___ 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
On 31-08-2012 14:22, Baptiste Daroussin wrote: On Fri, Aug 31, 2012 at 08:10:50AM -0400, John Baldwin wrote: On Friday, August 31, 2012 5:59:10 am Baptiste Daroussin wrote: On Thu, Aug 30, 2012 at 01:02:06PM -1000, Doug Barton wrote: I agree with John on all counts here. Further, the idea of a self-installing package, at least for the pkg stuff itself, addresses the issue that someone else brought up about how to handle installation of pkg by the installer for a new system. I like the idea of also providing a self-installing package, and it seems really easy to do, so I'll try to see what I can do in this area I'll wrote a PoC in 5 minutes which looks pretty good, this could also be a very simple and easy way to integrate into bsdinstaller. I'll do work in that direction. Still it doesn't solve the problem of boostrapping pkgng in a fresh new box, because the user may not know where to download the pkg-setup.sh. I do think that is something bsdinstall should be able to handle, and I would certainly want bsdinstall to include a dialog that says do you want to install the package manager? Of course this is being worked on by dteske@ on his bsdconfig scripts, so yes in anycase the bsdinstaller will end up with a boostrap dialog to install pkgng. ...using a mechanism that will be supported for the lifetime of the release. My concern is that the problem with the pkg tools was never that they were tied to FreeBSD releases. If that were true then you cannot accept the bootstrap solution above because it has exactly the same problems. The problem in my opinion was simply that the source code lived in src where ports developers didn't have good access to it. And the solution for that is to turn pkg development into a third party project and import that into base from time to time. There can also be a port for it so people can use more recent versions if they want to. That's the situation for several third party tools in base. Given that the ports tree is currently supporting both the old and new pkg tools I don't think it would be a problem for them to support older versions of pkgng when the time comes, especially since the database used by pkgng is much more flexible and you can execute any sql query on it. I also suspect that with pkgng's deployment features the temptation to package and deploy base with it are going to be bigger. And if that happens you want to ship a version of pkg on the release media and be able to do package management from the fixit shell. It would also be nice if the installation could fetch the latest security fixes for the release and install the latest packages so you don't have to install a browser with known vulnerabilities, etc. signature.asc Description: OpenPGP digital signature
Re: pkgng suggestion: renaming /usr/sbin/pkg to /usr/sbin/pkg-bootstrap
On Fri, Aug 31, 2012 at 8:47 AM, Tijl Coosemans t...@coosemans.org wrote: On 31-08-2012 14:22, Baptiste Daroussin wrote: On Fri, Aug 31, 2012 at 08:10:50AM -0400, John Baldwin wrote: On Friday, August 31, 2012 5:59:10 am Baptiste Daroussin wrote: On Thu, Aug 30, 2012 at 01:02:06PM -1000, Doug Barton wrote: I agree with John on all counts here. Further, the idea of a self-installing package, at least for the pkg stuff itself, addresses the issue that someone else brought up about how to handle installation of pkg by the installer for a new system. I like the idea of also providing a self-installing package, and it seems really easy to do, so I'll try to see what I can do in this area I'll wrote a PoC in 5 minutes which looks pretty good, this could also be a very simple and easy way to integrate into bsdinstaller. I'll do work in that direction. Still it doesn't solve the problem of boostrapping pkgng in a fresh new box, because the user may not know where to download the pkg-setup.sh. I do think that is something bsdinstall should be able to handle, and I would certainly want bsdinstall to include a dialog that says do you want to install the package manager? Of course this is being worked on by dteske@ on his bsdconfig scripts, so yes in anycase the bsdinstaller will end up with a boostrap dialog to install pkgng. ...using a mechanism that will be supported for the lifetime of the release. My concern is that the problem with the pkg tools was never that they were tied to FreeBSD releases. If that were true then you cannot accept the bootstrap solution above because it has exactly the same problems. The problem in my opinion was simply that the source code lived in src where ports developers didn't have good access to it. And the solution for that is to turn pkg development into a third party project and import that into base from time to time. There can also be a port for it so people can use more recent versions if they want to. That's the situation for several third party tools in base. Given that the ports tree is currently supporting both the old and new pkg tools I don't think it would be a problem for them to support older versions of pkgng when the time comes, especially since the database used by pkgng is much more flexible and you can execute any sql query on it. I also suspect that with pkgng's deployment features the temptation to package and deploy base with it are going to be bigger. And if that happens you want to ship a version of pkg on the release media and be able to do package management from the fixit shell. It would also be nice if the installation could fetch the latest security fixes for the release and install the latest packages so you don't have to install a browser with known vulnerabilities, etc. That seems easy to solve with symlinks and/or putting the tarball in the release directory, so that way bsdconfig downloads the copy that lives out in the release directory instead of the latest version in ports. Once development stabilizes a bit more, it might be wise to maintain multiple `release branches` of pkgng so it's possible to maintain the level of compatibility that FreeBSD users typically expect. Thanks, -Garrett ___ 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
On Fri, Aug 31, 2012 at 2:59 AM, Baptiste Daroussin b...@freebsd.org wrote: On Thu, Aug 30, 2012 at 01:02:06PM -1000, Doug Barton wrote: On 08/30/2012 07:32 AM, John Baldwin wrote: On Thursday, August 30, 2012 1:10:24 pm Chris Rees wrote: On 30 Aug 2012 18:03, John Baldwin j...@freebsd.org wrote: I agree with John on all counts here. Further, the idea of a self-installing package, at least for the pkg stuff itself, addresses the issue that someone else brought up about how to handle installation of pkg by the installer for a new system. ... Still it doesn't solve the problem of boostrapping pkgng in a fresh new box, because the user may not know where to download the pkg-setup.sh. A bit self-referential, but why not do something similar to what I proposed on http://docs.freebsd.org/cgi/getmsg.cgi?fetch=120111+0+current/freebsd-ports ? Thanks, -Garrett ___ 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
On 31 August 2012 16:47, Tijl Coosemans t...@coosemans.org wrote: On 31-08-2012 14:22, Baptiste Daroussin wrote: On Fri, Aug 31, 2012 at 08:10:50AM -0400, John Baldwin wrote: On Friday, August 31, 2012 5:59:10 am Baptiste Daroussin wrote: On Thu, Aug 30, 2012 at 01:02:06PM -1000, Doug Barton wrote: I agree with John on all counts here. Further, the idea of a self-installing package, at least for the pkg stuff itself, addresses the issue that someone else brought up about how to handle installation of pkg by the installer for a new system. I like the idea of also providing a self-installing package, and it seems really easy to do, so I'll try to see what I can do in this area I'll wrote a PoC in 5 minutes which looks pretty good, this could also be a very simple and easy way to integrate into bsdinstaller. I'll do work in that direction. Still it doesn't solve the problem of boostrapping pkgng in a fresh new box, because the user may not know where to download the pkg-setup.sh. I do think that is something bsdinstall should be able to handle, and I would certainly want bsdinstall to include a dialog that says do you want to install the package manager? Of course this is being worked on by dteske@ on his bsdconfig scripts, so yes in anycase the bsdinstaller will end up with a boostrap dialog to install pkgng. ...using a mechanism that will be supported for the lifetime of the release. My concern is that the problem with the pkg tools was never that they were tied to FreeBSD releases. If that were true then you cannot accept the bootstrap solution above because it has exactly the same problems. The problem in my opinion was simply that the source code lived in src where ports developers didn't have good access to it. And the solution for that is to turn pkg development into a third party project and import that into base from time to time. There can also be a port for it so people can use more recent versions if they want to. That's the situation for several third party tools in base. Given that the ports tree is currently supporting both the old and new pkg tools I don't think it would be a problem for them to support older versions of pkgng when the time comes, especially since the database used by pkgng is much more flexible and you can execute any sql query on it. Absolutely not. This is close to the top reason pkg has been moved to ports-- it should not be in base, because then we're stuck with supporting that version for a very long time. Chris ___ 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: Plugins support in pkgng
Glen Barber g...@freebsd.org wrote: How about the ability to add new commands to pkg? For example something like pkg cutleaves via plugins would be cool. I think 'pkg autoremove' already does this. Does autoremove show you all the leaves and ask which ones you want removed? I honestly don't know (and can't test at the moment); I assumed it only removed the ones with auto flag on. In any case, what I actually want is a pkg_cleanup alternative (i.e. cutleaves with a dialog(1)-like interface). There are other utilities that could benefit from being a plugin too. For example suggest plugin could use hooks on the build server to construct a database of binary name-package mapping, and add pkg suggest command on the client to query that database (e.g. pkg suggest ogg123 would suggest you to install audio/vorbis-tools, which is an idea that has been floating around). ___ 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: Plugins support in pkgng
On 8/31/2012 11:03 AM, Vitaly Magerya wrote: Glen Barber g...@freebsd.org wrote: How about the ability to add new commands to pkg? For example something like pkg cutleaves via plugins would be cool. I think 'pkg autoremove' already does this. Does autoremove show you all the leaves and ask which ones you want removed? I honestly don't know (and can't test at the moment); I assumed it only removed the ones with auto flag on. In any case, what I actually want is a pkg_cleanup alternative (i.e. cutleaves with a dialog(1)-like interface). No, because it already knows which you installed and which were pulled in as dependencies. There's a recent thread on ports@ regarding pkg2ng and marking your imported packages as automatic or not. See Script to set/unset automatic status in PKGNG database There are other utilities that could benefit from being a plugin too. For example suggest plugin could use hooks on the build server to construct a database of binary name-package mapping, and add pkg suggest command on the client to query that database (e.g. pkg suggest ogg123 would suggest you to install audio/vorbis-tools, which is an idea that has been floating around). Bryan ___ 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
On Friday, August 31, 2012 9:41:13 am Chris Rees wrote: On 31 Aug 2012 13:15, John Baldwin j...@freebsd.org wrote: On Friday, August 31, 2012 5:59:10 am Baptiste Daroussin wrote: On Thu, Aug 30, 2012 at 01:02:06PM -1000, Doug Barton wrote: On 08/30/2012 07:32 AM, John Baldwin wrote: On Thursday, August 30, 2012 1:10:24 pm Chris Rees wrote: On 30 Aug 2012 18:03, John Baldwin j...@freebsd.org wrote: I agree with John on all counts here. Further, the idea of a self-installing package, at least for the pkg stuff itself, addresses the issue that someone else brought up about how to handle installation of pkg by the installer for a new system. I like the idea of also providing a self-installing package, and it seems really easy to do, so I'll try to see what I can do in this area I'll wrote a PoC in 5 minutes which looks pretty good, this could also be a very simple and easy way to integrate into bsdinstaller. I'll do work in that direction. Still it doesn't solve the problem of boostrapping pkgng in a fresh new box, because the user may not know where to download the pkg-setup.sh. I do think that is something bsdinstall should be able to handle, and I would certainly want bsdinstall to include a dialog that says do you want to install the package manager? Putting aside my previous emotional red herring, this is a great idea; I don't see how it's different from a base binary, but OK. I don't see the need to be prompted-- it's not like the base system doesn't have other larger amounts of software that is useless to many. Can't it just go in? We could also do that. I had imagined something similar to sysinstall's Do you want to browse the packages collection and install packages dialog and that choosing yes to that in bsdinstall/bsdconfig would bootstrap pkgng when you say yes to that. However, I'm not opposed to just installing pkgng by default. -- John Baldwin ___ 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] Add locking to aha(4)
I have patches to add locking to aha(4) and mark it MPSAFE. The patches are from HEAD but should apply to 8 or 9. If you test it on 8 or 9 please enable INVARIANTS for at least the initial testing. Thanks. http://www.FreeBSD.org/~jhb/patches/aha_locking.patch -- John Baldwin ___ 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
Hi, I think the details of the patch would need to be worked out a bit, but I think you are on the right track. I think it would be nice to: (1) Have deprecation warnings in the legacy pkg_* tools. If someone types pkg_add, maybe warn them that it is deprecated, and they should read UPDATING and type pkg help add. (2) If $PKG_DBDIR/local.sqlite exists (usually /var/db/pkgs/local.sqlite), and someone types a legacy pkg_* command, then error out and warn them to use the new pkg equivalent. When I was playing with pkgng, I ran into some confusion when I typed the old commands after I had migrated my package database to the new system, so I have seen how this can be confusing for first-time users. Any *sensible* anti-foot shooting measures and useful diagnostics/warnings that we can put into the tools would help a lot. -- Craig Rodrigues rodr...@crodrigues.org On Sun, Aug 26, 2012 at 4:09 PM, Garrett Cooper yaneg...@gmail.com wrote: Rather than providing a solution for that problem because that's a bigger architectural issue (and not my job to solve), I offer this patch I quickly hacked up instead as my 2 cents for the discussion on how to make users aware that pkg_install is dying/dead, as this is one case that needs to be better handled. Thanks, -Garrett ___ 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: Can't build FreeBSD-head with CLANG
On 2012-08-30 18:43, Eir Nym wrote: On 30 August 2012 20:16, Dimitry Andric d...@freebsd.org wrote: ... It seems the WERROR= in the xfs module Makefile was right there from the start, but it was never removed. I have compiled it using gcc, and there are actually no warnings from gcc at all. With clang, there are several warnings, so I have added a few workaround -Wno-xxx flags for them. I committed the fixes in r239959. I tried building your GENERIC_PF kernel configuration, and it worked just fine 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
[PATCH] Add locking to ahb(4)
I have patches to add locking to ahb(4) and mark it MPSAFE. The patches are from HEAD but should apply to 8 or 9. If you test it on 8 or 9 please enable INVARIANTS for at least the initial testing. Thanks. http://www.FreeBSD.org/~jhb/patches/ahb_locking.patch -- John Baldwin ___ 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: Plugins support in pkgng
On 31 August 2012 09:15, Bryan Drewery br...@shatow.net wrote: No, because it already knows which you installed and which were pulled in as dependencies. There's a recent thread on ports@ regarding pkg2ng and marking your imported packages as automatic or not. There is a usecase for looking at all the leaf ports one by one and deciding if you want to keep them, recursively, regardless of the automatic flag. Even if this isn't provided by default, it would be nice for plugins to be able to do this. :) -- Eitan Adler ___ 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: Plugins support in pkgng
On 8/31/2012 10:15 PM, Eitan Adler wrote: On 31 August 2012 09:15, Bryan Drewery br...@shatow.net wrote: No, because it already knows which you installed and which were pulled in as dependencies. There's a recent thread on ports@ regarding pkg2ng and marking your imported packages as automatic or not. There is a usecase for looking at all the leaf ports one by one and deciding if you want to keep them, recursively, regardless of the automatic flag. Even if this isn't provided by default, it would be nice for plugins to be able to do this. :) Apparently pkg_cutleaves supports pkgng now anyhow. Bryan ___ 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
