Re: [yocto] Chromium browser for Yocto BSPs

[Cui, Dexuan]

Hi Kishore,
The download link for flash-10 seems invalid now: it returns "ERROR 404: Not 
Found".
flash-11 was released and we may want to use that.

Thanks,
-- Dexuan

From: Bodke, Kishore K
Sent: Tuesday, November 29, 2011 5:57 AM
To: yocto@yoctoproject.org; Cui, Dexuan
Cc: Saxena, Rahul
Subject: Chromium browser for Yocto BSPs

Hi,
I am trying to plugin the Chromium browser for one of meta-intel bsp.

I get the build failure 
flash-plugin_10.3.183.10.bb
 file for trying to fetch the flash plugin from different mirrors and not able 
to find.

I am building with bitbake core-image-m2m-jdk.

Attached is the log.

Does anyone saw the same failure?

Thanks
Kishore.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Chromium browser for Yocto BSPs

[Bodke, Kishore K]

Hi,
I am trying to plugin the Chromium browser for one of meta-intel bsp.

I get the build failure 
flash-plugin_10.3.183.10.bb
 file for trying to fetch the flash plugin from different mirrors and not able 
to find.

I am building with bitbake core-image-m2m-jdk.

Attached is the log.

Does anyone saw the same failure?

Thanks
Kishore.


log.do_fetch.29542
Description: log.do_fetch.29542
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Native build tools question

[Richard Purdie]

On Mon, 2011-11-28 at 16:17 -0500, Marc Ferland wrote:
> Hi,
> 
> I'm currently writing a recipe for the visualization toolkit (vtk). 
> 
> To compile, this library invokes executables that are generated
> on-the-fly by the compilation process (a little bit like Qt and
> qmake). 
> 
> The path to these executables can be specified to cmake when building
> vtk. So far I was able to make it work by hard-coding this "tools"
> directory in my recipe to a path on my local machine. It works, but it
> is not very portable.
> 
> What's the official way to handle such libraries?
> 
> Should I first do a native build, then use this native build directory
> when cross-compiling? If so, is there any examples I should look into?

Yes, a -native recipe to build the tools and then use those native tools
in the cross built is the way to go.

Take a look at any of the recipes which have a DEPENDS on a native
version of themselves. A simple example is say, the bison recipe and the
logic is something like:

DEPENDS = "bison-native"
DEPENDS_virtclass-native = ""

BBCLASSEXTEND = "native"

(simplified slightly)

Cheers,

Richard



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

[yocto] Native build tools question

[Marc Ferland]

Hi,

I'm currently writing a recipe for the visualization toolkit (vtk).

To compile, this library invokes executables that are generated on-the-fly
by the compilation process (a little bit like Qt and qmake).

The path to these executables can be specified to cmake when building vtk.
So far I was able to make it work by hard-coding this "tools" directory in
my recipe to a path on my local machine. It works, but it is not very
portable.

What's the official way to handle such libraries?

Should I first do a native build, then use this native build directory when
cross-compiling? If so, is there any examples I should look into?

Regards,

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

[yocto] Agenda: Yocto Technical Team Meeting - Tuesday, November 29, 2011 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US & Canada).

[Liu, Song]

Agenda:

* Opens collection - 5 min (Song)
* Yocto 1.0.2 and 1.1.1 point release update - 10 min (Josh/Beth)
* Yocto 1.2 M1 Status (features development) - 10 min (Song/Beth)
  https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.2_Status 
* Opens - 10 min
* Action item Review - 5 min
  1. Mark will review unsorted features from Wind River team and try to have 
them scheduled.
  2. Paul will ping Jeremy on 1598.
* Weekly team sharing (20 min)


-Original Appointment-


