CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rpoin...@cvs.openbsd.org2011/06/25 00:54:35 Modified files: math/gnuplot : Makefile math/gnuplot/pkg: DESCR Log message: Modify DESCR, spotted and corrected by Anthony J. Bentley (thanks). Bump revision.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rpoin...@cvs.openbsd.org2011/06/25 01:10:25 Log message: Import ikeman, from Martin Pelikan (MAINTAINER). ok giovanni@. ikeman is a tool designed to simplify management of X.509 public key infrastructure used to create IPsec flows by isakmpd(8) or iked(8). It displays all PKI data in a hierarchical view and can also create new certificate authorities, sign new certificate requests and revoke or un-revoke currently loaded certificates. All this in a user-friendly ncurses GUI, which also warns user about errors like already expired, revoked or not yet valid certificates. Status: Vendor Tag: mpelikan Release Tags: rpointel_20110625 N ports/security/ikeman/Makefile N ports/security/ikeman/distinfo N ports/security/ikeman/pkg/DESCR N ports/security/ikeman/pkg/PLIST No conflicts created by this import
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rpoin...@cvs.openbsd.org2011/06/25 01:11:30 Modified files: security : Makefile Log message: +ikeman
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: dco...@cvs.openbsd.org 2011/06/25 01:48:43 Modified files: lang/erlang: Makefile Log message: Fix MASTER_SITES: a double '/' breaks their webserver
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2011/06/25 02:23:40 Modified files: textproc/p5-Regexp-Common: Makefile distinfo Log message: - update to 2011041701 - fix comment which was obviously a pasto
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2011/06/25 02:23:43 Modified files: textproc/p5-Text-WordDiff: Makefile distinfo textproc/p5-Text-WordDiff/pkg: PLIST Log message: update to Text-WordDiff-0.07
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2011/06/25 02:23:52 Modified files: textproc/p5-Template-Plugin-Class: Makefile distinfo Log message: update to Template-Plugin-Class-0.14
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2011/06/25 02:23:55 Modified files: textproc/p5-Text-Diff: Makefile distinfo textproc/p5-Text-Diff/pkg: PLIST Log message: update to Text-Diff-1.41
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2011/06/25 02:24:00 Modified files: textproc/p5-XML-Parser: Makefile distinfo Log message: update to XML-Parser-2.41
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2011/06/25 02:35:46 Modified files: net/p5-Net-DAV-Server: Makefile distinfo Log message: update to Net-DAV-Server-1.302
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2011/06/25 02:41:15 Modified files: net/p5-SNMP-Info: Makefile distinfo net/p5-SNMP-Info/pkg: PLIST Log message: update to SNMP-Info-2.05
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: e...@cvs.openbsd.org2011/06/25 08:15:43 Modified files: x11/mplayer: Makefile x11/mplayer/patches: patch-Makefile patch-configure Log message: make mplayer build with thew new libass. OK sthen@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2011/06/25 08:34:35 Modified files: x11/gtksourceviewmm: Makefile distinfo x11/gtksourceviewmm/pkg: PLIST Log message: - bugfix update to gtksourceviewmm-2.0
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2011/06/25 09:33:33 Modified files: math/sc: Makefile math/sc/patches: patch-lex_c Log message: - prevent the return value from being uninitialized, which would break sc in various ways. from slackware via Donovan Watteau
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2011/06/25 09:36:08 Modified files: math/sc: Makefile math/sc/patches: patch-torev math/sc/pkg: PLIST Log message: - regen patch and PLIST - set license marker - remove freebsd-isms
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2011/06/25 10:18:07 Modified files: x11/gnome3/x11/gnome/session: Makefile x11/gnome3/x11/gnome/session/pkg: README Log message: Remove system-config-printer from the list, it doesn't have much to do with GNOME itself.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2011/06/25 12:01:06 Modified files: graphics/p5-GD : Makefile distinfo Log message: update to GD-2.46
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2011/06/25 12:01:21 Modified files: devel/p5-YAML-Tiny: Makefile distinfo Log message: update to YAML-Tiny-1.50
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2011/06/25 12:01:10 Modified files: textproc/p5-Pod-Tests: Makefile distinfo Log message: update to Pod-Tests-1.19
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2011/06/25 12:01:13 Modified files: mail/p5-MIME-Charset: Makefile distinfo Log message: update to MIME-Charset-1.009.1
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2011/06/25 12:01:08 Modified files: mail/p5-MIME-EncWords: Makefile distinfo mail/p5-MIME-EncWords/pkg: PLIST Log message: update to p5-MIME-EncWords-1.012.3
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2011/06/25 12:01:22 Modified files: devel/p5-YAML-Syck: Makefile distinfo Log message: update to YAML-Syck-1.17
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2011/06/25 12:01:19 Modified files: devel/p5-YAML : Makefile distinfo Log message: update to YAML-0.73
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2011/06/25 12:42:02 Modified files: audio/openal : Makefile distinfo audio/openal/pkg: DESCR PLIST Added files: audio/openal/patches: patch-Alc_portaudio_c patch-Alc_sndio_c patch-CMakeLists_txt Removed files: audio/openal/files: alc_backend_sndio.c audio/openal/patches: patch-admin_pkgconfig_openal-config_in patch-admin_pkgconfig_openal_pc_in patch-common_include_AL_al_h patch-common_include_AL_alc_h patch-configure_ac patch-src_Makefile_am patch-src_al_mixer_h patch-src_al_mixfunc_c patch-src_al_source_c patch-src_arch_i386_x86_cpu_caps_prk_c patch-src_arch_i386_x86_floatmul_c patch-src_mixaudio16_h Log message: - update to a more recent version Some games might require reseting configurations if sounds are not playing after the update. from Antti Harri ok ratchov@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2011/06/25 12:43:07 Modified files: games/scorched3d: Makefile Added files: games/scorched3d/patches: patch-configure-al_m4 Log message: - adjust after openal update (openal-config was removed) from Antti Harri ok ratchov@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2011/06/25 12:58:11 Modified files: games/tmw : Makefile distinfo games/tmw/pkg : PLIST-main PLIST-music Log message: - update to 0.5.2 and 0.3 for the music - switch to cmake from Antti Harri maintainer timed-out
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2011/06/25 13:09:37 ports/math/cgal/patches Update of /cvs/ports/math/cgal/patches In directory cvs.openbsd.org:/tmp/cvs-serv17839/patches Log Message: Directory /cvs/ports/math/cgal/patches added to the repository
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2011/06/25 13:12:36 Modified files: math/cgal : Makefile math/cgal/pkg : PLIST Log message: - fix manpage installation path - simplify PKGNAME
Re: mozilla-firefox 5.0
On Fri, Jun 24, 2011 at 07:33:44AM +0200, Landry Breuil wrote: On Thu, Jun 23, 2011 at 08:50:23PM -0500, Amit Kulkarni wrote: git co -b firefox-5http://rhaalovely.net/git/mozilla-firefox ^^ make that 'git clone' Landry, thanks for that. I am a git dummy but will get upto speed quickly. I just installed firefox5 using the above instructions on 4.9 (June 6 snapshot), i386. It all works fine, except for a couple of addons that are not compatible with firefox5. as many others have said on the internets, just edit the string and bump the firefox version in the .xpi files for the addons in your mozilla profile folder. Firefox is at version 7 already, how can they expect volunteers to bump version strings every few weeks? Addons.mozilla.org will have a process to automatically check addons compat, so the bump will be done mechanically in the install.rdf files. And for the record, here are some details from a mozilla dev : http://www.oxymoronical.com/blog/2011/06/Why-do-Firefox-updates-break-add-ons Landry
Re: [new] lang/datalog
On Fri, Jun 24, 2011 at 07:48:21PM -0400, Daniel Dickman wrote: Here's a port for datalog. Similar to prolog in some respects. Looks like a good recap of datalog vs. prolog can be found here: http://stackoverflow.com/questions/3924654/datalog-vs-clips-vs-prolog [~] pkg_info datalog Information for inst:datalog-1.5 Comment: subset of Prolog where all programs terminate Description: The Datalog package contains a lightweight deductive database system. Queries and database updates are expressed using Datalog -- a declarative logic language in which each formula is a function-free Horn clause, and every variable in the head of a clause must appear in the body of the clause. The use of Datalog syntax and an implementation based on tabling intermediate results, ensures that all queries terminate. The components in this package are designed to be small, and usable on memory constrained devices. The package includes an interactive interpreter for Datalog, and a library that can be employed to embed a small deductive database into C programs. The library uses the tabled logic programming algorithm described in Efficient Top-Down Computation of Queries under the Well-Founded Semantics, Chen, W., Swift, T., and Warren, D. S., J. Logic Prog., Vol. 24, No. 3, pp. 161-199. Another important reference is Tabled Evaluation with Delaying for General Logic Programs, Chen, W., and Warren, D. S., J. ACM, Vol. 43, No. 1, Jan. 1996, pp. 20-74. Datalog is described in What You Always Wanted to Know About Datalog (And Never Dared to Ask), Stefano Ceri, Georg Gottlob, and Letizia Tanca, IEEE Transactions of Knowledge and Data Engineering, Vol. 1, No. 1, March 1989. Maintainer: The OpenBSD ports mailing-list ports@openbsd.org WWW: http://www.ccs.neu.edu/home/ramsdell/tools/datalog/ Looks fine to me, though I've reworded COMMENT and shrank DESCR to just the first paragraph. Ok to import? -- Cheers, Jasper Capable, generous men do not create victims, they nurture them. datalog.tgz Description: application/tar-gz
PATCH: small fixes to cyphertite and its dependencies
Ok?
- always install headers, even if that same header file is already
installed in the system, this is for various conformal.com ports
- fix crash at the end of cyphertite session, from upstream cvs
- bump revision for cyphertite
Index: archivers/libshrink/patches/patch-libshrink_Makefile
===
RCS file: archivers/libshrink/patches/patch-libshrink_Makefile
diff -N archivers/libshrink/patches/patch-libshrink_Makefile
--- /dev/null 1 Jan 1970 00:00:00 -
+++ archivers/libshrink/patches/patch-libshrink_Makefile25 Jun 2011
09:45:31 -
@@ -0,0 +1,14 @@
+
+always install files
+
+$OpenBSD$
+--- libshrink/Makefile.origSun May 1 19:50:03 2011
libshrink/Makefile Sat Jun 25 10:01:46 2011
+@@ -23,7 +23,6 @@ LDADD+= -L${LOCALBASE}/lib
+
+ afterinstall:
+ @cd ${.CURDIR}; for i in ${HDRS}; do \
+- cmp -s $$i ${INCDIR}/$$i || \
+ ${INSTALL} ${INSTALL_COPY} -m 444 -o $(BINOWN) -g $(BINGRP) $$i
${DESTDIR}${INCDIR}/; \
+ echo ${INSTALL} ${INSTALL_COPY} -m 444 -o $(BINOWN) -g $(BINGRP) $$i
${DESTDIR}${INCDIR}/; \
+ done
Index: devel/libclog/patches/patch-Makefile
===
RCS file: devel/libclog/patches/patch-Makefile
diff -N devel/libclog/patches/patch-Makefile
--- /dev/null 1 Jan 1970 00:00:00 -
+++ devel/libclog/patches/patch-Makefile25 Jun 2011 09:46:00 -
@@ -0,0 +1,14 @@
+
+install files always
+
+$OpenBSD$
+--- Makefile.orig Tue Jun 14 19:27:35 2011
Makefile Sat Jun 25 01:03:34 2011
+@@ -44,7 +44,6 @@ CFLAGS+= -ggdb3 -I${.CURDIR} -I${INCDIR}
+
+ afterinstall:
+ @cd ${.CURDIR}; for i in ${HDRS}; do \
+- cmp -s $$i ${LOCALBASE}/include/$$i || \
+ ${INSTALL} ${INSTALL_COPY} -m 444 -o $(BINOWN) -g $(BINGRP) $$i
${DESTDIR}${LOCALBASE}/include; \
+ echo ${INSTALL} ${INSTALL_COPY} -m 444 -o $(BINOWN) -g $(BINGRP) $$i
${DESTDIR}${LOCALBASE}/include;\
+ done
Index: devel/libexude/patches/patch-Makefile
===
RCS file: devel/libexude/patches/patch-Makefile
diff -N devel/libexude/patches/patch-Makefile
--- /dev/null 1 Jan 1970 00:00:00 -
+++ devel/libexude/patches/patch-Makefile 25 Jun 2011 09:46:01 -
@@ -0,0 +1,14 @@
+
+install files always
+
+$OpenBSD$
+--- Makefile.orig Mon Apr 11 19:02:56 2011
Makefile Sat Jun 25 01:09:10 2011
+@@ -36,7 +36,6 @@ HDRS= exude.h
+
+ afterinstall:
+ @cd ${.CURDIR}; for i in ${HDRS}; do \
+- cmp -s $$i ${LOCALBASE}/include/$$i || \
+ ${INSTALL} ${INSTALL_COPY} -m 444 -o $(BINOWN) -g $(BINGRP) $$i
${DESTDIR}${LOCALBASE}/include; \
+ echo ${INSTALL} ${INSTALL_COPY} -m 444 -o $(BINOWN) -g $(BINGRP) $$i
${DESTDIR}${LOCALBASE}/include;\
+ done
Index: security/assl/patches/patch-Makefile
===
RCS file: security/assl/patches/patch-Makefile
diff -N security/assl/patches/patch-Makefile
--- /dev/null 1 Jan 1970 00:00:00 -
+++ security/assl/patches/patch-Makefile25 Jun 2011 09:47:27 -
@@ -0,0 +1,14 @@
+
+install files always
+
+$OpenBSD$
+--- Makefile.orig Thu May 5 03:46:52 2011
Makefile Sat Jun 25 10:04:01 2011
+@@ -44,7 +44,6 @@ CLEANFILES+= assl.cat3
+
+ afterinstall:
+ @cd ${.CURDIR}; for i in ${HDRS}; do \
+- cmp -s $$i ${LOCALBASE}/include/$$i || \
+ ${INSTALL} ${INSTALL_COPY} -m 444 -o $(BINOWN) -g $(BINGRP) $$i
${DESTDIR}${LOCALBASE}/include; \
+ echo ${INSTALL} ${INSTALL_COPY} -m 444 -o $(BINOWN) -g $(BINGRP) $$i
${DESTDIR}${LOCALBASE}/include; \
+ done
Index: sysutils/cyphertite/Makefile
===
RCS file: /cvs/ports/sysutils/cyphertite/Makefile,v
retrieving revision 1.3
diff -u -r1.3 Makefile
--- sysutils/cyphertite/Makefile23 Jun 2011 22:50:29 - 1.3
+++ sysutils/cyphertite/Makefile25 Jun 2011 09:47:34 -
@@ -3,6 +3,7 @@
COMMENT = tar-like secure remote deduplicating archiver
DISTNAME = cyphertite-0.1.3
+REVISION = 0
CATEGORIES = sysutils archivers security
HOMEPAGE = https://www.cyphertite.com/
Index: sysutils/cyphertite/patches/patch-ctutil_Makefile
===
RCS file: sysutils/cyphertite/patches/patch-ctutil_Makefile
diff -N sysutils/cyphertite/patches/patch-ctutil_Makefile
--- /dev/null 1 Jan 1970 00:00:00 -
+++ sysutils/cyphertite/patches/patch-ctutil_Makefile 25 Jun 2011 09:47:34
-
@@ -0,0 +1,14 @@
+
+install files always
+
+$OpenBSD$
+--- ctutil/Makefile.orig Thu May 19 19:55:01 2011
ctutil/MakefileSat Jun 25 10:08:10 2011
+@@ -21,7 +21,6 @@ CFLAGS+= -ggdb3
+
+ afterinstall:
+ @cd ${.CURDIR}; for i in ${HDRS}; do \
+- cmp -s $$i ${INCDIR}/$$i || \
+
using dlopen() instead of -lmylib
There's code (eg. audio/openal, but not only) that does: dlopen(libsndio.so, ...); and then calls dlsym() for each function and so on. What's the point of doing this instead of simply linking the binary with -lsndio and using functions normally? hints? -- Alexandre
Re: using dlopen() instead of -lmylib
On Saturday 25 June 2011 13:52:02 Alexandre Ratchov wrote: There's code (eg. audio/openal, but not only) that does: dlopen(libsndio.so, ...); and then calls dlsym() for each function and so on. What's the point of doing this instead of simply linking the binary with -lsndio and using functions normally? hints? -- Alexandre Extending the same subject a little: I'm interested in knowing how to handle these with ports? Is there a real good rule of thumb here and is this documented in the ports faq? For example xvidcore adds some libs to WANTLIB even though check-lib-depends doesn't want them. But devel/sdl depends on libGL that it opens with dlopen() and there is no GL in WANTLIB. -- Antti Harri
Re: webkit woes
On Fri, Jun 24, 2011 at 08:32:12PM +, Kevin Chadwick wrote: Your a brave man. check the mailing lists. Why would you download stuff you likely won't read, especially on a good internet connection where you are not waiting. I thought the author of the page marked links he wanted the browser to prefetch. This can (I know it won't, hence the knob) filter out the stuff you won't be reading and even on a good connection I wait because some idiot uses ads from 10 different domains, which means 10 different DNS lookups and by the way eight of them is hosted on that 56k modem and the whole page is in a table, so you wait for the slowest ones anyway. Sorry, Kevin, for double post; forgot the list's address. -- Martin Pelikan
Re: webkit woes
On Fri, Jun 24, 2011 at 09:01:30PM +0200, Martin Pelikan wrote: On Fri, Jun 24, 2011 at 01:42:57PM -0500, Chris Bennett wrote: On Fri, Jun 24, 2011 at 07:54:33PM +0200, Matthias Kilian wrote: On Fri, Jun 24, 2011 at 11:06:56AM -0500, Marco Peereboom wrote: My current best theory is that the brand new link prefetch stuff (ugh!) is easting gobs of file descriptors while another site is loading. So when webkit tries to establish a connection to get like favicon or css it runs out and renders the pages sans css or favicon (missing pictures etc etc). The link prefetch can't be disabled since it doesn't have a knob. I am trying to reason with the webkit people (again) that anything prefetch is not really that great for everybody. Well, if there a way we could introduce such a knob in the port then? BTW: I'm against a knob, too. If we patch it locally (in the port), I'm for disabling all the prefetching stuff unconditionally, because it's just plain stupid. If upstream accepts a knob (because they obviously think that prefetching is clever), that's another story. I agree, just get rid of it. If upstream is so big on having this prefetching crap, I doubt they will want even a knob. Just patch it locally unless a knob is really easy. Prefetching stuff is a brilliant idea on a sane internet connection. But people probably want to use their browser in a bush on GPRS 56k modem and share the line with others, too. Also, at least in our country, there are lots of stupid greedy ISPs who bill you based on how much traffic do you transfer. Why should either group of people be limited in favor of the other? Prefetching is a waste of bandwith no matter what. It just adds more load onto the servers. -- :wq Claudio
new wantlib computations, and why it's there to stay
Some people have expressed annoyance at the new behavior of the ports building system. Specifically, the fact that if your ports tree is out-of-sync with the installed system, you might run into trouble. But the new behavior is here to stay, because it's WAYS more consistent than it used to be. Historically, the ports tree solves dependencies during build time by matching stuff against installed packages. Then, at the end of build, it creates a package which records dependencies. *however* the dependencies were half-taken from the ports tree, and half-taken from installed packages. They can't be entirely taken from installed packages, here's why: if you build a package that depends on ghostscript, it often won't matter whether you have ghostscript-- or ghoscript--no_x11 installed. *but* if you take the deps from the installed package, then you end up with non-reproduceable builds: one package built somewhere will have ghostscript-- in its depends line, the other one will have ghoscript--no_x11 in its depends line. Thus, package builds have filled the @depend line with info from the ports tree for quite a few years. This has become *ways* more vital recently, because it is part of the info that's used during updates: to determine whether to update something or not, pkg_add first looks at the pkgname proper, and then, if that didn't change, it *looks at the whole signature*: all dependencies it was built from. If those, for some reason, are non-comparable, then it will whine (it means a dependency changed, and nobody bumped the REVISION, which is bad). So, if you have foo-1.0 that depends on ghostscript-- and foo-1.0 that depends on ghostscript--no_x11, guess what ? those are non-comparable... This is why PLIST_DB was tweaked to take this into account, so that bulk-builders would notice when this stuff happens. For instance: Create /home/ports/packages/amd64/all/mplayer-20110309p5.tgz /home/ports/plist/amd64/mplayer-20110309p5 was updated graphics/ffmpeg:ffmpeg-=20110408:ffmpeg-20110408 - graphics/ffmpeg:ffmpeg-=20110408:ffmpeg-20110408p1 avcodec.15.1 - avcodec.16.0 But now, if we take @wantlib lines from installed stuff, we're asking for trouble, since the @depend lines come from the ports tree ! Hence the recent change, which does check that installed libraries do match what's in the ports tree, in order to produce correct depend lines AND wantlib lines. Otherwise, you could end up with packages *that would be impossible to install on somebody else's machine*. (and there are probably bordeline cases where the dependency tree says something and the installation tree something else, like when wantlib are not really reachable the correct way). One unfortunate side-effect is that this stuff is a bit slow... which is partly why I shoved it in so that people could give me enough details to make it faster (okay, it's not perfect yet, but we are getting there). It should be possible to waive the check when you're actually polishing a port, and building and rebuilding a package... But the primary goal is still to build binary packages that work flawlessly on a user's machine, without the need for him to rebuild stuff from the source tree. All the recent checks in bsd.port.mk and pkg_create and PLIST_DB were specifically added to facilitate this. The second benefit from that change is that more stuff is amenable to introspection: now, make print-plist-with-depends gets all its info from the ports tree and should always work, irregardless of how much you *don't* have installed. Yes, this will help lib-depends-check, and it should already make out-of-date checks ways more accurate, as they can now properly compare installed libraries with libraries in the ports tree.
Re: using dlopen() instead of -lmylib
On Sat, Jun 25, 2011 at 02:08:07PM +0300, Antti Harri wrote: On Saturday 25 June 2011 13:52:02 Alexandre Ratchov wrote: There's code (eg. audio/openal, but not only) that does: dlopen(libsndio.so, ...); and then calls dlsym() for each function and so on. What's the point of doing this instead of simply linking the binary with -lsndio and using functions normally? hints? -- Alexandre Extending the same subject a little: I'm interested in knowing how to handle these with ports? Is there a real good rule of thumb here and is this documented in the ports faq? For example xvidcore adds some libs to WANTLIB even though check-lib-depends doesn't want them. But devel/sdl depends on libGL that it opens with dlopen() and there is no GL in WANTLIB. Yes, there is a good rule of thumb: things should work. Like, it the dlopen'd stuff is actually *mandatory* for the port to be useful, then it should be in WANTLIB. If it's not mandatory, it's like your usual RUN_DEPENDS: is it a problem not to have it ? does it show up as obvious from reduced functionality ? does it pull a whole lot of shit from the ports tree or is the dependance fairly minimal ? There's *no way* lib-depends-check is going to help you with these: by design, using a library through dlopen is something that happens at runtime, so you can run all the ldds and objdump in the world, they won't catch it.
Re: using dlopen() instead of -lmylib
On Sat, Jun 25, 2011 at 12:52:02PM +0200, Alexandre Ratchov wrote: There's code (eg. audio/openal, but not only) that does: dlopen(libsndio.so, ...); and then calls dlsym() for each function and so on. What's the point of doing this instead of simply linking the binary with -lsndio and using functions normally? hints? Misplaced portability concerns from upstreams, and ETOOMUCHWORK from the porter. If it's not too intrusive, telling upstream to forget about old OpenBSD versions and doing the normal linking thing is the way to go. (We have similar code in qt4 vs. openssl, but since it's reasonably clean and hugely intrusive, we left it that way).
Re: PATCH: small fixes to cyphertite and its dependencies
On 2011-06-25, Mikolaj Kucharski miko...@kucharski.name wrote: Ok? - always install headers, even if that same header file is already installed in the system, this is for various conformal.com ports Why would you want to do this? It doesn't affect ports at all, and if these are being built outside of ports you don't really want the timestamp on those headers to change unless the contents of the headers changes too.
Re: databases/sqlite3: 'no_tcl' flavor broken
On 2011-06-20, Landry Breuil lan...@rhaalovely.net wrote: On Mon, Jun 20, 2011 at 03:22:24PM +, Stuart Henderson wrote: This has been through a bulk and hasn't shown up any problems but I don't have any good ideas what to do with the regression tests. Any suggestions? Ask upstream why they don't provide them in the main tarball.. iirc stu@ talked to them about this. but for now, i'd go the 'pull the legacy zipfile to run the tests'. bah, I tried to make this work, but so far it has proved resistant to my efforts...
Re: PATCH: small fixes to cyphertite and its dependencies
On Sat, Jun 25, 2011 at 01:15:06PM +, Stuart Henderson wrote:
On 2011-06-25, Mikolaj Kucharski miko...@kucharski.name wrote:
Ok?
- always install headers, even if that same header file is already
installed in the system, this is for various conformal.com ports
Why would you want to do this? It doesn't affect ports at all, and if
these are being built outside of ports you don't really want the timestamp
on those headers to change unless the contents of the headers changes too.
I think it does affect if you have package installed and port is
rebuilding again. You end up with missing files in fake and package
fails to create. That's why I create those patches as I was affected by
this.
@cd ${.CURDIR}; for i in ${HDRS}; do \
cmp -s $$i ${INCDIR}/$$i || \
${INSTALL} ${INSTALL_COPY} -m 444 -o $(BINOWN) -g $(BINGRP) $$i
${DESTDIR}${INCDIR}/; \
echo ${INSTALL} ${INSTALL_COPY} -m 444 -o $(BINOWN) -g $(BINGRP)
$$i ${DESTDIR}${INCDIR}/; \
done
What happends if file $$i and ${INCDIR}/$$i are identical?
--
best regards
q#
Re: PATCH: small fixes to cyphertite and its dependencies
On Sat, Jun 25, 2011 at 02:27:04PM +0100, Mikolaj Kucharski wrote:
On Sat, Jun 25, 2011 at 01:15:06PM +, Stuart Henderson wrote:
On 2011-06-25, Mikolaj Kucharski miko...@kucharski.name wrote:
Ok?
- always install headers, even if that same header file is already
installed in the system, this is for various conformal.com ports
Why would you want to do this? It doesn't affect ports at all, and if
these are being built outside of ports you don't really want the timestamp
on those headers to change unless the contents of the headers changes too.
I think it does affect if you have package installed and port is
rebuilding again. You end up with missing files in fake and package
fails to create. That's why I create those patches as I was affected by
this.
@cd ${.CURDIR}; for i in ${HDRS}; do \
cmp -s $$i ${INCDIR}/$$i || \
${INSTALL} ${INSTALL_COPY} -m 444 -o $(BINOWN) -g $(BINGRP) $$i
${DESTDIR}${INCDIR}/; \
echo ${INSTALL} ${INSTALL_COPY} -m 444 -o $(BINOWN) -g $(BINGRP)
$$i ${DESTDIR}${INCDIR}/; \
done
Obvious missing DESTDIR in the cmp line.
[PATCH] math/sc doesn't work at all with gcc4
Hi there,
I'm afraid math/sc doesn't work at all when compiled with gcc4:
1) Launch sc
2) Type '=1'
3) You'll get syntax error: let A0= = 1
I have seen this problem with amd64, i386 and macppc. loongson seems
to be an exception. AFAIK, this problem exists since OpenBSD 4.8 (when
GCC was switched over to 4.2.1 for most architectures) and is still
here with -current.
Slackware had this problem some time ago, so I took the (trivial) patch
they used [1] (itself taken from Debian) and now everything is working
OK. You might want to pick more things from this patch, as it fixes the
numerous warnings produced during the build.
[1] http://slackware.osuosl.org/slackware-13.37/source/ap/sc/\
sc-7.16-3.diff.gz
Thanks for your good work,
Tsomi.
Index: ports/math/sc/patches/patch-lex_c
===
RCS file: /cvs/ports/math/sc/patches/patch-lex_c,v
retrieving revision 1.4
diff -u -p -r1.4 patch-lex_c
--- ports/math/sc/patches/patch-lex_c 28 May 2006 21:21:51 - 1.4
+++ ports/math/sc/patches/patch-lex_c 25 Jun 2011 13:58:41 -
@@ -1,6 +1,15 @@
$OpenBSD: patch-lex_c,v 1.4 2006/05/28 21:21:51 weingart Exp $
lex.c.orig Thu May 4 09:52:42 2006
-+++ lex.c Thu May 4 09:52:54 2006
+--- lex.c.orig Wed Aug 21 00:44:26 2002
lex.c Sat Jun 25 15:49:11 2011
+@@ -107,7 +107,7 @@ int
+ yylex()
+ {
+ char *p = line + linelim;
+-int ret;
++int ret = 0;
+ static int isfunc = 0;
+ static bool isgoto = 0;
+ static bool colstate = 0;
@@ -642,7 +642,7 @@ nmgetch()
#endif
Re: PATCH: small fixes to cyphertite and its dependencies
On Sat, Jun 25, 2011 at 03:48:20PM +0200, Marc Espie wrote:
@cd ${.CURDIR}; for i in ${HDRS}; do \
cmp -s $$i ${INCDIR}/$$i || \
${INSTALL} ${INSTALL_COPY} -m 444 -o $(BINOWN) -g $(BINGRP) $$i
${DESTDIR}${INCDIR}/; \
echo ${INSTALL} ${INSTALL_COPY} -m 444 -o $(BINOWN) -g $(BINGRP)
$$i ${DESTDIR}${INCDIR}/; \
done
Obvious missing DESTDIR in the cmp line.
Correct, but is there a point to have this line anyway?
--
best regards
q#
UPDATE: graphics/tgif
Hi,
This diff updates tgif to 4.2.4, a bugfix release.
Tested on amd64.
Comments ? OK ?
Cheers,
benoit
Index: Makefile
===
RCS file: /cvs/ports/graphics/tgif/Makefile,v
retrieving revision 1.33
diff -u -r1.33 Makefile
--- Makefile28 May 2011 09:30:35 - 1.33
+++ Makefile25 Jun 2011 14:10:57 -
@@ -2,7 +2,7 @@
COMMENT = two-dimensional drawing tool and hyper-object browser
-VERSION = 4.2.3
+VERSION = 4.2.4
DISTNAME = tgif-QPL-${VERSION}
PKGNAME = tgif-${VERSION}
CATEGORIES = graphics
Index: distinfo
===
RCS file: /cvs/ports/graphics/tgif/distinfo,v
retrieving revision 1.8
diff -u -r1.8 distinfo
--- distinfo28 May 2011 09:30:35 - 1.8
+++ distinfo25 Jun 2011 14:10:57 -
@@ -1,5 +1,5 @@
-MD5 (tgif-QPL-4.2.3.tar.gz) = WiQze5RMaTpRT/5+s97Utg==
-RMD160 (tgif-QPL-4.2.3.tar.gz) = qTLUoXLT9MSCZRdvOgKs2jmsgGc=
-SHA1 (tgif-QPL-4.2.3.tar.gz) = xadJeWW8E13y86Pd48amt7RMkb4=
-SHA256 (tgif-QPL-4.2.3.tar.gz) = zx7IBbp6gx5K7dLveh5jBpTTSrxXxTxAh47qme+9zjI=
-SIZE (tgif-QPL-4.2.3.tar.gz) = 3006463
+MD5 (tgif-QPL-4.2.4.tar.gz) = dZoZSGdBbf8UXIv9v/q76A==
+RMD160 (tgif-QPL-4.2.4.tar.gz) = VU78fsSiD8tQWpWU9oIfGywhDJY=
+SHA1 (tgif-QPL-4.2.4.tar.gz) = ZM/9ZaOruWQY6kQTHfdCoXchPnc=
+SHA256 (tgif-QPL-4.2.4.tar.gz) = 9oj2RrTl/9qdRBNaoomtgUZjtb8Zf5Bi0qzQFo9ruRQ=
+SIZE (tgif-QPL-4.2.4.tar.gz) = 3094521
Index: patches/patch-Tgif.tmpl
===
RCS file: /cvs/ports/graphics/tgif/patches/patch-Tgif.tmpl,v
retrieving revision 1.4
diff -u -r1.4 patch-Tgif.tmpl
--- patches/patch-Tgif.tmpl 28 May 2011 09:30:38 - 1.4
+++ patches/patch-Tgif.tmpl 25 Jun 2011 14:10:57 -
@@ -1,7 +1,7 @@
$OpenBSD: patch-Tgif.tmpl,v 1.4 2011/05/28 09:30:38 benoit Exp $
Tgif.tmpl.orig Mon May 23 11:12:30 2011
-+++ Tgif.tmpl Mon May 23 11:14:22 2011
-@@ -44,7 +44,8 @@
+--- Tgif.tmpl.orig Sat Jun 25 16:04:39 2011
Tgif.tmpl Sat Jun 25 16:04:40 2011
+@@ -44,7 +44,8 @@ MISCDEFINES = -D_BACKGROUND_DONT_FORK -D_USE_XDRAWPOIN
-D_USE_PS_ADOBE_STRING=\3.0/3.0\ -D_DONT_USE_MKTEMP \@@\
-D_DONT_REENCODE=\FFDingbests:ZapfDingbats\ \@@\
-D_NO_NKF -D_NO_CHINPUT -D_NO_XCIN \@@\
Index: patches/patch-setup.c
===
RCS file: /cvs/ports/graphics/tgif/patches/patch-setup.c,v
retrieving revision 1.3
diff -u -r1.3 patch-setup.c
--- patches/patch-setup.c 13 Feb 2007 10:12:08 - 1.3
+++ patches/patch-setup.c 25 Jun 2011 14:10:57 -
@@ -1,6 +1,7 @@
setup.c.orig Wed Jun 14 01:29:59 2006
-+++ setup.cSun Jan 21 12:08:33 2007
-@@ -233,7 +233,7 @@ char drawPath[MAXPATHLENGTH]; /* last ch
+$OpenBSD$
+--- setup.c.orig Sun Jun 19 00:06:08 2011
setup.cSat Jun 25 16:04:40 2011
+@@ -237,7 +237,7 @@ char drawPath[MAXPATHLENGTH]; /* last char is NOT
'/'
char bootDir[MAXPATHLENGTH+2];
char homeDir[MAXPATHLENGTH];
char tgifDir[MAXPATHLENGTH];
Re: PATCH: small fixes to cyphertite and its dependencies
On Sat, Jun 25, 2011 at 03:02:16PM +0100, Mikolaj Kucharski wrote:
On Sat, Jun 25, 2011 at 03:48:20PM +0200, Marc Espie wrote:
@cd ${.CURDIR}; for i in ${HDRS}; do \
cmp -s $$i ${INCDIR}/$$i || \
${INSTALL} ${INSTALL_COPY} -m 444 -o $(BINOWN) -g $(BINGRP) $$i
${DESTDIR}${INCDIR}/; \
echo ${INSTALL} ${INSTALL_COPY} -m 444 -o $(BINOWN) -g $(BINGRP)
$$i ${DESTDIR}${INCDIR}/; \
done
Obvious missing DESTDIR in the cmp line.
Correct, but is there a point to have this line anyway?
Those are normal practices, let that line be, tell people to fix the DESTDIR
though which is an obvious bug.
Re: PATCH: small fixes to cyphertite and its dependencies
On Sat, Jun 25, 2011 at 04:14:35PM +0200, Marc Espie wrote: Those are normal practices, let that line be, tell people to fix the DESTDIR though which is an obvious bug. Fair enough. I will update the patch later this evening or some time tomorrow. -- best regards q#
new: mail/milter-checkrcpt
Hi, Port of dhartmei@'s milter-checkrcpt. pkg/DESC The milter-checkrcpt plugin can be used with the milter API of sendmail(8) to filter mails with invalid recipients. The validity of a recipient address is determined by querying another mail server over SMTP. _milter-checkrcpt is not yet reserved in user.list, but it'll be whatever's next. comments, ok? Cheers, Okan milter-checkrcpt.tgz Description: application/tar-gz
Re: WIP: net/weechat
On Sun, Jun 12, 2011 at 07:49:51PM +0200, Jona Joachim wrote: This is my preliminary port for weechat 0.3.5. I tested it on i386 and amd64. WeeChat (Wee Enhanced Environment for Chat) is a fast and light chat environment for many operating systems. Everything can be done with a keyboard. It is customizable and extensible with scripts. Please test comment. works ok on loognson, I think python would be better in FLAVORS though. Samir.
Re: using dlopen() instead of -lmylib
On Sat, Jun 25, 2011 at 03:03:33PM +0200, Marc Espie wrote: On Sat, Jun 25, 2011 at 12:52:02PM +0200, Alexandre Ratchov wrote: There's code (eg. audio/openal, but not only) that does: dlopen(libsndio.so, ...); and then calls dlsym() for each function and so on. What's the point of doing this instead of simply linking the binary with -lsndio and using functions normally? hints? Misplaced portability concerns from upstreams, and ETOOMUCHWORK from the porter. If it's not too intrusive, telling upstream to forget about old OpenBSD versions and doing the normal linking thing is the way to go. but how using dlopen() would help old OpenBSD versions? do upstream thinks we ship old .so files in base? -- Alexandre
Re: make mplayer build with enca and newly imported libass
On Fri, Jun 24, 2011 at 11:49:06PM +, Stuart Henderson wrote: hmm, why does it think this is enabled in FFmpeg on a system with -current (i.e. post-faac-removal) FFmpeg installed... Checking for FAAC support ... yes (in FFmpeg: yes) So am I right in thinking we want to disable faac due to it's questionable licensing? -- Best Regards Edd Barrett http://www.theunixzoo.co.uk
[NEW] shells/dash
Hello!
Here is dash port.
I'm surprised that needs the great patch (which adds one letter).
What do you think, is correct that text utilities, which have always been a
part most
of all UNIX'es now in a separate package (textutils) and has different names?
$OpenBSD$
$Id: patch-src_mkbuiltins,v 1.2 2011/03/29 14:15:54 mike Exp $
--- src/mkbuiltins.orig Sat Jun 5 13:34:23 2010
+++ src/mkbuiltins Tue Mar 29 17:41:12 2011
@@ -84,7 +84,7 @@ cat \!
*/
!
-sed 's/-[a-z]*//' $temp2 | nl -v 0 | LC_COLLATE=C sort -u -k 3,3 |
+sed 's/-[a-z]*//' $temp2 | gnl -v 0 | LC_COLLATE=C sort -u -k 3,3 |
tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ |
awk '{ printf #define %s (builtincmd + %d)\n, $3, $1}'
printf '\n#define NUMBUILTINS %d\n' $(wc -l $temp2)
# $Id: Makefile,v 1.4 2011/03/29 18:08:30 mike-kmv Exp $
COMMENT=Debian Almquist shell, POSIX-compliant, faster than bash
DISTNAME= dash-0.5.6.1
PKGREVISION=0
CATEGORIES= shells
PKGNAME=${DISTNAME}p${PKGREVISION}
HOMEPAGE= http://gondor.apana.org.au/~herbert/dash/
MASTER_SITES= ${HOMEPAGE}/files/
MAINTAINER= Mike mike-...@yandex.ru
# GPL
PERMIT_PACKAGE_CDROM= Yes
PERMIT_PACKAGE_FTP= Yes
PERMIT_DISTFILES_CDROM= Yes
PERMIT_DISTFILES_FTP= Yes
BUILD_DEPENDS= devel/gmake
BUILD_DEPENDS= textproc/textutils
USE_GMAKE= yes
CONFIGURE_STYLE=gnu
include bsd.port.mk
dash.tar.gz
Description: Binary data
Re: [NEW] shells/dash
On Sat, Jun 25, 2011 at 07:21:19PM +0400, Mike Korbakov wrote:
Hello!
Here is dash port.
I'm surprised that needs the great patch (which adds one letter).
What do you think, is correct that text utilities, which have always been a
part most
of all UNIX'es now in a separate package (textutils) and has different names?
These are the GNU version of those utils, so they're prefixed with a
'g'. (In this case, there's no nl(1) in base though ...)
$OpenBSD$
$Id: patch-src_mkbuiltins,v 1.2 2011/03/29 14:15:54 mike Exp $
--- src/mkbuiltins.orig Sat Jun 5 13:34:23 2010
+++ src/mkbuiltinsTue Mar 29 17:41:12 2011
@@ -84,7 +84,7 @@ cat \!
*/
!
-sed 's/ -[a-z]*//' $temp2 | nl -v 0 | LC_COLLATE=C sort -u -k 3,3 |
+sed 's/ -[a-z]*//' $temp2 | gnl -v 0 | LC_COLLATE=C sort -u -k 3,3 |
Why not use:
awk '{ print FNR-1 $0 }'
and get rid of the dependency on textutils?
tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ |
awk '{ printf #define %s (builtincmd + %d)\n, $3, $1}'
printf '\n#define NUMBUILTINS %d\n' $(wc -l $temp2)
# $Id: Makefile,v 1.4 2011/03/29 18:08:30 mike-kmv Exp $
COMMENT= Debian Almquist shell, POSIX-compliant, faster than bash
DISTNAME= dash-0.5.6.1
PKGREVISION= 0
CATEGORIES= shells
PKGNAME=${DISTNAME}p${PKGREVISION}
Revisions are handled by $REVISION, but there's no need to set a
REVISION for a new port.
HOMEPAGE= http://gondor.apana.org.au/~herbert/dash/
MASTER_SITES= ${HOMEPAGE}/files/
MAINTAINER= Mike mike-...@yandex.ru
# GPL
Should have a version appended.
PERMIT_PACKAGE_CDROM= Yes
PERMIT_PACKAGE_FTP= Yes
PERMIT_DISTFILES_CDROM= Yes
PERMIT_DISTFILES_FTP= Yes
BUILD_DEPENDS=devel/gmake
BUILD_DEPENDS=textproc/textutils
USE_GMAKE=yes
CONFIGURE_STYLE= gnu
include bsd.port.mk
Re: webkit woes
Martin Pelikan wrote: On Fri, Jun 24, 2011 at 01:42:57PM -0500, Chris Bennett wrote: On Fri, Jun 24, 2011 at 07:54:33PM +0200, Matthias Kilian wrote: On Fri, Jun 24, 2011 at 11:06:56AM -0500, Marco Peereboom wrote: My current best theory is that the brand new link prefetch stuff (ugh!) is easting gobs of file descriptors while another site is loading. So when webkit tries to establish a connection to get like favicon or css it runs out and renders the pages sans css or favicon (missing pictures etc etc). The link prefetch can't be disabled since it doesn't have a knob. I am trying to reason with the webkit people (again) that anything prefetch is not really that great for everybody. Well, if there a way we could introduce such a knob in the port then? BTW: I'm against a knob, too. If we patch it locally (in the port), I'm for disabling all the prefetching stuff unconditionally, because it's just plain stupid. If upstream accepts a knob (because they obviously think that prefetching is clever), that's another story. I agree, just get rid of it. If upstream is so big on having this prefetching crap, I doubt they will want even a knob. Just patch it locally unless a knob is really easy. Prefetching stuff is a brilliant idea on a sane internet connection. But people probably want to use their browser in a bush on GPRS 56k modem and share the line with others, too. Also, at least in our country, there are lots of stupid greedy ISPs who bill you based on how much traffic do you transfer. Why should either group of people be limited in favor of the other? Well... Having someone using your credit card to make pre-orders for you in restaurants you might visit in the near future (no kidding, see https://developer.mozilla.org/en/Link_prefetching_FAQ) sounds dangerous, not brilliant. On some sites you will end up pre-fetching decent amount of pron, trojans, whatever because browser decided you might visit in the near future. Come on... Alexey
Re: using dlopen() instead of -lmylib
On Sat, Jun 25, 2011 at 05:05:01PM +0200, Alexandre Ratchov wrote: On Sat, Jun 25, 2011 at 03:03:33PM +0200, Marc Espie wrote: On Sat, Jun 25, 2011 at 12:52:02PM +0200, Alexandre Ratchov wrote: There's code (eg. audio/openal, but not only) that does: dlopen(libsndio.so, ...); and then calls dlsym() for each function and so on. What's the point of doing this instead of simply linking the binary with -lsndio and using functions normally? hints? Misplaced portability concerns from upstreams, and ETOOMUCHWORK from the porter. If it's not too intrusive, telling upstream to forget about old OpenBSD versions and doing the normal linking thing is the way to go. but how using dlopen() would help old OpenBSD versions? do upstream thinks we ship old .so files in base? When dlopen() fails, you can try something else. Whereas linked programs fail to start.
Re: [NEW] shells/dash
On Sat, Jun 25, 2011 at 07:21:19PM +0400, Mike Korbakov wrote: COMMENT= Debian Almquist shell, POSIX-compliant, faster than bash Comment's a bit too long, especially considering that *every* shell is faster than bash.
Re: webkit woes
On Sat, Jun 25, 2011 at 07:44:50PM +0300, Alexey Suslikov wrote: Well... Having someone using your credit card to make pre-orders for you in restaurants you might visit in the near future (no kidding, see https://developer.mozilla.org/en/Link_prefetching_FAQ) sounds dangerous, not brilliant. You mean by reading other site's cookies? How do you use my credit card number if I'm shopping at ebay which prefetches your site (for which the ebay webmaster should be hung anyway) and the only thing you see is the Referrer. What is the difference between automatic pre-loading and simultaneous browsing for example? These bugs will always be in browsers and one feature on top of that doesn't change a damn thing. And even that page talks about having a knob for all this, which is why this discussion started - let the user decide - if he thinks he knows better, it's his choice. for Claudio: Yes, it does use bandwidth. That's what bandwidth is for. And it's not browser decides, it's web creator decides and despite that it will surely be abused, many sites (like news) might benefit from that. Of course, the right way to do it is blocking all the ads, flash and javascript using a proxy and not really being concerned about idiots thinking their website is cooler. But from the user's point of view it doesn't matter - it's just slow. And I don't know if as a public ISP you would start blocking shit that makes pages that people visit slow, how long would it take for someone to notice and start complaining. Even if these filters were perfect. Honestly, how much of your network's traffic is the web? Even those rapidshares full of illegal shit aren't that much of a burden, because everyone is behind 1 or 2 IPs and these sites usually provide content per IP. On some sites you will end up pre-fetching decent amount of pron, trojans, whatever because browser decided you might visit in the near future. It's not whatever browser decided you might visit, it's what the creator of the page decided. So yes, if you are on some warez page, you have higher chance of prefetching potentially malicious crap, but (as was written on the page you linked) the creator can use javascript to trigger the same kind of effect, maybe with lower impact on your browser cache. And he will probably eat up more of your resources that way, which is basically why you need a quad core for surfing the web in Windows these days. It's not the amount of data, it's the way they're processed and served. Try telling some random BFU he should disable javascript for a week. He'll laugh at you then. I believe the right place for this is misc@. -- Martin Pelikan
1 Esfoliação Facial+1 Máscara de Hidratação Facial+1 Drenagem Linf. Facial+1 Massagem Relaxante 34,99 | Caldo Panta =?utf-8?B?bmVpcm8gbm8gTWnDp2EgQmFyIDQsO
www.incriveisofertas.com [IMAGE] Revis�o para sua Moto e para do seu Amor! 2 revis�es Completissima para motos de ate 150 cc, na MotoX, de 100,00 por apenas 29,90. de R$ 100,00 por R$ R$ 29,90 [IMAGE] Delic�a neste friozinho! 54% OFF em Caldo Pantaneiro no Mi�a Bar de R$ 11,00 por apenas R$ 4,99. Compre j� o seu! de R$ 11,00 por R$ R$ 4,99 [IMAGE] Del�cia! 50% OFF em 1 Frozen Yogurt + 1 Topping de R$ 6,00 por R$ 2,99 na YogoFest experimente esta novidade! de R$ 6,00 por R$ R$ 2,99 [IMAGE] Presente para todo momento! Incr�vel Cesta de Caf� da Manh�! De R$65,00 por R$34,99 ( 50% OFF ) de R$ 65,00 por R$ R$ 34,99 [IMAGE] 1 Esfoli��o facial + 1 M�scara de Hidrata��o facial + 1 Drenagem linf�tica facial + 1 Massagem Relaxante, Isso mesmo! Tudo por apenas R$ 34,99 ( 60% OFF ) de R$ 75,00 por R$ R$ 34,99 [IMAGE] Bye Bye Celulite! 01 Sess�o de Manta T�rmica com Infravermelho + Massagem Relaxante para os p�s de R$ 30,00 por apenas R$ 9,90.(67% OFF). Compre at� 5 cupons. de R$ 30,00 por R$ R$ 9,90 [IMAGE] Não desejo mais receber estes e-mails.
Re: webkit woes
On Sat, 25 Jun 2011 13:24:13 +0200 Martin Pelikan wrote: Sorry, Kevin, for double post; forgot the list's address. Just glad you realise and give a click or two. I still can't see any reason for pre-fetching, I know my phone couldn't handle it spending more time processing than downloading anyway and I haven't seen slow downs on my desktops for time. Of course I block ads javascript cookies and caching. I have to really want to use a site that wants javascript from like 10 domains, to stop me from just closing the page or closing my account. Here's an idea, An addon that adds a too much javascript button which goes to. www.currentdomain.com/too-much-scripts-so-im-fucking-off-you-idiot.html Then hopefully they'll notice during a 404 log check.
Re: webkit woes
On Sat, Jun 25, 2011 at 22:14, Martin Pelikan martin.peli...@gmail.com wrote: On Sat, Jun 25, 2011 at 07:44:50PM +0300, Alexey Suslikov wrote: Well... Having someone using your credit card to make pre-orders for you in restaurants you might visit in the near future (no kidding, see https://developer.mozilla.org/en/Link_prefetching_FAQ) sounds dangerous, not brilliant. You mean by reading other site's cookies? How do you use my credit card number if I'm shopping at ebay which prefetches your site (for which the ebay webmaster should be hung anyway) and the only thing you see is the Referrer. What is the difference between automatic pre-loading and simultaneous browsing for example? These bugs will always be in browsers and one feature on top of that doesn't change a damn thing. You didn't get it. The question here, do you want someone/something to make a decision for you? One can put a prefetch link on his page, making your browser to access some data with unknown access policy or license WITHOUT you even knowing about it. After job is done and your activity is logged, you are a copyright or policy violator. And even that page talks about having a knob for all this, which is why this discussion started - let the user decide - if he thinks he knows better, it's his choice. for Claudio: Yes, it does use bandwidth. That's what bandwidth is for. And it's not browser decides, it's web creator decides and despite that it will This is why web has tons of websites with malicious javascript code - because that's what web sites are for :) Prefetching is damn good for attacks because user thinks it is a part of html-some standard and super fast - it is good for me. Alexey
Re: webkit woes
On Sat, Jun 25, 2011 at 11:19:51PM +0300, Alexey Suslikov wrote: You didn't get it. The question here, do you want someone/something to make a decision for you? I don't want webkit making a decision for me, whether I enable this feature on my computer, no matter how stupid would it be. Neither do I want ports to disable it for me for the sake of better security. That's my point. I can see that link-prefetching has its issues, I don't say everyone has to use it unconditionally, I'm just saying if it's used properly, it might help. One can put a prefetch link on his page, making your browser to access some data with unknown access policy or license WITHOUT you even knowing about it. After job is done and your activity is logged, you are a copyright or policy violator. So can the javascripts. XSS is pretty old these days and look how many people are still not getting it. Or you can have an iframe with this content, or img with visibility:hidden; there are dozens of ways to do that. Hell, place a link that says Don't open it, it will harm your computer - what do you think most people would do? This is why web has tons of websites with malicious javascript code - because that's what web sites are for :) Do you really think the websites are made for running javascript code? I, on the other hand, do see that my laptop has a gigE card and on 100M fiber I still wait 5 seconds until every news page loads no matter what the browser is. Something is really really wrong along the way. Do we have to save bandwidth, when I run rtorrent and it flows 5 MB/s? Prefetching is damn good for attacks because user thinks it is a part of html-some standard and super fast - it is good for me. Then he's a stupid user. -- Martin Pelikan
update lang/ghc
Minor update to ghc-7.0.4, with an additional fix for libraries/process
(don't use vfork), which avoids spurious failures on landry@'s bulk
builds.
Heavily tested on amd64.
I want to get this in really soon (tomorrow, or on monday), and I'm
only interested in ok's or in `No, please let me test it on i386
first' replies ;-)
There will follow some bumps (I'll not send those to the list):
devel/alex
devel/bustle
devel/c2hs
devel/cabal-install
devel/cpphs,-main
devel/darcs
devel/gtk2hs-buildtools
devel/happy
devel/hasktags
devel/hscolour
games/monadius
net/hpodder
net/hs-pb
x11/bluetile
x11/xmobar
The following need bumps and minor fixes (which aren't related to
this update); I'll send separate diffs for them:
devel/haddock,-main
devel/haddock,-lib
x11/xmonad,-main
x11/xmonad,-lib
Ciao,
Kili
Index: Makefile
===
RCS file: /cvs/ports/lang/ghc/Makefile,v
retrieving revision 1.55
diff -u -p -r1.55 Makefile
--- Makefile25 Apr 2011 22:06:43 - 1.55
+++ Makefile25 Jun 2011 20:41:42 -
@@ -5,9 +5,7 @@ COMMENT-doc = documentation for GHC
DISTNAME = ghc-${MODGHC_VER}
PKGNAME-main = ghc-${MODGHC_VER}
-REVISION-main =0
PKGNAME-doc = ghc-doc-${MODGHC_VER}
-REVISION-doc = 0
CATEGORIES = lang devel
HOMEPAGE = http://www.haskell.org/ghc/
Index: distinfo
===
RCS file: /cvs/ports/lang/ghc/distinfo,v
retrieving revision 1.24
diff -u -p -r1.24 distinfo
--- distinfo23 Apr 2011 20:52:00 - 1.24
+++ distinfo25 Jun 2011 20:41:42 -
@@ -1,20 +1,20 @@
MD5 (ghc/ghc-6.12.3.20101121-amd64-unknown-openbsd.tar.bz2) =
IQ6FvB0LOTvXIY1z7E26dA==
MD5 (ghc/ghc-6.12.3.20101121-i386-unknown-openbsd.tar.bz2) =
zVTNo1qqvM3a6+T+VrYymA==
-MD5 (ghc/ghc-7.0.3-src.tar.bz2) = ELxemuG1gUBDdu+4XyYP8w==
-MD5 (ghc/testsuite-7.0.3.tar.bz2) = XQgF0Ye1xw4xhLkvuDZcog==
+MD5 (ghc/ghc-7.0.4-src.tar.bz2) = 8WewtFONGlZ4j0P8xmK1aA==
+MD5 (ghc/testsuite-7.0.4.tar.bz2) = FoCSWlV4Idfjq6s2jzf73A==
RMD160 (ghc/ghc-6.12.3.20101121-amd64-unknown-openbsd.tar.bz2) =
ItHT3PpKQf3/uWZmrBlSjWk/aNE=
RMD160 (ghc/ghc-6.12.3.20101121-i386-unknown-openbsd.tar.bz2) =
nDDNC7njDaRMkAgjWNiY0vpOBq0=
-RMD160 (ghc/ghc-7.0.3-src.tar.bz2) = vfmzWLyYUkzI0B2OMbAZe+RxJOE=
-RMD160 (ghc/testsuite-7.0.3.tar.bz2) = sxTffUk4WQw8vFwP9cPe24fh6Vs=
+RMD160 (ghc/ghc-7.0.4-src.tar.bz2) = gHJwQ8IUGgRy+eL//N9ajrn7Vew=
+RMD160 (ghc/testsuite-7.0.4.tar.bz2) = G23LI8DWRU8RHMc1sAnr/zo+0lE=
SHA1 (ghc/ghc-6.12.3.20101121-amd64-unknown-openbsd.tar.bz2) =
5QpZOKQh3ohtLnt0MABH4nBJZ0g=
SHA1 (ghc/ghc-6.12.3.20101121-i386-unknown-openbsd.tar.bz2) =
OMLt3oJBN9kH8Zk9jf3T+LED618=
-SHA1 (ghc/ghc-7.0.3-src.tar.bz2) = Ii7tlJQTcjsfRSGKkI1e5pMP2hs=
-SHA1 (ghc/testsuite-7.0.3.tar.bz2) = YrWWEclvtoMSviKzrD34G8Tg6nw=
+SHA1 (ghc/ghc-7.0.4-src.tar.bz2) = Rpp+1iblO/AvHnNxPeph4XIQb9U=
+SHA1 (ghc/testsuite-7.0.4.tar.bz2) = 1ARouqQFvZtlUsamo/M2GsxDJtQ=
SHA256 (ghc/ghc-6.12.3.20101121-amd64-unknown-openbsd.tar.bz2) =
PpFla5SrgfRNc1VCrKc2lF4orW1pbhZzQ1Euw0roNOE=
SHA256 (ghc/ghc-6.12.3.20101121-i386-unknown-openbsd.tar.bz2) =
oJvspljsABt8DwjULDwjks2kqwM57ke6UkL3b9IHUko=
-SHA256 (ghc/ghc-7.0.3-src.tar.bz2) =
FWFpwo2rg3kiJgoPv8yHPGeZQNgFpzbceK6xtgwTzNk=
-SHA256 (ghc/testsuite-7.0.3.tar.bz2) =
oynKm4VxMl5m96vX0s2J7mPAkOEdCwNduoTsuxzokSE=
+SHA256 (ghc/ghc-7.0.4-src.tar.bz2) =
Gpt42dZsnCHebAky42u4dAakhW8WEb+DvURTm9xu0O0=
+SHA256 (ghc/testsuite-7.0.4.tar.bz2) =
HCfoT4NjWdC5BXFrNfJ5Z5rWKD6xnZqHn2mFT8s8Bgs=
SIZE (ghc/ghc-6.12.3.20101121-amd64-unknown-openbsd.tar.bz2) = 47974406
SIZE (ghc/ghc-6.12.3.20101121-i386-unknown-openbsd.tar.bz2) = 48561471
-SIZE (ghc/ghc-7.0.3-src.tar.bz2) = 24201117
-SIZE (ghc/testsuite-7.0.3.tar.bz2) = 2734742
+SIZE (ghc/ghc-7.0.4-src.tar.bz2) = 24205070
+SIZE (ghc/testsuite-7.0.4.tar.bz2) = 2731917
Index: ghc.port.mk
===
RCS file: /cvs/ports/lang/ghc/ghc.port.mk,v
retrieving revision 1.22
diff -u -p -r1.22 ghc.port.mk
--- ghc.port.mk 23 Apr 2011 20:16:38 - 1.22
+++ ghc.port.mk 25 Jun 2011 20:41:42 -
@@ -4,7 +4,7 @@
# Not yet ported to other architectures
ONLY_FOR_ARCHS = i386 amd64
-MODGHC_VER = 7.0.3
+MODGHC_VER = 7.0.4
SUBST_VARS += MODGHC_VER
MODGHC_BIN = ${LOCALBASE}/bin/ghc
Index: patches/patch-libraries_process_include_runProcess_h
===
RCS file: patches/patch-libraries_process_include_runProcess_h
diff -N patches/patch-libraries_process_include_runProcess_h
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-libraries_process_include_runProcess_h25 Jun 2011
20:41:42 -
@@ -0,0 +1,21 @@
+$OpenBSD$
+
+vfork is for terrorists
+
+--- libraries/process/include/runProcess.h.origMon Jun 13 19:10:12 2011
update devel/haddock
The haddock library needs the ghc-paths library. so add it to
RUN_DEPENDS-lib and bump (in addition to the bump on -main after
the ghc update).
Index: Makefile
===
RCS file: /cvs/ports/devel/haddock/Makefile,v
retrieving revision 1.31
diff -u -p -r1.31 Makefile
--- Makefile23 Apr 2011 21:05:14 - 1.31
+++ Makefile25 Jun 2011 21:04:24 -
@@ -5,7 +5,9 @@ COMMENT-lib = haddock library
DISTNAME = haddock-2.9.2
PKGNAME-main = ${DISTNAME}
+REVISION-main =0
PKGNAME-lib = hs-${DISTNAME}
+REVISION-lib = 0
CATEGORIES = devel
HOMEPAGE = http://www.haskell.org/haddock/
@@ -42,6 +44,9 @@ BUILD_DEPENDS += devel/hs-ghc-paths \
textproc/docbook-xsl \
textproc/libxslt \
${RUN_DEPENDS}
+
+RUN_DEPENDS-lib = ${RUN_DEPENDS} \
+ devel/hs-ghc-paths
USE_GMAKE =Yes
CONFIGURE_STYLE = autoconf no-autoheader
fix x11/xmonad
Enforce Setup.lhs args and the dependency of xmonad-lib on lang/ghc.
Without this, the build fails when run from /usr/ports with SUBDIRLIST
pointing to x11/xmonad,-main x11/xmonad,-lib.
Index: Makefile
===
RCS file: /cvs/ports/x11/xmonad/Makefile,v
retrieving revision 1.27
diff -u -p -r1.27 Makefile
--- Makefile23 Apr 2011 14:32:51 - 1.27
+++ Makefile25 Jun 2011 21:07:47 -
@@ -5,9 +5,9 @@ COMMENT-lib = libraries for runtime con
DISTNAME = xmonad-0.9.2
PKGNAME-main = ${DISTNAME}
-REVISION-main =1
+REVISION-main =2
PKGNAME-lib = ${DISTNAME:S,-,-lib-,}
-REVISION-lib = 1
+REVISION-lib = 2
CATEGORIES = x11
HOMEPAGE = http://www.xmonad.org/
@@ -25,11 +25,7 @@ WANTLIB-lib =
MODULES = lang/ghc converters/libiconv
# No documentation for now (haddock thinks that module `xmonad-0.9.2:Main'
# is defined in multiple files).
-MODGHC_BUILD = cabal hackage register
-
-.if defined (SUBPACKAGE) ${SUBPACKAGE:M-main}
-MODGHC_BUILD +=nort
-.endif
+MODGHC_BUILD = cabal hackage register nort
BUILD_DEPENDS =${RUN_DEPENDS-lib}
RUN_DEPENDS-lib = devel/hs-mtl \
@@ -37,6 +33,14 @@ RUN_DEPENDS-lib =devel/hs-mtl \
x11/hs-X11=1.5.0.0
LIB_DEPENDS-main = ${LIB_DEPENDS} \
devel/gmp
+
+# Instead of adding `nort' to MODGHC_BUILD for -main, explicitely set
+# MODGHC_SETUP_CONF_ARGS and add lang/ghc to RUN_DEPENDS-lib.
+# Otherwise, we may end up in xmonad configured with `nort', which
+# causes xmonad-lib to be installed in the wrong place.
+MODGHC_SETUP_CONF_ARGS += --docdir=\$$datadir/doc/hs-\$$pkgid
+MODGHC_SETUP_CONF_ARGS += --libsubdir=ghc/\$$pkgid
+RUN_DEPENDS-lib += lang/ghc=${MODGHC_VER}
USE_GROFF =Yes
Re: webkit woes
On Fri, Jun 24, 2011 at 05:41:39PM +0200, Antoine Jacoutot wrote: On Fri, 24 Jun 2011, Marco Peereboom wrote: My current best theory is that the brand new link prefetch stuff (ugh!) is easting gobs of file descriptors while another site is loading. So when webkit tries to establish a connection to get like favicon or css it runs out and renders the pages sans css or favicon (missing pictures etc etc). The link prefetch can't be disabled since it doesn't have a knob. I am trying to reason with the webkit people (again) that anything prefetch is not really that great for everybody. Well, if there a way we could introduce such a knob in the port then? So I misread the port and link prefetching *is* disabled. The FD use seems to stem from unclosed and/or connections that are persistent. With the port webkit one sees tons of CLOSE_WAIT connections eating FDs. It seems like webkit forgets to close half open connections. This is true even when destroying a webkit frame; the connections remain there until they timeout. So I compiled it with --disable-web-sockets and the connections go from CLOSE_WAIT to ESTABLISHED but it does have the appearance that sockets are reused much quicker. Web feels snappier too in my very unscientific observation. I am still playing with the options to see if I can find out how to not have any long lived persistent connections. More later. In xxxterm the file descriptor starvation has other fun side effects because it opens and closes files left and right for things like state, bookmarks, etc. The easiest way to see this in action is having like 10 tabs created at startup. This usually results in pages not being rendered correctly and xxxterm complaining it can't open files. There is some evidence too that on top of this there is also a fd leak somewhere as well. -- Antoine
Re: [NEW] shells/dash
On 2011-06-25, Marc Espie es...@nerim.net wrote: On Sat, Jun 25, 2011 at 07:21:19PM +0400, Mike Korbakov wrote: COMMENT= Debian Almquist shell, POSIX-compliant, faster than bash Comment's a bit too long, especially considering that *every* shell is faster than bash. You haven't tried zsh?
Re: webkit woes
On Sat, Jun 25, 2011 at 10:46:03PM +0200, Martin Pelikan wrote: On Sat, Jun 25, 2011 at 11:19:51PM +0300, Alexey Suslikov wrote: ... This is why web has tons of websites with malicious javascript code - because that's what web sites are for :) Do you really think the websites are made for running javascript code? I, on the other hand, do see that my laptop has a gigE card and on 100M fiber I still wait 5 seconds until every news page loads no matter what the browser is. Something is really really wrong along the way. Do we have to save bandwidth, when I run rtorrent and it flows 5 MB/s? The problem with slow loading pages is more because of all the crap they load. Like the facebook and twitter iframes that take ages to load. And prefecthing will make it worse because the servers will all be busy serving prefetching clients of other users that will most probably never visit the site. The problem is that most webdesigners have no clue about how websites are loaded so they build stuff that takes ages to load. Not because of bandwidth issues but more because of people not understanding how TCP works and how to reduce delays. -- :wq Claudio
Re: Webkit on mips64l
On Thu, Jun 23, 2011 at 06:03:57PM -0400, James Turner wrote: On Thu, Jun 23, 2011 at 11:30:15PM +0200, Landry Breuil wrote: On Thu, Jun 23, 2011 at 11:30:50AM -0400, James Turner wrote: I just went through the long process of building webkit 1.4.1 on my yeeloong. It works fairly well until I go to any websites with javascript on them. Webkit segfaults at this point. Below is the output of running backtrace on the coredump. Anyways, I'm sure this is more of a webkit problem then a ports problem, but I thought I'd check here first. In the mean time running surf with javascript disabled works great. Looks like it's time to look back at what got broken in the js engine on mips64 in the 1.4 branch... you're welcome to help look at the bugzilla. I still don't have such hw and my time is low anyway. Landry I'm going to re-compile with --enable-debug. Hopefully this will provide a better backtrace. I'll report back in a couple days when webkit finishes compiling... When attempting to compile with --enable-debug it seems to run out of memory even with the highest ulimit -d I can do, which works with the normal build. Atleast webkit does a better job rendering pages then dillo which doesn't have javascript either so I guess I'm still winning.
Re: Webkit on mips64l
On Sat, Jun 25, 2011 at 05:56:17PM -0400, James Turner wrote: I'm going to re-compile with --enable-debug. Hopefully this will provide a better backtrace. I'll report back in a couple days when webkit finishes compiling... When attempting to compile with --enable-debug it seems to run out of memory even with the highest ulimit -d I can do, which works with the normal build. If you have an amd64 system, you might be able to reproduce the crash on an amd64 debug webkit build, if you compile it with --disable-jit so that JavaScript runs in the interpreter instead of being JIT-compiled. That's what I did when I was having problems with 1.2.x.
Re: [NEW] shells/dash
On 2011-06-25, Mike Korbakov mike-...@yandex.ru wrote: Here is dash port. I'm surprised that needs the great patch (which adds one letter). What do you think, is correct that text utilities, which have always been a part most of all UNIX'es now in a separate package (textutils) and has different names? GNU tools have not by any means been a part of most UNIX-like OS... Anyway it makes more sense to drop textutils and patch to replace nl with cat -n instead. The output format is the same (check with hexdump -C or something if you want to). # $Id: Makefile,v 1.4 2011/03/29 18:08:30 mike-kmv Exp $ We use $OpenBSD$ tags. COMMENT= Debian Almquist shell, POSIX-compliant, faster than bash DISTNAME= dash-0.5.6.1 PKGREVISION= 0 this isn't pkgsrc ;) we use REVISION which automatically sets pwhatever in PKGNAME (so there's no need to touch PKGNAME in the typical case where DISTNAME is sane), but we start with no REVISION line at all, then add REVISION=0 after the first update etc, than go back to no REVISION line when DISTNAME is increased to a new version.. BUILD_DEPENDS=devel/gmake BUILD_DEPENDS=textproc/textutils dep on gmake here is unnecessary, USE_GMAKE sets it. just as well, because your dep on textutils overrides the variable.. I would suggest that for new ports, you start from a current version of /usr/ports/infrastructure/templates/Makefile.template
Re: webkit woes
On 2011-06-25, Martin Pelikan martin.peli...@gmail.com wrote: Yes, it does use bandwidth. That's what bandwidth is for. And it's not browser decides, it's web creator decides and despite that it will surely be abused, many sites (like news) might benefit from that. It's partly browser decides, partly web creator decides, and also search engine decides and some random site linking to some other site decides. For one side of prefetching (DNS queries), it can be educational to install dnstop, run 'dnstop -l 3 interface' and then press 3, then move your mouse pointer around the browser window, try it in various browsers and see how they behave. Some do serious damage to the crappy caching dns resolver in cheap consumer-grade adsl routers... Of course, the right way to do it is blocking all the ads, flash and javascript using a proxy and not really being concerned about idiots thinking their website is cooler. Hang on, didn't you just say it's web creator decides? :-) And he will probably eat up more of your resources that way, which is basically why you need a quad core for surfing the web in Windows these days. No way.
Re: Webkit on mips64l
On Sat, Jun 25, 2011 at 06:11:08PM -0400, Todd Carson wrote: On Sat, Jun 25, 2011 at 05:56:17PM -0400, James Turner wrote: I'm going to re-compile with --enable-debug. Hopefully this will provide a better backtrace. I'll report back in a couple days when webkit finishes compiling... When attempting to compile with --enable-debug it seems to run out of memory even with the highest ulimit -d I can do, which works with the normal build. If you have an amd64 system, you might be able to reproduce the crash on an amd64 debug webkit build, if you compile it with --disable-jit so that JavaScript runs in the interpreter instead of being JIT-compiled. That's what I did when I was having problems with 1.2.x. I do have an amd64 machine, compiling with --disable-jit and --enable-debug now. Thanks for the hint. We will see if I can reproduce the behavior.
Re: PATCH: small fixes to cyphertite and its dependencies
Second try. Ok?
- fix headers installation during fake stage when exactly the same
header file is already installed in the system, this is for various
ports from conformal.com, no bump needed, build only issue
- fix crash at the end of cyphertite session, from upstream cvs
- bump revision for cyphertite
Index: archivers/libshrink/patches/patch-libshrink_Makefile
===
RCS file: archivers/libshrink/patches/patch-libshrink_Makefile
diff -N archivers/libshrink/patches/patch-libshrink_Makefile
--- /dev/null 1 Jan 1970 00:00:00 -
+++ archivers/libshrink/patches/patch-libshrink_Makefile25 Jun 2011
23:55:13 -
@@ -0,0 +1,12 @@
+$OpenBSD$
+--- libshrink/Makefile.origSun May 1 19:50:03 2011
libshrink/Makefile Sun Jun 26 00:23:04 2011
+@@ -23,7 +23,7 @@ LDADD+= -L${LOCALBASE}/lib
+
+ afterinstall:
+ @cd ${.CURDIR}; for i in ${HDRS}; do \
+- cmp -s $$i ${INCDIR}/$$i || \
++ cmp -s $$i ${DESTDIR}${INCDIR}/$$i || \
+ ${INSTALL} ${INSTALL_COPY} -m 444 -o $(BINOWN) -g $(BINGRP) $$i
${DESTDIR}${INCDIR}/; \
+ echo ${INSTALL} ${INSTALL_COPY} -m 444 -o $(BINOWN) -g $(BINGRP) $$i
${DESTDIR}${INCDIR}/; \
+ done
Index: devel/libclog/patches/patch-Makefile
===
RCS file: devel/libclog/patches/patch-Makefile
diff -N devel/libclog/patches/patch-Makefile
--- /dev/null 1 Jan 1970 00:00:00 -
+++ devel/libclog/patches/patch-Makefile25 Jun 2011 23:55:39 -
@@ -0,0 +1,12 @@
+$OpenBSD$
+--- Makefile.orig Tue Jun 14 19:27:35 2011
Makefile Sun Jun 26 00:26:23 2011
+@@ -44,7 +44,7 @@ CFLAGS+= -ggdb3 -I${.CURDIR} -I${INCDIR}
+
+ afterinstall:
+ @cd ${.CURDIR}; for i in ${HDRS}; do \
+- cmp -s $$i ${LOCALBASE}/include/$$i || \
++ cmp -s $$i ${DESTDIR}${LOCALBASE}/include/$$i || \
+ ${INSTALL} ${INSTALL_COPY} -m 444 -o $(BINOWN) -g $(BINGRP) $$i
${DESTDIR}${LOCALBASE}/include; \
+ echo ${INSTALL} ${INSTALL_COPY} -m 444 -o $(BINOWN) -g $(BINGRP) $$i
${DESTDIR}${LOCALBASE}/include;\
+ done
Index: devel/libexude/patches/patch-Makefile
===
RCS file: devel/libexude/patches/patch-Makefile
diff -N devel/libexude/patches/patch-Makefile
--- /dev/null 1 Jan 1970 00:00:00 -
+++ devel/libexude/patches/patch-Makefile 25 Jun 2011 23:55:40 -
@@ -0,0 +1,12 @@
+$OpenBSD$
+--- Makefile.orig Mon Apr 11 19:02:56 2011
Makefile Sun Jun 26 00:28:19 2011
+@@ -36,7 +36,7 @@ HDRS= exude.h
+
+ afterinstall:
+ @cd ${.CURDIR}; for i in ${HDRS}; do \
+- cmp -s $$i ${LOCALBASE}/include/$$i || \
++ cmp -s $$i ${DESTDIR}${LOCALBASE}/include/$$i || \
+ ${INSTALL} ${INSTALL_COPY} -m 444 -o $(BINOWN) -g $(BINGRP) $$i
${DESTDIR}${LOCALBASE}/include; \
+ echo ${INSTALL} ${INSTALL_COPY} -m 444 -o $(BINOWN) -g $(BINGRP) $$i
${DESTDIR}${LOCALBASE}/include;\
+ done
Index: security/assl/patches/patch-Makefile
===
RCS file: security/assl/patches/patch-Makefile
diff -N security/assl/patches/patch-Makefile
--- /dev/null 1 Jan 1970 00:00:00 -
+++ security/assl/patches/patch-Makefile25 Jun 2011 23:56:55 -
@@ -0,0 +1,12 @@
+$OpenBSD$
+--- Makefile.orig Thu May 5 03:46:52 2011
Makefile Sun Jun 26 00:29:52 2011
+@@ -44,7 +44,7 @@ CLEANFILES+= assl.cat3
+
+ afterinstall:
+ @cd ${.CURDIR}; for i in ${HDRS}; do \
+- cmp -s $$i ${LOCALBASE}/include/$$i || \
++ cmp -s $$i ${DESTDIR}${LOCALBASE}/include/$$i || \
+ ${INSTALL} ${INSTALL_COPY} -m 444 -o $(BINOWN) -g $(BINGRP) $$i
${DESTDIR}${LOCALBASE}/include; \
+ echo ${INSTALL} ${INSTALL_COPY} -m 444 -o $(BINOWN) -g $(BINGRP) $$i
${DESTDIR}${LOCALBASE}/include; \
+ done
Index: sysutils/cyphertite/Makefile
===
RCS file: /cvs/ports/sysutils/cyphertite/Makefile,v
retrieving revision 1.3
diff -u -r1.3 Makefile
--- sysutils/cyphertite/Makefile23 Jun 2011 22:50:29 - 1.3
+++ sysutils/cyphertite/Makefile25 Jun 2011 23:57:01 -
@@ -3,6 +3,7 @@
COMMENT = tar-like secure remote deduplicating archiver
DISTNAME = cyphertite-0.1.3
+REVISION = 0
CATEGORIES = sysutils archivers security
HOMEPAGE = https://www.cyphertite.com/
Index: sysutils/cyphertite/patches/patch-ctutil_Makefile
===
RCS file: sysutils/cyphertite/patches/patch-ctutil_Makefile
diff -N sysutils/cyphertite/patches/patch-ctutil_Makefile
--- /dev/null 1 Jan 1970 00:00:00 -
+++ sysutils/cyphertite/patches/patch-ctutil_Makefile 25 Jun 2011 23:57:01
-
@@ -0,0 +1,12 @@
+$OpenBSD$
+--- ctutil/Makefile.orig Thu May 19 19:55:01 2011
ctutil/Makefile
Re: [NEW] shells/dash (correction)
I have tried to consider all comments
26.06.2011, 02:22, Stuart Henderson s...@spacehopper.org:
On 2011-06-25, Mike Korbakov mike-...@yandex.ru; wrote:
Here is dash port.
I'm surprised that needs the great patch (which adds one letter).
What do you think, is correct that text utilities, which have always been a
part most
of all UNIX'es now in a separate package (textutils) and has different
names?
GNU tools have not by any means been a part of most UNIX-like OS...
Anyway it makes more sense to drop textutils and patch to replace nl
with cat -n instead. The output format is the same (check with
hexdump -C or something if you want to).
I didn't mean GNU tools. May be, not most of all old UNIX'es, but most modern
systems has textools.
Read bottom of page:
http://www.freebsd.org/cgi/man.cgi?query=nlapropos=0sektion=1manpath=FreeBSD+Ports+8.2-RELEASEformat=html
historical links:
http://minnie.tuhs.org/cgi-bin/utree.pl?file=pdp11v/usr/src/cmd/nl.c
http://minnie.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/cmd/nl.c
gnl -v 0 , cat -n , awk '{ printFNR-1$0 }' leads to three
different results, just try.
But in our case awk produced usefull code.
# $Id: Makefile,v 1.4 2011/03/29 18:08:30 mike-kmv Exp $
We use $OpenBSD$ tags.
- Corrected ($Id$ because I used cvs repository at sf.net)
COMMENT= Debian Almquist shell, POSIX-compliant, faster than bash
DISTNAME= dash-0.5.6.1
PKGREVISION= 0
this isn't pkgsrc ;) we use REVISION which automatically sets pwhatever
in PKGNAME (so there's no need to touch PKGNAME in the typical case where
DISTNAME is sane), but we start with no REVISION line at all, then add
REVISION=0 after the first update etc, than go back to no REVISION line
when DISTNAME is increased to a new version..
BUILD_DEPENDS= devel/gmake
BUILD_DEPENDS= textproc/textutils
dep on gmake here is unnecessary, USE_GMAKE sets it. just as well,
because your dep on textutils overrides the variable..
I would suggest that for new ports, you start from a current version of
/usr/ports/infrastructure/templates/Makefile.template
Makefile:
# $OpenBSD$
COMMENT=Debian Almquist shell, POSIX-compliant
DISTNAME= dash-0.5.6.1
REVISION= 0
CATEGORIES= shells
HOMEPAGE= http://gondor.apana.org.au/~herbert/dash/
MASTER_SITES= ${HOMEPAGE}files/
MAINTAINER= Mike Korbakov mike-...@yandex.ru
# BSD, GPLv2
PERMIT_PACKAGE_CDROM= Yes
PERMIT_PACKAGE_FTP= Yes
PERMIT_DISTFILES_CDROM= Yes
PERMIT_DISTFILES_FTP= Yes
USE_GMAKE= yes
CONFIGURE_STYLE=gnu
include bsd.port.mk
patches/patch-src_mkbuiltins:
$OpenBSD$
--- src/mkbuiltins.orig Sat Jun 5 13:34:23 2010
+++ src/mkbuiltins Sun Jun 26 02:36:23 2011
@@ -84,7 +84,7 @@ cat \!
*/
!
-sed 's/-[a-z]*//' $temp2 | nl -v 0 | LC_COLLATE=C sort -u -k 3,3 |
+sed 's/-[a-z]*//' $temp2 | awk '{ printFNR-1$0 }' |
LC_COLLATE=C sort -u -k 3,3 |
tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ |
awk '{ printf #define %s (builtincmd + %d)\n, $3, $1}'
printf '\n#define NUMBUILTINS %d\n' $(wc -l $temp2)
dash.tar.gz
Description: Binary data
Re: [NEW] shells/dash (correction)
sorry first link must be http://www.freebsd.org/cgi/man.cgi?query=nlapropos=0sektion=1manpath=FreeBSD+8.2-RELEASEformat=html in which we can see: STANDARDS The nl utility conforms to IEEE Std 1003.1-2001 (``POSIX.1''). HISTORY The nl utility first appeared in ATT System V Release 2 UNIX.
Fixes for OpenAL port.
Here are some fixes for the OpenAL port.
- Use CMake options via CONFIGURE_ARGS to disable unnecessary backends
and unwanted features which also means being able to remove some
patching of CMakeLists.
- Fix hardcoded path in the OpenAL code.
- Fix the pkg-config file to properly list the library dependencies.
Index: Makefile
===
RCS file: /home/cvs/ports/audio/openal/Makefile,v
retrieving revision 1.20
diff -u -p -r1.20 Makefile
--- Makefile25 Jun 2011 18:42:02 - 1.20
+++ Makefile25 Jun 2011 23:37:31 -
@@ -5,26 +5,33 @@ COMMENT = cross-platform 3D audio API
V =20110624
DISTNAME = openal-soft-$V
PKGNAME = openal-$V
+REVISION = 0
CATEGORIES = audio
SHARED_LIBS = openal 2.0
HOMEPAGE = http://kcat.strangesoft.net/openal.html
-# LGPL
+# LGPLv2+
PERMIT_PACKAGE_CDROM = Yes
PERMIT_PACKAGE_FTP = Yes
PERMIT_DISTFILES_CDROM =Yes
PERMIT_DISTFILES_FTP = Yes
-WANTLIB = c m pthread sndio portaudio
+WANTLIB = c m pthread sndio
MASTER_SITES = ${HOMEPAGE:S,.html,-releases/,} \
http://openbsd.fi/dist/
-LIB_DEPENDS = audio/portaudio-svn
MODULES = devel/cmake
+CONFIGURE_STYLE = cmake
+CONFIGURE_ARGS = -DALSA=off -DOSS=off -DSOLARIS=off -DPORTAUDIO=off
-DPULSEAUDIO=off \
+ -DDLOPEN=off
+
NO_REGRESS = Yes
+
+pre-build:
+ @${SUBST_CMD} ${WRKSRC}/Alc/alcConfig.c
post-install:
${INSTALL_DATA_DIR} ${PREFIX}/share/examples/openal
Index: patches/patch-Alc_alcConfig_c
===
RCS file: patches/patch-Alc_alcConfig_c
diff -N patches/patch-Alc_alcConfig_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-Alc_alcConfig_c 25 Jun 2011 23:40:46 -
@@ -0,0 +1,12 @@
+$OpenBSD$
+--- Alc/alcConfig.c.orig Sat Jun 25 19:34:30 2011
Alc/alcConfig.cSat Jun 25 19:34:48 2011
+@@ -226,7 +226,7 @@ void ReadALConfig(void)
+ }
+ }
+ #else
+-f = fopen(/etc/openal/alsoft.conf, r);
++f = fopen(${SYSCONFDIR}/openal/alsoft.conf, r);
+ if(f)
+ {
+ LoadConfigFromFile(f);
Index: patches/patch-Alc_portaudio_c
===
RCS file: patches/patch-Alc_portaudio_c
diff -N patches/patch-Alc_portaudio_c
--- patches/patch-Alc_portaudio_c 25 Jun 2011 18:42:02 - 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,12 +0,0 @@
-$OpenBSD: patch-Alc_portaudio_c,v 1.1 2011/06/25 18:42:02 jasper Exp $
Alc/portaudio.c.orig Sat Jun 25 19:34:32 2011
-+++ Alc/portaudio.cSat Jun 25 19:34:36 2011
-@@ -112,6 +112,8 @@ void *pa_load(void)
- {
- if(!pa_handle)
- {
-+PaError err;
-+
- pa_handle = (void*)0xDEADBEEF;
- if((err=Pa_Initialize()) != paNoError)
- {
Index: patches/patch-CMakeLists_txt
===
RCS file: /home/cvs/ports/audio/openal/patches/patch-CMakeLists_txt,v
retrieving revision 1.1
diff -u -p -r1.1 patch-CMakeLists_txt
--- patches/patch-CMakeLists_txt25 Jun 2011 18:42:02 - 1.1
+++ patches/patch-CMakeLists_txt25 Jun 2011 23:28:01 -
@@ -1,15 +1,6 @@
$OpenBSD: patch-CMakeLists_txt,v 1.1 2011/06/25 18:42:02 jasper Exp $
CMakeLists.txt.origFri Jun 24 03:02:57 2011
-+++ CMakeLists.txt Sat Jun 25 20:46:26 2011
-@@ -50,7 +50,7 @@ OPTION(REQUIRE_PULSEAUDIO Require PulseAudio backend
- OPTION(REQUIRE_COREAUDIO Require CoreAudio backend OFF)
- OPTION(REQUIRE_OPENSL Require OpenSL backend OFF)
-
--OPTION(DLOPEN Check for the dlopen API for loading optional libs ON)
-+OPTION(DLOPEN Check for the dlopen API for loading optional libs OFF)
-
- OPTION(WERROR Treat compile warnings as errors OFF)
-
+--- CMakeLists.txt.origThu Jun 23 20:02:57 2011
CMakeLists.txt Sat Jun 25 19:27:55 2011
@@ -145,13 +145,13 @@ ELSE()
ADD_DEFINITIONS(-Werror)
ENDIF()
@@ -27,19 +18,3 @@ $OpenBSD: patch-CMakeLists_txt,v 1.1 201
Flags used by the compiler during release builds
FORCE)
SET(CMAKE_C_FLAGS_DEBUG -g3 -D_DEBUG CACHE STRING
-@@ -508,6 +508,15 @@ ENDIF()
-
- # Check PortAudio backend
- IF(PORTAUDIO)
-+IF(${CMAKE_SYSTEM_NAME} STREQUAL OpenBSD)
-+INCLUDE(FindPkgConfig)
-+PKG_CHECK_MODULES(PORTAUDIO REQUIRED portaudio-2.0)
-+INCLUDE_DIRECTORIES(${PORTAUDIO_INCLUDE_DIRS})
-+LINK_DIRECTORIES(${PORTAUDIO_LIBRARY_DIRS})
-+SET(HAVE_PORTAUDIO 1)
-+SET(HAVE_LIBPORTAUDIO 1)
-+SET(HAVE_PORTAUDIO_H 1)
-+ENDIF()
- CHECK_INCLUDE_FILE(portaudio.h HAVE_PORTAUDIO_H)
- IF(HAVE_PORTAUDIO_H)
- CHECK_SHARED_LIBRARY_EXISTS(portaudio Pa_Initialize 0
HAVE_LIBPORTAUDIO)
Index: patches/patch-openal_pc_in
