[SOLVED] Re: Problems with gitup - doesn't delete files / old ports.
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.
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
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"
Re: Has NO_MANCOMPRESS been silently depreciated?
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: Has NO_MANCOMPRESS been silently depreciated?
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"
Has NO_MANCOMPRESS been silently depreciated?
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: security/libgcrypt checksum mismatch
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: security/libgcrypt checksum mismatch
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
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: portversion and pkg_version have different opinions on current versions
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.209 < needs 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: portversion and pkg_version have different opinions on current versions
In message , 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: apr-gdbm-db42 upgrade conflicting with libtool
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
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
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
In message <4ad871310907291312s6f4e1c1dx7e91e5d61b5c4...@mail.gmail.com>, Glen Barber (glen.j.bar...@gmail.com) wrote: > On Wed, Jul 29, 2009 at 3:26 PM, Esa Karkkainen 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: this time it's vim/distfiles
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: Proposal: mechanism for local patches
In message <20081213105545.ga40...@titania.njm.me.uk>,
N.J. Mann (n...@njm.me.uk) wrote:
> 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.
I spoke too soon. :-(
I found I needed LOCALPATCHDIR and LOCALSCRIPTDIR in the environment
passed to the my script and so had to change my patch.
%
--- bsd.port.mk.orig
+++ 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
@@ -2887,6 +2899,14 @@
SCRIPTS_ENV+= BATCH=yes
.endif
+.if defined(LOCALPATCHDIR)
+SCRIPTS_ENV+= LOCALPATCHDIR=${LOCALPATCHDIR}
+.endif
+
+.if defined(LOCALSCRIPTDIR)
+SCRIPTS_ENV+= LOCALSCRIPTDIR=${LOCALSCRIPTDIR}
+.endif
+
.if ${PREFIX} == /usr
MANPREFIX?=/usr/share
.else
@@ -3604,6 +3624,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_APPLI
Re: Proposal: mechanism for local patches
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)
+
Re: Proposal: mechanism for local patches
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
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
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]"
