Hi, Thanks for the advice. I am right now unsure how to solve it since I am on thud but I will continue to work on this so once I get this done and I have a solution that works I will try and remember to come back and try to write something together for anyone else encountering this issue.
/Måns Den mån 11 apr. 2022 kl 18:20 skrev Khem Raj <[email protected]>: > > On Mon, Apr 11, 2022 at 1:29 AM Mans Zigher <[email protected]> wrote: > > > > This is my first time working with them so I am learning a lot but > > never encountered anything like it. Trying to look into what it would > > require to move to a newer version it appears as if they have set up > > their layers inside the poky dir and then they are using COREBASE when > > one layer depends on the content of another layer. So again something > > that should have been fairly simple will now require some additional > > work. But thanks for all your help I appreciate it. I am getting a bit > > off topic in this thread. > > This will be valiant effort but my advice is don't go alone if you > want to undertake this > SOC sdks have lot of nitty gritty issues that will pop up along the > way and unless you > have someone from SOC suppliers actively supporting you on this upgrade you > will > burn your time to no end. > > > > > For anyone having issues with enabling INCOMPATIBLE_LICENSE make sure > > to set it per image but before that you will have to make sure you are > > not including any packages that have the incompatible license there is > > some tedious work but it needs to be done. > > Perhaps a write-up will be beneficial for someone who trips into these > issues in future. > > > > > Thanks > > > > Den mån 11 apr. 2022 kl 09:16 skrev Alexander Kanavin > > <[email protected]>: > > > > > > It's a contracting issue. You need to specify in writing that the > > > vendor cannot provide ancient Yocto. Otherwise they won't bother. > > > > > > Alex > > > > > > On Mon, 11 Apr 2022 at 09:13, Måns <[email protected]> wrote: > > > > > > > > Yes I know. Not sure why QC is stuck on Thud. Even newer releases from > > > > QC for the target that we are working on is stuck at Thud. > > > > > > > > Mans > > > > > > > > Den fre 8 apr. 2022 kl 18:59 skrev Alexander Kanavin > > > > <[email protected]>: > > > > > > > > > > Thud has been EOL for a long time. You can see when the support been > > > > > added here (end of 2019 it seems): > > > > > https://git.yoctoproject.org/poky/log/meta/lib/oeqa/selftest/cases/incompatible_lic.py?h=master-next > > > > > > > > > > Alex > > > > > > > > > > On Fri, 8 Apr 2022 at 18:56, Måns <[email protected]> wrote: > > > > > > > > > > > > I am currently on Thud so I am missing the support from what I can > > > > > > tell to set INCOMPATIBLE_LICENSE per image. I have tried to find the > > > > > > commit that adds that support but am having some problems finding > > > > > > it. > > > > > > Do you maybe know what I should look for to find the commit that > > > > > > adds > > > > > > this support? > > > > > > > > > > > > Thanks > > > > > > > > > > > > Den fre 8 apr. 2022 kl 10:16 skrev Alexander Kanavin > > > > > > <[email protected]>: > > > > > > > > > > > > > > Hello Mans, > > > > > > > > > > > > > > please refer to the tests we have for the feature: > > > > > > > https://git.yoctoproject.org/poky/tree/meta/lib/oeqa/selftest/cases/incompatible_lic.py?h=master-next#n95 > > > > > > > (line 95 and below) > > > > > > > > > > > > > > The key bit is: > > > > > > > INCOMPATIBLE_LICENSE:pn-core-image-minimal = "GPL-3.0* LGPL-3.0*" > > > > > > > e.g. apply the restriction only to core-image-minimal. > > > > > > > > > > > > > > Alex > > > > > > > > > > > > > > On Fri, 8 Apr 2022 at 08:06, Måns <[email protected]> wrote: > > > > > > > > > > > > > > > > Hi Alex, > > > > > > > > > > > > > > > > Could you maybe clarify what you mean with "setting > > > > > > > > INCOMPATIBLE_LICENSE per image"? Do you mean that you have one > > > > > > > > specific image that is used when you build an image for release > > > > > > > > to the > > > > > > > > customer and then one image for development? > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > Den ons 6 apr. 2022 kl 11:04 skrev Alexander Kanavin > > > > > > > > <[email protected]>: > > > > > > > > > > > > > > > > > > I'd suggest you start by setting INCOMPATIBLE_LICENSE per > > > > > > > > > image, e.g. > > > > > > > > > enable gpl3 ban only in the images that ship to the customers > > > > > > > > > and not > > > > > > > > > across the entire build. Then carefully look at what pulls in > > > > > > > > > bash > > > > > > > > > into those images and why, and reconfigure those pieces to > > > > > > > > > not do that > > > > > > > > > (e.g. by reconfiguring the PACKAGECONFIGs), or rewrite the > > > > > > > > > scripts in > > > > > > > > > posix shell. > > > > > > > > > > > > > > > > > > Alex > > > > > > > > > > > > > > > > > > On Wed, 6 Apr 2022 at 10:59, Mans Zigher > > > > > > > > > <[email protected]> wrote: > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > I cannot use GPLv3 packages in our image build. I am no > > > > > > > > > > legal expert > > > > > > > > > > but from what I can understand most companies will not be > > > > > > > > > > able to > > > > > > > > > > comply with this license without allowing the customer to > > > > > > > > > > compile and > > > > > > > > > > deploy a new version of any GPLv3 package to the target. I > > > > > > > > > > know it is > > > > > > > > > > possible to comply with this but we are using secure boot > > > > > > > > > > and have not > > > > > > > > > > the time and probably no interest in setting up a solution > > > > > > > > > > for > > > > > > > > > > allowing customers to be able to deploy GPLv3 packages on > > > > > > > > > > the target. > > > > > > > > > > We are trying to make use of INCOMPATIBLE_LICENSE but that > > > > > > > > > > results in > > > > > > > > > > several issues. We have made sure that we don't include > > > > > > > > > > GPLv3 in the > > > > > > > > > > image build using a manual process but would like to use > > > > > > > > > > INCOMPATIBLE_LICENSE to alert any developer about the > > > > > > > > > > issue. It seems > > > > > > > > > > like INCOMPATIBLE_LICENSE is a bit harsh since it will > > > > > > > > > > catch any > > > > > > > > > > packages even if it is only part of the SDK and also for > > > > > > > > > > native > > > > > > > > > > packages that are not part of the image build. > > > > > > > > > > > > > > > > > > > > I cannot be the only one with this problem so how are other > > > > > > > > > > companies > > > > > > > > > > solving this issue? Are they just not using the > > > > > > > > > > INCOMPATIBLE_LICENSE? > > > > > > > > > > Are you setting up a parallel process for checking for any > > > > > > > > > > incompatible licenses issues? > > > > > > > > > > > > > > > > > > > > A more specific issue is that there are so many packages > > > > > > > > > > with bash > > > > > > > > > > dependencies which are pulling in bash which is GPLv3 so > > > > > > > > > > how have you > > > > > > > > > > solved that? Currently we have done some pretty uggly hacks > > > > > > > > > > which I am > > > > > > > > > > not that happy with but we needed to keep it out of the > > > > > > > > > > image. > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#56741): https://lists.yoctoproject.org/g/yocto/message/56741 Mute This Topic: https://lists.yoctoproject.org/mt/90285507/21656 Group Owner: [email protected] Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
