Re: [yocto] [meta-raspberrypi][PATCH] firmware.inc: fetch from SVN instead of Git

[Nikolay Dimitrov]

Hi Andrei,

On 07/09/2015 11:19 PM, Andrei Gherzan wrote:

On Mon, Jul 6, 2015 at 6:59 PM, Nikolay Dimitrov mailto:picmas...@mail.bg>> wrote:

Hi Ross,

On 07/06/2015 07:58 PM, Nikolay Dimitrov wrote:

Hi Ross,

On 07/06/2015 07:26 PM, Burton, Ross wrote:


On 6 July 2015 at 17:23, Burton, Ross mailto:ross.bur...@intel.com>
>> wrote:

 How latest, remembering that oe-core supports LTS
distros which are
 likely to have old releases of git.


Assuming I'm driving it correctly:

[git init, git remote add origin ...]
$ git fetch  --depth=1 origin
beeafee030a38380c65a9a664003ba50f87aefbf
error: no such remote ref
beeafee030a38380c65a9a664003ba50f87aefbf
$ git --version
git version 2.1.4

That's with the latest Debian release.

Ross


Well, the commits that add this feature are from May-June.2015.
I fully
agree with you that LTS is a factor that can't be ignored.

Kind regards,
Nikolay


Forgot to answer you question - the expected versions to include
this feature are 2.5.0/2.5.1. 


So there is no support for depth clones until 2.5.0? I didn't really
understand.


Well, shallow clones are supported but only for branch tips, which is
not what we need. This feature for shallow cloning a specific revision
is available only in git 2.5.0+. Also, this feature needs a server-side
configuration option to be enabled, in order to work properly.

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

Re: [yocto] [meta-raspberrypi][PATCH] firmware.inc: Fetch a zip instead of cloning a git repo

[Nikolay Dimitrov]

Hi Andrei,

On 07/09/2015 11:13 PM, Andrei Gherzan wrote:

Finally I hop on to this discussion too.

On Mon, Jul 6, 2015 at 12:58 PM, Paul Eggleton
mailto:paul.eggle...@linux.intel.com>>
wrote:

On Monday 06 July 2015 12:48:50 Nikolay Dimitrov wrote:
> One issue with the regularly changing tarball checksums is that people
> start to get used to thes changes (e.g. everything looks like false
> positive). Currently the tarball checksums and SCM revisions are
> probably the most important tool for builds traceability. If we get
> used to think about these checksums as "unreliable", it will be much
> easier to miss an important component change, which would otherwise
> ring a bell.

Fully agreed.

There are a couple of things I think we can do here:

1) Implement shallow cloning in bitbake's git fetcher as suggested. This
shouldn't be too tricky. I've filed a bug to track this:

https://bugzilla.yoctoproject.org/show_bug.cgi?id=7958

(Richard is the default assignee, but anyone could potentially work
on this).


This should be the fix that would really fix the issue. And would be a
useful feature for many other BSPs / layers out there.

2) In the mean time we could consider upload git mirror tarballs to
a source
mirror that gets enabled through meta-raspberrypi (would need to be via
PREMIRRORS to actually solve the issue). This has the advantage that it
wouldn't require any changes to the kernel recipe itself, but new
tarballs
would of course need to be uploaded every time SRCREV is changed in the
recipe.


And until 1) is done, we can have a premirror. Paul, can you upload a
tarball? Can I help you with anything for having this up? After we have
this, can we force premirrors when using a specific layer? Was thinking
of forcing it by adding PREMIRRORS to layer.conf.


I don't think this is a good move. The current solution is already
working properly, although with slower-than-ideal download speed.

Prepackaged tarballs will require constant manpower for supporting,
and it's probably better to be invested into looking for a better
solution.



Using github snapshots is not a good idea. Most of the issues you guys
pointed out above I experienced as well. In my opinion we should combine
Paul's solutions in order to address this problem.

One more thing. Given the fact the the repository we are talking about
is not under our control, we shouldn't rely on releases or other things
from the remote repository.

Andrei




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

[yocto] fitimage and define multiple configurations

[Belisko Marek]

Hi,

I'm using yocto-1.8 and building minimal image for BBB. I want to use
FIT format for kernel build (to be able run same image on BB andf
BBB). So I changed beaglebone.conf following:

-KERNEL_IMAGETYPE = "zImage"
+KERNEL_CLASSES += "kernel-fitimage"
+KERNEL_IMAGETYPE = "fitImage"
KERNEL_DEVICETREE = "am335x-bone.dtb am335x-boneblack.dtb"

When build is finished I can see that fit image is build but only with
default configuration (kernel + first dtb).I'm expecting it should do
2 configurations like: kernel + dtb1 and kernel + dtb2. I can
understand it could be problematic when have multiple kernel images.
Is there any possibility to define mapping in conf for configurations?
I quickly check kernel-fitimage.bbclass but it seems it's not. Thanks,

BR,

marek
-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Autobuilder and 1.9_M1.rc2 status

[Flanagan, Elizabeth]

Last night the AB ran out of space towards the end of its build run.
We had to kick rc2 again. It is currently still running and will be
located at:

http://autobuilder.yoctoproject.org/pub/releases/yocto-yocto-1.9_M1.rc2

I realise the naming is odd. I'm ensuring that that doesn't happen
again. I'll need some time on Monday to push some AB changes out to
make it so that this all occurs from dropdown selection.

One other thing that will be pushed out on Monday is a selector box
for publishing artifacts. My guess is that most mut/master-next builds
don't need artifacts published. If you run builds on the AB, please be
aware of this checkbox, as the AB cleanup scripts take a while and
sometimes we publish artifacts faster than it can cleanup. I'm going
to default it to Publish for now, but will be watching to ensure
people are using it.

