stop trolling everywhere , i not request , i ask only.

Im not interesting in multilib , but i think ,if this package can ship with that enabled, then probably , no need "overlaping" , original packages with 3th repo packages , like alien. (with all the respects for Eric)

And , for your infomation , YES , you can have multilib, without gcc multilib , glibc is the part neede for "exec" 32bit apps , if no go build nothing, then no need gcc-32.

But i repeat , i post for "curiosity" , cause im not sure if this build option is new , or exist in other glibc releases... and what this option does.

Is trolling to be annoyed by the forever returning struggle with multilib?

BTW, you asked, (again) I responded: you need a multi-architecture compiler to build a multi-architecture glibc. Nothing new from what I know since 20 years ago.

dbus-1.12.10:

https://cgit.freedesktop.org/dbus/dbus/log/?h=dbus-1.12
https://dbus.freedesktop.org/release...1.12.10.tar.gz

mercurial-4.7:

https://www.mercurial-scm.org/wiki/Release4.7
https://www.mercurial-scm.org/releas...ial-4.7.tar.gz

rust-1.28.0:

https://github.com/rust-lang/rust/bl...280-2018-08-02
https://static.rust-lang.org/dist/ru...8.0-src.tar.gz

Quoted me , please, quoted my "request" to add multilib.

I see you can read , then please, understand what are you reading, and flame late, if can.
"
You are here only requesting "your interesting" updates, and flame when other user do the same...in forums ,that users are called trolls.

I never request multilib , no use wine here , i prefer ever pure 64 systems , 32 bits are in death process, slow, but in process ..

I comment one option from glibc compiling time, thinking if this can benefit or not, as example building glibc ,in a 64bit system , and making the same package to 32 bits , without start another vm , with the 32bit slackware system , thats all.

I never say "please enable that on glibc", i only comment cause im not sure if some benefit comes with this option.

Man, this option enables right on that "multilib" feature at build time on GLIBC. I hope I was clear enough previously.

BUT, this is not enough. You need also a "multilib" compiler to build a "multilib" GLIBC, like I said already two times.

We use to name a particular feature "multilib" but its real name is "multi-architecture" aka "multi-arch" in contrast with the "single architecture" (or "pure 32bit" and "pure 64bit") which is what Patrick Volkerding do today.

Excuse me and my biasing, BUT you asked these details right on the Requests Thread, hence I suspected you of intentions about requesting it later. Later yourself accepted that you look for a way to build a "multilib" GLIBC with a pure 64bit compiler.

However even if you asked in a separate thread, I am afraid that my response happened to be the same. Because is not about flaming, but a fact:

a pure 64bit compiler (like one from Slackware64) cannot generate 32bit binaries (excluding the standalone ones, like the kernel), that's WHY you need a "multilib" one for building a "multilib" GLIBC.

Speaking of requests for -current, we can have yet another update from xf86-video-ati GIT? https://cgit.freedesktop.org/xorg/dr...video-ati/log/

There was added improvements for the situation when Glamor is used together with the TearFree option, and I tested that update since several days already, with perfect success.

sysstat-11.6.5:

http://perso.orange.fr/sebastien.god...-11.6.5.tar.xz

When are we going to stop asking for updates? Cuz this'll never become Slackware 15 if we dont find a stopping point.

At the earliest when we will see "release candidate" in the ChangeLog, in several months. And Slackware 15 will be released, as usual, when Patrick Volkerding will think it's ready, whatever will be this thread's state then.

tl;dr: don't worry.

Latest HPLIP is broken
 

Cheers

it seems $DESTDIR isn't respected by this new binary blob, it installs in /usr/lib${LIBDIRSUFFIX}.
excerpt from running hplip.SlackBuild
EDIT: looks like an upstream bug: if useful I prepared a patch

Well I just figured out why I hosed my system the last time I tried to make a chroot. It's because I did "installpkg --root=/path/to/chroot" and not "installpkg --root /path/to/chroot".

Having installpkg work with the first syntax would be nice.

Greetings.

Is it desirable to have code in rc.S to only delete /etc/mtab if it is a file and not if it is a symlink to /proc/self/mounts ?

I have changed rc.S like seen above and it works fine in my case but i do not know if it is enough or there are corner cases like nfs mounts and stuff.

I asked about it again 10-15 months ago and some users wanted /etc/mtab as a file due to nfs or something (i don't remember) but maybe they changed their minds since then. Is it desirable by anyone else ? Is it the right time or it is too close to 15.0 for such a change ?

I use other sysntax here ..

This has probably been suggested some time in the past but searching on the forums hasn't given me any results so here goes:

Splitting the L series into a bunch of other L-* series? e.g. l-audio, l-x11 or even (since some have been talking about it), l-kde (and other such things) amongst other similar stuff?

Alternatively, get rid of series and of associated subdirs in the Slackware tree :D

We are not anymore in the floppy disk era, but for some very specific use cases.

I hope not: how would e.g. an XFCE user like myself be able to skip KDE during an install then?
:D

Use tagfiles, or make your own for XFCE. It would be possible to just ship tagfiles named like xfce-tagfile.

The community could also maintain lists of Slackware packages for specific purposes with just their short names: desktops, text-only installation, minimum installation, servers of various kinds, etc., taking care that each list be self-supporting, i.e. include all deps. Of course then there will be redundancy between lists, but that doesn't matter: if the package is already installed, just skip it (as does upgradepkg by default).

The only condition would be that all the listed package be shipped by Slackware.

Alternatively it is possible to make e.g. a sub-directory XFCE fed with hard links to packages included in this set, but that's probably not worth the maintenance involved.

Didier, putting everything in a single folder is the best way to ensure that nobody but a handful of die-hard KDE (or Plasma5) users will use Slackware.

How nobody knows the dependencies between the packages from Slackware, at least that's how is claimed officially, the tagfiles argument is moot.

Did you really believe that the sysadmins has nothing to do other than to study the package inter-dependencies from Slackware for at least several years? :D

That's Holly Full Install fundamentalism at its best. ;)

So sad that someone found your post useful. :(

Are you kidding? All dependencies are already documented by George using depfinder then editing the .dep in some cases, see for instance http://slackware.uk/salix/x86_64/slackware-14.2/deps/. I can't remember a complaint from a Salix user like "I wanted to add this genuine Slackware package to my Salix installation and I am missing this library".

I am not saying that depfinder is perfect but it's good enough. I also know that there are other tools, but am not sure they handle Python deps.

And this doesn't need at all that Slackware genuinely manage dependencies: it's easy enough to write a script that completes a list of packages with their dependencies using the .deps, which can of course be corrected as needed. Those of us who like obfuscation could even make it a one liner ;)

Sadly, this was already discussed in threads lengthy like some dozens pages every one. ;)

And was proposed something much smaller, like splitting L series into KDEL series (for everything associated with KDE only) and XL series (for everything associated with X11 but not KDE)

No, unfortunately I am not kidding.

I believe that putting everything in a single folder will exacerbate the problem of lack of package dependencies resolution in Slackware, up that will make it unusable for something else than a KDE desktop.

Not that that will hit on my usage of Slackware, because today I use it just as a hobby, only in several home computers, where I run a KDE desktop with a LAMP stack in background.

Of course, there's another computer dedicated for playing with Plasma5, if does matter. ;)

None of the Slackware derivatives ship a full Slackware installation, hence all need a way to manage the package dependencies by themselves, and I never heard a complaint by one of their maintainers about that. Whether Pat decides or not to publicly document the packages dependencies and to ship software to handle them is up to him, and that's neither an issue for me personally nor for Slint.

I disagree with Darth a lot, but he and I are on the same page here. It makes no sense to put all packages into one directory and then write something new to allow users to select functional subsets from that big directory. That's just inventing work for Patrick that does not add anything.
Call it dependency resolution or whatever, but fact is, Slackware does not provide dependency resolution and we are not Salix. Hence, we stick to the package series of old.

I am still very happy with the fact that I can select A, AP, N series and have a working base Slackware that way. Or de-select E, KDE, KDEI, in case I can do with a small-ish XFCE desktop environment.

