You are not logged in.
another option would be to cobble a script with yad for the gui (lighter for setups that already use yad) and on the inside all it does is run apt-get commands to show the information of the .deb and installs it with apt-get install <full/path/to/package.deb>
That was my thought. gdebi is only about 1 mb so it's small, but i'm pretty sure a simple script for doing this with yad and apt-get would only be like 20-30k. Edit: Actually less than that the more I think about it, apt-get will do all the legwork checking for depends etc. Just need to use the right command, then a success dialog at the end, some error checks of course etc.
If you're just making a quick and dirty for yourself and don't need a safety net, you can do it as a right-click extension with just a .desktop, like maybe so (if you know for sure you already have all needed depends installed):
[Desktop Entry]
Type=Action
Comment=Install local .deb package
Name=Install Package
Icon=info
Profiles=on_file;
[X-Action-Profile on_file]
Exec=gksu.sh dpkg -i %f
MimeTypes=application/x-debian-package;Before somebody asks again, gksu.sh is just my pkexec translator so I don't have to type a lot of extra crap when I make one of these.
yes, i've been thinking of rolling out my own apt wrapper, after all i already have apt-ui which uses fzf to provide a fuzzy ui for installing, uninstalling packages and also queriying package information: https://github.com/eylles/devuan-script … /apt-ui.sh
The comments! # if this is not your actual config dir then get rekt ![]()
Srsly tho, this put a bee in my bonnet on a small utility i've thought about in the past, a right-click context menu entry that offers to install a local .deb package when you select it in the file manager, little script + apt-get + some yad dialogs. I think that would be handy.
Probably easier to just use gdebi, it's nice.
/usr/lib/udev/rules.d/90-alsa-restore.rules
Here's the version in alsa-utils from their git:
# do not edit this file, it will be overwritten on update
ACTION=="add", SUBSYSTEM=="sound", KERNEL=="controlC*", KERNELS!="card*",@extratest@ GOTO="alsa_restore_go"
GOTO="alsa_restore_end"
LABEL="alsa_restore_go"
ENV{ALSA_CARD_NUMBER}="$attr{device/number}"
# mark HDA analog card; HDMI/DP card does not have capture devices
DRIVERS=="snd_hda_intel", TEST=="device/pcmC$env{ALSA_CARD_NUMBER}D0p", RUN+="/bin/sh -c 'echo ALSA_CARD_HDA_ANALOG=$env{ALSA_CARD_NUMBER} >> /run/udev/alsa-hda-analog-card'"
# check for ACP hardware
TEST=="device/device/acp3x-dmic-capture", GOTO="alsa_hda_analog"
TEST=="device/device/acp6x-dmic-capture", GOTO="alsa_hda_analog"
TEST=="device/device/acp63-dmic-capture", GOTO="alsa_hda_analog"
TEST=="device/device/acp-dmic-codec", GOTO="alsa_hda_analog"
GOTO="alsa_restore_std"
LABEL="alsa_hda_analog"
# restore configuration for profile with combined cards (HDA + digital mic)
TEST!="/run/udev/alsa-hda-analog-card", GOTO="alsa_restore_std"
IMPORT{program}="/usr/bin/cat /run/udev/alsa-hda-analog-card"
ENV{ALSA_CARD_HDA_ANALOG}!="", ENV{ALSA_CARD_NUMBER}="$env{ALSA_CARD_HDA_ANALOG}"
LABEL="alsa_restore_std"
TEST!="@daemonswitch@", RUN+="@sbindir@/alsactl@args@ restore $env{ALSA_CARD_NUMBER}"
TEST=="@daemonswitch@", RUN+="@sbindir@/alsactl@args@ nrestore $env{ALSA_CARD_NUMBER}"
LABEL="alsa_restore_end"And here's the current version in excalibur/trixie:
# do not edit this file, it will be overwritten on update
ACTION=="add", SUBSYSTEM=="sound", KERNEL=="controlC*", KERNELS!="card*", TEST=="/usr/sbin", TEST=="/usr/share/alsa", GOTO="alsa_restore_go"
GOTO="alsa_restore_end"
LABEL="alsa_restore_go"
ENV{ALSA_CARD_NUMBER}="$attr{device/number}"
# mark HDA analog card; HDMI/DP card does not have capture devices
DRIVERS=="snd_hda_intel", TEST=="device/pcmC$env{ALSA_CARD_NUMBER}D0p", RUN+="/bin/sh -c 'echo ALSA_CARD_HDA_ANALOG=$env{ALSA_CARD_NUMBER} >> /run/udev/alsa-hda-analog-card'"
# check for ACP hardware
TEST=="device/device/acp3x-dmic-capture", GOTO="alsa_hda_analog"
TEST=="device/device/acp6x-dmic-capture", GOTO="alsa_hda_analog"
TEST=="device/device/acp63-dmic-capture", GOTO="alsa_hda_analog"
TEST=="device/device/acp-dmic-codec", GOTO="alsa_hda_analog"
GOTO="alsa_restore_std"
LABEL="alsa_hda_analog"
# restore configuration for profile with combined cards (HDA + digital mic)
TEST!="/run/udev/alsa-hda-analog-card", GOTO="alsa_restore_std"
IMPORT{program}="/usr/bin/cat /run/udev/alsa-hda-analog-card"
ENV{ALSA_CARD_HDA_ANALOG}!="", ENV{ALSA_CARD_NUMBER}="$env{ALSA_CARD_HDA_ANALOG}"
LABEL="alsa_restore_go"
TEST!="/etc/alsa/state-daemon.conf", TEST=="/usr/sbin/alsactl", RUN+="/usr/sbin/alsactl -E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime restore $env{ALSA_CARD_NUMBER}"
TEST=="/etc/alsa/state-daemon.conf", TEST=="/usr/sbin/alsactl", RUN+="/usr/sbin/alsactl -E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime nrestore $env{ALSA_CARD_NUMBER}"
LABEL="alsa_restore_end"Okay, more info. The bug is in alsa-utils, in the 90-alsa-restore.rules file. Looks like alsa fixed it months ago, but then a patch from Debian broke it again so now I guess it's their bug, and it's still an issue in Trixie as of 2 days ago.
https://bugs-devel.debian.org/cgi-bin/b … ug=1093057
The patch is also supposed to be a fix for some mics not working from what i've read.
Okay, the point release from upstream came in the day after I put up those last iso's, lol, so I updated everything and ran a couple new ones. Just a maintenance release, 87 updates in the max and 70 in the mini. They're up on the site now.
a few times in the past but I couldn't get my laptop mic working on ALSA
I wonder if this might help?: https://github.com/alsa-project/alsa-utils/pull/281
There will be some complaints within the upgrade process if that wasn't done.
I thought as much, but would it error-out the process?
To update, I changed the entries daedalus to excalibur in /etc/apt/sources.list.
I'm sure you probably did this, but just to rule out the small stuff, you did install usrmerge before updating yes?
I actually don't know what would happen if you had not, likely wouldn't have succeeded in updating, but I always like to start with the simple stuff when troubleshooting.
So now he must be close to 102? That's awesome, what an amazing life!
I've been working on some stuff lately for my wife's 92 year old friend she looks after, using bigger print and simpler interfaces for older eyes.
Known issue, supposedly fixed, some links:
https://github.com/alsa-project/alsa-ut … e.rules.in
https://github.com/alsa-project/alsa-utils/issues/280
https://github.com/alsa-project/alsa-ut … 17e53b41a8
An even easier workaround (have not tested myself): https://andrzej.langow.ski/2025/05/14/s … -ignoring/
I guess the fix never made it into trixie?
The file is somewhere.
I think it's just the LABEL + definition missing, not an actual file? Possibly:
LABEL="alsa_restore_std"
TEST!="@daemonswitch@", RUN+="@sbindir@/alsactl@args@ restore $env{ALSA_CARD_NUMBER}"
TEST=="@daemonswitch@", RUN+="@sbindir@/alsactl@args@ nrestore $env{ALSA_CARD_NUMBER}"And from Ubuntu bugs:
I read the Debian bug which reports that although this was fixed in 1.2.14, there are Debian/Ubuntu patches that were not correctly updated which means the bug is still present in the latest packaging so I'm reopening this issue.
I don't have excalibur booted up right now, will boot up a live-session later and do some more testing.
Right there with ya my friend, running a couple of HP laptops from 2012-2013 here and they've been great, so sorry they ham-handed your new laptop, that's got to be hugely frustrating.
I keep thinking I need a newer laptop, but then I read various horror stories about new stuff, seems like the cutoff date for quality is around 2015 or so.
Thought 'd make a separate thread for this, in a nutshell on excalibur I am still getting the alsa errors on boot-up for months now.
"GOTO alsa_restore_std has no matching label in /usr/lib/udev/rules.d/90-alsa_restore_std",
and indeed there is no alsa_restore_std in that folder, maybe there should be one or the alsa rules file in there needs to be edited?
My temp workaround is to make a file in /etc/udev/rules.d/ , 90-alsa-restore-rules, that overrides the existing rules file:
ACTION=="add", SUBSYSTEM=="sound", KERNEL=="controlC*", KERNELS!="card*", TEST=="/usr/sbin", TEST=="/usr/share/alsa", GOTO="alsa_restore_go"
GOTO="alsa_restore_end"
LABEL="alsa_restore_go"
TEST!="/etc/alsa/state-daemon.conf", TEST=="/usr/sbin/alsactl", RUN+="/usr/sbin/alsactl -E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime restore $attr{device/number}"
TEST=="/etc/alsa/state-daemon.conf", TEST=="/usr/sbin/alsactl", RUN+="/usr/sbin/alsactl -E HOME=/run/alsa -E XDG_RUNTIME_DIR=/run/alsa/runtime nrestore $attr{device/number}"
LABEL="alsa_restore_end"You don't have to install something to try it, burn you a hybrid iso onto a USB stick and give it a whirl, you can install packages into a live system to see if they work. It's not that scary and you obviously have some advanced skills and knowledge. ![]()
Ouch! One year old and it already broke the network adapter internally? Yikes. And no ethernet port to fall back to (brilliant design that). Can you just share the make/model so folks know not to buy 'em?
So this may be the very occasion to install a fresh system
Seconding this excellent advice.
9-06-2025 New versions of Vuu-do Openbox 5.03 max and mini uploaded.
A number of important packages updated, including a new kernel. New version of the Vuu-do App Info app with a re-scan button now for when you add new programs. Set the volume icon in the tray to open AlsaTune when you middle-click instead of the terminal mixer. Cleaned up a redundant menu entry and did some small tweaks that should increase performance and use less power doing it. New versions of ffmpeg and Chromium (in the max) and udisks. Cleaned up some other cruft that had snuck in on me and some other house-cleaning.
Note: you can have two monitors with nouveau.
Cool beans, back in the day it didn't so I had to use proprietary stuff, I really don't miss flailing about in xorg.conf one bit. ![]()
A piece of paper and a pen. <<greenjeans password managing system ![]()
Sorry, I forgot that jokes can be censored.
Context can be difficult on the internet, perhaps if you had included like the winking smiley it might have indicated you were joking.
Do you know to use smilies? ![]()
Thanks rayburn! Also, that's good to know the blinking is happening on your machine too, that at least means it's not just my hardware.
And the solution was?
Sorry, I was rushing yesterday trying to get some stuff done before the windstorm hit. (I did not succeed).
The firmware package is not in Daedalus proper, it's in backports, which I forgot I had enabled. So technically nouveau should have some functionality without it. You may or may not get more by adding the firmware package.
Solved on IRC.
So I haven't used a machine with nvidia graphics in over 6 years, and when I did I used the proprietary drivers because I needed them at that time to run dual monitors. And now I don't have an nividia machine to test on.
A standard Devuan install (daedalus) already comes with libdrm-nouveau2 and xserver-xorg-video-nouveau, but do you also need the package firmware-nvidia-graphics to use nouveau?
Working on some Vuu-do updates, and just realized I hadn't included that firmware package. I stay away from the proprietary stuff as some of it conflicts with each other and I don't have a machine to test what works. But I want to be sure a user has at least nouveau to use if they have an nvidia machine.
Thanks!
Good questions ffp, I just don't have answers for you as i'm not a part of Devuan's Dev team. That being said I haven't heard anybody say it was in consideration for Devuan proper, there's just a lot of interest though in the community, if you take a peek at xlibre's IRC channel on libera you'll see a lot of members of this forum hanging out there.
I myself don't even have a good understanding of what it brings to the table, that's why i'm testing and trying to learn more about it, and trying to make it easier for other people like me to do some testing as well by squashing up these iso's. Not everybody wants to mess with their current installations by trying experimental software on them, but it's super easy to download an iso with xlibre already on there and burn it to a stick and run a live-session to run it through it's paces on their hardware.
@ffp: I haven't heard anyone say we needed it, some of us are just pitching in to help test it.
As i've said before, my main maxim for Linux is: you either make do, or you make new.
I'm just trying to help some folks that are trying to make new.