Requests for -current (14.2-->15.0)

SCerovec · 12-28-2019, 05:12 PM

Quote:

Originally Posted by dgusev

Hello.
Is there a todo checklist what have to be done to release Slackware 15.0?
Thanks.

Once this thread reaches 150 posts, we might be close

orbea · 12-29-2019, 10:51 AM

Can this patch be applied to zstd to fix the libdir in the .pc file? Its required for building the current mesa master on multilib systems. No changes to the slackbuild will be needed.

Code:

From 9da6b9612ef0ed2481c762f0c78af1204e407ccc Mon Sep 17 00:00:00 2001
From: orbea <orbea@riseup.net>
Date: Mon, 16 Dec 2019 05:17:03 -0800
Subject: [PATCH] pkgconfig: Don't hardcode libdir.

---
 lib/Makefile      | 1 +
 lib/libzstd.pc.in | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/lib/Makefile b/lib/Makefile
index fd1710cf1..cb8351e13 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -244,6 +244,7 @@ libzstd.pc:
 libzstd.pc: libzstd.pc.in
 	@echo creating pkgconfig
 	@sed -e 's|@PREFIX@|$(PREFIX)|' \
+             -e 's|@LIBDIR@|$(LIBDIR)|' \
              -e 's|@VERSION@|$(VERSION)|' \
              $< >$@
 
diff --git a/lib/libzstd.pc.in b/lib/libzstd.pc.in
index e7880be47..9309426ec 100644
--- a/lib/libzstd.pc.in
+++ b/lib/libzstd.pc.in
@@ -5,7 +5,7 @@
 prefix=@PREFIX@
 exec_prefix=${prefix}
 includedir=${prefix}/include
-libdir=${exec_prefix}/lib
+libdir=@LIBDIR@
 
 Name: zstd
 Description: fast lossless compression algorithm library

I submitted this upstream nearly two weeks ago, but I seem to have been ignored since.

https://github.com/facebook/zstd/pull/1930

Didier Spaier · 12-29-2019, 05:51 PM

Please apply the attached patch, cf. this post.

PS Maybe use a [:blank:] POSIX class instead of [ ], just in case someone will use \t in the future.

EDIT. Thanks!

Skaendo · 12-30-2019, 05:47 PM

Is there something holding up Python 3.8.1?

volkerdi · 12-30-2019, 06:41 PM

Quote:

Originally Posted by Skaendo

Is there something holding up Python 3.8.1?

No.

Skaendo · 12-30-2019, 07:27 PM

Quote:

Originally Posted by volkerdi

No.

Ok thanks. I just wondered, not in a hurry for it.

EDIT:

Thank You!

cwizardone · 12-31-2019, 04:39 AM

Oops! Skaendo beat me to it.
If you haven't seen it, check out today's change log.

http://www.slackware.com/changelog/c...php?cpu=x86_64

mats_b_tegner · 12-31-2019, 10:30 AM

ImageMagick 7.0.9-13 is out:
https://imagemagick.org/script/changelog.php
https://imagemagick.org/download/Ima....0.9-13.tar.lz
https://imagemagick.org/download/Ima...-13.tar.lz.asc

alex14641 · 12-31-2019, 11:30 AM

Could we get go 1.13.5 from golang.org installed? The go from GCC doesn't build mongo tools correctly. With the following code:

Code:

package main


import (
        "fmt"
)

var version = "Not Set!!!"

func main() {
        fmt.Printf("Hello world, version: %s\n", version)
}

the command

Code:

go build -o version -buildmode=pie -ldflags '-X main.version=1.0'

generates an incorrect binary.

Code:

# ./version
Hello world, version: Not Set!!!

When built with go 1.13.5 from golang, the output is correct:

Code:

# ./version
Hello world, version: 1.0

Also, when building Mongo tools with gccgo, the following error occurs:

Code:

Building mongoreplay...
go build: when using gccgo toolchain, please pass linker flags using -gccgoflags, not -ldflags
# command-line-arguments
/usr/bin/ld: $WORK/b001/_pkg1_.a(_cgo_defun.o): relocation R_X86_64_32 against `.rodata' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld: $WORK/b001/_pkg2_.a(_cgo_defun.o): relocation R_X86_64_32 against `.rodata' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld: $WORK/b001/_pkg3_.a(_cgo_defun.o): relocation R_X86_64_32 against `.rodata' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld: final link failed: nonrepresentable section on output
collect2: error: ld returned 1 exit status

This error does not occur with go 1.13.5.

I have installed go 1.13.5 in /usr/go1.13.5 so as not to conflict with gccgo.

Skaendo · 12-31-2019, 01:25 PM

Quote:

Originally Posted by alex14641

Could we get go 1.13.5 from golang.org installed? The go from GCC doesn't build mongo tools correctly.

go (golang) and gcc-go (gnu go compiler) are two different things, go is a programming language where gcc-go is a compiler frontend. Did mongo tools build properly before with gcc-go?

https://stackoverflow.com/questions/...n-gc-and-gccgo

Quote:

there is often a desynchronization between go supported by gccgo, and the latest go release:

See the first answer on stack overflow for more in-depth explanation.

alex14641 · 12-31-2019, 02:09 PM

Quote:

Originally Posted by Skaendo

go (golang) and gcc-go (gnu go compiler) are two different things, go is a programming language where gcc-go is a compiler frontend.

Ok... Don't see the relevance of that statement.

Quote:

Did mongo tools build properly before with gcc-go?

No.

mlangdn · 12-31-2019, 03:06 PM

Imagemagick gets updates faster than gas prices.

Didier Spaier · 12-31-2019, 04:59 PM

the names are confusing but, quoting the README:

Quote:

About Glade
~~~~~~~~~~~

This version of Glade (Glade >= 3.10) targets GTK+ >= 3.0 and is parallel
installable with Glade 3.8.

If you need to work with Glade projects that target GTK+2, you need an
installation of Glade 3.8 (more information on http://blogs.gnome.org/tvb/2011/01/15/the-glade-dl/)

Source. Willy has a SlackBuild as it is a dependency of Mate (I also ship it in Slint for the same reason). But maybe all this stuff is already in the pipe, who knows

Skaendo · 12-31-2019, 05:10 PM

Quote:

Originally Posted by alex14641

Ok... Don't see the relevance of that statement.

Well let me take a stab at this.

You are trying to build something with the wrong tools. So, you are requesting golang to be included in Slackware because something that is not in Slackware requires it?

golang is available via SBo and *I* don't think that volkerdi is or should include something that he and Slackware have no need of.

Didier Spaier · 12-31-2019, 05:54 PM

The doc says about the default_driver option:

Quote:

If this is not specified in any of the configuration files, the library will try to guess an appropriate driver to use.

But as we don't know what's behind this guess, better suggest the user or admin to set it explicitly. As an example I put this in /etc/libao.conf:

Code:

# To make a setting at user level write ~/.libao.conf
# It will have precedence over this one, for the user in concern.
# To know more, type: "man libao.conf"
# This libao package includes following drivers:
# alsa
# esd
# pulse
# oss
default_driver=alsa