You are not logged in.
I guess you won't be interested but as you may know, the action path for Devuan would be for a maintainer to set up a fork project (at git.devuan.org) to sort out its utility in Devuan. I anyhow invite you to take on that role for this package (as well as fftrate packages if you like).
Thanks. Good advice. I'll probably look at doing that eventually.
(I'm not using my bluetooth headset much at the moment)
It could possibly be helpful to the debian maintainer of bluez-alsa-util to lodge a bug regarding outdated codecs. Especially if there is a patch included. I guess the packaging project is on salsa.debian.org.
I think bluealsa gets started via dbus, But I haven't explored it.
Yes try https://pkginfo.devuan.org/bluez-alsa-utils rather
(golinux' URL includes the AI bot distraction so it's not sharable)
Note also that In excalibur bluez-alsa-utils provides bluealsa (without systemd dependency).
Are we searching for a distinct meaning of a marketing term?
I prefer asciidoctor
There is cryptsetup which according to its man page handles VeraCrypt encryption format.
It still will need two separate steps, like
cryptsetup open --type tcrypt /dev/sdb2 secrets
mount /dev/mapper/secrets /mnt/secretsThe first step creates the virtual partition (/dev/mapper/secrets) being the decryption of the real partition (/dev/sdb2), and the second step mounts that partition's filesystem on /mnt/secrets.
As per man page, if the VeraCrypt encryption has "personalized iteration count", you may need additional options to the open command.
Afaict tcplay does the same thing as cryptsetup, i.e. it creates that virtual partition for decrypted content access, and it doesn't mix in the filesystem mounting (which is an interpretation of the decrypted content).
When you try it, please don't do something destructive in case you succeed.
Which kind of virtual machine is it?
Which time sync program do you use?
In order for me to assist I will need to sight the exact result/response from the command I suggest; not some hand-wavy "it didn't work" or anything wiffle waffle ... I need to the exact response.
Ah, so you don't want help. Fair enough.
??? Did the command actually say "Hmm not working..." ???
@zapper: I'm guessing you need to resize the "home" logical volume to use up all the volume group space, and you then need to enlarge the filesystem inside the logical volume to fill all available logical volume space.
Possibly it all can be done in a sinlge command, something like:
# lvresize -l 100%VG -r $LVMwhere you replace $LVM with the identity fo the logical volume.
A backup might be handy.
.. and then you run lintian with the devuan profile to get adviced about the small things you forgotten, like man pages and stuff ![]()
The labels "excalibur", "excalibur-security", "excalibur-updates", etc are known as "codenames" and as such they identify "repositories" (not "distributions"). Each system (yours or mine) is set up with a package system that looks into one or more repositories for packages, which it (i.e. your system or my system) organises by package versions so as to get "the most recent version" of any package across those repositories.
A "distribution" is rather some particular collage of packages from some particular collective of repositories, that is formed and published so as to make a particular end user experience (and typically allowing for a smaller range of variations in experience).
HTH, Ralph.
You wish Devuan developers to debug Debian's debootstrap?
Right. That's wrong for debootstrapping Devuan. You need to use Devuan's debootstrap for that.
Where did you get that "excalibur" script from?
New threads are new trheads.
Which deboostrap version are you using?
EDIT: the reason I'm asking is because "merge_usr" is defined in the "functions" that come with the debootstrap installation, since excalibur.
1. please use code block markup for code blocks.
2. what do all those mean? same use case or different use case? successful or failing?
Perhaps you could show the tail end of the debootstrap.log file, for the failing case.
If your Hyperbola uses udev then it should work the same.
And by the way, the group doesn't have to be "plugdev"; that's just a (has been) convention. The key point is that due to that udev rule, the device node at /dev/bus/usb/xxx/yyy gets set up so that any user in that group have read-write access to it.
You install libdvd-pkg. It provides libdvdcss2.
Yes, you add GROUP="plugdev" with a preceding comma, to the end of line 13, to make it be:
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", IMPORT{builtin}="usb_id", IMPORT{builtin}="hwdb --subsystem=usb", GROUP="plugdev"With that, on your host, the USB that you plug in will be in group plugdev with rw mode.
It then requires the user that runs qemu to already be in group plugdev when logging in, which is a funny linux thing one can't avoid. I.e., after adding the user to the group, that user need to log out and in again in order to actually be in that group.
By that, the qemu guest should have and be able to access the USB key.
If however the USB key is unplugged, qemu will drop the connecting device setup, so that when the USB key is plugged in again, you need to operate the qemu console to restore the connecting device setup. This is another quirk to deal with. The best is of course to leave the USB key plugged in.