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.
Yes, good news indeed -- Thanks Pat. -- but zakame deserves the credit for spotting/raising the issue not me. I'm just a grumpy guy on the forum who expressed a preference for doing it the old way. I'm sure Pat came to his own conclusions.
As a follow on, it might be an idea to modify rc.S anyway to make the mtab handling conditional on it not being a symlink to cater for those who want to do it the new way. Something like:
Code:
if [ ! -L /etc/mtab ]; then
# Any /etc/mtab file that exists here is old, so we start with a new one:
/bin/rm -f /etc/mtab /etc/mtab~ /etc/mtab.tmp && /bin/touch /etc/mtab
# Add entry for / to /etc/mtab:
/sbin/mount -f -w /
# Add /proc, /sys, and /dev/shm mounts to /etc/mtab:
if [ -d /proc/sys ]; then
/sbin/mount -f -t proc proc /proc
fi
if [ -d /sys/bus ]; then
/sbin/mount -f -t sysfs sysfs /sys
fi
if grep -q '^[^ ]\+ /dev/shm ' /proc/mounts 2> /dev/null ; then
/sbin/mount -f -t tmpfs tmpfs /dev/shm
fi
fi
(I've also removed a bashism on the rm -f line, while I was looking at it),
It might even be better to make it if [ ! -L /etc/mtab ] && [ -f /etc/mtab ]; then to cater for there not being a mtab at all (which seems to be the direction that upstream want to go) but that needs more thought.
Yes, good news indeed -- Thanks Pat. -- but zakame deserves the credit for spotting/raising the issue not me. I'm just a grumpy guy on the forum who expressed a preference for doing it the old way. I'm sure Pat came to his own conclusions.
For the record: The PdfHandler extension from MediaWiki 1.28.0 isn't compatible with the pdfinfo command from the poppler-0.50.0 package. From the release notes:
Release 0.46.0
* pdfinfo: Don't print pdf info when printing metadata, javascript, or structure. Bug #96801
PdfHandler expects the old "buggy" behaviour. As a workaround I removed the -meta option from PdfHandler.image.php.
DUDE!
SackWare would not be SlackWare
if every thing was kept bleeding edge
I can see some benefit in rebuilding the libraries
for better CPUs but alot of this are small programs
and ones you would not very often so what dose it matter
On my system, the Sandisk Cruzer USB Stick has file names in /dev/disk/by-id/, that contain
colons: this causes lilo to fail when using one of these files as a boot disk. This patch
replaces the failure with a warning.
--- ./src/geometry.c.orig 2015-11-21 18:50:18.000000000 -0500
+++ ./src/geometry.c 2016-12-28 18:27:24.322516088 -0500
@@ -1357,16 +1357,12 @@
int geo_open(GEOMETRY *geo,const char *name,int flags)
{
- char *here;
- int user_dev,block_size;
+ int user_dev = -1,block_size;
struct stat st;
- if ((here = strrchr(name,':')) == NULL) user_dev = -1;
- else {
- *here++ = 0;
- warn("%s:BIOS syntax is no longer supported.\n Please use a "
- "DISK section.", name);
- user_dev = to_number(here);
+ if (strrchr(name,':') != NULL) {
+ warn("%s:BIOS syntax is no longer supported: "
+ "Treating as a device file.", name);
}
if ((geo->fd = open(name,flags)) < 0)
die("open %s: %s",name,strerror(errno));
let me check change logs . Pat rebuild firefox so it functions correct with the new GCC and stuff you built. like Seamonkey is working fine you rebuilt it.
DUDE!
SackWare would not be SlackWare
if every thing was kept bleeding edge
I can see some benefit in rebuilding the libraries
for better CPUs but alot of this are small programs
and ones you would not very often so what dose it matter
Slackware would not progress if Pat didn't put newer versions in -current. Even right now, it is pretty close to bleeding edge for X and mesa and probably quite a few other programs. That is exactly what -current is for. To throw stuff at the wall (newer versions) and see what sticks (bug-free and stable). When we get closer to a stable release, the "latest and greatest" versions usually take a back seat to the "tried and true" versions.
And I think all i486 packages that have been rebuilt for one reason or another for the last year or two have been rebuilt to i586, so Slackware is slowly working towards replacing i486 with i586. The i486 packages mentioned above all have newer versions, which would give Pat a reason to rebuild them as i586 (other than to just rebuild them to i586).
Overall, this is a "requests" thread. Anybody can request whatever they want. You can request upgrades, downgrades, new packages, removals, or changes. Pat and team have the experience and knowledge to make good decisions on whether or not to upgrade packages. Robby specifically posted this thread so people could request updates. Now, if you have good reasons that any of these programs shouldn't be updated, then that is worthy of a post. But to just say we don't want bleeding edge in the development version of Slackware, seems a little shortsighted.
I didn't mean this to slam, but rather to inform. Hopefully it seems informative rather than the alternative
bassmadrigal
slackware has a reputation for being the most stable and bug free distro there is .
and by staying a little bit behind Pat and the other devlopers
have avoided some of the traps that other distros have fallen in to let the other distros find the bugs
an example would be the buggy GNU libs that red hat 7 had
fact RHL7 is why I started using slackware in the first place
note
that's red hat linux 7 NOT Red Hat Enterprise Linux 7
I do have a request
I would like to see a update script included in the install media it just seems to me that making the major changes involved in updating would be safer on a non running system
I just always wonder if it will boot when ever I update my system
bassmadrigal
slackware has a reputation for being the most stable and bug free distro there is .
and by staying a little bit behind Pat and the other devlopers
I am well aware of Slackware's reputation. But this is Slackware's development channel. Pushing newer versions is exactly what -current should be used for, especially early in the release cycle. It's better to find buggy versions here than in a stable release.
Currently, according to Slackware's distrowatch page, -current is running the latest stable version (or newer, in the case of grub) on 16 out of the 30 installed packages that they track on their default page. If we widen the parameter to all packages they track, out of the 123 packages Slackware has installed, 85 of them are running the latest stable versions (or newer, in the case of grub). That's almost 70% of the packages distrowatch tracks, we're on the "bleeding edge".
Even with all those "bleeding edge" versions, -current stays remarkably stable. This is a testament that Pat and team are more than capable. Pat and team have been doing this long enough to know which projects tend to put out buggy releases and they're more likely to stay behind a version or two (maybe more, depending on the project). That reasoning has even been mentioned in this thread or on the forum (I can't remember which, and it would be too difficult to find the reference) as a reason that they aren't willing to upgrade to the latest version of some program.
As I said before, Pat and team know what they're doing. They've been providing us rock solid releases for years (decades, in Patrick's case). We can suggest whatever we want, and they'll "take it under advisement". They may choose to upgrade it, or they may choose to keep it the same version. But this is a "requests" thread, so people should be able to request anything they're interested in seeing.
Last edited by bassmadrigal; 01-17-2017 at 01:36 AM.
Reason: Fixed url for distrowatch
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 zakame deserves the credit for spotting/raising the issue not me. I'm just a grumpy guy on the forum who expressed a preference for doing it the old way. I'm sure Pat came to his own conclusions.
