You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[BUG] alsatplg: invalid option -- 'I' in debian:unstable #5323
Thanks, now that I see that commit https://github.com/alsa-project/alsa-utils/commits/c8c348e28a258f17e387 is 3 commits after tag v1.2.6. I got confused by the test #if SND_LIB_VER(1, 2, 5) < SND_LIB_VERSION . Maybe the -Iuser interface was added after v1.2.6 but the corresponding feature was added in alsa-lib in 1.2.5?
Funny enough I think we need a container "downgrade" right now, it would have caught this. More precisely, we need to stop using bleeding edge and unreleased versions in our container and stick to official ALSA releases so tests like if(${ALSATPLG_VERSION_NUMBER} VERSION_LESS "1.2.6") get a chance to do something useful which is not the case right now. Right now the container is uniquely successful = the opposite of what's expected from CI.
So we need a new release version for alsatplg and update the check in our scripts.
Should we bump the topology v2 test to the not yet released if(${ALSATPLG_VERSION_NUMBER} VERSION_LESS "1.2.7") in the meantime to fix everyone's build?
As reported here, the latest ALSA version 1.2.6 fails to build anything.
So the only ALSA version that produces something usable right now is 1.2.5. It does not build v2 and is not shipped by any major distro right now (see #5192). Good thing there are few SOF developers :-((
@marc-hb@lgirdwood give me a container, and I'll make it happen. Whatever is decided. If it's a roll-back, just tell me what recent container should be leveraged, and I'll have the reference updated in minutes. That's super easy.
The goal should be to make things working with the released and the development code, if you want to use or test some new functionality ahead of the release. So the version check is irrelevant for this and you need to find another way. Another goal is to be friendly to the users of the build system.
The SND_LIB_VER() checks were added to allow compilation of alsatlg with the older alsa-lib without a strict requirement for the newer alsa-lib in configure.ac . It's a nonstandard configuration and I keep up to the package maintainers or users, if they want to do this for a reason. But the key is that the build does not fail when someone wants to test / update another utility from this package with the older alsa-lib.
Luckily topology2 is not end user released yet, it's still WIP so it can be aligned with ALSA 1.2.7 when its ready. I think short term we need to remind developers that they need ALSA git for topology2 based development.
@marc-hb is this still an issue? so topology2 needs the -I flag and if it is used in our build scripts for topology2, thats an issue, we need to either remove the topology2 compilation until available or message the developers to update to alsa-utils upstream head.
Unfortunately we are in transit with topology2 (some needed functionality not officially released), so what can we do? we can't even compare to release number as it doesn't exist...
Until a released version of alsatplg can successfully build topoV2 I suggest commenting out the wrong alsatplg version check in topology/topology2/CMakeLists.txt and replace it with a test for the (empty) file topology/I_want_unstable_v2. CMake would build v2 if and only if this trigger file is found. Developers and CIs who have a recent enough alsatplg can very easily create this empty file, everyone else still builds topoV1.
Until the next (and worse) problem is found (like some silent corruption?). The explicit topology/I_want_unstable_v2 method provides a manual switch not just for this -I problem but for any future issue too. It's a constant reminder in git status that the topologies are produced by an unreleased and unpredictable alsatplg version. It draws a very clear line between developers who need bleeding edge stuff and others who only want things to just work. It is also a reminder and incentive to replace it with a proper version check when possible later.
Activity
lgirdwood commentedon Feb 8, 2022
@ranj063 @juimonen do we need latest alsa-utils HEAD ?
lgirdwood commentedon Feb 9, 2022
@afq984 can you try with latest alsa-utils HEAD.
@greg-intel fyi - may need a container update.
afq984 commentedon Feb 9, 2022
Haven't tested alsa-utils HEAD, but probably just the version check needs to be updated once
-Imakes itself into a release:sof/tools/topology/topology2/CMakeLists.txt
Line 21 in e5d95d1
marc-hb commentedon Feb 9, 2022
The
-Iis missing on Fedora too, I already reported this in #5192 (comment)I think this
-Ioption is supposed to be present in 1.2.5, so this looks more like an ALSA configuration bug.ranj063 commentedon Feb 9, 2022
@marc-hb the -I option was added after the 1.2.6 release. So we need a new release version for alsatplg and update the check in our scripts.
marc-hb commentedon Feb 9, 2022
Thanks, now that I see that commit https://github.com/alsa-project/alsa-utils/commits/c8c348e28a258f17e387 is 3 commits after tag v1.2.6. I got confused by the test
#if SND_LIB_VER(1, 2, 5) < SND_LIB_VERSION. Maybe the-Iuser interface was added after v1.2.6 but the corresponding feature was added in alsa-lib in 1.2.5?Funny enough I think we need a container "downgrade" right now, it would have caught this. More precisely, we need to stop using bleeding edge and unreleased versions in our container and stick to official ALSA releases so tests like
if(${ALSATPLG_VERSION_NUMBER} VERSION_LESS "1.2.6")get a chance to do something useful which is not the case right now. Right now the container is uniquely successful = the opposite of what's expected from CI.Should we bump the topology v2 test to the not yet released
if(${ALSATPLG_VERSION_NUMBER} VERSION_LESS "1.2.7")in the meantime to fix everyone's build?The current situation
iswas really awful:produces silently corrupted topologies, see revert Revert "topologies: switch all .m4 files to codec_provider and codec_consumer #5192So the only ALSA version that produces something usable right now is 1.2.5. It does not build v2 and is not shipped by any major distro right now (see #5192). Good thing there are few SOF developers :-((
greg-intel commentedon Feb 9, 2022
@marc-hb @lgirdwood give me a container, and I'll make it happen. Whatever is decided. If it's a roll-back, just tell me what recent container should be leveraged, and I'll have the reference updated in minutes. That's super easy.
2 remaining items
perexg commentedon Feb 10, 2022
The goal should be to make things working with the released and the development code, if you want to use or test some new functionality ahead of the release. So the version check is irrelevant for this and you need to find another way. Another goal is to be friendly to the users of the build system.
The SND_LIB_VER() checks were added to allow compilation of alsatlg with the older alsa-lib without a strict requirement for the newer alsa-lib in configure.ac . It's a nonstandard configuration and I keep up to the package maintainers or users, if they want to do this for a reason. But the key is that the build does not fail when someone wants to test / update another utility from this package with the older alsa-lib.
lgirdwood commentedon Feb 16, 2022
Luckily topology2 is not end user released yet, it's still WIP so it can be aligned with ALSA 1.2.7 when its ready. I think short term we need to remind developers that they need ALSA git for topology2 based development.
marc-hb commentedon Feb 16, 2022
This works only as long as all SOF developers know each other.
v2 is really not the worst problem right now. v1 is silently corrupted by most ALSA versions
right now, fixed by revert #5192juimonen commentedon Feb 21, 2022
@marc-hb is this still an issue? so topology2 needs the -I flag and if it is used in our build scripts for topology2, thats an issue, we need to either remove the topology2 compilation until available or message the developers to update to alsa-utils upstream head.
Unfortunately we are in transit with topology2 (some needed functionality not officially released), so what can we do? we can't even compare to release number as it doesn't exist...
marc-hb commentedon Feb 21, 2022
Until a released version of alsatplg can successfully build topoV2 I suggest commenting out the wrong alsatplg version check in
topology/topology2/CMakeLists.txtand replace it with a test for the (empty) filetopology/I_want_unstable_v2. CMake would build v2 if and only if this trigger file is found. Developers and CIs who have a recent enough alsatplg can very easily create this empty file, everyone else still builds topoV1.perexg commentedon Feb 21, 2022
The detection can be automated:
marc-hb commentedon Feb 21, 2022
Until the next (and worse) problem is found (like some silent corruption?). The explicit
topology/I_want_unstable_v2method provides a manual switch not just for this-Iproblem but for any future issue too. It's a constant reminder ingit statusthat the topologies are produced by an unreleased and unpredictable alsatplg version. It draws a very clear line between developers who need bleeding edge stuff and others who only want things to just work. It is also a reminder and incentive to replace it with a proper version check when possible later.topology2: Bump version requirement to 1.2.7
topology2: build only when alsatplg is v1.2.7 or greater
marc-hb commentedon Aug 17, 2022
v1.2.7 is out, tentative fix in:
topology2: build only when alsatplg is v1.2.7 or greater