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] 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] devshell problems after distro upgrade openSUSE Leap 42.3 -> 15.0 (tmux only)

On 13.12.18 16:17, Mike Crowe wrote: > This was deemed a bug by tmux upstream and fixed there: > > https://github.com/tmux/tmux/issues/1549 > > I reported the bug to Debian, who applied the fix on top of 2.8: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914816 Filed a bug for openSUS

Re: [OE-core] Dependency loops when enabling ptest with Ångström

On 06.09.2018 09:20, Steffen Sledz wrote: > Koen/Khem, can someone of you please remove the dependency in all relevant > branches (rocko, sumo, master?)! I've create to pull requests for this in Github. <https://github.com/Angstrom-distribution/meta-angstrom/pull/16> &l

Re: [OE-core] Dependency loops when enabling ptest with Ångström

On 06.09.2018 09:15, ChenQi wrote: > I tried to find your repo but failed. The meta-angstrom layer in > meta-opembedded's layer index does not have this commit. (rocko)

Re: [OE-core] Dependency loops when enabling ptest with Ångström

After some hours of analysis I could identify the following commit in meta-angstrom introducing the loops. ---> snip <-- commit c94ca0759c34e637b725f648a1925e007bbe60e9 (HEAD -> work, m/angstrom-v2017.12-rocko, github/angstrom-v2017.12-rocko) Author: Koen Kooi

Re: [OE-core] Dependency loops when enabling ptest with Ångström

On 05.09.2018 15:46, richard.pur...@linuxfoundation.org wrote: > I suspect the Ångström maintainers may appreciate some help in > narrowing it down and fixing it since I doubt they have any more > copious free time to solve all the bugs coming than I do. Of course your right! ;-) Here's a first h

Re: [OE-core] Dependency loops when enabling ptest with Ångström

On 05.09.2018 14:43, richard.pur...@linuxfoundation.org wrote: > Those are all OE-Core components and build fine with ptest enabled in > poky. That suggests one of the layers does something to the recipes in > a bbappend which breaks things. I'd try bisecting your layers, remove > some and see what

[OE-core] Dependency loops when enabling ptest with Ångström

[Sorry for the big addressee group, but I'm not sure where to address this issue correctly.] We're using meta-angstrom as base for our own software. At the moment we try to activate ptest for some of our components. Unfortunately the trys lead to dependency loops. :( To exclude our own stuff I

Re: [OE-core] devshell problems after distro upgrade openSUSE Leap 42.3 -> 15.0 (tmux only)

On 04.07.2018 13:37, Steffen Sledz wrote: > On 03.07.2018 08:04, Steffen Sledz wrote: >> On 02.07.2018 20:25, Khem Raj wrote: >>> On Sun, Jul 1, 2018 at 11:39 PM Steffen Sledz wrote: >>>> >>>> After upgrading my build system from openSU

Re: [OE-core] devshell problems after distro upgrade openSUSE Leap 42.3 -> 15.0 (tmux only)

On 03.07.2018 08:04, Steffen Sledz wrote: > On 02.07.2018 20:25, Khem Raj wrote: >> On Sun, Jul 1, 2018 at 11:39 PM Steffen Sledz wrote: >>> >>> After upgrading my build system from openSUSE Leap 42.3 to openSUSE Leap >>> 15.0 a >>> >>> bit

Re: [OE-core] devshell problems after distro upgrade openSUSE Leap 42.3 -> 15.0

On 02.07.2018 20:25, Khem Raj wrote: > On Sun, Jul 1, 2018 at 11:39 PM Steffen Sledz wrote: >> >> After upgrading my build system from openSUSE Leap 42.3 to openSUSE Leap >> 15.0 a >> >> bitbake foo -c devshell >> >> no longer switches to the rela

[OE-core] devshell problems after distro upgrade openSUSE Leap 42.3 -> 15.0

After upgrading my build system from openSUSE Leap 42.3 to openSUSE Leap 15.0 a bitbake foo -c devshell no longer switches to the related work directory. The devshell is opened in the original directory without any error or warning instead. Any hints what's wrong here or how I can debug this

Re: [OE-core] MS Windows machine?

On 04.01.2018 15:39, Richard Purdie wrote: > In basic terms, you need a machine which: > > * Sets TARGET_ARCH to the right thing (i686 or x86_64) > * Sets TARGET_OS to mingw32 > > and then some distro config which sets up the toolchain when mingw is > the target os to the values like meta-mingw/c

Re: [OE-core] MS Windows machine?

On 21.12.2017 14:00, Steffen Sledz wrote: > On 21.12.2017 12:39, Burton, Ross wrote: >> If you want to build for a Windows target then that should be possible but >> nobody as far as I'm aware has made the work public. meta-mingw will >> contain most of the changes

Re: [OE-core] MS Windows machine?

On 21.12.2017 12:39, Burton, Ross wrote: > If you want to build for a Windows target then that should be possible but > nobody as far as I'm aware has made the work public. meta-mingw will > contain most of the changes needed as that does build Windows binaries. That's exactly what we like to to.

Re: [OE-core] MS Windows machine?

On 21.12.2017 10:08, Burton, Ross wrote: > On 21 December 2017 at 06:40, Steffen Sledz wrote: >> Anyone tried to cross-compile for MS Windows target with Yocto/OE? > > Yes, see meta-mingw. A misunderstanding? I like to build *for* MS Windows, not *at* MS Wi

[OE-core] MS Windows machine?

Anyone tried to cross-compile for MS Windows target with Yocto/OE? Regards, Steffen PS: Fup set to -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] How to fix file-rdes QA error for /usr/bin/python or /bin/bash?

On 14.12.2017 14:34, Steffen Sledz wrote: > With rocko some builds are rejected because of the following package QA error > (formerly it was just a warning). > > ERROR: foo-1_gitrAUTOINC+2595b80a79-r17 do_package_qa: QA Issue: > //foo.py contained in package foo requires

[OE-core] How to fix file-rdes QA error for /usr/bin/python?

With rocko some builds are rejected because of the following package QA error (formerly it was just a warning). ERROR: foo-1_gitrAUTOINC+2595b80a79-r17 do_package_qa: QA Issue: //foo.py contained in package foo requires /usr/bin/python, but no providers found in RDEPENDS_for? [file-rdeps]

Re: [OE-core] [pyro][PATCH] u-boot-mkimage: fix nativesdk build

On 05.07.2017 14:59, Richard Purdie wrote: > On Wed, 2017-07-05 at 09:52 -0300, Otavio Salvador wrote: >> On Tue, Jul 4, 2017 at 8:17 PM, Khem Raj wrote: >>> >>> On Tue, Jul 4, 2017 at 3:16 PM, Otavio Salvador >>> wrote: On Tue, Jul 4, 2017 at 7:11 PM, Burton, Ross >>> om> wrote: >

[OE-core] [pyro][PATCH] u-boot-mkimage: fix nativesdk build

From: Max Krummenacher If building for nativesdk the wrong rss sysroot is used leading the following error message. | ERROR: oe_runmake failed | In file included from tools/imximage.c:13:0: | include/image.h:1024:27: fatal error: openssl/evp.h: No such file or directory | # include Tools nee

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)

[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

[OE-core] kernel not booting if build with gcc-5.2.0

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 While switching from fido to jethro we hit the next problem. :( For one of our machines (based on Marvell Kirkwood, very similar to OpenRD) the kernel build with the preferred gcc-5.2.0 does not boot. Immediately after the kernel is started from u-b

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

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: >> 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 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 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

[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] 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:

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.

[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] [PATCH] busybox: add UPDATE_ALTERNATIVE for syslog-service

This fixes [YOCTO-8688]. -- 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. Michael Weber, Werner Mögle; Amtsgericht Berlin Charlottenburg; HRB 130120 B; Ust.-IDNr. DE273

[OE-core] [PATCH] busybox: add UPDATE_ALTERNATIVE for syslog-service

Use ALTERNATIVE mechanism in OE to manage the syslog service to avoid conflicts with other syslog implementations like rsyslog or syslog-ng. Signed-off-by: Steffen Sledz --- meta/recipes-core/busybox/busybox.inc | 6 ++ 1 file changed, 6 insertions(+) diff --git a/meta/recipes-core/busybox

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

On 22.10.2015 10:54, Richard Leitner wrote: > On 10/22/2015 10:52 AM, Steffen Sledz wrote: >> 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? >>>> &

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

[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] "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

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 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] [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

[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

[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]

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: >>>

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 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

[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] [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

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(-) >

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:

[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] 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 '

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

[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] 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] 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] "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

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 >>

[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

[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] [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 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

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

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

[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 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 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] 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] 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] [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

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

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

[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 +

[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

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] ^{} 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] 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

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

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 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 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 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 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

[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] [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] [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] 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: >>

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 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 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

[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][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

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:

[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] [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

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: >>>>

  1   2   >