LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (https://www.linuxquestions.org/questions/slackware-14/)
-   -   Requests for -current (14.2-->15.0) (https://www.linuxquestions.org/questions/slackware-14/requests-for-current-14-2-15-0-a-4175620463/)

chemfire 04-29-2021 10:44 AM

Quote:

Originally Posted by Didier Spaier (Post 6246204)
Thanks for pointing this out. So the choice is between not including this flag when building the python3 Slackware package or let these users rebuild python3 without it.

I am not sure actually, a little more reading and this only affects linking libpython to libpython. So doing things like hooking calls into glibc or other libraries should still work. It might not actually impact much besides some python instrumenting stuff; which I would guess is a much smaller use case.

Might be good to do some tests though.

MDKDIO 04-29-2021 01:43 PM

Quote:

Originally Posted by EdGr (Post 6246224)
That won't solve the problem. The theme is really multiple themes that look alike but are implemented completely differently: a GTK 2 theme, a GTK 3 theme, and window manager themes.
Ed

Ok, thanks for the information Ed!

upnort 04-29-2021 05:35 PM

Pat,

Proposed patch for rc.S to create /tmp directories only when needed. I noticed when creating an X-less system.

Code:

--- /tmp/rc.S        2021-04-29 17:29:45.498905886 -0500
+++ /tmp/rc.S.new        2021-04-29 17:30:06.996646502 -0500
@@ -397,13 +397,16 @@
 fi
 
 # Create /tmp/{.ICE-unix,.X11-unix} if they are not present:
-if [ ! -e /tmp/.ICE-unix ]; then
-  mkdir -p /tmp/.ICE-unix
-  chmod 1777 /tmp/.ICE-unix
-fi
-if [ ! -e /tmp/.X11-unix ]; then
-  mkdir -p /tmp/.X11-unix
-  chmod 1777 /tmp/.X11-unix
+if [ "$(which X 2>/dev/null)" != "" ]; then
+  # X is installed.
+  if [ ! -e /tmp/.ICE-unix ]; then
+    mkdir -p /tmp/.ICE-unix
+    chmod 1777 /tmp/.ICE-unix
+  fi
+  if [ ! -e /tmp/.X11-unix ]; then
+    mkdir -p /tmp/.X11-unix
+    chmod 1777 /tmp/.X11-unix
+  fi
 fi
 
 # Create a fresh utmp file:


Nobby6 04-30-2021 12:21 AM

Quote:

Originally Posted by allend (Post 6246203)
My guess a problem in pushing updates to the mirrors. My normally reliable local mirror has problems e.g. versions of both the 5.10.32 and 5.10.33 kernel in the slackware64/a directory. I resorted to using http://ftp.osuosl.org/pub/slackware/...are64-current/ as the mirror to recover.


yeah, I've had the odd issue over time, been mirroring slackware for 15 years, mirror rsync logs goes back only 10 years, and not once have they been imported till last night, was the only thing that seemed different, I guess a later rsync will clean them up if they aren't supposed to be there or upstream mirror re adjusts their acl's, they dont look nefarious so I'm not bothered, just curious.

As for two kernels, did you try again right after, maybe it was in middle of sync? Although I use delete before, many dont.

elyk 04-30-2021 02:23 AM

libgtop contains a /usr/info/dir that clobbers whatever install-info does.

mumahendras3 04-30-2021 03:41 PM

Hi Mr. Volkerding, it seems the wg-quick script (from wireguard-tools) uses resolvconf (a program name) for some of its operation. I don't know much about this to give a good recommendation, but I found resolvconf being provided by openresolv which is available in slackbuilds.org here: https://slackbuilds.org/repository/1...rk/openresolv/

After installing that, wg-quick works as expected (at least for my very simple use case).

Also, I think wg and wg-quick needs to be moved to /usr/sbin since they require root permission. But, I don't use wireguard-tools extensively so I'm probably wrong about this.

Thanks!

EdGr 04-30-2021 06:47 PM

Don't use a percent character in a filename in the repository
 
The percent character gets translated *twice* by wget over HTTPS.

Code:

% wget https://mirrors.slackware.com/slackware/slackware64-current/source/l/qt5/patches/qtwebengine-everywhere-src-5.15.2-%25231904652.patch.gz
--2021-04-30 16:31:02--  https://mirrors.slackware.com/slackware/slackware64-current/source/l/qt5/patches/qtwebengine-everywhere-src-5.15.2-%25231904652.patch.gz
Resolving mirrors.slackware.com (mirrors.slackware.com)... 207.223.116.213
Connecting to mirrors.slackware.com (mirrors.slackware.com)|207.223.116.213|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1653 (1.6K) [application/x-gzip]
Saving to: ‘qtwebengine-everywhere-src-5.15.2-#1904652.patch.gz’

qtwebengine-everywh 100%[===================>]  1.61K  --.-KB/s    in 0s     

2021-04-30 16:31:02 (676 MB/s) - ‘qtwebengine-everywhere-src-5.15.2-#1904652.patch.gz’ saved [1653/1653]

% ls -l
total 4
-rw-r--r-- 1 ed users 1653 Feb  8 13:44 qtwebengine-everywhere-src-5.15.2-#1904652.patch.gz

The original name was qtwebengine-everywhere-src-5.15.2-%231904652.patch.gz
Ed

jwoithe 04-30-2021 07:13 PM

Request: add PyQtWebEngine since it's been split out of PyQt
 
While Slackware64 current includes QtWebEngine, PyQtWebEngine is not present. This seems a little odd given that the coverage of the installed components of Qt5 by the installed PyQt5 is otherwise mostly complete. A note on the PyQy website says:
Quote:

PyQt-WebEngine is a set of Python bindings for The Qt Company's Qt WebEngine libraries. ... Prior to PyQt5 v5.12 these bindings were part of PyQt itself.
Thus PyQtWebEngine would have been included with earlier versions of PyQt5. However, with the current versions it must be provided separately.

Slackware64 current does have PyQtWebKit, but it appears that this is regarded as deprecated in favour of QtWebEngine by Qt. See for example, the second comment in the thread at https://forum.qt.io/topic/55504/anyo...e-of-qt-webkit. It therefore seems prudent to add PyQtWebEngine to Slackware as it will be used by more and more software if QtWebKit/PyQtWebKit is indeed deprecated.

There's a SlackBuild script at https://slackbuilds.org/repository/1...PyQtWebEngine/ which I expect could be adapted for Slackware current. There doesn't appear to be much required in the way of changes other than to the PyQtWebEngine version number.

atelszewski 05-01-2021 04:50 AM

Hi,

Quote:

Originally Posted by mumahendras3 (Post 6246657)
Hi Mr. Volkerding, it seems the wg-quick script (from wireguard-tools) uses resolvconf (a program name) for some of its operation. I don't know much about this to give a good recommendation, but I found resolvconf being provided by openresolv which is available in slackbuilds.org here: https://slackbuilds.org/repository/1...rk/openresolv/

After installing that, wg-quick works as expected (at least for my very simple use case).

Also, I think wg and wg-quick needs to be moved to /usr/sbin since they require root permission. But, I don't use wireguard-tools extensively so I'm probably wrong about this.

Thanks!

I'm about to setup Wireguard over this weekend.
I'll try to re-confirm what you've said, especially when it comes to openresolv.
Sureley, the commands should go to sbin, as you're correct they require root.

I tried wg-quick on Ubuntu sometime ago.
It worked no problems there.

If openresolv is really required, then I second it's addition.
Wiregurad promise is to be ultra easy to set up, and it is indeed with wg-quick, so my opinion is that everything required for wg-quick to work out of the box should be included.

--
Best regards,
Andrzej Telszewski

marav 05-01-2021 06:11 AM

Quote:

Originally Posted by EdGr (Post 6246723)
The percent character gets translated *twice* by wget over HTTPS.

https://github.com/giuseppe/wget

I think, probably that :
The error in src/utils.c, which was already issued (the ending with the double brackets) :
Code:

  /* If the FILE itself doesn't exist, return it without
    modification. */
  if (!file_exists_p (file))

I compiled wget from its source tree, and this seems to be fixed
Code:

15step :: » /usr/local/bin/wget https://mirrors.slackware.com/slackware/slackware64-current/source/l/qt5/patches/qtwebengine-everywhere-src-5.15.2-%25231904652.patch.gz
--2021-05-01 13:05:14--  https://mirrors.slackware.com/slackware/slackware64-current/source/l/qt5/patches/qtwebengine-everywhere-src-5.15.2-%25231904652.patch.gz
Résolution de mirrors.slackware.com (mirrors.slackware.com)… 207.223.116.213
Connexion à mirrors.slackware.com (mirrors.slackware.com)|207.223.116.213|:443… connecté.
requête HTTP transmise, en attente de la réponse… 200 OK
Taille*: 1653 (1,6K) [application/x-gzip]
Sauvegarde en*: « qtwebengine-everywhere-src-5.15.2-%231904652.patch.gz »

qtwebengine-everywhere-src-5.15.2-%231904 100%[======================================================================================>]  1,61K  --.-KB/s  in 0s     

2021-05-01 13:05:15 (25,6 MB/s) — « qtwebengine-everywhere-src-5.15.2-%231904652.patch.gz » sauvegardé [1653/1653]

Code:

15step :: ~ » ls qt*
qtwebengine-everywhere-src-5.15.2-%231904652.patch.gz


EdGr 05-01-2021 11:57 AM

Quote:

Originally Posted by marav (Post 6246843)

That repository was last updated in 2014.

I submitted a bug report on wget https://savannah.gnu.org/bugs/index.php?60494

Pat may want to rename the file if the wget bug does not get fixed soon.
Ed

marav 05-01-2021 12:10 PM

Quote:

Originally Posted by EdGr (Post 6246949)
That repository was last updated in 2014.

I submitted a bug report on wget https://savannah.gnu.org/bugs/index.php?60494

Pat may want to rename the file if the wget bug does not get fixed soon.
Ed

My bad
I missed this detail
My error was unfortunately confirmed by the fact that the error probably did not exist before ...

saxa 05-01-2021 12:11 PM

librsvg-2.50.5
https://download.gnome.org/sources/l...-2.50.5.tar.xz

richarson 05-01-2021 12:33 PM

Bumping request for sof-firmware
 
Quote:

Originally Posted by richarson (Post 6198767)
Hello everyone!

This is my second post to LQ so forgive any newbie mistakes :)

I recently bought a new notebook (Lenovo IdeaPad 5 15M) and had some audio issues.

Researching the web I found this laptop's audio subsystem requires sof-firmware to work, which is available from https://github.com/thesofproject/sof-bin/

Based on Fedora's specfile and Arch's PKGBUILD I made a simple SlackBuild (https://github.com/richarson/slackbu...s/sof-firmware) but having sof-firmware ins stcok Slackware would be great (feel free to preuse/reuse/whatever my SlackBuild).

Thanks in advance!


PS: This Fedora bugzilla issue has way more info than needed: https://bugzilla.redhat.com/show_bug.cgi?id=1772498

Bumping my old request in case Pat missed it.

Summary: sof-firmware is needed in some Lenovo laptops to make speakers and mic work. There are sources (https://github.com/thesofproject/sof) and binaries (https://github.com/thesofproject/sof-bin). I made a slackbuild that repackages the binaries, as compiling the sources is pretty overkill for me and other distros (Arch, Fedora, openSUSE) also repackage the binaries.

More info:
https://www.linuxquestions.org/quest...ml#post6199638
https://www.linuxquestions.org/quest...5/#post6167184

I'm working on an update to sof-firmware 1.7 but the structure of the source package changed a lot so I'll have to rework my slackbuild (https://github.com/richarson/slackbu...s/sof-firmware).

saxa 05-01-2021 01:26 PM

at-spi2-core-2.40.1
https://download.gnome.org/sources/a...-2.40.1.tar.xz

opty 05-01-2021 04:55 PM

source/installer/ChangeLog.txt:

Code:

Fri Apr 30 17:30:36 UTC 2021
  setup: filter partition list through sort | uniq to prevent duplicates.

sort -u?

franzen 05-01-2021 10:06 PM

In case my mails didn't arrive, please consider updating texlive -> 2021, here it is:
https://ctan.net/systems/texlive/Sou...-source.tar.xz
http://slackware.schoepfer.info/slac...-210418.tar.xz
http://slackware.schoepfer.info/slac...ve/texlive.tar

Some infos to the build changes,
-texmf-base is now named YYMMDD, rather than YYYY.YYMMDD
-building against system poppler/xpdf isn't possible anymore by upstream
-removed unnecessary LD_LIBRARY_PATH and texmf.cnf adjustments before the build, which seems was needed some releases ago
-added some fixes by upstream after the release
-removed tabu.sty workaround for doxygen, as doxygen is now build without docs
-adjusted configure-options to make "make check" work

sombragris 05-02-2021 02:15 PM

sip >= 5.x

I use eric6 for python and the latest version requires sip >= 5.0. I understand that sip after 4.x no longer has standalone releases. Would it be possible to upgrade it to the latest version, either at about this time or after release?

I think source can be grabbed from this link (see the last file, a tarball)

https://pypi.org/project/sip/#files

Thanks!

Pixxt 05-02-2021 09:17 PM

Vulkan 1.2.177

https://github.com/KhronosGroup/Vulkan-Headers

Nobby6 05-02-2021 10:22 PM

p/mariadb-10.6.0-x86_64-1.txz WTF?

"The MariaDB Foundation is pleased to announce the availability of MariaDB 10.6.0, the first alpha release in the new MariaDB 10.6 development series."

marav 05-03-2021 03:40 AM

Quote:

Originally Posted by Nobby6 (Post 6247406)
p/mariadb-10.6.0-x86_64-1.txz WTF?

"The MariaDB Foundation is pleased to announce the availability of MariaDB 10.6.0, the first alpha release in the new MariaDB 10.6 development series."

Probably because of this :
Code:

Mon Apr 12 20:07:12 UTC 2021
I'm going to go ahead and call this a beta even though there's still no fix
for the illegal instruction issue with 32-bit mariadb. But there should be
soon

And :
Code:

  This update fixes the illegal instruction regession on 32-bit with processors
  that do not support SSE4.1 instructions.
  Thanks to Noel and Charlie Wilder for reporting the issue upstream
  and Matteo Bernardini for helping with the debugging.
  And of course, thanks to the MariaDB upstream developers. :-)


drgibbon 05-03-2021 06:49 AM

Could we perhaps have gcc built with support for JIT*, in anticipation of Emacs 28? :)

*There's some packaging notes on that page about having to build twice with and without '--enable-host-shared' (basically once for JIT with --enable-host-shared and --enable-languages=jit, and once with just --enable-languages=all).

Nobby6 05-03-2021 06:57 AM

Quote:

Originally Posted by marav (Post 6247460)
Probably because of this :
Code:

Mon Apr 12 20:07:12 UTC 2021
I'm going to go ahead and call this a beta even though there's still no fix
for the illegal instruction issue with 32-bit mariadb. But there should be
soon



Perhaps, although 10.5.10 is imminent in the stable tree, I have a copy, so I expect it publicly released very, very soon ;)
and well I guess -current still technically is a pre production with no guarantees, we all know the risks.

ponce 05-03-2021 07:08 AM

I was waiting for it too but unfortunately it hasn't even been tagged yet in their git

https://github.com/MariaDB/server/releases

saxa 05-03-2021 09:53 AM

adwaita-icon-theme-40.1
https://download.gnome.org/sources/a...me-40.1.tar.xz

Skaendo 05-03-2021 02:37 PM

Is the final conformation of the "Basic Network Setup" in the installer really needed?

Just seems like a extra step for nothing really.

atelszewski 05-03-2021 03:00 PM

Wireguard, openresolv
 
Hi,

I tested wg-quick with and without openresolv.

It will work properly in both cases, provided that the client configuration does not request setting up DNS in /etc/resolv.conf, with the DNS = X.X.X.X directive.

That is, wg-quick uses openresolv to add entry to /etc/resolv.conf if the client configuration file has DNS directive.

I have nothing against adding openresolv to Slackware.
That being said, if it's added, then IMO NetworkManager should be configured to use it by default.
This should avoid issues should the users use openresolv and NM at the same time.

I did a bit of testing and indeed when bringing up WG interface, the DNS from WG config file replaces the ones from /etc/resolv.conf. When the WG interface is torn down, the previous entry in /etc/resolv.conf is restored. Whether this is exactly the expected behaviour remains to be discussed.

I use NM to configure the main interface.

On a side note, NM has native support for Wireguard.

--
Best regards,
Andrzej Telszewski

marav 05-03-2021 03:19 PM

Quote:

Originally Posted by Nobby6 (Post 6247406)
p/mariadb-10.6.0-x86_64-1.txz WTF?

"The MariaDB Foundation is pleased to announce the availability of MariaDB 10.6.0, the first alpha release in the new MariaDB 10.6 development series."

Code:

testing/packages/mariadb-10.6.0-x86_64-1.txz:  Upgraded.
  Since this is still considered alpha and not production ready, we'll put it
  in /testing for now. Unless you're using an Atom (or other 32-bit processor
  affected by the illegal instruction issue) it's probably best to stick with
  mariadb-10.5.9.

:-)

cycojesus 05-04-2021 03:12 AM

As noted in the dedicated thread [ https://www.linuxquestions.org/quest...cs-4175694634/ ] future Emacs will require libgccjit. It would be nice to have it now [ https://gcc.gnu.org/onlinedocs/jit/i...he-jit-library ]

HQuest 05-04-2021 06:24 AM

Please undo distribution of httpd 2.4.47. It contains a regression bug and was pulled from the release after the vote.

https://lists.apache.org/x/thread.ht....apache.org%3E

Quote:

Hi all, as you probably have noticed, the 2.4.47 has been distributed on mirrors but not announced, neither on your favorite ML, nor on the official httpd.apache.org website. The reason is a very last minute regression discovered a few hours before the announcement. So, as the 2.4.32 release in March 2018, this 2.4.47 release will never be officially announced. A fix for the regression has already been proposed on trunk (r1889341). It should be reviewed and tested and, if agreed, backported to 2.4.x. So, I propose to give a little time for all this to occur and I already plan a new T&R on Sunday May 16, 2021, hoping for a successful release on Sunday May 23 or Monday May 24.

Nobby6 05-04-2021 06:50 AM

Quote:

Originally Posted by HQuest (Post 6247815)
Please undo distribution of httpd 2.4.47. It contains a regression bug and was pulled from the release after the vote.

https://lists.apache.org/x/thread.ht....apache.org%3E

Its in rare circumstances, most people wont be hit by it evident by no one including myself picked it up during T&R testing, so nothing to panic about.

-current runs fine with this version, and it has not been pulled, its still available on mirrors, just not being announced.

2.4.48 will be released (if passes) on May 23 or 24

niksoggia 05-04-2021 08:09 AM

I like SCHED_AUTOGROUP
 
Quote:

Originally Posted by GazL (Post 6243309)
Probably not a bad idea, especially as there seems to be a parameter to disable it at boot-time but not one to enable it.

It looks like SCHED_AUTOGROUP is on by default for "make defconfig":
find arch/*/configs/ -type f -exec grep -F CONFIG_SCHED_AUTOGROUP {} +

I have a FX6300/990FX 16GB PC, my root and home are on a SSD but I also have a WD80EZAZ where I store backups and big disk images for my VM's.
It's still a decent system and I use it daily. I hope ASMedia now sells better SATA silicon to AMD, but that's what I have to deal with now.
During heavy disk I/O on the rotating disk (e.g. backing up big files) Mate DE becomes irresponsive, even if the CPU's are mostly idle.
Qemu doesn't care too much, but VirtualBox guests that do a lot of I/O are always unusable (I can't imagine running them during a backup).

A few days ago I decided to give autogroup a try.
VirtualBox is still definitely slower than Qemu, but it went from unusable to slow, and this is a colossal improvement for me.
Heavy rotating disk I/O also no longer hangs my DE.
I got used pretty quickly to this new smoothness. And I like it to the point that I can now easily notice when autogroup is disabled or not.

Here is a silly benchmark I just made:
cd /dev/shm/linux-5.10.34 && make mrproper defconfig && time make -j6 all

autogroup on:
real 6m56,369s
user 36m46,422s
sys 3m19,560s

autogroup off:
real 6m54,400s
user 36m43,876s
sys 3m13,808s

It is a half percent penalty ("real" is 6m 48s slower every 24 hours of kernel compilation).
Unless you mine crypto currencies with your CPU, I think autogroup is desirable.
GazL is right: being able to disable it is much better than not having it at all.

Petri Kaukasoina 05-04-2021 08:41 AM

Quote:

Originally Posted by niksoggia (Post 6247839)
During heavy disk I/O on the rotating disk (e.g. backing up big files) Mate DE becomes irresponsive, even if the CPU's are mostly idle.

Which io scheduler do you use? bfq makes wonders to the rotating disk. Append
Code:

scsi_mod.use_blk_mq=1
to the kernel command line and add this as /etc/udev/rules.d/55-disk-scheduler.rules
Code:

ACTION=="add|change", KERNEL=="sd[a-z]|mmcblk[0-9]*|nvme[0-9]*", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="mq-deadline"
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="bfq"

SCHED_AUTOGROUP only works on cpu scheduling, so it seems strange you see what you see when you say that the cpus are mostly idle.

GazL 05-04-2021 09:14 AM

Quote:

Originally Posted by niksoggia (Post 6247839)
GazL is right: being able to disable it is much better than not having it at all.

It provides both options, is all I'm saying. Personally, I'll be disabling it should this change be made. When I investigated autogroup I concluded I'm better off without it.


P.S.
I always run intensive background workloads under:
chrt -i 0 ionice -c3

Keeps everything nice and responsive.

saxa 05-04-2021 10:11 AM

adwaita-icon-theme-40.1.1
https://download.gnome.org/sources/a...-40.1.1.tar.xz

niksoggia 05-04-2021 11:36 AM

1 Attachment(s)
Quote:

Originally Posted by Petri Kaukasoina (Post 6247853)
SCHED_AUTOGROUP only works on cpu scheduling, so it seems strange you see what you see when you say that the cpus are mostly idle.

That's because my SB950 AHCI eats up half to roughly three cores for iowait during writes.
I tried all the schedulers with the crude script I attached. You were right, "bfq" and "none" (who knew!) on my PC are the fastest by a good margin:

Code:

            find cp umount total
mq-deadline  27  54 4      85
kyber        26  41 13    80
bfq          26  45 1      72
none        26  45 1      72

But during all the tests the iowait didn't change: 40-75% for find, 100-300% for cp.
Thank you for investing your time on my ~10 years old mobo :)

Petri Kaukasoina 05-04-2021 02:03 PM

Quote:

Originally Posted by niksoggia (Post 6247927)
I tried all the schedulers with the crude script I attached. You were right, "bfq" and "none" (who knew!) on my PC are the fastest by a good margin:

Actually, I didn't think that it would be any faster doing those things with bfq. I think the point of the io scheduler is how the kernel divides the io between different processes. My experience is that it saves the OTHER interactive use and other processes in need of the disk while you are e.g. making backups. My measurement showed that if you are simultanously copying a large file from the rotating disk to the same disk, and building the kernel (using all the cores) on the same disk, the kernel builds 60 % faster with bfq than cfq. And you can do interactive work on X at the same time.

(BTW, when I do benchmarks, I use 'echo 3 > /proc/sys/vm/drop_caches' just before timing.)

Petri Kaukasoina 05-04-2021 02:31 PM

Quote:

Originally Posted by GazL (Post 6247868)
It provides both options, is all I'm saying. Personally, I'll be disabling it should this change be made. When I investigated autogroup I concluded I'm better off without it.

Me too.

The original patch came with benchmark results. There were eleven CPU bound processes running on ONE core: a kernel was built with -j10 and simultaneously another process in a loop only got one eleventh (9%) of cpu time. With autogroup the other process gets 50%. Why would anyone 'make -j10' on one core? With 'make -j1' the other process would have got 50%. And 'nice' would give even more. But with autogroup nice does not help. What if you are building a kernel (-j1) in one xterm and simultanously you are building qt (-j1) in another xterm (using one-core cpu)? They are in different groups because they were launched in different terminals. And all the processes you start from your WM belong to one single group. So, if you have three interactive processes: firefox looping in javascript, chromium looping in javascript, and you are watching a video, autogroup gives them all only 33% cpu to be divided between them, 33 % to the kernel building process and 33% to the qt building process. Nice does not help. Without autogroup, the three interactive processes firefox+chromium+video would get 60%, the kernel build 20%, and the qt build 20%. And nice would help.

Same thing with the Phoronix video/benchmark: they showed autogroup using 'make -j64', with a 6-core cpu...

Jeebizz 05-04-2021 04:58 PM

GParted 1.3

mats_b_tegner 05-05-2021 04:23 AM

Mozilla Firefox 88.0.1
https://ftp.mozilla.org/pub/firefox/....source.tar.xz
Mozilla Thunderbird 78.10.1
https://ftp.mozilla.org/pub/thunderb....source.tar.xz
Mutt 2.0.7
ftp://ftp.mutt.org/pub/mutt/mutt-2.0.7.tar.gz

biker_rat 05-05-2021 02:56 PM

Mesa 21.1.0 is available (feature release).

Raveriux 05-06-2021 01:55 AM

Is it possible to add libopenmpt (https://lib.openmpt.org/libopenmpt/) and recompile audacious-plugins to use it. As it sometimes useful to have module files support out of the box for playing module files like .xm, .it and etc. Audacious works quite well with libopenmpt.

marav 05-06-2021 04:04 AM

If it's possible to add ifuse to mount storage and access Apple iDevice documents ?

https://github.com/libimobiledevice/ifuse

saxa 05-06-2021 06:14 AM

gjs-1.68.1
https://download.gnome.org/sources/g...-1.68.1.tar.xz

marav 05-06-2021 12:05 PM

Rust 1.52

https://blog.rust-lang.org/2021/05/06/Rust-1.52.0.html

spinl0ck 05-06-2021 02:21 PM

libcgroup-2.0

https://github.com/libcgroup/libcgro...eases/tag/v2.0

LuckyCyborg 05-06-2021 02:28 PM

Quote:

Originally Posted by spinl0ck (Post 6248612)

FINALLY!

Until now, only the systemd had support for CGROUP v2 and everyone else was stuck on CGROUP v1.

But, now there's hope that it will be used also by elogind, LXC and any other software with interests on CGROUP's noble art.

Nobby6 05-07-2021 07:54 PM

mariadb 10.5.10 is now released

Nobby6 05-07-2021 08:00 PM

and since I dont see it mentioned, back on Thursday PHP 7.4.19 was released

I dont use pgsql but it apparently reverts a bug related to PDO_pgsql that was introduced in PHP 7.4.18.

gsl 05-07-2021 09:31 PM

Quote:

Originally Posted by Nobby6 (Post 6249059)
and since I dont see it mentioned, back on Thursday PHP 7.4.19 was released

Code:

Wed May  5 19:56:53 UTC 2021
...
n/php-7.4.19-x86_64-1.txz:  Upgraded



All times are GMT -5. The time now is 03:23 PM.