Skip to content

Update alsa packages#151357

Closed
L-as wants to merge 5 commits intoNixOS:stagingfrom
L-as:alsa
Closed

Update alsa packages#151357
L-as wants to merge 5 commits intoNixOS:stagingfrom
L-as:alsa

Conversation

@L-as
Copy link
Member

@L-as L-as commented Dec 19, 2021 •
edited
Loading

Motivation for this change

A bunch of the alsa packages were quite out of date.
Some have had attempted updates before but have been reverted:

In addition, many of the previous patches and customisations have been
removed as they are no longer necessary.

Cross-compilation for alsa-firmware does still work.

Things done

I've tested this on my Acer Chromebook Spin 513 and it works flawlessly.

  • Built on platform(s)
    • x86_64-linux
    • aarch64-linux
    • x86_64-darwin
    • aarch64-darwin
  • For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
  • Tested, as applicable:
  • Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
  • Tested basic functionality of all binary files (usually in ./result/bin/)
  • 22.05 Release Notes (or backporting 21.11 Release notes)
    • (Package updates) Added a release notes entry if the change is major or breaking
    • (Module updates) Added a release notes entry if the change is significant
    • (Module addition) Added a release notes entry if adding a new NixOS module
    • (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes
  • Fits CONTRIBUTING.md.

@L-as
Copy link
Member Author

L-as commented Dec 19, 2021

The reason this is one PR is that some of the versions likely depend on each other, e.g. alsa-ucm-conf on alsa-lib

@L-as L-as force-pushed the alsa branch 3 times, most recently from 2e3bf4c to 34f0640 Compare December 19, 2021 20:16
@ofborg ofborg bot added 11.by: package-maintainer This PR was created by a maintainer of all the package it changes. 10.rebuild-darwin: 101-500 This PR causes between 101 and 500 packages to rebuild on Darwin. 10.rebuild-linux: 501+ This PR causes many rebuilds on Linux and should normally target the staging branches. 10.rebuild-linux: 5001+ This PR causes many rebuilds on Linux and must target the staging branches. labels Dec 19, 2021
@L-as
Copy link
Member Author

L-as commented Dec 20, 2021

Discussion in #21751 is relevant, albeit in the case of alsa-firmware, the output seemingly doesn't actually differ depending on the platform (tested with diff -r). I'm not sure what it's compiling, but it will probably work fine even on when cross-compiled.

@collares
Copy link
Member

collares commented Dec 20, 2021 •
edited
Loading

I don't know if this problem is a blocker, but this breaks cross-compilation, as can be seen in the logs below. If you're on x86_64 and compiling for aarch64, as in the example below, CC should output aarch64 binaries but CC_FOR_BUILD should output x86_64 binaries. You might have something like boot.binfmt.emulatedSystems = [ "aarch64-linux" ]; in your config masking the mismatch.

Build log for pkgsCross.aarch64-multiplatform.alsa-firmware on x86_64. 
building '/nix/store/r5kgb4zkw82ax5qlqn3acyc5j06gn3a7-alsa-firmware-aarch64-unknown-linux-gnu-1.2.4.drv'...
unpacking sources
unpacking source archive /nix/store/z4sarpvzn4rv9a1c6i895l0fxvskvr6i-alsa-firmware-1.2.4.tar.bz2
source root is alsa-firmware-1.2.4
setting SOURCE_DATE_EPOCH to timestamp 1603193562 of file alsa-firmware-1.2.4/configure
patching sources
autoreconfPhase
autoreconf: export WARNINGS=
autoreconf: Entering directory '.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force
autoreconf: configure.ac: tracing
autoreconf: configure.ac: not using Libtool
autoreconf: configure.ac: not using Intltool
autoreconf: configure.ac: not using Gtkdoc
autoreconf: running: /nix/store/x5q70zjlassqa65m616cqdra18yvxl9z-autoconf-2.71/bin/autoconf --force
configure.ac:5: warning: The macro `AC_PROG_CC_FOR_BUILD' is obsolete.
configure.ac:5: You should run autoupdate.
m4/ax_prog_cc_for_build.m4:54: AC_PROG_CC_FOR_BUILD is expanded from...
configure.ac:5: the top level
configure.ac:8: warning: The macro `AC_HEADER_STDC' is obsolete.
configure.ac:8: You should run autoupdate.
./lib/autoconf/headers.m4:704: AC_HEADER_STDC is expanded from...
configure.ac:8: the top level
configure.ac:56: warning: AC_OUTPUT should be used without arguments.
configure.ac:56: You should run autoupdate.
autoreconf: configure.ac: not using Autoheader
autoreconf: running: automake --add-missing --copy --force-missing
vxloader/Makefile.am:47: warning: '%'-style pattern rules are a GNU make extension
autoreconf: './config.sub' is updated
autoreconf: './config.guess' is updated
autoreconf: Leaving directory '.'
updateAutotoolsGnuConfigScriptsPhase
Updating Autotools / GNU config script to a newer upstream version: ./config.sub
Updating Autotools / GNU config script to a newer upstream version: ./config.guess
configuring
fixing libtool script ./ltmain.sh
configure flags: --disable-dependency-tracking --prefix=/nix/store/qncbv68s88c0wkspm0vc3hsrnfymjnsw-alsa-firmware-aarch64-unknown-linux-gnu-1.2.4 --with-hotplug-dir=\$\(out\)/lib/firmware --build=x86_64-unknown-linux-gnu --host=aarch64-unknown-linux-gnu
checking for aarch64-unknown-linux-gnu-gcc... aarch64-unknown-linux-gnu-gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... yes
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether aarch64-unknown-linux-gnu-gcc accepts -g... yes
checking for aarch64-unknown-linux-gnu-gcc option to enable C11 features... none needed
checking whether aarch64-unknown-linux-gnu-gcc understands -c and -o together... yes
checking how to run the C preprocessor... aarch64-unknown-linux-gnu-gcc -E
checking build system type... x86_64-unknown-linux-gnu
checking for x86_64-unknown-linux-gnu-gcc... aarch64-unknown-linux-gnu-gcc
checking whether we are using the GNU C compiler... yes
checking whether aarch64-unknown-linux-gnu-gcc accepts -g... yes
checking for aarch64-unknown-linux-gnu-gcc option to enable C11 features... (cached) none needed
checking whether aarch64-unknown-linux-gnu-gcc understands -c and -o together... yes
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... configure: error: in `/build/alsa-firmware-1.2.4':
configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--build'.
See `config.log' for more details
error: builder for '/nix/store/r5kgb4zkw82ax5qlqn3acyc5j06gn3a7-alsa-firmware-aarch64-unknown-linux-gnu-1.2.4.drv' failed with exit code 77;
       last 10 log lines:
       > checking whether aarch64-unknown-linux-gnu-gcc accepts -g... yes
       > checking for aarch64-unknown-linux-gnu-gcc option to enable C11 features... (cached) none needed
       > checking whether aarch64-unknown-linux-gnu-gcc understands -c and -o together... yes
       > checking whether the C compiler works... yes
       > checking for C compiler default output file name... a.out
       > checking for suffix of executables...
       > checking whether we are cross compiling... configure: error: in `/build/alsa-firmware-1.2.4':
       > configure: error: cannot run C compiled programs.
       > If you meant to cross compile, use `--build'.
       > See `config.log' for more details
       For full logs, run 'nix log /nix/store/r5kgb4zkw82ax5qlqn3acyc5j06gn3a7-alsa-firmware-aarch64-unknown-linux-gnu-1.2.4.drv'.

@collares
Copy link
Member

collares commented Dec 20, 2021 •
edited
Loading

I guess you can add "CC_FOR_BUILD=${buildPackages.stdenv.cc}/bin/cc" to configureFlags (and maybe add depsBuildBuild = [ buildPackages.stdenv.cc ];, but I don't know if that's needed).

sternenseemann
sternenseemann reviewed Dec 20, 2021
View reviewed changes
@L-as
Copy link
Member Author

L-as commented Dec 20, 2021

@collares

You might have something like boot.binfmt.emulatedSystems = [ "aarch64-linux" ]; in your config masking the mismatch.

This is definitely the issue. So much for purity!

@L-as L-as requested a review from sternenseemann December 20, 2021 11:11
@collares
Copy link
Member

collares commented Dec 21, 2021

Should this target staging?

@L-as L-as mentioned this pull request Dec 22, 2021
Closed
@L-as
Copy link
Member Author

L-as commented Dec 22, 2021

#151645 #151649 #151646 don't target staging, so I think it's fine.

@Artturin
Copy link
Member

Artturin commented Dec 22, 2021

More than 500 rebuilds so this should target staging
The bit generated ucm update also does.

@L-as L-as changed the base branch from master to staging December 22, 2021 11:19
@L-as
Copy link
Member Author

L-as commented Dec 22, 2021

Fixed.

@L-as L-as requested a review from Artturin December 22, 2021 21:29
Artturin
Artturin approved these changes Dec 23, 2021
View reviewed changes
Copy link
Member

@Artturin Artturin left a comment •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tested compiling alsa-utils and pkgsCross.aarch64-multiplatform.alsa-utils but couldn't test running because of (i assume) mismatched system lib versions

./result/bin/speaker-test -t wav -c 6

speaker-test 1.2.6

Playback device is default
Stream parameters are 48000Hz, S16_LE, 6 channels
WAV file(s)
ALSA lib pcm.c:2576:(snd_pcm_open_conf) Unknown field libs
Playback open error: -22,Invalid argument

@L-as
Copy link
Member Author

L-as commented Dec 23, 2021

FWIW you can try the new ALSA for your system while avoiding a whole system recompilation by using Firefox with the old ALSA, that was the main culprit in my case. Firefox does still work, though crashes occasionally when you do this.

@Artturin
Copy link
Member

Artturin commented Dec 23, 2021

the firefox test does test audio so i'll run that https://github.com/NixOS/nixpkgs/blob/master/nixos/tests/firefox.nix

@collares collares mentioned this pull request Dec 23, 2021
Closed
@bobby285271 bobby285271 mentioned this pull request Dec 26, 2021
Merged
@L-as L-as requested a review from bobby285271 January 5, 2022 16:15
AndersonTorres
AndersonTorres previously requested changes Jan 5, 2022
View reviewed changes
AndersonTorres
AndersonTorres reviewed Jan 9, 2022
View reviewed changes
@L-as L-as force-pushed the alsa branch 2 times, most recently from 89e9aea to f3f5254 Compare January 9, 2022 15:45
@L-as
Copy link
Member Author

L-as commented Jan 9, 2022

Is there some rule that says we need to change sha256 = ... to hash = ...?

@ofborg ofborg bot requested review from AndersonTorres and fps January 9, 2022 16:08
@AndersonTorres
Copy link
Member

AndersonTorres commented Jan 9, 2022 •
edited
Loading

Is there some rule that says we need to change sha256 = ... to hash = ...?

Shortest answer:

No.

Long answer: Most of fetchers support hash as well as sha256. I think hash is preferrable because it is more future-proof: what if we need sha512 sums in the future? Not a long time ago we employed md5 attributes, and there is some legacy support for it afaicr.

And the SRI format is because the new nix tool uses it.

This way, I think we should change to hash attribute always when possible. The only serious blocker is some old fetchers (fetchsvn, fetchbower etc.) that were not updated yet.

@L-as
Copy link
Member Author

L-as commented Jan 10, 2022

I do not feel like working on this PR anymore.

@L-as L-as closed this Jan 10, 2022
@L-as
Copy link
Member Author

L-as commented Jan 10, 2022

In the future I suggest that you don't merge PRs like #154038 that cause merge conflicts with this one and don't offer anything more.

@bobby285271
Copy link
Member

bobby285271 commented Jan 10, 2022

Shall I revert #154038 instead (#154038 (comment))?

@bobby285271 bobby285271 mentioned this pull request Jan 10, 2022
Closed
@L-as L-as reopened this Jan 10, 2022
@L-as
Copy link
Member Author

L-as commented Jan 10, 2022

Well actually I still prefer rebasing this to master, do you mind do that?

Sure, I rebased @bobby285271

@L-as
Copy link
Member Author

L-as commented Jan 10, 2022

Ah, just noticed you merged #151649 . Only alsa-firmware here hasn't been updated. I'll close this again.

@L-as L-as closed this Jan 10, 2022
@L-as L-as mentioned this pull request Jan 10, 2022
Merged
13 tasks
@bobby285271
Copy link
Member

bobby285271 commented Jan 10, 2022

Maybe also alsa-lib? (oh that should target staging...)

@L-as L-as mentioned this pull request Jan 10, 2022
Merged
13 tasks
@L-as L-as deleted the alsa branch January 10, 2022 12:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@roastiek roastiek Awaiting requested review from roastiek

@MarcWeber MarcWeber Awaiting requested review from MarcWeber

@sternenseemann sternenseemann Awaiting requested review from sternenseemann

@Artturin Artturin Awaiting requested review from Artturin

@bobby285271 bobby285271 Awaiting requested review from bobby285271

@AndersonTorres AndersonTorres Awaiting requested review from AndersonTorres

@fps fps Awaiting requested review from fps

Assignees

No one assigned

Labels

10.rebuild-darwin: 101-500 This PR causes between 101 and 500 packages to rebuild on Darwin. 10.rebuild-linux: 501+ This PR causes many rebuilds on Linux and should normally target the staging branches. 10.rebuild-linux: 5001+ This PR causes many rebuilds on Linux and must target the staging branches. 11.by: package-maintainer This PR was created by a maintainer of all the package it changes.

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

6 participants

@L-as @collares @Artturin @AndersonTorres @bobby285271 @sternenseemann