Date   

[meta-ivi][PATCH] consolekit: Remove bbappend as gnome-common is not GPLv3

Andrei Gherzan
 

gnome-common's LICENSE fixed with this oe-core commit:
commit 97469db0cba6d21ab1290238225d3fe365931a5c
Author: Ross Burton <ross.burton@intel.com>
Date: Tue Oct 30 12:02:45 2012 +0000

gnome-common: Fix license
gnome-common 2.28 is GPLv2+. From Christian Persch, upstream:
The licence is presumed GPL2+, although it's not there explicitly. GPL2+
because as far as I could figure out when I tried to, gnome-autogen started in
gnome-core which had a GPL2 COPYING file.

Signed-off-by: Andrei Gherzan <andrei.gherzan@windriver.com>
---
.../consolekit/consolekit_0.4.5.bbappend | 8 --------
1 file changed, 8 deletions(-)
delete mode 100644 recipes-support-ivi/consolekit/consolekit_0.4.5.bbappend

diff --git a/recipes-support-ivi/consolekit/consolekit_0.4.5.bbappend b/recipes-support-ivi/consolekit/consolekit_0.4.5.bbappend
deleted file mode 100644
index 1dccee5..0000000
--- a/recipes-support-ivi/consolekit/consolekit_0.4.5.bbappend
+++ /dev/null
@@ -1,8 +0,0 @@
-PRINC := "${@int(PRINC) + 1}"
-
-# gnome-common is GPLv3 so we drop this dependency
-# if INCOMPATIBLE_LICENSE contains GPLv3
-python () {
- if (d.getVar("INCOMPATIBLE_LICENSE", True) or "").find("GPLv3") != -1:
- d.setVar("DEPENDS", " ".join(i for i in d.getVar("DEPENDS").split() if i != "gnome-common" and i != "gconf" and i != "gconf-native"))
-}
--
1.7.9.5


Recipes for Xilinx ZC706 (Zynq 7045) and Avnet Zedboard

Andreas Schweigstill <andreas@...>
 

Hello,

after successfully using the recipe for the ZC702 development board I would
like to know if anybody is working on recipes for the Xilinx ZC706 (Zynq 7045)
and Avnet Zedboard.

Thank you very much in advance!

With best regards,
Andreas Schweigstill

​--
Dipl.-Phys. Andreas Schweigstill
Schweigstill IT | Embedded Systems
Schauenburgerstraße 116, D-24118 Kiel, Germany
Phone: (+49) 431 530354-35, Fax: (+49) 431 530354-36
Mobile: (+49) 171 6921973, Web: http://www.schweigstill.de/


Re: Yocto Bug Trend

Serban, Laurentiu <laurentiu.serban@...>
 

Hello,

 

The dotted line is an inherited artifact from 1.3. It had a relevance at some point as far as I know. I will remove it in the next versions.

 

Br,

Laurentiu

 

From: Stewart, David C
Sent: Thursday, January 10, 2013 2:55 AM
To: Serban, Laurentiu; yocto@...
Cc: Wold, Saul; Liu, Song
Subject: Re: Yocto Bug Trend

 

Thanks – what's the new dotted line in the Weekly Open Bug Trend chart?

 

From: <Serban>, Laurentiu Serban <laurentiu.serban@...>
Date: Tuesday, January 8, 2013 9:08 AM
To: "yocto@..." <yocto@...>
Cc: "Wold, Saul" <saul.wold@...>, David Stewart <david.c.stewart@...>, "Liu, Song" <song.liu@...>
Subject: Yocto Bug Trend

 

Hello,

 

The Yocto Bug Trend was updated for ww01.

https://wiki.yoctoproject.org/wiki/Yocto_Bug_Trend

 

Best regards and a happy new year J

 

Laurentiu Serban

QA Engineer

Open Source Technology Center

System Software Division Romania

Desk: +40 31 8604742

iNET: 88451042

 


Re: I think my kernel image just went back in time...

Chris Tapp
 

On 7 Jan 2013, at 16:26, Darren Hart wrote:



On 12/21/2012 10:17 AM, Tomas Frydrych wrote:
On 09/12/12 23:17, Chris Tapp wrote:
In tmp/deploy/images:

1) bzImage had a timestamp of 2012-12-09 21:49 and the file ended
-20121209214459.bin

2) Cleaned the image and the task it contained (to pick up some
changes on rebuild) and deleted the image files (.hddimg, etc.) in
tmp/deploy/images making sure to leave the kernel files intact.
Did you cleansstate it? I find that without cleaning the state kernel
image gets always pulled out of sstate rather than properly rebuilt.
It was a while back now and I can't recall for sure. I'm 99.9% certain I used -c cleanall on the image.

Tomas
Do you still experience this on the master branch?
I've not had a chance to try and I can't remember the exact steps to reproduce it. I've only seen this happen once for the same work-flow.

--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Chris Tapp

opensource@keylevel.com
www.keylevel.com


Re: meta-cedartrail - where is grub configured for 'install' option?

Chris Tapp
 

Hi Darren,

On 7 Jan 2013, at 16:44, Darren Hart wrote:

On 12/09/2012 01:39 PM, Chris Tapp wrote:
I am trying to change the 'install' behaviour for the meta-cedartrail image so that the installed system has a different grub.cfg file. Is there a file I can bbappend to achieve this?

image_live.bbclass refers to the 'install' syslinux label that triggers the install, but I've not been able to get from this to how/where grub.cfg is created.
This is currently rather crudely implemented here:

meta/recipes-core/initrdscripts/files/init-install.sh

A better deployment mechanism is something being discussed and which
should make this more configurable.

For now, you could bbappend initramfs-live-install_1.0.bb and replace the
init-install.sh script with your own.
Thanks. I've already got to look at that script anyway as it fails to install to an internal USB drive on a DN2800-MT board as (I think) it isn't waiting long enough for it to enumerate when booting the 'install' image.

--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel
Chris Tapp

opensource@keylevel.com
www.keylevel.com


Re: Yocto Bug Trend

David Stewart
 

Thanks – what's the new dotted line in the Weekly Open Bug Trend chart?

From: <Serban>, Laurentiu Serban <laurentiu.serban@intel.com<mailto:laurentiu.serban@intel.com>>
Date: Tuesday, January 8, 2013 9:08 AM
To: "yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>" <yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>>
Cc: "Wold, Saul" <saul.wold@intel.com<mailto:saul.wold@intel.com>>, David Stewart <david.c.stewart@intel.com<mailto:david.c.stewart@intel.com>>, "Liu, Song" <song.liu@intel.com<mailto:song.liu@intel.com>>
Subject: Yocto Bug Trend

Hello,

The Yocto Bug Trend was updated for ww01.
https://wiki.yoctoproject.org/wiki/Yocto_Bug_Trend

Best regards and a happy new year :)

Laurentiu Serban
QA Engineer
Open Source Technology Center
System Software Division Romania
Desk: +40 31 8604742
iNET: 88451042


adt-manual.pdf

Edward Vidal <vidal.develone@...>
 

Hello,
I was testing the example  4.1 Autotools-Based Projects
should the file "configure".in be "configure.ac"
this is the error that I get when I execute aclocal
aclocal
aclocal: warning: autoconf input should be named 'configure.ac', not 'configure.in'
Any help will be appreciated.
Ed Vidal Jr.


Re: wiki page for building basic image for raspberry pi

Robert P. J. Day
 

On Wed, 9 Jan 2013, Jeff Osier-Mixon wrote:




On Tue, Jan 8, 2013 at 6:15 AM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
On Tue, 8 Jan 2013, Alex J Lennon wrote:

> On 08/01/2013 12:49, Robert P. J. Day wrote:
> >
> >   after reading what's available, i gave it a shot and documented the
> > results here:
> >
> > http://www.crashcourse.ca/wiki/index.php/Building_basic_RPi_image
> >
> >   the build seems to have worked, although i have no rpi unit on which
> > to test the generated artifacts.

