Re: UPDATE: www/moinmoin
"Federico G. Schwindt" writes:
> Update to 1.9.7.
> For details see http://hg.moinmo.in/moin/1.9/file/1.9.7/docs/CHANGES.
> While here simplify the Makefile somewhat.
> Comments? OK?
Basic testing shows no issue so far. ok jca@
Please see below.
> f.-
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/www/moinmoin/Makefile,v
> retrieving revision 1.29
> diff -u -p -r1.29 Makefile
> --- Makefile 18 May 2013 05:54:52 - 1.29
> +++ Makefile 21 Sep 2013 00:43:17 -
> @@ -2,7 +2,7 @@
>
> COMMENT =wiki engine written in python
>
> -MODPY_EGG_VERSION = 1.9.6
> +MODPY_EGG_VERSION = 1.9.7
> DISTNAME = moin-${MODPY_EGG_VERSION}
> PKGNAME =moin${DISTNAME}
>
> @@ -20,9 +20,8 @@ MODULES = lang/python
>
> NO_TEST =Yes
>
> -post-configure:
> - @cd ${WRKSRC}/wiki/server && perl -pi -e \
> - 's,/usr/bin/env python|/usr/bin/python,${MODPY_BIN},g' \
> +pre-configure:
> + @cd ${WRKSRC}/wiki/server && ${MODPY_BIN_ADJ} \
> moin moin.ajp moin.cgi moin.fcgi moin.scgi test.wsgi
Or
MODPY_ADJ_FILES = wiki/server/moin* wiki/server/test.wsgi
> post-install:
[...]
--
jca | PGP: 0x06A11494 / 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494
Re: UPDATE: boswars 2.7
On Sat, Sep 14, 2013 at 11:27:01PM -0400, Brad Smith wrote:
> Here is an update to boswars 2.7.
>
> OK?
Added the missing patches directory and its associated files.
Index: Makefile
===
RCS file: /home/cvs/ports/games/boswars/Makefile,v
retrieving revision 1.20
diff -u -p -r1.20 Makefile
--- Makefile3 Jun 2013 02:46:57 - 1.20
+++ Makefile17 Sep 2013 22:09:00 -
@@ -2,25 +2,25 @@
COMMENT= real-time strategy game
-V= 2.6.1
+V= 2.7
DISTNAME= boswars-${V}-src
PKGNAME= boswars-${V}
-REVISION= 4
CATEGORIES=games x11
+MASTER_SITES= http://www.boswars.org/dist/releases/
HOMEPAGE= http://www.boswars.org/
# GPLv2
PERMIT_PACKAGE_CDROM= Yes
-MASTER_SITES= http://www.boswars.org/dist/releases/
-
WANTLIB += GL SDL X11 c m ogg png pthread stdc++ theora vorbis z
WANTLIB += ${MODLUA_WANTLIB}
MODULES= devel/scons \
lang/lua
-MODSCONS_FLAGS=opengl=1
+MODSCONS_FLAGS=CPPPATH="${LOCALBASE}/include ${X11BASE}/include" \
+ opengl=1
+
BUILD_DEPENDS= devel/sdl-image
LIB_DEPENDS= devel/sdl \
multimedia/libtheora \
@@ -30,16 +30,17 @@ LIB_DEPENDS=devel/sdl \
NO_TEST= Yes
-DATA_DIR= campaigns graphics intro maps languages scripts sounds units
+DATA_DIR= campaigns graphics intro languages maps patches scripts sounds
units
pre-configure:
@${SUBST_CMD} ${WRKSRC}/SConstruct \
${WRKSRC}/engine/include/stratagus.h
do-install:
- ${INSTALL_PROGRAM} ${WRKSRC}/boswars ${PREFIX}/bin
${INSTALL_DATA_DIR} ${PREFIX}/share/boswars
${INSTALL_DATA_DIR} ${PREFIX}/share/doc/boswars/html/scripts
+ ${INSTALL_PROGRAM} ${WRKSRC}/build/boswars-release \
+ ${PREFIX}/bin/boswars
${INSTALL_DATA} ${WRKSRC}/doc/*.html ${PREFIX}/share/doc/boswars/html
${INSTALL_DATA} ${WRKSRC}/doc/scripts/{*.html,*.py}
${PREFIX}/share/doc/boswars/html/scripts
.for i in ${DATA_DIR}
Index: distinfo
===
RCS file: /home/cvs/ports/games/boswars/distinfo,v
retrieving revision 1.6
diff -u -p -r1.6 distinfo
--- distinfo12 May 2011 05:43:04 - 1.6
+++ distinfo15 Sep 2013 01:43:32 -
@@ -1,5 +1,2 @@
-MD5 (boswars-2.6.1-src.tar.gz) = fw/PRA6NdlxITwkHT5k7QA==
-RMD160 (boswars-2.6.1-src.tar.gz) = 98QbPJJ20hqrGek68N6FFkbcS6w=
-SHA1 (boswars-2.6.1-src.tar.gz) = SkggZObCLCilGavkhhiHWVuZeC0=
-SHA256 (boswars-2.6.1-src.tar.gz) =
YAMwdpK96ZE/a1wie/NR5D4z1E/6qxmPDQZ36P74YxU=
-SIZE (boswars-2.6.1-src.tar.gz) = 64708620
+SHA256 (boswars-2.7-src.tar.gz) = 3DcY9THp6kE8834TM7YqTF5p8UBVAtnFm55CRjUTXj4=
+SIZE (boswars-2.7-src.tar.gz) = 77280735
Index: patches/patch-SConstruct
===
RCS file: /home/cvs/ports/games/boswars/patches/patch-SConstruct,v
retrieving revision 1.6
diff -u -p -r1.6 patch-SConstruct
--- patches/patch-SConstruct10 Jul 2012 15:22:45 - 1.6
+++ patches/patch-SConstruct15 Sep 2013 01:47:23 -
@@ -1,6 +1,6 @@
$OpenBSD: patch-SConstruct,v 1.6 2012/07/10 15:22:45 jasper Exp $
SConstruct.origSun Apr 18 20:04:54 2010
-+++ SConstruct Mon Jul 9 19:37:51 2012
+--- SConstruct.origSun Jun 2 08:41:11 2013
SConstruct Sat Sep 14 21:46:08 2013
@@ -32,12 +32,12 @@ SConsignFile()
def DefineOptions(filename, args):
@@ -40,7 +40,7 @@ $OpenBSD: patch-SConstruct,v 1.6 2012/07
opengl['darwin'] = {
@@ -155,6 +162,8 @@ def CheckOpenGL(env, conf):
else:
- if sys.platform[:5] == 'linux':
+ if sys.platform[:5] == 'linux' or sys.platform.startswith('gnukfreebsd'):
platform = 'linux'
+ if sys.platform[:7] == 'openbsd':
+platform = 'openbsd'
Index: pkg/PLIST
===
RCS file: /home/cvs/ports/games/boswars/pkg/PLIST,v
retrieving revision 1.6
diff -u -p -r1.6 PLIST
--- pkg/PLIST 12 May 2011 05:43:04 - 1.6
+++ pkg/PLIST 17 Sep 2013 22:47:21 -
@@ -2,10 +2,70 @@
@bin bin/boswars
share/boswars/
share/boswars/campaigns/
+share/boswars/campaigns/conquest/
+share/boswars/campaigns/conquest/01/
+share/boswars/campaigns/conquest/01/presentation.smp
+share/boswars/campaigns/conquest/01/setup.sms
+share/boswars/campaigns/conquest/01/terrain.lua
+share/boswars/campaigns/conquest/01/triggers.lua
+share/boswars/campaigns/conquest/campaign.lua
+share/boswars/campaigns/conquest/conquest.png
+share/boswars/campaigns/islands/
+share/boswars/campaigns/islands/README&FAQ.txt
+share/boswars/campaigns/islands/campaign.lua
+share/boswars/campaigns/islands/crescents.png
+share/boswars/campaigns/islands/level01.smp
+share/boswars/campaigns/islands/level01.sms
+share/boswars/campaigns/islands/level02.smp
+share/boswars/campaigns/islands/level02.sms
+share/boswars/campaigns/isla
Re: UPDATE: boswars 2.7
On 17/09/13 1:10 AM, Anthony J. Bentley wrote: Brad Smith writes: Here is an update to boswars 2.7. OK? See how the background is all dark? You need to install the terrain patches directory. This will probably also fix the segfault that happens when exiting boswars from within a match. I don't see anything that looks unusual but all I am using is single player so far. I have not seen any crashing so far. By match do you mean multi player? -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
UPDATE: www/moinmoin
Update to 1.9.7.
For details see http://hg.moinmo.in/moin/1.9/file/1.9.7/docs/CHANGES.
While here simplify the Makefile somewhat.
Comments? OK?
f.-
Index: Makefile
===
RCS file: /cvs/ports/www/moinmoin/Makefile,v
retrieving revision 1.29
diff -u -p -r1.29 Makefile
--- Makefile18 May 2013 05:54:52 - 1.29
+++ Makefile21 Sep 2013 00:43:17 -
@@ -2,7 +2,7 @@
COMMENT = wiki engine written in python
-MODPY_EGG_VERSION = 1.9.6
+MODPY_EGG_VERSION = 1.9.7
DISTNAME = moin-${MODPY_EGG_VERSION}
PKGNAME = moin${DISTNAME}
@@ -20,9 +20,8 @@ MODULES = lang/python
NO_TEST = Yes
-post-configure:
- @cd ${WRKSRC}/wiki/server && perl -pi -e \
- 's,/usr/bin/env python|/usr/bin/python,${MODPY_BIN},g' \
+pre-configure:
+ @cd ${WRKSRC}/wiki/server && ${MODPY_BIN_ADJ} \
moin moin.ajp moin.cgi moin.fcgi moin.scgi test.wsgi
post-install:
Index: distinfo
===
RCS file: /cvs/ports/www/moinmoin/distinfo,v
retrieving revision 1.16
diff -u -p -r1.16 distinfo
--- distinfo9 Jan 2013 11:56:34 - 1.16
+++ distinfo21 Sep 2013 00:43:17 -
@@ -1,2 +1,2 @@
-SHA256 (moin-1.9.6.tar.gz) = gW8EVICOir3ETpg57QiAK+p4wXS9vXK5ZExy/OiR9vY=
-SIZE (moin-1.9.6.tar.gz) = 36754215
+SHA256 (moin-1.9.7.tar.gz) = 9LobXJVr2W0qYeJ+aNKXqmPRr7yA1XQOE53N8K/7TbU=
+SIZE (moin-1.9.7.tar.gz) = 36911772
Index: pkg/PLIST
===
RCS file: /cvs/ports/www/moinmoin/pkg/PLIST,v
retrieving revision 1.15
diff -u -p -r1.15 PLIST
--- pkg/PLIST 9 Jan 2013 11:56:34 - 1.15
+++ pkg/PLIST 21 Sep 2013 00:43:19 -
@@ -494,6 +494,8 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/MoinMoin/script/account/disable.pyc
lib/python${MODPY_VERSION}/site-packages/MoinMoin/script/account/homepage.py
lib/python${MODPY_VERSION}/site-packages/MoinMoin/script/account/homepage.pyc
+lib/python${MODPY_VERSION}/site-packages/MoinMoin/script/account/inactive.py
+lib/python${MODPY_VERSION}/site-packages/MoinMoin/script/account/inactive.pyc
lib/python${MODPY_VERSION}/site-packages/MoinMoin/script/account/resetpw.py
lib/python${MODPY_VERSION}/site-packages/MoinMoin/script/account/resetpw.pyc
lib/python${MODPY_VERSION}/site-packages/MoinMoin/script/cli/
@@ -626,6 +628,8 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/MoinMoin/script/migration/1090500.pyc
lib/python${MODPY_VERSION}/site-packages/MoinMoin/script/migration/1090600.py
lib/python${MODPY_VERSION}/site-packages/MoinMoin/script/migration/1090600.pyc
+lib/python${MODPY_VERSION}/site-packages/MoinMoin/script/migration/1090700.py
+lib/python${MODPY_VERSION}/site-packages/MoinMoin/script/migration/1090700.pyc
lib/python${MODPY_VERSION}/site-packages/MoinMoin/script/migration/__init__.py
lib/python${MODPY_VERSION}/site-packages/MoinMoin/script/migration/__init__.pyc
lib/python${MODPY_VERSION}/site-packages/MoinMoin/script/migration/_conv160.py
@@ -813,6 +817,111 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/MoinMoin/support/parsedatetime/parsedatetime.pyc
lib/python${MODPY_VERSION}/site-packages/MoinMoin/support/parsedatetime/parsedatetime_consts.py
lib/python${MODPY_VERSION}/site-packages/MoinMoin/support/parsedatetime/parsedatetime_consts.pyc
+lib/python${MODPY_VERSION}/site-packages/MoinMoin/support/passlib/
+lib/python${MODPY_VERSION}/site-packages/MoinMoin/support/passlib/__init__.py
+lib/python${MODPY_VERSION}/site-packages/MoinMoin/support/passlib/__init__.pyc
+lib/python${MODPY_VERSION}/site-packages/MoinMoin/support/passlib/_setup/
+lib/python${MODPY_VERSION}/site-packages/MoinMoin/support/passlib/_setup/__init__.py
+lib/python${MODPY_VERSION}/site-packages/MoinMoin/support/passlib/_setup/__init__.pyc
+lib/python${MODPY_VERSION}/site-packages/MoinMoin/support/passlib/_setup/docdist.py
+lib/python${MODPY_VERSION}/site-packages/MoinMoin/support/passlib/_setup/docdist.pyc
+lib/python${MODPY_VERSION}/site-packages/MoinMoin/support/passlib/_setup/stamp.py
+lib/python${MODPY_VERSION}/site-packages/MoinMoin/support/passlib/_setup/stamp.pyc
+lib/python${MODPY_VERSION}/site-packages/MoinMoin/support/passlib/apache.py
+lib/python${MODPY_VERSION}/site-packages/MoinMoin/support/passlib/apache.pyc
+lib/python${MODPY_VERSION}/site-packages/MoinMoin/support/passlib/apps.py
+lib/python${MODPY_VERSION}/site-packages/MoinMoin/support/passlib/apps.pyc
+lib/python${MODPY_VERSION}/site-packages/MoinMoin/support/passlib/context.py
+lib/python${MODPY_VERSION}/site-packages/MoinMoin/support/passlib/context.pyc
+lib/python${MODPY_VERSION}/site-packages/MoinMoin/support/passlib/exc.py
+lib/python${MODPY_VERSION}/site-packages/MoinMoin/support/passlib/exc.pyc
+lib/python${MODPY_VERSION}/site-packages/MoinMoin/support/passli
NEW: x11/radeontop (v5)
Another one: - add sysutils to CATEGORIES, based on comments from Dmitrij radeontop-0.6.tar.gz Description: application/tar-gz
Re: NEW: x11/radeontop (v4)
On 09/21/13 01:09, Kyle R W Milz wrote: Another one, - Nuked everything generating version.h in Makefile - Include pre generated version.h in the form of a patch that creates a new file (is this OK?) - Changed install permissions of binary from 755 -> 555 after observing the owner write bit is not set usually in sbin/ directory - Changed install permissions of manpage from 644 -> 444 for same reason Because of the first 2 changes above the double compiling issue goes away. Works for me on amd64 with radeon RV710. Thanks for the work in the port.
Re: NEW: x11/radeontop (v2)
On 09/21/13 01:07, Dmitrij D. Czarkoff wrote: On Fri, Sep 20, 2013 at 11:46:27PM +0100, Stuart Henderson wrote: It's probably because of the $(verh) stuff. At least it shouldn't be so, as $(verh) resolves to version.h file which appears to be successfully generated. To my understanding, gmake wouldn't exit with 0 status on "gmake all" during "make build" if "all" target's dependency - $(verh) - wasn't satisfied. Looks like it just doesn't like having "install" target depend on "all". Trim "all" from the "install" target. It does the trick.
Re: NEW: x11/radeontop (v2)
On 09/20/13 23:48, Kyle R W Milz wrote:
On Fri, Sep 20, 2013 at 09:30:21PM +0200, Juan Francisco Cantero Hurtado wrote:
On Fri, Sep 20, 2013 at 09:33:27AM -0600, Kyle R W Milz wrote:
ports@,
Thanks everyone for the feedback, here is an update with changes made.
Things I'm wary about still:
- had to set DESTDIRNAME = / to `make package' properly, there's some
sort of weird double path thing going on if not
- this thing needs root to run, does it make sense to be in bin/ ?
"LDFLAGS += -Wl" in the patch is wrong. You're passing literally nothing
to the linker.
OK nuked the entire line.
Don't use DESTDIRNAME. The software reads PREFIX and DESTDIR, so it
concatenates both paths. You need to patch the install part of the
makefile of radeontop.
Not sure what you're trying to say here but I've removed the DESTDIRNAME
from the port Makefile and replaced ${PREFIX} in the radeontop Makefile
with ${LOCALBASE} after reading in bsd.port.mk that $PREFIX is usually
set to $LOCALBASE anyways.
I was speaking about
/usr/ports/pobj/radeontop-0.6/fake-amd64//usr/ports/pobj/radeontop-0.6/fake-amd64/usr/local/bin/radeontop.
When I said "The software" I was speaking about the makefile of
radeontop. Sometimes my wording is terrible.
The idea of jca@ with a void DESTDIR within FAKE_FLAGS is the best.
It'll simplify your work as maintainer in the future.
You also didn't clarify whether or not this should be in bin/ or sbin/
so I moved it back to sbin/ because like I said before this thing needs
root to run (mmap /dev/mem).
Sorry for not responding directly to your questions, I didn't receive
your mails. Apparently openbsd.org and my mail provider are fighting to
death this week. Each mail sent take two hours to arrive to openbsd.org.
I prefer "bin" but this is subjetive :)
NEW: x11/radeontop (v4)
Another one, - Nuked everything generating version.h in Makefile - Include pre generated version.h in the form of a patch that creates a new file (is this OK?) - Changed install permissions of binary from 755 -> 555 after observing the owner write bit is not set usually in sbin/ directory - Changed install permissions of manpage from 644 -> 444 for same reason Because of the first 2 changes above the double compiling issue goes away. radeontop-0.6.tar.gz Description: application/tar-gz
Re: NEW: x11/radeontop (v2)
On Fri, Sep 20, 2013 at 11:46:27PM +0100, Stuart Henderson wrote: > It's probably because of the $(verh) stuff. At least it shouldn't be so, as $(verh) resolves to version.h file which appears to be successfully generated. To my understanding, gmake wouldn't exit with 0 status on "gmake all" during "make build" if "all" target's dependency - $(verh) - wasn't satisfied. Looks like it just doesn't like having "install" target depend on "all". -- Dmitrij D. Czarkoff
Re: NEW: x11/radeontop (v2)
On Sat, Sep 21, 2013 at 12:15:07AM +0200, J??r??mie Courr??ges-Anglas wrote:
> Kyle R W Milz writes:
< snip >
> Another option is to just set this:
>
> FAKE_FLAGS = DESTDIR=
>
> in the port Makefile.
Cool thanks.
> > Not sure what you're trying to say here but I've removed the DESTDIRNAME
> > from the port Makefile and replaced ${PREFIX} in the radeontop Makefile
> > with ${LOCALBASE} after reading in bsd.port.mk that $PREFIX is usually
> > set to $LOCALBASE anyways.
>
> DESTDIRNAME is not supposed to be used like this. You got it to do what
> you needed by chance.
Yeah figured as much, I was just fishing for solutions really.
> > You also didn't clarify whether or not this should be in bin/ or sbin/
> > so I moved it back to sbin/ because like I said before this thing needs
> > root to run (mmap /dev/mem).
>
> I see no reason to go against upstream on this issue.
>
> Is that port supposed to be compiled twice, at build and fake time?
I noticed that too and no, I don't think so.
My knowledge of Make is terrible at best. I think `all' is the default
rule and so it gets invoked during build time, and then at when faking
the install rule is invoked, which depends on `all' again. But I thought
Make was supposed to be smart and not rebuild if none of the
dependencies have changed.
At any rate, this Makefile sucks.
> --
> jca | PGP: 0x06A11494 / 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494
>
Re: NEW: x11/radeontop (v2)
On 2013/09/20 16:45, Kyle R W Milz wrote: > On Sat, Sep 21, 2013 at 12:15:07AM +0200, J??r??mie Courr??ges-Anglas wrote: > > < big snip > > > > Is that port supposed to be compiled twice, at build and fake time? > > OK I think I got something here. Untarring reveals that there is no > include/version.h but there is a getver.sh shell script that is > called while building to generate it. However getver.sh depends on > the git repository to define the version number (through git describe) > but the git repo is not included in the tarball. This thing is broken > as hell. Looks to me like it is meant to be generated when a release is rolled with 'make dist' and then there is a fallback for git checkouts which don't have that file.
Re: NEW: x11/radeontop (v2)
On 2013/09/20 16:29, Kyle R W Milz wrote: > My knowledge of Make is terrible at best. I think `all' is the default > rule and so it gets invoked during build time, and then at when faking > the install rule is invoked, which depends on `all' again. But I thought > Make was supposed to be smart and not rebuild if none of the > dependencies have changed. It's probably because of the $(verh) stuff. Please patch things so it doesn't use getver.sh to run git, nicest way would probably be to create version.h manually with the right version number in it.
Re: NEW: x11/radeontop (v2)
On Sat, Sep 21, 2013 at 12:15:07AM +0200, J??r??mie Courr??ges-Anglas wrote: < big snip > > Is that port supposed to be compiled twice, at build and fake time? OK I think I got something here. Untarring reveals that there is no include/version.h but there is a getver.sh shell script that is called while building to generate it. However getver.sh depends on the git repository to define the version number (through git describe) but the git repo is not included in the tarball. This thing is broken as hell. > -- > jca | PGP: 0x06A11494 / 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494 >
Re: Recent version of gcc for amd64?
On Fri, Sep 20, 2013 at 06:01:54PM -0400, John Carr wrote: > Ports worked. I needed OPENBSD_5_4 instead of the 5.3 version I had > checked out. > > Applying the ports patches manually did not work. I needed the ports > build process. Something in the rest of the ports environment is > needed. Maybe CONFIGURE_ARGS in the ports Makefile sets an option that > avoids the relocation bug. I'll have to investigate more another day. amd64... pretty sure that's the config.guess stuff we have that you missed.
Re: NEW: x11/radeontop (v2)
Kyle R W Milz writes:
> On Fri, Sep 20, 2013 at 09:30:21PM +0200, Juan Francisco Cantero Hurtado
> wrote:
>> On Fri, Sep 20, 2013 at 09:33:27AM -0600, Kyle R W Milz wrote:
>> > ports@,
>> >
>> > Thanks everyone for the feedback, here is an update with changes made.
>> >
>> > Things I'm wary about still:
>> >
>> > - had to set DESTDIRNAME = / to `make package' properly, there's some
>> > sort of weird double path thing going on if not
>> >
>> > - this thing needs root to run, does it make sense to be in bin/ ?
>>
>> "LDFLAGS += -Wl" in the patch is wrong. You're passing literally nothing
>> to the linker.
>
> OK nuked the entire line.
>
>> Don't use DESTDIRNAME. The software reads PREFIX and DESTDIR, so it
>> concatenates both paths. You need to patch the install part of the
>> makefile of radeontop.
Another option is to just set this:
FAKE_FLAGS = DESTDIR=
in the port Makefile.
> Not sure what you're trying to say here but I've removed the DESTDIRNAME
> from the port Makefile and replaced ${PREFIX} in the radeontop Makefile
> with ${LOCALBASE} after reading in bsd.port.mk that $PREFIX is usually
> set to $LOCALBASE anyways.
DESTDIRNAME is not supposed to be used like this. You got it to do what
you needed by chance.
> You also didn't clarify whether or not this should be in bin/ or sbin/
> so I moved it back to sbin/ because like I said before this thing needs
> root to run (mmap /dev/mem).
I see no reason to go against upstream on this issue.
Is that port supposed to be compiled twice, at build and fake time?
--
jca | PGP: 0x06A11494 / 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494
NEW: giflib
Quick history: giflib was changed to libungif when the patent became a problem, but more recently this has expired and so development has moved back to giflib. Here's a port for giflib. OK to import it (unlinked for now)? I have a diff for the rest of the tree to switch across (Makefile changes obviously, but also various patches are needed as the API has changed for thread safety) that I'll send separately. giflib.tgz Description: application/tar-gz
Re: Recent version of gcc for amd64?
> > Is it possible to build gcc 4.8 / 4.9 (development) for OpenBSD 5.3 amd64? > > > > I tried and failed. The first stage compiler fails building libgomp > > because of a relocation problem in a DWARF frame descriptor. > > > > "relocation R_X86_64_32 can not be used when making a shared object" > > > > I am not explicitly making a shared object but who knows what's going on > > internally. > > > > Thinking that the old GNU assembler might be at fault I fetched a recent > > binutils. Compiling that fails because the compiler gives errors about > > use of the "struct hack" (which is now blessed by standards, but still > > dangerous). I beat on the code to avoid the warning. The next obstacle > > is x86-64 openbsd is not a supported target for the linker. I changed > > the target script to treat it like netbsd. And I don't know what error > > will come next, but I expect to find one. And I don't know if old binutils > > is really the problem? > > > > Any advice? > > > > gcc 4.8 is in packages in -current and the upcoming release OpenBSD 5.4, > if you want to try and build it on 5.3 then fetching the port from the > OPENBSD_5_4 branch is probably your best starting point, you may need > to disable ada by removing amd64 from the ONLY_FOR_ARCHS-ada line to > avoid the binary bootstrap which is required). > > For 4.9 your best starting point is probably to get 4.8.1 building and > then copy/modify the port to point at 4.9 instead. Ports worked. I needed OPENBSD_5_4 instead of the 5.3 version I had checked out. Applying the ports patches manually did not work. I needed the ports build process. Something in the rest of the ports environment is needed. Maybe CONFIGURE_ARGS in the ports Makefile sets an option that avoids the relocation bug. I'll have to investigate more another day.
NEW: x11/radeontop (v3)
Here is another spin of this port, with changes requested by Juan:
- changed ${PREFIX} -> ${LOCALBASE} in radeontop Makefile
- nuked LDFLAGS in radeontop Makefile
- removed newline at end of file
- removed build dependency on asciidoc as the generated manpage comes
with the tarball
- tweaked pkg/DESRC and fixed some spelling errors
- install binary in sbin/
radeontop-0.6.tar.gz
Description: application/tar-gz
Re: NEW: x11/radeontop (v2)
On Fri, Sep 20, 2013 at 09:30:21PM +0200, Juan Francisco Cantero Hurtado wrote:
> On Fri, Sep 20, 2013 at 09:33:27AM -0600, Kyle R W Milz wrote:
> > ports@,
> >
> > Thanks everyone for the feedback, here is an update with changes made.
> >
> > Things I'm wary about still:
> >
> > - had to set DESTDIRNAME = / to `make package' properly, there's some
> > sort of weird double path thing going on if not
> >
> > - this thing needs root to run, does it make sense to be in bin/ ?
>
> "LDFLAGS += -Wl" in the patch is wrong. You're passing literally nothing
> to the linker.
OK nuked the entire line.
> Don't use DESTDIRNAME. The software reads PREFIX and DESTDIR, so it
> concatenates both paths. You need to patch the install part of the
> makefile of radeontop.
Not sure what you're trying to say here but I've removed the DESTDIRNAME
from the port Makefile and replaced ${PREFIX} in the radeontop Makefile
with ${LOCALBASE} after reading in bsd.port.mk that $PREFIX is usually
set to $LOCALBASE anyways.
You also didn't clarify whether or not this should be in bin/ or sbin/
so I moved it back to sbin/ because like I said before this thing needs
root to run (mmap /dev/mem).
> --
> Juan Francisco Cantero Hurtado http://juanfra.info
>
Re: CVS: cvs.openbsd.org: ports
Antoine Jacoutot writes: [...] >> > while there, drop run dependency on zoo; clamav actually switched from zoo >> > to unzoo (which we don't have in ports) in 0.60(!) so this was doing >> > nothing. >> > >> >> Here's a barely tested port if archivers/unzoo is wanted. Updated tarball; CPPFLAGS were not enough, I had to patch the source. I added a note in pkg/DESCR about the missing support for LZD (Lempel-Ziv "Default"?) compression scheme that isn't implemented by this program. The "funny" thing is that this scheme is the default used by archivers/zoo... > Having zoo support would only enforce our masturbating monkeys reputation. Are you saying that it would be a good thing? :) -- jca | PGP: 0x06A11494 / 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494 unzoo.tgz Description: Binary data
Re: Recent version of gcc for amd64?
On 2013/09/20 12:40, John Carr wrote: > > Is it possible to build gcc 4.8 / 4.9 (development) for OpenBSD 5.3 amd64? > > I tried and failed. The first stage compiler fails building libgomp > because of a relocation problem in a DWARF frame descriptor. > > "relocation R_X86_64_32 can not be used when making a shared object" > > I am not explicitly making a shared object but who knows what's going on > internally. > > Thinking that the old GNU assembler might be at fault I fetched a recent > binutils. Compiling that fails because the compiler gives errors about > use of the "struct hack" (which is now blessed by standards, but still > dangerous). I beat on the code to avoid the warning. The next obstacle > is x86-64 openbsd is not a supported target for the linker. I changed > the target script to treat it like netbsd. And I don't know what error > will come next, but I expect to find one. And I don't know if old binutils > is really the problem? > > Any advice? > gcc 4.8 is in packages in -current and the upcoming release OpenBSD 5.4, if you want to try and build it on 5.3 then fetching the port from the OPENBSD_5_4 branch is probably your best starting point, you may need to disable ada by removing amd64 from the ONLY_FOR_ARCHS-ada line to avoid the binary bootstrap which is required). For 4.9 your best starting point is probably to get 4.8.1 building and then copy/modify the port to point at 4.9 instead.
Re: NEW: x11/radeontop (v2)
On Fri, Sep 20, 2013 at 09:33:27AM -0600, Kyle R W Milz wrote: > ports@, > > Thanks everyone for the feedback, here is an update with changes made. > > Things I'm wary about still: > > - had to set DESTDIRNAME = / to `make package' properly, there's some > sort of weird double path thing going on if not > > - this thing needs root to run, does it make sense to be in bin/ ? "LDFLAGS += -Wl" in the patch is wrong. You're passing literally nothing to the linker. Don't use DESTDIRNAME. The software reads PREFIX and DESTDIR, so it concatenates both paths. You need to patch the install part of the makefile of radeontop. -- Juan Francisco Cantero Hurtado http://juanfra.info
UPDATE: sdlmame and sdlmess 0.149u1 => 0.150
Hi ports --
After a really short u cycle, mame's version number has been incremented.
These 2 patches (one for mame, one for mess) work for me on amd64 -
could someone with a fast i386 take these for a spin?
~Brian
Index: Makefile
===
RCS file: /cvs/ports/emulators/sdlmame/Makefile,v
retrieving revision 1.35
diff -u -p -u -p -r1.35 Makefile
--- Makefile 7 Aug 2013 03:40:24 - 1.35
+++ Makefile 20 Sep 2013 18:28:09 -
@@ -8,10 +8,10 @@ MULTI_PACKAGES = -main -tools
COMMENT-main = emulates a massive variety of arcades machines
COMMENT-tools = tools to manipulate MAME/MESS roms and disk images
-V = 149
+V = 150
DISTNAME = mame0${V}s
-PKGNAME-main = sdlmame-0.${V}pl1
-PKGNAME-tools = sdlmame-tools-0.${V}pl1
+PKGNAME-main = sdlmame-0.${V}
+PKGNAME-tools = sdlmame-tools-0.${V}
CATEGORIES = emulators games
@@ -40,8 +40,7 @@ DIST_SUBDIR = mame
# PATCHFILES doesn't work for .zip
DISTFILES = ${DISTNAME}${EXTRACT_SUFX} \
- 0${V}u1_diff.zip:0 \
- history${V}a.zip:1
+ history${V}.zip:1
MODULES = devel/gettext \
lang/python
@@ -72,9 +71,9 @@ post-extract:
@${UNZIP} -oq ${WRKDIR}/mame.zip -d ${WRKSRC}
pre-patch:
-.for v in 1
- ${PATCH} ${PATCH_DIST_ARGS} < ${WRKDIR}/0${V}u${v}.diff
-.endfor
+#.for v in 1
+# ${PATCH} ${PATCH_DIST_ARGS} < ${WRKDIR}/0${V}u${v}.diff
+#.endfor
@perl -pi -e 's|\r\n|\n|g' ${WRKDIST}/makefile \
${WRKDIST}/src/emu/fileio.h \
${WRKDIST}/src/emu/machine/netlist.h \
Index: distinfo
===
RCS file: /cvs/ports/emulators/sdlmame/distinfo,v
retrieving revision 1.16
diff -u -p -u -p -r1.16 distinfo
--- distinfo 7 Aug 2013 03:40:24 - 1.16
+++ distinfo 20 Sep 2013 18:28:09 -
@@ -1,6 +1,4 @@
-SHA256 (mame/0149u1_diff.zip) = O3RqVhysIRjNSR1AeNSzwHqDRrRabWzWYv0bAFmzmoA=
-SHA256 (mame/history149a.zip) = 8kqg5Th7Fn93ctshZ08otLERsLfiMiqAJggOUybreLs=
-SHA256 (mame/mame0149s.zip) = DkG1dzvqIX08oEACkDrF71aeb1tnwFxySW0s15k7Cms=
-SIZE (mame/0149u1_diff.zip) = 2792736
-SIZE (mame/history149a.zip) = 4680179
-SIZE (mame/mame0149s.zip) = 35160585
+SHA256 (mame/history150.zip) = fkBuNgkLRznCkPxFSJYMIEyNcBqT7uJ7YlqX8mH9XFE=
+SHA256 (mame/mame0150s.zip) = 5nKwM7qgAeGpCUmLbJIGxo0EVv2IPkEK1Q8aT0wiU/c=
+SIZE (mame/history150.zip) = 4694523
+SIZE (mame/mame0150s.zip) = 35999158
Index: patches/patch-makefile
===
RCS file: /cvs/ports/emulators/sdlmame/patches/patch-makefile,v
retrieving revision 1.6
diff -u -p -u -p -r1.6 patch-makefile
--- patches/patch-makefile 7 Aug 2013 03:40:25 - 1.6
+++ patches/patch-makefile 20 Sep 2013 18:28:10 -
@@ -1,7 +1,7 @@
$OpenBSD: patch-makefile,v 1.6 2013/08/07 03:40:25 bcallah Exp $
makefile.orig Tue Jun 11 09:47:45 2013
-+++ makefile Tue Jun 11 09:47:46 2013
-@@ -214,10 +214,10 @@ endif
+--- makefile.orig Fri Sep 20 12:15:22 2013
makefile Fri Sep 20 12:15:23 2013
+@@ -217,10 +217,10 @@ endif
# BIGENDIAN = 1
# uncomment next line to build expat as part of MAME build
@@ -14,7 +14,7 @@ $OpenBSD: patch-makefile,v 1.6 2013/08/0
# uncomment next line to build libflac as part of MAME build
BUILD_FLAC = 1
-@@ -318,7 +318,7 @@ endif
+@@ -330,7 +330,7 @@ endif
# compiler, linker and utilities
AR = @ar
@@ -23,7 +23,7 @@ $OpenBSD: patch-makefile,v 1.6 2013/08/0
LD = @g++
MD = -mkdir$(EXE)
RM = @rm -f
-@@ -367,7 +367,7 @@ NAME = $(TARGET)$(SUBTARGET)
+@@ -379,7 +379,7 @@ NAME = $(TARGET)$(SUBTARGET)
endif
# fullname is prefix+name+suffix+suffix64+suffixdebug
@@ -32,7 +32,7 @@ $OpenBSD: patch-makefile,v 1.6 2013/08/0
# add an EXE suffix to get the final emulator name
EMULATOR = $(FULLNAME)$(EXE)
-@@ -458,7 +458,7 @@ CPPONLYFLAGS =
+@@ -473,7 +473,7 @@ CPPONLYFLAGS =
# CFLAGS is defined based on C or C++ targets
# (remember, expansion only happens when used, so doing it here is ok)
@@ -41,7 +41,7 @@ $OpenBSD: patch-makefile,v 1.6 2013/08/0
# we compile C-only to C89 standard with GNU extensions
# we compile C++ code to C++98 standard with GNU extensions
-@@ -485,7 +485,7 @@ CCOMFLAGS += -pg
+@@ -506,7 +506,7 @@ CCOMFLAGS += -pg
endif
# add the optimization flag
Index: patches/patch-src_osd_sdl_sdl_mak
===
RCS file: /cvs/ports/emulators/sdlmame/patches/patch-src_osd_sdl_sdl_mak,v
retrieving revision 1.9
diff -u -p -u -p -r1.9 patch-src_osd_sdl_sdl_mak
--- patches/patch-src_osd_sdl_sdl_mak 7 Aug 2013 03:40:25 - 1.9
+++ patches/patch-src_osd_sdl_sdl_mak 20 Sep 2013 18:28:10 -
@@ -1,7 +1,7 @@
$OpenBSD: patch-src_osd_sdl_sdl_mak,v 1.9 2013/08/07 03:40:25 bcallah Exp $
src/osd/sdl/sdl.mak.orig Tue Jul 23 22:24:06 2013
-+++ src/osd/sdl/sdl.mak Tue Jul 23 22:24:06 2013
-@@ -712,9 +712,9 @@ LIBS += `pkg-config --libs gtk+-2.0` `pkg-config --lib
+--- src/osd/sdl/sdl.mak.orig Fri Sep 20 12:15:23 20
Re: NEW: x11/radeontop (v2)
On Fri, Sep 20, 2013 at 09:48:11AM -0700, Ryan Freeman wrote: > On Fri, Sep 20, 2013 at 09:33:27AM -0600, Kyle R W Milz wrote: > > ports@, > > > > Thanks everyone for the feedback, here is an update with changes made. > > > > Things I'm wary about still: > > > > - had to set DESTDIRNAME = / to `make package' properly, there's some > > sort of weird double path thing going on if not > > > > - this thing needs root to run, does it make sense to be in bin/ ? > > > gave this a (remote) test spin on my laptop and desktop via export > DISPLAY=localhost:0 and running glxgears while watching radeontop > in another tmux window; doesn't recognize the radeon in my laptop > though does run and show output for one of the fields. laptop > is i386 with x1400 (rv515 i think?) Yeah I think this is for >=R600 only. > desktop is amd64 and radeon hd3650; shows as RV635 in radeon top > and same 'test' as laptop with glxgears shows it updating all > fields and bar graphs dancing around. gonna run this while > playing a game at some point, might be interesting to see what > gets dimed to the top of usage during slow points to see where > bottlenecks are :) Yeah I tried it while running openarena on my HD4350 and it seemed to be working as well. > so in terms of it running and it not remotely crashing my machines > for me, OK rfreeman@. wait for OKs from the others that suggested > changes to port. ack. > -ryan >
Re: CVS: cvs.openbsd.org: ports
On Fri, Sep 20, 2013 at 06:45:13PM +0200, Jérémie Courrèges-Anglas wrote: > Stuart Henderson writes: > > > CVSROOT:/cvs > > Module name:ports > > Changes by: st...@cvs.openbsd.org 2013/09/20 09:23:03 > > > > Modified files: > > security/clamav: Makefile distinfo > > security/clamav/patches: patch-clamd_Makefile_in > > patch-database_Makefile_in > > patch-libclamav_Makefile_in > > patch-libclamav_mbox_c > > patch-libclamav_ole2_extract_c > > patch-libclamav_str_c > > patch-libclamav_vba_extract_c > > security/clamav/pkg: PLIST > > Added files: > > security/clamav/patches: patch-etc_clamd_conf_sample > > patch-etc_freshclam_conf_sample > > Removed files: > > security/clamav/patches: patch-etc-clamd_conf > > patch-etc-freshclam_conf > > patch-etc_Makefile_in > > > > Log message: > > update to clamav 0.98: > > > > - signature improvements, performance improvements, support for new file > > types including ISO9660, Flash, self-extracting 7z files > > > > - more configurable limits > > > > - callbacks added to API > > > > while there, drop run dependency on zoo; clamav actually switched from zoo > > to unzoo (which we don't have in ports) in 0.60(!) so this was doing > > nothing. > > > > Here's a barely tested port if archivers/unzoo is wanted. Having zoo support would only enforce our masturbating monkeys reputation. -- Antoine
Re: NEW: x11/radeontop (v2)
On Fri, Sep 20, 2013 at 09:33:27AM -0600, Kyle R W Milz wrote: > ports@, > > Thanks everyone for the feedback, here is an update with changes made. > > Things I'm wary about still: > > - had to set DESTDIRNAME = / to `make package' properly, there's some > sort of weird double path thing going on if not > > - this thing needs root to run, does it make sense to be in bin/ ? gave this a (remote) test spin on my laptop and desktop via export DISPLAY=localhost:0 and running glxgears while watching radeontop in another tmux window; doesn't recognize the radeon in my laptop though does run and show output for one of the fields. laptop is i386 with x1400 (rv515 i think?) desktop is amd64 and radeon hd3650; shows as RV635 in radeon top and same 'test' as laptop with glxgears shows it updating all fields and bar graphs dancing around. gonna run this while playing a game at some point, might be interesting to see what gets dimed to the top of usage during slow points to see where bottlenecks are :) so in terms of it running and it not remotely crashing my machines for me, OK rfreeman@. wait for OKs from the others that suggested changes to port. -ryan
Re: NEW: x11/radeontop (v2)
ports@, Thanks everyone for the feedback, here is an update with changes made. Things I'm wary about still: - had to set DESTDIRNAME = / to `make package' properly, there's some sort of weird double path thing going on if not - this thing needs root to run, does it make sense to be in bin/ ? radeontop-0.6.tar.gz Description: application/tar-gz
Re: CVS: cvs.openbsd.org: ports
Stuart Henderson writes: > CVSROOT: /cvs > Module name: ports > Changes by: st...@cvs.openbsd.org 2013/09/20 09:23:03 > > Modified files: > security/clamav: Makefile distinfo > security/clamav/patches: patch-clamd_Makefile_in >patch-database_Makefile_in >patch-libclamav_Makefile_in >patch-libclamav_mbox_c >patch-libclamav_ole2_extract_c >patch-libclamav_str_c >patch-libclamav_vba_extract_c > security/clamav/pkg: PLIST > Added files: > security/clamav/patches: patch-etc_clamd_conf_sample >patch-etc_freshclam_conf_sample > Removed files: > security/clamav/patches: patch-etc-clamd_conf >patch-etc-freshclam_conf >patch-etc_Makefile_in > > Log message: > update to clamav 0.98: > > - signature improvements, performance improvements, support for new file > types including ISO9660, Flash, self-extracting 7z files > > - more configurable limits > > - callbacks added to API > > while there, drop run dependency on zoo; clamav actually switched from zoo > to unzoo (which we don't have in ports) in 0.60(!) so this was doing nothing. > Here's a barely tested port if archivers/unzoo is wanted. -- jca | PGP: 0x06A11494 / 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494 unzoo.tgz Description: Binary data
Recent version of gcc for amd64?
Is it possible to build gcc 4.8 / 4.9 (development) for OpenBSD 5.3 amd64? I tried and failed. The first stage compiler fails building libgomp because of a relocation problem in a DWARF frame descriptor. "relocation R_X86_64_32 can not be used when making a shared object" I am not explicitly making a shared object but who knows what's going on internally. Thinking that the old GNU assembler might be at fault I fetched a recent binutils. Compiling that fails because the compiler gives errors about use of the "struct hack" (which is now blessed by standards, but still dangerous). I beat on the code to avoid the warning. The next obstacle is x86-64 openbsd is not a supported target for the linker. I changed the target script to treat it like netbsd. And I don't know what error will come next, but I expect to find one. And I don't know if old binutils is really the problem? Any advice?
Re: NEW: x11/radeontop
On Fri, Sep 20, 2013 at 01:56:07PM +0200, Juan Francisco Cantero Hurtado wrote:
> On Thu, Sep 19, 2013 at 04:19:34PM -0600, Kyle R W Milz wrote:
> > ports@,
> >
> > Attached is an attempt at a port for radeontop, a top like program
> > showing GPU utilization on radeon cards >=R600.
> >
> > It's quite the hack and I'm positive I'm doing some things wrong
> > including but not limited to
> >
> > 1) Getting tarball off of github and the name of the distfile itself
> > (v0.6)
> >
> > 2) Patching of the Makefile to link to libintl properly
> >
> > 3) Patching of the Makefile to install files properly
> >
> > If anyone could take a look and give feedback I would gladly appreciate.
>
> I've not tested the port but here are some comments.
>
> The patch is wrong:
> - Add CPPFLAGS and LDFLAGS to the Makefile of the port. Use "MAKE_ENV"
> to set the flags.
done
> - Use "${LOCALBASE}" instead of "/usr/local".
done
> - Why are you removing "DESTDIR"?
I was having difficulty during `make package', it kept wanting to
install to
/usr/ports/pobj/radeontop-0.6/fake-amd64//usr/ports/pobj/radeontop-0.6/fake-amd64/usr/local/*
which obviously is wrong.
Got around that with setting DESTDIRNAME = / this time around however
I'm unsure if this is the correct way. I think PREFIX might be getting
fucked up or something.
> - Trim LDFLAGS from the makefile of the software. We don't want extra
> optimizations. The same for "-Os".
ok I left -Wl in there but trimmed the rest, I think the "-Os" is
harmless because it's a conditional assignment ( ?= ) and CFLAGS is set
already.
> - Don't install the binary to "sbin", use "bin" instead.
This thing needs to be run as root as it mmaps /dev/mem, is it still
suitable for bin/ ? I did as you asked anyways.
> Makefile of the port:
> - Don't start COMMENT with capital letters. Also COMMENT is weird, use
> something like "top like program for radeon GPUs" or similar.
done
> - You don't need EXTRACT_SUFX for .tar.gz files.
done
> - Change "VERSION" to "V".
done
> - Change the DISTNAME to "radeontop-${V}".
done
> - Use https://github.com/clbr/radeontop/archive/v${V}/ in MASTER_SITES.
done, thanks for this. This is why I was doing the empty EXTRACT_SUFX
and WRKDIST dance.
> - Remove PKGNAME.
done
> - Remove WRKDIST.
done
> - Remove "\" from MODULES.
done
> --
> Juan Francisco Cantero Hurtado http://juanfra.info
>
Re: NEW: x11/radeontop
On Fri, Sep 20, 2013 at 01:08:32PM +0100, Stuart Henderson wrote:
> On 2013/09/20 13:20, Dmitrij D. Czarkoff wrote:
> > On Thu, Sep 19, 2013 at 04:19:34PM -0600, Kyle R W Milz wrote:
> > > 1) Getting tarball off of github and the name of the distfile itself
> > > (v0.6)
> >
> > You might want to use DIST_SUBDIR (see bsd.port.mk(5)). BTW, is it really
> > necessary to hide file suffix?
> >
> > > 2) Patching of the Makefile to link to libintl properly
> > >
> > > 3) Patching of the Makefile to install files properly
> >
> > While you are at patching Makefile anyway, why not patch away all the CFLAGS
> > stuff that is not needed (eg. it forces "-Wall", which may go against local
> > settings). FWIW I would probably replace the original Makefile with a custom
> > one.
> >
> > --
> > Dmitrij D. Czarkoff
> >
>
> - no problem with the -W's in CFLAGS, but the hardcoded /usr/local
> should pick up LOCALBASE instead (will need to be patched using SUBST_CMD
> etc).
> I see no reason to replace with a custom Makefile, that is more likely
> to cause problems at update time
OK I changed hardcoded /usr/local to ${LOCALBASE} and used MAKE_ENV
instead of patching Makefile.
> - lowercase start of COMMENT
Done
> - stray \ at end of MODULES
Done
> - follow Makefile.template ordering of variables e.g. WANTLIB is in
> the wrong place (goes below PERMIT_..), makes it easier when we do bulk
> work on the tree
Done
devel/boost: add libboost_locale
libboost_locale wasn't built because configure didn't pick libiconv right.
I'll need it for the upcoming new release of audio/ncmpcpp.
oky?
Index: Makefile
===
RCS file: /cvs/ports/devel/boost/Makefile,v
retrieving revision 1.46
diff -u -p -u -p -r1.46 Makefile
--- Makefile12 Apr 2013 01:11:32 - 1.46
+++ Makefile20 Sep 2013 13:36:43 -
@@ -7,7 +7,7 @@ COMMENT=free peer-reviewed portable C++
VERSION= 1.53.0
DISTNAME= boost_${VERSION:S/./_/g}
PKGNAME= boost-${VERSION}
-REVISION= 1
+REVISION= 2
CATEGORIES=devel
MASTER_SITES= ${MASTER_SITE_SOURCEFORGE:=boost/}
EXTRACT_SUFX= .tar.bz2
@@ -19,6 +19,7 @@ BOOST_LIBS= boost_atomic-mt \
boost_filesystem boost_filesystem-mt \
boost_graph boost_graph-mt \
boost_iostreams boost_iostreams-mt \
+ boost_locale-mt \
boost_math_c99 boost_math_c99-mt \
boost_math_c99f boost_math_c99f-mt \
boost_math_c99l boost_math_c99l-mt \
@@ -52,12 +53,14 @@ PERMIT_PACKAGE_CDROM= Yes
WANTLIB= c m pthread stdc++ util z
-MODULES= lang/python
+MODULES= converters/libiconv \
+ lang/python
MODPY_RUNDEP= No
MAKE_ENV= GCC="${CC}" GXX="${CXX}"
-BJAM_CONFIG= -sNO_BZIP2=1 \
+BJAM_CONFIG= -sICONV_PATH=${LOCALBASE} \
+ -sNO_BZIP2=1 \
-d+2 -q \
-j ${MAKE_JOBS} \
cflags='${CFLAGS}' cxxflags='${CXXFLAGS}' \
Index: pkg/PLIST
===
RCS file: /cvs/ports/devel/boost/pkg/PLIST,v
retrieving revision 1.10
diff -u -p -u -p -r1.10 PLIST
--- pkg/PLIST 8 Mar 2013 01:21:38 - 1.10
+++ pkg/PLIST 20 Sep 2013 13:36:55 -
@@ -10116,6 +10116,8 @@ lib/libboost_iostreams-mt.a
@lib lib/libboost_iostreams-mt.so.${LIBboost_iostreams-mt_VERSION}
lib/libboost_iostreams.a
@lib lib/libboost_iostreams.so.${LIBboost_iostreams_VERSION}
+lib/libboost_locale-mt.a
+@lib lib/libboost_locale-mt.so.${LIBboost_locale-mt_VERSION}
lib/libboost_math_c99-mt.a
@lib lib/libboost_math_c99-mt.so.${LIBboost_math_c99-mt_VERSION}
lib/libboost_math_c99.a
Re: NEW: x11/radeontop
On Thu, Sep 19, 2013 at 04:19:34PM -0600, Kyle R W Milz wrote:
> ports@,
>
> Attached is an attempt at a port for radeontop, a top like program
> showing GPU utilization on radeon cards >=R600.
>
> It's quite the hack and I'm positive I'm doing some things wrong
> including but not limited to
>
> 1) Getting tarball off of github and the name of the distfile itself
> (v0.6)
>
> 2) Patching of the Makefile to link to libintl properly
>
> 3) Patching of the Makefile to install files properly
>
> If anyone could take a look and give feedback I would gladly appreciate.
I've not tested the port but here are some comments.
The patch is wrong:
- Add CPPFLAGS and LDFLAGS to the Makefile of the port. Use "MAKE_ENV"
to set the flags.
- Use "${LOCALBASE}" instead of "/usr/local".
- Why are you removing "DESTDIR"?
- Trim LDFLAGS from the makefile of the software. We don't want extra
optimizations. The same for "-Os".
- Don't install the binary to "sbin", use "bin" instead.
Makefile of the port:
- Don't start COMMENT with capital letters. Also COMMENT is weird, use
something like "top like program for radeon GPUs" or similar.
- You don't need EXTRACT_SUFX for .tar.gz files.
- Change "VERSION" to "V".
- Change the DISTNAME to "radeontop-${V}".
- Use https://github.com/clbr/radeontop/archive/v${V}/ in MASTER_SITES.
- Remove PKGNAME.
- Remove WRKDIST.
- Remove "\" from MODULES.
--
Juan Francisco Cantero Hurtado http://juanfra.info
Fix mariadb with ninja
Hi!
The diff below fixes ninja build of mariadb.
There's no need to put sql_builtin.cc into GEN_SOURCES:
libmysqld/CMakeLists.txt does the right thing.
Tested in subsequent builds with "-j" up to 4.
Index: Makefile
===
RCS file: /cvs/ports/databases/mariadb/Makefile,v
retrieving revision 1.5
diff -u -p -u -p -r1.5 Makefile
--- Makefile4 Sep 2013 19:20:28 - 1.5
+++ Makefile20 Sep 2013 12:38:43 -
@@ -47,7 +47,6 @@ LIB_DEPENDS-tests=${BASE_PKGPATH}>=5.5,
VMEM_WARNING= Yes
USE_GROFF= Yes
-USE_NINJA= No
CONFIGURE_ARGS+=-DCMAKE_INSTALL_PREFIX="${PREFIX}" \
-DINSTALL_DOCDIR="share/doc/mysql" \
Index: patches/patch-sql_CMakeLists_txt
===
RCS file: /cvs/ports/databases/mariadb/patches/patch-sql_CMakeLists_txt,v
retrieving revision 1.2
diff -u -p -u -p -r1.2 patch-sql_CMakeLists_txt
--- patches/patch-sql_CMakeLists_txt30 May 2013 12:39:18 - 1.2
+++ patches/patch-sql_CMakeLists_txt20 Sep 2013 12:38:43 -
@@ -1,6 +1,22 @@
$OpenBSD: patch-sql_CMakeLists_txt,v 1.2 2013/05/30 12:39:18 brad Exp $
sql/CMakeLists.txt.origTue May 21 18:09:51 2013
-+++ sql/CMakeLists.txt Fri May 24 19:48:19 2013
+--- sql/CMakeLists.txt.origWed Jul 17 16:51:28 2013
sql/CMakeLists.txt Fri Sep 20 14:02:31 2013
+@@ -25,7 +25,6 @@ ${CMAKE_BINARY_DIR}/sql
+ SET(GEN_SOURCES
+ ${CMAKE_CURRENT_BINARY_DIR}/sql_yacc.h
+ ${CMAKE_CURRENT_BINARY_DIR}/sql_yacc.cc
+-${CMAKE_CURRENT_BINARY_DIR}/sql_builtin.cc
+ ${CMAKE_CURRENT_BINARY_DIR}/lex_hash.h
+ )
+
+@@ -60,6 +59,7 @@ SET (SQL_SOURCE
+sql_cursor.cc sql_db.cc sql_delete.cc sql_derived.cc sql_do.cc
+sql_error.cc sql_handler.cc sql_help.cc sql_insert.cc
sql_lex.cc
+sql_list.cc sql_load.cc sql_manager.cc sql_parse.cc
++ ${CMAKE_CURRENT_BINARY_DIR}/sql_builtin.cc
+sql_partition.cc sql_plugin.cc sql_prepare.cc sql_rename.cc
+debug_sync.cc debug_sync.h
+sql_repl.cc sql_select.cc sql_show.cc sql_state.c sql_string.cc
@@ -268,7 +268,7 @@ ADD_CUSTOM_TARGET(distclean
VERBATIM
)
Re: [UPDATE] mail/sylpheed
On 2013/09/20 07:12, Amit Kulkarni wrote: > On Fri, 20 Sep 2013 09:33:02 +0200 > Remi Pointel wrote: > > > Hi, > > > > this is the diff to update sylpheed to 3.3.0. > > > > Are you ok? > > > > Cheers, > > > > Remi. > > > 3.4.0 is going to come out soon. I am running 3.4 beta5... > > Please remove the extra PERMIT_* lines. Just keeping the > PERMIT_PACKAGE_CDROM=Yes line... following other ports. Careful with these btw, sylpheed is not quite like other ports, see the compface flavour. I'm not saying that this isn't right, but just check things work how you expect (make dump-vars).
Re: [UPDATE] mail/sylpheed
On 2013/09/20 09:33, Remi Pointel wrote: > Hi, > > this is the diff to update sylpheed to 3.3.0. This diff is against an out-of-date tree, you have Makefile 1.98, current is 1.102 > SHARED_LIBS += sylph-0 2.1 # 2.1 > SHARED_LIBS += sylpheed-plugin-0 2.1 # 2.1 have you checked if these need a bump? (also some space/tab/space/tab in the lines ;)
Re: [UPDATE] mail/sylpheed
On Fri, 20 Sep 2013 09:33:02 +0200 Remi Pointel wrote: > Hi, > > this is the diff to update sylpheed to 3.3.0. > > Are you ok? > > Cheers, > > Remi. 3.4.0 is going to come out soon. I am running 3.4 beta5... Please remove the extra PERMIT_* lines. Just keeping the PERMIT_PACKAGE_CDROM= Yes line... following other ports. thanks
Re: NEW: x11/radeontop
On 2013/09/20 13:20, Dmitrij D. Czarkoff wrote: > On Thu, Sep 19, 2013 at 04:19:34PM -0600, Kyle R W Milz wrote: > > 1) Getting tarball off of github and the name of the distfile itself > > (v0.6) > > You might want to use DIST_SUBDIR (see bsd.port.mk(5)). BTW, is it really > necessary to hide file suffix? > > > 2) Patching of the Makefile to link to libintl properly > > > > 3) Patching of the Makefile to install files properly > > While you are at patching Makefile anyway, why not patch away all the CFLAGS > stuff that is not needed (eg. it forces "-Wall", which may go against local > settings). FWIW I would probably replace the original Makefile with a custom > one. > > -- > Dmitrij D. Czarkoff > - no problem with the -W's in CFLAGS, but the hardcoded /usr/local should pick up LOCALBASE instead (will need to be patched using SUBST_CMD etc). I see no reason to replace with a custom Makefile, that is more likely to cause problems at update time - lowercase start of COMMENT - stray \ at end of MODULES - follow Makefile.template ordering of variables e.g. WANTLIB is in the wrong place (goes below PERMIT_..), makes it easier when we do bulk work on the tree
Re: NEW: x11/radeontop
On Fri, September 20, 2013 15:20, Dmitrij D. Czarkoff wrote:
> On Thu, Sep 19, 2013 at 04:19:34PM -0600, Kyle R W Milz wrote:
>> 1) Getting tarball off of github and the name of the distfile itself
>> (v0.6)
>
> You might want to use DIST_SUBDIR (see bsd.port.mk(5)). BTW, is it really
> necessary to hide file suffix?
We now have filename{url} feature for DISTFILES
>> 2) Patching of the Makefile to link to libintl properly
>>
>> 3) Patching of the Makefile to install files properly
>
> While you are at patching Makefile anyway, why not patch away all the CFLAGS
> stuff that is not needed (eg. it forces "-Wall", which may go against local
> settings). FWIW I would probably replace the original Makefile with a custom
> one.
>
Re: the_silver_searcher: Patch upstream with 0.16
On Fri, Sep 20, 2013 at 03:26:38AM -0400, Brian Callahan wrote: > > This appears to need archivers/xz for lzma.h and -llzma support. > Also, a CONFIGURE_ENV line to quash a configure warning. Diff > attached relative to what's in openbsd-wip. > Thank you for the patch I have commited it to openbsd-wip. Regards, Florian
Re: NEW: x11/radeontop
On Thu, Sep 19, 2013 at 04:19:34PM -0600, Kyle R W Milz wrote: > 1) Getting tarball off of github and the name of the distfile itself > (v0.6) You might want to use DIST_SUBDIR (see bsd.port.mk(5)). BTW, is it really necessary to hide file suffix? > 2) Patching of the Makefile to link to libintl properly > > 3) Patching of the Makefile to install files properly While you are at patching Makefile anyway, why not patch away all the CFLAGS stuff that is not needed (eg. it forces "-Wall", which may go against local settings). FWIW I would probably replace the original Makefile with a custom one. -- Dmitrij D. Czarkoff
Re: UPDATE: py-setuptools
On Fri, Sep 20, 2013 at 9:38 AM, Remi Pointel wrote: > On Thu, 19 Sep 2013 21:42:25 +0100 > Edd Barrett wrote: >> Hi, >> >> I noticed that our py-setuptools ports is quite lagging. The following >> diff brings it up to date. >> >> Presumably setuptools is mostly used for building/installing python >> packages, so to test I have checked that every port depending upon this >> still packages. I did this on a fresh install using a SUBDIRLIST. >> Surprisingly, no issues. >> >> I understand that distribute was merged back into setuptools, so some >> time in the future we might decide to have a python3 flavor of this >> port: >> http://pythonhosted.org/setuptools/merge.html >> >> But anyway, that is another story. >> >> OK? > > > Hi, > > it seems good for me, I just tested the setuptools ports (not the ports which > depends on it), but if you tested and it was ok, I'm ok to commit this update. > > We will see what we will do concerning distribute, because now it's merged > into setuptools... > > Cheers, > > Remi. Don't break youtube-dl and it's ok with me ;) ;) ciao, David
Re: UPDATE: py-setuptools
On Thu, 19 Sep 2013 21:42:25 +0100 Edd Barrett wrote: > Hi, > > I noticed that our py-setuptools ports is quite lagging. The following > diff brings it up to date. > > Presumably setuptools is mostly used for building/installing python > packages, so to test I have checked that every port depending upon this > still packages. I did this on a fresh install using a SUBDIRLIST. > Surprisingly, no issues. > > I understand that distribute was merged back into setuptools, so some > time in the future we might decide to have a python3 flavor of this > port: > http://pythonhosted.org/setuptools/merge.html > > But anyway, that is another story. > > OK? Hi, it seems good for me, I just tested the setuptools ports (not the ports which depends on it), but if you tested and it was ok, I'm ok to commit this update. We will see what we will do concerning distribute, because now it's merged into setuptools... Cheers, Remi.
[UPDATE] mail/sylpheed
Hi, this is the diff to update sylpheed to 3.3.0. Are you ok? Cheers, Remi. Index: Makefile === RCS file: /cvs/ports/mail/sylpheed/Makefile,v retrieving revision 1.98 diff -u -p -r1.98 Makefile --- Makefile12 Jul 2012 20:17:45 - 1.98 +++ Makefile19 Sep 2013 10:19:20 - @@ -2,7 +2,7 @@ COMMENT = lightweight and user-friendly e-mail client -DISTNAME = sylpheed-3.2.0 +DISTNAME = sylpheed-3.3.0 SHARED_LIBS += sylph-0 2.1 # 2.1 SHARED_LIBS += sylpheed-plugin-0 2.1 # 2.1 @@ -13,7 +13,6 @@ HOMEPAGE= http://sylpheed.sraoss.jp/en # GPLv2 - LGPLv2 PERMIT_PACKAGE_CDROM= Yes PERMIT_PACKAGE_FTP=Yes -PERMIT_DISTFILES_CDROM=Yes PERMIT_DISTFILES_FTP= Yes MODULES = devel/gettext @@ -30,7 +29,7 @@ WANTLIB += png gpgme gpg-error gtkspell WANTLIB += gtk-x11-2.0 gdk-x11-2.0 gtkspell assuan RUN_DEPENDS= devel/desktop-file-utils -MASTER_SITES = http://sylpheed.sraoss.jp/sylpheed/v3.2/ +MASTER_SITES = http://sylpheed.sraoss.jp/sylpheed/v3.3/ USE_LIBTOOL= Yes CONFIGURE_STYLE= gnu Index: distinfo === RCS file: /cvs/ports/mail/sylpheed/distinfo,v retrieving revision 1.50 diff -u -p -r1.50 distinfo --- distinfo12 Jul 2012 20:17:45 - 1.50 +++ distinfo19 Sep 2013 10:19:20 - @@ -1,5 +1,2 @@ -MD5 (sylpheed-3.2.0.tar.gz) = Gvl/NfIqIDjQUEEJIJHyGg== -RMD160 (sylpheed-3.2.0.tar.gz) = gWLE1Ffv8O6K4NXQVUh5yY4T2ts= -SHA1 (sylpheed-3.2.0.tar.gz) = pBqOL8PF5JNfMMe6z/jXJQhUbjU= -SHA256 (sylpheed-3.2.0.tar.gz) = lp6fL0uphuPLnJeRdtXpu42qxOsAQpDHwvrlobaUVcU= -SIZE (sylpheed-3.2.0.tar.gz) = 4925789 +SHA256 (sylpheed-3.3.0.tar.gz) = GN9jgDQqErTFB1SJORJQI+x7BRZL81Zbfu/YWTJjiU4= +SIZE (sylpheed-3.3.0.tar.gz) = 4940459
Re: the_silver_searcher: Patch upstream with 0.16
On 09/20/13 03:04, Giovanni Bechis wrote:
On 09/19/13 20:34, Florian Stinglmayr wrote:
On Thu, Sep 19, 2013 at 06:03:52PM +0100, Stuart Henderson wrote:
The bash completion script should go in
${PREFIX}/share/bash-completion/completions/ then it will be OK sthen@
for anyone who would like to import.
Fixed.
Annoyingly the MASTER_SITES has broken ipv6 :(
Should be fixed. (Can't test it myself though).
It is not fixed yet.
Cheers
Giovanni
This appears to need archivers/xz for lzma.h and -llzma support. Also, a
CONFIGURE_ENV line to quash a configure warning. Diff attached relative
to what's in openbsd-wip.
diff --git a/textproc/the_silver_searcher/Makefile b/textproc/the_silver_searcher/Makefile
index bdae22e..3b13812 100644
--- a/textproc/the_silver_searcher/Makefile
+++ b/textproc/the_silver_searcher/Makefile
@@ -11,13 +11,15 @@ MAINTAINER = Florian Stinglmayr
# Apache 2.0
PERMIT_PACKAGE_CDROM = Yes
-WANTLIB += c pcre pthread z
+WANTLIB += c lzma pcre pthread z
MASTER_SITES = http://pub.n0la.org/
-LIB_DEPENDS = devel/pcre
+LIB_DEPENDS = archivers/xz \
+ devel/pcre
CONFIGURE_STYLE = gnu
+CONFIGURE_ENV = CPPFLAGS="-I${LOCALBASE}/include"
NO_TEST = YES
Re: the_silver_searcher: Patch upstream with 0.16
On 09/19/13 20:34, Florian Stinglmayr wrote:
> On Thu, Sep 19, 2013 at 06:03:52PM +0100, Stuart Henderson wrote:
>>
>> The bash completion script should go in
>> ${PREFIX}/share/bash-completion/completions/ then it will be OK sthen@
>> for anyone who would like to import.
>>
>
> Fixed.
>
>> Annoyingly the MASTER_SITES has broken ipv6 :(
>>
>
> Should be fixed. (Can't test it myself though).
>
It is not fixed yet.
Cheers
Giovanni
Re: sdl: new release soon
On Fri, Sep 20, 2013 at 12:16:12AM -0600, Anthony J. Bentley wrote: > Jonathan Gray writes: > > On Sat, Aug 10, 2013 at 09:55:00PM +1000, Jonathan Gray wrote: > > > Even though it still isn't released there are a few projects > > > that now require it so I've added a quick port of the release > > > candidate as devel/sdl2 in the openbsd-wip repo. Attached > > > here as well. > > > > and now it has been released, so here is an updated port. > > Below is a patch to emulators/mupen64plus to build with SDL2 for > testing purposes. > > On both i386 and amd64, I get this behavior which didn't happen before: > > Video: Initializing OpenGL Device Context. > Core: Setting 32-bit video mode: 640x480 > Core Error: SDL_SetVideoMode failed: Failed loading libGL.so.1: File not found > Video Error: Failed to set 32-bit video mode: 640x480 > Core Status: Rom closed. updated version attached which should look for libGL.so sdl2.tgz Description: application/tar-gz
