New: devel/p5-App-cpanminus
Hi, Attached is my first OpenBSD port, cpanminus. "cpanminus" is a tool which simplifies the installation of Perl module from CPAN. I've tested it on amd64 which is my workstation that this port is created from. Comments and testing are much welcome. Regards, Edward. p5-App-cpanminus.tar.gz Description: application/tar-gz
Re: Unmarked conflict checking in portcheck
On 2014/07/24 03:36, Vadim Zhukov wrote: > 2014-07-24 3:30 GMT+04:00 Stuart Henderson : > > On 2014/07/24 00:46, Marc Espie wrote: > >> Nope, this exists elsewhere. Reuse bin/check-conflicts > > > > This is different, unlke check-conflicts it doesn't need a full set > > of built packages, it just uses pkglocatedb instead. > > check-conflicts uses print-plist-all target, which results in much > faster. hmmm, that possibility isn't apparent from the description, "check-conflicts is used to check a collection of packages for unregistered conflicts"..
Re: Unmarked conflict checking in portcheck
2014-07-24 3:30 GMT+04:00 Stuart Henderson : > On 2014/07/24 00:46, Marc Espie wrote: >> Nope, this exists elsewhere. Reuse bin/check-conflicts > > This is different, unlke check-conflicts it doesn't need a full set > of built packages, it just uses pkglocatedb instead. check-conflicts uses print-plist-all target, which results in much faster. Now I need to compare actual results, to make sure check-conflicts won't miss anything. Also, check-conflicts gives me weird errors about /usr/ports/openbsd-wip/* directories, even that it isn't listed in /usr/ports/Makefile - to be investigated... -- WBR, Vadim Zhukov
Re: Unmarked conflict checking in portcheck
On 2014/07/24 00:46, Marc Espie wrote: > Nope, this exists elsewhere. Reuse bin/check-conflicts This is different, unlke check-conflicts it doesn't need a full set of built packages, it just uses pkglocatedb instead.
New final gitversion.h-related patch for digikam-kde4
This ought to be a real fix; the problem is that both "core" Digikam app
and KIPI plugins do generate gitversion.h, using different targets. And,
of course, I've used the wrong one... Realized that when the build
finally borked on my i386. Now builds fine.
Okay? This is totally independant of OpenCV patches.
--
WBR,
Vadim Zhukov
Index: patches/patch-extra_kipi-plugins_common_libkipiplugins_CMakeLists_txt
===
RCS file:
/cvs/ports/graphics/digikam-kde4/patches/patch-extra_kipi-plugins_common_libkipiplugins_CMakeLists_txt,v
retrieving revision 1.2
diff -u -p -r1.2 patch-extra_kipi-plugins_common_libkipiplugins_CMakeLists_txt
--- patches/patch-extra_kipi-plugins_common_libkipiplugins_CMakeLists_txt
23 Jul 2014 10:17:40 - 1.2
+++ patches/patch-extra_kipi-plugins_common_libkipiplugins_CMakeLists_txt
23 Jul 2014 23:16:53 -
@@ -1,14 +1,14 @@
$OpenBSD: patch-extra_kipi-plugins_common_libkipiplugins_CMakeLists_txt,v 1.2
2014/07/23 10:17:40 zhuk Exp $
Missing dependency, fails in parallel build.
--- extra/kipi-plugins/common/libkipiplugins/CMakeLists.txt.orig Thu Jun
26 03:56:54 2014
-+++ extra/kipi-plugins/common/libkipiplugins/CMakeLists.txtWed Jul 23
13:56:07 2014
extra/kipi-plugins/common/libkipiplugins/CMakeLists.txtThu Jul 24
02:59:11 2014
@@ -45,6 +45,11 @@ TARGET_LINK_LIBRARIES(kipiplugins
${KIPI_LIBRARIES}
)
+SET_SOURCE_FILES_PROPERTIES(${CMAKE_CURRENT_SOURCE_DIR}/tools/kpversion.cpp
+ PROPERTIES
-+ OBJECT_DEPENDS digikam-gitversion
++ OBJECT_DEPENDS kipiplugins-gitversion
+ )
+
SET_TARGET_PROPERTIES(kipiplugins PROPERTIES VERSION
${KIPIPLUGINS_LIB_SO_VERSION_STRING} SOVERSION
${KIPIPLUGINS_LIB_SO_VERSION_STRING})
Re: Unmarked conflict checking in portcheck
2014-07-24 2:46 GMT+04:00 Marc Espie : > On Thu, Jul 24, 2014 at 02:38:34AM +0400, Vadim Zhukov wrote: >> 2014-07-24 0:18 GMT+04:00 Vadim Zhukov : >> > Hello all. >> > >> > This adds a useful but awfully slow feature: checking for unmarked >> > conflicts. This is done as a part of PLIST checks, so it could be >> > disabled by -P as well as by specifically added -C option. Yes, >> > there was -C option at some time previously with different meaning, >> > but I'm doubt we care about those times. :) >> > >> > The basic idea is that we accumulate up to $max_conflicts_queue_size, >> > 1000 by now, file items and then run pkg_locate in a batch. We parse >> > pkg_locate output, filter out implicit and explicit conflicts, and >> > finally display warnings about each conflicting file. >> > >> > Actual speed is about 5 PLIST items per second on my X201i. Yes, >> > it makes checking stuff like kdelibs and opencv-docs hell long. >> > Unfortunately, locate(1) (and thus pkg_locate) re-scans database >> > for each item on command line. This could be improved (I've already >> > looked at the code) but definitely not while we're in release lock. >> > >> > So... any opinions? Okay to let this go in? >> > >> > BTW, this diff contains a bugfix required for the mentioned feature >> > to work: I've used non-subpackaged version of FULLPKGNAME variable. >> > I plan to commit this fix and other nit I found separately. >> >> Updated version (should apply clean to -CURRENT). Includes updates >> to tests. >> >> -- >> WBR, >> Vadim Zhukov > > Nope, this exists elsewhere. Reuse bin/check-conflicts Hm-m-m... I ever used this tool some time ago. :-\ Now I'll need to rediscover right options - the manual page describes what this tool does but not how to use it for different cases. :-( Anyway, thanks, this should simplify and speed up things a lot. :) -- WBR, Vadim Zhukov
Re: Unmarked conflict checking in portcheck
On Thu, Jul 24, 2014 at 02:38:34AM +0400, Vadim Zhukov wrote: > 2014-07-24 0:18 GMT+04:00 Vadim Zhukov : > > Hello all. > > > > This adds a useful but awfully slow feature: checking for unmarked > > conflicts. This is done as a part of PLIST checks, so it could be > > disabled by -P as well as by specifically added -C option. Yes, > > there was -C option at some time previously with different meaning, > > but I'm doubt we care about those times. :) > > > > The basic idea is that we accumulate up to $max_conflicts_queue_size, > > 1000 by now, file items and then run pkg_locate in a batch. We parse > > pkg_locate output, filter out implicit and explicit conflicts, and > > finally display warnings about each conflicting file. > > > > Actual speed is about 5 PLIST items per second on my X201i. Yes, > > it makes checking stuff like kdelibs and opencv-docs hell long. > > Unfortunately, locate(1) (and thus pkg_locate) re-scans database > > for each item on command line. This could be improved (I've already > > looked at the code) but definitely not while we're in release lock. > > > > So... any opinions? Okay to let this go in? > > > > BTW, this diff contains a bugfix required for the mentioned feature > > to work: I've used non-subpackaged version of FULLPKGNAME variable. > > I plan to commit this fix and other nit I found separately. > > Updated version (should apply clean to -CURRENT). Includes updates > to tests. > > -- > WBR, > Vadim Zhukov Nope, this exists elsewhere. Reuse bin/check-conflicts
Re: Three packages in one build (to say nothing of the OS)
On 2014/07/24 00:26, Vadim Zhukov wrote: > Here is an updated version, after input from Gilles Caulier. This > is almost the same to what was committed in Digikam SC repos. > > Tested on i386. Okay? Looks sane, though I don't know this software at all..
Re: Three packages in one build (to say nothing of the OS)
Here is an updated version, after input from Gilles Caulier. This
is almost the same to what was committed in Digikam SC repos.
Tested on i386. Okay?
--
WBR,
Vadim Zhukov
Index: Makefile
===
RCS file: /cvs/ports/graphics/digikam-kde4/Makefile,v
retrieving revision 1.4
diff -u -p -r1.4 Makefile
--- Makefile18 Jul 2014 04:40:58 - 1.4
+++ Makefile23 Jul 2014 20:22:13 -
@@ -22,7 +22,9 @@ PKGNAME-main =${PKGNAME}
PKGNAME-mediawiki =libmediawiki-1.0.0
PKGNAME-vkontakte =libkvkontakte-1.0.0
-REVISION-main =0
+REVISION-main =1
+REVISION-kipi =0
+REVISION-face =0
EXTRACT_SUFX = .tar.bz2
@@ -76,9 +78,7 @@ WANTLIB-kipi += ${KDE4LIB}/kio ${KDE4LIB
WANTLIB-kipi += ${KDE4LIB}/ksane
WANTLIB-kipi += ${KDE4LIB}/nepomuk ${KDE4LIB}/nepomukutils ${KDE4LIB}/solid
WANTLIB-kipi += ${KDE4LIB}/threadweaver
-WANTLIB-kipi += opencv_core opencv_highgui opencv_legacy
-WANTLIB-kipi += opencv_calib3d opencv_features2d opencv_flann
-WANTLIB-kipi += opencv_imgproc opencv_ml opencv_video
+WANTLIB-kipi += opencv_core opencv_highgui opencv_imgproc opencv_objdetect
WANTLIB-kipi += exslt gdk_pixbuf-2.0 glib-2.0 gmodule-2.0 gobject-2.0 gpod
WANTLIB-kipi += gthread-2.0 jpeg
WANTLIB-kipi += qjson kgeomap kqoauth kvkontakte mediawiki png qca2 soprano
@@ -223,10 +223,6 @@ TEST_IS_INTERACTIVE = X11
CONFIGURE_ENV =CXXFLAGS="${CXXFLAGS}
-DOPENBSD_LIBKDCRAW_NO_CRASH=0"
.else
CONFIGURE_ENV =CXXFLAGS="${CXXFLAGS}
-DOPENBSD_LIBKDCRAW_NO_CRASH=1"
-.endif
-
-.if ${ARCH} == "amd64"
-BUILD_DEPENDS += graphics/opencv,-java
.endif
post-extract:
Index: patches/patch-core_CMakeLists_txt
===
RCS file: /cvs/ports/graphics/digikam-kde4/patches/patch-core_CMakeLists_txt,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 patch-core_CMakeLists_txt
--- patches/patch-core_CMakeLists_txt 9 Jul 2014 21:29:33 - 1.1.1.1
+++ patches/patch-core_CMakeLists_txt 23 Jul 2014 20:22:13 -
@@ -1,20 +1,22 @@
$OpenBSD: patch-core_CMakeLists_txt,v 1.1.1.1 2014/07/09 21:29:33 zhuk Exp $
-1. Avoid extra library dependencies.
-2. Avoid picking up exceptions from Boost, unbreaking compilation.
core/CMakeLists.txt.orig Thu Jun 26 01:57:33 2014
-+++ core/CMakeLists.txtWed Jul 9 21:04:26 2014
-@@ -175,12 +175,12 @@ FIND_PACKAGE(Boost) # 1.36.0)
+Avoid extra library dependencies.
+REVIEW: https://git.reviewboard.kde.org/r/119201/
+--- core/CMakeLists.txt.orig Thu Jun 26 03:57:33 2014
core/CMakeLists.txtFri Jul 18 22:56:09 2014
+@@ -174,13 +174,14 @@ FIND_PACKAGE(Boost) # 1.36.0)
+ # Therefore, first try finding OpenCV using FIND_PACKAGE(OpenCV), and if that
fails,
# add our FindOpenCV.cmake to the search path and search again.
++SET(OpenCV_LIBS)
MESSAGE(STATUS "First try at finding OpenCV...")
-FIND_PACKAGE(OpenCV)
-+FIND_PACKAGE(OpenCV COMPONENTS core highgui)
++FIND_PACKAGE(OpenCV COMPONENTS core highgui imgproc)
IF (NOT OpenCV_LIBRARIES AND NOT OpenCV_LIBS)
MESSAGE(STATUS "Could not find OpenCV normally, trying internal
FindOpenCV.cmake")
SET(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH}
${CMAKE_CURRENT_SOURCE_DIR}/cmake/modules/modules_opencv)
- FIND_PACKAGE(OpenCV REQUIRED)
-+ FIND_PACKAGE(OpenCV REQUIRED COMPONENTS core highgui)
++ FIND_PACKAGE(OpenCV REQUIRED COMPONENTS core highgui imgproc)
ELSE (NOT OpenCV_LIBRARIES AND NOT OpenCV_LIBS)
MESSAGE(STATUS "Great, found OpenCV on the first try.")
ENDIF (NOT OpenCV_LIBRARIES AND NOT OpenCV_LIBS)
Index: patches/patch-core_tests_imgqsort_detectblur_CMakeLists_txt
===
RCS file: patches/patch-core_tests_imgqsort_detectblur_CMakeLists_txt
diff -N patches/patch-core_tests_imgqsort_detectblur_CMakeLists_txt
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-core_tests_imgqsort_detectblur_CMakeLists_txt 23 Jul 2014
20:22:13 -
@@ -0,0 +1,13 @@
+$OpenBSD$
+Limit to components needed only.
+REVIEW: https://git.reviewboard.kde.org/r/119201/
+--- core/tests/imgqsort/detectblur/CMakeLists.txt.orig Fri Jul 18 20:27:15 2014
core/tests/imgqsort/detectblur/CMakeLists.txt Fri Jul 18 20:27:47 2014
+@@ -1,5 +1,6 @@
+ cmake_minimum_required(VERSION 2.8)
+ project( DisplayImage )
+-find_package( OpenCV REQUIRED )
++set( OpenCV_LIBS )
++find_package( OpenCV REQUIRED COMPONENTS core imgproc )
+ add_executable( detectblur detectblur.cpp )
+ target_link_libraries( detectblur ${OpenCV_LIBS} )
Index: patches/patch-core_tests_imgqsort_detectcompression_CMakeLists_txt
===
RCS file: patches/patch-core_tests_imgqsort_detectcompression_CMakeLists_txt
diff -N patches/patch-core_tests_imgqsort_detectcompression_CMakeLists_txt
--- /dev/null 1
newsbeuter-2.7 crashes in libsqlite3
Hi,
with the snapshot as of 21st July net/newsbeuter from ports crashes with
any feed URL I feed it.
The trace looks like:
--8<---cut here---start->8---
#0 0x0105fd0e in sqlite3VXPrintf (pAccum=0xcfbd6914, bFlags=0, fmt=0x3677538a
"q','%q',%d, '%q')", ap=0xcfbd6a00 ",e//,e//") at
/usr/src/lib/libsqlite3/src/printf.c:670
670 for(i=n=0; k!=0 && (ch=escarg[i])!=0; i++, k--){
(gdb) bt
#0 0x0105fd0e in sqlite3VXPrintf (pAccum=0xcfbd6914, bFlags=0, fmt=0x3677538a
"q','%q',%d, '%q')", ap=0xcfbd6a00 ",e//,e//") at
/usr/src/lib/libsqlite3/src/printf.c:670
#1 0x01060dfd in sqlite3_vmprintf (
zFormat=0x367752e0 "INSERT INTO rss_item
(guid,title,author,url,feedurl,pubDate,content,unread,enclosure_url,enclosure_type,enqueued,
base) VALUES ('%q','%q','%q','%q','%q','%u','%q','%d','%q','%q',%d, '%q')",
ap=0xcfbd69dc "\f¦\222wÌ\207¼\204\f¬X\206LºT\200\214÷rynpÂS") at
/usr/src/lib/libsqlite3/src/printf.c:928
#2 0x16780a28 in newsbeuter::cache::prepare_query (this=0x7b8e1fe0,
format=0x367752e0 "INSERT INTO rss_item
(guid,title,author,url,feedurl,pubDate,content,unread,enclosure_url,enclosure_type,enqueued,
base) VALUES ('%q','%q','%q','%q','%q','%u','%q','%d','%q','%q',%d, '%q')") at
src/cache.cpp:775
#3 0x16783e22 in newsbeuter::cache::update_rssitem_unlocked (this=0x7b8e1fe0,
item=@0xcfbd6bc8, feedurl=@0x82dfa320, reset_unread=false) at src/cache.cpp:649
#4 0x16787651 in newsbeuter::cache::externalize_rssfeed (this=0x7b8e1fe0,
feed=@0xcfbd6c90, reset_unread=false) at src/cache.cpp:388
#5 0x167bed18 in newsbeuter::controller::save_feed (this=0xcfbd7618,
feed=@0xcfbd6db0, pos=0) at src/controller.cpp:1390
#6 0x167c1d08 in newsbeuter::controller::reload (this=0xcfbd7618, pos=0,
max=0, unattended=false, easyhandle=0x0) at src/controller.cpp:712
#7 0x16819c1f in newsbeuter::feedlist_formaction::process_operation
(this=0x77b79c00, op=newsbeuter::OP_RELOAD, automatic=false, args=0x0) at
src/feedlist_formaction.cpp:107
#8 0x16807e54 in newsbeuter::formaction::process_op (this=0x77b79c00,
op=newsbeuter::OP_RELOAD, automatic=false, args=0x0) at src/formaction.cpp:139
#9 0x167b4096 in newsbeuter::view::run (this=0xcfbd7780) at src/view.cpp:239
#10 0x167c5005 in newsbeuter::controller::run (this=0xcfbd7618, argc=1,
argv=0xcfbd7884) at src/controller.cpp:595
#11 0x1677f11e in main (argc=1, argv=0xcfbd7884) at newsbeuter.cpp:30
Current language: auto; currently c
(gdb)
--8<---cut here---end--->8---
OpenBSD 5.6-beta (GENERIC.MP) #262: Mon Jul 21 20:03:20 MDT 2014
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
I don't know whether earlier versions have worked before.
Does anyone else see this too?
Kind regards,
Christian
Unmarked conflict checking in portcheck
Hello all.
This adds a useful but awfully slow feature: checking for unmarked
conflicts. This is done as a part of PLIST checks, so it could be
disabled by -P as well as by specifically added -C option. Yes,
there was -C option at some time previously with different meaning,
but I'm doubt we care about those times. :)
The basic idea is that we accumulate up to $max_conflicts_queue_size,
1000 by now, file items and then run pkg_locate in a batch. We parse
pkg_locate output, filter out implicit and explicit conflicts, and
finally display warnings about each conflicting file.
Actual speed is about 5 PLIST items per second on my X201i. Yes,
it makes checking stuff like kdelibs and opencv-docs hell long.
Unfortunately, locate(1) (and thus pkg_locate) re-scans database
for each item on command line. This could be improved (I've already
looked at the code) but definitely not while we're in release lock.
So... any opinions? Okay to let this go in?
BTW, this diff contains a bugfix required for the mentioned feature
to work: I've used non-subpackaged version of FULLPKGNAME variable.
I plan to commit this fix and other nit I found separately.
--
WBR,
Vadim Zhukov
Index: bin/portcheck
===
RCS file: /cvs/ports/infrastructure/bin/portcheck,v
retrieving revision 1.84
diff -u -p -r1.84 portcheck
--- bin/portcheck 10 Jul 2014 09:57:13 - 1.84
+++ bin/portcheck 23 Jul 2014 20:03:06 -
@@ -20,8 +20,8 @@ set +X
set -u
usage() {
- echo "usage: ${0##*/} [-dNP] [-p portsdir] [-x glob]" >&2
- echo " ${0##*/} -A [-dP] [-p portsdir] [-x glob] [subdir ...]" >&2
+ echo "usage: ${0##*/} [-CdNP] [-p portsdir] [-x glob]" >&2
+ echo " ${0##*/} -A [-CdP] [-p portsdir] [-x glob] [subdir ...]"
>&2
exit 1
}
@@ -33,13 +33,14 @@ usage() {
existing_port=true
ignore_cvs=true
plist_checks=true
+conflict_checks=true
portsdir=
rootrun=false
debugging=false
ignore_list=; unset ignore_list[0]
-while getopts "AdNPp:x:" OPT; do
+while getopts "ACdNPp:x:" OPT; do
case $OPT in
A)
$existing_port || usage
@@ -70,6 +71,10 @@ while getopts "AdNPp:x:" OPT; do
rootrun=true
;;
+ C)
+ conflict_checks=false
+ ;;
+
d)
debugging=true
;;
@@ -82,6 +87,7 @@ while getopts "AdNPp:x:" OPT; do
P)
plist_checks=false
+ conflict_checks=false
;;
p)
@@ -110,6 +116,17 @@ shift $(($OPTIND - 1))
(($# > 0)) && ! $rootrun && usage
(($# == 0)) && set -- .
+if $conflict_checks; then
+ # make sure pkglocatedb is installed
+ # XXX pkg_info doesn't fail if package wasn't found now
+ local pkgldbinst=$(pkg_info -qP pkglocatedb 2>/dev/null || true)
+ if [ -z "$pkgldbinst" ]; then
+ echo "The pkglocatedb package was not found." >&2
+ echo "It is required for checks for unmarked conflicts." >&2
+ exit 4
+ fi
+fi
+
# Detect path to root of directory tree of current port(s) and put it
# in $portsdir, unless it was set by user above. As a last resort, we
@@ -512,7 +529,7 @@ check_port_dir() {
local multi_packages pkgpath_this pseudo_flavor pseudo_flavors
local shared_libs subst_cmd
local perm_pkg_cdrom perm_pkg_ftp perm_dist_ftp
- local show_items="DIST_SUBDIR DISTFILES FLAVOR FLAVORS FULLPKGNAME"
+ local show_items="DIST_SUBDIR DISTFILES FLAVOR FLAVORS"
local show_items="$show_items MASTER_SITES MULTI_PACKAGES PKGPATH"
local show_items="$show_items PSEUDO_FLAVOR PSEUDO_FLAVORS"
local show_items="$show_items SHARED_LIBS SUBST_CMD"
@@ -526,7 +543,6 @@ check_port_dir() {
read -pr distfiles &&
read -pr flavor &&
read -pr flavors &&
- read -pr fullpkgname &&
read -pr master_sites &&
read -pr multi_packages &&
read -pr pkgpath_this &&
@@ -571,7 +587,7 @@ check_port_dir() {
$existing_port || check_shlibs_versions "$dir" $shared_libs
for _s in $multi_packages; do
- sub_checks "$dir" "$_s" "$fullpkgname" "${check_flavors[@]}"
+ sub_checks "$dir" "$_s" "${check_flavors[@]}"
done
pkgpath=${pkgpath:-"$pkgpath_this"}
@@ -660,7 +676,6 @@ sub_checks() {
local dir=$1; shift
local subpkg=$1; shift
- local fullpkgname=$1; shift
local flavor
for flavor in "$@"; do
# avoid extra noise
@@ -674,15 +689,19 @@ sub_checks() {
export SUBPACKAGE="$subpkg" FLAVOR="$flavor"
local wantlib_var=WANTLIB${subpkg%-}
- local vars="COMMENT$subpkg MODULES"
+ local vars="COMMENT$subpkg FULLPKGNAME$subpkg"
+
Re: devel/cppcheck: libexecinfo?
Christian Weisgerber writes: > devel/cppcheck failed to build: > > [...nothing interesting in the log...] > c++ -Ilib -Iexternals/tinyxml -DHAVE_RULES -DTIXML_USE_STL -Ilib > -I/usr/local/include -DCFGDIR=\"/usr/local/share/cppcheck/cfg\" -O2 -pipe > -std=c++0x -c -o cli/cppcheckexecutor.o cli/cppcheckexecutor.cpp > cli/cppcheckexecutor.cpp:37:22: fatal error: execinfo.h: No such file or > directory > #include > ^ > compilation terminated. thanks for the report. it is now fixed. thanks, Gleydson.
Re: devel/mingw build fix (gmkdir)
On Wed, Jul 23, 2014 at 04:29:19PM +0200, Christian Weisgerber wrote:
> Found with dpb -r:
> The configure scripts in devel/mingw pick up gmkdir if installed
> and the build fails if gmkdir then disappears in the background.
>
> Trivial fix. OK?
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/devel/mingw/Makefile,v
> retrieving revision 1.6
> diff -u -p -r1.6 Makefile
> --- Makefile 11 Jan 2014 12:56:41 - 1.6
> +++ Makefile 23 Jul 2014 14:25:00 -
> @@ -64,6 +64,7 @@ do-build:
> env MINGW32_TMP=${MINGW32_TMP} FULLDISTDIR=${FULLDISTDIR} \
> MINGW32_OUT=${MINGW32_OUT} MAKE=${MAKE_PROGRAM} \
> CONFIG_SHELL=${LOCALBASE}/bin/bash \
> + ac_cv_path_mkdir=/bin/mkdir \
> /bin/sh ${WRKBUILD}/${BASENAME}.sh --no-pre-clean --no-post-clean \
> --unattended
> cd ${MINGW32_OUT}/lib/gcc/i386-mingw32/3.4.5/ && \
> --
> Christian "naddy" Weisgerber na...@mips.inka.de
Okay
devel/mingw build fix (gmkdir)
Found with dpb -r:
The configure scripts in devel/mingw pick up gmkdir if installed
and the build fails if gmkdir then disappears in the background.
Trivial fix. OK?
Index: Makefile
===
RCS file: /cvs/ports/devel/mingw/Makefile,v
retrieving revision 1.6
diff -u -p -r1.6 Makefile
--- Makefile11 Jan 2014 12:56:41 - 1.6
+++ Makefile23 Jul 2014 14:25:00 -
@@ -64,6 +64,7 @@ do-build:
env MINGW32_TMP=${MINGW32_TMP} FULLDISTDIR=${FULLDISTDIR} \
MINGW32_OUT=${MINGW32_OUT} MAKE=${MAKE_PROGRAM} \
CONFIG_SHELL=${LOCALBASE}/bin/bash \
+ ac_cv_path_mkdir=/bin/mkdir \
/bin/sh ${WRKBUILD}/${BASENAME}.sh --no-pre-clean --no-post-clean \
--unattended
cd ${MINGW32_OUT}/lib/gcc/i386-mingw32/3.4.5/ && \
--
Christian "naddy" Weisgerber na...@mips.inka.de
Re: Firefox: Crashes while watching youtube videos
On Wed, Jul 23, 2014 at 01:33:14PM +0200, Landry Breuil wrote: > On Wed, Jul 23, 2014 at 12:30:20PM +0200, Fabian Raetz wrote: > > On Wed, Jul 23, 2014 at 11:33:44AM +0200, Landry Breuil wrote: > > > On Wed, Jul 23, 2014 at 12:01:01AM +0200, Fabian Raetz wrote: > > > > On Tue, Jul 22, 2014 at 11:48:18PM +0200, Landry Breuil wrote: > > > > > On Tue, Jul 22, 2014 at 11:27:36PM +0200, Fabian Raetz wrote: > > > > > > Hi, > > > > > > > > > > > > i am in the process of testing 5.6 on amd64 and > > > > > > noticed that firefox always coredumps while watching > > > > > > videos on youtube. > > > > > > > > > > > > Does someone see this too? > > > > > > > > > > > > I am uploading the coredumps to google drive. If someone > > > > > > want to take a look i will send the links. > > > > > > > > > > > > I will try on latest snapshot probably next day. > > > > > > > > > > > > > > > > > > @landry: > > > > > > I tries to install & test 31-beta from your pkgs > > > > > > but they are linked against an older libc. Do you have > > > > > > an actual package for me to test? Will firefox 31 make it > > > > > > into 5.6? > > > > > > > > > > No, and yes, probably. > > > > > > > > > > > Here's a sample backtrace. Have 3 of them, > > > > > > all with same backtrace: > > > > > > > > > > > > Current language: auto; currently asm > > > > > > #0 0x1be7cb2367fa in kill () at :2 > > > > > > #1 0x1be70a4e7f44 in XRE_FreeAppData () > > > > > >from /usr/local/lib/firefox-30.0/libxul.so.48.0 > > > > > > #2 > > > > > > #3 0x1be7faa71214 in decode_ics () > > > > > >from /usr/local/lib/gstreamer-1.0/libgstlibav.so > > > > > > > > > > Looks like at this point, a signal is raised within gstreamer1 for > > > > > some > > > > > reason, which calls the crash handler in firefox.. > > > > > > > > Hm, in two cases there was another coredump from "plugin-container" > > > > but i didn't know how to get a backtrace from it :( Maybe they have > > > > raised > > > > the signal? Any hints for me on how to get a backtrace of it? There is > > > > no program "plugin-container" on my system. > > > > > > $pkg_info -L firefox | grep plugin-container > > > /usr/local/lib/firefox-31.0/plugin-container > > > > -.- > > > > backtrace from plugin_container.core: > > > > #0 0x12d8637ea967 in mozalloc_abort () > >from /usr/local/lib/firefox-30.0/libmozalloc.so.48.0 > > > and another one: > > > > > > #0 0x1d6980704967 in mozalloc_abort () from > > /usr/local/lib/firefox-30.0/libmozalloc.so.48.0 > > bump your limits. Usually, when ffx hits the ulimits (because for some > reason a webpage consumes too much memory), it doesnt handle well the > case of malloc not returning more memory, and crashes. > > if you're running with the default ulimit -d of 500Mb, that's probably > the cause. Bump it to 1G or 2G. Hey Landry, i had bumped it to unlimited... ulimit -a time(cpu-seconds)unlimited file(blocks) unlimited coredump(blocks) unlimited data(kbytes) 33554432 stack(kbytes)4096 lockedmem(kbytes)1216644 memory(kbytes) 3627220 nofiles(descriptors) 7030 processes1310 > > Landry >
Re: FIX: conflict between ucspi-tcp and freedt
On 2014/07/23 13:56, Jérémie Courrèges-Anglas wrote: > Landry Breuil writes: > > > On Mon, Jul 21, 2014 at 07:10:47PM +0200, Jan Klemkow wrote: > >> Hi, > >> > >> this diff fixes a file conflict between the ports ucspi-tcp and freedt. > >> I just remove the binaries 'argv0' and 'recordio' cause I think the > >> manpages of the tools are useful. The package freedt does not provide > >> them. > >> > >> I am not sure, but I think increasing the revision number is the right > >> thing to do in this kind of situation!? > > > > Yes, bumping the rev number is one of the things to do, but simply > > removing files from PLIST wont be enough, since they'll come back next > > time someone runs make update-plist. You should either: > > - @comment both entries so they're not in the package > > - set appropriate @conflict markers in both PLISTs to explicitely say > > the two packages conflicts so they're not installed altogether. > > freedt is supposed to be a reimplementation of the daemontools package, > but the latter does not ship the argv0 and recordio executables. Also, > the freedt README says "These tools almost certainly aren't production > quality yet". Thus I'd either use @conflict or remove/rename the freedt > executables. +1 for removing/renaming the freedt executables.
Re: FIX: conflict between ucspi-tcp and freedt
Landry Breuil writes: > On Mon, Jul 21, 2014 at 07:10:47PM +0200, Jan Klemkow wrote: >> Hi, >> >> this diff fixes a file conflict between the ports ucspi-tcp and freedt. >> I just remove the binaries 'argv0' and 'recordio' cause I think the >> manpages of the tools are useful. The package freedt does not provide >> them. >> >> I am not sure, but I think increasing the revision number is the right >> thing to do in this kind of situation!? > > Yes, bumping the rev number is one of the things to do, but simply > removing files from PLIST wont be enough, since they'll come back next > time someone runs make update-plist. You should either: > - @comment both entries so they're not in the package > - set appropriate @conflict markers in both PLISTs to explicitely say > the two packages conflicts so they're not installed altogether. freedt is supposed to be a reimplementation of the daemontools package, but the latter does not ship the argv0 and recordio executables. Also, the freedt README says "These tools almost certainly aren't production quality yet". Thus I'd either use @conflict or remove/rename the freedt executables. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: Firefox: Crashes while watching youtube videos
On Wed, Jul 23, 2014 at 12:30:20PM +0200, Fabian Raetz wrote: > On Wed, Jul 23, 2014 at 11:33:44AM +0200, Landry Breuil wrote: > > On Wed, Jul 23, 2014 at 12:01:01AM +0200, Fabian Raetz wrote: > > > On Tue, Jul 22, 2014 at 11:48:18PM +0200, Landry Breuil wrote: > > > > On Tue, Jul 22, 2014 at 11:27:36PM +0200, Fabian Raetz wrote: > > > > > Hi, > > > > > > > > > > i am in the process of testing 5.6 on amd64 and > > > > > noticed that firefox always coredumps while watching > > > > > videos on youtube. > > > > > > > > > > Does someone see this too? > > > > > > > > > > I am uploading the coredumps to google drive. If someone > > > > > want to take a look i will send the links. > > > > > > > > > > I will try on latest snapshot probably next day. > > > > > > > > > > > > > > > @landry: > > > > > I tries to install & test 31-beta from your pkgs > > > > > but they are linked against an older libc. Do you have > > > > > an actual package for me to test? Will firefox 31 make it > > > > > into 5.6? > > > > > > > > No, and yes, probably. > > > > > > > > > Here's a sample backtrace. Have 3 of them, > > > > > all with same backtrace: > > > > > > > > > > Current language: auto; currently asm > > > > > #0 0x1be7cb2367fa in kill () at :2 > > > > > #1 0x1be70a4e7f44 in XRE_FreeAppData () > > > > >from /usr/local/lib/firefox-30.0/libxul.so.48.0 > > > > > #2 > > > > > #3 0x1be7faa71214 in decode_ics () > > > > >from /usr/local/lib/gstreamer-1.0/libgstlibav.so > > > > > > > > Looks like at this point, a signal is raised within gstreamer1 for some > > > > reason, which calls the crash handler in firefox.. > > > > > > Hm, in two cases there was another coredump from "plugin-container" > > > but i didn't know how to get a backtrace from it :( Maybe they have raised > > > the signal? Any hints for me on how to get a backtrace of it? There is > > > no program "plugin-container" on my system. > > > > $pkg_info -L firefox | grep plugin-container > > /usr/local/lib/firefox-31.0/plugin-container > > -.- > > backtrace from plugin_container.core: > > #0 0x12d8637ea967 in mozalloc_abort () >from /usr/local/lib/firefox-30.0/libmozalloc.so.48.0 > and another one: > > > #0 0x1d6980704967 in mozalloc_abort () from > /usr/local/lib/firefox-30.0/libmozalloc.so.48.0 bump your limits. Usually, when ffx hits the ulimits (because for some reason a webpage consumes too much memory), it doesnt handle well the case of malloc not returning more memory, and crashes. if you're running with the default ulimit -d of 500Mb, that's probably the cause. Bump it to 1G or 2G. Landry
Re: Firefox: Crashes while watching youtube videos
On Wed, Jul 23, 2014 at 11:33:44AM +0200, Landry Breuil wrote: > On Wed, Jul 23, 2014 at 12:01:01AM +0200, Fabian Raetz wrote: > > On Tue, Jul 22, 2014 at 11:48:18PM +0200, Landry Breuil wrote: > > > On Tue, Jul 22, 2014 at 11:27:36PM +0200, Fabian Raetz wrote: > > > > Hi, > > > > > > > > i am in the process of testing 5.6 on amd64 and > > > > noticed that firefox always coredumps while watching > > > > videos on youtube. > > > > > > > > Does someone see this too? > > > > > > > > I am uploading the coredumps to google drive. If someone > > > > want to take a look i will send the links. > > > > > > > > I will try on latest snapshot probably next day. > > > > > > > > > > > > @landry: > > > > I tries to install & test 31-beta from your pkgs > > > > but they are linked against an older libc. Do you have > > > > an actual package for me to test? Will firefox 31 make it > > > > into 5.6? > > > > > > No, and yes, probably. > > > > > > > Here's a sample backtrace. Have 3 of them, > > > > all with same backtrace: > > > > > > > > Current language: auto; currently asm > > > > #0 0x1be7cb2367fa in kill () at :2 > > > > #1 0x1be70a4e7f44 in XRE_FreeAppData () > > > >from /usr/local/lib/firefox-30.0/libxul.so.48.0 > > > > #2 > > > > #3 0x1be7faa71214 in decode_ics () > > > >from /usr/local/lib/gstreamer-1.0/libgstlibav.so > > > > > > Looks like at this point, a signal is raised within gstreamer1 for some > > > reason, which calls the crash handler in firefox.. > > > > Hm, in two cases there was another coredump from "plugin-container" > > but i didn't know how to get a backtrace from it :( Maybe they have raised > > the signal? Any hints for me on how to get a backtrace of it? There is > > no program "plugin-container" on my system. > > $pkg_info -L firefox | grep plugin-container > /usr/local/lib/firefox-31.0/plugin-container -.- backtrace from plugin_container.core: #0 0x12d8637ea967 in mozalloc_abort () from /usr/local/lib/firefox-30.0/libmozalloc.so.48.0 #1 0x12d85f3ea8d9 in NS_DebugBreak () from /usr/local/lib/firefox-30.0/libxul.so.48.0 #2 0x12d85f3ea78c in NS_DebugBreak () from /usr/local/lib/firefox-30.0/libxul.so.48.0 #3 0x12d85f633d20 in std::vector, std::allocator > >::_M_insert_aux () from /usr/local/lib/firefox-30.0/libxul.so.48.0 #4 0x12d85f635b83 in std::vector, std::allocator > >::_M_insert_aux () from /usr/local/lib/firefox-30.0/libxul.so.48.0 #5 0x12d85f5f6fa7 in std::vector >::operator= () from /usr/local/lib/firefox-30.0/libxul.so.48.0 #6 0x12d8725201e8 in event_base_loop (base=0x12d89060, flags=Variable "flags" is not available. ) at /usr/src/lib/libevent/event.c:405 #7 0x12d85f5ebbc9 in std::vector >::_M_fill_insert () from /usr/local/lib/firefox-30.0/libxul.so.48.0 #8 0x12d85f607339 in std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_erase () from /usr/local/lib/firefox-30.0/libxul.so.48.0 #9 0x12d85f614b3f in std::__find, char> () from /usr/local/lib/firefox-30.0/libxul.so.48.0 #10 0x12d85f5ec33a in std::vector >::_M_fill_insert () from /usr/local/lib/firefox-30.0/libxul.so.48.0 #11 0x12d7f9a7b97e in _rthread_start (v=Variable "v" is not available. ) at /usr/src/lib/librthread/rthread.c:145 #12 0x12d85c9b159b in __tfork_thread () at /usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:75 #13 0x in ?? () and another one: #0 0x1d6980704967 in mozalloc_abort () from /usr/local/lib/firefox-30.0/libmozalloc.so.48.0 #1 0x1d690716d8d9 in NS_DebugBreak () from /usr/local/lib/firefox-30.0/libxul.so.48.0 #2 0x1d690716d78c in NS_DebugBreak () from /usr/local/lib/firefox-30.0/libxul.so.48.0 #3 0x1d69073b6d20 in std::vector, std::allocator > >::_M_insert_aux () from /usr/local/lib/firefox-30.0/libxul.so.48.0 #4 0x1d69073b8b83 in std::vector, std::allocator > >::_M_insert_aux () from /usr/local/lib/firefox-30.0/libxul.so.48.0 #5 0x1d6907379fa7 in std::vector >::operator= () from /usr/local/lib/firefox-30.0/libxul.so.48.0 #6 0x1d69139221e8 in event_base_loop (base=0x1d6910fda000, flags=Variable "flags" is not available. ) at /usr/src/lib/libevent/event.c:405 #7 0x1d690736ebc9 in std::vector >::_M_fill_insert () from /usr/local/lib/firefox-30.0/libxul.so.48.0 #8 0x1d690738a339 in std::_Rb_tree, std::_Select1st >, std::less, std::allocator > >::_M_erase () from /usr/local/lib/firefox-30.0/libxul.so.48.0 #9 0x1d6907397b3f in std::__find, char> () from /usr/local/lib/firefox-30.0/libxul.so.48.0 #10 0x1d690736f33a in std::vector >::_M_fill_insert () from /usr/local/lib/firefox-30.0/libxul.so.48.0 #11 0x1d69c683897e in _rthread_start (v=Variable "v" is not available. ) at /usr/src/lib/librthread/rthread.c:145 #12 0x1d69340e659b in __tfork_thread () at /usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:75 #13 0x in ?? () The program is not being run. >
Re: Firefox: Crashes while watching youtube videos
On Wed, Jul 23, 2014 at 12:01:01AM +0200, Fabian Raetz wrote: > On Tue, Jul 22, 2014 at 11:48:18PM +0200, Landry Breuil wrote: > > On Tue, Jul 22, 2014 at 11:27:36PM +0200, Fabian Raetz wrote: > > > Hi, > > > > > > i am in the process of testing 5.6 on amd64 and > > > noticed that firefox always coredumps while watching > > > videos on youtube. > > > > > > Does someone see this too? > > > > > > I am uploading the coredumps to google drive. If someone > > > want to take a look i will send the links. > > > > > > I will try on latest snapshot probably next day. > > > > > > > > > @landry: > > > I tries to install & test 31-beta from your pkgs > > > but they are linked against an older libc. Do you have > > > an actual package for me to test? Will firefox 31 make it > > > into 5.6? > > > > No, and yes, probably. > > > > > Here's a sample backtrace. Have 3 of them, > > > all with same backtrace: > > > > > > Current language: auto; currently asm > > > #0 0x1be7cb2367fa in kill () at :2 > > > #1 0x1be70a4e7f44 in XRE_FreeAppData () > > >from /usr/local/lib/firefox-30.0/libxul.so.48.0 > > > #2 > > > #3 0x1be7faa71214 in decode_ics () > > >from /usr/local/lib/gstreamer-1.0/libgstlibav.so > > > > Looks like at this point, a signal is raised within gstreamer1 for some > > reason, which calls the crash handler in firefox.. > > Hm, in two cases there was another coredump from "plugin-container" > but i didn't know how to get a backtrace from it :( Maybe they have raised > the signal? Any hints for me on how to get a backtrace of it? There is > no program "plugin-container" on my system. $pkg_info -L firefox | grep plugin-container /usr/local/lib/firefox-31.0/plugin-container Landry
Re: Update plan9/plan9port with fontsrv support
On 2014/07/23 02:31, Matt Jibson wrote: > This enables support for fontsrv. I'm aware of the lock, just didn't want > to forget this once it's open. Realistically it's unlikely for developers to remember this mail for the month or more that ports locks usually take, it would be better to hang onto it and resend later. btw it's missing a REVISION bump.
