go.sh is broken since v1.7

The 1.7 release changed the repo's file layout without adjusting go.sh, so this way of installing the firmware is now broken. It should either be fixed or removed.

It should not be needed anymore, a recursive copy should be enough now, can you first confirm a recursive copy is enough? I recommend rsync -a.

@marc-hb

@marc-hb if these are not needed they should be deleted and also Readme.md updated to use your new flows.

It should not be needed anymore, a recursive copy should be enough now, can you first confirm a recursive copy is enough? I recommend rsync -a.

I'm using this now, which seems to work (with details specific to Arch Linux):

local fwdir="$pkgdir/usr/lib/firmware/intel"
mkdir -p "$fwdir"
cp -a sof-v$pkgver "$fwdir/sof"
cp -a sof-tplg-v$pkgver "$fwdir/sof-tplg"

@heftig

Thanks @heftig, looks good. Please keep letting us how you consume this release and how it goes because as you noticed this is the very first time SOF is released with this new, simpler layout (and corresponding build scripts, see thesofproject/sof#3862) so feedback from every distro is gold especially now.

I'm recommending rsync -a over cp -a because I think cp is flawed for recursive copies because it's not idempotent:

rm -rf dstdir
cp -a srcdir dstdir # does one thing
cp -a srcdir dstdir # does something else when run a second time
cp -a srcdir dstdir # does nothing at last

cp is also inconsistent across operating systems: cp srcdir/ dstdir is idempotent on macOS but not with GNU coreutils.

I bet this does not matter in your specific case but in general it should be easy and quick to run installation commands any number of times. Avoiding recursive cp also saves me getting caught by subtle bugs caused by the above.

The loss of being able to use go.sh for package construction is disappointing, and I'll have to see if the Void distro maintainers will accept the use of rsync. I agree that the script should be removed if it will no longer work for future releases, since its inclusion will likely result in confusion.

The loss of being able to use go.sh for package construction is disappointing, and I'll have to see if the Void distro maintainers will accept the use of rsync.

I think a recursive rsync is more reliable than a recursive cp but rsync is not a requirement at all. The only requirement is the ability to perform a recursive copy with anything that can preserve symbolic links. I hope that's not too demanding from a packaging and installation perspective.

I agree that the script should be removed if it will no longer work for future releases, since its inclusion will likely result in confusion.

Will do.

sof-firmware: update to 1.7

I think a recursive rsync is more reliable than a recursive cp but rsync is not a requirement at all. The only requirement is the ability to perform a recursive copy with anything that can preserve symbolic links. I hope that's not too demanding from a packaging and installation perspective.

My concern was that, since Void has pretty strict requirements for packaging, I wouldn't be allowed to use rsync to move files over and I would be forced to use cp or potentially even vcopy, the latter of which has no option to preserve links. As you can see from the above link, I was able to use rsync, so it's all good. Thank you for agreeing to remove go.sh in future releases!

@lgirdwood

@lgirdwood @marc-hb can we please fix this? I wanted to install v1.7 and I am just wasting time with non-functional scripts and obsolete documentation. Thank you.

Edit: I did things manually....

rm -rf /lib/firmware/intel/sof/
rm -rf /lib/firmware/intel/sof-tplg/
mkdir /lib/firmware/intel/sof/
mkdir /lib/firmware/intel/sof-tplg
cd sof-tplg-v1.7/
cp sof-tgl-rt715-rt711-rt1308-mono.tplg /lib/firmware/intel/sof-tplg/
cd ..
cd sof-v1.7/
cp sof-tgl.ldc /etc/sof/
cp sof-tgl.ri /lib/firmware/intel/sof
cd ../tools-v1.7/
chmod +x *
cp * /usr/local/bin

sof-firmware: update to 1.7

@marc-hb

@marc-hb any comments here ?

New README.md and install.sh for v1.7

@plbossart

I had great plans to get rid of the git branches and simplify a bit the install of older releases too but I lowered my expectations and merely added a new README.md and small install.sh script, please review #40

Also fixed the tools' missing +x permissions, sorry about that. @plbossart which tools do you actually use in practice? I've only used the sof-logger so far. I doubt anyone would ever use an sof-fuzzer _release, @cujomalainey ?

I suspect most distributions will prefer to compile them from source anyway as they normally do for everything user space.

@ranj063

sof-fuzzer is not actively used, oss-fuzz is the successor and is actively used. In theory the only additional space covered by that fuzzer is the tplg_parser which i think is not high risk soi i would be fine deprecating it once i expand oss-fuzz a bit more. @ranj063 thoughts?

@cujomalainey

@cujomalainey my question was specifically about using a binary release of sof-fuzzer (or oss-fuzz). Wouldn't anyone fuzzing do everything from source?

yes, there is no reason to release the fuzzers.

New README.md and install.sh for v1.7

Navigation Menu

Repository navigation

go.sh is broken since v1.7 #38

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

go.sh is broken since v1.7 #38

Description

Activity

marc-hb commented on Apr 7, 2021

lgirdwood commented on Apr 7, 2021

heftig commented on Apr 7, 2021

marc-hb commented on Apr 7, 2021

cinerea0 commented on Apr 13, 2021

marc-hb commented on Apr 13, 2021

cinerea0 commented on Apr 14, 2021

plbossart commented on Apr 28, 2021

lgirdwood commented on May 6, 2021

marc-hb commented on May 6, 2021

cujomalainey commented on May 6, 2021

marc-hb commented on May 6, 2021

cujomalainey commented on May 6, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions