Re: curl and nginx no longer build on same host
On Tuesday, July 19, 2016 07:32 SGT, "Matthew D. Fuller" wrote: > On Tue, Jul 19, 2016 at 06:44:49AM +0800 I heard the voice of > Euan Thoms, and lo! it spake thus: > > > > Aha, I got ftp/curl to build using WITH_OPENSSL_PORT=yes. Don't know > > why I didn't try it before, perhaps since it is deprecated. > > > > So, I think we need to address some shortcoming in the new macro > > DEFAULT_VERSIONS+=ssl=openssl. > > That seems... odd. > > > DEFAULT_VERSIONS+=ssl=openssl > > will cause bsd.default-versions.mk to set the variable SSL_DEFAULT to > the value 'openssl'. > > Contrarily, > > > WITH_OPENSSL_PORT=yes > > will cause bsd.default-versions.mk to set the variable SSL_DEFAULT to > the value 'openssl' (unless you've got OPENSSL_PORT defined, in which > case it's set to whatever that is) and spit out a warning. > > So, unless you're setting OPENSSL_PORT, they're doing exactly the same > thing (modulo the warning). If you are (e.g., from using libressl > instead), you need to set THAT instead of 'openssl' in the > DEFAULT_VERSIONS line. > I'm not setting anything else in make.conf, the jail is otherwise vanilla, no hacks etc. In both cases I'm only using openssl, no libressl. I just noticed that after running make using WITH_OPENSSL_PORT=yes , it builds fine. Then turning the make.conf back to using DEFAULT_VERSIONS+=ssl=openssl instead of WITH_OPENSSL_PORT=yes, it now builds OK. So I did a "make config" and GSSAPI_NONE is now set. After further examiniation, it seems that coincidentally I must have done a "make rmconfig" before using WITH_OPENSSL_PORT=yes. The "make rmconfig" removes my /var/db/ports/ftp_curl/options and then the next time "make" is run the macros in make.conf set GSSAPI_NONE. So, the problem I had was that my existing installation (in a jail) had options set that the make.conf macros were not clobbering. If I had set those make.conf options/macros in the first place, I would not have the said problem. But, the macro did not exist when I did the initial installation, neither was replacing openssl from base a thing. Worth noting that I'm pretty sure I never changed any options in ftp/curl on the initial install (or previous updates via portmaster either). So just the fact that I hit enter on the ftp/curl ncurses options screen meant that in future, setting the openssl macros would not take the desired effect. Tricky one to solve I guess, I wouldn't want a macro clobbering my custom options config either. -- Regards, Euan Thoms ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: curl and nginx no longer build on same host
On Tue, Jul 19, 2016 at 06:44:49AM +0800 I heard the voice of Euan Thoms, and lo! it spake thus: > > Aha, I got ftp/curl to build using WITH_OPENSSL_PORT=yes. Don't know > why I didn't try it before, perhaps since it is deprecated. > > So, I think we need to address some shortcoming in the new macro > DEFAULT_VERSIONS+=ssl=openssl. That seems... odd. > DEFAULT_VERSIONS+=ssl=openssl will cause bsd.default-versions.mk to set the variable SSL_DEFAULT to the value 'openssl'. Contrarily, > WITH_OPENSSL_PORT=yes will cause bsd.default-versions.mk to set the variable SSL_DEFAULT to the value 'openssl' (unless you've got OPENSSL_PORT defined, in which case it's set to whatever that is) and spit out a warning. So, unless you're setting OPENSSL_PORT, they're doing exactly the same thing (modulo the warning). If you are (e.g., from using libressl instead), you need to set THAT instead of 'openssl' in the DEFAULT_VERSIONS line. -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: curl and nginx no longer build on same host
Hello, > On Jul 18, 2016, at 6:44 PM, Euan Thoms wrote: > > >> On Tuesday, July 19, 2016 05:11 SGT, Jim Ohlstein wrote: >> >> Hello, >> >>> On Jul 18, 2016, at 4:37 PM, Euan Thoms wrote: > > >>> OK, I'm clear about the make.conf options and what they mean. But I still >>> have a problem in that even if I use DEFAULT_VERSIONS+=ssl=openssl, >>> ftp/curl will not build, certainly not with portmaster and I think I tried >>> building it manually from inside it's ports directory. >>> >>> /usr/ports/ftp/curl]# make >>> ===> curl-7.49.1 GSSAPI_BASE is not compatible with OpenSSL from ports. Use >>> other GSSAPI options or OpenSSL from base system. >>> *** Error code 1 >>> >>> Stop. >>> make: stopped in /usr/ports/ftp/curl >>> >>> >>> So basically, I'd have to change one of the GSSAPI options in ftp/curl. >>> Except I haven't got a clue on the ramifications of this. Do I need GSSAPI? >>> If so, should I use Heimdal or MIT? >>> >>> So you see my point, it's not friendly on new FreeBSD users. I'm a fairly >>> experienced FreeBSD sys-adimin and I don't know what to do in this case. >>> >>> At least I now know that there is a good reason to not have on port built >>> against base openssl and another built against ports openssl. >> >> So basically they've deprecated a useful option without replicating the >> functionality. Bravo! >> >> Fortunately, it still works as intended. > > > Aha, I got ftp/curl to build using WITH_OPENSSL_PORT=yes. Don't know why I > didn't try it before, perhaps since it is deprecated. > > So, I think we need to address some shortcoming in the new macro > DEFAULT_VERSIONS+=ssl=openssl. > > Perhaps I should create a new thread, with a more appropriate subject line? > Any suggestions? That's evidently above my pay grade. I recall recently there was a discussion of building all ports against the openssl port. It got lengthy and I stopped reading it. That's what that function does. Deprecating that function without forcing use of the openssl port was not wise IMMHO, but again, my opinion apparently doesn't matter. -- Jim ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: curl and nginx no longer build on same host
On Tuesday, July 19, 2016 05:11 SGT, Jim Ohlstein wrote: > Hello, > > > On Jul 18, 2016, at 4:37 PM, Euan Thoms wrote: > > > > OK, I'm clear about the make.conf options and what they mean. But I still > > have a problem in that even if I use DEFAULT_VERSIONS+=ssl=openssl, > > ftp/curl will not build, certainly not with portmaster and I think I tried > > building it manually from inside it's ports directory. > > > > /usr/ports/ftp/curl]# make > > ===> curl-7.49.1 GSSAPI_BASE is not compatible with OpenSSL from ports. Use > > other GSSAPI options or OpenSSL from base system. > > *** Error code 1 > > > > Stop. > > make: stopped in /usr/ports/ftp/curl > > > > > > So basically, I'd have to change one of the GSSAPI options in ftp/curl. > > Except I haven't got a clue on the ramifications of this. Do I need GSSAPI? > > If so, should I use Heimdal or MIT? > > > > So you see my point, it's not friendly on new FreeBSD users. I'm a fairly > > experienced FreeBSD sys-adimin and I don't know what to do in this case. > > > > At least I now know that there is a good reason to not have on port built > > against base openssl and another built against ports openssl. > > So basically they've deprecated a useful option without replicating the > functionality. Bravo! > > Fortunately, it still works as intended. > Aha, I got ftp/curl to build using WITH_OPENSSL_PORT=yes. Don't know why I didn't try it before, perhaps since it is deprecated. So, I think we need to address some shortcoming in the new macro DEFAULT_VERSIONS+=ssl=openssl. Perhaps I should create a new thread, with a more appropriate subject line? Any suggestions? -- Regards, Euan Thoms ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: is this a problem with screen, pkg or portupgrade?
It's a set of integers separated by dots, not a floating-point number (even less when there are 2 dots), so he 4.04 != 4.4 comparison doesn't apply here, it is (4, 04, 0) == (4, 4, 0). Anyway the issue here - if there is one - is with GNU Screen, not the port. On 2016-07-18 15:28:02, tech-lists wrote: > On 18/07/2016 14:27, Pierre Guinoiseau wrote: > > Why do you think there is a problem? 4.04.00 == 4.4.0 (and not 4.0.4), > > everything is fine, just ignore the leading zeros. ;) > > That makes no sense and is inconsistent WRT other numbering and > versioning. $4.04 is not $4.4 - applying leading zeros inconsistently in > a versioning string is stupid. > > -- > J. > ___ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" -- Pierre Guinoiseau https://segmentationfau.lt/ | +PierreGuinoiseau | @peikk00 signature.asc Description: PGP signature
Re: curl and nginx no longer build on same host
Hello, > On Jul 18, 2016, at 4:37 PM, Euan Thoms wrote: > > >> On Tuesday, July 19, 2016 04:03 SGT, Kevin Oberman >> wrote: >> >>> On Mon, Jul 18, 2016 at 12:45 PM, Euan Thoms wrote: >>> >>> >>> On Saturday, July 16, 2016 20:43 SGT, Jim Ohlstein wrote: > >>> >>> OK, I understand. And I'm glad we're heading somewhere where we will have >>> more consistency. I just feel that we shouldn't need anything in >>> /etc/make.conf unless we are exerting some extra control and using > >>> non-default options. I've managed to get away without anything in >>> /etc/make.conf on all my jails, collectively they install quite a range of >>> software types. >>> >>> Are you sure that WITH_OPENSSL_PORT isn't deprecated. I got some warnings >>> to that effect. So I've been using USES+=ssl=openssl instead. Perhaps >>> that's part of the problem, maybe the ftp/curl port is still using the >>> older make.conf flag. I'll try it next time I update. >>> >>> Thanks Jim. > >> >> Yes and no. WITH_OPENSSL_PORT in make,conf has been deprecated. It should >> still work, but you should update to the new syntax. If you do use it, you >> should see the following: >> "Using WITH_OPENSSL_PORT in make.conf is deprecated, replace it with >> DEFAULT_VERSIONS+=ssl=openssl in your make.conf" >> >> To avoid conflicting SSL libraries in different ports, it is bast to put >> the "DEFAULT_VERSIONS+=ssl=openssl" in /etc/make.conf. If you use base >> OpsnSSL in some ports that create shareable libraries and the ports version >> in others, you will eventually hit an executable, possibly from a third >> port, that is linked to both and those programs will not run. > > OK, I'm clear about the make.conf options and what they mean. But I still > have a problem in that even if I use DEFAULT_VERSIONS+=ssl=openssl, ftp/curl > will not build, certainly not with portmaster and I think I tried building it > manually from inside it's ports directory. > > /usr/ports/ftp/curl]# make > ===> curl-7.49.1 GSSAPI_BASE is not compatible with OpenSSL from ports. Use > other GSSAPI options or OpenSSL from base system. > *** Error code 1 > > Stop. > make: stopped in /usr/ports/ftp/curl > > > So basically, I'd have to change one of the GSSAPI options in ftp/curl. > Except I haven't got a clue on the ramifications of this. Do I need GSSAPI? > If so, should I use Heimdal or MIT? > > So you see my point, it's not friendly on new FreeBSD users. I'm a fairly > experienced FreeBSD sys-adimin and I don't know what to do in this case. > > At least I now know that there is a good reason to not have on port built > against base openssl and another built against ports openssl. So basically they've deprecated a useful option without replicating the functionality. Bravo! Fortunately, it still works as intended. -- Jim ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: curl and nginx no longer build on same host
On Tuesday, July 19, 2016 04:03 SGT, Kevin Oberman wrote: > On Mon, Jul 18, 2016 at 12:45 PM, Euan Thoms wrote: > > > > > On Saturday, July 16, 2016 20:43 SGT, Jim Ohlstein wrote: > > > > OK, I understand. And I'm glad we're heading somewhere where we will have > > more consistency. I just feel that we shouldn't need anything in > > /etc/make.conf unless we are exerting some extra control and using > > non-default options. I've managed to get away without anything in > > /etc/make.conf on all my jails, collectively they install quite a range of > > software types. > > > > Are you sure that WITH_OPENSSL_PORT isn't deprecated. I got some warnings > > to that effect. So I've been using USES+=ssl=openssl instead. Perhaps > > that's part of the problem, maybe the ftp/curl port is still using the > > older make.conf flag. I'll try it next time I update. > > > > Thanks Jim. > > > > Yes and no. WITH_OPENSSL_PORT in make,conf has been deprecated. It should > still work, but you should update to the new syntax. If you do use it, you > should see the following: > "Using WITH_OPENSSL_PORT in make.conf is deprecated, replace it with > DEFAULT_VERSIONS+=ssl=openssl in your make.conf" > > To avoid conflicting SSL libraries in different ports, it is bast to put > the "DEFAULT_VERSIONS+=ssl=openssl" in /etc/make.conf. If you use base > OpsnSSL in some ports that create shareable libraries and the ports version > in others, you will eventually hit an executable, possibly from a third > port, that is linked to both and those programs will not run. OK, I'm clear about the make.conf options and what they mean. But I still have a problem in that even if I use DEFAULT_VERSIONS+=ssl=openssl, ftp/curl will not build, certainly not with portmaster and I think I tried building it manually from inside it's ports directory. /usr/ports/ftp/curl]# make ===> curl-7.49.1 GSSAPI_BASE is not compatible with OpenSSL from ports. Use other GSSAPI options or OpenSSL from base system. *** Error code 1 Stop. make: stopped in /usr/ports/ftp/curl So basically, I'd have to change one of the GSSAPI options in ftp/curl. Except I haven't got a clue on the ramifications of this. Do I need GSSAPI? If so, should I use Heimdal or MIT? So you see my point, it's not friendly on new FreeBSD users. I'm a fairly experienced FreeBSD sys-adimin and I don't know what to do in this case. At least I now know that there is a good reason to not have on port built against base openssl and another built against ports openssl. -- Regards, Euan Thoms ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: curl and nginx no longer build on same host
On Mon, Jul 18, 2016 at 12:45 PM, Euan Thoms wrote: > > On Saturday, July 16, 2016 20:43 SGT, Jim Ohlstein wrote: > > > Hello, > > > > On 7/15/16 11:41 PM, Euan Thoms wrote: > > > > > > Yes. I've used ssl=openssl and ssl=libressl in make.conf, no luck with > either. The bottom line is ftp/curl with default port options does not want > to build against openssl or libressl from ports. And it doesn't want to try > and use the base openssl either. > > > > > > Your point about the port options for http2 requiring the ports > version of openssl is valid. But this happens when the default options for > both ports are used. I could accept my manual workaround if I had changed > the default port options on either of the two ports. But default port > options should build together. > > > > > > I suppose this has only come about on this upgrade cycle because nginx > port now has http2 on by default? > > > > As of version 1.10.0 it appears http2 is selected by default. It has > > been the default in www/nginx-devel for some time. it is not the default > > for ftp/curl: > > > > OPTIONS_DEFAULT=CA_BUNDLE COOKIES OPENSSL PROXY RESOLV > > THREADED_RESOLVER TLS_SRP > > > > My /etc/make.conf has the following: > > > > WITH_OPENSSL_PORT=yes > > > > That will force ftp/curl (and all ports) to build against the openssl > > port. If I understand correctly, that is about to become the default > > behavior for all ports at some time in the not so distant future, or at > > least it has been proposed. > > > > OK, I understand. And I'm glad we're heading somewhere where we will have > more consistency. I just feel that we shouldn't need anything in > /etc/make.conf unless we are exerting some extra control and using > non-default options. I've managed to get away without anything in > /etc/make.conf on all my jails, collectively they install quite a range of > software types. > > Are you sure that WITH_OPENSSL_PORT isn't deprecated. I got some warnings > to that effect. So I've been using USES+=ssl=openssl instead. Perhaps > that's part of the problem, maybe the ftp/curl port is still using the > older make.conf flag. I'll try it next time I update. > > Thanks Jim. > > -- > Regards, Euan Thoms > Yes and no. WITH_OPENSSL_PORT in make,conf has been deprecated. It should still work, but you should update to the new syntax. If you do use it, you should see the following: "Using WITH_OPENSSL_PORT in make.conf is deprecated, replace it with DEFAULT_VERSIONS+=ssl=openssl in your make.conf" To avoid conflicting SSL libraries in different ports, it is bast to put the "DEFAULT_VERSIONS+=ssl=openssl" in /etc/make.conf. If you use base OpsnSSL in some ports that create shareable libraries and the ports version in others, you will eventually hit an executable, possibly from a third port, that is linked to both and those programs will not run. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: curl and nginx no longer build on same host
On Saturday, July 16, 2016 20:43 SGT, Jim Ohlstein wrote: > Hello, > > On 7/15/16 11:41 PM, Euan Thoms wrote: > > > > Yes. I've used ssl=openssl and ssl=libressl in make.conf, no luck with > > either. The bottom line is ftp/curl with default port options does not want > > to build against openssl or libressl from ports. And it doesn't want to try > > and use the base openssl either. > > > > Your point about the port options for http2 requiring the ports version of > > openssl is valid. But this happens when the default options for both ports > > are used. I could accept my manual workaround if I had changed the default > > port options on either of the two ports. But default port options should > > build together. > > > > I suppose this has only come about on this upgrade cycle because nginx port > > now has http2 on by default? > > As of version 1.10.0 it appears http2 is selected by default. It has > been the default in www/nginx-devel for some time. it is not the default > for ftp/curl: > > OPTIONS_DEFAULT=CA_BUNDLE COOKIES OPENSSL PROXY RESOLV > THREADED_RESOLVER TLS_SRP > > My /etc/make.conf has the following: > > WITH_OPENSSL_PORT=yes > > That will force ftp/curl (and all ports) to build against the openssl > port. If I understand correctly, that is about to become the default > behavior for all ports at some time in the not so distant future, or at > least it has been proposed. > OK, I understand. And I'm glad we're heading somewhere where we will have more consistency. I just feel that we shouldn't need anything in /etc/make.conf unless we are exerting some extra control and using non-default options. I've managed to get away without anything in /etc/make.conf on all my jails, collectively they install quite a range of software types. Are you sure that WITH_OPENSSL_PORT isn't deprecated. I got some warnings to that effect. So I've been using USES+=ssl=openssl instead. Perhaps that's part of the problem, maybe the ftp/curl port is still using the older make.conf flag. I'll try it next time I update. Thanks Jim. -- Regards, Euan Thoms ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: www/nextcloud patch needs a committer
Hi! > Done. Please note that 9.0.53 is out due to > > https://httpoxy.org/ > http://cert.at/warnings/all/20160718.html > > Can you provide a patch ? I've put one up at: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211206 Please check and approve. -- p...@opsec.eu+49 171 3101372 4 years to go ! ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: www/nextcloud patch needs a committer
Hi! > Someone commits a patch i tested and validated for nextcloud > 9.0.52, can someone commit ? Done. Please note that 9.0.53 is out due to https://httpoxy.org/ http://cert.at/warnings/all/20160718.html Can you provide a patch ? -- p...@opsec.eu+49 171 3101372 4 years to go ! ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ! mDNSResponder Port update Error
Walter, 17.07.2016, 22:54, "Walter Schwarzenfeld" : > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210723 > > The patch is working for me. Can confirm that it is working for me as well, thanks! -- Brendan ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: is this a problem with screen, pkg or portupgrade?
Yup everything is good it's just the way screen does versions sometimes. On Jul 18, 2016 8:28 AM, "Pierre Guinoiseau" wrote: > Why do you think there is a problem? 4.04.00 == 4.4.0 (and not 4.0.4), > everything is fine, just ignore the leading zeros. ;) > > On 19/07/2016 00:58, tech-lists wrote: > > Hi, > > > > I saw in /usr/ports/UPDATING that special consideration needed to be > > given to screen in order to update it from 4.0.4 to 4.4.0. So I made > > sure I had no screens running, refreshed the ports tree (r418696), > > checked the version I was going to upgrade (4.0.4) and ran portupgrade > > -a. To my surprise, subsequent screen -v gave: > > > > Screen version 4.04.00 (GNU) 19-Jun-16 > > > > So I thought maybe I'd mistyped something so I ran > > > > root@www:~ pkg delete screen > > > > Updating database digests format: 100% > > Checking integrity... done (0 conflicting) > > Deinstallation has been requested for the following 1 packages (of 0 > > packages in the universe): > > > > Installed packages to be REMOVED: > > screen-4.4.0_1 > > > > Number of packages to be removed: 1 > > > > Proceed with deinstalling packages? [y/N]: y > > [1/1] Deinstalling screen-4.4.0_1... > > [1/1] Deleting files for screen-4.4.0_1: 100% > > root@www:~ screen -v > > -bash: /usr/local/bin/screen: No such file or directory > > > > ...then ran > > > > root@www:~ # cd /usr/ports/sysutils/screen > > root@www:/usr/ports/sysutils/screen # make install > > > > ...saw it was building > > > > ===> License GPLv3 accepted by the user > > ===> Found saved configuration for screen-4.4.0_1 > > ===> screen-4.4.0_1 depends on file: /usr/local/sbin/pkg - found > > ===> Fetching all distfiles required by screen-4.4.0_1 for building > > ===> Extracting for screen-4.4.0_1 > > => SHA256 Checksum OK for screen-4.4.0.tar.gz. > > ===> Patching for screen-4.4.0_1 > > ===> Applying extra patch > /usr/ports/sysutils/screen/files/opt-showencoding > > ===> Applying FreeBSD patches for screen-4.4.0_1 > > ===> screen-4.4.0_1 depends on executable: gmake - found > > ===> screen-4.4.0_1 depends on file: /usr/local/bin/ccache - found > > ===> Configuring for screen-4.4.0_1 > > configure: loading site script /usr/ports/Templates/config.site > > this is screen version 4.4.0 > > checking for gcc... cc > > checking whether the C compiler works... yes > > > > [snip lots of output] > > > > At the end I get the usual kind of message: > > > > > Compressing man pages (compress-man) > > ===> Installing for screen-4.4.0_1 > > ===> Checking if screen already installed > > ===> Registering installation for screen-4.4.0_1 > > Installing screen-4.4.0_1... > > = > > > > As of GNU Screen 4.4.0: > > > > Note that there was fix to screen message structure field > > responsible for $TERM handling, making it impossible > > to attach to older versions. > > > > = > > > > ===> SECURITY REPORT: > > This port has installed the following binaries which execute with > > increased privileges. > > /usr/local/bin/screen > > > > This port has installed the following files which may act as network > > servers and may therefore pose a remote security risk to the system. > > /usr/local/bin/screen > > > > If there are vulnerabilities in these programs there may be a security > > risk to the system. FreeBSD makes no guarantee about the security of > > ports included in the Ports Collection. Please type 'make deinstall' > > to deinstall the port if this is a concern. > > > > For more information, and contact details about the security > > status of this software, see the following webpage: > > http://www.gnu.org/software/screen/ > > > > ..so I check the version again: > > > > root@www:~ # screen -v > > Screen version 4.04.00 (GNU) 19-Jun-16 > > root@www:~ # > > > > ? > > > > pkg info screen gives: > > > > root@www:~ # pkg info screen > > screen-4.4.0_1 > > Name : screen > > Version: 4.4.0_1 > > Installed on : Mon Jul 18 13:11:25 2016 BST > > Origin : sysutils/screen > > Architecture : freebsd:11:x86:64 > > Prefix : /usr/local > > Categories : sysutils > > Licenses : GPLv3 > > Maintainer : c...@freebsd.org > > WWW: http://www.gnu.org/software/screen/ > > Comment: Multi-screen window manager > > > > ? > > > > thanks, > > > > -- > Pierre Guinoiseau > https://segmentationfau.lt/ | +PierreGuinoiseau | @peikk00 > > ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: is this a problem with screen, pkg or portupgrade?
On 18/07/2016 14:27, Pierre Guinoiseau wrote: > Why do you think there is a problem? 4.04.00 == 4.4.0 (and not 4.0.4), > everything is fine, just ignore the leading zeros. ;) That makes no sense and is inconsistent WRT other numbering and versioning. $4.04 is not $4.4 - applying leading zeros inconsistently in a versioning string is stupid. -- J. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: is this a problem with screen, pkg or portupgrade?
Why do you think there is a problem? 4.04.00 == 4.4.0 (and not 4.0.4), everything is fine, just ignore the leading zeros. ;) On 19/07/2016 00:58, tech-lists wrote: > Hi, > > I saw in /usr/ports/UPDATING that special consideration needed to be > given to screen in order to update it from 4.0.4 to 4.4.0. So I made > sure I had no screens running, refreshed the ports tree (r418696), > checked the version I was going to upgrade (4.0.4) and ran portupgrade > -a. To my surprise, subsequent screen -v gave: > > Screen version 4.04.00 (GNU) 19-Jun-16 > > So I thought maybe I'd mistyped something so I ran > > root@www:~ pkg delete screen > > Updating database digests format: 100% > Checking integrity... done (0 conflicting) > Deinstallation has been requested for the following 1 packages (of 0 > packages in the universe): > > Installed packages to be REMOVED: > screen-4.4.0_1 > > Number of packages to be removed: 1 > > Proceed with deinstalling packages? [y/N]: y > [1/1] Deinstalling screen-4.4.0_1... > [1/1] Deleting files for screen-4.4.0_1: 100% > root@www:~ screen -v > -bash: /usr/local/bin/screen: No such file or directory > > ...then ran > > root@www:~ # cd /usr/ports/sysutils/screen > root@www:/usr/ports/sysutils/screen # make install > > ...saw it was building > > ===> License GPLv3 accepted by the user > ===> Found saved configuration for screen-4.4.0_1 > ===> screen-4.4.0_1 depends on file: /usr/local/sbin/pkg - found > ===> Fetching all distfiles required by screen-4.4.0_1 for building > ===> Extracting for screen-4.4.0_1 > => SHA256 Checksum OK for screen-4.4.0.tar.gz. > ===> Patching for screen-4.4.0_1 > ===> Applying extra patch /usr/ports/sysutils/screen/files/opt-showencoding > ===> Applying FreeBSD patches for screen-4.4.0_1 > ===> screen-4.4.0_1 depends on executable: gmake - found > ===> screen-4.4.0_1 depends on file: /usr/local/bin/ccache - found > ===> Configuring for screen-4.4.0_1 > configure: loading site script /usr/ports/Templates/config.site > this is screen version 4.4.0 > checking for gcc... cc > checking whether the C compiler works... yes > > [snip lots of output] > > At the end I get the usual kind of message: > > > Compressing man pages (compress-man) > ===> Installing for screen-4.4.0_1 > ===> Checking if screen already installed > ===> Registering installation for screen-4.4.0_1 > Installing screen-4.4.0_1... > = > > As of GNU Screen 4.4.0: > > Note that there was fix to screen message structure field > responsible for $TERM handling, making it impossible > to attach to older versions. > > = > > ===> SECURITY REPORT: > This port has installed the following binaries which execute with > increased privileges. > /usr/local/bin/screen > > This port has installed the following files which may act as network > servers and may therefore pose a remote security risk to the system. > /usr/local/bin/screen > > If there are vulnerabilities in these programs there may be a security > risk to the system. FreeBSD makes no guarantee about the security of > ports included in the Ports Collection. Please type 'make deinstall' > to deinstall the port if this is a concern. > > For more information, and contact details about the security > status of this software, see the following webpage: > http://www.gnu.org/software/screen/ > > ..so I check the version again: > > root@www:~ # screen -v > Screen version 4.04.00 (GNU) 19-Jun-16 > root@www:~ # > > ? > > pkg info screen gives: > > root@www:~ # pkg info screen > screen-4.4.0_1 > Name : screen > Version: 4.4.0_1 > Installed on : Mon Jul 18 13:11:25 2016 BST > Origin : sysutils/screen > Architecture : freebsd:11:x86:64 > Prefix : /usr/local > Categories : sysutils > Licenses : GPLv3 > Maintainer : c...@freebsd.org > WWW: http://www.gnu.org/software/screen/ > Comment: Multi-screen window manager > > ? > > thanks, > -- Pierre Guinoiseau https://segmentationfau.lt/ | +PierreGuinoiseau | @peikk00 signature.asc Description: OpenPGP digital signature
Re: Porting OpenCPN
On 18/07/2016 10:52 PM, Andrea Venturoli wrote: > On 07/13/16 11:50, Kubilay Kocak wrote: > >> For GitHub there is ports infrastructure, using USE_GITHUB=yes and GH_* >> variables. For usage, see our Porters Handbook: >> https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/book.html#makefile-master_sites-github-description >> > > Hello and thanks for your answer. > I saw that description, but I really couldn't understand if the port > system will issue a "git clone" or still expect the tarball somewhere. The framework uses the variables provided in the port to construct a URL that obtains a tarball via GitHub's API. It is fetched via /archive/, the same method as the 'download as zip/tar' buttons in the GitHub web interface It is a snapshot of the repository code at that tag, branch or revision, not a clone of the repository. > In any case, as Thierry pointed out (thanks!), the tarball is there, so > this is over. > The distributions in /releases/ are separate and different (and may or may not be the same as the raw/pure sources) ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
is this a problem with screen, pkg or portupgrade?
Hi, I saw in /usr/ports/UPDATING that special consideration needed to be given to screen in order to update it from 4.0.4 to 4.4.0. So I made sure I had no screens running, refreshed the ports tree (r418696), checked the version I was going to upgrade (4.0.4) and ran portupgrade -a. To my surprise, subsequent screen -v gave: Screen version 4.04.00 (GNU) 19-Jun-16 So I thought maybe I'd mistyped something so I ran root@www:~ pkg delete screen Updating database digests format: 100% Checking integrity... done (0 conflicting) Deinstallation has been requested for the following 1 packages (of 0 packages in the universe): Installed packages to be REMOVED: screen-4.4.0_1 Number of packages to be removed: 1 Proceed with deinstalling packages? [y/N]: y [1/1] Deinstalling screen-4.4.0_1... [1/1] Deleting files for screen-4.4.0_1: 100% root@www:~ screen -v -bash: /usr/local/bin/screen: No such file or directory ...then ran root@www:~ # cd /usr/ports/sysutils/screen root@www:/usr/ports/sysutils/screen # make install ...saw it was building ===> License GPLv3 accepted by the user ===> Found saved configuration for screen-4.4.0_1 ===> screen-4.4.0_1 depends on file: /usr/local/sbin/pkg - found ===> Fetching all distfiles required by screen-4.4.0_1 for building ===> Extracting for screen-4.4.0_1 => SHA256 Checksum OK for screen-4.4.0.tar.gz. ===> Patching for screen-4.4.0_1 ===> Applying extra patch /usr/ports/sysutils/screen/files/opt-showencoding ===> Applying FreeBSD patches for screen-4.4.0_1 ===> screen-4.4.0_1 depends on executable: gmake - found ===> screen-4.4.0_1 depends on file: /usr/local/bin/ccache - found ===> Configuring for screen-4.4.0_1 configure: loading site script /usr/ports/Templates/config.site this is screen version 4.4.0 checking for gcc... cc checking whether the C compiler works... yes [snip lots of output] At the end I get the usual kind of message: > Compressing man pages (compress-man) ===> Installing for screen-4.4.0_1 ===> Checking if screen already installed ===> Registering installation for screen-4.4.0_1 Installing screen-4.4.0_1... = As of GNU Screen 4.4.0: Note that there was fix to screen message structure field responsible for $TERM handling, making it impossible to attach to older versions. = ===> SECURITY REPORT: This port has installed the following binaries which execute with increased privileges. /usr/local/bin/screen This port has installed the following files which may act as network servers and may therefore pose a remote security risk to the system. /usr/local/bin/screen If there are vulnerabilities in these programs there may be a security risk to the system. FreeBSD makes no guarantee about the security of ports included in the Ports Collection. Please type 'make deinstall' to deinstall the port if this is a concern. For more information, and contact details about the security status of this software, see the following webpage: http://www.gnu.org/software/screen/ ..so I check the version again: root@www:~ # screen -v Screen version 4.04.00 (GNU) 19-Jun-16 root@www:~ # ? pkg info screen gives: root@www:~ # pkg info screen screen-4.4.0_1 Name : screen Version: 4.4.0_1 Installed on : Mon Jul 18 13:11:25 2016 BST Origin : sysutils/screen Architecture : freebsd:11:x86:64 Prefix : /usr/local Categories : sysutils Licenses : GPLv3 Maintainer : c...@freebsd.org WWW: http://www.gnu.org/software/screen/ Comment: Multi-screen window manager ? thanks, -- J. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Porting OpenCPN
On 07/13/16 11:50, Kubilay Kocak wrote: For GitHub there is ports infrastructure, using USE_GITHUB=yes and GH_* variables. For usage, see our Porters Handbook: https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/book.html#makefile-master_sites-github-description Hello and thanks for your answer. I saw that description, but I really couldn't understand if the port system will issue a "git clone" or still expect the tarball somewhere. In any case, as Thierry pointed out (thanks!), the tarball is there, so this is over. I submitted a PR for the new port. bye & Thanks av. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
www/nextcloud patch needs a committer
Hi, Someone commits a patch i tested and validated for nextcloud 9.0.52, can someone commit ? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211007 (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211007) Thanks in advance! Loïc Blot ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
