Enable OpenBSD NVMe disk support in smartmontools
The diff below enables smartmontools (smartctl & smartd) support for
NVMe disks on -current kernels with the latest nvme(4) passthrough
commits.
Obvious features tested and work for me on various amd64 boxes and my m1
macmini.
ian@ has also succesfully tested it.
Thoughts? OK?
--
Ken
Index: Makefile
===
RCS file: /cvs/ports/sysutils/smartmontools/Makefile,v
diff -u -p -u -p -r1.50 Makefile
--- Makefile27 Sep 2023 17:16:34 - 1.50
+++ Makefile26 May 2024 14:54:25 -
@@ -2,6 +2,7 @@ COMMENT=control and monitor storage sy
# XXX at update time check whether C++11 is actually needed
DISTNAME= smartmontools-7.4
+REVISION= 0
CATEGORIES=sysutils
HOMEPAGE= https://www.smartmontools.org/
Index: patches/patch-openbsd_nvme_ioctl_h
===
RCS file: patches/patch-openbsd_nvme_ioctl_h
diff -N patches/patch-openbsd_nvme_ioctl_h
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-openbsd_nvme_ioctl_h 26 May 2024 14:54:25 -
@@ -0,0 +1,78 @@
+Index: openbsd_nvme_ioctl.h
+--- openbsd_nvme_ioctl.h.orig
openbsd_nvme_ioctl.h
+@@ -0,0 +1,74 @@
++/*
++ * Copyright (c) 2024 Kenneth R Westerback
++ *
++ * Permission to use, copy, modify, and distribute this software for any
++ * purpose with or without fee is hereby granted, provided that the above
++ * copyright notice and this permission notice appear in all copies.
++ *
++ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
++ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
++ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
++ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
++ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
++ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
++ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
++ */
++
++#define NVME_PASSTHROUGH_CMD_IOWR('n', 0, struct
nvme_pt_cmd)
++
++struct nvme_pt_status {
++ int ps_dv_unit;
++ int ps_nsid;
++ int ps_flags;
++#define NVME_CQE_SCT(_f) ((_f) & (0x07 << 9))
++#define NVME_CQE_SCT_GENERIC (0x00 << 9)
++#define NVME_CQE_SC(_f) ((_f) & (0xff << 1))
++#define NVME_CQE_SC_SUCCESS (0x00 << 1)
++ uint32_tps_csts;
++ uint32_tps_cc;
++};
++
++#define BIO_MSG_COUNT 5
++#define BIO_MSG_LEN 128
++
++struct bio_msg {
++ int bm_type;
++ charbm_msg[BIO_MSG_LEN];
++};
++
++struct bio_status {
++ charbs_controller[16];
++ int bs_status;
++ int bs_msg_count;
++ struct bio_msg bs_msgs[BIO_MSG_COUNT];
++};
++
++struct bio {
++ void*bio_cookie;
++ struct bio_status bio_status;
++};
++
++struct nvme_pt_cmd {
++ /* Commands may arrive via /dev/bio. */
++ struct bio pt_bio;
++
++ /* The sqe fields that the caller may specify. */
++ uint8_t pt_opcode;
++ uint32_tpt_nsid;
++ uint32_tpt_cdw10;
++ uint32_tpt_cdw11;
++ uint32_tpt_cdw12;
++ uint32_tpt_cdw13;
++ uint32_tpt_cdw14;
++ uint32_tpt_cdw15;
++
++ caddr_t pt_status;
++ uint32_tpt_statuslen;
++
++ caddr_t pt_databuf; /* User space address. */
++ uint32_tpt_databuflen; /* Length of buffer. */
++};
++
++#define nvme_completion_is_error(_flags)
\
++ ((NVME_CQE_SC(_flags) != NVME_CQE_SC_SUCCESS) \
++ || (NVME_CQE_SCT(_flags) != NVME_CQE_SCT_GENERIC))
Index: patches/patch-os_openbsd_cpp
===
RCS file: patches/patch-os_openbsd_cpp
diff -N patches/patch-os_openbsd_cpp
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-os_openbsd_cpp26 May 2024 14:54:25 -
@@ -0,0 +1,196 @@
+Index: os_openbsd.cpp
+--- os_openbsd.cpp.orig
os_openbsd.cpp
+@@ -14,6 +14,7 @@
+
+ #include "atacmds.h"
+ #include "scsicmds.h"
++#include "nvmecmds.h"
+ #include "utility.h"
+ #include "os_openbsd.h"
+
+@@ -22,11 +23,29 @@
+ #include
+ #include
+
++// based on OpenBSD "/usr/include/dev/ic/nvmeio.h" &&
"/usr/include/dev/biovar.h"
++#include "openbsd_nvme_ioctl.h" // NVME_PASSTHROUGH_CMD,
nvme_completion_is_error
+ const char * os_openbsd_cpp_cvsid = "$Id: os_openbsd.cpp 5393 2022-05-29
05:08:10Z dpgilbert $"
+ OS_OPENBSD_H_CVSID;
+
+ #define ARGUSED(x) ((void)(x))
+
More OCaml ports for /dev/null?
My full table is on cvs as ~krw/ocamlports.org. I have devel/ocaml-uutf lang/ocaml-camlp5 math/ocaml-num math/ocaml-zarith devel/dune as candidates for removal since they don't appear to be used by any end-user program. For anyone who hasn't stumbled across it, there is an inspirational video on youtube about the OCaml Platform vision. Presented by a grizzled veteran of the OCaml wars who looks tantalizingly familiar. https://m.youtube.com/watch?v=oyeKLAYPmQQ Ken
Re: lang/ocaml minor update
On Sat., Apr. 18, 2020, 4:59 p.m. Christian Weisgerber, wrote: > On 2020-04-17, Christopher Zimmermann wrote: > > > here's a straightforward minor update of OCaml. > > Since every update to OCaml seems to cause some breakage that needs > sorting out afterwards, I suggest to hold off on this until after > the release. > > -- > Christian "naddy" Weisgerber na...@mips.inka.d > e > And after release we could just jump to 4.10.0. I am not following ocaml minor releases close enough to comment on how important 4.09.1 is. FYI, just updated my opam based ocaml install to 4.10.0 and everything still compiles. Ken
Re: [pretest] emacs-27.0.91
On Sun., Jul. 5, 2020, 8:35 p.m. Jeremie Courreges-Anglas, wrote: > > First, thank you Timo, Ken and Matthieu for the feedback so far. > > On Sun, Jul 05 2020, Kenneth R Westerback wrote: > > On Sat, Jul 04, 2020 at 03:15:05PM +0200, Jeremie Courreges-Anglas wrote: > >> On Sat, Jul 04 2020, Timo Myyr?? wrote: > >> > >> [...] > >> > >> > Is there any particular reason why json is disabled in configure? > >> > >> Nope, I just forgot to mention that I had disabled it for no particular > >> reason. Let's blame it on Miod's gentiane. > >> > >> > It provides massive speed up for emacs-lsp mode so at least I'd like > to see it > >> > included. > >> > >> Oh, I had not looked at lsp-mode. Fine with me if people find fast json > >> support useful. > >> > >> And since Ken asked for it, here are some fresh (unsigned) amd64 > packages: > >> > >> https://russell.wxcvbn.org/pub/OpenBSD/snapshots/emacs-pretest/ > > > > Took a bit to remember how to configure PKG_PATH so pkg_add -u would > > work with local emacs package and remote supporting packages. But > > success! > > Hah. Here's the magic: > > env TRUSTED_PKG_PATH= > https://russell.wxcvbn.org/pub/OpenBSD/snapshots/emacs-pretest/ pkg_add > -d emacs > > -d to install the debug symbols, in case you experience a crash. > > > Now running the package and already noticed a BIG > > improvement. 'emacsclient -a "" -c' now seems to actually work when I > > try to reply to emails like this from neomutt. Previously I had to > > manually ensure emacs --daemon was already running. > > > > It did claim that package 'cl' is deprecated. Now I have to go look > > that up. :-) > > Hmm like Matthieu you probably have an extension which uses cl. FWIW > the release notes say: > > ** The 'cl' package is now officially deprecated in favor of 'cl-lib'. > Still looking for where I managed to invoke cl. Mom > Still, I would expect this library to still work like it did previously, > so people should have time to handle this deprecation. Did you see > runtime differences? > Not yet > >> And since someone else asked, *this is a preview only*, I'm not going > >> to commit an update to a pretest release unless you folks significantly > >> bribe me. ;) > > > > Following request for information does not in any way > > represent the OpenBSD Foundation or imply access to that organization's > > vast resources! > > > > Define "significant". :-) > > Maybe just a pint of beer or cider at the next hackathon? :) > Given the current state of the world and consequent delays in holding hackathons I am willing to commit to this level of bribe, confident we will all have forgotten about it when the time comes. :-) > More seriously, if the emacsclient changes help you, and if people from > base would like to get rid of some hacks we keep for emacs unexec, > The improvement in my workflow is not significant enough for me to worry about waiting for more tests. So I'm easy either way. I could consider an update to this pretest release reasonable. But there's > really some mess going on with how diffs are hilighted in my setup, though. > > -- > jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE > I have noticed occasional odd colouring of diffs too. I think it has something to do with recent search targets. Ken >
Re: [update] emacs-27.2
Got a emacs-27.2-gtk3 package I can download?
Ken
On Sat., Apr. 3, 2021, 3:32 p.m. Jeremie Courreges-Anglas,
wrote:
>
> Update to emacs-27.2, a bugfix only release, except maybe for an update
> of Org Mode. The fix for GTK+3 from yazuoka@ has been merged.
>
> Since emacs-27 doesn't play linking games any more, closs-platform
> tests are less relevant (but still welcome). And since release is
> approaching I'd prefer to get confirmations that it doesn't break your
> setup.
>
> oks welcome too.
>
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/editors/emacs/Makefile,v
> retrieving revision 1.97
> diff -u -p -r1.97 Makefile
> --- Makefile28 Feb 2021 10:47:09 - 1.97
> +++ Makefile3 Apr 2021 17:00:32 -
> @@ -2,8 +2,7 @@
>
> COMMENT= GNU editor: extensible, customizable,
> self-documenting
>
> -VERSION= 27.1
> -REVISION= 0
> +VERSION= 27.2
> DISTNAME= emacs-${VERSION}
>
> CATEGORIES=editors
> Index: distinfo
> ===
> RCS file: /cvs/ports/editors/emacs/distinfo,v
> retrieving revision 1.14
> diff -u -p -r1.14 distinfo
> --- distinfo23 Aug 2020 09:55:00 - 1.14
> +++ distinfo3 Apr 2021 17:00:32 -
> @@ -1,2 +1,2 @@
> -SHA256 (emacs-27.1.tar.xz) = SkwSj5FfyTfWHt/Cc8mBBnEbVAyb481dLiubWy8XLkE=
> -SIZE (emacs-27.1.tar.xz) = 43752012
> +SHA256 (emacs-27.2.tar.xz) = tKfMTnjmPzeGJOCRkhW5EK9bsqCvyBn60pgnLp9Awbk=
> +SIZE (emacs-27.2.tar.xz) = 44624480
> Index: patches/patch-src_gtkutil_c
> ===
> RCS file: patches/patch-src_gtkutil_c
> diff -N patches/patch-src_gtkutil_c
> --- patches/patch-src_gtkutil_c 28 Feb 2021 10:47:09 - 1.1
> +++ /dev/null 1 Jan 1970 00:00:00 -
> @@ -1,51 +0,0 @@
> -$OpenBSD: patch-src_gtkutil_c,v 1.1 2021/02/28 10:47:09 yasuoka Exp $
> -
> -Avoid crashes in Mew due to corrupted tool-bar label
> -https://debbugs.gnu.org/cgi/bugreport.cgi?bug=46791
> -
> -Index: src/gtkutil.c
> src/gtkutil.c.orig
> -+++ src/gtkutil.c
> -@@ -5019,11 +5019,10 @@ update_frame_tool_bar (struct frame *f)
> - GtkWidget *wbutton = NULL;
> - Lisp_Object specified_file;
> - bool vert_only = ! NILP (PROP (TOOL_BAR_ITEM_VERT_ONLY));
> -- const char *label
> -- = (EQ (style, Qimage) || (vert_only && horiz)) ? NULL
> -- : STRINGP (PROP (TOOL_BAR_ITEM_LABEL))
> -- ? SSDATA (PROP (TOOL_BAR_ITEM_LABEL))
> -- : "";
> -+ Lisp_Object label
> -+ = (EQ (style, Qimage) || (vert_only && horiz))
> -+ ? Qnil
> -+ : PROP (TOOL_BAR_ITEM_LABEL);
> -
> - ti = gtk_toolbar_get_nth_item (GTK_TOOLBAR (wtoolbar), j);
> -
> -@@ -5136,8 +5135,11 @@ update_frame_tool_bar (struct frame *f)
> -
> - /* If there is an existing widget, check if it's stale; if so,
> -remove it and make a new tool item from scratch. */
> -- if (ti && xg_tool_item_stale_p (wbutton, stock_name, icon_name,
> --img, label, horiz))
> -+ if (ti && xg_tool_item_stale_p (wbutton, stock_name, icon_name,
> img,
> -+NILP (label)
> -+? NULL
> -+: STRINGP (label) ? SSDATA (label) :
> "",
> -+horiz))
> - {
> - gtk_container_remove (GTK_CONTAINER (wtoolbar),
> - GTK_WIDGET (ti));
> -@@ -5194,7 +5196,11 @@ update_frame_tool_bar (struct frame *f)
> - #else
> - if (w) gtk_misc_set_padding (GTK_MISC (w), hmargin, vmargin);
> - #endif
> -- ti = xg_make_tool_item (f, w, &wbutton, label, i, horiz,
> text_image);
> -+ ti = xg_make_tool_item (f, w, &wbutton,
> -+NILP (label)
> -+? NULL
> -+: STRINGP (label) ? SSDATA (label) : "",
> -+i, horiz, text_image);
> - gtk_toolbar_insert (GTK_TOOLBAR (wtoolbar), ti, j);
> - }
> -
> Index: pkg/PLIST
> ===
> RCS file: /cvs/ports/editors/emacs/pkg/PLIST,v
> retrieving revision 1.25
> diff -u -p -r1.25 PLIST
> --- pkg/PLIST 23 Aug 2020 09:55:01 - 1.25
> +++ pkg/PLIST 3 Apr 2021 17:00:32 -
> @@ -1026,6 +1026,7 @@ share/emacs/${VERSION}/etc/tutorials/TUT
> share/emacs/${VERSION}/etc/tutorials/TUTORIAL.th
> share/emacs/${VERSION}/etc/tutorials/TUTORIAL.translators
> share/emacs/${VERSION}/etc/tutorials/TUTORIAL.zh
> +share/emacs/${VERSION}/etc/w32-feature.el
> share/emacs/${VERSION}/etc/yow.lines
> share/emacs/${VERSION}/lisp/
> share/emacs/${VERSION}/lisp/COPYING
> @@ -3346,6 +3347,8 @@ share/emacs/${VERSION}/lisp/org/org-plot
> share/emacs/${VERSION}/lisp/org
Re: [opam-devel] openbsd ocaml 4.02.3 + opam 1.2.2 upgrade
On 16 August 2015 at 10:02, Anil Madhavapeddy wrote: > On 14 Aug 2015, at 15:40, Anil Madhavapeddy wrote: >> >> On 3 Aug 2015, at 18:58, Anil Madhavapeddy wrote: >>> >>> This rather large ports diff does an update of the OCaml ports to 4.02.3: >>> http://www.recoil.org/~avsm/openbsd-patches/ocaml-4.02.3.patch.txt >>> >>> It bumps the REVISION of most of the untouched OCaml ports since binary >>> compat is not preserved across OCaml revisions. >>> >>> Any tests on non-x86 would be appreciated, especially ARM with native code. >> >> Here's a followup OCaml 4.02.3 patch that is now suitable for wider testing. >> I've run it on amd64 and sparc64 and am doing a complete bulk rebuild that >> isn't >> complete yet. >> >> Full patch: >> http://www.recoil.org/~avsm/openbsd-patches/ocaml-4.02.3-2.patch.txt >> > > And here's a third patchset with some fixes thanks to a bulk build by krw > http://recoil.org/~avsm/openbsd-patches/ocaml-4.02.3-3.patch.txt > > There's only one known failure now in ocaml-camlimages, and the rest all > builds on sparc64 as well. > > -a > Using this -3 version, the i386 build works except for ocaml-camlimages, as expected. Ken
Re: [opam-devel] openbsd ocaml 4.02.3 + opam 1.2.2 upgrade
On 17 August 2015 at 15:30, Anil Madhavapeddy wrote: > On 16 Aug 2015, at 09:18, Jonathan Gray wrote: >> >> On Sun, >> >> I built coccinelle on armv7 with the -2 version of the patch without >> problem. It appears this is not native as >> infrastructure/mk/arch-defines.mk has: >> OCAML_NATIVE_ARCHS = i386 sparc amd64 >> OCAML_NATIVE_DYNLINK_ARCHS = i386 amd64 >> ? >> >> I'm not really in a position to do a bulk build but if there is some >> sort of ocaml regression test or the like you'd like run let me know. > > Thanks! After your and krw's tests, the final -4 patchset here should > build all the ports on everything: > > http://recoil.org/~avsm/openbsd-patches/ocaml-4.02.3-4.patch.txt > > OCaml does support ARM native code, but our port currently doesn't > use it until the configure glue is in. I'll have a followup patch > to enable this, but got sidetracked with compiling up a custom u-Boot > for my Cubieboard2 since the current snapshots don't seem to boot > successfully on it. For now, the portable bytecode is sufficient > (but there aren't any interesting ARM-specific regress tests until > native code support lands). > > Would a ports person be able to give me an ok to commit the patchset? > > -a Firing up -4 on my i386 test box while you wait for the ports@ ok. :-) What was the issue with ocaml-camlimage? Ken
Re: [opam-devel] openbsd ocaml 4.02.3 + opam 1.2.2 upgrade
On 17 August 2015 at 15:37, Kenneth Westerback wrote: > On 17 August 2015 at 15:30, Anil Madhavapeddy wrote: >> On 16 Aug 2015, at 09:18, Jonathan Gray wrote: >>> >>> On Sun, >>> >>> I built coccinelle on armv7 with the -2 version of the patch without >>> problem. It appears this is not native as >>> infrastructure/mk/arch-defines.mk has: >>> OCAML_NATIVE_ARCHS = i386 sparc amd64 >>> OCAML_NATIVE_DYNLINK_ARCHS = i386 amd64 >>> ? >>> >>> I'm not really in a position to do a bulk build but if there is some >>> sort of ocaml regression test or the like you'd like run let me know. >> >> Thanks! After your and krw's tests, the final -4 patchset here should >> build all the ports on everything: >> >> http://recoil.org/~avsm/openbsd-patches/ocaml-4.02.3-4.patch.txt >> >> OCaml does support ARM native code, but our port currently doesn't >> use it until the configure glue is in. I'll have a followup patch >> to enable this, but got sidetracked with compiling up a custom u-Boot >> for my Cubieboard2 since the current snapshots don't seem to boot >> successfully on it. For now, the portable bytecode is sufficient >> (but there aren't any interesting ARM-specific regress tests until >> native code support lands). >> >> Would a ports person be able to give me an ok to commit the patchset? >> >> -a > > Firing up -4 on my i386 test box while you wait for the ports@ ok. :-) > > What was the issue with ocaml-camlimage? > > Ken i386 bulk build finished with no problems. Well, no problems related to ocaml. Just my usual tmpfs losing a file or two issues. :-) Ken
Re: [wip] clisp-2.49
I can probably set up build tests on i386 and sparc64 and eventually
macppc if that would help.
Ken
On 28 September 2015 at 19:39, Jérémie Courrèges-Anglas wrote:
>
> I've had several tentative diffs to update clisp, but every time
> I delete them because of frustrations with the build system.
>
> This has to stop!
>
> Here's a tentative diff, probably not perfect. I did not enable the use
> of shared modules, cause I don't know how to use them. There are a few
> missing entries in the PLIST, I did not investigate further yet.
>
> Passes make test, builds a working sbcl on amd64. Dunno about other
> archs.
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/lang/clisp/Makefile,v
> retrieving revision 1.43
> diff -u -p -r1.43 Makefile
> --- Makefile21 Mar 2013 08:46:32 - 1.43
> +++ Makefile28 Sep 2015 23:07:04 -
> @@ -4,8 +4,7 @@ ONLY_FOR_ARCHS =amd64 i386 powerpc spar
>
> COMMENT = ANSI Common Lisp implementation
>
> -DISTNAME= clisp-2.48
> -REVISION = 3
> +DISTNAME= clisp-2.49
> CATEGORIES=lang
> HOMEPAGE= http://clisp.cons.org/
> MAINTAINER = Joshua Elsasser
> @@ -35,7 +34,9 @@ CONFIGURE_ARGS= --fsstnd=openbsd \
> --docdir=${PREFIX}/share/doc/clisp \
> --elispdir=${PREFIX}/share/emacs/site-lisp \
> --vimdir=${PREFIX}/share/doc/clisp \
> - --srcdir=${WRKSRC} ${WRKBUILD}
> + --srcdir=${WRKSRC} ${WRKBUILD} \
> + --without-dynamic-modules
> +
> CONFIGURE_ENV =ac_cv_prog_DVIPDF=''
>
> .if ${MACHINE_ARCH} == "sparc64"
> @@ -49,5 +50,8 @@ LDFLAGS +=-nopie
> .else
> CONFIGURE_ARGS += --without-gmalloc
> .endif
> +
> +pre-build:
> + ln -sf ${LOCALBASE}/bin/gmake ${WRKDIR}/bin/make
>
> .include
> Index: distinfo
> ===
> RCS file: /cvs/ports/lang/clisp/distinfo,v
> retrieving revision 1.10
> diff -u -p -r1.10 distinfo
> --- distinfo18 Jan 2015 03:14:18 - 1.10
> +++ distinfo28 Sep 2015 18:58:02 -
> @@ -1,2 +1,2 @@
> -SHA256 (clisp-2.48.tar.bz2) = Bbg/VghZojZ5zPwHOhKKU3f+lInXNEMaPcMu+I8MPcI=
> -SIZE (clisp-2.48.tar.bz2) = 7885098
> +SHA256 (clisp-2.49.tar.bz2) = gTL/NTr6pw5rGTZ6Ja49WkNicnnCVkfCIGQf7QD46JA=
> +SIZE (clisp-2.49.tar.bz2) = 8091011
> Index: patches/patch-configure
> ===
> RCS file: /cvs/ports/lang/clisp/patches/patch-configure,v
> retrieving revision 1.3
> diff -u -p -r1.3 patch-configure
> --- patches/patch-configure 7 Jan 2010 10:55:28 - 1.3
> +++ patches/patch-configure 28 Sep 2015 23:14:55 -
> @@ -1,7 +1,7 @@
> $OpenBSD: patch-configure,v 1.3 2010/01/07 10:55:28 edd Exp $
> configure.orig Thu Jan 15 08:37:34 2009
> -+++ configure Wed Dec 30 01:35:49 2009
> -@@ -389,7 +389,7 @@ do
> +--- configure.orig Mon Dec 14 15:37:22 2009
> configure Tue Sep 29 01:08:02 2015
> +@@ -383,7 +383,7 @@ do
> passnext=both ;;
>
> --elispdir=* | --elispdi=* | --elispd=* | --elisp=* | --elis=* |
> --eli=* | --el=*)
> @@ -10,7 +10,7 @@ $OpenBSD: patch-configure,v 1.3 2010/01/
> makemake_args="$makemake_args --elispdir="`getarg "$arg"` ;;
>
> --elispdir | --elispdi | --elispd | --elisp | --elis | --eli | --el)
> -@@ -399,7 +399,7 @@ do
> +@@ -393,7 +393,7 @@ do
> passnext=both ;;
>
> --vimdir=* | --vimdi=* | --vimd=* | --vim=* | --vi=*)
> @@ -19,7 +19,7 @@ $OpenBSD: patch-configure,v 1.3 2010/01/
> makemake_args="$makemake_args --vimdir="`getarg "$arg"` ;;
>
> --vimdir | --vimdi | --vimd | --vim | --vi)
> -@@ -744,8 +744,7 @@ stacksizelimit=`ulimit -s 2>/dev/null || :` # cygwin /
> +@@ -723,8 +723,7 @@ stacksizelimit=`ulimit -s 2>/dev/null || :` # cygwin /
> # need 3 separate test calls because of "integer expression expected" errors
> # when $stacksizelimit is "" or "unlimited" (no short-circuiting!)
> set +e;
> Index: patches/patch-src_clisp-link_in
> ===
> RCS file: /cvs/ports/lang/clisp/patches/patch-src_clisp-link_in,v
> retrieving revision 1.1
> diff -u -p -r1.1 patch-src_clisp-link_in
> --- patches/patch-src_clisp-link_in 7 Jan 2010 10:55:28 - 1.1
> +++ patches/patch-src_clisp-link_in 28 Sep 2015 19:00:58 -
> @@ -1,11 +1,11 @@
> $OpenBSD: patch-src_clisp-link_in,v 1.1 2010/01/07 10:55:28 edd Exp $
> src/clisp-link.in.orig Wed Jun 17 19:30:31 2009
> -+++ src/clisp-link.in Sat Jan 2 19:08:19 2010
> -@@ -336,6 +336,7 @@ case "$1" in
> - link_some "$sourcedir" "$destinationdir" ${LISPRUN} lispinit.mem
> modules.h modules.o makevars ${FILES};
> +--- src/clisp-link.in.or
Re: [wip] clisp-2.49
On 29 September 2015 at 04:24, Jérémie Courrèges-Anglas wrote: > Kenneth Westerback writes: > >> I can probably set up build tests on i386 and sparc64 and eventually >> macppc if that would help. > > That would be great. :) > > -- > jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE i386 build started. I will keep you posted. :-) Ken
Re: [wip] clisp-2.49
On 29 September 2015 at 07:54, Kenneth Westerback wrote: > On 29 September 2015 at 04:24, Jérémie Courrèges-Anglas > wrote: >> Kenneth Westerback writes: >> >>> I can probably set up build tests on i386 and sparc64 and eventually >>> macppc if that would help. >> >> That would be great. :) >> >> -- >> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE > > i386 build started. > > I will keep you posted. :-) > > Ken That didn't take long. cc -I/usr/local/include -I/home/packages/wrkobj/clisp-2.49/build-i386/gllib -O2 -pipe -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral -O2 -fexpensive-optimizations -falign-functions=4 -DNO_SINGLEMAP -DNO_TRIVIALMAP -DENABLE_UNICODE -DDYNAMIC_FFI -I. -c spvw.c In file included from /home/packages/wrkobj/clisp-2.49/clisp-2.49/src/lispbibl.d:1983, from /home/packages/wrkobj/clisp-2.49/clisp-2.49/src/spvw.d:23: /home/packages/wrkobj/clisp-2.49/clisp-2.49/src/unix.d:65:1: warning: "MAP_ANON" redefined In file included from /home/packages/wrkobj/clisp-2.49/clisp-2.49/src/unix.d:62, from /home/packages/wrkobj/clisp-2.49/clisp-2.49/src/lispbibl.d:1983, from /home/packages/wrkobj/clisp-2.49/clisp-2.49/src/spvw.d:23: /usr/include/sys/mman.h:59:1: warning: this is the location of the previous definition /home/packages/wrkobj/clisp-2.49/clisp-2.49/src/spvw.d: In function 'init_memory': /home/packages/wrkobj/clisp-2.49/clisp-2.49/src/spvw.d:2881: error: 'MAP_ANON' undeclared (first use in this function) /home/packages/wrkobj/clisp-2.49/clisp-2.49/src/spvw.d:2881: error: (Each undeclared identifier is reported only once /home/packages/wrkobj/clisp-2.49/clisp-2.49/src/spvw.d:2881: error: for each function it appears in.) Makefile:1382: recipe for target 'spvw.o' failed gmake: *** [spvw.o] Error 1 *** Error 2 in lang/clisp (/usr/ports/infrastructure/mk/bsd.port.mk:2767 '/home/packages/wrkobj/clisp-2.49/build-i386/.build_done') *** Error 1 in lang/clisp (/usr/ports/infrastructure/mk/bsd.port.mk:2488 'build') ===> Exiting lang/clisp with an error *** Error 1 in /usr/ports (infrastructure/mk/bsd.port.subdir.mk:147 'build') Error: job failed 256 Full clisp-2.49.log at ~krw on cvs. Ken
Re: [wip] clisp-2.49
On 29 September 2015 at 19:43, Jérémie Courrèges-Anglas wrote: > Kenneth Westerback writes: > > [...] > >> That didn't take long. >> >> cc -I/usr/local/include >> -I/home/packages/wrkobj/clisp-2.49/build-i386/gllib -O2 -pipe -W >> -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type >> -Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral -O2 >> -fexpensive-optimizations -falign-functions=4 -DNO_SINGLEMAP >> -DNO_TRIVIALMAP -DENABLE_UNICODE -DDYNAMIC_FFI -I. -c spvw.c >> In file included from >> /home/packages/wrkobj/clisp-2.49/clisp-2.49/src/lispbibl.d:1983, >> from >> /home/packages/wrkobj/clisp-2.49/clisp-2.49/src/spvw.d:23: >> /home/packages/wrkobj/clisp-2.49/clisp-2.49/src/unix.d:65:1: warning: >> "MAP_ANON" redefined >> In file included from >> /home/packages/wrkobj/clisp-2.49/clisp-2.49/src/unix.d:62, >> from >> /home/packages/wrkobj/clisp-2.49/clisp-2.49/src/lispbibl.d:1983, >> from >> /home/packages/wrkobj/clisp-2.49/clisp-2.49/src/spvw.d:23: >> /usr/include/sys/mman.h:59:1: warning: this is the location of the >> previous definition >> /home/packages/wrkobj/clisp-2.49/clisp-2.49/src/spvw.d: In function >> 'init_memory': >> /home/packages/wrkobj/clisp-2.49/clisp-2.49/src/spvw.d:2881: error: >> 'MAP_ANON' undeclared (first use in this function) >> /home/packages/wrkobj/clisp-2.49/clisp-2.49/src/spvw.d:2881: error: >> (Each undeclared identifier is reported only once >> /home/packages/wrkobj/clisp-2.49/clisp-2.49/src/spvw.d:2881: error: >> for each function it appears in.) >> Makefile:1382: recipe for target 'spvw.o' failed >> gmake: *** [spvw.o] Error 1 >> *** Error 2 in lang/clisp >> (/usr/ports/infrastructure/mk/bsd.port.mk:2767 >> '/home/packages/wrkobj/clisp-2.49/build-i386/.build_done') >> *** Error 1 in lang/clisp >> (/usr/ports/infrastructure/mk/bsd.port.mk:2488 'build') >> ===> Exiting lang/clisp with an error >> *** Error 1 in /usr/ports (infrastructure/mk/bsd.port.subdir.mk:147 'build') >> Error: job failed 256 >> >> Full clisp-2.49.log at ~krw on cvs. > > Weird, I've just successfully built clisp on a freshly updated i386. > Thanks for the log, I'm taking a look. > > [...] > Real time: 117.58248 sec. > Run time: 102.05 sec. > Space: 1060930792 Bytes > GC: 1410, GC time: 26.42 sec. > 0 > Bye. > (echo *.erg | grep '*' >/dev/null) || (echo "Test failed:" ; ls -l *erg; echo > "To see which tests failed, type" ; echo "cat "`pwd`"/*.erg" ; exit 1) > echo "Test passed." > Test passed. > gmake[1]: Leaving directory '/usr/ports/pobj/clisp-2.49/build-i386/tests' > shannon /usr/ports/lang/clisp$ > > -- > jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE I built mine using dpb on a system from which my normal ports building script scrubbed all existing ports. Don't see why that would lead to the error. Shrug. I'll start another with a new snap. Perhaps it was an anomaly. Ken
Re: [wip] clisp-2.49
On 30 September 2015 at 04:11, Jérémie Courrèges-Anglas wrote: > > Last night I ran ''make; make clean'' in a loop on i386 and amd64. > > amd64: 142 builds / 0 failures > i386: 58 builds / 2 failures > > (same failure as yours) > > Maybe this has something to do with this... > > [...] > checking for the code address range... 0x1600 > checking for the malloc address range... 0x8700 > checking for the shared library address range... 0x2D00 > checking for the stack address range... 0xCF00 > [...] > > -- > jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE Black magic as far as I am concerned. :-) I can move on and try sparc64. Ken
Re: [wip] clisp-2.49
On 2 October 2015 at 08:18, Jérémie Courrèges-Anglas wrote: > Kenneth Westerback writes: > >> On 30 September 2015 at 04:11, Jérémie Courrèges-Anglas >> wrote: >>> >>> Last night I ran ''make; make clean'' in a loop on i386 and amd64. >>> >>> amd64: 142 builds / 0 failures >>> i386: 58 builds / 2 failures >>> >>> (same failure as yours) >>> >>> Maybe this has something to do with this... >>> >>> [...] >>> checking for the code address range... 0x1600 >>> checking for the malloc address range... 0x8700 >>> checking for the shared library address range... 0x2D00 >>> checking for the stack address range... 0xCF00 >>> [...] >>> >>> -- >>> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE >> >> Black magic as far as I am concerned. :-) > > 2.48 fails at the same rate on i386. > > -- > jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE In which case I would consider it fine to upgrade. :-) My sparc64 is resisting me but I hope to overcome it's reluctance today and start a build on -current. Ken
Re: [wip] clisp-2.49
On 2 October 2015 at 08:27, Kenneth Westerback wrote: > On 2 October 2015 at 08:18, Jérémie Courrèges-Anglas wrote: >> Kenneth Westerback writes: >> >>> On 30 September 2015 at 04:11, Jérémie Courrèges-Anglas >>> wrote: >>>> >>>> Last night I ran ''make; make clean'' in a loop on i386 and amd64. >>>> >>>> amd64: 142 builds / 0 failures >>>> i386: 58 builds / 2 failures >>>> >>>> (same failure as yours) >>>> >>>> Maybe this has something to do with this... >>>> >>>> [...] >>>> checking for the code address range... 0x1600 >>>> checking for the malloc address range... 0x8700 >>>> checking for the shared library address range... 0x2D00 >>>> checking for the stack address range... 0xCF00 >>>> [...] >>>> >>>> -- >>>> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE >>> >>> Black magic as far as I am concerned. :-) >> >> 2.48 fails at the same rate on i386. >> >> -- >> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE > > In which case I would consider it fine to upgrade. :-) > > My sparc64 is resisting me but I hope to overcome it's reluctance > today and start a build on -current. > > Ken It's still resisting. I am getting worried about it. :-( Ken
Re: [wip] clisp-2.49
On 5 October 2015 at 11:51, Josh Elsasser wrote: > On Mon, Oct 05, 2015 at 08:59:45AM -0400, Kenneth Westerback wrote: >> On 2 October 2015 at 08:27, Kenneth Westerback wrote: >> > On 2 October 2015 at 08:18, Jérémie Courrèges-Anglas >> > wrote: >> >> Kenneth Westerback writes: >> >> >> >>> On 30 September 2015 at 04:11, Jérémie Courrèges-Anglas >> >>> wrote: >> >>>> >> >>>> Last night I ran ''make; make clean'' in a loop on i386 and amd64. >> >>>> >> >>>> amd64: 142 builds / 0 failures >> >>>> i386: 58 builds / 2 failures >> >>>> >> >>>> (same failure as yours) >> >>>> >> >>>> Maybe this has something to do with this... >> >>>> >> >>>> [...] >> >>>> checking for the code address range... 0x1600 >> >>>> checking for the malloc address range... 0x8700 >> >>>> checking for the shared library address range... 0x2D00 >> >>>> checking for the stack address range... 0xCF00 >> >>>> [...] >> >>>> >> >>>> -- >> >>>> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 >> >>>> E7EE >> >>> >> >>> Black magic as far as I am concerned. :-) >> >> >> >> 2.48 fails at the same rate on i386. >> >> >> >> -- >> >> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 >> >> E7EE >> > >> > In which case I would consider it fine to upgrade. :-) >> > >> > My sparc64 is resisting me but I hope to overcome it's reluctance >> > today and start a build on -current. >> > >> > Ken >> >> It's still resisting. I am getting worried about it. :-( >> >> Ken > > I thought I'd jumped in here but it looks like not. > > This builds and appears to pass tests on macppc, and builds an sbcl > which also passes its tests. > > The fact that the configure script appears to be discovering and > hardcoding random memory addresses is concerning, but I guess it was > doing that already. > > Anyway, I'm OK with this and please feel free to remove me as > maintainer and add yourself. My only interest in clisp is for > bootstrapping sbcl anyway. Now I just feel bad. :-(. I'm ok with this going in as well unless you want to wait for a sparc64 test. Ken
Re: Bison 3, again
On 10 November 2015 at 08:00, Jérémie Courrèges-Anglas wrote:
>
> Hi,
>
> it's been a few years that our bison port hasn't been updated, the main
> reason being that our m4 doesn't groke some of the constructs used by
> newer bison releases. More and more packages out there require a recent
> bison version. As an OpenBSD developer, I don't think that building
> parsers using a recent bison on another OS is a valid answer to that
> problem.
>
> Yet, nobody found the time and motivation to implement the features /
> fix the bugs in m4.
>
> Here's my proposal: update bison to the latest version and make it use
> devel/m4 (GNU m4). *Then* *if* someone wants to make the efforts
> required for bison to use base m4, that would be awesome.
>
> Sorry if this sounds blunt, but this is the only way forward I can see.
>
> I'll be available later today to discuss this further if needed.
This sounds like a reasonable approach to me.
Ken
>
> Diff below,
>
> Index: devel/bison/Makefile
> ===
> RCS file: /cvs/ports/devel/bison/Makefile,v
> retrieving revision 1.51
> diff -u -p -r1.51 Makefile
> --- devel/bison/Makefile19 May 2015 09:54:53 - 1.51
> +++ devel/bison/Makefile10 Nov 2015 12:50:07 -
> @@ -2,8 +2,7 @@
>
> COMMENT= GNU parser generator
>
> -DISTNAME= bison-2.3
> -REVISION= 2
> +DISTNAME= bison-3.0.4
> CATEGORIES=devel
> MASTER_SITES= ${MASTER_SITE_GNU:=bison/}
>
> @@ -15,9 +14,12 @@ PERMIT_PACKAGE_CDROM=Yes
> WANTLIB= c
> MODULES= devel/gettext
> BUILD_DEPENDS= devel/m4
> +RUN_DEPENDS= devel/m4
>
> CONFIGURE_STYLE=gnu
> CONFIGURE_ARGS=--disable-yacc
> +# Instead of --gnu, not recognized by m4 from base
> +CONFIGURE_ENV+=ac_cv_prog_gnu_m4_gnu="-g"
> MODGNU_CONFIG_GUESS_DIRS=${WRKSRC}/build-aux
>
> .include
> Index: devel/bison/distinfo
> ===
> RCS file: /cvs/ports/devel/bison/distinfo,v
> retrieving revision 1.9
> diff -u -p -r1.9 distinfo
> --- devel/bison/distinfo18 Jan 2015 03:13:08 - 1.9
> +++ devel/bison/distinfo10 Nov 2015 12:50:07 -
> @@ -1,2 +1,2 @@
> -SHA256 (bison-2.3.tar.gz) = UveKpHYadM63/fdw81VN2EMIw7k8QlXjpcF1WOzaKT4=
> -SIZE (bison-2.3.tar.gz) = 1386694
> +SHA256 (bison-3.0.4.tar.gz) = tn/S2q56ZLW6hixmwHwa3bnmsbBcXyBJOSz9iiFylS4=
> +SIZE (bison-3.0.4.tar.gz) = 3354179
> Index: devel/bison/patches/patch-configure
> ===
> RCS file: devel/bison/patches/patch-configure
> diff -N devel/bison/patches/patch-configure
> --- devel/bison/patches/patch-configure 8 Jul 2008 00:24:17 - 1.3
> +++ /dev/null 1 Jan 1970 00:00:00 -
> @@ -1,16 +0,0 @@
> -$OpenBSD: patch-configure,v 1.3 2008/07/08 00:24:17 brad Exp $
> configure.orig Mon Jun 5 03:32:01 2006
> -+++ configure Sun Jun 29 22:09:16 2008
> -@@ -16768,10 +16768,10 @@ s,@host_cpu@,$host_cpu,;t t
> - s,@host_vendor@,$host_vendor,;t t
> - s,@host_os@,$host_os,;t t
> - s,@INTL_MACOSX_LIBS@,$INTL_MACOSX_LIBS,;t t
> --s,@LIBICONV@,$LIBICONV,;t t
> -+s,@LIBICONV@,$LTLIBICONV,;t t
> - s,@LTLIBICONV@,$LTLIBICONV,;t t
> - s,@INTLLIBS@,$INTLLIBS,;t t
> --s,@LIBINTL@,$LIBINTL,;t t
> -+s,@LIBINTL@,$LTLIBINTL,;t t
> - s,@LTLIBINTL@,$LTLIBINTL,;t t
> - s,@POSUB@,$POSUB,;t t
> - s,@UNISTD_H@,$UNISTD_H,;t t
> Index: devel/bison/patches/patch-data_m4sugar_m4sugar_m4
> ===
> RCS file: /cvs/ports/devel/bison/patches/patch-data_m4sugar_m4sugar_m4,v
> retrieving revision 1.2
> diff -u -p -r1.2 patch-data_m4sugar_m4sugar_m4
> --- devel/bison/patches/patch-data_m4sugar_m4sugar_m4 8 Jul 2008 00:24:17
> - 1.2
> +++ devel/bison/patches/patch-data_m4sugar_m4sugar_m4 10 Nov 2015 12:50:07
> -
> @@ -1,7 +1,7 @@
> $OpenBSD: patch-data_m4sugar_m4sugar_m4,v 1.2 2008/07/08 00:24:17 brad Exp $
> data/m4sugar/m4sugar.m4.orig Mon Nov 14 03:13:07 2005
> -+++ data/m4sugar/m4sugar.m4Sun Jun 29 22:09:16 2008
> -@@ -55,13 +55,6 @@ divert(-1)#
> +--- data/m4sugar/m4sugar.m4.orig Fri Aug 2 17:03:17 2013
> data/m4sugar/m4sugar.m4Fri Nov 6 20:39:48 2015
> +@@ -31,13 +31,6 @@ divert(-1)#
> changequote()
> changequote([, ])
>
> Index: devel/bison/patches/patch-data_yacc_c
> ===
> RCS file: devel/bison/patches/patch-data_yacc_c
> diff -N devel/bison/patches/patch-data_yacc_c
> --- devel/bison/patches/patch-data_yacc_c 19 May 2015 09:54:53 -
> 1.1
> +++ /dev/null 1 Jan 1970 00:00:00 -
> @@ -1,46 +0,0 @@
> -$OpenBSD: patch-data_yacc_c,v 1.1 2015/05/19 09:54:53 kettenis Exp $
> data/yacc.c.orig Mon May 18 18:07:15 2015
> -+++ data/yacc.cMon May 18 18:08:26 2015
> -@@ -307,10 +307,10 @@ typedef short int yytype_int16;
> - #define allo
Re: mod_auth_bsd (circleq fallout)
On 20 November 2015 at 06:19, Stuart Henderson wrote:
> can this just be switched to a TAILQ?
No. At least what buried memories I have of the conversions a year ago
say NO. It is a mechanical change but a bit more than
s/CIRCLEQ/TAILQ/g for some situations I can't immediately recall.
> is anyone using this that can test?
I can dig out some conversions I did and refresh my memory. but I'm
not a user of the software so a tester would still be good to find.
Ken
>
>
> Index: patches/patch-authd_c
> ===
> RCS file: patches/patch-authd_c
> diff -N patches/patch-authd_c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-authd_c 20 Nov 2015 11:18:12 -
> @@ -0,0 +1,123 @@
> +$OpenBSD$
> +--- authd.c.orig Fri Nov 20 11:16:51 2015
> authd.cFri Nov 20 11:17:14 2015
> +@@ -174,7 +174,7 @@ struct auth_attempt {
> + } result;
> +
> + SPLAY_ENTRY(auth_attempt) spe;
> +- CIRCLEQ_ENTRY(auth_attempt) cqe;
> ++ TAILQ_ENTRY(auth_attempt) cqe;
> + }; /* struct auth_attempt */
> +
> +
> +@@ -196,7 +196,7 @@ static const struct auth_peer {
> + struct auth_attempt;
> +
> + static SPLAY_HEAD(mod_auth_bsd_fail,auth_attempt) auth_failed_lookup;
> +-static CIRCLEQ_HEAD(,auth_attempt) auth_failed_cache;
> ++static TAILQ_HEAD(,auth_attempt) auth_failed_cache;
> + static size_t auth_failed_num;
> +
> + static int auth_fail_cmp(struct auth_attempt *a, struct auth_attempt *b) {
> +@@ -212,7 +212,7 @@ SPLAY_GENERATE(mod_auth_bsd_fail,auth_attempt,spe,auth
> + * Cache and lookup tree for successful authentications.
> + */
> + static SPLAY_HEAD(mod_auth_bsd_okay,auth_attempt) auth_okayed_lookup;
> +-static CIRCLEQ_HEAD(,auth_attempt) auth_okayed_cache;
> ++static TAILQ_HEAD(,auth_attempt) auth_okayed_cache;
> + static size_t auth_okayed_num;
> +
> + static int auth_okay_cmp(struct auth_attempt *a, struct auth_attempt *b) {
> +@@ -566,15 +566,15 @@ static struct auth_attempt *authd_userokay_cached(stru
> +* Just setup it up for reallocation.
> +*/
> + if (now - a->timestamp > cache_ttl) {
> +- CIRCLEQ_REMOVE(&auth_okayed_cache,a,cqe);
> +- CIRCLEQ_INSERT_HEAD(&auth_okayed_cache,a,cqe);
> ++ TAILQ_REMOVE(&auth_okayed_cache,a,cqe);
> ++ TAILQ_INSERT_HEAD(&auth_okayed_cache,a,cqe);
> +
> + a = NULL;
> + } else {
> + a->timestamp= now;
> +
> +- CIRCLEQ_REMOVE(&auth_okayed_cache,a,cqe);
> +- CIRCLEQ_INSERT_TAIL(&auth_okayed_cache,a,cqe);
> ++ TAILQ_REMOVE(&auth_okayed_cache,a,cqe);
> ++ TAILQ_INSERT_TAIL(&auth_okayed_cache,a,cqe);
> + }
> + }
> +
> +@@ -592,11 +592,11 @@ static struct auth_attempt *authd_userokay_cache(struc
> + now = time(NULL);
> +
> + if (okay) {
> +- if ((a = CIRCLEQ_FIRST(&auth_okayed_cache)) !=
> CIRCLEQ_END(&auth_okayed_cache)
> ++ if ((a = TAILQ_FIRST(&auth_okayed_cache)) !=
> TAILQ_END(&auth_okayed_cache)
> + && (now - a->timestamp > cache_ttl || auth_okayed_num >=
> cache_size)) {
> +
> assert(SPLAY_REMOVE(mod_auth_bsd_okay,&auth_okayed_lookup,a));
> +
> +- CIRCLEQ_REMOVE(&auth_okayed_cache,a,cqe);
> ++ TAILQ_REMOVE(&auth_okayed_cache,a,cqe);
> + auth_okayed_num--;
> + } else if (!(a = malloc(sizeof *a)))
> + return NULL;
> +@@ -609,7 +609,7 @@ static struct auth_attempt *authd_userokay_cache(struc
> + if ((e =
> SPLAY_INSERT(mod_auth_bsd_okay,&auth_okayed_lookup,a))) {
> + e->timestamp= now;
> +
> +- CIRCLEQ_REMOVE(&auth_okayed_cache,e,cqe);
> ++ TAILQ_REMOVE(&auth_okayed_cache,e,cqe);
> + auth_okayed_num--;
> +
> + free(a);
> +@@ -617,23 +617,23 @@ static struct auth_attempt *authd_userokay_cache(struc
> + a = e;
> + }
> +
> +- CIRCLEQ_INSERT_TAIL(&auth_okayed_cache,a,cqe);
> ++ TAILQ_INSERT_TAIL(&auth_okayed_cache,a,cqe);
> + auth_okayed_num++;
> + } else {
> + authd_hash_fail(k.key,pkt);
> +
> + if ((a =
> SPLAY_FIND(mod_auth_bsd_fail,&auth_failed_lookup,&k))) {
> +- CIRCLEQ_REMOVE(&auth_failed_cache,a,cqe);
> ++ TAILQ_REMOVE(&auth_failed_cache,a,cqe);
> + auth_failed_num--;
> +
> + if (now - a->timestamp > cache_ttl)
> + a->result.failed.count = 0;
> + } else {
> +- if ((a = CIRCLEQ_FIRST(&auth_failed_cache)) !=
> CIR
Re: net/kea
On 23 December 2015 at 21:53, Stuart Henderson wrote:
> On 2015/12/23 14:47, Patrik Lundin wrote:
>> On Wed, Dec 23, 2015 at 11:33:30AM +, Stuart Henderson wrote:
>> > Updated tar.gz for the 0.9.2-P1 crash fix ("Improved handling of incoming
>> > packets with invalid client-id and DUID.")
>> >
>>
>> Nice catch! I had not seen any word of this release on the kea mailing
>> lists, how did you notice it?
>
> I saw it on oss-sec first, then on ISC's security RSS feed (and as if
> to emphasize the slightly random nature of that feed it was followed
> by release notes for 0.9, 0.9.2-beta and 0.9.2 :-) I read oss-sec anyway,
> and since I maintain the BIND port I track a few places where ISC are
> likely to announce things.
>
> http://www.openwall.com/lists/oss-security/2015/12/22/11
> https://www.isc.org/?feed=security-feed
>
What would be really nice is if they described somewhere the
'crafted' packet that was blowing them up. As far as the diff goes
they just wrapped try {} around the code trying to get a client
identifier. So it's kinda unsatisfying as far as figuring out if our
in-tree dhcpd would blow up with a similar packet. :-)
Ken
Re: Update/new: x11/openmotif 2.3.5
Some of the ports I build cause openmotif to be compiled, so this
sounds good to me. No idea on the implications of moving directory to
/motif. Certainly no objections.
Ken
On 29 April 2016 at 10:47, Christian Weisgerber wrote:
> This updates x11/openmotif to 2.3.5 and completely overhauls the port.
>
> The existing port is a big pile of dung. Patches have been blindly
> cargo-culted forward for years. There are patches to fix the imake
> build infrastructure, which isn't used any longer. There are
> security patches that add checks that are already there, right in
> the context. There are patches to work around missing functions
> OpenBSD has had for years.
>
> The cleaned-up port might as well have been done from scratch.
> I verified that all ports that depend on Motif still build. xpdf
> still runs. DESCR is poor, but I haven't found any usable text on
> the Motif sites.
>
> Motif defaults to installing its demo programs and their associated
> data under share/Xm. That isn't right, share is for machine-independent
> data, not for compiled executables. Previously, the port installed
> the programs themselves into bin, but apparently nobody noticed
> that many of them don't run there. You can only run them from the
> directory that also holds their data. I've moved the whole mess
> to lib/Xm.
>
> With the many demo programs no longer cluttering up the bin directory,
> there is no point in splitting them off into a subpackage. Merging
> the subpackages changes the package paths, so the 21 dependent ports
> will need a bump. I think that's fine. (Diff not included.) Since
> the dependent ports will already need a bump, we might as well
> change the package name from the obsolete "openmotif" to plain
> "motif".
>
> I'm also considering moving the whole port from x11/openmotif to
> x11/motif. If you look at what's changing, there's precious little
> history to lose. See below.
>
> Comments? Opinions?
>
>
> M Makefile
> M distinfo
> R patches/patch-Imakefile
> R patches/patch-Makefile_imake-pure
> R patches/patch-autogen_sh
> R patches/patch-bindings-Imakefile
> R patches/patch-bitmaps-Imakefile
> R patches/patch-clients_mwm_WmFunction_c
> R patches/patch-clients_uil_UilDefI_h
> R patches/patch-config-Imakefile
> R patches/patch-config-cf-Imakefile
> R patches/patch-config-imake-Imakefile
> R patches/patch-config-makedepend-Imakefile
> R patches/patch-config-util-Imakefile
> R patches/patch-config_cf_Motif_rules
> M patches/patch-config_cf_Motif_tmpl
> R patches/patch-config_cf_bsdLib_tmpl
> R patches/patch-config_cf_host_def
> R patches/patch-config_cf_site_def
> R patches/patch-demos_lib_Exm_wml_Makefile_am
> R patches/patch-demos_programs_Imakefile
> R patches/patch-demos_programs_workspace_wsmData_c
> M patches/patch-demos_programs_workspace_xrmLib_c
> R patches/patch-demos_unsupported_motifshell_motifshell_c
> A patches/patch-lib_Xm_ColorS_c
> R patches/patch-lib_Xm_Scale_c
> A patches/patch-lib_Xm_TextF_c
> R patches/patch-lib_Xm_Xmos_r_h
> M patches/patch-lib_Xm_XpmI_h
> R patches/patch-lib_Xm_Xpmcreate_c
> R patches/patch-lib_Xm_Xpmparse_c
> R patches/patch-tools_wml_Makefile_am
> A pkg/DESCR
> R pkg/DESCR-demos
> R pkg/DESCR-main
> A pkg/PLIST
> R pkg/PLIST-demos
> R pkg/PLIST-main
>
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/x11/openmotif/Makefile,v
> retrieving revision 1.63
> diff -u -p -r1.63 Makefile
> --- Makefile27 Apr 2016 13:58:19 - 1.63
> +++ Makefile29 Apr 2016 08:45:12 -
> @@ -1,99 +1,56 @@
> -# $OpenBSD: Makefile,v 1.63 2016/04/27 13:58:19 naddy Exp $
> +# $OpenBSD: Makefile,v 1.62 2015/08/19 20:34:33 sthen Exp $
>
> -COMMENT-main= Motif toolkit
> -COMMENT-demos= Motif toolkit demos
> +COMMENT= Motif toolkit
>
> -VERSION= 2.3.4
> -REVISION-main= 2
> -REVISION-demos=0
> -DISTNAME= motif-${VERSION}
> -EXTRACT_SUFX= -src.tgz
> -PKGNAME-main= openmotif-${VERSION}
> -PKGNAME-demos= openmotif-demos-${VERSION}
> -
> -SHARED_LIBS= Mrm 4.1 \
> - Uil 5.0 \
> - Xm 6.0
> -
> -CATEGORIES=x11
> -MASTER_SITES= ${MASTER_SITE_SOURCEFORGE:=motif/}
> -DIST_SUBDIR= openmotif
> +DISTNAME= motif-2.3.5
>
> -HOMEPAGE= http://motif.ics.com/
> +SHARED_LIBS= Mrm 4.1 \
> + Uil 5.0 \
> + Xm 6.1
>
> -# LGPLv2.1
> -PERMIT_PACKAGE_CDROM= Yes
> -
> -MULTI_PACKAGES=-demos -main
> -
> -USE_GROFF= Yes
> -CONFIGURE_STYLE= gnu
> -AUTOCONF_VERSION= 2.69
> -AUTOMAKE_VERSION= 1.12
> -CONFIGURE_ARGS=--enable-themes \
> - --enable-xft \
> - --enable-jpeg \
> - --disable-printing \
> - --enable-png
> -CONFIGU
Re: minor cleanup for math/coq
On Fri, 24 Feb 2017 at 10:15 Alexandr Shadchin wrote: > On Thu, Feb 23, 2017 at 09:13:42PM -0500, Daniel Dickman wrote: > > I have an update for coq from 8.4 to 8.6, but I'd like to get the easy > > bits in first: > > - switch from http to https > > - drop gettext module > > - regen WANTLIB > > - move MODULES up in the Makefile, following Makefile.template > > > > ok? > > > > ok shadchin@ > > -- > Alexandr Shadchin > > Not being a coq user I don't have much useful to say on the details of this change or the update to 8.6 per se. But I keep thinking that the best strategy would be to leverage opam more, and eliminate as many individual ports as possible. Of course the last time I tried I think coq didn't install from opam. :-) Ken
Re: 'avoid W|X mappings in libffi' - MARC
What's 'obxj' that your spreadsheet says processes lang/obc? make search key=obxj doesn't show anything. Just curious as lang/obc popped out at me due to my ocaml update work. :-) Ken On 24 May 2016 at 06:51, Stuart Henderson wrote: > I've collected the known problems so far at > https://docs.google.com/spreadsheets/d/1RjfH2_ecaUc_G5kmPAKbH00w0qcR-vWljTiUb4UCVXI/edit?usp=sharing >
Re: 'avoid W|X mappings in libffi' - MARC
Aha. Google says obxj are files emitted by obc? So perhaps that row just has lang/obc in the wrong column. :-) Ken On 24 May 2016 at 07:05, Kenneth Westerback wrote: > What's 'obxj' that your spreadsheet says processes lang/obc? > > make search key=obxj > > doesn't show anything. > > Just curious as lang/obc popped out at me due to my ocaml update work. :-) > > Ken > > > On 24 May 2016 at 06:51, Stuart Henderson wrote: >> I've collected the known problems so far at >> https://docs.google.com/spreadsheets/d/1RjfH2_ecaUc_G5kmPAKbH00w0qcR-vWljTiUb4UCVXI/edit?usp=sharing >>
Re: flashrom
Seems like a multi-purpose piece of rope that would be both useful and have the potential side effect of removing some noise from misc@. :-) ok krw@ fwiw. Ken On 30 May 2016 at 18:50, Stuart Henderson wrote: > > flashrom is a utility for identifying, reading, writing, verifying > and erasing flash chips. It is designed to flash BIOS, EFI, coreboot, > firmware and optionROM images on mainboards, network/graphics/storage > controller cards, and various programmer devices. > > > This uses a patched pciutils to emulate 8/16-bit writes, diff from > an old ports@ post from Carl-Daniel Hailfinger. As it requires write > access to /dev/mem it will not run on a normally booted OpenBSD > system; there is a README that makes it clear that one should not > take it lightly and advises running it only in single user mode > (both so that write access can be done, and so that network > services aren't running). > > OK to import it? It's been useful for me while building new APU > boxes and I know a few other people have been using old versions > of this on openbsd-wip for the same. >
Re: NEW: books/progit
On 4 August 2016 at 04:04, Anthony J. Bentley wrote: > Hi, > > Pro Git (Second Edition) is your fully-updated guide to Git and its usage in > the modern world. Git has come a long way since it was first developed by > Linus Torvalds for Linux kernel development. It has taken the open source > world by storm since its inception in 2005, and this book teaches you how to > use it like a pro. > > Effective and well-implemented version control is a necessity for successful > web projects, whether large or small. With this book you'll learn how to > master the world of distributed version workflow, use the distributed > features of Git to the full, and extend Git to meet your every need. > > ok? > > -- > Anthony J. Bentley Read the book. Love the port. ok krw@ fwiw. Ken
Re: textlive_base amd64+dpb web2c == "No rule to make target 'all'
On Fri, 26 Aug 2016 at 16:00 Christian Weisgerber wrote: > On 2016-08-21, Kenneth R Westerback wrote: > > > Trying to compile coccinelle on my amd64 dpb builder with -current > > sources as of last night fails in the dependency textlive_base. The > > last messages are > > FWIW, I have not seen this in the amd64 package builds. > > -- > Christian "naddy" Weisgerber na...@mips.inka.de > > And it has not recurred here either. So I'm writing it off as a result of some mixup on my part. Ken
Re: Cruft: imake
Nothing I can see that is worth extra effort to retain. But that's just me. Ken On Fri, 2 Sep 2016 at 12:00 Christian Weisgerber wrote: > Now that gtk1 has been removed, we need to give jasper@ a new goal > in life. I think a good candidate is imake. Anything that still > uses imake for configuration is likely old cruft that has been > barely maintained, if at all, since the late 1990s. > > Here's a list of ports that use CONFIGURE_STYLE=imake: > > astro/sunclock > astro/xearth > astro/xephem > astro/xphoon > audio/ascd > audio/libworkman > audio/xcdplayer > audio/xmcd > benchmarks/xengine > comms/seyon > editors/axe > emulators/spim > fonts/ja-funetfonts > fonts/jmk-fonts > fonts/zh-kcfonts > fonts/zh-taipeifonts > games/speyes > games/spider > games/xasteroids > games/xbat > games/xbattle > games/xboing > games/xchomp > games/xcubes > games/xdeblock > games/xdino > games/xgolgo > games/xjewel > games/xkobo > games/xlife > games/xmine > games/xminesweep > games/xmj > games/xmris > games/xonix > games/xpat2 > games/xpilot > games/xripple > games/xscavenger > games/xscrabble > games/xskat > graphics/mpeg_play > graphics/tgif > graphics/xanim > graphics/xbmbrowser > graphics/xfig > graphics/xoris > graphics/xpaint > japanese/canna > japanese/kinput2 > japanese/kterm > mail/xlbiff > misc/magicpoint > misc/xgas > misc/xless > misc/xtar > misc/xtimer > net/ssvnc > net/wmnet > plan9/9wm > plan9/larswm > plan9/w9wm > print/bibview > print/ghostview > print/transfig > productivity/xinvest > productivity/xquote > sysutils/xbatt > sysutils/xbattbar > textproc/docbook-to-man > textproc/mgdiff > x11/asclock > x11/bclock > x11/bricons > x11/ctwm > x11/emiclock > x11/lupe > x11/mouseclock > x11/piewm > x11/root-tail > x11/sliderule > x11/swisswatch > x11/tvtwm > x11/unclutter > x11/viewfax > x11/wmdate > x11/x2vnc > x11/x2x > x11/xaniroc > x11/xantfarm > x11/xautolock > x11/xcb > x11/xco > x11/xcoloredit > x11/xcolors > x11/xdtm > x11/xdu > x11/xfed > x11/xfishtank > x11/xgrab > x11/xkeycaps > x11/xmascot > x11/xmold > x11/xpostit > x11/xpostitPlus > x11/xprompt > x11/xscribble > x11/xsnow > x11/xtacy > x11/xtattr > x11/xtestpicture > x11/xtoolwait > x11/xtu > x11/xvkbd > x11/xwit > x11/xzoom > > Some more ports that otherwise depend on imake or in turn on something > that does: > > audio/ardour > audio/aubio > chinese/crxvt > comms/x3270 > comms/xastir > fonts/zh-bg5pdf > games/redeclipse > games/xbl > graphics/GraphicsMagick > graphics/colorexplorer > graphics/darktable > graphics/enblend-enfuse > graphics/hugin > graphics/ipe > graphics/pdf2djvu > japanese/Wnn > japanese/jvim > japanese/onew > math/octave > x11/afterstep > x11/kde/base3 > x11/treewm > x11/wmclock > > -- > Christian "naddy" Weisgerber na...@mips.inka.de > >
Re: UPDATE: devel/coccinelle 1.0.5
On Sat, 24 Sep 2016 at 05:14 Stuart Henderson wrote: > On 2016/09/24 18:42, Jonathan Gray wrote: > > On Sat, Sep 24, 2016 at 09:37:45AM +0100, Stuart Henderson wrote: > > > On 2016/09/24 16:35, Jonathan Gray wrote: > > > > Update coccinelle to 1.0.5, changes described here: > > > > http://coccinelle.lip6.fr/distrib/changes.html > > > > > > I tried updating this at Cambridge (it seemed fitting ;) - my diff is > > > nearly the same, only packaging changes - > lib/coccinelle/spgen/spgen.opt > > > should be in PFRAG.dynlink instead of PLIST - but I dropped it because > > > the regression tests didn't look good and I didn't know where to start > > > with debugging it. > > > > Ah, indeed running make test gives: > > > > > > regression testing information > > > > regression file: tests/SCORE_expected.sexp > > > > total score > > > > good = 218/492 > > Current score is lower than expected :( > > (was expecting 451 but got 218) > > For comparison, the old version gave > > : good = 452/480 > : Current score is greater than expected :) > : (was expecting 445 but got 452) > > If it was just a small difference I'd probably just run with it, but > this was a lot bigger than usual. > I have an M in coccinelle/Makefile as part of my attempt to update ocaml-pcre (and its users ocaml-text, ocaml-net) but it's just a revision bump so I'm not concerned about conflicts. No idea if the slightly updated pcre would improve anything but I can try it if that's of interest. Just have to figure out why ocaml-pcre works fine if I build it alone but won't under dpb ... Ken
Re: collectd breakage, circleq removal
Looking now. Ken On 27 Dec 2013 11:16, "Stuart Henderson" wrote: > collectd failed in my bulk (circleq removal) - anyone have time to take a > look? > > tcpconns.c: In function 'conn_read': > tcpconns.c:678: error: 'struct inpthead' has no member named 'cqh_first' > tcpconns.c:686: error: 'struct ' has no member named 'cqe_next' > > > http://rhaalovely.net/build-failures/i386/20131219/sysutils/collectd,-pgsql.log > >
Re: [squid] ...rejecting '[127.0.0.1]:5330' as a name server...
Dhclient will not generate such syntax in resolved.conf so I assume you are doing so via resolv.conf.tail or ... ? And if so, I guess you need to choose between squid and your local DNS port. Or are you saying that there is a snort friendly syntax for this purpose that we should be using instead? Ken On 27 Jan 2014 06:06, "Jiri B" wrote: > Hi, > > squid doesn't like OpenBSD specific syntax on resolv.conf. > > # squid -N -d 3 > ... > 2014/01/26 17:58:51| DNS Socket created at [::], FD 5 > 2014/01/26 17:58:51| DNS Socket created at 0.0.0.0, FD 6 > 2014/01/26 17:58:51| Adding domain example.com from /etc/resolv.conf > 2014/01/26 17:58:51| Adding nameserver [127.0.0.1]:5330 from > /etc/resolv.conf > 2014/01/26 17:58:51| WARNING: rejecting '[127.0.0.1]:5330' as a name > server, because it is not a numeric IP address > ... > > $ cat /etc/resolv.conf > # Generated by iwn0 dhclient > search example.com > nameserver [127.0.0.1]:5330 > > resolv.conf(5) states: > ... > nameserver IPv4 address (in dot notation) or IPv6 address (in > hex-and- > colon notation) of a name server that the resolver should > query. Scoped IPv6 address notation is accepted as well > (see > inet6(4) for details). A non-standard port may also be > specified, with the host address enclosed in square > brackets. > For example: > >nameserver [10.0.0.1]:5353 >nameserver [::1]:5353 > > jirib > >
Re: [squid] ...rejecting '[127.0.0.1]:5330' as a name server...
On 27 January 2014 08:32, Jiri B wrote: > On Mon, Jan 27, 2014 at 08:09:20AM +1300, Kenneth Westerback wrote: >> Dhclient will not generate such syntax in resolved.conf so I assume you are >> doing so via resolv.conf.tail or ... ? And if so, I guess you need to >> choose between squid and your local DNS port. > > Yes, I used resolv.conf.tail. Hmmm, squid does not seem to support > custom dns port anyway via a config option. > >> Or are you saying that there is a snort friendly syntax for this purpose >> that we should be using instead? > > I don't understand the question. > Since I don't know squid, I was asking if it did handle some other syntax that we might be able to add to resolv.conf consumers. "does not seem to support custom dns port" would seem to answer the question. :-) Ken >> >> > Hi, >> > >> > squid doesn't like OpenBSD specific syntax on resolv.conf. >> > >> > # squid -N -d 3 >> > ... >> > 2014/01/26 17:58:51| DNS Socket created at [::], FD 5 >> > 2014/01/26 17:58:51| DNS Socket created at 0.0.0.0, FD 6 >> > 2014/01/26 17:58:51| Adding domain example.com from /etc/resolv.conf >> > 2014/01/26 17:58:51| Adding nameserver [127.0.0.1]:5330 from >> > /etc/resolv.conf >> > 2014/01/26 17:58:51| WARNING: rejecting '[127.0.0.1]:5330' as a name >> > server, because it is not a numeric IP address >> > ... >> > >> > $ cat /etc/resolv.conf >> > # Generated by iwn0 dhclient >> > search example.com >> > nameserver [127.0.0.1]:5330 >> > >> > resolv.conf(5) states: >> > ... >> > nameserver IPv4 address (in dot notation) or IPv6 address (in >> > hex-and- >> > colon notation) of a name server that the resolver should >> > query. Scoped IPv6 address notation is accepted as well >> > (see >> > inet6(4) for details). A non-standard port may also be >> > specified, with the host address enclosed in square >> > brackets. >> > For example: >> > >> >nameserver [10.0.0.1]:5353 >> >nameserver [::1]:5353 >> > >> > jirib >> > >> >
Re: Threading support in lang/sbcl
On 18 February 2014 10:33, Gregor Best wrote: > Hi Joshua, > > the attached patch enables threading support in lang/sbcl, which is > disabled by default for systems other than Linux. > > I briefly tested the results with bordeaux-threads, which seems to work > fine now. > > The only downside of the change that I have noticed is that it changes > *FEATURES*, which invalidates precompiled Lisp bytecode. This could be > cumbersome for unprepared users because it also applies to the REPL, but > removing cached bytecode in ~/.cache/common-lisp/sbcl* fixes that. > > -- > Gregor Best Nice, but ports is locked for 5.5. release so this will likely be post-5.5. Ken
Re: Delete: archivers/bzip
On 10 March 2014 11:42, Christian Weisgerber wrote: > I suggest to delete archivers/bzip. > > bzip is used by nobody. It was patent-encumbered and, from today's > POV, superseded immediately by bzip2. The upstream distfile is > long gone. > > ok? > > -- > Christian "naddy" Weisgerber na...@mips.inka.de > Sounds good to me. ok krw@ fwiw. Ken
Re: tedu asp2php
On 26 March 2014 10:33, Benoit Lecocq wrote: > Le 26/03/2014 15:25, James Turner a écrit : >> >> On Wed, Mar 26, 2014 at 02:22:38PM +, Stuart Henderson wrote: >>> >>> "asp2php is a program which converts Microsoft's ASP code to PHP. >>> It supports multiple database drivers, sessions, both PHP3 and PHP4, >>> and also provides a graphical front end to do all this." >>> >>> I don't think a program that hasn't been updated since 2006 that converts >>> Microsoft ASP to PHP3/4 is going to produce anything that should be run >>> on a webserver today. OK to zap it? >>> >> >> For the love of god, yes! >> > > yes ! ;o) > Just make sure you hunt down any php3/4 -> asp converters at the same time! :-) Ken
Re: Chromium GPU Acceleration
On 21 June 2014 12:10, Paul Irofti wrote: > On Sat, Jun 21, 2014 at 11:28:36AM +0200, Robert Nagy wrote: >> Hey, >> >> So if anyone out there having an old chromium profile and having issues >> with video playback or high CPU usage should listen and check some stuff >> out. >> >> First of all navigate to chromium://gpu and check if you have hardware >> acceleration enabled, if you do, there is nothing to do you can stop >> reading this email, on the other hand if it says that you are software >> accelarted only, quit chrome then start chrome with the >> --ignore-gpu-blacklist >> flag then quit chrome again and start using it the way you did before. >> It is only necessary to start chrome with this flag once, then you can skip >> it. >> >> It turns out that at one point chromium had an issue and flipped a switch >> in your profile that turns GPU acceleration off. This issue got fixed >> at one point since then but you actually have to manually force it to >> ignore the gpu blacklist to make it work again. >> If you have recently created a new profile, you should not have this >> issue, but the chrome://gpu page can tell you what's going on. >> >> We have an old profile saved that suffers from this issue and I am going >> try to figure it out and come up with a fix so that you don't have >> to start chrome with the --ignore-gpu-blacklist flag. >> > > Actually I still have the problem after running with > --ignore-gpu-blacklist. > > Ignoring blacklist: > Graphics Feature Status > Canvas: Hardware accelerated > 3D CSS: Hardware accelerated > Compositing: Hardware accelerated > CSS Animation: Accelerated > Flash 3D: Hardware accelerated > Flash Stage3D: Hardware accelerated > Flash Stage3D Baseline profile: Hardware accelerated > Video: Hardware accelerated > Video Decode: Hardware accelerated > WebGL: Hardware accelerated > > Regular run: > Graphics Feature Status > Canvas: Software only, hardware acceleration unavailable > 3D CSS: Hardware accelerated > Compositing: Hardware accelerated > CSS Animation: Accelerated > Flash 3D: Hardware accelerated > Flash Stage3D: Unavailable. Hardware acceleration unavailable > Flash Stage3D Baseline profile: Unavailable. Hardware acceleration > unavailable > Video: Hardware accelerated > Video Decode: Software only, hardware acceleration unavailable > WebGL: Hardware accelerated > > I run chrome w/o any flags or tweaks: > $ chrome --ignore-gpu-blacklist > ATTENTION: default value of option force_s3tc_enable overridden by > environment. > $ chrome > ATTENTION: default value of option force_s3tc_enable overridden by > environment. > > And my chrome version is: > $ chrome --version > Chromium 34.0.1847.116 > chrome://gpu/ was the only thing that worked for me. 'chromium' or leaving off the trailing slash just dumped me into google search results. Don't know if that is significant. :-) I'm running $ chrome --version Chromium 35.0.1916.155 $ on an amd64 desktop. '--ignore-gpu-blacklist' does seem to enable the youtube video I tried. But as pirofti@ says, it doesn't stick for me. And typing has become *very* slow. I feel like I'm using a 300baud modem as I type this into gmail. :-) Ken
Re: [UPDATE] devel/utop 1.15
On 1 September 2014 07:07, Christopher Zimmermann wrote:
> Here's an update for devel/utop 1.15. The broken Meta-Tab
> bar-completion is now fixed, so the README can go away. OK?
>
> Christopher
Interesting. I upgraded to utop 1.15 via opam yesterday and -TAB
or - still don't do anything useful for me. Either in X
(where cwm eats the as far as I can tell) or at the console. I'm
keen to understand what you're doing to make them work!
Ken
>
>
> Index: devel/utop/Makefile
> ===
> RCS file: /cvs/ports/devel/utop/Makefile,v
> retrieving revision 1.4
> diff -u -p -r1.4 Makefile
> --- devel/utop/Makefile 27 Aug 2014 08:05:17 - 1.4
> +++ devel/utop/Makefile 1 Sep 2014 10:12:13 -
> @@ -3,11 +3,11 @@
> COMMENT = enhanced OCaml toplevel
> CATEGORIES = devel
>
> -V =1.14
> +V =1.15
> GH_ACCOUNT = diml
> GH_PROJECT = utop
> GH_TAGNAME = ${V}
> -GH_COMMIT =af110d2742bc01ff7a898019676fa44e515043aa
> +GH_COMMIT =c77830eb9dc52e39c5ebcafac6ffe760a9dff012
> DISTNAME = ${GH_PROJECT}-$V
>
> HOMEPAGE = https://github.com/diml/utop
> @@ -21,7 +21,7 @@ CONFIGURE_ARGS += --enable-tests
>
> MODULES = lang/ocaml
> RUN_DEPENDS = devel/ocaml-lambda-term
> -BUILD_DEPENDS =${RUN_DEPENDS} sysutils/findlib
> lang/ocaml,-camlp4
> +BUILD_DEPENDS =${RUN_DEPENDS} sysutils/findlib
> lang/ocaml-camlp4
>
> # silence a warning
> post-extract:
> Index: devel/utop/distinfo
> ===
> RCS file: /cvs/ports/devel/utop/distinfo,v
> retrieving revision 1.2
> diff -u -p -r1.2 distinfo
> --- devel/utop/distinfo 27 Aug 2014 08:05:17 - 1.2
> +++ devel/utop/distinfo 1 Sep 2014 10:12:13 -
> @@ -1,2 +1,2 @@
> -SHA256 (utop-1.14.tar.gz) = 86OENG3LXOoOg3KtopA0PedDdH+G6qOlE2rd3LaNuJ0=
> -SIZE (utop-1.14.tar.gz) = 106017
> +SHA256 (utop-1.15.tar.gz) = Odd52QLsWhwBaDty3a3CsR/N/63jOFnfB6ELpU0H24A=
> +SIZE (utop-1.15.tar.gz) = 106190
> Index: devel/utop/pkg/PLIST
> ===
> RCS file: /cvs/ports/devel/utop/pkg/PLIST,v
> retrieving revision 1.2
> diff -u -p -r1.2 PLIST
> --- devel/utop/pkg/PLIST9 Mar 2014 19:50:33 - 1.2
> +++ devel/utop/pkg/PLIST1 Sep 2014 10:12:13 -
> @@ -15,7 +15,6 @@ lib/ocaml/utop/utop.cma
> @man man/man1/utop-full.1
> @man man/man1/utop.1
> @man man/man5/utoprc.5
> -share/doc/pkg-readmes/${FULLPKGNAME}
> share/doc/utop/
> share/doc/utop/CHANGES.md
> share/doc/utop/LICENSE
> @@ -28,6 +27,7 @@ share/doc/utop/api/index_attributes.html
> share/doc/utop/api/index_class_types.html
> share/doc/utop/api/index_classes.html
> share/doc/utop/api/index_exceptions.html
> +share/doc/utop/api/index_extensions.html
> share/doc/utop/api/index_methods.html
> share/doc/utop/api/index_module_types.html
> share/doc/utop/api/index_modules.html
> Index: devel/utop/pkg/README
> ===
> RCS file: devel/utop/pkg/README
> diff -N devel/utop/pkg/README
> --- devel/utop/pkg/README 17 Jul 2013 21:57:24 - 1.1.1.1
> +++ /dev/null 1 Jan 1970 00:00:00 -
> @@ -1,19 +0,0 @@
> -$OpenBSD: README,v 1.1.1.1 2013/07/17 21:57:24 edd Exp $
> -
> -+---
> -| Running ${FULLPKGNAME} on OpenBSD
> -+---
> -
> -Broken Bar-Complete
> -===
> -
> -The default bar-completion binding does not appear to work on OpenBSD.
> -This has been reported upstream: https://github.com/diml/utop/issues/19
> -
> -In the meantime you can bind bar-complete to something else, for example
> -ALT+down. Put the following in your ~/.lambda-term-rc:
> -
> 8<---
> -[read-line]
> -M-down: complete-bar
> 8<---
>
>
>
>
>
> --
> http://gmerlin.de
> OpenPGP: http://gmerlin.de/christopher.pub
> F190 D013 8F01 AA53 E080 3F3C F17F B0A1 D44E 4FEE
Re: [UPDATE] lang/ocaml 4.02
On 1 September 2014 17:21, Anil Madhavapeddy wrote: > On 1 Sep 2014, at 14:35, Christopher Zimmermann wrote: > >> On Mon, 1 Sep 2014 14:21:56 +0200 Anil Madhavapeddy >> wrote: >> >>> This is a huge update, thanks Christopher! Do you also want to take >>> joint MAINTAINER on OCaml? Main reason this should go in is that >>> 4.02 fixed all the sprintf/strcpy uses, so there are no more linker >>> warnings on every ocamlopt compilation. >>> >>> Bulk of the update is ok me; a few questions: >>> >>> - got a separate port for labltk now that it's pulled out? >> >> No. The only user I found is findlib's make_wizard, but I have no idea >> what it does. > > no idea -- can add the tk interface as a port later on if any users show up. > >> >>> - is there an upstream Mantis bug for the stack overflow detection? if so, >>> putting it in the port patch comment would make it easier to keep track of >>> what we need to upstream. >> >> I mailed it to c...@inria.fr. I can file a Mantis bug, too. > > A Mantis bug is definitely the way to make sure it gets fixed. > >> According to packages-specs(7), the package / ports system works well >> with rc versions. They are always below normal versions. So if a fast >> camlp4 release is not possible, we can use the rc, too. > > Final camlp4 version released from that tag now; > https://github.com/ocaml/camlp4/archive/4.02.0.tar.gz > > -anil > > Hmm. My dpb job got an error in databases/sqlports just after visiting the patched ocaml-net. Looking at the log for sqlports I see Fatal: Unknown flavor(s) pcre (in devel/ocaml-net) (No flavors for this port). (in devel/ocaml-net) *** Error 1 in devel/ocaml-net (/usr/ports/infrastructure/mk/bsd.port.mk:3552 '. BEGIN': @exit 1) devel/ocaml-net,pcre/bin/sh: exit 1: not found : exiting with an error Not sure which end is broken, but if it's not obvious to a ports-guru, I'll try to figure it out after dinner. I have the ocaml 4.02 diff applied, but not the ocamlp4 diff. Ken
Re: [NEW] lang/ocaml-camlp4
On 2 September 2014 00:50, Christopher Zimmermann wrote:
> On Mon, 1 Sep 2014 23:34:18 -0400 Kenneth Westerback
> wrote:
>
>> On 1 September 2014 07:12, Christopher Zimmermann wrote:
>> > Hi,
>> >
>> > OCaml 4.02 will no longer ship with camlp4. Therefore we need a
>> > separate port. OK?
>>
>> Since git, in what I ascribe to it's infinite annoying stupidity, does
>> not actually provide the information necessary to determine where you
>> intend this patch to be applied I'm kinda stymied. Especially when
>> sqlports bombed out again after jca@'s fix. This time complaining that
>> ocaml-camlp4 does not exit. :-(
>
>
> Well it wasn't git's, but my own stupidity. Here's a proper patch. This
> time with lang/Makefile addition, too. OK?
>
> Christopher
>
I like my git is stupid theory.
Anyway, I see all is committed! Much simpler. :-) Thanks.
Ken
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/lang/Makefile,v
> retrieving revision 1.163
> diff -u -p -r1.163 Makefile
> --- Makefile15 Aug 2014 12:24:46 - 1.163
> +++ Makefile2 Sep 2014 04:48:00 -
> @@ -66,6 +66,7 @@
> SUBDIR += nqp
> SUBDIR += obc
> SUBDIR += ocaml
> + SUBDIR += ocaml-camlp4
> SUBDIR += ocamlduce
> SUBDIR += onyx
> SUBDIR += oo2c
> Index: ocaml-camlp4/Makefile
> ===
> RCS file: ocaml-camlp4/Makefile
> diff -N ocaml-camlp4/Makefile
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ ocaml-camlp4/Makefile 2 Sep 2014 04:48:00 -
> @@ -0,0 +1,48 @@
> +# $OpenBSD: $
> +
> +COMMENT = OCaml Preprocessor and Pretty-Printer
> +CATEGORIES = lang
> +
> +V =4.02.0
> +GH_ACCOUNT = ocaml
> +GH_PROJECT = camlp4
> +GH_TAGNAME = ${V}
> +GH_COMMIT =0bb620fad7005850beadbf3aafeeb17d28c8fecd
> +DISTNAME = ${GH_PROJECT}-${GH_TAGNAME}
> +PKGNAME = ocaml-${DISTNAME}
> +
> +HOMEPAGE = https://github.com/ocaml/camlp4/
> +
> +MAINTAINER = Christopher Zimmermann
> +
> +# LGPL >=2.1
> +PERMIT_PACKAGE_CDROM = Yes
> +
> +MODULES = lang/ocaml
> +
> +WANTLIB += c m
> +BUILD_DEPENDS += sysutils/findlib
> +
> +USE_GMAKE =Yes
> +
> +CONFIGURE_STYLE = simple
> +
> +MAKE_ENV = DESTDIR=${WRKINST}
> +
> +ALL_TARGET = byte
> +
> +.include
> +.if ${PROPERTIES:Mocaml_native}
> +ALL_TARGET += native
> +.endif
> +
> +INSTALL_TARGET = install install-META
> +
> +
> +pre-install:
> + echo LIBDIR=${PREFIX}/lib/ocaml >>${WRKSRC}/config.sh
> + echo BINDIR=${PREFIX}/bin >>${WRKSRC}/config.sh
> + echo PKGDIR=${PREFIX}/lib/ocaml/camlp4 >>${WRKSRC}/config.sh
> +
> +
> +.include
> Index: ocaml-camlp4/distinfo
> ===
> RCS file: ocaml-camlp4/distinfo
> diff -N ocaml-camlp4/distinfo
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ ocaml-camlp4/distinfo 2 Sep 2014 04:48:00 -
> @@ -0,0 +1,2 @@
> +SHA256 (camlp4-4.02.0.tar.gz) = 6MuTgKfxtKhiadSr4hr8zws9lsbyB7hVwnFfOVgIu94=
> +SIZE (camlp4-4.02.0.tar.gz) = 697243
> Index: ocaml-camlp4/pkg/DESCR
> ===
> RCS file: ocaml-camlp4/pkg/DESCR
> diff -N ocaml-camlp4/pkg/DESCR
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ ocaml-camlp4/pkg/DESCR 2 Sep 2014 04:48:00 -
> @@ -0,0 +1,7 @@
> +Camlp4 is a software system for writing extensible parsers
> +for programming languages. It provides a set of OCaml
> +libraries that are used to define grammars as well as
> +loadable syntax extensions of such grammars. Camlp4 stands
> +for Caml Preprocessor and Pretty-Printer and one of its most
> +important applications is the definition of domain-specific
> +extensions of the syntax of OCaml.
> Index: ocaml-camlp4/pkg/PFRAG.native
> ===
> RCS file: ocaml-camlp4/pkg/PFRAG.native
> diff -N ocaml-camlp4/pkg/PFRAG.native
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ ocaml-camlp4/pkg/PFRAG.native 2 Sep 2014 04:48:00 -
> @@ -0,0 +1,75 @@
> +@comment $OpenBSD$
> +@bin bin/camlp4o.opt
> +@bin bin/camlp4of.opt
> +@bin bin/camlp4oof.opt
> +@bin bin/camlp4orf.opt
> +@bin bin/camlp4r.opt
> +@bin bin/camlp4rf.opt
> +lib/ocaml/camlp4/Camlp4Bin.cmx
> +lib/ocaml/camlp4/Camlp4Bin.o
> +lib/ocaml/camlp4/Camlp4Filters/Camlp4AstLifter.cmx
&g
Re: [UPDATE] lang/ocaml 4.02
On 1 September 2014 17:31, Kenneth Westerback wrote: > On 1 September 2014 17:21, Anil Madhavapeddy wrote: >> On 1 Sep 2014, at 14:35, Christopher Zimmermann wrote: >> >>> On Mon, 1 Sep 2014 14:21:56 +0200 Anil Madhavapeddy >>> wrote: >>> >>>> This is a huge update, thanks Christopher! Do you also want to take >>>> joint MAINTAINER on OCaml? Main reason this should go in is that >>>> 4.02 fixed all the sprintf/strcpy uses, so there are no more linker >>>> warnings on every ocamlopt compilation. >>>> >>>> Bulk of the update is ok me; a few questions: >>>> >>>> - got a separate port for labltk now that it's pulled out? >>> >>> No. The only user I found is findlib's make_wizard, but I have no idea >>> what it does. >> >> no idea -- can add the tk interface as a port later on if any users show up. >> >>> >>>> - is there an upstream Mantis bug for the stack overflow detection? if so, >>>> putting it in the port patch comment would make it easier to keep track of >>>> what we need to upstream. >>> >>> I mailed it to c...@inria.fr. I can file a Mantis bug, too. >> >> A Mantis bug is definitely the way to make sure it gets fixed. >> >>> According to packages-specs(7), the package / ports system works well >>> with rc versions. They are always below normal versions. So if a fast >>> camlp4 release is not possible, we can use the rc, too. >> >> Final camlp4 version released from that tag now; >> https://github.com/ocaml/camlp4/archive/4.02.0.tar.gz >> >> -anil >> >> > > Hmm. My dpb job got an error in databases/sqlports just after visiting > the patched ocaml-net. > > Looking at the log for sqlports I see > > Fatal: Unknown flavor(s) pcre (in devel/ocaml-net) >(No flavors for this port). (in devel/ocaml-net) > *** Error 1 in devel/ocaml-net (/usr/ports/infrastructure/mk/bsd.port.mk:3552 > '. > BEGIN': @exit 1) > devel/ocaml-net,pcre/bin/sh: exit 1: not found > : exiting with an error > > Not sure which end is broken, but if it's not obvious to a ports-guru, > I'll try to figure it out after dinner. > > I have the ocaml 4.02 diff applied, but not the ocamlp4 diff. > > Ken S close ... Got OCaml and OCaml-camlp4 built and installed. Some confusion about 'pkg_add -u' not working for OCaml or opam so I deleted the packages and re-installed. Also installed OCaml-graphics since it was there so I assumed it was necessary even if I hadn't asked for it specifically. Did 'opam install '. *Only* two did not work -- ocp-indent and async_graphics. Both complain that conduit is not available: $ opam install async_graphics The dependency ssl of package conduit.0.5.1 is not available for your compiler or your OS. 'opam install async_graphics' failed. $ cd - /usr/ports/packages/amd64/all $ opam install ocp-indent The dependency ssl of package conduit.0.5.1 is not available for your compiler or your OS. 'opam install ocp-indent' failed. Shouldn't affect anything I'm doing at the moment, but thought you'd be interested. List of things that did work: $ opam list Installed packages for system: async 111.25.00 Monadic concurrency library async_extra111.28.00 Monadic concurrency library async_kernel 111.28.00 Monadic concurrency library async_unix 111.28.00 Monadic concurrency library atd1.1.2 Parser for the ATD data format description languag atdgen 1.3.1 Generates efficient JSON serializers, deserializer base-bigarray base Bigarray library distributed with the OCaml compil base-bytes base Bytes library distributed with the OCaml compiler base-threadsbase Threads library distributed with the OCaml compile base-unix base Unix library distributed with the OCaml compiler bin_prot 111.03.00 A binary protocol generator biniou 1.0.9 Binary data format designed for speed, safety, eas camlp4 4.02.0+system Camlp4 is a system for writing extensible parsers camomile 0.8.5 A comprehensive Unicode library cmdliner 0.9.5 Declarative definition of command line interfaces cohttp0.11.2 HTTP library for Lwt, Async and Mirage comparelib 109.60.00 Part of Jane Streetâs Core library conduit0.5.1 Network connection library for TCP and SSL core 111.28.00 Industrial strength alternative to OCaml's standar core_bench 109.58.01 Benchmarking library core_kernel111.28.00 Industrial st
Re: [UPDATE] lang/ocaml 4.02
On 3 September 2014 03:14, Anil Madhavapeddy wrote: > On 3 Sep 2014, at 06:53, Kenneth Westerback wrote: >> >> Got OCaml and OCaml-camlp4 built and installed. Some confusion about >> 'pkg_add -u' not working for OCaml or opam so I deleted the packages >> and re-installed. Also installed OCaml-graphics since it was there so >> I assumed it was necessary even if I hadn't asked for it specifically. >> >> Did 'opam install '. *Only* two did not work -- >> ocp-indent and async_graphics. Both complain that conduit is not >> available: >> >> $ opam install async_graphics >> >> The dependency ssl of package conduit.0.5.1 is not available for your >> compiler or your OS. >> 'opam install async_graphics' failed. >> $ cd - >> /usr/ports/packages/amd64/all >> $ opam install ocp-indent >> >> The dependency ssl of package conduit.0.5.1 is not available for your >> compiler or your OS. >> 'opam install ocp-indent' failed. > > Can you try "opam install ssl", and if that fails, > "opam install async_graphics --debug"? "opam install ssl" followed by "opam install async_graphics" worked. And looking at 'opam list' on my other, as-yet-un-upgraded, box I see that ssl was present there. However, "opam install ocp-indent" failed. Albeit for apparently different reasons since it did not complain about conduit this time: ^[[31m[ERROR]^[[m Due to some errors while processing ocp-build.1.99.8-beta, the following actions will NOT proceed:^M - install ocp-indent.1.4.2^M ^M ^[[31m=^[[m ^[[01mERROR^[[m ^[[01mwhile installing ocp-build.1.99.8-beta^[[m ^[[31m=^[[m^M ^[[31m#^[[m ^[[31mopam-version^[[m 1.1.2^M ^[[31m#^[[m ^[[31mos^[[m openbsd^M ^[[31m#^[[m ^[[31mcommand^[[m gmake^M ^[[31m#^[[m ^[[31mpath^[[m /home/krw/.opam/system/build/ocp-build.1.99.8-beta^M ^[[31m#^[[m ^[[31mcompiler^[[m system (4.02.0)^M ^[[31m#^[[m ^[[31mexit-code^[[m2^M ^[[31m#^[[m ^[[31menv-file^[[m /home/krw/.opam/system/build/ocp-build.1.99.8-beta/ocp-build-19693-ffb3fd.env^M ^[[31m#^[[m ^[[31mstdout-file^[[m /home/krw/.opam/system/build/ocp-build.1.99.8-beta/ocp-build-19693-ffb3fd.out^M ^[[31m#^[[m ^[[31mstderr-file^[[m /home/krw/.opam/system/build/ocp-build.1.99.8-beta/ocp-build-19693-ffb3fd.err^M ^[[31m### stdout ###^M ^[[m^[[31m# ^[[m...[truncated]^M ^[[31m# ^[[mConfiguration for the "graph" library:^M ^[[31m# ^[[moptions for compiling -I/usr/X11R6/include^M ^[[31m# ^[[moptions for linking .. -L/usr/X11R6/lib -lX11^M ^[[31m# ^[[m^M ^[[31m# ^[[m** OCaml configuration completed successfully **^M ^[[31m# ^[[m^M ^[[31m# ^[[mocamlc -o ocp-build.run -custom -make-runtime win32_c.c primitives.ml unix.cma -cclib -lunix -I ocamlrun-4.02/byterun -cclib -lbyterun402^M ^[[31m# ^[[mMakefile:4: recipe for target 'ocp-build' failed^M ^[[31m# ^[[mgmake[1]: Leaving directory '/home/krw/.opam/system/build/ocp-build.1.99.8-beta/boot'^M ^[[31m# ^[[mMakefile:34: recipe for target 'boot/ocp-build' failed^M ^[[31m### stderr ###^M ^[[m^[[31m# ^[[mconfig.status: WARNING: '../src/ocp-build-bundle.ocp.in' seems to ignore the --datarootdir setting^M ^[[31m# ^[[mmake: don't know how to make w^M ^[[31m# ^[[mStop in /home/krw/.opam/system/build/ocp-build.1.99.8-beta/boot/ocamlrun-4.02/byterun^M ^[[31m# ^[[m/usr/bin/ld: cannot find -lbyterun402^M ^[[31m# ^[[mcollect2: ld returned 1 exit status^M ^[[31m# ^[[mFile "primitives.ml", line 1:^M ^[[31m# ^[[mError: Error while building custom runtime system^M ^[[31m# ^[[mgmake[1]: *** [ocp-build] Error 2^M ^[[31m# ^[[mgmake: *** [boot/ocp-build] Error 2^M ^M The full output from "opam install ocp-indent --debug" is at ~krw/ocpindent.debug on cvs. Ken > > I suspect this may be due to the internal package solver in 1.1.1, > but I'll have a port of OPAM 1.2.0 to put into the tree quite > shortly (with an improved solver). We could really use a port of > aspcud (an external solver that is picked up and used if present), > but it's a pain to port due to requiring a newer bison than we > have. > > -anil
Re: [UPDATE] lang/ocaml 4.02
On 3 September 2014 03:34, Anil Madhavapeddy wrote: > On 3 Sep 2014, at 09:32, Christopher Zimmermann wrote: > >> On Wed, 3 Sep 2014 09:14:00 +0200 Anil Madhavapeddy >> wrote: >> >>> On 3 Sep 2014, at 06:53, Kenneth Westerback wrote: >>>> >>>> Got OCaml and OCaml-camlp4 built and installed. Some confusion about >>>> 'pkg_add -u' not working for OCaml or opam so I deleted the packages >>>> and re-installed. Also installed OCaml-graphics since it was there so >>>> I assumed it was necessary even if I hadn't asked for it specifically. >>>> >>>> Did 'opam install '. *Only* two did not work -- >>>> ocp-indent and async_graphics. Both complain that conduit is not >>>> available: >>>> >>>> $ opam install async_graphics >>>> >>>> The dependency ssl of package conduit.0.5.1 is not available for your >>>> compiler or your OS. >>>> 'opam install async_graphics' failed. >>>> $ cd - >>>> /usr/ports/packages/amd64/all >>>> $ opam install ocp-indent >>>> >>>> The dependency ssl of package conduit.0.5.1 is not available for your >>>> compiler or your OS. >>>> 'opam install ocp-indent' failed. >>> >>> Can you try "opam install ssl", and if that fails, >>> "opam install async_graphics --debug"? >>> >>> I suspect this may be due to the internal package solver in 1.1.1, >>> but I'll have a port of OPAM 1.2.0 to put into the tree quite >>> shortly (with an improved solver). We could really use a port of >>> aspcud (an external solver that is picked up and used if present), >>> but it's a pain to port due to requiring a newer bison than we >>> have. >> >> Hi, >> >> well, I guess we did double work. I have an opam 1.2.0 port ready at >> wip... >> > > Happy to use yours -- I'm busy fixing the actual opam tool itself, > so the port shouldn't need any local patches... > > If you get a chance to look at aspcud and friends, that would be > very useful indeed, but you'll run into the bison issue with gringo. > > -a And I'm happy to test either ... if Chris will let me know where his 'wip' is, or Anil sends me his. :-) Ken
Re: Opam 3.2.2
On 3 September 2014 08:05, Christopher Zimmermann wrote:
> On Wed, 3 Sep 2014 07:47:20 -0400 Kenneth Westerback
> wrote:
>
>> And I'm happy to test either ... if Chris will let me know where his
>> 'wip' is, or Anil sends me his. :-)
>
>
> It's here: https://github.com/jasperla/openbsd-wip
>
> Simply do
> git clone https://github.com/jasperla/openbsd-wip.git /usr/ports/wip
>
> and put something like
> PORTSDIR_PATH = ${PORTSDIR}/mystuff:${PORTSDIR}:${PORTSDIR}/wip
> into your /etc/mk.conf
>
>
> Christopher
>
> --
> http://gmerlin.de
> OpenPGP: http://gmerlin.de/christopher.pub
> F190 D013 8F01 AA53 E080 3F3C F17F B0A1 D44E 4FEE
Thanks! I should be able to try that out later today when I return
from various chores.
Ken
Re: Opam 3.2.2
On 3 September 2014 08:05, Christopher Zimmermann wrote:
> On Wed, 3 Sep 2014 07:47:20 -0400 Kenneth Westerback
> wrote:
>
>> And I'm happy to test either ... if Chris will let me know where his
>> 'wip' is, or Anil sends me his. :-)
>
>
> It's here: https://github.com/jasperla/openbsd-wip
>
> Simply do
> git clone https://github.com/jasperla/openbsd-wip.git /usr/ports/wip
>
> and put something like
> PORTSDIR_PATH = ${PORTSDIR}/mystuff:${PORTSDIR}:${PORTSDIR}/wip
> into your /etc/mk.conf
>
>
> Christopher
>
> --
> http://gmerlin.de
> OpenPGP: http://gmerlin.de/christopher.pub
> F190 D013 8F01 AA53 E080 3F3C F17F B0A1 D44E 4FEE
I tossed your wip opam into the list of ports that were building on my
sparc64 and all went well. Haven't actually tested it yet. I'll do a
test and the "more important" amd64 ports build as soon as the sparc64
one is done hogging the tree.
Ken
Re: [FIX] lang/ocaml
On 10 October 2014 12:59, Christopher Zimmermann wrote:
> Hi,
>
> here are some fixes and a new CONFIGURE_STYLE for lang/ocaml.
>
> * add an oasis_setup CONFIGURE_STYLE, see the port-modules doc below.
>
> * Set CONFIGURE_ARGS += --enable-tests depending on NO_TEST in oasis
> CONFIGURE_STYLE.
>
> * install ocamlbuild.1
>
> * two patches already committed upstream for the next release, but I'd
> like to have them now.
>
> OK?
>
> Christopher
Been working fine for me for on amd64 for a few weeks, so ok krw@ fwiw.
Ken
>
>
> Index: port-modules.5
> ===
> RCS file: /cvs/src/share/man/man5/port-modules.5,v
> retrieving revision 1.181
> diff -u -p -r1.181 port-modules.5
> --- port-modules.5 8 Sep 2014 05:04:40 - 1.181
> +++ port-modules.5 10 Oct 2014 16:54:08 -
> @@ -858,6 +858,9 @@ property is set.
> When
> .Ev CONFIGURE_STYLE is set to `oasis',
> overrides for the do\-build, do\-install and do\-test targets are added.
> +`oasis_setup' can be used in addition to `oasis' to re-run `oasis setup' to
> +regenerate the _tags, myocamlbuild, setup.ml and various other files.
> +This is similar in functionality to autoconf/automake.
> .It lang/php/pecl
> Used for ports for PHP PECL extensions.
> Sets default
>
>
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/lang/ocaml/Makefile,v
> retrieving revision 1.66
> diff -u -p -r1.66 Makefile
> --- Makefile4 Sep 2014 15:56:26 - 1.66
> +++ Makefile10 Oct 2014 16:45:40 -
> @@ -11,7 +11,7 @@ COMMENT-graphics = OCaml Graphics librar
> # Do check that the ports that depend on it still work, or repair them.
> # Don't forget to bump version in ocaml.port.mk, too!
> VERSION=4.02.0
> -REVISION=0
> +REVISION=1
>
> PKGNAME-main = ocaml-${VERSION}
> PKGNAME-graphics = ocaml-graphics-${VERSION}
> @@ -72,6 +72,9 @@ post-install:
> ${PREFIX}/share/doc/ocaml/html
> @${INSTALL_DATA} ${WRKDIR}/htmlman/libref/* \
> ${PREFIX}/share/doc/ocaml/html/libref
> + ${INSTALL_DATA} \
> + ${WRKSRC}/ocamlbuild/man/ocamlbuild.1 \
> + ${PREFIX}/man/man1/
> @${INSTALL_DATA} \
> ${WRKSRC}/{LICENSE,Changes} \
> ${PREFIX}/share/doc/ocaml
> Index: ocaml.port.mk
> ===
> RCS file: /cvs/ports/lang/ocaml/ocaml.port.mk,v
> retrieving revision 1.29
> diff -u -p -r1.29 ocaml.port.mk
> --- ocaml.port.mk 8 Sep 2014 05:10:10 - 1.29
> +++ ocaml.port.mk 10 Oct 2014 16:45:40 -
> @@ -57,6 +57,13 @@ INSTALL_TARGET = -install
> TEST_TARGET ?= -test
> _MODOASIS_SETUP = ${WRKDIR}/oasis_setup.byte
>
> +. if ${NO_TEST:L} == "no"
> +CONFIGURE_ARGS += --enable-tests
> +. else
> +CONFIGURE_ARGS += --disable-tests
> +. endif
> +
> +
> ##
> # CONFIGURE
> .if ${PROPERTIES:Mocaml_native}
> @@ -64,7 +71,12 @@ _MODOASIS_OCAMLC = ocamlc.opt
> .else
> _MODOASIS_OCAMLC = ocamlc
> .endif
> -MODOASIS_configure = \
> +
> +. if ${CONFIGURE_STYLE:L:Moasis_setup}
> +BUILD_DEPENDS += sysutils/oasis
> +MODOASIS_configure += cd ${WRKSRC} && oasis setup &&
> +. endif
> +MODOASIS_configure += \
> ${_MODOASIS_OCAMLC} -o ${_MODOASIS_SETUP} ${WRKSRC}/setup.ml && \
> cd ${WRKSRC} && \
> rm setup.cm[io] && \
> @@ -74,6 +86,7 @@ MODOASIS_configure = \
> --infodir ${PREFIX}/info \
> --override pkg_name ${PKGNAME:C/-[0-9].*//} \
> ${CONFIGURE_ARGS}
> +
>
> ##
> # BUILD
> Index: patches/patch-ocamlbuild_ocaml_specific_ml
> ===
> RCS file: patches/patch-ocamlbuild_ocaml_specific_ml
> diff -N patches/patch-ocamlbuild_ocaml_specific_ml
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-ocamlbuild_ocaml_specific_ml 10 Oct 2014 16:45:40 -
> @@ -0,0 +1,15 @@
> +$OpenBSD$
> +
> +PR#6544: the bin_annot flag is only effective when compiling. It should be
> +enabled when packing, too.
> +
> +--- ocamlbuild/ocaml_specific.ml.orig Fri Aug 29 09:35:50 2014
> ocamlbuild/ocaml_specific.ml Mon Oct 6 16:42:59 2014
> +@@ -669,6 +669,7 @@ flag ["ocaml"; "link"; "byte"; "output_obj"] (A"-outpu
> + flag ["ocaml"; "dtypes"; "compile"] (A "-dtypes");;
> + flag ["ocaml"; "annot"; "compile"] (A "-annot");;
> + flag ["ocaml"; "bin_annot"; "compile"] (A "-bin-annot");;
> ++flag ["ocaml"; "bin_annot"; "pack"] (A "-bin-annot");;
> + flag ["ocaml"; "safe_string"; "compile"] (A "-safe-string");;
> + flag ["ocaml"; "safe_string"; "infer_interface"] (A "-safe-string");;
> + flag ["ocaml"; "unsafe_string"; "compile"] (A "-unsafe-string");;
> Index: patches/patch-otherlibs_threads_Makefile
> ===
Re: [NEW] OCaml oasis and Janestreet Core and Async
On 10 October 2014 13:03, Christopher Zimmermann wrote:
> Hi,
>
> attached you find many new OCaml ports. Mainly the following two and
> their dependencies:
>
> * Oasis (an OCaml project build and metadata tool) used by many of our
> OCaml ports.
>
> * Janestreet Core standard library overlay and Janestreet Async
>
> Oasis depends on devel/janestreet/ocaml-type_conv while most of
> janestreet stuff uses oasis. If this is too much, I could leave the rest
> of janestreet for now and only import ocaml-type_conv.
>
> Since I'm currently waiting for the release of OPAM 1.2
> (https://github.com/jasperla/openbsd-wip/tree/master/sysutils/opam),
> which can be used to install all those libraries and binaries, I'm
> wondering whether it still makes any sense to maintain those ports in
> our ports tree. The same applies to other ports already in our tree
> like devel/{utop,ocaml-lambda-term,ocaml-lwt} ...). Opinions? OKs?
>
>
> Christopher
Personally I would prefer to use opam over ports. The only reason I
can see for maintaining ports is if they are needed to build other
ocaml ports (mldonkey?) in the tree. That's my 0.05C (Canada has
eliminated the penny).
Ken
>
>
> The ports are also at /cvs.d/hack/chrisz/janestreet.tgz.
> This is the full list of new ports:
>
> devel/ocaml-data-notation
> devel/ocaml-expect
> devel/ocaml-fileutils
> devel/ocaml-mod
> devel/ocaml-ocamlify
> sysutils/oasis
> devel/janestreet/ocaml-type_conv
> devel/janestreet/ocaml-async
> devel/janestreet/ocaml-async_extra
> devel/janestreet/ocaml-async_kernel
> devel/janestreet/ocaml-async_shell
> devel/janestreet/ocaml-async_unix
> devel/janestreet/ocaml-bin_prot
> devel/janestreet/ocaml-comparelib
> devel/janestreet/ocaml-core
> devel/janestreet/ocaml-core_extended
> devel/janestreet/ocaml-core_kernel
> devel/janestreet/ocaml-custom_printf
> devel/janestreet/ocaml-enumerate
> devel/janestreet/ocaml-fieldslib
> devel/janestreet/ocaml-herelib
> devel/janestreet/ocaml-pa_bench
> devel/janestreet/ocaml-pa_ounit
> devel/janestreet/ocaml-pa_test
> devel/janestreet/ocaml-pipebang
> devel/janestreet/ocaml-re2
> devel/janestreet/ocaml-sexplib
> devel/janestreet/ocaml-textutils
> devel/janestreet/ocaml-typerep
> devel/janestreet/ocaml-variantslib
>
>
> --
> http://gmerlin.de
> OpenPGP: http://gmerlin.de/christopher.pub
> F190 D013 8F01 AA53 E080 3F3C F17F B0A1 D44E 4FEE
Re: [NEW] OCaml oasis and Janestreet Core and Async
On 10 October 2014 14:46, Kenneth Westerback wrote:
> On 10 October 2014 13:03, Christopher Zimmermann
> wrote:
>> Hi,
>>
>> attached you find many new OCaml ports. Mainly the following two and
>> their dependencies:
>>
>> * Oasis (an OCaml project build and metadata tool) used by many of our
>> OCaml ports.
>>
>> * Janestreet Core standard library overlay and Janestreet Async
>>
>> Oasis depends on devel/janestreet/ocaml-type_conv while most of
>> janestreet stuff uses oasis. If this is too much, I could leave the rest
>> of janestreet for now and only import ocaml-type_conv.
>>
>> Since I'm currently waiting for the release of OPAM 1.2
>> (https://github.com/jasperla/openbsd-wip/tree/master/sysutils/opam),
>> which can be used to install all those libraries and binaries, I'm
>> wondering whether it still makes any sense to maintain those ports in
>> our ports tree. The same applies to other ports already in our tree
>> like devel/{utop,ocaml-lambda-term,ocaml-lwt} ...). Opinions? OKs?
>>
>>
>> Christopher
>
> Personally I would prefer to use opam over ports. The only reason I
> can see for maintaining ports is if they are needed to build other
> ocaml ports (mldonkey?) in the tree. That's my 0.05C (Canada has
> eliminated the penny).
>
> Ken
I guess we would also need a port when upstream needs patches to
compile on OpenBSD. Hopefully a rare situation going forward.
Ken
>
>>
>>
>> The ports are also at /cvs.d/hack/chrisz/janestreet.tgz.
>> This is the full list of new ports:
>>
>> devel/ocaml-data-notation
>> devel/ocaml-expect
>> devel/ocaml-fileutils
>> devel/ocaml-mod
>> devel/ocaml-ocamlify
>> sysutils/oasis
>> devel/janestreet/ocaml-type_conv
>> devel/janestreet/ocaml-async
>> devel/janestreet/ocaml-async_extra
>> devel/janestreet/ocaml-async_kernel
>> devel/janestreet/ocaml-async_shell
>> devel/janestreet/ocaml-async_unix
>> devel/janestreet/ocaml-bin_prot
>> devel/janestreet/ocaml-comparelib
>> devel/janestreet/ocaml-core
>> devel/janestreet/ocaml-core_extended
>> devel/janestreet/ocaml-core_kernel
>> devel/janestreet/ocaml-custom_printf
>> devel/janestreet/ocaml-enumerate
>> devel/janestreet/ocaml-fieldslib
>> devel/janestreet/ocaml-herelib
>> devel/janestreet/ocaml-pa_bench
>> devel/janestreet/ocaml-pa_ounit
>> devel/janestreet/ocaml-pa_test
>> devel/janestreet/ocaml-pipebang
>> devel/janestreet/ocaml-re2
>> devel/janestreet/ocaml-sexplib
>> devel/janestreet/ocaml-textutils
>> devel/janestreet/ocaml-typerep
>> devel/janestreet/ocaml-variantslib
>>
>>
>> --
>> http://gmerlin.de
>> OpenPGP: http://gmerlin.de/christopher.pub
>> F190 D013 8F01 AA53 E080 3F3C F17F B0A1 D44E 4FEE
Re: [NEW] OCaml oasis and Janestreet Core and Async
On 11 October 2014 09:09, Anil Madhavapeddy wrote:
> On 10 Oct 2014, at 11:48, Kenneth Westerback wrote:
>
>> On 10 October 2014 14:46, Kenneth Westerback wrote:
>>> On 10 October 2014 13:03, Christopher Zimmermann
>>> wrote:
>>>> Hi,
>>>>
>>>> attached you find many new OCaml ports. Mainly the following two and
>>>> their dependencies:
>>>>
>>>> * Oasis (an OCaml project build and metadata tool) used by many of our
>>>> OCaml ports.
>>>>
>>>> * Janestreet Core standard library overlay and Janestreet Async
>>>>
>>>> Oasis depends on devel/janestreet/ocaml-type_conv while most of
>>>> janestreet stuff uses oasis. If this is too much, I could leave the rest
>>>> of janestreet for now and only import ocaml-type_conv.
>>>>
>>>> Since I'm currently waiting for the release of OPAM 1.2
>>>> (https://github.com/jasperla/openbsd-wip/tree/master/sysutils/opam),
>>>> which can be used to install all those libraries and binaries, I'm
>>>> wondering whether it still makes any sense to maintain those ports in
>>>> our ports tree. The same applies to other ports already in our tree
>>>> like devel/{utop,ocaml-lambda-term,ocaml-lwt} ...). Opinions? OKs?
>>>>
>>>>
>>>> Christopher
>>>
>>> Personally I would prefer to use opam over ports. The only reason I
>>> can see for maintaining ports is if they are needed to build other
>>> ocaml ports (mldonkey?) in the tree. That's my 0.05C (Canada has
>>> eliminated the penny).
>>>
>>> Ken
>>
>> I guess we would also need a port when upstream needs patches to
>> compile on OpenBSD. Hopefully a rare situation going forward.
>
> I'm happy to merge OpenBSD-specific fixes into OPAM -- it's possible to
> add OS-specific selectors in the patches field to not affect other OSes.
>
> However, it is very convenient to be able to depend on a binary
> installation of OCaml libraries for end-user applications, particularly
> given the strict versioning requirements. The OpenBSD port is also
> higher quality when it comes to architecture portability, since it
> separates out bytecode vs native code vs native dynlinking architectures.
>
> There is enough metadata available in an OPAM package to generate a
> snapshot of OpenBSD ports from a given package set. I'm not suggesting
> we automatically import the results into OpenBSD, but it would really
> help keep the ports tree in sync with the latest versions of libraries.
> The metadata needed for this is roughly:
>
> - build instructions -- present in OPAM, but they do not separate out
> fake installation and native code at the moment. This could be added
> to OPAM fairly easily.
>
> - external dependencies -- OPAM has a 'depexts' field where OS packages
> can be specified. This is a free-form field, so it could be a precise
> pkgspec for the OpenBSD entry.
>
> - categories and homepages -- these can be lifted straight out of the
> OPAM spec, and tags can be used to map OpenBSD-specific information.
>
> More broadly though, does any other language-specific packaging system
> do this at the moment, or all ports maintained manually?
>
> -anil
IANA porter, so I speak only from a user perspective. And I don't use
any perl ports so I don't know if they represent all perl ports used
on OpenBSD or just those needed OpenBSD specific tweaks.
If there are OpenBSD specific patches needed then I think a port is
the way to go. I'd hate to have a lot of info kept in opam only to
find Oxford has kidnapped Anil on boat race night and is demanding the
OpenBSD Ocaml community cough up. :-)
I currently have no idea how many OpenBSD patches are needed. The
couple I found while playing with getting core_extended working were
fixed by OpenBSD commits or are in queue to get fixed in core_extended
(right, Anil?). The other packages I needed/wanted to try all worked
from the wip opam 1.2 port.
My two minor concerns are 1) making sure RWO readers find OpenBSD a
congenial place to follow along, and 2) making sure that opam and
ports can co-exist if opam is available on OpenBSD.
In regards to 2), I encountered confusion when I had utop port
installed and then also blithely installed it with opam. Not to say it
is certain that I didn't screw up something just on my system, but the
relations between the two should be well known/easily discovered.
Ken
Re: building individual ports via MinGW
On 19 October 2014 07:29, R . wrote: > i know that m4 comes bundled together as part of the OS and typically only > gets built every build of OpenBSD, but is there a way to compile just the m4 > under MinGW?? i only need the binaries, no need for the manuals or things > like that. > I would think 1) Get the source tree. 2) cd /usr/src/usr.bin/m4 3) make clean; make obj; make 4) take your obj/m4 to wherever it needs to go. is sufficient. I ignore any complications due to trying this under MinGW since I still have nightmares from my brief exposure to it. Ken
Re: go ports.
On 19 October 2014 13:32, Edd Barrett wrote: > Hey, > > I just tried porting a go application and ran into trouble. Looks like > there are no go ports in-tree, and I think I know why. > > Go has one of these build systems that downloads (moving target) > dependencies. It reminds me of node. > > Has anyone else tried porting go stuff? This sounds similar to the challenges facing chrisz@ over Ocaml ports vs opam. Perhaps the two of you should discuss a Grand Unified Theory of Dependencies. Ken > > I guess what we would need to do is port each individual go dependency we > need, then add a systrace policy that blocks the go build system from > downloading dependencies. Any comments on that strategy? > > The application I was porting was pulse, a distributed file sync tool: > https://github.com/jasperla/openbsd-wip/tree/master/net/pulse > > If this turns out to be useful, and if I find some time, I may have a go at > porting all the deps and making a go.port.mk to automate much of the path > jiggery pokery the go build system expects. > > -- > Best Regards > Edd Barrett > > http://www.theunixzoo.co.uk >
Re: [NEW] sysutils/opam 1.2.0
On 24 October 2014 04:17, Christopher Zimmermann wrote: > Hi, > > now that OPAM 1.2.0 is released I'd like to import it. The opam port > and its dependencies are at wip: > https://github.com/jasperla/openbsd-wip/ > > the dependencies are: > devel/cudf > devel/ocaml-cmdliner > devel/ocaml-dose > devel/ocaml-graph > devel/ocaml-jsonm > devel/ocaml-re > devel/ocaml-uutf > > OK? > > > Christopher > > -- > http://gmerlin.de > OpenPGP: http://gmerlin.de/christopher.pub > F190 D013 8F01 AA53 E080 3F3C F17F B0A1 D44E 4FEE Works for me, so ok krw@. Ken
Re: [NEW] sysutils/opam 1.2.0
On 25 October 2014 08:37, Christopher Zimmermann wrote: > On Sat, 25 Oct 2014 07:55:52 -0400 Kenneth Westerback > wrote: > >> On 24 October 2014 19:37, Kenneth Westerback >> wrote: >> > On 24 October 2014 04:17, Christopher Zimmermann >> > wrote: >> >> Hi, >> >> >> >> now that OPAM 1.2.0 is released I'd like to import it. The opam >> >> port and its dependencies are at wip: >> >> https://github.com/jasperla/openbsd-wip/ >> >> >> >> the dependencies are: >> >> devel/cudf >> >> devel/ocaml-cmdliner >> >> devel/ocaml-dose >> >> devel/ocaml-graph >> >> devel/ocaml-jsonm >> >> devel/ocaml-re >> >> devel/ocaml-uutf >> >> >> >> OK? >> >> >> >> >> >> Christopher >> >> >> >> -- >> >> http://gmerlin.de >> >> OpenPGP: http://gmerlin.de/christopher.pub >> >> F190 D013 8F01 AA53 E080 3F3C F17F B0A1 D44E 4FEE >> > >> > Works for me, so ok krw@. >> > >> > Ken >> >> Apologies. I spoke too soon/insufficiently cleaned my system prior to >> testing. >> >> devel/ocaml-uutf >> >> still fails to build+package from a clean system because it can't find >> ocamlfind. So BUILD_DEPENDS on ocamlfind is required. >> >> Ken > > Thanks for testing! I added the findlib dependency. Building on > "bytecode only amd64" works, too. Do you think I can import now? > ok krw@ (again. :-)). Ken > > -- > http://gmerlin.de > OpenPGP: http://gmerlin.de/christopher.pub > F190 D013 8F01 AA53 E080 3F3C F17F B0A1 D44E 4FEE
Re: [UPDATE] devel/utop -> [UPDATE] devel/ocaml-lambda-term
On 27 October 2014 05:23, Christopher Zimmermann wrote: > Hi, > > utop 1.16 needs cppo, which is not yet in cvs, but a port is ready at > https://github.com/jasperla/openbsd-wip/tree/master/devel/ocaml-cppo > > OK to import? > > > Christopher > > -- > http://gmerlin.de > OpenPGP: http://gmerlin.de/christopher.pub > F190 D013 8F01 AA53 E080 3F3C F17F B0A1 D44E 4FEE I use opam to keep utop up-to-date so I'm not sure if I'm qualified to comment, but I have no objections to keeping the utop port current by adding a new dependency port. Ken
Re: tedu print/acroread
On 27 October 2014 12:08, David Coppa wrote: > Given this: > > http://blogs.adobe.com/adobereader/2012/06/one-year-from-now-adobe-reader-and-acrobat-9-eol.html > > Adobe has discontinued the support of Adobe Reader for Linux in June > 2013, and the fact that our port is even older (v7.x)... > > Can we finally put print/acroread to the Attic? > > There're a lot of valid alternatives nowadays! > > Ciao, > David > -- > "If you try a few times and give up, you'll never get there. But if > you keep at it... There's a lot of problems in the world which can > really be solved by applying two or three times the persistence that > other people will." > -- Stewart Nelson > I would not step in front of a bus to save it. Ken
www/p5-HTTP-GHTTP vs new Perl
Building my usual suspects on amd64 -current as of this morning I get ===> Configuring for p5-HTTP-GHTTP-1.07p5 running gnome-config... using fallback values for LIBS and INC failed options: LIBS='-L/usr/local/lib -L/usr/lib -lghttp' INC='-I/usr/local/include -I/usr/include' If this is wrong, Re-run as: $ perl Makefile.PL LIBS='-L/path/to/lib' INC='-I/path/to/include' checking for main() in -lghttp... libghttp not found Try setting LIBS and INC values on the command line Or get libghttp from ftp://ftp.gnome.org/pub/GNOME/stable/sources/libghttp/ no Which I assume is some fallout from the new Perl? Ken
Re: www/p5-HTTP-GHTTP vs new Perl
On 22 November 2014 at 14:01, ni...@openbsd.org wrote: > On 11/22/14 17:23, Kenneth Westerback wrote: >> Building my usual suspects on amd64 -current as of this morning I get >> >> ===> Configuring for p5-HTTP-GHTTP-1.07p5 >> running gnome-config... using fallback values for LIBS and INC >> failed >> options: >> LIBS='-L/usr/local/lib -L/usr/lib -lghttp' >> INC='-I/usr/local/include -I/usr/include' >> If this is wrong, Re-run as: >> $ perl Makefile.PL LIBS='-L/path/to/lib' INC='-I/path/to/include' >> >> checking for main() in -lghttp... libghttp not found >> Try setting LIBS and INC values on the command line >> Or get libghttp from >> ftp://ftp.gnome.org/pub/GNOME/stable/sources/libghttp/ >> no >> >> Which I assume is some fallout from the new Perl? >> >> Ken >> >> > > I would guess that your using dpb to build. Try repeating just building > www/p5-HTTP-GHTTP with make or dpb. Your probably find it build, I built > it here with perl 5.20.1. > OK, I'll do that in the next cycle. I am using dpb. Ken
Re: Fallout from stricter memcpy()
On 23 November 2014 at 07:14, Christian Weisgerber wrote: > On 2014-11-22, Christian Weisgerber wrote: > >> emulators/sdlmame m68kmake >> emulators/sdlmess m68kmake >> lang/gcc/4.8ada >> lang/gcc/4.9ada > > + textproc/p5-SWISH-API swish-e > > And that's all. > > -- > Christian "naddy" Weisgerber na...@mips.inka.de > I can confirm the 4.8/ada issue. :-) Ken
Re: Maintainer Update: www/p5-libwww GNOME I libghttp removal from ports
On 14 December 2014 at 13:50, Nigel Taylor wrote: > Time to remove GNOME I from ports, it's old and ancient, and not > maintained anymore. > > libghttp was the forerunner to libsoup and part of GNOME I, used to > speed up p5-libwww, provided by including www/p5-HTTP-GHTTP, a wrapper > around www/libghttp. This is the only remaining port using this GNOME I > library. The dependency has lingered on but not used. > > Once p5-libwww has been updated, the www/p5-HTTP-GHTTP port can be > removed and then followed by www/libghttp. > > I been using p5-libwww without libghttp/p5-HTTP-GHTTP for sometime on amd64. > > Only asking for Ok / Comments on www/p5-libwww > Without commenting on technical desirability, although your justification seems plausible to me, I can say I would *love* to see this because p5-HTTP-GHTTP has been crapping out of my dpb builds for some weeks now for reasons I haven't figured out, beyond knowing it was related to libghttp. :-) Ken
Re: Maintainer Update: www/p5-libwww GNOME I libghttp removal from ports
On 15 December 2014 at 13:02, ni...@openbsd.org wrote: > On 12/14/14 19:07, Kenneth Westerback wrote: >> On 14 December 2014 at 13:50, Nigel Taylor >> wrote: >>> Time to remove GNOME I from ports, it's old and ancient, and not >>> maintained anymore. >>> >>> libghttp was the forerunner to libsoup and part of GNOME I, used to >>> speed up p5-libwww, provided by including www/p5-HTTP-GHTTP, a wrapper >>> around www/libghttp. This is the only remaining port using this GNOME I >>> library. The dependency has lingered on but not used. >>> >>> Once p5-libwww has been updated, the www/p5-HTTP-GHTTP port can be >>> removed and then followed by www/libghttp. >>> >>> I been using p5-libwww without libghttp/p5-HTTP-GHTTP for sometime on amd64. >>> >>> Only asking for Ok / Comments on www/p5-libwww >>> >> >> Without commenting on technical desirability, although your >> justification seems plausible to me, I can say I would *love* to see >> this because p5-HTTP-GHTTP has been crapping out of my dpb builds for >> some weeks now for reasons I haven't figured out, beyond knowing it >> was related to libghttp. :-) >> >> Ken >> > Looking back at dpb logs p5-HTTP-GHTTP / libghttp built first time, 3 > time in a row, and can't recall ever having failed, doesn't mean I don't > believe your having problems. I have seen the same in my dpb builds with > other ports far too often, where you can't explain why they failed other > than using dpb. > > Removing p5-HTTP-GHTTP is likely to just shift the problem elsewhere. > I wouldn't be surprised. No idea what it is about my environment that causes the problem, so it could easily migrate. I've even tried not using tmpfs for /tmp without any change. "checking for main() in -lghttp... libghttp not found" is what happens. Even though I can *SEE* libghttp is in place. Perhaps it's caught up in caching for somehow. I guess I could dial my bufcachepercent down from 90. And when I kick it into retrying by 'make clean' in /usr/ports/www/p5-HTTP-GHTTP and removing all the "*GHTTP*" logs, it eventually works even though the libghttp is untouched by anything in the meantime. Even if p5-HTTP-GHTTP is the *only* port I try to build with dpb it fails. Sigh. I'd be happy to move on to another problem child, just for variety. :-). Ken
Re: java coders are complete morons
On 30 December 2014 at 18:13, Marc Espie wrote: > well, jdk 1.7 just stopped building. because one file is >10 years old and > there is an explicit check for that in the build process. > > Just think about it. > > I know 1st year students who are smarter than that. > > This is one of the stupidest bugs I've seen, on a part with 19100... > I thought Java was supposed to be "write once, works forever". :-) Ken
Re: Problem with chromium-40.0.2214.91p0
On 28 January 2015 at 03:00, Jonathan Gray wrote: > On Wed, Jan 28, 2015 at 02:48:00AM -0500, STeve Andre' wrote: >> On 01/28/15 02:27, Benoit Lecocq (BLQ) wrote: >> > >> >On 01/28/15 06:24, STeve Andre' wrote: >> >>Chrome isn't working at the moment. The screen is sold black. If >> >>I start with chrome nytimes.com the title bar says New York Times, >> >>so chrome is working but doesn't display. >> >> >> >>I see an error message >> >> >> >>ATTENTION: default value of option force_s3tc_enable overridden by >> >>environment. >> >>[50:-1956073728:0128/000817:ERROR:net_util_posix.cc(281)] Not >> >>implemented reached in bool net::GetNetworkList(NetworkInterfaceList *, >> >>int) >> >> >> >>but just black in the chrome window. >> >> >> >>This is an amd64-current system, compiled on Tues Jan 27th 8pm >> >>EST, cvsup'd just before via spacehopper.org. The package set is >> >>dated Jan 24th, pulled from mirror.team-cymru.org. >> >> >> >>--STeve Andre' >> >> >> >I have solved the problem with : "chrome --disable-gpu" >> > >> >cheers, >> >benoit >> > >> Well, that worked. Thank you Benoit. > > That is not a fix (and neither is --disable-gpu-compositing). > > It would be useful if people seeing this could mention what graphics > hardware they are running and if they are using a self built version of > xenocara with the Mesa update or the snapshots which seem to be lagging > and don't have the Mesa update. > > The window manager used may matter as well, it seems chromium > has had issues with non composited wms in the past. > Indeed. Using cwm on my amd64+"ATI Radeon HD 5450" with self-built snaps, Chromium has had problems for quite a while now. Basically not redrawing itself as I move xterms across it or switch focus to it. I've just gotten used to moving the cursor to the navigation bar to force a redraw. On the "black square" front I did notice that if I move the cursor into the probable navigation bar area the cursor shape changes to the bar shape indicating it's over an input field. Typing stuff in doesn't relieve the blackness though. I've never run xcompmgr, so I might try that. Ken
Re: [NEW] OCaml oasis and Janestreet Core and Async
On 29 March 2015 at 07:41, Christopher Zimmermann wrote: > Hi, > > I just updated my OCaml ports and I think at least oasis would be good > to have in ports tree because I need it occasionaly to regenerate > broken build systems (like recently for ocaml-rss). > It is the "OCaml automake". Oasis depends on five other ports I would > need to import. OK to import the attached ports? > > Attached you find those ports: > - oasis > - ocaml-data-notation > - ocaml-expect > - ocaml-fileutils > - ocaml-mod > - ocaml-ocamlify > > > Christopher > > > > -- > http://gmerlin.de > OpenPGP: http://gmerlin.de/christopher.pub > F190 D013 8F01 AA53 E080 3F3C F17F B0A1 D44E 4FEE No objections from me. I'm off to p2k15 in a couple of days so I won't be able to test builds on non-amd64 boxes until I get back. Of course while at p2k15 I'm available to poke at/learn about ports. :-) Ken
Suddenly 4 ports spew "Error: weird mode"
The smallest one is p5-Error: ===> Building package for p5-Error-0.17023 Create /usr/ports/packages/amd64/no-arch/p5-Error-0.17023.tgz Error: weird mode for /usr/local/share/examples/p5-Error/example.pl: 440 Error: modes don't match for /usr/local/share/examples/p5-Error/example.pl Error: weird mode for /usr/local/share/examples/p5-Error/next-in-loop/Error.pm-eval.pl: 440 Error: modes don't match for /usr/local/share/examples/p5-Error/next-in-loop/Error.pm-eval.pl Error: weird mode for /usr/local/share/examples/p5-Error/next-in-loop/Error.pm-next-label.pl: 440 Error: modes don't match for /usr/local/share/examples/p5-Error/next-in-loop/Error.pm-next-label.pl Error: weird mode for /usr/local/share/examples/p5-Error/next-in-loop/Error.pm-next-out-of-catch.pl: 440 Error: modes don't match for /usr/local/share/examples/p5-Error/next-in-loop/Error.pm-next-out-of-catch.pl Error: weird mode for /usr/local/share/examples/p5-Error/next-in-loop/Error.pm-next.pl: 440 Error: modes don't match for /usr/local/share/examples/p5-Error/next-in-loop/Error.pm-next.pl Error: weird mode for /usr/local/share/examples/p5-Error/next-in-loop/README: 440 Error: modes don't match for /usr/local/share/examples/p5-Error/next-in-loop/README Error: weird mode for /usr/local/share/examples/p5-Error/warndie.pl: 440 Error: modes don't match for /usr/local/share/examples/p5-Error/warndie.pl *** Error 1 in devel/p5-Error (/usr/ports/infrastructure/mk/bsd.port.mk:1947 '/usr/ports/packages/amd64/no-arch/p5-Error-0.17023.tgz') *** Error 1 in devel/p5-Error (/usr/ports/infrastructure/mk/bsd.port.mk:2496 '_internal-package') *** Error 1 in devel/p5-Error (/usr/ports/infrastructure/mk/bsd.port.mk:2476 'package') ===> Exiting devel/p5-Error with an error /bin/sh: exit 1: not found *** Error 127 in /usr/ports (infrastructure/mk/bsd.port.subdir.mk:147 'package') Error: job failed 256 $ The others are db-4.6.21p1v0.log lynx-2.8.9p15.log qpdf-5.1.2.log Since these ports failing mean only 199 of my approx. 400 ports even attempted to build so there may very well be others further down the line. I am running dpb as root on an amd64 box dedicated to building the ports. NFS /usr/ports and /usr/ports/packages. The snap installed on the box and the ports tree are -current as of 4 hours or so ago and include the latest perl update. It last worked last week some time as far as I can tell. I've poked around but can't see any reason the modes would have changed or be handled differently over the last few days. The 'weird mode' messages seems to have existed in the pkg code for more than a year! sthen@ muttered something about umask sensitivity, but I haven't changed the umask statement in root's .profile from the installed 'umask 022'. Anybody with a cluebat to apply? Logs or any other detailed info available to interested parties on request. Ken
Re: sndio for games/eboard
Sure. But I use xboard. Never even realized there was another way. And
you say it has sound. Perhaps I'll try it out. :-).
Ken
On Sat, Jan 2, 2010 at 3:24 PM, Jacob Meuser wrote:
>
> no chess players here?
>
> On Sat, Dec 26, 2009 at 12:46:43PM +, Jacob Meuser wrote:
>>
>> --
>> jake...@sdf.lonestar.org
>> SDF Public Access UNIX System - http://sdf.lonestar.org
>>
>> Index: Makefile
>> ===
>> RCS file: /cvs/ports/games/eboard/Makefile,v
>> retrieving revision 1.36
>> diff -N -u -p Makefile
>> --- Makefile 10 Aug 2009 06:31:42 - 1.36
>> +++ Makefile 26 Dec 2009 12:46:21 -
>> @@ -3,7 +3,7 @@
>> COMMENT= gtk+2 chess board interface
>>
>> DISTNAME= eboard-1.0.4
>> -PKGNAME= ${DISTNAME}p4
>> +PKGNAME= ${DISTNAME}p5
>> CATEGORIES= games x11
>>
>> HOMEPAGE= http://www.bergo.eng.br/eboard/
>> @@ -18,7 +18,7 @@ WANTLIB= X11 Xau Xcomposite Xcursor Xdamage Xdmcp Xex
>> Xi Xinerama Xrandr Xrender atk-1.0 c cairo expat fontconfig \
>> freetype gio-2.0 glib-2.0 glitz gmodule-2.0 gobject-2.0 \
>> m pango-1.0 pangocairo-1.0 pangoft2-1.0 pixman-1 \
>> - png pthread pthread-stubs stdc++ xcb z
>> + png pthread pthread-stubs sndio stdc++ xcb z
>>
>> MASTER_SITES= ${MASTER_SITE_SOURCEFORGE:=eboard/}
>>
>> Index: patches/patch-configure
>> ===
>> RCS file: /cvs/ports/games/eboard/patches/patch-configure,v
>> retrieving revision 1.3
>> diff -N -u -p patches/patch-configure
>> --- patches/patch-configure 19 Dec 2007 09:01:25 - 1.3
>> +++ patches/patch-configure 26 Dec 2009 12:46:21 -
>> @@ -1,15 +1,17 @@
>> $OpenBSD: patch-configure,v 1.3 2007/12/19 09:01:25 fgsch Exp $
>> configure.orig Wed May 23 20:57:45 2007
>> -+++ configure Sun Dec 16 02:26:41 2007
>> -@@ -6,7 +6,7 @@ my $prefix = "/usr/local";
>> +--- configure.orig Wed May 23 11:57:45 2007
>> configure Sat Dec 26 03:23:34 2009
>> +@@ -6,8 +6,8 @@ my $prefix = "/usr/local";
>> my $package = "eboard";
>> my $version = "1.0.4";
>> my $cxx = "g++";
>> -my @cxxflags = ("-O6");
>> +-my @ldflags = ("-lpthread");
>> +my @cxxflags = ();
>> - my @ldflags = ("-lpthread");
>> ++my @ldflags = ("-pthread");
>> my @libs = ();
>> my $configh = "config.h";
>> + my $configmake = "config.make";
>> @@ -236,7 +236,7 @@ sub append_flags {
>> my $x = shift @_;
>> my @y;
>> @@ -37,7 +39,18 @@ $OpenBSD: patch-configure,v 1.3 2007/12/19 09:01:25 fg
>> } else {
>> $program = "#include <$z>\nint main() { return 0; }\n";
>> }
>> -@@ -536,7 +538,7 @@ if ($t2 != 0) {
>> +@@ -512,6 +514,10 @@ if (!header_check("stdio.h","stdlib.h","string.h","uni
>> + #optional headers
>> +
>> header_check("strings.h","sys/soundcard.h","sys/audioio.h","linux/joystick.h");
>> +
>> ++if (header_check("sndio.h")) {
>> ++ append_libs("sndio");
>> ++}
>> ++
>> + $t1=macro_check("netinet/in.h","IPPROTO_TCP","HAVE_IPPROTO_TCP_ON_IN_H");
>> + $t2=macro_check("netinet/in.h","TCP_NODELAY","HAVE_TCP_NODELAY_ON_IN_H");
>> + $t3=macro_check("netinet/in.h","SOL_TCP","HAVE_SOL_TCP_ON_IN_H");
>> +@@ -536,7 +542,7 @@ if ($t2 != 0) {
>> print "netinet/tcp.h not required, SOL_TCP present.\n";
>> }
>> } else {
>> Index: patches/patch-sound_cc
>> ===
>> RCS file: /cvs/ports/games/eboard/patches/patch-sound_cc,v
>> retrieving revision 1.6
>> diff -N -u -p patches/patch-sound_cc
>> --- patches/patch-sound_cc 3 Dec 2007 18:54:58 - 1.6
>> +++ patches/patch-sound_cc 26 Dec 2009 12:46:21 -
>> @@ -1,7 +1,7 @@
>> $OpenBSD: patch-sound_cc,v 1.6 2007/12/03 18:54:58 fgsch Exp $
>> sound.cc.orig Wed May 23 19:57:45 2007
>> -+++ sound.cc Mon Dec 3 11:58:00 2007
>> -@@ -46,6 +46,7 @@
>> +--- sound.cc.orig Wed May 23 11:57:45 2007
>> sound.cc Sat Dec 26 04:11:49 2009
>> +@@ -46,14 +46,25 @@
>> #include "eboard.h"
>>
>> #define SOME_DRIVER 1
>> @@ -9,8 +9,16 @@ $OpenBSD: patch-sound_cc,v 1.6 2007/12/03 18:54:58 fgs
>>
>> #ifdef HAVE_SYS_SOUNDCARD_H
>>
>> -@@ -54,6 +55,9 @@
>> + #define OSS_DRIVER 1
>> + #include
>>
>> ++#elif defined HAVE_SNDIO_H
>> ++
>> ++#define SNDIO_DRIVER 1
>> ++#include
>> ++#undef SOUND_DEV
>> ++#define SOUND_DEV "default"
>> ++
>> #elif defined HAVE_SYS_AUDIOIO_H
>>
>> +#undef SOUND_DEV
>> @@ -19,7 +27,7 @@ $OpenBSD: patch-sound_cc,v 1.6 2007/12/03 18:54:58 fgs
>> #define OPENBSD_DRIVER 1
>> #include
>>
>> -@@ -74,7 +78,7 @@ SoundEvent::SoundEvent() {
>> +@@ -74,7 +85,7 @@ SoundEvent::SoundEvent() {
>> Pitch=800;
>> Duration=250;
>> Count=1;
>> @@ -28,7 +36,7 @@ $OpenBSD: patch-sound_cc,v 1.6 2007/12/03 18:54:58 fgs
>> ExtraData[0]=0;
>> enabled = true;
>> }
>> -@@ -157,7 +16
Re: www/firefox35
On Thu, May 20, 2010 at 9:07 PM, J.C. Roberts wrote: > Since we have 3.6 is in www/mozilla-firefox should www/firefox35 be put > in the attic? > > -- > The OpenBSD Journal - http://www.undeadly.org > > Nope. 3.6 doesn't support Java plug-in. . Ken
Re: [update] emacs-28.2
Alas, I can't make the emacs-28.2-gtk3 I downloaded from the link jca@
provided work. :-(
If I do my normal 'emacs --daemon' from i3 I get two (?) running 'emacs
--daemon' processes and 'emacsclient -c' does not seem to do anything.
If I just do 'emacs' it flashes the startup screen briefly, goes black
and then doesn't do much else. At least I only get 1 emacs process.
No idea if there is a newer package available to test, or if there is a
library dependency that I managed to break during my
g2k22/EuroBSDCon2022 travels.
This is on an amd64 Lenovo E595.
Happy to provide any potentially useful debug info or test stuff.
Ken
Timo Myyrä writes:
> Hi,
>
> I've been testing various emacs builds, at one point I was attempting to
> enable the native-compilation so it was probably leftover from there.
>
> Timo
>
> On Fri, Sep 16, 2022, at 16:54, Jeremie Courreges-Anglas wrote:
>> On Thu, Sep 15 2022, Timo Myyrä wrote:
>>> Hmm, not sure why it removes directories.
>>> I tested by manually updating the PLIST to keep the directories. After
>>> unistalling emacs it seems to leave behind the /usr/local/share/emacs
>>> directory. It probably should remove it as it is mentioned in the
>>> PLIST?
>>
>> Regarding the directories stripped: it happens with eg the gtk3 FLAVOR,
>> probably because some dep already ships those directories.
>>
>> Here's a minimal diff. Since --without-native-compilation is the
>> default I dropped it. Was there a reason to explicitely add it?
>>
>> By popular demand, here are the no_x11 and gtk3 package flavors:
>>
>> https://russell.wxcvbn.org/pub/OpenBSD/snapshots/emacs-28.2/
>>
>> I'm not aware of users affected by the bugs fixed in this 28.2 update,
>> but it seems worthwhile to push this in 7.2. I would appreciate some
>> test reports. Also if someone could confirm that emacs-28.2 builds on
>> sparc64 (base-gcc) that would help.
>>
>> Thanks for bringing this up, Timo.
>>
>>
>> Index: Makefile
>> ===
>> RCS file: /cvs/ports/editors/emacs/Makefile,v
>> retrieving revision 1.105
>> diff -u -p -r1.105 Makefile
>> --- Makefile 19 Apr 2022 11:54:34 - 1.105
>> +++ Makefile 14 Sep 2022 22:07:19 -
>> @@ -1,6 +1,6 @@
>> COMMENT=GNU editor: extensible, customizable, self-documenting
>>
>> -VERSION=28.1
>> +VERSION=28.2
>> DISTNAME= emacs-${VERSION}
>>
>> CATEGORIES= editors
>> Index: distinfo
>> ===
>> RCS file: /cvs/ports/editors/emacs/distinfo,v
>> retrieving revision 1.16
>> diff -u -p -r1.16 distinfo
>> --- distinfo 19 Apr 2022 11:54:34 - 1.16
>> +++ distinfo 14 Sep 2022 22:07:19 -
>> @@ -1,2 +1,2 @@
>> -SHA256 (emacs-28.1.tar.xz) = KLGz0JkDegiPCkyiUdfnJi6rXqFneqv/psRCaWGtdeE=
>> -SIZE (emacs-28.1.tar.xz) = 47699512
>> +SHA256 (emacs-28.2.tar.xz) = 7iEYIjPvMjLcl7SGry2G4UBC27ZbvFNd9WLDqFgjJIg=
>> +SIZE (emacs-28.2.tar.xz) = 47722600
>> Index: patches/patch-lisp_files_el
>> ===
>> RCS file: /cvs/ports/editors/emacs/patches/patch-lisp_files_el,v
>> retrieving revision 1.7
>> diff -u -p -r1.7 patch-lisp_files_el
>> --- patches/patch-lisp_files_el 19 Apr 2022 11:54:34 - 1.7
>> +++ patches/patch-lisp_files_el 14 Sep 2022 22:07:19 -
>> @@ -3,7 +3,7 @@
>> Index: lisp/files.el
>> --- lisp/files.el.orig
>> +++ lisp/files.el
>> -@@ -2918,6 +2918,7 @@ ARC\\|ZIP\\|LZH\\|LHA\\|ZOO\\|[JEW]AR\\|XPI\\|RAR\\|CB
>> +@@ -2919,6 +2919,7 @@ ARC\\|ZIP\\|LZH\\|LHA\\|ZOO\\|[JEW]AR\\|XPI\\|RAR\\|CB
>>("\\.\\(as\\|mi\\|sm\\)2\\'" . snmpv2-mode)
>>("\\.\\(diffs?\\|patch\\|rej\\)\\'" . diff-mode)
>>("\\.\\(dif\\|pat\\)\\'" . diff-mode) ; for MS-DOS
>> Index: patches/patch-src_emacs_c
>> ===
>> RCS file: /cvs/ports/editors/emacs/patches/patch-src_emacs_c,v
>> retrieving revision 1.3
>> diff -u -p -r1.3 patch-src_emacs_c
>> --- patches/patch-src_emacs_c19 Apr 2022 11:54:34 - 1.3
>> +++ patches/patch-src_emacs_c14 Sep 2022 22:07:19 -
>> @@ -3,7 +3,7 @@ Don't use printf %n.
>> Index: src/emacs.c
>> --- src/emacs.c.orig
>> +++ src/emacs.c
>> -@@ -2742,21 +2742,13 @@ shut_down_emacs (int sig, Lisp_Object stuff)
>> +@@ -2746,21 +2746,13 @@ shut_down_emacs (int sig, Lisp_Object stuff)
>> reset_all_sys_modes ();
>> if (sig && sig != SIGTERM)
>> {
>> Index: pkg/PLIST
>> ===
>> RCS file: /cvs/ports/editors/emacs/pkg/PLIST,v
>> retrieving revision 1.28
>> diff -u -p -r1.28 PLIST
>> --- pkg/PLIST19 Apr 2022 11:54:34 - 1.28
>> +++ pkg/PLIST14 Sep 2022 22:07:19 -
>> @@ -3810,6 +3810,8 @@ share/emacs/${VERSION}/lisp/term/common-
>> share/emacs/${VERSION}/lisp/term/common-win.elc
>> share/emac
Re: [update] emacs-28.2
Nam Nguyen writes:
> Kenneth Westerback writes:
>
>> Alas, I can't make the emacs-28.2-gtk3 I downloaded from the link jca@
>> provided work. :-(
>>
>> If I do my normal 'emacs --daemon' from i3 I get two (?) running 'emacs
>> --daemon' processes and 'emacsclient -c' does not seem to do anything.
>> If I just do 'emacs' it flashes the startup screen briefly, goes black
>> and then doesn't do much else. At least I only get 1 emacs process.
>>
>> No idea if there is a newer package available to test, or if there is a
>> library dependency that I managed to break during my
>> g2k22/EuroBSDCon2022 travels.
>
> I cannot reproduce this with both building a package and jca@'s provided
> package. I see only the expected behavior with one `emacs --daemon' and
> multiple emacs clients being able to connect and see the same instance
> using multiple `emacsclient -c'.
>
> Here are some sanity checks to try:
>
> 1. make sure snapshot is updated
Just installed the amd64 snapshot I built overnight from -current and the
unfortunate behaviour of 28.2 on my E595 did not change.
>
> 2. reinstall emacs-28.1. does `emacs --daemon' and `emacsclient -c' work
>there?
Yep. Typing this in mu4e in doom emacs with 28.1, after emacs --daemon,
emacsclient -c.
>
> 3. test in a different window manager like dwm
I'll try whatever the default is (fvwm?) and see what happens.
>
> 4. use -q to ignore .emacs config
>emacs --daemon -q
>emacsclient -c
I will add that to the test queue as the espresso machine heats up.
>
> 5. maybe some alias issue? use full paths
>/usr/local/bin/{emacs,emacsclient} to be sure
No aliases defined.
>
> 6. try `emacs -q' by itself since you said even emacs flashes screen
>briefly and goes black
Will do.
>
> When I try to launch emacs --daemon multiple times it errors out the
> second time as expected.
>
>>
>> This is on an amd64 Lenovo E595.
>>
>> Happy to provide any potentially useful debug info or test stuff.
>>
>> Ken
--
Ken
Re: [update] emacs-28.2
Kenneth Westerback writes:
> Nam Nguyen writes:
>
>> Kenneth Westerback writes:
>>
>>> Alas, I can't make the emacs-28.2-gtk3 I downloaded from the link jca@
>>> provided work. :-(
>>>
>>> If I do my normal 'emacs --daemon' from i3 I get two (?) running 'emacs
>>> --daemon' processes and 'emacsclient -c' does not seem to do anything.
>>> If I just do 'emacs' it flashes the startup screen briefly, goes black
>>> and then doesn't do much else. At least I only get 1 emacs process.
>>>
>>> No idea if there is a newer package available to test, or if there is a
>>> library dependency that I managed to break during my
>>> g2k22/EuroBSDCon2022 travels.
>>
>> I cannot reproduce this with both building a package and jca@'s provided
>> package. I see only the expected behavior with one `emacs --daemon' and
>> multiple emacs clients being able to connect and see the same instance
>> using multiple `emacsclient -c'.
>>
>> Here are some sanity checks to try:
>>
>> 1. make sure snapshot is updated
>
> Just installed the amd64 snapshot I built overnight from -current and the
> unfortunate behaviour of 28.2 on my E595 did not change.
>>
>> 2. reinstall emacs-28.1. does `emacs --daemon' and `emacsclient -c' work
>>there?
>
> Yep. Typing this in mu4e in doom emacs with 28.1, after emacs --daemon,
> emacsclient -c.
>
>>
>> 3. test in a different window manager like dwm
>
> I'll try whatever the default is (fvwm?) and see what happens.
No behaviour change in fvwm. Except ... when I 'close' the black window
I get a message box pop up and say it can't find something called
'cl-seq'. Which then quickly vanishes along with the emacs window.
Reinstalling 28.1 and searching the whole disk did not disclose the
presence of anything called cl-seq.
>
>>
>> 4. use -q to ignore .emacs config
>>emacs --daemon -q
>>emacsclient -c
>
> I will add that to the test queue as the espresso machine heats up.
>
And that works!
>>
>> 5. maybe some alias issue? use full paths
>>/usr/local/bin/{emacs,emacsclient} to be sure
>
> No aliases defined.
>
>>
>> 6. try `emacs -q' by itself since you said even emacs flashes screen
>>briefly and goes black
>
'emacs -q' also works fine.
> Will do.
>
>>
>> When I try to launch emacs --daemon multiple times it errors out the
>> second time as expected.
>>
>>>
>>> This is on an amd64 Lenovo E595.
>>>
>>> Happy to provide any potentially useful debug info or test stuff.
>>>
>>> Ken
So I will go see if I can debug what part of doom is getting upset
enough to prevent 28.2 from working.
'cuz life without doom, magit and mu4e is not worth living. :-)
--
Ken
Re: [update] emacs-28.2
Kenneth Westerback writes:
> Kenneth Westerback writes:
>
>> Nam Nguyen writes:
>>
>>> Kenneth Westerback writes:
>>>
>>>> Alas, I can't make the emacs-28.2-gtk3 I downloaded from the link jca@
>>>> provided work. :-(
>>>>
>>>> If I do my normal 'emacs --daemon' from i3 I get two (?) running 'emacs
>>>> --daemon' processes and 'emacsclient -c' does not seem to do anything.
>>>> If I just do 'emacs' it flashes the startup screen briefly, goes black
>>>> and then doesn't do much else. At least I only get 1 emacs process.
>>>>
>>>> No idea if there is a newer package available to test, or if there is a
>>>> library dependency that I managed to break during my
>>>> g2k22/EuroBSDCon2022 travels.
>>>
>>> I cannot reproduce this with both building a package and jca@'s provided
>>> package. I see only the expected behavior with one `emacs --daemon' and
>>> multiple emacs clients being able to connect and see the same instance
>>> using multiple `emacsclient -c'.
>>>
>>> Here are some sanity checks to try:
>>>
>>> 1. make sure snapshot is updated
>>
>> Just installed the amd64 snapshot I built overnight from -current and the
>> unfortunate behaviour of 28.2 on my E595 did not change.
>>>
>>> 2. reinstall emacs-28.1. does `emacs --daemon' and `emacsclient -c' work
>>>there?
>>
>> Yep. Typing this in mu4e in doom emacs with 28.1, after emacs --daemon,
>> emacsclient -c.
>>
>>>
>>> 3. test in a different window manager like dwm
>>
>> I'll try whatever the default is (fvwm?) and see what happens.
>
> No behaviour change in fvwm. Except ... when I 'close' the black window
> I get a message box pop up and say it can't find something called
> 'cl-seq'. Which then quickly vanishes along with the emacs window.
>
> Reinstalling 28.1 and searching the whole disk did not disclose the
> presence of anything called cl-seq.
>
>>
>>>
>>> 4. use -q to ignore .emacs config
>>>emacs --daemon -q
>>>emacsclient -c
>>
>> I will add that to the test queue as the espresso machine heats up.
>>
>
> And that works!
>
>>>
>>> 5. maybe some alias issue? use full paths
>>>/usr/local/bin/{emacs,emacsclient} to be sure
>>
>> No aliases defined.
>>
>>>
>>> 6. try `emacs -q' by itself since you said even emacs flashes screen
>>>briefly and goes black
>>
>
> 'emacs -q' also works fine.
>
>> Will do.
>>
>>>
>>> When I try to launch emacs --daemon multiple times it errors out the
>>> second time as expected.
>>>
>>>>
>>>> This is on an amd64 Lenovo E595.
>>>>
>>>> Happy to provide any potentially useful debug info or test stuff.
>>>>
>>>> Ken
>
> So I will go see if I can debug what part of doom is getting upset
> enough to prevent 28.2 from working.
>
> 'cuz life without doom, magit and mu4e is not worth living. :-)
Aha! I somehow skipped the required recompile of doom when running a
different version of emacs! 'doom sync' recompiled all the required
packages and I type this on an apparently fully functional 28.2!
Whew.
--
Ken
Re: [update] emacs-28.2
ok krw@ fwiw. :-)
Ken
On Wed, Sept 21, 2022, 8:05 a.m. Jeremie Courreges-Anglas
wrote:
> On Wed, Sep 21 2022, Kenneth Westerback wrote:
> > Kenneth Westerback writes:
> >
> >> Kenneth Westerback writes:
> >>
> >>> Nam Nguyen writes:
> >>>
> >>>> Kenneth Westerback writes:
> >>>>
> >>>>> Alas, I can't make the emacs-28.2-gtk3 I downloaded from the link
> jca@
> >>>>> provided work. :-(
> >>>>>
> >>>>> If I do my normal 'emacs --daemon' from i3 I get two (?) running
> 'emacs
> >>>>> --daemon' processes and 'emacsclient -c' does not seem to do
> anything.
> >>>>> If I just do 'emacs' it flashes the startup screen briefly, goes
> black
> >>>>> and then doesn't do much else. At least I only get 1 emacs process.
> >>>>>
> >>>>> No idea if there is a newer package available to test, or if there
> is a
> >>>>> library dependency that I managed to break during my
> >>>>> g2k22/EuroBSDCon2022 travels.
> >>>>
> >>>> I cannot reproduce this with both building a package and jca@'s
> provided
> >>>> package. I see only the expected behavior with one `emacs --daemon'
> and
> >>>> multiple emacs clients being able to connect and see the same instance
> >>>> using multiple `emacsclient -c'.
> >>>>
> >>>> Here are some sanity checks to try:
> >>>>
> >>>> 1. make sure snapshot is updated
> >>>
> >>> Just installed the amd64 snapshot I built overnight from -current and
> the
> >>> unfortunate behaviour of 28.2 on my E595 did not change.
> >>>>
> >>>> 2. reinstall emacs-28.1. does `emacs --daemon' and `emacsclient -c'
> work
> >>>>there?
> >>>
> >>> Yep. Typing this in mu4e in doom emacs with 28.1, after emacs --daemon,
> >>> emacsclient -c.
> >>>
> >>>>
> >>>> 3. test in a different window manager like dwm
> >>>
> >>> I'll try whatever the default is (fvwm?) and see what happens.
> >>
> >> No behaviour change in fvwm. Except ... when I 'close' the black window
> >> I get a message box pop up and say it can't find something called
> >> 'cl-seq'. Which then quickly vanishes along with the emacs window.
> >>
> >> Reinstalling 28.1 and searching the whole disk did not disclose the
> >> presence of anything called cl-seq.
> >>
> >>>
> >>>>
> >>>> 4. use -q to ignore .emacs config
> >>>>emacs --daemon -q
> >>>>emacsclient -c
> >>>
> >>> I will add that to the test queue as the espresso machine heats up.
> >>>
> >>
> >> And that works!
> >>
> >>>>
> >>>> 5. maybe some alias issue? use full paths
> >>>>/usr/local/bin/{emacs,emacsclient} to be sure
> >>>
> >>> No aliases defined.
> >>>
> >>>>
> >>>> 6. try `emacs -q' by itself since you said even emacs flashes screen
> >>>>briefly and goes black
> >>>
> >>
> >> 'emacs -q' also works fine.
> >>
> >>> Will do.
> >>>
> >>>>
> >>>> When I try to launch emacs --daemon multiple times it errors out the
> >>>> second time as expected.
> >>>>
> >>>>>
> >>>>> This is on an amd64 Lenovo E595.
> >>>>>
> >>>>> Happy to provide any potentially useful debug info or test stuff.
> >>>>>
> >>>>> Ken
> >>
> >> So I will go see if I can debug what part of doom is getting upset
> >> enough to prevent 28.2 from working.
> >>
> >> 'cuz life without doom, magit and mu4e is not worth living. :-)
> >
> > Aha! I somehow skipped the required recompile of doom when running a
> > different version of emacs! 'doom sync' recompiled all the required
> > packages and I type this on an apparently fully functional 28.2!
>
> Thanks for pinpointing this. emacs -q/-Q is the most useful tool to
> debug an emacs problem.
>
> Since I have received no negative (nor positive...) feedback except
> yours, I'm tempted to go ahead and commit this update.
>
> --
> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
>
