[update] mutagen 1.22
Hi!
The diff below updated audio/py-mutagen to its latest version.
MAKE_ENV here is needed to fix a reproducible error in regression
tests:
TMid3v2 (21):E 20
==
ERROR: test_encoding_with_escape (tests.test_tools_mid3v2.TMid3v2)
--
Traceback (most recent call last):
File
"/usr/ports/pobj/py-mutagen-1.22/mutagen-1.22/tests/test_tools_mid3v2.py", line
178, in test_encoding_with_escape
res, out = self.call("-e", "-a", text.encode(enc), self.filename)
UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-2:
ordinal not in range(128)
Index: Makefile
===
RCS file: /cvs/ports/audio/py-mutagen/Makefile,v
retrieving revision 1.11
diff -u -p -u -p -r1.11 Makefile
--- Makefile7 Aug 2013 21:31:17 - 1.11
+++ Makefile16 Sep 2013 07:41:48 -
@@ -2,10 +2,9 @@
COMMENT = Python module to handle audio metadata
-MODPY_EGG_VERSION = 1.20
+MODPY_EGG_VERSION = 1.22
DISTNAME = mutagen-${MODPY_EGG_VERSION}
PKGNAME = py-${DISTNAME}
-REVISION = 2
CATEGORIES = audio
HOMEPAGE = https://mutagen.googlecode.com/
@@ -17,7 +16,7 @@ PERMIT_PACKAGE_CDROM =Yes
MODULES = lang/python
-MODPY_ADJ_FILES = mutagen/__init__.py \
+MODPY_ADJ_FILES = docs/id3_frames_gen.py \
tools/mid3iconv \
tools/mid3v2 \
tools/moggsplit \
@@ -31,10 +30,9 @@ TEST_DEPENDS = audio/faad \
audio/vorbis-tools \
multimedia/oggz
-pre-build:
- @rm ${WRKDIST}/tools/*.orig
+MAKE_ENV = LC_CTYPE="en_US.UTF-8"
do-test:
- ${MODPY_CMD} test
+ ${MODPY_TEST_TARGET}
.include
Index: distinfo
===
RCS file: /cvs/ports/audio/py-mutagen/distinfo,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 distinfo
--- distinfo31 May 2011 09:49:52 - 1.3
+++ distinfo16 Sep 2013 07:41:48 -
@@ -1,5 +1,2 @@
-MD5 (mutagen-1.20.tar.gz) = rbFtn2BWvIZKXIbG+IWveQ==
-RMD160 (mutagen-1.20.tar.gz) = 6O3OuhHWcM3TAhQp3rz0VOEdTZY=
-SHA1 (mutagen-1.20.tar.gz) = eowZGBYOa10krNFG9XwI7ZQqL6g=
-SHA256 (mutagen-1.20.tar.gz) = flbEeN4VT9zQDSV+vHe+hxgYjxoNuRb1HxKbfKAd5uc=
-SIZE (mutagen-1.20.tar.gz) = 651649
+SHA256 (mutagen-1.22.tar.gz) = 3fKQe8r0gnsESj1wsvs8G1iVRJfYYTPxZxX8bEB9SU4=
+SIZE (mutagen-1.22.tar.gz) = 813763
Index: patches/patch-man_mid3v2_1
===
RCS file: patches/patch-man_mid3v2_1
diff -N patches/patch-man_mid3v2_1
--- patches/patch-man_mid3v2_1 31 May 2011 09:49:52 - 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,25 +0,0 @@
-$OpenBSD: patch-man_mid3v2_1,v 1.1 2011/05/31 09:49:52 dcoppa Exp $
-
-Add --TXXX support to mid3v2
-(upstream revision r97)
-
man/mid3v2.1.orig Sun Dec 13 05:11:56 2009
-+++ man/mid3v2.1 Thu May 26 12:28:04 2011
-@@ -1,4 +1,4 @@
--.TH mid3v2 1 "December 12th, 2009"
-+.TH mid3v2 1 "October 30th, 2010"
- .SH NAME
- mid3v2 \- audio tag editor similar to 'id3v2'
- .SH SYNOPSIS
-@@ -60,6 +60,11 @@ Set the track number (TRCK).
- Any text or URL frame (those beginning with T or W) can be modified or
- added by prefixing the name of the frame with "\-\-". For example,
- \fB\-\-TIT3 "Monkey!"\fR will set the TIT3 (subtitle) frame to \fBMonkey!\fR.
-+.PP
-+The TXXX frame requires a colon-separated description key; many TXXX
-+frames may be set in the file as long as they have different keys. To
-+set this key, just separate the text with a colon, e.g.
-+\fB\-\-TXXX "ALBUMARTISTSORT:Examples,\ The"\fR.
- .SH BUGS
- No sanity checking is done on the editing operations you perform, so
- mid3v2 will happily accept \-\-TSIZ when editing an ID3v2.4 frame. However,
Index: patches/patch-setup_py
===
RCS file: /cvs/ports/audio/py-mutagen/patches/patch-setup_py,v
retrieving revision 1.2
diff -u -p -u -p -r1.2 patch-setup_py
--- patches/patch-setup_py 31 May 2011 09:49:52 - 1.2
+++ patches/patch-setup_py 16 Sep 2013 07:41:48 -
@@ -1,7 +1,7 @@
$OpenBSD: patch-setup_py,v 1.2 2011/05/31 09:49:52 dcoppa Exp $
setup.py.orig Thu Oct 8 09:26:23 2009
-+++ setup.py Thu May 26 12:02:03 2011
-@@ -196,7 +196,7 @@ class coverage_cmd(Command):
+--- setup.py.orig Fri Sep 6 11:11:46 2013
setup.py Mon Sep 16 07:48:58 2013
+@@ -171,7 +171,7 @@ class coverage_cmd(Command):
raise SystemExit("Coverage percentage went up; change setup.py.")
if os.name == "posix":
Index: patches/patch-tests_test___init___py
===
RCS fil
Re: buildbot / buildslave 0.8.8
Hi Landry, simple & straightforward update, seems to work fine on my setup. Piotr, are you still using this ? I'm planning on getting back to using it again, but I don't at the moment, so feel free to takeover the maintainership. Thanks! Best regards, Piotr Sikora
Re: fix scons soname behaviour
On Thu, Sep 05, 2013 at 12:32:45PM -0400, Brad Smith wrote:
> On 05/09/13 9:57 AM, Stefan Sperling wrote:
> >On Thu, Sep 05, 2013 at 02:24:03PM +0100, Stuart Henderson wrote:
> >>On 2013/09/05 14:43, Stefan Sperling wrote:
> >>>On Wed, Sep 04, 2013 at 02:50:44PM -0400, Brad Smith wrote:
> The soname command line parameter should just be removed on the line
> below what is being modified.
> >>>
> >>>That would likely make it work. But I don't think we could push
> >>>such a patch upstream.
> >>
> >>Hmm, why not? Obviously it would need to be conditional on OS
> >
> >I couldn't tell from Brad's comment whether he meant it to be
> >OS-dependent or just the simple one-line removal hack.
> >
> >I'm working with the upstream devs now.
>
> Well what goes into the ports tree and how the issue is ultimately
> fixed upstream doesn't have to be the same but the goal is to
> eventually have it fixed properly upstream. The upstream fix would
> be OS dependent.
Here's a new diff that was discussed with upstream. They haven't
committed it yet but they didn't raise concerns about this.
Is this fine?
Index: Makefile
===
RCS file: /cvs/ports/devel/scons/Makefile,v
retrieving revision 1.17
diff -u -p -r1.17 Makefile
--- Makefile5 Jul 2013 20:09:59 - 1.17
+++ Makefile4 Sep 2013 17:16:15 -
@@ -3,6 +3,7 @@
COMMENT= Python-based build system
VERSION = 2.3.0
+REVISION = 1
DISTNAME= scons-${VERSION}
CATEGORIES=devel
Index: patches/patch-engine_SCons_Tool___init___py
===
RCS file: patches/patch-engine_SCons_Tool___init___py
diff -N patches/patch-engine_SCons_Tool___init___py
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-engine_SCons_Tool___init___py 16 Sep 2013 09:43:49 -
@@ -0,0 +1,40 @@
+$OpenBSD$
+http://scons.tigris.org/issues/show_bug.cgi?id=2916
+--- engine/SCons/Tool/__init__.py.orig Sun Mar 3 15:48:39 2013
engine/SCons/Tool/__init__.py Thu Sep 5 15:40:24 2013
+@@ -257,6 +257,10 @@ def VersionShLibLinkNames(version, libname, env):
+ print "VersionShLibLinkNames: linkname = ",linkname
+ linknames.append(linkname)
+ elif platform == 'posix':
++if sys.platform.startswith('openbsd'):
++# OpenBSD uses x.y shared library versioning numbering convention
++# and doesn't use symlinks to backwards-compatible libraries
++return []
+ # For libfoo.so.x.y.z, linknames libfoo.so libfoo.so.x.y libfoo.so.x
+ suffix_re = re.escape(shlib_suffix + '.' + version)
+ # First linkname has no version number
+@@ -302,13 +306,17 @@ symlinks for the platform we are on"""
+ if version:
+ # set the shared library link flags
+ if platform == 'posix':
+-suffix_re = re.escape(shlib_suffix + '.' + version)
+-(major, age, revision) = version.split(".")
+-# soname will have only the major version number in it
+-soname = re.sub(suffix_re, shlib_suffix, libname) + '.' + major
+-shlink_flags += [ '-Wl,-Bsymbolic', '-Wl,-soname=%s' % soname ]
+-if Verbose:
+-print " soname ",soname,", shlink_flags ",shlink_flags
++shlink_flags += [ '-Wl,-Bsymbolic' ]
++if sys.platform.startswith('openbsd'):
++pass # OpenBSD doesn't usually use SONAME for libraries
++else:
++suffix_re = re.escape(shlib_suffix + '.' + version)
++(major, age, revision) = version.split(".")
++# soname will have only the major version number in it
++soname = re.sub(suffix_re, shlib_suffix, libname) + '.' +
major
++shlink_flags += [ '-Wl,-soname=%s' % soname ]
++if Verbose:
++print " soname ",soname,", shlink_flags ",shlink_flags
+ elif platform == 'cygwin':
+ shlink_flags += [ '-Wl,-Bsymbolic',
+ '-Wl,--out-implib,${TARGET.base}.a' ]
Re: small www/apache-httpd fixes: rc script and readme
On Thu, Sep 12, 2013 at 04:40:47PM +0200, Antoine Jacoutot wrote:
> On Thu, Sep 12, 2013 at 04:28:59PM +0200, Stefan Sperling wrote:
> > The rc script prints httpd2(failed). If I manually run the command run
> > by the script ('/usr/local/sbin/httpd2 start') httpd2 prints its usage.
>
> But this is not the command run by the script.
> The command run by the script is:
> $daemon $daemon_flags
> i.e.
> '/usr/local/sbin/httpd2'
Right. Forget about this. I cannot reproduce the issue anymore, it must
have been due to a broken httpd config file or similar.
Re: fix scons soname behaviour
On Mon, Sep 16, 2013 at 11:44:42AM +0200, Stefan Sperling wrote: > On Thu, Sep 05, 2013 at 12:32:45PM -0400, Brad Smith wrote: > > On 05/09/13 9:57 AM, Stefan Sperling wrote: > > >On Thu, Sep 05, 2013 at 02:24:03PM +0100, Stuart Henderson wrote: > > >>On 2013/09/05 14:43, Stefan Sperling wrote: > > >>>On Wed, Sep 04, 2013 at 02:50:44PM -0400, Brad Smith wrote: > > The soname command line parameter should just be removed on the line > > below what is being modified. > > >>> > > >>>That would likely make it work. But I don't think we could push > > >>>such a patch upstream. > > >> > > >>Hmm, why not? Obviously it would need to be conditional on OS > > > > > >I couldn't tell from Brad's comment whether he meant it to be > > >OS-dependent or just the simple one-line removal hack. > > > > > >I'm working with the upstream devs now. > > > > Well what goes into the ports tree and how the issue is ultimately > > fixed upstream doesn't have to be the same but the goal is to > > eventually have it fixed properly upstream. The upstream fix would > > be OS dependent. > > Here's a new diff that was discussed with upstream. They haven't > committed it yet but they didn't raise concerns about this. > > Is this fine? That looks saner, and it's nice that upstream is willing to cooperate :) I suppose that will allow us to remove some patches in consumer ports ? Landry
Re: [update] mutagen 1.22
On 09/16/13 09:44, David Coppa wrote: > > Hi! > > The diff below updated audio/py-mutagen to its latest version. > > MAKE_ENV here is needed to fix a reproducible error in regression > tests: > regression tests are hanging for me (OpenBSD 5.4-current (GENERIC.MP) #1: Mon Aug 12 20:16:33 PDT 2013) with python stuck in getblk or biowait. mutagen-1.20 regression tests has the same problem. As for the MAKE_ENV trick maybe C.UTF-8 could be more correct ? I will try to update to more recent snapshot soon and retest. Cheers Giovanni
Re: Building GCC-4.8.1 without ports
2013/9/11 niXman: > 2013/9/11 Tobias Ulmer: >> Because it's work. Do you volunteer? > > Yes, I will, if someone will coordinate me. > First of all, I need a description of what exactly problem is solved > by each patch. ping? -- Regards, niXman ___ Dual-target(32 & 64-bit) MinGW compilers for 32 and 64-bit Windows: http://sourceforge.net/projects/mingwbuilds/ ___ Another online IDE: http://liveworkspace.org/
Re: Building GCC-4.8.1 without ports
On Mon, Sep 16, 2013 at 03:35:04PM +0400, niXman wrote: > 2013/9/11 niXman: > > 2013/9/11 Tobias Ulmer: > >> Because it's work. Do you volunteer? > > > > Yes, I will, if someone will coordinate me. > > First of all, I need a description of what exactly problem is solved > > by each patch. > > ping? Did you eat a clown for breakfast? > > > -- > Regards, > niXman > ___ > Dual-target(32 & 64-bit) MinGW compilers for 32 and 64-bit Windows: > http://sourceforge.net/projects/mingwbuilds/ > ___ > Another online IDE: http://liveworkspace.org/
Re: Building GCC-4.8.1 without ports
On Mon, Sep 16, 2013 at 03:35:04PM +0400, niXman wrote: > 2013/9/11 niXman: > > 2013/9/11 Tobias Ulmer: > >> Because it's work. Do you volunteer? > > > > Yes, I will, if someone will coordinate me. > > First of all, I need a description of what exactly problem is solved > > by each patch. > Look, you are obviously a clueless newbie. Do you think we *like* having those patches there ? Don't you think we do routinely get them upstream when we can ? This takes time, mostly because it's very very difficult to work with this particular upstream, between insane rules (only commit to current), and very slow moving for low priority targets like OpenBSD. If you had half a clue, you would: - be able to read the commit messages for those patches and figure out what they do by yourself. - subscribe to the relevant gcc mailing-lists, and see what's currently hanging. - look at the source code for gcc-current upstream, and see for yourself what's committe/uncommitted and why. Here, you have enough pointers to keep you occupied for a while. Go grab clues, and come back where you have figured a few things out. Or just shut up. Currently, you're just an obnoxious pain.
[new] fonts/hermit-ttf
Hola! New font: Hermit is a monospace font designed to be clear, pragmatic and very readable. Its creation has been focused on programming. Every glyph was carefully planned and calculated, according to defined principles and rules. For this reason, Hermit is coherent and regular. OK? hermit-ttf-1.01.tgz Description: GNU Zip compressed data
Re: [new] fonts/hermit-ttf
On Mon, Sep 16, 2013 at 9:33 AM, Aaron wrote: > On Mon, Sep 16, 2013 at 9:23 AM, Aaron wrote: >> On Mon, Sep 16, 2013 at 9:03 AM, Stuart Henderson wrote: >>> On 2013/09/16 08:22, Aaron wrote: Hola! New font: Hermit is a monospace font designed to be clear, pragmatic and very readable. Its creation has been focused on programming. Every glyph was carefully planned and calculated, according to defined principles and rules. For this reason, Hermit is coherent and regular. OK? >>> >>> I'd probably install this as hermit.ttf rather than hermit-1.01.ttf, what >>> do you think? >>> >> >> Sounds good, I also added "# OFL 1.1" per bcallah@. > > > New version with ttf file renamed to hermit.ttf - also added OFL version. > > OK? Heeen hermit-ttf-1.01.tgz Description: GNU Zip compressed data
Re: [new] fonts/hermit-ttf
On Mon, Sep 16, 2013 at 08:22:40AM -0600, Aaron wrote: > Hola! > > New font: Hermit is a monospace font designed to be clear, pragmatic > and very readable. Its creation has been focused on programming. Every > glyph was carefully planned and calculated, according to defined > principles and rules. For this reason, Hermit is coherent and regular. > > OK? - Change the name to hermit-fonts, the author will create new font variants in the future. - Include the otf file. -- Juan Francisco Cantero Hurtado http://juanfra.info
NEW: databases/mydumper
pkg/DESCR: mydumper is complement to mysqldump, for MySQL data dumping, providing parallelism, performance and easier to manage output. new version of databases/mysql-zrm can use this tool to speed up backups, separate diff soon. ok to import ? Comments ? Cheers Giovanni mydumper-0.5.2.tgz Description: application/compressed-tar
Re: unbreak lang/sbcl on i386
Sorry for slacking on this, this has been fixed upstream for a short
while now, and just needs a version bump. The only wrinkle is there's
now an "optional" dependency on gmp at build time, and at runtime if
one wishes to use the sb-gmp contrib module.
On Sun, Sep 15, 2013 at 04:54:19PM +0200, Jérémie Courrèges-Anglas wrote:
>
> Hi folks,
>
> here's a diff to correct sbcl's assumptions about struct timeval on
> OpenBSD i386. The second build just ended, quick testing shows no
> regression. I've refreshed the existing patches while here.
>
> ok?
>
> Questions:
> - is someone here already dealing with upstream? If no one steps up
> I'll send them the patch soon (if they fix their DNS problems...)
Fixed upstream already, and in a fairly portable and futureproof way
that avoids those hardcoded struct definitions.
> - I see subdirectories in the source code, named like "mips" or "alpha".
> Has anyone analyzed the work that should be done to make this port
> available on more architectures?
It will be a bit of work, I think. The easiest port to start with
would be hppa, I think. Possibly sparc if you can squeeze sbcl into
the virtual address space there. The alpha port of is somewhat
special, and I think would be more work to bring up on openbsd. The
mips port is 32-bit, so it's out unless we get a 32-bit mips platform.
> Index: Makefile
> ===
> RCS file: /cvs/ports/lang/sbcl/Makefile,v
> retrieving revision 1.19
> diff -u -p -r1.19 Makefile
> --- Makefile 6 Sep 2013 22:16:24 - 1.19
> +++ Makefile 15 Sep 2013 11:06:08 -
> @@ -2,12 +2,11 @@
>
> # not yet ported to other arches
> ONLY_FOR_ARCHS = amd64 i386 powerpc
> -BROKEN-i386= build fails post-64-bit time_t
> -# ^^ logs: http://rhaalovely.net/build-failures/i386/20130901/lang/sbcl.log
>
> COMMENT= compiler and runtime system for ANSI Common Lisp
>
> V = 1.1.8
> +REVISION=0
> DISTNAME=sbcl-${V}-source
> PKGNAME= sbcl-${V}
> WRKDIST= ${WRKDIR}/sbcl-${V}
> Index: patches/patch-contrib_asdf-module_mk
> ===
> RCS file: /cvs/ports/lang/sbcl/patches/patch-contrib_asdf-module_mk,v
> retrieving revision 1.1
> diff -u -p -r1.1 patch-contrib_asdf-module_mk
> --- patches/patch-contrib_asdf-module_mk 8 Jul 2011 11:42:09 -
> 1.1
> +++ patches/patch-contrib_asdf-module_mk 15 Sep 2013 12:11:41 -
> @@ -5,9 +5,9 @@ Fix 'all' target to allow building witho
> Don't copy every single file when installing the contribs, only the
> ones that are actually needed to load the system.
>
> contrib/asdf-module.mk.orig Mon May 9 04:49:39 2011
> -+++ contrib/asdf-module.mk Fri Jul 8 13:39:44 2011
> -@@ -25,7 +25,8 @@ endif
> +--- contrib/asdf-module.mk.orig Sun Jun 2 15:12:39 2013
> contrib/asdf-module.mk Sun Sep 15 14:11:33 2013
> +@@ -27,7 +27,8 @@ endif
>
> export CC SBCL EXTRA_CFLAGS EXTRA_LDFLAGS
>
> @@ -15,9 +15,9 @@ ones that are actually needed to load th
> +all: $(EXTRA_ALL_TARGETS) $(SYSTEM).fasl
> +$(SYSTEM).fasl:
> $(MAKE) -C ../asdf
> - $(SBCL) --eval '(defvar *system* "$(SYSTEM)")' --load ../asdf-stub.lisp
> --eval '(quit)'
> + $(SBCL) --eval '(defvar *system* "$(SYSTEM)")' --load ../asdf-stub.lisp
> --eval '(exit)'
>
> -@@ -37,5 +38,4 @@ test: all
> +@@ -40,5 +41,4 @@ test: all
> # KLUDGE: There seems to be no portable way to tell tar to not to
> # preserve owner, so chown after installing for the current user.
> install: $(EXTRA_INSTALL_TARGETS)
> Index: patches/patch-make-target-contrib_sh
> ===
> RCS file: /cvs/ports/lang/sbcl/patches/patch-make-target-contrib_sh,v
> retrieving revision 1.2
> diff -u -p -r1.2 patch-make-target-contrib_sh
> --- patches/patch-make-target-contrib_sh 11 Aug 2012 23:02:23 -
> 1.2
> +++ patches/patch-make-target-contrib_sh 15 Sep 2013 01:47:04 -
> @@ -4,9 +4,9 @@ Only run the contrib tests if $RUN_CONTR
> allows the contribs to be build when USE_SYSTRACE=Yes, and the tests
> to be run later in do-regress.
>
> make-target-contrib.sh.orig Mon Dec 5 00:09:01 2011
> -+++ make-target-contrib.sh Sat Aug 11 16:55:34 2012
> -@@ -43,6 +43,7 @@ export SBCL SBCL_BUILDING_CONTRIB
> +--- make-target-contrib.sh.orig Sun Jun 2 15:12:40 2013
> make-target-contrib.sh Sun Sep 15 03:26:47 2013
> +@@ -44,6 +44,7 @@ export SBCL SBCL_BUILDING_CONTRIB
> # as SB-RT and SB-GROVEL, but FIXME: there's probably a better
> # solution. -- CSR, 2003-05-30
>
> @@ -14,7 +14,7 @@ to be run later in do-regress.
> find contrib/ \( -name '*.fasl' -o \
>-name '*.FASL' -o \
>-name 'foo.c' -o \
> -@@ -57,6 +58,11 @@ find contrib/ \( -name '*.fasl' -o \
> +@@ -58,6 +59,11 @
Re: unbreak lang/sbcl on i386
Huh, I thought I had sent this mail... *shrug*
- updating clisp to 2.49
- texlive make build and make fake work fine; pkg/PLIST changed but
that doesn't seem to be due to the clisp update
- updating sbcl to 1.1.11 (using clisp-2.49 as a host)
- note: sbcl/INSTALL lists supported clisp versions: "(only some
versions: 2.44.1 is OK, 2.47 is not)"...
- patch committed yesterday doesn't apply and isn't needed anymore
- but a new struct timeval problem has been introduced in
contrib/sb-posix/constants.lisp :)
- two other errors in contrib/, maybe (?) linked to the one above, to
the clisp update, or... just plain regressions
dpb running on powerpc now, sbcl's make test on i386 not yet finished.
That stuff takes a long time to build...
WIP diff at the end of the mail.
>Kenneth R Westerback writes:
>
>> On Sun, Sep 15, 2013 at 04:54:19PM +0200, J??r??mie Courr??ges-Anglas wrote:
>>>
>>> Hi folks,
>>>
>>> here's a diff to correct sbcl's assumptions about struct timeval on
>>> OpenBSD i386. The second build just ended, quick testing shows no
>>> regression. I've refreshed the existing patches while here.
>>>
>>> ok?
>>
>> That's fine with me, unless you want to earn an extra star and go
>> to 1.11 at the same time. :-) It (1.11) compiles and regresses fine
>> on amd64 for me, but I got distracted by other stuff and haven't
>> tried on macppc yet.
>
>ACK. No promise about when I'll work on the update. Right now my
>concern is to get a working sbcl on i386 (and powerpc - the package on
>mirrors is from Aug 2...).
>
>> Ken
>>
>>>
>>> Questions:
>>> - is someone here already dealing with upstream? If no one steps up
>>> I'll send them the patch soon (if they fix their DNS problems...)
>
>>> - I see subdirectories in the source code, named like "mips" or "alpha".
>>> Has anyone analyzed the work that should be done to make this port
>>> available on more architectures?
I took a quick look, I don't think there's much to hope in this area
right now.
> [...]
Index: lang/clisp/Makefile
===
RCS file: /home/cvs/ports/lang/clisp/Makefile,v
retrieving revision 1.43
diff -u -p -r1.43 Makefile
--- lang/clisp/Makefile 21 Mar 2013 08:46:32 - 1.43
+++ lang/clisp/Makefile 16 Sep 2013 13:02:57 -
@@ -2,10 +2,12 @@
ONLY_FOR_ARCHS = amd64 i386 powerpc sparc64
+# Building io.o requires more than 512MB of ram on i386
+VMEM_WARNING = Yes
+
COMMENT = ANSI Common Lisp implementation
-DISTNAME= clisp-2.48
-REVISION = 3
+DISTNAME= clisp-2.49
CATEGORIES=lang
HOMEPAGE= http://clisp.cons.org/
MAINTAINER = Joshua Elsasser
@@ -36,7 +38,6 @@ CONFIGURE_ARGS= --fsstnd=openbsd \
--elispdir=${PREFIX}/share/emacs/site-lisp \
--vimdir=${PREFIX}/share/doc/clisp \
--srcdir=${WRKSRC} ${WRKBUILD}
-CONFIGURE_ENV =ac_cv_prog_DVIPDF=''
.if ${MACHINE_ARCH} == "sparc64"
CFLAGS += -DSAFETY=2 -DNO_ASM -mcmodel=medany
Index: lang/clisp/distinfo
===
RCS file: /home/cvs/ports/lang/clisp/distinfo,v
retrieving revision 1.9
diff -u -p -r1.9 distinfo
--- lang/clisp/distinfo 7 Jan 2010 10:55:28 - 1.9
+++ lang/clisp/distinfo 16 Sep 2013 13:02:57 -
@@ -1,5 +1,2 @@
-MD5 (clisp-2.48.tar.bz2) = XkxPfNz3oe9BlrmJfChxWA==
-RMD160 (clisp-2.48.tar.bz2) = AcFQ69HkTmJ/Qd6c3IS5AmcYWnA=
-SHA1 (clisp-2.48.tar.bz2) = 3CE+0CGU7EyLWWEYxfkrJdH1QOA=
-SHA256 (clisp-2.48.tar.bz2) = Bbg/VghZojZ5zPwHOhKKU3f+lInXNEMaPcMu+I8MPcI=
-SIZE (clisp-2.48.tar.bz2) = 7885098
+SHA256 (clisp-2.49.tar.bz2) = gTL/NTr6pw5rGTZ6Ja49WkNicnnCVkfCIGQf7QD46JA=
+SIZE (clisp-2.49.tar.bz2) = 8091011
Index: lang/clisp/patches/patch-modules_berkeley-db_Makefile_in
===
RCS file: lang/clisp/patches/patch-modules_berkeley-db_Makefile_in
diff -N lang/clisp/patches/patch-modules_berkeley-db_Makefile_in
--- /dev/null 1 Jan 1970 00:00:00 -
+++ lang/clisp/patches/patch-modules_berkeley-db_Makefile_in16 Sep 2013
13:02:57 -
@@ -0,0 +1,12 @@
+$OpenBSD$
+--- modules/berkeley-db/Makefile.in.orig Wed Mar 24 20:44:56 2010
modules/berkeley-db/Makefile.inSun Sep 15 19:29:17 2013
+@@ -10,7 +10,7 @@ CLISP_LINKKIT = @CLISP_LINKKIT@
+ LN = @LN@
+ LN_S = @LN_S@
+
+-MAKE = make
++#MAKE = make
+
+ SHELL = /bin/sh
+
Index: lang/clisp/patches/patch-modules_dbus_Makefile_in
===
RCS file: lang/clisp/patches/patch-modules_dbus_Makefile_in
diff -N lang/clisp/patches/patch-modules_dbus_Makefile_in
--- /dev/null 1 Jan 1970 00:00:00 -
+++ lang/clisp/patches/patch-modules_dbus_Makefile_in 16 Sep 2013 13:02:57
-
@@ -0,0 +1,12 @@
+$OpenBSD$
+--- modules/dbus/Ma
Re: unbreak lang/sbcl on i386
Josh Elsasser writes: > On Mon, Sep 16, 2013 at 06:06:06PM +0200, Jérémie Courrèges-Anglas wrote: >> >> Huh, I thought I had sent this mail... *shrug* > > I replied to the old mail before I saw this one. > >> - updating clisp to 2.49 >> - texlive make build and make fake work fine; pkg/PLIST changed but >> that doesn't seem to be due to the clisp update >> - updating sbcl to 1.1.11 (using clisp-2.49 as a host) >> - note: sbcl/INSTALL lists supported clisp versions: "(only some >> versions: 2.44.1 is OK, 2.47 is not)"... > > New versions of clisp occasionally break an sbcl cross-build, but > they're usually easy enough to fix. > >> - patch committed yesterday doesn't apply and isn't needed anymore > > Yep, sorry about that. Don't be sorry, if I hadn't first done this, I'm don't think I'd be working on updating clisp + sbcl right now. ;) >> - but a new struct timeval problem has been introduced in >> contrib/sb-posix/constants.lisp :) > > Oh, oops. I thought I'd tested all the contribs, but I guess not with > t64 i386. I'll see if I can get the sb-posix contrib to grovel that > struct, but patching the hardcoded definition is fine for now. > >> - two other errors in contrib/, maybe (?) linked to the one above, to >> the clisp update, or... just plain regressions > > Which contribs? The clisp update shouldn't have any effect, by the > time the build gets that far it's not cross-compiling from clisp anymore. IIRC: - asdf-install, probably due to me tripping on some patch, it looks ok now - sb-simple-streams, probably due to sb-posix fsckup I don't have the logs at hand, but they should be ok with the last diff I sent. >> dpb running on powerpc now, sbcl's make test on i386 not yet finished. >> That stuff takes a long time to build... > > Note that once you have a working sbcl package, you can build with the > native_bootstrap pseudo-flavor for a much, much quicker build. Yes, I even thought of using a bootstrap tarball that we could regen from time to time. [...] -- jca | PGP: 0x06A11494 / 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494
Re: [new] fonts/hermit-ttf
On Mon, Sep 16, 2013 at 9:23 AM, Aaron wrote: > On Mon, Sep 16, 2013 at 9:03 AM, Stuart Henderson wrote: >> On 2013/09/16 08:22, Aaron wrote: >>> Hola! >>> >>> New font: Hermit is a monospace font designed to be clear, pragmatic >>> and very readable. Its creation has been focused on programming. Every >>> glyph was carefully planned and calculated, according to defined >>> principles and rules. For this reason, Hermit is coherent and regular. >>> >>> OK? >> >> I'd probably install this as hermit.ttf rather than hermit-1.01.ttf, what do >> you think? >> > > Sounds good, I also added "# OFL 1.1" per bcallah@. New version with ttf file renamed to hermit.ttf - also added OFL version. OK?
Re: unbreak lang/sbcl on i386
On Mon, Sep 16, 2013 at 06:06:06PM +0200, Jérémie Courrèges-Anglas wrote:
>
> Huh, I thought I had sent this mail... *shrug*
I replied to the old mail before I saw this one.
> - updating clisp to 2.49
> - texlive make build and make fake work fine; pkg/PLIST changed but
> that doesn't seem to be due to the clisp update
> - updating sbcl to 1.1.11 (using clisp-2.49 as a host)
> - note: sbcl/INSTALL lists supported clisp versions: "(only some
> versions: 2.44.1 is OK, 2.47 is not)"...
New versions of clisp occasionally break an sbcl cross-build, but
they're usually easy enough to fix.
> - patch committed yesterday doesn't apply and isn't needed anymore
Yep, sorry about that.
> - but a new struct timeval problem has been introduced in
> contrib/sb-posix/constants.lisp :)
Oh, oops. I thought I'd tested all the contribs, but I guess not with
t64 i386. I'll see if I can get the sb-posix contrib to grovel that
struct, but patching the hardcoded definition is fine for now.
> - two other errors in contrib/, maybe (?) linked to the one above, to
> the clisp update, or... just plain regressions
Which contribs? The clisp update shouldn't have any effect, by the
time the build gets that far it's not cross-compiling from clisp anymore.
> dpb running on powerpc now, sbcl's make test on i386 not yet finished.
> That stuff takes a long time to build...
Note that once you have a working sbcl package, you can build with the
native_bootstrap pseudo-flavor for a much, much quicker build.
> WIP diff at the end of the mail.
They look good so far based on a quick scan, I'll take a closer look
later today.
>
> >Kenneth R Westerback writes:
> >
> >> On Sun, Sep 15, 2013 at 04:54:19PM +0200, J??r??mie Courr??ges-Anglas
> >> wrote:
> >>>
> >>> Hi folks,
> >>>
> >>> here's a diff to correct sbcl's assumptions about struct timeval on
> >>> OpenBSD i386. The second build just ended, quick testing shows no
> >>> regression. I've refreshed the existing patches while here.
> >>>
> >>> ok?
> >>
> >> That's fine with me, unless you want to earn an extra star and go
> >> to 1.11 at the same time. :-) It (1.11) compiles and regresses fine
> >> on amd64 for me, but I got distracted by other stuff and haven't
> >> tried on macppc yet.
> >
> >ACK. No promise about when I'll work on the update. Right now my
> >concern is to get a working sbcl on i386 (and powerpc - the package on
> >mirrors is from Aug 2...).
> >
> >> Ken
> >>
> >>>
> >>> Questions:
> >>> - is someone here already dealing with upstream? If no one steps up
> >>> I'll send them the patch soon (if they fix their DNS problems...)
> >
> >>> - I see subdirectories in the source code, named like "mips" or "alpha".
> >>> Has anyone analyzed the work that should be done to make this port
> >>> available on more architectures?
>
> I took a quick look, I don't think there's much to hope in this area
> right now.
>
> > [...]
>
>
> Index: lang/clisp/Makefile
> ===
> RCS file: /home/cvs/ports/lang/clisp/Makefile,v
> retrieving revision 1.43
> diff -u -p -r1.43 Makefile
> --- lang/clisp/Makefile 21 Mar 2013 08:46:32 - 1.43
> +++ lang/clisp/Makefile 16 Sep 2013 13:02:57 -
> @@ -2,10 +2,12 @@
>
> ONLY_FOR_ARCHS = amd64 i386 powerpc sparc64
>
> +# Building io.o requires more than 512MB of ram on i386
> +VMEM_WARNING = Yes
> +
> COMMENT =ANSI Common Lisp implementation
>
> -DISTNAME=clisp-2.48
> -REVISION = 3
> +DISTNAME=clisp-2.49
> CATEGORIES= lang
> HOMEPAGE=http://clisp.cons.org/
> MAINTAINER = Joshua Elsasser
> @@ -36,7 +38,6 @@ CONFIGURE_ARGS= --fsstnd=openbsd \
> --elispdir=${PREFIX}/share/emacs/site-lisp \
> --vimdir=${PREFIX}/share/doc/clisp \
> --srcdir=${WRKSRC} ${WRKBUILD}
> -CONFIGURE_ENV = ac_cv_prog_DVIPDF=''
>
> .if ${MACHINE_ARCH} == "sparc64"
> CFLAGS +=-DSAFETY=2 -DNO_ASM -mcmodel=medany
> Index: lang/clisp/distinfo
> ===
> RCS file: /home/cvs/ports/lang/clisp/distinfo,v
> retrieving revision 1.9
> diff -u -p -r1.9 distinfo
> --- lang/clisp/distinfo 7 Jan 2010 10:55:28 - 1.9
> +++ lang/clisp/distinfo 16 Sep 2013 13:02:57 -
> @@ -1,5 +1,2 @@
> -MD5 (clisp-2.48.tar.bz2) = XkxPfNz3oe9BlrmJfChxWA==
> -RMD160 (clisp-2.48.tar.bz2) = AcFQ69HkTmJ/Qd6c3IS5AmcYWnA=
> -SHA1 (clisp-2.48.tar.bz2) = 3CE+0CGU7EyLWWEYxfkrJdH1QOA=
> -SHA256 (clisp-2.48.tar.bz2) = Bbg/VghZojZ5zPwHOhKKU3f+lInXNEMaPcMu+I8MPcI=
> -SIZE (clisp-2.48.tar.bz2) = 7885098
> +SHA256 (clisp-2.49.tar.bz2) = gTL/NTr6pw5rGTZ6Ja49WkNicnnCVkfCIGQf7QD46JA=
> +SIZE (clisp-2.49.tar.bz2) = 8091011
> Index: lang/clisp/patches/patch-modules_berkeley-db_Makefile_in
>
Re: Building GCC-4.8.1 without ports
On Mon, Sep 16, 2013 at 10:02:15PM +0400, niXman wrote: > And you seem to be a rude fellow. Thank you. I have every right to be, by birth. And you're an obvious troll, since you chose to quote parts of my emails without the rest of the context. Enough said. byebye.
Re: unbreak lang/sbcl on i386
Josh Elsasser writes:
> Sorry for slacking on this, this has been fixed upstream for a short
> while now, and just needs a version bump. The only wrinkle is there's
> now an "optional" dependency on gmp at build time, and at runtime if
> one wishes to use the sb-gmp contrib module.
Grmpf, I hadn't noticed this.
> On Sun, Sep 15, 2013 at 04:54:19PM +0200, Jérémie Courrèges-Anglas wrote:
>>
>> Hi folks,
>>
>> here's a diff to correct sbcl's assumptions about struct timeval on
>> OpenBSD i386. The second build just ended, quick testing shows no
>> regression. I've refreshed the existing patches while here.
>>
>> ok?
>>
>> Questions:
>> - is someone here already dealing with upstream? If no one steps up
>> I'll send them the patch soon (if they fix their DNS problems...)
>
> Fixed upstream already, and in a fairly portable and futureproof way
> that avoids those hardcoded struct definitions.
Yup, it was nice to see it fixed cleanly.
>> - I see subdirectories in the source code, named like "mips" or "alpha".
>> Has anyone analyzed the work that should be done to make this port
>> available on more architectures?
>
> It will be a bit of work, I think. The easiest port to start with
> would be hppa,
*NoooOOooOO*
(disclaimer, if someone is smar^Wcrazy enough to fix emacs-24.3 on
hppa, be my guest).
> I think. Possibly sparc if you can squeeze sbcl into
> the virtual address space there. The alpha port of is somewhat
> special, and I think would be more work to bring up on openbsd. The
> mips port is 32-bit, so it's out unless we get a 32-bit mips platform.
Hmm, ok. :)
>> Index: Makefile
>> ===
>> RCS file: /cvs/ports/lang/sbcl/Makefile,v
>> retrieving revision 1.19
>> diff -u -p -r1.19 Makefile
>> --- Makefile 6 Sep 2013 22:16:24 - 1.19
>> +++ Makefile 15 Sep 2013 11:06:08 -
>> @@ -2,12 +2,11 @@
>>
>> # not yet ported to other arches
>> ONLY_FOR_ARCHS =amd64 i386 powerpc
>> -BROKEN-i386=build fails post-64-bit time_t
>> -# ^^ logs: http://rhaalovely.net/build-failures/i386/20130901/lang/sbcl.log
>>
>> COMMENT=compiler and runtime system for ANSI Common Lisp
>>
>> V = 1.1.8
>> +REVISION= 0
>> DISTNAME= sbcl-${V}-source
>> PKGNAME=sbcl-${V}
>> WRKDIST=${WRKDIR}/sbcl-${V}
>> Index: patches/patch-contrib_asdf-module_mk
>> ===
>> RCS file: /cvs/ports/lang/sbcl/patches/patch-contrib_asdf-module_mk,v
>> retrieving revision 1.1
>> diff -u -p -r1.1 patch-contrib_asdf-module_mk
>> --- patches/patch-contrib_asdf-module_mk 8 Jul 2011 11:42:09 -
>> 1.1
>> +++ patches/patch-contrib_asdf-module_mk 15 Sep 2013 12:11:41 -
>> @@ -5,9 +5,9 @@ Fix 'all' target to allow building witho
>> Don't copy every single file when installing the contribs, only the
>> ones that are actually needed to load the system.
>>
>> contrib/asdf-module.mk.orig Mon May 9 04:49:39 2011
>> -+++ contrib/asdf-module.mk Fri Jul 8 13:39:44 2011
>> -@@ -25,7 +25,8 @@ endif
>> +--- contrib/asdf-module.mk.orig Sun Jun 2 15:12:39 2013
>> contrib/asdf-module.mk Sun Sep 15 14:11:33 2013
>> +@@ -27,7 +27,8 @@ endif
>>
>> export CC SBCL EXTRA_CFLAGS EXTRA_LDFLAGS
>>
>> @@ -15,9 +15,9 @@ ones that are actually needed to load th
>> +all: $(EXTRA_ALL_TARGETS) $(SYSTEM).fasl
>> +$(SYSTEM).fasl:
>> $(MAKE) -C ../asdf
>> -$(SBCL) --eval '(defvar *system* "$(SYSTEM)")' --load ../asdf-stub.lisp
>> --eval '(quit)'
>> +$(SBCL) --eval '(defvar *system* "$(SYSTEM)")' --load ../asdf-stub.lisp
>> --eval '(exit)'
>>
>> -@@ -37,5 +38,4 @@ test: all
>> +@@ -40,5 +41,4 @@ test: all
>> # KLUDGE: There seems to be no portable way to tell tar to not to
>> # preserve owner, so chown after installing for the current user.
>> install: $(EXTRA_INSTALL_TARGETS)
>> Index: patches/patch-make-target-contrib_sh
>> ===
>> RCS file: /cvs/ports/lang/sbcl/patches/patch-make-target-contrib_sh,v
>> retrieving revision 1.2
>> diff -u -p -r1.2 patch-make-target-contrib_sh
>> --- patches/patch-make-target-contrib_sh 11 Aug 2012 23:02:23 -
>> 1.2
>> +++ patches/patch-make-target-contrib_sh 15 Sep 2013 01:47:04 -
>> @@ -4,9 +4,9 @@ Only run the contrib tests if $RUN_CONTR
>> allows the contribs to be build when USE_SYSTRACE=Yes, and the tests
>> to be run later in do-regress.
>>
>> make-target-contrib.sh.orig Mon Dec 5 00:09:01 2011
>> -+++ make-target-contrib.sh Sat Aug 11 16:55:34 2012
>> -@@ -43,6 +43,7 @@ export SBCL SBCL_BUILDING_CONTRIB
>> +--- make-target-contrib.sh.orig Sun Jun 2 15:12:40 2013
>> make-target-contrib.sh Sun Sep 15 03:26:47 2013
>> +@@ -44,6 +44,7 @@ export SBCL SBCL_BUILDING_CONTRIB
>> # as SB-RT and SB-GROVEL, but FIXME:
Re: SQLite 3.8.0.2 diff
On Sun, Sep 15, 2013 at 11:12:44AM +0200, Landry Breuil wrote: > On Thu, Sep 12, 2013 at 02:35:02PM -0400, James Turner wrote: > > Attached is a diff to update our in tree version of SQLite to the > > recently released 3.8.0.2. SQLite 3.8.0 is needed for a fossil update > > I'm working on. > > > > I've tested this diff against my fossil update and everything appears to > > be good, the recent arc4random addition should have been maintained > > across the diff. > > > > This should probably go through a round of bulk builds. I'll express my > > thanks now for anyone who can assist by running a bulk build on a couple > > platforms. > > Doesnt seem to cause any direct fallout in an amd64 bulk build. > Thanks for running this against a bulk build. Glad to hear it doesn't seem to have any ill effects. > At some poing mozilla will also require 3.8.x, see > https://bugzilla.mozilla.org/show_bug.cgi?id=909382. Apparently there > are still bugfixes piling on this 3.8.0.x branch.. > > And note that for mozilla, we might need to turn on the new > SQLITE_ALLOW_URI_AUTHORITY define flag at some point for > https://bugzilla.mozilla.org/show_bug.cgi?id=879133 . I dont grok all the > details here, it seems a windows only issue (profiles on a cifs network > drive) but mozilla might require that flag to be set to allow building > with systemwide sqlite. > > Landry > -- James Turner
Re: unbreak lang/sbcl on i386
On Mon, Sep 16, 2013 at 06:06:06PM +0200, J??r??mie Courr??ges-Anglas wrote:
>
> Huh, I thought I had sent this mail... *shrug*
>
> - updating clisp to 2.49
> - texlive make build and make fake work fine; pkg/PLIST changed but
> that doesn't seem to be due to the clisp update
> - updating sbcl to 1.1.11 (using clisp-2.49 as a host)
> - note: sbcl/INSTALL lists supported clisp versions: "(only some
> versions: 2.44.1 is OK, 2.47 is not)"...
> - patch committed yesterday doesn't apply and isn't needed anymore
> - but a new struct timeval problem has been introduced in
> contrib/sb-posix/constants.lisp :)
> - two other errors in contrib/, maybe (?) linked to the one above, to
> the clisp update, or... just plain regressions
>
> dpb running on powerpc now, sbcl's make test on i386 not yet finished.
> That stuff takes a long time to build...
Cool. I was starting 1.11 again and got as far as noticing that the
timestruct diff was no longer needed.
I am in awe of you figuring out clisp. I tried a few time and got lost
figuring out how to fix the weird directory reach arounds worked. :-)
I'll test when I get home from today's chores. And my current ports
build finishes.
Ken
>
> WIP diff at the end of the mail.
>
>
> >Kenneth R Westerback writes:
> >
> >> On Sun, Sep 15, 2013 at 04:54:19PM +0200, J??r??mie Courr??ges-Anglas
> >> wrote:
> >>>
> >>> Hi folks,
> >>>
> >>> here's a diff to correct sbcl's assumptions about struct timeval on
> >>> OpenBSD i386. The second build just ended, quick testing shows no
> >>> regression. I've refreshed the existing patches while here.
> >>>
> >>> ok?
> >>
> >> That's fine with me, unless you want to earn an extra star and go
> >> to 1.11 at the same time. :-) It (1.11) compiles and regresses fine
> >> on amd64 for me, but I got distracted by other stuff and haven't
> >> tried on macppc yet.
> >
> >ACK. No promise about when I'll work on the update. Right now my
> >concern is to get a working sbcl on i386 (and powerpc - the package on
> >mirrors is from Aug 2...).
> >
> >> Ken
> >>
> >>>
> >>> Questions:
> >>> - is someone here already dealing with upstream? If no one steps up
> >>> I'll send them the patch soon (if they fix their DNS problems...)
> >
> >>> - I see subdirectories in the source code, named like "mips" or "alpha".
> >>> Has anyone analyzed the work that should be done to make this port
> >>> available on more architectures?
>
> I took a quick look, I don't think there's much to hope in this area
> right now.
>
> > [...]
>
>
> Index: lang/clisp/Makefile
> ===
> RCS file: /home/cvs/ports/lang/clisp/Makefile,v
> retrieving revision 1.43
> diff -u -p -r1.43 Makefile
> --- lang/clisp/Makefile 21 Mar 2013 08:46:32 - 1.43
> +++ lang/clisp/Makefile 16 Sep 2013 13:02:57 -
> @@ -2,10 +2,12 @@
>
> ONLY_FOR_ARCHS = amd64 i386 powerpc sparc64
>
> +# Building io.o requires more than 512MB of ram on i386
> +VMEM_WARNING = Yes
> +
> COMMENT =ANSI Common Lisp implementation
>
> -DISTNAME=clisp-2.48
> -REVISION = 3
> +DISTNAME=clisp-2.49
> CATEGORIES= lang
> HOMEPAGE=http://clisp.cons.org/
> MAINTAINER = Joshua Elsasser
> @@ -36,7 +38,6 @@ CONFIGURE_ARGS= --fsstnd=openbsd \
> --elispdir=${PREFIX}/share/emacs/site-lisp \
> --vimdir=${PREFIX}/share/doc/clisp \
> --srcdir=${WRKSRC} ${WRKBUILD}
> -CONFIGURE_ENV = ac_cv_prog_DVIPDF=''
>
> .if ${MACHINE_ARCH} == "sparc64"
> CFLAGS +=-DSAFETY=2 -DNO_ASM -mcmodel=medany
> Index: lang/clisp/distinfo
> ===
> RCS file: /home/cvs/ports/lang/clisp/distinfo,v
> retrieving revision 1.9
> diff -u -p -r1.9 distinfo
> --- lang/clisp/distinfo 7 Jan 2010 10:55:28 - 1.9
> +++ lang/clisp/distinfo 16 Sep 2013 13:02:57 -
> @@ -1,5 +1,2 @@
> -MD5 (clisp-2.48.tar.bz2) = XkxPfNz3oe9BlrmJfChxWA==
> -RMD160 (clisp-2.48.tar.bz2) = AcFQ69HkTmJ/Qd6c3IS5AmcYWnA=
> -SHA1 (clisp-2.48.tar.bz2) = 3CE+0CGU7EyLWWEYxfkrJdH1QOA=
> -SHA256 (clisp-2.48.tar.bz2) = Bbg/VghZojZ5zPwHOhKKU3f+lInXNEMaPcMu+I8MPcI=
> -SIZE (clisp-2.48.tar.bz2) = 7885098
> +SHA256 (clisp-2.49.tar.bz2) = gTL/NTr6pw5rGTZ6Ja49WkNicnnCVkfCIGQf7QD46JA=
> +SIZE (clisp-2.49.tar.bz2) = 8091011
> Index: lang/clisp/patches/patch-modules_berkeley-db_Makefile_in
> ===
> RCS file: lang/clisp/patches/patch-modules_berkeley-db_Makefile_in
> diff -N lang/clisp/patches/patch-modules_berkeley-db_Makefile_in
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ lang/clisp/patches/patch-modules_berkeley-db_Makefile_in 16 Sep 2013
> 13:02:57 -
> @@ -0,0 +1,12 @@
> +$OpenBSD$
> +--- modules/berkeley-db/Makefile.in
Re: [new] fonts/hermit-ttf
Patrick, maybe play around with the anti-aliasing stuff.. Here is a new version with Juan's suggestions. On Mon, Sep 16, 2013 at 11:33 AM, patrick keshishian wrote: > On 9/16/13, Aaron wrote: >> On Mon, Sep 16, 2013 at 9:33 AM, Aaron wrote: >>> On Mon, Sep 16, 2013 at 9:23 AM, Aaron wrote: On Mon, Sep 16, 2013 at 9:03 AM, Stuart Henderson wrote: > On 2013/09/16 08:22, Aaron wrote: >> Hola! >> >> New font: Hermit is a monospace font designed to be clear, pragmatic >> and very readable. Its creation has been focused on programming. Every >> glyph was carefully planned and calculated, according to defined >> principles and rules. For this reason, Hermit is coherent and regular. >> >> OK? > > I'd probably install this as hermit.ttf rather than hermit-1.01.ttf, > what do you think? > Sounds good, I also added "# OFL 1.1" per bcallah@. >>> >>> >>> New version with ttf file renamed to hermit.ttf - also added OFL version. >>> >>> OK? >> >> >> Heeen > > Curious about this font. After looking at author's page and > examples he has up there, I am starting to wonder why this > fonts looks "soft" on my system. Any ideas? > > --patrick hermit-font.tbz Description: Binary data
Re: [new] fonts/hermit-ttf
On 9/16/13, Aaron wrote: > On Mon, Sep 16, 2013 at 9:33 AM, Aaron wrote: >> On Mon, Sep 16, 2013 at 9:23 AM, Aaron wrote: >>> On Mon, Sep 16, 2013 at 9:03 AM, Stuart Henderson >>> wrote: On 2013/09/16 08:22, Aaron wrote: > Hola! > > New font: Hermit is a monospace font designed to be clear, pragmatic > and very readable. Its creation has been focused on programming. Every > glyph was carefully planned and calculated, according to defined > principles and rules. For this reason, Hermit is coherent and regular. > > OK? I'd probably install this as hermit.ttf rather than hermit-1.01.ttf, what do you think? >>> >>> Sounds good, I also added "# OFL 1.1" per bcallah@. >> >> >> New version with ttf file renamed to hermit.ttf - also added OFL version. >> >> OK? > > > Heeen Curious about this font. After looking at author's page and examples he has up there, I am starting to wonder why this fonts looks "soft" on my system. Any ideas? --patrick
Re: Building GCC-4.8.1 without ports
Ie, we(OBSD developers/maintainers) have no time to send patches to the GCC-patches, and you have no desire to help me to send them. I understand correctly? P.S. 2013/9/16 Marc Espie: > Yes, USE THE FUCKING PORT. ... > Look, you are obviously a clueless newbie. ... > Or just shut up. And you seem to be a rude fellow. -- Regards, niXman ___ Dual-target(32 & 64-bit) MinGW compilers for 32 and 64-bit Windows: http://sourceforge.net/projects/mingwbuilds/ ___ Another online IDE: http://liveworkspace.org/
Re: UPDATE: png 1.6.5
Brad Smith wrote: > Here is an update to png 1.6.5. > > pngfix is commented out as it requires a newer zlib release. > > OK? This needs a lib minor bump because png_set_option() has been added. Otherwise, ok. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: UPDATE: boswars 2.7
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.
> Index: Makefile
> ===
> RCS file: /home/cvs/ports/games/boswars/Makefile,v
> retrieving revision 1.20
> diff -u -p -r1.20 Makefile
> --- Makefile 3 Jun 2013 02:46:57 - 1.20
> +++ Makefile 15 Sep 2013 03:26:22 -
> @@ -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 \
> @@ -37,9 +37,10 @@ pre-configure:
> ${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
> --- distinfo 12 May 2011 05:43:04 - 1.6
> +++ distinfo 15 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/6qxmPDQZ36P74
> YxU=
> -SIZE (boswars-2.6.1-src.tar.gz) = 64708620
> +SHA256 (boswars-2.7-src.tar.gz) = 3DcY9THp6kE8834TM7YqTF5p8UBVAtnFm55CRjUTXj
> 4=
> +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-SConstruct 10 Jul 2012 15:22:45 - 1.6
> +++ patches/patch-SConstruct 15 Sep 2013 01:47:23 -
> @@ -1,6 +1,6 @@
> $OpenBSD: patch-SConstruct,v 1.6 2012/07/10 15:22:45 jasper Exp $
> SConstruct.orig Sun Apr 18 20:04:54 2010
> -+++ SConstruct Mon Jul 9 19:37:51 2012
> +--- SConstruct.orig Sun 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 15 Sep 2013 03:17:31 -
> @@ -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/b
