On Apr 10 21:54:21, du...@l10n.ro wrote:
> >> Is mplayer still a thing? Have used it for many years a long time ago,
> >> but now I see the latest stable is 2 years old and nicknamed
> >> "worksforme"… :-]
> >>
> >> I think of mpv as the spiritual successor of mplayer, being the most
> >> succes
I made supplementary changes to the exim port to also take the
maintainership of that port.
I corrected the sites now accepting https.
I brought the internal exim Makefile more in line with the current one
from exim 4.91 so if someone wants to try something not in the normal
build, it's easier
Hi,
it may seem presumptuous that i'm fanning out candidate fixes for
kde/libs3, given that i never used KDE or GNOME or anything similar
in my life.
Not sure whether i should ask for OKs for this...
I have mostly done code inspection, no testing,
and the package now builds.
My hope is mainly th
Hi Brian,
Brian Callahan wrote on Mon, Apr 16, 2018 at 05:54:00PM -0400:
> games/xminehunter is extremely old, the tarball and code is from 1997.
> I'm not sure it warrants more than this minimal fix.
You could probably fix it in the same way that i just used for net/nam,
but it would be even mo
bulk build on macppc-1.ports.openbsd.org
started on Tue Mar 27 13:14:40 MDT 2018
finished at Mon Apr 16 17:22:45 MDT 2018
lasted 20D21h08m
done with kern.version=OpenBSD 6.3 (GENERIC.MP) #16: Sat Mar 24 16:32:29 MDT
2018
built packages:8906
Mar 27:409
Mar 28:461
Mar 29:456
Mar 30:272
Mar 31:426
On Tue, Apr 17 2018, Jeremie Courreges-Anglas wrote:
[...]
> It builds with lots of warnings
I was looking at another port, nepenthes doesn't exhibit *that* many
warnings, but my proposal stands.
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
net/nepenthes: honeypot software that hasn't seen a new release since
2008. It links with touchy libs like libmagic and libpcre as noted
by sthen@. It builds with lots of warnings and has been broken with
clang 4.0.0 and 6.0.1. I think keeping it on life support is doing more
harm than good.
Ok
Hi,
i already committed a fix that doesn't require
forcing an old language standard.
Yours,
Ingo
Giovanni Bechis wrote on Tue, Apr 17, 2018 at 12:36:12AM +0200:
> clang6 fix for net/nam, still a lot of warnings but at least it builds.
> Index: Makefile
>
Hi,
clang6 fix for net/nam, still a lot of warnings but at least it builds.
ok ? Comments ?
Cheers
Giovanni
Index: Makefile
===
RCS file: /var/cvs/ports/net/nam/Makefile,v
retrieving revision 1.40
diff -u -p -r1.40 Makefile
--- M
Hi ports --
games/xminehunter is extremely old, the tarball and code is from 1997.
I'm not sure it warrants more than this minimal fix.
Runs fine.
OK?
~Brian
Index: Makefile
===
RCS file: /cvs/ports/games/xminehunter/Makefile,v
r
On 2018-04-15, Brian Callahan wrote:
> For some reason I'm not quite sure about, with clang6 sdcc decides it
> needs to regen all its configure scripts.
There must be some kind of race condition. It built in _some_ bulk
runs since the clang6 switch.
--
Christian "naddy" Weisgerber
On Mon, Apr 16 2018, wrote:
> I tried to continue the build of php with the ports snapshot of today and ran
> into another gcc problem:
[...]
> /usr/ports/pobj/gcc-4.9.4/gcc-4.9.4/gcc/config/arm/arm.md:97:16: warning:
> equality comparison with
> extraneous parentheses [-Wparentheses-equ
On 2018/04/16 16:34, trondd wrote:
> On Mon, April 16, 2018 7:01 am, Stuart Henderson wrote:
> > On 2018/04/15 16:48, trondd wrote:
> >> What is the policy around setting SEPARATE_BUILD? Any GNU build? Not
> >> just builds that require it?
> >
> > It's useful for large ports where you might want
On Mon, April 16, 2018 7:01 am, Stuart Henderson wrote:
> On 2018/04/15 16:48, trondd wrote:
>> What is the policy around setting SEPARATE_BUILD? Any GNU build? Not
>> just builds that require it?
>
> It's useful for large ports where you might want to "make clean=build"
> and they take a long ti
I tried to continue the build of php with the ports snapshot of today and ran
into another gcc problem:
/usr/ports/pobj/gcc-4.9.4/gcc-4.9.4/gcc/config/arm/arm.md:97:16: note: remove
extraneous parentheses
around the comparison to silence this warning
(thumb1_code)) == (
^
/u
Hi,
The following diff adds MAP_STACK on allocated memory used for stack.
(Please note a diff on the kernel is pending for completely let qemu to
run - see https://marc.info/?l=openbsd-tech&m=152389221205108&w=2)
While compiling the port, I also see the following notice at end of
configure:
On 2018/04/16 17:00, Christian Weisgerber wrote:
> We still can't build libreoffice.
libreoffice at least needs this fixed:
http://build-failures.rhaalovely.net/amd64/2018-04-15/databases/strigi.log
/usr/obj/ports/strigi-0.7.7pl1/strigi-0.7.7pl1/libstreamanalyzer/plugins/indexers/clucenengindexe
We still can't build libreoffice.
Updated list as of Apr 16, 17:00 UTC. Logs at
http://build-failures.rhaalovely.net/amd64/2018-04-15/
audio/clementine
audio/hydrogen
audio/lmms
cad/kicad
databases/strigi
devel/qt-creator
emulators/BasiliskII
games/alephone/alephone
games/ja2-stracciatella
games
Hi,
not sure about the following one, there must be a less ugly way?
The problem is that there are *many* files containing lozts of
instances of
const char foo[] = { ..., 0xff, ..., 0xc0, ... }
which is not good on signed char archs. Patching all these files
would be even more noisy than s/c
On 2018/04/16 17:13, Ingo Schwarze wrote:
> Hi,
>
> not sure how to really test, but the following seems correct
> from code inspection, fixes the build, and the program still
> starts.
>
> Note that upstream is now at 2.0 and has rewritten everything
> in C, no more C++, so no need to report ups
Hi,
initialize to the correct data type.
Makes it build, and the program still
saves and opens project files for me.
Yours,
Ingo
Index: Makefile
===
RCS file: /cvs/ports/graphics/discwrapper/Makefile,v
retrieving revision 1.9
dif
Hi,
not sure how to really test, but the following seems correct
from code inspection, fixes the build, and the program still
starts.
Note that upstream is now at 2.0 and has rewritten everything
in C, no more C++, so no need to report upstream.
Yours,
Ingo
Index: Makefile
==
Hi Frederic,
Frederic Cambus wrote on Mon, Apr 16, 2018 at 03:05:23PM +0200:
> Here is a diff to fix BasiliskII build with Clang 6 (from upstream).
Uh oh. The upstream fix was committed on Feb 21, 2010.
That said, your patch does agree with upstream, looks reasonable,
and builds for me.
OK sc
Hi ports@,
Here is a diff to fix BasiliskII build with Clang 6 (from upstream).
Comments? OK?
Index: Makefile
===
RCS file: /cvs/ports/emulators/BasiliskII/Makefile,v
retrieving revision 1.38
diff -u -p -r1.38 Makefile
--- Makefile
Hi Anthony,
Anthony J. Bentley wrote on Mon, Apr 16, 2018 at 03:58:05AM -0600:
> japanese/groff is an ancient patchset on top of even more ancient
> groff (specifically groff-1.10, released in 1995).
Indeed, we are now almost at 1.22.4, and i regard anything older
than 1.22 as ancient and anythi
Hello,
Here is the patch to upgrade exim to 4.91.
This fixes CVE-2018-6789
Best Regards
Index: mail/exim/Makefile
===
RCS file: /cvs/ports/mail/exim/Makefile,v
retrieving revision 1.119
diff -u -p -u -r1.119 Makefile
--- mail/exim/
+cc maintainer
On Mon, Apr 16 2018, Alexander Bluhm wrote:
> Hi,
>
> This fixes facter build with clang6.
>
> /usr/include/c++/v1/memory:2541:13: error: delete called on
> 'facter::facts::external::resolver' that is abstract but has non-virtual
> destructor [-Werror,-Wdelete-non-virtual-dtor]
On Sun, Apr 15 2018, Brian Callahan wrote:
> Hi ports --
>
> For some reason I'm not quite sure about, with clang6 sdcc decides it
> needs to regen all its configure scripts. So let's oblige. Also adds
> a whole lot of items to the PLIST.
>
> OK?
ok, please mention (in the commit message and/or i
On 2018/04/16 11:35, Gonzalo L. Rodriguez wrote:
> > -DISTNAME= sqtop-2011-11-01
> > -PKGNAME= sqtop-2011.11.01
> > -REVISION= 2
> > +PKGNAME= sqtop-2015.02.08
> > +GH_ACCOUNT=paleg
> > +GH_PROJECT=sqtop
> > +GH_TAGNAME=
On 2018/04/16 11:05, Renaud Allard wrote:
> Hello,
>
> In the new exim version (4.91), DANE support moved from experimental to
> production. I tested by modifying the port to just include
> SUPPORT_DANE=yes in files/Makefile
>
> It compiles and runs fine without any other modification.
>
> Could
On 2018/04/15 16:48, trondd wrote:
> What is the policy around setting SEPARATE_BUILD? Any GNU build? Not
> just builds that require it?
It's useful for large ports where you might want to "make clean=build"
and they take a long time to extract/patch.
Otherwise it's pointless and can make extra
Hi,
japanese/groff is an ancient patchset on top of even more ancient
groff (specifically groff-1.10, released in 1995).
Nothing uses it anymore. So remove it as below (plus quirks of course).
ok?
Index: Makefile
===
RCS file: /cvs
On [09/04/18] [07:54P], Gonzalo L. Rodriguez wrote:
Hallo,
Update for Sqtop to 2015.02.08:
Switch to github, with the clang6 fix included,
https://github.com/paleg/sqtop/compare/v2015-02-08...master
OK? Comments?
Cheers.-
--
Sending from my toaster.
Index: Makefile
==
Hello,
In the new exim version (4.91), DANE support moved from experimental to
production. I tested by modifying the port to just include
SUPPORT_DANE=yes in files/Makefile
It compiles and runs fine without any other modification.
Could you enable this in further build with 4.91+?
Thank you,
On Sun, Apr 15, 2018 at 09:45:54PM +0200, Theo Buehler wrote:
> Three things:
>
> It seems upstream changed the server layout and killed the ftp://
> protocol, at least it isn't reachable from anywhere for me. I tried to
> find an official announcement for this, but gave up after 5 minutes.
>
> A
I have waited a long time for a working port of Godot. Godot runs on
my Thinkpad t460p on OpenBSD -current amd64 without any problems. I
hope Godot will be included in the ports tree and made available as a
package.
Best regards,
Christian
On Mon, Apr 16, 2018 at 02:22:58AM -0600, Anthony J. Bentley wrote:
> Theo Buehler writes:
> > +- (uchar**) &select_limit, 0, GET_ULONG, REQUIRED_ARG, 1000L, 1, ~0L, 0,
> > 1
> > , 0},
> > ++ (uchar**) &select_limit, 0, GET_ULONG, REQUIRED_ARG, 1000L, 1,
> > static_ca
> > st(~0L), 0, 1, 0},
>
Theo Buehler writes:
> +- (uchar**) &select_limit, 0, GET_ULONG, REQUIRED_ARG, 1000L, 1, ~0L, 0, 1
> , 0},
> ++ (uchar**) &select_limit, 0, GET_ULONG, REQUIRED_ARG, 1000L, 1, static_ca
> st(~0L), 0, 1, 0},
Would it make sense to use ~0ULL instead?
Only need to fix these two to build:
src/main.cpp:98:67: note: insert an explicit cast to silence this issue
(uchar**) &select_limit, 0, GET_ULONG, REQUIRED_ARG, 1000L, 1, ~0L, 0, 1, 0},
^~~
Brian Callahan writes:
>
> On 04/15/18 15:37, Klemens Nanni wrote:
> > On Sun, Apr 15, 2018 at 02:56:41PM -0400, Brian Callahan wrote:
> >> Index: Makefile
> >> ===
> >> RCS file: /cvs/ports/games/ja2-stracciatella/Makefile,v
> >> ret
trondd writes:
> What is the policy around setting SEPARATE_BUILD? Any GNU build? Not
> just builds that require it?
I don't know that there is any "policy", other than "set SEPARATE_BUILD
if needed, and don't set it if it breaks".
Certainly if it works, it's nice to have even when it's not str
41 matches
Mail list logo