Perhaps someone with depfinder on his computer could write a series of Slackware tagfiles for specific targets: KDE-less, X-less, minimal console with network, Desktop without development packages, LAMPP server without Desktops, etc...? That would be a nice project with its own merit that can be maintained in a git repository.

Thunderbird-60.0

The source, https://ftp.mozilla.org/pub/thunderb....source.tar.xz

The release notes, https://www.thunderbird.net/en-US/th.../releasenotes/

This appears to be a major release with 19 'new' items, 19 changes and 14 fixes.

Among other things.....

I do not volunteer for that as I am already late on too many things, but as an example here is a draft script to provide a tagfile for a base system with only light graphical environments:I didn't and won't check the output, that's just to give an idea to people wanting to actually do that:

1. Make a list of the packages you want (I did that in a here document, but of course that should be a regular file).
2. Populate the tagfile with packages needed in any system. To save time I just used the lists of packages included in the CORE Salix edition (this include the packages tools used by Salix, that you would remove), but you can begin with the tagfile for the a/ list of packages, whatever.
3. Then add the deps to the tagfile. I used the ones already computed by George for Salix to list them, but you may use depfinder or any other tool.

I'm confused. Why are we talking about Slackware derivatives? Slackware is not Salix or Slint.

You already know that the answer to that question is no. In light of that, I really can't understand why you think eliminating the existing package groups would be in any way useful or productive.

Re: hplip issues, I was also affected and since the upgrade to 3.18.7 I was unable to print. Downgrading to 3.18.6 solved the issue and I am able to print again.

I created a topic on the issue:
https://www.linuxquestions.org/quest...de-4175635625/

It doesn't make sense to split or eliminate any of the package series. Everything works as it is. A change to that degree would require a good technical reason to do so other than this is how <insert Slackware derivative> does it. The only change I see worth the effort is a redistribution of packages for KDE (when/if KDE 5 is added) only dependencies from l/ to kde/ makes sense because it simplifies everything.

My :twocents:

I was just answering to Darth, who wrote:What I wanted to illustrate is that having the packages in one or several directories is in my view a decision completely unrelated to the presence or absence of (provided by Slackware) packages dependencies. In other words putting all packages in the same directory doesn't increase or decrease the need of package dependencies

Well, in context I just wanted to provide a alternative to cut the L/ series in slices ;)

Actually I don't really care in how many directories the packages are stored. But at least putting them all in one directory would eventually end once and for all all the boring threads such as "this package is not in the right series" or "we need to review the layout in packages series because..." ;)

I have to agree with Darth here that even without actual dependency resolution, it's still very nice to be able to just exclude certain groups that you know you won't need rather than doing a true full install. For example, I normally don't use either XFCE or KDE; I use Openbox and add some apps from KDE and XFCE. I much prefer just adding those and resolving their relatively few dependencies manually rather than installing the entire XFCE and KDE series. Getting rid of the series altogether would add work for Pat while having many negative results and few if any positive ones.

Everyone is entitled to one's opinion. Let's go back to the topic.

btrfs-progs-4.17.1:

https://git.kernel.org/pub/scm/linux...rfs-progs.git/
https://mirrors.edge.kernel.org/pub/...v4.17.1.tar.xz

xindy from texlive is broken on -current, both the one from the slackware package or the ctan version:

the slackware version comes back with the error:
/usr/lib64/clisp-2.49.93+/base/lisp.run: initialization file `/usr/bin/xindy.mem' was not created by this version of CLISP runtime

and the ctan version (xindy.run) is compiled against libtinfo.so.5.

However simply adding libtinfo.so.5 to the aaa_elflibs package (which wouldn't be a bad idea on its own right since libncurses.so.5 is there already) wouldn't fix the whole issue as both packages (ctan and -current) uses the same xindy.mem file:

md5sum /usr/bin/xindy.mem /usr/local/texlive/2018/bin/x86_64-linux/xindy.mem
d6dfb2f5b2499f225a6f4f4bfeafcc12 /usr/bin/xindy.mem
d6dfb2f5b2499f225a6f4f4bfeafcc12 /usr/local/texlive/2018/bin/x86_64-linux/xindy.mem

Unfortunately, I know nothing about clisp so I don't know if it is possible to remove the versioning dependency. I can ask the texlive mailing list if that helps.

Just be advised that I still cannot get my HP LJ 1020 to print with the latest hplip (3.18.7). Reverting to 3.18.6 fixes the issue for me.

You can follow the developments and get a pastebin link to a debug log here:

https://www.linuxquestions.org/quest...8/#post5889028

xorg-server-1.20.1

The tarball, http://xorg.freedesktop.org/archive/...1.20.1.tar.bz2

As of the moment, the link to the tarball does not seem to work.

The announcement, https://lists.x.org/archives/xorg-an...st/002912.html

The x and xap groups are the meaningful ones, aren't they? Nothing outside of those two have X dependencies.

network-manager-applet-1.8.16
http://ftp.gnome.org/pub/gnome/sourc...-1.8.16.tar.xz

Not sure what you mean. No package outside the y group have dependencies on a package of the y group, but does that make the y group meaningful, bearing in mind that most games are in the kde group? Maybe I don't get what mean by meaningful .

Anyway if you want to continue this discussion I suggest that you open a new thread for it, to keep this one on tracks.

A friendly reminder about freetype 2.9.1. to get around the stupid windows misdetection bug all you have to do is run make RC="". I've tested it and it works. I also tried building the newest git release and it still has the windows.h bug. For what ever reason I guess they don't consider it a bug.

http://lists.nongnu.org/archive/html.../msg00078.html
http://cve.mitre.org/cgi-bin/cvename...=CVE-2018-6942

librsvg-2.42.6:

http://ftp.gnome.org/pub/gnome/sourc...vg-2.42.6.news
http://ftp.gnome.org/pub/gnome/sourc...-2.42.6.tar.xz

harbuzz-1.8.6:

https://github.com/harfbuzz/harfbuzz/releases
https://www.freedesktop.org/software...-1.8.6.tar.bz2

I can replicate this by running
in a directory containing the contents of the doc/style-tutorial directory from the xindy source at http://mirrors.ctan.org/indexing/xin...y-2.5.1.tar.gz
According to this, the solution is to rebuild xindy from source.
However, I have found that building the xindy source locally (without doing 'make install') and running
appears to succeed.

Seen CLISP mentioned made me wonder whether we could have another Lisp implementation. I'm aware of the historical significance of CLISP in Slackware (according to Wikipedia), but, let's be honest, it is not the best possible Lisp by any stretch of the imagination. Having SBCL would be much more useful, in my humble opinion. And it's already on slackbuilds.org, so promoting it to an official package should be pretty easy to do.

I'll look into this. I assume the cause is, that xindy is built by the texlive.slackbuild, but parts are also taken from the texmf-tree from tlnet and may overwrite something.
The idea was to have xindy build by Pat, but also keep the rest of the xindy stuff updated/in line with the other tlnet texmf stuff. I have hardly time at the moment, and i'm also away for some days, maybe this may take up to two weeks to fix/submit to Pat, along with some other reported problems.

Johannes

ConsoleKit2-1.2.1:

https://github.com/ConsoleKit2/Conso...ases/tag/1.2.1

... that should bring it closer to being a logind-API drop-in replacement for systemd-logind or elogind. Not needed in Slackware at the moment, but will become relevant if Plasma 5 enters Slackware and KWin is extended with support for Wayland (I currently do not enable Wayland).

audacious-3.10:

https://audacious-media-player.org/n...-3-10-released
https://distfiles.audacious-media-pl...s-3.10.tar.bz2
https://distfiles.audacious-media-pl...s-3.10.tar.bz2

cmake-3.12.1:

https://blog.kitware.com/cmake-3-12-...-for-download/
https://cmake.org/files/v3.12/cmake-3.12.1.tar.gz

harfbuzz-1.8.7:

https://github.com/harfbuzz/harfbuzz/releases
https://www.freedesktop.org/software...-1.8.7.tar.bz2

boost-1.68.0:

https://www.boost.org/users/history/version_1_68_0.html
https://dl.bintray.com/boostorg/rele...1_68_0.tar.bz2

Well that's not fair. I don't even have the already built 1.8.6 packages uploaded.