Re: [yocto] yocto x64-linux with bootia32.efi

2018-11-12 Thread Dimitris Tassopoulos 
That's great news!
Glad to help. It's frustrating some times, but I hope that also someone
else may come with a better solution.

Regarding secureboot, I guess that if you use the same keys, then there
shouldn't be any issue. But I haven't use it, so I can't tell from
experience.

Regards,
Dimitris

On Tue, 13 Nov 2018, 08:28 Knoppix  it works!
> It copied files to ESP (efi system partition).
> I hope it will work with secure boot concept too.
>
> *Mr. Dimitris *thank you so so much. I *am so glad to you* for your
> politeness and help.
>
> My best compliments..
>
> On Mon, Nov 12, 2018 at 5:51 PM Dimitris Tassopoulos 
> wrote:
>
>> Yeah, I think everybody is pretty busy. This project is huge and there
>> aren't many contributors.
>>
>> Anyway, in case you use wks files, then you can create a file named 
>> *test.wks.in
>> * (make sure you add
>> the .in at the end). Then add this (or similar depending your image):
>>
>> bootloader --ptable gpt
>> part /boot --source rootfs --rootfs-dir=${IMAGE_ROOTFS}/boot
>> --fstype=vfat --ondisk sda --label boot --active --align 1024
>> part / --source rootfs --ondisk sda --fstype=ext4 --label root --align
>> 1024 --exclude-path boot/
>>
>> The above will force wic tool not to use the default efi file that yocto
>> produces and it will use the content of the /boot
>> folder your image creates. Therefore, if you add your custom recipe that
>> copies the efi file you want, *but also* the
>> the rest of the boot files (like confs) then you can override the
>> image-efi and use your custom files from the recipe.
>>
>> For example, keep a copy of the whole boot folder that you already have,
>> then replace the efi file with your
>> precompiled and then create a recipe to copy all those files to your
>> image's /boot folder.
>>
>> I think that this may do the trick.
>>
>> The important keywords in the wks file are the `--rootfs-dir` in the
>> /boot part, which means that you force wic
>> to use your image's /boot folder. And the `--exclude-path` which forces
>> wic tool not to touch your /boot folder.
>>
>> Best regards,
>> Dimitris
>>
>> On Mon, Nov 12, 2018 at 3:37 PM Knoppix  wrote:
>>
>>> Yes I did this before I sent this email. First I created x86_32 system
>>> and backup boot files. Then i created regular x64 system and move
>>> bootia32.efi file to the boot partition. (I did manualy)
>>> And yes I'm using wic and I have wks file. (I dont know how can i copy
>>> my bootia32.efi to boot partition when yocto has create image)
>>>
>>> But very soon I should implement secure boot with the system.
>>> So I think copy precompilted bootia32.efi will not work with secure
>>> system. (I am not sure)
>>>
>>> By the way this is the first mail which I took any maillist system. I'm
>>> so happy to experiment this feeling :) until now nobody answers me.
>>> Kind regards.
>>>
>>> On Mon, Nov 12, 2018 at 5:20 PM Dimitris Tassopoulos 
>>> wrote:
>>>
 You're right about the toolchain, this will hit wall, because the
 x86_64 will build fail to build the x86 efi.

 Are you using wic and a wks file for your image?

 There might be a way to override the x86_64 efi bootloader with a
 pre-compiled one.
 If you do, then I may have a solution for you.

 Regards,
 Dimitris

 On Mon, Nov 12, 2018 at 2:39 PM Knoppix  wrote:

