Re: gimp error

2015-09-19 Thread Walter Schwarzenfeld 

Hallo !!

Please, read the newest /usr/port/UPDATING.

greetings
W.S.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: graphics/jpeg-turbo breaks on strip-debug

2015-09-19 Thread Antoine Brodin 
On Sat, Sep 19, 2015 at 5:32 PM, Julian H. Stacey  wrote:
> Hi ports@
> cc portmgr@ as MAINTAINER= of graphics/jpeg-turbo
>
> graphics/jpeg-turbo breaks on strip-debug
> I've commented out all occurences I can find, but it's still breaking.
> Any ideas ? Or a fix even ?

Hi,

Could you check that the version of nasm you are using has this fix:
https://svnweb.freebsd.org/changeset/ports/384314
It's supposed to fix this issue.

Cheers,

Antoine

> On current, kernel & src from yesterday, ports todays
> uname -a
> FreeBSD lapr.js.berklix.net 11.0-CURRENT FreeBSD 11.0-CURRENT
> #12135: Thu Sep 17 14:54:15 CEST 2015
> j...@lapr.js.berklix.net:/usr/src/sys/amd64/compile/LAPR.small
> amd64
> rm -r /var/db/ports/graphics_jpeg-turbo
> cd /usr/ports/graphics/jpeg-turbo  ; make clean ; make
> strip --strip-debug 
> /data/release/11.0-CURRENT/usr/ports/graphics/jpeg-turbo/work/stage/usr/local/lib/libjpeg.a
> strip: elf_update() failed: Layout constraint violation
> *** Error code 1
> file 
> /data/release/11.0-CURRENT/usr/ports/graphics/jpeg-turbo/work/stage/usr/local/lib/libjpeg.a
> /data/release/11.0-CURRENT/usr/ports/graphics/jpeg-turbo/work/\
> stage/usr/local/lib/libjpeg.a: current ar archive
> -rwxr-xr-x  1 root  wheel  560734 Sep 19 16:06
> strip --strip-debug /data/release/11.0-CURRENT/usr/ports/graphics/\
> jpeg-turbo/work/stage/usr/local/lib/libjpeg.a
> strip: elf_update() failed: Layout constraint violation
> strip 
> /data/release/11.0-CURRENT/usr/ports/graphics/jpeg-turbo/work/stage/usr/local/lib/libjpeg.a
> Succeeded
> -rwxr-xr-x  1 root  wheel  411050 Sep 19 16:08 /data/release/\
> 11.0-CURRENT/usr/ports/graphics/jpeg-turbo/work/stage/\
> usr/local/lib/libjpeg.a*
> file `which strip`
> /usr/bin/strip: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), 
> dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 11.0 
> (1100079), stripped
>
> strip-debug is not in a clean /usr/ports/graphics/jpeg-turbo/
>
> but strip-debug turns up during building:
> work/libjpeg-turbo-1.4.1/aclocal.m4:  test -z "$old_striplib" && 
> old_striplib="$STRIP --strip-debug"
> work/libjpeg-turbo-1.4.1/configure.libtool.bak:  test -z 
> "$old_striplib" && old_striplib="$STRIP --strip-debug"
> work/libjpeg-turbo-1.4.1/configure:  test -z "$old_striplib" && 
> old_striplib="$STRIP --strip-debug"
> work/libjpeg-turbo-1.4.1/libtool:old_striplib="strip --strip-debug"
>
> strip-debug is coming from a macro or include, but not from my /etc/make.conf 
> or includes
>
> MK/Uses/kmod.mk:STRIP_CMD+=  --strip-debug # do not strip kernel symbols
> Commented out
>
> rm -r /var/db/ports/graphics_jpeg-turbo
> cd /usr/ports/graphics/jpeg-turbo ; make clean ; make
>
> Still breaks
> cd /usr/share/mk
> Grep strip-debug
>   bsd.lib.mk:   ${OBJCOPY} --strip-debug 
> --add-gnu-debuglink=${SHLIB_NAME}.debug \
>   bsd.prog.mk:  ${OBJCOPY} --strip-debug 
> --add-gnu-debuglink=${PROGNAME}.debug \
>
> rm -r /var/db/ports/graphics_jpeg-turbo
> cd /usr/ports/graphics/jpeg-turbo ; make clean ; make MK_DEBUG_FILES=no
> strip --strip-debug
> /data/release/11.0-CURRENT/usr/ports/graphics/jpeg-turbo/work/stage/\
> usr/local/lib/libjpeg.a
> strip: elf_update() failed: Layout constraint violation
>
> PS I did a trawl for strip-debug
>  ports/
>   Mk/Uses/kmod.mk:STRIP_CMD+=   --strip-debug # do not strip kernel symbols
>   devel/nasm/files/patch-elf64-alignment:% strip -o /dev/null --strip-debug 
> jccolss2-64.o
>   emulators/virtualbox-ose/files/extrapatch-Config.kmk:+#   objcopy 
> --strip-debug $(out)
>   emulators/virtualbox-ose/files/extrapatch-Config.kmk:-objcopy 
> --strip-debug $(out)
>
>  src/
>   contrib/apr/configure:  test -z "$old_striplib" && old_striplib="$STRIP 
> --strip-debug"
>   contrib/binutils/bfd/configure:  test -z "$old_striplib" && 
> old_striplib="$STRIP --strip-debug"
>   contrib/binutils/binutils/ChangeLog-0203: (strip): Document -d as an 
> alias for --strip-debug.
>   contrib/binutils/binutils/ChangeLog-0203: --strip-debug.
>   contrib/binutils/binutils/ChangeLog-0203: Mention that --strip-debug 
> removes sections as well.
>   contrib/binutils/binutils/NEWS:  those sections that would be stripped out 
> by --strip-debug.  The idea is that
>   contrib/binutils/binutils/configure:  test -z "$old_striplib" && 
> old_striplib="$STRIP --strip-debug"
>   contrib/binutils/binutils/doc/binutils.7:[-g|--strip-debug]
>   contrib/binutils/binutils/doc/binutils.7:  [-S|-g|-d|--strip-debug]
>   contrib/binutils/binutils/doc/binutils.7:.It  --strip-debug
>   contrib/binutils/binutils/doc/binutils.7:.Li objcopy --strip-debug foo
>   contrib/binutils/binutils/doc/binutils.7:.Li strip --strip-debug foo
>   contrib/binutils/binutils/doc/binutils.7:.Op

FreeBSD 9: make: Error expanding embedded variable

2015-09-19 Thread Christian Weisgerber 
The po/Makefile.in.in file shipped with gettext 0.19 triggers a bug
in the old make(1) on FreeBSD 9 that causes this cryptic error:

Error expanding embedded variable.

A minimal Makefile to reproduce the problem is this:

FOO =
BAR = $(FOO$(BAZ))
all: $(BAR)

The bug no longer exists in bmake.

If you google for the error message, you'll find the advice "use
gmake", which is not particularly appropriate in this case, since
po/Makefile.in.in is portable and does not use any gmake features.

The po/Makefile.in.in that ships with gettext is copied into a
zillion projects.  I ran into the problem when pkg-fallout sent me
a report about my recent archivers/gcpio update.  I expect the
problem to spread, as projects start using newer versions of this
file.

Here's the fix I used:

--- po/Makefile.in.in.orig  2015-09-12 10:51:46 UTC
+++ po/Makefile.in.in
@@ -80,6 +80,7 @@ CATALOGS = @CATALOGS@
 POFILESDEPS_ = $(srcdir)/$(DOMAIN).pot
 POFILESDEPS_yes = $(POFILESDEPS_)
 POFILESDEPS_no =
+PO_DEPENDS_ON_POT =
 POFILESDEPS = $(POFILESDEPS_$(PO_DEPENDS_ON_POT))
 
 DISTFILESDEPS_ = update-po
-- 
Christian "naddy" Weisgerber  na...@mips.inka.de
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: graphics/jpeg-turbo breaks on strip-debug

2015-09-19 Thread Julian H. Stacey 
Antoine Brodin wrote:
> On Sat, Sep 19, 2015 at 5:32 PM, Julian H. Stacey  wrote:
> > Hi ports@
> > cc portmgr@ as MAINTAINER= of graphics/jpeg-turbo
> >
> > graphics/jpeg-turbo breaks on strip-debug
> > I've commented out all occurences I can find, but it's still breaking.
> > Any ideas ? Or a fix even ?
> 
> Hi,
> 
> Could you check that the version of nasm you are using has this fix:
> https://svnweb.freebsd.org/changeset/ports/384314
> It's supposed to fix this issue.
> 
> Cheers,
> 
> Antoine

