Re: CUPS woes
On Wednesday 08 August 2007 11:54:55 Lars Hansson wrote: client-error-document-format-not-supported: Unsupported format 'application/postscript Do you have ghostscript installed? -- Antoine
Re: CUPS woes
On 8/8/07, Antoine Jacoutot [EMAIL PROTECTED] wrote: Do you have ghostscript installed? Yes: $ pkg_info | grep ghost ghostscript-8.54p1 GNU PostScript interpreter ghostscript-fonts-8.11 35 standard PostScript fonts with Adobe name aliases hpijs-1.5p0 HP Inkjet driver for ghostscript --- Lars Hansson
xpp core dump
Base system snapshot from August 2, xpp 1.5 dumps core on exit. If you try to print something it will print it (ie send it to CUPS) but still dump core on exit. cups is 1.2.7p3. --- Lars Hansson
Re: xpp core dump
Forgot: due to segmentation fault: $ xpp Segmentation fault (core dumped) --- Lars Hansson
Re: xpp core dump
Also, not everything seems to be right with xpp itself (even though it can print): http://users.unet.net.ph/~lars/images/xpp.png Apparently nothing is known about the printer even though it shows up as ready in the CUPS web interface. --- Lars Hansson
Re: esound 0.2.34 - 0.2.38 problems on auich
On Fri, Aug 03, 2007 at 08:06:08PM +0200, Tim van der Molen wrote:
I looked over esound, and the following patch is all I can see that
could even remotely be a problem with the audio interface.
I tested your patch using ogg123 and libao's esd module.
The stuttering is almost completely gone, but ogg123 has problems to
start playing music.
If I run ogg123, its time counter counts very fast for a while.
Meanwhile, I hear no sound. At some point, the time count is normal and
I hear the music stuttering for a moment, but after that it is fine. The
music stutters very seldomly.
The duration of the `fast time count' depends on the time I haven't used
esound. The longer the time between two ogg123 invocations, the longer
the fast time count goes on. Waiting 10 seconds results in the fast time
count going to ~ 6 seconds; waiting ~ 5 minutes results in the fast time
count going to ~ 2.5 minutes.
I think I finally figured out what's happening here.
esound quits sending data to the audio device.
audio(4) says that if you let the buffer run out, then you
have to catch up before it will start playing back, unless
you are in AUMODE_PLAY_ALL mode, and this is indeed enforced
in the audio layer.
I don't know if previous versions of esound sent silence to
/dev/audio instead of pausing, or what, but 0.2.38 definitely
quits sending audio data.
this fixes the problem where clients skip through the
first bit of playback, length of skip depending on time
since esd's last activity (since it's trying to catch up).
it may also fix some crackling which could be produced by
quick starts and stops because of timing discrepencies, which could
happen if esound is not quite correct in it's delay calculations, or
if the audio device is not actually consuming data at the rate it
should. in such a case, the audio layer will pad in some silence
to keep things smooth in AUMODE_PLAY_ALL mode.
I'm also including the previous patch I sent to ports@, because
it was reported to help. however, it could actually work against
the AUMODE_PLAY_ALL change, because there could possibly be
fewer times padding will happen (but then there should also
be less time when it need to be padded as well ...). if this
patch in it's entirety does not fix the crackling, please try
again without the last chunk.
--
[EMAIL PROTECTED]
SDF Public Access UNIX System - http://sdf.lonestar.org
Index: Makefile
===
RCS file: /home/cvs/OpenBSD/ports/audio/esound/Makefile,v
retrieving revision 1.40
diff -u -r1.40 Makefile
--- Makefile26 Jun 2007 17:10:29 - 1.40
+++ Makefile8 Aug 2007 10:52:52 -
@@ -4,6 +4,7 @@
COMMENT= sound library for Enlightenment
DISTNAME= esound-0.2.38
+PKGNAME= ${DISTNAME}p0
SHARED_LIBS += esd 2.38 # .2.38
CATEGORIES=audio
MASTER_SITES= ${MASTER_SITE_GNOME:=sources/esound/0.2/}
Index: files/audio_sun.c
===
RCS file: /home/cvs/OpenBSD/ports/audio/esound/files/audio_sun.c,v
retrieving revision 1.3
diff -u -r1.3 audio_sun.c
--- files/audio_sun.c 25 Jan 2004 22:07:28 - 1.3
+++ files/audio_sun.c 8 Aug 2007 10:52:52 -
@@ -58,13 +58,11 @@
/* set the appropriate mode */
if((esd_audio_format ESD_MASK_FUNC) == ESD_RECORD) {
mode = O_RDWR;
- info.mode = AUMODE_PLAY | AUMODE_RECORD;
+ info.mode = AUMODE_PLAY_ALL | AUMODE_RECORD;
} else {
- info.mode = AUMODE_PLAY;
+ info.mode = AUMODE_PLAY_ALL;
}
-mode |= O_NONBLOCK;
-
/* open the sound device */
device = esd_audio_device ? esd_audio_device : /dev/audio;
if ((afd = open(device, mode, 0)) == -1) {
@@ -72,10 +70,6 @@
return( -2 );
}
-mode = fcntl(afd, F_GETFL);
-mode = ~O_NONBLOCK;
-fcntl(afd, F_SETFL, mode);
-
/* set the requested mode */
if(ioctl(afd, AUDIO_SETINFO, info) 0) {
sun_panic(afd, AUDIO_SETINFO);
@@ -132,6 +126,20 @@
if(ioctl(afd, AUDIO_SETINFO, info) 0 ||
fabs(info.play.sample_rate - esd_audio_rate) esd_audio_rate * 0.05) {
fprintf(stderr, Unsupported rate: %i Hz\n, esd_audio_rate);
+ sun_panic(afd, SETINFO);
+ return(-1);
+}
+
+/* OSS interface sets the blocksize to 256 bytes, but esound
+ * actually uses 8192 byte blocks for 16-bit encodings and 4096
+ * byte blocks for 8-bit encodings.
+ */
+if (enc.precision == 16)
+info.blocksize = 8192;
+else
+info.blocksize = 4096;
+if(ioctl(afd, AUDIO_SETINFO, info) == -1) {
+ fprintf(stderr, Unsupported blocksize: %d\n, info.blocksize);
sun_panic(afd, SETINFO);
return(-1);
}
NEW devel/openocd
Hi folks! I've ported openocd (Open On-Chip Debugger, http://openocd.berlios.de/web/). It works pretty well on OpenBSD now and allows me to flash/debug my AT91SAM7 using parallel port jtag wiggler. However, only parallel adapters work for now. This is a release of openocd svn revision 188. This is my first port, so please feel free to blame me a lot. Sorry for only one MASTER_SITES, i can't provide any more now. port tarball available on ftp://vpns.reklamy.ru/pub/openocd.tar -- I do not fear computers. I fear the lack of them. (c) openocd.tar Description: Unix tar archive
Re: NEW devel/openocd
On Wed, Aug 08, 2007 at 03:30:49PM +0400, Nickolay A. Burkov wrote:
I've ported openocd (Open On-Chip Debugger,
http://openocd.berlios.de/web/). It works pretty well on
OpenBSD now and allows me to flash/debug my AT91SAM7 using
parallel port jtag wiggler. However, only parallel adapters work
for now.
This is a release of openocd svn revision 188.
This is my first port, so please feel free to blame me a lot.
Sorry for only one MASTER_SITES, i can't provide any more now.
port tarball available on ftp://vpns.reklamy.ru/pub/openocd.tar
The tree is in soft lock now; please spend your time testing ports
already in the tree. Hold onto your port for now and resubmit it
after the tree unlocks.
http://marc.info/?l=openbsd-portsm=118609297808504w=2
http://marc.info/?l=openbsd-portsm=118649135223091w=2
--
o--{ Will Maier }--o
| web:...http://www.lfod.us/ | [EMAIL PROTECTED] |
*--[ BSD Unix: Live Free or Die ]--*
jdk-1.5.0.12: Broken?
Hi there Kurt and ports@ I tried to build java on a clean snapshot today, and the xalan-j checksums failed. # make install === Checking files for jdk-1.5.0.12 `/usr/ports/distfiles/jdk-1_5_0_12-fcs-src-b04-jrl-02_may_2007.jar' is up to date. `/usr/ports/distfiles/jdk-1_5_0_12-fcs-bin-b04-jrl-02_may_2007.jar' is up to date. `/usr/ports/distfiles/bsd-jdk15-patches-6.tar.bz2' is up to date. `/usr/ports/distfiles/jdk-1_5_0_12-solaris-i586.tar.Z' is up to date. `/usr/ports/distfiles/xalan-j_2_7_0-bin.tar.gz' is up to date. (SHA256) jdk-1_5_0_12-fcs-src-b04-jrl-02_may_2007.jar: OK (SHA256) jdk-1_5_0_12-fcs-bin-b04-jrl-02_may_2007.jar: OK (SHA256) bsd-jdk15-patches-6.tar.bz2: OK (SHA256) jdk-1_5_0_12-solaris-i586.tar.Z: OK (SHA256) xalan-j_2_7_0-bin.tar.gz: FAILED Checksum mismatch for xalan-j_2_7_0-bin.tar.gz. (sha256) Make sure the Makefile and checksum file (/usr/ports/devel/jdk/1.5/distinfo) are up to date. If you want to fetch a good copy of this file from the OpenBSD main archive, type make REFETCH=true [other args]. I have tried refetching the file several times, and eventually i tried make makesum make install (to remake the checksums, assuming that was the file the developer intended me to download) and I am faced with the follwoing: ocessor.TransformerFactoryImpl -Djavax.xml.parsers.DocumentBuilderFactory=org.apache.xerces.jaxp.DocumentBuilderFactoryImp l -Djavax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl -classpath /usr/ports/devel/jdk/1.5/w-j dk-1.5.0.12/hotspot/../xalan-j_2_7_0/xalan.jar:../generated/jvmtifiles jvmtiGen -IN /usr/ports/devel/jdk/1.5/w-jdk-1.5.0.1 2/hotspot/src/share/vm/prims/jvmti.xml -XSL /usr/ports/devel/jdk/1.5/w-jdk-1.5.0.12/hotspot/src/share/vm/prims/jvmdiEnter. xsl -OUT ../generated/jvmtifiles/jvmdiEnter.cpp -PARAM interface jvmdi java.lang.NullPointerException at gnu.xml.transform.WithParam.getValue (WithParam.java:89) at gnu.xml.transform.ApplyTemplatesNode.doApply (ApplyTemplatesNode.java:112) at gnu.xml.transform.TemplateNode.apply (TemplateNode.java:79) at gnu.xml.transform.TextNode.doApply (TextNode.java:102) at gnu.xml.transform.TemplateNode.apply (TemplateNode.java:79) at gnu.xml.transform.ValueOfNode.doApply (ValueOfNode.java:115) at gnu.xml.transform.TemplateNode.apply (TemplateNode.java:79) at gnu.xml.transform.TextNode.doApply (TextNode.java:102) at gnu.xml.transform.TemplateNode.apply (TemplateNode.java:79) at gnu.xml.transform.TextNode.doApply (TextNode.java:102) at gnu.xml.transform.TemplateNode.apply (TemplateNode.java:79) at gnu.xml.transform.ValueOfNode.doApply (ValueOfNode.java:115) at gnu.xml.transform.TemplateNode.apply (TemplateNode.java:79) at gnu.xml.transform.TextNode.doApply (TextNode.java:102) at gnu.xml.transform.TemplateNode.apply (TemplateNode.java:79) at gnu.xml.transform.TextNode.doApply (TextNode.java:102) at gnu.xml.transform.TemplateNode.apply (TemplateNode.java:79) at gnu.xml.transform.ParameterNode.doApply (ParameterNode.java:100) at gnu.xml.transform.TemplateNode.apply (TemplateNode.java:79) at gnu.xml.transform.ApplyTemplatesNode.doApply (ApplyTemplatesNode.java:153) at gnu.xml.transform.TemplateNode.apply (TemplateNode.java:79) at gnu.xml.transform.ApplyTemplatesNode.doApply (ApplyTemplatesNode.java:153) at gnu.xml.transform.TemplateNode.apply (TemplateNode.java:79) at gnu.xml.transform.ApplyTemplatesNode.doApply (ApplyTemplatesNode.java:153) at gnu.xml.transform.TemplateNode.apply (TemplateNode.java:79) at gnu.xml.transform.TextNode.doApply (TextNode.java:102) at gnu.xml.transform.TemplateNode.apply (TemplateNode.java:79) at gnu.xml.transform.IfNode.doApply (IfNode.java:88) at gnu.xml.transform.TemplateNode.apply (TemplateNode.java:79) at gnu.xml.transform.TextNode.doApply (TextNode.java:102) at gnu.xml.transform.TemplateNode.apply (TemplateNode.java:79) at gnu.xml.transform.OtherwiseNode.doApply (OtherwiseNode.java:69) at gnu.xml.transform.TemplateNode.apply (TemplateNode.java:79) at gnu.xml.transform.WhenNode.doApply (WhenNode.java:90) at gnu.xml.transform.TemplateNode.apply (TemplateNode.java:79) at gnu.xml.transform.ChooseNode.doApply (ChooseNode.java:69) at gnu.xml.transform.TemplateNode.apply (TemplateNode.java:79) at gnu.xml.transform.ApplyTemplatesNode.doApply (ApplyTemplatesNode.java:165) at gnu.xml.transform.TemplateNode.apply (TemplateNode.java:79) at gnu.xml.transform.TextNode.doApply (TextNode.java:102) at gnu.xml.transform.TemplateNode.apply (TemplateNode.java:79) at gnu.xml.transform.ApplyTemplatesNode.doApply (ApplyTemplatesNode.java:165) at gnu.xml.transform.TemplateNode.apply (TemplateNode.java:79) at gnu.xml.transform.TextNode.doApply (TextNode.java:102) at gnu.xml.transform.TemplateNode.apply (TemplateNode.java:79) at gnu.xml.transform.ApplyTemplatesNode.doApply (ApplyTemplatesNode.java:165) at
Re: jdk-1.5.0.12: Broken?
On 8/8/07, Kurt Miller [EMAIL PROTECTED] wrote: Someone else reported this to me but I can't reproduce it. In their case using wget to retrieve the xalan-j_2_7_0-bin.tar.gz distfile resolved the issue of the server closing the connection prematurely and borking the distfile. I had the same problem. I resolved it in using an apache mirror. Edd Barrett wrote: Hi there Kurt and ports@ I tried to build java on a clean snapshot today, and the xalan-j checksums failed. # make install === Checking files for jdk-1.5.0.12 `/usr/ports/distfiles/jdk-1_5_0_12-fcs-src-b04-jrl-02_may_2007.jar' is up to date. `/usr/ports/distfiles/jdk-1_5_0_12-fcs-bin-b04-jrl-02_may_2007.jar' is up to date. `/usr/ports/distfiles/bsd-jdk15-patches-6.tar.bz2' is up to date. `/usr/ports/distfiles/jdk-1_5_0_12-solaris-i586.tar.Z' is up to date. `/usr/ports/distfiles/xalan-j_2_7_0-bin.tar.gz' is up to date. (SHA256) jdk-1_5_0_12-fcs-src-b04-jrl-02_may_2007.jar: OK (SHA256) jdk-1_5_0_12-fcs-bin-b04-jrl-02_may_2007.jar: OK (SHA256) bsd-jdk15-patches-6.tar.bz2: OK (SHA256) jdk-1_5_0_12-solaris-i586.tar.Z: OK (SHA256) xalan-j_2_7_0-bin.tar.gz: FAILED Checksum mismatch for xalan-j_2_7_0-bin.tar.gz. (sha256) Make sure the Makefile and checksum file (/usr/ports/devel/jdk/1.5/distinfo) are up to date. If you want to fetch a good copy of this file from the OpenBSD main archive, type make REFETCH=true [other args]. I have tried refetching the file several times, and eventually i tried make makesum make install (to remake the checksums, assuming that was the file the developer intended me to download) and I am faced with the follwoing: ocessor.TransformerFactoryImpl -Djavax.xml.parsers.DocumentBuilderFactory=org.apache.xerces.jaxp.DocumentBuilderFactoryImp l -Djavax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl -classpath /usr/ports/devel/jdk/1.5/w-j dk-1.5.0.12/hotspot/../xalan-j_2_7_0/xalan.jar:../generated/jvmtifiles jvmtiGen -IN /usr/ports/devel/jdk/1.5/w-jdk-1.5.0.1 2/hotspot/src/share/vm/prims/jvmti.xml -XSL /usr/ports/devel/jdk/1.5/w-jdk-1.5.0.12/hotspot/src/share/vm/prims/jvmdiEnter. xsl -OUT ../generated/jvmtifiles/jvmdiEnter.cpp -PARAM interface jvmdi java.lang.NullPointerException at gnu.xml.transform.WithParam.getValue (WithParam.java:89) at gnu.xml.transform.ApplyTemplatesNode.doApply (ApplyTemplatesNode.java:112) at gnu.xml.transform.TemplateNode.apply (TemplateNode.java:79) at gnu.xml.transform.TextNode.doApply (TextNode.java:102) at gnu.xml.transform.TemplateNode.apply (TemplateNode.java:79) at gnu.xml.transform.ValueOfNode.doApply (ValueOfNode.java:115) at gnu.xml.transform.TemplateNode.apply (TemplateNode.java:79) at gnu.xml.transform.TextNode.doApply (TextNode.java:102) at gnu.xml.transform.TemplateNode.apply (TemplateNode.java:79) at gnu.xml.transform.TextNode.doApply (TextNode.java:102) at gnu.xml.transform.TemplateNode.apply (TemplateNode.java:79) at gnu.xml.transform.ValueOfNode.doApply (ValueOfNode.java:115) at gnu.xml.transform.TemplateNode.apply (TemplateNode.java:79) at gnu.xml.transform.TextNode.doApply (TextNode.java:102) at gnu.xml.transform.TemplateNode.apply (TemplateNode.java:79) at gnu.xml.transform.TextNode.doApply (TextNode.java:102) at gnu.xml.transform.TemplateNode.apply (TemplateNode.java:79) at gnu.xml.transform.ParameterNode.doApply (ParameterNode.java:100) at gnu.xml.transform.TemplateNode.apply (TemplateNode.java:79) at gnu.xml.transform.ApplyTemplatesNode.doApply (ApplyTemplatesNode.java:153) at gnu.xml.transform.TemplateNode.apply (TemplateNode.java:79) at gnu.xml.transform.ApplyTemplatesNode.doApply (ApplyTemplatesNode.java:153) at gnu.xml.transform.TemplateNode.apply (TemplateNode.java:79) at gnu.xml.transform.ApplyTemplatesNode.doApply (ApplyTemplatesNode.java:153) at gnu.xml.transform.TemplateNode.apply (TemplateNode.java:79) at gnu.xml.transform.TextNode.doApply (TextNode.java:102) at gnu.xml.transform.TemplateNode.apply (TemplateNode.java:79) at gnu.xml.transform.IfNode.doApply (IfNode.java:88) at gnu.xml.transform.TemplateNode.apply (TemplateNode.java:79) at gnu.xml.transform.TextNode.doApply (TextNode.java:102) at gnu.xml.transform.TemplateNode.apply (TemplateNode.java:79) at gnu.xml.transform.OtherwiseNode.doApply (OtherwiseNode.java:69) at gnu.xml.transform.TemplateNode.apply (TemplateNode.java:79) at gnu.xml.transform.WhenNode.doApply (WhenNode.java:90) at gnu.xml.transform.TemplateNode.apply (TemplateNode.java:79) at gnu.xml.transform.ChooseNode.doApply (ChooseNode.java:69) at gnu.xml.transform.TemplateNode.apply (TemplateNode.java:79) at gnu.xml.transform.ApplyTemplatesNode.doApply (ApplyTemplatesNode.java:165) at
sysutils/login_ldap: Misleading manpage
Hi All, While trying to setup login_ldap, i stumbled on a somewhat misleading phrase in the manpage: x-ldap-binddn DN used by login_ldap to bind to the ldap server. Can be (NULL) for anonymous bind. x-ldap-bindpw Password used by login_ldap to bind to the ldap server. Can be (NULL) for anonymous bind. This seems to suggest that you can put :x-ldap-binddn=:\ into your /etc/login.conf if you want to bind anonymously. This does not work and login is rejected without a proper debug message. The entry *must* read: :x-ldap-binddn=:\ (without quotes) Since this took me a few hours of debugging, i thought i should let you all know. Regards, Heinrich Rebehn University of Bremen Physics / Electrical and Electronics Engineering - Department of Telecommunications - Phone : +49/421/218-4664 Fax :-3341
Re: jdk-1.5.0.12: Broken?
On Wed, Aug 08, 2007 at 10:01:40AM -0400, Kurt Miller wrote:
Someone else reported this to me but I can't reproduce it. In
their case using wget to retrieve the xalan-j_2_7_0-bin.tar.gz
distfile resolved the issue of the server closing the connection
prematurely and borking the distfile.
Works for me too, using our in-tree ftp client:
$ ftp http://www.apache.org/dist/xml/xalan-j/xalan-j_2_7_0-bin.tar.gz
$ md5 -b xalan*
1SbQhIyIYHzk46Ck7bddUA==
# quick way to tell if one distfile matches without fetching the others
$ grep $(md5 -b xalan* | awk '{print $NF}') distinfo
MD5 (xalan-j_2_7_0-bin.tar.gz) = 1SbQhIyIYHzk46Ck7bddUA==
Fetch works, checksums match.
Re: jdk-1.5.0.12: Broken?
On 08/08/2007, Kurt Miller [EMAIL PROTECTED] wrote: Someone else reported this to me but I can't reproduce it. In their case using wget to retrieve the xalan-j_2_7_0-bin.tar.gz distfile resolved the issue of the server closing the connection prematurely and borking the distfile. How odd and incredibly annoying. I am using firefox to downlaod distfiles. -- Best Regards Edd --- http://students.dec.bournemouth.ac.uk/ebarrett
Tor 1.2.16 - Security hole
I hate to call Rui out in public but he is the maintainer here and very non responsive to private emails about this. Tor 1.1.x has BEEN DEPRECIATED from before the time 4.1 STABLE was released (you were notified of this also Rui) and all version earlier than 1.2.15 suffer a remote code exploitation which has been proven in the wild already with technical details to be released to the public in two week per the developers. The developers announced all users should update immediately yet still not seeing this port updated in stable when I csup. Can you (Rui) update this port finally as it would count as a security update or you just going to hang out and continue to be a subpar maintainer. If you don't want to maintain your own port then let me know and I or somebody else can do it but this is ridiculous. You missed the last couple stable releases and when informed of it you were like what the f*ck do I care ... OBSD isn't about the latest and greatest. Compile it yourself. Well now we have a serious remote code issue and a depreciated non-supported (in the current tor directory services) package in OBSD ... is this a big enough issue to get you to care? NOTE: I am pretty indifferent if it is fixed in CURRENT. This is a remote code exploit and I am pretty sure security patches are merged into stable's port tree considering I see updates to it at least weekly. Sorry to be an ass Rui but with maintenance comes responsibility. -Peter
Re: Tor 1.2.16 - Security hole
On Wed, Aug 08, 2007 at 11:47:56AM -0400, Peter Thoenen wrote:
I hate to call Rui out in public but he is the maintainer here and
very non responsive to private emails about this.
A fix (up to 0.1.2.16) was committed to -current yesterday; it was
MFCed this morning.
http://www.openbsd.org/cgi-bin/cvsweb/ports/net/tor/Makefile?rev=1.30content-type=text/x-cvsweb-markup
The rest of your post is rude. If a maintainer isn't being
responsive, a (non-rude) note to ports@ should be sufficient. A
screed will rarely make things happen any sooner; patches tend to
help things along.
--
o--{ Will Maier }--o
| web:...http://www.lfod.us/ | [EMAIL PROTECTED] |
*--[ BSD Unix: Live Free or Die ]--*
Re: Tor 1.2.16 - Security hole
On 8/8/07, Peter Thoenen [EMAIL PROTECTED] wrote: I hate to call Rui out in public but he is the maintainer here and very non responsive to private emails about this. Tor 1.1.x has BEEN DEPRECIATED from before the time 4.1 STABLE was released (you were notified of this also Rui) and all version earlier Can you share where you are getting this from? http://tor.eff.org/download.html.en The latest stable release is 0.1.2.16, and the latest development release is 0.2.0.4-alpha. We normally follow -stable ports and not alpha code snapshots from projects' development branches so I am afraid I see nothing improper here! Additionally: 2007-08-01: Tor 0.2.0.4-alpha fixes a critical security vulnerability for most users, specifically those running Vidalia, TorK, etc. Everybody should upgrade. 2007-08-01: Tor 0.1.2.16 fixes a critical security vulnerability for most users, specifically those running Vidalia, TorK, etc. Everybody should upgrade. I'm sorry but the bug affected BOTH stable AND the snapshot so you are on drugs that it would have helped. And you are an asshole for calling out Rui in the manner that you did! than 1.2.15 suffer a remote code exploitation which has been proven in the wild already with technical details to be released to the public in two week per the developers. The developers announced all users should update immediately yet still not seeing this port updated in stable when The port has been updated in -current immediately after this happened and this is where development happens. This is a volunteer project and -stable is not with priority.
pidgin-2.1.0p0 cannot compile
Hi, I'm using an OpenBSD snapshot from 2007-08-06, and when I'm trying to update pidgin, it ends up like this: cc -O2 -pipe -o .libs/finch gntaccount.o gntblist.o gntconn.o gntconv.o gntdebug.o gntft.o finch.o gntidle.o gntnotify.o gntplugin.o gntpounce.o gntprefs.o gntrequest.o gntsound.o gntstatus.o gntui.o -pthread -Wl,-E -pthread -Wl,-E -L/usr/local/lib -L/usr/X11R6/lib -L./libgnt/.libs -lgnt -lpanel -L../libpurple/.libs -lpurple -lxml2 -lm -lz -lgthread-2.0 -lgmodule-2.0 -ldbus-glib-1 -lgobject-2.0 -lglib-2.0 -liconv -lintl -ldbus-1 -pthread -lncurses -Wl,-rpath,/usr/local/lib /usr/local/lib/libpurple.so.0.0: warning: vsprintf() is often misused, please use vsnprintf() /usr/local/lib/libpurple.so.0.0: warning: strcpy() is almost always misused, please use strlcpy() /usr/local/lib/libpurple.so.0.0: warning: sprintf() is often misused, please use snprintf() /usr/local/lib/libxml2.so.9.6: warning: strcat() is almost always misused, please use strlcat() gntaccount.o(.text+0x71d): In function `update_user_splits': : undefined reference to `purple_account_user_split_get_reverse' gntaccount.o(.text+0x16df): In function `finch_accounts_show_all': : undefined reference to `gnt_window_present' gntaccount.o(.text+0x19ab): In function `finch_accounts_show_all': : undefined reference to `gnt_util_set_trigger_widget' gntaccount.o(.text+0x1aa8): In function `finch_accounts_show_all': : undefined reference to `gnt_util_set_trigger_widget' gntblist.o(.text+0x11d1): In function `selection_activate': : undefined reference to `gnt_window_present' gntblist.o(.text+0x28ee): In function `draw_tooltip_real': : undefined reference to `gnt_text_view_set_flag' gntblist.o(.text+0x2d17): In function `key_pressed': : undefined reference to `gnt_tree_is_searching' gntblist.o(.text+0x4d3c): In function `blist_show': : undefined reference to `gnt_window_present' gntconv.o(.text+0x10dc): In function `finch_create_conversation': : undefined reference to `gnt_text_view_attach_pager_widget' gntdebug.o(.text+0x40d): In function `finch_debug_window_show': : undefined reference to `gnt_window_present' gntdebug.o(.text+0x80a): In function `finch_debug_window_show': : undefined reference to `gnt_text_view_attach_pager_widget' gntft.o(.text+0x3ff): In function `finch_xfer_dialog_new': : undefined reference to `gnt_tree_set_column_width_ratio' gntft.o(.text+0x422): In function `finch_xfer_dialog_new': : undefined reference to `gnt_tree_set_column_resizable' gntft.o(.text+0x445): In function `finch_xfer_dialog_new': : undefined reference to `gnt_tree_set_column_resizable' gntft.o(.text+0x468): In function `finch_xfer_dialog_new': : undefined reference to `gnt_tree_set_column_resizable' gntft.o(.text+0x48b): In function `finch_xfer_dialog_new': : undefined reference to `gnt_tree_set_column_resizable' gntft.o(.text+0x837): In function `finch_xfer_dialog_show': : undefined reference to `gnt_window_present' gntnotify.o(.text+0xfde): In function `finch_notify_searchresults': : undefined reference to `gnt_tree_set_column_title' gntplugin.o(.text+0x7e7): In function `finch_plugins_show_all': : undefined reference to `gnt_window_present' gntpounce.o(.text+0xa8): In function `populate_pounces_list': : undefined reference to `purple_pounces_get_all_for_ui' gntpounce.o(.text+0x1b08): In function `finch_pounces_manager_show': : undefined reference to `gnt_window_present' gntpounce.o(.text+0x1cb5): In function `finch_pounces_manager_show': : undefined reference to `gnt_util_set_trigger_widget' gntpounce.o(.text+0x1d9f): In function `finch_pounces_manager_show': : undefined reference to `gnt_util_set_trigger_widget' gntprefs.o(.text+0x4b4): In function `finch_prefs_show_all': : undefined reference to `gnt_window_present' gntstatus.o(.text+0x2d4): In function `finch_savedstatus_show_all': : undefined reference to `gnt_window_present' gntstatus.o(.text+0x43d): In function `finch_savedstatus_show_all': : undefined reference to `gnt_tree_set_column_width_ratio' gntstatus.o(.text+0x56b): In function `finch_savedstatus_show_all': : undefined reference to `gnt_util_set_trigger_widget' gntstatus.o(.text+0x64f): In function `finch_savedstatus_show_all': : undefined reference to `gnt_util_set_trigger_widget' collect2: ld returned 1 exit status gmake[3]: *** [finch] Error 1 gmake[3]: Leaving directory `/usr/ports/net/pidgin/w-pidgin-2.1.0p0/build-i386/finch' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory `/usr/ports/net/pidgin/w-pidgin-2.1.0p0/build-i386/finch' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/ports/net/pidgin/w-pidgin-2.1.0p0/build-i386' gmake: *** [all] Error 2 *** Error code 2 Stop in /usr/ports/net/pidgin (line 2063 of /usr/ports/infrastructure/mk/bsd.port.mk). *** Error code 1 Stop in /usr/ports/net/pidgin (line 1373 of /usr/ports/infrastructure/mk/bsd.port.mk). *** Error code 1 Stop in /usr/ports/net/pidgin (line 1861 of /usr/ports/infrastructure/mk/bsd.port.mk). *** Error code 1
Re: Tor 1.2.16 - Security hole
On Wed, Aug 08, 2007 at 11:47:56AM -0400, Peter Thoenen wrote: I hate to call Rui out in public but he is the maintainer here and very non responsive to private emails about this. Tor 1.1.x has BEEN DEPRECIATED from before the time 4.1 STABLE was released (you were notified of this also Rui) and all version earlier than 1.2.15 suffer a remote code exploitation which has been proven in the wild already with technical details to be released to the public in two week per the developers. The developers announced all users should update immediately yet still not seeing this port updated in stable when I csup. Can you (Rui) update this port finally as it would count as a security update or you just going to hang out and continue to be a subpar maintainer. If you don't want to maintain your own port then let me know and I or somebody else can do it but this is ridiculous. You missed the last couple stable releases and when informed of it you were like what the f*ck do I care ... OBSD isn't about the latest and greatest. Compile it yourself. Well now we have a serious remote code issue and a depreciated non-supported (in the current tor directory services) package in OBSD ... is this a big enough issue to get you to care? NOTE: I am pretty indifferent if it is fixed in CURRENT. This is a remote code exploit and I am pretty sure security patches are merged into stable's port tree considering I see updates to it at least weekly. I agree with you on this -current/-stable thingy. This ports tree soft locking shit *how we care about -stable users* is bullshit, when outdated/security vulnerable stuff is even in -current and it takes ages to backport and make packages of needed security updates... I see there no logic, since developers are on -current anyway and they don't care about stable users really... Sorry to be an ass Rui but with maintenance comes responsibility. Can't agree on this, since Rui has been very responsive when I sent him secunia link about flaw. He is not ignorant one ;] And tor update has been commited in 4.1 branch too. However there are another ports which aren't updated. -Peter
Re: Tor 1.2.16 - Security hole
I agree with you on this -current/-stable thingy. This ports tree soft locking shit *how we care about -stable users* is bullshit, when outdated/security vulnerable stuff is even in -current and it takes ages to backport and make packages of needed security updates... I see there no logic, since developers are on -current anyway and they don't care about stable users really... There are likely going to be some changes soon as to how -stable is treated. However, I think you will not like the changes. Many people are quite overworked, unable to proceed forward because they are being pecked to death by whiny users, and are quite sick and tired of these people who whine. The solution will likely comprise some set of: promise less, give less, and listen less.
Re: Tor 1.2.16 - Security hole
* Peter Thoenen [2007-08-08]: Tor 1.1.x has BEEN DEPRECIATED from before the time 4.1 STABLE was Tor 1.2 only came out around the release of 4.1 and no update was marked a security update, so there was no reason to update the -stable ports. We have our policies and we do have them for a good reason. two week per the developers. The developers announced all users should update immediately yet still not seeing this port updated in stable when I csup. So what? Where does the OpenBSD project guarantee you security updates or any service whatsoever within any fixed timeframe? -current was updated within a week and 4.1-stable shortly thereafter. 4.0 will have to wait a little longer. Can you (Rui) update this port finally as it would count as a security update or you just going to hang out and continue to be a subpar maintainer. How about you smart ass send diffs instead of being a subpar user? And btw, we have a process for dealing with unresponsive maintainers. It's documented in the archives, but that of course, would mean a little work on your side finding out... If you don't want to maintain your own port then let me know and I or somebody else can do it but this is ridiculous. You Since 4.1 the tor port was updated within days of the release of a new version. Get your facts straight. Sorry to be an ass Rui but with maintenance comes responsibility. You have a responsibilty as well, mr consumer, care to take it on? Nikolay
Re: x11/kde/bindings3 fix for qtruby
On 08/08 04:30, steven mestdagh wrote:
Jeremy Evans [2007-08-07, 14:26:22]:
The attached patch fixes qtruby (part of kdebindings) so that it can
be used out of the box. Currently, when building kdebindings, .0.0
are added to the ruby .so extensions. Ruby assumes that .so
extensions don't have numeric extensions, so it can't load the files
until the appropriate files are renamed to remove .0.0. This patch
removes the .0.0 extensions before building the package so that qtruby
works out of the box.
Tested on i386. Please test and commit.
Can you try this diff instead?
This diff is certainly the better way to fix the problem. Works for me
on i386.
Marc, are you ok with this?
Index: Makefile
===
RCS file: /cvs/ports/x11/kde/bindings3/Makefile,v
retrieving revision 1.44
diff -u -r1.44 Makefile
--- Makefile 28 Jul 2007 14:08:08 - 1.44
+++ Makefile 8 Aug 2007 14:29:00 -
@@ -8,15 +8,11 @@
CATEGORIES= x11 x11/kde devel
VERSION= 3.5.7
DISTNAME=kdebindings-${VERSION}
-PKGNAME= ${DISTNAME}p0
+PKGNAME= ${DISTNAME}p1
MODKDE_VERSION= 3.5.7
SHARED_LIBS += kjsembed 2.0 # .1.0
SHARED_LIBS += smokeqt 4.0 # .3.2
SHARED_LIBS += smokekde 4.0 # .3.2
-# XXX
-#SHARED_LIBS += qtruby# .0.0
-#SHARED_LIBS += qui # .0.0
-#SHARED_LIBS += korundum # .0.0
LIB_DEPENDS=DCOP,kdecore.=6,kdefx,kdeprint,kdesu,kdeui,khtml,kio,kjs,kmdi,knewstuff,kparts,kscript,kspell,kutils,kwalletclient::x11/kde/libs3
\
qui-mt::x11/qt3 \
Index: patches/patch-korundum_rubylib_korundum_Makefile_in
===
RCS file: patches/patch-korundum_rubylib_korundum_Makefile_in
diff -N patches/patch-korundum_rubylib_korundum_Makefile_in
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-korundum_rubylib_korundum_Makefile_in 8 Aug 2007
14:29:00 -
@@ -0,0 +1,12 @@
+$OpenBSD$
+--- korundum/rubylib/korundum/Makefile.in.orig Wed Aug 8 16:25:03 2007
korundum/rubylib/korundum/Makefile.inWed Aug 8 16:25:12 2007
+@@ -433,7 +433,7 @@ xparts_SUBDIR_included_TRUE = @xparts_SUBDIR_included_
+ INCLUDES = -I$(top_srcdir)/smoke -I$(top_srcdir)/qtruby/rubylib/qtruby
$(all_includes) -I$(RUBY_ARCHDIR)
+ rubylibdir = $(RUBY_SITEARCHDIR)
+ rubylib_LTLIBRARIES = korundum.la
+-korundum_la_LDFLAGS = -module $(all_libraries) -version-info 0:0:0
++korundum_la_LDFLAGS = -module $(all_libraries) -avoid-version
+ #- korundum_la_METASOURCES = AUTO
+ korundum_la_SOURCES = Korundum.cpp kdehandlers.cpp
+ korundum_la_LIBADD = $(LIB_KDE) $(top_builddir)/smoke/kde/libsmokekde.la
$(top_builddir)/qtruby/rubylib/qtruby/libqtrubyinternal.la
Index: patches/patch-qtruby_rubylib_designer_uilib_Makefile_in
===
RCS file:
/cvs/ports/x11/kde/bindings3/patches/patch-qtruby_rubylib_designer_uilib_Makefile_in,v
retrieving revision 1.6
diff -u -r1.6 patch-qtruby_rubylib_designer_uilib_Makefile_in
--- patches/patch-qtruby_rubylib_designer_uilib_Makefile_in 27 May 2007
16:49:44 - 1.6
+++ patches/patch-qtruby_rubylib_designer_uilib_Makefile_in 8 Aug 2007
14:29:00 -
@@ -1,11 +1,13 @@
$OpenBSD: patch-qtruby_rubylib_designer_uilib_Makefile_in,v 1.6 2007/05/27
16:49:44 espie Exp $
--- qtruby/rubylib/designer/uilib/Makefile.in.orig Mon May 14 13:28:58 2007
-+++ qtruby/rubylib/designer/uilib/Makefile.inFri May 25 16:11:06 2007
-@@ -417,7 +417,7 @@ rubylibdir = $(RUBY_SITEARCHDIR)
qtruby/rubylib/designer/uilib/Makefile.inWed Aug 8 16:26:21 2007
+@@ -416,8 +416,8 @@ INCLUDES = -I$(top_srcdir)/smoke -I$(top_srcdir)/qtrub
+ rubylibdir = $(RUBY_SITEARCHDIR)
rubylib_LTLIBRARIES = qui.la
qui_la_SOURCES = qui.cpp
- qui_la_LDFLAGS = -module -export-dynamic $(all_libraries) -version-info
0:0:0
+-qui_la_LDFLAGS = -module -export-dynamic $(all_libraries) -version-info
0:0:0
-qui_la_LIBADD = -lqui
++qui_la_LDFLAGS = -module -export-dynamic $(all_libraries) -avoid-version
+qui_la_LIBADD = -lqui-mt
#- all: all-am
#+ 1
Index: patches/patch-qtruby_rubylib_qtruby_Makefile_in
===
RCS file: patches/patch-qtruby_rubylib_qtruby_Makefile_in
diff -N patches/patch-qtruby_rubylib_qtruby_Makefile_in
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-qtruby_rubylib_qtruby_Makefile_in 8 Aug 2007 14:29:00
-
@@ -0,0 +1,12 @@
+$OpenBSD$
+--- qtruby/rubylib/qtruby/Makefile.in.orig Wed Aug 8 16:26:48 2007
qtruby/rubylib/qtruby/Makefile.inWed Aug 8 16:26:54 2007
+@@ -455,7 +455,7 @@ libqtrubyinternal_la_SOURCES = Qt.cpp
Re: pidgin-2.1.0p0 cannot compile
Mike Swanson [2007-08-08, 10:14:52]: Hi, I'm using an OpenBSD snapshot from 2007-08-06, and when I'm trying to update pidgin, it ends up like this: cc -O2 -pipe -o .libs/finch gntaccount.o gntblist.o gntconn.o gntconv.o gntdebug.o gntft.o finch.o gntidle.o gntnotify.o gntplugin.o gntpounce.o gntprefs.o gntrequest.o gntsound.o gntstatus.o gntui.o -pthread -Wl,-E -pthread -Wl,-E -L/usr/local/lib -L/usr/X11R6/lib -L./libgnt/.libs -lgnt -lpanel -L../libpurple/.libs -lpurple -lxml2 -lm -lz -lgthread-2.0 -lgmodule-2.0 -ldbus-glib-1 -lgobject-2.0 -lglib-2.0 -liconv -lintl -ldbus-1 -pthread -lncurses -Wl,-rpath,/usr/local/lib /usr/local/lib/libpurple.so.0.0: warning: vsprintf() is often misused, please use vsnprintf() /usr/local/lib/libpurple.so.0.0: warning: strcpy() is almost always misused, please use strlcpy() /usr/local/lib/libpurple.so.0.0: warning: sprintf() is often misused, please use snprintf() /usr/local/lib/libxml2.so.9.6: warning: strcat() is almost always misused, please use strlcat() gntaccount.o(.text+0x71d): In function `update_user_splits': : undefined reference to `purple_account_user_split_get_reverse' if you have an older version of pidgin installed, remove it before compiling the new one.
Tor 1.2.16 - Security hole
I am sorry do get my hands dirty with a thread like that but I just can't help my self. The only thing I thought of when reading peters post was: Why the hell didn't he send a patch to the maintainer? -Julian -- Lubarsky's Law of Cybernetic Entomology: There's always one more bug.
Re: Tor 1.2.16 - Security hole
Julian Frede wrote: I am sorry do get my hands dirty with a thread like that but I just can't help my self. The only thing I thought of when reading peters post was: Why the hell didn't he send a patch to the maintainer? because he's busy sucking on a bag of dicks. -Julian --
Re: disc-cover-1.5.2p1 broken?
Hi there, On 03/08/2007, Joachim Schipper [EMAIL PROTECTED] wrote: On Fri, Aug 03, 2007 at 11:11:57AM +0100, Edd Barrett wrote: Whilst testing disc-cover-1.5.2p1 (-current) with texlive, I am unable to have disc-cover read the cdrom drive. It has correctly guessed the device node, but is unable to read the cd. I have checked the permissions on the node and even 777'd /dev/cd0c. Any ideas? No, but ktrace(1) may be helpful in diagnosing the problem further. OK, heres the problem. 22834 perl CALL ioctl(0x3,CDIOCREADSUBCHANNEL,0xcfbf66d0) 22834 perl RET ioctl -1 errno 22 Invalid argument man errno say sthe following about error code 22: 22 EINVAL Invalid argument. Some invalid argument was supplied. (For example, specifying an undefined signal to a signal(3) or kill(2) function). This might not be fault of disc-cover, but perhaps instead the fault of p5-Audio-CD-0.04 The abcde port functions perfectly, so we can rule out bad hardware / bad cd. Basically this port is quite broken, and I do not have the time or motivation to fix it. Nor is the breakage related to the texlive package which I am testing. Unless anyone is willing to take maintainership, I would reccommend it is removed from the ports tree, especially as it is not really an important port. -- Best Regards Edd --- http://students.dec.bournemouth.ac.uk/ebarrett
