Re: [yocto] Fwd: [DNF YOCTO clarifications] smart was replaced with dnf in Yocto 2.3
Hello Jussi, I would like to thank you very much for the useful reply. It was a bit different with me, but most boiled down as you said/explained (the difference are in client/server IP addresses, but everything else is almost the same - I guess, I do not have complete set of .rpms on my server side). I issued the following comand on client (qemux86-64): dnf list all | wc -l, and got the following response: *Repository 'oe-packages' is missing name in configuration, using id.* Last metadata expiration check: 0:42:56 ago on Thu Aug 24 06:13:31 2017 UTC *7909* Regarding the command's answer, I have two questions to ask: one easy, and one tough. ;-) Easy one. What is the reason for this message: *Repository 'oe-packages' is missing name in configuration, using id*??? Tough one: 7909 packages overall on server. Could you (YOCTO maintainers), please, keep DNF (for .rpm packages) onwards indefinitely in YOCTO, and make/create master YOCTO download servers, the same what Fedora distro does for almost two decades (with YUM, prior DNF)? The positive answer on the second question will make (for many thousand people using .rpms in YOCTO) life much easier, won't it?! Thank you, Zoran Stojsavljevic On Wed, Aug 23, 2017 at 2:39 PM, Jussi Kukkonen wrote: > > > On 23 August 2017 at 14:51, Zoran Stojsavljevic < > zoran.stojsavlje...@gmail.com> wrote: > >> Hello Jussi, >> >> Let me start giving you all the hints. So you can see where I lead. You >> made few mistakes, so DNF won't work as such/is (by default) in Pyro 2.3.1. >> >> I investigated a bit (I already wrote that I am quite familiar with DNF >> and its concepts). >> >> For the starters: Your DNF repo on Pyro 2.3.1 is in the following >> directory (I built full SATO image for target qemux86-64), transcript from >> my bare metal F26 follows: >> >> [user@localhost poky]$ cd build/tmp/deploy/rpm >> [user@localhost rpm]$ ls -al >> total 564 >> drwxr-xr-x. 5 user user 4096 Aug 22 13:33 . >> drwxr-xr-x. 5 user user 4096 Aug 22 13:28 .. >> drwxr-xr-x. 2 user user 462848 Aug 22 13:32 core2_64 >> drwxr-xr-x. 2 user user 16384 Aug 22 13:32 noarch >> drwxr-xr-x. 2 user user 81920 Aug 22 13:32 qemux86_64 >> [user@localhost rpm]$ cd noarch >> [user@localhost noarch]$ ls -al | wc -l >> 189 >> [user@localhost noarch]$ ls -al *.xml >> ls: cannot access '*.xml': No such file or directory >> [user@localhost noarch]$ >> >> As we see here, there are three .rpm repos on the server (let say, I am >> starting client qemux86-64). If you do the same, and built it for sato (or >> minimal, does not matter), you'll have the same. None of these .rpm repos >> have file which MUST be present there: repomd.xml??? >> >> Where is this file? How to generate it, for/per each local server repo, >> one instance of repomd.xml??? >> > > repomd.xml is created into TMPDIR/deploy/rpm/repodata/ when you run > "bitbake package-index" as the documentation suggested. > > I don't have Pyro but I've just tried this on master and it seems to work > fine (the docs might need updating on the baseurl format though). > > ** On the server: > ~/src/poky/build/tmp/deploy/rpm$ python -m SimpleHTTPServer > Serving HTTP on 0.0.0.0 port 8000 ... > > ** On target qemu: > root@qemux86-64:~# cat /etc/yum.repos.d/oe-packages.repo > [oe-packages] > baseurl=http://192.168.7.3:8000/ > root@qemux86-64:~# dnf makecache > Repository 'oe-packages' is missing name in configuration, using id. > Last metadata expiration check: 0:06:49 ago on Wed Aug 23 12:23:22 2017. > Metadata cache created. > root@qemux86-64:~# dnf --nogpgcheck install libinput-bin > Repository 'oe-packages' is missing name in configuration, using id. > Last metadata expiration check: 0:10:09 ago on Wed Aug 23 12:23:22 2017. > Dependencies resolved. > > > > PackageArch Version > Repository Size > > > > Installing: > libinput-bin core2_64 > 1.8.1-r0 oe-packages12 k > > Transaction Summary > > > > Install 1 Package > > Total download size: 12 k > Installed size: 19 k > Is this ok [y/N]: y > Downloading Packages: > libinput-bin-1.8.1-r0.core2_64.rpm >323 kB/s | 12 kB 00:00 > > > > Total > 134 kB/s | 12 kB 00:00 > Running transaction check > Transa
[yocto] [meta-selinux][PATCH] refpolicy: fix a typo in RDEPENDS
From: Jackie Huang Underscore ("_") should be used for variable overrides. Signed-off-by: Jackie Huang --- recipes-security/refpolicy/refpolicy_common.inc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/recipes-security/refpolicy/refpolicy_common.inc b/recipes-security/refpolicy/refpolicy_common.inc index 6a45e79..4a7b7eb 100644 --- a/recipes-security/refpolicy/refpolicy_common.inc +++ b/recipes-security/refpolicy/refpolicy_common.inc @@ -31,7 +31,7 @@ EXTRANATIVEPATH += "bzip2-native" DEPENDS += "bzip2-replacement-native checkpolicy-native policycoreutils-native m4-native" -RDEPENDS-${PN}-dev =+ " \ +RDEPENDS_${PN}-dev =+ " \ python \ " -- 2.11.0 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] RDEPENDS dependency problem
First of all, thanks for your reply. Il giorno mer 23 ago 2017 alle ore 20:56 Khem Raj ha scritto: > On 8/23/17 1:12 AM, Stefano Pagnottelli wrote: > > Hi to all, > > > > I'm trying to build this layer: > > (https://github.com/bachp/meta-homeassistant) using the yocto pyro on a > > raspberry pi 3 target and the opkg package system. > > > > Inside the recipe > > ( > https://github.com/bachp/meta-homeassistant/blob/master/recipes-homeassistant/homeassistant/python3-homeassistant_0.51.2.bb > ) > > there are some RDEPENDS with strict equal > > dependencies (ex:python3-aiohttp (= 2.2.5)). > > > > We I build the image with the opgk package system the system fail in the > > do_rootfs task because is not finding the package python3-aiohttp = > > 2.2.5.. If I understood correctly this happens because the build system > > si appending the recipe revision (PR variable) at end of package name > > and the results is python3-aiohttp_2.2.5-r0 and not > > python3-aiohttp_2.2.5 as opkg is expecting. > > I dont think r0 is in play here. You can test it by changing dependency > check to look for (= for 2.2.5-r0), I think it should still fail. > I do some tests of on rdendps on the recipe: With python3-aiohttp (= 2.2.5-r0) the image is built without problems, with python3-aiohttp (>= 2.2.5) the image is built without problems, with python3-aiohttp (= 2.2.5) the task fail with the following error: Problem 1/1: - nothing provides python3-aiohttp = 2.2.5 needed by python3-homeassistant-0.51.2-r0.cortexa7hf-neon-vfpv4 So it seems to me that know the recipe revision is mandatory if you want to put a strict dependency on a rdpends. But if I understood correctly the yocto build system it's not possible to predict the recipe revision because is automatically computed, And a change in the recipe will break the dependency also if the source software version is the same because this will change the recipe version. > > > > > As workaround I changed all strict = with a >= and the build complete > > without errors. > > this is ok as long as the package can work with newer versions of this > package. I am not sure if thats the case, you might have to check with > authors intent for using = instead of >= > I think that ,in that case the author is using strict = dependencies because we are trying to compile a python project that strictly depend python module with a specific version. Can be useful to have strict = dependency in a recipe but it is not mandatory, the project compile well also with >=. Regards Stefano > > > > > My question is: It's possible to instruct the build system to ignore > > the recipe revision when it match the version of the package? Or in > > alternative it's possible to automatically detect the recipe revision of > > the package? > > > > Thanks in advance > > Stefano > > … > > -- > > > > There are 10 types of people in this world, those who understand binary > > and those who dont > > > > > > -- There are 10 types of people in this world, those who understand binary and those who dont -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Runtime Dependencies dependent on lowercase recipe name?
Hello, >Now the strange thing happens: copy the helloworld_0.1.bb to >Helloworld_0.1.bb >So the only difference is the lowercase vs capital "H" in the recipe name. welcome to the club! https://bugzilla.yoctoproject.org/show_bug.cgi?id=11592 Hopefully we will have a big red warning/error when we use capital letters again :) G. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [feature request] avoid getting the server stuck because of high "-j" value
Thanks you all for the valuable answers! cheers, Gianfranco -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Fwd: [DNF YOCTO clarifications] smart was replaced with dnf in Yocto 2.3
On 24 August 2017 at 10:33, Zoran Stojsavljevic < zoran.stojsavlje...@gmail.com> wrote: > > Hello Jussi, > > I would like to thank you very much for the useful reply. It was a bit different with me, but most boiled down as you said/explained (the difference are in client/server IP addresses, but everything else is almost the same - I guess, I do not have complete set of .rpms on my server side). > > I issued the following comand on client (qemux86-64): dnf list all | wc -l, and got the following response: > Repository 'oe-packages' is missing name in configuration, using id. > Last metadata expiration check: 0:42:56 ago on Thu Aug 24 06:13:31 2017 UTC > 7909 > > Regarding the command's answer, I have two questions to ask: one easy, and one tough. ;-) > > Easy one. What is the reason for this message: Repository 'oe-packages' is missing name in configuration, using id??? I'm not a yum/dnf expert at all but the error seems to be saying that oe-packages.repo is missing a line like "name = OpenEmbedded packages". > Tough one: 7909 packages overall on server. Could you (YOCTO maintainers), please, keep DNF (for .rpm packages) onwards indefinitely in YOCTO, and make/create master YOCTO download servers, the same what Fedora distro does for almost two decades (with YUM, prior DNF)? > > The positive answer on the second question will make (for many thousand people using .rpms in YOCTO) life much easier, won't it?! No. Yocto is not an operating system, it's a toolset that can be used to build many wildly different operating systems. An rpm repo would only be compatible with one of those OSes. If a Yocto user builds and maintains a specific OS with Yocto, it might make sense for them to maintain rpm repos for that OS. It does not make sense for Yocto project. - Jussi -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Problems building U-Boot for x86_64
Hi Ferry, On 24/08/2017 08:51, Ferry Toth wrote: > Op Wed, 23 Aug 2017 21:07:56 -0700, schreef Khem Raj: > >> On 8/23/17 3:40 PM, Ferry Toth wrote: >>> Op Wed, 23 Aug 2017 14:51:55 -0700, schreef Khem Raj: >>> On 8/23/17 2:29 PM, Ferry Toth wrote: > Ferry Toth wrote: > >> Khem Raj wrote: >> >>> On 8/22/17 11:41 PM, Ferry Toth wrote: I am having trouble building a specific U-Boot version with Yocto. Outside of Yocto on 64 bit Ubuntu 17.04 with multilib it builds fine. I am extending meta-intel-edison to build a 64 bit Poke Morty, with a vanilla 64-bit kernel (4.12). This is working quite well. My host is x86_64, the target is core2 with tune=core-64. Without 64bit tune I can build U-Boot fine. With 64bit it can not link, appearently because it needs lbgcc.a >>> >>> what is exact error message ? is it while compiling host bits or >>> target bits ? >> >> The failing line is: >> x86_64-poky-linux-ld.bfd -Bsymbolic -Bsymbolic-functions -m elf_i386 >> --emit- relocs --wrap=__divdi3 --wrap=__udivdi3 --wrap=__moddi3 >> --wrap=__umoddi3 -- gc-sections -pie -Bstatic --no-dynamic-linker >> -Ttext 0x01101000 -o u-boot -T u-boot.lds arch/x86/cpu/start.o >> --start-group arch/x86/cpu/built-in.o arch/x86/lib/built-in.o >> board/intel/edison/built-in.o cmd/built-in.o common/built-in.o >> disk/built-in.o drivers/built-in.o drivers/dma/built-in.o >> drivers/gpio/built-in.o drivers/i2c/built-in.o >> drivers/mmc/built-in.o drivers/mtd/built-in.o >> drivers/mtd/onenand/built-in.o drivers/mtd/spi/built- in.o >> drivers/net/built-in.o drivers/net/phy/built-in.o drivers/pci/built- >> in.o drivers/power/built-in.o drivers/power/battery/built-in.o >> drivers/power/domain/built-in.o drivers/power/fuel_gauge/built-in.o >> drivers/power/mfd/built-in.o drivers/power/pmic/built-in.o >> drivers/power/regulator/built-in.o drivers/serial/built-in.o >> drivers/spi/built-in.o drivers/usb/common/built-in.o >> drivers/usb/dwc3/built- in.o drivers/usb/emul/built-in.o >> drivers/usb/eth/built-in.o drivers/usb/gadget/built-in.o >> drivers/usb/gadget/udc/built-in.o drivers/usb/host/built-in.o >> drivers/usb/musb-new/built-in.o drivers/usb/musb/built-in.o >> drivers/usb/phy/built-in.o drivers/usb/ulpi/built-in.o >> dts/built-in.o fs/built-in.o lib/built-in.o net/built-in.o >> test/built-in.o test/dm/built-in.o --end-group arch/x86/lib/lib.a >> -Map u-boot.map ERROR: oe_runmake failed arch/x86/lib/built-in.o: In >> function `__wrap___udivdi3': >> /home/ferry/tmp/edison-intel/my/edison- >> morty/out/linux64/build/tmp/work/edison-poky-linux/u-boot/edison- >>> v2017.03- >> r0/git/arch/x86/lib/gcc.c:25: undefined reference to >> `__normal___udivdi3' > > I as believe the missing lib is libgcc.a I just my sysroot and found > it here: the linker cmdline above does not link with libgcc and there might be a good reason for that, many standalone applications dont link with libgcc intentionally. You could look into the code and see if it can be written differently such that gcc does not have to invoke a helper function from gcc runtime. Another option is to link with libgcc explicitly >>> >>> If change my setup to build for a 32bit target, it build u-boot without >>> error. >> >> compiler may not be generating calls for the missing function. > > That would be a bug then? Regardless if I set tune=core-64 or not the > resulting U-Boot should be the same. > >>> When I build the same git outside yocto on 64bit with multilib >>> installed it also builds without error. In that case the make command >>> would be: make -j8 edison_defconfig >> >> same is possible. Can you do readelf -sW gcc.o and see if there is a >> undefined reference to __normal___udivdi3 >> > I will do that tonight. > >>> My conclusion: I have some bb variable set to the wrong value or I need >>> to get multilib installed into //sysroots/x86_64-linux/lib. >>> >>> So how to do that? >>> > sysroots/lib32-edison/usr/lib/i686-pokymllib32-linux/6.2.0/ > sysroots/lib32-edison-tcbootstrap/usr/lib/i686-pokymllib32- > linux/6.2.0/ > sysroots/edison/usr/lib64/x86_64-poky-linux/6.2.0/ > sysroots/edison-tcbootstrap/usr/lib64/x86_64-poky-linux/6.2.0/ > > How compile log shows: > NOTE: make -j8 CROSS_COMPILE=x86_64-poky-linux- > CC=x86_64-poky-linux-gcc --sysroot=//sysroots/edison V=1 > HOSTCC=gcc -isystem//sysroots/x86_64-linux/usr/include -O2 -pipe > -L//sysroots/x86_64-linux/usr/lib > -L//sysroots/x86_64-linux/lib > -Wl,-rpath-link,//sysroots/x86_64-linux/usr/lib > -Wl,-rpath-link,//sysroots/x86_64-linux/lib > -Wl,-rpath,//sysroots/x86_64-linux/usr/lib > -Wl,-rpath,//sysroots/x86_64-linux/lib -Wl,-O1 -C
[yocto] [meta-raspberrypi][PATCH] bluez5: add functions for raspberrypi0-wifi
I could not use bluetooth with raspberrypi0-wifi. hciattach on raspberrypi0-wifi failed because BCM43430A1.hcd is not found. Functions in bluez5_%.bbappend should be enabled with raspberrypi0-wifi too. I know that these changes are redundant. If you have any ideas for better solution, let me know. Yusuke Mitsuki (1): bluez5: add functions for raspberrypi0-wifi recipes-connectivity/bluez5/bluez5_%.bbappend | 25 + 1 file changed, 25 insertions(+) -- 2.7.4 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-raspberrypi][PATCH] bluez5: add functions for raspberrypi0-wifi
hciattach on raspberrypi0-wifi failed because BCM43430A1.hcd is not found. Paches that in order to use bluetooth with BCM43430 are not enabled. Functions are only enabled with raspberrypi3 in bluez5_%.bbappend like as follows: - SRC_URI_append_raspberrypi3 - do_install_append_raspberrypi3() - FILES_${PN}_append_raspberrypi3 - SYSTEMD_SERVICE_${PN}_append_raspberrypi3 These should be enabled with raspberrypi0-wifi too. Signed-off-by: Yusuke Mitsuki --- recipes-connectivity/bluez5/bluez5_%.bbappend | 25 + 1 file changed, 25 insertions(+) diff --git a/recipes-connectivity/bluez5/bluez5_%.bbappend b/recipes-connectivity/bluez5/bluez5_%.bbappend index 956d776..075dc2b 100644 --- a/recipes-connectivity/bluez5/bluez5_%.bbappend +++ b/recipes-connectivity/bluez5/bluez5_%.bbappend @@ -24,3 +24,28 @@ FILES_${PN}_append_raspberrypi3 = " \ " SYSTEMD_SERVICE_${PN}_append_raspberrypi3 = " brcm43438.service" + +SRC_URI_append_raspberrypi0-wifi = " \ +file://BCM43430A1.hcd \ +file://0001-bcm43xx-Add-bcm43xx-3wire-variant.patch \ +file://0002-bcm43xx-The-UART-speed-must-be-reset-after-the-firmw.patch \ +file://0003-Increase-firmware-load-timeout-to-30s.patch \ +file://0004-Move-the-43xx-firmware-into-lib-firmware.patch \ +file://brcm43438.service \ +" + +do_install_append_raspberrypi0-wifi() { +install -d ${D}/lib/firmware/brcm/ +install -m 0644 ${WORKDIR}/BCM43430A1.hcd ${D}/lib/firmware/brcm/BCM43430A1.hcd + +if ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'true', 'false', d)}; then +install -d ${D}${systemd_unitdir}/system +install -m 0644 ${WORKDIR}/brcm43438.service ${D}${systemd_unitdir}/system +fi +} + +FILES_${PN}_append_raspberrypi0-wifi = " \ +/lib/firmware/brcm/BCM43430A1.hcd \ +" + +SYSTEMD_SERVICE_${PN}_append_raspberrypi0-wifi = " brcm43438.service" -- 2.7.4 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-yocto-bsp][PATCH] machine: mpc8315e-rdb: change kernel provider assignment to default
To be able to configure the kernel provider at other locations, we need a default assignment here. Signed-off-by: Stefan Müller-Klieser --- meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf b/meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf index ce5015256a23..b6cb49b58358 100644 --- a/meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf +++ b/meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf @@ -15,7 +15,7 @@ SERIAL_CONSOLE = "115200 ttyS0" MACHINE_FEATURES = "keyboard pci ext2 ext3 serial" PREFERRED_VERSION_linux-yocto ?= "4.10%" -PREFERRED_PROVIDER_virtual/kernel = "linux-yocto" +PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto" PREFERRED_PROVIDER_virtual/xserver ?= "xserver-xorg" XSERVER ?= "xserver-xorg \ -- 1.9.1 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Problems building U-Boot for x86_64
Op Thu, 24 Aug 2017 12:40:57 +0200, schreef Stefano Babic: > Hi Ferry, > > On 24/08/2017 08:51, Ferry Toth wrote: >> Op Wed, 23 Aug 2017 21:07:56 -0700, schreef Khem Raj: >> >>> On 8/23/17 3:40 PM, Ferry Toth wrote: Op Wed, 23 Aug 2017 14:51:55 -0700, schreef Khem Raj: > On 8/23/17 2:29 PM, Ferry Toth wrote: >> Ferry Toth wrote: >> >>> Khem Raj wrote: >>> On 8/22/17 11:41 PM, Ferry Toth wrote: > I am having trouble building a specific U-Boot version with > Yocto. > Outside of Yocto on 64 bit Ubuntu 17.04 with multilib it builds > fine. > > I am extending meta-intel-edison to build a 64 bit Poke Morty, > with a vanilla 64-bit kernel (4.12). This is working quite well. > > My host is x86_64, the target is core2 with tune=core-64. > > Without 64bit tune I can build U-Boot fine. With 64bit it can > not link, appearently because it needs lbgcc.a what is exact error message ? is it while compiling host bits or target bits ? >>> >>> The failing line is: >>> x86_64-poky-linux-ld.bfd -Bsymbolic -Bsymbolic-functions -m >>> elf_i386 --emit- relocs --wrap=__divdi3 --wrap=__udivdi3 >>> --wrap=__moddi3 --wrap=__umoddi3 -- gc-sections -pie -Bstatic >>> --no-dynamic-linker -Ttext 0x01101000 -o u-boot -T u-boot.lds >>> arch/x86/cpu/start.o --start-group arch/x86/cpu/built-in.o >>> arch/x86/lib/built-in.o board/intel/edison/built-in.o >>> cmd/built-in.o common/built-in.o disk/built-in.o >>> drivers/built-in.o drivers/dma/built-in.o drivers/gpio/built-in.o >>> drivers/i2c/built-in.o drivers/mmc/built-in.o >>> drivers/mtd/built-in.o drivers/mtd/onenand/built-in.o >>> drivers/mtd/spi/built- in.o drivers/net/built-in.o >>> drivers/net/phy/built-in.o drivers/pci/built- >>> in.o drivers/power/built-in.o drivers/power/battery/built-in.o >>> drivers/power/domain/built-in.o >>> drivers/power/fuel_gauge/built-in.o drivers/power/mfd/built-in.o >>> drivers/power/pmic/built-in.o drivers/power/regulator/built-in.o >>> drivers/serial/built-in.o drivers/spi/built-in.o >>> drivers/usb/common/built-in.o drivers/usb/dwc3/built- in.o >>> drivers/usb/emul/built-in.o drivers/usb/eth/built-in.o >>> drivers/usb/gadget/built-in.o drivers/usb/gadget/udc/built-in.o >>> drivers/usb/host/built-in.o drivers/usb/musb-new/built-in.o >>> drivers/usb/musb/built-in.o drivers/usb/phy/built-in.o >>> drivers/usb/ulpi/built-in.o dts/built-in.o fs/built-in.o >>> lib/built-in.o net/built-in.o test/built-in.o test/dm/built-in.o >>> --end-group arch/x86/lib/lib.a -Map u-boot.map ERROR: oe_runmake >>> failed arch/x86/lib/built-in.o: In function `__wrap___udivdi3': >>> /home/ferry/tmp/edison-intel/my/edison- >>> morty/out/linux64/build/tmp/work/edison-poky-linux/u-boot/edison- v2017.03- >>> r0/git/arch/x86/lib/gcc.c:25: undefined reference to >>> `__normal___udivdi3' >> >> I as believe the missing lib is libgcc.a I just my sysroot and >> found it here: > > the linker cmdline above does not link with libgcc and there might > be a good reason for that, many standalone applications dont link > with libgcc intentionally. You could look into the code and see if > it can be written differently such that gcc does not have to invoke > a helper function from gcc runtime. Another option is to link with > libgcc explicitly If change my setup to build for a 32bit target, it build u-boot without error. >>> >>> compiler may not be generating calls for the missing function. >> >> That would be a bug then? Regardless if I set tune=core-64 or not the >> resulting U-Boot should be the same. >> When I build the same git outside yocto on 64bit with multilib installed it also builds without error. In that case the make command would be: make -j8 edison_defconfig >>> >>> same is possible. Can you do readelf -sW gcc.o and see if there is a >>> undefined reference to __normal___udivdi3 >>> >> I will do that tonight. >> My conclusion: I have some bb variable set to the wrong value or I need to get multilib installed into //sysroots/x86_64-linux/lib. So how to do that? >> sysroots/lib32-edison/usr/lib/i686-pokymllib32-linux/6.2.0/ >> sysroots/lib32-edison-tcbootstrap/usr/lib/i686-pokymllib32- >> linux/6.2.0/ >> sysroots/edison/usr/lib64/x86_64-poky-linux/6.2.0/ >> sysroots/edison-tcbootstrap/usr/lib64/x86_64-poky-linux/6.2.0/ >> >> How compile log shows: >> NOTE: make -j8 CROSS_COMPILE=x86_64-poky-linux- >> CC=x86_64-poky-linux-gcc --sysroot=//sysroots/edison V=1 >> HOSTCC=gcc -isystem//sysroots/x86_64-linux/usr/include -O2 >> -pipe -L//sysroots/x86_64-linux/usr/lib >> -L//sysroots/x86_64-linux/lib >> -Wl,-rpath-link,//sysroots/x86_64
Re: [yocto] Fwd: [DNF YOCTO clarifications] smart was replaced with dnf in Yocto 2.3
> No. Yocto is not an operating system, it's a toolset that can be used to build many wildly different operating systems. An rpm repo would > only be compatible with one of those OSes. YOCTO is a custom made distro for eLinuxes, on this I agree with you. At least, you should keep DNF (instead smartpm) as package representative for dealing with .rpms, in all future YOCTO releases. This should be (as considering embedded use cases) enough. And, yes, I see your point, if anybody has so big project that he would like to make master servers and maintain his own source code packages (.src.rpm), and plain .rpm (as Fedora does, I just run there on Fedora 26 command: dnf list all | wc -l and got package # around 60K), he should do this on his own. ;-) Do you agree to continue keeping DNF package (in .../meta/recipe_devtools/) for handling of .rpm type of packages in the future releases of YOCTO (it is, after all, much better and more mature tool that smartpm)? Thank you, Zoran On Thu, Aug 24, 2017 at 12:40 PM, Jussi Kukkonen wrote: > On 24 August 2017 at 10:33, Zoran Stojsavljevic < > zoran.stojsavlje...@gmail.com> wrote: > > > > Hello Jussi, > > > > I would like to thank you very much for the useful reply. It was a bit > different with me, but most boiled down as you said/explained (the > difference are in client/server IP addresses, but everything else is almost > the same - I guess, I do not have complete set of .rpms on my server side). > > > > I issued the following comand on client (qemux86-64): dnf list all | wc > -l, and got the following response: > > Repository 'oe-packages' is missing name in configuration, using id. > > Last metadata expiration check: 0:42:56 ago on Thu Aug 24 06:13:31 2017 > UTC > > 7909 > > > > Regarding the command's answer, I have two questions to ask: one easy, > and one tough. ;-) > > > > Easy one. What is the reason for this message: Repository 'oe-packages' > is missing name in configuration, using id??? > > I'm not a yum/dnf expert at all but the error seems to be saying that > oe-packages.repo is missing a line like "name = OpenEmbedded packages". > > > Tough one: 7909 packages overall on server. Could you (YOCTO > maintainers), please, keep DNF (for .rpm packages) onwards indefinitely in > YOCTO, and make/create master YOCTO download servers, the same what Fedora > distro does for almost two decades (with YUM, prior DNF)? > > > > The positive answer on the second question will make (for many thousand > people using .rpms in YOCTO) life much easier, won't it?! > > No. Yocto is not an operating system, it's a toolset that can be used to > build many wildly different operating systems. An rpm repo would only be > compatible with one of those OSes. > > If a Yocto user builds and maintains a specific OS with Yocto, it might > make sense for them to maintain rpm repos for that OS. It does not make > sense for Yocto project. > > - Jussi > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Fwd: [DNF YOCTO clarifications] smart was replaced with dnf in Yocto 2.3
On 08/24/2017 05:34 PM, Zoran Stojsavljevic wrote: Do you agree to continue keeping DNF package (in .../meta/recipe_devtools/) for handling of .rpm type of packages in the future releases of YOCTO (it is, after all, much better and more mature tool that smartpm)? The smart to dnf transition is now complete, and it has been well documented: http://www.yoctoproject.org/docs/2.3/ref-manual/ref-manual.html#migration-2.3-package-management-changes Alex -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] ERROR: Unable to connect to bitbake server, or start one
Hi I started to study bitbake and decided to repeat the BitBake Hello World from the manual (http://www.yoctoproject.org/docs/2.3.1/bitbake-user-manual/bitbake-user-manual.html#bitbake-hello-world). I do everything according to the instructions, but when I run the bitbake command, I get the following output: NOTE: Retrying server connection... (Traceback (most recent call last): File "/home/leonid/test/bitbake/lib/bb/main.py", line 432, in setup_bitbake topdir, lock = lockBitbake() File "/home/leonid/test/bitbake/lib/bb/main.py", line 484, in lockBitbake lockfile = topdir + "/bitbake.lock" TypeError: unsupported operand type(s) for +: 'NoneType' and 'str' ) This is repeated five times, and at the end: ERROR: Unable to connect to bitbake server, or start one Could someone please tell me what the problem is and what I can do about it? I'm using Kubuntu 17.04 and clear Ubuntu 17.04. BitBake Build Tool Core version 1.35.0 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Problems building U-Boot for x86_64
Hi Ferry, On 24/08/2017 15:09, Ferry Toth wrote: > Op Thu, 24 Aug 2017 12:40:57 +0200, schreef Stefano Babic: > >> Hi Ferry, >> >> On 24/08/2017 08:51, Ferry Toth wrote: >>> Op Wed, 23 Aug 2017 21:07:56 -0700, schreef Khem Raj: >>> On 8/23/17 3:40 PM, Ferry Toth wrote: > Op Wed, 23 Aug 2017 14:51:55 -0700, schreef Khem Raj: > >> On 8/23/17 2:29 PM, Ferry Toth wrote: >>> Ferry Toth wrote: >>> Khem Raj wrote: > On 8/22/17 11:41 PM, Ferry Toth wrote: >> I am having trouble building a specific U-Boot version with >> Yocto. >> Outside of Yocto on 64 bit Ubuntu 17.04 with multilib it builds >> fine. >> >> I am extending meta-intel-edison to build a 64 bit Poke Morty, >> with a vanilla 64-bit kernel (4.12). This is working quite well. >> >> My host is x86_64, the target is core2 with tune=core-64. >> >> Without 64bit tune I can build U-Boot fine. With 64bit it can >> not link, appearently because it needs lbgcc.a > > what is exact error message ? is it while compiling host bits or > target bits ? The failing line is: x86_64-poky-linux-ld.bfd -Bsymbolic -Bsymbolic-functions -m elf_i386 --emit- relocs --wrap=__divdi3 --wrap=__udivdi3 --wrap=__moddi3 --wrap=__umoddi3 -- gc-sections -pie -Bstatic --no-dynamic-linker -Ttext 0x01101000 -o u-boot -T u-boot.lds arch/x86/cpu/start.o --start-group arch/x86/cpu/built-in.o arch/x86/lib/built-in.o board/intel/edison/built-in.o cmd/built-in.o common/built-in.o disk/built-in.o drivers/built-in.o drivers/dma/built-in.o drivers/gpio/built-in.o drivers/i2c/built-in.o drivers/mmc/built-in.o drivers/mtd/built-in.o drivers/mtd/onenand/built-in.o drivers/mtd/spi/built- in.o drivers/net/built-in.o drivers/net/phy/built-in.o drivers/pci/built- in.o drivers/power/built-in.o drivers/power/battery/built-in.o drivers/power/domain/built-in.o drivers/power/fuel_gauge/built-in.o drivers/power/mfd/built-in.o drivers/power/pmic/built-in.o drivers/power/regulator/built-in.o drivers/serial/built-in.o drivers/spi/built-in.o drivers/usb/common/built-in.o drivers/usb/dwc3/built- in.o drivers/usb/emul/built-in.o drivers/usb/eth/built-in.o drivers/usb/gadget/built-in.o drivers/usb/gadget/udc/built-in.o drivers/usb/host/built-in.o drivers/usb/musb-new/built-in.o drivers/usb/musb/built-in.o drivers/usb/phy/built-in.o drivers/usb/ulpi/built-in.o dts/built-in.o fs/built-in.o lib/built-in.o net/built-in.o test/built-in.o test/dm/built-in.o --end-group arch/x86/lib/lib.a -Map u-boot.map ERROR: oe_runmake failed arch/x86/lib/built-in.o: In function `__wrap___udivdi3': /home/ferry/tmp/edison-intel/my/edison- morty/out/linux64/build/tmp/work/edison-poky-linux/u-boot/edison- > v2017.03- r0/git/arch/x86/lib/gcc.c:25: undefined reference to `__normal___udivdi3' >>> >>> I as believe the missing lib is libgcc.a I just my sysroot and >>> found it here: >> >> the linker cmdline above does not link with libgcc and there might >> be a good reason for that, many standalone applications dont link >> with libgcc intentionally. You could look into the code and see if >> it can be written differently such that gcc does not have to invoke >> a helper function from gcc runtime. Another option is to link with >> libgcc explicitly > > If change my setup to build for a 32bit target, it build u-boot > without error. compiler may not be generating calls for the missing function. >>> >>> That would be a bug then? Regardless if I set tune=core-64 or not the >>> resulting U-Boot should be the same. >>> > When I build the same git outside yocto on 64bit with multilib > installed it also builds without error. In that case the make command > would be: make -j8 edison_defconfig same is possible. Can you do readelf -sW gcc.o and see if there is a undefined reference to __normal___udivdi3 >>> I will do that tonight. >>> > My conclusion: I have some bb variable set to the wrong value or I > need to get multilib installed into //sysroots/x86_64-linux/lib. > > So how to do that? > >>> sysroots/lib32-edison/usr/lib/i686-pokymllib32-linux/6.2.0/ >>> sysroots/lib32-edison-tcbootstrap/usr/lib/i686-pokymllib32- >>> linux/6.2.0/ >>> sysroots/edison/usr/lib64/x86_64-poky-linux/6.2.0/ >>> sysroots/edison-tcbootstrap/usr/lib64/x86_64-poky-linux/6.2.0/ >>> >>> How compile log shows: >>> NOTE: make -j8 CROSS_COMPILE=x86_64-poky-linux- >>> CC=x86_64-poky-linux-gcc --sysroot=//sysroots/edison V=1 >>> HOSTCC=gcc -isystem//sysroots/x86_64-linu
Re: [yocto] Problems building U-Boot for x86_64
Op Thu, 24 Aug 2017 17:48:55 +0200, schreef Stefano Babic: > Hi Ferry, > > On 24/08/2017 15:09, Ferry Toth wrote: >> Op Thu, 24 Aug 2017 12:40:57 +0200, schreef Stefano Babic: >> >>> Hi Ferry, >>> >>> On 24/08/2017 08:51, Ferry Toth wrote: Op Wed, 23 Aug 2017 21:07:56 -0700, schreef Khem Raj: > On 8/23/17 3:40 PM, Ferry Toth wrote: >> Op Wed, 23 Aug 2017 14:51:55 -0700, schreef Khem Raj: >> >>> On 8/23/17 2:29 PM, Ferry Toth wrote: Ferry Toth wrote: > Khem Raj wrote: > >> On 8/22/17 11:41 PM, Ferry Toth wrote: >>> I am having trouble building a specific U-Boot version with >>> Yocto. >>> Outside of Yocto on 64 bit Ubuntu 17.04 with multilib it >>> builds fine. >>> >>> I am extending meta-intel-edison to build a 64 bit Poke Morty, >>> with a vanilla 64-bit kernel (4.12). This is working quite >>> well. >>> >>> My host is x86_64, the target is core2 with tune=core-64. >>> >>> Without 64bit tune I can build U-Boot fine. With 64bit it can >>> not link, appearently because it needs lbgcc.a >> >> what is exact error message ? is it while compiling host bits >> or target bits ? > > The failing line is: > x86_64-poky-linux-ld.bfd -Bsymbolic -Bsymbolic-functions -m > elf_i386 --emit- relocs --wrap=__divdi3 --wrap=__udivdi3 > --wrap=__moddi3 --wrap=__umoddi3 -- gc-sections -pie -Bstatic > --no-dynamic-linker -Ttext 0x01101000 -o u-boot -T u-boot.lds > arch/x86/cpu/start.o --start-group arch/x86/cpu/built-in.o > arch/x86/lib/built-in.o board/intel/edison/built-in.o > cmd/built-in.o common/built-in.o disk/built-in.o > drivers/built-in.o drivers/dma/built-in.o > drivers/gpio/built-in.o drivers/i2c/built-in.o > drivers/mmc/built-in.o drivers/mtd/built-in.o > drivers/mtd/onenand/built-in.o drivers/mtd/spi/built- in.o > drivers/net/built-in.o drivers/net/phy/built-in.o > drivers/pci/built- > in.o drivers/power/built-in.o drivers/power/battery/built-in.o > drivers/power/domain/built-in.o > drivers/power/fuel_gauge/built-in.o drivers/power/mfd/built-in.o > drivers/power/pmic/built-in.o drivers/power/regulator/built-in.o > drivers/serial/built-in.o drivers/spi/built-in.o > drivers/usb/common/built-in.o drivers/usb/dwc3/built- in.o > drivers/usb/emul/built-in.o drivers/usb/eth/built-in.o > drivers/usb/gadget/built-in.o drivers/usb/gadget/udc/built-in.o > drivers/usb/host/built-in.o drivers/usb/musb-new/built-in.o > drivers/usb/musb/built-in.o drivers/usb/phy/built-in.o > drivers/usb/ulpi/built-in.o dts/built-in.o fs/built-in.o > lib/built-in.o net/built-in.o test/built-in.o test/dm/built-in.o > --end-group arch/x86/lib/lib.a -Map u-boot.map ERROR: oe_runmake > failed arch/x86/lib/built-in.o: In function `__wrap___udivdi3': > /home/ferry/tmp/edison-intel/my/edison- > morty/out/linux64/build/tmp/work/edison-poky-linux/u-boot/ edison- >> v2017.03- > r0/git/arch/x86/lib/gcc.c:25: undefined reference to > `__normal___udivdi3' I as believe the missing lib is libgcc.a I just my sysroot and found it here: >>> >>> the linker cmdline above does not link with libgcc and there might >>> be a good reason for that, many standalone applications dont link >>> with libgcc intentionally. You could look into the code and see if >>> it can be written differently such that gcc does not have to >>> invoke a helper function from gcc runtime. Another option is to >>> link with libgcc explicitly >> >> If change my setup to build for a 32bit target, it build u-boot >> without error. > > compiler may not be generating calls for the missing function. That would be a bug then? Regardless if I set tune=core-64 or not the resulting U-Boot should be the same. >> When I build the same git outside yocto on 64bit with multilib >> installed it also builds without error. In that case the make >> command would be: make -j8 edison_defconfig > > same is possible. Can you do readelf -sW gcc.o and see if there is a > undefined reference to __normal___udivdi3 > I will do that tonight. >> My conclusion: I have some bb variable set to the wrong value or I >> need to get multilib installed into >> //sysroots/x86_64-linux/lib. >> >> So how to do that? >> sysroots/lib32-edison/usr/lib/i686-pokymllib32-linux/6.2.0/ sysroots/lib32-edison-tcbootstrap/usr/lib/i686-pokymllib32- linux/6.2.0/ sysroots/edison/usr/lib64/x86_64-poky-linux/6.2.0/ sysroots/edison-tcbootstrap/usr/lib64/x86_64-poky-linux/6.2.0/ H
Re: [yocto] ERROR: Unable to connect to bitbake server, or start one
On Thu, 2017-08-24 at 18:24 +0300, Gera Pesikoff wrote: > Hi > I started to study bitbake and decided to repeat the BitBake Hello > World from the manual > (http://www.yoctoproject.org/docs/2.3.1/bitbake-user-manual/bitbake-user-manual.html#bitbake-hello-world). > I do everything according to the instructions, but when I run the > bitbake command, I get the following output: > > NOTE: Retrying server connection... (Traceback (most recent call > last): > File "/home/leonid/test/bitbake/lib/bb/main.py", line 432, in > setup_bitbake > topdir, lock = lockBitbake() > File "/home/leonid/test/bitbake/lib/bb/main.py", line 484, in > lockBitbake > lockfile = topdir + "/bitbake.lock" > TypeError: unsupported operand type(s) for +: 'NoneType' and 'str' > ) > > This is repeated five times, and at the end: > > ERROR: Unable to connect to bitbake server, or start one Are you running bitbake from the build folder (TOPDIR)? > > Could someone please tell me what the problem is and what I can do > about it? > I'm using Kubuntu 17.04 and clear Ubuntu 17.04. BitBake Build Tool > Core version 1.35.0 > > -- > ___ > 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] OpenEmbedded Developer Meeting Oct 22, 2017 in Prague (before ELCE)
Once again we will have a developer meeting in Prague the Sunday before ELCE. Please go to https://www.openembedded.org/wiki/OEDEM_2017 and add yourself if you are attending and ideas for topics. Although it is called a developer meeting, we invite members of the larger community to attend. The core developers are always interested in hearing how OpenEmbedded is used, and what we can do to make it better for building the embedded devices of the future. Thanks, Philip -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Problems building U-Boot for x86_64
Op Thu, 24 Aug 2017 16:35:05 +, schreef Ferry Toth: > Op Thu, 24 Aug 2017 17:48:55 +0200, schreef Stefano Babic: > >> Hi Ferry, >> >> On 24/08/2017 15:09, Ferry Toth wrote: >>> Op Thu, 24 Aug 2017 12:40:57 +0200, schreef Stefano Babic: >>> Hi Ferry, On 24/08/2017 08:51, Ferry Toth wrote: > Op Wed, 23 Aug 2017 21:07:56 -0700, schreef Khem Raj: > >> On 8/23/17 3:40 PM, Ferry Toth wrote: >>> Op Wed, 23 Aug 2017 14:51:55 -0700, schreef Khem Raj: >>> On 8/23/17 2:29 PM, Ferry Toth wrote: > Ferry Toth wrote: > >> Khem Raj wrote: >> >>> On 8/22/17 11:41 PM, Ferry Toth wrote: I am having trouble building a specific U-Boot version with Yocto. Outside of Yocto on 64 bit Ubuntu 17.04 with multilib it builds fine. I am extending meta-intel-edison to build a 64 bit Poke Morty, with a vanilla 64-bit kernel (4.12). This is working quite well. My host is x86_64, the target is core2 with tune=core-64. Without 64bit tune I can build U-Boot fine. With 64bit it can not link, appearently because it needs lbgcc.a >>> >>> what is exact error message ? is it while compiling host bits >>> or target bits ? >> >> The failing line is: >> x86_64-poky-linux-ld.bfd -Bsymbolic -Bsymbolic-functions -m >> elf_i386 --emit- relocs --wrap=__divdi3 --wrap=__udivdi3 >> --wrap=__moddi3 --wrap=__umoddi3 -- gc-sections -pie -Bstatic >> --no-dynamic-linker -Ttext 0x01101000 -o u-boot -T u-boot.lds >> arch/x86/cpu/start.o --start-group arch/x86/cpu/built-in.o >> arch/x86/lib/built-in.o board/intel/edison/built-in.o >> cmd/built-in.o common/built-in.o disk/built-in.o >> drivers/built-in.o drivers/dma/built-in.o >> drivers/gpio/built-in.o drivers/i2c/built-in.o >> drivers/mmc/built-in.o drivers/mtd/built-in.o >> drivers/mtd/onenand/built-in.o drivers/mtd/spi/built- in.o >> drivers/net/built-in.o drivers/net/phy/built-in.o >> drivers/pci/built- >> in.o drivers/power/built-in.o drivers/power/battery/built-in.o >> drivers/power/domain/built-in.o >> drivers/power/fuel_gauge/built-in.o >> drivers/power/mfd/built-in.o drivers/power/pmic/built-in.o >> drivers/power/regulator/built-in.o drivers/serial/built-in.o >> drivers/spi/built-in.o drivers/usb/common/built-in.o >> drivers/usb/dwc3/built- in.o drivers/usb/emul/built-in.o >> drivers/usb/eth/built-in.o drivers/usb/gadget/built-in.o >> drivers/usb/gadget/udc/built-in.o drivers/usb/host/built-in.o >> drivers/usb/musb-new/built-in.o drivers/usb/musb/built-in.o >> drivers/usb/phy/built-in.o drivers/usb/ulpi/built-in.o >> dts/built-in.o fs/built-in.o lib/built-in.o net/built-in.o >> test/built-in.o test/dm/built-in.o --end-group >> arch/x86/lib/lib.a -Map u-boot.map ERROR: oe_runmake failed >> arch/x86/lib/built-in.o: In function `__wrap___udivdi3': >> /home/ferry/tmp/edison-intel/my/edison- >> morty/out/linux64/build/tmp/work/edison-poky-linux/u-boot/ > edison- >>> v2017.03- >> r0/git/arch/x86/lib/gcc.c:25: undefined reference to >> `__normal___udivdi3' > > I as believe the missing lib is libgcc.a I just my sysroot and > found it here: the linker cmdline above does not link with libgcc and there might be a good reason for that, many standalone applications dont link with libgcc intentionally. You could look into the code and see if it can be written differently such that gcc does not have to invoke a helper function from gcc runtime. Another option is to link with libgcc explicitly >>> >>> If change my setup to build for a 32bit target, it build u-boot >>> without error. >> >> compiler may not be generating calls for the missing function. > > That would be a bug then? Regardless if I set tune=core-64 or not > the resulting U-Boot should be the same. > >>> When I build the same git outside yocto on 64bit with multilib >>> installed it also builds without error. In that case the make >>> command would be: make -j8 edison_defconfig >> >> same is possible. Can you do readelf -sW gcc.o and see if there is >> a undefined reference to __normal___udivdi3 >> > I will do that tonight. > >>> My conclusion: I have some bb variable set to the wrong value or I >>> need to get multilib installed into >>> //sysroots/x86_64-linux/lib. >>> >>> So how to do that? >>> > sysroots/lib32-edison/usr/lib/i686-pokymllib32-linux/6.2.0/ > sysroots/lib32-edison-tcbootstrap/usr
Re: [yocto] [layerindex-web][PATCH v2] Asynchronous email notifications, task execution
Hi Diana, On Thursday, 24 August 2017 12:58:38 PM NZST Diana Thayer wrote: > This patch adds asynchronous task execution using a Celery backend > and RabbitMQ task queue. > > It updates the README to reflect the installation and configuration > of a basic RabbitMQ setup, adds a 'tasks.py' file to contain task > definitions, updates the 'edit_layer_view' function to send > emails to administrators about new and updated layers asynchronously, > and modifies the 'settings.py' to include a default configuration > for a RabbitMQ connection. This summarises what the patch does, which is useful, but it misses out the most important bit - why we're making this change, i.e. to allow layer submission process to proceed even in the event that sending the notification email fails, and establishing an asynchronous execution mechanism that we can use in future e.g. for triggering parse operations from the web UI. If you could also include a reference to the bug in the form [YOCTO #11197] that would be great. Please also add your Signed-off-by which is missing. One other comment below. > > --- a/layerindex/views.py > +++ b/layerindex/views.py > @@ -19,7 +19,6 @@ from layerindex.forms import EditLayerForm, > LayerMaintainerFormSet, EditNoteForm > from django.db import transaction > from django.contrib.auth.models import User, Permission > from django.db.models import Q, Count, Sum > -from django.core.mail import EmailMessage > from django.template.loader import get_template > from django.template import Context > from django.utils.decorators import method_decorator > @@ -28,6 +27,7 @@ from django.contrib import messages > from reversion.models import Revision > from . import utils > from . import simplesearch > +from . import tasks > import settings > from django.dispatch import receiver > import reversion > @@ -163,7 +163,7 @@ def edit_layer_view(request, template_name, > branch='master', slug=None): > # Send email > plaintext = get_template('layerindex/submitemail.txt') > perm = Permission.objects.get(codename='publish_layer') > -users = User.objects.filter(Q(groups__permissions=perm) > | Q(user_permissions=perm) ).distinct() > +users = User.objects.filter(Q(groups__permissions=perm) > | Q(user_permissions=perm) | Q(is_superuser=True)).distinct() I forgot to mention this earlier - can you make this a separate patch? It's not directly related. (It was mostly intentional, but I can see that it's a permission and therefore it can be argued that a superuser should logically have it, so I'm OK with it.) Thanks, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Yocto plug-in not running cmake
Yocto 2.2.1, standard SDK for RPi, Yocto plug-in for Eclipse Mars I do File -> New -> C Project, give it a name, select Project Type -> Yocto Project SDK CMake Project -> Hello World C CMake Project, click Finish, and it creates a project. I click the build button, and it runs "make all" and complains "make: *** No rule to make target 'all'. Stop." Why is it running make and not cmake? It's hard to imagine that I made a mistake somewhere in those two steps. -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Python module and build_ext args
I'm trying to make a recipe for python3-uvloop, using setuptools3. The Python 3 uvloop module depends on libuv. It bundles a version of libuv, and setup.py tries to build it, but it doesn't work well for cross-compilation. However, it also provides a build_ext parameter "--use-system-libuv", which seems to work when I try running it manually in devshell. (I have made a suitable recipe for libuv and added libuv to DEPENDS.) How can I specify the "--use-system-libuv" parameter for build_ext in the python3-uvloop recipe? I see a reference to DISTUTILS_BUILD_EXT_ARGS, but it doesn't seem to be functional. -- Craig McQueen -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Python module and build_ext args
I wrote: > I'm trying to make a recipe for python3-uvloop, using setuptools3. > > The Python 3 uvloop module depends on libuv. It bundles a version of libuv, > and setup.py tries to build it, but it doesn't work well for > cross-compilation. > However, it also provides a build_ext parameter "--use-system-libuv", which > seems to work when I try running it manually in devshell. (I have made a > suitable recipe for libuv and added libuv to DEPENDS.) > > How can I specify the "--use-system-libuv" parameter for build_ext in the > python3-uvloop recipe? I see a reference to DISTUTILS_BUILD_EXT_ARGS, > but it doesn't seem to be functional. I see DISTUTILS_BUILD_EXT_ARGS was submitted in this patch: https://patchwork.openembedded.org/patch/66071/ However, in the Yocto poky repository, I see commit 0221af0f4ee9e8bfb8796841bdf806e38bc600c6 which appears to be a broken version of the above patch with the separate build_ext step not actually executed with the DISTUTILS_BUILD_EXT_ARGS parameters. -- Craig McQueen -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Python module and build_ext args
On Thu, Aug 24, 2017 at 6:48 PM Craig McQueen wrote: > I wrote: > > I'm trying to make a recipe for python3-uvloop, using setuptools3. > > > > The Python 3 uvloop module depends on libuv. It bundles a version of > libuv, > > and setup.py tries to build it, but it doesn't work well for > cross-compilation. > > However, it also provides a build_ext parameter "--use-system-libuv", > which > > seems to work when I try running it manually in devshell. (I have made a > > suitable recipe for libuv and added libuv to DEPENDS.) > > > > How can I specify the "--use-system-libuv" parameter for build_ext in the > > python3-uvloop recipe? I see a reference to DISTUTILS_BUILD_EXT_ARGS, > > but it doesn't seem to be functional. > > > I see DISTUTILS_BUILD_EXT_ARGS was submitted in this patch: > https://patchwork.openembedded.org/patch/66071/ > > However, in the Yocto poky repository, I see commit > 0221af0f4ee9e8bfb8796841bdf806e38bc600c6 which appears to be a broken > version of the above patch with the separate build_ext step not actually > executed with the DISTUTILS_BUILD_EXT_ARGS parameters. You did not explain broken in which sense ? > > > -- > Craig McQueen > > -- > ___ > 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] Python module and build_ext args
Khem Raj wrote: On Thu, Aug 24, 2017 at 6:48 PM Craig McQueen mailto:craig.mcqu...@innerrange.com>> wrote: I wrote: > I'm trying to make a recipe for python3-uvloop, using setuptools3. > > The Python 3 uvloop module depends on libuv. It bundles a version of libuv, > and setup.py tries to build it, but it doesn't work well for > cross-compilation. > However, it also provides a build_ext parameter "--use-system-libuv", which > seems to work when I try running it manually in devshell. (I have made a > suitable recipe for libuv and added libuv to DEPENDS.) > > How can I specify the "--use-system-libuv" parameter for build_ext in the > python3-uvloop recipe? I see a reference to DISTUTILS_BUILD_EXT_ARGS, > but it doesn't seem to be functional. I see DISTUTILS_BUILD_EXT_ARGS was submitted in this patch: https://patchwork.openembedded.org/patch/66071/ However, in the Yocto poky repository, I see commit 0221af0f4ee9e8bfb8796841bdf806e38bc600c6 which appears to be a broken version of the above patch with the separate build_ext step not actually executed with the DISTUTILS_BUILD_EXT_ARGS parameters. You did not explain broken in which sense ? It is broken in the sense that: The separate build_ext step is not actually executed with the DISTUTILS_BUILD_EXT_ARGS parameters. The original patch submission contained: STAGING_INCDIR=${STAGING_INCDIR} \ STAGING_LIBDIR=${STAGING_LIBDIR} \ BUILD_SYS=${BUILD_SYS} HOST_SYS=${HOST_SYS} \ - ${STAGING_BINDIR_NATIVE}/${PYTHON_PN}-native/${PYTHON_PN} setup.py build ${DISTUTILS_BUILD_ARGS} || \ + ${STAGING_BINDIR_NATIVE}/${PYTHON_PN}-native/${PYTHON_PN} setup.py \ + build_ext --include-dirs ${STAGING_INCDIR}/${PYTHON_DIR}${PYTHON_ABI} \ + --library-dirs ${STAGING_LIBCDIR}/${PYTHON_DIR} \ + ${DISTUTILS_BUILD_EXT_ARGS} \ + build ${DISTUTILS_BUILD_ARGS} || \ + ${STAGING_BINDIR_NATIVE}/${PYTHON_PN}-native/${PYTHON_PN} setup.py build_ext ${DISTUTILS_BUILD_ARGS} || \ bbfatal "${PYTHON_PN} setup.py build_ext execution failed." } However that part of the patch is not present in commit 0221af0f4ee9e8bfb8796841bdf806e38bc600c6. -- Craig McQueen -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Python module and build_ext args
On Thu, Aug 24, 2017 at 9:42 PM, Craig McQueen wrote: > Khem Raj wrote: > > > > On Thu, Aug 24, 2017 at 6:48 PM Craig McQueen > wrote: > > I wrote: >> I'm trying to make a recipe for python3-uvloop, using setuptools3. >> >> The Python 3 uvloop module depends on libuv. It bundles a version of >> libuv, >> and setup.py tries to build it, but it doesn't work well for >> cross-compilation. >> However, it also provides a build_ext parameter "--use-system-libuv", >> which >> seems to work when I try running it manually in devshell. (I have made a >> suitable recipe for libuv and added libuv to DEPENDS.) >> >> How can I specify the "--use-system-libuv" parameter for build_ext in the >> python3-uvloop recipe? I see a reference to DISTUTILS_BUILD_EXT_ARGS, >> but it doesn't seem to be functional. > > > I see DISTUTILS_BUILD_EXT_ARGS was submitted in this patch: > https://patchwork.openembedded.org/patch/66071/ > > However, in the Yocto poky repository, I see commit > 0221af0f4ee9e8bfb8796841bdf806e38bc600c6 which appears to be a broken > version of the above patch with the separate build_ext step not actually > executed with the DISTUTILS_BUILD_EXT_ARGS parameters. > > > > You did not explain broken in which sense ? > > > > It is broken in the sense that: The separate build_ext step is not actually > executed with the DISTUTILS_BUILD_EXT_ARGS parameters. The original patch > submission contained: > > > > STAGING_INCDIR=${STAGING_INCDIR} \ > > STAGING_LIBDIR=${STAGING_LIBDIR} \ > > BUILD_SYS=${BUILD_SYS} HOST_SYS=${HOST_SYS} \ > > - ${STAGING_BINDIR_NATIVE}/${PYTHON_PN}-native/${PYTHON_PN} setup.py > build ${DISTUTILS_BUILD_ARGS} || \ > > + ${STAGING_BINDIR_NATIVE}/${PYTHON_PN}-native/${PYTHON_PN} setup.py > \ > > + build_ext --include-dirs > ${STAGING_INCDIR}/${PYTHON_DIR}${PYTHON_ABI} \ > > + --library-dirs ${STAGING_LIBCDIR}/${PYTHON_DIR} \ > > + ${DISTUTILS_BUILD_EXT_ARGS} \ > > + build ${DISTUTILS_BUILD_ARGS} || \ > > + ${STAGING_BINDIR_NATIVE}/${PYTHON_PN}-native/${PYTHON_PN} setup.py > build_ext ${DISTUTILS_BUILD_ARGS} || \ > > bbfatal "${PYTHON_PN} setup.py build_ext execution failed." > > } > > > > However that part of the patch is not present in commit > 0221af0f4ee9e8bfb8796841bdf806e38bc600c6. > IIRC there were some breakages with this but it was long time ago. Can you appy this change and test it out ? -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [layerindex-web][PATCH v3] Asynchronous email notifications, task execution
This patch adds asynchronous task execution using a Celery backend and RabbitMQ task queue, so that the layer submission process to proceed even in the event that sending the notification email fails, and establishing an asynchronous execution mechanism that we can use in the future e.g. for triggering parse operations from the web UI. It updates the README to reflect the installation and configuration of a basic RabbitMQ setup, adds a 'tasks.py' file to contain task definitions, updates the 'edit_layer_view' function to send emails to administrators about new and updated layers asynchronously, and modifies the 'settings.py' to include a default configuration for a RabbitMQ connection. Signed-off-by: Diana Thayer --- README | 10 +- TODO| 1 - layerindex/tasks.py | 24 layerindex/views.py | 7 +++ requirements.txt| 1 + settings.py | 4 6 files changed, 41 insertions(+), 6 deletions(-) create mode 100644 layerindex/tasks.py diff --git a/README b/README index 62f739d..c7f7409 100644 --- a/README +++ b/README @@ -14,6 +14,7 @@ In order to make use of this application you will need: * Python 3.4+ * Django 1.8.x - tested with 1.8.17; newer versions may work, but the application has not been tested with 1.9 or newer. +* RabbitMQ 3.6.x - tested with 3.6.10. * For production usage, a web server set up to host Django applications (not needed for local-only testing) * A database supported by Django (SQLite, MySQL, etc.). Django takes @@ -41,7 +42,9 @@ Setup instructions: 1. Edit settings.py to specify a database, EMAIL_HOST, SECRET_KEY and other settings specific to your installation. Ensure you set LAYER_FETCH_DIR to an absolute path to a location with sufficient - space for fetching layer repositories. + space for fetching layer repositories. Modify RABBIT_BROKER + and RABBIT_BACKEND to reflect the settings used by your RabbitMQ + server. 2. Run the following commands within the layerindex-web directory to initialise the database: @@ -64,6 +67,11 @@ Setup instructions: production you need to use a proper web server and have DEBUG set to False. + 3.1. In order to process asynchronous tasks like sending email, +you will need to run a Celery worker: + +celery -A layerindex.tasks worker --loglevel=info + 4. You'll need to add at least the openembedded-core layer to the database, or some equivalent that contains conf/bitbake.conf for the base system configuration. To add this, follow these steps: diff --git a/TODO b/TODO index 186219f..29986ac 100644 --- a/TODO +++ b/TODO @@ -27,7 +27,6 @@ Other * Show layer type in layer detail? * Usage links in list page? * Subdirs in list page? -* Prevent SMTP failures from breaking submission process * Query backend service i.e. special URL to query information for external apps/scripts * Add comparison to duplicates page * Create simple script to check for unlisted layer subdirectories in all repos diff --git a/layerindex/tasks.py b/layerindex/tasks.py new file mode 100644 index 000..de80804 --- /dev/null +++ b/layerindex/tasks.py @@ -0,0 +1,24 @@ +from celery import Celery +from django.core.mail import EmailMessage +from . import utils +import os +import time + +try: +import settings +except ImportError: +# not in a full django env, so settings is inaccessible. +# setup django to access settings. +utils.setup_django() +import settings + +tasks = Celery('layerindex', +broker=settings.RABBIT_BROKER, +backend=settings.RABBIT_BACKEND) + +@tasks.task +def send_email(subject, text_content, from_email=settings.DEFAULT_FROM_EMAIL, to_emails=[]): +# We seem to need to run this within the task +utils.setup_django() +msg = EmailMessage(subject, text_content, from_email, to_emails) +msg.send() diff --git a/layerindex/views.py b/layerindex/views.py index 1661cb3..c582505 100644 --- a/layerindex/views.py +++ b/layerindex/views.py @@ -19,7 +19,6 @@ from layerindex.forms import EditLayerForm, LayerMaintainerFormSet, EditNoteForm from django.db import transaction from django.contrib.auth.models import User, Permission from django.db.models import Q, Count, Sum -from django.core.mail import EmailMessage from django.template.loader import get_template from django.template import Context from django.utils.decorators import method_decorator @@ -28,6 +27,7 @@ from django.contrib import messages from reversion.models import Revision from . import utils from . import simplesearch +from . import tasks import settings from django.dispatch import receiver import reversion @@ -163,7 +163,7 @@ def edit_layer_view(request, template_name, branch='master', slug=None): # Send email plaintext = get_template('layerindex/submitemail.txt') perm = Permission.objects.get(codename='publish_layer') -users =
Re: [yocto] RDEPENDS dependency problem
On Thu, Aug 24, 2017 at 1:41 AM, Stefano Pagnottelli wrote: > First of all, thanks for your reply. > > Il giorno mer 23 ago 2017 alle ore 20:56 Khem Raj ha > scritto: >> >> On 8/23/17 1:12 AM, Stefano Pagnottelli wrote: >> > Hi to all, >> > >> > I'm trying to build this layer: >> > (https://github.com/bachp/meta-homeassistant) using the yocto pyro on a >> > raspberry pi 3 target and the opkg package system. >> > >> > Inside the recipe >> > >> > (https://github.com/bachp/meta-homeassistant/blob/master/recipes-homeassistant/homeassistant/python3-homeassistant_0.51.2.bb) >> > there are some RDEPENDS with strict equal >> > dependencies (ex:python3-aiohttp (= 2.2.5)). >> > >> > We I build the image with the opgk package system the system fail in the >> > do_rootfs task because is not finding the package python3-aiohttp = >> > 2.2.5.. If I understood correctly this happens because the build system >> > si appending the recipe revision (PR variable) at end of package name >> > and the results is python3-aiohttp_2.2.5-r0 and not >> > python3-aiohttp_2.2.5 as opkg is expecting. >> >> I dont think r0 is in play here. You can test it by changing dependency >> check to look for (= for 2.2.5-r0), I think it should still fail. > > > I do some tests of on rdendps on the recipe: > > With python3-aiohttp (= 2.2.5-r0) the image is built without problems, with > python3-aiohttp (>= 2.2.5) the image is built without problems, with > python3-aiohttp (= 2.2.5) the task fail with the following error: > > Problem 1/1: > - nothing provides python3-aiohttp = 2.2.5 needed by > python3-homeassistant-0.51.2-r0.cortexa7hf-neon-vfpv4 > > So it seems to me that know the recipe revision is mandatory if you want to > put a strict dependency on a rdpends. But if I understood correctly the > yocto build system it's not possible to predict the recipe revision because > is automatically computed, And a change in the recipe will break the > dependency also if the source software version is the same because this will > change the recipe version. Yeah ok PV as well as PR both are considered. > >> >> >> > >> > As workaround I changed all strict = with a >= and the build complete >> > without errors. >> >> this is ok as long as the package can work with newer versions of this >> package. I am not sure if thats the case, you might have to check with >> authors intent for using = instead of >= > > > I think that ,in that case the author is using strict = dependencies because > we are trying to compile a python project that strictly depend python module > with a specific version. Can be useful to have strict = dependency in a > recipe but it is not mandatory, the project compile well also with >=. > > Regards > Stefano > >> >> >> > >> > My question is: It's possible to instruct the build system to ignore >> > the recipe revision when it match the version of the package? Or in >> > alternative it's possible to automatically detect the recipe revision of >> > the package? >> > >> > Thanks in advance >> > Stefano >> > … >> > -- >> > >> > There are 10 types of people in this world, those who understand binary >> > and those who dont >> > >> > >> > -- > > There are 10 types of people in this world, those who understand binary and > those who dont > > > -- > ___ > 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] [layerindex-web][PATCH v4] Asynchronous email notifications, task execution
This patch adds asynchronous task execution using a Celery backend and RabbitMQ task queue, so that the layer submission process to proceed even in the event that sending the notification email fails, and establishing an asynchronous execution mechanism that we can use in the future e.g. for triggering parse operations from the web UI. This pertains to bug 11195: https://bugzilla.yoctoproject.org/show_bug.cgi?id=11195 It updates the README to reflect the installation and configuration of a basic RabbitMQ setup, adds a 'tasks.py' file to contain task definitions, updates the 'edit_layer_view' function to send emails to administrators about new and updated layers asynchronously, and modifies the 'settings.py' to include a default configuration for a RabbitMQ connection. Signed-off-by: Diana Thayer --- README | 10 +- TODO| 1 - layerindex/tasks.py | 24 layerindex/views.py | 5 ++--- requirements.txt| 1 + settings.py | 4 6 files changed, 40 insertions(+), 5 deletions(-) create mode 100644 layerindex/tasks.py diff --git a/README b/README index 62f739d..c7f7409 100644 --- a/README +++ b/README @@ -14,6 +14,7 @@ In order to make use of this application you will need: * Python 3.4+ * Django 1.8.x - tested with 1.8.17; newer versions may work, but the application has not been tested with 1.9 or newer. +* RabbitMQ 3.6.x - tested with 3.6.10. * For production usage, a web server set up to host Django applications (not needed for local-only testing) * A database supported by Django (SQLite, MySQL, etc.). Django takes @@ -41,7 +42,9 @@ Setup instructions: 1. Edit settings.py to specify a database, EMAIL_HOST, SECRET_KEY and other settings specific to your installation. Ensure you set LAYER_FETCH_DIR to an absolute path to a location with sufficient - space for fetching layer repositories. + space for fetching layer repositories. Modify RABBIT_BROKER + and RABBIT_BACKEND to reflect the settings used by your RabbitMQ + server. 2. Run the following commands within the layerindex-web directory to initialise the database: @@ -64,6 +67,11 @@ Setup instructions: production you need to use a proper web server and have DEBUG set to False. + 3.1. In order to process asynchronous tasks like sending email, +you will need to run a Celery worker: + +celery -A layerindex.tasks worker --loglevel=info + 4. You'll need to add at least the openembedded-core layer to the database, or some equivalent that contains conf/bitbake.conf for the base system configuration. To add this, follow these steps: diff --git a/TODO b/TODO index 186219f..29986ac 100644 --- a/TODO +++ b/TODO @@ -27,7 +27,6 @@ Other * Show layer type in layer detail? * Usage links in list page? * Subdirs in list page? -* Prevent SMTP failures from breaking submission process * Query backend service i.e. special URL to query information for external apps/scripts * Add comparison to duplicates page * Create simple script to check for unlisted layer subdirectories in all repos diff --git a/layerindex/tasks.py b/layerindex/tasks.py new file mode 100644 index 000..de80804 --- /dev/null +++ b/layerindex/tasks.py @@ -0,0 +1,24 @@ +from celery import Celery +from django.core.mail import EmailMessage +from . import utils +import os +import time + +try: +import settings +except ImportError: +# not in a full django env, so settings is inaccessible. +# setup django to access settings. +utils.setup_django() +import settings + +tasks = Celery('layerindex', +broker=settings.RABBIT_BROKER, +backend=settings.RABBIT_BACKEND) + +@tasks.task +def send_email(subject, text_content, from_email=settings.DEFAULT_FROM_EMAIL, to_emails=[]): +# We seem to need to run this within the task +utils.setup_django() +msg = EmailMessage(subject, text_content, from_email, to_emails) +msg.send() diff --git a/layerindex/views.py b/layerindex/views.py index 1661cb3..bcf6671 100644 --- a/layerindex/views.py +++ b/layerindex/views.py @@ -19,7 +19,6 @@ from layerindex.forms import EditLayerForm, LayerMaintainerFormSet, EditNoteForm from django.db import transaction from django.contrib.auth.models import User, Permission from django.db.models import Q, Count, Sum -from django.core.mail import EmailMessage from django.template.loader import get_template from django.template import Context from django.utils.decorators import method_decorator @@ -28,6 +27,7 @@ from django.contrib import messages from reversion.models import Revision from . import utils from . import simplesearch +from . import tasks import settings from django.dispatch import receiver import reversion @@ -181,8 +181,7 @@ def edit_layer_view(request, template_name, branch='master', slug=None): from_email = settings.SUBMIT_EMAIL_FROM to_email = user.email
[yocto] [layerindex-web][PATCH] views : add check for superusers in layer update notifications
When a user submits a layer, notification emails are sent to users with a certain permission. Superusers technically have all permissions, but Q ignores them currently so that such emails are not sent to superusers. This patch expands the check to include superusers. A few folks have discussed including this so I put this patch up for consideration. --- layerindex/views.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/layerindex/views.py b/layerindex/views.py index 1661cb3..c1a624c 100644 --- a/layerindex/views.py +++ b/layerindex/views.py @@ -163,7 +163,7 @@ def edit_layer_view(request, template_name, branch='master', slug=None): # Send email plaintext = get_template('layerindex/submitemail.txt') perm = Permission.objects.get(codename='publish_layer') -users = User.objects.filter(Q(groups__permissions=perm) | Q(user_permissions=perm) ).distinct() +users = User.objects.filter(Q(groups__permissions=perm) | Q(user_permissions=perm) | Q(is_superuser=True) ).distinct() for user in users: if user.first_name: user_name = user.first_name -- 2.7.4 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto