Re: [yocto] [meta-raspberrypi] [PATCH] ds1307-rtc-overlay.dtb has been removed from the kernel tree, and most overlays have been moved to the dts/overlays directory
Hi, I used the master head, downloaded in may. The last commit I see using "git log" is: commit 6ef9d94a2c2588dcefe442577ef6ae5bbe722dec Author: Petter Mabäcker Date: Fri May 8 23:49:05 2015 +0200 linux-raspberrypi: Update 3.12 branch to latest Update linux-raspberrypi_3.12 to latest revision. Remove sl030raspberrypii2ckernel.patch since it will not apply anymore and its content seems to be obsolite after '558d0bf Fix grabbing lock from atomic context in i2c driver' was merged to 3.12. [Support #60] Signed-off-by: Petter Mabäcker Signed-off-by: Andrei Gherzan Regards, Herve -Original Message- From: Andrei Gherzan [mailto:and...@gherzan.ro] Sent: mardi 23 juin 2015 20:29 To: Herve Jourdain Cc: Yocto Project Subject: Re: [yocto] [meta-raspberrypi] [PATCH] ds1307-rtc-overlay.dtb has been removed from the kernel tree, and most overlays have been moved to the dts/overlays directory Hi, On Thu, Jun 18, 2015 at 10:33 AM, Andrei Gherzan wrote: > Hello, > > On 18 Jun 2015 10:22, "Herve Jourdain" wrote: >> >> Hi Andrei, >> >> Well, it seems that the current meta-raspberrypi is pulling the >> kernel from github, and the kernel on github already has these "features" in. >> Which is why I could compile fine with the current meta-raspberrypi >> 2or 3 weeks ago, but it failed 2 days ago when I tried to do a fresh build... >> Therefore, I believe the change in the meta-raspberrypi is already >> needed for the 3.18.y branch, because the kernel already has it. > > This is interesting. I'll check it tonight. I re-downloaded and recompiled kernel on the current meta-raspberrypi master HEAD and had no issues. What meta-raspberrypi revision are you using? -- Andrei Gherzan e: and...@gherzan.ro w: www.gherzan.ro -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [LXCR-4977 PATCH 1/1] Add makedumpfile recipe to cgl.
JFYI, makedumpfile recipe patch was already sent on emea list on 3/31/2015.
Can you please check?
//Gaurang Shastri
-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On
Behalf Of Alexandru.Vaduva
Sent: Tuesday, June 23, 2015 7:30 PM
To: yocto@yoctoproject.org; adrian.du...@enea.com; alexandru.vad...@enea.com;
alexandra.sa...@enea.com
Cc: Siva Borra; li...@list.enea.se; iss...@enea.com
Subject: [yocto] [LXCR-4977 PATCH 1/1] Add makedumpfile recipe to cgl.
From: Siva Borra
Add the makedumpfile package recipe to
the cgl layer.
[LXCR-4977]
Signed-off-by: Siva Borra
---
.../makedumpfile/files/alias-powerpc-powerpc32.patch | 13 +
.../recipes-cgl/makedumpfile/makedumpfile_1.5.8.bb | 20
2 files changed, 33 insertions(+)
create mode 100644
meta-cgl-common/recipes-cgl/makedumpfile/files/alias-powerpc-powerpc32.patch
create mode 100644
meta-cgl-common/recipes-cgl/makedumpfile/makedumpfile_1.5.8.bb
diff --git
a/meta-cgl-common/recipes-cgl/makedumpfile/files/alias-powerpc-powerpc32.patch
b/meta-cgl-common/recipes-cgl/makedumpfile/files/alias-powerpc-powerpc32.patch
new file mode 100644
index 000..70ad663
--- /dev/null
+++ b/meta-cgl-common/recipes-cgl/makedumpfile/files/alias-powerpc-power
+++ pc32.patch
@@ -0,0 +1,13 @@
+diff -rupN makedumpfile-1.5.8/Makefile makedumpfile-1.5.8/Makefile
+--- makedumpfile-1.5.8/Makefile2015-03-24 02:58:33.0 +0100
makedumpfile-1.5.8/Makefile2015-06-23 11:08:30.595655336 +0200
+@@ -25,7 +25,8 @@ endif
+ ARCH := $(shell echo ${TARGET} | sed -e s/i.86/x86/ -e s/sun4u/sparc64/ \
+ -e s/arm.*/arm/ -e s/sa110/arm/ \
+ -e s/s390x/s390/ -e s/parisc64/parisc/ \
+- -e s/ppc64/powerpc64/ -e s/ppc/powerpc32/)
++ -e s/ppc64/powerpc64/ -e s/ppc/powerpc32/ \
++ -e s/powerpc/powerpc32/)
+
+ CROSS :=
+ ifneq ($(TARGET), $(HOST_ARCH))
diff --git a/meta-cgl-common/recipes-cgl/makedumpfile/makedumpfile_1.5.8.bb
b/meta-cgl-common/recipes-cgl/makedumpfile/makedumpfile_1.5.8.bb
new file mode 100644
index 000..6c32306
--- /dev/null
+++ b/meta-cgl-common/recipes-cgl/makedumpfile/makedumpfile_1.5.8.bb
@@ -0,0 +1,20 @@
+DESCRIPTION = "Make dump file utility"
+LICENSE = "GPLv2"
+
+LIC_FILES_CHKSUM = "file://COPYING;md5=751419260aa954499f7abaabaa882bbe"
+
+SRC_URI =
"http://sourceforge.net/projects/makedumpfile/files/makedumpfile/1.5.8/makedumpfile-${PV}.tar.gz;name=makedumpfile
\
+ file://alias-powerpc-powerpc32.patch \
+ "
+
+SRC_URI[makedumpfile.md5sum] = "642d975349dff744c6027d4486499258"
+SRC_URI[makedumpfile.sha256sum] =
"dd9c6c40c1ae6774b61bbe7b53f5ebbee9734f576d8ecb75ffb929288f5ea64d"
+
+DEPENDS = "zlib elfutils bzip2"
+
+EXTRA_OEMAKE = "TARGET=${TARGET_ARCH}"
+
+do_install() {
+ install -d ${D}${bindir}/
+ install -c -m 755 ${S}/makedumpfile ${D}${bindir}/ }
--
1.9.1
--
___
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] Deploying 2 machines, u-boot does not include with both.
Hi This is a weird one that I have been researching for a while trying to figure out how this can happen. We recently had to extend our targets with another machine, they have the same core CPU architecture, but we provide different configurations of the kernel for them. Along with some IMAGE_INSTALL changes. Since very little needs to be rebuilt, and the only thing needed to change target machine is to edit the MACHINE variable, we chose to build the images using the same build directory. This means we set the MACHINE variable to machine_A. run bitbake [machine_A_image], change the MACHINE variable to machine_B, and then run bitbake [machine_B_image]. Here is when the weird happens. After machine_A has built, we can find everything we expect to find in the machine_A image deploy directory. When we change the MACHINE variable and build machine_B, we find that the u-boot image from the machine_A directory has disappeared. Depending on build machine it has moved into the machine_B directory, in addition to u-boot image for machine_B being present in this directory, OR it has just been removed. Changing back to building machine_A, the u-boot(s) are removed from the machine_B directory, and the machine_A u-boot will show up in the machine_A directory. What could be at play here to cause such a strange behaviour? How can I debug such a behaviour? I could not find anything on Google regarding this, nor anything in the logs generated by bitbake. We're using the Daisy branch of Yocto. Thank you in advance. Best regards // John Ernberg -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [LXCR-4977 PATCH 1/1] Add makedumpfile recipe to cgl.
Thanks for the information and for the patch.I am really pleased when anyone
sends a patch, sorry though that I missed your.Hoping not to make this mistake
again.
Unfortunately I will leave your patch as it is since the meta-cgl itself is on
a change process and we are trying as much as possible to use the latest and
most stable packages available.Would you please make sure that the next time
you will send a patch for the meta-cgl layer that I am in CC or the
"[meta-cgl]" information is somewhere in the emails subject. By doing that we
can make sure that situations like the earlier one would not repeat.
Thanks once again for you interest. Sorry for the mistake. I will try to make
sure that the next patch sent to the meta-cgl layer will receive my full
attention.
Alex V.
On Wednesday, June 24, 2015 11:06 AM, Gaurang Shastri
wrote:
JFYI, makedumpfile recipe patch was already sent on emea list on 3/31/2015.
Can you please check?
//Gaurang Shastri
-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On
Behalf Of Alexandru.Vaduva
Sent: Tuesday, June 23, 2015 7:30 PM
To: yocto@yoctoproject.org; adrian.du...@enea.com; alexandru.vad...@enea.com;
alexandra.sa...@enea.com
Cc: Siva Borra; li...@list.enea.se; iss...@enea.com
Subject: [yocto] [LXCR-4977 PATCH 1/1] Add makedumpfile recipe to cgl.
From: Siva Borra
Add the makedumpfile package recipe to
the cgl layer.
[LXCR-4977]
Signed-off-by: Siva Borra
---
.../makedumpfile/files/alias-powerpc-powerpc32.patch | 13 +
.../recipes-cgl/makedumpfile/makedumpfile_1.5.8.bb | 20
2 files changed, 33 insertions(+)
create mode 100644
meta-cgl-common/recipes-cgl/makedumpfile/files/alias-powerpc-powerpc32.patch
create mode 100644
meta-cgl-common/recipes-cgl/makedumpfile/makedumpfile_1.5.8.bb
diff --git
a/meta-cgl-common/recipes-cgl/makedumpfile/files/alias-powerpc-powerpc32.patch
b/meta-cgl-common/recipes-cgl/makedumpfile/files/alias-powerpc-powerpc32.patch
new file mode 100644
index 000..70ad663
--- /dev/null
+++ b/meta-cgl-common/recipes-cgl/makedumpfile/files/alias-powerpc-power
+++ pc32.patch
@@ -0,0 +1,13 @@
+diff -rupN makedumpfile-1.5.8/Makefile makedumpfile-1.5.8/Makefile
+--- makedumpfile-1.5.8/Makefile 2015-03-24 02:58:33.0 +0100
makedumpfile-1.5.8/Makefile 2015-06-23 11:08:30.595655336 +0200
+@@ -25,7 +25,8 @@ endif
+ ARCH := $(shell echo ${TARGET} | sed -e s/i.86/x86/ -e s/sun4u/sparc64/ \
+ -e s/arm.*/arm/ -e s/sa110/arm/ \
+ -e s/s390x/s390/ -e s/parisc64/parisc/ \
+- -e s/ppc64/powerpc64/ -e s/ppc/powerpc32/)
++ -e s/ppc64/powerpc64/ -e s/ppc/powerpc32/ \
++ -e s/powerpc/powerpc32/)
+
+ CROSS :=
+ ifneq ($(TARGET), $(HOST_ARCH))
diff --git a/meta-cgl-common/recipes-cgl/makedumpfile/makedumpfile_1.5.8.bb
b/meta-cgl-common/recipes-cgl/makedumpfile/makedumpfile_1.5.8.bb
new file mode 100644
index 000..6c32306
--- /dev/null
+++ b/meta-cgl-common/recipes-cgl/makedumpfile/makedumpfile_1.5.8.bb
@@ -0,0 +1,20 @@
+DESCRIPTION = "Make dump file utility"
+LICENSE = "GPLv2"
+
+LIC_FILES_CHKSUM = "file://COPYING;md5=751419260aa954499f7abaabaa882bbe"
+
+SRC_URI =
"http://sourceforge.net/projects/makedumpfile/files/makedumpfile/1.5.8/makedumpfile-${PV}.tar.gz;name=makedumpfile
\
+ file://alias-powerpc-powerpc32.patch \
+ "
+
+SRC_URI[makedumpfile.md5sum] = "642d975349dff744c6027d4486499258"
+SRC_URI[makedumpfile.sha256sum] =
"dd9c6c40c1ae6774b61bbe7b53f5ebbee9734f576d8ecb75ffb929288f5ea64d"
+
+DEPENDS = "zlib elfutils bzip2"
+
+EXTRA_OEMAKE = "TARGET=${TARGET_ARCH}"
+
+do_install() {
+ install -d ${D}${bindir}/
+ install -c -m 755 ${S}/makedumpfile ${D}${bindir}/ }
--
1.9.1
--
___
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] meta-mono: Issue building 4.0.2.4
On 24/06/2015 01:01, Chris Morgan wrote: > The double nested output folder looks odd to me but leaving that, it > looks like a file is being installed twice. Anyone else seeing this? > > meta > meta-skeleton = > "(HEADdetachedat16caaab):16caaabfcc678b03a0cd88aaeac15f9b8d1c3dad" > meta-yocto > meta-yocto-bsp= > "(HEADdetachedat16caaab):16caaabfcc678b03a0cd88aaeac15f9b8d1c3dad" > meta-mono = "master:35e8ede514dd35eb3d645d5de22282d0e8204f86" > meta-oe > meta-webserver= > "(HEADdetachedatdf6c7b1):df6c7b1279790d27ebfd58fbdfbac89bde5782ec" > meta-ti = > "(HEADdetachedatb81014d):b81014dbb5cc39fdfa66af87d18b72eb9eb3c701" > meta-nodejs = > "(HEADdetachedate724e27):e724e270bc23a14f12d4a0d73869199457a1b925" > bitbake-npm = > "(HEADdetachedatd88833b):d88833bcf52da7d00e775ca8c2e63ca44cf6ace1" > meta-ros = > "(HEADdetachedatbdc603b):bdc603b821eae5e1d966ec25e63f6832f6386dc8" > meta-rust = > "(HEADdetachedat61708ed):61708ed85e76beafdb08b6caf340abeae13bf4b2" > meta-qt5 = > "(HEADdetachedat378dfc2):378dfc20ad0e024412da7f3be22efe04c3421c6d" > meta-ruby > meta-python > meta-networking = > "(HEADdetachedatdf6c7b1):df6c7b1279790d27ebfd58fbdfbac89bde5782ec" > > > (output snipped) > | /usr/bin/install -c -c -m 644 frameworks/net_4.5.xml > /home/cmorgan/projects/yocto/build/tmp/work/x86_64-linux/mono-native/4.0.2.4-r0/image/home/cmorgan/projects/yocto/build/tmp/sysroots/x86_64-linux/usr/lib/mono/xbuild-frameworks/.NETFramework/v4.5/RedistList/FrameworkList.xml > | /usr/bin/install -c -c -m 644 > targets/Microsoft.WebApplication.targets > /home/cmorgan/projects/yocto/build/tmp/work/x86_64-linux/mono-native/4.0.2.4-r0/image/home/cmorgan/projects/yocto/build/tmp/sysroots/x86_64-linux/usr/lib/mono/xbuild/Microsoft/VisualStudio/v9.0/WebApplications > | mkdir -p -- > /home/cmorgan/projects/yocto/build/tmp/work/x86_64-linux/mono-native/4.0.2.4-r0/image/home/cmorgan/projects/yocto/build/tmp/sysroots/x86_64-linux/usr/lib/mono/xbuild/14.0/bin/MSBuild > | /usr/bin/install -c -c -m 644 > targets/Microsoft.Portable.Common.targets > /home/cmorgan/projects/yocto/build/tmp/work/x86_64-linux/mono-native/4.0.2.4-r0/image/home/cmorgan/projects/yocto/build/tmp/sysroots/x86_64-linux/usr/lib/mono/xbuild/Microsoft/Portable/v4.0/Microsoft.Portable.Common.targets > | /usr/bin/install -c -c -m 644 > targets/Microsoft.WebApplication.targets > /home/cmorgan/projects/yocto/build/tmp/work/x86_64-linux/mono-native/4.0.2.4-r0/image/home/cmorgan/projects/yocto/build/tmp/sysroots/x86_64-linux/usr/lib/mono/xbuild/Microsoft/VisualStudio/v9.0/WebApplications > | /usr/bin/install: cannot create regular file > '/home/cmorgan/projects/yocto/build/tmp/work/x86_64-linux/mono-native/4.0.2.4-r0/image/home/cmorgan/projects/yocto/build/tmp/sysroots/x86_64-linux/usr/lib/mono/xbuild-frameworks/.NETFramework/v4.5/RedistList/FrameworkList.xml': > File exists > | Makefile:42: recipe for target 'install-frameworks' failed > | make[6]: *** [install-frameworks] Error 1 > | make[6]: *** Waiting for unfinished jobs Hi Chris, Yes the double nesting does look odd. I did a test build of 4.0.2.4 here which worked for me. I've also been supporting another chap who wanted to build 4.0.2.4 rather than the default 3.12.1 build and he also let me know he had it building successfully Clearly there's some kind of issue though. I'm relocating between countries at the moment without access to a build system and so it'll be 1-2 weeks before I can investigate further myself I'm afraid. In the meantime do 4.0.1.34 and earlier versions build for you? Does -c cleansstate help? Regards, Alex -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-mono: Issue building 4.0.2.4
On Wed, Jun 24, 2015 at 9:13 AM, Alex J Lennon wrote: > > > On 24/06/2015 01:01, Chris Morgan wrote: >> The double nested output folder looks odd to me but leaving that, it >> looks like a file is being installed twice. Anyone else seeing this? >> >> meta >> meta-skeleton = >> "(HEADdetachedat16caaab):16caaabfcc678b03a0cd88aaeac15f9b8d1c3dad" >> meta-yocto >> meta-yocto-bsp= >> "(HEADdetachedat16caaab):16caaabfcc678b03a0cd88aaeac15f9b8d1c3dad" >> meta-mono = "master:35e8ede514dd35eb3d645d5de22282d0e8204f86" >> meta-oe >> meta-webserver= >> "(HEADdetachedatdf6c7b1):df6c7b1279790d27ebfd58fbdfbac89bde5782ec" >> meta-ti = >> "(HEADdetachedatb81014d):b81014dbb5cc39fdfa66af87d18b72eb9eb3c701" >> meta-nodejs = >> "(HEADdetachedate724e27):e724e270bc23a14f12d4a0d73869199457a1b925" >> bitbake-npm = >> "(HEADdetachedatd88833b):d88833bcf52da7d00e775ca8c2e63ca44cf6ace1" >> meta-ros = >> "(HEADdetachedatbdc603b):bdc603b821eae5e1d966ec25e63f6832f6386dc8" >> meta-rust = >> "(HEADdetachedat61708ed):61708ed85e76beafdb08b6caf340abeae13bf4b2" >> meta-qt5 = >> "(HEADdetachedat378dfc2):378dfc20ad0e024412da7f3be22efe04c3421c6d" >> meta-ruby >> meta-python >> meta-networking = >> "(HEADdetachedatdf6c7b1):df6c7b1279790d27ebfd58fbdfbac89bde5782ec" >> >> >> (output snipped) >> | /usr/bin/install -c -c -m 644 frameworks/net_4.5.xml >> /home/cmorgan/projects/yocto/build/tmp/work/x86_64-linux/mono-native/4.0.2.4-r0/image/home/cmorgan/projects/yocto/build/tmp/sysroots/x86_64-linux/usr/lib/mono/xbuild-frameworks/.NETFramework/v4.5/RedistList/FrameworkList.xml >> | /usr/bin/install -c -c -m 644 >> targets/Microsoft.WebApplication.targets >> /home/cmorgan/projects/yocto/build/tmp/work/x86_64-linux/mono-native/4.0.2.4-r0/image/home/cmorgan/projects/yocto/build/tmp/sysroots/x86_64-linux/usr/lib/mono/xbuild/Microsoft/VisualStudio/v9.0/WebApplications >> | mkdir -p -- >> /home/cmorgan/projects/yocto/build/tmp/work/x86_64-linux/mono-native/4.0.2.4-r0/image/home/cmorgan/projects/yocto/build/tmp/sysroots/x86_64-linux/usr/lib/mono/xbuild/14.0/bin/MSBuild >> | /usr/bin/install -c -c -m 644 >> targets/Microsoft.Portable.Common.targets >> /home/cmorgan/projects/yocto/build/tmp/work/x86_64-linux/mono-native/4.0.2.4-r0/image/home/cmorgan/projects/yocto/build/tmp/sysroots/x86_64-linux/usr/lib/mono/xbuild/Microsoft/Portable/v4.0/Microsoft.Portable.Common.targets >> | /usr/bin/install -c -c -m 644 >> targets/Microsoft.WebApplication.targets >> /home/cmorgan/projects/yocto/build/tmp/work/x86_64-linux/mono-native/4.0.2.4-r0/image/home/cmorgan/projects/yocto/build/tmp/sysroots/x86_64-linux/usr/lib/mono/xbuild/Microsoft/VisualStudio/v9.0/WebApplications >> | /usr/bin/install: cannot create regular file >> '/home/cmorgan/projects/yocto/build/tmp/work/x86_64-linux/mono-native/4.0.2.4-r0/image/home/cmorgan/projects/yocto/build/tmp/sysroots/x86_64-linux/usr/lib/mono/xbuild-frameworks/.NETFramework/v4.5/RedistList/FrameworkList.xml': >> File exists >> | Makefile:42: recipe for target 'install-frameworks' failed >> | make[6]: *** [install-frameworks] Error 1 >> | make[6]: *** Waiting for unfinished jobs > > Hi Chris, > > Yes the double nesting does look odd. > > I did a test build of 4.0.2.4 here which worked for me. I've also been > supporting another chap who wanted to build 4.0.2.4 rather than the > default 3.12.1 build and he also let me know he had it building > successfully > > Clearly there's some kind of issue though. I'm relocating between > countries at the moment without access to a build system and so it'll be > 1-2 weeks before I can investigate further myself I'm afraid. > > In the meantime do 4.0.1.34 and earlier versions build for you? Does -c > cleansstate help? > > Regards, > > Alex > > Tried the cleansstate with 4.0.2.4 before sending the initial email. Similar issue with 4.0.1.34 but a different file and a different section of the code: | /usr/bin/install -c -c -m 644 targets/Microsoft.Portable.Common.targets /home/cmorgan/projects/yocto-cybex/build/tmp/work/x86_64-linux/mono-native/4.0.1.34-r0/image/home/cmorgan/projects/yocto-cybex/build/tmp/sysroots/x86_64-linux/usr/lib/mono/xbuild/Microsoft/Portable/v4.5/Microsoft.Portable.Common.targets | /usr/bin/install -c -c -m 644 targets/Microsoft.WebApplication.targets /home/cmorgan/projects/yocto-cybex/build/tmp/work/x86_64-linux/mono-native/4.0.1.34-r0/image/home/cmorgan/projects/yocto-cybex/build/tmp/sysroots/x86_64-linux/usr/lib/mono/xbuild/Microsoft/VisualStudio/v11.0/WebApplications | /usr/bin/install -c -c -m 644 targets/Microsoft.WebApplication.targets /home/cmorgan/projects/yocto-cybex/build/tmp/work/x86_64-linux/mono-native/4.0.1.34-r0/image/home/cmorgan/projects/yocto-cybex/build/tmp/sysroots/x86_64-linux/usr/lib/mono/xbuild/Microsoft/VisualStudio/v11.0/WebApplications | /usr/bin/install: cannot create regular file '/home/cmorgan/projects/yocto-cybex/build/tmp/work/x86_64-linux/mono-native/4.0.1.34-r0/image/home
Re: [yocto] [meta-raspberrypi] [PATCH] ds1307-rtc-overlay.dtb has been removed from the kernel tree, and most overlays have been moved to the dts/overlays directory
Hello, Adding Yocto back in loop (sorry for this - it is my fault). On Wed, Jun 24, 2015 at 2:37 PM, Herve Jourdain wrote: > Hi Andrei, > > OK, not sure what happened, it seemed that when I tested it, it downloaded > the latest version of the kernel on github.com/raspberrypi for the 3.18.y > branch, instead of the version specified in the SRCREV... And I really don't > know why... > So after rechecking from scratch, when it pulls the correct version, then it > still works like before. > > But this patch will be needed as soon as meta-raspberrypi moves to a more > recent 3.18y version (739c586c87576fb8ef151b5843ebed76c43a5221 or later). I understand that and checking the upstream code I can confirm this change. Thanks for informing and will definitely look into it when we will update the kernel. If you want, you can help Petter in getting the updates faster. I know he is already working on this (CCed). > Regards, > > Herve > > -Original Message- > From: Herve Jourdain [mailto:herve.jourd...@neuf.fr] > Sent: mercredi 24 juin 2015 12:40 > To: 'Andrei Gherzan' > Subject: RE: [yocto] [meta-raspberrypi] [PATCH] ds1307-rtc-overlay.dtb has > been removed from the kernel tree, and most overlays have been moved to the > dts/overlays directory > > Hi, > > OK, I'm trying right now... I will need a little time, though, compilation is > not really fast... > > Regards, > > Herve > > -Original Message- > From: Andrei Gherzan [mailto:and...@gherzan.ro] > Sent: mercredi 24 juin 2015 11:21 > To: Herve Jourdain > Subject: Re: [yocto] [meta-raspberrypi] [PATCH] ds1307-rtc-overlay.dtb has > been removed from the kernel tree, and most overlays have been moved to the > dts/overlays directory > > Hello, > > On Wed, Jun 24, 2015 at 10:02 AM, Herve Jourdain > wrote: >> Hi, >> >> I used the master head, downloaded in may. >> The last commit I see using "git log" is: >> commit 6ef9d94a2c2588dcefe442577ef6ae5bbe722dec >> Author: Petter Mabäcker >> Date: Fri May 8 23:49:05 2015 +0200 > > Could you please use the current HEAD? I can't reproduce on current revision. > > -- > Andrei Gherzan > e: and...@gherzan.ro > w: www.gherzan.ro Regards, -- Andrei Gherzan e: and...@gherzan.ro w: www.gherzan.ro -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] [PATCH] ds1307-rtc-overlay.dtb has been removed from the kernel tree, and most overlays have been moved to the dts/overlays directory
Hi Andrei, Petter, If there is any way I can help, I'll be glad to do it. Please let me know how best this can be achieved. Regards, Herve -Original Message- From: Andrei Gherzan [mailto:and...@gherzan.ro] Sent: mercredi 24 juin 2015 15:59 To: Herve Jourdain; Yocto Project Cc: Petter Mabäcker Subject: Re: [yocto] [meta-raspberrypi] [PATCH] ds1307-rtc-overlay.dtb has been removed from the kernel tree, and most overlays have been moved to the dts/overlays directory Hello, Adding Yocto back in loop (sorry for this - it is my fault). On Wed, Jun 24, 2015 at 2:37 PM, Herve Jourdain wrote: > Hi Andrei, > > OK, not sure what happened, it seemed that when I tested it, it downloaded > the latest version of the kernel on github.com/raspberrypi for the 3.18.y > branch, instead of the version specified in the SRCREV... And I really don't > know why... > So after rechecking from scratch, when it pulls the correct version, then it > still works like before. > > But this patch will be needed as soon as meta-raspberrypi moves to a more > recent 3.18y version (739c586c87576fb8ef151b5843ebed76c43a5221 or later). I understand that and checking the upstream code I can confirm this change. Thanks for informing and will definitely look into it when we will update the kernel. If you want, you can help Petter in getting the updates faster. I know he is already working on this (CCed). > Regards, > > Herve > > -Original Message- > From: Herve Jourdain [mailto:herve.jourd...@neuf.fr] > Sent: mercredi 24 juin 2015 12:40 > To: 'Andrei Gherzan' > Subject: RE: [yocto] [meta-raspberrypi] [PATCH] ds1307-rtc-overlay.dtb > has been removed from the kernel tree, and most overlays have been > moved to the dts/overlays directory > > Hi, > > OK, I'm trying right now... I will need a little time, though, compilation is > not really fast... > > Regards, > > Herve > > -Original Message- > From: Andrei Gherzan [mailto:and...@gherzan.ro] > Sent: mercredi 24 juin 2015 11:21 > To: Herve Jourdain > Subject: Re: [yocto] [meta-raspberrypi] [PATCH] ds1307-rtc-overlay.dtb > has been removed from the kernel tree, and most overlays have been > moved to the dts/overlays directory > > Hello, > > On Wed, Jun 24, 2015 at 10:02 AM, Herve Jourdain > wrote: >> Hi, >> >> I used the master head, downloaded in may. >> The last commit I see using "git log" is: >> commit 6ef9d94a2c2588dcefe442577ef6ae5bbe722dec >> Author: Petter Mabäcker >> Date: Fri May 8 23:49:05 2015 +0200 > > Could you please use the current HEAD? I can't reproduce on current revision. > > -- > Andrei Gherzan > e: and...@gherzan.ro > w: www.gherzan.ro Regards, -- Andrei Gherzan e: and...@gherzan.ro w: www.gherzan.ro -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 1/1] Add upstream status to patch.
From: Siva Borra Add description and upstream status information to the patch file. Signed-off-by: Siva Borra --- .../recipes-cgl/makedumpfile/files/alias-powerpc-powerpc32.patch | 5 + 1 file changed, 5 insertions(+) diff --git a/meta-cgl-common/recipes-cgl/makedumpfile/files/alias-powerpc-powerpc32.patch b/meta-cgl-common/recipes-cgl/makedumpfile/files/alias-powerpc-powerpc32.patch index 70ad663..e918ce8 100644 --- a/meta-cgl-common/recipes-cgl/makedumpfile/files/alias-powerpc-powerpc32.patch +++ b/meta-cgl-common/recipes-cgl/makedumpfile/files/alias-powerpc-powerpc32.patch @@ -1,3 +1,8 @@ +Create Alias for target for powerpc as powerpc32 + +Signed-off-by: Siva Borra +Upstream-status: Pending + diff -rupN makedumpfile-1.5.8/Makefile makedumpfile-1.5.8/Makefile --- makedumpfile-1.5.8/Makefile2015-03-24 02:58:33.0 +0100 +++ makedumpfile-1.5.8/Makefile2015-06-23 11:08:30.595655336 +0200 -- 1.9.1 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCHv2 1/1] Add packages umip, makedumpfile, openl2tp
From: Siva Borra Add packages umip, makedumpfile and open2tp to the image. Signed-off-by: Siva Borra --- meta-cgl-common/packagegroups/packagegroup-cgl-applications.bb | 2 ++ meta-cgl-common/packagegroups/packagegroup-cgl-middleware.bb | 1 + 2 files changed, 3 insertions(+) diff --git a/meta-cgl-common/packagegroups/packagegroup-cgl-applications.bb b/meta-cgl-common/packagegroups/packagegroup-cgl-applications.bb index 2f2d55f..f921c1c 100644 --- a/meta-cgl-common/packagegroups/packagegroup-cgl-applications.bb +++ b/meta-cgl-common/packagegroups/packagegroup-cgl-applications.bb @@ -50,6 +50,8 @@ RDEPENDS_packagegroup-cgl-applications = " \ pam-passwdqc \ libpam \ rsyslog \ +openl2tp \ +umip \ " LTTNG ?= "\ diff --git a/meta-cgl-common/packagegroups/packagegroup-cgl-middleware.bb b/meta-cgl-common/packagegroups/packagegroup-cgl-middleware.bb index effdb81..ea7377b 100644 --- a/meta-cgl-common/packagegroups/packagegroup-cgl-middleware.bb +++ b/meta-cgl-common/packagegroups/packagegroup-cgl-middleware.bb @@ -58,6 +58,7 @@ RDEPENDS_packagegroup-cgl-middleware = "\ cluster-resource-agents \ ifenslave \ drbd \ +makedumpfile \ " DISTRO_FEATURES_append = " ptest argp ext2 xattr nfs pci ipv4 ipv6" -- 1.9.1 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] cryptsetup in initramfs causes ~4 MB image size increase
I earlier wrote:
>
> I'm interested to use an encrypted root filesystem, by using cryptsetup in
> initramfs.
>
> I'm finding that adding cryptsetup to an initramfs image increases its size by
> about 4 MB. It seems that cryptsetup depends on openssl and lvm2, and
> lvm2 depends on bash, and the result of that is that a lot of extra files get
> dragged in.
>
> Is this all strictly necessary? Perhaps cryptsetup really only needs
> libraries,
> not all of openssl and lvm2.
>
> What would be a good way to go about reducing the dependencies that get
> pulled in for cryptsetup?
>
> I also noticed that libgcrypt could possibly be used instead of openssl (by
> putting in bbappend, PACKAGECONFIG = ""), saving about 0.5 MB. However
> libgcrypt isn't used, according to the cryptsetup bb file, because it drops
> root
> privileges if it is linked with libcap support. That gives the obscure
> cryptsetup
> error "Cannot initialize device-mapper. Is dm_mod kernel module loaded?"
> when trying to use cryptsetup with libgcrypt. Is there any reasonable work-
> around for this?
I found that I can cut it down significantly, using the following
lvm2_2.%.bbappend:
---
PACKAGES =+ "lvm2-libdevmapper"
# ${base_libdir}/udev ${sbindir}/dmsetup are to get device mapper udev rules,
# to avoid cryptsetup luksOpen hanging.
FILES_lvm2-libdevmapper = "${libdir}/libdevmapper.so.* ${base_libdir}/udev
${sbindir}/dmsetup"
RDEPENDS_lvm2-libdevmapper = "bash"
RDEPENDS_${PN} += " lvm2-libdevmapper"
RPROVIDES_${PN}-dev = "lvm2-libdevmapper-dev"
---
That cuts out a bunch of unneeded lvm files.
I'm not sure why there needs to be a bash dependency, but it didn't work
without it. I'd like to get rid of bash if it's possible.
(After reading more about libgcrypt, I think I'll just stick with openssl. It
seems questionable design for the library, to drop an application's
capabilities.)
--
Craig McQueen
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