Conference details 
Conference name: 
Yocto Technical Team
Conference date/start time: 
Tue Jun 28, 2011 at 10:00 AM Central Daylight Time 
Participants: 
30
Duration: 
60 minutes 
Participant passcode: 
49611427 
Dial-in number: 
1.972.995. 
US Toll Free number: 
1.877.561.6828 
BlackBerry users, click this link to join your conference as a chairperson:
1.972.995.x67184230#
BlackBerry users, click this link to join your conference as a participant:
1.972.995.x49611427#
 
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-995 or 8784277 
Beijing Out of Office dial 5878 4277
China (Shanghai): 
>From office dial 8-995 or 3073322 
Shanghai Out of Office dial 2307 3322
China (Shenzen): 
>From office dial 8-995 or 6007877 
Shenzen Out of Office dial 2600 7877
China (Other Cities): 
>From IP phone dial 8-995 
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 8995
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  
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  or 1877 561 6828

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

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

Re: [yocto] related to telnetd

[Paul Eggleton]

On Monday 28 November 2011 09:44:42 Navani Kamal Srivastava wrote:
> I am looking for "telnetd" utility so that I can take telnet session of my
> board. Can you please tell me in order to include this utility in my rootfs
> which packages I need to include in my *.bb file.

So the first question (which you might be expecting) is, is there a good reason 
why you would not use ssh in preference to telnet?

You could enable CONFIG_TELNETD in busybox if you really need telnetd, but for 
most purposes dropbear providing ssh should be enough for remote shell access.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] related to telnetd

[Navani Kamal Srivastava]

Hello,

I am looking for "telnetd" utility so that I can take telnet session of my 
board. Can you please tell me in order to include this utility in my rootfs 
which packages I need to include in my *.bb file.

Thanks & Regards,
Navani Kamal Srivastava


Larsen & Toubro Limited

www.larsentoubro.com

This mail is classified as: ( ) L&T Proprietary ( ) L&T Confidential (X) L&T 
Internal Use ( ) L&T General Business
This email may contain confidential or privileged information for the intended 
recipient(s). If you are not the intended recipient, please do not use or 
disseminate the information, notify the sender and delete it from your system.




Larsen & Toubro Limited

www.larsentoubro.com

This Email may contain confidential or privileged information for the intended 
recipient (s) If you are not the intended recipient, please do not use or 
disseminate the information, notify the sender and delete it from your system.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH] EFI support for IA

[Darren Hart]

On 11/28/2011 01:06 AM, Josef Ahmad wrote:
> Hi Darren,
> 
> I checked out your dvhart/efi branch and attempted to build my BSP.
> I inlcuded "efi" to my MACHINE_FEATURES, and "live" to my IMAGE_FSTYPES,
> so as to get an .hddimg file.
> 
> I haven't found GRUB in my deployed hddimg though. Maybe I'm missing
> something?


Hi Josef,

Do you see bootia32.efi and grub.cfg in the root directory of the
hddimg? That is all it installs.

--
Darren

