Creating patch files, skip post-patch

Dear all, I have some ports I maintain and in some of them I have post-patch-{{OPTION}}-on Makefile targets in that is patching files. But to update the files I need a file where only the patches from files/patch-* are applied. Is there a possibility to skip the post-patch target from the

Re: Creating patch files, skip post-patch

Matthias Fechner writes: > Dear all, > > I have some ports I maintain and in some of them I have > post-patch-{{OPTION}}-on Makefile targets in that is patching files. > But to update the files I need a file where only the patches from > files/patch-* are applied. > > Is

Re: Thanks!

On Mon, Jan 1, 2018 at 7:52 PM, George Mitchell wrote: > On 01/01/18 13:33, Jos Chrispijn wrote: >> I would like to thank all programmers and port maintainers for their >> excellent work in 2017. >> Without you we would never enjoy BSD as we do until this very day. >> >> I

Re: Creating patch files, skip post-patch

Am 02.01.2018 um 10:19 schrieb Jan Beich: > Try do-patch e.g., > > $ make clean extract do-patch makepatch EXTRA_PATCHES= BATCH= thanks a lot Jan! Gruß Matthias -- "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the

Re: Ports with binary bootstrap packages and CURRENT+ino64

Anthony Jenkins writes: > (gdb) where > #0 stat () at freebsd11_stat.S:3 > #1 0x016a94a0 in std::sys::imp::fs::stat () at > /checkout/src/libstd/sys/unix/fs.rs:732 > #2 0x016a1a76 in std::fs::metadata<::path::Path> () at > /checkout/src/libstd/fs.rs:1271 > #3

Re: I've started getting ^@^@> in my xterms w/mutt

Hi! > I recently updated my system (base OS and ports) that I read mail on using > mutt (accessed via an xterm on a separate system) and am now seeing this sort > of character string ^@^@> rather than the much more user friently characters I > used to get. > > Anyone know what I can do to get

Re: lang/ghc -8.0.2_2 mismatched checksums

On Tue, Jan 2, 2018 at 4:42 AM, Mike Clarke wrote: > > My daily periodic security run comes up with with these errors: > > Checking for packages with mismatched checksums: > ghc-8.0.2_2: /usr/local/bin/haddock > ghc-8.0.2_2:

mail/phpmailer abandoned?

Is the ports maintainer in charge of mail/phpmailer no longer updating it? I've sent 2 emails a couple months ago and heard nothing back. Also, I submitted a bug report stating an update is needed - and that is now collecting dust. PHPMailer 5.2.26 was released on November 4th. Also, the new

DEFAULT_VERSIONS conflicts

Per the 20171214 UPDATING entry: Support for some deprecated variables is going to be removed soon. If you use any of the following constructs (usually in /etc/make.conf), you must switch to the new incantations: ... WITH_OPENSSL_BASE DEFAULT_VERSIONS+= ssl=base

lang/ghc -8.0.2_2 mismatched checksums

My daily periodic security run comes up with with these errors: Checking for packages with mismatched checksums: ghc-8.0.2_2: /usr/local/bin/haddock ghc-8.0.2_2: /usr/local/lib/ghc-8.0.2/package.conf.d/package.cache ghc-8.0.2_2: /usr/local/share/doc/ghc-8.0.2/html/libraries/doc-index-33.html

Re: mail/mutt && security/gnupg (after gnupg20 -> gnupg) weirdness

I *think* the issue is that I needed to update ~/.muttrc for the change in gnupg; in particular: set pgp_decrypt_command="gpg --keyserver pgp.mit.edu --passphrase-fd 0 --no-verbose --batch -o - %f" was changed to set pgp_decrypt_command="gpg2 %?p?--passphrase-fd 0 --pinentry-mode=loopback?

Re: DEFAULT_VERSIONS conflicts

Sorry, the language there is unclear. It should say "ssl=[name of the port]". You just want the ssl=libressl line. Ah, so the "base" specified here is a constant whereas "port" is a variable, to be expanded before writing make.conf. If I might then suggest a potential documentation update: <

mail/mutt && security/gnupg (after gnupg20 -> gnupg) weirdness

I have been using mail/mutt & security/gnupg (latter switched to security/gnupg20 back when gnupg20 port was created because of a similar-looking issue to what's described in the first part of the below narrative) for several years -- without enabling "gpgme" (in case that turns out to be

Re: DEFAULT_VERSIONS conflicts

On 2 Jan, 2018, at 10:47, Roger Marquis wrote: Per the 20171214 UPDATING entry: Support for some deprecated variables is going to be removed soon. If you use any of the following constructs (usually in /etc/make.conf), you must switch to the new incantations: ...

I've started getting ^@^@> in my xterms w/mutt

I recently updated my system (base OS and ports) that I read mail on using mutt (accessed via an xterm on a separate system) and am now seeing this sort of character string ^@^@> rather than the much more user friently characters I used to get. Anyone know what I can do to get back the more