Re: [NEW] devel/py-pandas
Find attached the new version with just missing whitespaces between the variables of the Makefile. 2018-06-12 11:07 GMT-03:00 Elias M. Mariani : > and the attached tar.gz ? > Missed by that much... > > 2018-06-12 11:06 GMT-03:00 Elias M. Mariani : >> Sending the new version for test. >> The Makefile uses two flavors: >> python3 and test >> So, if you want to install you just run: >> env FLAVOR="" make install >> or >> env FLAVOR="python3" make install >> >> That generates everything only once. >> >> if you want to test: >> env FLAVOR="test" make test >> or >> env FLAVOR="test python3" make test >> also building just once but the result is non installable. >> >> I think is the best choice, if you want to test you build once, if you >> want to install you build once, if you want both... well. just build >> twice... >> Results of the regression tests (using textproc/py-xlrd as a >> dependency test witch I just sent to ports@): >> python2.7 = 2 failed, 24523 passed, 1675 skipped, 79 xfailed, 24 >> xpassed, 86 warnings in 76400.37 seconds >> python3.6 = 3 failed, 24619 passed, 1573 skipped, 80 xfailed, 26 >> xpassed, 197 warnings in 6313.57 seconds >> both OpenBSD-current, amd64. >> 2 failures are because the tester tries to invoke "python" as a >> command, witch it doesn't (necessarily) exist... Just ignore those >> 2... >> Also notice the difference in test time between py2 and py3... is >> better to use the py3 version to do tests... >> Some skips are hardcoded (wt...) others are because we are missing >> some test-dependencies, keep in mind that this tests cover pretty much >> everything that py-pandas does, just look at the RUN_DEPENDS vs >> TEST_DEPENDS and you get an idea of the magnitude of the test. >> >> So Edd kindly offered to check it out. >> Ignore the regression tests, the ideal would be to test it in a real >> application to see if really works as the regression tests say. >> Also I have been working on ports for some weeks now, but this is the >> first with some real logic inside, if Stuart or someone can check the >> Makefile to see if some corrections are needed would be great. >> >> Thanks to all, this pre-port-release was already been made with help >> of several people with examples, advises, warnings, etc. >> Alexandr Shadchin give me his permission to merge our versions in >> openbsd-wip, so, credits to him as well. >> >> Cheers. >> Elias. >> >> 2018-06-09 19:17 GMT-03:00 Elias M. Mariani : >>> Okey, last update: >>> - patched the docs building system. >>> - while building the docs yo need LOTS of depends and for some reason >>> a X session running (yes... I know...). So, either I am doing >>> something very wrong or this is a nasty way of building docs. I guess >>> that something in the source code uses the backend-gtk part of >>> Matplotlib and that triggers the creation of a cursor... because the >>> hole process uses the actual code working to build the docs... I get >>> lost in this nonsense... >>> My Solution will be: build without any docs, use >>> http://pandas.pydata.org/pandas-docs/stable/ for that. >>> Build py-pandas normally with setuptools and python3 flavor. >>> Regression tests will be done by re-building the port, so yes, we >>> build the port twice but only for testing, normal build will be done >>> just once. >>> Any ideas or/and OK ? >>> >>> Cheers. >>> Elias. >>> >>> >>> 2018-06-09 15:59 GMT-03:00 Elias M. Mariani : > Not sure if this helps, but the version in openbsd-wip has a (commented) > block which looks like it does a second (in-place) build to make the > docs: > https://github.com/jasperla/openbsd-wip/blob/cb917e8bcdf2b912209f97652eca484494138fa3/math/py-pandas/Makefile#L65-L68 > > If we really can't get the docs until the package is installed, you > could use SUBDIRs, and have a doc subdir BUILD_DEPEND on the main > package. Yes, but building the same package twice does not sound nice at all. I will add the py-pandas dependency to build py-pandas-docs, that seems the best solution overall... Cheers. Elias. py-pandas.tar.gz Description: GNU Zip compressed data
Re: [NEW] devel/py-test-timeout
Find attached the new version with just missing whitespaces between the variables of the Makefile. 2018-05-28 22:42 GMT-03:00 Elias M. Mariani : > Is a plugin which will terminate tests after a certain timeout. > When doing so it will show a stack dump of all threads running at > the time. This is useful when running tests under a continuous > integration server or simply if you don't know why the test suite > hangs. > > Done tests in python 2.7 and 3.6: > test_pytest_timeout.py ... > [100%] > 31 passed in 67.49 seconds > > Looking for OK and someone to commit to CVS. > Needed for other test suites that require pytest-timeout. > > Thanks. > Elias. py-test-timeout.tar.gz Description: GNU Zip compressed data
Re: [NEW] devel/py-test-qt
Find attached the new version with just missing whitespaces between the variables of the Makefile. 2018-05-29 10:42 GMT-03:00 Elias M. Mariani : > pytest-qt is a pytest plugin that allows programmers to write tests > for PySide, PySide2 and PyQt applications. > > Done tests in python 2.7 and 3.6: > 4 failed, 307 passed, 3 skipped, 1 xfailed. > > The 4 failures I'm pretty sure that are related with trying to delete > a variable from env during the test. > > Looking for OK and someone to commit to CVS. > Needed for other test suites that require pytest-timeout. > > Thanks. py-test-qt.tar.gz Description: GNU Zip compressed data
Re: "[NEW] devel/py-test-xvfb"
Find attached the new version with just missing whitespaces between the variables of the Makefile. 2018-05-29 11:02 GMT-03:00 Elias M. Mariani : > It's a pytest plugin to run Xvfb for tests. > > Done tests in python 2.7 and 3.6: > 1 failed, 14 passed. > > The failure as the rest of the plugins that I sent seems to be pytest > related, guessing that is about monkeypatching or changing the > environment in runtime. > > Looking for OK and someone to commit to CVS. > Needed for other test suites that require pytest-xvfb. > > Thanks. py-test-xvfb.tar.gz Description: GNU Zip compressed data
Re: NEW: devel/spyder
Attached is the new version. Decided to build a 3rd package for docs. Sorry for spamming my collection of ports but I don't want anyone grabbing the wrong version. 2018-06-09 15:37 GMT-03:00 Elias M. Mariani : > Spyder is an interactive Python development environment providing > MATLAB-like features in a simple and lightweight software. It also > provides ready-to-use pure-Python widgets to your PyQt5 or PyQt4 > application: source code editor with syntax highlighting and code > introspection/analysis features, NumPy array editor, dictionary > editor, Python console, etc. > > This is a work of Alexandr Shadchin and myself, merged in openbsd-wip. > It uses FLAVOR=python3 to build spyder3 instead of spyder, both > versions can live together, no conflicts, the documentation is small > so is inside each package. > > I tested both versions (python2 and python3), both worked OK. > > I made a new thread just to avoid confusions with the tar.gz packages > and to give the proper credit to Alexandr, I started to work on this > without realizing that he had a previous entry under editors/spyder > instead of devel/spyder. > > Regression tests on the application require some other ports, I leave > the TEST_DEPENDS commented until those requirements are present. > > Find attached the port in tar.gz and also available in openbsd-wip repository. > Looking for testers, OK and committer. :D > > Cheers. > Elias. spyder.tar.gz Description: GNU Zip compressed data
Re: NEW: graphics/sk1
Find attached the new version with just missing whitespaces between the variables of the Makefile. Good for a weekly ping. :D Cheers. Elias. 2018-06-07 15:32 GMT-03:00 Elias M. Mariani : > sK1 is an open source vector graphics editor. > First of all sK1 is oriented for prepress industry, therefore works > with CMYK colorspace and produces CMYK-based PDF and postscript > output. > > I use it myself to create vector graphics and exporting them to SVG. > Pretty cool. > > Tested by me, no errors found. > Looking for tester/OK/commit > > Cheers. > Elias. sk1.tar.gz Description: GNU Zip compressed data
Re: NEW: textproc/py-xlrd
Added test with py-test. All regression test passing. 2018-06-13 19:41 GMT-03:00 Elias M. Mariani : > Now I feel shame... > Thanks stuart. :D > > 2018-06-13 19:33 GMT-03:00 Stuart Henderson : >> On 2018/06/13 16:00, Elias M. Mariani wrote: >>> > 1) add whitespace around variables, "COMMENT=" -> "COMMENT =" >>> >>> OK, I saw examples in both ways so I didn't think it matters, but if >>> that is the convention, no problem. >>> >> >> whichever way you do it, "FLAVOR? =" isn't correct, it should either be >> "FLAVOR?=" >> or "FLAVOR ?=". >> py-xlrd.tar.gz Description: GNU Zip compressed data
[update] numpy 1.9.2 -> 1.9.3
Minor update of numpy.
The main change is to switch from sourceforge to pypi for hosting of the
distfile as the latest versions of numpy no longer seem to be published to
sourceforge.
ok?
Index: Makefile
===
RCS file: /cvs/ports/math/py-numpy/Makefile,v
retrieving revision 1.48
diff -u -p -u -r1.48 Makefile
--- Makefile21 Feb 2018 21:02:52 - 1.48
+++ Makefile14 Jun 2018 06:07:37 -
@@ -4,10 +4,9 @@ BROKEN-alpha = numpy/linalg/umath_linalg
COMMENT= fast array and numeric programming library for Python
-MODPY_EGG_VERSION= 1.9.2
+MODPY_EGG_VERSION= 1.9.3
DISTNAME= numpy-${MODPY_EGG_VERSION}
PKGNAME= py-${DISTNAME}
-REVISION= 2
CATEGORIES=math devel
@@ -20,14 +19,13 @@ PERMIT_PACKAGE_CDROM= Yes
WANTLIB= blas lapack m pthread ${MODFORTRAN_WANTLIB}
${MODPY_WANTLIB}
-MASTER_SITES= ${MASTER_SITE_SOURCEFORGE:=numpy/}
-
MODULES= lang/python \
fortran
FLAVORS= python3
FLAVOR?=
+MODPY_PI = Yes
MODPY_SETUPTOOLS= Yes
MODPY_SETUP= setupegg.py
MODPY_DISTUTILS_BUILD = build --build-base=${WRKBUILD} --fcompiler=gnu95
Index: distinfo
===
RCS file: /cvs/ports/math/py-numpy/distinfo,v
retrieving revision 1.10
diff -u -p -u -r1.10 distinfo
--- distinfo18 Mar 2016 13:26:10 - 1.10
+++ distinfo14 Jun 2018 06:07:37 -
@@ -1,2 +1,2 @@
-SHA256 (numpy-1.9.2.tar.gz) = Ml5fKwtDTstuaILH4QNMxs3ePu7qh9vEgldRmaau7yo=
-SIZE (numpy-1.9.2.tar.gz) = 3986067
+SHA256 (numpy-1.9.3.tar.gz) = w7dNO52kzrEfZqvSHhF9qM9YS2Og770BqbfpG2k/u9Y=
+SIZE (numpy-1.9.3.tar.gz) = 3984430
Re: devel/avr/gcc bug -> devel/simulavr build error
Another way people can approach this is to build the port with -fstack-protector-all, and all it's dependencies. The 1-byte overflow may be easier to diagnose without retguard protection, but the old school -all protector probably exposes it. These days, -fstack-protector defaults to -fstack-protector-strong. -strong is an innovation written by google staffers. It (probably) followed conversations I had with the years with some of them to improve the original heuristic. Dr. Etoh had written SSP to protect all functions, but it was too expensive. So in OpenBSD we went with only protecting functions with >=16 bytes of local storage. It was a middle choice that got us progress. Then other systems adopted the same approach. Over time, the compilers got better at tracking variable types and dependencies and then google build -strong (search for blogs discussing it), and we enabled this as the default. The old school stackprotector cookie method has the benefit that the debugger has an easier time following traces. Someone should compile the ports tree with -fstack-protector-all and see what falls out. Wait, don't just see, try to fix what you see :) Christian Weisgerber wrote: > Since the introduction of retguard, devel/simulavr has continuously > failed to build on amd64. This is actually a bug in devel/avr/gcc. > The problem was diagnosed early by mortimer@. As I'm not making > any progress, I'm forwarding his analysis here to give other people > a chance to help out. > > > Date: Wed, 9 May 2018 21:58:47 -0400 > From: Todd Mortimer > To: Christian Weisgerber > Cc: es...@openbsd.org > Subject: Re: Retguard needs a ports run > > > build failure that happened again when I re-tried: devel/simulavr > > > > avr-gcc -I. -I../src -I. -g -Wall -mmcu=atmega128 -MT timer.o -MD -MP > > -MF .deps/timer.Tpo -c -o timer.o timer.c > > avr-gcc: Internal error: Abort trap (program cc1) > > > > I'm skeptical that this has anything to do with retguard, but it > > is unexpected. > > This isn't a retguard failure - it's a buffer overwrite by one. The > overwrite smashes the stack protector, so the Abort is coming from the > stack smash handler: > > >>> bt > #0 thrkill () at -:3 > #1 0x0e789907db2c in __stack_smash_handler (func=, > damaged=) at /usr/src/lib/libc/sys/stack_protector.c:79 > #2 0x0e7667e2bdb2 in df_record_exit_block_uses () > #3 0x0e7667e313b7 in df_update_exit_block_uses () > #4 0x0e7667e2f44f in df_update_entry_exit_and_calls () > #5 0x0e7667f0a95c in thread_prologue_and_epilogue_insns () > #6 0x0e7667f05524 in rest_of_handle_thread_prologue_and_epilogue () > #7 0x0e7667fa3213 in execute_one_pass () > #8 0x0e7667fa2e9f in execute_pass_list () > #9 0x0e7667fa2ec7 in execute_pass_list () > #10 0x0e7667fa2ec7 in execute_pass_list () > #11 0x0e76680ccea6 in tree_rest_of_compilation () > #12 0x0e766827ac77 in cgraph_expand_function () > #13 0x0e766827b541 in cgraph_assemble_pending_functions () > #14 0x0e766827a9bd in cgraph_finalize_function () > #15 0x0e7667d14a8b in finish_function () > #16 0x0e7667d83b2b in c_parser_declaration_or_fndef () > #17 0x0e7667d8276f in c_parser_external_declaration () > #18 0x0e7667d818b7 in c_parser_translation_unit () > #19 0x0e7667d81617 in c_parse_file () > #20 0x0e7667d73022 in c_common_parse_file () > #21 0x0e76680680d1 in compile_file () > #22 0x0e7668066f35 in do_compile () > #23 0x0e7668066bc9 in toplev_main () > #24 0x0e7667d9d4ff in main () > > I stepped through the code to see where it was dying. It's like this: > > - df_record_exit_block_uses() has a buffer on the stack > > - it calls df_exit_block_uses_collect(), which iterates through the buffer > setting entries. > > - Before returning, df_exit_block_uses_collect() calls > df_canonize_collection_rec(), which null terminates the buffer, which > happens to null terminate just past the end of the buffer, which just > happens to be the stack cookie. > > - The cookie check fails, and it dies. > > So it seems that the way that retguard is responsible for this is > because retguard changes the stack frame layout a bit, and the stack > cookie happens to be immediately next to the buffer now, and now it gets > whacked. This shouldn't be too hard to patch - it's just a buffer > overflow. > > Thanks again! > > :-) > Todd > > -- > Christian "naddy" Weisgerber na...@mips.inka.de >
Re: [UPDATE] devel/arduino 1.8.5
The latest version that Edd and I were working on is located here: https://github.com/jasperla/openbsd-wip/tree/master/devel/arduino I haven't touched it in a few months (pre-6.3, maybe?), but it was working well at the time. Brian Conway Software Engineer, Owner RCE Software, LLC On Wed, Jun 13, 2018 at 7:48 PM, Base Pr1me wrote: > Hello ports, Finally got around to testing this. I couldn't get the diff to > apply correctly, but the attached port builds and installs fine. > > Tested on Arduino Uno at 115200 with no problems. > > Tested on Arduino Nano and could only write at 57600. Could be do to a > knock-off version of the nano. > > It would be really great if a porter had some time to look at this port and > replace the incredibly old arduino 1.0.2 port. > > Thanks, > > Tracey > > > On 2/28/18 1:28 PM, Brian Conway wrote: >> >> This version adds two missing includes (which were factored out in >> years past) to the template Makefile and should be more testable. >> >> - HardwareSerial0.cpp >> >> (https://github.com/arduino/Arduino/commit/0e97bcb2dfcc5ec9a867ffec8067c2a233381bca) >> - IPAddress.cpp >> >> (https://github.com/arduino/Arduino/commit/a5f6a42dd7128ba3dc13d25a430f4a5a896d7528) >> >> Thanks. >> >> Brian Conway >> Software Engineer, Owner >> RCE Software, LLC >> >> >> On Tue, Feb 27, 2018 at 1:30 PM, Brian Conway >> wrote: >>> >>> Greetings. This update builds on the work done by Edd Barrett in 2015: >>> >>> https://marc.info/?t=14283152151&r=1&w=2 >>> >>> Let me apologize in advance for failing to get `cvs diff` working >>> appropriately, I've attached a `diff -pruN` against head and a tarball >>> of the same. >>> >>> Changes since the 1.6.3 attempt include: >>> - Update Arduino to 1.8.5 and reference.zip (docs) to 1.6.6-3. >>> - Move from GH* tags to releases, per the recent thread. >>> - Set the default UPLOAD_RATE in the template Makefile to 57600. My >>> Nano clones (CH341 chip) all bomb out with 'avrdude: stk500_recv(): >>> programmer is not responding' when connecting at 115200. Perhaps this >>> is a more compatible default? >>> - Regenerate alibs.mk. >>> - As noted in the previous discussion, some libraries and hardware >>> (SAM) were moved out of the core Arduino package. I have not made any >>> attempt to re-add them here. >>> >>> This port works well for me, but I have limited hardware to test it >>> with. Help testing and/or pointers appreciated! >>> >>> Brian Conway >>> Software Engineer, Owner >>> RCE Software, LLC > >
Re: [UPDATE] devel/arduino 1.8.5
Hello ports, Finally got around to testing this. I couldn't get the diff to apply correctly, but the attached port builds and installs fine. Tested on Arduino Uno at 115200 with no problems. Tested on Arduino Nano and could only write at 57600. Could be do to a knock-off version of the nano. It would be really great if a porter had some time to look at this port and replace the incredibly old arduino 1.0.2 port. Thanks, Tracey On 2/28/18 1:28 PM, Brian Conway wrote: This version adds two missing includes (which were factored out in years past) to the template Makefile and should be more testable. - HardwareSerial0.cpp (https://github.com/arduino/Arduino/commit/0e97bcb2dfcc5ec9a867ffec8067c2a233381bca) - IPAddress.cpp (https://github.com/arduino/Arduino/commit/a5f6a42dd7128ba3dc13d25a430f4a5a896d7528) Thanks. Brian Conway Software Engineer, Owner RCE Software, LLC On Tue, Feb 27, 2018 at 1:30 PM, Brian Conway wrote: Greetings. This update builds on the work done by Edd Barrett in 2015: https://marc.info/?t=14283152151&r=1&w=2 Let me apologize in advance for failing to get `cvs diff` working appropriately, I've attached a `diff -pruN` against head and a tarball of the same. Changes since the 1.6.3 attempt include: - Update Arduino to 1.8.5 and reference.zip (docs) to 1.6.6-3. - Move from GH* tags to releases, per the recent thread. - Set the default UPLOAD_RATE in the template Makefile to 57600. My Nano clones (CH341 chip) all bomb out with 'avrdude: stk500_recv(): programmer is not responding' when connecting at 115200. Perhaps this is a more compatible default? - Regenerate alibs.mk. - As noted in the previous discussion, some libraries and hardware (SAM) were moved out of the core Arduino package. I have not made any attempt to re-add them here. This port works well for me, but I have limited hardware to test it with. Help testing and/or pointers appreciated! Brian Conway Software Engineer, Owner RCE Software, LLC
Re: NEW: textproc/py-xlrd
Now I feel shame... Thanks stuart. :D 2018-06-13 19:33 GMT-03:00 Stuart Henderson : > On 2018/06/13 16:00, Elias M. Mariani wrote: >> > 1) add whitespace around variables, "COMMENT=" -> "COMMENT =" >> >> OK, I saw examples in both ways so I didn't think it matters, but if >> that is the convention, no problem. >> > > whichever way you do it, "FLAVOR? =" isn't correct, it should either be > "FLAVOR?=" > or "FLAVOR ?=". > py-xlrd.tar.gz Description: GNU Zip compressed data
Re: NEW: textproc/py-xlrd
On 2018/06/13 16:00, Elias M. Mariani wrote: > > 1) add whitespace around variables, "COMMENT=" -> "COMMENT =" > > OK, I saw examples in both ways so I didn't think it matters, but if > that is the convention, no problem. > whichever way you do it, "FLAVOR? =" isn't correct, it should either be "FLAVOR?=" or "FLAVOR ?=".
devel/avr/gcc bug -> devel/simulavr build error
Since the introduction of retguard, devel/simulavr has continuously failed to build on amd64. This is actually a bug in devel/avr/gcc. The problem was diagnosed early by mortimer@. As I'm not making any progress, I'm forwarding his analysis here to give other people a chance to help out. Date: Wed, 9 May 2018 21:58:47 -0400 From: Todd Mortimer To: Christian Weisgerber Cc: es...@openbsd.org Subject: Re: Retguard needs a ports run > build failure that happened again when I re-tried: devel/simulavr > > avr-gcc -I. -I../src -I. -g -Wall -mmcu=atmega128 -MT timer.o -MD -MP > -MF .deps/timer.Tpo -c -o timer.o timer.c > avr-gcc: Internal error: Abort trap (program cc1) > > I'm skeptical that this has anything to do with retguard, but it > is unexpected. This isn't a retguard failure - it's a buffer overwrite by one. The overwrite smashes the stack protector, so the Abort is coming from the stack smash handler: >>> bt #0 thrkill () at -:3 #1 0x0e789907db2c in __stack_smash_handler (func=, damaged=) at /usr/src/lib/libc/sys/stack_protector.c:79 #2 0x0e7667e2bdb2 in df_record_exit_block_uses () #3 0x0e7667e313b7 in df_update_exit_block_uses () #4 0x0e7667e2f44f in df_update_entry_exit_and_calls () #5 0x0e7667f0a95c in thread_prologue_and_epilogue_insns () #6 0x0e7667f05524 in rest_of_handle_thread_prologue_and_epilogue () #7 0x0e7667fa3213 in execute_one_pass () #8 0x0e7667fa2e9f in execute_pass_list () #9 0x0e7667fa2ec7 in execute_pass_list () #10 0x0e7667fa2ec7 in execute_pass_list () #11 0x0e76680ccea6 in tree_rest_of_compilation () #12 0x0e766827ac77 in cgraph_expand_function () #13 0x0e766827b541 in cgraph_assemble_pending_functions () #14 0x0e766827a9bd in cgraph_finalize_function () #15 0x0e7667d14a8b in finish_function () #16 0x0e7667d83b2b in c_parser_declaration_or_fndef () #17 0x0e7667d8276f in c_parser_external_declaration () #18 0x0e7667d818b7 in c_parser_translation_unit () #19 0x0e7667d81617 in c_parse_file () #20 0x0e7667d73022 in c_common_parse_file () #21 0x0e76680680d1 in compile_file () #22 0x0e7668066f35 in do_compile () #23 0x0e7668066bc9 in toplev_main () #24 0x0e7667d9d4ff in main () I stepped through the code to see where it was dying. It's like this: - df_record_exit_block_uses() has a buffer on the stack - it calls df_exit_block_uses_collect(), which iterates through the buffer setting entries. - Before returning, df_exit_block_uses_collect() calls df_canonize_collection_rec(), which null terminates the buffer, which happens to null terminate just past the end of the buffer, which just happens to be the stack cookie. - The cookie check fails, and it dies. So it seems that the way that retguard is responsible for this is because retguard changes the stack frame layout a bit, and the stack cookie happens to be immediately next to the buffer now, and now it gets whacked. This shouldn't be too hard to patch - it's just a buffer overflow. Thanks again! :-) Todd -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: qtwebkit consumers are broken
> On Jun 13, 2018, at 11:11, Theo de Raadt wrote: > > Rafael Sadowski wrote: > >> Switch off retguard in qtwebkit fix the crashes above. >> >> Please find below a diff to disbale retguard for qtwebkit and respect >> CC/CXX in Qt. > > This diff misses the point. The problem should be looked at a little > deeper. > > retguard is a stack-corruption detector. The return address isn't > what is expected. This looks like an interface where JIT and non-JIT > code touch, perhaps by adjusting the return address on the stack without > being aware it needs an XOR. Maybe the XOR cookie be discovered by > XOR'ing the previous return value if that is known, to re-apply it to > the new ret value. If this is indeed an instance of the return address being deliberately modified between function entry and exit then that will be hard to fix so the program can update the cookie on stack so the check passes. In this case the easiest thing to do is disable retguard as this diff does. Chromium doesn’t have this problem though, but maybe earlier versions of webkit did this and qtwebkit is based on those. If this is the cookie value being corrupted then that would indicate a bug in the program that is being triggered by the stack frame being adjusted to make space for the retguard cookie. I don’t know how hard it is to attach a debugger to this and see if the return address is being modified or if the cookie is being corrupted. > > Aren't you a little curious? > > Also -- with your diff, is the old -fstack-protector(-strong) enabled > or disabled? I think it is disabled. Disabling retguard does not disable the stack protector, so whatever stack protector is enabled by the usual makefile will continue to apply.
Re: NEW: textproc/py-xlrd
> 1) add whitespace around variables, "COMMENT=" -> "COMMENT ="
OK, I saw examples in both ways so I didn't think it matters, but if
that is the convention, no problem.
> you could read /usr/ports/lang/python/python.port.mk because you redefine
> variables that already exist:
>
> my remarks:
>
> 2) use ${MODPY_MAJOR_VERSION} instead of PY_MAJOR, it will be 2 for Python
> 2.7 and 3 for 3.6; but I think you don't need it (see point 4)
I read the module file, I didn't use the variable from there because I
didn't know if it was a good practice to add to SUBST_VARS a variable
from the module.
I will keep that in mind, thanks for the heads up.
> 3) PKGNAME = py-${DISTNAME}
You are right.
> 4) we traditionnaly use ${MODPY_BIN_SUFFIX} for binary, and some people like
> to remove the ".py" extension for script, so I would do:
>
> post-install:
> mv ${PREFIX}/bin/runxlrd.py ${PREFIX}/bin/runxlrd${MODPY_BIN_SUFFIX}
OK, again, it wasn't by not looking, I attached a new version with the
modifications.
I have to correct several others that I sent to ports@ then...
But really, thanks for the info, better to know this things now than later. :D
Cheers.
Elias.
py-xlrd.tar.gz
Description: GNU Zip compressed data
Re: NEW: textproc/py-xlrd
On 06/13/18 18:53, Elias M. Mariani wrote:
I think you had forgotten the tarball :).
Cheers,
Remi.
Maybe...
Thanks for pointing that up. xD
Cheers.
Hi,
you could read /usr/ports/lang/python/python.port.mk because you
redefine variables that already exist:
my remarks:
1) add whitespace around variables, "COMMENT=" -> "COMMENT ="
2) use ${MODPY_MAJOR_VERSION} instead of PY_MAJOR, it will be 2 for
Python 2.7 and 3 for 3.6; but I think you don't need it (see point 4)
3) PKGNAME = py-${DISTNAME}
4) we traditionnaly use ${MODPY_BIN_SUFFIX} for binary, and some people
like to remove the ".py" extension for script, so I would do:
post-install:
mv ${PREFIX}/bin/runxlrd.py ${PREFIX}/bin/runxlrd${MODPY_BIN_SUFFIX}
Cheers,
Remi.
Iridium pledge "rpath", syscall 5
Hi, When I try to access https://mail.protonmail.com with Iridium I get an "Aw, Snap!" and the following in dmesg: iridium[19218]: pledge "stdio", syscall 197 iridium[49053]: pledge "rpath", syscall 5 iridium[52712]: pledge "rpath", syscall 5 iridium[22319]: pledge "rpath", syscall 5 iridium[15149]: pledge "rpath", syscall 5 iridium[64818]: pledge "rpath", syscall 5 iridium[71800]: pledge "rpath", syscall 5 iridium[23894]: pledge "rpath", syscall 5 When I try the same with Chromium I also get an "Aw, Snap!" but nothing in dmesg. Any ideas how to fix this? I'm on OpenBSD-current with up to date packages (see below) Kind regards, Martijn Rijkeboer $ sysctl kern.version kern.version=OpenBSD 6.3-current (GENERIC.MP) #6: Tue Jun 12 16:41:33 MDT 2018 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP $ pkg_info |egrep 'quirk|iridium|chromium' chromium-67.0.3396.62p1 Chromium browser iridium-2018.5.67 Iridium browser quirks-2.447exceptions to pkg_add rules
Re: NEW: textproc/py-xlrd
> I think you had forgotten the tarball :). > > Cheers, > > Remi. Maybe... Thanks for pointing that up. xD Cheers. py-xlrd.tar.gz Description: GNU Zip compressed data
[UPDATE] net/py-websocket-client
Hi,
attached is the diff to update py-websocket-client to latest release.
Ok?
Cheers,
Remi.
Index: Makefile
===
RCS file: /cvs/ports/net/py-websocket-client/Makefile,v
retrieving revision 1.6
diff -u -p -u -p -r1.6 Makefile
--- Makefile 29 Dec 2017 07:24:49 - 1.6
+++ Makefile 13 Jun 2018 16:44:05 -
@@ -2,10 +2,9 @@
COMMENT = WebSocket client for Python
-MODPY_EGG_VERSION = 0.37.0
+MODPY_EGG_VERSION = 0.48.0
DISTNAME = websocket_client-${MODPY_EGG_VERSION}
PKGNAME = py-websocket-client-${MODPY_EGG_VERSION}
-REVISION = 1
CATEGORIES = net
@@ -22,7 +21,10 @@ MODULES = lang/python
FLAVORS = python3
FLAVOR ?=
-RUN_DEPENDS = devel/py-six${MODPY_FLAVOR}
+.if !${FLAVOR:Mpython3}
+RUN_DEPENDS += devel/py-backports-ssl-match-hostname
+.endif
+RUN_DEPENDS += devel/py-six${MODPY_FLAVOR}
post-install:
mv ${PREFIX}/bin/wsdump.py ${PREFIX}/bin/wsdump.py${MODPY_BIN_SUFFIX}
Index: distinfo
===
RCS file: /cvs/ports/net/py-websocket-client/distinfo,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 distinfo
--- distinfo 3 Nov 2016 10:12:49 - 1.3
+++ distinfo 13 Jun 2018 16:44:05 -
@@ -1,2 +1,2 @@
-SHA256 (websocket_client-0.37.0.tar.gz) = Z4skbYFrlAGK9Sl+cpFRYOL+sELgzeGpOX9QKsOlL0E=
-SIZE (websocket_client-0.37.0.tar.gz) = 194246
+SHA256 (websocket_client-0.48.0.tar.gz) = GPEXDmobVGOYZznZ/UXEMIsNAlwbL5uIeI2Paeil60o=
+SIZE (websocket_client-0.48.0.tar.gz) = 44492
Index: pkg/PLIST
===
RCS file: /cvs/ports/net/py-websocket-client/pkg/PLIST,v
retrieving revision 1.2
diff -u -p -u -p -r1.2 PLIST
--- pkg/PLIST 7 Dec 2015 21:16:25 - 1.2
+++ pkg/PLIST 13 Jun 2018 16:44:05 -
@@ -6,6 +6,7 @@ ${MODPY_COMMENT}lib/python${MODPY_VERSIO
lib/python${MODPY_VERSION}/site-packages/websocket/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/websocket/${MODPY_PYCACHE}_abnf.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/websocket/${MODPY_PYCACHE}_app.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/websocket/${MODPY_PYCACHE}_cookiejar.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/websocket/${MODPY_PYCACHE}_core.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/websocket/${MODPY_PYCACHE}_exceptions.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/websocket/${MODPY_PYCACHE}_handshake.${MODPY_PYC_MAGIC_TAG}pyc
@@ -17,6 +18,7 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/websocket/${MODPY_PYCACHE}_utils.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/websocket/_abnf.py
lib/python${MODPY_VERSION}/site-packages/websocket/_app.py
+lib/python${MODPY_VERSION}/site-packages/websocket/_cookiejar.py
lib/python${MODPY_VERSION}/site-packages/websocket/_core.py
lib/python${MODPY_VERSION}/site-packages/websocket/_exceptions.py
lib/python${MODPY_VERSION}/site-packages/websocket/_handshake.py
@@ -26,15 +28,16 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/websocket/_ssl_compat.py
lib/python${MODPY_VERSION}/site-packages/websocket/_url.py
lib/python${MODPY_VERSION}/site-packages/websocket/_utils.py
-lib/python${MODPY_VERSION}/site-packages/websocket/cacert.pem
lib/python${MODPY_VERSION}/site-packages/websocket/tests/
lib/python${MODPY_VERSION}/site-packages/websocket/tests/__init__.py
${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/websocket/tests/${MODPY_PYCACHE}/
lib/python${MODPY_VERSION}/site-packages/websocket/tests/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/websocket/tests/${MODPY_PYCACHE}test_cookiejar.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/websocket/tests/${MODPY_PYCACHE}test_websocket.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/websocket/tests/data/
lib/python${MODPY_VERSION}/site-packages/websocket/tests/data/header01.txt
lib/python${MODPY_VERSION}/site-packages/websocket/tests/data/header02.txt
+lib/python${MODPY_VERSION}/site-packages/websocket/tests/test_cookiejar.py
lib/python${MODPY_VERSION}/site-packages/websocket/tests/test_websocket.py
lib/python${MODPY_VERSION}/site-packages/websocket_client-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/
lib/python${MODPY_VERSION}/site-packages/websocket_client-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/PKG-INFO
Re: UPDATE www/hugo
On 2018/06/13 14:36, fredl wrote: > > Either teach thunderbird to respect your diffs, or send them as > > attachments. > > This was an c/p error. I will do my best that it doesn’t happen again! "cvs diff | xclip" is quite good *if* the MUA doesn't mangle things.
Re: NEW: sysutils/realpath
On 6/13/2018 3:11 AM, Stuart Henderson wrote:
> On 2018/06/12 22:49, Brian Callahan wrote:
>> The realpath utility resolves all symbolic links, extra `/' characters
>> and references to /./ and /../ in the path. If path is absent, the
>> current working directory (`.') is assumed.
>>
>> It is a port of the realpath utility from DragonFly BSD.
>> ---
>>
>> I occasionally run into shell scripts that expect the utility.
> ..
>> OK?
> Port reads ok but realpath is just "readlink -f" (*some* implementations
> use a different exit code for a nonexistent file in a directory that does
> exist, but that can't be relied on).
>
> How widely is it actually used? It's barely any extra code on top of
> readlink.c so if it's useful enough to warrant adding to ports, maybe
> it's also useful enough for base as this diff does (manpage left out for
> now).
I have no opinion on whether this is a port or added directly to
readlink; it's fine by me either way. I don't think it's all that common
but it is a thing I see from time to time.
I'll note though that our implementation of readlink appears to be
different than the others in one meaningful way--they iterate over argv
whereas ours prints argv[0] (after getopt processing). The other
realpath's also iterate over argv. I'm not sure I've ever seen realpath
called with more than one argument in the wild though.
There would also be no -q flag, which again I've never seen in the wild.
~Brian
> Index: Makefile
> ===
> RCS file: /cvs/src/usr.bin/readlink/Makefile,v
> retrieving revision 1.2
> diff -u -p -r1.2 Makefile
> --- Makefile 18 Aug 1997 20:30:59 - 1.2
> +++ Makefile 13 Jun 2018 06:51:08 -
> @@ -2,4 +2,6 @@
>
> PROG=readlink
>
> +LINKS= ${BINDIR}/readlink ${BINDIR}/realpath
> +
> .include
> Index: readlink.c
> ===
> RCS file: /cvs/src/usr.bin/readlink/readlink.c,v
> retrieving revision 1.27
> diff -u -p -r1.27 readlink.c
> --- readlink.c9 Oct 2015 01:37:08 - 1.27
> +++ readlink.c13 Jun 2018 06:51:08 -
> @@ -40,14 +40,21 @@ static void usage(void);
> int
> main(int argc, char *argv[])
> {
> - char buf[PATH_MAX];
> + extern char *__progname;
> + char buf[PATH_MAX], *optstr;
> int n, ch, nflag = 0, fflag = 0;
> extern int optind;
>
> if (pledge("stdio rpath", NULL) == -1)
> err(1, "pledge");
>
> - while ((ch = getopt(argc, argv, "fn")) != -1)
> + if (strcmp(__progname, "realpath") == 0) {
> + optstr = "";
> + fflag = 1;
> + } else
> + optstr = "fn";
> +
> + while ((ch = getopt(argc, argv, optstr)) != -1)
> switch (ch) {
> case 'f':
> fflag = 1;
> @@ -90,6 +97,9 @@ main(int argc, char *argv[])
> static void
> usage(void)
> {
> - (void)fprintf(stderr, "usage: readlink [-fn] file\n");
> + if (strcmp(__progname, "realpath") == 0)
> + (void)fprintf(stderr, "usage: realpath file\n");
> + else
> + (void)fprintf(stderr, "usage: readlink [-fn] file\n");
> exit(1);
> }
>
Re: WireGuard for OpenBSD
Hi All, A new wireguard snapshot has been made. wireguard-tools, providing wg(8) and wg-quick(8) https://git.zx2c4.com/WireGuard/snapshot/WireGuard-0.0.20180613.tar.xz wireguard-go https://git.zx2c4.com/wireguard-go/snapshot/wireguard-go-0.0.20180613.tar.xz Is there any chance of this being made into a port/package, knowing it's just a snapshot? Thanks! -- --- inum: 883510009027723 sip: jungleboo...@sip2sip.info
Re: qtwebkit consumers are broken
Rafael Sadowski wrote: > Switch off retguard in qtwebkit fix the crashes above. > > Please find below a diff to disbale retguard for qtwebkit and respect > CC/CXX in Qt. This diff misses the point. The problem should be looked at a little deeper. retguard is a stack-corruption detector. The return address isn't what is expected. This looks like an interface where JIT and non-JIT code touch, perhaps by adjusting the return address on the stack without being aware it needs an XOR. Maybe the XOR cookie be discovered by XOR'ing the previous return value if that is known, to re-apply it to the new ret value. Aren't you a little curious? Also -- with your diff, is the old -fstack-protector(-strong) enabled or disabled? I think it is disabled.
Re: qtwebkit consumers are broken
On Tue Jun 12, 2018 at 08:33:11PM +0200, Rafael Sadowski wrote: > Looks like x11/qt5/qtwebkit is broken. I'm sure all consumers are > affected. backtraces below: > > digikam: > > Thread 1 received signal SIGTRAP, Trace/breakpoint trap. > 0x079d971c05fb in cti_vm_throw () from /usr/local/lib/libQt5WebKit.so.2.1 > (gdb) bt > #0 0x079d971c05fb in cti_vm_throw () from > /usr/local/lib/libQt5WebKit.so.2.1 > #1 0x079d971525e7 in JSC::Interpreter::execute(JSC::ProgramExecutable*, > JSC::ExecState*, JSC::JSObject*) () from /usr/local/lib/libQt5WebKit.so.2.1 > #2 0x079d9726b52e in JSC::evaluate(JSC::ExecState*, JSC::SourceCode > const&, JSC::JSValue, JSC::JSValue*) () from > /usr/local/lib/libQt5WebKit.so.2.1 > #3 0x079d95f83b7d in > WebCore::ScriptController::evaluateInWorld(WebCore::ScriptSourceCode const&, > WebCore::DOMWrapperWorld*) () from /usr/local/lib/libQt5WebKit.so.2.1 > #4 0x079d95f83e06 in > WebCore::ScriptController::evaluate(WebCore::ScriptSourceCode const&) () from > /usr/local/lib/libQt5WebKit.so.2.1 > #5 0x079d96f95511 in > WebCore::ScriptElement::executeScript(WebCore::ScriptSourceCode const&) () > from /usr/local/lib/libQt5WebKit.so.2.1 > #6 0x079d9605e92f in > WebCore::HTMLScriptRunner::executePendingScriptAndDispatchEvent(WebCore::PendingScript&) > () from /usr/local/lib/libQt5WebKit.so.2.1 > #7 0x079d9605e7e4 in > WebCore::HTMLScriptRunner::executeParsingBlockingScript() () from > /usr/local/lib/libQt5WebKit.so.2.1 > #8 0x079d9605f10b in > WebCore::HTMLScriptRunner::executeScriptsWaitingForLoad(WebCore::CachedResource*) > () from /usr/local/lib/libQt5WebKit.so.2.1 > #9 0x079d9605370f in > WebCore::HTMLDocumentParser::notifyFinished(WebCore::CachedResource*) () from > /usr/local/lib/libQt5WebKit.so.2.1 > #10 0x079d960a2453 in WebCore::CachedResource::checkNotify() () from > /usr/local/lib/libQt5WebKit.so.2.1 > #11 0x079d960f10f9 in > WebCore::SubresourceLoader::didFinishLoading(double) () from > /usr/local/lib/libQt5WebKit.so.2.1 > #12 0x079d9630d2fa in WebCore::QNetworkReplyHandler::finish() () from > /usr/local/lib/libQt5WebKit.so.2.1 > #13 0x079d9630bb0a in WebCore::QNetworkReplyHandlerCallQueue::flush() () > from /usr/local/lib/libQt5WebKit.so.2.1 > #14 0x079d9630f40a in > WebCore::QNetworkReplyWrapper::qt_static_metacall(QObject*, > QMetaObject::Call, int, void**) () from /usr/local/lib/libQt5WebKit.so.2.1 > #15 0x079dbc057572 in QMetaObject::activate(QObject*, int, int, void**) > () from /usr/local/lib/libQt5Core.so.2.2 > #16 0x079d3fbe7dea in QNetworkReply::qt_static_metacall(QObject*, > QMetaObject::Call, int, void**) () from /usr/local/lib/libQt5Network.so.2.2 > #17 0x079dbc04f952 in QObject::event(QEvent*) () from > /usr/local/lib/libQt5Core.so.2.2 > #18 0x079ddfef80dc in QApplicationPrivate::notify_helper(QObject*, > QEvent*) () from /usr/local/lib/libQt5Widgets.so.2.2 > #19 0x079ddfef96d9 in QApplication::notify(QObject*, QEvent*) () from > /usr/local/lib/libQt5Widgets.so.2.2 > #20 0x079dbc0200ba in QCoreApplication::notifyInternal2(QObject*, > QEvent*) () from /usr/local/lib/libQt5Core.so.2.2 > #21 0x079dbc0211c7 in QCoreApplicationPrivate::sendPostedEvents(QObject*, > int, QThreadData*) () from /usr/local/lib/libQt5Core.so.2.2 > #22 0x079dbc07e987 in postEventSourceDispatch(_GSource*, int (*)(void*), > void*) () from /usr/local/lib/libQt5Core.so.2.2 > #23 0x079daff7e889 in g_main_dispatch (context=) at > gmain.c:3177 > #24 g_main_context_dispatch (context=) at gmain.c:3830 > #25 0x079daff7ec93 in g_main_context_iterate (context=, > block=, dispatch=, self=) at > gmain.c:3903 > #26 0x079daff7ed73 in g_main_context_iteration (context=0x79d7b329e00, > may_block=0) at gmain.c:3964 > #27 0x079dbc07e1cb in > QEventDispatcherGlib::processEvents(QFlags) () > from /usr/local/lib/libQt5Core.so.2.2 > #28 0x079dbc020766 in > QCoreApplication::processEvents(QFlags) () > from /usr/local/lib/libQt5Core.so.2.2 > #29 0x079d993448b7 in Digikam::DSplashScreen::setMessage(QString const&) > () from /usr/local/lib/libdigikamcore.so.1.0 > #30 0x079dd4cd1c04 in Digikam::DigikamApp::setupActions() () from > /usr/local/lib/libdigikamgui.so.1.0 > #31 0x079dd4cd57b7 in Digikam::DigikamApp::DigikamApp() () from > /usr/local/lib/libdigikamgui.so.1.0 > #32 0x079b29902fc0 in main () > > otter-browser: > > Thread 1 received signal SIGTRAP, Trace/breakpoint trap. > 0x1f261430f4ad in cti_op_construct_NotJSConstruct () from > /usr/local/lib/qt5/./libQt5WebKit.so.2.1 > (gdb) bt > #0 0x1f261430f4ad in cti_op_construct_NotJSConstruct () from > /usr/local/lib/qt5/./libQt5WebKit.so.2.1 > #1 0x1f26142a85e7 in JSC::Interpreter::execute(JSC::ProgramExecutable*, > JSC::ExecState*, JSC::JSObject*) () from > /usr/local/lib/qt5/./libQt5WebKit.so.2.1 > #2 0x1f26143c152e in JSC::evaluate(JSC::ExecState*, JSC::SourceCode
Re: UPDATE www/hugo
> On 13.06.2018, at 14:06, Jeremie Courreges-Anglas wrote:
>
>> On Tue, Jun 12 2018, fredl wrote:
>>> On 06/12/18 18:43, Stuart Henderson wrote:
On 2018/06/12 18:38, fredl wrote:
Hey,
included is a diff for bringing www/hugo to v0.42.
Changelog can be found at: https://github.com/gohugoio/hugo/releases
ok?
Index: Makefile
===
RCS file: /cvs/ports/www/hugo/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 Makefile
--- Makefile11 Jun 2018 21:17:14 - 1.1.1.1
+++ Makefile12 Jun 2018 16:34:14 -
@@ -3,7 +3,7 @@ ONLY_FOR_ARCHS =${GO_ARCHS}
COMMENT = fast and flexible static site generator
-VERSION = 0.41
+VERSION = 0.42
GH_ACCOUNT = gohugoio
GH_PROJECT = hugo
GH_TAGNAME = v${VERSION}
Index: distinfo
===
RCS file: /cvs/ports/www/hugo/distinfo,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 distinfo
--- distinfo11 Jun 2018 21:17:14 - 1.1.1.1
+++ distinfo12 Jun 2018 16:34:14 -
@@ -1,2 +1,2 @@
-SHA256 (hugo-0.41.tar.gz) = NeoFBBcyZ3eIJZyg6Z193YvoUqxuzrqru0yDArU6gJE=
-SIZE (hugo-0.41.tar.gz) = 62943303
+SHA256 (hugo-0.42.tar.gz) = ai7WwqSm5eykSBoyIusghU2WAPXQEZeBrKDzq18o5jw=
+SIZE (hugo-0.42.tar.gz) = 63247625
>>> There are a couple of problems I spotted from a quick look at the makefile,
>>>
>>> : COMMENT = fast and flexible static site generator
>>> :
>>> : VERSION = 0.41
>>> : GH_ACCOUNT =gohugoio
>>> : GH_PROJECT =hugo
>>> : GH_TAGNAME =v${VERSION}
>>>
>>> no point using VERSION here, it's only used in this one place, but ...
>>>
>>> :
>>> : CATEGORIES =www
>>> :
>>> : HOMEPAGE = https://gohugo.io/
>>> :
>>> : MAINTAINER =Kevin Wondratsch
>>> :
>>> : #Apache License 2.0
>>> : PERMIT_PACKAGE_CDROM = Yes
>>> :
>>> : WANTLIB += c pthread
>>> :
>>> : MASTER_SITES = https://files.fairydust.space/
>>>
>>> GH_* are for fetching files from github auto-generated tarballs,
>>> you shouldn't have both GH_* and MASTER_SITES set.
>>>
>> Hey,
>>
>> thanks for your review!
>> Fixed it!
>
> Your diffs can't be applied at least because of multibyte whitespace
> characters. Maybe those were produced by copy/pasting?
>
> Either teach thunderbird to respect your diffs, or send them as
> attachments.
This was an c/p error. I will do my best that it doesn’t happen again!
>
>> Ok?
>
> oks are for committers. ;)
Point taken :)
> Here's a diff that applies.
Does the update work for you?
[NEW] textproc/py-termcolor
Hi, attached is the port of termcolor: an ANSII Color formatting for output in terminal. Ok? Cheers, Remi. py-termcolor-1.1.0.tar.gz Description: application/gzip
Re: UPDATE www/hugo
On Tue, Jun 12 2018, fredl wrote:
> On 06/12/18 18:43, Stuart Henderson wrote:
>> On 2018/06/12 18:38, fredl wrote:
>>> Hey,
>>>
>>> included is a diff for bringing www/hugo to v0.42.
>>> Changelog can be found at: https://github.com/gohugoio/hugo/releases
>>>
>>> ok?
>>>
>>>
>>>
>>> Index: Makefile
>>> ===
>>> RCS file: /cvs/ports/www/hugo/Makefile,v
>>> retrieving revision 1.1.1.1
>>> diff -u -p -r1.1.1.1 Makefile
>>> --- Makefile 11 Jun 2018 21:17:14 - 1.1.1.1
>>> +++ Makefile 12 Jun 2018 16:34:14 -
>>> @@ -3,7 +3,7 @@ ONLY_FOR_ARCHS = ${GO_ARCHS}
>>>
>>> COMMENT = fast and flexible static site generator
>>>
>>> -VERSION = 0.41
>>> +VERSION = 0.42
>>> GH_ACCOUNT = gohugoio
>>> GH_PROJECT = hugo
>>> GH_TAGNAME = v${VERSION}
>>> Index: distinfo
>>> ===
>>> RCS file: /cvs/ports/www/hugo/distinfo,v
>>> retrieving revision 1.1.1.1
>>> diff -u -p -r1.1.1.1 distinfo
>>> --- distinfo 11 Jun 2018 21:17:14 - 1.1.1.1
>>> +++ distinfo 12 Jun 2018 16:34:14 -
>>> @@ -1,2 +1,2 @@
>>> -SHA256 (hugo-0.41.tar.gz) = NeoFBBcyZ3eIJZyg6Z193YvoUqxuzrqru0yDArU6gJE=
>>> -SIZE (hugo-0.41.tar.gz) = 62943303
>>> +SHA256 (hugo-0.42.tar.gz) = ai7WwqSm5eykSBoyIusghU2WAPXQEZeBrKDzq18o5jw=
>>> +SIZE (hugo-0.42.tar.gz) = 63247625
>>>
>> There are a couple of problems I spotted from a quick look at the makefile,
>>
>> : COMMENT = fast and flexible static site generator
>> :
>> : VERSION = 0.41
>> : GH_ACCOUNT =gohugoio
>> : GH_PROJECT =hugo
>> : GH_TAGNAME =v${VERSION}
>>
>> no point using VERSION here, it's only used in this one place, but ...
>>
>> :
>> : CATEGORIES =www
>> :
>> : HOMEPAGE = https://gohugo.io/
>> :
>> : MAINTAINER =Kevin Wondratsch
>> :
>> : #Apache License 2.0
>> : PERMIT_PACKAGE_CDROM = Yes
>> :
>> : WANTLIB += c pthread
>> :
>> : MASTER_SITES = https://files.fairydust.space/
>>
>> GH_* are for fetching files from github auto-generated tarballs,
>> you shouldn't have both GH_* and MASTER_SITES set.
>>
> Hey,
>
> thanks for your review!
> Fixed it!
Your diffs can't be applied at least because of multibyte whitespace
characters. Maybe those were produced by copy/pasting?
Either teach thunderbird to respect your diffs, or send them as
attachments.
> Ok?
oks are for committers. ;)
Here's a diff that applies.
Index: Makefile
===
RCS file: /d/cvs/ports/www/hugo/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 Makefile
--- Makefile11 Jun 2018 21:17:14 - 1.1.1.1
+++ Makefile13 Jun 2018 11:22:46 -
@@ -3,10 +3,7 @@ ONLY_FOR_ARCHS = ${GO_ARCHS}
COMMENT = fast and flexible static site generator
-VERSION = 0.41
-GH_ACCOUNT = gohugoio
-GH_PROJECT = hugo
-GH_TAGNAME = v${VERSION}
+DISTNAME = hugo-0.42
CATEGORIES = www
@@ -22,6 +19,8 @@ WANTLIB +=c pthread
MASTER_SITES = https://files.fairydust.space/
MODULES = lang/go
+
+ALL_TARGET = github.com/gohugoio/hugo
SEPARATE_BUILD = Yes
Index: distinfo
===
RCS file: /d/cvs/ports/www/hugo/distinfo,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 distinfo
--- distinfo11 Jun 2018 21:17:14 - 1.1.1.1
+++ distinfo13 Jun 2018 11:25:00 -
@@ -1,2 +1,2 @@
-SHA256 (hugo-0.41.tar.gz) = NeoFBBcyZ3eIJZyg6Z193YvoUqxuzrqru0yDArU6gJE=
-SIZE (hugo-0.41.tar.gz) = 62943303
+SHA256 (hugo-0.42.tar.gz) = ai7WwqSm5eykSBoyIusghU2WAPXQEZeBrKDzq18o5jw=
+SIZE (hugo-0.42.tar.gz) = 63247625
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Fix reading coredumps on armv7 with ports gdb
Diff below makes reading core dumps work again.
ok?
Index: devel/gdb/Makefile
===
RCS file: /cvs/ports/devel/gdb/Makefile,v
retrieving revision 1.53
diff -u -p -r1.53 Makefile
--- devel/gdb/Makefile 24 Jan 2018 00:19:56 - 1.53
+++ devel/gdb/Makefile 13 Jun 2018 11:17:36 -
@@ -7,7 +7,7 @@ COMMENT=GNU debugger
CATEGORIES=devel
DISTNAME= gdb-7.12.1
-REVISION= 1
+REVISION= 2
HOMEPAGE= https://www.gnu.org/software/gdb/
Index: devel/gdb/patches/patch-gdb_armbsd-tdep_c
===
RCS file: devel/gdb/patches/patch-gdb_armbsd-tdep_c
diff -N devel/gdb/patches/patch-gdb_armbsd-tdep_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ devel/gdb/patches/patch-gdb_armbsd-tdep_c 13 Jun 2018 11:17:36 -
@@ -0,0 +1,41 @@
+$OpenBSD$
+
+Index: gdb/armbsd-tdep.c
+--- gdb/armbsd-tdep.c.orig
gdb/armbsd-tdep.c
+@@ -30,15 +30,12 @@
+ #define ARMBSD_SIZEOF_GREGS (17 * 4)
+
+ /* Sizeof `struct fpreg' in = ARMBSD_SIZEOF_FPREGS);
+
+- for (i = ARM_F0_REGNUM; i <= ARM_FPS_REGNUM; i++)
++ for (i = ARM_D0_REGNUM; i <= ARM_FPSCR_REGNUM; i++)
+ {
+ if (regnum == i || regnum == -1)
+ regcache_raw_supply (regcache, i, regs + armbsd_fpreg_offset (i));
+@@ -83,7 +80,7 @@ armbsd_supply_gregset (const struct regset *regset,
+ }
+
+ if (regnum == ARM_PS_REGNUM || regnum == -1)
+-regcache_raw_supply (regcache, i, regs + 16 * 4);
++regcache_raw_supply (regcache, ARM_PS_REGNUM, regs + 16 * 4);
+
+ if (len >= ARMBSD_SIZEOF_GREGS + ARMBSD_SIZEOF_FPREGS)
+ {
Re: UPDATE: emulators/ppsspp
"Anthony J. Bentley" writes: > GH_ACCOUNT = hrydgard > GH_PROJECT = ppsspp > -GH_TAGNAME = v1.5.4 > +GH_TAGNAME = v1.6.2 v1.6.3 was released some time ago, a day after you've started the thread. Is there a reason OpenBSD port cannot update to it? https://github.com/hrydgard/ppsspp/releases.atom https://github.com/hrydgard/ppsspp/compare/v1.6.2...v1.6.3 https://repology.org/metapackage/ppsspp/history FWIW, FreeBSD port also applied fixes that didn't make into 1.6.*: https://github.com/hrydgard/ppsspp/commit/c783e7761c2a https://github.com/hrydgard/ppsspp/commit/f2a75719d843 https://github.com/hrydgard/ppsspp/commit/78a41980dfd7
Re: [Update] GnuPG 2.2.8
On Wed 13/06/2018 10:40, Pierre-Emmanuel André wrote: > Hi, > > Small diff to update GnuPG to it's latest version (2.2.8). > Comments, ok ? > > Regards, Diffs reads ok, port builds, runs 'make test' without any hassle and works for me on amd64. OK bket@
Re: UPDATE: emulators/ppsspp
Jan Beich writes:
> > Here's an update to ppsspp-1.6.2.
>
> Do you plan to add libretro flavor a la mgba/nestopia?
Yes, I'll work on that after I commit the update.
> > LIB_DEPENDS = archivers/snappy \
> > - archivers/libzip \
>
> Have you tried the following?
>
> CONFIGURE_ARGS += -DUSE_SYSTEM_LIBZIP=ON
Ah, thanks!
Index: Makefile
===
RCS file: /cvs/ports/emulators/ppsspp/Makefile,v
retrieving revision 1.3
diff -u -p -r1.3 Makefile
--- Makefile4 Jan 2018 05:09:32 - 1.3
+++ Makefile13 Jun 2018 09:16:37 -
@@ -4,10 +4,10 @@ COMMENT = Sony PlayStation Portable emul
GH_ACCOUNT = hrydgard
GH_PROJECT = ppsspp
-GH_TAGNAME = v1.5.4
+GH_TAGNAME = v1.6.2
GLSLANG = 2edde6665d9a56ead5ea0e55b4e64d9a803e6164
-PPSSPP_LANG = 6537fc1bf38d0787a1d86375e5b3cb267349d2d5
+PPSSPP_LANG = c2c4ad9c38c5f5e97ff022a703c470fcd53da249
SPIRV_CROSS = 90966d50f57608587bafd95b4e345b02b814754a
ARMIPS = 0.9
TINYFORMAT = b7f5a22753c81d834ab5133d655f1fd525280765
@@ -38,7 +38,7 @@ DIST_SUBDIR = ppsspp
WANTLIB += ${COMPILER_LIBCXX}
WANTLIB += GL GLEW GLU SDL2 avcodec avformat avutil c m snappy
-WANTLIB += swresample swscale z zip
+WANTLIB += swresample swscale z zip
MODULES = devel/cmake
LIB_DEPENDS = archivers/snappy \
@@ -50,7 +50,8 @@ COMPILER =base-clang ports-gcc
CONFIGURE_ARGS = -DUSE_SYSTEM_FFMPEG=ON \
-DCMAKE_CXX_FLAGS="-I${X11BASE}/include" \
- -DCMAKE_CXX_FLAGS="${CXXFLAGS}"
+ -DCMAKE_CXX_FLAGS="${CXXFLAGS}" \
+ -DUSE_SYSTEM_LIBZIP=ON
NO_TEST = Yes
Index: distinfo
===
RCS file: /cvs/ports/emulators/ppsspp/distinfo,v
retrieving revision 1.2
diff -u -p -r1.2 distinfo
--- distinfo4 Jan 2018 05:09:32 - 1.2
+++ distinfo13 Jun 2018 09:16:37 -
@@ -1,12 +1,12 @@
SHA256 (ppsspp/2edde6665d9a56ead5ea0e55b4e64d9a803e6164.tar.gz) =
XiCldYwTzDlnosMecBf+TYE1wAVzNmK+RYXZ0ZtdjzQ=
-SHA256 (ppsspp/6537fc1bf38d0787a1d86375e5b3cb267349d2d5.tar.gz) =
uSmCAnMisURzE8D8GVCpO/gMD9nrMiZuv+zR6AD7tyM=
SHA256 (ppsspp/90966d50f57608587bafd95b4e345b02b814754a.tar.gz) =
KC0fF70wAxYt2UW4ulxaEMtXOKd1CUmoIA/2VV8Q/yg=
SHA256 (ppsspp/b7f5a22753c81d834ab5133d655f1fd525280765.tar.gz) =
nbm8Fun6/t5JO1iQuTWlfubl4oSp1uj6bZMpeQqWuMY=
-SHA256 (ppsspp/ppsspp-1.5.4.tar.gz) =
5zkVXxNfmz4uXOhdDMEQKMStcaAHhnOr4/kIrGh1KEo=
+SHA256 (ppsspp/c2c4ad9c38c5f5e97ff022a703c470fcd53da249.tar.gz) =
WpfRopSUgggrtOff93BMsP6CY6gozGZ3Ph1wx7zkctw=
+SHA256 (ppsspp/ppsspp-1.6.2.tar.gz) =
oqM2kzJOeYxoxnOJlIlvqjaPO7PBR/Fwwp9mT0h2o5A=
SHA256 (ppsspp/v0.9.tar.gz) = x1boXdcRpBjzO3IOGSb3gOCxZMhIpOdPtyWOGMMvzZQ=
SIZE (ppsspp/2edde6665d9a56ead5ea0e55b4e64d9a803e6164.tar.gz) = 1944927
-SIZE (ppsspp/6537fc1bf38d0787a1d86375e5b3cb267349d2d5.tar.gz) = 362410
SIZE (ppsspp/90966d50f57608587bafd95b4e345b02b814754a.tar.gz) = 228943
SIZE (ppsspp/b7f5a22753c81d834ab5133d655f1fd525280765.tar.gz) = 22284
-SIZE (ppsspp/ppsspp-1.5.4.tar.gz) = 19008538
+SIZE (ppsspp/c2c4ad9c38c5f5e97ff022a703c470fcd53da249.tar.gz) = 478373
+SIZE (ppsspp/ppsspp-1.6.2.tar.gz) = 19477075
SIZE (ppsspp/v0.9.tar.gz) = 154427
Index: pkg/PLIST
===
RCS file: /cvs/ports/emulators/ppsspp/pkg/PLIST,v
retrieving revision 1.2
diff -u -p -r1.2 PLIST
--- pkg/PLIST 4 Jan 2018 05:09:32 - 1.2
+++ pkg/PLIST 13 Jun 2018 09:16:37 -
@@ -80,6 +80,7 @@ share/ppsspp/assets/shaders/4xhqglsl.vsh
share/ppsspp/assets/shaders/5xBR-lv2.fsh
share/ppsspp/assets/shaders/5xBR.fsh
share/ppsspp/assets/shaders/5xBR.vsh
+share/ppsspp/assets/shaders/GaussianDownscale.fsh
share/ppsspp/assets/shaders/aacolor.fsh
share/ppsspp/assets/shaders/aacolor.vsh
share/ppsspp/assets/shaders/bloom.fsh
@@ -93,6 +94,7 @@ share/ppsspp/assets/shaders/grayscale.fs
share/ppsspp/assets/shaders/inversecolors.fsh
share/ppsspp/assets/shaders/natural.fsh
share/ppsspp/assets/shaders/natural.vsh
+share/ppsspp/assets/shaders/naturalA.fsh
share/ppsspp/assets/shaders/scanlines.fsh
share/ppsspp/assets/shaders/sharpen.fsh
share/ppsspp/assets/shaders/upscale_spline36.fsh
[Update] GnuPG 2.2.8
Hi,
Small diff to update GnuPG to it's latest version (2.2.8).
Comments, ok ?
Regards,
Index: Makefile
===
RCS file: /cvs/ports/security/gnupg2/Makefile,v
retrieving revision 1.57
diff -u -p -u -p -r1.57 Makefile
--- Makefile 17 Apr 2018 13:36:14 - 1.57
+++ Makefile 13 Jun 2018 08:39:24 -
@@ -2,7 +2,7 @@
COMMENT = GNU privacy guard - a free PGP replacement
-DISTNAME = gnupg-2.2.6
+DISTNAME = gnupg-2.2.8
CATEGORIES = security
MASTER_SITES = ${MASTER_SITE_GNUPG:=gnupg/}
Index: distinfo
===
RCS file: /cvs/ports/security/gnupg2/distinfo,v
retrieving revision 1.27
diff -u -p -u -p -r1.27 distinfo
--- distinfo 17 Apr 2018 13:36:14 - 1.27
+++ distinfo 13 Jun 2018 08:39:24 -
@@ -1,2 +1,2 @@
-SHA256 (gnupg-2.2.6.tar.bz2) = 5k2MX6LQWTilCAy3hKmKwhvggS8qJvhEsY8Nag5xGYQ=
-SIZE (gnupg-2.2.6.tar.bz2) = 6605028
+SHA256 (gnupg-2.2.8.tar.bz2) = d3tMuM7SGWWlBT1Pog/hFITwpHjz0BHO9QihpJ21Dc0=
+SIZE (gnupg-2.2.8.tar.bz2) = 6632465
Re: NEW: sysutils/realpath
On 2018/06/12 22:49, Brian Callahan wrote:
> The realpath utility resolves all symbolic links, extra `/' characters
> and references to /./ and /../ in the path. If path is absent, the
> current working directory (`.') is assumed.
>
> It is a port of the realpath utility from DragonFly BSD.
> ---
>
> I occasionally run into shell scripts that expect the utility.
..
> OK?
Port reads ok but realpath is just "readlink -f" (*some* implementations
use a different exit code for a nonexistent file in a directory that does
exist, but that can't be relied on).
How widely is it actually used? It's barely any extra code on top of
readlink.c so if it's useful enough to warrant adding to ports, maybe
it's also useful enough for base as this diff does (manpage left out for
now).
Index: Makefile
===
RCS file: /cvs/src/usr.bin/readlink/Makefile,v
retrieving revision 1.2
diff -u -p -r1.2 Makefile
--- Makefile18 Aug 1997 20:30:59 - 1.2
+++ Makefile13 Jun 2018 06:51:08 -
@@ -2,4 +2,6 @@
PROG= readlink
+LINKS= ${BINDIR}/readlink ${BINDIR}/realpath
+
.include
Index: readlink.c
===
RCS file: /cvs/src/usr.bin/readlink/readlink.c,v
retrieving revision 1.27
diff -u -p -r1.27 readlink.c
--- readlink.c 9 Oct 2015 01:37:08 - 1.27
+++ readlink.c 13 Jun 2018 06:51:08 -
@@ -40,14 +40,21 @@ static void usage(void);
int
main(int argc, char *argv[])
{
- char buf[PATH_MAX];
+ extern char *__progname;
+ char buf[PATH_MAX], *optstr;
int n, ch, nflag = 0, fflag = 0;
extern int optind;
if (pledge("stdio rpath", NULL) == -1)
err(1, "pledge");
- while ((ch = getopt(argc, argv, "fn")) != -1)
+ if (strcmp(__progname, "realpath") == 0) {
+ optstr = "";
+ fflag = 1;
+ } else
+ optstr = "fn";
+
+ while ((ch = getopt(argc, argv, optstr)) != -1)
switch (ch) {
case 'f':
fflag = 1;
@@ -90,6 +97,9 @@ main(int argc, char *argv[])
static void
usage(void)
{
- (void)fprintf(stderr, "usage: readlink [-fn] file\n");
+ if (strcmp(__progname, "realpath") == 0)
+ (void)fprintf(stderr, "usage: realpath file\n");
+ else
+ (void)fprintf(stderr, "usage: readlink [-fn] file\n");
exit(1);
}
