openembedded-architecture@lists.openembedded.org

Home Messages Hashtags Subgroups

Messages

Between

and

Re: [Automated-testing] RFC Linter in meta-openembedded

Dear Alex, Richard was kind enough to forward my email. Thanks @Richard. I’m happy to continue the discussion here. Best Marius

By Marius Kriegerowski · #1449 ·

Re: [Automated-testing] RFC Linter in meta-openembedded

Sounds fair. I’ll have a look. Thanks for pointing that out.

By Marius Kriegerowski · #1448 ·

Re: [Automated-testing] RFC Linter in meta-openembedded

This is the harder issue that needs to be resolved and implemented first, before we start arguing about what is a good set of rules to apply. There is a already a linter that is integrated into the

By Alexander Kanavin · #1447 ·

Re: [Automated-testing] RFC Linter in meta-openembedded

Done :) A very short wrap-up for those who don’t have a GitHub account: I proposed to add oelint-adv to meta-openembedded as part of the GitHub CI pipeline. I know that many find oelint-adv too

By Marius Kriegerowski · #1446 ·

Re: [Automated-testing] RFC Linter in meta-openembedded

Yes, except you aren't subscribed to the list, so your replies won't be seen by everyone, and you won't get replies that aren't CCd directly to you. Please take the trouble, and do embrace that awful

By Alexander Kanavin · #1445 ·

Re: [Automated-testing] RFC Linter in meta-openembedded

Marius, I know you want everyone to move to github and abandon email (seeing the previous thread), but asking everyone to go there for the 'discussion' won't get you far. Please write a proposal,

By Alexander Kanavin · #1444 ·

[Automated-testing] RFC Linter in meta-openembedded

Sharing a copy of this to openembedded-architecture. Cheers, Richard

By Richard Purdie · #1443 ·

Re: Status and future of npm and go support

Am 18.01.2022 um 15:37 schrieb Bruce Ashfield: Is it possible to see the code? Both solutions have advantages. The SRC_URI approach is known to OE developers but the manifest and lock file is

By Stefan Herbrechtsmeier · #1442 ·

Re: Status and future of npm and go support

Am 18.01.2022 um 15:32 schrieb Bruce Ashfield: The manifest and lock files are text, json or toml files. They list the name, version, url, checksum and sometimes path of every dependency. If we want

By Stefan Herbrechtsmeier · #1441 ·

Re: Status and future of npm and go support

<stefan.herbrechtsmeier-oss@...> wrote: It's done at the source level, just the same way that we've been manually checking vendor/ subdirectories up until now (except better, since we

By Bruce Ashfield · #1440 ·

Re: Status and future of npm and go support

<stefan.herbrechtsmeier-oss@...> wrote: That depends if lock files are in the implementation I guess :) The requirement to patch a lock file would be language specific, (and I know

By Bruce Ashfield · #1439 ·

Re: Status and future of npm and go support

Am 18.01.2022 um 15:10 schrieb Bruce Ashfield: Do you extract the licenses from dependencies and populate the license checksums? Do you prefer to populate the SRC_URI or would a direct use of the

By Stefan Herbrechtsmeier · #1438 ·

Re: Status and future of npm and go support

Am 18.01.2022 um 15:06 schrieb Bruce Ashfield: But this requires that you can patch lock files. Do we need to patch the file or is it okay to place an alternative lock file beside the recipe into the

By Stefan Herbrechtsmeier · #1437 ·

Re: Status and future of npm and go support

<richard.purdie@...> wrote: For go, I've been working on a generated SRC_URI (via a .inc file) for the source dependencies (but the low level tool to do that is outside of recipetool,

By Bruce Ashfield · #1436 ·

Re: Status and future of npm and go support

<richard.purdie@...> wrote: I think there might be a slight ambiguity in what people think of as dependency management. We've been allowing projects in go to carry their dependencies

By Bruce Ashfield · #1435 ·

Re: Status and future of npm and go support

I think either can be acceptable, it really depends on the situation. Cheers, Richard

By Richard Purdie · #1434 ·

Re: Status and future of npm and go support

Am 18.01.2022 um 14:40 schrieb Richard Purdie: But do we have a consensus that we prefer existing lock files and a specific fetcher instead of a multi line SRC_URI generated by recipetool?

By Stefan Herbrechtsmeier · #1433 ·

Re: Status and future of npm and go support

I think so. It isn't the perfect solution but it is what will likely be the most successful/practical. I don't think it makes sense to dictate that and make a hard rule. Where there are many

By Richard Purdie · #1432 ·

Re: Status and future of npm and go support

Hi Richard, Am 18.01.2022 um 11:26 schrieb Richard Purdie: In summary we use a language specific lock file based approach which support offline build, license checks and CVE scans and leaves the

By Stefan Herbrechtsmeier · #1431 ·

Re: Status and future of npm and go support

Ideally we will need this information to be visible to our tools, yes. No. I deliberately tried to stress the most important things we needed to ensure. There are other important things too, e.g. the

By Richard Purdie · #1430 ·

261 - 280 of 1709

Home Hashtags Subgroups Terms