[SOLVED] Re: Problems with gitup - doesn't delete files / old ports.

[N.J. Mann]

Hi,


On Saturday, April 24, 2021 I wrote:
> 
> I have been using gitup for just over a week (and before that svn and
> before that cvsup) to update a local ports tree.  I have encountered
> some annoying failures.
[...]

With the help of John Mehr and the folks of freebsd-fs@ we got to the
bottom of the issue.  The problem only occurred when /usr/ports was NFS
mounted and a small change to gitup fixed this.  This fix is now in the
FreeBSD ports tree: commit 8ec1455f5301f5addb88de8458c9a56784ed57dd


Regards,
Nick.
-- 

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

Problems with gitup - doesn't delete files / old ports.

[N.J. Mann]

Hi,


I have been using gitup for just over a week (and before that svn and
before that cvsup) to update a local ports tree.  I have encountered
some annoying failures.  I run it from a simple home made script called
from cron at just after 10am local time everyday.  The script basically
does

  gitup ports >$HOME/var/log/gitup/ports.log 2>&1
  gitup_res=$?

and echo's the result code if non-zero.  I seem to be always getting 1.
Checking the logs gitup appears to be having issues with removing files
and even removing deleted ports.  This morning it choked on
textproc/bsdsort:

gitup: prune_tree: cannot remove /remote/ports/textproc/bsdsort/files: 
Directory not empty

And, indeed that directory isn't empty:

% ls -lRTtr /remote/ports/textproc/bsdsort   
total 4
-rw-r--r--  1 njm  wheel  915 15 Apr 14:45:35 2021 Makefile
-rw-r--r--  1 njm  wheel  133 15 Apr 14:45:35 2021 distinfo
drwxr-xr-x  2 njm  wheel4 15 Apr 14:45:35 2021 files
-rw-r--r--  1 njm  wheel  368 15 Apr 14:45:35 2021 pkg-descr

/remote/ports/textproc/bsdsort/files:
total 3
-rw-r--r--  1 njm  wheel  516 15 Apr 14:45:35 2021 patch-sort.c
-rw-r--r--  1 njm  wheel  221 15 Apr 14:45:35 2021 patch-vsort.h
% 

I checked the handy web interface 

https://cgit.freebsd.org/ports/commit/textproc?id=b54974bf33c767167f058350819fa7b9c3142f02

and found that this port was removed a few days ago - above URL.

Yesterday, I was trying to update firefox-esr when that failed building
www/node.  From the portmaster log:

  ===>  Patching for node-16.0.0
  ===>  Applying FreeBSD patches for node-16.0.0 from 
/remote/ports/www/node/files
  Ignoring previously applied (or reversed) patch.
  2 out of 2 hunks ignored--saving rejects to 
deps/v8/src/objects/js-list-format.cc.rej
  ===>  FAILED Applying FreeBSD patch-deps_v8_src_objects_js-list-format.cc
  ===> Cleanly applied FreeBSD patch(es)  
patch-deps_openssl_config_archs_linux-elf_no-asm_openssl-cl.gypi 
patch-deps_openssl_config_archs_linux-elf_no-asm_openssl.gypi 
patch-deps_openssl_openssl-cl__no__asm.gypi 
patch-deps_openssl_openssl__no__asm.gypi 
patch-deps_v8_src_base_platform_platform-freebsd.cc 
patch-deps_v8_src_codegen_ppc_constants-ppc.h 
patch-deps_v8_src_libsampler_sampler.cc
  ===> FAILED to apply cleanly FreeBSD patch(es)  
patch-deps_v8_src_objects_js-list-format.cc
  *** Error code 1

  Stop.
  make[1]: stopped in /remote/ports/www/node
  *** Error code 1

  Stop.
  make: stopped in /remote/ports/www/node

Again checking the friendly web interface I found

https://cgit.freebsd.org/ports/commit/www/node?id=bc3d0937d0d2cc4a2e80334f5391a2d87458943e

that said patch file had been removed four days ago.

So, for me at least, gitup is not reliably removing deleted files and
even deleted ports.

Suggestions, recommendations, patches all welcome.


Regards,
Nick.
-- 

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

Re: Procmail Vulnerabilities check

[N.J. Mann]

Hi,

On Friday, December 08, 2017 17:12:45 +0100 Jos Chrispijn 
 wrote:
> A little concernedthat I got no response to this.
> Is Procmail dead for most of you guys(ducking)

See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223777
specifically the patch in "Comment 2".  I have been using this
patch for a few days without problems.

Sadly the vulnerability check still fails.


Cheers,
   Nick.
-- 

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

Has NO_MANCOMPRESS been silently depreciated?

[N.J. Mann]

Hi,


For many years I have set NO_MANCOMPRESS (and before that NOMANCOMPRESS)
in /etc/make.conf on all my machines.  In the last few weeks I have
noticed that this setting is being ignored by port updates.  Has this
setting been silently depreciated?


Cheers,
   Nick.
-- 

___
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: Has NO_MANCOMPRESS been silently depreciated?

[N.J. Mann]

In message 52f388ee.30...@marino.st,
John Marino (freebsd.cont...@marino.st) wrote:
 On 2/6/2014 13:54, N.J. Mann wrote:
  For many years I have set NO_MANCOMPRESS (and before that NOMANCOMPRESS)
  in /etc/make.conf on all my machines.  In the last few weeks I have
  noticed that this setting is being ignored by port updates.  Has this
  setting been silently depreciated?
  
 
 You have been setting it in make.conf?

Yes.

I don't believe it was ever a user variable.

It was and still is for the base system - this machine was updated to
8-STABLE r261161 ten days ago and all base manual pages are
uncompressed.

 Anyway, yes, it doesn't do anything on staged ports and it was silently
 removed because it was for port maintainers only, not users.  (subject

It _is_ a user, well administrator really, setting.  Please unremove it.


Cheers,
   Nick.
-- 

___
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: Has NO_MANCOMPRESS been silently depreciated?

[N.J. Mann]

In message 52f39326.2040...@marino.st,
John Marino (freebsd.cont...@marino.st) wrote:
 On 2/6/2014 14:31, N.J. Mann wrote:
 
 You are asking for an infrastructure
 change.

No I am not.  I _am_ asking that something which used to be supported
(and was documented), that has silently been removed, be reinstated.


Cheers,
Nick.
-- 

___
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: security/libgcrypt checksum mismatch

[N.J. Mann]

Hi,


In message 201305111044.r4baimuh059...@mech-cluster241.men.bris.ac.uk,
Anton Shterenlikht (me...@bris.ac.uk) wrote:
 This is on amd64/clang r249781, with ports at 317861:
 
 # pkg version -vX libgcry
 libgcrypt-1.5.0_1 needs updating (port has 1.5.2)
 
 ===  License GPLv2 LGPL21 accepted by the user
 ===   libgcrypt-1.5.2 depends on file: /usr/local/sbin/pkg - found
 = libgcrypt-1.5.2.tar.bz2 doesn't seem to exist in /usr/ports/distfiles//.
 = Attempting to fetch 
 http://gnupg.org.favoritelinks.net/libgcrypt/libgcrypt-1.5.2.tar.bz2
 fetch: http://gnupg.org.favoritelinks.net/libgcrypt/libgcrypt-1.5.2.tar.bz2: 
 size unknown
 fetch: http://gnupg.org.favoritelinks.net/libgcrypt/libgcrypt-1.5.2.tar.bz2: 
 size of remote file is not known
 libgcrypt-1.5.2.tar.bz2   1082  B 2277 kBps 00m00s
 === Fetching all distfiles required by libgcrypt-1.5.2 for building
 ===  License GPLv2 LGPL21 accepted by the user
 ===   libgcrypt-1.5.2 depends on file: /usr/local/sbin/pkg - found
 === Fetching all distfiles required by libgcrypt-1.5.2 for building
 = SHA256 Checksum mismatch for libgcrypt-1.5.2.tar.bz2.
 ===  Giving up on fetching files: libgcrypt-1.5.2.tar.bz2 
 Make sure the Makefile and distinfo file 
 (/usr/ports/security/libgcrypt/distinfo)
 are up to date.  If you are absolutely sure you want to override this
 check, type make NO_CHECKSUM=yes [other args].
 *** [checksum] Error code 1
 
 Stop in /usr/ports/security/libgcrypt.
 *** [checksum] Error code 1

I had something similar to this yesterday.  Can you do the following and
post the results here please?

# file /usr/ports/distfiles/libgcrypt-1.5.2*

In my case HTML files had been fetched!


Cheers,
   Nick.
-- 

___
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: security/libgcrypt checksum mismatch

[N.J. Mann]

In message 518e2913.5040...@hayers.org,
Gary J. Hayers (g...@hayers.org) wrote:
 I've been getting this with varying ports for some time now, sometimes 
 I've had to manually fetch the distfiles.

I am sorry to hear this, but glad I am not the only one.  :-)

The files I have had to manually fetch are:

libgcrypt-1.5.2.tar.bz2
libassuan-2.0.3.tar.bz2
libassuan-2.0.3.tar.bz2.sig
libksba-1.3.0.tar.bz2
libksba-1.3.0.tar.bz2.sig
gnupg-2.0.19.tar.bz2
gnupg-2.0.19.tar.bz2.sig
gnupg-2.0.20.tar.bz2
gnupg-2.0.20.tar.bz2.sig

Do you have a list of affected files/ports?


Cheers,
   Nick.
-- 

___
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: security/libgcrypt checksum mismatch

[N.J. Mann]

In message 2013055228.gc94...@titania.njm.me.uk,
N.J. Mann (n...@njm.me.uk) wrote:
 In message 518e2913.5040...@hayers.org,
   Gary J. Hayers (g...@hayers.org) wrote:
  I've been getting this with varying ports for some time now, sometimes 
  I've had to manually fetch the distfiles.
 
 I am sorry to hear this, but glad I am not the only one.  :-)
 
 The files I have had to manually fetch are:
 
 libgcrypt-1.5.2.tar.bz2
 libassuan-2.0.3.tar.bz2
 libassuan-2.0.3.tar.bz2.sig
 libksba-1.3.0.tar.bz2
 libksba-1.3.0.tar.bz2.sig
 gnupg-2.0.19.tar.bz2
 gnupg-2.0.19.tar.bz2.sig
 gnupg-2.0.20.tar.bz2
 gnupg-2.0.20.tar.bz2.sig

I now know why I get HTML files when trying to fetch these distfiles.
The common factor is that they all use HTTP rather FTP for fetching.
For HTTP fetches my ISP (British Telecom, aka BT) will display a
helpful 'sorry no one at home' web page when the fetch fails, and that
is what I end up with in the distfile.  Thankfully, this 'nice' feature
can be disabled.  Once disabled 'make fetch' does its job of trying the
next site after the failure and the proper file(s) are downloaded.

I do not know whether other ISPs do something similar, does anyone?  I
wonder whether FTP sites should be listed before HTTP ones?


Cheers,
   Nick.
-- 

___
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: portversion and pkg_version have different opinions on current versions

[N.J. Mann]

In message b787d58e-9157-48e7-adf3-e8d54f8af...@exscape.org,
Thomas Backman (seren...@exscape.org) wrote:
 First off: not subscribed to this list, please make sure to Cc me or I  
 won't see your answers! :)
 
 Oh, and I use portsnap, in crontab:
 0 19 * * *  portsnap -I cron update
 
 So, long story short:
 
 [r...@chaos ~]# pkgdb -aF
 ---  Checking the package registry database
 [r...@chaos ~]# portversion -l ''
 dnsmasq 
 ezm3
 libtool 
 python26
 [r...@chaos ~]# pkg_version | awk '$2 !~ /=/'
 [r...@chaos ~]# portupgrade -a
 [r...@chaos ~]#

I do not have portversion on my system so I assume it is part of
portupgrade or some other tool.  I find pkg_version works fine for
letting me know what needs updating after doing a CVSup.  BTW you do not
need to use awk in the above, e.g.

pkg_version -L =

will show only those ports which are not up-to-date, RTFM for details.
:-)

Some years ago I tried using portupgrade, but had all sorts of problems
with its database getting corrupted.  In desparation I tried portmaster
and have been a very happy since.  (Thanks Doug!).

[...]
 I don't care overly much about having the bleeding-edge version, but  
 I'd rather not, as I currently have, use packages with known  
 vulnerabilities (I do know about portaudit, though, and will give that  
 a check). For instance, I just noticed yesterday that I needed to  
 upgrade apr, among about 6-7 other packages; the apr vulnerability had  
 been known for a while before I updated.

I think portaudit is definitely worth having installed.  You can always
ignore its warnings if you want to.

 
Cheers,
   Nick.
-- 

___
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: portversion and pkg_version have different opinions on current versions

[N.J. Mann]

In message 6b5b7698-ccd8-48ff-a5fb-0349d4cc1...@exscape.org,
Thomas Backman (seren...@exscape.org) wrote:
 
 On Aug 15, 2009, at 20:31, Miroslav Lachman wrote:
  Thomas Backman wrote:
  [...]
  [r...@chaos ~]# pkgdb -aF
  ---  Checking the package registry database
  [r...@chaos ~]# portversion -l ''
  dnsmasq 
  ezm3
  libtool 
  python26
  [r...@chaos ~]# pkg_version | awk '$2 !~ /=/'
  [r...@chaos ~]# portupgrade -a
  [r...@chaos ~]#
  [...]
 
  As was mentioned, you can use pkg_version -L =, or you can compare  
  it with INDEX.db instead of ports tree: pkg_version -IL =. This is  
  significantly faster.
 
  pkg_version -L =
  Usr: 7.286s  Krnl: 3.984s  Totl: 0:31.77s
 
  pkg_version -IL =
  Usr: 0.195s  Krnl: 0.015s  Totl: 0:00.21s
 
  And if you want to know the version of newer (available) port, you  
  can use pkg_version -vIL =
  It gives you something like this:
 
  png-1.2.35  needs updating (index has 1.2.38)
  postfix-2.5.6,1 needs updating (index has 2.6.3,1)
  vim-lite-7.2.209needs updating (index has 7.2.239)
 
  Miroslav Lachman
 Thanks, guys!
 However, a new issue appeared... Kind of. I know I read something  
 about portsnap and INDEX on the -current list recently, so I'm  
 guessing this is related? Maybe not, though (see later in the mail).
[...]

I am not familiar with portsnap - I use CVS (and SVN) because I like to
have ports, src, doc and www locally, just in case...  Be that as it
may, you can always do a

make index

to rebuild the INDEX-* file.


Cheers,
   Nick.
-- 

___
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: apr-gdbm-db42 upgrade conflicting with libtool

[N.J. Mann]

In message 200908120851.14642.mel.flynn+fbsd.po...@mailing.thruhere.net,
Mel Flynn (mel.flynn+fbsd.po...@mailing.thruhere.net) wrote:
 
 Just got bitten by this too, amd64, 6.x in a jail, clean environment. I traced
 it to building as normal user, root works. The tell tale is this:
 buildconf: Using libtool.m4 at /usr/local/share/aclocal/libtool.m4.
 ./buildconf: cannot create build/libtool.m4: Permission denied
 
 As a result, configure works with the provided libtool.m4 and things go
 downhill from there.
 The provided libtool.m4 is installed by libtoolize with 444 permissions. Thus:
 cat $ltfile | sed -e 's/LIBTOOL=\(.*\)top_build/LIBTOOL=\1apr_build/'  \
   build/libtool.m4
 
 fails for a normal user. The patch below sig fixes the issue.

Your patch fixes it for me.

Many thanks.


Cheers,
   Nick.
-- 

___
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: apr-gdbm-db42 upgrade conflicting with libtool

[N.J. Mann]

In message 20090803155055.ga31...@titania.njm.me.uk,
N.J. Mann (n...@njm.me.uk) wrote:
 In message 20090803125519.ga60...@twisted.net,
   Troy (t...@twisted.net) wrote:
  I was trying to upgrade apr-gdbm-db42-1.3.6.1.3.8 to 1.3.7.1.3.8 and ran
  into the following error.  My libtool was just upgraded to libtool-2.2.6a
  so there may be a conflict there.  Anyone have ideas?
  
  
  checking minix/config.h usability... no
  checking minix/config.h presence... no
  checking for minix/config.h... no
  checking whether it is safe to define __EXTENSIONS__... yes
  checking for library containing strerror... none required
  checking whether system uses EBCDIC... no
  performing libtool configuration...
  ./configure: 9753: Syntax error: word unexpected (expecting ))
  *** Error code 2
  
  Stop in /usr/ports/devel/apr.
  *** Error code 1
  
  Stop in /usr/ports/devel/apr.
 
 I am also having problems updating devel/apr.  In my case it gets past
 the configure stage and fails during the compile stage:
 
 %
 
 ===  Building for apr-gdbm-db43-1.3.7.1.3.8
 cd /usr/ports.workdir/usr/ports/devel/apr/work/apr-1.3.7; /usr/bin/env 
 TMPDIR=/home/njm/tmp TMPDIR=/home/njm/tmp SHELL=/bin/sh NO_LINT=YES 
 ACLOCAL=/usr/local/bin/aclocal-1.9 AUTOMAKE=/usr/local/bin/automake-1.9 
 AUTOMAKE_VERSION=19 AUTOCONF=/usr/local/bin/autoconf-2.62 
 AUTOHEADER=/usr/local/bin/autoheader-2.62 
 AUTOIFNAMES=/usr/local/bin/ifnames-2.62 AUTOM4TE=/usr/local/bin/autom4te-2.62 
 AUTORECONF=/usr/local/bin/autoreconf-2.62 
 AUTOSCAN=/usr/local/bin/autoscan-2.62 
 AUTOUPDATE=/usr/local/bin/autoupdate-2.62 AUTOCONF_VERSION=262 
 LIBTOOL=/usr/local/bin/libtool LIBTOOLIZE=/usr/local/bin/libtoolize 
 LIBTOOL_M4=/usr/local/share/aclocal/libtool.m4 PREFIX=/usr/local  
 LOCALBASE=/usr/local X11BASE=/usr/local  MOTIFLIB=-L/usr/local/lib -lXm 
 -lXp LIBDIR=/usr/lib  CC=cc CFLAGS=-O2 -fno-strict-aliasing -pipe 
 CXX=c++ CXXFLAGS=-O2 -fno-strict-aliasing -pipe  MANPREFIX=/usr/local 
 BSD_INSTALL_PROGRAM=install  -s  -m 555  BSD_INSTALL_SCRIPT=install   -m 
 555  BSD_INSTALL_DATA=install   -m 444  BSD_INSTALL_
 MAN=install   -m 444 /usr/bin/make
 /bin/sh /libtool --silent --mode=compile cc   -O2 -fno-strict-aliasing -pipe 
 -DHAVE_CONFIG_H-I./include 
 -I/usr/ports.workdir/usr/ports/devel/apr/work/apr-1.3.7/include/arch/unix 
 -I./include/arch/unix 
 -I/usr/ports.workdir/usr/ports/devel/apr/work/apr-1.3.7/include/arch/unix 
 -I/usr/ports.workdir/usr/ports/devel/apr/work/apr-1.3.7/include  -o 
 passwd/apr_getpass.lo -c passwd/apr_getpass.c  touch passwd/apr_getpass.lo

  ^
  |
