Re: [yocto] [pseudo] Pseudo 1.8+ xattr sqlite corruption
On Tue, 18 Sep 2018 16:16:22 -0500 Joshua Watt wrote: > Are the databases supposed to be shareable between different build > machines? IIRC, the answer is no. Could you store the native inode > type as a sqlite BLOB? Not necessarily a good idea Just an idea. I think coercing the values into range is probably safer. It should be trivial enough... -s -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [pseudo] Pseudo 1.8+ xattr sqlite corruption
On Tue, Sep 18, 2018, 16:09 Seebs wrote: > On Tue, 18 Sep 2018 20:26:59 + > wrote: > > > SO... any suggestions how to make the inodes in the database an > > UNSIGNED value? > > We probably *can't* -- sqlite doesn't support that! They cap out at 8 > byte integer values, and are always signed. I don't know of a way to > fix this. We might be able to trick it by coercing them into the signed > range, and reversing the conversion later. And this is outside the > range that's accurately representable in float, too. Whee! > Are the databases supposed to be shareable between different build machines? IIRC, the answer is no. Could you store the native inode type as a sqlite BLOB? Not necessarily a good idea Just an idea. > -s > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [pseudo] Pseudo 1.8+ xattr sqlite corruption
On Tue, 18 Sep 2018 20:26:59 + wrote: > SO... any suggestions how to make the inodes in the database an > UNSIGNED value? We probably *can't* -- sqlite doesn't support that! They cap out at 8 byte integer values, and are always signed. I don't know of a way to fix this. We might be able to trick it by coercing them into the signed range, and reversing the conversion later. And this is outside the range that's accurately representable in float, too. Whee! -s -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Native yocto compile in docker container without cross compile
Hi, I am wondering, there does not seem to be any information about native compile of projects in a Yocto docker container. It seems that most of the people use cross compile even though that imho is not necessary if your target is x86 too. So here is what I want to do: - Create a docker container with Yocto Linux, possibly same as the target image - Install gcc, cmake, autotools etc. in the docker container - Run the docker container on a vanilla Ubuntu Linux - Run build jobs in this docker container directly Rational. I have several projects with fully functioning build systems, e.g. make, cmake or autotools which I need to compile for different platforms, e.g. Windows, Ubuntu Linux and Yocto Linux. I now don't want to write recipes just for the Yocto cross compile which I need to additionally maintain and I also don't want to make the original build systems cross compile aware. This can soon get really hard if the build system generates intermediate binaries that are called in the build itself and if it is not prepared for this. Since my target and host platform are both x86 I do not see the need for a cross compile anyways. Usually it is necessary since the target platform might be a very slow ARM system that can't handle all the builds itself. But I do not have this limitation. With such a solution my original build systems should still be able to run unmodified. Within the docker container the environment would be almost the same as in an Ubuntu Linux. The compiler can be accessed without any cross compile settings and any intermediate binaries can also be directly executed etc. If there are some fundamental reasons why this is a bad idea, I would like to know. I also would appreciate any tips on how to create such a docker image. Usually my Yocto image for the target would not contain a compiler or make tool. So I need a way to add those after the fact. Thanks a lot! Fabian -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [pseudo] Pseudo 1.8+ xattr sqlite corruption
> > On Wed, 2018-08-22 at 14:54 +, jack.f...@dell.com wrote: > > > So failure mode is the target filesystem is devoid of SELinux file > > > contexts, all files are unlabeled_t, which pretty much breaks > > > everything in enforcing mode. So whatever the corruption > > > cause/effect in the Psuedo database, the end result is when > > > Mksquashfs runs it can't get labels for the files. > > > > > > There is no obvious differences in the pseudo.log files between good > > > and bad runs, so it's nothing Pseudo is screaming about. > > > > > > I just found the Pseudo debug option flags, and how to insert them > > > using FAKEROOTENV += "PSEUDO_DEBUG=Dx", so I'm running builds trying > > > to get good and bad ones with the debug logs. > > > > Its not clear if you already tried this but if not, it'd probably be worth > > updating pseudo to the latest version too, see if it was some bug we > > already addressed in pseudo. I know we've had a few challenges supporting > > xattrs in there... > > > > Cheers, > > > > Richard > > We have a "bleeding edge" test environment for staging our next upgrades, and > I see Poky 2.5.1 just dropped, so I'll set that up and give it a whirl. And > pull down the top of the Pseudo git tree as well. The only issue is whatever > patch fixes this, I will need to backported into our 2.3 environment. The > next release is stabilized on 2.3 for shipment soon, so I can't yank the rug > out from under that one. If we just have to limp along it'll be annoying, but > not the end of the world as we can get some good builds out. > > Our 2.3 environment is behaving itself again for the moment, so it will take > a bit to get debug logs. Sounds like I have some homework to do, I'll keep > everyone posted. > > And thanks to all for your quick responses. > > Jack Fewx Update! After running a number of test builds and seeing passes and failures, I found the root cause of our issue. This one took a while. The inode values in our build system get too large. Meaning they exceed the MAX value of a SIGNED 64-bit integer. As long as they are under that limit the build is fine, as soon as the signed values become "negative" it all gets screwed up. Good build (paths redacted): get-xattr: path '...image/1.0.0-r0.0/rootfs/var/backups', oldpath 'security.selinux' [16/189] requested xattr named 'security.selinux' for ino 1573104496 set-xattr: path '...image/1.0.0-r0.0/rootfs/var/backups', oldpath 'security.selinux' [50/223] trying to set a value for ino 1573104496: name is 'security.selinux' [16/50 bytes], value is 'system_u:object_r:backup_store_t' [33 bytes]. Existing row -1. get-xattr: path '...image/1.0.0-r0.0/rootfs/var/backups', oldpath 'security.selinux' [16/189] requested xattr named 'security.selinux' for ino 1573104496 got 33-byte results: 'system_u:object_r:backup_store_t' get results: 'system_u:object_r:backup_store_t' (33 bytes) list-xattr: path '...image/1.0.0-r0.0/rootfs/var/backups', oldpath '' [-1/172] got 17 bytes of xattrs to list: security.selinux Bad build: get-xattr: path '...image/1.0.0-r0.0/rootfs/var/backups', oldpath 'security.selinux' [16/189] requested xattr named 'security.selinux' for ino 2983570948 set-xattr: path '...image/1.0.0-r0.0/rootfs/var/backups', oldpath 'security.selinux' [50/223] trying to set a value for ino 2983570948: name is 'security.selinux' [16/50 bytes], value is 'system_u:object_r:backup_store_t' [33 bytes]. Existing row -1. get-xattr: path '...image/1.0.0-r0.0/rootfs/var/backups', oldpath 'security.selinux' [16/189] requested xattr named 'security.selinux' for ino 2983570948 list-xattr: path '...image/1.0.0-r0.0/rootfs/var/backups', oldpath '' [-1/172] got 0 bytes of xattrs to list: The inode count is the later example is too great, so every lookup fails, and the xattr is set multiple times in the database, yet can't be read out during mkfs. SO... any suggestions how to make the inodes in the database an UNSIGNED value? -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Demos for the Yocto Project booth at ELCE in Edinburgh
On 09/18/2018 06:29 AM, Nicolas Dechesne wrote: > Dear all, > > As usual, the Yocto Project will have a booth at the ELCE conference > in Edinburgh next month. While the booth is a great opportunity for > everyone to get a new sticker of your favorite project ;-) we are also > very excited when developers from our community get a chance to show > off the fun and cool things they build thanks to the Yocto Project! > > If you want to bring any of your cool demo on the YP booth, please > send me an email so that we can plan and discuss any of the logistics! I will be bringing a demo.. Not sure it its cool though :) - armin > > Also, don't forget the YP Dev Day Europe, which is right after ELCE, > in Edinburgh, more information can be found here: > https://www.yoctoproject.org/yocto-project-dev-day-europe-2018/ > > cheers > nico -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-security][PATCH] keyutils: Fix build with usrmerge
On 09/16/2018 11:59 AM, Alex Kiernan wrote:
> Update BINDIR and SBINDIR so keyutils builds with usrmerge
>
> ERROR: keyutils-1.5.10-r0 do_package: QA Issue: keyutils: Files/directories
> were installed but not shipped in any package:
> /sbin/key.dns_resolver
> /sbin/request-key
> /bin/keyctl
> Please set FILES such that these items are packaged. Alternatively if they
> are unneeded, avoid installing them or delete them within do_install.
> keyutils: 3 installed and not shipped files. [installed-vs-shipped]
>
> Signed-off-by: Alex Kiernan
merged,
Thanks,
armin
> ---
>
> recipes-security/keyutils/keyutils_1.5.10.bb | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/recipes-security/keyutils/keyutils_1.5.10.bb
> b/recipes-security/keyutils/keyutils_1.5.10.bb
> index 2ead8fa..a4222b9 100644
> --- a/recipes-security/keyutils/keyutils_1.5.10.bb
> +++ b/recipes-security/keyutils/keyutils_1.5.10.bb
> @@ -27,6 +27,8 @@ SRC_URI[sha256sum] =
> "115c3deae7f181778fd0e0ffaa2dad1bf1fe2f5677cf2e0e348cdb7a1c
>
> EXTRA_OEMAKE = "'CFLAGS=${CFLAGS} -Wall' \
> NO_ARLIB=1 \
> +BINDIR=${base_bindir} \
> +SBINDIR=${base_sbindir} \
> LIBDIR=${base_libdir} \
> USRLIBDIR=${base_libdir} \
> BUILDFOR=${SITEINFO_BITS}-bit \
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-security][PATCH] keynote: depend on openssl10
On 09/12/2018 01:09 AM, Yi Zhao wrote: > Signed-off-by: Yi Zhao > --- > recipes-security/keynote/keynote_2.3.bb | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/recipes-security/keynote/keynote_2.3.bb > b/recipes-security/keynote/keynote_2.3.bb > index 0300894..6ec26b8 100644 > --- a/recipes-security/keynote/keynote_2.3.bb > +++ b/recipes-security/keynote/keynote_2.3.bb > @@ -23,7 +23,7 @@ inherit autotools-brokensep ptest > SRC_URI[md5sum] = "a14553e6ad921b5c85026ce5bec3afe7" > SRC_URI[sha256sum] = > "38d2acfa1c3630a07adcb5c8fe92d2aef7f0e6d242b8998b2bbb1c6e4c408d46" merged. thanks, Armin > > -DEPENDS = "flex openssl bison-native" > +DEPENDS = "flex openssl10 bison-native" > > EXTRA_OEMAKE += "test-sample -j1" > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Yocto Project Status WW38’18
Current Dev Position: YP 2.6 M3. - This is feature freeze for YP 2.6! Next Deadline: YP 2.6 M3 Build Target is Aug. 27, 2018 SWAT Team Rotation: · SWAT lead is currently: Tracy · SWAT team rotation: Tracy-> Armin on Sept. 21, 2018 · SWAT team rotation: Armin -> Chen on Sept. 28, 2018 · https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team Key Status/Updates: · We’re now well into M3 feature freeze so new feature patches, particularly for unplanned changes will be deferred until 2.7. · M3 has still not been built yet however we have: oupgraded to openssl 1.1 final omerged the allarch multilib changes we were waiting for. oresolved the xserver upgrade issues and merged the fixes/upgrades othe python3 openssl issues were resolved, thanks Anuj! · The main remaining question is what, if anything to do with openssh for 2.6. Upstream have now reluctantly merged openssl 1.1 support. Any new release date containing that work is unknown but its tempting to upgrade to the latest from revision control and then take the new released version into 2.6 when it does happen., thereby unifying openssl support in OE-Core. · There is a bug that has been identified in relocating gnupg-native causing oe-selftest failures. · An issue with the buildbot autobuilder UI plugin code was debugged and a fix sent and accepted upstream. Planned Releases for YP 2.6: · YP 2.6 M3 Build Target is Aug. 27, 2018 · YP 2.6 M3 Release Target is Sept. 7, 2018 · YP 2.6 M4 Build Target is Oct. 1, 2018 · YP 2.6 M4 Release Target is Oct. 26, 2018 Planned upcoming dot releases: · YP 2.4.4 (Rocko) will be targeted after YP 2.6 M4 is done. · YP 2.5.2 (Sumo) will be targeted after YP 2.4.4 is done. Tracking Metrics: · WDD 2589 (last week 2580) (https://wiki.yoctoproject.org/charts/combo.html) · Poky Patch Metrics oTotal patches found: 1646 (last week 1646) oPercentage of patches in the Pending State: 736 (45%) [last week 736 (45%)] Key Status Links for YP: https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.6_Status https://wiki.yoctoproject.org/wiki/Yocto_2.6_Schedule https://wiki.yoctoproject.org/wiki/Yocto_2.6_Features The Status reports are now stored on the wiki at: https://wiki.yoctoproject.org/wiki/Weekly_Status [If anyone has suggestions for other information you’d like to see on this weekly status update, let us know!] Thanks, Stephen K. Jolley Yocto Project Program Manager INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124 •Cell:(208) 244-4460 • Email: stephen.k.jol...@intel.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Demos for the Yocto Project booth at ELCE in Edinburgh
Dear all, As usual, the Yocto Project will have a booth at the ELCE conference in Edinburgh next month. While the booth is a great opportunity for everyone to get a new sticker of your favorite project ;-) we are also very excited when developers from our community get a chance to show off the fun and cool things they build thanks to the Yocto Project! If you want to bring any of your cool demo on the YP booth, please send me an email so that we can plan and discuss any of the logistics! Also, don't forget the YP Dev Day Europe, which is right after ELCE, in Edinburgh, more information can be found here: https://www.yoctoproject.org/yocto-project-dev-day-europe-2018/ cheers nico -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [linux-yocto] Using a pre-build kernel
Trevor (reply-to-all), I see. So a custom recipe inherited from bin_package to get the image included. But would I then need (in local.conf) : PREFERRED_PROVIDER_virtual/kernel = "linux-dummy" to avoid BitBake attempting to build one? And would setting PREFERRED_VERSION_linux-yocto to the kernel version of my binary kernel image provide the rest of the build system knowledge of what version my kernel was? Or, is there a better way? Thanks, -Alan On Mon, Sep 17, 2018 at 4:56 PM Trevor Woerner wrote: > Maybe bin_package.bbclass can help? > > http://cgit.openembedded.org/openembedded-core/tree/meta/classes/bin_package.bbclass > -- Alan Kozlay VES Solutions, LLC Alan Kozlay DESK 443-595-7734 CELL 443-752-0323 -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
[yocto] Adding SSL support to RabbitMQ Server 3.2.4
Hi, rookie here. I'm trying to enable SSL for RabbitMQ Server 3.2.4 on pyro.
Without modifying the build, I simply created /etc/rabbitmq/rabbitmq.config
with the following entries:
[
{rabbitmq_management,
[
{listener, [{port, 15671},
{ip, "0.0.0.0"},
{ssl, true},
{ssl_opts, [{cacertfile, "/etc/rabbitmq/root-ca.pem"},
{certfile, "/etc/rabbitmq/dev.pem"},
{keyfile,"/etc/rabbitmq/dev-np.key"}]}]}
]}
].
and placed the cacertfile, certfile, and keyfile at /etc/rabbitmq/
RabbitMQ Server fails to start at boot.
/var/log/rabbitmq/rabbitmq@{hostname}.log
shows the following error:
=ERROR REPORT 17-Sep-2018::20:13:16 ===
** Generic server rabbit_web_dispatch_registry terminating
** Last message in was {add,rabbit_mgmt,
[{port,15671},
{ip,"0.0.0.0"},
{ssl,true},
{ssl_opts,
[{cacertfile,"/etc/rabbitmq/root-ca.pem"},
{certfile,"/etc/rabbitmq/dcx-dev.pem"},
{keyfile,"/etc/rabbitmq/dcx-dev-np.key"}]}],
#Fun,
#Fun,
{[],"RabbitMQ Management"}}
** When Server state == undefined
** Reason for termination ==
** {could_not_start_listener,
[{port,15671},
{ip,"0.0.0.0"},
{ssl,true},
{ssl_opts,
[{cacertfile,"/etc/rabbitmq/root-ca.pem"},
{certfile,"/etc/rabbitmq/dcx-dev.pem"},
{keyfile,"/etc/rabbitmq/dcx-dev-np.key"}]}],
{'EXIT',
{{case_clause,{error,{"no such file or
directory","crypto.app"}}},
[{mochiweb,ensure_started,1,
[{file,"mochiweb-wrapper/mochiweb-git/src/mochiweb.erl"},
{line,71}]},
{mochiweb_socket_server,prep_ssl,1,
[{file,
"mochiweb-wrapper/mochiweb-git/src/mochiweb_socket_server.erl"},
{line,139}]},
{mochiweb_socket_server,start_server,2,
[{file,
"mochiweb-wrapper/mochiweb-git/src/mochiweb_socket_server.erl"},
{line,130}]},
{supervisor,do_start_child,2,
[{file,"supervisor.erl"},{line,310}]},
{supervisor,handle_start_child,2,
[{file,"supervisor.erl"},{line,681}]},
{supervisor,handle_call,3,[{file,"supervisor.erl"},{line,390}]},
{gen_server,handle_msg,5,[{file,"gen_server.erl"},{line,585}]},
{proc_lib,init_p_do_apply,3,
[{file,"proc_lib.erl"},{line,239}]}]}}}
After googling around, I'm going down the path of trying to build Erlang
with SSL support. Please stop me if this isn't the proper approach!
I clearly see in
meta-cloud-services/meta-openstack/recipes-devtools/erlang/erlang-native_R16B03-1.bb
a line that says:
EXTRA_OECONF = '--without-ssl'
To alter this statement, I wrote an erlang-native_R16B03-1.bbappend in my
meta-layer and tried the following entries:
*
DEPENDS += "ncurses-native openssl"
EXTRA_OECONF = '--with-ssl=/usr/bin/openssl'
This fails to build with the following error:
configure: error: Invalid path to option --with-ssl=PATH
configure: error: /bin/bash
'build/tmp/work/x86_64-linux/erlang-native/R16B03-1-r0/otp_src_R16B03-1/erts/configure'
failed for erts
*
DEPENDS += "ncurses-native openssl"
EXTRA_OECONF = '--with-ssl'
Builds successfully but products the same error as above in
/var/log/rabbitmq/rabbitmq@{hostname}.log
*
DEPENDS += "ncurses-native openssl"
EXTRA_OECONF = "--with-ssl=${STAGING_DIR_HOST}${layout_exec_prefix}"
Builds successfully but products the same error as above
in /var/log/rabbitmq/rabbitmq@{hostname}.log
*
DEPENDS += "ncurses-native openssl"
EXTRA_OECONF = "--with-ssl use SSL"
Builds successfully but products the same error as above
in /var/log/rabbitmq/rabbitmq@{hostname}.log
*
Detailed help is greatly appreciated. Seems like I'm missing something
obvious.
Best Regards,
Phillip Warren
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
