LinuxQuestions.org - Requests for -current (14.2-->15.0)

Current xauth-1.0.10-x86_64-2.txz have a bug with changing hostname - it breaks access to X
For fix this need to apply this patch to support adding such FamilyWild entries via xauth directly with an *:0 argument:

Code:

From bc78aa61cfbddaa27dee275f639ba40de6981b17 Mon Sep 17 00:00:00 2001

From: George V. Kouryachy (Fr. Br. George) <george@>

Date: Fri, 4 Aug 2017 18:37:33 +0300

Subject: [PATCH] parse_displayname: use FamilyWild for *:0



---

 xauth/gethost.c  |    4 ++++

 xauth/parsedpy.c |    4 ++++

 2 files changed, 8 insertions(+), 0 deletions(-)



diff --git a/xauth/gethost.c b/xauth/gethost.c

index 8cb58c5..598ac48 100644

--- a/xauth/gethost.c

+++ b/xauth/gethost.c

@@ -180,6 +180,10 @@ struct addrlist *get_address_info (

      * information to be copied and set len to the number of bytes.

      */

    switch (family) {

+      case FamilyWild:                        /* was :0 */

+        src = "\xff\xff";

+        len = strlen(src);

+        break;

      case FamilyLocal:                        /* hostname/unix:0 */

                                        /* handle unix:0 and :0 specially */

        if (prefix == 0 && (strncmp (fulldpyname, "unix:", 5) == 0 ||

diff --git a/xauth/parsedpy.c b/xauth/parsedpy.c

index 97988d3..6c98339 100644

--- a/xauth/parsedpy.c

+++ b/xauth/parsedpy.c

@@ -141,6 +141,10 @@ parse_displayname (const char *displayname,

            family = FamilyInternet;

        }

 #endif

+    } else if (len == 1 && *displayname == '*') {

+        /* ALT: wildcard cookie */

+        host = copystring("*", 1);

+        family = FamilyWild;

    } else if (!dnet && (*displayname == '[') && (*(ptr - 1) == ']')) {

        /* Allow RFC2732-like [<IPv6NumericAddress>]:display syntax */

        family = FamilyInternet6;

-- 

1.7.3.3

Link on the patch http://git.altlinux.org/people/georg...9ba40de6981b17

jostber

08-26-2018 11:59 AM

Wonder if Cups 2.3 and the new planned driver format in this version will be incorporated in the Slackware 15.0?

https://www.cups.org/blog/2018-06-06...velopment.html

jostber

08-26-2018 12:01 PM

Add an extra secure kernel as a choice in Slackware and a slack version of the enforcemode like in SElinux:

https://en.wikipedia.org/wiki/Security-Enhanced_Linux

jostber

08-26-2018 12:12 PM

Add a backup tool for snapshots and restore as a standard in Slackware. Something like Mondorescue:

http://www.mondorescue.org/

jostber

08-26-2018 12:14 PM

Add a nice looking Slackware wallpaper with the logo and 15.0 a standard for the KDE users. Like this:

http://wallpapercave.com/wp/Wr8IqHz.jpg

jostber

08-26-2018 12:25 PM

Have a half-yearly release cycle for Slackware versions. The incremental versions will mostly be security updates and bug fixes while the major releases will have the main new features. Current will then be for the major new releases. The major versions could come out about each 1.5 year.

chrisretusn

08-26-2018 12:28 PM

Quote:

Originally Posted by montagdude (Post 5895322)

I don't really see how it's any different. With my proposed changes, you would not get a .new file at all unless it was different from the previous default config file. This would be even more helpful for large complicated files where you've made lots of edits, because you wouldn't need to dig through it to find out whether there were important changes. No .new file = the only changes are the ones you made yourself. If there is a .new file, that means there are potentially important changes coming from the new package.

Okay maybe it's the use of default config file is what is blowing my mind. I consider the default config file the one included in the package being installed or upgraded (aka new config file). The currently installed config file would be the old one. If I make no changes then the old matches the new and the new config file will be deleted. With the current method if the old and new do not match the new is left for me to consider. In my case since I do all of my package updates using slackpkg, this will be handled at the end.

I think I see the light..., maybe not... You want to track the state of the default config file after it's first installed. If an update is made and the state of the default config file matches the state of the "first installed" config file, then no new config file is installed. The modified config file is basically ignored. So what happens if there are changes to the default config file that I may want to use, or may even need?

Didier Spaier

08-26-2018 12:54 PM

Quote:

Originally Posted by jostber (Post 5896230)

I would prefer to stay with a release "when it's ready".

However it could help to provide from time to time (maybe half yearly or yearly) a new ISO, that would just be "the current state of the stable release", i.e. with all updates provided in /patches since the last release and possibly an update of the installer. Rationale:

This could help people with recent hardware, not yet supported at time of the last release.
This would alleviate the need for heavy upgrades just after installation for people installing a release a long time after it has been made available.
It wouldn't add to the burden of maintenance for Pat beyond building the ISO itself as that wouldn't introduce a new version (in case the installer be updated, it could go in /patches, that's all.)
There would be no need for current users of -stable to do anything when the new ISO becomes available.

montagdude

08-26-2018 01:05 PM

Quote:

Originally Posted by chrisretusn (Post 5896231)

I think I see the light..., maybe not... You want to track the state of the default config file after it's first installed. If an update is made and the state of the default config file matches the state of the "first installed" config file, then no new config file is installed. The modified config file is basically ignored. So what happens if there are changes to the default config file that I may want to use, or may even need?

In that case, you would get a .new file. I think ttk's summary a page or two is the clearest one. (I would link to it, but it's painful to do stuff like that on my phone. It's the one with 4 scenarios listed.)

Darth Vader

08-26-2018 01:29 PM

Quote:

Originally Posted by Didier Spaier (Post 5896237)

This could help people with recent hardware, not yet supported at time of the last release.
This would alleviate the need for heavy upgrades just after installation for people installing a release a long time after it has been made available.
I wouldn't add to the burden of maintenance for Pat beyond building the ISO itself as that wouldn't introduce a new version (in case the installer be updated, it could go in /patches, that's all.)
There would be no need for current users of -stable to do anything when the new ISO becomes available.

Regarding this idea, I thought already about an annual Service Pack. ;)

This annual Service Pack can integrate the patches already issued through that year, and supplementary containing the switching to a newer LTS Kernel series and associated packages like the filesystems and tools, and an updated installer.

Additionally, the installer from a Service Pack can contain supplementary an "upgrade" option for installing packages, useful for applying the Service Pack on an existent installation. I think that's is possible because an Service Pack probably will not contains packages removals or renames.

This annual Service Pack could represent an incentive for those who pays subscriptions (then more sales for our BDFL) and in my opinion the Slackware 14.2 yells right now for it - see the endless issues with installation on EMMC and NVMe drives and support for many more modern hardware.

I know, I know, there will be raised the argument that the Slackware Gurus will build themselves new kernels and will do dark Slack-Fu art on installations, BUT not all users are Gurus, specially the rookies. ;)

sombragris

08-26-2018 04:47 PM

Quote:

Originally Posted by Didier Spaier (Post 5896237)

However it could help to provide from time to time (maybe half yearly or yearly) a new ISO, that would just be "the current state of the stable release", i.e. with all updates provided in /patches since the last release and possibly an update of the installer. Rationale:

AlienBob provides this and it's updated practically with every new release of the ChangeLog:

https://slackware.nl/slackware/slackware64-current-iso/

All times are GMT -5. The time now is 03:08 AM.

Page 130 of 657

130