[UPDATE] Awesome WM 4.2 -> 4.3
Hi again ports@,
I have updated the Makefile for the Awesome WM port. For those who don't
know what it is, Awesome WM is a window manager that is configurable and
scriptable with the Lua language. It's very flexible and lightweight on
resources.
The 4.3 version comes with a huge number of changes (see [1]) and was
released last January. I contacted the maintainer but got no reply, so I
went ahead and made this update.
The update was pretty straightforward: version bump, applying the
patches and tweak them so they would apply cleanly. I took the liberty
of removing the code that prevented manpages from gzipping. They don't
get gzipped unless you tell them too. I also removed the hardcoded
CFLAGS that were patched in. IIRC, they should be already inherited by
whatever the system provides, right?
One thing though, to make the manpages, asciidoctor, a ruby package,
must be installed. It can be trivially created with portgen. Tomorrow
I'll post the generated Makefile.
Looking forward to feedback,
Enric
[1] https://github.com/awesomeWM/awesome/releases/tag/v4.3
Index: Makefile
===
RCS file: /cvs/ports/x11/awesome/Makefile,v
retrieving revision 1.110
diff -u -r1.110 Makefile
--- Makefile12 Jul 2019 20:51:08 - 1.110
+++ Makefile11 Oct 2019 00:12:42 -
@@ -2,7 +2,7 @@
COMMENT= highly configurable framework window manager
-VER= 4.2
+VER= 4.3
DISTNAME= awesome-${VER}
REVISION= 1
EXTRACT_SUFX= .tar.xz
@@ -11,7 +11,7 @@
HOMEPAGE= https://awesomewm.org/
# GPLv2+
-PERMIT_PACKAGE=Yes
+PERMIT_PACKAGE=Yes
WANTLIB= X11 c cairo dbus-1 execinfo \
gdk_pixbuf-2.0 glib-2.0 gobject-2.0 \
Index: distinfo
===
RCS file: /cvs/ports/x11/awesome/distinfo,v
retrieving revision 1.28
diff -u -r1.28 distinfo
--- distinfo5 Aug 2017 20:18:11 - 1.28
+++ distinfo11 Oct 2019 00:12:42 -
@@ -1,2 +1,2 @@
-SHA256 (awesome-4.2.tar.xz) = rF2hqZ9frQg4IZk9K1bRzZWUFk6vwL4r61QFmDRdl08=
-SIZE (awesome-4.2.tar.xz) = 987024
+SHA256 (awesome-4.3.tar.xz) = eCZNbwEjULNx4zkSespIUmC8Cqk17/V4unXOGgDhF1M=
+SIZE (awesome-4.3.tar.xz) = 1037816
Index: patches/patch-CMakeLists_txt
===
RCS file: /cvs/ports/x11/awesome/patches/patch-CMakeLists_txt,v
retrieving revision 1.19
diff -u -r1.19 patch-CMakeLists_txt
--- patches/patch-CMakeLists_txt5 Aug 2017 20:18:11 - 1.19
+++ patches/patch-CMakeLists_txt11 Oct 2019 00:12:42 -
@@ -1,15 +1,9 @@
-$OpenBSD: patch-CMakeLists_txt,v 1.19 2017/08/05 20:18:11 dcoppa Exp $
-
-These auto-generated (db2man.xsl) manpages contain a mixture of ISO
-latin-1 characters and numerical HTML entities that neither mandoc
-nor groff can fully understand: do not install them.
-
-Fix usage of -export-dynamic
+$OpenBSD$
Index: CMakeLists.txt
--- CMakeLists.txt.orig
+++ CMakeLists.txt
-@@ -97,7 +97,6 @@ set(AWE_MAN_SRCS
+@@ -95,7 +95,6 @@ set(AWE_MAN_SRCS
${SOURCE_DIR}/manpages/awesome.1.txt
${SOURCE_DIR}/manpages/awesome-client.1.txt
${SOURCE_DIR}/manpages/awesomerc.5.txt)
@@ -17,192 +11,20 @@
# Don't strip RPATH if compiling on Solaris
if (${CMAKE_SYSTEM_NAME} MATCHES "SunOS")
-@@ -111,12 +110,11 @@ add_executable(${PROJECT_AWE_NAME}
-
- # CFLAGS
- set(AWESOME_C_FLAGS
---O1 -std=gnu99 -ggdb3 -fno-strict-aliasing -Wall -Wextra
---Wchar-subscripts -Wundef -Wshadow -Wcast-align -Wwrite-strings
---Wsign-compare -Wunused -Wno-unused-parameter -Wuninitialized -Winit-self
---Wpointer-arith -Wformat-nonliteral
---Wno-format-zero-length -Wmissing-format-attribute -Wmissing-prototypes
---Wstrict-prototypes
-+-std=gnu99 -fgnu89-inline -fno-strict-aliasing
-+-Wchar-subscripts -Wcast-align -Wwrite-strings -Wsign-compare
-+-Wunused -Wno-unused-parameter -Wuninitialized -Wpointer-arith
-+-Wno-format-zero-length -Wmissing-format-attribute
-+-Wmissing-prototypes -Wstrict-prototypes
- CACHE STRING "CFLAGS used to compile ${PROJECT_AWE_NAME}")
- mark_as_advanced(AWESOME_C_FLAGS)
- target_compile_options(${PROJECT_AWE_NAME} PRIVATE ${AWESOME_C_FLAGS})
-@@ -124,23 +122,11 @@ target_compile_options(${PROJECT_AWE_NAME} PRIVATE ${A
- # Make sure awesomerc.lua is generated
- add_dependencies(${PROJECT_AWE_NAME} generate_awesomerc)
+@@ -134,11 +133,11 @@ if(DEFINED CMAKE_SHARED_LIBRARY_LINK_C_FLAGS AND
+ $<$,$>:-rdynamic>)
+ endif()
--# Linux w/ GCC requires -rdynamic to get backtrace to fully work.
--#
--# For "historical reasons", CMake adds the option to the linker flags
--# unnoticeably for Linux w/ GCC through its modules Linux-GNU.cmake
--# and Linux-GNU-C.cmake. Our build system has counted on that. But
--# just in case CMake should do
Re: nvi problems with '|' in exrc
A quick check confirms that '|' also works as a command separator in exrc, so it's not clear to me if there is an actual bug or if you are fighting against a poorly documented feature. Hi, this is some kind of feature of nvi. You can take a look at the sources. Apart of the traditional command separator, you can use it in some other contexts, making life easiest. The part of the code that make that possible is somewhat, let's say _funny_. For example, you can make a map like this: map =c yEo^[p:.,.! tr -d '\n' | wc -m^M to count the following word, because after the !, vi will treat '|' like part of the shell command. But if you put that in exrc, it will treat the '|' like a command separator. The magic is in common/seq.c, there I saw that when constructing the sequence from input, it inserts before a CH_LITERAL (0x16). Indeed you can use Control-X to insert 0x16 before '|' in exrc, and the map will work. If you mind correctness you have several choices: One is to make the loading of exrc behave like the typed commands (that is what the patch does). another is to add a comment in the man page about inserting 0x16 before '|' in exrc when you don't want to use it like a command separator (I really don't like this option). Well, another solution could be to use Control-V to insert the pair 0x16| when used before |, and document the different behavior when loading a configuration file, or better, make that the common behavior typing commands and loading them. Of course the more sensible aproach to me is just to use another character for command separation, but that would be a big change for this venerable companion... Or maybe I'm just missing something and the best option is just to ignore me. Regards, adr
Re: nvi problems with '|' in exrc
On 2019-10-10, adr wrote: > I found that '|' can't be used in exrc files, unless a 0x16 precedes > it. This is what the code does in seq.c. The problem is in both > editors/nvi and base. I have the vaguest memory that '|' might be special in exrc... In my mutt configuration, I call vi with this environment setting: EXINIT="source ~/.nexrc|set wl=72" A quick check confirms that '|' also works as a command separator in exrc, so it's not clear to me if there is an actual bug or if you are fighting against a poorly documented feature. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: nvi problems with '|' in exrc
I forgot to update the length of the new string.
$OpenBSD$
Index: ex/ex_source.c
--- ex/ex_source.c.orig
+++ ex/ex_source.c
@@ -38,8 +38,8 @@ int
ex_source(SCR *sp, EXCMD *cmdp)
{
struct stat sb;
- int fd, len;
- char *bp;
+ int fd, len, i;
+ char *bp, c;
char *name, *np;
size_t nlen;
CHAR_T *wp;
@@ -64,8 +64,19 @@ ex_source(SCR *sp, EXCMD *cmdp)
errno = ENOMEM;
goto err;
}
-
- MALLOC(sp, bp, char *, (size_t)sb.st_size + 1);
+ i = 0;
+ for (len = 0; len < sb.st_size; ++len) {
+ if ((rc = read(fd, , 1)) <= 0) {
+ if (rc == 0)
+ errno = EIO;
+ (void)close(fd);
+ goto err;
+ }
+ if (c == '|')
+ ++i;
+ }
+ lseek(fd, 0, SEEK_SET);
+ MALLOC(sp, bp, char *, (size_t)sb.st_size + 1 + i);
if (bp == NULL) {
(void)close(fd);
return (1);
@@ -73,18 +84,28 @@ ex_source(SCR *sp, EXCMD *cmdp)
bp[sb.st_size] = '\0';
/* Read the file into memory. */
- len = read(fd, bp, (int)sb.st_size);
+ np = bp;
+ for (len = 0; len < sb.st_size; ++len, ++np) {
+ if ((rc = read(fd, np, 1)) <= 0) {
+ len = rc;
+ if (len == 0)
+ errno = EIO;
+ break;
+ }
+ if (*np == '|') {
+ *np = CH_LITERAL;
+ *++np = '|';
+ }
+ }
(void)close(fd);
- if (len == -1 || len != sb.st_size) {
- if (len != sb.st_size)
- errno = EIO;
+ if (len != sb.st_size) {
free(bp);
err: msgq_str(sp, M_SYSERR, name, "%s");
return (1);
- }
+ }
np = strdup(name);
- if (CHAR2INT(sp, bp, (size_t)sb.st_size + 1, wp, wlen))
+ if (CHAR2INT(sp, bp, (size_t)sb.st_size + 1 + i, wp, wlen))
msgq(sp, M_ERR, "323|Invalid input. Truncated.");
/* Put it on the ex queue. */
rc = ex_run_str(sp, np, wp, wlen - 1, 1, 0);
nvi problems with '|' in exrc
I found that '|' can't be used in exrc files, unless a 0x16 precedes
it. This is what the code does in seq.c. The problem is in both
editors/nvi and base.
This is a dirty hack if someone is interested. It's for editors/nvi,
but for base would be almost identical.
adr
$OpenBSD$
Index: ex/ex_source.c
--- ex/ex_source.c.orig
+++ ex/ex_source.c
@@ -38,8 +38,8 @@ int
ex_source(SCR *sp, EXCMD *cmdp)
{
struct stat sb;
- int fd, len;
- char *bp;
+ int fd, len, i;
+ char *bp, c;
char *name, *np;
size_t nlen;
CHAR_T *wp;
@@ -64,8 +64,19 @@ ex_source(SCR *sp, EXCMD *cmdp)
errno = ENOMEM;
goto err;
}
-
- MALLOC(sp, bp, char *, (size_t)sb.st_size + 1);
+ i = 0;
+ for (len = 0; len < sb.st_size; ++len){
+ if ((rc = read(fd, , 1)) <= 0) {
+ if (rc == 0)
+ errno = EIO;
+ (void)close(fd);
+ goto err;
+ }
+ if (c == '|')
+ ++i;
+ }
+ lseek(fd, 0, SEEK_SET);
+ MALLOC(sp, bp, char *, (size_t)sb.st_size + 1 + i);
if (bp == NULL) {
(void)close(fd);
return (1);
@@ -73,15 +84,25 @@ ex_source(SCR *sp, EXCMD *cmdp)
bp[sb.st_size] = '\0';
/* Read the file into memory. */
- len = read(fd, bp, (int)sb.st_size);
+ np = bp;
+ for (len = 0; len < sb.st_size; ++len, ++np){
+ if ((rc = read(fd, np, 1)) <= 0) {
+ len = rc;
+ if (len == 0)
+ errno = EIO;
+ break;
+ }
+ if (*np == '|'){
+ *np++ = CH_LITERAL;
+ *np = '|';
+ }
+ }
(void)close(fd);
- if (len == -1 || len != sb.st_size) {
- if (len != sb.st_size)
- errno = EIO;
+ if (len != sb.st_size){
free(bp);
err: msgq_str(sp, M_SYSERR, name, "%s");
return (1);
- }
+ }
np = strdup(name);
if (CHAR2INT(sp, bp, (size_t)sb.st_size + 1, wp, wlen))
Re: warning while updating Nextcloud
On 2019/10/10 18:31, Giovanni Bechis wrote: > While updating nextcloud on i386 I have this warning: > > nextcloud-16.0.5:php+php-bz2+php-curl+php-gd+php-intl+php-pdo_sqlite+php-zip-7.3.9->7.3.10: > ok > nextcloud-16.0.5:pecl73-imagick-3.4.4->3.4.4: ok > nextcloud-16.0.5:pecl73-redis-5.0.2->5.0.2: ok > File /var/www/nextcloud/config/CAN_INSTALL does not exist > nextcloud-16.0.4->16.0.5: ok I think the fix will be to stop packaging the file, and tell people to use touch to create the file before going through the installer process. > Is it worth fixing it for release ? No..
Re: Troubles with Bro
"dan (ddp)" wrote: > On Wed, Oct 9, 2019 at 2:06 PM Predrag Punosevac > wrote: > > > > Hi Ports, > > > > I am fully aware that this is very late in a release cycle so hopefully > > this works as expected on 6.6 which I didn't test > > > > iris# uname -a > > OpenBSD iris.int.autonsys.com 6.5 GENERIC.MP#5 amd64 > > iris# syspatch -l > > 001_rip6cksum > > 002_srtp > > 003_mds > > 004_bgpd > > 005_libssl > > 006_tcpsack > > 007_smtpd > > 008_swapgs > > 009_resume > > 010_frag6ecn > > 011_expat > > 012_sysupgrade > > 013_unbound > > 014_dhcpd > > > > iris# /usr/local/bin/broctl deploy > > checking configurations ... > > bro scripts failed. > > error in /usr/local/share/bro/base/protocols/dce-rpc/./main.bro, line > > 51: "redef" used but not previously defined (DPD::ignore_violations) > > > > > > Notice that I only change the name of the interface in > > /etc/bro/node.cfg per /usr/local/share/doc/pkg-readmes/bro > > > > iris# /usr/local/bin/broctl start > > Warning: broctl node config has changed (run the broctl "deploy" > > command) > > starting bro ... > > Error: bro terminated immediately after starting; check output with > > "diag" > > > > iris# /usr/local/bin/broctl status > > Warning: broctl node config has changed (run the broctl "deploy" > > command) > > Name Type Host StatusPidStarted > > bro standalone localhost stopped > > > > > > > > iris# /usr/local/bin/broctl diag > > Warning: broctl node config has changed (run the broctl "deploy" > > command) > > [bro] > > > > No core file found and egdb is not installed. It is recommended to > > install egdb so that BroControl can output a backtrace if Bro crashes. > > > > Bro 2.6.4 > > OpenBSD 6.5 > > > > Bro plugins: (none found) > > > > No reporter.log > > > > stderr.log > > error in /usr/local/share/bro/base/protocols/dce-rpc/./main.bro, line > > 51: "redef" used but not previously defined (DPD::ignore_violations) > > > > stdout.log > > max memory size (kbytes, -m) unlimited > > data seg size (kbytes, -d) 33554432 > > core file size (blocks, -c) unlimited > > > > .cmdline > > -i em0 -U .status -p broctl -p broctl-live -p standalone -p local -p bro > > local.bro broctl broctl/standalone broctl/auto > > > > .env_vars > > PATH=/usr/local/bin:/usr/local/share/broctl/scripts:/sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin:/usr/local/sbin:/usr/local/bin > > BROPATH=/var/spool/bro/installed-scripts-do-not-touch/site::/var/spool/bro/installed-scripts-do-not-touch/auto:/usr/local/share/bro:/usr/local/share/bro/policy:/usr/local/share/bro/site > > CLUSTER_NODE= > > > > .status > > TERMINATED [atexit] > > > > No prof.log > > > > No packet_filter.log > > > > No loaded_scripts.log > > > > > > > > Also > > > > Cron /usr/local/bin/broctl cron > > > > Error: cannot start bro; check output of "diag" > > Error: env: bash: No such file or directory > > > > starting bro ... > > > > This used to work as expected in 6.4 I shut down my installation as I > > didn't need at that time but I now needed badly. I will upgrade to 6.6 > > as soon as it is released. > > > > I've had similar errors after upgrading the package. I usually have to > uninstall and re-install it. > Copying the configuration out of etc and replacing it after the > re-install has worked fine for me. > I haven't had time to look into the issue at all, so I don't have any > clues as to why it actually happens. > Sure enough uninstalling and re-installing fixed for me as well. Thank you so much for quick heads-up. Predrag > > > > Best, > > Predrag > > > >
Re: warning while updating Nextcloud
On Thu, Oct 10, 2019 at 06:31:15PM +0200, Giovanni Bechis wrote:
> While updating nextcloud on i386 I have this warning:
>
> nextcloud-16.0.5:php+php-bz2+php-curl+php-gd+php-intl+php-pdo_sqlite+php-zip-7.3.9->7.3.10:
> ok
> nextcloud-16.0.5:pecl73-imagick-3.4.4->3.4.4: ok
> nextcloud-16.0.5:pecl73-redis-5.0.2->5.0.2: ok
> File /var/www/nextcloud/config/CAN_INSTALL does not exist
> nextcloud-16.0.4->16.0.5: ok
>
> Is it worth fixing it for release ?
>
dmesg attached.
Giovanni
OpenBSD 6.6 (GENERIC) #292: Tue Oct 8 17:46:27 MDT 2019
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
real mem = 536363008 (511MB)
avail mem = 510914560 (487MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 20/80/26, BIOS32 rev. 0 @ 0xfac40
pcibios0 at bios0: rev 2.0 @ 0xf/0x1
pcibios0: pcibios_get_intr_routing - function not supported
pcibios0: PCI IRQ Routing information unavailable.
pcibios0: PCI bus #0 is the last bus
bios0: ROM list: 0xc8000/0xa800
cpu0 at mainbus0: (uniprocessor)
cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD" 586-class) 500
MHz, 05-0a-02
cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX,MMXX,3DNOW2,3DNOW
mtrr: K6-family MTRR support (2 registers)
amdmsr0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
0:20:0: io address conflict 0x6100/0x100
0:20:0: io address conflict 0x6200/0x200
pchb0 at pci0 dev 1 function 0 "AMD Geode LX" rev 0x31
glxsb0 at pci0 dev 1 function 2 "AMD Geode LX Crypto" rev 0x00: RNG AES
vr0 at pci0 dev 6 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 11, address
00:00:24:c8:de:80
ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063,
model 0x0034
vr1 at pci0 dev 7 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 5, address
00:00:24:c8:de:81
ukphy1 at vr1 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063,
model 0x0034
vr2 at pci0 dev 8 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 9, address
00:00:24:c8:de:82
ukphy2 at vr2 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063,
model 0x0034
vr3 at pci0 dev 9 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 12, address
00:00:24:c8:de:83
ukphy3 at vr3 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063,
model 0x0034
glxpcib0 at pci0 dev 20 function 0 "AMD CS5536 ISA" rev 0x03: rev 3, 32-bit
3579545Hz timer, watchdog, gpio, i2c
gpio0 at glxpcib0: 32 pins
iic0 at glxpcib0
pciide0 at pci0 dev 20 function 2 "AMD CS5536 IDE" rev 0x01: DMA, channel 0
wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0:
wd0: 16-sector PIO, LBA48, 476940MB, 976773168 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
pciide0: channel 1 ignored (disabled)
ohci0 at pci0 dev 21 function 0 "AMD CS5536 USB" rev 0x02: irq 15, version 1.0,
legacy support
ehci0 at pci0 dev 21 function 1 "AMD CS5536 USB" rev 0x02: irq 15
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "AMD EHCI root hub" rev 2.00/1.00
addr 1
isa0 at glxpcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com0: console
com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbc0: unable to establish interrupt for irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
nsclpcsio0 at isa0 port 0x2e/2: NSC PC87366 rev 9: GPIO VLM TMS
gpio1 at nsclpcsio0: 29 pins
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
usb1 at ohci0: USB revision 1.0
uhub1 at usb1 configuration 1 interface 0 "AMD OHCI root hub" rev 1.00/1.00
addr 1
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
scsibus2 at softraid0: 256 targets
root on wd0a (5527fdd6d670763b.a) swap on wd0b dump on wd0b
warning while updating Nextcloud
While updating nextcloud on i386 I have this warning: nextcloud-16.0.5:php+php-bz2+php-curl+php-gd+php-intl+php-pdo_sqlite+php-zip-7.3.9->7.3.10: ok nextcloud-16.0.5:pecl73-imagick-3.4.4->3.4.4: ok nextcloud-16.0.5:pecl73-redis-5.0.2->5.0.2: ok File /var/www/nextcloud/config/CAN_INSTALL does not exist nextcloud-16.0.4->16.0.5: ok Is it worth fixing it for release ? Giovanni
Re: [NEW] Notmuch 0.29.1
Hi ports@, the attached tarball updates the work-in-progress port to upstream notmuch 0.29.1. The notmuch project fixed some build-related issues, fixed bugs and improved the Emacs bindings, now distribute signed sha sums among other changes. See [1] for a detailed list of changes. I've dropped the mentions on Python 2.7 due to Python 2 being sunsetting. The port now builds the bindings for Python 3 and Emacs. I've been using the port for the last week on -CURRENT#366 (2019/10/9 snapshot) and it works fine (I am composing this mail using Emacs+Notmuch). Admittedly, the tests are broken, I might look into them though, as they could provide pointers on what to work on. Please let me know what I can do to improve this port. Cheers, Enric notmuch,4.tgz Description: Notmuch port milestone 4 [1]: https://notmuchmail.org/pipermail/notmuch/2019/028080.html
Re: Troubles with Bro
On Wed, Oct 9, 2019 at 2:06 PM Predrag Punosevac wrote: > > Hi Ports, > > I am fully aware that this is very late in a release cycle so hopefully > this works as expected on 6.6 which I didn't test > > iris# uname -a > OpenBSD iris.int.autonsys.com 6.5 GENERIC.MP#5 amd64 > iris# syspatch -l > 001_rip6cksum > 002_srtp > 003_mds > 004_bgpd > 005_libssl > 006_tcpsack > 007_smtpd > 008_swapgs > 009_resume > 010_frag6ecn > 011_expat > 012_sysupgrade > 013_unbound > 014_dhcpd > > iris# /usr/local/bin/broctl deploy > checking configurations ... > bro scripts failed. > error in /usr/local/share/bro/base/protocols/dce-rpc/./main.bro, line > 51: "redef" used but not previously defined (DPD::ignore_violations) > > > Notice that I only change the name of the interface in > /etc/bro/node.cfg per /usr/local/share/doc/pkg-readmes/bro > > iris# /usr/local/bin/broctl start > Warning: broctl node config has changed (run the broctl "deploy" > command) > starting bro ... > Error: bro terminated immediately after starting; check output with > "diag" > > iris# /usr/local/bin/broctl status > Warning: broctl node config has changed (run the broctl "deploy" > command) > Name Type Host StatusPidStarted > bro standalone localhost stopped > > > > iris# /usr/local/bin/broctl diag > Warning: broctl node config has changed (run the broctl "deploy" > command) > [bro] > > No core file found and egdb is not installed. It is recommended to > install egdb so that BroControl can output a backtrace if Bro crashes. > > Bro 2.6.4 > OpenBSD 6.5 > > Bro plugins: (none found) > > No reporter.log > > stderr.log > error in /usr/local/share/bro/base/protocols/dce-rpc/./main.bro, line > 51: "redef" used but not previously defined (DPD::ignore_violations) > > stdout.log > max memory size (kbytes, -m) unlimited > data seg size (kbytes, -d) 33554432 > core file size (blocks, -c) unlimited > > .cmdline > -i em0 -U .status -p broctl -p broctl-live -p standalone -p local -p bro > local.bro broctl broctl/standalone broctl/auto > > .env_vars > PATH=/usr/local/bin:/usr/local/share/broctl/scripts:/sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin:/usr/local/sbin:/usr/local/bin > BROPATH=/var/spool/bro/installed-scripts-do-not-touch/site::/var/spool/bro/installed-scripts-do-not-touch/auto:/usr/local/share/bro:/usr/local/share/bro/policy:/usr/local/share/bro/site > CLUSTER_NODE= > > .status > TERMINATED [atexit] > > No prof.log > > No packet_filter.log > > No loaded_scripts.log > > > > Also > > Cron /usr/local/bin/broctl cron > > Error: cannot start bro; check output of "diag" > Error: env: bash: No such file or directory > > starting bro ... > > This used to work as expected in 6.4 I shut down my installation as I > didn't need at that time but I now needed badly. I will upgrade to 6.6 > as soon as it is released. > I've had similar errors after upgrading the package. I usually have to uninstall and re-install it. Copying the configuration out of etc and replacing it after the re-install has worked fine for me. I haven't had time to look into the issue at all, so I don't have any clues as to why it actually happens. > > Best, > Predrag > >
Re: [ports-gcc] Unbreak geo/gpsbabel
OK for post-6.6.
On 2019/10/10 11:30, Charlene Wendling wrote:
> On Thu, 10 Oct 2019 09:17:33 +0300
> Kirill Bychkov wrote:
>
> > On Thu, October 10, 2019 02:55, Charlene Wendling wrote:
> > > Hi,
> > >
> > > I was trying to build qt5^W geo/qlandkartegt with naddy's latest
> > > fix on macppc, but i hit that:
> > >
> > >> http://build-failures.rhaalovely.net//sparc64/2019-10-06/geo/gpsbabel.log
> > >> http://build-failures.rhaalovely.net//powerpc/2019-09-17/geo/gpsbabel.log
> > >
> > > I found out that landry met the issue with print/poppler, i quote
> > > the commit [0] message:
> > >
> > >> Add ${MODGCC4_CPPLIBDEP} to LIB_DEPENDS-*, changes nothing for
> > >> clang archs, but fixes the dreaded 'Missing library for estdc+
> > >> +>=17.0' error message at pkg_create on other archs.
> > >> COMPILER_LIBCXX is in WANTLIB-*, but nothing brought it into
> > >> context, as ${MODGCC4_CPPLIBDEP} is only in LIB_DEPENDS, which
> > >> isnt inherited by LIB_DEPENDS-* here.
> > >
> > > I bumped REVISION as this version was already built during a
> > > previous macppc fix for qlandkartegt iirc.
> > >
> > > This builds fine on amd64 and macppc [1].
> > >
> > > Two ports depend on it: geo/qlandkartegt (it's still building) and
> > > geo/viking
> > >
> > > naddy, sthen: i let you decide if it's critical enough to get
> > > committed, otherwise i'll ping post-unlock :)
> > >
> > > Charl?ne.
> > >
> > >
> > > [0]
> > > https://github.com/openbsd/ports/commit/10eedd1e2cf2afea1bcbe41e374ce44fb7be4a8a
> > > [1] https://bin.charlenew.xyz/gpsbabel.missinglib.log
> > >
> > >
> [...]
> >
> > Hi,
> > I was testing simillar diff. Looks like ${MODGCC4_CPPLIBDEP} is
> > needed only for -main and -qt.
> >
>
> It makes sense indeed given the WANTLIB! I tested again on macppc and
> amd64 - it builds fine.
>
> Charlène.
>
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/geo/gpsbabel/Makefile,v
> retrieving revision 1.35
> diff -u -p -u -p -r1.35 Makefile
> --- Makefile 3 Sep 2019 13:48:25 - 1.35
> +++ Makefile 10 Oct 2019 09:07:01 -
> @@ -12,6 +12,9 @@ DISTNAME= gpsbabel-${VERSION}
> PKGNAME-main=gpsbabel-${VERSION}
> PKGNAME-tk= gpsbabel-tk-${VERSION}
> PKGNAME-qt= gpsbabel-qt-${VERSION}
> +REVISION-main= 0
> +REVISION-tk= 0
> +REVISION-qt= 0
> CATEGORIES= geo
>
> HOMEPAGE=https://www.gpsbabel.org/
> @@ -34,7 +37,8 @@ MULTI_PACKAGES= -main -tk -qt
> MODULES= devel/qmake x11/tk x11/qt5
> MODQMAKE_PROJECTS = gui/app.pro
>
> -LIB_DEPENDS-main=devel/libusb-compat \
> +LIB_DEPENDS-main=${MODGCC4_CPPLIBDEP} \
> + devel/libusb-compat \
> devel/shapelib
>
> cWANTLIB = c m pthread
> @@ -44,7 +48,8 @@ WANTLIB-qt += GL Qt5Core Qt5Gui Qt5Netwo
> WANTLIB-qt += Qt5Widgets Qt5Xml ${COMPILER_LIBCXX} ${cWANTLIB}
>
> LIB_DEPENDS-tk=
> -LIB_DEPENDS-qt= x11/qt5/qtwebkit
> +LIB_DEPENDS-qt= ${MODGCC4_CPPLIBDEP} \
> + x11/qt5/qtwebkit
> PKG_ARCH-tk= *
> RUN_DEPENDS-tk= geo/gpsbabel \
> ${MODTK_RUN_DEPENDS}
>
Re: [ports-gcc] Unbreak geo/gpsbabel
On Thu, 10 Oct 2019 09:17:33 +0300
Kirill Bychkov wrote:
> On Thu, October 10, 2019 02:55, Charlene Wendling wrote:
> > Hi,
> >
> > I was trying to build qt5^W geo/qlandkartegt with naddy's latest
> > fix on macppc, but i hit that:
> >
> >> http://build-failures.rhaalovely.net//sparc64/2019-10-06/geo/gpsbabel.log
> >> http://build-failures.rhaalovely.net//powerpc/2019-09-17/geo/gpsbabel.log
> >
> > I found out that landry met the issue with print/poppler, i quote
> > the commit [0] message:
> >
> >> Add ${MODGCC4_CPPLIBDEP} to LIB_DEPENDS-*, changes nothing for
> >> clang archs, but fixes the dreaded 'Missing library for estdc+
> >> +>=17.0' error message at pkg_create on other archs.
> >> COMPILER_LIBCXX is in WANTLIB-*, but nothing brought it into
> >> context, as ${MODGCC4_CPPLIBDEP} is only in LIB_DEPENDS, which
> >> isnt inherited by LIB_DEPENDS-* here.
> >
> > I bumped REVISION as this version was already built during a
> > previous macppc fix for qlandkartegt iirc.
> >
> > This builds fine on amd64 and macppc [1].
> >
> > Two ports depend on it: geo/qlandkartegt (it's still building) and
> > geo/viking
> >
> > naddy, sthen: i let you decide if it's critical enough to get
> > committed, otherwise i'll ping post-unlock :)
> >
> > Charl?ne.
> >
> >
> > [0]
> > https://github.com/openbsd/ports/commit/10eedd1e2cf2afea1bcbe41e374ce44fb7be4a8a
> > [1] https://bin.charlenew.xyz/gpsbabel.missinglib.log
> >
> >
[...]
>
> Hi,
> I was testing simillar diff. Looks like ${MODGCC4_CPPLIBDEP} is
> needed only for -main and -qt.
>
It makes sense indeed given the WANTLIB! I tested again on macppc and
amd64 - it builds fine.
Charlène.
Index: Makefile
===
RCS file: /cvs/ports/geo/gpsbabel/Makefile,v
retrieving revision 1.35
diff -u -p -u -p -r1.35 Makefile
--- Makefile3 Sep 2019 13:48:25 - 1.35
+++ Makefile10 Oct 2019 09:07:01 -
@@ -12,6 +12,9 @@ DISTNAME= gpsbabel-${VERSION}
PKGNAME-main= gpsbabel-${VERSION}
PKGNAME-tk=gpsbabel-tk-${VERSION}
PKGNAME-qt=gpsbabel-qt-${VERSION}
+REVISION-main= 0
+REVISION-tk= 0
+REVISION-qt= 0
CATEGORIES=geo
HOMEPAGE= https://www.gpsbabel.org/
@@ -34,7 +37,8 @@ MULTI_PACKAGES= -main -tk -qt
MODULES= devel/qmake x11/tk x11/qt5
MODQMAKE_PROJECTS =gui/app.pro
-LIB_DEPENDS-main= devel/libusb-compat \
+LIB_DEPENDS-main= ${MODGCC4_CPPLIBDEP} \
+ devel/libusb-compat \
devel/shapelib
cWANTLIB = c m pthread
@@ -44,7 +48,8 @@ WANTLIB-qt += GL Qt5Core Qt5Gui Qt5Netwo
WANTLIB-qt += Qt5Widgets Qt5Xml ${COMPILER_LIBCXX} ${cWANTLIB}
LIB_DEPENDS-tk=
-LIB_DEPENDS-qt=x11/qt5/qtwebkit
+LIB_DEPENDS-qt=${MODGCC4_CPPLIBDEP} \
+ x11/qt5/qtwebkit
PKG_ARCH-tk= *
RUN_DEPENDS-tk=geo/gpsbabel \
${MODTK_RUN_DEPENDS}
Re: [ports-gcc] Unbreak geo/gpsbabel
On Thu, October 10, 2019 02:55, Charlene Wendling wrote:
> Hi,
>
> I was trying to build qt5^W geo/qlandkartegt with naddy's latest fix on
> macppc, but i hit that:
>
>> http://build-failures.rhaalovely.net//sparc64/2019-10-06/geo/gpsbabel.log
>> http://build-failures.rhaalovely.net//powerpc/2019-09-17/geo/gpsbabel.log
>
> I found out that landry met the issue with print/poppler, i quote the
> commit [0] message:
>
>> Add ${MODGCC4_CPPLIBDEP} to LIB_DEPENDS-*, changes nothing for clang
>> archs, but fixes the dreaded 'Missing library for estdc++>=17.0' error
>> message at pkg_create on other archs. COMPILER_LIBCXX is in WANTLIB-*,
>> but nothing brought it into context, as ${MODGCC4_CPPLIBDEP} is only in
>> LIB_DEPENDS, which isnt inherited by LIB_DEPENDS-* here.
>
> I bumped REVISION as this version was already built during a previous
> macppc fix for qlandkartegt iirc.
>
> This builds fine on amd64 and macppc [1].
>
> Two ports depend on it: geo/qlandkartegt (it's still building) and
> geo/viking
>
> naddy, sthen: i let you decide if it's critical enough to get
> committed, otherwise i'll ping post-unlock :)
>
> Charl?ne.
>
>
> [0]
> https://github.com/openbsd/ports/commit/10eedd1e2cf2afea1bcbe41e374ce44fb7be4a8a
> [1] https://bin.charlenew.xyz/gpsbabel.missinglib.log
>
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/geo/gpsbabel/Makefile,v
> retrieving revision 1.35
> diff -u -p -u -p -r1.35 Makefile
> --- Makefile 3 Sep 2019 13:48:25 - 1.35
> +++ Makefile 9 Oct 2019 23:41:05 -
> @@ -12,6 +12,9 @@ DISTNAME= gpsbabel-${VERSION}
> PKGNAME-main=gpsbabel-${VERSION}
> PKGNAME-tk= gpsbabel-tk-${VERSION}
> PKGNAME-qt= gpsbabel-qt-${VERSION}
> +REVISION-main= 0
> +REVISION-tk= 0
> +REVISION-qt= 0
> CATEGORIES= geo
>
> HOMEPAGE=https://www.gpsbabel.org/
> @@ -34,7 +37,8 @@ MULTI_PACKAGES= -main -tk -qt
> MODULES= devel/qmake x11/tk x11/qt5
> MODQMAKE_PROJECTS = gui/app.pro
>
> -LIB_DEPENDS-main=devel/libusb-compat \
> +LIB_DEPENDS-main=${MODGCC4_CPPLIBDEP} \
> + devel/libusb-compat \
> devel/shapelib
>
> cWANTLIB = c m pthread
> @@ -43,8 +47,9 @@ WANTLIB-tk =
> WANTLIB-qt += GL Qt5Core Qt5Gui Qt5Network Qt5WebKit Qt5WebKitWidgets
> WANTLIB-qt += Qt5Widgets Qt5Xml ${COMPILER_LIBCXX} ${cWANTLIB}
>
> -LIB_DEPENDS-tk=
> -LIB_DEPENDS-qt= x11/qt5/qtwebkit
> +LIB_DEPENDS-tk= ${MODGCC4_CPPLIBDEP}
> +LIB_DEPENDS-qt= ${MODGCC4_CPPLIBDEP} \
> + x11/qt5/qtwebkit
> PKG_ARCH-tk= *
> RUN_DEPENDS-tk= geo/gpsbabel \
> ${MODTK_RUN_DEPENDS}
>
>
Hi,
I was testing simillar diff. Looks like ${MODGCC4_CPPLIBDEP} is needed only
for -main and -qt.