> Mr. Tassopoulos
>
> Thank you so much for your answer.
>
> I am trying to do this because my device (atom cpu) has 64bit cpu but
> its efi doesn't support 64. Efi is x86. I learned that ".. The vast
> majority of EFI-based x86-64 computers use 64-bit EFIs and therefore use a
> bootx64.efi default boot loader file. A handful of early Macs and some
> Atom-based tablets have 64-bit CPUs but 32-bit EFIs ..."
> http://www.rodsbooks.com/efi-bootloaders/principles.html
>
> But I dont understand: if my target machine is x86_64 then yocto will
> prepare native/host toolchain to gcc-x64 but when we force to install grub
> as i386 what will happen? yocto will install a second toolchain for i386?
> And also shouldn't grub be x86?
>
> Bye the way, yocto has failed when i try.
>
> *do_mkimage*
> DEBUG: SITE files ['endian-little', 'common-linux', 'common-glibc',
> 'bit-64', 'x86_64-linux', 'common']
> DEBUG: Executing shell function do_mkimage
> *grub-mkimage: error: invalid ELF header.*
> WARNING: exit code 1 from a shell command.
>
>
> Best regards
>
>
> On Mon, Nov 12, 2018 at 11:44 AM Dimitris Tassopoulos <
> dimt...@gmail.com> wrote:
>
>> I don't know about your special case and why this happens, but a
>> simple "hack" it's, depending your bootloader
>> (grub or systemd-boot), to edit a couple of files in poky. I haven't
>> tested this, so I don't know if it really works.
>>
>> For Grub remove in poky/meta/classes/grub-efi.bbclass these
>> if [ "${TARGET_A

[yocto] [PATCH] meta-yocto-bsp: beaglebone-yocto.conf: support 8250 serial driver

2018-11-12 Thread Heiko Schocher 

it is possible to use the beagleboneblack with the 8250 serial
driver or with the deprecated omap serial driver.

Unfortunately serial console get different names (ttyS0 with
8250 driver and ttyO0 with omap driver)

So set SERIAL_CONSOLES to
SERIAL_CONSOLES ?= "115200;ttyS0 115200;ttyO0"

(intentionally with "?=" so it is overwriteable)
and activate

SERIAL_CONSOLES_CHECK = "${SERIAL_CONSOLES}"

with that on the first boot the correct value is picked up
automatically.

Signed-off-by: Heiko Schocher 
---

 meta-yocto-bsp/conf/machine/beaglebone-yocto.conf | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf 
b/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf

index e911e75004..69e11eca59 100644
--- a/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
+++ b/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
@@ -20,7 +20,8 @@ WKS_FILE ?= "beaglebone-yocto.wks"
 IMAGE_INSTALL_append = " kernel-devicetree kernel-image-zimage"
 do_image_wic[depends] += "mtools-native:do_populate_sysroot 
dosfstools-native:do_populate_sysroot"

-SERIAL_CONSOLES = "115200;ttyO0"
+SERIAL_CONSOLES ?= "115200;ttyS0 115200;ttyO0"
+SERIAL_CONSOLES_CHECK = "${SERIAL_CONSOLES}"

 PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
 PREFERRED_VERSION_linux-yocto ?= "4.18%"
--
2.13.6


--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Set linux capabilities on binary on a recipe in meta-oe layer

2018-11-12 Thread Mike Looijmans 
Sometimes the problem is that parts of the underscored function name are seen 
as overrides, so you should try using "mysetcapfunction" instead as a name.

Also, there's a semicolon missing:
ROOTFS_POSTPROCESS_COMMAND += "my_setcap_function;"


On 12-11-18 14:09, Markus W wrote:
> Thanks Uwe!
> 
> I tried the global approach by adding the following to my local.conf file:
> 
> ROOTFS_POSTPROCESS_COMMAND += "my_setcap_function"
> 
> my_setcap_function() {
>      setcap cap_net_raw+eip ${IMAGE_ROOTFS}/usr/bin/node
> }
> 
> But got the following warning:
> WARNING: core-image-full-cmdline-1.0-r0 do_rootfs: Function 
> my_setcap_function 
> doesn't exist
> 
> I have tried to add the function into a recipe but this doesn't work either. 
> Where should the function be defined?
> 
> Regards,
> Markus
> 
> 
> On Fri, 9 Nov 2018 at 15:35, Uwe Geuder  > wrote:
> 
> Hi!
> 
> 
> On Fri, Nov 9, 2018 at 12:16 PM Markus W markus4dev-at-gmail.com
>  wrote:
> 
>  > On Thu, 8 Nov 2018 at 22:53, Piotr Tworek  > wrote:
> ...
>  >> pkg_postinst_ontarget_${PN} () {
>  >>    setcap cap_net_raw+eip $D${bindir}/node
>  >> }
> ...
>  > How can this be achieved when the rootfs is created and not on first
>  > boot? I would like not to ship libcap binaries with the target in
>  > production.
> 
> Ideally I would do it "locally" in do_install of the node recipe (you can
> append extra statements to the task in your own .bbappend in your own
> layer, don't edit existing recipes)
> 
> That of course requires that the package manager preserves the
> capabilites. I have no experience which package manager would do
> or not do that.
> 
> "Globally" you can do it by appending a new function to
> ROOTFS_POSTPROCESS_COMMAND
> 
> https://www.yoctoproject.org/docs/2.5.1/mega-manual/mega-manual.html#var-
> ROOTFS_POSTPROCESS_COMMAND
> 
> This is done in your image recipe.
> 
> Regards,
> 
> Uwe Geuder
> Neuro Event Labs Oy
> Tampere, Finland
> uwe.gex...@neuroeventlabs.com  (Bot
> check: fix one obvious typo)
> -- 
> ___
> yocto mailing list
> yocto@yoctoproject.org 
> https://lists.yoctoproject.org/listinfo/yocto
> 
> 

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] QA cycle report for 2.6 M4 RC1

2018-11-12 Thread Burton, Ross 
On Mon, 12 Nov 2018 at 16:20, akuster808  wrote:
> Maybe shoot for before the Dec Holidays instead of a fixed period after
> 2.6 releases, a nice way to end the year : )

*Before* the holidays, I don't plan on taking a laptop with me and RP
works enough outside of Mon/Fri 9-5 as it is! :)

Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Yocto Project Unassigned Bugs - Help Needed

2018-11-12 Thread Jolley, Stephen K 
All,



The triage team meets weekly and does its best to handle the bugs reported into 
the bugzilla. The number of people attending that meeting has fallen, as have 
the number of people available to help fix bugs. One of the things we hear 
users report is they don't know how to help. We (the triage team) are therefore 
going to start reporting out the currently 296 unassigned bugs.



We're hoping people may be able to spare some time now and again to help out 
with these.



Bugs are split into two types, "true bugs" where things don't work as they 
should and "enhancements" which are features we'd want to add to the system.



There are also roughly four different "priority" classes right now, "2.7", 
"2.8", "2.99" and "Future", the more pressing/urgent issues being in "2.7" and 
then "2.8".



Please review this link and if a bug is something you would be able to help 
with either take ownership of the bug, or send me 
(stephen.k.jol...@intel.com) an e-mail with 
the bug number you would like and I will assign it to you (please make sure you 
have a bugzilla account).



The list is at: https://wiki.yoctoproject.org/wiki/Bug_Triage#Unassigned_Bugs


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

Re: [yocto] QA cycle report for 2.6 M4 RC1

2018-11-12 Thread akuster808 


On 11/12/18 8:12 AM, Burton, Ross wrote:
> On Sat, 10 Nov 2018 at 16:26,  wrote:
>> My personal view is that whilst there are a number of issues present in
>> rc1, we should release it, collect up fixes on the thud branch (aleady
>> happening) and plan on a 2.6.1 as soon as it looks like we have enough
>> critical mass behind those as opposed to an rc2 and further delays to
>> the release.
> I'd suggest we schedule 2.6.1 for about month after release, there's
> quite a queue of security fixes already.

Maybe shoot for before the Dec Holidays instead of a fixed period after
2.6 releases, a nice way to end the year : )

- armin

>
> With that caveat, I'm fine with this plan.
>
> Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] QA cycle report for 2.6 M4 RC1

2018-11-12 Thread Burton, Ross 
On Sat, 10 Nov 2018 at 16:26,  wrote:
> My personal view is that whilst there are a number of issues present in
> rc1, we should release it, collect up fixes on the thud branch (aleady
> happening) and plan on a 2.6.1 as soon as it looks like we have enough
> critical mass behind those as opposed to an rc2 and further delays to
> the release.

I'd suggest we schedule 2.6.1 for about month after release, there's
quite a queue of security fixes already.

With that caveat, I'm fine with this plan.

Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [opkg-devel] [opkg-utils PATCH] update-alternatives: Fix link relocation support

2018-11-12 Thread Alejandro Del Castillo 
good catch, thanks for the fix!

merged

On 11/11/18 8:19 AM, Niko Mauno wrote:
> Commit fcb2633921eb9bb711aa264247aebcfdd4ae which added Debian-style
> support for link relocation tries to relocate symbolic link on host OS,
> resulting in following-like error when two alternative packages have
> symbolic link source located in different directories (/bin/rev ->
> /bin/busybox.nosuid and /usr/bin/rev -> /usr/bin/rev.util-linux):
> 
>update-alternatives: renaming rev link from /bin/rev to /usr/bin/rev
>mv: cannot stat '/bin/rev': No such file or directory
> 
> Fix the issue by prefixing 'olink' and 'link' variable references with
> path to targeted root filesystem's root directory.
> 
> Signed-off-by: Niko Mauno 
> ---
>   update-alternatives | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/update-alternatives b/update-alternatives
> index 89a440b..d4fa7eb 100644
> --- a/update-alternatives
> +++ b/update-alternatives
> @@ -58,7 +58,7 @@ register_alt() {
>   local link_str=`echo $link | protect_slashes`
>   sed -e "1s/.*/$link_str/" $ad/$name > $ad/$name.new
>   mv $ad/$name.new $ad/$name
> - mv $olink $link
> + mv $OPKG_OFFLINE_ROOT$olink $OPKG_OFFLINE_ROOT$link
>   fi
>   else
>   echo "$link" > "$ad/$name"
> 

-- 
Cheers,

Alejandro
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] CONFFILES journey form source dir to rootfs

2018-11-12 Thread Burton, Ross 
On Mon, 12 Nov 2018 at 14:33, Alan Martinovic  wrote:
> > The standard do_install (which calls make install) copies the file
> > from the source tree to the staging directory.
>
> What's the reason for not seeing that in `bitbake -e systemd`?

It is there:

do_install() {
meson_do_install
...
}

do_install calls meson_do_install which calls ninja install, which
copies the file from the build directory to the staging directory,
which is then used in packaging.

Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] CONFFILES journey form source dir to rootfs

2018-11-12 Thread Alan Martinovic 
> The standard do_install (which calls make install) copies the file
> from the source tree to the staging directory.

What's the reason for not seeing that in `bitbake -e systemd`?


Be Well,
Alan

On Mon, Nov 12, 2018 at 1:30 PM Burton, Ross  wrote:
>
> The standard do_install (which calls make install) copies the file
> from the source tree to the staging directory.
>
> Ross
> On Mon, 12 Nov 2018 at 11:52, Alan Martinovic  
> wrote:
> >
> > Hi,
> > I'm trying to understand how a conf file finds its way from source to
> > the rootfs.
> >
> > The example is use is `journald.conf` from systemd.
> > The file originates from systemd source:
> > 
> > work/cortexa7hf-neon-vfpv4-senic-linux-gnueabi/systemd/1_234-r0/git/src/journal/journald.conf
> >
> > In the environment is only mentioned as a part of the CONFFILES.
> > [output of `bitbake systemd -e` formated for readability]:
> >
> > # $CONFFILES [2 operations]
> > #   set /mnt/data/alan/work/senic-os/oe/meta/conf/documentation.conf:116
> > # [doc] "Identifies editable or configurable files that are
> > part of a package."
> > #   override[systemd]:rename from CONFFILES_${PN} data.py:116 
> > [expandKeys]
> > # "${sysconfdir}/machine-id
> >${sysconfdir}/systemd/coredump.conf
> >${sysconfdir}/systemd/journald.conf
> >${sysconfdir}/systemd/logind.conf
> >${sysconfdir}/systemd/system.conf
> >${sysconfdir}/systemd/user.conf"
> > # pre-expansion value:
> > #   "None"
> > #
> > # $CONFFILES_systemd
> > #   rename from CONFFILES_${PN} data.py:116 [expandKeys]
> > # "${sysconfdir}/machine-id
> >${sysconfdir}/systemd/coredump.conf
> >${sysconfdir}/systemd/journald.conf
> >${sysconfdir}/systemd/logind.conf
> >${sysconfdir}/systemd/system.conf
> >${sysconfdir}/systemd/user.conf"
> > CONFFILES_systemd="/etc/machine-id
> > /etc/systemd/coredump.conf
> > /etc/systemd/journald.conf
> > /etc/systemd/logind.conf
> > /etc/systemd/system.conf
> > /etc/systemd/user.conf"
> >
> >
> > The file successfully ends up at `/etc/systemd/journald.conf`.
> >
> > Why isn't there an action in the environment showing the copying of
> > journald.conf
> > from `...git/src/journal/journald.conf` to
> > `${sysconfdir}/systemd/journald.conf`?
> >
> >
> > Disclaimer:
> > There were also some sed related actions with the file in the environment
> > which I dropped to reduce noise.
> >
> > Be Well,
> > Alan
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Set linux capabilities on binary on a recipe in meta-oe layer

2018-11-12 Thread Markus W 
Thanks Uwe!

I tried the global approach by adding the following to my local.conf file:

ROOTFS_POSTPROCESS_COMMAND += "my_setcap_function"

my_setcap_function() {
setcap cap_net_raw+eip ${IMAGE_ROOTFS}/usr/bin/node
}

But got the following warning:
WARNING: core-image-full-cmdline-1.0-r0 do_rootfs: Function
my_setcap_function doesn't exist

I have tried to add the function into a recipe but this doesn't work
either. Where should the function be defined?

Regards,
Markus


On Fri, 9 Nov 2018 at 15:35, Uwe Geuder  wrote:

> Hi!
>
>
> On Fri, Nov 9, 2018 at 12:16 PM Markus W markus4dev-at-gmail.com wrote:
>
> > On Thu, 8 Nov 2018 at 22:53, Piotr Tworek  wrote:
> ...
> >> pkg_postinst_ontarget_${PN} () {
> >>setcap cap_net_raw+eip $D${bindir}/node
> >> }
> ...
> > How can this be achieved when the rootfs is created and not on first
> > boot? I would like not to ship libcap binaries with the target in
> > production.
>
> Ideally I would do it "locally" in do_install of the node recipe (you can
> append extra statements to the task in your own .bbappend in your own
> layer, don't edit existing recipes)
>
> That of course requires that the package manager preserves the
> capabilites. I have no experience which package manager would do
> or not do that.
>
> "Globally" you can do it by appending a new function to
> ROOTFS_POSTPROCESS_COMMAND
>
> https://www.yoctoproject.org/docs/2.5.1/mega-manual/mega-manual.html#var-
> ROOTFS_POSTPROCESS_COMMAND
>
> This is done in your image recipe.
>
> Regards,
>
> Uwe Geuder
> Neuro Event Labs Oy
> Tampere, Finland
> uwe.gex...@neuroeventlabs.com (Bot check: fix one obvious typo)
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] CONFFILES journey form source dir to rootfs

2018-11-12 Thread Burton, Ross 
The standard do_install (which calls make install) copies the file
from the source tree to the staging directory.

Ross
On Mon, 12 Nov 2018 at 11:52, Alan Martinovic  wrote:
>
> Hi,
> I'm trying to understand how a conf file finds its way from source to
> the rootfs.
>
> The example is use is `journald.conf` from systemd.
> The file originates from systemd source:
> 
> work/cortexa7hf-neon-vfpv4-senic-linux-gnueabi/systemd/1_234-r0/git/src/journal/journald.conf
>
> In the environment is only mentioned as a part of the CONFFILES.
> [output of `bitbake systemd -e` formated for readability]:
>
> # $CONFFILES [2 operations]
> #   set /mnt/data/alan/work/senic-os/oe/meta/conf/documentation.conf:116
> # [doc] "Identifies editable or configurable files that are
> part of a package."
> #   override[systemd]:rename from CONFFILES_${PN} data.py:116 [expandKeys]
> # "${sysconfdir}/machine-id
>${sysconfdir}/systemd/coredump.conf
>${sysconfdir}/systemd/journald.conf
>${sysconfdir}/systemd/logind.conf
>${sysconfdir}/systemd/system.conf
>${sysconfdir}/systemd/user.conf"
> # pre-expansion value:
> #   "None"
> #
> # $CONFFILES_systemd
> #   rename from CONFFILES_${PN} data.py:116 [expandKeys]
> # "${sysconfdir}/machine-id
>${sysconfdir}/systemd/coredump.conf
>${sysconfdir}/systemd/journald.conf
>${sysconfdir}/systemd/logind.conf
>${sysconfdir}/systemd/system.conf
>${sysconfdir}/systemd/user.conf"
> CONFFILES_systemd="/etc/machine-id
> /etc/systemd/coredump.conf
> /etc/systemd/journald.conf
> /etc/systemd/logind.conf
> /etc/systemd/system.conf
> /etc/systemd/user.conf"
>
>
> The file successfully ends up at `/etc/systemd/journald.conf`.
>
> Why isn't there an action in the environment showing the copying of
> journald.conf
> from `...git/src/journal/journald.conf` to
> `${sysconfdir}/systemd/journald.conf`?
>
>
> Disclaimer:
> There were also some sed related actions with the file in the environment
> which I dropped to reduce noise.
>
> Be Well,
> Alan
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] CONFFILES journey form source dir to rootfs

2018-11-12 Thread Alan Martinovic 
Hi,
I'm trying to understand how a conf file finds its way from source to
the rootfs.

The example is use is `journald.conf` from systemd.
The file originates from systemd source:

work/cortexa7hf-neon-vfpv4-senic-linux-gnueabi/systemd/1_234-r0/git/src/journal/journald.conf

In the environment is only mentioned as a part of the CONFFILES.
[output of `bitbake systemd -e` formated for readability]:

# $CONFFILES [2 operations]
#   set /mnt/data/alan/work/senic-os/oe/meta/conf/documentation.conf:116
# [doc] "Identifies editable or configurable files that are
part of a package."
#   override[systemd]:rename from CONFFILES_${PN} data.py:116 [expandKeys]
# "${sysconfdir}/machine-id
   ${sysconfdir}/systemd/coredump.conf
   ${sysconfdir}/systemd/journald.conf
   ${sysconfdir}/systemd/logind.conf
   ${sysconfdir}/systemd/system.conf
   ${sysconfdir}/systemd/user.conf"
# pre-expansion value:
#   "None"
#
# $CONFFILES_systemd
#   rename from CONFFILES_${PN} data.py:116 [expandKeys]
# "${sysconfdir}/machine-id
   ${sysconfdir}/systemd/coredump.conf
   ${sysconfdir}/systemd/journald.conf
   ${sysconfdir}/systemd/logind.conf
   ${sysconfdir}/systemd/system.conf
   ${sysconfdir}/systemd/user.conf"
CONFFILES_systemd="/etc/machine-id
/etc/systemd/coredump.conf
/etc/systemd/journald.conf
/etc/systemd/logind.conf
/etc/systemd/system.conf
/etc/systemd/user.conf"


The file successfully ends up at `/etc/systemd/journald.conf`.

Why isn't there an action in the environment showing the copying of
journald.conf
from `...git/src/journal/journald.conf` to
`${sysconfdir}/systemd/journald.conf`?


Disclaimer:
There were also some sed related actions with the file in the environment
which I dropped to reduce noise.

Be Well,
Alan
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] using pip3-native to install python requirements

2018-11-12 Thread Belisko Marek 
On Mon, Nov 12, 2018 at 10:35 AM Outback Dingo  wrote:
>
> On Mon, Nov 12, 2018 at 3:22 PM Belisko Marek  wrote:
> >
> > Hi,
> >
> > I'm having recipe for custom python3 application whcih need to install
> > ~20 python dependencies. I've create requirements.txt and using pip on
> > PC I can install necessary python packages. When try to use
> > pip3-native (as DEPENDS) and call pip3 I get some errors:
> >
> > pkg_resources.VersionConflict: (pip 8.1.1
> > (/usr/lib/python3/dist-packages), Requirement.parse('pip==9.0.1'))
> >
> > I would like to ask it pip3 can be used (didn't find any other
> > occurrence in poky) or should I add python dependencies as RDEPENDS ?
>
> i believe you just need to add inherit setuptools3 to the recipe your
> trying to use pip3 for
Well application doesn't contain setup.py (after inheriting setuptool3 I get:)
recipe-sysroot-native/usr/bin/python3-native/python3: can't open file
'setup.py': [Errno 2] No such file or directory
| ERROR: python3 setup.py build_ext execution failed.

So is the correct way to create setup.py which will internall somehow
add all required external modules to be installed. Thanks.
>
> > Thanks.
> >
> > BR,
> >
> > marek
> >
> >
> > --
> > as simple and primitive as possible
> > -
> > Marek Belisko - OPEN-NANDRA
> > Freelance Developer
> >
> > Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
> > Tel: +421 915 052 184
> > skype: marekwhite
> > twitter: #opennandra
> > web: http://open-nandra.com
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] using pip3-native to install python requirements

2018-11-12 Thread Outback Dingo 
On Mon, Nov 12, 2018 at 3:22 PM Belisko Marek  wrote:
>
> Hi,
>
> I'm having recipe for custom python3 application whcih need to install
> ~20 python dependencies. I've create requirements.txt and using pip on
> PC I can install necessary python packages. When try to use
> pip3-native (as DEPENDS) and call pip3 I get some errors:
>
> pkg_resources.VersionConflict: (pip 8.1.1
> (/usr/lib/python3/dist-packages), Requirement.parse('pip==9.0.1'))
>
> I would like to ask it pip3 can be used (didn't find any other
> occurrence in poky) or should I add python dependencies as RDEPENDS ?

i believe you just need to add inherit setuptools3 to the recipe your
trying to use pip3 for

> Thanks.
>
> BR,
>
> marek
>
>
> --
> as simple and primitive as possible
> -
> Marek Belisko - OPEN-NANDRA
> Freelance Developer
>
> Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
> Tel: +421 915 052 184
> skype: marekwhite
> twitter: #opennandra
> web: http://open-nandra.com
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] yocto x64-linux with bootia32.efi

2018-11-12 Thread Knoppix 
I Searched this question on google, stackoverflow but I did not find.

I am using DISTRO=poky MACHINE=intel-corei7-64 IMAGE=core-image-x11 sceme.
The machine which I want to install image, doesn’t allow bootx64 but it
works when I install x32 efi.
I checked this (I copied first bootia32.efi and then bootx64.efi) and as I
understand my machine has x64 arch but only support x32-efi.

So how can I build an image which is intel-corei7-64 but has grup-efi 32
bit?
Would you advice me please to *what should I read to accomplish and learn *
this?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] using pip3-native to install python requirements

2018-11-12 Thread Belisko Marek 
Hi,

I'm having recipe for custom python3 application whcih need to install
~20 python dependencies. I've create requirements.txt and using pip on
PC I can install necessary python packages. When try to use
pip3-native (as DEPENDS) and call pip3 I get some errors:

pkg_resources.VersionConflict: (pip 8.1.1
(/usr/lib/python3/dist-packages), Requirement.parse('pip==9.0.1'))

I would like to ask it pip3 can be used (didn't find any other
occurrence in poky) or should I add python dependencies as RDEPENDS ?
Thanks.

BR,

marek


--
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto