Re: xlockmore-5.29: "BadWindow (invalid Window parameter)" using virtual wm

[Marius Nünnerich]

Hi David,

On Sun, Oct 11, 2009 at 20:54, David Wolfskill  wrote:
> This is running FreeBSD 6.4-STABLE r197725; I'm in the habit of
> updating installed ports on my laptop daily (after updating the
> stable/6 slice).
>
> The xlockmore port is at 5.29, updating 01 Oct 2009.
>
> I normally use the piewm Window Manager (I got used to tvtwm back in
> '93, and piewm is based on it and is very similar).
>
> If I try to issue "xlock -mode random" using either piewm or tvtwm, I
> now get:
>
> X Error of failed request:  BadWindow (invalid Window parameter)
>  Major opcode of failed request:  3 (X_GetWindowAttributes)
>  Resource id in failed request:  0x45
>  Serial number of failed request:  82
>  Current serial number in output stream:  83
>
> If I exit either of those Window Managers and fire up twm, xlock does
> not issue that message, and seems to run normally (at least in most
> modes).
>
> I believe that this change in behavior coincided with the update to
> xlockmore (01 Oct); I didn't mention it earlier because something odd
> also appears to have happened with DRI support recently, and I wasn't
> clear enough on the interrelationships to be reasonably confident that I
> was reporting things properly.
>
> I also run stable/7 and head slices (each with the misc/compat6x port
> installed, so I'm using a shared /usr/local among all slices).
> xlockmore appears to run OK in 7.2-STABLE r197901 and head r197928,
> though I'm unable to run X with DRI enabled in those environments.
>
> In checking the Net for other reports of similarissues, I see that
> xlockmore has had issues in the past with virtual window managers (ref.
> , from Thu, 19
> May 2005 11:18:03 UTC).
>
> Would it make more sense (for getting the issue resolved) for me to try
> reverting xlockmore to the previous version or some other approach?
> While I'm OK hacking code, I certainly don't claim much in-depth
> understanding of much X-related code; on the other hand, I do have local
> mirrors of the FreeBSD CVS & SVN repositories handy.
>
> Thanks!
>
> Peace,
> david
> --
> David H. Wolfskill                              da...@catwhisker.org
> Depriving a girl or boy of an opportunity for education is evil.
>
> See http://www.catwhisker.org/~david/publickey.gpg for my public key.
>

Could you please write to David A. Bagley  and
explain this problem to him? He is the current maintainer of
xlockmore.
___
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"

bsd.python.mk broken

[Dominic Fandrey]

If one uses the OPTIONS framework like in graphics/opencv
to trigger python support, bsd.python.mk breaks. Here is why:

USE_PYTHON has to be set before including bsd.port.pre.mk

Unfortunately it can only be set after bsd.port.pre.mk, because
WITH_PYTHON wouldn't be set before.

For this the _POSTMKINCLUDED variable is responsible. The
following is from the beginning of bsd.python.mk:#
.if !defined(_POSTMKINCLUDED) && !defined(Python_Pre_Include)

It looks similar for bsd.perl.mk, so maybe the problem
exists there as well. bsd.php.mk or bsd.java.mk are different:
.if !defined(Java_Include)

I suggest removing the !defined(_POSTMKINCLUDED) from both
bsd.python.mk and bsd.perl.mk.
___
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"

xlockmore-5.29: "BadWindow (invalid Window parameter)" using virtual wm

[David Wolfskill]

This is running FreeBSD 6.4-STABLE r197725; I'm in the habit of
updating installed ports on my laptop daily (after updating the
stable/6 slice).

The xlockmore port is at 5.29, updating 01 Oct 2009.

I normally use the piewm Window Manager (I got used to tvtwm back in
'93, and piewm is based on it and is very similar).

If I try to issue "xlock -mode random" using either piewm or tvtwm, I
now get:

X Error of failed request:  BadWindow (invalid Window parameter)
  Major opcode of failed request:  3 (X_GetWindowAttributes)
  Resource id in failed request:  0x45
  Serial number of failed request:  82
  Current serial number in output stream:  83

If I exit either of those Window Managers and fire up twm, xlock does
not issue that message, and seems to run normally (at least in most
modes).

I believe that this change in behavior coincided with the update to
xlockmore (01 Oct); I didn't mention it earlier because something odd
also appears to have happened with DRI support recently, and I wasn't
clear enough on the interrelationships to be reasonably confident that I
was reporting things properly.

I also run stable/7 and head slices (each with the misc/compat6x port
installed, so I'm using a shared /usr/local among all slices).
xlockmore appears to run OK in 7.2-STABLE r197901 and head r197928,
though I'm unable to run X with DRI enabled in those environments.

In checking the Net for other reports of similarissues, I see that
xlockmore has had issues in the past with virtual window managers (ref.
, from Thu, 19
May 2005 11:18:03 UTC).

Would it make more sense (for getting the issue resolved) for me to try
reverting xlockmore to the previous version or some other approach?
While I'm OK hacking code, I certainly don't claim much in-depth
understanding of much X-related code; on the other hand, I do have local
mirrors of the FreeBSD CVS & SVN repositories handy.

Thanks!

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Depriving a girl or boy of an opportunity for education is evil.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


pgpOIt6hMWDO2.pgp
Description: PGP signature

Re: dkimproxy rc script

[RW]

On Sun, 11 Oct 2009 15:02:18 +0200
ML  wrote:

> Hello,
> 
> currently dkimproxy rc scripts don’t handle the status rc command
> 

Status doesn't usually need any special handling unless it's something
a little more exotic like multiple daemons; it should "just work",
provided run_rc_command can find the pidfile.

I'm not familiar with dkimproxy, but based on your script below my guess
is that the variable dkimproxy_out_pidfile should simply be renamed to
pidfile.

> my hack is the following ("old school" script, I don’t know enough  
> about rc command deeps to make things nicer)
> 
> # at the end of rc.d/dkimproxy_out replace
> 
>  run_rc_command "$1"
> 
> # by the following
> 
>   case $1 in
>   status)
>   if /usr/bin/pgrep -F
> "${dkimproxy_out_pidfile}" > / dev/null 2>&1; then
>   echo "${name} is running"
>   exit 0;
>   else
>   echo "${name} is not running"
>   exit 1
>   fi
>   ;;
>   *)
>   run_rc_command "$1"
>   ;;
>   esac
> 
> 
> Hope this help.___
> 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"

[patch] typo in portaudit - fails with latest /bin/sh

[Stefan Hegnauer]

Hi,

portaudit (/usr/ports/ports-mgmt/portaudit) did not work anymore on a recent
build of FreeBSD 9.0-CURRENT #0 as of Fri Oct  9 09:27:54 CEST 2009.

As it turns out there seems to be a typo in the portaudit script which
manifests itself since the changes applied to /bin/sh in
http://svn.freebsd.org/viewvc/base?view=revision&sortby=date&revision=197691

The following patch cures this typo:

--- /usr/local/sbin/portaudit.orig   2009-10-09 12:36:10.0 +0200
+++ /usr/local/sbin/portaudit   2009-10-09 12:39:11.0 +0200
@@ -264,7 +264,7 @@
return 2
fi

-   PKGNAME=`make -VPKGNAME 2>/dev/null || true"`
+   PKGNAME=`make -VPKGNAME 2>/dev/null || true`

if [ -z "$PKGNAME" ]; then
echo "portaudit: Can't determine the package name" >&2


If somebody (e...@freebsd.org ?) could merge this in, please ...

--SH

___
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: Enforcing library version in a port Makefile?

[Alex Stangl]

On Sun, Oct 11, 2009 at 05:15:58AM +, b. f. wrote:
> Alex Stangl wrote:
> >I am trying to create a new port. The software I am trying to port uses
> >scons which calls out to pkg-config to check for certain minimal library
> >version #s (e.g., sndfile >= 1.0.18, libcurl >= 7).
> 
> >I would like to enforce these same checks upfront in the Makefile rather
> >than letting the build potentially blow up in scons. Section 5.7.8 of the
> >Porter's Handbook says that all of the _DEPENDS variables *except
> >LIB_DEPENDS* can enforce minimal dependency versions. It's not clear why
> >LIB_DEPENDS is excluded here, or what the correct alternative approach
> >is. It doesn't seem like putting LIB_DEPENDS= curl.5 is equivalent to
> >libcurl >= 7. Hopefully there's a straightforward way to accomplish
> >this, without having to patch or scrap the scons config file.
> >Unfortunately I have not been able to find the answers from
> >searching the net, so I hope somebody here can help.
> 
> It's not enforced in quite the same way, but there is a check on the
> version of the library if you specify it, only the check is for an
> exact match, not an inequality.  You can see the precise means by
> which this is accomplished by looking at the lib-depends target in
> /usr/ports/Mk/bsd.port.mk   (beginning on line 5102 of version 1.629
> of this file).  For example,
> 
 
>
> /sbin/ldconfig  -r | /usr/bin/grep -vwF -e "/usr/local/lib/compat/pkg"
> | /usr/bin/grep -wE -e "-lblas\\.2"
> 
> which is version-specific.  Probably an inequality check was not
> implemented because libraries with different major versions are
> expected to have different and incompatible ABI/APIs.  The
> corresponding version numbers of the port as a whole are not usually
> relevant for LIB_DEPENDS, only the version of the shared library
> itself, as the upstream maintainers are supposed to change a shared
> library version if and only if they change the API/ABI of the library.

It seems like there are 2 numbering schemes for shared libraries:

1. Version stored in /usr/local/libdata/pkgconfig/*.pc (same as
PORTVERSION?)

2. Major version number stored as part of the library filename.

I realized I could check for exact match for #2 (mentioned LIB_DEPENDS=
curl.5 in my message), however I would like to ideally check for #1
since that's what the scons config seems to be looking at.

It seems like checking #2 is only a rough proxy for #1 and is likely to
make for a fragile port. For instance, say scons config is checking
for >= X.Y in scheme #1, but all I can do is put a check
for M in scheme #2. Then we have these problematic scenarios:

1. If there are versions of the lib.M that have version #s in scheme #1
less than X.Y, then the build will fail in scons, leaving the user
confused and unhappy.

2. If user upgrades ports and gets lib.M+1, make fails because the exact
match is no longer satisfied. (Porter's Handbook says you can use
LIB_DEPENDS regular expressions like curl.[5-9] so this shouldn't be as
much of a problem, at least not until it breaks years later on curl.10)



>  If you are relying upon some feature of a port that may change while
> it's relevant shared library versions remain the same, then you should
> add the port to the other *_DEPENDS as needed, with appropriate checks
> on the port version number in those variables.

I suspect this is what I shall have to do. Is this what all other port
authors do in similar circumstances? It seems kind of a hackish
workaround, especially if the library in question doesn't have a
corresponding executable to list in RUN_DEPENDS. Do I force a library
name into RUN_DEPENDS?

It would be nice to be able to express the real dependency as precisely
and accurately as possible, say I want >= X.Y (in numbering scheme Z) of
this library, rather than have to obfuscate intent by using some proxy.

Thanks for the response!

Alex
___
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"

pecl ports bumping when php5 updated

[ML]

Hello,

Is it possible to bump pecl ports when php(4|5|6) version change ?
Most of the time PHP new version implies pecl rebuilt, or you face  
segfault and other strange stuffs.
I know ports maintainers are several, but if this can be done at some  
point of the process… would be great for all of us, IMHO.


My 2cts.___
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"

dkimproxy rc script

[ML]

Hello,

currently dkimproxy rc scripts don’t handle the status rc command

my hack is the following ("old school" script, I don’t know enough  
about rc command deeps to make things nicer)


# at the end of rc.d/dkimproxy_out replace

run_rc_command "$1"

# by the following

case $1 in
status)
	if /usr/bin/pgrep -F "${dkimproxy_out_pidfile}" > / 
dev/null 2>&1; then

echo "${name} is running"
exit 0;
else
echo "${name} is not running"
exit 1
fi
;;
*)
run_rc_command "$1"
;;
esac


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

[patch] USB video support in KDE4 + sane + more under FreeBSD

[Hans Petter Selasky]

Hi,

I was compiling the latest version of KDE4 on my box and I noticed it picked up 
my installed libv4l2. 
The only problem is that you need some patches before everything is compiling 
:-)

About libv4lX on FreeBSD, please see:

http://lists.freebsd.org/pipermail/freebsd-emulation/2009-June/006231.html

Only USB webcams supported yet.

After installation manually add -lv4lxdrivers to all the libv4l*.pc files!
I will try to get this included into my ulinux distribution soon.

Before:
Libs: -L${libdir} -lv4lconvert
After:
Libs: -L${libdir} -lv4lconvert -lv4lxdrivers

/usr/local/lib/pkgconfig/libv4lconvert.pc
/usr/local/lib/pkgconfig/libv4l2.pc
/usr/local/lib/pkgconfig/libv4l1.pc

Then patch KDE4 like this:

--- 
/usr/ports/net/kdenetwork4/work/kdenetwork-4.3.1/kopete/libkopete/avdevice/videodevice.h.orig
   2009-10-11 11:41:54.0 +0200
+++ 
/usr/ports/net/kdenetwork4/work/kdenetwork-4.3.1/kopete/libkopete/avdevice/videodevice.h
2009-10-11 11:44:34.0 +0200
@@ -62,6 +62,13 @@
 
 #endif // __linux__
 
+#if defined(__FreeBSD__) && defined(ENABLE_AV)
+#include 
+#ifdef HAVE_LIBV4L2
+#include 
+#endif // HAVE_V4L2
+#endif
+
 #include 
 #include 
 #include http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Checking for parity of ports conflicts

[Eitan Adler]

http://isis.poly.edu/~eitan/files/conflict-partity.sh

Is a simple script which checks to make sure that when port A
conflicts with port B the reverse is also true.
It is not entirely accurate. Any improvements are welcome.
___
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"