Re: [update] pwm-20060517

Hi Pedro, On 7/18/06, Pedro Martelletto [EMAIL PROTECTED] wrote: I wonder if we should still keep the PWM port now that Ion has incorporated all of its functionalities, builds and installs a PWM binary, and is officially considered its successor? I think it still makes sense for people that

Re: Invalid spec hugs98-Mar2005

On Sat, Jan 3, 2009 at 4:33 AM, Matthias Kilian k...@outback.escape.de wrote: On Sat, Jan 03, 2009 at 11:41:07AM +0100, Matthias Kilian wrote: Running the equivalent of pkg_add -r hugs98-2006.09 Invalid spec hugs98-Mar2005 at /usr/libdata/perl5/OpenBSD/PkgSpec.pm line 153. Looks like I

ghci dumping core on 4.5-amd64

It seems like we lost ghci somewhere on the way from 4.4 to 4.5. % ghci ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.6.1, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help.

Re: ghci dumping core on 4.5-amd64

On Tue, May 5, 2009 at 9:00 AM, Greg Steuck g...@nest.cx wrote: It seems like we lost ghci somewhere on the way from 4.4 to 4.5. % ghci   ___         ___ _  / _ \ /\  /\/ __(_)  / /_\// /_/ / /  | |      GHC Interactive, version 6.6.1, for Haskell 98. / /_\\/ __  / /___| |      http

xmonad problem (libHSffi missing from GHC)

Hi Matthias, Thanks for keeping Haskell going on OpenBSD! I installed xmonad package on 5.5/amd64 and tried to start with the most trivial config: % xmonad --recompile Error detected while loading xmonad configuration file: /home/greg/.xmonad/xmonad.hs /usr/bin/ld: cannot find -lHSffi collect2:

Re: xmonad problem (libHSffi missing from GHC)

Do you have any werid leftovers in your ~/.ghc and/or ~/.cabal directories? While our hs-ports always ensure to use only the globally installed hs libraries (i.e. in ${LOCALBASE}/lib/ghc), xmonad may also pull in user-installed libraries. It wasn't in my local directory, but I did have weird

OpenBSD 5.9: chrome(PID) in free(): error: use after free

Out of the blue after 5.9 upgrade I've started getting chromium reporting use-after-free. I do not seem to be the only person with this problem http://www.bsdforen.de/threads/chromium-st%C3%BCrzt-mit-dem-fehler-chrome-in-free-ab.32523/ I suspect both of us have some bizarre left over state on our

Re: OpenBSD 5.9: chrome(PID) in free(): error: use after free

Good call! It's ATI Radeon Mobility HD 5470. I also tried to run chrome via an ssh session which should supposedly get rid of any direct graphics card optimizations (DRM?). Still the same failure. Furthermore, I tried to point chrome at an Xvfb and the problem was still the same. This suggests

xmonad-lib install failure on 6.0 amd64

I got to installing 6.0 today and noticed there's a mismatch between the xmonad package and the ghc version of unix-2.7. I am getting this failure: # echo $PKG_PATH http://mirrors.syringanetworks.net/pub/OpenBSD/6.0/packages/amd64/ # pkg_add xmonad-lib quirks-2.241 signed on 2016-07-26T16:56:10Z

Re: Hiding BSD_VISIBLE macros

On Sun, Apr 23, 2017 at 12:07 AM Greg Steuck <g...@nest.cx> wrote: > I found some references to BSD_SOURCE and POSIX_C_SOURCE as being related, > but I don't see a cookie-cutter recipe to borrow, so I thought I should ask. > Adding CXXFLAGS="-D_POSIX_SOURCE" to CONFIGU

Re: Hiding BSD_VISIBLE macros

Thanks for all suggestions. On Sun, Apr 23, 2017 at 12:52 PM Stuart Henderson <s...@spacehopper.org> wrote: > On 2017/04/23 21:18, Jeremie Courreges-Anglas wrote: > > Greg Steuck <g...@nest.cx> writes: > > > > > On Sun, Apr 23, 2017 at 12:07 AM Greg Steuck

devel/protobuf 3.2.0 progress (SEGV in tests)

Thanks to the help of jca@ and sthen@ I got to a point where the port builds nicely on amd64 6.1 (I know the ports tree is tracking -current). The patch is here: https://github.com/openbsd/ports/compare/master...blackgnezdo:proto3?expand=1 Now some tests are failing. % make test ... FAIL:

