Re: [DNG] No Sound in XFCE Beowulf - Pulsaudio

[Gregory Nowak]

On Sat, Oct 31, 2020 at 10:57:52PM +0100, David Kuehling via Dng wrote:
> However, I think the proper fix, as pointed out by Ken, is
> to edit
> 
>   /etc/pulse/client.conf.d/00-disable-autospawn.conf
> 
> and comment out the "autospawn=no" line.  This is the solution that I'm
> currently using on all my Devuan Beowulf systems without encountering
> any issues.  I wonder why Devuan isn't distributing a patched version of
> pulseaudio that has this configured correctly by default?

Maybe because not all users of devuan want pulseaudio to be spawned by
default on their systems. Also spawning pulseaudio by default would
break the proposed fix for bug 496:



Greg


-- 
web site: http://www.gregn.net
gpg public key: http://www.gregn.net/pubkey.asc
skype: gregn1
(authorization required, add me to your contacts list first)
If we haven't been in touch before, e-mail me before adding me to your contacts.

--
Free domains: http://www.eu.org/ or mail dns-mana...@eu.org
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Building De{vu,bi}an kernel packages with embedded ZFS

[Mason Loring Bliss]

Some working notes for building ZFS into the kernel using the new
mechanisms. The last time I built Debian kernels, it was with make-kpkg,
and evidently things have improved substantially since then.

I've been building custom ZFS modules for a while, as some of my hardware
that uses ZFS is too slow to really have DKMS be viable. But even with the
modules, you have the issue of needing to build a new ZFS kmod for each
upgrade, and then if for some reason you install the kmod in a different
apt run from when you installed the new kernel, you'll probably find that
depmod didn't run and your initramfs didn't catch the new module, and you
have to correct it... I've done this often enough that I've got a fairly
strict procedure where I add the new kmod-zfs on the same run as when I
install the kernel, but this requires a little more discipline than is
ideal.

So, last night I decided to try building ZFS into the kernel so I don't
need modules at all. The down side is that I'm building my own local
kernel. The upside is also that I'm building my own local kernel. :) Plus,
I can just let the system update normally, pulling whatever's newest from
my local repository. (I'll document that sometime - more reason for me to
work on our wiki project.)

A great reference for the new way to build kernel packages is here:

https://debian-handbook.info/browse/stable/sect.kernel-compilation.html

Build prerequisites are noted here:

https://wiki.debian.org/BuildADebianKernelPackage

Since the last time I was building my own, Linux has learned how to build
Debian kernel packages, so there's no further need to have extra tools, and
you don't have to build as root any more, both of which are nice.

Since my goal is to build ZFS into my kernel, I need to configure it and
run a supplied script. It's assumed that you've unpacked the kernel source
into a local directory:

mkdir ~/kernel
cd ~/kernel
tar xf /usr/src/linux-source-4.19.tar.xz

Adding in ZFS bits:

cd ~/zfs-0.8.5/
./configure
./copy-builtin ~/kernel/linux-source-4.19/

And then finally building the kernel:

cd ~/kernel/linux-source-4.19/
cp /boot/config-4.19.0-12-amd64 .config
sed \
  -i 's/CONFIG_SYSTEM_TRUSTED_KEYS=.*/CONFIG_SYSTEM_TRUSTED_KEYS = ""/g' \
  .config
make oldconfig  # say 'y' when asked about ZFS and
# whack enter when asked about additional X.509 keys
make deb-pkg LOCALVERSION=-bliss KDEB_PKGVERSION=$(make kernelversion)-1

In truth, I edited the .config to eliminate CONFIG_SYSTEM_TRUSTED_KEYS
manually after I ran "make oldconfig". This should work as written - I've
tested it up to but excluding the actual build.

I did see the following warnings as the build process got partway through
ZFS but I've not observed any fallout from this.

  AS  fs/zfs/icp/asm-x86_64/sha1/sha1-x86_64.o
fs/zfs/icp/asm-x86_64/sha1/.tmp_sha1-x86_64.o: warning: objtool: 
sha1_block_data_order()+0x11: unsupported stack pointer realignment
  AS  fs/zfs/icp/asm-x86_64/sha2/sha256_impl.o
fs/zfs/icp/asm-x86_64/sha2/.tmp_sha256_impl.o: warning: objtool: 
SHA256TransformBlocks()+0x19: unsupported stack pointer realignment
  AS  fs/zfs/icp/asm-x86_64/sha2/sha512_impl.o
fs/zfs/icp/asm-x86_64/sha2/.tmp_sha512_impl.o: warning: objtool: 
SHA512TransformBlocks()+0x1c: unsupported stack pointer realignment

I'm running the kernel built by this process on a couple systems now to
give it a chance to do its thing for a while. My understanding is that
running built-in is the least-tested configuration, so make sure you've got
reliable and tested back-ups. (But of course you do already, right?)

NOTE: while a lot of the GPL/CDDL interaction people complain about is
quasi-legal FUD - the whimsical notion of modules becoming derivative works,
for instance, has never been tested in court - what we're doing here is
pretty clearly defined, and while your building ZFS into the kernel and
using it yourself is Just Fine, you're unambiguously violating the GPL if
you distribute the resulting binaries to other people, so don't do that.

Finally, note also that you still have to build and install the ZFS
userland tools. This process I've documented just obviates needing a
separate kernel module. You can follow the instructions here:


https://openzfs.github.io/openzfs-docs/Developer%20Resources/Custom%20Packages.html

TL;DR:

cd ~/zfs-0.8.5/
./configure
make -j1 deb-utils

At some point, to go along with this, I'll post my native-ZFS-root
installer scripting and notes, which assumes modules and will optionally
assume built-in ZFS before long, and which supports either LUKS or native
ZFS encryption, both with or without mirroring, on either UEFI or legacy
systems. (It's flexible. It'll even install Debian or Ubuntu.) (It'll make
the most sense for me to ship instructions for a local repository first.)

-- 
Mason Loring Bliss  ((   If I have not seen as far as others, it is