Date   

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@...
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@... <mailto:ajlennon@...>>
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@...
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@...
- 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@...
https://lists.yoctoproject.org/listinfo/yocto


_______________________________________________
yocto mailing list
yocto@...
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@...> 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@...
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@... [mailto:yocto-bounces@...] 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@...
https://lists.yoctoproject.org/listinfo/yocto
--
--
Tino Breddin
Technical Director

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

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

Travelping GmbH phone: +49-391-819099229
Roentgenstr. 13 fax: +49-391-819099299
D-39108 Magdeburg email: info@...
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@... [mailto:yocto-bounces@...] 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@...
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
========================================================================


Re: wiki page for building basic image for raspberry pi

Alex J Lennon <ajlennon@...>
 

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.

Cheers,

Alex


wiki page for building basic image for raspberry pi

Robert P. J. Day
 

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.

rday

--

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

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


Future of WebHob?

Tino Breddin <tb@...>
 

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/


Agenda: 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@...>
 

Agenda:

* Opens collection - 5 min (Saul)
* Denzil 1.2.2 Status - 5 min (ScottG/Saul)
* Danny 1.3.1 Status - 5 min (Ross/Saul)
* Yocto 1.4 status - 15 min (Saul/team)
* SWAT team rotation: Cristiana Voicu -> Radu Moisan
* Opens - 10 min
* Team Sharing - 20 min


-----Original Appointment-----

We encourage people attending the meeting to logon the Yocto IRC chancel during the meeting (optional):

Yocto IRC: http://webchat.freenode.net/?channels=#yocto
IRC Tutorial: http://www.irchelp.org/irchelp/irctutorial.html
Conference details
Conference name: Yocto Technical Team
Conference date/start time: Tue Jun 26, 2012 at 10:00 AM Central Daylight Time
Participants: 30
Duration: 60 minutes
Participant passcode: 76994298
Dial-in number: 1.972.995.7777
US Toll Free number: 1.877.561.6828
BlackBerry users, click this link to join your conference as a participant:
1.972.995.7777x76994298#

Depending on where you are dialing from, either your BlackBerry will pause and enter the passcode automatically or you will be prompted to click again to dial the passcode.

Local and Global Access Numbers

Country
Dial-in number
Australia: 1800 636 843
Czech Republic: 242 430 350
China (Beijing): >From office dial 8-9957777 or 8784277
Beijing Out of Office dial 5878 4277
China (Shanghai): >From office dial 8-9957777 or 3073322
Shanghai Out of Office dial 2307 3322
China (Shenzen): >From office dial 8-9957777 or 6007877
Shenzen Out of Office dial 2600 7877
China (Other Cities): >From IP phone dial 8-9957777
Other cities - Non IP phone dial 021-23073322
Denmark: 8060 1400
Finland: 09 41333477
France: 0497 275888
Germany: 08161 803232
Holland: 030 2417490
India: BSNL subscribers use 1800 425 9996 (Toll Free) Airtel subscribers use 0008 009 861 212 (Toll Free) From TI Campus use 89957777 Others use 2509 9555 (Landline within Bangalore) or
80 2509 9555 (Outside Bangalore)
Israel: 09 790 6715
Italy: 039 69061234 (039 is local city code not country code)
Japan: >From TI Campus use 8 995 7777
Outside TI use 03 4331 3777
Malaysia: >From IP phone dial 2643799
From Kuala Lumpur dial 4264 3799
Outside Kuala Lumpur dial (03)4264 3799
Norway: 2 295 8744
Philippines: >From Baguio City use 4471177
From Metro Manila area use 8702477
Singapore: >From IP phone dial 3894777
Outside TI use 6389 4777
South Korea: >From IP phone dial 5606998
From Seoul dial 5606998
Outside Seoul dial (02)5606998
Sweden: 08 58755577
Taiwan: >From IP phone dial 1363
From Taipei dial 2241 1363
Outside Taipei dial (02)2241 1363
Turkey: Landline Only dial 0811 288 0001
then enter 877 633 1123
UK: 01604 663003
US: 972 995 7777 or 1877 561 6828

Recurring conferences
First scheduled conference: Tue Jun 26, 2012
Recurrence frequency: Weekly - Every 1 week(s) on Tuesday
Recurrence ends: End on Fri Jun 21, 2013, 10:40 AM CDT



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


Re: Host authenticity failures

Thornburg, Christopher A <christopher.a.thornburg@...>
 

Yes…this is still happening. L

 

From: Stewart, David C
Sent: Friday, January 04, 2013 7:50 PM
To: Thornburg, Christopher A; yocto@...
Subject: Re: [yocto] Host authenticity failures

 

Is this still a problem?

 

From: <Thornburg>, Christopher A <christopher.a.thornburg@...>
Date: Wednesday, January 2, 2013 2:48 PM
To: "yocto@..." <yocto@...>
Subject: [yocto] Host authenticity failures

 

I’ve started getting the following error from bitbake when it’s trying to access my git server:

 

The authenticity of host '[<githost>]:<port>([<IP>]:<port>)' can't be established.

DSA key fingerprint is <blah>

 

I understand this error means that the server’s key has probably changed, and I understand in general how to deal with this via SSH config. When I manually ssh’d to the server the first time after receiving the error, I got the same message, as expected. I entered “yes” and tried again to verify that the error went away. It did. I think ran bitbake again and got the same error. I changed my ~/.ssh/ssh_config file to disable StrictHostKeyChecking and still get the error.

 

Is bitbake somehow using different known_hosts and ssh_config files from the ones I use for interactive logins? Other ideas on how to resolve this?

 


[meta-baryon][PATCH 4/4] schroedinger: specify the version of MPL in use

