On Mon, Dec 6, 2021 at 4:47 AM Ross Burton wrote:
>
> ldflags.patch isn't really suitable for upstream, so mark inappropriate.
>
> fix_ranlib.patch has been rebased into uselessness over time, it's now
> setting RANLIB to just '$@' which expands to '' when called, so is a
> null operation.
this
On Mon, Dec 6, 2021 at 4:47 AM Ross Burton wrote:
>
> ldflags.patch isn't really suitable for upstream, so mark inappropriate.
>
> fix_ranlib.patch has been rebased into uselessness over time, it's now
> setting RANLIB to just '$@' which expands to '' when called, so is a
> null operation.
>
not
On Mon, Dec 6, 2021 at 3:32 PM Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:
> On Mon, 2021-12-06 at 15:28 -0800, Khem Raj wrote:
> >
> >
> > On Mon, Dec 6, 2021 at 2:51 PM Richard Purdie
> > wrote:
> > > I did test such a patch today as well since we discussed it. I'd
> propose
>
This email is a follow-up from the session held on Friday at the
OpenEmbedded Developer's Virtual Meeting (see
https://www.openembedded.org/wiki/OEDVM_Nov_2021)
The session was not recorded, but the slides can be found at
On Mon, 2021-12-06 at 15:28 -0800, Khem Raj wrote:
>
>
> On Mon, Dec 6, 2021 at 2:51 PM Richard Purdie
> wrote:
> > I did test such a patch today as well since we discussed it. I'd propose
> > this
> > commit message since we need to say why:
> >
> > """
> >
> > glibc: Drop ppc sqrt
On Mon, 2021-12-06 at 16:35 +0100, Quentin Schulz wrote:
> blocklist has a more obvious meaning than blacklist and is also not an
> issue wrt inclusivity, so let's use that naming instead.
A "blocklist" with a filesystem is unfortunately confusing (a list of block
numbers on the filesystem?).
On Mon, Dec 6, 2021 at 2:51 PM Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:
> I did test such a patch today as well since we discussed it. I'd propose
> this
> commit message since we need to say why:
>
> """
>
> glibc: Drop ppc sqrt optimisations
>
> OpenEmbedded isn't an upstream
On Mon, 2021-12-06 at 13:13 -0600, Alex Stewart wrote:
> You beat me to posting my own recipe upgrade commit. :)
>
> Toward the bottom of the opkg_*.bb recipe file is a
> `package_qa_check_openssl_deprecation` function which I added in the
> 0.4.5 release to warn BB users when they are building
We're no longer patching files called "libm-test-ulps" so this patch isn't
really needed. Regardless, if we were, we should fix the real issue in the
upstream code which may have already happened. Drop this patch.
Signed-off-by: Richard Purdie
---
...m-err-tab.pl-with-specific-dirs-in-S.patch |
On Mon, 2021-12-06 at 16:35 +0100, Quentin Schulz wrote:
> Hi all,
>
> It seems some changes are not too invasive and can be made to be a bit
> more inclusive, so I'll make the autobuilder try those patches and tell
> me whether I broke something somewhere I wasn't aware of.
>
> In other words:
I did test such a patch today as well since we discussed it. I'd propose this
commit message since we need to say why:
"""
glibc: Drop ppc sqrt optimisations
OpenEmbedded isn't an upstream or a patch repository. These are optimisations
which for reasons unknown were never merged into upstream
Signed-off-by: Khem Raj
---
...5500-e6500-603e-fsqrt-implementation.patch | 1581 -
...undefined-reference-to-__sqrt_finite.patch | 205 ---
...-are-now-inline-functions-and-call-o.patch | 384
...-are-now-inline-functions-and-call-o.patch | 58 -
Fixes
| powerpc-yoe-linux/11.2.0/ld: libavformat/libavformat.so: undefined reference
to `__atomic_fetch_sub_8'
Signed-off-by: Khem Raj
---
meta/recipes-multimedia/ffmpeg/ffmpeg_4.4.1.bb | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-multimedia/ffmpeg/ffmpeg_4.4.1.bb
All,
The triage team is starting to try and collect up and classify bugs which a
newcomer to the project would be able to work on in a way which means people
can find them. They're being listed on the triage page under the appropriate
heading:
Patch looks good to me! ACK all.
Thanks,
--
Alex Stewart
Software Engineer - NI Real-Time OS
NI (National Instruments)
alex.stew...@ni.com
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159268):
You beat me to posting my own recipe upgrade commit. :)
Toward the bottom of the opkg_*.bb recipe file is a
`package_qa_check_openssl_deprecation` function which I added in the
0.4.5 release to warn BB users when they are building opkg with the
openssl options. Could you amend your patchset
From: Jasper Orschulko
Using a task instead of a version specific patch for setting the repo
revision within the source code. This drastically decreases the
maintenance burden and easier usage of the OE update helper.
Signed-off-by: Jasper Orschulko
---
.../0001-Set-REPO_REV-to-v2.17.3.patch
From: Jasper Orschulko
Signed-off-by: Jasper Orschulko
---
meta/recipes-devtools/repo/{repo_2.17.3.bb => repo_2.18.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-devtools/repo/{repo_2.17.3.bb => repo_2.18.bb} (95%)
diff --git
On Fri, Dec 3, 2021 at 10:07 AM Andre McCurdy wrote:
>
> On Fri, Dec 3, 2021 at 2:06 AM Richard Purdie
> wrote:
> >
> > On Fri, 2021-12-03 at 01:39 -0800, Andre McCurdy wrote:
> > > On Wed, Dec 1, 2021 at 2:33 PM Richard Purdie
> > > wrote:
> > > >
> > > > On Tue, 2021-11-30 at 13:45 -0800,
Nevermind ;)
Alex
On Mon, 6 Dec 2021 at 16:35, Quentin Schulz wrote:
> Golden image has a more explicit meaning than masterimage and is not an
> issue wrt inclusivity.
>
> Signed-off-by: Quentin Schulz
> ---
> .../{masterimage.py => goldenimage.py}| 32 +--
> 1 file
I'd use grep here and (case-insensitively) find all references to
masterimage in poky/. It's likely the file and the class can be renamed as
well without significant damage.
Alex
On Mon, 6 Dec 2021 at 16:35, Quentin Schulz wrote:
> golden image has a more explicit meaning in addition of not
Please do not forget mesa-gl recipe as well.
Alex
On Mon, 6 Dec 2021 at 16:06, zhengruoqin wrote:
> Changelog from 21.3.0
> =
> Bug fixes:
> GPU Crash in Yuzu 6600xt 5.15
> [spirv-fuzz] lower_trivial_continues_block: Assertion
Thanks - since there's already documented nomenclature for this situation,
I tweaked the patch to simply use that.
Alex
On Mon, 6 Dec 2021 at 17:47, Konrad Weihmann wrote:
> To quote the documentation:
>
>Inappropriate [reason]
>- The patch is not appropriate for upstream, include a
To quote the documentation:
Inappropriate [reason]
- The patch is not appropriate for upstream, include a brief reason
on the
same line enclosed with []
reason can be:
...
no upstream (the upstream is no longer available -- dead project)
so I think this is already
I just sent the proper fix to bitbake-devel :)
Alex
On Mon, 6 Dec 2021 at 17:41, Konrad Weihmann wrote:
> It's of course *not* the file extension, but the .orig. that is
> confusing the default upstream regex check
>
> This here worked for me
>
> UPSTREAM_CHECK_REGEX =
It's of course *not* the file extension, but the .orig. that is
confusing the default upstream regex check
This here worked for me
UPSTREAM_CHECK_REGEX = "${BPN}_(?P\d+(\.\d+)+)\.orig\..*"
but surely it can be fine tuned
On 06.12.21 17:30, Konrad Weihmann wrote:
I think the answer is that
On Mon, 2021-12-06 at 16:50 +0100, Alexander Kanavin wrote:
> I mean, if you insisit, we can add Upstream-Status: Defunct, but I do not
> think keeping patches in Pending state when there is no upstream is right
> either.
Maybe we should add an Upstream-Inactive status?
Cheers,
Richard
I think the answer is that latest release is a bz2, while the older one
are gzipped
http://ftp.debian.org/debian/pool/main/m/minicom/minicom_2.7.1.orig.tar.gz
vs.
http://ftp.debian.org/debian/pool/main/m/minicom/minicom_2.8.orig.tar.bz2
On 06.12.21 16:57, Alexander Kanavin wrote:
This one is
On Mon, 6 Dec 2021 at 17:13, Khem Raj wrote:
> There is a slightly different explanation here. libpthread was merged into
> libc
>
>> so this fix becomes a null-op on glibc. Not sure if musl has a separate
>> pthread
>> but if so we could/should test that?
>
>
> Musl has always been a single
On Mon, Dec 6, 2021 at 3:07 AM Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:
> On Sat, 2021-12-04 at 08:13 +0100, Alexander Kanavin wrote:
> > I ran the reproducing sequence on qemux86, and it went fine:
> >
> > root@qemux86:~# python3
> > Python 3.10.0 (default, Oct 4 2021,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
In regards to automatic update patch generation this actually is pretty
useful. I think I'll throw an extra patch on top to integrate this
suggestion.
- --
With best regards
Jasper Orschulko
DevOps Engineer
Tel. +49 30 58 58 14 265
Fax +49 30 58
This one is odd and it should be working. I'll cherry-pick your update and
get to the bottom of it. This may mean we are missing other updates that
are coming from debian tarballs.
Alex
On Mon, 6 Dec 2021 at 14:59, Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:
> On Mon, 2021-12-06
I mean, if you insisit, we can add Upstream-Status: Defunct, but I do not
think keeping patches in Pending state when there is no upstream is right
either.
Alex
On Mon, 6 Dec 2021 at 16:45, Alexander Kanavin via lists.openembedded.org
wrote:
> On Mon, 6 Dec 2021 at 15:08, Ross Burton wrote:
>
On Mon, 6 Dec 2021 at 15:08, Ross Burton wrote:
> On Mon, 6 Dec 2021 at 11:03, Alexander Kanavin
> wrote:
> > Presumably, that someone would start updating the repo and making
> releases, at which point we can reevaluate the situation with the patches.
> As of today, they are inappropriate.
>
>
On Mon, Dec 6, 2021 at 9:35 AM Quentin Schulz wrote:
>
> "golden" has a more explicit meaning than master in addition to not
> being an issue wrt inclusivity.
I don't think "golden" has the same meaning here. Perhaps "controller"
or something similar?
>
> Signed-off-by: Quentin Schulz
> ---
>
I tend to agree. Vim has a strange release policy where major releases
happen infrequently and allow unfixed issues to pile up, but minor releases
are tagged for every single commit. And so it becomes hard for integrators
to pick an update strategy between those thousands of commits, and even
Hi all,
It seems some changes are not too invasive and can be made to be a bit
more inclusive, so I'll make the autobuilder try those patches and tell
me whether I broke something somewhere I wasn't aware of.
In other words: I did not test those changes.
Those changes warrant some notes in the
blocklist has a more obvious meaning than blacklist and is also not an
issue wrt inclusivity, so let's use that naming instead.
Signed-off-by: Quentin Schulz
---
.../initrdscripts/files/init-install-efi-testfs.sh | 2 +-
.../initrdscripts/files/init-install-efi.sh| 2 +-
"golden" has a more explicit meaning than master in addition to not
being an issue wrt inclusivity.
Signed-off-by: Quentin Schulz
---
meta/conf/distro/include/distro_alias.inc | 4 ++--
meta/conf/distro/include/maintainers.inc| 4 ++--
golden image has a more explicit meaning in addition of not being an
issue wrt inclusivity.
Signed-off-by: Quentin Schulz
---
meta/lib/oeqa/controllers/masterimage.py | 10 +-
meta/lib/oeqa/runtime/cases/ssh.py | 4 ++--
Golden image has a more explicit meaning than masterimage and is not an
issue wrt inclusivity.
Signed-off-by: Quentin Schulz
---
.../{masterimage.py => goldenimage.py}| 32 +--
1 file changed, 16 insertions(+), 16 deletions(-)
rename
Changelog:
===
* Various improvements and bug fixes:
- codegen:
+ Use CCodeConstant for member access of constant symbol
+ Emit constants without initializer list in defines section [#440]
+ Add and use CCodeConstantIdentifier for accessing constants
+ Check required
Signed-off-by: Wang Mingyu
---
.../recipes-graphics/xorg-app/{xauth_1.1.bb => xauth_1.1.1.bb} | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
rename meta/recipes-graphics/xorg-app/{xauth_1.1.bb => xauth_1.1.1.bb} (75%)
diff --git a/meta/recipes-graphics/xorg-app/xauth_1.1.bb
Changelog:
===
* iostat: Always display persistent names with option -j.
* iostat: Fix how device mapper names are taken into account when
entered on the command line.
* mpstat: Don't display offline CPU.
* mpstat: Fix values displayed when an offline CPU goes back online.
*
Signed-off-by: Wang Mingyu
---
.../pango/{pango_1.48.10.bb => pango_1.50.0.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-graphics/pango/{pango_1.48.10.bb => pango_1.50.0.bb} (94%)
diff --git a/meta/recipes-graphics/pango/pango_1.48.10.bb
Changelog from 21.3.0
=
Bug fixes:
GPU Crash in Yuzu 6600xt 5.15
[spirv-fuzz] lower_trivial_continues_block: Assertion '!first_instr ||
instr_is_continue(first_instr)' failed.
[RADV] Crash in Metro Exodus in Caspain chapter and Sam???s Story
Signed-off-by: Zheng Ruoqin
---
.../opkg-utils/{opkg-utils_0.4.5.bb => opkg-utils_0.5.0.bb}| 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
rename meta/recipes-devtools/opkg-utils/{opkg-utils_0.4.5.bb =>
opkg-utils_0.5.0.bb} (94%)
diff --git
refresh 0001-Use-pkg-config-for-pcre-dependency-instead-of-config.patch
Changelog from 1.4.61:
Important changes:
support pcre2; HTTP Digest auth userhash
bugfixes:
[mod_alias] fix use-after-free bug (fixes #3114)
[core] clean up fdlog_st and log_error_st
Remove unsupported openssl and option --disable-pathfinder
Signed-off-by: Zheng Ruoqin
---
meta/recipes-devtools/opkg/{opkg_0.4.5.bb => opkg_0.5.0.bb} | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
rename meta/recipes-devtools/opkg/{opkg_0.4.5.bb => opkg_0.5.0.bb} (92%)
diff --git
Remove unsupported option "--enable-sdl-dlopen".
Changelog:
===
General:
The SDL wiki documentation and development headers are automatically kept in
sync
Each function has information about in which version of SDL it was introduced
SDL-specific CMake options are now
There's a fairly constant flow of CVEs being fixed in Vim, which are
getting increasing non-trivial to backport.
Instead of trying to backport (and potentially introduce more bugs), or
just ignoring them entirely, upgrade vim to the latest patch in the hope
that vim 8.3 will be released before we
On Mon, 2021-12-06 at 12:37 +0100, Alexander Kanavin wrote:
> On Mon, 6 Dec 2021 at 12:29, Richard Purdie
> wrote:
> > Ross has a point here. If we go this route we'll just push people to mark
> > patches as Inappropriate instead. People will know Pending isn't acceptable
> > so
> > they'll just
On Mon, 6 Dec 2021 at 11:03, Alexander Kanavin wrote:
> Presumably, that someone would start updating the repo and making releases,
> at which point we can reevaluate the situation with the patches. As of today,
> they are inappropriate.
But how, in two years time, would we know to re-evaluate
On Mon, 2021-12-06 at 14:43 +0100, Alexander Kanavin wrote:
> Since AUH didn't pick this up, can you run 'devtool latest-version minicom'
> with this update, as it probably would report something that needs fixing via
> regexp?
That shows:
WARNING: latest_versionstring: package
Since AUH didn't pick this up, can you run 'devtool latest-version minicom'
with this update, as it probably would report something that needs fixing
via regexp?
Alex
On Mon, 6 Dec 2021 at 14:06, Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:
> * Update the url to use .bz2 instead
* Update the url to use .bz2 instead of .gz compression.
* Drop three patches merged upstream
* Submit two patches upstream
* Drop the musl patch since half was already applied upstream and
musl now builds fine without the other piece
Signed-off-by: Richard Purdie
---
ldflags.patch isn't really suitable for upstream, so mark inappropriate.
fix_ranlib.patch has been rebased into uselessness over time, it's now
setting RANLIB to just '$@' which expands to '' when called, so is a
null operation.
Signed-off-by: Ross Burton
---
These three patches are backports from upstream, mark as such.
Signed-off-by: Richard Purdie
---
.../0001-Drop-superfluous-global-variable-definitions.patch | 2 +-
.../0002-Drop-superfluous-global-variable-definitions.patch | 2 +-
On Mon, 6 Dec 2021 at 12:29, Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:
> Ross has a point here. If we go this route we'll just push people to mark
> patches as Inappropriate instead. People will know Pending isn't
> acceptable so
> they'll just use Inappropriate and we'll lose
On Mon, 2021-12-06 at 12:21 +0100, Alexander Kanavin wrote:
> On Mon, 6 Dec 2021 at 12:15, Alexander Kanavin via lists.openembedded.org
> wrote:
> > On Mon, 6 Dec 2021 at 11:24, Ross Burton wrote:
> > >
> > > As much as I hate pending patches, and I really do hate patches that
> > > sit in
On Mon, 6 Dec 2021 at 12:15, Alexander Kanavin via lists.openembedded.org
wrote:
> On Mon, 6 Dec 2021 at 11:24, Ross Burton wrote:
>
>>
>> As much as I hate pending patches, and I really do hate patches that
>> sit in pending, there are situations where you know the problem, can
>> work around
Patch was merged to upstream gcc, update status.
Signed-off-by: Richard Purdie
---
.../gcc/gcc/0012-gcc-Fix-argument-list-too-long-error.patch| 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
a/meta/recipes-devtools/gcc/gcc/0012-gcc-Fix-argument-list-too-long-error.patch
On Mon, 6 Dec 2021 at 11:24, Ross Burton wrote:
>
> As much as I hate pending patches, and I really do hate patches that
> sit in pending, there are situations where you know the problem, can
> work around it, but still want to push it upstream at some point
> pending further discussion.
>
On Sat, 2021-12-04 at 08:13 +0100, Alexander Kanavin wrote:
> I ran the reproducing sequence on qemux86, and it went fine:
>
> root@qemux86:~# python3
> Python 3.10.0 (default, Oct 4 2021, 17:55:55) [GCC 11.2.0] on linux
> Type "help", "copyright", "credits" or "license" for more information.
>
On Mon, 6 Dec 2021 at 11:25, Ross Burton wrote:
> On Sat, 4 Dec 2021 at 07:13, Alexander Kanavin
> wrote:
> > -Upstream-Status: Pending
> > +Upstream-Status: Inappropriate [last release in 2015, last commit in
> 2019]
>
> If someone picked up Serf maintainership tomorrow, would these patches
>
Hello everyone,
This is the full report for yocto-3.4.1.rc1:
https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults
=== Summary
No high milestone defects.
new issue found
Bug 14622 - bsps-hw.bsps-hw.Test_Seek_bar_and_volume_control
On Sun, 5 Dec 2021 at 01:24, Peter Kjellerstedt
wrote:
> > stdio: ERROR: Nothing PROVIDES 'doxygen-native' (but
> > /home/pokybuild/yocto-worker/qemux86-world-alt/build/meta/recipes-graphics/xorg-lib/libxkbcommon_1.3.1.bb,
> >
On Sat, 4 Dec 2021 at 07:13, Alexander Kanavin wrote:
> -Upstream-Status: Pending
> +Upstream-Status: Inappropriate [last release in 2015, last commit in 2019]
If someone picked up Serf maintainership tomorrow, would these patches
be suitable upstream? If so, then they're not Inappropriate.
On Mon, 6 Dec 2021 at 08:36, Alexander Kanavin wrote:
> Misuse of 'Pending' patch status has been a problem for a long time;
> let's disallow that in any newly added patches. Please do the upsream
> submission at the same time as you submit the patch to oe-core.
As much as I hate pending
Misuse of 'Pending' patch status has been a problem for a long time;
let's disallow that in any newly added patches. Please do the upsream
submission at the same time as you submit the patch to oe-core.
Signed-off-by: Alexander Kanavin
---
meta/classes/insane.bbclass | 11 +
On Mon, 6 Dec 2021 at 06:45, pgowda wrote:
> When mozjs in firefox is built with DEBUG_BUILD = "1"
> in local.conf, it will fail with the following error:
>rustc-1.56.0-src/vendor/compiler_builtins/src/int/specialized_div_rem
> /asymmetric.rs:57:
>more undefined references to
From: Stefan Herbrechtsmeier
The selftest recipetool base class reuse the selftest devtool base
class. Thereby the selftest devtool base class setup its own devtool
sstate and the selftest recipetool classes trigger the build of recipes.
This leads to the problem that the build artifacts doesn't
From: Stefan Herbrechtsmeier
The recipetool support two ways to pass a branch and fallback to master
if no branch is defined. Add tests for default branch, branch parameter
and srcbranch option.
Signed-off-by: Stefan Herbrechtsmeier
---
This commit changes the test repository from
From: Stefan Herbrechtsmeier
Split tests into separate test classes to speed up individual test runs
by reducing the test setup to a minimum.
The pkgdata generation is only needed for the append tests and slow down
the other tests.
Signed-off-by: Stefan Herbrechtsmeier
---
From: Stefan Herbrechtsmeier
The commit 'meta/scripts: Manual git url branch additions (dc53fe75cc)'
sets the branch= parameter too early to master and thereby breaks the
-B/--srcbranch option.
ERROR: branch= parameter and -B/--srcbranch option cannot both be specified -
use one or the other
75 matches
Mail list logo
