Re: editors/vim, editors/vim-lite maintainership request
On 12/2/13 2:02 PM, Mikhail Tsatsenko wrote: As I can see maintainer of vim vim-lite ports is just reset, so I want to maintain them. It looks like you're too late by minutes. https://svnweb.freebsd.org/ports?view=revisionrevision=335535 But there's good news too! https://svnweb.freebsd.org/ports?view=revisionrevision=335537 -- neirbowj signature.asc Description: OpenPGP digital signature
Trouble verifying a pkg-repo signature manually
Hello freebsd-ports@, I'm trying to build and maintain my own package repository and understand how everything is put together in the process. Right now, I'm having trouble understanding how the signatures are made and verified. The following should illustrate both the problem I'm having and how I think things are supposed to work. My environment -- # pkg -v 1.2.6 # openssl version OpenSSL 0.9.8y 5 Feb 2013 # uname -a FreeBSD .saltant.net 9.2-STABLE FreeBSD 9.2-STABLE #1 r260112: Mon Dec 30 18:26:07 EST 2013 r...@.saltant.net:/usr/obj/usr/src/sys/NARB amd64 Build a package --- # cd /usr/ports/devel/pkgconf # make PACKAGES=/tmp/packages package [...] === Building package for pkgconf-0.9.4 # ls -lR /tmp/packages total 4 drwxr-xr-x 2 root wheel 512 Feb 8 18:32 All /tmp/packages/All: total 24 -rw-r--r-- 1 root wheel 23488 Feb 8 18:32 pkgconf-0.9.4.txz Prepare the keys # cd /tmp/keys # openssl genrsa -out repo.key 2048 Generating RSA private key, 2048 bit long modulus +++ ...+++ e is 65537 (0x10001) # openssl rsa -in repo.key -pubout repo.pub writing RSA key Generate the repo - # pkg repo /tmp/packages /tmp/keys/repo.key Generating repository catalog in /tmp/packages: done! Testing the signature - # cd /tmp/test # tar xf /tmp/packages/digests.txz # openssl dgst -verify /tmp/keys/repo.pub \ -signature signature -sha256 digests Verification Failure Making and testing a new signature -- # openssl dgst -sign /tmp/repo.key -sha256 -binary digests test_sig # openssl dgst -verify /tmp/keys/repo.pub \ -signature test_sig -sha256 digests Verified OK I would be grateful if somebody could point me in the right direction, or disabuse me of some obvious misconception. Regards, John signature.asc Description: OpenPGP digital signature
Re: Trouble verifying a pkg-repo signature manually
On 2/8/14 6:50 PM, John W. O'Brien wrote: Hello freebsd-ports@, I'm trying to build and maintain my own package repository and understand how everything is put together in the process. Right now, I'm having trouble understanding how the signatures are made and verified. The following should illustrate both the problem I'm having and how I think things are supposed to work. [...] Testing the signature - # cd /tmp/test # tar xf /tmp/packages/digests.txz # openssl dgst -verify /tmp/keys/repo.pub \ -signature signature -sha256 digests Verification Failure [...] I think I found out why this doesn't work. Inside pkg-repo(8), the code that actually generates the signature [0], signs an ASCII-encoded, zero-terminated [1] representation of the SHA256 digest. I would guess that inside openssl dgst ... -sha256 ... the signature generation and verification are operating on a SHA256 blob (i.e. unterminated binary). So, the next best way I've come up with to verify a repo by hand is this: # openssl rsautl -pubin -inkey /tmp/keys/repo.pub \ -verify -in test_sig -asn1parse 0:d=0 hl=2 l= 49 cons: SEQUENCE 2:d=1 hl=2 l= 13 cons: SEQUENCE 4:d=2 hl=2 l= 9 prim: OBJECT:sha256 15:d=2 hl=2 l= 0 prim: NULL 17:d=1 hl=2 l= 32 prim: OCTET STRING - 7d b0 d6 38 8c 0f 28 53-2a 76 40 4f d6 84 8f 24 }..8..(S*v@O...$ 0010 - e5 0a a1 57 45 ec f1 31-14 aa d0 4c 9a d0 fc 17 ...WE..1...L # sha256 -q digests 7db0d6388c0f28532a76404fd6848f24e50aa15745ecf13114aad04c9ad0fc17 I just visually compare the OCTET STRING to the digest. [0] rsa_sign() https://github.com/freebsd/pkg/blob/master/libpkg/rsa.c#L175 [2] sha256_hash() https://github.com/freebsd/pkg/blob/master/libpkg/utils.c#L343 signature.asc Description: OpenPGP digital signature
Redport builds are all finished without logs
Hello decke, Could you help me understand what's going on with this build [0]? Did an admin kill the job, and if so, why? Otherwise, what happened and is it because I'm doing something wrong? Thank you, John [0] https://redports.org/buildarchive/20140210032800-24135/ signature.asc Description: OpenPGP digital signature
Re: Redport builds are all finished without logs
On 2/10/14 9:52 AM, John W. O'Brien wrote: Could you help me understand what's going on with this build [0]? Did an admin kill the job, and if so, why? Otherwise, what happened and is it because I'm doing something wrong? [0] https://redports.org/buildarchive/20140210032800-24135/ Continuing to troubleshoot this. I've been adding ports to TEST_DEPENDS one by one, and found an instance where the /before/ [1] works but the /after/ [2] does not. The implicated port is math/py-statsmodels (maintainer CC'd). I'm still not clear on the circumstances under which Redports winds up in the finished state, and consequently am unable to avoid it or work around it. Any help or advice would be appreciated. Thank you, John [1] https://redports.org/buildarchive/20140215154500-1493/ [2] https://redports.org/buildarchive/20140215163200-621/ signature.asc Description: OpenPGP digital signature
Re: Redport builds are all finished without logs
On 2/15/14 12:53 PM, John W. O'Brien wrote: On 2/10/14 9:52 AM, John W. O'Brien wrote: Could you help me understand what's going on with this build [0]? Did an admin kill the job, and if so, why? Otherwise, what happened and is it because I'm doing something wrong? [0] https://redports.org/buildarchive/20140210032800-24135/ Continuing to troubleshoot this. I've been adding ports to TEST_DEPENDS one by one, and found an instance where the /before/ [1] works but the /after/ [2] does not. The implicated port is math/py-statsmodels (maintainer CC'd). I'm still not clear on the circumstances under which Redports winds up in the finished state, and consequently am unable to avoid it or work around it. Any help or advice would be appreciated. [1] https://redports.org/buildarchive/20140215154500-1493/ [2] https://redports.org/buildarchive/20140215163200-621/ I see the problem. math/py-statsmodels depends on math/py-pandas. So the bad news is that I cannot include the former in TEST_DEPENDS for the latter and expect much at all from Redports. The good news is that I can now fix my port to be more readily testable. For the benefit of those who come after, would it make sense to augment the description of the finished state [3] to mention the possibility of circular dependencies, which don't appear to be covered by the other detectable termination conditions? Regards, John [3] https://redports.org/wiki/Buildstatus signature.asc Description: OpenPGP digital signature
Re: [CFT+BRAINSTORM] One USE_ to rule them all
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/07/2013 04:52 AM, Baptiste Daroussin wrote: Let's go for USES then! regards, Bapt Clearly I'm a bit late to the party here, and I don't wish to reopen litigation of this particular design choice. However, I would like to respectfully suggest that, in addition to the grep-ability of a keyword, it is useful to inform selection on the basis of whether it is to be used in a declarative or imperative sense. The on-its-way-out USE_BLAH is imperative, whereas USES has a declarative flavor. In cases where the purpose is to tell the ports machinery to *do* something, I favor the imperative where it can be applied naturally. The declarative---statements of fact---are dandy for things like CONFLICTS, HAS_CONFIGURE, and PORTNAME. Consider this notional capability, BLAH, that is available from ports or even base, but which some ports bring with them (think libz or the client library for some protocol). If port X has its own BLAH, then USES=BLAH is a true statement but an erroneous usage in the context of port X. This is why USE would be better. In any case, thank you for embarking on this valuable consolidation. Cheers, John -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBAgAGBQJRF/LsAAoJEEdKvTwaez9w7/UH/jsInJF7A99LbFwPFxIlNwV1 hGDN7kZATxs55wfbk8q+EndQkXuwcQebOVQUO5GT+xOCvj8GLR9odEtDff21vjnc RnfpTzDXI+ynL/oX/rmibqTkUdb7Srd9iXhpxD4dAudIkmNA2XA6LInOhRdEcUq3 d/7n84ZppE22ia+tpfIFqGnDpwO4bPB3l/1gwy8MqQhXwodwHQiREHkevWmlA8S+ xdqpVm2byOXF+nlSmf/k8N1SOVWc9VErEaine9wM9+Cz7StuTRENiWe3gDyh3GMp L/292a1roKZM/bM5GhsJSB2Vl22V7dk+q8+szTxjOQr4uWa4mhiJ3DexO04PdsU= =SBg1 -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Discover stored options different from port defaults/defines
Hello ports@,
In the bad old days before poudriere and various improvements to
OptionsNG came to town, when I was using portmaster* to handle upgrades,
I cobbled together a configuration management practice that involved
using rsync and git to store /var/db/ports in a repository. The usual
workflow looked roughly like this:
svn up /usr/ports
portmaster -dga
# handle changes to OPTIONS_DEFINE and its brethren here
rsync -rpt --del --exclude distfiles /var/db/ports/ /path/to/repo
cd /path/to/repo
git commit -a -m Store options that changed
A downside of this approach is that it couldn't distinguish between
options I care about (Always do this and Never do this) and options
I don't care about (Do what the maintainer thinks is best). The only
upstream changes that would bubble to the surface of their own accord
were NEW_OPTIONS when OPTIONS_DEFINE changed.
When I switched from portmaster to poudriere+pkgng, I migrated
/var/db/ports to /usr/local/etc/poudriere.d/$jail-$ports-$set-options
and that worked OK for a little while. However, this compounded the old
problem in that now even NEW_OPTIONS would arrive silently.
The first part of my solution to these problems is to store only the
options that I know I care about. That is, I know I need to find out
where a stored option disagrees with the default.
I couldn't figure out how to use the stock tools to peel apart currently
stored options from current default options, so I wrote a
``nondefaultconfig`` target for Mk/bsd.port.mk (see attached), set all
the common options (DOCS, IPv6, etc) explicitly in /etc/make.conf using
OPTIONS_SET/OPTIONS_UNSET, and ran the new target against all of my
installed ports, replacing a subtree full of options files with a
single, quite modest make.conf. To make this more generally-useful, it
would need to behave more like NEW_OPTIONS.
cd /usr/ports
pkg info -aoq | sort | xargs -n1 make nondefaultconfig -C \
/usr/local/etc/poudriere.d/$jail-make.conf
rm -fr /usr/local/etc/poudriere.d/$jail-$ports-$set-options
At this point, any option not configured by $jail-make.conf will be
allowed to vary according to the whims of the maintainer. The next part
of the problem that I would like to solve is learning about options that
I don't yet know I care about (OPTIONS_DEFINE gains a member), and
secondarily to learn when an option is past caring (OPTIONS_DEFINE loses
a member that I used to care about), so that I can update
$jail-make.conf in an orderly fashion.
I welcome any comments on my approach so far, or suggestions about how I
might proceed.
Regards,
John
* Made the bad old days less bad.
Index: Mk/bsd.port.mk
===
--- Mk/bsd.port.mk (revision 349597)
+++ Mk/bsd.port.mk (working copy)
@@ -6060,6 +6060,27 @@
.endif
.endif # config-conditional
+NONDEFAULT_OPTIONS_SET=
+NONDEFAULT_OPTIONS_UNSET=
+.for opt in ${ALL_OPTIONS}
+. if empty(OPTIONS_DEFAULT:M${opt}) !empty(PORT_OPTIONS:M${opt})
empty(OPTIONS_SET:M${opt})
+NONDEFAULT_OPTIONS_SET+=${opt}
+. endif
+. if !empty(OPTIONS_DEFAULT:M${opt}) empty(PORT_OPTIONS:M${opt})
empty(OPTIONS_UNSET:M${opt})
+NONDEFAULT_OPTIONS_UNSET+=${opt}
+. endif
+.endfor
+
+.if !target(nondefaultconfig)
+nondefaultconfig:
+. if !empty(NONDEFAULT_OPTIONS_SET)
+ @${ECHO_MSG} ${OPTIONS_NAME}_SET= ${NONDEFAULT_OPTIONS_SET}
+. endif
+. if !empty(NONDEFAULT_OPTIONS_UNSET)
+ @${ECHO_MSG} ${OPTIONS_NAME}_UNSET=${NONDEFAULT_OPTIONS_UNSET}
+. endif
+.endif # nondefaultconfig
+
.if !target(showconfig)
.include ${PORTSDIR}/Mk/bsd.options.desc.mk
MULTI_EOL= : you have to choose at least one of them
signature.asc
Description: OpenPGP digital signature
Re: Discover stored options different from port defaults/defines
On 3/30/14 10:21 PM, Randy Pratt wrote: On Sun, 30 Mar 2014 17:13:15 -0400 John W. O'Brien j...@saltant.com wrote: [blah blah blah] [...] The first part of my solution to these problems is to store only the options that I know I care about. That is, I know I need to find out where a stored option disagrees with the default. I couldn't figure out how to use the stock tools to peel apart currently stored options from current default options, so I wrote a ``nondefaultconfig`` target for Mk/bsd.port.mk (see attached), set all the common options (DOCS, IPv6, etc) explicitly in /etc/make.conf using OPTIONS_SET/OPTIONS_UNSET, and ran the new target against all of my installed ports, replacing a subtree full of options files with a single, quite modest make.conf. To make this more generally-useful, it would need to behave more like NEW_OPTIONS. cd /usr/ports pkg info -aoq | sort | xargs -n1 make nondefaultconfig -C \ /usr/local/etc/poudriere.d/$jail-make.conf rm -fr /usr/local/etc/poudriere.d/$jail-$ports-$set-options [...] I found this posting useful to find OPTIONS: http://docs.freebsd.org/cgi/mid.cgi?CAOjFWZ45ACYnaByYxxrGoyqTOeS7_EDV6MwoH98-GtDe-F3Yug The mailing list archives seem to be missing for the past month PR187557 so here an excerpt from my notes: On 3/4/2014 9:40 AM, Thierry Thomas wrote: from within a port's directory, make showconfig will show you the current options set and make __MAKE_CONF=/dev/null PORT_DBDIR=/var/empty showconfig will show you the defaults. See make(1)'s -C option for specifying ports pathname. It shouldn't take too much to write a small script and find the diff in the output for each command. Randy, I like that this approach doesn't muck with /usr/ports/Mk/. I doubt I would have discovered __MAKE_CONF on my own, but now that I know to look for it, I see that it's covered early in make(1): First of all, the initial list of specifications will be read from the system makefile, sys.mk, unless inhibited with the -r option. The standard sys.mk as shipped with FreeBSD also handles make.conf(5), the default path to which can be altered via the make variable __MAKE_CONF. -John signature.asc Description: OpenPGP digital signature
Re: Discover stored options different from port defaults/defines
On 3/31/14 3:47 PM, Kevin Oberman wrote:
This is something I've wanted to have for quite a while, but never
enough to dig through the Makefiles.
I think the proper way would be for make showconfig to print out the
current config as it does now, but to tag default options (e.g. '+') so
that it would be easy to note that some option that you never touched
and probably don't really even understand had had the default changed
and you probably want to match that change.
There are two dimensions, though, and the showconfig annotations you
describe captures just one of them.
1. Is this option set the same as the default?
2. Is this an option I care about pinning?
Your proposal addresses #1. I already solved this for myself in an
ad-hoc manner. I placed an additional requirement on my solution that it
generate machine-readable output. Incidentally, there was a compelling
thread a few months ago which briefly discussed [0] the possibility of
teaching core CLI tools to output structured data like XML, JSON, etc.
The ports machinery would be another great candidate for that kind of
capability.
Anyway, I used the information from #1 as hints about what I was
thinking about #2 at the time I originally configured the port. Then I
put ${OPTIONS_NAME}_SET=FOO and ${OPTIONS_NAME}_UNSET=BAR in make.conf
as a way to express and record #2.
For example:
devel_git_SET= GITWEB GUI
editors_vim_UNSET= RUBY
I can feed this, and little else, to poudriere and remain confident that
as long as devel/git knows about the options GITWEB and GUI, and
editors/vim knows about the option RUBY, I can update my ports tree and
rebuild my packages until the sun comes up and those options will remain
pinned.
A 'pkg info' option to provide a list of changed defaults in installed
ports would be even nicer. Something equivalent to pkg version -vl\
perhaps. But just doing it in make showconfig would make a script that
would parse 'pkg version' optput and do a make showconfig, only
printing out the tagged lines, when any changes are noted would be trivial.
Would pkg-info be the place for this? It's looking at state data that
has no notion of history. pkg-info could show available options,
defaults, and built-with options, all as of build-time. It would be up
to pkg-upgrade to send up a flare, on request, if these sets changed
from the currently-installed package to the about-to-be-installed package.
I would also be interested in an equivalent a poudriere feature, because
it's at the moment I update a ports tree in preparation for building new
packages that I want to know if a port I build just grew a new option
that I might want to pin per #2.
Regards,
John
[0]
http://lists.freebsd.org/pipermail/freebsd-stable/2013-December/076205.html
signature.asc
Description: OpenPGP digital signature
Re: Snag in math/py-numpy: checksum fails
On 10/28/2012 09:58 PM, Thomas Mueller wrote:
This time, the checksum apparently fails on two files in math/py-numpy.
[snip]
= SHA256 Checksum OK for numpy-1.6.2.tar.gz.
= SHA256 Checksum mismatch for numpy-ref.pdf.
= SHA256 Checksum mismatch for numpy-user.pdf.
=== Giving up on fetching files: numpy-ref.pdf numpy-user.pdf
[snip]
http://docs.scipy.org/doc/numpy/numpy-ref.pdf
http://docs.scipy.org/doc/numpy/numpy-user.pdf
As others have noted, this problem arises when upgrading math/py-numpy
because the PDFs across versions are not distinguishable by file name.
Cached distfiles are not replaced but fail the checksum step.
science/py-scipy has this problem too.
I've filed a bug report upstream for numpy, and will follow-up in due
course with an equivalent ticket for scipy.
http://projects.scipy.org/numpy/ticket/2245
In the mean time, the work-around is to manually delete
$DISTDIR/numpy-{ref,user}.pdf before upgrading. Until this is resolved
upstream (or if it never is), perhaps the maintainer would develop a
local versioning system, or accept a patch that implements one.
Regards,
John
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Maintainer timeout on ports/192904: [patch] www/nginx: Optionally support SPNEGO via 3rd party http_auth_gss module
Last action was assignment to maintainer on 2014-08-22 (3 wk ago) by marino@. I would appreciate either an available committer or some feedback on the offered patch. Thank you, John https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192904 signature.asc Description: OpenPGP digital signature
Re: Should poudriere skip (IGNORE) a port marked BROKEN?
On 12/13/15 3:25 AM, Kurt Jaeger wrote: > Hi! > > [ports marked BROKEN are build in poudriere and fail] > >> But poudriere goes ahead with the build, fails on the broken dependency, >> and skips the port without printing or logging my helpful BROKEN message. >> >> Is this by design, or a flaw in my understanding or in poudriere's >> implementation? > > This is by design, there are two places: > > /usr/local/share/poudriere/testport.sh > > and > > /usr/local/share/poudriere/bulk.sh > > where TRYBROKEN=yes is exported, so that /usr/ports/Mk/bsd.port.mk > starts the build anyway. > > When I try to debug if I use BROKEN in the right manner, > I edited the testport.sh or bulk.sh script not to set TRYBROKEN 8-} > Thank you, Kurt. signature.asc Description: OpenPGP digital signature
security/john maintainer timeout PR 204903 2015-11-30
Are there any committers willing to take this bug? Current timeout is sitting at about six weeks depending on how you count. security/john: OPENMP option has no effect https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204903 Thank you, John signature.asc Description: OpenPGP digital signature
Re: net/freeradius3 maintainer timeout on 202684
On 7/17/16 5:02 AM, Kubilay Kocak wrote: > On 17/07/2016 11:17 AM, John W. O'Brien wrote: >> Hello all, >> >> I was just going through my old bugs and found this one still open from >> 2016-02-27. Is there a committer willing and available to take a look? >> >> net/freeradius3 w/ non-standard config option depends on IDN >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202684 >> >> Thank you, >> John >> > > Re-triaged, open for anyone to assign, please confirm QA pass > > Thanks John :) Confirmed, with artifacts posted to the bug. There are QA issues with this port, but my proposed patch introduces no new ones. signature.asc Description: OpenPGP digital signature
net/freeradius3 maintainer timeout on 202684
Hello all, I was just going through my old bugs and found this one still open from 2016-02-27. Is there a committer willing and available to take a look? net/freeradius3 w/ non-standard config option depends on IDN https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202684 Thank you, John signature.asc Description: OpenPGP digital signature
net/freeradius3 maintainer is ignoring the port (timeout)
Hello FreeBSD ports, The maintainer of net/freeradius3 is unresponsive on two open bugs, both with proposed patches. In one case [0], the submitter responded to feedback on 2016-02-03, there has been no further action on the part of the maintainer, and the port remains broken w.r.t. Kerberos. In the other case [1], there was already one maintainer timeout (5 mo as of 2016-07-17). The bug was reassigned to the maintainer on 2017-08-18, and there has been no further action. I would appreciate it if somebody could give these bugs the attention they need. Also, I ask that if the maintainer is unable or unwilling to attend to reported problems, that the port be released so that others could more easily work to improve it. Regards, John [0] net/freeradius3: Fix pkg-plist with IDN option https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202684 [1] net/freeradius3: Does not link properly against selected kerberos implementation https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205493 signature.asc Description: OpenPGP digital signature
Re: net/freeradius3 maintainer is ignoring the port (timeout)
On 2017/11/09 09:30, Ryan Steinmetz wrote:
> On (11/08/17 20:31), John W. O'Brien wrote:
>> On 2017/11/07 19:16, Ryan Steinmetz wrote:
>>> On (11/06/17 22:11), John W. O'Brien wrote:
>>>> Hello FreeBSD ports,
>>>>
>>>> The maintainer of net/freeradius3 is unresponsive on two open bugs,
>>>> both
>>>> with proposed patches.
>>>
>>> John,
>>>
>>> I was reviewing these two issues tonight and, if I am not mistaken, the
>>> IDN issue was resolved in a commit on 7/17/17:
>>> https://svnweb.freebsd.org/ports/head/net/freeradius3/pkg-plist?r1=442287=446076
>>>
>>
>> Hi Ryan,
>>
>> The change you cite allows the port to build with the IDN option.
>> However, it appears that this fragment of the Makefile needs some TLC.
>> Is the IDN module experimental or not?
>
> To me, this feels a little nit-picky and isn't something that an
> end-user is actually going to see.
Are port OPTIONS for end-users?
>> # freetds module is still experimental
>> .if ${PORT_OPTIONS:MIDN} && empty(PORT_OPTIONS:MEXPERIMENTAL)
>> EXPM= yes
>> .endif
>>
>>> I also believe that the Kerberos issue was resolved on 4/1/16:
>>> https://svnweb.freebsd.org/ports/head/net/freeradius3/Makefile?r1=412347=412348;
>>>
>>>
>>> Can you please verify your ports tree is current (you should see
>>> FreeRADIUS 3.0.15) and then confirm/deny?
>>
>> $ svn info /usr/ports | grep Revision
>> Revision: 453233
>> $ svn log -v -r 453233:HEAD /usr/ports/net/freeradius3
>>
>>
>> The issue persists. Here are some relevant excerpts from a poudriere
>> testport build.
>>
>
> OK so MIT Kerberos integration isn't 100%, but the Heimdal stuff works.
>
> I'll check this out.
Please see the PR for more details and a proposed solution.
I would be glad to help review a refreshed patch.
>> [...]
>> ---Begin OPTIONS List---
>> ===> The following configuration options are available for
>> freeradius3-3.0.15_1:
>> DEVELOPER=off: Enable developer options
>> DOCS=off: Build and/or install documentation
>> EDIR=off: Enable eDirectory support (implies LDAP)
>> EXPERIMENTAL=off: Build experimental modules
>> FIREBIRD=off: With Firebird database support (EXPERIMENTAL)
>> FREETDS=off: FreeTDS library support
>> HEIMDAL=off: With Heimdal Kerberos support
>> HEIMDAL_PORT=off: With Heimdal Kerberos from ports
>> IDN=off: International Domain Names support
>> KERBEROS=on: Kerberos support
>> LDAP=off: LDAP protocol support
>> MYSQL=off: MySQL database support
>> PERL=on: Perl scripting language support
>> PGSQL=off: PostgreSQL database support
>> PYTHON=off: Python bindings or support
>> REDIS=off: Redis key-value store database support
>> REST=off: Enable RESTful API support
>> RUBY=off: Ruby bindings or support
>> SQLITE3=off: SQLite 3 database support
>> UDPFROMTO=off: Compile in UDPFROMTO support
>> UNIXODBC=off: With unixODBC database support
>> USER=on: Run as user freeradius, group freeradius
>> ===> Use 'make config' to modify these settings
>> ---End OPTIONS List---
>>
>> --CONFIGURE_ARGS--
>> --without-rlm_sql_sqlite --with-rlm_krb5
>> --with-rlm-krb5-lib-dir=/usr/local/lib --wi
>> th-rlm-krb5-include-dir=/usr/local/include --without-edir
>> --without-rlm_ldap --without-rlm_sql_mysql --without-rlm_sql_postgresql
>> --without-rlm_sql_unixodbc --without-rlm_sql_firebird --with-rlm_perl
>> --without-rlm_python --without-rlm_ruby --with-ruby=no
>> --without-rlm_redis --without-rlm_rediswho --without-rlm_rest
>> --without-rlm_freetds --without-rlm_idn --without-experimental-modules
>> --quiet --without-docdir --with-openssl-libraries=/usr/local/lib
>> --with-logdir=/var/log --with-openssl-includes=/usr/local/include
>> --prefix=/usr/local --libdir=/usr/local/lib/freeradius-3.0.15
>> --localstatedir=/var --without-rlm_eap_ikev2 --without-rlm_eap_tnc
>> --without-rlm_eap2 --without-rlm_opendirectory --without-rlm_sql_db2
>> --without-rlm_sql_iodbc --without-rlm_sql_sybase --without-rlm_yubikey
>> --without-rlm_sql_oracle --without-rlm_securid
>> --without-rlm_cache_memcached --with-vmps
>> --with-collectdclient-lib-dir=/dev/null --disable-openssl-version-check
>> --with-pic --prefix=/usr/local ${_LATE_CONFIGURE_ARGS}
>> --End CONFIGURE_ARGS--
>>
>> --CONFIGU
Re: net/freeradius3 maintainer is ignoring the port (timeout)
On 2017/11/06 22:31, Kubilay Kocak wrote: [...] > If you'd like (or are offering) to maintain the port, please create a > separate issue updating the MAINTAINER line and have it depend on the > existing open issues (so they can be committed first). > > The maintainer change can then be made after maintainer timeout (2+ weeks). > > It's much easier and preferred to update maintainers with an explicit > offer and change (in a bug), than to release a port with the possible > prospect of having no maintainer. Thank you, koobs. I will keep that strategy in mind in the future. -John signature.asc Description: OpenPGP digital signature
Re: net/freeradius3 maintainer is ignoring the port (timeout)
On 2017/11/07 19:16, Ryan Steinmetz wrote:
> On (11/06/17 22:11), John W. O'Brien wrote:
>> Hello FreeBSD ports,
>>
>> The maintainer of net/freeradius3 is unresponsive on two open bugs, both
>> with proposed patches.
>
> John,
>
> I was reviewing these two issues tonight and, if I am not mistaken, the
> IDN issue was resolved in a commit on 7/17/17:
> https://svnweb.freebsd.org/ports/head/net/freeradius3/pkg-plist?r1=442287=446076
Hi Ryan,
The change you cite allows the port to build with the IDN option.
However, it appears that this fragment of the Makefile needs some TLC.
Is the IDN module experimental or not?
# freetds module is still experimental
.if ${PORT_OPTIONS:MIDN} && empty(PORT_OPTIONS:MEXPERIMENTAL)
EXPM= yes
.endif
> I also believe that the Kerberos issue was resolved on 4/1/16:
> https://svnweb.freebsd.org/ports/head/net/freeradius3/Makefile?r1=412347=412348;
>
> Can you please verify your ports tree is current (you should see
> FreeRADIUS 3.0.15) and then confirm/deny?
$ svn info /usr/ports | grep Revision
Revision: 453233
$ svn log -v -r 453233:HEAD /usr/ports/net/freeradius3
The issue persists. Here are some relevant excerpts from a poudriere
testport build.
[...]
---Begin OPTIONS List---
===> The following configuration options are available for
freeradius3-3.0.15_1:
DEVELOPER=off: Enable developer options
DOCS=off: Build and/or install documentation
EDIR=off: Enable eDirectory support (implies LDAP)
EXPERIMENTAL=off: Build experimental modules
FIREBIRD=off: With Firebird database support (EXPERIMENTAL)
FREETDS=off: FreeTDS library support
HEIMDAL=off: With Heimdal Kerberos support
HEIMDAL_PORT=off: With Heimdal Kerberos from ports
IDN=off: International Domain Names support
KERBEROS=on: Kerberos support
LDAP=off: LDAP protocol support
MYSQL=off: MySQL database support
PERL=on: Perl scripting language support
PGSQL=off: PostgreSQL database support
PYTHON=off: Python bindings or support
REDIS=off: Redis key-value store database support
REST=off: Enable RESTful API support
RUBY=off: Ruby bindings or support
SQLITE3=off: SQLite 3 database support
UDPFROMTO=off: Compile in UDPFROMTO support
UNIXODBC=off: With unixODBC database support
USER=on: Run as user freeradius, group freeradius
===> Use 'make config' to modify these settings
---End OPTIONS List---
--CONFIGURE_ARGS--
--without-rlm_sql_sqlite --with-rlm_krb5
--with-rlm-krb5-lib-dir=/usr/local/lib --wi
th-rlm-krb5-include-dir=/usr/local/include --without-edir
--without-rlm_ldap --without-rlm_sql_mysql --without-rlm_sql_postgresql
--without-rlm_sql_unixodbc --without-rlm_sql_firebird --with-rlm_perl
--without-rlm_python --without-rlm_ruby --with-ruby=no
--without-rlm_redis --without-rlm_rediswho --without-rlm_rest
--without-rlm_freetds --without-rlm_idn --without-experimental-modules
--quiet --without-docdir --with-openssl-libraries=/usr/local/lib
--with-logdir=/var/log --with-openssl-includes=/usr/local/include
--prefix=/usr/local --libdir=/usr/local/lib/freeradius-3.0.15
--localstatedir=/var --without-rlm_eap_ikev2 --without-rlm_eap_tnc
--without-rlm_eap2 --without-rlm_opendirectory --without-rlm_sql_db2
--without-rlm_sql_iodbc --without-rlm_sql_sybase --without-rlm_yubikey
--without-rlm_sql_oracle --without-rlm_securid
--without-rlm_cache_memcached --with-vmps
--with-collectdclient-lib-dir=/dev/null --disable-openssl-version-check
--with-pic --prefix=/usr/local ${_LATE_CONFIGURE_ARGS}
--End CONFIGURE_ARGS--
--CONFIGURE_ENV--
MAKE=gmake ac_cv_path_PERL=/usr/local/bin/perl
ac_cv_path_PERL_PATH=/usr/local/bin/perl PERL_USE_UNSAFE_INC=1
XDG_DATA_HOME=/wrkdirs/usr/ports/net/freeradius3/work
XDG_CONFIG_HOME=/wrkdirs/usr/ports/net/freeradius3/work
HOME=/wrkdirs/usr/ports/net/freeradius3/work TMPDIR="/tmp"
PATH=/wrkdirs/usr/ports/net/freeradius3/work/.bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin
SHELL=/bin/sh CONFIG_SHELL=/bin/sh
CONFIG_SITE=/usr/ports/Templates/config.site lt_cv_sys_max_cmd_len=262144
--End CONFIGURE_ENV--
--MAKE_ENV--
OPENSSLBASE=/usr/local OPENSSLDIR=/usr/local/openssl
OPENSSLINC=/usr/local/include OPENSSLLIB=/usr/local/lib
OPENSSLRPATH=/usr/local/lib PERL_USE_UNSAFE_INC=1
XDG_DATA_HOME=/wrkdirs/usr/ports/net/freeradius3/work
XDG_CONFIG_HOME=/wrkdirs/usr/ports/net/freeradius3/work
HOME=/wrkdirs/usr/ports/net/freeradius3/work TMPDIR="/tmp"
PATH=/wrkdirs/usr/ports/net/freeradius3/work/.bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin
NO_PIE=yes WITHOUT_DEBUG_FILES=yes WITHOUT_KERNEL_SYMBOLS=yes
SHELL=/bin/sh NO_LINT=YES PREFIX=/usr/local LOCALBASE=/usr/local
LIBDIR="/usr/lib" CC="cc" CFLAGS="-O2 -pipe -I/usr/local
Practice of "Sponsored by" in commit messages
Hello FreeBSD Ports, The Committer's Guide section on Commit Log Messages [0], doesn't cover the use of the "Sponsored by" key word. As a non-committer contributor, it only recently occurred to me to wonder what work that credit is intended to represent, and whether some light definition would be helpful to reduce ambiguity. When a committer credits a sponsor of theirs, from which the contributor received no sponsorship, the portrayal feels a little awkward. Does this strike the list as a problem, and if so, how ought it be solved? To make this concrete, allow me to illustrate the situation. Alice, working on her own time, prepares and contributes a patch. Bob, who works for Acme Corp, reviews and commits the patch on company time. The commit message includes "Sponsored by: Acme Corp". Alice eagerly awaits her check from Acme Corp. Should the commit message have read "Sponsored by: Acme Corp (Bob)"? This could be extensible to multiple sponsorships. If, instead, Alice prepares the patch having received a grant to do so from Best Sys Dev, the commit message could state "Sponsored by: Acme Corp (Bob), Best Sys Dev (Alice)". [0] https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/article.html#commit-log-message PS: I realize that this issue transcends ports, but it's not clear where I should send this instead, and this list seems like it would have a reasonably high concentration of people with a stake in the discussion. -- John W. O'Brien OpenPGP keys: 0x33C4D64B895DBF3B signature.asc Description: OpenPGP digital signature
Maintainer timeout: dns/dnsperf bug 227812
Hello FreeBSD Ports, I believe we have reached the two week maintainer timeout on bug 227812 [0]. A tested patch has been ready to commit without feedback since 2018-04-27T16:28:10Z. Are there any committers within earshot able and willing to take this bug? [0] dns/dnsperf: Update to 2.1.0.0 https://bugs.freebsd.org/227812 Thank you, -- John W. O'Brien OpenPGP keys: 0x33C4D64B895DBF3B signature.asc Description: OpenPGP digital signature
Re: Practice of "Sponsored by" in commit messages
On 2018/05/18 00:43, Eitan Adler wrote: > On 17 May 2018 at 21:15, Kurt Jaeger <li...@opsec.eu> wrote: >> Hi! >> >>> The FreeBSD project could help by asking committers to qualify >>> "Sponsored by" lines to indicate which participant(s) is(are) sponsored, >>> in way that is equivalent to the way that the actual work itself is >>> customarily attributed. >> >> This sounds reasonable, so I suggest that you submit a >> patch to the ports handbook that describes it for maintainers >> and committers. > > One thing to note: FreeBSD has a custom patch to subversion to detect > "ORGANIZATION_NAME" and automatically append it to the default > template. This is likely why its getting added in unexpected places. > How do you think I should handle that in my forthcoming doc patch? Is there a related bug I should file against services? -- John W. O'Brien OpenPGP keys: 0x33C4D64B895DBF3B signature.asc Description: OpenPGP digital signature
Re: Practice of "Sponsored by" in commit messages
On 2018/05/18 00:15, Kurt Jaeger wrote: > Hi! > >> The FreeBSD project could help by asking committers to qualify >> "Sponsored by" lines to indicate which participant(s) is(are) sponsored, >> in way that is equivalent to the way that the actual work itself is >> customarily attributed. > > This sounds reasonable, so I suggest that you submit a > patch to the ports handbook that describes it for maintainers > and committers. > Thank you. I will prepare a patch. It seems like it should be against the Committers' Guide [0], though. Also, since this would apply to trees besides ports, is there a venue besides this list where I should solicit feedback? [0] https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/article.html#commit-log-message -- John W. O'Brien OpenPGP keys: 0x33C4D64B895DBF3B signature.asc Description: OpenPGP digital signature
Re: Practice of "Sponsored by" in commit messages
On 2018/05/18 16:32, John W. O'Brien wrote: > On 5/18/18 14:20, Kurt Jaeger wrote: >> Hi! >> >>>>>>> The FreeBSD project could help by asking committers to qualify >>>>>>> "Sponsored by" lines to indicate which participant(s) is(are) sponsored, >>>>>>> in way that is equivalent to the way that the actual work itself is >>>>>>> customarily attributed. >> >>>>>> This sounds reasonable, so I suggest that you submit a >>>>>> patch to the ports handbook that describes it for maintainers >>>>>> and committers. >> >>>>> One thing to note: FreeBSD has a custom patch to subversion to detect >>>>> "ORGANIZATION_NAME" and automatically append it to the default >>>>> template. This is likely why its getting added in unexpected places. >> >>>> How do you think I should handle that in my forthcoming doc patch? Is >>>> there a related bug I should file against services? >> >>> Its a client side patch of the subversion binary. I'm not sure the >>> best way to handle it beyond perhaps changing the template a bit? >> >> What change would be needed ? There's already a Sponsored by field ? >> >> The custom patch is here: >> >> https://svnweb.freebsd.org/ports/head/devel/subversion/files/extra-patch-fbsd-template?revision=411397=markup > > I agree that this won't necessarily need to change. If anything, a very > small reminder to committers, or suggestive wording change, to fix-up > the the sponsorship line when applicable. I will submit a separate bug > with a candidate change that depends on the doc bug. I won't mind if the > doc bug is accepted and the subversion portbug is closed WONTFIX upon > review. > Patch away [1]! [1] devel/subversion: Update "Sponsored by" microcopy in FBSD extra patch https://bugs.freebsd.org/228362 -- John W. O'Brien OpenPGP keys: 0x33C4D64B895DBF3B signature.asc Description: OpenPGP digital signature
Re: Practice of "Sponsored by" in commit messages
On 5/18/18 14:20, Kurt Jaeger wrote: > Hi! > >>>>>> The FreeBSD project could help by asking committers to qualify >>>>>> "Sponsored by" lines to indicate which participant(s) is(are) sponsored, >>>>>> in way that is equivalent to the way that the actual work itself is >>>>>> customarily attributed. > >>>>> This sounds reasonable, so I suggest that you submit a >>>>> patch to the ports handbook that describes it for maintainers >>>>> and committers. > >>>> One thing to note: FreeBSD has a custom patch to subversion to detect >>>> "ORGANIZATION_NAME" and automatically append it to the default >>>> template. This is likely why its getting added in unexpected places. > >>> How do you think I should handle that in my forthcoming doc patch? Is >>> there a related bug I should file against services? > >> Its a client side patch of the subversion binary. I'm not sure the >> best way to handle it beyond perhaps changing the template a bit? > > What change would be needed ? There's already a Sponsored by field ? > > The custom patch is here: > > https://svnweb.freebsd.org/ports/head/devel/subversion/files/extra-patch-fbsd-template?revision=411397=markup I agree that this won't necessarily need to change. If anything, a very small reminder to committers, or suggestive wording change, to fix-up the the sponsorship line when applicable. I will submit a separate bug with a candidate change that depends on the doc bug. I won't mind if the doc bug is accepted and the subversion portbug is closed WONTFIX upon review. -- John W. O'Brien OpenPGP keys: 0x33C4D64B895DBF3B signature.asc Description: OpenPGP digital signature
Re: Practice of "Sponsored by" in commit messages
On 2018/05/14 20:25, Julian Elischer wrote: > On 15/5/18 7:40 am, John W. O'Brien wrote: >> Hello FreeBSD Ports, >> >> The Committer's Guide section on Commit Log Messages [0], doesn't cover >> the use of the "Sponsored by" key word. As a non-committer contributor, >> it only recently occurred to me to wonder what work that credit is >> intended to represent, and whether some light definition would be >> helpful to reduce ambiguity. >> >> When a committer credits a sponsor of theirs, from which the contributor >> received no sponsorship, the portrayal feels a little awkward. Does this >> strike the list as a problem, and if so, how ought it be solved? >> >> To make this concrete, allow me to illustrate the situation. >> >> Alice, working on her own time, prepares and contributes a patch. Bob, >> who works for Acme Corp, reviews and commits the patch on company time. >> The commit message includes "Sponsored by: Acme Corp". Alice eagerly >> awaits her check from Acme Corp. Should the commit message have read >> "Sponsored by: Acme Corp (Bob)"? > > Probably not for just a review, unless it was pretty in depth and took > many hours. It sounds like my example didn't make the point I intended. I was trying to highlight the fact that the unqualified credit in the example makes it seem like Alice's efforts were funded by the sponsor when they weren't. If Alice's efforts were trivial while Bob's were substantial, maybe that's no big deal. If the reverse is true, then I think there is a problem, which is why I propose qualifying the credit. Ambiguous:Sponsored by: Acme Corp Qualified:Sponsored by: Acme Corp (Bob) To be clear, a committer who "just" reviews and commits a contributed patch should definitely be able to credit their employer at their discretion. > However we want to give some sort of acknowledgement > to companies that do allow their work to be incorporated, and who allow > their employees to do some FreeBSD work as part of their duties. > It also makes their name familiar to the readers of the commit emails > and often results in others seeking work there etc. > "Sponsored by:" generally means "some (maybe small) part of this work > was developed > by someone being paid". It does not specify how much, and it is > generally left to the committer > to decide if it was meaningful. In some cases it is deliberately NOT > entered despite > the developer being paid. (e.g. when a company is in stealth mode, or > when some political > issue is relevant and people don't want to draw attention). I agree that the practice should not aim to quantify the relative contributions, and that the decision to credit a sponsor should be left to each participant. >> This could be extensible to multiple sponsorships. If, instead, Alice >> prepares the patch having received a grant to do so from Best Sys Dev, >> the commit message could state "Sponsored by: Acme Corp (Bob), Best Sys >> Dev (Alice)". >> >> [0] >> https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/article.html#commit-log-message >> >> >> PS: I realize that this issue transcends ports, but it's not clear where >> I should send this instead, and this list seems like it would have a >> reasonably high concentration of people with a stake in the discussion. >> > -- John W. O'Brien OpenPGP keys: 0x33C4D64B895DBF3B signature.asc Description: OpenPGP digital signature
Re: Practice of "Sponsored by" in commit messages
On 2018/05/14 20:14, Maxim Sobolev wrote: > What's wrong with a current practice. Why is it of any concern to you, > John? Just curious that is not very clear from your message. It is like > someone trying to moderate what people in general or some group in > particular (e.g. freebsd committers) are allowed to put on their > t-shirts just because you find it offensive or inappropriate. I don't find crediting sponsors offensive nor inappropriate. Quite the contrary. What I find problematic is when multiple people do work, not all with sponsorship or the same sponsorship, and only one person's sponsor is mentioned in a way that seems to imply that all the work was sponsored. What I'm proposing is not to end or ban the practice, but to improve and refine it so that sponsors are credited for what they sponsor and not for what they don't sponsor. Is that clearer? > On Mon, May 14, 2018, 4:40 PM John W. O'Brien <j...@saltant.com > <mailto:j...@saltant.com>> wrote: > > Hello FreeBSD Ports, > > The Committer's Guide section on Commit Log Messages [0], doesn't cover > the use of the "Sponsored by" key word. As a non-committer contributor, > it only recently occurred to me to wonder what work that credit is > intended to represent, and whether some light definition would be > helpful to reduce ambiguity. > > When a committer credits a sponsor of theirs, from which the contributor > received no sponsorship, the portrayal feels a little awkward. Does this > strike the list as a problem, and if so, how ought it be solved? > > To make this concrete, allow me to illustrate the situation. > > Alice, working on her own time, prepares and contributes a patch. Bob, > who works for Acme Corp, reviews and commits the patch on company time. > The commit message includes "Sponsored by: Acme Corp". Alice eagerly > awaits her check from Acme Corp. Should the commit message have read > "Sponsored by: Acme Corp (Bob)"? > > This could be extensible to multiple sponsorships. If, instead, Alice > prepares the patch having received a grant to do so from Best Sys Dev, > the commit message could state "Sponsored by: Acme Corp (Bob), Best Sys > Dev (Alice)". > > [0] > > https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/article.html#commit-log-message > > PS: I realize that this issue transcends ports, but it's not clear where > I should send this instead, and this list seems like it would have a > reasonably high concentration of people with a stake in the discussion. -- John W. O'Brien OpenPGP keys: 0x33C4D64B895DBF3B signature.asc Description: OpenPGP digital signature
Re: Practice of "Sponsored by" in commit messages
On 2018/05/17 19:18, Maxim Sobolev wrote: > John, no, not really, sorry. Work is done, credit is given. The form and > amount of this credit is between whoever does the work and whoever is > being credited. I don't see why is there any third-party to be involved > in governing whether or not this credit is "appropriate", "sufficient" > or "all encompassing" for the work in question. This is just a credit, > it does not affect the quality of work, nor the license (which is > 2-clause BSD) nor the copyright holder. Three things that really matter > long-time. So "Sponsored by" it's just the message on the t-shirt, > having only meaning to whoever produces the piece and whoever wears it, > but nothing in particular to the outside world. IMHO. I fear that you and I are still not on the same page. The difference between a t-shirt and a commit message is that two or three or four people can all do work on the same commit, but only one person can wear a t-shirt. Taking the analogy further, if you hang a t-shirt with your employer's logo on a piece of work that you and I collaborated to produce, don't you think my employer might feel slighted? What if I had done 80% of the work? > On Thu, May 17, 2018 at 3:43 PM, John W. O'Brien <j...@saltant.com > <mailto:j...@saltant.com>> wrote: > > On 2018/05/14 20:14, Maxim Sobolev wrote: > > What's wrong with a current practice. Why is it of any concern to you, > > John? Just curious that is not very clear from your message. It is like > > someone trying to moderate what people in general or some group in > > particular (e.g. freebsd committers) are allowed to put on their > > t-shirts just because you find it offensive or inappropriate. > > I don't find crediting sponsors offensive nor inappropriate. Quite the > contrary. What I find problematic is when multiple people do work, not > all with sponsorship or the same sponsorship, and only one person's > sponsor is mentioned in a way that seems to imply that all the work was > sponsored. > > What I'm proposing is not to end or ban the practice, but to improve and > refine it so that sponsors are credited for what they sponsor and not > for what they don't sponsor. > > Is that clearer? > > > On Mon, May 14, 2018, 4:40 PM John W. O'Brien <j...@saltant.com > <mailto:j...@saltant.com> > > <mailto:j...@saltant.com <mailto:j...@saltant.com>>> wrote: > > > > Hello FreeBSD Ports, > > > > The Committer's Guide section on Commit Log Messages [0], > doesn't cover > > the use of the "Sponsored by" key word. As a non-committer > contributor, > > it only recently occurred to me to wonder what work that credit is > > intended to represent, and whether some light definition would be > > helpful to reduce ambiguity. > > > > When a committer credits a sponsor of theirs, from which the > contributor > > received no sponsorship, the portrayal feels a little awkward. > Does this > > strike the list as a problem, and if so, how ought it be solved? > > > > To make this concrete, allow me to illustrate the situation. > > > > Alice, working on her own time, prepares and contributes a > patch. Bob, > > who works for Acme Corp, reviews and commits the patch on > company time. > > The commit message includes "Sponsored by: Acme Corp". Alice > eagerly > > awaits her check from Acme Corp. Should the commit message > have read > > "Sponsored by: Acme Corp (Bob)"? > > > > This could be extensible to multiple sponsorships. If, > instead, Alice > > prepares the patch having received a grant to do so from Best > Sys Dev, > > the commit message could state "Sponsored by: Acme Corp (Bob), > Best Sys > > Dev (Alice)". > > > > [0] > > > > https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/article.html#commit-log-message > > <https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/article.html#commit-log-message> > > > > PS: I realize that this issue transcends ports, but it's not > clear where > > I should send this instead, and this list seems like it would > have a > > reasonably high concentration of people with a stake in the > discussion. -- John W. O'Brien OpenPGP keys: 0x33C4D64B895DBF3B signature.asc Description: OpenPGP digital signature
Re: Practice of "Sponsored by" in commit messages
On 2018/05/17 19:36, Maxim Sobolev wrote: > Well, if your employer feels slighted it's for him to bring it up with > you (see my previous rant on the amount and scope of the credit and who > parties involved). And then for you to bring it up with me if you feel > brave enough. :) I don't see how and why FreeBSD project can help in > this highly hypothetical scenario by putting some rules around. Do we > have any real-world examples of this happening, bring me at least one > out of probably tents of thousands of times people used "Sponsored by" > in their commit messages. Just a single one, please! ) The FreeBSD project could help by asking committers to qualify "Sponsored by" lines to indicate which participant(s) is(are) sponsored, in way that is equivalent to the way that the actual work itself is customarily attributed. Examples showing this idea in action: r470149 | krion PR: 228292 [1], 227223 [2] Submitted by: maintainer [1], 0mp@ [2] [Interpretation: The maintainer did some work to prepare a patch, 0mp did some work to prepare a patch, and krion combined the patches and performed the commit.] r470018 | kan Reviewed by:jhb, bapt [Interpretation: kan prepared a patch, jhb and bapt reviewed it, kan committed it.] Examples where I perceive no problem: r470130 | truckman PR: 228172 Approved by:Leo Vandewoestijne <freebsd@dns.company> (maintainer) Sponsored by: Farsight Security, Inc. [Interpretation: truckman did the work on Farsight company time; Leo signed-off, but did little or no work, and either doesn't have a sponsor or chose not to credit the sponsor.] r469997 | mat PR: 228149 Reported by:Niels Bakker Sponsored by: Absolight [Interpretation: Niels called attention to a problem, but did little or no work on producing a patch, and either doesn't have a sponsor or chose not to credit the sponsor; mat did the work to produce a patch on Absolight company time.] Examples showing where improvement is needed: r469984 | dteske Reviewed by:mat (mentor; earlier version), imp (mentor), dbaio Approved by:imp (mentor) Sponsored by: Smule, Inc. Differential Revision: https://reviews.freebsd.org/D15415 [Uncertainty: Was the review by mat, imp, and dbaio all done on Smule company time? Doesn't mat work for Absolight? Maybe he was working on his own time for this one. Maybe acting as a mentor takes hardly any time. Possible improvements include "Sponsored by: Smule, Inc. (dteske)", or "Sponsored by: Smule, Inc. (dteske), Absolight (mat)", or...] r469709 | miwi PR: 228117 Submitted by: maintainer Sponsored by: iXsystems Inc. [Uncertainty: Does the maintainer work for iXsystems too? Did the sponsorship cover preparation of the patch or just the work to commit it? Possible improvements include "Sponsored by: iXsystems Inc. (miwi)", or "Sponsored by: iXsystems Inc. (miwi, maintainer)", or...] Are non-committer contributors entitled to specify sponsorship credits? Should I start requesting sponsorship credit under the name of my small, one-man consulting operation? If I do, would that discourage committers from taking my bugs who want to be able to credit their own employers for the commit? > On Thu, May 17, 2018 at 4:29 PM, John W. O'Brien <j...@saltant.com > <mailto:j...@saltant.com>> wrote: > > On 2018/05/17 19:18, Maxim Sobolev wrote: > > John, no, not really, sorry. Work is done, credit is given. The form and > > amount of this credit is between whoever does the work and whoever is > > being credited. I don't see why is there any third-party to be involved > > in governing whether or not this credit is "appropriate", "sufficient" > > or "all encompassing" for the work in question. This is just a credit, > > it does not affect the quality of work, nor the license (which is > > 2-clause BSD) nor the copyright holder. Three things that really matter > > long-time. So "Sponsored by" it's just the message on the t-shirt, > > having only meaning to whoever produces the piece and whoever wears it, > > but nothing in particular to the outside world. IMHO. > > I fear that you and I are still not on the same page. The difference > between a t-shirt and a commit message is that two or three or four > people can all do work on the same commit, but only one person can wear > a t-shirt. > > Taking the analogy further, if you hang a t-shirt with your employer's > logo on a piece of work that you and I collaborated to produce, don't > you think my employer might feel slighted? What if I had done 80% of the > work? > > > On Thu, May 17, 2018 at 3:43 PM, John W. O'Brien <j...@sa
Re: Practice of "Sponsored by" in commit messages
On 2018/05/18 07:38, John W. O'Brien wrote: > On 2018/05/18 00:15, Kurt Jaeger wrote: >> Hi! >> >>> The FreeBSD project could help by asking committers to qualify >>> "Sponsored by" lines to indicate which participant(s) is(are) sponsored, >>> in way that is equivalent to the way that the actual work itself is >>> customarily attributed. >> >> This sounds reasonable, so I suggest that you submit a >> patch to the ports handbook that describes it for maintainers >> and committers. >> > > Thank you. I will prepare a patch. It seems like it should be against > the Committers' Guide [0], though. Also, since this would apply to trees > besides ports, is there a venue besides this list where I should solicit > feedback? > > [0] > https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/article.html#commit-log-message > Patch away [0]! [0] https://bugs.freebsd.org/228353 -- John W. O'Brien OpenPGP keys: 0x33C4D64B895DBF3B signature.asc Description: OpenPGP digital signature
CFT/CFR: Update ELK stack to 5.6.6 (D14003)
Good day FreeBSD Ports, I would appreciate review [0] and test of my proposed patch to update the ELK stack ports to the latest version in the 5.x series. The maintainer has not yet responded to my request for review. [0] https://reviews.freebsd.org/D14003 Thank you, -- John W. O'Brien OpenPGP keys: 0x33C4D64B895DBF3B 0x474ABD3C1A7B3F70 (expires 2018-03-14) signature.asc Description: OpenPGP digital signature
Re: CFT/CFR: Update ELK stack to 5.6.7 (D14003)
On 2018/02/04 14:02, John W. O'Brien wrote: > On 2018/01/27 12:20, John W. O'Brien wrote: >> I would appreciate review [0] and test of my proposed patch to update >> the ELK stack ports to the latest version in the 5.x series. >> >> The maintainer has not yet responded to my request for review. >> >> [0] https://reviews.freebsd.org/D14003 > > I have revised the patch based on testing and further inspection and > submitted ports/225665 [1] to complete the update. > > [1] Update ELK stack to 5.6.6 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225665 > Shortly after my last message I became aware of the new upstream release (5.6.7 on 2018-01-30) and revised the review and bug accordingly. Sorry for the churn. -- John W. O'Brien OpenPGP keys: 0x33C4D64B895DBF3B 0x474ABD3C1A7B3F70 (expires 2018-03-14) signature.asc Description: OpenPGP digital signature
Re: CFT/CFR: Update ELK stack to 5.6.6 (D14003)
On 2018/01/27 12:20, John W. O'Brien wrote: > I would appreciate review [0] and test of my proposed patch to update > the ELK stack ports to the latest version in the 5.x series. > > The maintainer has not yet responded to my request for review. > > [0] https://reviews.freebsd.org/D14003 I have revised the patch based on testing and further inspection and submitted ports/225665 [1] to complete the update. [1] Update ELK stack to 5.6.6 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225665 -- John W. O'Brien OpenPGP keys: 0x33C4D64B895DBF3B 0x474ABD3C1A7B3F70 (expires 2018-03-14) signature.asc Description: OpenPGP digital signature
New port: dns/bind9stats -- Munin plugin for BINDv9 stats channel
Hello FreeBSD ports, This new port [0] has not gotten any committer love for the last two weeks. I would appreciate feedback or to have it added to the ports tree. [0] dns/bind9stats: Munin plugin to collect BINDv9 data from the statistics channel https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225508 Thank you, -- John W. O'Brien OpenPGP keys: 0x33C4D64B895DBF3B 0x474ABD3C1A7B3F70 (expires 2018-03-14) signature.asc Description: OpenPGP digital signature
New port: textproc/elasticsearch6
I'm glad to see this in the tree and appreciate the work pi@ and w.schwarzenfeld have done. I'm puzzled about why tj@, who is AWOL, ended up as maintainer. Could somebody help me understand this? $ svn log -c 461559 /usr/ports | egrep "^r[0-9]|Submitted" r461559 | pi | 2018-02-12 01:49:48 -0500 (Mon, 12 Feb 2018) | 10 lines Submitted by: w.schwarzenf...@utanet.at $ svn diff -c 461559 /usr/ports | grep MAINTAINER +MAINTAINER=t...@freebsd.org Nothing against tj@, by the way. -- John W. O'Brien OpenPGP keys: 0x33C4D64B895DBF3B 0x474ABD3C1A7B3F70 (expires 2018-03-14) signature.asc Description: OpenPGP digital signature
Re: New Flask ports: Flask-Moment, Flask-Mail, Flask-SAML, Flask-Kerberos
On 2018/03/01 23:04, John W. O'Brien wrote: > These new ports have not gotten any committer love for some time. I > would appreciate any feedback or to have them added to the ports tree. [...] > 2017-12-26 > www/py-flask-moment > https://bugs.freebsd.org/224587 > > 2017-12-26 > mail/py-flask-mail > https://bugs.freebsd.org/224588 > > 2018-01-16 > security/py-flask-kerberos > https://bugs.freebsd.org/225199 > > 2018-01-16 > security/py-flask-saml > https://bugs.freebsd.org/225202 Hello all, Please excuse the cross-posting, but these new ports have not gotten any attention from freebsd-python@ so I'm expanding the call for committers to freebsd-ports@. -- John W. O'Brien OpenPGP keys: 0x33C4D64B895DBF3B signature.asc Description: OpenPGP digital signature
New port: net/gobgp -- BGP routing daemon implemented in golang
Hello FreeBSD ports, This new port [0] has not gotten any committer love for the last two weeks since it was last refreshed. I would appreciate feedback or to have it added to the ports tree, as I'm sure nork (maintainer) would too. [0] net/gobgp: Add a new port GoBGP, which is a BGP routing daemon implemented in golang. https://bugs.freebsd.org/218678 -- John W. O'Brien OpenPGP keys: 0x33C4D64B895DBF3B 0x474ABD3C1A7B3F70 (expires 2018-03-14) signature.asc Description: OpenPGP digital signature
Re: New port: net/gobgp -- BGP routing daemon implemented in golang
On 2018/02/27 13:21, Kurt Jaeger wrote: > Hi! > >>> This new port [0] has not gotten any committer love for the last two >>> weeks since it was last refreshed. I would appreciate feedback or to >>> have it added to the ports tree, as I'm sure nork (maintainer) would too. >>> >>> [0] net/gobgp: Add a new port GoBGP, which is a BGP routing daemon >>> implemented in golang. >>> https://bugs.freebsd.org/218678 >> >> Testbuilds are fine, I'll do a runtest this evening, then commit. > > Runtest looks fine. Committed, thanks very much! > Thank you, Kurt. nork: Congratulations on your new port. -- John W. O'Brien OpenPGP keys: 0x33C4D64B895DBF3B 0x474ABD3C1A7B3F70 (expires 2018-03-14) signature.asc Description: OpenPGP digital signature
Re: security/py-gssapi: Strip libraries; add ssl -- needs a committer
On 2018/10/06 16:31, John W. O'Brien wrote: > Hello FreeBSD-Python, > > Are there any friendly neighborhood committers available to take > Nathan's patch [0]? > > [0] https://bugs.freebsd.org/231189 Hello FreeBSD Ports, Nathan's patch hasn't been getting any love over in FreeBSD Python. Are there any committers here who are available and would be willing to take this bug? -- John W. O'Brien OpenPGP keys: 0x33C4D64B895DBF3B signature.asc Description: OpenPGP digital signature
Re: security/py-gssapi: Strip libraries; add ssl -- needs a committer
On 2018/10/26 19:41, John W. O'Brien wrote: > On 2018/10/06 16:31, John W. O'Brien wrote: >> Hello FreeBSD-Python, >> >> Are there any friendly neighborhood committers available to take >> Nathan's patch [0]? >> >> [0] https://bugs.freebsd.org/231189 > > Hello FreeBSD Ports, > > Nathan's patch hasn't been getting any love over in FreeBSD Python. Are > there any committers here who are available and would be willing to take > this bug? > Hello again, It's been two more weeks with no attention to this patch, which is ready to commit. Could I entice a committer to pick it up? Thank you, -- John W. O'Brien OpenPGP keys: 0x33C4D64B895DBF3B signature.asc Description: OpenPGP digital signature
Re: security/py-gssapi: Strip libraries; add ssl -- needs a committer
On 2018/11/11 03:35, Kurt Jaeger wrote: > Hi! > >>>> [0] https://bugs.freebsd.org/231189 > [...] >> It's been two more weeks with no attention to this patch, which is ready >> to commit. Could I entice a committer to pick it up? > > Committed, thanks! It took me a while to clean up after the > 12/openssl111 update. > Thank you, Kurt. -- John W. O'Brien OpenPGP keys: 0x33C4D64B895DBF3B signature.asc Description: OpenPGP digital signature
New port: selectors2
Hello FreeBSD Python, Are there any friendly neighborhood committers willing and able to take this bug [0]. I would appreciate any feedback or to have it added to the ports tree. Also, the absence of this port is a blocker for updating net-mgmt/py-ncclient to the latest version [1]. [0] [NEW PORT] devel/py-selectors2: Backported, durable, and portable I/O selectors for python https://bugs.freebsd.org/230873 [1] net-mgmt/py-ncclient: Update to 0.6.2 https://bugs.freebsd.org/230874 Thank you, -- John W. O'Brien OpenPGP keys: 0x33C4D64B895DBF3B signature.asc Description: OpenPGP digital signature
Maintainer timeout: print/latex-beamer bug 241766
Hello FreeBSD Ports, I believe we have exceeded the two week maintainer timeout on bug 241766 [0]. A patch has been awaiting attention since 2019-11-25T19:11:52Z. Are there any committers within earshot able and willing to take this bug? [0] print/latex-beamer: update to 3.57 and unbreak https://bugs.freebsd.org/241766 Thank you, -- John W. O'Brien OpenPGP keys: 0x33C4D64B895DBF3B signature.asc Description: OpenPGP digital signature
ports/243787: [NEW PORT] net/mcjoin: Simple multicast testing application for UNIX
Hello FreeBSD Ports, This contribution [0] has been awaiting attention for about four weeks, since 2020-02-01 22:20:44 UTC. Are there any friendly, neighborhood committers who would be willing and available to take it? [0] https://bugs.freebsd.org/243787 -- John W. O'Brien OpenPGP keys: 0x33C4D64B895DBF3B signature.asc Description: OpenPGP digital signature
Re: ports/243787: [NEW PORT] net/mcjoin: Simple multicast testing application for UNIX
On 2020/03/01 03:35, Kurt Jaeger wrote: > Hi! > >> This contribution [0] has been awaiting attention for about four weeks, >> since 2020-02-01 22:20:44 UTC. Are there any friendly, neighborhood >> committers who would be willing and available to take it? >> >> [0] https://bugs.freebsd.org/243787 > > Done. Thanks for the cool application, I already have a use case for this 8-) > > Btw, the cause of the delay is a large surge in open ports PRs in > the last 3-5 weeks, from approx. 250 to 430. > Thank you, Kurt. I understand that folks have a lot of demands on their time, PR surge or not, and appreciate your taking the time on this one. -- John W. O'Brien OpenPGP keys: 0x33C4D64B895DBF3B signature.asc Description: OpenPGP digital signature
Maintainer timeout: databases/rrdtool bug 244808
Hello FreeBSD Ports, I believe we have exceeded the two week maintainer timeout on bug 244808 [0]. A patch has been awaiting attention since 2020-03-14T17:55:20Z. Are there any committers within earshot able and willing to take this bug? swills' buildbot recently posted a successful result. [0] databases/rrdtool: "VRULE:0" may cause segmentation fault https://bugs.freebsd.org/244808 Thank you, -- John W. O'Brien OpenPGP keys: 0x33C4D64B895DBF3B signature.asc Description: OpenPGP digital signature
