LinuxQuestions.org - [SOLVED] Slackware 14.2 is coming , but will the slackbuilds will also be updated accordingly?

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - Slackware 14.2 is coming , but will the slackbuilds will also be updated accordingly? (https://www.linuxquestions.org/questions/slackware-14/slackware-14-2-is-coming-but-will-the-slackbuilds-will-also-be-updated-accordingly-4175575223/)

Quote:

Originally Posted by 55020 (Post 5526507)

If we are going to design more rules, maybe we should consider this highly relevant blog post from Matthew Garrett which he published late last night.

Well, there is of course some ground in this post but it smells a little pro domo to my nose, knowing the links of Matthew to Fedora (not to diminish his merits as e.g. he did a lot to ease usage of UEFI by Linux installers).

Also, there are cases where the upstream developer having moved on since a long time, a distribution that inherited it is considered by others as "upstream" although it be not more developed, only maintained there, and maybe not even used.

Let's take the example of the "newt" library. Its name is an acronym of Not Erik's Windowing Toolkit and it was developed by Erik Troan from Red Hat.

It is now hosted by Fedora that Debian considers upstream. But it is used a lot more by Debian (in its text installer through whiptail). In an ideal word the Fedora and Debian maintainers would cooperate (maybe Alastair McKinstry from Debian making git pull requests that Miroslav Lichvar would check then merge). However, looking at the respective lists of open bugs in the two distributions, and to the long list of Debian patches not applied (and the bidi patch even reverted as I reported in another thread) by Fedora this looks like wishful thinking.

Sorry for this off topic lucubration.

Quote:

Originally Posted by bassmadrigal (Post 5525723)

If this is brought up to the SBo admins/mailing list, I'd imagine they'd consider various actions. If there's an updated version with a fix, and it builds correctly on Slackware, I'd bet they'd update it themselves, even if the maintainer isn't involved. If there's no updated versions, but a patch available, I'd suspect they'd work the patch into the SlackBuild. If there is no fix, then there'd probably be discussion on the ramifications of removing the package or keeping it in an insecure state.
But they have to be notified when there's security concerns. I certainly don't check the sites of the SlackBuilds I maintain very frequently to see if there's updates or security issues. With my SlackBuilds, the software isn't updated very frequently, so I don't check it very often. I don't even really care about the development of those programs. They're just dependencies for another program that already had a SlackBuild that broke with -current. So I fixed one and had to add the other as a new dependency. If someone were to notify me of a security concern, I'd do my best to put out an updated SlackBuild that either patches the version I already had or change it to a newer version that doesn't have the vulnerability. And if they were to notify me of a version update, I'd do a little bit of digging to make sure it builds fine and doesn't break things, then I'd submit an update to SBo.

Gentle and fair as usual

Quote:

Originally Posted by solarfields (Post 5526426)

PS: I am glad you stayed in the forum, I generally like your attitude. :)

Thanks, I have got some kind of addiction to this forum. Honestly, I tested many distors to replace it with my Slackware but I didn't find anything easier and simpler than it.

Quote:

Originally Posted by travis82 (Post 5525682)

Ok, let me clarify. IMHO, if a package threats security of Slackware users it should be removed from SBO at least until it fixed either by it's developer or by slackbuild maintainer.

Is this a hypothetical?

And if it's not, then are you aware that posting about it while intentionally omitting specifics is the least constructive action that you could have taken?

Quote:

Originally Posted by dugan (Post 5526652)

Is this a hypothetical?

Yes, That's absolutely a hypothesis as I am not sure about Drakeo's specifics.

@ dugan, I appreciate the link. Thanks.

How To Properly Set Up Slackware Linux

Quote:

Originally Posted by 55020 (Post 5526507)

If we are going to design more rules, maybe we should consider this highly relevant blog post from Matthew Garrett which he published late last night.

Well David, despite and notwithstanding my previous answer, let me apporter un peu d'eau à ton moulin[1].

[1]Litteral translation: bring some water to your mill. In other words, bring some food to your opinion or statement.

PS this brings me this saying of the day (but don't quote me on that):
Q. What's the difference between Debian and Fedora?
A. Fedora brings new bugs, whereas Debian doesn't fix old ones.

Yes, I'm aware of jwz's side of the Debian / xscreensaver thing, and I tend to have more sympathy with jwz than with Debian on this.

You may be interested that xscreensaver is actually the *second* similar dispute this month. Debian declared that Owncloud is an "unfit upstream":
http://lists.alioth.debian.org/piper...ch/002899.html
https://bugs.debian.org/cgi-bin/bugr...cgi?bug=816376

*However* I was thinking more about the other points in Matthew Garrett's blog -- that "security bugs" are just a subset of bugs, and you don't always know which bugs are "security bugs". If fix a known security bug by upgrading, you will also get a lot of other fixes and also new bugs, possibly including new security bugs. If you backport a single security fix, you won't fix any other bugs, and the unfixed bugs might include more security bugs.