I thought about warming up a thread like this thread, but since it is marked solved this would be incorrect.

Short summary: Some time ago we had discussion if packages that do not build anymore are broken or not. Of course they are, but some see it different.

Welcome 2018, Meltdown && Spectre

Through things like Retpoline, distributions that can fast recompile their packages will undoubtedly have an advantage and are these distros that are provable not broken, while others are different.
Isn't this fine?
Now, based on this very concrete usecase, we can say: packages that do not build and a are shipped as part of the distribution are broken.

This is not how Slackware is developed.
Instead of remaining vague and pointless, give some examples of software that has a critical vulnerability for which there is no Slackware security update, and which can not be compiled by you.

Note that the kernel devs are not releasing patched kernels for some of the versions used in older Slackware releases. But that's historically also true for Slackware: you (the sysadmin) take care of the kernel updates for the machines you run. It is quite exceptional that patched kernels are released for older Slackware versions, and it happens only when the upstream (i.e. the kernel devs) make the sources available. There's no back-porting of kernel patches into Slackware, like for instance Red Hat are doing.

Summarizing: packages whose binaries are running without error, are not broken, even if the sources currently associated with it are not compiling. The need for patches will be investigated if and when there is a requirement to recompile a package whose binaries stopped working.

If you want corporate support and deterministic build, then you should not pick Slackware as your distro. A one man distro will never be doing what you demand from it.
If you selected Slackware to run your business then this is a conscious decision marking you as a smart person, and therefore capable of handling these issues yourself - or with the help of the community. Tha's what happens all the time here on LQ: people report issues, and in a joint effort solutions are found that benefit everyone.

11 members found this post helpful.

Eric, you are mixing up things here, this has
*) nothing to do with deterministic build.
*) nothing to do with what you think I want need or will, for which all your guesses are, as usually, wrong anyway.
*) this is a different story than the kernel memory mapping.
*) the Retpoline patches are for the compiler to disable generation of code that enables branch target injection

a fixed compiler that eliminates a problem alone is not a fix, it needs also be applied, or, at least, be be able to be applied, if this is not the case ... well

And that this is not how Slackware is developed is not a news.
btw, did you know this?
Wer nicht mit der Zeit geht, geht mit der Zeit
(maybe translates to: who does not move with the times, will be removed over time)

Is there something stopping you from submitting patches to "fix" these "broken" packages?

1 members found this post helpful.

Slackware is a binary-based distribution. If the binaries work, then things aren't broken. How difficult is that to understand? (Or do you also think that if Slackware packages can't be built that they're breaking the GPL?) What you want is not something Slackware is ready to provide (and isn't required to provide either).

Maybe your expectations of Slackware are broken...

Yeah, "some"...

In this case, it does matter who the "some" are.

Historically, Slackware has had many packages that stayed the same across multiple Slackware releases, because they still worked.

The fixed compiler does not exist yet. There are lots of experimental patches, not yet tested, not yet integrated, not yet released, not yet backported. There is no point nagging about it at this time.

6 members found this post helpful.

a4z: It shoulds like your actual request should be:

"please rebuild all packages with a fixed compiler".

Or, even more specifically,

"please make sure you guys can do it when it's time to, because we can anticipate that need"

And not "please make sure I can do it myself".

Amirite?

EDITING TO ADD:

As most of the packages in the 32-bit branch were rebuilt in the last year or two (for i586), I'm pretty confident that the Slackware team is ready.

1 members found this post helpful.

Why not?

Wait and see gcc-7.3.0 with "retpoline" which will be released as quickly as possible, there seems to be some panic about "spectre" vulnerability.
It's a sort of race between the devs of gcc/kernel/glibc or whatever may be a source of vulnerabilty, and those who could exploit those "exploits".
I'm sure the Slackware devs will use gcc-7.3.0 when it's available.

Sure thing Slackware will adopt gcc-7.3.0.

BUT, some enlightened guys says that for a proper protection against Spectre the entire distribution should be recompiled with.

Also, while I agree that years ago building a distribution under an Athlon64 single core with socket 754, was literally a pain in ass, today we have trucks like Buldozers or even, goods forbid! Ryzens!

Those thingies have the ability to rebuild the entire Slackware in a matter of days.

And we have also tools to do it, for example: https://slackware.nl/alien-kde/source/

This thing already automate the (re)building roughly of a third part of the (future) Slackware.

who? where? why?

I have bad news for you: SPECTRE!

Daniel Craig will take care of them.

1 members found this post helpful.

I thouhgt he had thrown in the towel