"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
> ==
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/Mak
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 do
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
retrievin
Another one:
- add sysutils to CATEGORIES, based on comments from Dmitrij
radeontop-0.6.tar.gz
Description: application/tar-gz
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 b
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
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:
-
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
- C
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" durin
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 DESTDIRNA
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/ve
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
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
call
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.
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 ab
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
o
> > 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
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 pk
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 DE
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
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
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
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
==
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 `
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
> > securit
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
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/ ?
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
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 m
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
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 u
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
di
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
>
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: /
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
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
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=
Y
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 fil
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 t
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
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
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 pytho
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 depend
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
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 im
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.
>
>> Annoy
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
> > >
48 matches
Mail list logo
