Re: Let's add more DESKTOP_ENTRIES to our ports
On Wed, 19 Aug 2009 19:34:05 +0400, Dmitry Marakasov wrote I'd like to receive patch review and feedback. Also, I don't really understand what StartupNotification really is (true/false in the end of DESKTOP_ENTRY) and how to determine which is suitable for this or that port - could anyone explain? StartupNotification is telling the desktop env, that an app whose launcher was clicked by user, is currently being started up, but not ready yet, there is no window yet or so, so the desktop env could report back to the user. See here: http://library.gnome.org/devel/integration-guide/stable/startup- notification.html.en http://standards.freedesktop.org/startup-notification-spec/startup- notification-latest.txt -- Piotr Smyrak piotr.smy...@heron.pl ___ 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: Let's add more DESKTOP_ENTRIES to our ports
On 19/08/2009, Dmitry Marakasov amd...@amdmi3.ru wrote: Here's the list of ports that depend on libX11 (based on INDEX-8) and do not either have DESKTOP_ENTRIES in Makefile or share/applications/*.desktop in pkg-plist: http://people.freebsd.org/~amdmi3/desktop-needed.txt Should interactive console applications have desktop entries? For example we have console games (e.g. games/tornado), interpreters, shells; there's also irc/irssi, www/elinks and similar. How do others (e.g. pkgsrc, debian/ubuntu) handle this? ___ 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
vsftpd 2.2.0 - FTP clients (PASV) not working after upgrade from 2.1.0
Hi, all. Hopefully this is the right list; apologies if not. Wondering if anyone else has seen this or if something peculiar to my set-up. Server is i386 FreeBSD 7.2, ports upgraded with portmaster. vsftpd upgraded from 2.0.5 (or .6) to 2.1.0 no problems. Upgraded to 2.2.0 and ftp clients have started to fail - first noticed on Windows/Internet Explorer, but also OpenBSD/Firefox 3.0.x. If I try a command line line, no such issues (from the logs, the command line clients are using EPSV.) Firefox 3.5 on Mac gives me 500 OOPS: priv_sock_get_cmd Google gave me this: http://www.mail-archive.com/debian-bugs- d...@lists.debian.org/msg673507.html I crank up the logging with log_ftp_protocol=YES and I see the same behaviour as reported to the Debian list: Thu Aug 20 21:10:04 2009 [pid 73929] FTP command: Client XXX. 72.27.XXX, USER xxx Thu Aug 20 21:10:04 2009 [pid 73929] [xxx] FTP response: Client XXX.72.27.XXX, 331 Please specify the password. Thu Aug 20 21:10:04 2009 [pid 73929] [xxx] FTP command: Client XXX.72.27.XXX, PASS password Thu Aug 20 21:10:04 2009 [pid 73928] [xxx] OK LOGIN: Client XXX. 72.27.XXX Thu Aug 20 21:10:04 2009 [pid 73933] [xxx] FTP response: Client XXX.72.27.XXX, 230 Login successful. Thu Aug 20 21:10:04 2009 [pid 73933] [xxx] FTP command: Client XXX.72.27.XXX, SYST Thu Aug 20 21:10:04 2009 [pid 73933] [xxx] FTP response: Client XXX.72.27.XXX, 215 UNIX Type: L8 Thu Aug 20 21:10:04 2009 [pid 73933] [xxx] FTP command: Client XXX.72.27.XXX, PWD Thu Aug 20 21:10:04 2009 [pid 73933] [xxx] FTP response: Client XXX.72.27.XXX, 257 /usr/home/xxx Thu Aug 20 21:10:04 2009 [pid 73933] [xxx] FTP command: Client XXX.72.27.XXX, TYPE I Thu Aug 20 21:10:04 2009 [pid 73933] [xxx] FTP response: Client XXX.72.27.XXX, 200 Switching to Binary mode. Thu Aug 20 21:10:04 2009 [pid 73933] [xxx] FTP command: Client XXX.72.27.XXX, PASV ... and the log ends there (if I use an FTP command line client, there's an EPSV rather than a PASV, and things continue.) I've gone back to 2.1.0 in the meantime. Any advice, cluesticks, etc., welcomed. I appreciate there may be a lot more information required, but a yes, seen this or a no, all good here, it's something else in your configuration will help a lot at this point. 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
devel/apr: can't build after update to libtool-2.2.6a
Ports tree updated this morning.
libtool-2.2.6a is installed
stable/7 amd64
Options:
_OPTIONS_READ=apr-gdbm-db42-1.3.8.1.3.9
WITH_THREADS=true
WITHOUT_IPV6=true
WITH_GDBM=true
WITH_BDB=true
WITHOUT_NDBM=true
WITHOUT_LDAP=true
WITHOUT_MYSQL=true
WITHOUT_PGSQL=true
Build fails at configure stage.
Interesting snippets from output:
=== Configuring for apr-gdbm-db42-1.3.8.1.3.9
cd /usr/obj/ports/usr/ports/devel/apr/work/apr-1.3.8 ; /usr/bin/env CC=cc
CFLAGS=-O2 -fno-strict-aliasing -pipe -O2 -fno-strict-aliasing -pipe
-march=nocona PYTHON=/usr/local/bin/python2.6 SHELL=/bin/sh
CONFIG_SHELL=/bin/sh ACLOCAL=/usr/local/bin/aclocal-1.9
AUTOMAKE=/usr/local/bin/automake-1.9 AUTOMAKE_VERSION=19
AUTOCONF=/usr/local/bin/autoconf-2.62 AUTOHEADER=/usr/local/bin/autoheader-2.62
AUTOIFNAMES=/usr/local/bin/ifnames-2.62 AUTOM4TE=/usr/local/bin/autom4te-2.62
AUTORECONF=/usr/local/bin/autoreconf-2.62 AUTOSCAN=/usr/local/bin/autoscan-2.62
AUTOUPDATE=/usr/local/bin/autoupdate-2.62 AUTOCONF_VERSION=262
LIBTOOL=/usr/local/bin/libtool LIBTOOLIZE=/usr/local/bin/libtoolize
LIBTOOL_M4=/usr/local/share/aclocal/libtool.m4 lt_cv_sys_max_cmd_len=262144
/bin/sh ./buildconf
buildconf: checking installation...
buildconf: python version 2.6.2 (ok)
buildconf: autoconf version 2.62 (ok)
buildconf: libtool version 2.2.6 (ok)
Copying libtool helper files ...
buildconf: Using libtool.m4 at /usr/local/share/aclocal/libtool.m4.
Creating include/arch/unix/apr_private.h.in ...
configure.in:190: warning: LTOPTIONS_VERSION is m4_require'd but not m4_defun'd
build/libtool.m4:67: LT_INIT is expanded from...
build/libtool.m4:102: AC_PROG_LIBTOOL is expanded from...
configure.in:190: the top level
configure.in:190: warning: LTSUGAR_VERSION is m4_require'd but not m4_defun'd
configure.in:190: warning: LTVERSION_VERSION is m4_require'd but not m4_defun'd
configure.in:190: warning: LTOBSOLETE_VERSION is m4_require'd but not m4_defun'd
Creating configure ...
configure.in:190: warning: LTOPTIONS_VERSION is m4_require'd but not m4_defun'd
build/libtool.m4:67: LT_INIT is expanded from...
build/libtool.m4:102: AC_PROG_LIBTOOL is expanded from...
configure.in:190: the top level
configure.in:190: warning: LTSUGAR_VERSION is m4_require'd but not m4_defun'd
configure.in:190: warning: LTVERSION_VERSION is m4_require'd but not m4_defun'd
configure.in:190: warning: LTOBSOLETE_VERSION is m4_require'd but not m4_defun'd
configure:9755: error: possibly undefined macro: m4_ifval
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure:12392: error: possibly undefined macro: _LT_SET_OPTIONS
configure:12392: error: possibly undefined macro: LT_INIT
...
cd /usr/obj/ports/usr/ports/devel/apr/work/apr-1.3.8; /usr/bin/env CC=cc
CFLAGS=-O2 -fno-strict-aliasing -pipe -O2 -fno-strict-aliasing -pipe
-march=nocona PYTHON=/usr/local/bin/python2.6 SHELL=/bin/sh
CONFIG_SHELL=/bin/sh ACLOCAL=/usr/local/bin/aclocal-1.9
AUTOMAKE=/usr/local/bin/automake-1.9 AUTOMAKE_VERSION=19
AUTOCONF=/usr/local/bin/autoconf-2.62 AUTOHEADER=/usr/local/bin/autoheader-2.62
AUTOIFNAMES=/usr/local/bin/ifnames-2.62 AUTOM4TE=/usr/local/bin/autom4te-2.62
AUTORECONF=/usr/local/bin/autoreconf-2.62 AUTOSCAN=/usr/local/bin/autoscan-2.62
AUTOUPDATE=/usr/local/bin/autoupdate-2.62 AUTOCONF_VERSION=262
LIBTOOL=/usr/local/bin/libtool LIBTOOLIZE=/usr/local/bin/libtoolize
LIBTOOL_M4=/usr/local/share/aclocal/libtool.m4 lt_cv_sys_max_cmd_len=262144
/bin/sh ./configure --prefix=/usr/local ${_LATE_CONFIGURE_ARGS}
--with-installbuilddir=/usr/local/share/apr/build-1 --enable-threads
--disable-ipv6
...
performing libtool configuration...
./configure: 9753: Syntax error: word unexpected (expecting ))
*** Error code 2
Looking into the file I see a snippet in non-shell syntax:
Xsed=$SED -e 1s/^X//
lt_if_append_uniq(lt_decl_varnames, SED, , ,
lt_dict_add_subkey([lt_decl_dict], [SED], [libtool_name],
[m4_ifval([], [], [SED])])
lt_dict_add_subkey([lt_decl_dict], [SED], [value], [1])
m4_ifval([A sed program that does not truncate output],
[lt_dict_add_subkey([lt_decl_dict], [SED], [description], [A sed program
that does not truncate output])])
lt_dict_add_subkey([lt_decl_dict], [SED],
[tagged?], [m4_ifval([], [yes], [no])]))
lt_if_append_uniq(lt_decl_varnames, Xsed, , ,
lt_dict_add_subkey([lt_decl_dict], [Xsed], [libtool_name],
[m4_ifval([], [], [Xsed])])
lt_dict_add_subkey([lt_decl_dict], [Xsed], [value], [\$SED -e 1s/^X//])
m4_ifval([Sed that helps us avoid accidentally triggering echo(1) options
like
-n],
[lt_dict_add_subkey([lt_decl_dict], [Xsed], [description], [Sed that
helps
us avoid accidentally triggering echo(1) options like -n])])
lt_dict_add_subkey([lt_decl_dict], [Xsed],
[tagged?], [m4_ifval([], [yes], [no])]))
--
Andriy Gapon
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To
Re: devel/apr: can't build after update to libtool-2.2.6a
It seems that the problem is caused by arp carrying its own libtool-related bits and those bits being incompatible with libtool-2.2.6a. For me, I resolved the problem by copying /usr/local/share/aclocal/ltoptions.m4 /usr/local/share/aclocal/ltsugar.m4 /usr/local/share/aclocal/ltversion.m4 /usr/local/share/aclocal/lt~obsolete.m4 to work/apr-1.3.8/build And /usr/local/bin/libtool to work/apr-1.3.8 But maybe the problem could have been resolved by requiring the previous version of libtool for this particular port. -- 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: Migration to new SourceForge url scheme now inevitable, solution
* Philip M. Gollucci (pgollu...@p6m7g8.com) wrote: Rewriting this: my $portname = `make -VPORTNAME`; chomp $portname; my $portname_lc = lc($portname); my $portversion = `make -VPORTVERSION`; chomp $portversion; Like this, will help substantially by reducing make spawns by 1/2, you'll notice the ports tinderbox code does this too :) True, but that's actually 1/3, and I think make fetch-url-list still takes most the time. Also, I've discovered that the script skipped ports that used DIST_SUBDIR (make fetch-url-list needs to be able to create subdirs), now fixed, script and data reuploaded. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: apr-gdbm-db42 upgrade conflicting with libtool
Troy wrote: David Southwell wrote: Troy wrote: Updated all ports to python 26 and the problem still exists: pkg_info|grep py boost-python-libs-1.39.0 Framework for interfacing Python and C++ p5-Clone-0.31 Clone - recursively copy Perl datatypes py26-dbus-0.83.0_1 Python bindings for the D-BUS messaging system py26-elementtree-1.2.6_1 Container for hierarchical data structures written in Pytho py26-sip-4.8.2,1Python to C and C++ bindings generator py26-xml-0.8.4_2PyXML: Python XML library enhancements python26-2.6.2_1An interpreted object-oriented programming language ruby18-bdb-0.6.5_1 Ruby interface to Sleepycat's Berkeley DB revision 2 or lat xdpyinfo-1.0.3 Display information utility for X checking for stdint.h... yes checking for unistd.h... yes checking minix/config.h usability... no checking minix/config.h presence... no checking for minix/config.h... no checking whether it is safe to define __EXTENSIONS__... yes checking for library containing strerror... none required checking whether system uses EBCDIC... no performing libtool configuration... ./configure: 9753: Syntax error: word unexpected (expecting )) *** Error code 2 Stop in /usr/ports/devel/apr. *** Error code 1 Stop in /usr/ports/devel/apr. *** Error code 1 Stop in /usr/ports/devel/apr. ** Command failed [exit code 1]: /usr/bin/script -qa /tmp/portinstall20090810-73192-8x2jso-0 env make reinstall ** Fix the installation problem and try again. ** Listing the failed packages (-:ignored / *:skipped / !:failed) ! devel/apr (install error) FreeBSD somedomain 7.2-STABLE FreeBSD 7.2-STABLE #0: Sat May 23 10:45:33 CDT 2009 some...@domain /usr/obj/usr/src/sys/kernel amd64 Any thoughts? -Troy ___ 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 Just to add to this the following warnings came up when trying to build apr. I also deinstalled libtool and it installs just fine. I also researched these errors and someone said it was related to gettext. I reinstalled it just to be safe and still it did not change the outcome. Copying libtool helper files ... buildconf: Using libtool.m4 at /usr/local/share/aclocal/libtool.m4. Creating include/arch/unix/apr_private.h.in ... configure.in:190: warning: LTOPTIONS_VERSION is m4_require'd but not m4_defun'd build/libtool.m4:67: LT_INIT is expanded from... build/libtool.m4:102: AC_PROG_LIBTOOL is expanded from... configure.in:190: the top level configure.in:190: warning: LTSUGAR_VERSION is m4_require'd but not m4_defun'd configure.in:190: warning: LTVERSION_VERSION is m4_require'd but not m4_defun'd configure.in:190: warning: LTOBSOLETE_VERSION is m4_require'd but not m4_defun'd Creating configure ... configure.in:190: warning: LTOPTIONS_VERSION is m4_require'd but not m4_defun'd build/libtool.m4:67: LT_INIT is expanded from... build/libtool.m4:102: AC_PROG_LIBTOOL is expanded from... configure.in:190: the top level configure.in:190: warning: LTSUGAR_VERSION is m4_require'd but not m4_defun'd configure.in:190: warning: LTVERSION_VERSION is m4_require'd but not m4_defun'd configure.in:190: warning: LTOBSOLETE_VERSION is m4_require'd but not m4_defun'd configure:9755: error: possibly undefined macro: m4_ifval If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure:12392: error: possibly undefined macro: _LT_SET_OPTIONS configure:12392: error: possibly undefined macro: LT_INIT did you apply the following in updating?? 20090608: AFFECTS: users of lang/python* and py-* AUTHOR: m...@freebsd.org The default version of Python has been changed from 2.5.x to 2.6.x. If you have 2.5.x installed, perform an upgrade of lang/python25 to lang/python26 with one of the following commands: If using portupgrade: # portupgrade -o lang/python26 lang/python25 If using portmaster: # portmaster -o lang/python26 lang/python25 If you want to retain 2.5.x as default Python version, set the PYTHON_DEFAULT_VERSION variable to 'python2.5' (without quotes) in /etc/make.conf, then go to lang/python and perform the following command: # portupgrade -R python Once the installed Python has been updated to 2.6, by using the method above, it is required to run the upgrade-site-packages target in lang/python to assure that site-packages are made available to the new Python version. If using portupgrade: # cd /usr/ports/lang/python make upgrade-site-packages If using portmaster: # cd /usr/ports/lang/python make upgrade-site-packages -DUSE_PORTMASTER The portmaster case can
pulseaudio build error (curious/strange)
... /bin/sh /usr/obj/ports/usr/ports/audio/pulseaudio/work/gnome-libtool --tag=CC --mode=compile cc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I/usr/local/include -I../src -I../src -I../src/modules -I../src/modules -I../src/modules/rtp -I../src/modules/rtp -I../src/modules/gconf -I../src/modules/gconf -I../src/modules/bluetooth -I../src/modules/bluetooth -I../src/modules/alsa -I../src/modules/alsa -I../src/modules/raop -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS -I/usr/local/include -I/usr/local/include -I/usr/local/include -DPA_DLSEARCHPATH=\/usr/local/lib/pulse-0.9.15/modules/\ -DPA_DEFAULT_CONFIG_DIR=\/usr/local/etc/pulse\ -DPA_BINARY=\/usr/local/bin/pulseaudio\ -DPA_SYSTEM_RUNTIME_PATH=\/var/run/pulse\ -DPA_SYSTEM_CONFIG_PATH=\/var/lib/pulse\ -DPA_SYSTEM_STATE_PATH=\/var/lib/pulse\ -DAO_REQUIRE_CAS -DPULSE_LOCALEDIR=\/usr/local/share/locale\ -DPA_MACHINE_ID=\/var/lib/dbus/machine-id\ -O2 -fno-strict-aliasing -pipe -O2 -fno-strict-aliasing -pipe -march=nocona -Wall -W -Wextra -pipe -Wno-long-long -Winline -Wno-overlength-strings -Wunsafe-loop-optimizations -Wundef -Wformat=2 -Wsign-compare -Wformat-security -Wformat-nonliteral -Wold-style-definition -Wpointer-arith -Winit-self -Wdeclaration-after-statement -Wfloat-equal -Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls -Wmissing-declarations -Wmissing-noreturn -Wshadow -Wendif-labels -Wcast-align -Wstrict-aliasing=2 -Wwrite-strings -Wno-unused-parameter -ffast-math -Wp,-D_FORTIFY_SOURCE=2 -fno-common -fdiagnostics-show-option -MT module-raop-sink.lo -MD -MP -MF .deps/module-raop-sink.Tpo -c -o module-raop-sink.lo `test -f 'modules/module-raop-sink.c' || echo './'`modules/module-raop-sink.c gnome-libtool: compile: cc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I/usr/local/include -I../src -I../src -I../src/modules -I../src/modules -I../src/modules/rtp -I../src/modules/rtp -I../src/modules/gconf -I../src/modules/gconf -I../src/modules/bluetooth -I../src/modules/bluetooth -I../src/modules/alsa -I../src/modules/alsa -I../src/modules/raop -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS -I/usr/local/include -I/usr/local/include -I/usr/local/include -DPA_DLSEARCHPATH=\/usr/local/lib/pulse-0.9.15/modules/\ -DPA_DEFAULT_CONFIG_DIR=\/usr/local/etc/pulse\ -DPA_BINARY=\/usr/local/bin/pulseaudio\ -DPA_SYSTEM_RUNTIME_PATH=\/var/run/pulse\ -DPA_SYSTEM_CONFIG_PATH=\/var/lib/pulse\ -DPA_SYSTEM_STATE_PATH=\/var/lib/pulse\ -DAO_REQUIRE_CAS -DPULSE_LOCALEDIR=\/usr/local/share/locale\ -DPA_MACHINE_ID=\/var/lib/dbus/machine-id\ -O2 -fno-strict-aliasing -pipe -O2 -fno-strict-aliasing -pipe -march=nocona -Wall -W -Wextra -pipe -Wno-long-long -Winline -Wno-overlength-strings -Wunsafe-loop-optimizations -Wundef -Wformat=2 -Wsign-compare -Wformat-security -Wformat-nonliteral -Wold-style-definition -Wpointer-arith -Winit-self -Wdeclaration-after-statement -Wfloat-equal -Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls -Wmissing-declarations -Wmissing-noreturn -Wshadow -Wendif-labels -Wcast-align -Wstrict-aliasing=2 -Wwrite-strings -Wno-unused-parameter -ffast-math -Wp,-D_FORTIFY_SOURCE=2 -fno-common -fdiagnostics-show-option -MT module-raop-sink.lo -MD -MP -MF .deps/module-raop-sink.Tpo -c modules/module-raop-sink.c -fPIC -DPIC -o .libs/module-raop-sink.o In file included from /usr/local/include/sdp.h:26, from modules/module-raop-sink.c:65: /usr/local/include/mpeg4ip.h:126: warning: redundant redeclaration of 'strcasestr' [-Wredundant-decls] /usr/include/string.h:72: warning: previous declaration of 'strcasestr' was here modules/module-raop-sink.c: In function 'module_raop_sink_LTX_pa__get_version': modules/module-raop-sink.c:71: error: 'PACKAGE_VERSION' undeclared (first use in this function) modules/module-raop-sink.c:71: error: (Each undeclared identifier is reported only once modules/module-raop-sink.c:71: error: for each function it appears in.) The thing is that PACKAGE_VERSION is actually defined in config.h. But there is something strange/curios. module-raop-sink.c includes /usr/local/include/sdp.h that in turn includes /usr/local/include/mpeg4ip.h. mpeg4ip.h has the following code: #ifndef _WIN32 #ifdef PACKAGE_BUGREPORT #define TEMP_PACKAGE_BUGREPORT PACKAGE_BUGREPORT #define TEMP_PACKAGE_NAME PACKAGE_NAME #define TEMP_PACKAGE_STRING PACKAGE_STRING #define TEMP_PACKAGE_TARNAME PACKAGE_TARNAME #define TEMP_PACKAGE_VERSION PACKAGE_VERSION #undef PACKAGE_BUGREPORT #undef PACKAGE_NAME #undef PACKAGE_STRING #undef PACKAGE_TARNAME #undef PACKAGE_VERSION #include mpeg4ip_config.h #undef PACKAGE_BUGREPORT #undef PACKAGE_NAME #undef PACKAGE_STRING #undef PACKAGE_TARNAME #undef PACKAGE_VERSION #define PACKAGE_BUGREPORT TEMP_PACKAGE_BUGREPORT #define PACKAGE_NAME TEMP_PACKAGE_NAME #define PACKAGE_STRING TEMP_PACKAGE_STRING #define PACKAGE_TARNAME TEMP_PACKAGE_TARNAME #define PACKAGE_VERSION TEMP_PACKAGE_VERSION #else #include mpeg4ip_config.h #endif #endif In our case PACKAGE_BUGREPORT is actually defined (in config.h). So this whole block is
Re: Migration to new SourceForge url scheme now inevitable, solution
--On Wednesday, August 19, 2009 23:08:04 -0500 Philip M. Gollucci pgollu...@p6m7g8.com wrote: Dmitry Marakasov wrote: [1] http://people.freebsd.org/~amdmi3/sf.pl.txt Awesome. Rewriting this: my $portname = `make -VPORTNAME`; chomp $portname; my $portname_lc = lc($portname); my $portversion = `make -VPORTVERSION`; chomp $portversion; Like this, will help substantially by reducing make spawns by 1/2, you'll notice the ports tinderbox code does this too :) my @lines = lc `make -V PORTNAME -V PORTVERSION`; my $portname = $lines[0]; chomp $portname; my $portversion = $lines[1]; chomp $portversion; (untested) [2] http://people.freebsd.org/~amdmi3/sourceforge-subdirs.txt [3] http://people.freebsd.org/~amdmi3/sourceforge-subdirs-top.txt I've been following this discussion closely since several of my ports fetch from Sourceforge. Is it safe to assume that some global solution will be applied to the ports tree? Or are we maintainers going to need to submit PRs for affected ports once a solution is agreed upon? -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead. Thomas Jefferson ___ 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
webkit-gtk2 vs libtool-2.2.6a
webkit-gtk2 fails to build after libtool-2.2.6a update. Auto tools provide some helpful self diagnostics: === Configuring for webkit-gtk2-1.0.1_8 /usr/local/share/aclocal/smpeg.m4:13: warning: underquoted definition of AM_PATH_SMPEG /usr/local/share/aclocal/smpeg.m4:13: run info '(automake)Extending aclocal' /usr/local/share/aclocal/smpeg.m4:13: or see http://sources.redhat.com/automake/automake.html#Extending-aclocal configure.ac:70: warning: AC_CACHE_VAL(lt_prog_compiler_pic_works, ...): suspicious cache-id, must contain _cv_ to be cached [many more like that] ... libtoolize: putting auxiliary files in `.'. libtoolize: linking file `./ltmain.sh' libtoolize: You should add the contents of the following files to `aclocal.m4': libtoolize: `/usr/local/share/aclocal/libtool.m4' libtoolize: `/usr/local/share/aclocal/ltversion.m4' libtoolize: `/usr/local/share/aclocal/ltsugar.m4' libtoolize: `/usr/local/share/aclocal/lt~obsolete.m4' libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree. libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am. ... checking dependency style of c++... gcc3 checking for a BSD-compatible install... /usr/bin/install -c -o root -g wheel ./configure: 4727: Syntax error: word unexpected (expecting )) === Script configure failed unexpectedly. Failing line is _LT_DECL one below: === fi _LT_DECL(build_old_libs, enable_static, 0, Whether or not to build static libraries) enable_win32_dll=yes === Apparently this is not poper shell syntax. I made the port compile by hacking autogen.sh to add the following lines: cat /usr/local/share/aclocal/lt[o-v~]* aclocal.m4 cat /usr/local/share/aclocal/libtool.m4 aclocal.m4 -- 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: Migration to new SourceForge url scheme now inevitable, solution
* Paul Schmehl (pschmehl_li...@tx.rr.com) wrote: I've been following this discussion closely since several of my ports fetch from Sourceforge. Is it safe to assume that some global solution will be applied to the ports tree? Or are we maintainers going to need to submit PRs for affected ports once a solution is agreed upon? This should be done globally, or else we'll end up with 90% unfetchable SF ports for 8.0 release. I'm preparing the patch currently. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: devel/apr: can't build after update to libtool-2.2.6a
Am 20.08.2009, 13:32 Uhr, schrieb Andriy Gapon a...@icyb.net.ua: It seems that the problem is caused by arp carrying its own libtool-related bits and those bits being incompatible with libtool-2.2.6a. For me, I resolved the problem by copying /usr/local/share/aclocal/ltoptions.m4 /usr/local/share/aclocal/ltsugar.m4 /usr/local/share/aclocal/ltversion.m4 /usr/local/share/aclocal/lt~obsolete.m4 to work/apr-1.3.8/build And /usr/local/bin/libtool to work/apr-1.3.8 But maybe the problem could have been resolved by requiring the previous version of libtool for this particular port. This isn't sufficient on my system, because then the apr-util still fails. Note that there is no previous libtool version that Philip's port could require. -- Matthias Andree ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: devel/apr: can't build after update to libtool-2.2.6a
on 20/08/2009 19:50 Matthias Andree said the following: This isn't sufficient on my system, because then the apr-util still fails. Note that there is no previous libtool version that Philip's port could require. Could you please try also the following? cp /usr/local/share/libtool/config/ltmain.sh build/ltmain.sh -- 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: Migration to new SourceForge url scheme now inevitable, solution
Dmitry Marakasov píše v čt 20. 08. 2009 v 20:40 +0400: * Paul Schmehl (pschmehl_li...@tx.rr.com) wrote: I've been following this discussion closely since several of my ports fetch from Sourceforge. Is it safe to assume that some global solution will be applied to the ports tree? Or are we maintainers going to need to submit PRs for affected ports once a solution is agreed upon? This should be done globally, or else we'll end up with 90% unfetchable SF ports for 8.0 release. I'm preparing the patch currently. Once you have a patch, send it over for eyeball-review and approval. Thanks for attacking this! -- Pav Lucistnik p...@oook.cz p...@freebsd.org 42.7 percent of all statistics are made up on the spot. signature.asc Description: Toto je digitálně podepsaná část zprávy
xine failure during linking on FreeBSD 7.2
ports/multimedia/libxine Somehow links against a lib in its own source directory. Unresolvable link(s) found in: /usr/local/bin/xine-list-1.1 ../src/xine-engine/.libs/libxine.so Is there another way of getting around this problem ? -- Jason J. Hellenthal +1.616.403.8065 jas...@dataix.net ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: devel/apr: can't build after update to libtool-2.2.6a
Andriy Gapon wrote: It seems that the problem is caused by arp carrying its own libtool-related bits and those bits being incompatible with libtool-2.2.6a. For me, I resolved the problem by copying /usr/local/share/aclocal/ltoptions.m4 /usr/local/share/aclocal/ltsugar.m4 /usr/local/share/aclocal/ltversion.m4 /usr/local/share/aclocal/lt~obsolete.m4 to work/apr-1.3.8/build And /usr/local/bin/libtool to work/apr-1.3.8 But maybe the problem could have been resolved by requiring the previous version of libtool for this particular port. Andriy, We solved the problem for me. Please read the following: http://www.freebsd.org/cgi/query-pr.cgi?pr=137843 Check to see if you have /usr/local/bin/libtool15 /usr/local/bin/libtoolize15 /usr/local/share/libtool15 I found I had those files/directories even after upgrading the libtool 1.5 package to the latest one in ports. Deleting them let the apr build complete. ___ 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: Migration to new SourceForge url scheme now inevitable, solution
* Pav Lucistnik (p...@freebsd.org) wrote:
I've been following this discussion closely since several of my ports
fetch
from Sourceforge. Is it safe to assume that some global solution will be
applied to the ports tree? Or are we maintainers going to need to submit
PRs
for affected ports once a solution is agreed upon?
This should be done globally, or else we'll end up with 90% unfetchable
SF ports for 8.0 release. I'm preparing the patch currently.
Once you have a patch, send it over for eyeball-review and approval.
Thanks for attacking this!
Automated run is done, patch is here: [1]. It's not the final
version, as it turned out to be more complex as I thought. There
are things like SF:foo SF:bar (we can do this, right?), and
${MASTER_SITE_SOURECFORGE:C/$/:foo}, which should be fixed manually.
Also there are slave ports, for masters of which you don't want to
substitude ${PORTNAME} in some cases. There's a log [2] which lists
potential issues. Tomorrow I'll look them through and manually fix
remaining ports, run a quick fetchability test and present a final
patch.
[1] http://people.freebsd.org/~amdmi3/sfp.patch
[2] http://people.freebsd.org/~amdmi3/sfp.log
PS. Btw, SOURCEFORGE_EXTENDED and SOURCEFORGE_JP still use an old
scheme. Because of that SFE can no longer include SF, and honestly, I
would like it to go away, as there are more than enough official SF
mirrors. Also need to check if our SF mirror list can be extended with
more mirrors, last time I had that `select mirrors' screen on
sourceforge it looked like there are much more mirrors than we have.
--
Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D
amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru
___
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
INDEX build failed for 6.x
INDEX build failed with errors: Generating INDEX-6 - please wait..pkg_info: not found pkg_info: not found Done. make_index: psptoolchain-newlib-1.15.0: no entry for /usr/ports/devel/psptoolchain-pspsdk-stage1 make_index: psptoolchain-gdb-6.4: no entry for /usr/ports/devel/psptoolchain-pspsdk-stage2 Committers on the hook: araujo clsung Most recent CVS update was: U devel/Makefile U devel/psptoolchain/Makefile U devel/psptoolchain/pkg-descr U devel/psptoolchain-binutils/Makefile U devel/psptoolchain-binutils/distinfo U devel/psptoolchain-binutils/pkg-descr U devel/psptoolchain-binutils/pkg-plist U devel/psptoolchain-binutils/files/patch-bfd-Makefile.am U devel/psptoolchain-binutils/files/patch-bfd-Makefile.in U devel/psptoolchain-binutils/files/patch-bfd-archures.c U devel/psptoolchain-binutils/files/patch-bfd-bfd-in2.h U devel/psptoolchain-binutils/files/patch-bfd-configure U devel/psptoolchain-binutils/files/patch-bfd-cpu-mips.c U devel/psptoolchain-binutils/files/patch-bfd-elfxx-mips.c U devel/psptoolchain-binutils/files/patch-bfd-version.h U devel/psptoolchain-binutils/files/patch-binutils-readelf.c U devel/psptoolchain-binutils/files/patch-config.sub U devel/psptoolchain-binutils/files/patch-configure U devel/psptoolchain-binutils/files/patch-gas-config-tc-mips.c U devel/psptoolchain-binutils/files/patch-gas-configure U devel/psptoolchain-binutils/files/patch-gas-configure.in U devel/psptoolchain-binutils/files/patch-gas-testsuite-gas-mips-mips.exp U devel/psptoolchain-binutils/files/patch-include-bin-bugs.h U devel/psptoolchain-binutils/files/patch-include-elf-common.h U devel/psptoolchain-binutils/files/patch-include-elf-mips.h U devel/psptoolchain-binutils/files/patch-include-opcode-mips.h U devel/psptoolchain-binutils/files/patch-include-opcode-vfpu.h U devel/psptoolchain-binutils/files/patch-ld-Makefile.am U devel/psptoolchain-binutils/files/patch-ld-Makefile.in U devel/psptoolchain-binutils/files/patch-ld-configure.tgt U devel/psptoolchain-binutils/files/patch-ld-emulparams-elf_mipsallegrexel_psp.sh U devel/psptoolchain-binutils/files/patch-ld-scripttempl-elf_psp.sc U devel/psptoolchain-binutils/files/patch-opcodes-configure U devel/psptoolchain-binutils/files/patch-opcodes-mips-dis.c U devel/psptoolchain-binutils/files/patch-opcodes-mips-opc.c U devel/psptoolchain-gcc-stage1/Makefile U devel/psptoolchain-gcc-stage1/distinfo U devel/psptoolchain-gcc-stage1/pkg-descr U devel/psptoolchain-gcc-stage1/pkg-plist U devel/psptoolchain-gcc-stage1/files/patch-config.sub U devel/psptoolchain-gcc-stage1/files/patch-gcc-c-incpath.c U devel/psptoolchain-gcc-stage1/files/patch-gcc-config-mips-allegrex.md U devel/psptoolchain-gcc-stage1/files/patch-gcc-config-mips-mips.c U devel/psptoolchain-gcc-stage1/files/patch-gcc-config-mips-mips.h U devel/psptoolchain-gcc-stage1/files/patch-gcc-config-mips-mips.md U devel/psptoolchain-gcc-stage1/files/patch-gcc-config-mips-psp.h U devel/psptoolchain-gcc-stage1/files/patch-gcc-config-mips-t-allegrex U devel/psptoolchain-gcc-stage1/files/patch-gcc-config.gcc U devel/psptoolchain-gcc-stage1/files/patch-gcc-version.c U devel/psptoolchain-gcc-stage2/Makefile U devel/psptoolchain-gcc-stage2/pkg-plist U devel/psptoolchain-gdb/Makefile U devel/psptoolchain-gdb/distinfo U devel/psptoolchain-gdb/pkg-descr U devel/psptoolchain-gdb/pkg-plist U devel/psptoolchain-gdb/files/patch-bfd-archures.c U devel/psptoolchain-gdb/files/patch-bfd-bfd-in2.h U devel/psptoolchain-gdb/files/patch-bfd-cpu-mips.c U devel/psptoolchain-gdb/files/patch-bfd-elfxx-mips.c U devel/psptoolchain-gdb/files/patch-config.sub U devel/psptoolchain-gdb/files/patch-gdb-remote.c U devel/psptoolchain-gdb/files/patch-include-bin-bugs.h U devel/psptoolchain-gdb/files/patch-include-elf-common.h U devel/psptoolchain-gdb/files/patch-include-elf-mips.h U devel/psptoolchain-gdb/files/patch-include-opcode-mips.h U devel/psptoolchain-gdb/files/patch-opcodes-mips-dis.c U devel/psptoolchain-gdb/files/patch-opcodes-mips-opc.c U devel/psptoolchain-newlib/Makefile U devel/psptoolchain-newlib/distinfo U devel/psptoolchain-newlib/pkg-descr U devel/psptoolchain-newlib/pkg-plist U devel/psptoolchain-newlib/files/patch-config.sub U devel/psptoolchain-newlib/files/patch-configure U devel/psptoolchain-newlib/files/patch-configure.in U devel/psptoolchain-newlib/files/patch-newlib-Makefile.am U devel/psptoolchain-newlib/files/patch-newlib-Makefile.in U devel/psptoolchain-newlib/files/patch-newlib-configure.host U devel/psptoolchain-newlib/files/patch-newlib-libc-include-machine-time.h U devel/psptoolchain-newlib/files/patch-newlib-libc-include-sys-config.h U devel/psptoolchain-newlib/files/patch-newlib-libc-include-sys-types.h U devel/psptoolchain-newlib/files/patch-newlib-libc-include-time.h U devel/psptoolchain-newlib/files/patch-newlib-libc-sys-configure U devel/psptoolchain-newlib/files/patch-newlib-libc-sys-configure.in U devel/psptoolchain-newlib/files/patch-newlib-libc-sys-psp-Makefile.am U
Re: portmaster is not always recursive
Woo hoo! I found the bug, and fixed it in the just-committed version 2.10. The bug was in the NO_DEP_UPDATES flag which is one of the oldest features of portmaster. It operates in the first pass through the dependencies (aka config mode) and if all of the dependent ports are up to date it allows the second pass (build mode) to skip the dependency check(s) altogether. When I first added this feature (prior to the use of variables to store information on up to date ports/dependencies) this was a great time saver. It's not that important anymore given that dependency checks are so much faster, but it still helps some (especially if you are building/installing a lot of ports) and it has been overloaded a bit for other purposes. Unfortunately it didn't quite keep up with the times when some code paths were added (such as -r and the new code to do multiple ports on the same command line) and it was not always being unset when it should have been. The more common code paths (one port on the command line, or -a) didn't have this problem, which along with the fact that it only happened with certain combinations of out of date dependencies is why the bug went undiagnosed for so long. Ironically the flag was also being UNset at times when it should not have been (for similar, although somewhat different reasons) so in cases where you are building a list of ports (like multiple ports on the command line or -r) and all of the dependencies are up to date there will be a slight performance improvement. This side of the bug would never have been noticed by users since it only resulted in some unnecessary dependency checking. FWIW there is one more small performance improvement in 2.10 for building multiple ports on the command line, although the percentage of performance increase is probably quite small. Thanks Miroslav for providing all of the information you did which was a big help in allowing me to narrow down where the bug was _not_ which ultimately allowed me to find out where it was. :) Doug -- This .signature sanitized for your protection ___ 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: Let's add more DESKTOP_ENTRIES to our ports
Dmitry Marakasov amd...@amdmi3.ru writes:
To make adding DESKTOP_ENTRIES simple and fun, here's a script called
de which outputs a template for desktop entry when run from port's
directory:
--- de begins here ---
#!/bin/sh
echo DESKTOP_ENTRIES=\`make -V PORTNAME`\ \\
echo \`make -V COMMENT`\ \\
echo \\${DATADIR}/\ \\
echo \`make -V PORTNAME`\ \\
echo \`make -V CATEGORIES | tr ' ' ';' | sed 's|$|;|' | sed
's|games|game|'`\ \\
echo false
--- de ends here ---
Don't you need to run update-desktop-database during post-install?
It's not like using DESKTOPDIR or DESKTOP_ENTRIES adds appropriate
@exec/@unexec in plist for you.
if you use vim, just type !!de while editing port's makefile, and
it'll add template for you, which will require only a little editing:
- change app name in the first line for proper spacing and case
(i.e. brainworkshop - Brain Workshop)
- possibly simplify description in the second line (while leaving it
equal to COMMENT is generally good enough)
- Change icon path (some ports install icons into ${DATADIR},
I think such ports should be fixed to install icons into share/pixmaps.
some (this likely only applies to games) have graphic sprites
useable as icons, for others just list leave = no icon.
Can I use icons from dependency ports for ports that don't have icons
themselves, e.g. icons from audio/xmms2 for audio/gx2osd?
share/pixmaps/xmms2-128.png
share/pixmaps/xmms2-16.png
share/pixmaps/xmms2-32.png
share/pixmaps/xmms2-48.png
share/pixmaps/xmms2-black-on-white.svg
share/pixmaps/xmms2-white-on-black.svg
share/pixmaps/xmms2.svg
DESKTOP_ENTRIES=gx2osd \
On-screen display of current playing song for XMMS2 \
xmms2 \
gx2osd \
Audio;Player; \
false
- Fix categories. Full list here:
http://standards.freedesktop.org/menu-spec/latest/apa.html
___
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
