Re: graphics/gegl 0.1.8 does not build

2013-01-27 Thread Koop Mast
On Sat, 2013-01-26 at 18:40 -0600, ajtiM wrote:
 On Saturday 26 January 2013 14:55:06 Joseph A. Nagy, Jr wrote:
  On 01/26/13 13:56, Robert Huff wrote:
   Joseph A. Nagy, Jr writes:
 On 01/26/13 12:00, Rainer Hurling wrote:
  ../tools/gobj2dot.rb .. | /usr/local/bin/dot png 
  images/inheritance.png
  Error: dot: can't open png
  Failed to parse ../operations/workshop/max-rgb.c, probably invalid
  utf8
  gmake[3]: *** [images/inheritance.png] Fehler 2
  gmake[3]: Leaving directory
  `/usr/ports/graphics/gegl/work/gegl-0.1.8/docs'
  gmake[2]: *** [all-recursive] Fehler 1
 
 I just recognized (thanks to David), that the 'real' first error is
 not
 
  a problem with utf8 conversion, but in
 
 snip
 
 I just wanted to relay I built this on 9.1 with clang w/o any errors.
 
 I am unable to get a clean build on
   
   FreeBSD 10.0-CURRENT #0: Sun Dec 30 12:52:09 EST 2012  amd64
   
 and get the same error.
 
 Robert Huff
  
  FreeBSD alex-laptop 9.1-RELEASE FreeBSD 9.1-RELEASE #8: Tue Jan 22
  14:00:27 CST 2013 root@alex-laptop:/usr/obj/usr/src/sys/ALEX-LAPTOP
amd64
  
pkg which /usr/local/bin/gegl
  /usr/local/bin/gegl was installed by package gegl-0.1.8_6
 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243826: Tue Dec  4 06:55:39 UTC 2012 
 r...@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  i386
 
 I repeat with clang and gcc. I use portmaster and make but I got the same 
 error.
 
 

I just committed a fix for gegl doc build. I forgot to lift one small
change from the gnome devel repo. Thanks for reporting!

-Koop

___
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/gegl 0.1.8 does not build

2013-01-27 Thread Rainer Hurling
On 27.01.2013 12:38 (UTC+2), Koop Mast wrote:
 On Sat, 2013-01-26 at 18:40 -0600, ajtiM wrote:
 On Saturday 26 January 2013 14:55:06 Joseph A. Nagy, Jr wrote:
 On 01/26/13 13:56, Robert Huff wrote:
 Joseph A. Nagy, Jr writes:
   On 01/26/13 12:00, Rainer Hurling wrote:
../tools/gobj2dot.rb .. | /usr/local/bin/dot png 
images/inheritance.png
Error: dot: can't open png
Failed to parse ../operations/workshop/max-rgb.c, probably invalid
utf8
gmake[3]: *** [images/inheritance.png] Fehler 2
gmake[3]: Leaving directory
`/usr/ports/graphics/gegl/work/gegl-0.1.8/docs'
gmake[2]: *** [all-recursive] Fehler 1
   
   I just recognized (thanks to David), that the 'real' first error is
   not
   
a problem with utf8 conversion, but in
   
   snip
   
   I just wanted to relay I built this on 9.1 with clang w/o any errors.

I am unable to get a clean build on

 FreeBSD 10.0-CURRENT #0: Sun Dec 30 12:52:09 EST 2012  amd64

and get the same error.

Robert Huff

 FreeBSD alex-laptop 9.1-RELEASE FreeBSD 9.1-RELEASE #8: Tue Jan 22
 14:00:27 CST 2013 root@alex-laptop:/usr/obj/usr/src/sys/ALEX-LAPTOP
   amd64

   pkg which /usr/local/bin/gegl
 /usr/local/bin/gegl was installed by package gegl-0.1.8_6
 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243826: Tue Dec  4 06:55:39 UTC 2012 
 r...@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  i386

 I repeat with clang and gcc. I use portmaster and make but I got the same 
 error.


 
 I just committed a fix for gegl doc build. I forgot to lift one small
 change from the gnome devel repo. Thanks for reporting!
 
 -Koop

Hi Koop,

many thanks for the update. It works fine for me.

As mentioned in my second mail on this thread, one of the patches in the
Makefile is not necessary anymore, because it was updated upstream:

--- Makefile.orig   2013-01-27 12:50:15.0 +0100
+++ Makefile2013-01-27 13:25:30.0 +0100
@@ -203,8 +203,6 @@
 .endif
${REINPLACE_CMD} -e 's|\(lua\)\(5\.1\)|\1-\2|g ; s|x86_64|amd64|g' \
${WRKSRC}/configure
-   ${REINPLACE_CMD} -e 's|/usr/bin/ruby|/usr/bin/env ruby|' \
-   ${WRKSRC}/tools/gobj2dot.rb

 post-build:
 .if ${PORT_OPTIONS:MDOCS}


Regards,
Rainer

___
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: Cronjob Cvsup - What?

2013-01-27 Thread Thomas Mueller
W. D. w...@us-webmasters.com writes:

 According to:

   http://www.freebsd.org/news/2012-compromise.html

 Cvsup is deprecated.  If I have a Cron entry like:

 #-
 #Min   HrDOM   Mnth  DOW   Command

 #   At 3:46 in the morning, everyday, as root, update the ports tree:
 46 3 * * * /usr/local/bin/cvsup   -h   
 cvsup12.FreeBSD.org  /usr/share/examples/cvsup/ports-supfile
 #-

 What should I use: freebsd-update, Subversion, portsnap, or what?

 What would be the best Cron command to keep ports updated on a daily
 basis?

Lowell Gilbert freebsd-questions-lo...@be-well.ilk.org responds:

 portsnap is almost certainly the best answer for you.

 freebsd-update is for the base system, not ports.

 If you needed version control features on your ports tree (especially if
 you were regularly contributing changes to ports), getting and updating
 your tree through subversion would have some extra features you might
 want, but it doesn't sound as if that is the case for you.

 Unless you have a specific reason why portsnap doesn't fit your use
 case, it's definitely the way to go for just keeping a ports tree
 updated regularly.

I've always used portsnap fetch update after the initial portsnap fetch
and portsnap extract.  What would be the adverse side effect of using svn
instead?

Tom
___
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: Cronjob Cvsup - What?

2013-01-27 Thread RW
On Sun, 27 Jan 2013 08:22:02 -0500
Thomas Mueller wrote:


 I've always used portsnap fetch update after the initial portsnap
 fetch and portsnap extract.  What would be the adverse side effect
 of using svn instead?

In general it's best to avoid mixing update tools unless you fully
understand all the corner cases and know it's safe. 

The most significant  problem is they can lose track of what files
need to be deleted, which can lead to obsolete patch files being left
in the tree. One of the functions of portsnap extract is to eliminate
extra files in port directories to avoid this 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: graphics/gegl 0.1.8 does not build

2013-01-27 Thread Mike Harding
graphviz was just updated, and no longer, apparently, contains a
library called 'libgraph', it's now, as far as I can tell, called
'libcgraph', so the LIB_DEPENDS in the gegl makefile needs to start
with 'cgraph'

On Sun, Jan 27, 2013 at 4:36 AM, Rainer Hurling rhur...@gwdg.de wrote:
 On 27.01.2013 12:38 (UTC+2), Koop Mast wrote:
 On Sat, 2013-01-26 at 18:40 -0600, ajtiM wrote:
 On Saturday 26 January 2013 14:55:06 Joseph A. Nagy, Jr wrote:
 On 01/26/13 13:56, Robert Huff wrote:
 Joseph A. Nagy, Jr writes:
   On 01/26/13 12:00, Rainer Hurling wrote:
../tools/gobj2dot.rb .. | /usr/local/bin/dot png 
images/inheritance.png
Error: dot: can't open png
Failed to parse ../operations/workshop/max-rgb.c, probably invalid
utf8
gmake[3]: *** [images/inheritance.png] Fehler 2
gmake[3]: Leaving directory
`/usr/ports/graphics/gegl/work/gegl-0.1.8/docs'
gmake[2]: *** [all-recursive] Fehler 1
   
   I just recognized (thanks to David), that the 'real' first error is
   not
   
a problem with utf8 conversion, but in

   snip

   I just wanted to relay I built this on 9.1 with clang w/o any errors.

I am unable to get a clean build on

 FreeBSD 10.0-CURRENT #0: Sun Dec 30 12:52:09 EST 2012  amd64

and get the same error.

Robert Huff

 FreeBSD alex-laptop 9.1-RELEASE FreeBSD 9.1-RELEASE #8: Tue Jan 22
 14:00:27 CST 2013 root@alex-laptop:/usr/obj/usr/src/sys/ALEX-LAPTOP
   amd64

   pkg which /usr/local/bin/gegl
 /usr/local/bin/gegl was installed by package gegl-0.1.8_6
 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243826: Tue Dec  4 06:55:39 UTC 2012
 r...@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  i386

 I repeat with clang and gcc. I use portmaster and make but I got the same
 error.



 I just committed a fix for gegl doc build. I forgot to lift one small
 change from the gnome devel repo. Thanks for reporting!

 -Koop

 Hi Koop,

 many thanks for the update. It works fine for me.

 As mentioned in my second mail on this thread, one of the patches in the
 Makefile is not necessary anymore, because it was updated upstream:

 --- Makefile.orig   2013-01-27 12:50:15.0 +0100
 +++ Makefile2013-01-27 13:25:30.0 +0100
 @@ -203,8 +203,6 @@
  .endif
 ${REINPLACE_CMD} -e 's|\(lua\)\(5\.1\)|\1-\2|g ; s|x86_64|amd64|g' \
 ${WRKSRC}/configure
 -   ${REINPLACE_CMD} -e 's|/usr/bin/ruby|/usr/bin/env ruby|' \
 -   ${WRKSRC}/tools/gobj2dot.rb

  post-build:
  .if ${PORT_OPTIONS:MDOCS}


 Regards,
 Rainer

___
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


ghostscript dependency checking, CURRENT + pkgng

2013-01-27 Thread George Mitchell

On a FreeBSD 10.0-CURRENT system on Raspberry Pi, with pkgng installed,
I built print/ghostscript9-nox11 (since I'm not planning to run X11 on
the box).  But when I try to build any of the ports that specify
USE_GHOSTSCRIPT=yes, make in the port's directory tries to satisfy
the ghostscript dependency by trying to build ghostscript9 even though
ghostscript9-nox11 is installed.  If I add

_USE_GHOSTSCRIPT_PKGNAME_SUFFIX=-nox11

to the Makefile, it fixes the problem in an ugly way (although it
didn't fix the problem for print/hplip).

uname: r245840M (image built by Alie Tab on 25 January)
ports: svnversion 308518
pkg -v: 1.0.3

What's the best way to proceed?  I have CUPS installed and it even
works, but I am pretty sure my printer will work better if I can get
print/hplip installed.  -- George Mitchell
___
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 ports you maintain which are out of date

2013-01-27 Thread portscout
Dear port maintainer,

The portscout new distfile checker has detected that one or more of your
ports appears to be out of date. Please take the opportunity to check
each of the ports listed below, and if possible and appropriate,
submit/commit an update. If any ports have already been updated, you can
safely ignore the entry.

You will not be e-mailed again for any of the port/version combinations
below.

Full details can be found at the following URL:
http://portscout.freebsd.org/po...@freebsd.org.html


Port| Current version | New version
+-+
graphics/evolvotron | 0.6.1   | 0.6.3
+-+


If any of the above results are invalid, please check the following page
for details on how to improve portscout's detection and selection of
distfiles on a per-port basis:

http://portscout.freebsd.org/info/portscout-portconfig.txt

If wish to stop receiving portscout reminders, please contact
portsc...@portscout.freebsd.org

Thanks.
___
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/gegl 0.1.8 does not build

2013-01-27 Thread Mike Harding
Oh, and link against it as well, obviously.  Looks like it links
against the old lib now:

...
  CC gegl-visitable.lo
  CCLD   libgraph.la
gmake[3]: Leaving directory
`/usr/ports/graphics/gegl/work/gegl-0.1.8/gegl/graph'
...

On Sun, Jan 27, 2013 at 7:21 AM, Mike Harding mvhard...@gmail.com wrote:
 graphviz was just updated, and no longer, apparently, contains a
 library called 'libgraph', it's now, as far as I can tell, called
 'libcgraph', so the LIB_DEPENDS in the gegl makefile needs to start
 with 'cgraph'

 On Sun, Jan 27, 2013 at 4:36 AM, Rainer Hurling rhur...@gwdg.de wrote:
 On 27.01.2013 12:38 (UTC+2), Koop Mast wrote:
 On Sat, 2013-01-26 at 18:40 -0600, ajtiM wrote:
 On Saturday 26 January 2013 14:55:06 Joseph A. Nagy, Jr wrote:
 On 01/26/13 13:56, Robert Huff wrote:
 Joseph A. Nagy, Jr writes:
   On 01/26/13 12:00, Rainer Hurling wrote:
../tools/gobj2dot.rb .. | /usr/local/bin/dot png 
images/inheritance.png
Error: dot: can't open png
Failed to parse ../operations/workshop/max-rgb.c, probably invalid
utf8
gmake[3]: *** [images/inheritance.png] Fehler 2
gmake[3]: Leaving directory
`/usr/ports/graphics/gegl/work/gegl-0.1.8/docs'
gmake[2]: *** [all-recursive] Fehler 1
   
   I just recognized (thanks to David), that the 'real' first error is
   not
   
a problem with utf8 conversion, but in

   snip

   I just wanted to relay I built this on 9.1 with clang w/o any errors.

I am unable to get a clean build on

 FreeBSD 10.0-CURRENT #0: Sun Dec 30 12:52:09 EST 2012  amd64

and get the same error.

Robert Huff

 FreeBSD alex-laptop 9.1-RELEASE FreeBSD 9.1-RELEASE #8: Tue Jan 22
 14:00:27 CST 2013 root@alex-laptop:/usr/obj/usr/src/sys/ALEX-LAPTOP
   amd64

   pkg which /usr/local/bin/gegl
 /usr/local/bin/gegl was installed by package gegl-0.1.8_6
 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243826: Tue Dec  4 06:55:39 UTC 2012
 r...@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  i386

 I repeat with clang and gcc. I use portmaster and make but I got the same
 error.



 I just committed a fix for gegl doc build. I forgot to lift one small
 change from the gnome devel repo. Thanks for reporting!

 -Koop

 Hi Koop,

 many thanks for the update. It works fine for me.

 As mentioned in my second mail on this thread, one of the patches in the
 Makefile is not necessary anymore, because it was updated upstream:

 --- Makefile.orig   2013-01-27 12:50:15.0 +0100
 +++ Makefile2013-01-27 13:25:30.0 +0100
 @@ -203,8 +203,6 @@
  .endif
 ${REINPLACE_CMD} -e 's|\(lua\)\(5\.1\)|\1-\2|g ; s|x86_64|amd64|g' \
 ${WRKSRC}/configure
 -   ${REINPLACE_CMD} -e 's|/usr/bin/ruby|/usr/bin/env ruby|' \
 -   ${WRKSRC}/tools/gobj2dot.rb

  post-build:
  .if ${PORT_OPTIONS:MDOCS}


 Regards,
 Rainer

___
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


Issue about adapting japanese/ruby-mecab to new options framework

2013-01-27 Thread Yasuhiro KIMURA
Hello all,

I adapted japanese/ruby-mecab to new options framework and sent
following PR.

http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/175258

But after submitting I found a issue that options setting dialog is
always displayed even if options save file is already created.

According to the output of 'make' with '-d' option, following things
seem to happen:

1. PKGNAMEPREFIX variable is assigned to ja- and that causes
   OPTIONSFILE variable to be expanded to /var/db/ports/ja-mecab/options. 
2. /var/db/ports/ja-mecab/options is included as options save file.
3. PKGNAMEPREFIX is re-assigned to ja-ruby19- and that causes
   OPTIONFILE to be expanded to /var/db/ports/ja-ruby-mecab/options.
4. Options dialog is invoked and result is saved to 
/var/db/ports/ja-ruby-mecab/options. 
5. Since input and output files of options setting are different,
   dialog is displayed every time 'make' is invoked.

And below is detail:

01. RUBY_DEFAULT_VER is assigned to 1.9 in /etc/make.conf of my
machine. 
02. PORTNAME is assigned to mecab in japanese/ruby-mecab/Makefile.
03. PKGNAMEPREFIX is assigned to ja- in japanese/Makefile.inc.
04. PORT_DBDIR is assigned to /var/db/ports in Mk/bsd.port.mk.
05. UNIQUENAME is assigned to ${PKGNAMEPREFIX}${PORTNAME}
in Mk/bsd.port.mk. 
06. OPTIONSFILE is assigned to ${PORT_DBDIR}/${UNIQUENAME}/options
in Mk/bsd.options.mk.
07. Check is done if ${OPTIONSFILES} exists in Mk/bsd.options.mk.
At this point ${OPTIONSFILES} is expanded to 
/var/db/ports/ja-mecab/options. 
So file named /var/db/ports/ja-mecab/options is checked.
Since japanese/ruby-mecab is depend on japanese/mecab, this file
usually exists. So this file is included as saved options file of
japanese/ruby-mecab.
08. PKGNAMEPREFIX is assigned with expansion (':=' is used) to
${PKGNAMEPREFIX}${RUBY_PKGNAMEPREFIX} in japanese/ruby-mecab/Makefile.
09. RUBY_RELVERSION is assigned to 1.9.3 in Mk/bsd.ruby.mk.
10. RUBY_PATCHLEVEL is assigned to 327 in Mk/bsd.ruby.mk.
11. RUBY_VERSION is assigned to ${RUBY_RELVERSION}.${RUBY_PATCHLEVEL}
in Mk/bsd.ruby.mk.
12. RUBY_VER is assigned to 
${RUBY_VERSION:C/([[:digit:]]+\.[[:digit:]]+).*/\1/} 
in Mk/bsd.ruby.mk.
13. RUBY_SUFFIX is assigned to ${RUBY_VER:S/.//} in Mk/bsd.ruby.mk.
14. RUBY_PKGNAMEPREFIX is assigned to ruby${RUBY_SUFFIX}- in Mk/bsd.ruby.mk.
15. /usr/bin/dialog is invoked to show options setting dialog.
16. Result of step 15 is saved to ${OPTIONSFILE}. At this point
${OPTIONSFILE} is expanded to /var/db/ports/ja-ruby19-mecab/options.
So file named /var/db/ports/ja-ruby19-mecab/options is created
and options setting is saved to it.
17. Now options settings are saved to /var/db/ports/ja-ruby19-mecab/options
at step 16, and it is different from the file included at step 07.
So it cause step 01 to 16 to be repeated every time 'make' is invoked.

And now, how should I fix this issue? Is it possible to fix it by only
patching japanese/ruby-mecab/Makefile? Or are some changes of Mk/bsd.*.mk
needed?

Any suggestion is welcome.

Best regards.

---
Yasuhiro KIMURA
___
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: devel/gobject-introspection failure on ARM

2013-01-27 Thread Tim Kientzle

On Jan 27, 2013, at 7:57 AM, George Mitchell wrote:

 System: Raspberry Pi
 uname: r245840M (Alie Tan's image from 25 January)
 ports: svnversion 308518
 
 Build dies with message sizeof(ArrayTypeBlob) is expected to be 8 but
 is 12.  (Complete build log attached.)  I made a naive attempt to fix
 it by rearranging the order of the structure members, but obviously I
 don't understand structure packing on the ARM and it didn't help.

The easiest way to hack around this is usually to
sprinkle packed decorators on a lot of structure
definitions.

  It also didn't get rid of the huge number of cast increases required
 alignment of target type warnings.

How troublesome these are depends on the processor.
I think the ARMv6 on the RaspberryPi is late enough to
support misaligned accesses.  It's a big performance hit
but better than crashing.

 I note we're at version 0.10.8 of this package, but upstream is at
 1.34.2.  (It requires glib 2.34.1, though, and we're only at 2.28.8).
 
 What's the best way to proceed?  

Given the version numbers you quote, I expect that
a newer glib would be a good start.

Good luck,

Tim

___
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/gegl 0.1.8 does not build

2013-01-27 Thread Koop Mast
On Sun, 2013-01-27 at 07:21 -0800, Mike Harding wrote:
 graphviz was just updated, and no longer, apparently, contains a
 library called 'libgraph', it's now, as far as I can tell, called
 'libcgraph', so the LIB_DEPENDS in the gegl makefile needs to start
 with 'cgraph'

Committed both suggestions, thanks!

 On Sun, Jan 27, 2013 at 4:36 AM, Rainer Hurling rhur...@gwdg.de wrote:
  On 27.01.2013 12:38 (UTC+2), Koop Mast wrote:
  On Sat, 2013-01-26 at 18:40 -0600, ajtiM wrote:
  On Saturday 26 January 2013 14:55:06 Joseph A. Nagy, Jr wrote:
  On 01/26/13 13:56, Robert Huff wrote:
  Joseph A. Nagy, Jr writes:
On 01/26/13 12:00, Rainer Hurling wrote:
 ../tools/gobj2dot.rb .. | /usr/local/bin/dot png 
 images/inheritance.png
 Error: dot: can't open png
 Failed to parse ../operations/workshop/max-rgb.c, probably invalid
 utf8
 gmake[3]: *** [images/inheritance.png] Fehler 2
 gmake[3]: Leaving directory
 `/usr/ports/graphics/gegl/work/gegl-0.1.8/docs'
 gmake[2]: *** [all-recursive] Fehler 1

I just recognized (thanks to David), that the 'real' first error is
not

 a problem with utf8 conversion, but in
 
snip
 
I just wanted to relay I built this on 9.1 with clang w/o any errors.
 
 I am unable to get a clean build on
 
  FreeBSD 10.0-CURRENT #0: Sun Dec 30 12:52:09 EST 2012  amd64
 
 and get the same error.
 
 Robert Huff
 
  FreeBSD alex-laptop 9.1-RELEASE FreeBSD 9.1-RELEASE #8: Tue Jan 22
  14:00:27 CST 2013 root@alex-laptop:/usr/obj/usr/src/sys/ALEX-LAPTOP
amd64
 
pkg which /usr/local/bin/gegl
  /usr/local/bin/gegl was installed by package gegl-0.1.8_6
  9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243826: Tue Dec  4 06:55:39 UTC 2012
  r...@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  i386
 
  I repeat with clang and gcc. I use portmaster and make but I got the same
  error.
 
 
 
  I just committed a fix for gegl doc build. I forgot to lift one small
  change from the gnome devel repo. Thanks for reporting!
 
  -Koop
 
  Hi Koop,
 
  many thanks for the update. It works fine for me.
 
  As mentioned in my second mail on this thread, one of the patches in the
  Makefile is not necessary anymore, because it was updated upstream:
 
  --- Makefile.orig   2013-01-27 12:50:15.0 +0100
  +++ Makefile2013-01-27 13:25:30.0 +0100
  @@ -203,8 +203,6 @@
   .endif
  ${REINPLACE_CMD} -e 's|\(lua\)\(5\.1\)|\1-\2|g ; s|x86_64|amd64|g' \
  ${WRKSRC}/configure
  -   ${REINPLACE_CMD} -e 's|/usr/bin/ruby|/usr/bin/env ruby|' \
  -   ${WRKSRC}/tools/gobj2dot.rb
 
   post-build:
   .if ${PORT_OPTIONS:MDOCS}
 
 
  Regards,
  Rainer
 


___
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: Issue about adapting japanese/ruby-mecab to new options framework

2013-01-27 Thread Jason Helfman
On Sun, Jan 27, 2013 at 9:15 AM, Yasuhiro KIMURA y...@utahime.org wrote:

 Hello all,

 I adapted japanese/ruby-mecab to new options framework and sent
 following PR.

 http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/175258

 But after submitting I found a issue that options setting dialog is
 always displayed even if options save file is already created.

 According to the output of 'make' with '-d' option, following things
 seem to happen:

 1. PKGNAMEPREFIX variable is assigned to ja- and that causes
OPTIONSFILE variable to be expanded to /var/db/ports/ja-mecab/options.
 2. /var/db/ports/ja-mecab/options is included as options save file.
 3. PKGNAMEPREFIX is re-assigned to ja-ruby19- and that causes
OPTIONFILE to be expanded to /var/db/ports/ja-ruby-mecab/options.
 4. Options dialog is invoked and result is saved to
 /var/db/ports/ja-ruby-mecab/options.
 5. Since input and output files of options setting are different,
dialog is displayed every time 'make' is invoked.

 And below is detail:

 01. RUBY_DEFAULT_VER is assigned to 1.9 in /etc/make.conf of my
 machine.
 02. PORTNAME is assigned to mecab in japanese/ruby-mecab/Makefile.
 03. PKGNAMEPREFIX is assigned to ja- in japanese/Makefile.inc.
 04. PORT_DBDIR is assigned to /var/db/ports in Mk/bsd.port.mk.
 05. UNIQUENAME is assigned to ${PKGNAMEPREFIX}${PORTNAME}
 in Mk/bsd.port.mk.
 06. OPTIONSFILE is assigned to ${PORT_DBDIR}/${UNIQUENAME}/options
 in Mk/bsd.options.mk.
 07. Check is done if ${OPTIONSFILES} exists in Mk/bsd.options.mk.
 At this point ${OPTIONSFILES} is expanded to
 /var/db/ports/ja-mecab/options.
 So file named /var/db/ports/ja-mecab/options is checked.
 Since japanese/ruby-mecab is depend on japanese/mecab, this file
 usually exists. So this file is included as saved options file of
 japanese/ruby-mecab.
 08. PKGNAMEPREFIX is assigned with expansion (':=' is used) to
 ${PKGNAMEPREFIX}${RUBY_PKGNAMEPREFIX} in
 japanese/ruby-mecab/Makefile.
 09. RUBY_RELVERSION is assigned to 1.9.3 in Mk/bsd.ruby.mk.
 10. RUBY_PATCHLEVEL is assigned to 327 in Mk/bsd.ruby.mk.
 11. RUBY_VERSION is assigned to ${RUBY_RELVERSION}.${RUBY_PATCHLEVEL}
 in Mk/bsd.ruby.mk.
 12. RUBY_VER is assigned to
 ${RUBY_VERSION:C/([[:digit:]]+\.[[:digit:]]+).*/\1/}
 in Mk/bsd.ruby.mk.
 13. RUBY_SUFFIX is assigned to ${RUBY_VER:S/.//} in Mk/bsd.ruby.mk.
 14. RUBY_PKGNAMEPREFIX is assigned to ruby${RUBY_SUFFIX}- in Mk/
 bsd.ruby.mk.
 15. /usr/bin/dialog is invoked to show options setting dialog.
 16. Result of step 15 is saved to ${OPTIONSFILE}. At this point
 ${OPTIONSFILE} is expanded to /var/db/ports/ja-ruby19-mecab/options.
 So file named /var/db/ports/ja-ruby19-mecab/options is created
 and options setting is saved to it.
 17. Now options settings are saved to /var/db/ports/ja-ruby19-mecab/options
 at step 16, and it is different from the file included at step 07.
 So it cause step 01 to 16 to be repeated every time 'make' is invoked.

 And now, how should I fix this issue? Is it possible to fix it by only
 patching japanese/ruby-mecab/Makefile? Or are some changes of Mk/bsd.*.mk
 needed?

 Any suggestion is welcome.

 Best regards.

 ---
 Yasuhiro KIMURA


You could look at setting OPTIONSFILE in the ports Makefile, itself.
For instance, this is set in net/rubygem-net-ssh. Although this may not be
the exact entry, this is an example you can work with to get it to work as
it should.

OPTIONSFILE?=   ${PORT_DBDIR}/rubygem-${PORTNAME}/options

-jgh
___
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: Issue about adapting japanese/ruby-mecab to new options framework

2013-01-27 Thread Scot Hetzel
On Sun, Jan 27, 2013 at 11:15 AM, Yasuhiro KIMURA y...@utahime.org wrote:
 Hello all,

 I adapted japanese/ruby-mecab to new options framework and sent
 following PR.

 http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/175258

 But after submitting I found a issue that options setting dialog is
 always displayed even if options save file is already created.

 According to the output of 'make' with '-d' option, following things
 seem to happen:

 1. PKGNAMEPREFIX variable is assigned to ja- and that causes
OPTIONSFILE variable to be expanded to /var/db/ports/ja-mecab/options.
 2. /var/db/ports/ja-mecab/options is included as options save file.
 3. PKGNAMEPREFIX is re-assigned to ja-ruby19- and that causes
OPTIONFILE to be expanded to /var/db/ports/ja-ruby-mecab/options.
 4. Options dialog is invoked and result is saved to 
 /var/db/ports/ja-ruby-mecab/options.
 5. Since input and output files of options setting are different,
dialog is displayed every time 'make' is invoked.

 And below is detail:

 01. RUBY_DEFAULT_VER is assigned to 1.9 in /etc/make.conf of my
 machine.
 02. PORTNAME is assigned to mecab in japanese/ruby-mecab/Makefile.
 03. PKGNAMEPREFIX is assigned to ja- in japanese/Makefile.inc.
 04. PORT_DBDIR is assigned to /var/db/ports in Mk/bsd.port.mk.
 05. UNIQUENAME is assigned to ${PKGNAMEPREFIX}${PORTNAME}
 in Mk/bsd.port.mk.
 06. OPTIONSFILE is assigned to ${PORT_DBDIR}/${UNIQUENAME}/options
 in Mk/bsd.options.mk.
 07. Check is done if ${OPTIONSFILES} exists in Mk/bsd.options.mk.
 At this point ${OPTIONSFILES} is expanded to 
 /var/db/ports/ja-mecab/options.
 So file named /var/db/ports/ja-mecab/options is checked.
 Since japanese/ruby-mecab is depend on japanese/mecab, this file
 usually exists. So this file is included as saved options file of
 japanese/ruby-mecab.
 08. PKGNAMEPREFIX is assigned with expansion (':=' is used) to
 ${PKGNAMEPREFIX}${RUBY_PKGNAMEPREFIX} in japanese/ruby-mecab/Makefile.
 09. RUBY_RELVERSION is assigned to 1.9.3 in Mk/bsd.ruby.mk.
 10. RUBY_PATCHLEVEL is assigned to 327 in Mk/bsd.ruby.mk.
 11. RUBY_VERSION is assigned to ${RUBY_RELVERSION}.${RUBY_PATCHLEVEL}
 in Mk/bsd.ruby.mk.
 12. RUBY_VER is assigned to 
 ${RUBY_VERSION:C/([[:digit:]]+\.[[:digit:]]+).*/\1/}
 in Mk/bsd.ruby.mk.
 13. RUBY_SUFFIX is assigned to ${RUBY_VER:S/.//} in Mk/bsd.ruby.mk.
 14. RUBY_PKGNAMEPREFIX is assigned to ruby${RUBY_SUFFIX}- in Mk/bsd.ruby.mk.
 15. /usr/bin/dialog is invoked to show options setting dialog.
 16. Result of step 15 is saved to ${OPTIONSFILE}. At this point
 ${OPTIONSFILE} is expanded to /var/db/ports/ja-ruby19-mecab/options.
 So file named /var/db/ports/ja-ruby19-mecab/options is created
 and options setting is saved to it.
 17. Now options settings are saved to /var/db/ports/ja-ruby19-mecab/options
 at step 16, and it is different from the file included at step 07.
 So it cause step 01 to 16 to be repeated every time 'make' is invoked.

 And now, how should I fix this issue? Is it possible to fix it by only
 patching japanese/ruby-mecab/Makefile? Or are some changes of Mk/bsd.*.mk
 needed?

 Any suggestion is welcome.


You could add OPTIONSFILE to japanese/ruby-mecab/Makefile as:

OPTIONSFILE=${PORT_DBDIR}/ruby-mecab/options

This way it will always find it's own options file.

Scot
-- 
DISCLAIMER:

No electrons were maimed while sending this message. Only slightly bruised.
___
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


[PATCH] unbreak kdegraphics3 build when clang set as base compiler

2013-01-27 Thread Oliver Pinter
Hi all!

This patches required, when set clang as default compiler on FreeBSD:

patch-kmrml_kmrml_mrml__elements.h
patch-ksvg_impl_libs_libtext2path_src_Converter.cpp
patch-kviewshell_documentWidget.cpp
patch-kviewshell_plugins_djvu_libdjvu_GContainer.h

from: 
http://ftp.fr.netbsd.org/pub/NetBSD/NetBSD-current/pkgsrc/graphics/kdegraphics3/patches/

after fetching this patches, the kdegraphics3 builded.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


Re: [PATCH] unbreak kdegraphics3 build when clang set as base compiler

2013-01-27 Thread Oliver Pinter
http://www.freebsd.org/cgi/query-pr.cgi?pr=175634

On 1/27/13, Oliver Pinter oliver.p...@gmail.com wrote:
 Hi all!

 This patches required, when set clang as default compiler on FreeBSD:

 patch-kmrml_kmrml_mrml__elements.h
 patch-ksvg_impl_libs_libtext2path_src_Converter.cpp
 patch-kviewshell_documentWidget.cpp
 patch-kviewshell_plugins_djvu_libdjvu_GContainer.h

 from:
 http://ftp.fr.netbsd.org/pub/NetBSD/NetBSD-current/pkgsrc/graphics/kdegraphics3/patches/

 after fetching this patches, the kdegraphics3 builded.

___
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: Cronjob Cvsup - What?

2013-01-27 Thread Jeffrey Bouquet


..
Thomas Mueller wrote: I've always used portsnap fetch update after the 
initial portsnap fetch and portsnap extract.  What would be the adverse 
side effect of using svn instead?In general it's best to avoid mixing update 
tools unless you fullyunderstand all the corner cases and know it's safe. The 
most significant  problem is they can lose track of what filesneed to be 
deleted, which can lead to obsolete patch files being leftin the tree. One of 
the functions of portsnap extract is to eliminateextra files in port 
directories to avoid this problem.
.
Svn has a a few drawbacks vs csup (space required, longer backups without
- .svn   # or equiv 
in an exclude file, maybe others...)

however it may be more advantageous if one understands its use cases and the
consequences of each one.  Someone would someday maybe be resourceful
enough to write one up and post it somewhere in a flowchart...
(the revert up svnweb 
script -a a.log svn up /usr/ports 
(the intitial creation of it with the long CLI in the forum...)
# port # svn revert Makefile
# port # svn -R revert .
# svn up /usr/ports/multimedia/mplayerxp
 etc etc... 
As a newbie, those are all I know so far .  And one can use workarounds if
a disk is short on space, 
mount -t ufs -o union(fs) /dev/da0 /usr 
and even
svn -up /usr/ports   # after it mounts correctly
... to update the thumbdrive before port updates on the low-disk-space machine.
(that is the procedure as I recollect it anyway.  Something could be slightly
different.)
(if /ports in on the thumbdrive)  (that syntax is probably correct, but I am at 
another CPU and cannot check it right away.)



J. Bouquet
(Sorry for the post formatting and any typos...)
___
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: Cronjob Cvsup - What?

2013-01-27 Thread Joseph A. Nagy, Jr

On 01/27/13 07:22, Thomas Mueller wrote:
snip

Unless you have a specific reason why portsnap doesn't fit your use
case, it's definitely the way to go for just keeping a ports tree
updated regularly.


I've always used portsnap fetch update after the initial portsnap fetch
and portsnap extract.  What would be the adverse side effect of using svn
instead?

Tom

snip

I've used svn pretty much since day one as it only updates what has been 
updated, portsnap updates the whole tree regardless. They both take 
approximately the same time but most of svn's time is comparing local 
and remote working directories afaik. svn usually finishes within 10 
minutes or less.


Some people don't like having svn's working directory on their system 
(not sure why, but the world goes round just the same), but other than 
that I'd say there has been no adverse affects aside having the latest 
ports for your FreeBSD machine.

--
Yours in Christ,

Joseph A Nagy Jr
Whoever loves instruction loves knowledge, But he who hates correction
is stupid. -- Proverbs 12:1
Emails are not formal business letters, whatever businesses may want.
Original content CopyFree (F) under the OWL http://owl.apotheon.org
___
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: postfix-current broken on amd64 platform

2013-01-27 Thread Sahil Tandon
On Mon, 2012-11-26 at 07:05:59 +1100, Peter Jeremy wrote:
 ...
 [postfix dies with a Protocol not supported when built in a jail
  without an IPv6 address]
 ... 
 I've just bumped into this exact situation with mail/postfix28 and
 suspect that earlier postfix ports have the same issue.  The above fix
 works on postfix28 and I would request that it be added to that port's
 patch list.  Since this is a workaround for a FreeBSD-specific issue,
 I don't believe it's reasonable to expect Wietse to patch old postfix
 variants to work around it.

OK, mail/postfix2[6-8] are now patched.  Let me know if you have any
problems.

-- 
Sahil Tandon


pgpJmhcIpv61k.pgp
Description: PGP signature