New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[gatesgarth] QT build is broken #495
Comments
I'm aware of this issue, but I don't plan to add nobranch in meta-qt5, see #377 (review) |
I'm running into this problem as well. Is there a workaround for it? |
Not really. The real answer is to quit picking "Z" branches where it's versioned X.Y.Z or use a specific githash for the commit in question. Messy, but the problem people have is that there's upstream devs that absolutely don't have a handle on this.- they will delete the offending tags or worse. It was rather annoying trying to use the version tags that FreeRTOS has because they put the tags in and apparently deleted them or propagated them from a mirror improperly. @shr-project : SOMETHING needs to be done. It makes it where only Master is safe for people to use- and at some point, we can't do reproducible builds because your stuff and the Qt projects' is nothing to rely upon. If I'm mirroring it because I can't rely on its history, etc. to be consistent, why bother? |
SRCREV uses specific git hashes, but bitbake fetcher also checks that these git hashes are on the specified branch. Which isn't true after they deleted the X.Y.Z branches which they asked me to use instead of X.Y branches where the releases used to be downmerged (a I was waiting with meta-qt5 updates until that happened). Now they disable this check everywhere with nobranch=1 which is stupid, but I'm not The Qt Company employee, I was never paid by them and I've done enough to get their shit together (see https://bugreports.qt.io/browse/QTQAINFRA-3091 and #349 (comment) ). Merging nobranch=1 in meta-qt5 active branches wouldn't fix projects which are using older revision (for whatever reason, I know about big project still using 5.12.11 instead of warrior branch head with 5.12.12 and they have the same issue, for them I've created jansa/warrior-overrides branch where this is fixed (with only one nobranch in qtbase recipe, because only qtbase v5.12.12 tag isn't in any branch, other were downmerged to 5.12). Others need to deal with it on their own or ask TQC to restore the branches as I said there "Branches are cheap, breaking existing projects like meta-qt5 without good reason is not.". Also keep in mind that bitbake fetcher supports PREMIRROR, anyone serious about long term build reproducibility should use them (the branches aren't pruned there and builds still work fine). Adding nobranch at that time won't help, because if you want your builds reproducible in future you don't want to modify the metadata to make it buildable after branches are renamed or deleted, while keeping corresponding snapshot of PREMIRROR for your release builds is relatively easy and covers all possible source issues (tarballs removed or re-created, repos completely deleted etc). |
Hi all,
Seems that changes in the upstream QT repositories have broken meta-qt5 for Yocto 3.2 Gatesgarth. Upstream branches 5.15.2 have been deleted and thus building in yocto fails at fetching with:
Not sure what is the proper fix for this. Maybe changing the not-existing branch for nobranch=1 in the recipes is the way to go, but I'm not sure if this has side effects.
The text was updated successfully, but these errors were encountered: