Re: shells/ksh93 install fail
On Wed, Jun 22, 2011 at 02:01:28PM -0700, Doug Barton wrote: > On 6/22/2011 1:28 PM, Sunpoet Po-Chuan Hsieh wrote: > > On Tue, Jun 21, 2011 at 01:23:51PM -0700, Doug Barton wrote: > >> On 6/21/2011 1:02 PM, jhell wrote: > >>> > >>> > >>> On Tue, Jun 21, 2011 at 12:48:57PM -0700, Doug Barton wrote: > >>>> An effort to upgrade to 20110208_1 is failing for me: > >>>> > >>>> ===>Installing for ksh93-20110208_1 > >>>> ===> Generating temporary packing list > >>>> ===>Checking if shells/ksh93 already installed > >>>> install -o root -g wheel -m 555 > >>>> /usr/local/tmp/usr/ports/shells/ksh93/work/bin/ksh /usr/local/bin/ksh93 > >>>> install: $WRKDIRPREFIX/usr/ports/shells/ksh93/work/bin/ksh: No such file > >>>> or directory > >>>> *** Error code 71 > >>>> > >>>> Is it possible that $WRKDIRPREFIX is the trigger? > >>>> > >>> > >>> I did not actually see that here on 8-STABLE/i386, just for the record. > >> > >> Thanks. At least one person on IRC said that it worked for them with > >> or without $WRKDIRPREFIX, so that's probably not it. What's odd is > >> that these package building systems have been working fine for > >> hundreds of ports for quite a while now, so I'm stumped. > > > > Hi Doug, > > > > I have WRKDIRPREFIX=/usr/ports/works in /etc/make.conf. I'm running a > > 8-STABLE amd64. Do you need me to generate a build log for you to > > further investigate this problem? > > > > BTW, did you run 'find' to search for ksh? The binary must be somewhere > > in the WRKSRC. It might be helpful to know the path of ksh. > > It didn't exist at all. However I think I found the problem. If I remove > the STATIC option everything goes as planned. Perhaps that gives you a > new area to examine? Hey Doug, Can you give this a shot in (usr/ports/shells/ksh93/Makefile) Change this: .if defined(WITH_STATIC) MAKE_ENV+= LDFLAGS=-static .endif To: .if defined(WITH_STATIC) MAKE_ENV+= LDFLAGS+=-static .endif I am getting the distinct feeling here that the ksh binary is not being linked correctly because the override of LDFLAGS causing only -static to be used. You should be able to verify this somewhere either in the output from the build whether the linkage had failed or by verifying that the binary exists in your object tree. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: shells/ksh93 install fail
On Tue, Jun 21, 2011 at 01:23:51PM -0700, Doug Barton wrote: > On 6/21/2011 1:02 PM, jhell wrote: > > > > > > On Tue, Jun 21, 2011 at 12:48:57PM -0700, Doug Barton wrote: > >> An effort to upgrade to 20110208_1 is failing for me: > >> > >> ===> Installing for ksh93-20110208_1 > >> ===>Generating temporary packing list > >> ===> Checking if shells/ksh93 already installed > >> install -o root -g wheel -m 555 > >> /usr/local/tmp/usr/ports/shells/ksh93/work/bin/ksh /usr/local/bin/ksh93 > >> install: $WRKDIRPREFIX/usr/ports/shells/ksh93/work/bin/ksh: No such file > >> or directory > >> *** Error code 71 > >> > >> Is it possible that $WRKDIRPREFIX is the trigger? > >> > > > > I did not actually see that here on 8-STABLE/i386, just for the record. > > Thanks. At least one person on IRC said that it worked for them with or > without $WRKDIRPREFIX, so that's probably not it. What's odd is that > these package building systems have been working fine for hundreds of > ports for quite a while now, so I'm stumped. > How about your WRKDIRPREFIX var in make.conf ? I have mine set here to: WRKDIRPREFIX?=/usr/obj Also contained within an .if conditional for ports but that shouldnt matter. Though the difference of having something like ':=' '?=' '=' I don't think should make much of a difference unless something else strange is being set or happening elsewhere. Just a thought. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: shells/ksh93 install fail
On Tue, Jun 21, 2011 at 12:48:57PM -0700, Doug Barton wrote: > An effort to upgrade to 20110208_1 is failing for me: > > ===> Installing for ksh93-20110208_1 > ===> Generating temporary packing list > ===> Checking if shells/ksh93 already installed > install -o root -g wheel -m 555 > /usr/local/tmp/usr/ports/shells/ksh93/work/bin/ksh /usr/local/bin/ksh93 > install: $WRKDIRPREFIX/usr/ports/shells/ksh93/work/bin/ksh: No such file > or directory > *** Error code 71 > > Is it possible that $WRKDIRPREFIX is the trigger? > I did not actually see that here on 8-STABLE/i386, just for the record. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
sysutils/zfs-stats update
Hi Martin,
Would you mind adding the following to sysutils/zfs-stats/pkg-descr as
well here, http://www.vx.sk/zfs-stats/.
{{{
zfs-stats was branched from a previous revision of the original authors
code that is still maintained at the following URL. You may be interested
in some of the improvements that were made.
http://jhell.googlecode.com/hg/base/head/scripts/zfs/arc_summary/arc_summary.pl
}}}
A shorter URL for that is: http://bit.ly/arc_summary
If not, I do not mind taking maintainership of that port and rolling out
dated revisions in the download section that would coinside with the
release of the port.
The current version that I have up now is up-to-date as of ZFSv28,
supports flags to display single pages of information and defaults to a
display of all pages as well has human readable output for all the
values + increased system memory display in the header.
As I cleaned this up quite a bit from what it used to be before I got my
hands on it for FreeBSD usage I would like to contain the differences in
the least amount of branches for the users sake. As for right now ? I do
not plan on not maintaining it and have further improvements on the way.
You can consider this a public request for maintainership.
I see a much simpler port that doesnt need to fetch a tarball in the
near future and would appreciate your support in doing so.
--
Regards,
J. Hellenthal
JJH48-ARIN
0x89D8547E
pgpgdQR1ai61V.pgp
Description: PGP signature
Re: Options JAIL in jdk16 port
On Fri, Apr 01, 2011 at 01:27:18PM +0400, Subbsd wrote: > Hi > > Сan someone explain that option JAIL means for JDK16 when this builds > within jail ? > I have not found any specific mention in the patch or the code: > > grep -Ri jail /usr/ports/java/jdk16/* > /usr/ports/java/jdk16/Makefile: JAIL"Port is being built > within a jail" off > > and nothing more. Hi, This is for when you are using jail(8) and have a build environment setup within that jail for ports. If you enable that option then it allows you to be able to build jdk16 within the jail. Other than that, there is no special meaning to functionality of jdk. -- Regards, J. Hellenthal JJH48-ARIN 0x89D8547E pgpLfRmIozzOr.pgp Description: PGP signature
Re: xf86-video-ati 6.14.0 crashes System
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 1 Mar 2011 15:22, kamikaze@ wrote: On 27/02/2011 23:05, David Demelier wrote: On 27/02/2011 21:50, Christian Weisgerber wrote: Christoph Moench-Tegeder wrote: after update tu the new xorg on my FreeBSD8 my system crashes all time I start X. Same here with Also reported by me for the ATI Radeon RV370 X300 SE and somebody else for a differently branded card with the same chip. When using the ati/radeon driver, the system crashes too fast to leave any log (literally, Xorg.0.log was not changed), so I can't provide any information from there. Yup. As a workaround, install the version 6.13 driver. A separate port has been created for it. # portupgrade -o x11-drivers/xf86-video-ati613 xf86-video-ati That's sad, yet another panic :(. This time that's me who is lucky. I've got a radeon 4330 and it's working absolutely fine. Just to put this thread into context, the new driver improves the situation for some people, of course you don't see them complaining here. In light of this just for testament, it has improved the performance of my Radeon 9700 Pro (R300). My machine has 2 ATI cards, one onboard (HD4200) and one in the PCIE slot (HD5770). The new driver allows me to switch back to the console when using the HD5770. Just one card here in the AGP slot of this old mother board. Some tweaking that I had to do in order to get it to behave was switch it to PCI mode, and a few other things listed here: Option "DMAForXv""off" Option "BusType" "PCI" Option "AccelMethod" "XAA" Option "DynamicPM" "on" Option "Int10" "on" Option "DRI" "off" Option "RenderAccel" "on" Keep in mind though that this is a hacked up machine with a new video card in even older hardware so settings mentioned here will rarely match new machines with equally new hardware. In conjunction with the Xorg upgrade a reproducible panic with certain combinations of BIOS and xorg.conf configurations disappeared. These combinations still don't work, but instead of panicking the system, the Xorg process can be killed and the xorg.conf can be changed to a working configuration without a reboot or risk of data loss. No panics here because of the driver or new X.org but until the settings above were put into place and after a few thousand redraws of a browser on this system I was left to hit the power button and wait for watchdog to kick in and shut the system down because a frozen non responsive screen. All is well now. Thanks for the upgrades! nice job to all! Regards, - -- jhell -BEGIN PGP SIGNATURE- Comment: THIS SOFTWARE AND/OR CONTENTS IS PROVIDED BY THE AUTHOR ``AS IS'' AND Comment: ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE Comment: IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR Comment: PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY Comment: DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL Comment: DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS Comment: OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) Comment: HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, Comment: STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING Comment: IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE Comment: POSSIBILITY OF SUCH DAMAGE. iQEcBAEBAgAGBQJNbb18AAoJEJBXh4mJ2FR+NygH/iYcfiu2NEutcVAQuSlmLQER hZlPMA8upZHT4DI1134UMzFZMPE+rdXH7mlENk7EFTqTr/HF4TV+eftqgqY9m8fk n0vzci64y1zWXKSYF2YetXIwg8nFostiplC2jPnBqdQnflB7+d1QhDbha3gAwDiw O29x62df5H+amgkOX/cxnnE1u/uXporWwOvJVEzFtecY7K+eEufC5vL0IVkaBOcD gcoL/snWULLtpFatdBX35v1L4M5XUtaIkzQRbxpso1bZSAN4Uxn8r2oQqj03HVKb ww9Ug+dJ0i16eye32ha09fqJYkIxw5TZ7fPorUvzSr2lVAfCeMlwiGB6q6mXHLw= =987g -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
net/samba-libsmbclient SAMBA_PORT= -> SAMBA_PORT?=
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Timur, Could you please change the SAMBA_PORT= directive in samba-libsmbclient to SAMBA_PORT?= samba34 so it can be overridden by make.conf or command line ? There is probably some bad magic that will happen on a machine with samba35 installed and libsmbclient34 and I would like to stay as close as I can to using the same version of samba that's installed and making the above corrections would still allow for the current functionality to be kept while allowing an override. Specifically I would like to stay away from having to edit anything in the ports structure Makefiles as those changes would not be static across port snaps. Thanks in advance. - -- jhell -BEGIN PGP SIGNATURE- Comment: THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND Comment: ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE Comment: IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE Comment: ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE Comment: FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL Comment: DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS Comment: OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) Comment: HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT Comment: LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY Comment: OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF Comment: SUCH DAMAGE. iQEcBAEBAgAGBQJNbIg9AAoJEJBXh4mJ2FR+M1kH/iVXErTNcK9G8ZYydTst2ihD 7sCAl6yhjfRlO7NIzdOMBbisfe8yY4yM6v1npFqHuFfF29GbfFR7CJ3ElGswlI0p Vx5iyStsDzpXr/aT4T0Tc9KyRdm+ZCLd+mIhuhL82l8JoEkhw6u8tlZ4mkVBE+Hx 5dHphmUizqeXEyjqs9e0YCcgR5M15hOHmD8gBwH4xLXgMLeIC3+zJd8vkd52S7yk ShEdqhJQmaTnOxbZYPXihVfJtaPxFjCsfBgi4zBs3mnBstv4izNAS1nhRIfAYXXP SLcgPZje1A3m5KPUQfWiwNwY0/YtPpvpRWlQ2uxHmmPdGbShj+miSLzWAtznOeA= =ypF4 -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Find a corrupt port
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Content-Transfer-Encoding: QUOTED-PRINTABLE These are all very good suggestions but a simpler solution that someone dearly known as Doug Barton (dougb@) has already put a lot of work into. So instead of hacking it up and throwing a bunch of script at a user... lets give credit where credit is due! portmaster --check-depends If you do not have it already you can get it from (ports-mgmt/portmaster) On Sat, 26 Feb 2011 16:50, demelier.david@ wrote: On 26/02/2011 17:34, Sergio de Almeida Lenzi wrote: I use this script to get rid of the problem the script detects @pkgdep record without argument and deletes it from the +CONTENTS file in the /var/db/pkg/* directory === for i in /var/db/pkg/*/+CONTENTS do if grep -q "@pkgdep $" $i then sed -i "" -e "/@pkgdep $/d" $i echo nullpkg in $i fi done == Em Sáb, 2011-02-26 às 15:22 +0100, David Demelier escreveu: Hello, It seems I have a corrupted port on my system : $ pkg_info [...] dmxproto-2.3DMX extension headers pkg_info: corrupted record (pkgdep line without argument), ignoring pkg_info: corrupted record (pkgdep line without argument), ignoring pkg_info: corrupted record (pkgdep line without argument), ignoring pkg_info: corrupted record (pkgdep line without argument), ignoring docproj-1.17_4 The"meta-port" for the FreeBSD Documentation Project [...] Because it happens after dmxproto O tought it was this one, but after a make deinstall reinstall in x11/dmxproto the corrupt message is still there so I'm guessing if it's the corrupted port. How can I easily find? Cheers, There is something absolutely easier : egrep '^@pkgdep $' /var/db/pkg/*/+CONTENTS Cheers, Regards, - -- jhell -BEGIN PGP SIGNATURE- Comment: THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND Comment: ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE Comment: IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE Comment: ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE Comment: FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL Comment: DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS Comment: OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) Comment: HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT Comment: LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY Comment: OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF Comment: SUCH DAMAGE. iQEcBAEBAgAGBQJNabmfAAoJEJBXh4mJ2FR+W+cH/2jYtFxPZHFHba+0s9y2LSWy 6awmtUgNFDFG+ZxPnDvrWLAmAaNbhSBVdLNxNtOa+1uXsN6+QqPcE/qwUK/PigZ2 xfUkhoLhGbjgtRfX45Ko+aN01tGiCL9lz6+mE5YwNTwT8rirlQiA2HXHsq9tF8eX prQYrtGzzfwd8z9vYC5IOUbEI7cAobe4UD2pizA3ZLk+JsbD654P6Mf+wrwztDO7 3qiOs/4krTjoaXj344mjfe55c4y1mBTJTX4PVKWAcCFgCC8czGZzXB/ad3PlxKl7 GpqI1F6hysvDWxkEMz/bmILf1hNIskt3okCm1ZNyOSywkR45vtCc06edTctBHn0= =Wam5 -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS UP] Python Infrastructure changes Roadmap
On Sun, 6 Feb 2011 14:34, cvs-src@ wrote: 06.02.2011 18:36, Martin Wilke ?: [python 2.7 move to default] python 2.7 is already stable enough to be moved over as default. For this one we will do an exp-run to make sure nothing will break during the build. If all works fine, we think we can complete it by the first week of March. Good news! Just want to note that i'm using python2.7 as the only python version for a couple of months now. It's a common gnome desktop and many of third-party python apps from ports. All of them working smoothly with 2.7, w/o any problems. On that note out of every python app that I use there has only been one problem not really vital (ports/devel/py-psyco) does not seem to build against 2.7 and I assume that would be the same for ( > 2.7 ) Bails here: (i386 only afaik) In file included from c/initialize.h:55, from c/psyco.c:14: c/mergepoints.c:242: error: 'JUMP_IF_FALSE' undeclared here (not in a function) c/mergepoints.c:242: error: 'JUMP_IF_TRUE' undeclared here (not in a function) error: command 'cc' failed with exit status 1 *** Error code 1 Regards, -- jhell ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: libxul build hit the roof!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/29/2010 18:04, Da Rock wrote: > I got it worked out in the end, but it still took 2G+ memory to build; > so my suggestion is a warning to EU in the make process that this could > take a lot of memory to build, and some suggestions as to how to prevent > or workaround the problem so they don't go whining on the list about it > being broken. Turning off OPTIMIZED_CFLAGS for 'libxul, firefox* & thunderbird*' ports would have stopped all this swapping from happening. Is there a specific reason why you changed it from its defaults ? is there really anything to gain ? in respect to 'libxul'... Regards, - -- jhell,v -BEGIN PGP SIGNATURE- iQEcBAEBAgAGBQJNHLeVAAoJEJBXh4mJ2FR+PKcIAIa7GY1eR9QP1hd2PL/LRrXa sBmqHmCjThOzPDB7NL49EP7VHMDnKI9UPyTM41OmM3r7utdMQHNLb7DJT/qlayeg +Mkv4LnFrWVbOVO0Hby38ABkMO25HHhJDvbk0G4l+B0Fa1W5WOaAqCncoIRQZ7dS bgj5Ju9xrMjh3kf34qNfSI12mRbyob0v72sC7Z1UZbMn8GJXmPUyCKxogrA6lcAW Y26KeJl8N+Y7wLG20yGwAl28xwCQ4P2kvg0YwvffRm+OIGmWj8rqZiEbKzPL1RMb j7BF9+g0JA0TiKp4rr5wwO8ioNFacQz2WJ6Uy3mPw1xo/ivKsrNVzcqO4plwl9Q= =2UTN -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: portmaster: print /usr/ports/UPDATING on update
e port being developed rather than an outside tool. 4). If this is only relevant to when a ports tree is available and binary packages are not being used then there is no sense in injecting user-land tools into the world. Conclusion & with all due respect XML & JSON along with user-land tools are a lame temporary solution to a longer standing problem and there is a lack of framework that allows a developer to properly inform the user of changes that might effect an upgrade. ``bsd.updating.mk'' might be a better longer term solution that would allow a maintainer to alert the user with a simple "All done reading ?" and a spill of output that effects that port up-to version being upgraded. And yes XML and-or JSON could surely play a part in this as well. JST Regards, - -- jhell,v -BEGIN PGP SIGNATURE- iQEcBAEBAgAGBQJNGevwAAoJEJBXh4mJ2FR+r08H+wfNRp8Ks0VfZEbUqDbuvea+ kUPYSe1xvYkoC5CBiA3bBjEmAb7YIShMGemS3sU+Jc3FoZjAS3irbsQahpCEsooj 3gt1p72vaaKwE5L1yQUoiXH+gPxCobMS7fwn1hDz1lbZqSMb75jn/MZZ+8qcvXWw N8APAeFGNbs4xA94FTa39xzo5yZjF73lrEzHc+9NdbrknN21/EBE3p5DgMNS+aX1 Z9uaDqERKPFf+19hCb+VcVBxoaRYv1P7UVeAz+GnNa/EtccPK0iIww1TNX9n+qnS EaO58vgQDcAOePjBYrWXoUDbN+lkUYIvtZSrxCTwBdOdxOCRHEp9lNihYyDuiEQ= =EsqM -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Announce: the utility that dumps CVS logs for any port
On 12/13/2010 16:22, Alexander Gromnitsky wrote: > Hi, > > There is a small program--portvcs[0] that can feed your terminal with > logs for a particular port from CVS server. It's useful for those of > us who hates to browse cvsweb with firefox. > > For example, you can type: > > % portvcs www/firefox > > and it dumps logs for firefox (by default from now to 1 year ago). Or: > > % pwd > /usr/ports/x11-toolkits/gtk20 > % portvcs Makefile > > to see logs for gtk20. > > To install portvcs type: > > # gem install portvcs > > Warning: it requires Ruby 1.9.2 (and no other dependencies). Make sure > you have > > RUBY_DEFAULT_VER=1.9 > > in /etc/make.conf. Or install portvcs under RVM[1]. After installation > type: > > % ri PortVCS > > to get additional help. > > > [0] https://github.com/gromnitsky/portvcs > [1] http://rvm.beginrescueend.com > > Now there is something useful! Thanks for this! -- jhell,v ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: building ports/net/netcat
On 12/03/2010 06:18, Ferruccio Zamuner wrote: > Hi, > > u1# make > ===> Vulnerability check disabled, database not found > ===> License check disabled, port has not defined LICENSE > ===> Found saved configuration for netcat-1.10_3 > ===> Extracting for netcat-1.10_3 > => SHA256 Checksum OK for nc110.tgz. > => SHA256 Checksum OK for nc-v6-2918.patch.gz. > ===> Patching for netcat-1.10_3 > ===> Applying distribution patches for netcat-1.10_3 > ===> Applying FreeBSD patches for netcat-1.10_3 > /usr/bin/sed -e 's|%%DOCSDIR%%|/usr/local/share/doc/netcat|g' > /faster1/ports/net/netcat/files/nc.1 > > /faster1/ports/net/netcat/work/netcat.1 > ===> Configuring for netcat-1.10_3 > ===> Building for netcat-1.10_3 > make -e nc XFLAGS='-DFREEBSD -DIPV6 -DTELNET -DGAPING_SECURITY_HOLE' > STATIC=-static > cc -s -O2 -pipe -fno-strict-aliasing -DFREEBSD -DIPV6 -DTELNET > -DGAPING_SECURITY_HOLE -static -o nc netcat.c > netcat.c: In function 'doexec': > netcat.c:724: warning: incompatible implicit declaration of built-in > function 'execl' > A release that you are building on and related information would be helpful. Just-in-case... You do know that netcat comes in the source tree for FreeBSD sometime greater than 7.X correct ? -- jhell,v ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Ports - installation & upgrade history
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/30/2010 13:24, David Southwell wrote: > > Hi > > I was idly wondering how easy/difficult it might be to maintain and access an > historical record of port installations and upgrades on a particular system. > > Something fairly comprehensive that would enable one to see when a port was > first installed, its original version number, when it was > upgraded/deinstalled/reinstalled and subsequent changes to the installed > version. Maybe also time/date when a port tree was updated and which ports > were affected by those updates. > > I dont suppose there a convenient way of obtaining this information by > default? If not is there a port which would do it? > > Thoughts You might find the following handy. This is certainly not perfect and just a ``my use case scenario'' but I use a hg(1) or Mercurial repository in the package directory to keep track of these things along with a script[1] to update the repository after upgrades and installs that also sends an email once complete. And of course the repository itself has to be modified a little by adding necessary files I have provided at URL[1] and allows you to use pkg_info(1) on the .hg directory for information. Sample email output by default mailed to r...@localhost provided in signature. And of course the output of hg(1) run manually in the package directory can also provide you with more verbose output as well as diffs of changes to the files. I originally did this using svn(1) but converted it to using hg(1) because Mercurial only uses one directory in the package root rather than several in each package directory. This could also be converted to using git(1) as well but have not had a need for it as of yet and as I am more attracted to the use of Mercurial over git. [1] http://code.google.com/p/jhell/source/browse/base#base/projects/pkg_commit Regards, - -- changeset: 327:aef99c54e36c tag: 8.2-PRERELEASE user:J. Hellenthal date:Mon Nov 22 10:56:04 2010 -0500 description: Package database update by pkg_commit(1) Addendum: py26-zfs-1_1 Deprecated: py26-zfs-1 Modified: python26-2.6.6 jhell,v -BEGIN PGP SIGNATURE- iQEcBAEBAgAGBQJM9dyDAAoJEJBXh4mJ2FR+420H/RP5w4i65Eb4ud8zOAIeRV9P mJMthD18VX5LNtmOLOAQ1xcjFo0/bx44sHQl9NqlucF6SgDs0OCmXzUKpcSyVqWb JQipxHjnKnxhp5oiBZg6889F+8oeA7A1CxlE59AaN9vMT808H2RGy3rgLl4A38WR XxHA6SIMe/tS6vAtuPARMrAlF44Rc3FilaU9nSMS3G2XnQaITyUjsIhIolSk2wYZ l2LV7q/Q8fRhkrMiwOCMFqe8gU8lG3+iMfGQX8UGNXxO3pMgW/hA3yxLD8rNORxy KFVBL6cHlmF+6xvGshWFzf8vf7PDOcVz87zJ6Y0dpXfTpylEp30Nwx7w1LVrnug= =gFkj -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: packages compressed with xz
On 11/29/2010 18:40, Matthias Andree wrote: > Am 29.11.2010 19:31, schrieb jhell: > >> Adding to this, as the manual says... The decompressing host will need >> to have at minimal 5% -> 20% of memory 'available' for decompression of >> what the compressing host had. Seeing as FreeBSD still runs on systems >> with memory as little as 200MB "~20% of 1024MB" and quite possible to >> run on systems with memory of 64MB "~5% of 1024MB" I would not see any >> benefit in modifying the default memory limit on a compressing host to >> accommodate for these system rather than using gzip(1) or bzip2(1) by >> default. > > You can specify limits during compression, so the question is should we do > that > so that hosts with N MB of RAM can decompress packages? Do we retain the > compression ratio over bzip2 if we limit compression memory to 512 MB so that > decompression would be possible with, say, 128 MB? > Hosts that have [N]MB of "free or available" memory. Most systems in this case will not have a whole lot of RAM available in any case as they are likely to be utilizing it to its upper most potential. Doing such limiting on the compressors part I would think, be more of a waste of resources as such can be achieved by default just sticking with bzip2(1). Besides, limiting memory to 512MB to what ? shave an ~ small percentage off the top of a resulting package. >> It would be nice to support xz(1) compression for large selective >> packages like firefox or openoffice as those will never run on smaller >> systems. > > Yes, would be nice. I doubt it will happen soon. > Agreed. Soon can be quantified by actual need and of which there is not much need except for larger packages but adding this would just add unneeded complication to the system that is already in place. ~ JMO -- jhell,v ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: packages compressed with xz
On 11/29/2010 06:24, Matthias Andree wrote: > Am 28.11.2010 22:12, schrieb Goran Tal: >> Now that the base system supports xz compression, it should be used as >> the default compression for packages. >> >> Files compressed with xz are smaller and decompress faster than those >> compressed with bzip2. This can make an installation much quicker, >> especially when the complete system is installed or upgraded. >> >> Any reasons against it? > > xz compressed files can take up CONSIDERABLY more memory to decompress > than files compressed with bzip2 or gzip. Keep that in mind so that > systems that are low on memory can still decompress xz packages. If you > don't fit into RAM for decompression, it will be unusable. Adding to this, as the manual says... The decompressing host will need to have at minimal 5% -> 20% of memory 'available' for decompression of what the compressing host had. Seeing as FreeBSD still runs on systems with memory as little as 200MB "~20% of 1024MB" and quite possible to run on systems with memory of 64MB "~5% of 1024MB" I would not see any benefit in modifying the default memory limit on a compressing host to accommodate for these system rather than using gzip(1) or bzip2(1) by default. It would be nice to support xz(1) compression for large selective packages like firefox or openoffice as those will never run on smaller systems. -- jhell,v ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: devel/p4d x2 Makefile error.
On 11/25/2010 10:08, Andrzej Tobola wrote:
> % grep MASTERDIR /usr/ports/Mk/bsd.port.mk
> # MASTERDIR - Where the port finds patches, package files, etc.
> Define
> MASTERDIR?= ${.CURDIR}
Not really clear on what your trying to advise here. Even though that is
in bsd.port.mk it still does not change the operation as to when
WRKDIRPREFIX has been set to somewhere else.
What are you saying here ?
--
jhell,v
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
devel/p4d x2 Makefile error.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Attached is a patch that fixes up the Makefile if you happen to be using
a different WRKDIRPREFIX than the default of ${.CURDIR}.
Currently the Makefile assumes that pkg-message is in the object
directory which obviously it would not be unless copied. So a cat(1) of
that results in installation being aborted.
Regards,
- --
jhell,v
-BEGIN PGP SIGNATURE-
iQEcBAEBAgAGBQJM7gMtAAoJEJBXh4mJ2FR+zTEH/05XY2axBzCeJQPExRxf4lsF
aa13tNIH8GoTs7ZCndaajtVTUx5h31E/LE4LqmwW3eQ6i0cWgUkG6jbrnyhRNUgg
f287i2LdaYrp0DF2aZ6n5FlQLs4ogh3o20PXJAOyhQ8is4efcN/AI71xdAHw/ncg
gRlpuJke/8pe8lFWtYH5Z8gOam07u4su1tDDV3DvTVszE082h/017AX/MLAfufIP
QEE8tFyFjdDxAzyh7Hg3BduXebp3Espx36MurN6rL0jEbDdjKd5QIfPL0EzSHsrD
Z1zXca7CJd6coVwgO5gsyX9CzAZfCMoOEWSiHTPwoOPPpPVEzb/VEpjx3z+UqrY=
=TmfB
-END PGP SIGNATURE-
--- Makefile.orig 2010-11-25 01:23:32.753968347 -0500
+++ Makefile2010-11-25 01:25:11.503421041 -0500
@@ -49,7 +49,7 @@
${INSTALL_PROGRAM} ${_DISTDIR}/p4d ${PREFIX}/sbin/
post-install:
- @${CAT} pkg-message
+ @${CAT} ${.CURDIR}/pkg-message
${MKDIR} ${DESTDIR}${P4ROOT}
${CHOWN} p4admin:p4admin ${DESTDIR}${P4ROOT}
${CHMOD} 750 ${DESTDIR}${P4ROOT}
-BEGIN PGP SIGNATURE-
iQEcBAABAgAGBQJM7gMuAAoJEJBXh4mJ2FR+ev8H/iN/9BUaWAyPcRLV16fnHD61
5NBwElPSYdt+rWHxNTnl+1AZSOVO5VC0lKkHB2230JMvFdMCycaR87AgU6BmLFJd
Pi/xYx4rR5G7OqVNTyT5DChpZdAcoQReYlPXsrkMTSZmDcFnBo8ktV+cj+7B5klo
ebVUAmi6E33Vv1S5APU3/U7S55gmsZSe+4XrdQHiC312gnYX/XLSlbyx3mFkqpyA
dWID1quxIBh2dDf7I6/jLEm/wzhVa3cTsctMp3tdozZGO6zM07myHLMw9Tw/kIuF
JcmMDzZZV4s7dgaMtLQ0LZd2yLFnOaPQ2+Q7604YVOiC7odtyEQIynsT4BaIWZg=
=wOo9
-END PGP SIGNATURE-
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Conflict between netpipes-4.2 and timelimit-1.7
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The above two listed ports have a conflict with the installed binary '/usr/local/bin/timelimit' but do not list each-other as a conflict and should be adjusted to reflect the conflict with one-another. $ pkg_info -qW /usr/local/bin/timelimit pkg_info: both netpipes-4.2 and timelimit-1.7 claim to have installed /usr/local/bin/timelimit This could also be said for its manual pages as well. After removing the timelimit-1.7 package and then upgrading netpipes-4.2 ===>>> Creating a backup package for old version netpipes-4.2 tar: man/man1/timelimit.1.gz: Cannot stat: No such file or directory tar: bin/timelimit: Cannot stat: No such file or directory tar: Error exit delayed from previous errors. pkg_create: make_dist: tar command failed with code 256 ===>>> Package creation failed for netpipes-4.2! Though the functionality provided by both timelimit commands are fundamentally the same, timelimit-1.7 offers quite a bit more control over the one that ships with netpipes-4.2 without the need to install files like 'faucet' that may act as a network server. Would it be possible to install the netpipes version of timelimit binary as timelimit-4.2 instead ? or maybe another name so these can coexist ? *** As well, timelimit-1.7 would be a great candidate for import into world since it is your e-std 2 clause BSD license and a 3 file compile. ;) And if noone else wants to maintain it in tree then ill volunteer. *** Regards, - -- jhell,v -BEGIN PGP SIGNATURE- iQEcBAEBAgAGBQJM323hAAoJEJBXh4mJ2FR+nyAH/AiCStRku/gxLP9urxN1txov JaR7KgaMEiVuuUk5pt/9lOr5sY1tdRmX16CgPzwKfr5pZpC/BBkYpsYHH/QLJ1MC dgUubQoEowe50QmgFFhDDnAnnZ1FEnEWnknPZErKcNAF/td59xeMAzxN7lFZ40dC k1GTozKo7gx6pgYeFcpxCu14ve4LXsEkKfy3lhjMVunbgyjVSMT3NuwKlrYyEIGq +KUknTcaP5VEEg6tM//HS904WGPAtd6sbc62q6TowzYx2DEFx4I8Uf+NRoAjwJaZ KM0HYtwjjE7IRWk2d7CjN9O60tCVbZbzpr5Y9MFzaip4Wk6gLFJw94XpENOobFE= =aywI -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FreeBSD Port: snort-2.8.6.1
On 10/27/2010 17:59, ignace peeters wrote: > Hello, > > I'm trying to build and install snort,running into the following > recuring error: > > /bin/sh /usr/local/bin/libtool --tag=CC--mode=link cc -O2 -pipe > -fno-strict-aliasing -fvisibility=hidden -fno-strict-aliasing -Wall > -module -lssl -lcrypto -L/usr/local/lib -L/usr/local/lib > -Wl,-R/usr/local/lib -lpcre -L -L/usr/local/lib -L/usr/local/lib -ldnet The error seems to happen in here '-L' as stated by the error below leads me to believe that something in your make.conf, make.conf.local and possibly ports-mgmt/portconf and whatever config files it might use if you use that might be causing it. Can you double check those files and verify that there is no lines that would affect the flags passed to the linker or configure to cause that to appear ? > -o libsf_smtp_preproc.la -rpath /usr/local/lib/snort/dynamicpreprocessor > smtp_config.lo smtp_log.lo smtp_normalize.lo smtp_util.lo > smtp_xlink2state.lo snort_smtp.lo spp_smtp.lo ssl.lo > sf_dynamic_preproc_lib.lo sfPolicyUserData.lo -ldnet -lpq -lc -lpcre > -lpcap -lm -lm -lpq > libtool: link: require no space between `-L' and `-L/usr/local/lib' > > The error occurs in multiple Makefiles. Can this be corrected in the > ports collection. > -- jhell,v ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
[BUG] cd /usr/src/bin/sh && portmaster -ai
The above subject listed bug has been found in portmaster with cause unknown. portmaster(8) at this point fails to continue because it is waiting on a pipe for whatever reason. This also happens in '/usr/src/bin/csh' and I am not sure if there is other directories this happens in. ~25 lines of output from a run with '-x' + getopts BCDFGHKLPRabde:fghilm:nop:r:stuvwx: COMMAND_LINE_ARGUMENT + shift 1 + unset -f packages_init cross_idx + [ -n '' ] + [ -n '' ] + [ -n '' -a iopt ] + [ -n '' -a -n '' ] + [ -n '' -a -n Dopt ] + [ -n '' -a -n '' ] + [ -n '' -o -n '' ] + unset my_environment + unset -f test_command_line + [ -n '' -o -n '' ] + [ -n '' ] + [ -n '' ] + [ -z '' -a '' != only -a -z Dopt ] + [ 1 -eq 1 -a -z '' ] + CUR_DEPS=: + DISPLAY_LIST='' + INSTALLED_LIST='' + PM_DEPTH='' + pm_mktemp IPC_SAVE + /usr/bin/mktemp -t f-1-IPC_SAVE + IPC_SAVE=/tmp/f-1-IPC_SAVE.aKMgzSJW + export CUR_DEPS DISPLAY_LIST INSTALLED_LIST PM_DEPTH IPC_SAVE + [ -n '' ] + pm_make_b -f/usr/share/mk/bsd.port.mk -V LOCALBASE + PLB='' + [ -n '' ] + head -1 + cut -f 3 '-d|' This is the point where is stops. Found on FreeBSD 8.1-STABLE i386 If further information is needed let me know. Regards, -- jhell,v ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
ports/sysutils/fusefs-kmod setup.sh
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello amistry@, Ports, This is an informal request to have the subject listed port setup.sh script stop blindly loading the fuse.ko module upon install and upgrade procedures and to stop adding fusefs_enable="YES" to rc.conf without confirmation. While I find that it would be useful to enable this port on a system that it is being installed on I also find it to be frustrating to have to explicitly disable it as well. I believe it would be more of a convenience to a user on either side of this argument if the mount_fusefs command would load the appropriate module that was needed, in this case being fuse & also have the upgrade or install procedure inform the user of the possibility of adding the fusefs_enable="YES" to rc.conf* to enable it. Currently I do not see any other common ports that I use that exhibit this behavior of enabling services and or modules to load automatically and would like to see this port follow that same outline. If you would like help to achieve this then please let me know and I will do what I can to help. Questions, comments & replies forward them to me. Aggravations forward to bit-buc...@localhost. Regards, - -- jhell,v -BEGIN PGP SIGNATURE- iQEcBAEBAgAGBQJMuRoIAAoJEJBXh4mJ2FR+JMUH/iIiKP0MrE9YTaKJNdkNpQOj 2teZgDrjWzWb4Ywzivff+BwrrT9gloBBjFfsDbhweaPHWZBCsjzbSiVfm99bLGG+ lRU43JMcXBQuAbSCF4DxDWp0UR2QhOtG1JJ8KmG5BZHJFApeqXmlgeGT/RUxkRCQ TBmx+bBa84jPQOm1zyAJNhQ8oK98jZ3IFunu2hyn1hynC3nQIRSnq1yF6G1EGMKQ XS5HgTmuTXorhRurHSZSZzpJH8zZTeoFDWXJSHdqYDIe/HzYxguzMjpCf3YACFP2 fyxxG1R5u7/WTf78UMGYeM/sjM1MiG7rKCMXp1nelvxu/9o+vmZRWbZmnJHqFT8= =xDV4 -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: OPTIONS
On 10/06/2010 13:55, David O'Brien wrote:
> On Wed, Oct 06, 2010 at 12:01:48PM +0300, Andrew W. Nosenko wrote:
>> On Wed, Oct 6, 2010 at 11:40, David O'Brien wrote:
>>> On Tue, Oct 05, 2010 at 11:34:52AM -0700, David O'Brien (@FreeBSD) wrote:
>>>>> 2010/10/3 Matthew Seaman :
>>>>>> In fact, you might just as well write a small HTML form, display it
>>>>>> using lynx or w3c or some other text mode browser[*], and then have the
>>>>>> form action feed into a CGI program that outputs a small Makefile with
>>>>>> appropriate variable definitions in it.
>>>>
>>>> I like this statement -- as it shows just how complex this will get when
>>>> taken to its natural conclusion.
>>>
>>> This is also how ridiculous things can get:
>>>
>>> curl 7.21.1 now offers me:
>>> � �[X] WERROR � � � Treat compilation warnings as errors
>>>
>>> � �Can the port maintainer really not decide if that should just be
>>> � �turned off or turned on for FreeBSD?!?
>>
>> I wonder why -Werror even ever considered to be turned "on" at all.
>
> \AOL{me too}
>
> I mean building with "-Werror" sounds like goodness -- of course I
> want it.
>
> But why is the maintainer offering me a choice?
> What is the likelihood of the port not building with -Werror?
> Does he know of versions of FreeBSD where the port will not build
> with -Werror? Hum.. maybe I don't want -Werror. But then why didn't
> the the maintainer just decide we would all not build with -Werror?
>
> Given we are just building and installing Curl, what do we expect
> users to do choose WERROR and get a build break with -Werror?
> They aren't developing the next version of Curl. Can they submit a
> FreeBSD PR and expect the maintainer will quickly add a patch to the
> port to fix the warning(s)? Or will the response be
> "Well, don't do that."? In which case just turning off -Werror for
> all seems a better thing to do.
>
IMHO If I may, The OPTIONS framework is a UI(User Interface) to useful
options that a 'User' would be interested in turning on. This would be
things that a user, not a 'developer' could use or would find helpful.
With the above said, if it was the developers intent to add options in
order to make debugging the port easier for them, then I feel that is
the wrong approach as these are options that are more appropriately
handled by CFLAGS CXXFLAGS LDFLAGS and such since they are developer
centric and mean very little to the majority of the community.
Now with both of the above stated, it may be useful if specific
developer options were wrapped in a statement that would check to see if
a MAINTAINER_MODE has been defined allowing those options to be
dynamically added to the list of existing option.
Personally I feel that because of the loose guidelines that we already
have in the Porters Handbook that when frameworks like this present
problems as the options framework has already shown, that a better
defined standard should be developed & agreed upon so that every
developer and user knows exactly what to expect out of every port and
what is expected to be presented to the user. A ports tree of this size
and not having a clear and set-forth standard as to what can be expected
is fairly hazardous IMO. If I had missed an area 'one area' where this
is already defined then please excuse me and reference me a clear link.
Regards,
--
jhell,v
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
ftp/ncftp3 stale patch no recorded checksums
After the recent update of ftp/ncftp3 there seems to be a stale v6 patch
file left hanging around that no longer applies to the 3.2.4 source code
for ncftp3.
The following patch comments out the section in question but it also
seems as there is "no native support for v6 in ncftp3 ?" at this time.
Does anyone know of a v6 patch for the new (3.2.4) source ?
Regards,
--
jhell,v
--- Makefile.orig 2010-10-05 23:26:16.738633363 -0400
+++ Makefile2010-10-05 23:25:14.727629085 -0400
@@ -14,11 +14,11 @@
ftp://ftp.mirrorservice.org/sites/ftp.ncftp.com/ncftp/
DISTNAME= ncftp-${PORTVERSION}-src
-.if !defined(WITHOUT_NCFTP_IPV6) && !defined(WITHOUT_IPV6)
-PATCH_SITES= ftp://ftp.kame.net/pub/kame/misc/
-PATCHFILES=ncftp-323-v6-20091109.diff.gz
-PATCH_DIST_STRIP= -p1
-.endif
+#.if !defined(WITHOUT_NCFTP_IPV6) && !defined(WITHOUT_IPV6)
+#PATCH_SITES= ftp://ftp.kame.net/pub/kame/misc/
+#PATCHFILES= ncftp-323-v6-20091109.diff.gz
+#PATCH_DIST_STRIP= -p1
+#.endif
MAINTAINER=obr...@freebsd.org
COMMENT= ftp replacement with advanced user interface
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
devel/p4d/Makefile
Hi Gordon,
I have just upgraded my p4d install and have found the following
inconsistency in the Makefile:
${CAT} pkg-message
pkg-message at this point cannot be found and it would be better if this
referred to the ports directory and the portname /pkg-message instead.
I might also suggest that instead of using touch(1) chown(1) chmod(1) to
create entries in the filesystem for the p4d.log that you use install(1)
instead as that allows you to achieve all three steps listed above in
one command like so.
install -S -o p4admin -g p4admin -m 640 /dev/null /var/log/p4d.log
And of course this might need/involve some checking to see if the users
log file already exists as we would not want to overwrite that by the
above command but nor do we want to blindly chmod(1) the file either
which is also done in the Makefile already.
Regards,
--
jhell,v
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: editors/vim installs to /
On 10/02/2010 02:49, Ade Lovett wrote: > editors/vim -- fully functional console-only (no X11) > editors/vim-lite -- stripped down version (again, no X11, perhaps even > linked static for use within embedded systems) > editors/vim-gui -- take your pick. X11 is implied. athena/motif widgets > are pretty much dead, so unless there's a QT version floating around, GTK2. editors/vim editors/vim-lite editors/gvim editors/gvim-lite ? Makes sense does it not ? -- jhell,v ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS-UP] graphics/claraocr out of date.
On 09/25/2010 20:17, Ruslan Mahmatkhanov wrote: > 25.09.2010 22:49, jhell пишет: >> >> Going through some of my old OCR uses, I could the subject listed port >> out of date and the URL referenced in the pkg-descr is non functional. >> >> The new website for this port is: >> http://www.claraocr.org/en/download.html >> >> And seems to be last updated as of: 11/18/09 which is the v1.1 release. > > Did you ever tried to click download link? > It give you clara-20031214.tar.gz, that is in ports now. > So it's up-to-date with www.claraocr.org. > Aaaah, thanks I never actually checked out the file in question. Aweful mislead distribution. Thanks -- jhell,v ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADS-UP] graphics/claraocr out of date.
On 09/25/2010 19:01, Wesley Shields wrote: > On Sat, Sep 25, 2010 at 02:49:02PM -0400, jhell wrote: >> >> Going through some of my old OCR uses, I could the subject listed port >> out of date and the URL referenced in the pkg-descr is non functional. >> >> The new website for this port is: >> http://www.claraocr.org/en/download.html >> >> And seems to be last updated as of: 11/18/09 which is the v1.1 release. > > [HEADS-UP] like subject lines are usually reserved for when something > major is going to happen (like an update of gnome or kde). > > -- WXS So sue me. -- jhell,v ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
[HEADS-UP] graphics/claraocr out of date.
Going through some of my old OCR uses, I could the subject listed port out of date and the URL referenced in the pkg-descr is non functional. The new website for this port is: http://www.claraocr.org/en/download.html And seems to be last updated as of: 11/18/09 which is the v1.1 release. -- jhell,v ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FreeBSD Port: dovecot-1.2.14
On 09/25/2010 07:37, Garrett Heaver wrote: > Hi > > I was just wondering if there is a port for dovecot 2 in the works already or > if I could be any assistance in getting it up and running? > > Many Thanks! > Garrett Heaver___ I think someone had already asked this at one point so it might be a good thing checking the list archives. But if I am correct the final conclusion was to wait for the dust to settle in the dovecot-2 area. Regards, -- jhell,v ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Web feeds for UPDATING files
On 09/25/2010 09:24, Alexander Kojevnikov wrote: > On 25 September 2010 17:04, Alexander Kojevnikov > wrote: >> On 25 September 2010 15:44, jhell wrote: >>> Really awesome! >>> >>> This will come in handy to serve up stable/*/UPDATING and head/UPDATING >>> to. And thinking along those lines it could probably be incorporated >>> directly into the DAV tree on svn. to serve directly from there. >> >> Great idea, I'll try to implement both feeds during the weekend and >> will post here and on freebsd-current@ and freebsd-stable@ when it's >> done. > > ...and done: > > http://updating.versia.com/ > > The site now features Atom feeds for the following files: > > * ports/UPDATING > * head/UPDATING > * stable/7/UPDATING > * stable/8/UPDATING > > Hope you find the feeds useful. > > Cheers, > Alex > > PS: I apologise to ports/UPDATING subscribers who got quite a few > duplicate entries. I barely missed the Ballmer Peak, just delete > those. Your amazing! Thanks Alexander! -- jhell,v ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Can't compile x11/hs-X11-xft
On 09/25/2010 13:54, David DEMELIER wrote: > Hi, > > Today I can't compile xmonad-contrib anymore (hs-X11-xft is failing) > > ===> Installing for hs-xmonad-0.9.1_1 > ===> hs-xmonad-0.9.1_1 depends on executable: ghc - found > ===> hs-xmonad-0.9.1_1 depends on package: hs-X11>=1.5.0.0 - found > ===> hs-xmonad-0.9.1_1 depends on file: > /usr/local/libdata/pkgconfig/x11.pc - found > ===> Generating temporary packing list > ===> Checking if x11-wm/hs-xmonad already installed > Installing library in /usr/local/lib/xmonad-0.9.1/ghc-6.10.4 > Installing executable(s) in /usr/local/bin > Registering xmonad-0.9.1... > Reading package info from "dist/installed-pkg-config" ... done. > Writing new package config file... done. > ===> Compressing manual pages for hs-xmonad-0.9.1_1 > ===> Registering installation for hs-xmonad-0.9.1_1 > ===> Returning to build of hs-xmonad-contrib-0.9.1_1 > ===> hs-xmonad-contrib-0.9.1_1 depends on package: hs-utf8-string>=0 - found > ===> hs-xmonad-contrib-0.9.1_1 depends on package: hs-X11-xft>=0.2 - not > found > ===>Verifying install for hs-X11-xft>=0.2 in /usr/ports/x11/hs-X11-xft > ===> Vulnerability check disabled, database not found > ===> License check disabled, port has not defined LICENSE > ===> Extracting for hs-X11-xft-0.3_4 > => MD5 Checksum OK for cabal/X11-xft-0.3.tar.gz. > => SHA256 Checksum OK for cabal/X11-xft-0.3.tar.gz. > ===> Patching for hs-X11-xft-0.3_4 > ===> hs-X11-xft-0.3_4 depends on executable: ghc - found > ===> hs-X11-xft-0.3_4 depends on package: hs-utf8-string>=0.1 - found > ===> hs-X11-xft-0.3_4 depends on package: hs-X11>=1.2.1 - found > ===> hs-X11-xft-0.3_4 depends on executable: haddock - found > ===> hs-X11-xft-0.3_4 depends on executable: HsColour - found > ===> hs-X11-xft-0.3_4 depends on file: > /usr/local/libdata/pkgconfig/xft.pc - found > ===> hs-X11-xft-0.3_4 depends on file: > /usr/local/libdata/pkgconfig/xrender.pc - found > ===> Configuring for hs-X11-xft-0.3_4 > [1 of 1] Compiling Main ( Setup.lhs, Setup.o ) > Linking setup ... > Configuring X11-xft-0.3... > setup: At least the following dependencies are missing: > utf8-string >=0.1 > *** Error code 1 > > Stop in /usr/ports/x11/hs-X11-xft. > *** Error code 1 > > Stop in /usr/ports/x11-wm/hs-xmonad-contrib. > *** Error code 1 > > Stop in /usr/ports/x11-wm/hs-xmonad-contrib. > > mark...@melon ...x11-wm/hs-xmonad-contrib $ pkg_info hs-utf8-string-0.3.6 > Information for hs-utf8-string-0.3.6: > [...] > > I don't know what is happening right now. > These are part of the rest of the hs-* ports. They usually have to be compiled in order to compile correctly against their brothers and sisters. What usually solves this for me is ( portmaster hs-\* ). Good luck, -- jhell,v ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Web feed for /usr/ports/UPDATING
On 09/24/2010 20:20, Alexander Kojevnikov wrote: > On 25 September 2010 04:49, Jason wrote: >> I subscribed, as well. It would be great to get this code working inside the >> Documentation Project, itself, and serve the feed from: >> >> http://www.freebsd.org/ports/updating.html > > The code is available under FreeBSD license [0], feel free to use it > on the official website. Alternatively, they can link to my feed > directly, I'm going to keep it updated and if necessary will upgrade > the RootBSD VPS it's hosted on. > > [0] http://github.com/alexkay/freebsd-updating Really awesome! This will come in handy to serve up stable/*/UPDATING and head/UPDATING to. And thinking along those lines it could probably be incorporated directly into the DAV tree on svn. to serve directly from there. -- jhell,v ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Distributed Version Control for ports(7) ( was: Re: autoconf update )
On 09/20/2010 22:07, per...@pluto.rain.com wrote: > Janne Snabb wrote: > >> On Mon, 20 Sep 2010, per...@pluto.rain.com wrote: >>> One issue with either Git or Mercurial is that they are GPL. >>> AFAIK FreeBSD prefers to avoid GPL in the base or in critical >>> widely-used infrastructure if a viable non-GPL alternative >>> exists. >> >> The project currently uses Perforce for many sub-projects, >> so using GPL licenced solution could hardly be a problem. > > According to the "General Information" table here: > http://en.wikipedia.org/wiki/Comparison_of_revision_control_software > Perforce is not GPL -- it is proprietary (but "Free ... for OSS > development"). Thus the fact that FreeBSD currently uses Perforce > tells us nothing about the acceptability of a GPL licensed solution. > (Ditto for SVN, which -- as someone already pointed out -- is not > GPL either.) > > There are two distributed, BSD-licensed VCS listed on that page: > Codeville and Fossil. Both are in ports, but Codeville has been > proposed for removal as it seems no longer to be under active > development. That leaves Fossil as a possibly-viable BSD-licensed > alternative to Mercurial. (Of course, there may be others that > aren't listed on that particular Wikipedia page.) Feel free to correct me if I am wrong but it is not going to matter much to what extent a license has to do with this besides ease of mind maybe. We would not be using the source for the VCS in a repo that holds the source that is being distributed and none of the contained software would be effected by a GPL'd VCS. I don't believe the GPL reaches out that far as to where it can effect the contents of a repo even if it would happen to be GPLv3. Lets not bring licensing into this unless the license clearly states that the beholder needs to be rewarded for their work by any use of so said product. -- jhell,v ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Distributed Version Control for ports(7) ( was: Re: autoconf update )
On Mon, 20 Sep 2010 03:17, Konstantin Tokarev wrote: In Message-Id: <174981284967...@web24.yandex.ru> 1). http://bit.ly/d5UrtN 2). http://www.keltia.net/BSDCan/paper.pdf 3). http://bit.ly/97Y8Xi 4). Because CVS just does not do any of this. Make your final comparison here: http://bit.ly/cyQBn8 For the sake of argument can you think of any reason to not switch ? Why not Git? Or you prefer to manage ports tree from Windows? For one it really has a steeper learning curve for the interface than what mercurial presents. It presents a lot of information upfront to the user which tends to be overwhelming in some cases. GIT is nice, I like its speed but I have more of a preference to mercurial than anything else. I also like the fact that mercurial makes direct use of the python language but this is not really for this thread and could lead off in directions that were not intended. I do not do any development for anything to do with FreeBSD in a Window$ environment, Its not needed for me to do so because I always have access to a command line wherever I go. If the time comes and I would need to, it is nice to know that there is a front-end for Mercurial on Window$. Thanks for inquiring, -- jhell,v ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Distributed Version Control for ports(7) ( was: Re: autoconf update )
On 09/18/2010 07:17, Ion-Mihai Tetcu wrote: > > I'm still to see a concise, clear, precise, listing of advantages that > switching from CVS would bring us, that would overcome the effort > needed to do it (committers, users, infrastructure, tools). > 1). http://bit.ly/d5UrtN 2). http://www.keltia.net/BSDCan/paper.pdf 3). http://bit.ly/97Y8Xi 4). Because CVS just does not do any of this. Make your final comparison here: http://bit.ly/cyQBn8 For the sake of argument can you think of any reason to not switch ? lets hear those, I'm interested. -- jhell,v ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: editors/vim installs to /
On 09/17/2010 19:52, Anonymous wrote:
> jhell writes:
>
>> After a force upgrade of vim that had failed unfortunately not
>> registering the files it installed already I found out that it is
>> installing to / ~! ugh.
>
> Does the following diff fixes it?
>
> %%
> Index: editors/vim/Makefile
> ===
> RCS file: /a/.cvsup/ports/editors/vim/Makefile,v
> retrieving revision 1.357
> diff -u -p -r1.357 Makefile
> --- editors/vim/Makefile 17 Sep 2010 00:46:45 - 1.357
> +++ editors/vim/Makefile 17 Sep 2010 23:47:49 -
> @@ -166,7 +166,7 @@ MAKE_ARGS+= CONF_OPT_GUI="--enable-gui=n
> MAKE_ARGS+= CONF_OPT_PERL="--disable-perlinterp --disable-pythoninterp
> --disable-tclinterp --disable-rubyinterp"
> .endif # LITE
>
> -.if exists(${PREFIX}/lib/libiconv.so)
> +.if exists(${LOCALBASE}/lib/libiconv.so)
> USE_ICONV= yes
> .endif
>
> @@ -211,7 +211,7 @@ pre-configure:
> .endif
>
> post-configure:
> - @(cd ${WRKSRC} ; ${MAKE} scratch config)
> + @(cd ${WRKSRC} ; ${SETENV} ${MAKE_ENV} ${MAKE} ${MAKE_ARGS} scratch
> config)
>
> #Clean up junk files to keep them from being installed.
> pre-install:
> %%
Since this really is not specific to one installation on a single system
and that I have already compiled and re-installed this port I will not
be testing this patch. Thank you for providing more information to the
maintainer.
Regards,
--
jhell,v
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: editors/vim installs to /
On 09/17/2010 19:22, Wesley Shields wrote:
> On Fri, Sep 17, 2010 at 07:18:09PM -0400, jhell wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 09/17/2010 17:19, Wesley Shields wrote:
>>> On Fri, Sep 17, 2010 at 01:49:37PM -0400, jhell wrote:
>>>>
>>>> After a force upgrade of vim that had failed unfortunately not
>>>> registering the files it installed already I found out that it is
>>>> installing to / ~! ugh.
>>>>
>>>> Why is ${PREFIX} being used and not ${LOCALBASE} ???
>>>
>>> I reverted to the previous Makefile just to get something working before
>>> I leave. I did want to point out that the cleanup (at least for me) was
>>> not that hard. /man and /share were left behind along with a handful of
>>> files in /bin that shouldn't have been there. Once I had reverted and
>>> installed vim I was able to use something like
>>>
>>> pkg_info -L -x vim | fgrep /usr/local/bin | sed -e 's|/usr/local||'
>>>
>>> To find the files which were in /bin that should not have been there.
>>> Not all of them were there in my case but the cleanup was easy. Just
>>> delete /man and /share and the handful of files in /bin.
>>>
>>> I still don't know what the real fix for this is but hopefully someone
>>> is working on it. ;)
>>>
>>> -- WXS
>>
>> Attached is the exact patch that fixes this. The two effected areas are
>> post & pre-configure. My best guess on this lays on the REINPLACE_CMD in
>> pre-configure but I could be wrong.
>
> You may want to also revert the MAKE_JOBS_SAFE too.
>
> -- WXS
Yeah I am leaving that up to the committee to decide. With that setting
here, it builds and installs fine so I am not concerned with it as I
have no control over the end result.
--
jhell,v
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: editors/vim installs to /
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/17/2010 17:19, Wesley Shields wrote:
> On Fri, Sep 17, 2010 at 01:49:37PM -0400, jhell wrote:
>>
>> After a force upgrade of vim that had failed unfortunately not
>> registering the files it installed already I found out that it is
>> installing to / ~! ugh.
>>
>> Why is ${PREFIX} being used and not ${LOCALBASE} ???
>
> I reverted to the previous Makefile just to get something working before
> I leave. I did want to point out that the cleanup (at least for me) was
> not that hard. /man and /share were left behind along with a handful of
> files in /bin that shouldn't have been there. Once I had reverted and
> installed vim I was able to use something like
>
> pkg_info -L -x vim | fgrep /usr/local/bin | sed -e 's|/usr/local||'
>
> To find the files which were in /bin that should not have been there.
> Not all of them were there in my case but the cleanup was easy. Just
> delete /man and /share and the handful of files in /bin.
>
> I still don't know what the real fix for this is but hopefully someone
> is working on it. ;)
>
> -- WXS
Attached is the exact patch that fixes this. The two effected areas are
post & pre-configure. My best guess on this lays on the REINPLACE_CMD in
pre-configure but I could be wrong.
- --
jhell,v
-BEGIN PGP SIGNATURE-
iQEcBAEBAgAGBQJMk/cwAAoJEJBXh4mJ2FR+xukH/2JgWGagRpnvUUjbJfCXetDe
/ahIbbohU+pDmeJ3F6UwcoxPgSd2mW0vRiC+3fFLKi/otAgYqfS+L5X5hMmIoBd1
fgqTeXqy2hF+1IcPdBAIrigxGqv6CA4BmUHYhdMLHV+TVFfboeU70fuBeEYnfsR6
VNYWe8B/0Qb9VNkV+FDFSlvp0Qu4ONkwxPevp/hgTu2914Kd+kmjnLRBTBLekQJ+
KLwXoc1jqoLBwvhT+DRRDFSskNiXjJuAGyt0k10sQpYZCaPwXSXT4mYhjhqDyCnk
uSjxiQe3MK7W1G1QK9RjLOjyMiXbJ8Rv7j6h/pgAoxsegN8xOFryfonRQKp3G44=
=4CXp
-END PGP SIGNATURE-
--- Makefile.1.357 2010-09-17 18:49:24.188934083 -0400
+++ Makefile 2010-09-17 19:13:22.041265307 -0400
@@ -195,9 +195,6 @@
${REINPLACE_CMD} -e 's,ctags -R \.,${CTAGS_CMD},g')
pre-configure:
- # Fix dependency misspelling so that 'make -j#' will work.
- @${REINPLACE_CMD} -e 's|\./auto/osdef\.h|auto/osdef.h|g' \
- ${WRKSRC}/Makefile
@(cd ${WRKSRC} ; ${MAKE} distclean)
@${REINPLACE_CMD} -e ' \
s|\$$gtk_config_prefix/bin/gtk-config|\$${GTK_CONFIG}|g; \
@@ -210,9 +207,6 @@
${WRKSRC}/feature.h
.endif
-post-configure:
- @(cd ${WRKSRC} ; ${MAKE} scratch config)
-
# Clean up junk files to keep them from being installed.
pre-install:
@${FIND} ${WRKSRC:H} -type f -name '*.orig' -delete
Makefile.diff.sig
Description: Binary data
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
editors/vim installs to /
After a force upgrade of vim that had failed unfortunately not
registering the files it installed already I found out that it is
installing to / ~! ugh.
Why is ${PREFIX} being used and not ${LOCALBASE} ???
--
jhell,v
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: autoconf update
On 09/17/2010 00:41, Doug Barton wrote: > On 9/16/2010 6:15 PM, Doug Barton wrote: >> On 9/16/2010 3:35 PM, Anonymous wrote: >>> Dominic Fandrey writes: >>> >>>> On 16/09/2010 19:17, Dmitry Marakasov wrote: >>>>> * Dominic Fandrey (kamik...@bsdforen.de) wrote: >>>>> >>>>>> Just out of curiosity, why a version bump because of a build >>>>>> dependency? >>>>>> >>>>>> I don't think an autoconf update should have an effect on any >>>>>> /running/ software but build systems. And I don't see how rebuilding >>>>>> all the software improves it. >>>>>> >>>>>> This is not a criticism - I just think there is something I don't >>>>>> understand and that worries me. >>> >>> My guess is to uncover *early* build failures that exp-run didn't catch. >> >> We shouldn't use our users to beta-test infrastructure changes. > > Sorry, I'm not feeling well atm and realize that I didn't write what I > was thinking here. What I intended to say was that we _don't_ > intentionally use the ports system to force our users to beta test > changes. I think it goes without saying that we _shouldn't_ do this, > although I think that changes like this are a platinum-coated example of > why we need to have -stable and -dev branches for ports. > > > Doug > I agree with this to an extent. Having two branches while being a nice idea is not really needed with some of the version control software that is out there. Mercurial being the distributed version control that it is allows you to clone, make the changes you need to the clone test it thoroughly and then either push or pull them to the main tree. This would allow the same work that is being done on ports right now continue to happen with less effort and greater amount of cooperation between users and developers alike. The ports tree is a prime example of why we need a distributed version control. Personally I would love to be able to say HEY! I just made these changes to this port because it was not acting right and you can pull my patch for it here: http://host/repo/. Once tested by whomever Joe Blow Committee they can choose to modify it further test and or push it to the main tree where others can update from. Main Tree "Users pull and clone from here" | `- Dev Clone"Devs pull and clone from here and push to main" Ports is a distributed project being used in an old non distributed version control system. If this is going to get anywhere something needs to change and it needs to start from the ground up. Lets do it! no excuses, it does not take very long to convert to mercurial including keeping history intact and there is front-ends for this all over the place. -- jhell,v ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [ports/net/isc-dhcp*] Don't stop DHCP related daemons
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/12/2010 15:10, Matthew Seaman wrote: > On 12/09/2010 15:46:18, jhell wrote: >> On 09/12/2010 09:02, Matthew Seaman wrote: >>> On 12/09/2010 07:46:02, Ion-Mihai Tetcu wrote: >>>> And you can't really know if it's a new install or an upgrade. >> >>> An app like portmaster or portupgrade would be able to know that. It's >>> an oddity of the ports/pkg system that because 'upgrade' is implemented >>> as 'delete' followed by 'install' that there is difficulty in making >>> that distinction. >> >>> In fact, portupgrade has a nifty feature you can enable which causes it >>> to run '/usr/local/etc/rc.d/foo start' for any rc scripts installed by a >>> port it is working on. Which is almost, but not quite, exactly what is >>> wanted; it should issue 'restart' for services already running, or >>> 'start' for services stopped during the upgrade process. >> >> >> >> If someone really wants to go for automation lets not leave it on the >> backs of every user that is involved with ports that offer network >> services but learn how to properly script out periodic(8) runs or a >> cron(8) job to check for the existence of that process. >> >> Line wrapage: >> */5 * * * * /usr/local/etc/rc.d/rcscript status \ >> ||/usr/local/etc/rc.d/rcscript start >> >> Or write your own periodic script that makes use of _enable etc... and >> put it in /usr/local/etc/periodic somewhere. > > Heh. BTDT. Well, almost: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/118325 > > That just reports on any services that should be running and aren't. It > would be trivial to make it attempt to restart anything that needed > it. > >> People may also be interested in this, that I use for personal cron jobs >> that I need to schedule minutely hourly daily and such. >> http://bit.ly/9ODE56 >> >> Perfectly fine that tools like portmaster or portupgrade offer these >> things but lets not forget that its also really easy to figure out what >> services are going to be stopped before you start a upgrade and then >> restart them after using service(8) for example. >> >> Maybe it would not be such a bad idea to start a framework for a set of >> periodic checks that the user can configure simple by >> >> # 5 Minute Service checks >> minutely_check_enable="YES" # Allow disabling all 5 minute checks. >> minutely_check_rcscript_enable="YES" # Enable check for this rcscript. >> >> # Hourly checks # >> hourly_check_enable="YES"# See above >> hourly_check_rcscript2_enable="YES" # >> ... >> >> The rc.subr system should be able to handle this or service(8) by >> calling status and taking appropriate action for each script within an >> hourly_check_*_enable variable. > > Hmmm... checking every 5 minutes and automatically restarting anything > not running sounds like a sorcerer's apprentice scenario... Right but I'm just thinking of the "X wants Z" scenario but A comes along and says Y is not even in the picture?... Provide this as a common ground since the rest would already be done. But I'm not saying it should even report anything at all unless something has to be restarted. and heck that could be a option too ;) > > You shouldn't need to check service status that frequently -- a report > once a day will do, unless you've just been fiddling with the system, > when you could just run the daily check by hand and deal with anything > that needs it. If you've got a service where downtime cannot be > tolerated, that's why things like nagios and daemontools exist -- but > that's overkill much of the time. > I agree with that but like you said overkill in most cases and even this would be overkill in its own way. Providing something like this gives the user a generic middle-ground where they can make the decision if they would like something a little more sophisticated or nothing at all. Not really set in stone but those checks could also obey a *_threshold much like what 800.zfs-scrub does but for a time-frame instead with unsaid defaults for the moment. Anyhoo... Regards, - -- jhell,v -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMjTF5AAoJEJBXh4mJ2FR+NNEH/iEChgxhNXukrLHnlHxDUV69 zT16HArIsUR9S/0Wvc98Ok9DUBHMf6DeKREP/vbfFqnhWJ7SINCKzw9dod9wo+8W JudfrX7ultqv22Rimh2i8+EYUMHToqXP/gxDMINDHlJTsaqkO2J7oYPZu4w9svxy Q/PtoeGIWYAcg7IIHYSOZIv85eVoRkSTcuValQ81XBsksi5zP9eUMnBDtgkc25lB hbtpXfY3aftJPfPloatuIJL7V1yJAKpiMghkuNmrbUVgn6nywkLigrf7tSzJVDow WRKdirwrkuljb5mRsNz62TYXsbf6N2Dxxyh1iH6SN4hAnOPnNqeB8juyLH6zQYE= =kxmd -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [ports/net/isc-dhcp*] Don't stop DHCP related daemons
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/12/2010 09:02, Matthew Seaman wrote: > On 12/09/2010 07:46:02, Ion-Mihai Tetcu wrote: >> And you can't really know if it's a new install or an upgrade. > > An app like portmaster or portupgrade would be able to know that. It's > an oddity of the ports/pkg system that because 'upgrade' is implemented > as 'delete' followed by 'install' that there is difficulty in making > that distinction. > > In fact, portupgrade has a nifty feature you can enable which causes it > to run '/usr/local/etc/rc.d/foo start' for any rc scripts installed by a > port it is working on. Which is almost, but not quite, exactly what is > wanted; it should issue 'restart' for services already running, or > 'start' for services stopped during the upgrade process. > If someone really wants to go for automation lets not leave it on the backs of every user that is involved with ports that offer network services but learn how to properly script out periodic(8) runs or a cron(8) job to check for the existence of that process. Line wrapage: */5 * * * * /usr/local/etc/rc.d/rcscript status \ ||/usr/local/etc/rc.d/rcscript start Or write your own periodic script that makes use of _enable etc... and put it in /usr/local/etc/periodic somewhere. People may also be interested in this, that I use for personal cron jobs that I need to schedule minutely hourly daily and such. http://bit.ly/9ODE56 Perfectly fine that tools like portmaster or portupgrade offer these things but lets not forget that its also really easy to figure out what services are going to be stopped before you start a upgrade and then restart them after using service(8) for example. Maybe it would not be such a bad idea to start a framework for a set of periodic checks that the user can configure simple by # 5 Minute Service checks minutely_check_enable="YES" # Allow disabling all 5 minute checks. minutely_check_rcscript_enable="YES" # Enable check for this rcscript. # Hourly checks # hourly_check_enable="YES" # See above hourly_check_rcscript2_enable="YES" # ... The rc.subr system should be able to handle this or service(8) by calling status and taking appropriate action for each script within an hourly_check_*_enable variable. Just some thoughts to be expanded, Regards, - -- jhell,v -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMjOe6AAoJEJBXh4mJ2FR+20cH/ReHJDra84J19WX0UJxvcA2v Z4QK/y/Tn5J3bjQ8EVOmkZIokX3EDunHrlufdIq/iaWWVKC4xhJ6DNFqJJ8zw5Mm 5zL59xO/m+uw3Fuxxc67semTvFbLhmCG/IiDTyePjfhU9rj/eV0EdAtO9auBGXgJ GNfn1QQrejoYPt/bStwBnbmPM2JHmiU1Qbu+A7MpGZRVH1flUBbIk0EQBluErEsK vvWa6LYqZsZPT3IKZvMEmIi6WQQLrEnIHgsjUNqnbw8FijPsi0fATdUxwVGUaR4T hmIfkHtLz/v0zg5nHFNcMniz+Og3nWAWP68ews0gWyYm/5gftfWobaFTRLnm4FA= =CvPi -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: devel/apr1 and python use.
On 09/11/2010 09:19, Philip M. Gollucci wrote: > On 9/11/2010 6:04 AM, jhell wrote: >> Hi Apache Team& Ports, >> >> Would I be able to persuade you guys to bump or change if you will >> USE_PYTHON_BUILD from -2.6 to -2.7 or switch to using USE_PYTHON= >> instead ? >> >> Comment from bsd.python.mk: >> >> This file contains some variable definitions that are supposed to make >> your life easier when dealing with ports related to the Python language. >> It's automatically included when USE_PYTHON or PYTHON_VERSION is defined >> in the ports' makefile. Define PYTHON_VERSION to override the defaults >> that USE_PYTHON would give you. If your port requires only some set of >> Python versions, you can define USE_PYTHON as [min]-[max] or min+. (eg. >> 2.1-2.3, 2.0+ or -2.2) >> >> I have tested apr1 against python27 and have not seen any negative >> side >> effects unless someone can point it out but this port seems to be the >> only port holding up my builds due to this define. >> >> It seems correct to me that it should be using: >> USE_PYTHON=2.6+ or USE_PYTHON=-2.7 > Absolutely, I'll make the change momentarily. That was originally set > b/c 3.x+ does run the .py build generation scripts. > Thank you! Sir. -- jhell,v ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
devel/apr1 and python use.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Apache Team & Ports, Would I be able to persuade you guys to bump or change if you will USE_PYTHON_BUILD from -2.6 to -2.7 or switch to using USE_PYTHON= instead ? Comment from bsd.python.mk: This file contains some variable definitions that are supposed to make your life easier when dealing with ports related to the Python language. It's automatically included when USE_PYTHON or PYTHON_VERSION is defined in the ports' makefile. Define PYTHON_VERSION to override the defaults that USE_PYTHON would give you. If your port requires only some set of Python versions, you can define USE_PYTHON as [min]-[max] or min+. (eg. 2.1-2.3, 2.0+ or -2.2) I have tested apr1 against python27 and have not seen any negative side effects unless someone can point it out but this port seems to be the only port holding up my builds due to this define. It seems correct to me that it should be using: USE_PYTHON=2.6+ or USE_PYTHON=-2.7 Regards, PS: This might also serve as a heads up to the rest of ports that use python in their builds to also consider that there is a python27 port now and see how their port reacts to being configured to it. - -- Too many knobs... jhell,v -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMi1QcAAoJEJBXh4mJ2FR+lsoH/ijKOCcMkURTMcO+R/qcMF14 uL/QuhTwGrPReDGwUn15WvMDZRSgfSIChGngTMJiQPxbgFaCr6gCtzqpdgio+dPk 9J+8EYX86FB+6Ol7Me+n8jKsGNDepD3EIdQFhpy4MBnzlf5srC6HRXV7mz3AFv3p LIKe+Czgey55atzI2oqoJpqPQprxIzM7oxrlDTH1xVrgH5HC3doxFM6gTQuDMc0+ Q90yK/3BbxxyDIhqm0QtuMmM8ptA73OSytSSk8VBs8Dehm18rHuJi/GdrfYc1/DW jVmNsqaza0aFqwd602KlzmIoDcrXDEnKwoMaXrFc8DBTQQksjIPnXig+cRmAClE= =0stj -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: portmaster with no run arguments.
On 09/10/2010 17:35, jhell wrote: > > Hi Doug, > > Just thought I would write you about an unexpected output from > portmaster to get your opinion. I just ran 'portmaster' alone without > any arguments to get the list of "--help". Surprising enough to me it > searched for a null port and output the following. > > ===>>> No valid installed port, or port directory given > ===>>> Try portmaster --help > > Would it be wise if portmaster was run with no arguments that it just > output the '--help' by default ?. > > > Thanks & Regards, > Or better yet. That list seems pretty verbose just for running portmaster with no arguments, what about just printing the "Usage" information instead, along with the --help as a usage. Regards again, -- jhell,v ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
portmaster with no run arguments.
Hi Doug, Just thought I would write you about an unexpected output from portmaster to get your opinion. I just ran 'portmaster' alone without any arguments to get the list of "--help". Surprising enough to me it searched for a null port and output the following. ===>>> No valid installed port, or port directory given ===>>> Try portmaster --help Would it be wise if portmaster was run with no arguments that it just output the '--help' by default ?. Thanks & Regards, -- jhell,v ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [CFT] GNU gdb(1) 7.2 Shell Archive - devel/gdb7
On 09/07/2010 12:39, FreeBSD Ports wrote: > 06.09.2010 19:53, jhell написав(ла): >> I have just created a gdb7 port from the existing devel/gdb6. > > Sir, if your port follows my example of having the Insight (GUI-front > end for GDB) as an option, you have my blessing. Back in the day I had > to manually rip-out the Insight-bits out of the giant tarball the > developers had for download (they included the entire gdb, Tcl, Tk, > iTcl, and iTk with it!). > > If your port has the same kind of granularity, I'll gladly add your port > and can also make you a maintainer of devel/gdb6. Yours, > > -mi Alright, I wasnt looking into it too far but I can flip those back into the port. The current port of gdb6 already does not work for Insight if you have any other version of Tcl installed other than 8.4 so I guess I have some work to do in order to get that into shape. The main part that I am worried about ATM is functionality before experimental changes and I can add or work on putting the Insight support back into gdb7 while we get to this stage. Also the TUI support for some reason seems borked in XTerm, not sure about others so I am looking into that too. All-in-all its looking up besides one report on FreBSD-CURRENT that that does not recognize powerpc-unknown-9.0 but that seems to be a simple slight of hand fix. Personally I am not really looking to be the or a maintainer of any port but am willing to step up and submit patches and whatever is needed given free time is available so please do not misunderstand my intentions with the previous email as I am only looking to get these on an updated schedule so they flow with the rest of ports usage. Also still having ports in CVS adds some unnecessary overhead on my end that I am not prepared to deal with permanently at this point. But can if need be for a short time step in to help out. Later today Ill be putting the gdb7 port that I constructed into a Mercurial repo on GoogleCode so if people want to contribute they can easily by cloning and making their changes locally. Regards, -- jhell,v ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [CFT] GNU gdb(1) 7.2 Shell Archive - devel/gdb7
On 09/06/2010 19:53, jhell wrote: > > Hello Ports Users & Porters, > > I have just created a gdb7 port from the existing devel/gdb6. If you > would like to give this a few rounds of testing and ultimately decide if > it either a). needs adjustment or b). should be committed. then I would > greatly appreciate it. > > I have uploaded the SHAR file here: > http://bit.ly/ddYHDG > > (gdb7.shar) > MD5: 7b512c1f7397a989591ad204d5723104 > SHA1: 525875364f1cb07f2ef6d5be8f2474e20b65cefe > SHA256: f61ff837758665427047428f078c693550c51b2df8c2f4014f0d70ad9e660331 > SIZE: 5802 > > To test (any directory): > sh /path/to/gdb7.shar > > Will create ./gdb7 in your current working directory. So to extract it > to /usr/ports/devel you should first cd(1) to that directory before you > issue that command. > > Regards & Good luck testing, > Additional information. This was tested on stable/8 r212250 i386. If you are testing on head or 7 and another arch, & find issues, it would be greatly appreciated during the feedback cycle if you could provide a patch that fixes it for you as I do not have a stable/7 or head system to test on. Thank you, -- jhell,v ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
[CFT] GNU gdb(1) 7.2 Shell Archive - devel/gdb7
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Ports Users & Porters, I have just created a gdb7 port from the existing devel/gdb6. If you would like to give this a few rounds of testing and ultimately decide if it either a). needs adjustment or b). should be committed. then I would greatly appreciate it. I have uploaded the SHAR file here: http://bit.ly/ddYHDG (gdb7.shar) MD5:7b512c1f7397a989591ad204d5723104 SHA1: 525875364f1cb07f2ef6d5be8f2474e20b65cefe SHA256: f61ff837758665427047428f078c693550c51b2df8c2f4014f0d70ad9e660331 SIZE: 5802 To test (any directory): sh /path/to/gdb7.shar Will create ./gdb7 in your current working directory. So to extract it to /usr/ports/devel you should first cd(1) to that directory before you issue that command. NOTE TO THE MAINTAINER OF GDB6: I plan to file a PR (not filed yet) for a repo-copy of gdb6 -> gdb7 and request that gdb66 be sent to Attic as the gdb6 port is already at 6.6. and the 6.6 series is already pretty dated. The patch Ill submit with the PR is here: http://bit.ly/cZDVp3 After the repo-copy I will submit a patch to update gdb6 it to 6.8. In the event that the maintainer is not available Ill request that it be returned to ports@ as the maintainer with me in the CC list and I will do what I can to submit patches, given if free time is available to do so. Any thoughts on the above statements or questions please direct them to directly to me and the maintainer listed in the CC line. Thanks. Regards & Good luck testing, - -- jhell,v -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMhX7zAAoJEJBXh4mJ2FR+BXoH/ituKPP9tcnnpPH50B6LpVfl PgunL1zwUQ2ueCg4J4dOu6SHX9zd9xPLKbJNqemDWlMW6FKH7mafVhh/AIWdSXcx 1LjMKDbMNyWnNH215i3TeDfSmNNZMBwV2JrMDJZBki5ebb0vn1w+1Rg3pPRLbSCb 72rF+PdyCXXkWuuj/5y/aid9WfZBGgLwn3GB1sOxJzouBuZ5WPXynByRc3ccq/i0 l56GWb902Je15xwcknSDwaVQYOw67ofvqAMULWLAlOcKcgsJtD834DpFjW2t2IUF CNK9iQHOjbdhCntfI3YTifmQx/RgkPs/ukbMiE6V+2CYIYk/HXQmrH9EIe5MfbM= =UYoT -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
[SOLVED]: math/blas linking to gfortran with LDADD?= -lgfortran
On 09/05/2010 15:12, Peter Jeremy wrote: > On 2010-Aug-31 17:14:50 -0400, jhell wrote: >> On 08/31/2010 15:06, b. f. wrote: >>> Would you elaborate, please? Where is a transcript showing the linking >>> failure? >>> Would you mail it to me off-list? >> >> Simply -lgfortran by it self should not work. Since lib directories > > Actually, IMO, since libgfortran.so is a support library for gfortran > (much like libgcc_s.so is), it is reasonable for a user to expect > that '-lgfortran' _is_ sufficient and the current behaviour is a bug. > ports/129518 says I'm not the only person who think that. > >> -L/usr/local/lib/gcc44 would have to be passed to LDFLAGS in order for >> it to be found. > > And '-R/usr/local/lib/gcc44' as well. > > Note that a work-around has been added to bsd.gcc.mk so that ports > with USE_GCC shouldbehave correctly and the problem is limited to > using a non-base gcc outside the ports system. > Unfortunately this was caused by devel/ccache ;( or probably better said ccache attributed to finding this bug. The problem was that ccache was or is not liable for finding the lib/gccXX installs and therefore being called before, discards appropriate paths or whatnot ultimately borking the build. How I missed the problem was assuming that src.conf(5) is not used by ports(7) I had put the appropriate ccache, if then else statements in src.conf(5) to specifically keep it away from ports(7). As explained by b.f. math/blas being as old as it is uses files from /usr/src, so with that noted src.conf(5) gets pulled in and resulted in ccache being set by CC & CXX defines. The default if statement that I had in src.conf(5) was the one from the FreeBSD ccache example... Shouldn't have caught that right ??? think again... I had also set WRKDIRPREFIX=/usr/obj for ports(7)! in a if statement in make.conf(5) ARG!!! Here is the example: .if (!empty(.CURDIR:M/usr/src*) || !empty(.CURDIR:M/usr/obj*)) && !defined(NOCCACHE) Of course /usr/src is not empty here and of course /usr/obj is not empty, thats where I am compiling and of course I did not specify NOCCACHE because IMHO src.conf(5) should not be pulled into ports(7) at all. So needless to say I went the harder route of non-automation and changed that quickly to: .if defined(MY_LOCAL_DEFINE_HERE) && !defined(NOCCACHE) And now compiling graciously the ports I want with -DMY_LOCAL_DEFINE_HERE It would be real nice if someone could add NOCCACHE & WITHOUT_CCACHE to the ports .mk files so ports like math/blas can quickly override the use of ccache if the user decides to use the default example provided in local/share/doc/ccache/ccache-howto-freebsd.txt So to say the least there were multiple faulted layers here at play including me! Also math/lapack will not compile if a user has specified WITHOUT_PROFILE in there src.conf(5) specifically it wants libc_p.so.7 but a system with the above set will not have that installed. They are fixing this. Regards, -- jhell,v ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: math/blas linking to gfortran with LDADD?= -lgfortran
On 09/01/2010 01:41, b. f. wrote: > On 9/1/10, jhell wrote: >> On 09/01/2010 01:14, jhell wrote: >>> On 09/01/2010 00:58, b. f. wrote: >>>> No, it will still take effect, after the math/blas Makefile is parsed, >>>> unless _WITHOUT_SRCCONF is defined. See bsd.own.mk. >>> >>> ports(7) pulls in src.conf ??? I hope I am not understanding this right... >>> >> >> No wonder why some of my ports are fricking ticking my counters with >> ccache! (!...@#!%#$%#@!$...@# !...@#!$@#...@% @$...@$@%...@#^) >> >> Now that I know I can burn that bridge right now by adding that to >> make.conf in a .if (.CURDIR:M/usr/ports*) > > Well, that would be wise in any event, to minimize build pollution. > But if you look in /usr/share/mk/bsd.port.mk, you will see that > bsd.own.mk is typically only included after _WITHOUT_SRCCONF is > defined. It is only exceptional cases where src.conf can have any > effect in Ports. > > b. So really then the only ultimate way to get around this if someone needed it that bad would be make.conf with a .CURDIR:M for /usr/src/* and pull in their own dynamically evil hidden defines. Or creating their own define that will not be referenced by anything in source or ports. This is mind boggling in more ways than one but at least knowing this now can save the heart ache in the future. Personally I think were hitting a design bump in the road here that raises concern of how is this going to look 5,10,15 years from now. This seems a pretty apparent warning sign IMHO that something should be forked from this now and work be done to separate the two and make a simple strategic set of knobs that are well defined and minimal by design ultimately easing the project and the cruft floating around the pkg_install-NG debates. I know these are a lot of things to handle all at once given the large amount there is to work with but since these all of a sudden have been coming out of the framework and becoming more and more apparent its time to fix them permanently. If only I had the time and the money to sit here all day I would be more than happy to take this on but unfortunately I don't, at least for right now. Thanks, Regards & Good Dreams, -- jhell,v ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: math/blas linking to gfortran with LDADD?= -lgfortran
On 09/01/2010 01:14, jhell wrote: > On 09/01/2010 00:58, b. f. wrote: >> No, it will still take effect, after the math/blas Makefile is parsed, >> unless _WITHOUT_SRCCONF is defined. See bsd.own.mk. > > ports(7) pulls in src.conf ??? I hope I am not understanding this right... > No wonder why some of my ports are fricking ticking my counters with ccache! (!...@#!%#$%#@!$...@# !...@#!$@#...@% @$...@$@%...@#^) Now that I know I can burn that bridge right now by adding that to make.conf in a .if (.CURDIR:M/usr/ports*) FF Sakes. Thank you. -- jhell,v ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: math/blas linking to gfortran with LDADD?= -lgfortran
On 09/01/2010 00:58, b. f. wrote: > No, it will still take effect, after the math/blas Makefile is parsed, > unless _WITHOUT_SRCCONF is defined. See bsd.own.mk. ports(7) pulls in src.conf ??? I hope I am not understanding this right... -- jhell,v ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: math/blas linking to gfortran with LDADD?= -lgfortran
On 09/01/2010 00:10, Scot Hetzel wrote: > On Tue, Aug 31, 2010 at 10:06 PM, b. f. wrote: >> On 8/31/10, jhell wrote: >>> Looking closer at the math/blas & math/lapack ports: >>> >>> This statement does not make any sense. The logic is backwards for every >>> instance. And WITH_PROFILE would do. >>> .if !(defined(NOPROFILE) || defined(NO_PROFILE) || defined(WITHOUT_PROFILE)) >>> PLIST_FILES+= lib/libblas_p.a >>> .endif >>> >>> Which is basically saying: >>> Add that profile lib if NOPROFILE is not defined "_p is a profiled lib >>> why would you want to install this if the admin has NOT defined NOPROFILE? >>> >> >> Er, I'm not sure what you're getting at here. No means no. Really. >> The default, as I explained, is to build and install the profiling >> libraries, unless one or more of three disabling variables has been >> defined. And that's the default because users of these ports often use >> the profiled libraries when analyzing performance of their programs, >> which are usually computationally-intensive. Why the three variables? >> Because they control whether the profiling libraries are actually >> built via bsd.compat.mk and bsd.lib.mk. >> > Actually there are only 2 *_PROFILE variables (WITH_PROFILE and > WITHOUT_PROFILE) that are user visible for the FreeBSD sources. The > NOPROFILE variable is depreceiated, and the NO_PROFILE variable is > only supposed to be used in Makefiles according to bsd.own.mk: > > # Define MK_* variables (which are either "yes" or "no") for users > # to set via WITH_*/WITHOUT_* in /etc/src.conf and override in the > # make(1) environment. > # These should be tested with `== "no"' or `!= "no"' in makefiles. > # The NO_* variables should only be set by makefiles. > > So according to bsd.own.mk, this is the correct test for the math/blas > port to determine if profiling libraries should be built: > > .if !defined(WITHOUT_PROFILE) > PLIST_FILES+= lib/libblas_p.a > .endif > > I also tested how these variables responded: > > vbox# cd /usr/src/lib/libcam > vbox# make -V WITH_PROFILE -V MK_PROFILE -V NO_PROFILE -V WITHOUT_PROFILE > > yes > > > vbox# make -V WITH_PROFILE -V MK_PROFILE -V NO_PROFILE -V > WITHOUT_PROFILE WITH_PROFILE=yes > yes > yes > > > vbox# make -V WITH_PROFILE -V MK_PROFILE -V NO_PROFILE -V > WITHOUT_PROFILE NO_PROFILE=yes > > no > yes > > vbox# make -V WITH_PROFILE -V MK_PROFILE -V NO_PROFILE -V > WITHOUT_PROFILE WITHOUT_PROFILE=yes > > no > > yes > > vbox# make -V WITH_PROFILE -V MK_PROFILE -V NO_PROFILE -V > WITHOUT_PROFILE NOPROFILE=yes > "/usr/share/mk/bsd.compat.mk", line 35: warning: NOPROFILE is > deprecated in favour of NO_PROFILE > > no > yes > > > As can be seen, NOPROFILE is deprecated. > > NOTE: WITHOUT_PROFILE would need to be set in /etc/make.conf (instead > of /etc/src.conf) to disable building profiled libraries in the > FreeBSD sources and the math/blas port. > > Scot Thank you Scot As for src.conf Yes I know it would need to be defined in make.conf globally to effect src & ports. But to my belief at the time I did not believe that anything in ports would blindly assume that setting something with profiling would be acceptable which is why I suggested the if defined(WITH_PROFILE) instead. Things that enable options like profiling usually used for debugging that is not used in general usually lead to an infestation of other targets and programs that link against them and in some cases like the -PIE instance a while back with samba and cups where something in one of the source files was configured in a way that lead to global profiling of anything that had enabled -PIE during their builds resulting in *.gprof files being created in /. This is just one of the reasons why I don't like profiling enabled without the user knowing that its going to happen. For reference PR/143924 & MFC commit r205567 that happened during releng/7.2 days. Regards & Thank you again. -- jhell,v ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: math/blas linking to gfortran with LDADD?= -lgfortran
being able to deal with it but there is simply to many knobs to account for things that could be handled by fewer knobs. The way I see it is WITH_ means use this and WITHOUT_ means do not use and can be contorted with operators like (!) in either form that already adds enough complexity to handle even the stickiest situations with ports but on top of that you have NOPROFILE NO_PROFILE etc... etc... and whatever else may be used to define (NO|DONT|DO|THAT|WITH|THESE) If this is for sheer compatibility then why aren't the *.mk files handling this instead of forcing it upon the maintainers. If you were to write a C program in this sense then gawd! only knows what the consequences would be so why are we doing it here?. Please do not take offense to any of this as I am just trying to understand why in a sea of Makefile's & define's. Regards, -- jhell,v ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: math/blas linking to gfortran with LDADD?= -lgfortran
Looking closer at the math/blas & math/lapack ports: This statement does not make any sense. The logic is backwards for every instance. And WITH_PROFILE would do. .if !(defined(NOPROFILE) || defined(NO_PROFILE) || defined(WITHOUT_PROFILE)) PLIST_FILES+= lib/libblas_p.a .endif Which is basically saying: Add that profile lib if NOPROFILE is not defined "_p is a profiled lib why would you want to install this if the admin has NOT defined NOPROFILE? Second add that lib if NO_PROFILE is defined ? see previous question still doing the wrong thing here. Third add that lib if WITHOUT_PROFILE is defined ? see previous two question still not doing the right thing here. Simple following would do. .if (defined(WITH_PROFILE) PLIST_FILES+= lib/libblas_p.a ,endif Then if it is really a concern that this has to default to on, then use the options framework to present that to the user. At least in this instance the user will at least know whats going on. Regards, -- jhell,v ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: math/blas linking to gfortran with LDADD?= -lgfortran
On 08/31/2010 15:06, b. f. wrote: > Would you elaborate, please? Where is a transcript showing the linking > failure? > Would you mail it to me off-list? Simply -lgfortran by it self should not work. Since lib directories gcc44 gcc45 gcc46 and such are not in the standard path -L/usr/local/lib/gcc44 would have to be passed to LDFLAGS in order for it to be found. Off list should not be necessary. > > I don't find this to be the case. Perhaps you could provide listings for > `ldd -a /usr/local/lib/libblas.so.2`, `objdump -x > /usr/local/lib/libblas.so.2`, and > `make -C /usr/ports/math/blas -v -d l deinstall clean all`, with and > without your change, off-list? > With my change in objdump the only thing listed in objdump -x that is relevant to -lgfortran is the RPATH=/usr/local/lib/gcc44 and there is no undefined symbols. Without my change it simply will not build unless I either a) remove -lgfortran or b) add -L/usr/local/lib/gcc44 > ? USE_FORTRAN=yes ==> USE_GCC=4.4 > > You don't see any relevant undefined symbols in the blas libraries? > > With regards to your statements about math/lapack and profiling: it > has been the case for some time that this port has built and installed > these libraries by default, perhaps because this port has mainly been > used by people concerned about numerical linear algebra and concrete > measures of performance. I recently added the statement you quoted to > allow users to avoid these libraries -- it intentionally mirrors the > similar statement in the allied port math/blas, where the form is is > dictated by the use of bsd.lib.mk to build the libraries. Given the > typical use of these ports, I don't think it is unreasonable to enable > profiling libraries by default. But if you don't like it, you can now > easily opt out. Would it be possible with this to check for the existence of -lc_p before and opt out automatically while warning the user that the profiled libc was not found so profiling will be unavailable. ? Specifically this port is making a blind assumptions that profiled libraries are installed on the system it is being installed on, I do not find that to be correct. Something like this would best be handled by options that default off. gfortran44 -O -pg -c dsecndtst.f -o dsecndtst.o gfortran44 -O -pg -c tstiee.f -o tstiee.o gfortran44 -O -pg -c ilaver.f -o ilaver.o gfortran44 -O -pg -c LAPACK_version.f -o LAPACK_version.o gfortran44 -Wl,-rpath=/usr/local/lib/gcc44 -pg -o testlsame lsame.o lsametst.o /usr/local/bin/ld: cannot find -lc_p collect2: ld returned 1 exit status *** Error code 1 -- jhell,v ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: RFT: deskutils/sciplore-mindmapping
On 08/31/2010 13:01, Matthias Andree wrote: > Am 31.08.2010 17:47, schrieb J. Hellenthal: > >> Runs as expected on FreeBSD 8.1-STABLE. Java runs like shit, menu's for >> me have been wacked for some time with no seen fix in the future. I am >> starting to think its my minimal approach to X using Xmonad as a window >> manager but the last time I tried to get anyone to test and see if >> things worked! properly I had no replies. Would be nice to get software >> like this working but who knows. > > Hi J, > > java/jdk16 seems to work reasonably well for me, where the Xorg stuff was > automatically installed as part of a gnome2 desktop dependency for me, menus > work seemingly OK (AMD Radeon HD 3300 two-generations-past chipset graphics > here). > > Java is not blazingly fast (compared to Ubuntu Linux on the same hardware, I'M > using FreeBSD 8.1-STABLE amd64), but then again ZFS is the bigger hog on > performance currently. > >> Other than the above, nice job... Submit & Commit! > > Thanks. I'm a ports committer though, so you won't see an ephemeral PR - and I > am still awaiting a bit more feedback (I got test promises in private mail) > but > might commit Thursday night (European time) then. > > > I'd also appreciate if some of the java@ team could comment on the coding > style > of the port's Makefile/pkg-* files (unless someone already did and I didn't > reckon that). > > Best regards > Matthias I just patched up my xmonad. Just for reference the referring URL to the fix is here: http://bit.ly/cZt3UX to make Java act correctly in a non-re-parenting Window Manager. I am in a way shocked that they knew about this back at 0.8 and were up to 0.9 now with no fix... Sigh... I have not looked into this until now that I saw that you were working on SCIPlore very useful utility small and faster than Freemind in a lot of ways. Anyway... Thanks! Regards, -- jhell,v ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: i7z for FreeBSD
On 08/27/2010 09:30, Emanuel Haupt wrote: > How hard would it be to port i7z to FreeBSD? Seems like a very useful tool. > > http://code.google.com/p/i7z/ > This seems a little like ports/misc/cpuid, is it ? -- jhell,v ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: math/blas linking to gfortran with LDADD?= -lgfortran
On 08/30/2010 19:41, jhell wrote: > > The subject listed port fails to link during an upgrade from the > previous version. Looking into this further libblas.so.2 without being > linked to gfortran is correct as in the already installed previous > version installed inspected with ldd(1) shows the same linking as the > new version without the -lgfortran linker flags. > > Attached is the patch that solves the linking problem. I do not see any > dependents listed for this port for any of the gcc* ports that can be > installed so therefore I have removed the -lgfortran from LDADD. > > $FreeBSD: ports/math/blas/Makefile,v 1.47 2010/08/30 07:26:27 bf Exp $ It also appears that recent changes in math/lapack make blind assumptions that the user wants to compile these with ???PROFILING??? why? .if !(defined(NOPROFILE) || defined(NO_PROFILE) || defined(WITHOUT_PROFILE)) Would this not be better with if (defined(WITH_PROFILE)) ?? But then again this port also breaks so I guess I do not have to worry about blind assumptions here. -- jhell,v ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
math/blas linking to gfortran with LDADD?= -lgfortran
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The subject listed port fails to link during an upgrade from the
previous version. Looking into this further libblas.so.2 without being
linked to gfortran is correct as in the already installed previous
version installed inspected with ldd(1) shows the same linking as the
new version without the -lgfortran linker flags.
Attached is the patch that solves the linking problem. I do not see any
dependents listed for this port for any of the gcc* ports that can be
installed so therefore I have removed the -lgfortran from LDADD.
$FreeBSD: ports/math/blas/Makefile,v 1.47 2010/08/30 07:26:27 bf Exp $
Regards,
- --
jhell,v
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJMfEGwAAoJEJBXh4mJ2FR+cDUH/RfAGgADnpT862Ef2NrWYmvC
l49FDRSDjPpyWEAOX2tpQ4Is7/88N0siumeVqKSLYesxb9tRL2sAAcmHvAo0UR7I
JyufU49SIqvnsgMWV5Lkfb+l2Kb/7+C1BhQLA6PuotsyehGPgeH+1SynT/MtR+1I
kIlVtWVz0f5BwQ4Tny8aeqPLEmCcnkCJlZtXWjYfvlhULE/qhjlK67Q0T71oaGfN
Feyso8uDDsviwXEkwULRRIMmLTCNt5ZuJOsQe0VZiZR9Xfgc0MxVVcC4USvWHCiS
ODME2TZiTS7Gau5aAw/NT5PuugkrBOzvmS62X5xaMLpSaEAcrlpi6zyTIC3dIbo=
=Fabs
-END PGP SIGNATURE-
--- Makefile.orig 2010-08-30 19:27:57.024501012 -0400
+++ Makefile 2010-08-30 19:29:09.372193126 -0400
@@ -28,7 +28,7 @@
PLIST_FILES= lib/libblas.a lib/libblas.so lib/libblas.so.${SHLIB_MAJOR}
LDFLAGS+= ${FFLAGS}
-LDADD ?= -lgfortran -lm
+LDADD ?= -lm
MAKE_ENV+= LDADD="${LDADD}" LDFLAGS="${LDFLAGS}" \
SHLIB_MAJOR="${SHLIB_MAJOR}"
.for _u in AR NM RANLIB
blas.diff.sig
Description: Binary data
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: devel/p4d patch
On 08/29/2010 09:18, olli hauer wrote:
> On 2010-08-29 14:17, jhell wrote:
>> Hi Gordon,
>>
>> I just upgraded devel/p4d port and you might find this patch
>> interesting. This port would previously bail out trying to display the
>> pkg-message file that it can't find without a path.
>>
>> On a second note. Where it displays this message ``post-install'' does
>> not seem like the right place to display this message as it is not
>> really noticeable during that stage. But to solve this file not being
>> found I patched it up with the following.
>>
>> --- Makefile.orig 2010-08-29 08:08:25.801295898 -0400
>> +++ Makefile2010-08-29 08:10:49.149776482 -0400
>> @@ -49,7 +49,7 @@
>> ${INSTALL_PROGRAM} ${_DISTDIR}/p4d ${PREFIX}/sbin/
>>
>> post-install:
>> - @${CAT} pkg-message
>> + @${CAT} ${PORTSDIR}/devel/${PORTNAME}/pkg-message
>> ${MKDIR} ${DESTDIR}${P4ROOT}
>> ${CHOWN} p4admin:p4admin ${DESTDIR}${P4ROOT}
>> ${CHMOD} 750 ${DESTDIR}${P4ROOT}
>>
>>
>
> Hi J,
>
> this will only work if you install via ports but not via package.
>
> Try '@${CAT} ${PKGMESSAGE}' instead, the port system will find
> the file and it will be displayed during (package) install.
>
> post-install is the right section, but I agree the message can be
> overlooked easily, this is one of the reason some pkg-messages
> start and end with a line of '=' signs and have some blanks
> between the '..' line and the message self.
>
Hi Olli,
Thank you for the feedback. I knew there was something more to it!. Good
to know that is the right place for this. Maybe adding a @${ECHO} to the
bottom and top of that statement to echo a separation line would make it
more clear. Leaving it up to Gordon as I just wanted to inform him about
the error so it can be fixed.
Thank you again & Regards,
--
jhell,v
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
devel/p4d patch
Hi Gordon,
I just upgraded devel/p4d port and you might find this patch
interesting. This port would previously bail out trying to display the
pkg-message file that it can't find without a path.
On a second note. Where it displays this message ``post-install'' does
not seem like the right place to display this message as it is not
really noticeable during that stage. But to solve this file not being
found I patched it up with the following.
--- Makefile.orig 2010-08-29 08:08:25.801295898 -0400
+++ Makefile2010-08-29 08:10:49.149776482 -0400
@@ -49,7 +49,7 @@
${INSTALL_PROGRAM} ${_DISTDIR}/p4d ${PREFIX}/sbin/
post-install:
- @${CAT} pkg-message
+ @${CAT} ${PORTSDIR}/devel/${PORTNAME}/pkg-message
${MKDIR} ${DESTDIR}${P4ROOT}
${CHOWN} p4admin:p4admin ${DESTDIR}${P4ROOT}
${CHMOD} 750 ${DESTDIR}${P4ROOT}
Regards,
--
jhell,v
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: portmanager endlessly looping in x11
On 08/25/2010 21:27, Chuck Robey wrote: > I have an interesting thing here: I seem to have found an endless loop in > portmanager. It's *entirely* possible that I'm myself causing this, so I'll > explain, and if you can come up with any hints, I'll be happy to test them, > because I really do like using portmanager. > > What my goal is, is to update the qt4 port, but one of the dependencies it > finds > is x11/libX11 ... and two (the only 2) dependencies it finds unsatisfied for > libX11 are x11/libXau and x11/libXtrans. Trouble is, it endlessly (and > seemingly quite successfully) rebuilds both of these, but them can't seem to > find either to mark them as satisfied (to move onlto building libX11). I > tried > to cd into both of these dirs and build them directly using make > clean/package/clean, and it succeeds fine, but portmanager *still* can't get > past them. > > My ports are up to date, no more than a week old, I use cvs to keep the > sources > nicely up to date. I'd really appreciate any suggestions you can offer. CC: of ports-mgmt/portmanager is a good start. Maybe He/She can give you some insight of the working of portmanager. I am not sure how portmanager keeps the package database up to date but sometimes dependencies can get messed up in the database that can cause a loop and if not handled correctly by the upgrade process can cause a lot of grief. In portmaster you could be using --check-depends and in portupgrade you could use -Ffu but you don't seem to be using any of the suggested ports-mgmt upgrade utilities so good luck. ``emphasis on portmaster'' -- written by dougb@, so you know it works!. Regards, -- jhell,v ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: what next for the pkg_install rewrite
On 08/19/2010 23:08, Garrett Cooper wrote:
> On Aug 19, 2010, at 7:30 PM, jhell wrote:
>
>> On 08/19/2010 21:26, Garrett Cooper wrote:
>>> On Thu, Aug 19, 2010 at 3:10 PM, Ivan Voras
>>> wrote:
>>>>> On 19/08/2010, jhell wrote:
>>>>>>> Adding to this I would like to see a central database
>>>>>>> created for packages that have been removed like in
>>>>>>> Slackware Linux. They keep a file in
>>>>>>> /var/log/preserved_packages with a flat text format with
>>>>>>> the file name looking like:
>>>>>>>
>>>>>>> ${PORTNAME}-${PORTVERSION}${PORTREVISION}-`date
>>>>>>> +%Y%m%d%H%M%S`
>>> Please no. We need another ad hoc text format like we need holes
>>> in our head.
>>>
>>
>> You may have misunderstood or maybe not the intention behind that
>> file.
>>
>> This is just simply a log file of the transactions that were
>> performed upon package deletion and nothing more but just a way for
>> the user to look back and say "HEY! how did that get there!." or
>> "where in the ``jhell'' did that file come from!" that they can
>> simply grep the package removal logs to find out.
>>
>> -- Shameless plug with my email name put in for humor.
>
> :)
>
>> It is also really handy if you remove some packages that somehow
>> the depends had been messed up and later on your having a problem
>> with a missing lib, easy enough to grep the removal logs to find
>> out what package held that file. Especially useful if you only use
>> binary packages.
>
> This is part of the request that someone was making for a feature
> like Gentoo's world file on the forums:
> http://forums.freebsd.org/showthread.php?t=16963 .
>
> Personally it's one of the takeaways I like about Gentoo's portage
> system because it's easy to track what I as a user installed
> manually, and hence, it's easy to track what can be removed (instead
> of using pkg_cutleaves) if we have a `emerge -C` (package dependency
> [dist]clean equivalent). It also makes it easier for admins to mass
> install packages on multiple machines using a smaller `distroot'
> install binary base, so all I would have to do is:
>
> 1. Install prebuilt version of FreeBSD with sysinstall / ad hoc
> installer method. 2. Say, pkg_add 3. Do
> whatever I need to do to configure the machine.
>
> Done.
>
> That would make system administration really easy and slick, and
> would improve the setup process for corporations that build on a
> static FreeBSD base for several releases and have varying packages
> for several bits. I know if my group did it, things wouldn't be such
> a mess..
>
> By the way... /var/lib/portage/world is a simple text file composed
> line by line like:
>
>
>
> i.e.
>
> devel/gcc46 lang/python26 www/firefox36
>
> etc. Simple and easy to understand, and easy to modify :).
>
>> There is a lot of information that can be logged, especially with
>> '-v', I personally do not think we or anyone for that matter should
>> pass up that opportunity to make sure the information is collected
>> rather than leaving it up to the user to redirect or script(1) the
>> output every time which they would still or should be able to do.
>>
>> Another approach that I have not seen talked about here is a
>> proposed directory layout. I think before 'unless I missed it' that
>> someone jumps into this, some standards & goals should be made and
>> made quite loudly as to attract as much public opinion and
>> suggestions as possible for what works, what does not & what people
>> would like to see.
>>
>> Something of this magnitude like changing packaging databases and
>> directory structures and all that involved needs a central place
>> and a clear, clean plan to be developed properly. I personally do
>> not see this list anymore as a proper place to discuss it.
>> packaging@ list request ? so this can all be centralized.
>
> I agree that it's high time that a freebsd-packaging@ list be
> created. sysinstall has its own list now -- we should have one for
> the packaging software too :).
>
>> PS: I have been toying with the idea of the directory layout just
>> for spurring thoughts of others. http://bit.ly/aNLhNU but until
>> there is a central place for these things it does not mean much.
>
>
> I think that you're adding unnecessary complexity to the overall
> issue. It really d
Re: what next for the pkg_install rewrite
On 08/19/2010 17:45, Thierry Thomas wrote: > Le Jeu 19 aoû 10 à 23:24:10 +0200, jhell > écrivait : > >> As well I would also like to see something done about packages that >> don't need to be upgraded because they are neither platform or arch >> dependent but yet they are upgraded due to being listed as a dependent >> of another port that needs to be upgraded. For example any package that >> may be type shell script does not need updating due to a major lib >> version bump of for say libpng. > > For this purpose, it's already possible to check if the port set > NO_BUILD. > > Regards, Ah then to my understanding, port/pkg upgrade tools do not have any way currently implemented that checks for this to skip those or PORT_REVISION bumps are being made on those at the time a shlib major version bump happens or both. Thanks for your reply. -- jhell,v ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: what next for the pkg_install rewrite
On 08/19/2010 21:26, Garrett Cooper wrote:
> On Thu, Aug 19, 2010 at 3:10 PM, Ivan Voras wrote:
>> > On 19/08/2010, jhell wrote:
>>> >> Adding to this I would like to see a central database created for
>>> >> packages that have been removed like in Slackware Linux. They keep a
>>> >> file in /var/log/preserved_packages with a flat text format with the
>>> >> file name looking like:
>>> >>
>>> >> ${PORTNAME}-${PORTVERSION}${PORTREVISION}-`date +%Y%m%d%H%M%S`
> Please no. We need another ad hoc text format like we need holes in our head.
>
You may have misunderstood or maybe not the intention behind that file.
This is just simply a log file of the transactions that were performed
upon package deletion and nothing more but just a way for the user to
look back and say "HEY! how did that get there!." or "where in the
``jhell'' did that file come from!" that they can simply grep the
package removal logs to find out.
-- Shameless plug with my email name put in for humor.
It is also really handy if you remove some packages that somehow the
depends had been messed up and later on your having a problem with a
missing lib, easy enough to grep the removal logs to find out what
package held that file. Especially useful if you only use binary packages.
There is a lot of information that can be logged, especially with '-v',
I personally do not think we or anyone for that matter should pass up
that opportunity to make sure the information is collected rather than
leaving it up to the user to redirect or script(1) the output every time
which they would still or should be able to do.
Another approach that I have not seen talked about here is a proposed
directory layout. I think before 'unless I missed it' that someone jumps
into this, some standards & goals should be made and made quite loudly
as to attract as much public opinion and suggestions as possible for
what works, what does not & what people would like to see.
Something of this magnitude like changing packaging databases and
directory structures and all that involved needs a central place and a
clear, clean plan to be developed properly. I personally do not see this
list anymore as a proper place to discuss it. packaging@ list request ?
so this can all be centralized.
Regards,
PS: I have been toying with the idea of the directory layout just for
spurring thoughts of others. http://bit.ly/aNLhNU but until there is a
central place for these things it does not mean much.
--
jhell,v
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: what next for the pkg_install rewrite
On 08/19/2010 12:50, Ivan Voras wrote:
> - Fully specify and separate package name from its version - metadata
> should not record "apache-2.2.13" but "apache", "2.2.13" to better
> support upgrading and dependancies.
> - Debian-like dependancies - the "suggests" variety, as well as
> "ranged-dependancies" - package X depends on Y versions W through Z.
> - A wrapper for all pkg_ tools to use, implemented with libarchive.
> This wrapper would allow preparation of the whole archive layout
> in-memory, together with simulating common file system operations
> like chmod, chown, rmdir, mkdir, rename, unlink, etc. and would as a
> last step offer to serialize this virtual file system to an archive.
> - Policy to forbid the lazy-maintainer dances with package names, such
> as package names depending on config flags used, etc. - this probably
> needs more thinking through. Essentially, I want to avoid things like
> what happened to the apr port - names like
> "apr-ipv6-devrandom-gdbm-db42-1.4.2.9.3.1_1"
Adding to this I would like to see a central database created for
packages that have been removed like in Slackware Linux. They keep a
file in /var/log/preserved_packages with a flat text format with the
file name looking like:
${PORTNAME}-${PORTVERSION}${PORTREVISION}-`date +%Y%m%d%H%M%S`
With the contents being that of all the actions that were performed
upon package removal & and any output from errors etc.
Id like to see that same approach achieved within /var/db/preserved or
something similiar for a suggestion.
I have attached a copy of removepkg from Slackware 13.1 that appears to
be a 1 clause BSD license ;) for reference.
As well I would also like to see something done about packages that
don't need to be upgraded because they are neither platform or arch
dependent but yet they are upgraded due to being listed as a dependent
of another port that needs to be upgraded. For example any package that
may be type shell script does not need updating due to a major lib
version bump of for say libpng.
Regards,
--
jhell,v
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
#!/bin/sh
# Slackware remove package script
#
# Sat Apr 25 21:18:53 UTC 2009 (12.34567890b)
# Converted to use new pkgbase() function to remove pathname and
# valid package extensions.
#
# Revision 12.34567890 Sun Apr 5 20:59:32 CDT 2009
# - Support packages with the extensions: .tgz, .tbz, .tlz, .txz
#
# Revision 1.9 Wed Oct 31 14:04:28 CDT 2007 volkerding
# - Fix problem removing packages with a large number of fields.
# Thanks to Niki Kovacs for noticing this, and to Piter Punk
# for the patch.
# - Use LC_ALL=C locale, which is much faster with "sort".
# Thanks to Tsomi.
# - Don't try to remove any package that starts with '-'. This
# is not a proper package name (usually a typo), and results
# in the package database being broken. Thanks to Jef Oliver.
# - Patched cat_except() to allow the last Slackware package on
# a partition to be removed (using ROOT=, of course)
# Thanks to Selkfoster for the patch, and to everyone else who
# proposed solutions before. This issue really wasn't given
# the highest priority before, but I figured while I'm in here...
#
# Revision 1.8 Thu Nov 22 14:00:13 PST 2001 volkerding Rel $
# - Move $TMP underneath $ROOT
# - Understand the idea of a base package name, so that packages
# can be removed with any of these notations:
# removepkg foo-1.0-i386-1.tgz
# removepkg foo-1.0-i386-1
# removepkg foo.tgz
# removepkg foo
#
# Revision 1.7 2001/03/30 12:36:28 volkerding
# - Strip extra ".tgz" from input names.
#
# Revision 1.6 1999/03/25 18:26:41 volkerding
# - Use external $ROOT variable, like installpkg.
#
# Revision 1.5.1 1998/03/18 15:37:28 volkerding
# - Since removepkg is always run by root, the temp directory has been
# moved from /tmp to a private directory to avoid symlink attacks from
# malicious users.
#
# Revision 1.5 1997/06/26 12:09:53 franke
# - Fixed old bug in TRIGGER regex setting
# - -preserve/-copy options now preserve non-unique files
# and empty directories also
#
# Revision 1.4 1997/06/09 13:21:36 franke
# - Package file preserve (-preserve, -copy) added.
# - Don't execute "rm -rf" lines from doinst.sh, removing links explicit.
# - Warning on no longer existing files added.
# - Warning on files changed after package installation added.
# - Intermediate file preserve (-keep) added.
# - Check for required files/links now done on a combined list.
# - Write access to /var/log/{packages,scripts} no longer necessary for -warn.
#
# Revision 1.3 1997/06/08 13:03:05 franke
# Merged with revision 1.1.1.1
#
# Revision 1.2 1996/06/01 20:04:26 franke
# Delete empty directories & formated manual pages added
#
# Revision 1.1.1.1 1995/
Re: It's annoying when something other than rsyncd listens on tco/873
On 08/16/2010 01:49, David Wolfskill wrote: > My build machine is noisy & generates heat, so I leave it powered off > when it's not actively in use. > > As a consequence, it gets rebooted rather often. > > It is configured to run rsyncd(8) so I can update my laptop's local mirror > of the FreeBSD SVN repository. > > A couple of mornings ago, I woke up, ready to start my daily builds (on > the laptop & build machine), but noticed that the SVN mirror on the > laptop hadn't been updated. Eventually, I discovered that the reason > was that amd(8) [on the build machine] was listening on 873/tcp, which > is the port for rsync. I restarted amd(8); it happened to get other > ports, so I restarted rsyncd(8), and was able to perfomr the mirroring. > > Mind, that was the first time since around February that I've had a > problem with using rsyncd(8) in this fashion. > > Since then, I've become a bit ... sensitized to the issue, so a > quick "sockstat -4l" immediately after powering it on helps avoid ths > sort of thing. > > So this evening, such a check showed that ypbind(8) was listening on > 873/tcp. > > The most straightforward way to make this a non-issue (it seems to me) > would be to start rsyncd(8) before other services that grab arbitrary > ports; however, the start-up script for rsyncd s[ecifies: > > # PROVIDE: rsyncd > # REQUIRE: LOGIN > # BEFORE: securelevel > # KEYWORD: shutdown > > and both amd & ypbind specify > > # BEFORE: DAEMON > > so that approach doesn't seem to quite work out. > > (I note that I recently stopped tracking stable/7 on the build machine, > so I now boot into stable/8; perhaps something changed between stable/7 > and stable/8 that inicreases the probability of such an unfortunate > collsion.) > > Also, rsyncd(8) doesn't appear to consider this a condition worthy of > note -- at least, I wasn't able to find any whines, and the daemon was > still running. > > Anyone have suggestions for avoiding a recurrence (vs. working around > the coiindition should one occur)? > I have been at this point once or twice and it always boiled down to rpcbind in my situation on a few NIS+ boxen. The problem that I came across was that /usr/local/etc/rc.d is parsed long after /etc/rc.d contents so adding the BEFORE to the rsync start script would not help or didn't at that time. One thing that comes to mind is that script that Jeremy? posted for waiting for the network a certain period of time before initializing services. Maybe this could also play a role in a situation to have a services script that could be controlled by rc.conf(5) to wait for a service to come up before continuing its own operation. And of course it should continue no matter what in either case but would allow you to introduce possibly needed delays in the rc. Here is a slightly modified version of Jeremy's script that I use. http://bit.ly/cpbrlm Food-4-Thought Regards, -- jhell,v ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: i keep *trying* to move from portupgrade to portmaster
On 08/06/2010 18:03, Adam Vande More wrote:
> On Fri, Aug 6, 2010 at 4:26 PM, Doug Barton wrote:
>
>> I need to add an option for this, but it will likely be an "expert"
>> option that you can set in the rc file. The theory is that package
>> creation failure should be a rare thing, and since portmaster has no way
>> to know what packages are really critical to any given system it treats
>> inability to safely recover from an upgrade failure as a critical error.
>> However, having the ability to disable this is an oft-requested feature,
>> I just haven't gotten to it yet.
>>
>> I actually took a look at the code in this area last night with an eye
>> towards creating this option, I'll see if I can get it done for the next
>> release.
>>
>
> While your in the mood for for taking portmaster suggestions, I think an
> option to backup all currently installed packages would be useful. I have a
> python script that does this for me, but it would be easy enough to use sh
> as well. I do this because there have been too many times something has
> broken during a port upgrade run and I need to revert immediately and fix
> later. I realize the backup package feature sort of does the same thing,
> but reconciling the pre- and post- updates is a tough thing for me. Having
> a user defined directory all currently installed ports can be put in is much
> easier to work with IMO. I know of other people doing similar things because
> I shared my script on questions- and got a few responses awhile ago.
>
Just for reference. Doug B. has already touched on this.
#!/bin/sh
trap 'exit 1' 2
_pkg_bld(){
cd /exports/packages
for package in `ls /var/db/pkg |sed 's/pkgdb.db//'`; do
echo "Building package: $package"
pkg_create -v -b $package >>pkg_bld.log 2>&1
done
}
_pkg_bld
I never did add a test to see if the package was already there but then
again I used this before extreme situations that the upgrades would span
the whole ports tree.
--
jhell,v
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: i keep *trying* to move from portupgrade to portmaster
On 08/06/2010 17:26, Doug Barton wrote: >> and force creation of whatever you have on the system already? > Not sure what this means, can you explain it in more detail? No matter what the state of a package is I feel deeply that when making a backup package, that should not fail because of a missing file that might have been caused by a incorrect pkg-plist or whatever. Most of the times I have noticed backup package creation fail was caused by tar(1) or other tools not being able to stat a file or directory. For instance: Creating bzip'd tar ball in '/exports/packages/GraphicsMagick-1.1.15_3,1.tbz' tar: lib/ImageMagick-6.6.2/modules-Q16/coders/djvu.la: Cannot stat: No such file or directory tar: lib/ImageMagick-6.6.2/modules-Q16/coders/djvu.so: Cannot stat: No such file or directory tar: Error exit delayed from previous errors. pkg_create: make_dist: tar command failed with code 256 And this has left the GraphicsMagick package incomplete. I would believe that portmaster is probably dealing with the same problem. > >> > Configuration option to email the output of upgraded packages and their >> > pkg-message or a similar option to just log to a file? > The ability to log actions to a file is already in the dev version in > svn. You have to specify PM_LOG in your rc file. I want to see how that > goes first before I consider adding a command line option for it. I > don't anticipate adding e-mail functionality to portmaster, that sounds > like something that should be done in a wrapper script, along with > PM_LOG. (Although, there was a meme from the early days that no Unix app > is complete until it grows the ability to do e-mail, so you never know ...) > I agree with you on this. Seeing as PM_LOG will be there that makes it much easier to deal with. -- jhell,v ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: i keep *trying* to move from portupgrade to portmaster
On 08/06/2010 04:58, Sandra Kachelmann wrote: > On Fri, Aug 6, 2010 at 10:06 AM, Doug Barton wrote: >> On 08/06/2010 00:24, Sandra Kachelmann wrote: >>> I've been using ports-mgmt/portupgrade pretty much ever since it >>> started to exist. Unfortunately portupgrade seems to be pretty much >>> "abandonware" so I've been told to move on to portmaster. Despite the >>> very long manpage I can't seem to be able to achieve the following >>> thing with portmaster: >>> >>> $ portupgrade --batch -a >> >> Someone who has used portupgrade and is familiar with exactly what >> --batch does can probably help you with that bit, but I'm sure by now >> you've figured out that portmaster has a -a feature. >> >> Meanwhile, go get a $BEVERAGE, get comfortable, and actually _read_ the >> portmaster man page, don't just skim through it. I put a lot of effort >> into explain what portmaster does, how it does it, and also WHY it does >> things the way it does. Most (if not all) of your questions are answered >> there. > > Please don't take this wrong but IMO it's way too overdocumented for > normal users that don't actually read bsd.ports.mk before breakfast > :-) > > Sandra I have done exactly what you want with (portmaster -a), albeit you should sit there and wait for any option screens to pop up until you leave but it can be done. But also see below. Doug, One fallback that I cannot seem to get over is the creation of a backup package failed do you want to ignore [i] message prompt & the package messages that are displayed with $PAGER at the end of the upgrades. I do not recall the packages that his had happened on, it does not happen often but when it did happen it was just before a nice long compile of OpenOffice :( while I was gone. The pkg-message problem has been stumping me since it inhibits my use of pwait(1) on another terminal. For instance I started a portmaster -a on one terminal and issued pwait(1) on another so I could build a new kernel and world right after a ports(7) upgrade. Since the pkg-message is displayed with PAGER obviously the initial portmaster process never terminates and post processes are revolving so they would/could exit to soon. Do not prompt for a backup package creation failure and force creation of whatever you have on the system already? Configuration option to email the output of upgraded packages and their pkg-message or a similar option to just log to a file? Also I still see a need for installing a /usr/local/etc/portmaster.rc.sample file for whatever version is installed and seperating that from the man page. This would make it much easier on the end user to configure portmaster for options they see fit. Forwarded apologies if any of this is confusing. Regards, -- On another note I wish wc(1) would output some headers above these. ;) $ man portmaster |wc -Lclmw 6103363 30764 187 jhell,v ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Whither Thunderbird 3.1(.1)?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Just for the sheer sake of saying it since its the least I can do for this, I would like to say thanks to the gecko team for all the nice work. Having email with a nice project integrated like lightning means a world of difference for a lot of people if not just me. For the FreeBSD Project to have invaluable tools at-hand like these is priceless and speaks for it self among all the features and tools available. So with a final word, Thanks. Regards, - -- jhell,v -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (FreeBSD) iQEcBAEBAgAGBQJMWZUFAAoJEJBXh4mJ2FR+6S4H/3YXokrFYjg+bFARmyEmP0B4 wds5X9IygWH0XoZgbBTQ1RAmTZ31BbsjPeOzrwFjUZYeikW/nNDWrrqM+NoZPoFl jtIORjSnbVJRQUpRUn/68GTUiQfJWPyv2QhpJThoJLcrgTWGxQXD5wM4I2HbEe2W Vords8kE+89QcZci63lQ/sAYjOtqmNXbTZ7wtRHFqofrkwPHXJpExWouZjwKZ73b M9a9ikf9yOtmZCxH75KFEDj6VdKjXDqMaDeY9fc9ogDTVxpMuKbHWXYOukvP2NG5 l3MDOveHHL/93mxc+hXM9Zui9h1eK6OOrXRukKRLKtbVM2Fc1txMZb7x4/mNflA= =J2M7 -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ?? lang/python27 ?? Why is this even here ?
On 07/24/2010 23:38, Rob Farmer wrote: > On Sat, Jul 24, 2010 at 7:49 PM, jhell wrote: >> # New ports collection makefile for:python26 >> # Date created: 3 July 2003 >> # Whom: Hye-Shik Chang >> # >> # $FreeBSD: ports/lang/python27/Makefile,v 1.166 2010/05/12 12:13:06 wen >> Exp $ >> >> PORTNAME= python26 >> PORTVERSION=2.6.5 >> > > It's a repocopy - in cases like this, instead of starting a fresh file > at version 1.1, one of the cvs administrators copies the files from > the old port so that the history is maintained. So, the copy happened, > but a committer hasn't actually upgraded the port yet. > > It's discussed in the committers guide: > http://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/article.html#AEN1391 > No offense but I already know this. I do appreciate the time you took to explain this with the additional link. Thank you. I guess I should have made it more clear. +===+ | This happened?: 2010/05/12 12:13:06 | | And the date now: 2010/07/25 00:08:51 | +===+ This is more than 2 months that nothing has been done with this port. Unless I am wrong and the repo-copy is recent with an old date but I thought that the ident(1) line was/is/should be updated when this happens?. After a repo-copy I would have thought that these lines should have been updated to establish the new port and for whom created it, which would then be re-committed bumping the version to 1.167 and recent date so there is no confusion. # New ports collection makefile for:python26 # Date created: 3 July 2003 # Whom: Hye-Shik Chang A nice part about it is you can switch your ORIGIN to that and be all set for the upgrade. ;) Any way I just wanted to give a heads up for this as it seemed pretty odd as things like this usually happen and get updated all about the same time that a repo-copy happens & this has been in ports that I know of for more than ~1.5 weeks without any sort of update. Regards, PS: These were not followed from the link above. When a port has been repo copied: 1. Do a force commit on the files of the copied port, stating repository copy was performed. 2. Upgrade the copied port to the new version. Remember to change the LATEST_LINK so there are no duplicate ports with the same name. In some rare cases it may be necessary to change the PORTNAME instead of LATEST_LINK, but this should only be done when it is really needed -- e.g. using an existing port as the base for a very similar program with a different name, or upgrading a port to a new upstream version which actually changes the distribution name, like the transition from textproc/libxml to textproc/libxml2. In most cases, changing LATEST_LINK should suffice. -- jhell,v ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
?? lang/python27 ?? Why is this even here ?
# New ports collection makefile for:python26 # Date created: 3 July 2003 # Whom: Hye-Shik Chang # # $FreeBSD: ports/lang/python27/Makefile,v 1.166 2010/05/12 12:13:06 wen Exp $ PORTNAME= python26 PORTVERSION=2.6.5 Use it, or remove it ? Regards, -- jhell,v ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Problems with sysutils/screen (GNU Screen)
On 07/23/2010 15:43, Jim Trigg wrote: ls -l /usr/share/misc/termcap* You should see two files termcap and termcap.db Check the perms of both and the existence of both. I believe that cap_mkdb(1) is run on termcap to create the db but someone else should chime in on this because I am not sure at the moment. Regards, -- jhell,v ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: CFT: New version of portmaster in svn
On 07/23/2010 20:13, Doug Barton wrote: >> Server side: ( at port snapshot creation ) >> LOCATE_CONFIG=/usr/ports/locate.rc /usr/libexec/locate.updatedb >> locate.rc: >> FCODES="/usr/ports/locate.database" >> SEARCHPATHS="/usr/ports" >> >> real 149.79 > > It's not 100% clear to me what you're timing here, but it took 2.5 > minutes to do it. This was for creating the locate database with thoughts of how long it would take to do this upon every port snapshot. >> Just for creating the list of distfiles from the SIZE contents: >> $ du -sh DISTINDEX.8.1.gz >> 512BDISTINDEX.8.1.gz >> >> time -alhp ./createindex.sh >> real 490.99 > > Sorry I'm so dense, but I'm still not following exactly what part of the > process you're referring to here, but this time it took over 8 minutes. > Given that the method I'm using to generate a 100% up to date version of > the list that's guaranteed to get all the distfiles takes less time, I > do not think I will be adding the feature you are suggesting, but I do > appreciate the suggestion. :) No problem but just for clarity. This was on the client side but as well could be done server side from running the following. #!/bin/sh export LOCATE_PATH=/usr/ports/locate.databasea for distinfo in $(locate "/usr/ports/*/*/distinfo"); do grep SIZE $distinfo >>DISTINDEX.8.1 done Regards & Good to hear back from you, -- jhell,v ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: CFT: New version of portmaster in svn
On 07/23/2010 15:00, Doug Barton wrote: > The problem is that in order to accomplish that portmaster would have to > check every port in the tree. Assuming 22,000 ports, and that any given > port is equally likely to fall anywhere in the tree, on average you'd > have to search 11,000 ports for every distfile that is not related to a > port installed on that system. > > Now what I _could_ do is use the same technique I use in > --clean-distfiles (create a text file with the distfile information) but > instead of limiting it to installed ports, do all of them. I have never > even tested that to see how long it would take, but I suppose I could > take a look. Hi Doug Barton, Ports@, Here is a suggestion that I have just played around with involving locate(1) with environment LOCATE_PATH set in portmaster & ports-side locate.updatedb(8) with LOCATE_CONFIG before the port snapshots are made. Server side: ( at port snapshot creation ) LOCATE_CONFIG=/usr/ports/locate.rc /usr/libexec/locate.updatedb locate.rc: FCODES="/usr/ports/locate.database" SEARCHPATHS="/usr/ports" real 149.79 user 3.51 sys 27.53 2076 maximum resident set size 37 average shared memory size 3946 average unshared data size 134 average unshared stack size 2893 page reclaims 335 page faults 0 swaps 0 block input operations 0 block output operations 0 messages sent 0 messages received 0 signals received 35875 voluntary context switches 38020 involuntary context switches In portmaster(8): LOCATE_PATH=/usr/ports/locate.database Generate a list of distinfo files and create a distfile index using ``SIZE''. for file in $(locate "/usr/ports/*/*/distinfo"); do grep "SIZE " $file >>DISTINDEX.8 done Use the output from that to judge if the file in /usr/ports/distfiles needs to exist or of the file does not meet the SIZE requirements & you can kill two birds with one stone. You could always use the MD5 or SHA256 sum that's recorded but that may be IMO a slight bit of overhead. This may not be an exact proccess right now but it sure would be nice to have a locate database in ports that could be updated by (make locatedb) or something similar. Just for creating the list of distfiles from the SIZE contents: $ du -sh DISTINDEX.8.1.gz 512BDISTINDEX.8.1.gz time -alhp ./createindex.sh real 490.99 user 28.03 sys 117.14 1820 maximum resident set size 228 average shared memory size 2297 average unshared data size 133 average unshared stack size 2353331 page reclaims 0 page faults 0 swaps 0 block input operations 0 block output operations 0 messages sent 0 messages received 0 signals received 77884 voluntary context switches 165392 involuntary context switches Regards, -- jhell,v ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
net-mgmt/net-snmp Unresolvable links in libs
The following libs have Unrsesolvable links while lang/perl5.12 is installed. This was not tested to be true while 5.10.1 was installed. /usr/local/lib/libnetsnmpmibs.so.20 /usr/local/lib/libnetsnmphelpers.so.20 While this has not shown to be a problem in this installation it may pose a problem to others that depend on those directly. Temporary correction for this problem: test -d /usr/local/lib/compat/pkg ||mkdir /usr/local/lib/compat/pkg ln -s /usr/local/lib/perl5/5.12.1/mach/CORE/libperl.so \ /usr/local/lib/compat/pkg/libperl.so Regards, -- jhell,v ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: portmaster packages and perl upgrade
On 07/20/2010 12:45, Douglas Berry wrote: > I use portmaster on a build machine to make packages, copying /var/db/ports, > and /usr/local/etc/ports.conf to all clients, and NFS mounting /usr/ports on > the clients. Whats in your ports.conf ? Also as in "I don't use it" I believe ports.conf relies on being pulled in by make.conf am I correct ? If so then you would also have to include your make.conf on every host you expected that to work on right ? -- jhell,v ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
_PERL_REFACTORING_COMPLETE lang/perl5.12 Mk/bsd.perl.mk
The following consumes a "lot" of the bsd.perl.mk file. Could this have any negative impact on ports that were previously using the areas that are contained in the if statements ?. net-snmp-5.* Installs cleanly and depends on libperl.so right after its installed (twice I might add) libnetsnmphelpers.so.20 from /usr/local/lib has a "libperl.so => (0x0)". I forked around this for now by symlinking the real libperl.so to /usr/local/lib but I assume other problems already exist that haven't been seen. ./bsd.perl.mk:85:.if defined(_PERL_REFACTORING_COMPLETE) ./bsd.perl.mk:116:.endif # defined(_PERL_REFACTORING_COMPLETE) ./bsd.perl.mk:178:.if defined(_PERL_REFACTORING_COMPLETE) ./bsd.perl.mk:185:.endif # defined(_PERL_REFACTORING_COMPLETE) ./bsd.port.mk:1455:.if !defined(_PERL_REFACTORING_COMPLETE) ./bsd.port.mk:1491:.endif # !defined(_PERL_REFACTORING_COMPLETE) ./bsd.port.mk:2052:.if !defined(_PERL_REFACTORING_COMPLETE) ./bsd.port.mk:2057:.endif # !defined(_PERL_REFACTORING_COMPLETE) Regards, -- jhell ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: General note on rc scripts and daemonizing
On Sat, 17 Jul 2010 18:43, jhell wrote:
In Message-Id:
On Sat, 17 Jul 2010 06:56, Ed Schouten wrote:
In Message-Id: <20100717105658.gv1...@hoeg.nl>
Hello port maintainers,
I think I'd better send an email about this to ports@, because I've seen
it in various places and it is getting a bit tiresome to mail all port
authors individually.
I've seen various cases in the past where people write rc scripts that
do the following:
command="/usr/local/bin/dog"
command_args="--bark > /dev/null 2>&1 &"
So in this case `dog --bark' doesn't daemonize itself, so the & is
sufficient here, right? Well, it is not. :-) The point is that we simply
tell the kernel to redirect stdout/stderr and run it in the background.
It doesn't tell the kernel that the process should run in a separate
session (see getsid(2)/setsid(2)).
This has various implications. The most important one I can think of, is
that the daemon can still do open("/dev/tty", ...) if it wants and spam
your TTY, even if the daemon is running as user `nobody'. This also
means that if you run the rc script from within a pseudo-terminal, it
can never actually destroy the pseudo-terminal for you, because maybe
the daemon is interested in using it.
Below is the output of `pstat -t' on one of my systems, where I decided
to fire up MySQL:
| LINE INQ CAN LIN LOW OUTQ USE LOW COL SESS PGID STATE
| ...
| pts/11 0000 000 0 82711 0 G
The kernel actually wants to clean up this pseudo-terminal (state = G),
but it is prevented from doing so. It will only clean it up by the time
MySQL is shut down.
So how can this be solved? We already have a tool in base called
daemon(8). It is simply a wrapper around daemon(3) (which calls
setsid(2), which you can use to daemonize processes. So the next time
you write an rc script and need to daemonize something which cannot do
it by itself, please think of the kittens. ;-)
[ CCing this to r...@. Maybe we should add some kind of built-in
functionality to call daemon(8)? ]
Hi Ed,
Very nice note as well a very good practice. I have noticed this for
a while but never looked into it more so I could not really put a name to it.
Thanks.
Off topic of ports:
While this subject is hot, I have been doing the following on an
updated system, current version of xterm on two up-to-date stable/8 machines.
I am having trouble narrowing down the cause of the controlling pseudo
terminal freezing until ^C is hit after using daemon(1) to spawn ssh in the
background to start a remote xterm.
# Open a pseudo terminal [pts/13]
xterm (the culprit)
# Mix up the terminal a little so its not so fresh. [pts/13]
ls -l
# Use daemon to start a remote xterm through ssh. [pts/13]
daemon ssh -M remotehost xterm
At this stage the remote x11 forwarded xterm opens and works properly "set
this terminal aside, its not the problem".
# On the originating pseudo terminal [pts/13]
su -
Password: **
host# _
After that you should have to hit ^C to proceed to the next bang line or
enter anything for that matter.
Any clue at what might be going on or any more information that I could
provide to help deduce this ?.
Regards,
Also another use with the case above. Running top(1) instead of su(1) you
should see the same symptoms.
I should probably also state that using the -f flag to ssh(1) without
daemon(1) does not exhibit any of these symptoms.
Regards,
--
jhell,v
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Cant get new port Makefile to work
On Sat, 17 Jul 2010 22:04, jhell wrote: In Message-Id: On Sat, 17 Jul 2010 21:26, Doug Barton wrote: In Message-Id: On Sun, 18 Jul 2010, Joe wrote: Reviewed the portlint and portmaster port Makefiles and they both have the source files provided as part of the port. I have this method already working. Need to change to method where the source files have to be fetched from remote site. Looking for template of that method. Look at the other 20,000 ports as examples? :) You can also read the porter's handbook. Have it download the new copy from per-say, http://svn.freebsd.org/base/users/dougb/portmaster/release/portmaster.sh ? ;) Then maybe the example rc from the man page can be separated so management daemons can handle the differences ? ;) ;) -- jhell ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Cant get new port Makefile to work
On Sat, 17 Jul 2010 21:26, Doug Barton wrote: In Message-Id: On Sun, 18 Jul 2010, Joe wrote: Reviewed the portlint and portmaster port Makefiles and they both have the source files provided as part of the port. I have this method already working. Need to change to method where the source files have to be fetched from remote site. Looking for template of that method. Look at the other 20,000 ports as examples? :) You can also read the porter's handbook. Have it download the new copy from per-say, http://svn.freebsd.org/base/users/dougb/portmaster/release/portmaster.sh ? ;) -- jhell ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Fakeroot for ports new round
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Links are useful & save time. http://bit.ly/cNAYLd On Sat, 17 Jul 2010 18:29, Baptiste Daroussin wrote: In Message-Id: Hi all, I just send a new fakeroot patch for the ports (uptodate). Patch can be found here : ports/133815 the patch as begun as a port of the fakeroot implementation from midnightbsd ports system. What it does : basically it install everything in a fakeroot repository creates a package respecting the plist and only then installs it. currently adding USE_FAKE=yes in make.conf activates the feature. Some ports needs to be cleaned up to be able to works for example perl fails when creating the manpage for perl-after-upgrade.1. But most of them should just work Benefits : - currently porters have to do the *-install stuff twice one for the ports, one for the package. - some ports already uses fakes dir it would simplify them (firefox) - no more hacks to respects NOPORTSDOC NOPORTSDATA etc. - better QA : bad plist would be easily detected, no more crufts for end users - more focus on packages for QA for examples we could write tools to analyse them to be sure it respects the rules - better security : we could imagine to not allow ports to access anything that isn't in $WRKDIR like gentoo's sanbox or debian's fakeroot. disavantages: - overhead files a installed once of the fakeroot then a package is created and then installed. the could be reduced by adding the ability to pkg_add to copy files from a fakeroot respecting a plist like pkg_create does without creating the packages (for people who doesn't want packages) I think lot's of work can be done there to reduce the overhead. for a recall every modern packages system uses a fakeroot like features : openbsd's ports, pkgsrc, rpmbuilding, debian packaging with this feature I sure porters would benefit cleaner Makefiles and user would benefit better quality packages/ports. I need help finishing the patch because I just can't test everything. I also would like to get a clear statement on whether or should continue working on this (ie is there a chance that this could be accepted). regards, Bapt - -- jhell -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (FreeBSD) iQEcBAEBAgAGBQJMQjN7AAoJEJBXh4mJ2FR+DlQH/3CHUb+k2Xty1MFt9h/Yyeki SRxrPeTDhHJl90sF4EPmBV1TD5+S2wI1VVZtVQLtbTLrbm2L8f6H1Rz1wN40vxnq qO8OqlaMmXjnh1zF6zISG6vBI/x7ohhqJHP+rzod/xt8894UAFMkfK2s7z36woNY IsVZb1R4TLJQ0+q9tFyl3vA02Dq7HVU+PkaTOj9Us/fIsRh+e91ux7XlFjMZRCO7 cIIbQbhVtNdYQOeP0awr8XaF8p6cpOiQ97hcJ22TVJnT6frYhh4WtXbVrK5oGDky G4aCmqnnONkykTJ6cjGKGeZukZJWaqsJpFk0rSMdI9T6FXdzOsCRpzyJPHnW24M= =h7u3 -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: General note on rc scripts and daemonizing
On Sat, 17 Jul 2010 06:56, Ed Schouten wrote:
In Message-Id: <20100717105658.gv1...@hoeg.nl>
Hello port maintainers,
I think I'd better send an email about this to ports@, because I've seen
it in various places and it is getting a bit tiresome to mail all port
authors individually.
I've seen various cases in the past where people write rc scripts that
do the following:
command="/usr/local/bin/dog"
command_args="--bark > /dev/null 2>&1 &"
So in this case `dog --bark' doesn't daemonize itself, so the & is
sufficient here, right? Well, it is not. :-) The point is that we simply
tell the kernel to redirect stdout/stderr and run it in the background.
It doesn't tell the kernel that the process should run in a separate
session (see getsid(2)/setsid(2)).
This has various implications. The most important one I can think of, is
that the daemon can still do open("/dev/tty", ...) if it wants and spam
your TTY, even if the daemon is running as user `nobody'. This also
means that if you run the rc script from within a pseudo-terminal, it
can never actually destroy the pseudo-terminal for you, because maybe
the daemon is interested in using it.
Below is the output of `pstat -t' on one of my systems, where I decided
to fire up MySQL:
| LINE INQ CAN LIN LOW OUTQ USE LOW COL SESS PGID STATE
| ...
| pts/11 0000 000 0 82711 0 G
The kernel actually wants to clean up this pseudo-terminal (state = G),
but it is prevented from doing so. It will only clean it up by the time
MySQL is shut down.
So how can this be solved? We already have a tool in base called
daemon(8). It is simply a wrapper around daemon(3) (which calls
setsid(2), which you can use to daemonize processes. So the next time
you write an rc script and need to daemonize something which cannot do
it by itself, please think of the kittens. ;-)
[ CCing this to r...@. Maybe we should add some kind of built-in
functionality to call daemon(8)? ]
Hi Ed,
Very nice note as well a very good practice. I have noticed this
for a while but never looked into it more so I could not really put a name
to it. Thanks.
Off topic of ports:
While this subject is hot, I have been doing the following on an
updated system, current version of xterm on two up-to-date stable/8
machines. I am having trouble narrowing down the cause of the controlling
pseudo terminal freezing until ^C is hit after using daemon(1) to spawn
ssh in the background to start a remote xterm.
# Open a pseudo terminal [pts/13]
xterm (the culprit)
# Mix up the terminal a little so its not so fresh. [pts/13]
ls -l
# Use daemon to start a remote xterm through ssh. [pts/13]
daemon ssh -M remotehost xterm
At this stage the remote x11 forwarded xterm opens and works properly
"set this terminal aside, its not the problem".
# On the originating pseudo terminal [pts/13]
su -
Password: **
host# _
After that you should have to hit ^C to proceed to the next bang line or
enter anything for that matter.
Any clue at what might be going on or any more information that I could
provide to help deduce this ?.
Regards,
--
jhell,v
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: stable/8 net/ifstated build failed.
On 07/13/2010 20:53, Sahil Tandon wrote: > On Tue, 2010-07-13 at 20:28:46 -0400, jhell wrote: > >> cc -O2 -pipe -combine -fno-strict-aliasing -combine -Wall >> -I/usr/obj/usr/ports/net/ifstated/work/ifstated-4.7 -Wstrict-prototypes >> -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wshadow >> -Wpointer-arith -Wcast-qual -I/usr/local/include -std=gnu99 >> -fstack-protector -c log.c >> log.c:31: error: expected '=', ',', ';', 'asm' or '__attribute__' before >> 'void' > > Have you tried building with default CFLAGS? > Its still the same output regardless. -- +-+-+-+-+-+ |j|h|e|l|l| +-+-+-+-+-+ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
sysutils/tcplist "lsof use" broken
The above subject mentioned port is broken via its usage of sysutils/lsof. Log: # ./tcplist lsof: unknown -s protocol: "li" lsof 4.84 latest revision: ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/ latest FAQ: ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/FAQ latest man page: ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/lsof_man usage: [-?abChlnNoOPRtUvV] [+|-c c] [+|-d s] [+|-D D] [+|-f[cfgGn]] [-F [f]] [-g [s]] [-i [i]] [-k k] [+|-L [l]] [-m m] [+|-M] [-o [o]] [-p s] [+|-r [t]] [-s [p:s]] [-S [t]] [-T [t]] [-u s] [+|-w] [-x [fl]] [--] [names] Use the ``-h'' option to get more help information. ./tcplist: Can't get lsof output header So I manipulated my own script to output something like the following <->UID LOCAL:PORT REMOTE:PORT ===== == == 241001192.168.31.2:59782 192.168.31.12:993 241001192.168.31.2:59000 192.168.31.12:993 241001192.168.31.2:26007 192.168.31.12:993 241001192.168.31.2:25206 192.168.31.12:993 241001192.168.31.2:13985 192.168.31.12:993 131001192.168.31.2:61979 :80 131001192.168.31.2:59658 :80 131001192.168.31.2:53816 :80 131001192.168.31.2:49347 :80 131001192.168.31.2:39920 :80 131001192.168.31.2:14124 :80 11001192.168.31.2:25865 192.168.31.12:22 11001192.168.31.2:22 192.168.31.12:58642 11001192.168.31.2:12104 192.168.31.12:22 10 192.168.31.2:22 192.168.31.12:58642 If you could use something like this it is located here & remember this heavily depends on lsof and is still under construction. http://bit.ly/a54s2b Regards, -- +-+-+-+-+-+ |j|h|e|l|l| +-+-+-+-+-+ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
stable/8 net/ifstated build failed.
The following build error is from just before the timestamp on this message. Any way I can help let me know. --- FYI --- cc -O2 -pipe -combine -fno-strict-aliasing -combine -Wall -I/usr/obj/usr/ports/net/ifstated/work/ifstated-4.7 -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wshadow -Wpointer-arith -Wcast-qual -I/usr/local/include -std=gnu99 -fstack-protector -c log.c log.c:31: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'void' log.c:32: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'void' log.c: In function 'log_init': log.c:49: warning: implicit declaration of function 'tzset' log.c: At top level: log.c:140: warning: no previous prototype for 'fatal' log.c:155: warning: no previous prototype for 'fatalx' *** Error code 1 Stop in /usr/obj/usr/ports/net/ifstated/work/ifstated-4.7. *** Error code 1 -- +-+-+-+-+-+ |j|h|e|l|l| +-+-+-+-+-+ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Soprano Update eeded to 2.4.4 ? Current version not finding libiodbc
Lol how long did it take you to write all these emails ? I see this one is 4 hours later than the last one you have sent. With all due respect I do not see anyone else having the problem that you are having. Following along Doug Barton posting a way for you to fix this I would stick pretty close to that. But... adding to it I would also have you remove the full contents of /usr/local/* and some other common to your problem directories under /var. After you have gone through all this and have a pass or fail result, you might consider taking minimal time to write a email as most but only speaking for myself DO NOT HAVE the time to read a book of messages that only consist of a problem that only pertains to you. Severity: LOW Precedence: LOW On 07/04/2010 08:04, da...@vizion2000.net wrote: > > I have been ghaving substantial problems with soprano which appears to > caused by Redland Backend not be installed at compile time. The system is > freebsd 7.2 Amd64 on pentium quad core. > > > I found an interesting snippet at: > > http://forums.freebsd.org/showthread.php?t=14398 > > Aorchid said: > > "On my version there was an option for redland backend in Soprano. If there > is not on yours, you should edit the Makefile so that the option appears. > Rascal did build for me and there was no complaining of it being a broken > port...not sure." > > After reading this I realised that this could be connected with the message > "Soprano components that will not be built > Redland backend" which referred to http://librdf.org/ and eventually to > http://librdf.org/rasqal/ > > Console messages demonstrated that soprano was not finding the all important > libiodbc libraries. > > I went to http://soprano.sourceforge.net and founf the following: > > Soprano 2.4.4 released > Wed, 06/30/2010 - 20:20 - trueg > Soprano 2.4.4 is a bugfix release - probably the last one before the release > of Soprano 2.5. It features the following changes: > > Fix to FindIODBC.cmake which ensures that the correct locations are searched > first. This allows the usage of a locally installed libiodbc. > > Any chance of 2.4.4 being made available to see if this fixed the problem? > > > > > ___ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" -- +-+-+-+-+-+ |j|h|e|l|l| +-+-+-+-+-+ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: License Framework: Develop Best Practices
On 06/16/2010 16:06, Dominic Fandrey wrote: > On 15/06/2010 02:46, Marco Bröder wrote: >> BSD-2-clause# Simplified BSD License >> BSD-3-clause# Modified or New BSD License >> BSD-4-clause# Original BSD License > > Just a side note, am I the only one using a single clause variant > of the BSDL? I really don't give a damn what people do with > binaries, so out went the clause. > So really your using a MIT Style license just with a clause instead of the staticlly written "The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software." So why not just use that instead. Regards, -- jhell ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FreeBSD Port: gwhois-20100515
On 06/10/2010 06:14, Frank Reid wrote: > I've been running gwhois for a long time, but recently it stopped working > due to a missing dependency on p5-Net-LibIDN-0.12. The port doesn't appear > to recognize that perl module is needed. Thanks for maintaining the port. > I have tested all three of these ports on stable/8 r209090: This port requires package(s) "ca_root_nss-3.12.4 curl-7.20.1 gettext-0.18_1 libiconv-1.13.1_1 lynx-2.8.7.1_1,1 p5-HTML-Parser-3.65 p5-HTML-Tagset-3.20 p5-URI-1.54 p5-libwww-5.834 perl-5.10.1_1" to run. Please recheck that your ports database is correct i.e. portmaster --check-depends or portupgrade -fu or portupgrade -Fu or some combination of flags and then retry. Check man page for each tool for details. Not sure if you would be interested in a different whois client that is very functional but net/jwhois has quite a bit more options that you may be interested in if this one does not work out for you. Regards & Good Luck, -- jhell ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ap22-mod_perl2-* WTH!
On 06/03/2010 15:27, Philip M. Gollucci wrote: > On 06/03/10 12:39, jhell wrote: >> >> I did not install a package named ap22-mod_perl2, I installed mod_perl2 >> from ports!. So when looking for this package to check its status with >> pkg_info -g mod_perl2-\* >> >> I get! >> can't find package 'mod_perl2-*' installed or in a file! >> >> So needless to say (ls /var/db/pkg/ |grep mod_perl) to double check >> revealed the subject line. >> >> Can the person responsible for this change either back this out or come >> up with a better solution? using PKGNAMEPREFIX along with some conjured >> up APACHE_PKGNAMEPREFIX in ports/Mk/bsd.apache.mk does not seem like a >> viable solution to anything common to today problems. : No, it does solve issues and was requeste several times. It also : matches other ports/ tree things that do this. At least one of which is : that you can build mod_perl2 with both www/apache20 and www/apache22. : You might even have half a chance of knowing which one you are : installing too when you do a pkg_add. In what case will this actually happen ? bot apache20 and apache22 list each other as a CONFLICT... If this is a case for a jail(1) type environment then were going to start adjusting package names where these instances are few to none ? Maybe a better compromise would be to come up with a better solution for those few edge cases rather than adjust the package name for the many. Maybe a define that local to only that Makefile ? that when set adjusts the package name per the users request rather than making the assumption that everyone is going to do this... >> Maybe just copying the compile time options from var/db/ports/ if they >> exist to the packaging directory would be a better idea than >> >> apr-ipv6-devrandom-gdbm-db42-ndbm-mysql51-pgsql84-sqlite3-1.4.2.1.3.9_1 > No, this is so CONFLICTS in Makefiles can work. Several shared > libraries in ports/ do this. > >> machine it was compiled for i386 i486 i586 etc... etc.. etc. > The package already goes in an /$arch/ dir so thats not so usefule. > > Sorry we agree to disagree. > -- jhell ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: issues unveiled by devel/gettext
On 06/03/2010 00:35, Doug Barton wrote: > On 06/02/10 21:29, Doug Barton wrote: >> >> A better suggestion would be to do this: >> >> mkdir -p /usr/local/lib/compat/pkg >> cd /usr/local/lib >> mv libgettextpo.so.4 and libintl.so.8 /usr/local/lib/compat/pkg/ > > Oy, sorry, didn't think that all the way through. Instead of 'mv' it > should be 'cp,' then: > cd /usr/ports/devel/gettext > make clean ; make > pkg_delete gettext* > make install clean > > THEN: > >> /etc/rc.d/ldconfig start >> >> Then go about rebuilding your ports in an orderly manner until those >> libraries are no longer needed, at which point you can delete them. >> > I agree about both options but just as likely whether it be libmap.conf or a path in far distant directory usr/local/lib/compat/pkg/* are equally just as easy to be forgotten IMO. Though I do not know off the top of my head whether portmaster or any of the other utils look at removing files from the compat/pkg directory either which is why I state the previous. This brought me to the thought of a periodic check that would check for the existence of libmap.conf and usr/local/compat/pkg and display the contents or just warn of those being there and possibly populated. Anyhow regards, -- jhell ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
ap22-mod_perl2-* WTH!
I did not install a package named ap22-mod_perl2, I installed mod_perl2 from ports!. So when looking for this package to check its status with pkg_info -g mod_perl2-\* I get! can't find package 'mod_perl2-*' installed or in a file! So needless to say (ls /var/db/pkg/ |grep mod_perl) to double check revealed the subject line. Can the person responsible for this change either back this out or come up with a better solution? using PKGNAMEPREFIX along with some conjured up APACHE_PKGNAMEPREFIX in ports/Mk/bsd.apache.mk does not seem like a viable solution to anything common to today problems. Maybe just copying the compile time options from var/db/ports/ if they exist to the packaging directory would be a better idea than apr-ipv6-devrandom-gdbm-db42-ndbm-mysql51-pgsql84-sqlite3-1.4.2.1.3.9_1 WTH port is that! Is that sqlite3 now or is that apr? seeing as mod_perl2 was prefixed with ap22 and following that scheme would lead me to believe it is sqlite3 even though I do know it is apr. The only relevant SUFFIX I could see be usefull in this case is what machine it was compiled for i386 i486 i586 etc... etc.. etc. Anyway regards, .03 -- jhell ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Renamed Haskell Applications
On Wed, 26 May 2010 11:49, Dmitry Marakasov wrote: In Message-Id: <20100526154941.gc25...@hades.panopticon> * jhell (jh...@dataix.net) wrote: Recently I have tagged the following popular but Cabalized applications in the Ports Collection with the "hs-" prefix: - darcs [1]: devel/darcs -> devel/hs-darcs - pandoc [2]: textproc/pandoc -> textproc/hs-pandoc - xmonad [3]: x11-wm/xmonad -> x11-wm/hs-xmonad, x11-wm/xmonad-contrib -> x11-wm/hs-xmonad-contrib - xmobar [4]: x11/xmobar -> x11/hs-xmobar +1 Why do you think it's good to not have a port named the same as an application? Normally I would object to something like this but in this case being that it is about Haskell applications, the change helps users locate all of the Haskell related ports quicker. Its almost as if the hs-* ports were in their own category like the ports-mgmt tools are. For another part upgrading these will also be a slight bit smoother and locating what Haskell packages you have on your system will be easier just specifying hs-* to a upgrade tool or to pkg_de[lete|install]. Regards, -- jhell ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
src/usr.sbin/portsnap .cvs & .svn directories.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ports, Colin, ATM, I am looking over the possibility to make portsnap ignore ".cvs & .svn" either by default or through the use of some flags or some config variable that could be set and I am looking for your input. I am maintaining a internal revision of ports tree that I wish to use portsnap to update for the obvious reasons. While using portsnap to update that tree that is already under version control with Subversion, portsnap proceeds to remove .svn and .cvs directories. I have also tried a few tests with manipulating the REFUSE line in the config file with no luck, just for clarity - maybe I missed something. Does anyone see a problem with ignoring the .svn & .cvs directories by default ? If there is concern with that being the default would you rather see a flag or maybe multiple flags, one for svn, cvs, etc... ? Or would you rather see a configuration variable whether it be environment or from the portsnap.conf ? To make sure that I am covering it all, is there other VC directories that you would like to see excluded while I am here ? Suggestions for the unforeseen questions are welcome. If you see a quick way of doing this and you are already familiar with the internals of portsnap I would appreciate greatly any feedback as where to start or patches for testing. At-A-Glance I have minimal knowledge of the internals of portsnap. jhell/INBOX 2>&1 Thanks for your time, - -- jhell -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJL/TDgAAoJEJBXh4mJ2FR+JW0H/RCAfF1Ki5xKDpjIbiJGAJgk 3kVZds3sSxUAXyKXKw6r4OxEpkYQjKdCd6iIuoj54Ve0FRf6b7V6bgos0Cmmm3Rf 9WtpcTL7e4nGd1JSYjo42P2VPUqhXEX8ltB4VrdoaAZ4LE/tnZFQpj+Q6mDgWggL vVyaxwRUXZQ1ApztqPBfgtXTgnFZwFKy1B0uHS/LAIjWzMNg5i55Nl75/v0oPCXA xPYHPIKLayNXfQeBE44UDEfQeLTqTVoU92VrwkxHcWHOyrzJN7bAMUNkz0IGpLTV QOrK+M3zH+JopKsYUjREUsqlahYrjsoRhXzBAWsDlvlr2gldCAsQiDZ46TMUpOE= =p3L1 -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Renamed Haskell Applications
On 05/25/2010 10:16, Gabor PALI wrote: > Hello there, > > Recently I have tagged the following popular but Cabalized applications > in the Ports Collection with the "hs-" prefix: > > - darcs [1]: devel/darcs -> devel/hs-darcs > - pandoc [2]: textproc/pandoc -> textproc/hs-pandoc > - xmonad [3]: x11-wm/xmonad -> x11-wm/hs-xmonad, x11-wm/xmonad-contrib > -> x11-wm/hs-xmonad-contrib > - xmobar [4]: x11/xmobar -> x11/hs-xmobar > +1 > > I would like to ask everybody who is reading this message and using any > of these ports to comment on this change. +1 > > The reason was to do so that they are direct translation of their > hackages coming HackageDB [5], and as the port of the Haskell Platform > [6] is under way they would really serve the purpose for representing > the FreeBSD (binary and stable) version of the corresponding > applications. So there would be two (mutually exclusive) ways for > installing them. In case of xmonad: > > - The native way: > > # pkg_add -r haskell-platform +1 > # cabal install xmonad -1 > > Pros: Access updates and fixes immediately, not need for using the Ports > Collection, support for multiple versions for the same packages. > Cons: Need to build everything from sources, packages might be broken, > cannot remove installed applications. -1 > > > - The FreeBSD way: > > # pkg_add -r hs-xmonad +1 > > Pros: Reliable and stable dependencies, versions and updates, support > for binary-only installs, support for removing packages. +1 > Cons: Might not be the up-to-date, multiple versions for the same > package are not supported, not every package is ported. -1 > > > Please send "+1" or "-1" depending on whether you support or object this > change. Thank you! +1 > > > Cheers, +1 > :g > > > [1] http://www.darcs.net/ > [2] http://johnmacfarlane.net/pandoc/ > [3] http://www.xmonad.org/ > [4] http://code.haskell.org/~arossato/xmobar/ > [5] http://hackage.haskell.org/ > [6] http://hackage.haskell.org/platform/ +1 > > ___ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" -1 I believe this is one step in the right direction. Running total: 4 ;) -- jhell ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Users and groups kept after a port deinstallation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 23 May 2010 02:02, Matthew Seaman wrote: In Message-Id: <4bf8c4f8.9090...@infracaninophile.co.uk> On 23/05/2010 04:47:49, jhell wrote: But if a port can install a user there is no reason that it can not uninstall a user via pw(8) that is available from bsd.commands.mk after checking a recorded md5(1) sum that it could create upon installation for the output of pw usershow/groupshow UID/GID. The trick would be to teach the ports how to tell if a port was being deleted for good, when trashing the user would be appropriate, or if the port was being deleted as part of the process of upgrading it, when you'ld want to keep the user. That shouldn't actually be to hard. If a utility like the three main upgrade tools that are being used the most right now would export a variable for say "UPGRADING=yes" then the uninstall script could check against that to decide whether or not the port is being removed or upgraded and make the proper decision while alerting the admin to whats going on. Regards, - -- jhell -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJL+VbIAAoJEJBXh4mJ2FR+6d0H/RzxsitENOuEiG1j9l6cucod taGMfoitDYEFe7umLAyx/qfcLVkxRoVKNcStXGdQYFmhgbs0U3LgRfeCroKHcgaG GQkojvJvHMq0bGPXkGyM5Uqk2duN59dJbWyRqlfAxAt1b9SDl6LkHzfi4Bb0CoZ6 6/+izQ5Nl0nDDGGwzou2uCqhJ20YTm9N+XD5pdvDPPdC208wCc+1IPRNlZbx1stM B4viIveIBNJei1ooNqH3qwzO/fdOpJhd09eZNncOGLKPguHNNmqa/UH0ftXIBykU 3edE+gP+bvnf0kYeFBofYJDrG7H6grAyRUoObcD42sROLoD9Wk/RTO/MXZ8ekjA= =6JuP -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
