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.
When using other distros rebooting and powering down is fast. Very fast. I am well aware the other distros use systemd, but the pauses are annoying when compared to other distros.
Fast boot/shutdown is not exclusive to systemd distributions (see Void Linux for example, which uses runit).
/usr/share/kde4/services/ScreenSavers/electricsheep.desktop from electricsheep.SlackBuild needs to be moved elsewhere(i'm no kde/plasma user, don't know where or if useful on plasma at all).
And, as poppler was updated, texlive might be recompiled with "SYSTEMPOPPLER=${SYSTEMPOPPLER:-YES}"
Hey, Pat, I'd be pleased if you are interested in an stock global way to manage pausing during reboots and shutdowns. The idea was a request only. If not then c'est la vie.
I really thought I replied to this already, but checking my mails I see I obviously did not
Sorry about that! I'll send a reply to the mail there, but for folks reading here:
I don't think it's the SlackBuild's job to do this. I understand why you'd want this, and I appreciate the effort that went into the patch, but that's more or less turning the SlackBuild into a build system for ffmpeg.
The effort would be better served patching ffmpeg's configure to do this instead and try to get it upstream. If they reject it, based on the reasoning given, we can decide how to proceed on our side.
Unfortunately, it looks like ffmpeg developers have no intention on supporting autodetection and mean to require explicit enabling of options via the commandline. The following is in their latest configure script:
Code:
Note that only the system libraries are auto-detected. All the other external
libraries must be explicitly enabled.
As I am not familiar enough with configure scripts, I'll be unable to provide any patches beyond the SlackBuild itself. It's a shame the developers require so much work on the users to build their product with all the options.
I know we try and follow upstream's wishes, but there are exceptions when Slackware has gone against upstream when they do stupid unexpected things. I'm sure some ffmpeg developer has a strong reason on why it makes sense to not allow autodetection, but since it allows explicitly disabling autodetected system libraries (and could easily be added for everything else), I just don't understand why they are stuck in their ways.
I was really hoping to take some of the burden off Slackware users by allowing us to easily compile ffmpeg once additional libraries have been installed to the core system. As it stands, it's an extreme pain to build ffmpeg, whether by hand or using a build tool. If you're not willing to incorporate detection into the SlackBuild, then hopefully someone with knowledge of configure scripts can implement the changes and we can apply a patch with the SlackBuild to enable autodetection.
Attached are SlackBuild, slack-desc and doinst.sh.
Be merciful. These are ugly hacks and adapted from someone else's SlackBuilds.
Quote:
Is it published to SBo?
Nope, I always used -current and you need to run 14.2 for SBo. Moreover, 14.2 uses KDE4 and this tool requires Plasma 5 so it did not have any possibility of getting into SBo.
THis is part of a series of SlackBuilds I made for running ksnip, another screenshot tool made after Windows' snipping tool.
Besides this one, there's also kColorPicker (another dependency) and ksnip proper, in case you would like them.
To use the files remove the 'txt' extension. This was necessary in order to attach them here.
If it hasn't been suggested already, how about FIDO2/U2F support in OpenSSH ?
This looks like it requires cbor (which is already in SBo) and libfido2 (which isn't yet). libfido2 1.4.0 builds cleanly on x08_64 but there are some signed/unsigned
Hi - I noticed that the efivar upgrade hadn't happened possibly because the new build was failing under GCC 9.3.0. However, it now works again under GCC 10.x.
So if someone could run the included fetch-efivar.sh script and rebuild, it would be great. Fixes the eMMC ELILO installation problem.
The version in -current at the moment is 2.0.11_fad08f383 which dates from July 19, 2019. The 2.x series is nearing EOL - from https://linuxcontainers.org/lxc/introduction/, I see:
Code:
LXC 2.0 and 3.0 are long term support releases: - LXC 2.0 will be supported until June 1st 2021 - LXC 3.0 will be supported until June 1st 2023
Attached are SlackBuild, slack-desc and doinst.sh.
Be merciful. These are ugly hacks and adapted from someone else's SlackBuilds.
Thanks for this, @sombragris. Don't worry. Generosity is not meant to be criticized.
Quote:
Originally Posted by sombragris
Nope, I always used -current and you need to run 14.2 for SBo. Moreover, 14.2 uses KDE4 and this tool requires Plasma 5 so it did not have any possibility of getting into SBo.
Have you ever considered to submit then to ponce's SBo? They are for made for -current and could eventually becomes the release thing.
Thanks for this, @sombragris. Don't worry. Generosity is not meant to be criticized.
Have you ever considered to submit then to ponce's SBo? They are for made for -current and could eventually becomes the release thing.
You're very welcome Deny. I think ponce barely has the time to adapt the existing SlackBuilds from 14.2's SBo. That's one of the reasons why the wait for Plasma 5 was so grating; we were unable to contribute (or benefit from contributions) to SlackBuilds.org for Plasma 5.
You're very welcome Deny. I think ponce barely has the time to adapt the existing SlackBuilds from 14.2's SBo. That's one of the reasons why the wait for Plasma 5 was so grating; we were unable to contribute (or benefit from contributions) to SlackBuilds.org for Plasma 5.
This is past now. I think Ponce is doing a great job on -current SBo. The project RSS has been very active lately (compared to pre-Plasma days).
I used flameshot and it's available on SBo, but need to be updated to 0.8.5 to work with Qt5 in -current
I use flameshot too. Great app indeed.
But... given that annotated screenshots are something quite pervasive on many workflows (e.g. education, newsroom, software development, documentation etc), it would be nice to have on a near to be released Slackware version an embed tool to fill that void.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.