Re: [yocto] [bitbake] Failure to compile UltraJson, LMDB and Netifaces python modules recipes for Krogoth.

2016-12-20 Thread Mateusz Orzoł 


W dniu 2016-12-20 o 10:46, Mateusz Orzoł pisze:
>
>
>
> W dniu 2016-12-20 o 00:43, Khem Raj pisze:
>>
>>
>> On Mon, Dec 19, 2016 at 1:46 PM, Mateusz Orzoł
>> > > wrote:
>>
>> Hi everyone,
>>
>> I am migrating my old Yocto image from kernel 3.8 to 4.1 on the
>> Intel Quark based platform. After dealing with some SPI driver
>> issues now I've encountered some strange bitbake behaviour. My
>> web application requires UltraJson , LMDB and Netifaces modules.
>> After running bitbake  I am getting a lot of undefined reference
>> errors. In all three cases pretty similar. Exemplary log for
>> python-ujson is here: http://pastebin.com/8ms9PgnY . It seems
>> like the python environment wasn't linked properly but many other
>> python recipes have no problem with compiling.
>>
>> The python-ujson recipe comes from here
>> https://layers.openembedded.org/layerindex/recipe/49510/
>> . In 
>> previous distribution with kernel 3.8 it was working without any
>> problem.
>>
>> Have you got any idea what could be wrong or what should I check
>> first?
>>
>>
>> ​The error seems to have nothing to do with kernel version. Are you
>> upgrading the whole of yocto framework from one release to another ?
>> and if yes from which version to which new version.​
>>
>>  
> I am upgrading from 1.4.2 Dylan version to Krogoth. Firstly I've
> prepared clean Krogoth image which worked fine. Now I am adding
> necessary recipes and packages one by one and currently the only
> problem I've encountered is the mentioned one.
Hi,
W have found found quick fix for this.  The errors disappeared when all
the build flags were cleared in mentioned python modules recipes. It
means TARGET_CFLAGS = "" LDFLAGS = "" CFLAGS = "" in module .bb file. It
was checked on the device that modules are visible in python and they
work. I don't know why this helped and also what was causing the issue.
Do you have any clues what was wrong and how to fix it in proper way?
>>
>> Thank you for your help in advance,
>>
>> Mateusz
>>
>>
>> -- 
>>  
>>
>> --
>> ___
>> 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] [Openembedded-architecture] Deprecating hddimg/isoimg

2016-12-20 Thread Mark Hatle 
On 12/20/16 2:23 PM, Saul Wold wrote:
> 
> Folks,
> 
> For years we have wanted to get rid of the hddimg/iso type, we now have
> the WIC tool integrated into OE-Core such that we can build properly
> partitioned disk images.

No objection to getting rid of them, but I would love to see them replace with
one or more sample WIC configurations that resulted in -exactly- the same 
behavior.

--Mark

> Historically the hddimg was a single FAT filesystem that contained
> boot-loader, the kernel and a rootfs.img file for booting Intel Arch
> machines. This has a 4G limit due to the FAT limitations and we are
> starting to see this limit hit more frequently.
> 
> Are there any other usages out there that we are not aware of?
> 
> Any reasons that this should not get deprecated at this time?
> 
> Sau!
> 
> ___
> Openembedded-architecture mailing list
> openembedded-architect...@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
> 

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

[yocto] Deprecating hddimg/isoimg

2016-12-20 Thread Saul Wold 

Folks,

For years we have wanted to get rid of the hddimg/iso type, we now have
the WIC tool integrated into OE-Core such that we can build properly
partitioned disk images.

Historically the hddimg was a single FAT filesystem that contained
boot-loader, the kernel and a rootfs.img file for booting Intel Arch
machines. This has a 4G limit due to the FAT limitations and we are
starting to see this limit hit more frequently.

Are there any other usages out there that we are not aware of?

Any reasons that this should not get deprecated at this time?

Sau!

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

[yocto] yocto autobuilder scheduler

2016-12-20 Thread Mircea Gliga 

Hi

I'm using yocto-autobuilder to build my images. I have a GitPoller 
scheduler, that triggers a build when one of the layers, eg 
meta-mylayer, changes.

In my buildset I have something like:

[...]
repos: [{'poky':
{'repourl':'git://git.yoctoproject.org/poky',
 'layerversion':{'core':'meta', 'yocto':'meta-yocto', 
'poky':'meta-poky', 'yoctobsp':'meta-yocto-bsp'},

 'branch':'krogoth'}},
{'meta-openembedded':
{'repourl':'git://git.openembedded.org/meta-openembedded',
 'layerversion':{'mete-oe':'meta-oe', 
'networking':'meta-networking', 'python':'meta-python'},
 # add autoinclude false to prevent automatic add of teh 
meta-openembedded foler to the BBLAYERS; sub folders must be added

 'autoinclude': False,
 'branch':'krogoth'}},
{'meta-mylayer':
{'repourl':'http://server.tld/git/meta-mylayer.git',
 'branch':'master'}},
   ]
scheduler: [{'git-poller-scheduler':
{'type':'SingleBranchScheduler',
 'changesource':'GitPoller',
 'repository':'meta-mylayer',
 'branch':'master',
 'interval':'300',
 'stable-timer':30}}]

