pkgng: How to prevent autoremoval during pkg delete ?
Hi. Is there a way to tell pkg delete to just remove the package(s) listed on the command line, instead of automatically removing depending packages ? MfG CoCo ___ 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"
Choosing a port category for a new port
Hi, I've create a port for authbind, and am unsure which category or categories to pick for it. [pkg-desc] Authbind allows a program which does not or should not run as root to bind to low-numbered ports in a controlled way. In most cases, you will probably want to use mac_portacl(4) instead of authbind. WWW: http://www.chiark.greenend.org.uk/ucgi/~ian/git/authbind.git/ [pkg-desc] My current choice of categories would be: CATEGORY= net security What's the lists opinion on the main category and eventual secondary categories for this new port ? MfG CoCo ___ 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: How can I override global OPTIONS_UNSET for specific port in make.conf? www/xcache
Baptiste Daroussin wrote on 22.06.2014 12:03:
On Thu, Jun 19, 2014 at 11:49:29PM +0200, Marco Steinbach wrote:
Miroslav Lachman schrieb:
I don't need DOCS, EXAMPLES etc. for each port as I normaly do not use
them on servers.
I have this line in make.conf
OPTIONS_UNSET= X11 GUI CUPS DOCS EXAMPLES NLS
Now I need www/xcache port installed with EXAMPLES.
I tried following in make.conf:
xcache_SET= EXAMPLES
or
xcache_SET_FORCE= EXAMPLES
In both cases, xcache is installed without EXAMPLES.
So how can I have globally disabled EXAMPLES and enable it only for one
specific port?
After some testing, I think this could be a bug in the handling of
PORTEXAMPLES / PORTDOCS, since flipping EXAMPLES / DOCS options (and any
other options I tried) with these switches works as expected.
I'll try and have a go at this.
The port should just add EXAMPLES to OPTIONS_DEFINE otherwise the framework is
not entierly followed, if maintainer adds EXAMPLES then a simple
xcache_SET= EXAMPLES or www_xcache_SET= EXAMPLES
will just works.
That is why all DOCS, NLS, EXAMPLES etc should not anymore be hidden.
regards,
Bapt
The current handling, while working as designed, leads to confusing results.
I'll illustrate this for www/xcache:
Does install EXAMPLES:
OPTIONS_SET_FORCE=EXAMPLES
Does install EXAMPLES:
www_xcache_SET_FORCE=EXAMPLES
But this one does not install examples:
OPTIONS_UNSET_FORCE=EXAMPLES
www_xcache_SET_FORCE=EXAMPLES
The first two install EXAMPLES rather by accident, while the last one
doesn't, because it prevents the accident from happening, but promptly
ends up in a different one.
While I'd also prefer maintainers to fix their options, the current
behaviour leads to users trying to access the ports systems internals
for working around this, instead of using the interfaces OPTIONSng provides.
I think that's what my attached patch is mainly about. Prevent users
from introducing more complexity into their world, by keeping it in the
ports framework, instead of exposing them to the current deficiencies of
some 1700 [1] ports.
If we can agree on an approach, I'm first in line to volunteer for
fixing these ports. But that doesn't mean, I wouldn't want my patch to
be commited, of course :)
MfG CoCo
[1] Quick scan of the ports tree:
Ports that are using PORTEXAMPLES / PORTDOCS, but either don't have port
options at all, or just not for DOCS / EXAMPLES: ~1700 -- and I'm
reasonably sure, that this is not too far from the correct numbers.
Index: Mk/bsd.options.mk
===
--- Mk/bsd.options.mk (revision 358740)
+++ Mk/bsd.options.mk (working copy)
@@ -196,6 +196,15 @@
# complete list
COMPLETE_OPTIONS_LIST= ${ALL_OPTIONS}
+
+# Handle ports that are using PORTDOCS / PORTEXAMPLES, but do not provide
+# EXAMPLES / DOCS options
+.for m in DOCS EXAMPLES
+. if !empty(PORT_OPTIONS:M${m}) && empty(COMPLETE_OPTIONS_LIST:M${m})
+COMPLETE_OPTIONS_LIST+=${m}
+. endif
+.endfor
+
.for otype in SINGLE RADIO MULTI GROUP
. for m in ${OPTIONS_${otype}}
COMPLETE_OPTIONS_LIST+=${OPTIONS_${otype}_${m}}
___
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: How can I override global OPTIONS_UNSET for specific port in make.conf? www/xcache
Marco Steinbach wrote on 20.06.2014 02:06:
Marco Steinbach wrote on 19.06.2014 23:49:
Miroslav Lachman schrieb:
I don't need DOCS, EXAMPLES etc. for each port as I normaly do not
use them on servers.
I have this line in make.conf
OPTIONS_UNSET= X11 GUI CUPS DOCS EXAMPLES NLS
Now I need www/xcache port installed with EXAMPLES.
I tried following in make.conf:
xcache_SET= EXAMPLES
or
xcache_SET_FORCE= EXAMPLES
In both cases, xcache is installed without EXAMPLES.
So how can I have globally disabled EXAMPLES and enable it only for
one specific port?
After some testing, I think this could be a bug in the handling of
PORTEXAMPLES / PORTDOCS, since flipping EXAMPLES / DOCS options (and
any other options I tried) with these switches works as expected.
I'll try and have a go at this.
[...]
If a port does not explicitly define an option for a feature in its
Makefile, then a port specific setting for that option has no effect,
since it simply doesn't match against the options defined in the ports
Makefile.
IOW: If a port does not explicity define an EXAMPLES option, then a port
specific SET or UNSET for the EXAMPLES option in /etc/make.conf has no
effect.
Consequently, in the case of www/xcache, simply adding a dummy EXAMPLE
option to OPTIONS_DEFINE makes xcache_SET_FORCE=EXAMPLES work as
expected: It installs examples, overriding OPTIONS_UNSET_FORCE.
Depending on ones point of view, one could say, that this works as
advertised. But it's confusing and robs us of port specific _FORCE
flags in certain cases.
One possible solution could be, to have Mk/bsd.options.mk detect the use
of PORTEXAMPLES and PORTDOCS in a port, and then silently translate
these into DOCS / EXAMPLES options (adding them to
${COMPLETE_OPTIONS_LIST}), if they're not present.
Without them popping up in a dialog, since that would be the maintainers
domain, and without persisting them, of course.
I'm still trying to wrap my head around these parts of the ports system,
though, in order to not accidentially break things.
MfG CoCo
PS: I'm taking bapt@ out of the loop again, until we're either
completely stuck or are able to produce a patch.
I think I found a more simple way to do this. Could you please try the
attached patch ?
Thanks.
MfG CoCo
Index: Mk/bsd.options.mk
===
--- Mk/bsd.options.mk (revision 357923)
+++ Mk/bsd.options.mk (working copy)
@@ -199,6 +199,14 @@
# complete list
COMPLETE_OPTIONS_LIST= ${ALL_OPTIONS}
+
+# Handle ports that are using PORTDOCS / PORTEXAMPLES
+.for m in DOCS EXAMPLES
+. if !empty(PORT_OPTIONS:M${m}) && empty(COMPLETE_OPTIONS_LIST:M${m})
+COMPLETE_OPTIONS_LIST+= ${m}
+. endif
+.endfor
+
.for otype in SINGLE RADIO MULTI GROUP
. for m in ${OPTIONS_${otype}}
COMPLETE_OPTIONS_LIST+=${OPTIONS_${otype}_${m}}
___
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: How can I override global OPTIONS_UNSET for specific port in make.conf? www/xcache
Marco Steinbach wrote on 19.06.2014 23:49:
Miroslav Lachman schrieb:
I don't need DOCS, EXAMPLES etc. for each port as I normaly do not use
them on servers.
I have this line in make.conf
OPTIONS_UNSET= X11 GUI CUPS DOCS EXAMPLES NLS
Now I need www/xcache port installed with EXAMPLES.
I tried following in make.conf:
xcache_SET= EXAMPLES
or
xcache_SET_FORCE= EXAMPLES
In both cases, xcache is installed without EXAMPLES.
So how can I have globally disabled EXAMPLES and enable it only for
one specific port?
After some testing, I think this could be a bug in the handling of
PORTEXAMPLES / PORTDOCS, since flipping EXAMPLES / DOCS options (and any
other options I tried) with these switches works as expected.
I'll try and have a go at this.
[...]
If a port does not explicitly define an option for a feature in its
Makefile, then a port specific setting for that option has no effect,
since it simply doesn't match against the options defined in the ports
Makefile.
IOW: If a port does not explicity define an EXAMPLES option, then a port
specific SET or UNSET for the EXAMPLES option in /etc/make.conf has no
effect.
Consequently, in the case of www/xcache, simply adding a dummy EXAMPLE
option to OPTIONS_DEFINE makes xcache_SET_FORCE=EXAMPLES work as
expected: It installs examples, overriding OPTIONS_UNSET_FORCE.
Depending on ones point of view, one could say, that this works as
advertised. But it's confusing and robs us of port specific _FORCE
flags in certain cases.
One possible solution could be, to have Mk/bsd.options.mk detect the use
of PORTEXAMPLES and PORTDOCS in a port, and then silently translate
these into DOCS / EXAMPLES options (adding them to
${COMPLETE_OPTIONS_LIST}), if they're not present.
Without them popping up in a dialog, since that would be the maintainers
domain, and without persisting them, of course.
I'm still trying to wrap my head around these parts of the ports system,
though, in order to not accidentially break things.
MfG CoCo
PS: I'm taking bapt@ out of the loop again, until we're either
completely stuck or are able to produce a patch.
___
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: How can I override global OPTIONS_UNSET for specific port in make.conf? www/xcache
Miroslav Lachman schrieb: I don't need DOCS, EXAMPLES etc. for each port as I normaly do not use them on servers. I have this line in make.conf OPTIONS_UNSET= X11 GUI CUPS DOCS EXAMPLES NLS Now I need www/xcache port installed with EXAMPLES. I tried following in make.conf: xcache_SET= EXAMPLES or xcache_SET_FORCE= EXAMPLES In both cases, xcache is installed without EXAMPLES. So how can I have globally disabled EXAMPLES and enable it only for one specific port? After some testing, I think this could be a bug in the handling of PORTEXAMPLES / PORTDOCS, since flipping EXAMPLES / DOCS options (and any other options I tried) with these switches works as expected. I'll try and have a go at this. MfG CoCo ___ 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: [CFT]: net-mgmt/icinga2
Lars Engels wrote on 19.06.2014 16:08:
On Thu, Jun 19, 2014 at 03:51:20PM +0200, Marco Steinbach wrote:
Lars Engels wrote on 18.06.2014 16:36:
Hey folks,
[Icinga2 port, patch]
Good catch, thanks for this!
I just updated the shar file and also added WWW to pkg-descr.
This patch tries to make Icinga2 only link to what database client the
user selected, instead of linking to whatever database client cmake
stumbles over in addition to the users selection.
MfG CoCo
diff -Naur net-mgmt.orig/icinga2/Makefile net-mgmt/icinga2/Makefile
--- net-mgmt.orig/icinga2/Makefile 2014-06-19 14:12:45.0 +
+++ net-mgmt/icinga2/Makefile 2014-06-19 14:11:14.0 +
@@ -25,6 +25,9 @@
OPTIONS_DEFAULT= MYSQL
+MYSQL_CMAKE_ON= -DWITH_MYSQL:BOOL=true
+PGSQL_CMAKE_ON= -DWITH_PGSQL:BOOL=true
+
ICINGA2USER?= icinga
ICINGA2GROUP?= icinga
USERS= ${ICINGA2USER}
diff -Naur net-mgmt.orig/icinga2/files/patch-CMakeLists.txt
net-mgmt/icinga2/files/patch-CMakeLists.txt
--- net-mgmt.orig/icinga2/files/patch-CMakeLists.txt1970-01-01
00:00:00.0 +
+++ net-mgmt/icinga2/files/patch-CMakeLists.txt 2014-06-16 23:21:34.0
+
@@ -0,0 +1,12 @@
+--- CMakeLists.txt.orig2014-06-16 23:18:51.0 +
CMakeLists.txt 2014-06-16 23:19:01.0 +
+@@ -27,6 +27,9 @@
+ FORCE)
+ endif()
+
++option(WITH_MYSQL "MySQL support" OFF)
++option(WITH_PGSQL "PostgreSQL support" OFF)
++
+ file(STRINGS icinga2.spec VERSION_LINE REGEX "^Version: ")
+ string(REPLACE "Version: " "" ICINGA2_VERSION ${VERSION_LINE})
+
diff -Naur net-mgmt.orig/icinga2/files/patch-components__CMakeLists.txt
net-mgmt/icinga2/files/patch-components__CMakeLists.txt
--- net-mgmt.orig/icinga2/files/patch-components__CMakeLists.txt
1970-01-01 00:00:00.0 +
+++ net-mgmt/icinga2/files/patch-components__CMakeLists.txt 2014-06-16
23:21:47.0 +
@@ -0,0 +1,19 @@
+--- components/CMakeLists.txt.orig 2014-06-16 23:20:12.0 +
components/CMakeLists.txt 2014-06-16 23:20:18.0 +
+@@ -1,7 +1,14 @@
+ add_subdirectory(checker)
+ add_subdirectory(compat)
+-add_subdirectory(db_ido_mysql)
+-add_subdirectory(db_ido_pgsql)
++
++if(WITH_MYSQL)
++ add_subdirectory(db_ido_mysql)
++endif()
++
++if(WITH_PGSQL)
++ add_subdirectory(db_ido_pgsql)
++endif()
++
+ add_subdirectory(demo)
+ add_subdirectory(livestatus)
+ add_subdirectory(notification)
diff -Naur
net-mgmt.orig/icinga2/files/patch-components__db_ido_mysql__CMakeLists.txt
net-mgmt/icinga2/files/patch-components__db_ido_mysql__CMakeLists.txt
--- net-mgmt.orig/icinga2/files/patch-components__db_ido_mysql__CMakeLists.txt
1970-01-01 00:00:00.0 +
+++ net-mgmt/icinga2/files/patch-components__db_ido_mysql__CMakeLists.txt
2014-06-16 23:33:59.0 +
@@ -0,0 +1,9 @@
+--- components/db_ido_mysql/CMakeLists.txt.orig2014-06-16
23:31:26.0 +
components/db_ido_mysql/CMakeLists.txt 2014-06-16 23:31:37.0
+
+@@ -38,4 +38,6 @@
+ RUNTIME DESTINATION ${CMAKE_INSTALL_SBINDIR}
+ LIBRARY DESTINATION ${CMAKE_INSTALL_FULL_LIBDIR}/icinga2
+ )
++else()
++message( FATAL_ERROR "You have selected MySQL support, but MySQL could
not be found." )
+ endif()
diff -Naur
net-mgmt.orig/icinga2/files/patch-components__db_ido_pgsql__CMakeLists.txt
net-mgmt/icinga2/files/patch-components__db_ido_pgsql__CMakeLists.txt
--- net-mgmt.orig/icinga2/files/patch-components__db_ido_pgsql__CMakeLists.txt
1970-01-01 00:00:00.0 +
+++ net-mgmt/icinga2/files/patch-components__db_ido_pgsql__CMakeLists.txt
2014-06-16 23:34:55.0 +
@@ -0,0 +1,9 @@
+--- components/db_ido_pgsql/CMakeLists.txt.orig2014-06-16
23:27:15.0 +
components/db_ido_pgsql/CMakeLists.txt 2014-06-16 23:29:03.0
+
+@@ -40,4 +40,6 @@
+ RUNTIME DESTINATION ${CMAKE_INSTALL_SBINDIR}
+ LIBRARY DESTINATION ${CMAKE_INSTALL_FULL_LIBDIR}/icinga2
+ )
++else()
++message( FATAL_ERROR "You have selected PostgreSQL support, but
PostgreSQL could not be found." )
+ endif()
___
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: USE_MYSQL / USE_PGSQL buildtime dependency differences
Miroslav Lachman wrote on 19.06.2014 15:44: Marco Steinbach wrote: Hi. Mk/bsd.database.mk seems to handle dependencies resulting from the use of USE_PGSQL and USE_MYSQL flags differently. USE_PGSQL pulls in PostgreSQL at buildtime, for both, the client and the server component. USE_MYSQL seems to only pull anything in at buildtime, if the flag is set to 'client'. Thus, with USE_MYSQL=server the build of my port breaks by not installing anything at buildtime, neither the server nor (more importantly) its client slaveport, while USE_MYSQL=client does not install the server. [...] I've also tried renaming my MYSQL / PGSQL options to preclude possible collisions, but that didn't change behaviour. I'm trying to create a port of Icinga2 (https://www.icinga.org/icinga2/), FWIW. I think there is no need to install MySQL server on the same machine with Icinga2 (or any other MySQL dependent port). It really needs client library and then it can connect to any remote MySQL server. That's why this is not supported by bsd.database.mk. Giving the user a choice for exactly this was my intention. Depend on a locally installed server, or have just the client installed. Whatever ones position on this is, the difference in behaviour of the USE_PGSQL and USE_MYSQL flags confused me. I've posted my current workaround for that on the list. MfG CoCo ___ 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: USE_MYSQL / USE_PGSQL buildtime dependency differences
Matthew Seaman wrote on 19.06.2014 15:32:
On 06/19/14 14:04, Marco Steinbach wrote:
Mk/bsd.database.mk seems to handle dependencies resulting from the use
of USE_PGSQL and USE_MYSQL flags differently.
USE_PGSQL pulls in PostgreSQL at buildtime, for both, the client and the
server component. USE_MYSQL seems to only pull anything in at
buildtime, if the flag is set to 'client'.
Lars may have beaten you to the draw as far as icinga2 goes, but for
anyone else hitting this problem:
There is the new:
USES+= pgsql
WANT_PGSQL= client
form you can use nowadays. 'client' isn't mentioned in the comments at
the top of /usr/ports/Mk/Uses/pgsql.mk, but it's clearly there in the
code, and it seems to work.
Thanks for your suggestion.
I'll quote from my original post for clarification:
[begin quote]
Thus, with USE_MYSQL=server the build of my port breaks by not
installing anything at buildtime, neither the server nor (more
importantly) its client slaveport, while USE_MYSQL=client does not
install the server.
Can I have my cake and eat it by using the USE_MYSQL flags, or do I need
to revert to using explicit BUILD_DEPENDS / RUN_DEPENDS combinations to
get the MySQL client in at buildtime in any case ?
[end quote]
My question resulted from a problem with USE_MYSQL, not USE_PGSQL.
There is no documented WANT_PGSQL= flag (in Mk/bsd.database.mk at
least), since defining USE_PGSQL allways implies installing the client
in addition to whatever component is listed in the flag.
USE_PGSQL=server results in the client and the server being installed at
buildtime. USE_PGSQL=yaddayadda (I've actually just tried this to make
sure) gives you the client, only.
USE_MYSQL=yaddayadda installs the client at buildtime. USE_MYSQL=server
installs nothing at buildtime (and consequently my build breaks).
My current workaround for situations like these is to use something
along the lines of:
MYSQL_LIB_DEPENDS=
libmysqlclient.so:${PORTSDIR}/databases/mysql${MYSQL_VER}-client
But as said, I'd like to have my cake and eat it by using the USE_MYSQL
flag, since that fits nicely into a single option helper :)
MfG CoCo
___
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: [CFT]: net-mgmt/icinga2
Lars Engels wrote on 18.06.2014 16:36:
Hey folks,
I proudly present a CFT for the shiny new monitoring software Icinga 2,
a completely rewritten, multi-threaded, flexible and scalable successor
to Icinga 1.
Although it is completely new it still can run with your Icinga / Nagios
plugins and addons.
To use Icinga 2 with the Classic Web interface do the following:
% Download and extract shar file
# fetch -o /tmp http://bsd-geek.de/FreeBSD/icinga2_1.shar
# cd /usr/ports && sh /tmp/icinga2_1.shar
% Install net-mgmt/icinga2
% Install net-mgmt/icinga
% Install www/apache22
% Configure Apache and Icinga Classic Web
# cp /usr/local/share/examples/icinga/apache22/icinga.conf-sample
/usr/local/etc/apache2/Includes/icinga.conf
# cp /usr/local/etc/icinga/cgi.cfg-sample /usr/local/etc/icinga/cgi.cfg
% Make changes to cgi.cfg:
standalone_installation=1
object_cache_file=/var/cache/icinga2/objects.cache
status_file=/var/cache/icinga2/status.dat
command_file=/var/run/icinga2/cmd/icinga2.cmd
log_file=/var/log/icinga2/compat/icinga.log
log_archive_path=/var/log/icinga2/compat/archives
% Create a basic auth file
# htpasswd -c -s /usr/local/etc/icinga/htpasswd.users icingaadmin
(enter some password)
% Enable Apache and Icinga 2
# sysrc apache22_enable=YES
# sysrc icinga2_enable=YES
% Enable additional Icinga 2 features
# icinga2-enable-feature checker command compatlog icingastatus livestatus
mainlog notification statusdata
% Start Apache and Icinga 2
# service apache22 start
# service icinga2 start
% Check /var/log/icinga2/icinga2.log and error.log for any errors
% Browse to http://localhost/icinga
% Log in as icingaadmin
% Read http://docs.icinga.org/icinga2/latest/doc/module/icinga2/toc
% (Hopefully) have fun!
Please share your experience with me. :)
# uname -a
FreeBSD jail008.c0c0.intra 9.3-BETA2 FreeBSD 9.3-BETA2 #0 r267346:
# which flex
/usr/bin/flex
# flex --version
flex version 2.5.4
# make
[...]
-- Found FLEX: /usr/bin/flex version 2.5.4 (Required is at least version
"2.5.31")
[...]
[ 3%] [FLEX][class_lexer] Building scanner with flex /usr/bin/flex
version 2.5.4
"class_lexer.ll", line 92: unrecognized %option: reentrant
"class_lexer.ll", line 93: unrecognized %option: bison-bridge
"class_lexer.ll", line 94: unrecognized %option: unistd
*** [tools/mkclass/class_lexer.cc] Error code 1
1 error
*** [tools/mkclass/CMakeFiles/mkclass.dir/all] Error code 2
[ 3%] Built target execvpe
1 error
*** [all] Error code 2
1 error
Depending on flex from ports (flex-2.5.39_1) fixes this from me.
.if ${OSVERSION} < 133
BUILD_DEPENDS+= flex>=2.5.31:${PORTSDIR}/textproc/flex
CMAKE_ARGS+=-DFLEX_EXECUTABLE:STRING=${LOCALBASE}/bin/flex
CXXFLAGS+= -I${LOCALBASE}/include/flex
.endif
MfG CoCo
___
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: USE_MYSQL / USE_PGSQL buildtime dependency differences
Kurt Jaeger wrote on 19.06.2014 15:16: Hi! I'm trying to create a port of Icinga2 (https://www.icinga.org/icinga2/), FWIW. Lars Engels has already a port of icinga2 he wants us to test: http://lists.freebsd.org/pipermail/freebsd-ports/2014-June/093372.html Thanks :) MfG CoCo ___ 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"
USE_MYSQL / USE_PGSQL buildtime dependency differences
Hi. Mk/bsd.database.mk seems to handle dependencies resulting from the use of USE_PGSQL and USE_MYSQL flags differently. USE_PGSQL pulls in PostgreSQL at buildtime, for both, the client and the server component. USE_MYSQL seems to only pull anything in at buildtime, if the flag is set to 'client'. Thus, with USE_MYSQL=server the build of my port breaks by not installing anything at buildtime, neither the server nor (more importantly) its client slaveport, while USE_MYSQL=client does not install the server. Can I have my cake and eat it by using the USE_MYSQL flags, or do I need to revert to using explicit BUILD_DEPENDS / RUN_DEPENDS combinations to get the MySQL client in at buildtime in any case ? Here's an example: [Makefile ...] PGSQL_USE= pgsql=server PGSQLC_USE= pgsql=client MYSQL_USE= mysql=server MYSQLC_USE= mysql=client [...] With option MYSQL=On and MYSQLC=Off: $ ( make showconfig && make build-depends-list ) | egrep -i 'mysql|postgres' > Depend on PostgreSQL: you can only select none or one of them PGSQL=on: PostgreSQL database support PGSQLC=off: PostgreSQL database support (client only) > Depend on MySQL: you can only select none or one of them MYSQL=on: MySQL database support MYSQLC=off: MySQL database support (client only) /usr/ports/databases/postgresql92-client /usr/ports/databases/postgresql92-server $ As opposed to (note the changed MYSQLC / MYSQL options): $ ( make showconfig && make build-depends-list ) | egrep -i 'mysql|postgres' > Depend on PostgreSQL: you can only select none or one of them PGSQL=on: PostgreSQL database support PGSQLC=off: PostgreSQL database support (client only) > Depend on MySQL: you can only select none or one of them MYSQL=off: MySQL database support MYSQLC=on: MySQL database support (client only) /usr/ports/databases/mysql55-client /usr/ports/databases/postgresql92-client /usr/ports/databases/postgresql92-server $ I've also tried renaming my MYSQL / PGSQL options to preclude possible collisions, but that didn't change behaviour. I'm trying to create a port of Icinga2 (https://www.icinga.org/icinga2/), FWIW. MfG CoCo ___ 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"
make: don't know how to make makeplist. Stop
Hi. I'm updating a port after checking it out into a separated directory for making my modifications, since my ports tree is not writeable. coco@x2p:~/froxlor % make makeplist make: don't know how to make makeplist. Stop Same, if I try this as root: root@x2p:/usr/home/coco/froxlor # make makeplist make: don't know how to make makeplist. Stop Running this inside /usr/ports/sysutils/froxlor yiels a the expected list. Here's what I am working on: root@x2p:/usr/home/coco/froxlor # svn info Path: . Working Copy Root Path: /usr/home/coco/froxlor URL: svn://freebsdsvn/ports/head/sysutils/froxlor Relative URL: ^/head/sysutils/froxlor Repository Root: svn://freebsdsvn/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 332532 Node Kind: directory Schedule: normal Last Changed Author: danilo Last Changed Rev: 331547 Last Changed Date: 2013-10-25 04:38:15 +0200 (Fri, 25 Oct 2013) And the ports tree: coco@x2p:~ % svn info /usr/ports/ Path: /usr/ports Working Copy Root Path: /usr/ports URL: svn://freebsdsvn.c0c0.intra/ports/head Relative URL: ^/head Repository Root: svn://freebsdsvn.c0c0.intra/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 332532 Node Kind: directory Schedule: normal Last Changed Author: hrs Last Changed Rev: 332532 Last Changed Date: 2013-11-02 19:26:36 +0100 (Sat, 02 Nov 2013) It's a recent 8.4-STABLE i386. MfG CoCo ___ 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: NO_STAGE: Bump PORTREVISION ? Pr class 'change' or 'update' ?
John Marino wrote on 24.10.2013 10:21: On 10/24/2013 10:05, Marco Steinbach wrote: Hi, the 'FAQ on PORTREVISION' discussion found at [1] seems to suggest, that enabling staging does not require a PORTREVISION bump. On the other hand, enabling staging seems to be a change in packaging, although from a users perspective the packaged files don't change. And a change in packaging is said to require a bump in PORTREVISION, according to the referenced thread. Are you referring to man pages? I believe those were getting added to the plist internally before, so the final difference in plist before and after staging is zero (if man pages are the only item in question). When enabling staging, is a maintainer supposed to bump PORTREVISION ? I don't see many PORTREVISION bumps as result of stage conversion (only). So I think not. Is this then of class '[maintainer-]update' or just 'change' ? I think maintainer-updates only means the maintainer wrote the PR, so if that's the case, mark it maintainer-update. [...] From the port(1) (not port_s_) man page it looks like marking a pr as class 'update' (maintainer or nor) is substantially different from marking it as 'change'. I think, given that there's no change in functionality in the ports I'm going to modify, I'll stick with not bumping PORTREVISION as to not lead users into believing, that they need to upgrade the installed package. Which in turn results in setting the class to 'change', since that seems to fit with what it is I am doing. Thanks for your comments. MfG CoCo ___ 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"
NO_STAGE: Bump PORTREVISION ? Pr class 'change' or 'update' ?
Hi, the 'FAQ on PORTREVISION' discussion found at [1] seems to suggest, that enabling staging does not require a PORTREVISION bump. On the other hand, enabling staging seems to be a change in packaging, although from a users perspective the packaged files don't change. And a change in packaging is said to require a bump in PORTREVISION, according to the referenced thread. When enabling staging, is a maintainer supposed to bump PORTREVISION ? Is this then of class '[maintainer-]update' or just 'change' ? I think putting a hint to that respect on the StageDir Wiki page might help streamline maintainer prs. MfG CoCo [1] http://lists.freebsd.org/pipermail/freebsd-ports/2012-March/074120.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"
Re: port submission issues - sendmail setup
On Thu, 18 Jul 2013, R Skinner wrote: This has been a real fiasco to send one around the bend. I'm trying to quickly submit a port and I used the send-pr this time and attached my shar as opposed to using the web form, except my sendmail is being rejected because it is a firewalled host and can't be found. So I spent several hours trying to get my head around sendmail and the security involved and setup the 'smart host' option. Eventually this worked, and sent to my mail gateway which is postfix. I then checked the pr list - still not there. So I checked the mailq on the gateway and it still says its looking for the firewalled host! Arrrgh! I'm not up to speed on sendmail at all, so can someone tell what potion I've got to pour into this thing so the send-pr will work correctly without opening any security flaws or access outside of 127.0.0.1? Cheers (Please cc - thx) I am using jails created using sysutils/ezjail for fiddling with my ports. Inside these jails, I then use mail/nullmailer as a sendmail replacement, which logs on to my external mailserver, and simply drops the pr there just as if I'd use let's say alpine for sending mail. No sendmail SASL or other fiddling involved. I can detail my setup off-list, if you think my way of tackling this is an option for your port. Really boils down to just a few steps. MfG CoCo ___ 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: make config: doesn't work - reports ===> Options unchanged : no options menu popping up
O. Hartmann wrote on 07.07.2013 12:25: On boxes running recent /usr/ports and recent soutces( FreeBSD 10.0-CURRENT #0 r252885: Sat Jul 6 16:09:09 CEST 2013) I'm unable to configure some ports, for instance www/firefox: /usr/ports/www/firefox # make config ===> Options unchanged Even performing "make rmconfig" and repeating above procedure doesn't change anything. I can not change options anymore! Please CC me, I'm not subsrcribing the list. [...] I've seen this kind of behaviour with dialog4ports in various situations, but since dialog4ports-0.1.1 or so, I've never encountered this again. Here's a few shots in the dark: - Maybe you're running an outdated version of dialog4ports. Remove dialog4ports, then make config in www/firefox again. This will trigger installation of whatever the most recent version of dialog4ports is in your ports tree. - Check your environment. Unset DIALOG4PORTS or DIALOG, if they're set, then try make config again. MfG CoCo ___ 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: OPTIONSng: Overide options in /var/db/ports/*/options ?
Baptiste Daroussin wrote on 25.03.2013 22:23: On Mon, Mar 25, 2013 at 09:45:19PM +0100, Marco Steinbach wrote: Marco Steinbach wrote on 17.03.2013 21:02: Baptiste Daroussin wrote on 17.03.2013 19:49: On Sun, Mar 17, 2013 at 07:27:56PM +0100, Marco Steinbach wrote: Chris Rees wrote on 17.03.2013 17:15: On 17 Mar 2013 15:45, "Marco Steinbach" wrote: Matthew Seaman wrote on 17.03.2013 14:49: On 17/03/2013 12:16, Marco Steinbach wrote: Hi, is there a way to overide options stored in /var/db/ports/*/options, basically getting back the pre-OPTIONSng behaviour of being able to overide port options in /etc/make.conf ? Before OPTIONSng was introduced, I was able to specify options in /etc/make.conf (WITHOUT_X11, WITHOUT_CUPS, WITH_MAILHEAD, WITH_SSL, WITH_MYSQL, WITH_DOVECOT, ...), which then overode any occurency of that option in any port (or just specific ones, by e.g. checking .CURDIR), regardless of the setting the ports option file contained. Find the uniquename of the port[*] (by 'make -V UNIQUENAME') then in /etc/make.conf uniquename_SET= FOO BAR BAZ uniquename_UNSET= BLURFL will override the default settings in that port's Makefile for the FOO, BAR, BAZ and BLURFL options. Note: this won't override any settings you make from an options dialog. Might be a good idea to 'make rmconfig' if you only want to rely on /etc/make.conf [...] Exactly my point. Currently, with OPTIONSng there seems to be no way to overide anything in /var/db/ports/*/options. I find it irritating, that I no longer can be sure about options in /etc/make.conf. I have to check/reconfigure to make sure. As much as I like OPTIONSng (especially in combination with dialog4ports), this is one thing I'd very much like OPTIONSng to relearn: Enforce options regardless of what's in a ports options file. No, that's a bad idea. It's more confusing to have options not being set that are checked in the OPTIONS dialog. Setting those in make.conf sets defaults, and allows them to be overridden in individual ports. Let's say I never want CUPS, X11, EXAMPLES and DOCS, regardless of what I willingly or accidentially configured in an OPTIONS dialog (or is defaulted to in a ports Makefile), either because I didn't understand the dependancy of a choice, I fat-fingered something or someone helps me configuring something, and wants to make sure I get it right: OPTIONS_UNSET_FORCE= CUPS X11 EXAMPLES DOCS Same goes for the complementary case of having options set forcibly, either system-wide or per port: particularport_SET_FORCE= EXAMPLES DOCS I'd set these in /etc/make.conf, and be done for good. I have a local patch for that kind of behaviour, but wanted to check for possible alternatives besides the beaten path, before bothering bapt@. The thing is half of people wants the /var/db/*/options to be the last word, the other half want the behaviour you are exposing, so getting a final word that will satisfy everyone is hard. I think the approach of having a choice between the two by allowing for a new 'force it down the throat'-mechanism could serve both quite nicely. Existing /var/db/*/options files would still be read, but options can be forcibly set or unset from /etc/make.conf, overriding the corresponding options setting in options files. I personnally really dislike /var/db/port/*/options and the dialog :). The new option framework has been design to: 1/ respect the same behaviour has it used to be before: /var/db/port/*/options has the final word. 2/ provide the ability to users to be able to tune the whole system in a consistent way. 3/ provide a way to totally disable the dialog thing (NO_DIALOG) so that you can't save a option file by mistake. What we can probably do in the end is provide a new macro to totally in all cases ignore /var/db/port/*/options. Would that satisfy your needs? I'll recap the approaches: a) Options in /etc/make.conf only take precedence, if no /var/db/ports/*/options file exists for a given port b) Options in /etc/make.conf always take precedence over options of the same name read from /var/db/ports/*/options c) Options in /etc/make.conf are the only source of wisdom, anything in /var/db/ports/*/options is ignored a) is currently in place (*_SET, *_UNSET) b) is what I'd very much like to see added (*_SET_FORCE, *_UNSET_FORCE) c) probably comes closer to what you're suggesting I've attached my current workaround for b), where I simply duplicated parts of your code in bsd.options.mk, adding a new suffix. Maybe this further clarifies, what I'm currently missing. c) would come in handy, if you'd like to make sure nothing whatsoever from /var/db/ports/*/options impacts a build. Baptiste, are you considering b) ? MfG CoCo I will definitly I need to review you patch and some others I recieved, just I need to find
Anyone in for ports/176823 ?
Hi there, could a ports committer in the mood for picking lower hanging fruit have a look at my REDAXO CMS port (ports/176823) ? MfG CoCo ___ 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: Where has all the groupware gone.....
Joe Malcolm wrote on 31.03.2013 15:42:
On Mar 18, 2013, at 4:30 AM, Marco Steinbach wrote:
Paul Pathiakis wrote on 17.03.2013 20:46:
Hi, I have tried building many pieces of groupware so that I can
replace MS at various client sites. However: zimbra? No port.
(Hardcoded /opt/zimbra) kolab? No port.(Hardcoded /kolab -
This could work if they got rid of the idiocy of "OpenPKG") (A
kolab port could easily be done if all the dependencies their
rpms were made into a port for it. - It should work fairly easily
with ZFS) Citadel? No port. Got it working and seems pretty
decent. SimpleGroupware - Not DB independent, MySQL only Tine?
Not DB independent, MySQL only (Who does that in this day and
age?) Horde? Port is cumbersome and very few tips anywhere to
get it up and running quickly on FreeBSD (Is there a doc I can't
find?) Horde Web? Same as Horde Egroupware? Sweet... Works nice
and seems very useful. Many compliments from people on how well
it works. Phpgroupware? Not really groupware in the form of the
others above. I'm just evaluating. I have no affiliation with
any. However, the lack thereof when we could be inserting
groupware FreeBSD servers in clients... :-) Thank you for
checking into this and creating real ports and/or documentation.
P.
FYI: A port for SOGo (http://www.sogo.nu) has been submitted.
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/175947
Thanks for pointing this out! I had missed this. However, I just
tried it on a not-that-recently 10-current:
fub% uname -a FreeBSD fub 10.0-CURRENT FreeBSD 10.0-CURRENT #0: Sat
Feb 16 19:38:01 UTC 2013
r...@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64
and it errors out with:
Compiling file SOGo+DAV.m ... SOGo+DAV.m:134:2: warning: #warning all
REPORT method should be standardized... SOGo+DAV.m:340:2: warning:
#warning this is a bit ugly, as usual SOGo+DAV.m:480:5: warning:
#warning evil eVIL EVIl! Linking tool sogod ... /usr/bin/ld:
/usr/lib/crt1.o: relocation R_X86_64_32 against `_DYNAMIC' can not be
used when making a shared object; recompile with -fPIC
/usr/lib/crt1.o: could not read symbols: Bad value collect2: ld
returned 1 exit status gmake[4]: *** [obj/sogod] Error 1 gmake[3]:
*** [internal-tool-all_] Error 2 gmake[2]: ***
[sogod.all.tool.variables] Error 2 gmake[1]: *** [internal-all] Error
2 gmake: *** [internal-all] Error 2 *** [do-build] Error code 2
Which, FWIW, is what I got when I tried doing it myself. Some google
produced a hazy idea of what it means but not how to fix it.
Joe
I ran into the same error, and Jim (creator of the ports, cc'ed) had to
fix a rather small oversight. Things seem to work now.
Check both out from here:
https://svn.redports.org/jhriggs/devel/sope/
https://svn.redports.org/jhriggs/www/sogo/
Upon installation, the user and group for SOGo will be created
automatically from the contents of ${PORTSDIR}/UIDs and
${PORTSDIR}/GIDs, once the port has been accepted into the ports tree.
For now, you need to manually add the respective user and group to the
above files, as the ports system won't be able to handle them, otherwise.
See http://www.freebsd.org/cgi/query-pr.cgi?pr=175947.
Be warned, though, that you may need to adapt the numerical user and
group id, because those in the PR may have already been assigned to
other ports.
MfG CoCo
___
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: gettext-0.18.1.1_1 fails to build under jail
Paul Macdonald wrote on 28.03.2013 11:46: this port upgrades fine on the host system but not under a jail.. FreeBSD 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 config.status: executing depfiles commands sed: 2: " s/^include inclu ...": unterminated substitute pattern sed: 1: "s/$(DEPDIR)/.deps .deps/g ": unescaped newline inside substitute pattern I've been getting this message, also. For quite a while, iirc, in jails and on hosts. ./localename.c: In function '_nl_locale_name_thread_unsafe': ./localename.c:2607: error: 'locale_t' undeclared (first use in this function) ./localename.c:2607: error: (Each undeclared identifier is reported only once ./localename.c:2607: error: for each function it appears in.) ./localename.c:2607: error: expected ';' before 'thread_locale' ./localename.c:2608: error: 'thread_locale' undeclared (first use in this function) ./localename.c:2608: error: 'LC_GLOBAL_LOCALE' undeclared (first use in this function) *** Error code 1 Stop in /var/ports/basejail/usr/ports/devel/gettext/work/gettext-0.18.1.1/gettext-runtime/intl. *** Error code 1 Stop in /var/ports/basejail/usr/ports/devel/gettext/work/gettext-0.18.1.1/gettext-runtime. *** Error code 1 Stop in /var/ports/basejail/usr/ports/devel/gettext/work/gettext-0.18.1.1/gettext-runtime. *** Error code 1 Stop in /var/ports/basejail/usr/ports/devel/gettext/work/gettext-0.18.1.1. *** Error code 1 Stop in /basejail/usr/ports/devel/gettext. I didn't run into this, but seeing, that you're also using ezjail, maybe this thread in the FreeBSD forums can provide hints: http://forums.freebsd.org/showthread.php?t=38558 MfG CoCo ___ 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: cannot open tty-output
Bryan Drewery wrote on 25.03.2013 19:46:
On 3/25/2013 6:35 AM, Bryan Drewery wrote:
On 3/25/2013 5:11 AM, Ilya A. Arkhipov wrote:
Hi All,
Fixed in
https://bitbucket.org/m1cro/d4p/commits/42e03ab186b30120fa79e2d0a6093a3c673385ef
Thanks Marco.
After checking it will committed, but you already can test it:
- change dialog4ports version to 0.1.2
- make makesum
- portmaster -d /usr/ports/ports-mgmt/dialog4ports
- add 2(stderr) in Tools/scripts/dialog4ports.sh in "exec $DIALOG4PORTS
2> $OPTIONSFILE" line.
- test it :)
This has now been released to the ports tree. You will need to update
dialog4ports as normal with portmaster to see the jail fixes.
The jail fix was reverted for now. We missed that changing the wrapper
(Tools/scripts/dialog4ports.sh) from stdout to stderr would break
existing installs of previous versions. So this would cause the options
to not save (and be cleared) if using an older version with the new wrapper.
If you are using a jail just remove the '>&2' at the end of the wrapper
for now until we get a more backwards-compatible change ready.
How about enabling dialog4ports to show it's version ? That would
reduce the problem to having a look at the output of e.g.
'${PREFIX}/bin/dialog4ports --version'. Something like 'Version: 0.1.2'
would do, which is easily parseable.
From there, you'd be able to check this in the wrapper, and act
differently on different versions (no, please do not upgrade anything
without ask the user first, although it's tempting :) ). Naturally, if
the executable exists, but no version output is detected, then it's an
old version.
MfG CoCo
___
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: OPTIONSng: Overide options in /var/db/ports/*/options ?
Marco Steinbach wrote on 17.03.2013 21:02: Baptiste Daroussin wrote on 17.03.2013 19:49: On Sun, Mar 17, 2013 at 07:27:56PM +0100, Marco Steinbach wrote: Chris Rees wrote on 17.03.2013 17:15: On 17 Mar 2013 15:45, "Marco Steinbach" wrote: Matthew Seaman wrote on 17.03.2013 14:49: On 17/03/2013 12:16, Marco Steinbach wrote: Hi, is there a way to overide options stored in /var/db/ports/*/options, basically getting back the pre-OPTIONSng behaviour of being able to overide port options in /etc/make.conf ? Before OPTIONSng was introduced, I was able to specify options in /etc/make.conf (WITHOUT_X11, WITHOUT_CUPS, WITH_MAILHEAD, WITH_SSL, WITH_MYSQL, WITH_DOVECOT, ...), which then overode any occurency of that option in any port (or just specific ones, by e.g. checking .CURDIR), regardless of the setting the ports option file contained. Find the uniquename of the port[*] (by 'make -V UNIQUENAME') then in /etc/make.conf uniquename_SET= FOO BAR BAZ uniquename_UNSET= BLURFL will override the default settings in that port's Makefile for the FOO, BAR, BAZ and BLURFL options. Note: this won't override any settings you make from an options dialog. Might be a good idea to 'make rmconfig' if you only want to rely on /etc/make.conf [...] Exactly my point. Currently, with OPTIONSng there seems to be no way to overide anything in /var/db/ports/*/options. I find it irritating, that I no longer can be sure about options in /etc/make.conf. I have to check/reconfigure to make sure. As much as I like OPTIONSng (especially in combination with dialog4ports), this is one thing I'd very much like OPTIONSng to relearn: Enforce options regardless of what's in a ports options file. No, that's a bad idea. It's more confusing to have options not being set that are checked in the OPTIONS dialog. Setting those in make.conf sets defaults, and allows them to be overridden in individual ports. Let's say I never want CUPS, X11, EXAMPLES and DOCS, regardless of what I willingly or accidentially configured in an OPTIONS dialog (or is defaulted to in a ports Makefile), either because I didn't understand the dependancy of a choice, I fat-fingered something or someone helps me configuring something, and wants to make sure I get it right: OPTIONS_UNSET_FORCE= CUPS X11 EXAMPLES DOCS Same goes for the complementary case of having options set forcibly, either system-wide or per port: particularport_SET_FORCE= EXAMPLES DOCS I'd set these in /etc/make.conf, and be done for good. I have a local patch for that kind of behaviour, but wanted to check for possible alternatives besides the beaten path, before bothering bapt@. The thing is half of people wants the /var/db/*/options to be the last word, the other half want the behaviour you are exposing, so getting a final word that will satisfy everyone is hard. I think the approach of having a choice between the two by allowing for a new 'force it down the throat'-mechanism could serve both quite nicely. Existing /var/db/*/options files would still be read, but options can be forcibly set or unset from /etc/make.conf, overriding the corresponding options setting in options files. I personnally really dislike /var/db/port/*/options and the dialog :). The new option framework has been design to: 1/ respect the same behaviour has it used to be before: /var/db/port/*/options has the final word. 2/ provide the ability to users to be able to tune the whole system in a consistent way. 3/ provide a way to totally disable the dialog thing (NO_DIALOG) so that you can't save a option file by mistake. What we can probably do in the end is provide a new macro to totally in all cases ignore /var/db/port/*/options. Would that satisfy your needs? I'll recap the approaches: a) Options in /etc/make.conf only take precedence, if no /var/db/ports/*/options file exists for a given port b) Options in /etc/make.conf always take precedence over options of the same name read from /var/db/ports/*/options c) Options in /etc/make.conf are the only source of wisdom, anything in /var/db/ports/*/options is ignored a) is currently in place (*_SET, *_UNSET) b) is what I'd very much like to see added (*_SET_FORCE, *_UNSET_FORCE) c) probably comes closer to what you're suggesting I've attached my current workaround for b), where I simply duplicated parts of your code in bsd.options.mk, adding a new suffix. Maybe this further clarifies, what I'm currently missing. c) would come in handy, if you'd like to make sure nothing whatsoever from /var/db/ports/*/options impacts a build. Baptiste, are you considering b) ? MfG CoCo ___ 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: cannot open tty-output
Eugene V. Boontseff wrote on 25.03.2013 12:29:
On 25.03.2013 14:43, Marco Steinbach wrote:
Ilya A. Arkhipov wrote on 25.03.2013 11:11:
On 03/25/13 14:01, Marco Steinbach wrote:
Eugene V. Boontseff wrote on 25.03.2013 09:57:
On 25.03.2013 03:37, Marco Steinbach wrote:
Michael Gmelin schrieb:
On Sun, 24 Mar 2013 23:40:47 +0400
"Eugene V. Boontseff" wrote:
*Marco Steinbach wrote:
*
Hi,
after installing dialog4ports, I'm getting the following behaviour
on each 8.3-STABLE I tried:
# jexec /bin/tcsh
# cd
# make config
cannot open tty-output
===> Options unchanged
#
Regardless, if I'm logged in on the console or connect to the host
via ssh.
I've also tried on 8.4-BETA1 (r248617), but got the same
behaviour.
Anyone else experiencing this ?
Yes, I have also experienced this.
8.3-STABLE r244863
Only if i do a "make config" in a jail.
Outside the jail all goes well.
MfG CoCo
This problem doesn't exist in 9.1. On 8 it only happens when you
jexeced into the jail (ssh should be ok). As a workaround you can
run
tmux (sysutils/tmux) within your jail and install ports from
within the
terminal multiplexer (screen will do as well, but is also heavier).
dialog4ports(1) uses stdout for passing back results, where the
former dialog(1) used stderr. I reverted the new behaviour back
to the previous one, which fixed the problem for me. I don't know
about other implications, though.
Ilya (author of dialog4ports) is aware of the problem and having a
look at it.
I'm glad that other people are running into this, also. I was
beginning to think, that there's something fundamentally wrong
with the way our 8.x jails are configured.
What could it be? I configure jail with ezjail. Nothing special.. :-)
MfG CoCo
Same here. With and without ezjail, same behaviour on all 8.x
machines I tried.
Using a serial console on a 9.1 machine yields the same behaviour
when jexec is used, while there's no error when connected per ssh.
MfG CoCo
[...]
Hi All,
Fixed in
https://bitbucket.org/m1cro/d4p/commits/42e03ab186b30120fa79e2d0a6093a3c673385ef
Thanks Marco.
After checking it will committed, but you already can test it:
- change dialog4ports version to 0.1.2
- make makesum
- portmaster -d /usr/ports/ports-mgmt/dialog4ports
- add 2(stderr) in Tools/scripts/dialog4ports.sh in "exec
$DIALOG4PORTS 2> $OPTIONSFILE" line.
- test it :)
Tried it on 9.1 and 8.3, both with jexec using a serial console and
jexec from a ssh connection. Works as advertised.
Thank you for fixing this, Ilya :)
Hmm.. I've applied the patch:
eugene@repo-home [/]# diff -u
/var/ports/basejail/usr/ports/ports-mgmt/dialog4ports/work/dialog4ports-0.1.1/dialog4ports.c.orig
/var/ports/basejail/usr/ports/ports-mgmt/dialog4ports/work/dialog4ports-0.1.1/dialog4ports.c
---
/var/ports/basejail/usr/ports/ports-mgmt/dialog4ports/work/dialog4ports-0.1.1/dialog4ports.c.orig
2013-03-21 21:46:12.0 +0400
+++
/var/ports/basejail/usr/ports/ports-mgmt/dialog4ports/work/dialog4ports-0.1.1/dialog4ports.c
2013-03-25 15:17:45.0 +0400
@@ -273,8 +273,8 @@
/* return all active items */
for (i = 0; i < list_no; i++) {
if (items[i].state == 1) {
- printf("\"%s\"", items[i].name);
- printf(" ");
+ fprintf(stderr, "\"%s\"", items[i].name);
+ fprintf(stderr, " ");
}
}
} else {
Then build the port dialog4ports again.
Then tried make config:
eugene@repo-home [/]# make -C /usr/ports/devel/apr1 config
cannot open tty-output
===> Options unchanged
FreeBSD 8.3 stable.
jexec from a console and from a gnome-terminal give the same result.
What I did wrong?
Did you change Tools/scripts/dialog4ports.sh, also ?
MfG CoCo
___
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: cannot open tty-output
Ilya A. Arkhipov wrote on 25.03.2013 11:11: On 03/25/13 14:01, Marco Steinbach wrote: Eugene V. Boontseff wrote on 25.03.2013 09:57: On 25.03.2013 03:37, Marco Steinbach wrote: Michael Gmelin schrieb: On Sun, 24 Mar 2013 23:40:47 +0400 "Eugene V. Boontseff" wrote: *Marco Steinbach wrote: * Hi, after installing dialog4ports, I'm getting the following behaviour on each 8.3-STABLE I tried: # jexec /bin/tcsh # cd # make config cannot open tty-output ===> Options unchanged # Regardless, if I'm logged in on the console or connect to the host via ssh. I've also tried on 8.4-BETA1 (r248617), but got the same behaviour. Anyone else experiencing this ? Yes, I have also experienced this. 8.3-STABLE r244863 Only if i do a "make config" in a jail. Outside the jail all goes well. MfG CoCo This problem doesn't exist in 9.1. On 8 it only happens when you jexeced into the jail (ssh should be ok). As a workaround you can run tmux (sysutils/tmux) within your jail and install ports from within the terminal multiplexer (screen will do as well, but is also heavier). dialog4ports(1) uses stdout for passing back results, where the former dialog(1) used stderr. I reverted the new behaviour back to the previous one, which fixed the problem for me. I don't know about other implications, though. Ilya (author of dialog4ports) is aware of the problem and having a look at it. I'm glad that other people are running into this, also. I was beginning to think, that there's something fundamentally wrong with the way our 8.x jails are configured. What could it be? I configure jail with ezjail. Nothing special.. :-) MfG CoCo Same here. With and without ezjail, same behaviour on all 8.x machines I tried. Using a serial console on a 9.1 machine yields the same behaviour when jexec is used, while there's no error when connected per ssh. MfG CoCo [...] Hi All, Fixed in https://bitbucket.org/m1cro/d4p/commits/42e03ab186b30120fa79e2d0a6093a3c673385ef Thanks Marco. After checking it will committed, but you already can test it: - change dialog4ports version to 0.1.2 - make makesum - portmaster -d /usr/ports/ports-mgmt/dialog4ports - add 2(stderr) in Tools/scripts/dialog4ports.sh in "exec $DIALOG4PORTS 2> $OPTIONSFILE" line. - test it :) Tried it on 9.1 and 8.3, both with jexec using a serial console and jexec from a ssh connection. Works as advertised. Thank you for fixing this, Ilya :) MfG CoCo ___ 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: cannot open tty-output
Eugene V. Boontseff wrote on 25.03.2013 09:57: On 25.03.2013 03:37, Marco Steinbach wrote: Michael Gmelin schrieb: On Sun, 24 Mar 2013 23:40:47 +0400 "Eugene V. Boontseff" wrote: *Marco Steinbach wrote: * Hi, after installing dialog4ports, I'm getting the following behaviour on each 8.3-STABLE I tried: # jexec /bin/tcsh # cd # make config cannot open tty-output ===> Options unchanged # Regardless, if I'm logged in on the console or connect to the host via ssh. I've also tried on 8.4-BETA1 (r248617), but got the same behaviour. Anyone else experiencing this ? Yes, I have also experienced this. 8.3-STABLE r244863 Only if i do a "make config" in a jail. Outside the jail all goes well. MfG CoCo This problem doesn't exist in 9.1. On 8 it only happens when you jexeced into the jail (ssh should be ok). As a workaround you can run tmux (sysutils/tmux) within your jail and install ports from within the terminal multiplexer (screen will do as well, but is also heavier). dialog4ports(1) uses stdout for passing back results, where the former dialog(1) used stderr. I reverted the new behaviour back to the previous one, which fixed the problem for me. I don't know about other implications, though. Ilya (author of dialog4ports) is aware of the problem and having a look at it. I'm glad that other people are running into this, also. I was beginning to think, that there's something fundamentally wrong with the way our 8.x jails are configured. What could it be? I configure jail with ezjail. Nothing special.. :-) MfG CoCo Same here. With and without ezjail, same behaviour on all 8.x machines I tried. Using a serial console on a 9.1 machine yields the same behaviour when jexec is used, while there's no error when connected per ssh. MfG CoCo ___ 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: cannot open tty-output
Michael Gmelin schrieb: On Sun, 24 Mar 2013 23:40:47 +0400 "Eugene V. Boontseff" wrote: *Marco Steinbach wrote: * Hi, after installing dialog4ports, I'm getting the following behaviour on each 8.3-STABLE I tried: # jexec /bin/tcsh # cd # make config cannot open tty-output ===> Options unchanged # Regardless, if I'm logged in on the console or connect to the host via ssh. I've also tried on 8.4-BETA1 (r248617), but got the same behaviour. Anyone else experiencing this ? Yes, I have also experienced this. 8.3-STABLE r244863 Only if i do a "make config" in a jail. Outside the jail all goes well. MfG CoCo This problem doesn't exist in 9.1. On 8 it only happens when you jexeced into the jail (ssh should be ok). As a workaround you can run tmux (sysutils/tmux) within your jail and install ports from within the terminal multiplexer (screen will do as well, but is also heavier). dialog4ports(1) uses stdout for passing back results, where the former dialog(1) used stderr. I reverted the new behaviour back to the previous one, which fixed the problem for me. I don't know about other implications, though. Ilya (author of dialog4ports) is aware of the problem and having a look at it. I'm glad that other people are running into this, also. I was beginning to think, that there's something fundamentally wrong with the way our 8.x jails are configured. MfG CoCo ___ 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"
dialog4ports: cannot open tty-output
Hi, after installing dialog4ports, I'm getting the following behaviour on each 8.3-STABLE I tried: # jexec /bin/tcsh # cd # make config cannot open tty-output ===> Options unchanged # Regardless, if I'm logged in on the console or connect to the host via ssh. I've also tried on 8.4-BETA1 (r248617), but got the same behaviour. Anyone else experiencing this ? MfG CoCo ___ 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: Where has all the groupware gone.....
Paul Pathiakis wrote on 17.03.2013 20:46: Hi, I have tried building many pieces of groupware so that I can replace MS at various client sites. However: zimbra? No port. (Hardcoded /opt/zimbra) kolab? No port.(Hardcoded /kolab - This could work if they got rid of the idiocy of "OpenPKG") (A kolab port could easily be done if all the dependencies their rpms were made into a port for it. - It should work fairly easily with ZFS) Citadel? No port. Got it working and seems pretty decent. SimpleGroupware - Not DB independent, MySQL only Tine? Not DB independent, MySQL only (Who does that in this day and age?) Horde? Port is cumbersome and very few tips anywhere to get it up and running quickly on FreeBSD (Is there a doc I can't find?) Horde Web? Same as Horde Egroupware? Sweet... Works nice and seems very useful. Many compliments from people on how well it works. Phpgroupware? Not really groupware in the form of the others above. I'm just evaluating. I have no affiliation with any. However, the lack thereof when we could be inserting groupware FreeBSD servers in clients... :-) Thank you for checking into this and creating real ports and/or documentation. P. FYI: A port for SOGo (http://www.sogo.nu) has been submitted. http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/175947 MfG CoCo ___ 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: OPTIONSng: Overide options in /var/db/ports/*/options ?
Baptiste Daroussin wrote on 17.03.2013 19:49:
On Sun, Mar 17, 2013 at 07:27:56PM +0100, Marco Steinbach wrote:
Chris Rees wrote on 17.03.2013 17:15:
On 17 Mar 2013 15:45, "Marco Steinbach" wrote:
Matthew Seaman wrote on 17.03.2013 14:49:
On 17/03/2013 12:16, Marco Steinbach wrote:
Hi,
is there a way to overide options stored in /var/db/ports/*/options,
basically getting back the pre-OPTIONSng behaviour of being able to
overide port options in /etc/make.conf ?
Before OPTIONSng was introduced, I was able to specify options in
/etc/make.conf (WITHOUT_X11, WITHOUT_CUPS, WITH_MAILHEAD, WITH_SSL,
WITH_MYSQL, WITH_DOVECOT, ...), which then overode any occurency of that
option in any port (or just specific ones, by e.g. checking .CURDIR),
regardless of the setting the ports option file contained.
Find the uniquename of the port[*] (by 'make -V UNIQUENAME') then in
/etc/make.conf
uniquename_SET= FOO BAR BAZ
uniquename_UNSET= BLURFL
will override the default settings in that port's Makefile for the FOO,
BAR, BAZ and BLURFL options.
Note: this won't override any settings you make from an options dialog.
Might be a good idea to 'make rmconfig' if you only want to rely on
/etc/make.conf
[...]
Exactly my point. Currently, with OPTIONSng there seems to be no way to
overide anything in /var/db/ports/*/options.
I find it irritating, that I no longer can be sure about options in
/etc/make.conf. I have to check/reconfigure to make sure.
As much as I like OPTIONSng (especially in combination with
dialog4ports), this is one thing I'd very much like OPTIONSng to relearn:
Enforce options regardless of what's in a ports options file.
No, that's a bad idea. It's more confusing to have options not being set
that are checked in the OPTIONS dialog.
Setting those in make.conf sets defaults, and allows them to be overridden
in individual ports.
Let's say I never want CUPS, X11, EXAMPLES and DOCS, regardless of what
I willingly or accidentially configured in an OPTIONS dialog (or is
defaulted to in a ports Makefile), either because I didn't understand
the dependancy of a choice, I fat-fingered something or someone helps me
configuring something, and wants to make sure I get it right:
OPTIONS_UNSET_FORCE= CUPS X11 EXAMPLES DOCS
Same goes for the complementary case of having options set forcibly,
either system-wide or per port:
particularport_SET_FORCE= EXAMPLES DOCS
I'd set these in /etc/make.conf, and be done for good.
I have a local patch for that kind of behaviour, but wanted to check for
possible alternatives besides the beaten path, before bothering bapt@.
The thing is half of people wants the /var/db/*/options to be the last word, the
other half want the behaviour you are exposing, so getting a final word that
will satisfy everyone is hard.
I think the approach of having a choice between the two by allowing for
a new 'force it down the throat'-mechanism could serve both quite nicely.
Existing /var/db/*/options files would still be read, but options can be
forcibly set or unset from /etc/make.conf, overriding the corresponding
options setting in options files.
I personnally really dislike /var/db/port/*/options and the dialog :).
The new option framework has been design to:
1/ respect the same behaviour has it used to be before: /var/db/port/*/options
has the final word.
2/ provide the ability to users to be able to tune the whole system in a
consistent way.
3/ provide a way to totally disable the dialog thing (NO_DIALOG) so that you
can't save a option file by mistake.
What we can probably do in the end is provide a new macro to totally in all
cases ignore /var/db/port/*/options.
Would that satisfy your needs?
I'll recap the approaches:
a) Options in /etc/make.conf only take precedence, if no
/var/db/ports/*/options file exists for a given port
b) Options in /etc/make.conf always take precedence over options of the
same name read from /var/db/ports/*/options
c) Options in /etc/make.conf are the only source of wisdom, anything in
/var/db/ports/*/options is ignored
a) is currently in place (*_SET, *_UNSET)
b) is what I'd very much like to see added (*_SET_FORCE, *_UNSET_FORCE)
c) probably comes closer to what you're suggesting
I've attached my current workaround for b), where I simply duplicated
parts of your code in bsd.options.mk, adding a new suffix. Maybe this
further clarifies, what I'm currently missing.
c) would come in handy, if you'd like to make sure nothing whatsoever
from /var/db/ports/*/options impacts a build.
MfG CoCo
--- Mk/bsd.options.mk.orig 2013-03-17 14:57:27.0 +
+++ Mk/bsd.options.mk 2013-03-17 17:39:52.0 +
@@ -199,6 +199,8 @@
. include "${OPTIONSFILE}.local"
. endif
+
+
### convert WITH and WITHOUT found in make.conf or reloaded from old
optionsfile
.for opt
Re: OPTIONSng: Overide options in /var/db/ports/*/options ?
Chris Rees wrote on 17.03.2013 17:15: On 17 Mar 2013 15:45, "Marco Steinbach" wrote: Matthew Seaman wrote on 17.03.2013 14:49: On 17/03/2013 12:16, Marco Steinbach wrote: Hi, is there a way to overide options stored in /var/db/ports/*/options, basically getting back the pre-OPTIONSng behaviour of being able to overide port options in /etc/make.conf ? Before OPTIONSng was introduced, I was able to specify options in /etc/make.conf (WITHOUT_X11, WITHOUT_CUPS, WITH_MAILHEAD, WITH_SSL, WITH_MYSQL, WITH_DOVECOT, ...), which then overode any occurency of that option in any port (or just specific ones, by e.g. checking .CURDIR), regardless of the setting the ports option file contained. Find the uniquename of the port[*] (by 'make -V UNIQUENAME') then in /etc/make.conf uniquename_SET= FOO BAR BAZ uniquename_UNSET= BLURFL will override the default settings in that port's Makefile for the FOO, BAR, BAZ and BLURFL options. Note: this won't override any settings you make from an options dialog. Might be a good idea to 'make rmconfig' if you only want to rely on /etc/make.conf [...] Exactly my point. Currently, with OPTIONSng there seems to be no way to overide anything in /var/db/ports/*/options. I find it irritating, that I no longer can be sure about options in /etc/make.conf. I have to check/reconfigure to make sure. As much as I like OPTIONSng (especially in combination with dialog4ports), this is one thing I'd very much like OPTIONSng to relearn: Enforce options regardless of what's in a ports options file. No, that's a bad idea. It's more confusing to have options not being set that are checked in the OPTIONS dialog. Setting those in make.conf sets defaults, and allows them to be overridden in individual ports. Let's say I never want CUPS, X11, EXAMPLES and DOCS, regardless of what I willingly or accidentially configured in an OPTIONS dialog (or is defaulted to in a ports Makefile), either because I didn't understand the dependancy of a choice, I fat-fingered something or someone helps me configuring something, and wants to make sure I get it right: OPTIONS_UNSET_FORCE= CUPS X11 EXAMPLES DOCS Same goes for the complementary case of having options set forcibly, either system-wide or per port: particularport_SET_FORCE= EXAMPLES DOCS I'd set these in /etc/make.conf, and be done for good. I have a local patch for that kind of behaviour, but wanted to check for possible alternatives besides the beaten path, before bothering bapt@. MfG CoCo ___ 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: OPTIONSng: Overide options in /var/db/ports/*/options ?
Matthew Seaman wrote on 17.03.2013 14:49: On 17/03/2013 12:16, Marco Steinbach wrote: Hi, is there a way to overide options stored in /var/db/ports/*/options, basically getting back the pre-OPTIONSng behaviour of being able to overide port options in /etc/make.conf ? Before OPTIONSng was introduced, I was able to specify options in /etc/make.conf (WITHOUT_X11, WITHOUT_CUPS, WITH_MAILHEAD, WITH_SSL, WITH_MYSQL, WITH_DOVECOT, ...), which then overode any occurency of that option in any port (or just specific ones, by e.g. checking .CURDIR), regardless of the setting the ports option file contained. Find the uniquename of the port[*] (by 'make -V UNIQUENAME') then in /etc/make.conf uniquename_SET= FOO BAR BAZ uniquename_UNSET= BLURFL will override the default settings in that port's Makefile for the FOO, BAR, BAZ and BLURFL options. Note: this won't override any settings you make from an options dialog. Might be a good idea to 'make rmconfig' if you only want to rely on /etc/make.conf [...] Exactly my point. Currently, with OPTIONSng there seems to be no way to overide anything in /var/db/ports/*/options. I find it irritating, that I no longer can be sure about options in /etc/make.conf. I have to check/reconfigure to make sure. As much as I like OPTIONSng (especially in combination with dialog4ports), this is one thing I'd very much like OPTIONSng to relearn: Enforce options regardless of what's in a ports options file. Enforcing invalid multi/single/radio option combinations may be a possible pitfall, but that's catched by OPTIONSng, and the build simply stops. MfG CoCo ___ 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: [CFT] New dialog for ports
Baptiste Daroussin wrote on 17.03.2013 16:11: On Sun, Mar 17, 2013 at 08:56:13AM -0600, Warren Block wrote: On Thu, 14 Mar 2013, Baptiste Daroussin wrote: Ilya A. Arkhipov wrote dialog4ports which has just been added into the ports tree ports-mgmt/dialog4ports, this is intended to be a replacement for dialog(1) designed specifically for the options, in particular for optionsng. My one complaint is that, last I looked, long option descriptions are not supported. We really need this. A maintainer should be concerned with clear option descriptions and not have to restrict their length at the cost of clarity. The user should not have to interpret short or cut-off option descriptions. pkg-help might help here in the first place, second this could be worked on for a 0.2 version ;), have you tried anyway long description with this version? I think they just works correctly, but I haven't tested. I tried. They get truncated, instead of overflowing and hosing the layout. MfG CoCo ___ 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: [CFT] New dialog for ports
Baptiste Daroussin wrote on 14.03.2013 10:55: Hi all, Ilya A. Arkhipov wrote dialog4ports which has just been added into the ports tree ports-mgmt/dialog4ports, this is intended to be a replacement for dialog(1) designed specifically for the options, in particular for optionsng. It uses libdialog (recent version) and extend it with a new widget able to deal with both normal and radio options in the same window. I very much like this from the few ports I tried it with for now. Having UI elements in a config dialog behave like real radio groups is great, separating them from each other with horizontal lines adds greatly to readability and usabilty from where I sit. Being able to specifiy a descriptive text to be displayed in the heading of radio option groups is a very welcome feature, since that'll give me a chance to be more concise about what the user will get from the group. I think 'make showconfig' should learn to display these, also. Albeit being a rather small change, I quite like the use of a small 'X' letter for ticked options. dialog4ports will live forever in ports so that it can easily be updated and get support for new features on all supported arches at the same time. It bundles libdialog on FreeBSD versions that doesn't have a recent libdialog in base (read 8.x) dialog4ports also support a new feature: it has a help dialog to be able to print a human readable help text if possible. That's also very useful. I thought about asking for having long lines being automatically reflowed to screen width, but this would probably open a small can of worms. Anyway, help is supposed to give hints, not to replace documentation, and using fmt(1) on pkg-help before submission is not exactly rocket science. Here is a patch to the ports tree that makes it use dialog4ports by default. What it does is: When make config is requested and dialog4ports is not installed yet the ports tree will install dialog4ports first. New feature for maintainer, if a pkg-help file is found inside the port directory then dialog will show to the user a help file is available et propose him to hint F1 or ^E to show the said help file http://people.freebsd.org/~bapt/d4p.diff Please test! Nice work -- much appreciated :) MfG CoCo PS: There's a typo in the message asking for the dialog4ports installation. It reads '... installed to you want ...', but probably should read '... installed, do you want ...'. ___ 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"
OPTIONSng: Overide options in /var/db/ports/*/options ?
Hi, is there a way to overide options stored in /var/db/ports/*/options, basically getting back the pre-OPTIONSng behaviour of being able to overide port options in /etc/make.conf ? Before OPTIONSng was introduced, I was able to specify options in /etc/make.conf (WITHOUT_X11, WITHOUT_CUPS, WITH_MAILHEAD, WITH_SSL, WITH_MYSQL, WITH_DOVECOT, ...), which then overode any occurency of that option in any port (or just specific ones, by e.g. checking .CURDIR), regardless of the setting the ports option file contained. MfG CoCo ___ 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: proftpd-1.3.4b Error in port
On Fri, 8 Mar 2013, Paul Macdonald wrote:
Hi,
FYI we're seeing an issue upgrading proftpd..
proftpd-1.3.4b < needs updating (index has 1.3.4c)
proftpd-mod_sql_mysql-1.3.4b< needs updating (index has 1.3.4c)
Under:
FreeBSD XXX 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10
UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64
Error:
cc -DHAVE_CONFIG_H -DFREEBSD9_1 -DFREEBSD9 -I.. -I../include
-I/usr/local/include -O2 -pipe -DHAVE_OPENSSL -I/usr/include
-fno-strict-aliasing -Wall -c str.c
cc -DHAVE_CONFIG_H -DFREEBSD9_1 -DFREEBSD9 -I.. -I../include
-I/usr/local/include -O2 -pipe -DHAVE_OPENSSL -I/usr/include
-fno-strict-aliasing -Wall -c table.c
cc -DHAVE_CONFIG_H -DFREEBSD9_1 -DFREEBSD9 -I.. -I../include
-I/usr/local/include -O2 -pipe -DHAVE_OPENSSL -I/usr/include
-fno-strict-aliasing -Wall -c regexp.c
cc -DHAVE_CONFIG_H -DFREEBSD9_1 -DFREEBSD9 -I.. -I../include
-I/usr/local/include -O2 -pipe -DHAVE_OPENSSL -I/usr/include
-fno-strict-aliasing -Wall -c dirtree.c
cc -DHAVE_CONFIG_H -DFREEBSD9_1 -DFREEBSD9 -I.. -I../include
-I/usr/local/include -O2 -pipe -DHAVE_OPENSSL -I/usr/include
-fno-strict-aliasing -Wall -c expr.c
cc -DHAVE_CONFIG_H -DFREEBSD9_1 -DFREEBSD9 -I.. -I../include
-I/usr/local/include -O2 -pipe -DHAVE_OPENSSL -I/usr/include
-fno-strict-aliasing -Wall -c support.c
cc -DHAVE_CONFIG_H -DFREEBSD9_1 -DFREEBSD9 -I.. -I../include
-I/usr/local/include -O2 -pipe -DHAVE_OPENSSL -I/usr/include
-fno-strict-aliasing -Wall -c netaddr.c
netaddr.c:696: error: expected identifier or '(' before 'return'
netaddr.c:697: error: expected identifier or '(' before '}' token
gmake[1]: *** [netaddr.o] Error 1
gmake[1]: Leaving directory `/usr/ports/ftp/proftpd/work/proftpd-1.3.4c/src'
gmake: *** [src] Error 2
*** [do-build] Error code 1
[...]
Disabling IPV6 triggers this. Looks like the #endif in line 693 should trade
places with the curly bracket below it.
MfG CoCo
___
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"
Possibly interactive deinstallation warning for a port ?
Hi, I'm preparing a port for which the vendor advises the use of the built-in export and import functionality for upgrading from one version of the product to another. So, for an upgrade the user is supposed to export the current data, then delete the installed port, install the updated port, then import the data. Just trying to preserve configuration files and data upon deinstallation is prone to introduce hard to track errors for this product, so this does not seem to be a viable option. Currently, I'm just displaying a warning for 10 seconds during which the user has time for aborting the deinstallation. What I'd like to do is make the deinstallation truly interactive, enabling the user to read through the warning text, then either decide to ditch the product, or stop deinstallation, without any clock running (unless BATCH is specified, that is). Should I rely on the user knowing what he's doing, and just wait for a few seconds in my pkg-deinstall script like postgresql does ? Or is making deinstallation interactive an acceptable option ? If yes, do I need to mark the whole port as being interactive, although installation is not interactive ? I tend to just wait a few seconds in order to not overcomplicate things, but maybe someone can come up with some ideas or hints. MfG CoCo PS: The product in question is the REDAXO content management system. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: portmaster: Installing new ports without upgrading already installed ones ?
On Wed, 15 Feb 2012, Doug Barton wrote: On 02/15/2012 06:04, Marco Steinbach wrote: Hi there, is there a way for telling portmaster to not upgrade already installed dependencies, besides explicitly excluding these with '-x' or using '+IGNOREME' ? Someone already mentioned -i. In other words: Is there a flag, or a combination thereof, to have portmaster conveniently just install missing and not upgrade allready installed dependencies -- like a 'make install' in a ports' directory would do ? To answer your question, no. The tool is not designed to be used that way. (And no, I won't add that as an option.) Fair enough -- thanks for the clarification. And for maintaining portmaster in the first place, of course. MfG CoCo ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: portmaster: Installing new ports without upgrading already installed ones ?
geoffroy desvernay wrote on 15.02.2012 18:24: On 15.02.2012 15:04, Marco Steinbach wrote: Hi there, is there a way for telling portmaster to not upgrade already installed dependencies, besides explicitly excluding these with '-x' or using '+IGNOREME' ? In other words: Is there a flag, or a combination thereof, to have portmaster conveniently just install missing and not upgrade allready installed dependencies -- like a 'make install' in a ports' directory would do ? I'm using portmaster 3.11. MfG CoCo portmaster -i may let you decide what to update... Thanks for the hint -- Alas, going interactive kind of ends me up doing what I described in the first paragraph, just by other means. MfG CoCo ___ 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"
portmaster: Installing new ports without upgrading already installed ones ?
Hi there, is there a way for telling portmaster to not upgrade already installed dependencies, besides explicitly excluding these with '-x' or using '+IGNOREME' ? In other words: Is there a flag, or a combination thereof, to have portmaster conveniently just install missing and not upgrade allready installed dependencies -- like a 'make install' in a ports' directory would do ? I'm using portmaster 3.11. MfG CoCo ___ 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: [HEADSUP][CFT] pkgng beta1 is out
On Mon, 30 Jan 2012, Baptiste Daroussin wrote:
Hi,
pkgng has just reached the beta phase, and has now found its way to the
ports tree (disabled by default).
[...]
cd /usr/ports/
touch abc
touch: abc: Permission denied
pkg create net/ifstat
Creating package for ifstat-1.1_5
Segmentation fault
The attached patch tries to enable pkg(1) to stay on top of things by adding
error handling around archive_write_open_filename.
pkg create net/ifstat
Creating package for ifstat-1.1_5
pkg: archive_write_open_filename(.//ifstat-1.1_5.txz): Permission denied
pkg: unable to create archive
MfG CoCodiff --git a/libpkg/packing.c b/libpkg/packing.c
index e536eb8..9543c32 100644
--- a/libpkg/packing.c
+++ b/libpkg/packing.c
@@ -49,7 +49,15 @@ packing_init(struct packing **pack, const char *path,
pkg_formats format)
}
snprintf(archive_path, sizeof(archive_path), "%s.%s", path,
ext);
- archive_write_open_filename((*pack)->awrite, archive_path);
+ if (archive_write_open_filename(
+ (*pack)->awrite, archive_path) != ARCHIVE_OK ) {
+ pkg_emit_errno("archive_write_open_filename",
+ archive_path);
+ archive_read_finish((*pack)->aread);
+ archive_write_finish((*pack)->awrite);
+ *pack = NULL;
+ return EPKG_FATAL;
+ }
} else { /* pass mode directly write to the disk */
(*pack)->awrite = archive_write_disk_new();
archive_write_disk_set_options((*pack)->awrite,
EXTRACT_ARCHIVE_FLAGS);
___
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: databases/mysql55-server and DISABLE_CONFLICTS
Alex Dupre wrote on 24.01.2012 07:55: Marco Steinbach ha scritto: shouldn't I be able to fetch distfiles for conflicting ports, if DISABLE_CONFLICTS is set ? Yes, but in this case you should also set -DNO_IGNORE That did the trick -- thank you. MfG Coco ___ 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"
databases/mysql55-server and DISABLE_CONFLICTS
Hi, shouldn't I be able to fetch distfiles for conflicting ports, if DISABLE_CONFLICTS is set ? # cd /usr/ports/databases/mysql55-server # make -DDISABLE_CONFLICTS fetch ===> mysql-server-5.5.20 cannot install: MySQL versions mismatch: mysql51-client is installed and wanted version is mysql55-client. *** Error code 1 I didn't use this in a long time, and can't remember, if it ever worked for MySQL. This is on a recent 8.2-STABLE with freshly csuped ports. MfG CoCo ___ 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: sa-update under perl 5.14
Randy Bush wrote on 31.12.2011 07:51: FreeBSD psg.com 9.0-PRERELEASE FreeBSD 9.0-PRERELEASE #2: Sat Dec 24 13:35:25 GMT 2011 r...@psg.com:/usr/obj/usr/src/sys/PSG i386 perl 5, version 14, subversion 2 (v5.14.2) built for i386-freebsd-thread-multi-64int p5-Mail-SpamAssassin-3.3.2_3 libwww-5.4.0_4 p5-libwww-6.02_1 the fun starts about "retrying: 501 Protocol scheme 'http' is not supported: 501 Protocol scheme 'http' is not supported" # sa-update -D [... Dec 31 06:48:58.782 [95100] dbg: http: GET request, http://spamassassin.apache.org/updates/MIRRORED.BY Dec 31 06:48:58.820 [95100] dbg: http: GET http://spamassassin.apache.org/updates/MIRRORED.BY request failed, retrying: 501 Protocol scheme 'http' is not supported: 501 Protocol scheme 'http' is not supported Dec 31 06:48:58.822 [95100] dbg: http: GET request, http://spamassassin.apache.org/updates/MIRRORED.BY Dec 31 06:48:58.823 [95100] dbg: http: GET http://spamassassin.apache.org/updates/MIRRORED.BY request failed, retrying: 501 Attempt to reload LWP/Protocol/http.pm aborted. Dec 31 06:48:58.824 [95100] dbg: http: [...] Compilation failed in require: 501 Attempt to reload LWP/Protocol/http.pm aborted. Compilation failed in require Dec 31 06:48:58.825 [95100] dbg: http: GET request, http://spamassassin.apache.org/updates/MIRRORED.BY Dec 31 06:48:58.826 [95100] dbg: http: GET http://spamassassin.apache.org/updates/MIRRORED.BY request failed, retrying: 501 Attempt to reload LWP/Protocol/http.pm aborted. Dec 31 06:48:58.827 [95100] dbg: http: [...] Compilation failed in require: 501 Attempt to reload LWP/Protocol/http.pm aborted. Compilation failed in require http: GET http://spamassassin.apache.org/updates/MIRRORED.BY request failed: 501 Attempt to reload LWP/Protocol/http.pm aborted. Compilation failed in require: 501 Attempt to reload LWP/Protocol/http.pm aborted. Compilation failed in require Dec 31 06:48:58.827 [95100] dbg: channel: no mirror data available for channel updates.spamassassin.org from http://spamassassin.apache.org/updates/MIRRORED.BY error: no mirror data available for channel updates.spamassassin.org channel: MIRRORED.BY contents were missing, channel failed Dec 31 06:48:58.827 [95100] dbg: generic: cleaning up temporary directory/files Dec 31 06:48:58.828 [95100] dbg: diag: updates complete, exiting with code 4 [...] I just tried in a clean jail with default options picked for all dependencies, ports tree csuped yesterday. Updates as advertised, no noticeable errors. I'm using: FreeBSD x2q.c0c0.intra 9.0-PRERELEASE FreeBSD 9.0-PRERELEASE #0 r228927M: Thu Dec 29 13:36:57 CET 2011 root@x2.c0c0.intra:/usr/obj/usr/src/sys/GENERIC amd64 Logs and other info here: http://www.moehre.org/files/p5-Mail-SpamAssassin_perl-5.14.2/ MfG CoCo ___ 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: VirtualBox-kmod fails to build on -CURRENT
On Mon, 31 Oct 2011, Ed Schouten wrote: * Marco Steinbach , 20111031 13:11: Thanks for having a look into this -- I'm trying out your patch right now. This will take a while, as I'll try and test this on 7, also. Great. Thanks! I just inspected the code and it seems VirtualBox expects the device to be named /dev/vboxdrv%d explicitly. If that's the case, please try to add a symbolic link from vboxdrv0 to vboxdrv. If that works, I can get that fixed as well. Your patch seems to work for 10-CURRENT/amd64. I noticed no hickups with existing and newly created VMs, and the messages for loading the driver and network support stayed the same: vboxdrv: fAsync=1 offMin=0x34da8a offMax=0x34da8a supdrvGipCreate: omni timer not supported, falling back to synchronous mode vboxnet0: Ethernet address: 0a:00:27:00:00:00 You were right about the device naming, I had to create a symlink. I got another burp on the console. ISTR that I got this one before, also, but am not sure: acquiring duplicate lock of same type: "IPRT Fast Mutex Semaphore" 1st IPRT Fast Mutex Semaphore @ /usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.0.12_OSE/out freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/semfastmutex-r0drv-freebsd.c:100 2nd IPRT Fast Mutex Semaphore @ /usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.0.12_OSE/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/semfastmutex-r0drv-freebsd.c:100 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 _witness_debugger() at _witness_debugger+0x2c witness_checkorder() at witness_checkorder+0x93c _sx_xlock() at _sx_xlock+0x55 RTSemFastMutexRequest() at RTSemFastMutexRequest+0x59 g_aUnits() at g_aUnits+0x6963 g_aUnits() at g_aUnits+0x6ea7 g_aUnits() at 0x8165fe9e g_aUnits() at 0x81660398 supdrvIOCtl() at supdrvIOCtl+0x1a12 VBoxDrvFreeBSDIOCtl() at VBoxDrvFreeBSDIOCtl+0x1d0 devfs_ioctl_f() at devfs_ioctl_f+0x7a kern_ioctl() at kern_ioctl+0xcd sys_ioctl() at sys_ioctl+0xfd amd64_syscall() at amd64_syscall+0x3ac Xfast_syscall() at Xfast_syscall+0xf7 --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8012a950c, rsp = 0x7f9b7c88, rbp = 0x7f9b7c90 --- I'll come back to you with results from testing on 7/amd64. MfG CoCo ___ 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: textproc/libxml2 does not install libxml2.so.5
On Mon, 31 Oct 2011, b. f. wrote:
This doesn't seem to do the trick for me:
# echo $SHELL
/bin/csh
# setenv UNAME_r 9.9-CURRENT
# echo $UNAME_r
9.9-CURRENT
# cd /usr/ports/textproc/libxml2
# make install clean
[...]
# pkg_info -g libxml2-2.7.8_1
Information for libxml2-2.7.8_1:
Mismatched Checksums:
pkg_info: /usr/local/etc/xml2Conf.sh doesn't exist
pkg_info: /usr/local/lib/libxml2.so.5 doesn't exist
pkg_info: /usr/local/libdata/pkgconfig/libxml-2.0.pc doesn't exist
Am I doing something wrong here ?
Yes, you are trusting us. ;)
Ah, and I thought it was something serious.
There are a few problems related to the
FreeBSD 10 fix that are still being worked out. Whether or not the
FreeBSD 10 fix is used depends on OSVERSION, which is calculated in
bsd.port.mk, so your masquerading is incomplete:
1192 .if !defined(OSVERSION)
1193 .if exists(/usr/include/sys/param.h)
1194 OSVERSION!= ${AWK}
'/^\#define[[:blank:]]__FreeBSD_version/ {print $$3}' <
/usr/include/sys/param.h
1195 .elif exists(${SRC_BASE}/sys/sys/param.h)
1196 OSVERSION!= ${AWK}
'/^\#define[[:blank:]]__FreeBSD_version/ {print $$3}' <
${SRC_BASE}/sys/sys/param.h
1197 .else
1198 OSVERSION!= ${SYSCTL} -n kern.osreldate
1199 .endif
1200 .endif
...
3664 run-autotools-fixup:
3665 # Work around an issue where FreeBSD 10.0 is detected as
FreeBSD 1.x.
3666 .if defined(WITH_FBSD10_FIX) && ${OSVERSION} >= 100
...
You could edit the __FreeBSD_version line in param.h, or override
OSVERSION on the command-line, setting it less than 100, if you
wanted to continue to masquerade as 9.9 or some other suitable value
while the problems are being resolved.
Thank you for your explanations, much appreciated -- miwi@ suggested another,
different possible way in private mail (rebuilding devel/libtool, if I
understood correctly), but I already had cleaned out all packages from the
machine.
Not quite a sophisticated way of solving a problem, but it looks like it helped
for now.
MfG CoCo
___
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: textproc/libxml2 does not install libxml2.so.5
Ruslan Mahmatkhanov wrote on 31.10.2011 16:57: Marco Steinbach wrote on 31.10.2011 19:21: Hi, I'm trying to use textproc/libxml2 from ports, but it seems, that some files are missing after installation. Subsequently, installing textproc/libxslt fails due to a missing libxml2.so.5, for example. My /etc/make.conf is empty. I'm a bit reluctant to 'fix' this by symlinking, and besides that, libxml2.so.5 is listed in the pkg-plist of libxml2, so I assume something goes wrong locally or the port might need some attention. I've updated the ports tree on the machine just a few minutes ago. Here's some more information: # uname -a FreeBSD 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r226877: Fri Oct 28 07:55:10 UTC 2011 root@:/usr/obj/usr/src/sys/GENERIC amd64 # pwd /usr/ports/textproc/libxml2 # make -VPKGNAME libxml2-2.7.8_1 # make install clean [...] # pkg_info -IX libxml2 libxml2-2.7.8_1 XML parser library for GNOME # pkg_info -g libxml2-2.7.8_1 Information for libxml2-2.7.8_1: Mismatched Checksums: pkg_info: /usr/local/etc/xml2Conf.sh doesn't exist pkg_info: /usr/local/lib/libxml2.so.5 doesn't exist pkg_info: /usr/local/libdata/pkgconfig/libxml-2.0.pc doesn't exist Hints and/or pointers welcome. MfG CoCo Yes, it looks like WITH_FBSD10_FIX=yes doesn't works here. You may rebuild it with UNAME_r=9.9-CURRENT until the working fix will not be committed. This doesn't seem to do the trick for me: # echo $SHELL /bin/csh # setenv UNAME_r 9.9-CURRENT # echo $UNAME_r 9.9-CURRENT # cd /usr/ports/textproc/libxml2 # make install clean [...] # pkg_info -g libxml2-2.7.8_1 Information for libxml2-2.7.8_1: Mismatched Checksums: pkg_info: /usr/local/etc/xml2Conf.sh doesn't exist pkg_info: /usr/local/lib/libxml2.so.5 doesn't exist pkg_info: /usr/local/libdata/pkgconfig/libxml-2.0.pc doesn't exist Am I doing something wrong here ? MfG CoCo ___ 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"
textproc/libxml2 does not install libxml2.so.5
Hi, I'm trying to use textproc/libxml2 from ports, but it seems, that some files are missing after installation. Subsequently, installing textproc/libxslt fails due to a missing libxml2.so.5, for example. My /etc/make.conf is empty. I'm a bit reluctant to 'fix' this by symlinking, and besides that, libxml2.so.5 is listed in the pkg-plist of libxml2, so I assume something goes wrong locally or the port might need some attention. I've updated the ports tree on the machine just a few minutes ago. Here's some more information: # uname -a FreeBSD 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r226877: Fri Oct 28 07:55:10 UTC 2011 root@:/usr/obj/usr/src/sys/GENERIC amd64 # pwd /usr/ports/textproc/libxml2 # make -VPKGNAME libxml2-2.7.8_1 # make install clean [...] # pkg_info -IX libxml2 libxml2-2.7.8_1 XML parser library for GNOME # pkg_info -g libxml2-2.7.8_1 Information for libxml2-2.7.8_1: Mismatched Checksums: pkg_info: /usr/local/etc/xml2Conf.sh doesn't exist pkg_info: /usr/local/lib/libxml2.so.5 doesn't exist pkg_info: /usr/local/libdata/pkgconfig/libxml-2.0.pc doesn't exist Hints and/or pointers welcome. MfG CoCo ___ 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: VirtualBox-kmod fails to build on -CURRENT
Ed Schouten wrote on 31.10.2011 12:16: * Ed Schouten , 20111031 12:07: Ugh. Too impatient. Please try the attached patch. It should build on 7.x and higher. I have only compile-tested it, because I am not a VirtualBox user (yet). Read: I have only compile-tested it on HEAD, but the used interfaces should be present as of 7.x. Thanks for having a look into this -- I'm trying out your patch right now. This will take a while, as I'll try and test this on 7, also. MfG CoCo ___ 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: VirtualBox-kmod fails to build on -CURRENT
Vladimir Kushnir wrote on 26.10.2011 11:32:
Hi
Well, the problem is:
I'm trying to build VirtualBox{*} on amd64 10.0-CURRENT. The very first
port, virtualbox-ose-kmod fails with
/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.0.12_OSE/out/freebsd.
amd64/release/bin/src/vboxdrv/freebsd/SUPDrv-freebsd.c:104: error:
'D_PSEUDO' undeclared here (not in a function)
And indeed, threre's no D_PSEUDO flags in /usr/src
Any help?
Thanks in advance,
Vladimir
See http://svnweb.freebsd.org/base?view=revision&revision=226500
I presume emulators/virtualbox-ose-kmod needs to take this one into account.
I've submitted a PR.
MfG CoCo
___
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"
man page style questions
I'm reposting this to -ports, as I got no replies on -doc within several days. I'm currently preparing a man page for a yet to be submited new port, and altough I was able to get answers for some of my questions from the mdoc(7) man page and other sources, there are still some areas where I am not sure about how to properly format and label things. The current source of the man page is available at http://www.moehre.org/files/sqtop/sqtop.1 The port has an optional ncurses-based interface, which, if used, allows the behaviour of the utility to be changed by pressing certain keys. - Is "INTERACTIVE MODE" the appropiate term to be used as heading for the section dealing with the specifics of a ncurses-based user interface ? - What labels are to be used for keys which usually do not produce a printable character ? E.g. is the -key to be represented as "return", "" or "RETURN" (or is it to be named "enter", anyway ?) - What about the cursor movement and other directional keys like , , ? - Are there any preferences for the macros to use for keys to be pressed, e.g. is the following acceptable: .Bl -tag -width Fl .It Ic C Do the C thing. .It Ic A Do the A thing. .El Any hints and suggestions (wording, macro usage, etc) to make the man page a better fit to the style of the FreeBSD project are greatly appreciated. MfG CoCo ___ 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"
PYEASYINSTALL_CMD and minimal version of setuptools
Is there an agreed way to set the minimal version of py-setuptools required as dependency for a Python package ? The Python package in question requires py-setuptools >=0.6.c11, but I can't figure out how to get the magic in Mk/bsd.python.mk to do what I'd like it to do: Fail, if an older version is installed, otherwise install and use the required version. MfG CoCo ___ 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: request. Sogo
Sean McAfee schrieb: On 09/08/10 08:37, Johan Hendriks wrote: > I am no programmer in any way, and do not understand all of the > configure needs. > > > > I would like to know if anyone is working on it, because it is THE > solution for us. Seconded on that. Unfortunately, I don't have much time to burn on this and GNUStep is a mess. [...] I gave it a quick shot, and was able to build and install SOGo and SOPE in a clean 8.1/amd64 jail, with NOPORTDOCS=yes as the only flag in /etc/make.conf. The jails ports tree was last csuped yesterday. $ denotes an unprivileged user account, # denotes root. # cd /usr/ports/ports-mgmt/portmaster && make install clean # portmaster lang/gnustep-base # portmaster databases/mysql51-server # portmaster net/openldap24-server # portmaster mail/dovecot # portmaster mail/postfix # portmaster devel/monotone # portmaster shells/bash # portmaster databases/libmemcached Grab sources: $ mkdir ~/tmp $ cd ~/tmp $ mtn db init --db=~/db.mtn $ mtn --db=~/db.mtn pull inverse.ca ca.inverse.sope $ mtn --db=~/db.mtn checkout --branch ca.inverse.sope SOPE $ mtn --db=~/db.mtn pull inverse.ca ca.inverse.sogo $ mtn --db=~/db.mtn checkout --branch ca.inverse.sogo SOGo Build: bash $ cd ~/tmp/SOPE bash $ . /usr/local/GNUstep/System/Library/Makefiles/GNUstep.sh bash $ ./configure --with-gnustep --enable-debug --disable-strip bash $ gmake bash # . /usr/local/GNUstep/System/Library/Makefiles/GNUstep.sh bash # gmake install bash $ cd ~/tmp/SOGo bash $ . /usr/local/GNUstep/System/Library/Makefiles/GNUstep.sh bash $ ./configure --enable-debug --disable-strip bash $ gmake The build stops at a missing library named libOGoContentStore.so.0.9 bash $ cd OGoContentStore && gmake && gmake install && cd .. While you're at it, fix cp in SOPE/NGCards/GNUmakefile.postamble, by replacing -dpR with -a. bash $ gmake bash # . /usr/local/GNUstep/System/Library/Makefiles/GNUstep.sh bash # gmake install The mere fact, that it gets through the build and install phase of course doesn't mean the resulting files will be able to actually do anything useful for us, but it might be a start, at least. Since I just had a very quick look at the documentation of SOGO, I'm not able to supply any more hints at this time. Seeing Funambol being mentioned raised my interesst, though. MfG CoCo ___ 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: [Call For Testing] VirtualBox for FreeBSD! take 4
Martin Wilke wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Howdy, [...] Happy Testing :-) [...] I've successfully migrated two Microsoft Windows 2003 Server Standard x64 Edition SP2 testing machines (running MS IIS, MS SQL Server and an inhouse application) from VMWare Server 1.0.9 on Wintel to virtualbox-2.2.2r1985 on a freshly installed FreeBSD/amd64 7.2-RELEASE with sources as of the day before yesterday. I'm using "Internal network" to connect both machines, and so far VirtualBox played nicely during my 24 hour testing run. As this is a lab machine, I'm in a position to fiddle with it at will; just tell me what you'd like to see tested, if anything. CPU is an AMD Athlon X2 Dual Core (4850e), 8GB RAM, mainboard is a MSI K9N Neo V3 and the graphics card is an ATI X550. I've attached the dmesg. Thank you for bringing VirtualBox to FreeBSD ! MfG CoCo Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.2-RELEASE #0: Sat May 30 22:08:10 CEST 2009 r...@amd64.c0c0.intra:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Processor model unknown (2487.35-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x60fb2 Stepping = 2 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x11f TSC: P-state invariant Cores per package: 2 usable memory = 8576651264 (8179 MB) avail memory = 8275107840 (7891 MB) ACPI APIC Table: <112007 APIC1437> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: <112007 RSDT1437> on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of fec0, fed4 (3) failed acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, cff0 (3) failed Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x2008-0x200b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.0 (no driver attached) isab0: port 0x2f00-0x2fff at device 1.0 on pci0 isa0: on isab0 pci0: at device 1.1 (no driver attached) pci0: at device 1.2 (no driver attached) ohci0: mem 0xfe8ff000-0xfe8f irq 21 at device 2.0 on pci0 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 10 ports with 10 removable, self powered ehci0: mem 0xfe8fec00-0xfe8fecff irq 22 at device 2.1 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb1: EHCI version 1.0 usb1: companion controller, 10 ports each: usb0 usb1: on ehci0 usb1: USB revision 2.0 uhub1: on usb1 uhub1: 10 ports with 10 removable, self powered uhub2: on uhub1 uhub2: single transaction translator uhub2: 4 ports with 4 removable, self powered ums0: on uhub2 ums0: 6 buttons and Z dir. ukbd0: on uhub2 kbd2 at ukbd0 pci0: at device 7.0 (no driver attached) pcib1: at device 8.0 on pci0 pci1: on pcib1 xl0: <3Com 3c905B-TX Fast Etherlink XL> port 0xcc00-0xcc7f mem 0xfe9ffc00-0xfe9ffc7f irq 16 at device 10.0 on pci1 miibus0: on xl0 xlphy0: <3Com internal media interface> PHY 24 on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: Ethernet address: 00:04:76:d1:dc:9a xl0: [ITHREAD] atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 9.0 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] atapci1: port 0xf80-0xf87,0xf00-0xf03,0xe80-0xe87,0xe00-0xe03,0xa800-0xa80f mem 0xfe8fc000-0xfe8fdfff irq 20 at device 10.0 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] pcib2: at device 11.0 on pci0 pci2: on pcib2 pcib3: at device 12.0 on pci0 pci3: on pcib3 re0: port 0xd800-0xd8ff mem 0xfeaff000-0xfeaf irq 17 at device 0.0 on pci3 re0: Using 1 MSI messages re0: Chip rev. 0x3800 re0: MAC rev. 0x miibus1: on re0 rgephy0: PHY 1 on miibus1 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: 00:1d:92:84:e5:8b re0: [FILTER] pcib4: at device 13.0 on pci0 pci4: on pcib4 vgapci0: port 0xe000-0xe0ff mem 0xd000-0xdfff,0xfebf-0xfebf irq 18 at device 0.0 on pci4 vgapci1: mem 0xfebe-0xfebe at device 0.1 on pci4 pcib5: at device 14.0 on pci0 pci5: on pcib5 acpi_button0: on acpi0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FI
