Re: optionsng and tinderbox?
On Fri, Jun 22, 2012 at 06:14:00PM -0700, Doug Barton wrote:
On 06/22/2012 10:44, Olli Hauer wrote:
On 2012-06-21 11:26, Ganael LAPLANCHE wrote:
On Wed, 20 Jun 2012 13:28:26 +0100, Matthew Seaman wrote
[...]
Shouldn't make.conf / commandline settings override OPTIONSFILE rather
than the other way round? Seems there's not much point in being able to
set options from make.conf unless that is so, as OPTIONSFILE would be
created more often than not whenever make(1) was invoked in the port's
directory.
I think that command-line options should always override file ones, but
the main problem here is that we cannot distinguish what comes from the
command line from what comes from make.conf.
What would sound logical to me would be the following order of precedence :
make.conf - overridden by option files - overridden by command line
This looks wrong to me.
Options set in make.conf should not be overwritten by the option file
else you don't need etc/make.conf at all.
Right. make.conf and options files should be flipped in the example above.
Doug
Well the priority ordering the logical was to give the end word to the last user
action.
It goes from global to specific
1/ the global options (infrastructures) are applied
2/ the maintainer option (ports are applied)
3/ the user global options are applied (OPTIONS_{,UN}SET)
4/ the user ports options are applied (${UNIQUENAME}_{,UN}SET)
5/ the dialog (make config) options are applied
If that it looks not good to anyone, please comment (we can still change it) and
please provide arguments.
regards,
Bapt
pgpNssTSfm2RC.pgp
Description: PGP signature
Re: Linux binary looks for /proc/cpuinfo, dies when cannot be found, even when linprocfs mounted.
On Sat, Jun 23, 2012 at 02:23:42PM +1200, Benjamin wrote: Hi all. I have posted this question on the forums, and it was suggested that I post it here. I am currently porting Altera Quartus II design software to FreeBSD. I have got it installing, but running the binary requires /proc/cpuinfo to exist, and it dies when it can't find it. I have both procfs and linprocfs mounted. To be sure, show us the mount -v output. As a workaround (read hack) I can do the following to make the binary execute. 1. unmount procfs. 2. symlink /compat/linux/proc/cpuinfo to /proc/cpuinfo Since this problem has no doubt come up before, what is the best way to get around this issue? No, it did not came up before. Show the file(1) output on the binary which exhibit the faulty behaviour. Cheers, Benjamin ___ 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 pgptmTGLaNL81.pgp Description: PGP signature
Re: optionsng and tinderbox?
On 2012-06-23 10:18, Baptiste Daroussin wrote:
On Fri, Jun 22, 2012 at 06:14:00PM -0700, Doug Barton wrote:
On 06/22/2012 10:44, Olli Hauer wrote:
On 2012-06-21 11:26, Ganael LAPLANCHE wrote:
On Wed, 20 Jun 2012 13:28:26 +0100, Matthew Seaman wrote
[...]
Shouldn't make.conf / commandline settings override OPTIONSFILE rather
than the other way round? Seems there's not much point in being able to
set options from make.conf unless that is so, as OPTIONSFILE would be
created more often than not whenever make(1) was invoked in the port's
directory.
I think that command-line options should always override file ones, but
the main problem here is that we cannot distinguish what comes from the
command line from what comes from make.conf.
What would sound logical to me would be the following order of precedence :
make.conf - overridden by option files - overridden by command line
This looks wrong to me.
Options set in make.conf should not be overwritten by the option file
else you don't need etc/make.conf at all.
Right. make.conf and options files should be flipped in the example above.
Doug
Well the priority ordering the logical was to give the end word to the last
user
action.
It goes from global to specific
1/ the global options (infrastructures) are applied
2/ the maintainer option (ports are applied)
3/ the user global options are applied (OPTIONS_{,UN}SET)
4/ the user ports options are applied (${UNIQUENAME}_{,UN}SET)
5/ the dialog (make config) options are applied
If that it looks not good to anyone, please comment (we can still change it)
and
please provide arguments.
regards,
Bapt
OK, in case of tinderbox or any other build system think about the following.
You do a build for production or testing and it is required to always use pgsql
and *really* avoid mysql (real use case in my prod builds, I don't care
about mysql only ports, I just stay away from them).
Now you create a fresh build and set the proper build options in build.xxx or
inject a make.conf via post-extract hook since there you want to define with
two statements the dependencies.
- OPTIONS_UNSET+=MYSQL
- OPTIONS_SET+=PGSQL
This will not work if the directives are overwritten by /4 and /5.
In case of ports-mgmt/tinderbox you will end with a mysql enabled tinderbox :(
To prevent this you have to go over a whole build and all configure dialogs to
make sure this settings are in place which is not practical, time consuming
and error prone.
Luckily at the moment /4 and /5 can be overwritten with the old WITH|OUT_$opt
directives since this logic is applied as last in bsd.options.mk
So ether fix the logic or keep the old WITH|OUT_$opt logic in bsd.options.mk
so we can use make.conf last file of defense.
--
Regards,
olli
___
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 and tinderbox?
On 23/06/2012 09:18, Baptiste Daroussin wrote:
Well the priority ordering the logical was to give the end word to the last
user
action.
It goes from global to specific
1/ the global options (infrastructures) are applied
2/ the maintainer option (ports are applied)
3/ the user global options are applied (OPTIONS_{,UN}SET)
4/ the user ports options are applied (${UNIQUENAME}_{,UN}SET)
5/ the dialog (make config) options are applied
If that it looks not good to anyone, please comment (we can still change it)
and
please provide arguments.
It's the ordering of 4 and 5 that confuses me.
If you've got ${UNIQUENAME}_{,UN}SET in /etc/make.conf and then you run
'make config' you'ld expect the choices you make in the dialogue to be
the final word. (ie. 5 overrides 4, as currently) (Would you expect the
make.conf setting to affect what is shown in the dialog initially?
Seems logical)
On the other hand, if you run 'make foo_SET=yes all' on a command line,
you'ld expect the command line to override anything saved in an options
file (ie 4 overrides 5).
I don't think you can have both of those behaviours in any reasonable
way. If forced to choose, I'd prefer to have the capability to override
a config setting as a one-off on the command line.
Also given that in normal usage, selections would always be made in the
options dialogue when the port was compiled, so they would always
override any ${UNIQUENAME}_{,UN}SET setting in /etc/make.conf or from
the command line. Which implies ${UNIQUENAME}_{,UN}SET only has any
utility when the options dialogues are not used, such as in tinderbox or
other port building systems. Swapping 4 and 5 would make the behaviour
more consistent for all usage patterns.
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil.
PGP: http://www.infracaninophile.co.uk/pgpkey
signature.asc
Description: OpenPGP digital signature
Re: optionsng and tinderbox?
On Sat, Jun 23, 2012 at 11:11:49AM +0200, Olli Hauer wrote:
On 2012-06-23 10:18, Baptiste Daroussin wrote:
On Fri, Jun 22, 2012 at 06:14:00PM -0700, Doug Barton wrote:
On 06/22/2012 10:44, Olli Hauer wrote:
On 2012-06-21 11:26, Ganael LAPLANCHE wrote:
On Wed, 20 Jun 2012 13:28:26 +0100, Matthew Seaman wrote
[...]
Shouldn't make.conf / commandline settings override OPTIONSFILE rather
than the other way round? Seems there's not much point in being able to
set options from make.conf unless that is so, as OPTIONSFILE would be
created more often than not whenever make(1) was invoked in the port's
directory.
I think that command-line options should always override file ones, but
the main problem here is that we cannot distinguish what comes from the
command line from what comes from make.conf.
What would sound logical to me would be the following order of
precedence :
make.conf - overridden by option files - overridden by command line
This looks wrong to me.
Options set in make.conf should not be overwritten by the option file
else you don't need etc/make.conf at all.
Right. make.conf and options files should be flipped in the example above.
Doug
Well the priority ordering the logical was to give the end word to the last
user
action.
It goes from global to specific
1/ the global options (infrastructures) are applied
2/ the maintainer option (ports are applied)
3/ the user global options are applied (OPTIONS_{,UN}SET)
4/ the user ports options are applied (${UNIQUENAME}_{,UN}SET)
5/ the dialog (make config) options are applied
If that it looks not good to anyone, please comment (we can still change
it) and
please provide arguments.
regards,
Bapt
OK, in case of tinderbox or any other build system think about the following.
You do a build for production or testing and it is required to always use
pgsql
and *really* avoid mysql (real use case in my prod builds, I don't care
about mysql only ports, I just stay away from them).
Now you create a fresh build and set the proper build options in build.xxx or
inject a make.conf via post-extract hook since there you want to define with
two statements the dependencies.
- OPTIONS_UNSET+=MYSQL
- OPTIONS_SET+=PGSQL
This will not work if the directives are overwritten by /4 and /5.
In case of ports-mgmt/tinderbox you will end with a mysql enabled tinderbox :(
To prevent this you have to go over a whole build and all configure dialogs to
make sure this settings are in place which is not practical, time consuming
and error prone.
Luckily at the moment /4 and /5 can be overwritten with the old WITH|OUT_$opt
directives since this logic is applied as last in bsd.options.mk
So ether fix the logic or keep the old WITH|OUT_$opt logic in bsd.options.mk
so we can use make.conf last file of defense.
--
Regards,
olli
Well when you run from tinderbox or any automated build stuff, you don't run
make config so 5 never occurs.
4/ is made to give a finer grain for specific options for a given ports and is
set from make.conf so you can easily tune it for your tinderbox.
regards,
Bapt
pgpqobrrnTy5v.pgp
Description: PGP signature
Re: optionsng and tinderbox?
On 2012-06-23 11:23, Matthew Seaman wrote:
On 23/06/2012 09:18, Baptiste Daroussin wrote:
Well the priority ordering the logical was to give the end word to the last
user
action.
It goes from global to specific
1/ the global options (infrastructures) are applied
2/ the maintainer option (ports are applied)
3/ the user global options are applied (OPTIONS_{,UN}SET)
4/ the user ports options are applied (${UNIQUENAME}_{,UN}SET)
5/ the dialog (make config) options are applied
If that it looks not good to anyone, please comment (we can still change it)
and
please provide arguments.
It's the ordering of 4 and 5 that confuses me.
If you've got ${UNIQUENAME}_{,UN}SET in /etc/make.conf and then you run
'make config' you'ld expect the choices you make in the dialogue to be
the final word. (ie. 5 overrides 4, as currently) (Would you expect the
make.conf setting to affect what is shown in the dialog initially?
Seems logical)
No, I don't expect to see this see setting from make.conf in dialog
since I'm aware I've overwritten this in make.conf.
The other way around knowing you have set this explicit in make.conf and it
is overwritten later get me a bad feeling.
I suspect normal users don't use make.conf to control port builds except
for gcc/clang ... settings.
On the other hand, if you run 'make foo_SET=yes all' on a command line,
you'ld expect the command line to override anything saved in an options
file (ie 4 overrides 5).
Not for all dependency but for the actual port in ${.CURDIR}.
I don't think you can have both of those behaviours in any reasonable
way. If forced to choose, I'd prefer to have the capability to override
a config setting as a one-off on the command line.
Also given that in normal usage, selections would always be made in the
options dialogue when the port was compiled, so they would always
override any ${UNIQUENAME}_{,UN}SET setting in /etc/make.conf or from
the command line. Which implies ${UNIQUENAME}_{,UN}SET only has any
utility when the options dialogues are not used, such as in tinderbox or
other port building systems. Swapping 4 and 5 would make the behaviour
more consistent for all usage patterns.
Yes, sometimes I have to run 'make configure' with different command line
parameter only and save the config.log(s) to compare them later.
Not really handy to run all the time 'make configure' since this will break
automated test scripting. For example a script which builds devel/apr in a
loop with all possible options where you have for your daily work an option
file in place. Ok, for this case you could move the option file to another
location and run your scripts ...
--
Regatds,
olli
___
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 and tinderbox?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 06/23/2012 01:18, Baptiste Daroussin wrote:
Well the priority ordering the logical was to give the end word to
the last user action.
It goes from global to specific
1/ the global options (infrastructures) are applied 2/ the
maintainer option (ports are applied) 3/ the user global options
are applied (OPTIONS_{,UN}SET) 4/ the user ports options are
applied (${UNIQUENAME}_{,UN}SET) 5/ the dialog (make config)
options are applied
If that it looks not good to anyone, please comment (we can still
change it) and please provide arguments.
I'm not sure I explained myself well in the last message. I've already
discussed how make.conf should override the way the options are
presented to the user, which my understanding is that you've already
accomplished. That means that when 3 and 4 happen, the options
presented to the user will already reflect the global configuration
decisions made on the system level.
If at the point the options dialog is presented the user wants to
override the global choices for that particular port, fine. But the
global (make.conf, ports.conf, etc.) choices should always take
precedence absent this user twiddling, and when the options dialog is
first presented to the user it should *always* reflect the global
config choices by default, regardless of 1 and 2 in your list above.
Doug
- --
This .signature sanitized for your protection
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (FreeBSD)
iQEcBAEBCAAGBQJP5ZXPAAoJEFzGhvEaGryEv4cIAIATkjsdw6gr3SluCuuvvQgE
EXavIVGsHVpp0IuvkhNZzryH2TdZ4QUadquKRmHAWeIwyptxug8QMzZ7c2IG3Luf
CuC9KaMIjKnV6ADYMYIApb4pc581ivH4hutR81PB50AWRlGtmeysMKO4/SX0yT8Q
Asl7vMuMgpSNur8neH/vFVTvVs/b1jnHueHNIyzOAQWvga2aFLyzGcSsSaY+qJJ5
3EnnIbkzXvcX4l2VoZN6BSokaT7uXyRG0Ev6Fx0i45NJuul3+HsTKp3i/RZVEqg+
RawuBPIR2zM+IQOIop+43+5EQhUToB6fYvALIvO34OIhKv77hhJoFwFilRFluH0=
=MkNT
-END PGP SIGNATURE-
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Linux binary looks for /proc/cpuinfo, dies when cannot be found, even when linprocfs mounted.
On 06/23/12 20:57, Konstantin Belousov wrote: On Sat, Jun 23, 2012 at 02:23:42PM +1200, Benjamin wrote: Hi all. I have posted this question on the forums, and it was suggested that I post it here. I am currently porting Altera Quartus II design software to FreeBSD. I have got it installing, but running the binary requires /proc/cpuinfo to exist, and it dies when it can't find it. I have both procfs and linprocfs mounted. To be sure, show us the mount -v output. [snipped] linprocfs on /usr/compat/linux/proc (linprocfs, local) procfs on /proc (procfs, local) [/snipped] As a workaround (read hack) I can do the following to make the binary execute. 1. unmount procfs. 2. symlink /compat/linux/proc/cpuinfo to /proc/cpuinfo Since this problem has no doubt come up before, what is the best way to get around this issue? No, it did not came up before. Show the file(1) output on the binary which exhibit the faulty behaviour. Aha. I think you've identified the problem quartus_sh: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.2.5, not stripped brandelf(1)ing this to Linux seems to have worked. What does SYSV represent anyway? brandelf -l only lists known ELF types are: FreeBSD(9) Linux(3) Solaris(6) SVR4(0) so what does SYSV mean? Cheers. ___ 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: Linux binary looks for /proc/cpuinfo, dies when cannot be found, even when linprocfs mounted.
On Sat, Jun 23, 2012 at 09:55:22PM +1200, Benjamin wrote: On 06/23/12 20:57, Konstantin Belousov wrote: On Sat, Jun 23, 2012 at 02:23:42PM +1200, Benjamin wrote: Hi all. I have posted this question on the forums, and it was suggested that I post it here. I am currently porting Altera Quartus II design software to FreeBSD. I have got it installing, but running the binary requires /proc/cpuinfo to exist, and it dies when it can't find it. I have both procfs and linprocfs mounted. To be sure, show us the mount -v output. [snipped] linprocfs on /usr/compat/linux/proc (linprocfs, local) procfs on /proc (procfs, local) [/snipped] As a workaround (read hack) I can do the following to make the binary execute. 1. unmount procfs. 2. symlink /compat/linux/proc/cpuinfo to /proc/cpuinfo Since this problem has no doubt come up before, what is the best way to get around this issue? No, it did not came up before. Show the file(1) output on the binary which exhibit the faulty behaviour. Aha. I think you've identified the problem quartus_sh: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.2.5, not stripped brandelf(1)ing this to Linux seems to have worked. What does SYSV represent anyway? brandelf -l only lists known ELF types are: FreeBSD(9) Linux(3) Solaris(6) SVR4(0) so what does SYSV mean? There it means that an old branding method was not used on the binary. Note that the note is present in the executable, so even file is able to identify the binary as using Linux ABI. I very much doubt that your report of 'crash' was due to unability to open /proc/cpuinfo, the failure scenario should be much more spectacular and fun to watch. What version of the kernel do you use and what arch ? We have support for note-based ABI branding for very long time. I wonder is your kernel so ancient that it lacks the support, or we have a regression. Can you put the binary somewere so I can look into it ? pgpCEUueB7rm8.pgp Description: PGP signature
Unable to build /devel/kdebindings4-ruby-korundum
FreeBSD 8.3-STABLE #0 amd64 The build of devel/kdebindings4-ruby-korundum always ends in an error. The truncated build log showing the error messages follows. The entire build log is available upon request. Rather than just filing a PR, I wanted to see if anyone else had experienced this phenomenon. The build always ends like this: [ 58%] Built target rubyokular /usr/local/bin/cmake -E cmake_progress_report /usr/ports/devel/kdebindings4-ruby-korundum/work/korundum-4.8.4/CMakeFiles 6 [ 61%] Building CXX object src/CMakeFiles/korundum4.dir/kdehandlers.o cd /usr/ports/devel/kdebindings4-ruby-korundum/work/korundum-4.8.4/src /usr/bin/c++ -DMAKE_KORUNDUM4_LIB -DQT_QTDBUS -DRUBY_VERSION=0x10807 -O2 -pipe -march=native -fno-strict-aliasing -Woverloaded-virtual -fvisibility=hidden -Werror=return-type -fvisibility-inlines-hidden -O2 -DNDEBUG -DQT_NO_DEBUG -fPIC -I/usr/ports/devel/kdebindings4-ruby-korundum/work/korundum-4.8.4/src -I/usr/ports/devel/kdebindings4-ruby-korundum/work/korundum-4.8.4/generator -I/usr/ports/devel/kdebindings4-ruby-korundum/work/korundum-4.8.4/ruby/qtruby/src -I/usr/local/kde4/include -I/usr/local/kde4/include/KDE -I/usr/local/include/qt4/phonon -I/usr/local/include/qt4/QtXmlPatterns -I/usr/local/include/qt4/QtXml -I/usr/local/include/qt4/QtWebKit -I/usr/local/include/qt4/QtUiTools -I/usr/local/include/qt4/QtTest -I/usr/local/include/qt4/QtSvg -I/usr/local/include/qt4/QtSql -I/usr/local/include/qt4/QtScriptTools -I/usr/local/include/qt4/QtScript -I/usr/local/include/qt4/QtOpenGL -I/usr/local/include/qt4/QtNetwork -I/usr/local/include/qt4/QtMultimedia -I/usr/local/include/qt4/QtHelp -I/usr/local/include/qt4/QtDesigner -I/usr/local/include/qt4/QtDeclarative -I/usr/local/include/qt4/QtDBus -I/usr/local/include/qt4/Qt3Support -I/usr/local/include/qt4/QtGui -I/usr/local/include/qt4/QtCore -I/usr/local/include/qt4/Qt -I/usr/local/share/qt4/mkspecs/default -I/usr/local/include/qt4 -I/usr/local/include -I/usr/local/kde4/include/smoke -I/usr/local/kde4/include/qtruby -I/usr/local/lib/ruby/1.8/amd64-freebsd8 -o CMakeFiles/korundum4.dir/kdehandlers.o -c /usr/ports/devel/kdebindings4-ruby-korundum/work/korundum-4.8.4/src/kdehandlers.cpp make -f src/CMakeFiles/krubyapplication.dir/build.make src/CMakeFiles/krubyapplication.dir/depend cd /usr/ports/devel/kdebindings4-ruby-korundum/work/korundum-4.8.4 /usr/local/bin/cmake -E cmake_depends Unix Makefiles /usr/ports/devel/kdebindings4-ruby-korundum/work/korundum-4.8.4 /usr/ports/devel/kdebindings4-ruby-korundum/work/korundum-4.8.4/src /usr/ports/devel/kdebindings4-ruby-korundum/work/korundum-4.8.4 /usr/ports/devel/kdebindings4-ruby-korundum/work/korundum-4.8.4/src /usr/ports/devel/kdebindings4-ruby-korundum/work/korundum-4.8.4/src/CMakeFiles/krubyapplication.dir/DependInfo.cmake --color= Scanning dependencies of target krubyapplication make -f src/CMakeFiles/krubyapplication.dir/build.make src/CMakeFiles/krubyapplication.dir/build /usr/local/bin/cmake -E cmake_progress_report /usr/ports/devel/kdebindings4-ruby-korundum/work/korundum-4.8.4/CMakeFiles 7 [ 64%] Building CXX object src/CMakeFiles/krubyapplication.dir/krubyapplication_automoc.o cd /usr/ports/devel/kdebindings4-ruby-korundum/work/korundum-4.8.4/src /usr/bin/c++ -DQT_QTDBUS -DRUBY_VERSION=0x10807 -O2 -pipe -march=native -fno-strict-aliasing -Woverloaded-virtual -fvisibility=hidden -Werror=return-type -fvisibility-inlines-hidden -O2 -DNDEBUG -DQT_NO_DEBUG -I/usr/ports/devel/kdebindings4-ruby-korundum/work/korundum-4.8.4/src -I/usr/ports/devel/kdebindings4-ruby-korundum/work/korundum-4.8.4/generator -I/usr/ports/devel/kdebindings4-ruby-korundum/work/korundum-4.8.4/ruby/qtruby/src -I/usr/local/kde4/include -I/usr/local/kde4/include/KDE -I/usr/local/include/qt4/phonon -I/usr/local/include/qt4/QtXmlPatterns -I/usr/local/include/qt4/QtXml -I/usr/local/include/qt4/QtWebKit -I/usr/local/include/qt4/QtUiTools -I/usr/local/include/qt4/QtTest -I/usr/local/include/qt4/QtSvg -I/usr/local/include/qt4/QtSql -I/usr/local/include/qt4/QtScriptTools -I/usr/local/include/qt4/QtScript -I/usr/local/include/qt4/QtOpenGL -I/usr/local/include/qt4/QtNetwork -I/usr/local/include/qt4/QtMultimedia -I/usr/local/include/qt4/QtHelp -I/usr/local/include/qt4/QtDesigner -I/usr/local/include/qt4/QtDeclarative -I/usr/local/include/qt4/QtDBus -I/usr/local/include/qt4/Qt3Support -I/usr/local/include/qt4/QtGui -I/usr/local/include/qt4/QtCore -I/usr/local/include/qt4/Qt -I/usr/local/share/qt4/mkspecs/default -I/usr/local/include/qt4 -I/usr/local/include -I/usr/local/kde4/include/smoke -I/usr/local/kde4/include/qtruby -I/usr/local/lib/ruby/1.8/amd64-freebsd8 -o CMakeFiles/krubyapplication.dir/krubyapplication_automoc.o -c /usr/ports/devel/kdebindings4-ruby-korundum/work/korundum-4.8.4/src/krubyapplication_automoc.cpp /usr/local/bin/cmake -E cmake_progress_report /usr/ports/devel/kdebindings4-ruby-korundum/work/korundum-4.8.4/CMakeFiles 8 [ 67%] Building CXX object
Fwd: Re: Linux binary looks for /proc/cpuinfo, dies when cannot be found, even when linprocfs mounted.
Original Message Subject: Re: Linux binary looks for /proc/cpuinfo, dies when cannot be found, even when linprocfs mounted. Date: Sat, 23 Jun 2012 22:56:38 +1200 From: Benjamin by...@uclive.ac.nz To: Konstantin Belousov kostik...@gmail.com I very much doubt that your report of 'crash' was due to unability to open /proc/cpuinfo, the failure scenario should be much more spectacular and fun to watch. grep: /proc/cpuinfo: No such file or directory The Quartus II software is optimized for the Intel Pentium III processor and newer processors. The required extensions were not found on: '' The Quartus II software will not function properly on this processor model. Terminating... exit: Illegal number: -1 What version of the kernel do you use and what arch ? We have support for note-based ABI branding for very long time. I wonder is your kernel so ancient that it lacks the support, or we have a regression. FreeBSD foo@bar.weasel 8.2-STABLE FreeBSD 8.2-STABLE #0: Sat Mar 26 19:15:18 NZDT 2011 foo@bar.weasel:/usr/obj/usr/src/sys/BLACKBOX i386 Can you put the binary somewere so I can look into it ? Probably not without breaking copyright. ___ 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: Re: Linux binary looks for /proc/cpuinfo, dies when cannot be found, even when linprocfs mounted.
On Sat, Jun 23, 2012 at 12:57 PM, Benjamin by...@uclive.ac.nz wrote: Probably not without breaking copyright. But the web edition of Quartus II is available for download: http://www.altera.com/download HTH -- Regards, Torfinn Ingolfsen ___ 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: Re: Linux binary looks for /proc/cpuinfo, dies when cannot be found, even when linprocfs mounted.
On Jun 23, 2012 12:18 PM, Torfinn Ingolfsen tin...@gmail.com wrote: On Sat, Jun 23, 2012 at 12:57 PM, Benjamin by...@uclive.ac.nz wrote: Probably not without breaking copyright. But the web edition of Quartus II is available for download: http://www.altera.com/download HTH -- Regards, Torfinn Ingolfsen Hm also surely counts as fair use... I'm sure that if upstream were told one of our kernel hackers were to attempt to fix their product on another platform, who would say no? Just ask them if unsure! Chris ___ 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: Linux binary looks for /proc/cpuinfo, dies when cannot be found, even when linprocfs mounted.
grep: /proc/cpuinfo: No such file or directory Err, so it was an error from grep ? I bet that some script run the host (FreeBSD) version of external utility, simply because there is no /compat/linux/usr/bin/grep installed. Then, since FreeBSD binary has FreeBSD branding, it indeed accessed native /proc, and not translated /compat/linux/proc. Correct. But this wasn't a script, it was an executable. In any case, using brandelf to mark in as Linux seems to have solved the problem. ___ 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: Wine-fbsd64 updated to 1.5.6 (32bit Wine for 64bit FreeBSD)
(ports@ folk may know more about pkgng)
David Naylor naylor.b.da...@gmail.com writes:
Hi,
Packages [1] for wine-fbsd64-1.5.6 have been uploaded to mediafire [2]. The
packages for FreeBSD 10 use the pkgng* [3] format.
[...]
* Support for pkgng has been added to the nvidia-patch script
pkgng seems to be more pedantic regarding conflicting files. And I
haven't found a way to force register a package.
$ sudo /usr/local/share/wine/patch-nvidia.sh
=== Patching wine-fbsd64 to work with x11/nvidia-driver:
= Detected wine-fbsd64: 1.5.6,1
!!! Unable to detect nvidia-driver, please install first !!!
Terminating...
Exit 1
$ make deinstall install -C x11/nvidia-driver
[...]
=== Registering installation for nvidia-driver-302.17
Installing nvidia-driver-302.17...pkg: nvidia-driver-302.17 conflicts with
xorg-server-1.12.1,1 (installs files into the same place). Problematic file:
/usr/local/lib/xorg/modules/extensions/libglx.so
*** [fake-pkg] Error code 3
$ pkg info nvidia-driver
pkg: No package(s) matching nvidia-driver
Exit 70
--- patch-nvidia.sh~
+++ patch-nvidia.sh
@@ -92,12 +92,20 @@ do
done
version() {
+ local ret pkg=$1
if [ -f /usr/local/sbin/pkg ]
then
-echo `pkg query -g '%v' $1`
+ret=`pkg query -g '%v' $pkg`
else
-echo `pkg_info -E $1'*' | cut -f 3 -d -`
+ret=`pkg_info -E $pkg'*' | cut -f 3 -d -`
fi
+ # installed manually or failed to register
+ if [ -z $ret ] [ $pkg = nvidia-driver ]
+ then
+ret=`sed 2/dev/null -n 's/.*Version: //p' \
+ $PREFIX/share/doc/NVIDIA_GLX-1.0/README || true`
+ fi
+ echo $ret
}
[ `whoami` = root ] \
___
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 and tinderbox?
23.06.2012 14:07, Olli Hauer пишет: I suspect normal users don't use make.conf to control port builds except for gcc/clang ... settings. I'm not sure if it is the case but I have at /etc/make.conf: - WITH_CUPS= YES CUPS_OVERWRITE_BASE=YES WANT_OPENLDAP_SASL= YES LOCALIZED_LANG= ru QT4_OPTIONS=CUPS NAS QGTKSTYLE WITHOUT_NOUVEAU=YES THUNDERBIRD_I18N= ru - -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ 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 and tinderbox?
On 6/23/12 11:12 AM, Boris Samorodov wrote:
and I have;
export WITHOUT_GUI=yes
export WITHOUT_X11=yes
# make.conf
export SECNAP_INDEXDIR=/disk1/tinderbox/packages/7-SECNAP_AMD64
#export SECNAP_INDEXDIR=/disk1/tinderbox/packages/7-SECNAP_I386-nox11
export WITH_BDB_VER=44
export WITH_OPENLDAP_VER=24
export WITHOUT_IPV6=yes
# with optnsng?
export OPTIONS_UNSET=IPV6\ KERBEROS\ DOCS\ EXAMPLES\ GUI\ X11
export WITHOUT_KERBEROS=true
export NO_INET6=true
export WITHOUT_INET6=true
export NET_SNMP_MIB_MODULES=host disman/event-mib mibII/mta_postfix
mibII/tcpTable ucd-snmp/diskio
export AX_SOCKONLY=true
export NOPORTDOCS=yes
export NOPORTEXAMPLES=yes
# php5 php53
export DEFAULT_PHP_VER=53
WITHOUT_APACHE=true
# nginx, old:
#export WITH_FILE_AIO=true
#export WITH_GZIP_STATIC_MODULE=true
#export WITH_IMAGE_FILTER_MODULE=true
#export WITHOUT_WWW=true
#export WITH_HTTP_ACCEPT_LANGUAGE=true
#export WITH_HTTP_ZIP_MODULE=true
#export WITH_HTTP_SSL_MODULE=true
#nginx, new:
#export WITH_FILE_AIO=true
#export WITH_GZIP_STATIC=true
#export WITH_IMAGE_FILTER=true
#export WITH_HTTP_ACCEPT_LANGUAGE=true
#export WITH_HTTP_ZIP=true
#export WITH_HTTP_SSL=true
#maybe better?
#export NGINX_OPTIONS_DEFAULT=FILE_AIO\ HTTP_GZIP_STATIC\ HTTP\
HTTP_CACHE\ HTTP_REWRITE\ HTTP_STATUS\ WWW\ HTTP_IMAGE_FILTER\
HTTP_ACCEPT_LANGUAGE\ HTTP_ZIP\ HTTP_SSL
export nginx_SET=FILE_AIO\ HTTP_GZIP_STATIC\ HTTP\ HTTP_CACHE\
HTTP_REWRITE\ HTTP_STATUS\ WWW\ HTTP_IMAGE_FILTER\ HTTP_ACCEPT_LANGUAGE\
HTTP_ZIP\ HTTP_SSL
#export nginx_SET=FILE_AIO
# mysql
export WANT_MYSQL_VER=51
export WITH_FAST_MUTEXES=yes
export BUILD_OPTIMIZED=yes
export WITH_PROC_SCOPE_PTH=yes
#p5-IO-Socket-SSL
export WITH_IDN=yes
#ntop
export WITH_PCAP_PORT=yes
export WITH_MAKO=yes
# gdbm
export WITH_COMPAT=yes
# postfix
export NO_SENDMAIL=true
export WITHOUT_SENDMAIL=yes
export POSTFIX_DEFAULT_MTA=yes
#export POSTFIX_OPTIONS=TLS MySQL BDB OpenLDAP # only first one
export POSTFIX_OPTIONS=TLS\ MySQL\ BDB\ OpenLDAP
# openvpn
export WITHOUT_CHECK=yes
export LOG_OPENVPN=LOG_LOCAL6
#snort
export WITHOUT_GRE=yes
export WITHOUT_TARGETBASED=yes
export WITHOUT_NORMALIZER=yes
export WITHOUT_REACT=yes
export WITH_SNORTSAM=yes
export WITHOUT_FLEXRESP3=yes
export SNORT_OPTIONS=ZLIB\ PERFPROFILE
#barnyard
export WITH_SNORT=yes
#elm
export WITHOUT_ELM_TLS=yes
#tripwire
export NO_DB_BUILD=true
#nessu
export WITHOUT_GNOME=yes
export WITHOUT_GTK=yes
export WITHOUT_NESSUS_GTK=yes
#clamav
export clamav_SET=ICONV
export clamav_UNSET=TESTS
#export WITHOUT_TESTS=yes
#export WITH_ICONV=yes
#spamassassin
export WITHOUT_AS_ROOT=yes
export WITHOUT_SPAMC=yes
export WITH_SACOMPILE=yes
export WITH_SPF_QUERY=yes
export WITH_RELAY_COUNTRY=yes
#amavisd-new
export WITH_MYSQL=yes
export WITH_LDAP=yes
export WITH_SPAMASSASSIN=yes
export WITH_ALTERMIME=yes
export WITHOUT_ARJ=yes
export WITH_UNZOO=yes
export WITHOUT_ZOO=yes
#glib
export WITHOUT_COLLATION_FIX=yes
#p5-Test_nowarnings
export DEVEL_STACKTRACE=yes
#p5-HTML-Mason
export WITHOUT_MOD_PERL=yes
export WITHOUT_APACHE2=yes
# perl
#export WITH_PERL_MALLOC=yes buserr on mx1. (7.3 and 7.4, amd64)
export WITH_PERL_64BITINT=default
export WITH_USE_PERL=default
#subversion16/svn
export WITHOUT_P4_STYLE_MARKERS=yes
export WITHOUT_EHNAHCED_KEYWORD=yes
export WITHOUT_FREEBSD_TEMPLATE=yes
export WITHOUT_NEON=yes
export WITH_SVNSERV_WRAPPER=yes
#.if ${.CURDIR:M*devel/apr1}
#export WITHOUT_MYSQL=yes
#export WITHOUT_LDAP=yes
#export WITHOUT_SQLITE=yes
#.endif
#unison:
export WITH_OPT_DEF=yes
export WITHOUT_DOCS=yes
--
Michael Scheidell, CTO
*| * SECNAP Network Security Corporation
d: +1.561.948.2259
w: http://people.freebsd.org/~scheidell
___
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
Anyone using perl-5.12 and WITH_PERL_MALLOC?
I have tried it a couple of times, hearing that is increases the
performance of security/amavisd-new, but each time I tried it:
on 7.3, and 7.4 amd64, I get 'bus error'
on 7.4 I386, I get 'Segmentation fault'
Not ready (yet) to diagnose this.
but, here were build options:
---Begin OPTIONS List---
=== The following configuration options are available for perl-5.12.4_4:
DEBUGGING=off: Build with debugging support
GDBM=off: Build GDBM_File extension
PERL_MALLOC=on: Use Perl malloc
PERL_64BITINT=on: Use 64 bit integers (on i386)
THREADS=off: Build threaded perl
PTHREAD=on: Build with -pthread
MULTIPLICITY=off: Use multiplicity
SITECUSTOMIZE=off: Run-time customization of @INC
USE_PERL=on: Rewrite links in /usr/bin
=== Use 'make config' to modify these settings
---End OPTIONS List---
(I noticed in the Makefile, if you have WITH_THREADS WITH_PERL_MALLOC,
.if defined(WITH_THREADS)
#XXX .if ${ARCH} == amd64
#XXX IGNORE=Threaded perl does not pass tests on ${ARCH}
#XXX .endif
CONFIGURE_ARGS+=-Dusethreads=y
PKGNAMESUFFIX= -threaded
WITH_PTHREAD= yes
# it seems perl malloc has problems with threaded perl on FreeBSD
.undef WITH_PERL_MALLOC
I wonder if this is true for WITH_PTHREAD (which is on by default)
anyone using it this way? with_perl_malloc? on 7.x?
is it broken on 7.x?
--
Michael Scheidell, CTO
*| * SECNAP Network Security Corporation
d: +1.561.948.2259
w: http://people.freebsd.org/~scheidell
___
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: Anyone using perl-5.12 and WITH_PERL_MALLOC?
On Sat, Jun 23, 2012 at 9:10 AM, Michael Scheidell
scheid...@freebsd.org wrote:
I have tried it a couple of times, hearing that is increases the performance
of security/amavisd-new, but each time I tried it:
on 7.3, and 7.4 amd64, I get 'bus error'
on 7.4 I386, I get 'Segmentation fault'
Not ready (yet) to diagnose this.
but, here were build options:
---Begin OPTIONS List---
=== The following configuration options are available for perl-5.12.4_4:
DEBUGGING=off: Build with debugging support
GDBM=off: Build GDBM_File extension
PERL_MALLOC=on: Use Perl malloc
PERL_64BITINT=on: Use 64 bit integers (on i386)
THREADS=off: Build threaded perl
PTHREAD=on: Build with -pthread
MULTIPLICITY=off: Use multiplicity
SITECUSTOMIZE=off: Run-time customization of @INC
USE_PERL=on: Rewrite links in /usr/bin
=== Use 'make config' to modify these settings
---End OPTIONS List---
(I noticed in the Makefile, if you have WITH_THREADS WITH_PERL_MALLOC,
.if defined(WITH_THREADS)
#XXX .if ${ARCH} == amd64
#XXX IGNORE= Threaded perl does not pass tests on ${ARCH}
#XXX .endif
CONFIGURE_ARGS+= -Dusethreads=y
PKGNAMESUFFIX= -threaded
WITH_PTHREAD= yes
# it seems perl malloc has problems with threaded perl on FreeBSD
.undef WITH_PERL_MALLOC
I wonder if this is true for WITH_PTHREAD (which is on by default)
anyone using it this way? with_perl_malloc? on 7.x?
is it broken on 7.x?
On my 9.0-Stable (4/28/12) system I have perl-threaded installed with
PERL_MALLOC selected. 'perl5 -V' reports:
Characteristics of this binary (from libperl):
Compile-time options: MULTIPLICITY PERL_DONT_CREATE_GVSV
PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP USE_64_BIT_ALL
USE_64_BIT_INT USE_ITHREADS USE_LARGE_FILES
USE_PERLIO USE_PERL_ATOF USE_REENTRANT_API
Built under freebsd
Compiled at Feb 16 2012 10:25:18
--
R. Kevin Oberman, Network Engineer
E-mail: kob6...@gmail.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
Options dialog display problem
Here is a screen shot of what I'm seeing when I run make config for security/sudo: http://mozart.lib.uchicago.edu/mozart/images/sudo-config.jpg The leftmost column is mostly empty. I can get it to partially display by moving my cursor up and down the list, but it doesn't ever draw properly. Is anyone else seeing this problem? It doesn't occur for all ports, only select ones. Perhaps the issue is the text overflow on one of the lines? Not sure... This is on FreeBSD 8.3-RELEASE-p3 with ports tree current as of yesterday. --plw ___ 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: Anyone using perl-5.12 and WITH_PERL_MALLOC?
On 6/23/12 12:31 PM, Kevin Oberman wrote:
(I noticed in the Makefile, if you have WITH_THREADS WITH_PERL_MALLOC,
.if defined(WITH_THREADS)
#XXX .if ${ARCH} == amd64
#XXX IGNORE=Threaded perl does not pass tests on ${ARCH}
#XXX .endif
CONFIGURE_ARGS+=-Dusethreads=y
PKGNAMESUFFIX= -threaded
WITH_PTHREAD= yes
# it seems perl malloc has problems with threaded perl on FreeBSD
.undef WITH_PERL_MALLOC
I wonder if this is true for WITH_PTHREAD (which is on by default)
anyone using it this way? with_perl_malloc? on 7.x?
is it broken on 7.x?
On my 9.0-Stable (4/28/12) system I have perl-threaded installed with
PERL_MALLOC selected. 'perl5 -V' reports:
Characteristics of this binary (from libperl):
Compile-time options: MULTIPLICITY PERL_DONT_CREATE_GVSV
PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP USE_64_BIT_ALL
USE_64_BIT_INT USE_ITHREADS USE_LARGE_FILES
USE_PERLIO USE_PERL_ATOF USE_REENTRANT_API
Built under freebsd
Compiled at Feb 16 2012 10:25:18
I believe you were tricked by the above .if defined in the Makefile
mine (without_threads), and (without_perl_malloc) says same thing
'perl_malloc_wrap'
(I ASSUME that WITH_PERL_MALLOC and WITHOUT_THREADS, it would say
perl_malloc?
here is mine: (that runs, without_perl_malloc)
Characteristics of this binary (from libperl): this is the default build.
Compile-time options: PERL_DONT_CREATE_GVSV PERL_MALLOC_WRAP
USE_64_BIT_ALL
USE_64_BIT_INT USE_LARGE_FILES USE_PERLIO
USE_PERL_ATOF
--
Michael Scheidell, CTO
*| * SECNAP Network Security Corporation
d: +1.561.948.2259
w: http://people.freebsd.org/~scheidell
___
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: Wine-fbsd64 updated to 1.5.6 (32bit Wine for 64bit FreeBSD)
On Friday, 22 June 2012 12:26:50 Jan Beich wrote:
(ports@ folk may know more about pkgng)
David Naylor naylor.b.da...@gmail.com writes:
Hi,
Packages [1] for wine-fbsd64-1.5.6 have been uploaded to mediafire [2].
The packages for FreeBSD 10 use the pkgng* [3] format.
[...]
* Support for pkgng has been added to the nvidia-patch script
pkgng seems to be more pedantic regarding conflicting files. And I
haven't found a way to force register a package.
I have reported this issue to both pkgng and FreeBSD ports. I managed to get
it to register by tweaking pkg-plist, also not defining WITH_PKGNG may work
(and with the changes to nvidia.sh it will fall back to `pkg_info` if `pkg
info` doesn\t yield).
--- patch-nvidia.sh~
+++ patch-nvidia.sh
@@ -92,12 +92,20 @@ do
done
version() {
+ local ret pkg=$1
if [ -f /usr/local/sbin/pkg ]
then
-echo `pkg query -g '%v' $1`
+ret=`pkg query -g '%v' $pkg`
else
-echo `pkg_info -E $1'*' | cut -f 3 -d -`
+ret=`pkg_info -E $pkg'*' | cut -f 3 -d -`
fi
+ # installed manually or failed to register
+ if [ -z $ret ] [ $pkg = nvidia-driver ]
+ then
+ret=`sed 2/dev/null -n 's/.*Version: //p' \
+ $PREFIX/share/doc/NVIDIA_GLX-1.0/README || true`
+ fi
+ echo $ret
}
[ `whoami` = root ] \
Thanks for your patch. I have updates the nvidia.sh script and given you
credit. This will be available from wine 1.5.7.
Regards
signature.asc
Description: This is a digitally signed message part.
Re: Anyone using perl-5.12 and WITH_PERL_MALLOC?
On Sat, Jun 23, 2012 at 11:05 AM, Michael Scheidell
scheid...@freebsd.org wrote:
On 6/23/12 12:31 PM, Kevin Oberman wrote:
(I noticed in the Makefile, if you have WITH_THREADS WITH_PERL_MALLOC,
.if defined(WITH_THREADS)
#XXX .if ${ARCH} == amd64
#XXX IGNORE= Threaded perl does not pass tests on ${ARCH}
#XXX .endif
CONFIGURE_ARGS+= -Dusethreads=y
PKGNAMESUFFIX= -threaded
WITH_PTHREAD= yes
# it seems perl malloc has problems with threaded perl on FreeBSD
.undef WITH_PERL_MALLOC
I wonder if this is true for WITH_PTHREAD (which is on by default)
anyone using it this way? with_perl_malloc? on 7.x?
is it broken on 7.x?
On my 9.0-Stable (4/28/12) system I have perl-threaded installed with
PERL_MALLOC selected. 'perl5 -V' reports:
Characteristics of this binary (from libperl):
Compile-time options: MULTIPLICITY PERL_DONT_CREATE_GVSV
PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP
USE_64_BIT_ALL
USE_64_BIT_INT USE_ITHREADS USE_LARGE_FILES
USE_PERLIO USE_PERL_ATOF USE_REENTRANT_API
Built under freebsd
Compiled at Feb 16 2012 10:25:18
I believe you were tricked by the above .if defined in the Makefile
mine (without_threads), and (without_perl_malloc) says same thing
'perl_malloc_wrap'
(I ASSUME that WITH_PERL_MALLOC and WITHOUT_THREADS, it would say
perl_malloc?
here is mine: (that runs, without_perl_malloc)
Characteristics of this binary (from libperl): this is the default build.
Compile-time options: PERL_DONT_CREATE_GVSV PERL_MALLOC_WRAP
USE_64_BIT_ALL
USE_64_BIT_INT USE_LARGE_FILES USE_PERLIO
USE_PERL_ATOF
Yes, I agree that perl is not really being built with PERL_MALLOC, but
selecting THREADS and PERL_MALLOC options does produce a working
threaded perl. Neither THREADS nor PERL_MALLOC are defaults, but I
have ports installed that require threaded perl.
--
R. Kevin Oberman, Network Engineer
E-mail: kob6...@gmail.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: Options dialog display problem
On Sat, Jun 23, 2012 at 10:06 AM, Peggy Wilkins enli...@gmail.com wrote: Here is a screen shot of what I'm seeing when I run make config for security/sudo: http://mozart.lib.uchicago.edu/mozart/images/sudo-config.jpg The leftmost column is mostly empty. I can get it to partially display by moving my cursor up and down the list, but it doesn't ever draw properly. Is anyone else seeing this problem? It doesn't occur for all ports, only select ones. Perhaps the issue is the text overflow on one of the lines? Not sure... This is on FreeBSD 8.3-RELEASE-p3 with ports tree current as of yesterday. I think this is a bug in dialog(1). It is the result of a description extending past the end of the line as happens with the NLS description. It is not a problem with the new dialog in 9.0 and above, but still exists in 7 and 8. I am not sure of how to fix it, but ISTR that scrolling down the options would re-write the option name fields and the selection status. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.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: graphics/flphoto: Fails to build
Hello. Latest flphoto doesn't build (here). Build log: http://ketas.si.pri.ee/fbsd/ports-buildlogs/graphics::flphoto.1340021653.log uname -a: FreeBSD ketas-laptop.mydomain 8.2-RELEASE-p4 FreeBSD 8.2-RELEASE-p4 #0: Sat Dec 10 22:25:43 EET 2011 root@ketas-laptop.mydomain:/usr/obj/usr/src/sys/KETASLAPTOP i386 Yep, flphoto fails to build here too after my latest ports update. My csup date/time: Sun Jun 10 19:04:29 UTC 2012 ...Fl_Print_Dialog2.cxx:1839: error: expected primary-expression before ')' token Fl_Print_Dialog2.cxx:1839: error: expected `;' before 'w' *** Error code 1 Stop in /usr/ports/graphics/flphoto/work/flphoto-1.3.1. *** Error code 1 Stop in /usr/ports/graphics/flphoto. Finally got flphoto to work by installing the package using flphoto-1.3.1_8.tbz. NOTE: flphoto worked for me on another recent ports update prior to the 20120531 graphics/png update, just saying. Not sure if this could be related or not. A bit of searching revealed that Greg Lehey also mentioned he had a flphoto failure January 13, 2012 (per his diary page): ...found one port that didn't build: ... Fl_Print_Dialog2.cxx:1839: error: expected primary-expression before ')' token Fl_Print_Dialog2.cxx:1839: error: expected `;' before 'w' *** Error code 1 Stop in /home/ports/graphics/flphoto/work/flphoto-1.3.1. ... with ultimately only one port (flphoto) requiring to be fetched as a binary package. Thanks, Rob -- Rob Clark rpcl...@tds.net ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: graphics/flphoto: Fails to build
Latest flphoto doesn't build (here). uname -a: FreeBSD ketas-laptop.mydomain 8.2-RELEASE-p4 FreeBSD 8.2-RELEASE-p4 #0: Sat Dec 10 22:25:43 EET 2011 root@ketas-laptop.mydomain:/usr/obj/usr/src/sys/KETASLAPTOP i386 Sorry, forgot to mention my uname: FreeBSD me.atmyhost.org 8.3-STABLE FreeBSD 8.3-STABLE #1: Wed May 30 20:15:48 EDT 2012 me.atmyhost.org:/usr/obj/usr/src/sys/MYCUSTOMKERN i386 -- Rob Clark rpcl...@tds.net ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Options dialog display problem
On 6/23/2012 2:32 PM, Kevin Oberman wrote: I think this is a bug in dialog(1). It is the result of a description extending past the end of the line as happens with the NLS description. I get the same behavior on FreeBSD 8.3. I've submitted a PR to lessen the length of the NLS description, as well as some others. Regards, Bryan Drewery ___ 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: Options dialog display problem
On Sat, Jun 23, 2012 at 3:54 PM, Bryan Drewery br...@shatow.net wrote: On 6/23/2012 2:32 PM, Kevin Oberman wrote: I think this is a bug in dialog(1). It is the result of a description extending past the end of the line as happens with the NLS description. I get the same behavior on FreeBSD 8.3. I've submitted a PR to lessen the length of the NLS description, as well as some others. Yes, this issue only affects FreeBSD 7and 8 as 9 has replaced the old FreeBSD dialog (and libdialog) with the standard version used in most distros and I believe both NetBSD and OpenBSD. It just truncates a long description line, though, so getting it shortened is still a good idea. Thanks for submitting the PR. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.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: print/ghostscript9 build fail : vga.h not found
Florent Peterschmitt fpeters...@gmail.com wrote in 4fe1b98b.5040...@gmail.com: fp gmake: *** [so] Erreur 2 fp *** Error code 1 fp fp Stop in /usr/ports/print/ghostscript9. fp *** Error code 1 fp fp Stop in /usr/ports/print/ghostscript9. fp fp Problem : no vga.h in my system, even in source tree. print/ghostscript9 depends on graphics/svgalib which provides vga.h. Please check if svgalib is installed properly. -- Hiroki pgpQt9rBjTjdK.pgp Description: PGP signature
Re: print/ghostscript9 build fail : vga.h not found
On 24.06.2012 02:46, Hiroki Sato wrote: Florent Peterschmitt fpeters...@gmail.com wrote in 4fe1b98b.5040...@gmail.com: fp gmake: *** [so] Erreur 2 fp *** Error code 1 fp fp Stop in /usr/ports/print/ghostscript9. fp *** Error code 1 fp fp Stop in /usr/ports/print/ghostscript9. fp fp Problem : no vga.h in my system, even in source tree. print/ghostscript9 depends on graphics/svgalib which provides vga.h. Please check if svgalib is installed properly. -- Hiroki graphics/svgalib is installed, but even after deinstall and reinstall, no vga.h and vgagl.h. Manual copy from work build directory of svgalib to /usr/local/include of these two files makes print/ghostscript9 build. Should I submit a PR to svgalib ? ___ 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