Great !  It works ! Thanks Antoine! I'd have never found that!
I cleaned & re-installed /usr/ports/devel/nasm 
-r-xr-xr-x  1 root  wheel  1076888 Sep 20 01:03 /usr/local/bin/nasm*
-r-xr-xr-x  1 root  wheel  1073728 Dec 24  2014 /usr/local/bin/nasm.was*
& now graphics/jpeg-turbo builds :-)

I removed commenting out of strip-debug in all 3 of
/usr/ports/Mk/Uses/kmod.mk
/usr/share/mk bsd.lib.mk bsd.prog.mk
& jpeg-turbo still builds :-)

Cheers,
Julian
--
Julian Stacey, BSD Linux Unix C Sys Eng Consultant Munich http://berklix.com
 Reply after previous text, like a play - Not before, which looses context.
 Indent previous text with "> " Insert new lines before 80 chars.
 Send plain text, Not quoted-printable, Not HTML, Not ms.doc, Not base64.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

graphics/jpeg-turbo breaks on strip-debug

2015-09-19 Thread Julian H. Stacey 
Hi ports@
cc portmgr@ as MAINTAINER= of graphics/jpeg-turbo

graphics/jpeg-turbo breaks on strip-debug
I've commented out all occurences I can find, but it's still breaking.
Any ideas ? Or a fix even ?

On current, kernel & src from yesterday, ports todays
uname -a
FreeBSD lapr.js.berklix.net 11.0-CURRENT FreeBSD 11.0-CURRENT
#12135: Thu Sep 17 14:54:15 CEST 2015
j...@lapr.js.berklix.net:/usr/src/sys/amd64/compile/LAPR.small
amd64
rm -r /var/db/ports/graphics_jpeg-turbo
cd /usr/ports/graphics/jpeg-turbo  ; make clean ; make
strip --strip-debug 
/data/release/11.0-CURRENT/usr/ports/graphics/jpeg-turbo/work/stage/usr/local/lib/libjpeg.a
strip: elf_update() failed: Layout constraint violation
*** Error code 1
file 
/data/release/11.0-CURRENT/usr/ports/graphics/jpeg-turbo/work/stage/usr/local/lib/libjpeg.a
/data/release/11.0-CURRENT/usr/ports/graphics/jpeg-turbo/work/\
stage/usr/local/lib/libjpeg.a: current ar archive
-rwxr-xr-x  1 root  wheel  560734 Sep 19 16:06
strip --strip-debug /data/release/11.0-CURRENT/usr/ports/graphics/\
jpeg-turbo/work/stage/usr/local/lib/libjpeg.a
strip: elf_update() failed: Layout constraint violation
strip 
/data/release/11.0-CURRENT/usr/ports/graphics/jpeg-turbo/work/stage/usr/local/lib/libjpeg.a
Succeeded
-rwxr-xr-x  1 root  wheel  411050 Sep 19 16:08 /data/release/\
11.0-CURRENT/usr/ports/graphics/jpeg-turbo/work/stage/\
usr/local/lib/libjpeg.a*
file `which strip`
/usr/bin/strip: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), 
dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 11.0 
(1100079), stripped

strip-debug is not in a clean /usr/ports/graphics/jpeg-turbo/

but strip-debug turns up during building:
work/libjpeg-turbo-1.4.1/aclocal.m4:  test -z "$old_striplib" && 
old_striplib="$STRIP --strip-debug"
work/libjpeg-turbo-1.4.1/configure.libtool.bak:  test -z 
"$old_striplib" && old_striplib="$STRIP --strip-debug"
work/libjpeg-turbo-1.4.1/configure:  test -z "$old_striplib" && 
old_striplib="$STRIP --strip-debug"
work/libjpeg-turbo-1.4.1/libtool:old_striplib="strip --strip-debug"

strip-debug is coming from a macro or include, but not from my /etc/make.conf 
or includes

MK/Uses/kmod.mk:STRIP_CMD+=  --strip-debug # do not strip kernel symbols
Commented out

rm -r /var/db/ports/graphics_jpeg-turbo
cd /usr/ports/graphics/jpeg-turbo ; make clean ; make

Still breaks
cd /usr/share/mk
Grep strip-debug
  bsd.lib.mk:   ${OBJCOPY} --strip-debug 
--add-gnu-debuglink=${SHLIB_NAME}.debug \
  bsd.prog.mk:  ${OBJCOPY} --strip-debug --add-gnu-debuglink=${PROGNAME}.debug \

rm -r /var/db/ports/graphics_jpeg-turbo
cd /usr/ports/graphics/jpeg-turbo ; make clean ; make MK_DEBUG_FILES=no
strip --strip-debug
/data/release/11.0-CURRENT/usr/ports/graphics/jpeg-turbo/work/stage/\
usr/local/lib/libjpeg.a
strip: elf_update() failed: Layout constraint violation

PS I did a trawl for strip-debug
 ports/
  Mk/Uses/kmod.mk:STRIP_CMD+=   --strip-debug # do not strip kernel symbols
  devel/nasm/files/patch-elf64-alignment:% strip -o /dev/null --strip-debug 
jccolss2-64.o
  emulators/virtualbox-ose/files/extrapatch-Config.kmk:+#   objcopy 
--strip-debug $(out)
  emulators/virtualbox-ose/files/extrapatch-Config.kmk:-objcopy 
--strip-debug $(out)
 
 src/
  contrib/apr/configure:  test -z "$old_striplib" && old_striplib="$STRIP 
--strip-debug"
  contrib/binutils/bfd/configure:  test -z "$old_striplib" && 
old_striplib="$STRIP --strip-debug"
  contrib/binutils/binutils/ChangeLog-0203: (strip): Document -d as an 
alias for --strip-debug.
  contrib/binutils/binutils/ChangeLog-0203: --strip-debug.
  contrib/binutils/binutils/ChangeLog-0203: Mention that --strip-debug 
removes sections as well.
  contrib/binutils/binutils/NEWS:  those sections that would be stripped out by 
--strip-debug.  The idea is that
  contrib/binutils/binutils/configure:  test -z "$old_striplib" && 
old_striplib="$STRIP --strip-debug"
  contrib/binutils/binutils/doc/binutils.7:[-g|--strip-debug]
  contrib/binutils/binutils/doc/binutils.7:  [-S|-g|-d|--strip-debug]
  contrib/binutils/binutils/doc/binutils.7:.It  --strip-debug
  contrib/binutils/binutils/doc/binutils.7:.Li objcopy --strip-debug foo
  contrib/binutils/binutils/doc/binutils.7:.Li strip --strip-debug foo
  contrib/binutils/binutils/doc/binutils.7:.Op --strip-debug
  contrib/binutils/binutils/doc/binutils.texi:
[@option{-g}|@option{--strip-debug}]
  contrib/binutils/binutils/doc/binutils.texi:  
[@option{-S}|@option{-g}|@option{-d}|@option{--strip-debug}]
  contrib/binutils/binutils/doc/binutils.texi:@item Run @code{objcopy 
--strip-debug foo}
  contrib/binutils/binutils/doc/binutils.texi:@item Run @code{objcopy 
--strip-debug foo} to create a

Re: ZFS 9.2/9.3 oh so broken...

2015-09-19 Thread Michelle Sullivan 
Chad J. Milios wrote:
>> 9.x is really quite old I'd strongly advise you move to 10.2 as it includes 
>> a lot of fixes and enhancements to many areas including ZFS.
>> 

I *cannot* move to 10.x too many things break (none of my test servers
are currently operational, mostly through ports issues, but not only)
>
> 9.3 isn't that old and as far as I'm concerned 10.x is still today 
> unfortunately causing more problems than it's fixed. That's just my opinion 
> though. I'm an old coot with a fear of the cutting edge. I'll be bringing up 
> the rear clutching onto my legacy OS, thank you very much. Don't push me. 
> "Get off my lawn." I'm not totally alone in this sentiment, am I?
>   

No you're not alone.

> I haven't had a single issue to report with online replacement and 
> resilvering of drives on 9.0-9.3 and I've probably swapped about 20 failed 
> drives using ZFS across 9.x versions. 

I've had several issues - though some have been my own making, it's been
mostly stable and this drive failure was the worst (one drive
failed, the bus reset took out another (which came back online after a
kick) and then a third reset itself offline and killed the pool half way
through the resilver...  I kicked it back online, lost 2 files, which
then returned when the resilver got to the same point...! 


> Yes, I've had a second drive fail while resilvering a disk in a raidz2. I 
> haven't used any hardware RAID controllers in conjunction with FreeBSD for 
> about 5 years now and at first glance it looked to me like the OP might have 
> been. (Sorry I didn't look at it in detail, I'm on my phone and pastedumps 
> hurt my eyes.)
>   

I am - big mistake... well sorta, have 2 almost identical machines, one
gives trouble the other hasn't missed a beat since it was powered up -
both identical configs the only difference is the usage and the mobo's
... the first was non ECC ram the second is ECC.  The usage difference
is the one with the ECC is the 'backup' (a rsync'd mirror of the first)

... now off to get ready, wish me luck and I'll deal with all of this
when back from honeymoon. ;-)

Michelle

-- 
Michelle Sullivan
http://www.mhix.org/

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: ZFS 9.2/9.3 oh so broken...

2015-09-19 Thread Michelle Sullivan 
Steven Hartland wrote:
> freebsd-ports@ is not really the right mailing list for this as
> there's no ports involved, unless I'm totally missing something, best
> place is freebsd-fs@.

You are correct, sorry - I was not exactly thinking straight last
night...  today is a big day and I just wanted to get the mail done so I
could forget about it.

-- 
Michelle Sullivan
http://www.mhix.org/

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: FreeBSD Port: nvidia-driver for geforce 9500 GT

2015-09-19 Thread Wayne Sierke 
Tom,

On Sat, 2015-08-29 at 14:52 -0600, tom oakes wrote:
> I recently installed FreeBSD 10.2 on a computer with a Geforce 9500 
> GT.  
> The nvidia archive site says that the nvidia-driver-340-340.76 and 
> the 
> nvidia-driver-304-304.125 should work. When I try to make the port 
> for 
> either of these, I get an error "This driver does not support FreeBSD 
> 10.xx/-current" There are then more error messages.

I'm using -340 on 10.2-RELEASE amd64 for a 9600GT. Installed from
package but I just did a build which completed without error.

Is your ports tree up-to-date?


Wayne

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: port for letsencrypt ?

2015-09-19 Thread Carlos J Puga Medina 
On Sat, 2015-09-19 at 16:26 +0200, A.J. 

Hi Fonz,

> Carlos J Puga Medina wrote:
> 
> > I'm working on letsencrypt port but I need to fix somethings before
> > submit it.
> 
> By all means, feel free to ask if you need help with anything. I
> recently
> signed my domain up for the beta, so it would be nice if I can manage
> everything from FreeBSD and don't need to turn to a Linux box.
> 

LOL. I created the letsencrypt port, it install fine but fails to run
properly.

Furthermore, I opened an issue:

https://github.com/letsencrypt/letsencrypt/issues/792

I want to figure out what happens here :)

> Regards,
> 
> AvW
> 

Cheers,
-- 
Carlos Jacobo Puga Medina 
PGP fingerprint = C60E 9497 5302 793B CC2D  BB89 A1F3 5D66 E6D0 5453


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

Re: port for letsencrypt ?

2015-09-19 Thread Carlos J Puga Medina 
On Fri, 2015-09-18 at 12:35 -0500, Mark Felder wrote:
> 
> On Fri, Sep 18, 2015, at 07:07, Carlos J Puga Medina wrote:
> > Hi Jason,
> > 
> > In order to build letsencrypt port are necessary the following
> > ports
> > which actually are not into the ports tree.
> > 
> > - devel/py-repoze.sphinx.autointerface
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203189
> > - textproc/py-sphinxcontrib-programoutput
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203190
> > 
> 
> These have now landed in the tree. 

Thank you, Mark. I'm working on letsencrypt port but I need to fix
somethings before submit it. I hope have it ready in a couple of days.

> 
> 
-- 
Carlos Jacobo Puga Medina 
PGP fingerprint = C60E 9497 5302 793B CC2D  BB89 A1F3 5D66 E6D0 5453


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