CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2014/06/19 02:38:31 Modified files: mail/cyrus-imapd: Makefile mail/cyrus-imapd/patches: patch-imap_mailbox_c Added files: mail/cyrus-imapd/patches: patch-imap_sync_client_c Log message: One more time_t patch and merge with pkgsrc. tested by nl3dee, thanks
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2014/06/19 02:40:22 Modified files: mail/cyrus-imapd: Tag: OPENBSD_5_5 Makefile Added files: mail/cyrus-imapd/patches: Tag: OPENBSD_5_5 patch-imap_mailbox_c patch-imap_sync_client_c Log message: Fix crasher in mail delivery due to time_t expected to be 32-bits. tested by nl3dee, thanks
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2014/06/19 02:49:00 Modified files: geo/geoclue2 : Makefile distinfo Log message: update to geoclue2-2.1.9
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2014/06/19 05:20:29 Modified files: geo/geoclue2 : Makefile Log message: Drop dependency on wpa_supplicant. It requires DBus support in wpa_supplicant and according to sthen@ ours is crippled in other ways anyway... so not worth the pain. ok jasper@ (maintainer)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2014/06/19 06:27:39 Modified files: sysutils/ruby-puppet/3/patches: patch-lib_puppet_defaults_rb Log message: regen, no pkg change
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2014/06/19 06:28:34 Modified files: sysutils/ruby-puppet/3: Makefile sysutils/ruby-puppet/3/patches: patch-lib_puppet_provider_service_openbsd_rb Log message: sync with upstream pull request
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2014/06/19 07:48:44 Modified files: sysutils/cfengine: Makefile Log message: update MASTER_SITES, from Jiri B
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2014/06/19 07:56:10 Modified files: sysutils/ruby-facter: Makefile sysutils/ruby-facter/patches: patch-lib_facter_memory_rb Added files: sysutils/ruby-facter/patches: patch-lib_facter_util_memory_rb Log message: remove local re-implementation of swap{free,size} and unbreak the implementation from Facter::Memory.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: giova...@cvs.openbsd.org2014/06/19 08:43:05 Modified files: infrastructure/db: systrace.filter Log message: Fix ports builds with systrace after minherit addition and sort entries ok jca@ sthen@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2014/06/19 09:21:53 Modified files: security/stegdetect/patches: patch-f5_c Log message: forced whitespace-only commit to test a theory about cvsync
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2014/06/19 12:40:00 Modified files: meta/haskell-platform: Makefile Log message: Adjust haddock version number mentioned in a comment.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2014/06/19 12:58:02 Modified files: archivers/hs-zlib: Makefile devel/alex : Makefile devel/cabal-install: Makefile devel/haddock : Makefile devel/happy: Makefile devel/hs-HUnit : Makefile devel/hs-QuickCheck: Makefile devel/hs-async : Makefile devel/hs-case-insensitive: Makefile devel/hs-fgl : Makefile devel/hs-hashable: Makefile devel/hs-mtl : Makefile devel/hs-network: Makefile devel/hs-parallel: Makefile devel/hs-parsec: Makefile devel/hs-primitive: Makefile devel/hs-random: Makefile devel/hs-regex-base: Makefile devel/hs-regex-compat: Makefile devel/hs-regex-posix: Makefile devel/hs-split : Makefile devel/hs-stm : Makefile devel/hs-syb : Makefile devel/hs-text : Makefile devel/hs-transformers: Makefile devel/hs-unordered-containers: Makefile devel/hs-vector: Makefile graphics/hs-GLURaw: Makefile graphics/hs-GLUT: Makefile graphics/hs-OpenGL: Makefile graphics/hs-OpenGLRaw: Makefile lang/ghc : ghc.port.mk lang/hs-haskell-src: Makefile net/hs-HTTP: Makefile textproc/hs-attoparsec: Makefile www/hs-cgi : Makefile www/hs-html: Makefile Log message: Add comments to ports which meta/haskell-platform depends on, to stop other people wasting time on updates which should not be done. ian@ ran into this (while working on devel/hs-aeson and textproc/hs-attoparsec), and even I didn't notice before trying to build all Haskell ports (including meta/haskell-platform) with his diffs.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jer...@cvs.openbsd.org 2014/06/19 14:23:32 Modified files: databases/ruby-data_objects: Makefile distinfo Log message: Update to data_objects 0.10.14
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jer...@cvs.openbsd.org 2014/06/19 14:24:00 Modified files: databases/ruby-do_mysql: Makefile distinfo Log message: Update to do_mysql 0.10.14
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jer...@cvs.openbsd.org 2014/06/19 14:24:27 Modified files: databases/ruby-do_sqlite3: Makefile distinfo Log message: Update to do_sqlite3 0.10.14
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jer...@cvs.openbsd.org 2014/06/19 14:25:49 Modified files: databases/ruby-do_postgres: Makefile distinfo Added files: databases/ruby-do_postgres/patches: patch-ext_do_postgres_do_common_c patch-ext_do_postgres_do_common_h patch-ext_do_postgres_do_postgres_c Log message: Update to do_postgres 0.10.14 Include patches committed upstream to fix a couple of use-after-frees exposed by malloc junking.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2014/06/19 14:55:02 Modified files: devel/arduino : Makefile devel/arduino/files: BSDmakefile Log message: Define ARDUINO macro in the sample BSDmakefile used for user projects; some things need this. See http://comments.gmane.org/gmane.os.openbsd.ports/67938 From Daniel Bolgheroni with slight wording tweak.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2014/06/19 16:17:32 Modified files: mail/amavisd-new: Makefile mail/amavisd-new/patches: patch-amavisd patch-amavisd_conf patch-amavisd_conf-default Log message: Add .gadget files to the commented-out bad extension lines in amavisd's sample config, they can contain active content (including trojans) used by windows sidebar. OK giovanni@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ch...@cvs.openbsd.org 2014/06/19 16:45:56 Modified files: net/iodine : Makefile distinfo net/iodine/patches: patch-src_Makefile patch-src_iodine_c patch-src_iodined_c Added files: net/iodine/patches: patch-src_client_c Log message: Update iodine DNS tunnel to 0.7.0 ok sthen@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2014/06/19 16:58:10 Modified files: net/iodine : Tag: OPENBSD_5_5 Makefile distinfo net/iodine/patches: Tag: OPENBSD_5_5 patch-src_Makefile patch-src_iodine_c patch-src_iodined_c Added files: net/iodine/patches: Tag: OPENBSD_5_5 patch-src_client_c Log message: MFC Update iodine DNS tunnel to 0.7.0 - CVE-2014-4168 - authentication bypass The client could bypass the password check by continuing after getting error from the server and guessing the network parameters. The server would still accept the rest of the setup and also network traffic.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: b...@cvs.openbsd.org2014/06/19 17:02:55 Modified files: net/znc: Makefile distinfo net/znc/pkg: PLIST Removed files: net/znc/patches: patch-modules_webadmin_cpp Log message: Update to znc 1.4. ok sthen@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: b...@cvs.openbsd.org2014/06/19 17:04:42 Modified files: databases/mariadb: Makefile distinfo databases/mariadb/patches: patch-cmake_install_macros_cmake patch-libmysql_CMakeLists_txt patch-scripts_mysqld_safe_sh patch-sql_CMakeLists_txt databases/mariadb/pkg: PLIST-main PLIST-server PLIST-tests Log message: Update to MariaDB 10.0.12. ok giovanni@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bl...@cvs.openbsd.org 2014/06/19 17:07:31 Modified files: security/p5-Net_SSLeay: Makefile distinfo Log message: update p5-Net-SSLeay to 1.64
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2014/06/19 17:24:05 ports/net/icinga/core2/pkg Update of /cvs/ports/net/icinga/core2/pkg In directory cvs.openbsd.org:/tmp/cvs-serv29643/pkg Log Message: Directory /cvs/ports/net/icinga/core2/pkg added to the repository
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2014/06/19 17:24:47 Added files: net/icinga/core2: Makefile distinfo net/icinga/core2/pkg: DESCR-main DESCR-mysql DESCR-pgsql PLIST-main PLIST-mysql PLIST-pgsql Log message: Add icinga/core2, WIP port of icinga2, ok rpe@. (Unlinked for now; working on it with rpe.)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2014/06/19 17:23:58 ports/net/icinga/core2 Update of /cvs/ports/net/icinga/core2 In directory cvs.openbsd.org:/tmp/cvs-serv13944/core2 Log Message: Directory /cvs/ports/net/icinga/core2 added to the repository
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2014/06/19 17:25:05 ports/net/icinga/core2/patches Update of /cvs/ports/net/icinga/core2/patches In directory cvs.openbsd.org:/tmp/cvs-serv21757/patches Log Message: Directory /cvs/ports/net/icinga/core2/patches added to the repository
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2014/06/19 17:33:31 Modified files: net/icinga/core: Makefile Log message: reorder slightly, no pkg change
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2014/06/19 17:33:09 Modified files: net/icinga/core2: Makefile net/icinga/core2/pkg: PLIST-main PLIST-mysql PLIST-pgsql Added files: net/icinga/core2/patches: patch-etc_icinga2_constants_conf patch-etc_icinga2_scripts_mail-host-notification_sh patch-etc_icinga2_scripts_mail-service-notification_sh net/icinga/core2/pkg: icinga2.rc Log message: improvements, from rpe, minor tweaks by me
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bcal...@cvs.openbsd.org 2014/06/19 21:17:43 Modified files: graphics/optipng: Makefile distinfo Log message: Minor update to 0.7.5 ok Kyle Isom (MAINTAINER)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bcal...@cvs.openbsd.org 2014/06/19 23:46:06 Modified files: audio/mumble : Makefile distinfo Log message: Minor update to 1.2.7 Diff looks good sthen@ ok dcoppa@
Re: alpine fails linking because of undefined reference to `RAND_egd'
On 2014/06/19 10:02, Sebastian Reitenbach wrote: On Wednesday, June 18, 2014 22:02 CEST, Stuart Henderson st...@openbsd.org wrote: On 2014/06/18 21:54, Sebastian Reitenbach wrote: On Wednesday, June 18, 2014 20:23 CEST, Stuart Henderson st...@openbsd.org wrote: On 2014/06/18 18:54, Sebastian Reitenbach wrote: Hi, not sure if this is known already, but this happens to me on i386: Check you don't have old libs around, especially make sure you've followed the kerberos removal on current.html. I did not upgrade, it happens on a fresh clean install. as it turned out, i have DEBUG= defined in my /etc/mk.conf, which is triggering the build failure. attached patch allows building alpine with DEBUG in mk.conf. Don't know if this is the most clever way, but looking at how other ports handle RAND_egd they just removed it. Also I'm unsure which of the many SUBPACKAGE to bump REVISION ;) It seems rather strange that setting DEBUG should trigger building code that uses RAND_egd ..
Re: alpine fails linking because of undefined reference to `RAND_egd'
On Thursday, June 19, 2014 10:28 CEST, Stuart Henderson st...@openbsd.org wrote: On 2014/06/19 10:02, Sebastian Reitenbach wrote: On Wednesday, June 18, 2014 22:02 CEST, Stuart Henderson st...@openbsd.org wrote: On 2014/06/18 21:54, Sebastian Reitenbach wrote: On Wednesday, June 18, 2014 20:23 CEST, Stuart Henderson st...@openbsd.org wrote: On 2014/06/18 18:54, Sebastian Reitenbach wrote: Hi, not sure if this is known already, but this happens to me on i386: Check you don't have old libs around, especially make sure you've followed the kerberos removal on current.html. I did not upgrade, it happens on a fresh clean install. as it turned out, i have DEBUG= defined in my /etc/mk.conf, which is triggering the build failure. attached patch allows building alpine with DEBUG in mk.conf. Don't know if this is the most clever way, but looking at how other ports handle RAND_egd they just removed it. Also I'm unsure which of the many SUBPACKAGE to bump REVISION ;) It seems rather strange that setting DEBUG should trigger building code that uses RAND_egd .. it indeed is, but I haven't seen any obvious #ifdef around it. There are some #ifdefs in that file, but nothing that immediately seems to relate to DEBUG Sebastian
[UPDATE] cfengine master_site change
easy diff, let's first update our 3.4.5 version before trying to update to 3.6.0. j. Index: Makefile === RCS file: /cvs/ports/sysutils/cfengine/Makefile,v retrieving revision 1.44 diff -u -p -r1.44 Makefile --- Makefile20 Sep 2013 13:02:49 - 1.44 +++ Makefile19 Jun 2014 09:18:52 - @@ -3,8 +3,7 @@ COMMENT = GNU system administration tool for networks DISTNAME = cfengine-3.4.5 -F =${DISTNAME}${EXTRACT_SUFX} -DISTFILES =$F{download?file=$F} +REVISION = 0 SHARED_LIBS += promises 0.0 # 1.0 CATEGORIES = sysutils @@ -15,7 +14,7 @@ MAINTAINER = Martijn Rijkeboer martijn@ # GPLv3 only PERMIT_PACKAGE_CDROM = Yes -MASTER_SITES = http://cfengine.com/source-code/ +MASTER_SITES = https://s3.amazonaws.com/cfengine.package-repos/tarballs/ CFENGINE_BASE =/var/cfengine CFENGINE_EXAMPLES =${PREFIX}/share/examples/cfengine
Re: [UPDATE] cfengine master_site change
easy diff, let's first update our 3.4.5 version before trying to update to 3.6.0. j. Index: Makefile === RCS file: /cvs/ports/sysutils/cfengine/Makefile,v retrieving revision 1.44 diff -u -p -r1.44 Makefile --- Makefile20 Sep 2013 13:02:49 - 1.44 +++ Makefile19 Jun 2014 09:18:52 - @@ -3,8 +3,7 @@ COMMENT = GNU system administration tool for networks DISTNAME = cfengine-3.4.5 -F =${DISTNAME}${EXTRACT_SUFX} -DISTFILES =$F{download?file=$F} +REVISION = 0 SHARED_LIBS += promises 0.0 # 1.0 CATEGORIES = sysutils @@ -15,7 +14,7 @@ MAINTAINER = Martijn Rijkeboer martijn@ # GPLv3 only PERMIT_PACKAGE_CDROM = Yes -MASTER_SITES = http://cfengine.com/source-code/ +MASTER_SITES = https://s3.amazonaws.com/cfengine.package-repos/tarballs/ CFENGINE_BASE =/var/cfengine CFENGINE_EXAMPLES =${PREFIX}/share/examples/cfengine Fine by me. Kind regards, Martijn Rijkeboer
Anyone working on pandoc?
Hi all Has anyone tried / started to port pandoc, or knows of any good reason not to? I'd like to give it a shot, but I don't want do duplicate efforts... Cheers Zé --
Re: [UPDATE] cfengine master_site change
On 2014/06/19 05:20, Jiri B wrote: easy diff, let's first update our 3.4.5 version before trying to update to 3.6.0. committed, minus the REVISION change (MASTER_SITES doesn't make it into the package).
Re: NEW: games/hyperrogue
On 06/12/14 19:17, Brian Callahan wrote: On 06/08/14 16:02, Brian Callahan wrote: Hi ports -- Attached is a new port, games/hyperrogue. Hyperrogue is a treasure hunting, monster slaying game played on a non-Euclidean map. Works well for me on amd64 and i386. macppc testing shows what appear to be endian bugs (inverted colors, no sound). Would appreciate a double check on that. OK? ~Brian Ping. Ping again.
Re: diff to BSDmakefile in devel/arduino
On 2014/06/19 00:24, Daniel Bolgheroni wrote: On Wed, Jun 18, 2014 at 10:10:24AM +0100, Stuart Henderson wrote: This file is somewhat hidden in the port. What are the consequences of it not being updated if the port is updated? I think the main issue here is that if we don't define ARDUINO = 100, even libraries already in the current distribution, like Firmata, will fail to compile looking for WProgram.h, which we don't have anymore since we are at 1.0.2. Test case: create a project with 'arduinoproject', edit the BSDmakefile and add Firmata to LIBRARIES, run make. The libraries I checked until now use this test very much like it was suggested in revisions.txt (Firmata case) like important 3rd-party libraries Time and DS1307RTC (real time clock modules). The problem would be if libraries begin to use this with another purpose than what was initially suggested in revisions.txt, e.g. using 105, 106 and so on, to check for other renaming schemes in the future. I really doubt it will occur, since the development is moving onto 1.5.x, and 1.0.x is pretty much stable. Otherwise, we are safe defining ARDUINO=100. Does it need some check in the port Makefile to ensure that it's correct, or at least a reminder comment right next to DISTNAME? Also requires a REVISION bump. I don't see why. The alternative would be a comment in BSDmakefile stating that there are some libraries which depend on ARDUINO = 100 if using Arduino 1.0.x, but since we already are at that version, I don't see a point in not defining it previously. Thank you. -- db Say the port is updated to 1.5.x, these -D lines will need to be updated, right? What I am asking for is a comment, in the port Makefile, not in a file hidden away in files/, reminding people to do that. Does that make sense?
systrace.filter update
Add minherit and sort, it is needed at least to build mariadb with systrace enabled, comments ? ok ? Cheers Giovanni Index: systrace.filter === RCS file: /cvs/ports/infrastructure/db/systrace.filter,v retrieving revision 1.40 diff -u -p -u -p -r1.40 systrace.filter --- systrace.filter 14 Jun 2014 07:51:52 - 1.40 +++ systrace.filter 19 Jun 2014 13:44:53 - @@ -137,6 +137,8 @@ native-listen: permit native-lseek: permit native-madvise: permit + native-mincore: permit + native-minherit: permit native-mknod: filename match /tmp then permit native-mknod: filename match /var/tmp then permit native-mknod: filename match ${TMPDIR} then permit @@ -145,7 +147,6 @@ native-mknodat: filename match /var/tmp then permit native-mknodat: filename match ${TMPDIR} then permit native-mknodat: filename match ${WRKDIR} then permit - native-mincore: permit native-mlock: permit native-mlockall: permit native-mmap: permit
Re: Anyone working on pandoc?
On Thu, Jun 19, 2014 at 10:22:17AM -0400, Ian Darwin wrote: On 2014-06-19, 9:42 AM, Zé Loff wrote: Hi all Has anyone tried / started to port pandoc, or knows of any good reason not to? I'd like to give it a shot, but I don't want do duplicate efforts... Yes, I have it mostly done (a dozen or so new dependencies, of course), but it's on hold waiting for the annual churnover of Haskell GHC port. Nice, thanks. Let me know if I can help. Cheers Zé --
Re: Anyone working on pandoc?
On 2014-06-19, 9:42 AM, Zé Loff wrote: Hi all Has anyone tried / started to port pandoc, or knows of any good reason not to? I'd like to give it a shot, but I don't want do duplicate efforts... Yes, I have it mostly done (a dozen or so new dependencies, of course), but it's on hold waiting for the annual churnover of Haskell GHC port.
Re: systrace.filter update
On 2014/06/19 16:19, Giovanni Bechis wrote: Add minherit and sort, it is needed at least to build mariadb with systrace enabled, comments ? ok ? Cheers Giovanni Index: systrace.filter === RCS file: /cvs/ports/infrastructure/db/systrace.filter,v retrieving revision 1.40 diff -u -p -u -p -r1.40 systrace.filter --- systrace.filter 14 Jun 2014 07:51:52 - 1.40 +++ systrace.filter 19 Jun 2014 13:44:53 - @@ -137,6 +137,8 @@ native-listen: permit native-lseek: permit native-madvise: permit + native-mincore: permit + native-minherit: permit native-mknod: filename match /tmp then permit native-mknod: filename match /var/tmp then permit native-mknod: filename match ${TMPDIR} then permit @@ -145,7 +147,6 @@ native-mknodat: filename match /var/tmp then permit native-mknodat: filename match ${TMPDIR} then permit native-mknodat: filename match ${WRKDIR} then permit - native-mincore: permit native-mlock: permit native-mlockall: permit native-mmap: permit It won't just be mariadb. OK.
[NEW] devel/p5-Kwalify
$ cat devel/p5-Kwalify/pkg/DESCR Kwalify is a Perl implementation for validating data structures against the Kwalify schema. Testing: amd64, -current Sergey B. p5-Kwalify.tgz Description: application/tar-gz
[NEW] devel/p5-MooX-Types-MooseLike
$ cat devel/p5-MooX-Types-MooseLike/pkg/DESCR MooX::Types::MooseLike provides some Moosish types and a typer builder. Testing: amd64, -current Sergey B. p5-MooX-Types-MooseLike.tgz Description: application/tar-gz
[NEW] security/p5-Digest-JHash
The Digest::JHash module allows you to use the fast JHash hashing algorithm developed by Bob Jenkins from within Perl programs. The algorithm takes as input a message of arbitrary length and produces as output a 32-bit message digest of the input in the form of an unsigned long integer. Testing: amd64, -current Sergey B. p5-Digest-JHash.tgz Description: application/tar-gz
Re: Anyone working on pandoc?
On 19 Jun 2014 15:23, Zé Loff wrote: On Thu, Jun 19, 2014 at 10:22:17AM -0400, Ian Darwin wrote: On 2014-06-19, 9:42 AM, Zé Loff wrote: Hi all Has anyone tried / started to port pandoc, or knows of any good reason not to? I'd like to give it a shot, but I don't want do duplicate efforts... Yes, I have it mostly done (a dozen or so new dependencies, of course), but it's on hold waiting for the annual churnover of Haskell GHC port. Nice, thanks. Let me know if I can help. Cheers Zé -- Hi Zé and Ian, I am also a pandoc user so I'll try the port when it's available. Meanwhile, the cabal version works fine. The only problem is that, every time pandoc has to be rebuilt, it might take at least one hour. Cheers!
Re: [UPDATE] cfengine master_site change
CFEngine can be compiled with qdbm, tokyo cabinet or lmdb. Currently, OBSD only includes qdbm on port, and OBSD`s CFEngine is complied with qdbm. There is someone already working to include Tokyo Cabinet or lmdb into ports? 2014-06-19 6:20 GMT-03:00 Jiri B ji...@devio.us: easy diff, let's first update our 3.4.5 version before trying to update to 3.6.0. j. Index: Makefile === RCS file: /cvs/ports/sysutils/cfengine/Makefile,v retrieving revision 1.44 diff -u -p -r1.44 Makefile --- Makefile20 Sep 2013 13:02:49 - 1.44 +++ Makefile19 Jun 2014 09:18:52 - @@ -3,8 +3,7 @@ COMMENT = GNU system administration tool for networks DISTNAME = cfengine-3.4.5 -F =${DISTNAME}${EXTRACT_SUFX} -DISTFILES =$F{download?file=$F} +REVISION = 0 SHARED_LIBS += promises 0.0 # 1.0 CATEGORIES = sysutils @@ -15,7 +14,7 @@ MAINTAINER = Martijn Rijkeboer martijn@ # GPLv3 only PERMIT_PACKAGE_CDROM = Yes -MASTER_SITES = http://cfengine.com/source-code/ +MASTER_SITES = https://s3.amazonaws.com/cfengine.package-repos/tarballs/ CFENGINE_BASE =/var/cfengine CFENGINE_EXAMPLES =${PREFIX}/share/examples/cfengine
Re: Anyone working on pandoc?
Hi, On Thu, Jun 19, 2014 at 03:23:27PM +0100, Zé Loff wrote: On Thu, Jun 19, 2014 at 10:22:17AM -0400, Ian Darwin wrote: On 2014-06-19, 9:42 AM, Zé Loff wrote: Has anyone tried / started to port pandoc, or knows of any good reason not to? I'd like to give it a shot, but I don't want do duplicate efforts... Yes, I have it mostly done (a dozen or so new dependencies, of course), but it's on hold waiting for the annual churnover of Haskell GHC port. Nice, thanks. Let me know if I can help. Short story: try older versions of pandoc which can be built with aeson-0.6, *not* requiring any library which meta/haskell-platform depends on to be changed. pandoc-1.12.3.3 may be worth a try. Long story: The biggest problem is that the latest version of pandoc needs aeson-0.7, which needs attoparsec-=0.11.3.4, but the haskell-platform dictates attoparsec-0.10.4.0 (and even the current drafts of haskell-platform-2014 still depends on that same version of attoparsec). That means that even after the yearly churn of haskell ports (which I'll hopefully start in two or three weeks), our port of attoparsec has to stay at 0.10.4.0. For pandoc (or aeson-0.7), we would need a separate port/package hs-attoparsec-0.11 (or maybe -0.12?). But with two different ports of hs-attoparsec, for every existing port depending on hs-attoparsec (0.10), you'll have to make sure that either - it doesn't pick up hs-attoparsec-0.11 by accident when it's installed (by looking at its cabal file, and maybe patching it to depend on attoparsec-0.11), or - it builds and works with attoparsec-0.11, depends on it (in the port's Makefile) and *never* picks up an installed hs-attoparsec (0.10) because of other dependency constraints. I'd prefer to not doing such a stunt, because it's unmaintainable. Better go back a few releases of pandoc (see above) and then try to find out whether the newer releases really need aeson-0.7 (and probably other stuff causing similar problems) and wether they could be patched to still work with aeson-0.6. (Or try to get aeson-0.7 working with attoparsec-0.10) Ciao, Kili
Haskell-Platform-2014 (was: Anyone working on pandoc?)
On Thu, Jun 19, 2014 at 07:46:28PM +0200, Matthias Kilian wrote: The biggest problem is that the latest version of pandoc needs aeson-0.7, which needs attoparsec-=0.11.3.4, but the haskell-platform dictates attoparsec-0.10.4.0 (and even the current drafts of haskell-platform-2014 still depends on that same version of attoparsec). BTW: a list of haskell-platform-2014 will probably contain can be nowdays found here: https://github.com/haskell/haskell-platform/blob/new-build/hptool/src/Releases2014.hs (unless upstream changes their mind and suddenlly puts this information somwhere else, which *did* happen in the past) Ciao, Kili
security update: x11/kde4/libs
heads up @ports, securiry fix for kde4 libs. http://www.kde.org/info/security/advisory-20140618-1.txt Cheers, Rafael Index: Makefile === RCS file: /cvs/ports/x11/kde4/libs/Makefile,v retrieving revision 1.51 diff -u -p -u -r1.51 Makefile --- Makefile30 Apr 2014 09:36:04 - 1.51 +++ Makefile19 Jun 2014 15:05:42 - @@ -11,7 +11,7 @@ PKGNAME-langlist =kde4-langlist-${MODKD PKG_ARCH-en_US = * PKG_ARCH-langlist =* PKGSPEC-main = kdelibs-=4 -REVISION-main =8 +REVISION-main =9 DPB_PROPERTIES = parallel tag:kde4 Index: patches/patch-kio_kio_usernotificationhandler_cpp === RCS file: patches/patch-kio_kio_usernotificationhandler_cpp diff -N patches/patch-kio_kio_usernotificationhandler_cpp --- /dev/null 1 Jan 1970 00:00:00 - +++ patches/patch-kio_kio_usernotificationhandler_cpp 19 Jun 2014 15:05:42 - @@ -0,0 +1,47 @@ +$OpenBSD$ + +fix CVE-2014-3494 + +--- kio/kio/usernotificationhandler.cpp.orig Thu Jan 2 20:26:52 2014 kio/kio/usernotificationhandler.cppThu Jun 19 17:00:27 2014 +@@ -19,7 +19,7 @@ + #include usernotificationhandler_p.h + + #include slave.h +-#include job_p.h ++#include jobuidelegate.h + + #include kdebug.h + +@@ -76,19 +76,18 @@ void UserNotificationHandler::processRequest() + + if (m_cachedResults.contains(key)) { + result = *(m_cachedResults[key]); +-} else if (r-slave-job()) { +-SimpleJobPrivate* jobPrivate = SimpleJobPrivate::get(r-slave-job()); +-if (jobPrivate) { +-result = jobPrivate-requestMessageBox(r-type, +- r-data.value(MSG_TEXT).toString(), +- r-data.value(MSG_CAPTION).toString(), +- r-data.value(MSG_YES_BUTTON_TEXT).toString(), +- r-data.value(MSG_NO_BUTTON_TEXT).toString(), +- r-data.value(MSG_YES_BUTTON_ICON).toString(), +- r-data.value(MSG_NO_BUTTON_ICON).toString(), +- r-data.value(MSG_DONT_ASK_AGAIN).toString(), +- r-data.value(MSG_META_DATA).toMap()); +-} ++} else { ++JobUiDelegate ui; ++const JobUiDelegate::MessageBoxType type = static_castJobUiDelegate::MessageBoxType(r-type); ++result = ui.requestMessageBox(type, ++ r-data.value(MSG_TEXT).toString(), ++ r-data.value(MSG_CAPTION).toString(), ++ r-data.value(MSG_YES_BUTTON_TEXT).toString(), ++ r-data.value(MSG_NO_BUTTON_TEXT).toString(), ++ r-data.value(MSG_YES_BUTTON_ICON).toString(), ++ r-data.value(MSG_NO_BUTTON_ICON).toString(), ++ r-data.value(MSG_DONT_ASK_AGAIN).toString(), ++ r-data.value(MSG_META_DATA).toMap()); + m_cachedResults.insert(key, new int(result)); + } + } else {
Re: [UPDATE] cfengine master_site change
On Thu, Jun 19, 2014 at 02:16:30PM -0300, Rodrigo Mosconi wrote: CFEngine can be compiled with qdbm, tokyo cabinet or lmdb. Currently, OBSD only includes qdbm on port, and OBSD`s CFEngine is complied with qdbm. There is someone already working to include Tokyo Cabinet or lmdb into ports? First you should try to compile 3.6.0 ;) They were some issues which should be solved soon. I hope static compilation would be solved as well soon. Try yourself, file bugs upstream. j.
Update for net/iodine
Like this? Index: Makefile === RCS file: /cvs/ports/net/iodine/Makefile,v retrieving revision 1.13 diff -u -p -u -r1.13 Makefile --- Makefile11 Oct 2013 23:50:18 - 1.13 +++ Makefile19 Jun 2014 19:43:02 - @@ -2,8 +2,7 @@ COMMENT= tunnel IPv4 data through DNS -DISTNAME= iodine-0.5.2 -REVISION= 0 +DISTNAME= iodine-0.7.0 CATEGORIES=net HOMEPAGE= http://code.kryo.se/iodine/ Index: distinfo === RCS file: /cvs/ports/net/iodine/distinfo,v retrieving revision 1.3 diff -u -p -u -r1.3 distinfo --- distinfo2 Jun 2009 06:27:05 - 1.3 +++ distinfo19 Jun 2014 19:43:02 - @@ -1,5 +1,2 @@ -MD5 (iodine-0.5.2.tar.gz) = aVI0PMRhSFf4PbuBJHhx5w== -RMD160 (iodine-0.5.2.tar.gz) = LA1VIzwqYVeRGluGi8U40nwesIU= -SHA1 (iodine-0.5.2.tar.gz) = KNDQDlE+IKp/38xhhy3uDsAy8RI= -SHA256 (iodine-0.5.2.tar.gz) = y8FGZdMlY0MY69b3kvjcIikQG9WlUjJCBXBThhL2peQ= -SIZE (iodine-0.5.2.tar.gz) = 50788 +SHA256 (iodine-0.7.0.tar.gz) = rStArPFCExbsFYANzeD1h6sx19b4kfqLmWfE3tk8AT4= +SIZE (iodine-0.7.0.tar.gz) = 96181 Index: patches/patch-src_Makefile === RCS file: /cvs/ports/net/iodine/patches/patch-src_Makefile,v retrieving revision 1.2 diff -u -p -u -r1.2 patch-src_Makefile --- patches/patch-src_Makefile 30 Mar 2009 09:17:45 - 1.2 +++ patches/patch-src_Makefile 19 Jun 2014 19:43:02 - @@ -1,23 +1,16 @@ -$OpenBSD: patch-src_Makefile,v 1.2 2009/03/30 09:17:45 sthen Exp $ src/Makefile.orig Sat Mar 21 13:07:49 2009 -+++ src/Makefile Mon Mar 30 10:09:57 2009 -@@ -1,4 +1,4 @@ --CC = gcc -+CC ?= gcc - COMMONOBJS = tun.o dns.o read.o encoding.o login.o base32.o base64.o md5.o common.o - CLIENTOBJS = iodine.o - CLIENT = ../bin/iodine -@@ -10,7 +10,8 @@ ARCH = `uname -m` +--- src/Makefile.orig Thu Jun 19 12:05:05 2014 src/Makefile Thu Jun 19 12:05:38 2014 +@@ -9,7 +9,8 @@ LIBPATH = -L. - LDFLAGS = -lz `sh osflags $(TARGETOS) link` $(LIBPATH) --CFLAGS = -c -g -Wall -D$(OS) -pedantic `sh osflags $(TARGETOS) cflags` + LDFLAGS += -lz `sh osflags $(TARGETOS) link` $(LIBPATH) +-CFLAGS += -std=c99 -c -g -Wall -D$(OS) -pedantic `sh osflags $(TARGETOS) cflags` +CFLAGS ?= -g -+CFLAGS += -c -Wall -D$(OS) -pedantic `sh osflags $(TARGETOS) cflags` ++CFLAGS += -std=c99 -c -Wall -D$(OS) -pedantic `sh osflags $(TARGETOS) cflags` all: stateos $(CLIENT) $(SERVER) -@@ -18,18 +19,15 @@ stateos: +@@ -17,18 +18,15 @@ @echo OS is $(OS), arch is $(ARCH) $(CLIENT): $(COMMONOBJS) $(CLIENTOBJS) @@ -32,10 +25,10 @@ $OpenBSD: patch-src_Makefile,v 1.2 2009/ - @$(CC) $(COMMONOBJS) $(SERVEROBJS) -o $(SERVER) $(LDFLAGS) + $(CC) $(COMMONOBJS) $(SERVEROBJS) -o $(SERVER) $(LDFLAGS) - .c.o: + .c.o: - @echo CC $ - @$(CC) $(CFLAGS) $ -o $@ + $(CC) $(CFLAGS) $ -o $@ - clean: - @echo Cleaning src/ + base64u.o client.o iodined.o: base64u.h + base64u.c: base64.c Index: patches/patch-src_client_c === RCS file: patches/patch-src_client_c diff -N patches/patch-src_client_c --- /dev/null 1 Jan 1970 00:00:00 - +++ patches/patch-src_client_c 19 Jun 2014 19:43:02 - @@ -0,0 +1,16 @@ +--- src/client.c.orig Thu Jun 19 12:23:49 2014 src/client.c Thu Jun 19 12:23:21 2014 +@@ -121,11 +121,11 @@ + b64u = get_base64u_encoder(); + b128 = get_base128_encoder(); + dataenc = get_base32_encoder(); +- rand_seed = ((unsigned int) rand()) 0x; ++ rand_seed = ((unsigned int) arc4random()) 0x; + send_ping_soon = 1; /* send ping immediately after startup */ + conn = CONN_DNS_NULL; + +- chunkid = ((unsigned int) rand()) 0x; ++ chunkid = ((unsigned int) arc4random()) 0x; + chunkid_prev = 0; + chunkid_prev2 = 0; + Index: patches/patch-src_iodine_c === RCS file: /cvs/ports/net/iodine/patches/patch-src_iodine_c,v retrieving revision 1.2 diff -u -p -u -r1.2 patch-src_iodine_c --- patches/patch-src_iodine_c 30 Mar 2009 09:17:45 - 1.2 +++ patches/patch-src_iodine_c 19 Jun 2014 19:43:02 - @@ -1,18 +1,24 @@ -$OpenBSD: patch-src_iodine_c,v 1.2 2009/03/30 09:17:45 sthen Exp $ - -Drop privileges and chroot by default. - src/iodine.c.orig Sat Mar 21 14:07:49 2009 -+++ src/iodine.c Mon Mar 30 10:25:08 2009 -@@ -1009,9 +1009,9 @@ main(int argc, char **argv) - int autodetect_frag_size; - - memset(password, 0, 33); +--- src/iodine.c.orig Mon Jun 16 13:28:43 2014 src/iodine.c Thu Jun 19 12:22:17 2014 +@@ -155,11 +155,10 @@ + #ifndef WINDOWS32 + pw = NULL; + #endif - username = NULL; + username = _iodine; +
Re: diff to BSDmakefile in devel/arduino
On Thu, Jun 19, 2014 at 03:06:10PM +0100, Stuart Henderson wrote: Say the port is updated to 1.5.x, these -D lines will need to be updated, right? Until now, we are fine using ARDUINO=100 even if we update to 1.5.x. This macro is being used, as of today, only to control the renaming scheme from WProgram.h to Arduino.h. I can't say what they will eventually do in the future. If they begin to use this variable to control every other renaming schemes or, worst, something else, we still need to set this to something = 100 for 1.0.x. What I am asking for is a comment, in the port Makefile, not in a file hidden away in files/, reminding people to do that. Does that make sense? Sure. OK? Thank you. Index: Makefile === RCS file: /cvs/ports/devel/arduino/Makefile,v retrieving revision 1.10 diff -u -p -r1.10 Makefile --- Makefile7 Aug 2013 21:31:29 - 1.10 +++ Makefile19 Jun 2014 19:53:24 - @@ -4,6 +4,9 @@ COMMENT=open-source electronics prototy V= 1.0.2 PKGNAME= arduino-${V} +# Arduino uses the ARDUINO macro to control the renaming scheme they did +# on 1.0.x, from WProgram.h to Arduino.h. BSDmakefile, which defines +# it, may need to be updated accordingly. DISTNAME= arduino-${V}-src EPOCH= 0 REVISION = 1
UPDATE: audio/mumble 1.2.6 = 1.2.7
Hi ports -- Here's a minor update to mumble, fixing two small issues from the previous release. Changelog here: http://blog.mumble.info/mumble-1-2-7/ Works on amd64. OK? ~Brian Index: Makefile === RCS file: /cvs/ports/audio/mumble/Makefile,v retrieving revision 1.8 diff -u -p -r1.8 Makefile --- Makefile 27 May 2014 12:14:07 - 1.8 +++ Makefile 19 Jun 2014 21:53:09 - @@ -4,7 +4,7 @@ SHARED_ONLY = Yes COMMENT = low-latency voice chat client -DISTNAME = mumble-1.2.6 +DISTNAME = mumble-1.2.7 CATEGORIES = audio Index: distinfo === RCS file: /cvs/ports/audio/mumble/distinfo,v retrieving revision 1.3 diff -u -p -r1.3 distinfo --- distinfo 27 May 2014 12:14:07 - 1.3 +++ distinfo 19 Jun 2014 21:53:09 - @@ -1,2 +1,2 @@ -SHA256 (mumble-1.2.6.tar.gz) = h2zez7iXmKtFAgza4NZL0PqJmpqXwsf0pucG1BZftv8= -SIZE (mumble-1.2.6.tar.gz) = 3201577 +SHA256 (mumble-1.2.7.tar.gz) = LQx9t2TqfyMxG940/ycNBTmzjIQHXWtYxPVtNtucWH4= +SIZE (mumble-1.2.7.tar.gz) = 3202064
Re: UPDATE: audio/mumble 1.2.6 = 1.2.7
On 2014/06/19 18:23, Brian Callahan wrote: Hi ports -- Here's a minor update to mumble, fixing two small issues from the previous release. Changelog here: http://blog.mumble.info/mumble-1-2-7/ Works on amd64. OK? Diff looks good. Those issues, one of them isn't going to affect us as we don't have skype, but.W..T..F..?! Skype's click-to-call feature (which is optional, and can be disabled at install time) is causing trouble for quite a few Mumble users by flooding their Root CA store with an enormous amount of certificates ~Brian Index: Makefile === RCS file: /cvs/ports/audio/mumble/Makefile,v retrieving revision 1.8 diff -u -p -r1.8 Makefile --- Makefile 27 May 2014 12:14:07 - 1.8 +++ Makefile 19 Jun 2014 21:53:09 - @@ -4,7 +4,7 @@ SHARED_ONLY = Yes COMMENT =low-latency voice chat client -DISTNAME = mumble-1.2.6 +DISTNAME = mumble-1.2.7 CATEGORIES = audio Index: distinfo === RCS file: /cvs/ports/audio/mumble/distinfo,v retrieving revision 1.3 diff -u -p -r1.3 distinfo --- distinfo 27 May 2014 12:14:07 - 1.3 +++ distinfo 19 Jun 2014 21:53:09 - @@ -1,2 +1,2 @@ -SHA256 (mumble-1.2.6.tar.gz) = h2zez7iXmKtFAgza4NZL0PqJmpqXwsf0pucG1BZftv8= -SIZE (mumble-1.2.6.tar.gz) = 3201577 +SHA256 (mumble-1.2.7.tar.gz) = LQx9t2TqfyMxG940/ycNBTmzjIQHXWtYxPVtNtucWH4= +SIZE (mumble-1.2.7.tar.gz) = 3202064
Re: [NEW] net/mirall
On Thu, Jun 05, 2014 at 12:28:45PM +0400, Kirill Bychkov wrote: On Sun, May 4, 2014 11:07, Kirill Bychkov wrote: On Thu, May 1, 2014 10:07, Antoine Jacoutot wrote: On Thu, May 01, 2014 at 08:04:28AM +0200, Antoine Jacoutot wrote: On Thu, May 01, 2014 at 09:50:37AM +0400, Kirill Bychkov wrote: Hi! Mirall is an official owncloud desktop client. This is not the latest version, which involves update of ocsync. It depends on Linux's inotify mechanics, but luckily it was implemented in libinotify. Libinotify was developed for NetBSD at GSoC'11. libinotify passes regression tests on amd64 and macppc. Mirall itself was tested only in amd64 with owncloud-6.0.3 and is working fine. It builds on macppc, but I can't start X on my iBook, so I can't test. Comments? OKs? I already commented several times about this. libnotify for BSD has bugs (talked to the person who developed it) and is not maintained (that is the reason gio-kqueue was implemented directly in glib2 for now instead of relying on libnotify). Also this will probably be picked up by ports so that needs very careful checks to make sure nothing suddenly starts linking against that. To be clear, I am not against having it as long as nothing else uses it :-) Now with inotify renamed to kinotify, so nothing in ports would pick it automatically. Added README about bumping ulimit -n. Works fine for a long time on amd64. OK to import? Thanks to Kirill for porting this little program which is extremely useful when syncing against ownCloud. It really put the fun back into ownClouding! Tested on two different amd64 -current installations. Building takes quite some time (mainly gcc) and my initial attempts on running it failed when not making sure of bumping ulimit -n to 1024. When bumping ulimit everything appear to be working just fine.
py-selenium and OpenBSD
Hello, I'm relatively new to OpenBSD (6+ months and two CD sets) -- love it. I'm attempting to do some web development on OpenBSD but can't get py-selenium to work. This thread shows that I'm not alone: http://openbsd.7691.n7.nabble.com/py-selenium-td238035.html I can't be the only one trying to use py-selenium on OpenBSD. What is everyone else doing as a workaround in the meantime? Thanks in advance, Craig