Re: [OE-core] [oe] Any reasons not to use "newer" ppp?

On 30.06.2011 12:15, Phil Blundell wrote: > On Thu, 2011-06-30 at 12:12 +0200, Steffen Sledz wrote: >> The current oe-dev master contains recipes for 2.4.4 and 2.4.5, but both are >> DEFAULT_PREFERENCE = "-1", so 2.4.3 is used by default. >> >> We hit a proble

Re: [OE-core] [PATCH] ppp: sync packaging with OE .dev

Can you please resync again. Commit e05db51b7aea7a0359babd918d7efbb9cc213d83 introduces an own package for PPPoL2TP plugin. Adding that package fixes the following error message. NOTE: package ppp-2.4.5-r1: task do_qa_staging: Started WARNING: the following files were installed but

[OE-core] Uncommon source deployment policy of live555

The LIVE555 project has a really uncommon source deployment policy. :( They publish *only* the latest tarball of their code [1]. And they don't make the code available under a source code repository [2]. I've asked to change this policy but they are not willing to do that [3]. How can we handle

Re: [OE-core] Uncommon source deployment policy of live555

On 25.11.2011 12:21, Koen Kooi wrote: > > Op 25 nov. 2011, om 12:05 heeft Steffen Sledz het volgende geschreven: > >> The LIVE555 project has a really uncommon source deployment policy. :( >> >> They publish *only* the latest tarball of their code [1]. And they don&#x

[OE-core] layer priorities?

Just a few short questions about the layer priorities. May be there is an faq answering them, but i could not find it. What is the policy assigning a priority to a layer? Do multiple layers with the same priority are allowed? How is this handled? Would it make sense to add an *Layer prio* colum

Re: [OE-core] Uncommon source deployment policy of live555

On 26.11.2011 06:49, Khem Raj wrote: > On Fri, Nov 25, 2011 at 3:29 AM, Steffen Sledz wrote: >> On 25.11.2011 12:21, Koen Kooi wrote: >>> >>> Op 25 nov. 2011, om 12:05 heeft Steffen Sledz het volgende geschreven: >>> >>>> The LIVE555 projec

Re: [OE-core] Uncommon source deployment policy of live555

On 06.12.2011 08:07, Steffen Sledz wrote: > On 26.11.2011 06:49, Khem Raj wrote: >> On Fri, Nov 25, 2011 at 3:29 AM, Steffen Sledz wrote: >>> On 25.11.2011 12:21, Koen Kooi wrote: >>>> >>>> Op 25 nov. 2011, om 12:05 heeft Steffen Sledz het volgende geschr

[OE-core] SRC_URI and latest HEAD revision with git

After being OE abstinent for some months i'd like to ask what is the current suggested method for recipes building from the HEAD revision of a git repository (we need this for continuous integration). I read some RFC's in the ml about PKGV/PKGR stuff, but i miss a final decision, documentation

Re: [OE-core] SRC_URI and latest HEAD revision with git

On 22.07.2013 11:01, Nicolas Dechesne wrote: > On Mon, Jul 22, 2013 at 8:21 AM, Steffen Sledz <mailto:sl...@dresearch-fe.de>> wrote: >> After being OE abstinent for some months i'd like to ask what is the current >> suggested method for recipes building fr

Re: [OE-core] SRC_URI and latest HEAD revision with git

On 22.07.2013 11:51, Paul Eggleton wrote: > On Monday 22 July 2013 11:46:23 Steffen Sledz wrote: >> On 22.07.2013 11:01, Nicolas Dechesne wrote: >>> On Mon, Jul 22, 2013 at 8:21 AM, Steffen Sledz >> <mailto:sl...@dresearch-fe.de>> wrote: >>>> After b

Re: [OE-core] SRC_URI and latest HEAD revision with git

On 22.07.2013 13:08, Paul Eggleton wrote: > On Monday 22 July 2013 12:30:53 Steffen Sledz wrote: >> On 22.07.2013 11:51, Paul Eggleton wrote: >>> On Monday 22 July 2013 11:46:23 Steffen Sledz wrote: >>>> On 22.07.2013 11:01, Nicolas Dechesne wrote: >>>>

[OE-core] [PATCH] docbook-utils-native: fix syntax problem in jw.in

.mandriva.com/show_bug.cgi?id=61127> Signed-off-by: Steffen Sledz --- .../docbook-utils/docbook-utils-0.6.14/re.patch| 15 +++ .../docbook-utils/docbook-utils-native_0.6.14.bb |7 +-- 2 files changed, 20 insertions(+), 2 deletions(-) create mode 100644 meta/

[OE-core] [PATCH v2] docbook-utils-native: fix syntax problem in jw.in

.mandriva.com/show_bug.cgi?id=61127> Signed-off-by: Steffen Sledz --- .../docbook-utils/docbook-utils-0.6.14/re.patch| 29 .../docbook-utils/docbook-utils-native_0.6.14.bb |7 +++- 2 files changed, 34 insertions(+), 2 deletions(-) create mode 100644 meta/

Re: [OE-core] [PATCH v2] docbook-utils-native: fix syntax problem in jw.in

On 30.03.2012 11:45, Steffen Sledz wrote: > Fix runtime error occurred e.g. with docbook-to-man calls: > > grep: character class syntax is [[:space:]], not [:space:] > grep: character class syntax is [[:space:]], not [:space:] > jw: There is no frontend called "/

Re: [OE-core] Schizophrenic package management

On 03.04.2012 20:17, Mark Hatle wrote: > On 4/3/12 1:07 PM, Gary Thomas wrote: > ... > (And RedHat based linux distributions don't have any concept of alternatives. > They generally decide which binary package will provide the functionality > and that is the defacto standard for a given release. O

Re: [OE-core] [PATCH] dropbear: fix include dependent PR generation

On 22.05.2012 16:16, Steffen Sledz wrote: > Signed-off-by: Steffen Sledz > --- > meta/recipes-core/dropbear/dropbear.inc|2 ++ > meta/recipes-core/dropbear/dropbear_2012.55.bb |2 +- > 2 files changed, 3 insertions(+), 1 deletions(-) > > diff --git a/meta/

[OE-core] [PATCH] dropbear: fix include dependent PR generation

Signed-off-by: Steffen Sledz --- meta/recipes-core/dropbear/dropbear.inc|2 ++ meta/recipes-core/dropbear/dropbear_2012.55.bb |2 +- 2 files changed, 3 insertions(+), 1 deletions(-) diff --git a/meta/recipes-core/dropbear/dropbear.inc b/meta/recipes-core/dropbear/dropbear.inc

Re: [OE-core] [PATCH] dropbear: fix include dependent PR generation

On 23.05.2012 16:03, Saul Wold wrote: > On 05/23/2012 12:12 AM, Steffen Sledz wrote: >> On 22.05.2012 16:16, Steffen Sledz wrote: >>> Signed-off-by: Steffen Sledz >>> --- >>> meta/recipes-core/dropbear/dropbear.inc|2 ++ >>> meta/rec

Re: [OE-core] SRC_URI and latest HEAD revision with git (in oe-classic)

On 22.07.2013 11:51, Paul Eggleton wrote: > On Monday 22 July 2013 11:46:23 Steffen Sledz wrote: >> On 22.07.2013 11:01, Nicolas Dechesne wrote: >>> On Mon, Jul 22, 2013 at 8:21 AM, Steffen Sledz >> <mailto:sl...@dresearch-fe.de>> wrote: >>>> After b

Re: [OE-core] [oe] SRC_URI and latest HEAD revision with git (in oe-classic)

On 31.07.2013 14:50, Paul Eggleton wrote: > On Wednesday 31 July 2013 12:02:42 Steffen Sledz wrote: >> On 22.07.2013 11:51, Paul Eggleton wrote: >>> On Monday 22 July 2013 11:46:23 Steffen Sledz wrote: >>>> On 22.07.2013 11:01, Nicolas Dechesne wrote: >>>>

Re: [OE-core] [oe] SRC_URI and latest HEAD revision with git (in oe-classic)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01.08.2013 12:36, Martin Jansa wrote: > On Thu, Aug 01, 2013 at 08:11:48AM +0200, Steffen Sledz wrote: >> On 31.07.2013 14:50, Paul Eggleton wrote: >>> On Wednesday 31 July 2013 12:02:42 Steffen Sledz wrote: >> ... I read so

[OE-core] inc and bb vs. layers

Given to files foo.inc foo.bb (which requires foo.inc) in layer Foo. Now i want to write a new bar.bb (which requires foo.inc too) in layer Bar. Is this possible without keeping a copy of foo.inc in Bar? Steffen -- DResearch Fahrzeugelektronik GmbH Otto-Schmirgal-Str. 3, 10319 Berlin,

[OE-core] Profiling binaries?

Just a short question: Does oe[-core] provide a generic method to create packages containing binaries/libraries with profiling support? -- DResearch Fahrzeugelektronik GmbH Otto-Schmirgal-Str. 3, 10319 Berlin, Germany Tel: +49 30 515932-237 mailto:sl...@dresearch-fe.de Fax: +49 30 515932-299 Ges

Re: [OE-core] Profiling binaries?

On 22.10.2012 15:12, Samuel Stirtzel wrote: > 2012/10/22 Steffen Sledz : >> Just a short question: Does oe[-core] provide a generic method to create >> packages containing binaries/libraries with profiling support? >> > > Depending on your platform you could use

Re: [OE-core] [PATCH] u-boot.inc: update linker arguments to pass --sysroot arg (BUILD BREAKAGE)

On 29.07.2012 11:29, Richard Purdie wrote: > On Thu, 2012-07-26 at 11:21 -0500, Matthew McClintock wrote: >> If we are building from sstate-cache it's possible to be building >> from another folder on another machine, therefore the linker requires >> that a proper --sysroot is passed too it so it c

Re: [OE-core] [PATCH] u-boot.inc: update linker arguments to pass --sysroot arg (BUILD BREAKAGE)

On 29.10.2012 19:08, McClintock Matthew-B29882 wrote: > On Mon, Oct 29, 2012 at 9:36 AM, Matthew McClintock > wrote: >> On Mon, Oct 29, 2012 at 4:26 AM, Steffen Sledz wrote: >>> On 29.07.2012 11:29, Richard Purdie wrote: >>>> On Thu, 2012-07-26 at 11:21 -0500, M

[OE-core] [PATCH][for-dora] gdb-7.6: fix cygwin check in configure script

ned-off-by: Steffen Sledz --- meta/recipes-devtools/gdb/gdb-7.6.inc | 2 ++ .../gdb-fix-cygwin-check-in-configure-script.patch | 38 ++ 2 files changed, 40 insertions(+) create mode 100644 meta/recipes-devtools/gdb/gdb/gdb-fix-cygwin-check-in-configure-script.p

Re: [OE-core] [PATCH][for-dora] gdb-7.6: fix cygwin check in configure script

On 28.11.2013 15:09, Steffen Sledz wrote: > This is a fix which avoids false positives if the search pattern > "lose" is found in path descriptions in comments generated by the > preprocessor we hit in our development environment. > > [gdb Bug #16152] -- https:

Re: [OE-core] [PATCH][for-dora] gdb-7.6: fix cygwin check in configure script

On 10.12.2013 10:15, Robert Yang wrote: > Thanks, applied to dora-next. Great. Thanx. Just for my understanding. May be i somehow overlooked relevant announcements. * Where is the dora-next branch available (not at git://git.openembedded.org/openembedded-core if i'm looking right)? * And what i

[OE-core] opencv QA issue

After the latest update of our build host (Fedora-18) the opencv build fails with an QA issue. -> snip <- ERROR: QA Issue: non debug package contains .debug directory: opencv-apps path /work/cortexa9hf-vfp-neon-angstrom-linux-gnueabi/opencv/2.4.6+gitAUTOINC+c5afaa4e8d-r0/

Re: [OE-core] [PATCH] local.conf.sample: Add automatic defaults for BB_NUMBER_THREADS and PARALLEL_MAKE

On 27.01.2014 15:39, Richard Purdie wrote: > Its rather sad that people don't appear to read local.conf and then complain > about slow builds when they're just using a single thread. Most systems have > more than one core now so we might as well use a more automatic default > for these values. This

Re: [OE-core] [PATCH] local.conf.sample: Add automatic defaults for BB_NUMBER_THREADS and PARALLEL_MAKE

On 29.01.2014 11:22, Paul Eggleton wrote: > On Wednesday 29 January 2014 11:14:47 Steffen Sledz wrote: >> On 27.01.2014 15:39, Richard Purdie wrote: >>> Its rather sad that people don't appear to read local.conf and then >>> complain about slow builds when they

Re: [OE-core] [PATCH] local.conf.sample: Add automatic defaults for BB_NUMBER_THREADS and PARALLEL_MAKE

On 29.01.2014 11:59, Richard Purdie wrote: > On Wed, 2014-01-29 at 11:14 +0100, Steffen Sledz wrote: >> On 27.01.2014 15:39, Richard Purdie wrote: >>> Its rather sad that people don't appear to read local.conf and then complain >>> about slow builds when they

Re: [OE-core] [PATCH] local.conf.sample: Add automatic defaults for BB_NUMBER_THREADS and PARALLEL_MAKE

On 29.01.2014 12:52, Paul Eggleton wrote: > On Wednesday 29 January 2014 12:47:54 Steffen Sledz wrote: >> On 29.01.2014 11:59, Richard Purdie wrote: >>> On Wed, 2014-01-29 at 11:14 +0100, Steffen Sledz wrote: >>>> On 27.01.2014 15:39, Richard Purdie wrote: >>

[OE-core] [PATCH] lighttpd: introduce /etc/lighttpd.d subdir for config file includes

Extend default config file by a directive to include config file fragments from /etc/lighttpd.d. This allows other web application packages to put their configuration there. Signed-off-by: Steffen Sledz --- meta/recipes-extended/lighttpd/lighttpd/lighttpd.conf | 3 +++ meta/recipes-extended

Re: [OE-core] [PATCH] lighttpd: introduce /etc/lighttpd.d subdir for config file includes

On 11.02.2014 09:59, Steffen Sledz wrote: > Extend default config file by a directive to include config file > fragments from /etc/lighttpd.d. This allows other web application > packages to put their configuration there. > > Signed-off-by: Steffen Sledz > --- > meta/reci

[OE-core] complex versioning scenario

We've a complex versioning scenario here which leads me to my limits. :( There are two recipes. One for a shared library and one for an application using this library. Both use GNU autotools (so they have internal version information). For continuous integration purposes both use AUTOREV. At t

Re: [OE-core] complex versioning scenario

On 24.03.2014 13:35, Richard Purdie wrote: > On Mon, 2014-03-24 at 13:16 +0100, Steffen Sledz wrote: >> We've a complex versioning scenario here which leads me to my limits. :( >> >> There are two recipes. One for a shared library and one for an application >> us

Re: [OE-core] complex versioning scenario

On 24.03.2014 13:53, Richard Purdie wrote: > On Mon, 2014-03-24 at 13:49 +0100, Steffen Sledz wrote: >> On 24.03.2014 13:35, Richard Purdie wrote: >>> On Mon, 2014-03-24 at 13:16 +0100, Steffen Sledz wrote: >>>> We've a complex versioning scenar

Re: [OE-core] complex versioning scenario

On 24.03.2014 16:15, Martin Jansa wrote: > On Mon, Mar 24, 2014 at 03:22:35PM +0100, Steffen Sledz wrote: >> On 24.03.2014 13:53, Richard Purdie wrote: >>> On Mon, 2014-03-24 at 13:49 +0100, Steffen Sledz wrote: >>>> On 24.03.2014 13:35, Richard Purdie wrote: >

Re: [OE-core] complex versioning scenario

On 25.03.2014 16:03, Mark Hatle wrote: > On 3/25/14, 5:31 AM, Steffen Sledz wrote: >> On 24.03.2014 16:15, Martin Jansa wrote: >>> On Mon, Mar 24, 2014 at 03:22:35PM +0100, Steffen Sledz wrote: >>>> On 24.03.2014 13:53, Richard Purdie wrote: >>>>> On

Re: [OE-core] complex versioning scenario

On 07.04.2014 14:37, Steffen Sledz wrote: > On 25.03.2014 16:03, Mark Hatle wrote: >> ... >> If the package 'requiring libfoo' has a DEPENDS += ... in it.. then yes, it >> should have been rebuilt when the libfoo was rebuilt. > > Unfortunately i can't c

Re: [OE-core] complex versioning scenario

On 07.04.2014 16:49, Richard Purdie wrote: > On Mon, 2014-04-07 at 15:22 +0200, Steffen Sledz wrote: >> On 07.04.2014 14:37, Steffen Sledz wrote: >>> On 25.03.2014 16:03, Mark Hatle wrote: >>>> ... >>>> If the package 'requiring libfoo' has a D

Re: [OE-core] complex versioning scenario

Am 08.04.2014 19:20, schrieb Khem Raj: > On Tue, Apr 8, 2014 at 5:33 AM, Steffen Sledz wrote: >> If a package contains a shared library *and* a binary (e.g. a related >> command line tool) then the soname major version *is not appended* to the >> package name (see debian

[OE-core] ^{} what is it good for? (bitbake problem)

We're are currently switching to daisy (incl. bitbake 1.22). There we hit the following problem. We've a bbappend for linux-yocto-3.10 containing --> snip <- SRC_URI += " \ git://github.com/DFE/darmok.git;destsuffix=darmok;type=not-kmeta;tag=darmok_v0.10 \ " --

Re: [OE-core] ^{} what is it good for? (bitbake problem)

On 04.06.2014 10:29, Olof Johansson wrote: > On 14-06-04 10:06 +0200, Steffen Sledz wrote: >> So what is this ^{} which comes from lib/bb/fetch2/git.py good for? >> Or is this a remnant from a typo? > > From git-rev-parse(1): > > ^{}, e.g. v0.99.8^{} > A

[OE-core] No recipe for recipes-tweaks/qt5/qtbase_5.2.1.bbappend

We're currently switching to th daisy branches. According to [1] meta-angstrom depends on openembedded-core, meta-oe, and meta-systemd layers. The angstrom-v2014.06-yocto1.6 branch of meta-angstrom contains recipes-tweaks/qt5/qtbase_5.2.1.bbappend. But there's no qtbase recipe in the required

[OE-core] [meta-oe][daisy][PATCH] live555: fix fetch problem

live.2013.04.30.tar.gz is no longer available at original live555 url and the url of the FreeBSD mirror has changed according to[1]. [1] <http://ftp.freebsd.org/pub/FreeBSD/ports/distfiles/README.txt> Signed-off-by: Steffen Sledz --- meta-oe/recipes-multimedia/live555/live555.inc | 4 +

Re: [OE-core] [meta-oe][daisy][PATCH] live555: fix fetch problem

What is the right ML address for patches in this area? The meta-multimedia/README in git://git.openembedded.org/meta-openembedded (daisy branch) says: "Send pull requests to openembedded-de...@lists.openembedded.org" But i believe this should be openembedded-core@lists.openembedded.org. Stef

Re: [OE-core] [meta-oe][daisy][PATCH] live555: fix fetch problem

On 16.06.2014 10:48, Paul Eggleton wrote: > On Monday 16 June 2014 08:32:55 Steffen Sledz wrote: >> What is the right ML address for patches in this area? >> >> The meta-multimedia/README in git://git.openembedded.org/meta-openembedded >> (daisy branch) says: >

Re: [OE-core] [meta-oe][daisy][PATCH] live555: fix fetch problem

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 16.06.2014 12:59, Martin Jansa wrote: > On Mon, Jun 16, 2014 at 11:45:12AM +0200, Steffen Sledz wrote: >> On 16.06.2014 10:48, Paul Eggleton wrote: >>> On Monday 16 June 2014 08:32:55 Steffen Sledz wrote: >>>> Wh

[OE-core] Ralink RT3572/RT5572?

Are the linux kernel modules for Ralink WiFi-USB devices with RT3572 and/or RT5572 (available from ) still integrated in an OE-Layer? If not, what would be the right place for them (openembedded-core, meta-networking, or something else)? -- DResearch Fah

Re: [OE-core] Ralink RT3572/RT5572?

On 11.08.2014 11:53, Steffen Sledz wrote: > Are the linux kernel modules for Ralink WiFi-USB devices with RT3572 and/or > RT5572 (available from <http://www.mediatek.com/en/downloads/>) still > integrated in an OE-Layer? > > If not, what would be the right place for th

[OE-core] hash generation for PR Service?

I'm not sure if this is the right mailing list for our problem. Please forgive me if not (and tell me the right one). We're investigating some problems related with package versions going backwards using a PR Service[1]. Can someone give some hints where we can get information about generation

Re: [OE-core] hash generation for PR Service?

On 10.09.2014 13:24, Steffen Sledz wrote: > I'm not sure if this is the right mailing list for our problem. Please > forgive me if not (and tell me the right one). > > > We're investigating some problems related with package versions going > backwards using a PR

[OE-core] hash generation/PR service problem with xuser-account and other packages

As i mentioned in another thread before we're investigating some problems related with package versions going backwards using a PR service. Now i have some more information. But i'm not able to understand and fix the problem for myself. Assume we have a clean workspace and i bitbake the xuser-a

Re: [OE-core] hash generation/PR service problem with xuser-account and other packages

On 23.09.2014 15:21, Richard Purdie wrote: > On Tue, 2014-09-23 at 14:07 +0200, Steffen Sledz wrote: >> As i mentioned in another thread before we're investigating some problems >> related with package versions going backwards using a PR service. >> >> Now i hav

Re: [OE-core] hash generation/PR service problem with xuser-account and other packages

On 23.09.2014 18:16, Richard Purdie wrote: > On Tue, 2014-09-23 at 16:51 +0200, Steffen Sledz wrote: >> Hi Richard, thanx for this detailled explanation. It is another step on my >> way to understand all this. ;-) >> >>> The other recipes will need investigatin

[OE-core] [daisy][PATCH 3/3] layer.conf: Mark opkg-utils as ABISAFE for update-alternatives usage

Currently linux-firmware rebuilds for each machine due to its usage of update-alternatives which in turn means a dependency on opkg-utils. Marking opkg-utils as ABISAFE is the only option we have right now to avoid this. Signed-off-by: Richard Purdie Signed-off-by: Steffen Sledz --- meta/conf

[OE-core] [daisy][PATCH 1/3] layer.conf: Add in useradd dependencies as ABISAFE dependencies

Currently allarch recipes using useradd rebuild each time MACHINE changes which is not desireable. Adding the useradd dependencies to this list ensures they do not change under these circumstances. Signed-off-by: Richard Purdie Signed-off-by: Steffen Sledz --- meta/conf/layer.conf | 4 1

[OE-core] [daisy][PATCH 2/3] update-rc.d/systemd: Remove OVERRIDES dependency

low a single package to be generated for run-postinsts. Signed-off-by: Richard Purdie Signed-off-by: Steffen Sledz --- meta/classes/systemd.bbclass | 1 + meta/classes/update-rc.d.bbclass | 1 + 2 files changed, 2 insertions(+) diff --git a/meta/classes/systemd.bbclass b/meta/cl

[OE-core] "qemu-arm udevadm hwdb --update" eats swap space after build host update to openSUSE 13.2

After updating our build host from openSUSE 13.1 to 13.2 we're no longer able to build our images with OE (with 13.1 on the same host everything worked well). :( The first thing we observed was that the do_rootfs stage made a very big load (more than 500) on the machine but the cpu's aren't wor

Re: [OE-core] "qemu-arm udevadm hwdb --update" eats swap space after build host update to openSUSE 13.2

On 15.12.2014 12:00, Gaurang Shastri wrote: > From: openembedded-core-boun...@lists.openembedded.org > [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of > Steffen Sledz >> After updating our build host from openSUSE 13.1 to 13.2 we're no longer >>

Re: [OE-core] "qemu-arm udevadm hwdb --update" eats swap space after build host update to openSUSE 13.2

On 15.12.2014 12:00, Gaurang Shastri wrote: > From: openembedded-core-boun...@lists.openembedded.org > [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of > Steffen Sledz >> After updating our build host from openSUSE 13.1 to 13.2 we're no longer >>

Re: [OE-core] "qemu-arm udevadm hwdb --update" eats swap space after build host update to openSUSE 13.2

On 15.12.2014 17:19, Enrico Scholz wrote: > Steffen Sledz writes: > >> The first thing we observed was that the do_rootfs stage made a very >> big load (more than 500) on the machine but the cpu's aren't working >> for 100%. I could track down the problem to

[OE-core] GPSD time will jump back 1024 weeks at after week=2180 (23-October-2021)

There is a dirty gpsd bug (see https://gitlab.com/gpsd/gpsd/-/issues/144) which is fixed in the latest version 3.23 from yesterday. Is anyone already working on updating the bitbake recipe accordingly? -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online

Re: [OE-core] GPSD time will jump back 1024 weeks at after week=2180 (23-October-2021)

Am 7. August 2021 13:35:19 MESZ schrieb Otavio Salvador > >I am not; but from discussion with upstream it seems to need to be >ported down to 3.20 gpsd. Why not switch Tod 3.23? -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#154581): https://l

[OE-core] fetch race problem

We hit the following problem in oe-classic. And we're not sure if this problem may occur in current oe too, or if it is fixed there. They are two or more recipes (may be in different layers) for packages with sources from the same (git) repository. If the fetching from the repo needs some time

Re: [OE-core] fetch race problem

Am 24.03.2015 um 12:12 schrieb Richard Purdie: > On Tue, 2015-03-24 at 12:00 +0100, Steffen Sledz wrote: >> We hit the following problem in oe-classic. And we're not sure if this >> problem may occur in current oe too, or if it is fixed there. >> >> They ar

[OE-core] [fido] orphaned bbappend in meta-angstrom

The angstrom-v2015.06-yocto1.8 branch of meta-angstrom contains recipes-tweaks/linux/linux-yocto_3.10.bbappend. But the fido branch of openembedded-core does not have a recipe for linux-yocto_3.10 (just 3.14 and 3.19). So the bbappend should be removed or updated. Regards, Steffen -- DResear

Re: [OE-core] [fido] orphaned bbappend in meta-angstrom

On 30.04.2015 08:07, Steffen Sledz wrote: > The angstrom-v2015.06-yocto1.8 branch of meta-angstrom contains > recipes-tweaks/linux/linux-yocto_3.10.bbappend. But the fido branch of > openembedded-core does not have a recipe for linux-yocto_3.10 (just 3.14 and > 3.19). > &g

Re: [OE-core] opkg_install_pkg: Package md5sum mismatch. Either the opkg or the package index are corrupt.

Am 02.05.2015 um 23:55 schrieb Andrea Adami: > On Fri, May 1, 2015 at 6:06 PM, Denys Dmytriyenko wrote: >> Has anyone ever seen this message during .do_rootfs task? >> >> Collected errors: >> * opkg_install_pkg: Package md5sum mismatch. Either the opkg or >> the package index are corrupt. Try '

[OE-core] WARNING: The license listed CLOSED was not in the licenses collected for foo

Since switching from dizzy to fido we've some warnings related to some of our own closed source packages. WARNING: log_check: There is a warn message in the logfile WARNING: log_check: Matched keyword: [WARNING:] WARNING: log_check: WARNING: The license listed CLOSED was not in the licenses coll

Re: [OE-core] WARNING: The license listed CLOSED was not in the licenses collected for foo

On 08.05.2015 14:39, Paul Eggleton wrote: > Hi Steffen, > > On Friday 08 May 2015 13:07:35 Steffen Sledz wrote: >> Since switching from dizzy to fido we've some warnings related to some of >> our own closed source packages. >> >> WARNING: log_check:

Re: [OE-core] [PATCH] license_class: Add explicity avoid of CLOSED license in validations

On 18.05.2015 22:33, Aníbal Limón wrote: > The CLOSED license isn't a generic license it is a set and can > be any closed source license. > > [YOCTO #7752] > > Signed-off-by: Aníbal Limón > --- > meta/classes/license.bbclass | 10 -- > 1 file changed, 8 insertions(+), 2 deletions(-) >

Re: [OE-core] [FIDO][PATCH] license_class: Add explicity avoid of CLOSED license in validations

On 18.05.2015 21:17, Aníbal Limón wrote: > The CLOSED license isn't a generic license it is a set and can > be any closed source license. > > [YOCTO #7752] > > Signed-off-by: Aníbal Limón > --- > meta/classes/license.bbclass | 11 +-- > 1 file changed, 9 insertions(+), 2 deletions(-) >

[OE-core] systemd service vs. update-alternatives (was rsyslog: buggy systemd/ua handling?)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 18.11.2015 17:14, Steffen Sledz wrote: > On 17.11.2015 09:08, Steffen Sledz wrote: >> On 16.11.2015 12:28, Steffen Sledz wrote: >>> I'm not sure but i believe there's a bug in the systemd/ua-handling in >>

Re: [OE-core] systemd service vs. update-alternatives (was rsyslog: buggy systemd/ua handling?)

On 20.11.2015 10:06, ChenQi wrote: > I sent out a series of patches regarding syslog & systemd some time ago. > The title is "[OE-core] [PATCH V3 0/4] Fixes for systemd services in systemd". > Codes regarding update-alternatives and syslog for 'rsyslog' recipe is > actually part of the whole fix.

Re: [OE-core] systemd service vs. update-alternatives (was rsyslog: buggy systemd/ua handling?)

On 20.11.2015 14:42, Steffen Sledz wrote: > PS: What's the better place for this discussion? This mailing list? Or > <https://bugzilla.yoctoproject.org/show_bug.cgi?id=8688>? Ping! -- DResearch Fahrzeugelektronik GmbH Otto-Schmirgal-Str. 3, 10319 Berlin, Germany Tel:

[OE-core] fido -> jethro switching problem

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, for our internal development we use the Angstrom distro with some additional layers. Now we try to switch from fido to jethro branches and hit a problem where we are overchallenged. Our local.conf contains DISTRO_FEATURES_remove = "x11 w

Re: [OE-core] fido -> jethro switching problem

On 15.01.2016 14:06, Richard Purdie wrote: > On Fri, 2016-01-15 at 13:03 +0100, Steffen Sledz wrote: >> Hi all, >> >> for our internal development we use the Angstrom distro with some >> additional layers. Now we try to switch from fido to jethro branches >&g

Re: [OE-core] fido -> jethro switching problem

On 15.01.2016 14:24, Steffen Sledz wrote: > And I made another interesting discovery: The exception appears on certain > machine types only, e.g with qemuarm it appears, with qemuarm64 or qemux86 > not. It seems that all machines based on armv5e are affected. -- DResearch Fahrzeuge

Re: [OE-core] fido -> jethro switching problem

On 15.01.2016 15:29, Koen Kooi wrote: >> Op 15 jan. 2016 om 15:26 heeft Steffen Sledz het >> volgende geschreven: >> It seems that all machines based on armv5e are affected. > > FWIW, I'm seeing the same problem. The last time it happened it was due to > the fi

Re: [OE-core] fido -> jethro switching problem

On 18.01.2016 09:41, Koen Kooi wrote: >> Op 18 jan. 2016, om 09:28 heeft Steffen Sledz het >> volgende geschreven: >> On 15.01.2016 15:29, Koen Kooi wrote: >>>> Op 15 jan. 2016 om 15:26 heeft Steffen Sledz het >>>> volgende geschreven: >>&

Re: [OE-core] fido -> jethro switching problem

On 15.01.2016 15:29, Koen Kooi wrote: >> Op 15 jan. 2016 om 15:26 heeft Steffen Sledz het >> volgende geschreven: >>> On 15.01.2016 14:24, Steffen Sledz wrote: >>> And I made another interesting discovery: The exception appears on certain >>> machine

[OE-core] defining default locale (LANG/LC_ALL)

May be this is a FAQ, but I could not find any helpful documentation. What is the best way to define a system wide default locale setting (LANG and LC_ALL) for OE based Angstrom style images? Regards, Steffen -- DResearch Fahrzeugelektronik GmbH Otto-Schmirgal-Str. 3, 10319 Berlin, Germany Tel

Re: [OE-core] defining default locale (LANG/LC_ALL)

On 26.09.2016 13:01, Maciej Borzęcki wrote: > On Mon, Sep 26, 2016 at 12:46 PM, Steffen Sledz wrote: >> May be this is a FAQ, but I could not find any helpful documentation. >> >> What is the best way to define a system wide default locale setting (LANG >> and LC_ALL)

Re: [OE-core] [meta-qt5][fido] commit 699e1570e6 breaks build

On 28.05.2015 11:48, Richard Purdie wrote: > On Thu, 2015-05-28 at 11:39 +0200, Steffen Sledz wrote: >> Commit 699e1570e66cb28e4bfd0eb15d41f3af2bed5b62 (autotools: Fix find >> races on source directory) in fido branch of openembedded-core breaks >> build (do_configure) of qt

[OE-core] multiple git repos vs. AUTOREV?

For development purposes we use this method to build always from the HEAD revision of a git repository. -> snip <-- SRCREV="${AUTOREV}" PV = "gitr${SRCPV}" SRC_URI = "git://g...@bitbucket.org/.../foo.git;protocol=ssh" -> snap <-- Now we like to do

Re: [OE-core] multiple git repos vs. AUTOREV?

On 16.06.2015 16:20, Paul Eggleton wrote: > On Tuesday 16 June 2015 16:12:49 Steffen Sledz wrote: >> For development purposes we use this method to build always from the HEAD >> revision of a git repository. >> ... >> Now we like to do the same in one recipe whic

Re: [OE-core] multiple git repos vs. AUTOREV?

On 17.06.2015 10:10, Richard Purdie wrote: > On Wed, 2015-06-17 at 09:27 +0200, Steffen Sledz wrote: >> On 16.06.2015 16:20, Paul Eggleton wrote: >>> On Tuesday 16 June 2015 16:12:49 Steffen Sledz wrote: >>>> For development purposes we use this method to build alwa

Re: [OE-core] multiple git repos vs. AUTOREV?

On 17.06.2015 12:09, Steffen Sledz wrote: > On 17.06.2015 10:10, Richard Purdie wrote: >> On Wed, 2015-06-17 at 09:27 +0200, Steffen Sledz wrote: >>> On 16.06.2015 16:20, Paul Eggleton wrote: >>>> On Tuesday 16 June 2015 16:12:49 Steffen Sledz wrote: >>>

[OE-core] outdated compat-wireless

meta-openembedded contains a recipe for compat-wireless. According to [1] this is really outdated and replaced by a renamed project called backports[2]. Has anyone tried or plans to replace compat-wireless with this? [1] [2]

[OE-core] "sub" machine types?

We have some products which differ in bootloaders (u-boot) and kernel device trees only. They use the same kernel and root filesystem. Does OE have concepts for this? Or any suggestions to realize this without building for many machines? Steffen -- DResearch Fahrzeugelektronik GmbH Otto-Schmi

Re: [OE-core] [oe] "sub" machine types?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 04.09.2015 um 09:45 schrieb Nicolas Dechesne: > On Fri, Sep 4, 2015 at 9:35 AM, Steffen Sledz wrote: >> We have some products which differ in bootloaders (u-boot) and kernel device >> trees only. They use the same kernel and

Re: [OE-core] "sub" machine types?

On 05.09.2015 13:29, Mike Looijmans wrote: > ... and I think the u-boot recipe recently learned to have multiple targets, > so you can build multiple bootloaders for a single machine too. That sounds great. Can someone give a pointer to some documentation or examples for that? -- DResearch Fah

Re: [OE-core] "sub" machine types?

On 07.09.2015 09:09, Steffen Sledz wrote: > On 05.09.2015 13:29, Mike Looijmans wrote: >> ... and I think the u-boot recipe recently learned to have multiple targets, >> so you can build multiple bootloaders for a single machine too. > > That sounds great. Can someone g

Re: [OE-core] "sub" machine types?

On 07.09.2015 16:24, Lee Nipper wrote: > > On Mon, Sep 7, 2015 at 7:08 AM, Steffen Sledz <mailto:sl...@dresearch-fe.de>> wrote: > > On 07.09.2015 09:09, Steffen Sledz wrote: > > On 05.09.2015 13:29, Mike Looijmans wrote: > >> ... and I think t

[OE-core] cups-filters

Does anybody know about a recipe providing cups-filters? http://layers.openembedded.org was not really helpful here. -- DResearch Fahrzeugelektronik GmbH Otto-Schmirgal-Str. 3, 10319 Berlin, Germany Tel: +49 30 515932-237 mailto:sl...@dresearch-fe.de Fax: +49 30 515932-299 Geschäftsführer: Dr. M

Re: [OE-core] [oe] cups-filters

On 22.10.2015 09:50, Richard Leitner wrote: > On 10/21/2015 04:01 PM, Steffen Sledz wrote: >> Does anybody know about a recipe providing cups-filters? >> >> http://layers.openembedded.org was not really helpful here. > > I have one which works for my purposes but it i

  1   2   >