[solved] Re: SDL, perl and frozen-bubble: core dumped

2011-03-13 Thread Boris Samorodov
Gentlemen,

thank you for your incredible help. Success! Frozen-bubble runs!

On Sat, 12 Mar 2011 12:43:50 -0500 Kartik Thakore wrote:

 Just install frozen bubble with

 cpan Games:: FrozenBubble

Well, it was many years ago when I used direct CPAN installs. ;-)
So, I deleted the FrozenBubble package and used perl -MCPAN -e shell
to install FrozenBubble as Kartik suggested. Then I choze the
recommended option (reinstall SDL and others). And finally I
can use the game.

 If you give me your details for freebsd I can try to get a portable 
 frozenbubble package made.

You are too kind to my modest person, I can't ask you to do it.
Anyway you already have helped me.

 Kartik Thakore

 On 2011-03-12, at 4:35 AM, Boris Samorodov b...@ipt.ru wrote:

  Hi Kartik,
  
  On Sat, 12 Mar 2011 00:29:58 -0800 (PST) kthakore wrote:
  
  I picked this up on Google Alerts. I am the maintainer for SDL Perl
  and we have over the past year fixed a lot of bugs in SDL Perl. In
  addition to
  
  It was my first idea when I faced with the problem. However new
  SDL versions have a new API. So changing FreeBSD port as well as
  dependencies may need more time.
  
  that we have also migrated Frozen Bubble over to 2.2.2beta which
  should fix this problem. Please consider packaging the following
  packages.
  
  http://search.cpan.org/~garu/SDL-2.531/lib/pods/SDL.pod
  http://search.cpan.org/~kthakore/Games-FrozenBubble-2.212/lib/Games/FrozenBubble.pm
  
  Frozen Bubble beta is officially mentioned on the 
  http://www.frozen-bubble.org/downloads/
  site.
  
  Seems to be more work than I expected when offered my wife to
  install her favourable game. ;-)
  
  Btw Arch has already picked up the packages.

-- 
WBR, bsam
___
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: [solved] Re: SDL, perl and frozen-bubble: core dumped

2011-03-13 Thread Kartik Thakore
No problem! Hope you wife enjoys the game :) if you find any bugs let me know 
on sdl-de...@perl.org

Kartik Thakore

On 2011-03-13, at 4:28 AM, Boris Samorodov b...@ipt.ru wrote:

 Gentlemen,
 
 thank you for your incredible help. Success! Frozen-bubble runs!
 
 On Sat, 12 Mar 2011 12:43:50 -0500 Kartik Thakore wrote:
 
 Just install frozen bubble with
 
 cpan Games:: FrozenBubble
 
 Well, it was many years ago when I used direct CPAN installs. ;-)
 So, I deleted the FrozenBubble package and used perl -MCPAN -e shell
 to install FrozenBubble as Kartik suggested. Then I choze the
 recommended option (reinstall SDL and others). And finally I
 can use the game.
 
 If you give me your details for freebsd I can try to get a portable 
 frozenbubble package made.
 
 You are too kind to my modest person, I can't ask you to do it.
 Anyway you already have helped me.
 
 Kartik Thakore
 
 On 2011-03-12, at 4:35 AM, Boris Samorodov b...@ipt.ru wrote:
 
 Hi Kartik,
 
 On Sat, 12 Mar 2011 00:29:58 -0800 (PST) kthakore wrote:
 
 I picked this up on Google Alerts. I am the maintainer for SDL Perl
 and we have over the past year fixed a lot of bugs in SDL Perl. In
 addition to
 
 It was my first idea when I faced with the problem. However new
 SDL versions have a new API. So changing FreeBSD port as well as
 dependencies may need more time.
 
 that we have also migrated Frozen Bubble over to 2.2.2beta which
 should fix this problem. Please consider packaging the following
 packages.
 
 http://search.cpan.org/~garu/SDL-2.531/lib/pods/SDL.pod
 http://search.cpan.org/~kthakore/Games-FrozenBubble-2.212/lib/Games/FrozenBubble.pm
 
 Frozen Bubble beta is officially mentioned on the 
 http://www.frozen-bubble.org/downloads/
 site.
 
 Seems to be more work than I expected when offered my wife to
 install her favourable game. ;-)
 
 Btw Arch has already picked up the packages.
 
 -- 
 WBR, bsam
___
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: Fwd: prelminary analysis of the gmake3.82 -exp run

2011-03-13 Thread Ulrich Spörlein
On Sat, 12.03.2011 at 19:44:55 -0600, Mark Linimon wrote:
 A greatly expanded version of my original message is now at:
 
   http://wiki.freebsd.org/GmakeTODO
 
 Note: the second run is currently paused while we are working on hardware.

Augmented with a crude estimate of ports affected by these breakages
(via grepping INDEX, basically).

Only 7 ports have more than 10 deps, fixing these (for real) might be a
good start. I couldn't find a link to the actual gmake-3.82 update
patch. How do people actually test their changes?

Uli
___
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: Fwd: prelminary analysis of the gmake3.82 -exp run

2011-03-13 Thread Mark Linimon
On Sun, Mar 13, 2011 at 11:39:26AM +0100, Ulrich Spörlein wrote:
 Augmented with a crude estimate of ports affected by these breakages
 (via grepping INDEX, basically).

With a little detective work, you can get that from pointyhat.  e.g.
the Aff. (Affects) column in

  http://pointyhat-west.isc.freebsd.org/errorlogs/amd64-8-exp-latest/

 I couldn't find a link to the actual gmake-3.82 update patch.  How do
 people actually test their changes?

It's in the PR, ports/155215:

  http://tinderbox.lovett.com/patches/gmake-20110310.diff

mcl
___
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: Superfluous dependencies

2011-03-13 Thread Matthew Seaman
On 12/03/2011 23:25, Doug Barton wrote:
 That said, what is really needed is for the OPTIONS framework to take
 environmental preferences into account when dealing with defaults. In
 other words, if WITHOUT_X11 is defined in make.conf, then the defaults
 for OPTIONS that are related to requiring X11 stuff should be off. There
 are a few ports that have rolled their own manipulation of this, but
 that logic really needs to be in bsd.options.mk. Any volunteers?

+1

I've always felt it quite bizarre that WITHOUT_X11=yes has precisely no
effect on the various X11 ports themselves.

Mind you, X11 is only the largest and most obvious target here.  There's
also CUPS, SASL, MYSQL, POSTGRESQL, SQLITE, LDAP and many more where it
would be handy to be able to set a server-wide policy which:

   * disabled any optional dependency on the named target
   * blocked installation of any port with an obligatory
 dependency on the target
   * blocked installation of the target port or ports themselves

-- which I think is doable, given you're installing onto a clean system.
 What I can't get my head round is how to cope with changes of policy on
a system with plenty of packages already installed.

Cheers,

Matthew

-- 
Dr Matthew J Seaman MA, D.Phil.   7 Priory Courtyard
  Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
JID: matt...@infracaninophile.co.uk   Kent, CT11 9PW



signature.asc
Description: OpenPGP digital signature


Re: (no subject)

2011-03-13 Thread Dereckson
Good afternoon,

Meanwhile, you can download the source, uncompress and launch the
FreeBSD-aware interactive installer who compile and install the file.

fetch http://radsite.lbl.gov/radiance/dist/rad4R0all.tar.gz
tar xzvf rad4R0all.tar.gz
cd ray
./makeall install

If when you prepare the port, you use this installer instead to scons,
you have to:
- see how to offer $PREFIX instead /usr/local as default value (a
patch against makeall?)
- add to your port the following block:
.if defined(BATCH) || defined(PACKAGE_BUILDING)
IGNORE='This installer is interactive.'
.endif

A better way would be to copy the makeall script in a new one where
you pick default options (and use $PREFIX).

On Fri, Mar 4, 2011 at 2:11 PM, Konstantin Tokarev annu...@yandex.ru wrote:


 04.03.2011, 10:44, Anoop K kmtan...@gmail.com:
 Hello,
 I am a MS windows user and have come here from PC-BSD. I would like to
 make a port request for Radiance  http://radsite.lbl.gov/radiance/ .

 N.B:
 I have only begun experimenting with FreeBSD and have 8.2 installed on
 a stand alone multi boot machine, running KDE environment.

 You can start here:
 http://www.freebsd.org/doc/en/books/porters-handbook/

 --
 Regards,
 Konstantin
 ___
 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




-- 
Sébastien Santoro aka Dereckson
http://www.dereckson.be/
___
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: Compiling ports in a post-9.0-RELEASE world

2011-03-13 Thread Guido Falsi
On Sat, Mar 12, 2011 at 02:00:33PM -0800, Doug Barton wrote:
 Howdy,
 
 As many of you are no doubt already aware, much work has been
 undertaken to make clang the default compiler for the src tree
 starting with 9.0-RELEASE. It is not 100% certain that this change
 will be made, but it's looking more likely every day.
 
 This raises an interesting question for how to deal with compiling
 ports after 9.0 is released. So far there are 2 main ideas for how
 to deal with this:
 
 1. Fix all ports to compile with both gcc 4.2 (for RELENG_[78]) and clang.

This perhaps would be bst, but...(see below)

 2. Adopt an official ports compiler, which would likely be one of
 the gcc versions from the ports tree itself, and update all ports to
 work with it.

Since most of the software in the ports tree tends to be quite linux
or gcc centric I think 2 is the only viable option.

BTW I'd suggest a variation to 2. I think some option like CLANG_SAFE
or USE_CLANG(just saying, perhaps a better name can be found)
should be added to the infrastructure so, on 9.x and newer systems,
maintainer can sign that their port does build using the system
compiler. Obviously for ports having dependencies, especially
libraries, some extra testing should be performed to make sure
depending ports, which could use a different compiler, link correctly.

-- 
Guido Falsi m...@madpilot.net
___
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


Generate plist from install_manifest.txt when port uses CMake?

2011-03-13 Thread arrowdodger
Hello. Suppose we have a port, which uses CMake as build system and contains
following code:

include(FindFoo)

if(Foo_FOUND)
  add_library(FooPlugin ...)
  install(FooPlugin)
else()
  message(STATUS Foo not found, plugin will not be built.)
endif()

If user already has foo port installed, then this check will succeed and
plugin will be built, possibly altering plist. But since it's happening in
CMake, we dont know when we should adjust plist in port's Makefile. So, port
author is forced to create absolutely full plist with all variants of turned
options (which can be mutually exclusive, by the way). It's quite hard,
IMHO, especially when port has a lot of such optional dependencies. Moving
all of them into OPTIONS isnt a good solution too, because WITHOUT_FOO
option, cannot prevent CMake from building stuff if foo port is already
installed.

So, how about using CMake-generated install_manifest.txt to generate plists?
They are 100% accurate for any variant of used options and are generated
automatically, which makes porter's life easier.
___
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: Superfluous dependencies

2011-03-13 Thread Hans Ottevanger
On Sat, Mar 12, 2011 at 10:53 PM, Mark Linimon lini...@lonesome.com wrote:
 On Thu, Mar 10, 2011 at 10:28:40AM +0100, Hans Ottevanger wrote:
 If anybody is interested I could consolidate my results and post a few 
 patches.

 I would like to see them.

 This is the kind of really-dull-but-necessary work that we need to have
 people work on to fight the creeping dependencies :-)

 mcl


Real life intervened the last few days, so excuses for the delay.

Since the test system I used last week became a mess in the process, I
restarted the effort this morning on my 9.0-CURRENT system (amd64,
r219593). I have cvsupped the ports tree at about 10:45 UTC. Limiting
the discussion to Xorg alone for now, I made the following changes to
just three makefiles:

Index: devel/glib20/Makefile
===
RCS file: /home/ncvs/ports/devel/glib20/Makefile,v
retrieving revision 1.174
diff -r1.174 Makefile
42,43c42,43
 USE_PYTHON=   yes
 USE_PERL5=yes
---
 USE_PYTHON_BUILD=yes
 USE_PERL5_BUILD=yes
Index: sysutils/hal/Makefile
===
RCS file: /home/ncvs/ports/sysutils/hal/Makefile,v
retrieving revision 1.69
diff -r1.69 Makefile
29c29
 USE_PYTHON=   yes
---
 USE_PYTHON_BUILD=yes
Index: sysutils/polkit/Makefile
===
RCS file: /home/ncvs/ports/sysutils/polkit/Makefile,v
retrieving revision 1.9
diff -r1.9 Makefile
20c20
 RUN_DEPENDS=
${LOCALBASE}/share/gir-1.0/GLib-2.0.gir:${PORTSDIR}/devel/gobject-introspection
---
 #RUN_DEPENDS= 
 ${LOCALBASE}/share/gir-1.0/GLib-2.0.gir:${PORTSDIR}/devel/gobject-introspection

The first two are quite trivial, the third could be a bit tricky, but
I cannot find (and imagine) a situation where gobject-introspection is
needed on run-time for a normal end-user.

After building and installing xorg-7.5.1 I can deinstall the following
packages (and probably quite a few others that are only needed at
build-time):

autoconf-2.68
automake-1.11.1
bison-2.4.3,1
gobject-introspection-0.9.12_1
help2man-1.39.2
intltool-0.41.1
m4-1.4.15,1
p5-Locale-gettext-1.05_3
p5-XML-Parser-2.40
perl-5.10.1_3
python27-2.7.1_1
xcb-proto-1.6

As far as I can see now, X functions OK, though I still have to compile KDE.


Kind regards

Hans Ottevanger
___
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: Superfluous dependencies

2011-03-13 Thread Hans Ottevanger
On Sun, Mar 13, 2011 at 4:27 PM, Hans Ottevanger
hans.ottevan...@gmail.com wrote:
 On Sat, Mar 12, 2011 at 10:53 PM, Mark Linimon lini...@lonesome.com wrote:
 On Thu, Mar 10, 2011 at 10:28:40AM +0100, Hans Ottevanger wrote:
 If anybody is interested I could consolidate my results and post a few 
 patches.

 I would like to see them.

 This is the kind of really-dull-but-necessary work that we need to have
 people work on to fight the creeping dependencies :-)

 mcl


 Real life intervened the last few days, so excuses for the delay.

 Since the test system I used last week became a mess in the process, I
 restarted the effort this morning on my 9.0-CURRENT system (amd64,
 r219593). I have cvsupped the ports tree at about 10:45 UTC. Limiting
 the discussion to Xorg alone for now, I made the following changes to
 just three makefiles:

 Index: devel/glib20/Makefile
 ===
 RCS file: /home/ncvs/ports/devel/glib20/Makefile,v
 retrieving revision 1.174
 diff -r1.174 Makefile
 42,43c42,43
  USE_PYTHON=   yes
  USE_PERL5=    yes
 ---
 USE_PYTHON_BUILD=yes
 USE_PERL5_BUILD=yes
 Index: sysutils/hal/Makefile
 ===
 RCS file: /home/ncvs/ports/sysutils/hal/Makefile,v
 retrieving revision 1.69
 diff -r1.69 Makefile
 29c29
  USE_PYTHON=   yes
 ---
 USE_PYTHON_BUILD=yes
 Index: sysutils/polkit/Makefile
 ===
 RCS file: /home/ncvs/ports/sysutils/polkit/Makefile,v
 retrieving revision 1.9
 diff -r1.9 Makefile
 20c20
  RUN_DEPENDS=
 ${LOCALBASE}/share/gir-1.0/GLib-2.0.gir:${PORTSDIR}/devel/gobject-introspection
 ---
 #RUN_DEPENDS= 
 ${LOCALBASE}/share/gir-1.0/GLib-2.0.gir:${PORTSDIR}/devel/gobject-introspection

 The first two are quite trivial, the third could be a bit tricky, but
 I cannot find (and imagine) a situation where gobject-introspection is
 needed on run-time for a normal end-user.

 After building and installing xorg-7.5.1 I can deinstall the following
 packages (and probably quite a few others that are only needed at
 build-time):

 autoconf-2.68
 automake-1.11.1
 bison-2.4.3,1
 gobject-introspection-0.9.12_1
 help2man-1.39.2
 intltool-0.41.1
 m4-1.4.15,1
 p5-Locale-gettext-1.05_3
 p5-XML-Parser-2.40
 perl-5.10.1_3
 python27-2.7.1_1
 xcb-proto-1.6

 As far as I can see now, X functions OK, though I still have to compile KDE.


 Kind regards

 Hans Ottevanger


As suggested by Chris Rees, also as unified diffs:

--- devel/glib20/Makefile.orig  2011-03-13 17:26:30.0 +0100
+++ devel/glib20/Makefile   2011-03-13 17:26:47.0 +0100
@@ -39,8 +39,8 @@
 USE_GNOME= gnomehack pkgconfig ltverhack
 USE_GMAKE= yes
 MAKE_JOBS_SAFE=yes
-USE_PYTHON=yes
-USE_PERL5= yes
+USE_PYTHON_BUILD=yes
+USE_PERL5_BUILD=yes
 CONFIGURE_ARGS=--enable-static --with-libiconv=gnu \
--disable-gtk-doc --with-html-dir=${PREFIX}/share/doc \
--disable-man --without-xml-catalog \
--- sysutils/hal/Makefile.orig  2011-03-13 17:05:01.0 +0100
+++ sysutils/hal/Makefile   2011-03-13 17:27:58.0 +0100
@@ -26,7 +26,7 @@
 USE_GNOME= gnomehack intlhack ltverhack
 USE_AUTOTOOLS= libtool
 USE_LDCONFIG=  yes
-USE_PYTHON=yes
+USE_PYTHON_BUILD=yes
 CONFIGURE_ARGS=--disable-gtk-doc \
--with-backend=freebsd \
--disable-docbook-docs \
--- sysutils/polkit/Makefile.orig   2011-03-13 17:05:11.0 +0100
+++ sysutils/polkit/Makefile2011-03-13 17:28:54.0 +0100
@@ -17,7 +17,7 @@
 BUILD_DEPENDS=
${LOCALBASE}/share/gir-1.0/GLib-2.0.gir:${PORTSDIR}/devel/gobject-introspection
 LIB_DEPENDS=   eggdbus-1.0:${PORTSDIR}/devel/eggdbus \
expat.6:${PORTSDIR}/textproc/expat2
-RUN_DEPENDS=
${LOCALBASE}/share/gir-1.0/GLib-2.0.gir:${PORTSDIR}/devel/gobject-introspection
+#RUN_DEPENDS=
${LOCALBASE}/share/gir-1.0/GLib-2.0.gir:${PORTSDIR}/devel/gobject-introspection

 USE_GNOME= gnomehack glib20 intlhack
 USE_GMAKE= yes


Kind regards,

Hans Ottevanger
___
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: Fwd: prelminary analysis of the gmake3.82 -exp run

2011-03-13 Thread Jeremy Messenger
On Sun, Mar 13, 2011 at 6:06 AM, Mark Linimon lini...@lonesome.com wrote:
 On Sun, Mar 13, 2011 at 11:39:26AM +0100, Ulrich Spörlein wrote:
 Augmented with a crude estimate of ports affected by these breakages
 (via grepping INDEX, basically).

 With a little detective work, you can get that from pointyhat.  e.g.
 the Aff. (Affects) column in

  http://pointyhat-west.isc.freebsd.org/errorlogs/amd64-8-exp-latest/

 I couldn't find a link to the actual gmake-3.82 update patch.  How do
 people actually test their changes?

 It's in the PR, ports/155215:

  http://tinderbox.lovett.com/patches/gmake-20110310.diff

Or see here: http://lists.freebsd.org/pipermail/cvs-ports/2011-March/213529.html

I know that my steps was incorrect on 'cp' part, but I am sure that
everyone can figure it out. ;-)

Cheers,
Mezz

 mcl


-- 
mezz.free...@gmail.com - m...@freebsd.org
FreeBSD GNOME Team
http://www.FreeBSD.org/gnome/ - gn...@freebsd.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: [ECFT] drm/dri/mesa/xorg-server update [Part 1]

2011-03-13 Thread Martin Wilke
On Mon, Mar 14, 2011 at 1:20 AM, Tilman Keskinöz ar...@freebsd.org wrote:

 Hi List,

 I can confirm that the patch fixes compilation.

 The server starts up, but after the KDE4 splashscreen it segfaults.

 I tried removing the dri modules from my config, but it does not work.


 I tried to start with an autogenerated config, but the autogenerated
 config doesn't work either (on Ctrl+C the Server aborts).


ok this is with intel ?



 On Mar 12, 2011, at 17:21 , George Liaskos wrote:

  I compiled the intel driver with the following patch:
 
  --- src/i830_video.c.orig 2011-03-12 18:00:01.0 +0200
  +++ src/i830_video.c  2011-03-12 17:59:08.0 +0200
  @@ -2164,7 +2164,7 @@
  static void
  i830_fill_colorkey (ScreenPtr pScreen, uint32_t key, RegionPtr clipboxes)
  {
  -   DrawablePtr root = WindowTable[pScreen-myNum]-drawable;
  +   DrawablePtr root = pScreen-root-drawable.id;
 XID   pval[2];
 BoxPtr  pbox = REGION_RECTS(clipboxes);
 int   i, nbox = REGION_NUM_RECTS(clipboxes);
  @@ -2176,7 +2176,7 @@
 gc = GetScratchGC(root-depth, pScreen);
 pval[0] = key;
 pval[1] = IncludeInferiors;
  -   (void) ChangeGC(gc, GCForeground|GCSubwindowMode, pval);
  +   dixChangeGC(NullClient, gc, GCForeground|GCSubwindowMode, NULL);
 ValidateGC(root, gc);
 
 rects = xalloc (nbox * sizeof(xRectangle));
 
  It works but it doesn't support dri1,
 
 http://cgit.freedesktop.org/mesa/mesa/commit/?id=48c0ff14240044935049a1114edfc69bc6682b95
 
  Log: http://pastebin.com/W1iiDvWX
  ___
  freebsd-...@freebsd.org mailing list
  http://lists.freebsd.org/mailman/listinfo/freebsd-x11
  To unsubscribe, send any mail to freebsd-x11-unsubscr...@freebsd.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

___
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: Generate plist from install_manifest.txt when port uses CMake?

2011-03-13 Thread Raphael Kubo da Costa
arrowdodger 6year...@gmail.com writes:

 On Sun, Mar 13, 2011 at 7:49 PM, Raphael Kubo da Costa 
 kub...@gmail.comwrote:

 How would it interact with other features a plist might have, such as
 @dirrm or @dirrmtry and other commands?


 I'm not sure, if i get your question right. You are asking how we can
 distinguish which dirs should be @dirrm'd and which - @dirrmtry'd?

Nope, I mean if the plist is completely automatically generated, how are
you going to add commands to it, such as @dirrm or any other? In the
Makefile?

___
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


gscan2pdf 0.9.32 has unsatisfied dependencies

2011-03-13 Thread Torfinn Ingolfsen
It seems gscan2pdf 0.9.32 is missing a dependency:
tingo@kg-v2$  uname -a
FreeBSD kg-v2.kg4.no 8.1-STABLE FreeBSD 8.1-STABLE #3: Thu Sep 16
22:18:48 CEST 2010 r...@kg-v2.kg4.no:/usr/obj/usr/src/sys/GENERIC
amd64
tingo@kg-v2$ gscan2pdf
Can't locate Log/Log4perl.pm in @INC (@INC contains:
/usr/local/lib/perl5/5.10.1/BSDPAN
/usr/local/lib/perl5/site_perl/5.10.1/mach
/usr/local/lib/perl5/site_perl/5.10.1 /usr/local/lib/perl5/5.10.1/mach
/usr/local/lib/perl5/5.10.1 .) at /usr/local/bin/gscan2pdf line 156.
BEGIN failed--compilation aborted at /usr/local/bin/gscan2pdf line 156.

I installed p5-Log-Log4perl, and now I get this:
tingo@kg-v2$ gscan2pdf
Constant subroutine main::LC_CTYPE redefined at
/usr/local/lib/perl5/5.10.1/Exporter.pm line 67.
 at /usr/local/bin/gscan2pdf line 160
Prototype mismatch: sub main::LC_CTYPE () vs none at
/usr/local/lib/perl5/5.10.1/Exporter.pm line 67.
 at /usr/local/bin/gscan2pdf line 160
Constant subroutine main::LC_NUMERIC redefined at
/usr/local/lib/perl5/5.10.1/Exporter.pm line 67.
 at /usr/local/bin/gscan2pdf line 160
Prototype mismatch: sub main::LC_NUMERIC () vs none at
/usr/local/lib/perl5/5.10.1/Exporter.pm line 67.
 at /usr/local/bin/gscan2pdf line 160
Constant subroutine main::LC_TIME redefined at
/usr/local/lib/perl5/5.10.1/Exporter.pm line 67.
 at /usr/local/bin/gscan2pdf line 160
Prototype mismatch: sub main::LC_TIME () vs none at
/usr/local/lib/perl5/5.10.1/Exporter.pm line 67.
 at /usr/local/bin/gscan2pdf line 160
Constant subroutine main::LC_COLLATE redefined at
/usr/local/lib/perl5/5.10.1/Exporter.pm line 67.
 at /usr/local/bin/gscan2pdf line 160
Prototype mismatch: sub main::LC_COLLATE () vs none at
/usr/local/lib/perl5/5.10.1/Exporter.pm line 67.
 at /usr/local/bin/gscan2pdf line 160
Constant subroutine main::LC_MONETARY redefined at
/usr/local/lib/perl5/5.10.1/Exporter.pm line 67.
 at /usr/local/bin/gscan2pdf line 160
Prototype mismatch: sub main::LC_MONETARY () vs none at
/usr/local/lib/perl5/5.10.1/Exporter.pm line 67.
 at /usr/local/bin/gscan2pdf line 160
Constant subroutine main::LC_MESSAGES redefined at
/usr/local/lib/perl5/5.10.1/Exporter.pm line 67.
 at /usr/local/bin/gscan2pdf line 160
Prototype mismatch: sub main::LC_MESSAGES () vs none at
/usr/local/lib/perl5/5.10.1/Exporter.pm line 67.
 at /usr/local/bin/gscan2pdf line 160
Constant subroutine main::LC_ALL redefined at
/usr/local/lib/perl5/5.10.1/Exporter.pm line 67.
 at /usr/local/bin/gscan2pdf line 160
Prototype mismatch: sub main::LC_ALL () vs none at
/usr/local/lib/perl5/5.10.1/Exporter.pm line 67.
 at /usr/local/bin/gscan2pdf line 160
This Perl not built to support threads
Compilation failed in require at /usr/local/bin/gscan2pdf line 12397.
BEGIN failed--compilation aborted at /usr/local/bin/gscan2pdf line 12397.

Yes, it still fails, but at least the it doesn't complain about missing stuff.
A debug run:
tingo@kg-v2$ gscan2pdf --debug
Constant subroutine main::LC_CTYPE redefined at
/usr/local/lib/perl5/5.10.1/Exporter.pm line 67.
 at /usr/local/bin/gscan2pdf line 160
Prototype mismatch: sub main::LC_CTYPE () vs none at
/usr/local/lib/perl5/5.10.1/Exporter.pm line 67.
 at /usr/local/bin/gscan2pdf line 160
Constant subroutine main::LC_NUMERIC redefined at
/usr/local/lib/perl5/5.10.1/Exporter.pm line 67.
 at /usr/local/bin/gscan2pdf line 160
Prototype mismatch: sub main::LC_NUMERIC () vs none at
/usr/local/lib/perl5/5.10.1/Exporter.pm line 67.
 at /usr/local/bin/gscan2pdf line 160
Constant subroutine main::LC_TIME redefined at
/usr/local/lib/perl5/5.10.1/Exporter.pm line 67.
 at /usr/local/bin/gscan2pdf line 160
Prototype mismatch: sub main::LC_TIME () vs none at
/usr/local/lib/perl5/5.10.1/Exporter.pm line 67.
 at /usr/local/bin/gscan2pdf line 160
Constant subroutine main::LC_COLLATE redefined at
/usr/local/lib/perl5/5.10.1/Exporter.pm line 67.
 at /usr/local/bin/gscan2pdf line 160
Prototype mismatch: sub main::LC_COLLATE () vs none at
/usr/local/lib/perl5/5.10.1/Exporter.pm line 67.
 at /usr/local/bin/gscan2pdf line 160
Constant subroutine main::LC_MONETARY redefined at
/usr/local/lib/perl5/5.10.1/Exporter.pm line 67.
 at /usr/local/bin/gscan2pdf line 160
Prototype mismatch: sub main::LC_MONETARY () vs none at
/usr/local/lib/perl5/5.10.1/Exporter.pm line 67.
 at /usr/local/bin/gscan2pdf line 160
Constant subroutine main::LC_MESSAGES redefined at
/usr/local/lib/perl5/5.10.1/Exporter.pm line 67.
 at /usr/local/bin/gscan2pdf line 160
Prototype mismatch: sub main::LC_MESSAGES () vs none at
/usr/local/lib/perl5/5.10.1/Exporter.pm line 67.
 at /usr/local/bin/gscan2pdf line 160
Constant subroutine main::LC_ALL redefined at
/usr/local/lib/perl5/5.10.1/Exporter.pm line 67.
 at /usr/local/bin/gscan2pdf line 160
Prototype mismatch: sub main::LC_ALL () vs none at
/usr/local/lib/perl5/5.10.1/Exporter.pm line 67.
 at /usr/local/bin/gscan2pdf line 160
This Perl not built to support threads
Compilation failed in require at /usr/local/bin/gscan2pdf line 12397.
BEGIN failed--compilation aborted at 

Re: Generate plist from install_manifest.txt when port uses CMake?

2011-03-13 Thread arrowdodger
On Sun, Mar 13, 2011 at 8:43 PM, Raphael Kubo da Costa kub...@gmail.comwrote:

 Nope, I mean if the plist is completely automatically generated, how are
 you going to add commands to it, such as @dirrm or any other? In the
 Makefile?


Are they actually needed? I can't come up with example when i need to put
something into plist, if everything in it already generated automatically.
The initial idea was to get rid of writing something into plist by hand.
___
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: [ECFT] drm/dri/mesa/xorg-server update [Part 1]

2011-03-13 Thread Tilman Keskinöz

On Mar 13, 2011, at 18:40 , Martin Wilke wrote:
 
 Hi List,
 
 I can confirm that the patch fixes compilation.
 
 The server starts up, but after the KDE4 splashscreen it segfaults.
 
 I tried removing the dri modules from my config, but it does not work.
 
 
 I tried to start with an autogenerated config, but the autogenerated
 config doesn't work either (on Ctrl+C the Server aborts).
 
 
 ok this is with intel ?

Yes, with Intel. The card is an Intel G33.
The crash is probably happening the first time something tries to access
dri, libdrm.
___
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: [ECFT] drm/dri/mesa/xorg-server update [Part 1]

2011-03-13 Thread Martin Wilke
On Mon, Mar 14, 2011 at 2:04 AM, Tilman Keskinöz ar...@freebsd.org wrote:


 On Mar 13, 2011, at 18:40 , Martin Wilke wrote:
 
  Hi List,
 
  I can confirm that the patch fixes compilation.
 
  The server starts up, but after the KDE4 splashscreen it segfaults.
 
  I tried removing the dri modules from my config, but it does not work.
 
 
  I tried to start with an autogenerated config, but the autogenerated
  config doesn't work either (on Ctrl+C the Server aborts).
 
 
  ok this is with intel ?

 Yes, with Intel. The card is an Intel G33.
 The crash is probably happening the first time something tries to access
 dri, libdrm.



ok gives any logs?
___
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: Generate plist from install_manifest.txt when port uses CMake?

2011-03-13 Thread Raphael Kubo da Costa
arrowdodger 6year...@gmail.com writes:

 On Sun, Mar 13, 2011 at 8:43 PM, Raphael Kubo da Costa 
 kub...@gmail.comwrote:

 Nope, I mean if the plist is completely automatically generated, how are
 you going to add commands to it, such as @dirrm or any other? In the
 Makefile?

 Are they actually needed? I can't come up with example when i need to put
 something into plist, if everything in it already generated automatically.
 The initial idea was to get rid of writing something into plist by hand.

I might be missing something here, but I think they sometimes are.

Taking devel/cmake itself as an example, it has a few @dirrm and
@dirrmtry entries in the end which seem to make sense to exist.

Either way, using install_manifest.txt even as a hint does sounds useful
to me too.

P.S.: There's no need to CC me in the responses, just mailing
freebsd-ports should be fine :)

___
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: Superfluous dependencies

2011-03-13 Thread Miroslav Lachman

Charlie Kester wrote:

[...]


A few minutes ago, I was answering a post on the forums, in which a user
expressed surprise (and outrage) that the phpmyadmin port was installing
libX11 and similar things on his server. By installing it myself and
then using pkg_tree -v to examine the dependencies, I was able to
narrow it down to two of the port's options that were ON by default.


I made a simple shell script similar to pkg_tree but for ports about 
year ago.


http://freebsd.quip.cz/script/ports_tree.sh

It is very simple script showing full dependency tree for all listed 
dependencies (not skipping already shown deps - portdependencytree.py
is not showing them again). This way, you can find what needs libtool 
for example.


You can call it 'ports_tree.sh lang/php5', then it will show you all 
dependencies (build + run), or you can use -b (build deps only) or -r 
(run deps only)


example of build deps for Vim:

ports_tree.sh -b editors/vim
editors/vim
converters/libiconv
devel/libtool
devel/gettext
converters/libiconv
devel/libtool
devel/libtool


run deps for Vim:

ports_tree.sh -r editors/vim
editors/vim
converters/libiconv
devel/gettext
converters/libiconv

Shown dependency tree is affected by make.conf / ports.conf, options etc.

Miroslav Lachman
___
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: Compiling ports in a post-9.0-RELEASE world

2011-03-13 Thread Klaus T. Aehlig

Hi,

 I think some option like CLANG_SAFE or USE_CLANG (just 
 saying, perhaps a better name can be found) should be added [...]

I also think that it would be very useful to go the same route
as with MAKE_JOBS, i.e., ports can opt in, and in the long run opt out,
of being build with clang. In my opinion, that should also include a 
variable like FORCE_MAKE_JOBS, say FORCE_CLANG, that makes all undecided 
ports (i.e., those neither CLANG_SAFE nor CLANG_UNSAFE) chose clang.

Best,
Klaus

___
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: Plans for making MAKE_JOBS_SAFE as default

2011-03-13 Thread Anonymous
Alexey Dokuchaev da...@freebsd.org writes:

 On Thu, Dec 23, 2010 at 07:12:22AM -0600, Ade Lovett wrote:
 On Dec 23, 2010, at 03:18 , Alexey Dokuchaev wrote:
  I'd really like to see that happen.  If there is anything I can help
  with, don't hesitate to ask.  :-)
 
 Given that we're _really_ close to 7.4/8.2 -- not this side of
 January mumble -- random uneducated guess.  In time for 9.0.

 I understand that it's not in time for upcoming releases, but I'd like
 to push the change after the ports tree is unslushed.

7.4/8.2 are officially out. Didn't you request an -exp run yet?
I've tried to look at pointyhat.freebsd.org but it's opaque regarding
what patches were used for each -exp run. And there is no PR.

--
just a reminder
___
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: Superfluous dependencies

2011-03-13 Thread Matthew Seaman
On 13/03/2011 03:39, Charlie Kester wrote:
 On Sat 12 Mar 2011 at 18:28:42 PST Doug Barton wrote:
 On 03/12/2011 18:13, per...@pluto.rain.com wrote:
 Charlie Kestercorky1...@comcast.net  wrote:

 A few minutes ago, I was answering a post on the forums, in which
 a user expressed surprise (and outrage) that the phpmyadmin port
 was installing libX11 and similar things on his server.  By
 installing it myself and then using pkg_tree -v to examine the
 dependencies, I was able to narrow it down to two of the port's
 options that were ON by default.

 I'm not aware of any tool that will display a similar dependency
 tree for a port *before* it is installed.  make all-depends-list
 creates exactly what it suggests, a list, and doesn't show any
 of the hierarchical info that is needed to answer questions like
 the one I was working on.   If there is such a tool, I'd love to
 hear about it.

 Would something along the lines of make -n fetch-recursive
 help at all?  I would expect it to walk the dependency tree
 in a predictable order.

 The problem with the pre-existing targets is that they do not take the
 user's choices in OPTIONS into account. portmaster's technique (while
 not perfect) at least does that.
 
 True, but that's not really needed in order to answer questions like
 Why is this port installing foo?  Once we know which dependency leads
 to foo, we can look to see if there's an option to disable it somewhere
 up the tree.
 
 Same for the original problem at the start of this thread. Once we know
 where foo gets pulled in, we can look to see if it's a BUILD or a RUN
 dependency. (Although it would be nice if whatever tool is displaying
 the tree would have indicated that already, just as it would nice if
 portions of the tree were greyed out if the controlling options are
 turned off...)

Well, this seems to be turning into a bit of a band-wagon.  Here's my
attempt to jump on it.  Since I already had about 90% of the necessary
code already in my FreeBSD::Portindex stuff, I've added a new
'portdepends' script.  This generates a detailed dependency tree
printout for a port using the data stored in the portindex cache.

Output looks like this:

% portdepends textproc/sphinxsearch
[..] sphinxsearch-0.9.9 (textproc/sphinxsearch)
[.L] - libiconv-1.13.1_1 (converters/libiconv)
[...B..] - - libtool-2.4 (devel/libtool)
[.L] - mysql-client-5.1.55 (databases/mysql51-client)
[...BR.] - - openssl-1.0.0_5 (security/openssl)
[...B..] - - - makedepend-1.0.3,1 (devel/makedepend)
[...BR.] - - - - pkg-config-0.25_1 (devel/pkg-config)
[...B..] - - - - - gmake-3.81_4 (devel/gmake)
[.L] - - - - - - gettext-0.18.1.1 (devel/gettext)
[.L] - - - - - - - libiconv-1.13.1_1 (converters/libiconv)
[...B..] - - - - - - - - libtool-2.4 (devel/libtool)
[...B..] - - - - - - - libtool-2.4 (devel/libtool)
[...BR.] - - - - xproto-7.0.16 (x11/xproto)
[...BR.] - - - - - pkg-config-0.25_1 (devel/pkg-config)
[...B..] - - - - - - gmake-3.81_4 (devel/gmake)
[.L] - - - - - - - gettext-0.18.1.1 (devel/gettext)
[.L] - - - - - - - - libiconv-1.13.1_1 (converters/libiconv)
[...B..] - - - - - - - - - libtool-2.4 (devel/libtool)
[...B..] - - - - - - - - libtool-2.4 (devel/libtool)
[EP.B..] - - - perl-5.10.1_3 (lang/perl5.10)
[.L] - expat-2.0.1_1 (textproc/expat2)

The left hand column shows the type of dependency: one of Extract,
Patch, Fetch (v. rare), Build, Run or Lib.  It's kind of repetitive,
unlike Mark Linimon's python script, mostly because I wanted to keep the
code relatively simple.

Download here:

http://www.infracaninophile.co.uk/portindex/FreeBSD-Portindex-2.3.tar.bz2

I'll submit a ports PR shortly.

Cheers,

Matthew

-- 
Dr Matthew J Seaman MA, D.Phil.   7 Priory Courtyard
  Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
JID: matt...@infracaninophile.co.uk   Kent, CT11 9PW



signature.asc
Description: OpenPGP digital signature


Re: [ECFT] drm/dri/mesa/xorg-server update [Part 1]

2011-03-13 Thread George Liaskos
 The crash is probably happening the first time something tries to access
 dri, libdrm.

I believe that kwin tries to use desktop effects by default. Better
try a simple xinit for start to see how it goes and post the log.

Ok, after some research about the patch i believe that this how it should be :

--- src/i830_video.c.orig   2009-05-13 03:12:11.0 +0300
+++ src/i830_video.c2011-03-13 21:39:08.0 +0200
@@ -57,7 +57,6 @@

 #include xf86.h
 #include xf86_OSproc.h
-#include xf86Resources.h
 #include compiler.h
 #include xf86PciInfo.h
 #include xf86Pci.h
