Re: What to do with d-i on armel?

[Peter Green]

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 
"input shaping"  The actual device is about the size of a postage stamp on a 
teeny pcb. I do not know which version of linux it is that the rp2040 is actually 
running. For us, its one of those things that Just Works.


The rp2040 does not run linux.

Re: Raspberry Pi 5

[peter green]

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 this). So the first thing that needs to happen is adequate
support for the Pi 5 in upstream kernels. Some searches turned up that there
does seem to be some raspberry pi 5 related activity on the upstream kernel
mailing lists (e.g. https://www.spinics.net/lists/kernel/msg4986331.html )

Once there is adequate support in upstream kernels, then the Debian packaging
can be updated to support it.

In the meantime it's almost certainly possible to run a pure Debian userland
with a kernel from Raspberry pi.

Re: Just tried arm64 netinstall on a bananai-m5

[peter green]

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-full-desktop iso to card, mounts ok, boots bananapi-m5 
normally.

What did I do wrong?


The unfortunate reality is that boot on arm is *still* a mess. The server guys 
and the windows laptop guys
have settled on uefi (though the implementations are often far from perfect), 
but the hobbyist board segment
is still all over the place, with each board (or family of closely related 
boards) still needing it's own build
of u-boot that knows how to initialise the board, load a kernel and initrd and 
pass them the relavent device
tree.

For some boards, Debian offers "concatenatable images", where a board-specific 
boot section can be concatenated
with a board-independent d-i section to produce a boot image suitable for a 
specific board, yours doesn't seem
to be one of them though.

.

Re: buildd reliability

[peter green]

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 bit
of configury on the Aventek site suggests that basic ARM Altra servers
cost about twice as much as AMD ones for similar specs
(cores/RAM/disk), but then the power consumption is less than half. I
don't know how the performance actually compares for buildd purposes
(nor what sort of spec we prefer in terms of
nodes/cores/RAM/Disk/networkIF), but people describe the Altra's as
'fast'. I'll try and collect some more details to quantify that.


I'm not DSA, but the problem i've found when looking at such hardware
has always been that the "cost of entry" is so high. To me $7K is a
lot of money to put down "on spec".



It may well be worth approaching them to see if they would sponsor
some hardware, or at least provide a steep discount from list prices.
Debian is after-all one of the top Linux distros (and probablly the
top "community" distro).

Also can anyone confirm if these machines support arm32? or if they
are arm64 only?

Re: Bug#1001314: mozjs78: FTBFS on armhf: '-mfloat-abi=hard': selected architecture lacks an FPU

[peter green]

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 double precision registers which is above the Debian baseline.
>
> 
https://github.com/alexcrichton/cc-rs/commit/b2f6b146b75299c444e05bbde50d03705c7c4b6e
> (which I have now applied to the copy of cc-rs in mozjs78) uses
> "-march=armv7-a -mfpu=vfpv3-d16", which seems like a plausible encoding of
> the minimum spec given in https://wiki.debian.org/ArmHardFloatPort and
> https://wiki.debian.org/ArchitectureSpecificsMemo#Architecture_baselines
> (ARMv7 with Thumb-2 and VFPv3-D16).
Yes that is fine.

>
> If I understand correctly, VFPv3-D16 refers to the version of vfpv3 with
> only 16 registers, which is exactly what our armhf baseline guarantees
> (and as you point out, some ARM CPUs with VFPv3 have more registers, but we
> require our binaries to assume those extra registers are not available).
> Am I getting this right?
Yes.

Re: Bug#1001314: mozjs78: FTBFS on armhf: '-mfloat-abi=hard': selected architecture lacks an FPU

[peter green]

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?


Looks like this might be the same issue fixed by
https://github.com/alexcrichton/cc-rs/commit/b2f6b146b75299c444e05bbde50d03705c7c4b6e


Certainly looks like it to me.

The Debian gcc packages changed how they specify floating point options,
they now use "-march" to set both the CPU and FPU rather than using
seperate "-march" and "-mfpu" options.

The result of this change is if you manually set "-march" then it
overrides the built-in defaults for both the CPU and FPU rather than
only overriding the CPU. If your new "-march" setting doesn't specify
a FPU and you don't set a seperate "-mpfpu" option then you end up
with an invalid configuration (hard float ABI selected but no FPU
selected).

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 double precision registers which is above the Debian baseline.

https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html

Re: Help with boost1.74

[peter green]

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 package takes a different approach to specifying default 
cpu/fpu,
specifying -march=armv7-a+fp rather than seperate march and mfpu options, I 
wonder if
this is having an influence somehow.

Re: W: armhf version for thunderbird bullseye

[peter green]

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/2021 16:06, John Paul Adrian Glaubitz wrote:

Hello!

On 10/6/21 16:38, Tuxo wrote:

Is there a thunderbird version for armhf in one of the debian repositories?

checking [1] and [2] they mention armhf versions of tb 78 for Buster and 
Stretch, none for Bullseye so far.


Carsten Schoenert has disabled the 32-bit ARM builds of Thunderbird, see [1].

I have no clue why that happened as there is no mention of that change in 
debian/changelog,
but I assume it's because Mozilla upstream broke support on these targets.

It's unfortunately a big of cat and mouse with fixing all these regular 
regressions on
architectures that Mozilla doesn't care about. We would need more people 
working on
these.

Adrian


[1] https://buildd.debian.org/status/package.php?p=thunderbird=sid

Re: armhf SIGILL, Illegal Instruction

[peter green]

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 by gcc as "vfpv3" while the latter is reffered to by gcc as 
"vfpv3_d16".

Debian is supposed to support vfpv3_d16 but because there is relatively little 
hardware out there that doesn't support the extra registers bugs may take a 
while
to get noticed.

So IMO this is a bug in the compiler that is generating that code. What i'm not 
so sure about is whether selecting the correct compilation settings is the
responsibility of the frontend (ldc) or the backend (llvm).


Shouldn't that show up in the build logs? 


It will only show up in build logs if the build process is overriding the 
built-in defaults of the compiler.

Normal practice in Debian is that when invoked without specific architecture 
flags compilers should generate
code that will run on the baseline CPU of the port. If they don't then that is 
a bug in the compiler.

Re: armhf SIGILL, Illegal Instruction

[peter green]

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_d16 but because there is relatively little 
hardware out there that doesn't support the extra registers bugs may take a 
while
to get noticed.

So IMO this is a bug in the compiler that is generating that code. What i'm not 
so sure about is whether selecting the correct compilation settings is the
responsibility of the frontend (ldc) or the backend (llvm).

On 29/09/2021 21:06, Ash Hughes wrote:

Hi,

I've been getting some programs terminated with SIGILL today, and I'm trying to 
find out if this is a package issue or if Debian (Bullseye) is no longer 
compatible with my ARM machine. I first got an error with onedrive, with gdb 
output:

#0  0xb6948ca8 in gc.impl.conservative.gc.Gcx.fullcollect(bool) ()
    from /usr/lib/arm-linux-gnueabihf/libdruntime-ldc-shared.so.94

which is "vldr    d18, [pc, #216] ;".

I then tried to run ldc2, and I got something similar:

Core was generated by `ldc2 -c --output-o -conf= -w -mattr=-neon -O3 -release 
-relocation-model=pic -d'.
Program terminated with signal SIGILL, Illegal instruction.
#0  0x0089e15c in 
dmd.parse.Parser!(dmd.astcodegen.ASTCodegen).Parser.parsePrimaryExp() ()

which is also a vldr instruction ("vldr    d16, [r6, #80]  ; 0x50")

Finally, I tried to compile ldc2 myself and running it I got:

#0  0xb4a6eabc in ?? () from /usr/lib/arm-linux-gnueabihf/libLLVM-11.so.1

also vldr ("vldr    d16, [sp, #8]")

It looks like the vldr instruction is being used in several LLVM packages, in a 
way my CPU doesn't like. Here's my cpuinfo:

processor   : 0
model name  : ARMv7 Processor rev 1 (v7l)
BogoMIPS    : 37.39
Features    : half thumb fastmult vfp edsp thumbee vfpv3 vfpv3d16 tls idivt
CPU implementer : 0x56
CPU architecture: 7
CPU variant : 0x1
CPU part    : 0x581
CPU revision    : 1

Hardware    : Marvell Armada 370/XP (Device Tree)
Revision    : 
Serial  : 

I don't have neon, although I think armhf doesn't require it, unless this has 
changed for Bullseye? If neon isn't required for Debian armhf, does this mean 
some LLVM related packages could be built differently to improve compatibility?

Thanks,

Ash

Re: Replacement for raspPi

[peter green]

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?

Thanks

Background.
I've just set up a new SDCard with raspberryOS. Set myself up as a
user, and set root passsword. When I sshfs to my laptop, the mount
point AND all subdirectories are owned exclusively buy user pi.  Not
even root has access. 

So you had a problem with sshfs permissions, rather than investigate
said problem (e.g. 
https://unix.stackexchange.com/questions/59685/sshfs-mount-sudo-gets-permission-denied
 )
you chose to blame the Raspberry Pi.

Re: Porter roll call for Debian Bullseye

[peter green]

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 to not enough ram.
Pi4s are now available with 8GB of ram, not as much as the "server"
hardware granted, but enough to pretty much max out the address space
for two 32-bit processes at the same time.

>  And for build machines, you want rack
> mountable machines
You can rackmount damn near anything if you put a bit of effort in.

> with remote management.  Not something that doesn't
> even have a power switch or ability to be restarted remotely if needed.
A Pi4 can be set up with a serial console and netboot and turns on
when the power is applied (no need to press any buttons). Contrast
this to the asus arm64 server board I have access to, which according to
the hoster needs to be poked over IPMI after a power cycle before it
will turn back on and which sometimes fails to come back after a soft
reboot.

In terms of power cycling, what Mythic Beasts do for their hosted Pis
is to use a POE hat, then turn on and off the port power on the
network switch. They don't have HDDs/SSDs attached though, which you
would want for a buildbox, and i'm not sure if the PoE hat as the
current capability to reliably run a Pi4+HDD.

Re: Porter roll call for Debian Bullseye

[peter green]

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
servers are suitable for building armel or armhf or if they lack certain
required instructions.


Debian has been building armel and armhf on arm64 "server" hardware for
some time. There have been some issues relating to building on 64-bit
kernels (mostly that the 64-bit kernels default to trapping alignment
errors rather than fixing them up), but nothing earth-shatteringly bad.

You do of course have to make sure you get a machine that actually has
32-bit support, some of the arm server hardware doesn't.

Re: Bug#976567: libhmsbeagle: FTBFS: GPUInterface.h:221:27: error: there are no arguments to ‘malloc’ that depend on a template parameter, so a declaration of ‘malloc’ must be available [-fpermissive]

[peter green]

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 for a while (I've just hit the re-test button)



Any hint would be welcome


Looks like you need to add #include  to 
libhmsbeagle/GPU/GPUInterface.h
I would guess stdlib.h was previously pulled in implicitly by some other header 
and
no longer is.

re: bio-eagle: FTBFS: MemoryUtils.hpp:34:10: fatal error: xmmintrin.h: No such file or directory

[peter green]

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 architecture list for 
bio-eagle,
even if it was, the normal practice in Debian is only to consider a FTBFS bug rc
if the package has built on the architecture in the past.

I have downgraded the bug, I will leave the decision on whether to close it or 
not
up to the maintainer.

Re: eight-core ARM64 networking platform with mainline Linux support

[peter green]

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 would like to known about simular products



The clearfog/honeycomb from solidrun springs to mind.

Re: Bug#970132: buster-pu: package rustc/1.41.1+dfsg1-1~deb10u1

[peter green]

>
> 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.

Re: Bug#970132: buster-pu: package rustc/1.41.1+dfsg1-1~deb10u1

[peter green]

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, we use buster's LLVM 7 instead.


The updated rustc is in buster-proposed-updates now, but it failed to build for
armel. Looks like my change to debian/architecture.mk to use
arm-unknown-linux-gnueabi rather than armv5te-unknown-linux-gnueabi broke this a
bit. The reason for that change was that there were no armv5te binaries
upstream, and the arm ones are ARMv5 so should be good to bootstrap rustc on
armel. However, rustc now defaults to ARMv6 for arm-unknown-linux-gnueabi (see
vendor/cc/src/lib.rs), which could be causing some issues. Or perhaps the issue
lies elsewhere.

Anyway my attempts at getting rustc 1.41 bootstrapped on armel have failed so
far (I have tried to lower that -march to armv5te, and also attempted to build
for armv5te-unknown-linux-gnueabi while using the arm-unknown-linux-gnueabi
binaries). Any help from the armel porters would be appreciated.


I'll take a look, can't promise anything but I've had to deal with similar 
issues
in raspbian before.

Re: The state of Arm64 on Raspberry Pi (and its Documentation

[peter green]

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 aarch64, so users
are exposed to both names.


I think Debian made the right decision in using "arm64", IMO
the clarity for end-users (who aren't likely to have a clue what
"aarch" is but will probablly have heard of arm) outweighs
the inconsistency between Debian and projects that decided
to do what arm corporate wanted.

Interestingly andriod seems to use arm64 for the "abi"* and
aarch64 for the "instruction set"

* I am not an andriod expert, but an andiod "abi" seems to be
roughly equivilent to a Debian architecture.

Re: Raspberry Pi

[peter green]

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 should 
be possible to mix raspbian packages with debian armhf packages. This is 
in-fact how raspbian was initially bootstrapped and I still use it on occasion 
as a method to rebootstrap stuff. I can't rule out the possibility though that 
some libraries will change ABIs as a result of the change in minimum CPU 
requirements, so there is some risk in such mixing.

There is also the possibility of multiarching raspbian with another port of 
Debian. Unfortunately due to the design of multiarch it is necessary to build 
some extra packages for the architecture you are multiarching with to make this 
work, I built such packages for arm64 for buster, see 
https://www.raspberrypi.org/forums/viewtopic.php?t=254027

Re: Armbian

[peter green]

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 that
works on all devices (which won't be possible due to bootloader
diversity on ARM),


D-I "solved" this problem by creating "concatenatable images", so you have a 
small stub image that is board-specific and contains the partition table and first stage 
bootloader, which you concatenate to the main board-independent image. I don't see any reason why 
you couldn't do the same for pre-installed images.

Re: SolidRun HoneyComb LX2K

[peter green]

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 as a general desktop/server machine (buying one 
for an arm buildbox may be justifiable to some, so might buying one as a 
networking role).
2. Support for upstream stuff still seems to be "work in progress", combined 
with the above high price I would consider the risk of orphaning to be non-negligible.


Mini-ITX
16 x Coretex-A72 @ 2 GHz (NXP)
2 x SoDIMM RAM slots
1 x M.2 SSD
1 x PCIe x8 slot
1 x Gigabit ethernet
4 x SFP+ ports
4 x SATA
etc. etc.

Re: help with racket build failure

[peter green]

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 have appeared that in principle should be able to help with this sort of thing, but 
I haven't found any free ones for arm linux.

On 13/01/2020 11:36, David Bremner wrote:

Dear Arm experts;

Any help with

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948789

would be appreciated.

I can replicate the crash on harris, and

cd $HOME/racket-7.5+dfsg1/build  && \
gdb --args ./racketcgc -cu \
$HOME/racket-7.5+dfsg1/src/racket/src/compile-startup.rkt cstartup.inc \
cstartup.zo $HOME/racket-7.5+dfsg1/src/racket/src/startup.inc \
$HOME/racket-7.5+dfsg1/src/racket/src/schvers.h

should get you to the segfault in gdb. The backtrace doesn't make much
sense to me, lots of talk about

   

It's entirely possible racket is doing something odd with signals; I
remember something like using SEGFAULTS in gc.

d

state of d on armhf.

[Peter Green]

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 the transition.

appstream-generator: "Error /usr/share/gir-1.0/GObject-2.0.gir(48): Unexpected tag: 
function-macro in GirPackage: gobject" 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942379

diet-ng: "gdc: error: unrecognized command line option ‘-main’; did you mean 
‘-Wmain’?" no bug currently

glib-d: duplicate symbols, no bug currently.

gtk-d: duplicate symbols 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942607

lix: explicitly depends on ldc rather than using the default d compiler, 
doesn't seem to depend on any d libs, so this may not actually be a problem 
per-se.

onedrive: explicitly depends on ldc rather than using the default d compiler, 
doesn't seem to depend on any d libs, so this may not actually be a problem 
per-se.

tilix: blocked by gtk-d

This leaves me with two questions.

1. Why was the default D compiler on armhf changed?

2. Where do we go from here to restore things to a sane state? (i.e. a state 
where all d packages in testing can be succesfully rebuilt in testing)


Note: I am the maintainer of a derivative and an arm porter, but I don't have 
any particular knowledge or interest in d.

Re: Debian Installer on Pine64+ (no serial console)

[peter green]

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 (based on a vendor image) on it
stopped booting. Your instructions worked fine and after installation
the system sucessfully rebooted to a login prompt.

Great :)
  

At that point I got distracted, when I came back a day or so later I
found that the Ethernet interface had stopped working. It appeared to
be up and had an IP address (meaning it must have passed some packets
since the reboot), but no traffic was getting through. Downing and
re-upping the interface brought it back to life. I also rebooted the
system and found the network interface had come up successfully after
the reboot.

Then I ran into another problem. I have a SATA hard disk connected by
a startech USB to SATA/IDE adapter (I belive its
https://www.startech.com/uk/HDD/Adapters/USB-20-to-IDE-or-SATA-Adapter-Cable~USB2SATAIDE
though I'm not using the PSU that came with it). When I tried to rsync
a large file (an image of the pre-reinstall SD card contents) to said
drive it dropped out. I unmounted and re-mounted the drive (which had
renamed itself from sda to sdb after the dropout) and tried again, but
the same happened again.

As usual with this kind of devices, do make sure you have a good power
source (for the PINE A64 ideally via the Euler bus instead of the
micro-USB connector).

Right now i'm using a 5V 4A brick from stontronics. The output from this is 
split to feed the pine (currently via micro usb) and the HDD. One of the 
reasons I chose the particular USB to SATA adapter I did is because it is only 
a data adapter, allowing me to do the power the way I want it.

I have just tried a different USB to SATA adapter, this one unfortunately uses 
a combined data and power connection to the drive, but it has a second USB plug 
for power, so I chopped up a USB extension and used it to connect said second 
USB plug direct to the power supply. I figured the pine64 would probably 
tolerate (and may even benefit from) any backfeeding of it's USB device ports 
this caused.

After the swap I was able to complete the rsync successfully. So it seems that 
some issue with the USB to SATA adapter I was using (either with the adapter in 
general or a compatibility issue between the adapter and the pine) was to blame.






Connecting external drives without own power or via a powered USB hub is
just asking for trouble :)

Kind regards,
Andrei

Re: Debian Installer on Pine64+ (no serial console)

[peter green]

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

This prompted me to reinstall my pine64 which has been sitting idle for a 
while, since the old install (based on a vendor image) on it stopped booting. 
Your instructions worked fine and after installation the system sucessfully 
rebooted to a login prompt.

At that point I got distracted, when I came back a day or so later I found that 
the Ethernet interface had stopped working. It appeared to be up and had an IP 
address (meaning it must have passed some packets since the reboot), but no 
traffic was getting through. Downing and re-upping the interface brought it 
back to life. I also rebooted the system and found the network interface had 
come up successfully after the reboot.

Then I ran into another problem. I have a SATA hard disk connected by a 
startech USB to SATA/IDE adapter (I belive its 
https://www.startech.com/uk/HDD/Adapters/USB-20-to-IDE-or-SATA-Adapter-Cable~USB2SATAIDE
 though I'm not using the PSU that came with it). When I tried to rsync a large 
file (an image of the pre-reinstall SD card contents) to said drive it dropped 
out. I unmounted and re-mounted the drive (which had renamed itself from sda to 
sdb after the dropout) and tried again, but the same happened again. I have a 
dmesg log from the second dropout at the bottom of the mail. The running kernel 
at the time was

Linux pine64 4.19.0-4-arm64 #1 SMP Debian 4.19.28-2 (2019-03-15) aarch64 
GNU/Linux

I then decided to upgrade to linux-image-5.0.0-trunk-arm64_5.0.2-1~exp1, 
unfortunately that didn't seem to improve things much, rather than the usb SATA 
dropping out and rsync returning an error, rsync just seemed to hang in 
uninterruptable sleep with no disk or network IO.




[  987.717823] sd 1:0:0:0: [sdb] tag#0 CDB: Write(10) 2a 00 01 44 e3 c0 00 00 
f0 00
[  987.717830] print_req_error: 256 callbacks suppressed
[  987.717836] print_req_error: I/O error, dev sdb, sector 21291968
[  988.062499] usb 1-1: USB disconnect, device number 3
[  988.077085] print_req_error: I/O error, dev sdb, sector 21292208
[  988.083176] print_req_error: I/O error, dev sdb, sector 21292448
[  988.089258] print_req_error: I/O error, dev sdb, sector 495192064
[  988.095381] Buffer I/O error on dev sdb2, logical block 59277312, lost sync 
page write
[  988.103338] JBD2: Error -5 detected when updating journal superblock for 
sdb2-8.
[  988.103347] print_req_error: I/O error, dev sdb, sector 21292688
[  988.110743] Aborting journal on device sdb2-8.
[  988.121233] print_req_error: I/O error, dev sdb, sector 21292928
[  988.127268] EXT4-fs warning (device sdb2): ext4_end_bio:323: I/O error 10 
writing to inode 13 (offset 16777216 size 5246976 starting block 2661632)
[  988.127276] buffer_io_error: 7414 callbacks suppressed
[  988.127285] Buffer I/O error on device sdb2, logical block 39680
[  988.133319] Buffer I/O error on device sdb2, logical block 39681
[  988.139341] Buffer I/O error on device sdb2, logical block 39682
[  988.145368] Buffer I/O error on device sdb2, logical block 39683
[  988.151390] Buffer I/O error on device sdb2, logical block 39684
[  988.157416] Buffer I/O error on device sdb2, logical block 39685
[  988.163438] Buffer I/O error on device sdb2, logical block 39686
[  988.169467] Buffer I/O error on device sdb2, logical block 39687
[  988.175489] Buffer I/O error on device sdb2, logical block 39688
[  988.181516] Buffer I/O error on device sdb2, logical block 39689
[  988.188059] print_req_error: I/O error, dev sdb, sector 495192064
[  988.194161] Buffer I/O error on dev sdb2, logical block 59277312, lost sync 
page write
[  988.202106] JBD2: Error -5 detected when updating journal superblock for 
sdb2-8.
[  988.202120] print_req_error: I/O error, dev sdb, sector 21293056
[  988.215542] print_req_error: I/O error, dev sdb, sector 21293296
[  988.221578] print_req_error: I/O error, dev sdb, sector 21293536
[  988.228521] EXT4-fs warning (device sdb2): ext4_end_bio:323: I/O error 10 
writing to inode 13 (offset 16777216 size 6295552 starting block 2661888)
[  988.230033] EXT4-fs warning (device sdb2): ext4_end_bio:323: I/O error 10 
writing to inode 13 (offset 16777216 size 7344128 starting block 2662144)
[  988.231395] EXT4-fs error (device sdb2) in ext4_do_update_inode:5331: 
Journal has aborted
[  988.239701] EXT4-fs warning (device sdb2): ext4_end_bio:323: I/O error 10 
writing to inode 13 (offset 16777216 size 8388608 starting block 2662400)
[  988.240263] Buffer I/O error on dev sdb2, logical block 0, lost sync page 
write
[  988.247618] EXT4-fs (sdb2): I/O error while writing superblock
[  988.253478] EXT4-fs error (device sdb2): mpage_map_and_submit_extent:2568: 
comm kworker/u8:1: Failed to mark inode 13 dirty
[  

openssl sha1 not working with large files on stretch arm.

[peter green]

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 type"|

|
What puzzles me is that it worked on raspbian buster, and also worked on debian 
stretch i386. According to the user who reported it to me it  worked on 
Raspbian jessie. Anyone have any clues? I'm not finding anything obvious in the 
build logs or from a quick look at the source (it seems a couple of source 
files are built with large file support and the rest are not, but which files 
doesn't seem to have changed between stretch and buster).


|

Re: Rebuilding the entire Debian archive twice on arm64 hardware for fun and proft

[peter green]

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 architecture in these
toolchains is incorrectly set to target ARMv6 rather than
ARMv7. That should be fixed and all those packages rebuilt at some
point.

Haskell does appear to be configured for armv7 in Debian (in the sense that I 
had to patch the package in Raspbian to make it build for armv6). I would guess 
for haskell that this is an issue that needs digging into the upstream source, 
not just looking at the build system.

Re: coturn - bus error on armhf

[peter green]

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 with
that, but I failed to reproduce this on abel.debian.org or
harris.debian.org: the package built and the unit test ran fine on
both.  Could you please advise how to proceed with this problem?  The
maintainer already requested a giveback, but it hasn't happened yet.


Try using an armhf chroot on amdahl.debian.org , iirc armhf chroots on arm64 
machines are often stricter about alignment than pure armhf machines.

Re: giveback of knot-resolver 3.1.0-1 on armhf?

[peter green]

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.

can't boot 4.18 kernel on wandboard quad.

[peter green]

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 is current device
=> mmc rescan
=> run loadbootenv
416 bytes read in 28 ms (13.7 KiB/s)
=> run importbootenv
Importing environment from mmc (uEnv.txt)...
=> printenv
baudrate=115200
boot_fdt=try
bootcmd=mmc dev ${mmcdev};if mmc rescan; then echo SD/MMC found on device 
${mmcdev};if run loadbootenv; then run importbootenv;fi;if test -n $uenvcmd; 
then echo Running uenvcmd ...;run uenvcmd;fi;if run loadzimage; then run 
mmcboot;fi;fi;
bootdelay=1
bootscript=echo Running bootscript from mmc ...; source
console=ttymxc0
ethact=FEC
ethaddr=00:1f:7b:b4:05:1a
ethprime=FEC
fdt_addr=0x1100
fdt_file=imx6q-wandboard.dtb
fdt_high=0x
filesize=1a0
importbootenv=echo Importing environment from mmc (uEnv.txt)...; env import -t 
$loadaddr $filesize
initrd_addr=0x1300
initrd_high=0x
ip_dyn=yes
loadaddr=0x1200
loadbootenv=load mmc ${mmcdev}:${mmcpart} ${loadaddr} uEnv.txt
loadbootscript=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};
loadfdt=load mmc ${mmcdev}:${mmcpart} ${fdt_addr} /dtbs/${fdt_file}
loadinitrd=load mmc ${mmcdev}:${mmcpart} ${initrd_addr} initrd.img
loadzimage=load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage
mmcargs=setenv bootargs console=${console},${baudrate} ${optargs} 
root=${mmcroot} rootfstype=${mmcrootfstype} video=${video}
mmcboot=run loadfdt; run mmcargs; run loadinitrd; bootz ${loadaddr} 
${initrd_addr}:${filesize} ${fdt_addr};
mmcdev=0
mmcpart=1
mmcroot=UUID=b1bbc414-67f6-40c3-a366-d3317a114748 ro
mmcrootfstype=ext4 rootwait fixrtc
script=boot.scr
stderr=serial
stdin=serial
stdout=serial
uimage=uImage

=> version

U-Boot 2013.04-00015-g5cd081a (Jun 23 2013 - 19:58:00)
arm-linux-gnueabihf-gcc (crosstool-NG linaro-1.13.1-4.8-2013.06 - Linaro GCC 
2013.06) 4.8.2 20130603 (prerelease)
GNU ld (crosstool-NG linaro-1.13.1-4.8-2013.06 - Linaro GCC 2013.06) 
2.23.2.20130610 Linaro 2013.06
=>

It's an older (and probablly vendor) u-boot but I would really rather not mess 
with the u-boot version if I can avoid it as this is a remotely hosted box.

Re: Firefox-esr crashed on ARMHF

[peter green]

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 dependencies, kernel,
shell environment), they must be essentially different, or am I wrong?

The most obvious suspect in that case would be toolchain issues, particularly 
the versions of rustc and llvm used to build the packages.

Re: https://lists.debian.org/debian-arm/2018/09/ is no more updated

[peter green]

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.

Is anyone running buster/sid on armel? if so does current udev work?

[peter green]

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 with gcc-7.

This issue does not appear to affect Debian armhf.

Which leaves me wondering about armel, has anyone tried udev 239-8 or 239-9 on 
armel? if so did it work?

Re: armel/armhf arch qualification for buster: call for DSA, Security, toolchain concernsj

[peter green]

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 Learned
  and Solutions Found" by Alex Doyle from Cumulus Network, they run
  "Jessie on Chromebook" as armel build server
  https://youtu.be/OPsfX5_YCiQ?t=14m39s

Thanks for your info!


  Maybe we can do same thing for armel, it'd be better than using old
  NAS with larger memory (I know we're trying to build armel/hf packages
  on arm64 but just a FYI).

Yes. In latest ARM BoF of DebConf18, Steve (93sam) informed us that
he's trying to rebuild all the armhf archive on arm64 box.
When that's done, we will get to know how many packages need to fix.
If the number of those packages is limited and can be fixed before
buster, we can choose this way for both armhf and armel.
But if the number is huge that we don't have enough manpower to fix,
we need to find real machine (such as rack-mounted armhf/armel NAS
box) to work as buildd.

Personal opinion but (as a derivative maintainer) I really think
DSA are being unreasonable here. A buildd does not need to be
some critical 100% uptime server, if it occasionally goes down
to the point where it can't be recovered remotely then so be it.

Arm ports aside I don't think having "server class" hardware
available should be a blocker for getting or maintaining a port
in Debian. It never has been in the past and I don't see what
has changed now.

And I think with a serial console and remote power most issues
can be resolved remotely. We have been running wandboard
quads for raspbian for years and I have never hard a situation
I couldn't get out of with remote power and serial console.

On the subject of building on arm64 hardware we now do this
for some of our builds in raspbian. It *mostly* works but we
do see some testsuite failures that we don't see on the
wandboards (otoh we have some testsuites that pass on the
arm64 box but not the wandboards, go figure) and I have
also been having a build hang with rust recently, but other
than that I haven't noticed any prblems.

Re: causes for this?

[peter green]

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 packages into a small number of Debian packages, 
I understand why they do this (tex packages are mostly quite small and there is 
an overhead for each package in the Debian archive) but it basically means that 
you normally end up installing all the packages because you end up wanting 
something from each.
2. Up to and including stretch texlive-latex-base, texlive-latex-recommended and 
texlive-latex extra declared "recommends on" their corresponding doc packages. 
These doc packages (especially texlive-latex-extra-doc) are unfortunately very large 
adding up to about 450 megabytes of download and about 550 megabytes of installed size).

You can avoid the second issue by telling apt not to install recommends, 
unfortunately I don't think there is much you can do about the first.

Re: Anybody here know what a rock64 is?

[peter green]

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 designed for the whole Pi family.

Some parts of it are generic other parts are specific to either the Raspberry 
Pi hardware/firmware or to the way raspberry pi have set up their image.

The locales part is generic, but all it's doing is calling "dpkg-reconfigure 
locales" so there isn't much to borrow there.

gcc-8, libatomic and armel/raspbian

[peter green]

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 in Debian armel sid and 
buster.

I patched out the flag in the raspbian package and things still seem to build 
successfully with the resulting package passing our contamination checker. A 
debdiff should appear soon at http://debdiffs.raspbian.org/main/g/gcc-8/

It's possible (even likely) that this is a false positive and that the code in 
question is behind runtime detection, even if it is a false positive though 
problematic to have armv7 tags on a static library because they have the 
potential to cause further false positives in downstream code.

Anyone have any thoughts?

Re: all translations for Jessie are 403.

[peter green]

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 of verbosity from synaptic.  Its been this way for in
excess of a week.

You will need to be more specific; which sources.list are you using,
what errors are you getting etc.

This sources.list:
pi@picnc:~ $ cat /etc/apt/sources.list
deb http://mirrordirector.raspbian.org/raspbian/ jessie main contrib
non-free rpi
# Uncomment line below then 'apt-get update' to enable 'apt-get source'
#deb-src http://archive.raspbian.org/raspbian/ jessie main contrib
non-free rpi

And in /etc/apt/sources.list.d
pi@picnc:/etc/apt/sources.list.d $ cat raspi.list
deb http://archive.raspberrypi.org/debian/ jessie main ui
# Uncomment line below then 'apt-get update' to enable 'apt-get source'
#deb-src http://archive.raspberrypi.org/debian/ jessie main ui

And
pi@picnc:/etc/apt/sources.list.d $ cat linuxcnc-buildbot.list
#debhttp://buildbot.linuxcnc.org/ jessie master-sim
#deb-srchttp://buildbot.linuxcnc.org/ jessie master-sim
deb http://buildbot.linuxcnc.org/ jessie master-sim

Just now its upgrading about 8 or 9 files but isn't fussing about
translations. Its not doing the kernel because its a special kernel I
have pinned.

And as I said, apparently all the translations are missing.

And tonight, because you asked for the errors, it all worked on the rpi3.
And thats the only jessie install.  Go figure. But then I was running
apt over an ssh login. Not synaptic because some "genius" has set up a
security rule someplace I haven't yet found and nuked that keeps me from
running synaptic-pkexec over an ssh -Y session.


What puzzles me is I don't think raspbian has ever shipped translations, so I 
wonder what has changed recently.

Re: how to distinguish armel and armhf at runtime?

[peter green]

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 so has to know which cpp
symbols to define. Usually it uses uname -m to distinguish platforms but
that isn't suitable to tell armel and armhf apart.

For armhf I need to define __ARM_PCS_VFP but that must be absent on armel.

Right, that makes sense.


For upstreaming a fix it would be great if the test would not be Debian
specific.

That's likely to be difficult - it's perfectly possible to have
headers etc. for both on a single system with multi-arch (for
example). It's an ABI choice, not a hardware difference.

What are you trying to work this out for? Package build time?

No, it's for run time. The target is sparse which can parse C and to be
able to handle system includes it needs the right cpp variables defined.

Are people expected to have gcc installed when using this tool? if so gcc 
-dumpmachine may be an option.

Bug#850906: ceph FTBFS on armel, libtool/linker related issues.

[peter green]

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/../../../arm-linux-gnueabi/crti.o 
/usr/lib/gcc/arm-linux-gnueabi/6/crtbeginS.o  
java/native/.libs/libcephfs_jni_la-libcephfs_jni.o 
java/native/.libs/libcephfs_jni_la-JniConstants.o  -Wl,--whole-archive 
./.libs/libcommon.a -Wl,--no-whole-archive  -Wl,--as-needed 
-L/«PKGBUILDDIR»/debian/tmp/usr/lib/arm-linux-gnueabi 
-L/usr/lib/arm-linux-gnueabi -lcephfs -ldl -lboost_thread -lboost_random 
-lblkid -luuid -lrt -lboost_iostreams -lboost_system 
-L/usr/lib/gcc/arm-linux-gnueabi/6 
-L/usr/lib/gcc/arm-linux-gnueabi/6/../../../arm-linux-gnueabi 
-L/usr/lib/gcc/arm-linux-gnueabi/6/../../.. -L/lib/arm-linux-gnueabi -lstdc++ 
-lm -lc -lgcc_s /usr/lib/gcc/arm-linux-gnueabi/6/crtendS.o 
/usr/lib/gcc/arm-linux-gnueabi/6/../../../arm-linux-gnueabi/crtn.o  -O2 -g 
-fstack-protector-strong -g -O2 -fstack-protector-strong -Wl,-z -Wl,relro 
-Wl,-z -Wl,now -Wl,-z -Wl,relro -Wl,-z -Wl,now   -Wl,-soname 
-Wl,libcephfs_jni.so.1 -o .libs/libcephfs_jni.so.1.0.0
/usr/bin/ld: /«PKGBUILDDIR»/debian/tmp/usr/lib/arm-linux-gnueabi/libcephfs.so: 
invalid string offset 50471 >= 3194 for section `.strtab'
<--snip-->
libtool: warning: remember to run 'libtool --finish /usr/lib/arm-linux-gnueabi'
make[5]: Leaving directory '/«PKGBUILDDIR»/src'
Makefile:32173: recipe for target 'install-am' failed
make[4]: *** [install-am] Error 2
make[4]: Leaving directory '/«PKGBUILDDIR»/src'
Makefile:30865: recipe for target 'install-recursive' failed
make[3]: *** [install-recursive] Error 1
make[3]: Leaving directory '/«PKGBUILDDIR»/src'
Makefile:32167: recipe for target 'install' failed
make[2]: *** [install] Error 2
make[2]: Leaving directory '/«PKGBUILDDIR»/src'
Makefile:703: recipe for target 'install-recursive' failed
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory '/«PKGBUILDDIR»'
dh_auto_install: make -j4 install DESTDIR=/«PKGBUILDDIR»/debian/tmp 
AM_UPDATE_INFO_DIR=no returned exit code 2
debian/rules:73: recipe for target 'binary-arch' failed

This seems like a rather strange error, putting debian-arm in cc in case anyone 
there has any ideas.

Re: Help need with build failure of ceph 10.2.5-2 on armel

[peter green]

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 plugin on armel.


This flag must only be used on armel (not on armhf) and must only be 
used for code that is gaurded behind appropriate runtime detection.

Re: cubox i4x4 hard drive seen in D-I but not in installed system.

[peter green]

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 lower port. I know
the issue seems completely different from yours, but this might be an
important point to get your issue properly solved.
   
Just tried moving the power cable for my HDD to the lower port, that 
made no difference.


I then tried plugging the power cable for hard drive into a HTC phone 
charger. That made the drive show up without needing to use the 
"hotplug" option.


So it seems this is indeed a timing issue between power up of the USB 
port and initialisation of the SATA interface either because USB init is 
being sequenced after SATA init or because the hard drive takes some 
time from power up to being ready to talk on the SATA interface.

Re: cubox i4x4 hard drive seen in D-I but not in installed system.

[peter green]

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.


Checking the schematic I notice that the USB ports seem to have power 
control, I wonder if they are power-cycled at some point during the boot 
process.

Re: cubox i4x4 hard drive seen in D-I but not in installed system.

[peter green]

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 see it 
after installing. The ahci_imx module seems to be loaded but sda 
doesn't appear in /dev.


I upgraded to the kernel from backports. This made no difference.

Any idea how to go about troubleshooting this issue? the box isn't 
much use to me if I can't make the hard drive work.

Ok, after some discussions on irc I discovered some more.

It seems that the system sees the port but fails to detect the drive.

[2.694758] ahci-imx 220.sata: fsl,transmit-level-mV value 1104, 
using 0044
[2.694778] ahci-imx 220.sata: fsl,transmit-boost-mdB value 0, 
using 
[2.694791] ahci-imx 220.sata: fsl,transmit-atten-16ths value 9, 
using 2000
[2.694802] ahci-imx 220.sata: fsl,receive-eq-mdB not specified, 
using 0500
[2.698172] ahci-imx 220.sata: SSS flag set, parallel bus scan 
disabled
[2.698208] ahci-imx 220.sata: AHCI 0001.0300 32 slots 1 ports 3 
Gbps 0x1 impl platform mode
[2.698223] ahci-imx 220.sata: flags: ncq sntf stag pm led clo 
only pmp pio slum part ccc apst

[2.699973] scsi host0: ahci-imx
[3.014679] ahci-imx 220.sata: no device found, disabling link.
[3.014690] ahci-imx 220.sata: pass .hotplug=1 to enable hotplug

However if I unload and reload the driver then it sees the drive 
successfully.


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).

cubox i4x4 hard drive seen in D-I but not in installed system.

[peter green]

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 seems to be loaded but sda doesn't 
appear in /dev.


I upgraded to the kernel from backports. This made no difference.

Any idea how to go about troubleshooting this issue? the box isn't much 
use to me if I can't make the hard drive work.


When trying to debug I wondered if the wrong dtb was being used. 
Unfortunately I can't seem to figure out what puts the dtb in /boot and 
how it selects which dtb to use.

Re: Any chance to provide upstream access to armhf machine thats comparable to our autobuilder?

[peter green]

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 buildds and 
has both armel and armhf chroots available.


There is a procedure for guest accounts on porterboxes, though I haven't 
used it myself so I don't know how well it works in practice.

Re: What current NAS platform is recommended for installing Debian?

[peter green]

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 talk of partial 
architectures but partial architectures have been just talk for years.
I then saw the Seagate Personal Cloud - however, apparently these are 
also a bit dated:

A bit dated perhaps but nowhere near as dated as the QNAPs.

Re: postgis failing to build on arm64 only

[peter green]

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).
   
Yeah, I ran into the same thing when trying to sort out freepascal on 
powerpc. In the end I resorted into using qemu (which worked but is 
bloody slow).


I wonder if it could be worth talking to DSA about using 
container/namespace technology to improve the porterbox experiance.

Re: arm64 pointer tagging, VA-bits, the end of the world...

[peter green]

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 javascript 
engines), don't merely want to tag pointers, they want to create a 
64-bit "compact variant" that stores multiple different types of data 
including double precision integers and pointers (possiblly even more 
than one type of pointer) using non-overlapping bit patterns.


This is possible due to the fact that the double precision floating 
point format reserves a large chunk of code space (2^53 bit patterns) 
for NaNs and infinities. Assuming your application doesn't need a crazy 
number of different NaNs these bit patterns can be repurposed for other 
things.


If your pointers are 48 bit then it's no problem to store multiple 
different types of pointer and other values in the NaN-space. On the 
other hand if your pointers are 56 bit then you have a serious problem.


Alignment considerations mean that if the compact variant had to grow 
beyond 64 bit it would probablly end up being 128 bit which is a fairly 
steep penalty on memory usage.

Re: Which port for armv4l?

[peter green]

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 kernel) was supposed to allow running code with BX
instructions on a processor that lacks it, and that's why I want to use it
(to run Debian for armel on StrongARM SA-1100, which has ARMv4 core, so
without Thumb). Code in Debian for armel architecture doesn't use Thumb?


Unless explicitly told otherwise the compilers in Debian armel build arm mode 
code. I don't think there is anything forbidding packagers from chosing thumb 
mode for their code but they would have to go out of their way to make that 
choice and i'm not aware of anyone doing so.

However the compiler doesn't know whether you will be mixing the arm code it 
built with thumb code built with another compiler invocation. So it uses BX for 
function calls and returns.

Re: Broadcom BCM2709, ARMv8, and missing CPU features

[peter green]

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 models (older firmware 
will only work with older pi models).


The Pi1 needs a specific kernel. The Pi2 and the Pi3 can run the same 
32-bit kernel (at least with foundation kernels, I dunno what the 
situation is with upstream kernels)


The firmware by default selects a suitable kernel (kernel.img or 
kernel7.img) and device tree (each Pi model has a different one though 
IIRC they are pretty similar) based on the detected hardware.


There is some experimental 64-bit kernel/bootloader stuff out there for 
the raspberry pi 3 
https://www.raspberrypi.org/forums/viewtopic.php?f=72=137963=aarch64 
https://www.raspberrypi.org/forums/viewtopic.php?f=72=143765


Userland obviously has to be compatible with the hardware and kernel. 
Raspbian or Debian armel userlands should be usable on any Pi model. 
Debian armhf userland should be usable on a pi2 or pi3 but clearly not a 
pi1. Debian arm64 will obviously require a 64-bit kernel and a pi3.

Re: Summary of the ARM ports BoF at DC16

[peter green]

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?

SD card device name changed on wandboard quad.

[peter green]

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.

Re: armhf ABI flag problems with fpc-built binaries

[peter green]

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 whether they're using the
hard-float or soft-float ABI (if they care specifically - some
don't). I've found a few fpc-using packages (both under your
maintenance and not) that appear to get this wrong, which suggests
that there might be a toolchain issue here in fpc and friends. My
scanner is telling me that the following armhf packages are broken:

doublecmd-plugins_0.7.1-2_armhf.debhf_flags_wrong:6
fp-compiler-3.0.0_3.0.0+dfsg-4_armhf.deb   hf_flags_wrong:4
fp-ide-3.0.0_3.0.0+dfsg-4_armhf.debhf_flags_wrong:1
fp-utils-3.0.0_3.0.0+dfsg-4_armhf.deb  hf_flags_wrong:28 no_hf_flags:2
gearhead_1.300-1_armhf.deb hf_flags_wrong:1
pasdoc_0.14.0-1_armhf.deb  hf_flags_wrong:1

"hf_flags_wrong" here means that the package is targeting armhf, but
binaries within it claim to use the soft-float ABI. "no_hf_flags" is
the number of binaries that have no ABI float flags attached. To see
for yourself, you can use "readelf --file-header" to inspect the flags
on binaries - look for

   Flags:   0x5000202, has entry point, Version5 EABI, soft-float ABI

etc. armhf binaries should show

   Flags:   0x5000402, has entry point, Version5 EABI, hard-float ABI

instead. I'm not sure exactly where fpc would be setting flags like
this (if anywhere) or if it's calling binutils incorrectly maybe. Can
anybody help me dig into this please?

(See the attached list for details of the broken files.)
   

Most likely the place to start in the fpc code is compiler/arm/agarmgas.pas

If someone can tell me what needs to be done at an assembler level I can 
look into making fpc do it. (unfortunately infinity's paste referenced 
in the bug report has expired).

Re: kexec-tools installs on arm64

[peter green]

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
package?
   

I would class it as a design limitation of multiarch.

apt has no way of knowing if a particular foreign-architecture package 
will actually be useful. Only what dependencies it will satisfy and 
whether versions for multiple architectures can be co-installed.

Re: [Stretch] Status for architecture qualification

[peter green]

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 problems do you see?
   
A big concern going forward is C++11 atomics. AIUI (unless something has 
changed recently) these are unimplemented on armel causing code that 
uses them to FTBFS. Right now very little code uses them but if a major 
peice of infrastructure starts using them it could put armel in a very 
sticky sitution.


armv4t doesn't really have good atomic instructions (there is "swp" but 
it has to be emulated on later architectures and i'm not sure it's 
enough to support the normal range of operations) . AIUI there are 
kernel helpers available but it would need someone with good knowlage of 
the subject to implement the C++11 atomics in terms of the kernel helpers.

Re: [Stretch] Status for architecture qualification

[peter green]

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 .

Re: [Stretch] Status for architecture qualification

[peter green]

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 
other concerns?

- armel has a RT concern about lack of buildds (only 2)
   
I think this is outdated, my understanding is that armel and armhf are 
now using a shared buildd pool. I see arnold, hoiby, henze, hasse, 
antheil and hartmann recently active on the armel buildd page and the 
same on the armhf page.

Re: [Stretch] Status for architecture qualification

[peter green]

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 packages.
 

I'm not sure whether you are talking about source or binary packages but
sid/amd64 has over 24000 source packages and over 5 binary packages,
so I would call the above "on par". Or what am I missing?

   
I presume he is talking about source packages in the "installed" state 
in wana-build. For comparison this is currently 12153 for amd64 and 
10937 for mips.


(this leads to the interesting conclusion that about half the source 
packages in sid are arch-all only)

Re: affordable arm boards with plenty of ram.

[peter green]

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
   builds: 182
   

This looks interesting, do you have more information on it?

Re: affordable arm boards with plenty of ram.

[peter green]

On 19/05/16 17:25, Phil Endecott wrote:

peter green<plugwash  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 support would be nice.
 

This is what we've all been waiting for for years.
   
Indeed. I figured I probablly wasn't the only person on this list 
waiting for such a thing and hence I put out this message asking if 
anyone had spotted something I hadn't. I also asked on irc.


   

Currently looking at the cubox i4x4. Anyone have any other suggestions?
 

No, they're all deficient in some way.

That one (a) has a Freescale processor, which I would avoid after
my experience with the i.MX53,
mmm, I did have a nitrogen6x die on me (out of warranty and given where 
I live sending it back to boundary for an opinion on why it failed and 
whether it was repairable would have been prohibitively expensive). 
Other than that i've been pretty happy with imx6 based stuff.

(b) isn't 64-bit, (c) has only 1 GHz
CPU clock.

You can get faster CPUs (4x 2GHz A15, so probably about 3X the
speed) but half the RAM and no SATA (but USB3) in the ODROID-XU4.
   
Yeah, that is pretty much my conclusion. For the ammount of money I'm 
prepared to spend on arm boards you can get modern CPU cores of 4GB of 
ram but not both. Theres the nvidia jetson TX1 but it costs far more 
than I personally consider reasonable (though I would note that sili and 
i'm not sure what the kernel situation with it is (it apparently has 
some support in mainline but I dunno if it has enough to be usable). 
Theres the husky/cello (which is overbudget but good enough specs that I 
would consider blowing said budget) but afaict it's not actually 
available yet.

If you want 64-bit, the ODROID-C2 which I have is possibly
the best option - but it has A53 not A57 cores (so maybe 2X
the speed of the Cubox 4x4), and 2 GB RAM, and no SATA.

The question of whether CPU, RAM or filesystem I/O limits
performance in practice is an interesting one.  The feeling
I have is the for kernel compiles my ODROID-C2 is CPU-limited.
The thing with ram is that most of the time it doesn't matter much but 
when it does matter it really matters. Grinding swap sucks.



Let us know what you decide.
   
If noone suggests anything better by the end of today I think i'll go 
ahead and order the cubox i4x4

Re: [llvm-dev] llvm-toolchain-3.8 on lower arm targets, specifically Debian armel and Raspbian.

[peter green]

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 should carry on
quite happily without it.

If you do need the sanitizers from compiler-rt, you can disable the
bits that are causing problems right now with "cmake
-DCOMPILER_RT_BUILD_BUILTINS=OFF". Of course, the
sanitizers themselves may suffer from similar issues -- you just won't
know until you get there.
   
Thanks, -DCOMPILER_RT_BUILD_BUILTINS=OFF did the trick and I got a 
successful build for raspbian that passed my armv7 contamination checker 
script (which is not 100% foolproof but it's the best we have) and 
uploaded it to raspbian stretch.

affordable arm boards with plenty of ram.

[peter green]

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 
USB3 which is better than USB2).

Support in Debian kernels would be nice.
arm64 support would be nice.

Currently looking at the cubox i4x4. Anyone have any other suggestions?

Re: Hybrid armhf/arm64 system

[peter green]

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"

Re: [llvm-dev] llvm-toolchain-3.8 on lower arm targets, specifically Debian armel and Raspbian.

[peter green]

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 telling the cmake buildsystem 
(which is what the Debian packaging currently seems to use) that I want 
it to build without compiler-rt?

Re: [llvm-dev] llvm-toolchain-3.8 on lower arm targets, specifically Debian armel and Raspbian.

[peter green]

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 explicit -march=armv6 or
something so you're not at the mercy of how the host compiler was
configured.

I suspect you're the first person to try and get compiler-rt going for
pre-v7 hardware, which most of us prefer to pretend never happened
most of the time.
   

Thank you very much for your reply.

