Re: fvwm-devel (2.5.x)
On Mon, Mar 21, 2011 at 1:22 PM, Rafael Sadowski wrote: > On Fri Mar 18, 2011 at 09:17:23PM +0500, Alexandr Shadchin wrote: >> I prepared diff update x11/fvwm2 to 2.5.31 (on request and test mikeb@) >> >> current x11/fvwm2 - 2.4.20 (stable branch) >> last version fvwm2 - 2.5.31 (unstable branch) >> >> mikeb@ work with 2.5, no regression found. >> >> What should I do? Update current port, or separate port(fvwm2-devel)? >> > I don't think that any work with stable branch. In my opinion, separate > port like fvwm2-devel is the best choice but perhaps, a port like mutt > with subdirs stable and snapshot (for fvmw unsable) is also good. Previously it seemed silly to have 2 versions... what's the motivation not to stick with -stable? I'm really curious. I really don't see the point of two versions, but if there is such a demand, then stable/snapshot model makes sense.
Re: chromium port update
On Thu, Apr 1, 2010 at 10:42 AM, Auclair Vincent wrote: >>> Tested on an i386 eeepc. >>> Works fine, some quirks when moving a tab : a square that is not drawn >>> back until I drop the tab. (it follows the cursor) >> >> Hmm, actually tab dragging is totally busted with fvwm2, I just >> noticed - it always pops it out. So I imagine this is window manager >> specific, what are you using out of curiosity? > > I am using wmii. > There are also problems in the browser windows. (see the end of the mail) > If I drag a window out of the tab bar and drop it immediatly it spawns > a new window. > If I turn it arround an play with it enough it make the chrome crash > when I drop it. > >>> html 5 videos in youtube don't work. (probably expected, I just tested >>> for the fun) >> >> This should be doable though, if someone wanted to play with it/ > > I can definitly work on that, since I would like to have html5 videos. :) > >>> Options takes a heck of time to load, that nornal ? >> >> No.. it's instantaneous here > > Well it's instant on my desktop machine. > Will fidle with it a bit. > >>> Browser themes works. >>> Used gmail and reader. >>> >>> Thanks for the update :) > > So I was thinking on how to test the browser, I remembered > http://www.chromeexperiments.com/ > Some of them work, some don't. HTML5 videos obviously. > But there are some that use canvas that don't work either. > It may be a good place to stress test the browser. > > The `ping' test doesn't work long here, so window handling doesn't > work completly. > > The acid 3 test (acid3.acidtests.org/) says it get's 100% altough I do > get an error/warning. > > It also works on my desktop except for proxy. > Proxies seems to be broken. I set it in the environement and still > doesn't use it. > That normal ? I have only used --proxy-server=hostname:port to specify proxy. Sounds like a bug if it's not picking it up the other way.. I'll commit the port as it seems like it is definitely an improvement to what was there before. Again, the new distfile is 100% stock, and all the patches are in the port, so it's easy for people to help out and fix issues, add patches, etc. - just drop me an email. Help would be great.
Re: chromium port update
On Thu, Apr 1, 2010 at 8:47 AM, Auclair Vincent wrote: > On Thu, Apr 1, 2010 at 5:24 PM, Peter Valchev wrote: >> On Wed, Mar 31, 2010 at 11:50 PM, Antoine Jacoutot >> wrote: >>> On Wed, 31 Mar 2010, Peter Valchev wrote: >>> >>>> After a long battle with various issues that cropped up, and thanks to >>>> huge help from the guy working on the FreeBSD port (linked from my >>>> page), I have an update to chromium-5.0.539.0 >>>> >>>> 4.7ish packages for i386 & amd64 are available here: >>>> http://sightly.net/peter/openbsd/chromium/ >>>> >>>> As well as the port - if you want to build yourself. >>>> http://sightly.net/peter/openbsd/chromium/chromium.tar.gz >>>> >>>> I'd appreciate tests on amd64, especially, as I don't have one locally >>>> - I tested that it starts up and renders google.com, but anything more >>>> is too much of a pain over ssh X forwarding :-) I know the old port >>>> had V8 issues on amd64, so curious if this works better. >>> >>> Thanks Peter. >>> >>> Small thing I noticed is that the buttons and window flicker like hell >>> when clicking on "Clear browing data". >>> That is under current with cwm, not sure whether this is a local issue. >> >> buttons and windows flicker... that's probably just network churn >> while it's sending your browsing data to google (sorry, couldn't >> resist the joke) >> >> i can't reproduce on fvwm2 :) > > Tested on an i386 eeepc. > Works fine, some quirks when moving a tab : a square that is not drawn > back until I drop the tab. (it follows the cursor) Hmm, actually tab dragging is totally busted with fvwm2, I just noticed - it always pops it out. So I imagine this is window manager specific, what are you using out of curiosity? > html 5 videos in youtube don't work. (probably expected, I just tested > for the fun) This should be doable though, if someone wanted to play with it/ > Options takes a heck of time to load, that nornal ? No.. it's instantaneous here > Browser themes works. > Used gmail and reader. > > Thanks for the update :) Good to hear!
Re: chromium port update
On Wed, Mar 31, 2010 at 11:50 PM, Antoine Jacoutot wrote: > On Wed, 31 Mar 2010, Peter Valchev wrote: > >> After a long battle with various issues that cropped up, and thanks to >> huge help from the guy working on the FreeBSD port (linked from my >> page), I have an update to chromium-5.0.539.0 >> >> 4.7ish packages for i386 & amd64 are available here: >> http://sightly.net/peter/openbsd/chromium/ >> >> As well as the port - if you want to build yourself. >> http://sightly.net/peter/openbsd/chromium/chromium.tar.gz >> >> I'd appreciate tests on amd64, especially, as I don't have one locally >> - I tested that it starts up and renders google.com, but anything more >> is too much of a pain over ssh X forwarding :-) I know the old port >> had V8 issues on amd64, so curious if this works better. > > Thanks Peter. > > Small thing I noticed is that the buttons and window flicker like hell > when clicking on "Clear browing data". > That is under current with cwm, not sure whether this is a local issue. buttons and windows flicker... that's probably just network churn while it's sending your browsing data to google (sorry, couldn't resist the joke) i can't reproduce on fvwm2 :)
Re: chromium port update
On Wed, Mar 31, 2010 at 9:51 PM, Antti Harri wrote: > Great to have an updated build, but I guess this is still > true: > > "This package currently requires a CPU supporting SSE2. > You can check this with: dmesg | grep 'cpu.*SSE2'" Yeah. I'm sure it's possible to get it working on non-sse2, there are a few -msse2 flags in the *.gyp files and maybe a few more places that include *_sse2.c files etc., but it should be configurable. So with a few hours of work, it should be possible. Since the new distfile I published doesn't have any embedded patches in it (unlike the old one), you can easily add your own patches to the port (maybe we can do a non-sse2 flavor and selective include such a patch, in case there is an actual performance difference on other machines) > The i386 binary pkg installs and runs fine on my laptop. Cool!
Re: chromium port update
On Wed, Mar 31, 2010 at 9:16 PM, joshua stein wrote: >> I'd appreciate tests on amd64, especially, as I don't have one locally >> - I tested that it starts up and renders google.com, but anything more >> is too much of a pain over ssh X forwarding :-) I know the old port >> had V8 issues on amd64, so curious if this works better. > > binary package working ok so far on amd64. tested ssl, some heavy > javascript, canvas drawing, installing extensions, importing firefox > settings, and just general rendering. no full browser crashes, > although html 5 video pages seem to crash the current tab (e.g.: > http://jilion.com/sublime/video) Whoa, I wasn't brave enough to try html5 rendering yet :-) Nice to hear that's the only thing you found busted! > fonts render a bit differently than in firefox. overall they seem > to be of lighter weight and closer letter spacing, across many > different pages and fonts. Different, but not necessarily bad/worse? Thanks for the feedback!
chromium port update
After a long battle with various issues that cropped up, and thanks to huge help from the guy working on the FreeBSD port (linked from my page), I have an update to chromium-5.0.539.0 4.7ish packages for i386 & amd64 are available here: http://sightly.net/peter/openbsd/chromium/ As well as the port - if you want to build yourself. http://sightly.net/peter/openbsd/chromium/chromium.tar.gz I'd appreciate tests on amd64, especially, as I don't have one locally - I tested that it starts up and renders google.com, but anything more is too much of a pain over ssh X forwarding :-) I know the old port had V8 issues on amd64, so curious if this works better.
Re: NEW: geo/gdal
On Sat, Dec 6, 2008 at 2:36 AM, Matthias Kilian <[EMAIL PROTECTED]> wrote: > On Fri, Dec 05, 2008 at 08:20:09PM -0800, Peter Valchev wrote: >> A library necessary for QLandkarte GT which I'm in the process of >> porting - a newer version of geo/qlandkarte (www.qlandkarte.org) >> >> Would appreciate a cross-check and extra test :) > > There are some problems: > > - it should use MODULES = devel/gettext instead of LIB_DEPENDS = > intl::devel/gettext. done > - there seem to be some hidden dependencies, like xerces, postgresql, > jasper, geotiff. (Did I ever mention how much I hate this kind > of "pick it up if it's installed" automagic?) oh boy. i think i covered this, added explicit with/without lines for most things to avoid this ambiguity > - autoconf seems to pick up gsed and ggrep (if installed). This may be > harmless, but better find/xargs/grep for it in the fake dir. it seems harmless, and i don't understand your suggestion? > - if devel/geotiff is installed, the build fails. fixed i think. and sthen's error might be fixed too. updated tarball at: http://sightly.net/peter/openbsd/gdal.tar.gz
NEW: geo/gdal
A library necessary for QLandkarte GT which I'm in the process of porting - a newer version of geo/qlandkarte (www.qlandkarte.org) Would appreciate a cross-check and extra test :) Thanks, Peter gdal.tar.gz Description: application/tar-gz
Re: Update: xdelta
On Fri, Dec 5, 2008 at 8:02 AM, Jim Dew <[EMAIL PROTECTED]> wrote: > Theres no maintainer listed for xdelta, and I noticed there was an update > available when I was installing it earlier today. > > The changes in patches/patch-xd_edsio_c have been incorporated upstream, so > it needs to be removed. > > I was uncertain about the shared libs, so bumped them. thanks - submitted. bumped majors on libs as i didn't want to dig if APIs changed, etc and there aren't really any in-tree dependencies.
ports is now unlocked
Re: ports tree locked
On Thu, Aug 7, 2008 at 9:38 AM, Hugo Villeneuve <[EMAIL PROTECTED]> wrote: > On Tue, Aug 05, 2008 at 08:27:44PM -0700, Peter Valchev wrote: >> With the python fixes just making it in, the tree is now locked for >> the 4.4 release. Thanks to everyone who tested! > > > What's happening with m68k? No snapshot package update since 4.3. > > Are they halted until the linker/binutil issue is resolved? Is that > likely to be fixed in 4.4? (Is that issue just mac68k?) Probably going to miss 4.4.
ports tree locked
With the python fixes just making it in, the tree is now locked for the 4.4 release. Thanks to everyone who tested!
Re: Python, was: Re: only days left to ports lock (4.4 release)
On Mon, Aug 4, 2008 at 12:41 PM, Valery Masiutsin <[EMAIL PROTECTED]> wrote: >> On 2008/08/04 16:32, Valery Masiutsin wrote: >> > Hello. >> > >> > What about issues in #2588, #2599, #2620 ? >> >> Oh... Are python users supposed to tramp through the tickets just >> to identify the security problems? >> >> It would be nice if there was somewhere official to find these. >> Like http://www.python.org/news/security/, but actually maintained. >> >> > As far as i see from reading svn log of release25-maint, there are >> > also so called >> > "apple security fixes" and commit related to openbsd fcntl >> > handling. I've cherrypicked those patches, built python, it passes >> > make regress, and works fine for me, >> > is there any point to send the diff, at this point of time ? >> >> It might not go into the release, it's pretty late for that now, >> but you may as well send it along rather than just hold onto it. >> > Ok, here it is. I think it could suite as a starting point for > post-release activity. ... It appears that a lot of the work to pick the right patches has been done in this thread. Has someone familiar with python double checked Valery's work? Also extensive testing should be done by those that use it. It seems like enough people consider it important for the release, so let's get it done.
only days left to ports lock (4.4 release)
We are in release mode, with 4.4 just around the corner. This means that from now, no more commits to ports unless they are VERY urgent - such as fixing a broken dependency, high impact security issue, etc, and they must be explicitly approved. Every commit from now on must have an OK by pvalchev@, espie@ or naddy@ - email all 3 of us and describe why you think your patch must make it in the release. If you don't have a strong argument and are hesitant, please just wait until after the release. We really need the tree to stabilise and ask people to spend their energy on testing snapshots and finding real bugs at this point. I want to strongly emphasize that if you have any doubts about whether to suggest a patch for inclusion, then it can wait until after the release. In a few days, we'll actually lock the tree (zero commits) and final release builds will commence. Until then, we want to focus on showstoppers and not routine changes/additions.
Re: You gonna generate the 4.3_packages dir and upload it?
yes, doing it
Re: UPDATE: mcabber-0.9.7
updated, thanks!
On Fri, Apr 25, 2008 at 2:47 PM, Markus Hennecke
<[EMAIL PROTECTED]> wrote:
> This patch will bring the mcabber port to the version 0.9.7 released
> today. Included is the resize fix for OpenBSD.
>
> Tested by Simon Kuhnle and myself on amd64. Please test and commit.
>
> Kind regards,
> Markus
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/net/mcabber/Makefile,v
> retrieving revision 1.3
> diff -u -p -r1.3 Makefile
> --- Makefile6 Feb 2008 11:35:17 - 1.3
> +++ Makefile25 Apr 2008 15:23:24 -
> @@ -1,8 +1,7 @@
> # $OpenBSD: Makefile,v 1.3 2008/02/06 11:35:17 martynas Exp $
>
> COMMENT= console jabber client
> -DISTNAME= mcabber-0.9.6
> -PKGNAME= ${DISTNAME}p0
> +DISTNAME= mcabber-0.9.7
> CATEGORIES=net
>
> HOMEPAGE= http://www.lilotux.net/~mikael/mcabber/
> @@ -35,6 +34,7 @@ CONFIGURE_ARGS= --enable-gpgme \
> --disable-aspell \
> --enable-otr \
> --with-libotr-prefix=${LOCALBASE}/lib \
> + --enable-sigwinch \
> --with-libotr-inc-prefix=${LOCALBASE}/include
>
> pre-install:
> Index: distinfo
> ===
> RCS file: /cvs/ports/net/mcabber/distinfo,v
> retrieving revision 1.2
> diff -u -p -r1.2 distinfo
> --- distinfo17 Jan 2008 18:01:26 - 1.2
> +++ distinfo25 Apr 2008 15:23:24 -
> @@ -1,5 +1,5 @@
> -MD5 (mcabber-0.9.6.tar.bz2) = s9x9OPI1twGoKkkm6jyvkQ==
> -RMD160 (mcabber-0.9.6.tar.bz2) = rDSShtvCqRKeNgExZTLrerG6nns=
> -SHA1 (mcabber-0.9.6.tar.bz2) = eqh5Q8zj58LNQv50lgtToM0kAzE=
> -SHA256 (mcabber-0.9.6.tar.bz2) =
> NUVz11FhG3AMyWEmLfCZHTe1psigWNHNaRbSUxNlQ9M=
> -SIZE (mcabber-0.9.6.tar.bz2) = 480333
> +MD5 (mcabber-0.9.7.tar.bz2) = pvE2qg2r3X7P07+t7RgEBg==
> +RMD160 (mcabber-0.9.7.tar.bz2) = 4pn1EfQBL8hWi8rUooLQyRRnroo=
> +SHA1 (mcabber-0.9.7.tar.bz2) = CEh1S3oGhyZ8sLgkMxPncu8C4go=
> +SHA256 (mcabber-0.9.7.tar.bz2) =
> pHbMTxza4LrGZQ3aOzOrk/zDITBUpkf7dxRjqHgJjqk=
> +SIZE (mcabber-0.9.7.tar.bz2) = 489554
>
>
Re: DRM in xpdf
On Fri, Apr 25, 2008 at 8:22 AM, Deanna Phillips
<[EMAIL PROTECTED]> wrote:
> Floor Terra <[EMAIL PROTECTED]> writes:
>
> > There are similar checks to prevent printing for example. You
> > only need to put "return 1;" in OkToPrint()[1]. It's trivial
> > to change the source and recompile if you need to.
>
> That is much nicer. Here's a new diff from brad that uses your
> method.
>
> Works for me with xpdf, pdf2ps, pdftotext and pdfimages.
>
> anyone, ok?
Go for it.
> Index: Makefile
> ===
> RCS file: /cvs/ports/textproc/xpdf/Makefile,v
> retrieving revision 1.61
> diff -u -p -r1.61 Makefile
> --- Makefile19 Apr 2008 07:38:24 - 1.61
> +++ Makefile24 Apr 2008 23:06:43 -
> @@ -4,8 +4,8 @@ COMMENT-main= PDF viewer for X11
>
> COMMENT-utils= PDF conversion tools
>
> DISTNAME= xpdf-3.02
> -PKGNAME-main= xpdf-3.02pl2p3
> -PKGNAME-utils= xpdf-utils-3.02pl2p0
>
> +PKGNAME-main= xpdf-3.02pl2p4
> +PKGNAME-utils= xpdf-utils-3.02pl2p1
> CATEGORIES=textproc x11
>
> MASTER_SITES= ftp://ftp.foolabs.com/pub/xpdf/ \
>
> Index: patches/patch-xpdf_XPDFCore_cc
> ===
> RCS file: patches/patch-xpdf_XPDFCore_cc
> diff -N patches/patch-xpdf_XPDFCore_cc
>
> --- patches/patch-xpdf_XPDFCore_cc 30 Mar 2007 04:09:42 - 1.4
> +++ /dev/null 1 Jan 1970 00:00:00 -
> @@ -1,13 +0,0 @@
> -$OpenBSD: patch-xpdf_XPDFCore_cc,v 1.4 2007/03/30 04:09:42 ckuethe Exp $
>
> xpdf/XPDFCore.cc.orig Tue Feb 27 22:05:52 2007
> -+++ xpdf/XPDFCore.cc Fri Mar 30 00:31:19 2007
> -@@ -407,9 +407,6 @@ void XPDFCore::copySelection() {
> - int pg;
>
> - double ulx, uly, lrx, lry;
> -
> -- if (!doc->okToCopy()) {
> --return;
> -- }
> - if (getSelection(&pg, &ulx, &uly, &lrx, &lry)) {
> - //~ for multithreading: need a mutex here
> - if (currentSelection) {
> Index: patches/patch-xpdf_XPDFViewer_cc
> ===
> RCS file: patches/patch-xpdf_XPDFViewer_cc
> diff -N patches/patch-xpdf_XPDFViewer_cc
> --- patches/patch-xpdf_XPDFViewer_cc30 Mar 2007 04:09:42 - 1.4
> +++ /dev/null 1 Jan 1970 00:00:00 -
> @@ -1,15 +0,0 @@
> -$OpenBSD: patch-xpdf_XPDFViewer_cc,v 1.4 2007/03/30 04:09:42 ckuethe Exp $
> xpdf/XPDFViewer.cc.origTue Feb 27 22:05:52 2007
> -+++ xpdf/XPDFViewer.cc Fri Mar 30 00:31:19 2007
> -@@ -3406,11 +3406,6 @@ void XPDFViewer::printPrintCbk(Widget widget,
> XtPointe
> - PSOutputDev *psOut;
> -
> - doc = viewer->core->getDoc();
> -- if (!doc->okToPrint()) {
> --error(-1, "Printing this document is not allowed.");
> --return;
> -- }
> --
> - viewer->core->setBusyCursor(gTrue);
> -
> - XtVaGetValues(viewer->printWithCmdBtn, XmNset, &withCmd, NULL);
> Index: patches/patch-xpdf_XRef_cc
> ===
> RCS file: patches/patch-xpdf_XRef_cc
> diff -N patches/patch-xpdf_XRef_cc
>
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-xpdf_XRef_cc 24 Apr 2008 23:53:11 -
> @@ -0,0 +1,27 @@
> +$OpenBSD$
> +--- xpdf/XRef.cc.orig Thu Apr 24 19:13:00 2008
> xpdf/XRef.cc Thu Apr 24 19:50:06 2008
> +@@ -771,19 +771,19 @@ void XRef::setEncryption(int permFlagsA, GBool ownerPa
> + }
> +
> + GBool XRef::okToPrint(GBool ignoreOwnerPW) {
> +- return (!ignoreOwnerPW && ownerPasswordOk) || (permFlags & permPrint);
> ++ return (1);
> + }
> +
> + GBool XRef::okToChange(GBool ignoreOwnerPW) {
> +- return (!ignoreOwnerPW && ownerPasswordOk) || (permFlags & permChange);
> ++ return (1);
> + }
> +
> + GBool XRef::okToCopy(GBool ignoreOwnerPW) {
> +- return (!ignoreOwnerPW && ownerPasswordOk) || (permFlags & permCopy);
> ++ return (1);
> + }
> +
> + GBool XRef::okToAddNotes(GBool ignoreOwnerPW) {
> +- return (!ignoreOwnerPW && ownerPasswordOk) || (permFlags & permNotes);
> ++ return (1);
> + }
> +
> + Object *XRef::fetch(int num, int gen, Object *obj) {
> Index: patches/patch-xpdf_pdfimages_cc
> ===
> RCS file: patches/patch-xpdf_pdfimages_cc
> diff -N patches/patch-xpdf_pdfimages_cc
> --- patches/patch-xpdf_pdfimages_cc 24 Oct 2003 19:31:57 - 1.1
> +++ /dev/null 1 Jan 1970 00:00:00 -
> @@ -1,17 +0,0 @@
> -$OpenBSD: patch-xpdf_pdfimages_cc,v 1.1 2003/10/24 19:31:57 brad Exp $
> xpdf/pdfimages.cc.orig 2003-10-23 22:57:28.0 -0700
> -+++ xpdf/pdfimages.cc 2003-10-23 22:57:36.0 -0700
> -@@ -118,13 +118,6 @@ int main(int argc, char *argv[]) {
> - goto err1;
> - }
> -
> -- // check for copy permission
> -- if (!doc->okToCopy()) {
> --error(-1, "Copying of images from this document is not allowed.");
> --exitCode = 3;
> --goto err1;
> -- }
> --
> -
ports is unlocked
Re: PATCH: devel/sdl
On 1/25/08, Antoine Jacoutot <[EMAIL PROTECTED]> wrote: > On Fri, 25 Jan 2008, Antti Harri wrote: > >> If you don't specify a major.minor in the name passed dlopen() it will > >> select > >> the one with the highest major then highest minor after that. > > Anyone wanting to commit this has my OK; it really fixes things... Yep, sorry - I somehow missed this thread. It's in now.
update to sdl-1.2.13
Fixes a fullscreen crash with ffmpeg, etc. due to expecting memory to
be executable by default - use mprotect() - Reported by deanna@
Notes from the release:
Unix Notes
* Fixed crash in SDL_SoftStretch() on secure operating systems.
* Fixed undefined symbol on X11 implementations without UTF-8 support.
* Worked around BadAlloc error when using XVideo on the XFree86 Intel
* Integrated Graphics driver.
* Scan for all joysticks on Linux instead of stopping at one that was removed.
* Fixed use of sdl-config arguments in sdl.m4
Should be safe, but if you can test that something else didn't change,
please do.
? w-sdl-1.2.13
Index: Makefile
===
RCS file: /cvs/ports/devel/sdl/Makefile,v
retrieving revision 1.59
diff -u -p -r1.59 Makefile
--- Makefile9 Dec 2007 13:40:16 - 1.59
+++ Makefile3 Jan 2008 04:06:19 -
@@ -2,9 +2,9 @@
COMMENT= cross-platform multimedia library
-VERSION= 1.2.12
+VERSION= 1.2.13
DISTNAME= SDL-${VERSION}
-PKGNAME= ${DISTNAME:L}p2
+PKGNAME= ${DISTNAME:L}
CATEGORIES=devel
HOMEPAGE= http://www.libsdl.org/
Index: distinfo
===
RCS file: /cvs/ports/devel/sdl/distinfo,v
retrieving revision 1.16
diff -u -p -r1.16 distinfo
--- distinfo22 Sep 2007 01:12:38 - 1.16
+++ distinfo3 Jan 2008 04:06:19 -
@@ -1,10 +1,10 @@
-MD5 (SDL-1.2.12.tar.gz) = VEtFVJhuUe7W00Q1z5xfPw==
+MD5 (SDL-1.2.13.tar.gz) = xmYP7qKmg03hC8cbL45NiA==
MD5 (patch-libsd1.2.7-libcaca0.9.diff) = 3/bPX8l0lNvgWICGbhUWYA==
-RMD160 (SDL-1.2.12.tar.gz) = OHECPGPqBW66Q85PVe6NOnP/MCI=
+RMD160 (SDL-1.2.13.tar.gz) = 7Ygl/Jj0s3Wc+eXPg1fXHFDfmSU=
RMD160 (patch-libsd1.2.7-libcaca0.9.diff) = 50oezoZFd7b9r4UWqeS0AJWOV1s=
-SHA1 (SDL-1.2.12.tar.gz) = LDf/FoM2g2nA9VXUp0LwVEFTYQ0=
+SHA1 (SDL-1.2.13.tar.gz) = UfyqPh1cAf2BPqCGiHgPhrGc9Tk=
SHA1 (patch-libsd1.2.7-libcaca0.9.diff) = Tk0/XwKG5pYODlza0vkMVJl6bAQ=
-SHA256 (SDL-1.2.12.tar.gz) = 33friD79zGEiDq963jgyRinCc8J4zo1wClUwNp6bbfk=
+SHA256 (SDL-1.2.13.tar.gz) = lPmd8dYPKWtX9HQGUKcbZCXaZUBEyjD48M40k0Qp4TI=
SHA256 (patch-libsd1.2.7-libcaca0.9.diff) =
fnf1KYlqBfccSHTtjR9npVtt976i2zFrClxN/ejoAS8=
-SIZE (SDL-1.2.12.tar.gz) = 2829456
+SIZE (SDL-1.2.13.tar.gz) = 3373673
SIZE (patch-libsd1.2.7-libcaca0.9.diff) = 28259
Index: patches/patch-configure
===
RCS file: /cvs/ports/devel/sdl/patches/patch-configure,v
retrieving revision 1.15
diff -u -p -r1.15 patch-configure
--- patches/patch-configure 22 Sep 2007 01:12:38 - 1.15
+++ patches/patch-configure 3 Jan 2008 04:06:19 -
@@ -1,7 +1,7 @@
$OpenBSD: patch-configure,v 1.15 2007/09/22 01:12:38 pvalchev Exp $
configure.orig Sat Sep 8 22:38:20 2007
-+++ configure Sat Sep 8 22:39:50 2007
-@@ -25672,9 +25672,6 @@ echo "${ECHO_T}$CompileNASM_ret" >&6
+--- configure.orig Sun Dec 30 21:09:39 2007
configure Wed Jan 2 18:41:16 2008
+@@ -26333,9 +26333,6 @@ echo "${ECHO_T}$CompileNASM_ret" >&6; }
win32)
NASMFLAGS="-f win32"
;;
@@ -11,7 +11,7 @@ $OpenBSD: patch-configure,v 1.15 2007/09
macosx)
NASMFLAGS="-f macho"
;;
-@@ -33307,10 +33304,10 @@ _ACEOF
+@@ -33612,10 +33609,10 @@ _ACEOF
;;
netbsd|openbsd)
cat >>confdefs.h <<\_ACEOF
NEW: qlandkarte
Comments and tests appreciated. qlandkarte-20071222 Comment: garmin gps map management tool Description: QLandkarte is a Garmin GPS data visualization and managing tool. Maintainer: Peter Valchev <[EMAIL PROTECTED]> WWW: http://qlandkarte.sourceforge.net/ qlandkarte.tar.gz Description: GNU Zip compressed data
needs tests: sdl update
New SDL update from brad@ that needs a lot more testing. Antoine already verified that this fixes the powerpc bug that was a show-stopper for the previous updates (and caused a backout last year), so there are currently no known issues with this. Please report back sdl.diff Description: Binary data
ports unlock
ports is now unlocked, business can proceed as usual.
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.
ports soft lock
The ports tree is now soft locked. What this means is that we are in release mode, and new ports/updates will now stop except for very important cases. Everything has to be approved by me, naddy or espie. If you have something you deem will make 4.2 better, talk to us. This is what the next week or so will be about! Now is the time to start focusing on testing packages and trying to find subtle breakages. Please update your machines to -current and everyone can help out!
Re: drop maintainership of x11/wmii
Done. Anyone want to take it over?
Re: boehm-gc 6.8 working version
> > Here is an update to my first attempt to create a port for last > > boehm-gc. This one works well with inkscape and w3m on i386. > > boehm-gc is difficult, it needs someone with access to multiple > machine architectures and a fair understanding of OS internals to get > it configured properly. > > it should probably be ONLY_FOR_ARCHS which have been specifically > tested and known to work. I'm not sure the in-tree port works quite > right on many !i386 but it gets further than this update, which > fails to build on amd64: > > os_dep.c: In function `GC_get_stack_base': > os_dep.c:1095: error: `result' undeclared (first use in this function) > os_dep.c:1095: error: (Each undeclared identifier is reported only once > os_dep.c:1095: error: for each function it appears in.) > os_dep.c: In function `GC_register_data_segments': > os_dep.c:1483: error: `DATASTART' undeclared (first use in this function) > > (this update is also not made on -current, e.g. distinfo is still > old-style) - I didn't try any slow arch yet. A good way to start would be to look at every one of the patches in the existing boehm-gc port, and applying them to the new version by hand. The current port works on amd64, and you have broken that.. as well as many other things, I'm sure, so follow the old patches.
Re: NEW: textproc/gsed
> GNU sed is the Free Software Foundation's version of the sed(1) editor. > > GNU sed isn't really a true text editor or text processor. Instead, it > is used to filter text, i.e., it takes text input and performs some > operation (or set of operations) on it and outputs the modified text. > Sed is typically used for extracting part of a file using pattern > matching or substituting multiple occurrences of a string within a file. > > The sed binary is prefixed with the letter g to differentiate it from > the standard application with the same name. And what/who needs this?
Re: [strange work around] Re: snort alert timestamps are close to random
> > Ok, I think I've found the root cause of the problem, but it's strange. > > In ts_print() function in util.c (just for those interested in locating > > the line below in snort source code), there is a line like this: > > > > s = (tvp->tv_sec + localzone) % 86400; > > > > On amd64, this produces random output (not so random, but anyway), which > > is the value of s. To fix this problem, all I have to do is to expand > > that line as follows: > > > > temp = tvp->tv_sec + localzone; > > s = temp % 86400; > > > > Since I felt that this is a very dumb thing to do (and just a work > > around), I suspected the type of s. So I used different types for s, but > > nothing has changed. Also, since I tried -O0 compiler option, I don't > > think it's an optimization problem. > > > > Could somebody explain how this is possible? On amd64 what is it that's > > different from i386 and can cause a problem like this? And what is the > > correct way of fixing it? > > >From a quick look, it seems that it's a problem with struct timeval and > the type of tv_sec. The one in sys/time.h is long (64-bit in that case), > and the one from pcap is defined as a 32-bit int. Mixing the two makes > for strange things like you're seeing... Just to reiterate, snort/its plugins call ts_print() with an argument pcap_timeval, which has 32-bit tv_sec (uint32_t). ts_print however, works with sys/time.h timeval, which has 64-bit tv_sec (long). On i386 this is no problem of course. One has to carefully trace the actual problem (I have not done that yet) and make the usages consistent.
Re: [strange work around] Re: snort alert timestamps are close to random
> Ok, I think I've found the root cause of the problem, but it's strange. > In ts_print() function in util.c (just for those interested in locating > the line below in snort source code), there is a line like this: > > s = (tvp->tv_sec + localzone) % 86400; > > On amd64, this produces random output (not so random, but anyway), which > is the value of s. To fix this problem, all I have to do is to expand > that line as follows: > > temp = tvp->tv_sec + localzone; > s = temp % 86400; > > Since I felt that this is a very dumb thing to do (and just a work > around), I suspected the type of s. So I used different types for s, but > nothing has changed. Also, since I tried -O0 compiler option, I don't > think it's an optimization problem. > > Could somebody explain how this is possible? On amd64 what is it that's > different from i386 and can cause a problem like this? And what is the > correct way of fixing it? >From a quick look, it seems that it's a problem with struct timeval and the type of tv_sec. The one in sys/time.h is long (64-bit in that case), and the one from pcap is defined as a 32-bit int. Mixing the two makes for strange things like you're seeing...
amd64 pkg snapshot
A -current amd64 snapshot is making its way to the mirrors now, ready for testing. This is built with xenocara (after the lib fixes).
netbeans busted on amd64
Something broke it recently, java hangs on DDProvider.java [javac] /usr/obj/ports/netbeans-5.5p0/netbeans-src/websvc/websvcddapi/src/org/netbeans/modules/j2ee/dd/api/webservices/DDProvider.java:168: warning: [unchecked] unchecked call to put(K,V) as a member of the raw type java.util.Map And then the jave process just chews that forever.
Re: Build maxima and workman on amd64
> While trying to build the whole port tree on amd64, I found some ports
> which are not marked the same as their dependency as only buildable for
> some platform.
This is on purpose.
If someone fixes that particular dependency to allow it to work on
another architectures, everything else will just work, without the need
to hunt around for it. You're not solving a problem with your diff.
> For instance:
>
> workman depends on xview-config-3.2.1 which is not for alpha amd64 hppa64
> sparc64 mips64, but in workman Makefile port there is no:
> NOT_FOR_ARCHS= ${LP64_ARCHS}
>
> maxima depends on clisp, which is only for i386, not amd64, but in maxima
> Makefile port there is no:
> ONLY_FOR_ARCHS= i386
>
> Best regards,
>
> Charles Longeau
>
> Index: audio/workman/Makefile
> ===
> RCS file: /cvs/ports/audio/workman/Makefile,v
> retrieving revision 1.28
> diff -u -r1.28 Makefile
> --- audio/workman/Makefile13 Nov 2006 10:08:12 - 1.28
> +++ audio/workman/Makefile21 Mar 2007 21:22:12 -
> @@ -5,6 +5,8 @@
> PKGNAME= ${DISTNAME:L}p0
> CATEGORIES= audio
>
> +NOT_FOR_ARCHS= ${LP64_ARCHS}
> +
> MASTER_SITES=${MASTER_SITE_XCONTRIB:=applications/WorkMan/}
>
> PERMIT_PACKAGE_CDROM=Yes
> Index: math/maxima/Makefile
> ===
> RCS file: /cvs/ports/math/maxima/Makefile,v
> retrieving revision 1.5
> diff -u -r1.5 Makefile
> --- math/maxima/Makefile 25 Feb 2005 14:31:50 - 1.5
> +++ math/maxima/Makefile 22 Mar 2007 04:14:01 -
> @@ -1,5 +1,6 @@
> # $OpenBSD: Makefile,v 1.5 2005/02/25 14:31:50 alek Exp $
>
> +ONLY_FOR_ARCHS= i386
> COMMENT= "GPL computer algebra system based on DOE Macsyma"
>
> VERSION= 5.9.0
>
Re: UPDATE: hiawatha-5.7
> --- /usr/ports/www/hiawatha/pkg/PLIST Sun Dec 31 11:32:42 2006 > +++ hiawatha/pkg/PLISTSun Mar 4 13:02:22 2007 > @@ -1,14 +1,20 @@ > @comment $OpenBSD: PLIST,v 1.1.1.1 2006/12/31 10:32:42 ajacoutot Exp $ > @newgroup _hiawatha:579 > @newuser _hiawatha:579:579:daemon:Hiawatha HTTP > Server:/nonexistent:/sbin/nologin > [EMAIL PROTECTED] man/man1/cgi_wrapper.1 > [EMAIL PROTECTED] man/man1/cgi-wrapper.1 > @man man/man1/hiawatha.1 > -sbin/cgi_wrapper > [EMAIL PROTECTED] man/man1/php-fcgi.1 > [EMAIL PROTECTED] man/man1/wigwam.1 > [EMAIL PROTECTED] o+s > +sbin/cgi-wrapper > [EMAIL PROTECTED] why did that change to setuid?
Re: mirror, once more..
This is committed now. Since Bob is one of the biggest users of mirror here, it's been well tested :)
tree open
The ports tree is open for business again, so in case you submitted something in the past few weeks and it was ignored due to our release process, feel free to prod people and submit it again.
ports pre-lock
We are nearing release, so we need people to start focusing on testing packages and fixing bugs. At this point big updates (with long dependency chains) will be a no-no unless there is a very good reason, and new ports can wait until after release. Again, focus on finding problems. Trivial updates will still be OK. Everything needs to be approved now by either pvalchev, espie, naddy, bernd, sturm, or robert (ask more than one).
Re: UPDATE: nmap
> Nmap updated to 4.20 version, it seems to work even with OpenBSD's libpcap.
> Tested on i386.
Can you not GZIP the diffs that you send in the future please?
in your patch-tcpip.cc
--- tcpip.cc.orig Sun Feb 4 16:06:01 2007
+++ tcpip.ccSun Feb 4 16:08:26 2007
@@ -99,6 +99,8 @@
***/
/* $Id: tcpip.cc 4228 2006-12-08 03:01:08Z fyodor $ */
+#include
+
#ifdef WIN32
#include "nmap_winconfig.h"
#endif
@@ -1959,7 +1961,7 @@ if (timedout) {
// Returns whether the system supports pcap_get_selectable_fd() properly
bool pcap_selectable_fd_valid() {
-#if defined(WIN32) || defined(MACOSX)
+#if defined(WIN32) || defined(MACOSX) || (defined(BSD) && BSD >= 199306)
return false;
#endif
return true;
@@ -1972,7 +1974,7 @@ bool pcap_selectable_fd_valid() {
results. If you just want to test whether the function is supported,
use pcap_selectable_fd_valid() instead. */
int my_pcap_get_selectable_fd(pcap_t *p) {
-#if defined(WIN32) || defined(MACOSX)
+#if defined(WIN32) || defined(MACOSX) || (defined(BSD) && BSD >= 199306)
return -1;
#else
assert(pcap_selectable_fd_valid());
Why did you make these changes? pcap_get_selectable_fd() is in our
libpcap and removing that patch still seems to "work" in general though
I haven't looked to see what it affects... you patched it though,
so hence the question?
Re: UPDATE: scsh-0.6.7
> > Resubmitting the third time. > > > > http://www.altroot.org/scsh-0.6.7.patch > > > > The version we have is heavily outdated (last updated 4 years, 6 months > > ago), so it would be nice to have more recent and stable version in 4.1. > > > > MAINTAINER has not responded in 2 months, the email in the Makefile > > bounces; i found he is using another one ([EMAIL PROTECTED]), but he > > just ignores the patch. > > > > I also removed 108-lines-long patch-Makefile_in and did it in two lines in > > the post-install. > > > > Tested on i386. > > doesn't build on amd64, just like the in tree version. > trace and build log below. Since the in-tree version is also busted in the same way, this shouldn't be a show-stopper.
Re: print/acroread doesn't fetch
> With current up-to-date, print/acroread doesn't fetch: Well, it's binary only software that we're not even allowed to distribute the distfile of, so you should instead be more surprised at the times when it does fetch. There are alternatives...
New powerpc packages snapshot
Just copied a new powerpc snapshot, 3511 packages total. This was after a delay created by a bug in current and other issues, so it's been a while. Below is a list of the current breakage: 9libs-1.0p3 braindamaged gcc-4.2.20061024no powerpc config koffice-1.6.1 meinprog hung during "meinproc --check --cache index.cache.bz2 /usr/obj/ports/koffice-1.6.1/koffice-1.6.1/doc/kword/index.docbook" liboil-0.3.7i think fixed since nhc98-1.16 ? p5-Algorithm-Dependency-1.102 interactive (fixed since?) p5-Class-Std-0.0.8 can't find version.pm (!?) p5-Class-Std-Utils-0.0.2 ? as above p5-Smart-Comments-1.0.2 ? as above php5-pear-5.1.6p0 weird conflict in /var/www, may be local problem swi-prolog-5.6.18 macppc vs powerpc .. MACHINE vs MACHINE_ARCH somewhere transcode-1.0.2p2 asm: unrecognised 'vand' in cpu_accel.c xorp-1.3?
Re: gtk+2 patch for xenocara
> When building ports with X.Org 7.2RC2 (xenocara), the Gtk+2 configure > script picks up the new x11.pc pkg-config file but fails to use it > correctly (it ignores CFLAGS). > The attached patch fixes that, and doesn't change the behaviour with > X.Org 6.9.0 (XF4). > ok? Looks OK but bump PKGNAME of the package :) > Index: patches/patch-configure > === > RCS file: patches/patch-configure > diff -N patches/patch-configure > --- /dev/null 1 Jan 1970 00:00:00 - > +++ patches/patch-configure 30 Sep 2006 16:24:45 - > @@ -0,0 +1,10 @@ > +--- configure.orig Sun Jul 2 15:57:45 2006 > configureSat Sep 30 18:14:28 2006 > +@@ -26838,6 +26838,7 @@ > + have_base_x_pc=true > + X_PACKAGES="$X_PACKAGES x11 xext xrender" > + x_libs="`pkg-config --libs x11 xext xrender`" > ++X_CFLAGS="`pkg-config --cflags x11 xext xrender`" > + > + # Strip out any .la files that pkg-config might give us (this happens > + # with -uninstalled.pc files)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: [EMAIL PROTECTED] 2006/11/25 10:08:11 Modified files: . : INDEX Log message: sync, 3984 unzels
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: [EMAIL PROTECTED] 2006/11/24 22:40:31 Modified files: multimedia/xine-lib: Makefile multimedia/xine-lib/patches: patch-configure Log message: fix altivec test on powerpc, -force_cpusubtype_ALL appears to be a darwin-specific gcc4 option; from [EMAIL PROTECTED]
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: [EMAIL PROTECTED] 2006/11/24 22:33:28 Modified files: net/snort : Makefile Added files: net/snort/patches: patch-src_event_h patch-src_output-plugins_spo_unified_c patch-src_snort_packet_header_h Log message: Differentiate between struct timeval and bpf_timeval.. fixes logging/alerting on 64-bit platforms. >From [EMAIL PROTECTED]
Re: FIX: net/snort
> This diff fixes unified logging/alerting on 64-bit platforms.
>
> http://secure.lv/~nikns/stuff/ports/snort-2.6.0.2p1.diff
...
> +--- src/snort_packet_header.h.orig Thu Jan 19 19:09:12 2006
> src/snort_packet_header.hTue Nov 7 20:28:12 2006
> +@@ -16,12 +16,20 @@
> + #include
> +
> +
> ++/* we must use fixed size of 32 bits, because on-disk
> ++ * format of savefiles uses 32-bit tv_sec (and tv_usec)
> ++ */
> ++struct pcap_timeval {
> ++u_int32_t tv_sec; /* seconds */
> ++u_int32_t tv_usec; /* microseconds */
> ++};
> ++
Use bpf_timeval (see net/bpf.h) which is defined the same way,
don't define your own struct...
Re: libusb update
> >Please test with some of the software depending on this. Latest > >stable version, mostly bugfixes... > > Compiles and installs OK. Will test with my scanner later today, but > others have reported it works, so I'd say go for it. > > I actually need a later "devel" version of libusb (hile adding API, they > brilliantly changed the .h file from usb.h to libusb.h, and the program > I'm trying to port needs the new API). Should I make this as a separate > port with -devel in the name? It can't get committed over 1.0.12 because > it breaks compat with existing progs... It is dumb ot have stable/devel versions for everything, what software is that? If it's this one exception, maybe it'd be better to bundle in the libusb devel source and it build it statically just for that case? As ugly as it sounds, it may be preferred if it's just 1 exception. Since it only seems to be in CVS, who knows, they may keep changing the API, and different software may use different versions, so what are we going to do then, have 5 copies in the tree? Just a thought..
libusb update
Please test with some of the software depending on this. Latest
stable version, mostly bugfixes...
Index: Makefile
===
RCS file: /cvs/ports/devel/libusb/Makefile,v
retrieving revision 1.15
diff -u -p -r1.15 Makefile
--- Makefile1 Oct 2006 04:46:19 - 1.15
+++ Makefile15 Nov 2006 04:10:14 -
@@ -2,10 +2,9 @@
COMMENT= "USB access library"
-DISTNAME= libusb-0.1.10a
-PKGNAME= ${DISTNAME}p2
-SHARED_LIBS= usb 8.2 \
- usbpp 9.0
+DISTNAME= libusb-0.1.12
+SHARED_LIBS= usb 9.0 \
+ usbpp 10.0
MODGNU_SHARED_LIBS=usb '-export-dynamic' \
usbpp '-export-dynamic'
Index: distinfo
===
RCS file: /cvs/ports/devel/libusb/distinfo,v
retrieving revision 1.6
diff -u -p -r1.6 distinfo
--- distinfo21 May 2005 22:24:20 - 1.6
+++ distinfo15 Nov 2006 03:58:38 -
@@ -1,4 +1,4 @@
-MD5 (libusb-0.1.10a.tar.gz) = c6062b29acd2cef414bcc34e0decbdd1
-RMD160 (libusb-0.1.10a.tar.gz) = 18d50ac645440925bfa9f58d7a311d857e640882
-SHA1 (libusb-0.1.10a.tar.gz) = 7e03a71f2cec39d96f58e22ea9289088eee617ef
-SIZE (libusb-0.1.10a.tar.gz) = 375144
+MD5 (libusb-0.1.12.tar.gz) = caf182cbc7565dac0fd72155919672e6
+RMD160 (libusb-0.1.12.tar.gz) = 63848df717e00fff67ab30ba86a85466370d4e8e
+SHA1 (libusb-0.1.12.tar.gz) = 599a5168590f66bc6f1f9a299579fd8500614807
+SIZE (libusb-0.1.12.tar.gz) = 389343
Index: patches/patch-Makefile_in
===
RCS file: /cvs/ports/devel/libusb/patches/patch-Makefile_in,v
retrieving revision 1.5
diff -u -p -r1.5 patch-Makefile_in
--- patches/patch-Makefile_in 21 May 2005 22:24:20 - 1.5
+++ patches/patch-Makefile_in 15 Nov 2006 04:02:37 -
@@ -1,25 +1,26 @@
Makefile.in.orig Mon Feb 14 13:23:19 2005
-+++ Makefile.inFri May 20 22:44:55 2005
-@@ -250,7 +250,7 @@ target_alias = @target_alias@
+$OpenBSD$
+--- Makefile.in.orig Tue Nov 14 21:00:20 2006
Makefile.inTue Nov 14 21:00:52 2006
+@@ -256,7 +256,7 @@ target_alias = @target_alias@
# require automake 1.4
# gnu strictness chokes on README being autogenerated
AUTOMAKE_OPTIONS = 1.4 foreign
-SUBDIRS = . tests doc
+SUBDIRS = . doc
- AM_CFLAGS = $(CFLAGS_EXT)
+ AM_CFLAGS = -Werror $(AM_CFLAGS_EXT)
configincludedir = $(pkglibdir)/include
bin_SCRIPTS = libusb-config
-@@ -277,13 +277,11 @@ nodist_include_HEADERS = usb.h
+@@ -287,13 +287,11 @@ nodist_include_HEADERS = usb.h
include_HEADERS = usbpp.h
libusb_la_LDFLAGS = \
-version-info $(LT_CURRENT):$(LT_REVISION):$(LT_AGE) \
- -release $(LT_RELEASE) \
-export-dynamic \
- $(LDADDS)
+ $(LDADDS) $(PREBIND_FLAGS)
libusbpp_la_LDFLAGS = \
-version-info $(LT_CURRENT):$(LT_REVISION):$(LT_AGE) \
- -release $(LT_RELEASE) \
-export-dynamic \
- $(LDADDS) -lusb $(QT_LDFLAGS)
+ $(LDADDS) -lusb $(PREBIND_FLAGSPP)
Index: patches/patch-bsd_c
===
RCS file: /cvs/ports/devel/libusb/patches/patch-bsd_c,v
retrieving revision 1.6
diff -u -p -r1.6 patch-bsd_c
--- patches/patch-bsd_c 21 May 2005 22:24:20 - 1.6
+++ patches/patch-bsd_c 15 Nov 2006 04:02:37 -
@@ -1,6 +1,7 @@
bsd.c.orig Tue Feb 17 23:34:52 2004
-+++ bsd.c Fri May 20 22:35:57 2005
-@@ -357,7 +357,7 @@ int usb_bulk_read(usb_dev_handle *dev, i
+$OpenBSD$
+--- bsd.c.orig Fri Mar 3 19:52:46 2006
bsd.c Tue Nov 14 21:00:00 2006
+@@ -361,7 +361,7 @@ int usb_bulk_read(usb_dev_handle *dev, i
int usb_interrupt_write(usb_dev_handle *dev, int ep, char *bytes, int size,
int timeout)
{
@@ -9,7 +10,7 @@
/* Ensure the endpoint address is correct */
ep &= ~USB_ENDPOINT_IN;
-@@ -379,8 +379,7 @@ int usb_interrupt_write(usb_dev_handle *
+@@ -383,8 +383,7 @@ int usb_interrupt_write(usb_dev_handle *
USB_ERROR_STR(-errno, "error setting timeout: %s",
strerror(errno));
@@ -17,9 +18,9 @@
-ret = write(fd, bytes+sent, size-sent);
+ ret = write(fd, bytes, size);
if (ret < 0)
- #if __FreeBSD__
+ #ifdef __FreeBSD_kernel__
USB_ERROR_STR(-errno, "error writing to interrupt endpoint %s.%d: %s",
-@@ -390,16 +389,13 @@ int usb_interrupt_write(usb_dev_handle *
+@@ -394,16 +393,13 @@ int usb_interrupt_write(usb_dev_handle *
dev->device->filename, UE_GET_ADDR(ep), strerror(errno));
#endif
@@ -38,7 +39,7 @@
/* Ensure the endpoint address is correct */
ep |= USB_ENDPOINT_IN;
-@@ -424,8 +420,7 @@ int usb_interrupt_read(usb_dev_handle *d
+@@ -428,8 +424,7 @@ int usb_interrupt_read(usb_dev_handle *d
if (ret < 0)
USB_ERROR_STR(-errno, "error setting short xfer: %s", strerror(errno));
@@ -46,9 +47,9 @@
-ret = read(fd, b
Re: fvwm2 update to 2.5.x
Bernd said: > Antoine Jacoutot [Fri, Oct 27, 2006 at 02:37:29PM +0200] wrote: > >Selon Mike Belopuhov <[EMAIL PROTECTED]>: > >> Below comes update to fvwm2 port to bring it up to 2.5.18. > > > >I did not try the diff but at first glance: > >- there's no need for a png flavor, it should be included by default > >- why did you remove Peter Valchev from maintainer? Did you contact him? > > > >Anyway, since this is a devel version, I think it should not replace > >the in-tree fvwm2 port but rather be a new port like x11/fvwm2-devel. > > > How about creating stable and snapshot dirs inside the x11/fvwm2 > directory instead of add a fvwm2-devel port dir? > > Peter? This has been considered before and we came to the conclusion to simply stick to the -stable release. There is no reason to have every single development version of software inside the ports tree... unless there is a very good reason, but in the case of fvwm2, I don't really see it. A stable release will probably occur at some point soon, making these gymnastics useless.
Re: NEW: security/rainbowcrack
> >Here is a port to get rainbowcrack to natively compile on OpenBSD. > >Currently I do not allow source or binary distribution because of lack > >of license in the source file, however I am trying to contact the > >author to receive a friendly license. I know I would find this port > >very useful even considering lack of distribution, as it would let me > >do a lot of stuff at work on OpenBSD that I currently do on Linux. If > >you aren't familiar with rainbowcrack, the web site is here: > >http://www.antsight.com/zsl/rainbowcrack/ > > > > The author has stated to me it's provided as is and can be distributed > in source or binary form by anyone, so here's new port with that in > the PERMIT section Can you tell him to formulate an actual license, the above is not complete and would not hold in court. And to include the license in the next version...
Re: NEW: avidemux-2.1.2
> pkg/DESCR > Avidemux is a free video editor designed for simple cutting, filtering > and encoding tasks. It supports many file types, including AVI, DVD > compatible MPEG files, MP4 and ASF, using a variety of codecs. Tasks can > be automated using projects, job queue and powerful scripting > capabilities > > Allright, time to repost this port. > Tested under macppc (would appreciate feedbacks from other archs). > Basic editing, audio/video filtering and effects work well. > > Let me know... Looks good to me, I think you can commit it.
Re: UPDATE: www/tidy
this is a fixed patch
links binary against shared lib
fixes the way it's called (goes to fake location)
binary/libs installed to fake/ before headers now (since headers
are generated, other order breaks)
sets LD_LIBRARY_PATH
Index: Makefile
===
RCS file: /cvs/ports/www/tidy/Makefile,v
retrieving revision 1.19
diff -u -r1.19 Makefile
--- Makefile5 Oct 2005 09:39:20 - 1.19
+++ Makefile18 Oct 2006 17:23:53 -
@@ -2,9 +2,10 @@
COMMENT= "validate, correct, and pretty-print HTML files"
-TIDYDATE= 050921
+TIDYDATE= 051026
DISTNAME= tidy_src_${TIDYDATE}
PKGNAME= tidy-${TIDYDATE}
+SHARED_LIBS= tidy 1.0
CATEGORIES= www
@@ -23,8 +24,8 @@
MASTER_SITES1= ${HOMEPAGE}test/
EXTRACT_SUFX= .tgz
DISTFILES= ${DISTNAME}${EXTRACT_SUFX} \
- tidy_docs_050705${EXTRACT_SUFX}:0 \
- tidy_test_050919${EXTRACT_SUFX}:1
+ tidy_docs_051020${EXTRACT_SUFX}:0 \
+ tidy_test_051026${EXTRACT_SUFX}:1
USE_GMAKE= Yes
@@ -34,6 +35,9 @@
WRKBUILD= ${WRKDIST}/build/gmake
DOCDIR=${PREFIX}/share/doc/tidy
+
+MAKE_FLAGS=TIDY_MAJOR=${LIBtidy_VERSION:R} TIDY_MINOR=${LIBtidy_VERSION:E}
+FAKE_FLAGS=TIDY_MAJOR=${LIBtidy_VERSION:R} TIDY_MINOR=${LIBtidy_VERSION:E}
post-install:
${INSTALL_DATA_DIR} ${DOCDIR}
Index: distinfo
===
RCS file: /cvs/ports/www/tidy/distinfo,v
retrieving revision 1.7
diff -u -r1.7 distinfo
--- distinfo5 Oct 2005 09:39:20 - 1.7
+++ distinfo18 Oct 2006 17:23:53 -
@@ -1,12 +1,12 @@
-MD5 (tidy_docs_050705.tgz) = 2e6533fc48b077ff6243deaf21a781de
-MD5 (tidy_src_050921.tgz) = 82c76c061abfdf5f67d02951b4dd2a02
-MD5 (tidy_test_050919.tgz) = c9ca834e381537039e516da549662651
-RMD160 (tidy_docs_050705.tgz) = 49b8c2eaf87a0291b1bef6479cf1eeda6b720f52
-RMD160 (tidy_src_050921.tgz) = 958f532245412e3f8ac5bdd56edc5693cadf4b5b
-RMD160 (tidy_test_050919.tgz) = 337ca275ca6af513b1bf2a5bd4b10a2a244e90fe
-SHA1 (tidy_docs_050705.tgz) = b243d7910ce2fe57a8df27ff8f775e6d397c732d
-SHA1 (tidy_src_050921.tgz) = 4a53aa129e2575004dcbaf0cf4c5c3f1637723b0
-SHA1 (tidy_test_050919.tgz) = d214f85d581ceeeb4ec58d24d8d7494e10e62125
-SIZE (tidy_docs_050705.tgz) = 150359
-SIZE (tidy_src_050921.tgz) = 256079
-SIZE (tidy_test_050919.tgz) = 106674
+MD5 (tidy_docs_051020.tgz) = 86de2f198e57399c063d2567b2a25628
+MD5 (tidy_src_051026.tgz) = 1e39fafd6808978871346658c8da1454
+MD5 (tidy_test_051026.tgz) = 4b35b2e0495ad2fc1bc391f779c9541d
+RMD160 (tidy_docs_051020.tgz) = 63f033560af9a53393d9a3f656f26bb12bf505b6
+RMD160 (tidy_src_051026.tgz) = 0cae41f8c0cec51d4600d1bf2aac338cf60aa6b9
+RMD160 (tidy_test_051026.tgz) = 1caaf13ce9d484d8321b8b370782966066ea3a6f
+SHA1 (tidy_docs_051020.tgz) = 04988d51267566db6899e8061d9f2e5b58fbeec4
+SHA1 (tidy_src_051026.tgz) = 53be36945344af0c4080c34ebc95728bf8617f1c
+SHA1 (tidy_test_051026.tgz) = a790c98bdabffb8c181796e7ef4007cfbeb1f370
+SIZE (tidy_docs_051020.tgz) = 150402
+SIZE (tidy_src_051026.tgz) = 256131
+SIZE (tidy_test_051026.tgz) = 107014
Index: patches/patch-build_gmake_Makefile
===
RCS file: /cvs/ports/www/tidy/patches/patch-build_gmake_Makefile,v
retrieving revision 1.2
diff -u -r1.2 patch-build_gmake_Makefile
--- patches/patch-build_gmake_Makefile 19 Jul 2005 08:10:10 - 1.2
+++ patches/patch-build_gmake_Makefile 18 Oct 2006 17:34:25 -
@@ -1,6 +1,5 @@
-$OpenBSD: patch-build_gmake_Makefile,v 1.2 2005/07/19 08:10:10 aanriot Exp $
build/gmake/Makefile.orig Tue May 3 08:58:08 2005
-+++ build/gmake/Makefile Tue Jul 12 12:03:54 2005
+--- build/gmake/Makefile.orig Fri Jul 15 08:58:10 2005
build/gmake/Makefile Wed Oct 18 19:34:22 2006
@@ -58,8 +58,8 @@ SHELL=/bin/sh
PROJECT=tidy
@@ -19,7 +18,7 @@
-CC= gcc
-CFLAGS= -g -Wall -Wno-switch -Wno-parentheses -I $(INCDIR)
+#CC= gcc
-+CFLAGS+= -I $(INCDIR)
++CFLAGS+= -fPIC -I $(INCDIR)
# flags only supported with gcc 3.x
# CFLAGS += -Wunused-parameter
@@ -29,16 +28,28 @@
# OTHERCFLAGS+= -DSUPPORT_ACCESSIBILITY_CHECKS=1 -DSUPPORT_UTF16_ENCODINGS=1
-DSUPPORT_ASIAN_ENCODINGS=1
ifdef SUPPORT_UTF16_ENCODINGS
CFLAGS += -DSUPPORT_UTF16_ENCODINGS=$(SUPPORT_UTF16_ENCODINGS)
-@@ -115,7 +115,7 @@ LIBSUFFIX = .a
+@@ -112,10 +112,12 @@ TIDY_MINOR = 0
+ # This will come from autoconf again
+ LIBPREFIX = lib
+ LIBSUFFIX = .a
++SHAREDLIBSUFFIX = .so
OBJSUF = .o
LIBRARY = $(LIBDIR)/$(LIBPREFIX)$(PROJECT)$(LIBSUFFIX)
-AR=ar -r
++SHAREDLIBRARY =
$(LIBDIR)/$(LIBPREFIX)$(PROJECT)$(SHAREDLIBSUFFIX).$(TIDY_MAJOR).$(TIDY_MINOR)
+#AR=ar -r
XSLTPROC = xsltproc
-@@ -164,7 +164,7 @@ doc:$(DOCS)
+@@ -158,17 +160,21 @@ LIBHFILES= \
+ $(SRCDIR)/tidy-int.h
+
+
+-all:$(LIBRARY) $(EXES)
++all:$(LIBRARY) $(SHAREDLIBRARY) $(EXES)
+
+ doc:$(DOCS)
$(LI
Re: UPDATE: www/tidy
> > this is wrong, in OpenBSD, the libs are named libFOO.so.VERSION, > > not libFOO-version > > > > The below patch should correct that. Did you test it? It seems not: ../../bin/tidy -xml-help > ../../htmldoc/tidy-help.xml ../../bin/tidy: can't load library 'libtidy.so.1.0' gmake: *** [../../htmldoc/tidy-help.xml] Error 4 *** Error code 2 I was just looking at that, and the problem is that the tidy binary is linked w/ libtidy - before it was linking statically, when the shared lib has the proper name it links against it. During fake, the Makefile calls the binary from the wrong location (work area, not fake). The makefile needs to be fixed to work with fake which is a bit of a pain.
Re: UPDATE: www/tidy
> This diff updates www/tidy port + adds building of shared library
> which is usefull when, for example, compiling php with tidy support.
..
> Index: tidy/pkg/PFRAG.shared
> ===
> RCS file: tidy/pkg/PFRAG.shared
> diff -N tidy/pkg/PFRAG.shared
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ tidy/pkg/PFRAG.shared 28 Aug 2006 14:02:18 -
> @@ -0,0 +1,2 @@
> [EMAIL PROTECTED] $OpenBSD$
> [EMAIL PROTECTED] lib/libtidy-0.99.so.${LIBtidy-0.99_VERSION}
this is wrong, in OpenBSD, the libs are named libFOO.so.VERSION,
not libFOO-version
Re: databases/postgresql, changes to the -server subpackage
> I am changing slightly the way we install a PostgreSQL server. To
> recall, up to now installing the postgresql-server package created a
> default database for you. But this database was not secured.
>
> This has led to problems in some installations where the users were not
> aware of this.
Sounds good to me.
> So no database is created during package install, instead instructions
> are given on how to create a properly secured database.
>
> ok?
>
> Index: databases/postgresql/Makefile
> ===
> RCS file: /cvs/ports/databases/postgresql/Makefile,v
> retrieving revision 1.91
> diff -u -r1.91 Makefile
> --- databases/postgresql/Makefile 15 Oct 2006 16:00:11 - 1.91
> +++ databases/postgresql/Makefile 18 Oct 2006 11:12:19 -
> @@ -7,7 +7,7 @@
> VERSION= 8.1.5
> DISTNAME=postgresql-${VERSION}
> FULLPKGNAME= postgresql-client-${VERSION}
> -PKGNAME-server= postgresql-server-${VERSION}
> +PKGNAME-server= postgresql-server-${VERSION}p0
> PKGNAME-docs=postgresql-docs-${VERSION}
>
> CATEGORIES= databases
> Index: databases/postgresql/files/README.OpenBSD
> ===
> RCS file: /cvs/ports/databases/postgresql/files/README.OpenBSD,v
> retrieving revision 1.14
> diff -u -r1.14 README.OpenBSD
> --- databases/postgresql/files/README.OpenBSD 15 Oct 2006 16:00:11 -
> 1.14
> +++ databases/postgresql/files/README.OpenBSD 18 Oct 2006 11:12:19 -
> @@ -1,56 +1,40 @@
> -Requirements
> -
> -
> -Please note that the OpenBSD port of the PostgreSQL server requires a
> -kernel compiled with SYSVSEM and SYSVSHM options for proper operation.
> -The GENERIC kernel has these settings.
> -
> Using PostgreSQL in an OpenBSD environment
> ---
>
> -If you are installing PostgreSQL for the first time, a default database
> -will have been created for you. If this failed for any reason or if you
> -want to use non-default paramaters, you can do something similar to the
> -following steps manually:
> +If you are installing PostgreSQL for the first time, you have to create
> +a default database first. In the following example we install a database
> +in /var/postgresql/data with a dba account 'postgres' and md5 authentication.
> +We will be prompted for a password to protect the dba account:
>
> # su - _postgresql
> $ mkdir /var/postgresql/data
> - $ initdb -D /var/postgresql/data
> -
> -If you are upgrading PostgreSQL then you may have a `pgsql' or `postgresql'
> -user. It is suggested that you follow the steps in
> + $ initdb -D /var/postgresql/data -U postgres -A md5 -W
>
> - !!PREFIX!!/share/doc/postgresql/INSTALL
> -
> -for more information on how to upgrade your existing databases. See
> -also `Special notes for the OpenBSD port' below. Replace references to
> -the `postgresql' user below with `pgsql' or whatever other user you
> -have selected to be the database administration account.
> +Please consult the PostgreSQL website for more information, especially when
> +you are upgrading an existing database installation.
>
> Auto Start and Stop
>
>
> -If you wish to start PostgreSQL automatically during system startup,
> -add the following lines to /etc/rc.local:
> +To start PostgreSQL at boot and shut it down when the system shuts down,
> +add the following lines to /etc/rc.local and /etc/rc.shutdown, respectively:
> +
> +/etc/rc.local:
>
> if [ -x !!PREFIX!!/bin/pg_ctl ]; then
> su -l _postgresql -c "nohup !!PREFIX!!/bin/pg_ctl start \
> - -D /var/postgresql/data -l /var/postgresql/logfile \
> - -o '-D /var/postgresql/data'"
> + -D /var/postgresql/data -l /var/postgresql/logfile \
> + -o '-D /var/postgresql/data'"
> echo -n ' postgresql'
> fi
>
> -To automatically shutdown the database as part of the system shutdown,
> -add the following lines to /etc/rc.shutdown:
> +/etc/rc.shutdown:
>
> if [ -f /var/postgresql/data/postmaster.pid ]; then
> su -l _postgresql -c "!!PREFIX!!/bin/pg_ctl stop -m fast \
> - -D /var/postgresql/data"
> + -D /var/postgresql/data"
> rm -f /var/postgresql/data/postmaster.pid
> fi
>
> Network Connections and Tuning
> ---
>
> To allow connections over TCP (and other options) edit the file:
>
> Index: databases/postgresql/pkg/MESSAGE-server
> ===
> RCS file: /cvs/ports/databases/postgresql/pkg/MESSAGE-server,v
> retrieving revision 1.3
> diff -u -r1.3 MESSAGE-server
> --- databases/postgresql/pkg/MESSAGE-server 5 Feb 2006 09:23:22 -
> 1.3
> +++ databases/postgresql/pkg/MESSAGE-server 18 Oct 2006 11:12:19 -
> @@ -1,2 +1,7 @@
> -For more information on using PostgreSQL in an OpenBSD environment,
> -
update to sdl-1.2.11
Here is an SDL update various people have asked for.
I have only lightly tested it on amd64 so far, and would
love to get more comments.
Index: Makefile
===
RCS file: /cvs/ports/devel/sdl/Makefile,v
retrieving revision 1.45
diff -u -p -r1.45 Makefile
--- Makefile1 Aug 2006 23:39:08 - 1.45
+++ Makefile8 Oct 2006 06:05:15 -
@@ -3,9 +3,9 @@
COMMENT= "cross-platform multimedia library"
-VERSION= 1.2.9
+VERSION= 1.2.11
DISTNAME= SDL-${VERSION}
-PKGNAME= ${DISTNAME:L}p1
+PKGNAME= ${DISTNAME:L}
CATEGORIES=devel
HOMEPAGE= http://www.libsdl.org/
@@ -29,12 +29,10 @@ FLAVOR?=sun
USE_LIBTOOL= Yes
-AUTOCONF_VERSION= 2.59
-AUTOMAKE_VERSION= 1.9
SEPARATE_BUILD=concurrent
-CONFIGURE_STYLE= autoconf
+CONFIGURE_STYLE= gnu
MODGNU_CONFIG_GUESS_DIRS= ${WRKSRC} ${WRKSRC}/test
-SHARED_LIBS= SDL 6.0
+SHARED_LIBS= SDL 7.0
CONFIGURE_ENV+=X11BASE="${X11BASE}" \
CFLAGS="${CFLAGS} -I${LOCALBASE}/include" \
LDFLAGS="${LDFLAGS} -L${LOCALBASE}/lib"
@@ -100,7 +98,7 @@ CONFIGURE_ARGS+= --without-x \
--disable-video-x11
.else
USE_X11= Yes
-WANTLIB+= X11 Xext
+WANTLIB+= X11 Xext Xrandr Xrender
.endif
NO_REGRESS=Yes
Index: distinfo
===
RCS file: /cvs/ports/devel/sdl/distinfo,v
retrieving revision 1.11
diff -u -p -r1.11 distinfo
--- distinfo17 Sep 2005 00:38:15 - 1.11
+++ distinfo8 Oct 2006 04:27:25 -
@@ -1,8 +1,8 @@
-MD5 (SDL-1.2.9.tar.gz) = 80919ef556425ff82a8555ff40a579a0
+MD5 (SDL-1.2.11.tar.gz) = 418b42956b7cd103bfab1b9077ccc149
MD5 (patch-libsd1.2.7-libcaca0.9.diff) = dff6cf5fc97494dbe05880866e151660
-RMD160 (SDL-1.2.9.tar.gz) = 9faeeda9cf8f649a2b506e9db7c5cedb4512cfe7
+RMD160 (SDL-1.2.11.tar.gz) = 91dc8877224415a4ba59e1de57c31861e550d644
RMD160 (patch-libsd1.2.7-libcaca0.9.diff) =
e74a1ece864577b6fdaf8516a9e4b400958e575b
-SHA1 (SDL-1.2.9.tar.gz) = 8140de00e73ccdbdee196fa8fd9952ddb3cc75f1
+SHA1 (SDL-1.2.11.tar.gz) = 2259134d714e35ab1469d513674a3cd02510d198
SHA1 (patch-libsd1.2.7-libcaca0.9.diff) =
4e4d3f5f0286e6960e0e5cdad2f90c54997a6c04
-SIZE (SDL-1.2.9.tar.gz) = 2688179
+SIZE (SDL-1.2.11.tar.gz) = 2796407
SIZE (patch-libsd1.2.7-libcaca0.9.diff) = 28259
Index: patches/patch-Makefile_in
===
RCS file: patches/patch-Makefile_in
diff -N patches/patch-Makefile_in
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-Makefile_in 8 Oct 2006 05:51:54 -
@@ -0,0 +1,21 @@
+$OpenBSD$
+--- Makefile.in.orig Mon Jun 19 23:49:00 2006
Makefile.inSat Oct 7 23:51:35 2006
+@@ -44,7 +44,7 @@ LT_AGE = @LT_AGE@
+ LT_CURRENT = @LT_CURRENT@
+ LT_RELEASE = @LT_RELEASE@
+ LT_REVISION = @LT_REVISION@
+-LT_LDFLAGS = -no-undefined -rpath $(libdir) -release $(LT_RELEASE)
-version-info $(LT_CURRENT):$(LT_REVISION):$(LT_AGE)
++LT_LDFLAGS = -no-undefined -rpath $(libdir) $(LT_RELEASE) -version-info
$(LT_CURRENT):$(LT_REVISION):$(LT_AGE)
+
+ all: $(srcdir)/configure Makefile $(objects) $(objects)/$(TARGET)
$(objects)/$(SDLMAIN_TARGET)
+
+@@ -98,7 +98,7 @@ install-data:
+ $(SHELL) $(auxdir)/mkinstalldirs $(datadir)/aclocal
+ $(INSTALL) -m 644 $(srcdir)/sdl.m4 $(datadir)/aclocal/sdl.m4
+ $(SHELL) $(auxdir)/mkinstalldirs $(libdir)/pkgconfig
+- $(INSTALL) -m 644 $(srcdir)/sdl.pc $(libdir)/pkgconfig
++ $(INSTALL) -m 644 sdl.pc $(libdir)/pkgconfig
+ install-man:
+ $(SHELL) $(auxdir)/mkinstalldirs $(mandir)/man3
+ for src in $(srcdir)/docs/man3/*.3; do \
Index: patches/patch-configure_in
===
RCS file: patches/patch-configure_in
diff -N patches/patch-configure_in
--- patches/patch-configure_in 17 Sep 2005 00:38:15 - 1.25
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,71 +0,0 @@
-$OpenBSD: patch-configure_in,v 1.25 2005/09/17 00:38:15 pvalchev Exp $
configure.in.orig Sun Aug 28 00:31:18 2005
-+++ configure.in Sat Sep 10 20:34:34 2005
-@@ -535,9 +535,6 @@ CheckNASM()
- win32)
- NASMFLAGS="-f win32"
- ;;
-- openbsd)
-- NASMFLAGS="-f aoutb"
-- ;;
- *)
- NASMFLAGS="-f elf"
- ;;
-@@ -1082,9 +1079,6 @@ CheckOpenGL()
- AC_MSG_RESULT($video_opengl)
- if test x$video_opengl = xyes; then
- CFLAGS="$CFLAGS -DHAVE_OPENGL"
--if test x$use_dlopen != xyes; then
--AC_CHECK_LIB(dl, dlopen, SYSTEM_LIBS="$SYSTEM_LIBS -ldl")
--fi
- fi
- fi
- }
-@@ -1105,9 +1099,6 @@ CheckOpenGLQNX()
- if test x$video_opengl = xyes; then
- CFLAGS="$CFLAGS -DHAVE_OPENGL"
- SYSTE
Re: Update: net/tor (Update to 0.1.1.24 included)
> 0.1.1.23 is outdated now. They just released 0.1.1.24. Here the diff: It has a maintainer, did you send him a note too?
Re: UPDATE: pilot-link-0.12.1
> I did not realize that activating libusb support would disable native USB > sync (uvisor), so let's make it a FLAVOR. so what does the libusb flavor actually gain then ?
Re: UPDATE: subversion 1.4.0
> With alpha now using gcc3, the *_main_c patches are no longer needed. > Attached > a new diff. Please test. There are other architectures that still use gcc2.
Re: patch: isc dhcp with privdrop
Come on people - why did this get dropped???
> Date: Thu, 23 Mar 2006 09:28:27 -0600 (CST)
> From: Jakob Schlyter <[EMAIL PROTECTED]>
> To: ports@openbsd.org
> Subject: patch: isc dhcp with privdrop
> Message-ID: <[EMAIL PROTECTED]>
>
> could users of the isc dhcp please test this patch.
>
> thanks,
>
> jakob
>
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/net/isc-dhcp/Makefile,v
> retrieving revision 1.11
> diff -u -u -r1.11 Makefile
> --- Makefile 16 Aug 2005 18:28:55 - 1.11
> +++ Makefile 23 Mar 2006 15:27:55 -
> @@ -6,6 +6,7 @@
>
> VERSION= 3.0.3
> DISTNAME=isc-dhcp-${VERSION}
> +PKGNAME= isc-dhcp-${VERSION}p0
> CATEGORIES= net
>
> DISTFILES= dhcp-${VERSION}.tar.gz
> @@ -37,9 +38,12 @@
>
> EXAMPLEDIR= share/examples/isc-dhcp
>
> +do-configure:
> + cd ${WRKSRC} && ./configure \
> + --copts "${CONFIGURE_ARGS} -DPARANOIA -DEARLY_CHROOT ${CFLAGS}"
> +
> post-extract:
> @sed s,y0y0y0,${PREFIX}, < ${FILESDIR}/site.conf >
> ${WRKSRC}/site.conf
> -
>
> post-install:
> ${INSTALL_DATA_DIR} ${PREFIX}/${EXAMPLEDIR}
> Index: patches/patch-paranoia
> ===
> RCS file: patches/patch-paranoia
> diff -N patches/patch-paranoia
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-paranoia23 Mar 2006 15:27:55 -
> @@ -0,0 +1,168 @@
> +--- server/dhcpd.c Thu Jun 21 22:12:58 2001
> server/dhcpd.c Wed Oct 17 08:23:00 2001
> +@@ -56,6 +56,16 @@
> + #include "version.h"
> + #include
> +
> ++#if defined (PARANOIA)
> ++# include
> ++# include
> ++# include
> ++/* get around the ISC declaration of group */
> ++# define group real_group
> ++#include
> ++# undef group
> ++#endif /* PARANOIA */
> ++
> + static void usage PROTO ((void));
> +
> + TIME cur_time;
> +@@ -204,6 +214,22 @@
> + omapi_object_dereference (&listener, MDL);
> + }
> +
> ++#if defined (PARANOIA)
> ++/* to be used in one of two possible scenarios */
> ++static void setup_chroot (char *chroot_dir) {
> ++if (geteuid())
> ++log_fatal ("you must be root to use chroot");
> ++
> ++if (chroot(chroot_dir)) {
> ++log_fatal ("chroot(\"%s\"): %m", chroot_dir);
> ++}
> ++if (chdir ("/")) {
> ++/* probably permission denied */
> ++log_fatal ("chdir(\"/\"): %m");
> ++}
> ++}
> ++#endif /* PARANOIA */
> ++
> + int main (argc, argv, envp)
> + int argc;
> + char **argv, **envp;
> +@@ -236,6 +262,14 @@
> + char *traceinfile = (char *)0;
> + char *traceoutfile = (char *)0;
> + #endif
> ++#if defined (PARANOIA)
> ++char *set_user = 0;
> ++char *set_group = 0;
> ++char *set_chroot = 0;
> ++
> ++uid_t set_uid = 0;
> ++gid_t set_gid = 0;
> ++#endif /* PARANOIA */
> +
> + /* Make sure we have stdin, stdout and stderr. */
> + status = open ("/dev/null", O_RDWR);
> +@@ -298,6 +332,20 @@
> + if (++i == argc)
> + usage ();
> + server = argv [i];
> ++#if defined (PARANOIA)
> ++} else if (!strcmp (argv [i], "-user")) {
> ++if (++i == argc)
> ++usage ();
> ++set_user = argv [i];
> ++} else if (!strcmp (argv [i], "-group")) {
> ++if (++i == argc)
> ++usage ();
> ++set_group = argv [i];
> ++} else if (!strcmp (argv [i], "-chroot")) {
> ++if (++i == argc)
> ++usage ();
> ++set_chroot = argv [i];
> ++#endif /* PARANOIA */
> + } else if (!strcmp (argv [i], "-cf")) {
> + if (++i == argc)
> + usage ();
> +@@ -397,6 +445,44 @@
> + trace_seed_stop, MDL);
> + #endif
> +
> ++#if defined (PARANOIA)
> ++/* get user and group info if those options were given */
> ++if (set_user) {
> ++struct passwd *tmp_pwd;
> ++
> ++if (geteuid())
> ++log_fatal ("you must be root to set user");
> ++
> ++if (!(tmp_pwd = getpwnam(set_user)))
> ++log_fatal ("no such user: %s", set_user);
> ++
> ++set_uid = tmp_pwd->pw_uid;
> ++
> ++/* use the user's group as the default gid */
> ++if (!set_group)
> ++set_gid = tmp_pwd->pw_gid;
> ++}
> ++
> ++if (set_group) {
> ++/* get around the ISC declaration of group */
> ++#define group real_group
> ++struct group *tmp_grp;
> ++
> ++if (geteuid())
> ++log_fatal ("you must be root to set group");
> ++
> ++if (!(tmp_grp = getgrnam(set_group)))
> ++log_fatal ("no such group: %s", set_group);
> ++
> ++
Re: abcde: Fix which(1) usage, fix normalizing and MP3 id3 tagging
> This enables normalizing using audio/normalize (as opposed to
> normalize-audio, which we don't have) and id3 tagging to MP3s using
> audio/id3ed (as opposed to id3, which we don't have).
>
> There is also a bug in the way they use which(1); our version prints
> error messages to stdout, whereas they expect nothing to be printed
> out.
Anybody else tested/checked this? Looks reasonable to me...
> Index: Makefile
> ===
> RCS file: /cvs/ports/audio/abcde/Makefile,v
> retrieving revision 1.12
> diff -u -r1.12 Makefile
> --- Makefile 29 Jun 2006 01:41:23 - 1.12
> +++ Makefile 29 Jun 2006 05:40:22 -
> @@ -6,7 +6,7 @@
> # cd-diskid version number
> V2= 0.9
> DISTNAME=abcde_$V.orig
> -PKGNAME= abcde-$V
> +PKGNAME= abcde-${V}p0
> CATEGORIES= audio
>
> HOMEPAGE=http://www.hispalinux.es/~data/abcde.php
> @@ -31,7 +31,7 @@
> FLAVOR?=
>
> NO_REGRESS= Yes
> -WRKDIST= ${WRKDIR}/${PKGNAME}
> +WRKDIST= ${WRKDIR}/abcde-$V
>
> .if ${FLAVOR:L:Mlame}
> DISTFILES+= id3_0.12.orig.tar.gz:1
> Index: patches/patch-abcde
> ===
> RCS file: /cvs/ports/audio/abcde/patches/patch-abcde,v
> retrieving revision 1.5
> diff -u -r1.5 patch-abcde
> --- patches/patch-abcde 13 Apr 2004 21:07:48 - 1.5
> +++ patches/patch-abcde 29 Jun 2006 05:40:22 -
> @@ -1,7 +1,39 @@
> $OpenBSD: patch-abcde,v 1.5 2004/04/13 21:07:48 brad Exp $
> abcde.orig Fri Apr 9 20:12:15 2004
> -+++ abcdeSun Apr 11 16:58:13 2004
> -@@ -1574,7 +1574,7 @@
> +--- abcde.orig Sun Aug 14 15:51:31 2005
> abcdeThu Jun 29 01:38:10 2006
> +@@ -490,8 +490,9 @@ do_tag ()
> +
> + # FIXME # track numbers in mp3 come with 1/10, so we cannot
> happily substitute them with $TRACKNUM
> + run_command tagtrack-$1 $TAGGER $TAGGEROPTS -c "$COMMENTOUTPUT"
> \
> +--A "$DALBUM" -a "$TRACKARTIST" -t "$TRACKNAME" -y
> "$CDYEAR" \
> +--g "$GENREID" -T "${TRACKNUM:-$1/$TRACKS}" \
> ++-a "$DALBUM" -n "$TRACKARTIST" -s "$TRACKNAME" -y
> "$CDYEAR" \
> ++-g "$CDGENRE" -k "${TRACKNUM:-$1/$TRACKS}"
> ++
> + "$ABCDETEMPDIR/track$1.$OUTPUT"
> + ;;
> + vorbis|ogg)
> +@@ -857,8 +858,7 @@ do_batch_gain ()
> + do
> + MP3FILES="$TRACKFILES track$UTRACKNUM.mp3"
> + done
> +-# XXX: Hard-coded batch option!
> +-$NORMALIZER -b $NORMALIZEROPTS $TRACKFILES
> ++$NORMALIZER $NORMALIZEROPTS $TRACKFILES
> + RETURN=$?
> + if [ "$RETURN" != "0" ]; then
> + echo "batch-normalize: $NORMALIZER returned code $RETURN" >>
> errors
> +@@ -886,8 +886,7 @@ do_batch_normalize ()
> + do
> + TRACKFILES="$TRACKFILES track$UTRACKNUM.wav"
> + done
> +-# XXX: Hard-coded batch option!
> +-$NORMALIZER -b $NORMALIZEROPTS $TRACKFILES
> ++$NORMALIZER $NORMALIZEROPTS $TRACKFILES
> + RETURN=$?
> + if [ "$RETURN" != "0" ]; then
> + echo "batch-normalize: $NORMALIZER returned code $RETURN" >>
> errors
> +@@ -2058,7 +2057,7 @@ VAPLAYLISTFORMAT='${ARTISTFILE}-${ALBUMF
> VAPLAYLISTDATAPREFIX=''
> DOSPLAYLIST=n
> COMMENT=''
> @@ -10,16 +42,34 @@
> ENCNICE=10
> READNICE=10
> DISTMP3NICE=10
> -@@ -1683,7 +1683,7 @@
> - # We should have disktool in OSX, but let's be sure...
> +@@ -2095,7 +2094,7 @@ SPEEXENC=speexenc
> + # mpp (Musepack)
> + MPPENC=mppenc
> +
> +-ID3=id3
> ++ID3=id3ed
> + ID3V2=id3v2
> + CDPARANOIA=cdparanoia
> + CDDA2WAV=cdda2wav
> +@@ -2108,7 +2107,7 @@ MD5SUM=md5sum
> + DISTMP3=distmp3
> + VORBISCOMMENT=vorbiscomment
> + METAFLAC=metaflac
> +-NORMALIZE=normalize-audio
> ++NORMALIZE=normalize
> + CDSPEED=eject
> + VORBISGAIN=vorbisgain
> + MKCUE=mkcue
> +@@ -2170,7 +2169,7 @@ elif [ X$(uname) = "XDarwin" ] ; then
> NEEDDISKTOOL=y
> + CDROMREADERSYNTAX=cddafs
> elif [ X$(uname) = "XOpenBSD" ] ; then
> -HTTPGET=wget
> +HTTPGET=ftp
> MD5SUM=md5
> else
> HTTPGET=wget
> -@@ -1719,6 +1719,7 @@
> +@@ -2207,6 +2206,7 @@ if [ "$HTTPGETOPTS" = "" ] ; then
> wget) HTTPGETOPTS="-q -O -";;
> curl) HTTPGETOPTS="-f -s";;
> fetch)HTTPGETOPTS="-q -o -";;
> @@ -27,3 +77,17 @@
> *) echo "abcde warning: HTTPGET in non-standard and HTTPGETOPTS
> are not defined." >&2 ;;
> esac
> fi
> +@@ -2667,10 +2667,11 @@ for X in $CDROMREADER $CDDISCID ${NEEDTA
> + do
> + # Cut off the command-line options we just added in
> + X=$(echo $X | cut -d' ' -f2)
> +-if [ "$(which $X)" = "" ]; then
> ++which -- "$X" >/dev/null || {
> + echo "abcde error: $X is not in your path." >&2
> + exit 1
> +-elif [ ! -x $(which $X) ]; then
> ++}
> ++if [ ! -x $(which $X) ]; then
> + echo "abcde error: $X is no
ports tree lock
The tree is locked now. If you think something is important enough to consider for release, talk to me. Keep testing package snapshots... we're in full release mode.
ports tree soft lock
We are nearing release again. Stop working on big upgrades and features and concentrate on quality. From now on every commit should be approved by at least one of these people: pvalchev, naddy, espie, sturm Once again, concentrate on testing and fixing things. Simple upgrades and new ports with no good reason will be denied, please concentrate your time on making 4.0 better!
vmware in -current
Vmware has been broken in -current for a long time now by the PAE changes. If you have an interest in a working vmware in the next release, and want to try your hand at a hard problem, someone stepping up with a fix would be great. todd@ and mcbride@ should have details, and in fact posting them to the list may be a good idea.
math/cfitsio regress test
It requires that the library be installed so 'make regress' fails.
...
cd /t/obj/ports/cfitsio-3.006/cfitsio && ./testprog >testprog.lis
./testprog: can't load library 'libcfitsio.so.0.0'
*** Error code 4
Should we point LD_LIBRARY_PATH to the fake area so this works?
Or is this patch acceptable? Seems to be the correct thing to do.
Also worth noting is that the test itself produces unexpected
results on sparc64/amd64 and probably others...
Index: Makefile
===
RCS file: /cvs/ports/math/cfitsio/Makefile,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 Makefile
--- Makefile12 Jun 2006 11:14:08 - 1.1.1.1
+++ Makefile29 Jun 2006 00:39:09 -
@@ -39,6 +39,7 @@
${INSTALL_PROGRAM} ${WRKBUILD}/{fitscopy,imcopy,listhead} ${PREFIX}/bin
${INSTALL_DATA} ${WRKBUILD}/cookbook.c ${DOCDIR}
+REGRESS_DEPENDS=::math/cfitsio
do-regress:
cd ${WRKBUILD} && ${MAKE} testprog
cd ${WRKBUILD} && ./testprog >testprog.lis
Re: UPDATE: graphics/netpbm
> Builds on amd64, i386, sparc64.
> No checking of dependent ports done yet.
those are the only 2 that break i think (lib depends ones)
someone needs to make sure the RUN_DEPENDS ones work by
testing them too.
Index: converters/ppmtoTbmp/Makefile
===
RCS file: /cvs/ports/converters/ppmtoTbmp/Makefile,v
retrieving revision 1.6
diff -u -p -r1.6 Makefile
--- converters/ppmtoTbmp/Makefile 21 Nov 2004 22:53:58 - 1.6
+++ converters/ppmtoTbmp/Makefile 1 Jun 2006 04:16:48 -
@@ -3,6 +3,7 @@
COMMENT= "PPM to Pilot bitmap converter"
DISTNAME= ppmtoTbmp-1.1
+PKGNAME= ${DISTNAME}p0
CATEGORIES=converters graphics
HOMEPAGE= http://www.isaac.cs.berkeley.edu/pilot/
@@ -12,14 +13,14 @@ PERMIT_PACKAGE_CDROM= Yes
PERMIT_PACKAGE_FTP=Yes
PERMIT_DISTFILES_CDROM=Yes
PERMIT_DISTFILES_FTP= Yes
-WANTLIB= c
+WANTLIB= c m
MASTER_SITES= ${HOMEPAGE}
MAKE_FLAGS=CFLAGS="${CFLAGS} -I${LOCALBASE}/include" \
- LDLIBS="-L${LOCALBASE}/lib -lpnm -lppm -lpgm -lpbm"
+ LDLIBS="-L${LOCALBASE}/lib -lnetpbm -lm"
-LIB_DEPENDS= pnm,ppm,pgm,pbm::graphics/netpbm
+LIB_DEPENDS= netpbm::graphics/netpbm
do-install:
${INSTALL_PROGRAM} ${WRKBUILD}/Tbmptopnm ${PREFIX}/bin
Index: converters/ppmtoTbmp/patches/patch-ppmtoTbmp_c
===
RCS file: converters/ppmtoTbmp/patches/patch-ppmtoTbmp_c
diff -N converters/ppmtoTbmp/patches/patch-ppmtoTbmp_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ converters/ppmtoTbmp/patches/patch-ppmtoTbmp_c 1 Jun 2006 04:11:38
-
@@ -0,0 +1,14 @@
+$OpenBSD$
+--- ppmtoTbmp.c.orig Wed May 31 22:11:06 2006
ppmtoTbmp.cWed May 31 22:11:32 2006
+@@ -5,8 +5,8 @@
+ * Based on ppmtopuzz.c by Jef Paskanzer, from the netpbm-1mar1994 package.
+ */
+
+-#include "ppm.h"
+-#include "ppmcmap.h"
++#include
++#include
+
+ static int colcompare(const void *a, const void *b)
+ {
Index: graphics/vid/Makefile
===
RCS file: /cvs/ports/graphics/vid/Makefile,v
retrieving revision 1.9
diff -u -p -r1.9 Makefile
--- graphics/vid/Makefile 10 Sep 2005 18:29:55 - 1.9
+++ graphics/vid/Makefile 1 Jun 2006 04:09:57 -
@@ -4,7 +4,7 @@
COMMENT= "get images from USB cameras using the OV511(+) chipsets"
DISTNAME= vid-1.0.1
-PKGNAME= ${DISTNAME}p2
+PKGNAME= ${DISTNAME}p3
CATEGORIES=graphics
HOMEPAGE= http://ovtvid-bsd.sourceforge.net/
@@ -18,11 +18,11 @@ PERMIT_DISTFILES_FTP= Yes
MASTER_SITES= ${MASTER_SITE_SOURCEFORGE:=ovtvid-bsd/}
-LIB_DEPENDS= pbm,pnm::graphics/netpbm
-WANTLIB= c
+LIB_DEPENDS= netpbm::graphics/netpbm
+WANTLIB= c m
MAKE_FLAGS=CFLAGS="${CFLAGS}" CPPFLAGS="-I${LOCALBASE}/include" \
- LIBS="-L${LOCALBASE}/lib -lpnm -lpbm"
+ LIBS="-L${LOCALBASE}/lib -lnetpbm -lm"
ALL_TARGET=default
NO_REGRESS=Yes
Re: UPDATE: graphics/netpbm
> > Builds on amd64, i386, sparc64.
>
> As Bernd learned the hard way, this port triggers an amazing 11
> ICEs (instances of internal compiler error) on alpha, unless compiled
> without optimization.
But soon with gcc3 this won't be a problem I guess (this
is good though for now)
> --- netpbm.orig/Makefile Wed May 31 01:17:17 2006
> +++ netpbm/Makefile Wed May 31 01:19:13 2006
> @@ -46,3 +46,8 @@
> .else
> MAKE_FLAGS+= NETPBMLIBTYPE=unixshared
> .endif
> +
> +# multiple internal compiler errors
> +.if ${MACHINE_ARCH} == "alpha"
> +CFLAGS:= ${CFLAGS:N-O*}
> +.endif
> --
> Christian "naddy" Weisgerber [EMAIL PROTECTED]
Re: NEW: security/beecrypt
> Beecrypt is a crytography library, it is present both
> on NetBSD and FreeBSD's ports tree.
>
> This is my first attempt at creating a port, any corrections
> are most welcome.
- It looks to have various dependencies none of which are registered in
your port (such as python). Or these need to be turned off in the
configure script explicitly
- It has its own endianness.{c,h} which is not needed and in fact
produces shitloads of warnings as it overrides our sys/endian.h
This part of configure seems broken and should be fixed:
checking endian.h usability... no
checking endian.h presence... no
checking for endian.h... no
- The CFLAGS have some linux-specific stuff it seems, such as
-Wa,--noexecstack which appears just ignored right nwo and should
be removed
Also once these are resolved it should be tested by people on more
architectures.
Re: opinions about editors/openoffice-linux
> Do you mean opera-flashplugin? Neither opera nor acroread have linux > in their package or port name either. Still, having a subdir openoffice > doesn't make sense to me. Just add openoffice-linux, later add > openoffice and remove openoffice-linux. Or is there going to be a bunch > of openoffice related ports? Oh yes, definitely no subdir, misunderstanding here. I jsut think it makes sense to call it "openoffice-linux" if it will be imported at all, as it should not be confused for when a real port is added (and that one deleted).
Re: opinions about editors/openoffice-linux
> > In the meantime I am working on the native port of openoffice that > > will be placed to the same directory. (ports/editors/openoffice). > > What's the point? Just import your current port as editors/openoffice > and if you ever get the native version done, update the port. I don't > see why we would want to keep both versions. It's not really openoffice though, it's linux-emulated-binary and as such definitely should be called openoffice-linux to make that clear. Just like we've named flashplugin-linux... Personally I'm not fond of this but I guess folks'll find it useful.
Re: /tmp/.shtool.$$ files from php5-core install
> I just want to check to make sure that this is a "normal" > and "expected" behavior. > > During 'make package' step of building the php5-core port > these files are 'touch'ed. Nobody feel motivated to fix it? Come on it should be easy! > Details: > [EMAIL PROTECTED] $ pwd > /usr/port/www/php5/core > > [EMAIL PROTECTED] $ uname -a > OpenBSD puter.atmydomain.com 3.8 GENERIC#0 i386 > > [EMAIL PROTECTED] $ ls -l /tmp/ > > total 8 > drwxrwxrwt 2 root wheel 512 Mar 29 00:47 .ICE-unix/ > drwxrwxrwt 2 root wheel 512 Mar 29 00:47 .X11-unix/ > -rw--- 1 root wheel0 Apr 1 01:28 .shtool.11619 > -rw--- 1 root wheel0 Apr 1 01:28 .shtool.15599 > -rw--- 1 root wheel0 Apr 1 01:28 .shtool.17034 > -rw--- 1 root wheel0 Apr 1 01:28 .shtool.17169 > -rw--- 1 root wheel0 Apr 1 01:28 .shtool.17570 > -rw--- 1 root wheel0 Apr 1 01:28 .shtool.19110 > -rw--- 1 root wheel0 Apr 1 01:28 .shtool.22129 > -rw--- 1 root wheel0 Apr 1 01:28 .shtool.24573 > -rw--- 1 root wheel0 Apr 1 01:28 .shtool.28810 > -rw--- 1 root wheel0 Apr 1 01:28 .shtool.29591 > -rw--- 1 root wheel0 Apr 1 01:28 .shtool.3022 > -rw--- 1 root wheel0 Apr 1 01:28 .shtool.30527 > -rw--- 1 root wheel0 Apr 1 01:28 .shtool.30817 > -rw--- 1 root wheel0 Apr 1 01:28 .shtool.31440 > -rw--- 1 root wheel0 Apr 1 01:28 .shtool.31605 > -rw--- 1 root wheel0 Apr 1 01:28 .shtool.31636 > -rw--- 1 root wheel0 Apr 1 01:28 .shtool.5255 > -rw--- 1 root wheel0 Apr 1 01:28 .shtool.6835 >
Re: Update: archivers/zoo
Actually there are way more issues in it ... a small list that
linux people have fixed:
http://rpmfind.net/linux/RPM/suse/updates/10.0-OSS/i386/rpm/i586/zoo-2.10-858.4.i586.html
Patches for those follow; however this thing is a pile of poo
altogether. There are likely many other issues (just look at the
amount of remaining strcat/strcpy which come from user input).
Someone should fix them all but I feel like I've already wasted
enough time looking at this pile of poo. Anyway, someone
should double check these don't break anything at least.
Index: Makefile
===
RCS file: /cvs/ports/archivers/zoo/Makefile,v
retrieving revision 1.17
diff -u -p -r1.17 Makefile
--- Makefile21 Nov 2004 12:50:33 - 1.17
+++ Makefile7 Apr 2006 07:41:16 -
@@ -3,7 +3,7 @@
COMMENT= "handle the old .ZOO archive format"
DISTNAME= zoo-2.10pl1
-PKGNAME= zoo-2.10.1
+PKGNAME= zoo-2.10.1p0
CATEGORIES=archivers
MASTER_SITES= ftp://ftp.kiarchive.ru/pub/unix/arcers/
Index: patches/patch-misc_c
===
RCS file: patches/patch-misc_c
diff -N patches/patch-misc_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-misc_c7 Apr 2006 07:41:16 -
@@ -0,0 +1,21 @@
+$OpenBSD$
+--- misc.c.origTue Jul 16 09:52:54 1991
misc.c Fri Apr 7 01:36:17 2006
+@@ -135,11 +135,16 @@ if available, else the short filename is
+ char *fullpath (direntry)
+ struct direntry *direntry;
+ {
+- static char result[PATHSIZE];
++ static char result[PATHSIZE+LFNAMESIZE+12]; /* Room for enough space.*/
+ combine (result,
+ direntry->dirlen != 0 ? direntry->dirname : "",
+ (direntry->namlen != 0) ? direntry->lfname :
direntry->fname
+ );
++
++ if (strlen (result) >= PATHSIZE) {
++ prterror ('f', "Combined dirname and filename too long!\n");
++ }
++
+ return (result);
+ }
+
Index: patches/patch-parse_c
===
RCS file: patches/patch-parse_c
diff -N patches/patch-parse_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-parse_c 7 Apr 2006 07:41:16 -
@@ -0,0 +1,12 @@
+$OpenBSD$
+--- parse.c.orig Tue Jul 16 09:54:43 1991
parse.cFri Apr 7 01:37:24 2006
+@@ -39,7 +39,7 @@ char *fname;
+char *namep; /* points to relevant part of tempname */
+
+char *p;
+- strcpy (tempname, fname);
++ strlcpy(tempname, fname, LFNAMESIZE);
+
+ #ifdef DEBUG
+ printf ("parse: supplied name is [%s].\n", tempname);
Index: patches/patch-portable_c
===
RCS file: patches/patch-portable_c
diff -N patches/patch-portable_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-portable_c7 Apr 2006 07:41:16 -
@@ -0,0 +1,35 @@
+$OpenBSD$
+--- portable.c.origTue Jul 16 09:55:11 1991
portable.c Fri Apr 7 01:35:28 2006
+@@ -364,6 +364,31 @@ ZOOFILE zoo_file;
+ show_dir(direntry);
+}
+ #endif
++ char *p;
++ /* take off '../' */
++ while ((p = strstr( direntry->dirname, "../" )) != NULL) {
++ while (*(p+3) != '\0') {
++*p = *(p + 3);
++p++;
++ }
++ *p = *(p+3); /* move last null */
++ //printf("zoo: skipped \"../\" path component in '%s'\n",
direntry->dirname);
++ }
++ /* take off '/' */
++ if ( direntry->dirname[0] == '/' ) {
++ p = direntry->dirname;
++ while (*p != '\0') {
++*p = *(p + 1);
++p++;
++ }
++ *p = *(p+1); /* move last null */
++ //printf("zoo: skipped \"/\" path component in '%s'\n",
direntry->dirname);
++ }
++ /* take off '..' */
++ if(!strcmp(direntry->dirname, ".."))
++ direntry->dirname[0] = '\0';
++ /* direntry->dirlen = strlen(direntry->dirname); */
++
+return (0);
+ }
+
Re: update: net/nmap
> way overdue update. can someone test this on sparc64?
Re: net/centericq port update to 4.21.0
> PV> I have tried to fix this but failed; unfortunately the author has failed > PV> to take it seriously as well. > > PV> This update also suffers from the fact that it does not detect the > PV> installed libiconv/libintl (which is listed as dependency) and builds > PV> its own copy - that must be fixed. > > I tried to fix configure thus it could find installed libiconv and > libintl. It's still not fixed. But centericq works using it's own > copies. Sorry, just because "it works", doesn't mean it's correct or that it'll be accepted - it won't. This is a problem and must be fixed first by someone (yes it's stupid, I've looked at it briefly and the configure script is totally broken).
Re: net/centericq port update to 4.21.0
> >MSN support is disabled now, because it needs > > gcc 3.4, believe me. Otherwise, it just segfaults. > Even with the patch from > http://centericq.de/archive/contrib/patches/centericq-4.21.0.msn.patch I have tried to fix this but failed; unfortunately the author has failed to take it seriously as well. This update also suffers from the fact that it does not detect the installed libiconv/libintl (which is listed as dependency) and builds its own copy - that must be fixed.
Re: patch for mozilla and mozilla-firefox
> Here is a patch that stops firefox crashing on sites like zdnet and > ebay. (Murphy's crappy article about OpenBSD was a great help to find > this null-pointer dereference ;) ) .. Has anyone encountered problems with this patch? The code looks correct and obvious and I plan to otherwise commit it. Has it been submitted to the mozilla folks?
Re: [update] mark devel/gstreamer broken
> Since there's now close to no chance that devel/gstreamer will be fixed > > in time for release, I think it should be marked as broken at least on > > amd64 (I don't have other arches to see if it works or not). > > Otherwise the release's ports tree will ship in an inconsistent state. > I have a better idea - fix it. In any case 3.9 is long done and we're already working on -current.
Re: www/minimo: shlibsign core dump
> While trying to build www/minimo on amd64 -current > shlibsign coredumps. .. This is caused by patch-nsprpub_pr_src_misc_prdtoa_c which I added in order to fix a similar crash on Zaurus. The patch ripped out the mozilla implementation of strtod(3) with the one taken directly from our libc. I have no clue why this broke amd64 and have not figured it out yet. Feel free to hack at it. Also if someone brings this port up to date (there is a newer snapshot on the master site), that would be good.
Re: pkg_add in feb 15 current
> amaaq> sudo pkg_add teTeX-base > Error from http://openbsd.cz/pub/OpenBSD/snapshots/packages/i386/: > Successfully retrieved file. > Can't resolve teTeX-base > > (a simple typo. s/-base/_base/) And how do you expect it to know that? It would be like asking for Coke in a restaurant, and being given Pepsi (or anything else) without a warning. That's evil. > amaaq> sudo pkg_add teTeX_base > Error from http://openbsd.cz/pub/OpenBSD/snapshots/packages/i386/: > Successfully retrieved file. > Ambiguous: teTeX_base could be teTeX_base-3.0p3 teTeX_base-3.0p3-no_x11 Same here. Use pkg_add -i for interactive mode, then it'll ask you which you prefer. There are no bugs here. > another one. so is it success or error? :) Look up ambiguous in the dictionary
firefox on sparc (or gcc2)
firefox is broken with gcc2. i don't have anything but the log handy right now, but here's how it broke. in case someone wants to try to fix this, you're more than welcome... c++ -o nsDeviceContextPS.o -c -DMOZILLA_INTERNAL_API -DOSTYPE=\"OpenBSD3\" -DOSARCH=\"OpenBSD\" -DBUILD_ID=2006012017 -I../.. -I./.. -I./../shared -I../../../dist/include/xpcom -I../../../dist/include/string -I../../../dist/include/widget -I../../../dist/include/pref -I../../../dist/include/caps -I../../../dist/include/locale -I../../../dist/include/uconv -I../../../dist/include/view -I../../../dist/include/necko -I../../../dist/include/imglib2 -I../../../dist/include/unicharutil -I../../../dist/include/gfx -I../../../dist/include -I../../../dist/include/nspr -I/usr/X11R6/include/freetype2 -I/usr/X11R6/include -I/usr/local/include/libIDL-2.0 -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include -I/usr/local/include/libpng -I/usr/lib/include -I../../../dist/sdk/include -I/usr/X11R6/include -I/usr/X11R6/include/freetype2 -I/usr/X11R6/include -fPIC -I/usr/X11R6/include -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Wcast-al! ign -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wno-long-long -O2 -pipe -pthread -pipe -DNDEBUG -DTRIMMED -Os -DXTHREADS -D_REENTRANT -I/usr/local/include/gtk-2.0 -I/usr/local/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/local/include/atk-1.0 -I/usr/local/include/pango-1.0 -I/usr/X11R6/include/freetype2 -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/X11R6/include -DMOZILLA_CLIENT -include ../../../mozilla-config.h -Wp,-MD,.deps/nsDeviceContextPS.pp nsDeviceContextPS.cpp In file included from nsDeviceContextPS.h:50, from nsDeviceContextPS.cpp:55: nsFontMetricsPS.h: In method `PRInt32 nsFontPS::SupportsChar(short unsigned int)': nsFontMetricsPS.h:194: warning: cast increases required alignment of target type In file included from nsDeviceContextPS.h:50, from nsDeviceContextPS.cpp:55: nsFontMetricsPS.h: At top level: nsFontMetricsPS.h:285: ANSI C++ forbids data member `fontps' with same name as enclosing class gmake[4]: gmake[4]: Leaving directory `/usr/obj/ports/mozilla-firefox-1.5p3/mozilla/gfx/src/ps' gmake[3]: Leaving directory `/usr/obj/ports/mozilla-firefox-1.5p3/mozilla/gfx/src' gmake[2]: Leaving directory `/usr/obj/ports/mozilla-firefox-1.5p3/mozilla/gfx' gmake[1]: Leaving directory `/usr/obj/ports/mozilla-firefox-1.5p3/mozilla' *** Error code 2
ports tree locked
The ports tree is now locked. What that means is that you should be very careful with the changes you propose and everything should be approved by me. However, you must discuss it with the usual suspects and other developers as well. Accept that we will ship with some bugs, but focus on fixing the simple problems and what can be fixed reasonably. Only look at important issues and do not think "I'll throw this update in, it looks good and I'm sure it won't hurt anything" because now is the wrong time to do this. Focus on testing the package snapshots! The main reason we do this whole locking process is because the ports tree is so large and it takes a long time to build. Noticing problems can take a while and we need time to address them, so help out!
Re: any erlang ports? (otp r10bX)
> 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. Let's get this straight: it was asked for people to stop submitting non-important updates, or updates with a high risk of breaking things (like a large library change) due to the proximity of the next release. This is because subtle breakage is often not noticed for weeks, and we don't want to ship 3.9 with broken packages that people rely upon. However, bug fixes SHOULD be encouraged. The above is clearly a bugfix and should be a priority to fix for 3.9. In fact it is exactly this type of changes that people should be looking at right now!
Re: UPDATE: firefox 1.5.0.1
If this update is going to make 3.9, this is a pathetic amount of testing reports. This is important, please provide feedback! > Date: Thu, 2 Feb 2006 15:40:34 +0100 > From: Peter Stromberg <[EMAIL PROTECTED]> > To: ports@openbsd.org > Subject: UPDATE: firefox 1.5.0.1 > Message-ID: <[EMAIL PROTECTED]> > > Firefox 1.5.0.1 is a stability-and-security update to Firefox 1.5. > It also includes a number of low-risk fixes for other types of bugs. > > http://www.squarefree.com/burningedge/releases/1.5.0.1.html?dailytech ...
sparc packages snapshot
Just copied fresh sparc and macppc packages snapshots. There is a fairly extensive breakage on sparc, there are 59 broken ports and as a result a total of 354 packages are missing (due to dependencies). This is of course to be expected, since sparc is one of the few architectures remaining to use gcc2 and most of the breakage is caused due to that. The report follows below, perhaps people want to fix some of them. Now is the time, if you want to see any of htem in 3.9 (especially mozilla-firefox should really be fixed!) lang/ocaml out of memory databases/openldap Error in package: "/usr/obj/ports/openldap-2.3.11/fake-sparc//usr/local/lib/libldap-2.3.so.8.1" does not exist Error in package: "/usr/obj/ports/openldap-2.3.11/fake-sparc//usr/local/lib/libldap.so.8.1" does not exist but not reproducible... as a result a lot of stuff (eg. all KDE) did not build security/libgcrypt undefined reference to __udiv_qrnnd lang/nhc98 'Missing library for gmp' also not reproducible.. devel/libsigc++-2 seems like broken w/ gcc2 games/scummvm common/list.h: In method `T2 & Common::List::Iterator::operator *() const': common/list.h:94: `Node' is not a template common/list.h:94: warning: ANSI C++ forbids declaration `' with no type multimedia/libquicktime out of mem security/p5-Digest-MD5-M4p M4p.xs:135: stray '\' in program math/pari ../src/kernel/sparcv8/level0_sparcv8_micro.S:70: Error: Unknown opcode: `globl' www/mozilla-firefox nsFontMetricsPS.h: At top level: nsFontMetricsPS.h:285: ANSI C++ forbids data member `fontps' with same name as enclosing class www/cssed ScintillaGTK.cxx:1164: syntax error before `>=' emulators/simh wants -std=c99 net/xorpSTL-related errors x11/goggles ogle not for sparc dep. devel/gstreamer-plugins,-vorbis gcc2-related var needs to be moved to beginning of block productivity/ledger fdstream.hpp:29: istream: No such file or directory lang/gcc/3.3? but anyone care? games/zoom out of mem net/amule Format.h:209: `::numeric_limits' undeclared (first use here) (-gcc2) games/wesnoth gcc2-rel. editors/abiword out of mem x11/gnome/librsvg gcc2 easy to fix x11/xfce4/xfce4-showdesktop gcc2 graphics/py-matplotlib gcc2/c++ www/linkchecker -std=gnu99 not in gcc2 emulators/xmame,x11 out of mem math/maxima clisp not for sparc telephony/app_conferencegcc2 fixes needed graphics/pstoedit ? gcc2 basically same below devel/ddd graphics/gthumb x11/xscreensaver,no_gle net/gtk-gnutella audio/daapd x11/xfce4/xfce4-notes audio/gtkpod devel/mysql++ www/gtkhtml3 emulators/stella sysutils/gkrellm/plugins/wireless devel/mico x11/ogle_gui lang/gcc/3.3,-estdc x11/gnome/libxklavier
Testing Period
As we're nearing release, please concentrate on testing (especially binary packages) and less on needless updates or new ports. Of course there's still time to check out that piece of software you maintain or use and make sure there are no important reliability/security fixes available... The snapshots are in their usual place (use mirrors), ftp://ftp.openbsd.org/pub/OpenBSD/snapshots/packages/ Of course you must be running -current to use them. Help make the next release better! Submit problem reports and/or fixes to this list and the maintainers.
Re: lang/python and NO_SHARED_ARCHS support
Currently it does not get built in fact, because databases/db is marked as NO_SHARED by default, which seems a bit dumb.
gtk+2 backout
Please test this.
package update also seems to work, the major is bumped so it should
be trouble-free to go back in versions and continue life.
There is the XPM security fix that will also need to go in, but
I've left it out here for simplicity.
This should fix the 8bpp displays problems for good, and after 3.9
is done we can re-evaluate. In the meantime, more people should
tell the gtk people that this is a real problem.
Index: Makefile
===
RCS file: /cvs/ports/x11/gtk+2/Makefile,v
retrieving revision 1.30
diff -u -p -r1.30 Makefile
--- Makefile3 Jan 2006 07:33:36 - 1.30
+++ Makefile6 Jan 2006 00:13:31 -
@@ -5,7 +5,7 @@ NOT_FOR_ARCHS= ${NO_SHARED_ARCHS}
COMMENT= "multi-platform graphical toolkit"
COMMENT-docs= "gtk+-2 documentation"
-VERSION= 2.8.9
+VERSION= 2.6.10
DISTNAME= gtk+-${VERSION}
PKGNAME= gtk+2-${VERSION}
PKGNAME-docs= gtk+2-docs-${VERSION}
@@ -14,10 +14,10 @@ CATEGORIES= x11 devel
HOMEPAGE= http://www.gtk.org
MAINTAINER=Marc Matteo <[EMAIL PROTECTED]>
-SHARED_LIBS= gdk-x11-2.0 800.9 \
- gdk_pixbuf-2.0 800.9 \
- gdk_pixbuf_xlib-2.0 800.9 \
- gtk-x11-2.0 800.9
+SHARED_LIBS= gdk-x11-2.0 801.0 \
+ gdk_pixbuf-2.0 801.0 \
+ gdk_pixbuf_xlib-2.0 801.0 \
+ gtk-x11-2.0 801.0
# LGPL
PERMIT_PACKAGE_CDROM= Yes
@@ -33,12 +33,12 @@ MULTI_PACKAGES= -docs
SUBPACKAGE?=
.if ${SUBPACKAGE} != "-docs"
-WANTLIB= X11 Xcursor Xext Xfixes Xinerama Xrender \
- Xrandr c cairo fontconfig freetype glitz m z
+WANTLIB= X11 Xcursor Xext Xfixes Xft Xinerama Xrender \
+ c fontconfig freetype m z
MODULES= devel/gettext
LIB_DEPENDS=
glib-2.0.800.0,gmodule-2.0.800.0,gobject-2.0.800.0::devel/glib2 \
-
pango-1.0.1000.0,pangoft2-1.0.1000.0,pangocairo-1.0.1000.0::devel/pango \
+
pango-1.0.1000.0,pangoft2-1.0.1000.0,pangoxft-1.0.1001.0,pangox-1.0.1001.0::devel/pango
\
atk-1.0.0.1::devel/atk \
tiff.35::graphics/tiff \
png.3::graphics/png \
Index: distinfo
===
RCS file: /cvs/ports/x11/gtk+2/distinfo,v
retrieving revision 1.20
diff -u -p -r1.20 distinfo
--- distinfo3 Jan 2006 07:33:36 - 1.20
+++ distinfo5 Jan 2006 17:34:02 -
@@ -1,4 +1,4 @@
-MD5 (gtk+-2.8.9.tar.bz2) = e7a94132ae6353106c80cd4a1106a368
-RMD160 (gtk+-2.8.9.tar.bz2) = 3c458a11d22c7d658fcc65b969bf61d875a7559b
-SHA1 (gtk+-2.8.9.tar.bz2) = 8560c2ac2275bca7b9fd7d00c41555f95c638b82
-SIZE (gtk+-2.8.9.tar.bz2) = 11949090
+MD5 (gtk+-2.6.10.tar.bz2) = 520090ef291e35ba93397060e20f5025
+RMD160 (gtk+-2.6.10.tar.bz2) = 5bb2e4de406e0e6ccf5c66ec48f6ba3e5b0911ff
+SHA1 (gtk+-2.6.10.tar.bz2) = 9ba627683e0dc4bceb5fb900c1ee687638d95fcd
+SIZE (gtk+-2.6.10.tar.bz2) = 11521380
Index: patches/patch-contrib_gdk-pixbuf-xlib_Makefile_in
===
RCS file:
/cvs/ports/x11/gtk+2/patches/patch-contrib_gdk-pixbuf-xlib_Makefile_in,v
retrieving revision 1.6
diff -u -p -r1.6 patch-contrib_gdk-pixbuf-xlib_Makefile_in
--- patches/patch-contrib_gdk-pixbuf-xlib_Makefile_in 3 Jan 2006 07:33:37
- 1.6
+++ patches/patch-contrib_gdk-pixbuf-xlib_Makefile_in 6 Jan 2006 00:24:59
-
@@ -1,7 +1,7 @@
$OpenBSD: patch-contrib_gdk-pixbuf-xlib_Makefile_in,v 1.6 2006/01/03 07:33:37
marcm Exp $
contrib/gdk-pixbuf-xlib/Makefile.in.orig Fri Dec 30 22:59:46 2005
-+++ contrib/gdk-pixbuf-xlib/Makefile.inFri Dec 30 23:00:28 2005
-@@ -293,7 +293,7 @@ INCLUDES = \
+--- contrib/gdk-pixbuf-xlib/Makefile.in.orig Thu Aug 18 08:12:35 2005
contrib/gdk-pixbuf-xlib/Makefile.inThu Jan 5 17:24:45 2006
+@@ -298,7 +298,7 @@ INCLUDES = \
libgdk_pixbuf_xlib_2_0_la_LDFLAGS = \
-export-dynamic \
Index: patches/patch-demos_Makefile_in
===
RCS file: /cvs/ports/x11/gtk+2/patches/patch-demos_Makefile_in,v
retrieving revision 1.8
diff -u -p -r1.8 patch-demos_Makefile_in
--- patches/patch-demos_Makefile_in 13 Nov 2005 06:23:58 - 1.8
+++ patches/patch-demos_Makefile_in 6 Jan 2006 00:21:29 -
@@ -1,7 +1,
abiword va_copy
Make it use va_copy on OpenBSD regardless of the architecture.
Would love some tests on i386/amd64/macppc.
Index: Makefile
===
RCS file: /cvs/ports/editors/abiword/Makefile,v
retrieving revision 1.49
diff -u -r1.49 Makefile
--- Makefile15 Nov 2005 09:21:51 - 1.49
+++ Makefile6 Jan 2006 00:54:39 -
@@ -5,7 +5,7 @@
VERSION= 2.4.1
MAJORVER= ${VERSION:C/..$//}
DISTNAME= abiword-${VERSION}
-PKGNAME= ${DISTNAME}p1
+PKGNAME= ${DISTNAME}p2
CATEGORIES=editors
HOMEPAGE= http://www.abisource.com/
Index: patches/patch-abi_src_af_util_xp_ut_string_class_cpp
===
RCS file: patches/patch-abi_src_af_util_xp_ut_string_class_cpp
diff -N patches/patch-abi_src_af_util_xp_ut_string_class_cpp
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-abi_src_af_util_xp_ut_string_class_cpp6 Jan 2006
00:54:39 -
@@ -0,0 +1,14 @@
+$OpenBSD$
+--- abi/src/af/util/xp/ut_string_class.cpp.origThu Jan 5 12:40:22 2006
abi/src/af/util/xp/ut_string_class.cpp Thu Jan 5 12:41:53 2006
+@@ -342,7 +342,9 @@ UT_printf_string_upper_bound (const char
+ return len;
+ }
+
+-#if !defined (VA_COPY)
++#if !defined (VA_COPY) && defined(__OpenBSD__)
++# define VA_COPY(ap1, ap2) va_copy((ap1),(ap2))
++#elif !defined (VA_COPY)
+ # if defined (__GNUC__) && defined (__PPC__) && (defined (_CALL_SYSV) ||
defined (_WIN32) || defined(WIN32)) || defined(__s390__) || defined(__x86_64__)
+ # define VA_COPY(ap1, ap2) (*(ap1) = *(ap2))
+ # elif defined (VA_COPY_AS_ARRAY)
Re: www/analog
> FYI, it seems that the sources for all but the latest (6.0) version have > disappeared from $MASTER_SITES, thus failing the port build on all but > -current. > > Luckily for cases like this, there are still packages. And contrary to > source files, packages don't disappear. They are also on ftp.openbsd.org/pub/OpenBSD/distfiles/ and after failing to obtain the distfile from MASTER_SITES, the port will (or should, sometimes ftp hangs?) download it from there. That's what MASTER_SITE_BACKUP is for. Don't have control over the rest...
Re: libtool vs. -lresolv
> >The patch is fine as a workaround for above. But regarding upstream > >libtool, I'd rather like the fix be done in the right place, in KDEs > >configury. > > It's not only KDE which barfs at it. Things get worse when you also > have a dummy libdl (libdl functions are in libc), which - out of a > sudden - unbreaks lots of stuff which just refuses to build e.g. mo- > dules without a libdl existing. libdl has been dead/gone for a LONG time now. In fact it is silly to keep libresolv around at this day and age. "Legacy" programs that think they need it can be trivially fixed. I don't think having it around gains anything anymore, it's 2005.
Re: centericq
> so, i downloaded the newest, compiled with --without-msn (no curl here) > and so far it's good. what's the issue i should be looking for? You precisely avoided the problem as it's in the msn code, I've the diff --without-msn in my tree but I was hoping it would get fixed. Ignoring it's broken won't do that, spending some time or submitting a bug report to the author will.
Re: centericq
> i've just upgraded my production server to 3.8 > and i see now, that centericq is marked broken.. > > until the issue is fixed, could the old version be put back? why don't you ask the author to fix it for example? the old version had more than one issue and that's not going to change. you can remove the BROKEN line and you're on your own...
Re: strcmp vs strncmp question
> In the meantime, we're a few posts down the road from the original > question, and I haven't seen any answer; neither on the list, nor on the > Net. I suppose it has something to do with strcmp continuing to compare > until it finds a char with value 0, but I can think of many situations > where this wouldn't occur (it certainly shouldn't be an issue if all > strings are always 0-terminated). > > So, I second patrick's question, and I would ask that someone either > answer the question or provide a link to an answer. If it is indeed such > a frequently asked question, it shouldn't be too hard to find a FAQ > entry or mailing list post that answers it, right? Indeed, it's Rod who decided he knew what he was doing, and had to offend someone who was right. Sad, really... As already said, the obvious answer to the question is that most of these patches are plain wrong. I'm surprised they haven't been fixed yet...
Re: new flavor for misc/screen
> I've sent this to the maintainer some time ago, but have not heard > from him since, so now posting here : no > I've been using misc/screen for quite some time now, always with a > setgid utmp binary. This enables me, amongst other things, to talk(1) > to other users from within a screen session. I find it a handy > addition, so I made it into a flavor, perhaps it could be the default > setting with a 'no-setgid'-flavor, but
breakage (macppc)
A lot of these are generic and should be fixed asap. 9libs-1.0p3 totally busted wrt varargs, etc gcc-4.0.20050804powerpc target not in configure mrtg-2.12.2 gd breakage nagios-web-2.0b4cgi files not in fake area (shouldn't be looked for there?) nhc98-1.16 run-time crash ocamlduce-3.08.4pl3 seems like no config for powerpc octave-2.0.16 ancient C++? p5-GD-1.41p1gd breakage symon-2.71 missing many libs at linking stage xmame+xmess-0.100p1-x11 fake/usr/local/bin/xmame.x11: No such file or directory ?? xxdiff-3.1 ?? old
Re: bin_packages
> > > I've been trying to get BIN_PACKAGES to work by putting > > > "BIN_PACKAGES=Yes" in mk.conf, by exporting it to my environment and > > > by running "BIN_PACKAGES=Yes make install" to install a port. It's > > > not working. > > > > Is the workdir still present? You'll also want BULK=Yes and > > TRUST_PACKAGES=Yes most likely. > > And, so, where do these settings go? My environment? mk.conf? either, mk.conf is good permanently...
Re: bin_packages
> > > building a port tries to pkg_add any prerequisites before building them. > > > > this is already possible, see BIN_PACKAGES in bsd.port.mk(5). > > I've been trying to get BIN_PACKAGES to work by putting > "BIN_PACKAGES=Yes" in mk.conf, by exporting it to my environment and > by running "BIN_PACKAGES=Yes make install" to install a port. It's > not working. Is the workdir still present? You'll also want BULK=Yes and TRUST_PACKAGES=Yes most likely.
Re: Patch to fix xuvmstat port with 16bit display depth.
> I was getting failures to run xuvmstat on all my 3.7 and latest 3.8
> snapshots.
..
can you test this?
updates to latest version which includes the fix (with a little hack)
Index: Makefile
===
RCS file: /cvs/ports/sysutils/xuvmstat/Makefile,v
retrieving revision 1.7
diff -u -r1.7 Makefile
--- Makefile20 Dec 2004 10:35:37 - 1.7
+++ Makefile11 Oct 2005 22:52:53 -
@@ -2,7 +2,7 @@
COMMENT= "graphical display for the current uvm status"
-PKGNAME= xuvmstat-20010220
+PKGNAME= xuvmstat-20050909
DISTNAME= ${PKGNAME:S/-//}
CATEGORIES= sysutils x11
Index: distinfo
===
RCS file: /cvs/ports/sysutils/xuvmstat/distinfo,v
retrieving revision 1.2
diff -u -r1.2 distinfo
--- distinfo5 Jan 2005 17:29:42 - 1.2
+++ distinfo11 Oct 2005 22:52:59 -
@@ -1,4 +1,4 @@
-MD5 (xuvmstat20010220.tar.gz) = 85f90d23b4333898face3303d2b8e0f1
-RMD160 (xuvmstat20010220.tar.gz) = af17b79278144d267d87281122c99b0a2e53fc0c
-SHA1 (xuvmstat20010220.tar.gz) = bc9974355212bb4d0b831f5c755b0de6c2cf5968
-SIZE (xuvmstat20010220.tar.gz) = 7513
+MD5 (xuvmstat20050909.tar.gz) = b18610521da9d27ee85243d4301e1144
+RMD160 (xuvmstat20050909.tar.gz) = 6400ee7e396c410bf22ef9673b27b909f2a29a68
+SHA1 (xuvmstat20050909.tar.gz) = b8118b1b11c260683ff14fe2200e9ee584f6b7c5
+SIZE (xuvmstat20050909.tar.gz) = 7661
Index: patches/patch-xuvmstat_c
===
RCS file: /cvs/ports/sysutils/xuvmstat/patches/patch-xuvmstat_c,v
retrieving revision 1.2
diff -u -r1.2 patch-xuvmstat_c
--- patches/patch-xuvmstat_c29 Aug 2002 01:58:57 - 1.2
+++ patches/patch-xuvmstat_c11 Oct 2005 22:55:38 -
@@ -1,6 +1,6 @@
$OpenBSD: patch-xuvmstat_c,v 1.2 2002/08/29 01:58:57 wcobb Exp $
xuvmstat.c.origTue Feb 20 10:40:49 2001
-+++ xuvmstat.c Wed Aug 28 00:18:02 2002
+--- xuvmstat.c.origFri Sep 9 07:38:48 2005
xuvmstat.c Tue Oct 11 16:55:32 2005
@@ -24,6 +24,7 @@
* xuvmstat.c
*/
@@ -45,3 +45,19 @@
}
/*
+@@ -214,6 +215,7 @@ int was_timeout;
+ vals, colors, white);
+ }
+
++#ifdef notyet
+ y += 8;
+ {
+ static char *names[] = { "file", "anon", "exec", "free", "kernel" };
+@@ -237,6 +239,7 @@ int was_timeout;
+ y = draw_barbox(xdpy, win, gc, fnt_fixed, 5, 295, y, 5, cexp.npages,
names,
+ vals, colors, white);
+ }
++#endif
+
+ y += 8;
+
Re: new opendocman updated
> And how is that any different from say plump3p0, if it ever existed? > Should one really change the package name from the distro name to make > it harder to tell what version is installed? Oh that's the whole idea by > adding the p0 so it is an indicator of ports patch level. So if I remove > the p3 from the name then I'm indicating a wrong version number, maybe > and in the case of the ficticous plump3, now i'm not even indicating the > actual program at all. plump0.. Nope, your second example is wrong, as it would not be a problem. Read packages-specs(7) to understand this and comply to it...