@@ -2165,7 +2164,7 @@
 static void
 i830_fill_colorkey (ScreenPtr pScreen, uint32_t key, RegionPtr clipboxes)
 {
-   DrawablePtr root = WindowTable[pScreen-myNum]-drawable;
+   DrawablePtr root = pScreen-root-drawable;
XIDpval[2];
BoxPtr  pbox = REGION_RECTS(clipboxes);
inti, nbox = REGION_NUM_RECTS(clipboxes);
@@ -2177,7 +2176,7 @@
gc = GetScratchGC(root-depth, pScreen);
pval[0] = key;
pval[1] = IncludeInferiors;
-   (void) ChangeGC(gc, GCForeground|GCSubwindowMode, pval);
+   (void) dixChangeGC(NullClient, gc, GCForeground|GCSubwindowMode,
pval, NULL);
ValidateGC(root, gc);

rects = xalloc (nbox * sizeof(xRectangle));

This patch replaces xf86-video-intel/files/patch-src_i830_video.c
It works for me without AIGLX, tried dwm/awesome/xfce4. I will build kde next.
___
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: [HEADS UP] GNU make 3.82

2011-03-13 Thread Peter Jeremy
On 2011-Mar-10 21:46:06 -0600, Ade Lovett a...@freebsd.org wrote:
As for the rest of your post.  It's the usual diatribe.  If you think
you can do better, by all means, step up to the plate and actually
_do_ something.  Like yours truly has done reducing libtool to 1
version, and autoconf/automake to 2 versions (legacy and current).

I think you are being unreasonable here.  Doug is not denigrating the
work you have put into the ports system, he is merely stating that
your proposed implementation plan for gmake 3.82 seems sub-optimal,
based on the publicly available information.  Your initial post did
not even include a reference to your planned changes.

I fully accept that the problem has been created by the gmake
developers and is nothing to do with you.

Unless you're prepared to step up to the plate, offer alternate
_concrete_ plans (as I have already done) and are willing to spend
considerable brain and cpu cycles to get to the desired solution, you
have no right to question what _is_ being done by those that _are_
doing it.

It's very difficult to offer an alternative plan when the information
needed to produce such a plan is being withheld.  On several occasion,
Doug has asked for the results of the gmake 3.82 exp run.  This request
(which seems perfectly reasonable to me) has been consistently ignored.

Elsewhere in this thread, there was a reference to ports/151312.  This
shows as superceded by ports/155215.  Looking at the latter port, it
includes a reference to a patchset to implement your plan.

Having read through this thread, it is still unclear to me why it is
not possible to fix up the problematic ports before importing gmake
3.82, removing the need for a gmake381 port.

-- 
Peter Jeremy


pgpW6epYzFNgn.pgp
Description: PGP signature


Re: [HEADS UP] GNU make 3.82

2011-03-13 Thread Mark Linimon
On Mon, Mar 14, 2011 at 08:27:27AM +1100, Peter Jeremy wrote:
 On several occasion, Doug has asked for the results of the gmake 3.82
 exp run.  This request (which seems perfectly reasonable to me) has
 been consistently ignored.

Provided in email in this thread two days ago; annotated, at a high
level of detail, on the wiki, one day ago.

  http://wiki.freebsd.org/GmakeTODO

mcl
___
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: portmaster comments

2011-03-13 Thread Doug Barton

On 3/13/2011 5:35 PM, Peter Jeremy wrote:

Hi Doug,

I'd like to raise a couple of nits with portmaster (primarily a wish
for more configurability):

1) In v3.0, you added code to nice(1) all make(1) invocations.  In some
cases, the default niceness does not suit me (in particular, I'd often
prefer '0' to '10').  Would it be possible to add an option to control
the priority?

2) In v3.6, you added a find $WRKDIRPREFIX ... to the cleanup.  For
various reasons, I have _lots_ of unrelated stuff under that tree and
so the find(1) takes an unacceptably long time to run.  It would be
nice to restrict that search to $WRKDIRPREFIX${.CURDIR} and have an
option to disable it completely.


Neither is likely to happen. :)  I may however remove 1, it didn't 
really help much, if at all. As for 2, my suggestion is to have a 
WRKDIRPREFIX for development stuff, and a different one for portmaster. 
It's pretty easy to do with a make.conf knob searching for whether 
UPGRADE_TOOL is set to portmaster. I have such a thing which I can 
send you if you really need me to, but I'm not booted into FreeBSD right 
now so I don't have it close to hand.


BTW, the reason I'm not amenable to your suggestion in 2 is that only a 
few developer-types actually care about this, and that doesn't justify 
the code complexity. Just be thankful I didn't go with my first 
instinct, which was to 'rm -rf $WRKDIRPREFIX' :)



hth,

Doug


--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price.  :)  http://SupersetSolutions.com/

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


Re: Generate plist from install_manifest.txt when port uses CMake?

2011-03-13 Thread Rob Farmer
On Sun, Mar 13, 2011 at 10:43 AM, Raphael Kubo da Costa
kub...@gmail.com wrote:
 Nope, I mean if the plist is completely automatically generated, how are
 you going to add commands to it, such as @dirrm or any other? In the
 Makefile?


You can have most of the plist dynamically generated, then whatever is
in pkg-plist is added (at the end, IIRC). See math/scilab for an
example.

-- 
Rob Farmer
___
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


portmaster comments

2011-03-13 Thread Peter Jeremy
Hi Doug,

I'd like to raise a couple of nits with portmaster (primarily a wish
for more configurability):

1) In v3.0, you added code to nice(1) all make(1) invocations.  In some
cases, the default niceness does not suit me (in particular, I'd often
prefer '0' to '10').  Would it be possible to add an option to control
the priority?

2) In v3.6, you added a find $WRKDIRPREFIX ... to the cleanup.  For
various reasons, I have _lots_ of unrelated stuff under that tree and
so the find(1) takes an unacceptably long time to run.  It would be
nice to restrict that search to $WRKDIRPREFIX${.CURDIR} and have an
option to disable it completely.

-- 
Peter Jeremy


pgpLZJMbNTuMT.pgp
Description: PGP signature


Re: [HEADS UP] GNU make 3.82

2011-03-13 Thread Ade Lovett

On Mar 13, 2011, at 16:27 , Peter Jeremy wrote:
 Having read through this thread, it is still unclear to me why it is
 not possible to fix up the problematic ports before importing gmake
 3.82, removing the need for a gmake381 port.

I believe Mark has offered up, on multiple occasions a wiki page from the 
_first_ exp run.

Of course, if port A fails as a result of gmake (or, quite frankly, 
whatever), and it has dependent ports, then unti such time as the proverbial 
quick hack to unbreak it, we have absolutely no idea of the carnage further 
down the tree.

devel/gmake381 exists for one reason, and one reason only.  To allow -exp runs 
to fully test what breaks, and what doesn't with a devel/gmake being 3.82.  
You'll notice that it is not attached to the build (in devel/Makefile) and it 
is also marked IGNORE.  Using a few extra inodes in order to be able to 
properly test things (you should also note that USE_GMAKE=381 is merely part of 
an -exp patchset, and not present in the existing Mk/bsd.port.mk) is a minor 
cost for substantial gains when actually running said -exp runs.

Could this have been handled better.  Sure, maybe.  But it would require 
*proactive* work within the community as opposed to the you're doing it wrong 
*reactive* mentality.  It's easy to criticize.  Much harder to do work that 
affects thousand of ports and, in the best case, no-one actually sees a change.

-aDe

___
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