Re: [yocto] [meta-freescale] Including Static Libraries from sysroot in an autotools based package
On Mar 20, 2015, at 1:09 AM, Priya Agarwal
priya_agar...@students.iitmandi.ac.in wrote:
Hello,
Sorry to ask this question but I am unable to find any answer in reference
manuals.
${CC} is a c compiler. For c++ is it ${CXX} or something else.
Yes, you can always do bitbake -e somepackage | grep -e “^CXX=“
and figure out various variables that you want to evaluate
Thanks.
On Fri, Mar 20, 2015 at 9:07 AM, Priya Agarwal
priya_agar...@students.iitmandi.ac.in
mailto:priya_agar...@students.iitmandi.ac.in wrote:
I have edited the Makefile.am as well in this way:
squid_LDADD += -lusdpaa_of
Then I just retarred squid code and build it again.
And The libraries are shown in the compile command as well, when I see the
log.do_compile generated during the build.
Check Line number 403 in this pastebin link. (ctrl+F 'usdpaa_of' could show
where all it occurs). http://pastebin.com/LpaymTQa
http://pastebin.com/LpaymTQa
So how is it possible they are not actually linked.
I even checked the OVERRIDE variable in bitbake.conf which is set correctly.
I really need to link this library. :/
On Fri, Mar 20, 2015 at 8:43 AM, Khem Raj raj.k...@gmail.com
mailto:raj.k...@gmail.com wrote:
On Mar 19, 2015, at 2:07 AM, Priya Agarwal
priya_agar...@students.iitmandi.ac.in
mailto:priya_agar...@students.iitmandi.ac.in wrote:
Hi,
I need to link some libraries which are in sysroot into my source code.
These are usdpaa libraries.
I added DEPENDS += usdpaa in .bb file.
Apart from that also changed the Makefile.am of my source to include the
following:
area_LDADD = -lusdpaa_of
Then I ran aclocal, autoconf, automake --add-missing and retarred my package.
When the package is being built from recipe, do_compile fails. It shows
undefined reference to error.
So this means that libraries are not getting linked by just doing the above
changes. What else I need to change?
I think you need to specify them in Makefile.am using LDADD since it is using
auto tools. Please take a look at Automake documentation
http://www.gnu.org/software/automake/manual/html_node/Linking.html
http://www.gnu.org/software/automake/manual/html_node/Linking.html
might be helpful.
I think this problem is specific to autotools based projects as when I
include the libraries during the gcc command they are easily included.
do_compile() {
${CC} check.c -o check -lusdpaa_of
}
link to area.bb http://area.bb/
http://pastebin.com/Bef2C7nX http://pastebin.com/Bef2C7nX--
___
yocto mailing list
yocto@yoctoproject.org mailto:yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
https://lists.yoctoproject.org/listinfo/yocto
--
___
meta-freescale mailing list
meta-freesc...@yoctoproject.org mailto:meta-freesc...@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-freescale
https://lists.yoctoproject.org/listinfo/meta-freescale
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-freescale] Including Static Libraries from sysroot in an autotools based package
Hello,
Sorry to ask this question but I am unable to find any answer in reference
manuals.
${CC} is a c compiler. For c++ is it ${CXX} or something else.
Thanks.
On Fri, Mar 20, 2015 at 9:07 AM, Priya Agarwal
priya_agar...@students.iitmandi.ac.in wrote:
I have edited the Makefile.am as well in this way:
squid_LDADD += -lusdpaa_of
Then I just retarred squid code and build it again.
And The libraries are shown in the compile command as well, when I see the
log.do_compile generated during the build.
Check Line number 403 in this pastebin link. (ctrl+F 'usdpaa_of' could
show where all it occurs). http://pastebin.com/LpaymTQa
So how is it possible they are not actually linked.
I even checked the OVERRIDE variable in bitbake.conf which is set
correctly.
I really need to link this library. :/
On Fri, Mar 20, 2015 at 8:43 AM, Khem Raj raj.k...@gmail.com wrote:
On Mar 19, 2015, at 2:07 AM, Priya Agarwal
priya_agar...@students.iitmandi.ac.in wrote:
Hi,
I need to link some libraries which are in sysroot into my source code.
These are usdpaa libraries.
I added DEPENDS += usdpaa in .bb file.
Apart from that also changed the Makefile.am of my source to include the
following:
area_LDADD = -lusdpaa_of
Then I ran aclocal, autoconf, automake --add-missing and retarred my
package.
When the package is being built from recipe, do_compile fails. It shows
undefined reference to error.
So this means that libraries are not getting linked by just doing the
above changes. What else I need to change?
I think you need to specify them in Makefile.am using LDADD since it is
using auto tools. Please take a look at Automake documentation
http://www.gnu.org/software/automake/manual/html_node/Linking.html
might be helpful.
I think this problem is specific to autotools based projects as when I
include the libraries during the gcc command they are easily included.
do_compile() {
${CC} check.c -o check -lusdpaa_of
}
link to area.bb
http://pastebin.com/Bef2C7nX
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
--
___
meta-freescale mailing list
meta-freesc...@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-freescale
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Embedded Linux Package Management
On Fri, Mar 20, 2015 at 2:21 PM, Alex J Lennon ajlen...@dynamicdevices.co.uk wrote: On 20/03/2015 09:34, Prasant J wrote: Hi, I'm looking for package management for my embedded linux systems (yocto on armv7 iMX6Q) I'm looking for the following features: (a) Install remove a package (b) Install packages and its dependencies (c) Install a package with conflicts, such that the conflicting package is force removed (d) A local location with packages should serve as a package source (e) Remote server package (http file server based) (f) List of my packages installed (g) List of my packages not installed but available on the http file server (h) List of my packages that have updates (new version) (i) To be able to manage packages for multiple architectures (eg. rpm can produce packages for multiple architectures using one spec file) The above features will be invoked by the application GUI. Any suggestions: which package management solution would answer all the above use cases? (e) I use smart + RPM. I have a remote package server setup via this in local.conf FEED_DEPLOYDIR_BASE_URI = http://packages.foo.bar; Then I'm rsyncing the files up to the server after a bitbake package-index. Then smart update / search / install That seems to work well in my testing. Hi Alex, Thanks for inputs! Is smart development stopped? When I look at their mailing list it, the last posts were in Nov 2014. It looks like no more development for smart package manager. I would then tend to say that it will not be a right way for me. Regards, Pj -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Embedded Linux Package Management
On 20/03/2015 11:15, Prasant J wrote: On Fri, Mar 20, 2015 at 2:21 PM, Alex J Lennon ajlen...@dynamicdevices.co.uk wrote: On 20/03/2015 09:34, Prasant J wrote: Hi, I'm looking for package management for my embedded linux systems (yocto on armv7 iMX6Q) I'm looking for the following features: (a) Install remove a package (b) Install packages and its dependencies (c) Install a package with conflicts, such that the conflicting package is force removed (d) A local location with packages should serve as a package source (e) Remote server package (http file server based) (f) List of my packages installed (g) List of my packages not installed but available on the http file server (h) List of my packages that have updates (new version) (i) To be able to manage packages for multiple architectures (eg. rpm can produce packages for multiple architectures using one spec file) The above features will be invoked by the application GUI. Any suggestions: which package management solution would answer all the above use cases? (e) I use smart + RPM. I have a remote package server setup via this in local.conf FEED_DEPLOYDIR_BASE_URI = http://packages.foo.bar; Then I'm rsyncing the files up to the server after a bitbake package-index. Then smart update / search / install That seems to work well in my testing. Hi Alex, Thanks for inputs! Is smart development stopped? When I look at their mailing list it, the last posts were in Nov 2014. It looks like no more development for smart package manager. I would then tend to say that it will not be a right way for me. I don't know. To me the question would be does it do want I need it to do as well as I need it to do it, rather than asking whether there is a lot of activity. One might take the view that if it is doing its job, a lack of activity is a sign that it's a mature piece of software that needs little further development. You'll have to make that decision yourself. My understanding is that smart is the recommended way to do things (at least it was what was recommended to me) - https://wiki.yoctoproject.org/wiki/Smart Regards, Alex -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Embedded Linux Package Management
On 20/03/2015 09:34, Prasant J wrote: Hi, I'm looking for package management for my embedded linux systems (yocto on armv7 iMX6Q) I'm looking for the following features: (a) Install remove a package (b) Install packages and its dependencies (c) Install a package with conflicts, such that the conflicting package is force removed (d) A local location with packages should serve as a package source (e) Remote server package (http file server based) (f) List of my packages installed (g) List of my packages not installed but available on the http file server (h) List of my packages that have updates (new version) (i) To be able to manage packages for multiple architectures (eg. rpm can produce packages for multiple architectures using one spec file) The above features will be invoked by the application GUI. Any suggestions: which package management solution would answer all the above use cases? (e) I use smart + RPM. I have a remote package server setup via this in local.conf FEED_DEPLOYDIR_BASE_URI = http://packages.foo.bar; Then I'm rsyncing the files up to the server after a bitbake package-index. Then smart update / search / install That seems to work well in my testing. Regards, Alex -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] customising root file system by removing the unwanted commands and libraries
Hi Dilip, On Wednesday 18 March 2015 03:00:37 Dilip Basavaraju wrote: I want to build an RFS, which I need to customize it by removing the unwanted packages and particular commands which is not used by me. Please suggest me how to customize, or refer me for documents where I can read and understand completely all the details about customization. For example: /bin will have cat, ls, cd, lsmod, wc . I want to remove wc and lsmod and minimize my RFS as much as possible. We have a general guide that might be useful here: http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#building-a-tiny-system (Whether you actually need to use poky-tiny itself is a separate question, but it does explain some of the techniques used to generate it.) Ultimately, removing things comes down to figuring out how they got there in the first place. The Toaster Web UI, or the graphs produced by buildhistory for the image and bitbake -g may be useful in that process - but note that not everything can be removed easily. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Embedded Linux Package Management
On Friday 20 March 2015 11:26:43 Alex J Lennon wrote: On 20/03/2015 11:15, Prasant J wrote: On Fri, Mar 20, 2015 at 2:21 PM, Alex J Lennon ajlen...@dynamicdevices.co.uk wrote: On 20/03/2015 09:34, Prasant J wrote: Hi, I'm looking for package management for my embedded linux systems (yocto on armv7 iMX6Q) I'm looking for the following features: (a) Install remove a package (b) Install packages and its dependencies (c) Install a package with conflicts, such that the conflicting package is force removed (d) A local location with packages should serve as a package source (e) Remote server package (http file server based) (f) List of my packages installed (g) List of my packages not installed but available on the http file server (h) List of my packages that have updates (new version) (i) To be able to manage packages for multiple architectures (eg. rpm can produce packages for multiple architectures using one spec file) The above features will be invoked by the application GUI. Any suggestions: which package management solution would answer all the above use cases? (e) I use smart + RPM. I have a remote package server setup via this in local.conf FEED_DEPLOYDIR_BASE_URI = http://packages.foo.bar; Then I'm rsyncing the files up to the server after a bitbake package-index. Then smart update / search / install That seems to work well in my testing. Hi Alex, Thanks for inputs! Is smart development stopped? When I look at their mailing list it, the last posts were in Nov 2014. It looks like no more development for smart package manager. I would then tend to say that it will not be a right way for me. I don't know. To me the question would be does it do want I need it to do as well as I need it to do it, rather than asking whether there is a lot of activity. One might take the view that if it is doing its job, a lack of activity is a sign that it's a mature piece of software that needs little further development. You'll have to make that decision yourself. My understanding is that smart is the recommended way to do things (at least it was what was recommended to me) - https://wiki.yoctoproject.org/wiki/Smart FYI, here is some of the thinking that led to the decision to use smart: https://lists.yoctoproject.org/pipermail/yocto/2012-October/010384.html Of course that was a few years ago now - we probably ought to look at the RPM landscape again (e.g. DNF) and see if any change is warranted. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Embedded Linux Package Management
On Friday 20 March 2015 11:10:39 Paul Eggleton wrote: On Friday 20 March 2015 11:26:43 Alex J Lennon wrote: On 20/03/2015 11:15, Prasant J wrote: On Fri, Mar 20, 2015 at 2:21 PM, Alex J Lennon ajlen...@dynamicdevices.co.uk wrote: On 20/03/2015 09:34, Prasant J wrote: Hi, I'm looking for package management for my embedded linux systems (yocto on armv7 iMX6Q) I'm looking for the following features: (a) Install remove a package (b) Install packages and its dependencies (c) Install a package with conflicts, such that the conflicting package is force removed (d) A local location with packages should serve as a package source (e) Remote server package (http file server based) (f) List of my packages installed (g) List of my packages not installed but available on the http file server (h) List of my packages that have updates (new version) (i) To be able to manage packages for multiple architectures (eg. rpm can produce packages for multiple architectures using one spec file) The above features will be invoked by the application GUI. Any suggestions: which package management solution would answer all the above use cases? (e) I use smart + RPM. I have a remote package server setup via this in local.conf FEED_DEPLOYDIR_BASE_URI = http://packages.foo.bar; Then I'm rsyncing the files up to the server after a bitbake package-index. Then smart update / search / install That seems to work well in my testing. Hi Alex, Thanks for inputs! Is smart development stopped? When I look at their mailing list it, the last posts were in Nov 2014. It looks like no more development for smart package manager. I would then tend to say that it will not be a right way for me. I don't know. To me the question would be does it do want I need it to do as well as I need it to do it, rather than asking whether there is a lot of activity. One might take the view that if it is doing its job, a lack of activity is a sign that it's a mature piece of software that needs little further development. You'll have to make that decision yourself. My understanding is that smart is the recommended way to do things (at least it was what was recommended to me) - https://wiki.yoctoproject.org/wiki/Smart FYI, here is some of the thinking that led to the decision to use smart: https://lists.yoctoproject.org/pipermail/yocto/2012-October/010384.html Of course that was a few years ago now - we probably ought to look at the RPM landscape again (e.g. DNF) and see if any change is warranted. I forgot to mention, we do have some basic documentation here on setting up a feed if you hadn't already seen it: http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#using-runtime-package-management Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 0/2][autobuilder] Some fixes for PublishArtifacts
When deploying an autobuilder today I had to make a couple of changes to for variables I'd set in config/autobuilder.conf to work. The first patch for TMP_DIR seems good enough but the second for publishing sstate I'm more than a little wary of, mainly because you have to enable sharing sstate in two places (which is twice as many chances it'll be misconfigured)... Joshua Lock (2): PublishArtifacts.py: respect TMP_DIR if it's set PublishArtifacts: enable publishing of sstate .../autobuilder/buildsteps/PublishArtifacts.py | 51 ++ 1 file changed, 33 insertions(+), 18 deletions(-) -- 2.1.0 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 1/2] PublishArtifacts.py: respect TMP_DIR if it's set
If TMP_DIR is set look there for artifacts to publish, rather than a tmp
directory which is a child of basedir.
Signed-off-by: Joshua Lock joshua.l...@collabora.co.uk
---
.../autobuilder/buildsteps/PublishArtifacts.py | 39 --
1 file changed, 21 insertions(+), 18 deletions(-)
diff --git
a/lib/python2.7/site-packages/autobuilder/buildsteps/PublishArtifacts.py
b/lib/python2.7/site-packages/autobuilder/buildsteps/PublishArtifacts.py
index e636fe5..aee3d1f 100644
--- a/lib/python2.7/site-packages/autobuilder/buildsteps/PublishArtifacts.py
+++ b/lib/python2.7/site-packages/autobuilder/buildsteps/PublishArtifacts.py
@@ -47,6 +47,9 @@ class PublishArtifacts(ShellCommand):
self.basedir=os.path.join(os.path.join(
self.workerdir, buildername),
build/build/)
+self.tmpdir = os.environ.get(TMP_DIR)
+if self.tmpdir is None:
+self.tmpdir = os.path.join(self.basedir, tmp)
command=
DATESTAMP=datetime.datetime.now().strftime(%Y%m%d)
if str(os.environ.get('PUBLISH_BUILDS')) == True:
@@ -72,17 +75,17 @@ class PublishArtifacts(ShellCommand):
if artifact == adt-installer:
command=command+mkdir -p + os.path.join(DEST,
ADT_INST_PUBLISH_DIR) + ;
command=command+cp -R --no-dereference --preserve=links
+ \
-os.path.join(self.basedir,
tmp/deploy/sdk/) + \
+os.path.join(self.tmpdir, deploy/sdk/) +
\
*adt* + os.path.join(DEST,
ADT_INST_PUBLISH_DIR) + ;
elif artifact == adt-installer-QA:
command=command+mkdir -p + os.path.join(DEST,
ADTQA_INST_PUBLISH_DIR) + ;
command=command+cp -R --no-dereference --preserve=links
+ \
-os.path.join(self.basedir,
tmp/deploy/sdk/) + \
+os.path.join(self.tmpdir, deploy/sdk/) +
\
*adt* + os.path.join(DEST,
ADTQA_INST_PUBLISH_DIR)+ ;
elif artifact == adtrepo-dev:
adt_dev_dest= os.environ.get(ADTREPO_DEV_PATH) + / +
distroversion + - + got_revision_poky + '-' + self.getProperty(branch_poky)
command=command+mkdir -p + adt_dev_dest + /adt-ipk;
-command=command+rsync -av + os.path.join(self.basedir,
tmp/deploy/ipk/) + + adt_dev_dest + /adt-ipk;
+command=command+rsync -av + os.path.join(self.tmpdir,
deploy/ipk/) + + adt_dev_dest + /adt-ipk;
command=command+rm -rf + adt_dev_dest + /rootfs; mkdir
-p + adt_dev_dest + /rootfs;
command=command+for x in `ls + DEST +
/machines/qemu/|grep -v tiny`; do ln -s + DEST + /machines/qemu/$x +
adt_dev_dest + /rootfs/$x; done;
if self.layerversion_yocto is not None and
int(self.layerversion_yocto) 2:
@@ -98,49 +101,49 @@ class PublishArtifacts(ShellCommand):
command=command+mkdir -p + DEST + / + BA_PUBLISH_DIR
+ ;
if self.layerversion_core is not None and
int(self.layerversion_core) 2:
command=command+cp -R --no-dereference
--preserve=links + \
-os.path.join(self.basedir,
tmp/deploy/images/qemux86-64/*.zip) + \
+os.path.join(self.tmpdir,
deploy/images/qemux86-64/*.zip) + \
+ DEST + / + BA_PUBLISH_DIR + ;
else:
command=command+cp -R --no-dereference
--preserve=links + \
-os.path.join(self.basedir,
tmp/deploy/images/*.zip) + \
+os.path.join(self.tmpdir,
deploy/images/*.zip) + \
+ DEST + / + BA_PUBLISH_DIR + ;
elif artifact == buildtools-tarball:
command=command+mkdir -p + DEST + /buildtools;
command=command+cp -R --no-dereference --preserve=links
+ \
-os.path.join(self.basedir,
tmp/deploy/sdk/*.sh) + \
+os.path.join(self.tmpdir,
deploy/sdk/*.sh) + \
+ DEST + /buildtools;
elif artifact == rpm:
command=command+mkdir -p + os.path.join(DEST,
RPM_PUBLISH_DIR) + ;
command=command+cp -R --no-dereference --preserve=links
+ \
-os.path.join(self.basedir,
tmp/deploy/rpm/* ) + \
+os.path.join(self.tmpdir, deploy/rpm/* )
+ \
os.path.join(DEST, RPM_PUBLISH_DIR) + ;
elif artifact ==
[yocto] [PATCH 2/2] PublishArtifacts: enable publishing of sstate
The PUBLISH_SSTATE variable in config/autobuilder.conf didnt' appear to be wired up anywhere so I've forced it into PublishArtifacts here. I consider this patch an RFC because a) it required both the PUBLISH_SSTATE variable to be set and b) an sstate parameter to be passed to the PublishArtifacts step. Having to turn things on twice is not good. Signed-off-by: Joshua Lock joshua.l...@collabora.co.uk --- .../site-packages/autobuilder/buildsteps/PublishArtifacts.py | 12 1 file changed, 12 insertions(+) diff --git a/lib/python2.7/site-packages/autobuilder/buildsteps/PublishArtifacts.py b/lib/python2.7/site-packages/autobuilder/buildsteps/PublishArtifacts.py index aee3d1f..58add14 100644 --- a/lib/python2.7/site-packages/autobuilder/buildsteps/PublishArtifacts.py +++ b/lib/python2.7/site-packages/autobuilder/buildsteps/PublishArtifacts.py @@ -127,6 +127,18 @@ class PublishArtifacts(ShellCommand): command=command+cp -R --no-dereference --preserve=links + \ os.path.join(self.tmpdir, deploy/ipk/* ) + \ os.path.join(DEST, IPK_PUBLISH_DIR) + ; +elif artifact == sstate: +if str(os.environ.get(PUBLISH_SSTATE)) == True: +sstate_dir = os.environ.get(SSTATE_DIR) +pub_dir = os.environ.get(SSTATE_PUBLISH_DIR) +if sstate_dir is not None and pub_dir is not None: +command=command+mkdir -p + pub_dir + ; +command=command+cp -R --no-dereference --preserve=links + \ + sstate_dir + /* + pub_dir + ; +else: +command=command+echo 'Skipping copy of sstate, directories not configured.'; +else: +command=command+echo 'Skipping copy of sstate, PUBLISH_SSTATE not set.'; elif artifact == toolchain: command=command+mkdir -p + os.path.join(DEST, X86TC_PUBLISH_DIR) + ; command=command+cp -R --no-dereference --preserve=links + \ -- 2.1.0 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] unpacking poky-dora-10.0.4.tar.bz2
On 20 March 2015 at 14:53, Trevor Woerner twoer...@gmail.com wrote: Hi, When I download and unpack poky-dora-10.0.4.tar.bz2 from http://downloads.yoctoproject.org/releases/yocto/yocto-1.5.4/poky-dora-10.0.4.tar.bz2 I end up with a directory called poky-de14d21bc6633ddeb810cef051b91ee322276496 instead of (the expected?) poky-dora-10.0.4. Is this expected? No, it's not. It's an old bug that has crept back into the release process. The directory name should be poky-dora-10.0.4. I'll fix the tarball ASAP. -b Best regards, Trevor -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- Elizabeth Flanagan Yocto Project Build and Release -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] unpacking poky-dora-10.0.4.tar.bz2
Hi, When I download and unpack poky-dora-10.0.4.tar.bz2 from http://downloads.yoctoproject.org/releases/yocto/yocto-1.5.4/poky-dora-10.0.4.tar.bz2 I end up with a directory called poky-de14d21bc6633ddeb810cef051b91ee322276496 instead of (the expected?) poky-dora-10.0.4. Is this expected? Best regards, Trevor -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] unpacking poky-dora-10.0.4.tar.bz2
On 03/20/15 11:06, Flanagan, Elizabeth wrote: The directory name should be poky-dora-10.0.4. I'll fix the tarball ASAP. -b Great, thanks. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [linux-yocto] [PATCH] LSI AXXIA updates to 3.10 and 3.14 meta branches
On 2015-03-20 2:45 PM, Daniel Dragomir wrote: Hi Bruce, I created the kernel fragments for AXXIAPOWERPC bsp also. If everything is fine, please merge them for both 3.10 and 3.14 repos. The looked fine to me, so I went ahead and merged them to 3.10 and 3.14. I'll send SRCREV updates out on Monday. Cheers, Bruce Regards, Daniel Daniel Dragomir (1): meta: axxiapowerpc: Adding new fragment .../bsp/axxiapowerpc/axxiapowerpc-preempt-rt.scc |8 + .../bsp/axxiapowerpc/axxiapowerpc-standard.scc |9 ++ .../kernel-cache/bsp/axxiapowerpc/axxiapowerpc.cfg | 160 .../kernel-cache/bsp/axxiapowerpc/axxiapowerpc.scc |8 + .../kernel-cache/bsp/axxiapowerpc/no-preempt.cfg |1 + .../kernel-cache/bsp/axxiapowerpc/no-preempt.scc |1 + meta/cfg/kernel-cache/bsp/axxiapowerpc/rapidio.cfg | 12 ++ meta/cfg/kernel-cache/bsp/axxiapowerpc/rapidio.scc |4 + 8 files changed, 203 insertions(+) create mode 100644 meta/cfg/kernel-cache/bsp/axxiapowerpc/axxiapowerpc-preempt-rt.scc create mode 100644 meta/cfg/kernel-cache/bsp/axxiapowerpc/axxiapowerpc-standard.scc create mode 100644 meta/cfg/kernel-cache/bsp/axxiapowerpc/axxiapowerpc.cfg create mode 100644 meta/cfg/kernel-cache/bsp/axxiapowerpc/axxiapowerpc.scc create mode 100644 meta/cfg/kernel-cache/bsp/axxiapowerpc/no-preempt.cfg create mode 100644 meta/cfg/kernel-cache/bsp/axxiapowerpc/no-preempt.scc create mode 100644 meta/cfg/kernel-cache/bsp/axxiapowerpc/rapidio.cfg create mode 100644 meta/cfg/kernel-cache/bsp/axxiapowerpc/rapidio.scc -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH] LSI AXXIA updates to 3.10 and 3.14 meta branches
Hi Bruce, I created the kernel fragments for AXXIAPOWERPC bsp also. If everything is fine, please merge them for both 3.10 and 3.14 repos. Regards, Daniel Daniel Dragomir (1): meta: axxiapowerpc: Adding new fragment .../bsp/axxiapowerpc/axxiapowerpc-preempt-rt.scc |8 + .../bsp/axxiapowerpc/axxiapowerpc-standard.scc |9 ++ .../kernel-cache/bsp/axxiapowerpc/axxiapowerpc.cfg | 160 .../kernel-cache/bsp/axxiapowerpc/axxiapowerpc.scc |8 + .../kernel-cache/bsp/axxiapowerpc/no-preempt.cfg |1 + .../kernel-cache/bsp/axxiapowerpc/no-preempt.scc |1 + meta/cfg/kernel-cache/bsp/axxiapowerpc/rapidio.cfg | 12 ++ meta/cfg/kernel-cache/bsp/axxiapowerpc/rapidio.scc |4 + 8 files changed, 203 insertions(+) create mode 100644 meta/cfg/kernel-cache/bsp/axxiapowerpc/axxiapowerpc-preempt-rt.scc create mode 100644 meta/cfg/kernel-cache/bsp/axxiapowerpc/axxiapowerpc-standard.scc create mode 100644 meta/cfg/kernel-cache/bsp/axxiapowerpc/axxiapowerpc.cfg create mode 100644 meta/cfg/kernel-cache/bsp/axxiapowerpc/axxiapowerpc.scc create mode 100644 meta/cfg/kernel-cache/bsp/axxiapowerpc/no-preempt.cfg create mode 100644 meta/cfg/kernel-cache/bsp/axxiapowerpc/no-preempt.scc create mode 100644 meta/cfg/kernel-cache/bsp/axxiapowerpc/rapidio.cfg create mode 100644 meta/cfg/kernel-cache/bsp/axxiapowerpc/rapidio.scc -- 1.7.9.5 -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
[yocto] Embedded Linux Package Management
Hi, I'm looking for package management for my embedded linux systems (yocto on armv7 iMX6Q) I'm looking for the following features: (a) Install remove a package (b) Install packages and its dependencies (c) Install a package with conflicts, such that the conflicting package is force removed (d) A local location with packages should serve as a package source (e) Remote server package (http file server based) (f) List of my packages installed (g) List of my packages not installed but available on the http file server (h) List of my packages that have updates (new version) (i) To be able to manage packages for multiple architectures (eg. rpm can produce packages for multiple architectures using one spec file) The above features will be invoked by the application GUI. Any suggestions: which package management solution would answer all the above use cases? I have tried smart + rpm, but from my preliminary research suggests that smart is no longer developed (Am I correct?). Also I failed to setup remote repository [case (e)] and also case (h) failed. I am currently trying out yum + rpm, but it fails to answer case (f). It can lists all my packages but does not tell me if it is installed or available on the repo. I could make it work by additional steps (work around), but it will be good if the tool itself supports these features. It also fails case (c), does not force remove conflicting package. I also looked at opkg, but the last stable release seems to be v0.2.4 (v0.3.0-rc2 is current). Is it mature enough to be used? Does ipk packages support all features as rpm packages would support (dependencies, conflicts, groups) ? Sorry for asking a lot of questions. It would be very helpful if someone who has worked with package management on linux systems can give some inputs. Thanks in advance! Regards, Pj -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
