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

--enable-kernel=3.2

This tells Glibc to compile the library with support for 3.2 and later Linux kernels. Workarounds for older kernels are not enabled.

ponce

02-24-2019 11:31 AM

if I remember correctly I think it was set to 2.6.32 for compatibility with openvz.

it's true that there's a new openvz around based on kernel 3.10 but I'm not sure how many providers are supporting the newer version already (also because in their wiki is still labeled as "testing").

USUARIONUEVO

02-24-2019 02:15 PM

git-2.21

release notes --> http://lkml.iu.edu/hypermail/linux/k...2.3/00116.html
sources --> https://mirrors.edge.kernel.org/pub/...-2.21.0.tar.xz

Poprocks

02-24-2019 02:27 PM

Quote:

Originally Posted by dalacor (Post 5966122)

I recommend that N category be split into MX for email and everthing non email related stay in N.

Eh, I'm all for breaking some of the groups up (eg, I don't think there should be any KDE related libs in 'l') but I don't think this particular one is necessary. Email server packages are very discrete and you can just easily delete the 2 or 3 you don't need. slackpkg install-new will never try to re-add them to the system, unless a whole new email server package is introduced.

Didier Spaier

02-24-2019 02:44 PM

Packages series are a remnant of the floppy disk era anyway. Not that useful in 2019 IMO.

But you can still make your customized tag files without changing the default ones for Everybody (on which presumably Everybody won't agree), this is authorized by The Laws of Slackware ;)

LuckyCyborg

02-24-2019 03:15 PM

Quote:

Originally Posted by Didier Spaier (Post 5966396)

Packages series are a remnant of the floppy disk era anyway. Not that useful in 2019 IMO.

Mr. Didier, you know well that's a so big big lie, that's worth of mainstream UK politicians - then permit me to dare to differ. They are exceptionally useful right now.

The packages series are the last thing which keeps a bit of sanity for those not interested to install either KDE or XFCE, or even Emacs, while they are not interested to thinker with Slackware every night.

I am very sorry to disappoint you, but even I used Slackware since long years, still I do not started even one time an Apache webserver and the FTP servers never interested me. The mail servers interested me even less.

So, why I should have them installed in my computer, as simple user not interested to study the Slackware packages and their mighty dependencies, but just to use the Slackware as is? Aren't they just useless bloat for someone like me?

Didier Spaier

02-24-2019 03:52 PM

Hello

Well, this has been discussed so many times... Doing a full installation does not imply that you have to use all the software in it. Nobody does.

Let me give you a counter example. In Slint a full installation is mandatory, only KDE being optional. I have a blind friend who uses it and never starts X. He uses only ttys through a Braille device, mostly using Emacs and doing maths (he is a former math teacher), also listening music, reading books and doing some shell scripting. However he never complained that Slint ships software that he will never use. He just doesn't care.

As an aside there are other ways to strip down a Slackware system, e.g. you can install just the bare minimum, install slapt-get, include in /etc/slapt-get/slapt-getrc the repository http://slackware.uk/salix/x86_64/slackware-14.2/ as main SOURCE of package, run:
slapt-get --add-keys
slapt-get -u
slapt-get -i <package that you want to add>
and you will get this package and its dependencies.

This works 99.47% of the time ;)

Also, bear in mind that Pat guarantees that you won't miss any dependency *only* if you make a full installation.

I won't post again here on this topic in this thread, sorry to have contributed to derail it.

Best,

SCerovec

02-25-2019 03:04 AM

In the era of virtualization and containers there are ever more use cases where even the a, n and l series are over ones head.
Then this MX example. Also I find the KDE, KDEi and XFCE extremely useful and well thought out.

Floppies being obsolete, there really might be some reordering and reconsidering of the series down the road? Maybe, at least, for the time after the 15.0 hits the streets?

I for one would like to see bare(i'm short of better name right now) series with a minimal system able to only boot, install and be ssh-d into.

dalacor

02-25-2019 06:34 AM

I am fully aware that raising the issue of reviewing the install categories is a bit contentious as many people will disagree as to what application goes in which folder and what categories is considered necessary to run a modern system.

When I was looking at the n folder, I noticed that there were at least half a dozen to a dozen email programs. It's not a problem to install them but if you never use them, then it doesn't make sense to install them as it defeats the point of the categories. It just seemed to me that it should be in an Mx category because if you want to install a mail server/client you most likely would only want one installed.

I disagree that the categories should be viewed soley as from the floppy disk days. Being able to only install the bare minimum to run slackware plus the packages that you actually want is one of the things that I like most about Slackware in a age of software bloat. Because its a server running a filtering system, I don't need x, xap and kde etc. So I very much like the category concept.

It's certainly not a high priority agreed, but eventually reviewing the install categories and considering new categories or renaming/removing old categories should be looked at as computer usage has evolved quite considerably since these categories were created.

montagdude

02-25-2019 06:58 AM

Quote:

Originally Posted by SCerovec (Post 5966617)

I for one would like to see bare(i'm short of better name right now) series with a minimal system able to only boot, install and be ssh-d into.

It's not something available on the installer, but take a look at the LXC Slackware template. It contains a very minimal set of packages.

SCerovec

02-25-2019 09:13 AM

Quote:

Originally Posted by montagdude (Post 5966661)

It's not something available on the installer, but take a look at the LXC Slackware template. It contains a very minimal set of packages.

The point of running it as an actual install series (or supplying an tag for an equivalent install instead) is the actual use and purpose of such a feature.

And don't think x86 only ;)

Maybe Slackware could endorse and ship a tag-file of said package list?

bassmadrigal

02-25-2019 11:21 AM

Quote:

Originally Posted by LuckyCyborg (Post 5966407)

While it might be true that keeping package sets helps with people to uninstall things, what Didier stated wasn't a lie. Pat doesn't intend for them to be used that way.

Quote:

Originally Posted by volkerdi (Post 5766773)

Arguing about which series any particular package belongs in is even more pointless than having separate package series in the first place. Really, everything should just be dumped in one big package directory so that people don't get carried away with the idea that the divisions actually mean something.

Poprocks

02-25-2019 12:08 PM

Sometimes an inventor of something doesn't always understand how useful their invention is. Or the scope of its usefulness. I think package groups are an example of this. Mr. Volkerding may not have intended for them to be used and managed the way they are in practice, but the fact of the matter is that they are, and if they were cut, many, many, users would complain.

I don't think Mr. Volkerding will ultimately cut them out. It would violate the POLA (principle of least astonishment) which is an overarching principle I believe he takes much more seriously than any opinions he may hold on package groups.

bassmadrigal

02-25-2019 12:16 PM

Quote:

Originally Posted by Poprocks (Post 5966759)

I totally agree with this, he hasn't intended for them to be used this way, even if they are. I also don't think he opposes to them being used this way, but I don't think he cares to support people who think this is some form of dependency control within Slackware. Overall, I don't foresee him removing them, but I also don't see him going out of his way to change them to fit with requests people have on here.

But this is just my 2 cents...

igadoter

02-25-2019 12:38 PM

If things are to grow then they have to start their own life. No matter what was meant for them at the beginning. The diversity temporary/permanent is also well-known. Apache comes as I read somewhere from patches. So what was the meaning of package series now is of no importance. I was terrified by senseless pool in Debian - nightmare.

gmgf	02-25-2019 01:06 PM

libssh-0.8.7:

https://www.libssh.org/files/0.8/libssh-0.8.7.tar.xz

MarcT

02-26-2019 06:51 AM

Add initrd (or linux-firmware) functionality for packaging up CPU Microcode...?

How about enhancing "mkinitrd" to (optionally) package up CPU microcode and include it in the initrd? I think this is worthwhile since mitigations for vulnerabilities like Spectre/Meltdown may be included, and not all vendors issue BIOS/UEFI updates in a timely manner.

I know there is the "-P" option to include a pre-prepared CPU microcode archive, but there's no immediately obvious way of creating the required archive.
It would be handy if mkinitrd could detect the CPU type and package up the relevant microcode. Alternatively, perhaps the kernel-firmware package install script could create the relevant archives in /boot for Intel and AMD CPUs at least?

Example:

For AMD, I've been using this little script for years. I didn't write it, and I can't recall the original source. The resulting archive can be used with the -P switch, or be manually prepended to your initrd.

Code:

#! /bin/sh

set -x

set -e



LIB=/lib/firmware/amd-ucode/

TDIR=kernel/x86/microcode

CPIO=/boot/amd-ucode.cpio



echo "Create the $CPIO file from the $LIB directory of files"

rm -rf  /tmp/amd-ucode-cpio

mkdir -p /tmp/amd-ucode-cpio

cd      /tmp/amd-ucode-cpio

mkdir -p  $TDIR

find $LIB -type f -name \*bin | sort | xargs cat > $TDIR/AuthenticAMD.bin

find . | cpio --no-absolute-filenames -H newc -o -F $CPIO



#echo Remember to do:

#echo  cat $CPIO initrd.gz \> initrd.new

#echo ...and run "lilo", etc...                                                                                                                                                                                                                                                

exit

It works well, eg with my Ryzen 2700x I see:

Code:

root@deepthought:~# dmesg | grep microcode                                                                                                                                                                                                                                    

[    6.841445] microcode: microcode updated early to new patch_level=0x0800820b

[    6.842727] microcode: CPU0: patch_level=0x0800820b

[    6.843404] microcode: CPU1: patch_level=0x0800820b

[    6.844069] microcode: CPU2: patch_level=0x0800820b

[    6.844722] microcode: CPU3: patch_level=0x0800820b

[    6.845425] microcode: CPU4: patch_level=0x0800820b

[    6.846056] microcode: CPU5: patch_level=0x0800820b

[    6.846681] microcode: CPU6: patch_level=0x0800820b

[    6.847294] microcode: CPU7: patch_level=0x0800820b

[    6.847894] microcode: CPU8: patch_level=0x0800820b

[    6.848487] microcode: CPU9: patch_level=0x0800820b

[    6.849081] microcode: CPU10: patch_level=0x0800820b

[    6.849663] microcode: CPU11: patch_level=0x0800820b

[    6.850233] microcode: CPU12: patch_level=0x0800820b

[    6.850795] microcode: CPU13: patch_level=0x0800820b

[    6.851347] microcode: CPU14: patch_level=0x0800820b

[    6.851888] microcode: CPU15: patch_level=0x0800820b

Similarly, it updates the ucode on my older AMD Phenom CPU for which no BIOS update is available.

Thanks!

bassmadrigal

02-26-2019 08:59 AM

Quote:

Originally Posted by MarcT (Post 5967080)

How about enhancing "mkinitrd" to (optionally) package up CPU microcode and include it in the initrd?

--snip--

For AMD, I've been using this little script for years. I didn't write it, and I can't recall the original source. The resulting archive can be used with the -P switch, or be manually prepended to your initrd.

Note, I'm not suggesting we shouldn't do this since it doesn't apply to everything, but... AMD doesn't need initrds to load microcode. Theirs are included in the kernel-firmware package and will be loaded automatically on boot. Intel prevents distribution of their microcode, which is why there needs to be a separate mechanism to load it during the startup of the OS.

Code:

root@craven-moorhead:~# dmesg | grep microcode

[    7.210711] microcode: CPU0: patch_level=0x08001137

[    7.211358] microcode: CPU1: patch_level=0x08001137

[    7.212022] microcode: CPU2: patch_level=0x08001137

[    7.212661] microcode: CPU3: patch_level=0x08001137

[    7.213509] microcode: CPU4: patch_level=0x08001137

[    7.214230] microcode: CPU5: patch_level=0x08001137

[    7.214833] microcode: CPU6: patch_level=0x08001137

[    7.215425] microcode: CPU7: patch_level=0x08001137

[    7.216153] microcode: CPU8: patch_level=0x08001137

[    7.216808] microcode: CPU9: patch_level=0x08001137

[    7.217419] microcode: CPU10: patch_level=0x08001137

[    7.218062] microcode: CPU11: patch_level=0x08001137

[    7.218635] microcode: CPU12: patch_level=0x08001137

[    7.219290] microcode: CPU13: patch_level=0x08001137

[    7.220033] microcode: CPU14: patch_level=0x08001137

[    7.220664] microcode: CPU15: patch_level=0x08001137

[    7.221394] microcode: Microcode Update Driver: v2.2.

This is on 14.2 with 4.19.24 kernel built from Pat's config and the kernel-firmware-20181218_0f22c85 package.

cwizardone

02-26-2019 10:29 AM

OpenSSL-1.1.1b

Quote:

Latest News
Date
Item
26-Feb-2019
OpenSSL 1.1.1b is now available, including bug fixes
26-Feb-2019
OpenSSL 1.0.2r is now available, including bug and security fixes

https://www.openssl.org/

MarcT

02-26-2019 12:27 PM

Quote:

Originally Posted by bassmadrigal (Post 5967129)

Not true re AMD microcode being loaded automatically on boot. I have two AMD systems, one running Slackware-current and one running 14.2. Both are running Pat's stock kernels and neither update the microcode automatically despite there being an update available in /lib/firmware. I have to manually build the AMD cpio archive and add it to initrd.

What you show above is the original microcode version loaded by the BIOS/UEFI. There's no message about it being updated (early or late). Compare your output with mine - you're missing a line like this:

Code:

[ 6.841445] microcode: microcode updated early to new patch_level=0x0800820b

If a "late" update is done, you'd see a microcode entry with a "new patch_level=" message.

Now, it's possible yours is at the latest version, but I don't think it will update automatically if one becomes available.
You can try to force a "late" update by running:

Code:

echo 1 > /sys/devices/system/cpu/microcode/reload

...but there are some issues with "late" updates: For example if the ucode changes the CPU feature flags it can lead to a situation where flags which were advertised at boot are removed, or conversely extra flags are added; neither of which is well handled. Therefore "early" updates via the initrd are preferred.

More details in /usr/src/linux/Documentation/x86/microcode.txt which says the distribution should do it. Quote:

Quote:

Here's a crude example how to prepare an initrd with microcode (this is
normally done automatically by the distribution, when recreating the
initrd, so you don't really have to do it yourself. It is documented
here for future reference only).

Some further good info here: https://wiki.archlinux.org/index.php/microcode

alex14641

02-26-2019 02:44 PM

Xorg server:
Release notes: https://lists.x.org/archives/xorg-an...ry/002957.html
Source: https://xorg.freedesktop.org/archive...1.20.4.tar.bz2

dalacor

02-27-2019 03:18 AM

Perhaps thinking about it a different way would help. If you take Windows Server for example. When you install Windows Server, you install either core (no gui) or full (with gui). Then on top of that after you have installed Windows Server, you can install Roles such as active directory, DNS, DHCP, WSUS, WDS and so on.

Slackware does it better in that you can get rid of a lot more bloat by removing e, f, k, kde, tcl etc.

I think of a,d l and n as basically windows server core and ap as features that I can install. However a lot of Server roles seem to be in n by default eg mx servers.

I agree with Pat on one point. It's pointless arguing what should go in a, ap, d, l etc. And it's not a high priority. But I still see value in a core, full install and adding additional roles in the way windows server does it.

Anyway, if the developer sees this, he can decide what he wants to do if anything and I will be happy with whatever he comes up with as long as one can still do a bare minimum install as it were as many users like myself don't need a gui desktop server install.

Didier Spaier

02-27-2019 04:12 AM

@dalacor: Salix does something similar to what you suggest, with a choice between:

Core (minimal console system)
Basic (minimal graphical environment)
Full (everything)

The content of Full depends on the edition (graphical environment), cf.: https://github.com/gapan/iso-creation

I suggest to not bug Pat with requests for doing something similar, but volunteers could just set up a repository of customized tag files (on github, gitlab, whatever), that interested users could download, store on an USB stick, then use that during installation instead of the standard tag files, as the Slackware installer allows.

Thom1b

02-27-2019 04:29 AM

postfix 3.3.3 is released.
https://de.postfix.org/ftpmirror/off...x-3.3.3.tar.gz
https://de.postfix.org/ftpmirror/off....3.tar.gz.gpg2

SCerovec

02-27-2019 04:47 AM

Maybe a dedicated thread for tag files for various Slackware roles is in order?

allend

02-27-2019 07:19 AM

Quote:

many users like myself don't need a gui desktop server install

Quote:

Maybe a dedicated thread for tag files for various Slackware roles is in order?

Please! I suggest a poll, "Do you have an interest in Slackware tag files? Yes/No", to test what proportion of the community actually thinks this is important.
Personally, my answer is a flat no. But I am not trying to provision containers or run on limited hardware or limit attack surface or be a hairy chested CLI user.

bassmadrigal

02-27-2019 09:25 AM

Quote:

Originally Posted by MarcT (Post 5967220)

Code:

[ 6.841445] microcode: microcode updated early to new patch_level=0x0800820b

I know I checked this when I first read of Ryzen microcode updates being pushed for Spectre and I'm pretty sure that I found that my microcode was updated based on what was in the linux-firmware package (but this was a long time ago, and my memory isn't what it used to be). I'm guessing the microcode was updated when ASRock pushed out their latest firmware update for my board so it now isn't being loaded by the kernel (or possibly some kernel change that broke late loading). I'll have to keep an eye on this. According to Gentoo, I'm running the latest microcode for my CPU.

saahriktu

02-27-2019 01:31 PM

Error:

Code:

make[1]: Entering directory '/tmp/x11-build/xorg-server-1.20.4/config'

  CC      udev.lo

udev.c: In function ‘device_added’:

udev.c:126:49: error: implicit declaration of function ‘major’ [-Werror=implicit-function-declaration]

        if (xf86_find_platform_device_by_devnum(major(devnum), minor(devnum)))

                                                ^~~~~

udev.c:126:49: warning: nested extern declaration of ‘major’ [-Wnested-externs]

udev.c:126:64: error: implicit declaration of function ‘minor’; did you mean ‘mknod’? [-Werror=implicit-function-declaration]

        if (xf86_find_platform_device_by_devnum(major(devnum), minor(devnum)))

                                                                ^~~~~

                                                                mknod

udev.c:126:64: warning: nested extern declaration of ‘minor’ [-Wnested-externs]

cc1: some warnings being treated as errors

make[1]: *** [Makefile:686: udev.lo] Error 1

Patch:

Code:

diff -ur xorg-server-1.20.4/config/udev.c xorg-server-1.20.4_patched/config/udev.c

--- xorg-server-1.20.4/config/udev.c    2019-02-26 22:28:50.000000000 +0300

+++ xorg-server-1.20.4_patched/config/udev.c    2019-02-27 20:36:31.347077490 +0300

@@ -30,6 +30,7 @@

 #include <libudev.h>

 #include <ctype.h>

 #include <unistd.h>

+#include <sys/sysmacros.h>

 

 #include "input.h"

 #include "inputstr.h"

volkerdi

02-27-2019 04:46 PM

Quote:

Originally Posted by saahriktu (Post 5967770)

Error:

Code:

make[1]: Entering directory '/tmp/x11-build/xorg-server-1.20.4/config'

  CC      udev.lo

udev.c: In function ‘device_added’:

udev.c:126:49: error: implicit declaration of function ‘major’ [-Werror=implicit-function-declaration]

        if (xf86_find_platform_device_by_devnum(major(devnum), minor(devnum)))

                                                ^~~~~

udev.c:126:49: warning: nested extern declaration of ‘major’ [-Wnested-externs]

udev.c:126:64: error: implicit declaration of function ‘minor’; did you mean ‘mknod’? [-Werror=implicit-function-declaration]

        if (xf86_find_platform_device_by_devnum(major(devnum), minor(devnum)))

                                                                ^~~~~

                                                                mknod

udev.c:126:64: warning: nested extern declaration of ‘minor’ [-Wnested-externs]

cc1: some warnings being treated as errors

make[1]: *** [Makefile:686: udev.lo] Error 1

Patch:

Code:

diff -ur xorg-server-1.20.4/config/udev.c xorg-server-1.20.4_patched/config/udev.c

--- xorg-server-1.20.4/config/udev.c    2019-02-26 22:28:50.000000000 +0300

+++ xorg-server-1.20.4_patched/config/udev.c    2019-02-27 20:36:31.347077490 +0300

@@ -30,6 +30,7 @@

 #include <libudev.h>

 #include <ctype.h>

 #include <unistd.h>

+#include <sys/sysmacros.h>

 

 #include "input.h"

 #include "inputstr.h"

No problem here. I've verified that the code calling major() and minor() is not #ifdefed out.

saahriktu

02-27-2019 08:28 PM

Quote:

Originally Posted by volkerdi (Post 5967856)

No problem here. I've verified that the code calling major() and minor() is not #ifdefed out.

However, the package build without this patch may fails (this is a fatal error). I was able to get the package only after adding this patch. Before that, every time I got the xorg-server.failed file instead of a package.

teoberi

02-27-2019 11:00 PM

Postfix 3.4.0

SCerovec

02-28-2019 06:08 AM

Quote:

Originally Posted by allend (Post 5967595)

https://www.linuxquestions.org/quest...es-4175649249/

gaaslight

02-28-2019 02:48 PM

gtk+3.0 wayland-backends

I was wondering if during the next development cycle of Slackware 15, gtk-3.0 gets upgraded, could it be built with wayland-backends enabled? This would not require wayland itself, only wayland-protocols and wayland-egl, both are in SBO.

willysr

02-28-2019 05:38 PM

It's already using the latest GTK+3

gaaslight

02-28-2019 09:30 PM

Quote:

Originally Posted by willysr (Post 5968412)

It's already using the latest GTK+3

Then can it be rebuilt?

Code:

CFLAGS="$SLKCFLAGS" \

./configure \

  --prefix=/usr \

  --libdir=/usr/lib${LIBDIRSUFFIX} \

  --sysconfdir=/etc \

  --mandir=/usr/man \

  --enable-xkb \

  --enable-x11-backend \

  --enable-wayland-backend \

  --build=$ARCH-slackware-linux || exit 1

orbea

02-28-2019 11:53 PM

Is there any reason to not update to eudev-3.2.7? It resolves a trivial, but annoying issue here where when I use my Sony Playstation3 Controller with a program that uses libinput (i.e. wine) it prints this for every button press filling the logs with garbage.

Code:

(EE) libinput bug: Event for missing capability CAP_POINTER on device "Sony PLAYSTATION(R)3 Controller"

For more info please see this libinput issue where it was debugged.

https://gitlab.freedesktop.org/libin...put/issues/244

elyk	03-01-2019 01:41 AM

I'd like to have binutils (libbfd, in particular) built with --enable-targets=all instead of how it's currently set up. This will make objdump and other tools more capable of picking apart various other executables and libraries.

gmgf	03-01-2019 03:24 AM

gdk-pixbuf-2.38.1:

http://ftp.gnome.org/pub/gnome/sourc...uf-2.38.1.news
http://ftp.gnome.org/pub/gnome/sourc...-2.38.1.tar.xz

libqmi-1.22.2:

https://cgit.freedesktop.org/libqmi/log/?h=qmi-1-22
https://www.freedesktop.org/software...-1.22.2.tar.xz

saahriktu

03-01-2019 03:55 AM

UnZip 6.10c08+ BETA with ICONV=1 option.
http://antinode.info/ftp/info-zip/unzip610c08a_l_sM.zip
This will help get rid of this bug:

Quote:

Broken filenames when unzip archive with non-latin character

saahriktu

03-01-2019 05:36 AM

libvdpau 1.2
https://gitlab.freedesktop.org/vdpau...au-1.2.tar.bz2
https://gitlab.freedesktop.org/vdpau....2.tar.bz2.sig

Nobby6

03-01-2019 05:41 AM

New BIND releases are available - BIND 9.11.6, 9.12.4

9.11.6: https://ftp.isc.org/isc/bind9/9.11.6...nd-9.11.6.html
9.12.4: https://ftp.isc.org/isc/bind9/9.12.4...nd-9.12.4.html

MarcT

03-01-2019 01:20 PM

Anyone know what causes this, from ./configure (autoconf), compiling libaacs in -current:

Code:

configure: WARNING:

***

*** The config script /usr/bin/libgcrypt-config was

*** built for x86_64-slackware-linux-gnu and thus may not match the

*** used host x86_64-pc-linux-gnu.

*** You may want to use the configure option --with-libgcrypt-prefix

*** to specify a matching config script.

***

ponce

03-01-2019 02:00 PM

Quote:

Originally Posted by MarcT (Post 5968765)

Anyone know what causes this, from ./configure (autoconf), compiling libaacs in -current:

Code:

configure: WARNING:

***

*** The config script /usr/bin/libgcrypt-config was

*** built for x86_64-slackware-linux-gnu and thus may not match the

*** used host x86_64-pc-linux-gnu.

*** You may want to use the configure option --with-libgcrypt-prefix

*** to specify a matching config script.

***

maybe this is not the proper topic, you better open a new one...

BTW, I don't know which SlackBuild you are using but libaacs from SBo seems to build fine for me on slackware64-current.

USUARIONUEVO

03-01-2019 05:03 PM

Hi , after last eydev update i see this on dmesg output

Quote:

specified group 'kvm' unknown

Any idea?

Thanks!

orbea

03-01-2019 05:09 PM

Quote:

Originally Posted by USUARIONUEVO (Post 5968842)

Hi , after last eydev update i see this on dmesg output

Any idea?

Thanks!

Seems related.

https://github.com/systemd/systemd/issues/6360

Edit: The easiest method seems to be just add a 'kvm' group...

USUARIONUEVO

03-01-2019 06:10 PM

Quote:

Originally Posted by orbea (Post 5968845)

Seems related.

https://github.com/systemd/systemd/issues/6360

Edit: The easiest method seems to be just add a 'kvm' group...

Yes , groupadd kvm , stop messages.

Thanks!

Nobby6

03-01-2019 08:50 PM

Quote:

Originally Posted by teoberi (Post 5967998)

Postfix 3.4.0

Caution! this requires openssl later than 1.0.2

montagdude

03-01-2019 09:03 PM

Quote:

Originally Posted by USUARIONUEVO (Post 5968855)

Yes , groupadd kvm , stop messages.

Thanks!

Shouldn't be an issue now anyway.

Code:

Fri Mar  1 23:44:12 UTC 2019

a/eudev-3.2.7-x86_64-2.txz:  Rebuilt.

  Don't require kvm group.

USUARIONUEVO

03-02-2019 07:40 PM

xdm-1.1.12

CHANGELOG --> https://lists.x.org/archives/xorg-an...ch/002959.html
SOURCES --> https://xorg.freedesktop.org/archive...1.1.12.tar.bz2

saahriktu

03-03-2019 05:33 AM

Python-2.7.16
https://www.python.org/ftp/python/2....-2.7.16.tar.xz

All times are GMT -5. The time now is 04:11 PM.

Page 60 of 197

Show 50 post(s) from this thread on one page