Document -D flag in pkg_info
Hi tech --
The -D flag in pkg_info is undocumented. So document it.
Please doublecheck to make sure it's correct because I'm not sure.
Also fix a whitespace error while here.
OK?
~Brian
Index: pkg_info.1
===
RCS file: /cvs/src/usr.sbin/pkg_add/pkg_info.1,v
retrieving revision 1.50
diff -u -p -r1.50 pkg_info.1
--- pkg_info.1 8 Sep 2014 01:27:55 - 1.50
+++ pkg_info.1 4 Apr 2015 14:03:38 -
@@ -25,6 +25,7 @@
.Nm pkg_info
.Bk -words
.Op Fl AaCcdfIKLMmPqRSstUv
+.Op Fl D Ar nolock
.Op Fl E Ar filename
.Op Fl e Ar pkg-name
.Op Fl l Ar str
@@ -75,6 +76,8 @@ Show certificate information for signed
Show the one-line comment field for each package.
.It Fl d
Show the long-description field for each package.
+.It Fl D Ar nolock
+Do not lock the package database during run.
.It Fl E Ar filename
Look for the package(s) that contains the given
.Ar filename .
Index: OpenBSD/PkgInfo.pm
===
RCS file: /cvs/src/usr.sbin/pkg_add/OpenBSD/PkgInfo.pm,v
retrieving revision 1.33
diff -u -p -r1.33 PkgInfo.pm
--- OpenBSD/PkgInfo.pm 18 Jul 2014 16:57:41 - 1.33
+++ OpenBSD/PkgInfo.pm 4 Apr 2015 14:03:38 -
@@ -527,7 +527,7 @@ sub parse_and_run
};
$state-{no_exports} = 1;
$state-handle_options('cCdfF:hIKLmPQ:qr:RsSUe:E:Ml:aAt',
- '[-AaCcdfIKLMmPqRSstUv] [-D nolock][-E filename] [-e pkg-name] ',
+ '[-AaCcdfIKLMmPqRSstUv] [-D nolock] [-E filename] [-e pkg-name] ',
'[-l str] [-Q query] [-r pkgspec] [pkg-name] [...]');
if ($state-opt('r')) {
Re: mg(1) segfault
On Sat, Apr 04, 2015 at 10:48:15AM -0300, Gleydson Soares wrote:
mg(1) segfault.
it is triggered as follows:
1- echo (start-kbd-macro) $HOME/.mg
2- open mg and type twice C-x (
find below the backtrace and a patch to fix.
OK?
Program received signal SIGBUS, Bus error.
definemacro (f=Variable f is not available.
) at macro.c:43
43 lp2 = lp1-l_fp;
(gdb) backtrace
#0 definemacro (f=Variable f is not available.
) at macro.c:43
#1 0x038cecf15606 in doin () at kbd.c:158
#2 0x038cecf16d4b in main (argc=Variable argc is not available.
) at main.c:188
(gdb)
? mg
? mg_segfault.diff
Index: macro.c
===
RCS file: /cvs/src/usr.bin/mg/macro.c,v
retrieving revision 1.16
diff -u -p -r1.16 macro.c
--- macro.c 19 Mar 2015 21:22:15 - 1.16
+++ macro.c 4 Apr 2015 13:45:15 -
@@ -38,7 +38,7 @@ definemacro(int f, int n)
}
/* free lines allocated for string arguments */
- if (maclhead != NULL) {
+ if (macrodef maclhead != NULL) {
for (lp1 = maclhead-l_fp; lp1 != maclhead; lp1 = lp2) {
lp2 = lp1-l_fp;
free(lp1);
No, this is obviously not correct. macrodef can't be true here, ever.
Some lines above this we have:
if (macrodef) {
ewprintf(already defining macro);
return (macrodef = FALSE);
}
--
I'm not entirely sure you are real.
mg(1) segfault
mg(1) segfault.
it is triggered as follows:
1- echo (start-kbd-macro) $HOME/.mg
2- open mg and type twice C-x (
find below the backtrace and a patch to fix.
OK?
Program received signal SIGBUS, Bus error.
definemacro (f=Variable f is not available.
) at macro.c:43
43 lp2 = lp1-l_fp;
(gdb) backtrace
#0 definemacro (f=Variable f is not available.
) at macro.c:43
#1 0x038cecf15606 in doin () at kbd.c:158
#2 0x038cecf16d4b in main (argc=Variable argc is not available.
) at main.c:188
(gdb)
? mg
? mg_segfault.diff
Index: macro.c
===
RCS file: /cvs/src/usr.bin/mg/macro.c,v
retrieving revision 1.16
diff -u -p -r1.16 macro.c
--- macro.c 19 Mar 2015 21:22:15 - 1.16
+++ macro.c 4 Apr 2015 13:45:15 -
@@ -38,7 +38,7 @@ definemacro(int f, int n)
}
/* free lines allocated for string arguments */
- if (maclhead != NULL) {
+ if (macrodef maclhead != NULL) {
for (lp1 = maclhead-l_fp; lp1 != maclhead; lp1 = lp2) {
lp2 = lp1-l_fp;
free(lp1);
Re: OpenSMTPD with fewer semicolons
On Sat, Apr 4, 2015 at 5:19 PM, Mike Burns mike+open...@mike-burns.com wrote: Running into issues with the extra semicolons in OpenSMTPD's Received header. I see that these semicolons are now removed in -portable[1]. Any reason not to get rid of them in base, too? ... - fprintf(s-ofile, \t%s\n, time_to_text(time(NULL))); + fprintf(s-ofile, ;\n\t%s\n, time_to_text(time(NULL))); The other removals are correct, but this one is wrong. A Received: header field should have exactly one (unquoted, non-comment) semicolon: before the date-time at the end of the line. To quote rfc5321: Stamp = From-domain By-domain Opt-info [CFWS] ; FWS date-time ...and there are no other explicit semicolons in the syntax. Philip Guenther
OpenSMTPD with fewer semicolons
Running into issues with the extra semicolons in OpenSMTPD's Received
header. I see that these semicolons are now removed in -portable[1]. Any
reason not to get rid of them in base, too?
[1]: https://github.com/OpenSMTPD/OpenSMTPD/pull/520
Index: usr.sbin/smtpd/smtp_session.c
===
RCS file: /cvs/src/usr.sbin/smtpd/smtp_session.c,v
retrieving revision 1.221
diff -u -p -u -r1.221 smtp_session.c
--- usr.sbin/smtpd/smtp_session.c 17 Dec 2014 15:49:23 - 1.221
+++ usr.sbin/smtpd/smtp_session.c 5 Apr 2015 00:11:06 -
@@ -654,12 +654,12 @@ smtp_session_imsg(struct mproc *p, struc
fprintf(s-ofile, Received: );
if (! (s-listener-flags F_MASK_SOURCE)) {
- fprintf(s-ofile, from %s (%s [%s]);\n\t,
+ fprintf(s-ofile, from %s (%s [%s]),
s-evp.helo,
s-hostname,
ss_to_text(s-ss));
}
- fprintf(s-ofile, by %s (%s) with %sSMTP%s%s id %08x;\n,
+ fprintf(s-ofile, \n\tby %s (%s) with %sSMTP%s%s id %08x,
s-smtpname,
SMTPD_NAME,
s-flags SF_EHLO ? E : ,
@@ -670,7 +670,7 @@ smtp_session_imsg(struct mproc *p, struc
if (s-flags SF_SECURE) {
x = SSL_get_peer_certificate(s-io.ssl);
fprintf(s-ofile,
- \tTLS version=%s cipher=%s bits=%d verify=%s;\n,
+ \n\tTLS version=%s cipher=%s bits=%d verify=%s,
SSL_get_cipher_version(s-io.ssl),
SSL_get_cipher_name(s-io.ssl),
SSL_get_cipher_bits(s-io.ssl, NULL),
@@ -680,12 +680,12 @@ smtp_session_imsg(struct mproc *p, struc
}
if (s-rcptcount == 1) {
- fprintf(s-ofile, \tfor %s@%s;\n,
+ fprintf(s-ofile, \n\tfor %s@%s,
s-evp.rcpt.user,
s-evp.rcpt.domain);
}
- fprintf(s-ofile, \t%s\n, time_to_text(time(NULL)));
+ fprintf(s-ofile, ;\n\t%s\n, time_to_text(time(NULL)));
smtp_enter_state(s, STATE_BODY);
smtp_reply(s, 354 Enter mail, end with \.\
Re: OpenSMTPD with fewer semicolons
On 2015-04-04 17.27.47 -0700, Philip Guenther wrote: On Sat, Apr 4, 2015 at 5:19 PM, Mike Burns mike+open...@mike-burns.com wrote: Running into issues with the extra semicolons in OpenSMTPD's Received header. I see that these semicolons are now removed in -portable[1]. Any reason not to get rid of them in base, too? ... - fprintf(s-ofile, \t%s\n, time_to_text(time(NULL))); + fprintf(s-ofile, ;\n\t%s\n, time_to_text(time(NULL))); The other removals are correct, but this one is wrong. A Received: header field should have exactly one (unquoted, non-comment) semicolon: before the date-time at the end of the line. To quote rfc5321: Stamp = From-domain By-domain Opt-info [CFWS] ; FWS date-time ...and there are no other explicit semicolons in the syntax. I agree with your analysis of the grammar, but I believe that is what the code is doing. That line in question is the one that puts the bare semicolon before the date-time. The newlines have been re-arranged so that the semicolon occurs at the end of the line. Or am I misunderstanding you/the RFC? -Mike
Re: OpenSMTPD with fewer semicolons
On Sat, Apr 4, 2015 at 6:03 PM, Mike Burns mike+open...@mike-burns.com wrote: ... I agree with your analysis of the grammar, but I believe that is what the code is doing. That line in question is the one that puts the bare semicolon before the date-time. The newlines have been re-arranged so that the semicolon occurs at the end of the line. Or am I misunderstanding you/the RFC? Ah, I misread the placement in the diff; you're correct, the original diff is fine and should be applied. Philip
Compiling ports tree on older architecture question
Hello tech! A friend is borrowing one of my machines to build the entire pkgsrc tree, a task that entails compiling more than 15k individual programs. This has taken 3 days, even on my modern and prepared amd64 machine! (to my surprise). This has me curious: Every OpenBSD release includes an immediately-accessible source for prebuilt binary packages, meaning a similar feat involving building an entire tree of ports must be performed. How is this handled on platforms like vax or hppa? How long does it take using ostensibly decades-old machines? Ian
Re: sys/stat.h: visibility of fchmod and lstat
From: j...@wxcvbn.org (=?utf-8?Q?J=C3=A9r=C3=A9mie_Courr=C3=A8ges-Anglas?=) Date: Sat, 04 Apr 2015 18:35:57 +0100 Hi, just to make things clear, I have no strong opinion towards Philip's proposal. I merely had kept __BSD_VISIBLE mostly because those functions had appeared in BSD before they were standardized. Updated diff, reversing the order of the tests, but not (yet?) suppressing the __BSD_VISIBLE case. FWIW, I disagree with Philip. The __BSD_VISIBLE there is useful to remind us that these functions were present in BSD even before POSIX adopted them via System V. I've been sitting on this for too long, it would be a shame if the discussion stalled because of a detail. :) ok kettenis@ Index: stat.h === RCS file: /cvs/src/sys/sys/stat.h,v retrieving revision 1.27 diff -u -p -p -u -r1.27 stat.h --- stat.h8 Dec 2014 20:56:11 - 1.27 +++ stat.h4 Apr 2015 17:16:27 - @@ -198,6 +198,10 @@ int mkdir(const char *, mode_t); int mkfifo(const char *, mode_t); int stat(const char *, struct stat *); mode_t umask(mode_t); +#if __POSIX_VISIBLE = 200112L || __XPG_VISIBLE = 420 || __BSD_VISIBLE +int fchmod(int, mode_t); +int lstat(const char *, struct stat *); +#endif #if __POSIX_VISIBLE = 200809 int fchmodat(int, const char *, mode_t, int); int fstatat(int, const char *, struct stat *, int); @@ -211,8 +215,6 @@ int futimens(int, const struct timespec int chflags(const char *, unsigned int); int chflagsat(int, const char *, unsigned int, int); int fchflags(int, unsigned int); -int fchmod(int, mode_t); -int lstat(const char *, struct stat *); int isfdtype(int, int); #endif __END_DECLS -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: sys/stat.h: visibility of fchmod and lstat
On Sat, Apr 4, 2015 at 10:35 AM, Jérémie Courrèges-Anglas j...@wxcvbn.org wrote: just to make things clear, I have no strong opinion towards Philip's proposal. I merely had kept __BSD_VISIBLE mostly because those functions had appeared in BSD before they were standardized. Updated diff, reversing the order of the tests, but not (yet?) suppressing the __BSD_VISIBLE case. I've been sitting on this for too long, it would be a shame if the discussion stalled because of a detail. :) Sure, get it in. I'll run my crusade when todd's busy elsewhere... hehehhe
Re: const char *swapfile in kvm_open(3)
On Sat, Apr 4, 2015 at 11:31 AM, Jérémie Courrèges-Anglas j...@wxcvbn.org wrote: Here's some nitpicking. Matching the .h good. ok guenther@
const char *swapfile in kvm_open(3)
Here's some nitpicking. Index: kvm_open.3 === RCS file: /cvs/src/lib/libkvm/kvm_open.3,v retrieving revision 1.17 diff -u -p -r1.17 kvm_open.3 --- kvm_open.3 21 Jan 2014 03:15:45 - 1.17 +++ kvm_open.3 4 Apr 2015 18:29:25 - @@ -46,9 +46,9 @@ .In fcntl.h .In kvm.h .Ft kvm_t * -.Fn kvm_open const char *execfile const char *corefile char *swapfile int flags const char *errstr +.Fn kvm_open const char *execfile const char *corefile const char *swapfile int flags const char *errstr .Ft kvm_t * -.Fn kvm_openfiles const char *execfile const char *corefile char *swapfile int flags char *errbuf +.Fn kvm_openfiles const char *execfile const char *corefile const char *swapfile int flags char *errbuf .Ft int .Fn kvm_close kvm_t *kd .Sh DESCRIPTION -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: sys/stat.h: visibility of fchmod and lstat
Hi, just to make things clear, I have no strong opinion towards Philip's proposal. I merely had kept __BSD_VISIBLE mostly because those functions had appeared in BSD before they were standardized. Updated diff, reversing the order of the tests, but not (yet?) suppressing the __BSD_VISIBLE case. I've been sitting on this for too long, it would be a shame if the discussion stalled because of a detail. :) Index: stat.h === RCS file: /cvs/src/sys/sys/stat.h,v retrieving revision 1.27 diff -u -p -p -u -r1.27 stat.h --- stat.h 8 Dec 2014 20:56:11 - 1.27 +++ stat.h 4 Apr 2015 17:16:27 - @@ -198,6 +198,10 @@ intmkdir(const char *, mode_t); intmkfifo(const char *, mode_t); intstat(const char *, struct stat *); mode_t umask(mode_t); +#if __POSIX_VISIBLE = 200112L || __XPG_VISIBLE = 420 || __BSD_VISIBLE +intfchmod(int, mode_t); +intlstat(const char *, struct stat *); +#endif #if __POSIX_VISIBLE = 200809 intfchmodat(int, const char *, mode_t, int); intfstatat(int, const char *, struct stat *, int); @@ -211,8 +215,6 @@ int futimens(int, const struct timespec intchflags(const char *, unsigned int); intchflagsat(int, const char *, unsigned int, int); intfchflags(int, unsigned int); -intfchmod(int, mode_t); -intlstat(const char *, struct stat *); intisfdtype(int, int); #endif __END_DECLS -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: mg(1) segfault
return (macrodef = FALSE);
but we shouldn't change macrodef here.
? mg
? mg_segfault.diff
? v2_mg_segfault.diff
Index: macro.c
===
RCS file: /cvs/src/usr.bin/mg/macro.c,v
retrieving revision 1.16
diff -u -p -u -p -r1.16 macro.c
--- macro.c 19 Mar 2015 21:22:15 - 1.16
+++ macro.c 4 Apr 2015 16:09:38 -
@@ -34,11 +34,11 @@ definemacro(int f, int n)
if (macrodef) {
ewprintf(already defining macro);
- return (macrodef = FALSE);
+ return (FALSE);
}
/* free lines allocated for string arguments */
- if (maclhead != NULL) {
+ if (macrodef maclhead != NULL) {
for (lp1 = maclhead-l_fp; lp1 != maclhead; lp1 = lp2) {
lp2 = lp1-l_fp;
free(lp1);
Re: mg(1) segfault
On Sat, 4 Apr 2015 15:23:45 -0300 Gleydson Soares gsoa...@gmail.com wrote: but we shouldn't change macrodef here. Regardless of whether macrodef is being changed, you're still returning if macrodef is true, so there is no way for it to be true at the point where you're adding a test for it.
Re: mg(1) segfault
On Sat, Apr 04, 2015 at 03:23:45PM -0300, Gleydson Soares wrote:
return (macrodef = FALSE);
but we shouldn't change macrodef here.
I hate the startup file.
Look, this is a use after free, but I can't find it...
#0 0x1b9de0b1b77f in definemacro (f=0, n=1)
at /usr/src/usr.bin/mg/macro.c:43
43 lp2 = lp1-l_fp;
(gdb) p *maclhead
$1 = {l_fp = 0xdfdfdfdfdfdfdfdf, l_bp = 0xdfdfdfdfdfdfdfdf,
l_size = -538976289, l_used = -538976289,
l_text = 0xdfdfdfdfdfdfdfdf Address 0xdfdfdfdfdfdfdfdf out of bounds}
also: what Steven McDonald says
? mg
? mg_segfault.diff
? v2_mg_segfault.diff
Index: macro.c
===
RCS file: /cvs/src/usr.bin/mg/macro.c,v
retrieving revision 1.16
diff -u -p -u -p -r1.16 macro.c
--- macro.c 19 Mar 2015 21:22:15 - 1.16
+++ macro.c 4 Apr 2015 16:09:38 -
@@ -34,11 +34,11 @@ definemacro(int f, int n)
if (macrodef) {
ewprintf(already defining macro);
- return (macrodef = FALSE);
+ return (FALSE);
}
/* free lines allocated for string arguments */
- if (maclhead != NULL) {
+ if (macrodef maclhead != NULL) {
for (lp1 = maclhead-l_fp; lp1 != maclhead; lp1 = lp2) {
lp2 = lp1-l_fp;
free(lp1);
--
I'm not entirely sure you are real.
Re: [PATCH] bsd.port.mk - make relation between GH_TAGNAME GH_COMMIT more apparent (prevent actual bug regression)
On Sat, Apr 4, 2015, at 11:27 PM, Landry Breuil wrote:
On Sat, Apr 04, 2015 at 11:07:11PM +0200, Adam Wolk wrote:
Hi tech@
I'm the maintainer of www/otter-browser and I got caught while packaging
otter-browser 0.9.04. Upstream asked us to point at a different commit
then the tagged revision so we did:
GH_TAGNAME = v0.9.04
# This is the actual tagged revision
# GH_COMMIT = 869d29d19719b3057e137a79d4a10025d2c920f6
# but we were asked by upstream to release from the following commit
# as it's considered an important fix affecting the majority of users
GH_COMMIT =23d7ee6f9cd636e750687a01975b177c1c9c2e53
This port was reviewed with an ok by two people and underwent further
changes later on.
I didn't notice that the port actually packaged GH_TAGNAME contents
instead of GH_COMMIT.
GH_COMMIT is meaningless in terms of package version, which expects a
correctly structured version, hence GH_TAGNAME being usually used in
combination with GH_PROJECT.
Look, you even set it yourself for otter-browser:
DISTNAME = ${GH_PROJECT}-${GH_TAGNAME:C/^v//}
(and PKGNAME is derived from DISTNAME)
Here, since you go forward in git history, you have the choice of
bumping REVISION, or using .MMDD suffixes, or using the special
'pre' / 'rc' / 'beta' keywords in the version, see packages-specs(7).
S i'm not sure the documentation is at fault here :)
Landry
Yep, my fault. I should have tested this earlier.
ser/archive/v0.9.05/1ea5df13f908495df4ad9d634d997f6fd4c9.tar.gz
Trying 192.30.252.128...
Requesting
https://github.com/OtterBrowser/otter-browser/archive/v0.9.05/1ea5df13f908495df4a
d9d634d997f6fd4c9.tar.gz
Redirected to
https://codeload.github.com/OtterBrowser/otter-browser/tar.gz/v0.9.05
Trying 192.30.252.144...
Requesting
https://codeload.github.com/OtterBrowser/otter-browser/tar.gz/v0.9.05
100%
|**|
2248 KB00:05
2302624 bytes received in 5.65 seconds (398.11 KB/s)
So github redirects to the tag even though the ports system just shows a
download
=== Checking files for otter-browser-0.9.05
Fetch
https://github.com/OtterBrowser/otter-browser/archive/v0.9.05/1ea5df13f908495df4ad9d634d997f6fd4c9.tar.gz
I should pay more attention to what's going on during port building.
Feel free to ignore the
patch thanks for feedback ;)
Regards,
Adam
[PATCH] bsd.port.mk - make relation between GH_TAGNAME GH_COMMIT more apparent (prevent actual bug regression)
Hi tech@
I'm the maintainer of www/otter-browser and I got caught while packaging
otter-browser 0.9.04. Upstream asked us to point at a different commit
then the tagged revision so we did:
GH_TAGNAME = v0.9.04
# This is the actual tagged revision
# GH_COMMIT = 869d29d19719b3057e137a79d4a10025d2c920f6
# but we were asked by upstream to release from the following commit
# as it's considered an important fix affecting the majority of users
GH_COMMIT =23d7ee6f9cd636e750687a01975b177c1c9c2e53
This port was reviewed with an ok by two people and underwent further
changes later on.
I didn't notice that the port actually packaged GH_TAGNAME contents
instead of GH_COMMIT.
Current documentation for both tags are as follows:
GH_COMMIT SHA1 commit id to fetch. It is good practice to
always
specify the commit id, even if ${GH_TAGNAME} was
specified.
GH_TAGNAMEName of the tag to download. Setting ${GH_TAGNAME}
to
master is invalid and will throw an error.
${WRKDIST} is
auto-generated based on the ${GH_TAGNAME} if
specified,
otherwise ${GH_COMMIT} will be used to generate
${WRKDIST}.
I would like to suggest a small alteration to GH_COMMIT to point out
that
GH_TAGNAME takes precedence even if they point at different changeset.
The ports system doesn't warn about that situation and I almost got
caught
by it twice since upstream again asks us to package a couple of
revisions
ahead of the tagged version.
Regards,
Adam
Index: bsd.port.mk.5
===
RCS file: /cvs/src/share/man/man5/bsd.port.mk.5,v
retrieving revision 1.415
diff -u -p -r1.415 bsd.port.mk.5
--- bsd.port.mk.5 3 Apr 2015 10:19:22 - 1.415
+++ bsd.port.mk.5 4 Apr 2015 20:58:59 -
@@ -1703,6 +1703,7 @@ Account name of the GitHub user hosting
SHA1 commit id to fetch.
It is good practice to always specify
the commit id, even if ${GH_TAGNAME} was specified.
+${GH_TAGNAME} takes precedence even if ${GH_COMMIT} points at a
different changeset.
.It Ev GH_PROJECT
Name of the project on GitHub.
.It Ev GH_TAGNAME
Re: [PATCH] bsd.port.mk - make relation between GH_TAGNAME GH_COMMIT more apparent (prevent actual bug regression)
On Sat, Apr 04, 2015 at 11:07:11PM +0200, Adam Wolk wrote:
Hi tech@
I'm the maintainer of www/otter-browser and I got caught while packaging
otter-browser 0.9.04. Upstream asked us to point at a different commit
then the tagged revision so we did:
GH_TAGNAME = v0.9.04
# This is the actual tagged revision
# GH_COMMIT = 869d29d19719b3057e137a79d4a10025d2c920f6
# but we were asked by upstream to release from the following commit
# as it's considered an important fix affecting the majority of users
GH_COMMIT =23d7ee6f9cd636e750687a01975b177c1c9c2e53
This port was reviewed with an ok by two people and underwent further
changes later on.
I didn't notice that the port actually packaged GH_TAGNAME contents
instead of GH_COMMIT.
GH_COMMIT is meaningless in terms of package version, which expects a
correctly structured version, hence GH_TAGNAME being usually used in
combination with GH_PROJECT.
Look, you even set it yourself for otter-browser:
DISTNAME = ${GH_PROJECT}-${GH_TAGNAME:C/^v//}
(and PKGNAME is derived from DISTNAME)
Here, since you go forward in git history, you have the choice of
bumping REVISION, or using .MMDD suffixes, or using the special
'pre' / 'rc' / 'beta' keywords in the version, see packages-specs(7).
S i'm not sure the documentation is at fault here :)
Landry
Perl 5.20.2 testing for inclusion in base
I've updated OpenBSD patches for perl-5.20.2 and would like to get some additional testing before seeing about importing it. I've been able to run tests on alpha, amd64, armv7, macppc, and sparc64 and should be able to try vax shortly. I'd appreciate any other architectures you can try. As usual, the instructions for testing are on github: https://github.com/afresh1/OpenBSD-perl * download the patches: https://github.com/afresh1/OpenBSD-perl/archive/master.tar.gz * Extract them, and download perl into the extracted directory: https://cpan.metacpan.org/authors/id/S/SH/SHAY/perl-5.20.2.tar.gz * Then from someplace you have room (a couple hundred megs) * run /path/to/OpenBSD-perl/build_perl * And send me the log file(s) it generates. Primarily changes were to documentation, but several reliability fixes as well, nothing that particularly stands out, mostly crashes on bad input and memory leaks. https://metacpan.org/pod/distribution/perl/pod/perldelta.pod I am a fan of the new Perl Unicode Cookbook https://metacpan.org/pod/perlunicook On a related note, I will be talking about Perl in OpenBSD at YAPC::NA in Salt Lake City, UT, USA in June, come, learn perl things. http://www.yapcna.org/yn2015/
