Re: Using git mirror instead of CVS for working with ports?
On 2024-01-31 00:20, Stuart Henderson wrote: On 2024/01/30 22:58, Johannes Thyssen Tishman wrote: Subject says it all. I'm wondering if using the git conversion of the ports tree[0] is regarded as a good alternative to CVS for working with ports. Are the conversion updates frequent enough to not cause any issues? Do any of you porters use it instead of CVS? Any issues? For the record, I've been using CVS just fine without any problems. I just feel more comfortable with git. [0] https://github.com/openbsd/ports -- Johannes Thyssen Tishman https://www.thyssentishman.com They are fairly frequent (currently run hourly, though this may change if they start taking too long to run), but don't include the most recent commit (CVS commits are not atomic, and the conversion tool is looking for a different commit before it will treat the previous one as done) so at certain times (especially during tree locks for release) you can be waiting a while for a commit to show up. Also there are no tools which successfully managed to convert branches and tags in the OpenBSD CVS repo (we tried everything we could find at the time when it was set up, everything which handles them had some problem or other, and the range of software has not really expanded since) - so the git conversion is limited to dealing with -current only and there's no way to work with -stable or releases. I have been manually tagging and branching the stable branches for a couple of years, as a basis to my personal fork of src, xenocara and ports. And then I have some scripts trying to carry over the commits made to the stable branches, but they are not perfect. I guess I could push the tags and branches to my github, currently they are in a private gitlab only. I won't commit to support these branches though, but if someone would make use of them, in the state they are, I will push them. /Niklas
fix for smtp-vilter link stage on clang archs
Clang does not have -export-dynamic. Instead dlopen(3) teaches us to use
the -rdynamic option to cc(1).
The attached patch is needed for smtp-vilter to be able to dlopen(3) the
clamd and spamd backends on clang archs too.
/Niklas
diff --git a/mail/smtp-vilter/patches/patch-bin_smtp-vilter_Makefile
b/mail/smtp-vilter/patches/patch-bin_smtp-vilter_Makefile
index 7d6d6147b7c..30dab7adb89 100644
--- a/mail/smtp-vilter/patches/patch-bin_smtp-vilter_Makefile
+++ b/mail/smtp-vilter/patches/patch-bin_smtp-vilter_Makefile
@@ -1,7 +1,13 @@
Index: bin/smtp-vilter/Makefile
--- bin/smtp-vilter/Makefile.orig
+++ bin/smtp-vilter/Makefile
-@@ -12,7 +12,7 @@ YFLAGS= -d -p vilter
+@@ -7,12 +7,12 @@ SRCS=smtp-vilter.c engine.c imsg.c buffer.c
pftable.
+ CFLAGS+= -pthread -Wall -I{.CURDIR} -I${.CURDIR}/../../include \
+ -I/usr/src/gnu/usr.sbin/sendmail/include
+
+-LDADD+= -export-dynamic -lmilter -lpthread -L/usr/local/lib -lm
++LDADD+= -rdynamic -lmilter -lpthread -L/usr/local/lib -lm
+ YFLAGS= -d -p vilter
LFLAGS= -Pvilter -olex.yy.c
LINTFLAGS+= -u
Re: Monero port?
Hmm, I have it running, for a while, just to maintain my wallet. Didn't care about mining. Only thing I remember tweaking was some OpenSSL -> LibreSSL stuff, which I put on GitHub. Maybe it's fixed upstream in some other way now. https://github.com/niklasha/monero I have not looked at it for many months, I see it is 160 commits behind :-) Anyways, do with it what you please... On 2022-01-09 00:07, fo...@dnmx.org wrote: Hello there. I am new to OpenBSD so sorry for not doing this myself, I got a mountain to learn. Can I ask someone why hasn't anyone ported monero dameon and the monero wallet client (CLI or GUI)? Does it even need porting? The list says that the CLI wallet supports FreeBSD. I am sorry that I ask for things instead of trying out things myself first, but this is only because of security. I cannot trust myself to make a good security audit of the situation, let alone the code, at least not yet. You might wonder why is this important. It's important if you value anonymity, privacy and decentralization. Yes, it is a cryptocurrency, but if I were to be mining it again, I'd mine it, like I was before, for privacy, anonymity and independence, and not for profit. Also when we're at it, one of decent miners is xmrig https://getmonero.org/ https://github.com/xmrig/xmrig Please, best regards, fossy
nmap segfault fix
Hi!
While testing 7.0 packages I got an nmap segfault. It has been fixed
upstream in their github, but I don't know if it's part of any release yet.
However their fix may be incomplete as there are other opportunities for
a negative buffer overflow in nmap_dns.cc, at least without knowing all
callers of the ptrToIp method.
I attach a patch that works for me (tm) as well as a patch to add a
debug package for nmap, which was needed for me to debug this issue.
Even if its too late for 7.0, at least the segfault fix might make
7.0-stable package, I reckon.
The fault is indeterministic, and triggered by a PTR name being aligned
at the beginning of a page immediately preceded by an unmapped page.
The case which triggers it fairly often for me was just a nmap of a
single TCP port over some seven or so /24-networks.
/Niklas
commit 550c8a099e5eb1189e26f8868927c7b5cba950f2
Author: niklas
Date: Tue Sep 28 14:49:55 2021 +0200
Avoid careless dereferences outside the domain name buffer
diff --git a/net/nmap/patches/patch-nmap_dns_cc b/net/nmap/patches/patch-nmap_dns_cc
new file mode 100644
index 000..45e74a3e735
--- /dev/null
+++ b/net/nmap/patches/patch-nmap_dns_cc
@@ -0,0 +1,42 @@
+$OpenBSD$
+
+Avoid careless dereferences outside the domain name buffer.
+
+Index: nmap_dns.cc
+--- nmap_dns.cc.orig
nmap_dns.cc
+@@ -1352,7 +1352,7 @@ bool DNS::Factory::ptrToIp(const std::string , soc
+ memset(, 0, sizeof(sockaddr_storage));
+
+ // Check whether the name ends with the IPv4 PTR domain
+- if (NULL != (p = strcasestr(cptr + ptr.length() + 1 - sizeof(C_IPV4_PTR_DOMAIN), C_IPV4_PTR_DOMAIN)))
++ if (ptr.length() >= sizeof(C_IPV4_PTR_DOMAIN) - 1 && NULL != (p = strcasestr(cptr + ptr.length() + 1 - sizeof(C_IPV4_PTR_DOMAIN), C_IPV4_PTR_DOMAIN)))
+ {
+ struct sockaddr_in *ip4 = (struct sockaddr_in *)
+ u8 place_value[] = {1, 10, 100};
+@@ -1361,7 +1361,7 @@ bool DNS::Factory::ptrToIp(const std::string , soc
+ size_t i = 0;
+
+ p--;
+-while (i < sizeof(ip4->sin_addr.s_addr))
++while (p >= cptr && i < sizeof(ip4->sin_addr.s_addr))
+ {
+ if (*p == '.')
+ {
+@@ -1387,14 +1387,14 @@ bool DNS::Factory::ptrToIp(const std::string , soc
+ ip.ss_family = AF_INET;
+ }
+ // If not, check IPv6
+- else if (NULL != (p = strcasestr(cptr + ptr.length() + 1 - sizeof(C_IPV6_PTR_DOMAIN), C_IPV6_PTR_DOMAIN)))
++ else if (ptr.length() >= sizeof(C_IPV6_PTR_DOMAIN) - 1 && NULL != (p = strcasestr(cptr + ptr.length() + 1 - sizeof(C_IPV6_PTR_DOMAIN), C_IPV6_PTR_DOMAIN)))
+ {
+ struct sockaddr_in6 *ip6 = (struct sockaddr_in6 *)
+ u8 alt = 0;
+ size_t i=0;
+
+ p--;
+-while (i < sizeof(ip6->sin6_addr.s6_addr))
++while (p >= cptr && i < sizeof(ip6->sin6_addr.s6_addr))
+ {
+ if (*p == '.')
+ {
commit f2aafb4430c0150d70926e3277d0d816805111cb
Author: niklas
Date: Tue Sep 28 14:49:06 2021 +0200
Make debug packages
diff --git a/net/nmap/Makefile b/net/nmap/Makefile
index ff8db3d7594..c1752ffef46 100644
--- a/net/nmap/Makefile
+++ b/net/nmap/Makefile
@@ -33,6 +33,7 @@ MODULES= lang/python \
lang/lua
MODPY_VERSION= ${MODPY_DEFAULT_VERSION_2}
+DEBUG_PACKAGES= ${BUILD_PACKAGES}
CONFIGURE_STYLE=autoconf
AUTOCONF_VERSION=2.69
Re: update: lang/rust
Yes, I sort of agree, but personally I will run with this meanwhile. I now recall what it was that made me do this: wasm. The wasm-pack system requires the version of rustc to match with the wasm32-unknown-unknown target, and I thought it better (read: easier :-) )to use the published target instead of bootstrapping it myself. Esp. if the only reason is to get matching version strings. As the tarball version is containing the githash+date information I thought this was the easiest way. Call me lazy :-) I still had to build rust myself since I wanted 1.39 for other reasons. I won't push for the offical port of yours to contain this, I just wanted to contribute an idea. Do with it what you like. Maybe I will open a ticket with rustc for the tarball to contain the version, it makes sense I think. /Niklas On 2019-12-12 09:15, Sebastien Marie wrote: On Thu, Dec 12, 2019 at 07:52:21AM +0100, Niklas Hallqvist wrote: As a matter of fact I did the same update just a week ago, and ended up in exactly the same patch set as you, except for one thing: The version reported by 'rust -V' normally include the git hash and date, and some rust code out there depends on it (maybe dumb, but nevertheless it is). it is currently expected for build from a tarball. git information is only included when build from a git directory. so I am expecting that any rust installed from distribution to share the same output. (but when installed from rustup, it comes from a build from mozilla which is done using git) if some rust crate depends on it, you should open a bug report. it could be interesting to also open a bug report on rustc itself in order to include the information for tarball too (the tarball contains at least the commit-hash information). Thanks.
Re: update: lang/rust
As a matter of fact I did the same update just a week ago, and ended up in
exactly the same patch set as you, except for one thing:
The version reported by 'rust -V' normally include the git hash and date, and
some rust code out there depends on it (maybe dumb, but nevertheless it is).
I did it by adding to the diff-file for src/bootstrap/lib.rs, but it can
conceivably instead be a post-patch target patching lib.rs with the contents of
'git-commit-hash', a file found in the build directory.
/Niklas
diff --git a/lang/rust/patches/patch-src_bootstrap_lib_rs b/lang/rust/patches/p\
atch-src_bootstrap_lib_rs
index 4ae91048f80..5c8543e5e18 100644
--- a/lang/rust/patches/patch-src_bootstrap_lib_rs
+++ b/lang/rust/patches/patch-src_bootstrap_lib_rs
@@ -12,3 +12,12 @@ Index: src/bootstrap/lib.rs
.collect::>();
// If we're compiling on macOS then we add a few unconditional flags
+@@ -1048,7 +1047,7 @@ impl Build {
+ /// Note that this is a descriptive string which includes the commit date\
,
+ /// sha, version, etc.
+ fn rust_version() -> String {
+-self.rust_info.version(self, channel::CFG_RELEASE_NUM)
++String::from("1.39.0 (4560ea788 2019-11-04)")
+ }
+
+ /// Returns the full commit hash.
> On 8 Dec 2019, at 12:30, Sebastien Marie wrote:
>
> Hi,
>
> Here the diff for updating lang/rust to 1.39.0
>
> The patch took more time than expected to be done: I had problem with sparc64
> and I only achieved to have a workaround in order to avoid a SEGFAULT during
> the
> build. I am suspecting some LLVM bug in sparc64, as the workaround is to build
> some part of rust with -O3 (else the generated code will SEGFAULT). I didn't
> really investigated at asm level.
>
> The port was tested some times ago on amd64 (and build tested and all archs).
>
> I intent to commit it in few days. But comments or OK are welcome :)
>
> Thanks.
> --
> Sebastien Marie
>
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/lang/rust/Makefile,v
> retrieving revision 1.102
> diff -u -p -r1.102 Makefile
> --- Makefile 29 Sep 2019 08:23:17 - 1.102
> +++ Makefile 8 Dec 2019 10:55:23 -
> @@ -13,17 +13,17 @@ COMMENT-gdb = Rust debugger through gdb
> COMMENT-clippy = Rust linter
> COMMENT-rustfmt = Rust code formatter
>
> -V = 1.38.0
> -CARGO_V =0.39.0
> +V = 1.39.0
> +CARGO_V =0.40.0
> CLIPPY_V =0.0.212
> -RUSTFMT_V = 1.4.4
> +RUSTFMT_V = 1.4.8
> DISTNAME =rustc-${V}-src
>
> # rustc bootstrap version
> -BV-aarch64 = 1.38.0-20190926
> -BV-amd64 = 1.38.0-20190924
> -BV-i386 =1.38.0-20190924
> -BV-sparc64 = 1.37.0-20190813
> +BV-aarch64 = 1.39.0-20191124
> +BV-amd64 = 1.39.0-20191122
> +BV-i386 =1.39.0-20191123
> +BV-sparc64 = 1.39.0-20191207
> BV = ${BV-${MACHINE_ARCH}}
>
> PKGNAME = rust-${V}
> @@ -138,7 +138,7 @@ SUBST_VARS += WRKBUILD
> post-patch:
> sed -i 's/"files":{[^}]*}/"files":{}/' \
> ${WRKSRC}/vendor/*/.cargo-checksum.json
> - ${SUBST_CMD} ${WRKSRC}/src/tools/cargo/tests/testsuite/support/paths.rs
> + ${SUBST_CMD}
> ${WRKSRC}/src/tools/cargo/crates/cargo-test-support/src/paths.rs
>
> # - check datasize limit before configuring (and building)
> pre-configure:
> Index: distinfo
> ===
> RCS file: /cvs/ports/lang/rust/distinfo,v
> retrieving revision 1.58
> diff -u -p -r1.58 distinfo
> --- distinfo 29 Sep 2019 08:23:17 - 1.58
> +++ distinfo 8 Dec 2019 10:55:23 -
> @@ -1,10 +1,10 @@
> -SHA256 (rust/rustc-1.38.0-src.tar.xz) =
> OnmRqky0TvlB1xY25FqVRotSDcb8fPclNkklvT49OjQ=
> -SHA256 (rust/rustc-bootstrap-aarch64-1.38.0-20190926.tar.xz) =
> K6z7+X02Zw6kzFdt93JoOhVFJmVI1tp2kcV3Ep07i1k=
> -SHA256 (rust/rustc-bootstrap-amd64-1.38.0-20190924.tar.xz) =
> s7m04Xk4Rukj3of8sLaK2NRiRZoAEEaxeQ14zE7/42U=
> -SHA256 (rust/rustc-bootstrap-i386-1.38.0-20190924.tar.xz) =
> p7GH8ebq4uh5OUGIK3qbmRoWnotASu9Z6K/nMOLX2Ck=
> -SHA256 (rust/rustc-bootstrap-sparc64-1.37.0-20190813.tar.xz) =
> Mja3fEVQ6pD9cxq0ZfEX+O6QW+cVLpA9n5k67M6u0gU=
> -SIZE (rust/rustc-1.38.0-src.tar.xz) = 96163304
> -SIZE (rust/rustc-bootstrap-aarch64-1.38.0-20190926.tar.xz) = 179869984
> -SIZE (rust/rustc-bootstrap-amd64-1.38.0-20190924.tar.xz) = 195854424
> -SIZE (rust/rustc-bootstrap-i386-1.38.0-20190924.tar.xz) = 193885292
> -SIZE (rust/rustc-bootstrap-sparc64-1.37.0-20190813.tar.xz) = 77696860
> +SHA256 (rust/rustc-1.39.0-src.tar.xz) =
> Sw27NWBwaHpgYDT3HcAyt4O7+LXT+f/znywfvE8XHCk=
> +SHA256 (rust/rustc-bootstrap-aarch64-1.39.0-20191124.tar.xz) =
> d+u86EWh5RRFuzf3NbOkHPV+jT5ySxEkqnOgQgU+w1g=
> +SHA256 (rust/rustc-bootstrap-amd64-1.39.0-20191122.tar.xz) =
>
Re: Problems with java
ICMan wrote: Hello, I just compiled (after a whole day) the jdk 1.5.0p19 distribution on OBSD 4.0, and I get the following error whenever I run java or attempt to use the plugin with firefox: Error occurred during initialization of VM Could not reserve enough space for object heap Could not create the Java virtual machine. I have tried ulimit -d 10, I have tried java -Xms10M -Xmx10M, java -Xms100M -Xmx100M, and even java -Xms1M -Xmx1M. None work. I continue to get the same error. Need help badly. Thanks ICMan. Although I always run with a gig in ulimit (that's 10x what you have tried), I tried a lowering my ulimit to just 100M and start a big applet in firefox, it worked ok. I have never had to use VM args for the plugin... How much free memory do you have according to top(1)? How big is your swap? Do all applets exhibit this error? Niklas
Re: Two suggestions for the Ion port
I've wanted the nesting at occasions, the status bar I don't care much
about.
So ok from this user...
Pedro Martelletto wrote:
Hi,
I'd like to suggest that two changes be made in the Ion port.
- Don't load the status bar by default.
- Add and load the workspace nesting code by default. Permits you to do
this: http://ambientworks.net/~pedro/floating-over-tiled.png
Both modifications are based on the particular use I make of this window
manager, so I'd like to know if other people would be okay with them.
Please reply to me privately.
-p.
Index: Makefile
===
RCS file: /cvs/ports/x11/ion/Makefile,v
retrieving revision 1.24
diff -u -r1.24 Makefile
--- Makefile7 Sep 2005 19:53:41 - 1.24
+++ Makefile29 Sep 2005 04:05:15 -
@@ -3,6 +3,7 @@
COMMENT=light, keyboard friendly window manager
DISTNAME= ion-3ds-20050820
+PKGNAME= ${DISTNAME}p0
CATEGORIES= x11
HOMEPAGE= http://modeemi.cs.tut.fi/~tuomov/ion/
@@ -22,6 +23,9 @@
NO_REGRESS= Yes
LIB_DEPENDS=lua.5,lualib.5::lang/lua
+
+post-install:
+ $(INSTALL_DATA) ${FILESDIR}/*.lua ${PREFIX}/share/examples/ion3
.include bsd.port.mk
Index: files/detach.lua
===
RCS file: files/detach.lua
diff -N files/detach.lua
--- /dev/null 1 Jan 1970 00:00:00 -
+++ files/detach.lua29 Sep 2005 04:05:15 -
@@ -0,0 +1,407 @@
+-- $OpenBSD$
+-- Fancy management of transcient windows in ion. Mix WIonWS and
+-- WFloatWS on the same workspace.
+
+-- Written by Matthieu Moy [EMAIL PROTECTED] on February 17th 2005.
+-- Public domain.
+
+if not detach then
+ detach = {
+ -- default passiveness for the layer 2 floating workspace.
+ passive = true,
+ -- Whether transcient windows should automatically be made floating
+ manage_transcient_with_float = true,
+ }
+end
+
+-- Introduction:
+
+-- This extension exploits some of ion3's new features: It is now
+-- possible to attach objects on a second layer on the screen, which
+-- allows you to have, for example, floating objects on top of a
+-- traditional WIonWS workspace. See
+-- http://www-verimag.imag.fr/~moy/ion/ion3/float-split.png if you
+-- prefer images to explanations :-)
+
+-- A simple setup is to put the following in your cfg_user.lua:
+-- dopath(detach.lua)
+-- detach.setup_hooks()
+
+-- The layer 2 objects can be either passive or non passive. A passive
+-- object will only take the focus when the mouse is over it, while a
+-- non passive object will allways have the focus when shown. (The
+-- scratchpad is an example of non passive object).
+
+-- Layer 2 objects can be hidden. This way, a non passive object can
+-- let the focus to the layer 1.
+
+-- This script attaches two WFloatWS on the layer 2. One is passive,
+-- the other not. The function detach.topmost_transient_to_float sends
+-- a window (or the topmost transcient if the window has transcient)
+-- to one of them (depending on the value of the 3rd parameter).
+
+-- The function detach.toggle_floatws shows or hide the current layer
+-- 2 floating workspace. This is very usefull to get rid of the non
+-- passive WFloatWS, when it is active and you want to give the focus
+-- to a layer 1 object.
+
+
+
+-- User functions --
+
+
+
+-- Call this function once and all transcient windows will be managed
+-- as floating frame in layer 2. Additionally, you may define the
+-- float winprop for other non transcient windows to manage as
+-- floating frames like this
+--
+-- defwinprop {
+--class = Xawtv,
+--float = true,
+-- }
+--
+-- the winprop float_passive, if specified, overrides the
+-- detach.passive setting. For example,
+--
+-- defwinprop {
+--class = Gkrellm,
+--float = true,
+--float_passive = true
+-- }
+--
+-- will make gkrellm start in a passive floating window. (this means
+-- the window will not accept focus)
+--
+-- Note: Adding all the functions to hooks here may conflict with
+-- other functions you could have added to the same hook somewhere
+-- else. If you want to add your personal functions to
+-- clientwin_do_manage_alt, I suggest not adding detach.manager, but
+-- doing something like
+--
+--if detach.manager(cwin, table) then
+-- return true
+--end
+--
+-- at the beginning of function you'll use in clientwin_do_manage_alt.
+function detach.setup_hooks ()
+ ioncore.get_hook(clientwin_do_manage_alt):add(detach.manager)
+
ioncore.get_hook(frame_managed_changed_hook):add(detach.maybe_leave_layer2)
+ ioncore.get_hook(region_do_warp_alt):add(detach.skip_l2_warp)
+end
+
+
+-- Submenu to add to the WFrame menu:
+-- Add the line
+-- submenu(Attach, menudetach),
+-- to the definition defctxmenu(WFrame, { ... })
+defmenu(menudetach, {
+ menuentry(Topmost transient,
+ detach.topmost_transient_to_reg(_sub)),
+
