specialist audio configurations
by Tim
Hi,
Has pulseaudio/pipewire got to the stage where we can specify output
channels in our own way?
For instance, I use a Behringer UMC1820 for sound input/output. It's a
multichannel thing, over 10 inputs and outputs.
You can record multichannel, that works fine (usually). Occasionally
there's some restarting/rebooting fights to get things working with
Audacity (internal sound versus USB), and working at the correct speeds
(playback being slower than record, not knowing if one or both were
off-speed). It might only take a system ding, or a website sound, to
suddenly make Audacity play slowly (speed and pitch change).
That kind of issue isn't too surprising, all things considered. I
don't know if there's always a preset internal bitrate that pulseaudio
transcodes on demand, or it switches bitrates all the time to track the
input sources and output devices. I mostly worked in 44100 bitrates
suited to CD audio, though now I'm trialling 48000 commonly used for
video applications, since compact disc usage is getting rarer.
Multichannel playback is another issue. The OS thinks its a surround
sound system. So for the few things that can do more than two-channel
stereo, it thinks the other outputs are a specific use for front, back,
side, left, right, which aren't actually the case. It would be good if
there was a way to specify the purpose of each output in a custom way,
or even just have general purpose channel 1, 2, 3, 4, 5, etc.
Bye,
Tim.
--
uname -rsvp
Linux 3.10.0-1160.71.1.el7.x86_64 #1 SMP Tue Jun 28 15:37:28 UTC 2022 x86_64
Boilerplate: All unexpected mail to my mailbox is automatically deleted.
I will only get to see the messages that are posted to the mailing list.
1 year, 10 months
Is there an officially Fedora supported replacement for the old
rc.local?
by Peter Boy
I have to run some scripts at the end of the boot process to establish various workarounds for bugs in systemd. In the days of System V, /etc/rc.d/rc.local would be the right place for this.
My research revealed several solutions with conflicting recommendations:
(a)
There is - also in Fedora - systemd-rc-local service. In the man file it is advised not to use it. A Fedora default installation also does not completely create the necessary directory structure. And if one wants to execute this service as far as possible at the end of the boot process, further adjustments are necessary.
(b)
There is the DIY suggestion to create a service of one's own, and to place it as far as possible at the end of the system start.
(c)
A suggestion is to insert in the root-crontab at the end
@reboot systemctl start ….
The latter seems to be the most reliable solution at the moment.
Any recommendations and/or experiences?
1 year, 10 months
beat updatedb over the head?
by Tom Horsley
The timer installed by plocate insists on running updatedb at
maximally inconvenient times. I looked at the docs for systemd
timers and my brain screamed at me: "I don't feel like thinking
hard enough to get this right!"
Anyone have an example of a systemd timer that runs at a specific
time of day (like 1AM) so I can avoid thinking too hard? :-).
Can I override an installed systemd timer by putting a replacement
with the same name under /etc somewhere?
1 year, 10 months
MariaDB in Fedora - retiring 10.3 & 10.4 series
by Michal Schorm
Hello everyone,
Due to several circumstances I am stopping all efforts in maintaining
MariaDB 10.3 & 10.4 series in Fedora.
Just before that, I rebased both series to the latest upstream
versions, so you will get all the security patches released as for
today !
MariaDB 10.3: https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2022-0cd0202272
MariaDB 10.4: https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2022-c58e1ae21e
Also, please notice that neither series is available in Fedora > 35,
because our efforts to cherry-pick the OpenSSL 3 patch from the 10.8
series were unsuccessful.
Furthermore, please note that _on upstream_ :
MariaDB 10.3 will reach 'end of standard support' and EOL on: 25 May 2023
MariaDB 10.4 reached 'end of standard support' on: 02 July 2022 and
will reach EOL on: 02 July 2024
--
I strongly recommend updating your applications to at least MariaDB 10.5 series.
MariaDB upstream changed it's release model some time ago [1].
The upstream expects to release a new _serie_ every three months.
Every new series (starting 10.6) support period was shortened to _one
year_ only. Some of the series will be marked as LTS (long term
support) with support period being at least 5 years.
First serie marked as LTS is 10.6
Second serie that will _likely_ be marked as LTS is 10.10
My personal focus - as the package maintainer - is on the MariaDB 10.5
; and MariaDB 10.10 (should it be marked LTS).
Please consider all other series maintained (by me in Fedora) on 'best
effort' basis only.
The golden rule in case of my packages is that the development is done
in base Fedora (branch 'rawhide'), so whichever version there is, it
is the one maintained with most care.
--
As always, anyone is welcome to submit patches or (preferably) pull
requests to packages I maintain, or step in to maintain MariaDB series
I don't have capacity for.
Feel free to ask more questions if you are interested, I'll answer what I can.
I wish you a nice day and stable DB servers :)
[1] https://mariadb.com/newsroom/press-releases/mariadb-announces-new-innovat...
[2] rel-eng ticket regarding setting the EOL date:
https://pagure.io/releng/issue/10902
[3] Wiki page with info which series are in which Fedora releases:
https://fedoraproject.org/wiki/MariaDB_software
--
Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat
--
1 year, 10 months
Re: Is there an officially Fedora supported replacement for,> the old
rc.local? - still an issue
by R. G. Newbury
>> Am 18.07.2022 um 22:18 schrieb Peter Boy<pboy(a)uni-bremen.de>: wrote
>>
>> I got it finally working.
> After some tests: It isn’t.
>
> The programs I have to start depend on the existence of some (virtual) network interfaces. rc.local is ordered after network.target, which doesn’t mean, the network is functional then. Therefore, the program start via rc.local is in indeterministic process. Sometimes it works, sometimes not, sometimes only for some.
>
> Documentation mentions a drop in at/etc/systemd/system/rc-local.service.d/network.conf. But there is no
> subdirectory /etc/systemd/system/rc-local.service.d/
>
> Should I really mess around with vim and mkdir in the directories managed by the distribution? Seems like a bad idea to me.
>
> Or have I missed something?
There is a cleaner workaround, which does, unfortunately mean you have
to do some minor file amendments (with vim, *of course*!)
Your original /etc/rc.d/rc.local is renamed:
mv rc.local the-real-rc.local
/etc/rc.d/rc.local is replaced with a new version:
<code>
#!/bin/bash
# to run rc.local type things, without interference from systemd
# rc-local:
/usr/bin/at -M now <<'HERE' > /dev/null 2>&1
/etc/rc.d/the-real-rc.local
HERE
# And everything I used to run in rc.local now gets run
# from the-real-rc.local, untouched by systemd meddling
# (Resistance was futile, I was assimilated).
</code>
Both of these files have to be executable (chmod 755).
The /usr/systemd/rc-local.service file IS NOT TOUCHED, so there are no
problems with it being overwritten. (might need to be enabled. I cannot
remember.)
The rc-local service checks the rc.local file, and IF it is executable,
will run it. The new version rc.local calls 'the-real-rc.local'.
Your 'the-real-rc.local' file can have a sleep or structured pause until
the networks respond properly and signal they are awake.
This sleight-of-hand was posted by someone on an Arch distro
forum/mailing list. I do not have his name, but kudos and thanks whoever
you are. It works
In addition, you can also split your 'real' file, by creating a
semaphore file in /tmp, and run different sections.
If you prefer you can run a 'real' files only on the first run after a
boot, or even after an install.
If you have not yet changed, for example, /var/lib/mysql from a
directory to a link to somewhere else, then this is the first run after
a re-install, and that has not yet been done: an install, in my
experience, whether told to format or not to format, will wipe the /var
partition, and all of the databases in that folder. I put them elsewhere
and link to there, so no losses. So obviously one thing I want to do is
change the folder to a link to the proper place.
And obviously there are a plethora of things which need to be done
*once* after an install. Needs one 'if' statement in the bash script. A
re-run will skip the block.
Geoff
1 year, 10 months
diagnosing XFS corruption after upgrading to Fedora 36
by Patrick Hemmer
Ever since upgrading to Fedora 36, my root filesystem is getting corrupted every few hours. I maintain block level backups, and I have to restore every time this happens. xfs_repair can fix the filesystem, but the system is typically unusable as there's often over 10k files in lost+found.
I have tried creating a brand new filesystem (mkfs.xfs), but it still gets corrupted.
I would file a bug, but the caveat is that I also have LVM underneath the filesystem. And so I don't know whether it's a problem with XFS, or LVM. I have other XFS filesystems also on LVM, and have seen corruption on them as well, but it's nowhere near as significant or frequent as on the root filesystem.
Sometimes I can detect the corruption before the kernel does, by doing a snapshot, and running `xfs_repair -n` on the snapshot. And sometimes the kernel will detect the corruption first, usually with a message like:
Jul 17 15:06:52 whistler kernel: XFS (dm-0): Metadata corruption detected at xfs_buf_ioend+0x14c/0x5d0 [xfs], xfs_inode block 0x46057c8 xfs_inode_buf_verify
Jul 17 15:06:52 whistler kernel: XFS (dm-0): Unmount and run xfs_repair
Jul 17 15:06:52 whistler kernel: XFS (dm-0): First 128 bytes of corrupted metadata buffer:
Jul 17 15:06:52 whistler kernel: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Jul 17 15:06:52 whistler kernel: 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Jul 17 15:06:52 whistler kernel: 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Jul 17 15:06:52 whistler kernel: 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Jul 17 15:06:52 whistler kernel: 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Jul 17 15:06:52 whistler kernel: 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Jul 17 15:06:52 whistler kernel: 00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Jul 17 15:06:52 whistler kernel: 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Jul 17 15:06:52 whistler kernel: XFS (dm-0): metadata I/O error in "xfs_imap_to_bp+0x40/0x50 [xfs]" at daddr 0x46057c8 len 32 error 117
Jul 17 15:06:52 whistler kernel: XFS (dm-0): Metadata I/O Error (0x1) detected at xfs_trans_read_buf_map+0x179/0x2d0 [xfs] (fs/xfs/xfs_trans_buf.c:296). Shutting down filesystem.
Jul 17 15:06:52 whistler kernel: XFS (dm-0): Please unmount the filesystem and rectify the problem(s)
So how can I proceed on this? Is there any way to determine whether this is an LVM issue or an XFS issue?
1 year, 10 months
A simple question
by Joe Zeff
Recently, my laptop died and I had to buy a new one. Now, I'd like to
take a look at what hardware is inside. I know that there used to be a
program to show you all of the hardware, but it's been so long since I
needed it that I can't remember its name. I'd appreciate it if somebody
could point me in the right direction.
1 year, 10 months
Re Re: Long timeouts on logging out/shutting down
by R. G. Newbury
On 2022-07-17 15:17, Francis.Montagnac(a)inria.fr wrote
> On Sun, 17 Jul 2022 17:39:35 +0100 Patrick O'Callaghan wrote:
>>> Actually, according to systemd-system.conf(5), it looks like the
>>> proper place to do this is with a file under
>>> /usr/lib/systemd/system.conf.d, similar to the old rc.d init files.
>>> Presumably that will avoid the setting being overwritten by a new
>>> install.
>> Well, that was a bust. Turns out that you do have to edit the standard
>> file(s) to have any effect.
> It works for me.
> Did you specified the [Manager] tag in the drop-in file ?
> Example:
> ## Weird: systemd seems to uses internally a ...USec name for that
> systemctl show --property=DefaultTimeoutStopUSec
> DefaultTimeoutStopUSec=1min 30s
>
> mkdir /usr/lib/systemd/system.conf.d
> echo -e '[Manager]\nDefaultTimeoutStopSec=5s' > /usr/lib/systemd/system.conf.d/99-stop-fast.conf
>
> systemctl daemon-reload
>
> systemctl show --property=DefaultTimeoutStopUSec
> DefaultTimeoutStopUSec=5s
> -- francis
This reminds me SO much of reading old IBM Red Books. You must
thoroughly understand the *footnotes* to Chapter 22 before you can
actually understand the third paragraph of Chapter 2.
(Cannot now remember whether that was OS/2 or REXX... Lost to human memory.)
And also reminds me why Linux can be considered a cult, as there are
arcane and unknown rules controlling how things work.
Geoff
--
R. Geoffrey Newbury
954 Owenwood Drive
Mississauga, Ontario, L5H 3J2
416-854-8160 newbury(a)mandamus.org
1 year, 10 months
altas-devel
by Patrick Dupre
Hello,
Before fc36
atals-devel provided /usr/include/clapack.h
Now
clapack.h is
/usr/include/atlas-x86_64-base/clapack.h
Why such a change?
It requires to modify source files.
===========================================================================
Patrick DUPRÉ | | email: pdupre(a)gmx.com
Laboratoire interdisciplinaire Carnot de Bourgogne
9 Avenue Alain Savary, BP 47870, 21078 DIJON Cedex FRANCE
Tel: +33 (0)380395988 | | Room# D114A
===========================================================================
1 year, 10 months
