dlt-daemon:

[LocutusOfBorg]

• add patch to fix build with musl libc,
• refresh patch 0004-Modify-systemd-config-directory.patch to unfuzz it
• tweak patch 0002-Don-t-execute-processes-as-a-specific-user.patch to add a missing removal of DLT_USER occurrence

Signed-off-by: Gianfranco Costamagna costamagnagianfranco@yahoo.it

[gunnarx]

Thanks for the PR and the heads-up @LocutusOfBorg, @kraj
I had not seen it and no one mentioned it before - I have limited time to track the oe mailing list, but I found the proposal in the archive now. Even if it would be nice to have some conversation about it first... I do think this is a good idea... DLT could be available to a wider embedded audience this way.

We should also tell the dlt-daemon maintainer about this. --> for your information @ssugiura.

I was going to say that these patches should not be added, but instead fixed upstream in https://github.com/GENIVI/dlt-daemon project, but I can see you have sent at least one there too. Thanks.

Concerning this PR, I think we might wait with these patches a while and rather update to the newer dlt-daemon, to reduce the churn and effort. Actually, since meta-ivi officially depends on meta-openembedded the component should presumably be dropped from meta-ivi once updated to the latest branches of poky and meta-openembedded (which is dragging behind due to limited input/resource).

[ssugiura]

@LocutusOfBorg @kraj I merged 204.patch to dlt-daemon repository which you raised in the repo as a PR. So the patch can be removed from this PR. If you have any other changes which should be changed in general, please raise another PR to dlt-daemon git repo.
@gunnarx Thanks for notification.

[kraj]

@LocutusOfBorg @kraj I merged 204.patch to dlt-daemon repository which you raised in the repo as a PR. So the patch can be removed from this PR. If you have any other changes which should be changed in general, please raise another PR to dlt-daemon git repo.
@gunnarx Thanks for notification.

Thanks, this will happen when the recipe is updated to latest srcrev next time.

[LocutusOfBorg]

The reason for fixing this recipe, and moving to meta-oe is that I want to enable support for dlt-daemon in mosquitto, something really useful to have, and mosquitto is in meta-oe!

Feel free to drop this recipe from meta-ivi once meta-oe is updated to the next yocto stable!

For now @ssugiura I can't drop the patch because I prefer to avoid tracking "unstable" dlt-daemon releases (not tagged).

Please have a look at the other two patches, I'm not the author for them, and I don't want to open PR requests for code I don't really understand!

[slawr]

I think discussion would be required before dropping dlt recipes from meta-ivi.

[gunnarx]

To summarize, again we should hold on merging this. There is no major rush and various layer/branch updates are really required first...

@slawr Happy to discuss. I just believe that meta-ivi already depends on meta-openembedded i.e. you cannot really build it without it. So I saw little risk that projects depend on meta-ivi and not depend on meta-openembedded - thus little risk to drop the recipe. It's not by choice, but it seems to me that the recent meta-openembedded addition is forcing our hand here. Of course only as part of a larger upgrade.

One aspect would be what the future update/maintenance will be like. @LocutusOfBorg, @kraj, will you track the component and update the recipe in the future, when new tags appear?

Another reason this is not a risk for breaking a lot of things is that dropping the recipe is part of a larger update I wrote. It cannot be done without also updating the layers first.

Also given some time, dlt-daemon will be tagged again including the change, and then it is time to update the component again. Therefore, overall, I would propose to not merge this PR in meta-ivi yet.

[gunnarx]

@LocutusOfBorg Regarding 1c98eab, could you help me with information or reference to discussion on Yocto only "allowing" (otherwise warning) git as source?

Overall it is a reasonable idea, but it might affect efficient local caching of the sources.
More importantly, I am wondering about the BB_NO_NETWORK setting - I have found it to simply not work correctly before when using a git source? (bitbake would always go to the URL check if the repo was updated, even for tags, because git tags can theoretically be changed).

EDIT: Ah, I see the message now. Yes, the GitHub archives are unstable. I misunderstood the summary.

[LocutusOfBorg]

sorry, I don't see the problem in having the same recipe in two layers.

The layer has to be in meta-oe, because I would like to enable (selectively) dlt features on packages supporting it (as I did for mosquitto), and meta-oe can't really depend on meta-ivi.

Moreover, this pull request fixes lots of issues:

1. incomplete patch
2. build failure with musl c
3. builds only if systemd is enabled
4. don't use github archives to download, because they are auto-generated and regenerated from time to time with different hashes.

I propose to merge this one, so there is no difference between the two layers, and in the future we can discuss about dropping this one, or keeping them both (in case diverge) and let the user decide which one to pick up based on layer priorities.

In any case, this PR makes it behave and compiler better.

[LocutusOfBorg]

Sorry @gunnarx I answered before reading the new comment...
I found this discussion
https://yocto.yoctoproject.narkive.com/CHumkran/meta-raspberrypi-patch-firmware-inc-fetch-a-zip-instead-of-cloning-a-git-repo

but I don't remember where and when they have been changed, but right now, no new PR can use github tarballs anymore since one year or so...
Will try to find something via git log

[LocutusOfBorg]

commit 8b5ebbf6e6f2628aa3e165b89772c40ea20185df
Author: Khem Raj <raj.khem@gmail.com>
Date:   Sun Jun 16 22:21:58 2019 -0700

    stressapptest: Use git SHA instead of git archive
    
    git archives get regenerated randomly so lets use git fetcher instead

[LocutusOfBorg]

commit d776e6e353ba2f34b2fef6b83a887735e85b9f1f
Author: Martin Jansa <martin.jansa@gmail.com>
Date:   Fri May 17 21:49:19 2019 +0000

    triggerhappy: fix issues
    
    * using PN instead of BPN in S causes all tasks to fail:
      make: *** No targets specified and no makefile found.  Stop.
    * using github archives is bad, because they are regenerated from time to time
      with different checksums

[LocutusOfBorg]

In zeus migration guide:
https://github.com/mendersoftware/poky/blob/master/documentation/ref-manual/migration.xml

                    <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link>
                    is now checked for usage of two problematic items:
                    <itemizedlist>
                        <listitem><para>
                            "${PN}" prefix/suffix use - Warnings always appear
                            if ${PN} is used.
                            You must fix the issue regardless of whether
                            multiconfig or anything else that would cause
                            prefixing/suffixing to happen.
                            </para></listitem>
                        <listitem><para>
                            Github archive tarballs - these are not guaranteed
                            to be stable.
                            Consequently, it is likely that the tarballs will
                            be refreshed and thus the SRC_URI checksums
                            will fail to apply.
                            It is recommended that you fetch either an official
                            release tarball or a specific revision from the
                            actual Git repository instead.
                            </para></listitem>
                    </itemizedlist>
                    Either one of these items now trigger a warning by default.
                    If you wish to disable this check, remove
                    <filename>src-uri-bad</filename> from
                    <link linkend='var-WARN_QA'><filename>WARN_QA</filename></link>.
                    </para></listitem>

[gunnarx]

sorry, I don't see the problem in having the same recipe in two layers.

Sure, Yocto/bitbake has a lot of ways to control this of course, layer priorities, and other ways to state the intention. I was just anticipating that the building of our meta-ivi images are likely to need some changes to avoid any conflict. If I am right that all relevant (*meta-ivi dependent) builds have both layers then I think keeping only one copy of the recipe is the long term solution.

... and meta-oe can't really depend on meta-ivi.

Agreed, but I would rather say it would be mosquitto that would depend on meta-ivi to get the dlt recipe to solve your particular situation?

The layer has to be in meta-oe, because I would like to enable (selectively) dlt features on packages supporting it (as I did for mosquitto),

If I understand, you are suggesting that there are other projects (outside meta-ivi) that depend on dlt-daemon. That's fair enough. And I would encourage the possibility for that to grow, so I think it is a good idea. Overall I understand your need, and since it is merged already I think it is not worth discussing more.

[gunnarx]

Re: unstable github tarballs, yes we have been bitten by this a few times also. I support the change.

[gunnarx]

... in fact come to think of it I made an investigation into the GitHub tarballs a few years ago and shared this with the Yocto community when this problem was not known by everyone at least (I forget the exact place but there was at least a bug report and IRC discussion involved, and possibly a mailing list thread).

[LocutusOfBorg]

Everything in meta-oe can be reverted in case, please don't be scared of a patch being accepted :)

Having a mosquitto feature that depends on an external layer might also be a good solution, as well has adding dlt in DISTRO_FEATURES maybe...
what do you think?
I'm open and I can write the code once we all agree on a good solution!

[gunnarx]

It builds OK, so I think we can merge to master, based on the discussion we have had.
One more check with @slawr first (should be at the latest wednesday next week)

[gunnarx]

@LocutusOfBorg merging this now.