CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2013/07/01 00:49:14 Modified files: devel : Makefile Log message: -ruby-systemtimer
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2013/07/01 00:50:21 Removed files: devel/ruby-systemtimer: Makefile distinfo devel/ruby-systemtimer/pkg: DESCR PLIST Log message: drop ruby-systemtimer which is designed only for ruby 1.8 and will never work with other, non-deprecated versions of ruby. no objection from jeremy@ ok aja@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2013/07/01 02:44:41 Modified files: textproc/exempi: Makefile distinfo textproc/exempi/pkg: PLIST Added files: textproc/exempi/patches: patch-public_include_XMP_UnixEndian_h Removed files: textproc/exempi/patches: patch-source_common_EndianUtils_hpp textproc/exempi/pkg: PFRAG.shared Log message: Update to exempi-2.2.1. Remove maintainer as per his request.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2013/07/01 03:33:04 Modified files: . : INDEX Log message: sync, 8148
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2013/07/01 04:39:18 Modified files: audio/p5-Audio-FLAC-Header: Makefile audio/p5-Audio-Musepack: Makefile audio/p5-Audio-WMA: Makefile audio/p5-MP3-Info: Makefile audio/p5-MP3-Tag: Makefile audio/p5-Ogg-Vorbis-Header: Makefile cad/gerbv : Makefile cad/gnucap : Makefile cad/pcb: Makefile devel/openmpi : Makefile devel/py-logilab-astng: Makefile devel/py-logilab-common: Makefile devel/pylint : Makefile devel/sdcc : Makefile net/yaz: Makefile print/latex-mk : Makefile x11/tellico: Makefile Log message: Remove Andreas Bihlmaier as maintainer per his request on ports@. Drop USE_GROFF from perl ports while there.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: es...@cvs.openbsd.org 2013/07/01 06:35:35 Modified files: infrastructure/lib/DPB/Job: Port.pm Log message: normal ports task can accurately mark that they have failed. (so that the builder can look at them, and stop trusting the apparition of pkgfiles to indicate the build succeeded/failed)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: dco...@cvs.openbsd.org 2013/07/01 07:42:25 Modified files: x11/i3 : Makefile x11/i3/patches : patch-i3-nagbar_main_c patch-libi3_ipc_recv_message_c patch-src_config_parser_c Added files: x11/i3/patches : patch-src_floating_c patch-src_workspace_c Log message: Some bugfixes from upstream: i3-nagbar: Bugfix: -m requires an argument (crashes if none specified) (upstream git commit 4765427f219c306f0872f124d0b1e2398bf8e39f) i3-nagbar: call i3-nagbar correctly for configfiles without the font directive (upstream git commit e8759691b8fdac7f964626c357dd6512a698ea2f) Bugfix: fix focus handling in 'floating disable' on non-visible windows (upstream git commit b4f7142509e3af51504a1e72163d544d305f0fa8) Bugfix: Ignore spaces in front of default workspace name (upstream git commit 625d5bdba6318377baa716ad5ea5a0b2f85b1c0e)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2013/07/01 07:49:00 Modified files: databases/puppetdb: Makefile databases/puppetdb/patches: patch-ext_files_config_ini patch-ext_files_puppetdb-foreground Log message: don't hardcode /etc here.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: es...@cvs.openbsd.org 2013/07/01 10:29:29 Added files: net/net-snmp/patches: patch-snmplib_read_config_c Log message: fix the one 'declaration after statement' that prevents vax from building this.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2013/07/01 10:47:15 Modified files: security : Makefile Log message: +ruby-hmac
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2013/07/01 10:46:45 Log message: import ruby-hmac-0.4.0 This module provides common interface to HMAC functionality. HMAC is a kind of Message Authentication Code (MAC) algorithm whose standard is documented in RFC2104. Namely, a MAC provides a way to check the integrity of information transmitted over or stored in an unreliable medium, based on a secret key. ok aja@ Status: Vendor Tag: jasper Release Tags: jasper_20130107 N ports/security/ruby-hmac/Makefile N ports/security/ruby-hmac/distinfo N ports/security/ruby-hmac/pkg/PLIST N ports/security/ruby-hmac/pkg/DESCR No conflicts created by this import
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2013/07/01 10:51:02 Modified files: security : Makefile Removed files: security/metasploit: Makefile distinfo security/metasploit/patches: patch-lib_msf_ui_console_command_dispatcher_db_rb patch-lib_rbreadline_rb security/metasploit/pkg: DESCR-main DESCR-mysql DESCR-pgsql PLIST-main PLIST-mysql PLIST-pgsql Log message: remove metasploit, the open source version is unmaintained upstream and this port hadn't had much love in recent years. as discussed with and OK stephan@ (MAINTAINER)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2013/07/01 10:52:05 Modified files: net: Makefile Removed files: net/ruby-pcap : Makefile distinfo net/ruby-pcap/patches: patch-ruby_pcap_h net/ruby-pcap/pkg: DESCR PLIST net/ruby-pcaprub-msf: Makefile distinfo net/ruby-pcaprub-msf/patches: patch-pcaprub_c net/ruby-pcaprub-msf/pkg: DESCR PLIST Log message: remove these ruby18-only ports that are now unused, and were packaged just for metasploit. prompted by and OK stephan@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: dco...@cvs.openbsd.org 2013/07/01 11:00:40 Modified files: cad/xtrkcad: Makefile Added files: cad/xtrkcad/patches: patch-app_bin_CMakeLists_txt Log message: Fix and re-enable ninja build.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: es...@cvs.openbsd.org 2013/07/01 11:44:20 Added files: graphics/libexif/patches: patch-libexif_exif-entry_c Log message: yet another port with one single declaration after code problem...
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: na...@cvs.openbsd.org 2013/07/01 14:49:59 Modified files: education/verbiste: Makefile distinfo Log message: update to 0.1.38, which now includes wiktionary links
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2013/07/01 15:35:50 Modified files: www/hs-webkit : Makefile x11/xmobar : Makefile x11/hs-xmonad-contrib: Makefile Log message: Change maintainer address. ok by maintainer Jona Joachim.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2013/07/01 15:42:51 Modified files: lang/ghc : Makefile Log message: Remove redundant (and incomplete) comment.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2013/07/01 17:21:13 Modified files: net/smokeping : Makefile net/smokeping/pkg: PLIST Log message: reinstate @newuser/@newgroup, lost in PLIST r1.13. spotted by phessler.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sebas...@cvs.openbsd.org2013/07/01 22:30:20 Modified files: geo/qlandkartegt: Makefile distinfo geo/qlandkartegt/pkg: PLIST Log message: Update QLGT to 1.7 tested and OK tobiasu@
Drop maintainership
Dear ports@ community, after finally accepting that I don't get around to actually maintain the ports I'm still listed for as MAINTAINER anymore, I kindly ask to remove me from these variables. I hope at least some people profited from my former porting efforts and no one suffered from my recent slacking in this regard. If there are issues or questions, please contact me directly since I didn't get around to read ports@ ATM. Regards ahb
Re: MAINTAINER UPDATE: geo/qlandkartegt
On Sun, Jun 30, 2013 at 02:24:43PM +0200, Sebastian Reitenbach wrote: a long overdue update to geo/qlandkartegt from 1.5.0 to 1.7.0, jumping over the 1.6 releases. In 1.6.X some basic support for Magellan devices was added. Since I don't have such device, cannot really test it ;) Otherwise, the few features I really use all the time, work well for me on amd64. OK? Played with it a little. OK tobiasu@
Re: Drop maintainership
2013/7/1 Andreas Bihlmaier andreas.bihlma...@gmx.de: Dear ports@ community, after finally accepting that I don't get around to actually maintain the ports I'm still listed for as MAINTAINER anymore, I kindly ask to remove me from these variables. I hope at least some people profited from my former porting efforts and no one suffered from my recent slacking in this regard. If there are issues or questions, please contact me directly since I didn't get around to read ports@ ATM. I'll take x11/tellico, does anyone want something else? -- WBR, Vadim Zhukov
Re: groff to mandoc
On Jun 29 15:08:12, schwa...@usta.de wrote: Hi Jan, Jan Stary wrote on Sat, Jun 29, 2013 at 02:28:55PM +0200: Certain ports require groff because that's what their manpages are written for. Manuals specifically written for groff (as opposed to for roff in general) probably exist, but i don't think that's the majority of manuals requiring groff. Rather, i'd guess that most manuals requiring groff in OpenBSD ports use low-level roff formatting (in addition to man(7) macros) that is supported by most roff implementations, not just by groff. Yes; where I said manpages for groff, I should have said the legacy manpages. Admittedly, i didn't really check the above. But note that manuals written specifically for groff would hardly be usable e.g. on Solaris clones which typically do not inlude groff but older roff implementations. If I understand it correctly, the original manpages get preformated with groff, installed into the .../cat/ directotries, and that's what the user sees eventually. Yes, that's what USE_GROFF does, see bsd.port.mk(5). I haven't found the time yet to look into the internals of the mdoc(7) vs man(7) markup, but would it make sense to try to slightly rewrite the original manpages to get rid of groff? In the ports tree at large: No. That would be a gigantic make-work project, and lots of the work would have to be redone for each update of each affected port. That's completely unrealistic. Also note that the mdoc(7) and man(7) languages are completely distinct, they do not have a single common macro. Well, roff(7) requests can be used in both, but that's bad style in the first place. So, rewriting man(7) to mdoc(7) usually requires to change every single macro, and it usually requires adding several macros to the source code. It's more like rewriting the manual, not just like sprinkling a few changes. Hm, that's what I was afraid of. In one single port, provided that you cooperate closely with upstream, they like the idea, and you know what you are doing? Yes. The example I originally had in mind was mail/procmail. It comes with # ls -1 /usr/ports/pobj/procmail-3.22/procmail-3.22/man/ Makefile Makefile.0 README formail.man lockfile.man mansed procmail.man procmailex.man procmailrc.man procmailsc.man and says Please note that the *.man files in this directory still need to be converted into their *.1 and *.5 counterparts. You can convert them by typing make in this directory or in the directory above. The man pages *.1 and *.5 can then be displayed as readable plain text by typing something like this: nroff -man procmail.1 or they can be moved to man directories in your MANPATH to be be viewed with the normal man command. Indeed, the procmail build produces a procmail.1 and others, and thats what gets preprocessed and installed with the package. I suppose the resulting *.1 is a man(7) source. Could you please enlighten me historically on what the *.man format is? The translation happens with Guenther's ./mansed, which seems to be an ad hoc sed translation of one set of macros into another. However, if upstream wants to provide manuals for Solaris clones, they will need to do automatic mdoc(7) to man(7) conversions using mandoc -mdoc -Tman in the tarball build system, like portable sudo(1) does. That works quite well now, but requires mandoc in the tarball build system, so some upstream projects may not like the idea. Well, the upstream of procmail is Philip A. Guenther. So, as an example, what would it take to convert the procmail documentation to mdoc(7), while keeping the documentation usable for systems other that OpenBSD? Is that generally possible? Is an mdoc(7) manpage, when written with compatibility in mind, acceptable for upstream that originaly wrote the manpage for groff? That depends on the taste of the upstream developers. I think moving from man(7) to mdoc(7) and using -Tman makes manuals better, but some upstream projects will certainly disagree - or simply not care at all. Reading http://www.undeadly.org/cgi?action=articlesid=20100604082319mode=expanded specifically Kristaps' Lastly, if one's manuals are in -man format, for gods sakes re-write them in -mdoc format! is what got me into this. I will try to find a small man(7) page of a GROFF-dependent port I care about and try to persuade upstream to let me rewtite into mdoc(7) and see how that goes. Or is there something in base still not converted to mdoc? Would you please suggest a small bit I could learn this on?
Re: Ninja build failures on sgi and mips64el
There's an unaligned word access in ninja's murmurhash implementation: https://github.com/martine/ninja/blob/master/src/hash_map.h We need to change unsigned int k = *(unsigned int *)data; to unsigned int k; memcpy(k, data, sizeof k); and it should fix the unaligned accesses on strict arches like sparc64 and mips. Sorry, I'm not able to fix this myself right now, but I can help upstream the fix tomorrow. (I'm of course ok with any ports fix for this.) On Mon, Jul 1, 2013 at 10:24 AM, James Turner jtur...@openbsd.org wrote: Mathew, I just wanted to let you know we have discovered some build failures on sgi and mips64el during the Build ninja using itself phase. It looks like something is segfaulting. Below is the build output although it isn't very helpful. I can test diffs on mips64el and plan on trying to compile with debug symbols to see if I can get more info out of the core file that is left. Building ninja using itself... *** Error 246 in devel/ninja (Makefile:32 'do-build': @cd /usr/obj/ports/ninja-1.3.4/ninja-1.3.4 /usr/bin/env -i CXX=c++CC=cc PYTHONUS...) *** Error 1 in devel/ninja (/usr/ports/infrastructure/mk/bsd.port.mk:2634'/usr/obj/ports/ninja-1.3.4/.build_done') *** Error 1 in devel/ninja (/usr/ports/infrastructure/mk/bsd.port.mk:2367 'build') === Exiting devel/ninja with an error /bin/sh: exit 1: not found *** Error 127 in /usr/ports (infrastructure/mk/bsd.port.subdir.mk:147'build') Error: /usr/ports/packages/mips64el/all/ninja-1.3.4.tgz does not exist -- James Turner
[update] security/assl
update security/assl to 1.4.1 please review and commit thanks Index: Makefile === RCS file: /cvs/ports/security/assl/Makefile,v retrieving revision 1.27 diff -u -p -r1.27 Makefile --- Makefile18 Apr 2013 18:47:15 - 1.27 +++ Makefile1 Jul 2013 18:19:17 - @@ -2,10 +2,10 @@ COMMENT= hide awful SSL API in a sane interface -DISTNAME= assl-1.3.0 +DISTNAME= assl-1.4.1 EPOCH= 0 CATEGORIES=security devel -SHARED_LIBS= assl6.0 +SHARED_LIBS= assl6.1 HOMEPAGE= https://opensource.conformal.com/wiki/assl MASTER_SITES= https://opensource.conformal.com/snapshots/assl/ Index: distinfo === RCS file: /cvs/ports/security/assl/distinfo,v retrieving revision 1.17 diff -u -p -r1.17 distinfo --- distinfo18 Apr 2013 18:47:15 - 1.17 +++ distinfo1 Jul 2013 18:19:17 - @@ -1,2 +1,2 @@ -SHA256 (assl-1.3.0.tar.gz) = o0/s0MmBmbcEnFB4g0kKLyYafTc6p8cxUjEJVPl3uIc= -SIZE (assl-1.3.0.tar.gz) = 119415 +SHA256 (assl-1.4.1.tar.gz) = bn5kvutZfpohNI3jCoaZkEhLSdAhItpaHoYcWzzgvy8= +SIZE (assl-1.4.1.tar.gz) = 119718
[update] sysutils/cyphertite
update sysutils/cyphertite to 1.6.2 please review and commit. thanks Index: Makefile === RCS file: /cvs/ports/sysutils/cyphertite/Makefile,v retrieving revision 1.30 diff -u -p -r1.30 Makefile --- Makefile13 Jun 2013 10:46:06 - 1.30 +++ Makefile1 Jul 2013 18:23:05 - @@ -2,7 +2,7 @@ COMMENT = tar-like secure remote deduplicating archiver -DISTNAME = cyphertite-1.6.1 +DISTNAME = cyphertite-1.6.2 CATEGORIES = sysutils archivers security HOMEPAGE = https://www.cyphertite.com/ Index: distinfo === RCS file: /cvs/ports/sysutils/cyphertite/distinfo,v retrieving revision 1.25 diff -u -p -r1.25 distinfo --- distinfo13 Jun 2013 10:46:06 - 1.25 +++ distinfo1 Jul 2013 18:23:05 - @@ -1,2 +1,2 @@ -SHA256 (cyphertite-1.6.1.tar.gz) = yYTtbKj+GNtiFxL3g3RBSkyXjZCHYSGjn3+blSPgF08= -SIZE (cyphertite-1.6.1.tar.gz) = 214029 +SHA256 (cyphertite-1.6.2.tar.gz) = hoQr5SD1bX4UG650nOh5YZJQmOPdxJiIMbO9QGblFZs= +SIZE (cyphertite-1.6.2.tar.gz) = 214692
[update] devel/libestr
update devel/libestr to 0.1.5
please review and commit.
thanks
Index: Makefile
===
RCS file: /cvs/ports/devel/libestr/Makefile,v
retrieving revision 1.6
diff -u -p -r1.6 Makefile
--- Makefile21 Mar 2013 08:45:15 - 1.6
+++ Makefile1 Jul 2013 19:02:01 -
@@ -1,7 +1,7 @@
# $OpenBSD: Makefile,v 1.6 2013/03/21 08:45:15 ajacoutot Exp $
COMMENT = library for string essentials
-DISTNAME = libestr-0.1.4
+DISTNAME = libestr-0.1.5
SHARED_LIBS += estr 0.0 # 0.0
CATEGORIES = devel
@@ -11,8 +11,7 @@ MAINTAINER = David Hill dhill@mindcry.o
# LGPLv2.1
PERMIT_PACKAGE_CDROM = Yes
-MASTER_SITES = ${HOMEPAGE}/files/download/
-
+MASTER_SITES = http://libestr.adiscon.com/files/download/
CONFIGURE_STYLE= gnu
Index: distinfo
===
RCS file: /cvs/ports/devel/libestr/distinfo,v
retrieving revision 1.2
diff -u -p -r1.2 distinfo
--- distinfo3 Jan 2013 16:05:40 - 1.2
+++ distinfo1 Jul 2013 19:02:01 -
@@ -1,2 +1,2 @@
-SHA256 (libestr-0.1.4.tar.gz) = 4wsFvDCR4sNUZNesc2stTlwFTMiD4kTJILVx5TPeheM=
-SIZE (libestr-0.1.4.tar.gz) = 329510
+SHA256 (libestr-0.1.5.tar.gz) = /5c0ZjyOc4SDXhLGUxPv4UsdfsMQ9IyXfTX2axBQZZ4=
+SIZE (libestr-0.1.5.tar.gz) = 325583
Index: pkg/PFRAG.shared
===
RCS file: pkg/PFRAG.shared
diff -N pkg/PFRAG.shared
--- pkg/PFRAG.shared16 Jan 2012 15:17:58 - 1.1.1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,2 +0,0 @@
-@comment $OpenBSD: PFRAG.shared,v 1.1.1.1 2012/01/16 15:17:58 dhill Exp $
-@lib lib/libestr.so.${LIBestr_VERSION}
Index: pkg/PLIST
===
RCS file: /cvs/ports/devel/libestr/pkg/PLIST,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 PLIST
--- pkg/PLIST 16 Jan 2012 15:17:58 - 1.1.1.1
+++ pkg/PLIST 1 Jul 2013 19:02:01 -
@@ -1,7 +1,7 @@
@comment $OpenBSD: PLIST,v 1.1.1.1 2012/01/16 15:17:58 dhill Exp $
-%%SHARED%%
include/libestr.h
lib/libestr.a
lib/libestr.la
+@lib lib/libestr.so.${LIBestr_VERSION}
lib/pkgconfig/
lib/pkgconfig/libestr.pc
Re: groff to mandoc
Hi Jan, Jan Stary wrote on Mon, Jul 01, 2013 at 05:47:41PM +0200: On Jun 29 15:08:12, schwa...@usta.de wrote: Jan Stary wrote on Sat, Jun 29, 2013 at 02:28:55PM +0200: Certain ports require groff because that's what their manpages are written for. Manuals specifically written for groff (as opposed to for roff in general) probably exist, but i don't think that's the majority of manuals requiring groff. Rather, i'd guess that most manuals requiring groff in OpenBSD ports use low-level roff formatting (in addition to man(7) macros) that is supported by most roff implementations, not just by groff. Yes; where I said manpages for groff, I should have said the legacy manpages. That's even more wrong. Most legacy manuals do not require groff but work fine with mandoc. Most manuals that do not (yet) work with mandoc just use fancy low-level roff(7) requests because the manual author (or the author of today's code generation tool the manual author chose to use) thought mixing in fancy low-level stuff would be cool. Lots of the stuff that breaks is not old. The example I originally had in mind was mail/procmail. I may have a look at that later, i have too little time right now. I'm sending this quick answer anyway such that you don't set off into the wrong direction. Is that generally possible? Is an mdoc(7) manpage, when written with compatibility in mind, acceptable for upstream that originaly wrote the manpage for groff? That depends on the taste of the upstream developers. I think moving from man(7) to mdoc(7) and using -Tman makes manuals better, but some upstream projects will certainly disagree - or simply not care at all. Reading http://www.undeadly.org/cgi?action=articlesid=20100604082319mode=expanded specifically Kristaps' Lastly, if one's manuals are in -man format, for gods sakes re-write them in -mdoc format! That's overly optimistic. At the time Kristaps wrote that, it wasn't a realistic option for portable software because mandoc -Tman didn't exist yet. Nowadays, with a bit of care, it can be done, and it isn't rocket science, but because it requires proper use of mandoc -Tman, it is still not completely trivial. Kristaps is sometimes quite excited about nice things and tends to ignore all those pesky little problems related to details somewhat. :-) is what got me into this. I will try to find a small man(7) page of a GROFF-dependent port I care about and try to persuade upstream to let me rewtite into mdoc(7) and see how that goes. Oh well, but please make sure *first* you yourself understand thoroughly what you are talking about. Right now, that doesn't seem to be the case, yet. Misleading upstream projects into *about* the right direction but subtly mixing the education with bad advice is *not* helping. Let me be clear about that: Before you know both the man(7) and the mdoc(7) language very well, have a very good understanding of their strengthes, weaknesses and differences, and have quite some experience writing mdoc(7) code of good quality, you should not attempt to educate upstream, or it will end up in confusion and anger. Or is there something in base still not converted to mdoc? Why not search for such files yourself? Watch out for lines starting with .TH. But make sure you exclude files maintained upstream. Converting stuff in base would be counter-productive if that causes headaches for the next update. In particular, the following should not be converted: - Perl stuff - binutils - any gcc versions - curses - GNU cvs - bind and nsd - lynx - OpenSSL - ... maybe more ... I wouldn't be surprised if all the work has already been done. Yours, Ingo
Re: Ninja build failures on sgi and mips64el
This fixes the build on mips64. On Mon, Jul 01, 2013 at 10:36:09AM -0700, Matthew Dempsky wrote: There's an unaligned word access in ninja's murmurhash implementation: https://github.com/martine/ninja/blob/master/src/hash_map.h We need to change unsigned int k = *(unsigned int *)data; to unsigned int k; memcpy(k, data, sizeof k); and it should fix the unaligned accesses on strict arches like sparc64 and mips. Sorry, I'm not able to fix this myself right now, but I can help upstream the fix tomorrow. (I'm of course ok with any ports fix for this.) On Mon, Jul 1, 2013 at 10:24 AM, James Turner jtur...@openbsd.org wrote: Mathew, I just wanted to let you know we have discovered some build failures on sgi and mips64el during the Build ninja using itself phase. It looks like something is segfaulting. Below is the build output although it isn't very helpful. I can test diffs on mips64el and plan on trying to compile with debug symbols to see if I can get more info out of the core file that is left. Building ninja using itself... *** Error 246 in devel/ninja (Makefile:32 'do-build': @cd /usr/obj/ports/ninja-1.3.4/ninja-1.3.4 /usr/bin/env -i CXX=c++CC=cc PYTHONUS...) *** Error 1 in devel/ninja (/usr/ports/infrastructure/mk/bsd.port.mk:2634'/usr/obj/ports/ninja-1.3.4/.build_done') *** Error 1 in devel/ninja (/usr/ports/infrastructure/mk/bsd.port.mk:2367 'build') === Exiting devel/ninja with an error /bin/sh: exit 1: not found *** Error 127 in /usr/ports (infrastructure/mk/bsd.port.subdir.mk:147'build') Error: /usr/ports/packages/mips64el/all/ninja-1.3.4.tgz does not exist -- James Turner -- Regards, Jasper Lievisse Adriaanse, Engineering team M:tier
Re: Ninja build failures on sgi and mips64el
On Mon, Jul 1, 2013 at 10:37 PM, Jasper Lievisse Adriaanse jas...@openbsd.org wrote: This fixes the build on mips64. Thanks a lot, Mathew. Please go ahead and commit it, you or Jasper ;) Ciao, David On Mon, Jul 01, 2013 at 10:36:09AM -0700, Matthew Dempsky wrote: There's an unaligned word access in ninja's murmurhash implementation: https://github.com/martine/ninja/blob/master/src/hash_map.h We need to change unsigned int k = *(unsigned int *)data; to unsigned int k; memcpy(k, data, sizeof k); and it should fix the unaligned accesses on strict arches like sparc64 and mips. Sorry, I'm not able to fix this myself right now, but I can help upstream the fix tomorrow. (I'm of course ok with any ports fix for this.) On Mon, Jul 1, 2013 at 10:24 AM, James Turner jtur...@openbsd.org wrote: Mathew, I just wanted to let you know we have discovered some build failures on sgi and mips64el during the Build ninja using itself phase. It looks like something is segfaulting. Below is the build output although it isn't very helpful. I can test diffs on mips64el and plan on trying to compile with debug symbols to see if I can get more info out of the core file that is left. Building ninja using itself... *** Error 246 in devel/ninja (Makefile:32 'do-build': @cd /usr/obj/ports/ninja-1.3.4/ninja-1.3.4 /usr/bin/env -i CXX=c++CC=cc PYTHONUS...) *** Error 1 in devel/ninja (/usr/ports/infrastructure/mk/bsd.port.mk:2634'/usr/obj/ports/ninja-1.3.4/.build_done') *** Error 1 in devel/ninja (/usr/ports/infrastructure/mk/bsd.port.mk:2367 'build') === Exiting devel/ninja with an error /bin/sh: exit 1: not found *** Error 127 in /usr/ports (infrastructure/mk/bsd.port.subdir.mk:147'build') Error: /usr/ports/packages/mips64el/all/ninja-1.3.4.tgz does not exist -- James Turner -- Regards, Jasper Lievisse Adriaanse, Engineering team M:tier
Re: groff to mandoc
On Mon, 1 Jul 2013, Jan Stary wrote: ... Well, the upstream of procmail is Philip A. Guenther. Not really. procmail has been an orphan for about a decade: the cvs repository was converted to subversion...and then my access stopped working, Stephen wasn't responding, and I found I had better things to do. Philip
Re: Ninja build failures on sgi and mips64el
Jasper (or someone) will have to. My OpenBSD workstation is down until at least tomorrow. Glad to hear that fix worked though. On Mon, Jul 1, 2013 at 1:40 PM, David Coppa dco...@gmail.com wrote: On Mon, Jul 1, 2013 at 10:37 PM, Jasper Lievisse Adriaanse jas...@openbsd.org wrote: This fixes the build on mips64. Thanks a lot, Mathew. Please go ahead and commit it, you or Jasper ;) Ciao, David On Mon, Jul 01, 2013 at 10:36:09AM -0700, Matthew Dempsky wrote: There's an unaligned word access in ninja's murmurhash implementation: https://github.com/martine/ninja/blob/master/src/hash_map.h We need to change unsigned int k = *(unsigned int *)data; to unsigned int k; memcpy(k, data, sizeof k); and it should fix the unaligned accesses on strict arches like sparc64 and mips. Sorry, I'm not able to fix this myself right now, but I can help upstream the fix tomorrow. (I'm of course ok with any ports fix for this.) On Mon, Jul 1, 2013 at 10:24 AM, James Turner jtur...@openbsd.org wrote: Mathew, I just wanted to let you know we have discovered some build failures on sgi and mips64el during the Build ninja using itself phase. It looks like something is segfaulting. Below is the build output although it isn't very helpful. I can test diffs on mips64el and plan on trying to compile with debug symbols to see if I can get more info out of the core file that is left. Building ninja using itself... *** Error 246 in devel/ninja (Makefile:32 'do-build': @cd /usr/obj/ports/ninja-1.3.4/ninja-1.3.4 /usr/bin/env -i CXX=c++CC=cc PYTHONUS...) *** Error 1 in devel/ninja (/usr/ports/infrastructure/mk/bsd.port.mk:2634'/usr/obj/ports/ninja-1.3.4/.build_done') *** Error 1 in devel/ninja (/usr/ports/infrastructure/mk/bsd.port.mk:2367 'build') === Exiting devel/ninja with an error /bin/sh: exit 1: not found *** Error 127 in /usr/ports (infrastructure/mk/bsd.port.subdir.mk:147'build') Error: /usr/ports/packages/mips64el/all/ninja-1.3.4.tgz does not exist -- James Turner -- Regards, Jasper Lievisse Adriaanse, Engineering team M:tier
Re: Ninja build failures on sgi and mips64el
On Mon, Jul 01, 2013 at 10:37:57PM +0200, Jasper Lievisse Adriaanse wrote: This fixes the build on mips64. mips64el as well. On Mon, Jul 01, 2013 at 10:36:09AM -0700, Matthew Dempsky wrote: There's an unaligned word access in ninja's murmurhash implementation: https://github.com/martine/ninja/blob/master/src/hash_map.h We need to change unsigned int k = *(unsigned int *)data; to unsigned int k; memcpy(k, data, sizeof k); and it should fix the unaligned accesses on strict arches like sparc64 and mips. Sorry, I'm not able to fix this myself right now, but I can help upstream the fix tomorrow. (I'm of course ok with any ports fix for this.) On Mon, Jul 1, 2013 at 10:24 AM, James Turner jtur...@openbsd.org wrote: Mathew, I just wanted to let you know we have discovered some build failures on sgi and mips64el during the Build ninja using itself phase. It looks like something is segfaulting. Below is the build output although it isn't very helpful. I can test diffs on mips64el and plan on trying to compile with debug symbols to see if I can get more info out of the core file that is left. Building ninja using itself... *** Error 246 in devel/ninja (Makefile:32 'do-build': @cd /usr/obj/ports/ninja-1.3.4/ninja-1.3.4 /usr/bin/env -i CXX=c++CC=cc PYTHONUS...) *** Error 1 in devel/ninja (/usr/ports/infrastructure/mk/bsd.port.mk:2634'/usr/obj/ports/ninja-1.3.4/.build_done') *** Error 1 in devel/ninja (/usr/ports/infrastructure/mk/bsd.port.mk:2367 'build') === Exiting devel/ninja with an error /bin/sh: exit 1: not found *** Error 127 in /usr/ports (infrastructure/mk/bsd.port.subdir.mk:147'build') Error: /usr/ports/packages/mips64el/all/ninja-1.3.4.tgz does not exist -- James Turner -- Regards, Jasper Lievisse Adriaanse, Engineering team M:tier -- James Turner
update: node-typescript-0.9.0.1
The attached diff updates node-typscript to 0.9.0.1. It also fixes a
problem where tsc had the wrong permissions and wasn't executable. Is
the NPM_VERSION and PKGNAME the correct way to handle this update?
pkg_add doesn't seem to support the 0.9.0-1 scheme.
Release announcement can be found here [0]. Tested on amd64. oks?
[0]
http://blogs.msdn.com/b/typescript/archive/2013/06/28/announcing-typescript-0-9-0-1.aspx
--
James Turner
Index: Makefile
===
RCS file: /cvs/ports/lang/node-typescript/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -u -p -r1.1.1.1 Makefile
--- Makefile19 Jun 2013 22:37:38 - 1.1.1.1
+++ Makefile2 Jul 2013 01:14:35 -
@@ -2,8 +2,9 @@
COMMENT = typed superset of JavaScript
-NPM_VERSION = 0.9.0
+NPM_VERSION = 0.9.0-1
NPM_NAME = typescript
+PKGNAME = node-typescript-0.9.0.1
CATEGORIES = lang
MAINTAINER = James Turner ja...@calminferno.net
@@ -24,6 +25,7 @@ do-install:
mkdir ${PREFIX}/lib/node_modules; \
mv ${WRKDIR}/node_modules/${NPM_NAME} ${PREFIX}/lib/node_modules; \
chown -R ${SHAREOWN}:${SHAREGRP} ${PREFIX}/lib/node_modules; \
+ chmod 755 ${PREFIX}/lib/node_modules/${NPM_NAME}/bin/tsc
ln -s ${TRUEPREFIX}/lib/node_modules/${NPM_NAME}/bin/tsc
${PREFIX}/bin/tsc
.include bsd.port.mk
Index: distinfo
===
RCS file: /cvs/ports/lang/node-typescript/distinfo,v
retrieving revision 1.1.1.1
diff -u -p -u -p -r1.1.1.1 distinfo
--- distinfo19 Jun 2013 22:37:38 - 1.1.1.1
+++ distinfo2 Jul 2013 01:14:35 -
@@ -1,2 +1,2 @@
-SHA256 (typescript-0.9.0.tgz) = mOS7MmUhgxpJIyA6ZHZbOYO8bwW5Zto6ZHGawd4z//8=
-SIZE (typescript-0.9.0.tgz) = 620263
+SHA256 (typescript-0.9.0-1.tgz) = eXb6jGET9eCJEhEdC7tsiC5A2hw+eu39I2slEV7GBT8=
+SIZE (typescript-0.9.0-1.tgz) = 621267
Re: Ruby security releases for CVE-2013-4073
On 06/27 03:31, Jeremy Evans wrote: Ruby 1.8.7, 1.9.3, and 2.0.0 had security releases today to fix CVE-2013-4073: Hostname check bypassing vulnerability in SSL client. http://www.ruby-lang.org/en/news/2013/06/27/hostname-check-bypassing-vulnerability-in-openssl-client-cve-2013-4073/ Exploitation of this vulnerability requires that a trusted CA issue a certificate with a null byte in the subjectAltName field. This will likely be the last patch release of ruby 1.8.7, as it becomes unsupported upstream next week. The 1.9.3 and 2.0.0 releases also contain other bugfixes. Unfortunately, upstream got sloppy and changed ABI in a patch release (removing a function, adding some new functions), so this bumps the majors on libruby19.so and libruby20.so. Tested on i386. Compiles fine on amd64, but I still need to do some additional testing there. Assuming no problems, I will be commiting this next week. There have been regressions reported with these new releases, so I won't be committing this until they are fixed: https://bugs.ruby-lang.org/issues/8575 Thanks, Jeremy