Thanks for writing this up, Robert. If you would like to host this
on the Yocto Project wiki I'd be glad to help set it up.
let me test it first, i have no access to an RPi at the moment.
should be a day or two. and i want to clean it up just a touch.

rday


Re: wiki page for building basic image for raspberry pi

Jeff Osier-Mixon <jefro@...>
 




On Tue, Jan 8, 2013 at 6:15 AM, Robert P. J. Day <rpjday@...> wrote:
On Tue, 8 Jan 2013, Alex J Lennon wrote:

> On 08/01/2013 12:49, Robert P. J. Day wrote:
> >
> >   after reading what's available, i gave it a shot and documented the
> > results here:
> >
> > http://www.crashcourse.ca/wiki/index.php/Building_basic_RPi_image
> >
> >   the build seems to have worked, although i have no rpi unit on which
> > to test the generated artifacts.

Thanks for writing this up, Robert. If you would like to host this on the Yocto Project wiki I'd be glad to help set it up.
 
--
Jeff Osier-Mixon http://jefro.net/blog
Yocto Project Community Manager @Intel http://yoctoproject.org


Re: [OE-core] WebHob Mailing List Setup

Philip Balister
 

On 01/09/2013 10:22 AM, Richard Purdie wrote:
Various people at various times have expressed an interest in webhob
which will be a web interface to bitbake's functionality as an evolution
of the capabilities of the current hob UI. There are some people looking
at the design of it and who are actively working on figuring out what it
should look like, what it needs to do, who it needs to serve and some
other key questions. They will also likely start implementing the
functionality soon.

In the interests of collaboration, we've setup the mailing list:

https://lists.yoctoproject.org/listinfo/webhob
Is there a gmane archive?

Philip


which is where the design and initial implementation discussions are
going to happen. If you are interested please join the list.

I've cross posted this to ensure people know about it. Please take
discussion and replies up on the webhob list itself.

Cheers,

Richard


_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core


Re: Bitbake and task offloading onto multiple cloud-based servers

Tom Zanussi <tom.zanussi@...>
 

On Wed, 2013-01-09 at 11:58 +0000, Alex J Lennon wrote:
In the 1.1 timeframe I proposed something similar for a demo/research
project - I'll just copy the proposal verbatim below in case any of the
ideas could be of any value.
Very interesting Tom. Thanks for your thoughts.


if throwing a
40-processor system at a build doesn't really help much it's not likely
to be of much help either to distribute the individual pieces out to the
'cloud'.
Are there any figures for build time versus increase in processor cores?
It would be interesting to see what the immediate performance gain is
for a build with a low number of additional cores and then where it tops
out?
These threads have some hard data:

https://lists.yoctoproject.org/pipermail/poky/2011-July/006802.html
https://lists.yoctoproject.org/pipermail/yocto/2012-April/008293.html

Some of which is summarized here:

https://wiki.yoctoproject.org/wiki/Build_Performance

Other people may have pointers to more data or summaries..

Tom


The whole
process is completely peer-to-peer with no single node in charge - in
that context, a more appropriate name for it might be 'BuildTorrent'.
A "BuildTorrent". I like it!

Cheers,

Alex


WebHob Mailing List Setup

Richard Purdie
 

Various people at various times have expressed an interest in webhob
which will be a web interface to bitbake's functionality as an evolution
of the capabilities of the current hob UI. There are some people looking
at the design of it and who are actively working on figuring out what it
should look like, what it needs to do, who it needs to serve and some
other key questions. They will also likely start implementing the
functionality soon.

In the interests of collaboration, we've setup the mailing list:

https://lists.yoctoproject.org/listinfo/webhob

which is where the design and initial implementation discussions are
going to happen. If you are interested please join the list.

I've cross posted this to ensure people know about it. Please take
discussion and replies up on the webhob list itself.

Cheers,

Richard


Re: Bitbake and task offloading onto multiple cloud-based servers

Alex J Lennon <ajlennon@...>
 

In the 1.1 timeframe I proposed something similar for a demo/research
project - I'll just copy the proposal verbatim below in case any of the
ideas could be of any value.
Very interesting Tom. Thanks for your thoughts.


if throwing a
40-processor system at a build doesn't really help much it's not likely
to be of much help either to distribute the individual pieces out to the
'cloud'.
Are there any figures for build time versus increase in processor cores?
It would be interesting to see what the immediate performance gain is
for a build with a low number of additional cores and then where it tops
out?

The whole
process is completely peer-to-peer with no single node in charge - in
that context, a more appropriate name for it might be 'BuildTorrent'.
A "BuildTorrent". I like it!

Cheers,

Alex


Re: Bitbake and task offloading onto multiple cloud-based servers

Tom Zanussi <tom.zanussi@...>
 

On Fri, 2013-01-04 at 21:17 +0000, Alex J Lennon wrote:
On 04/01/2013 21:08, Chris Larson wrote:


On Fri, Jan 4, 2013 at 1:56 PM, Alex J Lennon
<ajlennon@dynamicdevices.co.uk <mailto:ajlennon@dynamicdevices.co.uk>>
wrote:

Can anybody advise on whether bitbake currently supports offloading of
build tasks onto multiple systems? Perhaps cloud based?

I'm thinking that it would be more efficient for me if I could bring up
a number of Amazon EC2 servers (or similar) then have bitbake
parallelise the build onto those servers to significantly reduce my
build times?

I see bitbake supports a level of task parallelisation on a single box.

Can parallelisation of build onto multiple systems be achieved?

Is it something that should even be a goal?


It's not supported today. It could be implemented, but nobody has made
it a priority and done so.
Do you have any feeling for the level of difficulty of such an
implementation / what would have to change / how invasive it would be to
the codebase ?

I'm wondering if it could be along the lines of creating a "remote task"
class and then, say, having that class ssh into one of a pool of servers
(running a standard image with all tools preinstalled maybe) then
bitbaking the recipes for the particular and waiting on completion
before pulling back the output rpm/deb/ipkg ?

Things are usually more complex than expected when you get into the
nitty gritty though. What would the challenges be do you think?

Where would one start to look in the bitbake code to add this kind of
support in?
Hi, just catching up on my vacation e-mail and saw this...

In the 1.1 timeframe I proposed something similar for a demo/research
project - I'll just copy the proposal verbatim below in case any of the
ideas could be of any value. At the time, it was proposed in the
context of creating a demo that would use java in a new
'machine-to-machine' layer, thus the references to 'm2m' and java in the
writeup.

I never got past the proposal phase - not enough time, etc, but I still
think it could make for an interesting research project.

The initial comments that were made that made me think it would be a
bigger job than I'd assumed and kind of made me drop the idea for the
time being were that because of build-time dependencies, an overall
build of a complete image is still pretty linear - if throwing a
40-processor system at a build doesn't really help much it's not likely
to be of much help either to distribute the individual pieces out to the
'cloud'.

The other barrier at the time was that we didn't have any self-hosting
Yocto images that could themselves be used to build Yocto images, but
that's no longer the case.

Probably the first step in making something like this feasible would be
to increase the granularity of parallelization and also decrease the
size of the build-time dependencies. I have no concrete idea at the
moment on how to actually do that, but in general the more you can break
down the problem into separate pieces that can be built in parallel, the
more opportunity you'd have to move those pieces into the cloud.
Combine that with the other resource considerations you'd need to track
such as network bandwidth, etc, I guess you'd have all the pieces you'd
need and the whole thing becomes a continuously-updating dynamic
optimization problem.

Well, enough handwaving - I do think it's an interesting problem and is
still worth at least investigating - feel free to use or expand on any
of the ideas below, if they're of any value for what you're thinking
of...

----

capybara: Cloud Assembly Protocol for Yocto Build And Runtime Arrays