Kevin Strasser <kevin.strasser@...>
 

Signed-off-by: Kevin Strasser <kevin.strasser@...>
---
recipes-multimedia/schroedinger/schroedinger.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-multimedia/schroedinger/schroedinger.inc b/recipes-multimedia/schroedinger/schroedinger.inc
index 4853616..7e84eed 100644
--- a/recipes-multimedia/schroedinger/schroedinger.inc
+++ b/recipes-multimedia/schroedinger/schroedinger.inc
@@ -1,5 +1,5 @@
HOMEPAGE = "http://schrodinger.sourceforge.net/"
-LICENSE = "MPL GPLv2 LGPLv2 MIT"
+LICENSE = "MPL-1.1 GPLv2 LGPLv2 MIT"
LIC_FILES_CHKSUM = "file://COPYING;md5=d91a46405fc074b88c963cc4f2a0aae9 \
file://COPYING.GPL;md5=e181e3b7c66f5f96921d813c1074f833 \
file://COPYING.LGPL;md5=38c893e21baec4cd75ad800ba9e2410a \
--
1.7.9.5


[meta-baryon][PATCH 3/4] baryon-image: use parted instead of util-linux

Kevin Strasser <kevin.strasser@...>
 

util-linux replaces the 'reset' command provided by busybox with
a script that uses 'tset', which fails because it isn't installed.

Signed-off-by: Kevin Strasser <kevin.strasser@...>
---
recipes-extended/images/baryon-image.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-extended/images/baryon-image.bb b/recipes-extended/images/baryon-image.bb
index 56b160c..656fdba 100644
--- a/recipes-extended/images/baryon-image.bb
+++ b/recipes-extended/images/baryon-image.bb
@@ -2,7 +2,7 @@ IMAGE_FEATURES = "nfs-server package-management ssh-server-dropbear debug-tweaks

inherit core-image

-IMAGE_INSTALL += "samba procps mdadm e2fsprogs-mke2fs util-linux \
+IMAGE_INSTALL += "samba procps mdadm e2fsprogs-mke2fs parted \
webmin \
webmin-module-status \
webmin-module-proc \
--
1.7.9.5


[meta-baryon][PATCH 2/4] ffmpeg: build position independent code where possible

Kevin Strasser <kevin.strasser@...>
 

Fixes several of the textrel warnings the package has been
producing.

Signed-off-by: Kevin Strasser <kevin.strasser@...>
---
recipes-multimedia/ffmpeg/ffmpeg_0.6.1.bb | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/recipes-multimedia/ffmpeg/ffmpeg_0.6.1.bb b/recipes-multimedia/ffmpeg/ffmpeg_0.6.1.bb
index 232cea1..a715ad7 100644
--- a/recipes-multimedia/ffmpeg/ffmpeg_0.6.1.bb
+++ b/recipes-multimedia/ffmpeg/ffmpeg_0.6.1.bb
@@ -2,7 +2,7 @@ require ffmpeg.inc

LICENSE = "LGPLv2.1+ & GPLv2+"
DEPENDS += "schroedinger libgsm"
-PR = "${INC_PR}.1"
+PR = "${INC_PR}.2"

SRC_URI = "http://ffmpeg.org/releases/ffmpeg-${PV}.tar.bz2"
SRC_URI[md5sum] = "4f5d732d25eedfb072251b5314ba2093"
@@ -28,6 +28,7 @@ EXTRA_OECONF = " \
--enable-pthreads \
--enable-shared \
--enable-swscale \
+ --enable-pic \
--extra-cflags="${TARGET_CFLAGS} ${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS}" \
--extra-ldflags="${TARGET_LDFLAGS} ${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS}" \
--prefix=${prefix}/ \
--
1.7.9.5


[meta-baryon][PATCH 1/4] webmin: remove perl-module-warnings-register RDEPENDS

Kevin Strasser <kevin.strasser@...>
 

As of poky commit 51cbb5ae76a22d465e2f6c5ef923ec2682624e3b,
the module is included by default and an error is produced if
requested.

Fixes [YOCTO #3530]

Signed-off-by: Kevin Strasser <kevin.strasser@...>
---
recipes-extended/webmin/webmin_1.590.bb | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/recipes-extended/webmin/webmin_1.590.bb b/recipes-extended/webmin/webmin_1.590.bb
index a408092..c2d593a 100644
--- a/recipes-extended/webmin/webmin_1.590.bb
+++ b/recipes-extended/webmin/webmin_1.590.bb
@@ -5,11 +5,11 @@ LIC_FILES_CHKSUM = "file://LICENCE;md5=0373ac9f611e542ddebe1ec6394afc3c"

# FIXME: some of this should be figured out automatically
RDEPENDS_${PN} += "perl perl-module-socket perl-module-exporter perl-module-exporter-heavy perl-module-carp perl-module-strict"
-RDEPENDS_${PN} += "perl-module-warnings perl-module-warnings-register perl-module-xsloader perl-module-posix perl-module-autoloader"
+RDEPENDS_${PN} += "perl-module-warnings perl-module-xsloader perl-module-posix perl-module-autoloader"
RDEPENDS_${PN} += "perl-module-fcntl perl-module-tie-hash perl-module-vars perl-module-time-local perl-module-config perl-module-constant"
RDEPENDS_${PN} += "perl-module-file perl-module-file-glob perl-module-file-copy perl-module-sdbm perl-module-sdbm-file perl-module-timelocal perl-module-feature"

-PR = "r0"
+PR = "r1"

SRC_URI = "${SOURCEFORGE_MIRROR}/webadmin/webmin-${PV}.tar.gz \
file://setup.sh \
--
1.7.9.5