Re: pkg_add: can't resolve
Hi!
On Wed, Jan 28, 2009 at 03:48:18PM +0100, Axel Keuchel wrote:
>[...]
>> > This is the next mirror to my hometown.
>> >
>> > After that I have logged out and in again and I have set a .Xdefaults with
>> > "XTerm*loginShell: true".
>> >
>> > But when I try to add a package this happens:
>> >
>> > # pkg_add -i fluxbox /{just an example!}/
>> ^
>> > Can't resolve fluxbox
>> Did you really set PKG_PATH for root? What does these show:
>> # echo $PKG_PATH
>> or
>> $ sudo echo $PKG_PATH
>No, I didn't set PKG_PATH for root. I set it in /home//.profile. I
>thought this is meant by FAQ 15.2.2
>(http://www.openbsd.org/faq/faq15.html#PkgMgmt).
>In fact it is not my first time with OpenBSD. And up to now, it always worked
>for me this way. And with a different mirror it does work today.
Depending on how you become root, the environment might be scrubbed. So
just be sure and *check* it.
>[...]
Of course, the other possibility might be that the mirror might
implement some FTP commands pkg_add needs differently or not at all.
Kind regards,
Hannah.
Re: md5?
Hi! On Thu, Feb 05, 2009 at 05:31:06PM -0500, Brad wrote: >On Thursday 05 February 2009 17:18:43 Marc Balmer wrote: >> shouldn't we abandon md5 in favor of e.g. sha256? >SHA256 has been the default for 2 years now. For ports, yes. For packages, more recently, IIRC. For the "MD5" file in the base distribution, not at all. However, I don't see it as *so very* critical. The practical attacks against MD5 are birthday attacks, not preimages for a given hash. At least not yet. Kind regards, Hannah.
Re: md5?
Hi, Marc! On Thu, Feb 12, 2009 at 05:44:17PM +0100, Marc Espie wrote: >On Thu, Feb 12, 2009 at 04:05:14PM +0100, Hannah Schroeter wrote: >> On Thu, Feb 05, 2009 at 05:31:06PM -0500, Brad wrote: >> >On Thursday 05 February 2009 17:18:43 Marc Balmer wrote: >> >> shouldn't we abandon md5 in favor of e.g. sha256? >> >SHA256 has been the default for 2 years now. >> For ports, yes. For packages, more recently, IIRC. For the "MD5" file >> in the base distribution, not at all. >Packages were dependent on two things: >[...] Just to be sure, there was no intent to criticise the timing, especially not with respect to packages, just to make sure there's no misunderstanding about the extent of the SHA256 support that's already been in for a longer time (checking distfiles in the ports tree). And thanks for the detailed explanations, including those about the aim to ensure backward interoperability even in the hope to make "big" upgrades work even though officially only upgrades from one release to the next one are supported, IIRC. Kind regards, Hannah.
Re: md5?
Hi! On Thu, Feb 12, 2009 at 03:59:20PM +, Christian Weisgerber wrote: >Hannah Schroeter wrote: >> However, I don't see it as *so very* critical. The practical attacks >> against MD5 are birthday attacks, not preimages for a given hash. >> At least not yet. >Actually, if you can overwrite or append a chunk of data, you can >create an MD5 collision at will. This allows for some practical >attacks. >In particular, arbitrary data can be appended to a gzipped file; >gzip will just ignore it on extraction. >In combination this means that creating a modified gzipped file >that shares the MD5 hash and the size of the original is quite >achievable. Ok, I was unaware that you can also, practically feasably, create collisions for *given* hash values (which would be an attack against the MD5 files of OpenBSD, for example, when someone checks the MD5 files from many sources, but downloads the tarballs only from one). What I am aware of is the birthday attacks (choosing some bits of *one* chunk of data someone signs, in parallel crafting another chunk of data with the same MD5 sum you can later substitute, e.g. the recent attack against an SSL CA that still used MD5 for signing certificates). So your scenario is creating a somewhat shorter malicious .tar.gz, and kind of "compensating" for the hash value by varying the appended junk (which is ignored by gzip) - are there already known feasible attacks that do something like that? Would it be too difficult to change the md5 invocation in the release target in /usr/src/etc into sha1 or sha256 (i.e. cksum -a sha256), or just to *add* them there? (And perhaps add creation of a kind of xMD5 file or xSHA... file into /usr/xenocara's Makefile, e.g. in the dist target after maketars and checkflist... That would make checksums work without needing to synchronize base vs. X builds on the build hosts.) Kind regards, Hannah.
Re: [Update] plib
Hi! There's a typo in the port (not patched in but in the context): On Fri, Mar 13, 2009 at 11:04:25AM +0100, Simon Bertrang wrote: >[...] >--- Makefile 10 Nov 2008 22:10:22 - 1.1.1.1 >+++ Makefile 13 Mar 2009 10:03:46 - >@@ -1,11 +1,9 @@ > # $OpenBSD: Makefile,v 1.1.1.1 2008/11/10 22:10:22 ajacoutot Exp $ > >-# needs joystick.h >-ONLY_FOR_ARCHS = i386 >- > COMMENT = suite of portable game librairies ^ drop that i. > >[...] Kind regards, Hannah.
Re: qemu: pkg/PLIST contains arch-dependent
Hi! On Fri, Apr 10, 2009 at 10:39:40AM -0400, Brynet wrote: >I attempted such an update to 0.10.1.. but unfortunately it crashes.. >trashing the stack.. I've contacted Todd Fries and he's seen this >behaviour as well in an earlier snapshot release. >The mysterious sparc64 object is related to the BSD userland emulation >target, I couldn't quite figure that one out.. so I just added >--disable-bsd-user to the CONFIGURE_ARGS. >Also, I'm attaching a patch that allows you to compile the PPC >targets.. back ported from SVN. >Todd's suggestion was go back and manually test each revision to find >the commit that broke things, unfortunately that's quite a >undertaking. git has an svn interface and git-bisect. Helped me more than once for identifying commits that broke the company internal stuff (which is officially done in svn too). git-bisect at least automatizes the binary search for the commit, you have to call make and test the stuff manually still. Unless you have a shell script to make and test and exit 0 for good builds and exit != 0 for bad builds, then you can git-bisect using that script to discriminate between good and bad revisions. Kind regards, Hannah.
Re: KDE4_edu
Hi! On Sat, Jun 20, 2009 at 08:09:25AM +0200, Landry Breuil wrote: >[...] >Kde 4 is not linked to the builds for a reason : it needs some time to >be updated and fixed. And I'm glad that kde3 is still available on OpenBSD. Co-workers are having a bad experience with the kde4 (which is there w/o choice on Debian, at least unstable). Kind regards, Hannah.
Re: KDE4_edu
Hi! On Sun, Jun 21, 2009 at 03:36:43AM +0200, Landry Breuil wrote: >On Sat, Jun 20, 2009 at 09:58:30PM +0200, Hannah Schroeter wrote: >> On Sat, Jun 20, 2009 at 08:09:25AM +0200, Landry Breuil wrote: >> >[...] >> >Kde 4 is not linked to the builds for a reason : it needs some time to >> >be updated and fixed. >> And I'm glad that kde3 is still available on OpenBSD. Co-workers are >> having a bad experience with the kde4 (which is there w/o choice on >> Debian, at least unstable). >I didn't imply Kde4 itself had to be fixed :) I didn't mean to say *you* said something to that amount. *I* said that myself, based on the experience of co-workers (and some by seeing it myself when sitting alongside with them at their desks). E.g. (re)painting errors in kde4's konqueror (dunno whether it's a bug of konqueror proper, of khtml [or its successor] or qt4 [but kate doesn't seem to have similar bugs, according to the co-worker who has those experiences). If you experience them, part of the web page is not seen, you see the screen background instead. And it seems to be a slower experience in general, compared to kde3. As long as that is not resolved (upstream, I guess), I'd be happy to have a choice to stay with kde3 instead of upgrading. >I've had some quite good >test reports of 4.2 on various systems, it seems pretty much usable >there. But on OpenBSD, there is still a lot of work to update the >existing port, and fix all the little runtime bugs noone sees when they >don't really _use_ the software. If someone steps up to do this work, >he'll be welcomed. (He has to update cmake first :) cmake :( Another thing I just couldn't stop griping about once I start. >Landry Kind regards, Hannah.
Re: pkg_add kdenetwork-3.2.3 on 3.6 did not install KMail ?
Hello! On Mon, Jun 13, 2005 at 03:43:18PM +0200, Frederic Durodie @ HOME wrote: >Then I proceeded with kdenetwork-3.2.3 expecting to get amongst other an >e-mail client. However whilst several new application were added to the KDE >Internet Menu (KSirc, Remote Desktop Connection, KGet, Kopete, KPPP) I could >not find KMail anywhere. >Any thoughts on what may be the cause ? Install the kdepim package. Should yield kmail and knode, among others. >[...] Kind regards, Hannah.
Re: Erlang Port broken
Hello! On Wed, Jun 15, 2005 at 05:18:01PM +0200, Jonathan Schleifer wrote: >The Erlang port is broken on x86. erl simply segfaults. Running gdb >returns this: >Program received signal SIGSEGV, Segmentation fault. >0x0585dd36 in vsprintf () from /usr/lib/libc.so.37.0 >If someone could debug that further or mark the port broken? There have been at least 2 newer ports submitted, but they were never checked in, even though they both worked at least better than the in-tree one, so even without any further testing they would've been better than the current state of affairs. Of course things like that is a bit frustrating to those making and submitting the ports. Kind regards, Hannah.
graphics/dia installs HTML as BASE/man/man1/dia.1!
Hello! See $SUBJECT for my little problem. The real fix would be making a port for docbook-xsl (current version 1.68.1, from http://sourceforge.net/projects/docbook/), then making that damn thing calling something like xsltproc --nonet --novalid /somewhere.../manpages/docbook.xsl dia.dbk in w-dia-0.94/dia-0.94/doc/en (perhaps one could convince that configure script to find ../manpages/docbook.xsl by itself; xsltproc would be from the libxslt port/package). A workaround would be substituting a pre-made nroff dia.1 in the patch phase. I'll attach a dia.1 generated in the way mentioned above. Alternatively, instead of putting a file in there from .../files, one could just use the patches mechanism, which is my workaround. patch-doc_en_dia_1 attached, too. Kind regards, Hannah. .\"Generated by db2man.xsl. Don't modify this, modify the source. .de Sh \" Subsection .br .if t .Sp .ne 5 .PP \fB\\$1\fR .PP .. .de Sp \" Vertical space (when we can't use .PP) .if t .sp .5v .if n .sp .. .de Ip \" List item .br .ie \\n(.$>=3 .ne \\$3 .el .ne 3 .IP "\\$1" \\$2 .. .TH "DIA" 1 "1999-07-03" "" "" .SH NAME dia \- a diagram drawing program .SH "SYNOPSIS" .ad l .hy 0 .HP 4 \fBdia\fR [\fB\-c\fR] [\fB\-\-credits\fR] [\fB\-e\ \fIOUTPUT\fR\fR] [\fB\-\-export=\fIOUTPUT\fR\fR] [\fB\-h\fR] [\fB\-\-help\fR] [\fB\-n\fR] [\fB\-\-nosplash\fR] [\fB\-s\ \fIWxH\fR\fR] [\fB\-\-size=\fIWxH\fR\fR] [\fB\-t\ \fIFORMAT\fR\fR] [\fB\-\-export\-to\-format=\fIFORMAT\fR\fR] [\fB\-v\fR] [\fB\-\-version\fR] [file\ \&.\&.\&.] .ad .hy .SH "DESCRIPTION" .PP \fBDia\fR is used to create diagrams\&. Dia has a number of basic tools, like lines and boxes but can also dynamically load \fIsheets\fR\&. A sheet is a collection of tools that are used in a certain type of diagram\&. .PP Most diagram objects in \fBDia\fR has \fIhandles\fR\&. Lines can be connected to these handles and this way graph structures can be formed\&. When objects are moved or resized the connections will follow the objects\&. .PP Diagrams drawn in \fBDia\fR can be exported PostScript\&. .SH "OPTIONS" .PP \fBDia\fR accepts the following options: .TP \fB\-c\fR \fB\-\-credits\fR Display credits list and exit\&. .TP \fB\-e \fIOUTPUT\fR\fR \fB\-\-export=\fIOUTPUT\fR\fR Export loaded file to OUTPUT and exit\&. .TP \fB\-h\fR \fB\-\-help\fR Display a list of all commandline options\&. .TP \fB\-n\fR \fB\-\-nosplash\fR Do not show the splash screen\&. .TP \fB\-s \fIWxH\fR\fR \fB\-\-size=\fIWxH\fR\fR Export loaded file in decimal given width and/or height\&. It is allowed to only select width or height\&. E\&.g\&. \fB\-\-size=\fI520x\fR\fR exports an image that is 520 pixels wide, while \fB\-\-size=\fIx900\fR\fR exports an image of 900 pixels height\&. .RS .Sh "Note" This option is currently only implemented for the PNG export filter\&. .RE .TP \fB\-t \fIFORMAT\fR\fR \fB\-\-export\-to\-format=\fIFORMAT\fR\fR Export loaded file in FORMAT and exit\&. Format are described below\&. .TP \fB\-v\fR \fB\-\-version\fR Display \fBdia\fR version and exit\&. .SH "EXPORT FORMATS" .PP The following export formats are supported by \fBdia\fR\&. .TP 3 \(bu cgm (Computer Graphics Metafile, ISO 8632) .TP \(bu dia (Native dia diagram) .TP \(bu dxf (Drawing Interchange File) .TP \(bu eps or epsi oreps\-builtin or eps\-pango (Encapsulated PostScript) The format specifications eps,epsi, and eps\-pango all use the font renderer of the Pango library, whileeps\-builtin uses a dia specific font renderer\&. If you have problems with Pango rendering, e\&.g\&. Unicode, try eps\-builtin instead\&. .TP \(bu fig (XFig format) .TP \(bu mp (TeX MetaPost macros) .TP \(bu plt or hpgl (HP Graphics Language) .TP \(bu png (Portable Network Graphics) .TP \(bu shape (Dia shape file) .TP \(bu svg (Scalable Vector Graphics) .TP \(bu tex (TeX PSTricks macros) .TP \(bu wpg (WordPerfect Graphics) .TP \(bu wmf (Windows MetaFile) .LP .SH "FILES" .PP \fBdia\fR creates a directory \fI\&.dia\fR in the user's home, which contains different files to store user preferences\&. To reset \fBdia\fR to it's default behaviour, just remove the respective file: .TP 3 \(bu \fIdefaults\&.dia\fR: contains default values for elements (XML format)\&. .TP \(bu \fIdiarc\fR: keeps\fBdia\fR preferences (ASCII)\&. .TP \(bu \fIhistory\fR: keeps the list of last edited diagrams (ASCII)\&. .TP \(bu \fImenurc\fR: contains an automated accelerator map dump (Lisp)\&. .TP \(bu \fIpersistence\fR: contains GUI information, e\&.g\&. open windows (XML)\&. .TP \(bu \fIpluginrc\fR: the list of loaded plugins (XML)\&. .LP .SH "SEE ALSO" .PP Pango: \fIhttp://www.pango.org/\fR .PP X (1) .SH "COPYRIGHT" .PP Copyright 1999 Alexander Larsson\&. .PP Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentatio
Re: graphics/dia installs HTML as BASE/man/man1/dia.1!
Hello!
Cool that you've done (close to) the real thing.
Just testing...
On Wed, Jul 13, 2005 at 11:57:38AM +0200, Bernd Ahlers wrote:
>[...]
>I've attached a docbook-xsl port and a diff for dia. With this the dia
>manpage is installed in the correct format. Works for me, please test.
One little remark:
>[...]
>--- patches/patch-configure22 Dec 2004 06:01:23 - 1.8
>+++ patches/patch-configure13 Jul 2005 09:51:11 -
>@@ -1,6 +1,6 @@
> $OpenBSD: patch-configure,v 1.8 2004/12/22 06:01:23 marcm Exp $
> configure.origTue Nov 9 20:12:16 2004
>-+++ configure Tue Nov 9 20:12:46 2004
>+--- configure.origWed Aug 18 17:36:58 2004
> configure Wed Jul 13 00:02:04 2005
> @@ -7998,7 +7998,7 @@ nto-qnx*)
> openbsd*)
>version_type=sunos
>@@ -10,3 +10,11 @@
>library_names_spec='${libname}${release}${shared_ext}$versuffix
> ${libname}${shared_ext}$versuffix'
>finish_cmds='PATH="\$PATH:/sbin" ldconfig -m $libdir'
>shlibpath_var=LD_LIBRARY_PATH
>+@@ -25102,6 +25102,7 @@ fi
>+
>+ db2man_file=
>+ for file in \
>++ /usr/local/share/xsl/docbook/manpages/docbook.xsl \
>+ /usr/share/sgml/docbook/stylesheet/xsl/nwalsh/manpages/docbook.xsl \
>+ /usr/share/sgml/docbook/xsl-stylesheets-\*/manpages/docbook.xsl; do
>+ if test -f $file; then db2man_file=$file; break; fi
With this, you hardcode /usr/local/ as package installation base.
Perhaps one could pass LOCALBASE in the environment and use that
instead, i.e. ${LOCALBASE}/share/xsl/docbook/manpages/docbook.xsl
Besides that, the patch looks good and...
[a few minutes later]
... works for me, too.
Kind regards,
Hannah.
Java plugin doesn't work (current)
Hello! In current (updated on Monday), I installed jdk-1.4.2p2-with_ipv6 from ports, and after installation it suggests putting a link for a Mozilla/Firefox Java plugin to an appropriate place. Yet, it doesn't work (tried the interactive map stuff from www.map24.de, with mozilla-firefox-1.0.4). Nothing too important for me, just that the suggestion is worded as if it would work. Would I have better chances with the 1.5 JDK? Kind regards, Hannah.
Re: Java plugin doesn't work (current)
Hello!
On Wed, Jul 13, 2005 at 06:00:45PM +0200, Andreas Bartelt wrote:
>[...]
>this map applet works on my PC (OBSD current, firefox 1.0.4, jdk
>1.4.2-p7 without ipv6). Perhaps you should try 1.4.2-p7 instead of
>1.4.2-p2. I have no clue whether this could be related to ipv6.
Where do you get the -p7 from? The -current port still has
PKGNAME=jdk-${V}p2
In the end, it was the ipv6 issue mentioned in the other reply.
I was already aware of the memory hungriness of jdk, so I tried
raised limits before the original mail.
Still thanks for all replies!
>regards,
>Andreas
Kind regards,
Hannah.
Re: Java plugin doesn't work (current)
Hello! On Wed, Jul 13, 2005 at 12:38:24PM -0400, Kurt Miller wrote: >[... Java plugin vs. firefox ...] >>From DESR: > with_ipv6 > Build the jdk/jre with ipv6 support. When the jdk/jre is built > with this flavor, java will create only ipv6 sockets by default. > Since ipv4 to ipv6 address mapping is disabled on OpenBSD, > using ipv4 addresses will fail. Consequently, you may only > use ipv6 addresses or you can start java with > -Djava.net.preferIPv4Stack=true and can only use ipv4 > addresses. >Since you've compiled with ipv6, you can try adding >-Djava.net.preferIPv4Stack=true to >file:///usr/local/jdk-1.4.2/jre/ControlPanel.html -> Advanced Tab -> >Java Runtime Parameters That did it, thanks. I see that I could've used /usr/local/jdk-1.4.2/jre/bin/ControlPanel instead, too, for a standalone version thereof. >Also, I've had one person report that setting ulimits was not >enough, they had to change login.conf for their login class >instead (IIRC). Here it worked with ulimit -Sd 50 before starting firefox, using a little script like this: $ cat bin/ff #! /bin/sh ( /usr/local/bin/firefox /dev/null 2>&1 & ) Without redirecting stdin/stdout, mplayer hangs if you use it as helper for movie stuff. Without the ulimit (having an own default of 262144 via login.conf), it does not work, but yield no error message either. >-Kurt Thanks again. Kind regards, Hannah.
Re: end of life sysutils/zap
Hello! On Sun, Jul 24, 2005 at 10:10:35AM -0400, Ian Darwin wrote: >The sysutils/zap port which I nominally maintain has been obsoleted by >pkill which is in the base system. I therefore propose to remove this port. >Should I leave behind (for a while) a minimal Makefile with s/t like >BROKEN= "obsoleted by pkill(1), in base system" >Or is it better just to get rid of it altogether? I don't think pkill is really equivalent. Especially it lacks the interactive mode. Couldn't zap be left in? Isn't it really rather low maintenance? Kind regards, Hannah.
Re: end of life sysutils/zap
Hello! On Sun, Jul 24, 2005 at 08:21:29PM -0400, Ian Darwin wrote: >Hannah Schroeter and tedu both spoke up in favor of keeping it, >so I'll leave it be. Many thanks. >Ian Kind regards, Hannah.
Re: lang/clisp build fails on i386 -current
Hello! On Sat, Aug 13, 2005 at 08:25:36AM +0200, Andreas Vögele wrote: >>Known problem, everybody does. >Do you know if the OpenBSD kernel will be fixed before 3.8 is released? >Thierry Deval wrote on 4th May: >"While a proper solution has to be devised, you can use the following >diff that diminishes the impact of randomization on malloc... And makes >clisp work again. [...]" >I still use the patch that Thierry provided. I've received the suggestion to build clisp with these Makefile's CFLAGS: -DNO_SINGLEMAP -DNO_TRIVIALMAP -DNO_MULTIMAP_FILE -DNO_MULTIMAP_SHM However I don't know how to pass them in using the port, and I didn't have the time/energy to try it out. However I've been advised that that'll decrease the performance of clisp, among others it'll make the GC non-generational. Btw, doesn't that high degree of mmap randomization cause the virtual memory space, especially on 32-bit machines, to be quite fragmented, so big allocations might fail? And... While clisp seems to be the only port/package affected by all that randomization stuff, there *are* other things affected, such as cmucl/sbcl, just that they're not in ports anyway. But there were discussions on how to fix/workaround problems for similar randomization (in that case shared library load address randomization) on some "flavours" of Linux. Kind regards, Hannah.
Re: Opera 8.50
Hello! On Wed, Sep 21, 2005 at 02:13:49PM +0200, Xavier Dectot wrote: >Any chance to see a port to other platforms ? (sorry if this question has been >asked >befre). If you get Opera to release the source or to make binary bundles for other archs... Kind regards, Hannah.
Re: clamav package dependency missing
Hello! On Thu, Sep 22, 2005 at 12:57:11PM -0400, Michael Erdely wrote: >On 9/22/05, David Terrell <[EMAIL PROTECTED]> wrote: >> On Thu, Sep 22, 2005 at 10:19:48AM -0400, Matt Van Mater wrote: >> > >pkg_add will sooner or later try to find a ports tree and build missing >> > >packages. >I'd also like to suggest the opposite: >building a port tries to pkg_add any prerequisites before building them. Only if this can be disabled. There're still people wanting to do source only. Kind regards, Hannah.
Re: opera 8.50
Hello! On Wed, Sep 28, 2005 at 12:20:03PM +0200, steven mestdagh wrote: >On Wed, Sep 28, 2005 at 09:52:37AM +, Antoine Jacoutot wrote: >> Selon frantisek holop <[EMAIL PROTECTED]>: ^ Oh what kind of language is that? (Asks a hobby linguist) >[...] >I am seeing the same messages, and also this line upon loading >/usr/local/lib/opera/plugins/operamotifwrapper-1: error while loading >shared libraries: libXm.so.1: cannot open shared object file: No such >file or directory >but the plugin does work. even the sound works. You can muffle that warning by installing the package redhat_motif. (/usr/ports/emulators/redhat/motif) Kind regards, Hannah. -- Hannah SchröterEntwicklung [EMAIL PROTECTED] Bei Schlund + Partner AG Brauerstraße 48 D-76135 Karlsruhe This specification allows any of these approaches. Solving the Halting Problem is considered extra credit. (RFC 3028)
Re: Jaava/odbc support for erlang (was:Re: Erlang Port broken)
Hello! No reason to carry along individual addresses in addition to ports@, I think. On Wed, Oct 05, 2005 at 09:04:32AM -0700, Geoff White wrote: >All, >I'm upgrading my R10B-3 port to R10B-7 (the latest erlang out there), >three questions. >1) Can I get java support for OBSD (current) so that I can enable the >jinterface >2) what package should I select to give erlang odbc support. >3) should I make the functionality of these additions Flavors? I think it should definitely be a flavor, as it adds a dependency to non-free stuff (unless you find a really free Java implementation that's up to the task). Or a pseudo-flavor that creates an additional subpackage, keeping the main erlang package free and unchanged even then. >[...] Kind regards, Hannah.
Re: CVS: cvs.openbsd.org: ports
Hello! On Wed, Oct 12, 2005 at 10:32:41PM -0600, Bernd Ahlers wrote: >[...] >Log message: >If we start a second firefox, don't show the profile chooser but open a >new browser window instead. (The same for thunderbird and mozilla.) Does this also apply if the $DISPLAY setting for the second invocation is different from the $DISPLAY the other instance is already running on? Then I might be affected by this, usually running firefox on the normal X display :0, and sometimes wanting to run it on a secondary tightvnc display (:20). In fact, I'd like to access the same profile and have some locking/ communication between the instances done in that case, but I guess hell might freeze over before that happens... Kind regards, Hannah.
Re: Updating Ports
Hello! On Sun, Oct 16, 2005 at 08:35:33PM +0200, Marc Espie wrote: >[...] >or a branch. Package building has become more reliable, and all options are >now encoded as flavors and multi-packages. Not completely. See /usr/ports/print/psutils, where the papersize selection is a quite individual hack. >[...] >Things are going to get better, but new functionality isn't always documented >out front... Besides the little thing mentioned above, there're frequent moments of "oh, cool" when reading your occasional announcements or some commit messages. Kind regards, Hannah.
Re: Package post-install scripts ?
Hello! On Thu, Oct 27, 2005 at 07:11:49PM +0800, Uwe Dippel wrote: >Marc Espie wrote: >>You have an issue with the way you do stuff. If you install enough packages >>to have these scroll by and get lost, then use tools to store the output, >>like script and friends... >No fun on ports, I tell you. >I still think the 'hook' doing it for me is much easier. >> I'm at a loss, I *never* had to deal with this >>issue, I always have something like the scrollbar of my xterm to get back >>to the messages... >Everyone works differently. Quite frequently there is no xterm. On my >servers never. And then I sit in front of them ... Then, script (from base!) or screen (from ports) can help. For screen, be sure to increase the scrollback, something like defscrollback 500 in your .screenrc helps much. >>Well, tell you what, I'll get pkg_add and pkg_delete to print a summary >>of what changed (+pkg1 pkg2 -pkg1 pkg2). >Oh, that would be something ! And once you have it, why not add three >lines to *display* pkg_info -M /var/db/pkg/foo_s/+DISPLAY if these exist >? Then I can seat myself in front of an xterm (I usually don't) and do >what I actually proposed, at least conceptually. And with screen, you can even cut&paste with the keyboard only. Or use the cut&paste features of wsmoused. >[...] Kind regards, Hannah.
dxpc and other remote X solutions (was Re: Package post-install scripts ?)
Hello! On Fri, Oct 28, 2005 at 10:47:10AM +0200, Marc Espie wrote: >[...] >> We don't all install X on hosts that are simply intended to be servers. >> What's more I regularly have to do package installs to remote hosts >> accessed over a DSL line - and if you've never tried using X under such >> circumstances then my advice is _don't bother_ -- the performance sucks >> something rotten. >Oh, you should try dxpc then. It's *not* rotten. I've used X over a modem >in the past (yes, the 56K thingy), and it was *usable*. Interesting. As I'm sometimes using remote X over a slow line, I just tried dxpc out, too. Used lbxproxy and tightvnc before. xterm was a breeze, the window was there quite fast - with lbx it took much time until the window appeared, but afterwards it was usable (but then, the same was the case for X through ssh with Compression on). tightvnc is very usable for xterm, too. gaim crashes with some BadMatch error (works through plain X via ssh, lbx and tightvnc). Konqueror works but scrolling can be slow (I guess scrolling would be faster with tightvnc). Still an interesting thing. >[...] Kind regards, Hannah. PS: Did all via ssh (with compression), of course. dxpc using -L4000:localhost:4000, lbx using the normal forwarded display to proxy onto, vncviewer with the -via option. So no loss of security on the connection with dxpc or tightvnc.
Re: sidebar patch for mutt
Hello! On Wed, Nov 02, 2005 at 10:38:01PM -0600, Jolan Luff wrote: >[...] >they promised me beer if i included it so here's a diff to the port >which adds the sidebar patch as a FLAVOR. all the config stuff is >listed on the website for the patch, http://thomer.com/mutt/. the >website is referenced in the DESCR. >comments? oks? Can one disable/enable the sidebar in the sidebar FLAVOR by using a configuration option, or is this a compile-time only setting? I'd prefer the former. The sidebar might be very cool if one has a wide screen, but annoying on 80x(some number of lines). Some people might use both, from time to time. Kind regards, Hannah.
Re: removal of security/pgp (2.6.3) ?
Hello! On Fri, Dec 09, 2005 at 10:23:38PM +0100, steven mestdagh wrote: >hello, >aanriot@ and I were wondering if anyone is still using ancient pgp >2.6.3, and whether it could be removed from the tree? >It makes sense to us since this code is very old and unmaintained, and >we have newer alternatives, like gnupg and pgp5. >thoughts/comments ? Do those newer alternatives, especially gnupg, replace *all* the functionality of pgp 2.6.3? Especially decrypting documents encrypted with pgp 2.6.3? Verifying pgp 2.6.3 signatures? For example I haven't got pgpverify for Usenet control messages to run with gpg. Unless it's clear that I can do all this with gnupg (of course with the idea plugin/flavor if needed), I'd not be fond of pgp 2.6.3 being removed. Kind regards, Hannah.
Re: UPDATE: mail/exim
Hello!
On Sun, Dec 18, 2005 at 09:42:55AM +0300, Andrey N. Oktyabrski wrote:
>Andreas Vögele wrote:
I've attached a port of Exim 4.60, which includes the setting
>>>Please provide a unified diff against -current.
>>-FLAVORS=no_exiscan no_x11 mysql postgresql ldap iconv
>>+FLAVORS=no_exiscan no_x11 mysql postgresql sqlite3 ldap iconv sasl
>Have You any plans for spf flavor? I have the port for libspf2-1.0.4 and
>exim-4.50 port with this flavor.
>.if ${FLAVOR:L:Mspf}
>EXIM_MAKECAT+= "EXPERIMENTAL_SPF=yes\n"
>EXIM_EXTRA_LIBS+= -L${LOCALBASE}/lib -lspf2
>EXIM_LDFLAGS+= -L${LOCALBASE}/lib -lspf2
>EXIM_CFLAGS+= -DSPF -I${LOCALBASE}/include
>LIB_DEPENDS+= spf2.1:libspf2-*:mail/libspf2
>.endif
If you're doing libspf2, you could perhaps have use of this patch.
Fixed a crash with some SPF records for us.
Kind regards,
Hannah.
Index: src/libspf2/spf_compile.c
===
--- src/libspf2/spf_compile.c (revision 24561)
+++ src/libspf2/spf_compile.c (revision 24562)
@@ -736,7 +736,7 @@
* expand the buffer
*/
-len = sizeof( struct in_addr );
+len = sizeof( struct in6_addr );
if ( spfi->mech_buf_len - spfi->header.mech_len < len )
{
SPF_mech_t *new_first;
Re: KDE question
Hello! On Tue, Jan 10, 2006 at 08:09:01AM -0500, Dave Feustel wrote: >Running 3.8, I used cvs to load up the src and ports tree and then started >a build of kde with a make -k in /usr/ports/x11/kde. Then I went to bed. >This morning I saw that errors had occurred during the make, so I cd'd to >/usr/ports/x11/kde/base3 and started make again. Base3 stops immediately >because arts is not configured. What is the proper sequence of commands to >build kde in the ports tree? For me, it works to cd /usr/ports/x11/kde/base3 and make install. It should pull in the dependencies as needed. But of course, if you can't cope with ports, you can always use the packages (if you use current, use the snapshots). >Thanks, >Dave Feustel Kind regards, Hannah.
Re: SHARED_LIBS status
Hello! On Wed, Jan 11, 2006 at 12:02:36PM -0500, Josh Grosse wrote: >On Mon, Jan 09, 2006 at 12:04:27AM +0100, Marc Espie wrote: >> We're now almost done converting all ports to SHARED_LIBS, and a huge >> subset of them to USE_LIBTOOL instead of building their ports. >I've noticed that USE_LIBTOOL means that devel/libtool must be a dependency. >At least I discovered this when doing a -current rebuild of my relatively >small set of packages, and having gettext fail with an Error Code 127 because >libtool wasn't found in /usr/local/bin. :-) How do you manage to get an error? For me, building a port automatically builds and installs the ports it depends on for building. >[...] Kind regards, Hannah.
Re: any erlang ports? (otp r10bX)
Hello! On Sat, Feb 04, 2006 at 06:28:44PM -0500, Todd C. Miller wrote: >The following appears to work for me. I'm not really familiar >with erlang--I was just hoping to get ejabberd working... Huh. For me, the patch patch-erts_etc_common_Install doesn't apply, because there's no file named Install in the upstream source tree (which *did* match the distinfo check). After removing the offending patch (the other one applies cleanly), building works, but packaging fails: Error in package: symlink /usr/ports/local/erlang.todd_miller_20060204/w-erlang-R10B-9/fake-i386//usr/local/lib/erlang/bin/epmd refers to /usr/ports/local/erlang.todd_miller_20060204/w-erlang-R10B-9/fake-i386/usr/local/lib/erlang/erts-5.4.12/bin/epmd After re-adding something to fix this, things seem to work. > - todd Diff against the port you sent follows. And... Please commit something before the upcoming release. The erlang port that is in the tree just doesn't work *at all*, so anything is better than that. Kind regards, Hannah. diff -urN /tmp/foo./erlang/patches/patch-erts_etc_common_Install ./patches/patch-erts_etc_common_Install --- /tmp/foo./erlang/patches/patch-erts_etc_common_Install Mon Feb 6 16:39:33 2006 +++ ./patches/patch-erts_etc_common_Install Thu Jan 1 01:00:00 1970 @@ -1,139 +0,0 @@ -$OpenBSD$ erts/etc/common/Install.orig Sat Feb 4 15:44:27 2006 -+++ erts/etc/common/InstallSat Feb 4 17:53:07 2006 -@@ -13,7 +13,7 @@ while [ $# -ne 0 ]; do - shift - done - --if [ -z "$ERL_ROOT" -o ! -d "$ERL_ROOT" ] -+if [ -z "$ERL_ROOT" ] - then - echo "Install: need ERL_ROOT directory as argument" - exit 1 -@@ -25,24 +25,11 @@ then - exit 1 - fi - --if [ ! -d $ERL_ROOT/erts-5.4.12/bin ] -+if [ -d erts-5.4.12/obj ] - then -- echo "Install: The directory $ERL_ROOT/erts-5.4.12/bin does not exist" -- echo " Bad location or erts module not un-tared" -- exit 1 -+ ( cd erts-5.4.12/obj && sed -e "s;%FINAL_ROOTDIR%;$ERL_ROOT;" Makefile.src > Makefile ) - fi - --if [ -d $ERL_ROOT/erts-5.4.12/obj ] --then -- cd $ERL_ROOT/erts-5.4.12/obj -- sed -e "s;%FINAL_ROOTDIR%;$ERL_ROOT;" Makefile.src > Makefile --fi -- --if [ ! -d $ERL_ROOT/bin ] --then --mkdir $ERL_ROOT/bin --fi -- - # - # Fetch target system. - # -@@ -57,44 +44,42 @@ case $SYS:$REL in - TARGET="" ;; - esac - --cd $ERL_ROOT/erts-5.4.12/bin -+(cd erts-5.4.12/bin; -+ sed -e "s;%FINAL_ROOTDIR%;$ERL_ROOT;" erl.src > erl; -+ chmod 755 erl) - --sed -e "s;%FINAL_ROOTDIR%;$ERL_ROOT;" erl.src > erl --chmod 755 erl -- - # - # Create start file for embedded system use, - # --(cd $ERL_ROOT/erts-5.4.12/bin; -+(cd erts-5.4.12/bin; - sed -e "s;%FINAL_ROOTDIR%;$ERL_ROOT;" start.src > start; - chmod 755 start) - --cd $ERL_ROOT/bin -+mkdir -p bin -+cp -p erts-5.4.12/bin/erl bin -+cp -p erts-5.4.12/bin/erlc bin - --cp -p $ERL_ROOT/erts-5.4.12/bin/erl . --cp -p $ERL_ROOT/erts-5.4.12/bin/erlc . -- - # - # Set a soft link to epmd - # This should not be done for an embedded system! - # - - # Remove old links first. --if [ -h epmd ]; then -- /bin/rm -f epmd -+if [ -h bin/epmd ]; then -+ /bin/rm -f bin/epmd - fi - --ln -s $ERL_ROOT/erts-5.4.12/bin/epmd epmd -+ln -s erts-5.4.12/bin/epmd bin/epmd - --cp -p $ERL_ROOT/erts-5.4.12/bin/run_erl . --cp -p $ERL_ROOT/erts-5.4.12/bin/to_erl . --cp -p $ERL_ROOT/erts-5.4.12/bin/start . --sed -e "s;%EMU%;beam;" $ERL_ROOT/erts-5.4.12/bin/start_erl.src > start_erl --chmod 755 start_erl -+cp -p erts-5.4.12/bin/run_erl bin -+cp -p erts-5.4.12/bin/to_erl bin -+cp -p erts-5.4.12/bin/start bin -+sed -e "s;%EMU%;beam;" erts-5.4.12/bin/start_erl.src > bin/start_erl -+chmod 755 bin/start_erl - echo "" - --echo 5.4.12 R10B > $ERL_ROOT/releases/start_erl.data --sed -e "s;%ERL_ROOT%;$ERL_ROOT;" $ERL_ROOT/releases/RELEASES.src > $ERL_ROOT/releases/RELEASES -+echo 5.4.12 R10B > releases/start_erl.data -+sed -e "s;%ERL_ROOT%;$ERL_ROOT;" releases/RELEASES.src > releases/RELEASES - - if [ "$start_option" = "query" ] - then -@@ -118,17 +103,16 @@ case $start_option in - Name=start_sasl ;; - esac - --cp -p ../releases/R10B/start_*.boot . --cp -p $Name.boot start.boot --cp -p ../releases/R10B/$Name.script start.script -+cp -p releases/R10B/start_*.boot bin -+cp -p bin/$Name.boot bin/start.boot -+cp -p releases/R10B/$Name.script bin/start.script - - # - # We always run ranlib unless Solaris/SunOS 5 - # but ignore failures. - # --if [ "X$TARGET" != "Xsunos5" -a -d $ERL_ROOT/usr/lib ]; then --cd $ERL_ROOT/usr/lib --for library in lib*.a -+if [ "X$TARGET" != "Xsunos5" -a -d usr/lib ]; then -+for library in usr/lib/lib*.a - do - (ranlib $library) > /dev/null 2>&1 - done -@@ -139,10 +123,9 @@ fi - # Fixing the man pages - # - --if [ -d $ERL_ROOT/man ] --then --cd $ERL_ROOT --./misc/format_man_pages $ERL_ROOT --fi -+#if [ -d man ] -+#then -+#./misc/format_man_pages $ERL_ROOT -+#fi - - diff -urN /tmp/foo./e
Re: Don't submit new ports at this point in time!
Hi! On Tue, Feb 07, 2006 at 01:14:43PM +0100, Nikolay Sturm wrote: >just a reminder to all the busy people porting applications atm and >sending their work to [EMAIL PROTECTED] It's useless, it will be forgotten, >don't >do it. At this point in time we are only concerned with bugfixes and >cleanup of the ports tree, so that 3.9 will be shipped with the best >possible ports tree. I'd still hope for one of the newer erlang ports to go in, as anything is better than what's currently in tree. The in-tree port is just utterly broken, even though it's not explicitely marked that way. >[...] Kind regards, Hannah.
Re: any erlang ports? (otp r10bX)
Hello! On Wed, Feb 08, 2006 at 08:57:10PM +0100, Jon Olsson wrote: >On Wed, Feb 08, 2006 at 07:33:35PM +0100, Jon Olsson wrote: >[snip] >> Sorry for the late reply. Just want to chime in here and confirm that >> the erlang port millert posted + Hannahs patches works fine for me on OpenBSD >> 3.8-currentish/sparc64. Building it on 3.9-beta/i386 right now. >Bah, disregard my statement. Packaging is indeed broken, I noticed that after >a make clean. Even with my patches? Part of them was to fix packaging. Kind regards, Hannah.
Re: any erlang ports? (otp r10bX)
Hello! On Sat, Feb 11, 2006 at 02:22:36PM +0100, steven mestdagh wrote: >[...] >> And I agree with Hannah, please commit this port as is, since it's >> much better than the one currently in the ports tree, it's just broken >> and old. >I think now is not the right time to bring in more updates, as has been >asked by a few people already. We like to get a port right before >committing it. 'Anything is better than...' does not make sense to me. >I suggest you finetune the erlang port after tree lock and then it can >get the necessary testing. Frankly, I'm somewhat pissed off. I'm one of those quite a few people who prepared erlang port submissions over the last few years. Nothing ever got committed. Around the last release I expressed that sentiment a bit and got a kind of promise that the port would be taken up by one of the committers (I don't remember who it was, but I could look it up) after the 3.8 release. This didn't happen. And... I *do* think "anything is better" in this case. The in-tree erlang port just doesn't work *at all*, and is shipped, even without a BROKEN status. Any of the submissions of the last few years definitely work(ed) better than that. Much better indeed. I don't have too much time/energy to spare for non-paid computer work, and what happened around the erlang port was/is actually another negative incentive for me. >steven Kind regards, Hannah.
Re: i386 breakage
Hello! On Thu, Feb 16, 2006 at 11:50:41AM +0100, steven mestdagh wrote: >from a bulk build started Feb 13: >6 packages not building on i386: >clisp-2.33.2p0 Cannot map memory... Issues with randomized mmap/malloc, which clobbers all over the address space (instead of more limited randomization), disallowing clisp to map its memory image where it belongs, and the memory image isn't relocatable (and if it were, it would lose sharing between different clisp processes). There were different suggestions for workarounds, among them was the suggestion to use the (IIRC (s)brk based) gmalloc which is included in the clisp tree anyway. I'm not sure though whether I'll have the time to actually try this out and submit patches in time for the release. >gcc-3.3.6p1 No rule to make target `gnatlib_and_tools' >gmt-4.0 changed distfile >gprolog-1.2.16p0cannot open input file /tmp/... >maxima-5.9.0p1 clisp >qt4-4.1.0p0 tries to package nonexistent files Any dependents on qt4 in the ports tree? Kind regards, Hannah.
Re: update: erlang
Hello! On Sun, Mar 05, 2006 at 12:04:53PM +0100, Nikolay Sturm wrote: >a little too late for 3.9, but here is a seemingly working update of >erlang to otp_src_R10B-9, based on a submission to ports@ some time ago. >If anyone could test this to make sure it actually does something >useful, I'd appreciate it. Be sure to remove any object dir before >testing. Works for me. (i386). systrace outputs a few harmless things (bind a socket, connect to DNS), which doesn't break the build though. Tested a little (compiling and using a small erlang module, using the graphical debugger on it, playing with the Mandelbrot generator, etc.). Kind regards, Hannah.
Re: update vim 6.4.6 -> 6.4.8
Hi!
On Fri, Mar 10, 2006 at 11:26:07AM -0700, Chris Kuethe wrote:
> VERSION= 6.4.${REVISION}
>-PKGNAME= vim-${VERSION}p1
>+PKGNAME= vim-${VERSION}p0
I think p0 is unnecessary until the first change to the package based on
the same upstream version goes into the tree.
Kind regards,
Hannah.
Re: opinions about editors/openoffice-linux
Hello! On Mon, Mar 20, 2006 at 11:06:33PM +0100, Tobias Ulmer wrote: >Attached is a port that for the binary version of OpenOffice. I just >wanted to hear, if it's worth my time to continue and extend (other >languages as subpackages) this port or if I just produced crap that nobody >needs. >Currently there are no instructions in pkg/MESSAGE on how to create the >/proc filesystem, because i'm not sure if it's really needed... Haven't you just tried it out? I'd think a port like yours *is* definitely useful. Of course, it'd be the best thing to make a native port, but as far as I can understand, that's quite difficult due to not quite portable upstream code. And so a emulated Linux binary would be more than nothing. I haven't tested your port yet, but perhaps I can do so soon. >Tobias Kind regards, Hannah.
Re: opinions about editors/openoffice-linux
Hi! On Mon, Mar 20, 2006 at 11:06:33PM +0100, Tobias Ulmer wrote: >Attached is a port that for the binary version of OpenOffice. I just >wanted to hear, if it's worth my time to continue and extend (other >languages as subpackages) this port or if I just produced crap that nobody >needs. >Currently there are no instructions in pkg/MESSAGE on how to create the >/proc filesystem, because i'm not sure if it's really needed... Did a very small test and it worked so far. Kind regards, Hannah.
Re: CVS: cvs.openbsd.org: src
Hello! Could this (and the following commit) affect/fix the problem with erlang's configure stuff on amd64? Alas, I can't test that myself, because I don't have any amd64 box at my hands. Kind regards, Hannah. - Forwarded message from Otto Moerbeek <[EMAIL PROTECTED]> - From: Otto Moerbeek <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Date: Tue, 14 Mar 2006 12:27:57 -0700 (MST) Subject: CVS: cvs.openbsd.org: src CVSROOT:/cvs Module name:src Changes by: [EMAIL PROTECTED] 2006/03/14 12:27:57 Modified files: lib/libm : Makefile Removed files: lib/libm/arch/amd64: e_exp.S Log message: amd64 asm code is not correct for exp(+/-Inf), so until somebody comes up with a correct asm version, use the C version of exp(3). ok steven@ kettenis@ - End forwarded message -
Re: Erlang update to R10B-10 + added manpages and HTML docs
Hi! On Wed, Mar 22, 2006 at 08:07:19PM +0100, Nikolay Sturm wrote: >* Jon Olsson [2006-03-22]: >> ? patches/patch-erts_etc_common_Install >Is that a new patch file? >> -lib/erlang/lib/megaco-3.2.3/priv/lib/megaco_flex_scanner_drv.so >> +lib/erlang/lib/megaco-3.3/priv/lib/megaco_flex_scanner_drv.so >Any chance to get rid of all those version numbers in the directory >names? No, that's quite ingrained into erlang. >Nikolay Kind regards, Hannah.
Re: gstreamer plays too fast
Hi! On Mon, Apr 10, 2006 at 04:56:20PM +0800, Lars Hansson wrote: >I discovered something add today, it appears that gstreamer plays mp3's too >fast. I first noticed this when i switched between arts (with akode >installed) and gstreamer in Juk. Songs would appear to be playing with a >slightyl higher pitch with gstreamer than arts so i dug out my trusty >stopwatch and timed a few song. Well, it turns out that when gstreamer has >finished a 3.30 minutes song my stopwatch only shows 3:11. The same goes for >other songs. Gstreamer seems play a slight bit too fast. Looks like you have a sound card for which the chip and/or driver only supports a fixed sample rate. Probably that fixed sample rate is 48000 Hz and you want to play something with 44100 Hz. Look for this: 48000/44100 = 1.08843537414965986394 210/191 = 1.09947643979057591623 (210 is 3'30'' in seconds, 191 is 3'11'') Kind regards, Hannah. PS: Who has the same problem, alas. Damn super-cheap sound chips included on mainboards (auich in my case).
Re: gstreamer plays too fast
Hi! On Mon, Apr 10, 2006 at 06:00:08PM +0800, Lars Hansson wrote: >On Monday 10 April 2006 17:57, Hannah Schroeter wrote: >> Looks like you have a sound card for which the chip and/or driver only >> supports a fixed sample rate. Probably that fixed sample rate is 48000 >> Hz and you want to play something with 44100 Hz. Look for this: >But why would arts work work without any problem then? >Both are using the sun/oss device so wouldnt the problem manifest itself in >both? Perhaps arts resamples in userland. Kind regards, Hannah.
Re: Java Binaries
Hi! On Thu, Apr 20, 2006 at 09:32:52AM -0400, Kurt Miller wrote: >On Thursday 20 April 2006 8:12 am, Edd Barrett wrote: >> One of my friends recently pointed out that FreeBSD are distributing >> Java 5 binaries and actually are licensed to do so from Sun >> Microsystems! I'm not sure how long thats been happening, but has >> anyone made any effort to try to bag a similar agreement for OpenBSD? >> If not I am willing to give it a try (with the consent of the OBSD >> developers). I think have an email address of a Java Core developer I >> met at JavaUK06. >There are two primary reasons why we will not be able >to distribute java binaries: >1) Legal: The OpenBSD project is a collection of individuals. >There is no legal entity associated with the project like a >Foundation or non-profit org. That means there is no singal >point of contact for Sun to contract with and shield the >developers from liability. >2) Political: Even if #1 were solved, the binaries would >come with a binary only license that is incompatible with >the projects goals. IIRC the project goals mostly apply to base, while the "rules" for licencing in ports/packages are less strict. E.g. no new GPL stuff in base, but new GPL ports/packages are ok. Even more restrictive licences are accepted, e.g. in textproc/glimpse, where OpenBSD mirrors distfiles and distributes packages via ftp (but not on CDs because of the licence conditions). >On the other hand, I have applied as an individual to Sun's >scholarship program to get access to the test kit for 1.5 >(JCK). I was approved by the scholarship committee and now >waiting on Sun to get them. Do you know without having to check whether it'd be possible for an individual to obtain such a licence from Sun and distribute inofficial (wrt the OpenBSD project) Java packages then? Or would that bee too risky from a legal POV? >-Kurt Kind regards, Hannah.
Re: GNU netcat port
Hello! On Sun, Apr 30, 2006 at 04:41:36PM -0500, Travis H. wrote: >My first port, be gentle. >This is GNU netcat, which exists since the original nc is no longer >being maintained, I guess. >I sort of created this without realizing nc was already in /usr/bin. >Anyhow, it's GNU, but I have no idea how to set PERMIT_* --- the >porting checklist gives no guidance, and I'm certainly not a lawyer. >Perhaps some sort of advice would be useful here? Even if it's just >"GPL means PERMIT_DISTFILES_* are Yes, but PERMIT_PACKAGE_* are set to >GPL". PERMIT_* is Yes for GPL. >When I did a lib-depends-check, I got: >Missing system lib: c.38 (/usr/local/bin/netcat) Have you set WANTLIB= c (at least)? >Also, I think it may depend on libiconv, but I'm not sure. Check ldd /usr/local/bin/netcat. >In any >case, this worked for me, please let me know your results if you have >time to try it. Not tried yet. Kind regards, Hannah.
Re: Problems compiling openoffice
Hello! On Thu, Feb 01, 2007 at 12:36:47AM -0500, STeve Andre' wrote: >Trying to compile the openoffice monster gives me the error >listed below. I've tried this multiple times, this last time after >recreating my ports tree. This is on a -current system compiled >on 1/30. Given the complexities of both Java and Openoffice, >I'm rather puzzled. Have others built oo lately? This is the >first time in several weeks for me. >Thanks, STeve Andre' I tried, but got disk space problems. Even after using up about 10GB, it hasn't completed yet (command given was: FLAVOR=cleanobj make package, dependencies were already installed and cleaned). So even the cleanobj PSEUDO_FLAVOR didn't help. Kind regards, Hannah.
Re: pkg_add clamav: Is it something wrong with the output message?
Hi! On Mon, Nov 26, 2007 at 02:28:51AM +0800, Bibby wrote: >Hi, [EMAIL PROTECTED] >I use OpenBSD 4.2 -release, and installed clamav from package, while >finished, i got this message: >[...snip...] >installed /etc/clamd.conf from /usr/local/share/examples/clamav/clamd.conf4% >[...snip...] >Is it something wrong with the string '4%'? No, it's ok. It's a leftover from the progress bar. Kind regards, Hannah.
Re: kqemu cleaning
Hi! On Sun, Jan 20, 2008 at 02:43:59PM +0100, Tobias Ulmer wrote: >(i havn't really tested this, but can't we drop the standard qemu and >make qemu-kqemu the default? In my [admitedly short] testing, this works >fine and just prints a message that it can't load kqemu) Seems people reported problems with kqemu, so I'm not in favor of dropping the non-kqemu variant. Kind regards, Hannah.
Re: kqemu cleaning
Hi! On Mon, Jan 21, 2008 at 12:41:29PM +0100, Antoine Jacoutot wrote: >On Mon, 21 Jan 2008, Hannah Schroeter wrote: >>Seems people reported problems with kqemu, so I'm not in favor of >>dropping the non-kqemu variant. >The point is that qemu should work fine with or without kqemu with no >need of a FLAVOR. >Even if compiled with support for kqemu, qemu will proceed in software >mode is the kernel module is not loaded. >If this works fine like that, then the non-kqemu variant should be >dropped. Can one, then, also disable kqemu in the kqemu variant of qemu even when the kqemu kernel module is loaded, e.g. with a command line option? E.g. if I'm a non-root user on a box and I've noticed that there's subtle behavior difference that is bad for me? Kind regards, Hannah.
Re: kqemu cleaning
Hi! On Mon, Jan 21, 2008 at 02:40:20PM +0100, Stefan Sperling wrote: >[...] >> Can one, then, also disable kqemu in the kqemu variant of qemu even when >> the kqemu kernel module is loaded, e.g. with a command line option? >Yes. >Quoting http://fabrice.bellard.free.fr/qemu/kqemu-doc.html : >[...] Thanks. Kind regards, Hannah.
Re: Beep-media-player and esd
Hi! On Sat, Apr 19, 2008 at 01:19:50PM +0200, Nicolas Letellier wrote: >I upgraded to 4.3-current (from 4.3-stable) and I installed >audio/beep-media-player and I see it requires esound be launched. Why? >So, I must launch esd before (and esd play a sound at the beginning). I >don't remember I had to do this before... Beep-media-player worked >perfectly without I had to launch esound. >Is there a possibility to launch esound automatically (with Xfce for >example). Did you have a look at /etc/esd.conf? Mine looks like this: [esd] auto_spawn=1 #spawn_options=-terminate -nobeeps -as 2 #spawn_options=-terminate -nobeeps -as 2 -r 48000 #spawn_options=-nobeeps -as 2 -r 48000 spawn_options=-nobeeps -as 2 spawn_wait_ms=100 (used esd when I had sucky sound hardware which only could cope with 48000 samples per second) The auto_spawn line could be relevant to you. Kind regards, Hannah.
Re: opera 9.27 in 4.3
Hi! On Tue, May 20, 2008 at 03:10:03PM +0200, frantisek holop wrote: >i have a curious situtation here... it is unsupported, >but i am quite baffled, and thought about asking for help >to track this down. >i have installed 4.3, together with packages for 4.3 >then i have realized that i need a snapshot... >i want to stay at 4.3 for packages but move on >with the kernel/userland. i have done this in the >past, as long as the old libraries are there, >my experience is that it works. >i have also downloaded ports.tar.gz because i knew >some of the programs are not redistributable. >by mistake i have downloaded the ports.tar.gz >for the snapshot and not for 4.3 >now opera is linux emulation and furthermore static. >so it doesnt really matter that it's 9.26 or 9.27 >or does it? >after installation it worked ok, apart from some font >problems. but then it refuses to run >amaaq> opera >/usr/local/bin/opera[16]: /usr/local/libexec/opera: Operation not permitted >amaaq> /usr/local/libexec/opera >ksh: /usr/local/libexec/opera: Operation not permitted >i reinstall, it works again than stops again. >my disk is not mounted noexec >i have tried removing the .opera directory >does anyone have an idea? Have you merged /etc/sysctl.conf? Have you missed re-enabling linux emulation there, again? You need kern.emul.linux=1 there. Kind regards, Hannah.
Re: Annoying firefox messages
Hi! On Tue, Jun 17, 2008 at 10:54:27AM -0500, Marco Peereboom wrote: >Choose what? >There are no plugins for openbsd; it is worthless osx/windows poopoo. Huh? What about e.g. the java plugin installed with the jdk/jre packages/ports? >[...] Kind regards, Hannah.
Re: how to update to gnupg-1.4.9 ?
Hi! On Tue, Jun 17, 2008 at 10:06:15AM -0600, macintoshzoom wrote: >The problem is (from my newly gnupg.1.4.9 port dir): > make install ... >Can't install gnupg-1.4.9 because of conflicts (gnupg-1.4.8) >/usr/sbin/pkg_add: gnupg-1.4.9-ldap:Fatal error >*** Error code 1 >Stop in /usr/ports/1/gnupg-1.4.9 (line 1420 of >/usr/ports/infrastructure/mk/bsd.port.mk). ># >OKAY, this shows me at least that my new port is instalable after I remove >gnupg-1.4.8 How about pkg_add -riv /usr/ports/packages/all/gnupg-1.4.9.tgz (i.e. the package you just built from the port)? >[...] Kind regards, Hannah.
Re: Annoying firefox messages
Hi! On Tue, Jun 17, 2008 at 10:15:12AM -0500, Marco Peereboom wrote: >One of the worst annoyances after installing firefox are that it keeps >whining about not installed plugins. I don't recognize what you're talking about. >Unfortunately we can't disable >that message using the traditional methods so I'd like to propose that >we set plugin.default_plugin_disabled to false to our port. >I always have to consult the google for 5 minutes to find out what the >key is again. >Or is there anybody attached to that slow scrolling bar that was >designed to bring nothing but despair? What slow scrolling bar do you mean? Do you mean those slowly "appearing" alerts like "hey I blocked a pop up and must annoy you very slowly about it by slowly scrolling down the web page and inserting some stuff above the page"? I could care less if that were replaced by an alert appearing at once. Kind regards, Hannah.
Re: Annoying firefox messages
Hi! On Tue, Jun 17, 2008 at 11:40:05AM -0500, Marco Peereboom wrote: >You have to do it manually. There is no point whatsoever in having that >crap slow my machine down. And with todays internets just about every >site is excited about informing that I need to install flash. >I can't believe this is even being debated. Cookie for the person that >can find a plugin that will autoinstall on OpenBSD using the bar. Ah you mean *that* crap. I won't miss that, of course. No debate on my side. Somehow I seem to look at different sites. Or perhaps that's NoScript in action. *g* Kind regards, Hannah.
Re: Annoying firefox messages
Hi! On Tue, Jun 17, 2008 at 12:23:11PM -0700, Unix Fan wrote: >Gosh you people are stupid! >http://img166.imageshack.us/img166/4868/firefoxmissingpluginbk2.jpg Not stupid. Not used to that shit any more after months or even years of NoScript usage. >[...] Kind regards, Hannah.
Re: 'Nother broken package - git-1.5.4.2
Hello! [Mailing list changed to ports@, where this belongs.] On Wed, Jul 16, 2008 at 07:41:24PM -0500, L. V. Lammert wrote: >[...] >Yes, I DO get it, Not completely. >[...] >As the maintainer explained some time ago, there has been a no-X11 version >of GIT since April, so the question is, really, why that isn't the >package. Good suggestion, I think you would agree. The package has been *split*. There's, for example on my system, git-1.5.6.1, which does *NOT* require X at all, git-svn-1.5.6.1 (does *NOT* require X either), and git-x11-1.5.6.1 (which obviously *does* require X, but you can omit its installation, of course). It's no FLAVOR, so it's no question of default or not. Just choose to install the git packages except for git-x11. Splitting packages into subpackages is way preferred over flavors on OpenBSD, as far as I get it. >[...] Kind regards, Hannah.
Re: [NEW]: rbutil - Rockbox Utility *fixed*
Hi! On Fri, Sep 05, 2008 at 03:20:53PM +0200, Marc Espie wrote: >[...] >> > CHECK_LIB_DEPENDS = YES >> oh, I didn't know you could do that, well spotted :) it's not >> something that would be normally set in a port's own Makefile though, >> rather something you could set in mk.conf, or on the make command >> line. (probably more useful on bulk build machines to identify >> problems; while you're working on a port, it's quicker to "make >> port-lib-depends-check" now we have that option). >This is documented in bsd.port.mk as User settings, minus the typo. >*Anything* documented as user settings only belongs in mk.conf. >If there was a simple automated way to check it does come from a Makefile, >this would error out. GNU make has $(origin VARIABLE) to find that out. Perhaps one could introduce something like that into OpenBSD make? Kind regards, Hannah.
Re: firefox3 weird rendering
Hi! On Thu, Sep 04, 2008 at 12:17:13AM +, Christian Weisgerber wrote: >In short: >* If you use XAA acceleration, set Option "XAANoOffscreenPixmaps" > "true". This should be safe. >* Alternatively, switch from XAA to EXA, if the latter is supported > and proves to work for your graphics card. I have an "i810" "Intel Corporation" "82945G/GZ Integrated Graphics Controller". If I see things right, from reading the i810 man page, these workarounds, and those described in /usr/local/mozilla-firefox/README.OpenBSD, do not apply here. Does anyone know something that might help here? I didn't see anything in reference to the i810 driver in the freedesktop or mozilla/firefox bug reports referred to directly or indirectly from there, either. Kind regards, Hannah.
Re: firefox3 weird rendering
Hi! On Tue, Sep 09, 2008 at 06:36:40PM +0200, Michiel van Baak wrote: >On 16:26, Tue 09 Sep 08, Hannah Schroeter wrote: >> On Thu, Sep 04, 2008 at 12:17:13AM +, Christian Weisgerber wrote: >> >In short: >> >* If you use XAA acceleration, set Option "XAANoOffscreenPixmaps" >> > "true". This should be safe. >> >* Alternatively, switch from XAA to EXA, if the latter is supported >> > and proves to work for your graphics card. >> I have an "i810" "Intel Corporation" "82945G/GZ Integrated Graphics >> Controller". If I see things right, from reading the i810 man page, >> these workarounds, and those described in >> /usr/local/mozilla-firefox/README.OpenBSD, do not apply here. Does >> anyone know something that might help here? I didn't see anything in >> reference to the i810 driver in the freedesktop or mozilla/firefox bug >> reports referred to directly or indirectly from there, either. >I switched to EXA and all trouble went away. I see no such option documented in i810(4) or xorg.conf(5). So is that EXA thing applicable to i810, and where does that option belong then? Kind regards, Hannah.
Re: firefox3 weird rendering
Hi!
On Tue, Sep 09, 2008 at 07:39:33PM +0200, Landry Breuil wrote:
>On Tue, Sep 09, 2008 at 06:42:51PM +0200, Hannah Schroeter wrote:
>> On Tue, Sep 09, 2008 at 06:36:40PM +0200, Michiel van Baak wrote:
>> >On 16:26, Tue 09 Sep 08, Hannah Schroeter wrote:
>> >> On Thu, Sep 04, 2008 at 12:17:13AM +, Christian Weisgerber wrote:
>> >> >In short:
>> >> >* If you use XAA acceleration, set Option "XAANoOffscreenPixmaps"
>> >> > "true". This should be safe.
>> >> >* Alternatively, switch from XAA to EXA, if the latter is supported
>> >> > and proves to work for your graphics card.
>> >> I have an "i810" "Intel Corporation" "82945G/GZ Integrated Graphics
>> >> Controller". If I see things right, from reading the i810 man page,
>> >> these workarounds, and those described in
>> >> /usr/local/mozilla-firefox/README.OpenBSD, do not apply here. Does
>> >> anyone know something that might help here? I didn't see anything in
>> >> reference to the i810 driver in the freedesktop or mozilla/firefox bug
>> >> reports referred to directly or indirectly from there, either.
>> >I switched to EXA and all trouble went away.
>> I see no such option documented in i810(4) or xorg.conf(5). So is that
>> EXA thing applicable to i810, and where does that option belong then?
>Just drop i810 in favor of intel(4) in you xorg.conf. You'll be able to
>enjoy EXA and all those kind of whistles and bells like DRI and so on..
>Landry
Tried it, and using the options (XaaNoOffscreenPixmaps from
/usr/local/mozilla-firefox/README.OpenBSD)
Driver "intel"
Option "AccelMethod" "EXA"
Option "XaaNoOffscreenPixmaps"
the images in firefox3 are ok.
*However*, in contrast to i810, the driver can't be persuaded to use
1600x1200 by default, not even by using
Virtual 1600 1200
Modes "1600x1200" "1280x1024" "1024x768" "800x600" "640x480"
in each Display subsection in the Screen section (definitely including
the subsection for depth 24, which is my DefaultDepth and the depth
actually used, according to xdpyinfo).
Instead, 1280x1024 is used, even though xrandr *does* report 1600x1200
as available. It's not even 1600x1200 as *virtual* size, despite my
configuration ("Virtual 1600 1200").
Switching to 1600x1200 with xrandr *does* work, and that's my
workaround: doing that in my .xsession/.xinitrc early, followed by a
sleep 1. But it's not really nice. Why does 1600x1200 not work without
that workaround with intel(4), but with i810(4)?
(And why does X -configure select i810 over intel as driver, anyway, if
intel seems to be better?)
Kind regards,
Hannah.
Re: QEMU acceleration layer not activated
Hi! On Tue, Oct 28, 2008 at 02:08:28AM +, Mikolaj Kucharski wrote: >Anyone is using qemu with kqemu? I have installed: Not any more. I have experienced crashes of the host with kqemu (with the multiprocessor kernel), as well as strange behavior of the guest OS (for *some* guest OSes; Debian seems to run fine as guest, OpenBSD not [panic, init died, IIRC]). So I stopped using kqemu again (alas, because *as far as it worked*, it definitely got me a significant speed boost). >kqemu-1.3.0pre11p3 >qemu-0.9.1p4 >Loaded module on startup: ># modstat >Type Id Off Loadaddr Size Info Rev Module Name >DEV 0 29 dd047000 001b dd061360 2 kqemu ># ls -l /dev/kqemu >crw-rw 1 root _kqemu 29, 0 Oct 26 07:41 /dev/kqemu >When I start qemu I have following error message: >$ qemu ... >Could not open '/dev/kqemu' - QEMU acceleration layer not activated: Device >busy Strange. Worked for me (compiled the kqemu package myself on exactly the kernel/system I wanted to use, though, and added the appropriate lines to rc.securelevel and rebooted). >My user is member of _kqemu group. That should be fine then. >Running qemu as root user gives >the same error message and guest os (OpenBSD) is really slow no matter >which user executed qemu. Yes, of course qemu falls back to non-kqemu mode if it can't use the kqemu module. And *as far as it worked*, the acceleration was bigger when one uses -kernel-kqemu (KQEMU full virtualization instead of user mode only). Kind regards, Hannah.
Re: devel/boost update
Hi! On Tue, Oct 07, 2008 at 03:03:52PM +0200, Uwe Stuehler wrote: >I depend on the current release of boost, so attached is a diff to >update devel/boost to 1.36.0. It works for me, but I am not sure what >the implications of this update are for other ports. I would love to >help getting the port updated! I'd be interested in this upgrade too. I like that the diff now installs boost-build, too (though one could perhaps separate bjam and boost-build out into MULTI_PACKAGES). I also see that PFRAG.shared got lost (the .sos are in the main PLIST). That probably should be corrected, if this is not shared only. I can't judge the other changes in your patch, nor how well it works. Still waiting for the distfile and the build and then for some testing. >Cheers, >Uwe Kind regards, Hannah.
Re: devel/boost update
Hi! On Wed, Oct 29, 2008 at 04:11:03PM +0100, Hannah Schroeter wrote: ... Ok, first experience: With the system compiler, it just doesn't work much. For example: /usr/local/include/boost/exception/exception.hpp:108: warning: `mutable' is not at beginning of declaration Code: intrusive_ptr mutable data_; Seems the system compiler (3.3.5) needs mutable *before* the type. Kind regards, Hannah.
Re: devel/boost update
Hi! On Thu, Oct 30, 2008 at 03:24:06AM +0100, Uwe Stuehler wrote: >Hannah Schroeter wrote: >>I like that the diff now installs boost-build, too (though one could >>perhaps separate bjam and boost-build out into MULTI_PACKAGES). >Yes, that would be better. >>I also see that PFRAG.shared got lost (the .sos are in the main PLIST). >>That probably should be corrected, if this is not shared only. >It is not shared only, I have no clue why PFRAG.shared is not generated. >>I can't judge the other changes in your patch, nor how well it works. >>Still waiting for the distfile and the build and then for some testing. >Meanwhile, I had a need to use the Boost.Interprocess library and had to >make a number changes to let me use it. These are in the new patches >patch-boost_interprocess_* and patch-boost_intrusive_*. Cool. >I also disabled BOOST_TEST_USE_ALT_STACK to allow me to run >multi-threaded tests, although maybe a better fix exists. The test setup >failed, because of the way our sigaltstack() works. I don't think a better fix exists (until maybe OpenBSD's thread implementation switches to rthreads). Boost just should not assume sigaltstack works with multithreaded. The standards allow OpenBSD's behavior, see for example http://www.opengroup.org/onlinepubs/95399/functions/sigaltstack.html the last paragraph in DESCRIPTION. >Attached is a new diff against -current. Compiling (grind grind), still without trying a fix for the PFRAG.shared problem or multi-packaging bjam/boost.build. I've also recently experienced that this port doesn't compile when it (the new version) is already installed. However I can only look into it later if at all. >[...] Kind regards, Hannah.
Re: devel/boost update
Hi! On Thu, Oct 30, 2008 at 02:45:29PM +0100, Hannah Schroeter wrote: >On Thu, Oct 30, 2008 at 03:24:06AM +0100, Uwe Stuehler wrote: >[...] >>Attached is a new diff against -current. >Compiling (grind grind), still without trying a fix for the PFRAG.shared >problem or multi-packaging bjam/boost.build. Packaging *failed*: ===> Building package for boost-1.36.0 Create /usr/ports/packages/i386/all/boost-1.36.0.tgz Error in package: /usr/ports/devel/boost-1.36.0/w-boost-1.36.0/fake-i386//usr/local/lib/libboost_prg_exec_monitor-mt.a does not exist Error in package: /usr/ports/devel/boost-1.36.0/w-boost-1.36.0/fake-i386//usr/local/lib/libboost_prg_exec_monitor-mt.so.1.1 does not exist Error in package: /usr/ports/devel/boost-1.36.0/w-boost-1.36.0/fake-i386//usr/local/lib/libboost_prg_exec_monitor.a does not exist Error in package: /usr/ports/devel/boost-1.36.0/w-boost-1.36.0/fake-i386//usr/local/lib/libboost_prg_exec_monitor.so.1.1 does not exist Error in package: /usr/ports/devel/boost-1.36.0/w-boost-1.36.0/fake-i386//usr/local/lib/libboost_test_exec_monitor-mt.a does not exist Error in package: /usr/ports/devel/boost-1.36.0/w-boost-1.36.0/fake-i386//usr/local/lib/libboost_test_exec_monitor.a does not exist Error in package: /usr/ports/devel/boost-1.36.0/w-boost-1.36.0/fake-i386//usr/local/lib/libboost_unit_test_framework-mt.a does not exist Error in package: /usr/ports/devel/boost-1.36.0/w-boost-1.36.0/fake-i386//usr/local/lib/libboost_unit_test_framework-mt.so.1.1 does not exist Error in package: /usr/ports/devel/boost-1.36.0/w-boost-1.36.0/fake-i386//usr/local/lib/libboost_unit_test_framework.a does not exist Error in package: /usr/ports/devel/boost-1.36.0/w-boost-1.36.0/fake-i386//usr/local/lib/libboost_unit_test_framework.so.1.1 does not exist I'm just fixing this (it's a few additional changes to boost/test/impl/execution_monitor.ipp), as well as my other issues, and can then prepare patches based upon yours. >[...] Kind regards, Hannah.
Re: NEW: graphics/tkimg
Hi! On Fri, Nov 14, 2008 at 10:58:10PM +0300, Anton Yabchinskiy wrote: >Hi. Here is the port that I've made while working on net/tkabber. >Tclers, please test. >>From pkg/DESCR: >The IMG package provides the handling of several image formats >beyond the standard formats in Tk. The formats supported by Img's >are: BMP, GIF (with transparency, but without LZW, due to patent ^^ >restrictions), ico, JPEG, pcx, pixmap, PNG, ppm, postscript, sgi, >sun, tga, TIFF, window, XBM, XPM. The GIF-related patents are long dead. *rolls eyes* See for example http://www.kyzer.me.uk/essays/giflzw/ The last patent mentioned there expired in 2006. Kind regards, Hannah.
Re: ff3
Hi! On Sun, Dec 07, 2008 at 02:12:16PM -0600, Marco Peereboom wrote: >I did my customary pkg_add -ui and to my total shock firefox went from >2.x to 3.x. Not so shocking was that ff3 doesn't work after the update. Remove/backup and rename your old profile directory and make a new one (you can import your bookmarks later). Then it works (at least for me). >I want to make a plead to keep 2.x around. ff3 uses even more resources >than ff2 and it is impractical for my ultra-portable laptop (as an >example). For me it feels a little bit less slow and not more memory hungry than ff2 always was (ff2 was/is a beast and on my a bit slower home box I began moving over to konqueror again, which is fast even though I don't use kde otherwise - even faster than ff3 on my faster work box). >This change should be reverted. Here is the output on vanilla i386 >after the pkg_add -ui: >(firefox-bin:9897): Pango-WARNING **: File not found >(firefox-bin:9897): Pango-WARNING **: Failed to load Pango module >'/usr/local/lib/pango/1.5.0/modules/pango-basic-fc.so' for id >'BasicScriptEngineFc' Perhaps something else isn't completely clean after the upgrade? Perhaps rather related to pango than ff. >[...] Kind regards, Hannah.
Re: ff3
Hi! On Sun, Dec 07, 2008 at 02:12:16PM -0600, Marco Peereboom wrote: >[...] >This change should be reverted. Here is the output on vanilla i386 >after the pkg_add -ui: PS: Not so good an idea to keep ff2 when there'll be no fixes any more, not even security fixes, from upstream. Kind regards, Hannah.
Re: ff3
Hi! On Mon, Dec 08, 2008 at 01:57:23PM +, Christian Weisgerber wrote: >Hannah Schroeter <[EMAIL PROTECTED]> wrote: >> Remove/backup and rename your old profile directory and make a new one >> (you can import your bookmarks later). Then it works (at least for me). >Nice knee-jerk response, but I tested taking the existing configuration >from ff2 to ff3 (and in fact going back and forth between them) and >it worked just fine. Cool that it worked for you. For me it wasn't that smooth so I did what I described. Kind regards, Hannah.
Re: ff3
Hi! On Mon, Dec 08, 2008 at 09:18:41AM +0100, Marc Balmer wrote: >* Marco Peereboom wrote: >> But we are better than this. Since when is it ok that pkg_add -ui screws >> up? Are we turning into debian? >> I'll let it rest though since it seems that no one gives a shit; why >> should I care? >Just for the record: I built the package last night and used pkg_add -ui >to update. Not a single problem, not whil installing, not while using. >I'd even say that FF3 is a wee bit faster. That's my experience too. Sometimes still a little bit unstable, but then, ff2 wasn't rock stable either (and konqueror isn't completely stable either, though konqueror on a much slower box still feels faster than ff3 on a faster box; but I like some features of ff, like adblock plus, stylish for some pages with nearly unreadable styles, etc.). >[...] Kind regards, Hannah.
Re: mplayer audio and video stutters on CURRENT
Hi! On Wed, Dec 10, 2008 at 06:18:20PM +0100, Alexandre Ratchov wrote: >On Wed, Dec 10, 2008 at 05:53:42PM +0100, Andreas Bartelt wrote: >> Alexandre Ratchov wrote: >>> On Wed, Dec 10, 2008 at 07:55:59AM +0100, Andreas Bartelt wrote: I've updated my systems to CURRENT on Dec, 7th. Since then, I'm experiencing problems with mplayer audio and video playback on one of my boxes (audio and video stutters about every 5 seconds). Could this be caused by the libsndio related changes which have been committed to the mplayer port about one month ago? >>> does it happen both with and without "aucat -l" running? >> with "aucat -l" running, there are no problems with mplayer/libsndio. >> Perhaps I did miss something in the last weeks -- will there be an aucat >> daemon in the future which should run by default in order to handle >> audio? >yes i hope this will be possible. First we have to update all ports >to use libsndio, because while aucat is running, programs trying to >open directly /dev/audio will fail with "Device busy". Couldn't aucat free the sound device after some idle time (and re-open when needed), just like esd or arts do it? Then it could co-habitate a bit better with applications that do not use aucat. >[...] Kind regards, Hannah.
Re: sndio for xmms
Hi! On Sun, Dec 21, 2008 at 11:04:38PM +, Christian Weisgerber wrote: >Jacob Meuser wrote: >> > > here's a version to do that and add a device dialog. "AUDIODEVICE" >> > > means to use sndio default ... >> > I think it would be more intuitive to just use an empty string to >> > mean the sndio default. >> otoh, maybe people will think they have to type something in. the sun >> backend has something there by default ... >My thinking is that the sndio plugin should be the default. Probably difficult to model in a clean way. It *has* a sense that the plugins depend on xmms-main. But if that is so, making xmms-main depend on xmms-sndio would create circular dependencies. And OpenBSD doesn't have "Suggests" or "Recommends" as Debian has. One could, of course, instead rename xmms-main into xmms-core, make xmms-main a kind of meta-package, containing no files, but depending on xmms-main and xmms-sndio. >In >that case, people will probably have used it with success before >they get to the configuration panel, so they wouldn't feel any need >to put something in there. >"AUDIODEVICE" is a magic value and these are never good. I agree. Would be nothing bad in having the empty string use the sndio default and have a short explanatory text in the configuration dialogue of the plugin (like "empty = sndio default", or "empty = use $AUDIODEVICE, or default"). >What do other people think? Here my 0.02 of your favourite unit of currency. Kind regards, Hannah.
Issue with swig-1.3.24p4 and perl5 with C++
Hello!
I wrote this to Kevin Lo, the maintainer of the swig port. He wrote back
that I should mail this to [EMAIL PROTECTED]
So here I do it, even if a bit late.
Kind regards,
Hannah.
- Forwarded message from Hannah Schroeter <[EMAIL PROTECTED]> -
From: Hannah Schroeter <[EMAIL PROTECTED]>
To: Kevin Lo <[EMAIL PROTECTED]>
Date: Wed, 7 Mar 2007 19:33:21 +0100
Subject: Issue with swig-1.3.24p4 and perl5 with C++
Hello!
If I use swig with perl target with *C++* code, swig generates code that
produces compile errors.
This is caused by w-swig-1.3.24/SWIG-1.3.24/Lib/perl5/perlrun.swg,
line 377:
typedef XS(SwigPerlWrapper);
XS, in turn, is defined in XSUB.h (/usr/libdata/perl5/i386-openbsd/5.8.8/CORE),
around line 98. In C++, the above typedef expands to
typedef extern "C" void SwigPerlWrapper(pTHX_ CV* cv);
^^
(in plain C, the expansion doesn't have extern "C" and compilation will
succeed.)
I think, a *good* fix would be perl providing another #define usable for
typedef, like #define XSTYPEDEF(name) or something like that, and swig
using that.
Without changing perl, however, I did it by adding a small patch (see
below) and bumping the package name of swig.
Hope that's a usable report for you. If not, ask on.
Kind regards,
Hannah.
patches/patch-Lib_perl5_perlrun_swg
-
$OpenBSD$
``extern "C"'' comes in the way when wrapping C++ stuff
--- Lib/perl5/perlrun.swg.orig Wed Mar 7 19:00:49 2007
+++ Lib/perl5/perlrun.swg Wed Mar 7 19:00:21 2007
@@ -374,7 +374,11 @@ SWIG_Perl_SetErrorf(const char *fmt, ...
/* #define SWIG_croakf(x...) { SWIG_SetErrorf(x); goto fail; } */
+#ifdef __cplusplus
+typedef void SwigPerlWrapper(pTHX_ CV* cv);
+#else
typedef XS(SwigPerlWrapper);
+#endif
typedef SwigPerlWrapper *SwigPerlWrapperPtr;
/* Structure for command table */
---
- End forwarded message -
Re: Binary upgrade of mozilla-thunderbird fails on OpenBSD 4.1
Hello! Don't multipost. Stop posting HTML. On Wed, May 09, 2007 at 05:42:23AM -0700, jeraklo wrote: >Suspected line reads: >"Checking for collisions with >.libs-mozilla-thunderbird-1.5.0.10... some found" cleanup .libs-* before upgrading: pkg_delete /var/db/pkg/.libs* Kind regards, Hannah.
Re: can't update gettext
Hello! On Wed, May 09, 2007 at 06:42:47PM +0200, [EMAIL PROTECTED] wrote: >I'm wondering what am I doing wrong, that I can't update gettext. (i'm running >current port tree) >When I'm trying to upgrade I get this: >[EMAIL PROTECTED]:/usr/ports/devel/gettext# make update >===> Updating for gettext-0.14.6p0 >Upgrading from gettext-0.14.6 >Can't install /usr/ports/packages/i386/all/gettext-0.14.6p0.tgz: lib not found >expat.7.0 >Even by looking in the dependency tree: >libiconv-1.9.2p3 >*** Error code 1 Do you have current X (i.e. the one from xenocara) installed? Kind regards, Hannah.
Re: can't update gettext
Hello! On Wed, May 09, 2007 at 07:42:16PM +0200, [EMAIL PROTECTED] wrote: >> Do you have current X (i.e. the one from xenocara) installed? >I don't know, how can I check/install it? Do you really want to run -current if you don't know that? Kind regards, Hannah.
Re: glib2 compilation troubles
Hi! On Thu, May 10, 2007 at 10:36:58AM +0200, Marc Espie wrote: >On Thu, May 10, 2007 at 02:25:15AM -0500, Vijay Ramesh wrote: >> I haven't been able to compile glib-2.12.11. Did I miss a crucial >> announcement or is everyone having this problem? >In some cases, especially with gnu shit, you have to uninstall the previous >version before compiling the new one. >Since those nitwits who develop libtool do not really understand linking, >that's hardly surprising. Frankly, I encountered the same problem, then tried to uninstall the old stuff (not really, just moved it away, includes and libs), but still kept getting the same error message. *Uninstalling* doesn't work because of those many dependencies. (I wanted to "make update" in among others glib2, after glib2 was still out of date after upgrading using the latest snapshot packages.) Kind regards, Hannah. PS: I thought we have a tweaked libtool in our tree/ports?
Re: can't update gettext
Hi! On Wed, May 09, 2007 at 08:48:44PM +0200, [EMAIL PROTECTED] wrote: >> Do you really want to run -current if you don't know that? >Yes, I really want to run -current :) >So is there any thing about this in the faq, or would you be so kind to help >me? If you're not sure whether you have xenocara installed, just install it (again). As someone else said, you can just use the x*.tgz sets from the latest snapshot. Kind regards, Hannah.
Re: NEW: textproc/gsed
Hello! On Tue, May 15, 2007 at 08:12:21AM +0200, Paul de Weerd wrote: >On Mon, May 14, 2007 at 11:03:01PM -0300, Andr?s Delfino wrote: >| >And what/who needs this? >| Sorry, but, is that question relevant? I mean, shoudn't the ports tree >| have all the programs it can? :S >I don't think that's the goal of the OpenBSD portstree. The portstree >(or better, packaging system) should be an easy to use interface to >add functionality to OpenBSD that is missing from the base >installation. If GNU Sed doesn't add anything that the default sed(1) >is missing (I don't know, I think this is what Peter is asking), why >should it be added to the tree ? There are sed scripts out there that are GNU sed specific. Alas. But GNU sed has a few features that sed(1) doesn't have. Kind regards, Hannah.
Re: WIP: GNUstep
Hello! On Thu, May 31, 2007 at 03:49:48PM +0200, Antoine Jacoutot wrote: >On Thu, 31 May 2007, Giovanni Bechis wrote: >>On the committed version gnumake still "run_depends" on gtar, ^^^ >>is it needed ? > >Of course it is... gnustep-make actually installs a bunch of makefiles >which only work with gmake. But where's the relationship to *gtar*? Kind regards, Hannah.
Re: New: textproc/crm114
Hello! On Mon, Jun 11, 2007 at 05:26:35PM +0200, Matthias Kilian wrote: >Description: >[...] Works a bit. I'd install mailfilter.cf as example, too. You can get coredumps by doing things like echo asdlkj | crm /usr/local/share/examples/crm114/shuffle.crm Though I don't know whether that's due to an upstream bug or a port(ability) problem. arch is i386 here. Kind regards, Hannah.
Re: New: textproc/crm114
Hello! On Mon, Jun 11, 2007 at 09:01:44PM +0200, Matthias Kilian wrote: >On Mon, Jun 11, 2007 at 06:26:00PM +0200, Hannah Schroeter wrote: >> I'd install mailfilter.cf as example, too. >Sure. >> You can get coredumps by doing things like >> echo asdlkj | crm /usr/local/share/examples/crm114/shuffle.crm >> Though I don't know whether that's due to an upstream bug or a >> port(ability) problem. >It's a stupid sprintf(3) overflow. Thanks for reporting. >After having a look at the code, I slowly start to no longer believe >that the powerpc issue really is related to any gcc bug on powerpc. *nods* >In other words: I'll fix the crm bug (or rather: bugs, since there's >more stupid code in it) and then again look at the problems happening >on powerpc. But this may take a few days, since the crm code is >hard to read (very ugly, indeed). *nods* In fact, I've compiled crm114 myself on a Linux box (and I'd expect software written in the "all the world is Linux" style to work "better" there) and tried to get mail filtering work. Futile. Quite a few more segfaults, etc. So my temporary conclusion is: Nice ideas (e.g. the different text classifiers), but bad implementation. *sigh* I'll probably not have time/energy for further testing soon, anyway. >Ciao, > Kili Kind regards, Hannah.
Resend: Issue with swig-1.3.24p4 and perl5 with C++
Hello!
I sent this already.
Perhaps it could be considered now.
Kind regards,
Hannah.
- Forwarded message from Hannah Schroeter <[EMAIL PROTECTED]> -
From: Hannah Schroeter <[EMAIL PROTECTED]>
To: ports@openbsd.org
Date: Tue, 10 Apr 2007 16:55:12 +0200
Subject: Issue with swig-1.3.24p4 and perl5 with C++
Hello!
I wrote this to Kevin Lo, the maintainer of the swig port. He wrote back
that I should mail this to [EMAIL PROTECTED]
So here I do it, even if a bit late.
Please note that I'm present only up to Tuesday, then I'll be (mostly)
off the net for at least 6 weeks.
Kind regards,
Hannah.
- Forwarded message from Hannah Schroeter <[EMAIL PROTECTED]> -
From: Hannah Schroeter <[EMAIL PROTECTED]>
To: Kevin Lo <[EMAIL PROTECTED]>
Date: Wed, 7 Mar 2007 19:33:21 +0100
Subject: Issue with swig-1.3.24p4 and perl5 with C++
Hello!
If I use swig with perl target with *C++* code, swig generates code that
produces compile errors.
This is caused by w-swig-1.3.24/SWIG-1.3.24/Lib/perl5/perlrun.swg,
line 377:
typedef XS(SwigPerlWrapper);
XS, in turn, is defined in XSUB.h (/usr/libdata/perl5/i386-openbsd/5.8.8/CORE),
around line 98. In C++, the above typedef expands to
typedef extern "C" void SwigPerlWrapper(pTHX_ CV* cv);
^^
(in plain C, the expansion doesn't have extern "C" and compilation will
succeed.)
I think, a *good* fix would be perl providing another #define usable for
typedef, like #define XSTYPEDEF(name) or something like that, and swig
using that.
Without changing perl, however, I did it by adding a small patch (see
below) and bumping the package name of swig.
Hope that's a usable report for you. If not, ask on.
Kind regards,
Hannah.
patches/patch-Lib_perl5_perlrun_swg
-
$OpenBSD$
``extern "C"'' comes in the way when wrapping C++ stuff
--- Lib/perl5/perlrun.swg.orig Wed Mar 7 19:00:49 2007
+++ Lib/perl5/perlrun.swg Wed Mar 7 19:00:21 2007
@@ -374,7 +374,11 @@ SWIG_Perl_SetErrorf(const char *fmt, ...
/* #define SWIG_croakf(x...) { SWIG_SetErrorf(x); goto fail; } */
+#ifdef __cplusplus
+typedef void SwigPerlWrapper(pTHX_ CV* cv);
+#else
typedef XS(SwigPerlWrapper);
+#endif
typedef SwigPerlWrapper *SwigPerlWrapperPtr;
/* Structure for command table */
---
- End forwarded message -
- End forwarded message -
