CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2010/06/25 02:16:51 Modified files: audio/tremor : Makefile Log message: Add libtool to BUILD_DEPENDS instead of overriding it. Fixes build on a clean machine so that it correctly installs autoconf/automake/metaauto.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: es...@cvs.openbsd.org 2010/06/25 04:37:03 Modified files: infrastructure/package: find-all-conflicts Log message: get bin files to participate, as noticed by sthen
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2010/06/25 05:45:12 Modified files: net/aircontrol : Makefile distinfo net/aircontrol/pkg: MESSAGE Log message: update to 1.2-beta; N.B. default http port changed to 9080.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: es...@cvs.openbsd.org 2010/06/25 06:02:18 Modified files: infrastructure/install: make-plist Log message: work-around: if we don't get a shortname, tell the user something is a bit too wrong, and return instead of building bogus things. (I don't see how this ends up in haystack, though). as noticed by sthen@ on tomcat/v6
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2010/06/25 06:29:03 Modified files: net/aircontrol : Makefile net/aircontrol/pkg: PLIST Log message: fix the plist
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: merd...@cvs.openbsd.org 2010/06/25 07:50:47 Modified files: www/privoxy: Makefile distinfo www/privoxy/pkg: PLIST Log message: Update to 3.0.16. Adds IPv6 support. Diff from Robert robert ! openbsd . pap . st Similar diff from Gabriel Kihlman gk ! stacken . kth . se ok benoit@, theoretical ok ajacoutot@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2010/06/25 07:54:34 Modified files: databases/evolution-data-server: Makefile Log message: Use autoconf 2.64 instead of 2.65, which still has some issues. Fixes the build on gcc4 archs.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ste...@cvs.openbsd.org 2010/06/25 11:18:21 Added files: x11/gtk-vnc/patches: patch-src_Makefile_in Log message: remove space after -Wl argument fixes build with in-tree libtool
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2010/06/25 11:39:12 Modified files: net/samba : Makefile distinfo net/samba/patches: patch-configure_in Log message: update to 3.5.4, from new maintainer, Ian McWilliam.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ste...@cvs.openbsd.org 2010/06/25 14:03:54 Modified files: infrastructure/build: libtool Log message: always search for the library file when walking the final lib list; also delete the fullpath if no library file is found. maybe slightly less efficient but should be safer
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ste...@cvs.openbsd.org 2010/06/25 14:29:11 Modified files: infrastructure/build: libtool Log message: put string into a variable here
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ste...@cvs.openbsd.org 2010/06/25 14:59:33 Modified files: infrastructure/build: libtool Log message: Library-find wants to know where it is called from (LaFile or Program)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ste...@cvs.openbsd.org 2010/06/25 15:39:35 Modified files: infrastructure/build: libtool Log message: basic dependency drop if library isn't found (only when linking a library) makes security/pcsc-lite build
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2010/06/25 16:44:33 Modified files: comms/smstools : Makefile distinfo Log message: update to 3.1.11
URGENT Locaux commerciaux à louer ou à vendre
URGENT! A CRETEIL A LOUER OU A VENDRE LOCAUX A USAGE DE BUREAUX, ACTIVITE ET ENTREPOSAGE 1) Immeuble indipendant sur 2 niveaux 1100 m2 15 places de parkings POUR TOUT RENSEIGNEMENT, CONTACTER STR FINANCE 17 rue des Rifugniks 94000 CRETEIL Fax : 01 41 94 85 76 e-mail : str-finance-wanadoo.fr Tel: 01 41 94 85 58 Port: 06 11 17 04 38 [demime 1.01d removed an attachment of type image/jpeg which had a name of image002.jpg] [demime 1.01d removed an attachment of type image/jpeg which had a name of image004.jpg]
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: will...@cvs.openbsd.org 2010/06/25 20:14:11 Modified files: devel/pcre : Tag: OPENBSD_4_7 Makefile Added files: devel/pcre/patches: Tag: OPENBSD_4_7 patch-pcre_compile_c Log message: MFC: SECURITY FIX Resolves SA39738 ok jasper@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2010/06/25 21:41:24 Removed files: graphics/win32-codecs: Makefile distinfo graphics/win32-codecs/pkg: DESCR PLIST Log message: Remove win32-codecs. Nothing in tree uses them anymore. From Brad. ok robert@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2010/06/25 21:42:59 Removed files: sysutils/policykit: Makefile distinfo sysutils/policykit/patches: patch-configure_in patch-data_PolicyKit_conf_in patch-src_kit_kit-memory_c patch-src_kit_kit-spawn_c patch-src_kit_kit-string_c patch-src_polkit-dbus_polkit-dbus_c patch-src_polkit-dbus_polkit-resolve-exe-helper_c patch-src_polkit-grant_Makefile_in patch-src_polkit-grant_polkit-grant-helper-bsdauth_c patch-src_polkit-grant_polkit-grant-helper_c patch-src_polkit_Makefile_in patch-src_polkit_polkit-sysdeps_c patch-tools_polkit-auth_c sysutils/policykit/pkg: DESCR MESSAGE PFRAG.shared PLIST Log message: Remove non working policykit. It's been deprecated by polkit anyway. ok robert@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2010/06/25 21:41:42 Modified files: graphics : Makefile Log message: -win32-codecs
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2010/06/25 21:53:36 Modified files: textproc/meld : Makefile distinfo textproc/meld/pkg: PLIST Added files: textproc/meld/patches: patch-bin_meld Removed files: textproc/meld/patches: patch-meld Log message: Update to meld-1.3.2.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: will...@cvs.openbsd.org 2010/06/25 22:14:26 Modified files: editors/nano : Tag: OPENBSD_4_7 Makefile distinfo editors/nano/patches: Tag: OPENBSD_4_7 patch-doc_man_Makefile_in patch-doc_man_fr_Makefile_in patch-doc_syntax_c_nanorc patch-src_Makefile_in editors/nano/pkg: Tag: OPENBSD_4_7 PLIST Added files: editors/nano/patches: Tag: OPENBSD_4_7 patch-doc_syntax_cmake_nanorc Log message: MFC: SECURITY UPDATE to nano-2.2.4 Resolves CVE-2010-1160 and CVE-2010-1161 ok naddy@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2010/06/25 22:15:19 Modified files: x11/gnome/tracker: Makefile distinfo Log message: Bugfix update to tracker-search-0.8.13.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2010/06/25 22:42:51 Modified files: x11/gnome/games: Makefile distinfo x11/gnome/games/pkg: PLIST Log message: Update to gnome-games-2.30.2. * minor fix-ups and translation updates
Tanit Newslettre juin 2010
Vous ne visualisez pas correctement cet email ? Cliquez-ici www.tshirt-personnalisation.fr Nouveau site : Avantages inidits ! - Plus de produits - Plus de services - Prix en baisse... Exemple: le t-shirt imprimi ` votre logo ` 1,63 * Personnalisations illimities par article ! LIVRAISON EXPRESS - Nous traitons votre commande en prioriti - Pour vos commandes d'articles non personnalisis : traitement prioritaire et expidition en express le jour mjme. - Pour vos commandes d'articles personnalisis : traitement prioritaire, personnalisation et expidition en express sous 5 jours ouvrables. ETIQUETTE PERSONNALISEE - Nous dicousons l'itiquette du fabricant de l'encolure et refermons la couture. - Nous apposons en transfert votre label ` l'intirieur du col, ainsi que les informations de composition et de conditions d'entretien. ACHATS DE GROS VOLUME - Possibiliti achat de gros volume. - Nous sommes les seuls ` proposer des prix de grossistes pour des commandes de ditail. - Apparition de nouvelles collections textile et objet. - Pour tous les articles, les prix sont en baisse. EMBALLAGE INDIVIDUEL - Notre service ensachage individuel vous garantit une prisentation parfaite et une meilleure mise en valeur de vos articles. Pratique pour le stockage, c'est aussi une attention appriciie lorsqu'il s'agit d'offrir un cadeau. Info : cont...@tanit-online.com - Til. : 03 200 200 20 * prix pour 1000 TS imprimis 1 couleur - Pour ne plus recevoir nos mails cliquez-ici [demime 1.01d removed an attachment of type image/jpeg which had a name of btn-jenprofite.jpg] [demime 1.01d removed an attachment of type image/jpeg which had a name of carton.jpg] [demime 1.01d removed an attachment of type image/jpeg which had a name of etiquette.jpg] [demime 1.01d removed an attachment of type image/jpeg which had a name of livreur.jpg] [demime 1.01d removed an attachment of type image/jpeg which had a name of logo-tanit.jpg] [demime 1.01d removed an attachment of type image/jpeg which had a name of patch-bleu.jpg] [demime 1.01d removed an attachment of type image/jpeg which had a name of sachet.jpg]
Re: seamonkey 2.0.5 / firefox 3.5.10
On Thu, Jun 24, 2010 at 04:54:09PM +0200, Landry Breuil wrote:
Hi,
another week, another pair of mozilla release... see
http://www.mozilla.org/security/known-vulnerabilities/seamonkey20.html#seamonkey2.0.5
http://www.mozilla.org/security/known-vulnerabilities/firefox35.html#firefox3.5.10
for the list of fixed MFSA.
While here, tweak WANTLIBs, switch www/firefox35 to use systemwide
nss/nspr as its brothers, and use newer ${SUBST_CMD} idioms.
Only built-tested on amd64 so if you use those ports, please test
those diffs.
Tested building and still running fine on ppc/sparc64, fwiw.
Landry
webkit 1.2.1
Hi,
here's the update to latest webkit-gtk. As usual, test in you random
configuration if you use it or one of the depending ports..
Landry
? libwebkit-1.0.so.2.1
? libwebkit-1.0.so.2.1-120
Index: Makefile
===
RCS file: /cvs/ports/www/webkit/Makefile,v
retrieving revision 1.29
diff -u -r1.29 Makefile
--- Makefile21 Jun 2010 15:55:33 - 1.29
+++ Makefile25 Jun 2010 07:13:38 -
@@ -2,10 +2,10 @@
COMMENT = open source web browser engine
-V = 1.2.0
+V = 1.2.1
DISTNAME = webkit-${V}
# XXX do not remove v0. pX comes before vX.
-PKGNAME = webkit-${V}p2v0
+PKGNAME = webkit-${V}v0
CATEGORIES = www
HOMEPAGE = http://webkitgtk.org/
@@ -53,10 +53,10 @@
::multimedia/gstreamer-0.10/plugins-good
WANTLIB = ICE SM X11 Xau Xcomposite Xcursor Xdamage Xdmcp Xext \
- Xfixes Xi Xinerama Xrandr Xrender Xt atk-1.0 c \
+ Xfixes Xi Xinerama Xrandr Xrender Xt atk-1.0 c xcb-render \
expat fontconfig freetype gcrypt gio-2.0 glib-2.0 glitz
gmodule-2.0 \
gnutls gobject-2.0 gpg-error gthread-2.0 intl jpeg m \
- pango-1.0 pangocairo-1.0 pangoft2-1.0 pcre pthread \
+ pango-1.0 pangocairo-1.0 pangoft2-1.0 pcre pthread
xcb-render-util \
tasn1 z cairo pixman-1 png pthread-stubs xcb xml2 ${STDCPPLIB}
LIB_DEPENDS =
gtk-x11-2.0,gdk-x11-2.0,gdk_pixbuf-2.0,gailutil::x11/gtk+2,-main \
Index: distinfo
===
RCS file: /cvs/ports/www/webkit/distinfo,v
retrieving revision 1.12
diff -u -r1.12 distinfo
--- distinfo22 Apr 2010 13:36:59 - 1.12
+++ distinfo25 Jun 2010 07:13:38 -
@@ -1,5 +1,5 @@
-MD5 (webkit-1.2.0.tar.gz) = sr/LxLvx0KUfhIy1TCHuZg==
-RMD160 (webkit-1.2.0.tar.gz) = EitA8tEDQGpC5TQPpmYngaDjVuI=
-SHA1 (webkit-1.2.0.tar.gz) = rJ23wlRx7tnQPqkM6hwLM3i21H4=
-SHA256 (webkit-1.2.0.tar.gz) = DOSSeJcIV9s3TTH9GDG/Qv+x3KR5fvOZEaltAdjF4fc=
-SIZE (webkit-1.2.0.tar.gz) = 7554632
+MD5 (webkit-1.2.1.tar.gz) = 629HPY175W7NIm591V3Lmw==
+RMD160 (webkit-1.2.1.tar.gz) = +MFYtn+839mXft1TDV+MFeQC2m0=
+SHA1 (webkit-1.2.1.tar.gz) = ztVkUU8L4KiMaW56/WkC2WfVMqI=
+SHA256 (webkit-1.2.1.tar.gz) = ye5VHqtOmHMPoGqqSTzpWCjmxmYewUNh5iVLwjeVot0=
+SIZE (webkit-1.2.1.tar.gz) = 7577236
Index: patches/patch-GNUmakefile_in
===
RCS file: /cvs/ports/www/webkit/patches/patch-GNUmakefile_in,v
retrieving revision 1.7
diff -u -r1.7 patch-GNUmakefile_in
--- patches/patch-GNUmakefile_in23 May 2010 10:27:46 - 1.7
+++ patches/patch-GNUmakefile_in25 Jun 2010 07:13:38 -
@@ -1,7 +1,7 @@
$OpenBSD: patch-GNUmakefile_in,v 1.7 2010/05/23 10:27:46 espie Exp $
install GtkLauncher, remove silent build lines, fix lpthread/pthread
GNUmakefile.in.origMon Apr 5 14:55:24 2010
-+++ GNUmakefile.in Wed Apr 21 15:32:34 2010
+--- GNUmakefile.in.origFri May 7 23:03:21 2010
GNUmakefile.in Thu Jun 24 18:04:00 2010
@@ -82,9 +82,9 @@ PRE_UNINSTALL = :
POST_UNINSTALL = :
build_triplet = @build@
@@ -14,7 +14,7 @@
$(am__EXEEXT_1)
# For the Gtk port we want to use XP_UNIX both in X11 and Mac
-@@ -5877,7 +5877,7 @@ COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES
+@@ -5895,7 +5895,7 @@ COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES
$(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
AM_V_CC = $(am__v_CC_$(V))
am__v_CC_ = $(am__v_CC_$(AM_DEFAULT_VERBOSITY))
@@ -23,7 +23,7 @@
AM_V_at = $(am__v_at_$(V))
am__v_at_ = $(am__v_at_$(AM_DEFAULT_VERBOSITY))
am__v_at_0 = @
-@@ -5887,22 +5887,22 @@ LINK = $(LIBTOOL) $(AM_V_lt) --tag=CC $(AM_LIBTOOLFLAG
+@@ -5905,22 +5905,22 @@ LINK = $(LIBTOOL) $(AM_V_lt) --tag=CC $(AM_LIBTOOLFLAG
$(AM_LDFLAGS) $(LDFLAGS) -o $@
AM_V_CCLD = $(am__v_CCLD_$(V))
am__v_CCLD_ = $(am__v_CCLD_$(AM_DEFAULT_VERBOSITY))
@@ -50,7 +50,7 @@
SOURCES = $(TestNetscapePlugin_libtestnetscapeplugin_la_SOURCES) \
$(libJavaScriptCore_la_SOURCES) \
$(nodist_libJavaScriptCore_la_SOURCES) \
-@@ -8956,9 +8956,10 @@ libJavaScriptCore_la_SOURCES = \
+@@ -8976,9 +8976,10 @@ libJavaScriptCore_la_SOURCES = \
libJavaScriptCore_la_LIBADD = \
$(UNICODE_LIBS) \
@@ -63,7 +63,7 @@
libJavaScriptCore_la_CXXFLAGS = \
$(global_cxxflags) \
$(libJavaScriptCore_la_CFLAGS)
-@@ -9007,12 +9008,12 @@ libwebkit_1_0_la_CPPFLAGS = \
+@@ -9027,12 +9028,12 @@ libwebkit_1_0_la_CPPFLAGS = \
$(HILDON_CPPFLAGS)
libwebkit_1_0_la_LDFLAGS = \
@@ -77,7 +77,7 @@
libJavaScriptCore.la \
libWebCoreJS.la \
$(webcore_ldflags) \
-@@ -9074,7 +9075,7 @@ Programs_minidom_CFLAGS = \
+@@ -9094,7 +9095,7 @@ Programs_minidom_CFLAGS = \
Programs_minidom_LDADD = \
libJavaScriptCore.la \
-lm \
Index: pkg/PLIST
Re: hunspell segfaults
On Fri, Jun 25, 2010 at 07:49:25AM +0200, Antoine Jacoutot wrote:
post-install:
+ echo LOCALBSE = ${LOCALBASE}
???
Debug junk, I forgot to remove.
-+#!${LOCALBASE}/bin/bash
++#!/usr/local/bin/bash
Are you re-hardcoding /usr/local here?
If so, don't.
Not intentionally. Looks like a ran 'make update-patches' at the wrong time.
I will make a new diff - sorry, that sucked.
--
Best Regards
Edd Barrett
http://www.theunixzoo.co.uk
Re: hunspell segfaults
On Fri, Jun 25, 2010 at 09:03:22 +0100, Edd Barrett wrote: On Fri, Jun 25, 2010 at 07:49:25AM +0200, Antoine Jacoutot wrote: Not intentionally. Looks like a ran 'make update-patches' at the wrong time. I will make a new diff - sorry, that sucked. Nevertheless I've tested it, and it doesn't segfault when specifying a file to check. Only thing I've noticed so far is when I use the Hungarian dictionary from the mozzila-dicts-hu package, hunspell writes these messages: $ hunspell -d hu textfile error: line 214289: bad flagvector error: line 214290: bad flagvector error: line 214291: bad flagvector error: line 214292: bad flagvector error: line 214293: bad flagvector error: line 214294: bad flagvector error: line 214295: bad flagvector error: line 214296: bad flagvector error: line 215652: bad flagvector error: line 215653: bad flagvector error: line 215654: bad flagvector error: line 215655: bad flagvector error: line 215656: bad flagvector error: line 215657: bad flagvector error: line 215658: bad flagvector error: line 215659: bad flagvector error: line 222749: bad flagvector error: line 222750: bad flagvector error: line 222751: bad flagvector error: line 222752: bad flagvector error: line 222753: bad flagvector error: line 222754: bad flagvector error: line 222755: bad flagvector error: line 222756: bad flagvector error: line 222996: bad flagvector error: line 222997: bad flagvector error: line 222998: bad flagvector error: line 222999: bad flagvector error: line 223000: bad flagvector error: line 223001: bad flagvector error: line 223002: bad flagvector error: line 223003: bad flagvector error: line 223004: bad flagvector error: line 223005: bad flagvector error: line 223006: bad flagvector error: line 223007: bad flagvector error: line 224136: bad flagvector error: line 224137: bad flagvector error: line 224138: bad flagvector error: line 224139: bad flagvector error: line 224140: bad flagvector error: line 224141: bad flagvector error: line 224142: bad flagvector error: line 224143: bad flagvector error: line 246317: bad flagvector Using any other dictionary don't produce messages. Daniel -- LÉVAI Dániel PGP key ID = 0x83B63A8F Key fingerprint = DBEC C66B A47A DFA2 792D 650C C69B BE4C 83B6 3A8F
Re: hunspell segfaults
On Fri, 25 Jun 2010, LEVAI Daniel wrote: On Fri, Jun 25, 2010 at 09:03:22 +0100, Edd Barrett wrote: On Fri, Jun 25, 2010 at 07:49:25AM +0200, Antoine Jacoutot wrote: Not intentionally. Looks like a ran 'make update-patches' at the wrong time. I will make a new diff - sorry, that sucked. Nevertheless I've tested it, and it doesn't segfault when specifying a file to check. Only thing I've noticed so far is when I use the Hungarian dictionary from the mozzila-dicts-hu package, hunspell writes these messages: $ hunspell -d hu textfile error: line 214289: bad flagvector error: line 214290: bad flagvector Don't worry, it's just gipsy talk. error: line 214291: bad flagvector error: line 214292: bad flagvector error: line 214293: bad flagvector error: line 214294: bad flagvector error: line 214295: bad flagvector error: line 214296: bad flagvector error: line 215652: bad flagvector error: line 215653: bad flagvector error: line 215654: bad flagvector error: line 215655: bad flagvector error: line 215656: bad flagvector error: line 215657: bad flagvector error: line 215658: bad flagvector error: line 215659: bad flagvector error: line 222749: bad flagvector error: line 222750: bad flagvector error: line 222751: bad flagvector error: line 222752: bad flagvector error: line 222753: bad flagvector error: line 222754: bad flagvector error: line 222755: bad flagvector error: line 222756: bad flagvector error: line 222996: bad flagvector error: line 222997: bad flagvector error: line 222998: bad flagvector error: line 222999: bad flagvector error: line 223000: bad flagvector error: line 223001: bad flagvector error: line 223002: bad flagvector error: line 223003: bad flagvector error: line 223004: bad flagvector error: line 223005: bad flagvector error: line 223006: bad flagvector error: line 223007: bad flagvector error: line 224136: bad flagvector error: line 224137: bad flagvector error: line 224138: bad flagvector error: line 224139: bad flagvector error: line 224140: bad flagvector error: line 224141: bad flagvector error: line 224142: bad flagvector error: line 224143: bad flagvector error: line 246317: bad flagvector Using any other dictionary don't produce messages. Daniel -- Antoine
Re: hunspell segfaults
On Fri, Jun 25, 2010 at 10:31:20AM +0200, LEVAI Daniel wrote:
On Fri, Jun 25, 2010 at 09:03:22 +0100, Edd Barrett wrote:
On Fri, Jun 25, 2010 at 07:49:25AM +0200, Antoine Jacoutot wrote:
Not intentionally. Looks like a ran 'make update-patches' at the wrong time.
I will make a new diff - sorry, that sucked.
Nevertheless I've tested it, and it doesn't segfault when specifying a
file to check.
OK Good.
Only thing I've noticed so far is when I use the Hungarian dictionary
from the mozzila-dicts-hu package, hunspell writes these messages:
$ hunspell -d hu textfile
error: line 214289: bad flagvector
I don't know what this means, but will take a look. Do you have any idea aja?
In the meanwhile, here is a new diff with aja's observations corrected:
Index: Makefile
===
RCS file: /cvs/ports/textproc/hunspell/Makefile,v
retrieving revision 1.2
diff -u -p -u -r1.2 Makefile
--- Makefile11 Oct 2009 14:06:20 - 1.2
+++ Makefile25 Jun 2010 08:57:53 -
@@ -2,8 +2,7 @@
COMMENT = spelling, stemming, morphological analysis and generation
-DISTNAME = hunspell-1.2.8
-PKGNAME = ${DISTNAME}p0
+DISTNAME = hunspell-1.2.11
SHARED_LIBS = hunspell-1.20.0 # .0.0
@@ -27,7 +26,7 @@ MODULES = devel/gettext
CONFIGURE_STYLE = gnu
CONFIGURE_ENV= CPPFLAGS=-I${LOCALBASE}/include \
- LDFLAGS=-L${LOCALBASE}/lib
+ LDFLAGS=-L${LOCALBASE}/lib
-L${WRKBUILD}/src/hunspell/.libs
CONFIGURE_ARGS = ${CONFIGURE_SHARED} \
--with-ui \
--with-readline
Index: distinfo
===
RCS file: /cvs/ports/textproc/hunspell/distinfo,v
retrieving revision 1.1.1.1
diff -u -p -u -r1.1.1.1 distinfo
--- distinfo13 Jun 2009 07:48:53 - 1.1.1.1
+++ distinfo25 Jun 2010 08:57:53 -
@@ -1,5 +1,5 @@
-MD5 (hunspell-1.2.8.tar.gz) = EXevVKCeMg0sJAFfKcOpPg==
-RMD160 (hunspell-1.2.8.tar.gz) = 5P055frfltoTEfKqcWPsF+rPD4M=
-SHA1 (hunspell-1.2.8.tar.gz) = 6qdvgvzwhnjkn3owr9qiaLzHUjU=
-SHA256 (hunspell-1.2.8.tar.gz) = r1Y+E2RmIOYIBStGl04Q0Pw+TUixuZb5dxy/rG38PDg=
-SIZE (hunspell-1.2.8.tar.gz) = 784360
+MD5 (hunspell-1.2.11.tar.gz) = j1fNxNsJHWnh9oLtTYqygg==
+RMD160 (hunspell-1.2.11.tar.gz) = +meiQTGouk2c39W07Pucco+D/iM=
+SHA1 (hunspell-1.2.11.tar.gz) = CvfPk6mRR5BwW2cEZNL5WkvqY0E=
+SHA256 (hunspell-1.2.11.tar.gz) = P5dcBW4OiIOzjr518Eoy45g+qdlRr6A1GBgGsHDQbpM=
+SIZE (hunspell-1.2.11.tar.gz) = 926658
Index: patches/patch-man_hu_hunspell_1
===
RCS file: /cvs/ports/textproc/hunspell/patches/patch-man_hu_hunspell_1,v
retrieving revision 1.1.1.1
diff -u -p -u -r1.1.1.1 patch-man_hu_hunspell_1
--- patches/patch-man_hu_hunspell_1 13 Jun 2009 07:48:53 - 1.1.1.1
+++ patches/patch-man_hu_hunspell_1 25 Jun 2010 08:57:53 -
@@ -1,6 +1,6 @@
$OpenBSD: patch-man_hu_hunspell_1,v 1.1.1.1 2009/06/13 07:48:53 ajacoutot Exp $
man/hu/hunspell.1.orig Mon May 26 11:42:10 2008
-+++ man/hu/hunspell.1 Fri Jun 5 20:41:01 2009
+--- man/hu/hunspell.1.orig Tue Feb 23 09:08:52 2010
man/hu/hunspell.1 Fri Jun 25 09:56:36 2010
@@ -65,12 +65,12 @@ a javaslattevést). Az elsŠszótár mindig alapszót
.PP
Az alapértelmezett szótár a környezet nyelvi beállÃtásától fÃŒgg
Index: patches/patch-man_hunspell_1
===
RCS file: /cvs/ports/textproc/hunspell/patches/patch-man_hunspell_1,v
retrieving revision 1.1.1.1
diff -u -p -u -r1.1.1.1 patch-man_hunspell_1
--- patches/patch-man_hunspell_113 Jun 2009 07:48:53 - 1.1.1.1
+++ patches/patch-man_hunspell_125 Jun 2010 08:57:53 -
@@ -1,10 +1,10 @@
-$OpenBSD: patch-man_hunspell_1,v 1.1.1.1 2009/06/13 07:48:53 ajacoutot Exp $
man/hunspell.1.origFri Jun 5 20:03:16 2009
-+++ man/hunspell.1 Fri Jun 5 20:04:20 2009
-@@ -360,10 +360,10 @@ Dictionary path.
- Equivalent to
- .I \-p.
- .SH FILES
+$OpenBSD$
+--- man/hunspell.1.origThu Jun 24 20:23:47 2010
man/hunspell.1 Thu Jun 24 20:24:53 2010
+@@ -366,10 +366,10 @@ following environment variables are searched: LC_ALL,
+ LC_MESSAGES, and LANG. If none are set then the following
+ fallbacks are used:
+
-.BI /usr/share/myspell/default.aff
+.BI ${PREFIX}/share/myspell/default.aff
Path of default affix file. See hunspell(4).
Index: patches/patch-src_tools_hunspell_cxx
===
RCS file: /cvs/ports/textproc/hunspell/patches/patch-src_tools_hunspell_cxx,v
retrieving revision 1.1.1.1
diff -u -p -u -r1.1.1.1 patch-src_tools_hunspell_cxx
--- patches/patch-src_tools_hunspell_cxx13 Jun 2009 07:48:53 -
1.1.1.1
+++ patches/patch-src_tools_hunspell_cxx25 Jun 2010 08:57:53 -
Re: [flashrom] Porting flashrom to OpenBSD
Hi Jonathan, you're in CC of this mail because you sent the unbreak pciutils mail to this list, and the failure mode is related. http://marc.info/?l=openbsd-portsm=126918139214769 On 25.06.2010 01:30, Stuart Henderson wrote: On 2010/06/25 00:21, Stuart Henderson wrote: On 2010/06/22 04:02, Carl-Daniel Hailfinger wrote: I added a few fixups to the flashrom tree in the meantime to get the OpenBSD patch size down a bit. After all, if it gets easier for you to test, we all win. Stuart, if this works for you, I'll commit the patches into flashrom subversion ASAP. My stated goal is to support every OS without the need for any local patches. A good first step to check if flashrom could run on your system is to run lspci. You may have to set machdep.allowaperture=2 and possibly other settings to get it working. flashrom uses raw memory access (/dev/mem), raw x86 port access (via inb/outb functions) and PCI access (via libpci). Port attached and at http://spacehopper.org/flashrom.tgz; this is basically your patches with a typo fixed (missing ; in the Makefile). Right, my bad. Thanks. You can see exampkle output from an unsuccessful run on amd64 attempting to dump rom contents at http://spacehopper.org/flashrom.txt Excerpt from that log: pcilib: obsd_write: ioctl(PCIOCWRITE) failed Ouch. I remember a pciutils patch on the ports mailing list which may be related to this: http://marc.info/?l=openbsd-portsm=126918139214769 flashrom uses libpci from pciutils, and it absolutely _must_ have write access to PCI. Port at http://spacehopper.org/flashrom.tgz is updated (add dmidedode as a RUN_DEPENDS and tidy the Makefile). Thanks, looks good. One small comment about installation in sbin, though. flashrom can also work with programmers attached to serial ports and USB, and those might work even for non-root users if appropriate permissions are set (well, under most Unix-like OS, but OpenBSD might be different). Due to that, some people think installing in bin instead of sbin makes more sense. Stuart, does the pcilib abort happen on i386 and amd64? Regards, Carl-Daniel -- http://www.hailfinger.org/
Re: UPDATE: www/py-genshi, www/trac
Stuart Henderson wrote:
Is anyone able to test the trac update with trac-ldapplugin?
(the Genshi update is committed now).
On 2010/06/14 15:36, Stuart Henderson wrote:
The new version of Trac needs new Genshi (included; Trac is the
only thing in ports using this at the moment).
For Trac you will have to do the usual database upgrade;
'trac-admin /path/to/projenv upgrade' (this is also displayed
when you connect without upgrading). You're also advised to
upgrade the wiki pages and resync repo's as described at
http://trac.edgewall.org/wiki/TracUpgrade
Any comments/ok's?
Index: trac/Makefile
===
RCS file: /cvs/ports/www/trac/Makefile,v
retrieving revision 1.25
diff -u -p -r1.25 Makefile
--- trac/Makefile 20 Mar 2010 23:53:56 - 1.25
+++ trac/Makefile 14 Jun 2010 14:27:16 -
@@ -2,7 +2,7 @@
COMMENT= wiki and bug tracking system for software projects
-MODPY_EGG_VERSION=0.11.7
+MODPY_EGG_VERSION=0.12
DISTNAME= Trac-${MODPY_EGG_VERSION}
PKGNAME= trac-${MODPY_EGG_VERSION}
CATEGORIES=www devel
@@ -30,7 +30,7 @@ RUN_DEPENDS= ::databases/py-sqlite2 \
::textproc/py-docutils \
::textproc/py-pygments \
:clearsilver-*-python:www/clearsilver,python \
- ::www/py-genshi
+ :py-genshi-=0.6:www/py-genshi
do-regress:
@cd ${WRKSRC} PYTHONPATH=. ${MODPY_BIN} ./trac/test.py
Index: trac/distinfo
===
RCS file: /cvs/ports/www/trac/distinfo,v
retrieving revision 1.12
diff -u -p -r1.12 distinfo
--- trac/distinfo 20 Mar 2010 23:53:56 - 1.12
+++ trac/distinfo 14 Jun 2010 14:27:16 -
@@ -1,5 +1,5 @@
-MD5 (Trac-0.11.7.tar.gz) = PNltrQ5PJdl3xCL9bphemQ==
-RMD160 (Trac-0.11.7.tar.gz) = 1VzGCV8A30c2tncWNAWzHN0oU0E=
-SHA1 (Trac-0.11.7.tar.gz) = Cht1bKWA7KrH52Ux6AiQcouXYSI=
-SHA256 (Trac-0.11.7.tar.gz) = xq+MyfoMuP10YRiW5GpDbO+WYLd74ZcqmbDT3biUIy8=
-SIZE (Trac-0.11.7.tar.gz) = 757073
+MD5 (Trac-0.12.tar.gz) = Po+ruvj+iJ6cA6ff8J1dBQ==
+RMD160 (Trac-0.12.tar.gz) = rKjQJKWCUZzv7wcFNRfRRyL4dgk=
+SHA1 (Trac-0.12.tar.gz) = 8TpcryqzUySPaW3FMg33onwQLgY=
+SHA256 (Trac-0.12.tar.gz) = ocFcDDoMcX5tUNTk+Um46MUQowhhEBPEXGJTxnXoBc8=
+SIZE (Trac-0.12.tar.gz) = 2107428
Index: trac/pkg/PLIST
===
RCS file: /cvs/ports/www/trac/pkg/PLIST,v
retrieving revision 1.7
diff -u -p -r1.7 PLIST
--- trac/pkg/PLIST 4 Dec 2009 12:12:32 - 1.7
+++ trac/pkg/PLIST 14 Jun 2010 14:27:16 -
@@ -9,9 +9,9 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/Trac-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/SOURCES.txt
lib/python${MODPY_VERSION}/site-packages/Trac-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/dependency_links.txt
lib/python${MODPY_VERSION}/site-packages/Trac-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/entry_points.txt
-lib/python${MODPY_VERSION}/site-packages/Trac-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/not-zip-safe
lib/python${MODPY_VERSION}/site-packages/Trac-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/requires.txt
lib/python${MODPY_VERSION}/site-packages/Trac-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/top_level.txt
+lib/python${MODPY_VERSION}/site-packages/Trac-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/zip-safe
lib/python${MODPY_VERSION}/site-packages/trac/
lib/python${MODPY_VERSION}/site-packages/trac/__init__.py
lib/python${MODPY_VERSION}/site-packages/trac/__init__.pyc
@@ -42,6 +42,8 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/trac/admin/web_ui.pyc
lib/python${MODPY_VERSION}/site-packages/trac/attachment.py
lib/python${MODPY_VERSION}/site-packages/trac/attachment.pyc
+lib/python${MODPY_VERSION}/site-packages/trac/cache.py
+lib/python${MODPY_VERSION}/site-packages/trac/cache.pyc
lib/python${MODPY_VERSION}/site-packages/trac/config.py
lib/python${MODPY_VERSION}/site-packages/trac/config.pyc
lib/python${MODPY_VERSION}/site-packages/trac/core.py
@@ -105,12 +107,15 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/trac/htdocs/feed.png
lib/python${MODPY_VERSION}/site-packages/trac/htdocs/file.png
lib/python${MODPY_VERSION}/site-packages/trac/htdocs/folder.png
+lib/python${MODPY_VERSION}/site-packages/trac/htdocs/grip.png
lib/python${MODPY_VERSION}/site-packages/trac/htdocs/guide/
lib/python${MODPY_VERSION}/site-packages/trac/htdocs/guide/basic-workflow.png
lib/python${MODPY_VERSION}/site-packages/trac/htdocs/guide/original-workflow.png
lib/python${MODPY_VERSION}/site-packages/trac/htdocs/ics.png
lib/python${MODPY_VERSION}/site-packages/trac/htdocs/imggrid.png
lib/python${MODPY_VERSION}/site-packages/trac/htdocs/js/
+lib/python${MODPY_VERSION}/site-packages/trac/htdocs/js/auto_preview.js
Re: [NEW] saxon-java
Updated version of saxon 6.5.5 with `saxon-xslt' wrapper (inspired from Debian). Works fine, if you don't mind then commit please. Thanks jirib $ pkg_info saxon-java Information for inst:saxon-java-6.5.5p6 Comment: Michael H. Kay's Java XSLT processor Description: The SAXON package is a collection of tools for processing XML documents. The main components are: * An XSLT processor, which implements the Version 1.0 XSLT and XPath Recommendations from the World Wide Web Consortium. This version of Saxon also includes some features defined in XSLT 1.1. * A Java library, which supports a similar processing model to XSL, but allows full programming capability, which you need if you want to perform complex processing of the data or to access external services such as a relational database * A slightly improved version of the AElfred parser from Microstar. (But you can use SAXON with any SAX-compliant XML parser if you prefer). Saxon is distributed under the terms of the Mozilla Public License (MPL). Maintainer: The OpenBSD ports mailing-list ports@openbsd.org WWW: http://saxon.sourceforge.net/ Install notice: To process with Saxon, issue a command like the following (all on one line): saxon-xslt file.xml stylesheet.xsl See the html docs for more details. saxon-java-6.5.5p6.tgz Description: application/compressed-tar
wine core dumps
Hello, wine-1.1.21p1 core dumps on -current, it's not able to run at all. It has been reported here some time ago: http://bugs.winehq.org/show_bug.cgi?id=1 So is this normal behaviour? Any progress? jirib
Re: [flashrom] Porting flashrom to OpenBSD
On 2010/06/25 11:57, Carl-Daniel Hailfinger wrote:
Hi Jonathan,
you're in CC of this mail because you sent the unbreak pciutils mail
to this list, and the failure mode is related.
http://marc.info/?l=openbsd-portsm=126918139214769
Hmmm... So why is PCIOCWRITE failing, even when securelevel is 0 and
allowaperture=2...
I don't know this area at all well, but this looks worth investigating
/sys/dev/pci/pci.c
case PCIOCWRITE:
io = (struct pci_io *)data;
switch (io-pi_width) {
case 4:
/* Make sure the register is properly aligned */
if (io-pi_reg 0x3)
return EINVAL;
pci_conf_write(pc, tag, io-pi_reg, io-pi_data);
error = 0;
break;
default:
error = ENODEV;
break;
}
break;
Thanks, looks good. One small comment about installation in sbin,
though. flashrom can also work with programmers attached to serial ports
and USB, and those might work even for non-root users if appropriate
permissions are set (well, under most Unix-like OS, but OpenBSD might be
different). Due to that, some people think installing in bin instead of
sbin makes more sense.
I don't think the location is a problem..
Stuart, does the pcilib abort happen on i386 and amd64?
I don't have an i386 box handy to try at the moment.
As an aside, anyone know why securelevel gets set to 1 after
booting (despite the setting in rc.securelevel)?
Re: [flashrom] Porting flashrom to OpenBSD
you're in CC of this mail because you sent the unbreak pciutils mail
to this list, and the failure mode is related.
http://marc.info/?l=openbsd-portsm=126918139214769
Hmmm... So why is PCIOCWRITE failing, even when securelevel is 0 and
allowaperture=2...
I don't know this area at all well, but this looks worth investigating
/sys/dev/pci/pci.c
case PCIOCWRITE:
io = (struct pci_io *)data;
switch (io-pi_width) {
case 4:
/* Make sure the register is properly aligned */
if (io-pi_reg 0x3)
return EINVAL;
pci_conf_write(pc, tag, io-pi_reg, io-pi_data);
error = 0;
break;
default:
error = ENODEV;
break;
}
break;
Thanks, looks good. One small comment about installation in sbin,
though. flashrom can also work with programmers attached to serial ports
and USB, and those might work even for non-root users if appropriate
permissions are set (well, under most Unix-like OS, but OpenBSD might be
different). Due to that, some people think installing in bin instead of
sbin makes more sense.
I don't think the location is a problem..
Stuart, does the pcilib abort happen on i386 and amd64?
I don't have an i386 box handy to try at the moment.
The aperture is for X. Only one use at a time is permitted.
Re-using the aperture like this is a mistake. In time, if the X
server support for kernel mode setting, the aperture will largely go
away, or at least have the hole shrunk.
Again -- reusing the aperture for this is a mistake. Sorry. What
X does on PC's is totally wrong, and more things don't need to make
the same mistake.
As an aside, anyone know why securelevel gets set to 1 after
booting (despite the setting in rc.securelevel)?
To protect the machine.
Re: [flashrom] Porting flashrom to OpenBSD
On 2010/06/25 08:32, Theo de Raadt wrote:
you're in CC of this mail because you sent the unbreak pciutils mail
to this list, and the failure mode is related.
http://marc.info/?l=openbsd-portsm=126918139214769
Hmmm... So why is PCIOCWRITE failing, even when securelevel is 0 and
allowaperture=2...
I don't know this area at all well, but this looks worth investigating
/sys/dev/pci/pci.c
case PCIOCWRITE:
io = (struct pci_io *)data;
switch (io-pi_width) {
case 4:
/* Make sure the register is properly aligned */
if (io-pi_reg 0x3)
return EINVAL;
pci_conf_write(pc, tag, io-pi_reg, io-pi_data);
error = 0;
break;
default:
error = ENODEV;
break;
}
break;
Thanks, looks good. One small comment about installation in sbin,
though. flashrom can also work with programmers attached to serial ports
and USB, and those might work even for non-root users if appropriate
permissions are set (well, under most Unix-like OS, but OpenBSD might be
different). Due to that, some people think installing in bin instead of
sbin makes more sense.
I don't think the location is a problem..
Stuart, does the pcilib abort happen on i386 and amd64?
I don't have an i386 box handy to try at the moment.
The aperture is for X. Only one use at a time is permitted.
I should have mentioned, this was single-user.
Re: [flashrom] Porting flashrom to OpenBSD
On 2010/06/25 08:32, Theo de Raadt wrote:
you're in CC of this mail because you sent the unbreak pciutils mail
to this list, and the failure mode is related.
http://marc.info/?l=openbsd-portsm=126918139214769
Hmmm... So why is PCIOCWRITE failing, even when securelevel is 0 and
allowaperture=2...
I don't know this area at all well, but this looks worth investigating
/sys/dev/pci/pci.c
case PCIOCWRITE:
io = (struct pci_io *)data;
switch (io-pi_width) {
case 4:
/* Make sure the register is properly aligned */
if (io-pi_reg 0x3)
return EINVAL;
pci_conf_write(pc, tag, io-pi_reg, io-pi_data);
error = 0;
break;
default:
error = ENODEV;
break;
}
break;
Thanks, looks good. One small comment about installation in sbin,
though. flashrom can also work with programmers attached to serial ports
and USB, and those might work even for non-root users if appropriate
permissions are set (well, under most Unix-like OS, but OpenBSD might be
different). Due to that, some people think installing in bin instead of
sbin makes more sense.
I don't think the location is a problem..
Stuart, does the pcilib abort happen on i386 and amd64?
I don't have an i386 box handy to try at the moment.
The aperture is for X. Only one use at a time is permitted.
I should have mentioned, this was single-user.
The aperture is for X.
kill pkg_info -l
Is anyone actually using pkg_info -l ? It's an annoying flag that's not even implemented consistently, and I would like to actually kill it.
Re: [flashrom] Porting flashrom to OpenBSD
On Fri, Jun 25, 2010 at 03:25:10PM +0100, Stuart Henderson wrote: On 2010/06/25 11:57, Carl-Daniel Hailfinger wrote: Hi Jonathan, you're in CC of this mail because you sent the unbreak pciutils mail to this list, and the failure mode is related. http://marc.info/?l=openbsd-portsm=126918139214769 Hmmm... So why is PCIOCWRITE failing, even when securelevel is 0 and allowaperture=2... Probably because you do un-aligned PCI config space access. Our /dev/pci only supports 32 bit wide read/write, aligned on 4 bytes boundaries. The rest of the discussion about not abusing the aperture driver for this also stays. If you need to write to PCI config space, you'll need a separate kernel interface, with a high-level interface, so that you don't allow random changes in the PCI config space from userland. -- Matthieu Herrb
Re: [flashrom] Porting flashrom to OpenBSD
On 25.06.2010 16:44, Theo de Raadt wrote:
On 2010/06/25 08:32, Theo de Raadt wrote:
you're in CC of this mail because you sent the unbreak pciutils mail
to this list, and the failure mode is related.
http://marc.info/?l=openbsd-portsm=126918139214769
Hmmm... So why is PCIOCWRITE failing, even when securelevel is 0 and
allowaperture=2...
I don't know this area at all well, but this looks worth investigating
/sys/dev/pci/pci.c
case PCIOCWRITE:
io = (struct pci_io *)data;
switch (io-pi_width) {
case 4:
/* Make sure the register is properly aligned */
if (io-pi_reg 0x3)
return EINVAL;
pci_conf_write(pc, tag, io-pi_reg, io-pi_data);
error = 0;
break;
default:
error = ENODEV;
break;
}
break;
Thanks, looks good. One small comment about installation in sbin,
though. flashrom can also work with programmers attached to serial ports
and USB, and those might work even for non-root users if appropriate
permissions are set (well, under most Unix-like OS, but OpenBSD might be
different). Due to that, some people think installing in bin instead of
sbin makes more sense.
I don't think the location is a problem..
Stuart, does the pcilib abort happen on i386 and amd64?
I don't have an i386 box handy to try at the moment.
The aperture is for X. Only one use at a time is permitted.
I should have mentioned, this was single-user.
The aperture is for X.
I think I should clarify a bit what flashrom (BIOS/EFI/optionROM
flasher) does/needs.
PCI config space writes (usually only to the PCI-LPC bridge) are
needed to tell that bridge to enable pass through for flash chip accesses.
I/O port access is needed on some chipsets which have the passthrough
enable in I/O space instead of PCI config space.
Raw memory access is needed to the top 16 MB of the 32bit address space
because that's where the BIOS flash ROM chip is mapped on i386/amd64,
and to access the SPI flash ROM controller MMIO regions (somewhere in
the address space, needs to be determined from PCI config space
registers) on most chipsets released in the last 4 years.
flashrom accesses PCI config space read/write via pciutils/libpci which
uses /dev/pci AFAICS. The problem flashrom has right now is that PCI
config writes via /dev/pci don't work. Without PCI config space write
access, everything else is sort of pointless (you won't have access to
the flash chip).
Some people use flashrom to read out the flash chip and check it for
malware, and I heard that's one of the motivations (well, besides BIOS
updates) for trying to get it working on OpenBSD.
Regards,
Carl-Daniel
Re: [flashrom] Porting flashrom to OpenBSD
I think I should clarify a bit what flashrom (BIOS/EFI/optionROM flasher) does/needs. PCI config space writes (usually only to the PCI-LPC bridge) are needed to tell that bridge to enable pass through for flash chip accesses. I/O port access is needed on some chipsets which have the passthrough enable in I/O space instead of PCI config space. Raw memory access is needed to the top 16 MB of the 32bit address space because that's where the BIOS flash ROM chip is mapped on i386/amd64, and to access the SPI flash ROM controller MMIO regions (somewhere in the address space, needs to be determined from PCI config space registers) on most chipsets released in the last 4 years. flashrom accesses PCI config space read/write via pciutils/libpci which uses /dev/pci AFAICS. The problem flashrom has right now is that PCI config writes via /dev/pci don't work. Without PCI config space write access, everything else is sort of pointless (you won't have access to the flash chip). I understand very well what you are trying to do. But it is the kernel's job to protect the hardware from all manner of direct access. Even essentially in single user mode. Now it is an accident of history that X is so terribly designed. It is currently accepted that this is so, and that's too bad, so there is a hole for X. There's a 10+ year effort to improve X so that this hole can go away. When it does, stuff like your code will stop working. Unix is designed to hide the hardware, to protect the hardware, and it does this by providing and using highly abstracted interfaces. What you are trying to do is get around Unix. Some people use flashrom to read out the flash chip and check it for malware, and I heard that's one of the motivations (well, besides BIOS updates) for trying to get it working on OpenBSD. I don't buy any of that stuff. By the time this has happened, you're already hosed.
Re: [flashrom] Porting flashrom to OpenBSD
Theo de Raadt wrote: I should have mentioned, this was single-user. The aperture is for X. But it's not opening /dev/xf86 or /dev/drm, it's playing around with /dev/pci via libpci.. and writes always fail, even in single-user. -Bryan.
UPDATE: mail/courier-imap
Update to Courier-imap 4.8.0, comments ? ok ?
Cheers
Giovanni Bechis
Index: Makefile
===
RCS file: /cvs/ports/mail/courier-imap/Makefile,v
retrieving revision 1.59
diff -u -p -r1.59 Makefile
--- Makefile21 Apr 2010 07:18:25 - 1.59
+++ Makefile25 Jun 2010 14:15:53 -
@@ -3,7 +3,7 @@
COMMENT-main= imap server for maildir format mailboxes
COMMENT-pop3= pop3 server for maildir format mailboxes
-V= 4.7.0
+V= 4.8.0
DISTNAME= courier-imap-${V}
PKGNAME-main= ${DISTNAME}
FULLPKGNAME-pop3= courier-pop3-${V}
@@ -33,7 +33,8 @@ CONFIGURE_ENV=LDFLAGS=-L${LOCALBASE}/
CXXFLAGS=-I${LOCALBASE}/include \
CPPFLAGS=-I${LOCALBASE}/include
-LIB_DEPENDS=
courierauthsasl.=0,courierauth.=0::mail/courier-authlib
+LIB_DEPENDS=
courierauthsasl.=0,courierauth.=0::mail/courier-authlib \
+ idn::devel/libidn
COURIERSTATE= /var/run/courier
EXAMPLE_DIR= ${PREFIX}/share/examples/courier
@@ -90,6 +91,8 @@ MULTI_PACKAGES= -main -pop3
LIB_DEPENDS-main= ${LIB_DEPENDS} \
gdbm.=3::databases/gdbm
WANTLIB-main= ${WANTLIB} ssl crypto
+MODULES= converters/libiconv \
+ devel/gettext
CNFFILES= etc/courier/imapd-ssl.dist etc/courier/imapd.dist \
etc/courier/pop3d-ssl.dist etc/courier/pop3d.dist \
Index: distinfo
===
RCS file: /cvs/ports/mail/courier-imap/distinfo,v
retrieving revision 1.12
diff -u -p -r1.12 distinfo
--- distinfo21 Apr 2010 07:18:25 - 1.12
+++ distinfo25 Jun 2010 14:15:53 -
@@ -1,5 +1,5 @@
-MD5 (courier-imap-4.7.0.tar.bz2) = 5phIkOGuzzzGsJmhYZMk5g==
-RMD160 (courier-imap-4.7.0.tar.bz2) = KrF2j7dxTP4pHtzADJbMJ2rxJ4I=
-SHA1 (courier-imap-4.7.0.tar.bz2) = lynzrdhpJWOGXaUWfP6I8iJ8OWg=
-SHA256 (courier-imap-4.7.0.tar.bz2) =
oKms7ns2OZ0iZmrFruIsvF21KZagd5HgM78fe643C58=
-SIZE (courier-imap-4.7.0.tar.bz2) = 3414328
+MD5 (courier-imap-4.8.0.tar.bz2) = h8UB5l6uedZntRI99q6J8g==
+RMD160 (courier-imap-4.8.0.tar.bz2) = z8C+7GiTwVXPlxLZIAAjIBaa0MU=
+SHA1 (courier-imap-4.8.0.tar.bz2) = 9ojOqHxmGBNiYizpy9RxDXUmjPw=
+SHA256 (courier-imap-4.8.0.tar.bz2) =
7HURpDmJIKBPO7YM8SCOKamlQyuu/001ak7BQhE7+/I=
+SIZE (courier-imap-4.8.0.tar.bz2) = 3362734
Index: patches/patch-imap_courierpop3d_8_in
===
RCS file: patches/patch-imap_courierpop3d_8_in
diff -N patches/patch-imap_courierpop3d_8_in
--- patches/patch-imap_courierpop3d_8_in21 Apr 2010 07:18:25 -
1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,21 +0,0 @@
-$OpenBSD: patch-imap_courierpop3d_8_in,v 1.1 2010/04/21 07:18:25 giovanni Exp $
imap/courierpop3d.8.in.origFri Jan 8 20:00:30 2010
-+++ imap/courierpop3d.8.in Fri Jan 8 20:01:00 2010
-@@ -27,7 +27,6 @@
- .de SH-xref
- .ie n \{\
- .\}
--.toupper \\$*
- .el \{\
- \\$*
- .\}
-@@ -56,9 +55,6 @@
- .ft B
- .ne (2v + 1u)
- .ie n \{\
--.\ if n (TTY output), use uppercase
--.toupper \\$*
--.\}
- .el \{\
- .nr an-break-flag 0
- .\ if not n (not TTY), use normal case (not uppercase)
Index: patches/patch-imap_imapd_8_in
===
RCS file: patches/patch-imap_imapd_8_in
diff -N patches/patch-imap_imapd_8_in
--- patches/patch-imap_imapd_8_in 21 Apr 2010 07:18:25 - 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,21 +0,0 @@
-$OpenBSD: patch-imap_imapd_8_in,v 1.1 2010/04/21 07:18:25 giovanni Exp $
imap/imapd.8.in.orig Fri Jan 8 20:00:17 2010
-+++ imap/imapd.8.inFri Jan 8 20:00:46 2010
-@@ -27,7 +27,6 @@
- .de SH-xref
- .ie n \{\
- .\}
--.toupper \\$*
- .el \{\
- \\$*
- .\}
-@@ -56,9 +55,6 @@
- .ft B
- .ne (2v + 1u)
- .ie n \{\
--.\ if n (TTY output), use uppercase
--.toupper \\$*
--.\}
- .el \{\
- .nr an-break-flag 0
- .\ if not n (not TTY), use normal case (not uppercase)
Index: patches/patch-maildir_maildiracl_1_in
===
RCS file: patches/patch-maildir_maildiracl_1_in
diff -N patches/patch-maildir_maildiracl_1_in
--- patches/patch-maildir_maildiracl_1_in 21 Apr 2010 07:18:25 -
1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,21 +0,0 @@
-$OpenBSD: patch-maildir_maildiracl_1_in,v 1.1 2010/04/21 07:18:25 giovanni Exp
$
maildir/maildiracl.1.in.orig Fri Jan 8 19:57:10 2010
-+++ maildir/maildiracl.1.inFri Jan 8 19:59:39 2010
-@@ -27,7 +27,6 @@
- .de SH-xref
- .ie n \{\
- .\}
--.toupper \\$*
- .el \{\
- \\$*
- .\}
-@@ -56,9 +55,6 @@
- .ft B
- .ne (2v + 1u)
- .ie n \{\
--.\ if n (TTY output), use uppercase
--.toupper \\$*
--.\}
- .el \{\
- .nr an-break-flag 0
- .\ if
UPDATE: mail/maildrop
Update to maildrop 2.5.0, comments ? ok ?
Cheers
Giovanni
Index: Makefile
===
RCS file: /cvs/ports/mail/maildrop/Makefile,v
retrieving revision 1.32
diff -u -p -r1.32 Makefile
--- Makefile21 Apr 2010 07:23:58 - 1.32
+++ Makefile25 Jun 2010 13:55:10 -
@@ -3,7 +3,7 @@
COMMENT-main= mail delivery agent with filtering abilities
COMMENT-utils= quota tools for the Courier mail suite
-V= 2.4.3
+V= 2.5.0
DISTNAME= maildrop-$V
PKGNAME-main= maildrop-$V
FULLPKGNAME-utils= courier-utils-$V
@@ -73,10 +73,16 @@ CONFIGURE_ARGS+=--enable-trusted-users=
CONFIGURE_ARGS+= --enable-trusted-groups=wheel _courier
.endif
+MODULES= converters/libiconv \
+ devel/gettext
+
+LIB_DEPENDS= idn::devel/libidn
+
WANTLIB-utils= c
WANTLIB-main= c gdbm m stdc++
-LIB_DEPENDS-main= gdbm.=3::databases/gdbm \
+LIB_DEPENDS-main= ${LIB_DEPENDS} \
+ gdbm.=3::databases/gdbm \
pcre.=1::devel/pcre \
courierauth::mail/courier-authlib
Index: distinfo
===
RCS file: /cvs/ports/mail/maildrop/distinfo,v
retrieving revision 1.11
diff -u -p -r1.11 distinfo
--- distinfo21 Apr 2010 07:23:58 - 1.11
+++ distinfo25 Jun 2010 13:55:10 -
@@ -1,5 +1,5 @@
-MD5 (maildrop-2.4.3.tar.bz2) = FbdSi6Xnq3bmdllq9rzRyQ==
-RMD160 (maildrop-2.4.3.tar.bz2) = yq6QJ3XG+zRw09nrpwsiDVCtF+g=
-SHA1 (maildrop-2.4.3.tar.bz2) = F71ZoCwdHuqyq0lpKGqP5atNORQ=
-SHA256 (maildrop-2.4.3.tar.bz2) = tPVPX/ZZvwnhlxQdpdGQlwkbxLBfsZp/c9HLuZau0xA=
-SIZE (maildrop-2.4.3.tar.bz2) = 2413480
+MD5 (maildrop-2.5.0.tar.bz2) = 792aEySqDFtCenfTBe1eyw==
+RMD160 (maildrop-2.5.0.tar.bz2) = rXiAus5ubmE12bwlrsc5fXrJaDc=
+SHA1 (maildrop-2.5.0.tar.bz2) = 4JJV3sF515blWvAIqKU2R5rsVaw=
+SHA256 (maildrop-2.5.0.tar.bz2) = SaNaKb9XuF4YV3yMJwVQrkP1p3LdI00/OzVkuIxO9K0=
+SIZE (maildrop-2.5.0.tar.bz2) = 2413245
Index: patches/patch-maildrop_configure
===
RCS file: /cvs/ports/mail/maildrop/patches/patch-maildrop_configure,v
retrieving revision 1.4
diff -u -p -r1.4 patch-maildrop_configure
--- patches/patch-maildrop_configure21 Apr 2010 07:23:58 - 1.4
+++ patches/patch-maildrop_configure25 Jun 2010 13:55:10 -
@@ -1,12 +1,12 @@
$OpenBSD: patch-maildrop_configure,v 1.4 2010/04/21 07:23:58 giovanni Exp $
maildrop/configure.origFri Dec 25 23:14:47 2009
-+++ maildrop/configure Mon Jan 11 17:06:04 2010
-@@ -19265,15 +19265,12 @@ fi
+--- maildrop/configure.origSun May 30 23:36:43 2010
maildrop/configure Fri Jun 25 09:17:14 2010
+@@ -16697,16 +16697,12 @@ fi
$as_echo $maildrop_cv_SYS_INSTALL_RESET_GID 6; }
# Check whether --with-default-maildrop was given.
--if test ${with_default_maildrop+set} = set; then
-+if false; then
+-if test ${with_default_maildrop+set} = set; then :
++if false; then :
withval=$with_default_maildrop; maildrop_cv_SYS_INSTALL_MBOXDIR=$withval
else
# Courier defaults to ./Maildir
@@ -15,7 +15,8 @@ $OpenBSD: patch-maildrop_configure,v 1.4
- then
- maildrop_cv_SYS_INSTALL_MBOXDIR=./Maildir
- fi
+-
+ maildrop_cv_SYS_INSTALL_MBOXDIR=./Maildir
-
fi
+
Index: patches/patch-maildrop_maildrop_1_in
===
RCS file: patches/patch-maildrop_maildrop_1_in
diff -N patches/patch-maildrop_maildrop_1_in
--- patches/patch-maildrop_maildrop_1_in21 Apr 2010 07:23:58 -
1.4
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,12 +0,0 @@
-$OpenBSD: patch-maildrop_maildrop_1_in,v 1.4 2010/04/21 07:23:58 giovanni Exp $
maildrop/maildrop.1.in.origSat Sep 5 23:44:19 2009
-+++ maildrop/maildrop.1.in Mon Jan 11 17:06:04 2010
-@@ -192,7 +192,7 @@ is not owned by the user, or if it has any group or wo
- \fBmaildrop\fR
- is heavily optimized and tries to use as little resources as possible\.
- \fBmaildrop\fR
--reads smalle messages into memory, then filters and/or delivers the message
directly from memory\. For larger messages,
-+reads smaller messages into memory, then filters and/or delivers the message
directly from memory\. For larger messages,
- \fBmaildrop\fR
- accesses the message directly from the file\. If the standard input is not a
file,
- \fBmaildrop\fR
Index: patches/patch-rfc2045_reformime_1
===
RCS file: /cvs/ports/mail/maildrop/patches/patch-rfc2045_reformime_1,v
retrieving revision 1.1
diff -u -p -r1.1 patch-rfc2045_reformime_1
--- patches/patch-rfc2045_reformime_1 21 Apr 2010 07:23:59 - 1.1
+++ patches/patch-rfc2045_reformime_1 25 Jun 2010 13:55:10 -
@@ -1,52 +1,6 @@
$OpenBSD:
Re: [flashrom] Porting flashrom to OpenBSD
On 25.06.2010 17:20, Theo de Raadt wrote: I think I should clarify a bit what flashrom (BIOS/EFI/optionROM flasher) does/needs. PCI config space writes (usually only to the PCI-LPC bridge) are needed to tell that bridge to enable pass through for flash chip accesses. I/O port access is needed on some chipsets which have the passthrough enable in I/O space instead of PCI config space. Raw memory access is needed to the top 16 MB of the 32bit address space because that's where the BIOS flash ROM chip is mapped on i386/amd64, and to access the SPI flash ROM controller MMIO regions (somewhere in the address space, needs to be determined from PCI config space registers) on most chipsets released in the last 4 years. flashrom accesses PCI config space read/write via pciutils/libpci which uses /dev/pci AFAICS. The problem flashrom has right now is that PCI config writes via /dev/pci don't work. Without PCI config space write access, everything else is sort of pointless (you won't have access to the flash chip). I understand very well what you are trying to do. But it is the kernel's job to protect the hardware from all manner of direct access. Even essentially in single user mode. Now it is an accident of history that X is so terribly designed. It is currently accepted that this is so, and that's too bad, so there is a hole for X. There's a 10+ year effort to improve X so that this hole can go away. When it does, stuff like your code will stop working. What's the correct way forward for flashrom on OpenBSD? Unix is designed to hide the hardware, to protect the hardware, and it does this by providing and using highly abstracted interfaces. What you are trying to do is get around Unix. The Unix interfaces for hardware access usually have a reasonable level of abstraction as well, and flashrom makes use of that to run on pretty much any OS. flashrom is essentially a self-contained driver+frontend in userspace and thus very similar to X. It would be possible to move all hardware access into a kernel driver, but such a kernel driver would (if you really care about userspace not being able to screw up) have in excess of 25000 lines of code, constantly growing. That's the point where kernel maintainers usually run away screaming. The minimalistic and still somewhat safe approach is to have flashrom generate a list of PCI config space locations it needs to read/write, and whitelist only those in a kernel driver. Such a whitelist would reduce the amount of damage another userspace app with the same privileges could cause, and it's way better than a blacklist which will never be exhaustive. That kernel driver would also allow opening /dev/flashrom_memory which is essentially /dev/mem restricted to the regions which are absolutely necessary. Some people use flashrom to read out the flash chip and check it for malware, and I heard that's one of the motivations (well, besides BIOS updates) for trying to get it working on OpenBSD. I don't buy any of that stuff. By the time this has happened, you're already hosed. Not necessarily. You can easily boot with a known-clean flash chip, then (once the machine is booted) hot-swap the flash chip and read out the new flash chip. No code from the new flash chip will be executed. In fact, you can remove the flash chip after booting and run the machine without a flash chip forever (until you need to boot again). As long as the flash chip technology is compatible, you can exchange them regardless of mainboard chipset or CPU. This only applies to i386/amd64, I have no idea about other architectures. Regards, Carl-Daniel
Re: [flashrom] Porting flashrom to OpenBSD
On 25.06.2010 17:07, Matthieu Herrb wrote: On Fri, Jun 25, 2010 at 03:25:10PM +0100, Stuart Henderson wrote: On 2010/06/25 11:57, Carl-Daniel Hailfinger wrote: Hi Jonathan, you're in CC of this mail because you sent the unbreak pciutils mail to this list, and the failure mode is related. http://marc.info/?l=openbsd-portsm=126918139214769 Hmmm... So why is PCIOCWRITE failing, even when securelevel is 0 and allowaperture=2... Probably because you do un-aligned PCI config space access. Our /dev/pci only supports 32 bit wide read/write, aligned on 4 bytes boundaries. If you need to write to PCI config space, you'll need a separate kernel interface, with a high-level interface, so that you don't allow random changes in the PCI config space from userland. Wouldn't allowing 16 bit and 8 bit reads/writes at native alignments in /dev/pci work for that? I could modify flashrom to use read/modify/write cycles to emulate 8/16 bit reads/writes with 32 bit reads/writes, but that may have undesirable side effects on some chipsets. The rest of the discussion about not abusing the aperture driver for this also stays. I never fully understood how /dev/mem and the aperture driver are related. flashrom uses /dev/mem for memory access. The allowaperture stuff is something I guessed from reading various OpenBSD docs and mailing list posts. Regards, Carl-Daniel
Re: [flashrom] Porting flashrom to OpenBSD
On Fri, Jun 25, 2010 at 06:24:56PM +0200, Carl-Daniel Hailfinger wrote: On 25.06.2010 17:07, Matthieu Herrb wrote: On Fri, Jun 25, 2010 at 03:25:10PM +0100, Stuart Henderson wrote: On 2010/06/25 11:57, Carl-Daniel Hailfinger wrote: Hi Jonathan, you're in CC of this mail because you sent the unbreak pciutils mail to this list, and the failure mode is related. http://marc.info/?l=openbsd-portsm=126918139214769 Hmmm... So why is PCIOCWRITE failing, even when securelevel is 0 and allowaperture=2... Probably because you do un-aligned PCI config space access. Our /dev/pci only supports 32 bit wide read/write, aligned on 4 bytes boundaries. If you need to write to PCI config space, you'll need a separate kernel interface, with a high-level interface, so that you don't allow random changes in the PCI config space from userland. Wouldn't allowing 16 bit and 8 bit reads/writes at native alignments in /dev/pci work for that? I could modify flashrom to use read/modify/write cycles to emulate 8/16 bit reads/writes with 32 bit reads/writes, but that may have undesirable side effects on some chipsets. As far as I know this is an urban legend. Ask kettenis@ for details. So far we resisted to do that. libpciaccess handles it for OpenBSD (/usr/xenocara/lib/libpciaccess/src/openbsd_pci.c). The rest of the discussion about not abusing the aperture driver for this also stays. I never fully understood how /dev/mem and the aperture driver are related. flashrom uses /dev/mem for memory access. The allowaperture stuff is something I guessed from reading various OpenBSD docs and mailing list posts. The aperture driver was initially created to allow the X server to access the physical memory addresses of the graphics cards, even when running at securelevel 0, where /dev/mem access is forbidden. /dev/xf86 is used for that purpose and is attached to a character device which has the same major device number as /dev/mem. The sysctl is there to enable or disable the aperture, in order to avoid rebuilding a kernel to disable it. Then, when PCI/AGP video cards appeared, many PCI BIOS started so buggy that something had to fix their configuration space in order to be able to use them. Since XFree86 was a multi-platform system, instead of asking and waiting until every possible supported system implements the required kernel bits, they decided to write to the PCI config space directly from userland to fix those problems. On OpenBSD we decided that those /dev/pci write access are similar to /dev/mem access, and thus decided to control it using the same sysctl, in order not to create more knobs. -- Matthieu Herrb
Re: mozilla-firefox 3.6.4
OK on powerpc. On Fri, Jun 25, 2010 at 02:37:55AM +0200, Dawe wrote: On Thu, 24 Jun 2010 23:44:17 +0200 Landry Breuil lan...@rhaalovely.net wrote: Hi, update to latest 3.6.4, the sandboxing stuff for plugins is disabled, this part of code is horrible, unportable, and comes from an old version of chromium. And anyway from what i understood it only works with binary plugins we don't have (flash, silverlight, quicktime..) Please test, esp if you use it in some weird cases/archs. Landry Works for me on amd64. I can test this on powerpc next week.
Re: [flashrom] Porting flashrom to OpenBSD
On 25.06.2010 18:58, Matthieu Herrb wrote: On Fri, Jun 25, 2010 at 06:24:56PM +0200, Carl-Daniel Hailfinger wrote: On 25.06.2010 17:07, Matthieu Herrb wrote: On Fri, Jun 25, 2010 at 03:25:10PM +0100, Stuart Henderson wrote: On 2010/06/25 11:57, Carl-Daniel Hailfinger wrote: Hi Jonathan, you're in CC of this mail because you sent the unbreak pciutils mail to this list, and the failure mode is related. http://marc.info/?l=openbsd-portsm=126918139214769 Hmmm... So why is PCIOCWRITE failing, even when securelevel is 0 and allowaperture=2... Probably because you do un-aligned PCI config space access. Our /dev/pci only supports 32 bit wide read/write, aligned on 4 bytes boundaries. If you need to write to PCI config space, you'll need a separate kernel interface, with a high-level interface, so that you don't allow random changes in the PCI config space from userland. Wouldn't allowing 16 bit and 8 bit reads/writes at native alignments in /dev/pci work for that? I could modify flashrom to use read/modify/write cycles to emulate 8/16 bit reads/writes with 32 bit reads/writes, but that may have undesirable side effects on some chipsets. As far as I know this is an urban legend. Ask kettenis@ for details. So far we resisted to do that. libpciaccess handles it for OpenBSD (/usr/xenocara/lib/libpciaccess/src/openbsd_pci.c). Thanks. Do you know if anyone plans to implement the same trickery in libpci? If it works fine for libpciaccess, it should be doable for libpci. The rest of the discussion about not abusing the aperture driver for this also stays. I never fully understood how /dev/mem and the aperture driver are related. flashrom uses /dev/mem for memory access. The allowaperture stuff is something I guessed from reading various OpenBSD docs and mailing list posts. The aperture driver was initially created to allow the X server to access the physical memory addresses of the graphics cards, even when running at securelevel 0, where /dev/mem access is forbidden. /dev/xf86 is used for that purpose and is attached to a character device which has the same major device number as /dev/mem. The sysctl is there to enable or disable the aperture, in order to avoid rebuilding a kernel to disable it. Then, when PCI/AGP video cards appeared, many PCI BIOS started so buggy that something had to fix their configuration space in order to be able to use them. Since XFree86 was a multi-platform system, instead of asking and waiting until every possible supported system implements the required kernel bits, they decided to write to the PCI config space directly from userland to fix those problems. On OpenBSD we decided that those /dev/pci write access are similar to /dev/mem access, and thus decided to control it using the same sysctl, in order not to create more knobs. So if I understand you correctly, full /dev/pci and /dev/mem access should be possible with securelevel=0, and we shouldn't screw with allowaperture at all? No problem, I am happy to change the flashrom docs. flashrom is something you won't run on every boot, so I think requiring securelevel=0 for the few times you need to access flash is perfectly fine. Regards, Carl-Daniel
Re: Porting flashrom to OpenBSD
Stuart Henderson wrote: Port attached and at http://spacehopper.org/flashrom.tgz; this is basically your patches with a typo fixed (missing ; in the Makefile). You can see exampkle output from an unsuccessful run on amd64 attempting to dump rom contents at http://spacehopper.org/flashrom.txt Hi sthen, I've reported this to the lists and elsewhere before, libpci writes appear broken on at least i386/amd64, and have been for some time.. it always returns error on writes, setpci from pciutils also fails. I suspect the problem is in the kernel, not libpci.. but I haven't been able to figure it out yet. I believe once libpci/pci(4) writes are fixed, flashrom should work as intended. I would say that, as a general principle -- if you can't find this and fix it yourself, you probably are unable to evaluate the risk from bypassing the kernel and talking direct to the hardware.
Re: mozilla-firefox 3.6.4
On Fri, Jun 25, 2010 at 02:37:55AM +0200, Dawe wrote: On Thu, 24 Jun 2010 23:44:17 +0200 Landry Breuil lan...@rhaalovely.net wrote: update to latest 3.6.4, the sandboxing stuff for plugins is disabled, this part of code is horrible, unportable, and comes from an old version of chromium. And anyway from what i understood it only works with binary plugins we don't have (flash, silverlight, quicktime..) Yes, that's what I understood too. Not too useful for OpenBSD users... Works for me on amd64. I can test this on powerpc next week. Works for me, too. I'm on amd64 as well. Joachim
pyclutter port
Howdy! I went to compile the pyclutter port and was unable to. I noticed somewhere that the port is listed as not working. I was able to download the source tarball from the pyclutter project download page and get it working with 2 simple changes to the untar'red files. If the maintainer of the pyclutter port would be interested in this, please let me know.
Re: kill pkg_info -l
On Fri, Jun 25, 2010 at 04:45:24PM +0200, Marc Espie wrote: Is anyone actually using pkg_info -l ? It's an annoying flag that's not even implemented consistently, and I would like to actually kill it. I don't even know what it is. So, I'm a no. Ken
Re: kill pkg_info -l
On Fri, Jun 25, 2010 at 06:34:33PM -0400, Kenneth R Westerback wrote: On Fri, Jun 25, 2010 at 04:45:24PM +0200, Marc Espie wrote: Is anyone actually using pkg_info -l ? It's an annoying flag that's not even implemented consistently, and I would like to actually kill it. I don't even know what it is. So, I'm a no. Ken There's a lot of similar stuff I inherited straight from ye old freebsd implementation, back when I needed to make compatible shit. I'm pretty certain I can kill most of it, using pkg_info for programmatic purposes is mostly dead in our land, since the *.pm primitives are much better for that kind of purpose. (takes about as long to write 5 lines of perl that do things as it takes to figure the pkg_info options you would need to get something vaguely similar and parse it with some shell).
Re: Porting flashrom to OpenBSD
Theo de Raadt wrote: I would say that, as a general principle -- if you can't find this and fix it yourself, you probably are unable to evaluate the risk from bypassing the kernel and talking direct to the hardware. I haven't looked beyond libpci, I was giving a heads up, given that the problem wasn't documented anywhere. Given the nature of this tool, it's kind of obvious that it can be dangerous.. unfortunately some vendors no longer release OS-indepdent tools for upgrading their firmware. There are plenty of other ways to trash your system, this is just another possible way.. but maybe it can still be useful, like those dangerous X drivers you mentioned. Seems like the risk has to be evaluted on a case-by-case basis, don't you agree? I know of at least one OpenBSD developer wanting to update their BIOS from OpenBSD. -Bryan.
update and abandon net/ap-utils
I haven't had an AP that supports snmp management in years... -- GDB has a 'break' feature; why doesn't it have 'fix' too? ap-utils.diff Description: Binary data
ogle with sndio, big endian
After upgrading to 4.7, ogle gave only noise when playing dvds on my powermac. The change below fixed it for me: diff -uNr --exclude=CVS ogle.orig/patches/patch-libogleao_obsd_audio_c ogle/patches/patch-libogleao_obsd_audio_c --- ogle.orig/patches/patch-libogleao_obsd_audio_c Fri Jun 25 23:58:45 2010 +++ ogle/patches/patch-libogleao_obsd_audio_c Fri Jun 25 23:27:07 2010 @@ -88,7 +88,7 @@ + + par.bits = audio_info-sample_resolution; + par.sig = 1; -+ par.le = 1; ++ par.le = SIO_LE_NATIVE; + par.pchan = audio_info-channels; + par.rate = audio_info-sample_rate; + par.appbufsz = par.rate / 4; -- Mike Small sma...@panix.com
2� Via do Boleto
Prezado Cliente Consta em nosso sistema um título vencido referente ao mês de Maio ( 05 / 2010 ) caso não tenha efetuado o pagamento segue o título em anexo. Titulo_Maio ( 05 / 2010 ) Aguardo sua confirmação.
Re: ogle with sndio, big endian
On Sat, Jun 26, 2010 at 12:19:34AM -0400, Michael Small wrote: After upgrading to 4.7, ogle gave only noise when playing dvds on my powermac. The change below fixed it for me: diff -uNr --exclude=CVS ogle.orig/patches/patch-libogleao_obsd_audio_c ogle/patches/patch-libogleao_obsd_audio_c --- ogle.orig/patches/patch-libogleao_obsd_audio_cFri Jun 25 23:58:45 2010 +++ ogle/patches/patch-libogleao_obsd_audio_c Fri Jun 25 23:27:07 2010 @@ -88,7 +88,7 @@ + + par.bits = audio_info-sample_resolution; + par.sig = 1; -+ par.le = 1; ++ par.le = SIO_LE_NATIVE; + par.pchan = audio_info-channels; + par.rate = audio_info-sample_rate; + par.appbufsz = par.rate / 4; thanks. didn't/don't have a DVD drive in a big endian machine to test, but that certainly makes sense. -- jake...@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org
