and what support the device offers
to allow for those operations.
--
Neil Williams
=
neil.willi...@linaro.org
http://www.linux.codehelp.co.uk/
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-dev
ng on how the device connects to LAVA, how the device is powered
and whether the software on the device allows the device to be
controlled remotely.
So what you can change or add depends on what you are trying to do but
you should first add known devices and understand how those work before
conside
On Tue, 1 Dec 2015 17:35:10 +
Wookey wrote:
> +++ Neil Williams [2015-12-01 16:52 +]:
> > Please let us know if you are using OpenID authentication with
> > LAVA.
>
> I use OpenID whenever I get the chance as one of the few ID protocols
> where I get some cont
jango authentication modules, also
let us know.
--
Neil Williams
=
neil.willi...@linaro.org
http://www.linux.codehelp.co.uk/
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-dev
interested in or using LAVA is encouraged to subscribe to the
lava-announce mailing list which is low volume and only used for
substantial changes like this.
https://lists.linaro.org/mailman/listinfo/lava-announce
See also https://validation.linaro.org/static/docs/support.html
--
Neil Williams
> > linux-headers-amd64 package first, described as
> >
> > "Header files for Linux amd64 configuration (meta-package) This
> >package depends on the architecture-specific header files for the
> >latest Linux kernel amd64 configuration."
> >
> &g
Any team could setup a similar daily / weekly event, if one doesn't
exist already.
I'm using a wheezy chroot to get around problems with the plugin on
unstable/testing. The only problem I get is when trying to do
screenshare, my audio clips constantly.
--
Neil Williams
=
h
ubmissions which would help integrate LAVA into some of the Debian
testing strategies.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
signature.asc
Description: PGP signature
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
h
an later, an updated package elsewhere in sid/testing
is going to need the updated cairo which underpins all of GTK (Gnome,
XFCE, LXDE, Mint etc.). The better solution will be a wheezy chroot
with a browser installed and using X forwarding.
If we could see the source code for google-talkplugin, it co
top continues running with an old version of such a critical
library
The change in libcairo2 at 14-5 was:
Add gl/egl support back now that wayland has been multi-archified.
http://ftp-master.metadata.debian.org/changelogs/main/c/cairo/unstable_changelog
The change was made to fix:
h
e
existing cache values. If those do not work, try *extending* the cache
list.
> with the following aarch64.cache file contents:
>
> glib_cv_long_long_format=I64
> glib_cv_stack_grows=no
That is almost certainly too short. The cache file needs to specify all
necessar
On Sat, 2 Apr 2011 05:47:47 +0200
Guillem Jover wrote:
Adding linaro people and debian-embedded to CC:
> Hi!
>
> On Fri, 2011-04-01 at 22:31:07 +0100, Neil Williams wrote:
> > dpkg cannot be executed inside the chroot because it has not
> > necessarily been unpacked at thi
being found by a Multi-Arch
aware toolchain, that's not something dpkg-cross should be expected to
solve.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpwNYKIvgMPW.pgp
Description: PGP signature
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
On Mon, 21 Mar 2011 14:03:37 +0100
Matthias Klose wrote:
> On 21.03.2011 11:25, Neil Williams wrote:
> > The people who are most likely to be doing this now are Linaro.
> > Emdebian Crush stalled after Lenny (and used ARM not armel), so the
> > version of gcc-4.2 in Lenny sh
ulti-arch path is not needed... but I don't see why
> it should be treated differently than the cross-arch paths.
>
> Can you enlighten us?
For building a cross-compiler, Steve is correct - it doesn't matter.
For using that cross-compiler to cross-compile gcc itself, it will
ma
he-modules. So there is quite a lot of bloat, but
> probably no breakage.
Retaining the changes to the contents of the files whilst simply adding
lots more *stuff* to -cross packages is the least harmful option.
However, because the contents haven't changed, it doesn't actually he
d, leading to a dpkg-cross 3.0.0. The final list will only
include stuff which dpkg-cross can reliably identify *and* which is
absolutely essential to cross-builds. /usr/share won't be included,
except for pkg-config files.
--
Neil Williams
=
http://www.data-freedom.org/
http://ww
learly wrong for the cross build).
Either the file is in the wrong place (as in this case) or the change of
location is simply going to break without a package-specific wrapper
script anyway because the locations of things in /usr/share should not
(need to) change to support a cross-build.
- --
18 matches
Mail list logo