This is the why it fails.  In the relevant makefile this is actually:

./build/apr_rules.mk:38:LIBTOOL=$(SHELL) $(top_builddir)/libtool

but  top_buildir  is not defined anywhere in the makefiles.  If I set it
then everything works.  If I change the line above to use  top_blddir
instead of  top_builddir  it works.

So, why isn't it defined?  I looked through the config files - I know
nothing about autoconf, automake, c., and found:

./config.log:17410:LIBTOOL='$(SHELL) $(top_builddir)/libtool'
./config.log:17611:top_builddir='/usr/ports.workdir/usr/ports/devel/apr/work/apr-1.3.7'

but I do not know whether the syntax of the second line is correct (the
path is for my setup).

Anyway, I tried compiling after making the above change and it worked
until it changed directory into  apr/work/apr-util-1.3.8  whereapon the
same problem manifested.  This time though I had to change the line in
build/rules.mk  to be  LIBTOOL=$(SHELL) $(apr_builddir)/libtool  and
that did the trick: I now have an updated  devel/apr.

I really would like to get to the bottom of why this is failing for me,
even if it is not failing for anyone else.  Any and all suggetions
accepted.


Cheers,
   Nick.
-- 

___
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: apr-gdbm-db42 upgrade conflicting with libtool

[N.J. Mann]

In message 20090803125519.ga60...@twisted.net,
Troy (t...@twisted.net) wrote:
 I was trying to upgrade apr-gdbm-db42-1.3.6.1.3.8 to 1.3.7.1.3.8 and ran
 into the following error.  My libtool was just upgraded to libtool-2.2.6a
 so there may be a conflict there.  Anyone have ideas?
 
 
 checking minix/config.h usability... no
 checking minix/config.h presence... no
 checking for minix/config.h... no
 checking whether it is safe to define __EXTENSIONS__... yes
 checking for library containing strerror... none required
 checking whether system uses EBCDIC... no
 performing libtool configuration...
 ./configure: 9753: Syntax error: word unexpected (expecting ))
 *** Error code 2
 
 Stop in /usr/ports/devel/apr.
 *** Error code 1
 
 Stop in /usr/ports/devel/apr.

I am also having problems updating devel/apr.  In my case it gets past
the configure stage and fails during the compile stage:

%

===  Building for apr-gdbm-db43-1.3.7.1.3.8
cd /usr/ports.workdir/usr/ports/devel/apr/work/apr-1.3.7; /usr/bin/env 
TMPDIR=/home/njm/tmp TMPDIR=/home/njm/tmp SHELL=/bin/sh NO_LINT=YES 
ACLOCAL=/usr/local/bin/aclocal-1.9 AUTOMAKE=/usr/local/bin/automake-1.9 
AUTOMAKE_VERSION=19 AUTOCONF=/usr/local/bin/autoconf-2.62 
AUTOHEADER=/usr/local/bin/autoheader-2.62 
AUTOIFNAMES=/usr/local/bin/ifnames-2.62 AUTOM4TE=/usr/local/bin/autom4te-2.62 
AUTORECONF=/usr/local/bin/autoreconf-2.62 AUTOSCAN=/usr/local/bin/autoscan-2.62 
AUTOUPDATE=/usr/local/bin/autoupdate-2.62 AUTOCONF_VERSION=262 
LIBTOOL=/usr/local/bin/libtool LIBTOOLIZE=/usr/local/bin/libtoolize 
LIBTOOL_M4=/usr/local/share/aclocal/libtool.m4 PREFIX=/usr/local  
LOCALBASE=/usr/local X11BASE=/usr/local  MOTIFLIB=-L/usr/local/lib -lXm -lXp 
LIBDIR=/usr/lib  CC=cc CFLAGS=-O2 -fno-strict-aliasing -pipe CXX=c++ 
CXXFLAGS=-O2 -fno-strict-aliasing -pipe  MANPREFIX=/usr/local 
BSD_INSTALL_PROGRAM=install  -s  -m 555  BSD_INSTALL_SCRIPT=install   -m 
555  BSD_INSTALL_DATA=install   -m 444  BSD_INSTALL_MAN=install   -m 444 
/usr/bin/make
/bin/sh /libtool --silent --mode=compile cc   -O2 -fno-strict-aliasing -pipe 
-DHAVE_CONFIG_H-I./include 
-I/usr/ports.workdir/usr/ports/devel/apr/work/apr-1.3.7/include/arch/unix 
-I./include/arch/unix 
-I/usr/ports.workdir/usr/ports/devel/apr/work/apr-1.3.7/include/arch/unix 
-I/usr/ports.workdir/usr/ports/devel/apr/work/apr-1.3.7/include  -o 
passwd/apr_getpass.lo -c passwd/apr_getpass.c  touch passwd/apr_getpass.lo
/libtool: Can't open /libtool: No such file or directory
*** Error code 2

Stop in /usr/ports.workdir/usr/ports/devel/apr/work/apr-1.3.7.
*** Error code 1

Stop in /usr/ports.workdir/usr/ports/devel/apr/work/apr-1.3.7.
*** Error code 1

Stop in /usr/ports/devel/apr.
*** Error code 1

Stop in /usr/ports/devel/apr.

%

I have not had time to try to figure out what is going wrong, but I may
have time tomorrow.


Cheers,
   Nick.
-- 

___
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: this time it's vim/distfiles

[N.J. Mann]

In message 200907291305.n6td5kst010...@mp.cs.niu.edu,
Scott Bennett (benn...@cs.niu.edu) wrote:
  When portmaster tries to rebuild vim-lite, it tries to verify the
 checksums of 239 (?) patches.  (I guess I should take that as a warning.)
 Unfortunately, one of them apparently doesn't check out properly.  Here's
 an excerpt of the portmaster output.
 
 = MD5 Checksum OK for vim/7.2.040
 = SHA256 Checksum OK for vim/7.2.040.
 = No MD5 checksum recorded for vim/7.2.041^.
 = No SHA256 checksum recorded for vim/7.2.041^.
 = No suitable checksum found for vim/7.2.041^.
 = MD5 Checksum OK for vim/7.2.042.
 = SHA256 Checksum OK for vim/7.2.042.
  .
  .
  .
 = MD5 Checksum OK for vim/7.2.239.
 = SHA256 Checksum OK for vim/7.2.239.
 *** Error code 1
 
 Stop in /usr/ports/editors/vim-lite.
 
 === make failed for editors/vim-lite
 === Aborting update
 
 === Update for vim-lite-7.2.209 failed
 === Aborting update
 
  I looked in distfiles and found that the line in question apparently
 had an extraneous character that displays in less and vi as a percent sign.
 
 DISTFILE:vim/7.2.040:SIZE=1836:SHA256=ad320d45c2541a767b351fdb8720c349c468acec8cf54dcfced0a6d1e58e5d8e:MD5=4c493255ae227498016f30a0002ec1cc
 DISTFILE:vim/7.2.041%:SIZE=22405:SHA256=2f48e173df3d306edd982f8a3d5a15c65ba19694ca32bdbdaa51f8bcc48a3d06:MD5=107ba5dccb1df727601aead37abf8cd3
 DISTFILE:vim/7.2.042:SIZE=4987:SHA256=d5fa884a7c5ee77b60fe512ceccaac640c0dfc00bd435211f4e4597ae3bee2cd:MD5=99baedef8a9c908774b7ed74deacf184

NB: you should be looking in editors/vim since editors/vim-lite is a
slave port.

The Makefile and distinfo files have different names for the patch - the
maintainer appears to have decided to rename the patch file earlier
today and only updated Makefile accordingly.  The old name was 7.2.041%
and the new is to 7.2.041^.  Try changing distinfo accordingly.


Cheers,
   Nick.
-- 

___
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: this time it's vim/distfiles

[N.J. Mann]

In message 4ad871310907291312s6f4e1c1dx7e91e5d61b5c4...@mail.gmail.com,
Glen Barber (glen.j.bar...@gmail.com) wrote:
 On Wed, Jul 29, 2009 at 3:26 PM, Esa Karkkainene...@iki.fi wrote:
  On Wed, Jul 29, 2009 at 02:59:56PM +0100, N.J. Mann wrote:
  Try changing distinfo accordingly.
 
  You can use your favourite editor or run the following commands as root
 
  # cd /usr/ports/editors/vim
  # sed -I .orig -e 's/7\.2\.041%/7.2.041^/' distinfo
 
 
 That shouldn't fix the problem, because according to the OP's error:
 
 = No MD5 checksum recorded for vim/7.2.041^.
 = No SHA256 checksum recorded for vim/7.2.041^.
 = No suitable checksum found for vim/7.2.041^.
 
 Meaning, there is no checksum for the file with '^' in place of '%'.

I think you have missed the point.  The Makefile has been updated to
include the renaming of the patch file from 7.2.041% to 7.2.41^, whereas
the distinfo file _has not_.  So, the distinfo has no checksums for
7.2.041^.  Instead it has them for 7.2.041%.

So I think Esa's idea is correct.

1 minute later
Wesley Shields (wxs@) has just committed a fix to the distfile, so those
affected should re-sync their port trees.


Cheers,
   Nick.

-- 

___
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: Proposal: mechanism for local patches

[N.J. Mann]

In message 20081212102516.gb7...@hades.panopticon,
Dmitry Marakasov (amd...@amdmi3.ru) wrote:
 * N.J. Mann (n...@njm.me.uk) wrote:
 
   I suppose that check was done to help to detect patching failures, so it
   may be removed.
  
  I've just been trying out your patch and I think from an organisational
  point of view it is very good.  What I mean by this is that with the
  patch I am now able to keep my local patches completely separate from
  the official, FreeBSD patches.  No more backing up the whole of
  /usr/ports just in case I have a private patch in there somewhere.  Now
  I just need to backup /usr/ports.localpatchdir (which is what I called
  the directory LOCAPATCHDIR points to).
 
 Nice to hear that it's useful :)

I found that it was not quite enough.  For one port I am developing
local patches for I found I either needed to modify the ports' FreeBSD
Makefile or add a post-extract script.  Since I no longer want to have
locally modified files in /usr/ports I needed to have a local
post-extract script.  So, I have modified your change to support both
patch files and script files.

%

--- bsd.port.mk~
+++ bsd.port.mk
@@ -591,6 +591,13 @@
 #Default: ${MASTERDIR}/files
 # PKGDIR   - A directory containing any package creation files.
 #Default: ${MASTERDIR}
+# LOCALDIRPREFIX
+#  - Root of local patches and scripts tree.
+# LOCALPATCHDIR- An optional directory for storing local patches.
+#Default: 
${LOCALDIRPREFIX}/${CATEGORY}/${PORT}/files
+# LOCALSCRIPTDIR
+#  - An optional directory for storing local 
scripts.
+#Default: 
${LOCALDIRPREFIX}/${CATEGORY}/${PORT}/scripts
 #
 # Variables that serve as convenient aliases for your *-install targets.
 # Use these like: ${INSTALL_PROGRAM} ${WRKSRC}/prog ${PREFIX}/bin.
@@ -1371,6 +1378,11 @@
 SCRIPTDIR?=${MASTERDIR}/scripts
 PKGDIR?=   ${MASTERDIR}
 
+.if defined(LOCALDIRPREFIX)
+LOCALPATCHDIR?=
${LOCALDIRPREFIX}/${.CURDIR:C/^.*\/([^\/]+\/[^\/]+)$/\\1/}/files
+LOCALSCRIPTDIR?=   
${LOCALDIRPREFIX}/${.CURDIR:C/^.*\/([^\/]+\/[^\/]+)$/\\1/}/scripts
+.endif
+
 .if defined(USE_IMAKE)  !defined(USE_X_PREFIX)
 USE_X_PREFIX=  yes
 .endif
@@ -3604,6 +3616,35 @@
done; \
fi; \
fi
+.if defined(LOCALPATCHDIR)
+   @if [ -d ${LOCALPATCHDIR} ]; then \
+   if [ `${ECHO_CMD} ${LOCALPATCHDIR}/patch-*` != 
${LOCALPATCHDIR}/patch-* ]; then \
+   ${ECHO_MSG} ===  Applying local patches for 
${PKGNAME} ; \
+   PATCHES_APPLIED= ; \
+   for i in ${LOCALPATCHDIR}/patch-*; do \
+   case $$i in \
+   *.orig|*.rej|*~|*,v) \
+   ${ECHO_MSG} ===   Ignoring 
patchfile $$i ; \
+   ;; \
+   *) \
+   if [ ${PATCH_DEBUG_TMP} = yes 
]; then \
+   ${ECHO_MSG} ===   
Applying local patch $$i ; \
+   fi; \
+   if ${PATCH} ${PATCH_ARGS}  $$i 
; then \
+   
PATCHES_APPLIED=$$PATCHES_APPLIED $$i ; \
+   else \
+   ${ECHO_MSG} 
`${ECHO_CMD} = Local patch $$i failed to apply cleanly. | ${SED} 
s|${LOCALPATCHDIR}/||` ; \
+   if [ 
x$$PATCHES_APPLIED != x ]; then \
+   ${ECHO_MSG} 
`${ECHO_CMD} = Local patch(es) $$PATCHES_APPLIED applied cleanly. | ${SED} 
s|${LOCALPATCHDIR}/||g` ; \
+   fi; \
+   ${FALSE} ; \
+   fi; \
+   ;; \
+   esac; \
+   done; \
+   fi; \
+   fi
+.endif
 .endif
 
 .if !target(run-autotools)
