Squid and TPROXY

[Andrea Venturoli]

Hello.

I might be interested in running Squid's TPROXY with ipfw.

Looking for docs, I've found almost only this:
http://tproxy.no-ip.org/

It seems a bit old, is it still valid?

Any caveat/hint?
Can it work alongside standard mode?

 bye & Thanks
av.
___
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: lang/spidermonkey185 build breaks

[Kubilay Kocak]

On 7/05/2013 3:02 AM, Beeblebrox wrote:
> Err Msg is:
> 
> In file included from jsapi.cpp:1:
> jsapi.cpp:1641:14: warning: cast from 'char *' to 'JSAtom **' increases
> required alignment from 1 to 8 [-Wcast-align]
> atom = (*(JSAtom **)((char*)&(cx->runtime)->atomState + (offset)));
>  ^~~~
> jsapi.cpp:1646:15: warning: cast from 'char *' to 'JSAtom **' increases
> required alignment from 1 to 8 [-Wcast-align]
> (*(JSAtom **)((char*)&(cx->runtime)->atomState + (offset))) =
> atom;
> ...
> jsapi.cpp:3988:16: warning: initialization of pointer of type 'JSIdArray *'
> to null from a constant boolean expression [-Wbool-conversion]
> return false;
>^
> In file included from jsapi.cpp:1:
> In file included from jsapi.cpp:57:
> In file included from ./jsarray.h:47:
> In file included from ./jsatom.h:52:
> ./jsstr.h:525:14: warning: private field 'mDummy' is not used
> [-Wunused-private-field]
> JSString mDummy;
>  ^
> 87 warnings and 4 errors generated.
> gmake[1]: *** [jsatom.o] Error 1
> gmake[1]: *** [jsapi.o] Error 1
> gmake[1]: Leaving directory
> `/wrkdirs/usr/ports/lang/spidermonkey185/work/js-1.8.5/js/src'
> gmake: *** [all] Error 2
> *** [do-build] Error code 1
> 
> Stop in /usr/ports/lang/spidermonkey185.
> 
> 
>

Hi,

Can you test the attached patch for me and let me know how it goes?

-koobs

Index: Makefile
===
--- Makefile(revision 309185)
+++ Makefile(working copy)
@@ -3,7 +3,7 @@
 
 PORTNAME=  spidermonkey185
 PORTVERSION=   1.8.5
-PORTREVISION=  1
+PORTREVISION=  2
 CATEGORIES=lang
 MASTER_SITES=  ${MASTER_SITE_MOZILLA}
 MASTER_SITE_SUBDIR=js
@@ -17,6 +17,7 @@
 
 CONFLICTS= njs-[0-9]*
 
+USE_AUTOTOOLS= autoconf213:env
 GNU_CONFIGURE= yes
 USE_GMAKE= yes
 USE_GNOME= gnomehack
@@ -151,6 +152,9 @@
 PLIST_SUB+=SPARC="@comment "
 .endif
 
+pre-configure:
+   (cd ${WRKSRC} && ${AUTOCONF})
+
 regression-test: build
@${ECHO_MSG} -n "===> Running jstests.py: "
@cd ${WRKSRC} && ${SETENV} TZ=PST8PDT ${PYTHON_CMD} tests/jstests.py \
Index: files/patch-js-src-configure.in
===
--- files/patch-js-src-configure.in (revision 0)
+++ files/patch-js-src-configure.in (working copy)
@@ -0,0 +1,12 @@
+--- configure.in.orig  2011-03-31 21:08:36.0 +0200
 configure.in   2012-12-17 23:12:14.0 +0100
+@@ -3378,7 +3378,8 @@
+rm -f conftest.{c,S}
+])
+ if test "$ac_cv_have_visibility_builtin_bug" = "no" -a \
+-"$ac_cv_have_visibility_class_bug" = "no"; then
++"$ac_cv_have_visibility_class_bug" = "no" -a \
++  "$OS_ARCH" != "FreeBSD" ; then
+   VISIBILITY_FLAGS='-I$(DIST)/system_wrappers_js -include 
$(topsrcdir)/config/gcc_hidden.h'
+   WRAP_SYSTEM_INCLUDES=1
+   STL_FLAGS='-I$(DIST)/stl_wrappers'

Property changes on: files/patch-js-src-configure.in
___
Added: svn:mime-type
## -0,0 +1 ##
+text/plain
\ No newline at end of property
Added: fbsd:nokeywords
## -0,0 +1 ##
+yes
\ No newline at end of property
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
___
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 unmaintained ports which are currently marked broken

[linimon]

As part of an ongoing effort to reduce the number of problems in
the FreeBSD ports system, we periodically notify users of ports
that are marked as "broken" in their Makefiles.  In many cases
these ports are failing to compile on some subset of the FreeBSD
build environments.  The most common problem is that recent versions
of -CURRENT include gcc4.2, which is much stricter than older versions.
The next most common problem is that compiles succeed on the i386
architecture (e.g. the common Intel PC), but fail on one or more
of the other architectures due to assumptions about things such as
size of various types, byte-alignment issues, and so forth.

In occasional cases we see that the same port may have different
errors in different build environments.  The script that runs on the
build cluster uses heuristics to try to 'guess' the error type to
help you isolate problems, but it is only a rough guide.

One more note: on occasion, there are transient build errors seen
on the build farm.  Unfortunately, there is not yet any way for this
algorithm to tell the difference (humans are much, much better at
this kind of thing.)

The errors are listed below.  In the case where the same problem
exists on more than one build environment, the URL points to the
latest errorlog for that type.  (By 'build environment' here we
mean 'combination of 7.x/8.x/9.x/-current with target architecture'.)

(Note: the dates are included to help you to gauge whether or not
the error still applies to the latest version.  The program
that generates this report is not yet able to determine this
automatically.)

portname:   archivers/unalz
broken because: fails to build
build errors:
http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.9.20130422131134.pointyhat/unalz-0.65.log
 (Apr 25 23:53:37 UTC 2013)
http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/e.9.20130422131143.pointyhat/unalz-0.65.log
 (Apr 25 20:35:07 UTC 2013)
http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.10.20130313090402.pointyhat/unalz-0.65.log
 (Mar 14 00:13:37 UTC 2013)
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=archivers&portname=unalz


portname:   biology/dotter
broken because: checksum mismatch
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=biology&portname=dotter


portname:   chinese/big5con
broken because: fails to build with new utmpx
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=chinese&portname=big5con


portname:   chinese/bitchx
broken because: patch reject
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=chinese&portname=bitchx


portname:   chinese/hztty
broken because: fails to build with new utmpx
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=chinese&portname=hztty


portname:   databases/msql
broken because: Broken on FreeBSD 9+
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=databases&portname=msql


portname:   databases/sqlrelay
broken because: does not compile
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=databases&portname=sqlrelay


portname:   deskutils/libopensync-plugin-python-devel
broken because: fails to build with recent libopensync
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=deskutils&portname=libopensync-plugin-python-devel


portname:   deskutils/libopensync-plugin-vformat-devel
broken because: fails to build
build errors:
http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/e.9.20130422131143.pointyhat/libopensync-plugin-vformat-devel-0.36_1.log
 (Apr 25 20:05:45 UTC 2013)
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=deskutils&portname=libopensync-plugin-vformat-devel


portname:   deskutils/msynctool-devel
broken because: fails to build with recent libopensync
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=deskutils&portname=msynctool-devel


portname:   deskutils/simpleagenda
broken because: does not build
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=deskutils&portname=simpleagenda


portname:   devel/allegro
broken because: fails to build
build errors:
http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/e.8.20130416155942.pointyhat/allegro-4.2.2_3.log
 (Apr 21 23:44:25 UTC 2013)
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=devel&portname=allegro


portname:   devel/arm-rtems-gcc
broken because: many issues; see
https://www.rtems.org/bugzilla/show_bug.cgi?id=2099
build errors:

FreeBSD ports which are currently marked broken

[linimon]

As part of an ongoing effort to reduce the number of problems in
the FreeBSD ports system, we periodically notify users of ports
that are marked as "broken" in their Makefiles.  In many cases
these ports are failing to compile on some subset of the FreeBSD
build environments.  The most common problem is that recent versions
of -CURRENT include gcc4.2, which is much stricter than older versions.
The next most common problem is that compiles succeed on the i386
architecture (e.g. the common Intel PC), but fail on one or more
of the other architectures due to assumptions about things such as
size of various types, byte-alignment issues, and so forth.

In occasional cases we see that the same port may have different
errors in different build environments.  The script that runs on the
build cluster uses heuristics to try to 'guess' the error type to
help you isolate problems, but it is only a rough guide.

One more note: on occasion, there are transient build errors seen
on the build farm.  Unfortunately, there is not yet any way for this
algorithm to tell the difference (humans are much, much better at
this kind of thing.)

The errors are listed below.  In the case where the same problem
exists on more than one build environment, the URL points to the
latest errorlog for that type.  (By 'build environment' here we
mean 'combination of 7.x/8.x/9.x/-current with target architecture'.)

(Note: the dates are included to help you to gauge whether or not
the error still applies to the latest version.  The program
that generates this report is not yet able to determine this
automatically.)

portname:   accessibility/yasr
broken because: fails to build with new utmpx
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=accessibility&portname=yasr


portname:   archivers/unalz
broken because: fails to build
build errors:
http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.9.20130422131134.pointyhat/unalz-0.65.log
 (Apr 25 23:53:37 UTC 2013)
http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/e.9.20130422131143.pointyhat/unalz-0.65.log
 (Apr 25 20:35:07 UTC 2013)
http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.10.20130313090402.pointyhat/unalz-0.65.log
 (Mar 14 00:13:37 UTC 2013)
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=archivers&portname=unalz


portname:   audio/gdam
broken because: does not build
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=gdam


portname:   benchmarks/polygraph31
broken because: does not build
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=benchmarks&portname=polygraph31


portname:   biology/dotter
broken because: checksum mismatch
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=biology&portname=dotter


portname:   cad/meshlab
broken because: does not build
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=cad&portname=meshlab


portname:   chinese/big5con
broken because: fails to build with new utmpx
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=chinese&portname=big5con


portname:   chinese/bitchx
broken because: patch reject
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=chinese&portname=bitchx


portname:   chinese/cxterm
broken because: fails to build with new utmpx
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=chinese&portname=cxterm


portname:   chinese/hztty
broken because: fails to build with new utmpx
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=chinese&portname=hztty


portname:   comms/hso-kmod
broken because: does not build with USB2, please try comms/uhso-kmod
instead
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=comms&portname=hso-kmod


portname:   comms/ib-kmod
broken because: does not build
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=comms&portname=ib-kmod


portname:   comms/uticom
broken because: does not compile
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=comms&portname=uticom


portname:   converters/pdf2djvu
broken because: does not build
build errors:
http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.10.20130313090402.pointyhat/pdf2djvu-0.5.11_10.log
 (Mar 14 00:22:50 UTC 2013)
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=converters&portname=pdf2djvu


portname: 

FreeBSD ports which are currently marked forbidden

[linimon]

As part of an ongoing effort to reduce the number of problems in the
FreeBSD ports system, we periodically notify users about
ports that are marked as "forbidden" in their Makefiles.  Often,
these ports are so marked due to security concerns, such as known
exploits.

An overview of each port, including errors seen on the build farm,
is included below.

portname:   graphics/linux-tiff
forbidden because:  Vulnerable since 2004-10-13,

http://portaudit.freebsd.org/8816bf3a-7929-11df-bcce-0018f3e2eb82.html
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=graphics&portname=linux-tiff


portname:   security/sudosh3
forbidden because:  Secunia Advisory SA38292, ISS X-Force sudosh-replay-bo
(55903), replay() function buffer overflow.
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=security&portname=sudosh3


portname:   x11-toolkits/linux-pango
forbidden because:  Vulnerable since 2009-05-13,

http://portaudit.freebsd.org/4b172278-3f46-11de-becb-001cc0377035.html
build errors:   none.
overview:   
http://portsmon.FreeBSD.org/portoverview.py?category=x11-toolkits&portname=linux-pango
___
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: Squid and TPROXY

[Alexander]

07.05.2013, 11:47, "Andrea Venturoli" :
> Hello.
>
> I might be interested in running Squid's TPROXY with ipfw.
>
> Looking for docs, I've found almost only this:
> http://tproxy.no-ip.org/
>
> It seems a bit old, is it still valid?
>
> Any caveat/hint?
> Can it work alongside standard mode?
>
>   bye & Thanks
> av.
> ___
> 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"
You must have kernel with:
options IPFIREWALL_FORWARD
then in ipfw rules you should add something like:
${fwcmd} add fwd 127.0.0.1,3128 tcp from ${int_net} to any 80 out via ${ext_if}
and in squid.conf you should add something like:
http_port 192.168.1.1:3128
http_port 127.0.0.1:3128 transparent
thats all
___
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"

Error: can't open Makefile

[Fernando Apesteguía]

Hi,

I was updating graphics/converseen from 0.5.3 to 0.6.1

In the current version, I use

USE_CMAKE= yes

But this doesn't seem to work now, and I have to use

USES+= cmake

to make it compile in redports.org.

There should be a code portion like this:

.if defined(USE_CMAKE)
. if defined(CMAKE_OUTSOURCE)
USES+=  cmake:outsource
. else
USES+=  cmake
. endif
.endif

in bsd.port.mk so using USE_CMAKE should suffice.

What am I missing?

Thanks in advance.
___
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: Error: can't open Makefile

[Alberto Villa]

Hi,

On Tuesday 07 May 2013 13:45:15 Fernando Apesteguía wrote:
> In the current version, I use
>
> USE_CMAKE= yes

converseen was converted to USES=cmake along with all the other ports using
USE_CMAKE.

> There should be a code portion like this:
> in bsd.port.mk so using USE_CMAKE should suffice.

USE_CMAKE was completely removed from the tree, USES is the way to go.
--
Alberto Villa, FreeBSD committer 
http://people.FreeBSD.org/~avilla

It's not that I'm afraid to die.
I just don't want to be there when it happens.
-- Woody Allen


signature.asc
Description: This is a digitally signed message part.

Re: lang/spidermonkey185 build breaks

[Beeblebrox]

koobs:

patch did not work (native host or poudriere). Patch output below, contents
of link above changed to build output from poudriere for your patched ver.

# patch http://freebsd.1045724.n5.nabble.com/lang-spidermonkey185-build-breaks-tp5809189p5809381.html
Sent from the freebsd-ports mailing list archive at Nabble.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"

smartd dumps core

[Andrea Venturoli]

Hello.

I've installed smartmontools on several machines, both i386 and amd64, 
8.3 or 9.1.


On one box in particular, though, it dumps core.
There are two SCSI and four SATA HDs here.

The stacktrace:

# gdb smartd
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...
(gdb) r
Starting program: /usr/local/sbin/smartd
[New LWP 100131]
[New Thread 802007400 (LWP 100131/smartd)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 802007400 (LWP 100131/smartd)]
0x0008015044f5 in memcpy () from /lib/libc.so.7
(gdb) bt
#0  0x0008015044f5 in memcpy () from /lib/libc.so.7
#1  0x in ?? ()
#2  0x in ?? ()
#3  0x in ?? ()
#4  0x in ?? ()
#5  0x in ?? ()
#6  0x in ?? ()
#7  0x in ?? ()
#8  0x in ?? ()
#9  0x in ?? ()
#10 0x in ?? ()
#11 0x in ?? ()
#12 0x in ?? ()
#13 0x in ?? ()
#14 0x in ?? ()
#15 0x in ?? ()
#16 0x in ?? ()
#17 0x in ?? ()
#18 0x in ?? ()
#19 0x000802077300 in ?? ()
#20 0x0036 in ?? ()
#21 0x0008020d6100 in ?? ()
#22 0x0036 in ?? ()
#23 0x00080147d731 in _pthread_mutex_init_calloc_cb () from /lib/libc.so.7
#24 0x0006 in ?? ()
#25 0x0001 in ?? ()
#26 0x7fffa520 in ?? ()
#27 0x01fc in ?? ()
#28 0x7fffa4b0 in ?? ()
#29 0x0020 in ?? ()
#30 0x0014 in ?? ()
#31 0xff36 in ?? ()
#32 0x in ?? ()
#33 0x00677f70 in ?? ()
#34 0x00d6 in ?? ()
#35 0x00080200 in ?? ()
#36 0x00677990 in ?? ()
#37 0x00fc01000112 in ?? ()
#38 0x00080200 in ?? ()
#39 0x00677f70 in ?? ()
#40 0x00080148012e in _malloc_postfork () from /lib/libc.so.7
#41 0x000802082780 in ?? ()
#42 0x in ?? ()
#43 0x in ?? ()
#44 0x in ?? ()
#45 0x in ?? ()
#46 0x in ?? ()
#47 0x in ?? ()
#48 0x in ?? ()
#49 0x in ?? ()
#50 0x in ?? ()
#51 0x in ?? ()
#52 0x in ?? ()
#53 0x in ?? ()
#54 0x in ?? ()
#55 0x in ?? ()
#56 0x in ?? ()
#57 0x in ?? ()
#58 0x in ?? ()
#59 0x in ?? ()
#60 0x in ?? ()
#61 0x in ?? ()
#62 0x in ?? ()
#63 0x in ?? ()
#64 0x in ?? ()
#65 0x in ?? ()
#66 0x in ?? ()
---Type  to continue, or q  to quit---
#67 0x in ?? ()
#68 0x in ?? ()
#69 0x in ?? ()
#70 0x in ?? ()
#71 0x in ?? ()
#72 0x in ?? ()
#73 0x in ?? ()
#74 0x in ?? ()
#75 0x in ?? ()
#76 0x in ?? ()
#77 0x in ?? ()
#78 0x in ?? ()
#79 0x in ?? ()
#80 0x in ?? ()
#81 0x in ?? ()
#82 0x in ?? ()
#83 0x in ?? ()
#84 0x in ?? ()
#85 0x in ?? ()
#86 0x in ?? ()
#87 0x in ?? ()
#88 0x in ?? ()
#89 0x in ?? ()
#90 0x in ?? ()
#91 0x in ?? ()
#92 0x in ?? ()
#93 0x in ?? ()
#94 0x in ?? ()
#95 0x in ?? ()
#96 0x in ?? ()
#97 0x in ?? ()
#98 0x in ?? ()
#99 0x in ?? ()
#100 0x in ?? ()
#101 0x in ?? ()
#102 0x in ?? ()
#103 0x in ?? ()
#104 0x in ?? ()
#105 0x in ?? ()
#106 0x7fffac80 in ?? ()
#107 0x0041025d in SCSIDeviceScan (cfg=@0x801b81eb0, 
state=@0x801b81ea0, scsidev=0x801b82080) at smartd.cpp:2203
Previous frame inner to this frame (corrupt stack?)




From what I can get, the crash happens when a SCSI HD is queried.
In fact, "smartctl -a" works fine for SATA drives, but will dump core 
too with SCSI HDs.

Again, here's the stack:

# gdb smartd
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to c

Cyrus IMAP upgrade

[Andrea Venturoli]

Hello.

I've got a medium-sized installation of Cyrus-IMAP 2.2 (~80 mailboxes, 
~5000 folders, >1M mails).
Due to OL2013 misbehaviours, I've been asked to upgrade it to 2.4, so 
I'll feature XLIST.


Considering the setup is a simple one (one partition, no murder, no 
other fancies) and having waded through the generic upgrade instructions 
(http://cyrusimap.org/docs/cyrus-imapd/2.4.12/install-upgrade.php), is 
there something FreeBSD specific I should be aware of?


Is it just a matter of pkg_deleting the old one and installing the new 
version?


Of course I'll do a run on a test server, but any other warning is 
appreciated.


 bye & Thanks
av.
___
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: smartd dumps core

[Alex Samorukov]

Hi.

You should at least specify version of the smartmontools :)
On 05/07/2013 01:33 PM, Andrea Venturoli wrote:

Hello.

I've installed smartmontools on several machines, both i386 and amd64, 
8.3 or 9.1.


On one box in particular, though, it dumps core.
There are two SCSI and four SATA HDs here.

The stacktrace:

# gdb smartd
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and 
you are
welcome to change it and/or distribute copies of it under certain 
conditions.

Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for 
details.

This GDB was configured as "amd64-marcel-freebsd"...
(gdb) r
Starting program: /usr/local/sbin/smartd
[New LWP 100131]
[New Thread 802007400 (LWP 100131/smartd)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 802007400 (LWP 100131/smartd)]
0x0008015044f5 in memcpy () from /lib/libc.so.7
(gdb) bt
#0  0x0008015044f5 in memcpy () from /lib/libc.so.7
#1  0x in ?? ()
#2  0x in ?? ()
#3  0x in ?? ()
#4  0x in ?? ()
#5  0x in ?? ()
#6  0x in ?? ()
#7  0x in ?? ()
#8  0x in ?? ()
#9  0x in ?? ()
#10 0x in ?? ()
#11 0x in ?? ()
#12 0x in ?? ()
#13 0x in ?? ()
#14 0x in ?? ()
#15 0x in ?? ()
#16 0x in ?? ()
#17 0x in ?? ()
#18 0x in ?? ()
#19 0x000802077300 in ?? ()
#20 0x0036 in ?? ()
#21 0x0008020d6100 in ?? ()
#22 0x0036 in ?? ()
#23 0x00080147d731 in _pthread_mutex_init_calloc_cb () from 
/lib/libc.so.7

#24 0x0006 in ?? ()
#25 0x0001 in ?? ()
#26 0x7fffa520 in ?? ()
#27 0x01fc in ?? ()
#28 0x7fffa4b0 in ?? ()
#29 0x0020 in ?? ()
#30 0x0014 in ?? ()
#31 0xff36 in ?? ()
#32 0x in ?? ()
#33 0x00677f70 in ?? ()
#34 0x00d6 in ?? ()
#35 0x00080200 in ?? ()
#36 0x00677990 in ?? ()
#37 0x00fc01000112 in ?? ()
#38 0x00080200 in ?? ()
#39 0x00677f70 in ?? ()
#40 0x00080148012e in _malloc_postfork () from /lib/libc.so.7
#41 0x000802082780 in ?? ()
#42 0x in ?? ()
#43 0x in ?? ()
#44 0x in ?? ()
#45 0x in ?? ()
#46 0x in ?? ()
#47 0x in ?? ()
#48 0x in ?? ()
#49 0x in ?? ()
#50 0x in ?? ()
#51 0x in ?? ()
#52 0x in ?? ()
#53 0x in ?? ()
#54 0x in ?? ()
#55 0x in ?? ()
#56 0x in ?? ()
#57 0x in ?? ()
#58 0x in ?? ()
#59 0x in ?? ()
#60 0x in ?? ()
#61 0x in ?? ()
#62 0x in ?? ()
#63 0x in ?? ()
#64 0x in ?? ()
#65 0x in ?? ()
#66 0x in ?? ()
---Type  to continue, or q  to quit---
#67 0x in ?? ()
#68 0x in ?? ()
#69 0x in ?? ()
#70 0x in ?? ()
#71 0x in ?? ()
#72 0x in ?? ()
#73 0x in ?? ()
#74 0x in ?? ()
#75 0x in ?? ()
#76 0x in ?? ()
#77 0x in ?? ()
#78 0x in ?? ()
#79 0x in ?? ()
#80 0x in ?? ()
#81 0x in ?? ()
#82 0x in ?? ()
#83 0x in ?? ()
#84 0x in ?? ()
#85 0x in ?? ()
#86 0x in ?? ()
#87 0x in ?? ()
#88 0x in ?? ()
#89 0x in ?? ()
#90 0x in ?? ()
#91 0x in ?? ()
#92 0x in ?? ()
#93 0x in ?? ()
#94 0x in ?? ()
#95 0x in ?? ()
#96 0x in ?? ()
#97 0x in ?? ()
#98 0x in ?? ()
#99 0x in ?? ()
#100 0x in ?? ()
#101 0x in ?? ()
#102 0x in ?? ()
#103 0x in ?? ()
#104 0x in ?? ()
#105 0x in ?? ()
#106 0x7fffac80 in ?? ()
#107 0x0041025d in SCSIDeviceScan (cfg=@0x801b81eb0, 
state=@0x801b81ea0, scsidev=0x801b82080) at smartd.cpp:2203

Previous frame inner to this frame (corrupt stack?)




From what I can get, the crash happens when a SCSI HD is queried.
In fact, "smartctl -a" works fine for SATA drives, but will dump core 
too with SCSI HDs.

Again, here's the stack:

# gdb smartd
GNU gdb 6.1.1 [FreeBSD]
Copyright 200

Re: smartd dumps core

[Andrea Venturoli]

On 05/07/13 14:21, Alex Samorukov wrote:

Hi.

You should at least specify version of the smartmontools :)


Oh, sorry! :)
It's the latest:

% pkg_info|grep smart
smartmontools-6.1   S.M.A.R.T. disk monitoring tools




 bye & Thanks
av.
___
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: firefox build broken under clang 3.3

[Rafael Espíndola]

On 1 May 2013 00:26, Rafael Espíndola  wrote:
> This is now
>
> http://llvm.org/bugs/show_bug.cgi?id=15882

And it got fixed! :-)

It just missed 3.3 branching, but I will make sure it gets ported.

Cheers,
Rafael
___
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: firefox build broken under clang 3.3

[Dimitry Andric]

On 2013-05-07 14:59, Rafael Espíndola wrote:

On 1 May 2013 00:26, Rafael Espíndola  wrote:

This is now

http://llvm.org/bugs/show_bug.cgi?id=15882


And it got fixed! :-)

It just missed 3.3 branching, but I will make sure it gets ported.


Okay, can the original posters that suffered from the crash, please try
the attached patch on their -current source, then try to rebuild the
Firefox port, and check if the crash has disappeared?

If you just want to incrementally build clang, you can do:

  cd /usr/src/lib/clang/libllvmvectorize
  make
  cd /usr/src/usr.bin/clang/clang
  make
  sudo make install

-Dimitry
Index: contrib/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
===
--- contrib/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp	(revision 250331)
+++ contrib/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp	(working copy)
@@ -214,7 +214,7 @@ class InnerLoopVectorizer {
   /// This function adds 0, 1, 2 ... to each vector element, starting at zero.
   /// If Negate is set then negative numbers are added e.g. (0, -1, -2, ...).
   /// The sequence starts at StartIndex.
-  Value *getConsecutiveVector(Value* Val, unsigned StartIdx, bool Negate);
+  Value *getConsecutiveVector(Value* Val, int StartIdx, bool Negate);
 
   /// When we go over instructions in the basic block we rely on previous
   /// values within the current basic block or on loop invariant values.
@@ -771,7 +771,7 @@ Value *InnerLoopVectorizer::getBroadcastInstrs(Val
   return Shuf;
 }
 
-Value *InnerLoopVectorizer::getConsecutiveVector(Value* Val, unsigned StartIdx,
+Value *InnerLoopVectorizer::getConsecutiveVector(Value* Val, int StartIdx,
  bool Negate) {
   assert(Val->getType()->isVectorTy() && "Must be a vector");
   assert(Val->getType()->getScalarType()->isIntegerTy() &&
@@ -784,8 +784,8 @@ Value *InnerLoopVectorizer::getBroadcastInstrs(Val
 
   // Create a vector of consecutive numbers from zero to VF.
   for (int i = 0; i < VLen; ++i) {
-int Idx = Negate ? (-i): i;
-Indices.push_back(ConstantInt::get(ITy, StartIdx + Idx));
+int64_t Idx = Negate ? (-i) : i;
+Indices.push_back(ConstantInt::get(ITy, StartIdx + Idx, Negate));
   }
 
   // Add the consecutive indices to the vector value.
@@ -1928,7 +1928,8 @@ InnerLoopVectorizer::vectorizeBlockInLoop(LoopVect
   // After broadcasting the induction variable we need to make the
   // vector consecutive by adding  ... -3, -2, -1, 0.
   for (unsigned part = 0; part < UF; ++part)
-Entry[part] = getConsecutiveVector(Broadcasted, -VF * part, true);
+Entry[part] = getConsecutiveVector(Broadcasted, -(int)VF * part,
+   true);
   continue;
 }
 
___
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: Error: can't open Makefile

[Fernando Apesteguía]

On Tue, May 7, 2013 at 1:52 PM, Alberto Villa  wrote:
> Hi,
>
> On Tuesday 07 May 2013 13:45:15 Fernando Apesteguía wrote:
>> In the current version, I use
>>
>> USE_CMAKE= yes
>
> converseen was converted to USES=cmake along with all the other ports using
> USE_CMAKE.
>

Thanks. I updated my ports and I see the changes now.

>> There should be a code portion like this:
>> in bsd.port.mk so using USE_CMAKE should suffice.
>
> USE_CMAKE was completely removed from the tree, USES is the way to go.

Just out of curiosity, why this change?

> --
> Alberto Villa, FreeBSD committer 
> http://people.FreeBSD.org/~avilla
>
> It's not that I'm afraid to die.
> I just don't want to be there when it happens.
> -- Woody Allen
___
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"

astro/gpsd fails to build on CURRENT

[Rainer Hurling]

When I try to build astro/gpsd on 10.0-CURRENT it fails with the
following messages (devel/scons should be up to date):

/usr/ports/astro/gpsd#make
===>  Found saved configuration for gpsd-3.9
===> Fetching all distfiles required by gpsd-3.9 for building
===>  Extracting for gpsd-3.9
=> SHA256 Checksum OK for gpsd-3.9.tar.gz.
===>  Patching for gpsd-3.9
===>  Applying FreeBSD patches for gpsd-3.9
===>   gpsd-3.9 depends on package: docbook-xsl>=0 - found
===>   gpsd-3.9 depends on executable: xsltproc - found
===>   gpsd-3.9 depends on file: /usr/local/bin/python2.7 - found
===>   gpsd-3.9 depends on executable: pkgconf - found
===>   gpsd-3.9 depends on file: /usr/local/bin/scons - found
===>  Configuring for gpsd-3.9
===>  Building for gpsd-3.9
scons: Reading SConscript files ...
Checking if compiler accepts -Wextra ...yes
Checking if compiler accepts -Wall ...yes
Checking if compiler accepts -Wno-uninitialized ...yes
Checking if compiler accepts -Wno-missing-field-initializers ...yes
Checking if compiler accepts -Wcast-align ...yes
Checking if compiler accepts -Wmissing-declarations ...yes
Checking if compiler accepts -Wmissing-prototypes ...yes
Checking if compiler accepts -Wstrict-prototypes ...yes
Checking if compiler accepts -Wpointer-arith ...yes
Checking if compiler accepts -Wreturn-type ...yes
chrpath is not available or use of it has been disabled.
Checking whether the C++ compiler worksyes
Checking for ncurses... no
Checking for ncurses5-config... yes
Checking for libusb-1.0... no
Checking for C library librt... yes
Checking for C library libcap... no
Checking for bluez... no
Checking for C header file sys/timepps.h... no
You do not have kernel PPS available.
Checking for C header file linux/can.h... no
You do not have kernel CANbus available.
Checking for C function daemon()... yes
Checking for C function strlcpy()... yes
Checking for C function strlcat()... yes
Checking for C function clock_gettime()... yes
Checking for C function pselect()... yes
Checking for C header file endian.h... no
Checking for C header file sys/endian.h... yes
Checking that xsltproc can make man pages... yes
Altered configuration variables:
mtk3301 = False (default True): MTK-3301 support
nmea2000 = False (default True): NMEA2000/CAN support
bluez = False (default True): BlueZ support for Bluetooth devices
libQgpsmm = False (default True): build QT bindings
chrpath = False (default True): use chrpath to edit library load paths
mandir = man (default share/man): manual pages directory
pkgconfig = libdata/pkgconfig (default lib/pkgconfig): pkgconfig file
directory
TypeError: Tried to lookup Dir '/usr/local/lib' as a File.:
  File "/usr/ports/astro/gpsd/work/gpsd-3.9/SConstruct", line 955:
parse_flags=gpsdlibs + ncurseslibs + ['-lm'])
  File "/usr/local/lib/scons-2.1.0/SCons/Environment.py", line 258:
return MethodWrapper.__call__(self, target, source, *args, **kw)
  File "/usr/local/lib/scons-2.1.0/SCons/Environment.py", line 222:
return self.method(*nargs, **kwargs)
  File "/usr/local/lib/scons-2.1.0/SCons/Builder.py", line 631:
env = env.Override(env_kw)
  File "/usr/local/lib/scons-2.1.0/SCons/Environment.py", line 635:
if merges: env.MergeFlags(merges)
  File "/usr/local/lib/scons-2.1.0/SCons/Environment.py", line 810:
args = self.ParseFlags(args)
  File "/usr/local/lib/scons-2.1.0/SCons/Environment.py", line 796:
do_parse(arg)
  File "/usr/local/lib/scons-2.1.0/SCons/Environment.py", line 670:
for t in arg: do_parse(t)
  File "/usr/local/lib/scons-2.1.0/SCons/Environment.py", line 726:
dict['LIBS'].append(self.fs.File(arg))
  File "/usr/local/lib/scons-2.1.0/SCons/Node/FS.py", line 1339:
return self._lookup(name, directory, File, create)
  File "/usr/local/lib/scons-2.1.0/SCons/Node/FS.py", line 1318:
return root._lookup_abs(p, fsclass, create)
  File "/usr/local/lib/scons-2.1.0/SCons/Node/FS.py", line 2223:
result.must_be_same(klass)
  File "/usr/local/lib/scons-2.1.0/SCons/Node/FS.py", line 626:
(self.__class__.__name__, self.path, klass.__name__))
*** [do-build] Error code 2
Stop in /usr/ports/astro/gpsd.
*** [build] Error code 1
Stop in /usr/ports/astro/gpsd.


Please let me know, if you need more informations.

Thanks in advance,
Rainer Hurling
___
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"

[QAT] r317623: 8x leftovers

[Ports-QAT]

Update net/bird && net/bird6 to 1.3.10.

Reviewed by:az
-

  Build ID:  20130507163000-15364
  Job owner: melif...@freebsd.org
  Buildtime: 17 minutes
  Enddate:   Tue, 07 May 2013 16:46:53 GMT

  Revision:  r317623
  Repository:
https://svnweb.freebsd.org/ports?view=revision&revision=317623

-

Port:net/bird 1.3.10

  Buildgroup: 9.1-QAT/amd64
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~melif...@freebsd.org/20130507163000-15364-135804/bird-1.3.10.log

  Buildgroup: 9.1-QAT/i386
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~melif...@freebsd.org/20130507163000-15364-135805/bird-1.3.10.log

  Buildgroup: 8.3-QAT/amd64
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~melif...@freebsd.org/20130507163000-15364-135806/bird-1.3.10.log

  Buildgroup: 8.3-QAT/i386
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~melif...@freebsd.org/20130507163000-15364-135807/bird-1.3.10.log

-

Port:net/bird6 1.3.10

  Buildgroup: 9.1-QAT/amd64
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~melif...@freebsd.org/20130507163000-15364-135808/bird6-1.3.10.log

  Buildgroup: 9.1-QAT/i386
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~melif...@freebsd.org/20130507163000-15364-135809/bird6-1.3.10.log

  Buildgroup: 8.3-QAT/amd64
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~melif...@freebsd.org/20130507163000-15364-135810/bird6-1.3.10.log

  Buildgroup: 8.3-QAT/i386
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~melif...@freebsd.org/20130507163000-15364-135811/bird6-1.3.10.log


--
Buildarchive URL: 
redports 
___
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: astro/gpsd fails to build on CURRENT

[Christoph Moench-Tegeder]

## Rainer Hurling (rhur...@gwdg.de):

> When I try to build astro/gpsd on 10.0-CURRENT it fails with the
> following messages (devel/scons should be up to date):

The root cause of this is the interaction between scons and
ncurses5-config (from devel/ncurses) - scons mis-parses the
output of the (autotools-generated) ncurses5-config:
: cmt@elch:~$ ncurses5-config --libs
: -L/usr/local/lib -rpath /usr/local/lib -lncurses -ltinfo

The argument to -rpath is not recognized as such but instead taken
as a file argument and objectified as such.
I enden up "fixing" this by adding a "=" after -rpath in ncurses5-config,
which is valid syntax for gcc/ld and keeps scons of that "/usr/local/lib".
I'm quite sure that there should be a better solution.

Regards,
Christoph

-- 
Spare Space
___
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"

[QAT] r317624: 4x leftovers

[Ports-QAT]

Fix dependency.

Reported by:miwi
-

  Build ID:  20130507165000-51171
  Job owner: h...@freebsd.org
  Buildtime: 16 minutes
  Enddate:   Tue, 07 May 2013 17:05:55 GMT

  Revision:  r317624
  Repository:
https://svnweb.freebsd.org/ports?view=revision&revision=317624

-

Port:devel/tex-web2c 

  Buildgroup: 9.1-QAT/amd64
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~h...@freebsd.org/20130507165000-51171-135812/tex-web2c-20120701_1.log

  Buildgroup: 9.1-QAT/i386
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~h...@freebsd.org/20130507165000-51171-135813/tex-web2c-20120701_1.log

  Buildgroup: 8.3-QAT/amd64
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~h...@freebsd.org/20130507165000-51171-135814/tex-web2c-20120701_1.log

  Buildgroup: 8.3-QAT/i386
  Buildstatus:   LEFTOVERS
  Log: 
https://qat.redports.org//~h...@freebsd.org/20130507165000-51171-135815/tex-web2c-20120701_1.log


--
Buildarchive URL: 
redports 
___
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: astro/gpsd fails to build on CURRENT

[Rainer Hurling]

On 07.05.2013 18:47 (UTC+2), Christoph Moench-Tegeder wrote:
> ## Rainer Hurling (rhur...@gwdg.de):
> 
>> When I try to build astro/gpsd on 10.0-CURRENT it fails with the
>> following messages (devel/scons should be up to date):
> 
> The root cause of this is the interaction between scons and
> ncurses5-config (from devel/ncurses) - scons mis-parses the
> output of the (autotools-generated) ncurses5-config:
> : cmt@elch:~$ ncurses5-config --libs
> : -L/usr/local/lib -rpath /usr/local/lib -lncurses -ltinfo
> 
> The argument to -rpath is not recognized as such but instead taken
> as a file argument and objectified as such.
> I enden up "fixing" this by adding a "=" after -rpath in ncurses5-config,
> which is valid syntax for gcc/ld and keeps scons of that "/usr/local/lib".
> I'm quite sure that there should be a better solution.
> 
> Regards,
> Christoph
> 

Christoph,
Thanks for your answer.

I am wondering, if this could have something to do with the simultaneous
presence of libncurses in base system and ports?

ldconfig -r | grep libncurses
29:-lncursesw.8 => /lib/libncursesw.so.8
30:-lncurses.8 => /lib/libncurses.so.8
1127:-lncursesw.5 => /usr/local/lib/libncursesw.so.5
1277:-lncurses.5 => /usr/local/lib/libncurses.so.5

In astro/gpsd file 'SConstruct', lines 450--465 it seems, they try to
test for the right version of ncurses ...

___
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: astro/gpsd fails to build on CURRENT

[Christoph Moench-Tegeder]

## Rainer Hurling (rhur...@gwdg.de):

> I am wondering, if this could have something to do with the simultaneous
> presence of libncurses in base system and ports?

No, that's no problem. I'd blame scons and scons alone, as it tries
to interpret the output of ncurses5-config, which is meant to be taken
at face value. But then, I'm always suspicious of build utilities trying
to be intelligent...

Regards,
Christoph

-- 
Spare Space
___
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: x11/nvidia-driver-173 build failed on CURRENT

[sig6247]

On Mon, 06 May 2013 14:14:04 +0200, Dimitry Andric  wrote:

>> /wrkdirs/usr/ports/x11/nvidia-driver-173/work/NVIDIA-FreeBSD-x86-173.14.35/src/nv-freebsd.h:145:11:
>>  note: previous declaration is here
>> RM_STATUS os_alloc_contig_pages(void **, U032);
>>^
>
> Please try the attached patch.  I am not sure if there are more driver
> versions that include these inconsisent prototypes, but if anybody is
> aware of them, we can adjust the ${NVVERSION} check a little.

Thanks so much for the patch, it worked for me.

___
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"

a2ps-letter -> a2ps

[The BSD Dreamer]

I wish the UPDATING note on "users of print/a2ps-{a4,letter} ... " had said 
I should remove a2ps-letter or I guess replace it (ie portmaster -o 
print/a2ps print/a2ps-letter).  Because, while hunting where a port 
dependency had crept in and broke other packagesI noticed that I had 
a2ps-letter-4.13b_4 still installed with the a2ps-4.13b_5.


So, I removed a2ps-letterwhich complained that the MD5 didn't match, but 
it removed the file anyways.


Wasn't a big deal building a2ps again though

--
  Name: Lawrence "The Dreamer" Chen   Email: beas...@tardisi.com
 Snail: 1530 College Ave, A5   Blog: http://lawrencechen.net
Manhattan, KS 66502-2768  Phone: 785-789-4132
___
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"

nginx SPDY and openssl

[The BSD Dreamer]

So, with the new nginx, I saw SPDY.  Being curious I turned it on.  It said 
"(SSL req.)", but it wasn't obvious that it mean that it meant openssl from 
ports, which was going to break everything else that uses SSL on my system.


At least everything that needs to verify certificates, because ports OPENSSL 
doesn't have such things, lives in a different place and apparently wants 
things in a different format that ca_root_nss (since I had tried copying that 
overI didn't dig further, since it was 1am and I wanted to crash...so I 
removed the openssl port and rebuilt all the ports that it said depended on 
it.  (unchecked SPDY in nginx config first, of course)


This morning I found other ports (such as subversion and virtualbox-ose) 
that weren't working, because libssl.so.8 was missing.  So, ended up just 
rebuilding all the ports that been updated since openssl had appeared.  
Probably overkillbut quicker than checking each executable


--
  Name: Lawrence "The Dreamer" Chen   Email: beas...@tardisi.com
 Snail: 1530 College Ave, A5   Blog: http://lawrencechen.net
Manhattan, KS 66502-2768  Phone: 785-789-4132
___
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: ports/178250: Fix build failures of japanese/{mozc-server, mozc-tool, ibus-mozc, mozc-el}

[Hiroki Sato]

Hiroki Sato  wrote
  in <20130503.215135.1987071730491164980@allbsd.org>:

hr> hr>  Thanks for the feedback!  A revised version is as follows:
hr> hr>
hr> hr>   http://people.allbsd.org/~hrs/FreeBSD/mozc_port_20130501-1.diff
hr> hr>   http://people.allbsd.org/~hrs/FreeBSD/mozc_port_full_20130501-1.tar.gz
hr> hr>
hr> hr>  In addition to fixing the spotted issues, toolchain handling has been
hr> hr>  fixed.  I am waiting for a report from one who got a build error on a
hr> hr>  10-CURRENT box.  Any comments are welcome.

 Another minor build issue when binutils package is installed has been
 fixed.

 http://people.allbsd.org/~hrs/FreeBSD/mozc_port_full_20130508-1.tar.gz
 http://people.allbsd.org/~hrs/FreeBSD/mozc_port_20130508-1.diff

 A brief summary of the changes is as follows:

  mozc_port_20130508-1.diff 
 - Add Japan Post zip code dictionary.
 - Add LICENSE.
 - Fix malformed BUILD_DEPENDS and remove unnecessary dependencies.
   Use USE_* in a consistent manner.
 - Fix inconsistency toolchain usage in build_tools and the others.
   Hardcoded g++ was always used only for the former even if both gcc
   and clang were available.
 - Enable -Werror.
 - Fix SSP issue on i386 platform.
 - Let cpp(1) to replace LOCALBASE instead of patching and sed(1).
 - Use GYP_DEFINES for build variables instead of patching.
 - Separate the stages of configuration and build from each other.
 - Add options for localbase and openssl-related configuration to gyp
   instead of patching.
 - Fix makesum target.
 - Fix whitespaces to make portlint happy.
 - Disable serialization for linking.  It is not needed.
 - Remove hardcoded mozc.xml.
 - Respect DISABLE_MAKE_JOBS=yes.  Do not calculate the factor using the
   number of CPUs.
 - Remove a confusing message after pkg-message.
 - Rename a deprecated function (inactivate-current-input-method-function)
   in mozc.el in a compatible fashion with the older emacsen [1].
 - Add leim-list.el for registration of mozc-mode via LEIM API.
   "(require 'mozc)" is no longer needed.
 - Fix a build problem when binutils is installed and ${LOCALBASE}/bin
   comes first in $PATH [2].

 Submitted by:   Tadaaki Nagao [1]
 Reported by:Kenichi Niioka [2]
 

-- Hiroki


pgpvjF47ni_np.pgp
Description: PGP signature

pkg: tex-kpathsea-6.1.0 conflicts with tex-kpathsea-6.1.0

[Anton Shterenlikht]

On ia64 r247266 with ports at r317606:

===>   Compressing manual pages for tex-kpathsea-6.1.0
===>   Running ldconfig
/sbin/ldconfig -m /usr/local/lib
===>   Registering installation for tex-kpathsea-6.1.0
Installing tex-kpathsea-6.1.0...pkg: tex-kpathsea-6.1.0 conflicts with 
tex-kpathsea-6.1.0 (installs files into the same place).  Problematic file: 
/usr/local/man/man1/kpseaccess.1.gz
*** [fake-pkg] Error code 70

Stop in /usr/ports/devel/tex-kpathsea.


Thanks

Anton
___
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: pkg: tex-kpathsea-6.1.0 conflicts with tex-kpathsea-6.1.0

[Hiroki Sato]

Anton Shterenlikht  wrote
  in <201305071613.r47gdhdf075...@mech-cluster241.men.bris.ac.uk>:

me> On ia64 r247266 with ports at r317606:
me>
me> ===>   Compressing manual pages for tex-kpathsea-6.1.0
me> ===>   Running ldconfig
me> /sbin/ldconfig -m /usr/local/lib
me> ===>   Registering installation for tex-kpathsea-6.1.0
me> Installing tex-kpathsea-6.1.0...pkg: tex-kpathsea-6.1.0 conflicts with 
tex-kpathsea-6.1.0 (installs files into the same place).  Problematic file: 
/usr/local/man/man1/kpseaccess.1.gz
me> *** [fake-pkg] Error code 70
me>
me> Stop in /usr/ports/devel/tex-kpathsea.

 Can you send me installed package lists displayed by "pkg info" and
 "pkg_info"?

-- Hiroki


pgpf1kroNa_NR.pgp
Description: PGP signature