Update: net/bitlbee-facebook 1.1.2 -> 1.2.0
There's been an update of net/bitlebee-facebook around for a while with some fixes: https://github.com/bitlbee/bitlbee-facebook/releases I've been running it on OpenBSD/amd64 for some time with no problem. The diff is quite simple, but as gmail webmail mangles all text I'll try to attach the diff as a text attachment, see if that works out. -- Eivind Eide "ONLY THOSE WHO ATTEMPT THE IMPOSSIBLE WILL ACHIEVE THE ABSURD" - Oceania Association of Autonomous Astronauts diff -rupN bitlbee-facebook.bak/Makefile bitlbee-facebook/Makefile --- bitlbee-facebook.bak/Makefile Tue Jul 9 00:51:58 2019 +++ bitlbee-facebook/Makefile Tue Jul 9 01:33:46 2019 @@ -1,10 +1,9 @@ # $OpenBSD: Makefile,v 1.4 2019/05/19 19:58:51 danj Exp $ COMMENT= Facebook Messenger protocol plugin for bitlbee -V= 1.1.2 +V= 1.2.0 DISTNAME= bitlbee-facebook-$V CATEGORIES=net -REVISION= 0 HOMEPAGE= https://github.com/bitlbee/bitlbee-facebook diff -rupN bitlbee-facebook.bak/distinfo bitlbee-facebook/distinfo --- bitlbee-facebook.bak/distinfo Sun Oct 15 12:52:09 2017 +++ bitlbee-facebook/distinfo Tue Jul 9 01:35:52 2019 @@ -1,2 +1,2 @@ -SHA256 (bitlbee-facebook-1.1.2.tar.gz) = O5RfgFdzoO8nyXIHzbqmUESr5QvmqpV08sMZ+OU4CWg= -SIZE (bitlbee-facebook-1.1.2.tar.gz) = 397445 +SHA256 (bitlbee-facebook-1.2.0.tar.gz) = vkbimvTCfM5NqyJJ0jzjmMJ93s+Rcs4tSt9vgCp8Vmo= +SIZE (bitlbee-facebook-1.2.0.tar.gz) = 409444
Re: Update: net/bitlbee-facebook 1.1.2 -> 1.2.0
Committed, thanks.
Re: NEW: fonts/b612-font
On Tue Jul 09, 2019 at 01:15:20AM -0400, Kurt Mosiejczuk wrote: > Saw a pointer at this font: https://b612-font.com/ > > "B612 is an highly legible open source font family designed and tested > to be used on aircraft cockpit screens." > > It's an interesting font and I'm trying it out. So figured I'd make a port > for it. > > --Kurt Hi Kurt, the port looks good but why Eclipse License? https://github.com/polarsys/b612/blob/master/OFL.txt s,# Eclipse Public License 1.0,# Open Font License, ? RS
[UPDATE] lang/python/3.7
Hi, this diff updates python 3.7 to latest release 3.7.4. Could you test it in a bulk build please? Cheers, Remi. Index: Makefile === RCS file: /cvs/ports/lang/python/3.7/Makefile,v retrieving revision 1.4 diff -u -p -u -p -r1.4 Makefile --- Makefile 20 May 2019 22:15:15 - 1.4 +++ Makefile 9 Jul 2019 06:04:02 - @@ -6,11 +6,9 @@ # Python itself. VERSION = 3.7 -PATCHLEVEL = .3 +PATCHLEVEL = .4 SHARED_LIBS = python3.7m 0.0 VERSION_SPEC = >=3.7,<3.8 - -REVISION = 2 CONFIGURE_ARGS += --with-ensurepip=no CONFIGURE_ARGS += --enable-loadable-sqlite-extensions Index: distinfo === RCS file: /cvs/ports/lang/python/3.7/distinfo,v retrieving revision 1.1 diff -u -p -u -p -r1.1 distinfo --- distinfo 21 Apr 2019 09:33:32 - 1.1 +++ distinfo 9 Jul 2019 06:04:02 - @@ -1,2 +1,2 @@ -SHA256 (Python-3.7.3.tgz) = 1i4wFfL4nJcKxSNDl2tAZpSTF0L73i/tjRzo67Th+P8= -SIZE (Python-3.7.3.tgz) = 22973527 +SHA256 (Python-3.7.4.tgz) = 1j5j4U5tKeF0kKu+b30Xr7PbGC29gBIp8U5V9BV8S6M= +SIZE (Python-3.7.4.tgz) = 23017663 Index: pkg/PLIST-main === RCS file: /cvs/ports/lang/python/3.7/pkg/PLIST-main,v retrieving revision 1.3 diff -u -p -u -p -r1.3 PLIST-main --- pkg/PLIST-main 10 May 2019 12:01:55 - 1.3 +++ pkg/PLIST-main 9 Jul 2019 06:04:02 - @@ -1500,6 +1500,7 @@ lib/python3.7/distutils/tests/__pycache_ lib/python3.7/distutils/tests/__pycache__/test_versionpredicate.cpython-37.opt-1.pyc lib/python3.7/distutils/tests/__pycache__/test_versionpredicate.cpython-37.opt-2.pyc lib/python3.7/distutils/tests/__pycache__/test_versionpredicate.cpython-37.pyc +lib/python3.7/distutils/tests/includetest.rst lib/python3.7/distutils/tests/support.py lib/python3.7/distutils/tests/test_archive_util.py lib/python3.7/distutils/tests/test_bdist.py @@ -2373,9 +2374,9 @@ lib/python3.7/lib-dynload/xxlimited.so lib/python3.7/lib-dynload/zlib.so lib/python3.7/lib2to3/ lib/python3.7/lib2to3/Grammar.txt -lib/python3.7/lib2to3/Grammar3.7.3.final.0.pickle +lib/python3.7/lib2to3/Grammar3.7.4.final.0.pickle lib/python3.7/lib2to3/PatternGrammar.txt -lib/python3.7/lib2to3/PatternGrammar3.7.3.final.0.pickle +lib/python3.7/lib2to3/PatternGrammar3.7.4.final.0.pickle lib/python3.7/lib2to3/__init__.py lib/python3.7/lib2to3/__main__.py lib/python3.7/lib2to3/__pycache__/ Index: pkg/PLIST-tests === RCS file: /cvs/ports/lang/python/3.7/pkg/PLIST-tests,v retrieving revision 1.2 diff -u -p -u -p -r1.2 PLIST-tests --- pkg/PLIST-tests 10 May 2019 12:01:55 - 1.2 +++ pkg/PLIST-tests 9 Jul 2019 06:04:02 - @@ -1802,6 +1802,9 @@ lib/python3.7/test/libregrtest/__pycache lib/python3.7/test/libregrtest/__pycache__/utils.cpython-37.opt-1.pyc lib/python3.7/test/libregrtest/__pycache__/utils.cpython-37.opt-2.pyc lib/python3.7/test/libregrtest/__pycache__/utils.cpython-37.pyc +lib/python3.7/test/libregrtest/__pycache__/win_utils.cpython-37.opt-1.pyc +lib/python3.7/test/libregrtest/__pycache__/win_utils.cpython-37.opt-2.pyc +lib/python3.7/test/libregrtest/__pycache__/win_utils.cpython-37.pyc lib/python3.7/test/libregrtest/cmdline.py lib/python3.7/test/libregrtest/main.py lib/python3.7/test/libregrtest/refleak.py @@ -1810,6 +1813,7 @@ lib/python3.7/test/libregrtest/runtest_m lib/python3.7/test/libregrtest/save_env.py lib/python3.7/test/libregrtest/setup.py lib/python3.7/test/libregrtest/utils.py +lib/python3.7/test/libregrtest/win_utils.py lib/python3.7/test/list_tests.py lib/python3.7/test/lock_tests.py lib/python3.7/test/mailcap.txt @@ -3011,6 +3015,9 @@ lib/python3.7/test/test_tools/__pycache_ lib/python3.7/test/test_tools/__pycache__/test_i18n.cpython-37.opt-1.pyc lib/python3.7/test/test_tools/__pycache__/test_i18n.cpython-37.opt-2.pyc lib/python3.7/test/test_tools/__pycache__/test_i18n.cpython-37.pyc +lib/python3.7/test/test_tools/__pycache__/test_lll.cpython-37.opt-1.pyc +lib/python3.7/test/test_tools/__pycache__/test_lll.cpython-37.opt-2.pyc +lib/python3.7/test/test_tools/__pycache__/test_lll.cpython-37.pyc lib/python3.7/test/test_tools/__pycache__/test_md5sum.cpython-37.opt-1.pyc lib/python3.7/test/test_tools/__pycache__/test_md5sum.cpython-37.opt-2.pyc lib/python3.7/test/test_tools/__pycache__/test_md5sum.cpython-37.pyc @@ -3032,6 +3039,7 @@ lib/python3.7/test/test_tools/__pycache_ lib/python3.7/test/test_tools/test_fixcid.py lib/python3.7/test/test_tools/test_gprof2html.py lib/python3.7/test/test_tools/test_i18n.py +lib/python3.7/test/test_tools/test_lll.py lib/python3.7/test/test_tools/test_md5sum.py lib/python3.7/test/test_tools/test_pdeps.py lib/python3.7/test/test_tools/test_pindent.py
Re: When will OpenBSD become a friendly place for bug reporters?
moved to ports@ On 2019-07-09, STeve Andre' wrote: > > > On 7/8/19 10:57 PM, mazoc...@disroot.org wrote: >> Hi! >> >> We all know that bugs don't get fixed without backtraces. >> >> After few years of using OpenBSD I am annoyed to get mocked for not >> sending backtraces, but why I don't send them? The answer is: OpenBSD >> doesn't provide software packages with debugging symbols. >> >> Do I look like a Gentoo user? It's not cool to leave no choice to bug >> reporters but to make them rebuild all ports they use with: >> $ env CFLAGS='-pipe -g' DEBUG=-g make -j $(sysctl -n hw.ncpu) reinstall >> >> The current OpenBSD is definetely not friendly to bug reporters, so >> don't blame me when I refuse to send backtraces, I am simply not in mood >> to rebuild software when it shouldn't be necessary, I value my time. > > For heavens sake, why don't you compile the code with symbols? If you > have the ability to go inside and look for problems, you can compile > stuff yourself. If you're going to submit a patch you have to build > to test the fix! Perhaps you have a core from a hard to trigger crash, and you aren't able to get a matching binary by rebuilding things. It is a valid request and has been made before by people with rather more tact. But it's not an easy fix. An all-arches package snapshot currently runs at 200GB and adding symbols across the board would add a lot to this. Slower builds, more disk space and bandwidth needed on build/signing infrastructure and mirrors and, if they're in the main packages, also on user systems. But done on a port-by-port opt-in basis for more important ports (major libraries, for example) it might be viable. I think it would need to use detached symbols in a subpackage - build with symbols, then postprocess the various files, it looks like this might do the trick objcopy --only-keep-debug $file $file.debug objcopy --strip-debug $file objcopy --add-gnu-debuglink $file.debug $file or llvm-objcopy --only-keep=debug $file $file.debug llvm-objcopy --strip-debug $file llvm-objcopy --add-gnu-debuglink $file.debug $file And then it needs additional infrastructure to handle putting these into subpackages (which gets complicated where a port already uses subpackages). Unfortunately the tone of mazocomp's mail ather puts one off from wanting to spend time on this... Maybe I need to polish my scorefile as it only dropped the original mail not the replies :-)
Re: When will OpenBSD become a friendly place for bug reporters?
> It is definately not a friendly place for people with a tone like yours. Theo, your excuse that OpenBSD is not more popular than Linux because AT sued BSD in 90's is ridiculous, that's your own fault for being so terrible in technical field, also you are terrible person, just like me you can't communicate, so why do you think you can teach me communication? If my tone is that important you prefer ignoring important topic then you are even more terrible in terms of both personality and technical field. > An all-arches package snapshot currently runs at 200GB and adding > symbols across the board would add a lot to this. Stuart and Espie, have you ever heard of compression? Again, what's wrong with my tone? I can't elaborate my thoughts in different ways, also my tone only bothers people in this community, most other communities don't see anything wrong about my way of speaking. Anyway, Stuart suggests a really good solution: detaching symbols into subpackages, this practice is already used in Void Linux, I downloaded 1 GB of compressed archives and they expanded to 27 GB, so maybe you can learn how to use compression or at least switch packages to proper compression method.
Re: When will OpenBSD become a friendly place for bug reporters?
Please leave the list. Leonid Bobrov wrote: > > It is definately not a friendly place for people with a tone like yours. > > Theo, your excuse that OpenBSD is not more popular than Linux because AT > sued BSD in 90's is ridiculous, that's your own fault for being so > terrible in technical field, also you are terrible person, just like > me you can't communicate, so why do you think you can teach me > communication? If my tone is that important you prefer ignoring important > topic then you are even more terrible in terms of both personality and > technical field. > > > An all-arches package snapshot currently runs at 200GB and adding > > symbols across the board would add a lot to this. > > Stuart and Espie, have you ever heard of compression? > > Again, what's wrong with my tone? I can't elaborate my thoughts in > different ways, also my tone only bothers people in this community, > most other communities don't see anything wrong about my way of speaking. > > Anyway, Stuart suggests a really good solution: detaching symbols into > subpackages, this practice is already used in Void Linux, I downloaded > 1 GB of compressed archives and they expanded to 27 GB, so maybe you > can learn how to use compression or at least switch packages to proper > compression method.
Re: When will OpenBSD become a friendly place for bug reporters?
On Tue, Jul 9, 2019 at 1:13 PM Leonid Bobrov wrote: > Theo, your excuse that OpenBSD is not more popular than Linux because AT > sued BSD in 90's is ridiculous, Nah, it's a relevant issue. That said, it's not the only issue, which I imagine was the point you were trying to get across. -- Raul
Re: When will OpenBSD become a friendly place for bug reporters?
Perhaps rather than whining that OpenBSD lacks some specific feature, those who want it could write it? A novel idea, I know, but it IS specifically a development platform and there are precisely zero restrictions. Or if you don't wish to start with code, at least try a tack such as "I intend to write feature $foo and would like advice for how to go about it". Notice that the act of _writing actual code_ is still implied. I imagine that if a patch came through which adapted the build/release process such that symbols weren't removed but extracted into their own set for post-hoc installation by interested individuals, for example, that it would at least receive discussion if not eventual inclusion. The bitching and public masturbation in this and the recent X thread, among many other examples, helps no-one. Matthew
Re: When will OpenBSD become a friendly place for bug reporters?
On Tue, Jul 09, 2019 at 08:04:23PM +0300, Leonid Bobrov wrote: > > An all-arches package snapshot currently runs at 200GB and adding > > symbols across the board would add a lot to this. > > Stuart and Espie, have you ever heard of compression? WTF is wrong with you ? I haven't participated to that thread yet, but I wager I know more about compression than you do. Just have a fucking look at the code in signify, the pkg tools, and more generally, EVERYWHERE I have touched in BSD before spouting insults like this. Most specifically: - we do use gzip because other compression systems won't work with little memory/don't have the right licence. - gzip allows you to stick COMMENTS in the header, which is where the signature lives. I DID A WHOLE FUCKING PRESENTATION ABOUT THAT DESIGN CHOICE. - pkg_create uses an LRU cache to make updates faster. And we use some specificities of gzip to make packages amenable to using rsync actually. - Stuart has wasted hours getting mirrors to work as good as they can. - *we* have spent hours trying to share stuff while keeping things secure. It *still* doesn't change the fact that a full snapshot takes up a lot of space. And it's an important factor in having enough sites provide mirrors. It's also an important factor in making sure snapshots are distributed quickly. Heck, there are design choices in package snapshots to avoid shearing. So, to summarize. Get the hell away from this mailing-list. I don't want to have anything to do with a condescending idiot who sends disparaging comments my way 100% out of the blue. Fuck you very much, -- Marc
Re: When will OpenBSD become a friendly place for bug reporters?
Marc and Stuart (and whoever else was involved), thanks for the work done on this stuff. It is simple and clean for me as a user and I have trust in the integrity of what I'm receiving. I don't take it for granted. And there's probably a ton more involved that I'm not aware of yet, but I trust in you guys to do the right thing (tm) all the time for users. Trust is a big deal. Sadly, the OP could have saved a lot of effort for everyone if they just would have remembered there's other humans on the other side of the email. And the fundamentals of communication include if you want to have a real conversation with someone where they listen to you, don't come at them guns blazing and emotional. Thanks for explaining things (for the rest of us that are curious). Hope you didn't let the emotional outrage of a random person on the Internet infect you. On Tue, Jul 09, 2019 at 08:40:29PM +0200, Marc Espie wrote: > On Tue, Jul 09, 2019 at 08:04:23PM +0300, Leonid Bobrov wrote: > > > An all-arches package snapshot currently runs at 200GB and adding > > > symbols across the board would add a lot to this. > > > > Stuart and Espie, have you ever heard of compression? > > WTF is wrong with you ? > > I haven't participated to that thread yet, but I wager I know more about > compression than you do. > > Just have a fucking look at the code in signify, the pkg tools, and more > generally, EVERYWHERE I have touched in BSD before spouting insults like > this. > > Most specifically: > - we do use gzip because other compression systems won't work with little > memory/don't have the right licence. > - gzip allows you to stick COMMENTS in the header, which is where the > signature lives. I DID A WHOLE FUCKING PRESENTATION ABOUT THAT DESIGN > CHOICE. > - pkg_create uses an LRU cache to make updates faster. And we use some > specificities of gzip to make packages amenable to using rsync actually. > - Stuart has wasted hours getting mirrors to work as good as they can. > - *we* have spent hours trying to share stuff while keeping things secure. > > It *still* doesn't change the fact that a full snapshot takes up a lot of > space. And it's an important factor in having enough sites provide mirrors. > > It's also an important factor in making sure snapshots are distributed > quickly. > > Heck, there are design choices in package snapshots to avoid shearing. > > So, to summarize. Get the hell away from this mailing-list. > > I don't want to have anything to do with a condescending idiot who sends > disparaging comments my way 100% out of the blue. > > Fuck you very much, > > -- > Marc > -- Chris Humphries 5223 9548 E1DE DE87 F509 1888 8141 8451 6338 DD29
Re: NEW PORT: p5-Selenium-Remote-Driver
On Sun, 07 Jul 2019, Andrew Hewus Fresh wrote:
> p5-Test-LWP-UserAgent is missing a RUN_DEPENDS on p5-namespace-clean and
> a TEST_DEPENDS on p5-Test-Deep and p5-Test-Fatal, plus might benefit
> from adding p5-JSON-MaybeXS.
November last year I sent a tarball for this port but nobody seem to use
it back then. Here's the Makefile I used to build it (I still use it
today, just removed MAINTAINER and adapted PERMIT_PACKAGE in case you
want to use it as is). I think it might be more accurate on dependencies
than the one Marc Espie sent. He included devel/p5-Moose which I think
is not needed looking at CPAN, but probably drags in all the needed
dependencies (and many more, as Moose is pretty heavy on deps).
I hope it's somewhat useful.
# $OpenBSD$
COMMENT = LWP::UserAgent for simulating and testing network calls
MODULES = cpan
PKG_ARCH = *
DISTNAME = Test-LWP-UserAgent-0.033
CATEGORIES =www devel
# Perl
PERMIT_PACKAGE =Yes
BUILD_DEPENDS = ${RUN_DEPENDS}
RUN_DEPENDS = www/p5-HTTP-Date \
www/p5-HTTP-Message \
www/p5-libwww \
devel/p5-namespace-clean \
devel/p5-Safe-Isa \
devel/p5-Try-Tiny \
www/p5-URI
TEST_DEPENDS += devel/p5-Path-Tiny \
devel/p5-Test-Deep \
devel/p5-Test-Fatal \
devel/p5-Test-Needs \
devel/p5-Test-RequiresInternet \
devel/p5-Test-Warnings
MAKE_ENV = TEST_POD=Yes
.include
--
Paco Esteban.
https://onna.be/gpgkey.asc
9A6B 6083 AD9E FDC2 0EAF 5CB3 5818 130B 8A6D BC03
Re: When will OpenBSD become a friendly place for bug reporters?
On Tue, Jul 09, 2019 at 12:12:49PM -, Stuart Henderson wrote: > [...] > > But done on a port-by-port opt-in basis for more important ports > (major libraries, for example) it might be viable. I think it would > need to use detached symbols in a subpackage - build with symbols, > then postprocess the various files, it looks like this might do the > trick > > objcopy --only-keep-debug $file $file.debug > objcopy --strip-debug $file > objcopy --add-gnu-debuglink $file.debug $file > > or > > llvm-objcopy --only-keep=debug $file $file.debug > llvm-objcopy --strip-debug $file > llvm-objcopy --add-gnu-debuglink $file.debug $file > > And then it needs additional infrastructure to handle putting these > into subpackages (which gets complicated where a port already uses > subpackages). As I understand it, this is essentially what Debian does. See https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols. Like you say, reproducing a crash and getting a backtrace is not always easy, having matching debug symbols in a package would be useful. Debian makes these packages automatically now (as you likely know), after a decade (!!!) of thinking and implementation: https://lists.debian.org/debian-devel/2015/12/msg00262.html. And decades of lots of people putting in the manual work to make -dbg packages. Since I'm not sending any diffs to implement this, and wouldn't even use the debug symbol packages, I'm not sure it would be worth the time for OpenBSD. > Unfortunately the tone of mazocomp's mail ather puts one off from > wanting to spend time on this... Maybe I need to polish my scorefile > as it only dropped the original mail not the replies :-) If demanding a feature rudely means devs won't implement it, maybe I should send a rude email demanding more bugs in OpenBSD :) -- Kaashif Hymabaccus GPG: 3E810B04
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2019/07/09 04:56:07 Modified files: net/bitlbee-facebook: Makefile distinfo Log message: Update to bitlbee-facebook 1.2.0 - Fix ERROR_QUEUE_OVERFLOW on login by bumping orca agent version - Fix "Failed to read fixed header" with TLS 1.3 / GnuTLS 3.6.x - Add workplace chat support (enable the "work" setting to use it) >From Eivind Eide , thanks. Switch to PERMIT_PACKAGE while here.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: e...@cvs.openbsd.org2019/07/09 03:46:17 Modified files: editors/neovim : Makefile distinfo Removed files: editors/neovim/patches: patch-src_nvim_getchar_c Log message: Update editors/neovim to version 0.3.8. Tested by Paco Esteban, input and OK kn@. Thanks.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: j...@cvs.openbsd.org2019/07/09 07:21:37 Modified files: devel/llvm : Makefile devel/llvm/patches: patch-include_llvm_CodeGen_ReturnProtectorLowering_h patch-include_llvm_CodeGen_TargetFrameLowering_h patch-lib_CodeGen_ReturnProtectorLowering_cpp patch-lib_Target_AArch64_AArch64ReturnProtectorLowering_cpp patch-lib_Target_AArch64_AArch64ReturnProtectorLowering_h patch-lib_Target_X86_X86MCInstLower_cpp patch-lib_Target_X86_X86ReturnProtectorLowering_cpp patch-tools_clang_include_clang_Basic_CodeGenOptions_def patch-tools_lld_ELF_Options_td Added files: devel/llvm/patches: patch-lib_Target_Mips_AsmParser_MipsAsmParser_cpp patch-lib_Target_Mips_MCTargetDesc_MipsTargetStreamer_cpp patch-lib_Target_Mips_Mips64InstrInfo_td patch-lib_Target_Mips_MipsAsmPrinter_cpp patch-lib_Target_Mips_MipsISelLowering_cpp patch-lib_Target_Mips_MipsInstrInfo_td patch-lib_Target_Mips_MipsTargetStreamer_h patch-lib_Target_Sparc_SparcAsmPrinter_cpp patch-tools_clang_include_clang_AST_FormatString_h patch-tools_clang_lib_AST_FormatString_cpp patch-tools_clang_lib_Basic_Targets_Mips_h patch-tools_clang_lib_Driver_ToolChains_Arch_X86_cpp patch-tools_lld_ELF_SyntheticSections_cpp Removed files: devel/llvm/patches: patch-lib_Target_X86_X86Subtarget_cpp Log message: Merge various improvements from base o clang: - add back kernel printf %b length specifier support (%llb, etc, lost in the update to 8.0.0) o lld: - Restore previous section after setting the MIPS ABI marker - Fix output section alignement when entry size isn't a power of two o arm64, amd64: - Do not store the retguard cookie in frame in leaf functions if possible - Emit variable length trap padding in retguard epilogue o amd64: - move code that selects retpoline by default to a different source file o mips64: - Fix a bug in memory operand handling - Implement SGE pseudo-instructions - Implement .cplocal directive - Fix instruction guard - Implement the 'h' register constraint on mips64 o sparc64: - Remove cast that truncates immediate operands to 32 bits
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2019/07/09 07:26:52 Modified files: devel/glib2: Makefile distinfo devel/glib2/pkg: PLIST Log message: Update to glib2-2.60.5.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2019/07/09 01:00:52 Modified files: graphics/ffmpeg: Makefile distinfo x11/mplayer: Makefile Removed files: graphics/ffmpeg/patches: patch-libavformat_aacdec_c Log message: Bug fix update to FFmpeg 4.1.4. from Brad (maintainer)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2019/07/09 05:24:28 Modified files: lang/rust : Makefile distinfo lang/rust/patches: patch-src_bootstrap_lib_rs patch-src_bootstrap_test_rs patch-src_librustdoc_test_rs patch-src_libstd_sys_unix_os_rs patch-src_libstd_sys_unix_stack_overflow_rs patch-src_test_run-pass_out-of-stack_rs patch-src_test_run-pass_stack-probes-lto_rs patch-src_test_run-pass_stack-probes_rs patch-src_tools_cargo_src_cargo_core_compiler_context_compilation_files_rs patch-vendor_openssl-sys_build_main_rs lang/rust/pkg : PLIST-main Removed files: lang/rust/patches: patch-src_tools_compiletest_src_main_rs Log message: update lang/rust to 1.36.0 Announce: https://blog.rust-lang.org/2019/07/04/Rust-1.36.0.html Release notes: https://github.com/rust-lang/rust/blob/master/RELEASES.md#version-1360-2019-07-04 ok landry@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2019/07/09 11:58:22 Modified files: www/mozilla: mozilla.port.mk Log message: Bump minimum sqlite requirement to 3.27.2, and nss to 3.44.1, as that's what gecko 68 requires.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2019/07/09 12:05:15 Modified files: www/firefox-esr: Makefile distinfo www/firefox-esr-i18n: Makefile.inc distinfo Log message: Update to firefox-esr 60.8.0. See https://www.mozilla.org/en-US/firefox/60.8.0/releasenotes/ Fixes https://www.mozilla.org/security/advisories/mfsa2019-22/
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2019/07/09 12:15:36 Modified files: www/firefox-i18n: Makefile.inc Makefile distinfo Added files: www/firefox-i18n/bn: Makefile Log message: Seems bn-BD & bn-IN were merged in a single bengali (bn) localization.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2019/07/09 12:14:50 ports/www/firefox-i18n/bn Update of /cvs/ports/www/firefox-i18n/bn In directory cvs.openbsd.org:/tmp/cvs-serv40129/bn Log Message: Directory /cvs/ports/www/firefox-i18n/bn added to the repository
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: gsoa...@cvs.openbsd.org 2019/07/09 11:13:32 Added files: net/tacacs+: Makefile distinfo Log message: Add tacacs+ by Shrubbery.net TACACS+ is used for authentication, authorization, and accounting on Cisco routers. This daemon provides a server for TACACS+ routers. Tests done by Ampie Niemand, Jan Vlach(MAINTAINER) and myself. OK/tweaks sthen@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2019/07/09 12:04:16 Modified files: www/mozilla-firefox: Makefile distinfo www/mozilla-firefox/patches: patch-js_src_jit_ProcessExecutableMemory_h patch-security_manager_pki_resources_content_exceptionDialog_js patch-storage_mozStorageConnection_cpp patch-widget_nsPrintSettingsImpl_cpp www/firefox-i18n: Makefile Makefile.inc distinfo Removed files: www/mozilla-firefox/patches: patch-servo_components_style_lib_rs patch-servo_components_style_traits_lib_rs Log message: Update to firefox 68.0. See https://www.mozilla.org/en-US/firefox/68.0/releasenotes/ Fixes https://www.mozilla.org/en-US/security/advisories/mfsa2019-21/ Remove servo patches finally unneeded with rust 1.36.0. Note that it is very unlikely this will get backported to 6.5-stable, as this new release requires cbindgen 0.8.7 and rust 1.34, which are not going to get backported either. Which also means no 68.0esr for -stable.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2019/07/09 12:09:19 Modified files: mail/thunderbird-i18n: Makefile.inc distinfo mail/mozilla-thunderbird: Makefile distinfo Log message: Update to thunderbird 60.8.0. See https://www.thunderbird.net/en-US/thunderbird/60.8.0/releasenotes/ Probably fixes https://www.mozilla.org/en-US/security/advisories/mfsa2019-23/ (guessed number)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: gsoa...@cvs.openbsd.org 2019/07/09 10:39:55 Modified files: infrastructure/db: user.list Log message: reserve 511 for tacacs_
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2019/07/09 11:59:09 Modified files: www/seamonkey : Makefile Log message: bump after mozilla.port.mk change
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: gsoa...@cvs.openbsd.org 2019/07/09 14:22:43 Modified files: net/tacacs+: Makefile net/tacacs+/patches: patch-pwlib_c patch-tac_plus_c patch-tac_plus_conf_5_in patch-tac_plus_h net/tacacs+/pkg: PLIST README tac_plus.rc Added files: net/tacacs+/files: tac_plus.conf.sample Log message: i let it slip through my fingers no bump since it doesn't currently build/package
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: js...@cvs.openbsd.org 2019/07/09 11:54:46 Modified files: lang/go: Makefile distinfo lang/go/pkg: PLIST Log message: Update lang/go to Go 1.12.7.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2019/07/09 12:12:57 Modified files: www/firefox-esr: Tag: OPENBSD_6_5 Makefile distinfo Log message: MFC: Update to firefox-esr 60.8.0. See https://www.mozilla.org/en-US/firefox/60.8.0/releasenotes/ Fixes https://www.mozilla.org/security/advisories/mfsa2019-22/ packages at the usual spot. ppl wanting 68.0 should use -current.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: gsoa...@cvs.openbsd.org 2019/07/09 11:24:22 Added files: net/tacacs+/patches: patch-pwlib_c patch-tac_plus_c patch-tac_plus_conf_5_in patch-tac_plus_h net/tacacs+/pkg: DESCR PLIST README tac_plus.rc Log message: tweaking previous
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2019/07/09 12:17:56 Removed files: www/firefox-i18n/as: Makefile www/firefox-i18n/bn-BD: Makefile www/firefox-i18n/bn-IN: Makefile www/firefox-i18n/en-ZA: Makefile www/firefox-i18n/mai: Makefile www/firefox-i18n/ml: Makefile www/firefox-i18n/or: Makefile Log message: Garbage collect unlinked langpacks: * Assamese (as) * Bengali - Bangladesh (bn-BD) * Bengali - India (bn-IN) * English - South Africa (en-ZA) * Maithili (mai) * Malayalam (ml) * Odia (or)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: gsoa...@cvs.openbsd.org 2019/07/09 11:29:39 Modified files: devel/quirks : Makefile devel/quirks/files: Quirks.pm Log message: renable net/tacacs+ no longer absolete,
