On 12/01/2024 15:49, Emanuele Rocca wrote:
Hi Mathieu!
On 2024-01-12 11:33, Mathieu Malaterre wrote:
Could someone please confirm what I see on the armel/buildd:
*
https://buildd.debian.org/status/fetch.php?pkg=dcmtk&arch=armel&ver=3.6.8-2&stamp=1705054390&raw=0
Is this a 32bits/limited RAM
On 09/01/2024 23:33, gene heskett wrote:
3d printing environment relies heavily on whatever runs the rp2040. A whole industry has
grown up around the combo of the adxl345 and an rp2040 to measure resonances and tune
them out, allowing the printer to run several times faster with what is called
On 28/11/2023 17:52, Robert Wilkinson wrote:
Hello
What chance do I have of getting Debian to run on my new RPi 5 ?
Pure Debian will likely be possible in the long term, but it may take a while.
The Debian kernel team refuse to package vendor downstream kernels (ubuntu are
more flexible on th
On 15/08/2023 17:44, gene heskett wrote:
used dd to write the arm64-bookworm-12.1 netinstall image to a 64G SDXC ONN.
brand card, makes no attempt to boot plugged into a bananapi-m5. bring card
back to reader, can't mount it, wrong filesystem for both partitions. Give up,
write Armbian-jammie-
On 30/03/2023 19:59, Wookey wrote:
OK. I'll see what can be done. I see Altra servers are from
$7000-$53000 on https://store.avantek.co.uk/arm-servers.html.
What does DSA consider 'decent'? I guess we'd prefer the resilience of
a couple of reasonable machines over one ridiculously manly one. A b
On 08/12/2021 23:56, Simon McVittie wrote:
> On Wed, 08 Dec 2021 at 20:11:55 +0000, peter green wrote:
>> The default -march value on Debian armhf is "armv7-a+fp". You should
>> *NOT* use "armv7-a+vfpv3" as that specifies the version of vfpv3
>> with 32
On 08/12/2021 09:48, Simon McVittie wrote:
On Wed, 08 Dec 2021 at 09:41:29 +, Simon McVittie wrote:
At a guess, perhaps the problem is that the mozjs build system is explicitly
specifying -march=armv7-a when it should be something like
-march=armv7-a+vfpv3 or accepting the compiler's default
On 09/11/2021 19:51, Giovanni Mascellani wrote:
Dear Debian ARM people,
last boost1.74 version (1.74.0-12) fails to build on armhf[1], and I suspect
the failure is caused by the switch to GCC 11, because it didn't happen in the
version before (compiled with GCC 10).
IIRC the Debian gcc-11 pa
I think the issue may have been the linker running out of address space.
Certainly we ran into that in
raspbian.
I do have a thunderbird package in raspbian which may work for you, but I have
to build it in a slightly
hacked-up environment with the linker replaced by a cross-linker.
On 06/10/2
On 29/09/2021 23:39, Jeffrey Walton wrote:
On Wed, Sep 29, 2021 at 5:05 PM peter green wrote:
As I understand it, there are two variants of "VFPv3", a version with 32 double
registers (d0 to d31) and a version with only 16 double registers (d0 to d16).
The former is reffered to
As I understand it, there are two variants of "VFPv3", a version with 32 double
registers (d0 to d31) and a version with only 16 double registers (d0 to d16).
The former is reffered to by gcc as "vfpv3" while the latter is reffered to by gcc as
"vfpv3_d16".
Debian is supposed to support vfpv3_d
On 9/11/21 2:19 PM, Vagrant Cascadian wrote:
On 2021-09-11, Peter Ehlert wrote:
On 9/11/21 1:11 AM, Keith Bainbridge wrote:
On Tue, 7 Sep 2021 10:01:49 +0300
Andrei POPESCU wrote:
Andrei -- happy Debian user of a PINE A64+ and (still) considering
the Pinebook Pro for my next laptop
On 9/11/21 7:24 AM, Andrei POPESCU wrote:
On Sb, 11 sep 21, 04:30:21, Peter Ehlert wrote:
On 9/11/21 1:11 AM, Keith Bainbridge wrote:
On Tue, 7 Sep 2021 10:01:49 +0300
Andrei POPESCU wrote:
Kind regards,
Andrei -- happy Debian user of a PINE A64+ and (still) considering
the Pinebook Pro
On 9/11/21 1:11 AM, Keith Bainbridge wrote:
On Tue, 7 Sep 2021 10:01:49 +0300
Andrei POPESCU wrote:
Kind regards,
Andrei -- happy Debian user of a PINE A64+ and (still) considering
the Pinebook Pro for my next laptop
There's an interesting review of the Pro here:
https://www.jeremymorgan.c
On 07/09/2021 11:32, Keith Bainbridge wrote:
G'day
I've been following the recent thread Subject: Re: Debian on Pine64
H64B?
I'm looking for suggestions for a new SBC, please. Ideally something
more than 2M RAM. I see that a few a happy with Pine laptops. Does this
translate to their SBC?
Tha
On 6/10/21 7:43 AM, Uwe Kleine-König wrote:
Hello,
next week there is a (virtual) meeting at ARM who invited some people
involved in Linux on ARM CPUs. One of the topics there is to tell them
Debian's needs and pain points.
where and how can I attend that meeting?
My current list (based o
On 08/12/2020 21:02, Lennart Sorensen wrote:
> My understanding is that Debian never cross compiles
Indeed Debian always builds native, though "native"
does include running 32-bit userlands on 64-bit kernels.
> And some packages would take way to long to compile on small machines
> like a pi4 due
On 08/12/2020 16:40, Lennart Sorensen wrote:
On Tue, Dec 08, 2020 at 09:21:42AM +0100, basti wrote:
Hello Adrian,
How can I help to get bullseye on armel?
My impression was that the biggest problem for armel and armhf is the
lack of reliable build machines. Not sure if any of the 64 bit arm
On 05/12/2020 20:26, Andreas Tille wrote:
Control: tags -1 help
Hi,
I need to admit that I have no idea why this error occures on arm64.
According to reproducible builds, it's also happening on i386 and armhf,
it's showing a pass for amd64 but that could just be because it hasn't
been tested
severity 976572 normal
thanks
During a rebuild of all packages in sid, your package failed to build
on arm64 (I don't know if it also fails on amd64).
It's cool that you have expanded your rebuild tests to include arm64, but it
seems
your test workflow needs some work. arm64 is not on the arc
On 14/11/2020 14:47, Geert Stappers wrote:
Hi,
ARM64 hardware about to hit the market
Traverse Ten64 an eight-core ARM64 networking platform with mainline Linux
support
More information at https://www.crowdsupply.com/traverse-technologies/ten64
Regards
Geert Stappers
Did order one and
>
> I'll take a look, can't promise anything but I've had to deal with similar
issues
> in raspbian before.
No, my idea (treat it like a cross-build) didn't work.
On 17/09/2020 15:06, Emilio Pozuelo Monfort wrote:
On 12/09/2020 11:09, Emilio Pozuelo Monfort wrote:
This updates buster's rustc to 1.41, as needed by the new firefox 78 ESR.
The bootstrap happens with the upstream binaries as we've done in the past.
I have also avoided the bump to LLVM 9/10, w
ssw_cpp.o
cc -o ssw-align main.c kseq.h -L. -lssw -lm -lz
cc -o example_c ssw.o example.c -lm -lz
g++ -o example_cpp example.cpp ssw.o ssw_cpp.o -lm -lz
Hoping to help
Peter Ji
At 2020-08-12 15:33:31, "Andreas Tille" wrote:
>Hi,
>
>while the package libssw bu
On 16/04/2020 19:27, Wookey wrote:
Apologies for the confusion. I was rather hoping more projects would
use the obvious (and IMHO more user-friendly) arm64 name, rather than
following the corporate steer, and in the early days it was hard
to tell how this would go. But most have plumped for aarc
On 02/03/2020 19:14, Alan Corey wrote:
That poses an interesting question: can you install Debian debs on a
Raspbian system and vice versa?
In principle Raspbian is just a change of minimum CPU requirements from Debian
armhf. So provided your CPU meets the minimum requirements for both, it sho
On 03/02/2020 01:20, Paul Wise wrote:
The other problem with image-based installation methods is that there
are a ridiculous number of devices, so you have to either limit your
device support, produce a prohibitively large amount of
device-specific images, or figure out how to create one image th
On 16/01/2020 16:35, Phil Endecott wrote:
Does anyone have one of these?
https://www.solid-run.com/nxp-lx2160a-family/honeycomb-workstation/
I don't have one, but two things strike me
1. The price, £750 basically puts this at a level where you would have to be a
total arm fanatic to buy one
my first suspicions when a debugger can't give a useful backtrace are stack
corruption or a call down a bogus function pointer.
Unfortunately such problems can be a nightmare to debug, I have often resorted to
debugging with printf statements in the past. Recently "reverse debugging"
tools hav
Hi
A couple of months ago the default d compiler on armhf was changed from ldc to gdc, the
changelog entry was simply "Update list of default compilers forsupported
architectures (Closes: #939375)" and bug 939375 makes no mention of armhf.
Unfortunately a number of packages have failed to make
links to the version in Debian
> buster which someone reported as broken a few weeks ago.
> I will point to the version in Debian stretch. Sorry about that.
As another data point, u-boot 2018.07 works here:
https://git.buildroot.net/buildroot/tree/configs/sheevaplug_defconfig#n22
--
Bye, Peter Korsgaard
On 07/05/19 07:06, Andrei POPESCU wrote:
On Ma, 07 mai 19, 00:33:19, peter green wrote:
On 04/05/19 18:49, Andrei POPESCU wrote:
https://wiki.debian.org/InstallingDebianOn/PINE64/PINEA64
This prompted me to reinstall my pine64 which has been sitting idle
for a while, since the old install
On 04/05/19 18:49, Andrei POPESCU wrote:
On Sb, 04 mai 19, 06:57:43, Andrei POPESCU wrote:
I'm ready to start a second try where I will be using manual
partitioning (without GPT), hoping I will get a bootable system.
This worked, see
https://wiki.debian.org/InstallingDebianOn/PINE64/PINEA64
Th
I got a report from a user about "openssl sha1 " not working for
large files on raspbian stretch.
I investigated the problem and found that when I tried to use "openssl sha1 " for
a large (>2GB) file on Debian armhf stretch or raspbian stretch I get|an error "Value too large for
defined data t
On 06/01/19 23:45, Steve McIntyre wrote:
In my initial testing for rebuilding armhf only, I did not enable
either of these. I was then finding *lots* of "Illegal Instruction"
crashes due to CP15 barrier usage in armhf Haskell and Mono
programs. This suggests that the baseline arch
On 22/12/18 11:33, wf...@niif.hu wrote:
Dear ARM porters,
I sponsored the 4.5.0.8-1 upload of the coturn package. It's unit test
failed with bus error on armhf and sparc64:
https://buildd.debian.org/status/package.php?p=coturn
The former being a release architecture, I started investigation wit
On 30/11/18 23:23, Daniel Kahn Gillmor wrote:
entry=entry@entry=0xf051c962
Well that looks to be your problem, an unaligned pointer. You need to figure
out where it is coming from and fix it.
I recently went to upgrade one of my wandboard quads from 4.9.0-0.bpo.1-armmp
to 4.18.0-0.bpo.1-armmp
Unfortunately the new kernel doesn't seem to boot, it seems to hang after "starting
kernel". Any ideas on what the problem could be?
My u-boot environment looks like
=> mmc dev ${mmcdev}
mmc0
On 17/10/18 16:49, ibu ☉ radempa wrote:
What I find confusing: The changelogs of firefox-esr for stable and
unstable essentially contain the same items (since v52), but the one
reproducibly crashes, and the other reproducibly works. Given that I've
tried them in the same environment (versions of
On 23/09/18 15:20, LinAdmin wrote:
The above archive site is broken:
"The last update was on 09:00 GMT Fri Sep 21." which is more
than 2 days ago while it should regularly updated ...
I could be wrong but I think it's only updated if/when new mails arrive.
It has recently been discovered in raspbian (
https://bugs.launchpad.net/raspbian/+bug/1793415 ) that udev doesn't start if
built with gcc 8 due to what appears to be a hardening related failure. As a
result I have just forced the systemd source package (which builds udev) in
raspbian to build
On 18/08/18 11:01, Roger Shimizu wrote:
On Sat, Aug 18, 2018 at 12:33 PM, Hideki Yamane wrote:
Hi,
So it'll be super great if you (or your boss) can kindly sponsor some
armel/armhf hardwares that support to install 4GB memory.
From DebConf18 seesion "Building a Debian Derivative: Lessons L
On 24/06/18 14:44, Alan Corey wrote:
Yeah, texlive is like 1 GB. I used it once about 10 years ago but I have it on
every Debian or Raspbian machine. I wish there was more flexibility in
dependencies somehow.
The large size is caused by a couple of factors.
1. Debian bundles together tex pac
On 20/04/18 13:33, Alan Corey wrote:
Well yes, all of that's true, but would raspberrypi.org mind if Debian
borrowed a copy of their scripts?
It's MIT licensed so it should be fine to borrow
https://github.com/RPi-Distro/raspi-config/LICENSE
raspi-config isn't 3b specific
Indeed, it's design
It seems that gcc-8 unconditionally builds parts of libatomic with
"-march=armv7-a+fp". This was detected by Raspbian's armv7 contamination
checker before the package was uploaded to raspbian. There is no such checking for Debian
armel so the package was accepted there and is now being shipped
On 09/11/17 06:22, Gene Heskett wrote:
On Thursday 09 November 2017 00:54:52 Paul Wise wrote:
On Fri, Nov 3, 2017 at 8:54 PM, Gene Heskett wrote:
I did an update on an armhf/jessie install last night, and noticed
that all the files for translations were missing, which resulted in
quite a bit o
lems caused by missing
locales, so this fix most probably is cosmetic only.
With kind regards
Stefan Peter
On 23/09/17 19:42, Uwe Kleine-König wrote:
On Sat, Sep 23, 2017 at 02:08:28AM +0100, Steve McIntyre wrote:
On Fri, Sep 22, 2017 at 09:57:02PM +0200, Uwe Kleine-König wrote:
Hello,
for the package sparse I have to distinguish armel and armhf. The reason
is that sparse parses system headers and
Package: ceph
Version: 10.2.5-5
Severity: serious
x-debbugs-cc: debian-arm@lists.debian.org
The most recent upload of ceph fixed the build on most architectures but
unfortunately armel is still failing.
libtool: relink: g++ -fPIC -DPIC -shared -nostdlib
/usr/lib/gcc/arm-linux-gnueabi/6/../../
On 26/12/16 21:52, Gaudenz Steinlin wrote:
AFAICS the build failure appears if a source file uses
"#include".
AFAIU the build tries to build a plugin with NEON instructions to be
used depending on runtime detection.
You need to add "-mfloat-abi=softfp" to the compilation of the
neon-using p
On 20/12/16 12:50, Gunnar Wolf wrote:
I have a CuBox-i 4 (not 4x4). It's currently in stable use, and have
not fiddled with it for long (and right now, it sits 7000Km away from
me), but if I recall correctly, any USB media needed for the boot
process (i.e. a keyboard) has to be inserted in the l
On 13/12/16 21:42, peter green wrote:
I would guess at this point either a race condition or a power glitch
(maybe powering the HDD off one of the USB ports wasn't such a good
idea).
OK, I found that adding ahci-imx.hotplug=1 to the kernel command line
made it work.
Checkin
On 13/12/16 19:59, peter green wrote:
I have just bought a cubox i4x4 and installed Debian Jessie on it
using D-I (concatenatable netboot). I am using a SD card for the
rootfs and plan to use a hard drive to store chroots.
Unfortunately while I can see the hard drive in D-I I can't s
I have just bought a cubox i4x4 and installed Debian Jessie on it using
D-I (concatenatable netboot). I am using a SD card for the rootfs and
plan to use a hard drive to store chroots.
Unfortunately while I can see the hard drive in D-I I can't see it after
installing. The ahci_imx module seem
On 13/12/16 07:37, Andreas Tille wrote:
Hi,
when discussing bug #800469 upstream thinks that armhf should work and
the question came up whether there is some chance to access an armhf
machine that is comparable to our autobuilders.
The porterbox abel.debian.org runs the same hardware as the
On 03/12/16 15:53, Victor Hooi wrote:
Hi,
I'm looking at buying a cheap 2-bay NAS to install Debian onto.
The QNAP TS-21X units are quite good, but are a little dated.
armel's days as a full Debian port appear to be coming to an end (it
looks like stretch will be the last release). There is t
On 12/10/16 18:57, Wookey wrote:
That seems quite likely. It might just be the senstivity of C++
symbols to compiler changes. Unfortunately so far as I know one can't
test such a thing on the porter boxes (because there is no way to
unstall the local gdal you just built due to lack of root rights
On 17/08/16 17:06, Leif Lindholm wrote:
Indeed. And we need to stay on the ball with that, and try to ensure
any changes we do from this point onwards are at least 56-bit
safe. And start agitating against pointer tagging in general.
AIUI a big problem is that some systems (in particular jav
On 17/08/16 10:19, Adam Wysocki wrote:
Is it possible for a compiler to generate BX instructions without Thumb
code (for example to return from a function with bx lr, where lr will
always be even - no Thumb)?
Correct me if I'm wrong, but I thought that BX patch (to emulate BX
instruction in ker
On 17 August 2016 at 17:06, Leif Lindholm wrote:
> And start agitating against pointer tagging in general.
Why would you want to do that when the architecture has
specific support for it?
thanks
-- PMM
gt; pacrunner
> plowshare
> polkit
> cinnamon
> cjs
> cjs
> cjs-tests
> gjs
> gjs
> gjs-tests
> gnome-shell
> 0ad
> mongodb
> mongodb-server
>
> Some of these may only need an updated luajit/mozjs package, but some
> may need more invasive changes.
Actually that list doesn't include any luajit based packages in Fedora
because there's not, upstreamed at least, support for aarch64 in
luajit as yet.
Peter
On 28/07/16 17:35, Gunnar Wolf wrote:
I'm far from an absolute expert in this area... But I am fairly
certain of what I say — That is, I have a RPi 1 and 2B, and they
cannot boot from the same images.
That depends what is in the image.
The current raspberry pi firmware works on all pi model
On 22/07/16 02:36, Steve McIntyre wrote:
Affordable, usable machines are available now, e.g. the Cello
Does anyone know what is going on with this. Have boards actually
started shipping?
While upgrading a wandboard quad from 4.4 to 4.6 (debian armmp kernels)
I got a boot failure. I tracked this down to the device name for the SD
card changing from mmcblk0 to mmcblk2
Any idea why this has changed? There don't seem to be any other
lower-numbered mmcblk devices.
On 09/06/16 18:55, Steve McIntyre wrote:
Hi folks,
I'm one of the ARM porters, and I've recently run a scan of binaries
in the archive to check on the state of the binaries for armel and
armhf. As part of the ARM ABI, binaries (libraries and programs) are
expected to specify ELF flags to specify
On 13/06/16 14:49, Phil Endecott wrote:
Dear All,
I was surprised to find that "apt-get install kexec-tools"
succeeds on an arm64 system - it installs the armhf version.
It then fails to run, with an "Unsupported machine type"
error.
Is this an error in the multiarch tagging for the kexec-tools
On 07/06/16 19:38, Martin Michlmayr wrote:
* Steve McIntyre [2016-06-06 15:14]:
However, I will admit (again) that armel is starting to lose upstream
support in some cases. I'm tempted to suggest that Stretch should be
the last release for armel for that reason.
Which upstream proble
On 05/06/16 23:01, Wookey wrote:
Ok, so a total of 6 shared between the two architectures?
Thats what it looks like to me.
And I think we are building armhf on the arm64 build machines too?
I don't think so. At least I see no evidence of it on buildd.debian.org .
On 05/06/16 11:01, Niels Thykier wrote:
all arm ports have DSA concerns.
Is there a current reference to what these concerns are? Is there still
a lack of out of band management? (the old mail I found on the topic
said it was "being worked on", sledge whats the status here?) are there
othe
On 05/06/16 13:00, Holger Levsen wrote:
On Sun, Jun 05, 2016 at 01:26:39PM +0200, John Paul Adrian Glaubitz wrote:
ppc64:
This architecture is basically on par with the release architectures. We have
over
11.000 packages installed
[...]
sparc64:
We are close to 11.000 installed
On 19/05/16 18:35, Vagrant Cascadian wrote:
Firefly-4GB:
price: ~US$260
kernel: 4.6.x in experimental (4.4.x worked fine, but 4.5.x broke
ethernet).
cpu: quad-core cortex-a12?/a17? (Rockchip rk3288)
ram: 4GB
disk: USB2
u-boot: patched u-boot 2016.01 to recognize 4GB of ram
On 19/05/16 17:25, Phil Endecott wrote:
peter green p10link.net> writes:
As much ram as possible.
Plenty of CPU power would be nice.
A good storage interface (in order of preference SATA is better than
USB3 which is better than USB2).
Support in Debian kernels would be nice.
arm64 supp
On 18/05/16 04:50, Tim Northover wrote:
If you don't need/want the various Sanitizer runtimes (e.g. you don't
support sanitizers or already have versions provided with GCC) then
it's as easy as not downloading compiler-rt or removing it from the
projects/ directory before running CMake. The build
I'm looking for an arm board/box to add to my collection of buildboxes.
Critera (in roughly descending order of importance):
Reasonablly affordable (upper limit ~£200)
As much ram as possible.
Plenty of CPU power would be nice.
A good storage interface (in order of preference SATA is better than
On 19/05/16 01:06, Steve McIntyre wrote:
Yes, there is - #822489 in ldconfig. It's fixed already and that fix
should be migrating into testing any day.
According to the pts it's blocked by a "block-udeb"
On 17/05/16 22:38, Tim Northover wrote:
Compiler-rt is the equivalent of libgcc, and Clang can use the
existing host's libgcc quite happily so it's really not that important
unless you're trying to build a GNU-free environment for whatever
reason.
Thanks
Can you tell me how I would go about
On 17/05/16 18:07, Tim Northover wrote:
Yes, it looks like we'd need to conditionally compile these functions
in ARM mode and use the v6 barrier instead of dmb ("mcr p15, #0, r0,
c7, c10, #5" I believe) to support the ARM1176JZF-S in RPi. You'd
probably also want the build system to use an explic
llvm-toolchain-3.8 seems to have problems on debian armel and raspbian.
On raspbian it builds but our armv7 contamination checker blocked it
from entering the repo. Further investigation showed that "compiler-rt"
was being built with -march=armv7 . I was able to remove the -march with
some bui
On 14/05/16 23:13, Alan Corey wrote:
On 5/14/16, Wookey wrote:
I consider the stable/testing choice/tradeoffs to be exactly the same for
arm and x86.
So it depends what you are using the box for.
I think it's worth bearing in mind the size of the userbase here,
something in arm prob
On 06/05/16 20:59, Phil Endecott wrote:
It interests me to speculate as to why, at both a technical and an
organisational level, these people are doing their own things, rather
than making "real" Debian work on this board. Are any of the
people involved in this even reading this list?
To get
along with the panic occurs after a pause of two seconds.
Regards,
Peter
Dear Debian ARM porters,
Are any of you running an armv7 board similar to the Cubieboard or
Cubietruck by chance, who happen to see a kernel panic on poweroff
using Debian testing/unstable with Linux kernel 4.2 up to 4.5?
https://bugs.debian.org/818951
Regards,
Peter
> by a given (commercial) CDN?
Fastly and MaxCDN aren't asking for donations to keep Debian running.
They are the sponsors here.
--
| .''`. ** Debian **
Peter Palfrader | : :' : The universal
https://w
On 23/04/16 13:41, Raphael Hertzog wrote:
Hi,
On Fri, 22 Apr 2016, Tollef Fog Heen wrote:
I am not speaking on behalf of DSA here.
Thanks for making this clear. I also want to explain why I included DSA
in the discussion: I wanted to make sure that the fact that we run wheezy
armel/a
opped in commit 17796f1.
Regards,
Peter
aimler to offer a purely HTML5 app and content myself with
android until the picture improves.
By the way, the Spark Modular Tablet is appealing although too large for
my purposes. http://www.instructables.com/id/Spark-The-DIY-Modular-Tablet/
Thanks,... Peter E.
--
123456789 12345678
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
carrier contract" problem.
No thoughts about the original topic? More specifically,
"... installation of debian armel or armhf or arm64 or
similar, using one of the apps, "Linux Deploy" and "Complete
Linux Installer"."
Regards, ... Pete
On 08/04/16 20:55, Graham Inggs wrote:
Secondly, it should be possible to reproduce the fault by building in
an armhf schroot on abel.d.o, which has the same hardware as the
buildds. A temporary solution would be to upload armhf binaries built
on asachi.d.o.
It would be useful if someone ca
e regressions with Julia on
> LLVM > 3.3 that were only fixed in 3.8.
The reason for switching to LLVM 3.8 was the abysmal performance
of LLVM 3.7 on i386, and complete failure of LLVM 3.6 or earlier.
https://github.com/JuliaLang/julia/issues/14191
Peter
l or armhf
or arm64 or similar, using using one of the apps, "Linux Deploy"
and "Complete Linux Installer".
Inadvisable? Feasible?
Thanks, ... Peter E.
--
123456789 123456789 123456789 123456789 123456789 123456789 123456789 12
Tel +1 360 639 0202
,... Peter E.
--
123456789 123456789 123456789 123456789 123456789 123456789 123456789 12
Tel +1 360 639 0202
http://easthope.ca/Peter.html Bcc: peter at easthope. ca
On 06/03/16 16:34, Vagrant Cascadian wrote:
I got the impression it was another broadcom chip, maybe with a
cortex-a53? Gotta love ARM's confusing namespace.
It is indeed a broadcom chip. It's like the Pi2 but with a quad cortex
A53 complex instead of the quad cortex A7 complex and with a
s
onding bug report is now available here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815786
Thanks again for all your comments.
Peter
On 23.02.2016 15:29, Alan Corey wrote:
Right, the OpenBSD version at the time (15 years ago) I think was
raidframe and they called it a serial number, it does
the new hostname.
If I would change the hostname of the ARRAY in mdadm.conf I should also
change the hostname within the superblocks.
However, I have no idea how to change the homehost settings in the
superblock ...
Peter
On 22.02.2016 11:43, Alan Corey wrote:
Ah:
"In a nutshell: Your
Since the RAID-device contains the / directory I can not just stop and
re-assamble the RAID-device with a new name.
How can I change the name of the RAID-device?
Peter
name.
Since the RAID-device contains the / directory I can not just stop and
re-assamble the RAID-device with a new name.
How can I change the name of the RAID-device?
Peter
smime.p7s
Description: S/MIME Cryptographic Signature
On 15/02/16 13:36, Yaroslav Halchenko wrote:
Sorry about delay... quite often those Bus errors just go away on their
own since aren't anything to be fixed in pandas, but this time it still
persists with 0.17.1:
https://buildd.debian.org/status/fetch.php?pkg=pandas&arch=armhf&ver=0.17.1-3&stamp=1
On one of the wandboard quads I use as an autobuilder for raspbian a
btrfs filesystem got into a state where mount hung. After some googling
the reccomended fix was a kernel upgrade so I upgraded to the kernel
from sid.
Linux bm-wb-01 4.3.0-1-armmp #1 SMP Debian 4.3.3-7 (2016-01-19) armv7l
GN
On 28/11/15 13:06, Mikhail Kotelnikov wrote:
Hi.
I have Netgear ReadyNAS with OS based on Debian armel arch. When I try
to update it to current version of squeeze all mirrors miss some deb
packages.
My sources.list:
=== cut ===
deb http://ftp.debian.org/debian/ squeeze main contrib non-free
de
1 - 100 of 681 matches
Mail list logo
