textproc/wkhtmltopdf - switch to QT5
The following diff changes the textproc/wkhtmltopdf port to use QT5 instead of QT4. Any comments? Thanks! Frank Index: Makefile === RCS file: /cvs/ports/textproc/wkhtmltopdf/Makefile,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 Makefile --- Makefile4 Nov 2015 21:11:16 - 1.1.1.1 +++ Makefile15 Nov 2015 08:33:27 - @@ -7,6 +7,7 @@ GH_PROJECT =wkhtmltopdf GH_TAGNAME = 0.12.2.4 DISTNAME = wkhtmltopdf-${GH_TAGNAME} +REVISION = 0 SHARED_LIBS = wkhtmltox 0.0 # 0.12 @@ -19,11 +20,11 @@ MAINTAINER =Frank Groeneveld
Re: NetBeans garbage output problem report
On Sat Nov 14, 2015 at 03:36:36PM -0700, Scott Walters wrote: > Hopefully this is going to the correct place. > http://www.openbsd.org/faq/faq15.html#Problems says to mail the > maintain, and http://openports.se/devel/netbeans gives > http://openports.se/bbmaint.php?maint=ports|a|openbsd.org as the > maintainer. > > The "Output" window in NetBeans shows garbled characters (boxes) when > the green "play arrow"/Run button is pressed. This is reproducible > for me by starting NetBeans, picking "New Project", taking the default > of "Java", naming it "Hello World", then immediately pressing the > green arrow to run the default skeleton project. > NetBeans 8.1 is much better it shows empty output. Only whitespaces or non visible characters :-/ > NetBeans on OpenBSD (5.8, amd64, package current as of the other day) > continues to exhibit this problem first reported in 2008 to the > NetBeans bug tracker: > https://netbeans.org/bugzilla/show_bug.cgi?id=145696 > > No small number of OpenBSD people have chimed in there. > https://netbeans.org/bugzilla/show_bug.cgi?id=224526 seems to be > continuation of that bug. Other platforms are affected by the same > basic failure mode. > > The problem seems to be that NetBeans does not detect the encoding of > output from Maven, nor does it attempt to interrogate Maven's > configuration to learn the encoding it will likely use. For example, > Maven emits UTF-16 and NetBeans interprets it as UTF-8 (or as ASCII, > how the OpenBSD port has its configured). > > scott@fluffy:~$ /usr/local/netbeans/java/maven/bin/mvn --version > Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; > 2013-02-19 06:51:28-0700) > Maven home: /usr/local/netbeans/java/maven > Java version: 1.7.0_80, vendor: Oracle Corporation > Java home: /usr/local/jdk-1.7.0/jre > Default locale: en_US, platform encoding: US-ASCII > OS name: "openbsd", version: "5.8", arch: "amd64", family: "unix" > > I don't know why (stopped investigating at this point), but mvn says > the "Default locale" is "en_US" and platform encoding is "US-ASCII", > but this piece of configuration change (also documented in more detail > on the NetBeans ticket) fixes the garbled output: > > In ~/NetBeansProjects/*/build.xml, at the top level (under ), > where "*" is your project (or repeated for each project), at this: > > > > > org.apache.maven.plugins > maven-resources-plugin > 3.0.5 > > US-ASCII > > > > > > ... needs to match Maven's version. That file is > created for a project after the project is created. Start NetBeans, > create the project, quit, edit the file, restart, then press "play", > and output should be non-garbled (or this worked for me at least). > > I wasn't able to successfully apply this fix to > /usr/local/netbeans/java/maven/conf/settings.xml (perhaps it has a > different structure or needs to be installed somewhere to be used; I > didn't investigate). > > I was able to reproduce this problem in the latest daily developer > release of NetBeans, dated yesterday, in addition to the 6.9.1 in > OpenBSD packages. > > tl;dr It may be possible to fix the garbage from running a project > that shows up in the "Output" window with a config change to Maven or > NetBeans. > Nice hint and thank you, I'll try to apply this advice in netbeans 8.1 port on https://github.com/jasperla/openbsd-wip/tree/master/devel/netbeans Here is 8.1rc2 but I'll commit my finale 8.1 as soon as possible. NetBeans 8.1 comes whiteout netbeans.desktop and a lot of windows/linux/solaris binary crap. Best regards, Rafael
Re: NEW: devel/py-ptyprocess
On 11/14/15 21:31, Edd Barrett wrote: "Launch a subprocess in a pseudo terminal (pty), and interact with both the process and its pty." Needed for terminado, in turn needed by jupyter-notebook. OK? ok rpointel@
NEW: devel/autoconf-archive
Hi, The GNU Autoconf Archive is a collection of more than 500 macros for GNU Autoconf that have been contributed as free software by friendly supporters of the cause from all over the Internet. I've encountered software in the wild (not yet in ports) that uses some of the C++11 macros. ok? -- Anthony J. Bentley autoconf-archive.tar.gz Description: autoconf-archive.tar.gz
Re: NEW: www/py-terminado
On 11/14/15 21:35, Edd Barrett wrote: "A Tornado websocket backend for the term.js Javascript terminal emulator library." Needed by jupyter-notebook. Requires the py-ptyprocess port I just posted. OK? P.S. If you are interested in IPython4 or jupyter-notebook, there's two more deps on-list which also need review (py-traitlets and py-ipython_genutils). Cheers ok rpointel@
Re: textproc/wkhtmltopdf - switch to QT5
On Sun Nov 15, 2015 at 09:36:39AM +0100, Frank Groeneveld wrote: > The following diff changes the textproc/wkhtmltopdf port to use QT5 instead > of QT4. Any comments? > Why? Is there any benefit from Qt5 now? Looks like the next release will require Qt5: https://github.com/wkhtmltopdf/wkhtmltopdf/blob/0.13/README.md#013-alpha Cheers, Rafael
Re: net/tor - add Flavor
On Sat, 14 Nov 2015 21:37:08 +0100, Uwe Werler wrote: > On Sat, Nov 14, 2015 at 08:40:40PM +0100, Pascal Stumpf wrote: > > On Fri, 13 Nov 2015 17:37:12 -0500, Michael McConville wrote: > > > Uwe Werler wrote: > > > > Hello list, > > > > > > > > I'd like to add a Flavor to tor which allows Tor2webMode: > > > > > > This seems like a rare enough use-case that it probably isn't worth a > > > flavor. > > > > I tend to agree. A tor2web proxy is an extremely rare configuration > > compared to the total number of tor nodes. > > I don't think so 'cause it's one possible way e.g. leaking sites may run. This is exactly one of those scenarios that are extremely dangerous. An attacker can trivially expose whistleblowers by inspecting the traffic at the reverse proxy's end. I'm glad if we can stop people from making such mistakes by not providing a tor2web package. > > I am also opposed to the whole model of making .onion sites available > > through clearnet. Where a hidden service is needed, it is mostly for > > content that both the content provider and the recipient may get into > > legal trouble (or worse) in their respective jurisdictions. > > Yeah, maybe. I live in a country where some years ago You could be > hung for listening BBC or radio London. There are countries in the > world where it's illegal to read foreign newspapers or to be gay... > > I think it's not our businness to decide which sites people want to > look for or not. > > > While > > tor2web preserves the content provider's anonymity, it exposes the > > (often naive) end user to uncertain risks. > > I tend to forbit knives 'cause naive people my cut their fingers off. I tend to not give machetes to kids, yes. But still, I'm not stopping anyone from compiling their own tor2web and deploying it. Hell, it's not even that hard to keep a local patch for the port. Just don't expect any support from me. > Or we should remove the -d switch from pfctl too. > > > > > It is protected by no more than simple SSL/TLS, which makes correlation > > attacks even easier, especially considering the very limited number of > > .onion sites out there. An attacker can plausibly deduce the site > > you're looking at just by inspecting the encrypted traffic. > > It's not to keep the user itself anonymously or a proxy e.g. Exactly. And thereby it goes against the fundamental idea of hidden services, namely to keep both the client and the server anonymous. > > Frankly, I don't think it's ethical to provide people with this > > particular gun to shoot themselves in the foot (i.e. ruin their life). > > It's not ethical to pay taxes for governments to shoot innocent people > in other countries. Isn't it? Or should government protect us for > ourself? Irrelevant. This is about OpenBSD ports. > I think it's not the right place here to decide what other people > should or shouldn't do. See above. Not stopping anyone from rolling their own. > > It is a convenience mechanism to access .onion content on the clearnet > > that is on .onion in the first place *for a darn good reason*. > > This is only *one* possible scenario. I told two others which imho > makes more sense than simply making hidden content public available. 2. is just as dangerous; I don't understand why you need tor2web for 3. > > > It also runs the risk that people will think "Tor2web" is what > > > they need (plausible, based on the name) and thereby deanonymize > > > themselves. > > > > >
Re: Bison 3, again
Committed, thank you all who helped to unblock this situation. Cheers, -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: net/tor - add Flavor
IMO the potential risk is high and if I read correctly we haven't seen any numbers how many users need this flavor, just Uwe? :) j.
Re: net/tor - add Flavor
On Sun, Nov 15, 2015 at 07:29:23AM -0500, Jiri B wrote: > IMO the potential risk is high and if I read correctly > we haven't seen any numbers how many users need this flavor, > just Uwe? :) > > j. > Maybe most people don't see a real scenario for this mode. Ok. The potential risk to die is very high if You drive a car too fast or drunken. I think cars shouldn't be selled anymore to people. --
Re: net/tor - add Flavor
On Sun, Nov 15, 2015 at 01:15:03PM +0100, Pascal Stumpf wrote: > On Sat, 14 Nov 2015 21:37:08 +0100, Uwe Werler wrote: > > On Sat, Nov 14, 2015 at 08:40:40PM +0100, Pascal Stumpf wrote: > > > On Fri, 13 Nov 2015 17:37:12 -0500, Michael McConville wrote: > > > > Uwe Werler wrote: > > > > > Hello list, > > > > > > > > > > I'd like to add a Flavor to tor which allows Tor2webMode: > > > > > > > > This seems like a rare enough use-case that it probably isn't worth a > > > > flavor. > > > > > > I tend to agree. A tor2web proxy is an extremely rare configuration > > > compared to the total number of tor nodes. > > > > I don't think so 'cause it's one possible way e.g. leaking sites may run. > > This is exactly one of those scenarios that are extremely dangerous. An > attacker can trivially expose whistleblowers by inspecting the traffic > at the reverse proxy's end. If it's so *trivial* then the whole tor concept is trivial. The hidden service remains hidden and anonymously. If You are right the same is true for any tor entry or exit node. > > I'm glad if we can stop people from making such mistakes by not > providing a tor2web package. I think You are wrong. But's Your opinion. > > > I am also opposed to the whole model of making .onion sites available > > > through clearnet. Where a hidden service is needed, it is mostly for > > > content that both the content provider and the recipient may get into > > > legal trouble (or worse) in their respective jurisdictions. > > > > Yeah, maybe. I live in a country where some years ago You could be > > hung for listening BBC or radio London. There are countries in the > > world where it's illegal to read foreign newspapers or to be gay... > > > > I think it's not our businness to decide which sites people want to > > look for or not. > > > > > While > > > tor2web preserves the content provider's anonymity, it exposes the > > > (often naive) end user to uncertain risks. > > > > I tend to forbit knives 'cause naive people my cut their fingers off. > > I tend to not give machetes to kids, yes. I agree. But I think we have a dissence about which people kids are. > But still, I'm not stopping anyone from compiling their own tor2web and > deploying it. Hell, it's not even that hard to keep a local patch for > the port. That's true. > > Just don't expect any support from me. > Ok. You are the maintainer, it's Your decision. > > Or we should remove the -d switch from pfctl too. > > > > > > > > It is protected by no more than simple SSL/TLS, which makes correlation > > > attacks even easier, especially considering the very limited number of > > > .onion sites out there. An attacker can plausibly deduce the site > > > you're looking at just by inspecting the encrypted traffic. > > > > It's not to keep the user itself anonymously or a proxy e.g. > > Exactly. And thereby it goes against the fundamental idea of hidden > services, namely to keep both the client and the server anonymous. No. The idea of hidden services is to keep the service hidden. The idea of tor as a client is to hide the client. Even it's the same bin it's not automatically the same. The people of tor project developed this mode not without reason. And yes, it's dangerous for *naive* people and that's why it's not compiled in by default and there's no possibility to use it outside tor. > > > > Frankly, I don't think it's ethical to provide people with this > > > particular gun to shoot themselves in the foot (i.e. ruin their life). > > > > It's not ethical to pay taxes for governments to shoot innocent people > > in other countries. Isn't it? Or should government protect us for > > ourself? > > Irrelevant. This is about OpenBSD ports. Exactly this I meant. You argued "ethical". > > I think it's not the right place here to decide what other people > > should or shouldn't do. > > See above. Not stopping anyone from rolling their own. As You already mentioned above. > > > It is a convenience mechanism to access .onion content on the clearnet > > > that is on .onion in the first place *for a darn good reason*. > > > > This is only *one* possible scenario. I told two others which imho > > makes more sense than simply making hidden content public available. > > 2. is just as dangerous; I don't understand why you need tor2web for 3. It's my secred ;). It's possible to build a totally anonymous network on top of tor. This is the basic idea behind that. And access to ressources within this network is only possible through proxies within this private network. > > > > It also runs the risk that people will think "Tor2web" is what > > > > they need (plausible, based on the name) and thereby deanonymize > > > > themselves. > > > > > > > > > --
Re: net/tor - add Flavor
On Sun, Nov 15, 2015 at 07:29:23AM -0500, Jiri B wrote: > IMO the potential risk is high and if I read correctly > we haven't seen any numbers how many users need this flavor, > just Uwe? :) > > j. > And now my last five ct. OpenBSD ships with *sane defaults*. Possible dangerous features You have to enable Yourself. You should know what You're doing. Tor ships with *sane defaults*: 1. You explicitely have to enable this feature and 2. You can't leave the the tor net. Find the difference. Pascal decided not to support this - it's ok. --
Re: textproc/wkhtmltopdf - switch to QT5
On 11/15/15 13:56, Rafael Sadowski wrote: Why? Is there any benefit from Qt5 now? It was suggested earlier on the list and I thought Amit had a good point: On 11/11/15 20:53, Amit Kulkarni wrote: why have multi-packages for the same functionality? eventually the ports@ tree will move towards qt5. qt4 is deprecated and over time will suffer bit-rot, so if it works equally well with stock qt5 (with missing features), IMHO wkhtmltopdf should be switched to work with qt5 only. Are you not able to use the QT5 version? Or is there another reason to use the QT4 version? Frank
UPDATE: devel/ruby-bundler
Attached a diff that updates ruby-bundler to vesion 1.10.6. I use bundler on a daily basis and having the --jobs option available (introduced in 1.5) is a real time saver on big projects. I've tested the new version with a few of my projects on amd64. Any comments? Frank Index: Makefile === RCS file: /cvs/ports/devel/ruby-bundler/Makefile,v retrieving revision 1.9 diff -u -p -r1.9 Makefile --- Makefile11 Oct 2014 19:54:46 - 1.9 +++ Makefile15 Nov 2015 14:33:14 - @@ -2,11 +2,10 @@ COMMENT= ruby application dependency manager -DISTNAME= bundler-1.3.5 -REVISION = 1 +DISTNAME= bundler-1.10.6 CATEGORIES=devel -HOMEPAGE= http://gembundler.com/ +HOMEPAGE= http://bundler.io/ # MIT PERMIT_PACKAGE_CDROM= Yes Index: distinfo === RCS file: /cvs/ports/devel/ruby-bundler/distinfo,v retrieving revision 1.3 diff -u -p -r1.3 distinfo --- distinfo28 Jun 2013 16:44:23 - 1.3 +++ distinfo15 Nov 2015 14:33:14 - @@ -1,2 +1,2 @@ -SHA256 (bundler-1.3.5.gem) = CLiQR/e4KfPhl6KPsb3nTD9c/qFVL5nfuiN/7jDq/+Q= -SIZE (bundler-1.3.5.gem) = 268800 +SHA256 (bundler-1.10.6.gem) = +ykz0SMEzsddrHW5OhywRdoCaykebGWwl0TOuQB2n+4= +SIZE (bundler-1.10.6.gem) = 251392 Index: pkg/PLIST === RCS file: /cvs/ports/devel/ruby-bundler/pkg/PLIST,v retrieving revision 1.3 diff -u -p -r1.3 PLIST --- pkg/PLIST 28 Jun 2013 16:44:23 - 1.3 +++ pkg/PLIST 15 Nov 2015 14:33:14 - @@ -1,27 +1,52 @@ @comment $OpenBSD: PLIST,v 1.3 2013/06/28 16:44:23 jasper Exp $ ${GEM_BIN}/bundle${GEM_BIN_SUFFIX} +${GEM_BIN}/bundler${GEM_BIN_SUFFIX} ${GEM_LIB}/cache/${DISTNAME}.gem ${GEM_LIB}/gems/${DISTNAME}/ ${GEM_LIB}/gems/${DISTNAME}/.gitignore ${GEM_LIB}/gems/${DISTNAME}/.rspec ${GEM_LIB}/gems/${DISTNAME}/.travis.yml ${GEM_LIB}/gems/${DISTNAME}/CHANGELOG.md -${GEM_LIB}/gems/${DISTNAME}/CONTRIBUTE.md +${GEM_LIB}/gems/${DISTNAME}/CODE_OF_CONDUCT.md ${GEM_LIB}/gems/${DISTNAME}/CONTRIBUTING.md +${GEM_LIB}/gems/${DISTNAME}/DEVELOPMENT.md ${GEM_LIB}/gems/${DISTNAME}/ISSUES.md ${GEM_LIB}/gems/${DISTNAME}/LICENSE.md ${GEM_LIB}/gems/${DISTNAME}/README.md ${GEM_LIB}/gems/${DISTNAME}/Rakefile -${GEM_LIB}/gems/${DISTNAME}/UPGRADING.md ${GEM_LIB}/gems/${DISTNAME}/bin/ ${GEM_LIB}/gems/${DISTNAME}/bin/bundle ${GEM_LIB}/gems/${DISTNAME}/bin/bundle_ruby +${GEM_LIB}/gems/${DISTNAME}/bin/bundler ${GEM_LIB}/gems/${DISTNAME}/bundler.gemspec ${GEM_LIB}/gems/${DISTNAME}/lib/ ${GEM_LIB}/gems/${DISTNAME}/lib/bundler/ ${GEM_LIB}/gems/${DISTNAME}/lib/bundler.rb ${GEM_LIB}/gems/${DISTNAME}/lib/bundler/capistrano.rb +${GEM_LIB}/gems/${DISTNAME}/lib/bundler/cli/ ${GEM_LIB}/gems/${DISTNAME}/lib/bundler/cli.rb +${GEM_LIB}/gems/${DISTNAME}/lib/bundler/cli/binstubs.rb +${GEM_LIB}/gems/${DISTNAME}/lib/bundler/cli/cache.rb +${GEM_LIB}/gems/${DISTNAME}/lib/bundler/cli/check.rb +${GEM_LIB}/gems/${DISTNAME}/lib/bundler/cli/clean.rb +${GEM_LIB}/gems/${DISTNAME}/lib/bundler/cli/common.rb +${GEM_LIB}/gems/${DISTNAME}/lib/bundler/cli/config.rb +${GEM_LIB}/gems/${DISTNAME}/lib/bundler/cli/console.rb +${GEM_LIB}/gems/${DISTNAME}/lib/bundler/cli/exec.rb +${GEM_LIB}/gems/${DISTNAME}/lib/bundler/cli/gem.rb +${GEM_LIB}/gems/${DISTNAME}/lib/bundler/cli/init.rb +${GEM_LIB}/gems/${DISTNAME}/lib/bundler/cli/inject.rb +${GEM_LIB}/gems/${DISTNAME}/lib/bundler/cli/install.rb +${GEM_LIB}/gems/${DISTNAME}/lib/bundler/cli/lock.rb +${GEM_LIB}/gems/${DISTNAME}/lib/bundler/cli/open.rb +${GEM_LIB}/gems/${DISTNAME}/lib/bundler/cli/outdated.rb +${GEM_LIB}/gems/${DISTNAME}/lib/bundler/cli/package.rb +${GEM_LIB}/gems/${DISTNAME}/lib/bundler/cli/platform.rb +${GEM_LIB}/gems/${DISTNAME}/lib/bundler/cli/show.rb +${GEM_LIB}/gems/${DISTNAME}/lib/bundler/cli/update.rb +${GEM_LIB}/gems/${DISTNAME}/lib/bundler/cli/viz.rb +${GEM_LIB}/gems/${DISTNAME}/lib/bundler/constants.rb +${GEM_LIB}/gems/${DISTNAME}/lib/bundler/current_ruby.rb ${GEM_LIB}/gems/${DISTNAME}/lib/bundler/definition.rb ${GEM_LIB}/gems/${DISTNAME}/lib/bundler/dep_proxy.rb ${GEM_LIB}/gems/${DISTNAME}/lib/bundler/dependency.rb @@ -31,7 +56,12 @@ ${GEM_LIB}/gems/${DISTNAME}/lib/bundler/ ${GEM_LIB}/gems/${DISTNAME}/lib/bundler/endpoint_specification.rb ${GEM_LIB}/gems/${DISTNAME}/lib/bundler/env.rb ${GEM_LIB}/gems/${DISTNAME}/lib/bundler/environment.rb +${GEM_LIB}/gems/${DISTNAME}/lib/bundler/fetcher/ ${GEM_LIB}/gems/${DISTNAME}/lib/bundler/fetcher.rb +${GEM_LIB}/gems/${DISTNAME}/lib/bundler/fetcher/base.rb +${GEM_LIB}/gems/${DISTNAME}/lib/bundler/fetcher/dependency.rb +${GEM_LIB}/gems/${DISTNAME}/lib/bundler/fetcher/downloader.rb +${GEM_LIB}/gems/${DISTNAME}/lib/bundler/fetcher/index.rb ${GEM_LIB}/gems/${DISTNAME}/lib/bundler/friendly_errors.rb ${GEM_LIB}/gems/${DISTNAME}/lib/bundler/gem_helper.rb ${GEM_LIB}/g
[UPDATE] databases/py-redis
Hi, attached is the diff to update py-redis to latest release. Ok? Cheers, Remi. Index: Makefile === RCS file: /cvs/ports/databases/py-redis/Makefile,v retrieving revision 1.30 diff -u -p -u -p -r1.30 Makefile --- Makefile29 Sep 2015 10:51:14 - 1.30 +++ Makefile15 Nov 2015 15:24:10 - @@ -2,7 +2,7 @@ COMMENT = Python interface to Redis -MODPY_EGG_VERSION =2.10.3 +MODPY_EGG_VERSION =2.10.5 GH_ACCOUNT = andymccurdy GH_PROJECT = redis-py @@ -11,7 +11,6 @@ GH_TAGNAME = ${MODPY_EGG_VERSION} DISTNAME = ${GH_PROJECT}-${MODPY_EGG_VERSION} PKGNAME = py-redis-${MODPY_EGG_VERSION} CATEGORIES = databases -REVISION = 0 HOMEPAGE = https://github.com/andymccurdy/redis-py/ Index: distinfo === RCS file: /cvs/ports/databases/py-redis/distinfo,v retrieving revision 1.21 diff -u -p -u -p -r1.21 distinfo --- distinfo16 Sep 2014 07:14:14 - 1.21 +++ distinfo15 Nov 2015 15:24:10 - @@ -1,2 +1,2 @@ -SHA256 (redis-py-2.10.3.tar.gz) = eu+4Cowu3KVmuNJGXIMscOxh/MfPPPcJUb+dL99S+zY= -SIZE (redis-py-2.10.3.tar.gz) = 84039 +SHA256 (redis-py-2.10.5.tar.gz) = FZg1rF8JgiuzxXi9+Ei50TemfC5K5LeqBTkNrDMIfe8= +SIZE (redis-py-2.10.5.tar.gz) = 86029
[UPDATE] databases/py-sqlite2
Hi, this is the diff to update py-sqlite2 to latest release. Ok? Cheers, Remi. Index: Makefile === RCS file: /cvs/ports/databases/py-sqlite2/Makefile,v retrieving revision 1.26 diff -u -p -u -p -r1.26 Makefile --- Makefile18 Jul 2015 21:11:18 - 1.26 +++ Makefile15 Nov 2015 15:43:37 - @@ -2,18 +2,17 @@ COMMENT = SQLite3 adapter for Python -MODPY_EGG_VERSION =2.6.0 +MODPY_EGG_VERSION =2.8.1 DISTNAME = pysqlite-${MODPY_EGG_VERSION} PKGNAME = py-sqlite2-${MODPY_EGG_VERSION} -REVISION = 5 CATEGORIES = databases devel MAINTAINER = Eric Faurot -HOMEPAGE = https://code.google.com/p/pysqlite/ +HOMEPAGE = https://github.com/ghaering/pysqlite/ -MASTER_SITES = https://pysqlite.googlecode.com/files/ +MODPY_PI = Yes # BSD-like PERMIT_PACKAGE_CDROM = Yes Index: distinfo === RCS file: /cvs/ports/databases/py-sqlite2/distinfo,v retrieving revision 1.12 diff -u -p -u -p -r1.12 distinfo --- distinfo18 Jan 2015 03:13:05 - 1.12 +++ distinfo15 Nov 2015 15:43:37 - @@ -1,2 +1,2 @@ -SHA256 (pysqlite-2.6.0.tar.gz) = VVg01972in/d88iet9ZpgLig1dyTJ3BfXHUueLTjWHk= -SIZE (pysqlite-2.6.0.tar.gz) = 74453 +SHA256 (pysqlite-2.8.1.tar.gz) = dcrhj5ZG8qYTfh+1MC26Z0tpgu6rOigpN36YsTz+oGY= +SIZE (pysqlite-2.8.1.tar.gz) = 79539 Index: patches/patch-setup_cfg === RCS file: patches/patch-setup_cfg diff -N patches/patch-setup_cfg --- patches/patch-setup_cfg 9 Apr 2009 01:05:25 - 1.2 +++ /dev/null 1 Jan 1970 00:00:00 - @@ -1,12 +0,0 @@ -$OpenBSD: patch-setup_cfg,v 1.2 2009/04/09 01:05:25 martynas Exp $ setup.cfg.orig Wed Mar 11 18:31:40 2009 -+++ setup.cfg Sun Mar 22 14:12:42 2009 -@@ -1,6 +1,6 @@ - [build_ext] - #define= --#include_dirs=/usr/local/include --#library_dirs=/usr/local/lib -+include_dirs=_LOCALBASE_/include -+library_dirs=_LOCALBASE_/lib - libraries=sqlite3 - define=SQLITE_OMIT_LOAD_EXTENSION Index: pkg/PLIST === RCS file: /cvs/ports/databases/py-sqlite2/pkg/PLIST,v retrieving revision 1.8 diff -u -p -u -p -r1.8 PLIST --- pkg/PLIST 7 Sep 2010 16:57:03 - 1.8 +++ pkg/PLIST 15 Nov 2015 15:43:37 - @@ -19,11 +19,6 @@ lib/python${MODPY_VERSION}/site-packages lib/python${MODPY_VERSION}/site-packages/pysqlite2/test/factory.pyc lib/python${MODPY_VERSION}/site-packages/pysqlite2/test/hooks.py lib/python${MODPY_VERSION}/site-packages/pysqlite2/test/hooks.pyc -lib/python${MODPY_VERSION}/site-packages/pysqlite2/test/py25/ -lib/python${MODPY_VERSION}/site-packages/pysqlite2/test/py25/__init__.py -lib/python${MODPY_VERSION}/site-packages/pysqlite2/test/py25/__init__.pyc -lib/python${MODPY_VERSION}/site-packages/pysqlite2/test/py25/py25tests.py -lib/python${MODPY_VERSION}/site-packages/pysqlite2/test/py25/py25tests.pyc lib/python${MODPY_VERSION}/site-packages/pysqlite2/test/regression.py lib/python${MODPY_VERSION}/site-packages/pysqlite2/test/regression.pyc lib/python${MODPY_VERSION}/site-packages/pysqlite2/test/transactions.py
Re: [UPDATE] databases/py-redis
Il 15/nov/2015 16:28, "Remi Pointel" ha scritto: > > Hi, > > attached is the diff to update py-redis to latest release. > > Ok? Ok dcoppa@ > Cheers, > > Remi. Ciao! David
Re: Early Look: ruby 2.3.0-preview1
On 11/12/15 07:53, Jeremy Evans wrote: Attached is a port for ruby 2.3.0-preview1. This is useful if you want to test your ruby software to make sure it will run on ruby 2.3, but it won't be committed till the ruby 2.3.0 final release in late December. Release announcement is at: https://www.ruby-lang.org/en/news/2015/11/11/ruby-2-3-0-preview1-released/ Thanks, good work preparing for the release like this! I tested it out and receive errors like this when installing some gems (json, sqlite3) using bundler 1.3.5 from ports: Installing json (1.8.3) Gem::Ext::BuildError: ERROR: Failed to build gem native extension. current directory: /home/frank/.gem/ruby/2.3/gems/json-1.8.3/ext/json/ext/generator /usr/local/bin/ruby23 -r ./siteconf20151115-14676-coy40a.rb extconf.rb creating Makefile current directory: /home/frank/.gem/ruby/2.3/gems/json-1.8.3/ext/json/ext/generator make "DESTDIR=" clean current directory: /home/frank/.gem/ruby/2.3/gems/json-1.8.3/ext/json/ext/generator make "DESTDIR=" compiling generator.c linking shared-object json/ext/generator.so current directory: /home/frank/.gem/ruby/2.3/gems/json-1.8.3/ext/json/ext/generator make "DESTDIR=" install /usr/ports/pobj/ruby-2.3.0-preview1/bin/install -c -m 0755 generator.so ./.gem.20151115-14676-1oavqqb/json/ext /usr/ports/pobj/ruby-2.3.0-preview1/bin/install: not found *** Error 1 in /home/frank/.gem/ruby/2.3/gems/json-1.8.3/ext/json/ext/generator (Makefile:186 'install-so') make install failed, exit code 1 Gem files will remain installed in /home/frank/.gem/ruby/2.3/gems/json-1.8.3 for inspection. Results logged to /home/frank/.gem/ruby/2.3/extensions/x86_64-openbsd/2.3/json-1.8.3/gem_make.out An error occurred while installing json (1.8.3), and Bundler cannot continue. Make sure that `gem install json -v '1.8.3'` succeeds before bundling. Do you think this is a bug in the port? You can reproduce this by running: git clone https://github.com/ivaldi/brimir bundle install --path ~/.gem Let me know if I can help or re-test. Frank
Re: Early Look: ruby 2.3.0-preview1
On Sun, Nov 15, 2015 at 8:03 AM, Frank Groeneveld < frank+openbsd-po...@frankgroeneveld.nl> wrote: > On 11/12/15 07:53, Jeremy Evans wrote: > >> Attached is a port for ruby 2.3.0-preview1. This is useful if you want >> to test your ruby software to make sure it will run on ruby 2.3, but it >> won't be committed till the ruby 2.3.0 final release in late December. >> >> Release announcement is at: >> https://www.ruby-lang.org/en/news/2015/11/11/ruby-2-3-0-preview1-released/ >> > > Thanks, good work preparing for the release like this! I tested it out and > receive errors like this when installing some gems (json, sqlite3) using > bundler 1.3.5 from ports: > > Installing json (1.8.3) > Gem::Ext::BuildError: ERROR: Failed to build gem native extension. > > current directory: > /home/frank/.gem/ruby/2.3/gems/json-1.8.3/ext/json/ext/generator > /usr/local/bin/ruby23 -r ./siteconf20151115-14676-coy40a.rb extconf.rb > creating Makefile > > current directory: > /home/frank/.gem/ruby/2.3/gems/json-1.8.3/ext/json/ext/generator > make "DESTDIR=" clean > > current directory: > /home/frank/.gem/ruby/2.3/gems/json-1.8.3/ext/json/ext/generator > make "DESTDIR=" > compiling generator.c > linking shared-object json/ext/generator.so > > current directory: > /home/frank/.gem/ruby/2.3/gems/json-1.8.3/ext/json/ext/generator > make "DESTDIR=" install > /usr/ports/pobj/ruby-2.3.0-preview1/bin/install -c -m 0755 generator.so > ./.gem.20151115-14676-1oavqqb/json/ext > /usr/ports/pobj/ruby-2.3.0-preview1/bin/install: not found > *** Error 1 in > /home/frank/.gem/ruby/2.3/gems/json-1.8.3/ext/json/ext/generator > (Makefile:186 'install-so') > > make install failed, exit code 1 > > Gem files will remain installed in > /home/frank/.gem/ruby/2.3/gems/json-1.8.3 for inspection. > Results logged to > /home/frank/.gem/ruby/2.3/extensions/x86_64-openbsd/2.3/json-1.8.3/gem_make.out > > An error occurred while installing json (1.8.3), and Bundler cannot > continue. > Make sure that `gem install json -v '1.8.3'` succeeds before bundling. > > Do you think this is a bug in the port? You can reproduce this by running: > git clone https://github.com/ivaldi/brimir > bundle install --path ~/.gem > > Let me know if I can help or re-test. There's various ports that don't build without modifications (textproc/ruby-nokogiri) or that have issues at runtime with ruby 2.3.0-preview1 (www/ruby-capybara). Hopefully these issues will be fixed before the ruby 2.3.0 final release, but they aren't a bug in the port as far as I know. If you believe this is a bug in the port itself, please provide a diff or at least a reason why you think that. Note that the json gem ships with ruby since 1.9. Instead of bundle install, try: gem23 install -G ~/.gem --conservative Thanks, Jeremy
Re: UPDATE: devel/ruby-bundler
On Sun, Nov 15, 2015 at 6:48 AM, Frank Groeneveld < frank+openbsd-po...@frankgroeneveld.nl> wrote: > Attached a diff that updates ruby-bundler to vesion 1.10.6. > > I use bundler on a daily basis and having the --jobs option available > (introduced in 1.5) is a real time saver on big projects. I've tested the > new version with a few of my projects on amd64. > > Any comments? jcs@ sent the same diff a few weeks ago. I gave him the OK, but it hasn't been committed yet, so I'll commit it. Thanks, Jeremy
Re: NEW: devel/autoconf-archive
"Anthony J. Bentley" writes: > Hi, Hi, > The GNU Autoconf Archive is a collection of more than 500 macros for GNU > Autoconf that have been contributed as free software by friendly supporters > of the cause from all over the Internet. > > I've encountered software in the wild (not yet in ports) that uses some > of the C++11 macros. > > ok? If we install those macros in share/aclocal, then they will be available directly via autoreconf and friends, right? I'm not sure whether it is desirable, it's a lot of code and autotools are already ugly enough... Do you know of other OSes which packages those macros in a directly reachable directory? What about installing them in another dir? Maybe I'm being paranoid here, *shrug*. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: Early Look: ruby 2.3.0-preview1
On 11/15/15 18:04, Jeremy Evans wrote: There's various ports that don't build without modifications (textproc/ruby-nokogiri) or that have issues at runtime with ruby 2.3.0-preview1 (www/ruby-capybara). Hopefully these issues will be fixed before the ruby 2.3.0 final release, but they aren't a bug in the port as far as I know. If you believe this is a bug in the port itself, please provide a diff or at least a reason why you think that. I believe this is a bug in the port, because of the error: > /usr/ports/pobj/ruby-2.3.0-preview1/bin/install: not found It seems Ruby is somehow passing the install command to the gem with the build path of ruby-2.3.0-preview1 prepended. Note that the json gem ships with ruby since 1.9. Instead of bundle install, try: gem23 install -G ~/.gem --conservative Thanks, but the bug occurs in various other gems as well, including sqlite3. Thanks. Frank
Re: net/tor - add Flavor
On Sun, Nov 15, 2015 at 7:15 AM, Pascal Stumpf wrote: > This is exactly one of those scenarios that are extremely dangerous. An > attacker can trivially expose whistleblowers by inspecting the traffic > at the reverse proxy's end. The danger here is that browsers send information related to messages sent in other contexts if the user has used that browser in other contexts. Browsers are deliberately security compromised to support various popular revenue models. There are some analogous issues having to do with setting up a web server and the leaky nature of development platforms. But treating this as "extremely dangerous" without offering a path forward means that people need to "roll their own" approaches when faced with related needs. (For example: write one's own web server from scratch, use a tor browser on a discardable and short lived machine which isn't used for anything else and which has no non-tor internetworking capability.) Is that what you are suggesting here? Thanks, -- Raul
Re: Early Look: ruby 2.3.0-preview1
On Sun, Nov 15, 2015 at 9:57 AM, Frank Groeneveld < frank+openbsd-po...@frankgroeneveld.nl> wrote: > On 11/15/15 18:04, Jeremy Evans wrote: > >> There's various ports that don't build without modifications >> (textproc/ruby-nokogiri) or that have issues at runtime with ruby >> 2.3.0-preview1 (www/ruby-capybara). Hopefully these issues will be fixed >> before the ruby 2.3.0 final release, but they aren't a bug in the port as >> far as I know. If you believe this is a bug in the port itself, please >> provide a diff or at least a reason why you think that. >> > > I believe this is a bug in the port, because of the error: > > > /usr/ports/pobj/ruby-2.3.0-preview1/bin/install: not found > > It seems Ruby is somehow passing the install command to the gem with the > build path of ruby-2.3.0-preview1 prepended. I apologize, I obviously didn't read your bug report closely enough. Yes that is a bug in the port, and it's because the port adds a post-install target to fix a bug, which overrides the post-install target in Makefile.inc. Here's a diff for Makefile.inc: Index: Makefile.inc === RCS file: /cvs/ports/lang/ruby/Makefile.inc,v retrieving revision 1.11 diff -u -p -r1.11 Makefile.inc --- Makefile.inc 15 Oct 2014 02:06:35 - 1.11 +++ Makefile.inc 15 Nov 2015 19:06:06 - @@ -28,7 +28,8 @@ SUB ?= ${MACHINE_ARCH:S/amd64/x86_64/} SUBST_VARS += SUB REV FILESDIR ?= ${.CURDIR}/../files +FIX_RBCONFIG = sed 's/INSTALL_ARGS/-c -o ${BINOWN} -g ${BINGRP}/' < \ + ${FILESDIR}/rbconfig_fix.rb >> \ + ${PREFIX}/lib/ruby/${RUBYLIBREV}/${SUB}/rbconfig.rb post-install: - sed 's/INSTALL_ARGS/-c -o ${BINOWN} -g ${BINGRP}/' < \ - ${FILESDIR}/rbconfig_fix.rb >> \ - ${PREFIX}/lib/ruby/${RUBYLIBREV}/${SUB}/rbconfig.rb + ${FIX_RBCONFIG} Here's a new 2.3/Makefile: # $OpenBSD: Makefile,v 1.6 2015/08/22 15:14:14 jeremy Exp $ BROKEN-mips64 = miniruby spins on rbconfig.rb COMMENT-main = object oriented script language with threads COMMENT-gdbm = gdbm interface for ruby COMMENT-tk = tk interface for ruby COMMENT-ri_docs = ri documentation files for ruby VERSION = 2.3.0-preview1 RUBYLIBREV = 2.3 DISTNAME = ruby-${VERSION} SHARED_LIBS = ruby23 0.0 PKGNAME-main = ruby-${VERSION} PKGNAME-gdbm = ruby23-gdbm-${VERSION} PKGNAME-tk = ruby23-tk-${VERSION} PKGNAME-ri_docs = ruby23-ri_docs-${VERSION} PKG_ARCH-ri_docs = * WANTLIB-ri_docs = # empty NEXTVER = 2.4 PKGSPEC-main = ruby->=${RUBYLIBREV},<${NEXTVER} CONFIGURE_ARGS = --program-suffix=23 \ --with-soname=ruby23 \ --with-ruby-version=minor \ --with-mantype=doc \ --enable-pthread \ --enable-ipv6 \ --without-bundled-libffi \ --disable-option-checking CONFIGURE_ENV = LIBruby23_VERSION=${LIBruby23_VERSION} \ ac_cv_prog_DOXYGEN="" \ ac_cv_prog_DOT="" \ DLDFLAGS="-L${LOCALBASE}/lib" MAKE_ENV = DLDFLAGS="-I${LOCALBASE}/lib" ALL_TARGET = V=1 main INSTALL_TARGET = V=1 install-nodoc WANTLIB-main = c crypto ffi gmp m ncurses pthread readline ssl \ util yaml z LIB_DEPENDS-main = devel/gmp \ devel/libyaml \ devel/libffi PSEUDO_FLAVORS= no_x11 no_ri_docs # Do not build the RI docs on slow arches .if ${MACHINE_ARCH:Malpha} || ${MACHINE_ARCH:Marm} || ${MACHINE_ARCH:Mhppa} || ${MACHINE_ARCH:Msparc} || ${MACHINE_ARCH:Mvax} FLAVOR?= no_ri_docs .else FLAVOR?= .endif MULTI_PACKAGES = -main -gdbm WANTLIB-gdbm = c m gdbm gmp pthread ruby23 LIB_DEPENDS-gdbm = databases/gdbm \ devel/gmp \ lang/ruby/${REV},-main>=${VERSION},<${NEXTVER} RUN_DEPENDS-gdbm = .if !${FLAVOR:Mno_x11} MULTI_PACKAGES+= -tk CONFIGURE_ARGS+= --with-tcl-include=${LOCALBASE}/include/tcl8.5 \ --with-tk-include=${LOCALBASE}/include/tk8.5 \ --with-tcllib=tcl85 \ --with-tklib=tk85 \ --with-X11-dir=${X11BASE} WANTLIB-tk = X11 c gmp m pthread ruby23 tcl85 tk85 LIB_DEPENDS-tk = tk->=8.5,<8.6:x11/tk/8.5 \ devel/gmp \ lang/ruby/${REV},-main>=${VERSION},<${NEXTVER} RUN_DEPENDS-tk = .endif .if !${FLAVOR:Mno_ri_docs} MULTI_PACKAGES += -ri_docs ALL_TARGET += rdoc INSTALL_TARGET += install-doc .endif SUBST_VARS += RUBYLIBREV TEST_DEPENDS = ${FULLPKGNAME-main}:${BUILD_PKGPATH} post-extract: rm -rf ${WRKSRC}/ext/fiddle/libffi-* ${WRKSRC}/tool/downloader.rb pre-install: find ${WRKSRC} -name '*.orig' -print0 | xargs -0r rm ${INSTALL_DATA_DIR} ${PREFIX}/share/doc/ruby post-install: ${FIX_RBCONFIG} chmod 444 ${PREFIX}/lib/ruby/gems/*/{cache,specifications}/*.gem* do-test: -cd ${WRKSRC} && make test-sample -cd ${WRKSRC} && make btest-ruby cd ${WRKSRC} && make test-all TESTOPTS="-v -q" .include Thanks, Jeremy
Re: net/tor - add Flavor
On Sun, Nov 15, 2015 at 01:32:25PM -0500, Raul Miller wrote: > But treating this as "extremely dangerous" without offering a path > forward means that people need to "roll their own" approaches when > faced with related needs. The way forward is use tor properly to access hidden services. tor2web was conceived in 2008 to make it easier for whistleblowers to use tor instead of nothing. Unfortunately in 2015 whistleblowers have very good reasons to use something better than tor2web.
Re: NEW: devel/autoconf-archive
On Sun, Nov 15, 2015 at 06:30:48PM +0100, Jérémie Courrèges-Anglas wrote: > "Anthony J. Bentley" writes: > > > Hi, > > Hi, > > > The GNU Autoconf Archive is a collection of more than 500 macros for GNU > > Autoconf that have been contributed as free software by friendly supporters > > of the cause from all over the Internet. > > > > I've encountered software in the wild (not yet in ports) that uses some > > of the C++11 macros. > > > > ok? > > If we install those macros in share/aclocal, then they will be available > directly via autoreconf and friends, right? I'm not sure whether it is > desirable, it's a lot of code and autotools are already ugly enough... > Do you know of other OSes which packages those macros in a directly > reachable directory? What about installing them in another dir? > > Maybe I'm being paranoid here, *shrug*. Precedent here is that we should wait until there is actual need. Like, when you have software in the wild that moves to ports, then this will be the time to consider this.
Re: net/tor - add Flavor
Stefan Sperling: > On Sun, Nov 15, 2015 at 01:32:25PM -0500, Raul Miller wrote: >> But treating this as "extremely dangerous" without offering a path >> forward means that people need to "roll their own" approaches when >> faced with related needs. > > The way forward is use tor properly to access hidden services. Yes, that is the default method of accessing Tor hidden services. > > tor2web was conceived in 2008 to make it easier for whistleblowers > to use tor instead of nothing. Unfortunately in 2015 whistleblowers > have very good reasons to use something better than tor2web. > Not from my understanding exactly. It's not whistleblowers using Tor2Web, but rather those accessing their hidden web site. Tor2Web is mostly a method for non-Tor users to access hidden web sites. There are contexts in which the destination needs to be hidden, but user/source access isn't. Imagine a case in which disclosures are made, and a wide audience is encouraged, such as the media, yet the destination's location needs to be hidden. This discussion has started off with the wrong premise. Yes, Tor2Web doesn't hide the source IP/user. It's not meant to. It's a bridge *into* the Tor network, in most cases a hidden web site, without any illusion of giving the source IP/user anonymity. It's a clear and conscious design decision, not a mistake or something overlooked. Regardless of Pascal's decision on this, Tor2Web is a legitimate tool from the Tor Project with specific goals, somewhat distinct from the usual premises of Tor. Let's get beyond talking about the problems with it versus using Tor Browser and recognize what it's meant for. It's a *server* service that can be employed by a Tor relay. It should be an option for those who want to use a Tor relay for that explicit purpose. g
Re: net/tor - add Flavor
On Sun, Nov 15, 2015 at 08:15:57PM +0100, Stefan Sperling wrote: > On Sun, Nov 15, 2015 at 01:32:25PM -0500, Raul Miller wrote: > > But treating this as "extremely dangerous" without offering a path > > forward means that people need to "roll their own" approaches when > > faced with related needs. > > The way forward is use tor properly to access hidden services. > > tor2web was conceived in 2008 to make it easier for whistleblowers > to use tor instead of nothing. Unfortunately in 2015 whistleblowers > have very good reasons to use something better than tor2web. > Hello Stefan, what do You mean with "use something better"? I'm really interested in Your suggestion. Regards Uwe --
Re: net/tor - add Flavor
Uwe Werler wrote: > On Sun, Nov 15, 2015 at 08:15:57PM +0100, Stefan Sperling wrote: > > On Sun, Nov 15, 2015 at 01:32:25PM -0500, Raul Miller wrote: > > > But treating this as "extremely dangerous" without offering a path > > > forward means that people need to "roll their own" approaches when > > > faced with related needs. > > > > The way forward is use tor properly to access hidden services. > > > > tor2web was conceived in 2008 to make it easier for whistleblowers > > to use tor instead of nothing. Unfortunately in 2015 whistleblowers > > have very good reasons to use something better than tor2web. > > what do You mean with "use something better"? I'm really interested in > Your suggestion. I think this discussion is getting outside the scope of this mailing list. tor-t...@lists.torproject.org is probably a better place for it.
Re: net/tor - add Flavor
On Sun, Nov 15, 2015 at 09:42:23PM +0100, Uwe Werler wrote: > On Sun, Nov 15, 2015 at 08:15:57PM +0100, Stefan Sperling wrote: > > On Sun, Nov 15, 2015 at 01:32:25PM -0500, Raul Miller wrote: > > > But treating this as "extremely dangerous" without offering a path > > > forward means that people need to "roll their own" approaches when > > > faced with related needs. > > > > The way forward is use tor properly to access hidden services. > > > > tor2web was conceived in 2008 to make it easier for whistleblowers > > to use tor instead of nothing. Unfortunately in 2015 whistleblowers > > have very good reasons to use something better than tor2web. > > > > Hello Stefan, > > what do You mean with "use something better"? I'm really interested in Your > suggestion. It depends. As discussed, if tor2web is used to set up a site which receives leaks, IPs making submissions can be de-anonymized so tor2web should not be used in this case. So "something better" might be tor or something else. In the reverse scenario, where a site sends leaks obtained from who knows where out to the open internet from a hidden service location, tor2web may make sense. Or it may not. I'm not quite sure. Tor has so many edge cases as is even if both sides run Tor. I won't believe random stranger's from the internet opinions about any of this. If Pascal is not willing to put effort into maintaining a port flavour for this feature, I won't mind that in the slightest.
Re: Early Look: ruby 2.3.0-preview1
On 11/15/15 20:08, Jeremy Evans wrote: I apologize, I obviously didn't read your bug report closely enough. Yes that is a bug in the port, and it's because the port adds a post-install target to fix a bug, which overrides the post-install target in Makefile.inc. No problem. I tested your fix and it works great. Thanks for solving it and lets hope 2.3 is release soon! Frank
Re: Bison 3, again
On 11/15/15 00:19, Nigel Taylor wrote: > On 11/14/15 22:46, Stuart Henderson wrote: >> On 2015/11/14 21:39, Jérémie Courrèges-Anglas wrote: I have a better solution for this problem encountered with m4, $ diff -u bison-3.0.4{.gm4,}/bison-3.0.4/examples/calc++/calc++-parser.cc --- bison-3.0.4.gm4/bison-3.0.4/examples/calc++/calc++-parser.cc Thu Nov 12 01:25:32 2015 +++ bison-3.0.4/bison-3.0.4/examples/calc++/calc++-parser.cc Sat Nov 14 13:09:05 2015 @@ -1010,7 +1010,7 @@ // The symbols being reduced. for (int yyi = 0; yyi < yynrhs; yyi++) YY_SYMBOL_PRINT (" $" << yyi + 1 << " =", - yystack_[(yynrhs) - (yyi + 1)]); + yystack_[..]); } #endif // YYDEBUG also solves all the similar problems. foreach.m4 redefined m4_bmatch to use a faster method, removing it makes things work. diff is attached to switch back to m4, includes the patch for foreach.m4. The Makefile change to it will add the --gnu argument when bison uses m4. m4 I have now accepts --gnu as an argument, which allows the ac_cv_prog_gnu_m4_gnu=yes to be used. Now all the bison tests pass for m4, same results as gnu m4. ## - ## ## Test results. ## ## - ## 470 tests were successful. 23 tests were skipped. I needed to increase m4 macro arguments to 4digits for torture tests to pass. Skipped tests are for things like java not installed. diff of changes for m4 updated in ~nigel. There maybe other changes, if problems are hit building a release / ports. Index: Makefile === RCS file: /home/cvs/ports/devel/bison/Makefile,v retrieving revision 1.53 diff -u -p -r1.53 Makefile --- Makefile 15 Nov 2015 11:57:35 - 1.53 +++ Makefile 15 Nov 2015 20:33:20 - @@ -3,6 +3,7 @@ COMMENT= GNU parser generator DISTNAME= bison-3.0.4 +REVISION= 0 CATEGORIES= devel MASTER_SITES= ${MASTER_SITE_GNU:=bison/} @@ -13,10 +14,10 @@ PERMIT_PACKAGE_CDROM= Yes WANTLIB= c MODULES= devel/gettext -BUILD_DEPENDS= devel/help2man \ - devel/m4 -RUN_DEPENDS= devel/m4 +BUILD_DEPENDS= devel/help2man +# Only use with m4 that accepts --gnu argument... +CONFIGURE_ENV += ac_cv_prog_gnu_m4_gnu=yes M4="/usr/bin/m4" CONFIGURE_STYLE=gnu CONFIGURE_ARGS= --disable-yacc MODGNU_CONFIG_GUESS_DIRS=${WRKSRC}/build-aux Index: patches/patch-data_c++_m4 === RCS file: patches/patch-data_c++_m4 diff -N patches/patch-data_c++_m4 --- /dev/null 1 Jan 1970 00:00:00 - +++ patches/patch-data_c++_m4 15 Nov 2015 20:16:31 - @@ -0,0 +1,15 @@ +$OpenBSD$ +--- data/c++.m4.orig Fri Jan 16 14:47:42 2015 data/c++.m4 Thu Nov 12 01:20:00 2015 +@@ -100,9 +100,9 @@ m4_define([b4_namespace_open], + m4_define([b4_namespace_close], + [b4_user_code([b4_percent_define_get_syncline([[api.namespace]]) + m4_bpatsubst(m4_dquote(m4_bpatsubst(m4_dquote(b4_namespace_ref[ ]), +-[^\(.\)[ ]*\(::\)?\([^][:]\|:[^:]\)*], ++[^\(.\)[ ]*\(::\)?\([ -9;-Z^-~]\|:[^:]\)*], + [\1])), +- [::\([^][:]\|:[^:]\)*], [} ])[} // ]b4_namespace_ref])]) ++ [::\([ -9;-Z\^-~]\|:[^:]\)*], [} ])[} // ]b4_namespace_ref])]) + + + # b4_token_enums Index: patches/patch-data_m4sugar_foreach_m4 === RCS file: patches/patch-data_m4sugar_foreach_m4 diff -N patches/patch-data_m4sugar_foreach_m4 --- /dev/null 1 Jan 1970 00:00:00 - +++ patches/patch-data_m4sugar_foreach_m4 15 Nov 2015 20:17:33 - @@ -0,0 +1,26 @@ +$OpenBSD$ +--- data/m4sugar/foreach.m4.orig Sun Nov 15 16:48:24 2015 data/m4sugar/foreach.m4 Sun Nov 15 16:49:48 2015 +@@ -120,14 +120,14 @@ m4_define([_m4_case__], + # m4_define([_m4_b], _m4_defn([_m4_bmatch]))_m4_b([$1], [$2], [$3])... + # _m4_b([$1], [$m-1], [$m])_m4_b([], [], [$m+1]_m4_popdef([_m4_b])) + # then invoke m4_unquote(_m4_b($@)), for concatenation with later text. +-m4_define([m4_bmatch], +-[m4_if([$#], 0, [m4_fatal([$0: too few arguments: $#])], +- [$#], 1, [m4_fatal([$0: too few arguments: $#: $1])], +- [$#], 2, [$2], +- [m4_pushdef([_m4_b], [m4_define([_m4_b], +- _m4_defn([_$0]))]_m4_for([3], m4_eval([($# + 1) / 2 * 2 - 1]), +- [2], [_$0_(], [)])[_m4_b([], [],]m4_dquote([$]m4_eval( +- [($# + 1) / 2 * 2]))[_m4_popdef([_m4_b]))])m4_unquote(_m4_b($@))])]) ++#m4_define([m4_bmatch], ++#[m4_if([$#], 0, [m4_fatal([$0: too few arguments: $#])], ++# [$#], 1, [m4_fatal([$0: too few arguments: $#: $1])], ++# [$#], 2, [$2], ++# [m4_pushdef([_m4_b], [m4_define([_m4_b], ++# _m4_defn([_$0]))]_m4_for([3], m4_eval([($# + 1) / 2 * 2 - 1]), ++# [2], [_$0_(], [)])[_m4_b([], [],]m4_dquote([$]m4_eval( ++# [($# + 1) / 2 * 2]))[_m4_popdef([_m4_b]))])m4_unquote(_m4_b($@))])]) + + m4_define([_m4_bmatch], + [m4_if(m4_bregexp([$1], [$2]), [-1], [], [[$3]m4_define([$0])])])