Re: Unable to run program linked statically against GnuTLS on OpenBSD 5.8.
Op maandag 12 oktober 2015 22:38:46 schreef Jack J. Woehr: > Remco wrote: > > I have a static binary linked against GnuTLS > > Thread-local storage is not, I believe, currently supported in OpenBSD. You're confusing me, statically linking against GnuTLS seemed to work fine on OpenBSD 5.7. You're not misinterpreting the meaning of GnuTLS "The GnuTLS Transport Layer Security Library", are you ?
KDE4's konsole appears to go in an endless loop when piping through more/less.
After an upgrade to OpenBSD 5.8 the konsole application in KDE4 starts taking 100% cpu when piping somethine through more/less, e.g.: $ getent passwd |less I got some very basic output by running konsole as follows (from another konsole window): $ konsole > /tmp/konsole.log 2>&1 The logged information looks like: konsole:/usr/lib/libstdc++.so.57.0: /usr/local/lib/libestdc++.so.17.0 : WARNING: symbol(_ZN11__gnu_debug17_S_debug_messagesE) size mismatch, relink your program QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave. QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave. konsole(21654) OpenBSDProcessInfo::readProcArgs: sysctl() call failed with code 3 konsole(21654) OpenBSDProcessInfo::readCurrentDir: sysctl() call failed with code 3 konsole(21654) OpenBSDProcessInfo::readProcArgs: sysctl() call failed with code 3 konsole(21654) OpenBSDProcessInfo::readCurrentDir: sysctl() call failed with code 3 konsole(21654) OpenBSDProcessInfo::readProcArgs: sysctl() call failed with code 3 konsole(21654) OpenBSDProcessInfo::readCurrentDir: sysctl() call failed with code 3 with the last two messages appearing to repeat endlessly. The looping konsole can still be "stopped" by closing it's window. After some time a popup will appear saying something along the lines of "the application doesn't respond" giving the option to terminate it.
Unable to run program linked statically against GnuTLS on OpenBSD 5.8.
I have a static binary linked against GnuTLS, o.a., that fails to run when
built on OpenBSD 5.8. The program appears to crash even before it's able to
start.
I run:
OpenBSD 5.8-current (GENERIC.MP) #0: Fri Oct 9 18:37:33 CEST 2015
re...@ws0001.home.lan:/usr/src/sys/arch/amd64/compile/GENERIC.MP
(built from src.tar.gz of the OpenBSD 5.8 CD with patches 001, 002, 003 and
004 applied)
Since linking GnuTLS is optional for my program I decided to leave it out and
the problem went away. No other libraries appear to cause problems.
To demonstrate the problem I tried to create a program, as small as possible,
statically linked against GnuTLS that shows the failure. I used the following
source/Makefile file, and include some basic output of building/running the
program.
*) source file static_test.c:
#include
int
main(int argc, char **argv)
{
gnutls_global_init();
gnutls_global_deinit();
return (0);
}
*) Makefile:
CFLAGS+=-I/usr/local/include
LDFLAGS+= -L/usr/local/lib
LDADD+= -static
LDADD+= -lgnutls
LDADD+= -liconv -lintl -lz
LDADD+= -lp11-kit -lffi
LDADD+= -ltasn1 -lnettle -lhogweed -lgmp
LDADD+= -lpthread
PROG= static_test
NOMAN=
.include
*) creating it with 'make':
$ make obj
$ make depend
mkdep -a -I/usr/local/include /home/remco/static_test/static_test.c
$ make
cc -O2 -pipe -I/usr/local/include -c /home/remco/static_test/static_test.c
cc -L/usr/local/lib -o static_test static_test.o -static -lgnutls -liconv
-lintl -lz -lp11-kit -lffi -ltasn1 -lnettle -lhogweed -lgmp -lpthread
/usr/local/lib/libgnutls.a(gnutls_ui.o): In function `gnutls_session_get_desc':
gnutls_ui.c:(.text+0xda6): warning: warning: strcpy() is almost always misused,
please use strlcpy()
/usr/local/lib/libgnutls.a(gnutls_str.o): In function `_gnutls_str_cat':
gnutls_str.c:(.text+0x1744): warning: warning: strcat() is almost always
misused, please use strlcat()
/usr/local/lib/libgnutls.a(gnutls_str.o): In function `_gnutls_bin2hex':
gnutls_str.c:(.text+0x8e2): warning: warning: sprintf() is often misused,
please use snprintf()
$ ldd obj/static_test
obj/static_test:
StartEnd Type Open Ref GrpRef Name
0c1b6ceb 0c1b6d5d1000 dlib 10 0
/home/remco/static_test/obj/static_test
$ gdb obj/static_test
GNU gdb 6.3
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-unknown-openbsd5.8"...
(gdb) run
Starting program: /home/remco/static_test/obj/static_test
Program received signal SIGSEGV, Segmentation fault.
0x1d8c4d423a6d in _dl_boot_bind ()
(gdb) bt
#0 0x1d8c4d423a6d in _dl_boot_bind ()
#1 0x1d8c4d423669 in __start ()
#2 0x in ?? ()
(gdb) q
The program is running. Exit anyway? (y or n) y
*) creating it with 'env NOPIE=make':
$ make clean
rm -f a.out [Ee]rrs mklog *.core y.tab.h static_test static_test.o
$ env NOPIE= make
cc -O2 -pipe -I/usr/local/include -fno-pie -c
/home/remco/static_test/static_test.c
cc -L/usr/local/lib -nopie -o static_test static_test.o -static -lgnutls
-liconv -lintl -lz -lp11-kit -lffi -ltasn1 -lnettle -lhogweed -lgmp -lpthread
/usr/local/lib/libgnutls.a(gnutls_ui.o): In function `gnutls_session_get_desc':
gnutls_ui.c:(.text+0xda6): warning: warning: strcpy() is almost always misused,
please use strlcpy()
/usr/local/lib/libgnutls.a(gnutls_str.o): In function `_gnutls_str_cat':
gnutls_str.c:(.text+0x1744): warning: warning: strcat() is almost always
misused, please use strlcat()
/usr/local/lib/libgnutls.a(gnutls_str.o): In function `_gnutls_bin2hex':
gnutls_str.c:(.text+0x8e2): warning: warning: sprintf() is often misused,
please use snprintf()
$ ldd obj/static_test
obj/static_test:
not a dynamic executable
$ gdb obj/static_test
GNU gdb 6.3
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-unknown-openbsd5.8"...
(gdb) run
Starting program: /home/remco/static_test/obj/static_test
Program received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) bt
#0 0x in ?? ()
#1 0x0055038e in pthread_once (once_control=0xaef050,
init_routine=0x4f5610 ) at
/usr/src/lib/librthread/rthread_once.c:26
#2 0x0040044e in __register_frame_info ()
#3 0x00400536 in atexit ()
#4 0x0
Re: Problems with kde4 in the 1/21 and 1/24 package snapshots
Just confirming that the problem of kwin(v4) not starting appears to be gone with the latest package snapshot. (tried on i386 and amd64) thanks Vadim.
Re: Problems with kde4 in the 1/21 and 1/24 package snapshots
Remco wrote: Vadim Zhukov wrote: 26.01.2014 12:34 STeve Andreapos; and...@msu.edu ???: On 01/26/14 03:21, Vadim Zhukov wrote: 26.01.2014 11:55 STeve Andreapos; and...@msu.edu ???: I'm still learning about KDE4 so perhaps this is my fault, but I'm having problems at the moment. When I run kde4 from the last two package snaps, the splash screen comes up, but I have a single virtual window. Going to the window behavior panel I can set multiple windows, but after clicking apply nothing happens. Any panel I bring up is missing the top controls and window frame, so I can't move it. Fortunately ^Q works. When switching to 4.11.5 I moved the .kde4 dir, but cleverly destroyed it so I can't test with that. What am I missing? Can I turn a debug history on (or up) so I can better see what's going on? This is an amd64-current system updated/compiled on Jan 25th about 7pm est, with a package set from 1/24. ... The transcript from console could help in finding the issue. Most likely it's related with deconflicting patches for renaming binaries; I already removed one erroneous patch which broke KHelpCenter, but there could be others. Running: OpenBSD 5.5-beta (GENERIC.MP) #225: Fri Jan 24 12:16:08 MST 2014 t...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP I think it's kwin not starting. (when running KDE from .xinitrc I see ksmserver(15854) KSMServer::wmProcessChange: Window manager kwin failed to launch, there don't appear to be any other related messages) kwin as such doesn't appear to exist, but it exists in a renamed version. When I work around the problem by making a symlink from /usr/local/bin/kwinv4 to kwin (ln -s kwin /usr/local/bin/kwinv4), the windows appear normal again. P.S. the binary could be called kwin4 instead of kwinv4 on a slightly older snapshot. I noticed the startkde4 script honours the KDEWM environment variable. Removing the symlink and setting the KDEWM variable in .xinitrc/.xsession seems to work as well, e.g.: (this is supposed to be a single line) exec env KDEWM=/usr/local/bin/kwinv4 /usr/local/bin/ck-launch-session /usr/local/bin/startkde4
Re: Problems with kde4 in the 1/21 and 1/24 package snapshots
Vadim Zhukov wrote: 26.01.2014 12:34 STeve Andreapos; and...@msu.edu ???: On 01/26/14 03:21, Vadim Zhukov wrote: 26.01.2014 11:55 STeve Andreapos; and...@msu.edu ???: I'm still learning about KDE4 so perhaps this is my fault, but I'm having problems at the moment. When I run kde4 from the last two package snaps, the splash screen comes up, but I have a single virtual window. Going to the window behavior panel I can set multiple windows, but after clicking apply nothing happens. Any panel I bring up is missing the top controls and window frame, so I can't move it. Fortunately ^Q works. When switching to 4.11.5 I moved the .kde4 dir, but cleverly destroyed it so I can't test with that. What am I missing? Can I turn a debug history on (or up) so I can better see what's going on? This is an amd64-current system updated/compiled on Jan 25th about 7pm est, with a package set from 1/24. ... The transcript from console could help in finding the issue. Most likely it's related with deconflicting patches for renaming binaries; I already removed one erroneous patch which broke KHelpCenter, but there could be others. Running: OpenBSD 5.5-beta (GENERIC.MP) #225: Fri Jan 24 12:16:08 MST 2014 t...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP I think it's kwin not starting. (when running KDE from .xinitrc I see ksmserver(15854) KSMServer::wmProcessChange: Window manager kwin failed to launch, there don't appear to be any other related messages) kwin as such doesn't appear to exist, but it exists in a renamed version. When I work around the problem by making a symlink from /usr/local/bin/kwinv4 to kwin (ln -s kwin /usr/local/bin/kwinv4), the windows appear normal again. P.S. the binary could be called kwin4 instead of kwinv4 on a slightly older snapshot.
Correct startkde path in KDE4 minimal README.
AFAICT the installed binary is called startkde4, not startkde:
Index: pkg/README-minimal
===
RCS file: /cvs/ports/meta/kde4/pkg/README-minimal,v
retrieving revision 1.2
diff -u -r1.2 README-minimal
--- pkg/README-minimal 15 Jan 2014 15:36:25 - 1.2
+++ pkg/README-minimal 23 Jan 2014 16:54:02 -
@@ -23,7 +23,7 @@
Then the following line should be added:
- exec ${LOCALBASE}/bin/ck-launch-session ${TRUEPREFIX}/bin/startkde
+ exec ${LOCALBASE}/bin/ck-launch-session ${TRUEPREFIX}/bin/startkde4
... in ~/.xinitrc when using startx(1) (console login)
... in ~/.xsession when using xdm(1) (X Display Manager login)
Re: missing icons in cvsweb on OpenBSD 5.4.
On Monday 28 October 2013 23:37:17 Christian Weisgerber wrote:
Remco re...@d-compu.dyndns.org wrote:
I tried out cvsweb on OpenBSD 5.4 and noticed the icons left of the
File items were missing. cvsweb installs its icons under
/var/www/htdocs/icons/ where the base system's icons are installed in
/var/www/icons/. Moving cvsweb's icons under /var/www/icons/ made them
pop up in cvsweb.
The CVS log shows that the icons were moved from /var/www/icons/
to /var/www/htdocs/icons/ in PLIST revision 1.7 and Makefile revision
1.47.
Yes. /var/www/icons/ is an Apache directory. Presumably it will
disappear with the base httpd, and nginx doesn't have access to it
by default. That's why I moved the icons when I switched my cvsweb
setup to nginx.
Alas, it completely slipped my mind that httpd still defaults to
mapping a /icons/ prefix in URLs to /var/www/icons/, so it in turn
doesn't have access to /var/www/htdocs/icons/.
I guess the best solution is to switch to a different path.
How does /cvsweb/icons/ sound?
With Apache's /icons/ mapping in mind, I think this is fine.
Your patch works for me,
thanks
Index: Makefile
===
RCS file: /cvs/ports/devel/cvsweb/Makefile,v
retrieving revision 1.49
diff -u -p -r1.49 Makefile
--- Makefile 13 Aug 2013 16:47:25 - 1.49
+++ Makefile 28 Oct 2013 22:34:52 -
@@ -3,7 +3,7 @@
COMMENT= CGI script to browse CVS repository trees
DISTNAME=cvsweb-2.0.6
-REVISION = 15
+REVISION = 16
CATEGORIES= devel www
HOMEPAGE=http://www.freebsd.org/projects/cvsweb.html
@@ -37,9 +37,9 @@ do-install:
.for file in ${CONFFILES}
${INSTALL_DATA} ${WRKSRC}/${file} ${CONFDIR}/cvsweb/${file}.dist
.endfor
- ${INSTALL_DATA_DIR} ${PREFIX}/htdocs/icons/cvsweb
+ ${INSTALL_DATA_DIR} ${PREFIX}/htdocs/cvsweb/icons
.for file in ${ICONS}
- ${INSTALL_DATA} ${WRKSRC}/icons/${file} ${PREFIX}/htdocs/icons/cvsweb/
+ ${INSTALL_DATA} ${WRKSRC}/icons/${file} ${PREFIX}/htdocs/cvsweb/icons/
.endfor
.include bsd.port.mk
Index: patches/patch-cvsweb_conf
===
RCS file: /cvs/ports/devel/cvsweb/patches/patch-cvsweb_conf,v
retrieving revision 1.11
diff -u -p -r1.11 patch-cvsweb_conf
--- patches/patch-cvsweb_conf 7 Apr 2013 20:07:24 - 1.11
+++ patches/patch-cvsweb_conf 28 Oct 2013 22:34:52 -
@@ -1,6 +1,6 @@
$OpenBSD: patch-cvsweb_conf,v 1.11 2013/04/07 20:07:24 naddy Exp $
--- cvsweb.conf.orig Mon Sep 23 07:30:17 2002
-+++ cvsweb.conf Sun Apr 7 14:09:30 2013
cvsweb.conf Mon Oct 28 23:27:17 2013
@@ -82,7 +82,7 @@ $cvstreedefault = $CVSrepositories[2 * 0];# The fi
# Manual gateway
##
@@ -23,7 +23,7 @@ $OpenBSD: patch-cvsweb_conf,v 1.11 2013/
# If these icons are too large, check out the miniicons in the
# icons/ directory; they have a width/height of 16/16
-my $iconsdir = /icons;
-+my $iconsdir = /icons/cvsweb;
++my $iconsdir = /cvsweb/icons;
# format: TEXT ICON-URL width height
%ICONS = (
Index: pkg/PLIST
===
RCS file: /cvs/ports/devel/cvsweb/pkg/PLIST,v
retrieving revision 1.7
diff -u -p -r1.7 PLIST
--- pkg/PLIST 2 Jun 2013 19:09:09 - 1.7
+++ pkg/PLIST 28 Oct 2013 22:34:52 -
@@ -7,13 +7,13 @@ conf/cvsweb/cvsweb.conf-openbsd.dist
conf/cvsweb/cvsweb.conf-ruby.dist
conf/cvsweb/cvsweb.conf.dist
@sample ${CONFDIR}/cvsweb/cvsweb.conf
-htdocs/icons/
-htdocs/icons/cvsweb/
-htdocs/icons/cvsweb/back.gif
-htdocs/icons/cvsweb/dir.gif
-htdocs/icons/cvsweb/miniback.gif
-htdocs/icons/cvsweb/minidir.gif
-htdocs/icons/cvsweb/minitext.gif
-htdocs/icons/cvsweb/text.gif
+htdocs/cvsweb/
+htdocs/cvsweb/icons/
+htdocs/cvsweb/icons/back.gif
+htdocs/cvsweb/icons/dir.gif
+htdocs/cvsweb/icons/miniback.gif
+htdocs/cvsweb/icons/minidir.gif
+htdocs/cvsweb/icons/minitext.gif
+htdocs/cvsweb/icons/text.gif
@cwd ${LOCALBASE}/share/doc/pkg-readmes
${FULLPKGNAME}
mod_auth_kerb missing symbols in OpenBSD 5.4.
After the upgrade to 5.4 I found httpd staying inactive on my test box. It turned out mod_auth_kerb was missing some symbols: # /etc/rc.d/httpd -d start doing rc_read_runfile doing rc_check httpd doing rc_pre doing rc_start /usr/sbin/httpd:/usr/lib/apache/modules/mod_auth_kerb.so: undefined symbol 'fix_dce' /usr/sbin/httpd:/usr/lib/apache/modules/mod_auth_kerb.so: undefined symbol 'encode_octet_string' /usr/sbin/httpd:/usr/lib/apache/modules/mod_auth_kerb.so: undefined symbol 'copy_octet_string' /usr/sbin/httpd:/usr/lib/apache/modules/mod_auth_kerb.so: undefined symbol 'free_octet_string' /usr/sbin/httpd:/usr/lib/apache/modules/mod_auth_kerb.so: undefined symbol 'decode_octet_string' /usr/sbin/httpd:/usr/lib/apache/modules/mod_auth_kerb.so: undefined symbol 'copy_oid' /usr/sbin/httpd:/usr/lib/apache/modules/mod_auth_kerb.so: undefined symbol 'decode_oid' /usr/sbin/httpd:/usr/lib/apache/modules/mod_auth_kerb.so: undefined symbol 'encode_enumerated' /usr/sbin/httpd:/usr/lib/apache/modules/mod_auth_kerb.so: undefined symbol 'length_enumerated' /usr/sbin/httpd:/usr/lib/apache/modules/mod_auth_kerb.so: undefined symbol 'length_octet_string' /usr/sbin/httpd:/usr/lib/apache/modules/mod_auth_kerb.so: undefined symbol 'free_oid' /usr/sbin/httpd:/usr/lib/apache/modules/mod_auth_kerb.so: undefined symbol 'decode_enumerated' /usr/sbin/httpd:/usr/lib/apache/modules/mod_auth_kerb.so: undefined symbol 'length_len' /usr/sbin/httpd:/usr/lib/apache/modules/mod_auth_kerb.so: undefined symbol 'encode_oid' /usr/sbin/httpd:/usr/lib/apache/modules/mod_auth_kerb.so: undefined symbol 'length_oid' Syntax error on line 274 of /var/www/conf/httpd.conf: Cannot load /usr/lib/apache/modules/mod_auth_kerb.so into server: Cannot load specified object doing rc_rm_runfile (failed) The easiest solution for me was disabling mod_auth_kerb since I wasn't using it anymore, however I decided to take a closer look. AFAICT some symbols were removed during the Heimdal update. At least fix_dce got missing from a recent libasn1: $ objdump -t /usr/lib/libasn1.so.19.0 | grep fix_dce 00069930 g F .text 0023 _heim_fix_dce compared to an older version: $ objdump -t /usr/lib/libasn1.so.18.0 | grep fix_dce 0007cc10 g F .text 0023 fix_dce I noticed mod_auth_kerb includes sources for these symbols, so I cooked up a patch to have them built and included in mod_auth_kerb.so. Included patches to configure.in and configure seem to get rid of the missing symbols problem. I can now start my httpd again, however, lacking a configuration actually using mod_auth_kerb authentication, I did NOT test if the actual authentication works ! I'm most likely going to remove mod_auth_kerb from my config, so I'm mainly posting this hoping it's useful to others. regards, Remco configure.in patch: $OpenBSD$ --- configure.in.orig Mon Oct 28 09:48:18 2013 +++ configure.inMon Oct 28 09:48:28 2013 @@ -187,18 +187,7 @@ int main(int argc, char** argv) LDFLAGS=$ac_save_LDFLAGS if test -z $gssapi_supports_spnego; then - if test -n $have_heimdal; then SPNEGO_SRCS=\ - spnegokrb5/asn1_MechType.c \ - spnegokrb5/asn1_MechTypeList.c \ - spnegokrb5/asn1_ContextFlags.c \ - spnegokrb5/asn1_NegTokenInit.c \ - spnegokrb5/asn1_NegTokenTarg.c \ - spnegokrb5/init_sec_context.c \ - spnegokrb5/accept_sec_context.c\ - spnegokrb5/encapsulate.c \ - spnegokrb5/decapsulate.c \ - spnegokrb5/external.c - else SPNEGO_SRCS=\ + SPNEGO_SRCS=\ spnegokrb5/asn1_MechType.c \ spnegokrb5/asn1_MechTypeList.c \ spnegokrb5/asn1_ContextFlags.c \ @@ -215,7 +204,6 @@ int main(int argc, char** argv) spnegokrb5/encapsulate.c \ spnegokrb5/decapsulate.c \ spnegokrb5/external.c - fi fi fi fi configure patch: $OpenBSD$ --- configure.orig Wed Nov 22 11:33:58 2006 +++ configure Mon Oct 28 09:56:28 2013 @@ -3931,18 +3931,7 @@ fi LDFLAGS=$ac_save_LDFLAGS if test -z $gssapi_supports_spnego; then - if test -n $have_heimdal; then SPNEGO_SRCS=\ - spnegokrb5/asn1_MechType.c \ - spnegokrb5/asn1_MechTypeList.c \ - spnegokrb5/asn1_ContextFlags.c \ - spnegokrb5/asn1_NegTokenInit.c \ - spnegokrb5/asn1_NegTokenTarg.c \ - spnegokrb5/init_sec_context.c \ - spnegokrb5/accept_sec_context.c\ - spnegokrb5/encapsulate.c \ - spnegokrb5/decapsulate.c \ - spnegokrb5/external.c - else SPNEGO_SRCS=\ + SPNEGO_SRCS=\ spnegokrb5/asn1_MechType.c
missing icons in cvsweb on OpenBSD 5.4.
I tried out cvsweb on OpenBSD 5.4 and noticed the icons left of the File
items were missing. cvsweb installs its icons under /var/www/htdocs/icons/
where the base system's icons are installed in /var/www/icons/. Moving
cvsweb's icons under /var/www/icons/ made them pop up in cvsweb.
In case it matters, I'm running httpd unchrooted. (httpd_flags=-u)
The CVS log shows that the icons were moved from /var/www/icons/
to /var/www/htdocs/icons/ in PLIST revision 1.7 and Makefile revision 1.47.
I'm not sure where these icons should be stored. The included patches seem to
put them in the right place for me.
regards,
Remco
Index: Makefile
===
RCS file: /home/cvs/ports/devel/cvsweb/Makefile,v
retrieving revision 1.48
diff -u -r1.48 Makefile
--- Makefile5 Jul 2013 07:23:33 - 1.48
+++ Makefile28 Oct 2013 13:11:30 -
@@ -3,7 +3,7 @@
COMMENT= CGI script to browse CVS repository trees
DISTNAME= cvsweb-2.0.6
-REVISION = 14
+REVISION = 15
CATEGORIES=devel www
HOMEPAGE= http://www.freebsd.org/projects/cvsweb.html
@@ -37,9 +37,9 @@
.for file in ${CONFFILES}
${INSTALL_DATA} ${WRKSRC}/${file} ${CONFDIR}/cvsweb/${file}.dist
.endfor
- ${INSTALL_DATA_DIR} ${PREFIX}/htdocs/icons/cvsweb
+ ${INSTALL_DATA_DIR} ${PREFIX}/icons/cvsweb
.for file in ${ICONS}
- ${INSTALL_DATA} ${WRKSRC}/icons/${file} ${PREFIX}/htdocs/icons/cvsweb/
+ ${INSTALL_DATA} ${WRKSRC}/icons/${file} ${PREFIX}/icons/cvsweb/
.endfor
.include bsd.port.mk
Index: pkg/PLIST
===
RCS file: /home/cvs/ports/devel/cvsweb/pkg/PLIST,v
retrieving revision 1.7
diff -u -r1.7 PLIST
--- pkg/PLIST 2 Jun 2013 19:09:09 - 1.7
+++ pkg/PLIST 28 Oct 2013 13:08:42 -
@@ -7,13 +7,12 @@
conf/cvsweb/cvsweb.conf-ruby.dist
conf/cvsweb/cvsweb.conf.dist
@sample ${CONFDIR}/cvsweb/cvsweb.conf
-htdocs/icons/
-htdocs/icons/cvsweb/
-htdocs/icons/cvsweb/back.gif
-htdocs/icons/cvsweb/dir.gif
-htdocs/icons/cvsweb/miniback.gif
-htdocs/icons/cvsweb/minidir.gif
-htdocs/icons/cvsweb/minitext.gif
-htdocs/icons/cvsweb/text.gif
+icons/cvsweb/
+icons/cvsweb/back.gif
+icons/cvsweb/dir.gif
+icons/cvsweb/miniback.gif
+icons/cvsweb/minidir.gif
+icons/cvsweb/minitext.gif
+icons/cvsweb/text.gif
@cwd ${LOCALBASE}/share/doc/pkg-readmes
${FULLPKGNAME}
Re: fluidsynth vs sndiod
Alexandre Ratchov wrote: On Tue, Apr 02, 2013 at 08:47:34AM +0200, Jan Stary wrote: On Apr 02 00:17:16, a...@caoua.org wrote: On Mon, Apr 01, 2013 at 07:16:20PM +0200, Jan Stary wrote: On this fresh install of current/amd64, using the new audio/fluidsynth 1.1.6 (thank you sthen), I can only use it with sndiod _not_ running. When sndiod runs, my MIDI keyboard still works fine, as tested with 'aucat -Mq rmidi/0 -o -' (suggested by the FAQ), but fluidsynth never seems to get any of the MIDI messages. The keyboard is a CME UF-6 connected by an M-Audio USB-to-MIDI, reports itself as umidi0 at uhub2 port 2 configuration 1 interface 1 M-Audio USB Uno MIDI Interface rev 1.00/1.25 addr 2 umidi0: (genuine USB-MIDI) umidi0: out=1, in=1 midi0 at umidi0: USB MIDI I/F ugen0 at uhub2 port 2 configuration 1 M-Audio USB Uno MIDI Interface rev 1.00/1.25 addr 2 and works OK in many other situations. If I shut sndiod down, fluidsynth works OK. Can some shed some light on why is that? Can this a problem of fluidsynth's sndio backend? Maybe fluidsynth uses the default MIDI port; if sndiod is running this corresponds to midithru/0, else to rmidi/0. Does it work if you force fluidsynth to use rmidi/0 ? Is there a way to do that? There is midi.portname in fluidsynth's settings, but setting it to whatever doesn't seem to have any effect. When I reroute audio in fluidsynth I'm using 'fluidsynth -o audio.sndio.device=...', so for MIDI 'fluidsynth -o midi.sndio.device=...' might work. don't have a box to test it right now, but iirc the -p option used to work, you could also try: export MIDIDEVICE=rmidi/0 in case fluidsynth uses the default device. -- Alexandre
Re: fluidsynth vs sndiod
Jan Stary wrote: On this fresh install of current/amd64, using the new audio/fluidsynth 1.1.6 (thank you sthen), I can only use it with sndiod _not_ running. When sndiod runs, my MIDI keyboard still works fine, as tested with 'aucat -Mq rmidi/0 -o -' (suggested by the FAQ), but fluidsynth never seems to get any of the MIDI messages. The keyboard is a CME UF-6 connected by an M-Audio USB-to-MIDI, reports itself as umidi0 at uhub2 port 2 configuration 1 interface 1 M-Audio USB Uno MIDI Interface rev 1.00/1.25 addr 2 umidi0: (genuine USB-MIDI) umidi0: out=1, in=1 midi0 at umidi0: USB MIDI I/F ugen0 at uhub2 port 2 configuration 1 M-Audio USB Uno MIDI Interface rev 1.00/1.25 addr 2 and works OK in many other situations. If I shut sndiod down, fluidsynth works OK. Can some shed some light on why is that? Can this a problem of fluidsynth's sndio backend? (BTW, has anyone tried to push the sndio backend upstream?) Jan I'm suspecting that without sndiod fluidsynth connects directly to the MIDI port your keyboard is connected to. I think you may be missing the proper connections between your keyboard, a sndio MIDI through box, and fluidsynth. e.g.: (this is on OpenBSD 5.2) I run sndiod with the -M option. AFAICT this gives me a MIDI through box (midithru/0). fluidsynth will automatically connect to its output. I use midiplay, which automatically connects to midithru/0's input, to play a MIDI file. (So, midiplay - midithru/0 - fluidsynth) If I understand the CURRENT system (haven't tried it yet), starting fluidsynth with sndiod active will dynamically create a MIDI through box for you. In my mind all you have to do is use a tool (aucat/midish) to connect your keyboard to the MIDI through box. I haven't got the equipment to test, but assuming my understanding is correct and the dynamically created MIDI through box is named midithru/0, this might work to connect your keyboard: (analogous to FAQ 13.7) aucat -M -q midithru/0 -q rmidi/0 (So, rmidi/0 - midithru/0 - fluidsynth)
Re: NEW: audio/mscore
Brian Callahan wrote:
Hi ports --
Attached is a port of mscore (also known as musescore), a WYSIWYG music
notation program, similar to Finale or Sibelius.
There is one minor issue; when attempting to save a file as .flac or
.ogg, you get the following error:
open soundfile failed: File contains data in an unimplemented format.
I believe this is because our libsndfile is built with
--disable-external-libs. Trying to save in all other formats works as
expected. One could, as a workaround, save as wav and then convert it to
the format of your choice with external tools. Adding libvorbis and
libogg to the depends does nothing to fix this.
Also, I have no midi hardware so I can't test the midi input. If this is
important to you, please test.
Only tested on amd64 so far.
OK?
~Brian
Building this on either an i386 CURRENT system with CURRENT ports, or OpenBSD
5.2 amd64 with unknown (I think 5.2) ports, I get this error:
-- Configuring done
-- Generating done
-- Build files have been written
to: /home/home.lan/remco/ports/pobj/mscore-1.2/mscore-1.2/build
make: unknown option -- -
usage: make [-BeiknPqrSst] [-D variable] [-d flags] [-f makefile]
[-I directory] [-j max_jobs] [-m directory] [-V variable]
[NAME=value] [target ...]
make: unknown option -- -
usage: make [-BeiknPqrSst] [-D variable] [-d flags] [-f makefile]
[-I directory] [-j max_jobs] [-m directory] [-V variable]
[NAME=value] [target ...]
gmake: *** [release] Error 2
*** Error code 2
Stop in /home/home.lan/remco/git.myports/audio/mscore (line 2496
of /home/home.lan/remco/ports/infrastructure/mk/bsd.port.mk).
*** Error code 1
Stop in /home/home.lan/remco/git.myports/audio/mscore (line 2245
of /home/home.lan/remco/ports/infrastructure/mk/bsd.port.mk).
I noticed your USE_GMAKE=Yes dependency and made an educated guess that this
can't be build with OpenBSD's stock make. The main Makefile has 'make'
hardcoded in many places.
I'm not sure that my assumption that USE_GMAKE=Yes sets the MAKE environment
variable to 'gmake' but the following updates patch seems to enable me to, at
least, kick off a build: (It seems that this will take a while so I can't
tell whether this is enough, there are still hardcoded 'make'-s left)
$OpenBSD$
--- Makefile.orig Tue Mar 13 14:37:09 2012
+++ MakefileTue Jan 15 10:34:14 2013
@@ -19,7 +19,7 @@
#=
REVISION = `cat mscore/mscore/revision.h`
-CPUS = `grep -c processor /proc/cpuinfo`
+CPUS = `sysctl -n hw.ncpu`
PREFIX= /usr/local
#VERSION = 1.2r${REVISION}
@@ -32,11 +32,12 @@ release:
then \
mkdir build; \
cd build; \
+cp ../mscore/all.h .; \
cmake -DCMAKE_BUILD_TYPE=RELEASE \
-DCMAKE_INSTALL_PREFIX=${PREFIX} \
../mscore; \
-make lrelease; \
-make -j ${CPUS}; \
+${MAKE} lrelease; \
+${MAKE} -j ${CPUS};\
else \
echo build directory does already exist, please remove first
with 'make clean'; \
fi;
Re: NEW: audio/mscore
Remco wrote:
$OpenBSD$
--- Makefile.orig Tue Mar 13 14:37:09 2012
+++ Makefile Tue Jan 15 10:34:14 2013
@@ -19,7 +19,7 @@
#=
REVISION = `cat mscore/mscore/revision.h`
-CPUS = `grep -c processor /proc/cpuinfo`
+CPUS = `sysctl -n hw.ncpu`
PREFIX= /usr/local
#VERSION = 1.2r${REVISION}
@@ -32,11 +32,12 @@ release:
then \
mkdir build; \
cd build; \
+cp ../mscore/all.h .; \
cmake -DCMAKE_BUILD_TYPE=RELEASE\
-DCMAKE_INSTALL_PREFIX=${PREFIX} \
../mscore; \
-make lrelease; \
-make -j ${CPUS}; \
+${MAKE} lrelease; \
+${MAKE} -j ${CPUS};\
else \
echo build directory does already exist, please remove first
with 'make clean'; \
fi;
Here's an updated patch in order to be able to run 'make install' as well.
With this I'm able to build and install the whole package. I can at least
start MuseScore and play the example song, have never really used it before,
so can't say much else about it right now.
thanks for your effort so far.
$OpenBSD$
--- Makefile.orig Tue Mar 13 14:37:09 2012
+++ MakefileTue Jan 15 11:52:06 2013
@@ -19,7 +19,7 @@
#=
REVISION = `cat mscore/mscore/revision.h`
-CPUS = `grep -c processor /proc/cpuinfo`
+CPUS = `sysctl -n hw.ncpu`
PREFIX= /usr/local
#VERSION = 1.2r${REVISION}
@@ -32,11 +32,12 @@ release:
then \
mkdir build; \
cd build; \
+cp ../mscore/all.h .; \
cmake -DCMAKE_BUILD_TYPE=RELEASE \
-DCMAKE_INSTALL_PREFIX=${PREFIX} \
../mscore; \
-make lrelease; \
-make -j ${CPUS}; \
+${MAKE} lrelease; \
+${MAKE} -j ${CPUS};\
else \
echo build directory does already exist, please remove first
with 'make clean'; \
fi;
@@ -115,7 +116,7 @@ version: revision
@echo ${VERSION}
install:
- cd build; make install
+ cd build; ${MAKE} install
#
# linux
[pkgpath.7] fix dashes
I hope this makes sense: Index: pkgpath.7 === RCS file: /cvs/src/share/man/man7/pkgpath.7,v retrieving revision 1.1 diff -u -r1.1 pkgpath.7 --- pkgpath.7 21 Nov 2011 12:00:57 - 1.1 +++ pkgpath.7 9 Jan 2013 11:30:14 - @@ -65,7 +65,7 @@ Note that .Ar -sub and -.Ar -flavor +.Ar flavor parts can be specified in any order, as all subpackages start with a dash. It is an error to ask for several subs at once, e.g.\ @@ -89,7 +89,7 @@ (all of which are pseudo-flavors), so that only the main package will build. .It Ar net/avahi,no_mono,-qt3 Build avahi with the no_mono pseudo-flavor, which will build the --main, -qt3, qt4, -gui, -gtk, -gtk3, and -ui subpackages, and refer to the +-main, -qt3, -qt4, -gui, -gtk, -gtk3, and -ui subpackages, and refer to the .Ar -qt3 subpackage. .It Ar net/avahi,
Re: Firefox 13.0.1 language add-on needs enabling
On Thursday 28 June 2012 05:04:23 Eric Elena wrote: You should look at extensions.autoDisableScopes. This value should be 15 on your system, which means that all the extensions are disabled by default. You can set it to 0 to automatically enable all the extensions, of course if you trust what is installed on your PC. Eric Thanks for explaining this, but I don't consider enabling all extensions a solution. Le mercredi 27 juin 2012 à 14:55 +0200, Remco a écrit : I installed firefox 13.0.1 on OpenBSD 5.2-beta and, apart from installing the appropriate firefox-i18n package and changing general.useragent.locale, I had to manually enable the language of choice in the browser. (I don't remember doing that ever before) I'm wondering if the following patch to the MESSAGE file of the firefox-i18n package makes sense. Of course, if firefox is already configured for a language other than English, the words Tools - Add-ons - Languages will be displayed in that other language, which may or may not be confusing. I don't know how to deal with that, if needed. Index: pkg/MESSAGE === RCS file: /cvs/ports/www/firefox-i18n/pkg/MESSAGE,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 MESSAGE --- pkg/MESSAGE 25 Jun 2006 21:25:44 - 1.1.1.1 +++ pkg/MESSAGE 27 Jun 2012 12:21:16 - @@ -1,3 +1,4 @@ To configure Firefox for your language, type about:config in the URL bar and edit general.useragent.locale (e.g. fr-FR ; default is en-US), +enable your language in Tools - Add-ons - Languages, then restart Firefox.
Re: Firefox 13.0.1 language add-on needs enabling
Landry Breuil wrote: On Wed, Jun 27, 2012 at 02:55:55PM +0200, Remco wrote: I installed firefox 13.0.1 on OpenBSD 5.2-beta and, apart from installing the appropriate firefox-i18n package and changing general.useragent.locale, I had to manually enable the language of choice in the browser. (I don't remember doing that ever before) I'm wondering if the following patch to the MESSAGE file of the firefox-i18n package makes sense. Of course, if firefox is already configured for a language other than English, the words Tools - Add-ons - Languages will be displayed in that other language, which may or may not be confusing. I don't know how to deal with that, if needed. They way it is now, if you install a firefox-i18n package firefox will ask you at next restart if you want to enable the new extension. We can add more blurb to MESSAGE, but to me the current state might be enough.. Landry I checked that and you're right when firefox-i18n-xx gets installed after firefox has been used before. However, when installing firefox and firefox-i18n-xx first and then starting firefox for the first time, I don't see a reminder to enable language add-ons. (I suppose it doesn't consider this situation a newly added language) It's not a terrible big deal, but in this case I think a reminder in the MESSAGE file is useful. (it feels like the MESSAGE file is telling only half the story in this situation) I reworded my initial patch a bit to avoid mentioning menu items in a specific language: Index: pkg/MESSAGE === RCS file: /cvs/ports/www/firefox-i18n/pkg/MESSAGE,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 MESSAGE --- pkg/MESSAGE 25 Jun 2006 21:25:44 - 1.1.1.1 +++ pkg/MESSAGE 28 Jun 2012 08:34:51 - @@ -1,3 +1,4 @@ To configure Firefox for your language, type about:config in the URL bar and edit general.useragent.locale (e.g. fr-FR ; default is en-US), +check that your language is available and enabled in the language add-ons, then restart Firefox. Index: pkg/MESSAGE === RCS file: /cvs/ports/www/firefox-i18n/pkg/MESSAGE,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 MESSAGE --- pkg/MESSAGE 25 Jun 2006 21:25:44 - 1.1.1.1 +++ pkg/MESSAGE 27 Jun 2012 12:21:16 - @@ -1,3 +1,4 @@ To configure Firefox for your language, type about:config in the URL bar and edit general.useragent.locale (e.g. fr-FR ; default is en-US), +enable your language in Tools - Add-ons - Languages, then restart Firefox.
Firefox 13.0.1 language add-on needs enabling
I installed firefox 13.0.1 on OpenBSD 5.2-beta and, apart from installing the appropriate firefox-i18n package and changing general.useragent.locale, I had to manually enable the language of choice in the browser. (I don't remember doing that ever before) I'm wondering if the following patch to the MESSAGE file of the firefox-i18n package makes sense. Of course, if firefox is already configured for a language other than English, the words Tools - Add-ons - Languages will be displayed in that other language, which may or may not be confusing. I don't know how to deal with that, if needed. Index: pkg/MESSAGE === RCS file: /cvs/ports/www/firefox-i18n/pkg/MESSAGE,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 MESSAGE --- pkg/MESSAGE 25 Jun 2006 21:25:44 - 1.1.1.1 +++ pkg/MESSAGE 27 Jun 2012 12:21:16 - @@ -1,3 +1,4 @@ To configure Firefox for your language, type about:config in the URL bar and edit general.useragent.locale (e.g. fr-FR ; default is en-US), +enable your language in Tools - Add-ons - Languages, then restart Firefox.
Re: c++ headers w/ -pedantic, overflow in implicit constant conversion
Stuart Henderson wrote:
There are a fair few of these in c++ builds which tend to obscure some
of the actually useful warnings. Antoine noticed it a while ago, Landry
noticed it recently, I see it from time to time..
Any suggestions other than not using -pedantic? (Actually I think
I have seen this without -pedantic too somewhere but I forget where).
Is this just a silly warning or is there actually a problem with the
headers?
This example is from chopping down a file from converters/wv2 (which
is itself a relatively small example) until the warning no longer
occurs then going back one step.
$ cat a.c
#include string
^D
$ c++ -pedantic -c a.c
In file included from /usr/include/g++/memory:60,
from /usr/include/g++/string:48,
from a.c:1:
/usr/include/g++/limits: In static member function 'static char
std::numeric_limitschar::min()': /usr/include/g++/limits:375: warning:
overflow in implicit constant conversion /usr/include/g++/limits: In
static member function 'static wchar_t
std::numeric_limitswchar_t::max()': /usr/include/g++/limits:530:
warning: overflow in implicit constant conversion
Not a solution, but hopefully helpful.
If I interpreted everything correctly, the macro __glibcxx_min
in /usr/include/g++/limits is used in std::numeric_limitschar::min().
It uses something like ((char)17) to determine the minimum value of a
char. I suspect that ((char)17), or (17) before being converted to
char, is interpreted as 128 in an intermediate stage of the processing.
When being pedantic 128 wouldn't fit in a char at that moment.
(AFAICT -128 = char = 127)
I suspect something similar is the case for the max function. 128 is used as
an intermediate result. Subtracting 1 gets the proper end result. But the
intermediate result (128) doesn't fit in a char when having a pedantic look
at this.
Attached is the simplest case I could come up with to reproduce this:
btw, this is on:
OpenBSD 5.0 (GENERIC.MP) #63: Wed Aug 17 10:14:30 MDT 2011
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
make a file, e.g. t.cc, containing:
char
test1()
{
return ((char)16);
}
char
test2()
{
return ((char)17);
}
char
test3()
{
return ((char)18);
}
compile using C++ compiler:
being pedantic:
$ c++ -pedantic -c t.cc
t.cc: In function 'char test2()':
t.cc:11: warning: overflow in implicit constant conversion
t.cc: In function 'char test3()':
t.cc:18: warning: overflow in implicit constant conversion
NOT being pedantic:
$ c++ -c t.cc
t.cc: In function 'char test3()':
t.cc:18: warning: overflow in implicit constant conversion
copy to a .c file:
$ cp t.cc t.c
compile using C compiler:
being pedantic:
$ cc -pedantic -c t.c
t.c: In function 'test2':
t.c:11: warning: overflow in implicit constant conversion
t.c: In function 'test3':
t.c:18: warning: overflow in implicit constant conversion
NOT being pedantic:
$ cc -c t.c
t.c: In function 'test3':
t.c:18: warning: overflow in implicit constant conversion
openldap client segfault
On a beta system:
$ dmesg |head -n2
OpenBSD 5.1-beta (GENERIC.MP) #178: Thu Feb 2 02:44:59 MST 2012
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
I have openldap clients segfault on me using GSSAPI, e.g.:
$ ldapwhoami
SASL/GSSAPI authentication started
SASL username: re...@test.lan
SASL SSF: 56
SASL data security layer installed.
Segmentation fault (core dumped)
$ gdb ldapwhoami
GNU gdb 6.3
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 i386-unknown-openbsd5.1...(no debugging symbols
found)
(gdb) run
Starting program: /usr/local/bin/ldapwhoami
(no debugging symbols found)
SASL/GSSAPI authentication started
SASL username: re...@test.lan
SASL SSF: 56
SASL data security layer installed.
Program received signal SIGSEGV, Segmentation fault.
0x093b099e in sasl_gss_encode () from /usr/local/lib/sasl2/libgssapiv2.so.2.22
(gdb) bt
#0 0x093b099e in sasl_gss_encode ()
from /usr/local/lib/sasl2/libgssapiv2.so.2.22
#1 0x06ff1311 in _sasl_encodev () from /usr/local/lib/libsasl2.so.2.23
#2 0x06ff1832 in sasl_encodev () from /usr/local/lib/libsasl2.so.2.23
#3 0x06ff19fa in sasl_encode () from /usr/local/lib/libsasl2.so.2.23
#4 0x1c023d9a in ?? ()
#5 0x7edf74d0 in ?? ()
#6 0x7edf2020 in ?? ()
#7 0x0020 in ?? ()
#8 0x7edf3944 in ?? ()
#9 0xcfbe83ac in ?? ()
#10 0x0061 in ?? ()
#11 0x01ff in ?? ()
#12 0x2a826c98 in ?? () from /usr/lib/libc.so.62.0
#13 0x in ?? ()
(gdb) q
The program is running. Exit anyway? (y or n) y
From reading http://www.spinics.net/lists/cyrus-sasl/msg02004.html, I
understand the issue probably is a pointer being assigned to a buffer, that
buffer potentially being a NULL pointer, or getting reallocated, invalidating
the pointer. Dereferencing the pointer after that (hopefully) segfaults.
Since it makes sense to me, I tried the suggestion from that message
(assigning the pointer after the potential reallocation) and it seems to
solve the problem.
What I did:
modify the plugins/gssapi.c file and use 'make update-patches' to create the
file patches/patch-plugins_gssapi_c:
$OpenBSD$
--- plugins/gssapi.c.orig Mon Feb 6 09:30:58 2012
+++ plugins/gssapi.cMon Feb 6 09:31:47 2012
@@ -370,7 +370,7 @@ sasl_gss_encode(void *context, const struct iovec *inv
}
if (output_token-value output) {
- unsigned char * p = (unsigned char *) text-encode_buf;
+ unsigned char * p;
ret = _plug_buf_alloc(text-utils,
(text-encode_buf),
@@ -384,6 +384,8 @@ sasl_gss_encode(void *context, const struct iovec *inv
return ret;
}
+ p = (unsigned char *) text-encode_buf;
+
p[0] = (output_token-length24) 0xFF;
p[1] = (output_token-length16) 0xFF;
p[2] = (output_token-length8) 0xFF;
updated the package revision:
? patches/patch-plugins_gssapi_c
Index: Makefile
===
RCS file: /cvs/ports/security/cyrus-sasl2/Makefile,v
retrieving revision 1.64
diff -u -r1.64 Makefile
--- Makefile21 Dec 2011 14:36:15 - 1.64
+++ Makefile6 Feb 2012 09:12:42 -
@@ -20,7 +20,7 @@
CATEGORIES=security
-REVISION= 1
+REVISION= 2
HOMEPAGE= http://www.cyrusimap.org/
in directory ~/ports/security/cyrus-sasl2, do:
$ make clean
$ make configure
$ make
$ make fake
$ make package
$ make update
resulting in a working ldapwhoami:
$ ldapwhoami
SASL/GSSAPI authentication started
SASL username: re...@test.lan
SASL SSF: 56
SASL data security layer installed.
dn:uid=remco,cn=gssapi,cn=auth
Re: UPDATE: security/qca2
I was wondering if there's anyone who has run into this: One thing I've run into the very few times I tried building KDE4 is that for me the qca2 library is installed with version 2.0 instead of 3.0. make package fails with: Error: /home/remco/ports/pobj/qca2-2.0.3/fake-i386/usr/local/lib/libqca.so.3.0 does not exist .. $ cat /etc/mk.conf FETCH_PACKAGES=yes MAKE_FLAGS=-j4 overwritten MAKE_FLAGS. should be MAKE_FLAGS+=-j4 Thanks, that fixed it.
Re: UPDATE: security/qca2
Alexandr Shadchin wrote:
On Thu, Dec 01, 2011 at 12:06:50PM -0600, Amit Kulkarni wrote:
On Thu, Dec 1, 2011 at 12:58 AM, Antoine Jacoutot ajacou...@bsdfrog.org
wrote:
On Thu, Dec 01, 2011 at 05:43:36AM +0600, Alexandr Shadchin wrote:
Hi,
This update package qca2 to the latest release 2.0.3.
Tested on amd64.
Comments ? OK ?
Considering this port is not hooked to the build, I think it's pretty
safe... ok aja@
NO_REGRESS should be Yes. there's some weird space between WANTLIB
line and .include...
in the original file there are tabs. thanks for NO_REGRESS.
other than that, it works fine...
thanks
I was wondering if there's anyone who has run into this:
One thing I've run into the very few times I tried building KDE4 is that for
me the qca2 library is installed with version 2.0 instead of 3.0.
make package fails with:
Error: /home/remco/ports/pobj/qca2-2.0.3/fake-i386/usr/local/lib/libqca.so.3.0
does not exist
The build is done on i386:
OpenBSD 5.0-current (GENERIC.MP) #134: Mon Nov 28 16:18:46 MST 2011
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
$ ls -l ~/ports/pobj/qca2-2.0.3/fake-i386/usr/local/lib/
total 2640
drwxr-xr-x 3 root wheel 512 Dec 1 20:02 X11
-rw-r--r-- 1 root wheel 392 Dec 1 20:02 libqca.prl
-rwxr-xr-x 1 root wheel 1313478 Dec 1 20:02 libqca.so.2.0
drwxr-xr-x 2 root wheel 512 Dec 1 20:02 pkgconfig
drwxr-xr-x 3 root wheel 512 Dec 1 20:02 qt4
If I remember correctly, in the past, I once worked around it by
defining SHARED_LIBS += qca 2.0 and subsequently changing qca2
dependencies to =2.0 instead of =3.0 within KDE4.
Another time I somehow hardcoded the 3.0 version into qca2 leaving all
KDE4 dependencies at =3.0.
One particularity of this system is that I have ports installed
in /usr/local/ports.
The system I tried today also has ports in a non-default location:
$ grep PORTSDIR ~/.profile
PORTSDIR=/home/remco/ports
export PORTSDIR
$ cat /etc/mk.conf
FETCH_PACKAGES=yes
MAKE_FLAGS=-j4
SUDO=/usr/bin/sudo
PORTSDIR_PATH=${PORTSDIR}:$(PORTSDIR)/openbsd-wip
I don't know if my setup has some weirdness, though that means I have two
similarly weird setups. The biggest difference I'm able to spot is that I'm
building on i386 with ports in a non-default location, though I don't
understand how that could possibly affect the version of the library
produced.
Re: Qemu works with OpenBSD as host and guest (both amd64), but what linux will work as guest?
Brett wrote: Hi, Not sure if this is a ports question, or misc question, or none of the above... I am running amd64 current, and installed qemu-0.15.1p0 from ports. Following the readme instructions, I was able to boot a recent snapshot of OpenBSD (amd64) as the guest OS. Networking and x window system all work. I've then tried to install some kind of linux as the guest. After creating a virtual.img, I then try: $ qemu-system-x86_64 -m 200 -monitor stdio -no-fd-bootchk -hda virtual.img -cdrom debian-6.0.3-amd64-CD-1.iso -boot d The initial boot message and installer menu appears, however when I select something (eg install or graphical install) the screen then blanks indefintely, and looking at top, qemu-system starts at about 7% cpu usage, then climbs to 98% over a few minutes. I left the installer in this state for about 4 hours this afternoon, and it was still stuck on blank screen when I came home, so I don't think its just being incredibly slow. I've seen that too in the past, but I may have found a way that works. Basically the same result occurs if I try TinyCore Linux, Bodhi Linux, or Lubuntu. The monitor in the shell I launch qemu from just displays: QEMU 0.15.1 monitor - type 'help' for more information (qemu) I've played around with the arguments to the above command, trying teh different -vga and -net settings, but i'm pretty sure they are not the problem. Is there a known working linux distro I could try? Or some other arguments or changes I can make so the critter will boot? I could not find anything relevant on the mailing lists or web. A couple of weeks ago Slackware and Debian seemed to work for me. (qemu 0.13.0p1 on 4.9 amd64) If I'm not mistaken they both have a non-graphical installer. I removed the Slackware image but I remember it working fairly smooth from the command line. (I didn't install a graphical environment on either) Though I haven't really used it, I still have a Debian image around that seems to boot up fine without the black/blank screen. (If I remember correctly the black screen was there for, maybe, up to a couple of minutes, during the initial install) I used the following CD image: $ ls Debian/*.iso Debian/debian-6.0.2.1-amd64-netinst.iso and the script I use is: $ cat debian.sh #!/bin/sh qemu-system-x86_64 -no-acpi -soundhw ac97 \ -hda ~/thuis.lan/virtual/Debian/hd.img \ -net nic,vlan=0,model=e1000,macaddr=52:54:00:12:34:58 \ -net user,vlan=0 Perhaps the -no-acpi parameter does the magic. Also, launching as a normal user, the highest I can specify -m is 330 (with a Failed to allocate memory: Cannot allocate memory message), while using the above command as root, I can set -m to (eg) 2660. Is there a sysctl or other setting that will allow a higher memory allocation as normal user? see ksh(1) - use ulimit to increase the size of the data area, e.g.: ulimit -Sd 1048576 I hope some of this is useful.
Re: mpd skipping a lot on my thinkpad
Thanks Alexandre and Jacob for your elaborate explanation. Apparently I missed the flow control part, so after making sure I can handle partial writes, sound appears to be smooth using both libsndio and audio(4). Sorry to the mpd users for hijacking your thread. Still, I hope the information provided will be useful to you and others struggling with audio. Regards, Remco
Re: mpd skipping a lot on my thinkpad
... endless clicking noise intermixed with music ... sounds like the mp delayed interrupt notification issue that wreaks havoc on audio. I don't know if I'm telling anything new and whether this is useful. (my coding skills may be lacking as well) I seem to be able to reproduce the following reliably: When I create a producer/consumer loop using circular buffers where the producer (WAVE file) is much faster than the consumer (audio device), using polling to see whether there is work to do for either the producer or consumer: - in blocking mode everything seems fine: The producer fills the buffers, if it overruns it's paused. The consumer takes the buffers one at the time and when it's about to underrun it resumes the producer. This seems to produce uninterrupted sound just fine. - in non-blocking mode: This basically follows the same procedure as with blocking mode. However, it appears that the audio device becomes available prematurely. (within a few ms independent of the amount of data that was written) e.g.: when I try to send the audio data in ~20ms chunks, I hear a lot of clicks, and the audio appears to be sped up somewhat. Increasing the length of the audio chunks (~2s) makes it sound like it is in fast forward. Just a few ms of each 2s buffer appear to be played before advancing to the next buffer skipping over the song really fast, playing only tiny fragments of the song. It doesn't necessarily seem to be related to sndio/aucat. I seem to get the same results with audio(4). I was expecting the writes to the audio device to fail (EAGAIN) if the previous buffer isn't done playing yet. Basically I don't expect POLLOUT to be set until all software buffers have been drained and the data has been written to the device completely. Unless I'm doing something wrong or misinterpreting something, this doesn't seem to be the case.
Re: mpd skipping a lot on my thinkpad
Remco wrote:
... endless clicking noise intermixed with music ...
sounds like the mp delayed interrupt notification issue that wreaks
havoc on audio.
I was expecting the writes to the audio device to fail (EAGAIN) if the
previous buffer isn't done playing yet. Basically I don't expect POLLOUT
to be set until all software buffers have been drained and the data has
been written to the device completely. Unless I'm doing something wrong or
misinterpreting something, this doesn't seem to be the case.
Another simplified way of looking at this in stub code:
{
open_wavefile_for_reading();
open_audio_device_for_writing();
set_audio_device_to_non_blocking_mode();
read_large_chunk_of_data_from_wavefile();
write_large_chunk_of_data_to_audio_device();
poll_for_POLLOUT_on_audio_device();
}
I'd expect this to play the large chunk of data but it returns almost
immediately, only playing a fraction of a second.
I'm not sure whether this is a misconception on my part.
[PATCH] dovecot: enable GSSAPI mechanism
While toying around I noticed the GSSAPI mechanism doesn't work in dovecot.
I think the BUILTIN_GSSAPI define is missing prohibiting registration of the
GSSAPI mechansim.
see: src/auth/mech-gssapi.c, src/auth/mech.c
This replacement of the 'patch-configure_in' file made it possible for me to
authenticate using GSSAPI. It just adds the line:
AC_DEFINE(BUILTIN_GSSAPI,, GSSAPI support is built in)
(since I was just playing with dovecot, consider it (very) lightly tested)
--- configure.in.orig Wed Feb 4 00:41:16 2009
+++ configure.inSun Jul 5 18:15:05 2009
@@ -13,6 +13,7 @@
AC_HEADER_STDC
AC_C_INLINE
AC_PROG_LIBTOOL
+LIBS=${LIBS} -liconv
AM_ICONV
AC_CHECK_HEADERS(strings.h stdint.h unistd.h dirent.h malloc.h inttypes.h \
@@ -1797,74 +1798,16 @@
have_gssapi=no
if test $want_gssapi != no; then
- AC_CHECK_PROG(KRB5CONFIG, krb5-config, YES, NO)
- if test $KRB5CONFIG = YES; then
- if ! krb5-config --version gssapi 2/dev/null /dev/null; then
- # krb5-config doesn't support gssapi.
- KRB5_LIBS=`krb5-config --libs`
- KRB5_CFLAGS=`krb5-config --cflags`
- AC_CHECK_LIB(gss, gss_acquire_cred, [
- # Solaris
- KRB5_LIBS=$KRB5_LIBS -lgss
- ], [
- # failed
- KRB5_LIBS=
- ], $KRB5_LIBS)
- else
- KRB5_LIBS=`krb5-config --libs gssapi`
- KRB5_CFLAGS=`krb5-config --cflags gssapi`
- fi
- if test $KRB5_LIBS != ; then
- AC_SUBST(KRB5_LIBS)
- AC_SUBST(KRB5_CFLAGS)
-
- # Although krb5-config exists, all systems still don't
- # have gssapi.h
- old_CFLAGS=$CFLAGS
- CFLAGS=$CFLAGS $KRB5_CFLAGS
- AC_CHECK_HEADER([gssapi/gssapi.h], [
- AC_DEFINE(HAVE_GSSAPI_GSSAPI_H,, GSSAPI headers
in gssapi/gssapi.h)
- have_gssapi=yes
- ])
- AC_CHECK_HEADER([gssapi.h], [
- AC_DEFINE(HAVE_GSSAPI_H,, GSSAPI headers in
gssapi.h)
- have_gssapi=yes
- ])
- if test $have_gssapi = yes; then
- AC_DEFINE(HAVE_GSSAPI,, Build with GSSAPI
support)
- AC_CHECK_HEADERS(gssapi/gssapi_ext.h
gssapi_krb5.h gssapi/gssapi_krb5.h)
- AC_CHECK_LIB(gss, __gss_userok, [
- AC_DEFINE(HAVE___GSS_USEROK,,
- Define if you have
__gss_userok())
- KRB5_LIBS=$KRB5_LIBS -lgss
- ],, $KRB5_LIBS)
-
- # MIT has a #define for Heimdal
acceptor_identity, but it's way too
- # difficult to test for it..
- old_LIBS=$LIBS
- LIBS=$LIBS $KRB5_LIBS
-
AC_CHECK_FUNCS(gsskrb5_register_acceptor_identity
krb5_gss_register_acceptor_identity)
- LIBS=$old_LIBS
-
- if test x$want_gssapi_plugin != xyes; then
- AUTH_LIBS=$AUTH_LIBS $KRB5_LIBS
- AUTH_CFLAGS=$AUTH_CFLAGS $KRB5_CFLAGS
- AC_DEFINE(BUILTIN_GSSAPI,, GSSAPI support is
built in)
- else
- have_gssapi_plugin=yes
- fi
- else
- if test $want_gssapi = yes; then
- AC_ERROR([Can't build with GSSAPI support: gssapi.h
not found])
- fi
- fi
- CFLAGS=$old_CFLAGS
- fi
- else
- if test $want_gssapi = yes; then
- AC_ERROR([Can't build with GSSAPI support: krb5-config not found])
- fi
- fi
+ # no krb5-config on OpenBSD, bring in the necessary libs and includes
+ # manually
+ AC_CHECK_HEADER([kerberosV/gssapi.h], [
+ AC_DEFINE(HAVE_GSSAPI,, Build with GSSAPI support)
+ AC_DEFINE(HAVE_GSSAPI_H,, Build with GSSAPI support)
+ AC_DEFINE(HAVE_GSSKRB5_REGISTER_ACCEPTOR_IDENTITY,, Have the
gsskrb5_register_acceptor_identity function)
+ AC_DEFINE(BUILTIN_GSSAPI,, GSSAPI support is built in)
+ have_gssapi=yes
+ ])
+ AUTH_LIBS=$LIBS -lkrb5 -lgssapi -lcrypto
fi
AM_CONDITIONAL(GSSAPI_PLUGIN, test $have_gssapi_plugin = yes)
