sysutils/cdrtools in i386 chroot on amd64
I am trying to build all ports that I have installed in an i386 chroot environment on an amd64 machine. All work except for sysutils/cdrtools. I have installed an i386 system to some directory, mounted a devfs to the devfs subdirectory, set MACHINE=i386 ; UNAME_p=i386 ; UNAME_m=i386 and exported them, chrooted to the directory, and called /etc/rc.d/ldconfig start. sysutils/cdrtools fails with many errors as it still builds for amd64. Is this expected? Should I do more to get an i386 environment? (I have tried to set ARCH and MACHINE_ARCH with no change.) sysutils/cdrtools/Makefile mentions: Hack to allow building with TARGET and TARGET_ARCH set in the environment as done by the release building scripts. This seems to be the problem as all the variables I set cannot have an effect. How can I work around that hack except for changing the Makefile? Could the port detect if it is called from the release building scripts and only apply the hack in that case? Cheers, Jan Henrik ___ 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: [PATCH] Proposal for a new option framework
On 17/11/2010 15:58, Baptiste Daroussin wrote:
Hi all,
I'd like to expose you a new proposal for the framework option.
First the problem with the actual situation.
the option framework has some problems :
- for a given option we have two variable : WITH_OPT WITHOUT_OPT only
having to check one will be great.
- the option framework isn't consistent : if you set a WITH_BLA in
/etc/make.conf, make config doesn't mind about it for example.
So here is my proposal and a patch that implements it :
for porters :
3 types of options : simple, group and list
- simple options are the same as the current options (ie user can
activate what ever they wants)
- group options are options where at least one has to be set (1-N)
- list options are options where only one has to be set and only one
can be set (exclusive options)
a maintainer can defined them it the ports and some can be defined system wide.
every options can have a description but this is not mandatory.
maintainer can set default options (DEFAULT_OPTS) and remove global
options that the ports doesn't support yet OPTS_RM.
in a ports how to define them like this
OPTS= OPT1 OPT2 OPT3
OPTS_GROUP= GRP1 GRP2
OPTS_GROUP_GRP1= OPT4 OPT5
OPTS_GROUP_GRP2= OPT6 OPT7
OPTS_LIST= LIST1
OPTS_LIST_LIST1= OPT8 OTP9 OPT10
DEFAULT_OPTS= OPT2 OPT3 OPT9 OPT7 OPT8 OPT4
OPTS_RM= NLS NOPORTDOCS
to define a desciption for a given option :
OPT1_DESC= Description of my option
make showoptions will present all the options and their descriptions :
=== The following configuration options are available:
OPT1=off: Description of my option
OPT2=on
OPT3=on
Options available for the group GRP1: you have to choose at
least one of them
OPT4=on
OPT5=off
Options available for the group GRP2: you have to choose at
least one of them
OPT6=off
OPT7=on
Options available for the group LIST1: you have to select only one of
them
OPT8=on
OPT9=off
OPT10=off
a user can set in make.conf global options for the whole ports :
OPTS_SET= OPT1 OPT3
of unset them system wide
OPTS_UNSET= OPT10 OPT15
per port options can be specified in two ways for a given ports :
through /etc/make.conf:
${UNIQUENAME}_OPTS_SET= OPT1
${UNIQUENAME}_OPTS_UNSET= OPT2
for zsh it would be:
zsh_OPTS_SET= OPT1
zsh_OPTS_UNSET= OPT2
through /var/db/ports/${UNIQUENAME}/opts (in case we add a dialog like feature)
OPTS_SET= OPT1
OPTS_UNSET= OPT2
The framework check how the options are set in the following way :
1/ set the default options has wanted by the maintainer
2/ override them using the system wide options (OPTS_(UN)SET)
3/ the per ports defined options in /var/db/ports/${UNIQUENAME}/opts
4/ the per ports defined options in make.conf ${UNIQUENAME}_OPTS_(UN)SET
We can maintain some generic options descriptions like it is done in the KNOBS
for the maintainer to check if an option is set or not, we do not need
to choose between WITHOUT ou WITH option the options as to be checked
that way:
if !empty(PORTS_OPTS:MOPT1)
@${ECHO_CMD} the options OPT1 is set
.else
@${ECHO_CMD} the options OPT2 is not set
.endif
the framework check (check-options) for the consitency for the options
set (exclusive options and 1-n option)
In the patch nothing is activated by default (user has make
check-options himself currently)
there is nothing to create /var/db/ports/${UNIQUENAME}/opts it don't
really like having a gui for that but I understand some prefers and I
am checking how to make dialog4ports able to do the job.
The new framework can live with the old one
The implementation is really really simple.
In the implementation I added 3 global options: NOPORTDOCS NOPORTDATA
NOPORTEXAMPLES
Variable names are temporary if you have better ideas :)
I think it is quite easy to extend to add features later.
http://people.freebsd.org/~bapt/ports-newopts.patch
This is the best thing that could happens to the FreeBSD ports. Now the
ports OPTIONS framework lacks a lot of feature. We can't select only
one option in a list of (like pkgsrc does) and this new framework may
provides this feature !
The group feature may helps in a backend dependency too!
I really like this new framework and hope will be bring to ports before
2026 :-).
Thanks bapt.
--
David Demelier
___
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: [PATCH] Proposal for a new option framework
On 17/11/2010 15:58, Baptiste Daroussin wrote:
Hi all,
I'd like to expose you a new proposal for the framework option.
First the problem with the actual situation.
the option framework has some problems :
- for a given option we have two variable : WITH_OPT WITHOUT_OPT only
having to check one will be great.
- the option framework isn't consistent : if you set a WITH_BLA in
/etc/make.conf, make config doesn't mind about it for example.
So here is my proposal and a patch that implements it :
for porters :
3 types of options : simple, group and list
- simple options are the same as the current options (ie user can
activate what ever they wants)
- group options are options where at least one has to be set (1-N)
- list options are options where only one has to be set and only one
can be set (exclusive options)
a maintainer can defined them it the ports and some can be defined system wide.
every options can have a description but this is not mandatory.
maintainer can set default options (DEFAULT_OPTS) and remove global
options that the ports doesn't support yet OPTS_RM.
in a ports how to define them like this
OPTS= OPT1 OPT2 OPT3
OPTS_GROUP= GRP1 GRP2
OPTS_GROUP_GRP1= OPT4 OPT5
OPTS_GROUP_GRP2= OPT6 OPT7
OPTS_LIST= LIST1
OPTS_LIST_LIST1= OPT8 OTP9 OPT10
DEFAULT_OPTS= OPT2 OPT3 OPT9 OPT7 OPT8 OPT4
OPTS_RM= NLS NOPORTDOCS
to define a desciption for a given option :
OPT1_DESC= Description of my option
make showoptions will present all the options and their descriptions :
=== The following configuration options are available:
OPT1=off: Description of my option
OPT2=on
OPT3=on
Options available for the group GRP1: you have to choose at
least one of them
OPT4=on
OPT5=off
Options available for the group GRP2: you have to choose at
least one of them
OPT6=off
OPT7=on
Options available for the group LIST1: you have to select only one of
them
OPT8=on
OPT9=off
OPT10=off
a user can set in make.conf global options for the whole ports :
OPTS_SET= OPT1 OPT3
of unset them system wide
OPTS_UNSET= OPT10 OPT15
per port options can be specified in two ways for a given ports :
through /etc/make.conf:
${UNIQUENAME}_OPTS_SET= OPT1
${UNIQUENAME}_OPTS_UNSET= OPT2
for zsh it would be:
zsh_OPTS_SET= OPT1
zsh_OPTS_UNSET= OPT2
through /var/db/ports/${UNIQUENAME}/opts (in case we add a dialog like feature)
OPTS_SET= OPT1
OPTS_UNSET= OPT2
The framework check how the options are set in the following way :
1/ set the default options has wanted by the maintainer
2/ override them using the system wide options (OPTS_(UN)SET)
3/ the per ports defined options in /var/db/ports/${UNIQUENAME}/opts
4/ the per ports defined options in make.conf ${UNIQUENAME}_OPTS_(UN)SET
We can maintain some generic options descriptions like it is done in the KNOBS
for the maintainer to check if an option is set or not, we do not need
to choose between WITHOUT ou WITH option the options as to be checked
that way:
if !empty(PORTS_OPTS:MOPT1)
@${ECHO_CMD} the options OPT1 is set
.else
@${ECHO_CMD} the options OPT2 is not set
.endif
the framework check (check-options) for the consitency for the options
set (exclusive options and 1-n option)
In the patch nothing is activated by default (user has make
check-options himself currently)
there is nothing to create /var/db/ports/${UNIQUENAME}/opts it don't
really like having a gui for that but I understand some prefers and I
am checking how to make dialog4ports able to do the job.
The new framework can live with the old one
The implementation is really really simple.
In the implementation I added 3 global options: NOPORTDOCS NOPORTDATA
NOPORTEXAMPLES
Variable names are temporary if you have better ideas :)
I think it is quite easy to extend to add features later.
http://people.freebsd.org/~bapt/ports-newopts.patch
regards,
Bapt
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
This is the best thing that could happens to the FreeBSD ports. Now the
ports OPTIONS framework lacks a lot of feature. We can't select only
one option in a list of (like pkgsrc does) and this new framework may
provides this feature !
The group feature may helps in a backend dependency too!
I really like this new framework and hope will be bring to ports before
2026 :-).
Thanks bapt.
--
David Demelier
___
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: sysutils/cdrtools in i386 chroot on amd64
On Fri, Feb 11, 2011 at 02:34:02PM +0100, Jan Henrik Sylvester wrote: I am trying to build all ports that I have installed in an i386 chroot environment on an amd64 machine. All work except for sysutils/cdrtools. I have installed an i386 system to some directory, mounted a devfs to the devfs subdirectory, set MACHINE=i386 ; UNAME_p=i386 ; UNAME_m=i386 and exported them, chrooted to the directory, and called /etc/rc.d/ldconfig start. sysutils/cdrtools fails with many errors as it still builds for amd64. Is this expected? Should I do more to get an i386 environment? (I have tried to set ARCH and MACHINE_ARCH with no change.) Yes, that approach isn't expected to generally work for cross-building ports for i386 on amd64. What is expected to work is compiling them in an i386 environment on amd64 running a kernel with r210369/rev. 1.103 of sys/kern/kern_mib.c (r210855/rev. 1.98.2.5 for 8-STABLE) in place so the i386 binaries act as if they are running on native i386 without hacks like MACHINE, UNAME_* etc being set. The cdrtools port is known to be buildable for i386 in an i386 jail on amd64 that way. Marius ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
FreeBSD Port: nrpe-2.12_3
Howdy. I hope this is the right place to send a port bug report, but my apologies if not and I'll appreciate any redirection. It looks to me like the nrpe2 port is partly ignoring the WITH_OPENSSL_PORT=yes directive in /etc/make.conf. It does look in the right place during the dependencies check: === nrpe-2.12_3 depends on file: /usr/local/lib/libcrypto.so.7 - found and during the configure stage it also looks in the right place for the header files: checking for SSL headers... SSL headers found in /usr/local but it does *not* look in the right place for the library file: checking for SSL libraries... SSL libraries found in /usr/lib I found I was able to force it to the right place by specifying the make variable: CONFIGURE_ARGS=--with-ssl-lib=/usr/local/lib but I think the need to do that indicates a bug in the portification, yes? system: -FreeBSD 8.1 -nrpe-2.12_3 port -openssl-1.0.0_4 port installed Thanks much! adam ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
FreeBSD Port: subversion-1.6.15
Howdy. I hope this is the right place to send a port bug report, but my apologies if not and I'll appreciate any redirection. It looks to me like the subversion port is ignoring the MOD_DAV_SVN configuration setting, always behaving as if it's turned on even when it's not (which is the default). The mod_dav_svn.so and mod_authz_svn.so modules always get built into Apache's modules directory, and the corresponding LoadModule lines are always added to httpd.conf. I found I was able to force it not to build and load these modules by specifying the make argument: CONFIGURE_ARGS=--without-apxs but I think the need to do that indicates a bug in the portification, yes? system: -FreeBSD 8.1 -subversion 1.6.15 port -apache 2.2.17 from source Thanks much! adam ___ 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: FreeBSD Port: subversion-1.6.15
best to open a PR http://www.freebsd.org/support.html if you have a patch, against current ports tree, then you are more likely to get action. we all have day jobs. suggested subject line: [PATCH] fix mod_dav_svn config args. upload the patch, bump portrevision. On 2/11/11 3:34 PM, Adam Bernstein wrote: Howdy. I hope this is the right place to send a port bug report, but my apologies if not and I'll appreciate any redirection. -- Michael Scheidell, CTO o: 561-999-5000 d: 561-948-2259 ISN: 1259*1300 *| *SECNAP Network Security Corporation * Certified SNORT Integrator * 2008-9 Hot Company Award Winner, World Executive Alliance * Five-Star Partner Program 2009, VARBusiness * Best in Email Security,2010: Network Products Guide * King of Spam Filters, SC Magazine 2008 __ This email has been scanned and certified safe by SpammerTrap(r). For Information please see http://www.secnap.com/products/spammertrap/ __ ___ 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: FreeBSD Port: subversion-1.6.15
On 02/11/2011 12:38, Michael Scheidell wrote: suggested subject line: [PATCH] fix mod_dav_svn config args. For ports PRs please mention the category/portname in the subject. That way the auto-assigner can do its magic. hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD Port: subversion-1.6.15
In the case of this port, it explains to send the report directly to the maintainer. (I did that about 4 days ago and haven't heard any reply). I guess the answer is, when in doubt open a pr. Still, it's annoying to be misled in another direction. configure: error: no suitable apr found === Script configure failed unexpectedly. Please report the problem to l...@freebsd.org [maintainer] and attach the /usr/ports/devel/subversion/work/subversion-1.6.15/config.log including the output of the failure of your make command. Also, it might be a good idea to provide an overview of all packages installed on your system (e.g. an `ls /var/db/pkg`). *** Error code 1 -- Mark D. Foster m...@foster.cc http://mark.foster.cc/ ___ 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
