Fail to kill children
FreeBSD 10.1-RELEASE #0 r276896: pkg 1.4.4 or pkg 1.4.6 poudriere 3.1.1 under 11.0-CURRENT r275419 On i386 only pkg complains with "Fail to kill children". I have checked some but not all packages and they appear to be updated as expected so this is a heads up. I do not see this behaviour with pkg on amd64 clients. I see this behaviour on more than one i386 client. Anything further I can provide? --mikej [root@jackson /usr/home/mikej]# pkg upgrade Updating 0_local repository catalogue... 0_local repository is up-to-date. All repositories are up-to-date. Checking for upgrades (6 candidates): 100% Processing candidates (6 candidates): 100% The following 6 packages will be affected (of 0 checked): Installed packages to be UPGRADED: unzip: 6.0_2 -> 6.0_3 pciids: 20150105 -> 20150117 openssl: 1.0.1_17 -> 1.0.1_18 duo: 1.9.13 -> 1.9.13_1 ccache: 3.2.1 -> 3.2.1_1 bash: 4.3.30_1 -> 4.3.33 The process will require 1 KB more space. 4 MB to be downloaded. Proceed with this action? [y/N]: y Fetching unzip-6.0_3.txz: 100% 121 KB 123.9k/s00:01 Fetching pciids-20150117.txz: 100% 185 KB 189.4k/s00:01 Fetching openssl-1.0.1_18.txz: 100%2 MB 851.7k/s00:03 Fetching duo-1.9.13_1.txz: 100% 70 KB 71.2k/s00:01 Fetching ccache-3.2.1_1.txz: 100% 80 KB 81.8k/s00:01 Fetching bash-4.3.33.txz: 100%1 MB 594.3k/s00:02 Checking integrity... done (0 conflicting) [1/6] Upgrading unzip from 6.0_2 to 6.0_3... pkg: Fail to kill children [1/6] Extracting unzip-6.0_3: 100% pkg: Fail to kill children [2/6] Upgrading pciids from 20150105 to 20150117... pkg: Fail to kill children [2/6] Extracting pciids-20150117: 100% pkg: Fail to kill children [3/6] Upgrading openssl from 1.0.1_17 to 1.0.1_18... pkg: Fail to kill children pkg: Fail to kill children [3/6] Extracting openssl-1.0.1_18: 100% pkg: Fail to kill children [4/6] Upgrading duo from 1.9.13 to 1.9.13_1... You may need to manually remove /usr/local/etc/login_duo.conf if it's no longer needed. pkg: Fail to kill children [4/6] Extracting duo-1.9.13_1: 100% pkg: Fail to kill children [5/6] Upgrading ccache from 3.2.1 to 3.2.1_1... pkg: Fail to kill children [5/6] Extracting ccache-3.2.1_1: 100% Create compiler links... create symlink for cc create symlink for cc (world) create symlink for c++ create symlink for c++ (world) create symlink for CC create symlink for CC (world) create symlink for gcc create symlink for gcc (world) create symlink for g++ create symlink for g++ (world) create symlink for gcc48 create symlink for gcc48 (world) create symlink for g++48 create symlink for g++48 (world) pkg: Fail to kill children [6/6] Upgrading bash from 4.3.30_1 to 4.3.33... pkg: Fail to kill children [6/6] Extracting bash-4.3.33: 100% pkg: Fail to kill children Message for openssl-1.0.1_18: Copy /usr/local/openssl/openssl.cnf.sample to /usr/local/openssl/openssl.cnf and edit it to fit your needs. Message for duo-1.9.13_1: = Configuration file /usr/local/etc/login_duo.conf was created. You must edit it to add your Duo integration and secret keys. If you are using the PAM module, a line similar to the following should be added to your service(s) of choice in /etc/pam.d: authrequired/usr/local/lib/security/pam_duo.so Additionally, you must edit /usr/local/etc/pam_duo.conf duo headers have been installed to /usr/local/include/duo = Message for ccache-3.2.1_1: NOTE: Please read /usr/local/share/doc/ccache/ccache-howto-freebsd.txt for information on using ccache with FreeBSD ports and src. Message for bash-4.3.33: == bash requires fdescfs(5) mounted on /dev/fd If you have not done it yet, please do the following: mount -t fdescfs fdesc /dev/fd To make it permanent, you need the following lines in /etc/fstab: fdesc /dev/fd fdescfs rw 0 0 == [root@jackson /usr/home/mikej]# So ccache for example did get upgraded. [root@jackson /usr/home/mikej]# ccache -V ccache version 3.2.1 ___ 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 - Fail to kill children
On 2015-01-19 09:20, Michael Jung wrote: FreeBSD 10.1-RELEASE #0 r276896: pkg 1.4.4 or pkg 1.4.6 poudriere 3.1.1 under 11.0-CURRENT r275419 On i386 only pkg complains with "Fail to kill children". I have checked some but not all packages and they appear to be updated as expected so this is a heads up. I do not see this behaviour with pkg on amd64 clients. I see this behaviour on more than one i386 client. Anything further I can provide? --mikej [root@jackson /usr/home/mikej]# pkg upgrade Updating 0_local repository catalogue... 0_local repository is up-to-date. All repositories are up-to-date. Checking for upgrades (6 candidates): 100% Processing candidates (6 candidates): 100% The following 6 packages will be affected (of 0 checked): Installed packages to be UPGRADED: unzip: 6.0_2 -> 6.0_3 pciids: 20150105 -> 20150117 openssl: 1.0.1_17 -> 1.0.1_18 duo: 1.9.13 -> 1.9.13_1 ccache: 3.2.1 -> 3.2.1_1 bash: 4.3.30_1 -> 4.3.33 The process will require 1 KB more space. 4 MB to be downloaded. Proceed with this action? [y/N]: y Fetching unzip-6.0_3.txz: 100% 121 KB 123.9k/s00:01 Fetching pciids-20150117.txz: 100% 185 KB 189.4k/s00:01 Fetching openssl-1.0.1_18.txz: 100%2 MB 851.7k/s00:03 Fetching duo-1.9.13_1.txz: 100% 70 KB 71.2k/s00:01 Fetching ccache-3.2.1_1.txz: 100% 80 KB 81.8k/s00:01 Fetching bash-4.3.33.txz: 100%1 MB 594.3k/s00:02 Checking integrity... done (0 conflicting) [1/6] Upgrading unzip from 6.0_2 to 6.0_3... pkg: Fail to kill children [1/6] Extracting unzip-6.0_3: 100% pkg: Fail to kill children [2/6] Upgrading pciids from 20150105 to 20150117... pkg: Fail to kill children [2/6] Extracting pciids-20150117: 100% pkg: Fail to kill children [3/6] Upgrading openssl from 1.0.1_17 to 1.0.1_18... pkg: Fail to kill children pkg: Fail to kill children [3/6] Extracting openssl-1.0.1_18: 100% pkg: Fail to kill children [4/6] Upgrading duo from 1.9.13 to 1.9.13_1... You may need to manually remove /usr/local/etc/login_duo.conf if it's no longer needed. pkg: Fail to kill children [4/6] Extracting duo-1.9.13_1: 100% pkg: Fail to kill children [5/6] Upgrading ccache from 3.2.1 to 3.2.1_1... pkg: Fail to kill children [5/6] Extracting ccache-3.2.1_1: 100% Create compiler links... create symlink for cc create symlink for cc (world) create symlink for c++ create symlink for c++ (world) create symlink for CC create symlink for CC (world) create symlink for gcc create symlink for gcc (world) create symlink for g++ create symlink for g++ (world) create symlink for gcc48 create symlink for gcc48 (world) create symlink for g++48 create symlink for g++48 (world) pkg: Fail to kill children [6/6] Upgrading bash from 4.3.30_1 to 4.3.33... pkg: Fail to kill children [6/6] Extracting bash-4.3.33: 100% pkg: Fail to kill children Message for openssl-1.0.1_18: Copy /usr/local/openssl/openssl.cnf.sample to /usr/local/openssl/openssl.cnf and edit it to fit your needs. Message for duo-1.9.13_1: = Configuration file /usr/local/etc/login_duo.conf was created. You must edit it to add your Duo integration and secret keys. If you are using the PAM module, a line similar to the following should be added to your service(s) of choice in /etc/pam.d: authrequired/usr/local/lib/security/pam_duo.so Additionally, you must edit /usr/local/etc/pam_duo.conf duo headers have been installed to /usr/local/include/duo = Message for ccache-3.2.1_1: NOTE: Please read /usr/local/share/doc/ccache/ccache-howto-freebsd.txt for information on using ccache with FreeBSD ports and src. Message for bash-4.3.33: == bash requires fdescfs(5) mounted on /dev/fd If you have not done it yet, please do the following: mount -t fdescfs fdesc /dev/fd To make it permanent, you need the following lines in /etc/fstab: fdesc /dev/fd fdescfs rw 0 0 == [root@jackson /usr/home/mikej]# So ccache for example did get upgraded. [root@jackson /usr/home/mikej]# ccache -V ccache version 3.2.1 ___ 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"
pkg 1.5.1 wants to remove locked packages
Maybe I'm missing something obvious, but pkg 1.5.1 wants to remove
locked
packages. The packages are indeed really removed.
Thanks.
--mikej
"pkg lock is used to lock packages against reinstallation, modification
or
deletion."
FreeBSD charon.corp.pai.local 10.1-RC1-p2 FreeBSD
I do not have /usr/local/etc/pkg.conf file
root@charon /var/log]# pkg lock -l
Currently locked packages:
chromium-40.0.2214.115 <-
firefox-esr-31.6.0,1
libreoffice-4.3.6 <-
[root@charon /var/log]# pkg upgrade
Updating 0local repository catalogue...
0local repository is up-to-date.
All repositories are up-to-date.
Checking for upgrades (634 candidates): 100%
Processing candidates (634 candidates): 0%
chromium-40.0.2214.115 is locked and may not be modified
Processing candidates (634 candidates): 100%
The following 75 package(s) will be affected (of 0 checked):
Installed packages to be REMOVED:
libvisio01-0.1.1
libmspub01-0.1.2
libe-book-0.1.2
libcdr01-0.1.1
qt5-webkit-5.3.2_1
libreoffice-4.3.6<--
qt5-declarative-5.3.2
stellarium-0.13.1
chromium-40.0.2214.115 <
qt5-designer-5.3.2
qt5-assistant-5.3.2
[root@charon /usr/local/etc]# pkg -vv
Version : 1.5.1
PKG_DBDIR = "/var/db/pkg";
PKG_CACHEDIR = "/var/cache/pkg";
PORTSDIR = "/usr/ports";
INDEXDIR = "";
INDEXFILE = "INDEX-10";
HANDLE_RC_SCRIPTS = false;
DEFAULT_ALWAYS_YES = false;
ASSUME_ALWAYS_YES = false;
REPOS_DIR [
"/etc/pkg/",
"/usr/local/etc/pkg/repos/",
]
PLIST_KEYWORDS_DIR = "";
SYSLOG = true;
ABI = "FreeBSD:10:amd64";
ALTABI = "freebsd:10:x86:64";
DEVELOPER_MODE = false;
VULNXML_SITE = "http://vuxml.freebsd.org/freebsd/vuln.xml.bz2";;
FETCH_RETRY = 3;
PKG_PLUGINS_DIR = "/usr/local/lib/pkg/";
PKG_ENABLE_PLUGINS = true;
PLUGINS [
]
DEBUG_SCRIPTS = false;
PLUGINS_CONF_DIR = "/usr/local/etc/pkg/";
PERMISSIVE = false;
REPO_AUTOUPDATE = true;
NAMESERVER = "";
EVENT_PIPE = "";
FETCH_TIMEOUT = 30;
UNSET_TIMESTAMP = false;
SSH_RESTRICT_DIR = "";
PKG_ENV {
}
PKG_SSH_ARGS = "";
DEBUG_LEVEL = 0;
ALIAS {
}
CUDF_SOLVER = "";
SAT_SOLVER = "";
RUN_SCRIPTS = true;
CASE_SENSITIVE_MATCH = false;
LOCK_WAIT = 1;
LOCK_RETRIES = 5;
SQLITE_PROFILE = false;
WORKERS_COUNT = 0;
READ_LOCK = false;
PLIST_ACCEPT_DIRECTORIES = false;
IP_VERSION = 0;
AUTOMERGE = true;
VERSION_SOURCE = "";
CONSERVATIVE_UPGRADE = true;
PKG_CREATE_VERBOSE = false;
Repositories:
0local: {
url : "pkg+http://10.10.0.80/10stablepkg";,
enabled : yes,
priority: 0,
mirror_type : "SRV"
}
[root@charon /usr/local/etc]#
___
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.5.1 wants to remove locked packages
On 2015-04-27 09:59, Baptiste Daroussin wrote: On Mon, Apr 27, 2015 at 09:21:40AM -0400, Michael Jung wrote: Maybe I'm missing something obvious, but pkg 1.5.1 wants to remove locked packages. The packages are indeed really removed. Thanks. --mikej "pkg lock is used to lock packages against reinstallation, modification or deletion." FreeBSD charon.corp.pai.local 10.1-RC1-p2 FreeBSD I do not have /usr/local/etc/pkg.conf file root@charon /var/log]# pkg lock -l Currently locked packages: chromium-40.0.2214.115 <- firefox-esr-31.6.0,1 libreoffice-4.3.6 <- [root@charon /var/log]# pkg upgrade Updating 0local repository catalogue... 0local repository is up-to-date. All repositories are up-to-date. Checking for upgrades (634 candidates): 100% Processing candidates (634 candidates): 0% chromium-40.0.2214.115 is locked and may not be modified Processing candidates (634 candidates): 100% The following 75 package(s) will be affected (of 0 checked): Installed packages to be REMOVED: libvisio01-0.1.1 libmspub01-0.1.2 libe-book-0.1.2 libcdr01-0.1.1 qt5-webkit-5.3.2_1 libreoffice-4.3.6<-- qt5-declarative-5.3.2 stellarium-0.13.1 chromium-40.0.2214.115 < qt5-designer-5.3.2 qt5-assistant-5.3.2 Can you run pkg -o DEBUG_LEVEL=4 upgrade and send me the output (be careful this will be verbose) This is probably due to icu update somehow, as libreoffice and chrome will not work without being themselves upgraded but you locked them. Probably the answer of removing them is bad and we should just stop the processing saying we cannot go further without you unlocking the said packages. Best regards, Bapt Unfortunately we went ahead with the upgrade. I will send the output if I can reproduce it on another machine. Thank you. --mikej ___ 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.5.1 wants to remove locked packages
On 2015-04-27 09:59, Baptiste Daroussin wrote: On Mon, Apr 27, 2015 at 09:21:40AM -0400, Michael Jung wrote: Maybe I'm missing something obvious, but pkg 1.5.1 wants to remove locked packages. The packages are indeed really removed. Thanks. --mikej "pkg lock is used to lock packages against reinstallation, modification or deletion." FreeBSD charon.corp.pai.local 10.1-RC1-p2 FreeBSD I do not have /usr/local/etc/pkg.conf file root@charon /var/log]# pkg lock -l Currently locked packages: chromium-40.0.2214.115 <- firefox-esr-31.6.0,1 libreoffice-4.3.6 <- [root@charon /var/log]# pkg upgrade Updating 0local repository catalogue... 0local repository is up-to-date. All repositories are up-to-date. Checking for upgrades (634 candidates): 100% Processing candidates (634 candidates): 0% chromium-40.0.2214.115 is locked and may not be modified Processing candidates (634 candidates): 100% The following 75 package(s) will be affected (of 0 checked): Installed packages to be REMOVED: libvisio01-0.1.1 libmspub01-0.1.2 libe-book-0.1.2 libcdr01-0.1.1 qt5-webkit-5.3.2_1 libreoffice-4.3.6<-- qt5-declarative-5.3.2 stellarium-0.13.1 chromium-40.0.2214.115 < qt5-designer-5.3.2 qt5-assistant-5.3.2 Can you run pkg -o DEBUG_LEVEL=4 upgrade and send me the output (be careful this will be verbose) This is probably due to icu update somehow, as libreoffice and chrome will not work without being themselves upgraded but you locked them. Probably the answer of removing them is bad and we should just stop the processing saying we cannot go further without you unlocking the said packages. Best regards, Bapt Bapt, This has happened again and I have the debug output you requested. I have NOT proceeded with the updates this time and will await your remarks. Charon is FreeBSD 10 r277247M [root@charon /home/mikej/Downloads]# pkg -v 1.5.2 [root@charon /home/mikej/Downloads]# pkg lock -l Currently locked packages: libreoffice-4.3.6 <--- [root@charon /home/mikej/Downloads]# pkg upgrade Updating 0local repository catalogue... 0local repository is up-to-date. All repositories are up-to-date. Checking for upgrades (564 candidates): 100% Processing candidates (564 candidates): 100% Checking integrity... done (1 conflicting) Checking integrity... done (0 conflicting) The following 10 package(s) will be affected (of 0 checked): Installed packages to be REMOVED: liborcus07-0.7.0 libreoffice-4.3.6<--- Installed packages to be UPGRADED: oss: 4.2.b2009_1 -> 4.2.b2011 npth: 1.1 -> 1.2 liborcus: 0.5.2_1 -> 0.9.0 gpgme: 1.5.3 -> 1.5.4 gawk: 4.1.1_1 -> 4.1.2 erlang: 17.5.2_1,3 -> 17.5.3,3 ccache: 3.2.1_2 -> 3.2.1_3 GeoIP: 1.6.5_1 -> 1.6.5_2 The operation will free 289 MiB. Proceed with this action? [y/N]: n [root@charon /home/mikej/Downloads]# Full debug output https://charon.gopai.com/pkg.out.tgz My repository is built with: [root@bsd11 /var/log]# poudriere version 3.1.3 Regards, --mikej ___ 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: [Bug 205242] editors/libreoffice (5.0.3, r403255) does not build in poudriere on 11.0-CURRENT r276659
On 2015-12-15 09:02, Matthias Apitz wrote:
El día Monday, December 14, 2015 a las 06:59:48AM +0100, Matthias
Apitz escribió:
> > There are other (older) cases visible with Google showing the same
> > problem, for example:
> > https://forums-web2.gentoo.org/viewtopic-t-1025000.html
> > saying that the dir /Gallery/arrows/ only contains two empty files
> > with the names arrows.sdv and arrows.thm. The files are not part of the
> > tar file in /usr/ports/distfiles so they are perhaps generated wrong
> > on the run.
I could save the workspace and it shows that the two mentioned files
are
zero sized:
# ls -l libreoffice-5.0.3.2/workdir/Gallery/arrows/arrows.*
-rw-r--r-- 1 guru wheel 0 Dec 13 21:48
libreoffice-5.0.3.2/workdir/Gallery/arrows/arrows.sdv
-rw-r--r-- 1 guru wheel 0 Dec 13 21:48
libreoffice-5.0.3.2/workdir/Gallery/arrows/arrows.thm
the files are generated by some tool 'gengal'
libreoffice-5.0.3.2/svx/source/gengal
libreoffice-5.0.3.2/svx/source/gengal/gengal.sh
libreoffice-5.0.3.2/svx/source/gengal/gengal.cxx
The shell script gengal.sh is not used;
I was unable to use 'poudriere testport ...' with this the make cores
at
some earlier point.
I've built it again the port within podriere mit more verbosity; the
failing part is this:
...
[build LNK] Executable/gengal.bin
S=/wrkdirs/usr/ports/editors/libreoffice/work/libreoffice-5.0.3.2 &&
I=$S/instdir && W=$S/workdir && clang++-Wl,-z,origin
'-Wl,-rpath,$ORIGIN' -Wl,-rpath-link,$I/program
-fstack-protector-strong -Wl,-rpath-link,/lib:/usr/lib
-Wl,-z,combreloc -Wl,--hash-style=gnu -Wl,--dynamic-list-cpp-new
-Wl,--dynamic-list-cpp-typeinfo -Wl,-Bsymbolic-functions
-L$W/LinkTarget/StaticLibrary -L$I/sdk/lib -L$I/program -L$I/program
-L/usr/local/lib -fstack-protector -L/usr/local/lib
$W/CxxObject/svx/source/gengal/gengal.o -Wl,--start-group
$W/LinkTarget/StaticLibrary/libvclmain.a
$W/LinkTarget/StaticLibrary/libglxtest.a -lGL -lX11 -Wl,--end-group
-Wl,--no-as-needed -lbasegfxlo -luno_sal -ltllo -lsvllo -lsvtlo
-lcomphelper -luno_cppu -luno_cppuhelpergcc3 -lutllo -lvcllo
-lsvxcorelo -o $I/program/gengal.bin
TEMPFILE=/tmp/gbuild.XX.KP2AjNiW && mv ${TEMPFILE}
/wrkdirs/usr/ports/editors/libreoffice/work/libreoffice-5.0.3.2/workdir/LinkTarget/Executable/gengal.bin.objectlist
touch
/wrkdirs/usr/ports/editors/libreoffice/work/libreoffice-5.0.3.2/workdir/Executable/gengal.run
mkdir -p
/wrkdirs/usr/ports/editors/libreoffice/work/libreoffice-5.0.3.2/workdir/Gallery/
mkdir -p
/wrkdirs/usr/ports/editors/libreoffice/work/libreoffice-5.0.3.2/workdir/Gallery/arrows/
mkdir -p
/wrkdirs/usr/ports/editors/libreoffice/work/libreoffice-5.0.3.2/workdir/Package/prepared/Gallery/Files/
&& touch
/wrkdirs/usr/ports/editors/libreoffice/work/libreoffice-5.0.3.2/workdir/Package/prepared/Gallery/Files/arrows
[build GAL] arrows
S=/wrkdirs/usr/ports/editors/libreoffice/work/libreoffice-5.0.3.2 &&
I=$S/instdir && W=$S/workdir && rm -f $W/Gallery/arrows/* &&
RESPONSEFILE=/tmp/gbuild.XX.bLFqAu2F && SAL_USE_VCLPLUGIN=svp
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/program:$I/program"
$I/program/gengal.bin "-env:BRAND_BASE_DIR=file://$S/instdir"
"-env:CONFIGURATION_LAYERS=xcsxcu:file://$I/share/registry"
"-env:UNO_SERVICES=file://$W/Rdb/ure/services.rdb
file://$W/ComponentTarget/comphelper/util/comphelp.component
file://$W/ComponentTarget/configmgr/source/configmgr.component
file://$W/ComponentTarget/drawinglayer/drawinglayer.component
file://$W/ComponentTarget/framework/util/fwk.component
file://$W/ComponentTarget/i18npool/util/i18npool.component
file://$W/ComponentTarget/package/source/xstor/xstor.component
file://$W/ComponentTarget/package/util/package2.component
file://$W/ComponentTarget/sax/source/expatwrap/expwrap.component
file://$W/ComponentTarget/sfx2/util/sfx.component
file://$W/ComponentTarget/svgio/svgio.component
file://$W/ComponentTarget/svx/util/svx.component
file://$W/ComponentTarget/svx/util/svxcore.component
file://$W/ComponentTarget/ucb/source/core/ucb1.component
file://$W/ComponentTarget/ucb/source/ucp/file/ucpfile1.component
file://$W/ComponentTarget/unoxml/source/service/unoxml.component"
"-env:UNO_TYPES= file://$I/program/types/offapi.rdb
file://$I/program/types.rdb"
-env:URE_INTERNAL_LIB_DIR=file://$I/program
-env:LO_LIB_DIR=file://$I/program --build-tree --destdir
file://$S/extras/source/gallery --name "arrows" --path
$W/Gallery/arrows --filenames file://$RESPONSEFILE && rm
$RESPONSEFILE && touch $W/Gallery/arrows.done
Work on gallery
'file:///wrkdirs/usr/ports/editors/libreoffice/work/libreoffice-5.0.3.2/workdir/Gallery/arrows'
Existing themes: 0
Existing themes: 1
Failed to acquire theme
/wrkdirs/usr/ports/editors/libreoffice/work/libreoffice-5.0.3.2/solenv/gbuild/Gallery.mk:72:
recipe for target
'/wrkdirs/usr/ports/editors/libreoffice/work/libreoffice-5.0.3.2/workdir/Gallery/arrows.done'
failed
gmake[2]: ***
[/wrkdirs/usr/ports/editors/libreoffice/work/libreoffice-5.0.3.2/workdir/Gallery/ar
Re: [Bug 205242] editors/libreoffice (5.0.3, r403255) does not build in poudriere on 11.0-CURRENT r276659
On 2015-12-16 03:15, Matthias Apitz wrote:
El día Tuesday, December 15, 2015 a las 05:31:39PM -0500, Michael Jung
escribió:
> I still have a copy of the failed workspace.
>
>matthias
FWIW
# $FreeBSD: head/editors/libreoffice/Makefile 403436 2015-12-09
23:43:30Z jbeich $
built without error for me on FreeBSD 11.0-CURRENT #10 r291494M today.
using poudriere-devel-3.1.99.20151204
...
I'll be happy to post the log file or provide additional info if help
other regard
this as (s)HAM
Question: Do you compiled the port in poudriere with clang or gcc?
Please send ma the log off-list. Thanks.
Meanwhile, I could catch the situation with the failing gengal.bin for
the Gallery/arrows dir. A truss shows that the proc for gengal is
failing during start with a message:
pen("/wrkdirs/usr/ports/editors/libreoffice/work/libreoffice-5.0.3.2/workdir/Rdb/ure/services.rdb",O_EXCL,00)
= 7 (0x7)
fstat(7,{ mode=-rw-r--r-- ,inode=168077,size=7991,blksize=4096 }) = 0
(0x0)
mmap(0x0,7991,PROT_READ,MAP_SHARED,7,0x0)= 34367979520
(0x8007dc000)
munmap(0x8007dc000,7991) = 0 (0x0)
close(7) = 0 (0x0)
write(2,"Bootstrap exception 'service not supplied'\n",43) = 43 (0x2b)
_umtx_op(0x800630008,UMTX_OP_WAIT_UINT_PRIVATE,0x0,0x18,0x7fffdfffdee0)
= 0 (0x0)
_umtx_op(0x819c06658,UMTX_OP_NWAKE_PRIVATE,0x1,0x0,0x0) = 0 (0x0)
open("/lib/libgcc_s.so.1",O_CLOEXEC,00) = 7 (0x7)
fstat(7,{ mode=-r--r--r-- ,inode=16373968,size=56248,blksize=32768 }) =
0 (0x0)
close(7) = 0 (0x0)
_umtx_op(0x819c07000,UMTX_OP_WAIT,0x1875d,0x0,0x0) = 0 (0x0)
munmap(0x8007cc000,65536)= 0 (0x0)
munmap(0x8007bc000,65536)= 0 (0x0)
madvise(0x819cf,0x3a000,0x5,0x804d4dbe8,0x804d4dbe8,0x0) = 0 (0x0)
close(3) = 0 (0x0)
madvise(0x819cbe000,0x32000,0x5,0x804d4dbe8,0x804d4dbe8,0x0) = 0 (0x0)
madvise(0x819c9c000,0x2000,0x5,0x804d4dbe8,0x804d4dbe8,0x0) = 0 (0x0)
process exit, rval = 1
I have from the situation the following data:
- complete args and environment for gengal.bin
- the above visible XML file services.rdb
- the complete truss file
The failing code in gengal.cxx is this
void GalApp::Init()
{
try {
if( !mbInBuildTree && getenv( "OOO_INSTALL_PREFIX" ) == NULL )
{
OUString fileName = GetAppFileName();
int lastSlash = fileName.lastIndexOf( '/' );
#ifdef WNT
// Don't know which directory separators GetAppFileName()
// returns on Windows.
// Be safe and take into consideration they might be
// backslashes.
if( fileName.lastIndexOf( '\\' ) > lastSlash )
lastSlash = fileName.lastIndexOf( '\\' );
#endif
OUString baseBinDir = fileName.copy( 0, lastSlash );
OUString installPrefix = baseBinDir + "/../..";
OUString envVar( "OOO_INSTALL_PREFIX");
osl_setEnvironment(envVar.pData, installPrefix.pData);
}
OSL_TRACE( "OOO_INSTALL_PREFIX=%s", getenv(
"OOO_INSTALL_PREFIX"
) );
uno::Reference xComponentContext
= ::cppu::defaultBootstrap_InitialComponentContext();
xMSF = uno::Reference
( xComponentContext->getServiceManager(), uno::UNO_QUERY );
if( !xMSF.is() )
{
fprintf( stderr, "Failed to bootstrap\n" );
exit( 1 );
}
::comphelper::setProcessServiceFactory( xMSF );
// For backwards compatibility, in case some code still uses
// plain
// createInstance w/o args directly to obtain an instance:
com::sun::star::ucb::UniversalContentBroker::create(xComponentContext);
} catch (const uno::Exception &e) {
fprintf( stderr, "Bootstrap exception '%s'\n",
And I can very easy reproduce the problem by just un-taring a saved
work/ dir into a stopped jail, if someone with more C++ and libreoffice
knowledge is willing to investigate this.
Just drop me a line. Thanks
matthias
Clang - Log is in route.
--mikej
___
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"
Reporting fixes so that vuxml can be updated
Hi, "pkg audit" on my system returns the following CVE's for ffmpeg. I have noted in the list below that http://www.ffmpeg.org/security.html claims these CVE's were fixed in the ffmpeg version noted. Is this the correct place/list to report updates to that vuxml can be updated? I know there was a discussion about ports and security reporting and updating but I don't remember an outcome. Happy holidays, --mikej handbrake-0.10.2_2 is vulnerable: ffmpeg -- multiple vulnerabilities CVE: CVE-2015-6826 < Fixed in 2.7.2 CVE: CVE-2015-6825 < Fixed in 2.7.2 CVE: CVE-2015-6824 < Fixed in 2.7.2 CVE: CVE-2015-6823 < Fixed in 2.7.2 CVE: CVE-2015-6822 < Fixed in 2.7.2 CVE: CVE-2015-6821 < Fixed in 2.7.2 CVE: CVE-2015-6820 < Fixed in 2.7.2 CVE: CVE-2015-6819 < Fixed in 2.7.2 CVE: CVE-2015-6818 < Fixed in 2.7.2 WWW: https://vuxml.FreeBSD.org/freebsd/3d950687-b4c9-4a86-8478-c56743547af8.html handbrake-0.10.2_2 is vulnerable: ffmpeg -- use-after-free CVE: CVE-2015-3417 < Fixed in 2.5.2 WWW: https://vuxml.FreeBSD.org/freebsd/da434a78-e342-4d9a-87e2-7497e5f117ba.html handbrake-0.10.2_2 is vulnerable: ffmpeg -- multiple vulnerabilities CVE: CVE-2015-8365 < Fixed in 2.4.12 CVE: CVE-2015-8364 < Fixed in 2.4.12 CVE: CVE-2015-8363 < Fixed in 2.4.12 CVE: CVE-2015-8219 < Fixed in 2.4.12 CVE: CVE-2015-8218 < Fixed in 2.8.2 CVE: CVE-2015-8217 < Fixed in 2.8.2 CVE: CVE-2015-8216 < Fixed in 2.8.2 CVE: CVE-2015-6761 < Fixed in 2.8.2 WWW: https://vuxml.FreeBSD.org/freebsd/b0da85af-21a3-4c15-a137-fe9e4bc86002.html handbrake-0.10.2_2 is vulnerable: ffmpeg -- out-of-bounds array access CVE: CVE-2015-3395 < Fixed in 2.7 WWW: https://vuxml.FreeBSD.org/freebsd/80c66af0-d1c5-449e-bd31-63b12525ff88.html ___ 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: Reporting fixes so that vuxml can be updated
On 2015-12-23 11:55, Lowell Gilbert wrote: Michael Jung writes: "pkg audit" on my system returns the following CVE's for ffmpeg. I have noted in the list below that http://www.ffmpeg.org/security.html claims these CVE's were fixed in the ffmpeg version noted. Is this the correct place/list to report updates to that vuxml can be updated? No updates to vuxml are needed (or appropriate). Update your ffmpeg port and you'll be fine. ___ 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" I neglected to state that my port is current ffmpeg-2.8.3_2,1 Realtime audio/video encoder/converter and streaming server Yet all the CVE's reported by "pkg audit" have been fixed according to the ffmpeg security link provided in my previous email and my notes as to what version of ffmpeg they were corrected in. This would seem to me that vuxml is not current as of the current maintainers package version. PORTNAME= ffmpeg PORTVERSION=2.8.3 PORTREVISION= 2 PORTEPOCH= 1 Please let me know what I am missing here. Regards, --mikej ___ 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: Mailman in a jail
On 2016-04-21 14:10, Jim Ohlstein wrote:
Hello,
On 4/21/16 1:31 PM, Alphons van Werven wrote:
Jim Ohlstein wrote:
Mailman logs show connection errors.
I don't know exactly how Postfix and Mailman (try to) communicate with
one
another, but is it possible that SysV IPC has to be enabled for the
jail?
Or maybe raw sockets, although that's probably less likely.
Enabling each did not change the problem. I still see multiple lines
like this in Mailman's logs:
Apr 21 14:06:45 2016 (70072) Low level smtp error: [Errno 61]
Connection refused, msgid:
Apr 21 14:06:45 2016 (70072) delivery to em...@doman.com failed with
code -1: [Errno 61] Connection refused
and nothing in /var/log/maillog
A long time ago I setup mailman with postfix but not in a jail, from
my notes here is all I had in
/usr/local/mailman/Mailman/mm_cfg.py
IMAGE_LOGOS = '/icons/'
add_virtualhost('lists.foo.com', 'lists.foo.com')
POSTFIX_STYLE_VIRTUAL_DOMAINS = ['lists.foo.com']
DEFAULT_EMAIL_HOST = 'lists.foo.com'
DEFAULT_URL_HOST = 'lists.foo.com'
MTA = 'Postfix'
If you look at /usr/local/etc/mailman/Mailman/Defaults.py and you
haven't changed the directives below in in mm_cfg.py then they are
DELIVERY_MODULE = 'SMTPDirect'
SMTPHOST = 'localhost'
Could it be as simple as postfix is not listening on port 25?
Can you 'telnet localhost 25' and "telnet 25'
sucessfully?
--mikej
___
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: SAT resolver problem - [CFT] SSP Package Repository available
On 2014-08-22 16:17, Bryan Drewery wrote:
On 8/22/2014 1:16 PM, mikej wrote:
On , 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.
This repository is available for:
head
10.0
9.1,9.2,9.3
It is not available for 8.4. If someone is willing to test on 8.4 I
will
build a repository for it.
Place this in /usr/local/etc/pkgs/repos/FreeBSD_ssp.conf:
FreeBSD: { enabled: no }
FreeBSD_ssp: {
url: "pkg+http://pkg.FreeBSD.org/${ABI}/ssp";,
mirror_type: "srv",
signature_type: "fingerprints",
fingerprints: "/usr/share/keys/pkg",
enabled: yes
}
Once that is done you should force reinstall packages from this
repository:
pkg update
pkg upgrade -f
Thanks for your help!
Bryan Drewery
On behalf of portmgr.
I have been using this without issue on several machines until today.
root@firewall:/usr/ports # pkg -v
1.3.6
root@firewall:/usr/ports #
Repositories:
FreeBSD_ssp: {
url :
"pkg+http://pkg.FreeBSD.org/freebsd:10:x86:64/ssp";,
enabled : yes,
mirror_type : "SRV",
signature_type : "FINGERPRINTS",
fingerprints: "/usr/share/keys/pkg"
}
root@firewall:/usr/ports # pkg update -f
Updating repository catalogue
pkg: http://pkg.FreeBSD.org/freebsd:10:x86:64/ssp/meta.txz: Not Found
pkg: repository FreeBSD_ssp has no meta file, using default settings
Fetching digests.txz: 100% of 1 MB
Fetching packagesite.txz: 100% of 5 MB
Adding new entries: 100%
Incremental update completed, 23305 packages processed:
0 packages updated, 0 removed and 23305 added.
root@firewall:/usr/ports # pkg install mdnsresponder
Updating repository catalogue
pkg: http://pkg.FreeBSD.org/freebsd:10:x86:64/ssp/meta.txz: Not Found
pkg: repository FreeBSD_ssp has no meta file, using default settings
FreeBSD_ssp repository is up-to-date
All repositories are up-to-date
Checking integrity... done (1 conflicting)
pkg: Cannot solve problem using SAT solver:
cannot install package mDNSResponder~net/mDNSResponder, remove it from
request [Y/n]: y
Checking integrity... done (0 conflicting)
The most recent version of packages are already installed
root@firewall:/usr/ports # uname -a
FreeBSD firewall 10.0-STABLE FreeBSD 10.0-STABLE #0 r269366M: Fri Aug
1
00:35:49 EDT 2014 mikej@firewall:/usr/obj/usr/src/sys/GENERIC
amd64
root@firewall:/usr/ports # date
Fri Aug 22 14:12:30 EDT 2014
root@firewall:/usr/ports #
root@firewall:/usr/ports # pkg info | grep mdns
root@firewall:/usr/ports #
Regards,
--mikej
It looks like the (SSP) freebsd:10:x86:64 freebsd:11:x86:32
repositories
are stale from a month ago. Looking into why.
Sadly this was not noticed and the instructions effectively will
downgrade packages. These 2 repositories have pkg-1.2 still as well.
Bryan,
Any update? As you probably expect if I build the port locally with
poudriere and install there is no issue. I'm building with
WITH_SSP_PORTS=YES
in /etc/make.conf
Regards,
--mikej
___
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.7 out. Special handling recommended to avoid reinstalls.
Following your instructions: root@bsd11:/usr/home/mikej # pkg -v 1.3.6 root@bsd11:/usr/home/mikej # pkg update -f Updating repository catalogue Fetching meta.txz: 100% of 944 B Fetching digests.txz: 100% of 2 MB Fetching packagesite.txz: 100% of 5 MB Adding new entries: 100% Incremental update completed, 23246 packages processed: 0 packages updated, 0 removed and 23246 added. root@bsd11:/usr/home/mikej # pkg install ports-mgmt/pkg Updating repository catalogue FreeBSD_ssp repository is up-to-date All repositories are up-to-date pkg~ports-mgmt/pkg has no direct installation candidates, change it to pkg~ports-mgmt/pkg-devel [Y/n]: This is not what I expected. --mikej -Original Message- From: owner-freebsd-sta...@freebsd.org [mailto:owner-freebsd-sta...@freebsd.org] On Behalf Of Bryan Drewery Sent: Wednesday, August 27, 2014 11:28 AM To: p...@freebsd.org; po...@freebsd.org Subject: Pkg 1.3.7 out. Special handling recommended to avoid reinstalls. Pkg 1.3.7 is now released. The port is updated. pkg.FreeBSD.org packages are now published with fixed shared libraries. It was found that 'pkg update -f' may be required as well. Here are the updated instructions: - Binary package users should run 'pkg update -f' and 'pkg check -Ba' after upgrading to pkg-1.3.7 and before updating any other packages. This avoids needing to reinstall anything not needed due to changed shared libraries. For binary package users: # pkg install ports-mgmt/pkg # pkg update -f # pkg check -Ba # pkg upgrade For port users: # portsnap fetch update # make -C /usr/ports/ports-mgmt/pkg build deinstall install clean # pkg check -Ba - People building packages for serving to other systems need to rebuild all packages with 1.3.7. The previous announcement explaining this in more detail is at http://lists.freebsd.org/pipermail/freebsd-ports-announce/2014-August/86.html -- Regards, Bryan Drewery GoPai.com | Facebook.com/PaymentAlliance CONFIDENTIALITY NOTE: This message is intended only for the use of the individual or entity to whom it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, please notify us by telephone at (502) 212-4001 or notify us at PAI , Dept. 99, 6060 Dutchmans Lane, Suite 320, Louisville, KY 40205 ___ 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.7 out. Special handling recommended to avoid reinstalls.
NIX THIS! Damn, I ran this on a box with the SSP repository configured. Hope no-one wasted any time on this. Pkg has updated on numerous other machines without incident. :-( -Original Message- From: Michael Jung Sent: Wednesday, August 27, 2014 1:10 PM To: 'Ports FreeBSD'; p...@freebsd.org; po...@freebsd.org Subject: RE: Pkg 1.3.7 out. Special handling recommended to avoid reinstalls. Following your instructions: root@bsd11:/usr/home/mikej # pkg -v 1.3.6 root@bsd11:/usr/home/mikej # pkg update -f Updating repository catalogue Fetching meta.txz: 100% of 944 B Fetching digests.txz: 100% of 2 MB Fetching packagesite.txz: 100% of 5 MB Adding new entries: 100% Incremental update completed, 23246 packages processed: 0 packages updated, 0 removed and 23246 added. root@bsd11:/usr/home/mikej # pkg install ports-mgmt/pkg Updating repository catalogue FreeBSD_ssp repository is up-to-date All repositories are up-to-date pkg~ports-mgmt/pkg has no direct installation candidates, change it to pkg~ports-mgmt/pkg-devel [Y/n]: This is not what I expected. --mikej -Original Message- From: owner-freebsd-sta...@freebsd.org [mailto:owner-freebsd-sta...@freebsd.org] On Behalf Of Bryan Drewery Sent: Wednesday, August 27, 2014 11:28 AM To: p...@freebsd.org; po...@freebsd.org Subject: Pkg 1.3.7 out. Special handling recommended to avoid reinstalls. Pkg 1.3.7 is now released. The port is updated. pkg.FreeBSD.org packages are now published with fixed shared libraries. It was found that 'pkg update -f' may be required as well. Here are the updated instructions: - Binary package users should run 'pkg update -f' and 'pkg check -Ba' after upgrading to pkg-1.3.7 and before updating any other packages. This avoids needing to reinstall anything not needed due to changed shared libraries. For binary package users: # pkg install ports-mgmt/pkg # pkg update -f # pkg check -Ba # pkg upgrade For port users: # portsnap fetch update # make -C /usr/ports/ports-mgmt/pkg build deinstall install clean # pkg check -Ba - People building packages for serving to other systems need to rebuild all packages with 1.3.7. The previous announcement explaining this in more detail is at http://lists.freebsd.org/pipermail/freebsd-ports-announce/2014-August/86.html -- Regards, Bryan Drewery GoPai.com | Facebook.com/PaymentAlliance CONFIDENTIALITY NOTE: This message is intended only for the use of the individual or entity to whom it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, please notify us by telephone at (502) 212-4001 or notify us at PAI , Dept. 99, 6060 Dutchmans Lane, Suite 320, Louisville, KY 40205 ___ 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"
"poudriere bulk" - why does it fail on single package with missing port origin?
Why does "poudriere bulk" need to bail because of a single package that has a missing port origin and not build other packages in the package list? If I remove x11/mate from my package list poudriere rocks on building all my other ports. The missing origin is a RUN_DEPENDS in the x11/mate Makefile, but that dependency should only be for x11/mate right? I can't seem to find a good explanation in the general man pages or searching the web. Educate me please ;-) --mikej Example: poudriere 3.0.17/11.0-CURRENT #1 r264318M amd64 [root@bsd11 /usr/local/poudriere/ports/default/x11/mate]# poudriere bulk -j 10stable -f /usr/local/etc/charon-list >> Creating the reference jail... done >> Mounting system devices for 10stable-default >> Mounting ports/packages/distfiles >> Mounting ccache from: /var/cache/ccache >> Mounting packages from: /usr/local/poudriere/data/packages/10stable-default >> Logs: /usr/local/poudriere/data/logs/bulk/10stable-default/2014-09-10_12h18m15s >> Appending to make.conf: /usr/local/etc/poudriere.d/10stable-make.conf /etc/resolv.conf -> /usr/local/poudriere/data/build/10stable-default/ref/etc/resolv.conf >> Starting jail 10stable-default >> Loading MOVED >> Calculating ports order and dependencies >> MOVED: databases/db41 renamed to databases/db48 >> MOVED: databases/db42 renamed to databases/db48 >> Error: Invalid port origin 'archivers/mate-file-archiver' not found. >> Cleaning up >> Umounting file systems [root@bsd11 /usr/local/poudriere/ports/default/x11/mate]# AFTER remove x11/mate from the list "charon-list" [root@bsd11 /usr/local/poudriere/ports/default/x11/mate]# poudriere bulk -j 10stable -f /usr/local/etc/charon-list >> Creating the reference jail... done >> Mounting system devices for 10stable-default >> Mounting ports/packages/distfiles >> Mounting ccache from: /var/cache/ccache >> Mounting packages from: /usr/local/poudriere/data/packages/10stable-default >> Logs: /usr/local/poudriere/data/logs/bulk/10stable-default/2014-09-10_12h20m14s >> Appending to make.conf: /usr/local/etc/poudriere.d/10stable-make.conf /etc/resolv.conf -> /usr/local/poudriere/data/build/10stable-default/ref/etc/resolv.conf >> Starting jail 10stable-default >> Loading MOVED >> Calculating ports order and dependencies >> MOVED: databases/db41 renamed to databases/db48 >> MOVED: databases/db42 renamed to databases/db48 >> Sanity checking the repository >> Deleting old version: liboil-0.3.17_1.txz >> Deleting old version: p5-DBD-Pg-3.4.0.txz >> Deleting old version: p5-Net-SSLeay-1.65.txz >> Deleting stale symlinks >> Deleting empty directories >> Cleaning the build queue >> Building 490 packages using 8 builders >> Starting/Cloning builders >> Hit CTRL+t at any time to see build progress and stats ___ 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"
SUSCRIBE
___ 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"
"poudriere bulk" - why does it fail on single package with missing port origin?
Why does "poudriere bulk" need to bail because a single package has a missing port origin and not continue to build other packages in the package list? If I remove x11/mate from my package list poudriere rocks on building all my other ports. The missing origin is a RUN_DEPENDS in the x11/mate Makefile, but that dependency should only be for x11/mate right? I can't seem to find a good explanation in the general man pages or searching the web. Educate me please ;-) --mikej Example: poudriere 3.0.17/11.0-CURRENT #1 r264318M amd64 [root@bsd11 /usr/local/poudriere/ports/default/x11/mate]# poudriere bulk -j 10stable -f /usr/local/etc/charon-list >> Creating the reference jail... done >> Mounting system devices for 10stable-default >> Mounting ports/packages/distfiles >> Mounting ccache from: /var/cache/ccache >> Mounting packages from: /usr/local/poudriere/data/packages/10stable-default >> Logs: /usr/local/poudriere/data/logs/bulk/10stable-default/2014-09-10_12h18m15s >> Appending to make.conf: /usr/local/etc/poudriere.d/10stable-make.conf /etc/resolv.conf -> /usr/local/poudriere/data/build/10stable-default/ref/etc/resolv.conf >> Starting jail 10stable-default >> Loading MOVED >> Calculating ports order and dependencies >> MOVED: databases/db41 renamed to databases/db48 >> MOVED: databases/db42 renamed to databases/db48 >> Error: Invalid port origin 'archivers/mate-file-archiver' not found. >> Cleaning up >> Umounting file systems [root@bsd11 /usr/local/poudriere/ports/default/x11/mate]# AFTER remove x11/mate from the list "charon-list" [root@bsd11 /usr/local/poudriere/ports/default/x11/mate]# poudriere bulk -j 10stable -f /usr/local/etc/charon-list >> Creating the reference jail... done >> Mounting system devices for 10stable-default >> Mounting ports/packages/distfiles >> Mounting ccache from: /var/cache/ccache >> Mounting packages from: /usr/local/poudriere/data/packages/10stable-default >> Logs: /usr/local/poudriere/data/logs/bulk/10stable-default/2014-09-10_12h20m14s >> Appending to make.conf: /usr/local/etc/poudriere.d/10stable-make.conf /etc/resolv.conf -> /usr/local/poudriere/data/build/10stable-default/ref/etc/resolv.conf >> Starting jail 10stable-default >> Loading MOVED >> Calculating ports order and dependencies >> MOVED: databases/db41 renamed to databases/db48 >> MOVED: databases/db42 renamed to databases/db48 >> Sanity checking the repository >> Deleting old version: liboil-0.3.17_1.txz >> Deleting old version: p5-DBD-Pg-3.4.0.txz >> Deleting old version: p5-Net-SSLeay-1.65.txz >> Deleting stale symlinks >> Deleting empty directories >> Cleaning the build queue >> Building 490 packages using 8 builders >> Starting/Cloning builders >> Hit CTRL+t at any time to see build progress and stats ___ 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 bulk" - why does it fail on single package with missing port origin?
On 2014-09-12 17:46, Bryan Drewery wrote: On 9/11/2014 8:51 AM, Michael Jung wrote: Why does "poudriere bulk" need to bail because a single package has a missing port origin and not continue to build other packages in the package list? If I remove x11/mate from my package list poudriere rocks on building all my other ports. The missing origin is a RUN_DEPENDS in the x11/mate Makefile, but that dependency should only be for x11/mate right? I can't seem to find a good explanation in the general man pages or searching the web. Educate me please ;-) A lot of the reason is just the way poudriere handles looking up dependencies. I'm willing to explore moving this fatal error such that the port is just listed as FAILED and anything depending on it is SKIPPED. There's currently no way to do that without more logic. This sort of error hits the package build system quite often. When someone breaks INDEX they also break package building because of this error. I am more and more convinced that we should not consider these immediately fatal. However, we should also consider a threshold feature such that too many failures for bulk will cause the set to not be published. 3.1 adds a feature called "atomic package repository" that builds packages outside of the normal repository dir. Once the build is done the packages are synced over. I added a way to prevent publishing the set if ANYTHING fails, but it's not using a threshold yet. I'll improve that. This will have to wait until after 3.1 though. It will be releasing once I find time to focus on getting it out. --mikej Example: poudriere 3.0.17/11.0-CURRENT #1 r264318M amd64 [root@bsd11 /usr/local/poudriere/ports/default/x11/mate]# poudriere bulk -j 10stable -f /usr/local/etc/charon-list >> Creating the reference jail... done >> Mounting system devices for 10stable-default >> Mounting ports/packages/distfiles >> Mounting ccache from: /var/cache/ccache >> Mounting packages from: /usr/local/poudriere/data/packages/10stable-default >> Logs: /usr/local/poudriere/data/logs/bulk/10stable-default/2014-09-10_12h18m15s >> Appending to make.conf: /usr/local/etc/poudriere.d/10stable-make.conf /etc/resolv.conf -> /usr/local/poudriere/data/build/10stable-default/ref/etc/resolv.conf >> Starting jail 10stable-default >> Loading MOVED >> Calculating ports order and dependencies >> MOVED: databases/db41 renamed to databases/db48 >> MOVED: databases/db42 renamed to databases/db48 >> Error: Invalid port origin 'archivers/mate-file-archiver' not found. >> Cleaning up >> Umounting file systems [root@bsd11 /usr/local/poudriere/ports/default/x11/mate]# AFTER remove x11/mate from the list "charon-list" [root@bsd11 /usr/local/poudriere/ports/default/x11/mate]# poudriere bulk -j 10stable -f /usr/local/etc/charon-list >> Creating the reference jail... done >> Mounting system devices for 10stable-default >> Mounting ports/packages/distfiles >> Mounting ccache from: /var/cache/ccache >> Mounting packages from: /usr/local/poudriere/data/packages/10stable-default >> Logs: /usr/local/poudriere/data/logs/bulk/10stable-default/2014-09-10_12h20m14s >> Appending to make.conf: /usr/local/etc/poudriere.d/10stable-make.conf /etc/resolv.conf -> /usr/local/poudriere/data/build/10stable-default/ref/etc/resolv.conf >> Starting jail 10stable-default >> Loading MOVED >> Calculating ports order and dependencies >> MOVED: databases/db41 renamed to databases/db48 >> MOVED: databases/db42 renamed to databases/db48 >> Sanity checking the repository >> Deleting old version: liboil-0.3.17_1.txz >> Deleting old version: p5-DBD-Pg-3.4.0.txz >> Deleting old version: p5-Net-SSLeay-1.65.txz >> Deleting stale symlinks >> Deleting empty directories >> Cleaning the build queue >> Building 490 packages using 8 builders >> Starting/Cloning builders >> Hit CTRL+t at any time to see build progress and stats ___ 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" Thank you for the answer. And as a user since 2.x kudo's to you, Brian and all the others working on PKG and poudriere - they have made port management and deployment nearly a non-event and I applaud everyone's effort. --mikej ___ 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
On 2014-08-20 12: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.
This repository is available for:
head
10.0
9.1,9.2,9.3
It is not available for 8.4. If someone is willing to test on 8.4 I
will
build a repository for it.
Place this in /usr/local/etc/pkgs/repos/FreeBSD_ssp.conf:
FreeBSD: { enabled: no }
FreeBSD_ssp: {
url: "pkg+http://pkg.FreeBSD.org/${ABI}/ssp";,
mirror_type: "srv",
signature_type: "fingerprints",
fingerprints: "/usr/share/keys/pkg",
enabled: yes
}
Once that is done you should force reinstall packages from this
repository:
pkg update
pkg upgrade -f
Thanks for your help!
Bryan Drewery
On behalf of portmgr.
I have been building (poudriere) and running some 1100+ ports
WITH_SSP_PORT=yes under 10-STABLE and CURRENT without issue. This is
using both our local repository and the ssp repository listed above.
--mikej
___
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: Removal of legacy X.Org (aka non-WITH_NEW_XORG)
I hope this may be an additional data point. I also had grave issues with NEW_XORG. When I did experience a problem 99% of the time the computer locked up. My uptime was never more than a 24 hour period. No crash dumps, black screen, no keyboard light activity in toggling caps lock. However, on occasion Xorg would loop as reported in http://lists.freebsd.org/pipermail/freebsd-current/2014-June/050690.html I finally noticed that Xorg was complaining about xfdevhw not being available and so I installed the port. Since then zero lockups. I left the machine run with no additional update or changes for over one week without issue, and have since that time been updating Xorg and drivers without issue short of having to always re-install xf86-input-keyboard (and in past both xf86-input-keyboard and xf86-input-mouse). My current Xorg.log reports [ 486.836] (II) Loading sub module "fbdevhw" [ 486.836] (II) LoadModule: "fbdevhw" [ 486.836] (II) Loading /usr/local/lib/xorg/modules/libfbdevhw.so [ 486.836] (EE) LoadModule: Module fbdevhw does not have a fbdevhwModuleData data object. [ 486.836] (II) UnloadModule: "fbdevhw" [ 486.836] (II) Unloading fbdevhw [ 486.836] (EE) Failed to load module "fbdevhw" (invalid module, 0) [ 486.836] (WW) Falling back to old probe method for fbdev so why this apparently made a difference I do not understand. I am by no means an expert and this may not be relevant at all but this seems to be the right audience. This was my course of events and X11 still is working great for me. I can supply any additional information if requested, I am on X.Org X Server 1.12.4 / 10.1-BETA1 --mikej -Original Message- From: owner-freebsd-sta...@freebsd.org [mailto:owner-freebsd-sta...@freebsd.org] On Behalf Of Marat N.Afanasyev Sent: Friday, October 03, 2014 11:45 AM To: Jean-Sébastien Pédron; Claude Buisson; Baptiste Daroussin; po...@freebsd.org; sta...@freebsd.org; freebsd-...@freebsd.org Subject: Re: Removal of legacy X.Org (aka non-WITH_NEW_XORG) Jean-Sébastien Pédron wrote: > On 03.10.2014 11:01, Claude Buisson wrote: >> NVIDIA does not exist in your world ? > > Hi! > > You're right, we forgot to mention NVIDIA. > > The NVIDIA port installs its own bits from the kernel module to the > specific libGL.so. The notion of "UMS/KMS" doesn't exist and the port is > made to work with all versions of FreeBSD and X.Org server. Therefore, > NVIDIA users are not impacted by this change at all. > I think that old X stack should not be dropped until at least, GPU locking problem is resolved, what we can say about Xorg stability under FreeBSD if one should reset one's desktop every week or so with lots of lost files? I cannot really use KMS drivers at all because of this problem. I've lost enough data while trying to test radeon kms, and I cannot switch from old xorg to new one. Is it possible to build new xorg without kms and with old radeon driver? -- SY, Marat GoPai.com | Facebook.com/PaymentAlliance CONFIDENTIALITY NOTE: This message is intended only for the use of the individual or entity to whom it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, please notify us by telephone at (502) 212-4001 or notify us at PAI , Dept. 99, 6060 Dutchmans Lane, Suite 320, Louisville, KY 40205 ___ 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 1.4.0.alpha3 - pkg: pkg_repo_fetch_remote_mmap(cannot mmap fetched): Invalid argument / Assertion failed: (curvar != NULL), function pkg_solve_add_request_rule, file pkg_solve.c, line 537.
Hello:
Errors shown toward end of email.
Note this is a cleanly installed jail but an previously built repository
from an older
version of head. I can nuke the head repository and rebuild from
scratch but I wanted to
present these errors first.
--mikej
FreeBSD bsd11 11.0-CURRENT FreeBSD 11.0-CURRENT #4 r273857: Thu Oct 30
08:50:37 EDT 2014
mikej@bsd11:/usr/obj/usr/src/sys/GENERIC amd64
JAILNAME VERSION ARCH METHOD TIMESTAMP PATH
10stable 10.1-PRERELEASE r273580 amd64 svn2014-10-24 11:10:51
/usr/local/poudriere/jails/10stable
head 11.0-CURRENT r273858amd64 svn2014-10-30 10:45:31
/usr/local/poudriere/jails/head
9stable 9.2-STABLE amd64 svn
/usr/local/poudriere/jails/9stable
9stable32 9.2-STABLE i386 ftp
/usr/local/poudriere/jails/9stable32
root@bsd11:~ # pkg -vv
Version : 1.4.0.alpha3
PKG_DBDIR = "/var/db/pkg";
PKG_CACHEDIR = "/var/cache/pkg";
PORTSDIR = "/usr/ports";
INDEXDIR = "";
INDEXFILE = "INDEX-11";
HANDLE_RC_SCRIPTS = false;
ASSUME_ALWAYS_YES = false;
REPOS_DIR [
"/etc/pkg/",
"/usr/local/etc/pkg/repos/",
]
PLIST_KEYWORDS_DIR = "";
SYSLOG = true;
ABI = "FreeBSD:11:amd64";
ALTABI = "freebsd:11:x86:64";
DEVELOPER_MODE = false;
VULNXML_SITE = "http://vuxml.freebsd.org/freebsd/vuln.xml.bz2";;
FETCH_RETRY = 3;
PKG_PLUGINS_DIR = "/usr/local/lib/pkg/";
PKG_ENABLE_PLUGINS = true;
PLUGINS [
]
DEBUG_SCRIPTS = false;
PLUGINS_CONF_DIR = "/usr/local/etc/pkg/";
PERMISSIVE = false;
REPO_AUTOUPDATE = true;
NAMESERVER = "";
EVENT_PIPE = "";
FETCH_TIMEOUT = 30;
UNSET_TIMESTAMP = false;
SSH_RESTRICT_DIR = "";
PKG_ENV {
}
PKG_SSH_ARGS = "";
DEBUG_LEVEL = 0;
ALIAS {
}
CUDF_SOLVER = "";
SAT_SOLVER = "";
RUN_SCRIPTS = true;
CASE_SENSITIVE_MATCH = false;
LOCK_WAIT = 1;
LOCK_RETRIES = 5;
SQLITE_PROFILE = false;
WORKERS_COUNT = 0;
READ_LOCK = false;
PLIST_ACCEPT_DIRECTORIES = false;
IP_VERSION = 0;
AUTOMERGE = true;
Repositories:
myrepo: {
url :
"File:///usr/local/poudriere/data/packages/head-default",
enabled : yes
}
FreeBSD_ssp: {
url : "pkg+http://pkg.FreeBSD.org/FreeBSD:11:amd64/ssp";,
enabled : yes,
mirror_type : "SRV",
signature_type : "FINGERPRINTS",
fingerprints: "/usr/share/keys/pkg"
}
root@bsd11:~ #
And here execution from the console:
root@bsd11:/usr/local/poudriere/data/packages # rm -r head-default/
root@bsd11:/usr/local/poudriere/data/packages # cd
root@bsd11:~ # poudriere bulk -j head archivers/arc
[00:00:00] >> Creating the reference jail... done
[00:00:00] >> Mounting system devices for head-default
[00:00:00] >> Mounting ports/packages/distfiles
[00:00:00] >> Converting package repository to new format
[00:00:00] >> Stashing existing package repository
[00:00:00] >> Mounting ccache from: /var/cache/ccache
[00:00:00] >> Mounting packages from:
/usr/local/poudriere/data/packages/head-default
[00:00:00] >> Mounting /var/db/ports from:
/usr/local/etc/poudriere.d/options
[00:00:00] >> Appending to make.conf:
/usr/local/etc/poudriere.d/head-make.conf
/etc/resolv.conf ->
/usr/local/poudriere/data/.m/head-default/ref/etc/resolv.conf
[00:00:00] >> Starting jail head-default
[00:00:01] >> Logs:
/usr/local/poudriere/data/logs/bulk/head-default/2014-10-30_11h12m11s
[00:00:01] >> Loading MOVED
[00:00:01] >> Calculating ports order and dependencies
[00:00:01] >> pkg package missing, skipping sanity
[00:00:01] >> Skipping incremental rebuild and repository sanity
checks
[00:00:01] >> Cleaning the build queue
[00:00:01] >> Recording filesystem state for prepkg... done
[00:00:03] >> Building 3 packages using 3 builders
[00:00:03] >> Starting/Cloning builders
[00:00:03] >> Hit CTRL+t at any time to see build progress and stats
[00:00:03] >> [01][00:00:00] Starting build of ports-mgmt/pkg
[00:01:10] >> [01][00:01:07] Finished build of ports-mgmt/pkg:
Success
[00:01:11] >> [01][00:00:00] Starting build of devel/ccache
[00:01:19] >> [01][00:00:08] Finished build of devel/ccache: Success
[00:01:20] >> [01][00:00:00] Starting build of archivers/arc
[00:01:25] >> [01][00:00:05] Finished build of archivers/arc:
Success
[00:01:26] >> Stopping 3 builders
[00:01:27] >> Creating pkgng repository
Creating repository in /tmp/packages: 100%
Packing files for repository: 100%
[00:01:29] >> Committing packages to repository
[00:01:29] >> Removing old packages
[00:01:29] >> Built ports: ports-mgmt/pkg devel/ccache archivers/arc
[head-default] [2014-10-30_11h12m11s] [committing:] Queued: 3 Built: 3
Failed: 0 Skipped: 0 Ignored: 0 Tobuild: 0 Time: 00:01:28
[00:01:29] >> Logs:
/usr/local/poudriere/data/logs/bulk/head-default/2014-10-30_11h12m11s
[00:01:29] >> Cleaning up
[00:01:29] >> Umounting file systems
root@bsd11:~ #
root@bsd11:~ # p
Re: pkg 1.4.0.alpha3 - pkg: pkg_repo_fetch_remote_mmap(cannot mmap fetched): Invalid argument / Assertion failed: (curvar != NULL), function pkg_solve_add_request_rule, file pkg_solve.c, line 537.
On 2014-10-30 13:10, Baptiste Daroussin wrote: On Thu, Oct 30, 2014 at 12:53:29PM -0400, Michael Jung wrote: Hello: Errors shown toward end of email. Note this is a cleanly installed jail but an previously built repository from an older version of head. I can nuke the head repository and rebuild from scratch but I wanted to present these errors first. Can you try alpha4 before nuking the head repository? regards, Bapt Ok, I built archivers/zoo, pkg update and pkg install. Looks ok know. I'll let it build my pkg list for head/10/9 with a few new packages and report back it I see any problems. --mikej root@bsd11:/usr/ports/ports-mgmt/pkg-devel # make reinstall root@bsd11:~ # pkg -v 1.4.0.alpha4 root@bsd11:~ # root@bsd11:~ # poudriere bulk -j head archivers/zoo [00:00:00] >> Creating the reference jail... done [00:00:00] >> Mounting system devices for head-default [00:00:00] >> Mounting ports/packages/distfiles [00:00:00] >> Stashing existing package repository [00:00:00] >> Mounting ccache from: /var/cache/ccache [00:00:00] >> Mounting packages from: /usr/local/poudriere/data/packages/head-default [00:00:00] >> Mounting /var/db/ports from: /usr/local/etc/poudriere.d/options [00:00:00] >> Appending to make.conf: /usr/local/etc/poudriere.d/head-make.conf /etc/resolv.conf -> /usr/local/poudriere/data/.m/head-default/ref/etc/resolv.conf [00:00:00] >> Starting jail head-default [00:00:00] >> Logs: /usr/local/poudriere/data/logs/bulk/head-default/2014-10-30_14h33m25s [00:00:00] >> Loading MOVED [00:00:01] >> Calculating ports order and dependencies [00:00:01] >> Sanity checking the repository [00:00:01] >> Checking packages for incremental rebuild needed [00:00:02] >> Deleting stale symlinks [00:00:02] >> Deleting empty directories [00:00:02] >> Cleaning the build queue [00:00:02] >> Recording filesystem state for prepkg... done [00:00:03] >> Building 1 packages using 1 builders [00:00:03] >> Starting/Cloning builders [00:00:03] >> Hit CTRL+t at any time to see build progress and stats [00:00:03] >> [01][00:00:00] Starting build of archivers/zoo [00:00:17] >> [01][00:00:14] Finished build of archivers/zoo: Success [00:00:18] >> Stopping 1 builders [00:00:18] >> Creating pkgng repository Creating repository in /tmp/packages: 100% Packing files for repository: 100% [00:00:19] >> Committing packages to repository [00:00:19] >> Removing old packages [00:00:19] >> Built ports: archivers/zoo [head-default] [2014-10-30_14h33m25s] [committing:] Queued: 1 Built: 1 Failed: 0 Skipped: 0 Ignored: 0 Tobuild: 0 Time: 00:00:20 [00:00:20] >> Logs: /usr/local/poudriere/data/logs/bulk/head-default/2014-10-30_14h33m25s [00:00:20] >> Cleaning up [00:00:20] >> Umounting file systems root@bsd11:~ # root@bsd11:~ # pkg update Updating myrepo repository catalogue... Fetching meta.txz: 100% 264 B 0.3k/s00:01 Fetching packagesite.txz: 100%2 KB 1.6k/s00:01 Processing entries: 100% myrepo repository update completed. 4 packages processed Updating FreeBSD_ssp repository catalogue... FreeBSD_ssp repository is up-to-date. root@bsd11:~ # pkg install zoo Updating myrepo repository catalogue... myrepo repository is up-to-date. Updating FreeBSD_ssp repository catalogue... FreeBSD_ssp repository is up-to-date. All repositories are up-to-date. Updating database digests format: 100% The following 1 packages will be affected (of 0 checked): New packages to be INSTALLED: zoo: 2.10.1_3 [myrepo] The process will require 112 KB more space. 56 KB to be downloaded. Proceed with this action? [y/N]: y Checking integrity... done (0 conflicting) [1/1] Installing zoo-2.10.1_3... [1/1] Extracting zoo-2.10.1_3: 100% root@bsd11:~ # ___ 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: graphics/png fail
On 2014-10-31 15:33, Beeblebrox wrote: graphics/png has been failing like this for some time, and I would go around the problem by fetching the newer binary then re-starting poudriere. That trick did not work this time, so now I'm stuck. Same error when building on host (non-poudriere). Port used to compile on host, but no longer. Host & poudriere make.conf are identical. Running tests... /usr/local/bin/ctest --force-new-ctest-process Test project /wrkdirs/usr/ports/graphics/png/work/libpng-1.5.19 Start 1: pngtest 1/2 Test #1: pngtest .. Passed0.01 sec Start 2: pngvalid 2/2 Test #2: pngvalid .***Failed5.88 sec 50% tests passed, 1 tests failed out of 2 Total Test time (real) = 5.89 sec The following tests FAILED: 2 - pngvalid (Failed) Errors while running CTest - FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS -- View this message in context: http://freebsd.1045724.n5.nabble.com/graphics-png-fail-tp5961223.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" While this does not directly help you, it passes the test for me on 11.0-CURRENT #4 r273857: PORTNAME= png PORTVERSION=1.5.19 Running tests... Test project /usr/ports/graphics/png/work/libpng-1.5.19 Start 1: pngtest 1/2 Test #1: pngtest .. Passed0.03 sec Start 2: pngvalid 2/2 Test #2: pngvalid . Passed 31.60 sec 100% tests passed, 0 tests failed out of 2 Total Test time (real) = 31.74 sec ===> Staging for png-1.5.19 /bin/mkdir -p /usr/ports/graphics/png/work/stage/usr/local/include/libpng /bin/mkdir -p /usr/ports/graphics/png/work/stage/usr/local/libdata/pkgconfig ===> Generating temporary packing list ___ 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 upgrade candidates not correct
I noted that when running 'pkg upgrade' only 50 candidates where detected when I have 1158 ports installed. What am I missing? My local repository 0local is built using poudriere 3.1-RC3 [root@charon ~]# pkg -v 1.4.0.rc3 [root@charon ~]# pkg update -f Updating 0local repository catalogue... Fetching meta.txz: 100% 260 B 0.3k/s00:01 Fetching packagesite.txz: 100% 351 KB 359.8k/s00:01 Processing entries: 100% 0local repository update completed. 1488 packages processed Updating FreeBSD repository catalogue... Fetching meta.txz: 100% 944 B 0.9k/s00:01 Fetching packagesite.txz: 100%5 MB 296.4k/s00:18 Processing entries: 100% FreeBSD repository update completed. 23741 packages processed [root@charon ~]# pkg info | wc -l 1158 [root@charon ~]# pkg check -Ba Checking all packages: 100% [root@charon ~]# uname -a FreeBSD charon 10.1-RC1 FreeBSD 10.1-RC1 #1 r272610M: Mon Oct 6 09:52:58 EDT 2014 mikej@charon:/usr/obj/usr/src/sys/GENERIC amd64 [root@charon ~]# pkg upgrade Updating 0local repository catalogue... 0local repository is up-to-date. Updating FreeBSD repository catalogue... FreeBSD repository is up-to-date. All repositories are up-to-date. Checking for upgrades (50 candidates): 100% Processing candidates (50 candidates): 100% Checking integrity... done (0 conflicting) The following 5 packages will be affected (of 0 checked): Installed packages to be REINSTALLED: sqlite3-3.8.7.2 [0local] (options changed) libwpg03-0.3.0 [0local] (direct dependency changed) libsoup-gnome-2.48.0_1 [FreeBSD] (needed shared library changed) libdrm-2.4.58_1,1 [0local] (options changed) guile-1.8.8_2 [FreeBSD] (direct dependency changed) The process will require 79 KB more space. Proceed with this action? [y/N]: --mikej ___ 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"
nvida Go 7300 working - WAS: Removal of XAA acceleration in X.org, and older NVIDIA GeForce
On 2014-12-23 10:20, Mark Martinec wrote: Tijl Coosemans wrote: This card is still supported by x11/nvidia-driver-304 Mark Martinec wrote: Good suggestion! It does seem to draw screen and scroll much faster than NV (although it seems to stall from time to time (like unresponsive mouse) on a busy host). Will need to test more thoroughly tomorrow when poudriere builds will be over. Thanks! Actually it did not turn out well. Although nvidia-driver-304 with a GeForce 7300 GT does not suffer from slow scrolls and slow rendering of web pages, it frequently stalls (like every minute) and nothing happens for a dozen of seconds: mouse cannot move a cursor, a cursor may even temporarily disappear, typing on an xterm or konsole window is unresponsive. It appears as if a host is terribly busy, even though it is not (the yesterday's poudriere build was over, and I even rebooted the host, with nvidia driver loaded by a boot loader this time). After a dozen of seconds or so, things get back at being responsive again, until the next lockup. Occasionally a window may become scrambled, but rectifies itself after a while. After trying to work in this situation for a while, eventually screen turned black, with a host totally locked up - not even responding to ssh or ping or ctrl alt F1, or a soft ACPI power off button, so had to be forcibly rebooted. So in the end I had to revert back to the NV driver, which is now slow, but at least is stable and consistent. I guess we need to start looking for a new graphics board, quite unfortunate. Mark FWIW on i386 current r275874 I do no have these lockup issues with nvidia GeForce Go 7300 I did find that though loading the nvidia kernel module in /boot/loader.conf was not enough, I had to create a small xorg.conf simply containing Section "Device" Identifier "Device0" Driver "nvidia" VendorName "NVIDIA Corporation" EndSection or GLX instead of NV-GLX would try to be loaded grep GLX Xorg.0.log-without-xorg.conf [ 21401.540] (II) NVIDIA GLX Module 304.125 Mon Dec 1 20:18:39 PST 2014 [ 21401.540] Loading extension GLX [ 21401.782] (EE) Failed to initialize GLX extension (Compatible NVIDIA X driver not found) grep GLX Xorg.0.log-with-xorg.conf [ 21298.014] (II) NVIDIA GLX Module 304.125 Mon Dec 1 20:18:39 PST 2014 [ 21298.014] Loading extension GLX [ 21298.839] Loading extension NV-GLX [ 21298.931] (II) Initializing extension GLX http://mail.mikej.com/Xorg.0.log-without-xorg.conf http://mail.mikej.com/Xorg.0.log-with-xorg.conf I also have both devd and hald running. --mikej ___ 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: Failure compiling java/openjdk8
On 2016-04-28 05:30, Willem Offermans wrote: Dear Matthias and FreeBSD friends, On Sun, Apr 24, 2016 at 10:48:16AM +0200, Matthias Andree wrote: Am 23.04.2016 um 12:02 schrieb Willem Offermans: > Dear FreeBSD friends, > > In my attempt to juvenile an old FreeBSD beast, I encountered another > hurdle: a failure compiling java/openjdk8 > > > gmake[4]: Leaving directory '/usr/ports/java/openjdk8/work/openjdk/jdk/make' > gmake[4]: Entering directory '/usr/ports/java/openjdk8/work/openjdk/jdk/make' > Compiling 9455 files for BUILD_JDK > Killed > gmake[4]: *** [/usr/ports/java/openjdk8/work/openjdk/build/bsd-x86-normal-server-release/jdk/classes/_the.BUILD_JDK_batch] Error 137 That Error 137 is "signal 9 (SIGKILL)" and added 128 for "core dump requested". Typically an indication of a last-resort cleanup by the kernel. Has the machine run out of memory during the compile? Can you reduce the number of CPU cores used for the compile, in an attempt to reduce RAM usage? You were right about the memory usage during the compilation. The system is an old one and has only 512 MB RAM and one CPU core. During compilation of openjdk8 it run out of memory. The swap file, which is 512 MB as well, was completely used. Shortly after this state was reached, the above error message appeared, but the system __did not__ freeze. The bad part is that I cannot upgrade the old system totally. The good part is that all other programs could be updated without any problem. Many thnx to the good work of the FreeBSD community. I really appreciate this. I like to test some things on this rejuvenated beast and probably I don't need openjdk8 for that. So I can live with the situation. I only announced it, so that other people do not run into the same situation. But who is running a FreeBSD system with 512 MB RAM nowadays anyway? -- Met vriendelijke groeten, With kind regards, Mit freundlichen Gruessen, De jrus wah, Will * W.K. Offermans Powered by (__) \\\'',) \/ \ ^ .\._/_) www.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" If you really want to try and build it on that system and have some free disk space you could always add a file instead of a partition as extra swap. Instuctions here: https://www.freebsd.org/doc/handbook/adding-swap-space.html --mikej ___ 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"
