Add bashdb port #1

rocky · 2013-01-27T05:35:53Z

Please consider this port of my bash debugger for FreeBSD.

I will also use pr-send to send the request, but if one method is better than the other and it is not desirable to do both, let me know.

Thanks!

uqs · 2013-01-27T10:39:16Z

Hey rocky! Thank you for your submission, but please use send-pr for now to send these in. I'm not sure any ports committers are actively watching the pull queue on github for submissions. Our PR database is the way to go.

Thanks!

Submitted by: Michael Moll via github (pull request freebsd#1)

Users will see a "changed shlibs" reinstall for 'pkg upgrade' until: 1. _All_ packages on remote repositories are rebuilt with this version of pkg. 2. 'pkg check -Ba' should be run after upgrading pkg but before upgrading other packages. This requires #1 though, which is not happening until 1.3.7 is released. Running 'pkg check -Ba' before the remote repository is fixed will just continue to propose reinstalling packages for 'changed shlibs'. Changes: * pkg fetch -d: Fix crash (#955) * Progress bar improvements/fixes * Fix ETA for fetching (#943) * Fix progressbar stalled support * ETA progress: Account for TCP SLOW START and weigh the first few ticks less * Rework 'pkg update' output slightly to clarify what it is doing. * pkg check: Add progressbar when not using -v * pkg check: Add job counter with using -v * pkg clean: Add progressbar * Fix hardlink calculations (#958) * pkg backup: Add -q * pkg backup: Remove docs for '-d -' as it does not work. * pkg config: Fix output for arrays/objects (#971) * Fix RC scripts being started on deinstall rather than stopped * Add some more asserts * pkg-fetch.8: Remove reference to removed mirror mode * Fix a few typos in pkg.conf.5 (#969) * Document new configuration options. (#969)

Users will see a "changed shlibs" reinstall for 'pkg upgrade' until: 1. _All_ packages on remote repositories are rebuilt with this version of pkg. 2. 'pkg check -Ba' should be run after upgrading pkg but before upgrading other packages. This requires freebsd#1 though, which is not happening until 1.3.7 is released. Running 'pkg check -Ba' before the remote repository is fixed will just continue to propose reinstalling packages for 'changed shlibs'. Changes: * pkg fetch -d: Fix crash (#955) * Progress bar improvements/fixes * Fix ETA for fetching (#943) * Fix progressbar stalled support * ETA progress: Account for TCP SLOW START and weigh the first few ticks less * Rework 'pkg update' output slightly to clarify what it is doing. * pkg check: Add progressbar when not using -v * pkg check: Add job counter with using -v * pkg clean: Add progressbar * Fix hardlink calculations (#958) * pkg backup: Add -q * pkg backup: Remove docs for '-d -' as it does not work. * pkg config: Fix output for arrays/objects (#971) * Fix RC scripts being started on deinstall rather than stopped * Add some more asserts * pkg-fetch.8: Remove reference to removed mirror mode * Fix a few typos in pkg.conf.5 (#969) * Document new configuration options. (#969) git-svn-id: svn+ssh://svn.freebsd.org/ports/head@365429 35697150-7ecd-e111-bb59-0022644237b5

<ChangeLog> --[ Redis 2.8.17 ] Release date: 19 Sep 2014 # UPGRADE URGENCY: HIGH for Redis Sentinel. LOW for Redis Server (unmodified compared to 2.8.16). * [FIX] Resolved a memory leak in the hiredis library causing a memory leak in Redis Sentinel when a monitored instance or another Sentinel is unavailable. Every reconnection attempt will leak a small amount of memory, but in the long run the process can reach a considerable size. --[ Redis 2.8.16 ] Release date: 16 Sep 2014 # UPGRADE URGENCY: HIGH for Redis if you are using 2.8.15 + AOF. LOW for Sentinel. * [FIX] The ability to load truncated AOF files introduced with Redis 2.8.15 contains a bug fixed in this release: after loading the file was not truncated to the last valid command, so the new commands are appended after a non well formed command. This means that: 1) The first AOF rewrite triggered by the server will automatically fix the problem. 2) However, if the server is restarted before the rewrite, Redis may not be able to load the file and you need to manually fix it. In order to fix a corrupted file you should start the redis-check-aof utility WITHOUT the --fix option, just to check the offset where the corruption is found. Around the offset reported by the check utility you'll find, inside your AOF file, a command which is not complete according to the Redis protocol. Just remove this incomplete command leafing the file unaltered before and after the offending command, and restart the server. IMPORTANT #1: Redis 2.8.15 is the only stable version of Redis with this bug so probably no actual real-world problem happened since the problem is automatically fixed at the first automatic AOF rewrite. IMPORTANT #2: Before upgrading to Redis 2.8.16, if you are using Redis 2.8.15 with AOF enabled, make sure to trigger a manual AOF rewrite using the BGREWRITEAOF command. * [FIX] SAVE is no longer propagated to AOF / slaves. </ChangeLog> git-svn-id: svn+ssh://svn.freebsd.org/ports/head@368794 35697150-7ecd-e111-bb59-0022644237b5

<ChangeLog> --[ Redis 2.8.17 ] Release date: 19 Sep 2014 # UPGRADE URGENCY: HIGH for Redis Sentinel. LOW for Redis Server (unmodified compared to 2.8.16). * [FIX] Resolved a memory leak in the hiredis library causing a memory leak in Redis Sentinel when a monitored instance or another Sentinel is unavailable. Every reconnection attempt will leak a small amount of memory, but in the long run the process can reach a considerable size. --[ Redis 2.8.16 ] Release date: 16 Sep 2014 # UPGRADE URGENCY: HIGH for Redis if you are using 2.8.15 + AOF. LOW for Sentinel. * [FIX] The ability to load truncated AOF files introduced with Redis 2.8.15 contains a bug fixed in this release: after loading the file was not truncated to the last valid command, so the new commands are appended after a non well formed command. This means that: 1) The first AOF rewrite triggered by the server will automatically fix the problem. 2) However, if the server is restarted before the rewrite, Redis may not be able to load the file and you need to manually fix it. In order to fix a corrupted file you should start the redis-check-aof utility WITHOUT the --fix option, just to check the offset where the corruption is found. Around the offset reported by the check utility you'll find, inside your AOF file, a command which is not complete according to the Redis protocol. Just remove this incomplete command leafing the file unaltered before and after the offending command, and restart the server. IMPORTANT #1: Redis 2.8.15 is the only stable version of Redis with this bug so probably no actual real-world problem happened since the problem is automatically fixed at the first automatic AOF rewrite. IMPORTANT #2: Before upgrading to Redis 2.8.16, if you are using Redis 2.8.15 with AOF enabled, make sure to trigger a manual AOF rewrite using the BGREWRITEAOF command. * [FIX] SAVE is no longer propagated to AOF / slaves. </ChangeLog>

Bugs: - Fix NULL check against lcap data from the jail which was actually setting lcap to NULL. This lines up with similar code in jexec(8). Github PR #1 - Fix compile warning and segfault if lcap was actually NULL - can't cast the jusername struct to string output Github PR #2 Enhancements: - Support dynamic maximum number of groups rather than relying on compile-time NGROUPS Github PR #2 - Support specify target jail by jailname or jail ID through use of libjail jail_get_id() Github PR #3 - Return more specific details when username/UID mapping into jail fails Github PR #3 PR: 197207 Submitted by: Nicholas Kiraly <kiraly.nicholas@gmail.com> Approved by: steve.polyack@intermedix.com (maintainer) git-svn-id: svn+ssh://svn.freebsd.org/ports/head@378754 35697150-7ecd-e111-bb59-0022644237b5

Bugs: - Fix NULL check against lcap data from the jail which was actually setting lcap to NULL. This lines up with similar code in jexec(8). Github PR #1 - Fix compile warning and segfault if lcap was actually NULL - can't cast the jusername struct to string output Github PR #2 Enhancements: - Support dynamic maximum number of groups rather than relying on compile-time NGROUPS Github PR #2 - Support specify target jail by jailname or jail ID through use of libjail jail_get_id() Github PR #3 - Return more specific details when username/UID mapping into jail fails Github PR #3 PR: 197207 Submitted by: Nicholas Kiraly <kiraly.nicholas@gmail.com> Approved by: steve.polyack@intermedix.com (maintainer)

- Fixed subroutine redefine errors (perlinfo script) #1 with patch from Baldur Kristinsson git-svn-id: svn+ssh://svn.freebsd.org/ports/head@389323 35697150-7ecd-e111-bb59-0022644237b5

- Fixed subroutine redefine errors (perlinfo script) #1 with patch from Baldur Kristinsson

…e the sole purpose to avoid using our standard MAKE_ENV. They were introduced in r279589 as part of "update to 0.0.6" PR 159499 by Kato (duh!) some four years ago; in r359185 bapt@ had mentioned that "lots of invocation of MAKE_CMD here are wrong as they do not properly respect MAKE_ENV" (which is ironic as avoiding MAKE_ENV *is* their only point) but the the real problem was neither fixed nor rationale for ugly work-around explained. The port builds itself through a series of recursive make(1) calls, and is using variables to pass various bits of internal state to submakes. This approach typically requires strict discipline and can be hard to implement correctly, to an extent being considered harmful [Miller 1997]. Incidentally, ${MAKE_ENV} includes variables that are 1) used by the port's own build logic and 2) are not handled in a robust way by it. Problem #1: consider the following code from `Makefile.rules.gnu.in': ifndef LIBDIR LIBDIR=. endif This is roughly equivalent to the following: ifeq ($(origin LIBDIR), undefined) LIBDIR=. else # use whatever LIBDIR value make(1) can deduce endif Knowing that LIBDIR is set to some other value (`..') by inner makefiles, that code can be rewritten more elaborately like this: ifeq ($(origin LIBDIR), undefined) LIBDIR=. else ifeq ($(origin LIBDIR), file) # use LIBDIR value set by some Makefile else # use whatever LIBDIR value make(1) can deduce endif Now, because LIBDIR is passed to make(1) via MAKE_ENV and the code above does not have "ifeq ($(origin LIBDIR), environment)" check, the build was affected by unexpected bogus value of it and subsequently failed. Since the only valid place we can expect "our" LIBDIR to come from is makefiles, we can inhibit unwanted pollution from the environment by rewriting the initial code like this: ifneq ($(origin LIBDIR), file) LIBDIR=. endif Problem #2 is similar: checking for CFLAGS and LDFLAGS to protect their initial assignment is very fragile as many frameworks akin to the Ports Collection would provide some default values. While it is usually safe to append to them, it is almost always a bad idea to use them verbatim. Apparently, these checks were put there to support resetting CFLAGS and LDFLAGS in `util/Makefile', but since removing them does not hurt do so regardless of small pollution in that one case that does not affect the build in any noticeable way. git-svn-id: svn+ssh://svn.freebsd.org/ports/head@399689 35697150-7ecd-e111-bb59-0022644237b5

…e the sole purpose to avoid using our standard MAKE_ENV. They were introduced in r279589 as part of "update to 0.0.6" PR 159499 by Kato (duh!) some four years ago; in r359185 bapt@ had mentioned that "lots of invocation of MAKE_CMD here are wrong as they do not properly respect MAKE_ENV" (which is ironic as avoiding MAKE_ENV *is* their only point) but the the real problem was neither fixed nor rationale for ugly work-around explained. The port builds itself through a series of recursive make(1) calls, and is using variables to pass various bits of internal state to submakes. This approach typically requires strict discipline and can be hard to implement correctly, to an extent being considered harmful [Miller 1997]. Incidentally, ${MAKE_ENV} includes variables that are 1) used by the port's own build logic and 2) are not handled in a robust way by it. Problem #1: consider the following code from `Makefile.rules.gnu.in': ifndef LIBDIR LIBDIR=. endif This is roughly equivalent to the following: ifeq ($(origin LIBDIR), undefined) LIBDIR=. else # use whatever LIBDIR value make(1) can deduce endif Knowing that LIBDIR is set to some other value (`..') by inner makefiles, that code can be rewritten more elaborately like this: ifeq ($(origin LIBDIR), undefined) LIBDIR=. else ifeq ($(origin LIBDIR), file) # use LIBDIR value set by some Makefile else # use whatever LIBDIR value make(1) can deduce endif Now, because LIBDIR is passed to make(1) via MAKE_ENV and the code above does not have "ifeq ($(origin LIBDIR), environment)" check, the build was affected by unexpected bogus value of it and subsequently failed. Since the only valid place we can expect "our" LIBDIR to come from is makefiles, we can inhibit unwanted pollution from the environment by rewriting the initial code like this: ifneq ($(origin LIBDIR), file) LIBDIR=. endif Problem #2 is similar: checking for CFLAGS and LDFLAGS to protect their initial assignment is very fragile as many frameworks akin to the Ports Collection would provide some default values. While it is usually safe to append to them, it is almost always a bad idea to use them verbatim. Apparently, these checks were put there to support resetting CFLAGS and LDFLAGS in `util/Makefile', but since removing them does not hurt do so regardless of small pollution in that one case that does not affect the build in any noticeable way.

