Well, I'm in home now monday I'll take a look on this, it should have a
way, maybe a little hack is needed, thanks for informing, best regards I
keep in touch
Em 26/06/2015 21:39, "Nikolay Dimitrov" escreveu:
> Hi Daniel,
>
> On 06/27/2015 03:30 AM, Daniel. wrote:
>
>> What you mean about deploye
Hi Daniel,
On 06/27/2015 03:30 AM, Daniel. wrote:
What you mean about deployed? They are compiled but doesnt go to
tmp/deploy folder?!
Exactly. In my project I also don't use the sdcard image, but I just
have to leave it because of the previously described behavior.
Guess how I discovered it
What you mean about deployed? They are compiled but doesnt go to tmp/deploy
folder?!
Im building to imx6 :/
Em 26/06/2015 21:25, "Nikolay Dimitrov" escreveu:
> Hi guys,
>
> On 06/26/2015 11:32 PM, Daniel. wrote:
>
>> Hmm, this seems cleaner than setting whole IMAGE_FSTYPES, I'll try!
>>
>> Thank
Hi guys,
On 06/26/2015 11:32 PM, Daniel. wrote:
Hmm, this seems cleaner than setting whole IMAGE_FSTYPES, I'll try!
Thank you!
2015-06-26 17:28 GMT-03:00 Gary Thomas mailto:g...@mlbassoc.com>>:
On 2015-06-26 13:52, Leonardo Sandoval wrote:
On 06/26/2015 02:45 PM, Daniel. wrote:
Bian,
thanks,
merged.
- armin
On 06/25/2015 12:19 AM, Bian Naimeng wrote:
WARNING: QA Issue: /etc/init.d/samhain-server_samhain-server contained in
package samhain-server requires /bin/bash, but no providers found in its
RDEPENDS [file-rdeps]
Signed-off-by: Bian Naimeng
---
recipes-secu
Hmm, this seems cleaner than setting whole IMAGE_FSTYPES, I'll try!
Thank you!
2015-06-26 17:28 GMT-03:00 Gary Thomas :
> On 2015-06-26 13:52, Leonardo Sandoval wrote:
>
>> On 06/26/2015 02:45 PM, Daniel. wrote:
>>
>>> Does any one knows how to avoid the creation of .sdcard images? This ones
>>>
On 2015-06-26 13:52, Leonardo Sandoval wrote:
On 06/26/2015 02:45 PM, Daniel. wrote:
Does any one knows how to avoid the creation of .sdcard images? This ones
The variable controlling the type of output images is IMAGE_FSTYPES, so you can
redefine it under your local.conf. To see the current c
OK, thanks for that Bian
-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On
Behalf Of Bian, Naimeng
Sent: Thursday, June 25, 2015 11:51 AM
To: yocto@yoctoproject.org
Subject: [yocto] [meta-cgl][RFC]upgrade resource-agents
Hi all
We have a
On 06/26/2015 02:45 PM, Daniel. wrote:
Does any one knows how to avoid the creation of .sdcard images? This ones
The variable controlling the type of output images is IMAGE_FSTYPES, so
you can redefine it under your local.conf. To see the current content,
you can do
$bitbake -e | grep IMAGE_
Does any one knows how to avoid the creation of .sdcard images? This ones
takes a lot of diskspace and I have to delete it periodically, which gives
headaches about cleaning everything every time. A have an 50GB partition
and from month to month I get out of disk space. :(
Thanks in advance
--
*
From: Mariano Lopez
This add a tooltip in the upstream status field that
show how long the recipe hasn't been updated.
Signed-off-by: Mariano Lopez
---
rrs/models.py | 15 +++
rrs/views.py | 23 ++-
templates/rrs/recipes.html | 8
Software/Hardware Used:
Yocto poky-dizzy-12.0.1
AMD Radeon E8860 GFX Card
Hi all,
I am trying write up a recipe that is supposed to pull in a custom radeon.conf
file and install it into Yocto's rootfs at /usr/share/X11/xorg.conf.d. This
file is basically an Xorg configuration file that enables
Current Dev Position: 1.9 Milestone 2 (M2)
Next Deadline: M2 cut off of July 27th at noon GMT
SWAT team rotation: Beth -> Saul
https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team
Key Status/Updates:
YP 1.9 M1 is in QA - Target for release is before July 10th.
https://wiki.yoctoprojec
On 06/25/2015 11:02 PM, Aníbal Limón wrote:
I'm glad to announce the enabling of Automatic Upgrade Helper (a.k.a.
AUH), the AUH is a service
that provides recipe upgrades and will be run on weekly basis.
If you are a maintainer (listed in [1]) you will receive AUH emails with
Recipe upgrades whe
On 26 June 2015 at 15:42, Jon Szymaniak wrote:
> Back to the git depth point... why is "--depth 1" not the default for all
> cases? Could anyone elaborate on some use cases where we'd actually want
> the entire history for builds?
>
I'm sure I've been told that it's not as simple as you'd expec
On Fri, Jun 26, 2015 at 10:19 AM, Burton, Ross
wrote:
>
>
> On 26 June 2015 at 15:16, Jon Szymaniak wrote:
>
>> I'm open to other suggestions as well, as this was just a first stab at
>> it. I've been seeing that cloning this git repo containing binary firmware
>> blobs takes an absurd amount of
On Fri, Jun 26, 2015 at 4:31 AM, Burton, Ross wrote:
>
> On 26 June 2015 at 05:16, Jon Szymaniak wrote:
>
>> GitHub provides this ability to download repository contents at
>> a specified changeset as a zip file. This is generally *much* quicker
>> than fetching the entire git repository.
>>
>
>
On 26 June 2015 at 15:16, Jon Szymaniak wrote:
> I'm open to other suggestions as well, as this was just a first stab at
> it. I've been seeing that cloning this git repo containing binary firmware
> blobs takes an absurd amount of time, if it even finishes at all
> successfully.
>
I believe git
On 25 June 2015 at 21:02, Aníbal Limón wrote:
> I'm glad to announce the enabling of Automatic Upgrade Helper (a.k.a.
> AUH), the AUH is a service
> that provides recipe upgrades and will be run on weekly basis.
>
Excellent news, thanks Anibal for working on this!
(one day I'll figure out where
On 26 June 2015 at 10:07, Gary Thomas wrote:
> Is that something that can be in the recipe, or is this ability
> something that needs to be added to the bitbake/OE-core infrastructure?
>
The fetcher needs to be patched.
Ross
--
___
yocto mailing list
On 2015-06-26 02:31, Burton, Ross wrote:
On 26 June 2015 at 05:16, Jon Szymaniak mailto:jon.szyman...@gmail.com>> wrote:
GitHub provides this ability to download repository contents at
a specified changeset as a zip file. This is generally *much* quicker
than fetching the entire git
On 26 June 2015 at 05:16, Jon Szymaniak wrote:
> GitHub provides this ability to download repository contents at
> a specified changeset as a zip file. This is generally *much* quicker
> than fetching the entire git repository.
>
Github also can and will regenerate these tarballs whenever it fee
22 matches
Mail list logo
