Date   

Re: [meta-raspberrypi] Problem with RPI_USE_U_BOOT with RaspberryPi4

Marc Ferland
 

On Fri, Jan 14, 2022 at 10:39 AM Jean-Philippe Lebel <jp@...> wrote:

I finally received my UART cable, giving me more details about where the boot sequence fails.

Just a quick summary of my tests
- Enabling UART does indeed "fix" the issue when working from the meta-raspberrypi AND yocto master.
- Enabling UART has no impact when working from the meta-raspberrypi and yocto hardknott branch (which I need to support) - image doesn't boot
- Backporting the meta-raspberrypi master branch to hardknott does NOT fix the problem.

Here is the uboot log (failing).

U-Boot 2021.01 (Jan 11 2021 - 18:11:43 +0000)

DRAM: 1.9 GiB
RPI 4 Model B (0xb03114)
MMC: mmcnr@7e300000: 1, emmc2@7e340000: 0
Loading Environment from FAT... ** No partition table - mmc 0 **
In: serial
Out: serial
Err: serial
Net: eth0: ethernet@7d580000
PCIe BRCM: link up, 5.0 Gbps x1 (SSC)
starting USB...
Bus xhci_pci: Register 5000420 NbrPorts 5
Starting the controller
USB XHCI 1.00
scanning bus xhci_pci for devices... 2 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot: 0
switch to partitions #0, OK
mmc0 is current device
** No partition table - mmc 0 **
Card did not respond to voltage select! : -110

Here is a normal uboot sequence

U-Boot 2021.10 (Oct 04 2021 - 15:09:26 +0000)

DRAM: 1.9 GiB
RPI 4 Model B (0xb03114)
MMC: mmcnr@7e300000: 1, mmc@7e340000: 0
Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1... In: serial
Out: vidconsole
Err: vidconsole
Net: eth0: ethernet@7d580000
PCIe BRCM: link up, 5.0 Gbps x1 (SSC)
starting USB...
Bus xhci_pci: Register 5000420 NbrPorts 5
Starting the controller
USB XHCI 1.00
scanning bus xhci_pci for devices... 2 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot: 0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
262 bytes read in 6 ms (42 KiB/s)
## Executing script at 02400000
23202304 bytes read in 997 ms (22.2 MiB/s)
Saving Environment to FAT... OK
Moving Image from 0x80000 to 0x200000, end=1960000
## Flattened Device Tree blob at 2eff3600
Booting using the fdt blob at 0x2eff3600
Using Device Tree in place at 000000002eff3600, end 000000002f002f13

Starting kernel ...

Basically, the failing Uboot can't find the partition table.
Well is there a partition table? Can you share what you are doing to
flash your uSD? Maybe it's just some manipulation error.

Marc


Re: perf compilation fails

Khem Raj
 

take a look at following link, it will help solve this hopefully

https://wiki.gentoo.org/wiki/Project:Toolchain/Binutils_2.34_porting_notes/undefined_reference_to_bfd_get_section_*

On Fri, Jan 14, 2022 at 2:02 AM Michael Opdenacker
<michael.opdenacker@...> wrote:

Hi Jose Antonio

On 1/13/22 3:29 PM, Cardenas Jose Antonio (JCARDENA) wrote:

Hi guys



I’m no table to build correctly perf package.



It looks like some sources have no been compiled because I’m getting
an “undefined reference to” error.



This problem has appeared since we have upgraded the version of yocto
zeus.



I’m getting this error



arm-poky-linux-gnueabi-ld
--sysroot=/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/recipe-sysroot
-r -o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/perf-in.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-bench.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-annotate.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-config.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-diff.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-evlist.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-ftrace.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-help.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-sched.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-buildid-list.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-buildid-cache.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-kallsyms.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-list.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-record.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-report.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-stat.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-timechart.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-top.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-script.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-kmem.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-lock.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-kvm.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-inject.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-mem.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-data.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-version.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-c2c.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-probe.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/bench/perf-in.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/tests/perf-in.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/perf.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/util/perf-in.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/arch/perf-in.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/ui/perf-in.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/scripts/perf-in.o

arm-poky-linux-gnueabi-gcc -march=armv7-a -mfpu=neon -mfloat-abi=hard
-fstack-protector-strong -D_FORTIFY_SOURCE=2 -Wformat
-Wformat-security -Werror=format-security -Os -pipe -g
-feliminate-unused-debug-types
-fmacro-prefix-map=/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9=/usr/src/debug/perf/1.0-r9
-fdebug-prefix-map=/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9=/usr/src/debug/perf/1.0-r9
-fdebug-prefix-map=/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/recipe-sysroot=
-fdebug-prefix-map=/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/recipe-sysroot-native=
--sysroot=/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/recipe-sysroot
-ldw -Wbad-function-cast -Wdeclaration-after-statement
-Wformat-security -Wformat-y2k -Winit-self -Wmissing-declarations
-Wmissing-prototypes -Wnested-externs -Wno-system-headers
-Wold-style-definition -Wpacked -Wredundant-decls -Wstrict-prototypes
-Wswitch-default -Wswitch-enum -Wundef -Wwrite-strings -Wformat
-Wstrict-aliasing=3 -Wshadow -DHAVE_PERF_REGS_SUPPORT -O6
-fno-omit-frame-pointer -ggdb3 -funwind-tables -Wall -Wextra
-std=gnu99 -fstack-protector-all -D_FORTIFY_SOURCE=2
-I/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/tools/perf/util/include
-I/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/tools/perf/arch/arm/include
-I/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/tools/include/uapi
-I/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/tools/include/
-I/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/tools/arch/arm/include/uapi
-I/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/tools/arch/arm/include/
-I/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/tools/arch/arm/
-I/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0//util
-I/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/
-I/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/tools/perf/util
-I/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/tools/perf
-I/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/tools/lib/
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE
-DHAVE_SYNC_COMPARE_AND_SWAP_SUPPORT
-DHAVE_PTHREAD_ATTR_SETAFFINITY_NP -DHAVE_PTHREAD_BARRIER
-DHAVE_EVENTFD -DHAVE_GET_CURRENT_DIR_NAME -DHAVE_GETTID
-DHAVE_DWARF_GETLOCATIONS_SUPPORT -DHAVE_GLIBC_SUPPORT
-DHAVE_AIO_SUPPORT -DHAVE_SCHED_GETCPU_SUPPORT -DHAVE_SETNS_SUPPORT
-DHAVE_LIBELF_SUPPORT -DHAVE_LIBELF_MMAP_SUPPORT
-DHAVE_ELF_GETPHDRNUM_SUPPORT -DHAVE_GELF_GETNOTE_SUPPORT
-DHAVE_ELF_GETSHDRSTRNDX_SUPPORT -DHAVE_LIBBPF_SUPPORT -DHAVE_JITDUMP
-DHAVE_DWARF_UNWIND_SUPPORT -DHAVE_LIBUNWIND_SUPPORT
-I/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/recipe-sysroot/usr/include
-DHAVE_LIBCRYPTO_SUPPORT -DHAVE_SLANG_SUPPORT -DNO_LIBPERL
-DHAVE_TIMERFD_SUPPORT -DNO_LIBPYTHON -DHAVE_CPLUS_DEMANGLE_SUPPORT
-DHAVE_LIBBFD_SUPPORT -DHAVE_ZLIB_SUPPORT -DHAVE_LZMA_SUPPORT
-DHAVE_BACKTRACE_SUPPORT -DDISASM_FOUR_ARGS_SIGNATURE
-DHAVE_AUXTRACE_SUPPORT
-I/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/
-ldl -lutil -Wl,-z,noexecstack -lunwind -lunwind-arm
-L/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/recipe-sysroot/usr/lib
-Xlinker
--dynamic-list=/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/libtraceevent-dynamic-list
\


/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/perf-in.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/pmu-events/pmu-events-in.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/libperf-in.o
-Wl,--whole-archive
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/libapi.a
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/libtraceevent.a
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/libsubcmd.a
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/libbpf.a
-Wl,--no-whole-archive -Wl,--start-group -lpthread -lrt -lm -ldl -lelf
-lunwind -lunwind-arm -lcrypto -lslang -lbfd -lopcodes -liberty -lz
-llzma -Wl,--end-group -o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/perf

/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi/../../libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/9.3.0/ld:
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/perf-in.o:
in function `find_address_in_section':

/usr/src/debug/perf/1.0-r9/perf-1.0/tools/perf/util/srcline.c:200:
undefined reference to `bfd_get_section_flags'

/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi/../../libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/9.3.0/ld:
/usr/src/debug/perf/1.0-r9/perf-1.0/tools/perf/util/srcline.c:204:
undefined reference to `bfd_get_section_vma'

/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi/../../libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/9.3.0/ld:
/usr/src/debug/perf/1.0-r9/perf-1.0/tools/perf/util/srcline.c:205:
undefined reference to `bfd_get_section_size'

collect2: error: ld returned 1 exit status

make[2]: *** [Makefile.perf:608:
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/perf]
Error 1

make[1]: *** [Makefile.perf:219: sub-make] Error 2

make: *** [Makefile:70: all] Error 2

make: Leaving directory
'/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/tools/perf'

ERROR: oe_runmake failed

WARNING:
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/temp/run.do_compile.146045:1
exit 1 from 'exit 1'

ERROR: Execution of
'/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/temp/run.do_compile.146045'
failed with exit code 1
Weird, this doesn't happen building core-image-minimal *for x86_64* on
the latest Poky, with gcc 11.2.
This may not help much, but at least you could compare.
Cheers
Michael.

--
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com




Re: Red alert but apparently harmless setscene errors

Michael Opdenacker
 

On 1/13/22 10:53 PM, Richard Purdie wrote:
On Thu, 2022-01-13 at 19:37 +0100, Michael Opdenacker wrote:
Hi Jose,

Thanks for your advice!

On 1/13/22 6:37 PM, Jose Quaresma wrote:
Hi,

I've seen the same for some time now when building core-image-minimal
with yocto state mirror and hashequiv servers.

After some investigation I think the root cause is some
bandwidth/connection limitation on the http yocto mirror.

Reducing the BB_NUMBER_THREADS="1" to a single core solves many of the
fetch issues for me,
my config is the default one with:

  BB_NUMBER_THREADS="1"
  SSTATE_MIRRORS = "file://.*
http://sstate.yoctoproject.org/dev/PATH;downloadfilename=PATH
<http://sstate.yoctoproject.org/dev/PATH;downloadfilename=PATH>"
  BB_HASHSERVE_UPSTREAM = "typhoon.yocto.io:8687
<http://typhoon.yocto.io:8687>"
Oops, it seems you're right. I have the same SSTATE_MIRRORS and
BB_HASHSERVE_UPSTREAM settings as you do, and adding
BB_NUMBER_THREADS="1" makes the errors disappear.

It seems I should file a bug about that. The error messages just mention
local paths, not remote ones, so it sounds like a local issue while it's
apparently not.
That is useful to debug it but suggests there is an issue with concurrent
connections to the YP server.

I think we should have an open bug and get Michael Halstead's input on this.

Done: https://bugzilla.yoctoproject.org/show_bug.cgi?id=14690
Thanks for your advice.
Cheers
Michael.

--
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


Re: [OE-core] Question of Yocto dunfell LTS period

Ross Burton <ross@...>
 

On Fri, 14 Jan 2022 at 12:41, Zoltan Boszormenyi via
lists.yoctoproject.org <zboszor=pr.hu@...> wrote:
It would also help if recipes staying on the same version
but adding patches for e.g. CVE fixes should increase their
PR value so their rebuilt versions can be put into a package repo.

Throwing away the buildroot (as suggested any time some obscure
build error happens) and restarting a complete image build
resets the autopr value so the repo would contain packages with
the same r0.0 release string and the package manager doesn't know
that the package is newer.
If you want persistent PRs between builds after deleting the build
tree, simply archive the PR database.

We're not going back to manually updating the PR on changes.

Ross


Re: [meta-raspberrypi] Problem with RPI_USE_U_BOOT with RaspberryPi4

Jean-Philippe Lebel
 

I finally received my UART cable, giving me more details about where the boot sequence fails.

Just a quick summary of my tests
- Enabling UART does indeed "fix" the issue when working from the meta-raspberrypi AND yocto master.
- Enabling UART has no impact when working from the meta-raspberrypi and yocto hardknott branch (which I need to support) - image doesn't boot
- Backporting the meta-raspberrypi master branch to hardknott does NOT fix the problem.

Here is the uboot log (failing).

U-Boot 2021.01 (Jan 11 2021 - 18:11:43 +0000)

DRAM:  1.9 GiB
RPI 4 Model B (0xb03114)
MMC:   mmcnr@7e300000: 1, emmc2@7e340000: 0
Loading Environment from FAT... ** No partition table - mmc 0 **
In:    serial
Out:   serial
Err:   serial
Net:   eth0: ethernet@7d580000
PCIe BRCM: link up, 5.0 Gbps x1 (SSC)
starting USB...
Bus xhci_pci: Register 5000420 NbrPorts 5
Starting the controller
USB XHCI 1.00
scanning bus xhci_pci for devices... 2 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0 is current device
** No partition table - mmc 0 **
Card did not respond to voltage select! : -110

Here is a normal uboot sequence

U-Boot 2021.10 (Oct 04 2021 - 15:09:26 +0000)

DRAM:  1.9 GiB
RPI 4 Model B (0xb03114)
MMC:   mmcnr@7e300000: 1, mmc@7e340000: 0
Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1... In:    serial
Out:   vidconsole
Err:   vidconsole
Net:   eth0: ethernet@7d580000
PCIe BRCM: link up, 5.0 Gbps x1 (SSC)
starting USB...
Bus xhci_pci: Register 5000420 NbrPorts 5
Starting the controller
USB XHCI 1.00
scanning bus xhci_pci for devices... 2 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
262 bytes read in 6 ms (42 KiB/s)
## Executing script at 02400000
23202304 bytes read in 997 ms (22.2 MiB/s)
Saving Environment to FAT... OK
Moving Image from 0x80000 to 0x200000, end=1960000
## Flattened Device Tree blob at 2eff3600
   Booting using the fdt blob at 0x2eff3600
   Using Device Tree in place at 000000002eff3600, end 000000002f002f13

Starting kernel ...

Basically, the failing Uboot can't find the partition table.

Any idea why?

Thanks

-------------
Jean-Philippe Lebel, ing. MBA

AVIS IMPORTANT: Ce courriel est strictement réservé à l'usage de la (des) personne(s) à qui il est adressé et peut contenir de l'information privilégiée et confidentielle. Toute divulgation, distribution, copie, ou autre utilisation de ce courriel par une autre personne est strictement prohibée. Si vous avez reçu ce courriel par erreur, veuillez s'il vous plaît communiquer immédiatement avec l'expéditeur et détruire le courriel sans en faire de copie sous quelque forme.

WARNING: This e-mail contains confidential information intended only for the person(s) named above. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution, or any other use of this e-mail is strictly prohibited. If you have received this e-mail by mistake, please notify us immediately and destroy this e-mail without making any copy of any kind.


On Wed, Jan 12, 2022 at 4:45 PM Jerome Oufella <jerome.oufella@...> wrote:
On Jan 12, 2022, at 3:37 PM, Jean-Philippe Lebel wrote:

> For a reason I can't quite understand, everything stated working when I added
> ENABLE_UART = "1"
>
> Does anyone understand the relation between ENABLE_UART = "1" and RPI_USE_U_BOOT
> = "1" ?
>
> Thanks
>
> -------------
> Jean-Philippe

The documentation mentions a relationship between enable_uart and
(lower) core frequency on some hardware variants - could there be a
side-effect (if yes, maybe gpu_freq/arm_freq could play a factor) ?

Jerome


Re: Question of Yocto dunfell LTS period

Richard Purdie
 

On Fri, 2022-01-14 at 07:14 +0000, Matthias Klein wrote:
Hello together,

I would like to add a question to the topic:

Why was the LTS period for dunfell extended?
Can we expect the same for kirstone?
The project members agreed to fun an extension to the lifetime of dunfell from 2
years to 4 years. There should have been some announcements about this but we
lack people on the advocacy side of the project with time to make that happen.
That saddens me a lot and I think it is a missed opportunity but there isn't
much I can do about it beyond what I've already tried.

Extending Dunfell is an experiment so we would base a decision on how well the
dunfell extension is working out. Extending an LTS like this requires a
financial commitment from the project. At this point in time the project cannot
commit to extending kirkstone as we can't guarantee the finances.

Cheers,

Richard


Re: [OE-core] Question of Yocto dunfell LTS period

Zoltan Boszormenyi <zboszor@...>
 

Funny you mention PR.

It would also help if recipes staying on the same version
but adding patches for e.g. CVE fixes should increase their
PR value so their rebuilt versions can be put into a package repo.

Throwing away the buildroot (as suggested any time some obscure
build error happens) and restarting a complete image build
resets the autopr value so the repo would contain packages with
the same r0.0 release string and the package manager doesn't know
that the package is newer.

2022. 01. 14. 10:42 keltezéssel, Alexander Kanavin írta:

Actually, I think this was some kind of missed PR opportunity. Regular distros, such as RHEL, Debian and everyone else, are constantly trotting out their support windows as the reason to hand them the job of making products, so we could counter that better perhaps.
Alex
On Fri, 14 Jan 2022 at 06:28, Michael Opdenacker <michael.opdenacker@... <mailto:michael.opdenacker@...>> wrote:
On 1/14/22 2:36 AM, Jate Sujjavanich wrote:
> I received the answer to this question in IRC on 10/29/2021.
>
> 16:06
> <https://libera.irclog.whitequark.org/yocto/2021-10-29#31083490
<https://libera.irclog.whitequark.org/yocto/2021-10-29#31083490>> <jatedev>
> I saw a wiki edit that said dunfell's LTS period is now through April
> 2024, but I've seen no announcements. Any truth to this rumor?
> 16:20
> <https://libera.irclog.whitequark.org/yocto/2021-10-29#31083555
<https://libera.irclog.whitequark.org/yocto/2021-10-29#31083555>> <smurray>
> jatedev: it was announced on one of the technical calls a few weeks
> back, so yes AFAIK
> 16:25
> <https://libera.irclog.whitequark.org/yocto/2021-10-29#31083577
<https://libera.irclog.whitequark.org/yocto/2021-10-29#31083577>> <RP>
> jatedev: definitely true. I wish we could sort out the project
> advocacy side of things :(
>
> Let this email serve as a little advocacy.
I believe this would also help if the website (releases page) and/or
official documentation carried such information.
Thanks for raising this concern!
Cheers
Michael.
--
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com <https://bootlin.com>


Re: [meta-zephyr][PATCH v3] meta-zephyr-bsp: Add autogenerated machines.

Eilís Ní Fhlannagáin
 

On Thu, 13 Jan 2022 at 23:17, Jon Mason <jdmason@...> wrote:

On Wed, Jan 12, 2022 at 8:02 PM Eilís Ní Fhlannagáin <pidge@...> wrote:

From: Eilís Ní Fhlannagáin <elizabeth.flanagan@...>

This commit adds 382 autogenerated machines generated via
generate-zephyr-machines.bb. These machines have obviously not all been
tested due to hardware access, but should work out of box.

Signed-off-by: Eilís Ní Fhlannagáin <elizabeth.flanagan@...>
I'm still seeing errors:
TUNE_ARCH is unset. Please ensure your MACHINE configuration includes
a valid tune configuration file which will set this correctly.
Error, the PACKAGE_ARCHS variable (all any noarch
${PACKAGE_EXTRA_ARCHS:tune-${DEFAULTTUNE}} v2m_musca_s1) for
DEFAULTTUNE (None) does not contain TUNE_PKGARCH ().Toolchain tunings
invalid:
No tuning found for default multilib.
Yes. Some numbers on this after my poor laptop thrashed around on this
for a bit.

395 boards in zephyr 2.7.1
391 boards autogenerated via this patch
299 (including the original 8 in meta-zephyr) that can build zephyr-helloworld.

Compiling is taking forever, given the number of boards (and other
reasons). So, I can't give an exhaustively confirmed list, but a
lazy grep of files without "require" shows 70 of them.
Yes. Not a surprise on some of these. This patch tries to find the
needed tune and sometimes just can't for various reasons.


$ git grep -L require meta-zephyr-bsp/conf/machine/
meta-zephyr-bsp/conf/machine/adp-xc7k-ae350.conf
meta-zephyr-bsp/conf/machine/altera-max10.conf
meta-zephyr-bsp/conf/machine/beaglev-starlight-jh7100.conf
meta-zephyr-bsp/conf/machine/bl5340-dvk-cpunet.conf
meta-zephyr-bsp/conf/machine/em-starterkit-em11d.conf
meta-zephyr-bsp/conf/machine/em-starterkit-em7d-v22.conf
meta-zephyr-bsp/conf/machine/em-starterkit-em7d.conf
meta-zephyr-bsp/conf/machine/em-starterkit.conf
meta-zephyr-bsp/conf/machine/emsdp-em4.conf
meta-zephyr-bsp/conf/machine/emsdp-em5d.conf
meta-zephyr-bsp/conf/machine/emsdp-em6.conf
meta-zephyr-bsp/conf/machine/emsdp-em7d-esp.conf
meta-zephyr-bsp/conf/machine/emsdp-em7d.conf
meta-zephyr-bsp/conf/machine/emsdp-em9d.conf
meta-zephyr-bsp/conf/machine/emsdp.conf
meta-zephyr-bsp/conf/machine/esp32c3-devkitm.conf
meta-zephyr-bsp/conf/machine/generic-leon3.conf
meta-zephyr-bsp/conf/machine/gr716a-mini.conf
meta-zephyr-bsp/conf/machine/hifive-unleashed.conf
meta-zephyr-bsp/conf/machine/hifive-unmatched.conf
meta-zephyr-bsp/conf/machine/hifive1-revb.conf
meta-zephyr-bsp/conf/machine/hifive1.conf
meta-zephyr-bsp/conf/machine/hsdk-2cores.conf
meta-zephyr-bsp/conf/machine/hsdk.conf
meta-zephyr-bsp/conf/machine/include/tune-arc.inc
meta-zephyr-bsp/conf/machine/include/tune-iamcu.inc
meta-zephyr-bsp/conf/machine/include/tune-nios2.inc
meta-zephyr-bsp/conf/machine/intel-adsp-cavs15.conf
meta-zephyr-bsp/conf/machine/intel-adsp-cavs18.conf
<snips>
meta-zephyr-bsp/conf/machine/v2m-musca-b1.conf
meta-zephyr-bsp/conf/machine/v2m-musca-s1-ns.conf
meta-zephyr-bsp/conf/machine/v2m-musca-s1.conf
meta-zephyr-bsp/conf/machine/xt-sim-intel-s1000.conf
meta-zephyr-bsp/conf/machine/xt-sim.conf

Arm does care about the v2m boards, and we have a version of them in
meta-arm-bsp. So, I'm not being difficult for no reason. :)
No, please. Be difficult, Jon. This is a radical change and needs a
bit of review. I think maybe one solution here is (outside of making
the search for tunes a bit better which will never be perfect as from
an OE context as layers with a specific tune may not exist):

- Run this pointing MACHINE_TUNINGS at the meta-arm-bsp layer and a
few different layers. Or alternately, remove configs that exist in
other layers.
- Run a build on each machine generated to see if it passes helloworld
- Remove any broken machines that don't pass that smoke test.

Again, I'm very open to suggestions here. Outside the additional
machines however, the one thing this patch series does give us is
getting rid of MACHINEOVERRIDES for ZEPHYR_MODULES and lets west just
figure this out.

-b


Thanks,
Jon


Re: [meta-tensorflow][PATCH 3/3] tensorflow-lite: add recipe

Julien STEPHAN
 

Hi Hongxu

Did you have a chance to take a look at it?

Best
Julien


Le ven. 24 déc. 2021 à 19:48, Randy MacLeod <randy.macleod@...> a écrit :
Thanks Stephan.

Hongxu, did you miss this?

../Randy

On 2021-12-21 3:42 a.m., Julien STEPHAN wrote:
> Adding 2.6.1 tensorflow-lite recipe.
> This recipe is directly based on the corresponding 2.6.1 tensorflow
> recipe.
>
> It has been build tested with latest honister and tested on
> several mediatek soc using benchmark_model and label_image (C++ and
> python)
>
> Signed-off-by: Julien STEPHAN <jstephan@...>
> ---
>   .../tensorflow/tensorflow-lite_2.6.1.bb       | 156 ++++++++++++++++++
>   1 file changed, 156 insertions(+)
>   create mode 100644 recipes-framework/tensorflow/tensorflow-lite_2.6.1.bb
>
> diff --git a/recipes-framework/tensorflow/tensorflow-lite_2.6.1.bb b/recipes-framework/tensorflow/tensorflow-lite_2.6.1.bb
> new file mode 100644
> index 0000000..104e5a3
> --- /dev/null
> +++ b/recipes-framework/tensorflow/tensorflow-lite_2.6.1.bb
> @@ -0,0 +1,156 @@
> +include tensorflow.inc
> +
> +SRC_URI += " \
> +           file://0001-add-yocto-toolchain-to-support-cross-compiling.patch \
> +           file://0001-fix-build-tensorflow-lite-examples-label_image-label.patch \
> +           file://0001-label_image-tweak-default-model-location.patch \
> +           file://0001-label_image.lite-tweak-default-model-location.patch \
> +           file://0001-CheckFeatureOrDie-use-warning-to-avoid-die.patch \
> +           file://0001-support-32-bit-x64-and-arm-for-yocto.patch \
> +           file://0001-Revert-set-distinct_host_configuration-false-by-defa.patch \
> +           file://0001-fix-default-Bazel-toolchain-not-work.patch \
> +           file://0001-distutils-is-deprecated-in-Python-3.10-cross.patch \
> +           file://BUILD.in \
> +           file://BUILD.yocto_compiler \
> +           file://cc_config.bzl.tpl \
> +           file://yocto_compiler_configure.bzl \
> +          "
> +
> +SRC_URI += "https://storage.googleapis.com/download.tensorflow.org/models/inception_v3_2016_08_28_frozen.pb.tar.gz;name=model-inv3"
> +SRC_URI[model-inv3.md5sum] = "a904ddf15593d03c7dd786d552e22d73"
> +SRC_URI[model-inv3.sha256sum] = "7045b72a954af4dce36346f478610acdccbf149168fa25c78e54e32f0c723d6d"
> +
> +SRC_URI += "https://storage.googleapis.com/download.tensorflow.org/models/tflite/mobilenet_v1_1.0_224_quant_and_labels.zip;name=model-mobv1"
> +SRC_URI[model-mobv1.md5sum] = "38ac0c626947875bd311ef96c8baab62"
> +SRC_URI[model-mobv1.sha256sum] = "2f8054076cf655e1a73778a49bd8fd0306d32b290b7e576dda9574f00f186c0f"
> +
> +RDEPENDS:${PN} += " \
> +    python3 \
> +    python3-core \
> +    python3-numpy \
> +"
> +
> +export PYTHON_BIN_PATH="${PYTHON}"
> +export PYTHON_LIB_PATH="${STAGING_LIBDIR_NATIVE}/${PYTHON_DIR}/site-packages"
> +
> +export CROSSTOOL_PYTHON_INCLUDE_PATH="${STAGING_INCDIR}/python${PYTHON_BASEVERSION}${PYTHON_ABI}"
> +
> +do_configure:append () {
> +    if [ ! -e ${CROSSTOOL_PYTHON_INCLUDE_PATH}/pyconfig-target.h ];then
> +        mv ${CROSSTOOL_PYTHON_INCLUDE_PATH}/pyconfig.h ${CROSSTOOL_PYTHON_INCLUDE_PATH}/pyconfig-target.h
> +    fi
> +
> +    install -m 644 ${STAGING_INCDIR_NATIVE}/python${PYTHON_BASEVERSION}${PYTHON_ABI}/pyconfig.h \
> +       ${CROSSTOOL_PYTHON_INCLUDE_PATH}/pyconfig-native.h
> +
> +    cat > ${CROSSTOOL_PYTHON_INCLUDE_PATH}/pyconfig.h <<ENDOF
> +#if defined (_PYTHON_INCLUDE_TARGET)
> +#include "pyconfig-target.h"
> +#elif defined (_PYTHON_INCLUDE_NATIVE)
> +#include "pyconfig-native.h"
> +#else
> +#error "_PYTHON_INCLUDE_TARGET or _PYTHON_INCLUDE_NATIVE is not defined"
> +#endif // End of #if defined (_PYTHON_INCLUDE_TARGET)
> +
> +ENDOF
> +
> +    mkdir -p ${S}/third_party/toolchains/yocto/
> +    sed "s#%%CPU%%#${BAZEL_TARGET_CPU}#g" ${WORKDIR}/BUILD.in  > ${S}/third_party/toolchains/yocto/BUILD
> +    chmod 644 ${S}/third_party/toolchains/yocto/BUILD
> +    install -m 644 ${WORKDIR}/cc_config.bzl.tpl ${S}/third_party/toolchains/yocto/
> +    install -m 644 ${WORKDIR}/yocto_compiler_configure.bzl ${S}/third_party/toolchains/yocto/
> +    install -m 644 ${WORKDIR}/BUILD.yocto_compiler ${S}
> +
> +    CT_NAME=$(echo ${HOST_PREFIX} | rev | cut -c 2- | rev)
> +    SED_COMMAND="s#%%CT_NAME%%#${CT_NAME}#g"
> +    SED_COMMAND="${SED_COMMAND}; s#%%WORKDIR%%#${WORKDIR}#g"
> +    SED_COMMAND="${SED_COMMAND}; s#%%YOCTO_COMPILER_PATH%%#${BAZEL_OUTPUTBASE_DIR}/external/yocto_compiler#g"
> +
> +    sed -i "${SED_COMMAND}" ${S}/BUILD.yocto_compiler \
> +                            ${S}/WORKSPACE
> +
> +    ${TF_CONFIG} \
> +    ./configure
> +}
> +
> +TF_TARGET_EXTRA ??= ""
> +
> +export CUSTOM_BAZEL_FLAGS = " \
> +    ${TF_ARGS_EXTRA} \
> +    --jobs=auto \
> +    -c opt \
> +    --cpu=${BAZEL_TARGET_CPU} \
> +    --crosstool_top=@local_config_yocto_compiler//:toolchain \
> +    --host_crosstool_top=@bazel_tools//tools/cpp:toolchain \
> +"
> +
> +do_compile () {
> +    export CT_NAME=$(echo ${HOST_PREFIX} | rev | cut -c 2- | rev)
> +    unset CC
> +
> +    ${BAZEL} build \
> +        ${CUSTOM_BAZEL_FLAGS} \
> +        --copt -DTF_LITE_DISABLE_X86_NEON --copt -DMESA_EGL_NO_X11_HEADERS \
> +        tensorflow/lite:libtensorflowlite.so \
> +        tensorflow/lite/tools/benchmark:benchmark_model \
> +        //tensorflow/lite/examples/label_image:label_image \
> +        ${TF_TARGET_EXTRA}
> +
> +    # build pip package
> +    ${S}/tensorflow/lite/tools/pip_package/build_pip_package_with_bazel.sh
> +
> +}
> +
> +do_install() {
> +    install -d ${D}${libdir}
> +    install -m 644 ${S}/bazel-bin/tensorflow/lite/libtensorflowlite.so \
> +        ${D}${libdir}
> +
> +    install -d ${D}${sbindir}
> +    install -m 755 ${S}/bazel-bin/tensorflow/lite/tools/benchmark/benchmark_model \
> +        ${D}${sbindir}
> +
> +    install -m 755 ${S}/bazel-bin/tensorflow/lite/examples/label_image/label_image \
> +        ${D}${sbindir}/label_image
> +
> +    install -d ${D}${datadir}/label_image
> +    install -m 644 ${WORKDIR}/imagenet_slim_labels.txt ${D}${datadir}/label_image
> +    install -m 644 ${WORKDIR}/inception_v3_2016_08_28_frozen.pb \
> +        ${D}${datadir}/label_image
> +    install -m 644 ${S}/tensorflow/examples/label_image/data/grace_hopper.jpg \
> +        ${D}${datadir}/label_image
> +
> +    install -m 644 ${WORKDIR}/labels_mobilenet_quant_v1_224.txt ${D}${datadir}/label_image
> +    install -m 644 ${WORKDIR}/mobilenet_v1_1.0_224_quant.tflite \
> +        ${D}${datadir}/label_image
> +    install -m 644 ${S}/tensorflow/lite/examples/label_image/testdata/grace_hopper.bmp \
> +        ${D}${datadir}/label_image
> +
> +
> +    #echo "Installing pip package"
> +    install -d ${D}/${PYTHON_SITEPACKAGES_DIR}
> +    ${STAGING_BINDIR_NATIVE}/pip3 install --disable-pip-version-check -v \
> +        -t ${D}/${PYTHON_SITEPACKAGES_DIR} --no-cache-dir --no-deps \
> +        ${S}/tensorflow/lite/tools/pip_package/gen/tflite_pip/python3/dist/tflite_runtime-${PV}-*.whl
> +
> +}
> +
> +FILES:${PN} += "${libdir} ${sbindir} ${datadir}/*"
> +INSANE_SKIP:${PN} += "dev-so \
> +                      already-stripped \
> +                     "
> +
> +SOLIBS = ".so"
> +FILES_SOLIBSDEV = ""
> +ALLOW_EMPTY:${PN} = "1"
> +
> +FILES:${PN} += "${libdir} /home/root/*"
> +
> +inherit siteinfo unsupportarch
> +python __anonymous() {
> +    if d.getVar("SITEINFO_ENDIANNESS") == 'be':
> +        msg =  "\nIt failed to use pre-build model to do predict/inference on big-endian platform"
> +        msg += "\n(such as qemumips), since upstream does not support big-endian very well."
> +        msg += "\nDetails: https://github.com/tensorflow/tensorflow/issues/16364"
> +        bb.warn(msg)
> +}
>
>
>
>
>


--
# Randy MacLeod
# Wind River Linux


Re: perf compilation fails

Michael Opdenacker
 

Hi Jose Antonio

On 1/13/22 3:29 PM, Cardenas Jose Antonio (JCARDENA) wrote:

Hi guys

 

I’m no table to build correctly perf package.

 

It looks like some sources have no been compiled because I’m getting
an “undefined reference to” error.

 

This problem has appeared since we have upgraded the version of yocto
zeus.

 

I’m getting this error

 

   arm-poky-linux-gnueabi-ld
--sysroot=/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/recipe-sysroot   
-r -o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/perf-in.o 
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-bench.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-annotate.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-config.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-diff.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-evlist.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-ftrace.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-help.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-sched.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-buildid-list.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-buildid-cache.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-kallsyms.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-list.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-record.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-report.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-stat.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-timechart.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-top.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-script.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-kmem.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-lock.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-kvm.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-inject.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-mem.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-data.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-version.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-c2c.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-probe.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/bench/perf-in.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/tests/perf-in.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/perf.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/util/perf-in.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/arch/perf-in.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/ui/perf-in.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/scripts/perf-in.o

arm-poky-linux-gnueabi-gcc  -march=armv7-a -mfpu=neon -mfloat-abi=hard
-fstack-protector-strong  -D_FORTIFY_SOURCE=2 -Wformat
-Wformat-security -Werror=format-security -Os -pipe -g
-feliminate-unused-debug-types
-fmacro-prefix-map=/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9=/usr/src/debug/perf/1.0-r9                     
-fdebug-prefix-map=/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9=/usr/src/debug/perf/1.0-r9                     
-fdebug-prefix-map=/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/recipe-sysroot=                     
-fdebug-prefix-map=/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/recipe-sysroot-native= 
--sysroot=/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/recipe-sysroot
-ldw -Wbad-function-cast -Wdeclaration-after-statement
-Wformat-security -Wformat-y2k -Winit-self -Wmissing-declarations
-Wmissing-prototypes -Wnested-externs -Wno-system-headers
-Wold-style-definition -Wpacked -Wredundant-decls -Wstrict-prototypes
-Wswitch-default -Wswitch-enum -Wundef -Wwrite-strings -Wformat
-Wstrict-aliasing=3 -Wshadow -DHAVE_PERF_REGS_SUPPORT -O6
-fno-omit-frame-pointer -ggdb3 -funwind-tables -Wall -Wextra
-std=gnu99 -fstack-protector-all -D_FORTIFY_SOURCE=2
-I/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/tools/perf/util/include
-I/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/tools/perf/arch/arm/include
-I/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/tools/include/uapi
-I/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/tools/include/
-I/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/tools/arch/arm/include/uapi
-I/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/tools/arch/arm/include/
-I/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/tools/arch/arm/
-I/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0//util
-I/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/
-I/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/tools/perf/util
-I/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/tools/perf
-I/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/tools/lib/
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE
-DHAVE_SYNC_COMPARE_AND_SWAP_SUPPORT
-DHAVE_PTHREAD_ATTR_SETAFFINITY_NP -DHAVE_PTHREAD_BARRIER
-DHAVE_EVENTFD -DHAVE_GET_CURRENT_DIR_NAME -DHAVE_GETTID
-DHAVE_DWARF_GETLOCATIONS_SUPPORT -DHAVE_GLIBC_SUPPORT
-DHAVE_AIO_SUPPORT -DHAVE_SCHED_GETCPU_SUPPORT -DHAVE_SETNS_SUPPORT
-DHAVE_LIBELF_SUPPORT -DHAVE_LIBELF_MMAP_SUPPORT
-DHAVE_ELF_GETPHDRNUM_SUPPORT -DHAVE_GELF_GETNOTE_SUPPORT
-DHAVE_ELF_GETSHDRSTRNDX_SUPPORT -DHAVE_LIBBPF_SUPPORT -DHAVE_JITDUMP
-DHAVE_DWARF_UNWIND_SUPPORT -DHAVE_LIBUNWIND_SUPPORT
-I/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/recipe-sysroot/usr/include
-DHAVE_LIBCRYPTO_SUPPORT -DHAVE_SLANG_SUPPORT -DNO_LIBPERL
-DHAVE_TIMERFD_SUPPORT -DNO_LIBPYTHON -DHAVE_CPLUS_DEMANGLE_SUPPORT
-DHAVE_LIBBFD_SUPPORT -DHAVE_ZLIB_SUPPORT -DHAVE_LZMA_SUPPORT
-DHAVE_BACKTRACE_SUPPORT -DDISASM_FOUR_ARGS_SIGNATURE
-DHAVE_AUXTRACE_SUPPORT
-I/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/
-ldl -lutil -Wl,-z,noexecstack -lunwind -lunwind-arm
-L/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/recipe-sysroot/usr/lib
-Xlinker
--dynamic-list=/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/libtraceevent-dynamic-list
\

              
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/perf-in.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/pmu-events/pmu-events-in.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/libperf-in.o
-Wl,--whole-archive
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/libapi.a
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/libtraceevent.a
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/libsubcmd.a
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/libbpf.a 
-Wl,--no-whole-archive -Wl,--start-group -lpthread -lrt -lm -ldl -lelf
-lunwind -lunwind-arm -lcrypto -lslang -lbfd -lopcodes -liberty -lz
-llzma -Wl,--end-group -o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/perf

/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi/../../libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/9.3.0/ld:
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/perf-in.o:
in function `find_address_in_section':

/usr/src/debug/perf/1.0-r9/perf-1.0/tools/perf/util/srcline.c:200:
undefined reference to `bfd_get_section_flags'

/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi/../../libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/9.3.0/ld:
/usr/src/debug/perf/1.0-r9/perf-1.0/tools/perf/util/srcline.c:204:
undefined reference to `bfd_get_section_vma'

/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi/../../libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/9.3.0/ld:
/usr/src/debug/perf/1.0-r9/perf-1.0/tools/perf/util/srcline.c:205:
undefined reference to `bfd_get_section_size'

collect2: error: ld returned 1 exit status

make[2]: *** [Makefile.perf:608:
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/perf]
Error 1

make[1]: *** [Makefile.perf:219: sub-make] Error 2

make: *** [Makefile:70: all] Error 2

make: Leaving directory
'/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/tools/perf'

ERROR: oe_runmake failed

WARNING:
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/temp/run.do_compile.146045:1
exit 1 from 'exit 1'

ERROR: Execution of
'/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/temp/run.do_compile.146045'
failed with exit code 1
Weird, this doesn't happen building core-image-minimal *for x86_64* on
the latest Poky, with gcc 11.2.
This may not help much, but at least you could compare.
Cheers
Michael.

--
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


Re: [OE-core] Question of Yocto dunfell LTS period

Alexander Kanavin
 

Actually, I think this was some kind of missed PR opportunity. Regular distros, such as RHEL, Debian and everyone else, are constantly trotting out their support windows as the reason to hand them the job of making products, so we could counter that better perhaps.

Alex


On Fri, 14 Jan 2022 at 06:28, Michael Opdenacker <michael.opdenacker@...> wrote:

On 1/14/22 2:36 AM, Jate Sujjavanich wrote:
> I received the answer to this question in IRC on 10/29/2021.
>
> 16:06
> <https://libera.irclog.whitequark.org/yocto/2021-10-29#31083490> <jatedev>
> I saw a wiki edit that said dunfell's LTS period is now through April
> 2024, but I've seen no announcements. Any truth to this rumor? 
> 16:20
> <https://libera.irclog.whitequark.org/yocto/2021-10-29#31083555> <smurray>
> jatedev: it was announced on one of the technical calls a few weeks
> back, so yes AFAIK 
> 16:25
> <https://libera.irclog.whitequark.org/yocto/2021-10-29#31083577> <RP>
> jatedev: definitely true. I wish we could sort out the project
> advocacy side of things :( 
>
> Let this email serve as a little advocacy.


I believe this would also help if the website (releases page) and/or
official documentation carried such information.
Thanks for raising this concern!
Cheers
Michael.

--
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com





Re: Installing specific systemd service file according to selected distro

Konrad Weihmann <kweihmann@...>
 

Fairly easy, each distro creates an OVERRIDE by default, so you could do

A:poky = "foo.service"
A:yourdistro = "bar.service"

SYSTEMD_PACKAGES = "${A}"

do_install:append() {
install -d ${D}${systemd_system_unitdir}
install -m 0644 ${WORKDIR}/${A} ${D}${systemd_system_unitdir}
}

you could also try to create distro-specific do_install appends like

do_install:append:<yourdistro> if you need to do further step besides installing

On 14.01.22 06:54, davis roman wrote:
Hello,
I have a recipe that contains two service files( A and B) and I build
for two distros where each include the foo recipe.
When I build for distro A, I need to use foo's service file A but when
I build distro B, I need to use foo's service file B.
I could add some logic in the foo recipe to detect the DISTRO and
install the proper service file but I have a feeling this isn't the
yocto way.
Is there a better way of handling this use case?
Thank you,
Davis


[layerindex][PATCH 19/18] templates/*: staticfiles -> static

Tim Orling
 

In Django 3.0 the staticfiles tag was changed to static

Signed-off-by: Tim Orling <tim.orling@...>
---
templates/layerindex/classicstats.html | 2 +-
templates/rrs/base_toplevel.html | 2 +-
templates/rrs/maintainers.html | 2 +-
templates/rrs/recipedetail.html | 2 +-
templates/rrs/recipes.html | 2 +-
templates/rrs/rrs_stats.html | 2 +-
6 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/templates/layerindex/classicstats.html b/templates/layerindex/classicstats.html
index 18fdf70..b677520 100644
--- a/templates/layerindex/classicstats.html
+++ b/templates/layerindex/classicstats.html
@@ -1,6 +1,6 @@
{% extends "layerindex/classic_base.html" %}
{% load i18n %}
-{% load staticfiles %}
+{% load static %}

{% comment %}

diff --git a/templates/rrs/base_toplevel.html b/templates/rrs/base_toplevel.html
index c2f1c21..7ba97ab 100644
--- a/templates/rrs/base_toplevel.html
+++ b/templates/rrs/base_toplevel.html
@@ -1,6 +1,6 @@
{% extends "base.html" %}
{% load i18n %}
-{% load staticfiles %}
+{% load static %}

{% comment %}

diff --git a/templates/rrs/maintainers.html b/templates/rrs/maintainers.html
index 217a060..c8f2418 100644
--- a/templates/rrs/maintainers.html
+++ b/templates/rrs/maintainers.html
@@ -1,6 +1,6 @@
{% extends "rrs/base_toplevel.html" %}
{% load i18n %}
-{% load staticfiles %}
+{% load static %}

{% comment %}

diff --git a/templates/rrs/recipedetail.html b/templates/rrs/recipedetail.html
index e2bcfe2..8f90735 100644
--- a/templates/rrs/recipedetail.html
+++ b/templates/rrs/recipedetail.html
@@ -1,6 +1,6 @@
{% extends "base.html" %}
{% load i18n %}
-{% load staticfiles %}
+{% load static %}

{% comment %}

diff --git a/templates/rrs/recipes.html b/templates/rrs/recipes.html
index b62df87..663f547 100644
--- a/templates/rrs/recipes.html
+++ b/templates/rrs/recipes.html
@@ -1,6 +1,6 @@
{% extends "rrs/base_toplevel.html" %}
{% load i18n %}
-{% load staticfiles %}
+{% load static %}

{% comment %}

diff --git a/templates/rrs/rrs_stats.html b/templates/rrs/rrs_stats.html
index a13c8f2..52b723f 100644
--- a/templates/rrs/rrs_stats.html
+++ b/templates/rrs/rrs_stats.html
@@ -1,6 +1,6 @@
{% extends "rrs/base_toplevel.html" %}
{% load i18n %}
-{% load staticfiles %}
+{% load static %}

{% comment %}

--
2.30.2


Re: Question of Yocto dunfell LTS period

Matthias Klein
 

Hello together,

I would like to add a question to the topic:

Why was the LTS period for dunfell extended?
Can we expect the same for kirstone?

Many greetings,
Matthias

-----Ursprüngliche Nachricht-----
Von: yocto@... <yocto@...> Im Auftrag von Chanho Park via lists.yoctoproject.org
Gesendet: Freitag, 14. Januar 2022 02:14
An: yocto@...; openembedded-core@...
Cc: richard.purdie@...; steve@...
Betreff: [yocto] Question of Yocto dunfell LTS period

Dear folks,

I found the lts period of Yocto dunfell has been extended from 2022.04 to 2024.04[1].
AFAIK, a Yocto LTS version has 2 years period. I tried to find any notice regarding this but I just found Richard's e-mail[2] in last year.
Can I find any thread or notice regarding this extension?

[1]: https://wiki.yoctoproject.org/wiki/Releases
[2]:
https://lore.kernel.org/yocto/3878e27fb895718b8c5d65f444fea443a56e0587.camel
@linuxfoundation.org/

Best Regards,
Chanho Park


[layerindex][PATCH 18/18] requirements.txt: bump all to latest

Tim Orling
 

Run pip-upgrade and update all to latest

Signed-off-by: Tim Orling <tim.orling@...>
---
requirements.txt | 36 ++++++++++++++++++------------------
1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/requirements.txt b/requirements.txt
index 41a0b1e..77b1aa9 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -1,27 +1,27 @@
-amqp==5.0.6
-beautifulsoup4==4.9.3
+amqp==5.0.9
+beautifulsoup4==4.10.0
billiard==3.6.4.0
-celery==5.1.2
+celery==5.2.3
confusable-homoglyphs==3.2.0
Django>=3.2,<3.3
-django-appconf==1.0.4
-django-axes==5.20.0
+django-appconf==1.0.5
+django-axes==5.31.0
django-bootstrap-pagination==1.7.1
-django-cors-headers==3.7.0
-django-ipware==3.0.2
+django-cors-headers==3.11.0
+django-ipware==4.0.2
django-ranged-response==0.2.0
django-registration==3.2
-django-reversion==4.0.0
-django-reversion-compare==0.14.0
+django-reversion==4.0.1
+django-reversion-compare==0.14.1
django-simple-captcha==0.5.14
-djangorestframework==3.12.4
-gitdb==4.0.7
-GitPython==3.1.18
-kombu==5.1.0
-mysqlclient==2.0.3
-Pillow==8.3.1
-pytz==2021.1
+djangorestframework==3.13.1
+gitdb==4.0.9
+GitPython==3.1.26
+kombu==5.2.3
+mysqlclient==2.1.0
+Pillow==9.0.0
+pytz==2021.3
six==1.16.0
-smmap==4.0.0
-soupsieve==2.2.1
+smmap==5.0.0
+soupsieve==2.3.1
vine==5.0.0
--
2.30.2


[layerindex][PATCH 17/18] Dockerfile: add back python2 dependencies

Tim Orling
 

We have some layers and especially older releases that still support
python2. Add python2 dependencies back to the container so that the
older releases still function.

Signed-off-by: Tim Orling <tim.orling@...>
---
Dockerfile | 5 +++++
1 file changed, 5 insertions(+)

diff --git a/Dockerfile b/Dockerfile
index 25ab5ea..4b2870a 100644
--- a/Dockerfile
+++ b/Dockerfile
@@ -22,6 +22,11 @@ RUN DEBIAN_FRONTEND=noninteractive apt-get update \
g++ \
gcc \
make \
+ python-pip \
+ python-mysqldb \
+ python-dev \
+ python-pil \
+ python-wheel \
python3-pip \
python3-mysqldb \
python3-dev \
--
2.30.2


[layerindex][PATCH 16/18] rrs: add 0030_alter_recipeupgrade_maintainer.py miagration

Tim Orling
 

Signed-off-by: Tim Orling <tim.orling@...>
---
.../0030_alter_recipeupgrade_maintainer.py | 20 +++++++++++++++++++
1 file changed, 20 insertions(+)
create mode 100644 rrs/migrations/0030_alter_recipeupgrade_maintainer.py

diff --git a/rrs/migrations/0030_alter_recipeupgrade_maintainer.py b/rrs/mi=
grations/0030_alter_recipeupgrade_maintainer.py
new file mode 100644
index 0000000..7044739
--- /dev/null
+++ b/rrs/migrations/0030_alter_recipeupgrade_maintainer.py
@@ -0,0 +1,20 @@
+# -*- coding: utf-8 -*-=0D
+# Generated by Django 3.2.11 on 2022-01-13 22:16=0D
+=0D
+from django.db import migrations, models=0D
+import django.db.models.deletion=0D
+=0D
+=0D
+class Migration(migrations.Migration):=0D
+=0D
+ dependencies =3D [=0D
+ ('rrs', '0029_rrs_license_group'),=0D
+ ]=0D
+=0D
+ operations =3D [=0D
+ migrations.AlterField(=0D
+ model_name=3D'recipeupgrade',=0D
+ name=3D'maintainer',=0D
+ field=3Dmodels.ForeignKey(blank=3DTrue, null=3DTrue, on_delete=
=3Ddjango.db.models.deletion.SET_NULL, to=3D'rrs.maintainer'),=0D
+ ),=0D
+ ]=0D
--=20
2.30.2


[layerindex][PATCH 15/18] Dockerfile: fix warnings

Tim Orling
 

* Define LANGUAGE
* Set DEBIAN_FRONTEND=noninteractive before apt call

Signed-off-by: Tim Orling <tim.orling@...>
---
Dockerfile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Dockerfile b/Dockerfile
index f6623fa..25ab5ea 100644
--- a/Dockerfile
+++ b/Dockerfile
@@ -4,6 +4,7 @@ FROM debian:buster
LABEL maintainer="Michael Halstead <mhalstead@...>"

ENV PYTHONUNBUFFERED=1 \
+ LANGUAGE=en_US \
LANG=en_US.UTF-8 \
LC_ALL=en_US.UTF-8 \
LC_CTYPE=en_US.UTF-8
@@ -15,7 +16,7 @@ ENV PYTHONUNBUFFERED=1 \
# NOTE: we don't purge gcc below as we have some places in the OE metadata that look for it

COPY requirements.txt /
-RUN apt-get update \
+RUN DEBIAN_FRONTEND=noninteractive apt-get update \
&& apt-get install -y --no-install-recommends \
autoconf \
g++ \
--
2.30.2


[layerindex][PATCH 14/18] rrs/admin.py: drop curry import

Tim Orling
 

Dropped in Django 3.0 [1]
Suggested replacements are functools.partial() or
functools.partialmethod() [2]

[1] https://docs.djangoproject.com/en/4.0/releases/3.0/
[2] https://github.com/django/django/commit/5b1c389603a353625ae1603ba345147356336afb

Signed-off-by: Tim Orling <tim.orling@...>
---
rrs/admin.py | 2 --
1 file changed, 2 deletions(-)

diff --git a/rrs/admin.py b/rrs/admin.py
index 402279f..25e9125 100644
--- a/rrs/admin.py
+++ b/rrs/admin.py
@@ -6,8 +6,6 @@
#
# SPDX-License-Identifier: MIT

-from django.utils.functional import curry
-
from django.contrib import admin
from django.contrib.admin import DateFieldListFilter
from django import forms
--
2.30.2


[layerindex][PATCH v2 13/18] README.devel: update versions

Tim Orling
 

This updated code-base should be compatible with
Django 3.1 and obviously 3.2 (but not 3.0 or earlier).

Django 3.2 requires Python 3.6+.

With the upgrade to Celery 5, it is safer to recommend
RabbitMQ 3.8.x, since that is what we are using.

Signed-off-by: Tim Orling <tim.orling@...>
---
README.devel | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/README.devel b/README.devel
index 347dafc..78fbfbb 100644
--- a/README.devel
+++ b/README.devel
@@ -7,9 +7,9 @@ covered in the main README.

In order to run this application standalone, you will need:

-* Python 3.5+
-* Django 2.2.x
-* RabbitMQ 3.7.x
+* Python 3.6+
+* Django 3.2.x (not compatible with 3.0 or older)
+* RabbitMQ 3.8.x
* For production usage, a web server set up to host Django applications
(not needed for local-only testing/development)
* A database system supported by Django (SQLite, MariaDB/MySQL, etc.).
--
2.30.2

1501 - 1520 of 57339