Richard,
This is mostly a set of package updates with a couple of fixes
fro systemd from Khem and Ross.
Please review Peter's rename patch.
I have build and booted sato locally with most of the udpated pacakges,
the Auotbuilder is currently running with Master under Test.
Thanks
Sau!
Failing to get recipe from upstream svn repository now fails with ugly
stack trace.
I have bitbake/master from today and it's not really google-glog fault I had
network
issue when bitbake was parsing, but error message should look better (it looked
better
before)
Parsing recipes...ERROR: Erro
From: Matthew McClintock
This improves reusabiliy of sstate-cache across different hosts
Signed-odd-by: Matthew McClintock
Signed-off-by: Saul Wold
---
meta/recipes-core/glib-2.0/glib-2.0_2.32.4.bb | 2 +-
meta/recipes-core/glib-2.0/glib.inc | 2 +-
2 files changed, 2 insertions(+),
The 'make update' was using wget to get the gmo and other gnu files from
upstream, since need to work cleanly in a non-networked or proxy environment
this does not so well. Remove the list of languages from the LINGUAS file.
[YOCTO #3745]
Signed-off-by: Saul Wold
---
meta/recipes-devtools/rema
On 02/14/13 15:57, Jack Mitchell wrote:
On 14/02/13 15:44, Jack Mitchell wrote:
On 14/02/13 15:31, Burton, Ross wrote:
On 14 February 2013 14:31, Jack Mitchell
wrote:
Did this ever go anywhere? I have just tried again today with
exactly the
same result, all I did was change the DISTRO_FEATURE
On 02/14/2013 09:09 AM, Joe Slater wrote:
Override the hard-coded CFLAGS used in Makefile
to reference our CFLAGS.
Can you be clearer about this?
I just checked the output of the compile log and these flags are set
correctly. I also looked at the make -n output via a devshell.
This seems t
Override the hard-coded CFLAGS used in Makefile
to reference our CFLAGS.
Upstream-Status: Pending
Signed-off-by: Joe Slater
---
meta/recipes-bsp/acpid/acpid.inc |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-bsp/acpid/acpid.inc b/meta/recipes-bsp/acpid
On 14 February 2013 18:31, Martin Jansa wrote:
> Shouldn't this show at least a warning about missing conffile?
>
> opkg-build error saved me few times before adding CONFFILES with wrong
> pattern not matching anything in FILES.
I'm pretty certain rpm doesn't produce a warning, so we'd want to fi
On Thu, Feb 14, 2013 at 05:52:50PM +, Ross Burton wrote:
> opkg-build verifies that conffiles exist, so verify that the specified files
> actually exist before writing them to conffiles.
Shouldn't this show at least a warning about missing conffile?
opkg-build error saved me few times before
What version of OE-Core/POoky are you using? It would be helpful to know
that.
If you are not using the Poky Distro, then you could try setting
PREMIRRORS and/or use the own-mirrors.bbclass and set SOURCE_MIRROR_URL
to something like "http://downloads.yoctoproject.org/mirror/sources/";
Sau!
Signed-off-by: Ross Burton
---
meta/classes/insane.bbclass |1 -
1 file changed, 1 deletion(-)
diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index d285e56..f52fcea 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -165,7 +165,6 @@ def pack
Many hardware platforms can autodetect their hardware and don't need a xorg.conf
at all. Make it easy for BSPs to not ship a xorg.conf by not installing empty
xorg.conf files.
Signed-off-by: Ross Burton
---
.../recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bb | 10 ++
1 file c
opkg-build verifies that conffiles exist, so verify that the specified files
actually exist before writing them to conffiles.
This mirrors the behaviour of FILES and package_rpm's CONFFILES handling.
Signed-off-by: Ross Burton
---
meta/classes/package_ipk.bbclass |3 ++-
1 file changed, 2 i
The idea of a generic xorg.conf is meaningless, especially when they specify the
"intel" driver. Empty this file so that unless the BSP specifies it's own
xorg.conf, no xorg.conf file is installed.
Signed-off-by: Ross Burton
---
.../xorg-xserver/xserver-xf86-config/xorg.conf | 26
Hi,
This series lets a BSP not ship a xorg.conf as not all BSPs need them. This is
implemented by not installing empty xorg.conf files, and making the generic
xorg.conf empty (which is a good move, as it specified the intel driver).
There's a patch to package_ipkg that's required to sanity check
On Thu, Feb 14, 2013 at 06:19:34AM -0700, Gary Thomas wrote:
> I have an customized image which explicitly names 'pulseaudio-server'
> Building my image will break if I don't also explicitly name 'consolekit'
see
http://lists.linuxtogo.org/pipermail/openembedded-core/2012-November/032203.html
>
Hi,
due to local company restrictions, I cannot clone external git repository.
During prelink-native fetch I catch the warning about that (given that the
SRC_URI point to git) but then,
trying other mirrors, system is able to download a tar.gz of the prelink.
The strange thing is that however bitb
On 14 February 2013 16:03, Trevor Woerner wrote:
> Just out of curiosity:
> - will systemd be the default?
> - will it be possible to still use/choose sysvinit (i.e. is sysvinit
> going away)?
No and yes.
> How does systemd fit in with busybox? My understanding is that busybox
> has its own init
Just out of curiosity:
- will systemd be the default?
- will it be possible to still use/choose sysvinit (i.e. is sysvinit
going away)?
How does systemd fit in with busybox? My understanding is that busybox
has its own init system. If someone enables/chooses systemd, does it
disable busybox's init
On 14/02/13 15:44, Jack Mitchell wrote:
On 14/02/13 15:31, Burton, Ross wrote:
On 14 February 2013 14:31, Jack Mitchell wrote:
Did this ever go anywhere? I have just tried again today with
exactly the
same result, all I did was change the DISTRO_FEATURES_INITMAN to
systemd.
Odd, as I just bu
For some packages PRS reported incorrect upstream version
as it was either the raw string or it mismatched some
alternative groups.
Signed-off-by: Emilia Ciobanu
---
meta/classes/distrodata.bbclass |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/meta/classes/distroda
On 14/02/13 15:31, Burton, Ross wrote:
On 14 February 2013 14:31, Jack Mitchell wrote:
Did this ever go anywhere? I have just tried again today with exactly the
same result, all I did was change the DISTRO_FEATURES_INITMAN to systemd.
Odd, as I just built and booted a systemd image (core-image
On 14 February 2013 14:02, Ian Geiser wrote:
> Hey, I noticed that systemd service files are going back into the oe-core
> layer and not always compatible with meta-oe. What is the official policy on
> systemd right now? Is it supposed to be confined to the meta-oe/meta-systemd
> layer? Or w
On 14 February 2013 14:31, Jack Mitchell wrote:
> Did this ever go anywhere? I have just tried again today with exactly the
> same result, all I did was change the DISTRO_FEATURES_INITMAN to systemd.
Odd, as I just built and booted a systemd image (core-image-sato, in
poky master), and it worked
On 14 February 2013 12:32, Florin Sarbu wrote:
> So choosing, for example ${PN} to hold the systemd services, and also choose
> to use sysvinit as the init manager, then I'd end up with a rootfs
> containing useless systemd services.
That would be a packaging bug.
The systemd class only does wor
On 13 February 2013 15:52, Florin Sarbu wrote:
> connman.inc was missing the SYSTEMD_PACKAGES variable. Declared
> ${PN}-systemd as the package containing the systemd service
> file and also added this package to PACKAGES variable.
NACK.
SYSTEMD_PACKAGES defaults to $PN so the systemd service fi
On 25/01/13 08:28, Radu Moisan wrote:
On 01/24/2013 04:52 PM, Burton, Ross wrote:
On 24 January 2013 13:03, Radu Moisan wrote:
ok, thanks Enrico, this clears the picture for me.
Well then it looks like Jack's problems is coming from some other
place.
No - /run needs to exist for the mount t
Hey, I noticed that systemd service files are going back into the oe-core layer
and not always compatible with meta-oe. What is the official policy on systemd
right now? Is it supposed to be confined to the meta-oe/meta-systemd layer?
Or what cases will they be pulled in and/or duplicated in
On 02/14/2013 01:57 PM, Mike Looijmans wrote:
On 02/14/2013 01:42 PM, Marcin Juszkiewicz wrote:
W dniu 14.02.2013 13:35, Mike Looijmans pisze:
So far i've been using good old initscripts for my systems. I want to
try out systemd. Having zero experience with that, I just added
"systemd" to the D
I have an customized image which explicitly names 'pulseaudio-server'
Building my image will break if I don't also explicitly name 'consolekit'
root@my_target:~# opkg whatdepends consolekit
Root set:
consolekit
What depends on root set
pulseaudio-module-console-kit 2.1-r15 depends on
On Thu, 2013-02-14 at 05:35 -0700, Gary Thomas wrote:
> WARNING: QA Issue: ELF binary
> '/home/local/p82_soft/tmp/work/cortexa9-vfp-neon-amltd-linux-gnueabi/gst-plugins-bad/0.10.23-r3.ti1.6.4.3/packages-split/gst-plugins-bad-vp8/usr/lib/gstreamer-0.10/libgstvp8.so'
>
> has relocations in .text
>
On 02/14/2013 01:42 PM, Marcin Juszkiewicz wrote:
W dniu 14.02.2013 13:35, Mike Looijmans pisze:
So far i've been using good old initscripts for my systems. I want to
try out systemd. Having zero experience with that, I just added
"systemd" to the DISTRO_FEATURES and started a fresh build. The
On Thu, 2013-02-14 at 05:35 -0700, Gary Thomas wrote:
> I imported libav from meta-oe into my build so I can have additional
> gstreamer support. Now I'm seeing these warnings:
>
> WARNING: QA Issue: ELF binary
> '/home/local/p82_soft/tmp/work/cortexa9-vfp-neon-amltd-linux-gnueabi/gst-plugins-ba
W dniu 14.02.2013 13:35, Mike Looijmans pisze:
> So far i've been using good old initscripts for my systems. I want to
> try out systemd. Having zero experience with that, I just added
> "systemd" to the DISTRO_FEATURES and started a fresh build. The build
> ran fine, but it produced something tha
I imported libav from meta-oe into my build so I can have additional
gstreamer support. Now I'm seeing these warnings:
WARNING: QA Issue: ELF binary
'/home/local/p82_soft/tmp/work/cortexa9-vfp-neon-amltd-linux-gnueabi/gst-plugins-bad/0.10.23-r3.ti1.6.4.3/packages-split/gst-plugins-bad-vp8/usr/l
So far i've been using good old initscripts for my systems. I want to
try out systemd. Having zero experience with that, I just added
"systemd" to the DISTRO_FEATURES and started a fresh build. The build
ran fine, but it produced something that still seems to be using
initscripts, albeit that
So choosing, for example ${PN} to hold the systemd services, and also
choose to use sysvinit as the init manager, then I'd end up with a
rootfs containing useless systemd services.
Then can someone detail what is SYSTEMD_PACKAGES used for? If it's only
for adding the packages to PACKAGES, then i
The use of arch specific variables like MIPSPKGSFX_ABI was creeping
into the -native sstate checksums of package like ncurses-native.
This is pointless and undesireable. We could add specific variable
exclusions but we might as well just brute force the code to be disabled
in the -native case sinc
On 14 February 2013 09:09, Florin Sarbu wrote:
> The issue I was referring to was that the individual packages (that contain
> the systemd service files) generated from various recipes, do not end up in
> the rootfs solely by having them declared in the SYSTEMD_PACKAGES and having
> DISTRO_FEATURE
The issue I was referring to was that the individual packages (that
contain the systemd service files) generated from various recipes, do
not end up in the rootfs solely by having them declared in the
SYSTEMD_PACKAGES and having DISTRO_FEATURES_INITMAN ="systemd". You need
now to explicitly add
On 02/13/2013 05:33 PM, Florin Sarbu wrote:
Hi all,
following the transition of the systemd.bbclass from meta-openembedded
to oe-core, I stumbled upon on what seems to me a missing feature that
has not been brought along in the new systemd.bbclass in oe-core.
Seems that if one does not explic
41 matches
Mail list logo
