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
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 14 February 2013 09:09, Florin Sarbu florin.sa...@windriver.com 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
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
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
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 a
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
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 that
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
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:
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
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 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
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 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 radu.moi...@intel.com 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
On 13 February 2013 15:52, Florin Sarbu florin.sa...@windriver.com 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
On 14 February 2013 12:32, Florin Sarbu florin.sa...@windriver.com 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
On 14 February 2013 14:31, Jack Mitchell m...@communistcode.co.uk 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
On 14 February 2013 14:02, Ian Geiser igei...@devonit.com 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
On 14/02/13 15:31, Burton, Ross wrote:
On 14 February 2013 14:31, Jack Mitchell m...@communistcode.co.uk 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
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 emilia.maria.silvia.ciob...@intel.com
---
meta/classes/distrodata.bbclass |6 +++---
1 file changed, 3 insertions(+), 3
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 m...@communistcode.co.uk 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
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
On 14 February 2013 16:03, Trevor Woerner twoer...@gmail.com 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
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
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,
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
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 ross.bur...@intel.com
---
.../xorg-xserver/xserver-xf86-config/xorg.conf
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 ross.bur...@intel.com
---
meta/classes/package_ipk.bbclass |3
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 ross.bur...@intel.com
---
.../recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bb |
Signed-off-by: Ross Burton ross.bur...@intel.com
---
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
@@
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!
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
On 14 February 2013 18:31, Martin Jansa martin.ja...@gmail.com 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,
Override the hard-coded CFLAGS used in Makefile
to reference our CFLAGS.
Upstream-Status: Pending
Signed-off-by: Joe Slater jsla...@windriver.com
---
meta/recipes-bsp/acpid/acpid.inc |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-bsp/acpid/acpid.inc
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
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 m...@communistcode.co.uk
wrote:
Did this ever go anywhere? I have just tried again today with
exactly the
same result, all I did was
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 s...@linux.intel.com
---
From: Matthew McClintock m...@freescale.com
This improves reusabiliy of sstate-cache across different hosts
Signed-odd-by: Matthew McClintock m...@freescale.com
Signed-off-by: Saul Wold s...@linux.intel.com
---
meta/recipes-core/glib-2.0/glib-2.0_2.32.4.bb | 2 +-
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:
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!
41 matches
Mail list logo
