Re: Machine learning
I have had a pytorch port (with Vulkan) in the works last year, but there were so many small things to cover so I got tired of it. I did succeed in running some inference on my Radeon cards, but I could never care enough about cleaning it all up for a port, and now I have forgot most of the details :-(. I am still very interested in ML, and do a lot of experiments, but nothing for production use. I too have succeeded with llama.cpp, but do most of my experiments with candle (the Rust pytorch wannabe), which sadly lacks Vulkan, which seems to be the easiest wy to get GPU support on OpenBSD. CPU works great though. Currenty I actually build POCs of using Rust/vulkano for building small neural nets, just to see if I can learn enough of Vulkan, to actually add support for it to candle. However all this is vaporware, and I cannot be trusted to finish any of it. Maybe I can dig out specific bits of someone else is curious, but it will not be in very good shape. This is all stuff I deal with on the little spare time I have. /Niklas On 2024-07-17 17:28, José Maldonado wrote: El mié, 17 jul 2024 a la(s) 7:04 a.m., Frank Baster (frankbas...@protonmail.com) escribió: Is there any interest in machine learning ports for PyTorch / JAX / TensorFlow? I had a quick look at mlpack but couldn't find support for recurrent neural networks. PyTorch looks like the most do-able. This is possible, but the performance is a big issue here. For example, you can build PyTorch using Vulkan Backend (https://pytorch.org/tutorials/prototype/vulkan_workflow.html - in OpenBSD Vulkan support is very good) but Vulkan Backend is slow when you compare with specific AI HW accel options. In my case I use Llama.cpp with Vulkan support enable on AMD RX 580 for curiosity, and work fine is very usable. Give a read for this: Kompute (https://kompute.cc/). This is a general purpose GPU compute framework for AI using Vulkan Kompute.
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 &ptr, soc + memset(&ip, 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 *)&ip; + u8 place_value[] = {1, 10, 100}; +@@ -1361,7 +1361,7 @@ bool DNS::Factory::ptrToIp(const std::string &ptr, 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 &ptr, 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 *)&ip; + 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
Sympa's wwsympa Fails "Can't locate CGI/Fast.pm in @INC"
I have been working on setting up Sympa on OpenBSD. I have OpenSMTPd working with the Sympa daemon, but I'm getting stuck on the wwsympa set up with nginx (I hope to switch to OpenBSD's HTTPd after I get Nginx working). I used the Nginx config provided by the port maintainer: >server { > server_name domain.com; > listen on 0.0.0.0:80; > > location /static-sympa { > alias /var/www/sympa/; > } > > > location / { > fastcgi_pass localhost:1026; > fastcgi_split_path_info ^(/sympa)(.+)$; > include fastcgi_params; > fastcgi_param PATH_INFO $fastcgi_path_info; > fastcgi_param > SCRIPT_FILENAME /usr/local/libexec/sympa/wwsympa-wrapper.fcgi; } >} When I launch all the services, wwsympa crashes out with the following error in /var/log/messages. >wwsympa[40272]: err main::#138 DIED: Can't locate CGI/Fast.pm in @INC >(you may need to install the CGI::Fast module) (@INC >contains: /usr/local/libdata/perl5/site_perl/amd64-openbsd >/usr/local/libdata/perl5/site_perl /usr/libdata/perl5/amd64-openbsd >/usr/libdata/perl5) >at /usr/local/libexec/sympa/wwsympa.fcgi line 139 I will now make this email unbearably long by sharing this dump: >ls /usr/local/libdata/perl5/site_perl/ AppConfigEncode MIME Role iso8859.pl mhsingle.pl AppConfig.pm ErrorMLDBM SQL libwww mhthread.pl Archive Error.pm MLDBM.pm Sort mhamain.pl mhtime.pl BEval MRO StackTrace mhdb.pl mhtxtenrich.pl Bundle Exporter Mail Sub mhdysub.pl mhtxthtml.pl CGI Fh.pmMath Sympamhexternal.plmhtxtplain.pl CGI.pm File MaxMind Sympa.pm mhfile.plmhtxttsv.pl CGI.pod Font Method Term mhidxrc.pl mhusage.pl ClassFreezeThaw.pmModule Test mhindex.pl mhutil.pl CloneGeoIP2 MojoX Throwablemhinit.plnamespace Conf.pm GeoIP2.pmMoo Throwable.pm mhlock.ploo.pm Convert HTML Moo.pm Time mhmimetypes.pl osinit.pl Crypt HTTP MooX Try mhmsgextbody.pl qprint.pl DDP.pm IO Mozilla URI mhmsgfile.pl readmail.pl Data JSON MuninURI.pm mhnote.plspamassassin-run.pod Date LWP Net WWW mhnull.plstrictures DateTime LWP.pm OpenBSD XML mhopt.pl strictures.pm Devel List POD2 amd64-openbsd mhrcfile.pl Digest Locale Package base64.plmhrcvars.pl Dist Log RPC ewhutil.pl mhrmm.pl EmailMHonArc RRDp.pm iso2022jp.pl mhscan.pl Is this a dependency issue, or is there a step that I could be missing? I am not familiar with CGI in general. Thank you all!
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(&self) -> 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
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 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_re