From: Martin Jansa <martin.jansa@gmail.com>
To: Daniel Mack <daniel@zonque.org>
Cc: openembedded-devel <openembedded-devel@lists.openembedded.org>
Subject: Re: [meta-qt5][PATCH] qt5: Update to Qt 5.11.0
Date: Wed, 20 Jun 2018 20:06:20 +0200 [thread overview]
Message-ID: <20180620180620.GC3257@jama> (raw)
In-Reply-To: <67f7d601-e2e7-63c8-ac49-2cf27345853d@zonque.org>
[-- Attachment #1: Type: text/plain, Size: 3494 bytes --]
On Wed, Jun 20, 2018 at 03:52:19PM +0200, Daniel Mack wrote:
> On Wednesday, June 20, 2018 01:29 PM, Martin Jansa wrote:
> > On Wed, Jun 20, 2018 at 12:50:52PM +0200, Daniel Mack wrote:
> >> On Wednesday, June 20, 2018 12:36 PM, Martin Jansa wrote:
> >>> It's already in meta-qt5/master with couple fixes on top of that.
> >>
> >> Ah, sorry. For some reason, I only looked into the -next branches.
> >
> > Well, meta-qt5/master-next is exactly the same as meta-qt5/master :).
> >
> >> Stupid. FWIW, I have a patch for 5.11.1 ready. Will send once the build
> >> succeeded.
> >
> > I've started rebasing the patches in meta-qt5 as well, but we cannot use
> > 5.11.1 until downmerge to 5.11 is finished, because:
> >
> > 1) we cannot use 5.11.1 branch, because they might delete this branch at
> > any time (like with 5.10.1)
>
> But there's also a v5.11.1 tag, which is unlikely to be deleted?
This is true. But not good enough for bitbake fetcher.
> I might miss something and I haven't followed the discussions, but is
> your idea to drop the explicit SRCREVs in the recipes in favor of
> AUTOREV and a branch name?
Definitely not.
bitbake fetcher checks out the defined SRCREV, but also checks that the
revision exists in the branch specified in branch parameter ("master" is
the default when the parameter is missing), if the revision exists, but
isn't in the specified branch then an error is shown (which happens when
upstream deletes the branch e.g. 5.10.1 branch and the revision of v5.10.1
tag which is used in SRCREV exists currently only in 5.11 and dev
branches.
qtbase $ git branch -a --contains v5.10.1 | grep origin
remotes/origin/5.11
remotes/origin/5.11.0
remotes/origin/5.11.1
remotes/origin/dev
remotes/origin/wip/qbs2
remotes/origin/wip/webassembly
There is fix for meta-qt5/sumo which is using 5.10.1:
https://patchwork.openembedded.org/patch/151543/
but that's quite unfortunate to use 5.11 branch from 5.10.1 recipes..
That's why I was waiting with 5.9.6 upgrade until it was downmerged to
5.9 branch:
qtbase $ git branch -a --contains v5.9.6 | grep origin
remotes/origin/5.9
remotes/origin/5.9.6
and now I wait for the same with v5.11.1
qtbase $ git branch -a --contains v5.11.1 | grep origin
remotes/origin/5.11.1
AUTOREV is just for people who want to track latest revision in given
branch (e.g. in CI builds).
It's not acceptable to use AUTOREV by default in public layers, because
that would break the build every other day without any change in the
metadata so it would be a mess to use such layer. But in some layers we
were providing .inc files for easy switch between well-tested SRCREVs
and bleeding edge AUTOREV e.g. for developers.
> FWIW, I've written a small shell script that retrieves the SHA1 for each
> of the qt projects and updates the .bb files automatically. That seems
> to work quite well, and I'm happy to share it. There's still the problem
> with downstream patches and other necessary changes in the recipes for
> new Qt versions, but that's an issue either way.
I have some scripts as well, SRCREV is the easy part, updating the
patches in meta-qt5 and corresponding branches/tags on meta-qt5/qt*
repos is the tricky part, because only small part of it can be
automated - that's probably why I'm the only one who updates them when I
find the time :).
Cheers,
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 201 bytes --]
prev parent reply other threads:[~2018-06-20 18:06 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-29 9:25 [meta-qt5][PATCH] qt5: Update to Qt 5.11.0 Samuli Piippo
2018-06-06 20:05 ` Martin Jansa
2018-06-08 4:21 ` Samuli Piippo
2018-06-15 5:44 ` Samuli Piippo
2018-06-20 10:07 ` Daniel Mack
2018-06-20 10:36 ` Martin Jansa
2018-06-20 10:50 ` Daniel Mack
2018-06-20 11:29 ` Martin Jansa
2018-06-20 11:57 ` Samuli Piippo
2018-06-20 12:19 ` Martin Jansa
2018-06-20 13:38 ` Samuli Piippo
2018-06-21 5:14 ` Samuli Piippo
2018-06-21 9:03 ` Martin Jansa
2018-06-21 9:55 ` Samuli Piippo
2018-06-20 13:52 ` Daniel Mack
2018-06-20 18:06 ` Martin Jansa [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180620180620.GC3257@jama \
--to=martin.jansa@gmail.com \
--cc=daniel@zonque.org \
--cc=openembedded-devel@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.