[SMALL FIX] archivers/lrzip
Hello,
lrzip's ZPAQ has been broken since this port got added to the tree.
This patch fixes it. It has been working for years for me.
diff -u -p -r1.3 Makefile
--- Makefile4 Nov 2022 15:05:10 - 1.3
+++ Makefile22 Apr 2024 11:12:34 -
@@ -3,7 +3,7 @@ COMMENT = compression utility for large
GH_ACCOUNT = ckolivas
GH_PROJECT = lrzip
GH_TAGNAME = v0.651
-REVISION = 0
+REVISION = 1
CATEGORIES = archivers
@@ -24,7 +24,7 @@ RUN_DEPENDS = shells/bash
CONFIGURE_STYLE = autoreconf
CONFIGURE_ARGS = --disable-doc
-CONFIGURE_ENV =CPPFLAGS="-I${LOCALBASE}/include" \
+CONFIGURE_ENV =CPPFLAGS="-I${LOCALBASE}/include -DNOJIT" \
LDFLAGS="-L${LOCALBASE}/lib" \
ac_cv_prog_ASM_PROG='no '
# don't pick up archivers/nasm; it breaks build
Re: [NEW] security/nitrocli
This is a second attempt at the port, incorporating some suggestions
from Klemens Nanni.
I include both a full version of the port (attached) and a patch that
shows the differences between the earlier version and the current
version of the port (attached).
nitrocli.tar.gz
Description: application/gzip
diff -Nur nitrocli.orig/Makefile nitrocli/Makefile
--- nitrocli.orig/Makefile Sun Apr 14 15:28:33 2024
+++ nitrocli/Makefile Mon Apr 22 12:18:42 2024
@@ -18,91 +18,24 @@
LIB_DEPENDS = comms/libhidapi
+RUN_DEPENDS = security/gnupg
+
COMPILER = base-clang ports-gcc
CONFIGURE_STYLE = cargo
MODCARGO_RUSTFLAGS = -L ${LOCALBASE}/lib
-MODCARGO_CRATES += aho-corasick 0.7.18 # Unlicense/MIT
-MODCARGO_CRATES += anyhow 1.0.40 # MIT OR Apache-2.0
-MODCARGO_CRATES += autocfg 1.0.1 # Apache-2.0 OR MIT
-MODCARGO_CRATES += base32 0.4.0 # MIT OR Apache-2.0
-MODCARGO_CRATES += bitflags 1.2.1 # MIT/Apache-2.0
-MODCARGO_CRATES += cc 1.0.67 # MIT/Apache-2.0
-MODCARGO_CRATES += cfg-if 1.0.0 # MIT/Apache-2.0
-MODCARGO_CRATES += clap 2.33.3 # MIT
-MODCARGO_CRATES += directories 3.0.2 # MIT OR Apache-2.0
-MODCARGO_CRATES += dirs-sys 0.3.6 # MIT OR Apache-2.0
-MODCARGO_CRATES += envy 0.4.2 # MIT
-MODCARGO_CRATES += getrandom 0.1.16 # MIT OR Apache-2.0
-MODCARGO_CRATES += getrandom 0.2.2 # MIT OR Apache-2.0
-MODCARGO_CRATES += heck 0.3.2 # MIT OR Apache-2.0
-MODCARGO_CRATES += lazy_static 1.4.0 # MIT/Apache-2.0
-MODCARGO_CRATES += libc 0.2.94 # MIT OR Apache-2.0
-MODCARGO_CRATES += log 0.4.14 # MIT OR Apache-2.0
-MODCARGO_CRATES += memchr 2.4.0 # Unlicense/MIT
-MODCARGO_CRATES += merge 0.1.0 # Apache-2.0 OR MIT
-MODCARGO_CRATES += merge_derive 0.1.0 # Apache-2.0 OR MIT
-MODCARGO_CRATES += nitrokey 0.9.0 # MIT
-MODCARGO_CRATES += nitrokey-sys 3.6.0 # LGPL-3.0
-MODCARGO_CRATES += nitrokey-test 0.5.0 # GPL-3.0-or-later
-MODCARGO_CRATES += nitrokey-test-state 0.1.0 # GPL-3.0-or-later
-MODCARGO_CRATES += num-traits 0.2.14 # MIT OR Apache-2.0
-MODCARGO_CRATES += numtoa 0.1.0 # MIT OR Apache-2.0
-MODCARGO_CRATES += ppv-lite86 0.2.10 # MIT/Apache-2.0
-MODCARGO_CRATES += proc-macro-error 1.0.4 # MIT OR Apache-2.0
-MODCARGO_CRATES += proc-macro-error-attr 1.0.4 # MIT OR Apache-2.0
-MODCARGO_CRATES += proc-macro2 1.0.26 # MIT OR Apache-2.0
-MODCARGO_CRATES += progressing 3.0.2 # Apache-2.0
-MODCARGO_CRATES += quote 1.0.9 # MIT OR Apache-2.0
-MODCARGO_CRATES += rand 0.8.3 # MIT OR Apache-2.0
-MODCARGO_CRATES += rand_chacha 0.3.0 # MIT OR Apache-2.0
-MODCARGO_CRATES += rand_core 0.5.1 # MIT OR Apache-2.0
-MODCARGO_CRATES += rand_core 0.6.2 # MIT OR Apache-2.0
-MODCARGO_CRATES += rand_hc 0.3.0 # MIT OR Apache-2.0
-MODCARGO_CRATES += redox_syscall 0.2.8 # MIT
-MODCARGO_CRATES += redox_termios 0.1.2 # MIT
-MODCARGO_CRATES += redox_users 0.4.0 # MIT
-MODCARGO_CRATES += regex 1.5.4 # MIT OR Apache-2.0
-MODCARGO_CRATES += regex-syntax 0.6.25 # MIT/Apache-2.0
-MODCARGO_CRATES += remove_dir_all 0.5.3 # MIT/Apache-2.0
-MODCARGO_CRATES += serde 1.0.125 # MIT OR Apache-2.0
-MODCARGO_CRATES += serde_derive 1.0.125 # MIT OR Apache-2.0
-MODCARGO_CRATES += structopt 0.3.21 # Apache-2.0 OR MIT
-MODCARGO_CRATES += structopt-derive 0.4.14 # Apache-2.0/MIT
-MODCARGO_CRATES += syn 1.0.72 # MIT OR Apache-2.0
-MODCARGO_CRATES += tempfile 3.2.0 # MIT OR Apache-2.0
-MODCARGO_CRATES += termion 1.5.6 # MIT
-MODCARGO_CRATES += textwrap 0.11.0 # MIT
-MODCARGO_CRATES += toml 0.5.8 # MIT/Apache-2.0
-MODCARGO_CRATES += unicode-segmentation 1.7.1 # MIT/Apache-2.0
-MODCARGO_CRATES += unicode-width 0.1.8 # MIT/Apache-2.0
-MODCARGO_CRATES += unicode-xid 0.2.2 # MIT OR Apache-2.0
-MODCARGO_CRATES += version_check 0.9.3 # MIT/Apache-2.0
+.include "modules.inc"
-# Apache-2.0 WITH LLVM-exception OR Apache-2.0 OR MIT
-MODCARGO_CRATES += wasi 0.9.0+wasi-snapshot-preview1
-
-# Apache-2.0 WITH LLVM-exception OR Apache-2.0 OR MIT
-MODCARGO_CRATES += wasi 0.10.2+wasi-snapshot-preview1
-MODCARGO_CRATES += winapi 0.3.9 # MIT/Apache-2.0
-
-# MIT/Apache-2.0
-MODCARGO_CRATES += winapi-i686-pc-windows-gnu 0.4.0
-
-# MIT/Apache-2.0
-MODCARGO_CRATES += winapi-x86_64-pc-windows-gnu 0.4.0
-
-MODCARGO_VENDOR_DIR = ${WRKSRC}/modcargo-crates
-
-RUN_DEPENDS = security/gnupg
-
MY_REPLACE_CMD = sed -i s/hid_init/hidapi_hid_init/g
-MY_HIDAPI_DIR = /nitrokey-sys-*/libnitrokey-*/libnitrokey/
-MY_HIDAPI_HEADER = hidapi/hidapi.h
+MY_HEADER = /nitrokey-sys-*/libnitrokey-*/libnitrokey/hidapi/hidapi.h
post-patch:
- ${MY_REPLACE_CMD} ${MODCARGO_VENDOR_DIR}${MY_HIDAPI_DIR}${MY_HIDAPI_HEADER}
+ ${MY_REPLACE_CMD} ${MODCARGO_VENDOR_DIR}${MY_HEADER}
+
+post-install:
+ mv ${PREFIX}/bin/shell-complete \
+ ${PREFIX}/bin/nitrocli-shell-complete
.include
diff -Nur nitrocli.orig/modules.inc nitrocli/modules.inc
--- nitrocli.orig/modules.inc Thu Jan 1 01:00:00 1970
+++ nitrocli/modules.inc Sun Apr 14 15:31:32 2024
@@ -0,0 +1,69 @@
+MODCARGO_CRATES += aho-corasick 0.7.18 # Unlicense/MIT
+MODCARGO_CRATES += anyhow 1.0.40 # MIT OR Apache-2.0
+MODCARGO_CRATES += autocfg 1.0.1 # Apache-2.0 OR MIT
Re: [Please, unbreak] multimedia/handbrake
Hello, I tried with H.264 (10-bit) and it worked here. Give it try yourself. Brad Smith wrote: On 2024-04-13 11:00 p.m., Rubén Llorente wrote: It looks like h.264 works with your diff, since I encoded a movie into h.264 + AAC with no issues. You probably tried regular H.264. It's the high bit depth option (10-bit) that has an issue. Thanks for testing. Brad Smith wrote: Rubén, I'd love any and all feedback to try and get it into shape.
Re: [Please, unbreak] multimedia/handbrake
It looks like h.264 works with your diff, since I encoded a movie into h.264 + AAC with no issues. Brad Smith wrote: Rubén, I'd love any and all feedback to try and get it into shape.
Re: [Please, unbreak] multimedia/handbrake
Brad Smith wrote: Testing Brad's diff and reporting back to the list is probably the best way to move this forward. Rubén, I'd love any and all feedback to try and get it into shape. It is very late here. I managed to compile Handbrake 1.6.1 with your diff. I will encode a bunch of movies and report back with my findings next time I find the time for it.
Re: [Please, unbreak] multimedia/handbrake
Here you are. Stuart Henderson wrote: On 2024/04/13 14:48, Rubén Llorente wrote: Hello, multimedia/handbrake has been broken for at least three releases already. Please, either fix this port or remove it from the tree. Right now it is as good as junk. I am including a local mod of this port I have been using for a good while, just in case somebody finds it useful. It updates Handbrake to version 1.5.1 which, while not the latest, it is not broken. I make no claim about the correctness of this port (ie. I have not checked the listed dependencies are correct) but I hope it gets the ball rolling. Nothing attached. https://marc.info/?l=openbsd-ports=171230094127744=2 needs tests/feedback. handbrake.tar.gz Description: application/gzip
[Please, unbreak] multimedia/handbrake
Hello, multimedia/handbrake has been broken for at least three releases already. Please, either fix this port or remove it from the tree. Right now it is as good as junk. I am including a local mod of this port I have been using for a good while, just in case somebody finds it useful. It updates Handbrake to version 1.5.1 which, while not the latest, it is not broken. I make no claim about the correctness of this port (ie. I have not checked the listed dependencies are correct) but I hope it gets the ball rolling.
[NEW] security/nitrocli
Hello, I have been using this port in my personal machines for nearly a year already and it works alright. This port makes it so Nitrokey Pro, Nitrokey Storage and Librem Key devices are supported by OpenBSD. I have just build and tested this port on OpenBSD 7.5 (amd64) with a Nitrokey Storage 2. nitrocli.tar.gz Description: application/gzip
[NEW] sysutils/sake
Hello, I am submitting a Sake port. Sake is a command runner for executing batch jobs in remote servers. They have an official OpenBSD in github but so far we have no packaged version ourselves. sake.tar.gz Description: application/gzip
[NEW] security/nitrocli
Hello, This ought to be the definitive version of the port. nitrocli.tar.gz Description: application/gzip
Re: [NEW] nitrocli
Theo de Raadt wrote: +Beware this may allow the user unintended access to other hardware +associated to the same usb(4) controller, so do this with extreme +caution. Can you explain what extreme caution means? More than one piece of hardware can be attached to the same usb(4) device. You can, for example, have a mouse and a NitroKey both hanging from /dev/usb1 According to the manpage at usb(4), there are commands that can break the integrity of the bus over the usb interface. In other words: if I allow somebody read/write access to /dev/usb1 so he can use the NitroKey, he could mess up with everything depending on /dev/usb1, including hardware I didn't want him to have access to. There is people using NitroKeys in headless multiuser systems so this can be an issue. The administrator should do his best to ensure no USB hardware is connected to the same usb(4) interface the NitroKey is using if he wants to grant access to the NitroKey to one user but not to the other USB devices.
Re: [NEW] nitrocli
Stuart Henderson wrote:
> I don't think there's much else you can do if you want to run this on
> OpenBSD.
>
> Does it not also need access to some ugen or uhid device node as well as
> /dev/usbX?
I am afraid /dev/ugen* also needs its permissions adjusted. I have
updated the README to address this. I have also included some
workarounds for an upstream bug I have just discovered.
> The license marker comment should use the more restrictive license then,
> not MIT.
I have switched to GPL-3-0-or-later since it is the most restrictive of
the bunch.
> As a special case, I would suggest using sed -i rather than patching
> files with names embedding a version number e.g.
>
${WRKDIR}/modcargo-crates/nitrokey-sys-*/libnitrokey-*/libnitrokey/hidapi/hidapi.h
> (do you really need to patch what looks like a comment line in the other
> patch?)
I have removed the patches I had included and replaced them with a sed
command in the Makefile. Maybe there is a prettier way to accomplish the
same thing. I am open to suggestions.
Patch is attached.diff -uar nitrocli.old/Makefile nitrocli/Makefile
--- nitrocli.old/Makefile Thu Nov 9 03:21:39 2023
+++ nitrocli/Makefile Thu Nov 9 14:58:43 2023
@@ -9,7 +9,7 @@
MAINTAINER = Ruben Llorente
-# MIT
+# GPL-3.0-or-later
PERMIT_PACKAGE = Yes
MODULES = devel/cargo
@@ -97,5 +97,12 @@
MODCARGO_VENDOR_DIR = ${WRKSRC}/modcargo-crates
RUN_DEPENDS = security/gnupg
+
+MY_REPLACE_CMD = sed -i s/hid_init/hidapi_hid_init/g
+MY_HIDAPI_DIR = /nitrokey-sys-*/libnitrokey-*/libnitrokey/
+MY_HIDAPI_HEADER = hidapi/hidapi.h
+
+post-patch:
+ ${MY_REPLACE_CMD} ${MODCARGO_VENDOR_DIR}${MY_HIDAPI_DIR}${MY_HIDAPI_HEADER}
.include
Only in nitrocli.old: patches
diff -uar nitrocli.old/pkg/README nitrocli/pkg/README
--- nitrocli.old/pkg/README Thu Nov 9 03:31:11 2023
+++ nitrocli/pkg/README Thu Nov 9 15:19:48 2023
@@ -2,18 +2,38 @@
| Running ${FULLPKGNAME} on OpenBSD
+---
+Granting access to users
+===
The user running nitrocli needs the necessary privileges to access
the device. You may need to change the permissions of the corresponding
-usb(4) controller as a result. In order to do this, plug your
-NitroKey and use usbdevs(8) to identify the usb(4) controller it
-is attached to. Then use chmod(1) and/or chown(8) to give the user
-read/write access to the corresponding /dev/usb* character special
-device. Beware this may allow the user unintended access to other
-hardware associated to the same usb(4) controller, so do this with
-extreme caution.
+usb(4) and ugen(4) controllers as a result.
+You may identify the usb(4) device the NitroKey is attatched to with
+usbdevs(8). The corresponding ugen(4) device can be obtained from the
+ouput of dmesg(8). You may then use chgrp(1) and chmod(8) to grant
+access to the NitroKey. For example, in order to allow users from the
+wheel group to use the NitroKey you would issue commands such as:
+
+chgrp wheel /dev/usb1 /dev/ugen0.*
+chmod 640 /dev/usb1 /dev/ugen0.*
+
+Beware this may allow the user unintended access to other hardware
+associated to the same usb(4) controller, so do this with extreme
+caution.
+
+Interaction with gpg-agent
+===
A working gpg-agent is required for a number of operations. You may
need to add the following line to your $HOME/.profile in order to
ensure the agent is invoked properly:
export GPG_TTY=$(tty)
+
+There is a known bug in libnitrokey that may cause the NitroKey to hang
+if a smartcard operation is performed and a libnitrokey operation is
+attempted immediately afterwards. The implication is that if you use a
+NitroKey for decrypting or signing via gpg, you will need to either
+unplug and plug again the NitroKey right after, or restart the
+gpg-agent with:
+
+gpgconf --kill gpg-agent
[NEW] nitrocli
I am submitting a port which allows to use NitroKey hardware under OpenBSD. It has been lightly tested on OpenBSD -current and 7.4 (amd64) with a Nitrokey Storage 2. Under Linux, the software responsible for accessing the NitroKey over USB depends on udev rules to make the NitroKey available to regular users. Since this is not an option here, we need to manually chmod+chown the corresponding usb(4) character device. I have added a mention in the README, but the solution seems dirty to me and I would like to hear about alternatives, if somebody can come up with any. nitrocli is MIT licensed, but some of the cargo modules required for building this use licenses which are a bit more restrictive. In particular: nitrokey-sysLGPL-3.0 nitrokey-test GPL-3.0-or-later nitrokey-test-state GPL-3.0-or-later nitrocli.tar.gz Description: application/gzip
Re: [Update] lrzip
On Thu, Apr 27, 2023 at 12:02:30AM +0100, Stuart Henderson wrote: > All amd64 have sse2. > > However many JITs don't work unless writable-and-executable mappings > work. (Notable exceptions include Firefox's and luajit). > > [...] > > You could try it with the port built with USE_WXNEEDED=Yes and, > if it works, compare hiw well it works vs the NOJIT version. > Some quick test shows that the NOJIT version without USE_WXNEEDED is a slower but offers slightly better compression (speed loss is 30% and compression gain is 11%). Personally, I think if you are using zpaq it is because you care more about compression than speed. Nevertheless, I suppose that obscure architectures supported by OpenBSD may not include the required instruction set. If so, having the port ship without the NOJIT define for those would mean lrzip for those architectures would ship with a broken zpaq implementation. Thoughts? -- OpenPGP Key Fingerprint: 543F EB89 7FDE 8E33 AFF7 E794 E4AB 4807 58F7 6C76
Re: [Update] lrzip
According to libzpaq/libzpaq.h "By default, LIBZPAQ uses JIT (just in time) acceleration. This only works on x86-32 and x86-64 processors that support the SSE2 instruction set. To disable JIT, compile with -DNOJIT." Besides, I have tried the current lrzip port (without -DNOJIT) for zpaq compression and it fails due to other issues: computer$ du -h archive.tar 3.1Garchive.tar computer$ lrzip -z archive.tar Using configuration file /etc/lrzip/lrzip.conf Output filename is: archive.tar.lrz zpipe error: allocx failed computer$ I have not looked into it closely but it looks like an error from line 100 in libzpaq/libzpaq.cpp On Wed, Apr 26, 2023 at 09:46:16AM -0400, A Tammy wrote: > > On 4/25/23 12:10, Rubén Llorente wrote: > > Hello, > > > > this is a small update to the Makefile. > > > > The current port does not support zpaq compression on OpenBSD. The > > following change allows lrzip to use zpaq compression. > > > > > > > Why is there an addition of `-DNOJIT` to CPPFLAGS? -- OpenPGP Key Fingerprint: 543F EB89 7FDE 8E33 AFF7 E794 E4AB 4807 58F7 6C76
[Update] lrzip
Hello,
this is a small update to the Makefile.
The current port does not support zpaq compression on OpenBSD. The
following change allows lrzip to use zpaq compression.
--
OpenPGP Key Fingerprint:
543F EB89 7FDE 8E33 AFF7 E794 E4AB 4807 58F7 6C76
--- Makefile.orig Fri Nov 4 16:05:10 2022
+++ MakefileTue Apr 25 18:04:38 2023
@@ -3,7 +3,7 @@
GH_ACCOUNT = ckolivas
GH_PROJECT = lrzip
GH_TAGNAME = v0.651
-REVISION = 0
+REVISION = 1
CATEGORIES = archivers
@@ -24,7 +24,7 @@
CONFIGURE_STYLE = autoreconf
CONFIGURE_ARGS = --disable-doc
-CONFIGURE_ENV =CPPFLAGS="-I${LOCALBASE}/include" \
+CONFIGURE_ENV =CPPFLAGS="-I${LOCALBASE}/include -DNOJIT" \
LDFLAGS="-L${LOCALBASE}/lib" \
ac_cv_prog_ASM_PROG='no '
# don't pick up archivers/nasm; it breaks build
Re: Package collisions
On Wed, Oct 05, 2022 at 10:47:27PM +0100, Stuart Henderson wrote: > Disappointing that lrzip added a conflict with a long-standing Unix utility. > Undecided between renaming that to bin/lrzip and adding an @conflict. I don't know if there is many people interesting in running lrzip's lrz, actually. Adding a @conflict sounds ok but it still feels like an ugly hack to me. @conflict will do as a temporary solution but I'd probably should bring this to the attention of upstream. -- OpenPGP Key Fingerprint: 543F EB89 7FDE 8E33 AFF7 E794 E4AB 4807 58F7 6C76
Re: [NEW] sysutils/wdfs-fuse
Here you are a port served as an attachment. On Wed, May 18, 2022 at 12:49:51AM +0100, Stuart Henderson wrote: > please send ports as attachments to the list > -- OpenPGP Key Fingerprint: 543F EB89 7FDE 8E33 AFF7 E794 E4AB 4807 58F7 6C76 wdfs-fuse.tar.gz Description: application/tar-gz
Re: Fluxbox Segfault upon X termination
On Wed, Oct 20, 2021 at 03:32:36PM +0200, Matthieu Herrb wrote:
> On Wed, Oct 20, 2021 at 03:04:14PM +0200, Björn Ketelaars wrote:
> > +@@ -95,7 +95,7 @@ void handleSignal(int signum) {
> > + break;
> > + #endif
> > + case SIGSEGV:
> > +-abort();
> > ++exit(0);
> > + break;
> > + case SIGALRM:
> > + // last resort for shutting down fluxbox. the alarm() is set in
>
> Hi,
>
> This just hides the issue under the carpet...
>
> The real issue is that there is no X I/O errror handler
> installed other than the default one, and the default one seems to
> segfault (SIGSEGV) for a reason (looks like a shared libs destructor
> issue at 1st glance, but I don't care enough to look deeper for now).
>
> See XSetIOErrorHandler(3) for details.
>
> --
> Matthieu Herrb
Actually, XSetIOErrorHandler and XSetErrorHandler are set in fluxbox.cc.
They call handleXIOErrors and handleXErrors respectively.
int handleXIOErrors(Display* d) {
cerr << "Fluxbox: XIOError: lost connection to display.\n";
exit(1);
}
--
OpenPGP Key Fingerprint:
543F EB89 7FDE 8E33 AFF7 E794 E4AB 4807 58F7 6C76
Re: Fluxbox Segfault upon X termination
On Wed, Oct 20, 2021 at 01:34:20PM +0200, Solene Rapenne wrote: > > this seems a fluxbox bug which is not OpenBSD specific, you should > rather report it on fluxbox bug tracker if any. I can't reproduce it on Linux. On the other hand I have not seen anything in the code that was OpenBSD specific in this regard so I am a bit confused. I don't think Fluxbox has a formal bug tracker. I might dust off my rusty gdb skills and see what is going on, but really, I should be considered a last resort :-) -- OpenPGP Key Fingerprint: 543F EB89 7FDE 8E33 AFF7 E794 E4AB 4807 58F7 6C76
Fluxbox Segfault upon X termination
Hi there, This is a bug report against x11/fluxbox I have noticed that fluxbox has a tendency to segfault and dump a core in my $HOME when the X server is manually turned off. If you use xenodm to launch fluxbox and then turn it off (eihter by issuing # rcctl stop xenodm or by hitting Ctrl + Alt + Backspace) then fluxbox receives a termination signal and segfaults. I am not a code guru, but a quick look at the fluxbox code shows fluxbox calls a shutdown function upon receiving typical signals. I have reproduced this bug on multiple installs (7.0 amd64). It is not critical by any means (the program crashes on exit) but it is ugly as heck. Anybody wants to take this bug? -- OpenPGP Key Fingerprint: 543F EB89 7FDE 8E33 AFF7 E794 E4AB 4807 58F7 6C76
[cvsweb] Patch
Hello,
the current version of cvsweb has a stupid bug that prevents diffing a
file using tags only.
How to Reproduce:
Head to a file URL such as
https://cvsweb.bsd.lv/cvsweb/HISTORY
In the diff form, select "Diff between and ",
then hit Get Diffs.
Result: "Invalid character ":" in the value "" of the query parameter "r1"
Expected Result: A valid diff should be displayed.
KNOWN FIX:
In file "cvsweb" (the one installed under /var/www/cgi-bin/cvsweb)
replace line 322.
--- /tmp/original Fri May 21 06:54:20 2021
+++ cvsweb Thu May 20 12:07:21 2021
@@ -319,7 +319,7 @@
'Invalid character "%s" in query parameter "%s"',
$1, $key);
if (defined $value) {
- $value =~ /([^a-zA-Z_01-9.\/-])/ and fatal(
+ $value =~ /([^a-zA-Z_01-9.\/\:-])/ and fatal(
'404 Not Found', 'Invalid character "%s"' .
'in the value "%s" of the query parameter "%s"',
$1, $value, $key);
--
OpenPGP Key Fingerprint:
543F EB89 7FDE 8E33 AFF7 E794 E4AB 4807 58F7 6C76
Re: [NEW] net/i2pd
I forgot to attach the actual port in my last message, here it is. On Thu, Dec 28, 2017 at 02:47:34PM +0100, Rubén Llorente wrote: > Here is an updated version of the i2pd port. > > * Version bumped to 2.17.0 > * Some old family and reseed certificates removed. > * DISTFILE/WORKDIST/GH_* workarounds have been fixed. > * Added README with comments regarding openfile limits. > * Added a NO_TEST = Yes line. > * Moved devel/boost to LIB_DEPEND only > * Moved everything in post-install into do-install > > Have fun testing the hell out of this. > > -- > OpenPGP Key Fingerprint: > BB5A C2A2 2CAD ACB7 D50D C081 1DB9 6FC4 5AB7 92FA -- OpenPGP Key Fingerprint: BB5A C2A2 2CAD ACB7 D50D C081 1DB9 6FC4 5AB7 92FA i2pd.tar.gz Description: application/tar-gz
Re: [NEW] net/i2pd
Here is an updated version of the i2pd port. * Version bumped to 2.17.0 * Some old family and reseed certificates removed. * DISTFILE/WORKDIST/GH_* workarounds have been fixed. * Added README with comments regarding openfile limits. * Added a NO_TEST = Yes line. * Moved devel/boost to LIB_DEPEND only * Moved everything in post-install into do-install Have fun testing the hell out of this. -- OpenPGP Key Fingerprint: BB5A C2A2 2CAD ACB7 D50D C081 1DB9 6FC4 5AB7 92FA
[NEW] net/i2pd
Here is a port I have been using locally. It is a non Java
implementation of the i2p protocol. Maybe it will be useful for other
OpenBSDers, so here you go.
Some comments and clarifications:
* Upstream's makefiles lack an "install" target. This is intended
because upstream wants packagers to copy over their files manually.
* i2pd gets installed as a poorman's system service with all its
configuration on /var/i2pd. This folder gets pre-populated with config
files provided by upstream. Trying to run the software without
configuration files may cause it to run in a potentially insecure
manner.
* Upstream's config scripts are a bit messy and passing configuration
parameters for the building process when using Clang is not possible.
Since the defaults are sane enough, I think it is ok to let the port as
it is.
Testing and destructive criticism ("get your hands off the keyboard
before you get hurt, kid") are welcome.
--
OpenPGP Key Fingerprint:
BB5A C2A2 2CAD ACB7 D50D C081 1DB9 6FC4 5AB7 92FA
i2pd.tar
Description: Unix tar archive
