Re: [SOLVED] libpkg, sqlite and database problems prevent building any packages
On 07/08/2013 02:00, Thomas Mueller wrote: At first, with sqlite3 not listed as a dependency of pkg, I wouldn't have realized what needed fixing. That's deliberate. If pkg(8) had to install other packages as dependencies of itself, it would make bootstrapping pkg on a new system a bit difficult. So sqlite is bundled into the pkg source tree, along with a few other external bits. That pkg(8) uses sqlite is not exactly secret -- there's a whole man page for pkg-shell(8) which talks about using the sqlite3 console, and sqlite is clearly mentioned in pkg(8) and other man pages. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey signature.asc Description: OpenPGP digital signature
[QAT] r324331: 8x leftovers
update audacious + audacious-plugins to 3.4 - Build ID: 20130807063600-5725 Job owner: oli...@freebsd.org Buildtime: 30 minutes Enddate: Wed, 07 Aug 2013 07:06:23 GMT Revision: r324331 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=324331 - Port:multimedia/audacious 3.4 Buildgroup: 9.1-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~oli...@freebsd.org/20130807063600-5725-168440/audacious-3.4.log Buildgroup: 9.1-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~oli...@freebsd.org/20130807063600-5725-168441/audacious-3.4.log Buildgroup: 8.4-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~oli...@freebsd.org/20130807063600-5725-168442/audacious-3.4.log Buildgroup: 8.4-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~oli...@freebsd.org/20130807063600-5725-168443/audacious-3.4.log - Port:multimedia/audacious-plugins 3.4 Buildgroup: 9.1-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~oli...@freebsd.org/20130807063600-5725-168444/audacious-plugins-3.4.log Buildgroup: 9.1-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~oli...@freebsd.org/20130807063600-5725-168445/audacious-plugins-3.4.log Buildgroup: 8.4-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~oli...@freebsd.org/20130807063600-5725-168446/audacious-plugins-3.4.log Buildgroup: 8.4-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~oli...@freebsd.org/20130807063600-5725-168447/audacious-plugins-3.4.log -- Buildarchive URL: https://qat.redports.org/buildarchive/20130807063600-5725 redports https://qat.redports.org/ ___ 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
FreeBSD unmaintained ports which are currently marked broken
As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 7.x/8.x/9.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: audio/mp3towav-bundle broken because: fails to build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=mp3towav-bundle portname: biology/dotter broken because: checksum mismatch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=biologyportname=dotter portname: chinese/big5con broken because: fails to build with new utmpx build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=chineseportname=big5con portname: chinese/bitchx broken because: patch reject build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=chineseportname=bitchx portname: chinese/hztty broken because: fails to build with new utmpx build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=chineseportname=hztty portname: converters/p5-Unicode-Lite broken because: Overwrites bin/map from converters/p5-Unicode-Map build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=convertersportname=p5-Unicode-Lite portname: databases/grass broken because: Does not build build errors: http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.9.20130722060933.pointyhat/grass-6.4.2_5,2.log (Jul 23 05:43:45 UTC 2013) http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.8.20130713170952.pointyhat/grass-6.4.2_5,2.log (Jul 14 21:58:49 UTC 2013) overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=grass portname: databases/msql broken because: Broken on FreeBSD 9+ build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=msql portname: databases/ruby-interbase broken because: does not build with ruby 1.9 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=ruby-interbase portname: deskutils/libopensync-plugin-python-devel broken because: fails to build with recent libopensync build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=deskutilsportname=libopensync-plugin-python-devel portname: deskutils/libopensync-plugin-vformat-devel broken because: fails to build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=deskutilsportname=libopensync-plugin-vformat-devel portname: deskutils/simpleagenda broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=deskutilsportname=simpleagenda portname: devel/dsss broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=dsss portname: devel/libYGP broken because: Does not build with recent boost build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=libYGP portname: devel/lua50-dfui broken because: Does not build build errors:
FreeBSD unmaintained ports which are currently scheduled for deletion
As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically schedule removal of ports that have been judged to have outlived their usefulness. Often, this is due to a better alternative having become available and/or the cessation of development on the existing port. In some cases, ports are marked for removal because they fail to build and install correctly from their sources, or otherwise fail in operation. The ports, and the reason and date that they have been scheduled for removal, are listed below. If no one has stepped forward before that time to propose a way to fix the problems (such as via a PR), the ports will be deleted. portname: databases/ruby-interbase description:Ruby interface to Firebird/Interbase library maintainer: po...@freebsd.org status: BROKEN deprecated because: Does not work with Ruby 1.9 expiration date:2013-05-02 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=ruby-interbase portname: devel/dsss description:D Shared Software System maintainer: po...@freebsd.org status: BROKEN deprecated because: Depends on expired lang/gdc expiration date:2013-09-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=dsss portname: devel/g2c description:Glade to C translator maintainer: po...@freebsd.org deprecated because: Not supported upstream anymore expiration date:2013-08-29 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=g2c portname: devel/ppl description:The Parma Polyhedra Library maintainer: po...@freebsd.org status: BROKEN deprecated because: obsolete version; fails to build expiration date:2013-09-21 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=ppl portname: devel/rubygem-zoom description:A Ruby binding to the Z39.50 Object-Orientation Model (ZOOM) maintainer: po...@freebsd.org status: BROKEN deprecated because: Does not work with Ruby 1.9 expiration date:2013-05-02 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=rubygem-zoom portname: games/kaid description:XLink Kai tunneling server maintainer: po...@freebsd.org status: BROKEN deprecated because: Does not fetch expiration date:2013-08-07 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=gamesportname=kaid portname: games/koth description:Multiplayer tank artillery game similar to Scorched Earth maintainer: po...@freebsd.org deprecated because: Unmaintained expiration date:2013-09-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=gamesportname=koth portname: multimedia/linux-gspca-kmod description:A port of the linux gspcav1 webcam driver maintainer: po...@freebsd.org status: BROKEN deprecated because: Broken for more than 6 month expiration date:2013-08-27 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=multimediaportname=linux-gspca-kmod portname: net-im/jabber-pymsn description:Python MSN-Transport for Jabber maintainer: po...@freebsd.org deprecated because: Primary MSN Messenger service terminated 30 APR 2013 expiration date:2013-10-31 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net-importname=jabber-pymsn portname: net-im/p5-Net-MSN description:Net::MSN interface maintainer: po...@freebsd.org deprecated because: Primary MSN Messenger service terminated 30 APR 2013 expiration date:2013-10-31 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net-importname=p5-Net-MSN portname: net-im/py-msnp description:MSN messaging in Python maintainer: po...@freebsd.org deprecated because: Primary MSN Messenger service terminated 30 APR 2013 expiration date:2013-10-31 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net-importname=py-msnp portname: net-im/pymsn description:MSN Connection library maintainer: po...@freebsd.org deprecated because: Primary MSN Messenger service terminated 30 APR 2013 expiration date:2013-10-31 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net-importname=pymsn portname:
FreeBSD ports you maintain which are out of date
Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/po...@freebsd.org.html Port| Current version | New version +-+ devel/newt | 0.52.15 | 0.52.16 +-+ devel/p5-Parse-ErrorString-Perl | 0.15| 0.19 +-+ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt If wish to stop receiving portscout reminders, please contact portsc...@freebsd.org Thanks. ___ 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
x11/nvidia-driver build failure in head/i386 @r253985 with clang
Builds/runs OK (so far) in stable/9/i386 @r254053 with clang. Whine is: ... clang -O2 -pipe -fno-strict-aliasing -DNV_VERSION_STRING=\319.32\ -D__KERNEL__ -DNVRM -Wno-unused-function -Wuninitialized -O -UDEBUG -U_DEBUG -DNDEBUG -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I. -I@ -I@/contrib/altq -fno-common -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -Qunused-arguments -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -c nvidia_sysctl.c --- nvidia_subr.o --- nvidia_subr.c:948:33: error: incompatible pointer types passing 'vm_map_t' (aka 'struct vm_map *') to parameter of type 'struct vmem *' [-Werror,-Wincompatible-pointer-types] address = kmem_alloc_contig(kernel_map, size, flags, 0, ^~ @/vm/vm_extern.h:54:44: note: passing argument to parameter here vm_offset_t kmem_alloc_contig(struct vmem *, vm_size_t size, int flags, ^ nvidia_subr.c:997:19: error: incompatible pointer types passing 'vm_map_t' (aka 'struct vm_map *') to parameter of type 'struct vmem *' [-Werror,-Wincompatible-pointer-types] kmem_free(kernel_map, ^~ @/vm/vm_extern.h:58:29: note: passing argument to parameter here void kmem_free(struct vmem *, vm_offset_t, vm_size_t); ^ nvidia_subr.c:1024:15: error: incompatible pointer types passing 'vm_map_t' (aka 'struct vm_map *') to parameter of type 'struct vmem *' [-Werror,-Wincompatible-pointer-types] kmem_free(kernel_map, at-pte_array[0].virtual_address, ^~ @/vm/vm_extern.h:58:29: note: passing argument to parameter here void kmem_free(struct vmem *, vm_offset_t, vm_size_t); ^ nvidia_subr.c:1088:37: error: incompatible pointer types passing 'vm_map_t' (aka 'struct vm_map *') to parameter of type 'struct vmem *' [-Werror,-Wincompatible-pointer-types] address = kmem_alloc_contig(kernel_map, PAGE_SIZE, flags, 0, ^~ @/vm/vm_extern.h:54:44: note: passing argument to parameter here vm_offset_t kmem_alloc_contig(struct vmem *, vm_size_t size, int flags, ^ nvidia_subr.c:1142:19: error: incompatible pointer types passing 'vm_map_t' (aka 'struct vm_map *') to parameter of type 'struct vmem *' [-Werror,-Wincompatible-pointer-types] kmem_free(kernel_map, ^~ @/vm/vm_extern.h:58:29: note: passing argument to parameter here void kmem_free(struct vmem *, vm_offset_t, vm_size_t); ^ nvidia_subr.c:1172:19: error: incompatible pointer types passing 'vm_map_t' (aka 'struct vm_map *') to parameter of type 'struct vmem *' [-Werror,-Wincompatible-pointer-types] kmem_free(kernel_map, ^~ @/vm/vm_extern.h:58:29: note: passing argument to parameter here void kmem_free(struct vmem *, vm_offset_t, vm_size_t); ^ 6 errors generated. *** [nvidia_subr.o] Error code 1 make[3]: stopped in /common/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86-319.32/src 1 error I am presently updating head to r254052 and that process will attempt to rebuild x11/nvidia-driver. If that's successful, I will follow up. In the mean time, I will try to figure out what's wrong: nvidia-driver-304.51 built/ran OK in head/i386 @r253985 (with clang). Peace, david -- David H. Wolfskill da...@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpWMLn6bcJLv.pgp Description: PGP signature
Re: x11/nvidia-driver build failure in head/i386 @r253985 with clang
On Wed, Aug 07, 2013 at 06:02:41AM -0700, David Wolfskill wrote: [...] nvidia_subr.c:997:19: error: incompatible pointer types passing 'vm_map_t' (aka 'struct vm_map *') to parameter of type 'struct vmem *' [-Werror, -Wincompatible-pointer-types] kmem_free(kernel_map, ^~ @/vm/vm_extern.h:58:29: note: passing argument to parameter here void kmem_free(struct vmem *, vm_offset_t, vm_size_t); I've tested the new driver on my Julyish -CURRENT and it was all fine... I suspect the problem might be with Jeff's r254025 (CC'ed). I will see what I can do about it, thanks for your report! In the mean time, I will try to figure out what's wrong: nvidia-driver-304.51 built/ran OK in head/i386 @r253985 (with clang). Please share your findings once you have them. :-) ./danfe ___ 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 converters/libiconv and devel/gettext
I was trying to update (portmaster) subversion (1.7 to 1.8) on a USB-stick (9.2-BETA2 amd64) installation and failed because of a conflict between converters/libiconv and devel/gettext apparently trying to install files to the same place: /usr/local/lib/charset.alias Closing error messages were install -o root -g wheel -m 444 ./iconv.3 /usr/local/man/man3/iconv.3 install -o root -g wheel -m 444 ./iconv_close.3 /usr/local/man/man3/iconv_close.3 install -o root -g wheel -m 444 ./iconv_open.3 /usr/local/man/man3/iconv_open.3 install -o root -g wheel -m 444 ./iconv_open_into.3 /usr/local/man/man3/iconv_open_into.3 install -o root -g wheel -m 444 ./iconvctl.3 /usr/local/man/man3/iconvctl.3 if [ ! -d /usr/local/share/doc/libiconv ] ; then /bin/sh ../build-aux/mkinstalldirs /usr/local/share/doc/libiconv ; fi mkdir /usr/local/share/doc/libiconv builddir=`pwd`; cd . for f in *.html ; do (cd $builddir; echo install -o root -g wheel -m 444 ./$f /usr/local/share/doc/libiconv/$f ; install -o root -g wheel -m 444 ./$f /usr/local/share/doc/libiconv/$f) ; done install -o root -g wheel -m 444 ./iconv.1.html /usr/local/share/doc/libiconv/iconv.1.html install -o root -g wheel -m 444 ./iconv.3.html /usr/local/share/doc/libiconv/iconv.3.html install -o root -g wheel -m 444 ./iconv_close.3.html /usr/local/share/doc/libiconv/iconv_close.3.html install -o root -g wheel -m 444 ./iconv_open.3.html /usr/local/share/doc/libiconv/iconv_open.3.html install -o root -g wheel -m 444 ./iconv_open_into.3.html /usr/local/share/doc/libiconv/iconv_open_into.3.html install -o root -g wheel -m 444 ./iconvctl.3.html /usr/local/share/doc/libiconv/iconvctl.3.html === Compressing manual pages for libiconv-1.14_1 === Running ldconfig /sbin/ldconfig -m /usr/local/lib === Registering installation for libiconv-1.14_1 Installing libiconv-1.14_1...pkg-static: libiconv-1.14_1 conflicts with gettext-0.18.1.1 (installs files into the same place). Problematic file: /usr/local/lib/charset.alias *** [fake-pkg] Error code 70 Stop in /BETA1/usr/ports/converters/libiconv. *** [install] Error code 1 Stop in /BETA1/usr/ports/converters/libiconv. === A backup package for libiconv-1.14 should be located in /usr/packages/portmaster-backup === Installation of libiconv-1.14_1 (converters/libiconv) failed === Aborting update === Update for libiconv-1.14 failed === Aborting update === Update for apr-1.4.6.1.4.1_1 failed === Aborting update === Killing background jobs Terminated === Installation of databases/sqlite3 (sqlite3-3.7.17_1) complete === You can restart from the point of failure with this command line: portmaster flags devel/subversion devel/apr1 converters/libiconv databases/gdbm devel/gettext net/openldap24-client textproc/expat2 www/serf === Exiting Strangely, the same update succeeded on a USB-stick i386 (9.1-STABLE) installation, maybe because the last update on that was more recent, possibly including the would-be-offending libiconv and gettext (only a guess on my part). Tom ___ 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: x11/nvidia-driver build failure in head/i386 @r253985 with clang
On Wed, Aug 07, 2013 at 01:20:34PM +, Alexey Dokuchaev wrote: On Wed, Aug 07, 2013 at 06:02:41AM -0700, David Wolfskill wrote: [...] nvidia_subr.c:997:19: error: incompatible pointer types passing 'vm_map_t' (aka 'struct vm_map *') to parameter of type 'struct vmem *' [-Werror, -Wincompatible-pointer-types] kmem_free(kernel_map, ^~ @/vm/vm_extern.h:58:29: note: passing argument to parameter here void kmem_free(struct vmem *, vm_offset_t, vm_size_t); I've tested the new driver on my Julyish -CURRENT and it was all fine... I suspect the problem might be with Jeff's r254025 (CC'ed). I will see what I can do about it, thanks for your report! Glad to heko! In the mean time, I will try to figure out what's wrong: nvidia-driver-304.51 built/ran OK in head/i386 @r253985 (with clang). Please share your findings once you have them. :-) Build still fails in head/i386 @r254052, similarly: ... clang -O2 -pipe -fno-strict-aliasing -DNV_VERSION_STRING=\319.32\ -D__KERNEL__ -DNVRM -Wno-unused-function -Wuninitialized -O -UDEBUG -U_DEBUG -DNDEBUG -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I. -I@ -I@/contrib/altq -fno-common -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -Qunused-arguments -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -c nvidia_subr.c nvidia_subr.c:948:33: error: incompatible pointer types passing 'vm_map_t' (aka 'struct vm_map *') to parameter of type 'struct vmem *' [-Werror,-Wincompatible-pointer-types] address = kmem_alloc_contig(kernel_map, size, flags, 0, ^~ @/vm/vm_extern.h:54:44: note: passing argument to parameter here vm_offset_t kmem_alloc_contig(struct vmem *, vm_size_t size, int flags, ^ nvidia_subr.c:997:19: error: incompatible pointer types passing 'vm_map_t' (aka 'struct vm_map *') to parameter of type 'struct vmem *' [-Werror,-Wincompatible-pointer-types] kmem_free(kernel_map, ^~ @/vm/vm_extern.h:58:29: note: passing argument to parameter here void kmem_free(struct vmem *, vm_offset_t, vm_size_t); ^ Not sure how much further I'll be able to get for a while; I'm out-of-town and Internet access is a bit flaky. Sorry... Peace, david -- David H. Wolfskill da...@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpLVjhSrTObE.pgp Description: PGP signature
Re: Conflict between converters/libiconv and devel/gettext
On Wed, Aug 07, 2013 at 01:41:49PM +, Thomas Mueller wrote: I was trying to update (portmaster) subversion (1.7 to 1.8) on a USB-stick (9.2-BETA2 amd64) installation and failed because of a conflict between converters/libiconv and devel/gettext apparently trying to install files to the same place: /usr/local/lib/charset.alias UPDATING: 20130316 regards, Bapt pgpcGxP6frzWU.pgp Description: PGP signature
Re: [SOLVED] libpkg, sqlite and database problems prevent building any packages
On 07/08/2013 02:00, Thomas Mueller wrote: At first, with sqlite3 not listed as a dependency of pkg, I wouldn't have realized what needed fixing. That's deliberate. If pkg(8) had to install other packages as dependencies of itself, it would make bootstrapping pkg on a new system a bit difficult. So sqlite is bundled into the pkg source tree, along with a few other external bits. That pkg(8) uses sqlite is not exactly secret -- there's a whole man page for pkg-shell(8) which talks about using the sqlite3 console, and sqlite is clearly mentioned in pkg(8) and other man pages. Cheers, Matthew Dr Matthew J Seaman MA, D.Phil. man pkg-shell doesn't show much on using the sqlite3 console, mainly points why for the most part it should not be used. Maybe my rescue was the better way or at least the safer way? Tom ___ 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
mozc-tool 1.11.1502.102 build fail
Dear porters. I have following error with FreeBSD 10.0-CURRENT #0 r253884 amd64. $ cd /usr/ports/japanese/mozc-tool $ make [snip] CXX(target) out_linux/Release/obj.target/word_register_dialog_lib/gui/word_register_dialog/word_register_dialog_libmain.o AR(target) out_linux/Release/obj.target/gui/libcharacter_pad_lib.a AR(target) out_linux/Release/obj.target/client/libclient.a AR(target) out_linux/Release/obj.target/gui/libconfig_dialog_lib.a AR(target) out_linux/Release/obj.target/session/libkey_parser.a AR(target) out_linux/Release/obj.target/session/libkeymap.a AR(target) out_linux/Release/obj.target/session/libkey_event_util.a AR(target) out_linux/Release/obj.target/gui/libdictionary_tool_lib.a AR(target) out_linux/Release/obj.target/gui/libgui_base.a AR(target) out_linux/Release/obj.target/gui/libpost_install_dialog_lib.a AR(target) out_linux/Release/obj.target/gui/libset_default_dialog_lib.a AR(target) out_linux/Release/obj.target/gui/libword_register_dialog_lib.a CXX(target) out_linux/Release/obj.target/mozc_tool/gui/tool/mozc_tool_main.o LINK(target) out_linux/Release/mozc_tool /usr/bin/ld: : invalid DSO for symbol `libiconv_open' definition /usr/local/lib/libiconv.so.3: could not read symbols: Bad value c++: error: linker command failed with exit code 1 (use -v to see invocation) gmake[4]: *** [out_linux/Release/mozc_tool] Error 1 gmake[4]: Leaving directory `/usr/ports/japanese/mozc-tool/work/mozc-1.11.1502.102' Traceback (most recent call last): File build_mozc.py, line 1521, in module main() File build_mozc.py, line 1509, in main BuildMain(cmd_opts, cmd_args, original_directory_name) File build_mozc.py, line 1134, in BuildMain BuildOnLinux(options, targets, original_directory_name) File build_mozc.py, line 1087, in BuildOnLinux RunOrDie([make_command] + build_args + target_names) File /usr/ports/japanese/mozc-tool/work/mozc-1.11.1502.102/build_tools/util.py, line 97, in RunOrDie '=='])) build_tools.util.RunOrDieError: == ERROR: /usr/ports/japanese/mozc-tool/work/mozc-1.11.1502.102/mozcmake -j8 MAKE_JOBS=8 BUILDTYPE=Release builddir_name=out_linux mozc_tool == *** Error code 1 Stop. make[3]: stopped in /usr/ports/japanese/mozc-tool *** Error code 1 Stop. make[2]: stopped in /usr/ports/japanese/mozc-tool *** Error code 1 Stop. make[1]: stopped in /usr/ports/japanese/ibus-mozc *** Error code 1 Stop. make: stopped in /usr/ports/japanese/ibus-mozc Thanks in advance. -- Kenichi Niioka ___ 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
Upgrading Telepathy-glib-0.18.2 to 0.20.2 fails
Im trying to upgrade telepathy-glib-0.18.2 to 0.20.2 and its failing with the following error. It seems it's not finding Glib-2.0 and Gio-2.0. Are these packages supposed to be part of the build? Anyone familiar with those exact packages? Why wouldn't it build the dependencies? telepathy-glib-0.18.2 needs updating (port has 0.20.2) portupgrade telepathy-glib-0.18.2 gmake[2]: Leaving directory `/usr/ports/net-im/telepathy-glib/work/telepathy-glib-0.20.2/telepathy-glib' Making all in vala gmake[2]: Entering directory `/usr/ports/net-im/telepathy-glib/work/telepathy-glib-0.20.2/vala' /usr/local/bin/vapigen \ --library telepathy-glib \ --metadatadir=../telepathy-glib \ --pkg gio-2.0 \ ../telepathy-glib/TelepathyGLib-0.12.gir \ error: Package `GLib-2.0' not found in specified Vala API directories or GObject-Introspection GIR directories error: Package `Gio-2.0' not found in specified Vala API directories or GObject-Introspection GIR directories Generation failed: 2 error(s), 0 warning(s) gmake[2]: *** [telepathy-glib.vapi] Error 1 gmake[2]: Leaving directory `/usr/ports/net-im/telepathy-glib/work/telepathy-glib-0.20.2/vala' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/ports/net-im/telepathy-glib/work/telepathy-glib-0.20.2' gmake: *** [all] Error 2 *** [do-build] Error code 1 Stop in /usr/ports/net-im/telepathy-glib. ** Command failed [exit code 1]: /usr/bin/script -qa /tmp/portupgrade20130807-60458-r86key env UPGRADE_TOOL=portupgrade UPGRADE_PORT=telepathy-glib-0.18.2 UPGRADE_PORT_VER=0.18.2 make ** Fix the problem and try again. ** Listing the failed packages (-:ignored / *:skipped / !:failed) ! net-im/telepathy-glib (telepathy-glib-0.18.2) (new compiler error) ___ 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
[QAT] r324355: 4x leftovers
Fix index by replacing the incorrect variable brace. - Build ID: 20130807151000-58396 Job owner: vsevo...@freebsd.org Buildtime: 28 minutes Enddate: Wed, 07 Aug 2013 15:37:55 GMT Revision: r324355 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=324355 - Port:multimedia/audacious-plugins 3.4 Buildgroup: 9.1-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~vsevo...@freebsd.org/20130807151000-58396-168540/audacious-plugins-3.4.log Buildgroup: 9.1-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~vsevo...@freebsd.org/20130807151000-58396-168541/audacious-plugins-3.4.log Buildgroup: 8.4-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~vsevo...@freebsd.org/20130807151000-58396-168542/audacious-plugins-3.4.log Buildgroup: 8.4-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~vsevo...@freebsd.org/20130807151000-58396-168543/audacious-plugins-3.4.log -- Buildarchive URL: https://qat.redports.org/buildarchive/20130807151000-58396 redports https://qat.redports.org/ ___ 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
Strange problem with portmaster
I recently upgraded all the ports on a server, so I decided to run portmaster -r perl to make sure all the perl ports were up to date. I used portmaster -rfd perl and got the following error: /var/db/pkg/fd does not exist I googled a bit and found nothing. Then I thought, that's strange, fd was the second and third commands. So I ran: portmaster -r -f -d perl and I got /var/db/pkg/f does not exist Then I tried portmaster -rf -d perl and got /var/db/pkg/d does not exist I finally just ran portmaster -r perl, which worked of course. Apparently the -r switch doesn't want to see anything after except the port that's being recursively built? I didn't try portmaster -fd -r perl. Maybe I should have? -- Paul Schmehl (pa...@utdallas.edu) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/infosecurity/ ___ 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: Strange problem with portmaster
Am 07.08.2013 18:06, schrieb Paul Schmehl: I recently upgraded all the ports on a server, so I decided to run portmaster -r perl to make sure all the perl ports were up to date. I used portmaster -rfd perl and got the following error: /var/db/pkg/fd does not exist I googled a bit and found nothing. Then I thought, that's strange, fd was the second and third commands. So I ran: portmaster -r -f -d perl and I got /var/db/pkg/f does not exist Then I tried portmaster -rf -d perl and got /var/db/pkg/d does not exist I finally just ran portmaster -r perl, which worked of course. Apparently the -r switch doesn't want to see anything after except the port that's being recursively built? I didn't try portmaster -fd -r perl. Maybe I should have? Paul, you should have tried that: The -r switch has a mandatory argument and is not just a bare switch, so be sure to keep the r right before the perl argument when coalescing options. portmaster -dfr perl should work, as should portmaster -d -fr perl, or portmaster -fr perl -d $ grep getopt /usr/local/sbin/portmaster | grep -v ^# while getopts 'BCDFGHKLPRabde:fghilm:nop:r:stvwx:y' COMMAND_LINE_ARGUMENT ; do meaning that e, m, p, r, x options take a mandatory argument. Just standard getopts business shared by most POSIX shell utilities. HTH Matthias ___ 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: Strange problem with portmaster
On Wed, Aug 07, 2013 at 11:06:52AM -0500, Paul Schmehl wrote: I recently upgraded all the ports on a server, so I decided to run portmaster -r perl to make sure all the perl ports were up to date. I used portmaster -rfd perl and got the following error: /var/db/pkg/fd does not exist I googled a bit and found nothing. Then I thought, that's strange, fd was the second and third commands. So I ran: portmaster -r -f -d perl and I got /var/db/pkg/f does not exist Then I tried portmaster -rf -d perl and got /var/db/pkg/d does not exist I finally just ran portmaster -r perl, which worked of course. Apparently the -r switch doesn't want to see anything after except the port that's being recursively built? I didn't try portmaster -fd -r perl. Maybe I should have? Yes, you should have, at least if you wanted the '-fd' flags. It may not be highlighted in the man page, but it does say -r name/glob of port directory in /var/db/pkg, and I've found that the '-r' flag does require that the port follow immediately. -- greg byshenk - gbysh...@byshenk.net - Portland, OR USA ___ 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: x11/nvidia-driver build failure in head/i386 @r253985 with clang
On Wed, 7 Aug 2013, David Wolfskill wrote: On Wed, Aug 07, 2013 at 01:20:34PM +, Alexey Dokuchaev wrote: On Wed, Aug 07, 2013 at 06:02:41AM -0700, David Wolfskill wrote: [...] nvidia_subr.c:997:19: error: incompatible pointer types passing 'vm_map_t' (aka 'struct vm_map *') to parameter of type 'struct vmem *' [-Werror, -Wincompatible-pointer-types] kmem_free(kernel_map, ^~ @/vm/vm_extern.h:58:29: note: passing argument to parameter here void kmem_free(struct vmem *, vm_offset_t, vm_size_t); I've tested the new driver on my Julyish -CURRENT and it was all fine... I suspect the problem might be with Jeff's r254025 (CC'ed). I will see what I can do about it, thanks for your report! Glad to heko! In the mean time, I will try to figure out what's wrong: nvidia-driver-304.51 built/ran OK in head/i386 @r253985 (with clang). Please share your findings once you have them. :-) Build still fails in head/i386 @r254052, similarly: ... clang -O2 -pipe -fno-strict-aliasing -DNV_VERSION_STRING=\319.32\ -D__KERNEL__ -DNVRM -Wno-unused-function -Wuninitialized -O -UDEBUG -U_DEBUG -DNDEBUG -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I. -I@ -I@/contrib/altq -fno-common -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -Qunused-arguments -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -c nvidia_subr.c nvidia_subr.c:948:33: error: incompatible pointer types passing 'vm_map_t' (aka 'struct vm_map *') to parameter of type 'struct vmem *' [-Werror,-Wincompatible-pointer-types] address = kmem_alloc_contig(kernel_map, size, flags, 0, ^~ @/vm/vm_extern.h:54:44: note: passing argument to parameter here vm_offset_t kmem_alloc_contig(struct vmem *, vm_size_t size, int flags, ^ nvidia_subr.c:997:19: error: incompatible pointer types passing 'vm_map_t' (aka 'struct vm_map *') to parameter of type 'struct vmem *' [-Werror,-Wincompatible-pointer-types] kmem_free(kernel_map, ^~ @/vm/vm_extern.h:58:29: note: passing argument to parameter here void kmem_free(struct vmem *, vm_offset_t, vm_size_t); ^ Not sure how much further I'll be able to get for a while; I'm out-of-town and Internet access is a bit flaky. Sorry... This is my fault. The first argument to the kmem_ functions should now be kernel_arena or kmem_arena. I don't know how to modify ports but I can produce a patch later today to resolve this unless someone beats me to it. It will be a simple substitution based on version. Jeff Peace, david -- David H. Wolfskill da...@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. ___ 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: Conflict between converters/libiconv and devel/gettext
To resolve this conflict remove gettext and libiconv and reinstall gettext (it reinstall libiconv). This resolves the problem (but it's not proper because process which uses gettext when gettext is missing don't like it). -- Best regards, Loïc BLOT, UNIX systems, security and network expert http://www.unix-experience.fr Le mercredi 07 août 2013 à 15:44 +0200, Baptiste Daroussin a écrit : On Wed, Aug 07, 2013 at 01:41:49PM +, Thomas Mueller wrote: I was trying to update (portmaster) subversion (1.7 to 1.8) on a USB-stick (9.2-BETA2 amd64) installation and failed because of a conflict between converters/libiconv and devel/gettext apparently trying to install files to the same place: /usr/local/lib/charset.alias UPDATING: 20130316 regards, Bapt signature.asc Description: This is a digitally signed message part
Re: Conflict between converters/libiconv and devel/gettext
On Wed, Aug 07, 2013 at 10:40:40PM +0200, Loïc BLOT wrote: To resolve this conflict remove gettext and libiconv and reinstall gettext (it reinstall libiconv). This resolves the problem (but it's not proper because process which uses gettext when gettext is missing don't like it). Now that we have config.site, this shouldn't happen again (what happened was that configure script were picking in priority gawk or gsed for example when they were present and because they were linked to gettext it was failing, config.site make sure that awk or sed (and many others) from base are picked up in priority, so this is safe now. regards, Bapt pgpVEilegjQsB.pgp Description: PGP signature
Re: x11/nvidia-driver build failure in head/i386 @r253985 with clang
On Wed, Aug 07, 2013 at 08:53:02AM -1000, Jeff Roberson wrote: ... Not sure how much further I'll be able to get for a while; I'm out-of-town and Internet access is a bit flaky. Sorry... This is my fault. The first argument to the kmem_ functions should now be kernel_arena or kmem_arena. I don't know how to modify ports but I can produce a patch later today to resolve this unless someone beats me to it. It will be a simple substitution based on version. ... I'll be happy to test. Peace, david -- David H. Wolfskill da...@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgp9fE7OMxyg4.pgp Description: PGP signature
Re: kdenetwork4
On Wed, 2013-08-07 at 18:49 -0500, Scot Hetzel wrote: On Mon, Aug 5, 2013 at 7:58 PM, Stan Gammons s_gamm...@charter.net wrote: Here the output I get when I try to build kdenetwork4 from ports. Looks like libmsn is the problem. Where is the makefile located that has libmsn as a dependency? === Continuing initial dependency check for net-im/kopete-kde4 === Launching child to install net-im/libmsn === net/kdenetwork4 net-im/kopete-kde4 net-im/libmsn (10/10) ]0;portmaster: net/kdenetwork4 net-im/kopete-kde4 net-im/libmsn (10/10) === Port directory: /usr/ports/net-im/libmsn === This port is marked DEPRECATED === Primary MSN Messenger service terminated 30 APR 2013 === If you are sure you can build it, remove the DEPRECATED line in the Makefile and try again. === Update for net-im/libmsn failed === Aborting update === Update for net-im/kopete-kde4 failed === Aborting update You have 3 choices here. 1. Comment out the DEPRECATED line in /usr/ports/net-im/libmsn/Makefile 2. Remove net-im/libmsn from the LIB_DEPENDS in /usr/ports/net-im/kopete-kde4/Makefile (may need to adjust PLIST also). 3. Wait for the KDE team to fix the issue with net-im/kopete-kde depending on a deprecated port. Scot, I removed net-im/libmsn from LIB_DEPENDS in /usr/ports/net-im/kopete-kde4/Makefile and kdenetwork4 builds Ok. I see from one of the automated emails earlier today that net-im/libmsn is scheduled to be deleted. Thanks for the help! Stan ___ 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: x11/nvidia-driver build failure in head/i386 @r253985 with clang
On Wed, Aug 07, 2013 at 08:53:02AM -1000, Jeff Roberson wrote: This is my fault. The first argument to the kmem_ functions should now be kernel_arena or kmem_arena. I don't know how to modify ports but I can produce a patch later today to resolve this unless someone beats me to it. It will be a simple substitution based on version. Yep, it is a simple substitution, our users also figured it out. No need for a patch, I will adopt the one in PR ports/181118. Luckily, __FreeBSD_version was bumped just couple of days ago, otherwise I'd had to harass Jeff about not bumping it along with API breakage. ;-) ./danfe ___ 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: x11/nvidia-driver build failure in head/i386 @r253985 with clang
On Wed, Aug 07, 2013 at 02:03:13PM -0700, David Wolfskill wrote: On Wed, Aug 07, 2013 at 08:53:02AM -1000, Jeff Roberson wrote: ... Not sure how much further I'll be able to get for a while; I'm out-of-town and Internet access is a bit flaky. Sorry... This is my fault. The first argument to the kmem_ functions should now be kernel_arena or kmem_arena. I don't know how to modify ports but I can produce a patch later today to resolve this unless someone beats me to it. It will be a simple substitution based on version. ... I'll be happy to test. Should be fixed now as of r324376. ./danfe ___ 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
