Feb 2018 01:23:06 -
@@ -10,8 +10,6 @@ PKGNAME = hack-fonts-$V
CATEGORIES = fonts
HOMEPAGE = http://sourcefoundry.org/hack/
-MAINTAINER = Michael McConville
-
# SIL OFL 1.1
PERMIT_PACKAGE_CDROM = Yes
Index: mail/imap
Last fall, people discussed and reviewed jsg's patch to update
devel/coccinelle to 1.0.5:
https://marc.info/?t=14746991551&r=1&w=2
Since then, 1.0.6 has been released.
It seems that jsg's patch stalled because there was, for an unknown
reason, a big regression in the test suite results. Howe
Jordon wrote:
> I have current running on some machines and multiple times a week I
> will update them by booting bsd.rd and doing the (u) option (i think
> that is the ‘proper’ way to update to the latest current base system).
>
> I will occasionally update all the packages I have installed by do
Long overdue.
Index: Makefile
===
RCS file: /cvs/ports/fonts/hack-fonts/Makefile,v
retrieving revision 1.4
diff -u -p -u -r1.4 Makefile
--- Makefile22 Jan 2016 00:54:50 - 1.4
+++ Makefile25 Sep 2016 21:06:41 -
@@
Stephen Graf wrote:
> I have built a port for turnserver-4.5.0.3,
> https://github.com/coturn/coturn.
>
> It needs an experienced maintainer to complete and verify.
>
> I have tested the port and am running the results on openBSD 5.9
> stable. There is a reported dependency problem but it does no
This builds and runs fine for me.
Thanks for your time,
Mike
Index: Makefile
===
RCS file: /cvs/ports/net/syncthing/Makefile,v
retrieving revision 1.9
diff -u -p -u -r1.9 Makefile
--- Makefile3 Aug 2016 09:34:39 - 1.9
There aren't any patches to worry about. This update just adds Python 3
support and fixes --quiet compliance.
Thanks for your time,
Mike
Index: Makefile
===
RCS file: /cvs/ports/sysutils/bitrot/Makefile,v
retrieving revision 1.1.1.1
Michael McConville wrote:
> Ray Lai wrote:
> > Detects bit rotten files on the hard drive to save your precious
> > photo and music collection from slow decay.
> >
> > Don't let your bits rot, ffs.
>
> Attached is an iteration with a few fixes:
>
&g
Marc Espie wrote:
> On Tue, Aug 09, 2016 at 02:45:46PM -0400, Michael McConville wrote:
> > Syncthing is a daemon that lets you sync data between devices. By
> > default, both metadata and user data are stored in /var/syncthing.
> > However, when you update or delete the packa
Hi, everyone.
I was recently discussing this with edd@, who suggested that I pull in
ports@ and Marc.
Syncthing is a daemon that lets you sync data between devices. By
default, both metadata and user data are stored in /var/syncthing.
However, when you update or delete the package, pkg_add tells
Ray Lai wrote:
> Detects bit rotten files on the hard drive to save your precious photo
> and music collection from slow decay.
>
> Don't let your bits rot, ffs.
Attached is an iteration with a few fixes:
* update to 0.8.0
* specify that it's released under the MIT license
* tweak $COMMENT an
A few trivial fixes I've had sitting in my tree for months.
Index: infrastructure/man/man1/proot.1
===
RCS file: /cvs/ports/infrastructure/man/man1/proot.1,v
retrieving revision 1.14
diff -u -p -r1.14 proot.1
--- infrastructure/man/m
attila wrote:
> Ping.
>
> Just tested that the diff works against recentish i386 snap (22 May).
> Patch attached.
I can't comment on all of the changes, but this builds and runs fine for
me.
> Index: Makefile
> ===
> RCS file: /cvs
Twenty seconds of search queries suggests that it's a missing Qt4 Python
library. Here's an apparently similar issue from Debian:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=525556
Thanks,
Mike
mike:/home/mike$ hp-setup
HP Linux Imaging and Printing System (ver. 3.16.5)
Printer/Fax Setup
Stuart Henderson wrote:
> There's also an internal copy of libffi in ports/lang/gcc, I haven't
> got that far in my bulk build to know if it needs similar treatment
> yet.
IIRC, lang/racket has one too.
Dmitrij D. Czarkoff wrote:
> Stuart Henderson said:
> > glib2 is a pretty clean port patch-wise. This sort of thing would be
> > better done with proper autoconf etc so it can go upstream.
>
> Totally agree. It would be best if upstream would maintain the code.
> They could benefit from arc4rando
Michael McConville wrote:
> We patch Tor to use /var/tor instead of /var/lib/tor, but the hidden
> service example in the config hasn't been patched. This causes Tor to
> fail on startup if the example is used:
>
> > Error creating directory /var/lib/tor/hidden_se
I've had this sitting around for a while.
GLib's g_rand* functions use a simple Mersenne Twister, and the docs
warn against their use where strong randomness is needed:
https://developer.gnome.org/glib/stable/glib-Random-Numbers.html
g_rand_* are deterministic, while g_random_* are nondeterminis
We patch Tor to use /var/tor instead of /var/lib/tor, but the hidden
service example in the config hasn't been patched. This causes Tor to
fail on startup if the example is used:
> Error creating directory /var/lib/tor/hidden_service/: No such file or
> directory
The below patch fixes this.
In
Michael McConville wrote:
> As per mdoc(7), \&. is needed to escape a literal period.
>
> That said, shouldn't .Pa be used here rather than .Sq?
To clarify, it currently generates this:
‘’.,
When it should generate this:
‘.’,
&
As per mdoc(7), \&. is needed to escape a literal period.
That said, shouldn't .Pa be used here rather than .Sq?
Index: portbump.1
===
RCS file: /cvs/ports/infrastructure/man/man1/portbump.1,v
retrieving revision 1.4
diff -u -p -u -
Michael McConville wrote:
> Reasoning:
>
> o the code was last touched in 1995
>
> o the port hasn't been updated since import in 1999
>
> o it's obviously a very security-sensitive tool
>
> Alternatively, someone could update to a fork. I could onl
Are there more than a few cases in which ports should use -O3? A good
number still do, including Qt4 and Qt5.
Someone referred me to this past thread:
https://marc.info/?t=13560113402&r=1&w=2
But I couldn't find annotations in the Makefiles of ports still using
-O3.
Thanks for your time,
Mi
Stuart Henderson wrote:
> On 2016/04/21 23:21, Michael McConville wrote:
> > Dmitrij D. Czarkoff wrote:
> > > This diff sets PKGNAME and uses explicit HOMEPAGE. OK?
> >
> > I think you forgot the diff.
> >
> > In response to this:
> >
> > S
Dmitrij D. Czarkoff wrote:
> This diff sets PKGNAME and uses explicit HOMEPAGE. OK?
I think you forgot the diff.
In response to this:
Stuart Henderson said:
> And it changes the package name from sshfs-fuse to just sshfs.
That ship sailed when we changed DISTNAME for the GitHub mirror.
Regardl
Michael McConville wrote:
> Stuart Henderson wrote:
> > On 2016/04/21 20:58, Rafael Sadowski wrote:
> > > On Wed Apr 20, 2016 at 05:30:26AM -0400, Michael McConville wrote:
> > > > It's on by default, but can be disabled with the below cmake
> > > > a
Stuart Henderson wrote:
> On 2016/04/21 20:58, Rafael Sadowski wrote:
> > On Wed Apr 20, 2016 at 05:30:26AM -0400, Michael McConville wrote:
> > > It's on by default, but can be disabled with the below cmake
> > > argument.
> >
> > Are test results
Dmitrij D. Czarkoff wrote:
> Michael McConville said:
> > +GH_ACCOUNT = libfuse
> > +GH_PROJECT = sshfs
>
> You don't need these any more.
Don't we need them for HOMEPAGE? It uses the explicitly set MASTER_SITES
in its current form, too, so w
Michael McConville wrote:
> Stuart Henderson wrote:
> > On 2016/04/15 12:58, Michael McConville wrote:
> > > +GH_ACCOUNT = libfuse
> > > +GH_PROJECT = sshfs
> > > +GH_TAGNAME = sshfs-${V}
> >
> > Please use the proper uploade
Michael McConville wrote:
> Sorry, I meant graphics/DevIL here, obviously. I'll have a patch for
> graphics/darktable soon.
...never mind, I just noticed that darktable's Makefile specifies SSE3
as a hard requirement. Sorry for the noise.
The below patch for DevIL is st
Sorry, I meant graphics/DevIL here, obviously. I'll have a patch for
graphics/darktable soon.
Michael McConville wrote:
> Index: Makefile
> ===
> RCS file: /cvs/ports/graphics/DevIL/Makefile,v
> retrieving revision
Index: Makefile
===
RCS file: /cvs/ports/graphics/DevIL/Makefile,v
retrieving revision 1.18
diff -u -p -u -r1.18 Makefile
--- Makefile17 Jan 2016 17:29:09 - 1.18
+++ Makefile20 Apr 2016 09:48:16 -
@@ -3,7 +3,7 @@
It's on by default, but can be disabled with the below cmake argument.
Index: Makefile
===
RCS file: /cvs/ports/graphics/opencv/Makefile,v
retrieving revision 1.37
diff -u -p -u -r1.37 Makefile
--- Makefile15 Apr 2016 08:53:49 -0
The Makefile variable NATIVE defaults to 'on', in which case
-march=native is used. This disables it.
Index: Makefile
===
RCS file: /cvs/ports/math/ntl/Makefile,v
retrieving revision 1.40
diff -u -p -r1.40 Makefile
--- Makefile21
Michael McConville wrote:
> It seems dumb to include all the command line options in DESCR. Also,
> the formatting and grammar is somewhat unfortunate.
Same patch, now with more REVISION bump.
Index: Makefile
===
RCS file
It seems dumb to include all the command line options in DESCR. Also,
the formatting and grammar is somewhat unfortunate.
Index: net/icmpinfo/pkg/DESCR
===
RCS file: /cvs/ports/net/icmpinfo/pkg/DESCR,v
retrieving revision 1.2
diff -u
Stuart Henderson wrote:
> On 2016/04/15 12:58, Michael McConville wrote:
> > +GH_ACCOUNT = libfuse
> > +GH_PROJECT = sshfs
> > +GH_TAGNAME = sshfs-${V}
>
> Please use the proper uploaded release tarball
>
> DISTNAME =sshfs-2.7
> MASTER_
Does anyone who uses sshfs-fuse want to test this? It seems like an
interesting tool and I'm planning on trying it, but I haven't previously
and therefore might not notice regressions.
Index: Makefile
===
RCS file: /cvs/ports/sysutil
Reasoning:
o the code was last touched in 1995
o the port hasn't been updated since import in 1999
o it's obviously a very security-sensitive tool
Alternatively, someone could update to a fork. I could only find this
one, which doesn't seem popular and hasn't been touched in three years:
ht
I always find the current wording confusing. The first clause of this
sentence initially seems to imply that there may actually be a race
condition in the code.
Index: infrastructure/man/man1/dpb.1
===
RCS file: /cvs/ports/infrastruc
o it hasn't been updated since import in 2001
o it has twelve patches, most removing unsafe string functions
o I couldn't find a website or active development community
Is anyone still using this?
Michael McConville wrote:
> A few things:
>
> o a minor bugfix update (but not for tessdata)
>
> o remove a patch that's no longer necessary
>
> o the archive locations and distfile naming have apparently changed
That last part was unnecessary. Updated patch:
A few things:
o a minor bugfix update (but not for tessdata)
o remove a patch that's no longer necessary
o the archive locations and distfile naming have apparently changed
Index: Makefile.inc
===
RCS file: /cvs/ports/graphics/
Frederic Cambus wrote:
> MSN Messenger has been discontinued in 2013.
>
> Out of curiosity, I tried both of them to try to connect and see what
> happens, and expectedly, both clients time out. As far as I know,
> there is no open source server for the MSN protocol, so there is
> indeed no way at
Most or all of the changes were already included in patches. I'm not
sure whether the minor PLIST changes make sense - couldn't find anything
in the cvs logs.
Index: Makefile
===
RCS file: /cvs/ports/www/sthttpd/Makefile,v
retrieving
Michael McConville wrote:
> We last updated net/loudmouth in 2008. Upstream is gone, and the
> following depend on it:
>
> o net/mcabber
> o net/irssi-xmpp
> o net/freetalk
> o lang/io (strangly)
>
> I know that at least two of those are pretty common chat client
Chris Bennett wrote:
> After I delete packages, especially pkg_delete -X, I get a long list
> of instructions like:
I have thought this before and it seems like a good idea to me. Patches
welcome, from my perspective.
> -2.1.3 ---
> You should also run rm -rf /etc/cups/*.conf.O /v
Lawrence Teo wrote:
> On Wed, Mar 23, 2016 at 08:42:09PM -0400, Lawrence Teo wrote:
> > ssdeep is a fuzzy hashing program and library that is useful for finding
> > almost identical files.
> >
> > From pkg/DESCR:
> > "ssdeep is a program for computing context triggered piecewise hashes
> > (CTPH)
Stuart Henderson wrote:
> On 2016/03/15 22:11, Michael McConville wrote:
> > I was trying to port GNU Complexity, but our autogen version is too
> > old. Below is an initial patch to update it. I've been planning to
> > run it through a bulk build, but my build
I recently cleared the distfiles directory on my bulk build machine and
noticed that img2pdf was failing. I talked to upstream, who said he
recently switched packages for GitLab. He suggested the below approach,
which works for me.
The old WRKDIST is present but empty in the new archive, so I chan
Sevan Janiyan wrote:
> net/quagga - CVE-2016-2342
> devel/pcre - CVE-2016-3191
Looks like PCRE 8.39 isn't being mirrored yet. Should we patch manually?
That looks like a pretty serious vulnerability:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-3191
Is this a problem with my build environment or the port? My dpb
configuration is pretty standard.
>>> Building on localhost under games/dopewars
BDEPENDS =
[devel/gettext;converters/libiconv;devel/gettext-tools;x11/gtk+2;devel/glib2]
DIST = [games/dopewars:dopewars-1.5.12.tar.g
Stuart Henderson wrote:
> As mentioned elsewhere but wanted to get it on ports@ as well, a few
> other programs have a soft dependency on metamail, mostly newsreaders
> (tin, slrn and emacs gnus can optionally uae it). And it may be used
> in some local scripts for encoding MIME messages, there are
Jeremie Courreges-Anglas wrote:
>
> Looks fine to me except:
>
> 1. pkg_info says
>
> Comment:
> tool to analyse
> [...]
>
> Escaping the # is enough:
> COMMENT= tool to analyse \#includes in C and C++ source files
>
> 2. python interpreter:
>
> Better use "MODPY_ADJ_FILES = fix_includes
Michael McConville wrote:
> Marc Espie wrote:
> > On Wed, Mar 16, 2016 at 07:48:53PM +0100, Andreas Kusalananda Kähäri wrote:
> > > Hi,
> > >
> > > I'm building my ports with MAKE_JOBS=4, and I noticed that a few of the
> > > ports were failing.
Joerg Jung wrote:
> On Sun, Mar 20, 2016 at 12:06:55AM +0100, Jeremie Courreges-Anglas wrote:
> > Christian Weisgerber writes:
> >
> > > On 2016-03-09, Christian Weisgerber wrote:
> > >
> > >> I propose to delete audio/rplay.
> > >
> > > sthen@ pointed out that x11/fvwm95 depends on this. That
d
To: Michael McConville
CC: hylafax-de...@hylafax.org
Subject: Re: [hylafax-devel] Metamail dependency
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110
Thunderbird/17.0.2
On 03/18/2016 10:11 AM, Michael McConville wrote:
> Have you guys considered replacing metamail as a de
attila wrote:
> The attached patch brings textproc/multimarkdown up to the latest
> release (5.1.0). It ditches a bunch of patches, some of which are no
> longer necessary and some of which I tried and failed to sell to the
> upstream.
Do you think any of these patches are worth keeping around re
The code has been apparently sat untouched since 1999, and it's a
networked client/server pair. If people think I'm being too aggressive
with my deletion suggestions, let me know. However, I doubt that code
left unmaintained for this long is secure to run networked in 2016.
Thoughts?
Gregor Best wrote:
> On Wed, Mar 16, 2016 at 12:04:31AM -0400, Michael McConville wrote:
> > Michael McConville wrote:
> > > For some reason, it picks up guile if available and uses it even if
> > > guile2 (which is the only one that works here) is installed. I didn
Marc Espie wrote:
> On Wed, Mar 16, 2016 at 07:48:53PM +0100, Andreas Kusalananda Kähäri wrote:
> > Hi,
> >
> > I'm building my ports with MAKE_JOBS=4, and I noticed that a few of the
> > ports were failing.
> >
> > * devel/boehm-gcfailed sometimes (can't find "libgc.la" towards the
> >
Jiri B wrote:
> I'm working on to make grub2 work on OpenBSD to replace
> pxelinux on my netinstall server and I have this question -
> - why is there 'ONLY_FOR_ARCHS= i386' in our old grub?
Try building. You get the following during configure:
> checking whether the C compiler works... configure
It's an authentication server daemon and it's code was last touched in
2000. My cursory Internet research suggests that RADIUS has mostly
replaced it. The HOMEPAGE is down. Does anyone still use this?
I won't be so long-winded on this one, but basically:
o it has patches removing gets(3)
o it hasn't been updated since 1997
o the source files are timestamped 1993-94
o it's obviously exposed to untrusted data (and MIME data at that)
Any objections for removing it?
Joerg Jung wrote:
> > Our port is probably still vulnerable to CVE-2006-0709:
> >
> > https://security-tracker.debian.org/tracker/CVE-2006-0709
> >
> > https://rhn.redhat.com/errata/RHSA-2006-0217.html
> >
> > There are two patches included in the Debian tickets and I can't tell
> > which was ap
Stuart Henderson wrote:
> On 2016/03/18 11:52, Michael McConville wrote:
> > It's an authentication server daemon and it's code was last touched
> > in 2000. My cursory Internet research suggests that RADIUS has
> > mostly replaced it. The HOMEPAGE is down. Does an
Rationale:
o it's been unmodified since import in 2001
o there are patches fixing a bunch of obvious dangerous buffer issues
o it's an ad-filter proxy, so it's very exposed
Any objections?
This is a 21-year-old 362-line Perl script. Do people suspect that it's
still useful? I recall seeing other port scan detectors in the ports
tree, and I suspect they're better choices...
Jaime Tarrant wrote:
> I noticed that line 583 of file:
>
> /usr/libdata/perl5/OpenBSD/PackageRepository.pm
>
> references the user _pkgfetch, however there is no such user on my
> system (-current, updated a earlier today). Should this be the _pfetch
> user instead?
>
> I tested changing it to
It's only got fixing tweaks since it was imported in 1998, nothing
depends on it, and (this is a good red flag for deletion candidates) it
still has patches removing gets(3). The source files in the tarball are
timestamped 1993-94 and the opening paragraph of the README is:
> I found this in a zip
According to the timestamps, the code has been untouched since 1993. I
don't even really understand what does, but it's some kind of telecom
extension for X Windows. Sounds obselete and probably dangerous.
Any users?
Stuart Henderson wrote:
> On 2016/03/17 21:13, Michael McConville wrote:
> > I won't be so long-winded on this one, but basically:
> >
> > o it has patches removing gets(3)
> > o it hasn't been updated since 1997
> > o the source files are timestamp
Our port is probably still vulnerable to CVE-2006-0709:
https://security-tracker.debian.org/tracker/CVE-2006-0709
https://rhn.redhat.com/errata/RHSA-2006-0217.html
There are two patches included in the Debian tickets and I can't tell
which was applied. They removed the port in 2009, so it's hard
Michael McConville wrote:
> For some reason, it picks up guile if available and uses it even if
> guile2 (which is the only one that works here) is installed. I didn't
> see a configure option to force guile2. If only guile2 is installed, it
> works as expected. What's the be
I was trying to port GNU Complexity, but our autogen version is too old.
Below is an initial patch to update it. I've been planning to run it
through a bulk build, but my build machine has been giving me issues.
I'll get to it pretty soon, but if anyone else can once it's ready, I'd
appreciate it.
Stuart Henderson wrote:
> On 2016/03/12 19:18, Florian Stinglmayr wrote:
> > This is also fixed in the patch below for irssi-otr.
> >
> > Also +1 for the irssi patch.
>
> irssi-icb, irssi-otr: fixes committed.
I'm getting the below failure in my bulk build. It's plausible that
everyone who's tes
Frederic Cambus wrote:
> Makefile has been tweaked to use MASTER_SITES instead of fetching
> source using a Git tag.
Are we sure we want this? What's the benefit? It seems simpler the way
it was.
> Index: Makefile
> ===
> RCS file: /
David Hill wrote:
> On Thu, Mar 10, 2016 at 05:22:55PM -0800, Michael McConville wrote:
> > David Hill wrote:
> > > This moves productivity/slideml to github.
> >
> > It's strange that the old HOMEPAGE is still up and doesn't mention
> > GitHub at
David Hill wrote:
> Hello -
>
> This moves productivity/slideml to github.
It's strange that the old HOMEPAGE is still up and doesn't mention
GitHub at all. Do you know if upstream has a preference about which is
used?
> Index: Makefile
> =
David Hill wrote:
> Hello -
>
> This updates sysutils/diskrescue to 0.4 and moves it to github.
> The change between 0.3 and 0.4 is the patch has been applied. :).
Makes sense, and builds for me. ok mmcc@
> Index: Makefile
> ===
> R
Karel Gardas wrote:
> This is a sign of not so correct network configuration. MICO is really
> picky about it so it should be able to resolve your host name/IP
> address. What's failing precisely in the assert above is that it's not
> able to get IP for your hostname. Can you confirm that this is t
It looks like devel/iso-codes needs libintl, although make
lib-depends-check doesn't pick it up. See the build failure below.
===> Building for iso-codes-3.66
Making all in iso_639
gmake[1]: Entering directory
'/home/dpb-wrk/iso-codes-3.66/iso-codes-3.66/iso_639'
/usr/local/bin/msgfmt --verbose
Apparently none of the sources are valid anymore. IIRC, this has been
happening since I started bulk building a couple months ago.
>>> From productivity/davical
===> Trying https://gitlab.com/davical-project/davical/repository/
/usr/bin/ftp -C -o /mnt/big/ports/distfiles/davical-1.1.3.1.tar.gz.pa
It's been failing reliably on my machine since I started bulk building a
couple months ago.
>>> Building on localhost under devel/mico
BDEPENDS = [devel/gmake]
DIST = [devel/mico:mico-2.3.13.tar.gz]
FULLPKGNAME = mico-2.3.13p0
(Junk lock failure for localhost at 1455583
Is anyone working on updates for security/libotr and
security/pidgin-otr? There were releases addressing a scary
vulnerability this morning:
https://marc.info/?l=otr-announce&m=145754687614832&w=2
If not, I probably have time to work on it tonight.
We last updated net/loudmouth in 2008. Upstream is gone, and the
following depend on it:
o net/mcabber
o net/irssi-xmpp
o net/freetalk
o lang/io (strangly)
I know that at least two of those are pretty common chat clients.
Because loudmouth is a network-exposed XMPP library, this is probably a
Any objections? lum@, its author and maintainer, doesn't develop it
anymore and thinks it should probably go.
It's probably easiest to do this before we remove mail/faces and
mail/xfaces.
ok?
Index: claws-mail/Makefile
===
RCS file: /cvs/ports/mail/claws-mail/Makefile,v
retrieving revision 1.86
diff -u -p -r1.86 Makefile
--- claws-mail/Make
ok?
It's also due for an update, if anyone uses it and has time.
Index: Makefile
===
RCS file: /cvs/ports/x11/grantlee/Makefile,v
retrieving revision 1.5
diff -u -p -r1.5 Makefile
--- Makefile15 Aug 2015 22:30:57 - 1.5
It seems unmaintained, it hasn't been updated since 2005, and the
website is gone. I don't know if this is considered acceptable for a
network client. There was Nicotine+:
http://www.nicotine-plus.org/
But that seems dead too.
Does this look good? The distfile's slightly different - otherwise, this
is straight-forward.
Our port's pretty out of date, too. If anyone's interested in updating
it, let me know. Otherwise, I may try in the next couple weeks.
Index: Makefile
===
It's implicit when GH_ACCOUNT and GH_PROJECT are set.
ok?
Index: devel/ocaml-ppx-tools/Makefile
===
RCS file: /cvs/ports/devel/ocaml-ppx-tools/Makefile,v
retrieving revision 1.2
diff -u -p -r1.2 Makefile
--- devel/ocaml-ppx-tools/Ma
Matthias Kilian wrote:
> On Sat, Feb 27, 2016 at 02:04:37AM -0500, Michael McConville wrote:
> > This port seems truly ancient - if I understand correctly, it's been on
> > version 1.6.1 since it was imported in 1997. The fact that it's a server
> > makes this l
This port seems truly ancient - if I understand correctly, it's been on
version 1.6.1 since it was imported in 1997. The fact that it's a server
makes this less tolerable. I came across it while scanning distfiles for
undefined behavior... And it has a patch that changes gets(3) to
fgets(3). What's
Michael McConville wrote:
> The only change in this release is the addition of our SSLv3 patch.
>
> ok?
jturner@ pointed out that this has to wait two weeks because it removes
a file, but ok'd otherwise.
>
The only change in this release is the addition of our SSLv3 patch.
ok?
Index: Makefile
===
RCS file: /cvs/ports/mail/imapfilter/Makefile,v
retrieving revision 1.21
diff -u -p -r1.21 Makefile
--- Makefile22 Jan 2016 00:51:24 -00
Juan Francisco Cantero Hurtado wrote:
> On Tue, Feb 16, 2016 at 06:04:29PM -0500, Michael McConville wrote:
> > Juan Francisco Cantero Hurtado wrote:
> > > I've seeing a bunch of double-free and use-after-free in htop.
> > > Please, run your tests with "MALLOC_
Juan Francisco Cantero Hurtado wrote:
> I've seeing a bunch of double-free and use-after-free in htop. Please,
> run your tests with "MALLOC_OPTIONS=CFGJU htop" and fix the code
> yourself in the upstream github repo if you can.
Hm. I've been running it with a brutal malloc.conf for more than a da
IIUC, we use a bundled version of Menhir in Coccinelle. It exists as the
tarball bundles/menhirLib/menhir-20120123.tar.gz in the Coccinelle
codebase.
Here's the relevant Makefile line:
> CONFIGURE_ARGS += --disable-menhirLib # version in ports is too new
However, the build fails for me bec
Michael McConville wrote:
> Have you guys had issues with wd(4) timeouts on macppc? It was
> happening intermittently, but I figured it was because the drive was
> old. However, I'm now experiencing it again with a brand new hard
> drive and it's making the machine unusa
1 - 100 of 185 matches
Mail list logo
