On Fri, Jan 29, 2021 at 10:15:21PM +0100, Klemens Nanni wrote:
> The new version from 04.04.2020 fixes `-fno-common' builds.
> I sysutils/dtb already built on amd64 with this diff, the following
> consumers have yet to build-tested:
>
> $ show-reverse-deps devel/dtc
> emulators/qemu
>
Hi ports --
Attached is a patch to fix games/spacezero for -fno-common.
Upstream is long silent. Could not find other packages that had fixed
this. But the fix was easy.
OK?
~Brian
spacezero-nocommon.diff
Description: Binary data
backport a patch to fix -fno-common build
https://github.com/chocolate-doom/chocolate-doom/commit/a8fd4b1f563d24d4296c3e8225c8404e2724d4c2.patch
--- /dev/null Sat Jan 30 16:04:08 2021
+++ games/chocolate-doom/patches/patch-src_hexen_mn_menu_c Sat Jan 30
15:59:47 2021
@@ -0,0 +1,16 @@
+$Ope
+DISTNAME = plan9port-20210129
GH_ACCOUNT = 9fans
GH_PROJECT = plan9port
-GH_COMMIT =291f7411783bf6871b253f3b15ce691eea7a257e
+GH_COMMIT =36cd4c58c1346375b98f517fb8568be5bb47618d
CATEGORIES = plan9
@@ -32,10 +32,6 @@ NO_TEST
Hello ports --
OpenJK was identified as a port that fails with -fno-common.
It doesn't make much sense to cherry pick. Upstream makes no releases,
and it has been over a year since the last update. So let's just update
and that'll take care of -fno-common for us.
I know there are several OpenJK p
On 1/27/2021 12:54 AM, Brad Smith wrote:
On Wed, Jan 20, 2021 at 04:06:20PM -0500, Brad Smith wrote:
Here is an update to Boost 1.72.
Took a bit more digging. After a bit of adjustments and with debugging
messages turned on in one step, hinting that user-config.jam was being created
in the wron
Hello ports --
Attached is a fix for games/jumpnbump for -fno-common.
Taken from upstream (no new release since this commit):
https://gitlab.com/LibreGames/jumpnbump/-/commit/b72b70a4233776bdaa6a683c89af2becefd53bd6.diff
Left off the Makefile portion, since it is a no-op for us.
OK?
~Brian
ju
Updated tarball attached. I have added myself as
maintainer.
Thanks,
Anindya
From: Anindya Mukherjee
Sent: January 29, 2021 12:04 AM
To: Dimitri Karamazov
Cc: ports@openbsd.org
Subject: Re: New port: Gaupol subtitle editor
Hi,
Many thanks for the comments and fixes. Sure, I can take
maint
Hello ports --
Attached is a patch to fix cad/gerbv for -fno-common.
It is taken from Debian:
https://sources.debian.org/patches/gerbv/2.7.0-2/fixes/gcc10-extern.patch/
As it appears upstream is inactive.
OK?
~Brian
gerbv-nocommon.diff
Description: Binary data
Hello ports --
This patch fixes vgmplay for -fno-common.
Taken from upstream (no new release since this was committed upstream):
https://github.com/vgmrips/vgmplay/pull/74
OK?
~Brian
vgmplay-nocommon.diff
Description: Binary data
I've slipped this into a bulk build, and will let you know.
On 2021 Jan 29 (Fri) at 20:47:00 +0100 (+0100), Rafael Sadowski wrote:
:I have no access to aarch64. This is my first try to unbreak qtwebengine
:on arm64.
:
:http://build-failures.rhaalovely.net/aarch64/2021-01-24/x11/qt5/qtwebengine.lo
On 2021/01/29 20:49, Klemens Nanni wrote:
> It fails to build with "-fno-common" and HOMEPAGE indicates that its a)
> not being worked on any longer and b) already left behind (the note
> still has not been updated):
>
> http://nut.sourceforge.net says
>
> NUT Nutrition Software
> We
After seeing Carlos' mail on misc@ about Suricata I thought I'd try
running it but ran into some problems, I've included a diff below for
some of them:
- the default config file doesn't work due to a typo
- suricata-update and the default config don't use the directories setup
in PLIST
- some of
Hi,
Fix taken from Debian [0], with a patch refresh.
While here, HOMEPAGE and MASTER_SITES are not reachable, use the
dockapps archive [1]. Checksum is still the same.
OK?
Charlène.
[0]
https://sources.debian.org/patches/wmcalclock/1.25-16.1/05-fix-ftbfs.patch/
[1] https://www.dockapps.net/
A new dependency is required only during build.
All tests pass for robin-map
Information for inst:robin-map-0.6.3
Comment:
fast hash map and hash set
Description:
A C++ implementation of a fast hash map and hash set using
open-addressing and linear robin hood hashing with backward
shift deletion
The new version from 04.04.2020 fixes `-fno-common' builds.
I sysutils/dtb already built on amd64 with this diff, the following
consumers have yet to build-tested:
$ show-reverse-deps devel/dtc
emulators/qemu
emulators/spike
sysutils/u-boot
sysutils/u-boot,a
On Fri, Jan 29, 2021 at 08:56:47PM +, Brian Callahan wrote:
> Attached is a patch to fix cad/gerbv for -fno-common.
> It is taken from Debian:
> https://sources.debian.org/patches/gerbv/2.7.0-2/fixes/gcc10-extern.patch/
OK kn
>From pkg/DESCR:
Nemesis is a command line, portable "human IP stack". It can be useful
for easy injection of packet streams from simple shell scripts. It
supports 8 protocols (ARP/RARP, DNS, ICMP, IGMP, OSPF, RIP, TCP, UDP),
and packets can be injected on either L
This is take 2 for this port, I wasn't subscribed and I managed to
read over a small mistake for which is fixed in the included tarball.
Hi there,
I've been working with the nicotine-plus team for over 9 month now and
it has been going from flakey outdated code to a very nice program. It
has bee
It fails to build with "-fno-common" and HOMEPAGE indicates that its a)
not being worked on any longer and b) already left behind (the note
still has not been updated):
http://nut.sourceforge.net says
NUT Nutrition Software
We are in the process of rewriting NUT to work well on cu
I have no access to aarch64. This is my first try to unbreak qtwebengine
on arm64.
http://build-failures.rhaalovely.net/aarch64/2021-01-24/x11/qt5/qtwebengine.log
A built test to confirm this would be excellent.
Rafael
Index:
patches/patch-src_3rdparty_chromium_third_party_skia_src_opts_SkRast
Both are Python 2 only, collecting dust, their common upstream is dead
and py-vorbis is the only consumer of py-ogg.
Nothing in the tree uses either of them, not even as TEST_DEPENDS.
py-ogg now fails to build with "-fno-common".
OK?
On 2021/01/28 23:28, Sebastian Reitenbach wrote:
> Hi,
> not long ago, stegcracker was imported. I saw an update is available, looking
> at it,
> it says, that's the last version, use stegseek, as that's "lightning fast".
> Which indeed, it
> is. So attached a port of stegseek.
>
> so, I'd like
About half the times it fails to start:
$ xtraceroute
[...]
xtraceroute(66505) in free(): recursive call
Abort trap (core dumped)
It does not support IPv6.
I have also seen this:
#0 0x0ea94526e066 in __svfscanf (fp=, fmt0=,
ap=)
at /usr/src/lib/libc/std
This allows www/squidguard to build with -fno-common. Compile tested
only, on amd64. I'm not sure if this requires a bump or not.
Thanks,
Jeremy
Index: patches/patch-src_lex_yy_c_flex
===
RCS file: patches/patch-src_lex_yy_c_flex
d
The import of this tool in 2004 predates pf.conf(5)'s "af-to" which came
about in 2011.
Since that, there have been no port changes other than dusting things of
in the Makefile.
Upstream is dead, this port fails with "-fno-common" and I have a hard
time seeing how one would use a proxy daemon wit
Hi there,
I've been working with the nicotine-plus team for over 9 month now and
it has been going from flakey outdated code to a very nice program. It
has been extensively tested on amd64 and I do expect it to work on
other platforms as well, but your mileage may vary.
This is my first port in a
On Thu, Jan 28, 2021 at 11:28:10PM +0100, Sebastian Reitenbach wrote:
> for the quirks, just use reason 3: "no longer maintained upstream"
> or add a new one: "no longer maintained upstream, suggest stegseek" ?
Just add new ones if need be, no need to be less specific.
But if one replaces the oth
On Fri, Jan 29, 2021 at 08:00:27AM -0700, Tracey Emery wrote:
> Quick fix for naddy's -fno-common build error.
OK kn
On Fri, Jan 29, 2021 at 02:12:28PM +, Dimitri Karamazov wrote:
> Hi,
>
> The diff below updates Tor Browser to 10.0.9. Tested on amd64. More
> information can be found here:
> https://blog.torproject.org/new-release-tor-browser-1009
>
> Thanks,
> Caspar Schutijser
>
Works fine for me, thanks
This was one of the ports flagged by naddy@ with fno-common issues.
I've tested that this builds correctly with -fno-common.
One patch goes away as LibreSSL support is already upstream. A couple
new patches added to address a couple build errors.
Tested on amd64 to connect to a mainframe. Will
On Fri 29/01/2021 16:52, Sebastien Marie wrote:
> Hi,
>
> The following patch backport upstream patch to compile with
> -fno-common :
>
> https://github.com/ggreer/the_silver_searcher/commit/21eaa1c4160b868b0c5bbf59da17974429f30055
>
> Upstream patch doesn't cleanly apply to src/search.c du to c
Hi,
The following patch backport upstream patch to compile with
-fno-common :
https://github.com/ggreer/the_silver_searcher/commit/21eaa1c4160b868b0c5bbf59da17974429f30055
Upstream patch doesn't cleanly apply to src/search.c du to context
changes, but manually applying it work.
Tested with and
Build tested.
OK?
Index: Makefile
===
RCS file: /cvs/ports/x11/awesome/Makefile,v
retrieving revision 1.112
diff -u -p -r1.112 Makefile
--- Makefile1 Dec 2020 06:03:24 - 1.112
+++ Makefile29 Jan 2021 15:37:25 -
Build tested.
OK?
Index: Makefile
===
RCS file: /cvs/ports/textproc/the_silver_searcher/Makefile,v
retrieving revision 1.33
diff -u -p -r1.33 Makefile
--- Makefile12 Jul 2019 20:50:16 - 1.33
+++ Makefile29 Jan 2021
Quick fix for naddy's -fno-common build error.
Ok?
--
Tracey Emery
Index: Makefile
===
RCS file: /cvs/ports/net/thingsd/Makefile,v
retrieving revision 1.6
diff -u -p -u -r1.6 Makefile
--- Makefile26 Aug 2020 16:59:56 -
Here are the results from a first amd64 bulk build with -fno-common.
It's very much a case of mixed news.
The good news is that few ports with a significant number of
dependencies failed, and consequently most of the tree built.
The bad news is that there are about 300 mostly leaf ports that
fail
Christian Weisgerber:
> I'll send a followup message with additional background information.
So what's a "common (variable)"? When multiple object files have
an externally visible variable with the same name, the linker will
merge these variables so that they all refer to the same memory
locatio
On Fri, Jan 29, 2021 at 04:28:50AM +, Dimitri Karamazov wrote:
> Hi, this is a port of gaupol, an editor for text-based subtitle files.
> It supports multiple subtitle file formats and provides means of
> creating, editing and translating subtitles and timing subtitles to
> match video.
>
> Th
Björn Gohla writes:
> Omar Polo writes:
>
>> Omar Polo writes:
>>
>>> Björn Gohla writes:
>>>
Hi All,
Is there any particular reason why we don't have a Guile 3
(https://www.gnu.org/software/guile/) port?
(I might secretly try making one.)
>>>
>>> I tried some tim
Hi,
Many thanks for the comments and fixes. Sure, I can take
maintainer. So, it looks like I only need to add maintainer
to your version? Build and package looks ok and runs.
Any other suggestions?
Thanks,
Anindya
From: Dimitri Karamazov
Sent: January 28, 2021 9:14 PM
To: Anindya Mukherjee
Cc:
41 matches
Mail list logo
