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.
that have the same getopt-based parser as the native tool, so the
syntax remains the same, eg.
Code:
# iptables-compat -P INPUT DROP
# iptables-compat -A INPUT -m state --state ESTABLISHED,RELATED
# iptables-compat -A INPUT -m state --state NEW -p tcp --dport 22 -j ACCEPT
# iptables-compat -A INPUT -m state --state INVALID -j LOG --log-prefix "INVALID: "
First of all, *thanks* for putting download links with your requests - that's a real timesaver for us.
All of these are either in my queue or in Pat's tree now - except for rpm. I used to try to keep rpm relatively recent, but it became a real booger (for reasons I don't recall now) at some point. It might be a simple bump, but it might not be, and I don't want to crawl down into that rabbithole only to find that it's not simple at all. Have you tried this one to have some idea one way or the other?
I tested rpm here, just for fun. No changes needed to the build. The `query` and `verify` commands worked just fine:
Code:
root@/tmp/package-rpm/bin:# ./rpm --verify /home/ry/Downloads/atom.x86_64.rpm
warning: Generating 12 missing index(es), please wait...
package /home/ry/Downloads/atom.x86_64.rpm is not installed
root@/tmp/package-rpm/bin:# ./rpm --query /home/ry/Downloads/atom.x86_64.rpm
package /home/ry/Downloads/atom.x86_64.rpm is not installed
Strangely `--version` still says 4.10, had to double-check the tarball on that one, but I think it is an upstream mistake:
Code:
root@/tmp/package-rpm/bin:# ./rpm --version
RPM version 4.10.0
Hope that helps! Anyways, I'm pretty happy with where -current is at now, thanks to Robby, Pat and everyone else for providing a top-notch OS.
...except for rpm. I used to try to keep rpm relatively recent, but it became a real booger (for reasons I don't recall now) at some point. It might be a simple bump, but it might not be, and I don't want to crawl down into that rabbithole only to find that it's not simple at all. Have you tried this one to have some idea one way or the other?
Before my request for an upgrade, I had installed rpm-4.10.3 and rpm-4.12.0.1.
same SlackBuild as the one in current at the moment.
the command rpm2cpio *rpm | cpio -ivm was working.
rpm --showrc displayed the usual unix tools(*) at the right place for Slackware, even the man directory If my memory doesn't fail me. optflags add to be adjusted (in the HOME directory) since we use "-O2 -fPIC" not "-O2 -g" and I don't want to build with "-mtune=generic" but with "-march=x86-64 -mtune=native".
Few weeks ago I started to use Fedora, learn to and make my own packages on that rpm platform (Mandrake, father of Mandriva, was the last rpm distro I used more than 2 days).
I liked very much the rpm way of building packages and I told to myself why not turning my building scripts into rpms for Slackware?
I haven't make that thought into motion yet, basically I was waiting for the upgrade.
Is there a possibility of including a 4.3 Kernel, maybe in testing? Slackware would have skylake compatibility (i'm getting a skylake laptop next month from work).
I second this request having had unexpected fun with a Skylake based laptop this weekend, not having paid enough attention when putting an order in. The 4.1 kernel needs specific boot-options to enable hardware support for these CPUs, see http://www.phoronix.com/scan.php?pag...prelim-support which is non-obvious to figure out at best. Moreover both with and without that boot-option the 4.1 kernel doesn't work properly, i.e. I see complete system lock-ups, display glitches, not able to switch between GUI/console, etc.
As these CPUs are now actively being sold it is worth including at LTS kernel that can deal with those CPUs, i.e. the 4.4 kernel branch. I have it Slackware current running with the 4.4.0-rc5 kernel on a skylake laptop and seems to work without issues.
I second this request having had unexpected fun with a Skylake based laptop this weekend, not having paid enough attention when putting an order in. The 4.1 kernel needs specific boot-options to enable hardware support for these CPUs, see http://www.phoronix.com/scan.php?pag...prelim-support which is non-obvious to figure out at best. Moreover both with and without that boot-option the 4.1 kernel doesn't work properly, i.e. I see complete system lock-ups, display glitches, not able to switch between GUI/console, etc.
As these CPUs are now actively being sold it is worth including at LTS kernel that can deal with those CPUs, i.e. the 4.4 kernel branch. I have it Slackware current running with the 4.4.0-rc5 kernel on a skylake laptop and seems to work without issues.
Are you absolutely sure the lock ups are not being caused by nouveau? There is a known bug with nouveau, so I always boot with 'nouveau.modeset=0' on 4.1.x kernels.
Are you absolutely sure the lock ups are not being caused by nouveau? There is a known bug with nouveau, so I always boot with 'nouveau.modeset=0' on 4.1.x kernels.
The OpenVPN developers recently released version 2.3.9; -current has 2.3.6. I've been using my own 2.3.8 package on a production VPN server for some time with no problems, and I imagine 2.3.9 will be fine too.
Some little tests around kernels 4.3.x & 4.4.x , for me , are bogus.
I see error messages in this kernel lines around ata , ending in to NCQ disabled for too many errors.
If some one have a 4.4 or 4.3 , pay attention to dmesg.
Some little tests around kernels 4.3.x & 4.4.x , for me , are bogus.
I see error messages in this kernel lines around ata , ending in to NCQ disabled for too many errors.
If some one have a 4.4 or 4.3 , pay attention to dmesg.
dmesg|grep -i error
I have seen no errors so far on my normal PC which is running 4.3.3. But i understand 4.3 / 4.4 Kernel might not be for everyone, so maybe put it in testing or extra?
As these CPUs are now actively being sold it is worth including at LTS kernel that can deal with those CPUs, i.e. the 4.4 kernel branch. I have it Slackware current running with the 4.4.0-rc5 kernel on a skylake laptop and seems to work without issues.
I running too a skylake cpu the i7-6700K and my problem is the Intel HD graphics 530 see: http://www.phoronix.com/scan.php?pag...prelim-support
Also Mesa driver is exposing OpenGL 3.3 support while OpenGL 4.3 is what's supported by the hardware.
I am now in 4.3.X branch with Intel firmware built in and seems to working fine.
Last edited by Panagiotis Nik; 12-22-2015 at 04:47 AM.
We could introduce the libinput driver(s) into the mix
This just recently made it into Fedora. While it's only fair to point out that libinput seemed to be a completely seamless transition for two machines here in front of me, we'll let Fedora do the testing on libinput support and work out the kinks.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.