[SOLVED] Requests for -current (20151216)

Didier Spaier · 02-21-2016, 05:38 PM

Quote:

Originally Posted by ecoslacker

Please do not forget poppler-qt5 and texlive:

ftp://tug.org/historic/systems/texlive/

http://www.linuxquestions.org/questi...2/#post4928474

franzen · 02-22-2016, 12:35 AM

Quote:

Originally Posted by Didier Spaier

http://www.linuxquestions.org/questi...2/#post4928474

This should be discussed in a new thread, but in short:
texlive is far too big, everything needed to build the package would have to be shipped, too(several GBs). The chance i see(to late for 14.2 i assume) is, to build a custom texlive with about 50mb(tetex has about 37mb). This is not possible with the provided schemes(texlive-tetex-scheme has several hundred mbs), but with single packages provided by texlive(with drawbacks, e.g. cbfonts(greek) has nearly 70mb alone and can't be added as is comes).
The singel-packages have a corresponding source- and doc-packages, so the full texlive sourcetree wouldn't have to be shipped.

ReaperX7 · 02-22-2016, 05:15 AM

Yeah, TexLive, even if you grabbed the prebuilt online download is HUGE as a package. I've built TexLive on other distributions and packaged it on my own, and it's massive in size if you want coverage that works for packages. You could trim it maybe, but you're removing a lot of functionality equally.

ecoslacker · 02-22-2016, 10:32 AM

Quote:

Originally Posted by Didier Spaier

http://www.linuxquestions.org/questi...2/#post4928474

Sorry that was mean to be on SBo, not Slackware -current. My mistake.

Didier Spaier · 02-22-2016, 10:38 AM

No problem Eduardo. Have a good day.

ecd102 · 02-23-2016, 12:22 AM

cups-2.1.3-i586-1.txz doesn't run on 'real' Pentium 3.

When I try to start cups, I get:

Code:

# /etc/rc.d/rc.cups start
cups: unable to start scheduler.

This is because its cupsd uses SSE2 instruction, not supported by P3:

Code:

# uname -p
Pentium III (Coppermine)
# cupsd -f
Illegal instruction

Could you insert the following block right before './configure' of cups.SlackBuild and rebuild ?

Code:

# Set CFLAGS/CXXFLAGS
if [ "$ARCH" = "i586" ]; then
    export CFLAGS="-O2 -march=i586 -mtune=i686"
elif [ "$ARCH" = "s390" ]; then
    export CFLAGS="-O2"
elif [ "$ARCH" = "x86_64" ]; then
    export CFLAGS="-O2 -fPIC"
else
    export CFLAGS="-O2"
fi
export CXXFLAGS="$CFLAGS"

This solves the issue as I tried.

DarkVision · 02-23-2016, 10:51 AM

libcaca-0.99-beta19 will fix creating empty directories for /usr/lib64/jni and /usr/share/java even if java has been disabled. The package included in -current includes these empty directories which could be removed. The development version has some more fixes, have a look here.

orbea · 02-23-2016, 04:51 PM

Any chance /etc/asound.conf can be removed from alsa-lib and moved to the pulseaudio package? As far as I am aware its only needed if pulseaudio is used and not including it in alsalib would be quite considerate to those few who do not use pulseaudio so that they do not need to keep an empty version of the file or manually remove it from the alsa-lib slackbuild. Thanks!

franzen · 02-23-2016, 06:05 PM

minimal-lxc.template within /usr/share/lxc/templates/lxc-slackware lists "logrotate", but not "dcron". Logrotate is mostly useless without dcron, so i suggest to add dcron or remove logrotate from minimal-lxc.template.

volkerdi · 02-23-2016, 07:06 PM

Quote:

Originally Posted by orbea

Any chance /etc/asound.conf can be removed from alsa-lib and moved to the pulseaudio package? As far as I am aware its only needed if pulseaudio is used and not including it in alsalib would be quite considerate to those few who do not use pulseaudio so that they do not need to keep an empty version of the file or manually remove it from the alsa-lib slackbuild. Thanks!

You're going to need the pulseaudio package for libpulse anyway... unless you're recompiling all those things. In which case you should be able to handle keeping an empty asound.conf.

gmgf · 02-24-2016, 12:26 AM

libssh-0.7.3 (security and bugfix)

https://www.libssh.org/2016/02/23/li...ugfix-release/

https://red.libssh.org/attachments/d...h-0.7.3.tar.xz

also a new libssh2-1.7.0

https://www.libssh2.org/changes.html

https://www.libssh2.org/download/libssh2-1.7.0.tar.gz

USUARIONUEVO · 02-24-2016, 02:30 AM

linux-4.4.3 arrives in 2-3 days . nice patch set again. (137 patches)

https://www.mail-archive.com/linux-k...sg1084162.html

if some one want to test 4.4.3-rc1 , here is the patch set , donwload 4.4.2 and aply
https://www.kernel.org/pub/linux/ker...h-4.4.3-rc1.xz

GazL · 02-24-2016, 04:35 AM

https://www.mail-archive.com/linux-k...sg1084198.html

Quote:

It's in the list of patches I haven't gotten to yet, which is still over 200.

Looks like Greg is still playing catch-up. If he's doing about 100 or so each time, then it'll be 4.4.5 or .6 before we've caught up with everything.

titopoquito · 02-24-2016, 05:33 AM

The files README_CRYPT.TXT and README_LVM.TXT on the Slackware DVD contain info about setting up encrypted partitions. The given example might give a problem with newer cryptsetup (>=1.6.0) as far as I understand it. The standard encryption cypher has changed with that version from aes-cbc-essiv to aes-xts-plain64.

Quote:

From version 1.6.0 of cryptsetup onwards, aes-xts-plain64 is the default for LUKS

Source: https://gitlab.com/cryptsetup/crypts...curity-aspects See chapter 5.16

As far as I understand it, the key size is handled differently if you use xts - to get the desired key size you have to double it, so that a key size of 512 should mean the aes part gets 256 bit and the xts gets 256 bit, too. Using the old example lines I fear it would result in an 128 bit encryption.

Quote:

For key-size, you can use 128 bit (e.g. AES-128 with CBC), 256 bit (e.g. AES-256 with CBC) or 512 bit (e.g. AES-256 with XTS mode). You can do 64 bit (e.g. blowfish-64 with CBC), but anything below 128 bit has to be considered insecure today.

Source: https://gitlab.com/cryptsetup/crypts...curity-aspects, see chapter 6.13

Quote:

By default a 256 bit key-size is used. Note however that XTS splits the supplied key in half, so to use AES-256 instead of AES-128 you have to set the XTS key-size to 512.

Source: https://wiki.archlinux.org/index.php..._for_LUKS_mode

It would be nice if someone more familiar with this could take a look, if the instructions have to be reworked.

CTM · 02-24-2016, 06:34 AM

Quote:

Originally Posted by titopoquito

The files README_CRYPT.TXT and README_LVM.TXT on the Slackware DVD contain info about setting up encrypted partitions. The given example might give a problem with newer cryptsetup (>=1.6.0) as far as I understand it. The standard encryption cypher has changed with that version from aes-cbc-essiv to aes-xts-plain64.

As far as I understand it, the key size is handled differently if you use xts - to get the desired key size you have to double it, so that a key size of 512 should mean the aes part gets 256 bit and the xts gets 256 bit, too. Using the old example lines I fear it would result in an 128 bit encryption.

It would be nice if someone more familiar with this could take a look, if the instructions have to be reworked.

The instructions do need to be reworked, but the default cipher now used by cryptsetup (aes-xts-plain64 with a 256-bit key) should be fine. Attacks on AES, even AES-128, are still only theoretical (and are a long way from being practical in the foreseeable future), and although it's now a matter of public record that state actors are trying to find a realistic cryptographic attack could be mounted against AES, there's no evidence that any of them have.

Unless you work in a US government department and are trying to keep TS material safe, worrying about AES key lengths is ill-considered: if someone wanted to decrypt your disk, there are much easier ways of doing it than attempting to mount a complex cryptographic attack against a FIPS 140-2-approved cipher (they could attempt to insert a backdoor into cryptsetup, for instance, or hit you until you tell them your passphrase).