> 
> Thanks
> 
> Josef
> 
> On 24 November 2011 16:01, Darren Hart  > wrote:
> 
> On 11/24/2011 12:48 AM, Josef Ahmad wrote:
> > Hi Darren,
> >
> > I'll track your branch to sync our efforts.
> 
> Hi Josef,
> 
> Great. I just sent an RFC patch series to this list last night. Please
> try it out and see how it goes.
> 
> >
> > I meant to only generate the Grub EFI binary for the target, without
> > including any tool/library into the root filesystem: I assumed
> that it's
> > sufficient to deploy the bootloader onto the top-level image.
> That's why
> 
> Agreed.
> 
> > I build natively the mkimage tool and run that on the host to get the
> > EFI executable. Now, as you justly point out, there's a target
> mismatch:
> > mkimage incorrectly calls out the host architecture under the -O
> switch,
> > whereas it should have been something like ${TARGET_ARCH}-efi.
> 
> Right. That took some doing, but it is now resolved in my branch.
> 
> >
> > That said, surely a solution that embodies the GRUB tools into the
> root
> > filesystem is desirable.
> 
> That can be accomplished using the grub_1.99 recipe. Perhaps we should
> enable building with EFI if MACHINE_FEATURES includes "efi". I consider
> that to be separate from this effort.
> 
> 
> > Feel free to merge my grub config generator into your branch, as
> well as
> > any of my contrib you may like. Speaking of grub.bbclass, I named
> it so
> > as it's not specifically tied to the EFI mode. It basically builds up
> > the grub configuration menu, based off machine-specific parameters. I
> > implemented it among the lines of syslinux.bbclass.
> 
> While the menu creation isn't necessarily EFI specific, the rest of the
> bbclass is. If we wanted to, we could create another grub.bbclass that
> can do a live image with GRUB legacy booting. However, I'm also working
> to use the syslinux family of loaders wherever possible. I'm using
> grub-efi as a stop-gap until an EFI syslinux becomes available. The idea
> here is to keep things consistent from the live image to the installed
> image, as well as reduce the number of bootloaders and configuration
> files we need deal with for a given BSP.
> 
> Please review the patch series I sent out and let me know if it works
> for your purposes. General code review is needed as well.
> 
> Thanks Josef!
> 
> --
> Darren Hart
> Intel Open Source Technology Center
> Yocto Project - Linux Kernel
> ___
> yocto mailing list
> yocto@yoctoproject.org 
> https://lists.yoctoproject.org/listinfo/yocto
> 
> 

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

Re: [yocto] [PATCH] EFI support for IA

[Josef Ahmad]

Hi Darren,

I checked out your dvhart/efi branch and attempted to build my BSP.
I inlcuded "efi" to my MACHINE_FEATURES, and "live" to my IMAGE_FSTYPES, so
as to get an .hddimg file.

I haven't found GRUB in my deployed hddimg though. Maybe I'm missing
something?

Thanks

Josef

On 24 November 2011 16:01, Darren Hart  wrote:

> On 11/24/2011 12:48 AM, Josef Ahmad wrote:
> > Hi Darren,
> >
> > I'll track your branch to sync our efforts.
>
> Hi Josef,
>
> Great. I just sent an RFC patch series to this list last night. Please
> try it out and see how it goes.
>
> >
> > I meant to only generate the Grub EFI binary for the target, without
> > including any tool/library into the root filesystem: I assumed that it's
> > sufficient to deploy the bootloader onto the top-level image. That's why
>
> Agreed.
>
> > I build natively the mkimage tool and run that on the host to get the
> > EFI executable. Now, as you justly point out, there's a target mismatch:
> > mkimage incorrectly calls out the host architecture under the -O switch,
> > whereas it should have been something like ${TARGET_ARCH}-efi.
>
> Right. That took some doing, but it is now resolved in my branch.
>
> >
> > That said, surely a solution that embodies the GRUB tools into the root
> > filesystem is desirable.
>
> That can be accomplished using the grub_1.99 recipe. Perhaps we should
> enable building with EFI if MACHINE_FEATURES includes "efi". I consider
> that to be separate from this effort.
>
>
> > Feel free to merge my grub config generator into your branch, as well as
> > any of my contrib you may like. Speaking of grub.bbclass, I named it so
> > as it's not specifically tied to the EFI mode. It basically builds up
> > the grub configuration menu, based off machine-specific parameters. I
> > implemented it among the lines of syslinux.bbclass.
>
> While the menu creation isn't necessarily EFI specific, the rest of the
> bbclass is. If we wanted to, we could create another grub.bbclass that
> can do a live image with GRUB legacy booting. However, I'm also working
> to use the syslinux family of loaders wherever possible. I'm using
> grub-efi as a stop-gap until an EFI syslinux becomes available. The idea
> here is to keep things consistent from the live image to the installed
> image, as well as reduce the number of bootloaders and configuration
> files we need deal with for a given BSP.
>
> Please review the patch series I sent out and let me know if it works
> for your purposes. General code review is needed as well.
>
> Thanks Josef!
>
> --
> Darren Hart
> Intel Open Source Technology Center
> Yocto Project - Linux Kernel
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto