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
reg
>From fe79c6fa8b4a46072bcb6651ebfd3b4c58ddf4f0 Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Mon, 23 Jan 2023 09:11:17 -0800
Subject: [PATCH] Shrink Haskell binaries size via link time deduplication
http://brandon.si/code/linking-smaller-haskell-binaries/
---
devel/cabal/cabal.port.mk |
Hi Matthias,
I tested this upgrade by rebuilding all the dependenents and running a
minimal manual flow. OK?
Thanks
Greg
>From 99f7e29829c85c6d68d62a97a1d59a771d8d9346 Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Sat, 21 Jan 2023 22:36:28 -0800
Subject: [PATCH] Upgrade cabal-install
Volker Schlecht writes:
> Bump and correction:
>
> It has been broken for almost *three* years.
>
> Any thoughts?
I'm game to delete riak unless somebody speaks up in the next week?
>
> On 12/30/22 09:59, Volker Schlecht wrote:
>> Cc: Maintainer
>> Hi,
>> the version of riak in ports has been b
Thanks for the diff Volker. I committed it after confirming `make test`
looks better now.
Volker Schlecht writes:
> bump
>
> On 12/28/22 23:29, Volker Schlecht wrote:
>> Forgot a REVISION bump there.
>> On 12/28/22 11:55, Volker Schlecht wrote:
>>> Attached is a proposal to build benchmarks/tsun
I played with kdenlive on amd64 a bit and it crashes pretty frequently
with a core indicating memory corruption. I submitted the details to the
bug tracker. If anybody has a reliable way to cause or even avoid this,
please document your findings in
https://bugs.kde.org/show_bug.cgi?id=463764
Thank
I tested locally with `git-annex test`. Other testing is welcome.
Thanks
Greg
>From 86382af3ecd6cf42ae4898ddc9b4540fbbbdfa0b Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Sun, 11 Dec 2022 15:48:07 -0800
Subject: [PATCH] Upgrade git-annex 10.20220822 -> 10.20221103
---
devel/git
me as with the existing version.
OK?
>From c476295ff8e1aef293595dd1b7551bc9a23fd515 Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Sat, 26 Nov 2022 16:53:29 -0800
Subject: [PATCH] Upgrade lang/ghc 9.2.4->9.2.5
---
lang/ghc/Makefile | 9 -
lang/ghc/distinfo | 8
lang/g
ore local context.
Thanks
Greg
Applies to they develeopment branch (exact commit included)
https://github.com/ivmai/bdwgc/commits/master
>From 7d8cbc8ad5beb68194c32722f5b6c9e19847b07e Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Sat, 19 Nov 2022 22:58:41 -0800
Subject: [PATCH] Remove GC_OPENBSD
Hi Matthias,
I queued up a couple of upgrades while the tree was locked. I've been
using new hledger and James Cook helped me test and proof-read the patch
for git-annex.
OK?
Thanks
Greg
>From ac9aed2f074dc2a3c39d95b4e4594312bedbb83a Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Thu
William Rusnack writes:
> Hi,
>
> I am trying to use ghci from the ghc package and am receiving the following
>
> ```
> $ ghci
> GHCi, version 8.10.6: https://www.haskell.org/ghc/ :? for help
> ghc: internal error: setExecutable: failed to protect 0x0xc2fa3c4e000
>
> (GHC version 8.10.6 for
I did notice the crashes myself, but
they were rare and I couldn't properly diagnose.
Thanks
Greg
>From aef0924ef518ff3d4107957fb3a176cdee583154 Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Thu, 28 Jul 2022 21:34:37 -0700
Subject: [PATCH] Upgrade lang/ghc 9.2.{3->4}
---
lang/g
Hi Matthias,
Simple tool-generated upgrade that I'm running now. OK?
Thanks
Greg
>From b9b6b7cc2538bbe221a7ff18c29472322f7bba46 Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Tue, 7 Jun 2022 22:09:12 -0700
Subject: [PATCH] Upgrade productivity/hledger 1.25->1.26
---
productiv
Aaron Bieber writes:
> I had to adjust for REVISION - but other then that it builds fine for me!
>
> OK abieber@ if anyone wants a free commit! (if not i'll get to it this weekend
> some time)
Committed. "Free" here didn't mean "painless". The whitespace mangling
turned the OP patch application
Almost completely machine generated update. OK?
>From 43707ca4a34b39c3728c2ce7a6dda585654c10d8 Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Sun, 29 May 2022 14:42:30 -0700
Subject: [PATCH] Upgrade x11/xmobar 0.42->0.43
---
x11/xmobar/Makefile | 49 +
point,
we should look into aligning the automake versions between bootstrap and
port builds.
Thanks
Greg
>From dee8ca038ee8f42c9949503da289ce8614f4091e Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Sun, 22 May 2022 23:06:36 -0700
Subject: [PATCH 1/2] Remove USE_WXNEEDED from lang/ghc as i
Hi Omar,
This looks like a pretty significant update, thanks for taking it on.
Omar Polo writes:
> The list of consumer is daunting and I can't test everything nor run a
> bulk. So far I tested on amd64:
>
> - java/jna: (post update, see other thread) builds fine + all tests passing
> - lang
Matthias Kilian writes:
>> Once people test the patches to their satisfaction, we could update the
>> tree.
>
> At the moment, there seem to be three people doing test-builds with
> the patches (you, Volker and me), and all seem to be happy with the
> update ;-)
>
> So why wait? (That's an ok kil
I feel pretty good about where we are with ghc-9.2.2 (patches in
https://marc.info/?l=openbsd-ports&m=165103738516521&w=2). I just
rebuilt all the directly dependent ports. I have been running the
updated Haskell ports I use for the last couple of weeks.
Furthermore I have a stash of packages that
Thanks Volker for catching the bug.
Matthias Kilian writes:
>> Indeed, I get the same error. It looks like for whatever reason,
>> the xhml library isn't built before the build system starts to (try
>> to build) the stage2 compiler.
>
> This (on top of Greg's diffs) should hopefully fix it:
>
>
Hi Matthias and ports testers,
I have a plausible set of attached patches that should switch us to the
newest GHC. We are skipping the 9.0 series as I don't think they offer
anything valuable compared to going directly to the latest.
The ports that were easy to update while keeping compatible ghc
Hi Evan,
Evan Silberman writes:
> Attached updates pandoc to 2.18, also takes maintainer. (I finally have
> openbsd on a laptop after a couple years of debating with myself how
> sensible it is to buy yet another laptop.)
Very nice, thank you for taking the initiative and upgrading the port.
I'
kili@ and I are working towards the switch to ghc 9.2.2. Most things are
looking good and I pushed the most recent branch to
https://github.com/blackgnezdo/ports/commits/ghc-9.2
We have a couple of issues remaining to consider.
1) We can no longer produce a viable bootstrap package for i386. This
Hi Matthias,
Greg Steuck writes:
> As hinted a couple of weeks ago, the attached upgrades should be easy to
> land now. I rebuilt them on amd64 with ghc-8.10.6 and the new 9.2.
Here's another one which can go in: devel/alex
OK?
>From 9ab91286af7815e6358509f451019a14238e82c1 Mo
Hi Matthias,
As hinted a couple of weeks ago, the attached upgrades should be easy to
land now. I rebuilt them on amd64 with ghc-8.10.6 and the new 9.2.
OK?
Thanks
Greg
>From e1297b4d5f7feff4e94c28d55da52e601bfcf366 Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Sat, 26 Mar 2022 19:45
Ashton Fagg writes:
> The attached diff updates devel/git-annex to the latest version.
Thanks! I'll apply this after the ports unlock.
If you want a more substantial challenge, try to make git-annex work
with ghc 9.2 on any system as the problem is not particular to us. You
could also grab my
1 - 100 of 374 matches
Mail list logo
