Volker Schlecht writes:
> benchmarks/tsung currently suffers from a number of compilation
> and runtime errors when compiling/running on OTP versions > 25
>
> All that is needed to fix that, has been documented in a number
> of issues, and pull requests, but it appears that there isn't a
> lot of
Just realized I didn't update this port in this cycle. I tested that it
works for me on amd64. I'm building it on arm64 now.
I'm equally happy to merge now or wait until 7.7 is cut.
---
productivity/hledger/Makefile | 135 +++
productivity/hledger/distinfo | 308 -
Hi Matthias,
I rebuilt ghc bootstraps on both supported platforms and uploaded the
results into ~gnezdo/snapshot. I was running these snaps:
amd64 OpenBSD 7.7-beta (GENERIC.MP) #600: Sun Mar 16 17:44:04 MDT 2025
arm64 OpenBSD 7.7-beta (GENERIC.MP) #341: Sun Mar 16 16:10:07 MDT 2025
If you could
Should eventually enable building ghc-9.12.
I'm rebuilding the dependents as we speak. OK?
---
devel/cabal-install/Makefile | 39 +-
devel/cabal-install/distinfo | 96 +--
devel/cabal-install/files/openbsd.json | 841 +
3 files changed, 525 insertion
Volker Schlecht writes:
> Here's an update to the latest release of bazel 6.x
> I didn't manage to build XLA (https://openxla.org) yet, but at least it
> doesn't
> complain about the bazel version anymore :-)
Thanks for working on the update. I played with an update to the 7.x
series but it's n
This is now based on the newest version but it still has some problems
like the version in the tree. E.g. it won't include happy-lib or tasty
dependency when trying to regenerate pandoc.
I'm not eager to submit this, just recording it here for posterity.
0001-Update-cabal-bundler-to-the-latest-
James Turner writes:
> Also 9.8.4 was release :P
Thanks. My reading of the changelog indicates the changes aren't
important for us.
Matthias Kilian writes:
>> I had to repack the amd64 bootstraps because I previously had the wrong
>> date inside the archive. Matthias, would you mind picking up the new
>> tarballs from my cvs dir?
>
> Done. Checksums for all files (still the old hadrian-sources, I hope
> that's ok):
>
> SHA256
George Koehler writes:
> lang/ruby/Makefile.inc has
> SUB ?= ${MACHINE_ARCH:S/amd64/x86_64/}-openbsd
> SUBST_VARS += SUB
>
> Then the ${QUAKE_ARCH} or ${SUB} goes in PLIST.
Nice, thanks! New patch attached. It seems complete enough now to ask
for OK. I confirmed arm64 is s
There are newer versions of criterion-measurement that
support arm64. Yet I'd rather cut the feature nobody's
known to need than add a custom configuration that
certainly nobody used before.
OK?
diff --git a/devel/git-annex/Makefile b/devel/git-annex/Makefile
index 130e39c100d..f21462e1f1a 100644
Greg Steuck writes:
> Greg Steuck writes:
>
>> I'll keep building Haskell ports, but wanted to share this early now
>> that I confirmed cabal-{install,bundler} ports work fine.
>
> I checked all the ports using ghc. They all built fine which was to be
> expe
Stuart Henderson writes:
>> And I've already mentioned these in previous emails (with patches), but
>> just to clarify, in case it helps (since I don't know what opaque FILE
>> means, or how it relates to needing cross-compile scaffolding; sounds
>> like an abstract FILE pointer in C):
>
> There'
حبيب محمد الأمين محمد الهادي writes:
>> To be honest, I'm focusing on putting together a monster of a hack
>> environment on arm64 by cross-compiling just enough stuff. I suspect
>> polishing the cross-build flow is too much trouble for one use that we
>> need to happen. The next one is likely to
Matthias Kilian writes:
> Hi,
>
> On Mon, Nov 18, 2024 at 07:06:35PM +, Stuart Henderson wrote:
>> It's possible there might have been some other way to workaround this
>> for ghc but it seemed an apt time to remind about it. Last time we did
>> this (for 64-bit time_t) we had to go through g
حبيب محمد الأمين محمد الهادي writes:
> Okay, those references have nothing to do with it. I'm starting a build
> from scratch.
In case anybody cares to pick up a prebuilt bindist, I put it up:
https://github.com/blackgnezdo/ports/releases/download/ghc-9.10.1-arm64/ghc-9.10.1-aarch64-unknown-ope
writes:
> My bad, looks like those references do have something to do with it.
>
> I made some more changes to the cross-build script, and tried again,
> and the result was that the sysroot shows up in the linker's -L args
> when compiling with that GHC, then stops showing up after removing
> tho
Nice, with these hacks we're making more progress still :)
> I've been looking into this, and the weird line I mentioned before in
> hadrian/src/Rules/Program.hs was to blame.
>
> Make the following change and Hadrian will actually attempt to build a
> stage 2 aarch64 compiler instead of simply co
My guess was accurate. A couple of small patches[0] allow me to
cross-compile a working hello-world. I'll see if I can turn this into a
full bindist to make arm64 ghc self hosting.
Then there a question of building ghc 9.8.3 instead of 9.10.1 which we
currently have. I imagine we can figure this o
حبيب محمد الأمين محمد الهـاد writes:
> I reproduced your same error, and figured out the cause. I'll just embed
> it as a diff inline, you'll spot it in the script instantly :).
AFAICT we are out of the cross-compilation woods and straight into the
OpenBSD mitigations paradise :) I pushed a tiny
حبيب محمد الأمين محمد الهـاد writes:
> I reproduced your same error, and figured out the cause. I'll just embed
> it as a diff inline, you'll spot it in the script instantly :).
>
> Took me annoyingly long to find it; I didn't at all expect that it'd be
> either the configure or Hadrian lines, as
Sorry, wrong config.log before. This one is from
_build/stage1/rts/build/config.log
config.log.gz
Description: Binary data
Greg Steuck writes:
> I'll keep building Haskell ports, but wanted to share this early now
> that I confirmed cabal-{install,bundler} ports work fine.
I checked all the ports using ghc. They all built fine which was to be
expected insce all the work was done before we aborted 9.8.2 l
Hi Matthias,
I believe ghc-9.8.3 is no longer behind 9.6.6 in terms of bug fixes. I
put a set of updated bootstraps in cvs:~gnezdo/snapshots and the patch
references them. People who want to follow along at home can skip the
BIN_VER change, the previous bootstrap still works fine.
I'll keep build
حبيب محمد الأمين محمد الهـاد writes:
> I've been keeping the commands in a shell script, though I was still
> a bit surprised it worked to get to the same point first try. I was
> running the commands manually, as the script didn't fetch the sources,
> extract the sysroot, etc.
Thanks for the de
حبيب محمد الأمين محمد الهـاد writes:
> New progress update.
>
> I got stage 1 and 2 to build together(!) in just 2 hours. As before,
> stage 2 compiler seems to be copied.
That's exciting. Now that you have the recipe reproduced more than once,
maybe you can document it well enough for others to
ault and put me on a better path. I
> wonder if choosing a flavour other than quickest might also result in an
> aarch64 stage 2 GHC binary?
>
> Sent from my iPhone
>
> On 2 Nov 2024, at 11:22 pm, Greg Steuck wrote:
>
>
> You seem to have made it pretty far through the b
t when cross-compiling… which it doesn't. So I guess GHC's
> configure script needs to learn so it knows this when cross-compiling on
> OpenBSD. I'll hack it for now to see if the build otherwise works.
>
> Cheers,
> Habib
>
> On 29 Oct 2024, at 14:49, حبيب محمد الأمي
>
> "stage1.*.ghc.c.opts += -I$SYSROOT/usr/include -I/usr/include" \
> "stage1.*.ghc.link.opts += -L$SYSROOT/usr/lib -L/usr/lib -lpthread" \
> "stage1.*.cc.c.opts += -L$SYSROOT/usr/lib -L/usr/lib -lpthread" \
> -VV --freeze1 \
>
Lydia Sobot writes:
>>Perfect. How far in are you?
> Not very, still figuring out how exactly the pieces fit in together
FWIW, I made some effort in this area and it didn't go particularly
smoothly. Some info in https://gitlab.haskell.org/ghc/ghc/-/issues/24431
Works for my normal use. OK?
---
productivity/hledger/Makefile | 116 +++
productivity/hledger/distinfo | 284 +-
.../hledger/patches/patch-hledger_cabal | 43 ---
3 files changed, 196 insertions(+), 247 deletions(-)
delete mode 100644 p
Seems to be working well enough to build hledger (to follow).
>From 03a0f0fecf71de606ef8088b4e2dba9dad53fc40 Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Fri, 18 Oct 2024 21:52:22 -0700
---
devel/cabal-install/Makefile | 40 +-
devel/cabal-install/distinfo |
"Anthony J. Bentley" writes:
> Currently, the font module defines a default install target based on
> file extension. A port sets MODFONT_TYPES to "ttf otf", and the module
> installs ${WRKSRC}/*.ttf and ${WRKSRC}/*.otf to MODFONT_DIR.
>
> This misses two fairly common cases:
>
> - the port needs
Greg Steuck writes:
> The ports tree dependencies all built fine. I'll look into why one test
> failed, but otherwise, does this look OK?
I found the patch to backport. All the tests pass now with this added:
>From 7bf4b189deb0b1446a099ba9786ca7f8b8434d94 Mon Sep 17 00:00:00 2
>From a7223783b7b5ad3fd8ea4d2cb2883e8dac1b071e Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Mon, 8 Jul 2024 09:59:20 -0700
Subject: [PATCH 1/3] Update to to ghc 9.6.6
---
lang/ghc/Makefile| 8 +++-
lang/ghc/distinfo
Jan Stary writes:
> On Jun 06 11:47:05, h...@stare.cz wrote:
>> On Jun 04 13:29:21, s...@spacehopper.org wrote:
>> > On 2024/06/04 12:38, Jan Stary wrote:
>> > > The audio/opencore-amr port provides amrnb (narrowband encoder + decoder)
>> > > and amrwb (wideband decoder). This is the missing part
Hi Matthias,
Even though we have everything lined up to switch to ghc-9.8.2, I'm
having second thoughts.
GHC release plans here deprioritize this branch:
https://www.haskell.org/ghc/blog/20240521-ghc-release-priorities.html
Unless somebody has a good reason for us to jump, I propose we keep the
p
Seems to work. OK?
The main point of the two upgrades is to make ghc-9.8 import that
follows not cause any further churn.
>From 3d1fbcadc2598cdc75be6d7dd4f1337b2cd51279 Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Sun, 28 Apr 2024 17:24:27 -0700
Subject: [PATCH 2/2] Support ghc-9.8 in
Running fine here. OK?
>From ce39a866ea4e5ff0b3042e50a83d0e25776562f1 Mon Sep 17 00:00:00 2001
From: Greg Steuck
---
productivity/hledger/Makefile | 66
productivity/hledger/distinfo | 142 +-
.../hledger/patches/patch-hledger_ca
James Cook writes:
> On Mon, Apr 22, 2024 at 11:21:36AM GMT, Greg Steuck wrote:
>> James, if you'd like to play with this on -current, please remove both
>> patch-libraries_text_simdutf_simdutf_h and
>> patch-libraries_text_cbits_measure_off_c
>>
>>
Stuart Henderson writes:
> On 2024/04/22 10:30, Greg Steuck wrote:
>> > If it would help, I could update my old AMD machine to -current
>> > and check ghc works with the two patches removed, once I've finished
>> > trying out the patch I just sent for 7.5.
>
James Cook writes:
> The line you linked to comes after a check for cpuid_bit::osxsave,
> so I don't think it would get reached on machines that don't have
> xgetbv, i.e. it should be fine.
Cool, so maybe we need a patch which does this? I also just noticed
that you patched libraries/text/cbits/
Stuart Henderson writes:
> This is in the avx512 checks in the text library again, I think it must
> be patch-libraries_text_cbits_measure_off_c (the simdutf one doesn't
> explicitly check for xgetbv but it does check for osxsave so I think
> wouldn't have executed the xgetbv opcode on this cpu).
James Cook writes:
> Here are some results of debugging with lldb.
>
>
> With cabal-bundler and pandoc, it seems to be the xgetbv instruction
> itself:
>
>
> $ lldb /usr/local/bin/cabal-bundler
> (lldb) target create "/usr/local/bin/cabal-bundler"
> Current executable set to '/usr/local/bin/cabal
I recently noticed that notification that firefox shows for Google Chat
are displayed as ordinary windows by xmonad as opposed to corner popups.
Is this a recent change or did I simply not notice this behavior before?
Anybody else hit this? Any workarounds?
The windows have somewhat different pro
Evan Silberman writes:
> Fairly straightforward now that I can build working Haskell programs on
> here again. The version of the pandoc-cli package is now 1:1 with the
> pandoc version so packaging is a bit easier. The manuals for the
> pandoc-server and pandoc-lua modes are also packaged now.
T
Stuart Henderson writes:
> On 2024/02/18 16:56, Evan Silberman wrote:
>> Something like this? I'm out of my depth and heavily pattern-matching
>> against the fix to simdutf and other references. Genuinely no idea if
>> I'm using inline asm correctly, etc. Works on my machine, however.
>
> That se
Oh wow, this is becoming eerily similar to the failures aja@ is getting. Do
dig more into this!
On Sat, Feb 17, 2024, 21:34 Evan Silberman wrote:
> Evan Silberman wrote:
> > Thanks to the amd64 snapshot package archives I was able to bisect to a
> > working pandoc package on my machine. OK on 2
Evan Silberman writes:
> Can you repeat for OPENBSD_WXNEED? On my syspatched 7.4-release VPS, pandoc
> from packages has wxneeded:
>
> ~$ uname -rsv
> OpenBSD 7.4 GENERIC#1336
> ~$ readelf -Wl $(which pandoc) | grep OPENBSD_WXNEED
> OPENBSD_WXNEED 0x00 0x 0x
Evan Silberman writes:
> I should've figured out how to use readelf before I bothered with this,
> the NOBTCFI elf segment is already present in the ports in question.
> Above diff is irrelevant. It does seem significant that the ports that
> work fine (ghc and cabal-install) are, naturally, the
Stuart Henderson writes:
> It runs ok on ryzen. 11th gen intel + SIGILL - looks like an IBT
> issue.
Isn't -Wl,-z,nobtcfi supposed to have disabled this?
https://codeberg.org/OpenBSD/ports/src/branch/master/lang/ghc/Makefile#L123
Thanks
Greg
Evan Silberman writes:
> Hi ports@ and Greg,
>
> On -current (yesterday's amd64 snap, this morning's amd64 packages),
> ports built with ghc are all getting SIGILL early in execution on my
> laptop.
Interesting, when was the last time it worked for you?
> I'm not totally positive what is helpfu
Anybody else got this with the recent update to
OpenBSD 7.4-current (GENERIC.MP) #1634: Sat Jan 27 20:29:34 MST 2024 ?
# pkg_add -ui
quirks-7.0:updatedb-0->0p0: ok
quirks-7.0 signed on 2024-01-27T13:35:18Z
quirks-7.0->7.0: ok
...
unzip-6.0p17-iconv->6.0p17-iconv (processing)|No change in
unzip-6.
Normal development happening:
https://hackage.haskell.org/package/hledger-1.32.2/changelog
Completely machine generated update. Seems to be working for me.
OK?
>From ef5c498786a6d0e83d5604c30f0b9ce66a79b2c9 Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Sat, 27 Jan 2024 23:14:04 -0
Now that we landed ghc-9.6 is a good time to have `make test` fixed. It
took some doing to have them all fixed upstream and even then some of the
fixes are still not in 9.6. Anyway, OK?
>From fe0577aab710d1a3c5c5e4178088ffe96a2da07d Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Sun, 14
Greg Steuck writes:
> So I was wondering which program is responsible (because my previous
> "fix" was to restart the X session). Turns out exiting firefox is
> enough to get the device back.
I don't understand how or why firefox decides that it should hold on to
fid
Greg Steuck writes:
> I verified that this works well enough in emacs with eglot. Maybe others
> will find it useful enough to OK? If so, I'd apprecite a bit of extra
> diligence as this is my first rust port.
>
> rust-src seems important for this port, maybe it should be
>From 66e7595456552f8b76a602eff92e4136b7b97441 Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Sun, 3 Dec 2023 13:06:02 -0800
Subject: [PATCH] Added devel/rust-analyzer
---
devel/rust-analyzer/Makefile | 31 +++
devel/rust-analyzer/crates.inc | 191
devel/rust-analyzer/distinfo
Thank you for giving these a try. Care to try again with just the single
patch included?
James Cook writes:
> On Sat, Nov 11, 2023 at 07:22:32PM +0000, Greg Steuck wrote:
>> Here's an update to the most recent version which still includes the
>> docs in the published tg
Hi James,
Thanks for giving these patches a go.
James Cook writes:
> On Sun, Nov 12, 2023 at 10:14:07AM -0800, Greg Steuck wrote:
>>Took a bit of effort to patch because the upstream doesn't seem to be
>>active. Next time I have to touch darcs I'll propose to delete
Antoine Jacoutot writes:
> On Tue, Nov 21, 2023 at 09:32:03AM -0800, Greg Steuck wrote:
> Archival?
> I think it would be a welcome addition to ports@ if you care to maintain it.
Sure, any OKs then?
Stuart Henderson writes:
> some tweaks for consideration,
>
> - drop rcs id
> - no point restricting untested archs
> - unzip is already auto-added to BDEPs
> - no need to set MODPY_VERSION to what's already the default
> - verbose builds are often helpful to figure out any issues in
> bulk build
The eagle-eyed readers of the bazel port I just sent will notice I used
a non-recommended jdk-17. That's because the recommended jdk-11 is dying
with SEGV. It's enough to change to `MODJAVA_VER = 11` in my port and
run `make build`. That's all happening on a post llvm-16 amd64 snapshot.
I'm attach
The Google polyglot build tool at https://bazel.build/ turned out to be
a bit more trouble to port than usual, but it is somewhat functional
with the preliminary port below.
The effort is losely based on the previous attempt by Matt Hildebrand
from 2020 (thanks Matt!).
I'm not yet sure if I want
Took a bit of effort to patch because the upstream doesn't seem to be
active. Next time I have to touch darcs I'll propose to delete it.
OK?
>From e5d47b0a79d2f89ac180fc7ff7b5808e75f2e983 Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Sun, 12 Nov 2023 09:53:08 -0800
openFd API
Here I'm confused why things used to work or when it broke. The new
code makes sense and is consistent with the revision handling below.
OK?
>From a646f21c45e5a13fb76981e0b8e936b5fce77ad3 Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Sun, 12 Nov 2023 08:25:24 -0800
This looks lik
Machine-generated, OK?
>From f0a34d14842b2c3a9cd9352264b93110d89fecfe Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Sun, 12 Nov 2023 08:24:45 -0800
---
devel/hasktags/Makefile | 38 +++
devel/hasktags/distinfo | 100 ++--
2 files changed,
The easiest upgrade ever, OK?
>From 86df508432b1a391b3c3eb41c674ad6cc3d1116d Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Sun, 12 Nov 2023 13:46:26 +
Subject: [PATCH] Bump cpphs to allow building with ghc 9.6
---
devel/cpphs/Makefile | 4 ++--
devel/cpphs/distinfo | 4 ++--
2 fi
OK?
>From 1cf532b4908dc47c03d0cef218821b8339f98571 Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Sun, 12 Nov 2023 03:17:05 -0800
Subject: [PATCH] Update shelcheck to a ghc-9.6 compatible version from git
I asked for a formal release, but it would be good to be ready
should we choose to m
Greg Steuck writes:
> Running this now on my laptop, OK?
This one also builds with 9.6.3. OK?
>From f4de82273eadc159ea36cfdb70e21253b74df784 Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Sat, 11 Nov 2023 03:50:02 -0800
Subject: [PATCH] Upgrade xmobar to 0.47.1
---
x11/xmobar/Ma
Here's an update to the most recent version which still includes the
docs in the published tgz bundle. The second commit is to be delayed
until GHC 9.6.3 goes in.
OK?
>From 69c6396a0c7cd68ad697475833c69fc48f4d7103 Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Sat, 11 Nov 2023 04:43:
Running this locally. Compatible with 9.6.3. OK?
>From 01e6b2155ff4ec67ae939a254547ff8330e06818 Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Sat, 11 Nov 2023 15:20:13 +
---
x11/xmonad/Makefile | 9 -
x11/xmonad/distinfo |
Greg Steuck writes:
> Completely machine-generated, OK?
That one was broken such that it wouldn't build when happy not already
installed. So, this one is better:
>From dfc8ca6e72b89a44e422fc4fd5281850b525f203 Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Fri, 10 Nov 2023 11:
Running this now on my laptop, OK?
>From cbaa0db1941781ffe7692ffb6c0853d65932a052 Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Sat, 11 Nov 2023 03:50:02 -0800
---
x11/xmobar/Makefile | 174 ++---
x11/xmobar/distinfo | 358
Except for a somewhat ugly way to patch out "Safe", this
is a trivial upgrade. Upstream knows but there are complication
due to maintainership situations.
OK?
>From 87869100d059eae74485e68487454bce5c7682c1 Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Fri, 10 Nov 2023 0
Completely machine-generated, OK?
>From b6a2b6e7c8f36852406b5284c39236aff8d2f469 Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Fri, 10 Nov 2023 11:50:25 -0800
Subject:
---
devel/happy/Makefile | 3 +--
devel/happy/distinfo | 4 ++--
devel/happy/pkg/PLIST | 16 +++-
3 fi
This a trivial usability improvement OK?
>From 80955d7c5979f7d83f9df32abda1f78cc030245e Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Fri, 10 Nov 2023 10:12:46 -0800
Subject:
---
devel/cabal/cabal.port.mk | 1 +
1 file changed, 1 insertion(+)
diff --git a/devel/cabal/cabal.port.mk b/de
Theo Buehler writes:
> The relevant bit seems to be this. Full log below.
>
> Warning: No remote package servers have been specified. Usually you would have
> one specified in the config file.
> Resolving dependencies...
> Error: cabal: Could not resolve dependencies:
> [__0] next goal: X11-xft (
Theo Buehler writes:
>> Alright. I've added that and will let you know if it happens again.
>
> This gives slightly more info. No change in the rest of the log except
> time stamps.
I'm pretty sure this is both new and actionable:
> Running: /usr/bin/pkg-config --version
> Running: /usr/bin/pkg
Theo Buehler writes:
> On Fri, Oct 06, 2023 at 08:38:12AM -0700, Evan Silberman wrote:
>> Evan Silberman wrote:
>> > Can't tell you why this cropped up for you and not me and Greg but would
>> > you try adding MODCABAL_BUILD_ARGS="-c digest-pkg-config" to your build?
>>
>> Sorry, should probabl
Matthias Kilian writes:
> Greg asked me to provide a new ghc boostrap. Here it is; i could built
> lang/ghc and all ports depending on it with it.
Thank you Matthias!
> If it's ok to put it in before release, could someone else please
> commit it?
I intend to your patch as is once my build su
Marc Espie writes:
> On Tue, Sep 26, 2023 at 10:29:57PM +0200, Matthias Kilian wrote:
>> Hi,
>>
>> Greg asked me to provide a new ghc boostrap. Here it is; i could built
>> lang/ghc and all ports depending on it with it.
>>
>> If it's ok to put it in before release, could someone else please
>>
Hi Evan,
Evan Silberman writes:
> Hi Greg, ports,
>
> Straightforward upgrade of Pandoc to 3.1.8 from a couple weeks ago,
> hoping to go in before ports freeze. (I only sit down to do this every
> so often so I was sort of playing chicken with the release cycle in case
> there was a bugfix relea
Looks like we no longer have to manage a namespace of just 10 entries
globally in the ports tree :)
OK?
>From 9f430fa6addbc4b89e260d5d7aa5cb43b8943b9b Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Mon, 4 Sep 2023 12:41:33 -0700
Subject: [PATCH] Switch from MASTER_SITES to MASTER_SITES.hs
Hi Matthias,
Does this look OK to you? I tested it locally.
Thanks
Greg
>From 489489bcc48fa74e992b86a1db3250b88d1c7529 Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Mon, 4 Sep 2023 12:30:11 -0700
Subject: [PATCH] Upgrade productivity/hledger 1.28->1.31
---
productivity/hledger/Ma
ven't addressed
> that yet)
See if the attached is close to what you had in mind. I only minimally
tested it and it's been decades since I wrote perl for a living.
>From 3024ba34f0c20946284888b53852b7603ace7a91 Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Thu, 24 Aug 2023
Evan Silberman writes:
> Greg Steuck wrote:
>> Looks like `pandoc lua` doesn't require and runtime deps on lua,
>> is that correct?
>
> Correct. HsLua embeds a Lua interpreter by default. NB the embedded Lua
> existed before 3.x for custom filters there just wasn&#x
Thanks for the update Evan! I was not eager to do it due to the -cli
changes, so I appreciate your taking care of it.
I tested your diff with net/gssdp (which seems like the only BUILD_DEPS
user of pandoc). Then also ran a manual step of shellcheck to confirm
the new version produces something sen
Matthias Kilian writes:
> still slacking around like hell, but I guess we need a new bootstrap
> for lang/ghc. If so, I'll try to enable USE_NOBTCFI, build a new
> bootstrap with it, and then use that for building the regular ghc
> package.
Yeah, sounds about right. I have no illusions about GHC
Greg Steuck writes:
> firefox 113.0 crashes for me on amd64 with the message above and prints
> this to its output when opening a folder full of pictures on
> dropbox.com.
Chances are, this is https://bugzilla.mozilla.org/show_bug.cgi?id=1829641
which is supposedly fixed in 114.
firefox 113.0 crashes for me on amd64 with the message above and prints
this to its output when opening a folder full of pictures on
dropbox.com.
[Parent 10375, IPC I/O Parent] WARNING: process 2097 exited on signal 11: file
/usr/obj/ports/firefox-113.0/firefox-113.0/ipc/chromium/src/base/process
Hi Matthias,
Does this look OK? I'm running it now.
Thanks
Greg
>From 46d19bdd46830e22ecc1ce3ebb0bb74661e48f96 Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Sun, 14 May 2023 15:19:58 -0700
Subject: [PATCH] Upgrade devel/cabal-install 3.8->3.10
---
devel/cabal-insta
"Lévai, Dániel" writes:
> Hi all,
>
> Attached is an update to the terminus font.
> Seems trivial enough, but couldn't test the raw fonts, though.
Thanks Dániel.
I also tested this with xterm, OK gnezdo
> Daniel
>
> diff --git a/fonts/terminus-font/Makefile b/fonts/terminus-font/Makefile
> ind
A fairly simple upgrade, I'm running it now.
OK?
>From a1df423d7323c48f142c6ddc9d722a43678884a4 Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Sun, 16 Apr 2023 00:14:09 -0700
Subject: [PATCH] Upgrade x11/xmobar-{0.43->0.46}
---
x11/xmobar/Makefile
I changed ld.so behavior in -current. We are now better aligned with
other systems. Still, if you see some libraries not being found at
runtime in strange scenarios, do let me know.
If you can confirm reverting the change fixes such breakage, it will be
even better: https://marc.info/?l=openbsd-cv
Matthias Kilian writes:
> Use a new bootstrap (still 8.10.7, but built on current from
> 2023-02-18). Attached is some kind of "port" I fiddled together
> from what's in CVS and some newer stuff, only used for "make
> bootstrap".
Nice! I belive we should keep a variation of this in the tree and
Hi Matthias,
We get this annoying line all over the place now in Haskell ports logs:
cc: warning: -Wl,--no-execute-only: 'linker' input unused
[-Wunused-command-line-argument]
I don't know of a simple way to stick the --no-execute-only flag only
into the link and not the compiler line of ghc/se
I rebuilt all our ports with this. Looks like a safe and useful upgrade,
OK?
https://www.haskell.org/ghc/blog/20230210-ghc-9.2.6-released.html
>From bb3d3aef3c36d2ebb05d9bc546e80907e51e2af5 Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Sat, 11 Feb 2023 18:44:41 -0800
Subject: [PATCH] Upgr
${WRKSRC}/cabal.project.local
+
# Automatically copies the cabal.project file if any.
MODCABAL_post-extract += \
&& (test -f ${FILESDIR}/cabal.project \
--
2.39.1
>From 644d93b129217c7b12feef0fdfced9347095ba08 Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Sat, 4 Feb 2023 22:3
Klemens Nanni writes:
> 25.01.2023 06:25, Greg Steuck пишет:
>> Should I crank up revision for them all so we can easily tell which side
>> people are on should things go wrong?
>
> You MUST bump REVISION for all ports producing haskell binaries because
> you changed th
Christian Weisgerber writes:
> Greg Steuck:
>
>> Yes, it does rely on us shipping lld on amd64 which is the only platform
>> with lang/ghc.
>
> lld is the default linker on amd64! You don't even need -fuse-ld=lld.
Indeed, so the patch below is even better. I rebui
1 - 100 of 399 matches
Mail list logo
