Re: graphics/gegl 0.1.8 does not build
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 > > >> > > >> > > >> > > >> 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
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
>
>
>
> 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?
"W. D." 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 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?
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
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 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
>>
>>
>>
>> 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"
devel/gobject-introspection failure on ARM
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. It also didn't get rid of the huge number of "cast increases required alignment of target type" warnings. 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? -- George Mitchell typescript.xz Description: Binary data ___ 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"
devel/gobject-introspection failure on ARM
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. It also didn't get rid of the huge number of "cast increases required alignment of target type" warnings. 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? -- George Mitchell typescript.xz Description: Binary data ___ 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
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
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
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 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 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
>>>
>>>
>>>
>>> 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
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
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
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 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
> >>
> >>
> >>
> >> 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
On Sun, Jan 27, 2013 at 9:15 AM, Yasuhiro KIMURA 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
On Sun, Jan 27, 2013 at 11:15 AM, Yasuhiro KIMURA 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
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
http://www.freebsd.org/cgi/query-pr.cgi?pr=175634 On 1/27/13, Oliver Pinter 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?
.. >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?
On 01/27/13 07:22, Thomas Mueller wrote: 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 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
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
