Re: Deploying new code to snapshots.linaro.org
Hi Ricardo, Sorry for all the trouble we caused you. У нед, 26. 08 2012. у 07:39 -0300, Ricardo Salveti пише: > Please, avoid landing such intrusive changes at a friday next time, > specially at the friday just before the release :-) Yes, I definitely agree with that. There were some circumstances that led to this being deployed as it was, sorry. > > Since the release is right around the corner, we are ready to roll back > > as soon as someone notices a problem. > > Seems we got a few issues at the Ubuntu side: > - Failures while publishing all the image related jobs (already fixed) This was an unrelated change (a typo) from the IS side. (Caused by my request though, so my fault for doing it at this time). > - All the pre-built images are now failing as fetch image doesn't > work with current snapshots.l.o Yeah, we didn't count on the screenscraping tools (even our own). Should be solved now, if not, please let us know asap! Cheers, Danilo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Deploying new code to snapshots.linaro.org
Hi John, У нед, 26. 08 2012. у 17:15 -0600, John Rigby пише: > Probably related or same issue. On the old site I was able to > download hwpacks with for example: > > wget -q -k --no-cookies --header 'Cookie: redirectlicensephp=200' > http://oldsnapshots.linaro.org/precise/hwpacks/lt-snowball/latest/hwpack_linaro-lt-snowball_20120815-254_armhf_supported.tar.gz > > This no longer works and I get the license acceptance page instead. We have provided a script which can download stuff for you in lp:linaro-license-protection (license_protected_file_downloader inside tests/ directory - should be moved to scripts/ though). This has been present for a while now, and has been a recommended way to download binaries from snapshots.l.o. (Or, if you are doing this from a static IP, we've got support for allowing that through if it's an automated service [we do that for eg. validation.linaro.org].) We will look into providing a nicer API, but until we do, any interface we've got is going to be unstable and internal. I know Friday is not the perfect timing, but that's why we are still keeping the oldsnapshots.l.o to ensure we can quickly go back if needed. We'll make sure to avoid deployments this late in the cycle, and I hope this to be a one-off that's more of an exception than a standard. Cheers, Danilo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Utter lunacy of Linaro "license" protection Re: Deploying new code to snapshots.linaro.org
W dniu 27.08.2012 18:01, Danilo Šegan pisze: Hi John, У нед, 26. 08 2012. у 17:15 -0600, John Rigby пише: Probably related or same issue. On the old site I was able to download hwpacks with for example: wget -q -k --no-cookies --header 'Cookie: redirectlicensephp=200' http://oldsnapshots.linaro.org/precise/hwpacks/lt-snowball/latest/hwpack_linaro-lt-snowball_20120815-254_armhf_supported.tar.gz This no longer works and I get the license acceptance page instead. We have provided a script which can download stuff for you in lp:linaro-license-protection (license_protected_file_downloader inside tests/ directory - should be moved to scripts/ though). This has been present for a while now, and has been a recommended way to download binaries from snapshots.l.o. (Or, if you are doing this from a static IP, we've got support for allowing that through if it's an automated service [we do that for eg. validation.linaro.org].) We will look into providing a nicer API, but until we do, any interface we've got is going to be unstable and internal. IMHO this is utter lunacy, is there any oversight on how we do this? If we offer both the "protected", click through, EULA, downloads and the tools to download them without seeing any license then I cannot see how this is any more legally fine than just ignoring the whole damn mess. The stuff we are doing here feels like DRM but it is even more insane as we are the senders and recipients and we _still_ cannot get it right! Maybe it's time to write an RFC on the "eula compliance" bit, get a new HTTP header defined, offer a patch for wget and couple of other tools and not reinvent the download tools over and over. Frustrated ZK PS: In Linaro we _wrote_ code that generates, displays, enforces, avoids and side-steps licenses. We have scripts that send magic cookies. We have tools that click or type "I ACCEPT". I wonder how much time was wasted on this, instead of, say, writing better kernel code, or LAVA, or whatever... -- Zygmunt Krynicki Linaro Validation Team s/Validation/Android/ ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v3 06/25] docs: Xen ARM DT bindings
On 08/16/2012 10:35 AM, Stefano Stabellini wrote:
> Add a doc to describe the Xen ARM device tree bindings
>
> Signed-off-by: Stefano Stabellini
> CC: devicetree-disc...@lists.ozlabs.org
> CC: David Vrabel
> ---
> Documentation/devicetree/bindings/arm/xen.txt | 22 ++
> 1 files changed, 22 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/arm/xen.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/xen.txt
> b/Documentation/devicetree/bindings/arm/xen.txt
> new file mode 100644
> index 000..ec6d884
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/xen.txt
> @@ -0,0 +1,22 @@
> +* Xen hypervisor device tree bindings
> +
> +Xen ARM virtual platforms shall have the following properties:
> +
> +- compatible:
> + compatible = "xen,xen", "xen,xen-";
> + where is the version of the Xen ABI of the platform.
> +
> +- reg: specifies the base physical address and size of a region in
> + memory where the grant table should be mapped to, using an
> + HYPERVISOR_memory_op hypercall.
> +
> +- interrupts: the interrupt used by Xen to inject event notifications.
You should look at ePAPR 1.1 which defines hypervisor related bindings.
While it is a PPC doc, we should reuse or extend what makes sense.
See section 7.5:
https://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.1.pdf
Rob
> +
> +
> +Example:
> +
> +hypervisor {
> + compatible = "xen,xen", "xen,xen-4.3";
> + reg = <0xb000 0x2>;
> + interrupts = <1 15 0xf08>;
> +};
>
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [GIT PULL] bit-LITTLE-MP-v7
On 24 August 2012 16:39, Jon Medhurst (Tixy) wrote: > Sounds OK from my point of view, except that rather than fixed dates > each month the should probably be tied to the release dates. E.g. the > Monday of the week before release (the normal WG cut-of date), and two > weeks before (or after?) that? Hi Guys, I have updated https://wiki.linaro.org/WorkingGroups/PowerManagement/Process/bigLittleMPTree as per our last discussion. Please see if i have missed something. -- viresh ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [GIT PULL] bit-LITTLE-MP-v7
On Mon, Aug 27, 2012 at 10:07 PM, Viresh Kumar wrote: > On 24 August 2012 16:39, Jon Medhurst (Tixy) wrote: >> Sounds OK from my point of view, except that rather than fixed dates >> each month the should probably be tied to the release dates. E.g. the >> Monday of the week before release (the normal WG cut-of date), and two >> weeks before (or after?) that? > > Hi Guys, > > I have updated > > https://wiki.linaro.org/WorkingGroups/PowerManagement/Process/bigLittleMPTree > > as per our last discussion. Please see if i have missed something. > Looks good to me. Thanks. /Amit ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
