CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: m...@cvs.openbsd.org2013/04/10 01:33:33 Modified files: www/liferea: Makefile distinfo Log message: Update to liferea 1.8.12 and remove USE_GROFF, maintainer timeout. ok landry@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: pas...@cvs.openbsd.org 2013/04/10 02:29:56 Modified files: lang/fpc : Makefile Added files: lang/fpc/patches: patch-fpcsrc_packages_openssl_src_openssl_pas Log message: Load libcrypto before libssl in the OpenSSL package.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2013/04/10 03:40:02 Modified files: x11/gnome/user-share: Makefile x11/gnome/user-share/patches: patch-configure_ac patch-src_user_share_c Added files: x11/gnome/user-share/patches: patch-data_Makefile_am patch-data_org_gnome_desktop_file-sharing-bluetooth_gschema_xml_in_in patch-data_org_gnome_desktop_file-sharing_gschema_xml_in_in Log message: Split the sharing schema so that we don't install the bluetooth keys which we don't support.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2013/04/10 03:40:59 Modified files: x11/gnome/controlcenter: Makefile x11/gnome/controlcenter/patches: patch-panels_sharing_cc-sharing-panel_c Log message: FILE_SHARING_SCHEMA_ID - FILE_SHARING_BLUETOOTH_SCHEMA_ID where needed.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2013/04/10 06:34:27 Modified files: print/system-config-printer: Makefile Log message: Missing BUILD_DEPENDS; spotted by naddy@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2013/04/10 07:15:14 Modified files: converters/p5-DateManip: Makefile distinfo converters/p5-DateManip/pkg: PLIST Log message: update to p5-DateManip 6.39, ok espie@ (maintainer)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2013/04/10 08:13:53 Modified files: x11/gnome/tracker: Makefile x11/gnome/tracker/patches: patch-src_libtracker-common_tracker-type-utils_c Added files: x11/gnome/tracker/patches: patch-configure_ac patch-m4_intltool_m4 patch-src_libtracker-extract_tracker-utils_c patch-src_tracker-needle_tracker-utils_c Removed files: x11/gnome/tracker/patches: patch-configure patch-src_libtracker-common_Makefile_in patch-src_libtracker-common_tracker-dbus_c patch-src_libtracker-common_tracker-os-dependant-unix_c patch-src_libtracker-miner_tracker-password-provider_c patch-src_tracker-control_Makefile_in patch-src_tracker-control_tracker-control-general_c patch-src_tracker-needle_tracker-utils_vala Log message: Rework all kvm(3) patches to a state closer to being commitable upstream. Fix a few implicit declarations. Remove patch-src_libtracker-miner_tracker-password-provider_c which is not needed anymore.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: o...@cvs.openbsd.org2013/04/10 08:14:37 Modified files: sysutils/sec : Makefile distinfo Log message: maintenance update to 2.7.1 ok ajacoutot
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2013/04/10 08:29:53 Modified files: x11/gnome/settings-daemon: Makefile x11/gnome/settings-daemon/patches: patch-plugins_media-keys_gsd-media-keys-manager_c Log message: Fix a race condition that could lead to a crash (upstream).
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2013/04/10 08:30:43 Modified files: x11/gnome/tracker: Makefile Added files: x11/gnome/tracker/patches: patch-src_libtracker-common_tracker-dbus_c patch-src_libtracker-common_tracker-os-dependant-unix_c patch-src_tracker-control_tracker-control-general_c Log message: cvs(1) missed those...???
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2013/04/10 09:41:47 Modified files: x11/gnome/tracker: Makefile x11/gnome/tracker/patches: patch-tests_libtracker-common_tracker-sched-test_c Added files: x11/gnome/tracker/patches: patch-src_tracker-needle_Makefile_in patch-src_tracker-needle_tracker-utils_vala Removed files: x11/gnome/tracker/patches: patch-src_tracker-needle_tracker-utils_c Log message: Fix another implicit declaration.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2013/04/10 10:14:28 Modified files: www/chromium : Makefile distinfo Log message: update to 26.0.1410.63
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2013/04/10 11:07:39 Modified files: print/cups-filters/patches: patch-utils_cups-browsed_c Log message: Committed upstream.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2013/04/10 11:17:23 Modified files: print/cups-filters: Makefile print/cups-filters/patches: patch-utils_cups-browsed_c Log message: Forgot to sync the patch in previous.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2013/04/10 12:46:43 Modified files: www/chromium : Makefile www/chromium/patches: patch-base_atomicops_h patch-chrome_chrome_browser_gypi Log message: update some patches
Re: NEW: www/c-icap (web proxy content inspection)
Here's an update with a patch to the manpage to fix the path for control socket/pid as setup by the port. I've been using this with squidclamav for a few days, it seems much nicer than havp so far. c-icap.tgz Description: application/tar-gz
update sysutils/sec
maintenance update to 2.7.1
ok?
cheers,
okan
Index: Makefile
===
RCS file: /home/open/cvs/ports/sysutils/sec/Makefile,v
retrieving revision 1.20
diff -u -p -r1.20 Makefile
--- Makefile11 Mar 2013 11:41:32 - 1.20
+++ Makefile10 Apr 2013 13:59:51 -
@@ -2,7 +2,7 @@
COMMENT= simple event correlator
-DISTNAME= sec-2.7.0
+DISTNAME= sec-2.7.1
CATEGORIES=sysutils
MASTER_SITES= ${MASTER_SITE_SOURCEFORGE:=simple-evcorr/}
Index: distinfo
===
RCS file: /home/open/cvs/ports/sysutils/sec/distinfo,v
retrieving revision 1.15
diff -u -p -r1.15 distinfo
--- distinfo31 Jan 2013 18:33:39 - 1.15
+++ distinfo10 Apr 2013 14:01:31 -
@@ -1,2 +1,2 @@
-SHA256 (sec-2.7.0.tar.gz) = henwNWuQWR8F9QV92St4AIHK9oXYiWvLYYX7nubb2+g=
-SIZE (sec-2.7.0.tar.gz) = 105388
+SHA256 (sec-2.7.1.tar.gz) = sxqUg0bqDBkNLdGKf13XKWTTsY80/OXUDGCeWv1jIUU=
+SIZE (sec-2.7.1.tar.gz) = 107617
NEW: games/polymorphable
Hi ports -- Attached is a tarball for the game polymorphable, which is an action RPG mod of games/flare. Works for me on amd64. OK? ~Brian polymorphable.tgz Description: Binary data
Firefox and large images
A number of weeks ago, I reported this problem on freebsd-ports: --- Viewing large images has become cumbersome with the switch from Firefox 18 to 19. Am I the only one to notice this? Wikipedia's high-resolution pictures of the day are great for this: https://upload.wikimedia.org/wikipedia/commons/e/e9/Bison_skull_pile_edit.jpg What happens is that Firefox loads the image and then does some sort of operation that causes the X11 server to be busy for a noticeable amount of time. During this time the whole X11 session hangs. If you have a network login, you can see the Xorg process eat all the CPU it can get. The duration of this delay varies and depends on the size of the image; with the one above it just took 30 seconds. This isn't entirely new. With previous versions of Firefox it happened when I accidentally dragged an image. But now with Firefox 19, just viewing the image is enough. Needless to say, this is painful if you are going through a number of large images and are forced to pause for half a minute each. --- Unsurprisingly, several people have now run into the same problem on OpenBSD. Workarounds are setting MOZ_DISABLE_IMAGE_OPTIMIZE=1 in the environment or disabling gfx.xrender.enabled in about:config. (You have to restart Firefox after toggling gfx.xrender.enabled.) I'm throwing this out there, but users shouldn't really be required to invoke magic incantations. -- Christian naddy Weisgerber na...@mips.inka.de
Re: Firefox and large images
On Wed, Apr 10, 2013 at 03:57:21PM +, Christian Weisgerber wrote: A number of weeks ago, I reported this problem on freebsd-ports: --- Viewing large images has become cumbersome with the switch from Firefox 18 to 19. Am I the only one to notice this? Wikipedia's high-resolution pictures of the day are great for this: https://upload.wikimedia.org/wikipedia/commons/e/e9/Bison_skull_pile_edit.jpg What happens is that Firefox loads the image and then does some sort of operation that causes the X11 server to be busy for a noticeable amount of time. During this time the whole X11 session hangs. If you have a network login, you can see the Xorg process eat all the CPU it can get. The duration of this delay varies and depends on the size of the image; with the one above it just took 30 seconds. You'll also see the memory footprint of the Xorg process climb to the ceiling during that period. This isn't entirely new. With previous versions of Firefox it happened when I accidentally dragged an image. But now with Firefox 19, just viewing the image is enough. Needless to say, this is painful if you are going through a number of large images and are forced to pause for half a minute each. --- I've seen that too for a long time, and what's most annoying imho is that it also does it for large images scaled down with small width= and height= values in the image tag. Since afaik the X server offers no services to help scaling down the image, I didn't understand the point in firefox allocating the full size pixmap (or even several copies of it) in the X server. But yes, dragging may make sense. So ff may indeed be copying the full size image fo one of X cut buffers, which have the ability to contain stuff other than text... Unsurprisingly, several people have now run into the same problem on OpenBSD. Workarounds are setting MOZ_DISABLE_IMAGE_OPTIMIZE=1 in the environment or disabling gfx.xrender.enabled in about:config. (You have to restart Firefox after toggling gfx.xrender.enabled.) I'm throwing this out there, but users shouldn't really be required to invoke magic incantations. -- Christian naddy Weisgerber na...@mips.inka.de -- Matthieu Herrb
Re: Firefox and large images
On Wed, Apr 10, 2013 at 03:57:21PM +, Christian Weisgerber wrote: Workarounds are setting MOZ_DISABLE_IMAGE_OPTIMIZE=1 in the environment or disabling gfx.xrender.enabled in about:config. (You have to restart Firefox after toggling gfx.xrender.enabled.) I see the samething with landry's wip firefox 20.0 from April 2nd. MOZ_DISABLE_IMAGE_OPTIMIZE=1 fixes the problem while disableing gfx.xrender.enabled leeds to a segfault on restart. [florian@laptop:~]$ gdb /usr/local/bin/firefox firefox.core GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-unknown-openbsd5.3...(no debugging symbols fou Core was generated by `firefox'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libpthread.so.17.0...done. Loaded symbols for /usr/lib/libpthread.so.17.0 Reading symbols from /usr/lib/libstdc++.so.55.0...done. Loaded symbols for /usr/lib/libstdc++.so.55.0 Reading symbols from /usr/lib/libm.so.8.0...done. Loaded symbols for /usr/lib/libm.so.8.0 Symbols already loaded for /usr/lib/libpthread.so.17.0 Reading symbols from /usr/lib/libc.so.67.0...done. Loaded symbols for /usr/lib/libc.so.67.0 Reading symbols from /usr/libexec/ld.so...done. Loaded symbols for /usr/libexec/ld.so Reading symbols from /usr/local/lib/firefox-20.0/libmozalloc.so.39.0...done. Loaded symbols for /usr/local/lib/firefox-20.0/libmozalloc.so.39.0 Reading symbols from /usr/local/lib/firefox-20.0/libxul.so.39.0...done. Loaded symbols for /usr/local/lib/firefox-20.0/libxul.so.39.0 Reading symbols from /usr/local/lib/libssl3.so.33.2...done. Loaded symbols for /usr/local/lib/libssl3.so.33.2 Reading symbols from /usr/local/lib/libsmime3.so.33.2...done. Loaded symbols for /usr/local/lib/libsmime3.so.33.2 Reading symbols from /usr/local/lib/libnss3.so.33.2...done. Loaded symbols for /usr/local/lib/libnss3.so.33.2 Reading symbols from /usr/local/lib/libnssutil3.so.33.2...done. Loaded symbols for /usr/local/lib/libnssutil3.so.33.2 Reading symbols from /usr/local/lib/libcairo.so.12.2...done. Loaded symbols for /usr/local/lib/libcairo.so.12.2 Reading symbols from /usr/X11R6/lib/libXext.so.12.0...done. Loaded symbols for /usr/X11R6/lib/libXext.so.12.0 Reading symbols from /usr/X11R6/lib/libXrender.so.5.0...done. Loaded symbols for /usr/X11R6/lib/libXrender.so.5.0 Reading symbols from /usr/X11R6/lib/libX11.so.15.1...done. Loaded symbols for /usr/X11R6/lib/libX11.so.15.1 Reading symbols from /usr/lib/libsqlite3.so.22.0...done. Loaded symbols for /usr/lib/libsqlite3.so.22.0 Reading symbols from /usr/lib/libz.so.4.1...done. Loaded symbols for /usr/lib/libz.so.4.1 Reading symbols from /usr/lib/libevent.so.3.1...done. Loaded symbols for /usr/lib/libevent.so.3.1 Reading symbols from /usr/X11R6/lib/libpixman-1.so.28.0...done. Loaded symbols for /usr/X11R6/lib/libpixman-1.so.28.0 Reading symbols from /usr/X11R6/lib/libpthread-stubs.so.1.0...done. Loaded symbols for /usr/X11R6/lib/libpthread-stubs.so.1.0 Reading symbols from /usr/local/lib/libplds4.so.22.2...done. Loaded symbols for /usr/local/lib/libplds4.so.22.2 Reading symbols from /usr/local/lib/libplc4.so.22.2...done. Loaded symbols for /usr/local/lib/libplc4.so.22.2 Reading symbols from /usr/local/lib/libnspr4.so.22.2...done. Loaded symbols for /usr/local/lib/libnspr4.so.22.2 Reading symbols from /usr/lib/libsndio.so.4.0...done. Loaded symbols for /usr/lib/libsndio.so.4.0 Reading symbols from /usr/local/lib/libpangocairo-1.0.so.3400.0...done. Loaded symbols for /usr/local/lib/libpangocairo-1.0.so.3400.0 Reading symbols from /usr/local/lib/libpangoft2-1.0.so.3400.0...done. Loaded symbols for /usr/local/lib/libpangoft2-1.0.so.3400.0 Reading symbols from /usr/local/lib/libpango-1.0.so.3400.0...done. Loaded symbols for /usr/local/lib/libpango-1.0.so.3400.0 Reading symbols from /usr/local/lib/libgobject-2.0.so.3600.0...done. Loaded symbols for /usr/local/lib/libgobject-2.0.so.3600.0 Reading symbols from /usr/local/lib/libglib-2.0.so.3600.0...done. Loaded symbols for /usr/local/lib/libglib-2.0.so.3600.0 Reading symbols from /usr/local/lib/libintl.so.6.0...done. Loaded symbols for /usr/local/lib/libintl.so.6.0 Reading symbols from /usr/X11R6/lib/libfreetype.so.19.0...done. Loaded symbols for /usr/X11R6/lib/libfreetype.so.19.0 Reading symbols from /usr/X11R6/lib/libfontconfig.so.8.0...done. Loaded symbols for /usr/X11R6/lib/libfontconfig.so.8.0 Reading symbols from /usr/local/lib/libgtk-x11-2.0.so.2400.0...done. Loaded symbols for /usr/local/lib/libgtk-x11-2.0.so.2400.0 Reading symbols from /usr/local/lib/libatk-1.0.so.20809.1...done. Loaded symbols for /usr/local/lib/libatk-1.0.so.20809.1 Reading symbols from /usr/local/lib/libgdk-x11-2.0.so.2400.0...done.
Re: Do you plan update version of net/psi to 0.15?
On Wed, Apr 10, 2013 at 10:57:31AM +0500, dmitry.sensei wrote:
Hi!
Do you plan update version of net/psi to 0.15?
Some suggestion was be made in
http://comments.gmane.org/gmane.os.openbsd.ports/58536
sync with last changes in ports.
Someone has any objections ? Comment ? OK ?
--
Alexandr Shadchin
Index: Makefile
===
RCS file: /cvs/ports/net/psi/Makefile,v
retrieving revision 1.17
diff -u -p -r1.17 Makefile
--- Makefile11 Mar 2013 11:35:55 - 1.17
+++ Makefile10 Apr 2013 18:28:08 -
@@ -2,8 +2,7 @@
COMMENT= multiplatform Jabber client
-DISTNAME= psi-0.10
-REVISION= 1
+DISTNAME= psi-0.15
CATEGORIES=net
HOMEPAGE= http://psi-im.org/
@@ -11,73 +10,66 @@ HOMEPAGE= http://psi-im.org/
MASTER_SITES= ${MASTER_SITE_SOURCEFORGE:=psi/}
EXTRACT_SUFX= .tar.bz2
-# GPL
+# GPLv2
PERMIT_PACKAGE_CDROM= Yes
-WANTLIB= X11 Xext Xss m c pthread pthread-stubs stdc++ xcb z \
- qca=1
+WANTLIB += ICE QtDBus QtGui QtNetwork QtXml SM X11 Xext Xi Xinerama
+WANTLIB += Xrender Xss c enchant fontconfig freetype glib-2.0
+WANTLIB += gmodule-2.0 intl m pthread qca2 stdc++ z
-MODULES= x11/qt3
-
-MODQT_OVERRIDE_UIC=No
+MODULES= x11/qt4
USE_GMAKE= Yes
-LIB_DEPENDS= security/qca
-RUN_DEPENDS= security/qca-tls
+LIB_DEPENDS= security/qca2 \
+ textproc/enchant
+RUN_DEPENDS= devel/desktop-file-utils \
+ security/qca-gnupg \
+ security/qca-ossl \
+ x11/gtk+2,-guic
CONFIGURE_STYLE= simple
-CONFIGURE_ARGS+= --qtdir=${MODQT_QTDIR} \
- --with-qca-inc=${LOCALBASE}/include \
- --with-qca-lib=${LOCALBASE}/lib \
- --disable-growl \
- --disable-dnotify \
- --disable-ghbnr
-
-CONFIGURE_ENV+=LOCALBASE=${LOCALBASE} \
- KDEDIR=${LOCALBASE}
+CONFIGURE_ARGS+= --prefix=${LOCALBASE} \
+ --qtdir=${MODQT4_QTDIR} \
+ --with-qca-inc=${LOCALBASE}/include/QtCrypto \
+ --disable-growl
# For QSettings to write its setup
-PORTHOME= ${WRKDIST}
+PORTHOME= ${WRKDIST}
NO_TEST= Yes
-pre-configure:
- @perl -pi -e s@%%X11BASE%%@${X11BASE}@ ${WRKSRC}/configure
-
-# compilation breaks if /usr/local/include/socks.h (from security/dante) is
-# found before psi's own socks.h, so add a workaround.
-pre-build:
- @perl -pi -e 's,INCLUDEPATH.*,,' ${WRKSRC}/conf.pri
-
do-install:
- ${INSTALL_PROGRAM} ${WRKSRC}/src/psi ${PREFIX}/bin
+ ${INSTALL_PROGRAM} ${WRKSRC}/psi ${PREFIX}/bin
${INSTALL_DATA_DIR} ${PREFIX}/share/psi
${INSTALL_DATA} ${WRKSRC}/COPYING ${PREFIX}/share/psi
${INSTALL_DATA} ${WRKSRC}/README ${PREFIX}/share/psi
cp -R ${WRKSRC}/iconsets ${PREFIX}/share/psi
cp -R ${WRKSRC}/sound ${PREFIX}/share/psi
cp -R ${WRKSRC}/certs ${PREFIX}/share/psi
- cp -R ${WRKSRC}/certs ${PREFIX}/share/psi
- ${INSTALL_DATA} ${WRKSRC}/libpsi/psiwidgets/libpsiwidgets.so \
- ${PREFIX}/share/psi
- # Icons for KDE
- ${INSTALL_DATA_DIR} ${PREFIX}/share/applnk/Internet
- ${INSTALL_DATA} ${WRKSRC}/psi.desktop \
- ${PREFIX}/share/applnk/Internet/
+ ${INSTALL_DATA_DIR} ${PREFIX}/share/applications
+ ${INSTALL_DATA} ${WRKSRC}/psi.desktop ${PREFIX}/share/applications/
${INSTALL_DATA_DIR} ${PREFIX}/share/icons/hicolor/16x16/apps
- ${INSTALL_DATA} ${WRKSRC}/iconsets/system/default/icon_16.png \
+ ${INSTALL_DATA} ${WRKSRC}/iconsets/system/default/logo_16.png \
${PREFIX}/share/icons/hicolor/16x16/apps/psi.png
${INSTALL_DATA_DIR} ${PREFIX}/share/icons/hicolor/32x32/apps
- ${INSTALL_DATA} ${WRKSRC}/iconsets/system/default/icon_32.png \
+ ${INSTALL_DATA} ${WRKSRC}/iconsets/system/default/logo_32.png \
${PREFIX}/share/icons/hicolor/32x32/apps/psi.png
${INSTALL_DATA_DIR} ${PREFIX}/share/icons/hicolor/48x48/apps
- ${INSTALL_DATA} ${WRKSRC}/iconsets/system/default/icon_48.png \
+ ${INSTALL_DATA} ${WRKSRC}/iconsets/system/default/logo_48.png \
${PREFIX}/share/icons/hicolor/48x48/apps/psi.png
+
+ ${INSTALL_DATA_DIR} ${PREFIX}/share/icons/hicolor/64x64/apps
+ ${INSTALL_DATA} ${WRKSRC}/iconsets/system/default/logo_64.png \
+ ${PREFIX}/share/icons/hicolor/64x64/apps/psi.png
+
+ ${INSTALL_DATA_DIR} ${PREFIX}/share/icons/hicolor/128x128/apps
+ ${INSTALL_DATA} ${WRKSRC}/iconsets/system/default/logo_128.png \
+ ${PREFIX}/share/icons/hicolor/128x128/apps/psi.png
.include bsd.port.mk
Index:
Re: NEW: games/polymorphable
On 04/10/13 11:24, Brian Callahan wrote: Hi ports -- Attached is a tarball for the game polymorphable, which is an action RPG mod of games/flare. Works for me on amd64. OK? ~Brian Now with tweaks from kirby@ Makes the do-install routine a lot more sane. And some style tweaks. ~Brian polymorphable.tgz Description: Binary data
Squashing the main portimport's bug
Hello all.
This patch tries to address the (only mentioned) portimport(1) bug.
Now, if you're the one who has @openbsd.org nickname different from
your login one, you can just add the following to ~/.kshrc (or
whatever you're using):
alias portimport=portimport -u myobsdlogin
... instead of patching the code. Thoughts, okays?
--
WBR,
Vadim Zhukov
Index: bin/portimport
===
RCS file: /cvs/ports/infrastructure/bin/portimport,v
retrieving revision 1.1
diff -u -p -r1.1 portimport
--- bin/portimport 9 Apr 2013 19:51:37 - 1.1
+++ bin/portimport 10 Apr 2013 20:21:51 -
@@ -21,10 +21,19 @@
set -e
A
-# XXX
-# XXX CHANGE if you login to cvs.openbsd.org with different user
-# XXX
+usage() {
+ echo usage: $(basename $0) [-u username] 2
+ exit 1
+}
+
user=$(id -un)
+
+while getopts u: OPT; do
+ case $OPT in
+ u) user=$OPTARG;;
+ *) usage;;
+ esac
+done
cvsroot=$u...@cvs.openbsd.org:/cvs
error=false
Index: man/man1/portimport.1
===
RCS file: /cvs/ports/infrastructure/man/man1/portimport.1,v
retrieving revision 1.1
diff -u -p -r1.1 portimport.1
--- man/man1/portimport.1 9 Apr 2013 19:51:37 - 1.1
+++ man/man1/portimport.1 10 Apr 2013 20:21:51 -
@@ -22,6 +22,7 @@
.Nd import a new port to the ports cvs repository
.Sh SYNOPSIS
.Nm portimport
+.Op Fl u Ar username
.Sh DESCRIPTION
.Nm
is used to import the directories and files of a new port to the
@@ -45,6 +46,16 @@ In the second step, the current ports di
ports cvs repository.
After the import, the new port is checked out in the respective directory
of the local ports tree.
+.Pp
+By default, the login name of the current user is used for the
+.Xr ssh 1
+connection to the
+.Ox
+cvs server, to compose the vendortag and the releasetag.
+The
+.Fl u
+option could be used to specify different username.
+In the latter case, it would be a good idea to create a shell alias even.
.Sh SEE ALSO
.Xr cvs 1
.Sh HISTORY
@@ -54,13 +65,3 @@ modified by Stuart Henderson and rewritt
The
.Ev CVSROOT
environment variable is not used.
-.Sh BUGS
-The login name of the current user is used for the
-.Xr ssh 1
-connection to the
-.Ox
-cvs server, to compose the vendortag and the releasetag.
-The value of the
-.Va user
-variable has to be changed in the sourcecode if a different login name is
-used to connect to the cvs server.
Re: Firefox and large images
On Wed, Apr 10, 2013 at 03:57:21PM +, Christian Weisgerber wrote: A number of weeks ago, I reported this problem on freebsd-ports: --- Viewing large images has become cumbersome with the switch from Firefox 18 to 19. Am I the only one to notice this? Wikipedia's high-resolution pictures of the day are great for this: https://upload.wikimedia.org/wikipedia/commons/e/e9/Bison_skull_pile_edit.jpg What happens is that Firefox loads the image and then does some sort of operation that causes the X11 server to be busy for a noticeable amount of time. During this time the whole X11 session hangs. If you have a network login, you can see the Xorg process eat all the CPU it can get. The duration of this delay varies and depends on the size of the image; with the one above it just took 30 seconds. This isn't entirely new. With previous versions of Firefox it happened when I accidentally dragged an image. But now with Firefox 19, just viewing the image is enough. Needless to say, this is painful if you are going through a number of large images and are forced to pause for half a minute each. --- Unsurprisingly, several people have now run into the same problem on OpenBSD. Workarounds are setting MOZ_DISABLE_IMAGE_OPTIMIZE=1 in the environment or disabling gfx.xrender.enabled in about:config. (You have to restart Firefox after toggling gfx.xrender.enabled.) It slows down firefox in my ssh session. Anyway, I don't have the issue described in your mail. I'm throwing this out there, but users shouldn't really be required to invoke magic incantations. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: [bug] chromium problem since 26.0.1410.43
On Mon, Apr 08, 2013 at 07:23, Robert Nagy wrote: It seems to be a different issue which is not related to chromium itself. It is being investigated. I assume you have been trying on i386? I suspect you don't need this, but to fill out a few details in case anybody else is seeing crashes, they can confirm this is the same problem. I see this on i386 with chromium-26.0.1410.43-proprietary. Opening a new tab displays the sad tab and this on console: [6692:-2104363520:0411/005739:ERROR:user_style_sheet_watcher.cc(174)] Failed to setup watch for /home/tedu/.config/chromium/Default/User StyleSheets/Custom.css Visiting www.openbsd.org works as expected. Visiting www.apple.com displays the sad tab and this (repeating): [5303:600661216:0411/005904:ERROR:omnibox_view_gtk.cc(431)] Not implemented reached in virtual void OmniboxViewGtk::ApplyCaretVisibility() Runing as env G_SLICE=always-malloc chrome helps a little, but not really. It's still pretty useless.
