| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| *** | ChanServ sets mode: +v mchehab | [02:17] |
| .................................................... (idle for 4h15mn) | ||
| hverkuil | mchehab: let me know when media-tree has been synced to mainline. I'll rebase my for-v5.4a branch and post the pull request for it. | [06:32] |
| ................................................................ (idle for 5h18mn) | ||
| Ha! v5.3-rc1! | [11:50] | |
| mchehab | hverkuil: v5.3-rc1 merged | [11:56] |
| hverkuil | Preparing my PR. | [11:56] |
| mchehab | do you have more fixes for 5.3? | [11:56] |
| hverkuil | no | [11:56] |
| mchehab | ok, so I'll be sending the PR for the two ones | [11:56] |
| hverkuil | Great. | [11:57] |
| mchehab | sent | [11:58] |
| ....... (idle for 32mn) | ||
| hverkuil | I'm hitting this https://lkml.org/lkml/2019/7/5/156 since this fix isn't in -rc1. It's already in mainline though, so will appear in -rc2.
Hmm, scratch that. | [12:30] |
| ............... (idle for 1h12mn) | ||
| FYI: CONFIG_KASAN_OUTLINE crashed the kernel-under-test when booting my virtme image with qemu, I had to switch to CONFIG_KASAN_INLINE. Didn't pursue this any further, but just in case someone else hits this...
(with v5.3-rc1, that is) | [13:44] | |
| ..... (idle for 22mn) | ||
| mchehab: posted PR. It would be great if this can be merged soon since it touches on so many sources. | [14:07] | |
| mchehab | yeah, I'll likely merge it today | [14:11] |
| ...................... (idle for 1h48mn) | ||
| hverkuil | mchehab: are you sure about the PR for v5.4? It is clearly based on top of "Merge tag 'v5.3-rc1' into patchwork" if you look at git log of that branch.
https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=for-v5.4a2 | [15:59] |
| mchehab | weird
caching issues somewhere? at your second series: testing if patches/0001-0006-media-v4l2-ctrl-Move-compound-control-validation.patch applies patch -p1 -i patches/0001-0006-media-v4l2-ctrl-Move-compound-control-validation.patch --dry-run -t -N checking file drivers/media/v4l2-core/v4l2-ctrls.c Reversed (or previously applied) patch detected! Skipping patch. 1 out of 1 hunk ignored drivers/media/v4l2-core/v4l2-ctrls.c | 126 +++++++++++++++++++---------------- # GIT Patches from git://linuxtv.org/hverkuil/media_tree.git tags/br-v5.4b let me wipe out my quilt tree and generate it from scratch same thing it seems that cgit is providing an outdated version of the branch no From 5260b59f999721d5c32b02ba3ac5132d158cc28d Mon Sep 17 00:00:00 2001 that's the same as: authorHans Verkuil <hverkuil-cisco@xs4all.nl>2019-06-11 13:48:54 (GMT) committerHans Verkuil <hverkuil-cisco@xs4all.nl>2019-07-22 12:14:52 (GMT) commit5260b59f999721d5c32b02ba3ac5132d158cc28d (patch) https://git.linuxtv.org/hverkuil/media_tree.git/commit/?h=for-v5.4a2&id=5260b59f999721d5c32b02ba3ac5132d158cc28d hmm... it seems that my tree was dirty somehow I mean my working copy no, that's not the problem either hverkuil: your tree was not based on v5.3-rc1 I did a rebase here and the rebased patches apply cleanly | [16:00] |
| hverkuil | I'm confused. My tree was based on media_tree/master. Did I do something wrong? | [16:16] |
| mchehab | it sounds so
those two fix patches at the fix branches, for example, are there a simple rebase worked fine and the patches after it work ok I suspect you probably merged back from some other branch causing some differences at the codeset anyway, no need to re-submit that branch... I'm applying the patches from my rebased version (but please check the results) | [16:16] |
| hverkuil | I'm a bit worried since I applied all these patches on top of https://git.linuxtv.org/media_tree.git/log/ | [16:19] |
| mchehab | do you want me then to just wait for you to do another rebase and test if everything is ok? | [16:20] |
| hverkuil | There is nothing for me to rebase. It's really based on top of media_tree/master. | [16:21] |
| mchehab: just go ahead and push. I'll pull and check. | [16:27] | |
| mchehab | I'm pretty sure your tree has something else... that's the diff between it, and the rebased version (after removing the two patches that are at the fixes branch):
https://pastebin.com/TpRK57GG I suspect you did a git merge somewhere in time... (probably a long time ago), and now it did just a git merge instead of a git rebase | [16:30] |
| hverkuil | Hold on, you committed those fixes to our master branch. Those are in that diff.
(I got this in media-commits: [git:media_tree/master] media: videodev2.h: change V4L2_PIX_FMT_BGRA444 define: fourcc was already in use) | [16:38] |
| .... (idle for 16mn) | ||
| mchehab | It sholdn't be there...
I have multiple working branches from a single tree using git-new-workdir extension | [16:54] |
| hverkuil | I did a complete fresh git clone. | [16:55] |
| mchehab | perhaps this is causing issues after some git version upgrade? | [16:55] |
| hverkuil | and git log include/uapi/linux/videodev2.h clearly shows this commit. | [16:55] |
| mchehab | git-new-workdir is at git contrib branch, and it is not part of "mainstream"
this is what I see here on my master branch: 3f98538c7673 (origin/patchwork) Merge tag 'v5.3-rc1' into patchwork 5f9e832c1370 (tag: v5.3-rc1, tag: stable/v5.3-rc1, linus/master, docs-next/master, to_next) Linus 5.3-rc1 | [16:56] |
| hverkuil | git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git m
cd m git remote add linuxtv git://linuxtv.org/media_tree.git git remote update git checkout -b linuxtv linuxtv/master git log include/uapi/linux/videodev2.h |less git version 2.20.1 | [16:56] |
| mchehab | right | [16:59] |
| hverkuil | These two fix commit were made well before you merged v5.3-rc1, so they are buried somewhere deep in the top level git log. | [16:59] |
| mchehab | true, it is there | [17:00] |
| hverkuil | it's dinner time. I'll check in later this evening. | [17:01] |
| mchehab | with is weird, as Linus just pulled it:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c92f0380673bd295c9ac73030a17c16b9df3e702 and it applied fine upstream did some sha hash collision happen???? | [17:01] |
| hverkuil | as far as I can tell you just committed those two fixes to our master 11 days ago by accident.
then merged v5.3-rc1 on top. At least, that is what I observe. And now Linux merged those fixes from a fixes branch (where you also committed them) into mainline. | [17:06] |
| mchehab | the changeset at the fixes branch is the same.
-rwxr-xr-x. 1 root root 1886 jun 18 2012 /usr/local/bin/git-new-workdir git-new-workdir is too old I guess I'll re-clone from master, and re-create the several workdirs using the latest git-new-workdir I'll ping you after doing it that's the latest change to git-new-workdir: commit e32afab7b0376a7b07601a87cd5c6841ff2a811a Author: Paul Smith <paul@mad-scientist.net> Date: Wed Nov 26 15:38:28 2014 -0500 git-new-workdir: don't fail if the target directory is empty | [17:07] |
| ......... (idle for 44mn) | ||
| hverkuil: I recreated my branches
still the same issue I fail to see what's wrong | [17:54] | |
| ........... (idle for 50mn) | ||
| I think I know what it could have happened... I added a "-W" flag when doing the diff
that increases the context lines to cover an entire function I bet that's the reason why patches failed to apply (still doesn't explain the issue with a rebased branch) but that's the only thing that changed on my environment that could possible explain the merge errors | [18:47] | |
| ..... (idle for 22mn) | ||
| hverkuil: merged
patches/lmml_57634_git_pull_for_v5_4_fix_device_caps_don_t_set_fmt_description.patch | [19:11] | |
| hverkuil | mchehab: thanks! You can expect more PRs this week. | [19:17] |
| mchehab | ok, good!
syoung: it seems that you're using a branch instead of a tag for your pull requests: error: FETCH_HEAD: cannot verify a non-tag object of type commit. git can only verify signed tags | [19:17] |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |