SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
All that is needed for python3 bindings in opencv is for numpy3 to already be installed at build time. None of the cmake options that have been suggested are required for the current SlackBuild; it automatically creates the python bindings provided numpy3 is installed.
chris
Last edited by chris.willing; 01-11-2022 at 12:52 AM.
Any chance of getting nvme(1) added to the installer initrd to allow for provisioning NVMe storage at install time? (After install is kinda pointless as it would nuke your installation ;-) Thanks!
Any chance of getting nvme(1) added to the installer initrd to allow for provisioning NVMe storage at install time? (After install is kinda pointless as it would nuke your installation ;-) Thanks!
I've never needed nvme-cli during installation on any of my devices with NVMe. Under what circumstances would that be required?
I've never needed nvme-cli during installation on any of my devices with NVMe. Under what circumstances would that be required?
In my case, I'm going for overprovisioning[1] to improve performance and longevity. Other uses include multi-tenancy[1] and changing the sector size[2] if the drive supports it (sadly, mine don't or I'd be going for this too).
I've never needed nvme-cli during installation on any of my devices with NVMe. Under what circumstances would that be required?
I haven't had any need for this, but nvme-cli will allow you to create additional namespaces (nvme0n{1,2}) on the same device (not sure on the big benefit with this over a simple partition). It also allows you to securely delete the contents of a namespace without needing to use other utilities. I imagine there's a few other benefits it offers.
That being said, I've never used any of these features. I keep all my partitions within the stock/single namespace and I haven't had a need to securely delete the contents.
So metamail installation overwrites man page of mmencode with the man page of mimencode.
(At installation time metamail installation happens after elm installation).
As a result, "man mimencode" doesn't find any man page, while "man mmencode" shows mimencode man page.
Apparently the mmencode.1.gz filename in metamail should be changed in mimencode.1.gz
The two executables appear to be two different versions/implementations of mail-oriented coding/decoding software.
The issue is in 14.2 (but I believe it has been there for a looooong time ), but also in current.
Ok, the issue is small: these packages are very old and it happens very seldom to be forced to use mimencode on command line ... but sometimes it may happen ;-) (as it did to me, and that's how I realised this)
Instead of configuring vmd as a loadable module, can CONFIG_VMD be set to "Y"?
On this laptop the huge kernel panics on startup, it only works when vmd is compiled in.
Generic kernel works only if you include vmd when running mkinitrd.
- rescue: new subcommand clear-uuid-tree to fix failed mount due to bad uuid subvolume keys, caught by tree-checker
- fi du: skip inaccessible files
- prop: properly resolve to symlink targets
- send, receive: fix crash after parent subvolume lookup errors
build:
- fix build on 5.12+ kernels due to changes in linux/kernel.h
- fix build on musl with old kernel headers
other:
- error handling fixes, cleanups, refactoring
- extent tree v2 preparatory work
- lots of RST documentation updates (last release with asciidoc sources)
The original behaviour is aimed at "Users of non-KDE desktop environments, which use kglobalaccel for shortcuts". To me it seems an extremely niche use-case. XFCE includes its own shortcut daemon, and even non-included in Slackware DEs, which have been mentioned on this forum sometimes, such as i3, and LXQt, do not seem to rely on kglobalaccel. And in case someone uses kglobalaccel... well, why not just run it from the session manager, or xinitrc.
Therefore, I am asking to add the aforementioned patch to Slackware 15, in order to prevent kglobalaccel from overriding the default XFCE shortcut manager, for XFCE users.
The guys have a actually fixed this bug first, only to revert the fix later, in order to "postpone such a change until KDE 6", due to legacy issues. It seems to me that on Slackware this "legacy issues" would not arise.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
), but also in current.
