>
> Sona,
>
> Does it make more sense to update to 1.0.1j directly (I know it's late in the
> 1.7 release cycle), but given there are 3 other CVEs fixed in 'j'
> along with some other fixes. People may look more at the version that is
> part of 1.7 than the back ported fixes.
>
> Please review
On 10/15/2014 10:50 PM, Sona Sarmadi wrote:
This patch is a backport from OpenSSL_1.0.1j.
(From upstream: 6bfe55380abbf7528e04e59f18921bd6c896af1c)
"Unfortunately there are still ancient and broken servers in use which
cannot handle this technique and will fail to connect. Some servers
This patch is a backport from OpenSSL_1.0.1j.
(From upstream: 6bfe55380abbf7528e04e59f18921bd6c896af1c)
"Unfortunately there are still ancient and broken servers in use which
cannot handle this technique and will fail to connect. Some servers only
work if TLS is turned off."
Reference:
ht
Ping, please merge these two CVE patches.
Thanks
-Roy
On 08/29/2014 02:46 PM, Yue Tao wrote:
libavcodec/h264.c in FFmpeg before 0.11.4 allows remote attackers to
cause a denial of service (crash) via vectors related to alternating bit
depths in H.264 data.
http://web.nvd.nist.gov/view/vuln/de
On 10/15/2014 06:42 PM, Burton, Ross wrote:
On 15 October 2014 03:54, Chong Lu wrote:
The gconfd-2 will be called in org.gnome.GConf.service file and the path of
gconfd-2 is ${libexecdir}, this will get following error when multilib exported
in the sdk:
error: file /usr/share/dbus-1/services/o
From: "Roy.Li"
rpm needs gnupg to do signature, otherwise the below error:
$ rpm -v --addsign m4-1.4.16-r4.0.x86_64.rpm
Enter pass phrase:
error: Could not exec gpg: No such file or directory
$
Signed-off-by: Roy.Li
---
meta/recipes-devtools/rpm/rpm_5.4.14.bb | 1 +
1 file chan
I have revised the patches and have taken some of your feedback on
board. See comments further down...
On 12/10/14 03:04, Andreas Oberritter wrote:
On 10.10.2014 18:45, Peter Urbanec wrote:
In the case of init-ifupdown, the default prerm and preinst scripts stop
networking.
I think prerm and
It appears that cross-localedef-native should have the above variable set, and
it does not. I don't know why this does not normally cause a problem, but if
get_srcrev() in fetcher2 code is run in an event handler, it fails for this
recipe. I cannot find any recipe that sets this variable, so I
Writes build information to target filesystem to help developers
[YOCTO #6770]
Signed-off-by: Alejandro Hernandez
---
meta/classes/image.bbclass | 29 -
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbc
On 16/10/14 04:26, Paul Barker wrote:
For the sake of future readers within OpenEmbedded, we need to make
clearer here that this is opkg issue 104, not an OE issue number. This
change isn't needed in the patch to opkg upstream though.
+
+Signed-off-by: Peter Urbanec
Sorry to be pedantic but
opkg upgrade will now call prerm and postrm scripts from the old package
with "upgrade new-version" arguments, similar to what dpkg does.
Signed-off-by: Peter Urbanec
---
.../opkg/opkg/prerm-and-postrm-scripts.patch | 81
++
meta/recipes-devtools/opkg/opkg_0.2.2.bb
On 15 October 2014 17:31, Peter Urbanec wrote:
> opkg upgrade will now call prerm and postrm scripts from the old package
> with the "upgrade new-version" arguments, similar to what dpkg does.
>
> Signed-off-by: Peter Urbanec
> ---
> .../opkg/opkg/prerm-and-postrm-scripts.patch | 82
>
On 16/10/14 00:17, Paul Barker wrote:
This is still missing "Upstream-status:"
...
+ }
+ + static int
I don't think the patch has been generated properly here. There
shouldn't be a change to this line.
Patch resent. I moved the Upstream-status: from the header of the patch,
into the heade
opkg upgrade will now call prerm and postrm scripts from the old package
with the "upgrade new-version" arguments, similar to what dpkg does.
Signed-off-by: Peter Urbanec
---
.../opkg/opkg/prerm-and-postrm-scripts.patch | 82
++
meta/recipes-devtools/opkg/opkg_0.2.2.
Ross,
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf
> Of Burton, Ross
> Sent: Wednesday, October 15, 2014 6:07 AM
> To: Sona Sarmadi
> Cc: yo...@yoctoproject.org; openembedded-
> c...@list
On 15 October 2014 11:07, Burton, Ross wrote:
> Presumably the list of affected packages is:
> - gnutls
> - openssl
> - nss
There's a openssl 1.0.1j out now (fixing FOUR (!) CVEs, including
"disabling SSLv3 didn't work"...). I think considering the situation
we'd take the upgrade for dizzy, even
On 10/15/2014 09:27 PM, Laurentiu Palcu wrote:
Hi Hongxu,
Out of curiosity, was this broken since 2011? Because the commit you're
mentioning is more than 3 years old and I'm not totally convinced that it's
the one triggering the problem...
It failed after do_rootfs refactor, in previous versio
Hi Hongxu,
Out of curiosity, was this broken since 2011? Because the commit you're
mentioning is more than 3 years old and I'm not totally convinced that it's
the one triggering the problem...
laurentiu
On Wed, Oct 15, 2014 at 08:31:14PM +0800, Hongxu Jia wrote:
> There is a failure to build lib
On 15 October 2014 12:49, Peter Urbanec wrote:
> opkg upgrade will now call prerm and postrm scripts from the old package
> with the "upgrade new-version" arguments, similar to what dpkg does.
>
> Signed-off-by: Peter Urbanec
> Upstream-Status: Submitted [opkg-de...@googlegroups.com]
> ---
> ...
There is a failure to build lib32-meta-toolchain:
...
|ERROR: lib32-packagegroup-core-standalone-sdk-target not found in the base
feeds (qemux86_64 x86 noarch any all).
...
In package_manager.py, the variable 'DEFAULTTUNE_virtclass-multilib-lib32'
is used to process multilib image/toolchain. But f
Changed in V3:
Comparisons to singletons like None should always be done 'is not'
Changed in V2:
V1 caused build failure of meta-toolchain, in order to avoid it, we
should use DEFAULTTUNE_virtclass-multilib-lib32 first, if it is not
available, and try to use DEFAULTTUNE_ML_
Test steps:
1. env
Commit e9672387 split one long line into a multi-line string, but in
the process white space between words was lost. This results in badly
formatted output when this message is printed.
Signed-off-by: Peter Urbanec
---
meta/classes/sstate.bbclass | 40
1
update-rc.d.bbclass provides default implementations of prerm, postrm,
preinst and postinst. Unfortunately these default implementations don't
deal with package upgrades as well as they could.
For example, if "opkg upgrade" contains init-ifupdown, in the list of
packages to upgrade, the default pr
opkg upgrade will now call prerm and postrm scripts from the old package
with the "upgrade new-version" arguments, similar to what dpkg does.
Signed-off-by: Peter Urbanec
Upstream-Status: Submitted [opkg-de...@googlegroups.com]
---
.../opkg/opkg/prerm-and-postrm-scripts.patch | 79
On 10/15/2014 07:00 PM, Laurentiu Palcu wrote:
Hi Hongxu,
On Wed, Oct 15, 2014 at 05:23:16PM +0800, Hongxu Jia wrote:
There is a failure to build lib32-meta-toolchain:
...
|ERROR: lib32-packagegroup-core-standalone-sdk-target not found in the base
feeds (qemux86_64 x86 noarch any all).
...
In
Hi Hongxu,
On Wed, Oct 15, 2014 at 05:23:16PM +0800, Hongxu Jia wrote:
> There is a failure to build lib32-meta-toolchain:
> ...
> |ERROR: lib32-packagegroup-core-standalone-sdk-target not found in the base
> feeds (qemux86_64 x86 noarch any all).
> ...
>
> In package_manager.py, the variable 'DE
On 15 October 2014 03:54, Chong Lu wrote:
> The gconfd-2 will be called in org.gnome.GConf.service file and the path of
> gconfd-2 is ${libexecdir}, this will get following error when multilib
> exported
> in the sdk:
> error: file /usr/share/dbus-1/services/org.gnome.GConf.service from install
>
On 15 October 2014 10:28, wrote:
> +- $(INSTALL_SCRIPT) $(srcdir)/scripts/$j ${DESTDIR}$(bindir)/$j
> ; \
> ++ $(INSTALL_PROGRAM) $(srcdir)/scripts/$j
> ${DESTDIR}$(bindir)/$j ; \
Maybe you meant to install both scripts and programs:
$ buildhistory-diff
packages/core
On 15 October 2014 07:48, Sona Sarmadi wrote:
> The advice is: Disable SSLv3.
>
> I created https://bugzilla.yoctoproject.org/show_bug.cgi?id=6843 so we can
> start to work with this immediately.
Presumably the list of affected packages is:
- gnutls
- openssl
- nss
Are there more? Will ENEA b
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
From: Wenlin Kang
When build fs with mtools-3.9.9, has file /usr/bin/lz in rootfs,
it is the symlink to uz:
root@qemu3:~# /usr/bin/lz
-sh: /usr/bin/lz: No such file or directory
$root@qemu3:~# ls -l /usr/bin/lz
lrwxrwxrwx 1 root root 2 Jul 18 18:07 /usr/bin/lz -> uz
root@qemu3:~# uz
-sh: uz: com
There is a failure to build lib32-meta-toolchain:
...
|ERROR: lib32-packagegroup-core-standalone-sdk-target not found in the base
feeds (qemux86_64 x86 noarch any all).
...
In package_manager.py, the variable 'DEFAULTTUNE_virtclass-multilib-lib32'
is used to process multilib image/toolchain. But f
Changed in V2:
V1 caused build failure of meta-toolchain, in order to avoid it, we
should use DEFAULTTUNE_virtclass-multilib-lib32 first, if it is not
available, and try to use DEFAULTTUNE_ML_
Test steps:
1. env
vim local.conf
...
MACHINE = "qemux86-64"
require conf/multilib.conf
MULTILIBS ?=
From: Roy Li
Calling strncpy with NULL second argument, even when the size is 0,
is undefined behavior, which leads to GCC to drop the check old
variable with NULL in following code.
https://bugzilla.yoctoproject.org/show_bug.cgi?id=6743
Signed-off-by: Roy Li
---
.../files/fix-a-Gcc-undefined
On 10/15/2014 01:59 PM, Hongxu Jia wrote:
@@ -61,7 +61,7 @@ class RpmIndexer(Indexer):
eext = ext.split(':')
if len(eext) > 1 and eext[0] == 'multilib':
localdata = bb.data.createCopy(self.d)
-default_tune_key = "DEFAUL
35 matches
Mail list logo