Hiding BSD_VISIBLE macros

Hello, In my effort to upgrade devel/protobuf to 3.2.0 I ran into an interesting snag. The build process creates a code-generated file which happens to have a line like this: ::google::protobuf::int32 major() const; as part of its src/google/protobuf/compiler/plugin.pb.h This would normally be

Enable built-in tests of devel/gtest

The tests now pass for me on amd64 with make test: 100% tests passed, 0 tests failed out of 41 devel-gtest-enable-tests.patch.gz Description: application/gzip

Repair devel/protobuf tests

Looks like the upgrade to gtest-1.8 left devel/protobuf test-deficient. I didn't find a good way to disable currently incompatible death tests, hence the rash of patches. History here on github . The

devel/{gtest,protobuf} maintainer

I realized I forgot to mention. I contacted Vincent separately and he's no longer interested in maintaining these ports. Hence my going directly to the mailing list with the patches. Thanks Greg

Re: devel/{gtest,protobuf} maintainer

On Wed, May 17, 2017 at 1:27 PM Stuart Henderson <s...@spacehopper.org> wrote: > On 2017/05/17 16:22, Greg Steuck wrote: > > I realized I forgot to mention. I contacted Vincent separately and he's > no > > longer interested in maintaining these ports. Hence my going dir

devel/protobuf -> 3.3.1 (help needed)

Hello, I've spent some time trying to get this upgrade into shape on 6.1-amd64 but the tests prove resistant to my efforts. The patch is attached. The first error I fixed was due to the one-definition-rule violation where devel/gtest port is being compiled with a command line define which is not

devel/shellcheck update for ghc 8.6.4

In my quest to update the ports [tree] to ghc 8.6.4 I arrived at a fork re ShellCheck. The first blocker is ANN/TemplateHaskell is [broken] enough that patching is required to get rid of all ShellCheck testing code. Now, the next snag is the ancient version of ShellCheck in ports. At least a

Re: portgen.hs

On Mon, Jun 3, 2019 at 8:39 PM Andrew Hewus Fresh wrote: > What's most important though is knowing what a Haskell port's Makefile > should look like. We also need an API that we can use to query for the > distfile name[1] and a way to figure out the dependencies, preferably > via some sort of

portgen.hs

I noticed the undeadly [story] about Python joining the cool kids generating their ports with portgen(1). Superficially the language specific packages in OpenBSD::PortGen::Port appear short enough to contemplate adding support for Haskell. Should I try reviving my 15 year old Perl skillz or is the

ANN module crashes ghc 8.6.4 with a bus error on OpenBSD

I'm in the process of upgrading to GHC 8.6.4 on OpenBSD-6.5-amd64-stable ( https://github.com/blackgnezdo/ports/commits/ghc_864_may26) I hit a bus error when porting fgl, but then reduced the problem to a trivially reproducible one below. I've also stored a log from -v9 run in

lang/ghc 8.6.4

I've updated a couple dozen more ports after having slacked for 2 months: https://github.com/blackgnezdo/ports/commits/ghc_864_may26 I'm attaching a jumbo patch against ports-current. I confess to not following the proper protocol and building stuff on 6.5. I'm also probably making tons of other

Re: lang/ghc 8.6.4

Mass import averted. It's easy enough to patch up the old version of hs-dbus. hs-dbus.patch.gz Description: application/gzip

Haskell ports: cabal v2-build?

While looking at Haskell binary ports, a couple of approaches seem possible. 1) Embed Haskell libraries into ports, build binaries from them. 2) Build binaries with `cabal new-build` The status quo is #1. This has a few benefits: it exists, libraries are reused by multiple ports reducing build

Re: devel/shellcheck update for ghc 8.6.4

On Mon, Jun 3, 2019 at 11:03 AM Caspar Schutijser wrote: > On Sun, Jun 02, 2019 at 03:06:28PM -0700, Greg Steuck wrote: > > In my quest to update the ports [tree] to ghc 8.6.4 I arrived at a fork > re > > ShellCheck. > > > > The first blocker is ANN/Temp

ghc 8.6.4 update as of Sep 1

Things always take longer than anticipated. I need another check for my progress before making one more pass through Haskell ports. I built and ran everything up to xmonad, darcs, xmobar, ShellCheck. This required a few new ports and updates to all the existing ones up to these binaries. The

