CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: dco...@cvs.openbsd.org 2013/11/12 01:10:32 Modified files: databases/ruby-redis: Makefile distinfo databases/ruby-redis/pkg: PLIST Log message: Update to 3.0.6
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2013/11/12 01:16:52 Modified files: x11/gnome/gdm : Makefile Added files: x11/gnome/gdm/patches: patch-daemon_gdm-session_c Log message: Use g_credentials_get_unix_pid() instead of home baked function (upstream).
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2013/11/12 01:22:38 Modified files: comms/fldigi : Makefile distinfo comms/fldigi/pkg: PLIST Log message: update to fldigi-3.21.77
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2013/11/12 01:28:29 Modified files: sysutils/ruby-puppet/3: Makefile sysutils/ruby-puppet/pkg: puppetd.rc Log message: use a better regexp for the puppetd process to avoid killing every puppetd process; ok jasper@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ben...@cvs.openbsd.org 2013/11/12 03:04:42 Modified files: devel/git : Makefile distinfo Log message: Update to git 1.8.4.3.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: z...@cvs.openbsd.org2013/11/12 04:24:21 Modified files: infrastructure/bin: portcheck Log message: Remove check for files/directories named core, they are not a problem anymore. Pointed out by sthen@.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2013/11/12 04:18:38 Modified files: x11/kde4/libs : Makefile Added files: x11/kde4/libs/patches: patch-mimetypes_kde_xml Log message: Silence Unknown media type in type ... warnings by removing some fake mime types. Until upstream properly addresses this issue. ok zhuk@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2013/11/12 06:44:48 Modified files: x11/gnome/totem: Makefile Log message: sounttouch - scaletempo
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2013/11/12 07:09:54 Modified files: x11/gnome/user-share: Makefile distinfo x11/gnome/user-share/pkg: PLIST Log message: Update to gnome-user-share-3.10.1.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org 2013/11/12 08:00:25
Modified files:
audio/glyr : Makefile
devel/libgit2 : Makefile.inc
devel/libgit2/libgit2: Makefile
devel/lua-penlight: Makefile
devel/lualdoc : Makefile
devel/ninja: Makefile
www/tt-rss : Makefile
Log message:
switch github MASTER_SITES urls with the query-string hack to using
DISTFILES=myfilename{theirfilename} type syntax, using a unified DISTFILES
line so they can later be merged. ok rpe@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2013/11/12 08:57:00 Modified files: databases/openldap: Makefile distinfo Log message: update to openldap-2.4.37
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2013/11/12 09:17:58 Modified files: devel/glib2: Makefile distinfo devel/glib2/pkg: PLIST Log message: Update to glib2-2.38.2.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2013/11/12 10:10:43 Modified files: x11/gnome/totem: Makefile Added files: x11/gnome/totem/patches: patch-configure Log message: We do not need to depend on gstreamer1-plugins-bad anymore.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: fg...@cvs.openbsd.org 2013/11/12 10:55:11 Modified files: devel/startup-notification: Makefile Added files: devel/startup-notification/patches: patch-libsn_sn-monitor_c patch-libsn_sn-monitor_h Log message: Fix warnings: pass the right types for tv_sec and tv_usec. Bump. ajacoutot@ ok.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: fg...@cvs.openbsd.org 2013/11/12 11:18:52 ports/x11/compiz/ccsm Update of /cvs/ports/x11/compiz/ccsm In directory cvs.openbsd.org:/tmp/cvs-serv19779/ccsm Log Message: Directory /cvs/ports/x11/compiz/ccsm added to the repository
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: fg...@cvs.openbsd.org 2013/11/12 11:18:55 ports/x11/compiz/plugins-main Update of /cvs/ports/x11/compiz/plugins-main In directory cvs.openbsd.org:/tmp/cvs-serv19779/plugins-main Log Message: Directory /cvs/ports/x11/compiz/plugins-main added to the repository
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: fg...@cvs.openbsd.org 2013/11/12 11:18:53 ports/x11/compiz/compizconfig-python Update of /cvs/ports/x11/compiz/compizconfig-python In directory cvs.openbsd.org:/tmp/cvs-serv19779/compizconfig-python Log Message: Directory /cvs/ports/x11/compiz/compizconfig-python added to the repository
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: fg...@cvs.openbsd.org 2013/11/12 11:20:14 ports/x11/compiz/ccsm/pkg Update of /cvs/ports/x11/compiz/ccsm/pkg In directory cvs.openbsd.org:/tmp/cvs-serv18701/ccsm/pkg Log Message: Directory /cvs/ports/x11/compiz/ccsm/pkg added to the repository
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: fg...@cvs.openbsd.org 2013/11/12 11:20:22 ports/x11/compiz/bcop/patches Update of /cvs/ports/x11/compiz/bcop/patches In directory cvs.openbsd.org:/tmp/cvs-serv18701/bcop/patches Log Message: Directory /cvs/ports/x11/compiz/bcop/patches added to the repository
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: fg...@cvs.openbsd.org 2013/11/12 11:18:54 ports/x11/compiz/libcompizconfig Update of /cvs/ports/x11/compiz/libcompizconfig In directory cvs.openbsd.org:/tmp/cvs-serv19779/libcompizconfig Log Message: Directory /cvs/ports/x11/compiz/libcompizconfig added to the repository
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: fg...@cvs.openbsd.org 2013/11/12 11:18:51 ports/x11/compiz/bcop Update of /cvs/ports/x11/compiz/bcop In directory cvs.openbsd.org:/tmp/cvs-serv19779/bcop Log Message: Directory /cvs/ports/x11/compiz/bcop added to the repository
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: fg...@cvs.openbsd.org 2013/11/12 11:20:21 ports/x11/compiz/bcop/pkg Update of /cvs/ports/x11/compiz/bcop/pkg In directory cvs.openbsd.org:/tmp/cvs-serv18701/bcop/pkg Log Message: Directory /cvs/ports/x11/compiz/bcop/pkg added to the repository
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: fg...@cvs.openbsd.org 2013/11/12 11:20:18 ports/x11/compiz/libcompizconfig/pkg Update of /cvs/ports/x11/compiz/libcompizconfig/pkg In directory cvs.openbsd.org:/tmp/cvs-serv18701/libcompizconfig/pkg Log Message: Directory /cvs/ports/x11/compiz/libcompizconfig/pkg added to the repository
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: fg...@cvs.openbsd.org 2013/11/12 11:20:19 ports/x11/compiz/libcompizconfig/patches Update of /cvs/ports/x11/compiz/libcompizconfig/patches In directory cvs.openbsd.org:/tmp/cvs-serv18701/libcompizconfig/patches Log Message: Directory /cvs/ports/x11/compiz/libcompizconfig/patches added to the repository
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: fg...@cvs.openbsd.org 2013/11/12 11:20:20 ports/x11/compiz/plugins-main/pkg Update of /cvs/ports/x11/compiz/plugins-main/pkg In directory cvs.openbsd.org:/tmp/cvs-serv18701/plugins-main/pkg Log Message: Directory /cvs/ports/x11/compiz/plugins-main/pkg added to the repository
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: fg...@cvs.openbsd.org 2013/11/12 11:20:15 ports/x11/compiz/compizconfig-python/pkg Update of /cvs/ports/x11/compiz/compizconfig-python/pkg In directory cvs.openbsd.org:/tmp/cvs-serv18701/compizconfig-python/pkg Log Message: Directory /cvs/ports/x11/compiz/compizconfig-python/pkg added to the repository
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: fg...@cvs.openbsd.org 2013/11/12 11:20:17 ports/x11/compiz/compizconfig-python/patches Update of /cvs/ports/x11/compiz/compizconfig-python/patches In directory cvs.openbsd.org:/tmp/cvs-serv18701/compizconfig-python/patches Log Message: Directory /cvs/ports/x11/compiz/compizconfig-python/patches added to the repository
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: s...@cvs.openbsd.org2013/11/12 11:53:03 Modified files: devel/libftdi : Makefile distinfo devel/libftdi/patches: patch-src_ftdi_c devel/libftdi/pkg: PLIST Removed files: devel/libftdi/pkg: PFRAG.shared Log message: Update to 0.20. ok landry@; thanks sthen@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bcal...@cvs.openbsd.org 2013/11/12 12:03:10 Modified files: lang/seed7 : Makefile distinfo lang/seed7/pkg : PLIST Log message: Update lang/seed7 to 20131110. Big change is that Seed7 is no longer broken on sparc64 (I gave upstream access to one of my sparc64 boxes).
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2013/11/12 13:01:04 Modified files: archivers : Makefile Log message: +lz4
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2013/11/12 13:00:50 Log message: import ports/archivers/lz4, ok jca@ LZ4 is a very fast lossless compression algorithm, providing compression speed at 400 MB/s per core, scalable with multi-cores CPU. It also features an extremely fast decoder, with speed in multiple GB/s per core, typically reaching RAM speed limits on multi-core systems. The library is BSD-licensed. Status: Vendor Tag: sthen Release Tags: sthen_20131112 N ports/archivers/lz4/Makefile N ports/archivers/lz4/distinfo N ports/archivers/lz4/pkg/PLIST N ports/archivers/lz4/pkg/DESCR N ports/archivers/lz4/patches/patch-Makefile N ports/archivers/lz4/patches/patch-cmake_CMakeLists_txt No conflicts created by this import
Re: CVS: cvs.openbsd.org: ports
On 2013/11/12 13:00, Stuart Henderson wrote: CVSROOT: /cvs Module name: ports Changes by: st...@cvs.openbsd.org 2013/11/12 13:00:50 Log message: import ports/archivers/lz4, ok jca@ LZ4 is a very fast lossless compression algorithm, providing compression speed at 400 MB/s per core, scalable with multi-cores CPU. It also features an extremely fast decoder, with speed in multiple GB/s per core, typically reaching RAM speed limits on multi-core systems. The library is BSD-licensed. Status: Vendor Tag: sthen Release Tags: sthen_20131112 N ports/archivers/lz4/Makefile N ports/archivers/lz4/distinfo N ports/archivers/lz4/pkg/PLIST N ports/archivers/lz4/pkg/DESCR N ports/archivers/lz4/patches/patch-Makefile N ports/archivers/lz4/patches/patch-cmake_CMakeLists_txt No conflicts created by this import This was also ok benoit@.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: s...@cvs.openbsd.org2013/11/12 13:12:02 Modified files: graphics/scratch: Makefile Log message: Tidy Makefile.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bcal...@cvs.openbsd.org 2013/11/12 13:13:21 Log message: Import games/bluemoon. Blue Moon is a console-based 52-card solitaire game. ok benoit@ Status: Vendor Tag: bcallah Release Tags: bcallah_2013-Nov-12 N ports/games/bluemoon/Makefile N ports/games/bluemoon/distinfo N ports/games/bluemoon/patches/patch-bluemoon_c N ports/games/bluemoon/pkg/DESCR N ports/games/bluemoon/pkg/PLIST No conflicts created by this import
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bcal...@cvs.openbsd.org 2013/11/12 13:13:49 Modified files: games : Makefile Log message: +bluemoon
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: es...@cvs.openbsd.org 2013/11/12 15:11:50 Modified files: infrastructure/lib/DPB: PkgPath.pm PortInfo.pm Log message: redo the discovery of tree yet once again, after issues found out by naddy@ following the bsd.port.arch.mk change. Suddenly, some paths make their way into the build where they should not ! This actually comes from setting up wantbuild/wantinfo straight when building path lists. So reorganize stuff: - don't ask for more scans during straight dump-vars reading. - perform the BUILD_PACKAGES may vanish from MULTI_PACKAGES early in merge_depends. - do add appropriate wantbuild/wantinfo during actual dependency registration there, which ensures depends that got ignored will be built. This should restore proper behavior and fix long-standing semi-random behavior.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2013/11/12 15:24:57 Modified files: mail/postgrey : Makefile mail/postgrey/patches: patch-postgrey Log message: preemptively fix postgrey for taint changes in newer perl (since I just happened to run across the diff when looking for something else).
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2013/11/12 15:25:07 Modified files: mail/postgrey : distinfo Log message: regen
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bcal...@cvs.openbsd.org 2013/11/12 17:19:28 Modified files: games/bluemoon : Makefile games/bluemoon/patches: patch-bluemoon_c Log message: Use time_t instead of long long in the patch. Noticed by aja@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bcal...@cvs.openbsd.org 2013/11/12 18:10:15 Modified files: audio : Makefile Log message: +schismtracker
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bcal...@cvs.openbsd.org 2013/11/12 18:09:51 Log message: Import audio/schismtracker. Schism Tracker is a free reimplentation of the 90s tracker editor and player, Impulse Tracker. ok benoit@ Status: Vendor Tag: bcallah Release Tags: bcallah_2013-Nov-12 N ports/audio/schismtracker/Makefile N ports/audio/schismtracker/distinfo N ports/audio/schismtracker/patches/patch-modplug_snd_gm_c N ports/audio/schismtracker/pkg/PLIST N ports/audio/schismtracker/pkg/DESCR No conflicts created by this import
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bcal...@cvs.openbsd.org 2013/11/12 20:30:26 Modified files: lang/seed7 : Makefile Log message: This update also fixes the alpha build, so remove BROKEN-alpha. Thanks to merdely@ for testing.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2013/11/13 00:10:00 Modified files: x11/gnome/settings-daemon: Makefile distinfo Log message: Update to gnome-settings-daemon-3.10.2.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2013/11/13 00:13:19 Modified files: x11/gnome/tweak-tool: Makefile distinfo x11/gnome/tweak-tool/pkg: PLIST Log message: Update to gnome-tweak-tool-3.10.1.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2013/11/13 00:24:52 Modified files: x11/gnome/controlcenter: Makefile distinfo Log message: Update to gnome-control-center-3.10.2.
Re: UPDATE: libftdi
On 2013/11/11 23:02, Stuart Cassoff wrote: On 11/10/13 01:14, Stuart Cassoff wrote: Update to 0.20. Updated diff. Index: Makefile === RCS file: /cvs/ports/devel/libftdi/Makefile,v retrieving revision 1.8 diff -u -p -u -p -r1.8 Makefile --- Makefile 21 Mar 2013 08:45:15 - 1.8 +++ Makefile 12 Nov 2013 04:00:48 - @@ -4,10 +4,9 @@ COMMENT =libftdi, interface to ftdi deb CATEGORIES = devel -DISTNAME = libftdi-0.18 -REVISION = 1 +DISTNAME = libftdi-0.20 -SHARED_LIBS =ftdi15.1# 19.0 +SHARED_LIBS =ftdi15.2# 21.0 Looking at a diff between old+new source, I don't see any changes that seem to warrant bumping the shared library minor. http://www.openbsd.org/faq/ports/specialtopics.html#SharedLibs Rest looks good, I don't have any hardware to test it with but I don't see anything in the update to cause concern.
specialtopics.html#SharedLibs
- remove some a.out mentions
- adjust USE_LIBTOOL now that this is the default and talk about
CMake as well since this works in a similar way
- remove the outdated list of autoconf versions in the ports tree
and suggest that people use the version originally used in the distfile
any comments?
Index: specialtopics.html
===
RCS file: /cvs/www/faq/ports/specialtopics.html,v
retrieving revision 1.31
diff -u -p -r1.31 specialtopics.html
--- specialtopics.html 22 Jun 2013 09:58:46 - 1.31
+++ specialtopics.html 12 Nov 2013 09:00:07 -
@@ -109,9 +109,6 @@ Sometimes, it happens that a library is
internal functions happen to be visible to communicate between those files.
Those function names traditionally begin with an underscore, and are not
part of the API proper.
-p
-Note that the library naming scheme is ubiquitous on OpenBSD platforms,
-whether they be ELF or a.out.
h3Tweaking ports builds to achieve the right names/h3
Quite a few ports need tweaks to build shared libraries correctly anyways.
@@ -128,18 +125,23 @@ internal name, so you must link it with
p
On the other hand, remember that you can override ttMakefile/tt variables
from
the command line, by using ttMAKE_FLAGS/tt in the port's ttMakefile/tt.
-This is quite valuable in, for instance, libtool-based ports, which provide
-one such version variable for each library they create.
+In some cases, the program you're porting will have a simple variable which
+you can override by setting the library version in MAKE_FLAGS, for example
+ttMAKE_FLAGS= SO_VERSION=${LIBfoo_VERSION}/tt.
+In others, the port will need to be patched to make use of such a variable.
p
-The best way to handle libtool-based ports is to set
-ttUSE_LIBTOOL=Yes/tt.
-This activates the version of libtool in base, which handles most details
-automatically:
+The ports infrastructure already handles these details in libtool-based
+and CMake-based ports.
+For libtool, by default the version from the base OS is used, but in some
+cases this is insufficient and ttUSE_LIBTOOL=gnu/tt can be set.
+CMake is handled by using the ttcmake.port.mk/tt module:
+ttMODULES += devel/cmake/tt.
+In these cases, most details are handled automatically:
ul
- lilibtool looks at ttSHARED_LIBS/tt and automatically
- replaces version numbers.
- lilibtool produces a log of shared library building in
+ littSHARED_LIBS/tt is examined and version numbers are
+ automatically replaced.
+ lishared library building is logged in
tt${WRKBUILD}/shared_libs.log/tt which can be directly
included in the port's ttMakefile/tt.
/ul
@@ -444,9 +446,9 @@ Which autoconf script actually gets call
environment variable ttAUTOCONF_VERSION/tt.
Calling autoconf happens if you set ttCONFIGURE_STYLE=autoconf/tt,
together with setting ttAUTOCONF_VERSION/tt.
-Versions currently available are 2.13, 2.52, 2.54, 2.56, 2.57, 2.58,
-2.59, 2.60, 2.61, 2.62, 2.63, 2.64, 2.65, 2.67 and 2.68.
-These cover 99% of all configure scripts out there.
+In most cases, identify the version of autoconf that was used to generate
+the distributed configure script (usually obvious when reading the script)
+and use this same version yourself.
p
autoconf relies on the standard unix preprocessor m4(1).
Re: UPDATE: tklib
Stuart Cassoff s...@bell.net writes:
On 11/10/13 02:46, Stuart Cassoff wrote:
Update to 0.6.
Better quirks.
Already fixed. ;)
Index: Makefile
===
RCS file: /cvs/ports/devel/quirks/Makefile,v
retrieving revision 1.95
diff -u -p -u -p -r1.95 Makefile
--- Makefile 25 Sep 2013 07:57:37 - 1.95
+++ Makefile 12 Nov 2013 03:44:24 -
@@ -5,7 +5,7 @@ CATEGORIES = devel databases
DISTFILES =
# API.rev
-PKGNAME =quirks-1.92
+PKGNAME =quirks-1.93
PKG_ARCH = *
MAINTAINER = Marc Espie es...@openbsd.org
Index: files/Quirks.pm
===
RCS file: /cvs/ports/devel/quirks/files/Quirks.pm,v
retrieving revision 1.99
diff -u -p -u -p -r1.99 Quirks.pm
--- files/Quirks.pm 25 Sep 2013 07:57:38 - 1.99
+++ files/Quirks.pm 12 Nov 2013 03:44:24 -
@@ -322,11 +322,12 @@ my $stem_extensions = {
'php-mhash' = 'php',
'php-ncurses' = 'php',
'php-sqlite' = 'php',
- 'thttpd' = 'sthttpd',
'pecl-fileinfo' = 'php',
'thttpd' = 'sthttpd',
'dbus-python' = 'py-dbus',
'libungif' = 'giflib',
+ 'mentry' = 'tklib',
+ 'wcb' = 'tklib',
};
# -is_base_system($handle, $state):
--
jca | PGP : 0x06A11494 / 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494
Re: specialtopics.html#SharedLibs
2013/11/12 Stuart Henderson s...@spacehopper.org:
- remove some a.out mentions
- adjust USE_LIBTOOL now that this is the default and talk about
CMake as well since this works in a similar way
- remove the outdated list of autoconf versions in the ports tree
and suggest that people use the version originally used in the distfile
any comments?
Index: specialtopics.html
===
RCS file: /cvs/www/faq/ports/specialtopics.html,v
retrieving revision 1.31
diff -u -p -r1.31 specialtopics.html
--- specialtopics.html 22 Jun 2013 09:58:46 - 1.31
+++ specialtopics.html 12 Nov 2013 09:00:07 -
@@ -109,9 +109,6 @@ Sometimes, it happens that a library is
internal functions happen to be visible to communicate between those files.
Those function names traditionally begin with an underscore, and are not
part of the API proper.
-p
-Note that the library naming scheme is ubiquitous on OpenBSD platforms,
-whether they be ELF or a.out.
h3Tweaking ports builds to achieve the right names/h3
Quite a few ports need tweaks to build shared libraries correctly anyways.
@@ -128,18 +125,23 @@ internal name, so you must link it with
p
On the other hand, remember that you can override ttMakefile/tt
variables from
the command line, by using ttMAKE_FLAGS/tt in the port's
ttMakefile/tt.
-This is quite valuable in, for instance, libtool-based ports, which provide
-one such version variable for each library they create.
+In some cases, the program you're porting will have a simple variable which
+you can override by setting the library version in MAKE_FLAGS, for example
+ttMAKE_FLAGS= SO_VERSION=${LIBfoo_VERSION}/tt.
+In others, the port will need to be patched to make use of such a variable.
p
-The best way to handle libtool-based ports is to set
-ttUSE_LIBTOOL=Yes/tt.
-This activates the version of libtool in base, which handles most details
-automatically:
+The ports infrastructure already handles these details in libtool-based
+and CMake-based ports.
+For libtool, by default the version from the base OS is used, but in some
+cases this is insufficient and ttUSE_LIBTOOL=gnu/tt can be set.
+CMake is handled by using the ttcmake.port.mk/tt module:
+ttMODULES += devel/cmake/tt.
+In these cases, most details are handled automatically:
ul
- lilibtool looks at ttSHARED_LIBS/tt and automatically
- replaces version numbers.
- lilibtool produces a log of shared library building in
+ littSHARED_LIBS/tt is examined and version numbers are
+ automatically replaced.
+ lishared library building is logged in
tt${WRKBUILD}/shared_libs.log/tt which can be directly
included in the port's ttMakefile/tt.
/ul
@@ -444,9 +446,9 @@ Which autoconf script actually gets call
environment variable ttAUTOCONF_VERSION/tt.
Calling autoconf happens if you set ttCONFIGURE_STYLE=autoconf/tt,
together with setting ttAUTOCONF_VERSION/tt.
-Versions currently available are 2.13, 2.52, 2.54, 2.56, 2.57, 2.58,
-2.59, 2.60, 2.61, 2.62, 2.63, 2.64, 2.65, 2.67 and 2.68.
-These cover 99% of all configure scripts out there.
+In most cases, identify the version of autoconf that was used to generate
+the distributed configure script (usually obvious when reading the script)
+and use this same version yourself.
p
autoconf relies on the standard unix preprocessor m4(1).
Reads fine for me.
--
WBR,
Vadim Zhukov
SOGo mail bundles not loading
Hi, When trying to use SOGo I'm getting the following error after logging in: An error occurred during object publishing the requested object could not be found! In the SOGo log file the following messages are given: Nov 12 11:20:16 sogod [6583]: 0x0x1c37d07be3c8[SOGoProductLoader] AdministrationUI.SOGo, Appointments.SOGo, CommonUI.SOGo, Contacts.SOGo, ContactsUI.SOGo, MailPartViewers.SOGo, Mailer.SOGo, MailerUI.SOGo, MainUI.SOGo, PreferencesUI.SOGo, SchedulerUI.SOGo /usr/local/sbin/sogod:/usr/local/lib/GNUstep/SOGo/MailPartViewers.SOGo/./MailPartViewers: undefined symbol '__objc_class_name_SOGoMailBodyPart' /usr/local/sbin/sogod:/usr/local/lib/GNUstep/SOGo/MailPartViewers.SOGo/./MailPartViewers: undefined symbol '__objc_class_name_SOGoAppointmentObject' Nov 12 11:20:16 sogod [6583]: [so-product-registry] could not load product: MailPartViewers /usr/local/sbin/sogod:/usr/local/lib/GNUstep/SOGo/MailerUI.SOGo/./MailerUI: undefined symbol '__objc_class_name_UIxMailRenderingContext' Nov 12 11:20:16 sogod [6583]: [so-product-registry] could not load product: MailerUI On the SOGo bug tracking system I've found a similar error (http://www.sogo.nu/bugs/view.php?id=2327). Unfortunately ludovic marked it as won't fix since the OP should use the SOGo version of GNUstep. Any ideas how to fix this? OS: OpenBSD 5.4-stable Arch: amd64 Sogo: sogo-2.0.5.0p0 Sope: sope-2.0.5.0 GNUstep: gnustep-base-1.24.4p0, gnustep-make-2.6.4 Kind regards, Martijn Rijkeboer
Re: specialtopics.html#SharedLibs
On Tue, Nov 12, 2013 at 10:55 AM, Vadim Zhukov persg...@gmail.com wrote:
2013/11/12 Stuart Henderson s...@spacehopper.org:
- remove some a.out mentions
- adjust USE_LIBTOOL now that this is the default and talk about
CMake as well since this works in a similar way
- remove the outdated list of autoconf versions in the ports tree
and suggest that people use the version originally used in the distfile
any comments?
Index: specialtopics.html
===
RCS file: /cvs/www/faq/ports/specialtopics.html,v
retrieving revision 1.31
diff -u -p -r1.31 specialtopics.html
--- specialtopics.html 22 Jun 2013 09:58:46 - 1.31
+++ specialtopics.html 12 Nov 2013 09:00:07 -
@@ -109,9 +109,6 @@ Sometimes, it happens that a library is
internal functions happen to be visible to communicate between those files.
Those function names traditionally begin with an underscore, and are not
part of the API proper.
-p
-Note that the library naming scheme is ubiquitous on OpenBSD platforms,
-whether they be ELF or a.out.
h3Tweaking ports builds to achieve the right names/h3
Quite a few ports need tweaks to build shared libraries correctly anyways.
@@ -128,18 +125,23 @@ internal name, so you must link it with
p
On the other hand, remember that you can override ttMakefile/tt
variables from
the command line, by using ttMAKE_FLAGS/tt in the port's
ttMakefile/tt.
-This is quite valuable in, for instance, libtool-based ports, which provide
-one such version variable for each library they create.
+In some cases, the program you're porting will have a simple variable which
+you can override by setting the library version in MAKE_FLAGS, for example
+ttMAKE_FLAGS= SO_VERSION=${LIBfoo_VERSION}/tt.
+In others, the port will need to be patched to make use of such a variable.
p
-The best way to handle libtool-based ports is to set
-ttUSE_LIBTOOL=Yes/tt.
-This activates the version of libtool in base, which handles most details
-automatically:
+The ports infrastructure already handles these details in libtool-based
+and CMake-based ports.
+For libtool, by default the version from the base OS is used, but in some
+cases this is insufficient and ttUSE_LIBTOOL=gnu/tt can be set.
+CMake is handled by using the ttcmake.port.mk/tt module:
+ttMODULES += devel/cmake/tt.
+In these cases, most details are handled automatically:
ul
- lilibtool looks at ttSHARED_LIBS/tt and automatically
- replaces version numbers.
- lilibtool produces a log of shared library building in
+ littSHARED_LIBS/tt is examined and version numbers are
+ automatically replaced.
+ lishared library building is logged in
tt${WRKBUILD}/shared_libs.log/tt which can be directly
included in the port's ttMakefile/tt.
/ul
@@ -444,9 +446,9 @@ Which autoconf script actually gets call
environment variable ttAUTOCONF_VERSION/tt.
Calling autoconf happens if you set ttCONFIGURE_STYLE=autoconf/tt,
together with setting ttAUTOCONF_VERSION/tt.
-Versions currently available are 2.13, 2.52, 2.54, 2.56, 2.57, 2.58,
-2.59, 2.60, 2.61, 2.62, 2.63, 2.64, 2.65, 2.67 and 2.68.
-These cover 99% of all configure scripts out there.
+In most cases, identify the version of autoconf that was used to generate
+the distributed configure script (usually obvious when reading the script)
+and use this same version yourself.
p
autoconf relies on the standard unix preprocessor m4(1).
Reads fine for me.
ok for me too.
ciao,
David
Re: Fix for quvi-scripts and youtube
Dmitrij D. Czarkoff said:
Aparently there were more missing dependencies: devel/luabitop,
textproc/luaexpat and currently missing from ports devel/luajson, which
in turn requires lunit for test target.
Updated patch. New ports re-attached.
--
Dmitrij D. Czarkoff
Index: Makefile
===
RCS file: /var/cvs/ports/net/quvi/scripts/Makefile,v
retrieving revision 1.13
diff -u -p -r1.13 Makefile
--- Makefile11 Nov 2013 14:56:46 - 1.13
+++ Makefile12 Nov 2013 03:46:54 -
@@ -7,10 +7,14 @@ COMMENT = scripts libquvi uses for parsi
V =0.9.20131104
DISTNAME = libquvi-scripts-${V}
SUBST_VARS += V
+REVISION = 0
MODULES = lang/lua
-RUN_DEPENDS = net/luasocket
+RUN_DEPENDS = devel/luabitop \
+ devel/luajson \
+ net/luasocket \
+ textproc/luaexpat
CONFIGURE_ARGS=--with-nsfw
luajson.tar.gz
Description: application/tar-gz
lunit.tar.gz
Description: application/tar-gz
switch github MASTER_SITES url hack to DISTFILES
This replaces the current users of the github MASTER_SITES hack
(archive/${V}.tar.gz?bleh=/) to the new format with DISTFILES=...{...}.
I use some slightly awkward looking ${GH_VER:S/v//} constructs in a
couple of ports, which aren't strictly necessary here, but doing it this
way means we have a common DISTFILES line that can be later unified into
a module or infrastructure/ file (some projects include 'v' in their
tags and others don't).
I've tested 'make clean=dist; make makesum' and checked there are no
changes to distinfo files. (I'll also note that the MASTER_SITE_BACKUP
handling might not handle files using this syntax..)
Comments? OK?
Index: audio/glyr/Makefile
===
RCS file: /cvs/ports/audio/glyr/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 Makefile
--- audio/glyr/Makefile 11 Aug 2013 14:59:54 - 1.1.1.1
+++ audio/glyr/Makefile 12 Nov 2013 12:24:44 -
@@ -1,8 +1,8 @@
# $OpenBSD: Makefile,v 1.1.1.1 2013/08/11 14:59:54 landry Exp $
COMMENT = music related metadata searchengine
-V =1.0.1
-DISTNAME = glyr-${V}
+GH_VER = 1.0.1
+DISTNAME = glyr-${GH_VER}
CATEGORIES = audio net
SHARED_LIBS += glyr0.0 # 1.1
@@ -11,7 +11,8 @@ HOMEPAGE =https://github.com/sahib/glyr
# GPLv3+
PERMIT_PACKAGE_CDROM = Yes
-MASTER_SITES = https://github.com/sahib/glyr/archive/${V}.tar.gz?bleh=/
+MASTER_SITES = https://github.com/sahib/glyr/archive/
+DISTFILES= ${DISTNAME}${EXTRACT_SUFX}{${GH_VER}${EXTRACT_SUFX}}
MODULES = devel/cmake \
devel/gettext
Index: devel/libgit2/Makefile.inc
===
RCS file: /cvs/ports/devel/libgit2/Makefile.inc,v
retrieving revision 1.8
diff -u -p -r1.8 Makefile.inc
--- devel/libgit2/Makefile.inc 7 Aug 2013 21:57:45 - 1.8
+++ devel/libgit2/Makefile.inc 12 Nov 2013 12:24:44 -
@@ -9,6 +9,5 @@ HOMEPAGE= http://libgit2.github.com/
# GPLv2 with linking exemption.
PERMIT_PACKAGE_CDROM?= Yes
-MASTER_SITES?=
https://github.com/libgit2/${PROJECT}/archive/v${V}.tar.gz?dummy=/
DIST_SUBDIR= libgit
DISTNAME?= ${PROJECT}-${V}
Index: devel/libgit2/libgit2/Makefile
===
RCS file: /cvs/ports/devel/libgit2/libgit2/Makefile,v
retrieving revision 1.10
diff -u -p -r1.10 Makefile
--- devel/libgit2/libgit2/Makefile 9 Jul 2013 10:09:44 - 1.10
+++ devel/libgit2/libgit2/Makefile 12 Nov 2013 12:24:44 -
@@ -2,10 +2,14 @@
COMMENT= the Git library, take 2
-V= 0.19.0
+GH_VER=v0.19.0
+V= ${GH_VER:S/v//}
PROJECT= libgit2
REVISION= 0
SHARED_LIBS += git2 4.0 # 0.19
+
+MASTER_SITES= https://github.com/libgit2/${PROJECT}/archive/
+DISTFILES= ${DISTNAME}${EXTRACT_SUFX}{${GH_VER}${EXTRACT_SUFX}}
MODULES= devel/cmake \
lang/python
Index: devel/lua-penlight/Makefile
===
RCS file: /cvs/ports/devel/lua-penlight/Makefile,v
retrieving revision 1.5
diff -u -p -r1.5 Makefile
--- devel/lua-penlight/Makefile 30 Sep 2013 13:04:06 - 1.5
+++ devel/lua-penlight/Makefile 12 Nov 2013 12:24:44 -
@@ -2,9 +2,9 @@
COMMENT = pure Lua libraries focusing on input data handling
-VER = 1.3.1
-DISTNAME = Penlight-${VER}
-PKGNAME = lua-penlight-${VER}
+GH_VER = 1.3.1
+DISTNAME = Penlight-${GH_VER}
+PKGNAME = lua-penlight-${GH_VER}
CATEGORIES = devel
HOMEPAGE = http://stevedonovan.github.io/Penlight/
@@ -16,7 +16,8 @@ PERMIT_PACKAGE_CDROM =Yes
MODULES = lang/lua
-MASTER_SITES =
https://github.com/stevedonovan/Penlight/archive/${VER}.tar.gz?bleh=/
+MASTER_SITES = https://github.com/stevedonovan/Penlight/archive/
+DISTFILES= ${DISTNAME}${EXTRACT_SUFX}{${GH_VER}${EXTRACT_SUFX}}
MODLUA_RUN_DEPENDS = devel/luafs
Index: devel/lualdoc/Makefile
===
RCS file: /cvs/ports/devel/lualdoc/Makefile,v
retrieving revision 1.5
diff -u -p -r1.5 Makefile
--- devel/lualdoc/Makefile 23 Sep 2013 14:11:12 - 1.5
+++ devel/lualdoc/Makefile 12 Nov 2013 12:24:44 -
@@ -2,9 +2,9 @@
COMMENT = LuaDoc-compatible documentation generation system
-VER = 1.4.0
-DISTNAME = LDoc-${VER}
-PKGNAME = lualdoc-${VER}
+GH_VER = 1.4.0
+DISTNAME = LDoc-${GH_VER}
+PKGNAME = lualdoc-${GH_VER}
CATEGORIES = devel
HOMEPAGE = http://stevedonovan.github.io/ldoc/
@@ -16,7 +16,8 @@ PERMIT_PACKAGE_CDROM =Yes
MODULES = lang/lua
-MASTER_SITES =
https://github.com/stevedonovan/ldoc/archive/${VER}.tar.gz?bleh=/
+MASTER_SITES =
[was tech@] Re: httpd and nginx in base
On 13-11-11 07:06 PM, Stuart Henderson wrote: Help identify which ports currently rely on Apache from base, work out which ones can use nginx and move them across (updating READMEs etc where necessary), which can use apache2 from ports and move them across, and which (if any) won't work with either of these and require a port of the modified apache from base. Re this... We could do with some directory under /etc/nginx that ports can use as a common place to install config fragments (that the use can then include in nginx.conf), somewhat similar to /var/www/conf/modules.sample (but no need for the symlink mechanism, having the user manually include them makes more sense for nginx) and similar to debian's sites-available.. Doesn't necessarily need to be in base's mtree (just using the same directory in all ports would be enough), though it might make sense..
NEW: games/bluemoon
Hi ports -- Attached is a new port, Blue Moon. Blue Moon is a console-based 52-card solitaire game. Works for me on amd64, loongson, and macppc. OK? ~Brian bluemoon.tgz Description: application/compressed-tar
Re: UPDATE: libftdi
On 11/12/13 03:42, Stuart Henderson wrote: On 2013/11/11 23:02, Stuart Cassoff wrote: On 11/10/13 01:14, Stuart Cassoff wrote: Update to 0.20. Updated diff. Index: Makefile === RCS file: /cvs/ports/devel/libftdi/Makefile,v retrieving revision 1.8 diff -u -p -u -p -r1.8 Makefile --- Makefile 21 Mar 2013 08:45:15 - 1.8 +++ Makefile 12 Nov 2013 04:00:48 - @@ -4,10 +4,9 @@ COMMENT = libftdi, interface to ftdi deb CATEGORIES =devel -DISTNAME = libftdi-0.18 -REVISION = 1 +DISTNAME = libftdi-0.20 -SHARED_LIBS = ftdi15.1# 19.0 +SHARED_LIBS = ftdi15.2# 21.0 Looking at a diff between old+new source, I don't see any changes that seem to warrant bumping the shared library minor. Ok. I thought there were some new functions added but I was mistaken. No lib bump, then. Stu
Re: [was tech@] Re: httpd and nginx in base
On Tue, Nov 12, 2013 at 03:49:35PM +, Stuart Henderson wrote: On 13-11-11 07:06 PM, Stuart Henderson wrote: Help identify which ports currently rely on Apache from base, work out which ones can use nginx and move them across (updating READMEs etc where necessary), which can use apache2 from ports and move them across, and which (if any) won't work with either of these and require a port of the modified apache from base. Re this... We could do with some directory under /etc/nginx that ports can use as a common place to install config fragments (that the use can then include in nginx.conf), somewhat similar to /var/www/conf/modules.sample (but no need for the symlink mechanism, having the user manually include them makes more sense for nginx) and similar to debian's sites-available.. Doesn't necessarily need to be in base's mtree (just using the same directory in all ports would be enough), though it might make sense.. +1 jbelka
Re: switch github MASTER_SITES url hack to DISTFILES
On Tue, November 12, 2013 16:29, Stuart Henderson wrote:
This replaces the current users of the github MASTER_SITES hack
(archive/${V}.tar.gz?bleh=/) to the new format with DISTFILES=...{...}.
I use some slightly awkward looking ${GH_VER:S/v//} constructs in a
couple of ports, which aren't strictly necessary here, but doing it this
way means we have a common DISTFILES line that can be later unified into
a module or infrastructure/ file (some projects include 'v' in their
tags and others don't).
I've tested 'make clean=dist; make makesum' and checked there are no
changes to distinfo files. (I'll also note that the MASTER_SITE_BACKUP
handling might not handle files using this syntax..)
Comments? OK?
I like it, except V=${GH_VER:S/v//} thing. May be we can remove leading v
(if it occurs) somewhere in bsd.port.mk?
Index: audio/glyr/Makefile
===
RCS file: /cvs/ports/audio/glyr/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 Makefile
--- audio/glyr/Makefile 11 Aug 2013 14:59:54 - 1.1.1.1
+++ audio/glyr/Makefile 12 Nov 2013 12:24:44 -
@@ -1,8 +1,8 @@
# $OpenBSD: Makefile,v 1.1.1.1 2013/08/11 14:59:54 landry Exp $
COMMENT =music related metadata searchengine
-V = 1.0.1
-DISTNAME = glyr-${V}
+GH_VER = 1.0.1
+DISTNAME = glyr-${GH_VER}
CATEGORIES = audio net
SHARED_LIBS += glyr0.0 # 1.1
@@ -11,7 +11,8 @@ HOMEPAGE = https://github.com/sahib/glyr
# GPLv3+
PERMIT_PACKAGE_CDROM = Yes
-MASTER_SITES = https://github.com/sahib/glyr/archive/${V}.tar.gz?bleh=/
+MASTER_SITES = https://github.com/sahib/glyr/archive/
+DISTFILES= ${DISTNAME}${EXTRACT_SUFX}{${GH_VER}${EXTRACT_SUFX}}
MODULES =devel/cmake \
devel/gettext
Index: devel/libgit2/Makefile.inc
===
RCS file: /cvs/ports/devel/libgit2/Makefile.inc,v
retrieving revision 1.8
diff -u -p -r1.8 Makefile.inc
--- devel/libgit2/Makefile.inc7 Aug 2013 21:57:45 - 1.8
+++ devel/libgit2/Makefile.inc12 Nov 2013 12:24:44 -
@@ -9,6 +9,5 @@ HOMEPAGE= http://libgit2.github.com/
# GPLv2 with linking exemption.
PERMIT_PACKAGE_CDROM?= Yes
-MASTER_SITES?=
https://github.com/libgit2/${PROJECT}/archive/v${V}.tar.gz?dummy=/
DIST_SUBDIR= libgit
DISTNAME?= ${PROJECT}-${V}
Index: devel/libgit2/libgit2/Makefile
===
RCS file: /cvs/ports/devel/libgit2/libgit2/Makefile,v
retrieving revision 1.10
diff -u -p -r1.10 Makefile
--- devel/libgit2/libgit2/Makefile9 Jul 2013 10:09:44 - 1.10
+++ devel/libgit2/libgit2/Makefile12 Nov 2013 12:24:44 -
@@ -2,10 +2,14 @@
COMMENT= the Git library, take 2
-V= 0.19.0
+GH_VER= v0.19.0
+V= ${GH_VER:S/v//}
PROJECT= libgit2
REVISION=0
SHARED_LIBS += git2 4.0 # 0.19
+
+MASTER_SITES=https://github.com/libgit2/${PROJECT}/archive/
+DISTFILES= ${DISTNAME}${EXTRACT_SUFX}{${GH_VER}${EXTRACT_SUFX}}
MODULES= devel/cmake \
lang/python
Index: devel/lua-penlight/Makefile
===
RCS file: /cvs/ports/devel/lua-penlight/Makefile,v
retrieving revision 1.5
diff -u -p -r1.5 Makefile
--- devel/lua-penlight/Makefile 30 Sep 2013 13:04:06 - 1.5
+++ devel/lua-penlight/Makefile 12 Nov 2013 12:24:44 -
@@ -2,9 +2,9 @@
COMMENT =pure Lua libraries focusing on input data handling
-VER =1.3.1
-DISTNAME = Penlight-${VER}
-PKGNAME =lua-penlight-${VER}
+GH_VER = 1.3.1
+DISTNAME = Penlight-${GH_VER}
+PKGNAME =lua-penlight-${GH_VER}
CATEGORIES = devel
HOMEPAGE = http://stevedonovan.github.io/Penlight/
@@ -16,7 +16,8 @@ PERMIT_PACKAGE_CDROM =Yes
MODULES =lang/lua
-MASTER_SITES
= https://github.com/stevedonovan/Penlight/archive/${VER}.tar.gz?bleh=/
+MASTER_SITES = https://github.com/stevedonovan/Penlight/archive/
+DISTFILES= ${DISTNAME}${EXTRACT_SUFX}{${GH_VER}${EXTRACT_SUFX}}
MODLUA_RUN_DEPENDS = devel/luafs
Index: devel/lualdoc/Makefile
===
RCS file: /cvs/ports/devel/lualdoc/Makefile,v
retrieving revision 1.5
diff -u -p -r1.5 Makefile
--- devel/lualdoc/Makefile23 Sep 2013 14:11:12 - 1.5
+++ devel/lualdoc/Makefile12 Nov 2013 12:24:44 -
@@ -2,9 +2,9 @@
COMMENT =LuaDoc-compatible documentation generation system
-VER =1.4.0
-DISTNAME = LDoc-${VER}
-PKGNAME =lualdoc-${VER}
+GH_VER = 1.4.0
+DISTNAME = LDoc-${GH_VER}
+PKGNAME =
Re: new: net/bitcoin
On Sat, Jan 12, 2013 at 9:47 AM, David Hill dh...@mindcry.org wrote: On Sun, Dec 09, 2012 at 05:09:56PM +0100, Pascal Stumpf wrote: :On Sat, 26 May 2012 15:44:31 +0200, Pascal Stumpf wrote: : Bitcoin is an experimental new digital currency that enables instant : payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer : technology to operate with no central authority: managing transactions : and issuing money are carried out collectively by the network. : Bitcoin is also the name of the open source software which enables : the use of this currency. : : : Of course, mining is not very efficient on OpenBSD, but it is still : useful to manage your wallet, make transactions etc. : : :Updated port attached (0.7.1), latest update done by Alex Bula. : :ok? Updated your port to 0.7.2 and successfully using it on i386. Attached is the tarball. Updated to 0.8.5 - working great on amd64. FWIW I can't reproduce the deleting /dev/null issue. bitcoin.tar.gz Description: GNU Zip compressed data
NEW: archivers/lz4
Anyone interested in a fast BSD-licensed compression library? -- -- LZ4 is a very fast lossless compression algorithm, providing compression speed at 400 MB/s per core, scalable with multi-cores CPU. It also features an extremely fast decoder, with speed in multiple GB/s per core, typically reaching RAM speed limits on multi-core systems. The library is BSD-licensed. -- -- Tested on amd64 and macppc so far.. Any more tests? OK to import? lz4.tgz Description: application/tar-gz
Re: [was tech@] Re: httpd and nginx in base
On Tue, November 12, 2013 19:49, Stuart Henderson wrote: On 13-11-11 07:06 PM, Stuart Henderson wrote: Help identify which ports currently rely on Apache from base, work out which ones can use nginx and move them across (updating READMEs etc where necessary), which can use apache2 from ports and move them across, and which (if any) won't work with either of these and require a port of the modified apache from base. Re this... We could do with some directory under /etc/nginx that ports can use as a common place to install config fragments (that the use can then include in nginx.conf), somewhat similar to /var/www/conf/modules.sample (but no need for the symlink mechanism, having the user manually include them makes more sense for nginx) and similar to debian's sites-available.. I thought symlink mechanism helps you to keep config fragment in sync, until you customize it. As for me, this should be done like php modules ini and apache module configs - with the help of symlinks and not copying this configuration chunks. This way or another, but we need some infrastructure for nginx config samples to encourage porters to test their webstuff with nginx without unneeded pain. Just my 0.02 RUR. Doesn't necessarily need to be in base's mtree (just using the same directory in all ports would be enough), though it might make sense..
Re: [was tech@] Re: httpd and nginx in base
On 2013/11/12 22:35, Kirill Bychkov wrote:
On Tue, November 12, 2013 19:49, Stuart Henderson wrote:
On 13-11-11 07:06 PM, Stuart Henderson wrote:
Help identify which ports currently rely on Apache from base, work out
which ones can use nginx and move them across (updating READMEs etc
where
necessary), which can use apache2 from ports and move them across, and
which (if any) won't work with either of these and require a port of
the modified apache from base.
Re this...
We could do with some directory under /etc/nginx that ports can use as a
common place to install config fragments (that the use can then include in
nginx.conf), somewhat similar to /var/www/conf/modules.sample (but no
need for the symlink mechanism, having the user manually include them
makes more sense for nginx) and similar to debian's sites-available..
I thought symlink mechanism helps you to keep config fragment in sync, until
you customize it.
As for me, this should be done like php modules ini and apache module configs
- with the help of symlinks and not copying this configuration chunks.
I'm not suggesting that people should copy the chunks to nginx.conf,
but use the include keyword.
So the file would be @sampled into (for example) /etc/nginx/includes
so it would be kept in-sync unless edited, but since we don't have
anything like Apache's directory blocks in nginx, the config
fragments need to be included within the correct part of nginx.conf,
so the file might a block like this,
location = ... {
some config
}
and then we tell people in a README to add include includes/somefile.conf
within the server block for the relevant host.
This way or another, but we need some infrastructure for nginx config samples
to encourage porters to test their webstuff with nginx without unneeded pain.
Just my 0.02 RUR.
I'm hoping that if we have some kind of framework, people can start
fitting things into it, it should be easier when we have some examples in
the ports tree.
Re: new: net/bitcoin
On 11/12/13 18:31, Aaron wrote: On Sat, Jan 12, 2013 at 9:47 AM, David Hill dh...@mindcry.org wrote: On Sun, Dec 09, 2012 at 05:09:56PM +0100, Pascal Stumpf wrote: :On Sat, 26 May 2012 15:44:31 +0200, Pascal Stumpf wrote: : Bitcoin is an experimental new digital currency that enables instant : payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer : technology to operate with no central authority: managing transactions : and issuing money are carried out collectively by the network. : Bitcoin is also the name of the open source software which enables : the use of this currency. : : : Of course, mining is not very efficient on OpenBSD, but it is still : useful to manage your wallet, make transactions etc. : : :Updated port attached (0.7.1), latest update done by Alex Bula. : :ok? Updated your port to 0.7.2 and successfully using it on i386. Attached is the tarball. Updated to 0.8.5 - working great on amd64. FWIW I can't reproduce the deleting /dev/null issue. Hi Aaron, Thanks for the port - I can confirm that it is working well on amd64: port:fred ~ bitcoind -?|head -1 Bitcoin version v0.8.5.0-gef14a26-beta port:fred ~ dmesg|head -4 OpenBSD 5.4-current (GENERIC.MP) #117: Sun Nov 3 11:37:42 MST 2013 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8447131648 (8055MB) avail mem = 8214102016 (7833MB) Cheers Fred
Re: [was tech@] Re: httpd and nginx in base
On Wed, November 13, 2013 00:10, Stuart Henderson wrote:
On 2013/11/12 22:35, Kirill Bychkov wrote:
On Tue, November 12, 2013 19:49, Stuart Henderson wrote:
On 13-11-11 07:06 PM, Stuart Henderson wrote:
Help identify which ports currently rely on Apache from base, work out
which ones can use nginx and move them across (updating READMEs etc
where
necessary), which can use apache2 from ports and move them across, and
which (if any) won't work with either of these and require a port of
the modified apache from base.
Re this...
We could do with some directory under /etc/nginx that ports can use as a
common place to install config fragments (that the use can then include
in
nginx.conf), somewhat similar to /var/www/conf/modules.sample (but no
need for the symlink mechanism, having the user manually include them
makes more sense for nginx) and similar to debian's sites-available..
I thought symlink mechanism helps you to keep config fragment in sync, until
you customize it.
As for me, this should be done like php modules ini and apache module
configs
- with the help of symlinks and not copying this configuration chunks.
I'm not suggesting that people should copy the chunks to nginx.conf,
but use the include keyword.
Sorry, didn't get it at first.
So the file would be @sampled into (for example) /etc/nginx/includes
so it would be kept in-sync unless edited, but since we don't have
anything like Apache's directory blocks in nginx, the config
fragments need to be included within the correct part of nginx.conf,
so the file might a block like this,
location = ... {
some config
}
and then we tell people in a README to add include includes/somefile.conf
within the server block for the relevant host.
This way or another, but we need some infrastructure for nginx config
samples
to encourage porters to test their webstuff with nginx without unneeded
pain.
Just my 0.02 RUR.
I'm hoping that if we have some kind of framework, people can start
fitting things into it, it should be easier when we have some examples in
the ports tree.
+1
So, the first step is to create /etc/nginx/includes, add it to mtree and make
some changes in nginx and ports documentation?
