Re: Failed building kdebase-workspace-4.5.5_1 cannot find the library liblzma.la
On Mar 27, 2011, at 21:24 , Troy wrote: I do have those libs there. I'm not sure why it's looking in /usr/local/lib to find it. I double checked and have /usr/lib in my PATH. Do you have any thoughts here? At a rough guess, you source-upgraded your system from a time when archivers/xz was required (and included the .la file) to a point where it was in the base system without essentially rebuilding everything. You could _probably_ temporarily fix this by looking for /usr/local/lib/liblzma.la in _every_ .la file installed under /usr/local/lib, and replace it with -lzma but this is just a very temporary fix to a horribly fragile .la interdependency framework. There are various solutions to this, but they're all by nature very invasive and can cause other issues. Sadly, there is no easy one-liner fix to this either. -aDe ___ 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
Current unassigned ports problem reports
(Note: an HTML version of this report is available at http://www.freebsd.org/cgi/query-pr-summary.cgi?category=ports .) The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description f ports/155992[patch] update net/ndisc6 to 1.0.1 o ports/155964OS hangs completely when suspend\resume with active Vi f ports/155960[UPDATE]: audio/qmpdclient Update to new release, 1.2. o ports/155954[MAINTAINER] multimedia/openshot: add missing dependen o ports/155947Software that does not launch or start ! f ports/155941mwserv library support is not included in nepenthes.co o ports/155934Incorporate patch from the Ice project into devel/mcpp o ports/155933[MAINTAINER] sysutils/lsof: pick up src_base o ports/155932[NEW PORT] net/xorp-ct: Open source network routing pl f ports/155931[patch] sysutils/arcconf: update to v6_50_18771 o ports/155919new port: IPv4/IPv6 Webserver port, BSD license o ports/155914new port: audio/autotalent, ladspa plugin autotalent f ports/155898Update port devel/libthai f ports/155876[PATCH] security/shibboleth2-sp: do not clobber/remove o ports/155875hungarian/hunspell misfiled under ports/hungarian o ports/155790[patch] games/simutrans: version 110.0.1 o ports/155788ports security/cfsd startup -- multiple problems o ports/155785[PATCH] dns/nsd: update to 3.2.8, take maintainership o ports/155779[PATCH] mail/policyd2: fix RC script o ports/155767New port: www/cutycapt o ports/155766Vendor update: net/kvirc f ports/155763update of mail/phplist to version 2.10.13 f ports/155750www/p5-RT-Authen-ExternalAuth stopped working after up f ports/155706net/quagga: ripd is broken f ports/155697ports-mgmt/pkg_replace doesn't want to replace java/op f ports/155656net/ipv6socket_scrub : port deprecate f ports/155655[patch] science/meep Add Option to support MPI build f ports/155595[PATCH] lang/guile: update to 1.8.8 o ports/155593lang/mpd .16.1 ignores embedded cue sheets in FLAC fil f ports/155592polish/ekg, after polish/libgadu update, contacts are o ports/155581[maintainer-update][patch] databases/jasperserver: dis f ports/155563net/tucan: update to 0.3.10 o ports/155561[patch] update sysutils/bcfg2 port to latest stable re f ports/16[PATCH] mail/davmail: Deobfuscate rc script and add sh o ports/155547java/jboss 5 port build failure f ports/155545Updating port multimedia/mediainfo to 0.7.42 o ports/155538new port devel/radlib radlib developer library. Event- o ports/155525[MAINTAINER] games/assaultcube: fixes and additions o ports/155509Update port: net/xrdp update to current cvs version an f ports/155469[patch] science/meep missing build dependency gsed o ports/155456security/openssh-portable fails to compile with LPK en o ports/155417[patch] www/nspluginwrapper: NSPlugin Viewer WARNING: o ports/155413devel/pwlib fails to install o ports/155405databases/cego: [update] [ports] new version and added f ports/155404[PATCH] mail/mutt-devel: doesn't build in presence of f ports/155393[PATCH] www/speedtest-mini: update to 2.1.8 f ports/155356audio/xwave changed master site o ports/155344New port: irc/inspircd12 f ports/155306multimedia/openshot doesn't work o ports/155225plz split antlr2 and antlr3 ports. not update antlr2 - f ports/155208sysutils/file is updated to 5.05 f ports/155200[UPDATE] devel/libchipcard: Update to 5.0.0, remove de f ports/155170[update] www/ocaml-net to 3.2.1 o ports/155166update deskutils/org-mode.el to 7.4 f ports/155143/usr/ports/irc/unreal - Unreal IRCD runs as root by d f ports/155120Update of port devel/php-libawl o ports/155116new port: devel/antlr2-python-runtime, ANTLR v2 python f ports/155115devel/doxygen: dependancy loop o ports/155111Create new megaglest port o ports/155105Port science/vis5d+ does not build. o ports/155070NEW PORT: games/CastleVox - new fast strategy board ga o ports/155064New port: devel/stringtemplate, a java lib for text fo o ports/155063Port update: devel/antlrworks a ports/155062Port update: devel/antlr o ports/154995[NEW PORT]
Re: some vdr intro/installation notes (watch/record/stream tv)
Quoting Juergen Lock n...@jelal.kn-bremen.de (from Sat, 26 Mar 2011 20:28:38 +0100): Hi, now that the vdr ports are finally committed here are some updated notes: Hi all, I wiki-fied this mail (http://wiki.freebsd.org/VDR). Interested people can now enhance it (I don't). Bye, Alexander. -- 1 bulls, 3 cows. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: some vdr intro/installation notes (watch/record/stream tv)
On Mon, Mar 28, 2011 at 02:45:38PM +0200, Alexander Leidinger wrote: Quoting Juergen Lock n...@jelal.kn-bremen.de (from Sat, 26 Mar 2011 20:28:38 +0100): Hi, now that the vdr ports are finally committed here are some updated notes: Hi all, I wiki-fied this mail (http://wiki.freebsd.org/VDR). Interested people can now enhance it (I don't). Thank you very much! I just did some minor tweaks. (yeah I finally got a wiki account too... :) Enjoy, Juergen ___ 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: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install
on 25/03/2011 12:11 Baptiste Daroussin said the following: Hi all, miwi@ launched the new thing called Experimental Call For Testing, it's our turn :) Julien Laffaye (jlaffaye@) and I, helped by Philippe Pepiot (huge contributor) have been working since the end of the last GSoC on a rewrite of pkg_install. pkgng is a binary package manager written from scratch for FreeBSD. After a long period of technology testing, (json, tinycdb, bdb, etc) and we now have achieved to implement the basic functionnality. We would greatly approciate to have some feedback, wider testing, patching, documenting etc, before implementing the higher level features. pkgng is built on top of a new libpkg, which allow to deal with the database of installed packages, to deal with remote repositories, manage packages: creation, installation gathering informations, registering new ports. features supported are or will be : - smooth integration with bsd.port.mk (including bsd.pkg.mk line 2486) which allow to have a bsd.port.mk which deal with both pkg_install and pkgng. (done in alpha) - the register command can analyse elf files when registering a new port to discover forgotten dependencies if necessary. (done in alpha using libelf) - the register command has two mode available : when dealing with old fashion ports it just registers the package, in new mode it does everything that would have been done by pkg add when installing the package : should display messages, execute post-install, execute @exec etc. (old fashion done in the alpha) - pkg add supports two mode : the old fashion one (no real upgrade support) and new one: upgrade scripts supported. (old fashion in the alpha) - new scripts supported +PREINSTALL +POSTINSTALL, +PREDEINSTALL, +POSTDEINSTALL, +PREUPGRADE, +POSTUPGRADE as well as the old fashion scripts : +INSTALL +DEINSTALL +UPGRADE (all supported *UPGRADES aren't supported in the alpha) - new +MANIFEST (plist-like format) with new metadatas : options, arch, os version, etc. (done in the alpha) - pkgng supports checking arch of the package which means that users won't be able to install sparc64 binary package into amd64 machines. (not done yet) - a special architecture all allows to specify when a package can be used on every architecture. (not done yet) - @dirrm and @dirrmtry are now deprecated, pkgng can discover itself which directory has to be removed. (done in the alpha but needs love :)) - new repository (apt-like feature) (only the repository generation is done) - real support for reverse dependency (no ugly +REQUIRED_BY) (done in the alpha) - test unit (libcheck) on libpkg. (done in the alpha needs some more love) - many more Perhaps I am too impatient :) but I would like to inquire about the following features: I. A provides/requires interface for packages. Each package specified a list of files (and perhaps other entities) that it provides and requires. At the initial stage, without ports modifications, these could be: (1) a list of all files installed by package for provides; (2) for requires - an auto-generated list of dependencies based on required shared libraries plus dependency specifications in ports. I think that this kind of interface should help with using alternatives that provide the same interface (e.g. like gamin vs fam). II. Package signing. III. Package naming that includes architecture, major OS version (for API/ABI), maybe more. IV. Convenient support for i386 packages on amd64. Distinct installation directories, proper installation conflict detection/avoidance between i386 and amd64 packages, proper library paths, etc. And finally some exotic ideas - support for multiple package sources (when different people build packages in different ways (e.g. with different options, or different optimizations) from the same ports tree; support for multiple ports sources.(when people maintain different ports tree (e.g. kde or gnome development ports tree)). Perhaps, with some compatibility/hierarchy support for packages and ports sources. But that's almost a pipe dream, so don't take it seriously :) -- Andriy Gapon ___ 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: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install
On Mon, Mar 28, 2011 at 10:44 AM, Andriy Gapon a...@freebsd.org wrote: on 25/03/2011 12:11 Baptiste Daroussin said the following: Hi all, miwi@ launched the new thing called Experimental Call For Testing, it's our turn :) Julien Laffaye (jlaffaye@) and I, helped by Philippe Pepiot (huge contributor) have been working since the end of the last GSoC on a rewrite of pkg_install. pkgng is a binary package manager written from scratch for FreeBSD. After a long period of technology testing, (json, tinycdb, bdb, etc) and we now have achieved to implement the basic functionnality. We would greatly approciate to have some feedback, wider testing, patching, documenting etc, before implementing the higher level features. pkgng is built on top of a new libpkg, which allow to deal with the database of installed packages, to deal with remote repositories, manage packages: creation, installation gathering informations, registering new ports. features supported are or will be : - smooth integration with bsd.port.mk (including bsd.pkg.mk line 2486) which allow to have a bsd.port.mk which deal with both pkg_install and pkgng. (done in alpha) - the register command can analyse elf files when registering a new port to discover forgotten dependencies if necessary. (done in alpha using libelf) - the register command has two mode available : when dealing with old fashion ports it just registers the package, in new mode it does everything that would have been done by pkg add when installing the package : should display messages, execute post-install, execute @exec etc. (old fashion done in the alpha) - pkg add supports two mode : the old fashion one (no real upgrade support) and new one: upgrade scripts supported. (old fashion in the alpha) - new scripts supported +PREINSTALL +POSTINSTALL, +PREDEINSTALL, +POSTDEINSTALL, +PREUPGRADE, +POSTUPGRADE as well as the old fashion scripts : +INSTALL +DEINSTALL +UPGRADE (all supported *UPGRADES aren't supported in the alpha) - new +MANIFEST (plist-like format) with new metadatas : options, arch, os version, etc. (done in the alpha) - pkgng supports checking arch of the package which means that users won't be able to install sparc64 binary package into amd64 machines. (not done yet) - a special architecture all allows to specify when a package can be used on every architecture. (not done yet) - @dirrm and @dirrmtry are now deprecated, pkgng can discover itself which directory has to be removed. (done in the alpha but needs love :)) - new repository (apt-like feature) (only the repository generation is done) - real support for reverse dependency (no ugly +REQUIRED_BY) (done in the alpha) - test unit (libcheck) on libpkg. (done in the alpha needs some more love) - many more Perhaps I am too impatient :) but I would like to inquire about the following features: I. A provides/requires interface for packages. Each package specified a list of files (and perhaps other entities) that it provides and requires. At the initial stage, without ports modifications, these could be: (1) a list of all files installed by package for provides; (2) for requires - an auto-generated list of dependencies based on required shared libraries plus dependency specifications in ports. I think that this kind of interface should help with using alternatives that provide the same interface (e.g. like gamin vs fam). II. Package signing. That would be really nice. III. Package naming that includes architecture, major OS version (for API/ABI), maybe more. This could be provided in the manifest. Doing it in the filename sort of turns into a mess, as I've discovered working at Cisco :). IV. Convenient support for i386 packages on amd64. Distinct installation directories, proper installation conflict detection/avoidance between i386 and amd64 packages, proper library paths, etc. There are other architectures that would benefit from this as well, like powerpc 32-bit on 64-bit, MIPs 32-bit on n32, etc. This involves more work than pkgng could provide IIRC as build infrastructure would need to be fixed to look at and link against usr/lib32 instead of usr/lib, unless you mean to rewrite the linker stuff at install-time. And finally some exotic ideas - support for multiple package sources (when different people build packages in different ways (e.g. with different options, or different optimizations) from the same ports tree; support for multiple ports sources.(when people maintain different ports tree (e.g. kde or gnome development ports tree)). Perhaps, with some compatibility/hierarchy support for packages and ports sources. But that's almost a pipe dream, so don't take it seriously :) It would be nice. That's a request in the same general area that Gentoo portage's overlay goes into, but I think that would require rewriting certain bits of ports infrastructure to be extensible, not extend pkgng in this
Unable to configure dirmngr after libksba upgrade
After I upgraded libksba to 1.2.0, I attempted to re-build dirmngr, but all of my systems are failing due to failing to detect LDAP. checking whether LDAP via -lldap is present and sane... no checking whether LDAP via -lldap -llber is present and sane... no checking whether LDAP via -lldap -llber -lresolv is present and sane... no checking whether LDAP via -lwldap32 is present and sane... no checking for ANSI C header files... (cached) yes checking for string.h... (cached) yes checking locale.h usability... yes checking locale.h presence... yes checking for locale.h... yes checking for an ANSI C-conforming const... yes checking for inline... inline checking for size_t... yes checking return type of signal handlers... void checking whether sys_siglist is declared... yes checking for byte typedef... no checking for ushort typedef... yes checking for ulong typedef... no checking for struct sigaction... yes checking for sigset_t... yes checking for sys/stat.h... (cached) yes checking for unistd.h... (cached) yes checking direct.h usability... no checking direct.h presence... no checking for direct.h... no checking if mkdir takes one argument... no checking for memicmp... no checking for stpcpy... yes checking for strsep... yes checking for strlwr... no checking for strtoul... yes checking for memmove... yes checking for stricmp... no checking for strtol... yes checking for memrchr... yes checking for isascii... yes checking for timegm... yes checking for getrusage... yes checking for setrlimit... yes checking for stat... yes checking for setlocale... yes checking for flockfile... yes checking for funlockfile... yes checking for funopen... yes checking for fopencookie... no checking for gmtime_r... yes checking for getaddrinfo... yes checking for strtoull... yes checking for mmap... yes checking for canonicalize_file_name... no configure: *** *** You need a LDAP library to build this program. *** Check out ***http://www.openldap.org *** for a suitable implementation. *** configure: error: *** *** Required libraries not found. Please consult the above messages *** and install them before running configure again. *** === Script configure failed unexpectedly. Please report the problem to u...@ueo.co.jp [maintainer] and attach the /usr/ports/security/dirmngr/work/dirmngr-1.1.0/config.log including the output of the failure of your make command. Also, it might be a good idea to provide an overview of all packages installed on your system (e.g. an `ls /var/db/pkg`). *** Error code 1 Stop in /usr/ports/security/dirmngr. *** Error code 1 I certainly do have openldap-client installed. I even re-installed it, just to make sure nothing had been stepped on. I have libldap and liblber in /usr/local/lib/ The first two attempts fail with: /usr/local/lib/libldap.so: undefined reference to `fetchGetURL' Any idea what may be going wrong? -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ 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: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install
On Mon, Mar 28, 2011 at 6:59 PM, Garrett Cooper gcoo...@freebsd.org wrote: On Mon, Mar 28, 2011 at 10:44 AM, Andriy Gapon a...@freebsd.org wrote: on 25/03/2011 12:11 Baptiste Daroussin said the following: Hi all, miwi@ launched the new thing called Experimental Call For Testing, it's our turn :) Julien Laffaye (jlaffaye@) and I, helped by Philippe Pepiot (huge contributor) have been working since the end of the last GSoC on a rewrite of pkg_install. pkgng is a binary package manager written from scratch for FreeBSD. After a long period of technology testing, (json, tinycdb, bdb, etc) and we now have achieved to implement the basic functionnality. We would greatly approciate to have some feedback, wider testing, patching, documenting etc, before implementing the higher level features. pkgng is built on top of a new libpkg, which allow to deal with the database of installed packages, to deal with remote repositories, manage packages: creation, installation gathering informations, registering new ports. features supported are or will be : - smooth integration with bsd.port.mk (including bsd.pkg.mk line 2486) which allow to have a bsd.port.mk which deal with both pkg_install and pkgng. (done in alpha) - the register command can analyse elf files when registering a new port to discover forgotten dependencies if necessary. (done in alpha using libelf) - the register command has two mode available : when dealing with old fashion ports it just registers the package, in new mode it does everything that would have been done by pkg add when installing the package : should display messages, execute post-install, execute @exec etc. (old fashion done in the alpha) - pkg add supports two mode : the old fashion one (no real upgrade support) and new one: upgrade scripts supported. (old fashion in the alpha) - new scripts supported +PREINSTALL +POSTINSTALL, +PREDEINSTALL, +POSTDEINSTALL, +PREUPGRADE, +POSTUPGRADE as well as the old fashion scripts : +INSTALL +DEINSTALL +UPGRADE (all supported *UPGRADES aren't supported in the alpha) - new +MANIFEST (plist-like format) with new metadatas : options, arch, os version, etc. (done in the alpha) - pkgng supports checking arch of the package which means that users won't be able to install sparc64 binary package into amd64 machines. (not done yet) - a special architecture all allows to specify when a package can be used on every architecture. (not done yet) - @dirrm and @dirrmtry are now deprecated, pkgng can discover itself which directory has to be removed. (done in the alpha but needs love :)) - new repository (apt-like feature) (only the repository generation is done) - real support for reverse dependency (no ugly +REQUIRED_BY) (done in the alpha) - test unit (libcheck) on libpkg. (done in the alpha needs some more love) - many more Perhaps I am too impatient :) but I would like to inquire about the following features: I. A provides/requires interface for packages. Each package specified a list of files (and perhaps other entities) that it provides and requires. At the initial stage, without ports modifications, these could be: (1) a list of all files installed by package for provides; (2) for requires - an auto-generated list of dependencies based on required shared libraries plus dependency specifications in ports. I think that this kind of interface should help with using alternatives that provide the same interface (e.g. like gamin vs fam). Adding require/provide support in pkgng is kind of trivial. But ports have to support it first. II. Package signing. That would be really nice. Right know we only planned to sign the repo database, so we can trust the sah256 of the packages stored in the database. Then if the package has the same sha256 as the one in the repo database it is considered trusted. If we want a per-package signing, we would have a tarball in a tarball. III. Package naming that includes architecture, major OS version (for API/ABI), maybe more. This could be provided in the manifest. Doing it in the filename sort of turns into a mess, as I've discovered working at Cisco :). Actually, it *is* in the +MANIFEST of pkgng packages archives :-) IV. Convenient support for i386 packages on amd64. Distinct installation directories, proper installation conflict detection/avoidance between i386 and amd64 packages, proper library paths, etc. There are other architectures that would benefit from this as well, like powerpc 32-bit on 64-bit, MIPs 32-bit on n32, etc. This involves more work than pkgng could provide IIRC as build infrastructure would need to be fixed to look at and link against usr/lib32 instead of usr/lib, unless you mean to rewrite the linker stuff at install-time. I dont think we are going that way right now... And finally some exotic ideas - support for multiple package sources (when different people build packages in different
Re: Unable to configure dirmngr after libksba upgrade
Date: Mon, 28 Mar 2011 11:22:37 -0700 From: Doug Barton do...@freebsd.org On 03/28/2011 11:13, Kevin Oberman wrote: I certainly do have openldap-client installed. I even re-installed it, just to make sure nothing had been stepped on. I have libldap and liblber in/usr/local/lib/ The first two attempts fail with: /usr/local/lib/libldap.so: undefined reference to `fetchGetURL' Any idea what may be going wrong? I haven't tested the theory yet, but can you check if openldap has been built with the FETCH option, and if not, try enabling it and see if that helps? Thanks, but no joy. It was built with fetch(3) support. I'll look more closely at the log in a bit, but I'm going to be tied up for an hour or so with other issues. (Still have a network to engineer.) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ 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: Unable to configure dirmngr after openldap upgrade
This has nothing to do with libksba, it's just a coincidence that bumping the PORTREVISION on dirmngr for the libksba update caused you to rebuild dirmngr against an up to date openldap. Reverting to openldap-client-2.4.24 allows dirmngr to build, thus I've changed the subject line of this message. The presence of the FETCH option (which is what I always use anyway) doesn't improve the situation, FYI. Doug On 03/28/2011 11:22, Kevin Oberman wrote: After I upgraded libksba to 1.2.0, I attempted to re-build dirmngr, but all of my systems are failing due to failing to detect LDAP. checking whether LDAP via -lldap is present and sane... no checking whether LDAP via -lldap -llber is present and sane... no checking whether LDAP via -lldap -llber -lresolv is present and sane... no checking whether LDAP via -lwldap32 is present and sane... no checking for ANSI C header files... (cached) yes checking for string.h... (cached) yes checking locale.h usability... yes checking locale.h presence... yes checking for locale.h... yes checking for an ANSI C-conforming const... yes checking for inline... inline checking for size_t... yes checking return type of signal handlers... void checking whether sys_siglist is declared... yes checking for byte typedef... no checking for ushort typedef... yes checking for ulong typedef... no checking for struct sigaction... yes checking for sigset_t... yes checking for sys/stat.h... (cached) yes checking for unistd.h... (cached) yes checking direct.h usability... no checking direct.h presence... no checking for direct.h... no checking if mkdir takes one argument... no checking for memicmp... no checking for stpcpy... yes checking for strsep... yes checking for strlwr... no checking for strtoul... yes checking for memmove... yes checking for stricmp... no checking for strtol... yes checking for memrchr... yes checking for isascii... yes checking for timegm... yes checking for getrusage... yes checking for setrlimit... yes checking for stat... yes checking for setlocale... yes checking for flockfile... yes checking for funlockfile... yes checking for funopen... yes checking for fopencookie... no checking for gmtime_r... yes checking for getaddrinfo... yes checking for strtoull... yes checking for mmap... yes checking for canonicalize_file_name... no configure: *** *** You need a LDAP library to build this program. *** Check out ***http://www.openldap.org *** for a suitable implementation. *** configure: error: *** *** Required libraries not found. Please consult the above messages *** and install them before running configure again. *** === Script configure failed unexpectedly. Please report the problem to u...@ueo.co.jp [maintainer] and attach the /usr/ports/security/dirmngr/work/dirmngr-1.1.0/config.log including the output of the failure of your make command. Also, it might be a good idea to provide an overview of all packages installed on your system (e.g. an `ls /var/db/pkg`). *** Error code 1 Stop in /usr/ports/security/dirmngr. *** Error code 1 I certainly do have openldap-client installed. I even re-installed it, just to make sure nothing had been stepped on. I have libldap and liblber in /usr/local/lib/ The first two attempts fail with: /usr/local/lib/libldap.so: undefined reference to `fetchGetURL' Any idea what may be going wrong? -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ 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: Unable to configure dirmngr after libksba upgrade
On Mon, Mar 28, 2011 at 11:22:40AM -0700, Kevin Oberman wrote: After I upgraded libksba to 1.2.0, I attempted to re-build dirmngr, but all of my systems are failing due to failing to detect LDAP. checking whether LDAP via -lldap is present and sane... no checking whether LDAP via -lldap -llber is present and sane... no checking whether LDAP via -lldap -llber -lresolv is present and sane... no checking whether LDAP via -lwldap32 is present and sane... no checking for ANSI C header files... (cached) yes checking for string.h... (cached) yes checking locale.h usability... yes checking locale.h presence... yes checking for locale.h... yes checking for an ANSI C-conforming const... yes checking for inline... inline checking for size_t... yes checking return type of signal handlers... void checking whether sys_siglist is declared... yes checking for byte typedef... no checking for ushort typedef... yes checking for ulong typedef... no checking for struct sigaction... yes checking for sigset_t... yes checking for sys/stat.h... (cached) yes checking for unistd.h... (cached) yes checking direct.h usability... no checking direct.h presence... no checking for direct.h... no checking if mkdir takes one argument... no checking for memicmp... no checking for stpcpy... yes checking for strsep... yes checking for strlwr... no checking for strtoul... yes checking for memmove... yes checking for stricmp... no checking for strtol... yes checking for memrchr... yes checking for isascii... yes checking for timegm... yes checking for getrusage... yes checking for setrlimit... yes checking for stat... yes checking for setlocale... yes checking for flockfile... yes checking for funlockfile... yes checking for funopen... yes checking for fopencookie... no checking for gmtime_r... yes checking for getaddrinfo... yes checking for strtoull... yes checking for mmap... yes checking for canonicalize_file_name... no configure: *** *** You need a LDAP library to build this program. *** Check out ***http://www.openldap.org *** for a suitable implementation. *** configure: error: *** *** Required libraries not found. Please consult the above messages *** and install them before running configure again. *** === Script configure failed unexpectedly. Please report the problem to u...@ueo.co.jp [maintainer] and attach the /usr/ports/security/dirmngr/work/dirmngr-1.1.0/config.log including the output of the failure of your make command. Also, it might be a good idea to provide an overview of all packages installed on your system (e.g. an `ls /var/db/pkg`). *** Error code 1 Stop in /usr/ports/security/dirmngr. *** Error code 1 I certainly do have openldap-client installed. I even re-installed it, just to make sure nothing had been stepped on. I have libldap and liblber in /usr/local/lib/ The first two attempts fail with: /usr/local/lib/libldap.so: undefined reference to `fetchGetURL' Any idea what may be going wrong? Did you selected Fetch support (or similar) in the openldap-client config dialog ? pgp0OsHhMq5E1.pgp Description: PGP signature
Re: Unable to configure dirmngr after libksba upgrade
On Mon, 28 Mar 2011 22:17:24 +0300 Kostik Belousov kostik...@gmail.com articulated: On Mon, Mar 28, 2011 at 11:22:40AM -0700, Kevin Oberman wrote: After I upgraded libksba to 1.2.0, I attempted to re-build dirmngr, but all of my systems are failing due to failing to detect LDAP. checking whether LDAP via -lldap is present and sane... no checking whether LDAP via -lldap -llber is present and sane... no checking whether LDAP via -lldap -llber -lresolv is present and sane... no checking whether LDAP via -lwldap32 is present and sane... no checking for ANSI C header files... (cached) yes checking for string.h... (cached) yes checking locale.h usability... yes checking locale.h presence... yes checking for locale.h... yes checking for an ANSI C-conforming const... yes checking for inline... inline checking for size_t... yes checking return type of signal handlers... void checking whether sys_siglist is declared... yes checking for byte typedef... no checking for ushort typedef... yes checking for ulong typedef... no checking for struct sigaction... yes checking for sigset_t... yes checking for sys/stat.h... (cached) yes checking for unistd.h... (cached) yes checking direct.h usability... no checking direct.h presence... no checking for direct.h... no checking if mkdir takes one argument... no checking for memicmp... no checking for stpcpy... yes checking for strsep... yes checking for strlwr... no checking for strtoul... yes checking for memmove... yes checking for stricmp... no checking for strtol... yes checking for memrchr... yes checking for isascii... yes checking for timegm... yes checking for getrusage... yes checking for setrlimit... yes checking for stat... yes checking for setlocale... yes checking for flockfile... yes checking for funlockfile... yes checking for funopen... yes checking for fopencookie... no checking for gmtime_r... yes checking for getaddrinfo... yes checking for strtoull... yes checking for mmap... yes checking for canonicalize_file_name... no configure: *** *** You need a LDAP library to build this program. *** Check out ***http://www.openldap.org *** for a suitable implementation. *** configure: error: *** *** Required libraries not found. Please consult the above messages *** and install them before running configure again. *** === Script configure failed unexpectedly. Please report the problem to u...@ueo.co.jp [maintainer] and attach the /usr/ports/security/dirmngr/work/dirmngr-1.1.0/config.log including the output of the failure of your make command. Also, it might be a good idea to provide an overview of all packages installed on your system (e.g. an `ls /var/db/pkg`). *** Error code 1 Stop in /usr/ports/security/dirmngr. *** Error code 1 I certainly do have openldap-client installed. I even re-installed it, just to make sure nothing had been stepped on. I have libldap and liblber in /usr/local/lib/ The first two attempts fail with: /usr/local/lib/libldap.so: undefined reference to `fetchGetURL' Any idea what may be going wrong? Did you selected Fetch support (or similar) in the openldap-client config dialog ? For what its worth, I am getting exactly the same thing. Has anyone filed a PR against it yet? -- Jerry ✌ freebsd-ports.u...@seibercom.net Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ signature.asc Description: PGP signature
Re: Unable to configure dirmngr after openldap upgrade
Date: Mon, 28 Mar 2011 11:47:49 -0700 From: Doug Barton do...@freebsd.org This has nothing to do with libksba, it's just a coincidence that bumping the PORTREVISION on dirmngr for the libksba update caused you to rebuild dirmngr against an up to date openldap. Reverting to openldap-client-2.4.24 allows dirmngr to build, thus I've changed the subject line of this message. The presence of the FETCH option (which is what I always use anyway) doesn't improve the situation, FYI. Doug On 03/28/2011 11:22, Kevin Oberman wrote: After I upgraded libksba to 1.2.0, I attempted to re-build dirmngr, but all of my systems are failing due to failing to detect LDAP. checking whether LDAP via -lldap is present and sane... no checking whether LDAP via -lldap -llber is present and sane... no checking whether LDAP via -lldap -llber -lresolv is present and sane... no checking whether LDAP via -lwldap32 is present and sane... no checking for ANSI C header files... (cached) yes checking for string.h... (cached) yes checking locale.h usability... yes checking locale.h presence... yes checking for locale.h... yes checking for an ANSI C-conforming const... yes checking for inline... inline checking for size_t... yes checking return type of signal handlers... void checking whether sys_siglist is declared... yes checking for byte typedef... no checking for ushort typedef... yes checking for ulong typedef... no checking for struct sigaction... yes checking for sigset_t... yes checking for sys/stat.h... (cached) yes checking for unistd.h... (cached) yes checking direct.h usability... no checking direct.h presence... no checking for direct.h... no checking if mkdir takes one argument... no checking for memicmp... no checking for stpcpy... yes checking for strsep... yes checking for strlwr... no checking for strtoul... yes checking for memmove... yes checking for stricmp... no checking for strtol... yes checking for memrchr... yes checking for isascii... yes checking for timegm... yes checking for getrusage... yes checking for setrlimit... yes checking for stat... yes checking for setlocale... yes checking for flockfile... yes checking for funlockfile... yes checking for funopen... yes checking for fopencookie... no checking for gmtime_r... yes checking for getaddrinfo... yes checking for strtoull... yes checking for mmap... yes checking for canonicalize_file_name... no configure: *** *** You need a LDAP library to build this program. *** Check out ***http://www.openldap.org *** for a suitable implementation. *** configure: error: *** *** Required libraries not found. Please consult the above messages *** and install them before running configure again. *** === Script configure failed unexpectedly. Please report the problem to u...@ueo.co.jp [maintainer] and attach the /usr/ports/security/dirmngr/work/dirmngr-1.1.0/config.log including the output of the failure of your make command. Also, it might be a good idea to provide an overview of all packages installed on your system (e.g. an `ls /var/db/pkg`). *** Error code 1 Stop in /usr/ports/security/dirmngr. *** Error code 1 I certainly do have openldap-client installed. I even re-installed it, just to make sure nothing had been stepped on. I have libldap and liblber in /usr/local/lib/ The first two attempts fail with: /usr/local/lib/libldap.so: undefined reference to `fetchGetURL' Any idea what may be going wrong? -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ Yup. openldap-client-2.4.24 does fine. Looks like a bug in 2.4.25. I'll take a look at CHANGES and see if I can figure out what broke the inclusion of fetch(3) support if I get a bit of time. Thanks! -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ 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: Failed building kdebase-workspace-4.5.5_1 cannot find the library liblzma.la
On 2011-Mar-27 21:24:25 -0500, Troy t...@twisted.net wrote: I do have those libs there. I'm not sure why it's looking in /usr/local/lib to find it. I double checked and have /usr/lib in my PATH. Do you have any thoughts here? Congratulations. You've been screwed by libtool. A possible alternative to ade@'s suggestion would be to create a /usr/local/lib/liblzma.la based on one of your other .la files but with libdir='/usr/lib' at the end. The downside of this is that it will probably further entrench the idea that liblzma lives in /usr/local/lib -- Peter Jeremy pgpn3m8c4qgb7.pgp Description: PGP signature
Re: Unable to configure dirmngr after openldap upgrade
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/28/11 12:42, Kevin Oberman wrote: Yup. openldap-client-2.4.24 does fine. Looks like a bug in 2.4.25. I'll take a look at CHANGES and see if I can figure out what broke the inclusion of fetch(3) support if I get a bit of time. It seems that libldif now referenced the fetch support, and ironically it seem be a bug but a feature :( I have decided to disable FETCH support from now on, since it's likely to bring more problems. (If you would prefer to fix the problem for this specific problem, I think adding a '-lfetch' would be sufficient; but, it seems to be undesirable to depend fetch(3) unconditionally for all programs that uses openldap). Cheers, - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (FreeBSD) iQEcBAEBCAAGBQJNkPQ6AAoJEATO+BI/yjfBGi8IAJ/3o2sVhal0i7982PNuCZXW gI2aH/e7dWDM2NfL8dSKZlmF8vH/Q0aZHHvlVpQ4o0tCYSk4Iouk8BM6MEVS1Upc 3JLmHVR12D0FBblLpetTstcdx2w2390efPrTI+j+YrJn5yz218Ypu53k1d4F4D/L IbM3t96FwulS/vSara6pb4m1H28FMpEs7+0jqEDdeJxm26cWWe++z48Lg5yUcnwW uh2aiDpll7ep7vEuWQGw7pfG+IBd3tsTKm1rqXJ4hgZirYI5lXg18tL2W702P0Ez kyeye7uY7nsWqR0f7nWCBF5GMPidCQ1/fzAz/WwHtoTkbw4vPpDxiNxwox59H7I= =m6q3 -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Unable to configure dirmngr after openldap upgrade
On 03/28/2011 13:48, Xin LI wrote: On 03/28/11 12:42, Kevin Oberman wrote: Yup. openldap-client-2.4.24 does fine. Looks like a bug in 2.4.25. I'll take a look at CHANGES and see if I can figure out what broke the inclusion of fetch(3) support if I get a bit of time. It seems that libldif now referenced the fetch support, and ironically it seem be a bug but a feature :( I have decided to disable FETCH support from now on, since it's likely to bring more problems. (If you would prefer to fix the problem for this specific problem, I think adding a '-lfetch' would be sufficient; but, it seems to be undesirable to depend fetch(3) unconditionally for all programs that uses openldap). I know next to nothing about how the openldap-client stuff works, so I'm sorry if these questions are silly. :) The biggest question is, does dirmngr compile after your change? The other question is that the only reason I have openldap installed at all is so that gnupg can use it to fetch keys from ldap keyservers. Will this still work when the FETCH option is no longer present? Thanks, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ 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: Unable to configure dirmngr after openldap upgrade
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/28/11 13:57, Doug Barton wrote: On 03/28/2011 13:48, Xin LI wrote: On 03/28/11 12:42, Kevin Oberman wrote: Yup. openldap-client-2.4.24 does fine. Looks like a bug in 2.4.25. I'll take a look at CHANGES and see if I can figure out what broke the inclusion of fetch(3) support if I get a bit of time. It seems that libldif now referenced the fetch support, and ironically it seem be a bug but a feature :( I have decided to disable FETCH support from now on, since it's likely to bring more problems. (If you would prefer to fix the problem for this specific problem, I think adding a '-lfetch' would be sufficient; but, it seems to be undesirable to depend fetch(3) unconditionally for all programs that uses openldap). I know next to nothing about how the openldap-client stuff works, so I'm sorry if these questions are silly. :) The biggest question is, does dirmngr compile after your change? The other question is that the only reason I have openldap installed at all is so that gnupg can use it to fetch keys from ldap keyservers. Will this still work when the FETCH option is no longer present? hmm... how do I test fetching from an ldap keyserver? Cheers, - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (FreeBSD) iQEcBAEBCAAGBQJNkPuXAAoJEATO+BI/yjfBIfQH/0eDvRuE5BTRr/lpMhKgsLQf 8m18MN+52TXNV1xDGvsPU9Z4fRRFfIgm90mVXVeKGwAvTa9xJdLygybPtvsbh6OJ AIlLa7N1JBF9G7BxD8Mzg8T43Ho5UgpZDsFCnd/K1CkjDFuvCMO8SEUWRdNGY23T 6j83Zdb+8rhlbq3nL3+2oejYGRR/QzoqTwGBLvHYZD0NFmcDuR6qUddHxfN7+94h rYzw03GHlSu734PWfuqR5i8+tgrvv2eAte0flhrXU+ukMbZKFB8HBJRHAsylRRs/ SYxoDjO441GpEjGS51ZRlXdyx+cWoDa15lXO9G26y270DE7YmOScXzF1sp/wKQI= =H2fm -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Help with first port Makefile
Hello,
I read FreeBSD needs new blood! by Martin Wilke and decided to try my
hand at this, but before diving into X11 like I want, I need to brush
off the C skills I haven't used in 10 years. I decided to first port
something from the Wanted Ports on the FreeBSD wiki and choose Fotoxx.
I've been successful in translating the code enough to get it to build
but I having some issues with the LIBS_DEPEND in the port Makefile.
Fotoxx depends on Libgtk2.0 as it is called, according to the web page,
in Ubuntu. This would be x11-toolkits/gtk20.
If I put:
USE_GNOME= yes
in the Makefile everything builds great, but it checks for dependencies
that aren't needed by Fotoxx. All I want to check is to make sure gtk20
is installed. I have tried the following, but all of these fail to find
gtk20, even though it is installed on my system.
LIB_DEPENDS= gtk20:${PORTSDIR}/x11-toolkits/gtk20
and
LIB_DEPENDS= libgtk-x11-2.0.so:${PORTSDIR}/x11-toolkits/gtk20
I've also tried as BUILD_DEPENDS but it has the same result. I've
attached the Makefile in the current state.
Any help is greatly appreciated.
--
Rod Person
http://www.rodperson.com
You ain't ready, yet.
- Michael L. Flecther, Sr.
aka Mike-A-Nike
Makefile
Description: Binary data
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Unable to configure dirmngr after openldap upgrade
On 03/28/2011 14:20, Xin LI wrote: On 03/28/11 13:57, Doug Barton wrote: On 03/28/2011 13:48, Xin LI wrote: On 03/28/11 12:42, Kevin Oberman wrote: Yup. openldap-client-2.4.24 does fine. Looks like a bug in 2.4.25. I'll take a look at CHANGES and see if I can figure out what broke the inclusion of fetch(3) support if I get a bit of time. It seems that libldif now referenced the fetch support, and ironically it seem be a bug but a feature :( I have decided to disable FETCH support from now on, since it's likely to bring more problems. (If you would prefer to fix the problem for this specific problem, I think adding a '-lfetch' would be sufficient; but, it seems to be undesirable to depend fetch(3) unconditionally for all programs that uses openldap). I know next to nothing about how the openldap-client stuff works, so I'm sorry if these questions are silly. :) The biggest question is, does dirmngr compile after your change? The other question is that the only reason I have openldap installed at all is so that gnupg can use it to fetch keys from ldap keyservers. Will this still work when the FETCH option is no longer present? hmm... how do I test fetching from an ldap keyserver? I'll save you the trouble. :) I got your latest update and tested both scenarios myself, and the answer is that they both work. So now the question is, should the FETCH OPTION be removed altogether? I imagine that a lot of users will be at least as confused as I, and word is that PRs for other ports are already showing up. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ 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: Unable to configure dirmngr after openldap upgrade
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/28/11 16:30, Doug Barton wrote: On 03/28/2011 14:20, Xin LI wrote: On 03/28/11 13:57, Doug Barton wrote: On 03/28/2011 13:48, Xin LI wrote: On 03/28/11 12:42, Kevin Oberman wrote: Yup. openldap-client-2.4.24 does fine. Looks like a bug in 2.4.25. I'll take a look at CHANGES and see if I can figure out what broke the inclusion of fetch(3) support if I get a bit of time. It seems that libldif now referenced the fetch support, and ironically it seem be a bug but a feature :( I have decided to disable FETCH support from now on, since it's likely to bring more problems. (If you would prefer to fix the problem for this specific problem, I think adding a '-lfetch' would be sufficient; but, it seems to be undesirable to depend fetch(3) unconditionally for all programs that uses openldap). I know next to nothing about how the openldap-client stuff works, so I'm sorry if these questions are silly. :) The biggest question is, does dirmngr compile after your change? The other question is that the only reason I have openldap installed at all is so that gnupg can use it to fetch keys from ldap keyservers. Will this still work when the FETCH option is no longer present? hmm... how do I test fetching from an ldap keyserver? I'll save you the trouble. :) I got your latest update and tested both scenarios myself, and the answer is that they both work. So now the question is, should the FETCH OPTION be removed altogether? I imagine that a lot of users will be at least as confused as I, and word is that PRs for other ports are already showing up. I think that's being used in some ldap utilities so it might broke some applications that makes use of that? I'll add a note in UPDATING to document this. Cheers, - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (FreeBSD) iQEcBAEBCAAGBQJNkR1YAAoJEATO+BI/yjfBqaoH/0fOftHLInATGWxi9/JxTrv2 K0/SViPM7z9QRhPs8bpb1OnsQQvD7gwp/siz6TRkGMmTQcRc41ezmHmmX3wyhC27 mWQ6dx2BXNHJDATBcwiqAvQnUlIv5BBLwWqHRqiVvPc1k4ecqzoWSVACPzWNL4c0 LwlOgnE0dXwShB8ML5/4EJhAAsrtaaOveEDGT+WL6CmeDZzh/bc5K1g3qYHcmeBb qUD/crMrE3CfZAOd6qYY6L4gMw1A2Ed30DrjtKiW/4F807zBnmKVmH+5+YheIe9p McsHlHpxNtbN49A6pXTsYOhLD8ZyJIm6O/Znm6a1UcOi2pXBC7FWVuzcot/LJ1I= =a5f5 -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Unable to configure dirmngr after openldap upgrade
On 03/28/2011 16:44, Xin LI wrote: On 03/28/11 16:30, Doug Barton wrote: On 03/28/2011 14:20, Xin LI wrote: On 03/28/11 13:57, Doug Barton wrote: On 03/28/2011 13:48, Xin LI wrote: On 03/28/11 12:42, Kevin Oberman wrote: Yup. openldap-client-2.4.24 does fine. Looks like a bug in 2.4.25. I'll take a look at CHANGES and see if I can figure out what broke the inclusion of fetch(3) support if I get a bit of time. It seems that libldif now referenced the fetch support, and ironically it seem be a bug but a feature :( I have decided to disable FETCH support from now on, since it's likely to bring more problems. (If you would prefer to fix the problem for this specific problem, I think adding a '-lfetch' would be sufficient; but, it seems to be undesirable to depend fetch(3) unconditionally for all programs that uses openldap). I know next to nothing about how the openldap-client stuff works, so I'm sorry if these questions are silly. :) The biggest question is, does dirmngr compile after your change? The other question is that the only reason I have openldap installed at all is so that gnupg can use it to fetch keys from ldap keyservers. Will this still work when the FETCH option is no longer present? hmm... how do I test fetching from an ldap keyserver? I'll save you the trouble. :) I got your latest update and tested both scenarios myself, and the answer is that they both work. So now the question is, should the FETCH OPTION be removed altogether? I imagine that a lot of users will be at least as confused as I, and word is that PRs for other ports are already showing up. I think that's being used in some ldap utilities so it might broke some applications that makes use of that? I'll add a note in UPDATING to document this. I think an UPDATING entry is a good idea, however I think that a slave port would also be useful. Just remove FETCH from the current/master port, and add a slave with FETCH enabled. That way whatever (few?) ports that rely on that can change their dependency, and the rest of the users won't be affected. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ 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: Failed building kdebase-workspace-4.5.5_1 cannot find the library liblzma.la
On 3/28/2011 2:35 AM, Ade Lovett wrote: On Mar 27, 2011, at 21:24 , Troy wrote: I do have those libs there. I'm not sure why it's looking in /usr/local/lib to find it. I double checked and have /usr/lib in my PATH. Do you have any thoughts here? At a rough guess, you source-upgraded your system from a time when archivers/xz was required (and included the .la file) to a point where it was in the base system without essentially rebuilding everything. You could _probably_ temporarily fix this by looking for /usr/local/lib/liblzma.la in _every_ .la file installed under /usr/local/lib, and replace it with -lzma but this is just a very temporary fix to a horribly fragile .la interdependency framework. There are various solutions to this, but they're all by nature very invasive and can cause other issues. Sadly, there is no easy one-liner fix to this either. -aDe Anytime I've ever upgraded the system, I built the kernel and the world. I have 419 .la files in /usr/local/lib. I don't think I want to try that idea. Are you saying if I rebuilt the kernel/world it would not fix this properly? ___ 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: Unable to configure dirmngr after openldap upgrade
Am 28.03.2011 um 19:30 schrieb Doug Barton: On 03/28/2011 14:20, Xin LI wrote: On 03/28/11 13:57, Doug Barton wrote: On 03/28/2011 13:48, Xin LI wrote: On 03/28/11 12:42, Kevin Oberman wrote: Yup. openldap-client-2.4.24 does fine. Looks like a bug in 2.4.25. I'll take a look at CHANGES and see if I can figure out what broke the inclusion of fetch(3) support if I get a bit of time. It seems that libldif now referenced the fetch support, and ironically it seem be a bug but a feature :( I have decided to disable FETCH support from now on, since it's likely to bring more problems. (If you would prefer to fix the problem for this specific problem, I think adding a '-lfetch' would be sufficient; but, it seems to be undesirable to depend fetch(3) unconditionally for all programs that uses openldap). I know next to nothing about how the openldap-client stuff works, so I'm sorry if these questions are silly. :) The biggest question is, does dirmngr compile after your change? The other question is that the only reason I have openldap installed at all is so that gnupg can use it to fetch keys from ldap keyservers. Will this still work when the FETCH option is no longer present? hmm... how do I test fetching from an ldap keyserver? I'll save you the trouble. :) I got your latest update and tested both scenarios myself, and the answer is that they both work. So now the question is, should the FETCH OPTION be removed altogether? I imagine that a lot of users will be at least as confused as I, and word is that PRs for other ports are already showing up. Being the one who caused the FETCH OPTION to be added in the first place (see ports/145337), I'm in favor of completely disabling it unconditionally. As noted in this PR, linking openldap-client with libfetch also can introduce other ugly side effects depending on your environment. In my case, I use security/openssl from ports, but since libfetch is built against openssl from base the result is that my www/apache22 (with LDAP support) depended on two conflicting versions of OpenSSL (from base through libfetch and ports/openssl directly). The effect of turning this off seems to be minor. Grepping around the OpenLDAP source tree, the only place where the URL fetching actually is used is to support LDIF values referenced from a URL (e.g. using myPicture: http://my.server/me.jpg; to load the content of me.jpg). According to RFC2849 defining the LDIF format (note 6): a) Implementations SHOULD support the file:// URL format. The contents of the referenced file are to be included verbatim in the interpreted output of the LDIF file. b) Implementations MAY support other URL formats.[...] Even without libfetch, a) will still work, while b) will not. Note also that OpenLDAP's support for this is a very FreeBSD specific feature. The configure.in file actually states as much (it only detects FreeBSD's libfetch): [...] dnl Check for fetch URL support dnl should be extended to support other fetch URL APIs [...] Given these facts, I'd be surprised if any public application were to rely on this feature (since it won't work with the (de-facto standard) OpenLDAP libraries anywhere but on FreeBSD). That only leaves the possibility of breaking some homebrew code by FreeBSD users that may exist and rely on this feature. Alexander ___ 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: Updating multiple ports with portmaster
On 03/26/2011 09:47, Doug Barton wrote: On 3/26/2011 8:22 AM, Ron (Lists) wrote: Is there a way to get portmaster to behave like portupgrade did and only upgrade what needs to be upgraded? I reserve the right not only to change my mind, but also to be wrong on occasion. :) I just ran into a situation where having this option would be useful, so I added it to the svn version of portmaster, r220121. Fortunately it was not as painful as I thought it might have been. I don't have immediate plans to cut a new release given that 3.6.1 has been very stable, and I have a lot of other fish to fry atm. However feel free to download the devel version from svn and give it a try. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ 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: Unable to configure dirmngr after libksba upgrade
Reverting openldap-client to openldap-client-2.4.24 allowed my dirmngr to build and stopped playing havoc with my kde 4.6.1 upgrade in kdepim and kdeadmin (thus far) Tim On 03/28/11 14:48, Kevin Oberman wrote: Date: Mon, 28 Mar 2011 11:22:37 -0700 From: Doug Bartondo...@freebsd.org On 03/28/2011 11:13, Kevin Oberman wrote: I certainly do have openldap-client installed. I even re-installed it, just to make sure nothing had been stepped on. I have libldap and liblber in/usr/local/lib/ The first two attempts fail with: /usr/local/lib/libldap.so: undefined reference to `fetchGetURL' Any idea what may be going wrong? I haven't tested the theory yet, but can you check if openldap has been built with the FETCH option, and if not, try enabling it and see if that helps? Thanks, but no joy. It was built with fetch(3) support. I'll look more closely at the log in a bit, but I'm going to be tied up for an hour or so with other issues. (Still have a network to engineer.) ___ 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 Port: mysql51-q4m-0.9.2
Hello, The latest version of q4m is is 0.9.5 and it includes some critical bug fixes and stability improvements. Also, the URL has been changed to http://q4m.github.com Could you please update the port file? Thank you, Tomislav ___ 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: Help with first port Makefile
Rod Person rodper...@rodperson.com writes:
If I put:
USE_GNOME= yes
in the Makefile everything builds great, but it checks for dependencies
that aren't needed by Fotoxx. All I want to check is to make sure gtk20
is installed. I have tried the following, but all of these fail to find
gtk20, even though it is installed on my system.
LIB_DEPENDS= gtk20:${PORTSDIR}/x11-toolkits/gtk20
and
LIB_DEPENDS= libgtk-x11-2.0.so:${PORTSDIR}/x11-toolkits/gtk20
I suggest taking a look at section 5.7.1 of the porter's handbook, which
describes the format for LIB_DEPENDS entries. You almost got it right on
the second try -- by taking a quick glance at
/usr/ports/Mk/bsd.gnome.mk, you can see this in line 281:
gtk20_LIB_DEPENDS= gtk-x11-2.0.0:${PORTSDIR}/x11-toolkits/gtk20
By the way, taking a look at the comments in the beginning of
bsd.gnome.mk is also a good idea, as it shows you can use something like
USE_GNOME=gtk20
and be done with it.
___
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: Help with first port Makefile
On Mon, Mar 28, 2011 at 9:28 PM, Raphael Kubo da Costa kub...@gmail.com wrote:
Rod Person rodper...@rodperson.com writes:
If I put:
USE_GNOME= yes
in the Makefile everything builds great, but it checks for dependencies
that aren't needed by Fotoxx. All I want to check is to make sure gtk20
is installed. I have tried the following, but all of these fail to find
gtk20, even though it is installed on my system.
LIB_DEPENDS= gtk20:${PORTSDIR}/x11-toolkits/gtk20
and
LIB_DEPENDS= libgtk-x11-2.0.so:${PORTSDIR}/x11-toolkits/gtk20
I suggest taking a look at section 5.7.1 of the porter's handbook, which
describes the format for LIB_DEPENDS entries. You almost got it right on
the second try -- by taking a quick glance at
/usr/ports/Mk/bsd.gnome.mk, you can see this in line 281:
gtk20_LIB_DEPENDS= gtk-x11-2.0.0:${PORTSDIR}/x11-toolkits/gtk20
By the way, taking a look at the comments in the beginning of
bsd.gnome.mk is also a good idea, as it shows you can use something like
USE_GNOME=gtk20
and be done with it.
And... Visit here:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/
(Click on 'Using GNOME')
Cheers,
Mezz
--
mezz.free...@gmail.com - m...@freebsd.org
FreeBSD GNOME Team
http://www.FreeBSD.org/gnome/ - gn...@freebsd.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
Re: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install
On Mon, 28 Mar 2011, Julien Laffaye wrote: On Mon, Mar 28, 2011 at 6:59 PM, Garrett Cooper gcoo...@freebsd.org wrote: On Mon, Mar 28, 2011 at 10:44 AM, Andriy Gapon a...@freebsd.org wrote: II. Package signing. That would be really nice. Right know we only planned to sign the repo database, so we can trust the sah256 of the packages stored in the database. Then if the package has the same sha256 as the one in the repo database it is considered trusted. If we want a per-package signing, we would have a tarball in a tarball. I really expected this to have been mentioned already, but this approach (tarball in a tarball) is taken by Debian packages, and I don't remember hearing of any issues related to it. I don't think it's worth discounting from the start without giving some considerationg, but I will defer to the people actually doing the work. -Ben Kaduk ___ 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: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install
II. Package signing. That would be really nice. Right know we only planned to sign the repo database, so we can trust the sah256 of the packages stored in the database. Then if the package has the same sha256 as the one in the repo database it is considered trusted. If we want a per-package signing, we would have a tarball in a tarball. I really expected this to have been mentioned already, but this approach (tarball in a tarball) is taken by Debian packages, and I don't remember hearing of any issues related to it. I don't think it's worth discounting from the start without giving some considerationg, but I will defer to the people actually doing the work. If you use libarchive-style streaming, it's even pretty straightforward to read and extract such things without having to create a bunch of temporary files. You just need to be careful about compression. Tim ___ 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: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install
2011/3/29 Tim Kientzle kient...@freebsd.org: II. Package signing. That would be really nice. Right know we only planned to sign the repo database, so we can trust the sah256 of the packages stored in the database. Then if the package has the same sha256 as the one in the repo database it is considered trusted. If we want a per-package signing, we would have a tarball in a tarball. I really expected this to have been mentioned already, but this approach (tarball in a tarball) is taken by Debian packages, and I don't remember hearing of any issues related to it. I don't think it's worth discounting from the start without giving some considerationg, but I will defer to the people actually doing the work. If you use libarchive-style streaming, it's even pretty straightforward to read and extract such things without having to create a bunch of temporary files. You just need to be careful about compression. Tim ok but what is the problem with signing only the repository then rely on digest? I am not sure we need more that this. second question howto sign? pgp? ssl? First would be the easiest way to go but we don't have in base anything to check signatures (maybe we should in that case investigating to import netpgp), ssl why not? but which algorithm? what security officer would prefer? We are ok to investigate that part, but we need more information about what is expected. regards, Bapt ___ 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
