Re: HEADS UP: xorg 7.2 ready for testing

[Thierry Thomas]

Le Sam 12 mai 07 à 16:46:11 +0200, Thierry Thomas <[EMAIL PROTECTED]>
 écrivait :

> The full log - an extract on my typescript) is available at
> .
> 
> No patch ATM, because the upgrade is still in progress...

Actually I have no patches to suggest: tix has been successfully
upgraded during the second pass.

Once tix has been upgraded, cad/opencascade failed: dps is no more
pulled automatically, and it must be added as a dependence:

--- cad/opencascade.orig/Makefile   Thu May 10 22:17:10 2007
+++ cad/opencascade/MakefileThu May 17 09:54:30 2007
@@ -7,7 +7,7 @@
 
 PORTNAME=  opencascade
 PORTVERSION=   6.2
-PORTREVISION=  1
+PORTREVISION=  1
 CATEGORIES=cad science
 MASTER_SITES=  ${MASTER_SITE_LOCAL}
 MASTER_SITE_SUBDIR=thierry
@@ -22,7 +22,8 @@
 LIB_DEPENDS=   itcl.${ITCL_VER}:${PORTSDIR}/lang/itcl  \
itk.${ITK_VER}:${PORTSDIR}/x11-toolkits/itk \
tix${TIX_VER}:${PORTSDIR}/x11-toolkits/tix  \
-   fltk.1:${PORTSDIR}/x11-toolkits/fltk
+   fltk.1:${PORTSDIR}/x11-toolkits/fltk\
+   dps.0:${PORTSDIR}/x11/dgs
 
 USE_BZIP2= yes
 USE_BISON= yes

Regards,
-- 
Th. Thomas.


pgplpIq2GMqcG.pgp
Description: PGP signature

Re: HEADS UP: xorg 7.2 ready for testing

[Gary Jennejohn]

I've installed everything by hand because I wanted to start with a
clean slate.

I've noticed the following problems:

1) xpdf sort of works but it's not possible to enter text into any
   text box. That means that e.g. searching in a PDF cannot be done.
   Luckily, acroread still works.
2) acidrip dies in perl. This is the backtrace from gdb:

error message:
 Pango-WARNING **: shape engine failure, expect ugly output. the
offending font is 'Bitstream Vera Sans Not-Rotated 0'
at /usr/local/bin/acidrip line 60.

(gdb) bt
#0  0x2929f70a in _cairo_ft_unscaled_font_lock_face ()
   from /usr/local/lib/libcairo.so.2
#1  0x292a1aa0 in _cairo_ft_ucs4_to_index ()
#from /usr/local/lib/libcairo.so.2 2  0x29293bd8 in
#_cairo_scaled_font_text_to_glyphs ()
   from /usr/local/lib/libcairo.so.2
#3  0x29293f50 in cairo_scaled_font_text_extents ()
   from /usr/local/lib/libcairo.so.2
#4  0x29a2b96d in pango_cairo_font_get_type ()
   from /usr/local/lib/libpangocairo-1.0.so.0
#5  0x29a2be03 in pango_cairo_font_get_type ()
   from /usr/local/lib/libpangocairo-1.0.so.0
#6  0x29a2e30f in pango_cairo_fc_font_get_type ()
   from /usr/local/lib/libpangocairo-1.0.so.0
#7  0x29a94b21 in pango_font_get_glyph_extents ()
   from /usr/local/lib/libpango-1.0.so.0
#8  0x29a9b7fa in pango_engine_shape_get_type ()
   from /usr/local/lib/libpango-1.0.so.0
#9  0x29a9b6a9 in pango_engine_shape_get_type ()
   from /usr/local/lib/libpango-1.0.so.0
#10 0x29aaab0d in pango_shape () from /usr/local/lib/libpango-1.0.so.0
#11 0x29a9ea13 in pango_layout_iter_get_line_yrange ()
   from /usr/local/lib/libpango-1.0.so.0
#12 0x29a9f218 in pango_layout_iter_get_line_yrange ()
   from /usr/local/lib/libpango-1.0.so.0
#13 0x29aa104b in pango_layout_line_get_pixel_extents ()
   from /usr/local/lib/libpango-1.0.so.0
#14 0x29aa19f6 in pango_layout_line_get_pixel_extents ()
   from /usr/local/lib/libpango-1.0.so.0
#15 0x2982aa55 in gtk_text_layout_get_line_display ()
   from /usr/local/lib/libgtk-x11-2.0.so.0
#16 0x2982b586 in gtk_text_layout_set_cursor_direction ()
   from /usr/local/lib/libgtk-x11-2.0.so.0
#17 0x29828b15 in gtk_text_layout_wrap ()
   from /usr/local/lib/libgtk-x11-2.0.so.0
#18 0x29812ba1 in gtk_text_mark_set_visible ()
   from /usr/local/lib/libgtk-x11-2.0.so.0
#19 0x2982957e in gtk_text_layout_validate_yrange ()
   from /usr/local/lib/libgtk-x11-2.0.so.0
#20 0x29839be5 in gtk_text_view_new_with_buffer ()
   from /usr/local/lib/libgtk-x11-2.0.so.0
#21 0x2983a085 in gtk_text_view_scroll_to_iter ()
   from /usr/local/lib/libgtk-x11-2.0.so.0
#22 0x2983a0b1 in gtk_text_view_scroll_to_iter ()
   from /usr/local/lib/libgtk-x11-2.0.so.0
#23 0x28460c54 in g_child_watch_add ()
#from /usr/local/lib/libglib-2.0.so.0 24 0x2845ddcd in
#g_main_context_dispatch ()
   from /usr/local/lib/libglib-2.0.so.0
#25 0x2845f67d in g_main_context_acquire ()
   from /usr/local/lib/libglib-2.0.so.0
#26 0x2845f8d8 in g_main_loop_run ()
#from /usr/local/lib/libglib-2.0.so.0 27 0x297903df in gtk_main ()
#from /usr/local/lib/libgtk-x11-2.0.so.0 28 0x2955640c in XS_Gtk2_main
#()
   from /usr/local/lib/perl5/site_perl/5.8.8/mach/auto/Gtk2/Gtk2.so
#29 0x280f53a4 in Perl_pp_entersub ()
   from /usr/local/lib/perl5/5.8.8/mach/CORE/libperl.so
#30 0x280ee389 in Perl_runops_standard ()
   from /usr/local/lib/perl5/5.8.8/mach/CORE/libperl.so
#31 0x2809dd62 in perl_run ()
   from /usr/local/lib/perl5/5.8.8/mach/CORE/libperl.so
#32 0x0804908a in main ()

I haven't debugged it further.

-- 
Gary Jennejohn / garyjATjennejohnDOTorg gjATfreebsdDOTorg
garyjATdenxDOTde
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Time to abandon recursive pulling of dependencies?

[Alexander Leidinger]

Quoting Robert Noland <[EMAIL PROTECTED]> (Wed, 16 May 2007 18:14:01 -0400):

> On Wed, 2007-05-16 at 16:01 -0500, Stephen Montgomery-Smith wrote:
> > Ok chaps, I think I have it.
> > 
> > This involves no recursive calls of make.  Furthermore the
> > dependencies 
> > it creates are the real dependencies on your system, not what ports 
> > thinks it should be, because it gets all the information from 
> > /var/db/pkg.  On my system it takes a second or two to register a port
> > - 
> > it takes about the same amount of time whether it has few
> > dependencies 
> > or many, except when there are zero dependencies, when it takes no
> > time 
> > at all.
> > 
> > If I get some positive feedback on this one, I'll submit a PR.  You
> > can 
> > try it out by typing "make actual-package-depends" as opposed to
> > "make 
> > package-depends."
> 
> Ok, I'm really trying to make sense of these numbers...
> 
> For gnome2-2.18.1_1 on my -current system...
> 
> rnoland-ibm% make package-depends|wc -l
>  362
> rnoland-ibm% make actual-package-depends|wc -l
>  294
> 
> Registered the old way:
> rnoland-ibm% grep @pkgdep /var/db/pkg/gnome2-2.18.1_1/+CONTENTS|wc -l
>  176
> 
> and the new way:
> rnoland-ibm% grep @pkgdep /var/db/pkg/gnome2-2.18.1_1/+CONTENTS|wc -l
>  294
> 
> I put together an awk script yesterday which was very close to the one
> Alexander posted and got 295... and the diff of the output of my awk and
> actual-package-depends is much more than a single line, which I also
> can't yet explain.

I had a look at it. It is missing those dependencies which are not
installed. Depending on when this target is used, this is ok or not.

Some benchmark:
---snip---
[original]
make package-depends  80.18s user 53.92s system 73% cpu 3:01.53 total
make package-depends  80.70s user 52.94s system 87% cpu 2:32.25 total
make package-depends > /tmp/list1  79.58s user 54.28s system 87% cpu 2:32.59 
total

[no AWK]
make actual-package-depends  4.76s user 7.46s system 57% cpu 21.082 total
make actual-package-depends  4.87s user 7.34s system 67% cpu 18.019 total
make actual-package-depends > /tmp/list2  4.58s user 7.60s system 87% cpu 
13.942 total

[AWK]
make actual-package-depends  3.15s user 7.45s system 85% cpu 12.420 total
make actual-package-depends  3.13s user 7.49s system 84% cpu 12.524 total
make actual-package-depends  3.11s user 7.49s system 88% cpu 11.995 total
make actual-package-depends >| /tmp/list3  3.16s user 7.42s system 89% cpu 
11.83 0 total

[AWK + partly missing (only direct dependencies)]
make actual-package-depends > /tmp/list4  4.60s user 7.63s system 90% cpu 
13.479 total
make actual-package-depends  4.68s user 7.56s system 87% cpu 13.985 total
make actual-package-depends  4.58s user 7.64s system 89% cpu 13.594 total

...sorting list1 & list2 & list3 & list4...

% wc -l /tmp/list*s
 320 /tmp/list1s
 308 /tmp/list2s
 308 /tmp/list3s
 310 /tmp/list4s
1246 total
---snip---

Note, there was trackerd running in the background while testing...

For the difference between the redirected output case: I think the
gnome terminal needs a lot of time to print all the lines. But still,
the awk version takes around 3/4 of the time (interesting is the user
time, not the total time). Stephen's version can be speed up some
fractions by inserting a break into the first while-loop.

Attached is my awk-version and the awk version which also includes the
direct dependencies.

Bye,
Alexander.

-- 
The only new TV show worth watching will be cancelled.
http://www.Leidinger.net  Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org  : PGP ID = 72077137
--- /usr/ports/Mk/bsd.port.mk	Sat Apr  7 14:51:47 2007
+++ /space/jails/basejail/usr/ports/Mk/bsd.port.mk	Thu May 17 11:19:03 2007
@@ -2321,7 +2321,7 @@
 DISABLE_CONFLICTS=	YES
 .endif
 .if !defined(PKG_ARGS)
-PKG_ARGS=		-v -c -${COMMENT:Q} -d ${DESCR} -f ${TMPPLIST} -p ${PREFIX} -P "`cd ${.CURDIR} && ${MAKE} package-depends | ${GREP} -v -E ${PKG_IGNORE_DEPENDS} | ${SORT} -u`" ${EXTRA_PKG_ARGS} $${_LATE_PKG_ARGS}
+PKG_ARGS=		-v -c -${COMMENT:Q} -d ${DESCR} -f ${TMPPLIST} -p ${PREFIX} -P "`cd ${.CURDIR} && ${MAKE} actual-package-depends | ${GREP} -v -E ${PKG_IGNORE_DEPENDS} | ${SORT} -u`" ${EXTRA_PKG_ARGS} $${_LATE_PKG_ARGS}
 .if !defined(NO_MTREE)
 PKG_ARGS+=		-m ${MTREE_FILE}
 .endif
@@ -5145,15 +5145,47 @@
 shift 3; \
 			done; \
 			checked="$$dir $$childdir $$checked"; \
-		else \\
+		else \
 			${ECHO_MSG} "${PKGNAME}: \"$$dir\" non-existent -- dependency list incomplete" >&2; \
 		fi; \
 	done
 
+ACTUAL-PACKAGE-DEPENDS?= \
+	if [ "${_LIB_RUN_DEPENDS}" != "  " ]; then \
+		origins=$$(for pkgname in ${PKG_DBDIR}/*; do \
+			if [ -e $$pkgname/+CONTENTS ]; then \
+basename $$pkgname; \
+${SED} -n -e "s/@comment ORIGIN://p" $$pkgname/+CONTENTS; \
+			fi; \
+		done); \
+		for dir in ${_LIB_RUN_DEPENDS:C,[^:]*:([^:]*):?.*,\1,}; do \
+			dir=`dirname $$dir | xargs basename`/`basename $$dir`;

Re: HEADS UP: xorg 7.2 ready for testing

[Peter Jeremy]

I can report success on three systems.  A further system is still
upgrading.

In all cases, I had to execute multiple 'portupgrade -a' commands (and
a few 'pkgdb -F' commands) to get it to work.  One system mad a couple
of problems with portupgrade apparently forgetting to re-install
packages after uninstalling them - which took a bit of cleaning up -
and losing pieces of packages ('pkg_info -g' reported files missing).

Overall, I'd rate it as a success, though I don't think it rates as
totally idiot-proof.

Thanks to all for your efforts in getting Xorg 7.2 into the tree.

-- 
Peter Jeremy


pgpJtCUMC94I5.pgp
Description: PGP signature

Re: HEADS UP: xorg 7.2 ready for testing

[Peter Jeremy]

On 2007-May-17 11:02:31 +0200, Gary Jennejohn <[EMAIL PROTECTED]> wrote:
>1) xpdf sort of works but it's not possible to enter text into any
>   text box. That means that e.g. searching in a PDF cannot be done.

FWIW, xpdf works for me after an upgrade.

-- 
Peter Jeremy


pgpNRhBmRuwzH.pgp
Description: PGP signature

Re: Time to abandon recursive pulling of dependencies?

[Alexander Leidinger]

Quoting Alexander Leidinger <[EMAIL PROTECTED]> (Thu, 17 May 2007 11:44:36 
+0200):

> For the difference between the redirected output case: I think the
> gnome terminal needs a lot of time to print all the lines. But still,
> the awk version takes around 3/4 of the time (interesting is the user
> time, not the total time). Stephen's version can be speed up some
> fractions by inserting a break into the first while-loop.
> 
> Attached is my awk-version and the awk version which also includes the
> direct dependencies.

After a little review: For the awk version the embedded "sort -u" can
be removed (it is done in the PKG_ARGS part), for Stephen's version it
is necessary to cut down processing time in the following part.

It seems the processing of the not installed dependencies has not to be
done, as this target is only used in the PKG_ARGS part and is used in a
way which evaluates the result at the time of the invocation of the
pkg_create program (when the port is installed and all dependencies
should reflect what is on disk).

Bye,
Alexander.

-- 
A work project expands to fill the space available.
http://www.Leidinger.net  Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org  : PGP ID = 72077137
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: HEADS UP: xorg 7.2 ready for testing

[Angelo Turetta]

Peter Jeremy wrote:

One system had a couple
of problems with portupgrade apparently forgetting to re-install
packages after uninstalling them - which took a bit of cleaning up -
and losing pieces of packages ('pkg_info -g' reported files missing).


This is an annoying known issue

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

But I've not been able to debug it: of course, every time I try with a 
controlled set of portupgrade invocations, it never fails !!


Angelo.

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: HEADS UP: xorg 7.2 ready for testing

[Gary Jennejohn]

On Thu, 17 May 2007 21:17:27 +1000
Peter Jeremy <[EMAIL PROTECTED]> wrote:

> On 2007-May-17 11:02:31 +0200, Gary Jennejohn <[EMAIL PROTECTED]>
> wrote:
> >1) xpdf sort of works but it's not possible to enter text into any
> >   text box. That means that e.g. searching in a PDF cannot be done.
> 
> FWIW, xpdf works for me after an upgrade.
> 

Hmm. I wonder what could be different? As stated, I started out with
an empty /usr/local and /var/db/pkg. Maybe I missed a new tarball?
-- 
Gary Jennejohn / garyjATjennejohnDOTorg gjATfreebsdDOTorg
garyjATdenxDOTde
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Time to abandon recursive pulling of dependencies?

[Stephen Montgomery-Smith]

Alexander Leidinger wrote:

Quoting Robert Noland <[EMAIL PROTECTED]> (Wed, 16 May 2007 18:14:01 -0400):


On Wed, 2007-05-16 at 16:01 -0500, Stephen Montgomery-Smith wrote:

Ok chaps, I think I have it.

This involves no recursive calls of make.  Furthermore the
dependencies 
it creates are the real dependencies on your system, not what ports 
thinks it should be, because it gets all the information from 
/var/db/pkg.  On my system it takes a second or two to register a port
- 
it takes about the same amount of time whether it has few
dependencies 
or many, except when there are zero dependencies, when it takes no
time 
at all.


If I get some positive feedback on this one, I'll submit a PR.  You
can 
try it out by typing "make actual-package-depends" as opposed to
"make 
package-depends."

Ok, I'm really trying to make sense of these numbers...

For gnome2-2.18.1_1 on my -current system...

rnoland-ibm% make package-depends|wc -l
 362
rnoland-ibm% make actual-package-depends|wc -l
 294

Registered the old way:
rnoland-ibm% grep @pkgdep /var/db/pkg/gnome2-2.18.1_1/+CONTENTS|wc -l
 176

and the new way:
rnoland-ibm% grep @pkgdep /var/db/pkg/gnome2-2.18.1_1/+CONTENTS|wc -l
 294

I put together an awk script yesterday which was very close to the one
Alexander posted and got 295... and the diff of the output of my awk and
actual-package-depends is much more than a single line, which I also
can't yet explain.


I had a look at it. It is missing those dependencies which are not
installed. Depending on when this target is used, this is ok or not.

Some benchmark:
---snip---
[original]
make package-depends  80.18s user 53.92s system 73% cpu 3:01.53 total
make package-depends  80.70s user 52.94s system 87% cpu 2:32.25 total
make package-depends > /tmp/list1  79.58s user 54.28s system 87% cpu 2:32.59 
total

[no AWK]
make actual-package-depends  4.76s user 7.46s system 57% cpu 21.082 total
make actual-package-depends  4.87s user 7.34s system 67% cpu 18.019 total
make actual-package-depends > /tmp/list2  4.58s user 7.60s system 87% cpu 
13.942 total

[AWK]
make actual-package-depends  3.15s user 7.45s system 85% cpu 12.420 total
make actual-package-depends  3.13s user 7.49s system 84% cpu 12.524 total
make actual-package-depends  3.11s user 7.49s system 88% cpu 11.995 total
make actual-package-depends >| /tmp/list3  3.16s user 7.42s system 89% cpu 
11.83 0 total

[AWK + partly missing (only direct dependencies)]
make actual-package-depends > /tmp/list4  4.60s user 7.63s system 90% cpu 
13.479 total
make actual-package-depends  4.68s user 7.56s system 87% cpu 13.985 total
make actual-package-depends  4.58s user 7.64s system 89% cpu 13.594 total

...sorting list1 & list2 & list3 & list4...

% wc -l /tmp/list*s
 320 /tmp/list1s
 308 /tmp/list2s
 308 /tmp/list3s
 310 /tmp/list4s
1246 total
---snip---

Note, there was trackerd running in the background while testing...

For the difference between the redirected output case: I think the
gnome terminal needs a lot of time to print all the lines. But still,
the awk version takes around 3/4 of the time (interesting is the user
time, not the total time). Stephen's version can be speed up some
fractions by inserting a break into the first while-loop.

Attached is my awk-version and the awk version which also includes the
direct dependencies.

Bye,
Alexander.




I think I like Alexander's awk version better than mine.  Alexander - 
can I ask you to submit the PR using send-pr?


Stephen
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Time to abandon recursive pulling of dependencies?

[Stephen Montgomery-Smith]

Alexander Leidinger wrote:

Quoting Alexander Leidinger <[EMAIL PROTECTED]> (Thu, 17 May 2007 11:44:36 
+0200):


For the difference between the redirected output case: I think the
gnome terminal needs a lot of time to print all the lines. But still,
the awk version takes around 3/4 of the time (interesting is the user
time, not the total time). Stephen's version can be speed up some
fractions by inserting a break into the first while-loop.

Attached is my awk-version and the awk version which also includes the
direct dependencies.


After a little review: For the awk version the embedded "sort -u" can
be removed (it is done in the PKG_ARGS part), for Stephen's version it
is necessary to cut down processing time in the following part.


Agreed


It seems the processing of the not installed dependencies has not to be
done, as this target is only used in the PKG_ARGS part and is used in a
way which evaluates the result at the time of the invocation of the
pkg_create program (when the port is installed and all dependencies
should reflect what is on disk).



Yes, definitely.

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

make -j patch

[Benjamin Lutz]

Hello,

I have another version of the patch that allows multiple make jobs for a 
port build, please tell me what you think:

http://www.maxlor.com/freebsd/files/make_jobs.diff

I've abandoned the name PARALLEL_BUILD in favor of MAKE_JOBS since the 
former intuitively hints at several port builds running at once, 
instead of one single port build being built with several make 
processes. I've shamelessly taken the MAKE_JOBS name from pav, 
thanks :)

Here's an explanation of the variables used:

ENABLE_MAKE_JOBS: The master switch that enables or disables the whole
thing. The user is supposed to set it in his /etc/make.conf . If
this variable isn't set, the ports are supposed to build like they
always did.

ALLOW_MAKE_JOBS: Goes into a port's makefile. The port maintainer
indicates with it that the port can be built with multiple make
jobs.

MAKE_JOBS_WHITELIST: Allows the user to override ALLOW_MAKE_JOBS. Any
port whose UNIQUENAME is listed in MAKE_JOBS_WHITELIST will have
its ALLOW_MAKE_JOBS defined. The user would put something like this
in his /etc/make.conf: MAKE_JOBS_WHITELIST=kdebase gtk20

The following are new "internal" variables I introduced:

CPUS: The number of CPUs in the system.

MAKE_JOBS_NJOBS: The number of make jobs that will be used. Currently,
this is ${CPUS} + 1.

MAKE_JOBS_ARGS: The argument that is passed to make.

BUILD_FAILMSG: A message that is printed if the do-build stage fails. 
Note that this variable can be used by any part of the ports system,
not just the MAKE_JOBS part. To use it, write code like

  BUILD_FAILMSG+= "===> Foo"

Each message added to BUILD_FAILMSG like this will be printed at the
end of the do-build stage (if it fails), one paragraph per message.

The MAKE_JOBS code currently uses this to inform the user that he
needn't bother to send bug reports if MAKE_JOBS_WHITELIST is used.

Now, please let's hear what you think! I would like for this patch (or a 
modified version of it) to be added to FreeBSD. If the powers that be 
agree to that, I will then also write patches for the porters handbook 
and portlint.

Cheers
Benjamin


pgpZG8DvGqQAn.pgp
Description: PGP signature

Re: Time to abandon recursive pulling of dependencies?

[Alexander Leidinger]

Quoting Stephen Montgomery-Smith <[EMAIL PROTECTED]> (Thu, 17 May 2007 08:14:43 
-0500):

> Alexander Leidinger wrote:
> > Quoting Alexander Leidinger <[EMAIL PROTECTED]> (Thu, 17 May 2007 11:44:36 
> > +0200):
> > 
> >> For the difference between the redirected output case: I think the
> >> gnome terminal needs a lot of time to print all the lines. But still,
> >> the awk version takes around 3/4 of the time (interesting is the user
> >> time, not the total time). Stephen's version can be speed up some
> >> fractions by inserting a break into the first while-loop.
> >>
> >> Attached is my awk-version and the awk version which also includes the
> >> direct dependencies.
> > 
> > After a little review: For the awk version the embedded "sort -u" can
> > be removed (it is done in the PKG_ARGS part), for Stephen's version it
> > is necessary to cut down processing time in the following part.
> 
> Agreed

I played around a little bit with this, new version attached (simple
error handling in awk, doing just one awk for all files).

Comments please.

Stephen, if I don't get problem reports I will send-pr this as you
suggested.

Bye,
Alexander.

-- 
STANDARDS:
The principles we use to reject other people's code.
http://www.Leidinger.net  Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org  : PGP ID = 72077137
--- /usr/ports/Mk/bsd.port.mk	Sat Apr  7 14:51:47 2007
+++ /space/jails/basejail/usr/ports/Mk/bsd.port.mk	Thu May 17 17:46:25 2007
@@ -2321,7 +2321,7 @@
 DISABLE_CONFLICTS=	YES
 .endif
 .if !defined(PKG_ARGS)
-PKG_ARGS=		-v -c -${COMMENT:Q} -d ${DESCR} -f ${TMPPLIST} -p ${PREFIX} -P "`cd ${.CURDIR} && ${MAKE} package-depends | ${GREP} -v -E ${PKG_IGNORE_DEPENDS} | ${SORT} -u`" ${EXTRA_PKG_ARGS} $${_LATE_PKG_ARGS}
+PKG_ARGS=		-v -c -${COMMENT:Q} -d ${DESCR} -f ${TMPPLIST} -p ${PREFIX} -P "`cd ${.CURDIR} && ${MAKE} actual-package-depends | ${GREP} -v -E ${PKG_IGNORE_DEPENDS} | ${SORT} -u`" ${EXTRA_PKG_ARGS} $${_LATE_PKG_ARGS}
 .if !defined(NO_MTREE)
 PKG_ARGS+=		-m ${MTREE_FILE}
 .endif
@@ -5145,15 +5145,43 @@
 shift 3; \
 			done; \
 			checked="$$dir $$childdir $$checked"; \
-		else \\
+		else \
 			${ECHO_MSG} "${PKGNAME}: \"$$dir\" non-existent -- dependency list incomplete" >&2; \
 		fi; \
 	done
 
+ACTUAL-PACKAGE-DEPENDS?= \
+	if [ "${_LIB_RUN_DEPENDS}" != "  " ]; then \
+		origins=$$(for pkgname in ${PKG_DBDIR}/*; do \
+			if [ -e $$pkgname/+CONTENTS ]; then \
+basename $$pkgname; \
+${SED} -n -e "s/@comment ORIGIN://p" $$pkgname/+CONTENTS; \
+			fi; \
+		done); \
+		for dir in ${_LIB_RUN_DEPENDS:C,[^:]*:([^:]*):?.*,\1,}; do \
+			dir=`dirname $$dir | xargs basename`/`basename $$dir`; \
+			set -- $$origins; \
+			while [ $$\# != 0 ]; do \
+if [ $$dir = $$2 ]; then \
+	${ECHO_CMD} $$1:$$dir; \
+	if [ -e ${PKG_DBDIR}/$$1/+CONTENTS ]; then \
+		packagelist="$$packagelist ${PKG_DBDIR}/$$1/+CONTENTS"; \
+	fi; \
+	break; \
+fi; \
+shift 2; \
+			done; \
+		done; \
+		[ -z "$$packagelist" ] || ${AWK} -F '( |:)' 'BEGIN { pkgname="broken_contents" } /@pkgdep / { pkgname=$$2 } /@comment DEPORIGIN:/ { printf "%s:%s\n", pkgname, $$3; pkgname="broken_contents" }' $$packagelist; \
+	fi
+
 # Print out package names.
 
 package-depends:
 	@${PACKAGE-DEPENDS-LIST} | ${AWK} '{print $$1":"$$3}'
+
+actual-package-depends:
+	@${ACTUAL-PACKAGE-DEPENDS}
 
 # Build packages for port and dependencies
 
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: when are the ports being unfrozen ?

[Kris Kennaway]

On Wed, May 16, 2007 at 10:09:33AM +0100, Craig Butler wrote:
> Hi All
> 
> Any news when the ports are being unfrozen ?

Hopefully soon; there is at least one issue to be resolved (reports of
GL failures).  However I didn't see an X.org upgrade report from you
yet.  Did my mail server lose your email?

> Portaudit is now detecting a few problems
> 
> Surly it is beneficial to keep the ports current with security updates
> during a freeze ?

The patch set touches literally thousands of ports and the cost of
conflicts is nontrivial.

Kris
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Time to abandon recursive pulling of dependencies?

[Alexander Leidinger]

Quoting Stephen Montgomery-Smith <[EMAIL PROTECTED]> (Wed, 16 May 2007 16:01:56 
-0500):

> If I get some positive feedback on this one, I'll submit a PR.  You can 
> try it out by typing "make actual-package-depends" as opposed to "make 
> package-depends."

Did you my chance also had a look how to speed up ALL-DEPENDS-LIST? It
is used in clean-depends. And on my system it is slow (nearly 6 minutes
for gnome2) too. As portupgrade cleans before and after updating a
port, optimizing this may also be beneficial.

Maybe first trying to construct all dependencies of the installed ports
like in actual-package-depends and then the remaining ones like it is
done currently...

Bye,
Alexander.

-- 
Music in the soul can be heard by the universe.
-- Lao Tsu
http://www.Leidinger.net  Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org  : PGP ID = 72077137
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: HEADS UP: xorg 7.2 ready for testing

[Kris Kennaway]

On Thu, May 17, 2007 at 10:32:35AM +0200, Thierry Thomas wrote:
> Le Sam 12 mai 07 ? 16:46:11 +0200, Thierry Thomas <[EMAIL PROTECTED]>
>  ?crivait?:
> 
> > The full log - an extract on my typescript) is available at
> > .
> > 
> > No patch ATM, because the upgrade is still in progress...
> 
> Actually I have no patches to suggest: tix has been successfully
> upgraded during the second pass.
> 
> Once tix has been upgraded, cad/opencascade failed: dps is no more
> pulled automatically, and it must be added as a dependence:

I think the issue is that dps itself does not build correctly with
X.org 7.2.

Kris
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: HEADS UP: xorg 7.2 ready for testing

[Kris Kennaway]

On Thu, May 17, 2007 at 01:43:11PM +0200, Angelo Turetta wrote:
> Peter Jeremy wrote:
> >One system had a couple
> >of problems with portupgrade apparently forgetting to re-install
> >packages after uninstalling them - which took a bit of cleaning up -
> >and losing pieces of packages ('pkg_info -g' reported files missing).
> 
> This is an annoying known issue
> 
>  http://www.freebsd.org/cgi/query-pr.cgi?pr=110630
> 
> But I've not been able to debug it: of course, every time I try with a 
> controlled set of portupgrade invocations, it never fails !!

I think it's one of the issues fixed in portupgrade-devel.

Kris
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: HEADS UP: xorg 7.2 ready for testing

[KAYVEN RIESE]

umm.. try to do it tonite


jnielsendotnet:I would try this:

# pkg_deinstall -f pango
  to remove the installed pango package(s)
# cd /usr/ports/x11-toolkits/pango && make install clean
  to re-install it without portupgrade getting in the way
# pkgdb -F
  so portupgrade can figure out what you did.

If you still have problems then see what errors you are getting from xfce, 
either by looking at the console where you ran startx (if you use startx) 
or by looking at ~/.xsession-errors (if you use xdm). Post the results 
here.


Also, are you sure your ports tree is up-to-date? Mine has pango-1.16.4.

===>   An older version of x11-toolkits/pango is already installed 
(pango-1.14.9

)
  You may wish to ``make deinstall'' and install this port again
  by ``make reinstall'' to upgrade it properly.
  If you really wish to overwrite the old port of x11-toolkits/pango
  without deleting it first, set the variable "FORCE_PKG_REGISTER"
  in your environment or the "make install" command line.
*** Error code 1

Stop in /usr/ports/x11-toolkits/pango.
*** Error code 1

Stop in /usr/ports/x11-toolkits/pango.
** Command failed [exit code 1]: /usr/bin/script -qa 
/tmp/portinstall.17243.0 en
v UPGRADE_TOOL=portupgrade UPGRADE_PORT=pango-1.8.1 UPGRADE_PORT_VER=1.8.1 
make

reinstall
--->  Skipping 'x11-toolkits/pango' (pango-1.14.9) because it has already 
failed

** Listing the failed packages (*:skipped / !:failed)
! x11-toolkits/pango (pango-1.8.1)  (Failed to rewrite 
/var/db/pkg/p
ango-1.8.1/+CONTENTS: No such file or directory - 
/var/db/pkg/pango-1.8.1/+CONTE

NTS)
* x11-toolkits/pango (pango-1.14.9)
--->  Packages processed: 0 done, 0 ignored, 1 skipped and 1 failed
** Could not clean up temporary directory: Directory not empty - 
/var/tmp/portup

gradets6wfTsF
Command failed [exit code 1]: /usr/local/sbin/portinstall 
x11-toolkits/pango

bsd@/root#


On Thu, 17 May 2007, Kris Kennaway wrote:


Experts Exchange 05.17.2007 - 10:10AM PDT
A Possible Solution Has Been Added!
Hello, kayvey!
A possible solution has been added to your question:


Question: xfce4 hosed on freeBSD because of pan...
Zone: System Diagnostic Software
Comment From: jnielsendotnet


Check to see if this could be your solution.
View This Question *Please remember that it is important to return to the 
question you ask.
Copyright (C) 2007 Experts Exchange, Inc. All Rights Reserved / Privacy Policy


___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Time to abandon recursive pulling of dependencies?

[Stephen Montgomery-Smith]

Alexander Leidinger wrote:

Quoting Stephen Montgomery-Smith <[EMAIL PROTECTED]> (Wed, 16 May 2007 16:01:56 
-0500):

  
If I get some positive feedback on this one, I'll submit a PR.  You can 
try it out by typing "make actual-package-depends" as opposed to "make 
package-depends."



Did you my chance also had a look how to speed up ALL-DEPENDS-LIST? It
is used in clean-depends. And on my system it is slow (nearly 6 minutes
for gnome2) too. As portupgrade cleans before and after updating a
port, optimizing this may also be beneficial.

Maybe first trying to construct all dependencies of the installed ports
like in actual-package-depends and then the remaining ones like it is
done currently...

Bye,
Alexander.
  


I don't use "make clean" preferring a variant of "find /usr/ports -name 
work -exec rm -rf {} \;".




___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: HEADS UP: xorg 7.2 ready for testing

[Craig Boston]

Another success story for the fire, I can report a successful upgrade on
another machine -- upgrading the existing ports, not a clean install.
Used portmaster instead of portupgrade and didn't run into any problems.

I did take the slow and cautious route of upgrading a few of the ports
at a time, starting with xorg-libraries, then the individual pieces of
the meta port, finally the xorg meta port itself and then applications.
I have no reason to believe that a simple portmaster -a wouldn't work,
that's just the way I always tend to upgrade.

Xorg 7.2 works.  nvidia-driver works.  Even managed to get beryl working
(which I have to say is _very_ exciting to see something like that
running on FreeBSD).

Note to anyone wanting to run beryl -- bump kern.ipc.shmall up to at
least 16384 or 32768 to avoid strange things happening.

Craig
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: HEADS UP: xorg 7.2 ready for testing

[Rainer Hurling]

I upgraded from xorg-6.9 to xorg-7.2 on FreeBSD 7.0-CURRENT (amd64) with 
success. Now I can use nv-driver instead of vesa-driver :-)


Like Peter Jeremy I had to execute multiple 'portupgrade -a' commands. 
But two ports did not upgrade at all (math/xgobi and mail/thunderbird).


Rainer


Peter Jeremy schrieb:

I can report success on three systems.  A further system is still
upgrading.

In all cases, I had to execute multiple 'portupgrade -a' commands (and
a few 'pkgdb -F' commands) to get it to work.  One system mad a couple
of problems with portupgrade apparently forgetting to re-install
packages after uninstalling them - which took a bit of cleaning up -
and losing pieces of packages ('pkg_info -g' reported files missing).

Overall, I'd rate it as a success, though I don't think it rates as
totally idiot-proof.

Thanks to all for your efforts in getting Xorg 7.2 into the tree.


___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: HEADS UP: xorg 7.2 ready for testing

[Thierry Thomas]

Le Jeu 17 mai 07 à 18:54:36 +0200, Kris Kennaway <[EMAIL PROTECTED]>
 écrivait :
> > Once tix has been upgraded, cad/opencascade failed: dps is no more
> > pulled automatically, and it must be added as a dependence:
> 
> I think the issue is that dps itself does not build correctly with
> X.org 7.2.

It has been built on my machine (i386), and then I have been able to
build OpenCascade successfully with the previous patch.
-- 
Th. Thomas.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: HEADS UP: xorg 7.2 ready for testing

[KAYVEN RIESE]

On Thu, 17 May 2007, Thierry Thomas wrote:


Le Jeu 17 mai 07 à 18:54:36 +0200, Kris Kennaway <[EMAIL PROTECTED]>
écrivait :

Once tix has been upgraded, cad/opencascade failed: dps is no more
pulled automatically, and it must be added as a dependence:


I think the issue is that dps itself does not build correctly with
X.org 7.2.


It has been built on my machine (i386), and then I have been able to
build OpenCascade successfully with the previous patch.
--
Th. Thomas.


it seems like this list will let me know when i can safely upgrade
to xorg 7.2.. is that correct?___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Saving old shared libs (Was: Re: HEADS UP: xorg upgrade plans)

[Doug Barton]

Kris Kennaway wrote:

On Tue, May 08, 2007 at 12:06:59AM +0200, Thierry Thomas wrote:

Le Lun  7 mai 07 ? 22:58:50 +0200, Brooks Davis <[EMAIL PROTECTED]>
 ?crivait?:


The other problem is that if you're going to automatically update all
the dependencies for a port, you need to upgrade all the stuff that
depends on them as well.  For example the gettext upgrade got triggered
on my laptop by upgrading something the used gmake.  The result was that
virtually nothing outside the base worked any more.  Saving the shared
library would have prevented this and allowed a more graceful upgrade
over a few weeks.  The fact that a basic desktop setup takes days to
build on fairly fast hardware seems to be an indication that we need a
workaround here.  There are other possible solutions, but saving copied
of libraries seems to be the accepted one at the moment.

For this kind of upgrades, it's possible to add

libgettextpo.so.1   libgettextpo.so.3
libintl.so.6libintl.so.8

in your /etc/libmap.conf. Just delete these lines after the storm...


It is possible, but this is not something that non-technical users
will think of (nor should they have to).

The question is whether portmaster is to be considered as a tool for
advanced users only (those who are capable of cleaning up and
repairing damage themselves when an upgrade fails), or if it is
intended as a tool for ordinary users who don't want to (or are not
capable of) doing this kind of manual repair work.


That's a fair question, and the answer in terms of how it got started 
is definitely more the former than the latter. As feature requests 
have come in and as a wider audience has been interested in the tool 
I've tried to lower the bar quite a bit however.


At the same time, I think it's probably worthwhile to examine what the 
goals of the ports system are in this regard. If the goal is to always 
provide a fail-safe upgrade path for users then perhaps we should be 
talking about moving that support into the ports infrastructure, 
rather than talking about adding it to all the different upgrade tools.


That said, I have seen a fair bit of interest in adding the "save old 
shared libs" feature, so I'll take a look at that after I'm done with 
the "restart an aborted upgrade" stuff I'm working on now. What might 
be useful in this regard is if someone were to start a new thread 
describing exactly what the desired behavior is, and ideally to 
include a description of how portupgrade does it now.


Thanks,

Doug

--

This .signature sanitized for your protection
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: HEADS UP: xorg upgrade plans

[Doug Barton]

Brian Gruber wrote:


if you don't like the idea, that's fine, but since you
say there's been no user demand, i just thought i
should note that I tried portmaster a few months ago.
while there were things i like, i ultimately switched
back to portupgrade specifically because it lacked old
library preservation.


Thanks for letting me know.

Doug

--

This .signature sanitized for your protection
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Saving old shared libs (Was: Re: HEADS UP: xorg upgrade plans)

[Kris Kennaway]

On Thu, May 17, 2007 at 01:06:02PM -0700, Doug Barton wrote:

> At the same time, I think it's probably worthwhile to examine what the 
> goals of the ports system are in this regard. If the goal is to always 
> provide a fail-safe upgrade path for users then perhaps we should be 
> talking about moving that support into the ports infrastructure, 
> rather than talking about adding it to all the different upgrade tools.

This is true, and some first steps are already in progress.

Kris
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Time to abandon recursive pulling of dependencies?

[Stephen Montgomery-Smith]

Stephen Montgomery-Smith wrote:

Alexander Leidinger wrote:
Quoting Stephen Montgomery-Smith <[EMAIL PROTECTED]> (Wed, 16 
May 2007 16:01:56 -0500):


 
If I get some positive feedback on this one, I'll submit a PR.  You 
can try it out by typing "make actual-package-depends" as opposed to 
"make package-depends."



Did you my chance also had a look how to speed up ALL-DEPENDS-LIST? It
is used in clean-depends. And on my system it is slow (nearly 6 minutes
for gnome2) too. As portupgrade cleans before and after updating a
port, optimizing this may also be beneficial.

Maybe first trying to construct all dependencies of the installed ports
like in actual-package-depends and then the remaining ones like it is
done currently...

Bye,
Alexander.
  


I don't use "make clean" preferring a variant of "find /usr/ports -name 
work -exec rm -rf {} \;".


I just looked at it.  I really don't think it is worth the big effort 
that we put into registering ports, because a make clean only happens 
once or twice, unlike registering of the port which happens for every 
single dependency.


I think it would be better to modify portupgrade to use find to delete 
all the work in all the ports.


___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: make -j patch

[Pav Lucistnik]

Benjamin Lutz píše v čt 17. 05. 2007 v 17:00 +0200:

> ALLOW_MAKE_JOBS: Goes into a port's makefile. The port maintainer
> indicates with it that the port can be built with multiple make
> jobs.

Nit: what about making this just MAKE_JOBS, for brevity?

Otherwise it looks decent.

-- 
Pav Lucistnik <[EMAIL PROTECTED]>
  <[EMAIL PROTECTED]>

A two-eyed cyclops would be a bicyclops.


signature.asc
Description: Toto je digitálně	 podepsaná část	 zprávy

Specs for saving old shared libs

[Pav Lucistnik]

Doug Barton píše v čt 17. 05. 2007 v 13:06 -0700:

> What might 
> be useful in this regard is if someone were to start a new thread 
> describing exactly what the desired behavior is, and ideally to 
> include a description of how portupgrade does it now.

Just before old package deinstall, scan the list of files installed by
old port (pkg_info -g). Match .so.X files under PREFIX/lib and any
ldconfig'ed paths 1*), copy them away to /usr/local/lib/compat/pkg.

After installation of new port, match .so.X files again. If same
filenames appear, remove old copies from /usr/local/lib/compat/pkg.

Finally, ldconfig -r /usr/local/lib/compat/pkg


1*) portupgrade currently gets this wrong and saves all .so* files,
including uninteresting things like plugins etc.

-- 
Pav Lucistnik <[EMAIL PROTECTED]>
  <[EMAIL PROTECTED]>

The final screw holding up a rackmount server is always possessed
by demons.


signature.asc
Description: Toto je digitálně	 podepsaná část	 zprávy

Re: HEADS UP: xorg 7.2 ready for testing

[Craig Butler]

Hi All

Two successful builds and installs, stock GENERIC 6.2-RELEASE, and SMP
6.2-RELEASE-p3

Like others I also had to run 'portupgrade -a' few times.

Cheers

CB


Kris Kennaway wrote:
> Dear porters,
>
> We are now ready for xorg 7.2 testing!  Over the past week we have
> done extensive tests of various upgrade scenarios, fixed many
> remaining bugs, and now the upgrade is looking good.  Of course, we
> can't possibly test everything, so that's where you come in.  What we
> need now is for everyone to download this tarball:
>
>   http://people.freebsd.org/~kris/ports-xorg-7.2.tbz
>
> Extract it into a clean directory (i.e. not over the top of your
> existing ports tree), then follow the directions in UPDATING to begin
> the upgrade process.  In particular, please pay special attention to
> the instructions on how to record and report information should
> something go wrong: without a transcript of the upgrade session we may
> be unable to determine what went wrong on your system, and your report
> may be wasted.
>
> We're asking all FreeBSD ports committers and other interested
> developers to participate in this process: it's now up to you guys to
> test the upgrade and report problems you encounter, before we unleash
> it on the general user base.
>
> Once we have enough success reports and have dealt with all reported
> failures, we will proceed with the next stage, which is to import into
> CVS.
>
> Kris
>
>   



This email has been handled by lerwick.hopto.org mail server
and has been scanned by 3 virus killers and spamassassin


___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: make -j patch

[Benjamin Lutz]

On Thursday 17 May 2007 23:26, Pav Lucistnik wrote:
> Benjamin Lutz píše v čt 17. 05. 2007 v 17:00 +0200:
> > ALLOW_MAKE_JOBS: Goes into a port's makefile. The port maintainer
> > indicates with it that the port can be built with multiple make
> > jobs.
>
> Nit: what about making this just MAKE_JOBS, for brevity?

Well, all the other switches that go into a ports makefile start with a 
verb (USE_* or WANT_*), whereas with variables that don't start with a 
verb, their value usually matters. Since ALLOW_MAKE_JOBS is just a 
switch, I think the ALLOW should be kept.

But there's another small thing that I changed: BUILD_FAILMSG should of 
course also be printed if Perl is used for building. And while here, 
move the ===> out of the error message and into the printf format 
string. The file has been modified in place, so the URL is still

http://www.maxlor.com/freebsd/files/make_jobs.diff

The previous version, for completeness sake, is here:

http://www.maxlor.com/freebsd/files/make_jobs.diff.1

Cheers
Benjamin


pgpQrcROukQC6.pgp
Description: PGP signature

FreeBSD Port: festival-1.96

[Dave Cabot]

Maybe you can tell me what I'm doing wrong.  On a fresh copy of FreeBSD 6.2
i386 I complied festival 1.96 (and tried 1.95beta1 with the same results),
installed a voice, and tried the saytime script.  It failed with an error
msg:
SIOD ERROR: unbound variable : ¼
The last character changes every time I try compiling it.  I even installted
the gcc-4.2.0 compiler and tried and still get the same results.

Is the --script flag for festival broken on FreeBSD?  I need it for
text2wave.

Pls advise.  Thanks,
Dave

Dave Cabot
ICON Soluciones
+505 419-0750 office  | +1 727 490-3579 VoIP USA
+505 841-1013 cell| +1 519 489-0516 VoIP Canada
  | +1 727 683-9313 fax



___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

FreeBSD Port: security/expiretable

[Abdullah Ibn Hamad Al-Marri]

Hello,

FreeBSD ns2.domain.com 6.2-STABLE FreeBSD 6.2-STABLE #2: Thu May 17
22:10:51 UTC 2007

I see these errors.

messages.c: In function `error':
messages.c:34: warning: ISO C does not support the `%m' printf format
messages.c: In function `warning':
messages.c:52: warning: ISO C does not support the `%m' printf format
messages.c: In function `info':
messages.c:69: warning: ISO C does not support the `%m' printf format


ns2# cd /usr/ports/security/expiretable/ && make install clean
===>  Vulnerability check disabled, database not found
=> expiretable-0.6.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
=> Attempting to fetch from http://expiretable.fnord.se/.
expiretable-0.6.tar.gz100% of 5974  B   23 kBps
===>  Extracting for expiretable-0.6
=> MD5 Checksum OK for expiretable-0.6.tar.gz.
=> SHA256 Checksum OK for expiretable-0.6.tar.gz.
===>  Patching for expiretable-0.6
===>  Configuring for expiretable-0.6
===>  Building for expiretable-0.6
cc -O2 -fno-strict-aliasing -pipe -march=pentiumpro -march=pentiumpro
-pedantic -Wall -ansi -c expiretable.c -o expiretable.o
cc -O2 -fno-strict-aliasing -pipe -march=pentiumpro -march=pentiumpro
-pedantic -Wall -ansi -c ioctl_helpers.c -o ioctl_helpers.o
cc -O2 -fno-strict-aliasing -pipe -march=pentiumpro -march=pentiumpro
-pedantic -Wall -ansi -c messages.c -o messages.o
messages.c: In function `error':
messages.c:34: warning: ISO C does not support the `%m' printf format
messages.c: In function `warning':
messages.c:52: warning: ISO C does not support the `%m' printf format
messages.c: In function `info':
messages.c:69: warning: ISO C does not support the `%m' printf format
cc -O2 -fno-strict-aliasing -pipe -march=pentiumpro -march=pentiumpro
-pedantic -Wall -ansi expiretable.o ioctl_helpers.o messages.o -o
expiretable
===>  Installing for expiretable-0.6
===>   Generating temporary packing list
install -g bin -o root -m 755 expiretable /usr/local/sbin
install -g bin -o root -m 644 expiretable.1 /usr/local/man/man1
===> Installing rc.d startup script(s)
===>   Compressing manual pages for expiretable-0.6
===>   Registering installation for expiretable-0.6
===>  Cleaning for expiretable-0.6


Is it ok, or something need to be fixed?

--
Regards,

-Abdullah Ibn Hamad Al-Marri
Arab Portal
http://www.WeArab.Net/
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

vlock: new upstream maintainer

[Frank Benkstein]

Hi,

I just wanted to inform you that I am the new upstream maintainer
of the vlock package. I got hold of the original author, Michael Johnson
[1], and wanted to send him some patches. Instead he suggested that I
take up maintenance because he hadn't looked at the sources for a long
time himself.

From now on you may find newer versions at [2] and I am willing to look
at any pending bug reports, patches, or feature requests from you.

The next version will only incorporate my own changes and otherwise only
deal with cosmetic changes (compile time warnings, license clarification).

For future versions I have some more features on my mind and I will
probably declare shadow support dead and make PAM the only option. Also 
 I will try to keep (or enhance) FreeBSD compatibility, if I can get 
hold of some machine with root access (will try qemu first).


I'd be more than happy to hear from you, best regards
Frank Benkstein.

[1]: http://www.danlj.org/mkj/
[2]: http://cthulhu.c3d2.de/~toidinamai/vlock/vlock.html
[3]: http://www.freebsd.org/cgi/cvsweb.cgi/ports/security/vlock/

--
GPG (Mail): 7093 7A43 CC40 463A 5564  599B 88F6 D625 BE63 866F
GPG (XMPP): 2243 DBBA F234 7C5A 6D71  3983 9F28 4D03 7110 6D51
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: HEADS UP: xorg 7.2 ready for testing

[Arno J. Klaassen]

Hello,

I tested on a clean amd64-current, using portugrade-devel.

portupgrade -R xorg\* dies in graphics/libGL (probably related
to the recent changes in the thread-libraries; for some reason
/usr/lib/libpthread.so is considered 'incompatible' ) :


../../../bin/mklib -o GL -linker 'cc' \
-major 1 -minor 2  \
-install ../../../lib -L/usr/local/lib -lX11 -lXext -lXxf86vm 
-lXdamage -lXfixes -lm -lpthread `pkg-config --libs libdrm` glcontextmodes.o 
clientattrib.o compsize.o eval.o glxcmds.o glxext.o glxextensions.o indirect.o 
indirect_init.o indirect_size.o indirect_window_pos.o 
indirect_transpose_matrix.o indirect_vertex_array.o indirect_vertex_program.o 
pixel.o pixelstore.o render2.o renderpix.o single2.o singlepix.o vertarr.o 
xfont.o glx_pbuffer.o glx_query.o glx_texture_compression.o dri_glx.o XF86dri.o 
../../../src/mesa/main/dispatch.o ../../../src/mesa/glapi/glapi.o 
../../../src/mesa/glapi/glthread.o
mklib: Making FreeBSD shared library:  libGL.so.1
/usr/bin/ld: skipping incompatible /usr/lib/libpthread.so when searching for 
-lpthread
/usr/bin/ld: /usr/lib/libpthread.a(thr_syscalls.o): relocation R_X86_64_32 can 
not be used when making a shared object; recompile with -fPIC
/usr/lib/libpthread.a: could not read symbols: Bad value
mklib: Installing libGL.so.1 libGL.so in ../../../lib
mv: rename libGL.so.1 to ../../../lib/libGL.so.1: No such file or directory
gmake[3]: *** [../../../lib/libGL.so] Error 1
gmake[3]: Leaving directory 
`/files/bsd/ports7/ports/graphics/libGL/work/Mesa-6.5.3/src/glx/x11'
gmake[2]: *** [subdirs] Error 1
gmake[2]: Leaving directory 
`/files/bsd/ports7/ports/graphics/libGL/work/Mesa-6.5.3/src'
gmake[1]: *** [default] Error 1
gmake[1]: Leaving directory 
`/files/bsd/ports7/ports/graphics/libGL/work/Mesa-6.5.3'
gmake: *** [freebsd-dri] Error 2
*** Error code 2

Stop in /files/bsd/ports7/ports/graphics/libGL.
** Command failed [exit code 1]: /usr/bin/script -qa /tmp/portupgrade.70788.1 
env UPGRADE_TOOL=portupgrade UPGRADE_PORT=xorg-clients-6.9.0_3 
UPGRADE_PORT_VER=6.9.0_3 make reinstall
--->  Restoring the old version
** Fix the installation problem and try again.
[Updating the pkgdb  in /var/db/pkg ... - 294 packages found 
(-0 +37) . done]
** Listing the failed packages (*:skipped / !:failed)
! x11/xorg-apps (xorg-clients-6.9.0_3)  (install error)
--->  Packages processed: 10 done, 68 ignored, 0 skipped and 1 failed


Arno


___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: HEADS UP: xorg 7.2 ready for testing

[Arno J. Klaassen]

follow-up to myself [ Cc to current@ since per se this seems not
related to the xorg7.2 update ]:

launcing the final link command by hand and hardcoding
/lib/libthr.so.2, I get :

cc -shared -Wl,-soname,libGL.so.1 -o libGL.so.1 glcontextmodes.o clientattrib.o 
compsize.o eval.o glxcmds.o glxext.o glxextensions.o indirect.o indirect_init.o 
indirect_size.o indirect_window_pos.o indirect_transpose_matrix.o 
indirect_vertex_array.o indirect_vertex_program.o pixel.o pixelstore.o 
render2.o renderpix.o single2.o singlepix.o vertarr.o xfont.o glx_pbuffer.o 
glx_query.o glx_texture_compression.o dri_glx.o XF86dri.o 
../../../src/mesa/main/dispatch.o ../../../src/mesa/glapi/glapi.o 
../../../src/mesa/glapi/glthread.o -L/usr/local/lib -lX11 -lXext -lXxf86vm 
-lXdamage -lXfixes -lm /lib/libthr.so.2 -L/usr/local/lib -ldrm

/lib/libthr.so.2: could not read symbols: Invalid operation

though libthr.so is in good condition :

nm -D /lib/libthr.so.2 | head
 A FBSD_1.0
 A FBSDprivate_1.0
 w _Jv_RegisterClasses
51e0 T ___creat
8db0 T ___pause  


Arno

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

[ports]: VERY SERIOUS security bug in ports/sysutils/eject

[Rickardo Branco]

http://lists.freebsd.org/pipermail/freebsd-ports-bugs/2007-May/120117.html
http://www.freebsd.org/cgi/query-pr.cgi?pr=112754
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Time to abandon recursive pulling of dependencies?

[Alexander Leidinger]

Quoting Stephen Montgomery-Smith <[EMAIL PROTECTED]> (from  
Thu, 17 May 2007 15:58:38 -0500):



Stephen Montgomery-Smith wrote:

Alexander Leidinger wrote:
Quoting Stephen Montgomery-Smith <[EMAIL PROTECTED]> (Wed,  
 16 May 2007 16:01:56 -0500):



If I get some positive feedback on this one, I'll submit a PR.
You can try it out by typing "make actual-package-depends" as   
opposed to "make package-depends."




Did you my chance also had a look how to speed up ALL-DEPENDS-LIST? It
is used in clean-depends. And on my system it is slow (nearly 6 minutes
for gnome2) too. As portupgrade cleans before and after updating a
port, optimizing this may also be beneficial.

Maybe first trying to construct all dependencies of the installed ports
like in actual-package-depends and then the remaining ones like it is
done currently...

Bye,
Alexander.



I don't use "make clean" preferring a variant of "find /usr/ports   
-name work -exec rm -rf {} \;".


I just looked at it.  I really don't think it is worth the big effort
that we put into registering ports, because a make clean only happens
once or twice, unlike registering of the port which happens for every
single dependency.


"make install clean" is recommended to install a port. So it  
contributes to the time the user sees.



I think it would be better to modify portupgrade to use find to delete
all the work in all the ports.


It is not allowed to delete all ports. What if I do a make in a  
orthogonal port? It has to d o a make all-depends-list and clean the  
ports in there, but that's what make clean does.


Bye,
Alexander.

--
It is when I struggle to be brief that I become obscure.
-- Quintus Horatius Flaccus (Horace)

http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"