[yocto] Raspberry Pi [was Re: Kernel modules fail to compile for ARM]
On 14/05/12 19:52, Chris Tapp wrote: > I'm trying to put a BSP together for an ARM system (Raspberry Pi, > ARM1176JZF-S CPU). I got the feeling that there might be multiple OE/RPI efforts going on at the same time unaware of each other, e.g., I noticed this meta-raspberrypi layer on github that seems to be well on the way, https://github.com/djwillis/meta-raspberrypi ... perhaps getting various folk interested in this together would be beneficial. Tomas ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Download mirror instability
The new download mirror is now active. Fetching from downloads.yoctoproject.org should be reliable once again. Michael Halstead Yocto Project / Sys Admin On 05/14/2012 08:21 PM, Michael Halstead wrote: > > We are experiencing download mirror instability that began with a DDOS > on Friday. Since then the network configuration attached to the mirror > server has been in flux. This caused several outages. Fetcher failures > during the last 36 hours are probably caused by these issues. > > I am in the process of building a new download server which will help > with stability. I will post to the list when the build is complete. > > Michael Halstead > Yocto Project / Sys Admin > smime.p7s Description: S/MIME Cryptographic Signature ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Fwd: Narcissus update <- IMPORTANT
Apologies for the massive cross-post, but most users don't read the development lists :) To avoid 'reply all' mistakes the addressed lists are in BCC. In case you are wondering which lists: the beagleboard list, the meta-ti list and the yocto project list. A minor update to the below: the test server will be down for a short time wednesday to upgrade the RAM. Begin doorgestuurd bericht: > Van: Koen Kooi > Onderwerp: Narcissus update <- IMPORTANT > Datum: 3 mei 2012 11:49:56 GMT+02:00 > Aan: Discussion of the angstrom distribution development > > > Hi, > > With the change to an oe-core based system a lot of things changed and > angstrom itself has gone through some changes as well. One of those changes > is that some packages were renamed or deprecated. > To keep narcissus working the decision was made to remove all machines and > trim the package lists. > > The new machine list matches the autobuilder: qemuarm, qemumips, qemuppc, > qemux86, beagleboard and beagleboard. That matches the machines supported in > OE-core and the ones I get paid to support for my day job. > > The branch: > https://github.com/Angstrom-distribution/narcissus/commits/core-update > Test setup: http://dominion.thruhere.net/koen/narcissus/ > > The process to add machines is fairly simple: > > 1) Find the layer for the machine in > http://www.openembedded.org/wiki/LayerIndex > 2) Check the setup scripts to see if it's already configured > 3) Send patch for setupscripts > 4) Send patch for narcissus > > The process for packages is pretty much the same. The will need review since > not every layer plays nice with others. I'm hoping that this process will be > easy enough for people to follow while preventing non-working combinations to > get added. > > As always, feedback appreciated. > > regards, > > Koen ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Raspberry Pi [was Re: Kernel modules fail to compile for ARM]
Hi Tomas, > On 14/05/12 19:52, Chris Tapp wrote: > > I'm trying to put a BSP together for an ARM system (Raspberry Pi, > ARM1176JZF-S CPU). > > I got the feeling that there might be multiple OE/RPI efforts going on at the > same time unaware of each other, e.g., I noticed this meta-raspberrypi layer > on github that seems to be well on the way, > https://github.com/djwillis/meta-raspberrypi ... perhaps getting various > folk interested in this together would be beneficial. If anyone wants to pitch in with patches that would be great. There is also a little more information on the layer from a post of mine a few weeks back - http://blogs.distant-earth.com/wp/?p=377. I tend to build my layers using Angstrom as the distro (in fact it is now referenced in the Angstrom setup scripts) or straight OE-core and no distro so I can't claim this layer is well tested on Yocto but there are very few, if any, reasons it will not work well. Pull requests are great ;). There are a few things missing at the moment, mainly the binary GPU libs but as the proprietary licence has now been sorted for the blobs I'll push the recipe in the next few days. Other than that it works pretty well on both variants of the hardware but there is always room for improvement. Regards, John ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Raspberry Pi [was Re: Kernel modules fail to compile for ARM]
There do seem to be multiple efforts. The Qt on Pi folks are also putting together a BSP. I'd like to find a way to put everyone together to make sure effort is not being duplicated. Is there interest in a meeting of interested parties, perhaps on Thursday? On Tue, May 15, 2012 at 7:51 AM, John Willis wrote: > Hi Tomas, > >> On 14/05/12 19:52, Chris Tapp wrote: >> > I'm trying to put a BSP together for an ARM system (Raspberry Pi, >> ARM1176JZF-S CPU). >> >> I got the feeling that there might be multiple OE/RPI efforts going on at the >> same time unaware of each other, e.g., I noticed this meta-raspberrypi layer >> on github that seems to be well on the way, >> https://github.com/djwillis/meta-raspberrypi ... perhaps getting various >> folk interested in this together would be beneficial. > > If anyone wants to pitch in with patches that would be great. There is also a > little more information on the layer from a post of mine a few weeks back - > http://blogs.distant-earth.com/wp/?p=377. > > I tend to build my layers using Angstrom as the distro (in fact it is now > referenced in the Angstrom setup scripts) or straight OE-core and no distro > so I can't claim this layer is well tested on Yocto but there are very few, > if any, reasons it will not work well. Pull requests are great ;). > > There are a few things missing at the moment, mainly the binary GPU libs but > as the proprietary licence has now been sorted for the blobs I'll push the > recipe in the next few days. > > Other than that it works pretty well on both variants of the hardware but > there is always room for improvement. > > Regards, > > John > > > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- Jeff Osier-Mixon http://jefro.net/blog Yocto Project Community Manager @Intel http://yoctoproject.org ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] YP 1.3 release criteria
https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.3_Status#Milestone_1 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Raspberry Pi [was Re: Kernel modules fail to compile for ARM]
> There do seem to be multiple efforts. The Qt on Pi folks are also putting > together a BSP. I'd like to find a way to put everyone together to make sure > effort is not being duplicated. Is there interest in a meeting of interested > parties, perhaps on Thursday? I have quite a few commitments on Thursday (oe hacking is not my day job) but pulling everyone together sounds like a very good idea. I'll try and make a meeting if someone else wants to pull it together. It's also worth pushing http://www.openembedded.org/wiki/LayerIndex again as people (me included) often seem to forget to add layers to this so it can be hard to find out if pre-existing work is being carried out. Regards, John ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Raspberry Pi [was Re: Kernel modules fail to compile for ARM]
On 12-05-15 05:15 AM, Tomas Frydrych wrote: On 14/05/12 19:52, Chris Tapp wrote: I'm trying to put a BSP together for an ARM system (Raspberry Pi, ARM1176JZF-S CPU). I got the feeling that there might be multiple OE/RPI efforts going on at the same time unaware of each other, e.g., I noticed this meta-raspberrypi layer on github that seems to be well on the way, https://github.com/djwillis/meta-raspberrypi ... perhaps getting various folk interested in this together would be beneficial. I'll jump in and ask my obvious question, if we want to pull in some extra BSP/kernel developers, is there a fundamental reason why a different kernel/kernel version than one of the linux-yocto ones is being used ? If you line up with one of those, there's a chance to pickup fixes, features and have someone like me help maintain things where it makes sense. Collecting kernels and BSPs in trees all over the place is one of the things that I'd like to try and help with going forward in 2012. Cheers, Bruce Tomas ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Raspberry Pi [was Re: Kernel modules fail to compile for ARM]
On 15 May 2012, at 16:44, Bruce Ashfield wrote: > On 12-05-15 05:15 AM, Tomas Frydrych wrote: >> On 14/05/12 19:52, Chris Tapp wrote: >>> I'm trying to put a BSP together for an ARM system (Raspberry Pi, >>> ARM1176JZF-S CPU). >> >> I got the feeling that there might be multiple OE/RPI efforts going on >> at the same time unaware of each other, e.g., I noticed this >> meta-raspberrypi layer on github that seems to be well on the way, >> https://github.com/djwillis/meta-raspberrypi ... perhaps getting various >> folk interested in this together would be beneficial. > > I'll jump in and ask my obvious question, if we want to pull in some > extra BSP/kernel developers, is there a fundamental reason why a > different kernel/kernel version than one of the linux-yocto ones is > being used ? That's certainly the way I'm trying to go. I would like to see a full-feature BSP as the 'default' for the board that can easily be customized to reduce the size / boot times for 'full embedded' use. If only I could work out how to get it to work ;-) It also needs some extra 'stuff' to pull the image together - there's a Broadcom-provided binary that has to be used as the first stage when booting, but the first step (as I see it) is to get a working kernel image based on linux-yocto 3.0/3.2. > If you line up with one of those, there's a chance to pickup fixes, > features and have someone like me help maintain things where it > makes sense. That would be really nice. > Collecting kernels and BSPs in trees all over the place is one of the > things that I'd like to try and help with going forward in 2012. Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Raspberry Pi [was Re: Kernel modules fail to compile for ARM]
On 15 May 2012, at 16:05, Osier-mixon, Jeffrey wrote: > There do seem to be multiple efforts. The Qt on Pi folks are also > putting together a BSP. I'd like to find a way to put everyone > together to make sure effort is not being duplicated. Is there > interest in a meeting of interested parties, perhaps on Thursday? I would be interested, but ideally have to do it out of working hours. I'm uk-based, so I would prefer it to be outside of 08:00 to 16:30 UTC. If that's not possible, then I can try and arrange some time off. Chris Tapp opensou...@keylevel.com www.keylevel.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Minutes: Yocto Project Technical Team Meeting - Tuesday, May 15, 2012 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US & Canada).
Attendees: Josh, Sean, Jessica, ScottG, Mark, Darren, Denys, Jefro, Beth, Jeff, Matthew, Laurentiu, Michael, Bruce, Chris Larson, Ciby, Song Agenda * Opens collection - 5 min (Song) * 1.2.1 update - 10 min (ScottG) - We have 21 bugs fixed for 1.2.1, 23 more remain open. Current RC1 is July 2nd. First Monday in July. A little behind on merging patches. * 1.1.2 update - 10 min (Josh) - Not much changed, going through bug list, the branch has not changed much. - Matthew: It's nice to have a release, but we are tracking fixes closely. Matthew will talk Josh on IRC to possibly include those in 1.1.2. * Yocto 1.3 status - 10 min (Song/team) - 1.3 feature list: https://wiki.yoctoproject.org/wiki/Yocto_1.3_Features - 1.3 schedule: https://wiki.yoctoproject.org/wiki/Yocto_1.3_Schedule - Process doc, will put it on wiki and send it to the public mailing list for review this week - Action Item for the team: complete 1.3 planning by EOD tomorrow. Complete M1 planning by EOD this Friday: features in M1 need to be smaller than 5D, estimate can be updated based on latest information. - QA: test plan for 1.3, Laurentiu will work with Jiajun. - Release criteria review: https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.3_Status * Beth: AB has some infrastructure upgrade, there is some instability. Having some issues with build history repo, Paul was working on that yesterday. Some other failures. Right now we are building meta-intel. Mails will be continued for build status. * SWAT team rotation: Saul - Darren * Opens - 10 min - Sean: glibc changes (header change) are causing some problems, 2.16 may have this fixed. Need to update. Sean will open a bug on this. * Team Sharing - 20 min - Bruce: working on a few bugs, concentrating on 3.4, qemu64, simulation, etc. - Michael: moving service to dedicated VMs, fighting network attack. Finally got linux foundation address. This week will work on dev cluster for beth. Bugilla re-classification got postponed. Sean: Can we post the categories on the wiki. There is no reason that we cannot. - Beth: Yocto Project is going to have an intern, working on training. Look at some code for license manifest, rewriting it to fix some issues. Preping something to minimize AB downtime, ETA either this week or next week. - Darren: Working FRI II BSP, working through final enablement I2C, GPIO, polished, etc. Helping with some kernel work. Additional BSPs. Finishing up FRI II this week. - Mark: working on RPM, got it finally complete, hopefully I can submit today. Got some performance issues. 2420, generic issue. Slow performance sstate cache data. Did some optimization things. - ScottG: 1.2.1 work, outline for YP training screencast, how to customize image, how to use some tools in 1.2, 5-min screencast on making use of our source control, work on recipe. Linux-Zigbee is building and running, it's not interacting with hardware, 90% complete. Doing another 90% to make it work - Jessica: bug scrub for 1.3, 400 bugs, bucket them, working on bugs for 1.3 and 1.2.1. Song: Richard needs help on prioritizing HOB2 bugs, Jessica will take a look. - Sean: eglic bug, category, will work with Song - Josh: last week on 1.1.2, this week continue 1.1.2, and other bugs. - Ciby: Nothing specific. - Chris: primary working on fixing some bugs on oe-core, master, working on mentor backlog. - Paul: Continuing to work on the ability to take changes from local changes and files. 2044, 75% done. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Raspberry Pi [was Re: Kernel modules fail to compile for ARM]
Hi Bruce, On 15/05/12 16:44, Bruce Ashfield wrote: > On 12-05-15 05:15 AM, Tomas Frydrych wrote: >> On 14/05/12 19:52, Chris Tapp wrote: >>> I'm trying to put a BSP together for an ARM system (Raspberry Pi, >>> ARM1176JZF-S CPU). >> >> I got the feeling that there might be multiple OE/RPI efforts going on >> at the same time unaware of each other, e.g., I noticed this >> meta-raspberrypi layer on github that seems to be well on the way, >> https://github.com/djwillis/meta-raspberrypi ... perhaps getting various >> folk interested in this together would be beneficial. > > I'll jump in and ask my obvious question, if we want to pull in some > extra BSP/kernel developers, is there a fundamental reason why a > different kernel/kernel version than one of the linux-yocto ones is > being used ? > > If you line up with one of those, there's a chance to pickup fixes, > features and have someone like me help maintain things where it > makes sense. Let me turn this question back at you then: is Yocto going to be doing thorough Q&A for all of these HW platforms? Decent Q&A is what really sets Yocto apart, and what makes it my first port of call, but I got a feeling that the scope of this is at the moment somewhat restricted as far as HW is concerned; without Q&A 'fixes' quickly turn into problems -- I'd rather be pulling kernel from somewhere that deals with the specific HW that pick up generic fixes without the Q&A. (Though admittedly working with some silicon vendors specific meta layers can be real PITA :) ). Tomas ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Raspberry Pi [was Re: Kernel modules fail to compile for ARM]
On 12-05-15 01:36 PM, Tomas Frydrych wrote: Hi Bruce, On 15/05/12 16:44, Bruce Ashfield wrote: On 12-05-15 05:15 AM, Tomas Frydrych wrote: On 14/05/12 19:52, Chris Tapp wrote: I'm trying to put a BSP together for an ARM system (Raspberry Pi, ARM1176JZF-S CPU). I got the feeling that there might be multiple OE/RPI efforts going on at the same time unaware of each other, e.g., I noticed this meta-raspberrypi layer on github that seems to be well on the way, https://github.com/djwillis/meta-raspberrypi ... perhaps getting various folk interested in this together would be beneficial. I'll jump in and ask my obvious question, if we want to pull in some extra BSP/kernel developers, is there a fundamental reason why a different kernel/kernel version than one of the linux-yocto ones is being used ? If you line up with one of those, there's a chance to pickup fixes, features and have someone like me help maintain things where it makes sense. Let me turn this question back at you then: is Yocto going to be doing thorough Q&A for all of these HW platforms? Decent Q&A is what really sets Yocto apart, and what makes it my first port of call, but I got a feeling that the scope of this is at the moment somewhat restricted as far as HW is concerned; without Q&A 'fixes' quickly turn into problems -- I'd rather be pulling kernel from somewhere that deals with the specific HW that pick up generic fixes without the Q&A. I spend all day every day working with targets across the spectrum of arch and use case, with plenty of drivers and core infrastructure in common, so those sorts of changes being monitored and being included are definitely in place. As for hardware specific QA, the yocto project itself runs QA on targets that we've tagged as a hardware reference. The raspberry pi is one that I've been considering as a new reference, so if that was the case, it would get extra coverage. That being said, it obviously doesn't scale that just because we align on a kernel version, set of features, base configuration, etc, that the yocto project itself would run machine/BSP specific QA. That would be a place where interested parties would already be doing QA, so doing that on top of the QA's arch and general base would be logical/incremental. Rather than something completely different which isn't incremental at all. Cheers, Bruce (Though admittedly working with some silicon vendors specific meta layers can be real PITA :) ). Tomas ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] LICENSE = "GPL" -- problem?
On 12-05-14 04:11 PM, Wolfgang Denk wrote: Hi, we noticed warnings like "No generic license file exists for: GPL in any provider" for our own linux kernel recipe. The cause wa the use of an entry LICENSE = "GPL" which whould read "GPLv2" instead of "GPL". A scan detected that the same string "GPL" is used in a number of other recipes: bitbake/lib/bb/shell.py:LICENSE = "GPL" meta/recipes-kernel/kern-tools/kern-tools-native_git.bb:LICENSE = "GPL" I've updated this license to be more specific. I'm not sure if a bug was opened for the other ones, but I took care of the one that I look after. Cheers, Bruce meta/recipes-kernel/linux/linux-dummy.bb:LICENSE = "GPL" meta/recipes-bsp/x-load/x-load.inc:LICENSE = "GPL" meta/recipes-devtools/gcc/gcc-common.inc:LICENSE = "GPL" meta/recipes-devtools/unifdef/unifdef-native_2.6.18+git.bb:LICENSE = "GPL" Eventually these should be fixed, too? Best regards, Wolfgang Denk ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] How is the list in package.manifest derived?
I used poky-denzil-7.0 to build a core-image-minimal for the BeagleBoard.
Now I am looking for a list of everything that went into my image together
with the license information. The logical thing seems to be
${TMPDIR}/deploy/licenses/core-image-minimal-beagleboard-/package.manifest:
base-files
base-passwd
bash
busybox
busybox-syslog
busybox-udhcpc
initscripts
libc6
libgcc1
libtinfo5
libusb-1.0-0
libusb-compat
modutils-initscripts
ncurses-terminfo-base
netbase
pciutils-ids
sysvinit
sysvinit-inittab
sysvinit-pidof
task-core-boot
tinylogin
udev
udev-extraconf
udev-utils
update-alternatives-cworth
update-rc.d
usbutils-ids
However, I don't think this is everything that went into the image. I would
expect the kernel to be in the list as well as module-init-tools and
u-boot. Apparently package.manifest and the corresponding license.manifest
for an image target do not contain all the licensing information that a
device builder would need to give to the end customer. How is that list
created?
Rudi
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How is the list in package.manifest derived?
On Tue, May 15, 2012 at 3:38 PM, Rudolf Streif wrote:
> I used poky-denzil-7.0 to build a core-image-minimal for the BeagleBoard.
> Now I am looking for a list of everything that went into my image together
> with the license information. The logical thing seems to be
> ${TMPDIR}/deploy/licenses/core-image-minimal-beagleboard-/package.manifest:
>
> base-files
> base-passwd
> bash
> busybox
> busybox-syslog
> busybox-udhcpc
> initscripts
> libc6
> libgcc1
> libtinfo5
> libusb-1.0-0
> libusb-compat
> modutils-initscripts
> ncurses-terminfo-base
> netbase
> pciutils-ids
> sysvinit
> sysvinit-inittab
> sysvinit-pidof
> task-core-boot
> tinylogin
> udev
> udev-extraconf
> udev-utils
> update-alternatives-cworth
> update-rc.d
> usbutils-ids
>
> However, I don't think this is everything that went into the image. I would
> expect the kernel to be in the list as well as module-init-tools and u-boot.
> Apparently package.manifest and the corresponding license.manifest for an
> image target do not contain all the licensing information that a device
> builder would need to give to the end customer. How is that list created?
This list is created via license_create_manifest within
license.bbclass. I'm currently in the process of refactoring it quite
a bit so I'll look out for this issue.
It derives the list from list_installed_packages. Which means that
there may be an issue with that function. The way I'm planning on
doing it does not use list_installed_packages, however I'm going to
open a bug on it to verify that it is in fact returning an incomplete
list.
What would be helpful here is knowing what package type you're using.
-b
>
> Rudi
>
> ___
> 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
Re: [yocto] How is the list in package.manifest derived?
Thanks for your response, Beth. I am using the default: RPM.
:rjs
On Tue, May 15, 2012 at 3:53 PM, Flanagan, Elizabeth <
elizabeth.flana...@intel.com> wrote:
> On Tue, May 15, 2012 at 3:38 PM, Rudolf Streif
> wrote:
> > I used poky-denzil-7.0 to build a core-image-minimal for the BeagleBoard.
> > Now I am looking for a list of everything that went into my image
> together
> > with the license information. The logical thing seems to be
> >
> ${TMPDIR}/deploy/licenses/core-image-minimal-beagleboard-/package.manifest:
> >
> > base-files
> > base-passwd
> > bash
> > busybox
> > busybox-syslog
> > busybox-udhcpc
> > initscripts
> > libc6
> > libgcc1
> > libtinfo5
> > libusb-1.0-0
> > libusb-compat
> > modutils-initscripts
> > ncurses-terminfo-base
> > netbase
> > pciutils-ids
> > sysvinit
> > sysvinit-inittab
> > sysvinit-pidof
> > task-core-boot
> > tinylogin
> > udev
> > udev-extraconf
> > udev-utils
> > update-alternatives-cworth
> > update-rc.d
> > usbutils-ids
> >
> > However, I don't think this is everything that went into the image. I
> would
> > expect the kernel to be in the list as well as module-init-tools and
> u-boot.
> > Apparently package.manifest and the corresponding license.manifest for an
> > image target do not contain all the licensing information that a device
> > builder would need to give to the end customer. How is that list created?
>
> This list is created via license_create_manifest within
> license.bbclass. I'm currently in the process of refactoring it quite
> a bit so I'll look out for this issue.
>
> It derives the list from list_installed_packages. Which means that
> there may be an issue with that function. The way I'm planning on
> doing it does not use list_installed_packages, however I'm going to
> open a bug on it to verify that it is in fact returning an incomplete
> list.
>
> What would be helpful here is knowing what package type you're using.
>
> -b
>
> >
> > Rudi
> >
> > ___
> > 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] [Infra] Network home directories
Problems: Moving files between builders requires copying them to localhost and back (slow) or forwarding your ssh-agent around (poor security). Different amounts of free local storage mean pokybuild has different size constraints on different builders which isn't helpful. Solution: Beth and I propose that we mount user home directories from the NAS on the autobuilder stack so that user files are shared across the build infrastructure. We will keep a copy of bare home directories with ssh keys on the filesystem below the network mount so that logins will continue to function even during a NAS outage. Interruption: Setting this up requires moving user home directories from /srv and consolidating the data. This wouldn't interrupt the builders but would keep some users from logging in for several minutes. What we gain: This offers the benefit of shared files across the builders as well as keeping the local disk free for poky builds. It allows easy tear-down and rebuilding of slave hosts because unique data is separated from local storage. Does this break anyone's existing workflow? Any other concerns? Michael Halstead Yocto Project / Sys Admin smime.p7s Description: S/MIME Cryptographic Signature ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How is the list in package.manifest derived?
Related to that I have another question. If I use this recipe to create an
image
DESCRIPTION = "A small image with gcc"
IMAGE_INSTALL = "task-core-boot gcc"
LICENSE = "MIT"
inherit core-image
and call it myimage.bb
${TMPDIR}/deploy/icenses will contain a subdirectory named myimage.
However, the content of the directory is not, as I would love to have it, a
license.manifest and a package.manifest file but the MIT licensing
information.
What makes a recipe such as core-image-minimal.bb magically different from
myimage.bb so that the former includes the manifests? It does not seem to
be the content of the recipe.
:rjs
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How is the list in package.manifest derived?
On Tuesday, May 15, 2012, Rudolf Streif wrote:
> I used poky-denzil-7.0 to build a core-image-minimal for the BeagleBoard.
Now I am looking for a list of everything that went into my image together
with the license information. The logical thing seems to be
${TMPDIR}/deploy/licenses/core-image-minimal-beagleboard-/package.manifest:
> base-files
> base-passwd
> bash
> busybox
> busybox-syslog
> busybox-udhcpc
> initscripts
> libc6
> libgcc1
> libtinfo5
> libusb-1.0-0
> libusb-compat
> modutils-initscripts
> ncurses-terminfo-base
> netbase
> pciutils-ids
> sysvinit
> sysvinit-inittab
> sysvinit-pidof
> task-core-boot
> tinylogin
> udev
> udev-extraconf
> udev-utils
> update-alternatives-cworth
> update-rc.d
> usbutils-ids
> However, I don't think this is everything that went into the image. I
would expect the kernel to be in the list as well as module-init-tools and
u-boot. Apparently package.manifest and the corresponding license.manifest
for an image target do not contain all the licensing information that a
device builder would need to give to the end customer. How is that list
created?
I think kernel and uboot are not bundled into image but kernel modules are
why module-init-tools does not appear there might be a bug
> Rudi
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How is the list in package.manifest derived?
>> I think kernel and uboot are not bundled into image but kernel modules are why >> module-init-tools does not appear there might be a bug Yes, that is technically of course correct. However, the idea of package.manifest and license.manifest should be to provide a list of everything that goes into the distribution together with the licenses. That's what one needs to provide to customers. And the image recipe has these items as dependencies. I would think that anything that is a runtime dependency of an image should show up in the manifests. task-core-boot is a runtime dependency of core-image-minimal. Interestingly, virtual/kernel is not a runtime dependency of task-core-boot but it is a build-time dependency. From the view of the build system that is correct and sufficient. It creates the kernel but of course the kernel is not included with the root file system image. It looks to me as if the class creating the licensing manifest evaluates the runtime dependencies which is not sufficient. That explains the kernel. But it does not explain module-init-tools, as you say. Checking reverse dependencies of module-init-tools shows nothing depends on them. So how do they get included with the root fs in the first place? Another strange thing I cannot make sense of is that linux-yocto runtime depends on python, perl, elfutils, kernel-base and kernel-image. :rjs ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