Is it possible to trigger a build when another repository, eg. the 
application repository, changes ? Obviously, that repo is not in the 
"repos" field of the buildset.
According to the "repository" field documentation, "the repository to 
attach the scheduler to; this is the repo name from the 'repos' 
section;[...]"


Thanks and regards.


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

[yocto] questions about KBUILD_DEFCONFIG explanation in kernel-dev manual

2016-12-20 Thread Robert P. J. Day 

  (yes, i really am digging through the user guides these days ...)

from kernel-dev manual, section 2.2.4:

  "To specify an "in-tree" defconfig file, edit the recipe that builds
   your kernel so that it has the following command form:

 KBUILD_DEFCONFIG_KMACHINE ?= defconfig_file

   You need to append the variable with KMACHINE and then supply the
   path to your "in-tree" defconfig file."

first, i'm going to tag the "KMACHINE" part above with
, since it pretty clearly needs it.

  next, you need to "supply the path" to the defconfig file? uh, don't
you just need to give the simple name of the in-tree defconfig file
you want to use as it is somewhere under arch//configs in the
kernel source tree? here's a snippet from the meta-altera layer:

   KBUILD_DEFCONFIG ?= "socfpga_defconfig"
   KBUILD_DEFCONFIG_stratix10swvp ?= "defconfig"
   KBUILD_DEFCONFIG_10m50 ?= "10m50_defconfig"

seems like one needs just the name of the defconfig file to be used,
there's no concept of needing a "path" to the file, is there?

  next, it appears that one does *not* "need to append the variable
with KMACHINE", given one of the lines from meta-altera above, is that
correct? this just sets a default, no?

   KBUILD_DEFCONFIG ?= "socfpga_defconfig"

  and finally, must all defconfig files identified via
KBUILD_DEFCONFIG be an "in-tree" file? i ask since this line above:

   KBUILD_DEFCONFIG_stratix10swvp ?= "defconfig"

is potentially confusing, and might make someone perusing the source
to think that's an alternative way to point at their "out-of-tree"
defconfig file. but it's not, is it?

  i checked that machine type, and it's armv8, so i'm *assuming* that
line would refer to the in-tree file arch/arm64/configs/defconfig, is
that right?

  i think that will do it for now.

rday

-- 


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

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


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

[yocto] potentially confusing wordage in kernel dev manual

2016-12-20 Thread Robert P. J. Day 

  section 2.2.4:

  "By default, the OpenEmbedded build system looks for defconfig files
  in the layer used for Metadata, which is "out-of-tree", and then
  configures them using the following:

 SRC_URI += "file://defconfig"


um ... that wording makes it sounds like it's the OE build system
that automatically adds a local defconfig file to SRC_URI. does anyone
else see the potential confusion in the way that's explained?

rday

-- 


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

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


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

[yocto] in yocto-docs, many tags should properly be tags

2016-12-20 Thread Robert P. J. Day 

  pretty sure i mentioned this once upon a time but, for pedantic
precision, quite a few strings currently tagged with  should
rather be tagged with . i'm currently proofing the kernel dev
manual and things like FILESPATH and FILESEXTRAPATHS are rendered with
the use of , which isn't really appropriate.

  *currently*, there is no difference in the final rendering of these
two tags, but one never knows when that might be desirable.

  obviously, not a high priority if any.

rday

-- 


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

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


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

Re: [yocto] [bitbake] Failure to compile UltraJson, LMDB and Netifaces python modules recipes for Krogoth.

2016-12-20 Thread Mateusz Orzoł 


W dniu 2016-12-20 o 00:43, Khem Raj pisze:
>
>
> On Mon, Dec 19, 2016 at 1:46 PM, Mateusz Orzoł
>  > wrote:
>
> Hi everyone,
>
> I am migrating my old Yocto image from kernel 3.8 to 4.1 on the
> Intel Quark based platform. After dealing with some SPI driver
> issues now I've encountered some strange bitbake behaviour. My web
> application requires UltraJson , LMDB and Netifaces modules. After
> running bitbake  I am getting a lot of undefined reference errors.
> In all three cases pretty similar. Exemplary log for python-ujson
> is here: http://pastebin.com/8ms9PgnY . It seems like the python
> environment wasn't linked properly but many other python recipes
> have no problem with compiling.
>
> The python-ujson recipe comes from here
> https://layers.openembedded.org/layerindex/recipe/49510/
> . In 
> previous distribution with kernel 3.8 it was working without any
> problem.
>
> Have you got any idea what could be wrong or what should I check
> first?
>
>
> ​The error seems to have nothing to do with kernel version. Are you
> upgrading the whole of yocto framework from one release to another ?
> and if yes from which version to which new version.​
>
>  
I am upgrading from 1.4.2 Dylan version to Krogoth. Firstly I've
prepared clean Krogoth image which worked fine. Now I am adding
necessary recipes and packages one by one and currently the only problem
I've encountered is the mentioned one.
>
> Thank you for your help in advance,
>
> Mateusz
>
>
> -- 
>  
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org 
> https://lists.yoctoproject.org/listinfo/yocto
> 
>
>

-- 
3City Electronics Sp. z o.o. Abrahama 1A/5.02-5.05 80-307 Gdańsk tel.:
+48 58 765 01 48
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto