[linux-yocto] v4.18.x - stable updates comprising v4.18.41
Bruce, Yocto kernel folks: Here is the next 4.18.x stable update "extension" primarily created for the Yocto project, continuing from the previous v4.18.40 release. There are about 220 commits here, based on commits chosen from what were used in the 4.19.46/47 stable releases -- plus some TCP related commits that were of interest to reach ahead and source from newer 4.19 now. Not all the 47 content was processed here, in order to keep the release size sane. The remainder will be considered for the 4.18.42 release. And as we enter August, I need to again remind people that the creation of these 4.18 stable backport releases will be ending relatively soon, as I'll expect to be moving to newer kernels used in newer Yocto releases. So people need to get their own maintenance or migration plans in place as soon as possible, if they have not yet done so. I've put this 4.18.x queue through the usual testing; build testing on x86-64/32, ARM-64/32, PPC and MIPS, plus some static analysis and finally some sanity runtime tests on x86-64. I did the signed tag just as per the previously released versions. Please find a signed v4.18.41 tag using this key: http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6 in the repo in the kernel.org directory here: https://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.18.y.git/?h=linux-4.18.y git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.18.y.git for merge to standard/base in linux-yocto-4.18 and then out from there into the other base and BSP branches. For those who are interested, the evolution of the commits is here: https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.18.git/ This repo isn't needed for anything; it just exists for transparency and so people can see the evolution of the raw commits that were originally selected to create this 4.18.x release. Paul. -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
[yocto] Announcing Preliminary Agenda - DevDay NA 2019
Yocto Project is excited to announce the preliminary agenda for the Yocto Project DevDay NA 2019. Agenda: Keynote & Welcome Package Feeds Deep-dive Runqueue and Build Equivalency to New Yocto Project Releases OEQA, QA Selftest, Runtime APIs, pTest Containers/Multiconfig Security Response Tool Gitlab, Docker and AWS or Devtool or User Space Not registered yet? Go to our event page and either add it to your OSS NA 2019 registration, or complete the standalone registration. https://www.yoctoproject.org/yocto-project-dev-day-north-america-2019/ Looking forward to welcoming you in San Diego! Yocto Project -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [yocto-autobuilder2][PATCH 2/3] Added remote distribution of config JSON files
I'm not sure I follow. This collects everything into the worker's "builddir/yocto-autobuilder-helper" path (I think; I'm new to buildbot). My aim was to let the buildbot master the chance to SCM the configuration files apart from the helper's behavior which should otherwise be consistent whether we're rebuilding for warrior or morty. For us this is turning out to not be "enough" since certain build targets don't exist between different releases of Poky and we're held back by BSPs to certain releases, so we need to decouple a bit further than this patch. The issue could also be solved with templates that dynamically point to other templates based on the Force Build branch, revision, etc., but I'm looking for a more simple approach than a recursive overlay. Thanks again for all your help and feedback. Cheers, Thomas On Fri, Aug 2, 2019 at 12:41 PM Richard Purdie wrote: > On Tue, 2019-07-30 at 14:36 -0400, Thomas Goodwin wrote: > > This feature/fix allows the worker to download the > > autobuilder helper JSON files from the controller > > rather than having to store them in the > > yocto-autobuilder-helper repository. The process > > installs the file into the worker's > > builddir/yocto-autobuilder-helper path. > > > > Signed-off-by: Thomas Goodwin > > --- > > builders.py | 22 ++ > > 1 file changed, 22 insertions(+) > > I like the idea however this is going to break the autobuilders as they > already use full paths in the variable. > > I've merged some of the other patches but this one will need a little > further thought so we don't break the existing install. > > The existing code also allows for different path locations on > individual workers (e.g. different username) which this would break. > > Cheers, > > Richard > > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] /var/volatile not mounted as tmpfs on read-only rootfs when migrating to Warrior
Hi Carsten, Thanks for your help. On Fri, 2 Aug 2019 at 20:42, Stelling2 Carsten < carsten.stelli...@goerlitz.com> wrote: > Hi Ryan, > > > > Regarding to timesyncd, have a look at > https://wiki.archlinux.org/index.php/systemd-timesyncd, especially the > section > > “Note: The service writes to a local file /var/lib/systemd/timesync/clock > with every synchronization. > > This location is hard-coded and cannot be changed. This may be problematic > for running off > > read-only root partition or trying to minimize writes to an SD card.” > Yes, this looks like it is my problem. I experimented with timesync, and by making /var/lib and a few other places writable, I'm able to start it manually, but not via systemd, which I think is experiencing other issues with the read-only rootfs. > > See also https://github.com/systemd/systemd/issues/5610 for your problem > with systemd-resolved. > > According to this, /var, /var/tmp, /run, and /tmp should be writable. > I think the problem is not Yocto specific, but possibly I overlook > something. > Again, I think you're right. I need to have these areas writable from boot. But I don't know how. I suppose my problem is that these areas used to be writable when I was using Sumo, but moving to Warrior has caused something to change. I'm wondering what extra steps I need to do in Warrior to ensure that all these things are mounted with tmpfs as before. I expect my Sumo recipes worked through luck more than design, and now something has changed, I need to improve them. It is rather difficult to work out what the relevant changes are. Kind regards, Ryan. > > Best regards, > > > > Carsten > > > > *Von:* yocto-boun...@yoctoproject.org [mailto: > yocto-boun...@yoctoproject.org] *Im Auftrag von *Ryan Harkin > *Gesendet:* Freitag, 2. August 2019 13:09 > *An:* yocto@yoctoproject.org > *Cc:* openembedded > *Betreff:* [yocto] /var/volatile not mounted as tmpfs on read-only rootfs > when migrating to Warrior > > > > Hi, > > > > I have a working system based on Sumo. The system boots with a read-only > rootfs, then applies are read-write overlay for /etc. > > > > When I migrate to Warrior, systemd-resolved fails to start. If I mount the > same rootfs via NFS, it starts and works fine. systemd-timesyncd is also > failing, but I haven't looked into that yet. It also works fine on the NFS > mounted system. > > > > The resolve problem seems to be caused by two things: > > - /var/volatile is read-only > > - /run/systemd/resolve has the wrong ownership > > drwxr-xr-x 2 systemd-network systemd-journal 80 Jul 12 16:23 > resolve/ > > I think this permissions problem may be a result of the > /var/volatile mounting > > problems; it looks fine on the NFS mounted system. > > > > If I manually mount /var/volatile (it's in fstab) and change the ownership > on /run/systemd/resolve, the service starts just fine. > > > > I also notice that /tmp is not mounted at all, which may be related. > > > > Here are the various tmp mount points on my read-only rootfs: > > > > $ mount | grep tmp > > devtmpfs on /dev type devtmpfs > (rw,nosuid,size=112036k,nr_inodes=28009,mode=755) > tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) > tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755) > tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755) > overlay on /etc type overlay > (rw,relatime,lowerdir=/tmp/lower/etc,upperdir=/tmp/upper/etc,workdir=/tmp/upper/work/etc) > tmpfs on /run/user/0 type tmpfs > (rw,nosuid,nodev,relatime,size=23840k,mode=700) > > On the NFS mounted system, I see these: > > > > $ mount | grep tmp > devtmpfs on /dev type devtmpfs > (rw,relatime,size=118180k,nr_inodes=29545,mode=755) > tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) > tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755) > tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755) > tmpfs on /tmp type tmpfs (rw,nosuid,nodev) > tmpfs on /var/volatile type tmpfs (rw,relatime) > tmpfs on /run/user/0 type tmpfs > (rw,nosuid,nodev,relatime,size=23840k,mode=700) > > As you can see, NFS has these extra mounts: > > > > tmpfs on /tmp type tmpfs (rw,nosuid,nodev) > > tmpfs on /var/volatile type tmpfs (rw,relatime) > > > > I've tried reverting a few commits that may be related, but I haven't had > any luck working out things have changed, eg: > > > > c4acf1b531 2018-10-19 volatile-binds: use overlayfs if available > [Matt Hoosier] > > > > Advice would be appreciated. Are there any particular areas I should be > looking to work out what's going wrong? > > > > Kind regards, > > Ryan. > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] installed-vs-shipped
Add
FILES_${PN} += "/usr/local/bin"
in recipe. but it would be nicer if it was installed into /usr/bin by
qmake/make files itself
On Fri, Aug 2, 2019 at 11:59 AM Mauro Ziliani wrote:
>
> Hi all.
>
> This is my problem.
>
> I have my terminal.pro project (qmake5) with target "terminal".
>
> The default destination folder for the binary is /usr/local/bin
>
> With this setup I get installed-vs-shipped error.
>
>
> Why?
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] /var/volatile not mounted as tmpfs on read-only rootfs when migrating to Warrior
Hi Ryan, Regarding to timesyncd, have a look at https://wiki.archlinux.org/index.php/systemd-timesyncd, especially the section “Note: The service writes to a local file /var/lib/systemd/timesync/clock with every synchronization. This location is hard-coded and cannot be changed. This may be problematic for running off read-only root partition or trying to minimize writes to an SD card.” See also https://github.com/systemd/systemd/issues/5610 for your problem with systemd-resolved. According to this, /var, /var/tmp, /run, and /tmp should be writable. I think the problem is not Yocto specific, but possibly I overlook something. Best regards, Carsten Von: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] Im Auftrag von Ryan Harkin Gesendet: Freitag, 2. August 2019 13:09 An: yocto@yoctoproject.org Cc: openembedded Betreff: [yocto] /var/volatile not mounted as tmpfs on read-only rootfs when migrating to Warrior Hi, I have a working system based on Sumo. The system boots with a read-only rootfs, then applies are read-write overlay for /etc. When I migrate to Warrior, systemd-resolved fails to start. If I mount the same rootfs via NFS, it starts and works fine. systemd-timesyncd is also failing, but I haven't looked into that yet. It also works fine on the NFS mounted system. The resolve problem seems to be caused by two things: - /var/volatile is read-only - /run/systemd/resolve has the wrong ownership drwxr-xr-x 2 systemd-network systemd-journal 80 Jul 12 16:23 resolve/ I think this permissions problem may be a result of the /var/volatile mounting problems; it looks fine on the NFS mounted system. If I manually mount /var/volatile (it's in fstab) and change the ownership on /run/systemd/resolve, the service starts just fine. I also notice that /tmp is not mounted at all, which may be related. Here are the various tmp mount points on my read-only rootfs: $ mount | grep tmp devtmpfs on /dev type devtmpfs (rw,nosuid,size=112036k,nr_inodes=28009,mode=755) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755) tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755) overlay on /etc type overlay (rw,relatime,lowerdir=/tmp/lower/etc,upperdir=/tmp/upper/etc,workdir=/tmp/upper/work/etc) tmpfs on /run/user/0 type tmpfs (rw,nosuid,nodev,relatime,size=23840k,mode=700) On the NFS mounted system, I see these: $ mount | grep tmp devtmpfs on /dev type devtmpfs (rw,relatime,size=118180k,nr_inodes=29545,mode=755) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755) tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755) tmpfs on /tmp type tmpfs (rw,nosuid,nodev) tmpfs on /var/volatile type tmpfs (rw,relatime) tmpfs on /run/user/0 type tmpfs (rw,nosuid,nodev,relatime,size=23840k,mode=700) As you can see, NFS has these extra mounts: tmpfs on /tmp type tmpfs (rw,nosuid,nodev) tmpfs on /var/volatile type tmpfs (rw,relatime) I've tried reverting a few commits that may be related, but I haven't had any luck working out things have changed, eg: c4acf1b531 2018-10-19 volatile-binds: use overlayfs if available [Matt Hoosier] Advice would be appreciated. Are there any particular areas I should be looking to work out what's going wrong? Kind regards, Ryan. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] installed-vs-shipped
Hi all. This is my problem. I have my terminal.pro project (qmake5) with target "terminal". The default destination folder for the binary is /usr/local/bin With this setup I get installed-vs-shipped error. Why? -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] git.yoctoproject.org TLS certificate expired
On Sat, May 04, 2019 at 10:59:34AM -0700, Michael Halstead wrote: > On 5/4/19 9:19 AM, Adrian Bunk wrote: > > $ git pull > > fatal: unable to access 'https://git.yoctoproject.org/git/poky/': server > > certificate verification failed. CAfile: none CRLfile: none > > $ > > > > > > Firefox says: > > git.yoctoproject.org uses an invalid security certificate. The > > certificate expired on May 4, 2019, 7:53 AM. The current time is May 4, > > 2019, 7:16 PM. > > > > > > cu > > Adrian > > I've renewed the certificate manually for now. > > I will review the automated process and monitoring to make sure this > doesn't happen again. 90 days later the new certificate now expired. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Patching /lib/systemd/system/systemd-networkd-wait-online.service
>
> Is ./sources/poky/meta/recipes-core/systemd/systemd_234.bb the proper
> place to patch this service file?
You should really put this in a `.bbappend` instead and also that
`.bbappend` should be in your own meta-layer if possible. In case you want
to upgrade stuff in the future it makes life a lot easier.
On Thu, Aug 1, 2019 at 11:52 PM Khem Raj wrote:
> you should be patching ./units/systemd-networkd-wait-online.service.in
> file
>
> On Thu, Aug 1, 2019 at 8:14 AM Edward Tyrrell
> wrote:
> >
> > Hi,
> >
> >
> > I'm trying to add a patch to the systemd layer to amend
> systemd-networkd-wait-online.service. Within the service I simply want to
> add --any as a parameter.
> >
> >
> > The problem is my is bitbake fails with:
> >
> > Applying patch 0020-systemd-networkd-wait-online-service.patch
> > can't find file to patch at input line 3
> > Perhaps you used the wrong -p or --strip option?
> > The text leading up to this was:
> > --
> > |--- a/units/systemd-networkd-wait-online.service 2019-05-23
> 13:38:23.0 +0100
> > |+++ b/units/systemd-networkd-wait-online.service 2019-07-31
> 08:30:40.823968051 +0100
> > --
> > No file to patch. Skipping patch.
> > 1 out of 1 hunk ignored
> > Patch 0020-systemd-networkd-wait-online-service.patch does not apply
> (enforce with -f)
> >
> >
> >
> > My ./sources/poky/meta/recipes-core/systemd/systemd_234.bbappend
> consists of:
> >
> >
> > FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> > SRC_URI += "file://0020-systemd-networkd-wait-online-service.patch"
> >
> > My patch file:
> >
> > --- a/units/systemd-networkd-wait-online.service 2019-05-23
> 13:38:23.0 +0100
> > +++ b/units/systemd-networkd-wait-online.service 2019-07-31
> 08:30:40.823968051 +0100
> > @@ -16,7 +16,7 @@
> >
> > [Service]
> > Type=oneshot
> > -ExecStart=/lib/systemd/systemd-networkd-wait-online
> > +ExecStart=/lib/systemd/systemd-networkd-wait-online --any
> > RemainAfterExit=yes
> >
> > [Install]
> >
> >
> ---
> >
> >
> > So it finds the patch but struggles locating the service file to patch
> within the build. Any ideas where I'm going wrong?
> >
> > Is ./sources/poky/meta/recipes-core/systemd/systemd_234.bb the
> proper place to patch this service file?
> >
> >
> >
> > Regards,
> >
> >
> > Edward
> >
> >
> >
> >
> > This message and any attachment are confidential and may be privileged
> or otherwise protected from disclosure. If you are not the intended
> recipient, please telephone or email the sender and delete this message and
> any attachment from your system. If you are not the intended recipient you
> must not copy this message or attachment or disclose the contents to any
> other person.
> >
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Anyone tried to build and to use QUIC?
Hi Randy, On 8/2/19, Randy MacLeod wrote: > On 7/31/19 7:06 AM, JH wrote: >> Hi, >> >> I searched recipes for supporting QUIC, but could not find it. Has >> anyone tried to build and to use QUIC? >> >> Thank you. >> >> Kind regards, >> >> - JH >> > > Hi, > > I presume that you mean QUIC (Quick UDP Internet Connections) > as in: https://github.com/conght/quic Correct. > I also couldn't find an existing recipe using: > > https://layers.openembedded.org/layerindex/branch/master/recipes/?q=QUIC > > or by a general web search. > > Do you have a specific implementation in mind? I am looking for a small example of Linux C/C++ QUIC client / server program in socket level to replace TCP socket communication application. The client will run on an embedded system resource limited imx6 built from Yocto, the server is running in Ubuntu VM. > Care to write a recipe and send it in? > FYI: >http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded > > Alternatively contractors and companies are available if you want to go > that route. Absolutely, I am actually looking for that right now, contractors or companies have expertise in both QUIC and Yocto, please contact me. Appreciate recommendation of information for relevant contractors and companies. Thank you very much Randy. Kind regards, - JH -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] /var/volatile not mounted as tmpfs on read-only rootfs when migrating to Warrior
Hi, I have a working system based on Sumo. The system boots with a read-only rootfs, then applies are read-write overlay for /etc. When I migrate to Warrior, systemd-resolved fails to start. If I mount the same rootfs via NFS, it starts and works fine. systemd-timesyncd is also failing, but I haven't looked into that yet. It also works fine on the NFS mounted system. The resolve problem seems to be caused by two things: - /var/volatile is read-only - /run/systemd/resolve has the wrong ownership drwxr-xr-x 2 systemd-network systemd-journal 80 Jul 12 16:23 resolve/ I think this permissions problem may be a result of the /var/volatile mounting problems; it looks fine on the NFS mounted system. If I manually mount /var/volatile (it's in fstab) and change the ownership on /run/systemd/resolve, the service starts just fine. I also notice that /tmp is not mounted at all, which may be related. Here are the various tmp mount points on my read-only rootfs: $ mount | grep tmp devtmpfs on /dev type devtmpfs (rw,nosuid,size=112036k,nr_inodes=28009,mode=755) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755) tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755) overlay on /etc type overlay (rw,relatime,lowerdir=/tmp/lower/etc,upperdir=/tmp/upper/etc,workdir=/tmp/upper/work/etc) tmpfs on /run/user/0 type tmpfs (rw,nosuid,nodev,relatime,size=23840k,mode=700) On the NFS mounted system, I see these: $ mount | grep tmp devtmpfs on /dev type devtmpfs (rw,relatime,size=118180k,nr_inodes=29545,mode=755) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755) tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755) tmpfs on /tmp type tmpfs (rw,nosuid,nodev) tmpfs on /var/volatile type tmpfs (rw,relatime) tmpfs on /run/user/0 type tmpfs (rw,nosuid,nodev,relatime,size=23840k,mode=700) As you can see, NFS has these extra mounts: tmpfs on /tmp type tmpfs (rw,nosuid,nodev) tmpfs on /var/volatile type tmpfs (rw,relatime) I've tried reverting a few commits that may be related, but I haven't had any luck working out things have changed, eg: c4acf1b531 2018-10-19 volatile-binds: use overlayfs if available [Matt Hoosier] Advice would be appreciated. Are there any particular areas I should be looking to work out what's going wrong? Kind regards, Ryan. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Make the service the last run in boot
Terrific, that works well, thanks Rudolf and ChenQi. On 8/2/19, Rudolf J Streif wrote: > Adding > > After=multi-user.target > > to the [Unit] section in your systemd service file should do what you want. > > :rjs > > On 8/1/19 4:08 AM, JH wrote: >> The application requires network connection to communicate services >> via Internet, it could only work if the network connection is ready, >> so I really want to know which system servuce run at last I could put >> it in the After statement. >> >> On 8/1/19, ChenQi wrote: >>> On 08/01/2019 03:37 PM, JH wrote: Hi, How can I find the systemd last run service I can put it in my network application After=? I need my network application service to be run at last in boot, I made After=connman and Requires=connman.service that did not work, always failed in boot, I have to manually restart the network application service which won't work in field operation. >>> I'd suggest you find out what you network service actually require. >>> Searched from Internet, there is a blog Systemd: Run it last to create a custom.target After=multi-user.target, and put my network application service WantedBy=custom.target, that works well, but it is a little bit cumbersome to configure customer.target in Yocto bb file, enabling the customer.target is called systemctl isolate custom.target, the /etc/systemd/system/default.target link needs be changed to from multi-user.target to custom.target. I am not sure how it could be done in do_install, appreciate your tips. Thank you. Kind regards, - JH >>> >>> -- >>> ___ >>> yocto mailing list >>> yocto@yoctoproject.org >>> https://lists.yoctoproject.org/listinfo/yocto >>> > -- > - > Rudolf J Streif > CEO/CTO ibeeto > +1.855.442.3396 x700 > > > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
