Re: Problem building py-cryptography

[Simon Wright]

On 20/05/2021 12:32 pm, Kubilay Kocak wrote:

On 20/05/2021 2:17 pm, Simon Wright wrote:

On 20/05/2021 12:00 pm, Kubilay Kocak wrote:

On 20/05/2021 1:21 pm, Simon Wright wrote:

Hi all,

I've been unable to build security/py-cryptography for about 10 days
now. The build in Poudriere under 12.2 and 13.0 fail with a
"Bad_C++_code" error.

I tried removing the libressl dependency but that made no
difference. Is
anyone else seeing this and can anyone point me in the right direction
to get this fixed please?

Below is my make.conf, list of poudriere-built ports and the full
poudriere log for py-cryptography



Hi Simon,

Is the issue reproducible without ccache?

Also, make.conf still shows:

DEFAULT_VERSIONS+=ssl=libressl



Thanks Kubs. When I tested I removed libressl, tried the build again and
it failed so I replaced libressl after the test.

Removing ccache (and with libressl) made no difference - still the same
error. I then removed the libressl dependency and I reran the build - no
ccache and no libressl - the build still failed, same error message.

Since no-one else has reported this I suppose it should be something in
my environment . . . . But what? :)


While the build error *with libressl* is known, matching that reported in:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255241

Failing to build without libressl is unexpected.

Jump into the poudriere jail to confirm (or not) its libressl that's
being installed and used.  Could be:

  - Custom WRKDIRPREFIX?
  - An overriding jail or set (-z) specific poudriere foo-make.conf?


Hi all,

Here is the new py-cryptography build log with no libressl and no ccache.

make.conf

WRKDIRPREFIX=/usr/tmp
#WRKDIRPREFIX=/tmp/drupal7
OPTIONS_SET=GECKO CUPS
NOI4B=1
OPTIONS_SET+=NO-X11
#OPTIONS_UNSET+=X11 GUI CUPS DOCS EXAMPLES NLS LPR
CUPS_OVERWRITE_BASE=YES
WITH_VIM_OPTIONS=yes
#DEFAULT_VERSIONS+=ssl=libressl bdb=5
DEFAULT_VERSIONS+=bdb=5
VALID_CATEGORIES+=local
SVN=svnlite
#WITH_OPENSSL_PORT=yes


/usr/local/etc/poudriere.d/make.conf

VALID_CATEGORIES+=local
#DEFAULT_VERSIONS+=ssl=libressl bdb=5
#DEFAULT_VERSIONS+=ssl=libressl
DEFAULT_VERSIONS+=bdb=5
OPTIONS_SET+=NO-X11
OVERLAYS=local
#DEFAULT_VERSIONS+=ssl=port
#DEVELOPER=yes
LICENSES_ACCEPTED=NONE

There is no jail-specific make.conf or -z options set.

And see this extract from the full build log:

===
===>   py38-cryptography-3.3.2 depends on package: py38-cffi>=1.8 - not
found
===>   Installing existing package /packages/All/py38-cffi-1.14.5.txz
[pkg.home.santos-wright.net] Installing py38-cffi-1.14.5...
[pkg.home.santos-wright.net] `-- Installing libffi-3.3_1...
[pkg.home.santos-wright.net] |   `-- Installing indexinfo-0.3.1...
[pkg.home.santos-wright.net] |   `-- Extracting indexinfo-0.3.1:  done
[pkg.home.santos-wright.net] `-- Extracting libffi-3.3_1: .. done
[pkg.home.santos-wright.net] `-- Installing py38-pycparser-2.20...
[pkg.home.santos-wright.net] |   `-- Installing py38-setuptools-44.0.0_1...
[pkg.home.santos-wright.net] |   | `-- Installing python38-3.8.10...
[pkg.home.santos-wright.net] |   |   `-- Installing gettext-runtime-0.21...
[pkg.home.santos-wright.net] |   |   `-- Extracting
gettext-runtime-0.21: .. done
[pkg.home.santos-wright.net] |   |   `-- Installing libressl-3.3.3...
[pkg.home.santos-wright.net] |   |   `-- Extracting libressl-3.3.3:
.. done
[pkg.home.santos-wright.net] |   |   `-- Installing mpdecimal-2.5.1...
[pkg.home.santos-wright.net] |   |   `-- Extracting mpdecimal-2.5.1:
.. done
[pkg.home.santos-wright.net] |   |   `-- Installing readline-8.1.1...
[pkg.home.santos-wright.net] |   |   `-- Extracting readline-8.1.1:
.. done
[pkg.home.santos-wright.net] |   | `-- Extracting python38-3.8.10:
.. done
[pkg.home.santos-wright.net] |   `-- Extracting
py38-setuptools-44.0.0_1: .. done
[pkg.home.santos-wright.net] `-- Extracting py38-pycparser-2.20:
.. done
[pkg.home.santos-wright.net] Extracting py38-cffi-1.14.5: .. done
=

It looks to me as though python38 is pulling in libressl. Python options
are default though not sure whether options were specifically set.

simon@vmserver04:/usr/ports/lang/python38$ sudo make showconfig
===> The following configuration options are available for python38-3.8.10:
 DEBUG=off: Build with debugging support
 IPV6=on: IPv6 protocol support
 LIBFFI=on: Use libffi from ports instead of bundled version
 LIBMPDEC=on: Use libmpdec from ports instead of bundled version
 NLS=on: Enable gettext support for the locale module
 PYMALLOC=on: Enable specialized mallocs
> Hash Algorithm (PEP-456): you can only select none or one of them
 FNV=off: Modified Fowler-Noll-Vo Algorithm
 SIPHASH=off: SipHash24 Algorithm
===> Use 'make config' to modify these settings

I've just removed the config options for python (make rmconfig) and
poudirere is now rebuild

Re: Problem building py-cryptography

[Simon Wright]

Thanks Kubs, I'm travelling at the moment and will check further when I'm 
back home. The original build log was with libressl and ccache. I'll 
repeat without both and attach a new build log.


Apologies for the top post.

Regards,

Simon.

20 May 2021 13:50:54 Kubilay Kocak :


On 20/05/2021 2:17 pm, Simon Wright wrote:

On 20/05/2021 12:00 pm, Kubilay Kocak wrote:

On 20/05/2021 1:21 pm, Simon Wright wrote:

Hi all,

I've been unable to build security/py-cryptography for about 10 days
now. The build in Poudriere under 12.2 and 13.0 fail with a
"Bad_C++_code" error.

I tried removing the libressl dependency but that made no 
difference. Is
anyone else seeing this and can anyone point me in the right 
direction

to get this fixed please?

Below is my make.conf, list of poudriere-built ports and the full
poudriere log for py-cryptography



Hi Simon,

Is the issue reproducible without ccache?

Also, make.conf still shows:

DEFAULT_VERSIONS+=ssl=libressl

Thanks Kubs. When I tested I removed libressl, tried the build again 
and

it failed so I replaced libressl after the test.
Removing ccache (and with libressl) made no difference - still the 
same
error. I then removed the libressl dependency and I reran the build - 
no

ccache and no libressl - the build still failed, same error message.
Since no-one else has reported this I suppose it should be something 
in

my environment . . . . But what? :)


While the build error *with libressl* is known, matching that reported 
in:


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255241

Failing to build without libressl is unexpected.

Jump into the poudriere jail to confirm (or not) its libressl that's 
being installed and used.  Could be:


  - Custom WRKDIRPREFIX?
  - An overriding jail or set (-z) specific poudriere foo-make.conf?

Note, the OP build log contains:

[pkg.home.santos-wright.net] |   |   `-- Installing libressl-3.3.3...
[pkg.home.santos-wright.net] |   |   `-- Extracting libressl-3.3.3:

With defaults, base openssl will be used, and you wont see libressl as 
a dependency in the build.


[1] build/temp.freebsd-13.0-RELEASE-amd64-3.8/_openssl.c:2172:19: 
error:

expected identifier or '('
static const long SSL_OP_NO_DTLSv1 = 0;


Regards,
Simon.




make.conf

WRKDIRPREFIX=/usr/tmp
OPTIONS_SET=GECKO CUPS
NOI4B=1
OPTIONS_SET+=NO-X11
CUPS_OVERWRITE_BASE=YES
WITH_VIM_OPTIONS=yes
DEFAULT_VERSIONS+=ssl=libressl bdb=5
VALID_CATEGORIES+=local
SVN=svnlite


Poudriere ports list:

devel/git@lite
dns/bind916
emulators/open-vm-tools@nox11
ftp/curl
graphics/cairo
local/vmserver-baseline
mail/postfix
print/hplip
sysutils/facter
sysutils/puppet6
sysutils/rsyslog8
sysutils/rubygem-puppetserver-ca
www/apt-cacher-ng
www/mod_log_sql



___
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"

___
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: Problem building py-cryptography

[Simon Wright]

Thanks Kubs, I'm travelling at the moment and will check further when I'm 
back home. The original build log was with libressl and ccache. I'll 
repeat without both and attach a new build log.


Apologies for the top post.

Regards,

Simon.

20 May 2021 13:50:54 Kubilay Kocak :


On 20/05/2021 2:17 pm, Simon Wright wrote:

On 20/05/2021 12:00 pm, Kubilay Kocak wrote:

On 20/05/2021 1:21 pm, Simon Wright wrote:

Hi all,

I've been unable to build security/py-cryptography for about 10 days
now. The build in Poudriere under 12.2 and 13.0 fail with a
"Bad_C++_code" error.

I tried removing the libressl dependency but that made no 
difference. Is
anyone else seeing this and can anyone point me in the right 
direction

to get this fixed please?

Below is my make.conf, list of poudriere-built ports and the full
poudriere log for py-cryptography



Hi Simon,

Is the issue reproducible without ccache?

Also, make.conf still shows:

DEFAULT_VERSIONS+=ssl=libressl

Thanks Kubs. When I tested I removed libressl, tried the build again 
and

it failed so I replaced libressl after the test.
Removing ccache (and with libressl) made no difference - still the 
same
error. I then removed the libressl dependency and I reran the build - 
no

ccache and no libressl - the build still failed, same error message.
Since no-one else has reported this I suppose it should be something 
in

my environment . . . . But what? :)


While the build error *with libressl* is known, matching that reported 
in:


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255241

Failing to build without libressl is unexpected.

Jump into the poudriere jail to confirm (or not) its libressl that's 
being installed and used.  Could be:


  - Custom WRKDIRPREFIX?
  - An overriding jail or set (-z) specific poudriere foo-make.conf?

Note, the OP build log contains:

[pkg.home.santos-wright.net] |   |   `-- Installing libressl-3.3.3...
[pkg.home.santos-wright.net] |   |   `-- Extracting libressl-3.3.3:

With defaults, base openssl will be used, and you wont see libressl as 
a dependency in the build.


[1] build/temp.freebsd-13.0-RELEASE-amd64-3.8/_openssl.c:2172:19: 
error:

expected identifier or '('
static const long SSL_OP_NO_DTLSv1 = 0;


Regards,
Simon.




make.conf

WRKDIRPREFIX=/usr/tmp
OPTIONS_SET=GECKO CUPS
NOI4B=1
OPTIONS_SET+=NO-X11
CUPS_OVERWRITE_BASE=YES
WITH_VIM_OPTIONS=yes
DEFAULT_VERSIONS+=ssl=libressl bdb=5
VALID_CATEGORIES+=local
SVN=svnlite


Poudriere ports list:

devel/git@lite
dns/bind916
emulators/open-vm-tools@nox11
ftp/curl
graphics/cairo
local/vmserver-baseline
mail/postfix
print/hplip
sysutils/facter
sysutils/puppet6
sysutils/rsyslog8
sysutils/rubygem-puppetserver-ca
www/apt-cacher-ng
www/mod_log_sql



___
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"

___
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: Problem building py-cryptography

[Simon Wright]

On 20/05/2021 12:00 pm, Kubilay Kocak wrote:

On 20/05/2021 1:21 pm, Simon Wright wrote:

Hi all,

I've been unable to build security/py-cryptography for about 10 days
now. The build in Poudriere under 12.2 and 13.0 fail with a
"Bad_C++_code" error.

I tried removing the libressl dependency but that made no difference. Is
anyone else seeing this and can anyone point me in the right direction
to get this fixed please?

Below is my make.conf, list of poudriere-built ports and the full
poudriere log for py-cryptography



Hi Simon,

Is the issue reproducible without ccache?

Also, make.conf still shows:

DEFAULT_VERSIONS+=ssl=libressl



Thanks Kubs. When I tested I removed libressl, tried the build again and 
it failed so I replaced libressl after the test.


Removing ccache (and with libressl) made no difference - still the same 
error. I then removed the libressl dependency and I reran the build - no 
ccache and no libressl - the build still failed, same error message.


Since no-one else has reported this I suppose it should be something in 
my environment . . . . But what? :)


Regards,

Simon.





make.conf

WRKDIRPREFIX=/usr/tmp
OPTIONS_SET=GECKO CUPS
NOI4B=1
OPTIONS_SET+=NO-X11
CUPS_OVERWRITE_BASE=YES
WITH_VIM_OPTIONS=yes
DEFAULT_VERSIONS+=ssl=libressl bdb=5
VALID_CATEGORIES+=local
SVN=svnlite


Poudriere ports list:

devel/git@lite
dns/bind916
emulators/open-vm-tools@nox11
ftp/curl
graphics/cairo
local/vmserver-baseline
mail/postfix
print/hplip
sysutils/facter
sysutils/puppet6
sysutils/rsyslog8
sysutils/rubygem-puppetserver-ca
www/apt-cacher-ng
www/mod_log_sql



___
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: Problem building py-cryptography

[Simon Wright]

On 20/05/2021 12:00 pm, Kubilay Kocak wrote:

On 20/05/2021 1:21 pm, Simon Wright wrote:

Hi all,

I've been unable to build security/py-cryptography for about 10 days
now. The build in Poudriere under 12.2 and 13.0 fail with a
"Bad_C++_code" error.

I tried removing the libressl dependency but that made no difference. Is
anyone else seeing this and can anyone point me in the right direction
to get this fixed please?

Below is my make.conf, list of poudriere-built ports and the full
poudriere log for py-cryptography



Hi Simon,

Is the issue reproducible without ccache?

Also, make.conf still shows:

DEFAULT_VERSIONS+=ssl=libressl



Thanks Kubs. When I tested I removed libressl, tried the build again and
it failed so I replaced libressl after the test.

Removing ccache (and with libressl) made no difference - still the same
error. I then removed the libressl dependency and I reran the build - no
ccache and no libressl - the build still failed, same error message.

Since no-one else has reported this I suppose it should be something in
my environment . . . . But what? :)

Regards,

Simon.





make.conf

WRKDIRPREFIX=/usr/tmp
OPTIONS_SET=GECKO CUPS
NOI4B=1
OPTIONS_SET+=NO-X11
CUPS_OVERWRITE_BASE=YES
WITH_VIM_OPTIONS=yes
DEFAULT_VERSIONS+=ssl=libressl bdb=5
VALID_CATEGORIES+=local
SVN=svnlite


Poudriere ports list:

devel/git@lite
dns/bind916
emulators/open-vm-tools@nox11
ftp/curl
graphics/cairo
local/vmserver-baseline
mail/postfix
print/hplip
sysutils/facter
sysutils/puppet6
sysutils/rsyslog8
sysutils/rubygem-puppetserver-ca
www/apt-cacher-ng
www/mod_log_sql



___
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"

Problem building py-cryptography

[Simon Wright]

Hi all,

I've been unable to build security/py-cryptography for about 10 days
now. The build in Poudriere under 12.2 and 13.0 fail with a
"Bad_C++_code" error.

I tried removing the libressl dependency but that made no difference. Is
anyone else seeing this and can anyone point me in the right direction
to get this fixed please?

Below is my make.conf, list of poudriere-built ports and the full
poudriere log for py-cryptography

Thanks,

Simon Wright.



make.conf

WRKDIRPREFIX=/usr/tmp
OPTIONS_SET=GECKO CUPS
NOI4B=1
OPTIONS_SET+=NO-X11
CUPS_OVERWRITE_BASE=YES
WITH_VIM_OPTIONS=yes
DEFAULT_VERSIONS+=ssl=libressl bdb=5
VALID_CATEGORIES+=local
SVN=svnlite


Poudriere ports list:

devel/git@lite
dns/bind916
emulators/open-vm-tools@nox11
ftp/curl
graphics/cairo
local/vmserver-baseline
mail/postfix
print/hplip
sysutils/facter
sysutils/puppet6
sysutils/rsyslog8
sysutils/rubygem-puppetserver-ca
www/apt-cacher-ng
www/mod_log_sql


Poudriere build log:

=>> Building security/py-cryptography
build started at Thu May 20 10:58:41 PST 2021
port directory: /usr/ports/security/py-cryptography
package name: py38-cryptography-3.3.2
building for: FreeBSD pkg.home.santos-wright.net 13.0-RELEASE FreeBSD
13.0-RELEASE amd64
maintained by: ko...@freebsd.org
Makefile ident:
Poudriere version: 3.3.99.20210303_2
Host OSVERSION: 1300139
Jail OSVERSION: 1300139
Job Id: 01

---Begin Environment---
SHELL=/bin/csh
OSVERSION=1300139
UNAME_v=FreeBSD 13.0-RELEASE
UNAME_r=13.0-RELEASE
BLOCKSIZE=K
MAIL=/var/mail/root
MM_CHARSET=UTF-8
LANG=C.UTF-8
STATUS=1
HOME=/root
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin
LOCALBASE=/usr/local
USER=root
LIBEXECPREFIX=/usr/local/libexec/poudriere
POUDRIERE_VERSION=3.3.99.20210303_2
MASTERMNT=/export/poudriere/data/.m/FreeBSD_13_amd64-default/ref
LC_COLLATE=C
POUDRIERE_BUILD_TYPE=bulk
PACKAGE_BUILDING=yes
SAVED_TERM=xterm-256color
OUTPUT_REDIRECTED_STDERR=4
OUTPUT_REDIRECTED=1
PWD=/export/poudriere/data/.m/FreeBSD_13_amd64-default/ref/.p/pool
OUTPUT_REDIRECTED_STDOUT=3
P_PORTS_FEATURES=FLAVORS SELECTED_OPTIONS
MASTERNAME=FreeBSD:13:amd64-default
SCRIPTPREFIX=/usr/local/share/poudriere
OLDPWD=/export/poudriere/data/.m/FreeBSD_13_amd64-default/ref/.p
SCRIPTPATH=/usr/local/share/poudriere/bulk.sh
POUDRIEREPATH=/usr/local/bin/poudriere
---End Environment---

---Begin Poudriere Port Flags/Env---
PORT_FLAGS=
PKGENV=
FLAVOR=py38
DEPENDS_ARGS=
MAKE_ARGS= FLAVOR=py38
---End Poudriere Port Flags/Env---

---Begin OPTIONS List---
---End OPTIONS List---

--MAINTAINER--
ko...@freebsd.org
--End MAINTAINER--

--CONFIGURE_ARGS--

--End CONFIGURE_ARGS--

--CONFIGURE_ENV--
PYTHON="/usr/local/bin/python3.8"
XDG_DATA_HOME=/wrkdirs/usr/ports/security/py-cryptography/work-py38
XDG_CONFIG_HOME=/wrkdirs/usr/ports/security/py-cryptography/work-py38
HOME=/wrkdirs/usr/ports/security/py-cryptography/work-py38 TMPDIR="/tmp"
PATH=/wrkdirs/usr/ports/security/py-cryptography/work-py38/.bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin
SHELL=/bin/sh CONFIG_SHELL=/bin/sh
--End CONFIGURE_ENV--

--MAKE_ENV--
OPENSSLBASE=/usr/local OPENSSLDIR=/usr/local/openssl
OPENSSLINC=/usr/local/include OPENSSLLIB=/usr/local/lib
OPENSSLRPATH=/usr/local/lib
XDG_DATA_HOME=/wrkdirs/usr/ports/security/py-cryptography/work-py38
XDG_CONFIG_HOME=/wrkdirs/usr/ports/security/py-cryptography/work-py38
HOME=/wrkdirs/usr/ports/security/py-cryptography/work-py38 TMPDIR="/tmp"
PATH=/wrkdirs/usr/ports/security/py-cryptography/work-py38/.bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin
NO_PIE=yes MK_DEBUG_FILES=no MK_KERNEL_SYMBOLS=no SHELL=/bin/sh
NO_LINT=YES LDSHARED="cc -shared" PYTHONDONTWRITEBYTECODE=
PYTHONOPTIMIZE= PREFIX=/usr/local  LOCALBASE=/usr/local  CC="cc"
CFLAGS="-O2 -pipe  -I/usr/local/include -fstack-protector-strong
-fno-strict-aliasing "  CPP="cpp" CPPFLAGS=""  LDFLAGS="
-L/usr/local/lib -Wl,-rpath,/usr/local/lib -fstack-protector-strong "
LIBS=""  CXX="c++" CXXFLAGS="-O2 -pipe -I/usr/local/include
-fstack-protector-strong -fno-strict-aliasing  "  MANPREFIX="/usr/local"
BSD_INSTALL_PROGRAM="install  -s -m 555"  BSD_INSTALL_LIB="install  -s
-m 0644"  BSD_INSTALL_SCRIPT="install  -m 555"
BSD_INSTALL_DATA="install  -m 0644"  BSD_INSTALL_MAN="install  -m 444"
--End MAKE_ENV--

--PLIST_SUB--
PYTHON_INCLUDEDIR=include/python3.8  PYTHON_LIBDIR=lib/python3.8
PYTHON_PLATFORM=freebsd13  PYTHON_SITELIBDIR=lib/python3.8/site-packages
 PYTHON_SUFFIX=38  PYTHON_EXT_SUFFIX=.cpython-38  PYTHON_VER=3.8
PYTHON_VERSION=python3.8 PYTHON2="@comment " PYTHON3="" OSREL=13.0
PREFIX=%D LOCALBASE=/usr/local  RESETPREFIX=/usr/local LIB32DIR=lib
DOCSDIR="share/doc/py38-cryptography"
EXAMPLESDIR="share/examples/py38-cryptography

Re: Additional filtering on pkg-status.freebsd.org url

[Simon Wright]

Totally perfect. Thank you Michael :).

On 08/05/2021 5:53 pm, Michael Gmelin wrote:



On Sat, 8 May 2021 17:46:03 +0800
Simon Wright  wrote:


Hi all,

The move to git for ports is more or less OK for me now, thanks to
several for the various pointers. I still have issues with accessing
the individual build machine due to IPv6 issues on my side so am using
pkg-status.freebsd.org to check the status of the build cluster rather
than the specific machine that is building for my desired
architecture.

My (minor) issue now is that accessing:

https://pkg-status.freebsd.org/builds?type=package

gives me a long list of builds. I'm looking for a way to pass a search
string of '130amd64' in the URL so that I can go straight to the
builds that I'm interested in. Is this possible? Encoding

AND Search='130amd64'

in the URL does not work. Can anyone point me in the right direction
for this?


Does this show what you want?

https://pkg-status.freebsd.org/builds?jailname=130amd64=package

Best



Thanks,

Simon Wright.
___
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"





___
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"

Additional filtering on pkg-status.freebsd.org url

[Simon Wright]

Hi all,

The move to git for ports is more or less OK for me now, thanks to
several for the various pointers. I still have issues with accessing the
individual build machine due to IPv6 issues on my side so am using
pkg-status.freebsd.org to check the status of the build cluster rather
than the specific machine that is building for my desired architecture.

My (minor) issue now is that accessing:

https://pkg-status.freebsd.org/builds?type=package

gives me a long list of builds. I'm looking for a way to pass a search
string of '130amd64' in the URL so that I can go straight to the builds
that I'm interested in. Is this possible? Encoding

AND Search='130amd64'

in the URL does not work. Can anyone point me in the right direction for
this?

Thanks,

Simon Wright.
___
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: misc/compat11x pkg-descr correction

[Simon Wright]

Thank you for checking this Adriaan.

On 27/04/2021 6:20 pm, Adriaan de Groot wrote:

On Tuesday, 27 April 2021 11:23:51 CEST freebsd-ports-requ...@freebsd.org
wrote:

From: Simon Wright 
To: freebsd-ports@freebsd.org
Subject: Bug 242248 - misc/compat11x pkg-descr correction [PATCH],
 committer love pls!
Message-ID: <6c276940-b0e4-28f6-8bb3-c373b3642...@gmx.net>
Content-Type: text/plain; charset=utf-8; format=flowed

Hi all,

Would any committer with a few spare cycles please look at the
correction to the pkg-descr in compat11x? It's a very minor issue but so
quick to fix :).

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242248


The pkg-descr was fixed a year ago, but the PR wasn't closed; the PORTREVISION
at the time wasn't bumped like in the patch you provided. I'm not going to
bump it now, though, and have closed the PR.

[ade]


___
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"

Bug 242248 - misc/compat11x pkg-descr correction [PATCH], committer love pls!

[Simon Wright]

Hi all,

Would any committer with a few spare cycles please look at the
correction to the pkg-descr in compat11x? It's a very minor issue but so
quick to fix :).

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242248

Thanks,

Simon.
___
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: Access to detailed status info on package build servers

[Simon Wright]

On 14/04/2021 2:46 pm, Ronald Klop wrote:

Van: Kevin Oberman 
Datum: 14 april 2021 08:31
Aan: Simon Wright 
CC: FreeBSD Ports ML 
Onderwerp: Re: Access to detailed status info on package build servers




On Tue, Apr 13, 2021 at 11:02 PM Simon Wright 
wrote:

> Hi all,
>
>
> I use a script to pull down this file:
>
> http://beefy6.nyi.freebsd.org/data/122amd64-default/.data.json
>
> and extract the builds.latest field from it for the jail. Since the
move
> to git I can no longer access this file. Curl fails with an error 7
> which is a permission denied error.
>
> Simon Wright.
>
This is likely not your problem, but Is it possible that you have an IPv6
issue? As of a few days ago, beefy6 is IPv6 only. For me, it means no
access unless I bring up a tunnel as Frontier does not support IPv6. Next
week I'll be moving to Comcast and that will fix the problem. Since it
appears that Frontier has no plans to ever support IPv6 on fiber, or at
least not for several years, I guess an HE tunnel is the only fix if I
want
500 Mbps FIOS.


If it is because of ipv6 you can also wrap the url in a service like
http://www.ipv6proxy.net/
I use that sometimes to access the pkg servers.


Regards,
Ronald


Thanks Kevin and Roland, this is an ipv6 issue, wrapping the URL in the
proxy that Ronald suggested works fine. I know that Globe in Philippines
has only just been dragged screaming into the 20th century so I imagine
that the 21st century is still some way off :).

Thanks again for the guidance. I will escalate this with Globe and see
whether there is a real solution in the offing, otherwise I'd better get
used to more work-arounds in the future.
___
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"

Access to detailed status info on package build servers

[Simon Wright]

Hi all,

As detailed in other threads, I have been tracking the latest complete
build information on the package build servers (actually on
beefy6.ny.freebsd.org) in order to synchronise my ports tree with the
ports tree used by the build servers. This is so that the packages that
I build locally are as far as possible in sync with the packages
available from the freebsd mirrors.

I use a script to pull down this file:

http://beefy6.nyi.freebsd.org/data/122amd64-default/.data.json

and extract the builds.latest field from it for the jail. Since the move
to git I can no longer access this file. Curl fails with an error 7
which is a permission denied error.

This is the command line I have been using:
/sbin/curl -so -
http://beefy6.nyi.freebsd.org/data/122amd64-default/.data.json

Can anyone suggest another source for this data? Does the pkg-status
server have this info in a JSON file somewhere? It is on the status page
for the build here:

https://pkg-status.freebsd.org/builds/default:default:122amd64:4c2cc95952a6:beefy6

Build 4c2cc95952a6
Serverbeefy6
Statusstopped:done:
Jail  122amd64
Set   default
Ports Tree  default
Build type  Package
Start time  2021-04-10 01:01
Elapsed   99:04:36
SVN

Or is it possible to return the access permissions for this
server/directory/file to what they were last week?

Thanks for any guidance.

Simon Wright.
___
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: Specific svn/git package update use case

[Simon Wright]

Great, that answers all my questions thank you very much!

Just need to wait for the package build process to run again (the last
status for 122amd64-default was stoped: crashed:) so that I can test
properly.

On 10/04/2021 1:20 am, Mark Millard via freebsd-ports wrote:

Simon Wright simon.wright at gmx.net wrote on
Fri Apr 9 10:12:04 UTC 2021 :


Excellent Mark, thank you, then that is exactly what I need, the git
equivilent of svn up -r xx ${portsdir}.

And is there a need to do git-commit or git-merge to deal with the
'detached HEAD' message or can I just suppress this? Any local
modifications live in an overlay for poudriere to use so there is
nothing unique in my /usr/ports and I only track main, no other branches.


So far as I know, you could just ignore the messages about
detached HEAD for your intended style of use, if I
understand your usage correctly.

You may have other git use besides FreeBSD ports (now or
someday), so I'm cautious about claiming the specifics
below are fully appropriate, but you could do something
like:

git config --global advice.detachedHead false

to make detached HEADs status easier to ignore: no more
messages, or at least in fewer contexts. (I'm unsure if
it would disable git status reporting on the that
specific type of status information.)

As indicated already, you may want to periodically use
git status to cross-check on if something unexpected
happened in your use that should be cleaned up.


On 09/04/2021 1:23 pm, Mark Millard via freebsd-ports wrote:

Simon Wright simon.wright at gmx.net wrote on
Fri Apr 9 02:48:47 UTC 2021 :


I'm still not clear though whether checking out this commit brings in
all the commits from git clone to this one or only this commit. My
reading seems to say that this is *only* this one commit which is not my
need. Can anyone confirm this please?


[My wording is not trying to be explicit about multi-branch
merge points. Nor does it try to deal much with if you have
local changes or staged changes in place at the time of the
activity or if you have extra files not checked into git in
the tree as well. And so on: a simple same-branch context.]

A commit hash/id identifies everything on the branch at the
time the commit finished, including what did not change
compared to the prior commit on the branch. Checking out the
commit spans all of it. Jumping forward (or backward) a bunch
of commits on a branch does not require doing them one by one
to get the net effect.

You may want to inspect after checkouts (or similar activity)
that "git status" does not display any surprises that need
to be cleaned up in the local file system via some variant(s)
of git restore or/and git clean or the like.


===
Mark Millard
marklmi at yahoo.com

___
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: Specific svn/git package update use case

[Simon Wright]

Excellent Mark, thank you, then that is exactly what I need, the git
equivilent of svn up -r xx ${portsdir}.

And is there a need to do git-commit or git-merge to deal with the
'detached HEAD' message or can I just suppress this? Any local
modifications live in an overlay for poudriere to use so there is
nothing unique in my /usr/ports and I only track main, no other branches.

On 09/04/2021 1:23 pm, Mark Millard via freebsd-ports wrote:

Simon Wright simon.wright at gmx.net wrote on
Fri Apr 9 02:48:47 UTC 2021 :


I'm still not clear though whether checking out this commit brings in
all the commits from git clone to this one or only this commit. My
reading seems to say that this is *only* this one commit which is not my
need. Can anyone confirm this please?


[My wording is not trying to be explicit about multi-branch
merge points. Nor does it try to deal much with if you have
local changes or staged changes in place at the time of the
activity or if you have extra files not checked into git in
the tree as well. And so on: a simple same-branch context.]

A commit hash/id identifies everything on the branch at the
time the commit finished, including what did not change
compared to the prior commit on the branch. Checking out the
commit spans all of it. Jumping forward (or backward) a bunch
of commits on a branch does not require doing them one by one
to get the net effect.

You may want to inspect after checkouts (or similar activity)
that "git status" does not display any surprises that need
to be cleaned up in the local file system via some variant(s)
of git restore or/and git clean or the like.

===
Mark Millard
marklmi at yahoo.com

___
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: Specific svn/git package update use case

[Simon Wright]

Thanks for this Dewayne. I have worked out the outlines of how the new
process works, it's the specifics of how it will impact my personal
process that I'm not clear about :).

With Masachika's help I now know how to link the build number as
reported by Poudriere to the git commit. That is trivial to feed to my
script though I do have a couple of other questions which I raised
further down the thread.

On 09/04/2021 11:08 am, Dewayne Geraghty wrote:

On 4/04/2021 12:30 pm, Simon Wright wrote:

Hi all,

I've been following the discussion about the git upgrade to the ports
repro but am not clear about how it impacts my use case.

At the moment I track ports on the revision that the Freebsd build
cluster uses to build the "latest" package set. I take the currently
reported latest build revision number from Poudriere on the appropriate
package build box, update my ports tree to that revision using svn on a
Debian box then use the resulting port tree to build my few ports and
dependencies locally with somewhat different build options from default
then export the resulting package set to my local machines. This process
has been working satisfactorily for several years now. My systems are
always running the same package set as "latest".

My question is: is the poudriere build process going to change and will
the build cluster still report the latest build in a form that I can
feed to git on Debian to update my ports tree to the same level as the
Freebsd package server?

As of today I am still seeing the Latest build version on
http://beefy6.nyi.freebsd.org/jail.html?mastername=122amd64-default/
reported as svn revision 569609 and updating my ports using svn works.



Unfortunately svn is frozen at
Revision: 569609
which I'm sure will disenfranchise some.

I'd suggest that you search this mail-list for
"Re: I run poudriere - what do I need to do once ports switch over to git?"
Though it is not something we use.

This may help https://wiki.freebsd.org/git
specifically https://github.com/lwhsu/freebsd-git-docs/blob/main/URLs.md

The reason(s) for moving to git are described here
https://github.com/bsdimp/freebsd-git-docs/

I've also found Ed Maste's email "Proposed ports git transition
schedule" helpful.



My apologies if I've missed this in the discussion or referenced docs
and thanks for any guidance or pointers.

___
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: Specific svn/git package update use case

[Simon Wright]

Thank you. I had to delete and recreate the repro as non-shallow to get
the commit history but once done then I could find the commit and update
to it.

Follow-up:
I'm still not clear though whether checking out this commit brings in
all the commits from git clone to this one or only this commit. My
reading seems to say that this is *only* this one commit which is not my
need. Can anyone confirm this please?

Second follow-up:

After the checkout I receive this message:
==
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

  git switch -c 

Or undo this operation with:

  git switch -

Turn off this advice by setting config variable advice.detachedHead to false
HEAD is now at c3c627b0656 devel/jenkins-lts: Update to 2.277.2
==

I don't want to create a new branch but "fix" or merge the checkout into
my local branch? Or can I just leave it as is?

Thanks,

Simon.


On 09/04/2021 9:02 am, Masachika ISHIZUKA wrote:

[/share/freebsd_ports] # git pull c3c627b06563
fatal: 'c3c627b06563' does not appear to be a git repository
fatal: Could not read from remote repository.


First, check the commit.
% git log| grep c3c627b06563
commit c3c627b06563cd0c7bcc4f491cd9c6f50716033b

Then checkout it.
% git checkout c3c627b06563cd0c7bcc4f491cd9c6f50716033b


___
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: Specific svn/git package update use case

[Simon Wright]

Update:

From beefy6.nyi.freebsd.org I can now see the poudriere build status.
This shows the last build as being c3c627b06563 (with status stopped:
crashed:). My issue now is: is it possible to relate this build number
to a specific git revision? Or am I looking in the wrong place? I want
to find out which revision is on the build box and pull all revisions up
to and including this revision in order to get the same revision locally
as the build box uses.

Is this possible?

[/share/freebsd_ports] # git pull c3c627b06563
fatal: 'c3c627b06563' does not appear to be a git repository
fatal: Could not read from remote repository.

Thanks,

Simon.

On 04/04/2021 10:30 am, Simon Wright wrote:

Hi all,

I've been following the discussion about the git upgrade to the ports
repro but am not clear about how it impacts my use case.

At the moment I track ports on the revision that the Freebsd build
cluster uses to build the "latest" package set. I take the currently
reported latest build revision number from Poudriere on the appropriate
package build box, update my ports tree to that revision using svn on a
Debian box then use the resulting port tree to build my few ports and
dependencies locally with somewhat different build options from default
then export the resulting package set to my local machines. This process
has been working satisfactorily for several years now. My systems are
always running the same package set as "latest".

My question is: is the poudriere build process going to change and will
the build cluster still report the latest build in a form that I can
feed to git on Debian to update my ports tree to the same level as the
Freebsd package server?

As of today I am still seeing the Latest build version on
http://beefy6.nyi.freebsd.org/jail.html?mastername=122amd64-default/
reported as svn revision 569609 and updating my ports using svn works.

My apologies if I've missed this in the discussion or referenced docs
and thanks for any guidance or pointers.

Simon Wright.
___
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"

___
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"

Specific svn/git package update use case

[Simon Wright]

Hi all,

I've been following the discussion about the git upgrade to the ports
repro but am not clear about how it impacts my use case.

At the moment I track ports on the revision that the Freebsd build
cluster uses to build the "latest" package set. I take the currently
reported latest build revision number from Poudriere on the appropriate
package build box, update my ports tree to that revision using svn on a
Debian box then use the resulting port tree to build my few ports and
dependencies locally with somewhat different build options from default
then export the resulting package set to my local machines. This process
has been working satisfactorily for several years now. My systems are
always running the same package set as "latest".

My question is: is the poudriere build process going to change and will
the build cluster still report the latest build in a form that I can
feed to git on Debian to update my ports tree to the same level as the
Freebsd package server?

As of today I am still seeing the Latest build version on
http://beefy6.nyi.freebsd.org/jail.html?mastername=122amd64-default/
reported as svn revision 569609 and updating my ports using svn works.

My apologies if I've missed this in the discussion or referenced docs
and thanks for any guidance or pointers.

Simon Wright.
___
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: pkg feature request

[Simon Wright]

On 12/08/2020 5:51 am, Mateusz Piotrowski wrote:

On 8/11/20 9:39 PM, Mike Clarke wrote:

On Sunday, 9 August 2020 17:27:01 BST RW via freebsd-ports wrote:



What I'd like to see is a simple way to update the ports tree to match
what was used to build the current packages in the repository.

Something I've felt in need of for a long time, and suggested from
time to time
in the past.

What we need is a pkg command which returns the revision number of the
ports tree which was used to build the current repository. When
provided with
that information I could run "svnlite up -q -r $REV $PORTSDIR" to keep
my ports
and packages in sync.


I also think that would be great.


+1
___
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: Updating poudriere jail

[Simon Wright]

On 14/12/2018 05:41, Kurt Jaeger wrote:


I am using FreeBSD 11.2-RELEASE-p6. If I use freebsd-update to install the
new version 12, what do I have to do to update the poudriere jail? Plus, if I
do update, will I have to rebuild all of my installed applications?


I had a jail '120' created as

poudriere jail -c -v 12.0-RC3 -a amd64 -j 120

I updated it with this:

poudriere jail -u -t 12.0-RELEASE -j 120


+1

This upgrade command line has worked for me since 10.x for major and 
minor upgrades. Yes you will have to let poudriere rebuild your apps 
since the build process will clean your pkg repro on any jail updates.


--
Simon Wright.
--
Simon Wright
Public key: http://www.santos-wright.net/pki/publickey.gpg



smime.p7s
Description: S/MIME Cryptographic Signature

Re: gettng the port revision number associated with the pkg repo.

[Simon Wright]

On 02/10/2017 22:19, Julian Elischer wrote:

On 28/9/17 9:25 pm, Lowell Gilbert wrote:

Julian Elischer  writes:


On 26/9/17 10:07 pm, Lowell Gilbert wrote:

Julian Elischer  writes:

SO imagine that I needed to be ab;e to reproduce the pkg repo 
as of a
articular day, is there anywhere one can look to see the svn 
revision

number that corresponds to teh current pkg files.


I would like to take a snapshot at a particular revision.. but 
how do

I find out what the revision was when the build was kicked off?
If you want to do that after the fact, I'm not sure how you'd 
specify
when you want the information for. But if you do it when you 
kick off

the build (or if you haven't changed the tree since), svnversion(1)
will tell you.


I mean for the official pkg repo..

is there a file somewhere that says "these packages are as of 
r443234"?

Sorry that I misunderstood your intent.

I am fairly sure that what you want exists somewhere, but I can't 
find

it at the moment.


Unfortunately neither can I.


Hi Julian, Lowell

I need this information so that I can start my poudriere builds with 
my quite small list of ports with non-standard options from the same 
revision as the pkg system. I use a somewhat modified version of 
this script:


https://gist.github.com/reedacartwright/8622973baf89b263a6d7

Thanks to Reed for creating and maintaining this.

--
Simon.
___
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"

Bug 215153: sysutils/apcupsd, change default options to enable SNMP driver

[Simon Wright]

Hi all,

I requested this change to sysutils/apcupsd so that it will be 
possible to access/control/monitor UPS's across the network out of 
the box. At present due to the SNMP driver not being enabled in the 
default settings this is not possible.


The maintainer has not responded to the bug or follow-up mails. 
Would any committer be able to look at this suggestion and the 
included patch?


Any feedback appreciated.

Thanks,

Simon.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Poudriere package builds for 101amd64-default have not run since 1-Jan-2017

[Simon Wright]

On 14/01/2017 15:26, Mathieu Arnold wrote:

Le 14/01/2017 à 05:57, Simon Wright a écrit :

Hi all

I sync my local ports tree to the same release as is used to build
packages. Checking my logs and the logs on beefy6 which is/was the

Has anything changed with the build system or are there issues? There
are a few security issues in r430183 which I guess are fixed in more


Adding to what was already said, builds are often shuffled around
without any notice, and the beefyX boxes should never be accessed
directly, if you really need this kind of informations,
pkg-status.freebsd.org is the place to go to.


Thanks Mathieu, that points me to the solution: pull the json file 
from pkg-status.freebsd.org instead of beefy6 and parse it for the 
build info for the jail I'm interested in. In this case whichever 
jail is building 10.x packages. That will give me the revision for 
the latest completed package-build run then I can go back to 
synching to that ports revision and building my ~30 packages with 
non-default options from that rather than the latest available.


My system is a bit of a cludge since it is not possible to directly 
pull the revision info used to build a given package or group of 
packages. Ideally this would be included in the output of pkg info 
or similar command. If we could do that, the whole process would be 
much more straightforward. I realise that trying to keep a local 
ports tree and poudriere system in sync with the build cluster will 
never be completely correct and prone to breakage, but it (mostly!) 
works for my small-scale deployment . . . .


Thanks again for the tip, have a good weekend!

Simon.



smime.p7s
Description: S/MIME Cryptographic Signature

Poudriere package builds for 101amd64-default have not run since 1-Jan-2017

[Simon Wright]

Hi all

I sync my local ports tree to the same release as is used to build 
packages. Checking my logs and the logs on beefy6 which is/was the 
build box for 101amd64-default, I find that the latest run completed 
at 13.27 on 1-Jan and used r430183.


Has anything changed with the build system or are there issues? 
There are a few security issues in r430183 which I guess are fixed 
in more current revisions. We are currently at r431456 for the ports 
tree.


If anyone has any info or links to updates or changes . . . .

Cheers,

Simon Wright.



smime.p7s
Description: S/MIME Cryptographic Signature

www/drupal6 www/drupal7: Security patches submitted (bugs 200956 200957)

[Simon Wright]

Hi all

I have submitted patches to apply needed security updates to Drupal 
6  7 and the corresponding Poudriere logs. Would a committer be 
able to have a look please?


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200956

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200957

Many thanks,

Simon Wright.
___
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

Re: Synchronising ports with package cluster

[Simon Wright]

On 12/04/2015 18:50, Mike Clarke wrote:


Sounds like it would be a useful feature but in the meantime could anyone
point me to where I can find the SVN revision used by the ports cluster when
building for 101amd64-default? It used to be on
beefy2.isc.freebsd.org/#latest_builds but that now only shows 101amd64-
quarterly and 93amd64-default. I assume the build logs must be available
somewhere.


+1

I do the same as Mike and have fallen back to using the quarterly 
builds because I cannot find the stable package build revision info 
that used to be on beefy2.


Regards

Simon.

___
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

Security patch for Drupal 6/7 needed

[Simon Wright]

Hi all

I am the maintainer of Drupal 6  7. Upstrem have just released a 
moderately critical security update but I am travelling with no access 
to my systems. If someone can quickly write and test a patch I will 
approve it.


There are a couple of points listed on the release notes but nothing major.

Thanks

Simon.
___
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

ports-mgmt/portshaker: Maintainer timeout [patch]

[Simon Wright]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195740

Would anyone be able to have a look at this bug to allow portshaker 
to use either subversion 1.7 or 1.8 depending on the setting of 
WITH_SUBVERSION_VER in make.conf. It's been open for 3 weeks now.


Regards

Simon Wright.
___
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

Re: Tracking Binary Ports/Pkgs Tree

[Simon Wright]

Seconded. This has been an issue for me this weekend with the perl 
default changing to 5.18 and the gettext port split but the packages 
in the FreeBSD repo are still using the old default for perl and the 
old version for gettext whereas my local repo (with custom options) 
are using the new settings/ports.


My preference would be to keep my local ports tree for poudriere 
exactly in sync with the package build port tree and to have a 
date/time when the repo has also been fully rebuilt so that I can 
run updates that will not try to pull in outdated packages. Is this 
position possible?


My solution for this weekend has been to return to the old-faithful 
portupgrade and rebuild all affected ports from my current ports tree.


Cheers

Simon.

On 30/11/2014 05:58, Reed A. Cartwright wrote:

I have been using poudriere for a while to build packages locally.  I
recently reduced the package server to just the ports that I need to
have custom options.  I want to rely on the freebsd pkgs as much as I
can.

However, this has proven difficult because my ports directory is often
ahead of the one that corresponded to the latest set of binary
packages.  I read where packages are build off of a snapshot of the
ports tree on every wednesday.

Is this snapshot saved anywhere?  If so, I would like to be able to
sync my local ports directory against it.  If not, I would like to
request such ability.



___
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

Security patches for Drupal 6 and 7: upgrades to 6.34 7.34 respectively

[Simon Wright]

Hi all

I have submitted patches for the latest Drupal security 
vulnerability on 6  7, would a committer be able to take a look at 
them? Patches are:


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195254
and
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195257

Poudriere build logs are attached to both bugs.

Many thanks

Simon.
___
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

Bug 192099 - [security][patch] www/drupal7: update to 7.31

[Simon Wright]

Hi all

Could we get a maintainer timeout on this security patch for Drupal 
7 and get it committed please? Patch was originally submitted on 
2014-07-24, updated on 2014-08-07.


Thanks

Simon.
___
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

[Resolved] Re: Any update planned for www/mod_log_sql2

[Simon Wright]

On 06/09/2014 19:36, Patrick Powell wrote:

On 09/06/14 02:05, Simon Wright wrote:


I was wondering whether mod_log_sql2 will be or can be updated to
work with the new default of Apache24? Apache22 is specified
explictly in the Makefile.

I'm not sure whether mod_log_mysql is a replacement/substitute but
that is also linked explicitly to Apache22.

An indication of any time line or migration path would be much
appreciated!



I had a quick look at this (Note: I am NOT an Apache module expert,
but I have updated a couple of them that I needed).

The source code for the module needs to be updated to match Apache
2.4. There are more than a few trivial changes here.

I you feel brave, look at:

http://httpd.apache.org/docs/trunk/developer/new_api_2_4.html
and
http://httpd.apache.org/docs/2.4/developer/modguide.html
and
http://httpd.apache.org/docs/current/mod/mod_example.html


Update: Olli Hauer has just committed an update to this port that 
fixs the outstanding issues :). We have tested it and it works for 
me with both Apache 22 and Apache 24.


I'm not brave but thanks for the links! If I'm feeling brave I *may* 
go through the code and see how it was fixed . . . but not tonight :).


Thanks to Olli for his work to update and tidy-up this port, I'm 
very grateful!


Regards

Simon.
___
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

Any update planned for www/mod_log_sql2

[Simon Wright]

Hi Team!

I was wondering whether mod_log_sql2 will be or can be updated to 
work with the new default of Apache24? Apache22 is specified 
explictly in the Makefile.


I'm not sure whether mod_log_mysql is a replacement/substitute but 
that is also linked explicitly to Apache22.


An indication of any time line or migration path would be much 
appreciated!


Many thanks.

Simon Wright.
___
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

Re: [CFT] SSP Package Repository available

[Simon Wright]

On 20/08/2014 18:34, Bryan Drewery wrote:

On 9/21/2013 5:49 AM, Bryan Drewery wrote:

Ports now support enabling Stack Protector [1] support on FreeBSD 10
i386 and amd64, and older releases on amd64 only currently.

Support may be added for earlier i386 releases once all ports properly
respect LDFLAGS.

To enable, just add WITH_SSP=yes to your make.conf and rebuild all ports.

The default SSP_CLFAGS is -fstack-protector, but -fstack-protector-all
may optionally be set instead.

Please help test this on your system. We would like to eventually enable
this by default, but need to identify any major ports that have run-time
issues due to it.

[1] https://en.wikipedia.org/wiki/Buffer_overflow_protection



We have not had any feedback on this yet and want to get it enabled by
default for ports and packages.

We now have a repository that you can use rather than the default to
help test. We need your help to identify any issues before switching the
default.


Another data point:

I've been using WITH_SSP_PORTS=yes for building from ports since 
late 2013. No issues noticed on 9.2 and 9.3 amd64 systems. I have 
also been building a selection of packages locally with poudriere 
using the same make.conf setting for about two months and have seen 
no issues there either. I have just updated my pkg configuration to 
use the new repository and have reinstalled all official packages.


Regards,

Simon Wright.
___
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

Re: pkg aparently not respecting subversion make.conf settings

[Simon Wright]

On 11/06/2014 00:19, olli hauer wrote:

On 2014-06-11 00:02, Simon Wright wrote:

On 10/06/2014 22:35, olli hauer wrote:

...


poudriere bulk -j freebsd:9:x86:64 -C
ports-mgmt/portdowngrade

portdowngrade is removed from the repo and then the
rebuild begins:


:

..



Not easy to tell since we do not have the list of ports you
feed into pd

Perhaps you find the answer in the buildlogs

