bash velnerability
Hi, https://www.freebsd.org/cgi/ports.cgi?query=The+GNU+Project%27s+Bourne+Again+SHellstype=textsektion=all Is this version patched from the bash vulnerability? https://access.redhat.com/articles/1200223 -- Riyaz T K Admod Technologies ___ 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
www/xpi-https-everywhere
EFF's https-everywhere add-on for firefox (and other browsers) redirects http
to https connection, for those websites supporting https protocol
(https://www.eff.org/Https-everywhere)
The add-on is no longer available for download from addons.mozilla.org, for
reasons explained by EFF as:
We felt that the Mozilla privacy policy that applies to downloads from
addons.mozilla.org is somewhat less protective than the privacy policies of
the organizations that develop HTTPS Everywhere, and we prefer for HTTPS
Everywhere users to be protected by our privacy policy. This decision could
change in the future as Mozilla's privacy practices evolve or as we
re-examine the details of the current Mozilla policy.
So the download for firefox extension is here (instead of mozilla.org):
https://www.eff.org/files/https-everywhere-latest.xpi
And might the Makefile look like this?
-
PORTNAME= https-everywhere
DISTVERSION=4.0.1
DISTVERSIONSUFFIX= (???)
CATEGORIES= www
MAINTAINER= po...@freebsd.org
COMMENT=EFF's tool that rewrites HTTP requests as HTTPS for sites
supporting encryption.
LICENSE=(???)
LICENSE_FILE= (???)
MASTER_SITES= https://www.eff.org/files/https-everywhere-latest.xpi
XPI_DISTNAME= https-everywhere
XPI_ID= i...@eff.org
## XPI_NUM= N/A
.include ${.CURDIR}/../xpi-adblock/Makefile.xpi
.include bsd.port.mk
-
If someone is willing to help me with this, I can inquire with EFF as to
license, their porting rules and whether above MASTER_SITE is acceptable to
them.
Regards.
-
FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS
--
View this message in context:
http://freebsd.1045724.n5.nabble.com/www-xpi-https-everywhere-tp5951795.html
Sent from the freebsd-ports mailing list archive at Nabble.com.
___
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: bash velnerability
I think not yet[1]. But it will be shortly updated to patched version because the vulnerability is already documented written in security/vuxml [2]. That means port committer(s) already aware of the bash vulnerability. [1] http://svnweb.freebsd.org/ports/head/shells/bash/Makefile?revision=369185view=markup [2] http://svnweb.freebsd.org/ports?view=revisionrevision=369192 On Thu, Sep 25, 2014 at 11:58:30AM +0530, Riyaz T.K wrote: Hi, https://www.freebsd.org/cgi/ports.cgi?query=The+GNU+Project%27s+Bourne+Again+SHellstype=textsektion=all Is this version patched from the bash vulnerability? https://access.redhat.com/articles/1200223 -- Riyaz T K Admod Technologies ___ 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 -- `whois vmeta.jp | nkf -w` meta m...@vmeta.jp ___ 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: bash velnerability
Please let me make corrections. The shellshock bash vulnerabilities are described by 2 CVEs. - CVE-2014-6271 - CVE-2014-7169 The first CVE is already fixed in latest freebsd ports tree (r369185), so far the second CVE is not fixed yet. On Thu, Sep 25, 2014 at 11:58:30AM +0530, Riyaz T.K wrote: Hi, https://www.freebsd.org/cgi/ports.cgi?query=The+GNU+Project%27s+Bourne+Again+SHellstype=textsektion=all Is this version patched from the bash vulnerability? https://access.redhat.com/articles/1200223 -- Riyaz T K Admod Technologies ___ 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 -- `whois vmeta.jp | nkf -w` meta m...@vmeta.jp ___ 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: Need help compiling use of std::vector
On Wed, Sep 24, 2014 at 08:57:17PM +0200, Matthias Andree wrote:
Am 24.09.2014 um 17:04 schrieb Shane Ambler:
I am trying to compile the new version of a port I maintain and have
trouble related to std::vector. The code producing the error can be
boiled down to the following test case, which compiles as 64bit but
fails as 32bit.
#include stdlib.h
#include vector
int main(int argc, char *argv[])
{
int num_layers = 3;
std::vectorconst char * layers (num_layers, NULL);
exit(0);
}
So that should create a vector containing 3 items initially set to NULL.
10.0 compiles ok - both 32 and 64 bit. (libc++)
8.4, 9.2 and 9.3 compiles 64bit but fails on 32bit. (libstdc++)
Using the above code
clang++ -m32 test.cpp
fails with
/usr/include/c++/4.2/bits/stl_algobase.h:641:15: error: assigning to
'const char *' from incompatible type 'const int'
I don't think -m32 compilation has ever worked properly for C++ on the
older FreeBSD releases, where older includes 9.3.
The headers for machine/x86 were only consilidated during 10-CURRENT.
The -m32 works on 10.0 and later, but not on stable/9.
You're probably better off trying to build with 32-bit chroots or jails
on your 64-bit host, like poudriere or Tinderbox are doing (but I'm not
sure if they support setting up 32-bit jails on 64-bit computers).
See here
https://lists.freebsd.org/pipermail/freebsd-stable/2009-September/051855.html
so it's a long-standing thing, and for recent developments:
https://lists.freebsd.org/pipermail/freebsd-current/2013-June/042378.html
-so that would have been for 10-CURRENT at the time, and hints that the
headers weren't pure enough for -m32 and similar tricks.
I am not aware that this effort was ever MFH'd.
No, it was not, and it will not be merged.
I am Cc'ing Konstantin Belousov in case he wants to shed more light on
this issue.
HTH
___
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
FreeBSD ports you maintain which are out of date
Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/po...@freebsd.org.html Port| Current version | New version +-+ audio/pd| 0.46-0 | 0.46-1 +-+ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Thanks. ___ 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: On Docs option and custom build target
On Wed, 24 Sep 2014 23:54:19 +0200 Fernando Apesteguía
fernando.apesteg...@gmail.com wrote:
On Wed, Sep 24, 2014 at 8:52 PM, Tijl Coosemans t...@freebsd.org wrote:
On Tue, 23 Sep 2014 23:23:31 +0200 Fernando Apesteguía
fernando.apesteg...@gmail.com wrote:
I have a Makefile for an application that provides both examples and
documentation. I created the two options in the Makefile (both enabled
by default).
The package doesn't provide any flags stock like --with-docs or
--with-examples, so I have a custom target like this:
do-build:
@cd ${BUILD_WRKSRC}/ ${MAKE}
.if ${PORT_OPTIONS:MDOCS}
@cd ${BUILD_WRKSRC}/ ${MAKE_CMD} doc
.endif
You don't have to override do-build like this. You can build the
documentation from a post-build target.
Thanks. Changed.
However, when I try to run this in poudriere, I get the following error:
make[1]: don't know how to make doc. Stop
make[1]: stopped in /wrkdirs/usr/ports/graphics/code-eli/work/.build
*** Error code 2
Does the makefile in BUILD_WRKSRC actually have a doc target? Is doc
a subdirectory maybe?
Yes it does.
In fact, with port test builds fine with the same code (change
directory and ${MAKE} doc). There is a doc.dir subdirectory in
BUILD_WRKSRC/CMakeFiles. The doc target basically gets a Doxygen
configuration file and runs doxygen on the whole library code.
Poudriere tests the port in a clean environment so check the build log
to see if any dependencies (like doxygen) are missing.
___
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 1.3.8 requested but not available?
RE original post, it is broken because pkg-1.3.7 is the latest in the pkg repo, whereas if you bootstrap it, the latest is 1.3.8, I just hit this and had to pkg remove -f pkg and bootstrap again who broke it? :) On 24/09/2014 00:29, Craig Rodrigues wrote: On Tue, Sep 23, 2014 at 3:35 PM, Patrick Gibson gibblert...@gmail.com wrote: The port I was trying to install was lang/v8 (3.18.5). I don't see anything in the Makefile that says it needs a particular version of pkg, but maybe it's hidden somewhere else. The MINIMAL_PKG_VERSION variable in /usr/ports/Mk/bsd.port.mk triggers this behavior for all ports. -- Craig ___ 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 ___ 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: Poudriere Build of pkg_* repos?
Thanks Bryan... On Wed, Sep 24, 2014 at 5:32 PM, Bryan Drewery bdrew...@freebsd.org wrote: On 9/24/2014 3:35 PM, Rick Miller wrote: Hi all, Does the EOL of legacy pkg_* tools in FreeBSD Ports affect Poudriere's ability to build legacy package repos? No. Poudriere still supports it as long as you're using an older ports tree. Poudriere was able to build a legacy pkg_* repo from a snapshot of Ports from around the time releng/10.0 received the patch for -p7, but it failed to build a legacy repo from a snapshot taken today and instead built a pkg(8) repo despite make.conf having WITHOUT_PKGNG=yes. Aside: Actually, it seemed to ignore the make.conf altogether as it contains PERL_VERSION=5.14.4 and built 5.16 instead. It must be /usr/local/etc/poudriere.d/make.conf Provided this is the case, what suggestions are there for patching today's bash remote execution vulnerability[1] in a version of Ports that can be built into a legacy repo? Just apply the patch via files/ and use EXTRA_PATCHES: http://dan.langille.org/2014/06/10/freebsd-custom-port-patches-when-using-poudriere/ Excellent! Thanks! -- Take care Rick Miller ___ 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
devel/git vs gui
I've noticed that pre-built packages for git do not contain the gui component. Is possible to flip the options' default? Or, better but more laborious, provide a separate git-gui port? Thanks a lot! -- Andriy Gapon ___ 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: Poudriere Build of pkg_* repos?
On Wed, Sep 24, 2014 at 5:32 PM, Bryan Drewery bdrew...@freebsd.org wrote:
On 9/24/2014 3:35 PM, Rick Miller wrote:
Hi all,
Does the EOL of legacy pkg_* tools in FreeBSD Ports affect Poudriere's
ability to build legacy package repos?
No. Poudriere still supports it as long as you're using an older ports
tree.
Given that, is the expectation that the below workflow would produce an 8.4
package repo? Unfortunately, it did not.
After creating an 8.4-RELEASE jail and an older, equivalent Ports tree as
follows...
# poudriere jail -c -j 8_4-amd64 -v 8.4-RELEASE -a amd64
# poudriere ports -c -p 8_4-amd64 -m svn+http -B branches/RELEASE_8_4_0
/usr/local/etc/poudriere.d/8_4-amd64-make.conf:
WITHOUT_PKGNG=yes
PERL_VERSION=5.14.4
OPTIONS_UNSET=X11 GTK2
.if ${.CURDIR:M*/shells/bash}
EXTRA_PATCHES+= /distfiles/local-patches/8_4-amd64/bash.patch
.endif
note: above .if added to the make.conf according to the link provided below
Executing poudriere bulk, as follows, results in no packages built due to
numerous stage failures subsequently resulting in a bunch of skipped builds
due to these failures.
# poudriere bulk -j 8_4-amd64 -f $package_file -p 8_4-amd64
===phase: stage
make: don't know how to make stage. Stop
Poudriere was able to build a legacy pkg_* repo from a snapshot of Ports
from around the time releng/10.0 received the patch for -p7, but it
failed
to build a legacy repo from a snapshot taken today and instead built a
pkg(8) repo despite make.conf having WITHOUT_PKGNG=yes.
Aside: Actually, it seemed to ignore the make.conf altogether as it
contains PERL_VERSION=5.14.4 and built 5.16 instead.
It must be /usr/local/etc/poudriere.d/make.conf
Provided this is the case, what suggestions are there for patching
today's
bash remote execution vulnerability[1] in a version of Ports that can be
built into a legacy repo?
Just apply the patch via files/ and use EXTRA_PATCHES:
http://dan.langille.org/2014/06/10/freebsd-custom-port-patches-when-using-poudriere/
--
Take care
Rick Miller
___
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
Push requested
Hi, i sent a new port, rainloop. A very good and modern webmail. Can this port be reviewed and pushed ? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193831 Ty Regards, Loïc Blot, UNIX Systems, Network and Security Engineer http://www.unix-experience.fr ___ 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
Failed ports build of nagios-plugins via Poudriere
Using poudriere to build 10.x packages, including nagios-plugins, the following error is observed: gmake[4]: Nothing to be done for `install-data-am'. gmake[4]: Leaving directory `/wrkdirs/usr/ports/net-mgmt/nagios-plugins/work/nagios-plugins-2.0.3/plugins-root' gmake[3]: Leaving directory `/wrkdirs/usr/ports/net-mgmt/nagios-plugins/work/nagios-plugins-2.0.3/plugins-root' Making install in po gmake[3]: Entering directory `/wrkdirs/usr/ports/net-mgmt/nagios-plugins/work/nagios-plugins-2.0.3/po' /wrkdirs/usr/ports/net-mgmt/nagios-plugins/work/stage/usr/local/share gmake[3]: execvp: /wrkdirs/usr/ports/net-mgmt/nagios-plugins/work/stage/usr/local/share: Permission denied gmake[3]: *** [install-data-yes] Error 127 gmake[3]: Leaving directory `/wrkdirs/usr/ports/net-mgmt/nagios-plugins/work/nagios-plugins-2.0.3/po' gmake[2]: *** [install-recursive] Error 1 gmake[2]: Leaving directory `/wrkdirs/usr/ports/net-mgmt/nagios-plugins/work/nagios-plugins-2.0.3' *** Error code 2 Stop. make[1]: stopped in /usr/ports/net-mgmt/nagios-plugins *** Error code 1 The bulk build was executed as root. Is this indicative of an issue with the port? -- Take care Rick Miller ___ 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 193849] www/xpi-conkeror builds from very old source code
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193849 Tilman Keskinoz ar...@freebsd.org changed: What|Removed |Added CC|freebsd-ports@FreeBSD.org |ar...@freebsd.org -- You are receiving this mail because: You are on the CC list for the bug. ___ 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: Failed ports build of nagios-plugins via Poudriere
Disregard the below. I noticed an update the port which occurred after I snapshotted it. Updating ports and executing a new build appears to have resolved it. On Thu, Sep 25, 2014 at 9:22 AM, Rick Miller vmil...@hostileadmin.com wrote: Using poudriere to build 10.x packages, including nagios-plugins, the following error is observed: gmake[4]: Nothing to be done for `install-data-am'. gmake[4]: Leaving directory `/wrkdirs/usr/ports/net-mgmt/nagios-plugins/work/nagios-plugins-2.0.3/plugins-root' gmake[3]: Leaving directory `/wrkdirs/usr/ports/net-mgmt/nagios-plugins/work/nagios-plugins-2.0.3/plugins-root' Making install in po gmake[3]: Entering directory `/wrkdirs/usr/ports/net-mgmt/nagios-plugins/work/nagios-plugins-2.0.3/po' /wrkdirs/usr/ports/net-mgmt/nagios-plugins/work/stage/usr/local/share gmake[3]: execvp: /wrkdirs/usr/ports/net-mgmt/nagios-plugins/work/stage/usr/local/share: Permission denied gmake[3]: *** [install-data-yes] Error 127 gmake[3]: Leaving directory `/wrkdirs/usr/ports/net-mgmt/nagios-plugins/work/nagios-plugins-2.0.3/po' gmake[2]: *** [install-recursive] Error 1 gmake[2]: Leaving directory `/wrkdirs/usr/ports/net-mgmt/nagios-plugins/work/nagios-plugins-2.0.3' *** Error code 2 Stop. make[1]: stopped in /usr/ports/net-mgmt/nagios-plugins *** Error code 1 The bulk build was executed as root. Is this indicative of an issue with the port? -- Take care Rick Miller -- Take care Rick Miller ___ 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: Poudriere Build of pkg_* repos?
On 09/25/14 14:56, Rick Miller wrote:
On Wed, Sep 24, 2014 at 5:32 PM, Bryan Drewery bdrew...@freebsd.org wrote:
On 9/24/2014 3:35 PM, Rick Miller wrote:
Hi all,
Does the EOL of legacy pkg_* tools in FreeBSD Ports affect Poudriere's
ability to build legacy package repos?
No. Poudriere still supports it as long as you're using an older ports
tree.
Given that, is the expectation that the below workflow would produce an 8.4
package repo? Unfortunately, it did not.
After creating an 8.4-RELEASE jail and an older, equivalent Ports tree as
follows...
# poudriere jail -c -j 8_4-amd64 -v 8.4-RELEASE -a amd64
# poudriere ports -c -p 8_4-amd64 -m svn+http -B branches/RELEASE_8_4_0
I think you should grab ports with the tag PKG_INSTALL_EOL (-B
tag/PKG_INSTALL_EOL)
That's the last revision at which the ports tree supported old pkg_tools.
/usr/local/etc/poudriere.d/8_4-amd64-make.conf:
WITHOUT_PKGNG=yes
PERL_VERSION=5.14.4
OPTIONS_UNSET=X11 GTK2
.if ${.CURDIR:M*/shells/bash}
EXTRA_PATCHES+= /distfiles/local-patches/8_4-amd64/bash.patch
.endif
note: above .if added to the make.conf according to the link provided below
Executing poudriere bulk, as follows, results in no packages built due to
numerous stage failures subsequently resulting in a bunch of skipped builds
due to these failures.
# poudriere bulk -j 8_4-amd64 -f $package_file -p 8_4-amd64
===phase: stage
make: don't know how to make stage. Stop
You took ports tagged for 8.4 release, which happened quite some time
ago, I don't think the ports tree had stage support at the time.
--
Guido Falsi m...@madpilot.net
___
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: bash velnerability
On 2014-09-25 02:54:06 -0400, Koichiro Iwao wrote: Please let me make corrections. The shellshock bash vulnerabilities are described by 2 CVEs. - CVE-2014-6271 - CVE-2014-7169 The first CVE is already fixed in latest freebsd ports tree (r369185), so far the second CVE is not fixed yet. CVE-2014-7169 is fixed now (r369261). http://svnweb.freebsd.org/changeset/ports/369261 Note the commit log says CVE-2014-3659 but it was actually reassigned as CVE-2014-7169. Jung-uk Kim On Thu, Sep 25, 2014 at 11:58:30AM +0530, Riyaz T.K wrote: Hi, https://www.freebsd.org/cgi/ports.cgi?query=The+GNU+Project%27s+Bourne+Again+SHellstype=textsektion=all Is this version patched from the bash vulnerability? https://access.redhat.com/articles/1200223 ___ 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: bash velnerability
On 9/25/2014 11:13 AM, Jung-uk Kim wrote: On 2014-09-25 02:54:06 -0400, Koichiro Iwao wrote: Please let me make corrections. The shellshock bash vulnerabilities are described by 2 CVEs. - CVE-2014-6271 - CVE-2014-7169 The first CVE is already fixed in latest freebsd ports tree (r369185), so far the second CVE is not fixed yet. CVE-2014-7169 is fixed now (r369261). http://svnweb.freebsd.org/changeset/ports/369261 Note the commit log says CVE-2014-3659 but it was actually reassigned as CVE-2014-7169. Thanks, vuxml updated. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: bash velnerability
On 9/25/2014 11:13 AM, Jung-uk Kim wrote: On 2014-09-25 02:54:06 -0400, Koichiro Iwao wrote: Please let me make corrections. The shellshock bash vulnerabilities are described by 2 CVEs. - CVE-2014-6271 - CVE-2014-7169 The first CVE is already fixed in latest freebsd ports tree (r369185), so far the second CVE is not fixed yet. CVE-2014-7169 is fixed now (r369261). http://svnweb.freebsd.org/changeset/ports/369261 Note the commit log says CVE-2014-3659 but it was actually reassigned as CVE-2014-7169. Jung-uk Kim The port is fixed with all known public exploits. The package is building currently. However bash still allows the crazy exporting of functions and may still have other parser bugs. I would recommend for the immediate future not using bash for forced ssh commands as well as these guidelines: 1. Do not ever link /bin/sh to bash. This is why it is such a big problem on Linux, as system(3) will run bash by default from CGI. 2. Web/CGI users should have shell of /sbin/nologin. 3. Don't write CGI in shell script / Stop using CGI :) 4. httpd/CGId should never run as root, nor apache. Sandbox each application into its own user. 5. Custom restrictive shells, like scponly, should not be written in bash. 6. SSH authorized_keys/sshd_config forced commands should also not be written in bash. Cheers, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: [package - 91amd64-quarterly] build failure mail
24.09.2014 14:36, Vitaly Magerya пишет: On 2014-09-24 08:37, pkg-fall...@freebsd.org wrote: You are receiving this mail as a port that you maintain is failing to build on the FreeBSD package build server. Please investigate the failure and submit a PR to fix build. Maintainer: vmage...@gmail.com Last committer: olg...@freebsd.org Ident: $FreeBSD: branches/2014Q3/editors/wordgrinder/Makefile 357277 2014-06-10 07:39:01Z olgeni $ Log URL: http://beefy2.isc.freebsd.org/data/91amd64-quarterly/2014-09-24_01h22m09s/logs/wordgrinder-0.3.3.log Build URL: http://beefy2.isc.freebsd.org/build.html?mastername=91amd64-quarterlybuild=2014-09-24_01h22m09s Log: Building editors/wordgrinder build started at Wed Sep 24 05:37:27 UTC 2014 port directory: /usr/ports/editors/wordgrinder building for: FreeBSD 91amd64-quarterly-job-16 9.1-RELEASE-p17 FreeBSD 9.1-RELEASE-p17 amd64 maintained by: vmage...@gmail.com Makefile ident: $FreeBSD: branches/2014Q3/editors/wordgrinder/Makefile 357277 2014-06-10 07:39:01Z olgeni $ Poudriere version: 3.1-pre Host OSVERSION: 1100027 Jail OSVERSION: 901000 Folks, what should I do to not receive these messages? I've already updated the port (long time ago), but I still get mail about build failures in the quarterly branch. I guess that the change was done to HEAD but not merged to the quarterly branch. However, a new quarterly branch seems to be branched soon. -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ 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
linux_base-f10-10_7 installation failure on FreeBSD 10.1 BETA2
Hi, I've FreeBSD 10.1 BETA2. I tried to install a package of nVidia 304.xx driver. This package depends on the linux_base-f10 one. The linuxulator installation has failed. See the sysctl: unknown oid 'compat.linux.osrelease': No such file or directory line in the following installation log. Is it a known problem? root@saturn:~ # pkg install nvidia-driver-304-304.88_2 Updating FreeBSD repository catalogue... FreeBSD repository is up-to-date. All repositories are up-to-date. The following 2 packages will be affected (of 0 checked): New packages to be INSTALLED: nvidia-driver-304: 304.88_2 linux_base-f10: 10_7 The process will require 230 MB more space. 37 MB to be downloaded. Proceed with this action? [y/N]: y Fetching nvidia-driver-304-304.88_2.txz: 100% 21 MB 505.1k/s00:43 Fetching linux_base-f10-10_7.txz: 100% 17 MB 300.7k/s00:58 Checking integrity... done (0 conflicting) sysctl: unknown oid 'compat.linux.osrelease': No such file or directory linuxulator is not (kld)loaded, exiting pkg: PRE-INSTALL script failed [1/2] Installing linux_base-f10-10_7: 100% +++ Some programs may need linprocfs, please add it to /etc/fstab! +++ Running linux ldconfig... ELF binary type 3 not known. /compat/linux/sbin/ldconfig: Exec format error [2/2] Installing nvidia-driver-304-304.88_2: 100% ELF binary type 3 not known. /compat/linux/sbin/ldconfig: Exec format error root@saturn:~ # ___ 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: Poudriere Build of pkg_* repos?
On Thu, Sep 25, 2014 at 10:43 AM, Guido Falsi m...@madpilot.net wrote:
On 09/25/14 14:56, Rick Miller wrote:
On Wed, Sep 24, 2014 at 5:32 PM, Bryan Drewery bdrew...@freebsd.org
wrote:
[ snip ]
After creating an 8.4-RELEASE jail and an older, equivalent Ports tree as
follows...
# poudriere jail -c -j 8_4-amd64 -v 8.4-RELEASE -a amd64
# poudriere ports -c -p 8_4-amd64 -m svn+http -B branches/RELEASE_8_4_0
I think you should grab ports with the tag PKG_INSTALL_EOL (-B
tag/PKG_INSTALL_EOL)
That's the last revision at which the ports tree supported old pkg_tools.
/usr/local/etc/poudriere.d/8_4-amd64-make.conf:
WITHOUT_PKGNG=yes
PERL_VERSION=5.14.4
OPTIONS_UNSET=X11 GTK2
.if ${.CURDIR:M*/shells/bash}
EXTRA_PATCHES+= /distfiles/local-patches/8_4-amd64/bash.patch
.endif
note: above .if added to the make.conf according to the link provided
below
Executing poudriere bulk, as follows, results in no packages built due to
numerous stage failures subsequently resulting in a bunch of skipped
builds
due to these failures.
# poudriere bulk -j 8_4-amd64 -f $package_file -p 8_4-amd64
===phase: stage
make: don't know how to make stage. Stop
You took ports tagged for 8.4 release, which happened quite some time
ago, I don't think the ports tree had stage support at the time.
Thanks! That put me on the right track and a bash package was built, but
does not appear to have mitigated the vulnerability...
$ foo='() { echo hi mom; }' bash -c 'foo'
hi mom
The 4.3.25 patch[1] was downloaded and, with the above changes to the
make.conf, it appears to have applied cleanly according to the Poudriere
logs (note: this patch is the second patch application, bash.patch).
===phase: patch
=== Patching for bash-4.3.24
=== Applying distribution patches for bash-4.3.24
=== Applying extra patch /distfiles/local-patches/8_4-amd64/bash.patch
=== Applying extra patch
/usr/ports/shells/bash/files/extrapatch-colonbreakswords
=== Applying extra patch
/usr/ports/shells/bash/files/extrapatch-implicitcd
=== Applying FreeBSD patches for bash-4.3.24
===
The first sign that something didn't appear to have gone as expected was
that the package was built as bash-4.3.24.tbz as opposed to
bash-4.3.25.tbz. The above test was executed observing the behavior of a
still vulnerable binary.
The test was performed on an 8.4 host with a [unpatched] bash-4.3.24 after
forcefully removing the package and adding the new, patched package. It
complained of dependencies on packages that were already installed, but not
up to the version of the dependency. After manually fixing these
dependencies (forcefully deleting the existing dependencies and installing
the new ones), the test was executed once again to the same results.
Could this be an issue of the order the patches were applied in or ??
[1] http://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-025
--
Take care
Rick Miller
___
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: linux_base-f10-10_7 installation failure on FreeBSD 10.1 BETA2
Hi! I've FreeBSD 10.1 BETA2. I tried to install a package of nVidia 304.xx driver. This package depends on the linux_base-f10 one. The linuxulator installation has failed. See the sysctl: unknown oid 'compat.linux.osrelease': No such file or directory line in the following installation log. What does kldstat say ? I have it here on a 10.1 beta2 amd64 system: # sysctl -a | grep osrelease kern.osrelease: 10.1-BETA2 compat.linux.osrelease: 2.6.16 security.jail.param.linux.osrelease: 65 -- p...@opsec.eu+49 171 3101372 6 years to go ! ___ 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: Poudriere Build of pkg_* repos?
On 09/25/14 20:57, Rick Miller wrote:
On Thu, Sep 25, 2014 at 10:43 AM, Guido Falsi m...@madpilot.net wrote:
On 09/25/14 14:56, Rick Miller wrote:
On Wed, Sep 24, 2014 at 5:32 PM, Bryan Drewery bdrew...@freebsd.org
wrote:
[ snip ]
After creating an 8.4-RELEASE jail and an older, equivalent Ports tree as
follows...
# poudriere jail -c -j 8_4-amd64 -v 8.4-RELEASE -a amd64
# poudriere ports -c -p 8_4-amd64 -m svn+http -B branches/RELEASE_8_4_0
I think you should grab ports with the tag PKG_INSTALL_EOL (-B
tag/PKG_INSTALL_EOL)
That's the last revision at which the ports tree supported old pkg_tools.
/usr/local/etc/poudriere.d/8_4-amd64-make.conf:
WITHOUT_PKGNG=yes
PERL_VERSION=5.14.4
OPTIONS_UNSET=X11 GTK2
.if ${.CURDIR:M*/shells/bash}
EXTRA_PATCHES+= /distfiles/local-patches/8_4-amd64/bash.patch
.endif
note: above .if added to the make.conf according to the link provided
below
Executing poudriere bulk, as follows, results in no packages built due to
numerous stage failures subsequently resulting in a bunch of skipped
builds
due to these failures.
# poudriere bulk -j 8_4-amd64 -f $package_file -p 8_4-amd64
===phase: stage
make: don't know how to make stage. Stop
You took ports tagged for 8.4 release, which happened quite some time
ago, I don't think the ports tree had stage support at the time.
Thanks! That put me on the right track and a bash package was built, but
does not appear to have mitigated the vulnerability...
$ foo='() { echo hi mom; }' bash -c 'foo'
hi mom
I've not studied the vulnerability and can't really help you analyzing that.
I don't think the fix is going to completely disable such construct
though. But as I said I don't know the details right now.
The 4.3.25 patch[1] was downloaded and, with the above changes to the
make.conf, it appears to have applied cleanly according to the Poudriere
logs (note: this patch is the second patch application, bash.patch).
===phase: patch
=== Patching for bash-4.3.24
=== Applying distribution patches for bash-4.3.24
=== Applying extra patch /distfiles/local-patches/8_4-amd64/bash.patch
=== Applying extra patch
/usr/ports/shells/bash/files/extrapatch-colonbreakswords
=== Applying extra patch
/usr/ports/shells/bash/files/extrapatch-implicitcd
=== Applying FreeBSD patches for bash-4.3.24
===
The first sign that something didn't appear to have gone as expected was
that the package was built as bash-4.3.24.tbz as opposed to
bash-4.3.25.tbz. The above test was executed observing the behavior of a
still vulnerable binary.
The way you are applying the patch simply modifies the code being
compiled by the port, you're not patching the port itself, so the port
maintains the same version number.
The test was performed on an 8.4 host with a [unpatched] bash-4.3.24 after
forcefully removing the package and adding the new, patched package. It
complained of dependencies on packages that were already installed, but not
up to the version of the dependency. After manually fixing these
dependencies (forcefully deleting the existing dependencies and installing
the new ones), the test was executed once again to the same results.
Could this be an issue of the order the patches were applied in or ??
You should check the build log and see if in the patching phase there
was any error.
--
Guido Falsi m...@madpilot.net
___
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: linux_base-f10-10_7 installation failure on FreeBSD 10.1 BETA2
Hi! 'compat.linux.osrelease': No such file or directory line in the following installation log. What does kldstat say ? [...] root@saturn:~ # kldstat Id Refs AddressSize Name 17 0xc040 139e5a4 kernel 21 0xc6cbb000 5000 ums.ko 31 0xc72d6000 4000 uhid.ko root@saturn:~ # sysctl -a | grep osrelease kern.osrelease: 10.1-BETA2 root@saturn:~ # Please try: kldload linux The 'compat.linux.osrelease' is missing. Who is responsible to set it? The kernel module, if loaded, provides it. Is it the 'linux_base-f10' package itself? No. In /etc/rc.conf, add: linux_enable=YES Then: /etc/rc.d/abi restart -- p...@opsec.eu+49 171 3101372 6 years to go ! ___ 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
Fwd: linux_base-f10-10_7 installation failure on FreeBSD 10.1 BETA2
I forgot freebsd-ports@freebsd.org in the Cc. Forwarding: -- Forwarded message -- From: Rostislav Krasny rosti@gmail.com Date: Thu, Sep 25, 2014 at 10:08 PM Subject: Re: linux_base-f10-10_7 installation failure on FreeBSD 10.1 BETA2 To: Kurt Jaeger li...@opsec.eu On Thu, Sep 25, 2014 at 10:03 PM, Kurt Jaeger li...@opsec.eu wrote: Hi! I've FreeBSD 10.1 BETA2. I tried to install a package of nVidia 304.xx driver. This package depends on the linux_base-f10 one. The linuxulator installation has failed. See the sysctl: unknown oid 'compat.linux.osrelease': No such file or directory line in the following installation log. What does kldstat say ? I have it here on a 10.1 beta2 amd64 system: # sysctl -a | grep osrelease kern.osrelease: 10.1-BETA2 compat.linux.osrelease: 2.6.16 security.jail.param.linux.osrelease: 65 root@saturn:~ # kldstat Id Refs AddressSize Name 17 0xc040 139e5a4 kernel 21 0xc6cbb000 5000 ums.ko 31 0xc72d6000 4000 uhid.ko root@saturn:~ # sysctl -a | grep osrelease kern.osrelease: 10.1-BETA2 root@saturn:~ # The 'compat.linux.osrelease' is missing. Who is responsible to set it? Is it the 'linux_base-f10' package itself? ___ 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: linux_base-f10-10_7 installation failure on FreeBSD 10.1 BETA2
On Thu, Sep 25, 2014 at 10:11 PM, Kurt Jaeger li...@opsec.eu wrote: Hi! 'compat.linux.osrelease': No such file or directory line in the following installation log. What does kldstat say ? [...] root@saturn:~ # kldstat Id Refs AddressSize Name 17 0xc040 139e5a4 kernel 21 0xc6cbb000 5000 ums.ko 31 0xc72d6000 4000 uhid.ko root@saturn:~ # sysctl -a | grep osrelease kern.osrelease: 10.1-BETA2 root@saturn:~ # Please try: kldload linux After of before putting the ' linux_enable=YES' into the /etc/rc.conf and running ' /etc/rc.d/abi restart'? The 'compat.linux.osrelease' is missing. Who is responsible to set it? The kernel module, if loaded, provides it. Is it the 'linux_base-f10' package itself? No. In /etc/rc.conf, add: linux_enable=YES Then: /etc/rc.d/abi restart If this is mandatory, why the 'linux_base-f10' package doesn't check/update it by itself? ___ 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: linux_base-f10-10_7 installation failure on FreeBSD 10.1 BETA2
Hi! Please try: kldload linux After of before putting the ' linux_enable=YES' into the /etc/rc.conf and running ' /etc/rc.d/abi restart'? kldload linux tests whether it is loadable at all. The rest makes it work on reboot. If this is mandatory, why the 'linux_base-f10' package doesn't check/update it by itself? Because a pkg or port does not automatically change values in /etc/rc.conf. That should be a concious decision of the admin. -- p...@opsec.eu+49 171 3101372 6 years to go ! ___ 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: linux_base-f10-10_7 installation failure on FreeBSD 10.1 BETA2
On Thu, Sep 25, 2014 at 10:30 PM, Kurt Jaeger li...@opsec.eu wrote: Hi! Please try: kldload linux After of before putting the ' linux_enable=YES' into the /etc/rc.conf and running ' /etc/rc.d/abi restart'? kldload linux tests whether it is loadable at all. The rest makes it work on reboot. Ok, did it. Also deleted the 'nvidia-driver-304' and 'linux_base-f10' and installed them again by the same command. It works, thank you. If this is mandatory, why the 'linux_base-f10' package doesn't check/update it by itself? Because a pkg or port does not automatically change values in /etc/rc.conf. That should be a concious decision of the admin. But how could I know all this before the installation? The 'linux_base-f10' package could check it and stop the installation with an appropriate warning message, if that manadatory condition is not fulfilled. I think It must never try to install itself if it's known that it will fail. ___ 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: games/linux-nwnclient with c6
Hi Sean, thanks for reporting this issue. How should I request libGLU in c6 with and without nvidia-driver? Currently, the port sets USE_LINUX_APPS to either libglu or dri depending upon the driver. You just did, I'll take care of that port. If you could create an issue with Bugzilla about it as well (and assign it to me), that would help. Are you okay with using you as a bit of a guinea pig? I don't have a GPU that supports nvidia-driver OR a license to NWN, so I'd need someone with both to test if the Mesa/libGLU port actually works. Cheers, -xmj -- Johannes Meixner| FreeBSD Committer x...@freebsd.org| http://people.freebsd.org/~xmj pgpsy48HBM3xZ.pgp Description: PGP signature
Re: linux_base-f10-10_7 installation failure on FreeBSD 10.1 BETA2
Hi! If this is mandatory, why the 'linux_base-f10' package doesn't check/update it by itself? Because a pkg or port does not automatically change values in /etc/rc.conf. That should be a concious decision of the admin. But how could I know all this before the installation? I think in the past the module was automatically loaded, have a look at pkg-install, where it is done. I'm not sure whether pkg-install is still used in the new pkg(8) area. Anyway, linux_base-f10 is currently being replaced by linux_base-c6, a much more modern linux system (basically, cent os 6.5). See http://www.freshports.org/emulators/linux_base-c6/ for details and also check /usr/ports/UPDATING on that topic. -- p...@opsec.eu+49 171 3101372 6 years to go ! ___ 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: Poudriere Build of pkg_* repos?
On Thu, Sep 25, 2014 at 3:05 PM, Guido Falsi m...@madpilot.net wrote: On 09/25/14 20:57, Rick Miller wrote: On Thu, Sep 25, 2014 at 10:43 AM, Guido Falsi m...@madpilot.net wrote: [snip] ===phase: patch === Patching for bash-4.3.24 === Applying distribution patches for bash-4.3.24 === Applying extra patch /distfiles/local-patches/8_4-amd64/bash.patch === Applying extra patch /usr/ports/shells/bash/files/extrapatch-colonbreakswords === Applying extra patch /usr/ports/shells/bash/files/extrapatch-implicitcd === Applying FreeBSD patches for bash-4.3.24 === The first sign that something didn't appear to have gone as expected was that the package was built as bash-4.3.24.tbz as opposed to bash-4.3.25.tbz. The above test was executed observing the behavior of a still vulnerable binary. The way you are applying the patch simply modifies the code being compiled by the port, you're not patching the port itself, so the port maintains the same version number. Makes sense The test was performed on an 8.4 host with a [unpatched] bash-4.3.24 after forcefully removing the package and adding the new, patched package. It complained of dependencies on packages that were already installed, but not up to the version of the dependency. After manually fixing these dependencies (forcefully deleting the existing dependencies and installing the new ones), the test was executed once again to the same results. Could this be an issue of the order the patches were applied in or ?? You should check the build log and see if in the patching phase there was any error. The above log snippet is from the patch phase of the build indicating success (well, at least no error). A build with the wrong patch was attempted that did indicate errors, as expected. The full log can be viewed at http://pastebin.com/hwHwJAKK Is there some way in the log to identify if the source was patched and built correctly? Does Poudriere [ I say Poudriere realizing that it likely does not, but perhaps the system does? ] provide the ability to review the source code after patching to actually verify the patch was applied? A cursory search of the filesystem where Poudriere stores the jail turned up no leads. -- Take care Rick Miller ___ 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: On Docs option and custom build target
On Thu, Sep 25, 2014 at 12:06 PM, Tijl Coosemans t...@freebsd.org wrote:
On Wed, 24 Sep 2014 23:54:19 +0200 Fernando Apesteguía
fernando.apesteg...@gmail.com wrote:
On Wed, Sep 24, 2014 at 8:52 PM, Tijl Coosemans t...@freebsd.org wrote:
On Tue, 23 Sep 2014 23:23:31 +0200 Fernando Apesteguía
fernando.apesteg...@gmail.com wrote:
I have a Makefile for an application that provides both examples and
documentation. I created the two options in the Makefile (both enabled
by default).
The package doesn't provide any flags stock like --with-docs or
--with-examples, so I have a custom target like this:
do-build:
@cd ${BUILD_WRKSRC}/ ${MAKE}
.if ${PORT_OPTIONS:MDOCS}
@cd ${BUILD_WRKSRC}/ ${MAKE_CMD} doc
.endif
You don't have to override do-build like this. You can build the
documentation from a post-build target.
Thanks. Changed.
However, when I try to run this in poudriere, I get the following error:
make[1]: don't know how to make doc. Stop
make[1]: stopped in /wrkdirs/usr/ports/graphics/code-eli/work/.build
*** Error code 2
Does the makefile in BUILD_WRKSRC actually have a doc target? Is doc
a subdirectory maybe?
Yes it does.
In fact, with port test builds fine with the same code (change
directory and ${MAKE} doc). There is a doc.dir subdirectory in
BUILD_WRKSRC/CMakeFiles. The doc target basically gets a Doxygen
configuration file and runs doxygen on the whole library code.
Poudriere tests the port in a clean environment so check the build log
to see if any dependencies (like doxygen) are missing.
That's it!
Thanks!
___
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: Poudriere Build of pkg_* repos?
On Thu, Sep 25, 2014 at 4:51 PM, Rick Miller vmil...@hostileadmin.com wrote: On Thu, Sep 25, 2014 at 3:05 PM, Guido Falsi m...@madpilot.net wrote: On 09/25/14 20:57, Rick Miller wrote: On Thu, Sep 25, 2014 at 10:43 AM, Guido Falsi m...@madpilot.net wrote: [snip] ===phase: patch === Patching for bash-4.3.24 === Applying distribution patches for bash-4.3.24 === Applying extra patch /distfiles/local-patches/8_4-amd64/bash.patch === Applying extra patch /usr/ports/shells/bash/files/extrapatch-colonbreakswords === Applying extra patch /usr/ports/shells/bash/files/extrapatch-implicitcd === Applying FreeBSD patches for bash-4.3.24 === The first sign that something didn't appear to have gone as expected was that the package was built as bash-4.3.24.tbz as opposed to bash-4.3.25.tbz. The above test was executed observing the behavior of a still vulnerable binary. The way you are applying the patch simply modifies the code being compiled by the port, you're not patching the port itself, so the port maintains the same version number. Makes sense The test was performed on an 8.4 host with a [unpatched] bash-4.3.24 after forcefully removing the package and adding the new, patched package. It complained of dependencies on packages that were already installed, but not up to the version of the dependency. After manually fixing these dependencies (forcefully deleting the existing dependencies and installing the new ones), the test was executed once again to the same results. Could this be an issue of the order the patches were applied in or ?? You should check the build log and see if in the patching phase there was any error. The above log snippet is from the patch phase of the build indicating success (well, at least no error). A build with the wrong patch was attempted that did indicate errors, as expected. The full log can be viewed at http://pastebin.com/hwHwJAKK Is there some way in the log to identify if the source was patched and built correctly? Does Poudriere [ I say Poudriere realizing that it likely does not, but perhaps the system does? ] provide the ability to review the source code after patching to actually verify the patch was applied? A cursory search of the filesystem where Poudriere stores the jail turned up no leads. The patch does apply to evalstring.c which shows the following warnings in the build log though I am unfamiliar enough to know whether or not this would apply to this particular scenario. cc -c -DHAVE_CONFIG_H -DSHELL -I. -I.. -I.. -I../include -I../lib -I. -I/usr/local/include -O2 -pipe -fno-strict-aliasing evalstring.c evalstring.c: In function 'parse_and_execute': evalstring.c:208: warning: passing argument 1 of 'sigemptyset' discards qualifiers from pointer target type evalstring.c:209: warning: passing argument 3 of 'sigprocmask' discards qualifiers from pointer target type evalstring.c:288: warning: passing argument 2 of 'sigprocmask' discards qualifiers from pointer target type evalstring.c: In function 'parse_string': evalstring.c:444: warning: passing argument 1 of 'sigemptyset' discards qualifiers from pointer target type evalstring.c:445: warning: passing argument 3 of 'sigprocmask' discards qualifiers from pointer target type evalstring.c:497: warning: passing argument 2 of 'sigprocmask' discards qualifiers from pointer target type -- Take care Rick Miller ___ 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 1.3.8 requested but not available?
On Thu, Sep 25, 2014 at 3:05 AM, Joe Holden li...@rewt.org.uk wrote: RE original post, it is broken because pkg-1.3.7 is the latest in the pkg repo, whereas if you bootstrap it, the latest is 1.3.8, I just hit this and had to pkg remove -f pkg and bootstrap again Is this problem the following? (1) You have pkg-1.3.7 installed on your system (2) cd /usr/ports/ports-mgmt/pkg; make - build will fail because system will complain that you have pkg-1.3.7 installed but should have pkg-1.3.8 to continue -- Craig ___ 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: linux_base-f10-10_7 installation failure on FreeBSD 10.1 BETA2
On Thu, Sep 25, 2014 at 11:07 PM, Kurt Jaeger li...@opsec.eu wrote: Hi! If this is mandatory, why the 'linux_base-f10' package doesn't check/update it by itself? Because a pkg or port does not automatically change values in /etc/rc.conf. That should be a concious decision of the admin. But how could I know all this before the installation? I think in the past the module was automatically loaded, have a look at pkg-install, where it is done. I'm not sure whether pkg-install is still used in the new pkg(8) area. It seems it is. pkg-install of the linux_base-f10 has following code: case $2 in PRE-INSTALL) if [ `/sbin/sysctl -n compat.linux.osrelease`x = x ]; then echo 'linuxulator is not (kld)loaded, exiting' exit 1 fi if [ -z `kldstat -v | grep -E 'linux(aout|elf)'` ]; then echo 'Linux mode is not enabled.' echo 'Loading linux kernel module now...' if ! kldload linux; then echo 'The linux kernel module could not be loaded.' echo 'Please enable linux mode manually and retry.' exit 1 fi fi ;; This is exactly where it failed in my case. See logs in my first email. Firstly it's failed on running sysctl, then it printed out the 'linuxulator is not (kld)loaded, exiting' error message: sysctl: unknown oid 'compat.linux.osrelease': No such file or directory linuxulator is not (kld)loaded, exiting pkg: PRE-INSTALL script failed And it happens before the linux kernel module is loaded. Maybe this order is wrong? Anyway, linux_base-f10 is currently being replaced by linux_base-c6, a much more modern linux system (basically, cent os 6.5). Does it have the same problem? ___ 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: Poudriere Build of pkg_* repos?
On Thu, Sep 25, 2014 at 5:09 PM, Rick Miller vmil...@hostileadmin.com wrote: On Thu, Sep 25, 2014 at 4:51 PM, Rick Miller vmil...@hostileadmin.com wrote: On Thu, Sep 25, 2014 at 3:05 PM, Guido Falsi m...@madpilot.net wrote: On 09/25/14 20:57, Rick Miller wrote: On Thu, Sep 25, 2014 at 10:43 AM, Guido Falsi m...@madpilot.net wrote: [snip] ===phase: patch === Patching for bash-4.3.24 === Applying distribution patches for bash-4.3.24 === Applying extra patch /distfiles/local-patches/8_4-amd64/bash.patch === Applying extra patch /usr/ports/shells/bash/files/extrapatch-colonbreakswords === Applying extra patch /usr/ports/shells/bash/files/extrapatch-implicitcd === Applying FreeBSD patches for bash-4.3.24 === The first sign that something didn't appear to have gone as expected was that the package was built as bash-4.3.24.tbz as opposed to bash-4.3.25.tbz. The above test was executed observing the behavior of a still vulnerable binary. The way you are applying the patch simply modifies the code being compiled by the port, you're not patching the port itself, so the port maintains the same version number. Makes sense The test was performed on an 8.4 host with a [unpatched] bash-4.3.24 after forcefully removing the package and adding the new, patched package. It complained of dependencies on packages that were already installed, but not up to the version of the dependency. After manually fixing these dependencies (forcefully deleting the existing dependencies and installing the new ones), the test was executed once again to the same results. Could this be an issue of the order the patches were applied in or ?? You should check the build log and see if in the patching phase there was any error. The above log snippet is from the patch phase of the build indicating success (well, at least no error). A build with the wrong patch was attempted that did indicate errors, as expected. The full log can be viewed at http://pastebin.com/hwHwJAKK Is there some way in the log to identify if the source was patched and built correctly? Does Poudriere [ I say Poudriere realizing that it likely does not, but perhaps the system does? ] provide the ability to review the source code after patching to actually verify the patch was applied? A cursory search of the filesystem where Poudriere stores the jail turned up no leads. The patch does apply to evalstring.c which shows the following warnings in the build log though I am unfamiliar enough to know whether or not this would apply to this particular scenario. cc -c -DHAVE_CONFIG_H -DSHELL -I. -I.. -I.. -I../include -I../lib -I. -I/usr/local/include -O2 -pipe -fno-strict-aliasing evalstring.c evalstring.c: In function 'parse_and_execute': evalstring.c:208: warning: passing argument 1 of 'sigemptyset' discards qualifiers from pointer target type evalstring.c:209: warning: passing argument 3 of 'sigprocmask' discards qualifiers from pointer target type evalstring.c:288: warning: passing argument 2 of 'sigprocmask' discards qualifiers from pointer target type evalstring.c: In function 'parse_string': evalstring.c:444: warning: passing argument 1 of 'sigemptyset' discards qualifiers from pointer target type evalstring.c:445: warning: passing argument 3 of 'sigprocmask' discards qualifiers from pointer target type evalstring.c:497: warning: passing argument 2 of 'sigprocmask' discards qualifiers from pointer target type After reading an extensive thread about this, I was able to reliably test the immediate threat which does mitigate the initial risk. Having said that, there is ongoing discussion about a more long term solution. -- Take care Rick Miller ___ 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: squid-3.4.8_1 leaking memory
(Bottom-posted) On 25/09/2014 3:48 PM, Brian W. wrote: You seem to be onto something. On a single user testbox I use I see this PID USERNAMETHR PRI NICE SIZERES STATE C TIMEWCPU COMMAND 6100 squid 1 200 612M 84076K kqread 1 4:01 0.00% squid I then restarted squid and saw 73400 squid 1 200 61568K 21456K kqread 0 0:00 0.00% squid I am on the i386 flavor of 10.0-RELEASE-p9 On Wed, Sep 24, 2014 at 9:56 PM, Victor Sudakov v...@mpeks.tomsk.su wrote: Colleagues, squid-3.4.8_1 seems to be leaking memory heavily. Its SIZE and RES are growing several MB per minute until eventually swapping begins. Is anyone using it? Have you encountered this problem? The relevant entries in squid.conf are: cache_mem 128 MB cache_dir ufs /webcache/cache 512 16 256 memory_pools off # neither on nor off have any effect on leaking. As you see, the memory requirements should be rather modest. Running on 8.4-RELEASE-p16 i386. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ I think you should file a bug report https://bugs.freebsd.org/bugzilla/enter_bug.cgi so that this can be actioned/tracked. I don't have squid 3.4.8 running yet, but a friend forwarded his experience after only 6 days of light use: last pid: 43552; load averages: 0.34, 0.23, 0.18 up 5+22:34:1206:01:32 245 processes: 1 running, 244 sleeping Mem: 483M Active, 6021M Inact, 1581M Wired, 371M Cache, 1636M Buf, 7394M Free Swap: 32G Total, 1104M Used, 31G Free, 3% Inuse PID USERNAMETHR PRI NICE SIZERES STATE C TIMEWCPU COMMAND 6095 squid 1 200 738M 63044K kqread 7 2:12 0.00% squid 73487 squid 1 200 326M 7548K kqread 3 0:15 0.00% squid Regards, Dewayne. ___ 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: squid-3.4.8_1 leaking memory
Dewayne Geraghty wrote: squid-3.4.8_1 seems to be leaking memory heavily. Its SIZE and RES are growing several MB per minute until eventually swapping begins. [dd] I think you should file a bug report https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193938 If anyone has anything to add or just say me too, please do. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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: squid-3.4.8_1 leaking memory
I added my observations via forward to the freebsd ports list since that is the listed maintainer for squid. Brian On Sep 25, 2014 10:11 PM, Victor Sudakov v...@mpeks.tomsk.su wrote: Dewayne Geraghty wrote: squid-3.4.8_1 seems to be leaking memory heavily. Its SIZE and RES are growing several MB per minute until eventually swapping begins. [dd] I think you should file a bug report https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193938 If anyone has anything to add or just say me too, please do. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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