…an array Obtained from: roundcube/Net_Sieve@47419a26b6 git-svn-id: svn+ssh://svn.freebsd.org/ports/head@409873 35697150-7ecd-e111-bb59-0022644237b5

…an array Obtained from: roundcube/Net_Sieve@47419a26b6

…r400822) fastboot.o:fastboot.cpp:function std::_Function_handler<void (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&), main::{lambda(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)#1}>::_M_invoke(std::_Any_data const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&): error: undefined reference to 'fs_get_generator(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)' fastboot.o:fastboot.cpp:function fb_perform_format(Transport*, char const*, int, char const*, char const*) [clone .constprop.79]: error: undefined reference to 'fs_get_generator(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)' fastboot.o:fastboot.cpp:function fb_perform_format(Transport*, char const*, int, char const*, char const*) [clone .constprop.79]: error: undefined reference to 'fs_generator_generate(fs_generator const*, int, long long)' Reported by: muscles.dragonflybsd.org git-svn-id: svn+ssh://svn.freebsd.org/ports/head@411358 35697150-7ecd-e111-bb59-0022644237b5

…r400822) fastboot.o:fastboot.cpp:function std::_Function_handler<void (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&), main::{lambda(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)#1}>::_M_invoke(std::_Any_data const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&): error: undefined reference to 'fs_get_generator(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)' fastboot.o:fastboot.cpp:function fb_perform_format(Transport*, char const*, int, char const*, char const*) [clone .constprop.79]: error: undefined reference to 'fs_get_generator(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)' fastboot.o:fastboot.cpp:function fb_perform_format(Transport*, char const*, int, char const*, char const*) [clone .constprop.79]: error: undefined reference to 'fs_generator_generate(fs_generator const*, int, long long)' Reported by: muscles.dragonflybsd.org

Changes since test#13: + Move the dhcp_release and dhcp_lease_time tools from + contrib/wrt to contrib/lease-tools. + + Add dhcp_release6 to contrib/lease-tools. Many thanks + to Sergey Nechaev for this code. + + To avoid filling logs in configurations which define + many upstream nameservers, don't log more that 30 servers. + The number to be logged can be changed as SERVERS_LOGGED + in src/config.h. Changelog since v2.75 at: http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob_plain;f=CHANGELOG;hb=8628cd603fd0c55c7d41b84488446db44f58ff5b git-svn-id: svn+ssh://svn.freebsd.org/ports/head@415035 35697150-7ecd-e111-bb59-0022644237b5

Changes since test#13: + Move the dhcp_release and dhcp_lease_time tools from + contrib/wrt to contrib/lease-tools. + + Add dhcp_release6 to contrib/lease-tools. Many thanks + to Sergey Nechaev for this code. + + To avoid filling logs in configurations which define + many upstream nameservers, don't log more that 30 servers. + The number to be logged can be changed as SERVERS_LOGGED + in src/config.h. Changelog since v2.75 at: http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob_plain;f=CHANGELOG;hb=8628cd603fd0c55c7d41b84488446db44f58ff5b

Changes in upstream Git between releases (git shortlog): Sergey Nechaev (1): Stricter command line args validation to dhcp_release6. Simon Kelley (4): Fix error in PXE arch names and add ARM32 and ARM64. Tweak CSAs affected by UEFI PXE workaround code. Tweak UEFI workaround code. Merge messages into translation files. Upstream CHANGELOG diff since rc #1: Swap the values if BC_EFI and x86-64_EFI in --pxe-service. These were previously wrong due to an error in RFC 4578. If you're using BC_EFI to boot 64-bit EFI machines, you will need to update your config. Add ARM32_EFI and ARM64_EFI as valid architectures in --pxe-service. git-svn-id: svn+ssh://svn.freebsd.org/ports/head@415366 35697150-7ecd-e111-bb59-0022644237b5

Changes in upstream Git between releases (git shortlog): Sergey Nechaev (1): Stricter command line args validation to dhcp_release6. Simon Kelley (4): Fix error in PXE arch names and add ARM32 and ARM64. Tweak CSAs affected by UEFI PXE workaround code. Tweak UEFI workaround code. Merge messages into translation files. Upstream CHANGELOG diff since rc #1: Swap the values if BC_EFI and x86-64_EFI in --pxe-service. These were previously wrong due to an error in RFC 4578. If you're using BC_EFI to boot 64-bit EFI machines, you will need to update your config. Add ARM32_EFI and ARM64_EFI as valid architectures in --pxe-service.

- Enhancement: Main plugin needs access to the Schema's current_user so move stashing of user in Schema from Routes to main plugin class. - Bug Fix Add dep on Scalar::Utils for weaken method. - Tests o Remove pg_enable_utf8 from Pg tests - closes issue #1. o Omit BUILD from pod-coverage. PR: 211726 Submitted by: Henk van Oers <hvo.pm@xs4all.nl> (maintainer) git-svn-id: svn+ssh://svn.freebsd.org/ports/head@420198 35697150-7ecd-e111-bb59-0022644237b5

- Enhancement: Main plugin needs access to the Schema's current_user so move stashing of user in Schema from Routes to main plugin class. - Bug Fix Add dep on Scalar::Utils for weaken method. - Tests o Remove pg_enable_utf8 from Pg tests - closes issue #1. o Omit BUILD from pod-coverage. PR: 211726 Submitted by: Henk van Oers <hvo.pm@xs4all.nl> (maintainer)

devel/arduino-builder. =) Right now, there's two possible configurations for building and flashing Arduino projects: 1.) Use devel/arduino16 -- this pulls in devel/arduino-builder and devel/arduino-tools itself, and uses its own method (as it turns out, completely different from arduino-builder's discovery mechanism =() for finding the proper utility for flashing (devel/bossa vs. devel/avrdude) 2.) Use devel/arduino-builder + devel/arduino-tools directly, flash the result yourself -- this has the pro of not requiring Java to build a project, but the con that you do have to figure out how to flash the board (w/ devel/bossa or devel/avrdude) yourself. I suspect that #1 will be the most commonly used configuration, but #2 is nice for "advanced" (or not-so-advanced) applications (such as using a Raspberry Pi to compile+flash firmware for a 3D printer =)). As such, we add an OPTION to make this a more straightforward process of install devel/arduino-builder and then Just Do It. This option will also add in a file at arduino/arduino-builder.options that can be passed into arduino-builder through the -build-options-file. This removes the need for -hardware, -libraries, and -tools flags based on the defaults for devel/arduino-tools. This also auto-populates the core version ("runtime.ide.version", -ide-version/-core-api-version, and the ARDUINO #define) with the minimally supported version (see: _COMPAT_VER, _IDE_VER -- these should be kept in sync, and correspond to versions of devel/arduino-{core,tools}) PR: 213749 Submitted by: Kyle Evans <bsdports@kyle-evans.net> (maintainer) git-svn-id: svn+ssh://svn.freebsd.org/ports/head@424593 35697150-7ecd-e111-bb59-0022644237b5

devel/arduino-builder. =) Right now, there's two possible configurations for building and flashing Arduino projects: 1.) Use devel/arduino16 -- this pulls in devel/arduino-builder and devel/arduino-tools itself, and uses its own method (as it turns out, completely different from arduino-builder's discovery mechanism =() for finding the proper utility for flashing (devel/bossa vs. devel/avrdude) 2.) Use devel/arduino-builder + devel/arduino-tools directly, flash the result yourself -- this has the pro of not requiring Java to build a project, but the con that you do have to figure out how to flash the board (w/ devel/bossa or devel/avrdude) yourself. I suspect that #1 will be the most commonly used configuration, but #2 is nice for "advanced" (or not-so-advanced) applications (such as using a Raspberry Pi to compile+flash firmware for a 3D printer =)). As such, we add an OPTION to make this a more straightforward process of install devel/arduino-builder and then Just Do It. This option will also add in a file at arduino/arduino-builder.options that can be passed into arduino-builder through the -build-options-file. This removes the need for -hardware, -libraries, and -tools flags based on the defaults for devel/arduino-tools. This also auto-populates the core version ("runtime.ide.version", -ide-version/-core-api-version, and the ARDUINO #define) with the minimally supported version (see: _COMPAT_VER, _IDE_VER -- these should be kept in sync, and correspond to versions of devel/arduino-{core,tools}) PR: 213749 Submitted by: Kyle Evans <bsdports@kyle-evans.net> (maintainer)

Program received signal SIGBUS: Access to an undefined portion of a memory object. Backtrace for this error: #0 0x28B2C4D6 #1 0x28B2CB17 #2 0xFFFFE193 gmake[2]: *** [Makefile:10: level1] Bus error (core dumped) Approved by: portmgr blanket git-svn-id: svn+ssh://svn.freebsd.org/ports/head@429052 35697150-7ecd-e111-bb59-0022644237b5

Program received signal SIGBUS: Access to an undefined portion of a memory object. Backtrace for this error: #0 0x28B2C4D6 #1 0x28B2CB17 #2 0xFFFFE193 gmake[2]: *** [Makefile:10: level1] Bus error (core dumped) Approved by: portmgr blanket

Changelog: <http://rawtherapee.com/blog/rawtherapee-5.0-revision-1-released> git-svn-id: svn+ssh://svn.freebsd.org/ports/head@433186 35697150-7ecd-e111-bb59-0022644237b5

… symbol sc_get_softc undefined https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216050 regression: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214769 kernel: KLD nvidia-modeset.ko: depends on nvidia - not available or version mismatch kernel: linker_load_file: Unsupported file type kernel: link_elf_obj: symbol sc_get_softc undefined kernel: linker_load_file: Unsupported file type FreeBSD rimwks 11.0-STABLE FreeBSD 11.0-STABLE freebsd#1 r312105M: Sat Jan 14 05:59:46 MSK 2017 I try to rewrite patch to make it respect kernel options, but it is undone: 1. No code for VT 2. Make does not get DEV_SC and DEV_VT from opt_syscons.h - it is empty, and does not included from ${KERNBUILDDIR}.

Add bashdb port

0878b12

uqs closed this Jan 27, 2013

tota pushed a commit to tota/freebsd-ports that referenced this pull request May 28, 2013

Fix build with GCC 4.7

3df5566

Submitted by: Michael Moll via github (pull request freebsd#1)

tota mentioned this pull request Jun 4, 2013

net/netatalk3: fix leftover build file #2

Closed

uqs pushed a commit that referenced this pull request Jun 13, 2015

www/p5-HTML-Perlinfo: 1.64 -> 1.68

44e09cf

- Fixed subroutine redefine errors (perlinfo script) #1 with patch from Baldur Kristinsson git-svn-id: svn+ssh://svn.freebsd.org/ports/head@389323 35697150-7ecd-e111-bb59-0022644237b5

uqs pushed a commit that referenced this pull request Jun 13, 2015

www/p5-HTML-Perlinfo: 1.64 -> 1.68

9e54bb9

- Fixed subroutine redefine errors (perlinfo script) #1 with patch from Baldur Kristinsson

uqs pushed a commit that referenced this pull request Mar 1, 2016

mail/roundcube: chase PHP Warning: array_merge(): Argument #1 is not …

4869491

…an array Obtained from: roundcube/Net_Sieve@47419a26b6

uqs pushed a commit that referenced this pull request Feb 3, 2017

Update to upstream bugfix revision #1.

25f7737

Changelog: <http://rawtherapee.com/blog/rawtherapee-5.0-revision-1-released> git-svn-id: svn+ssh://svn.freebsd.org/ports/head@433186 35697150-7ecd-e111-bb59-0022644237b5

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add bashdb port #1

Add bashdb port #1

rocky commented Jan 27, 2013

uqs commented Jan 27, 2013

Add bashdb port #1

Add bashdb port #1

Conversation

rocky commented Jan 27, 2013

uqs commented Jan 27, 2013