Re: [graphics/mapserver] PHP Mapscript
Btw., I wonder why
/usr/ports/lang/php5/work/php-5.4.6/Zend/zend_object_handlers.c appears
in the core dump. Shouldn't that have been moved to an appropriate
directory somewhere and the link be updated?
Frank
Am 2012-09-26 16:17, schrieb Frank Broniewski:
Hi,
I have a problem with PHP Mapscript (the graphics/mapserver package). I
suppose the problem is in conjunction with the combination of lang/php5
(PHP 5.4.6) and Mapserver 6.0.3. Everytime I try to initiate a new
mapObj in mapscript, PHP segfaults.
My testscript:
ms_GetVersion() still works, but the next line ($map = new
mapObj('test.map')) causes the segmentation fault to happen:
brfr@frodo# php -f pi.php
MapServer version 6.0.3 OUTPUT=GIF OUTPUT=PNG OUTPUT=JPEG SUPPORTS=PROJ
SUPPORTS=AGG SUPPORTS=FREETYPE SUPPORTS=ICONV SUPPORTS=WMS_SERVER
SUPPORTS=WMS_CLIENT SUPPORTS=WFS_SERVER SUPPORTS=WFS_CLIENT
SUPPORTS=GEOS INPUT=POSTGIS INPUT=OGR INPUT=GDAL
INPUT=SHAPEFILESegmentation fault (core dumped)
An examination of the core with gdb yields
brfr@frodo# gdb /usr/local/bin/php php.core
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...
Core was generated by `php'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libcrypt.so.5...done.
Loaded symbols for /lib/libcrypt.so.5
[snip ...]
Reading symbols from /usr/local/lib/php/20100525-debug/tidy.so...done.
Loaded symbols for /usr/local/lib/php/20100525-debug/tidy.so
Reading symbols from /usr/local/lib/libtidy-0.99.so.0...done.
Loaded symbols for /usr/local/lib/libtidy-0.99.so.0
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
#0 0x0069a10a in zend_std_get_constructor (object=0x8024762c8)
at
/usr/ports/lang/php5/work/php-5.4.6/Zend/zend_object_handlers.c:1271
1271/usr/ports/lang/php5/work/php-5.4.6/Zend/zend_object_handlers.c:
No such file or directory.
in /usr/ports/lang/php5/work/php-5.4.6/Zend/zend_object_handlers.c
[New Thread 802407400 (LWP 100919/php)]
(gdb)
I tried compiling everything back and forth, enabled and disabled all
kinds of PHP extensions but nothing helps. Segfault is coming always
back to me. Btw.
root@frodo# php -v
PHP 5.4.6 (cli) (built: Sep 26 2012 15:32:23) (DEBUG)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies
works, and all non-mapscript PHP applications seem to run fine.
So, finally, any tipps to solve this problem are greatly appreceated ...
Frank
--
Frank BRONIEWSKI
METRICO s.à r.l.
géomètres
technologies d'information géographique
rue des Romains 36
L-5433 NIEDERDONVEN
tél.: +352 26 74 94 - 28
fax.: +352 26 74 94 99
http://www.metrico.lu
___
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: Quick status update on Squid 3.x ports
Hi Thomas,
Thomas-Martin Seck wrote on 27.09.2012 09:22:
Hi,
this is just a short update on the status of Squid 3 ports. As you may
have noticed I am a bit behind with regards to Squid 3.2. Sorry for that
-- I could not spend much time for ports development in the last few
months. To add insult to injury I will be offline for the next couple of
days but I plan to have the 3.2 port ready in the week starting Oct 7
nonetheless.
I just submitted an update request for 3.1 to 3.1.21 for the time being.
On a side note: in the past, the default Squid port was named
www/squid and the older or development Squid versions had versioned port
directory names. Should we move www/squid to www/squid27 instead and
make all Squid dependend ports that currently depend on www/squid use
www/squid27 instead?
Best regards
First thank you for working on this. According to squid web-page, 3.2 is
the only stable version ("Current versions suitable for production
use."), that is actively maintained. 3.1 and less are listed in "Old
versions - Provided for archival purposes only. Not intended for general
use in new installations". Is there still 2.7 users?! As for me, 3.2
should go to www/squid and some kind of exp-run should be done to make
sure the ports depending on it builds fine.
--
Regards,
Ruslan
Tinderboxing kills... the drives.
___
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: coovachilli port update
On 27 Sep 2012, at 05:02 AM, Егор Потёмкин wrote: > Hello! > > Are you planning to update coovachilli port to version 1.2.9? > > Thank you, > Egor No, waiting for 1.3.0 to release.___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [graphics/mapserver] PHP Mapscript
Sorry for spamming. I did a `make` in /usr/ports/lang/php5 and checked,
if there's a Zend directory in work/php-5.4.6/, but there's no Zend
directory in work. Should one be there? Can someone please verify, if
there's usually a Zend directory at
/usr/ports/lang/php5/work/php-5.4.6/? That would be very kind :-)
If `Zend` is not a standard directory for compiling PHP, the directory
seems to be introduced by another extension (mapscript maybe?)
Thanks,
Frank
Am 2012-09-27 09:00, schrieb Frank Broniewski:
Btw., I wonder why
/usr/ports/lang/php5/work/php-5.4.6/Zend/zend_object_handlers.c appears
in the core dump. Shouldn't that have been moved to an appropriate
directory somewhere and the link be updated?
Frank
Am 2012-09-26 16:17, schrieb Frank Broniewski:
Hi,
I have a problem with PHP Mapscript (the graphics/mapserver package). I
suppose the problem is in conjunction with the combination of lang/php5
(PHP 5.4.6) and Mapserver 6.0.3. Everytime I try to initiate a new
mapObj in mapscript, PHP segfaults.
My testscript:
ms_GetVersion() still works, but the next line ($map = new
mapObj('test.map')) causes the segmentation fault to happen:
brfr@frodo# php -f pi.php
MapServer version 6.0.3 OUTPUT=GIF OUTPUT=PNG OUTPUT=JPEG SUPPORTS=PROJ
SUPPORTS=AGG SUPPORTS=FREETYPE SUPPORTS=ICONV SUPPORTS=WMS_SERVER
SUPPORTS=WMS_CLIENT SUPPORTS=WFS_SERVER SUPPORTS=WFS_CLIENT
SUPPORTS=GEOS INPUT=POSTGIS INPUT=OGR INPUT=GDAL
INPUT=SHAPEFILESegmentation fault (core dumped)
An examination of the core with gdb yields
brfr@frodo# gdb /usr/local/bin/php php.core
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "amd64-marcel-freebsd"...
Core was generated by `php'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libcrypt.so.5...done.
Loaded symbols for /lib/libcrypt.so.5
[snip ...]
Reading symbols from /usr/local/lib/php/20100525-debug/tidy.so...done.
Loaded symbols for /usr/local/lib/php/20100525-debug/tidy.so
Reading symbols from /usr/local/lib/libtidy-0.99.so.0...done.
Loaded symbols for /usr/local/lib/libtidy-0.99.so.0
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
#0 0x0069a10a in zend_std_get_constructor (object=0x8024762c8)
at
/usr/ports/lang/php5/work/php-5.4.6/Zend/zend_object_handlers.c:1271
1271/usr/ports/lang/php5/work/php-5.4.6/Zend/zend_object_handlers.c:
No such file or directory.
in /usr/ports/lang/php5/work/php-5.4.6/Zend/zend_object_handlers.c
[New Thread 802407400 (LWP 100919/php)]
(gdb)
I tried compiling everything back and forth, enabled and disabled all
kinds of PHP extensions but nothing helps. Segfault is coming always
back to me. Btw.
root@frodo# php -v
PHP 5.4.6 (cli) (built: Sep 26 2012 15:32:23) (DEBUG)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies
works, and all non-mapscript PHP applications seem to run fine.
So, finally, any tipps to solve this problem are greatly appreceated ...
Frank
--
Frank BRONIEWSKI
METRICO s.à r.l.
géomètres
technologies d'information géographique
rue des Romains 36
L-5433 NIEDERDONVEN
tél.: +352 26 74 94 - 28
fax.: +352 26 74 94 99
http://www.metrico.lu
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [graphics/mapserver] PHP Mapscript
Hi,
Can this be some kind of library version mismatch? Both PHP and
Mapserver use GD for working with graphics. But PHP uses its internal GD
while Mapserver uses the FreeBSD version. Both differ in version;
FreeBSD GD is gd-2.0.35_8,1, PHP uses [GD Version] => bundled (2.0.34
compatible). So, how can I force PHP to use the FreeBSD GD version? If I
had a .configure, I'd use --with-gd=/usr/... but how is that possible
with make config?
Frank
Am 2012-09-27 09:00, schrieb Frank Broniewski:
Btw., I wonder why
/usr/ports/lang/php5/work/php-5.4.6/Zend/zend_object_handlers.c appears
in the core dump. Shouldn't that have been moved to an appropriate
directory somewhere and the link be updated?
Frank
Am 2012-09-26 16:17, schrieb Frank Broniewski:
Hi,
I have a problem with PHP Mapscript (the graphics/mapserver package). I
suppose the problem is in conjunction with the combination of lang/php5
(PHP 5.4.6) and Mapserver 6.0.3. Everytime I try to initiate a new
mapObj in mapscript, PHP segfaults.
My testscript:
ms_GetVersion() still works, but the next line ($map = new
mapObj('test.map')) causes the segmentation fault to happen:
brfr@frodo# php -f pi.php
MapServer version 6.0.3 OUTPUT=GIF OUTPUT=PNG OUTPUT=JPEG SUPPORTS=PROJ
SUPPORTS=AGG SUPPORTS=FREETYPE SUPPORTS=ICONV SUPPORTS=WMS_SERVER
SUPPORTS=WMS_CLIENT SUPPORTS=WFS_SERVER SUPPORTS=WFS_CLIENT
SUPPORTS=GEOS INPUT=POSTGIS INPUT=OGR INPUT=GDAL
INPUT=SHAPEFILESegmentation fault (core dumped)
An examination of the core with gdb yields
brfr@frodo# gdb /usr/local/bin/php php.core
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "amd64-marcel-freebsd"...
Core was generated by `php'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libcrypt.so.5...done.
Loaded symbols for /lib/libcrypt.so.5
[snip ...]
Reading symbols from /usr/local/lib/php/20100525-debug/tidy.so...done.
Loaded symbols for /usr/local/lib/php/20100525-debug/tidy.so
Reading symbols from /usr/local/lib/libtidy-0.99.so.0...done.
Loaded symbols for /usr/local/lib/libtidy-0.99.so.0
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
#0 0x0069a10a in zend_std_get_constructor (object=0x8024762c8)
at
/usr/ports/lang/php5/work/php-5.4.6/Zend/zend_object_handlers.c:1271
1271/usr/ports/lang/php5/work/php-5.4.6/Zend/zend_object_handlers.c:
No such file or directory.
in /usr/ports/lang/php5/work/php-5.4.6/Zend/zend_object_handlers.c
[New Thread 802407400 (LWP 100919/php)]
(gdb)
I tried compiling everything back and forth, enabled and disabled all
kinds of PHP extensions but nothing helps. Segfault is coming always
back to me. Btw.
root@frodo# php -v
PHP 5.4.6 (cli) (built: Sep 26 2012 15:32:23) (DEBUG)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies
works, and all non-mapscript PHP applications seem to run fine.
So, finally, any tipps to solve this problem are greatly appreceated ...
Frank
--
Frank BRONIEWSKI
METRICO s.à r.l.
géomètres
technologies d'information géographique
rue des Romains 36
L-5433 NIEDERDONVEN
tél.: +352 26 74 94 - 28
fax.: +352 26 74 94 99
http://www.metrico.lu
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [PATCH] unbreak XDM build when clang set as base compiler
On 2012-09-26 01:41, Jan Beich wrote: > Oliver Pinter writes: I just committed a fix for this, based on Jan's patch in ports/172100. Regards! -- Niclas ___ 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"
coovachilli port update
Hello! Are you planning to update coovachilli port to version 1.2.9? Thank you, Egor ___ 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"
redports - should I rename the updated distfile (tarball)?
redports.org is good, thank you to whoever worked on it. One question: the upstream for my port is non-existent, so rather then patch it, I'm updating the code itself. I then create a new tarball. It seems redports doesn't update the tarball every time I request a build. So it seems I have to update the version in Makefile each time and create a tarball with this new number. Is that so? Thanks Anton ___ 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"
clang dangling else help
I'm not great with C.
Building my port with clang I get this warning
(gcc doesn't pick this up):
x11.c:1543:5: warning: add explicit braces to avoid dangling else
[-Wdangling-else]
else if (actual_type != None)
^
1 warning generated.
I think I understand what's going on,
but wanted somebody to double check.
This is the relevant fragment:
1511 static void freePrevious(dpy, w)
1512 Display *dpy;
1513 Window w;
1514 {
1515 Pixmap *pm;
1516 Atom actual_type;
1517 int format;
1518 unsigned long nitems;
1519 unsigned long bytes_after;
1520
1521 /* intern the property name */
1522 Atom atom = XInternAtom(dpy, RETAIN_PROP_NAME, 0);
1523
1524 /* look for existing resource allocation */
1525 if ((XGetWindowProperty(dpy, w, atom, 0, 1, 1 /*delete*/,
1526 AnyPropertyType, &actual_type,
1527 &format, &nitems, &bytes_after,
1528 (unsigned char **) &pm) == Success) &&
1529 (nitems == 1))
1530 if ((actual_type == XA_PIXMAP) && (format == 32) &&
1531 (nitems == 1) && (bytes_after == 0))
1532 {
1533 /* blast it away, but first provide new X error handler in case
1534* the client that installed the RETAIN_PROP_NAME (_XSETROOT_ID)
1535* property on the root window has already terminated
1536*/
1537 orig_error_handler = XSetErrorHandler(xkill_handler);
1538 XKillClient(dpy, (XID) *pm);
1539 XSync(dpy, False);
1540 XSetErrorHandler(orig_error_handler);
1541 XFree((void *) pm);
1542 }
1543 else if (actual_type != None)
1544 {
1545 fprintf(stderr,
1546 "%s: warning: invalid format encountered for property
%s\n",
1547 RETAIN_PROP_NAME, progname);
1548 }
1549 }
I think, to preserve the logic, this should be changed to:
1511 static void freePrevious(dpy, w)
1512 Display *dpy;
1513 Window w;
1514 {
1515 Pixmap *pm;
1516 Atom actual_type;
1517 int format;
1518 unsigned long nitems;
1519 unsigned long bytes_after;
1520
1521 /* intern the property name */
1522 Atom atom = XInternAtom(dpy, RETAIN_PROP_NAME, 0);
1523
1524 /* look for existing resource allocation */
1525 if ((XGetWindowProperty(dpy, w, atom, 0, 1, 1 /*delete*/,
1526 AnyPropertyType, &actual_type,
1527 &format, &nitems, &bytes_after,
1528 (unsigned char **) &pm) == Success) &&
1529 (nitems == 1))
{
1530 if ((actual_type == XA_PIXMAP) && (format == 32) &&
1531 (nitems == 1) && (bytes_after == 0))
1532 {
1533 /* blast it away, but first provide new X error handler in case
1534* the client that installed the RETAIN_PROP_NAME (_XSETROOT_ID)
1535* property on the root window has already terminated
1536*/
1537 orig_error_handler = XSetErrorHandler(xkill_handler);
1538 XKillClient(dpy, (XID) *pm);
1539 XSync(dpy, False);
1540 XSetErrorHandler(orig_error_handler);
1541 XFree((void *) pm);
1542 }
1543 else if (actual_type != None)
1544 {
1545 fprintf(stderr,
1546 "%s: warning: invalid format encountered for property
%s\n",
1547 RETAIN_PROP_NAME, progname);
1548 }
}
1549 }
I guess it's impossible to say for sure,
without knowing the whole of the code,
but, judging by the identation, this
was probably the intended logic.
Can somebody confirm this.
Thanks
Anton
___
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: do I need to specify explicity what to install for make install to work?
On Wed, Sep 26, 2012 at 03:12:39PM +0100, Anton Shterenlikht wrote:
> From m.sea...@infracaninophile.co.uk Wed Sep 26 14:21:51 2012
>
> On 26/09/2012 13:06, Anton Shterenlikht wrote:
> > I was updating my port until I got to
> >
> > make: don't know how to make install. Stop
> > *** [do-install] Error code 2
> >
> > and I realised that I don't really understand
> > the sequence of commands involved in "make install".
> > I've looked through the porter's handbook,
> > but still not clear.
> >
> > I see lots of post-install targets in
> > Makefiles, but never just "install".
> > I presume it should be pulled into by
> > .include
> >
> > Still, if I have a set of source files,
> > generated object files, and just one
> > executable I want to install, I probably
> > have to specify somewhere in the Makefile
> > the name of this executable, right?
> >
> > Or are PLIST_FILES and PLIST_DIRS used
> > to let make know what to install?
>
> The ports 'make install' generally does one of two things: either it
> runs appropriate make install commands from $WRKDIR -- ie. what the
> ported software provides itself -- or it has a list of files,
> directories etc. from within $WRKDIR which it copies into place itself,
> which is usually only done if the ported software doesn't provide its
> own installation routines. As I recall, if you don't provide an
> explicit install target yourself, the default is to run 'make install'
> from $WRKDIR.
>
> PLIST_FILES, PLIST_DOCS or the pkg-plist file don't tell the ports what
> to install. Instead, they document what the installation process should
> be installing, and so what files to include in a pkg tarball and what to
> delete at pkg deinstallation time. Hence the effort required to make
> sure your plist is accurate.
>
> Ok, I think I get it.
> All I need is the install target
> in $WRKDIR/Makefile.
> If I make this target empty, then
> I can add the real install commands
> under post-install in the port's
> Makefile.
>
> However, it seems if there is no
> install target in $WRKDIR/Makefile,
> then I must add install target to
> port's Makefile.
Actually, since the "install" target in bsd.port.mk does a lot of other
things (generating/handling package lists, registering the package
installation, etc), what you need to override is the "do-install"
target (in the port's Makefile). For the upstream's Makefile (the one
in $WRKSRC) it is the "install" target that is looked for.
This is true for almost all of the "high-level" bsd.port.mk targets (the
ones that the user invokes with "make" in the port's directory) -
bsd.port.mk does some magic, determines whether anything needs to be
done at all, and if there is indeed a need to do something, it invokes
the "do-*" target. Thus, if bsd.port.mk determines that it needs to
fetch an upstream tarball, it will invoke the "do-fetch" target that, by
default, tries to fetch ${DISTFILES} from ${MASTER_SITE} and so on. If
it determines that it needs to build a program, it invokes the
"do-build" target that, by default, goes into ${WRKSRC} and does "make
all" (but of course, you can also override the "all" part using another
variable). For the "install" target, if bsd.port.mk determines that it
needs to install the already-built-in-${WRKSRC} files to ${PREFIX}, it
will invoke "do-install"; if you don't override do-install, it will
change into ${WRKSRC} and run "make install" - and then it will go on
with the rest of what the "install" bsd.port.mk target does.
In general, you don't really need to do this very often - most of what
you might need to do in the do-* targets is already configurable by
other variables. I guess that's why nobody felt the need to document
this in the Porter's Handbook so far :)
G'luck,
Peter
--
Peter Pentchev r...@ringlet.net r...@freebsd.org pe...@packetscale.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
.siht ekil ti gnidaer eb d'uoy ,werbeH ni erew ecnetnes siht fI
signature.asc
Description: Digital signature
Re: Failed upgrade sudo-1.8.5.p3 to sudo-1.8.6.p3 running stable/9
On Wed, Sep 26, 2012 at 02:05:57PM -0700, David Wolfskill wrote: > On Wed, Sep 26, 2012 at 04:59:28PM -0400, Wesley Shields wrote: > > On Wed, Sep 26, 2012 at 04:43:57AM -0700, David Wolfskill wrote: > > > This is a FreeBSD/i386 stable/9 system: > > > > > > FreeBSD freebeast.catwhisker.org 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE > > > #485 240956M: Wed Sep 26 04:19:48 PDT 2012 > > > r...@freebeast.catwhisker.org:/usr/obj/usr/src/sys/GENERIC i386 > > > > > > built with clang, but cc is gcc: > > > > This is a failure on i386 only, which is why I didn't notice it. Would > > you apply the patch available at [1] and let me know if it works. It > > does build for me now that I built up a i386 environment. > > > > [1]: http://people.freebsd.org/~wxs/sudo-ssp.diff > > > > Aye; builds & a trivial test: > > d134(9.1-P)[1] sudo id > Password: > uid=0(root) gid=0(wheel) groups=0(wheel),5(operator) > d134(9.1-P)[2] > > works. :-} My original patch did not build correctly with clang. I've just committed r304961 which works on both i386 and under clang. -- WXS ___ 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: clang dangling else help
On 2012-09-27 14:16, Anton Shterenlikht wrote:
Building my port with clang I get this warning
(gcc doesn't pick this up):
x11.c:1543:5: warning: add explicit braces to avoid dangling else
[-Wdangling-else]
else if (actual_type != None)
^
1 warning generated.
If the warning isn't fatal (e.g. you are not using -Werror), and you
know the code is right, you could just ignore the warning. Or are you
trying to make it warning-free?
I think I understand what's going on,
but wanted somebody to double check.
This is the relevant fragment:
1511 static void freePrevious(dpy, w)
1512 Display *dpy;
1513 Window w;
1514 {
1515 Pixmap *pm;
1516 Atom actual_type;
1517 int format;
1518 unsigned long nitems;
1519 unsigned long bytes_after;
1520
1521 /* intern the property name */
1522 Atom atom = XInternAtom(dpy, RETAIN_PROP_NAME, 0);
1523
1524 /* look for existing resource allocation */
1525 if ((XGetWindowProperty(dpy, w, atom, 0, 1, 1 /*delete*/,
1526 AnyPropertyType, &actual_type,
1527 &format, &nitems, &bytes_after,
1528 (unsigned char **) &pm) == Success) &&
1529 (nitems == 1))
1530 if ((actual_type == XA_PIXMAP) && (format == 32) &&
1531 (nitems == 1) && (bytes_after == 0))
1532 {
1533 /* blast it away, but first provide new X error handler in case
1534* the client that installed the RETAIN_PROP_NAME (_XSETROOT_ID)
1535* property on the root window has already terminated
1536*/
1537 orig_error_handler = XSetErrorHandler(xkill_handler);
1538 XKillClient(dpy, (XID) *pm);
1539 XSync(dpy, False);
1540 XSetErrorHandler(orig_error_handler);
1541 XFree((void *) pm);
1542 }
1543 else if (actual_type != None)
1544 {
1545 fprintf(stderr,
1546 "%s: warning: invalid format encountered for property
%s\n",
1547 RETAIN_PROP_NAME, progname);
1548 }
1549 }
I think, to preserve the logic, this should be changed to:
1511 static void freePrevious(dpy, w)
1512 Display *dpy;
1513 Window w;
1514 {
1515 Pixmap *pm;
1516 Atom actual_type;
1517 int format;
1518 unsigned long nitems;
1519 unsigned long bytes_after;
1520
1521 /* intern the property name */
1522 Atom atom = XInternAtom(dpy, RETAIN_PROP_NAME, 0);
1523
1524 /* look for existing resource allocation */
1525 if ((XGetWindowProperty(dpy, w, atom, 0, 1, 1 /*delete*/,
1526 AnyPropertyType, &actual_type,
1527 &format, &nitems, &bytes_after,
1528 (unsigned char **) &pm) == Success) &&
1529 (nitems == 1))
{
1530 if ((actual_type == XA_PIXMAP) && (format == 32) &&
1531 (nitems == 1) && (bytes_after == 0))
1532 {
1533 /* blast it away, but first provide new X error handler in case
1534* the client that installed the RETAIN_PROP_NAME (_XSETROOT_ID)
1535* property on the root window has already terminated
1536*/
1537 orig_error_handler = XSetErrorHandler(xkill_handler);
1538 XKillClient(dpy, (XID) *pm);
1539 XSync(dpy, False);
1540 XSetErrorHandler(orig_error_handler);
1541 XFree((void *) pm);
1542 }
1543 else if (actual_type != None)
1544 {
1545 fprintf(stderr,
1546 "%s: warning: invalid format encountered for property
%s\n",
1547 RETAIN_PROP_NAME, progname);
1548 }
}
1549 }
Yes, this is precisely what clang means, though the diagnostic can be a
bit confusing. It tells you the else in line 1543 is ambiguous, since
some people might be tempted to believe it belongs to the first if(),
instead of the second one. In fact, even my auto-indenting editor also
got it wrong at first. :)
Simplified, this example becomes:
void foo(int i, int j, int k)
{
if (i)
if (j)
{
bar();
}
else if (k)
{
baz();
}
}
So clang is suggesting to change that to:
void foo(int i, int j, int k)
{
if (i)
{
if (j)
{
bar();
}
else if (k)
{
baz();
}
}
}
In my opinion the diagnostic could be more helpful though, and point you
at the if() statements that needed additional braces.
In this case, gcc 4.8 is indeed more helpful:
dangling.c: In function 'foo':
dangling.c:6:6: warning: suggest explicit braces to avoid ambiguous 'else'
[-Wparentheses]
if (i)
^
___
Re: CFT: x11/nvidia-driver major update to 304.xx series
2012/9/26 Lawrence K. Chen, P.Eng. : > So, now that its in the wild...I upgraded...and it broke my dual monitor > desktop (at work). Seems like gdm/gnome can't see the other monitor. Tried > rebuilding a bunch of other things, but didn't help. Reverting to previous > (295.71) has things working again. Wonder what people will do for > portdowngrade when CVS goes away. Are you setting the dual screen up in /etc/X11/xorg.conf, at home and at work ? Is yes, how ? With last nvidia drivers you can use xrandr instead of twinview. -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org- against HTML email & vCards X www: http://www.gid0.org- against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." ___ 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: x11/Terminal - why not xfce4-terminal
Le 26/09/2012 14:10, Olivier Duchateau a écrit : 2012/9/26 Florent Peterschmitt: Le 26/09/2012 12:26, Sergey V. Dyatko a écrit : On Wed, 26 Sep 2012 14:17:57 + Florent Peterschmitt wrote: Hello, Why the terminal emulator from XFCE4 is called Terminal instead of xfce4-terminal ? http://goodies.xfce.org/projects/applications/terminal Ok, then next question. Why xfce apps are not under un sub-directory called xfce (or xfce4 if versionning becomes important) ? What do you mean by « Why xfce apps are not under un sub-directory called xfce » ? Have something like /usr/ports/xfce/ ? ___ 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: clang dangling else help
From: Dimitry Andric On 2012-09-27 14:16, Anton Shterenlikht wrote: > Building my port with clang I get this warning > (gcc doesn't pick this up): > > x11.c:1543:5: warning: add explicit braces to avoid dangling else [-Wdangling-else] > else if (actual_type != None) > ^ > 1 warning generated. If the warning isn't fatal (e.g. you are not using -Werror), and you know the code is right, you could just ignore the warning. Or are you trying to make it warning-free? Yes, would be good to have no warnings. Anyway, this particular one is really worth fixing. Thanks for the clarification. Anton ___ 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"
redports: USA_RESIDENT=YES ?
What is the meaning of USA_RESIDENT=YES in redports build logs? Anton ___ 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: redports: USA_RESIDENT=YES ?
On 27 Sep 2012 16:29, "Anton Shterenlikht" wrote: > > What is the meaning of USA_RESIDENT=YES in redports build logs? > The US government considers cryptography a weapon, so exporting it is technically an offence. Therefore, a declaration that you're a US resident is required for strong cryptography, since the rest of the world is full of terrorists and whatnot. Chris ___ 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: FreeBSD Port: fusefs-encfs-1.7.4_1
On Wed, Sep 26, 2012 at 5:42 PM, Joseph Mingrone wrote: > Hello; > > I have been using encfs successfully for many months. > > % encfs ~/.crypt ~/files/crypt > > Today, I tried to mount the same way as usual. My password was > accepted, but the directory ~/files/crypt disappeared after the mount. > That is, before the command above I see the ~/files/crypt directory, > but after it doesn't show up with an ls -la. However, when I do ls > ~/files/crypt I see the message "ls: crypt: Bad file descriptor". The > ~/.crypt directory seems unchanged. The only thing I can think of > that might have changed in the past few days: I may have updated a > dependent port (e.g. /deve/icu). I'm running 9-STABLE amd64 with port > version 1.7.4_1. > It looks like encfs is crashing. % encfs -d /usr/home/jrm/.crypt /usr/home/jrm/files/crypt EncFS Password: FUSE library version: 2.9.1 nullpath_ok: 0 nopath: 0 utime_omit_ok: 0 unique: 0, opcode: INIT (26), nodeid: 0, insize: 56, pid: 1426 INIT: 7.19 flags=0x max_readahead=0x INIT: 7.19 flags=0x0011 max_readahead=0x max_write=0x0002 max_background=0 congestion_threshold=0 NOTIFY: code=0 length=40 unique: 0, opcode: GETATTR (3), nodeid: 1, insize: 40, pid: 1431 fgetattr[0] / zsh: segmentation fault (core dumped) encfs -d /usr/home/jrm/.crypt /usr/home/jrm/files/crypt ___ 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: Quick status update on Squid 3.x ports
On Thu, Sep 27, 2012 at 12:07 AM, Ruslan Mahmatkhanov wrote:
> First thank you for working on this. According to squid web-page, 3.2 is
> the only stable version ("Current versions suitable for production use."),
> that is actively maintained. 3.1 and less are listed in "Old versions -
> Provided for archival purposes only. Not intended for general use in new
> installations". Is there still 2.7 users?! As for me, 3.2 should go to
> www/squid and some kind of exp-run should be done to make sure the ports
> depending on it builds fine.
>
>
There are bound to be at least some 2.7 users who are waiting for all 2.7's
features to be implemented in the 3.x branch. e.g. an equivalent of
url_rewrite_program doesn't exist in pre-3.2.
Anton
___
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: x11/Terminal - why not xfce4-terminal
On Thu, 27 Sep 2012 17:21:30 + Florent Peterschmitt wrote: > Le 26/09/2012 14:10, Olivier Duchateau a écrit : > > 2012/9/26 Florent Peterschmitt: > >> Le 26/09/2012 12:26, Sergey V. Dyatko a écrit : > >> > >>> On Wed, 26 Sep 2012 14:17:57 + > >>> Florent Peterschmitt wrote: > >>> > Hello, > > Why the terminal emulator from XFCE4 is called Terminal instead of > xfce4-terminal ? > >>> http://goodies.xfce.org/projects/applications/terminal > >>> > >>> > >>> > >> Ok, then next question. Why xfce apps are not under un sub-directory called > >> xfce (or xfce4 if versionning becomes important) ? > >> > > What do you mean by « Why xfce apps are not under un sub-directory > > called xfce » ? > > > > > > > Have something like /usr/ports/xfce/ ? There's meta-port calls, x11-wm/xfce4. But if you want to known where're Xfce applications, try: for file in `find /usr/ports -name 'Makefile' -type f`; do grep SITE_XFCE file && echo `basename $file`; done www/midori is hosted by Xfce project, but it doesn't need Xfce related stuff to work. -- olivier ___ 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: CFT: x11/nvidia-driver major update to 304.xx series
- Original Message - > 2012/9/26 Lawrence K. Chen, P.Eng. : > > So, now that its in the wild...I upgraded...and it broke my dual > > monitor desktop (at work). Seems like gdm/gnome can't see the > > other monitor. Tried rebuilding a bunch of other things, but > > didn't help. Reverting to previous (295.71) has things working > > again. Wonder what people will do for portdowngrade when CVS goes > > away. > > Are you setting the dual screen up in /etc/X11/xorg.conf, at home and > at work ? Is yes, how ? With last nvidia drivers you can use xrandr > instead of twinview. > dual screen in /etc/X11/xorg.conf using Xineramaconfigs are the same (except for hardware) at home and at work. Got things working at home first, and followed that to get it working at work. -- Who: Lawrence K. Chen, P.Eng. - W0LKC - Senior Unix Systems Administrator For: Enterprise Server Technologies (EST) -- & SafeZone Ally Snail: Computing and Telecommunications Services (CTS) Kansas State University, 109 East Stadium, Manhattan, KS 66506-3102 Phone: (785) 532-4916 - Fax: (785) 532-3515 - Email: lkc...@ksu.edu Web: http://www-personal.ksu.edu/~lkchen - Where: 11 Hale Library ___ 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: x11/Terminal - why not xfce4-terminal
On 27 September 2012 13:21, Florent Peterschmitt wrote: > Le 26/09/2012 14:10, Olivier Duchateau a écrit : > >> 2012/9/26 Florent Peterschmitt: >>> >>> Le 26/09/2012 12:26, Sergey V. Dyatko a écrit : >>> On Wed, 26 Sep 2012 14:17:57 + Florent Peterschmitt wrote: > Hello, > > Why the terminal emulator from XFCE4 is called Terminal instead of > xfce4-terminal ? http://goodies.xfce.org/projects/applications/terminal >>> Ok, then next question. Why xfce apps are not under un sub-directory >>> called >>> xfce (or xfce4 if versionning becomes important) ? >>> >> What do you mean by « Why xfce apps are not under un sub-directory >> called xfce » ? >> >> >> > Have something like /usr/ports/xfce/ ? symports will create one for you: it adds symbolic links for virtual categories. -- Eitan Adler ___ 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: redports - should I rename the updated distfile (tarball)?
On Thu, Sep 27, 2012 at 12:55:51PM +0100, Anton Shterenlikht wrote: > redports.org is good, thank you to whoever worked on it. > > One question: the upstream for my port is non-existent, > so rather then patch it, I'm updating the code itself. > I then create a new tarball. It seems redports doesn't > update the tarball every time I request a build. > So it seems I have to update the version in Makefile > each time and create a tarball with this new number. > Is that so? I can't comment on the relation of this to redports as I've never used it myself. I can state that if you're modifying the source and creating a new tarball you should bump the PORTVERSION in the port (and consequently in your distfile too) and also make sure distinfo is correct. This will help to distinguish your changed tarball from the original. -- WXS ___ 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: redports - should I rename the updated distfile (tarball)?
On Do., 27. Sep. 2012 13:55:51 CEST, Anton Shterenlikht wrote: > redports.org is good, thank you to whoever worked on it. You're welcome. > One question: the upstream for my port is non-existent, > so rather then patch it, I'm updating the code itself. > I then create a new tarball. It seems redports doesn't > update the tarball every time I request a build. > So it seems I have to update the version in Makefile > each time and create a tarball with this new number. > Is that so? Redports uses a distfile cache so it only tries to download the distfile if it's not in the cache of that build machine yet. You could try to check bsd.ports.mk if there is a target that you can overwrite in your port where it does the distfile check. -- http://www.bluelife.at/ ___ 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: aspell conflicts with ispell?
I think aspell does not conflict with ispell; they have no common files. Is it any problem with ispell when running or building aspell ? BTW, textproc/ispell does not have "CONFLICTS" entry... it is confusing. --- Tsurutani Naoki turut...@scphys.kyoto-u.ac.jp ___ 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: aspell conflicts with ispell?
On Thu, Sep 27, 2012 at 6:17 PM, Tsurutani Naoki wrote: > I think aspell does not conflict with ispell; they have no common files. > Is it any problem with ispell when running or building aspell ? > > BTW, textproc/ispell does not have "CONFLICTS" entry... it is confusing. I suspect it is bogus unless the Install the ispell wrapper is selected. If so, it installs it's own /usr/local/bin/ispell, a definite conflict. I don't know how good the ispell emulation is, but it MIGHT replace the separate ispell port. In any case, if you don't have the ispell wrapper selected, than there should be no conflict. It looks like that was intended since there are two CONFLICTS statements. the first is unconditional and I suspect should have been removed. The second is conditional on hte ispell wrapper being selected. I'd just comment out the first CONFLICTS line in the Makefile and request that the Makefile be corrected. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.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: aspell conflicts with ispell?
On 27 September 2012 22:52, Kevin Oberman wrote: > In any case, if you don't have the ispell wrapper selected, than there > should be no conflict. It looks like that was intended since there are > two CONFLICTS statements. the first is unconditional and I suspect > should have been removed. The second is conditional on hte ispell > wrapper being selected. I'd just comment out the first CONFLICTS line > in the Makefile and request that the Makefile be corrected. On a quick look, this seems correct. Please file a PR so it doesn't get lost! -- Eitan Adler ___ 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: aspell conflicts with ispell?
On Thu, Sep 27, 2012 at 8:39 PM, Eitan Adler wrote: > On 27 September 2012 22:52, Kevin Oberman wrote: >> In any case, if you don't have the ispell wrapper selected, than there >> should be no conflict. It looks like that was intended since there are >> two CONFLICTS statements. the first is unconditional and I suspect >> should have been removed. The second is conditional on hte ispell >> wrapper being selected. I'd just comment out the first CONFLICTS line >> in the Makefile and request that the Makefile be corrected. > > On a quick look, this seems correct. Please file a PR so it doesn't get lost! Wow! Sounds exactly like one of my responses. PR ports/172131. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.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"
