Re: [yocto] How to enable UDHCP?
From: Paul D. DeRocco My build is an Intel Cedartrail system based on Dylan, using systemd. It appears to have udhcp available from busybox, but it's not running. systemd reports that it is masked, because /etc/systemd/system/busybox-udhcpc.service is linked to /dev/null. What creates this link, and how do I get the DHCP client enabled in my build? Is there something else I need to include? It appears this is masked by a post-install script in meta/recipes-core/systemd/system-compat-units.bb. The comment says Units to make systemd work better with existing sysvinit scripts. Doesn't seem like it's doing that in this case. However, if I tweak the recipe so that the systemd service unit for busybox-udhcpc isn't masked, it doesn't reveal a valid service unit, I wind up with nothing. That suggests that there should be a sysvinit script somewhere else for starting udhcpc, but I can't find anything under /etc that contains the string udhcpc other than the script that udhcpc calls when an interface changes state. I also find that I can manually run udhcpc with the appropriate interface parameter, and it works fine; my Samba server from OE becomes accessible from a Windows machine, and everything seems happy. So how is udhcpc normally supposed to be launched? I could hack it in any number of ways, but I'd like to know the right way, because I'd like it to be able to assign an address if someone plugs in a USB WiFi dongle, too, and that's beyond my ability. Or is this just something that works with sysvinit, but no one's gotten around to figuring out how to integrate it into systemd, and I'm on my own? -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Criteria for proposing a host distribution supported
Hi, may I ask if it is acceptable to target Archlinux host (64 bit) supported any time soon for a release? As I might need to work in this environment on a daily bases for a long term product, I might just need to stand up to get more involved, albeit I have already filed couple of bug reports even though those are mostly generic, not tied to Archlinux. Could you please list the criteria that it has to hit, like proper CI node for that one, whether or not someone needs to belong an organization already supporting Yocto, does it go through the vote system I have read about, and so forth? Thanks in advance, Laszlo ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Criteria for proposing a host distribution supported
On 26 July 2013 11:21, Laszlo Papp lp...@kde.org wrote: Hi, may I ask if it is acceptable to target Archlinux host (64 bit) supported any time soon for a release? I'm not in any official position within the Yocto project but I do use Arch so I'm just putting my tuppence (or 2 cents) in here. I don't think it makes sense to call a rolling-release, compiled from source and close to bleeding edge distro like Arch (or Gentoo for that matter) supported. The sanity check warning when building Poky was what made me decide to spin up a Ubuntu Server 12.04 LTS virtual machine for doing my important builds as that is a much more stable distribution. When a new official release of Ubuntu, Debian, Fedora, etc are released, a Poky build can be tested on that release and the platform certified as being supported because it's been proven to correctly build Poky. How often would you have to test Arch Linux when major package updates can occur on any given day? Don't get me wrong, I love Arch and use it on my desktop for all development work. But for builds I want to be known-good, I push them off to a Ubuntu Server virtual machine. -- Paul Barker Email: p...@paulbarker.me.uk http://www.paulbarker.me.uk ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Criteria for proposing a host distribution supported
If you do not trust Arch, you can use something else. That does not mean there would not be people who update (daily for instance) and fix the issues coming up. It is your decision not to trust Archlinux, so do I not with Ubuntu, Fedora, Debian, and so forth, but that does not mean I would like to rule them out for not being usable in your case. On Fri, Jul 26, 2013 at 11:34 AM, Paul Barker p...@paulbarker.me.uk wrote: On 26 July 2013 11:21, Laszlo Papp lp...@kde.org wrote: Hi, may I ask if it is acceptable to target Archlinux host (64 bit) supported any time soon for a release? I'm not in any official position within the Yocto project but I do use Arch so I'm just putting my tuppence (or 2 cents) in here. I don't think it makes sense to call a rolling-release, compiled from source and close to bleeding edge distro like Arch (or Gentoo for that matter) supported. The sanity check warning when building Poky was what made me decide to spin up a Ubuntu Server 12.04 LTS virtual machine for doing my important builds as that is a much more stable distribution. When a new official release of Ubuntu, Debian, Fedora, etc are released, a Poky build can be tested on that release and the platform certified as being supported because it's been proven to correctly build Poky. How often would you have to test Arch Linux when major package updates can occur on any given day? Don't get me wrong, I love Arch and use it on my desktop for all development work. But for builds I want to be known-good, I push them off to a Ubuntu Server virtual machine. -- Paul Barker Email: p...@paulbarker.me.uk http://www.paulbarker.me.uk ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Criteria for proposing a host distribution supported
Needless to mention, but just in case, the CI note for Arch could be happening with a well-documented setup. Note, how Debian, Ubuntu, and other supported distributions are untested in chroot environments for instance. It is very unlikely you can cover everything for each supported distributions, anyhow. On Fri, Jul 26, 2013 at 11:39 AM, Laszlo Papp lp...@kde.org wrote: If you do not trust Arch, you can use something else. That does not mean there would not be people who update (daily for instance) and fix the issues coming up. It is your decision not to trust Archlinux, so do I not with Ubuntu, Fedora, Debian, and so forth, but that does not mean I would like to rule them out for not being usable in your case. On Fri, Jul 26, 2013 at 11:34 AM, Paul Barker p...@paulbarker.me.ukwrote: On 26 July 2013 11:21, Laszlo Papp lp...@kde.org wrote: Hi, may I ask if it is acceptable to target Archlinux host (64 bit) supported any time soon for a release? I'm not in any official position within the Yocto project but I do use Arch so I'm just putting my tuppence (or 2 cents) in here. I don't think it makes sense to call a rolling-release, compiled from source and close to bleeding edge distro like Arch (or Gentoo for that matter) supported. The sanity check warning when building Poky was what made me decide to spin up a Ubuntu Server 12.04 LTS virtual machine for doing my important builds as that is a much more stable distribution. When a new official release of Ubuntu, Debian, Fedora, etc are released, a Poky build can be tested on that release and the platform certified as being supported because it's been proven to correctly build Poky. How often would you have to test Arch Linux when major package updates can occur on any given day? Don't get me wrong, I love Arch and use it on my desktop for all development work. But for builds I want to be known-good, I push them off to a Ubuntu Server virtual machine. -- Paul Barker Email: p...@paulbarker.me.uk http://www.paulbarker.me.uk ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Criteria for proposing a host distribution supported
On 26 July 2013 11:34, Paul Barker p...@paulbarker.me.uk wrote: may I ask if it is acceptable to target Archlinux host (64 bit) supported any time soon for a release? I'm not in any official position within the Yocto project but I do use Arch so I'm just putting my tuppence (or 2 cents) in here. I don't think it makes sense to call a rolling-release, compiled from source and close to bleeding edge distro like Arch (or Gentoo for that matter) supported. The sanity check warning when building Poky was what made me decide to spin up a Ubuntu Server 12.04 LTS virtual machine for doing my important builds as that is a much more stable distribution. When a new official release of Ubuntu, Debian, Fedora, etc are released, a Poky build can be tested on that release and the platform certified as being supported because it's been proven to correctly build Poky. How often would you have to test Arch Linux when major package updates can occur on any given day? Don't get me wrong, I love Arch and use it on my desktop for all development work. But for builds I want to be known-good, I push them off to a Ubuntu Server virtual machine. Personally speaking, what Paul said. We don't support any other unstable/rolling distribution such as Rawhide, Debian Sid/Unstable, etc either as they routinely change daily and therefore the testing that needs to be done to classify it as supported would have to be done daily. Note that the warning is entirely advisory, you can feel free to ignore it. I do so on one of my machines which runs Debian Unstable. You can even disable it by setting SANITY_TESTED_DISTROS = in your configuration. Supported here means in a normal configuration we've verified that it works, nothing more. Ross ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Criteria for proposing a host distribution supported
On Fri, Jul 26, 2013 at 11:44 AM, Burton, Ross ross.bur...@intel.comwrote: Personally speaking, what Paul said. I already replied why I think it is more blocking than helping certain part of the community. We don't support any other unstable/rolling distribution such as Rawhide, Debian Sid/Unstable, etc either as they routinely change daily and therefore the testing that needs to be done to classify it as supported would have to be done daily. Note that the warning is entirely advisory, you can feel free to ignore it. I do so on one of my machines which runs Debian Unstable. You can even disable it by setting SANITY_TESTED_DISTROS = in your configuration. Supported here means in a normal configuration we've verified that it works, nothing more. This is not different for Arch, especially with ARM (not the architecture) and similar helpers for grabbing older versions. As I wrote in a previous email of this thread: it is the matter of CI node documentation. Not to mention, it is easier to grab certain bugfixes and so forth in Arch due to the quick integration of those. If you try to do that with a stable distribution, you will end up having troubles when waiting for a fix, or going yourself to fix it. Laszlo ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Criteria for proposing a host distribution supported
On 26 July 2013 11:39, Laszlo Papp lp...@kde.org wrote: If you do not trust Arch, you can use something else. That does not mean there would not be people who update (daily for instance) and fix the issues coming up. And that already happens - I'm running Debian Unstable, others may be running Rawhide, or Arch. You'll see numerous commits in master fixing issues where updates on the *host* have broken the build[1]. Let's imagine we are testing Arch or any other rolling/development distribution. The day we freeze oe-core 1.5 we could write that Arch Linux is a tested and supported distribution, and we release. A week later Arch integrates (for example) a newer gcc that introduces some new errors, so we can't bootstrap anymore. The documentation says that Arch is tested, yet someone using Arch will discover that it doesn't work. They'll rightly complain that the documentation is wrong, and Arch doesn't work. Of course if ArchLinux decided to have a maintained stable branch, then that would be something worth testing on. Ross [1] The latest I can recall of the top of my head is 8db36429ef328b97340ee1d9fc2e697cfdd68bff. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Criteria for proposing a host distribution supported
Actually, I also have problems with Debian stable? See the bugreports I sent. It is mentioned as supported distribution. Yet, it does not work. I do not to follow the parallelism with Arch accordingly. People can always revert the offending arch package to one week older if they wanna use Yocto, or they can fix it. I do not see it a problem, and easily solvable, especially with a clear CI documentation which should happen for any node, anyhow. The problem is currently that there is no any focus on Arch, and that is bad for the Arch arch community. Note, it is not about 1-2 people. Arch is a quite common distribution, especially for development because it gives you the most power for working with bleeding edge technologies. On Fri, Jul 26, 2013 at 11:52 AM, Burton, Ross ross.bur...@intel.comwrote: On 26 July 2013 11:39, Laszlo Papp lp...@kde.org wrote: If you do not trust Arch, you can use something else. That does not mean there would not be people who update (daily for instance) and fix the issues coming up. And that already happens - I'm running Debian Unstable, others may be running Rawhide, or Arch. You'll see numerous commits in master fixing issues where updates on the *host* have broken the build[1]. Let's imagine we are testing Arch or any other rolling/development distribution. The day we freeze oe-core 1.5 we could write that Arch Linux is a tested and supported distribution, and we release. A week later Arch integrates (for example) a newer gcc that introduces some new errors, so we can't bootstrap anymore. The documentation says that Arch is tested, yet someone using Arch will discover that it doesn't work. They'll rightly complain that the documentation is wrong, and Arch doesn't work. Of course if ArchLinux decided to have a maintained stable branch, then that would be something worth testing on. Ross [1] The latest I can recall of the top of my head is 8db36429ef328b97340ee1d9fc2e697cfdd68bff. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Criteria for proposing a host distribution supported
On 26 July 2013 11:57, Laszlo Papp lp...@kde.org wrote: Actually, I also have problems with Debian stable? See the bugreports I sent. It is mentioned as supported distribution. Yet, it does not work. I do not to follow the parallelism with Arch accordingly. The words I were careful to use were normal configuration. A chroot isn't normal and needs careful attention to get the details right (such as a working /dev, /sys /dev/shm). If you can't get this configured correctly you may have more luck with a more featureful container such as systemd-nspawn or KVM, where the guest actually boots and can set itself up. Ross ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Criteria for proposing a host distribution supported
On Fri, Jul 26, 2013 at 12:05 PM, Burton, Ross ross.bur...@intel.comwrote: On 26 July 2013 11:57, Laszlo Papp lp...@kde.org wrote: Actually, I also have problems with Debian stable? See the bugreports I sent. It is mentioned as supported distribution. Yet, it does not work. I do not to follow the parallelism with Arch accordingly. The words I were careful to use were normal configuration. A chroot isn't normal and needs careful attention to get the details right (such as a working /dev, /sys /dev/shm). If you can't get this configured correctly you may have more luck with a more featureful container such as systemd-nspawn or KVM, where the guest actually boots and can set itself up. As far as I can tell, the reference documentation does not write that anywhere what you are claiming here. So you are either incorrect, or I need to file a bugreport to fix the documentation. No doubt a common normal could be found for Arch as well, which is what I have been referring to, in several emails of this thread now. I do not see Arch exclusive, respectively. Laszlo ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Criteria for proposing a host distribution supported
On 26 July 2013 11:57, Laszlo Papp lp...@kde.org wrote: Actually, I also have problems with Debian stable? See the bugreports I sent. It is mentioned as supported distribution. Yet, it does not work. I do not to follow the parallelism with Arch accordingly. The cost of supporting a distro will be dependent on the rate and magnitude of changes within that distro. Arch has large, frequent updates to core packages and so would have to be re-tested almost continuously. Stable releases of many distros limit how and when they will update things like gcc, binutils, etc and try not to introduce backwards-incompatible changes. Such things still slip through, but they are rare, so OE/Yocto can cope with the developer time needed to get the problem fixed. Supporting a rolling-release distro which follows the latest toolchain updates would essentially be an open-ended commitment. People can always revert the offending arch package to one week older if they wanna use Yocto, or they can fix it. I do not see it a problem, and easily solvable, especially with a clear CI documentation which should happen for any node, anyhow. So we'd have to say Arch Linux, with xxx version of gcc, yyy version of binutils, etc was supported, not just Arch Linux. How many packages do we specify the version of? The problem is currently that there is no any focus on Arch This is incorrect. Just because there Arch isn't supported doesn't mean no-one cares about it. When the sanity check for a broken make 3.82 was added to OE, I put in a bug report to Arch (https://bugs.archlinux.org/task/35968) and it got fixed. -- Paul Barker Email: p...@paulbarker.me.uk http://www.paulbarker.me.uk ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Criteria for proposing a host distribution supported
On Fri, Jul 26, 2013 at 12:14 PM, Paul Barker p...@paulbarker.me.uk wrote: On 26 July 2013 11:57, Laszlo Papp lp...@kde.org wrote: Actually, I also have problems with Debian stable? See the bugreports I sent. It is mentioned as supported distribution. Yet, it does not work. I do not to follow the parallelism with Arch accordingly. The cost of supporting a distro will be dependent on the rate and magnitude of changes within that distro. Arch has large, frequent updates to core packages and so would have to be re-tested almost continuously. Stable releases of many distros limit how and when they will update things like gcc, binutils, etc and try not to introduce backwards-incompatible changes. Such things still slip through, but they are rare, so OE/Yocto can cope with the developer time needed to get the problem fixed. Supporting a rolling-release distro which follows the latest toolchain updates would essentially be an open-ended commitment. I already explained that you are having a bit of double standard in here. Updating is not a necessary evil. It is actually the nice way at times when you get bugfixes, and do not wait for a simple one-liner fix for ages. Let us not argue over personal styles. I hope, decisions are not based on personal styles in here. People can always revert the offending arch package to one week older if they wanna use Yocto, or they can fix it. I do not see it a problem, and easily solvable, especially with a clear CI documentation which should happen for any node, anyhow. So we'd have to say Arch Linux, with xxx version of gcc, yyy version of binutils, etc was supported, not just Arch Linux. How many packages do we specify the version of? Obviously, the necessary few packages that are listed on the dependency page. The problem is currently that there is no any focus on Arch This is incorrect. Just because there Arch isn't supported doesn't mean no-one cares about it. When the sanity check for a broken make 3.82 was added to OE, I put in a bug report to Arch (https://bugs.archlinux.org/task/35968) and it got fixed. No no, I was referring to the Yocto project, not Archlinux, and even then: clear focus is not equal to occasional low-hanging fruit fixes. Laszlo ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Criteria for proposing a host distribution supported
On 26 July 2013 12:10, Laszlo Papp lp...@kde.org wrote: As far as I can tell, the reference documentation does not write that anywhere what you are claiming here. So you are either incorrect, or I need to file a bugreport to fix the documentation. I'd say it's a fair assumption that when the documentation says supported on FooLinux we mean supported on a typical and working installation of FooLinux. No doubt a common normal could be found for Arch as well, which is what I have been referring to, in several emails of this thread now. I do not see Arch exclusive, respectively. All Arch needs to be in the supported list is a long-term stable release, and someone willing to do the testing. You're clearly interested in being the latter, so when the former exists please say. Via Google I see there's been at least two attempts but nothing has actually stuck around. Ross ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Criteria for proposing a host distribution supported
On Fri, Jul 26, 2013 at 12:21 PM, Burton, Ross ross.bur...@intel.comwrote: On 26 July 2013 12:10, Laszlo Papp lp...@kde.org wrote: As far as I can tell, the reference documentation does not write that anywhere what you are claiming here. So you are either incorrect, or I need to file a bugreport to fix the documentation. I'd say it's a fair assumption that when the documentation says supported on FooLinux we mean supported on a typical and working installation of FooLinux. Yeah, right, fair assumption, Typical and working Needless to mention that is relative without an absolute measure. It is a fair assumption that there is no fair assumption in here as people differ. :) No doubt a common normal could be found for Arch as well, which is what I have been referring to, in several emails of this thread now. I do not see Arch exclusive, respectively. All Arch needs to be in the supported list is a long-term stable release, and someone willing to do the testing. You cannot test every variation, but that is generic, and not arch specific. However, what certain other projects do is they test a certain configuration (or range of that). You're clearly interested in being the latter, so when the former exists please say. I already said because that is how I opened this thread. Via Google I see there's been at least two attempts but nothing has actually stuck around. Well, there was the archserver project for that mean. Chakra was also freezing the core bits. Laszlo ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Packaging questions
On 2013-07-24 08:38, Burton, Ross wrote:
On 24 July 2013 15:30, Gary Thomas g...@mlbassoc.com wrote:
ERROR: QA Issue: non -dev/-dbg/-nativesdk package contains symlink .so:
amanda path
'/work/armv7a-vfp-neon-amltd-linux-gnueabi/amanda/3.3.3-r0/packages-split/amanda/usr/lib/amanda/libamar.so'
I'm curious, what does the symlink point to? It's possible that we
can refine the check to reduce the number of false positives, because
this is a fairly common one that needs to be skipped.
The .so symlink points to a fully qualified library, e.g.
-rwxr-xr-x 1 gthomas gthomas 1383729 Jul 24 06:35 libamanda-3.3.3.so
lrwxrwxrwx 1 gthomas gthomas 18 Jul 24 06:35 libamanda.so -
libamanda-3.3.3.so
The problem seems to be that this is the unqualified .so name and not a
version qualified name like 'libamanda.so.3'. The package isn't building
the version qualified names, just the fully unqualified one.
You can skip this QA test by setting INSANE_SKIP. In this case,
INSANE_SKIP_${PN} = dev-so (you can identify the tag to use by
looking through classes/insane.bbclass for the error message).
So that's not the pattern that the test was designed for (not that
it's actually implementing that design). I'm sure Amanda developers
have a reason for this, but the presence of a .so symlink in a non-dev
package is enough to trip this test, so INSANE_SKIP is the best thing
to do.
One final packaging question. In my build I have these files:
/etc/amanda/
/etc/amanda/MyConfig/
/etc/amanda/MyConfig/tapelist
/etc/amanda/MyConfig/disklist
/etc/amanda/MyConfig/amanda.conf
I want the /etc/amanda/MyConfig to be packaged separately in amanda-demo
package.
PACKAGES += ${PN}-demo
FILES_${PN}-demo += \
/etc/amanda/MyConfig/ \
/amanda \
FILES_${PN} += ${libdir} \
${libexecdir}/amanda/* \
/var/amanda \
/etc/amanda \
Sadly, the /etc/amanda/MyConfig tree is ending up in the main package. How
can I stratify it the way I want?
Thanks
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Adding a new target architecture
Hi Michael, On Saturday 20 July 2013 11:24:32 Michael Stickel wrote: is there any documentation on how to add a new target architecture (openrisc and sparc)? The poky-handbook states in chapter 3. that it's not part of that chapter and there is no other chapter explaining porting to a new architecture. We don't have specific documentation on new architectures, but it should just be an extention of adding a BSP, so see the BSP guide for general stuff: http://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html You may find the tune files in meta/conf/machine/include/ instructive as well; you could also use some of the other BSP layers as examples since some of them add support for architectures that aren't supported as part of the core. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] bitbake -c populate_sdk -v poky-image
Hi Navani, On Monday 22 July 2013 16:33:48 Navani Srivastava wrote: I want to build meta-toolchain-qte.bb as sdk while running bitbake -c populate_sdk -v core-image-minimal .. Please suggest what changes need to be done to provide this feature? At the moment you'll have to add something like the following to your image, after the inherit image or inherit core-image line: TOOLCHAIN_HOST_TASK += nativesdk-packagegroup-qte-toolchain-host You'll also need to append to the toolchain environment setup script. See what meta/recipes-qt/meta/meta-toolchain-qt.inc does and you should be able to do the same in your image recipe. (I'd like to make this easier at some point in future, so that this extra stuff isn't needed.) Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Packaging questions
On 26 July 2013 16:43, Gary Thomas g...@mlbassoc.com wrote:
One final packaging question. In my build I have these files:
/etc/amanda/
/etc/amanda/MyConfig/
/etc/amanda/MyConfig/tapelist
/etc/amanda/MyConfig/disklist
/etc/amanda/MyConfig/amanda.conf
I want the /etc/amanda/MyConfig to be packaged separately in amanda-demo
package.
PACKAGES += ${PN}-demo
FILES_${PN}-demo += \
/etc/amanda/MyConfig/ \
/amanda \
FILES_${PN} += ${libdir} \
${libexecdir}/amanda/* \
/var/amanda \
/etc/amanda \
Sadly, the /etc/amanda/MyConfig tree is ending up in the main package. How
can I stratify it the way I want?
Various things interacting explain this. Package takes files in the
order that they appear in PACKAGES, so by using += you're *appending*
amanda-demo to PACKAGES, so it's at the end. FILES_$PN defaults to a
long list of useful paths, including ${sysconfdir}.
So, two options, both of which will work:
1) prepend amanda-demo to PACKAGES, so it gets to take files first. =+
is the prepend operator.
2) Change FILES_$PN to explictly set the entire value instead of
appending the default, then you can leave out $sysconfdir.
Ross
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] It's a [PERL] lie...
On 26 July 2013 16:49, Gary Thomas g...@mlbassoc.com wrote: It turns out that PERL is the only package that cares about this DISTRO_FEATURE and it builds incorrectly if it's left out :-( Adding this feature back into my settings made PERL build properly and now Amanda runs as well. According to grep it's perl, cmake and libarchive that respect the largefile feature. If perl is known to break without largefile it's simple enough to make it error when building if the feature isn't enabled, but to be honest should we just remove this feature as it's so infrequently used? Ross ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] It's a [PERL] lie...
On 2013-07-26 09:54, Burton, Ross wrote: On 26 July 2013 16:49, Gary Thomas g...@mlbassoc.com wrote: It turns out that PERL is the only package that cares about this DISTRO_FEATURE and it builds incorrectly if it's left out :-( Adding this feature back into my settings made PERL build properly and now Amanda runs as well. According to grep it's perl, cmake and libarchive that respect the largefile feature. Indeed, I missed them in my zeal :-( I new I was looking for something that affected my problem, and perl was the key (I'm not using either of the other packages) If perl is known to break without largefile it's simple enough to make it error when building if the feature isn't enabled, but to be honest should we just remove this feature as it's so infrequently used? I'd vote for at least fixing the perl recipe. The problem is insidious; it only fails at runtime and then in mysterious ways... It also fails on every architecture I tried (x86, ARM, PPC) -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Packaging questions
On 2013-07-26 09:52, Burton, Ross wrote:
On 26 July 2013 16:43, Gary Thomas g...@mlbassoc.com wrote:
One final packaging question. In my build I have these files:
/etc/amanda/
/etc/amanda/MyConfig/
/etc/amanda/MyConfig/tapelist
/etc/amanda/MyConfig/disklist
/etc/amanda/MyConfig/amanda.conf
I want the /etc/amanda/MyConfig to be packaged separately in amanda-demo
package.
PACKAGES += ${PN}-demo
FILES_${PN}-demo += \
/etc/amanda/MyConfig/ \
/amanda \
FILES_${PN} += ${libdir} \
${libexecdir}/amanda/* \
/var/amanda \
/etc/amanda \
Sadly, the /etc/amanda/MyConfig tree is ending up in the main package. How
can I stratify it the way I want?
Various things interacting explain this. Package takes files in the
order that they appear in PACKAGES, so by using += you're *appending*
amanda-demo to PACKAGES, so it's at the end. FILES_$PN defaults to a
long list of useful paths, including ${sysconfdir}.
So, two options, both of which will work:
1) prepend amanda-demo to PACKAGES, so it gets to take files first. =+
is the prepend operator.
2) Change FILES_$PN to explictly set the entire value instead of
appending the default, then you can leave out $sysconfdir.
Option #1 is perfect and does just what I want, thanks!
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Build/install question
One final tidy-up for my Amanda recipe. In do_install() I have:
install -d -m 0777 -o amandabackup -g amandabackup ${D}/amanda
install -d -m 0777 -o amandabackup -g amandabackup
${D}/amanda/vtapes/slot{1,2,3,4}
install -d -m 0777 -o amandabackup -g amandabackup ${D}/amanda/holding
install -d -m 0777 -o amandabackup -g amandabackup
${D}/amanda/state/{curinfo,log,index}
The problem I have is that /amanda and /amanda/holding end up with
the correct file owner/group, but the others (anything that has
multiple names) end up being owned by 'root'. When I install my package,
I get this on the target:
# ls -lR /amanda/
/amanda/:
total 3
drwxr-xr-x 2 amandabackup amandabackup 1024 Jul 26 2013 holding
drwxr-xr-x 5 root root 1024 Jul 26 15:44 state
drwxr-xr-x 6 root root 1024 Jul 26 15:44 vtapes
/amanda/holding:
total 0
/amanda/state:
total 3
drwxr-xr-x 2 amandabackup amandabackup 1024 Jul 26 2013 curinfo
drwxr-xr-x 2 amandabackup amandabackup 1024 Jul 26 2013 index
drwxr-xr-x 2 amandabackup amandabackup 1024 Jul 26 2013 log
/amanda/state/curinfo:
total 0
/amanda/state/index:
total 0
/amanda/state/log:
total 0
/amanda/vtapes:
total 4
drwxr-xr-x 2 amandabackup amandabackup 1024 Jul 26 2013 slot1
drwxr-xr-x 2 amandabackup amandabackup 1024 Jul 26 2013 slot2
drwxr-xr-x 2 amandabackup amandabackup 1024 Jul 26 2013 slot3
drwxr-xr-x 2 amandabackup amandabackup 1024 Jul 26 2013 slot4
/amanda/vtapes/slot1:
total 0
/amanda/vtapes/slot2:
total 0
/amanda/vtapes/slot3:
total 0
/amanda/vtapes/slot4:
total 0
Is this to be expected, or is it a bug? If so, where do I look
and/or report it?
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Build/install question
On 2013-07-26 10:15, Gary Thomas wrote:
One final tidy-up for my Amanda recipe. In do_install() I have:
install -d -m 0777 -o amandabackup -g amandabackup ${D}/amanda
install -d -m 0777 -o amandabackup -g amandabackup
${D}/amanda/vtapes/slot{1,2,3,4}
install -d -m 0777 -o amandabackup -g amandabackup ${D}/amanda/holding
install -d -m 0777 -o amandabackup -g amandabackup
${D}/amanda/state/{curinfo,log,index}
The problem I have is that /amanda and /amanda/holding end up with
the correct file owner/group, but the others (anything that has
multiple names) end up being owned by 'root'. When I install my package,
I get this on the target:
# ls -lR /amanda/
/amanda/:
total 3
drwxr-xr-x 2 amandabackup amandabackup 1024 Jul 26 2013 holding
drwxr-xr-x 5 root root 1024 Jul 26 15:44 state
drwxr-xr-x 6 root root 1024 Jul 26 15:44 vtapes
/amanda/holding:
total 0
/amanda/state:
total 3
drwxr-xr-x 2 amandabackup amandabackup 1024 Jul 26 2013 curinfo
drwxr-xr-x 2 amandabackup amandabackup 1024 Jul 26 2013 index
drwxr-xr-x 2 amandabackup amandabackup 1024 Jul 26 2013 log
/amanda/state/curinfo:
total 0
/amanda/state/index:
total 0
/amanda/state/log:
total 0
/amanda/vtapes:
total 4
drwxr-xr-x 2 amandabackup amandabackup 1024 Jul 26 2013 slot1
drwxr-xr-x 2 amandabackup amandabackup 1024 Jul 26 2013 slot2
drwxr-xr-x 2 amandabackup amandabackup 1024 Jul 26 2013 slot3
drwxr-xr-x 2 amandabackup amandabackup 1024 Jul 26 2013 slot4
/amanda/vtapes/slot1:
total 0
/amanda/vtapes/slot2:
total 0
/amanda/vtapes/slot3:
total 0
/amanda/vtapes/slot4:
total 0
Is this to be expected, or is it a bug? If so, where do I look
and/or report it?
A little experiment shows that the problem is only with the directories
that are implicitly created, e.g. /amanda/state/
Indeed, this seems to be how install works and bitbake is using the
native host version:
root@zeus:/tmp# install -d -m 0755 -o gthomas -g gthomas
/tmp/this/is/a/long/dir/tree
root@zeus:/tmp# ls -lR /tmp/this
/tmp/this:
total 4
drwxr-xr-x 3 root root 4096 Jul 26 14:24 is
/tmp/this/is:
total 4
drwxr-xr-x 3 root root 4096 Jul 26 14:24 a
/tmp/this/is/a:
total 4
drwxr-xr-x 3 root root 4096 Jul 26 14:24 long
/tmp/this/is/a/long:
total 4
drwxr-xr-x 3 root root 4096 Jul 26 14:24 dir
/tmp/this/is/a/long/dir:
total 4
drwxr-xr-x 2 gthomas gthomas 4096 Jul 26 14:24 tree
/tmp/this/is/a/long/dir/tree:
total 0
All of the intermediate directories are owned by 'root', not
the designated owner.
Looks like I'll just work around this one...
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Discovering available Perl modules OR writing recipes for your own
Did you get an answer? I'm not seeing it. From: mulhern mulh...@gmail.commailto:mulh...@gmail.com Date: Wednesday, July 24, 2013 8:30 AM To: yocto@yoctoproject.orgmailto:yocto@yoctoproject.org yocto@yoctoproject.orgmailto:yocto@yoctoproject.org Subject: [yocto] Discovering available Perl modules OR writing recipes for your own Hi all, I'm working on a recipe for pullledpork, which is a Perl app which grabs and combines Snort rules from various sites. My questions all revolve around pulledpork's various module dependencies. pulledpork tries to use the module Crypt::SSLeay and in my current configuration it can't find it. It is very easy to write a little recipes that provides this module and forge ahead. But I'm not sure that that is the correct thing to do...especially as it looks like I'll have to do the same thing for another ten or so tiny modules if I take that approach. First, is there some way that I can find out whether that or any particular Perl module is provided by some recipe somewhere? My plan would be to RDEPEND on every available Perl module, forcing them all to be installed in the right place, run the pulledpork script, do the right think to provide any modules still missing until the script can actually complete, and then remove from RDEPENDS all previously included modules that don't show up a values in %INC. So far, so good, but I don't know how to even locate all the Perl modules that are already available. Second, if the modules really are not available is there a better way to package them up than writing individual recipes for each and every missing module? Third, are there naming conventions that should be followed? For example there is a recipe for liburi-perl that provides the very simply named Perl module URI. Thanks! - mulhern ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
