gcc 4.7 in meta-linaro-toolchain

[Nicolas Dechesne]

hi,

in meta-linaro-toolchain (dylan branch), the recipe points to
gcc-linaro-4.7 from 1304 release:

https://git.linaro.org/gitweb?p=openembedded/meta-linaro.git;a=blob;f=meta-linaro-toolchain/recipes-devtools/gcc/gcc-linaro-4.7.inc;h=69152514ad7872e7d4a33033cb9507ebc45c81b6;hb=79d20a4127639e961e671de24c94ea2621fce93e#l4

However that file seems to have be removed/cleaned from where the recipe
expects it:

http://cbuild.validation.linaro.org/snapshots/

As such anyone build against that branch will now fails.

That brings some questions:
 - How do we want to deal with that situation? Is (
http://snapshots.linaro.org/openembedded/sources) guaranteed to always keep
all tarballs, forever? Or should we put such tarballs in such a place (and
update recipes accordingly)? There can be non Linaro users of our layers
(it's even referenced publicly here:
http://layers.openembedded.org/layerindex/layer/meta-linaro-toolchain/)

 - most of the recent commits seem to go to master, not dylan. so it
clearly stated somewhere what our official requirements/committments are
wrt to OE branch support?

thanks

nicolas
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: gcc 4.7 in meta-linaro-toolchain

[Fathi Boudra]

Hi,

On 25 June 2013 11:50, Nicolas Dechesne  wrote:
> hi,
>
> in meta-linaro-toolchain (dylan branch), the recipe points to gcc-linaro-4.7
> from 1304 release:
>
> https://git.linaro.org/gitweb?p=openembedded/meta-linaro.git;a=blob;f=meta-linaro-toolchain/recipes-devtools/gcc/gcc-linaro-4.7.inc;h=69152514ad7872e7d4a33033cb9507ebc45c81b6;hb=79d20a4127639e961e671de24c94ea2621fce93e#l4
>
> However that file seems to have be removed/cleaned from where the recipe
> expects it:
>
> http://cbuild.validation.linaro.org/snapshots/
>
> As such anyone build against that branch will now fails.
>
> That brings some questions:
>  - How do we want to deal with that situation? Is
> (http://snapshots.linaro.org/openembedded/sources) guaranteed to always keep
> all tarballs, forever? Or should we put such tarballs in such a place (and
> update recipes accordingly)? There can be non Linaro users of our layers
> (it's even referenced publicly here:
> http://layers.openembedded.org/layerindex/layer/meta-linaro-toolchain/)

As the name implies, it's snapshots builds:
http://cbuild.validation.linaro.org/snapshots/
http://snapshots.linaro.org/openembedded

They are guaranteed to _not_ stay.

We (Linaro OE maintainers) should use stable, released tarballs.

That's the reason we have 2 lines for the SRC_URI:
https://git.linaro.org/gitweb?p=openembedded/meta-linaro.git;a=blob;f=meta-linaro-toolchain/recipes-devtools/gcc/gcc-linaro-4.7.inc

When a toolchain release candidate is available, we switch to the
snapshots build, but we should switch back to the released build as
soon as it's available.

>  - most of the recent commits seem to go to master, not dylan. so it clearly
> stated somewhere what our official requirements/committments are wrt to OE
> branch support?

We don't have any commitment wrt OE branch support. IMO, we should fix
the URL to use
https://releases.linaro.org/13.04/components/toolchain/gcc-linaro/4.7/gcc-linaro-4.7-2013.04.tar.bz2

> thanks
>
> nicolas
>
> ___
> linaro-dev mailing list
> linaro-dev@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-dev

Cheers,
--
Fathi Boudra
Builds and Baselines Manager | Release Manager
Linaro.org | Open source software for ARM SoCs

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[ANN] ci.linaro.org security realm and authorization strategy

[Fathi Boudra]

Hi,

ci.linaro.org has switched the security realm from Launchpad OpenID to
Crowd SSO.
In practice, it means that authentication is using your regular
login/password from login.linaro.org service.

In addition, the project authorization strategy has been switched to
project-based matrix authorization strategy.

Those changes allows more permissions granularity at the project/job level.
It is now possible to create private/restricted jobs or allow
anonymous users to read your job configuration if you want.

Cheers,
--
Fathi Boudra
Builds and Baselines Manager | Release Manager
Linaro.org | Open source software for ARM SoCs

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev