Re: [External] Re: Intel SOF audio firmware packaging
On 12/12/2020 05:48, Vincent Bernat wrote: > ❦ 11 décembre 2020 20:36 -05, Mark Pearson: > > You need to use "~rc" instead of "-rc", otherwise, users won't be able > to upgrade to "1.6" when they have "1.6-rc3" installed. > Ooops - my bad. I started wearing glasses this year...but don't always put them on :) I've corrected that. Thank you! > >> What do I need to do going forward to look after this? Is there anything >> in particular that is needed as new sof firmware is released? Just >> wanting to check what expectations are going forward and if there is >> anything I should be looking out for etc. > > We wait until monday and then we can upload. When a new firmware is > released, you upgrade your repository on Salsa, ping me, I'll review and > upload. At some point, you may want to become a DM (Debian Maintainer) > to do upload of known packages yourself. > Great. Thanks again for your help. Longer term I'd love to work towards becoming a DM - I think I still have a lot of learning to do though :) >>> Also, did you test the package on real hardware or do you need me to >>> test it? I can test it, I just need to spend 10 minutes doing it. >> Tested on my X1Carbon7 and it works well. I have a bunch of other >> platforms I can try it on too if that helps but it will have to be next >> week. > > No need, I'll test it on mine during the week-end. > Sound good - let me know if any issues. As a note - I did find that for some reason the speaker is muted by default and needed to go into alsamixer to unmute it (someone in the bug saw the same effect and I've seen that previously on the P1G3 with Debian). I don't believe that has anything to do with the SOF firmware but is more likely an issue in ALSA/pulseaudio. I'll dig into that separately. Mark
Re: [External] Re: Intel SOF audio firmware packaging
❦ 11 décembre 2020 20:36 -05, Mark Pearson: >> They seem to say future releases will be tagged. So, I think you should >> use in gbp.conf: >> >> upstream-tag = v%(version%~%-)s >> pristine-tar = False >> >> No need for upstream-branch since you won't use "gbp import-orig" as the >> origin lives directly in git repository. >> > Got it - I've made these changes and pushed them to the repository You need to use "~rc" instead of "-rc", otherwise, users won't be able to upgrade to "1.6" when they have "1.6-rc3" installed. #v+ diff --git a/debian/changelog b/debian/changelog index 1b404ac5e2e6..a5a29a905188 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,4 +1,4 @@ -firmware-sof (1.6-rc3-1) UNRELEASED; urgency=medium +firmware-sof (1.6~rc3-1) UNRELEASED; urgency=medium * Initial release. (Closes: #960788) diff --git a/debian/gbp.conf b/debian/gbp.conf index 12bd6acf629c..ac06bdd3b375 100644 --- a/debian/gbp.conf +++ b/debian/gbp.conf @@ -1,5 +1,5 @@ [DEFAULT] debian-branch = debian/latest -upstream-tag = v%(version%-%-)s +upstream-tag = v%(version%~%-)s pristine-tar = False #v- > What do I need to do going forward to look after this? Is there anything > in particular that is needed as new sof firmware is released? Just > wanting to check what expectations are going forward and if there is > anything I should be looking out for etc. We wait until monday and then we can upload. When a new firmware is released, you upgrade your repository on Salsa, ping me, I'll review and upload. At some point, you may want to become a DM (Debian Maintainer) to do upload of known packages yourself. >> Also, did you test the package on real hardware or do you need me to >> test it? I can test it, I just need to spend 10 minutes doing it. > Tested on my X1Carbon7 and it works well. I have a bunch of other > platforms I can try it on too if that helps but it will have to be next > week. No need, I'll test it on mine during the week-end. -- It is often the case that the man who can't tell a lie thinks he is the best judge of one. -- Mark Twain, "Pudd'nhead Wilson's Calendar"
Re: [External] Re: Intel SOF audio firmware packaging
Thanks Vincent On 11/12/2020 14:22, Vincent Bernat wrote: > owner 960788 markpear...@lenovo.com > quit > > ❦ 11 décembre 2020 12:15 -05, Mark Pearson: > >>> >>> This should do the trick. You may want to tag the upstream commit >>> yourself with upstream/1.6 if you upstream is not consistent with >>> tagging (which seems the case). >> I'm not sure what I need to do here - do I create a tag on my repository >> with the name 1.6 on the v1.6-rc3 branch? >> Just want to make sure I do the right steps :) > > Well, for all these questions, upstream versioning strategy is > confusing. There is the branch stable-v1.6. There is the v1.6-rc3 which > is not part of the stable-v1.6 branch. We need to have a stable version > number. Either the branch stable-v1.6 doesn't move anymore or there are > tags, but upstream is inconsistent because there is no tag others than > v1.6-rc3. Other users are complaining about this as well: > > https://github.com/thesofproject/sof-bin/issues/25 > > They seem to say future releases will be tagged. So, I think you should > use in gbp.conf: > > upstream-tag = v%(version%~%-)s > pristine-tar = False > > No need for upstream-branch since you won't use "gbp import-orig" as the > origin lives directly in git repository. > Got it - I've made these changes and pushed them to the repository > And you need to use 1.6~rc3-1 in debian/changelog since this is the > version you are packaging (1.6~rc3 and the -1 is the Debian part). > 1.6~rc3 orders before 1.6 while 1.6-rc3 orders after, that's why we want > to use "~", while upstream uses "-". > > Also, debian/watch is incorrect as it is watching branches instead of tags. > You need to fix it with: > > version=4 > opts="filenamemangle=s%(?:.*?)?v?(\d.*)\.tar\.gz%@PACKAGE@-$1.tar.gz%;s%-rc%~rc%" > \ > https://github.com/thesofproject/sof-bin/tags \ > (?:.*?/)?v?(\d.*)\.tar\.gz debian uupdate > > You can test with "uscan --report --verbose". > As a note, Stephan Lachlit previously mentioned that I didn't need "debian uupdate" so I've removed that here too. Let me know if you disagree. It all seems to work when I test it :) > As for using an overlay or not, let's stick to your current strategy. If > the repository becomes too big, it's always possible to start a new one. > Not using an overlay is easier for everybody since it's the most common > workflow. Great - works for me! > >>> You may want to either rename firmware-sof-signed.install to install or >>> rename postinst to firmware-sof-signed.postinst. The #!/bin/sh is >>> missing at the top of the postinst script. >> I think I've fixed this now > > You also added "#v+" and "#v-" markers. It was not part of the file. > Some mailers use this to mark code blocks, that's why I have added them. > It was unclear, sorry. > > Also, nitpicking, but either use: > > - firmware-sof-signed.install and firmware-sof-signed.postinst > - install and postinst > > Since you have only one binary package, it's equivalent, but it's just > better to not mix the two. Agreed - this should be fixed in my latest, let me know if I'm missing something. > > Everything else looks good. > >> As I understand it the next step is to find a DM or DD who can sponsor >> this? Any recommendations on how that process works? > > Usually, you can go through mentors.debian.net, upload your package > there and file an "RFS" (request for sponsor). But you don't really need > to do that as I can upload it for you. So, fix the last details above, > I'll do another review and I'll upload if anything is correct. Big thank you! That would be fantastic. What do I need to do going forward to look after this? Is there anything in particular that is needed as new sof firmware is released? Just wanting to check what expectations are going forward and if there is anything I should be looking out for etc. > > Also, did you test the package on real hardware or do you need me to > test it? I can test it, I just need to spend 10 minutes doing it. Tested on my X1Carbon7 and it works well. I have a bunch of other platforms I can try it on too if that helps but it will have to be next week. > > We should also take over the RFS. We were a bit fast in this process. I > am doing that in this email as well for you (with you as owner). We'll > wait a few days if anyone protests. > Sounds good. This process went a lot faster than I expected too - really appreciate all the help and feedback I got from various community members. Very Cool! I'll continue to keep an eye out for any other suggestions/corrections/etc Mark
Re: [External] Re: Intel SOF audio firmware packaging
owner 960788 markpear...@lenovo.com quit ❦ 11 décembre 2020 12:15 -05, Mark Pearson: >>> I did have to comment out "overlay = True" in the gbp.conf - it gave me >>> an error that I'll have to dig into. >> >> That's because you went for the first "classic" solution. I was pushing >> for the overlay solution as the upstream git repository is pushing some >> big files at each release and your git repository will become bigger and >> bigger. With the overlay solution, you only have a debian/latest branch >> and the user is expected to retrieve the tarball to make it work (this >> is automated by uscan, thanks to the debian/watch). > Ah - that makes sense. > Should I be looking at changing what I've done or is the current > solution OK? I'd like to get it as right as it can be. >> >> However, you can keep your repository as is and add to gbp.conf: >> >> upstream-branch = stable-v1.6 >> upstream-tag = v1.6-rc3 >> pristine-tar = False > Great - I've updated the repository with this change. Thank you. >> >> This should do the trick. You may want to tag the upstream commit >> yourself with upstream/1.6 if you upstream is not consistent with >> tagging (which seems the case). > I'm not sure what I need to do here - do I create a tag on my repository > with the name 1.6 on the v1.6-rc3 branch? > Just want to make sure I do the right steps :) Well, for all these questions, upstream versioning strategy is confusing. There is the branch stable-v1.6. There is the v1.6-rc3 which is not part of the stable-v1.6 branch. We need to have a stable version number. Either the branch stable-v1.6 doesn't move anymore or there are tags, but upstream is inconsistent because there is no tag others than v1.6-rc3. Other users are complaining about this as well: https://github.com/thesofproject/sof-bin/issues/25 They seem to say future releases will be tagged. So, I think you should use in gbp.conf: upstream-tag = v%(version%~%-)s pristine-tar = False No need for upstream-branch since you won't use "gbp import-orig" as the origin lives directly in git repository. And you need to use 1.6~rc3-1 in debian/changelog since this is the version you are packaging (1.6~rc3 and the -1 is the Debian part). 1.6~rc3 orders before 1.6 while 1.6-rc3 orders after, that's why we want to use "~", while upstream uses "-". Also, debian/watch is incorrect as it is watching branches instead of tags. You need to fix it with: version=4 opts="filenamemangle=s%(?:.*?)?v?(\d.*)\.tar\.gz%@PACKAGE@-$1.tar.gz%;s%-rc%~rc%" \ https://github.com/thesofproject/sof-bin/tags \ (?:.*?/)?v?(\d.*)\.tar\.gz debian uupdate You can test with "uscan --report --verbose". As for using an overlay or not, let's stick to your current strategy. If the repository becomes too big, it's always possible to start a new one. Not using an overlay is easier for everybody since it's the most common workflow. >> You may want to either rename firmware-sof-signed.install to install or >> rename postinst to firmware-sof-signed.postinst. The #!/bin/sh is >> missing at the top of the postinst script. > I think I've fixed this now You also added "#v+" and "#v-" markers. It was not part of the file. Some mailers use this to mark code blocks, that's why I have added them. It was unclear, sorry. Also, nitpicking, but either use: - firmware-sof-signed.install and firmware-sof-signed.postinst - install and postinst Since you have only one binary package, it's equivalent, but it's just better to not mix the two. Everything else looks good. > As I understand it the next step is to find a DM or DD who can sponsor > this? Any recommendations on how that process works? Usually, you can go through mentors.debian.net, upload your package there and file an "RFS" (request for sponsor). But you don't really need to do that as I can upload it for you. So, fix the last details above, I'll do another review and I'll upload if anything is correct. Also, did you test the package on real hardware or do you need me to test it? I can test it, I just need to spend 10 minutes doing it. We should also take over the RFS. We were a bit fast in this process. I am doing that in this email as well for you (with you as owner). We'll wait a few days if anyone protests. -- Be careful of reading health books, you might die of a misprint. -- Mark Twain
Re: [External] Re: Intel SOF audio firmware packaging
Hi Vincent On 10/12/2020 13:53, Vincent Bernat wrote: > ❦ 10 décembre 2020 12:57 -05, Mark Pearson: > >> I did have to comment out "overlay = True" in the gbp.conf - it gave me >> an error that I'll have to dig into. > > That's because you went for the first "classic" solution. I was pushing > for the overlay solution as the upstream git repository is pushing some > big files at each release and your git repository will become bigger and > bigger. With the overlay solution, you only have a debian/latest branch > and the user is expected to retrieve the tarball to make it work (this > is automated by uscan, thanks to the debian/watch). Ah - that makes sense. Should I be looking at changing what I've done or is the current solution OK? I'd like to get it as right as it can be. > > However, you can keep your repository as is and add to gbp.conf: > > upstream-branch = stable-v1.6 > upstream-tag = v1.6-rc3 > pristine-tar = False Great - I've updated the repository with this change. Thank you. > > This should do the trick. You may want to tag the upstream commit > yourself with upstream/1.6 if you upstream is not consistent with > tagging (which seems the case). I'm not sure what I need to do here - do I create a tag on my repository with the name 1.6 on the v1.6-rc3 branch? Just want to make sure I do the right steps :) > > You may want to either rename firmware-sof-signed.install to install or > rename postinst to firmware-sof-signed.postinst. The #!/bin/sh is > missing at the top of the postinst script. I think I've fixed this now > > Most firmware-* packages seem to ship to /lib/firmware, not > /usr/lib/firmware. As I am using a usr-merged system (this is the > default now), I don't see a difference. From my understanding, in the > future, packages need to ship this way. I think Linux will look into > /lib/firmware only and therefore, this will fail on non-usr-merged > systems. You can fix that by modifying the install file with: > > builddir/usr/lib / I've applied this fix - thank you > > In debian/control, you also need to add Vcs-Browser and Vcs-Git fields > to point to Salsa. Also, maybe the source pakcage could be > `firmware-sof` instead of sof-bin, to match your repository name. Just > update debian/control and debian/changelog. I added the Vcs fields - hoepfully correctly. Source has been updated to match the repo name > > Everything else looks OK for me. > Thank you for all the pointers - very much appreciated. Let me know if you spot anything else that is wrong or can be improved. As I understand it the next step is to find a DM or DD who can sponsor this? Any recommendations on how that process works? Thanks Mark
Re: [External] Re: Intel SOF audio firmware packaging
❦ 10 décembre 2020 12:57 -05, Mark Pearson: > I did have to comment out "overlay = True" in the gbp.conf - it gave me > an error that I'll have to dig into. That's because you went for the first "classic" solution. I was pushing for the overlay solution as the upstream git repository is pushing some big files at each release and your git repository will become bigger and bigger. With the overlay solution, you only have a debian/latest branch and the user is expected to retrieve the tarball to make it work (this is automated by uscan, thanks to the debian/watch). However, you can keep your repository as is and add to gbp.conf: upstream-branch = stable-v1.6 upstream-tag = v1.6-rc3 pristine-tar = False This should do the trick. You may want to tag the upstream commit yourself with upstream/1.6 if you upstream is not consistent with tagging (which seems the case). You may want to either rename firmware-sof-signed.install to install or rename postinst to firmware-sof-signed.postinst. The #!/bin/sh is missing at the top of the postinst script. Most firmware-* packages seem to ship to /lib/firmware, not /usr/lib/firmware. As I am using a usr-merged system (this is the default now), I don't see a difference. From my understanding, in the future, packages need to ship this way. I think Linux will look into /lib/firmware only and therefore, this will fail on non-usr-merged systems. You can fix that by modifying the install file with: builddir/usr/lib / In debian/control, you also need to add Vcs-Browser and Vcs-Git fields to point to Salsa. Also, maybe the source pakcage could be `firmware-sof` instead of sof-bin, to match your repository name. Just update debian/control and debian/changelog. Everything else looks OK for me. -- Make it right before you make it faster. - The Elements of Programming Style (Kernighan & Plauger)
Re: [External] Re: Intel SOF audio firmware packaging
So a big thank you to all who responded with suggestions and advice. Particularly thanks to Stephan Lachnit and Vincent Bernat for providing fixes and improvements directly to my first attempt. I've taken most of what they gave (not all - some pieces still in progress) and have a second attempt up - I created as a new repository with (hopefully) a better name and a better implementation https://salsa.debian.org/mpearson/firmware-sof - I've switched to using gbp-buildpackage. It's currently using the v1.6-rc3 tag from the SOF project. My understanding is this will make it much easier to maintain this. - The improvements in all the debian control/format/rules from Stephan and Vincent are integrated - The copyright file has been updated with the Intel and NXP copyrights. Hopefully it is correct now I'm hoping this is a step closer to where it needs to be. I've done some testing and it's looking good. Any mistakes are my own :) I did have to comment out "overlay = True" in the gbp.conf - it gave me an error that I'll have to dig into. Any suggestions/reviews/comments would be appreciated. Thanks Mark
Re: [External] Re: Intel SOF audio firmware packaging
Hi Paul, On 08/12/2020 21:16, Paul Wise wrote: > On Tue, Dec 8, 2020 at 3:04 PM Mark Pearson wrote: > >> From my point of view (admittedly limited) there is limited benefit to >> building your own unsigned firmware as it won't load on our systems. > > According the discussion I had with Lenovo and Intel folks, Intel > Baytrail/Cherrytrail/Broadwell systems have support for loading > unsigned firmware. If anyone owns hardware from these generations, I > encourage you to work on packaging the unsigned firmware, or to give > it to someone willing to do so. > To my knowledge we don't have any platforms with those CPUs so I wouldn't have the ability to test it. I also don't think I'd be a good candidate for that kind of exercise (both in terms of experience and time). For Lenovo platforms I'd be looking at Whiskeylake, Cometlake and Tigerlake based (using SOF), and my understanding was the signed firmware is required. At least when I've tried unsigned previously the firmware does not load. If somebody more knowledgeable can correct me (with details) that would be great. Mark
Re: [External] Re: Intel SOF audio firmware packaging
On Tue, Dec 8, 2020 at 3:04 PM Mark Pearson wrote: > From my point of view (admittedly limited) there is limited benefit to > building your own unsigned firmware as it won't load on our systems. According the discussion I had with Lenovo and Intel folks, Intel Baytrail/Cherrytrail/Broadwell systems have support for loading unsigned firmware. If anyone owns hardware from these generations, I encourage you to work on packaging the unsigned firmware, or to give it to someone willing to do so. -- bye, pabs https://wiki.debian.org/PaulWise
Re: [External] Re: Intel SOF audio firmware packaging
Hello, El dt., 8 de des. 2020, 16:04, Mark Pearson va escriure: > > I studied the different options time ago, Fedora ships it's own > > separate package, Ubuntu merges it into firmware-linux-nonfree, > > firmware could also be built but dependencies would be hard to > > package/maintain - as I understood - those need a forked xtensa > > compiler. > From my point of view (admittedly limited) there is limited benefit to > building your own unsigned firmware as it won't load on our systems. > I was focusing (selfishly) on the intel-signed firmware and it being a > non-free repository. I'm hoping that's not a big sticking point > > > > > As I understood Maks was given a laptop by Lenovo to test the update > > and he was going to package sof firmware within firmware-linux-nonfree > > - which apparently has not happened yet. > > I don't want to make a big deal out of this, I fully appreciate that > everybody has their own priorities and things going on. 2020 has been a > bit of a basketcase of a year! However, Maks has stopped replying to my > emails and so I'm writing that particular exercise off as a failure at > this point. > > I figured that I would have a go at packaging myself - see what was > involved. If what I've done is complete nonsense and useless, that's > fine - if someone can point out what is wrong I'll try and fix it. > If someone else already has this in hand and I can support that let me > know. > If what I've done is enough to get someone more competent started that > would be awesome too. I'd like to be involved and help out as a learning > exercise but don't want to get in the way. > > I honestly don't mind what happens next. My aim is to get Debian working > on Lenovo platforms and SOF firmware is currently by far and away the > biggest blocker. I had a quiet evening last week so figured I would play > with it and see where it led. I have no expectations at this point - > this is just me having some fun and learning something new. > > > > > If we want to support these laptops in bullseye we need to ship such > firmware. > Right, overall no big fuzz, but it would be nice to get these laptops supported by bullseye. Regards
Re: [External] Re: Intel SOF audio firmware packaging
On 08/12/2020 04:43, Hector Oron wrote: > Hello, > > On Tue, 8 Dec 2020 at 09:47, Jonas Smedegaard wrote: >> >> Quoting Mark Pearson (2020-12-08 04:18:20) >>> On 07/12/2020 21:19, Paul Wise wrote: On Mon, Dec 7, 2020 at 1:58 PM Mark Pearson wrote: > I'd like to solve the lack of Intel SOF audio firmware IIRC the Debian kernel team were planning on adding those to the linux-firmware.git packaging. >>> If that is happening that sounds good to me and quite sensible. Can you >>> point me at who is working on that so I can find out the details? >>> >>> I did do a search before starting on this but didn't find anything - but >>> it would be an easy thing to miss :) >> >> Try file a bugreport against firmware-linux-nonfree - more infor do ding >> that is here: https://www.debian.org/Bugs/Reporting > > A bug was created for new package - https://bugs.debian.org/960788 > That's the bug I raised after your kind recommendations :) > I studied the different options time ago, Fedora ships it's own > separate package, Ubuntu merges it into firmware-linux-nonfree, > firmware could also be built but dependencies would be hard to > package/maintain - as I understood - those need a forked xtensa > compiler. >From my point of view (admittedly limited) there is limited benefit to building your own unsigned firmware as it won't load on our systems. I was focusing (selfishly) on the intel-signed firmware and it being a non-free repository. I'm hoping that's not a big sticking point > > As I understood Maks was given a laptop by Lenovo to test the update > and he was going to package sof firmware within firmware-linux-nonfree > - which apparently has not happened yet. I don't want to make a big deal out of this, I fully appreciate that everybody has their own priorities and things going on. 2020 has been a bit of a basketcase of a year! However, Maks has stopped replying to my emails and so I'm writing that particular exercise off as a failure at this point. I figured that I would have a go at packaging myself - see what was involved. If what I've done is complete nonsense and useless, that's fine - if someone can point out what is wrong I'll try and fix it. If someone else already has this in hand and I can support that let me know. If what I've done is enough to get someone more competent started that would be awesome too. I'd like to be involved and help out as a learning exercise but don't want to get in the way. I honestly don't mind what happens next. My aim is to get Debian working on Lenovo platforms and SOF firmware is currently by far and away the biggest blocker. I had a quiet evening last week so figured I would play with it and see where it led. I have no expectations at this point - this is just me having some fun and learning something new. > > If we want to support these laptops in bullseye we need to ship such firmware. > > Regards > Thanks Mark
Re: [External] Re: Intel SOF audio firmware packaging
> firmware could also be built but dependencies would be hard to > package/maintain - as I understood - those need a forked xtensa > compiler. I'm adopting the firmware-ath9k-htc package at the moment, which also uses a forked xtensa compiler and is built from source. Rather than package the custom toolchain first, I build the toolchain in addition to the firmware at the same time. I don't know that I'll have time before the freeze to help, but after Bullseye is released I think it would be relatively unpainful with my groundwork laid. That said I've not looked at the audio firmware and if it typically needs to be digitally signed, that's a bummer. signature.asc Description: This is a digitally signed message part.
Re: [External] Re: Intel SOF audio firmware packaging
Hello, On Tue, 8 Dec 2020 at 09:47, Jonas Smedegaard wrote: > > Quoting Mark Pearson (2020-12-08 04:18:20) > > On 07/12/2020 21:19, Paul Wise wrote: > > > On Mon, Dec 7, 2020 at 1:58 PM Mark Pearson wrote: > > > > > >> I'd like to solve the lack of Intel SOF audio firmware > > > > > > IIRC the Debian kernel team were planning on adding those to the > > > linux-firmware.git packaging. > > > > > If that is happening that sounds good to me and quite sensible. Can you > > point me at who is working on that so I can find out the details? > > > > I did do a search before starting on this but didn't find anything - but > > it would be an easy thing to miss :) > > Try file a bugreport against firmware-linux-nonfree - more infor do ding > that is here: https://www.debian.org/Bugs/Reporting A bug was created for new package - https://bugs.debian.org/960788 I studied the different options time ago, Fedora ships it's own separate package, Ubuntu merges it into firmware-linux-nonfree, firmware could also be built but dependencies would be hard to package/maintain - as I understood - those need a forked xtensa compiler. As I understood Maks was given a laptop by Lenovo to test the update and he was going to package sof firmware within firmware-linux-nonfree - which apparently has not happened yet. If we want to support these laptops in bullseye we need to ship such firmware. Regards -- Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-.
Re: [External] Re: Intel SOF audio firmware packaging
Quoting Mark Pearson (2020-12-08 04:18:20) > On 07/12/2020 21:19, Paul Wise wrote: > > On Mon, Dec 7, 2020 at 1:58 PM Mark Pearson wrote: > > > >> I'd like to solve the lack of Intel SOF audio firmware > > > > IIRC the Debian kernel team were planning on adding those to the > > linux-firmware.git packaging. > > > If that is happening that sounds good to me and quite sensible. Can you > point me at who is working on that so I can find out the details? > > I did do a search before starting on this but didn't find anything - but > it would be an easy thing to miss :) Try file a bugreport against firmware-linux-nonfree - more infor do ding that is here: https://www.debian.org/Bugs/Reporting - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: [External] Re: Intel SOF audio firmware packaging
Thanks Paul, On 07/12/2020 21:19, Paul Wise wrote: > On Mon, Dec 7, 2020 at 1:58 PM Mark Pearson wrote: > >> I'd like to solve the lack of Intel SOF audio firmware > > IIRC the Debian kernel team were planning on adding those to the > linux-firmware.git packaging. > If that is happening that sounds good to me and quite sensible. Can you point me at who is working on that so I can find out the details? I did do a search before starting on this but didn't find anything - but it would be an easy thing to miss :) Happy to help out, even if just as a test guinea-pig. Mark
Re: [External] Re: Intel SOF audio firmware packaging
Thanks Vincent, On 07/12/2020 09:03, Vincent Bernat wrote: ❦ 7 décembre 2020 08:57 -05, Mark Pearson: I'd like to solve the lack of Intel SOF audio firmware & topology files being available on Debian - I know it's impacting a lot of users on some of the newer Thinkpads. I figured I should have a stab at this exercise myself and see what happens. I did a bit of reading this weekend, and started the process. Having created appropriate files under a debian sub-dir, and messed around a bit, now when running 'debuild -us -uc' from the 1.6 cloned branch of the sof-bin git repo I end up with a .deb file that I can install and makes audio work. Feels like progress :) There are plenty of warnings along the way, and it's my first time doing this so I'm sure I'm doing all sorts of things wrong (there seems like a lot of different options on how to do this); but I figured I have a good starting point. I wasn't sure where to go with this next. Is there anybody in the Debian community with the expertise to spend a bit of time guiding me through the next steps? I think I need someone who can review what I have done and point out where it needs fixing/improving. Once it's good enough then I think I need someone to help me actually get it uploaded and into Debian. There is a bug already available (https://bugs.debian.org/960788) if that helps. Obviously happy to share all the work I've done in an appropriate format if that helps too. Note - I'm new to packaging, I'm not a SOF expert and I'm not a DM or a DD - so someone with patience for dumbass questions would be a bonus. Hello Mark, I can help you, using the easy way: shipping binary firmwares as non-free. I don't think this is worth the effort trying to compile from source while it is not possible to use the compiled firmwares. I agree - I went the non-free route as my understanding is from a practical point of view, that's what makes sense to use the firmware on most PCs. At least it does on Lenovo's. I figure for people who need/want to use non intel signed firmware they probably have their own hardware and know more about SOF firmware than me. I'm not really sure what other vendors do but I know in Lenovo's case the signed firmware is a requirement that I can't change. You can either use salsa.debian.org or mentors.debian.net to expose your current work. Tell me if it means something for you or if I need to explain. I replied to Jonathan's email, so at the risk of having two threads, I did just upload what I have here: https://salsa.debian.org/mpearson/sof-bin-packaging Let me know if that doesn't work as a starting point, very happy to change it for whatever works best for Debian folk. Thanks Mark
Re: [External] Re: Intel SOF audio firmware packaging
On 07/12/2020 11:13, Jonathan Carter wrote: On 2020/12/07 18:07, Mark Pearson wrote: I pushed what I have to https://salsa.debian.org/mpearson/sof-bin-packaging It's pretty basic :) Seems like you haven't committed go.sh? (and hopefully more files?) -Jonathan They're all in the upstream sof-bin repository In theory (ha!) if you try the steps in the Readme it should give you a .deb Should I be making a copy of the upstream sof-bin repository? The file I've uploaded go on top of that. Mark
Re: [External] Re: Intel SOF audio firmware packaging
On 2020/12/07 18:07, Mark Pearson wrote: > I pushed what I have to https://salsa.debian.org/mpearson/sof-bin-packaging > > It's pretty basic :) Seems like you haven't committed go.sh? (and hopefully more files?) -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Debian, the universal operating system.
Re: [External] Re: Intel SOF audio firmware packaging
Thanks Jonathan, On 07/12/2020 10:15, Jonathan Carter wrote: Hi Mark On 2020/12/07 15:57, Mark Pearson wrote: I did a bit of reading this weekend, and started the process. Having created appropriate files under a debian sub-dir, and messed around a bit, now when running 'debuild -us -uc' from the 1.6 cloned branch of the sof-bin git repo I end up with a .deb file that I can install and makes audio work. Feels like progress :) That sounds like great progress! There are plenty of warnings along the way, and it's my first time doing this so I'm sure I'm doing all sorts of things wrong (there seems like a lot of different options on how to do this); but I figured I have a good starting point. I wasn't sure where to go with this next. Push it to a git repository and/or mentors.debian.net and send a link, I'd be happy to also take a look and give some pointers. -Jonathan I pushed what I have to https://salsa.debian.org/mpearson/sof-bin-packaging It's pretty basic :) Thanks Mark