Re: switch lang/ghc to @define-tag/@tag

Hi Matthias and Marc, On Fri, 2019-08-23 23:31:20 Marc Espie wrote: >> I'm not sure about wether it's worth to try to avoid the collisions (I'd >> prefer to just add a small note to the upgrade FAQ), nor am I shure >> wether I should commit this change (to ghc and *all* hs-ports) now or >> after

lang/ghc leaves package.cache.lock behind

Hi Matthias, There seems to be a minor nit with lang/ghc uninstall: $ doas env PKG_PATH= https://cdn.openbsd.org/pub/OpenBSD/snapshots/packages/amd64/ pkg_add ghc quirks-3.180 signed on 2019-09-19T12:12:14Z ghc-8.2.2p5: ok Running tags: ok $ doas pkg_delete ghc ghc-8.2.2p5: ok Running tags: ok

ghc 8.6.4 upgrade Sep 15

Hi Matthias, I feel pretty good about the state of https://github.com/blackgnezdo/ports/tree/ghc_864_sep15 on 6.6-beta amd64 as of Sep 15. All the packages transitively depending on lang/ghc build and install in a proot of a clean machine. I confirmed I can run darcs, xmonad, hedgewars,

ghc vs gmp

Hi Matthias, On Mon, Sep 23, 2019 at 2:40 PM Matthias Kilian wrote: > Instead of adding more madness (like a patch to diff in this case), > I compared the bundled gmp sources against the upstream used by > devel/gmp (which are identical except for the remoced coeumentation > in ghc's version)

Re: [NEW] security/py-fido2

I installed a few ports to get all the way to /usr/local/bin/ykman and tried to run it on amd64-current-ish. It appears the py-fido2 port needs a bit more work. There is some OS sniffing code which seems to be missing any support for openbsd. The closest that I see freebsd.py.

Re: [NEW] security/libfido2

> My PRs have all been merged, so here's an updated port that uses > the Yubico upstream instead of my fork. This port works for me. I successfully ssh-d into my localhost with a newly enrolled key: Nov 3 09:13:57 hippy sshd[18160]: Accepted publickey for greg from 127.0.0.1 port 4508 ssh2:

Re: [NEW] security/py-fido2

On Sun, Nov 3, 2019 at 6:10 AM Lucas Raab wrote: > > Lucas, have you tried using ykman? > > I have, using Python 3. The other dependencies/ports (py-fido2 and > pyscard) that I submitted are now Python 3 only as well due to pcsclite > now being a Python 3-only package. Unfortunately I'm still

Missing comma in devel/hs-constraints

One-liner patch. Surprisingly this hasn't been caught so far. -- nest.cx is Gmail hosted, use PGP: https://pgp.key-server.io/0x0B1542BD8DF5A1B0 Fingerprint: 5E2B 2D0E 1E03 2046 BEC3 4D50 0B15 42BD 8DF5 A1B0 diff --git a/devel/hs-constraints/Makefile b/devel/hs-constraints/Makefile index

Common .cabal file handling in hs-ports

Hi Matthias, I noticed we have a few bound relaxation patches that approximate the cabal behavior of downloading revised package files from hackage. I propose we build a tiny bit more common mechanism into ghc.mk that would copy files/*.cabal files if they exist over into $WRKDIST. Then we can

Re: HS_ENCODING in localeEncoding

C3 4D50 0B15 42BD 8DF5 A1B0 From f48a1ee1ee02e4b6b6557a0ec2709cb8625b95d0 Mon Sep 17 00:00:00 2001 From: Greg Steuck Date: Tue, 4 Feb 2020 07:55:05 -0800 Subject: [PATCH] Remove HS_ENCODING. LC_ALL works now. --- lang/ghc/Makefile | 15

Re: HS_ENCODING in localeEncoding

Hi Ingo, On Mon, Feb 3, 2020 at 6:31 AM Ingo Schwarze wrote: > The function locale_charset() appears to be part of the converters/libiconv > package, but it appears to be totally undocumented. I failed to > find any documentation whatsoever: neither in the package nor even > with Google on the

Re: [update] devel/protobuf-3.11.3

> Simple bump to keep tracking the latest release. Apart from the version > number bump, the only change to the compiled source is wrapped in > #ifdef _MSC_VER, and there are some minor changes to the build > infrastructure, so no real change at all. Looks good to me. -- nest.cx is Gmail hosted,

New port: JetBrainsMono fonts

I tested this with emacs and xterm on amd64-current. Add JetBrainsMono fonts port --- fonts/Makefile | 1 + fonts/jetbrains-mono/Makefile | 28 fonts/jetbrains-mono/distinfo | 2 ++ fonts/jetbrains-mono/pkg/DESCR | 8

Re: New port: JetBrainsMono fonts

Thanks for the comments Stuart & George. I believe I addressed all your comments. I further stole from espie@'s port which simplified things a bit more. jetbrains-mono.tgz Description: application/compressed-tar

Re: HS_ENCODING in localeEncoding

On Tue, Feb 4, 2020 at 10:38 AM Greg Steuck wrote: > So far I confirmed that: > * getLocaleEncoding is correctly steered by LC_ALL > * utf8 characters are accepted by ghci and correctly parsed into > String literals > * utf8 characters are printed back correctly > * utf8

Re: New port: JetBrainsMono fonts

On Sun, Feb 2, 2020 at 8:55 PM George Koehler wrote: > Some programs (like emacs and xfce4-terminal) don't show these Superficial searches indicate emacs (at least version 27) can be taught to render ligatures. > ligatures, but some (like firefox-esr and libreoffice) do. I saw a > glitch in

HS_ENCODING in localeEncoding

Hi Matthias, Do you believe lang/ghc/patches/patch-libraries_base_cbits_PrelIOUtils_c is still relevant? I ran some test programs and both locale_charset() and nl_langinfo(CODESET) yield sensible results (at least for UTF8). The history of the patch seems to go back approximately 10 years, so

Re: Common .cabal file handling in hs-ports

Hi Matthias, On Sun, Feb 23, 2020 at 11:50 AM Matthias Kilian wrote: > I don't understand the benefit of complete copies of .cabal files > over patches. I was hoping to get some automation around it, but maybe the change should wait until such automation materializes. > IMHO, the annoying part

Re: UPDATE: www/mozilla-firefox U2F/FIDO support - using fido(4)

FWIW, the same patch works find with firefox upgraded to 72.0.1 in ports as of today. I built it from this tree: https://github.com/blackgnezdo/ports/tree/firefox-fido-2020-01-10 Thanks Greg

[PATCH] net/libsignal-protocol-c to use upstream commit

I'm looking for feedback about the trade-offs of such changes. I tested the upgrade, but not sure if it's valid: % make install SUDO=doas ===> libsignal-protocol-c-2.3.2pl1 depends on: protobuf-c-* -> protobuf-c-1.3.2 ===> Verifying specs: m ===> found m.10.1 ===> Installing

Chromium U2F auth vs libfido2

Hello and Happy New Year! I'm fixing a Chromium bug [1] in OpenBSD port and am trying to use libfido2. Unfortunately there's an abstraction mismatch between what Chromium expects and libfido2 provides. Chromium needs (and libfido2 approximations): 1) discover a device (fido_dev_info_manifest,

Re: UPDATE: www/mozilla-firefox U2F/FIDO support - using fido(4)

> This updated version has some changes: > 1. It uses the new fido(4) driver in OpenBSD-current instead of uhid(4). I confirmed this works great (registration and authentication) with these two devices across github and google: The original gnubby: uhidev0 at uhub0 port 2 configuration 1

[PATCH] Support U2F/FIDO in www/chromium.

Fixes: https://bugs.chromium.org/p/chromium/issues/detail?id=451248 Uses /dev/fido via libfido2 bundled with the system. Due to an abstraction level mismatch only the discovery phase is done via libfido2. The port was verified to work with demo.yubico.com, google.com, github.com on amd64

lang/ghc fixups

-- nest.cx is Gmail hosted, use PGP: https://pgp.key-server.io/0x0B1542BD8DF5A1B0 Fingerprint: 5E2B 2D0E 1E03 2046 BEC3 4D50 0B15 42BD 8DF5 A1B0 From 5af03d55127188f0427f23781b08559e489d6ab8 Mon Sep 17 00:00:00 2001 From: Greg Steuck Date: Sun, 8 Mar 2020 17:08:16 -0700 Subject: [PATCH 1/2

[PATCH] Add /dev/fido unveil to enable FIDO support in firefox

All reyk@'s changes are now merged upstream so this is the only patch that remains. Tested post-install by adding the same line to /usr/local/lib/firefox/browser/defaults/preferences/unveil.main --- www/mozilla-firefox/Makefile | 1 + www/mozilla-firefox/files/unveil.main | 1 + 2 files

Re: update print/poppler (annoying as always)

Hi Matthias, > #0 build_goto_dest (document=, action=, link=0x0) at \ > /home/ports/pobj/p2/poppler-0.86.1/poppler-0.86.1/glib/poppler-action.cc:348 348 \ > if (! link->isOk ()) { [Current thread is 1 (process 435846)] > (gdb) print link > $1 = (const LinkGoTo *) 0x0 > (gdb) up > #1

lang/ghc: Use py3 sphinx, sync PLIST

Hi Matthias, I'm not positive that I got py3 stuff exactly right, but at least configure goes through fine unlike what happened before: https://github.com/blackgnezdo/ports/issues/6 Thanks Greg -- nest.cx is Gmail hosted, use PGP: https://pgp.key-server.io/0x0B1542BD8DF5A1B0 Fingerprint: 5E2B

Update lang/ghc: Remove -no-pie from GHC_CC_OPTS

2D0E 1E03 2046 BEC3 4D50 0B15 42BD 8DF5 A1B0 From ce549a87690a9308af788ea08d3148a6442e3ec7 Mon Sep 17 00:00:00 2001 From: Greg Steuck Date: Sun, 5 Apr 2020 14:56:42 -0700 Subject: [PATCH 2/2] Remove -no-pie from GHC_CC_OPTS. --- lang/ghc/Makefile | 3 +-- 1 file changed, 1 insertion(+), 2

Update net/libsignal-protocol-c 2.3.2->3

On Mon, Jan 13, 2020 at 9:29 AM Alex Holst wrote: > > I'm looking for feedback about the trade-offs of such changes. > Hi. This seems like needless churn to me. Upstream should be nudged to > do a new release instead. > Done. The local patches got rolled in. Library version bump seems

GHC 8.10 progress

Hi Matthias, I got lang/ghc 8.10.1 packaged but nothing else is done: https://github.com/blackgnezdo/ports/commits/ghc810 The main outstanding issue is we need a threaded rts library in the bootstrap package: https://github.com/blackgnezdo/ports/issues/5 I can run some basic operations with

[PATCH] Update devel/happy to 1.19.10 (after ports unlock)

-server.io/0x0B1542BD8DF5A1B0 Fingerprint: 5E2B 2D0E 1E03 2046 BEC3 4D50 0B15 42BD 8DF5 A1B0 From 26975ed71595927224477356dfbf9433c9c72be2 Mon Sep 17 00:00:00 2001 From: Greg Steuck Date: Sat, 9 May 2020 17:13:20 -0700 Subject: [PATCH] Update devel/happy to 1.19.10 This the lowest version required by GHC

[PATCH] lang/ghc cleanup (after ports unfreeze)

dd5d488f4064fc76ac41d5b08725177afab21769 Mon Sep 17 00:00:00 2001 From: Greg Steuck Date: Sun, 5 Apr 2020 14:56:42 -0700 Subject: [PATCH] lang/ghc cleanup Remove -no-pie from GHC_CC_OPTS. Nothing breaks for 8.6.4 and ghc 8.10.1 port starts working. Remove ffi related patch: since we use system libffi

Autoconf question

Hello, We [workaround] an upstream [bug] in x11/hs-X11. A proper fix would be to add an exrta-lib-dirs line to [X11.buildinfo.in] that sets the directory where X libs live (/usr/X11R6/lib). The directory is already included as ld-options: @LDFLAGS@, except it ends up as -L/usr/X11R6/lib and is

ghc 8.10.2 won't build haddock on i386

Looks like we can't easily generate haddock on i386 with ghc 8.10.2. It simply wants more RAM than the platform permits. The highest ulimit -d is 3145728. Even then I get: haddock: out of memory (requested 1048576 bytes) gmake[1]: *** [compiler/ghc.mk:310:

Re: [update] protobuf 3.13.0

Theo Buehler writes: > I built this on amd64, macppc and sparc64 and did the usual > interoperability tests with mosh between versions and architectures. > I built the consumers below net/ (except ktorrent) and a handful of > others, no issues encountered. All three shared libs remove and add >

lang/fpc and downstream

Hi Pascal, I noticed lang/fpc has been broken for some time. This transitively breaks devel/lazarus and games/hedgewars. I'm working on converting Haskell packages and hedgewars is one of them. I'd prefer to not leave hedgewars extra broken. At the same time, I can't adapt a broken port. This

Re: ghc 8.10.2 won't build haddock on i386

Hi Matthias, Matthias Kilian writes: >> Should I split the port into multi-package and limit -haddock to amd64? > > Would it be an option to just don't generate the GHC docs on i386 > but still build a single package (including the haddock binary)? HADDOCK_DOCS=NO seems to case the haddock

Re: lang/fpc and downstream

Greg Steuck writes: > Hi Pascal, > > I noticed lang/fpc has been broken for some time. This transitively > breaks devel/lazarus and games/hedgewars. I'm working on converting > Haskell packages and hedgewars is one of them. I'd prefer to not leave > hedgewars extra broken. A

Re: Future update: devel/shellcheck 0.7.1

Greg Steuck writes: > I'm giving i386 builds a go in a vmm to see how well that fares. I got all the packages I ported to package successfully having finished ghc-hackage subpackage split. I'm not attached to subpackages going forward, simply reporting that it was enough to verify i386. Tha

Re: [MAINTAINER UPGRADE] editors/kakoune 2020-09-01

Frédéric GALUSIK writes: > Attached a diff to upgrade kakoune to 2020-09-01. > > This is mostly a bugfix release. > * Daemon mode (-d switch) does not fork anymore. > * Fix crash on completion. > > OK ? Builds for me on amd64. OK gnezdo > Cheers. > > fredg > > diff -rupN kakoune.o/Makefile

Re: Review for cabal.port.mk

Marc Espie writes: > I would prefer that you would reconstitute DISTNAME from MODCABAL variables > exactly like stuff is done for github. Does the diff below look like what you had in mind? I like it as the data becomes more structured (parsing is almost never the best choice). I can imagine

Re: Review for cabal.port.mk

Sebastien Marie writes: > On Sun, Oct 04, 2020 at 09:56:22AM +0200, Marc Espie wrote: >> I'll have to look more closely, but I have a few concerns. >> >> On Sat, Oct 03, 2020 at 11:03:43PM -0700, Greg Steuck wrote: >> > MASTER_SITES0 =https://hackage.

Re: Review for cabal.port.mk

Thanks for the prompt review! Marc Espie writes: > I'll have to look more closely, but I have a few concerns. > > On Sat, Oct 03, 2020 at 11:03:43PM -0700, Greg Steuck wrote: >> MASTER_SITES0 = https://hackage.haskell.org/package/ > That's a minor one. >

Re: Review for cabal.port.mk

Greg Steuck writes: > Marc Espie writes: > >> I would prefer that you would reconstitute DISTNAME from MODCABAL variables >> exactly like stuff is done for github. > > Does the diff below look like what you had in mind? I like it as the > data becomes more structur

update-plist not picking the longest replacement

I am running with my cabal.port.mk[1] patches which include this SUBST_VARS += DISTNAME MODCABAL_STEM MODCABAL_VERSION PKGNAME I try to regenerate x11/xmonad/pkg/PLIST[2] with `make update-plist` and the result comes out with ${MODCABAL_STEM}-${MODCABAL_VERSION} contrary to my

Re: lang/ghc, some failure on i386

Matthias Kilian writes: >> I guess it will probably build on a retry, but I just ran into this: > [...] >> "utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" register >> libraries/parsec dist-install >> "/pobj/ghc-8.6.4/bootstrap/lib/ghc/bin/ghc" >>

Re: [update] games/xcowsay to 1.5.1

Charlene Wendling writes: > Hi, > > Here is an update for xcowsay to 1.5.1, this fixes various issues > related to (non) compositing display [0], and add flag detection > for C99. > > Port-wise, i've removed the explicit CFLAGS (it picks C99 flags with > CC=gcc), and added a patch, that i've

gnupg: avoid printf %n in build process

I tried to get this upstreamed in https://dev.gnupg.org/T5104 to no avail. If people find it useful to not see %n related complaints during the build, the patch below would do it. If desirable, OK? Thanks Greg >From 8afc030e5e22cdcde94437a8b2056ab4c6f16061 Mon Sep 17 00:00:00 2001 From: G

update-plist and dups (Re: update-plist not picking the longest replacement)

Greg Steuck writes: > I am running with my cabal.port.mk[1] patches which include this > SUBST_VARS += DISTNAME MODCABAL_STEM MODCABAL_VERSION PKGNAME > > I try to regenerate x11/xmonad/pkg/PLIST[2] with `make update-plist` and > the result comes out with

Re: gnupg: avoid printf %n in build process

gh. I developed the patch outside of ports and ./configure used /usr/bin/gcc by default. Compiling the port surfaces the problem as you reported... along with 10 other warnings drowning the important piece. Thanks Greg >From 50687a42962b7eeca3568b2203ec688a75d28dff Mon Sep 17 00:00:00 2001 From:

MODCABAL_MANIFEST generator port

Hi Matthias, This is the next installment in my quest to make Hackage Haskell executables trivial to add to ports. I added a new --openbsd mode to cabal-bundler program in cabal-extras[1]. I also added a port of this program to my ever growing stack of patches[2] (hacky as there's no formal

Re: chromium: Check failed: . : Too many open files

Greg Steuck writes: > On Tue, Aug 18, 2020 at 10:50 PM Robert Nagy wrote: > > What is your fd limit? Please monitor fstat and see which process goes out > of whack with file descriptor usage. > > Presumably we verify that the minimal viable value of 400 is available, I h

Re: Hacking cabal v2-build stuff together

Greg Steuck writes: >> I took this a bit further and I get a working devel/happy package now. >> >> This is still a complete WIP but I wanted to get some early feedback on >> the implementation choices as this is my first foray into port-modules. > > Converting devel

Re: Future update: devel/shellcheck 0.7.1

Hi Caspar, Caspar Schutijser writes: >> Just wanted to share where things are going with Haskell ports on >> OpenBSD. >> >> ShellCheck 0.7.1 was not hard to convert though already unpleasant to do >> by hand. The key learning here is that with a tiny bit of elbow grease a >> new port can use

chromium: Check failed: . : Too many open files

I've had chromium dump core on me a few times recently (it had run reliably for a long time before). I'm on a Aug 5 amd64-current and have chromium-84.0.4147.105p2. My .xsession-errors contains these lines: [8234:607566400:0817/213026.408392:ERROR:platform_shared_memory_region_posix.cc(250)]

Re: chromium: Check failed: . : Too many open files

On Tue, Aug 18, 2020 at 10:50 PM Robert Nagy wrote: > What is your fd limit? Please monitor fstat and see which process goes out > of whack with file descriptor usage. > Presumably we verify that the minimal viable value of 400 is available, I have % ulimit -Sn 512 I'll keep an eye on fstat

Re: Hacking cabal v2-build stuff together

patches. I'll have to figure out if there's a way to go back to ghc-8.6 and cabal-2.4. Thanks Greg >From 44e3d9a1b52ffd5ef6ff327d929fe22977c77082 Mon Sep 17 00:00:00 2001 From: Greg Steuck Date: Thu, 20 Aug 2020 11:54:08 -0700 Subject: [PATCH] Build devel/happy with cabal v2-install Passes `m

Re: Hacking cabal v2-build stuff together

Greg Steuck writes: > I took this a bit further and I get a working devel/happy package now. > > This is still a complete WIP but I wanted to get some early feedback on > the implementation choices as this is my first foray into port-modules. Converting devel/alex is straightf

Re: chromium: Check failed: . : Too many open files

Stuart Henderson writes: >> (gdb) x/36wx $rsp >> 0xf1ccd9823c0: 0xbedead01 0x3332385b 0x392d3a34 0x37353038 >> 0xf1ccd9823d0: 0x30343238 0x3138303a 0x31322f37 0x36323033 >> 0xf1ccd9823e0: 0x3537342e 0x3a393332 0x41544146 0x6c703a4c >>

Hacking cabal v2-build stuff together

Hey Matthias, Hope your summer is going well. I got devel/happy to build with cabal v2-build but the lack of datadir is a show stopper (asking Gleb for pointers). Still if you wanna take a look I pushed the current state of my ports tree to:

Future update: devel/shellcheck 0.7.1

experience than the previous transitive update ripples. Thanks Greg P.S. This can't be easily submitted, too much prior hacky stuff preceeds this patch: https://github.com/blackgnezdo/ports/commits/ghc810 >From 7183d458a71393a3ad3ed98670cdf1fcd0681da6 Mon Sep 17 00:00:00 2001 From: Greg Ste

Cabal-based Haskell ports module

Hey Matthias, I've been working on this for a while. There's a fairly solid story for replacing all Haskell binary ports. I also added a few more ports that previously looked daunting (e.g. pandoc). All the hs-library ports will be going away. So does the brittle dependency tracking that

Re: Include libHSrts_thr.a into lang/ghc bootstrap

Matthias Kilian writes: > On Mon, Sep 21, 2020 at 04:33:38PM +0200, Matthias Kilian wrote: >> I'll now check wether 8.6.4 still builds with the new bootstrapper. > > It does, including all ports depending on lang/ghc, on both amd64 > and i386. New bootstrap also works great for ghc-8.10.2. Thank

Re: Include libHSrts_thr.a into lang/ghc bootstrap

On Mon, Sep 21, 2020 at 2:03 PM Matthias Kilian wrote: > On Mon, Sep 21, 2020 at 04:33:38PM +0200, Matthias Kilian wrote: > > I'll now check wether 8.6.4 still builds with the new bootstrapper. > > It does, including all ports depending on lang/ghc, on both amd64 > and i386. > Very cool, thanks

Review for cabal.port.mk

This is a follow up to my previous email "Cabal-based Haskell ports module". I cleaned this up pretty good for my taste. All haskell program packages (and then some) work well in this framework. The full context is published in https://github.com/blackgnezdo/ports/commits/ghc810 This file is the

Transitive hs-ports updates

events. Thanks Greg -- nest.cx is Gmail hosted, use PGP: https://pgp.key-server.io/0x0B1542BD8DF5A1B0 Fingerprint: 5E2B 2D0E 1E03 2046 BEC3 4D50 0B15 42BD 8DF5 A1B0 From 9ab295509a5cfa4d7d6b29c1a7030320c7b1d063 Mon Sep 17 00:00:00 2001 From: Greg Steuck Date: Sat, 16 May 2020 20:51:18 -0700

Re: Transitive hs-ports updates

On Mon, May 25, 2020 at 2:52 PM Matthias Kilian wrote: > > I know why GHC behaves this way, but this property turns minor updates > > into major events. > > Should we do an experiment and try to get rid of MODGHC_PACKAGE_KEY? I expect we'd trade an obvious and quick failure for a delayed and

OK to GC net/hpodder?

The upstream has ceased hpodder development over 8 years ago. The port has to be updated every time GHC is released and for all other infrastructure changes. Even though we have enough patches for the code to compile with GHC 8.10, there needs to be somebody who runs this package to test it. Hence

Re: lang/ghc: more cleanups

On Fri, May 29, 2020 at 5:22 PM Matthias Kilian wrote: > this is mainly for getting rid of overriding things via CONFIGURE_ENV > and CFLAGS in favor of patching aclocal.m4 and configure.ac (and > running autoconf), which may help getting this merged upstream. > > It also kills some left-over

Re: OK to GC net/hpodder?

> Can we remove net/hpodder? > We'd also be free to remove at least these libraries solely required by hpodder: sqlite> select fullpkgpath from ports where build_depends like '%hs-HaXml%'; net/hpodder sqlite> select fullpkgpath from ports where build_depends like '%hs-HDBC-sqlite3%'; net/hpodder

Include libHSrts_thr.a into lang/ghc bootstrap

Hi Matthias, In my attempts to port ghc 8.10.2 I didn't figure out how to avoid requiring threaded rts for ghc bootstrap. I propose we change the bootstrap ghc 8.6.4 to include libHSrts_thr.a. So far I confirmed that applying the patch below makes libHSrts_thr.a appear in the generated *xz file

Planning ghc-8.10.2 and cabal.port.mk switch-over

Hi Matthias and ports@ folks, I believe now is a good time to replace ghc and cabal with the new pieces I've been progressively sharing over the past several months. We'll get a bunch of upgrades to the existing Haskell binary ports such as ShellCheck and xmobar. We'll be able to easily add new

Re: lang/ghc workaround for clang 10 fallout

> I only tested the attached up to `make patch`. I have a build running > on amd64-current. It shows the export-dynamic token has disappeared > from the build log so far. While the patch is not known to have fixed > the problem with clang 10, it looks promising. I have more confidence in this

  1   2   3   4   5   6   7   >