Can you clarify what exactly compiler-rt is and how important it is to 
the stack as a whole. It seems that llvm-toolchain-3.7 built 
successfully on raspbian without building compiler-rt while 
llvm-toolchain-3.8 built an armv7 compiler-rt (and hence got blocked 
from entering the raspbian repos).

llvm-toolchain-3.8 on lower arm targets, specifically Debian armel and Raspbian.

[peter green]

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 build-system hacker but then I got a failure on

projects/compiler-rt/lib/builtins/arm/sync_fetch_and_add_4.S

[  8%] Building ASM object 
projects/compiler-rt/lib/builtins/CMakeFiles/clang_rt.builtins-armhf.dir/arm/sync_fetch_and_add_4.S.o
cd 
/llvm-toolchain-3.8-3.8/build-llvm/projects/compiler-rt/lib/builtins 
&& /usr/bin/gcc-5  -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS 
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
-I/llvm-toolchain-3.8-3.8/build-llvm/projects/compiler-rt/lib/builtins 
-I/llvm-toolchain-3.8-3.8/projects/compiler-rt/lib/builtins 
-I/llvm-toolchain-3.8-3.8/build-llvm/include 
-I/llvm-toolchain-3.8-3.8/include  -fPIC -O2 -g -DNDEBUG
-mfloat-abi=hard -o 
CMakeFiles/clang_rt.builtins-armhf.dir/arm/sync_fetch_and_add_4.S.o -c 
/llvm-toolchain-3.8-3.8/projects/compiler-rt/lib/builtins/arm/sync_fetch_and_add_4.S
/llvm-toolchain-3.8-3.8/projects/compiler-rt/lib/builtins/arm/sync_fetch_and_add_4.S: 
Assembler messages:
/llvm-toolchain-3.8-3.8/projects/compiler-rt/lib/builtins/arm/sync_fetch_and_add_4.S:20: 
Error: selected processor does not support `dmb' in Thumb mode
/llvm-toolchain-3.8-3.8/projects/compiler-rt/lib/builtins/arm/sync_fetch_and_add_4.S:20: 
Error: selected processor does not support `ldrex r0,[r12]' in Thumb mode
/llvm-toolchain-3.8-3.8/projects/compiler-rt/lib/builtins/arm/sync_fetch_and_add_4.S:20: 
Error: cannot honor width suffix -- `add r2,r0,r1'
/llvm-toolchain-3.8-3.8/projects/compiler-rt/lib/builtins/arm/sync_fetch_and_add_4.S:20: 
Error: selected processor does not support `strex r3,r2,[r12]' in 
Thumb mode
/llvm-toolchain-3.8-3.8/projects/compiler-rt/lib/builtins/arm/sync_fetch_and_add_4.S:20: 
Error: selected processor does not support `dmb' in Thumb mode
projects/compiler-rt/lib/builtins/CMakeFiles/clang_rt.builtins-armhf.dir/build.make:1097: 
recipe for target 
'projects/compiler-rt/lib/builtins/CMakeFiles/clang_rt.builtins-armhf.dir/arm/sync_fetch_and_add_4.S.o' 
failed
make[4]: *** 
[projects/compiler-rt/lib/builtins/CMakeFiles/clang_rt.builtins-armhf.dir/arm/sync_fetch_and_add_4.S.o] 
Error 1

make[4]: Leaving directory '/llvm-toolchain-3.8-3.8/build-llvm'
CMakeFiles/Makefile2:12146: recipe for target 
'projects/compiler-rt/lib/builtins/CMakeFiles/clang_rt.builtins-armhf.dir/all' 
failed
make[3]: *** 
[projects/compiler-rt/lib/builtins/CMakeFiles/clang_rt.builtins-armhf.dir/all] 
Error 2

make[3]: *** Waiting for unfinished jobs...
I traced this back to code in compiler-rt/lib/builtins/arm/sync-ops.h . 
The comments talk about both arm mode and thumb2 mode code but I only 
actually see thumb2 code in the file. I'm kinda stuck here.


I expect this would be a problem for armel too (though it may go 
unnoticed due to the fact the armel autobuilders now run on armv7 
hardware and afaict Debian armel unlike raspbian doesn't have any 
contamination checking in place) but the build doesn't even get that 
far. It fails earlier with.



/«PKGBUILDDIR»/include/llvm/Support/ThreadPool.h: In member function 'std::shared_future  
llvm::ThreadPool::async(Function&&, Args&&  ...)':
/«PKGBUILDDIR»/include/llvm/Support/ThreadPool.h:77:77: error: return type 'class 
std::shared_future' is incomplete
inline std::shared_future  async(Function&, Args&&... ArgList) {
  ^
/«PKGBUILDDIR»/include/llvm/Support/ThreadPool.h: In member function 
'std::shared_future  llvm::ThreadPool::async(Function&&)':
/«PKGBUILDDIR»/include/llvm/Support/ThreadPool.h:95:57: error: return type 'class 
std::shared_future' is incomplete
inline std::shared_future  async(Function&) {

Re: Hybrid armhf/arm64 system

[peter green]

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 probably doesn't get tested as much as something in
i386.  Same amount of time maybe but less actual usage.
   
That is true, and hence the chance of being the first person to hit a 
regression is going to be higher on arm* testing than on i386/amd64 testing.


On the other hand while arm64 scraped into the jessie release it only 
barely did so. At the time of the jessie release the *only* arm64 
hardware available to us was internal arm devboards and a bit of server 
hardware. So afaict arm64 jessie never really got any end-user testing.

Re: ODROID-C2

[peter green]

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 "plain Debian" working on a board with a new SoC requires a LOT 
of effort upstreaming patches (since the Debian maintainers 
understandablly don't want to put random vendor crap in their packages 
and try to support it locally). Even when it does work there are often 
functional limitations due to code that is either non-free or is free 
but needs major reworking before upstream will take it.


Whereas to get a mostly Debian system with a few custom bits (kernel, 
bootloader, possiblly custom versions of a few libraries) going is much 
easier.

Re: Supporting armel/armhf in wheezy-lts

[peter green]

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/armhf buildd for two more years do not go against some DSA plans to
decommission some machines running those buildd and that you had no other
problems to keep those machine running during the LTS timeframe.
   
I'm not DSA but my understanding is that all suites are built on the 
same buildds, since jessie supports armel and armhf and squeeze will 
almost certainly support at least one and hopefully both of those we 
will need autobuilder hardware for the forseeable future.

Re: [Pkg-julia-devel] Bug#820220: Bug#820220: Bug#820220: Bug#820220: julia: FTBFS on armel/armhf

[peter green]

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 can reproduce the issue and get a 
dissasembly of the failure location.


My gut feeling is that llvm is trying to use neon without first checking 
it is supported. Afaict the marvell boards we are using for armhf 
buildds (and for the abel.d.o porterbox) don't have neon.



[1] 
https://buildd.debian.org/status/package.php?p=llvm-toolchain-3.8=unstable

   

Re: [Reproducible-builds] Raspi 3 suitable for arm64?

[peter green]

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 
substantially bumped up clockspeed. Ram is still limited to 1GB by 
limitations in the videocore bus strutucture.


Right now only a 32-bit kernel is available from raspberry pi. There is 
a config.txt option to make the cores start in 64-bit mode ( 
https://www.raspberrypi.org/forums/viewtopic.php?f=72=137963#p915771 ) 
but it's not clear if Raspberry Pi will put in the effort to do a 64-bit 
port of the platform code in the kernel and if not whether someone else 
will.

Re: Bug#790925: pandas: FTBFS on armhf and sparc: Bus error in test_append_frame_column_oriented

[peter green]

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=armhf=0.17.1-3=1450078009
test_append_frame_column_oriented (pandas.io.tests.test_pytables.TestHDFStore) ... 
Exception AttributeError: AttributeError("'File' object has no attribute 
'_node_manager'",) in  ignored
Bus error

sparc is gone and seems to be not trying on sparc64 yet.  I will look
into fixing up my testing environment on sparc64 to see how current
master is doing:
http://nipy.bic.berkeley.edu/builders/pandas-py2.x-sid-sparc/builds/1806

Dear ARM people -- any clues on what could be a culprit here
The most likely cause of "bus error" on armhf is an alignment issue with 
a pointer to a floating point type.

imx6 ethernet drops with sid kernel.

[peter green]

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 
GNU/Linux


However the board now seems to be having issues with ethernet dropping 
from time to time. The most recent time it happened I was on the serial 
console and saw the following messages.


[ 9348.474418] fec 2188000.ethernet eth0: MDIO read timeout
[ 9350.478804] fec 2188000.ethernet eth0: Link is Down

Some googling shows reports of similar issues but i'm not sure if/how 
these apply to the Debian kernel.

Re: Squeeze support

[peter green]

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
deb-src http://ftp.debian.org/debian/ squeeze main contrib non-free

deb http://security.debian.org/ squeeze/updates main contrib non-free
deb-src http://security.debian.org/ squeeze/updates main contrib non-free

deb http://ftp.debian.org/debian/ squeeze-updates main contrib non-free
deb-src http://ftp.debian.org/debian/ squeeze-updates main contrib non-free
=== cut ===

Also tried us.debian.org and de.debian.org.
   

Use archive.debian.org

https://lists.debian.org/debian-devel-announce/2015/08/msg9.html

Re: Mixing Fortran and C (on arm64, ppc64, ppc64el, mips64el and s390x)

[peter green]

On 25/09/15 21:57, Edmund Grimley Evans wrote:

Does anyone here have any experience of mixing Fortran and C?

A couple of (possibly) related bug reports:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774618
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800040
   

Right.

I don't use fortran but I took a look at the bug reports anyway.


#if defined(__alpha__) || defined(__sparc64__) || defined(__x86_64__) || 
defined(__ia64__)

I think you could just add the failing 64-bit architectures to that
list: defined(__aarch64__) for arm64; see
https://wiki.debian.org/ArchitectureSpecificsMemo  for the others.
   

That just seems like papering over the problem.

(Note that this is, presumably, not supposed to be a list of all
"64-bit architectures". The package seems to be working on s390x and
ppc64, although they are "64-bit architectures" and not in the list

I belive your conclusion is wrong.

From the ppc64 build log (s390x was much the same).

┌──┐
│ Run tests for ruby2.1 from debian/ruby-tests.rb  │
└──┘

RUBYLIB=/«PKGBUILDDIR»/debian/ruby-lapack/usr/lib/powerpc64-linux-gnu/ruby/vendor_ruby/2.1.0:/«PKGBUILDDIR»/debian/ruby-lapack/usr/lib/ruby/vendor_ruby:.
 ruby2.1 debian/ruby-tests.rb
Loaded suite tests
Started ** On entry to CGESDD parameter number  5 had an illegal value
/usr/bin/ruby2.2 /usr/bin/gem2deb-test-runner


On the other hand from the alpha build log I see (armel and i386 were 
much the same).


┌──┐
│ Run tests for ruby2.1 from debian/ruby-tests.rb  │
└──┘

RUBYLIB=/«PKGBUILDDIR»/debian/ruby-lapack/usr/lib/alpha-linux-gnu/ruby/vendor_ruby/2.1.0:/«PKGBUILDDIR»/debian/ruby-lapack/usr/lib/ruby/vendor_ruby:.
 ruby2.1 debian/ruby-tests.rb
Loaded suite tests
Started
...
.

Finished in 0.232545348 seconds.
--
116 tests, 448 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 
notifications
100% passed
--
498.83 tests/s, 1926.51 assertions/s
/usr/bin/ruby2.2 /usr/bin/gem2deb-test-runner


So I would conclude that the code is broken on all 64-bit architectures 
not explicitly enumerated in the ifdef but the breakage manifests itself 
differently on big endian and little endian architectures and for 
whatever reason the manifestation seen on big endian architectures 
doesn't cause a build failure.


Personally I would suggest changing the ifdef to

#if defined(__alpha__) || defined(__sparc64__) || defined(__x86_64__) || 
defined(__ia64__) || defined(__LP64__)


(you could remove the specific CPUs that are already there but I left 
them in just in case anyone is building with an old compiler)


I would then suggest running test builds on at least one architecture 
from each category (e.g. at least one out of arm64/mips64el/ppc64el and 
at least one out of s390x/ppc64) and seeing if the situation improves.

Re: Bug#795331: iceweasel: backport/security builds (bundled libvpx) FTBFS on armhf

[peter green]

On 13/08/15 00:05, Simon McVittie wrote:

As described onhttps://bugs.debian.org/795079, a rebuild of
iceweasel/38.1.1esr-1 with ~deb9u1 appended to the version number, in a
stretch environment, failed to build from source on armhf. Build log:
https://people.debian.org/~jcristau/iceweasel_38.1.1est-1~deb9u1_armhf.log.txt
I worked around this by using ~stretch instead of ~deb9u1 for the
subsequent 38.2.0 upload.

I suspect this might also be affecting 38.2.0esr-1~deb8u1 in the
security archive. security.debian.org offers 38.2.0esr-1~deb8u1 for armel
but not armhf, which supports this theory. However, security buildds don't
publish their logs to avoid leaking details of embargoed packages
   
Yeah, it sucks that there is no system in place to publish logs for 
security packages along with the packages themselves.

The iceweasel packaging automatically adapts itself to be suitable for
backports when it sees ~bpo or ~deb in the version number:

yuck

  in particular,
it uses a few bundled libraries, including libvpx, instead of the system
equivalents. If I had re-generated control.in from control, it would also
have dropped the corresponding build-dependencies, but for a t-p-u upload
I didn't particularly want to do that.

Instead of its upstream build system as used in src:libvpx, the bundled
libvpx in iceweasel is built using media/libvpx/moz.build, which has
this code:

if CONFIG['VPX_ARM_ASM']:
...
 for f in SOURCES:
 if f.endswith('.c') and 'neon' in f:
 SOURCES[f].flags += ['-march=armv7-a', '-mthumb', 
'-mfloat-abi=softfp', '-mfpu=neon']

I assume this is present so that the NEON-optimized files will be built
with the softfp ABI on ARM OABI (the deprecated arm architecture in Debian),
which used a different ABI by default.
Using a non-default ABI seems like a good way to break stuff and afaict 
few people care about OABI anymore. I doubt this was the reason.



On ARM EABI softfloat (armel),
-mfloat-abi=softfp is equivalent to the default, and is harmless.
   
No it's not equivilent to the default. The default on armel is 
mfloat-abi=soft which disables the FPU completely. mfloat-abi=softfp 
uses the soft-float ABI but allows the compiler to use the FPU


So if you are going to build an alternative code path/version of a 
binary for armel that uses the fpu (obviously there must be a non-fpu 
based codepath/binary as well as presense of a VFP FPU is not 
gauranteed) then you need to use -mfloat-abi=softfp.

Unfortunately, on ARM EABI hardfloat (armhf), the use of -mfloat-abi=softfp
causes glibc to take the softfloat code path ingnu/stubs.h:

#if !defined __ARM_PCS_VFP
# includegnu/stubs-soft.h
#endif
#if defined __ARM_PCS_VFP
# includegnu/stubs-hard.h
#endif

In Debian,gnu/stubs-soft.h  only exists on armel, whilegnu/stubs-hard.h
only exists on armhf, so this fails:

code that tries to use the soft float abi on debian armhf is going to be pretty 
broken, so it's probablly a good thing that it fails to build.

Bug#785770: RM: xserver-xorg-video-siliconmotion [arm64] -- RoP; FTBFS; out-of-date; uninstallable; quite possiblly never worked, little if any utility

[peter green]

Package: ftp.debian.org
x-debbugs-cc: debian-arm@lists.debian.org,debia...@lists.debian.org

A recent xorg update caused xserver-xorg-siliconmotion to fail to build 
with the following error.



/bin/bash ../libtool  --tag=CC   --mode=compile gcc -std=gnu99 -DHAVE_CONFIG_H 
-I. -I../../src -I..   -D_FORTIFY_SOURCE=2 -fvisibility=hidden 
-I/usr/include/pixman-1 -I/usr/include/libdrm -I/usr/include/xorg 
-I/usr/include/X11/dri  -Wall -Wpointer-arith -Wmissing-declarations -Wformat=2 
-Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Wbad-function-cast 
-Wold-style-definition -Wdeclaration-after-statement -Wunused -Wuninitialized 
-Wshadow -Wmissing-noreturn -Wmissing-format-attribute -Wredundant-decls 
-Wlogical-op -Werror=implicit -Werror=nonnull -Werror=init-self -Werror=main 
-Werror=missing-braces -Werror=sequence-point -Werror=return-type 
-Werror=trigraphs -Werror=array-bounds -Werror=write-strings -Werror=address 
-Werror=int-to-pointer-cast -Werror=pointer-to-int-cast -fno-strict-aliasing  
-g -O2 -fstack-protector-strong -Wformat -Werror=format-security -c -o 
smi_501.lo ../../src/smi_501.c
libtool: compile:  gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../../src -I.. 
-D_FORTIFY_SOURCE=2 -fvisibility=hidden -I/usr/include/pixman-1 
-I/usr/include/libdrm -I/usr/include/xorg -I/usr/include/X11/dri -Wall 
-Wpointer-arith -Wmissing-declarations -Wformat=2 -Wstrict-prototypes 
-Wmissing-prototypes -Wnested-externs -Wbad-function-cast 
-Wold-style-definition -Wdeclaration-after-statement -Wunused -Wuninitialized 
-Wshadow -Wmissing-noreturn -Wmissing-format-attribute -Wredundant-decls 
-Wlogical-op -Werror=implicit -Werror=nonnull -Werror=init-self -Werror=main 
-Werror=missing-braces -Werror=sequence-point -Werror=return-type 
-Werror=trigraphs -Werror=array-bounds -Werror=write-strings -Werror=address 
-Werror=int-to-pointer-cast -Werror=pointer-to-int-cast -fno-strict-aliasing -g 
-O2 -fstack-protector-strong -Wformat -Werror=format-security -c 
../../src/smi_501.c  -fPIC -DPIC -o .libs/smi_501.o
In file included from ../../src/smi.h:317:0,
  from ../../src/smi_501.c:33:
../../src/regsmi.h: In function 'VGAIN8_INDEX':
../../src/regsmi.h:67:2: error: implicit declaration of function 'outb' 
[-Werror=implicit-function-declaration]
   outb(pSmi-PIOBase + indexPort, index);
   ^
../../src/regsmi.h:67:2: warning: nested extern declaration of 'outb' 
[-Wnested-externs]
../../src/regsmi.h:68:2: error: implicit declaration of function 'inb' 
[-Werror=implicit-function-declaration]
   return(inb(pSmi-PIOBase + dataPort));
   ^
../../src/regsmi.h:68:2: warning: nested extern declaration of 'inb' 
[-Wnested-externs]
cc1: some warnings being treated as errors



Further investigation (see 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785491) showed that 
the reason for the FTBFS was the removal of non-functional stub 
implementations of those functions from xorg.


I belive the out of date binary should be removed from sid for the 
following reasons.


1: it's uninstallable with the xorg currently in sid/stretch
2: while I have not investigated throughly it seems very likely that the 
use of stub versions of those functions would have rendered the driver 
unusable.
3: the siliconmotion chips in question seem to be obsolete parts mostly 
used for onboard graphics in old systems (though I did find one 
industrial minipcie card that claimed to use a siliconmotion chip, dunno 
if it's one supported by this driver). It seems unlikely that one would 
end up in an arm64 system.


If this removal request is actioned I will downgrade bug 785491


--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/555bda04.30...@p10link.net

arm64 porterboxes

[peter green]

In order to answer a query on the xserver-xorg-video-siliconmotion bug 
report I tried to log into asachi.debian.org and got



plugwash@debian:~$ ssh asachi.debian.org
ssh: connect to host asachi.debian.org port 22: No route to host
plugwash@debian:~$

The traceroute would seem to indicate that the problem is at or near the 
server end.


traceroute to asachi.debian.org (64.28.108.84), 30 hops max, 60 byte packets
 1  192.168.1.1 (192.168.1.1)  12.045 ms  12.033 ms  12.016 ms
 2  * * *
 3  0278095e.bb.sky.com (2.120.9.94)  26.176 ms  26.178 ms  26.170 ms
 4  ae51.edge6.London1.Level3.net (212.113.9.53)  26.160 ms  26.129 ms  
26.117 ms
 5  ae-0-11.bar1.Houston1.Level3.net (4.69.137.133)  115.703 ms  
114.634 ms  115.686 ms
 6  ONRAMP-ACCE.bar1.Houston1.Level3.net (4.34.204.186)  121.314 ms  
120.535 ms  120.532 ms

 7  216.109.208.18 (216.109.208.18)  131.140 ms  131.064 ms  131.052 ms
 8  onr108-84.onr.com (64.28.108.84)  130.981 ms  130.990 ms  130.979 ms
 9  onr108-84.onr.com (64.28.108.84)  3128.088 ms !H  3039.879 ms !H  
3038.847 ms !H

plugwash@debian:~$

So I then tried turfan I was able to log in but I got.

Could not chdir to home directory /home/plugwash: No such file or directory

And there was no info in the motd about chroots etc. Are things just 
handled manually on that box?



--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5557f284.7050...@p10link.net

Re: Guide to getting ported?

[peter green]

On 01/05/15 18:32, Paul Wise wrote:

On Fri, May 1, 2015 at 6:07 PM, Wookey wrote:

   

Sarting off by saying in this doc 'Host' is 'BUILD' and 'Target' is
'HOST' seems like a great way to add to the confusion :-)
 

Fixed.
   

I don't see the edit fixing it. did you forget to save?

Assuming that the dpkg-architecture variables are likely to get a
mention in any such discussion it seems sensible to just use the GNU
(and thus Debian) DEB_BUILD_ARCH and DEB_HOST_ARCH and DEB_TARGET_ARCH
terminology and explain that, rather than introducing a different one.
 

Does DEB_TARGET_ARCH actually exist?
   

Looks like it:

https://wiki.debian.org/MultiarchCrossToolchainBuild#Multiarch_Cross_Toolchain_Build


--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/554406d0.2020...@p10link.net

chromium on arm (was: About Jessie and missing packages)

[peter green]

On Mon, Mar 30, 2015 at 1:21 AM, Umut KARCI master.rep...@gmail.com 
mailto:master.rep...@gmail.com wrote:



   I'm very grateful for your work on raspbian, I've been using it
   since the first pi. But currently I'm having a problem. I've
   upgraded to Jessie lately. Since yesterday, I can't install chromium
   browser, I checked mirrors and main repo, source packages are there
   but no deb packages.

Debian dropped arm support from their chromium packages because I 
couldn't get it to work when built with the toolchain Debian had at the 
time (this was in wheezy) and noone else was stepping up to fix it 
either. It was crashing and I was unable to get a usable backtrace from 
the crash.


See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=696909 for more 
information on the many issues we had trying to keep chromium working on 
armhf.


raspbian wheezy continues to ship the last chromium package I managed to 
make work. We are not currently shipping a chromium package in raspbian 
jessie. I don't recall exactly why I removed it but I think that the old 
version of chromium was no longer compatible with new library versions 
or something like that.


If there is to be a supported chromium package in raspbian going forward 
it needs to be dealt with on the Debian side first. Unfortunately 
chromium seems to be the package from hell.


It looks like since that time that the Debian chromium maintainers have 
tried to reenable armhf support on two occasions (in versions 
28.0.1500.71-1 and 29.0.1547.57-3+exp1) but in both cases the package 
failed to build. ccing the chromium maintainers to see if they have any 
comments.

Are you recompiling jessie packages for better armv7 support?
The whole point of raspbian is to provide support for armv6. If you want 
armv7 optimised packages use Debian armhf.

Re: Question about build box hardware

[peter green]

On 02/03/15 19:02, Lennart Sorensen wrote:

Well I was seeing a ton of crashes building openjdk (it rarely survived
it), and ceph, when running 3.14 linaro kernel on the arndale-octa.
With 3.19 plain release kernel, I have built openjdk, ceph and others
a number of times (even did 3 builds of openjdk in parallel to abuse
it) and have had no crashes at all.  So perhaps something in 3.14 was
unstable (and could still be true in 3.16) for some are systems, that
3.19 has fixed.  I don't know which kernel the jessie builders are
currently running.
   
Assuming you mean the raspbian jessie autobuilders they are currently 
running a 3.17 kernel from Debian experimental. I tried Debian 3.18 but 
had issues with udev not working. IIRC wheezy's version refused to start 
while jessie/sid's version claimed to start successfully but didn't 
actually populate /dev .






--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54f506fb.1090...@p10link.net

Re: Question about build box hardware

[peter green]

On 27/02/15 15:27, Lennart Sorensen wrote:

I believe raspian has managed failly well with an army of imx53qsb
systems, with 1GB ram and single core, but quite a lot of them.
   
Both Debian armhf and raspbian used those boards successfully during the 
wheezy release cycles, they coped in sufficient quantities (I think 
debian had 7, raspbian has 8) but some builds (e.g. many webkit 
variants) spent literally days in swap hell and at least one (pypy) 
outright refused to build because of the low ram.


The original model of the imx53 quickstart board had the problem that it 
needed a button push to turn it on, the later R model with a different 
PMIC boots at power on (yay) but will not supply power the USB port when 
running a Debian wheezy kernel (it did work when running the freescale 
kernel, I haven't tested with a post-wheezy Debian kernel).


In raspbian we are currently still building wheezy updates on the imx53 
boards (I was meaning to move it over to the new infrastructure 
alongside jessie but haven't got round to it) but are building jessie 
stuff on quad core imx6 machines with 2GB of ram. For stuff like webkit 
the difference is night and day.


AIUI Debian stuck with the mx53 boards through much of the jessie cycle 
before replacing them fairly recently with some donated marvell boards 
(which I don't think are readilly available to us plebs), not sure if 
any of the IMX53 boards are still in use by Debian.



When they
started that was one of the cheapest and easiest to get systems with
1GB ram.  And some of us other debian arm users were recommending them. :)
Indeed, at the time the two main choices I was aware of that were 
reasonablly affordable and had 1GB of ram were the pandaboard and the 
imx53 quickstart board.


I was told at the time by people I trusted that ubuntu were having big 
problems with USB relibaility on the pandaboard. I understand these 
issues were later traced to a kernel bug but by that time our descision 
was long made.


Of course I would not reccomend either the IMX53 quickstart board or the 
pandaboard to someone starting now. The bang per buck is TERRIBLE by 
current standards.



Now a cubox-i4 might not be a bad choice either.  4 core Cortex-A9 with
2GB ram and SATA (something the arndale-octa does not have, it only has
onboard eMMC and a uSD slot, as well as a USB3 port).
AIUI That is substantially the same as the wandboard quads and 
nitrogen6x we use for raspbian jessie, just in a different form factor.


Those boards haven't been too bad in general with us. We have been 
having some crashes during iceweasel builds (strangely it very rarely 
crashes when building anything else but has a high probability of 
crashing when building iceweasel) but I have my suspiscions that those 
may be more down to btrfs than to our choice of board.



  Certainly the
quad A15 is faster than the quad A9, so the arndale is probably still
a faster compile system.
   
I would expect you are right, USB3 makes me nervous not so much because 
of performance as because USB in general does not see to be a 
particulally dependable storage interface (for example I have USB3 hard 
drives from a major hard drive vendor where mearly touching the cable 
gently will cause a dropout, this tells me something about how seriously 
the vendors take reliability on their USB products).



--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54f3991b.4030...@p10link.net

Re: Expanding memory of an armel device?

[peter green]

On 27/02/15 00:26, Paul Wise wrote:

On Thu, 2015-02-26 at 23:47 +, peter green wrote:

   

Umm the odriod C1 and the raspberry Pi 2 model B (there is no raspberry
pi 2 model A currently, this may or may not change in future) both have
1GB of ram.
 

Bah, was mislead by the wiki pages. Fixed the FreedomBox one. The RPi2
Wikipedia page redirects to RPi and mediawiki didn't change the URL so I
didn't notice. Could you followup on the list?
   
Yeah, I meant to send my previous mail to the list but accidently sent 
it to you privately, i've sent it to the list now.

Also they both lack SATA, so for NAS-type use i'd be looking more
towards something like the cubieboards
 

Good point, could you followup on the list? Especially if there any NAS
form-factor or plug-computer form-factor devices with Cubie stuff.
   
AIUI The cubietruck comes with plexiglass covers which can mount a 2.5 
inch HDD. If you want full enclosure (the covers cover the top and 
bottom but not the sides) then those seem to be available too.



--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54efc148.8010...@p10link.net

Re: Expanding memory of an armel device?

[peter green]

On 26/02/15 13:29, Paul Wise wrote:

There appear to be PCIe SSDs but I and others couldn't find any PCIe
RAM,
   
People have successfully set up swap on graphics cards in the past, I 
don't know how feasible that is with modern cards though (I guess they 
are now using a windowing system or so to avoid taking up too much 
address space).



there appears to be a gap in the market.


You can get FPGAs with PCIe and memory interfaces and i'm sure you could 
program one to make the memory visible on the PCIe bus but the cost 
would be dispropotionate to the benefit. To do this efficiently would 
really need a dedicated PCIe to DDR3 chip and I don't think there is 
enough of a market to support that.




--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54ef70c1.5060...@p10link.net

Re: Expanding memory of an armel device?

[peter green]

On 26/02/15 22:58, Paul Wise wrote:

I think this is what it comes down to, any hardware method to increase
the RAM of such an old machine is probably going to cost more than
just upgrading to a more recent board like the RPi2 (256MB/512MB/1GB)
or ODroid C1 (2GB).


Umm the odriod C1 and the raspberry Pi 2 model B (there is no raspberry pi 2 
model A currently, this may or may not change in future) both have 1GB of ram.

Also they both lack SATA, so for NAS-type use i'd be looking more towards 
something like the cubieboards


--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54efbe18.5060...@p10link.net

Re: Question about build box hardware

[peter green]

On 27/02/15 00:44, Stephen Paul Weber wrote:
Storage interfaces can also be an issue. USB is ubiquitous on arm 
boards but the implementations can be shaky and this has made me wary


Do you need a lot of on-device storage all at once?  With gigabit 
ethernet, having an on-LAN mirror + NAS for storing results might work 
as long as there's enough space to build the current task?  Or, I may 
be missing something.


You will want a few gigabytes of swap (2GB of ram may be enough to build 
stuff in less than a day, it's not enough to build stuff without 
swapping, IIRC I have 5GB of swap configured on the raspbian 
autobuilders though that may be overkill). You also need space for the 
build chroot and the build tree inside it which can easilly reach into 
the gigabytes (I looked at a libreoffice build and it was over 5GB, it 
wouldn't surprise me if there is some stuff that goes beyond 10GB though 
I can't name any offhand). Ideally the build chroot should also be 
restored to a clean snapshot after each build.


In raspbian we use local HDDs with btrfs snapshots for this*, I think 
Debian uses LVM snapshots HDDs on some buildds and SSDs on others but 
i'm not positive on that.


I would not want to put this kind of thing on SD cards, USB sticks, etc 
because of the heavy write load which these devices are simply not 
designed for.


Putting it on some kind of networked storage (I've wondered about 
exporting ramdrives over NBD from a large-ram x86 box in the past and 
using them as swap on arm boards but i've never actually tried it) may 
be an option on boards that have fast network but I have not tried such 
setups.


* Though if I had to start from scratch I suspect I would go for the 
(less space efficient) lvm snapshots instead. I suspect some of the 
build failures we get in raspbian are a result of our btrfs use.



--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54efc920.6070...@p10link.net

ccing bug reports to debian-arm (was: Bug#778898: FTBFS on arm64)

[peter green]

On 21/02/15 13:53, Chen Baozi wrote:

Add dh-autoreconf to build-dep to fix FTBFS on arm64
   
I can understand ccing bug reports that are complex and need more eyes 
to debian-arm, I do it myself occasionally but I don't think it's 
nessacery or productive to cc debian-arm on trivial buildsystem fixes 
like this.



--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54e89b1c.30...@p10link.net

Re: Bug#764732: gcc-4.9: broken -O2 optimizations on armhf

[peter green]

Matthias Klose wrote:

there exist several workarounds for it (lowering the
optimization, using gcc-4.8, ...). 
Disabling stack protector also seems to result in a succesful compile 
(reducing it from strong to regular does not).



--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/549cdaf0.4000...@p10link.net

Re: Bug#764732: gcc-4.9: broken -O2 optimizations on armhf

[peter green]

peter green wrote:

Matthias Klose wrote:

there exist several workarounds for it (lowering the
optimization, using gcc-4.8, ...). 
Disabling stack protector also seems to result in a succesful compile 
(reducing it from strong to regular does not).

And another workaround is to use -marm.



--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/549cdc99.6010...@p10link.net

issues with experimental kernels on imx6 based boards.

[peter green]

I have some imx6 based boards which work as autobuilders for raspbian. I 
use btrfs for efficient snapshotting and have had some issues (crashes, 
weird filesystem errors) which I suspect are down to btrfs. As such i've 
been frequently upgradeing the kernel to the latest versions from 
experimental in the hope that the issues will be fixed upstream.


There are a total of six boards. Five wandboard quads (one hosted at my 
flat, four hosted at bytemark), and one nitrogen6x, the wandboard quads 
are running a mostly wheezy system while the nitrogen6x is running a 
mostly jessie system.


On all the systems the boot files and ext4 root filesystem is on a micro 
SD card while a hard drive is used for buildd related stuff (btrfs) and 
swap. The wandboards have a seperate ext2 boot partition while the 
nitrogen6x has /boot on the root partition.


Currently there are (among others) the following kernels installed on 
the boards.


linux-image-3.16-trunk-armmp version 3.16-1~exp1
linux-image-3.17-1-armmp version 3.17-1~exp1
linux-image-3.18.0-trunk-armmp version 3.18-1~exp1

linux-image-3.16-trunk-armmp seemed to work ok without any tweaking.
linux-image-3.17-1-armmp seemed to work ok without any tweaking on the 
wandboard quads but it failed to boot with a timeout waiting for rootfs. 
I was able to get it to boot by doing lsmod | cut -d ' ' -f 1  
/etc/initramfs-tools/modules (while running 3.16) and then rebuilding 
the initrd for 3.17, i'll try to investigate further whether this is 
reproducable with later versions of initramfs-tools and if-so what 
modules exactly are missing.
linux-image-3.18.0-trunk-armmp, this failed on the nitrogen6x in the 
same way as 3.17, I haven't debugged that issue further yet. On the 
wandboard quad it booted but /dev was nearly empty and udev was failing 
to start, I tried upgrading udev first to the wheezy-backports version 
and then to the jessie version but while udev claimed to start 
successfully it still didn't seem to actually start managing /dev.  Is 
anyone aware of any udev incompatibilities with 3.18?




--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54975d0d.1060...@p10link.net

swp on armv8 (Was: Haskell on arm needs help)

[peter green]

Joachim Breitner wrote:

Hi,

Am Mittwoch, den 03.12.2014, 23:02 +0100 schrieb Joachim Breitner:
  

Trying to use it, but ghc fails to install in the schroot, and using
just dd-schroot-cmd, I cannot debug this. Does installing ghc work
properly for you?

$ dd-schroot-cmd -c  ghc apt-get install ghc
Reading package lists...
Building dependency tree...
Reading state information...
ghc is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 15 not upgraded.
1 not fully installed or removed.
Conf ghc (7.6.3-20 Debian:unstable [armhf])
Do it for real [Y/n]: 
Reading package lists...

Building dependency tree...
Reading state information...
ghc is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 15 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Download complete and in download only mode
Reading package lists...
Building dependency tree...
Reading state information...
ghc is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 15 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Setting up ghc (7.6.3-20) ...
Illegal instruction
Illegal instruction
dpkg: error processing package ghc (--configure):
 subprocess installed post-installation script returned error exit status 132
Errors were encountered while processing:
 ghc
E: Sub-process /usr/bin/dpkg returned an error code (1)
Command apt-get --assume-yes -o Dpkg::Options::=--force-confnew install -- ghc 
exited with exit code 1.



there is more things strage with this machine. The above was the sid
schroot (presuambly arm64).
I think the default chroot arch follows the userland arch of the outer 
system and the outer system on asachi is armhf.


I can confirm that on asachi ghc fails to install in the armhf chroot, 
installs but fails to run in the armel chroot and installs and runs in 
the arm64 chroot.



 On the armel chroot on that machine I can
install ghc, but cannot run it successfully:

~/ghc-7.8.20141119 $ ghc
Illegal instruction
~/ghc-7.8.20141119 $ ghc --version
Illegal instruction

(This is calling the ghc from the package from unstable.)


  
I vaugely remember something a while back about some deprecated 32-bit 
arm instructions needing kernel emulation on armv8 and that emulation 
not being implemented yet.


After some fighting with gdb I got

(sid_armel-dchroot)plugwash@asachi:~$ gdb /usr/lib/ghc/lib/ghc
--snip gdb startup--
Reading symbols from /usr/lib/ghc/lib/ghc...(no debugging symbols 
found)...done.

(gdb) run
Starting program: /usr/lib/ghc/lib/ghc
Cannot access memory at address 0x0
[Thread debugging using libthread_db enabled]
Using host libthread_db library /lib/arm-linux-gnueabi/libthread_db.so.1.

Program received signal SIGILL, Illegal instruction.
0x02921958 in ?? ()
(gdb)
--snip fighting with gdb--
(gdb) disassemble 0x02921958,0x02921962
Dump of assembler code from 0x2921958 to 0x2921962:
= 0x02921958:  swp r3, r4, [r5]
  0x0292195c:  cmp r3, #0
  0x02921960:  beq 0x292197c
End of assembler dump.
(gdb)

swp has been deprecated for a while, armhf binaries should really avoid 
using it but sadly other than runtime CPU detection i'm not sure there 
is much choice for armel.


AIUI swp is already handled through kernel emulation on armv7 
multiprocessor systems. There seem to be patches to port that emulation 
to arm64 but it doesn't appear they are in the kernel tree debian is 
using. Having 32-bit binaries break on armv8 systems due to lack of the 
swp instruction does not seem like a good thing so IMO we really want 
this in our kernels before release.


Putting debian-arm back in cc and adding debian-kernel to cc to 
hopefully get some comments from people more knowlagable,




Should I use a different machine to debug armel build failures? Or is
ghc in unstable (and hence testing) that broken on armel?
Theres a few armv7 porterboxes available though with lower resources 
than asachi


abel.debian.org (I think this is the best resourced one)
harris.debian.org
ipa.debian.net (non-dsa)



--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/547f9b7d.6080...@p10link.net

armv7 builds leaking into armel

[peter green]

I just filed a couple of bugs about packages whose build systems are 
building for armv7 on armel[1][2].


While doing so I also noticed that openmpi also seems to have similar 
problems but that case is more complex and I don't have the time/energy 
to investigate it right now. We have a patch in raspbian[3] but it needs 
some work to figure out what should be done in Debian.


The two issues mentioned above were using armv7 cflags unconditionally 
on all arm architctures but i've also come across ones in the past that 
use armv7 cflags only if the system they are being built on is armv7 
[4]. Since Debian recently switched to armv7 autobuilders for armel it 
is likely that Debian has latent issues of this type.


For the most part armv7 binaries can be detected using readelf. It does 
suffer from some false positives (runtime cpu detection etc) and false 
negatives (jit compilers etc) but it should be sufficient to discover 
most issues.


In Raspbian we run all packages we build through a check that unpacks 
them and runs readelf[5]. I try to push issues I detect this way back up 
to Debian but I sometimes forget and there are some less clear cut cases 
that I don't have the time to triage (for example with neon related ones 
there may or may not be runtime detection, in raspbian I just tend to 
disable neon completely but that may not be appropriate for Debian). I 
don't think Debian armel should be relying on Raspbian to find these issues.


Anyone here who cares about armel fancy putting something together to 
check the armel archive for armv7 binaries? or are we just going to 
leave them arround until some user gets the illegal instruction error?


[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770782
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770793
[3] http://debdiffs.raspbian.org/main/o/openmpi/openmpi_1.6.5-8+rpi1.debdiff
[4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=719355
[5] https://lists.debian.org/debian-arm/2013/05/msg00154.html


--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5472b18c.2050...@p10link.net

Haskell on arm needs help (was: hledger and hledger-web packages for raspbian)

[peter green]

oops, forgot to actually cc debian-arm

Readers on debian-arm and raspbian-devel, see
https://lists.debian.org/debian-haskell/2014/11/msg00024.html if you
want more context.

Joachim Breitner wrote:

There was some support for ghci on arm, but it wasn’t working
well and disabled it in Debian in 7.6.3:

  * Disable GHCi on arm, as it is severly borken (for more information see
http://hackage.haskell.org/trac/ghc/ticket/7794)

Maybe things have improved in 7.8 (currently in experimental). We could
use some manpower dedicated to testing this, hunting down upstream
patches and trying them out. Unfortunately, the current 7.8 package does
not even build on arm:
https://buildd.debian.org/status/package.php?p=ghcsuite=experimental
and every developer trying to fix it gave up, mostly because the long
build times make it so annoying.
  

You might find asachi.debian.org useful, it's an APM x-gene mustang with
8 64-bit cores. Not sure of the clockspeed but i'm fairly sure it's
high. The box has armel, armhf and arm64 chroots available for use.


Maybe there are people out there in the Raspbian community who care for
ghc (not just ghci!) on arm and would like to fix these problems before
they migrate to Raspbian? You’d be welcome to join the Debian Haskell
Group!
  

Well it won't be me, I don't know haskell and I don't have the
time/inclination to learn it.

Sending this to debian-arm and raspbian-devel to see if anyone there can
help out.


--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/546fb852.4070...@p10link.net

arm64 box under $1K for developers in the USA

[peter green]

I just saw an advert on LWN which people here might find interesting. It 
looks like apm have reduced the price of their box to $1495 and are 
offering a developer special at $895.


Still more than i'm personally willing to pay and it looks like the 
offer is US only (for non-us customers they point to avnet who still 
seem to be quoting a price of about $3K)


https://www.apm.com/products/data-center/x-gene-family/x-c1-development-kits/x-c1-development-kit-basic/



--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54681850.4030...@p10link.net

Re: State of arm64 in testing.

[peter green]

peter green wrote:
gadmin-openvpn-client0.1.2-4unsatisfied dependency on 
openvpn   gadmin-openvpn-client-dbg0.1.2-4unsatisfied 
dependency on openvpn   gadmin-openvpn-server0.1.5-3.1
unsatisfied dependency on openvpn   gadmin-openvpn-server-dbg
0.1.5-3.1unsatisfied dependency on openvpn
openvpn-auth-ldap2.0.3-6.1unsatisfied dependency on openvpn 
(= 2)   openvpn-auth-radius2.1-6+b1unsatisfied dependency on 
openvpn (= 2)   openvpn-auth-radius-dbg2.1-6+b1unsatisfied 
dependency on openvpn (= 2)


openvpn has been binnmu'd in tpu, hopefully it will show up as fixed 
after the next run.

The binnmu has made it successfully into testing fixing these.


gnome-core-devel1:3.8+8unsatisfied dependency on 
libseed-gtk3-dev (= 3.2)


The release team have told me this will be fixed by dropping the 
depedendency

Dependency has been dropped in sid and unblocked, waiting for it to migrate.


tcos-core0.89.93unsatisfied dependency on xtightvncviewer

tightvnc is fixed in sid, an unblock request has been filed with the 
release team.

The fixed tightvnc has now migrated to testing making tcos-core installable.


xfce4-goodies4.1unsatisfied dependency on xfce4-battery-plugin

This has been fixed in sid but afaict an unblock request has not yet 
been filed, i'll probablly do so in a day or two if noone else gets 
there first.
xfce4-battery-plugin migrated, unfortunately it turns out it wasn't the 
only thing making xfce4-goodies uninstallable. We now have


xfce4-goodies4.1unsatisfied dependency on xfce4-notes-plugin

I'm investigating this now and will file a bug later, hopefully with a 
patch.


snort2.9.7.0-3unsatisfied dependency on libdaq0   
snort-common-libraries2.9.7.0-3unsatisfied dependency on libdaq0


These have just appeared due to the migration of a new version of 
snort to testing, I suspect a TPU binnmu of daq is the appropriate 
response, again i'll probablly request it in a day or so if noone else 
does so first.
I investigated this in more detail and it was messier than this and the 
mess wasn't really arm64 specific, see the thread starting with 
https://lists.debian.org/debian-release/2014/11/msg00339.html for more 
details.



--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/546117a3.1010...@p10link.net

Re: State of arm64 in testing.

[peter green]

peter green wrote:

peter green wrote:
I've been looking at the list 
(https://qa.debian.org/dose/debcheck/testing_main/1413608403/arm64.html) 
of uninstallable packages in arm64 testing focussing on packages that 
are arch specific (since AIUI current de-facto policy is it's 
acceptable for arch all packages to be uninstallable but unacceptable 
for arch specific packages to be uninstallable).
Time for an update. the stiaution has imrpoved massively but we still 
have some ways to go to get the list of uninstallable arch specific 
binaries down to 0
Getting very close now. The remaining arch specific entries on the dose 
page are (i'm pretty sure this is correct, unfortunately the dose pages 
don't allow filtering to arch specific packages making it difficult to 
be positive)


gadmin-openvpn-client0.1.2-4unsatisfied dependency on openvpn   
gadmin-openvpn-client-dbg0.1.2-4unsatisfied dependency on 
openvpn   
gadmin-openvpn-server0.1.5-3.1unsatisfied dependency on openvpn   
gadmin-openvpn-server-dbg0.1.5-3.1unsatisfied dependency on openvpn
openvpn-auth-ldap2.0.3-6.1unsatisfied dependency on openvpn (= 
2)   
openvpn-auth-radius2.1-6+b1unsatisfied dependency on openvpn (= 
2)   
openvpn-auth-radius-dbg2.1-6+b1unsatisfied dependency on openvpn 
(= 2)


openvpn has been binnmu'd in tpu, hopefully it will show up as fixed 
after the next run.


gnome-core-devel1:3.8+8unsatisfied dependency on 
libseed-gtk3-dev (= 3.2)


The release team have told me this will be fixed by dropping the 
depedendency


tcos-core0.89.93unsatisfied dependency on xtightvncviewer

tightvnc is fixed in sid, an unblock request has been filed with the 
release team.


xfce4-goodies4.1unsatisfied dependency on xfce4-battery-plugin

This has been fixed in sid but afaict an unblock request has not yet 
been filed, i'll probablly do so in a day or two if noone else gets 
there first.


snort2.9.7.0-3unsatisfied dependency on libdaq0   
snort-common-libraries2.9.7.0-3unsatisfied dependency on libdaq0


These have just appeared due to the migration of a new version of snort 
to testing, I suspect a TPU binnmu of daq is the appropriate response, 
again i'll probablly request it in a day or so if noone else does so first.




--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54597619.9020...@p10link.net

Bug#767439: python-zmq FTBFS on official arm64 arm-arm autobuilders.

[peter green]

Package: python-zmq
Version: 14.3.1-1
Severity: important
User: debian-arm@lists.debian.org
Usertags: arm64
x-debbugs-cc: debian-arm@lists.debian.org

Python-zmq (versions 14.3.1-1 and 14.4.0-1) FTBFS on the official 
arm-arm arm64 autobuilders. The same versions succeeded on the 
debian-ports arm64 autobuilder turfan. The arm-linaro official arm64 
autobuilders have never tried to build the package.


The failure takes the form of a test failure

Test connected monitoring socket. ... Assertion failed: pfd.revents  POLLIN 
(signaler.cpp:193)
Aborted
E: pybuild pybuild:256: test: plugin distutils failed with: exit code=134: cd /«PKGBUILDDIR»/.pybuild/pythonX.Y-dbg_3.4/build; python3.4-dbg -m unittest discover -v 
dh_auto_test: pybuild --test -i python{version}-dbg -p 3.4 --dir . returned exit code 13

debian/rules:51: recipe for target 'override_dh_auto_test' failed

Anyone have any thoughts?


This failure is making one arch specific package and a number of arch all 
packages uninstallable in arm64 testing.


--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5452ef1a.2080...@p10link.net

Re: State of arm64 in testing.

[peter green]

peter green wrote:
I've been looking at the list 
(https://qa.debian.org/dose/debcheck/testing_main/1413608403/arm64.html) 
of uninstallable packages in arm64 testing focussing on packages that 
are arch specific (since AIUI current de-facto policy is it's 
acceptable for arch all packages to be uninstallable but unacceptable 
for arch specific packages to be uninstallable).
Time for an update. the stiaution has imrpoved massively but we still 
have some ways to go to get the list of uninstallable arch specific 
binaries down to 0


1: gcc-4.9/binutils: gcc-4.9 picked up a tighter binutils dependency 
on arm64 than on other architectures. Unfortunately this means it's 
not installable with the binutils currently in jessie. Binutils has 
not been migrating to jessie due to frequent uploads.

Binutils has now finally migrated to testing :).
2: gcc-defaults: gcc-defaults has not been migrating to jessie for a 
while due to depdency issues on kfreebsd. It was binnmu'd successfully 
in arm64 tpu and that binnmu migrated (I suspect it was forced but I 
don't know for sure) to testing but unfortunately several of the 
binary packages built from gcc-defaults are not binnmu safe and are 
hence uninstallable.
This has apparently just migrated, it will take some time for the dose 
pages to update to reflect that.
3: many dependencies sitting in needs-build: hopefully the extra 
autobuilders that have just come online will help with that.

This is no longer an issue.
4: notify-python, wookey bugrepped this about 6 days ago, probablly 
about time to turn that bugrep into a NMU.

hippo-canvas: also seems to need a NMU for config.sub/guess issues.
dvdauthor: also seems to need a NMU for config.sub/guess issues. 

Theese are fixed in sid but waiting for migration to testing.


Other packages that need to be dealt with

cython: blocked from migrating to testing by build failures on armel 
(testsuite failure) and mips (timeout). May be a candiate for a TPU 
binnmu later (probablly not the right time to do it yet)
seed: blocked from migration to testing by build failures on mips, 
powerpc and s390x)

These two are still outstanding


tightvnc: also seems to need a NMU for config.sub/guess issues.
As wookey pointed out I misdiagnosed this before, i'm now taking a more 
detailed look.


New issues/concerns

gnat-4.9: needs to migrate to testing and for that it needs to be built 
on mips, it's been sitting in needs-build on mips for a worryingly long 
time.

vinagre: waiting for migration to testing
plplot: appears to be blocked from migrating to testing by gnat-4.9 (see 
above)
haskell: I think this may just need some time to settle after binutils 
got in, needs keeping an eye on over the next few days.
magics++: weird issue relating to -data package but a new versions 
migrating from unstable soon, hopefully that will fix things
xfce4-battery-plugin: needs a small fix for arm64, sledge posted a 
bugrep a few days ago, probablly wait a couple more days then NMU if 
there is no maintainer response.



--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/545018f6.7070...@p10link.net