$ grep devel/subversion
/usr/local/poudriere/data/logs/bulk/$YourBuild/latest/logs/*.log




If you have identified a port that depends on devel/subversion

and not devel/subversion17 check the Makefile of this port
has a switch for WITH_SUBVERSION_VER


I've checked these log files and the only thing that references
subversion is the subversion 1.8.9 port itself.

I tried just deleting the 1.8.9 package file and re-running
poudriere and 1.8.9 is still rebuilt.

As per your earlier mail Olli, I also tried this in case
something in the pkg database was playing up:

pkg delete devel/subversion17 pkg install devel/subversion pkg
set -o devel/subversion:devel/subversion17 pkg delete
devel/subversion pkg install devel/subversion17

No change, 1.8.9 is still pulled in on the poudriere build of
portdowngrade build.

---Begin make.conf--- USE_PACKAGE_DEPENDS=yes BATCH=yes
WRKDIRPREFIX=/wrkdirs PACKAGES=/packages DISTDIR=/distfiles
 /usr/local/etc/poudriere.d/make.conf 
WITH_GECKO=libxul NOI4B=1 OPTIONS_UNSET+=X11 WITH_PKGNG=yes
WITH_CUPS=YES CUPS_OVERWRITE_BASE=YES WITHOUT_LPR=YES
WITH_BDB_VER=5 WITH_SSP_PORTS=yes WITH_VIM_OPTIONS=yes
JAVA_PREFERRED_PORTS=JAVA_PORT_NATIVE_OPENJDK_JDK_1_7
WITH_SUBVERSION_VER=17 WITHOUT_PKGTOOLS=1
VALID_CATEGORIES+=local DISABLE_MAKE_JOBS=poudriere ---End
make.conf---

snipped

===phase: run-depends ===
portdowngrade-1.5 depends on executable: svn - not found ===
Verifying install for svn in /usr/ports/devel/subversion ===
Installing existing package /packages/All/subversion-1.8.9.txz
Installing subversion-1.8.9...Installing
apr-1.5.1.1.5.3...Installing db5-5.3.28... done Installing
expat-2.1.0... done Installing gdbm-1.11...Installing
gettext-0.18.3.1_1...Installing libiconv-1.14_3... done


I tried 'pkg info -rx subversion' to see whether an old port
was responsible:

[simon@vmserver04 ~]$ pkg info -rx subversion
subversion17-1.7.17:

If I build from ports with portupgrade the build works as
expected and portdowngrade uses the installed subversion17.

It seems a little odd . . . .


No, not so strange as you think.

$ grep svn portdowngrade/Makefile RUN_DEPENDS=
svn:${PORTSDIR}/devel/subversion

Do the following $ cd ports-mgmt/portdowngrade $ fetch
http://people.freebsd.org/~ohauer/diffs/portdowngrade_svn.diff $
patch  portdowngrade_svn.diff

Now this port uses the correct subversion port.

If it works for you, be so kind and open a PR so it will be added
to the official port.


Tested, works. Extract of my Poudriere log:

===phase: run-depends
===   portdowngrade-1.5 depends on executable: svn - not found
===Verifying install for svn in /usr/ports/devel/subversion17
===   Installing existing package /packages/All/subversion17-1.7.17.txz
Installing subversion17-1.7.17...Installing
apr-1.5.1.1.5.3...Installing db5-5.3.28... done
Installing expat-2.1.0... done

PR submitted:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=190946

Many thanks Olli!

Simon.
___
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

pkg aparently not respecting subversion make.conf settings

[Simon Wright]

Hi all

I've recently set up poudriere and pkg on a 9.2 amd64 box. This has 
worked well for the last month or so. However I have just tried to 
downgrade subversion to 1.7x from 1.8x to support querying my 
network /usr/src /usr/ports that is setup on another box that only 
runs subversion 1.7.


As per updating, I set WITH_SUBVERSION_VER=17 in /etc/make.conf and 
also in /usr/local/etc/poudriere.d/make.conf, added subversion17 to 
the list of packages to be built and removed portdowngrade from the 
repository with:


poudriere bulk -j freebsd:9:x86:64 -C ports-mgmt/portdowngrade

portdowngrade is removed from the repo and then the rebuild begins:

snipped

---Begin make.conf---
USE_PACKAGE_DEPENDS=yes
BATCH=yes
WRKDIRPREFIX=/wrkdirs
PACKAGES=/packages
DISTDIR=/distfiles
 /usr/local/etc/poudriere.d/make.conf 
WITH_GECKO=libxul
NOI4B=1
OPTIONS_UNSET+=X11
WITH_PKGNG=yes
WITH_CUPS=YES
CUPS_OVERWRITE_BASE=YES
WITHOUT_LPR=YES
WITH_BDB_VER=5
WITH_SSP_PORTS=yes
WITH_VIM_OPTIONS=yes
JAVA_PREFERRED_PORTS=JAVA_PORT_NATIVE_OPENJDK_JDK_1_7
WITH_SUBVERSION_VER=17
WITHOUT_PKGTOOLS=1
VALID_CATEGORIES+=local
DISABLE_MAKE_JOBS=poudriere
---End make.conf---

snipped

===phase: run-depends 


===   portdowngrade-1.5 depends on executable: svn - not found
===Verifying install for svn in /usr/ports/devel/subversion
===   Installing existing package /packages/All/subversion-1.8.9.txz
Installing subversion-1.8.9...Installing 
apr-1.5.1.1.5.3...Installing db5-5.3.28... done

Installing expat-2.1.0... done

snipped

It looks as though pkg is not recognising the WITH_SUBVERSION_VER=17 
variable and instead pulling in version 1.8 which is the default.


There are no options in portdowngrade to use a specific version of 
subversion.


Can anyone offer any suggestions to let me build a package of 
portdowngrade that uses my desired version of subversion or see what 
I've done wrong?


Thanks!

Simon Wright.
___
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

Re: pkg aparently not respecting subversion make.conf settings

[Simon Wright]

On 10/06/2014 18:50, Mikhail Tsatsenko wrote:

2014-06-10 20:31 GMT+04:00 Simon Wright simon.wri...@gmx.net:

Hi all

I've recently set up poudriere and pkg on a 9.2 amd64 box. This has worked
well for the last month or so. However I have just tried to downgrade
subversion to 1.7x from 1.8x to support querying my network /usr/src
/usr/ports that is setup on another box that only runs subversion 1.7.




Packages you install via pkg is built on FreeBSD cluster and it knows
nothing about make.conf content on your machine


Packages are being built with poudriere on a locally-hosted repo


There are no options in portdowngrade to use a specific version of
subversion.

Can anyone offer any suggestions to let me build a package of portdowngrade
that uses my desired version of subversion or see what I've done wrong?



You are doing right everything, but you cant redefine default
WITH_SUBVERSION_VER if you are using official packages.


Thanks but see above!
___
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

Re: pkg aparently not respecting subversion make.conf settings

[Simon Wright]

On 10/06/2014 19:45, Scot Hetzel wrote:

On Tue, Jun 10, 2014 at 11:31 AM, Simon Wright simon.wri...@gmx.net wrote:

Hi all

I've recently set up poudriere and pkg on a 9.2 amd64 box. This has worked
well for the last month or so. However I have just tried to downgrade
subversion to 1.7x from 1.8x to support querying my network /usr/src
/usr/ports that is setup on another box that only runs subversion 1.7.

As per updating, I set WITH_SUBVERSION_VER=17 in /etc/make.conf and also in
/usr/local/etc/poudriere.d/make.conf, added subversion17 to the list of
packages to be built and removed portdowngrade from the repository with:

poudriere bulk -j freebsd:9:x86:64 -C ports-mgmt/portdowngrade

portdowngrade is removed from the repo and then the rebuild begins:


:

===phase: run-depends 
===   portdowngrade-1.5 depends on executable: svn - not found
===Verifying install for svn in /usr/ports/devel/subversion
===   Installing existing package /packages/All/subversion-1.8.9.txz
Installing subversion-1.8.9...Installing apr-1.5.1.1.5.3...Installing
db5-5.3.28... done
Installing expat-2.1.0... done

snipped

It looks as though pkg is not recognising the WITH_SUBVERSION_VER=17
variable and instead pulling in version 1.8 which is the default.

There are no options in portdowngrade to use a specific version of
subversion.

Can anyone offer any suggestions to let me build a package of portdowngrade
that uses my desired version of subversion or see what I've done wrong?


It looks like you have subversion-1.8.9 in your package repo. Try
removing it from the repo and try the poudriere build again.


Yes I do. I tried to remove the package with poudriere bulk -j 
freebsd:9:x86:64 -C devel/subversion


but after removing the package poudriere then rebuilds it. How can I 
remove devel/subversion for the repo. Can I just delete the package 
and rerun the bulk command?

___
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

Re: pkg aparently not respecting subversion make.conf settings

[Simon Wright]

On 10/06/2014 22:35, olli hauer wrote:

On 2014-06-10 22:01, Simon Wright wrote:

On 10/06/2014 19:45, Scot Hetzel wrote:

On Tue, Jun 10, 2014 at 11:31 AM, Simon Wright
simon.wri...@gmx.net wrote:

Hi all

I've recently set up poudriere and pkg on a 9.2 amd64 box.
This has worked well for the last month or so. However I
have just tried to downgrade subversion to 1.7x from 1.8x
to support querying my network /usr/src /usr/ports that is
setup on another box that only runs subversion 1.7.

As per updating, I set WITH_SUBVERSION_VER=17 in
/etc/make.conf and also in
/usr/local/etc/poudriere.d/make.conf, added subversion17 to
the list of packages to be built and removed portdowngrade
from the repository with:

poudriere bulk -j freebsd:9:x86:64 -C
ports-mgmt/portdowngrade

portdowngrade is removed from the repo and then the rebuild
begins:


:

===phase: run-depends
 ===   portdowngrade-1.5
depends on executable: svn - not found ===Verifying
install for svn in /usr/ports/devel/subversion ===
Installing existing package
/packages/All/subversion-1.8.9.txz Installing
subversion-1.8.9...Installing apr-1.5.1.1.5.3...Installing
db5-5.3.28... done Installing expat-2.1.0... done

snipped

It looks as though pkg is not recognising the
WITH_SUBVERSION_VER=17 variable and instead pulling in
version 1.8 which is the default.

There are no options in portdowngrade to use a specific
version of subversion.

Can anyone offer any suggestions to let me build a package
of portdowngrade that uses my desired version of subversion
or see what I've done wrong?


It looks like you have subversion-1.8.9 in your package repo.
Try removing it from the repo and try the poudriere build
again.


Yes I do. I tried to remove the package with poudriere bulk -j
freebsd:9:x86:64 -C devel/subversion

but after removing the package poudriere then rebuilds it. How
can I remove devel/subversion for the repo. Can I just delete
the package and rerun the bulk command?


Not easy to tell since we do not have the list of ports you feed
into pd

Perhaps you find the answer in the buildlogs

$ grep devel/subversion
/usr/local/poudriere/data/logs/bulk/$YourBuild/latest/logs/*.log

If you have identified a port that depends on devel/subversion
and not devel/subversion17 check the Makefile of this port has a
switch for WITH_SUBVERSION_VER


I've checked these log files and the only thing that references 
subversion is the subversion 1.8.9 port itself.


I tried just deleting the 1.8.9 package file and re-running 
poudriere and 1.8.9 is still rebuilt.


As per your earlier mail Olli, I also tried this in case something 
in the pkg database was playing up:


pkg delete devel/subversion17
pkg install devel/subversion
pkg set -o devel/subversion:devel/subversion17
pkg delete devel/subversion
pkg install devel/subversion17

No change, 1.8.9 is still pulled in on the poudriere build of 
portdowngrade build.


---Begin make.conf---
USE_PACKAGE_DEPENDS=yes
BATCH=yes
WRKDIRPREFIX=/wrkdirs
PACKAGES=/packages
DISTDIR=/distfiles
 /usr/local/etc/poudriere.d/make.conf 
WITH_GECKO=libxul
NOI4B=1
OPTIONS_UNSET+=X11
WITH_PKGNG=yes
WITH_CUPS=YES
CUPS_OVERWRITE_BASE=YES
WITHOUT_LPR=YES
WITH_BDB_VER=5
WITH_SSP_PORTS=yes
WITH_VIM_OPTIONS=yes
JAVA_PREFERRED_PORTS=JAVA_PORT_NATIVE_OPENJDK_JDK_1_7
WITH_SUBVERSION_VER=17
WITHOUT_PKGTOOLS=1
VALID_CATEGORIES+=local
DISABLE_MAKE_JOBS=poudriere
---End make.conf---

snipped

===phase: run-depends
===   portdowngrade-1.5 depends on executable: svn - not found
===Verifying install for svn in /usr/ports/devel/subversion
===   Installing existing package /packages/All/subversion-1.8.9.txz
Installing subversion-1.8.9...Installing 
apr-1.5.1.1.5.3...Installing db5-5.3.28... done

Installing expat-2.1.0... done
Installing gdbm-1.11...Installing gettext-0.18.3.1_1...Installing 
libiconv-1.14_3... done



I tried 'pkg info -rx subversion' to see whether an old port was 
responsible:


[simon@vmserver04 ~]$ pkg info -rx subversion
subversion17-1.7.17:

If I build from ports with portupgrade the build works as expected 
and portdowngrade uses the installed subversion17.


It seems a little odd . . . .
___
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: security patch, ports/188945 (www/drupal6)

[Simon Wright]

Would any committer be able to look at the captioned patch for 
www/drupal6? This is a security update that has been pending since 
24 April.


Many thanks

Simon Wright.
___
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

Re: Why does Samba requires 777 permissions on /tmp

[Simon Wright]

On 20/05/2013 15:38, Bob Eager wrote:

On Mon, 20 May 2013 08:03:09 -0500
sindrome sindr...@gmail.com wrote:

What I think is happening is that portupgrade is building and running
shell scripts in /tmp. It's running them with (in ruby):

   system('/tmp/script') [roughly]

The ruby runtime is checking the *path-to-the-command* and THAT is what
it's complaining about.

Try setting PKG_TMPDIR (in pkgtools.conf) to some suitable non world
writable temporary directory.

I have an older ports tree on this machine or I'd try it myself. I had
to download the latest sources to check all this,


Trying to summarise what I've tested here with the results.

My PKG_TMPDIR and TMPDIR are set to /var/tmp:

pkgtools.conf:

  ENV['TMPDIR'] ||= '/var/tmp'
  ENV['PKG_TMPDIR'] ||= '/var/tmp'
  ENV['PORTSDIR'] ||= '/usr/ports'
  ENV['PACKAGES'] ||= ENV['PORTSDIR'] + '/packages'

from /usr/local/etc/sudoers:
# Uncomment if needed to preserve environmental variables related to the
# FreeBSD pkg_* utilities and fetch.
Defaultsenv_keep += PKG_PATH PKG_DBDIR PKG_TMPDIR TMPDIR 
PACKAGEROOT PACKAGESITE PKGDIR FTP_PASSIVE_MODE


[simon@vmserver04 ~]$ ls -ld /var/tmp
drwxrwxr-t  9 root  wheel  33280 May 20 23:02 /var/tmp/

Note: /var/tmp is not world writeable

[simon@vmserver04 ~]$ echo $PATH
/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin:/usr/local/scripts:

root@vmserver04:/root # echo $PATH
/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin

I run portupgrade via sudo but both $PATH's show no /tmp or .

[simon@vmserver04 ~]$ ruby -v
ruby 1.8.7 (2012-10-12 patchlevel 371) [amd64-freebsd9]

portupgrade-2.4.10.5_1,2 FreeBSD ports/packages administration and 
management tool s


Other (not likely) relevant stuff:
- I have /usr/ports mounted rw with NFS
- I have the packages directory mounted rw with NFS and amd then 
redefine $PACKAGES to point to the mount point

This has been working for several years with no issues

[simon@vmserver04 ~]$ sudo portupgrade -v portupgrade*
---  Reading default options: -v -D -l 
/var/tmp/portupgrade.results_20130520-22:56:25 -L 
/var/tmp/portupgrade/%s::%s.log

---  Session started at: Mon, 20 May 2013 22:56:26 +0200
** None has been installed or upgraded.
---  Saving the results to 
'/var/tmp/portupgrade.results_20130520-22:56:25'
/usr/local/lib/ruby/site_ruby/1.8/pkgtools/pkgtools.rb:483: warning: 
Insecure world writable dir /tmp/ in PATH, mode 041777


Still the complaint about /tmp/

[simon@vmserver04 ~]$ sudo chmod 1775 /tmp

[simon@vmserver04 ~]$ ls -ld /tmp
drwxrwxr-t  9 root  wheel  1024 May 20 23:16 /tmp/

[simon@vmserver04 ~]$ sudo portupgrade -v portupgrade*
---  Reading default options: -v -D -l 
/var/tmp/portupgrade.results_20130520-23:16:07 -L 
/var/tmp/portupgrade/%s::%s.log

---  Session started at: Mon, 20 May 2013 23:16:07 +0200
** None has been installed or upgraded.
---  Saving the results to '/var/tmp
/portupgrade.results_20130520-23:16:07'
---  Session ended at: Mon, 20 May 2013 23:16:08 +0200 (consumed 
00:00:00)


No more complaint.

I can't read the portupgrade code well enough to see what it's doing 
with the script, but if Bob is right that Ruby is running the 
portupgrade commands from /tmp then the error is within the checks 
in Ruby which is saying the 777 permission on /tmp is not 
acceptable, 775 *is* acceptable. Which is strange since surely then 
everyone with 777 permissions on /tmp would be seeing this message? 
Does this get us any further?


Thanks for all the input, it is appreciated.

Cheers

Simon.
___
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

Re: Why does Samba requires 777 permissions on /tmp

[Simon Wright]

On 05/19/13 20:56, Bob Eager wrote:

On Sun, 19 May 2013 13:34:49 -0500
sindrome sindr...@gmail.com wrote:


can't authenticate to my samba server.  There has to be a root of
this problem to make them both work.  Is there some other place
portupgrade is having /tmp amended on without it being in my $PATH?


I went back and had a closer look at your error message. What I hadn't
done (and neither had you, prior to that) was read and fully digest the
error message.

portupgrade is calling its 'system()' function to run a command. The
Ruby runtime does a sanity check to make sure that the directories in
the path are secure...and /tmp isn't. I suspect that portupgrade puts
temporary scripts into /tmp, then executes them; this implies that it's
probably chdir'ing to /tmp, then haveing '.' in thge path, or even just
adding /tmp to the path, although I don't think so.

Anyway, what's insecure is that you don't have the sticky bit set. If
you use:

   chmod 1777 /tmp

it ought to all work.


Unfortunately it doesn't - for me at least! Here's the error I get 
from portupgrade on (all of) my FreeBSD boxes:


[simon@vmserver02 ~]$ sudo portupgrade -pP sysutils/webmin
---  Session started at: Sun, 19 May 2013 21:11:25 +0200
/usr/local/lib/ruby/site_ruby/1.8/pkgtools/pkgtools.rb:288: warning: 
Insecure world writable dir /tmp/ in PATH, mode 041777


AFAIR this started around the time of the last Ruby update over a 
year ago, the change and subsequent rollback to making the default 
version of Ruby 1.9. I'm using 1.8.7 which I believe is still the 
FBSD default version. Is anyone seeing this issue using Ruby 1.9?


I definitely do not have /tmp in my $PATH.

Cheers

Simon.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Ports make fetchindex still getting outdated INDEX-9

[Simon Wright]

On 01/01/13 23:07, Simon L. B. Nielsen wrote:

On 14 December 2012 13:08, Jim Pingleli...@pingle.org  wrote:

On 13 Dec 2012 16:57, Jim Pingle wrote:
 I saw a thread last month about the servers that build INDEX

files being

 down since the security incident - is that still the case?


On 12/13/2012 6:35 PM, Simon L. B. Nielsen wrote:
I had forgotten about it again. I will try and to get it fixed within
the next couple of days.



Anyway, it's fixed as of today fully based on portmgr based INDEX
build. It's also now not served of www.FreeBSD.org which was a bit
ugly IMO, but a HTTP redirect makes 'make fetchindex' work.

PS. should people be so inclined, you can now also get it via rsync
from rsync://bit0.us-west.freebsd.org/FreeBSD-bit/ports-index/ .


Thank you Simon, this is much appreciated. Hope you had time for a bit 
of a holiday as well :).


Regards

Simon.

___
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

Re: Unable to build graphics/ImageMagick port

[Simon Wright]

On 20/06/12 06:22, Kevin Oberman wrote:


For this to work, install ImageMagick WITH HDRI, The test that fails
is for HDRI and attempts to use files that don't yet exist. Thus
analyze.sh failes.

To install ImageMagick with all default options, turn on HDRI (High
Dynamic Range), a very desirable capability for many but turn off
TESTS. Build and INSTALL ImageMagick. That puts all of the needed
files in place. Then turn on TESTS and re-buildand ImageMagick.It will
then pass all tests.


On i386 with a ports tree from this morning, with TESTS disabled 
ImageMagick builds and installs. Re-enabling TESTS and rebuilding fails 
the test averageImages.sh.


YMMV of course!

Simon.
___
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

Re: portupgrade - portmaster Rosetta Stone?

[Simon Wright]

On 03/03/12 12:23, Kurt Jaeger wrote:

The script that does this uses:

   portupgrade -arR -m BATCH=yes


Hi Kurt

Wouldn't portupgrade -a do exactly the same as -arR since -a affects all 
ports that have been updated and so by definition will build *updated* 
dependencies as well?


Regards

Simon.
___
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