-b
-- 
Elizabeth Flanagan
Yocto Project
Build and Release
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Yocto Project Status WW28

[Jolley, Stephen K]

Current Dev Position: 1.9 Milestone 2 (M2)
Next Deadline: M2 cut off of July 27th at noon GMT

SWAT team rotation: Paul -> Ross
https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team

Key Status/Updates:

  *   Too many issues in 1.9M1 RC1 to release, moving to RC2.
  *   1.9 M1 RC2 due to enter QA (build currently in progress)
  *   Many fixes for various random autobuilder failures, still more needed but 
patch queues somewhat unblocked
  *   Data store changes on Bitbake list, will merge on Monday assuming no 
major feedback
  *   No feedback on getVar expansion parameter changes. Fixes posted for 
meta-oe, will likely just merge if no objections

Key YP 1.9 Dates:
1.9 Feature Freeze Date/M3 Cut off: Aug. 24, 2015 noon GMT
YP Final/M4 Cut off: Sept. 28, 2015 noon GMT
1.9 M1 Release Target: Before July 10, 2015  (Will miss deadline.)
1.9 M2 Release Target: Before Aug. 14, 2015
1.9 M3 Release Target: Before Sept. 11 2015
1.9 final Release Target: Before Oct. 30, 2015

Key Status Links for YP:
https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.9_Status
https://wiki.yoctoproject.org/wiki/Yocto_1.9_Schedule
https://wiki.yoctoproject.org/wiki/Yocto_1.9_Features

Tracking Metrics:
WDD 1684 (last week 1640)
(https://wiki.yoctoproject.org/charts/combo.html)

[If anyone has suggestions for other information you'd like to see on this 
weekly status update, let us know!]
Thanks,

Stephen K. Jolley
Yocto Project Program Manager
INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124
*   Work Telephone:  (503) 712-0534
*Cell:(208) 244-4460
* Email: stephen.k.jol...@intel.com

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

[yocto] Unexpected behavior with custom Linux kernel build

[Rudolf Streif]

I am using this recipe to build a very latest kernel from kernel.org:

>>>>>>
DESCRIPTION = "Linux Kernel from Tarball"
SECTION = "kernel"
LICENSE = "GPLv2"

inherit kernel

LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"

LINUX_VERSION ?= "4.2"
LINUX_VERSION_EXTENSION ?= "-custom"
PR = "rc1"
PV = "${LINUX_VERSION}"

SRC_URI = "
https://www.kernel.org/pub/linux/kernel/v4.x/testing/linux-${LINUX_VERSION}-${PR}.tar.xz;name=kernel
"
SRC_URI += "file://defconfig"

SRC_URI[kernel.md5sum] = "3e8331759af56ddd621528b2c7015ae1"
SRC_URI[kernel.sha256sum] =
"3c524ee0446b4ea8288708fa30acd28647317b9724f2d336052130e164c83f29"

S = "${WORKDIR}/linux-${LINUX_VERSION}-${PR}"

COMPATIBLE_MACHINE = "qemux86|qemux86-64"
<<<<<

Yes, that is the somewhat traditional method of building the kernel. The
kernel builds and works fine.

Now I would like to enable Yocto tooling for the kernel so that I can use
configuration fragments by adding

require recipes-kernel/linux/linux-yocto.inc

to the recipe. That worked just fine in the past. The kernel builds and
boots but then in userspace some unexpected things happen: avahi does not
start and login does not work. Reason being:

setgid: Function not implemeted

Why would that change in tooling cause this error?

Build Configuration:
BB_VERSION= "1.27.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING   = "Fedora-21"
TARGET_SYS= "x86_64-poky-linux"
MACHINE   = "qemux86-64"
DISTRO= "poky"
DISTRO_VERSION= "1.8+snapshot-20150710"
TUNE_FEATURES = "m64 core2"
TARGET_FPU= ""
meta
meta-yocto
meta-yocto-bsp= "master:20a3a36547831349d5d8b429cb35f1415a856bda"


The effect is the same when using this recipe to build from kernel.org git
repo:

>>>>>
DESCRIPTION = "Linux Kernel from kernel.org Git Repository"
SECTION = "kernel"
LICENSE = "GPLv2"

require recipes-kernel/linux/linux-yocto.inc

LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"

LINUX_VERSION ?= "4.2"
LINUX_VERSION_EXTENSION ?= "-custom"
PR = "rc1"
PV = "${LINUX_VERSION}+git${SRCPV}"

SRC_URI = "git://
git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git;protocol=git;nocheckout=1;name=machine
"
SRC_URI += "file://defconfig"

SRCREV_machine="d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754"

COMPATIBLE_MACHINE = "qemux86|qemux86-64"
<<<<<<<

Thanks,
Rudi
-- 
*Rudolf J. Streif*
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Release Candidate Build for yocto-yocto-1.9_M1.rc2 now available.

[Poky Build User]

-e 
A release candidate build for yocto-yocto-1.9_M1.rc2 is now available at:

 
http://autobuilder.yoctoproject.org/pub/releases/yocto-yocto-1.9_M1.rc2


Please begin QA on this build as soon as possible.


Build hash information: 
meta-intel : 6b3837170bfda7ce9df409c10e05f66f4b987a89 
meta-fsl-arm : 645749dd76f37e4b9116e6f5a02ee5716b80538a 
meta-minnow : 9c965ef5252e383843d796cd8b50c61b3034b6ae 
meta-qt3 : 3016129d90b7ac8517a5227d819f10ad417b5b45 
meta-fsl-ppc : 36bd6ce8c63b8876c96fc1cd50e43863cdc2e44e 
poky : f9ea480e6c26fea46c3011c4e9d0e2de3d5c81b4 


This is an automated message from
The Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder
Email: elizabeth.flana...@intel.com 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto