Re[2]: Remove broken window maker dockapps
>Пятница, 27 апреля 2018, 22:12 +05:00 от Jeremie Courreges-Anglas >: > >On Fri, Apr 27 2018, Solene Rapenne < sol...@perso.pw > wrote: >> I propose to remove from the ports tree the following ports. I've not >> been able to figure out since how many time they were broken. >> >> Ports that are not working: >> >> - net/wmnet (only display a blinking arrow, no use) >> >> Do you agree on removal of all, some, none? > >ok jca@ to kill them except for wmnet and wmspaceweather. cc'ing the >MAINTAINER of wmnet. Vladimir, what's your opinion? Sorry for the late reply. wmnet was useful in the dial-up times, when the speeds were measured in kilobytes per second. Nowadays, this dockapp is pretty much useless. I'm for removing it. -- Vladimir Popov
Re: UPDATE: audio/soundtouch
Looking for someone to check and commit the change to the CVS. Elias. 2018-05-02 20:17 GMT-03:00 Elias M. Mariani : > Hi, > I send a diff for soundtouch, minor change in Makefile from version > 1.9.2 to 2.0.0. > > Soundtouch is a dependency of: > audio/audacity > emulators/desmume > multimedia/gstreamer-0.10/plugins-bad,-main > multimedia/gstreamer1/plugins-bad > > Changes from 1.9.2 to 2.0.0: > https://www.surina.net/soundtouch/soundtouch-abi-tracker/compat_report/soundtouch/1.9.2/2.0.0/65640/abi_compat_report.html > > No changes on patches and PLIST. > Thanks. > Elias.
Re: NEW: Spyder + UPDATE: py-rope
Updated to 3.2.8 from 3.2.6.
New spyder.tar.gz attached and also in openbsd-wip:
https://github.com/jasperla/openbsd-wip/tree/master/devel/spyder
Again, thanks Stuart for the help.
Elias.
2018-05-04 17:13 GMT-03:00 Elias M. Mariani :
> Thanks for the help Stuart,
>
>> - stray whitespace in Makefile ( and )
> Fixed.
>
>> - don't include a maintainer line if it's the default (i.e. ports@)
> Fixed.
>
>> - would prefer to see the FLAVOR bits next to MODULES for python
>> things so it's obvious
> Done.
>
>> - RUN_DEPENDS etc should be one entry per line
> Done.
>
>> - why do you @comment the appdata.xml file?
> My mistake, replaced by ${MODPY_COMMENT}, is only for the python3 flavor.
>> - it doesn't use our standard handling for multi-version python ports
>> with py- and py3- prefixes. I think in this case that's alright as it's
>> more of an application than library and upstream has their own py3
>> renaming so it seems better to keep that, however this is a bit ugly:
>>
>> MAJOR_VERSION=
>> .if ${FLAVOR:Mpython3}
>> MAJOR_VERSION= 3
>> PKGNAME = spyder${MODPY_MAJOR_VERSION}-${MODPY_EGG_VERSION}
>> .endif
>>
>> I'd replace it with:
>>
>> .if ${FLAVOR:Mpython3}
>> MAJOR_VERSION= 3
>> PKGNAME=spyder3-${MODPY_EGG_VERSION}
>> .else
>> MAJOR_VERSION=
>> .endif
> Changed in the Makefile, yes, it was ugly...
> The naming convention seems to be attaching a 3 at the end of the
> application name in this cases, even the setup.py itself makes spyder
> or spyder3 executable for the python and python3 version.
>
> I'm working on openbsd-wip, but I will send here a new tar.gz version
> when finished.
spyder.tar.gz
Description: application/gzip
Re: python setuptools
Yep, thanks Daniel. Fixed. 2018-05-04 17:29 GMT-03:00 Daniel Jakots : > On Fri, 4 May 2018 17:03:50 -0300, "Elias M. Mariani" > wrote: > >> Hi, >> For some reason the port in witch I was working (devel/spyder) is >> having some issues. >> When building: >> error: invalid command 'egg_info' >> When installing: >> error: option --single-version-externally-managed not recognized >> Both from the setup.py script. >> Is there any changes that could have affected this ? >> The current Makefile is here: >> https://github.com/jasperla/openbsd-wip/blob/master/devel/spyder/Makefile > > Something like audio/radiotray/patches/patch-setup_py should solve your > issue.
Re: NEW: sysutils/rw
On 04/25/18 20:46, Brian Callahan wrote: Hi ports -- Attached is a simple new port, sysutils/rw. rw is a simple dd(1) replacement utility from Sortix. --- pkg/DESCR: Sortix rw is a program that reads blocks from the standard input and copies them to the standard output until the end of the standard input. rw(1) is designed to be a replacement for dd(1), providing only the core blockwise I/O. It has a standard command line interface with dashed options, useful and efficient defaults, and is simpler because it doesn't support converting the input (e.g. converting ASCII to/from EBCDIC). --- Seems ok here. Upstream seems pretty aggressive about learning how to write portable code and getting packages in every OS, so why not. OK? ~Brian Ping.
Re: UPDATE: math/ginac 1.7.4
On 2018/05/04 17:59, Theo Buehler wrote:
> On Fri, May 04, 2018 at 06:52:40PM +0300, Paul Irofti wrote:
> > On Fri, May 04, 2018 at 12:13:35PM +0200, Theo Buehler wrote:
> > > On Sat, Apr 28, 2018 at 01:42:52PM +0300, Paul Irofti wrote:
> > > > Hi,
> > > >
> > > > Here is a minor update to GiNaC. All tests pass. OK?
> > > >
> > >
> > > Builds and packages fine, confirm that all tests pass. Portcheck is
> > > happy.
> > >
> > > There is one thing:
> > >
> > > 'make lib-depends-check' complains as follows:
> > >
> > > Missing: curses.14 (/usr/local/bin/ginsh) (system lib)
> > > Extra: ncurses.14
> > > WANTLIB += curses
> > > Scanning: ok
> > >
> > > I think that should be fixed.
This is because base started using soname, so the library name as shown
in objdump -p changed. As far as ports/updates go it's basically a noop
but yes please do fix.
> > Like this?
>
> I think so, but I'd rather have an experienced porter confirm this.
LIBCXX is wrong for ports-gcc arches, it should be like this:
${COMPILER_LIBCXX} c cln curses gmp m readline
NEW: sysutils/free
Hi ports -- Attached is a simple new port, sysutils/free. free is a utility that displays the amount of free and used memory in the system. It's a clone of the Linux command of the same name. --- pkg/DESCR: free is a utility that displays the amount of free and used memory in the system. --- It's written by the person who wrote the lscpu command clone in ports, who reached out to me about committing this. Worked for me on amd64 and armv7. OK? ~Brian free.tgz Description: Binary data
Re: new: games/barony
On 05/04/18 16:31, Brian Callahan wrote: On 5/4/2018 4:24 PM, Daniel Jakots wrote: On Fri, 4 May 2018 13:35:27 +0100, David CARLIER wrote: fair enough. here an updated version. A couple of nits: - patches/patch-CMakeLists_txt: maybe a short summary about what it's patching would be nice - in the README: the sh file is a zip? also please fix the useless doas - it would be nice to ask upstream to upload a proper release on their github repo The sh file is a shell script, which just so happens also has the ability to be unzipped to extract the data. It cannot successfully be run as a shell script (on OpenBSD at least), so unzipping is the only option. ~Brian - Makefile: tab vs space issue in PKGNAME, GH_*, and MAINTAINER lines - I'd say to move NO_TEST at the end but ymmv Hopefully this is the last tarball. At least, this one is ok for me if someone wants to import. ~Brian barony.tgz Description: Binary data
Re: new: games/barony
On 5/4/2018 4:24 PM, Daniel Jakots wrote: > On Fri, 4 May 2018 13:35:27 +0100, David CARLIER > wrote: > >> fair enough. here an updated version. > A couple of nits: > - patches/patch-CMakeLists_txt: maybe a short summary about what it's > patching would be nice > - in the README: the sh file is a zip? also please fix the useless doas > - it would be nice to ask upstream to upload a proper release on their > github repo The sh file is a shell script, which just so happens also has the ability to be unzipped to extract the data. It cannot successfully be run as a shell script (on OpenBSD at least), so unzipping is the only option. ~Brian > - Makefile: tab vs space issue in PKGNAME, GH_*, and MAINTAINER lines > - I'd say to move NO_TEST at the end but ymmv >
Re: python setuptools
On Fri, 4 May 2018 17:03:50 -0300, "Elias M. Mariani" wrote: > Hi, > For some reason the port in witch I was working (devel/spyder) is > having some issues. > When building: > error: invalid command 'egg_info' > When installing: > error: option --single-version-externally-managed not recognized > Both from the setup.py script. > Is there any changes that could have affected this ? > The current Makefile is here: > https://github.com/jasperla/openbsd-wip/blob/master/devel/spyder/Makefile Something like audio/radiotray/patches/patch-setup_py should solve your issue.
Re: new: games/barony
On Fri, 4 May 2018 13:35:27 +0100, David CARLIER wrote: > fair enough. here an updated version. A couple of nits: - patches/patch-CMakeLists_txt: maybe a short summary about what it's patching would be nice - in the README: the sh file is a zip? also please fix the useless doas - it would be nice to ask upstream to upload a proper release on their github repo - Makefile: tab vs space issue in PKGNAME, GH_*, and MAINTAINER lines - I'd say to move NO_TEST at the end but ymmv
Re: NEW: Spyder + UPDATE: py-rope
Thanks for the help Stuart,
> - stray whitespace in Makefile ( and )
Fixed.
> - don't include a maintainer line if it's the default (i.e. ports@)
Fixed.
> - would prefer to see the FLAVOR bits next to MODULES for python
> things so it's obvious
Done.
> - RUN_DEPENDS etc should be one entry per line
Done.
> - why do you @comment the appdata.xml file?
My mistake, replaced by ${MODPY_COMMENT}, is only for the python3 flavor.
> - it doesn't use our standard handling for multi-version python ports
> with py- and py3- prefixes. I think in this case that's alright as it's
> more of an application than library and upstream has their own py3
> renaming so it seems better to keep that, however this is a bit ugly:
>
> MAJOR_VERSION=
> .if ${FLAVOR:Mpython3}
> MAJOR_VERSION= 3
> PKGNAME = spyder${MODPY_MAJOR_VERSION}-${MODPY_EGG_VERSION}
> .endif
>
> I'd replace it with:
>
> .if ${FLAVOR:Mpython3}
> MAJOR_VERSION= 3
> PKGNAME=spyder3-${MODPY_EGG_VERSION}
> .else
> MAJOR_VERSION=
> .endif
Changed in the Makefile, yes, it was ugly...
The naming convention seems to be attaching a 3 at the end of the
application name in this cases, even the setup.py itself makes spyder
or spyder3 executable for the python and python3 version.
I'm working on openbsd-wip, but I will send here a new tar.gz version
when finished.
python setuptools
Hi, For some reason the port in witch I was working (devel/spyder) is having some issues. When building: error: invalid command 'egg_info' When installing: error: option --single-version-externally-managed not recognized Both from the setup.py script. Is there any changes that could have affected this ? The current Makefile is here: https://github.com/jasperla/openbsd-wip/blob/master/devel/spyder/Makefile Thanks. Elias.
Re: [UPDATE] Tor Browser 7.5.3 backport to -stable
attila wrote: > Hi ports@, > > Now that 7.5.3 has been committed to -current I'd like to propose a > patch to backport to -stable. This has been lightly tested on an > amd64 -stable machine with all patches. > > We're going to be building and publishing signed packages for -stable > in the way that landry@ does for the regular Mozillan ports. > > Signing Key: https://bits.torbsd.org/pub/OpenBSD/torbsd-pkg.pub > RWSrDOvkXBL2Z8d8BnXpVCOmmtYX/gphG1E6BPWOM2s3XZT+9KDqh0te > Packages:https://bits.torbsd.org/pub/OpenBSD/6.3/packages/amd64/ > > I will announce on our blog (https://torbsd.org) the availability of > signed packages in that directory once the backport patch is accepted. > Until then anything you see there is a mirage. Tried the packages myself, updated tor-browser runs surprisingly fine here on hardware from 2008 with just 2GB of RAM (after a very slow start-up). Have tested it over a couple of days, it crashed once on me, but it's very usable. Almost as usable as SeaMonkey on this machine (shouldn't be a surprise as both are currently based on Firefox 52 ESR). Not sure why NoScript settings are reset after every session though. Maybe this is a bug? Anyway, keep up the great work! I added your repo to my list to check when updating packages, alongside Landry's one for Firefox… ;-] pgpPfv54MZOS3.pgp Description: Semnătură digitală OpenPGP
Re: Which port produces this build output?
On 05/04/18 12:46, Stuart Henderson wrote: On 2018/05/04 11:09, Brian Callahan wrote: On 05/04/18 06:45, Solene Rapenne wrote: Christian Weisgerber writes: I see this splashed on my dpb window. Apparently a port writes to /dev/tty during the build. Any idea which one? 476 loops; 25s; 139520 Kstmts; 4894 Kst/sec 381 loops; 20s; 111675 Kstmts; 4891 Kst/sec 93 loops; 5s; 27261 Kstmts; 4778 Kst/sec it's lang/snobol4 Fix looks like the attached. Rather than patching build infra to avoid the test, would it be simpler to use e.g. /dev/stderr instead of /dev/tty? In this case, I think no. There's no reason to run the tests during the build. It just adds a forced minute of time to every build of snobol4. We can still patch the test to use /dev/stderr instead of /dev/tty of course.
Re: Which port produces this build output?
On 2018/05/04 11:09, Brian Callahan wrote: > > On 05/04/18 06:45, Solene Rapenne wrote: > > Christian Weisgerber writes: > > > > > I see this splashed on my dpb window. Apparently a port writes to > > > /dev/tty during the build. Any idea which one? > > > > > > 476 loops; 25s; 139520 Kstmts; 4894 Kst/sec > > > 381 loops; 20s; 111675 Kstmts; 4891 Kst/sec > > >93 loops; 5s; 27261 Kstmts; 4778 Kst/sec > > it's lang/snobol4 > > > > Fix looks like the attached. Rather than patching build infra to avoid the test, would it be simpler to use e.g. /dev/stderr instead of /dev/tty?
Re: UPDATE: math/ginac 1.7.4
On Fri, May 04, 2018 at 06:52:40PM +0300, Paul Irofti wrote:
> On Fri, May 04, 2018 at 12:13:35PM +0200, Theo Buehler wrote:
> > On Sat, Apr 28, 2018 at 01:42:52PM +0300, Paul Irofti wrote:
> > > Hi,
> > >
> > > Here is a minor update to GiNaC. All tests pass. OK?
> > >
> >
> > Builds and packages fine, confirm that all tests pass. Portcheck is
> > happy.
> >
> > There is one thing:
> >
> > 'make lib-depends-check' complains as follows:
> >
> > Missing: curses.14 (/usr/local/bin/ginsh) (system lib)
> > Extra: ncurses.14
> > WANTLIB += curses
> > Scanning: ok
> >
> > I think that should be fixed.
>
> Like this?
I think so, but I'd rather have an experienced porter confirm this.
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/math/ginac/Makefile,v
> retrieving revision 1.30
> diff -u -p -u -p -r1.30 Makefile
> --- Makefile 4 May 2018 11:11:39 - 1.30
> +++ Makefile 4 May 2018 15:51:59 -
> @@ -5,6 +5,7 @@ COMMENT= GiNaC is Not a Computer Algebra
> DISTNAME=ginac-1.7.4
> SHARED_LIBS += ginac 7.0 # 8.0
> CATEGORIES= math
> +REVISION=0
>
> HOMEPAGE=https://www.ginac.de/
>
> @@ -16,7 +17,7 @@ PERMIT_PACKAGE_CDROM= Yes
> MASTER_SITES=${HOMEPAGE}
> EXTRACT_SUFX=.tar.bz2
>
> -WANTLIB= c m ncurses readline ${LIBCXX} gmp cln
> +WANTLIB= c m curses readline ${LIBCXX} gmp cln
>
> MODULES =lang/python
>
>
Re: UPDATE: math/ginac 1.7.4
On Fri, May 04, 2018 at 12:13:35PM +0200, Theo Buehler wrote:
> On Sat, Apr 28, 2018 at 01:42:52PM +0300, Paul Irofti wrote:
> > Hi,
> >
> > Here is a minor update to GiNaC. All tests pass. OK?
> >
>
> Builds and packages fine, confirm that all tests pass. Portcheck is
> happy.
>
> There is one thing:
>
> 'make lib-depends-check' complains as follows:
>
> Missing: curses.14 (/usr/local/bin/ginsh) (system lib)
> Extra: ncurses.14
> WANTLIB += curses
> Scanning: ok
>
> I think that should be fixed.
Like this?
Index: Makefile
===
RCS file: /cvs/ports/math/ginac/Makefile,v
retrieving revision 1.30
diff -u -p -u -p -r1.30 Makefile
--- Makefile4 May 2018 11:11:39 - 1.30
+++ Makefile4 May 2018 15:51:59 -
@@ -5,6 +5,7 @@ COMMENT=GiNaC is Not a Computer Algebra
DISTNAME= ginac-1.7.4
SHARED_LIBS += ginac 7.0 # 8.0
CATEGORIES=math
+REVISION= 0
HOMEPAGE= https://www.ginac.de/
@@ -16,7 +17,7 @@ PERMIT_PACKAGE_CDROM= Yes
MASTER_SITES= ${HOMEPAGE}
EXTRACT_SUFX= .tar.bz2
-WANTLIB= c m ncurses readline ${LIBCXX} gmp cln
+WANTLIB= c m curses readline ${LIBCXX} gmp cln
MODULES = lang/python
Re: Which port produces this build output?
On 05/04/18 06:45, Solene Rapenne wrote:
Christian Weisgerber writes:
I see this splashed on my dpb window. Apparently a port writes to
/dev/tty during the build. Any idea which one?
476 loops; 25s; 139520 Kstmts; 4894 Kst/sec
381 loops; 20s; 111675 Kstmts; 4891 Kst/sec
93 loops; 5s; 27261 Kstmts; 4778 Kst/sec
it's lang/snobol4
Fix looks like the attached.
~Brian
Index: Makefile
===
RCS file: /cvs/ports/lang/snobol4/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 Makefile
--- Makefile 6 Nov 2017 08:14:14 - 1.1.1.1
+++ Makefile 4 May 2018 15:08:43 -
@@ -25,4 +25,6 @@ CONFIGURE_ARGS = --prefix="${PREFIX}" \
# Reduce PLIST churn at update time.
FAKE_FLAGS = DOC_DIR="${DESTDIR}${PREFIX}/share/doc/snobol4"
+TEST_TARGET = timing.out
+
.include
Index: patches/patch-Makefile2_m4
===
RCS file: /cvs/ports/lang/snobol4/patches/patch-Makefile2_m4,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 patch-Makefile2_m4
--- patches/patch-Makefile2_m4 6 Nov 2017 08:14:14 - 1.1.1.1
+++ patches/patch-Makefile2_m4 4 May 2018 15:08:43 -
@@ -3,7 +3,48 @@ $OpenBSD: patch-Makefile2_m4,v 1.1.1.1 2
Index: Makefile2.m4
--- Makefile2.m4.orig
+++ Makefile2.m4
-@@ -636,9 +636,9 @@ install: snobol4 sdb timing.out $(GENERATED_DOCS)
+@@ -233,7 +233,7 @@ GENERATED_DOCS= $(GENERATED_DOCS_DOCDIR)
+
+ .PRECIOUS: $(SNOBOL4).o data_init.o snobol4
+
+-all: build_all timing.out
++all: sdb xsnobol4 $(GENERATED_DOCS) $(MODULES_GENERATED)
+
+ BUILD_ALL=sdb snobol4 snopea $(GENERATED_DOCS)
+ build_all: $(BUILD_ALL)
+@@ -250,6 +250,7 @@ xsnobol4: $(OBJS)
+ $(CC) $(CFLAGS) -c build.c
+ rm -f xsnobol4$(EXT)
+ $(CC) -o xsnobol4 $(OBJS) build.o $(LDFLAGS)
++ cp xsnobol4$(EXT) snobol4$(EXT)
+
+ changequote([,])dnl
+
+@@ -608,13 +609,13 @@ llib-lf.ln:
+
+ SNOPEA=./snobol4 -N -Isnolib -I. snopea.in
+
+-snopea.1: snopea snolib/snopea.sno snobol4
++snopea.1: snopea snolib/snopea.sno xsnobol4
+ $(SNOPEA) snopea snopea.1
+
+-snopea.1.html: snopea snolib/snopea.sno snobol4
++snopea.1.html: snopea snolib/snopea.sno xsnobol4
+ $(SNOPEA) snopea snopea.1.html
+
+-$(GENERATED_DOCS_DOCDIR): snopea snolib/snopea.sno snobol4
++$(GENERATED_DOCS_DOCDIR): snopea snolib/snopea.sno xsnobol4
+ cd doc; make
+
+ #
+@@ -630,15 +631,15 @@ GENSNOLIB=host.sno config.sno
+
+ SNOLIB_FILES=snolib/*.sno $(GENSNOLIB) $(MODULES_INCLUDE)
+
+-install: snobol4 sdb timing.out $(GENERATED_DOCS)
++install: xsnobol4 sdb $(GENERATED_DOCS)
+ $(INSTALL) -d $(BINDIR)
+ $(INSTALL) $(INSTALL_BIN_FLAGS) snobol4 $(BINDIR)/snobol4-$(VERS)
$(INSTALL) sdb $(BINDIR)/sdb-$(VERS)
$(INSTALL) snopea $(BINDIR)/snopea-$(VERS)
rm -f $(BINDIR)/snobol4 $(BINDIR)/sdb $(BINDIR)/snopea
Re: new: games/barony
David CARLIER writes: > fair enough. here an updated version. > > On 4 May 2018 at 08:10, Solene Rapenne wrote: > Nice work ! I think it's good now :) ok solene@
Re: ELK updates (elasticsearch, logstash, kibana) + new: sysutils/x-pack
Hi,
Am Donnerstag, Mai 03, 2018 16:27 CEST, Stuart Henderson
schrieb:
> On 2018/05/03 15:54, Sebastian Reitenbach wrote:
> > Hi,
> >
> > Am Freitag, April 27, 2018 13:58 CEST, Pavel Korovin
> > schrieb:
> >
> > > Dear all,
> > >
> > > Please find updates for
> > > sysutils/logstash
> > > textproc/elasticsearch
> > > www/kibana
> > > and new sysutils/x-pack port attached.
> >
> >
> > I installed/updated all but the x-pack, but I still don't get logstash
> > starting up with beats plugin with SSL enabled,
> > seems I still hit:
> > https://github.com/logstash-plugins/logstash-input-beats/issues/188
>
> "still" -> sounds like this isn't any worse with the updates?
with the current logstash 2.4.0, I can setup SSL between filebeat and logstash.
The "still" refers to other intermediate versions I tried from the 5.x logstash
series.
>
> > Here's my beats input config snippet, otherwise, using more or less the
> > defaults that the updated package installs:
> >
> > cat /etc/logstash/conf.d/filebeat.yml
> >
> >
> > input {
> > beats {
> > host => "127.0.0.1"
> > port => 12364
> > ssl => true
> > ssl_certificate => "/etc/logstash/logstash.crt"
> > ssl_key => "/etc/logstash/logstash.key"
> > ssl_certificate_authorities => [ "/etc/logstash/logstash-ca.crt" ]
> > ssl_verify_mode => "force_peer"
> > cipher_suites => [ 'TLS_RSA_WITH_AES_256_CBC_SHA' ]
> > # cipher_suites => [ 'TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256' ]
> > }
> > }
> > ...
> >
> >
> > I tried to play with different ciphers, but to no avail. Some more info I
> > added to the issue mentioned above.
> > But maybe I'm missing something obvious, so if someone gets the beats input
> > to work with SSL I'm all ears
>
> I'm not using any of this stuff, but could this be as simple as having
> to build OpenBSD .so files for netty-tcnative (similar to what I'm having
> to do for snappy-java with net/unifi)?
>
I checked what you did there, and that might work.
A quick try building netty-tcnactive following instructions here:
http://netty.io/wiki/forked-tomcat-native.html#building-on-linux
It failed on me like this:
however, it quickly fails like this for me:
[INFO]
[INFO] Reactor Summary:
[INFO]
[INFO] Netty/TomcatNative [Parent] 2.0.9.Final-SNAPSHOT ... SUCCESS [ 29.771 s]
[INFO] Netty/TomcatNative [OpenSSL - Dynamic] . FAILURE [ 9.080 s]
[INFO] Netty/TomcatNative [OpenSSL - Static] .. SKIPPED
[INFO] Netty/TomcatNative [BoringSSL - Static] SKIPPED
[INFO] Netty/TomcatNative [LibreSSL - Static] 2.0.9.Final-SNAPSHOT SKIPPED
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 44.556 s
[INFO] Finished at: 2018-05-04T14:47:03+02:00
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile) on
project netty-tcnative: Compilation failure -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile) on
project netty-tcnative: Compilation failure
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:213)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:154)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:146)
and I'm lost here, that doesn't tell me anything. My Maven/java knowledge is
rather limited.
However, when it even would come to build boringssl-static,I guess the
boringssl-static/pom.xml might need
some tweaks as well, adding some OpenBSD target.
Sebastian
Re: update: www/weboob 1.3
On Tue, Apr 17, 2018 at 04:49:49PM +0200, Sebastien Marie wrote:
> Hi,
>
> The weboob version we have in ports is a bit old (1.0 is from
> 2014-10-17).
>
> Here an update to latest version 1.3 (2017-09-20).
>
> It switchs from qt4 to qt5. I added NO_TEST as the testsuite looks like:
> "Ran 0 tests in 0.000s"
>
> For the dependency list, I have mostly stolen it from freebsd port
> www/py-weboob.
>
> I am not very confident in the update, but as I am unable to use the
> current port without it fails when I tried some bank modules... at least
> it works with 1.3.
>
Hi,
Here a new diff more complete.
>From previous diff, some missing RUN_DEPENDS has been added. I also be
able to make the testsuite to run. But it fails (it fails also in CI at
upstream, so nothing new here).
I also added python3 flavor. As it adds lot of complexity in the port,
some explanation: the core of Weboob (what the port contains) is python3
compatible. But lot of backends (modules downloaded at runtime using
weboob-config) aren't compatible. So to let users has more possibilities,
I included the two.
Thanks.
--
Sebastien Marie
Index: Makefile
===
RCS file: /cvs/ports/www/weboob/Makefile,v
retrieving revision 1.6
diff -u -p -r1.6 Makefile
--- Makefile29 Sep 2015 10:53:17 - 1.6
+++ Makefile4 May 2018 12:35:59 -
@@ -2,9 +2,8 @@
COMMENT = web out of browsers
-MODPY_EGG_VERSION =1.0
+MODPY_EGG_VERSION =1.3
DISTNAME = weboob-${MODPY_EGG_VERSION}
-REVISION = 3
CATEGORIES = www
HOMEPAGE = http://weboob.org
@@ -12,35 +11,93 @@ HOMEPAGE = http://weboob.org
# AGPLv3+
PERMIT_PACKAGE_CDROM = Yes
-MASTER_SITES = https://symlink.me/attachments/download/289/
+MASTER_SITES = https://symlink.me/attachments/download/356/
MODULES = lang/python
+FLAVORS = python3
+FLAVOR ?=
+
USE_GMAKE =Yes
MODPY_SETUPTOOLS = Yes
MODPY_DISTUTILS_BUILDARGS = --qt --xdg
-BUILD_DEPENDS += x11/py-qt4
-RUN_DEPENDS = devel/desktop-file-utils \
+BUILD_DEPENDS += x11/py-qt5${MODPY_FLAVOR}
+RUN_DEPENDS += devel/desktop-file-utils \
x11/gtk+3,-guic \
- www/py-mako \
- www/py-clientform \
- www/py-mechanize \
- www/py-requests \
- www/py-routes \
- www/py-webob \
- devel/py-dateutil \
- devel/py-gdata \
- devel/py-html5lib \
- devel/py-simplejson \
- converters/py-html2text \
- graphics/py-Pillow \
- x11/py-qt4 \
- textproc/py-prettytable \
- textproc/py-feedparser \
- textproc/py-lxml \
- textproc/py-cssselect \
- textproc/py-yaml
+ converters/py-html2text${MODPY_FLAVOR} \
+ devel/py-dateutil${MODPY_FLAVOR} \
+ devel/py-html5lib${MODPY_FLAVOR} \
+ devel/py-simplejson${MODPY_FLAVOR} \
+ devel/py-six${MODPY_FLAVOR} \
+ graphics/py-Pillow${MODPY_FLAVOR} \
+ net/curl \
+ security/gnupg \
+ textproc/py-lxml${MODPY_FLAVOR} \
+ textproc/py-feedparser${MODPY_FLAVOR} \
+ textproc/py-prettytable${MODPY_FLAVOR} \
+ textproc/py-yaml${MODPY_FLAVOR} \
+ textproc/py-cssselect${MODPY_FLAVOR} \
+ www/py-requests${MODPY_FLAVOR} \
+ x11/py-qt5${MODPY_FLAVOR}
+
+TEST_DEPENDS +=${RUN_DEPENDS} \
+ devel/py-coverage${MODPY_FLAVOR} \
+ devel/py-nose${MODPY_FLAVOR} \
+ shells/bash
+
+.if ${FLAVOR:Mpython3}
+PKGNAME = weboob${MODPY_MAJOR_VERSION}-${MODPY_EGG_VERSION}
+.else
+RUN_DEPENDS += devel/py-futures \
+ www/py-mechanize
+.endif
+
+WEBOOB_BINARIES = boobank boobathon boobcoming boobill booblyrics boobmsg \
+ boobooks boobsize boobtracker cineoob comparoob cookboob \
+ flatboob galleroob geolooc handjoob havedate monboob \
+ parceloob pastoob qbooblyrics qboobmsg qcineoob qcookboob \
+ qflatboob qhandjoob qhavedate qvideoob qwebcontentedit \
+ radioob shopoob suboob translaboob traveloob videoob \
+ webcontentedit weboob weboob-cli weboob-config \
+ weboob-config-qt weboob-debug weboob-repos weboorrents \
+ wetboobs
+
+post-install:
+ rm -f ${PREFIX}/man/man1/masstransit.1 \
+ ${PREFIX}/share/applications/qgalleroob.desktop \
+ ${PREFIX}/share/applications/masstransit.desktop \
+ ${PREFIX}/share/icons/hicolor/64x64/apps/allomatch.png \
+ ${PREFIX}/share/icons/hicolor/64x64/apps/banquepopulaire.png \
+ ${PREFIX}/share/icons/hicolor/64x64/apps/google.png \
+ ${PREFIX}/share/ic
Re: new: games/barony
fair enough. here an updated version. On 4 May 2018 at 08:10, Solene Rapenne wrote: > > David CARLIER writes: > > > slightly update version with all your inputs. > > > > I don't know if it's preferable but I would have renamed the binary > barony-bin and named the launcher barony. So that users just type > "barony" to get the game with the correct saving folder. > > Also, someone on IRC (sorry anonymous, I don't remember your name ) > noticed that the echo should send text to stderr in the launcher script. > > 4c4 > < cd ~/.barony || (echo "Can't cd into ~/.barony"; exit 1) > --- > > cd ~/.barony || (echo "Can't cd into ~/.barony" >&2 ; exit 1) > barony.tgz Description: application/compressed-tar
Re: update www/sope www/sogo to 4.0.0
Hi, Am Mittwoch, Mai 02, 2018 23:10 CEST, Landry Breuil schrieb: > On Wed, May 02, 2018 at 10:28:57PM +0200, Sebastian Reitenbach wrote: > > Hi, > > > > > > > > Am Montag, April 30, 2018 15:20 CEST, Landry Breuil > > schrieb: > > > > > On Fri, Mar 09, 2018 at 11:55:48AM +0100, Sebastian Reitenbach wrote: > > > > > > > > > > Wouldn't it be better to use upstream's standard names? Then a simple > > > > > wildcard works, it matches their usual setup, and you don't have the > > > > > inconsistency you have here where some files are renamed with > > > > > -postgres and others aren't. > > > > > > > > > > > > yeah, with the loop in my updated version, I use the standard names, and > > > > I dropped some legacy scripts. > > > > > > Can you resend the updated version ? it seems it never made it to the > > > list, and now that i've upgraded my work server to 6.3 i might give it a > > > shot.. > > > > > > > great, thanks! See below. > > > > ? sogo/patches/patch-Scripts_sql-update-3_2_10_to_4_0_0-mysql_sh > > ? sogo/patches/patch-Scripts_sql-update-3_2_10_to_4_0_0_sh > > Forgotten ? patches not needed ? > indeed forgotten, sorry, updated patch attached. Sebastian sope-sogo-4.0.diff Description: Binary data
Re: mail/mailpile requires python in BUILD_DEPENDS
On Thu, May 03 2018, Solene Rapenne wrote:
> naddy@ founds in his latest bulk build that mailpile was failing due to
> python missing at do-install target.
duh
> sthen@ proposed to set an empty do-build target and remove NO_BUILD so
> the module lang/python will set the BUILD_DEPENDS variable correctly.
Sounds reasonable. It would have been nice to just set explicitely
"MODPY_BUILDDEP=Yes" and have that variable honored, but python.port.mk
doesn't work like that. ok jca@, but please see comments below.
> After this patch, `make print-build-depends` shows the following instead
> of nothing :
>
> This port requires package(s) "bzip2-1.0.6p8 metaauto-1.0p1 xz-5.2.3p0
> help2man-1.47.6 autoconf-2.69p2 libiconv-1.14p3 gettext-0.19.8.1p1
> gdbm-1.14.1 sqlite3-3.23.0 tcl-8.5.19p1 tk-8.5.19p1 db-4.6.21p5v0
> libffi-3.2.1p4 python-2.7.14p1" to build.
>
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/mail/mailpile/Makefile,v
> retrieving revision 1.2
> diff -u -p -r1.2 Makefile
> --- Makefile27 Apr 2018 08:31:01 - 1.2
> +++ Makefile3 May 2018 17:08:55 -
> @@ -5,7 +5,7 @@ PKGNAME = ${DISTNAME:L}
> GH_ACCOUNT = mailpile
Patch doesn't apply (but I'm not sure it's worth sending another patch).
> GH_PROJECT = Mailpile
>GH_TAGNAME = 1.0.0rc2
>-REVISION = 0
>+REVISION = 1
BUILD_DEPENDS don't end up in the resulting package thus no need
to bump REVISION, right?
> CATEGORIES = mail
>
> @@ -26,11 +26,13 @@ RUN_DEPENDS = devel/py-fasteners \
> TEST_DEPENDS = shells/bash \
> ${RUN_DEPENDS}
>
> -NO_BUILD = Yes
> -
> PKG_ARCH = *
>
> INSTDIR = ${PREFIX}/share/mailpile
> +
> +# Nothing to build but allows MODPY to define BUILD_DEPENDS correctly
> +do-build:
>
> do-install:
> ${INSTALL_DATA_DIR} ${INSTDIR}
>
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: Which port produces this build output?
Christian Weisgerber writes: > I see this splashed on my dpb window. Apparently a port writes to > /dev/tty during the build. Any idea which one? > > 476 loops; 25s; 139520 Kstmts; 4894 Kst/sec > 381 loops; 20s; 111675 Kstmts; 4891 Kst/sec > 93 loops; 5s; 27261 Kstmts; 4778 Kst/sec it's lang/snobol4
Re: Which port produces this build output?
On Fri, May 04, 2018 at 12:30:27PM +0200, Christian Weisgerber wrote: > I see this splashed on my dpb window. Apparently a port writes to > /dev/tty during the build. Any idea which one? > > 476 loops; 25s; 139520 Kstmts; 4894 Kst/sec > 381 loops; 20s; 111675 Kstmts; 4891 Kst/sec > 93 loops; 5s; 27261 Kstmts; 4778 Kst/sec lang/snobol4 has snobol4-2.0/test/bench.sno OUTPUT(.TTY, IO_FINDUNIT(),, '/dev/tty') ... TTY = LPAD(LOOPS,4) ' loops; ' + LPAD(TDISP,8) '; ' LPAD(st / 1000,7) ' Kstmts; ' + SS ' Kst/sec'
Re: Which port produces this build output?
On 2018/05/04 12:30, Christian Weisgerber wrote: > I see this splashed on my dpb window. Apparently a port writes to > /dev/tty during the build. Any idea which one? > > 476 loops; 25s; 139520 Kstmts; 4894 Kst/sec > 381 loops; 20s; 111675 Kstmts; 4891 Kst/sec > 93 loops; 5s; 27261 Kstmts; 4778 Kst/sec > > -- > Christian "naddy" Weisgerber na...@mips.inka.de > Probably snobol4.
Which port produces this build output?
I see this splashed on my dpb window. Apparently a port writes to /dev/tty during the build. Any idea which one? 476 loops; 25s; 139520 Kstmts; 4894 Kst/sec 381 loops; 20s; 111675 Kstmts; 4891 Kst/sec 93 loops; 5s; 27261 Kstmts; 4778 Kst/sec -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: UPDATE: math/ginac 1.7.4
On Sat, Apr 28, 2018 at 01:42:52PM +0300, Paul Irofti wrote: > Hi, > > Here is a minor update to GiNaC. All tests pass. OK? > Builds and packages fine, confirm that all tests pass. Portcheck is happy. There is one thing: 'make lib-depends-check' complains as follows: Missing: curses.14 (/usr/local/bin/ginsh) (system lib) Extra: ncurses.14 WANTLIB += curses Scanning: ok I think that should be fixed.
Re: NEW: x11/kde-applications/libkdcraw
On 2018/05/04 08:05, Landry Breuil wrote: > On Thu, May 03, 2018 at 11:07:28PM +0200, Rafael Sadowski wrote: > > On Thu May 03, 2018 at 10:34:45PM +0200, Landry Breuil wrote: > > > On Thu, May 03, 2018 at 10:25:48PM +0200, Rafael Sadowski wrote: > > > > > > > > > > > > > > > Looks simple but it feels like a trap. > > > > > > > > > > > > libkdcraw-17.12.3 has no > > > > > > > > > > > > conflicts with libkdcraw from KDE4 but we can't just > > > > > > > > > > > > commit because all > > If there are no files conflicting, then it should be possible to install > both alongside. Either with the same pkgname and the right combination > of options in both packages (look at how autoconf does, it works!) or > with a different pkgname (ugly, but that's the case for gegl ...) A different PKGNAME isn't ugly at all, this library is called kf5kdcraw anyway...
Re: new: games/barony
David CARLIER writes: > slightly update version with all your inputs. > I don't know if it's preferable but I would have renamed the binary barony-bin and named the launcher barony. So that users just type "barony" to get the game with the correct saving folder. Also, someone on IRC (sorry anonymous, I don't remember your name ) noticed that the echo should send text to stderr in the launcher script. 4c4 < cd ~/.barony || (echo "Can't cd into ~/.barony"; exit 1) --- > cd ~/.barony || (echo "Can't cd into ~/.barony" >&2 ; exit 1)
