Date   

DNF package reinstallation

Hugh Boddington
 

I’ve got a fresh image, hot off the press with a clean install from dunfell (febbe2944c…).  I deploy it to my target machine as a fresh install, overwriting the whole storage array.  I’m using DNF as my package manager and I copy the packages from the build output to my web server.  On the target machine, I run ‘dnf upgrade’ and it hits the package repo and tells me that there’s a number of packages that need to be ‘reinstalled’.  No upgrades, conflicts etc – just reinstalled.  The packages don’t appear to have much in common – some are packages from my layers, some are unmodified poky packages.  I cannot figure out why dnf thinks they need to be reinstalled when it’s a fresh install and there’s only one version of everything.  I also can’t figure out the magic incantation to get dnf to tell me how it arrived at this conclusion.

 

Can anyone shed any light on this problem?  It’s driving me mad.  If I allow it to reinstall the packages and re-run ‘dnf upgrade’ I just get the same reinstallation list.


Re: ERROR: iso-codes-4.4-r0

Mikko Rapeli
 

Hi,

On Wed, Jul 08, 2020 at 07:52:30AM -0700, Pankaj Vinadrao Joshi wrote:
I am trying to build yocto image for RPI4 but i am getting following error

pankaj@exaleap-Inspiron-3584:~/raspberrypi4_image$ bitbake core-image-sato
Parsing recipes: 100% |######################################################################################################################################################################| Time: 0:09:59
Parsing of 2198 .bb files complete (0 cached, 2198 parsed). 3282 targets, 147 skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION           = "1.46.0"
BUILD_SYS            = "x86_64-linux"
NATIVELSBSTRING      = "universal"
TARGET_SYS           = "arm-poky-linux-gnueabi"
MACHINE              = "raspberrypi4"
DISTRO               = "poky"
DISTRO_VERSION       = "3.1"
TUNE_FEATURES        = "arm vfp cortexa7 neon vfpv4 thumb callconvention-hard"
TARGET_FPU           = "hard"
meta
meta-poky
meta-yocto-bsp       = "dunfell:9c8049068406532c3dd5d8906c595218b0fefd40"
meta-oe
meta-python
meta-networking
meta-multimedia      = "dunfell:e413c1ef621688e69bb7830bb3151ed23b30b73e"
meta-raspberrypi     = "master:5ac6f013339b0b1ab2d71f9f6af48a186e126c19"

Initialising tasks: 100% |###################################################################################################################################################################| Time: 0:00:18
Sstate summary: Wanted 1395 Found 0 Missed 1395 Current 1738 (0% match, 55% complete)
NOTE: Executing Tasks
WARNING: iso-codes-4.4-r0 do_fetch: Failed to fetch URL git://salsa.debian.org/iso-codes-team/iso-codes.git;protocol=http, attempting MIRRORS if available
ERROR: iso-codes-4.4-r0 do_fetch: Fetcher failure: Unable to find revision 38edb926592954b87eb527124da0ec68d2a748f3 in branch master even from upstream
ERROR: iso-codes-4.4-r0 do_fetch: Fetcher failure for URL: 'git://salsa.debian.org/iso-codes-team/iso-codes.git;protocol=http'. Unable to fetch URL from any source.
ERROR: Logfile of failure stored in: /home/pankaj/raspberrypi4_image/tmp/work/all-poky-linux/iso-codes/4.4-r0/temp/log.do_fetch.24501
ERROR: Task (/home/pankaj/Yocto-practice/poky/meta/recipes-support/iso-codes/iso-codes_4.4.bb:do_fetch) failed with exit code '1'

can someone help me how i can resolve this error?
Debian developers changed branch names in their repository.

Fixed in latest master and dunfell branches so either update or cherry-pick the
changes:

https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=dunfell&id=c253fd28ad26b4996666b0794dfee1d59c14e3ca

https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=75e91b8e52ec77398e6b0fc09456e971662d9d7e

Cheers,

-Mikko


Re: ERROR: iso-codes-4.4-r0

Quentin Schulz
 

Hi Pankaj,

On Wed, Jul 08, 2020 at 07:52:30AM -0700, Pankaj Vinadrao Joshi wrote:
I am trying to build yocto image for RPI4 but i am getting following error

pankaj@exaleap-Inspiron-3584:~/raspberrypi4_image$ bitbake core-image-sato
Parsing recipes: 100% |######################################################################################################################################################################| Time: 0:09:59
Parsing of 2198 .bb files complete (0 cached, 2198 parsed). 3282 targets, 147 skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION           = "1.46.0"
BUILD_SYS            = "x86_64-linux"
NATIVELSBSTRING      = "universal"
TARGET_SYS           = "arm-poky-linux-gnueabi"
MACHINE              = "raspberrypi4"
DISTRO               = "poky"
DISTRO_VERSION       = "3.1"
TUNE_FEATURES        = "arm vfp cortexa7 neon vfpv4 thumb callconvention-hard"
TARGET_FPU           = "hard"
meta
meta-poky
meta-yocto-bsp       = "dunfell:9c8049068406532c3dd5d8906c595218b0fefd40"
meta-oe
meta-python
meta-networking
meta-multimedia      = "dunfell:e413c1ef621688e69bb7830bb3151ed23b30b73e"
meta-raspberrypi     = "master:5ac6f013339b0b1ab2d71f9f6af48a186e126c19"

Initialising tasks: 100% |###################################################################################################################################################################| Time: 0:00:18
Sstate summary: Wanted 1395 Found 0 Missed 1395 Current 1738 (0% match, 55% complete)
NOTE: Executing Tasks
WARNING: iso-codes-4.4-r0 do_fetch: Failed to fetch URL git://salsa.debian.org/iso-codes-team/iso-codes.git;protocol=http, attempting MIRRORS if available
ERROR: iso-codes-4.4-r0 do_fetch: Fetcher failure: Unable to find revision 38edb926592954b87eb527124da0ec68d2a748f3 in branch master even from upstream
ERROR: iso-codes-4.4-r0 do_fetch: Fetcher failure for URL: 'git://salsa.debian.org/iso-codes-team/iso-codes.git;protocol=http'. Unable to fetch URL from any source.
ERROR: Logfile of failure stored in: /home/pankaj/raspberrypi4_image/tmp/work/all-poky-linux/iso-codes/4.4-r0/temp/log.do_fetch.24501
ERROR: Task (/home/pankaj/Yocto-practice/poky/meta/recipes-support/iso-codes/iso-codes_4.4.bb:do_fetch) failed with exit code '1'

can someone help me how i can resolve this error?
Update your dunfell branch (should be at commit
c253fd28ad26b4996666b0794dfee1d59c14e3ca)

Quentin


ERROR: iso-codes-4.4-r0

Pankaj Vinadrao Joshi
 

I am trying to build yocto image for RPI4 but i am getting following error 

pankaj@exaleap-Inspiron-3584:~/raspberrypi4_image$ bitbake core-image-sato
Parsing recipes: 100% |######################################################################################################################################################################| Time: 0:09:59
Parsing of 2198 .bb files complete (0 cached, 2198 parsed). 3282 targets, 147 skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies
 
Build Configuration:
BB_VERSION           = "1.46.0"
BUILD_SYS            = "x86_64-linux"
NATIVELSBSTRING      = "universal"
TARGET_SYS           = "arm-poky-linux-gnueabi"
MACHINE              = "raspberrypi4"
DISTRO               = "poky"
DISTRO_VERSION       = "3.1"
TUNE_FEATURES        = "arm vfp cortexa7 neon vfpv4 thumb callconvention-hard"
TARGET_FPU           = "hard"
meta                 
meta-poky            
meta-yocto-bsp       = "dunfell:9c8049068406532c3dd5d8906c595218b0fefd40"
meta-oe              
meta-python          
meta-networking      
meta-multimedia      = "dunfell:e413c1ef621688e69bb7830bb3151ed23b30b73e"
meta-raspberrypi     = "master:5ac6f013339b0b1ab2d71f9f6af48a186e126c19"
 
Initialising tasks: 100% |###################################################################################################################################################################| Time: 0:00:18
Sstate summary: Wanted 1395 Found 0 Missed 1395 Current 1738 (0% match, 55% complete)
NOTE: Executing Tasks
WARNING: iso-codes-4.4-r0 do_fetch: Failed to fetch URL git://salsa.debian.org/iso-codes-team/iso-codes.git;protocol=http, attempting MIRRORS if available
ERROR: iso-codes-4.4-r0 do_fetch: Fetcher failure: Unable to find revision 38edb926592954b87eb527124da0ec68d2a748f3 in branch master even from upstream
ERROR: iso-codes-4.4-r0 do_fetch: Fetcher failure for URL: 'git://salsa.debian.org/iso-codes-team/iso-codes.git;protocol=http'. Unable to fetch URL from any source.
ERROR: Logfile of failure stored in: /home/pankaj/raspberrypi4_image/tmp/work/all-poky-linux/iso-codes/4.4-r0/temp/log.do_fetch.24501
ERROR: Task (/home/pankaj/Yocto-practice/poky/meta/recipes-support/iso-codes/iso-codes_4.4.bb:do_fetch) failed with exit code '1'

can someone help me how i can resolve this error?


Re: Configuring UIO to handle GPIO interrupt #yocto #linux

Quentin Schulz
 

Hi Scott,

On Wed, Jul 08, 2020 at 07:15:17AM -0700, sdw@... wrote:
Dear Yocto community,

I am hoping that you can provide advice on configuring UIO to handle a GPIO interrupt from user space. I found an excellent summary at https://yurovsky.github.io/2014/10/10/linux-uio-gpio-interrupt.html and have tried to follow it as well as I can, being a newcomer to Yocto and embedded Linux.

We are using a Variscite DART-MX8M-MINI development kit, with the i.MX8M Mini processor on a System-on-Module. I have enabled spidev, which I am using to communicate with an ADS1299 EEG analog front end from TI. It generates a “data ready” interrupt DRDY# (active low). I’d like to be able to handle this falling-edge interrupt by connecting it to a GPIO (GPIO1_0) and either read() or poll() to wait for an interrupt, and can then read the acquired data using /dev/spidev0.0.

In my device tree, I have added the following under my &ecspi1 node. I am not certain this is the correct place to add this information, or if I can simply add it within the device tree “root” node “/ {“. I would appreciate your advice on the best place add this information!
// Added for DRDY# interrupt on GPIO1_0 from user space
user_io@0 {
compatible = "mydevice,generic-uio,ui_pdrv";
status = "okay";
interrupt-parent = <&gpio1>;
interrupts = <0 IRQ_TYPE_EDGE_FALLING>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_user_io>;
};

Under my dts &iomuxc node, the various pinctrl groups are defined. I added the following for GPIO1_0:
// Added for DRDY# interrupt on GPIO1_0 from user space
pinctrl_user_io: user_io-0 {
fsl,pins = <
MX8MM_IOMUXC_GPIO1_IO00_GPIO1_IO0 0x1c0
>;
};
This should configure the pin to enable a pull-up.

I have modified my kernel .config file via 'bitbake -c menuconfig virtual/kernel', and it contains the following entries:
CONFIG_UIO=y
CONFIG_UIO_PDRV_GENIRQ=m

The “y” setting for CONFIG_UIO was evidently due to other dependencies in the provided configuration. I then built the SD card image using 'bitbake fsl-image-qt5', and programmed it onto my SD card.
Up till there, this discussion would probably fit some kernel
communities more than the Yocto one.

A few things though:

- Bear in mind that using bitbake -c menuconfig virtual/kernel, the
changes aren't permanent. If there's a clean rebuild of the kernel for
some reason, your changes will be overwritten, you need to create a
patch for it (or take a defconfig) and add it to your kernel recipe (or
fork the kernel repo and add your own defconfig),

- Modules aren't shipped by default by Yocto, so you need either to
add kernel-modules to IMAGE_INSTALL or probably smarter to have it in
your machine configuration file in MACHINE_EXTRA_RRECOMMENDS, this will
install **all** kernel modules created by yocto,
or just add kernel-module-uio-pdrv-genirq (probably, don't know the exact
name of it) the same way to only have uio,

Quentin


Configuring UIO to handle GPIO interrupt #yocto #linux

sdw@...
 

Dear Yocto community,

I am hoping that you can provide advice on configuring UIO to handle a GPIO interrupt from user space. I found an excellent summary at https://yurovsky.github.io/2014/10/10/linux-uio-gpio-interrupt.html and have tried to follow it as well as I can, being a newcomer to Yocto and embedded Linux.

We are using a Variscite DART-MX8M-MINI development kit, with the i.MX8M Mini processor on a System-on-Module. I have enabled spidev, which I am using to communicate with an ADS1299 EEG analog front end from TI. It generates a “data ready” interrupt DRDY# (active low). I’d like to be able to handle this falling-edge interrupt by connecting it to a GPIO (GPIO1_0) and either read() or poll() to wait for an interrupt, and can then read the acquired data using /dev/spidev0.0.

In my device tree, I have added the following under my &ecspi1 node. I am not certain this is the correct place to add this information, or if I can simply add it within the device tree “root” node “/ {“. I would appreciate your advice on the best place add this information!
// Added for DRDY# interrupt on GPIO1_0 from user space
user_io@0 {
compatible = "mydevice,generic-uio,ui_pdrv";
status = "okay";
interrupt-parent = <&gpio1>;
interrupts = <0 IRQ_TYPE_EDGE_FALLING>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_user_io>;
};

Under my dts &iomuxc node, the various pinctrl groups are defined. I added the following for GPIO1_0:
// Added for DRDY# interrupt on GPIO1_0 from user space
pinctrl_user_io: user_io-0 {
fsl,pins = <
MX8MM_IOMUXC_GPIO1_IO00_GPIO1_IO0 0x1c0
>;
};
This should configure the pin to enable a pull-up.

I have modified my kernel .config file via 'bitbake -c menuconfig virtual/kernel', and it contains the following entries:
CONFIG_UIO=y
CONFIG_UIO_PDRV_GENIRQ=m

The “y” setting for CONFIG_UIO was evidently due to other dependencies in the provided configuration. I then built the SD card image using 'bitbake fsl-image-qt5', and programmed it onto my SD card.

However, when I boot the board up, I cannot see /dev/uio0 or run the modprobe command as specified in the description at the link provided above:
root@imx8mm-var-dart:~# ls /dev/u*
/dev/ubi_ctrl /dev/udev_network_queue /dev/uhid /dev/uinput /dev/urandom root@imx8mm-var-dart:~# modprobe uio_pdrv_genirq of_id="mydevice,generic-uio,ui_pdrv"
modprobe: FATAL: Module uio_pdrv_genirq not found in directory /lib/modules/4.19.35-imx8mm+ge6d3e3fefe4e

I used grep to look for “uio” in the /lib/modules directory, and only found the following:
root@imx8mm-var-dart:/lib/modules/4.19.35-imx8mm+ge6d3e3fefe4e# grep -RnI uio .
./modules.builtin:270:kernel/drivers/uio/uio.ko

I am stumped, and think I must have something wrong in my .dts file, my .config file, or in the packages/libraries added to the Yocto image. Do you have any suggestions for how to diagnose/fix this problem? I can provide my .config file, .dts file, or any other information, but I am not sure how they should be added for access by the group.

UIO apparently is a "preferred" way to handle writing simple device drivers from user space. Do I need to add something to Yocto to enable UIO and UIO_PDRV_GENIRQ?

Thank you for your help, and kind regards,
Scott


Re: Broken dunfell branch

Stefano Babic
 

Hi Guy,

On 08.07.20 15:15, Guy Morand wrote:
Hallo Yocto deveopers!

For our daily release, we build from the latest dunfell branch. I would
like to thank and congratulate you because we have been doing so for
over a year and the build never broke because of poky/OE meta layers!

However, we recently got some errors:

ERROR: mtd-utils-2.1.1-r0 do_patch: Command Error: 'quilt --quiltrc
/mnt/sdb/buildAgent/work/8161e17a85bb6b69/build/tmp/work/armv7vet2hf-neon-scewo-linux-gnueabi/mtd-utils/2.1.1-r0/recipe-sysroot-native/etc/quiltrc
push' exited with 0  Output:
Applying patch 0001-mtd-utils-Fix-return-value-of-ubiformat.patch
patching file ubi-utils/ubiformat.c
Hunk #1 FAILED at 550.
Hunk #2 FAILED at 643.
Hunk #3 FAILED at 669.
3 out of 3 hunks FAILED -- rejects in file ubi-utils/ubiformat.c
Patch 0001-mtd-utils-Fix-return-value-of-ubiformat.patch can be
reverse-applied
ERROR: Logfile of failure stored in:
/mnt/sdb/buildAgent/work/8161e17a85bb6b69/build/tmp/work/armv7vet2hf-neon-scewo-linux-gnueabi/mtd-utils/2.1.1-r0/temp/log.do_patch.23641

ERROR: Task
(/mnt/sdb/buildAgent/work/8161e17a85bb6b69/meta-layers/poky/meta/recipes-devtools/mtd/mtd-utils_git.bb:do_patch)
failed with exit code '1'

It seems the faulty commit is:
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=dunfell&id=994783b52e5c0a97000b8b643c8fd80d81069097


For now I simply build from the previous commit and everything is fine.
Not sure if someone already noticed that or if there is something wrong
with my setup?
Do you have meta-swupdate in your layers, too, and are you using -master
(see commit ece400ed5) ?

Best regards,
Stefano Babic

Best regards,

Guy Morand



--
=====================================================================
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic@...
=====================================================================


Re: Broken dunfell branch

Martin Jansa
 

This 0001-mtd-utils-Fix-return-value-of-ubiformat.patch patch was recently backported to dunfell in

check with "bitbake -e mtd-utils" to see which other layer in your build adds the same patch or changes SRCREV to newer commit which already contains the same change from upstream.

On Wed, Jul 8, 2020 at 3:15 PM Guy Morand <guy@...> wrote:
Hallo Yocto deveopers!

For our daily release, we build from the latest dunfell branch. I would
like to thank and congratulate you because we have been doing so for
over a year and the build never broke because of poky/OE meta layers!

However, we recently got some errors:

ERROR: mtd-utils-2.1.1-r0 do_patch: Command Error: 'quilt --quiltrc
/mnt/sdb/buildAgent/work/8161e17a85bb6b69/build/tmp/work/armv7vet2hf-neon-scewo-linux-gnueabi/mtd-utils/2.1.1-r0/recipe-sysroot-native/etc/quiltrc
push' exited with 0  Output:
Applying patch 0001-mtd-utils-Fix-return-value-of-ubiformat.patch
patching file ubi-utils/ubiformat.c
Hunk #1 FAILED at 550.
Hunk #2 FAILED at 643.
Hunk #3 FAILED at 669.
3 out of 3 hunks FAILED -- rejects in file ubi-utils/ubiformat.c
Patch 0001-mtd-utils-Fix-return-value-of-ubiformat.patch can be
reverse-applied
ERROR: Logfile of failure stored in:
/mnt/sdb/buildAgent/work/8161e17a85bb6b69/build/tmp/work/armv7vet2hf-neon-scewo-linux-gnueabi/mtd-utils/2.1.1-r0/temp/log.do_patch.23641
ERROR: Task
(/mnt/sdb/buildAgent/work/8161e17a85bb6b69/meta-layers/poky/meta/recipes-devtools/mtd/mtd-utils_git.bb:do_patch)
failed with exit code '1'

It seems the faulty commit is:
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=dunfell&id=994783b52e5c0a97000b8b643c8fd80d81069097

For now I simply build from the previous commit and everything is fine.
Not sure if someone already noticed that or if there is something wrong
with my setup?

Best regards,

Guy Morand


Broken dunfell branch

Guy Morand <guy@...>
 

Hallo Yocto deveopers!

For our daily release, we build from the latest dunfell branch. I would like to thank and congratulate you because we have been doing so for over a year and the build never broke because of poky/OE meta layers!

However, we recently got some errors:

ERROR: mtd-utils-2.1.1-r0 do_patch: Command Error: 'quilt --quiltrc /mnt/sdb/buildAgent/work/8161e17a85bb6b69/build/tmp/work/armv7vet2hf-neon-scewo-linux-gnueabi/mtd-utils/2.1.1-r0/recipe-sysroot-native/etc/quiltrc push' exited with 0 Output:
Applying patch 0001-mtd-utils-Fix-return-value-of-ubiformat.patch
patching file ubi-utils/ubiformat.c
Hunk #1 FAILED at 550.
Hunk #2 FAILED at 643.
Hunk #3 FAILED at 669.
3 out of 3 hunks FAILED -- rejects in file ubi-utils/ubiformat.c
Patch 0001-mtd-utils-Fix-return-value-of-ubiformat.patch can be reverse-applied
ERROR: Logfile of failure stored in: /mnt/sdb/buildAgent/work/8161e17a85bb6b69/build/tmp/work/armv7vet2hf-neon-scewo-linux-gnueabi/mtd-utils/2.1.1-r0/temp/log.do_patch.23641
ERROR: Task (/mnt/sdb/buildAgent/work/8161e17a85bb6b69/meta-layers/poky/meta/recipes-devtools/mtd/mtd-utils_git.bb:do_patch) failed with exit code '1'

It seems the faulty commit is:
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=dunfell&id=994783b52e5c0a97000b8b643c8fd80d81069097

For now I simply build from the previous commit and everything is fine. Not sure if someone already noticed that or if there is something wrong with my setup?

Best regards,

Guy Morand


Add application with library to target

Kjeld Flarup
 

I have a functioning Yocto build today, but two of the recipes are optional. An application and a library.
I would like to split my build in two. 

One that contains the basic system with kernel rootfs etc.
A second that just contains the application and the library

If I just had the application, it would be simple just to use the SDK and generate the application. 
But when adding the library, things starts to be more complex. 

I would also like to use my existing recipe with dependencies etc. 

What is the best approach
  • Can this be done with the ADT?
  • Can a layer solve it
  • Do I need to do it all manually with the SDK

--
Regards 
Kjeld Flarup
DEIF A/S


Re: iso-codes project

Martin Jansa
 

Hi,

having both would be useful, but you have to ask upstream iso-codes developers why they also removed master, OE DL_DIR just followed what they did in upstream, which unfortunately includes pruning the master branch, still referenced by older releases.

Cheers,

On Wed, Jul 8, 2020 at 8:55 AM Michael Nazzareno Trimarchi <michael@...> wrote:
Hi Martin

On Wed, Jul 8, 2020 at 8:36 AM Martin Jansa <martin.jansa@...> wrote:
>
> Hi,
>
> it's know issue already fixed in master, see
> https://lists.openembedded.org/g/openembedded-architecture/message/1108
> thud is pretty much out of support and probably won't be fixed there, you should be able to easily fix it from .bbappend in one of your layers.
>

Why just don't continue to have both? I think was even re-history. I
will give a try

Michael

> Regards,
>
> On Wed, Jul 8, 2020 at 7:57 AM Michael Nazzareno Trimarchi <michael@...> wrote:
>>
>> Hi all
>>
>> anyone has problem on iso-codes in thud. Seems that project was
>> changed and not possible to download with the actual configuration
>>
>> Michael
>>
>> --
>> | Michael Nazzareno Trimarchi                     Amarula Solutions BV |
>> | COO  -  Founder                                      Cruquiuskade 47 |
>> | +31(0)851119172                                 Amsterdam 1018 AM NL |
>> |                  [`as] http://www.amarulasolutions.com               |
>>



--
| Michael Nazzareno Trimarchi                     Amarula Solutions BV |
| COO  -  Founder                                      Cruquiuskade 47 |
| +31(0)851119172                                 Amsterdam 1018 AM NL |
|                  [`as] http://www.amarulasolutions.com               |


Re: iso-codes project

Michael Nazzareno Trimarchi
 

Hi Martin

On Wed, Jul 8, 2020 at 8:36 AM Martin Jansa <martin.jansa@...> wrote:

Hi,

it's know issue already fixed in master, see
https://lists.openembedded.org/g/openembedded-architecture/message/1108
thud is pretty much out of support and probably won't be fixed there, you should be able to easily fix it from .bbappend in one of your layers.
Why just don't continue to have both? I think was even re-history. I
will give a try

Michael

Regards,

On Wed, Jul 8, 2020 at 7:57 AM Michael Nazzareno Trimarchi <michael@...> wrote:

Hi all

anyone has problem on iso-codes in thud. Seems that project was
changed and not possible to download with the actual configuration

Michael

--
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO - Founder Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
| [`as] http://www.amarulasolutions.com |


--
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO - Founder Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
| [`as] http://www.amarulasolutions.com |


Re: [ptest-runner][PATCH] Fix inappropriate ioctl when detaching tty

Tero Kinnunen
 

On Tue, Jul 7, 2020 at 06:49 AM, Anibal Limon wrote:
First thanks for the patch, Is there an option to test for isatty(fd) for run ioctl instead?.
Hi Anibal,

    if (isatty(0) && ioctl(0, TIOCNOTTY) == -1)

would help for ssh case but not to errors between tests. There fd 0 is a tty but detach should
be done only once. Now it is inside loop. It could work if it was also moved outside the loop,
before PTEST_LIST_ITERATE_START?

Kind regards,

    - Tero


Re: iso-codes project

Masahiko Kimoto
 

The project seems to change master branch name to 'main'.

Please try to add ';branch=main' into SRC_URI.

Regards,

From: "Michael Nazzareno Trimarchi" <michael@...>
Subject: [yocto] iso-codes project
Date: Wed, 8 Jul 2020 07:56:44 +0200

> Hi all
>
> anyone has problem on iso-codes in thud. Seems that project was
> changed and not possible to download with the actual configuration
>
> Michael
>
> --
> | Michael Nazzareno Trimarchi Amarula Solutions BV |
> | COO - Founder Cruquiuskade 47 |
> | +31(0)851119172 Amsterdam 1018 AM NL |
> | [`as] http://www.amarulasolutions.com |

----------------------------------------------------------------------
木本 雅彦 / Masahiko Kimoto, Ph.D.
E-mail: kimoto@... URL: http://www.ohnolab.org/~kimoto


Re: iso-codes project

Martin Jansa
 

Hi,

it's know issue already fixed in master, see
thud is pretty much out of support and probably won't be fixed there, you should be able to easily fix it from .bbappend in one of your layers.

Regards,

On Wed, Jul 8, 2020 at 7:57 AM Michael Nazzareno Trimarchi <michael@...> wrote:
Hi all

anyone has problem on iso-codes in thud. Seems that project was
changed and not possible to download with the actual configuration

Michael

--
| Michael Nazzareno Trimarchi                     Amarula Solutions BV |
| COO  -  Founder                                      Cruquiuskade 47 |
| +31(0)851119172                                 Amsterdam 1018 AM NL |
|                  [`as] http://www.amarulasolutions.com               |


iso-codes project

Michael Nazzareno Trimarchi
 

Hi all

anyone has problem on iso-codes in thud. Seems that project was
changed and not possible to download with the actual configuration

Michael

--
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO - Founder Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
| [`as] http://www.amarulasolutions.com |


Yocto Technical Team Minutes, Engineering Sync, for July 7, 2020

Trevor Woerner
 

Yocto Technical Team Minutes, Engineering Sync, for July 7, 2020
archive: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit

== disclaimer ==
Best efforts are made to ensure the below is accurate and valid. However,
errors sometimes happen. If any errors or omissions are found, please feel
free to reply to this email with any corrections.

== attendees ==
Trevor Woerner, Jan-Simon Möller, Stephen Jolly, Josef Holtzmeyer, Joshua
Watt, Trevor Gamblin, Steve Sakoman, Armin Kuster, Scott Murray, Peter
Kjellerstedt, Saul Wold, Ross Burton, Richard Purdie, Michael Halstead,
Rahul, Vineela?, Bruce Ashfield, Tim Orling, Randy MacLeod, Mathew Zeng,
Rob Woolley, Philip Balister, Paul Barker, Khem Raj

== notes ==
- thanks to everyone involved in any way with ELC and DevDay!
- still have AB instability
- still looking for more maintainers
- looking for way to attract and thank contributors
- lots of unassigned bugs we’d like to see for 3.2 (see unassigned bugs)

== general ==
RP: happy to have some things fixed in AB, but still issues

RP: thanks to everyone involved in ELC and especially the Yocto DevDay

Timo: i see the perl update was merged, but it seems like lots of things
were dropped (RDEPENDS), so i predict there will still be issues with
split-packaging
RP: i noticed that too, the AB was all green
Timo: we’re probably missing tests

Saul: heard a rumor about Stephen
Stephen: that i’m retiring? yes, next week. but i’m continuing on as a
volunteer with YP
Randy: how long at Intel?
Stephen: 34.5 years

RP: ? licenses are inherited globally, are people using the license package
directly?
JPEW: we display the generic and specific license because they’re there
SS: customers i’ve known have always used just the generic
Randy: WR has its own code for analysing the code to pull licenses, but
customers appreciate having the generic
Peter: we have to go through the code to sort out the 20 different variations
on GPLv2, a mess!
RP: it’s been pointed out to me that the checksums of the generic license
files are not checked, so if there was ever a change in the generic text,
there isn’t anything that would alert the users
Peter: is it meaningful to use checksums for the generic text? that’s not
the same case as the license of some upstream code changing
RP: well, if that changes then the task-hash should change which is supposed
to case rebuilds etc
JPEW: there was a bug filed
https://bugzilla.yoctoproject.org/show_bug.cgi?id=13917
RP: this shouldn’t be happening, but there are probably other “games”
going on

RP: is anyone using the SPDX class from OE-core? i hope the answer is
“no”, i imagine it’s quite broken by now. i have a patch i plan to
post
Randy: i don’t see WR using it (quick look)

Timo: i was looking at patchwork again, is there somewhere we can run a test
instance somewhere for testing
Michael: vm at digital ocean currently, i can create a staging instance on YP
hardware. who else will be using it?
Timo: Amber, potentially. i’ll give you an update
Michael: i’ll spin up something new, the current is ubuntu 16.04 so it needs
an update anyway

TW: how did the booth go last week at ELC virtual?
Philip Balister: the interface for the booth was clucky, didn’t get any new
contacts
Timo: i had one interesting contact at the booth, but it didn’t go as well
as it could have
Josef: not a lot of new folks, got a lot of people contacting me in thanks
for the live coding stuff, lots of contacts from the middle-European and
south-central Asia, we have lots of contacts in west Europe and NA, but
need to develop more in the other areas
RP: this would be a good question for the advocacy list
Randy: do you know what sort of communication would work best?
Josef: lots via linked-in, stack overflow. irc and email are not that popular.
lots and lots in twitter!
Timo: agree with twitter

Timo: what did people think of using slack?
TrevorG: hard to know whether to reply in-line or as a thread
Philip: feel it’s terrible for open source to use slack (free version
loses history, bad optics). gnu radio tried slack, moved away. recommend
mattermost
JPEW: slack can work if you have the ability to create arbitrary channels
(which wasn’t available with the ELC slack)
Scott: the mattermost interface has better handling for threads, a “best of
both worlds” between slack and irc
Timo: gitter (meta-python, etc) works better for me. i agree with Philip that
the thread thing
Philip: i’d be curious to see a mattermost try
RP: matrix might be a good way to bridge both worlds (traditional use irc,
younger crowd using other things)
Philip: matrix worked well for gnu radio
Paul: agree with others that slack wasn’t that great, but think that we
should explore other technologies
Timo: looking at what Fedora has done, it’d be great to see more
integration. e.g. reports from AB reported live
Khem: i’ve used matrix and like it, can’t comment on mattermost, i think
Fedora is also using discourse to amalgamate email, irc, etc. matrix is
nice because you can edit, so the log looks better than irc
RP: resources, risk of forking the community (some follow email, some follow
A, some follow B) i’d like to have a central dashboard but we need to
find resources
Paul: people who use a given technology might not be the people to are
interested in various aspects of the project
Timo: i like the idea of integrating
RP: it sounds like it can all be integrated
Balister: if the bridges aren’t setup properly it can be detrimental
(PaulB has visions of messages going around each platform recursively forever)

Timo: how did people feel about the hands-on sessions?
Khem: i think it went well in general, in-person would have been more
effective
TW: usually there are 2 tracks, break-out rooms
Khem: virtual is much harder, hard to get people the help when you’re not
sure who is at what stage, people have to speak up
Timo: in the past sometime we would just get to jump in and give people a new
instance
TW: hard to know who’s struggling, no feedback
Timo: large numbers too, glad to see the number of participants, but the
larger the class, the harder to manage.
Rob Woolley: https://github.com/conan-io/training?files=1 did a hands-on that
i thought was really well done. instructions on git, thumbs-up to say
“i’m done”, scripts to get people caught up
Khem: yes, good idea!
Josef: unfortunate that the biggest devday ever had only 1, mostly advanced,
track. and the first couple talks were on advanced details (licenses,
containers)
Scott: i think they were merged because beginner numbers were going down
Khem: we should have separate rooms
RP: there was a definite trend, in real conferences, esp in NA towards
intermediate/advanced talks. beginner attendance higher in europe
Khem: lots of people from everywhere around the world
Randy: why wait for the next conference? maybe do this monthly
JPEW: was there a survey?
various: yes

Timo: i really missed not having an OED{E|A}M
Philip: board is talking about it
TW: what about #oe-meeting on irc, we had a couple a while back
Philip: give us a bit of time to figure something out. nice that we don’t
have to put it against ELC/ELCe

Timo: want to give a shoutout to Josef for his working especially bringing in
new people via his Twitch streams
Josef: thanks! lots of neat stuff coming up. we’re over 32k views in last
few months, 150 new followers each week


Re: [yocto-autobuilder2][PATCH 0/2] Clarification and formatting of README-Guide.md

Trevor Gamblin
 


On 6/22/20 10:18 AM, Trevor Gamblin wrote:
Long-overdue patches based on experiences trying to set up an
autobuilder instance. I've split it into two patches because the second
patch (the one that line wraps the majority of the document) may not be
desired, if the doc is meant to be read in the pre-existing format.
Patch 0001 cleans up the doc so that the sections can be more easily
referenced.
Any issues with this patch set? Do I need to resend?

Trevor Gamblin (2):
  README-Guide: cleanup, clarify setup instructions
  README-Guide: wrap lines at 80 characters

 README-Guide.md | 489 ++++++++++++++++++++++++++++++++++++------------
 1 file changed, 372 insertions(+), 117 deletions(-)



    


Yocto Project Status WW27'20

Stephen Jolley
 

Current Dev Position: YP 3.2 M2

Next Deadline: YP 3.2 M2 build date 2020/7/27

 

Next Team Meetings:

 

Key Status/Updates:

  • Thanks to everyone who attended, helped out, organized or otherwise contributed to our ELC presence and YP Dev Day last week, we believe it was successful and people found it interesting and useful.
  • We continue to be concerned about autobuilder stability, we’re continuing to see high numbers of intermittent failures. You can see the list of failures we’re seeing by searching for the “AB-INT” tag in bugzilla: https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT

Help is urgently needed to bring these to a manageable level. We have managed to resolve or work around some of these issues over the past week and are starting to see green builds again.

  • We are struggling with maintainers for some key components of the system/infrastructure such as devtool, wic, buildhistory and patchwork/patchtest. If anyone can help in these areas please contact Richard.
  • If anyone has thoughts on attracting and recognising project contributors and contributions, we would be interested in ideas and assistance in that area.
  • Another way to help the project is to help us with bugs that are currently unassigned but ideally needed during 3.2. See: https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_3.2_Unassigned_Enhancements.2FBugs
  • We’re planning to migrate the project documentation from docbook to sphinx. If you’re interested/able to help with this please join the discussion over on the docs mailing list.

 

YP 3.2 Milestone Dates:

  • YP 3.2 M2 build date 2020/7/27
  • YP 3.2 M2 Release date 2020/8/7
  • YP 3.2 M3 build date 2020/8/31
  • YP 3.2 M3 Release date 2020/9/11
  • YP 3.2 M4 build date 2020/10/5
  • YP 3.2 M4 Release date 2020/10/30

 

Planned upcoming dot releases:

  • YP 3.0.4 build date 2020/8/10
  • YP 3.0.4 release date 2020/8/21
  • YP 3.1.2 build date 2020/9/14
  • YP 3.1.2 release date 2020/9/25

 

Tracking Metrics:

 

The Yocto Project’s technical governance is through its Technical Steering Committee, more information is available at:

https://wiki.yoctoproject.org/wiki/TSC

 

The Status reports are now stored on the wiki at: https://wiki.yoctoproject.org/wiki/Weekly_Status

 

[If anyone has suggestions for other information you’d like to see on this weekly status update, let us know!]

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Re: [ptest-runner][PATCH] Fix inappropriate ioctl when detaching tty

Anibal Limon
 

Hi Tero,

First thanks for the patch, Is there an option to test for isatty(fd) for run ioctl instead?.

Regards,
Anibal

On Tue, 7 Jul 2020 at 02:21, Tero Kinnunen <tero.kinnunen@...> wrote:
Fixes error

    ERROR: Unable to detach from controlling tty, Inappropriate ioctl for device

when running multiple ptests

    ptest-runner a b

or when invoked over ssh single command, like

    $ ssh localhost ptest-runner a

For ssh case, fd 0 is not a tty. (isatty(0) is false).
When running multiple ptests, deattach for parent needs to be
done only once. On subsequent calls, if deattach fails,
according to man 4 tty

    it is obviously not attached to a terminal and does not
    need to detach itself.

Detach was not necessary, skip the error message.

Signed-off-by: Tero Kinnunen <tero.kinnunen@...>
---
 utils.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/utils.c b/utils.c
index a8ba190..35ef551 100644
--- a/utils.c
+++ b/utils.c
@@ -444,7 +444,7 @@ run_ptests(struct ptest_list *head, const struct ptest_options opts,
                                break;
                        }
                        dirname(ptest_dir);
-                       if (ioctl(0, TIOCNOTTY) == -1) {
+                       if (ioctl(0, TIOCNOTTY) == -1 && errno != ENOTTY) {
                                fprintf(fp, "ERROR: Unable to detach from controlling tty, %s\n", strerror(errno));
                        }

--
2.25.1