@@ -4248,6 +4289,12 @@
cd ${.CURDIR}  ${SETENV} ${SCRIPTS_ENV} ${SH} \
${SCRIPTDIR}/${.TARGET:S/-script$//}; \
fi
+.if defined(LOCALSCRIPTDIR)
+   @if [ -f ${LOCALSCRIPTDIR}/${.TARGET:S/-script$//} ]; then \
+   cd ${.CURDIR}  ${SETENV} ${SCRIPTS_ENV} ${SH} \
+   ${LOCALSCRIPTDIR}/${.TARGET:S/-script$//}; \
+   fi
+.endif
 .endif
 
 .endfor

%
 
  However, please consider putting back in the test for *.orig and *~
  files.  That way one can

Re: Proposal: mechanism for local patches

[N.J. Mann]

In message 20081203131234.gd70...@hades.panopticon,
Dmitry Marakasov (amd...@amdmi3.ru) wrote:
 * G. Paul Ziemba (pz-freebsd-po...@ziemba.us) wrote:
[...]
 
  2. I'm not sure we need the test for *.orig|*.rej|*~|*,v, but it
 wouldn't hurt. Maybe it helps admins who are actively developing
 local patches. I see that it's in the existing do-patch code above.
 
 I suppose that check was done to help to detect patching failures, so it
 may be removed.

I've just been trying out your patch and I think from an organisational
point of view it is very good.  What I mean by this is that with the
patch I am now able to keep my local patches completely separate from
the official, FreeBSD patches.  No more backing up the whole of
/usr/ports just in case I have a private patch in there somewhere.  Now
I just need to backup /usr/ports.localpatchdir (which is what I called
the directory LOCAPATCHDIR points to).

However, please consider putting back in the test for *.orig and *~
files.  That way one can be actively be hacking on a patch without
having to keep deleting editor backup files, which you may not wish to
delete anyway, before attempting another build.  In my case I see no
need to skip *.rej and *,v files, but others may have a need for them.

I hope some form of your patch gets into the tree once 7.1 ships.


Cheers,
   Nick.
-- 

___
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: upgrade failed for security/sudo

[N.J. Mann]

In message [EMAIL PROTECTED],
Doug Barton ([EMAIL PROTECTED]) wrote:
 N.J. Mann wrote:
[...]
  All went well until the install phase,
  when portmaster could no longer find sudo.  It looks like portmaster got
  into a chicken and egg situation: it needed to uninstall sudo in order
  to complete the upgrade, but it needed to run sudo to perform the actual
  install.  Oh, dear.
 
 I thought it went without saying that this couldn't possibly work, but
 I'll update the man page in this regard.

I didn't really think about at the time, it was a bit early :-)  But,
once it failed it did make me think about what I had done.  I am happy
if it is documented as a caveat.  The main reason I posted to the list
was so that others who had had the same failure would know that it was
possible to recover from it easily.

I still think portmaster is a great tool!

Thanks Doug.


Cheers,
   Nick.
-- 

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]

portmaster: upgrade failed for security/sudo

[N.J. Mann]

Good morning,


I am using portmaster v2.0 and very good it is to, except...

This morning among the ports that needed updating following my
over-night CVSup was security/sudo (1.6.9.6 - 1.6.9.12).  I am using
portmaster's new feature SU_CMD.  I am also using the new HIDE_BUILD
feature which I really like!  All went well until the install phase,
when portmaster could no longer find sudo.  It looks like portmaster got
into a chicken and egg situation: it needed to uninstall sudo in order
to complete the upgrade, but it needed to run sudo to perform the actual
install.  Oh, dear.

The solution to my failed upgrade was to cd into security/sudo and do a
make install which installed the new sudo fine.  I was then able to
re-run portmaster to upgrade the other ports which were out of date.

More details:

Tail of portmaster output during upgrade attempt:

=== Installation of sudo-1.6.9.12 (security/sudo) failed
=== Aborting update

=== Update for sudo-1.6.9.6 failed
=== Aborting update

Tail of sudo upgrade log:

cc -shared  .libs/sudo_noexec.o   -Wl,-soname -Wl,sudo_noexec.so -o 
.libs/sudo_noexec.so
creating sudo_noexec.la
(cd .libs  rm -f sudo_noexec.la  ln -s ../sudo_noexec.la sudo_noexec.la)
eval: /usr/local/bin/sudo: not found


Cheers,
   Nick.
-- 

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]