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=1=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=1=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
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jer...@cvs.openbsd.org 2018/06/13 16:34:42 Modified files: databases/ruby-sequel_pg: Makefile distinfo Log message: Update to sequel_pg 1.9.0
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 ?=".
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jer...@cvs.openbsd.org 2018/06/13 16:26:53 Modified files: lang/ruby : rubygems-ext.PLIST audio/ruby-taglib: Makefile audio/ruby-vorbis_comment: Makefile databases/ruby-amalgalite: Makefile databases/ruby-ldap: Makefile databases/ruby-mysql: Makefile databases/ruby-mysql2: Makefile databases/ruby-pg: Makefile databases/ruby-sqlite3: Makefile databases/ruby-tiny_tds: Makefile devel/ruby-atomic: Makefile devel/ruby-ffi : Makefile devel/ruby-kgio: Makefile devel/ruby-libv8: Makefile devel/ruby-narray: Makefile devel/ruby-ncurses: Makefile devel/ruby-prof: Makefile devel/ruby-racc: Makefile devel/ruby-rb-gsl: Makefile devel/ruby-subset_sum: Makefile devel/ruby-therubyracer: Makefile devel/ruby-yajl: Makefile graphics/ruby-rmagick: Makefile net/ruby-eventmachine: Makefile net/ruby-msgpack: Makefile security/ruby-bcrypt: Makefile security/ruby-gpgme: Makefile security/ruby-pledge: Makefile sysutils/ruby-augeas: Makefile sysutils/ruby-libvirt: Makefile sysutils/ruby-posix-spawn: Makefile sysutils/ruby-shadow: Makefile textproc/ruby-fast-stemmer: Makefile textproc/ruby-fast_xs: Makefile textproc/ruby-hpricot: Makefile textproc/ruby-hyperestraier: Makefile textproc/ruby-nokogiri: Makefile textproc/ruby-rdiscount: Makefile textproc/ruby-redcarpet: Makefile textproc/ruby-redcloth: Makefile www/ruby-capybara-webkit: Makefile www/ruby-fcgi : Makefile www/ruby-passenger: Makefile www/ruby-puma : Makefile www/ruby-raindrops: Makefile www/ruby-thin : Makefile www/ruby-unicorn: Makefile www/ruby-websocket-driver: Makefile x11/ruby-tk: Makefile Log message: Add OpenBSD comment to rubygems-ext.PLIST Bump ruby gem ext ports as this changes the package. Requested by espie@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2018/06/13 15:58:41 Modified files: net/wireshark : Makefile Log message: BUILD_DEPENDS on portaudio-svn, build problem noticed by naddy. I think this may affect the Gtk build (though doesn't show in symbols) so bump REVISION-gtk just in case. (upstream remove Gtk support in the next major version anyway so the problem will magically vanish later).
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.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: s...@cvs.openbsd.org2018/06/13 10:01:00 Added files: devel/tcllib/patches: patch-sak_tcl Log message: Prevent creation of strange file /usr/ports/devel/devel.tcl. This has been a problem since the last version. Apologies for not spotting it until now. Package unchanged, no REVISON bump.
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*,
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: pas...@cvs.openbsd.org 2018/06/13 07:59:57 Modified files: net/tor: Makefile distinfo net/tor/patches: patch-configure_ac Log message: Update to tor 0.3.3.7.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: gonz...@cvs.openbsd.org 2018/06/13 07:37:32 Modified files: www/nextcloud : Makefile distinfo Log message: Update for Nextcloud to 13.0.4. OK abieber@
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
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rpoin...@cvs.openbsd.org2018/06/13 06:15:47 Modified files: graphics/p5-Image-ExifTool: Makefile distinfo graphics/p5-Image-ExifTool/pkg: PLIST Log message: update exiftool to 11.01. take maintainership. ok jca@.
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
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2018/06/13 05:31:01 Modified files: x11/gtk+4 : Makefile Log message: Mark as BROKEN for the time being. There's a meson(1) dependency ordering issue which breaks the build in a non reproducible way. I'll look at it when I have time.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: j...@cvs.openbsd.org2018/06/13 05:24:01 Modified files: security/gnupg : Tag: OPENBSD_6_3 Makefile distinfo Removed files: security/gnupg/patches: Tag: OPENBSD_6_3 patch-configure Log message: SECURITY update to gnupg-1.4.23 Fix for CVE-2017-7526 - Sanitize the diagnostic output of the original file name in verbose mode.
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)
+ {
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2018/06/13 04:12:23 Modified files: sysutils/google-cloud-sdk: Makefile distinfo sysutils/google-cloud-sdk/patches: patch-platform_gsutil_gslib_commands_config_py sysutils/google-cloud-sdk/pkg: PLIST Log message: Update to google-cloud-sdk-205.0.0.
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
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2018/06/13 04:08:44 Modified files: net/py-botocore: Makefile distinfo Log message: Update to py-botocore-1.10.37.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2018/06/13 04:05:44 Modified files: net/py-boto3 : Makefile distinfo Log message: Update to py-boto3-1.7.37.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2018/06/13 04:02:32 Modified files: devel/harfbuzz : Makefile distinfo Log message: Update to harfbuzz-1.8.1.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: b...@cvs.openbsd.org2018/06/13 03:49:26 Modified files: devel/git-lfs : Makefile distinfo Log message: Update to git-lfs-2.4.2. OK sthen@
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);
}
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: gonz...@cvs.openbsd.org 2018/06/13 00:26:06 Removed files: www/nextcloud/patches: patch-apps_updatenotification_appinfo_info_xml Log message: And now yes, no more file. Thanks abieber@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: j...@cvs.openbsd.org2018/06/13 00:20:01 Modified files: security/gnupg : Makefile distinfo Removed files: security/gnupg/patches: patch-configure Log message: SECURITY update to gnupg-1.4.23 Fix for CVE-2017-7526 - Sanitize the diagnostic output of the original file name in verbose mode.
