liballium attempts to reduce the amount of boilerplate code required to implement pluggable transports for Tor in C or C++. WWW: https://github.com/yawning/liballium -- This is a dependency for the port security/obfclient which I'll submit in another PR. Note that I'm intentionally not using the still-optional LICENSE "framework" in my ports until it's properly maintained, documented and the legal aspects are clear. Please do not add LICENSE* goo to this port without discussing it with me first. Thanks. Fix: Patch attached with submission follows:
I can't find security/obfclient ?? ======================= Hi, if you are still interested in having this port in FreeBSD, it may (or may not) need to be reworked to support stage, and it may need updating to other newer conventions such as "USES" which is expanding all time. For staging, see http://lists.freebsd.org/pipermail/freebsd-ports-announce/2014-May/000080.html Additionally, you need to provide some sort of quality assurance. In order of preference, we are looking for: 1) "poudriere testport" or "poudriere bulk -t" logs 2) Redports or tinderbox logs Please provide an updated shar file and attach a test log. Alternatively, please indicate if you are no longer interested in having this software in the Ports Collection and that we can close the PR. Thanks!
okay, it's bug 187927
Created attachment 145463 [details] Updated devel/liballium port The updated port builds without warnings on my 11.0-CURRENT system using DEVELOPER=yes. My impression is that Redports doesn't support Uses=libtool yet, but I'll look into this tomorrow.
If you can't do the first two options, doing this: https://www.freebsd.org/doc/en/books/porters-handbook/porting-testing.html Is a (risky for us) third option that I'd accept. Particularly interesting is output of make check-plist and make stag
Doesn't build for me. Also, while having a central licenses path is a good idea, the trend cannot be started from this port. For now, please install it into ${DOCSDIR}, like every other port. [root@lockup ~] poudriere testport -j 10amd64 -o devel/liballium ===> Configuring for liballium-0.0.1 aclocal-1.14: warning: couldn't open directory 'm4': No such file or directory configure.ac:15: installing './ar-lib' configure.ac:14: installing './compile' configure.ac:12: installing './install-sh' configure.ac:12: installing './missing' Makefile.am:11: error: Libtool library used but 'LIBTOOL' is undefined Makefile.am:11: The usual way to define 'LIBTOOL' is to add 'LT_INIT' Makefile.am:11: to 'configure.ac' and run 'aclocal' and 'autoconf' again. Makefile.am:11: If 'LT_INIT' is in 'configure.ac', make sure Makefile.am:11: its definition is in aclocal's search path. Makefile.am: installing './depcomp' parallel-tests: installing './test-driver' autoreconf-2.69: automake failed with exit status: 1 *** Error code 1 Stop. make: stopped in /usr/ports/devel/liballium
Also, instead of patching Makefile.am and adding custom CONFIGURE_ARGS, why note use instead of HAS_CONFIGURE, USES= pathfix GNU_CONFIGURE= yes
I'll just fix it. Committed with modifications.
Thanks for committing the ports and making the required fixes for 10amd64, Adam. I previously wasn't aware of USES= pathfix and GNU_CONFIGURE= yes, but agree that using them is superior to clowning around with CONFIGURE_ARGS and will use them in the future. I intentionally didn't install the license file as "documentation" because I suspect that some people build all packages without documentation to decrease the package size and assume that this does not affect whether or not the packages can be legally distributed to third parties on their own. There are indeed already lots of ports that have this issue and as far as I know there is no (documented) project policy that prohibits this, but my personal preference is to always include the license in the package (for my ports). I did not actually invent the "central license path" but used the one that is used by the undocumented LICENSE "framework", which is already used by quite a few ports. Anyway, as long as everyone involved is aware of the legal implications of treating the license file as documentation, I can live with it.
I'm confused, why isn't the license installed with the LICENSE framework, e.g. LICENSE_FILE ?
(In reply to John Marino from comment #9) > I'm confused, why isn't the license installed with the LICENSE framework, > e.g. LICENSE_FILE ? See the last paragraph of the original submission. Also, I have no idea what LICENSE_FILE does. It's not described in the PHB, and bsd.licenses.mk only says the variable exists, not what it does.
(In reply to fk from comment #8) > I intentionally didn't install the license file as "documentation" because I > suspect that some people build all packages without documentation to > decrease the package size and assume that this does not affect whether or > not the packages can be legally distributed to third parties on their own. That is my fault. I completely forgot to add a DOCS option to the port. Thank you for catching this!
(In reply to fk from comment #0) > Note that I'm intentionally not using the still-optional LICENSE "framework" > in my ports until it's properly maintained, documented and the legal aspects > are clear. Please do not add LICENSE* goo to this port without discussing it > with me first. Thanks. I would say that if the maintainer feels this way, there shouldn't be any LICENSE installed at all. I agree with him on all these points, but the solution is not roll-your-own. There's no requirement to participate, so don't. Omitting it is not incorrect. Putting it in DOCSDIR is. Adam, it's explained in Mk/bsd.license.mk
(In reply to John Marino from comment #12) > (In reply to fk from comment #0) > I would say that if the maintainer feels this way, there shouldn't be any > LICENSE installed at all. Given that we have absolutely no clear directive on what we are supposed to do or not do with licenses, I can get behind that. > I agree with him on all these points, but the solution is not roll-your-own. > There's no requirement to participate, so don't. Omitting it is not > incorrect. Putting it in DOCSDIR is. 3096 COPYING or LICENSE files are installed. 585 of them are in DOCSDIR. You can't tell me that there's no precedent. > Adam, it's explained in Mk/bsd.license.mk There is nothing explained in bsd.licenses.mk.
(In reply to Adam Weinberger from comment #13) > 3096 COPYING or LICENSE files are installed. 585 of them are in DOCSDIR. You > can't tell me that there's no precedent. I'd have a hard time, true, but I'd conjecture quite a few of those are there because of a "copy tree" command rather than be excluded intentionally. > There is nothing explained in bsd.licenses.mk. line 75? I didn't say it was great.
(In reply to John Marino from comment #14) > line 75? > I didn't say it was great. It's definitely there, but it just says the variable *exists*, not what it does. Last I remember hearing on the topic, it was decided that merely setting LICENSE was insufficient, because if any word was changed from the canonical license then we were violating terms by not distributing the provided license. So my understanding was that, to comply with the terms of the licenses, the license had to be distributed with the packaged binary.
(In reply to Adam Weinberger from comment #15) > (In reply to John Marino from comment #14) > > line 75? > > I didn't say it was great. > > It's definitely there, but it just says the variable *exists*, not what it > does. Last I remember hearing on the topic, it was decided that merely > setting LICENSE was insufficient, because if any word was changed from the > canonical license then we were violating terms by not distributing the > provided license. That came from mat@ and a lot of people pushed back on the idea that LICENCE_FILE is required unconditionally. The original thinking what that *if* the license matched word for word what ports provided, just the LICENSE= definition was enough. Of course, the license framework is a red-headed stepchild that half of us just want to go away because nobody loves it, so there's no definitive answer. > So my understanding was that, to comply with the terms of the licenses, the > license had to be distributed with the packaged binary. if LICENSE= is defined, the license is distributed with the binary. The question is where there text comes from the ports templates or from the distribution tarball (or from the ports Makefile with LICENSE_TEXT=)
> if LICENSE= is defined, the license is distributed with the binary. The > question is where there text comes from the ports templates or from the > distribution tarball (or from the ports Makefile with LICENSE_TEXT=) I definitely understand the red-headed stepchild comment. Normally, adding COPYING into PORTDOCS is easier because we're already installing other stuff. In liballium's case, it is the ONLY thing being installed in there, which makes it highly conspicuous. Really I have no opposition to removing it. I'm just concerned that if we don't set LICENSE, and we don't install a copy of the license, then we are not complying with the part that says: * Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
I see I never answered your question. if LICENSE_FILE exists, that file is installed with the binary package. All the licenses are installed in a standard location. See ".PLIST.mktemp" in WRKDIR for see how it gets added to the pkg-plist if LICENSE_FILE doesn't exist, a standard license from the Templates directory is installed instead The 2 alternative is LICENSE_TEXT which creates a file from the text (see textproc/words as an example)
we cross-posted (In reply to Adam Weinberger from comment #17) > Normally, adding COPYING into PORTDOCS is easier because we're already > installing other stuff. In liballium's case, it is the ONLY thing being > installed in there, which makes it highly conspicuous. As I mentioned before, there's a dedicated area in share/ for licenses, automatically created by the license framework so this circumvents that "standard". That's your "central" area, it already exists. > Really I have no opposition to removing it. I'm just concerned that if we > don't set LICENSE, and we don't install a copy of the license, then we are > not complying with the part that says: > > * Redistributions in binary form must reproduce the above copyright notice, > this list of conditions and the following disclaimer in the documentation > and/or other materials provided with the distribution. sure. But we are told licencing isn't mandatory and maybe thousands of ports violate that.
(In reply to John Marino from comment #18) > if LICENSE_FILE exists, that file is installed with the binary package. All > the licenses are installed in a standard location. Ahh now I understand. LICENSE_FILE does what submitter's original patch attempted to do. Fabian, it sounds like LICENSE_FILE is really the right thing to use here. Can I get your permission to use that instead of installing it into DOCSDIR manually?
(In reply to John Marino from comment #19) > As I mentioned before, there's a dedicated area in share/ for licenses, > automatically created by the license framework so this circumvents that > "standard". > > That's your "central" area, it already exists. Trying to honour submitter's request that LICENSE* not be used, it was the best idea I could come up with.
Just in case it wasn't clear: What I attempted to do in the original patch was to make sure that ${WRKSRC}/COPYING was included in packages (as that's the right thing to do assuming the license in the file covers all the upstream code and the resulting binary) without implying that the FreeBSD foundation, I or anyone else actually did a license audit to confirm this. I wouldn't mind LICENSE_FILE being set to the path of the file that, according to upstream, contains the license that is relevant, but my impression is that LICENSE_FILE only works together with LICENSE and the latter is a claim I'm not interested to make (except for the few upstream commits I did myself).
(In reply to fk from comment #22) > Just in case it wasn't clear: What I attempted to do in the original patch > was to make sure that ${WRKSRC}/COPYING was included in packages (as that's > the right thing to do assuming the license in the file covers all the > upstream code and the resulting binary) without implying that the FreeBSD > foundation, I or anyone else actually did a license audit to confirm this. That's exactly what LICENSE_FILE does, it puts that exact file in the package. > I wouldn't mind LICENSE_FILE being set to the path of the file that, > according to upstream, contains the license that is relevant, but my > impression is that LICENSE_FILE only works together with LICENSE and the > latter is a claim I'm not interested to make (except for the few upstream > commits I did myself). Each variable is independent. If you define LICENSE_FILE, you get that exact license. In fact, that is what @mat wants all ports to do.
(In reply to John Marino from comment #23) > (In reply to fk from comment #22) > > I wouldn't mind LICENSE_FILE being set to the path of the file that, > > according to upstream, contains the license that is relevant, but my > > impression is that LICENSE_FILE only works together with LICENSE and the > > latter is a claim I'm not interested to make (except for the few upstream > > commits I did myself). > > Each variable is independent. If you define LICENSE_FILE, you get that > exact license. In fact, that is what @mat wants all ports to do. The whole of bsd.licenses.mk is wrapped in .if defined(LICENSE). Using LICENSE_FILE with an unknown license also requires breaking down the license into LICENSE_PERMS. Submitter is correct that it isn't as easy as just defining LICENSE_FILE and being done with it. There is no officially sanctioned location for licenses. Thousands of other ports install their license file into DOCSDIR, and this port does the same. Fabian, if you believe that the COPYING file should go back into ${PREFIX}/share/licenses where you originally had it, I am fine with moving it there instead. Past that, I agree with you that LICENSE* is ambiguous. I'll leave the decision up to you, I am happy to move the file to share/licenses or leave it as-is and close this PR.
(In reply to Adam Weinberger from comment #24) > The whole of bsd.licenses.mk is wrapped in .if defined(LICENSE). Using > LICENSE_FILE with an unknown license also requires breaking down the license > into LICENSE_PERMS. Submitter is correct that it isn't as easy as just > defining LICENSE_FILE and being done with it. If you use a value of LICENSE that is recognized, the permissions are defined. If you use a value of LICENSE that is not recognized, you *must* define the permissions (and LICENCE_TEXT or LICENSE_FILE). If you don't want to define permissions then my recommendation is omit the license completely (as you know). That said, there are only 5 permissions, it's not that big a deal. Any normal license is going to permit all 5 things. > There is no officially sanctioned location for licenses. Thousands of other > ports install their license file into DOCSDIR, and this port does the same. It's only a matter of time before they are forcibly moved to LICENCES when somebody finally starts caring about the LICENSE framework. It's just shoving work on somebody down the road. > Fabian, if you believe that the COPYING file should go back into > ${PREFIX}/share/licenses where you originally had it, I am fine with moving > it there instead. Past that, I agree with you that LICENSE* is ambiguous. > > I'll leave the decision up to you, I am happy to move the file to > share/licenses or leave it as-is and close this PR. I'm less ambivalent. I don't really see the download to using LICENSE_FILE. If it's a matter of principle then just skip the whole thing.
(In reply to John Marino from comment #25) > > Fabian, if you believe that the COPYING file should go back into > > ${PREFIX}/share/licenses where you originally had it, I am fine with moving > > it there instead. Past that, I agree with you that LICENSE* is ambiguous. > > > > I'll leave the decision up to you, I am happy to move the file to > > share/licenses or leave it as-is and close this PR. > > I'm less ambivalent. I don't really see the download to using LICENSE_FILE. > If it's a matter of principle then just skip the whole thing. Thanks for your opinion, John, but it's Fabian's opinion, as the maintainer, that I'm after. The terms of the LICENSE make skipping the whole thing not an option.
(In reply to Adam Weinberger from comment #26) > Thanks for your opinion, John, but it's Fabian's opinion, as the maintainer, > that I'm after. The terms of the LICENSE make skipping the whole thing not > an option. I believe my point before that the fact this is not enforced in ports and thus we are not held to it is valid. By your logic we IMMEDIATELY need to fix all the ports that violate this. If you say we don't, then it is an option. Secondly, I am not actually that comfortable letting Fabian make up his own licensing scheme as a protest against licensing framework. In other words, I don't think it's his call. At this point, I'm almost ready to get portmgr involved and make a decree. Big picture -- because a lot of good points have been brought up here.
(In reply to John Marino from comment #27) > (In reply to Adam Weinberger from comment #26) > > Thanks for your opinion, John, but it's Fabian's opinion, as the maintainer, > > that I'm after. The terms of the LICENSE make skipping the whole thing not > > an option. > > I believe my point before that the fact this is not enforced in ports and > thus we are not held to it is valid. By your logic we IMMEDIATELY need to > fix all the ports that violate this. If you say we don't, then it is an > option. John, your hyperbolic statements here suggest that you're getting worked up. I would ask that you take a step back and a deep breath and/or a nice sandwich before posting more replies. I'm going to take the sandwich route myself. > Secondly, I am not actually that comfortable letting Fabian make up his own > licensing scheme as a protest against licensing framework. In other words, > I don't think it's his call. At this point, I'm almost ready to get portmgr > involved and make a decree. Big picture -- because a lot of good points > have been brought up here. John, do whatever makes you happy. I stand behind the decision to install a copy of the license, as specified by the terms of the license. Using the combination of LICENSE, LICENSE_FILE, LICENSE_NAME, and LICENSE_PERMS is not mandatory, but honouring the terms of the license is. Fabian, I and the port are not inventing a licensing scheme. We are installing a copy of the license. I ask that you re-read this, because this whole thing is coming down to you objecting to installing a copy of the license. If you would like to involve portmgr then please, by all means seek their input. For now I am going to let the port continue to install its COPYING file, and I am leaving it with the port's maintainer to choose the location he prefers to see it installed in.
(In reply to Adam Weinberger from comment #28) > John, your hyperbolic statements here suggest that you're getting worked up. > I would ask that you take a step back and a deep breath and/or a nice > sandwich before posting more replies. I'm going to take the sandwich route > myself. I don't know how this is coming across, but I'm not worked up. The only logical conclusion to that we *must* include the license is that we *must* fix all the other violators too. I don't understand any other conclusion. > John, do whatever makes you happy. I stand behind the decision to install a > copy of the license, as specified by the terms of the license. Using the > combination of LICENSE, LICENSE_FILE, LICENSE_NAME, and LICENSE_PERMS is not > mandatory, but honouring the terms of the license is. Okay, let's get's portmgr involved to finally stand behind the licence framework and make some rules. > Fabian, I and the port are not inventing a licensing scheme. We are > installing a copy of the license. I ask that you re-read this, because this > whole thing is coming down to you objecting to installing a copy of the > license. Correction: my objection is *where* to install it. I have no objection to not installing it.
(In reply to John Marino from comment #29) > Okay, let's get's portmgr involved to finally stand behind the licence > framework and make some rules. A clarification in the PHB about where license files should be installed, in an mtree-listed location, would certainly be welcome.
Trying to involve portmgr makes sense to me, too. In fact, I already tried this in the past but failed: https://lists.freebsd.org/pipermail/freebsd-ports/2014-January/089140.html And of course the legal concerns were already raised by dougb@ and others, way before the "framework" was committed (IIRC, without even acknowledging the concerns).
The distfile contains tests. They can be exposed by adding OPTIONS_DEFINE= TEST TEST_ALL_TARGET=check > MASTER_SITES= GH Redundant with USE_GITHUB. > CFLAGS+= -I${LOCALBASE}/include > LDFLAGS+= -L${LOCALBASE}/lib What the flags are used for? Did you miss adding a port dependency? > USE_AUTOTOOLS= autoconf aclocal automake ... > pre-configure: > @(cd ${WRKSRC}; ./autogen.sh) Either define USE_AUTOTOOLS="autoconf:env aclocal:env ..." or get rid of pre-configure target or convert to USES=autoreconf. Using automake also means the following ====> Running Q/A tests (stage-qa) Warning: 'lib/liballium-1.0.so.0.0.1' is not stripped consider trying INSTALL_TARGET=install-strip or using ${STRIP_CMD} > @${MKDIR} ${STAGEDIR}/${PREFIX}/share/licenses/${PKGNAME} > ${INSTALL_DATA} ${WRKSRC}/COPYING ${STAGEDIR}${PREFIX}/share/licenses/${PKGNAME} No need to have / (slash) after ${STAGEDIR} or at least keep consistency. And wrap long lines to fit on 80 characters terminal.
Please, don't keep NEW PORT bugs hanging. Either close, move to a separate bug or assign to the next responsible (portmgr?). https://svnweb.freebsd.org/changeset/ports/365738
Adam is in the middle of relocating between countries and his computer is packed up, so he's got a decent excuse. Maybe our discussion sidelined the PR but in the end he's the assignee and can do what he feels is best.
(In reply to Jan Beich from comment #33) > Please, don't keep NEW PORT bugs hanging. Either close, move to a separate > bug or assign to the next responsible (portmgr?). > > https://svnweb.freebsd.org/changeset/ports/365738 Actually, aren't we wanting for fk to implement your comments anyway?
I already approved the patch Jan submitted in Bug 187926.
(In reply to fk from comment #36) > I already approved the patch Jan submitted in Bug 187926. I don't see a patch and I don't see approval. Are you sure it's registered on the PR? All I see is your patch from 7 Aug.
D'oh, I copy and pasted the wrong bug number. It's actually Bug 194139.
wait, let me get this straight. The port doesn't yet exist, yet there's a PR to correct the shar before it's committed? This is silly. Please update the shar to take into account bug Bug 194139 so we can close Bug 194139. Also, don't forget to get rid of @dirrm. redports is worthless for QA until further notice.
The port does exist: https://svnweb.freebsd.org/ports?view=revision&revision=365738 Bug 194139 is about the remaining issues (some were already fixed by Adam).
okay, adamw listed two PRs and dfilter was broken at the time meaning neither PR got a copy of the commit. Okay, so I'm closing this PR then. I think the license worry was way blown out of proportion, but portmgr isn't responding to me consistently on more important issues so I'm not going to increase the noise with license issues (the whole license topic is a problem they refuse to address)