You are not logged in.
Are you using pulseaudio? When I was using pulseaudio I had to set the default output in a configuration file, see this post and the following post:
https://dev1galaxy.org/viewtopic.php?pid=28936#p28936
I haven't had to do that with pipewire as the settings in KDE/plasma audio settings have held.
Latest issues:
[UPGRADE] dmsetup:i386 2:1.02.185-2 -> 2:1.02.185-3
this moves /sbin/dmsetup to /usr/sbin/dmsetup
initramfs-tools 0.142 uses /sbin/dmsetup in /usr/share/initramfs-tools/hooks/dmsetup
The easiest temporary solution was to downgrade the following packages:
[DOWNGRADE] dmsetup:i386 2:1.02.185-3 -> 2:1.02.185-2
[DOWNGRADE] libdevmapper-dev:i386 2:1.02.185-3 -> 2:1.02.185-2
[DOWNGRADE] libdevmapper-event1.02.1:i386 2:1.02.185-3 -> 2:1.02.185-2
[DOWNGRADE] libdevmapper1.02.1:i386 2:1.02.185-3 -> 2:1.02.185-2
Alternatively, (and this would require a boot from rescue media and mounting the root file system and being careful to make the symbolic links point correctly),
moving /lib/i386-linux-gnu to /usr/lib/i386-linux-gnu and providing a symbolic link from /lib/i386/linux-gnu to ../usr/lib/i386-linux-gnu
and moving /lib/modules to /usr/lib/modules and providing a symbolic link from /lib/modules to ../usr/lib/modules
and moving /lib/udev/* to /usr/lib/udev and providing a symbolic link from /lib/udev to ../usr/lib/udev
then rebooting without the rescue media
then upgrade dmsetup / libdevmapper and then create a symbolic link from /sbin/dmsetup to /usr/sbin/dmsetup
Funnily enough,
timidity somefile.mid
(ie using default audio output) worked
Hi, if anyone has timidity working with pipewire on Devuan, I would like to know the details as I haven't yet succeeded in getting it working and am now reliant on my old SoundBlaster Audigy 2 ZS for playing MIDI files.
Now it's the turn of kmod / libkmod2
After experimenting, it seems to work if one upgrades to version (31-1), then create the following symbolic links:
# cd /sbin
am64:/sbin# ln -s /usr/sbin/depmod depmod
am64:/sbin# ln -s /usr/sbin/insmod insmod
am64:/sbin# ln -s /usr/sbin/modinfo modinfo
am64:/sbin# ln -s /usr/sbin/modprobe modprobe
am64:/sbin# ln -s /usr/sbin/rmmod rmmod
EDIT, forgot lsmod:
cd /sbin
ln -s /usr/sbin/lsmod lsmod
then re-installing kmod (31-1) so that update-initramfs is run successfully.
More fun today with grep and egrep and fgrep moving to /usr/bin
eudev apparently tries to find egrep in /bin and I had only added a symbolic link for /bin/grep to /usr/bin/grep at the time.
This bit me this morning:
sed (4.9-2) unstable; urgency=medium
[ Gioele Barabucci ]
* Support <nodoc> build profile. closes: #1051792.
[ Clint Adams ]
* Patch from Helmut Grohne to move sed to /usr/bin. closes: #1059821.
-- Clint Adams <clint@debian.org> Mon, 01 Jan 2024 18:37:14 -0500
I manually added a symbolic link from /bin/sed to /usr/bin/sed afterwards.
Fortunately the recent coreutils update still installed programs in /bin:
coreutils (9.4-3) unstable; urgency=low
* remove arch restriction from libssl-dev build-depend
* revert cp -n behavior to debian 12 & prior (Closes: #1058752)
* add deprecation/compatibility warning for above
-- Michael Stone <mstone@debian.org> Tue, 02 Jan 2024 08:54:03 -0500
Hi, I wasn't the original poster in this thread, however the usrmerge issue did prevent firmware for my AMD gpu and for my network card from being loaded (back in early December 2023).
Since then firmware-amd-graphics has been updated again:
Thu, Dec 21 2023 22:15:16 +1030
[UPGRADE] firmware-amd-graphics:amd64 20230625-1 -> 20230625-2What did you have to do? I'm getting close to reinstalling my OS as I want to use this GPU that I spent nearly $1k on, granted I can use it just fine, but I'd like to continue getting support and newer features without breakage everytime I upgrade...
Thanks.
This is risky as you might end up with an unbootable system.
As I still have optical drives, I made a bootable Devuan live DVD on another pc for rescue purposes after suffering non-working graphics and networking.
I ended up manually moving the contents of /lib/firmware to /usr/lib/firmware
mv /lib/firmware/* /usr/lib/firmware
then
mv /lib/firmware /lib/oldfirmware (there shouldn't be anything left in the /lib/firmware directory after the previous command)
and most importantly, create a symbolic link from /lib/firmware to /usr/lib/firmware
ln -s /usr/lib/firmware /lib/firmware
After all these changes, try running
update-initramfs -u -k $(uname -r)
to get the firmware included in the initramfs
Look out for any missing firmware commands. If there are any warnings for hardware that you use, you many need to install additional firmware packages.
Good day Mirrortokyo,
Your updated graphics driver version, 20230625-1, is out of date as of my posting. The current version is firmware-amd-graphics-20230625-2, and is available in the Devuan repos. If your apt cache is up-to-date, the version you are trying to install, 20230625-1 looks to be the current Debian Trixie release, and NOT from Devuan.
...
Nietz
Hi, I wasn't the original poster in this thread, however the usrmerge issue did prevent firmware for my AMD gpu and for my network card from being loaded (back in early December 2023).
Since then firmware-amd-graphics has been updated again:
Thu, Dec 21 2023 22:15:16 +1030
[UPGRADE] firmware-amd-graphics:amd64 20230625-1 -> 20230625-2
I had some pain with the usrmerge process associated with:
[UPGRADE] firmware-amd-graphics:amd64 20230515-3 -> 20230625-1
which happened for me on 03 December 2023
(and not just firmware for the AMD GPU, but also for the Ethernet card, so I couldn't do a remote login to the affected pc).
update-initramfs also complained of missing firmware (once I had stopped the boot process from attempting to change out of text mode and was able to see where the failure was occuring).
I ended up copying the contents from /lib/firmware to /usr/lib/firmware then renamed the old /lib/firmware directory /lib/oldfirmware then recreated a symbolic link from /lib/firmware to /usr/llib/firmware
Somewhere I read the starting order was important... but mine looks different.
~.xsessionrc
# kill any existing pipewire instance to restore sound pkill -u "$USER" -fx /usr/bin/pipewire-pulse 1>/dev/null 2>&1 pkill -u "$USER" -fx /usr/bin/wireplumber 1>/dev/null 2>&1 pkill -u "$USER" -fx /usr/bin/pipewire 1>/dev/null 2>&1 exec /usr/bin/pipewire & # wait for pipewire to start before attempting to start related daemons while [ "$(pgrep -f /usr/bin/pipewire)" = "" ] ; do sleep 1 done exec /usr/bin/wireplumber & exec /usr/bin/pipewire-pulse &
This appears to work better than stopAI's simpler script.
Just reporting back that GlennW's script seems to work well.
Why pipewire? Because, it is considerably more reliable, and is a comfortable drop-in replacement for many use-cases.
How to install and start using pipewire?
...
P.S.I also recommend installing a package called
pavucontrol
which makes it easy to adjust the audio outputs.
Thanks, this worked well, just had to run pavucontrol to pick the correct output once and the setting was saved.
I build custom kernels at least for each release candidate and release, using a script like:
MAKEFLAGS='HOSTCC=gcc-13 CC=gcc-13' make -j7 menuconfig bindeb-pkg
One can remove drivers for hardware not used and filesystems and protocols not used and speed up the build process considerably. (One slow machine gets its kernel rebuilt without netfilter support to reduce the build process significantly).
If something breaks, one can still have alternative kernels to boot into and report problems to the maintainers.
Maybe just as a reminder to myself and also due to some painful experiences I wanted to note some useful information for those who want their machine to be able to send mail from reportbug and popularity-contest.
My machine is on a dynamic IP address permanently connected via VDSL with the ISP providing a smarthost at mail.isp.domain (but reverse lookup of the IP address of mail.isp.domain results in a *.compute.amazonaws.com machine name).
I had a lot of grief until I set /etc/mailname to contain:
localhost
When the ISP moved mail.isp.domain from a machine whose IP address gave a reverse lookup of mail.isp.domain to a machine that gave a reverse lookup of some-name.amazonaws.com, it broke one of the exim4 assumptions:
the manual page for /etc/exim4/passwd.client, which is exim4_passwd_client (5) states:
/etc/exim4/passwd.client
contains account and password data for SMTP authentication when exim is
authenticating as a client to some remote server.
The file should contain lines of the form
target.mail.server.example:login-user-name:password
which will cause exim to use login-user-name and password when sending
messages to a server with the canonical host name tar‐
get.mail.server.example. Please note that this does not configure the
mail server to send to (this is determined in Debconf), but only cre‐
ates the correlation between host name and authentication credentials
to avoid exposing passwords to the wrong host.
Please note that target.mail.server.example is currently the value that
exim can read from reverse DNS: It first follows the host name of the
target system until it finds an IP address, and then looks up the re‐
verse DNS for that IP address to use the outcome of this query (or the
IP address itself should the query fail) as index into
/etc/exim4/passwd.client.
This goes inevitably wrong if the host name of the mail server is a
CNAME (a DNS alias), or the reverse lookup does not fit the forward
one.
Currently, you need to manually lookup all reverse DNS names for all IP
addresses that your SMTP server host name points to, for example by us‐
ing the host command. If the SMTP smarthost alias expands to multiple
IPs, you need to have multiple lines for all the hosts. When your ISP
changes the alias, you will need to manually fix that.
You may minimize this trouble by using a wild card entry or regular ex‐
pressions, thus reducing the risk of divulging the password to the
wrong SMTP server while reducing the number of necessary lines. For a
deeper discussion, see the Debian BTS #244724.
password is your SMTP password in clear text. If you do not know about
your SMTP password, you can try using your POP3 password as a first
guess.
This file must be readable for the Debian-exim user and should not be
readable for others. Recommended file mode is root:Debian-exim 640.
# example for CONFDIR/passwd.client
# this will only match if the server's generic name matches exactly
mail.server.example:user:password
# this will deliver the password to any server
*:username:password
# this will deliver the password to servers whose generic name ends in
# mail.server.example
*.mail.server.example:user:password
# this will deliver the password to servers whose generic name matches
# the regular expression
^smtp[0-9]*\.mail\.server\.example:user:password
In my case, I originally had:
mail.isp.domain:username@isp.domain:password
and added:
*.newhost.newdomain:username@isp.domain:password
*.compute.amazonaws.com:username@isp.comain:password
Hope this helps someone...
In Konsole 4:23.08.1-1 I lost the menubar and tabs moved from bottom to top of screen.
Thanks to the Debian maintainer I was given the instructions:
Use Control-Shift-M to toggle display of the menubar;
and under settings / configure konsole / tab bar/splitters tab position can be selected to be below terminal area.
From 2012, but still as brilliant as ever: Linked Horizon Luxendarc Kikou live https://www.youtube.com/watch?v=ZDrp0k-11lM
Includes Marty Friedman.
Available on Amazon Prime with subtitles (search Luxendarc).
Does anyone have ideas for a more elegant way of setting the default pulseaudio device?
I have a Realtek RTL2832-based DVB-T USB stick which works fine after a full shutdown and restart or simply removing and re-inserting it when the machine is up and running.
Is there any way to properly reset a USB DVB-T stick in the boot process, so that the DVB-T stick could be left in a working state after an init 6 restart?
I'm still stuck with kexec-tools 1:2.0.20-2.1 - Debian upstream doesn't appear to have addressed this problem.
Reportbug 11.4.0devuan2 changelog has:
Offer to send bugs in unforked packages directly to Debian, but still default to Devuan. (Closes: #656)
then at the end of /etc/pulse/default.pa I put:
# set-card-profile name-of-card-without-angle-brackets name-of-profile-without-trailing-colon
set-card-profile alsa_card.pci-0000_03_06.0 output:analog-stereo+input:analog-mono
After adding another PCI-Express card to the pc, I needed to comment out the line referencing the sound card in /etc/pulse/default.pa and re-run:
pacmd list-cards
which gave the new name of the card as:
alsa_card.pci-0000_04_06.0
and updated the line in /etc/pulse/default.pa to:
set-card-profile alsa_card.pci-0000_04_06.0 output:analog-stereo+input:analog-mono
I registered here to just to report on this issue (long time Devuan user).
Thanks to this thread I solved the issue for myself and filed a bug report:
https://bugs.debian.org/cgi-bin/bugrepo … bug=986211
My solution was to do:
pacmd list-cards
(program pacmd is in package pulseaudio-utils)
to find the actual output that I wanted to use (in my case, analogue stereo output on a Soundblaster Audigy 2 ZS)
then at the end of /etc/pulse/default.pa I put:
# set-card-profile name-of-card-without-angle-brackets name-of-profile-without-trailing-colon
set-card-profile alsa_card.pci-0000_03_06.0 output:analog-stereo+input:analog-mono
I also recommend installing the package pavucontrol and using the command pavucontrol if something gets accidentally muted.
This seems to be a problem of lack of documentation on setting the default audio profile.