The basic idea is that you have a 'cloud' of Yocto build machines, each
of course running Yocto, that use a smart but simple protocol to
coordinate the building of a new Yocto image by farming out portions of
the overall build to each machine in the cloud, each according to its
capacity. In other words, extending the parallel build across machines
and assembling it into a final image somewhere in the cloud. The whole
process is completely peer-to-peer with no single node in charge - in
that context, a more appropriate name for it might be 'BuildTorrent'.

From the user's perspective, simply turning on a machine running an
'm2m' yocto image immediately, automatically, and seamlessly adds the
horsepower of that machine to the build - there's nothing else to do,
since the protocol automatically discovers the new build machine and
enlists it into the network. Theoretically, adding enough machines to
the cloud would allow a new image to be built instantaneously (actually,
having a trivially easy-to-use system like this, and a way to monitor
the protocol and dynamically tweak tunables would allow for a lot of
experimentation with the build system parameters and immediate
observation of the results, and could provide some good insights into
the build system dynamics, which in the end just might allow approaching
that goal).

To accomplish this, it should be possible to design and implement a
simple protocol that would basically split the build up into a number of
independent 'work units' e.g. recipes, and match those up with whichever
machines in the cloud have the best currently available capacity for
building a given recipe. The 'currently available capacity' metric
would change dynamically for any given machine, and would be essentially
a metric or set of metrics culled from dynamically-generated performance
data available on that machine (from e.g. the numerous tracing and
performance tools we have in Yocto). The machine with the 'best'
currently available capacity for a given recipe would be chosen by
combining the current capacity metric for a given machine with other
factors such as network bandwidth to the image destination, etc. and
matching that up with the 'weight' of the recipe, essentially a
statically defined relative cost value associated with building that
recipe. When a recipe completes, it sends that info out into the cloud,
which removes it from the list of remaining work (while building, it's
'pending').

Implementation-wise, each peer in the cloud would be running a Yocto
image containing a Java Virtual Machine instance running the 'capybara'
service. The capybara service would itself be layered on top of some
basic and simple m2m-enabling messaging code. Presumably, all of this
would be included in the 'meta-m2m' layer and would make it easy to add
as a feature to any Yocto image.

That's the basic idea in a nutshell. If we combine that (JVM, meta-m2m
layer containing capybara on top of basic m2m messaging), the new Chrome
browser with JVM plugin support, and some minimal hooks into the build
system, I think we might have the basis for a pretty interesting demo
that actually uses Yocto to build Yocto and more importantly should
actually be useful in its own right for analyzing the build system and
speeding up builds for anyone with idle hardware.

Part of the reason I'd like to see this happen too is that I have a
bunch of hardware here that sits idle, and some of it actually pretty
powerful that shouldn't be going unused - it would be great to just kick
off a build and do nothing more than switch on these machines whenever I
wanted to make use of them, without having to actually set anything up
or type a command to do that (which is actually what prevents me from
making use of that hardware as it stands - may be laziness, but really I
don't have time to be bothered with being derailed by small tasks like
that all the time).

I don't think the full-fledged idea can be implemented in the 1.1 demo
timeframe, but I think a sufficiently interesting subset can. So, I've
broken it into a couple phases, Phase I, which I think can be done in
the 1.1 demo timeframe, and Phase II, the follow-on:

Phase I: simply implement the 'work unit' breakup and the capacity
monitoring side of the protocol, but build on only a single machine
(i.e. only one machine would 'accept' work). The protocol and m2m stack
would be running on any number of machines, each one actually reporting
capacity metrics into the cloud, and each one also monitoring the
protocol e.g. recipe-pending and -completion messages, and using that
information to display the overall build progress on each machine, in
the Java-enabled Chrome browser running on each machine (or maybe
modifying the demo from last ELC that showed Yocto commits graphically
to show completed recipes by machine or something instead).

We already have all the basic componentry we need, but it would require
some modest amount of Java development work to enable a minimal portion
of the protocol, some minimal hooks into the build system to at least
emit recipe-completion and -pending messages, and some minimal work to
extract and packetize the performance metrics that each machine sends
out (note that the performance data for Phase I would mainly be for demo
purposes and not actually used in the single-machine build (but they
would be real in the sense that they would provide real information over
the real protocol being monitored, and could be relatively simple-minded
at this point). All of the above should be doable within the 1.1 demo
timeframe.

Phase II:

Everything else.


Well, I'll flesh out Phase II if/when it makes sense. Just thought I'd
throw the basic idea out there as a possibility - if it doesn't make
sense as a demo, I still think it would be worthwhile as a side project,
so any comments would be welcome regardless...

----

Thanks,

Tom

Thanks,

Alex


--
Christopher Larson
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Minutes: Yocto Project Technical Team Meeting - Tuesday, January 8, 2013 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US & Canada).

Saul Wold <sgw@...>
 

Attendees:
PaulE, MihaiL, LaurentuiS, TomZ, ScottR, SeanH, EranT, Amit, JessicaZ, Nitin, KevinS, BruceA, CorneliuxS, RossB, Saul and possibly others lurking

Minutes:
* Opens collection

* Yocto 1.2.2 status (Saul for Scott)
- In Full pass testing right now, planning for release next week.
- QA Testing planned by end of week.
* Yocto 1.3.1 / Danny (Ross)
- Few more patches have been merged, ready for QA
* Yocto 1.4 / Milestone 2/3
- Many patches merged, currently we have some major functionality pending for systemd and wayland, there is also an issue with the headers build currently being worked.
- Need to schedule QA for 1.4 based on getting functionality in


* SWAT team rotation: Cristiana Voicu -> Radu Moisan

* Opens - 2 min
- Darren - Deployment
Discussion on the mailing list and in IRC, Assembling images, partition types, ramdisk and filesystems, unifiying filesystem generation without root privs, ext3 and ext4 have gap because of missing functionality. Patches being reviewed on EXTFS mailing list, needs some test suite
Mark: Installs based on package feeds, run same bitbake code for image generation. Working on it currently, expect RFC in a couple of weeks.
Script with config files. Cross or target based install via some interface, using same bitbake backend code. Still Prototype mode.
Darren: Live and Partitioned images is sub-optimal, parted type script to create disk image, POC created, but needs integration work
Memory based FS, Disk Based and Live Type.

- Scott Rif - Bitbake Manual
http://git.openembedded.org/bitbake/log/?h=wmat
https://wiki.yoctoproject.org/wiki/BitBake/UserManual
Bill Traynor would like review of the manaual, please take a look
- Corneliu - Testopia
- Officially Launched:
https://bugzilla.yoctoproject.org/tr_show_product.cgi
- Open to the community to add tests or create test plans
- https://wiki.yoctoproject.org/wiki/Testopia
- Contact Corneliu if you have questions, please contact
corneliux.stoicescu@intel.com
- extensions planned for the wiki to generate

* Team Sharing - 10 min
Alex D: Wayland Patches are on the list for review, ran into an issue with eglibc-initial
RP: DUring his vacation, playing with RaspberryPi: http://www.rpsys.net/avrpi.jpg


Sau!


_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Yocto Bug Trend

Serban, Laurentiu <laurentiu.serban@...>
 

Hello,

 

The Yocto Bug Trend was updated for ww01.

https://wiki.yoctoproject.org/wiki/Yocto_Bug_Trend

 

Best regards and a happy new year J

 

Laurentiu Serban

QA Engineer

Open Source Technology Center

System Software Division Romania

Desk: +40 31 8604742

iNET: 88451042

 


Re: Future of WebHob?

David Stewart
 

On 1/8/13 3:34 AM, "Tino Breddin" <tb@travelping.com> wrote:

Hi,

I was wondering what the future plans for WebHob are. I'm aware of the
wiki design page [1] and the repo [2] and recall having read that it has
been dropped from release 1.3. However I can't find any further
information.
Hi Tino - here's the update. We decided to stop work on this version of
webHob because we were lacking some key developer input and we were not
convinced that we were taking the right approach. So what we have right
now is a prototype of this design which was functional at least at some
level (there was a demo of some functionality).

The good news is that we spent the past 6 months doing research with
stakeholders and we now have a proposed roadmap of features based on this
research. This seems to be getting healthy enough that we think we can
start a community process to refine the design and restart development.

We should see an announcement to this mailing list within the next week or
so to invite participation into this process.


Cheers,
Tino

[1] https://wiki.yoctoproject.org/wiki/Yocto_Web_Hob_Design
[2] http://git.yoctoproject.org/cgit/cgit.cgi/yocto-webhob-design/
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: Future of WebHob?

Tino Breddin <tb@...>
 

Hi Jessica,

Thanks for the heads up. I find the idea very promising and am looking
forward to see it getting traction as
its own project.

Cheers,
Tino

On Tue 08 Jan 2013 04:31:18 PM CET, Zhang, Jessica wrote:
Hi Tino,

We're in the process of officially kick off webhob as a sub project of Yocto Project, e.g. setup mailing list, wiki pages, etc. And some announcement will be made soon. So stay tuned.

Thanks,
Jessica

-----Original Message-----
From: yocto-bounces@yoctoproject.org [mailto:yocto-bounces@yoctoproject.org] On Behalf Of Tino Breddin
Sent: Tuesday, January 08, 2013 3:34 AM
To: yocto
Subject: [yocto] Future of WebHob?

Hi,

I was wondering what the future plans for WebHob are. I'm aware of the wiki design page [1] and the repo [2] and recall having read that it has been dropped from release 1.3. However I can't find any further information.

Cheers,
Tino

[1] https://wiki.yoctoproject.org/wiki/Yocto_Web_Hob_Design
[2] http://git.yoctoproject.org/cgit/cgit.cgi/yocto-webhob-design/
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
--
--
Tino Breddin
Technical Director

email: tb@travelping.com
mobile: +49-151-27054995

------------------- enabling your networks -------------------

Travelping GmbH phone: +49-391-819099229
Roentgenstr. 13 fax: +49-391-819099299
D-39108 Magdeburg email: info@travelping.com
GERMANY web: http://www.travelping.com


Company Registration: Amtsgericht Stendal Reg No.: HRB 10578
Geschaeftsfuehrer: Holger Winkelmann | VAT ID No.: DE236673780
--------------------------------------------------------------


Re: Future of WebHob?

Zhang, Jessica
 

Hi Tino,

We're in the process of officially kick off webhob as a sub project of Yocto Project, e.g. setup mailing list, wiki pages, etc. And some announcement will be made soon. So stay tuned.

Thanks,
Jessica

-----Original Message-----
From: yocto-bounces@yoctoproject.org [mailto:yocto-bounces@yoctoproject.org] On Behalf Of Tino Breddin
Sent: Tuesday, January 08, 2013 3:34 AM
To: yocto
Subject: [yocto] Future of WebHob?

Hi,

I was wondering what the future plans for WebHob are. I'm aware of the wiki design page [1] and the repo [2] and recall having read that it has been dropped from release 1.3. However I can't find any further information.

Cheers,
Tino

[1] https://wiki.yoctoproject.org/wiki/Yocto_Web_Hob_Design
[2] http://git.yoctoproject.org/cgit/cgit.cgi/yocto-webhob-design/
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: wiki page for building basic image for raspberry pi

Robert P. J. Day
 

On Tue, 8 Jan 2013, Alex J Lennon wrote:

On 08/01/2013 12:49, Robert P. J. Day wrote:

after reading what's available, i gave it a shot and documented the
results here:

http://www.crashcourse.ca/wiki/index.php/Building_basic_RPi_image

the build seems to have worked, although i have no rpi unit on which
to test the generated artifacts.
Robert, if you want to send me a .torrent I'll be happy to run up the
image to test for you.
can't set up a .torrent at the moment, but i may have some H/W to
test shortly. in any event, if anyone else wants to follow along in
that recipe and see if they get something workable out the other end,
that would be great. that was all done on 64-bit ubuntu 12.10 system.

rday

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================