On Sat, Apr 9, 2016 at 10:57 PM, Peter Easthope wrote:
> In summary, a moving target of proprietary hardware can
> not be tracked effectively by a community of volunteers,
> enthusiastic and energetic as they are. A necessary
> condition for the communal approach is a relatively stable
> open har
On Fri, Apr 8, 2016 at 11:13 PM, Alan Corey wrote:
> Does build.prop do any good toward a device list?
Completely unrelated to the Linux kernel as far as I can tell.
> For that matter I'm not sure where a build.prop comes from, my guess
> is an output from the kernel build telling what options w
Re (2): Correction: Re: a Debian executable on Android
Yes, I was studying how to write apps but I'll be 62 in a few months
myself, I may not live that long. Not to mention I've been trying to
"repo sync" (git-based) their source tree for about 6 weeks to try to
compile under OpenBSD. I just hit
FWIIW, access to most of the Daimler car2go vehicles
here requires their app running on android or an apple device.
Primarily for that, I purchased an XO Tablet. Apparently the
fastest machine I now own. 2nd hand and under 50 US dollars.
From: Alan Corey , Sat, 9 Apr 2016 17:44:05 -0400
>
Aside from practical considerations of running under Android you're
also going to have deal with their paranoia about such things, which
is quite evolved. Every app runs as its own user in pretty much a
chroot jail with limited permissions, that sort of thing. They use
Java partly because it has
Correction: A _refinement_ of the original topic.
"... installation of debian armel or armhf or arm64 or
similar, using one of the apps, "Linux Deploy" and "Complete
Linux Installer"."
Thanks, ... Peter E.
--
123456789 123456789 123456789 123456789 123456789 123456789 12345678
On Mon, Apr 04, 2016 at 05:24:38AM +, Riku Voipio wrote:
> The reproducible-builds is armhf while the failing ones are armel. The
> regression
> appears to be a code change in haskell-http2 between 1.0.4 and 1.3.1:
>
> https://buildd.debian.org/status/logs.php?pkg=haskell-http2&arch=armel
I
I've truncated the references. They can always be traced in the index page.
From: Paul Wise
Date: Fri, 8 Apr 2016 14:01:47 +0800
> ... each device vendor had their own boot mechanisms. More recently UEFI/ACPI
> have emerged as the standard boot mechanism for ARM servers so we may
> see that on m
On Sat, Apr 09, 2016 at 12:02:44PM +0200, Graham Inggs wrote:
> On 9 April 2016 at 00:53, peter green wrote:
> > It would be useful if someone can reproduce the issue and get a dissasembly
> > of the failure location.
>
> I hope this is useful. I'll leave my screen session on abel.d.o. open
> in
On 9 April 2016 at 00:53, peter green wrote:
> It would be useful if someone can reproduce the issue and get a dissasembly
> of the failure location.
I hope this is useful. I'll leave my screen session on abel.d.o. open
in case I need to fetch more information.
[Thread debugging using libthread
LLVM 3.7.1 should have decent performance as we upstreamed various performance
patches from the Julia project. However, we still have patches on top of llvm
3.7.1 for getting acceptable performance. However, this is all on the julia
master, and not julia 0.4.
-viral
> On 08-Apr-2016, at 9:31
11 matches
Mail list logo
