| Message ID | 20260321073820.1403645-1-zboszor@gmail.com |
|---|---|
| Headers | show |
| Series | gn: upgrade to latest revision | expand |
On Sat Mar 21, 2026 at 8:36 AM CET, Zoltan Boszormenyi via lists.openembedded.org wrote: > > The latest revision of gn is needed to build Chromium 145 > for whinlatter. Nothing else. > > See https://github.com/OSSystems/meta-browser/pull/963 > > Please merge these into whinlatter. Hello, Sorry but general upgrades like this are not acceptable for stable. Is there a verifiable stability promise from gn upstream that would somehow make that acceptable? Note that I'm not familiar with it. Regards, > > Thanks in advance, > Zoltán Böszörményi
2026. 03. 21. 10:19 keltezéssel, Yoann Congal írta: > On Sat Mar 21, 2026 at 8:36 AM CET, Zoltan Boszormenyi via lists.openembedded.org wrote: >> The latest revision of gn is needed to build Chromium 145 >> for whinlatter. Nothing else. >> >> See https://github.com/OSSystems/meta-browser/pull/963 >> >> Please merge these into whinlatter. > Hello, > > Sorry but general upgrades like this are not acceptable for stable. I can keep the gn_git.bbappend in the meta-browser PR. But then it's not better when every layer shipped their version before moving it to core. > Is there a verifiable stability promise from gn upstream that would > somehow make that acceptable? Note that I'm not familiar with it. Chromium updates carry a lot of CVE fixes, too. gn is just a build tool for it and other projects.
On Sat Mar 21, 2026 at 3:02 PM CET, Böszörményi Zoltán wrote: > 2026. 03. 21. 10:19 keltezéssel, Yoann Congal írta: >> On Sat Mar 21, 2026 at 8:36 AM CET, Zoltan Boszormenyi via lists.openembedded.org wrote: >>> The latest revision of gn is needed to build Chromium 145 >>> for whinlatter. Nothing else. >>> >>> See https://github.com/OSSystems/meta-browser/pull/963 >>> >>> Please merge these into whinlatter. >> Hello, >> >> Sorry but general upgrades like this are not acceptable for stable. > > I can keep the gn_git.bbappend in the meta-browser PR. > > But then it's not better when every layer shipped their version > before moving it to core. > >> Is there a verifiable stability promise from gn upstream that would >> somehow make that acceptable? Note that I'm not familiar with it. > > Chromium updates carry a lot of CVE fixes, too. > gn is just a build tool for it and other projects. Yes I understand. But this upgrade has feature changes in it (see below) and those are generaly unacceptable on the risk breaking existing code and our stability promise. Your whole series upgrade gn by 43 commits. I saw these ones that are problematic just by reading the commit title: $ git log --oneline 81b24e01531ecf0eff12ec9359a555ec3944ec4e..9d19a7870add65151ff91bcc26252bb7521065cf 7498ca2e Add validation support to gn analyze/desc/path/refs 3c0f5be7 Add pcm files to the deps of phony target bd3356ac Add `validations` dependency type to targets 1d89b984 Add conductor setup files 4e0818fd Add a sha256 hash implementation and use it for string_hash 0eb071f6 Add a `module_name` flag to source_set. bf891ce4 Refactor module name to be dynamic. 8450d601 Optimize vector creation in compile_commands_writer.cc. 6e0b557d Run 'tools/run_formatter.sh' ab6f8b21 Implement `string_hash` function. d92aee22 Support weak_libraries 4619125b Do not add .inputdeps paths to --ninja-outputs-file fb3b73df Make clang modules output -fmodule-file=foo=<pcm>. e7f32021 Add --file_relation to gn refs command 20a6b6d6 Optimize vector initialization and preallocation in desc_builder.cc. a0c5124a Add `reserve` statement when vector size is known beforehand. 092f4f0d Refactor container update by preferring the range insert. If you want a shared repo with an upgraded gn for LTS, what do you think about creating a mixin layer? https://wiki.yoctoproject.org/wiki/Stable_Release_and_LTS#LTS_%E2%80%9CMixin%E2%80%9D_repositories https://git.yoctoproject.org/meta-lts-mixins For whinlatter (stable but not a LTS) which have more or less a month of support left, the bbappend in your layer is, IMHO, the realistic solution. Regards,
2026. 03. 21. 19:45 keltezéssel, Yoann Congal írta: > On Sat Mar 21, 2026 at 3:02 PM CET, Böszörményi Zoltán wrote: >> 2026. 03. 21. 10:19 keltezéssel, Yoann Congal írta: >>> On Sat Mar 21, 2026 at 8:36 AM CET, Zoltan Boszormenyi via lists.openembedded.org wrote: >>>> The latest revision of gn is needed to build Chromium 145 >>>> for whinlatter. Nothing else. >>>> >>>> See https://github.com/OSSystems/meta-browser/pull/963 >>>> >>>> Please merge these into whinlatter. >>> Hello, >>> >>> Sorry but general upgrades like this are not acceptable for stable. >> I can keep the gn_git.bbappend in the meta-browser PR. >> >> But then it's not better when every layer shipped their version >> before moving it to core. >> >>> Is there a verifiable stability promise from gn upstream that would >>> somehow make that acceptable? Note that I'm not familiar with it. >> Chromium updates carry a lot of CVE fixes, too. >> gn is just a build tool for it and other projects. > Yes I understand. > But this upgrade has feature changes in it (see below) and those are > generaly unacceptable on the risk breaking existing code and our > stability promise. > > Your whole series upgrade gn by 43 commits. I saw these ones that are > problematic just by reading the commit title: > $ git log --oneline 81b24e01531ecf0eff12ec9359a555ec3944ec4e..9d19a7870add65151ff91bcc26252bb7521065cf > 7498ca2e Add validation support to gn analyze/desc/path/refs > 3c0f5be7 Add pcm files to the deps of phony target > bd3356ac Add `validations` dependency type to targets > 1d89b984 Add conductor setup files > 4e0818fd Add a sha256 hash implementation and use it for string_hash > 0eb071f6 Add a `module_name` flag to source_set. > bf891ce4 Refactor module name to be dynamic. > 8450d601 Optimize vector creation in compile_commands_writer.cc. > 6e0b557d Run 'tools/run_formatter.sh' > ab6f8b21 Implement `string_hash` function. At least this one is needed by Chromium 145. Its do_configure failed due to missing function. > d92aee22 Support weak_libraries > 4619125b Do not add .inputdeps paths to --ninja-outputs-file > fb3b73df Make clang modules output -fmodule-file=foo=<pcm>. > e7f32021 Add --file_relation to gn refs command > 20a6b6d6 Optimize vector initialization and preallocation in desc_builder.cc. > a0c5124a Add `reserve` statement when vector size is known beforehand. > 092f4f0d Refactor container update by preferring the range insert. > > If you want a shared repo with an upgraded gn for LTS, what do > you think about creating a mixin layer? > https://wiki.yoctoproject.org/wiki/Stable_Release_and_LTS#LTS_%E2%80%9CMixin%E2%80%9D_repositories > https://git.yoctoproject.org/meta-lts-mixins > > For whinlatter (stable but not a LTS) which have more or less a month of > support left, the bbappend in your layer is, IMHO, the realistic > solution. meta-browser is not my layer, I just create PRs for it. Thanks, anyway. cc-ed the maintainer of meta-browser. Maybe it would be best to branch off whinlatter and cherry-pick new versions and add the gn bbappend there later.