Re: [External] Re: Intel SOF audio firmware packaging
Thanks Vincent
On 11/12/2020 14:22, Vincent Bernat wrote:
> owner 960788 markpearson@lenovo.com
> quit
>
> ❦ 11 décembre 2020 12:15 -05, Mark Pearson:
>
<snip>
>>>
>>> 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
Reply to: