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.
Question: Does any 'average user' actually need to rotate their logs every day ?
IMO, logrotate should not be in /etc/cron.daily but rather in /etc/cron.weekly
or even in /etc/cron.monthly as it is here on my systems.
To keep my systems working the way I want, the script I use the do upgrades
includes a line to delete /etc/cron.daily/logrotate just in case that package
was upgraded.
Would it be good enough if you changed 'weekly' to 'monthly' or 'yearly' in /etc/logrotate.conf:
Code:
# For more details, see "man logrotate".
# rotate log files weekly:
weekly
Question: Does any 'average user' actually need to rotate their logs every day ?
Probably one of those lovable discussions of 'that depends' -- on the definition of 'average' and what each user needs.
If certain logs do not fill quickly then a conf file in /etc/logrotate.d will change rotations to weekly, monthly, based on size, etc. This is how I manage rotations. I let logrotate run daily but many of my conf files are configured for longer rotation periods and those logs do not get rotated daily.
Daily probably works well for many people. If the computer is not powered on when weekly or monthly cron jobs are scheduled, or as often is the case with many people running laptops and the device is in sleep mode, then without customizing or something like anacron, those cron jobs never launch and logs will never rotate. Running logrotate daily provides a reasonable attempt to rotate logs at least some of the time.
Likely 'average' users do not want the default Slackware cron job times that are based on server usage and run in the early AM when many people are sleeping. Many 'average' users probably do not have their computers powered on at that time. So the 'average' user probably wants to change those default cron job times.
# some packages install log rotation information in this directory:
include /etc/logrotate.d
in /etc/logrotate.conf instead of IMHO not necessary logrotate source code patch or explain the reason(s) for the latter please.
The original reason for the patch was that there was no "tabooext" directive supported in logrotate.conf for many years while we used the patch. The current reason is that the patch still works fine.
While it would seem that this could replace the patch, it could also cause issues for anyone who would upgrade to a newer package without the patch who had files with these extensions and didn't pay proper attention to the logrotate.conf.new file.
Good News , since last release of linux-firmwares , the support for XZ and ZSTD , are included by default , no need extra patches and no need touch the kernel config cause we have enabled "firmware" compress , with support boot xz+zstd.
Example for zstd compressed firmwares...
Quote:
make DESTDIR=$PKG FIRMWAREDIR=/lib/firmware install-zst
Example for xz firmware compression..
Quote:
make DESTDIR=$PKG FIRMWAREDIR=/lib/firmware install-xz
The reduction for final package are good with xz , but personally i testing zstd cause better for low resources machines.
Testing here kernel with zstd modules compression + firmware compression , ...are nice , no impact.
Checking dmesg , all fine...all firmwares loaded and system running smooth.
Quote:
dmesg|grep -i firmware
[ 0.091166] Spectre V2 : Enabling Speculation Barrier for firmware calls
[ 0.240511] ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored
[ 0.248939] acpi PNP0A08:00: [Firmware Info]: MMCONFIG for domain 0000 [bus 00-7f] only partially covers this bridge
[ 1.578837] Bluetooth: hci0: Firmware revision 0.1 build 19 week 44 2021
[ 1.579504] iwlwifi 0000:01:00.0: loaded firmware version 36.ca7b901d.0 8265-36.ucode op_mode iwlmvm
[ 1.679981] [drm] Loading DMUB firmware via PSP: version=0x01010027
[ 1.682994] [drm] Found VCN firmware Version ENC: 1.20 DEC: 5 VEP: 0 Revision: 3
[ 1.683007] amdgpu 0000:03:00.0: amdgpu: Will use PSP to load VCN firmware
Last edited by USUARIONUEVO; 06-28-2023 at 03:45 PM.
Good News , since last release of linux-firmwares , the support for XZ and ZSTD , are included by default , no need extra patches and no need touch the kernel config cause we have enabled "firmware" compress , with support boot xz+zstd.
Thanks for the heads-up. I see that Arch dropped the patch for xz compression two days ago. I will do that also for Slint, comparing the sizes for xz and zstd compression. I also consider splitting the package in several ones as they do to avoid overloading the installer, being too lazy for cherry-picking
Last edited by Didier Spaier; 06-29-2023 at 01:58 AM.
Reason: Typo fix.
I think it could be nice to support zst format to make and install packages.
I just wrote two very simple patches for pkgtools and slackpkg slackbuilds. They both support the ".tzz" extension. I'd like to name it ".tzst" but I'm not good to rewrite the sed patterns, so ".tzz" is fine.
I tested them with my own repo successfully. I didn't need to patch slackpkg+.
I don't think it's a fully zst support, anyway it's a working start.
Hi again, just to say I use my patch since 3 months now, it works like a charm!
@Thom1b: The file extension is zst according to RFC8878 and pretty much everyone uses it, so zstd compressed file names should end in .zst. Other than that , +1.
@Thom1b: The file extension is zst according to RFC8878 and pretty much everyone uses it, so zstd compressed file names should end in .zst. Other than that , +1.
But Slackware packages use .t?z suffixes, where g (.tgz) for gzip, b (.tbz) for bzip2, l (.tlz) for lzip, x (.txz) for xz.
So z (.tzz) for zstd goes this way in package name ;-)
.tar.zst goes for zstd-compressed tarballs (or .zst for any files).
Sun Apr 7 18:15:16 PDT 2002
[...]
a/logrotate-3.6.2-i386-1.tgz: Added by popular demand. ;-)
Quote:
Originally Posted by volkerdi
The current reason is that the patch still works fine.
While it would seem that this could replace the patch, it could also cause issues for anyone who would upgrade to a newer package without the patch who had files with these extensions and didn't pay proper attention to the logrotate.conf.new file.
While this could seem reasonable, it should have never happened in the first place. :-)
@Thom1b: The file extension is zst according to RFC8878 and pretty much everyone uses it, so zstd compressed file names should end in .zst. Other than that , +1.
You're right! Like @bormant said, I choose "tzz" because of convention package name in slackware, but I don't care about extension. If Pat wants to support zst format, he can choose whatever extension name, it's fine for me
*.fw --> no compressed
*.bin --> no compressed
*.zst --> zstd firmware compressed
*.xz --> xz firmware compressed
Thats totally different thing , compared with the "FINAL" package ...linux-firmware.txz
Its a double compression , firmwares and later as a single package.
That reduce the final size of firmware folder...cause all single files are compressed.
---------------------
If i undertand bad and are talking around change the type os slackware packages compression , then sorry.
But are two diferent things , i post linux-firmware provides officially support to conpress all firmwares to save disk space , thats not same thing as slackware provide the packages compressed.
Last edited by USUARIONUEVO; 06-29-2023 at 04:12 PM.
If i undertand bad and are talking around change the type os slackware packages compression , then sorry.
But are two diferent things , i post linux-firmware provides officially support to conpress all firmwares to save disk space, thats not same thing as slackware provide the packages compressed.
I have built a kernel-packages kernel-firmware-20230625_ee91452-noarch-1slint.txz using the SlackBuild from Slackware with COMPRESSION=xz and indeed individual files are compressed.
The previous package I have provided for Slint had just a few less M in both lines, using the same patch as did Arch since a few days, so the result is the same, but we now get zstd compression in addition to xz.
Last edited by Didier Spaier; 06-30-2023 at 01:35 AM.
The more relevant point ,is cause we get "officially" from installer , not need extra patches or solutions , thats all , im happy cause its on provided makefile , and as extra , receive zstd.
I write other explanation cause i think people confused , that with the type os final packages from slackware and are different things.
We can compress firmwares with zstd , and provided in a classic as ever *.txz
For some clarifications, thats like compressed man pages , ...can compress or not , that no affect for the last point of package creation...but can reduce the final size.
Last edited by USUARIONUEVO; 06-29-2023 at 05:05 PM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
