Re: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64

[Riku Voipio]

On Mon, Nov 26, 2018 at 12:37:57PM +0100, Raphael Hertzog wrote:
> were in the week-end). I was aware of the discussion but did not
> had the time to chime in, yet I was the person who re-opened the bug
> #881333 in the first place.
 
> I also invited someone else who is working on a concrete project involving
> Kali Linux (Debian derivative) and off-the-shelf arm64 hardware available
> now but he also did not have the time to contribute to the discussion.

> Software can be fixed/improved to also work with OpenGL ES. However
> hardware, once bought, cannot be fixed to support Desktop OpenGL
> when it has been designed for OpenGL ES only.

Reading from #881333 you mean Gemini PDA. It comes with Mediatek X27,
featuring Mali-T880. The hardware is not OpenGL ES only .. the
propiertary driver is. Mesa-based panfrost driver should support both
OpenGL and OpenGL ES:

https://gitlab.freedesktop.org/panfrost

The open source driver is of course not ready... ...but neither is
Debian ES 2.0. In the long run, making the driver ready is time better
spent than time spent trying to make Debian more friendly to a class
of propiertary drivers.

Riku

Re: Upcoming Qt switch to OpenGL ES on arm64

[Riku Voipio]

On Thu, Nov 22, 2018 at 07:14:44PM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> El jueves, 22 de noviembre de 2018 18:30:39 -03 Marcin Juszkiewicz escribió:
> > Does it mean that arm64 box with PCI Express graphics card will be not
> > able to use Qt based software? I can put Radeon or NVidia card into my
> > box and use it as a normal OpenGL accelerated desktop (did that already
> > few years ago).

> "Depends". The change is only for software using some specific classes inside 
> libqt5gui5. If your video card supports GLES (aka OpenGL ES) then you should 
> be fine.

Mesa based nouveau, radeon and freedreno should support both - so the
deskop env itself should work I think.

> The real issue here is that *many* arm64 boards currently do not support 
> Desktop OpenGL, but do support GLES.

The boards may or may not support Desktop GL. As far as debian is
concerned, they remain headless devices until they have free drivers.

See, most of the propiertary GLES drivers are craptastic and don't work
with Debians kernel. Even ff you manage to dance the right kernel, device
tree and userspace combo, you may still not get the desktop enviroment
up. And nobody is going to fix the bugs you encounter.

Debian does support Qualcomm based boards with freedreno driver, and
work is progressing with etnaviv for Vivante. Both based on Mesa and
support both OpenGL and GLES. With the MALI reverse engineering active
again, it would seem rather short-sighted and counterproductive to
put lots of energy in supporting the propiertary drivers.

> Also applications using GLU[T] or glew will not be able to compile anymore on 
> arm64. GLU[T] has not been ported to GLES, glew somehow differs in a type 
> definition.

I have an Synquacer box with nvidia card running Lxqt desktop, running
fine most tasks. While none of the apps I run on it seem to be of the
Qt + GLU/glew combo, it would be unfortunate if I ever need to use them.

Riku

Re: Arch qualification for buster: call for DSA, Security, toolchain concerns

[Riku Voipio]

On Thu, Jun 28, 2018 at 08:11:14PM +0200, Florian Weimer wrote:
> * Niels Thykier:
> 
> > armel/armhf:
> > 
> >
> >  * Undesirable to keep the hardware running beyond 2020.  armhf VM
> >support uncertain. (DSA)
> >- Source: [DSA Sprint report]
> 
> Fedora is facing an issue running armhf under virtualization on arm64:
> 
>   

I think you mean:

https://bugzilla.redhat.com/show_bug.cgi?id=1576593

>   
> 
> Unless the discussion has moved somewhere where I can't follow it, no
> one seems to have solid idea what is going on. 

True. Looking at comment #22, the suggestion seems to be that the guest is
doing something wrong, and kvm is being terrible at pinpointing the source.

> It's also not clear that this configuration has substantial vendor or
> community support. This makes me concerned that virtualization is a viable
> path forward here.

I understand your concern. It would be surprising if this specific bug doesn't
get found and fixed. It's probably stuck because everyone thinks it's 
probably someone elses bug ;)

I still think the armhf vm on arm64 is the only reasonable path forward medium
term. The existing arm64 hw that suport arm32 vm's is still around and
infinitely better than native aarch32 builder hw, and should still be viable
for some time. 

Riku

Re: [OE-core] SFO17 Cross-Distro meeting notes

[Riku Voipio]

On 29 September 2017 at 21:26, Tom Rini <tr...@konsulko.com> wrote:
> On Fri, Sep 29, 2017 at 02:06:21AM +0300, Riku Voipio wrote:
>
> [snip]
>> On arm64, Kernel doesn't self-decompress. The bootloaders are stringly
>> recommended to support decompressing kernel images. It's optional in
>> grub, make sure your grub does. At least iPXE and u-boot don't support
>> booting Image.gz on arm64, and should be fixed.
>
> Not strictly true.  We do expect that if you're loading in a
> compressed something that you uncompress it then boot it.  I assume part
> of the reason that Linux didn't go for self-decompression this time is
> the "my goodness, it's tricky to get here's where we are, here's what
> else is in the system, lets not stomp anything and get ourself to where
> we need to be" is in fact tricky.

Thanks for the clarification. The kernel
Documentation/arm64/booting.txt is vague in reasoning, but you are
right it's tricky. Kernel developers  assume the bootloader is better
equipped to know where in memory to decompress than a early kernel
decompress loop.

> That said, patches to check for ${VALID_COMPRESSION_HEADER}, uncompress
> a chunk, confirm valid Image header, and uncompress to where it needs to
> reside would be welcome.

While the unzip command hint is good, from cross-distro PoV I think
this kind of transparent decompression is needed to make the syslinux
bootmenu command "just work".

Riku

SFO17 Cross-Distro meeting notes

[Riku Voipio]

= LSE atomics problem =

Large System Extensions, part of ARMv8.1, provides new atomics
instructions. These instructions are essential for high performance
locking when you have lots of cores.

Recommendation: distributions should provide an alternative optimized
glibc with LSE atomics based locks for end users.

= Scalable Vector Extensions =

May have an ABI issue. Situation under investigation.

= Page size =

Don't assume your binaries will always execute in the page size they
were built on. Even if your distribution is built on 4K page size, be
aware that some of your users might opt to run with 64K page size
kernel - for example in containers.

Users be aware, that switching between 4K and 64K kernels may break
some data structures that depend on page size. Swap needs be
reformatted, and btrfs will explode on page size change-

= OCI spec =

With LSE, SVE, armv8.x releases coming, any containers using newer
instructions should be identified in variant field.

= Booting =

One day, booting on arm will be so boring, that nobody will bring it
up on our cross-distribution BoF. That day was not today.

RHEL only supports ACPI on arm64. Even if you are not RHEL, you should
prefer ACPI over device tree, if the former is available.

U-boot can now start EFI binaries, making u-boot an excellent platform
to implement an UEFI bios. This allows single-path installers for
distributions, where install of distribution starts always by loading
grub from EFI.

On arm64, Kernel doesn't self-decompress. The bootloaders are stringly
recommended to support decompressing kernel images. It's optional in
grub, make sure your grub does. At least iPXE and u-boot don't support
booting Image.gz on arm64, and should be fixed.

Riku

ARM Cross-distro BoF at Linaro Connect next week

[Riku Voipio]

Hi,

We'll have the traditional cross-distribution BoF at Linaro connect
Wednesday  27.9, at 3PM US pacific time - 22.00 UTC. We don't have a
set agenda, but if anything is bugging you, replying to this mail is
great way to make it into our topics :)

Riku

Re: CP15 Barrier emulation performance?

[Riku Voipio]

On Tue, Jul 11, 2017 at 09:45:49AM +0100, Ian Campbell wrote:
> On Tue, 2017-07-11 at 08:56 +0100, Edmund Grimley Evans wrote:
> > > Does this emulation take a considerable performance hit, as opposed
> > > to
> > > running on armhf hardware/kernel, where the instruction doesn't
> > > appear
> > > to be listed as deprecated?
> > 
> > I'd expect the kernel-emulated instruction to be much slower than any
> > non-emulated instruction, but the overall effect on performance will,
> > of course, depend on how often the instruction is used.
> > 
> > See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864847 (where I
> > think I claimed that the instruction is deprecated on armhf hardware
> > but I could easily be wrong)

> Deprecated for both ARMv7 and ARMv8 according to the Kconfig help:
> config CP15_BARRIER_EMULATION
> bool "Emulate CP15 Barrier instructions"
> help
>   The CP15 barrier instructions - CP15ISB, CP15DSB, and
>   CP15DMB - are deprecated in ARMv8 (and ARMv7). It is
>   strongly recommended to use the ISB, DSB, and DMB
>   instructions instead.
> 
>   Say Y here to enable software emulation of these
>   instructions for AArch32 userspace code. When this option is
>   enabled, CP15 barrier usage is traced which can help
>   identify software that needs updating.
> 
>   If unsure, say Y
> 
> However I there is a sysctl which allows selecting between "undef",
> "emulated" and "hw" (where the latter is dependent on the hw actually
> supporting the instructions in question). See:
> http://elixir.free-electrons.com/linux/latest/source/Documentation/arm64/legacy_instructions.txt

The ghc sources don't appeart to have direct CP15 instructions, so I suspect
ghc might be calling llvm with options that make it emit CP15 barriers instead
of DMB. Anyways look like a configuration error rather than a coding error.

Riku

Re: CP15 Barrier emulation performance?

[Riku Voipio]

On Wed, Jul 05, 2017 at 12:51:08PM -0700, Vagrant Cascadian wrote:
> Some of the reproducible builds armhf nodes are actually arm64 capable
> machines, running an arm64 kernel build.  When haskell related packages
> get built, I get a tremendous number of messages on to the console:
> 
>   "ghc" (13126) uses deprecated CP15 Barrier instruction at 0xefadd224

Do we have bugreport to make haskell use newer barrier instructions on 
armv7+ ?
 

Riku

Re: arm64: Image vs. Image.gz

[Riku Voipio]

On Wed, Feb 01, 2017 at 01:35:40PM -0800, Vagrant Cascadian wrote:
> So, when building an arm64 linux package using Debian's packaging, it
> builds a package where /boot/vmlinuz-VERSION is uncompressed, and
> bootloaders such as u-boot can boot it with booti.
 
> But when building a mainline kernel with "make bindeb-pkg" it produces a
> package where /boot/vmlinuz-VERSION is compressed with gzip, and
> u-boot's booti fails to boot it. Simply uncompressing the
> /boot/vmlinuz-VERSION then allows u-boot's booti command to work
> properly.

Since it already breaks with "failed magic" error, I think adding support
for detecting gzip magic would not be very hard? 
 
> I seem to recall a similar issue with grub not booting the compressed
> image, but it's been a while since I've tried.

grub has a gzip module, which may or may not get included the grub that 
get installed in grubaa64.efi. We should mae sure it happens.
 
> Are there platforms on arm64 that use Image.gz?
 
> Should upstream default to "Image" instead, or should upstream's
> bindeb-pkg target default arm64 builds to use KBUILD_IMAGE=Image, to be
> consistant with Debian's linux packages?

Personally I'd like to see compressed kernels by default (because they are 
so yuge). But for now, as no bootloader really works out of box with compressed
images, deb-pkg/bindeb-pkg should match what Debian is doing.

Riku

Re: U-boot menu support in Debian

[Riku Voipio]

On Tue, Jan 17, 2017 at 03:59:33PM +, Riku Voipio wrote:
> I guess I'll push it to it's own package, since not all u-boot-tools
> may want a menu.

Done now:
https://tracker.debian.org/pkg/u-boot-menu
 

Re: U-boot menu support in Debian

[Riku Voipio]

On Sun, Jan 15, 2017 at 12:03:05PM -0800, Vagrant Cascadian wrote:
> On 2017-01-05, Riku Voipio wrote:
> > I only recently noticed that Debian doesn't seem use U-boot
> > support for extlinux style boot menus. This makes jumping
> > between kernel versions frustrating.
> >
> > I've taken the old syslinux support for menu generation and
> > re-purposed it for u-boot:
> >
> > https://github.com/suihkulokki/u-boot-update
> 
> Thanks for working on this!
> 
> This would also be good to do for debian-installer images (one concern
> was how widespread support for the "chosen" console was, as there was no
> way to pass the console via extlinux.conf in a platform agnostic way).

I see the console from dtb worksforme, and adding it to missing DTB's should
be easy.
 
> > Note location is temporary, I don't know if this is
> > preferrable as independent package, part of flash-kernel
> > or even u-boot package itself.
 
> Indeed. On the one hand, it'd be nice to keep it outside of
> flash-kernel, so as not to require flash-kernel and it's dependencies.

Rethinking, the only link I get for flash-kernel, is the dtb name / device
model name map which could be used to set the FDT setting.
 
> I could include it in the u-boot-tools package, but I'd want it to
> default to doing nothing out of the box, if someone is relying on a boot
> script this could break their boot configuration. It could also be
> implemented as a separate package and enabled by default; probably too
> late for stretch, though.

I guess I'll push it to it's own package, since not all u-boot-tools
may want a menu.

> I've submitted a pull request that fixes an issue with falling back to
> using "fdtdir" and make the "fdtdir" configurable via a variable to
> improve compatibility with flash-kernel or when /boot is on a separate
> partition:
> 
>   https://github.com/suihkulokki/u-boot-update/pull/1

Thanks, applied.
 
> My workaround was to use flash-kernel to copy the dtb into /boot (which
> I had to do anyways, since /boot was on a separate partition), and
> configure /boot/dtbs/$VERSION in my patches above.

Yeah, separate /boot doesn't work with DTBs out of box. 

Riku

Re: graphicsmagick/1.3.25-7 build reschedule on armhf

[Riku Voipio]

On Sun, Jan 15, 2017 at 09:06:45PM +0100, László Böszörményi (GCS) wrote:
> Hi,
 
> Back in time the build of GraphicsMagick failed. Later I could build
> it on an armhf porter box and just did the same on a Qemu emulated
> armhf box with a pbuilder setup.
> Please reschedule its build on the official buildds, it seems it will
> build correctly this time.

Give back. Note that Qemu isn't accurate presentation. The errorSIGILL being
consistent on only Webp tests in buildd log[1] might suggest that libwebp is
using NEON instructions. Qemu and most armv7 hardware has NEON support, however 
a
small subset, including our buildd's doesn't support NEON.

For accurate test, run on porter machine abel.debian.org, which is identical to
builders.

Riku

[1] 
https://buildd.debian.org/status/fetch.php?pkg=graphicsmagick=armhf=1.3.25-7=1482683011

U-boot menu support in Debian

[Riku Voipio]

Hi,

I only recently noticed that Debian doesn't seem use U-boot
support for extlinux style boot menus. This makes jumping
between kernel versions frustrating.

I've taken the old syslinux support for menu generation and
re-purposed it for u-boot:

https://github.com/suihkulokki/u-boot-update

Note location is temporary, I don't know if this is
preferrable as independent package, part of flash-kernel
or even u-boot package itself.

Setting this up for Dragonboard 410c is matter of:

# echo U_BOOT_FDT=\"qcom/apq8016-sbc.dtb\" > /etc/default/u-boot

This could be truly platform agnostic by using the 
the "fdtdir" keyword in the menu. However, on u-boot the
fdtfile is "apq8016-sbc.dtb", missing the qcom/ directory
prefix. We need to submit a patch for u-boot to search device
tree from vendor sub-dirs too.

Now that the device tree is set, the only thing to make it work on
any new u-boot with distro_bootcmd set is generating and using the menu:

# u-boot-update 
P: Checking for EXTLINUX directory... found.
P: Writing config for /boot/vmlinuz-4.9.0-rc8-arm64...
P: Writing config for /boot/vmlinuz-4.8.0-rc8-arm64...
P: Writing config for /boot/vmlinuz-4.4.23-linaro-lt-qcom...
P: Updating /boot/extlinux/extlinux.conf...
# reboot 
...
U-Boot 2016.09+dfsg1-1 (Sep 12 2016 - 19:43:29 +)
...
Scanning mmc 0:a...
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
1965 bytes read in 99 ms (18.6 KiB/s)
U-Boot menu
1:  Debian GNU/Linux kernel 4.9.0-rc8-arm64
2:  Debian GNU/Linux kernel 4.9.0-rc8-arm64 (rescue target)
3:  Debian GNU/Linux kernel 4.8.0-rc8-arm64
4:  Debian GNU/Linux kernel 4.8.0-rc8-arm64 (rescue target)
5:  Debian GNU/Linux kernel 4.4.23-linaro-lt-qcom
6:  Debian GNU/Linux kernel 4.4.23-linaro-lt-qcom (rescue target)
Enter choice: 5
5:  Debian GNU/Linux kernel 4.4.23-linaro-lt-qcom
Retrieving file: /boot/initrd.img-4.4.23-linaro-lt-qcom
4658722 bytes read in 596 ms (7.5 MiB/s)
Retrieving file: /boot/vmlinuz-4.4.23-linaro-lt-qcom
13888000 bytes read in 1552 ms (8.5 MiB/s)
append: root=/dev/disk/by-partlabel/rootfs rw rootwait
Retrieving file: /usr/lib/linux-image-4.4.23-linaro-lt-qcom/qcom/apq8016-sbc.dtb
70369 bytes read in 440 ms (155.3 KiB/s)
## Flattened Device Tree blob at 8300
   Booting using the fdt blob at 0x8300
   Using Device Tree in place at 8300, end 830142e0

Starting kernel ...

[0.00] Booting Linux on physical CPU 0x0

Re: Porter roll call for Debian Stretch

[Riku Voipio]

On Tue, Sep 20, 2016 at 09:16:00PM +, Niels Thykier wrote:
> Over all, most people (who answered it) was positive towards the switch.
>  Based on this, I suspect that if we make PIE default in Stretch, then
> we will do it for all architectures.  That said, you will be notified if
> that default changes for Stretch.

Is this just for ASLR, or is ther another motivating factor for PIE?

AFAIK Address space randomizing is not really helpful on 32 bit 
architectures - there is just not that many places to randomize to[1].
At least previously, PIE added ~10% to binary size, which can have a major
performance impact on the 32-bit arm core's that don't have much cache to
begin with.

Riku
[1] https://cseweb.ucsd.edu/~hovav/dist/asrandom.pdf

Re: Thinking about a "jessie and a half" release

[Riku Voipio]

On Thu, Jul 07, 2016 at 12:24:03PM +0200, Alexander Wirt wrote:
> On Thu, 07 Jul 2016, Riku Voipio wrote:
> > On Mon, Jul 04, 2016 at 02:01:03PM +0100, Steve McIntyre wrote:
> > > There's something I've been pondering for a while, along with some
> > > other folks - it might be useful to do a "jessie and a half" release,
> > > similarly to what we did in the etch days. That's *basically* just
> > > like a normal jessie release, but with a few key updates:
> > > 
> > >  * backports kernel
> > >  * rebuilt d-i to match that kernel
> > >  * X drivers
> > >  * ... (other things that might be needed for consistency)
> > > 
> > > all rolled up with a small installer image build (netinst, maybe DVD#1).
> > > 
> > > A lot of arm64 machine users would benefit from this
> > 
> > One particular pain point is libssl. The version in jessie:
> > 
> > - Is too old for providing HTTP/2 servers for chrome [1]
> > - Lacks API features already used by apps like nodejs, #815272
> > - Has no arm64 optimizations 
> > 
> > The problem is that uploading latest openssl from unstable to
> > jessie-backports is not really feasible (ABI break and security
> > maintainance needed...). 
> In fact the maintainer uploaded a new openssl to backports and I approved it
> an hour again or so.
 
Great, I love to be proven wrong :) Thanks Kurt! 

Riku 

Re: Thinking about a "jessie and a half" release

[Riku Voipio]

On Mon, Jul 04, 2016 at 02:01:03PM +0100, Steve McIntyre wrote:
> There's something I've been pondering for a while, along with some
> other folks - it might be useful to do a "jessie and a half" release,
> similarly to what we did in the etch days. That's *basically* just
> like a normal jessie release, but with a few key updates:
> 
>  * backports kernel
>  * rebuilt d-i to match that kernel
>  * X drivers
>  * ... (other things that might be needed for consistency)
> 
> all rolled up with a small installer image build (netinst, maybe DVD#1).
> 
> A lot of arm64 machine users would benefit from this

One particular pain point is libssl. The version in jessie:

- Is too old for providing HTTP/2 servers for chrome [1]
- Lacks API features already used by apps like nodejs, #815272
- Has no arm64 optimizations 

The problem is that uploading latest openssl from unstable to
jessie-backports is not really feasible (ABI break and security
maintainance needed...). 

Riku

[1] 
https://ma.ttias.be/day-google-chrome-disables-http2-nearly-everyone-may-31st-2016/
#815272 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815272

Re: creating official Debian images for ARM-based NAS devices

[Riku Voipio]

On Wed, Apr 13, 2016 at 04:55:53PM +0200, Daniel Pocock wrote:
> get started.  There is no need for the user to run through all the
> installer questions, on many devices they can simply log in to the
> standard admin page, upload the OpenWRT image through a web form and it
> starts running with default settings.

The minimum we need to ask from users is for user/password setting. Most
live-cd / live-image tools just hardcode a default credential, which is
quite bad for embedded devices that will be running for years... 

Riku

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

[Riku Voipio]

On Sat, Apr 09, 2016 at 12:02:44PM +0200, Graham Inggs wrote:
> On 9 April 2016 at 00:53, peter green  wrote:
> > It would be useful if someone can reproduce the issue and get a dissasembly
> > of the failure location.
> 
> I hope this is useful.  I'll leave my screen session on abel.d.o. open
> in case I need to fetch more information.
> 
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
> WARNING: unable to determine host cpu name.
> exports.jl
> essentials.jl
> docs/bootstrap.jl
> base.jl
> reflection.jl
> build_h.jl
> version_git.jl
 
> Program received signal SIGILL, Illegal instruction.
> 0x940c5060 in julia_call_891 ()
> (gdb) disassemble $pc
> Dump of assembler code for function julia_call_891:
>0x940c5054 <+0>: push{r4, r5, r6, lr}
>0x940c5058 <+4>: vpush   {d8}
>0x940c505c <+8>: mov r0, #40 ; 0x28
> => 0x940c5060 <+12>:vorrd8, d0, d0

And yes, vorr is an NEON instruction.

>0x940c5064 <+16>:mov r4, r3
>0x940c5068 <+20>:mov r5, r2
>0x940c506c <+24>:mov r6, r1
>0x940c5070 <+28>:bl  0x940c50c4
>0x940c5074 <+32>:movwr1, #16432  ; 0x4030
>0x940c5078 <+36>:movtr1, #37900  ; 0x940c
>0x940c507c <+40>:ldr r1, [r1]
>0x940c5080 <+44>:stmda   r0, {r1, r6}
>0x940c5084 <+48>:ldr r1, [sp, #24]
>0x940c5088 <+52>:str r5, [r0, #4]
>0x940c508c <+56>:str r4, [r0, #8]
>0x940c5090 <+60>:str r1, [r0, #12]
>0x940c5094 <+64>:ldr r1, [sp, #28]
>0x940c5098 <+68>:str r1, [r0, #16]
>0x940c509c <+72>:ldrbr1, [sp, #32]
>0x940c50a0 <+76>:and r1, r1, #1
>0x940c50a4 <+80>:strbr1, [r0, #20]
>0x940c50a8 <+84>:ldr r1, [sp, #36]   ; 0x24
>0x940c50ac <+88>:str r1, [r0, #24]
>0x940c50b0 <+92>:vstrd8, [r0, #32]
>0x940c50b4 <+96>:vpop{d8}
>0x940c50b8 <+100>:   pop {r4, r5, r6, pc}
> End of assembler dump.

 

Re: Bug#819890: haskell-http2: FTBFS on armel buildds (was: Re: Please give back haskell-http2 on armel)

[Riku Voipio]

On Sun, Apr 03, 2016 at 03:11:39PM +0100, Steven Chamberlain wrote:
> Wookey wrote:
> > +++ Steven Chamberlain [2016-04-01 10:31 +0100]:
> > > Currently haskell-http2 FTBFS on only armel:
> > > https://buildd.debian.org/status/package.php?p=haskell-http2=unstable
> > > delaying the package's testing migration and keeping many reverse-deps
> > > BD-Uninstallable on armel.
> > > 
> > > More recently than that it has successfully built:
> > > https://tests.reproducible-builds.org/rbuild/unstable/armhf/haskell-http2_1.5.3-2.rbuild.log
> > > 
> > > Therefore, please could it be given back for another build attempt?
> > > 
> > >   gb haskell-http2_1.5.3-2 . armel
> > 
> > Seems a reasonable request.
> > done
 
> Thanks;  it didn't work though.  Please could arm porters take a look?
 
> The reproducible-builds log shows the test suite passing, whereas on the
> buildds one test failed, on both build attempts.

The reproducible-builds is armhf while the failing ones are armel. The 
regression
appears to be a code change in haskell-http2 between 1.0.4 and 1.3.1:

https://buildd.debian.org/status/logs.php?pkg=haskell-http2=armel

Riku

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

[Riku Voipio]

On Thu, Mar 10, 2016 at 10:13:22AM +0800, Paul Wise wrote:
> On Thu, Mar 10, 2016 at 1:18 AM, Ronald Maas wrote:
> > I am not familiar with the whole Debian build infrastructure. So if I missed
> > the point where this becomes a real issue, hope you can elaborate.
 
> For example:
 
> You can't flash UEFI over u-boot from the official Debian/etc installers.

But we most certainly don't want flash UEFI from d-i. What should do is 
document:

1. Please install UEFI version X or newer using instructions from manufacturer
2. Insert d-i boot media and let the UEFI firmware boot GRUB from it.

Essentially the process would be the same as on X86 if some PC machine came
with a BIOS that would be too buggy to boot grub/linux out of box. 

Riku

Cross-distribution ARM meetings at Linaro connect this weel

[Riku Voipio]

Hi,

We have a few sessions at this Linaro connect that could be in
interest of Linux distributions working on Arm/Linux:

Tuesday 14.00 Bangkok time: (07.00 UTC):
https://bkk16.pathable.com/meetings/372827 BKK16-212: What's broken on ARM64?
Thursday 10.10 Bangkok time: (03.00 UTC):
https://bkk16.pathable.com/meetings/372890 BKK16-402: Cross distro BoF
Friday 10.10 Bangkok time: (03.00 UTC):
https://bkk16.pathable.com/meetings/372923 BKK16-501: Kernel
Consolidation and Other Short Stories

Talks are being live-streamed (thou there were problems today..) and
recorded in case time happens to be inconvenient in your timezones.

If you have anything specific in your mind, feel free to reply to this mail to
cross-distribution list, and I'll get it added to the agenda slides.

Cheers,
Riku

Re: [PATCH v3] deb-pkg: Add automatic support for armhf architecture

[Riku Voipio]

On 28 September 2015 at 04:34, Ben Hutchings <b...@decadent.org.uk> wrote:
> The Debian armhf architecture uses the ARM EABI hard-float variant,
> whereas armel uses the soft-float variant.  Although the kernel
> doesn't use FP itself, CONFIG_VFP must be enabled to support
> hard-float userland and will probably be disabled when supporting a
> soft-float userland.  So set the architecture to armhf by default when
> CONFIG_AEABI and CONFIG_VFP are both enabled.
>
> Signed-off-by: Ben Hutchings <b...@decadent.org.uk>
> Acked-by: Ian Campbell <i...@hellion.org.uk>
> Acked-by: Fathi Boudra <fathi.bou...@linaro.org>

Reviewed-by: Riku Voipio <riku.voi...@linaro.org>

> ---
> v2: rebased
> v3: rebased
>
>  scripts/package/builddeb | 11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
>
> --- a/scripts/package/builddeb
> +++ b/scripts/package/builddeb
> @@ -52,7 +52,16 @@ set_debarch() {
> arm64)
> debarch=arm64 ;;
> arm*)
> -   debarch=arm$(grep -q CONFIG_AEABI=y $KCONFIG_CONFIG && echo 
> el || true) ;;
> +   if grep -q CONFIG_AEABI=y $KCONFIG_CONFIG; then
> +   if grep -q CONFIG_VFP=y $KCONFIG_CONFIG; then
> +   debarch=armhf
> +   else
> +   debarch=armel
> +   fi
> +   else
> +   debarch=arm
> +   fi
> +   ;;
> *)
> debarch=$(dpkg --print-architecture)
> echo "" >&2
> --
> Ben Hutchings
> All extremists should be taken out and shot.

Cross-distribution ARM Linux platform support meeting at Connect San Fransisco

[Riku Voipio]

Hi everyone,

Since cross-distribution meetings at Linaro Connect have been popular,
we are continuing the tradition and having a session[1] in Linaro Connect next
week.
https://sfo15.pathable.com/meetings/302652

The event is on Monday September 21, 16.10 PST (aka 23:10:00 UTC).
Details of google hangout should be coming closer to event.

If you have anything specific in your mind, feel free to reply to this mail to
cross-distribution list, and I'll get it added to the agenda.

Cheers,
Riku

Re: kvm-arm: qemu always starts with drive in read-only mode

[Riku Voipio]

On Wed, Aug 19, 2015 at 07:44:34PM +0200, Guido Haase wrote:
 After I started the system by command
 
   qemu-system-arm -enable-kvm -smp 1 -m 256 -M vexpress-a15 -cpu host
   -kernel /home/guido/kvm-arm/jessie/vexpress-zImage -dtb
   /home/guido/kvm-arm/jessie/vexpress-v2p-ca15-tc1.dtb -append
   root=/dev/vda console=ttyAMA0 rootwait -drive
   if=none,file=/home/guido/kvm-arm/jessie/jessie-arm.img,id=factory
   -device virtio-blk-device,drive=factory -net
   nic,macaddr=02:fd:01:de:ad:34 -net tap -monitor null -serial stdio
   -nographic
 
 the VM starts and I'm aible to login. Sadly, device jessie-arm.img i.e.
 /dev/vda is allways mounted read-only. After loging into the VM I can
 mount it read/write. But this no solution. I want the machine booting
 with the device in read/write mode, because already during the boot
 process some deamons try to write to it.

You can change the -append line to root=/dev/vda console=ttyAMA0 rootwait rw
I'm exactly sure why that doesn't happen by default. 

Riku 

Re: [PATCH 1/4] deb-pkg: Add automatic support for armhf architecture

[Riku Voipio]

On 2 April 2015 at 17:18, Michal Marek mma...@suse.cz wrote:
 On 2015-04-02 15:14, Riku Voipio wrote:
 On 2 April 2015 at 15:01, Arnaud Patard arnaud.pat...@rtp-net.org wrote:
 riku.voi...@linaro.org writes:
 --- a/scripts/package/builddeb
 +++ b/scripts/package/builddeb
 @@ -45,7 +45,16 @@ create_package() {
   arm64)
   debarch=arm64 ;;
   arm*)
 - debarch=arm$(grep -q CONFIG_AEABI=y $KCONFIG_CONFIG  echo 
 el || true) ;;
 + if grep -q CONFIG_AEABI=y $KCONFIG_CONFIG; then
 + if $CC -dM -E -  /dev/null|grep -q __ARM_PCS_VFP; 
 then

 Actually, I guess there's nothing preventing you building a armhf kernel
 with a compiler not having __ARM_PCS_VFP defined by default, but I'm not 
 sure
 we should take care of this case. One can always use KBUILD_DEBARCH=armhf.

 I think the common use cases would be a) native compilers or b)
 cross-compiler targeting the same debian architecture as the rootfs.
 This patch provides automatic detection for both cases.

 $CC should be used together with $KBUILD_CFLAGS to behave the same as
 when building the kernel.

I just tested and it won't work. $KBUILD_CFLAGS has -msoft-float so
__ARM_PCS_VFP wont be set. Which makes sense - we wouldn't want kernel
to pass anything in float registers. Given the constraint, would you
prefer Ben's original patch that checks CONFIG_VFP[1], or my version
using CC without KBUILD_CFLAGS?

[1] https://lists.debian.org/debian-arm/2014/06/msg00016.html

Riku


-- 
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/caaqcghnrvdu+7nhd37tk98bwjefy1+mstsm6bryza11akv7...@mail.gmail.com

[PATCH 1/4] deb-pkg: Add automatic support for armhf architecture

[riku . voipio]

From: Ben Hutchings b...@decadent.org.uk

The Debian armhf architecture uses the ARM EABI hard-float variant,
whereas armel uses the soft-float variant.  If the compiler used
to compile the kernel uses the __ARM_PCS_VFP ABI, the compiler
targets armhf architecture.

v3 by Riku: Use gcc define instead of CONFIG_VFP

Cc: debian-arm@lists.debian.org
Signed-off-by: Ben Hutchings b...@decadent.org.uk
Signed-off-by: Riku Voipio riku.voi...@linaro.org
---
 scripts/package/builddeb | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/scripts/package/builddeb b/scripts/package/builddeb
index 88dbf23..146b74f 100755
--- a/scripts/package/builddeb
+++ b/scripts/package/builddeb
@@ -45,7 +45,16 @@ create_package() {
arm64)
debarch=arm64 ;;
arm*)
-   debarch=arm$(grep -q CONFIG_AEABI=y $KCONFIG_CONFIG  echo el 
|| true) ;;
+   if grep -q CONFIG_AEABI=y $KCONFIG_CONFIG; then
+   if $CC -dM -E -  /dev/null|grep -q __ARM_PCS_VFP; then
+   debarch=armhf
+   else
+   debarch=armel
+   fi
+   else
+   debarch=arm
+   fi
+   ;;
*)
echo  2
echo ** ** **  WARNING  ** ** ** 2
-- 
2.1.4


-- 
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/834bd55c0de686780eb15f9a06b13f7fb560e9a8.1427968988.git.riku.voi...@linaro.org

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

[Riku Voipio]

On Tuesday, March 31, 2015 1:33:29 PM EEST, peter green wrote:
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.


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.


Looks like ubuntu has chromium in armhf packages:

https://launchpad.net/ubuntu/+source/chromium-browser/41.0.2272.76-0ubuntu1.1134

The changes to enable armhf build seems quite small (bunch of arm related 
defines and unsetting sysroot). I haven't tested if the binaries ubuntu 
builds actually work.


Riku


--
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/e7a6e5c4-bde5-4099-97a9-c93d3c19f...@iki.fi

Cross Distribution sync on ARM issues session at Linaro connect

[Riku Voipio]

Hi everyone,

Since cross-distribution meetings at Linaro Connect have been popular,
we are continuing the tradition and having a session[1] in Linaro Connect next
week.

https://hkg15.pathable.com/meetings/250818

The event is on Wednesday 11 February, 14.00 hong kong time (06.00 UTC).
We'll try to get session broadcasted on google hangouts for remote
participation, but I don't have the link at hand yet.

If you have anything specific in your mind, feel free to reply to this mail to
cross-distribution list, and I'll get it added to agenda.

Riku


-- 
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/CAAqcGHm5+XwhKnc6cjgHr7q78W1Xpi-XvywQmpkp=ehpwie...@mail.gmail.com

Re: armv7 builds leaking into armel

[Riku Voipio]

On Mon, Nov 24, 2014 at 04:18:20AM +, peter green wrote:
 In Raspbian we run all packages we build through a check that
 unpacks them and runs readelf[5]. 

We could do this as post-build-command in armel buildds. But we would
still need some volunteer to maintain the whitelist of false positives.

other actions:

a LD_PRELOAD that sets uname to armv4t could help prevent
the leakage somewhat.

echo 4  /proc/cpu/alignment to detect unaligned accesses (tricker
since we need to remove the flag on starting armhf builds on same
machines).

Riku


-- 
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/20141124104523.ga20...@afflict.kos.to

Re: libv8 packaging and arm64

[Riku Voipio]

  Please read this answer i made a couple of months ago:
  https://lists.alioth.debian.org/pipermail/pkg-javascript-devel/2014-June/008013.html

  ACK. Thanks for the quick response - I appreciate you're in a
  difficult situation. :-/. Do you have any feel for progress towards
  nodejs 0.12 / mongodb 2.8 that you mentioned there?
 
 It doesn't look promising !

nodejs has a 0.12 branch[1]. Would it be possible to upload new libv8
and nodejs release branch to experimental for testing?

[1] https://github.com/joyent/node/tree/v0.12


-- 
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/20140915182511.ga31...@afflict.kos.to

Re: Illegal Instruction on Debian 7 on QNAP TS-209 after upgrade

[Riku Voipio]

Hi,

On Wed, Aug 06, 2014 at 11:43:33AM +0200, Ole Langbehn wrote:
 On 06.08.2014 11:35, Riku Voipio wrote:
  Best change to recover is probably to take backups from disk, reinstall
  (and don't upgrade), and then create chroot and try to upgrade there -
  if it fails under chroot, it is possible to attach debuggers and see
  what instructions is SIGILing
 
 Since this box has a raid1, I can probably just rip out one disk and
 attach it to another box and then chroot into the debian env. Can I
 simply attach gdb to apt on the system in its current state?

Yes, but you would need an ARM based box to attach the disk on,
preferrably same Marvell orion cpu as on your TS-209, but any ARMv5
cpu would do.

 But please consider this topic as frozen, and don't expect any progress
 on my side soon, since my wife and I are expecting twins, and she's
 currently in hospital. I will post any progress.

Understood, best wishes!

Riku


-- 
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/20140807114735.ga23...@afflict.kos.to

Re: Illegal Instruction on Debian 7 on QNAP TS-209 after upgrade

[Riku Voipio]

On Tue, Aug 05, 2014 at 02:44:05PM +0200, Ole Langbehn wrote:
 Recently (2014/7/25) I upgraded my debian 7 on my qnap TS209 box (see
 the attached apt output) and after installing some packages (libc, apt,
 ...), the installation fails with an Illegal Instruction signal. Shortly
 after I wasn't able to continue the update due to Illegal Instruction
 errors, but processes were running just fine. Now, a couple of days
 later, I can't login/ping the box (which is headless, so I don't have
 access to the console).

Well, without console, this is going to be challenge to debug :(
Either some non-armv5 instructions have slipped to the stable/security
updates of libc/dpkg, or your machine is breaking down.

 Is this a known error? What can I do to resolve this?

Not as far as I know - I was unable to reproduce it in a chroot on a ARMv5
machine. 

Best change to recover is probably to take backups from disk, reinstall
(and don't upgrade), and then create chroot and try to upgrade there -
if it fails under chroot, it is possible to attach debuggers and see
what instructions is SIGILing

 Cheers,
 
 Ole

 root@nas:~# apt-get upgrade
 Reading package lists... Done
 Building dependency tree   
 Reading state information... Done
 The following packages will be upgraded:
   apt apt-utils base-files cups cups-bsd cups-client cups-common cups-ppdc 
 curl dbus dpkg dpkg-dev gnupg gnupg-agent gpgv imagemagick imagemagick-common 
 libapt-inst1.5 libapt-pkg4.12 libc-bin libc-dev-bin libc6 libc6-dev libcups2 
 libcupscgi1 libcupsdriver1
   libcupsimage2 libcupsmime1 libcupsppdc1 libcurl3 libcurl3-gnutls 
 libcurl4-gnutls-dev libdbus-1-3 libdpkg-perl libgnutls-dev 
 libgnutls-openssl27 libgnutls26 libgnutlsxx27 libjbig0 libjpeg8 liblcms2-2 
 libmagickcore5 libmagickcore5-extra libmagickwand5 libnspr4
   libnss-winbind libopenjpeg2 libpam-winbind libsnmp-base libsnmp15 
 libssl-dev libssl-doc libssl1.0.0 libsvn-perl libsvn1 libwbclient0 libxfont1 
 libxml2 libxml2-dev linux-image-3.2.0-4-orion5x linux-libc-dev locales 
 multiarch-support openssh-client openssh-server
   openssl python-lxml python-subversion samba samba-common samba-common-bin 
 samba-doc smbclient subversion subversion-tools swat transmission-cli 
 transmission-common transmission-daemon tzdata winbind
 81 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
 Need to get 91.0 MB of archives.
 After this operation, 224 kB disk space will be freed.
 Do you want to continue [Y/n]? y
 Get:1 http://security.debian.org/ stable/updates/main libc-dev-bin armel 
 2.13-38+deb7u3 [223 kB]
 Get:2 http://ftp.de.debian.org/debian/ stable/main base-files armel 
 7.1wheezy6 [69.1 kB]
 Get:3 http://ftp.de.debian.org/debian/ stable/main dpkg armel 1.16.15 [2,595 
 kB]
 Get:4 http://security.debian.org/ stable/updates/main libc6-dev armel 
 2.13-38+deb7u3 [2,518 kB]
 Get:5 http://security.debian.org/ stable/updates/main libc-bin armel 
 2.13-38+deb7u3 [1,209 kB]
 Get:6 http://ftp.de.debian.org/debian/ stable/main libapt-pkg4.12 armel 
 0.9.7.9+deb7u2 [871 kB]
 Get:7 http://ftp.de.debian.org/debian/ stable/main gpgv armel 1.4.12-7+deb7u4 
 [206 kB]  
   
 
 Get:8 http://security.debian.org/ stable/updates/main libc6 armel 
 2.13-38+deb7u3 [4,219 kB] 
   
 
 Get:9 http://ftp.de.debian.org/debian/ stable/main gnupg armel 
 1.4.12-7+deb7u4 [1,902 kB]
   

 Get:10 http://ftp.de.debian.org/debian/ stable/main apt armel 0.9.7.9+deb7u2 
 [1,244 kB]
   
  
 Get:11 http://ftp.de.debian.org/debian/ stable/main libapt-inst1.5 armel 
 0.9.7.9+deb7u2 [164 kB]   
   
  
 Get:12 http://ftp.de.debian.org/debian/ stable/main libssl-doc all 
 1.0.1e-2+deb7u11 [1,198 kB]   
   

 Get:13 http://security.debian.org/ stable/updates/main linux-libc-dev armel 
 3.2.60-1+deb7u1 [806 kB]  
   
   
 

Re: [PATCH v2 1/2] deb-pkg: Add automatic support for armhf architecture

[Riku Voipio]

On Tue, Jun 10, 2014 at 04:06:39PM +0300, Riku Voipio wrote:
 On Mon, Jun 09, 2014 at 01:21:34AM +0100, Ben Hutchings wrote:
  The Debian armhf architecture uses the ARM EABI hard-float variant,
  whereas armel uses the soft-float variant.  Although the kernel
  doesn't use FP itself, CONFIG_VFP must be enabled to support
  hard-float userland and will probably be disabled when supporting a
  soft-float userland.  So set the architecture to armhf by default when
  CONFIG_AEABI and CONFIG_VFP are both enabled.
  
  Signed-off-by: Ben Hutchings b...@decadent.org.uk
  ---
  v2: rebased
  
  After discussion with Hector, we agreed this would be a worthwhile
  change.  Hector may later improve this by using gcc specs.
 
 That should be easy:
 
 -if grep -q CONFIG_VFP=y $KCONFIG_CONFIG; then
 +if $CC -dM -E -  /dev/null|grep -q __ARM_PCS_VFP; then
 
 It worked at least for my cross-compile test a minute ago.

It would be nice to have this change scheduled in any form to 3.17.
Most people building kernels these days do armhf, so Bens version is
already a material improvement for everyone.

Riku

 Riku
 
  Ben.
  
   scripts/package/builddeb | 11 ++-
   1 file changed, 10 insertions(+), 1 deletion(-)
  
  diff --git a/scripts/package/builddeb b/scripts/package/builddeb
  index f46e4dd..6756ed6 100644
  --- a/scripts/package/builddeb
  +++ b/scripts/package/builddeb
  @@ -43,7 +43,16 @@ create_package() {
  mips*)
  debarch=mips$(grep -q CPU_LITTLE_ENDIAN=y $KCONFIG_CONFIG  
  echo el || true) ;;
  arm*)
  -   debarch=arm$(grep -q CONFIG_AEABI=y $KCONFIG_CONFIG  echo el 
  || true) ;;
  +   if grep -q CONFIG_AEABI=y $KCONFIG_CONFIG; then
  +   if grep -q CONFIG_VFP=y $KCONFIG_CONFIG; then
  +   debarch=armhf
  +   else
  +   debarch=armel
  +   fi
  +   else
  +   debarch=arm
  +   fi
  +   ;;
  *)
  echo  2
  echo ** ** **  WARNING  ** ** ** 2
  
  
  -- 
  Ben Hutchings
  One of the nice things about standards is that there are so many of them.
 
 
 
 -- 
 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/20140610130639.ga25...@afflict.kos.to


-- 
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/20140714141446.ga26...@afflict.kos.to

Re: [PATCH v2 1/2] deb-pkg: Add automatic support for armhf architecture

[Riku Voipio]

On Mon, Jun 09, 2014 at 01:21:34AM +0100, Ben Hutchings wrote:
 The Debian armhf architecture uses the ARM EABI hard-float variant,
 whereas armel uses the soft-float variant.  Although the kernel
 doesn't use FP itself, CONFIG_VFP must be enabled to support
 hard-float userland and will probably be disabled when supporting a
 soft-float userland.  So set the architecture to armhf by default when
 CONFIG_AEABI and CONFIG_VFP are both enabled.
 
 Signed-off-by: Ben Hutchings b...@decadent.org.uk
 ---
 v2: rebased
 
 After discussion with Hector, we agreed this would be a worthwhile
 change.  Hector may later improve this by using gcc specs.

That should be easy:

-if grep -q CONFIG_VFP=y $KCONFIG_CONFIG; then
+if $CC -dM -E -  /dev/null|grep -q __ARM_PCS_VFP; then

It worked at least for my cross-compile test a minute ago.

Riku

 Ben.
 
  scripts/package/builddeb | 11 ++-
  1 file changed, 10 insertions(+), 1 deletion(-)
 
 diff --git a/scripts/package/builddeb b/scripts/package/builddeb
 index f46e4dd..6756ed6 100644
 --- a/scripts/package/builddeb
 +++ b/scripts/package/builddeb
 @@ -43,7 +43,16 @@ create_package() {
   mips*)
   debarch=mips$(grep -q CPU_LITTLE_ENDIAN=y $KCONFIG_CONFIG  
 echo el || true) ;;
   arm*)
 - debarch=arm$(grep -q CONFIG_AEABI=y $KCONFIG_CONFIG  echo el 
 || true) ;;
 + if grep -q CONFIG_AEABI=y $KCONFIG_CONFIG; then
 + if grep -q CONFIG_VFP=y $KCONFIG_CONFIG; then
 + debarch=armhf
 + else
 + debarch=armel
 + fi
 + else
 + debarch=arm
 + fi
 + ;;
   *)
   echo  2
   echo ** ** **  WARNING  ** ** ** 2
 
 
 -- 
 Ben Hutchings
 One of the nice things about standards is that there are so many of them.



-- 
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/20140610130639.ga25...@afflict.kos.to

Re: Bug#738981: Fwd: Bug#738981: Switch to use generic_fpu for ARM

[Riku Voipio]

On Tue, Mar 04, 2014 at 11:49:45AM +0100, Thomas Orgis wrote:
 In any case ... Riku: Care to run timings of MAD on your
 configurations? I'm interested in how fast it is producing that 24 bit
 output on limited CPUs.

time madplay -d -o null: convergence_-_points_of_view/*.mp3  /dev/null  

Cortex A15:

real0m33.154s
user0m33.045s
sys 0m0.110s

ARMv5:

real1m35.923s
user1m18.290s
sys 0m0.070s

Seems mpg123 wins bragging rights :) thanks, awesome work!

Riku


-- 
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/20140305091407.ga16...@afflict.kos.to

Re: Bug#738981: Fwd: Bug#738981: Switch to use generic_fpu for ARM

[Riku Voipio]

On Tue, Mar 04, 2014 at 02:59:44AM +, peter green wrote:
 On Sun, Mar 02, 2014 at 09:06:44AM -0500, Reinhard Tartler wrote:
 
 That sounds like if the mpg123 package should use:
 on armel: --with-cpu=arm_nofpu
 on armhf: --with-cpu=arm_fpu
 
 
 Does this make sense to everybody?
 Seems sane to me. armv7 devices without neon are relatively uncommon
 so while it's important that they are supported it's IMO not vitally
 important to squeeze out every last drop of performance from them.
 
 I wonder what we should use on raspbian? I haven't tested on a Pi
 yet but it seems that on all tests i've seen so-far the generic fpu
 code is quite a bit slower than the arm nofpu code. Is there any
 quality difference from using a fpu vs nonfpu decoder? If so how
 much performance degredation do you beleive should be accepted in
 exchange for that quality improvement.

I think nofpu would good for raspian. Any lost audio quality would
unnoticable on the Rasberry's analog audio output ;)

Peter, what's the recommended way to recognize raspbian in debian/rules
?

Riku


-- 
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/20140305093430.gb16...@afflict.kos.to

Re: Bug#738981: Fwd: Bug#738981: Switch to use generic_fpu for ARM

[Riku Voipio]

On Sun, Mar 02, 2014 at 12:02:40PM +0100, Thomas Orgis wrote:
 Am Sat, 01 Mar 2014 01:00:02 +0900
 schrieb Taihei Momma t...@mac.com: 
 
  OK, after some investigation with armhf cross environment and qemu, finally 
  the current mpg123 svn (r3517) should work 
 
 After Tahei didn't stop at this (big thanks from here!), we got a new
 snapshot,
 
   http://mpg123.org/snapshot/mpg123-20140302115523.tar.bz2 ,
 
 that will hopefully become mpg123 1.19.0 soon (not 1.18.x
 because of feature additions regarding this very debian issue). The
 main points:
 
 - float output with all decoders (also arm_nofpu)
 - ARM decoders (esp. NEON) working with debian toolchain
 - new --with-cpu=arm_fpu choice with runtime detection to switch
   between NEON or normal FPU
 
 So, the number of builds for optimal treatment of differing platforms
 reduces to two:
 
 1. --with-cpu=arm_nofpu
 2. --with-cpu=arm_fpu

Awesome work!

 I hope we can all be happy about that. I'd also be glad to get some
 confirmation from debian that it really works now. Release will be
 imminent, then.

Here's some test results

On a cortex-a15 system arm_nofpu: (ubuntu armhf)

#decodert_s16/s t_f32/s
ARM 24.22   25.02

On a cortex-a15 system arm_fpu: (ubuntu armhf)

#decodert_s16/s t_f32/s
NEON14.33   14.90
generic 36.25   27.46
generic_dither  39.52   27.44

the A15 core was downclocked and cpufreq disabled to ensure
stable results

ARMv5 system arm_nofpu (debian armel)

#mpg123 benchmark (user CPU time in seconds for decoding)
#decodert_s16/s t_f32/s
ARM 49.12   63.17

ARMv5 system arm_fpu (debian sid)

#mpg123 benchmark (user CPU time in seconds for decoding)
#decodert_s16/s t_f32/s
generic 491.75  468.37
generic_dither  535.50  468.38

armel is with softfloat emulation, so horrible times were expected - 
the main point of that last run was to verify that NEON runtime
detection works (Seems so).

Riku


-- 
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/20140303085058.ga1...@afflict.kos.to

Bug#740334: qtwebkit creates ARMv5 assembler

[Riku Voipio]

Package: qtwebkit-opensource-src
Version: 5.2.1+dfsg-3
X-Debbugs-CC: debian-arm@lists.debian.org
Severity: normal

Checking the end of the builddlog[1]:

/tmp/ccaKPWJK.s: Assembler messages:
/tmp/ccaKPWJK.s:23: Error: selected processor does not support ARM mode
`blx r0'
make[4]: *** [.obj/jit/JITStubs.o] Error 1

blx is not supported on ARMv4t, lowest arch supported on debian/armel.
One needs to replace this code with:

mov lr,pc
bx r0

Or, alternatively build with -march=armv5. This option would mean than
qtwebkit would be unusable on armv4t hardware. The main usecase for such
hardware is the openmoko freerunner. Do we still have openmoko users who
are interested in qtwebkit?

Riku

[1] 
https://buildd.debian.org/status/fetch.php?pkg=qtwebkit-opensource-srcarch=armelver=5.2.1%2Bdfsg-3stamp=1393519544


-- 
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/20140228095703.ga19...@afflict.kos.to

Re: Fwd: Bug#738981: Switch to use generic_fpu for ARM

[Riku Voipio]

Hi,

On Sun, Feb 16, 2014 at 07:41:02PM -0500, Reinhard Tartler wrote:
 On Sun, Feb 16, 2014 at 7:28 PM, peter green plugw...@p10link.net wrote:
  We can't use the neon option because no arm port of debian gaurantees that
  neon will be available. So I belive until the no-fpu options are made
  compatible with audacious and/or some form of runtime detection is
  implemeted (either using ld.so.hwcaps to load different versions of the
  library) we need to keep using --with-generic-fpu on all our arm ports.

Thanks Peter for explaining, this was how I ended up the suggestion
in the bug.

 I see. In that case, I'll have to leave the package as it until
 something along those lines is implemented.

Yes. The ideal solution is for the upstream to implement cpu runtime
detection that:

1) uses neon if it is available
2) falls back to fixed point if app requested 16-bit playback
3) finally falls back to generic fpu code if neither of above applies

Any packaging level workaround is going to be suboptimal for someone.

Riku


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140217080048.ga14...@afflict.kos.to

Re: Fwd: Bug#738981: Switch to use generic_fpu for ARM

[Riku Voipio]

 -- Forwarded message --
 From: Thomas Orgis thomas-fo...@orgis.org
 Date: Sun, Feb 16, 2014 at 5:46 AM
 Subject: Bug#738981: Switch to use generic_fpu for ARM
 To: 738...@bugs.debian.org
 
 
 There is no runtime detection in mpg123 for this and at least for the
 decision of fixed or floating point decoding, it likely will never be
 as that is a very basic decision on the whole decoder code, not just
 some optimization. 

- snip-

 Something which is possible right now is to produce one libmpg123.so with
 the standard build to please users using slow ARM machines who just
 want plain 16 bit playback and produce one libmpg123_float.so for people
 using beefy machines and who are using audacious as a media player.

If is indeed the case that doing runtime detection of float/fixed code
is not feasible, then it might make sense to provide separate
libmpg123_float.so and libmpg123.so (on armel).

Applications needing flaots would then be linked against libmpg123_float.so
and all others against plain libmpg123.so.

This would mean that audacious would be slow on non-fpu hardware, but
people could still use fast command line mpg123. Which I guess is what
most people with slow non-fpu hardware would do anyways.

Now, if audacious is the only application that need floats, a more
brutal approach could be acceptable:

on armel: ship audacious-plugins without libmpg123 support, and libmpg123
as fixed point for other applications.

on armhf, ship libmpg123 as floats, with runtime autodection of NEON.

This leaves in limbo only on rasberry and others who have vfp but
no NEON. It would be interesting to hear what's the performance of
libmpg123 compiled with different options on rasberry to make sense
what would be the optimal solution for raspbian.

 I could implement a conversion step to floating point with the
 arm_nofpu decoder. That would make audacious work (although wasting
 precision on machines that have hardware floating point, or even NEON)
 and have the benefit of the command-line mpg123 still being fast with
 16 bit output. A debian build targeting modern floating-point-capable
 hardware would use generic_fpu or better the neon decoder to begin with.

 Is there preference to have the faster decoder for debian without
 floating point hardware?

There is as many preferences as there is debian developers, I'm afraid.
My primarily preference is that binaries in debian work. Which with
previous state of libmpg123 and audacious was not the case - on any
hardware.

Riku


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140217085233.gb14...@afflict.kos.to

Re: gcc armel status and armel architecture defaults

[Riku Voipio]

On Mon, Jan 13, 2014 at 08:32:49AM +, Ian Campbell wrote:
 On Mon, 2014-01-13 at 05:51 +0100, Matthias Klose wrote:

  the gcc-4.9 in experimental fails to build while the one for armhf succeeds.
 
 For reference the logs are at:
 https://buildd.debian.org/status/fetch.php?pkg=gcc-4.9arch=armelver=4.9-20140111-1stamp=1389510444
 
 build/genpreds -c ../../src/gcc/config/arm/arm.md  tmp-constrs.h
 /bin/bash: line 1: 18632 Segmentation fault  build/genpreds -c 
 ../../src/gcc/config/arm/arm.md  tmp-constrs.h

I did a local build of gcc-4.9 and got to the same point. build/genpreds 
succeeds 
if built with O0, and fails if built with -O1. Backtrace: 

Program received signal SIGSEGV, Segmentation fault.
needs_variable (exp=exp@entry=0x0, var=var@entry=0x1a438 ival)
at ../../src/gcc/genpreds.c:169
169   switch (GET_CODE (exp))
(gdb) bt
#0  needs_variable (exp=exp@entry=0x0, var=var@entry=0x1a438 ival)
at ../../src/gcc/genpreds.c:169
#1  0xa8e0 in write_tm_constrs_h () at ../../src/gcc/genpreds.c:1051
#2  main (argc=optimized out, argv=optimized out)
at ../../src/gcc/genpreds.c:1400
(gdb) bt full
#0  needs_variable (exp=exp@entry=0x0, var=var@entry=0x1a438 ival)
at ../../src/gcc/genpreds.c:169
__FUNCTION__ = needs_variable
#1  0xa8e0 in write_tm_constrs_h () at ../../src/gcc/genpreds.c:1051
needs_ival = optimized out
needs_hval = optimized out
needs_lval = optimized out
needs_rval = optimized out
needs_mode = optimized out
needs_op = optimized out
c = 0x2c800
#2  main (argc=optimized out, argv=optimized out)
at ../../src/gcc/genpreds.c:1400
defn = optimized out
pattern_lineno = 421
next_insn_code = 3816
(gdb) p exp
$1 = (rtx) 0x0
(gdb) frame 1
#1  0xa8e0 in write_tm_constrs_h () at ../../src/gcc/genpreds.c:1051
1051bool needs_ival = needs_variable (c-exp, ival);
(gdb) p c
$3 = (constraint_data *) 0x2c800
(gdb) p *c
$4 = {next_this_letter = 0x0, next_textual = 0x2c828, name = 0x53930 t, 
  c_name = 0x53930 t, namelen = 1, 
  regclass = 0x53938 TARGET_32BIT ? VFP_LO_REGS : NO_REGS, exp = 0x0, 
  lineno = 44, is_register = 0, is_const_int = 0, is_const_dbl = 0, 
  is_extra = 0, is_memory = 0, is_address = 0}
(gdb) 


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140113145016.ga21...@afflict.kos.to

Re: [Fwd: Buggy perl on buildd cause build failures - please update perl on buildds to perl_5.18.1-5]

[Riku Voipio]

Hi,

Sorry I didn't notice armel mentioned on the original mail, so I assumed
it was just sent to ports@ . Will look at the buildd's asap.

Riku

On Wed, Jan 01, 2014 at 11:39:23AM +0100, Mattias Ellert wrote:
 Hi!
 
 Is there anyone that receives the mails sent to ar...@buildd.debian.org?
 
 The build in currently building for the second time with the broken perl
 version. It once again has ended up in an eternal loop in the buggy perl
 installation in the buildd build root. The build has now been running
 for more than 31 hours, and will not succeed this time either. With a
 perl version without the eternal loop bug the build usually takes less
 than 3 hours.
 
   Mattias
 
 sön 2013-12-29 klockan 14:51 +0100 skrev Mattias Ellert:
  tor 2013-12-19 klockan 22:23 +0100 skrev Mattias Ellert:
   Hi!
   
    Vidarebefordrat meddelande 
   Från: Mattias Ellert mattias.ell...@fysast.uu.se
   Till: i...@buildd.debian.org, kfreebsd-am...@buildd.debian.org,
   kfreebsd-i...@buildd.debian.org, m...@buildd.debian.org,
   powe...@buildd.debian.org, sp...@buildd.debian.org
   Ämne: Buggy perl on buildd cause build failures - please update perl on
   buildds to perl_5.18.1-5
   Datum: Wed, 18 Dec 2013 07:38:51 +0100
   
   The build of condor_7.8.8~dfsg.1-2.1 has failed on
   
   i386, kfreebsd-amd64, kfreebsd-i386, mips, powerpc and sparc
   
   where perl_5.18.1-4 was used during the build
   
   The build has succeeded on
   
   390x, alpha and powerpcspe
   
   where perl_5.18.1-5 was used.
   
   (The rest of the architectures have not yet been tried.)
   
   Please update perl to perl_5.18.1-5 on the buildds, then try the condor
   build again.
   
 Mattias
   
   
   
   The build on armel seems to be stuck as well due to the buggy perl
   version. Please update perl to version 5.18.1-5 in the armel buildd
   build roots and then try the build of condor again.
   
   With the 5.18.1-4 version perl gets into an eternal loop and never
   finishes.
   
 Mattias
   
  
  The condor build on armel is now the only one that has not been
  attempted using perl 5.18.1-5.
  
  The old condor build on armel is currently the only remaining package
  that is still using libgsoap3. A successful rebuild of condor on armel
  would complete the libgsoap3 → libgsoap4 migration and would allow a
  number of stalled packages to migrate to testing.
  
  perl 5.18.1-5 was built on armel 2013-12-07. It is now more than 3 weeks
  later and the armel buildd build roots still use the buggy perl
  5.18.1-4...
  
  Mattias
  
 
 



-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140101132449.ga24...@afflict.kos.to

Re: Proposal to replace/extend current armhf builders

[Riku Voipio]

  I think we need to bash out some criteria for deciding  during the
  mini-debconf. i.e deciding how we decide (or just make a decision if
  possible).
 
 Better to decide now rather than wait for the perfect solution next
 year (which might have other problems other than price). Better is
 Good's worst enemy.

Wearing my armel buildd maintainer hat, I don't feel the same urgency
as you seem to have - perhaps that's because the armel buildd'd are less
ram-starved than the locos?

  e.g hold out for server-grade kit for a while - if so how long? (0
  months, 3 months, 6months, longer?)
 
 If it was a vote, I'd say get some cheap hardware now to replace the
 current builders, say costing under an absolute limit of 1000GBP
 (total: disks, boards, cases, PSU, multiserial terminals, etc). That
 might even get lower if we accept the Nitrogen6X offer. And reevaluate
 the situation in 12 months when arm server class becomes available
 (arm64 or arm32).

One thing I'd like to avoid is growing the diversity of buildd's we
have. If we have many different buildd hardware, each of buildd
classes needs different kind of maintainence. So when add a new type
of hw for buildd's, it should go in tandem of getting rid of another
type of hw.

So if we go with nitrogenx 2GB, are we ready to get rid of locos?

  Is debian kernel an absolute requirement, or are we prepared to risk a
  custom kernel if we think it'll only be for 6 months? 

 If DSA absolutely requires kernel support then I don't think there is
 much we can do. And I don't think that's a promise anyone could actually
 make, that we expect mainline support to be fixed in the next 6 months.

It's not just DSA, it is also in our porters best interests. We don't
want to end up in the situtation where glibc/udev/systemd/ruby needs
features from a new kernel version, while we are stuck in a old kernel.

Riku


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131115155033.ga23...@afflict.kos.to

Cross Distribution sync on ARM issues session at Linaro connect

[Riku Voipio]

Hi everyone,

After a break, we are again having a cross distribution collaboration
session[1]. The event is on wednesday 12.10pm PST (aka 19.10 UTC). The
session will be broadcast on google hangouts[2] for remote
participation.

If you have any great ideas you think other ARM distributions would
benefit as well, wish to see something standardized, or have some
gripes about supporting ARM - now is your chance to get heard. If you
can't make it on wednesday (or just want to start discussing
already!), feel free to email the cross-distro mailing listing and I
can get it added to the agenda anyways.

Riku

[1] http://lcu-13.zerista.com/event/member/85125
[2] 
https://plus.google.com/events/c73vv18k4b74g8ku7frnp31h4jc?partnerid=gplp0eto


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caaqcghk8s1jiad5odf9jbjniiwasah4wunx7pznepx0fdpp...@mail.gmail.com

Re: Roll call for porters of architectures in sid and testing

[Riku Voipio]

On Sun, Sep 01, 2013 at 09:33:51AM +0200, Niels Thykier wrote:
 If you are (or intend to become) an active porter for the lifetime of
 jessie, then please send a signed email explaining your involvement in
 the port to the Release Team debian-rele...@lists.debian.org before
 1st of October 2013. Please explain the level of your involvement in
 the port.

Sorry I missed the deadline, but I guess the information is still
valuable. 

Hi,

I am active porter for armel and also help on armhf and arm64.
I intend to continue helping for the lifetime for jessie.

For armel, I
 - maintain the buildd's, file bugs on failed builds
 - provide packagers bugfixes in case they are unable to fix armel bugs
   in their package themself

For armel, armhf and possibly in future for arm64:
 - test packages on the architectures
 - fix arch-related bugs

I am a DD,

Riku Voipio


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131007101951.ga16...@afflict.kos.to

Re: Results of the porter roll call (Was: Roll call for porters of architectures in sid and testing)

[Riku Voipio]

On Wed, Oct 02, 2013 at 04:07:25PM +0100, Wookey wrote:
 +++ Niels Thykier [2013-10-02 09:45 +0200]:
  armel: Wookey (DD), Gatis Visnevskis (!DD), Nobuhiro Iwamatsu (DD), Steve 
  McIntyre (DD)
  armhf: Jeremiah Foster (!DD, but NM?), Wookey (DD), Justus Winter (!DD), 
  Lennart Sorensen (!DD), Nobuhiro Iwamatsu (DD), Steve McIntyre (DD)
 
 I am surprised not to see Riku Voipio and Hector Oron on this list as
 I know they help manage the buildds and Riku signs uploads. I don't
 know if they are trying to escape, or just being too slack to send
 mail :-)

Sorry, I missed the fact that this request had a deadline. Anyways,
I am available for arm related issues - just try not to use debian-devel
to reach me, as I tend to just skim subjects here...

Riku


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131007102229.gb16...@afflict.kos.to

Re: the SoC GPU driver interview

[Riku Voipio]

On Fri, Apr 26, 2013 at 09:26:28AM +0100, Luke Kenneth Casson Leighton wrote:
 On Fri, Apr 26, 2013 at 3:49 AM, Paul Wise p...@debian.org wrote:
  This is a great interview with folks doing reverse engineering of ARM
  GPU drivers and devices.
 
  http://blog.emmanueldeloget.com/index.php?post/2013/03/08/The-SoC-GPU-driver-interview
 
  Only the PowerVR reverse engineering folks are missing from it:
 
  that's because there's no funding for their efforts, nor is there
 anyone who is financially sufficiently independent to be able to pay
 attention for the required minimum of one man-year of full-time effort
 required to complete the work.

I think it's rather the PowerVR architecture is too complex to RE.
There is a huge firmware the driver loads to the powervr gpu you would
have to reverse engineer first - reverse engineering the command stream
from the driver doesn't get you anywhere, as you would get firmware
rather than gpu commands...

Anyone who's actually worked with powervr tend to say it's a horrible mess 
tell you to run away from the hardware if you can.

Then again, that is quite similar to the Videocore setup that someone actually
decided to start reverse engineering...

Anyways, rather than push for more reverse engineering projects to get
started, I think we should concentrate in finishing the current projects.

Riku


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130426114702.ga10...@afflict.kos.to

Re: arm build hardware

[Riku Voipio]

On Wed, Mar 13, 2013 at 11:16:42PM +, peter green wrote:
 After the bad stuff i'm reading about the arndaleboard (apparently
 problems even at 1.4 GHz despite the advertised speed being 1.8 GHz)

pandaboards were not particularry stable when people started using them. 
Likewise, using the early kernels with imx5 boards was not a happy
experience. 

 i'm thinking the 2GB nitrogen6x is the best option right now.
 Has anyone here hammered on a nitrogen6x or similar board? is it
 stable at the advertised 1GHz with all cores loaded?

Btw compulab is offering imx6 with upto 4G of RAM:

http://compulab.co.il/products/computer-on-modules/cm-fx6/#ordering

The price will unfortunately rack up especially for small orders.

Riku


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130326140841.ga18...@afflict.kos.to

Re: Add new armhf flavor armada370xp

[Riku Voipio]

On Wed, Mar 06, 2013 at 06:09:11AM +, Steve McIntyre wrote:
 On Tue, Mar 05, 2013 at 11:22:23PM +, peter green wrote:
 Each flavor of armel and armhf should have the same function, too.
 IMO if you think you can support all armada series devices that are
 likely to run debian armhf from one kernel flavour then you should
 just call the flavour armada (similar to the way the flavour that
 covers beagle/panda/etc is just called omap)
 
 Definitely, yes. Hopefully in the longer term we'll be able to run
 more of the ARMv7+ machines with single kernels using DT, but that's
 not going to happen overnight.

I hope we could be more ambitious and enter the single zImage /
multiplatform setup early. We could start by simply calling the
armada370 / armadaxp flavour multiplatform. And then any new
architectures would only be added by including them to multiplatform
flavour - and only accepted if adding doesn't break existing platforms
supported by our multiplatform kernel.

Riku


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130307072742.ga11...@afflict.kos.to

Re: potential new build hardware, arndaleboard samsung exynos 5,?2GB?ram

[Riku Voipio]

On Sat, Dec 01, 2012 at 06:24:32PM +, Phil Endecott wrote:
 Phil Endecott spam_from_debian_arm at chezphil.org writes: 
  peter green plugwash at p10link.net writes:
   It looks like a new samsung based devboard has come out (though it's not 
   scheduled to actually ship until november).
  
  Ignore it until it actually exists.
 
 Maybe it does now exist, and is worth investigating :-)

Have now one as well, so it clearly does exist :)

One thing that might surprise people used to beagleboard/pandaboard
style boards is that this one is actually quite large. 

Booting and running the board using the quick setup instructions from:

https://wiki.linaro.org/Boards/Arndale/Setup/EnterpriseUbuntuServer

Work just fine. The kernel is quite fresh (3.7-rc2 based) and is about
4000 lines / 40 changed away from mainline. The only major stumbling
block to debian support is that the exynos kernel isn't single zimage
ready (yet). Also, support for 3D acceleration and video codec
acceleration is android-only and propiertary.

 I agree with Peter that it is an interesting board.  The USB ethernet is
 unfortunate, but looking on the bright side that might be better-supported 
 than
 some unknown SoC ethernet thing.

USB ethernet is ASIX based and seems to work fine (once you set up mac
address). eSATA didn't work for me reliably, but sata code is still said to be
work in progress and my HD isn't in the list of (currently) supported
drivers of the above wikipage.

Riku


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121204092247.ga22...@afflict.kos.to

Re: potential new build hardware, arndaleboard samsung exynos 5,?2GB?ram

[Riku Voipio]

On Tue, Dec 04, 2012 at 11:28:35AM +0100, Arnaud Patard wrote:
  USB ethernet is ASIX based and seems to work fine (once you set up mac
  address). eSATA didn't work for me reliably, but sata code is still said to 
  be
  work in progress and my HD isn't in the list of (currently) supported
  drivers of the above wikipage.
 
 what do you mean ? if one wants to use sata, one has to use one of the
 HD listed ? that sounds weird/wrong and rather annoying in case you need
 to replace a failing drive.

What I believe, is that sata driver simply isn't complete yet. Eventually
it should be fixed to implement all required features. At least since
the controller behind the platform code is AHCI, it would be surprising
if it was a hw issue rather than a driver issue.

Riku


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121204143630.ga23...@afflict.kos.to

Re: Seagate GoFlex Satellite

[Riku Voipio]

On Sat, Aug 25, 2012 at 09:29:11PM -0700, Braddock Gaskill wrote:
 Unfortunately no such luck.  I disassembled my GoFlex Satellite this
 morning and the CON1 connector is for the battery.

That's unlucky then..

 If you see anything I might try please let me know.

You could try connecting a powered-off GoFlex Satellite to a PC, boot it
and see if there is activity on the USB. Some omap systems are can boot
from host USB and/or export a boot console over there. 

Also, did you see any mention of GPL sources in product documentation or
support website?


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120827082954.ga1...@afflict.kos.to

Re: Seagate GoFlex Satellite

[Riku Voipio]

On Mon, Aug 13, 2012 at 09:41:15PM -0700, Braddock Gaskill wrote:
 
 Is there much hope of getting Debian running on a Seagate GoFlex
 Satellite?  This is a very sexy little Linux-based device which encloses a
 500GB harddrive with wifi and runs off a battery.

According to the following article, Seagate GoFlex runs using TI AM3703,
which should be supportable with with Debian armhf omap3 kernel -
assuming the right device drivers are added. 

http://www.anandtech.com/show/4706/understanding-wireless-storage-kingston-widrive-and-seagate-goflex-satellite

I certainly see potential for wireless portable Debian server.

 What would be involved in getting Debian to run?  Where would I start?  Is
 anyone interested in working on this?

Getting the results of dmesg command and the kernel sources would be
the first step. After that, finding the serial port or JTAG port.

Riku


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120817180206.ga20...@afflict.kos.to

yade will no longerbe built on armel/armhf

[Riku Voipio]

Hi,

yade takes obscene amounts of RAM during builds, causing excessive build
times due to swapping on armel/armhf buildds. Since it does not seem to
be a package likely to be run ARM machines in near future, we have
disabled building it for now.

Riku


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120606145438.ga1...@afflict.kos.to

Re: armel qualification for Wheezy

[Riku Voipio]

On Wed, May 23, 2012 at 09:02:33PM +0100, Tixy wrote:
 I may be being naive, but could an X86 PC be used with an ARM chroot and
 qemu-arm-static to emulate ARM instructions? Or is qemu not stable
 enough, or the emulated environment different enough that package
 building would fail (e.g. through use of uname)?

It has been discussed before. Qemu linux-user is generally stable enough
these days as long as package being built doesn't try to anything fancy
(eg. run testsuites). That said when you hit problems, 1) they might
slip under the radar and users end up hitting them much later 2)
debugging and fixing them might be timeconsuming - we still have
deadlocks in qemu threading code which have been hunted for years.

So ideally I'd prefer ARM hardware targetted for servers - where the
current memory and IO bandwidth issues wouldn't be the problem it is
in the current mobile-targetted hardware.

Riku


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120525065327.ga11...@afflict.kos.to

Re: armel qualification for Wheezy

[Riku Voipio]

On Mon, May 21, 2012 at 10:00:53AM +0200, Luk Claes wrote:
 ancina is a developer's board, so what components should be in the
 shipping if we go that route?

The board, memory at least, hard drive would be great as it would save
the pain of reinstall. The rest (PSU, cables) I think Steve and Mark can
source if you have other uses for the ones currently in ancina.

 How long would it take to have better machines than ancina so it could
 just get fased out btw?

Sigh, I year ago when armhf buildd's were being chosen, I was expecting
to see significantly faster HW available by now. But things like ARM
servers seem always to be at least half year in future...

If we really want to replace ancina quickly, we could get some i.mx53
quick start boards like the ones currently used as armhf buildd's. I'd
like not to introduce new hardware models as buildd's unless they are
significantly faster as the old ones.

 On another note, the only reason ancina cannot get OOB access is because
 it's not rack mountable. We can easily provide OOB access for rack
 mountable things and probably could even provide more rackspace for
 Debian things (have to get that confimed though if it's something worth
 considering?).

I think ancina should fit in a rack case just fine - Just can't be attached
to standard ATX screw locations. I believe the mv78x00 boards like
ancina at ARM are installed into a rack somehow. Steve knows details I
think?

Riku

Riku


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120521141541.gb22...@afflict.kos.to

Re: armel qualification for Wheezy

[Riku Voipio]

Hi,

On Sat, May 19, 2012 at 10:57:03AM +0200, Luk Claes wrote:
 As everyone keeps claiming there is no armel buildd location redundancy,
 I don't have much motivation to keep ancina running. It's ignored anyway.

Would you mind packaging ancina and posting it to another hosting
location? IIRC Mark Hymers was interested and he already hosts a bunch
of armhf buildd's.

Riku


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120519150024.ga12...@afflict.kos.to

Re: N2100 Bricked - Redboot rescue needed

[Riku Voipio]

Hi,

  IIRC I saw that when I had a bad ram DIMM installed. So it could be
  that some
  of your hardware components has got loose/dusty.
 
 I will give a try, but I think I may have bricked the RedBoot.
 Is there a serial RedBoot rescue mode possible, like in UBoot [2] ?
 
 Is there any technicals references or tools for booting RedBoot by serial ?

Note if you believe that redboot is bricked, any rescue mode *in* redboot 
wouldn't
help. What you describe in your uBoot link is not a uBoot feature, but a 
kirkwood
SoC feature.

N2100 comes with intel iop321 SoC, and I dont remember if it has a serial boot
mode. If it has, it can be discovered from the Intel Technial reference 
manuals[1].

If IOP doesn't come with a serial boot feature, you will essentially need
JTAG access. Or alternatively desolder the flash chip and flash it with separe
flasher board.

[1] http://int.xscale-freak.com/XSDoc/IOP321/IOP321_index.htm


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2006105640.ga9...@afflict.kos.to

Re: N2100 Bricked - Redboot rescue needed

[Riku Voipio]

Hi,

On Sat, Nov 05, 2011 at 05:53:03PM +0100, DrEagle wrote:
 I have two Thecus N2100 Bricked and make a call for some help !
 
 I have soldered a RS232 on the SATA Board, as explained here and [1] on
 my wiki [2].
 
 With the serial console I have one of the Thecus that only show a + at Boot.

IIRC I saw that when I had a bad ram DIMM installed. So it could be that some
of your hardware components has got loose/dusty.
 
 The other one hang at booting debian kernel :
 
 RedBoot exec -c console=ttyS0,115200 root=/dev/ram0 initrd=0xa080,42M
 Build ATAG
 ATAG_MEM: Overwrite ram_end with real_region_top=0x2000, memsize=512 M
 ATAG_MEM=536870912@0xa000, MACH_TYPE=1101
 Using base address 0x0020 and length 0x0016
 
 Is there any method to get the kernel and initrd from TFTP and reflash
 them into RedBoot ?

See the commands listed here:

http://www.cyrius.com/debian/iop/n2100/telnet.html
 
 Where can I get the kernel and initrd ?

Debian-installer kernel and ramdisk should be good:

http://ftp.uk.debian.org/debian/dists/stable/main/installer-armel/current/images/iop32x/network-console/
 

 Is there any rescue method for Debian without bricking ?
 
 Amicalement,
 -- 
 Gk2 [:-]
 
 [1] david.thg.se/n2100/addserial.html
 [2] doukki.net/doku.php?id=wiki:notes:n2100
 



-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2005200237.ga5...@afflict.kos.to

Re: Getting rid of alignment faults in userspace

[Riku Voipio]

On 18 June 2011 22:17, Nicolas Pitre nicolas.pi...@linaro.org wrote:
 Turns out that a prominent ARM developer still has binaries from the
 ARMv3 era around, and the default of not fixing up misaligned user space
 accesses is for remaining compatible with them.

 So if you do have a version of glibc that is not from 15 years ago (that
 would have to be a.out and not ELF if it was) then you do not want to
 let misaligned accesses go through unfixed, otherwise you'll simply have
 latent data corruption somewhere.

Can we tie the alignment correction default to depend if a.out support is in the
kernel or not?

Riku


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/banlktikf4bomemvjj+d4q5outaoeaow...@mail.gmail.com

Re: fpc: FTBFS on armel: An unhandled exception occurred at $00033B60

[Riku Voipio]

On Sun, Mar 27, 2011 at 12:12:16AM +, peter green wrote:
 I have tried and failed to reproduce this issue in qemu with an up to  
 date sid. Can anyone else reproduce it? Since both failures have been  
 from the same buildd I wonder if it's some issue with the particular 
 buildd.

Tried it on another buildd and got the same issue. There a few things
qemu doesn't emulate, for example alignement errors.

Riku


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110327080332.ga17...@afflict.kos.to

Re: gcc-4.6 build failure on armel

[Riku Voipio]

On Tue, Mar 22, 2011 at 12:50:17AM +, Hector Oron wrote:
 Hi,
 
 2011/3/21 Matthias Klose d...@debian.org:
  gcc-4.6 fails to build on the buildds with an ICE.  Unable to reproduce on a
  local armv5t machine.  Please could an ARM porter reproduce this ICE and 
  attach
  the requrest information to upstream PR 48173?
 
 I was able to reproduce:

on abel.debian.org ?
 
 $ /home/zumbi/gcc-4.6-4.6.0~rc1/build/./prev-gcc/xgcc
 -B/home/zumbi/gcc-4.6-4.6.0~rc1/build/./prev-gcc/
 -B/usr/arm-linux-gnueabi/bin/ -B/usr/arm-linux-gnueabi/bin/
 -B/usr/arm-linux-gnueabi/lib/ -isystem /usr/arm-linux-gnueabi/include
 -isystem /usr/arm-linux-gnueabi/sys-include-c   -g -O2 -gtoggle
 -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes
 -Wmissing-prototypes -Wmissing-format-attribute -pedantic
 -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
 -Wold-style-definition -Wc++-compat  -Wno-error -DHAVE_CONFIG_H -I.
 -I. -I../../src/gcc -I../../src/gcc/. -I../../src/gcc/../include
 -I../../src/gcc/../libcpp/include  -I../../src/gcc/../libdecnumber
 -I../../src/gcc/../libdecnumber/dpd -I../libdecnumber
 ../../src/gcc/expmed.c -o expmed.o
 ../../src/gcc/expmed.c: In function ‘init_expmed’:
 ../../src/gcc/expmed.c:159:3: warning: array subscript is above array
 bounds [-Warray-bounds]
 xgcc: internal compiler error: Segmentation fault (program cc1)
 Please submit a full bug report,
 with preprocessed source if appropriate.
 See file:///usr/share/doc/gcc-4.6/README.Bugs for instructions.
 
 Preprocessed source available at:
 http://people.debian.org/~zumbi/tmp/expmed.o.gz
 
 -- 
  Héctor Orón
 
 Our Sun unleashes tremendous flares expelling hot gas into the Solar
 System, which one day will disconnect us.
 
 -- Day DVB-T stop working nicely
 Video flare: http://antwrp.gsfc.nasa.gov/apod/ap100510.html
 
 
 --
 To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
 Archive: 
 http://lists.debian.org/AANLkTi=jR5BFMEO9=N=_n_9atsv+zmjxpzvsgtgl4...@mail.gmail.com


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110323135218.ga1...@afflict.kos.to

Re: dpkg armhf patch acceptance status?

[Riku Voipio]

On Fri, Feb 18, 2011 at 04:27:52AM +, Luke Kenneth Casson Leighton wrote:
  precisely.  this is another, (clearer or at least different) way of
 stating what i've been advocating.  by having such a delta-maintaining
 tool, complex sets of deltas can be maintained indefinitely, or in
 fact completely reworked.

We dont *want* to maintain deltas. If we start maintaining deltas, we are no
longer Debian, we are a fork. Lets end this discussion now.


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110218095330.ga25...@afflict.kos.to

Re: armhf performance of vorbisgain

[Riku Voipio]

On Wed, Aug 11, 2010 at 02:48:51AM +, Clint Adams wrote:
 In summary, it takes less than half the time to do the
 run with armhf than it does with armel.

Can you also test vorbisgain performance with regular armel port
and with compiler flags of:

-march=armv7-a -mtune=cortex-a8 -mfpu=vfpv3-d16 -mfloat-abi=softfp

 [0] http://people.debian.org/~schizo/tmp/armhf/vgain-test-harness
 [1] http://people.debian.org/~schizo/tmp/armhf/vgain.test.out
 [2] http://people.debian.org/~schizo/tmp/armhf/vgain.test.gnumeric


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100818205545.ga32...@afflict.kos.to

Re: subarch support

[Riku Voipio]

On Tue, Jul 13, 2010 at 03:24:35PM +0200, Loïc Minier wrote:
 On Tue, Jul 13, 2010, Riku Voipio wrote:
  If dpkg had subarchitecture support, lpia wouldn't have been as big
  a issue. Ubuntu decided to shortcut and not add support for compatible
  subarchs in dpkg, and the result was what it always is when people make
  shortcuts...
  
  Subarchs could also be useful if we wanted to build softfp abi compatible
  armv6/armv7 armel builds of the whole debian repository. Of course we could 
  do
  builds without subarchs, but then users would be unable distinguish which
  installed packages are for which cpu, and providing that via debian infra
  would not be possible.

  It sounds like you have good ideas about the subarch concept; would you
  mind expanding on them a bit?

Basicly close to what RPM does, so it is not my idea :) For example:

On X86 one could have i486, i586, i686, atom, core2 - all being subarchs of
i386 and crossinstallable.

On ARM one could have armelv5, armelv6, armelv7, armelv7neon, .., all subarchs
armel and crossinstallable. Before someone jumps what about a ARMv6 with NEON 
but
no VFP, obviously some discretion must be used when selecting subarchs to be
supported.

At package install time, package manager knows on what cpu we are running on,
and can thus select which subarchs are supported. For example a ARMv6 machine
could install armel.deb, armelv5.deb, armelv6.deb packages.

From debian/rules point of view, the package would still building for armel
or i386. If we want, we can add a new DEB_HOST_* variable, but ideally
supported cpu features would be identified ./configure -time from what gcc
accepts with given defaults.

Also, compatible subarchs mean we don't neccessarily need to compile (and 
mirror)
every single package for every subarch. If a package doesn't actually use any
float/double variables, we could jsut skip building it on vfp subarchs. If the
package isn't performance critical at all, just compile it for the base arch.

This way ubuntu wouldn't have just had to drop armv5 support when building armv6
stuff, or make it impossible for lpia users to install i386 .debs.

Riku


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100716091108.ga30...@afflict.kos.to

Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)

[Riku Voipio]

On Fri, Jul 16, 2010 at 09:55:49AM +0100, Martin Michlmayr wrote:
 * Aurelien Jarno aurel...@aurel32.net [2010-07-16 09:38]:
  BTW, has anybody thought about increasing the minimum requirement for
  the armel port, for example to armv5? Available machines has evolved,
  maybe the port should do the same.
 
 Indeed.  From Paul's emails, I'm getting the feeling that moving the
 armel port to armv5

My impression is the ARMv4t - ARMV5 doesn't really gain many useful
instructions (PLD, CLZ), so it is not neccesarily worth it, at least
as long as there ar ARMv4t users (basicly openmoko).

 and proving optimized libraries for some things might be the way to go.

And when the performance critical code is not in a library but in a binary?


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100716094141.ga30...@afflict.kos.to

Re: armelfp: new architecture name for an armel variant

[Riku Voipio]

On Thu, Jul 08, 2010 at 01:06:58PM +0200, Guillem Jover wrote:
 Personally, before any further discussion I'd like to see some numbers
 with core libraries (libc, libgcc, libgmp, libatlas? etc) built with
 softfp, which eventually might be able to switch to use the hwcaps
 infrastructure in a similar way as how packages like libc6-i686 are
 handled.

The key limitation with hwcap approach is that it only extends to shared
libraries. Optimized binaries and plugins cannot be provided with hwcaps.
Things like libc-i686 are also problematic for endusers. How do I
quickly install all 686 optimized versions of libraries I already have?

 Adding a new (official) architecture variant is a huge overhead for
 everyone, it implies adding new porter boxes, patching packages (but
 hopefully not many) to handle the new arch, having someone handle the
 build daemons,

Adding a new arch creates a big overhead for *selected* people, rather than
everyone - most packagers in debian are unaffected. Multiple libraries
is not exactly zero-effort either, there could easily be hundreds libraries
we could want optimized. That is if we want to provide a *good* service
to users with VFP's rather than a lipservice. And we still wouldn't have
a vfp version of quake2.

 The lpia is a great example of an architecture variant that was a
 mistake, and should haver never been created.

LPIA was mainly a issue since people used it as if arch=lpia then build
mobile ui. That prevented users from installing full versions of software
or trying mobile UI's in regular i386 installations.

If dpkg had subarchitecture support, lpia wouldn't have been as big
a issue. Ubuntu decided to shortcut and not add support for compatible
subarchs in dpkg, and the result was what it always is when people make
shortcuts...

Subarchs could also be useful if we wanted to build softfp abi compatible
armv6/armv7 armel builds of the whole debian repository. Of course we could do
builds without subarchs, but then users would be unable distinguish which
installed packages are for which cpu, and providing that via debian infra
would not be possible.

But the key difference with lpia and hardfloat armel is that they are not binary
compatible. And if we use it as a opportunity to target armv7+, do not really
share much of hardware either.


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100713130615.ga14...@afflict.kos.to

Re: armelfp: new architecture name for an armel variant

[Riku Voipio]

On Tue, Jul 06, 2010 at 10:55:25PM +0200, Loïc Minier wrote:
 On Tue, Jul 06, 2010, Joey Hess wrote:
  Could the targeted CPU be used in the name? Ie, armelv7.

Or even just armv7. It is just a name, so it should be short and
not try to encode too much information in it.
 
  I would be a bit scared that this has a chance of getting out of date,

we have i386 port and nobody has an issue with 2 decades old name.

  or be confusing because other ports might be v7 as well

There might be a big-endian port, but I find it very unlikely we would
make another port baselined on armv7.


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100708115858.ga29...@afflict.kos.to

Re: Bug#584610: [mips] gcc-4.4 build failure after upgrade to eGLIBC-2.11

[Riku Voipio]

On Mon, Jun 07, 2010 at 09:15:05AM +0200, Matthias Klose wrote:
 On 06.06.2010 00:51, Aurelien Jarno wrote:
 These functions were present before in the library, but not exported
 in the headers. This has been changed as it is required by ISO C99.

 While these functions are strictly not needed in libstdc++6 anymore, we
 have two options:
 - revert the GLIBC change, which means we break the C99 compatibility
(as before)
 - patch GCC to export these functions anyway.

 What's your opinion?

 For ARM I did choose the second option, but didn't get any feedback about 
 it. So maybe it's time to ask the mips and arm porters?

 The patch applied for armel is:
 http://svn.debian.org/viewsvn/gcccvs/branches/sid/gcc-4.4/debian/patches/libstdc%2B%2B-arm-ldbl-compat.diff?view=log

I'm fine with this fix.

Riku


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100607115104.gb14...@afflict.kos.to

Re: possibly 'stuck' build?

[Riku Voipio]

 I see that protobuf is being build for more than 8 days on ancina. However,
 last time when it was built successfully it took 1h:10m (also on ancina), and 
 a
 previous failed build took also 1h:10m.

Was built yesterday. The official contact for buildd issues is 
ar...@buildd.debian.org

Riku


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100607114955.ga14...@afflict.kos.to

fpc bootstrapping

[Riku Voipio]

Hi,

was written ages ago:
 free pascal needs bootstrapping.

 I started trying with roughly the following recipie (note: these should be
 equivilent to what I did but I also went down a lot of dead ends, did things
 in a less sensible order etc)

 So IMO the thing to do is to wait for the next major release of freepascal
 before trying further to introduce it to debian armel

Now 2.4.0 was introduced to sid, does someone have time to try bootstrapping 
again?

full original mail at:

http://lists.debian.org/debian-arm/2009/08/msg00080.html


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: the mangling of ‘va_list’ has cha nged in GCC 4.4

[Riku Voipio]

Hi debian-release,

There is a major problem with gcc 4.4 and armel - the ABI of va_list 
changed (for c++ libraries). We need to decide one of the following:


1) library package name rename (like c2a rename previously)

+ the right thing to do
+ partial upgrades work as expected
- Some hassle for !armel sid users while transition happens
- Quite a bit of extra work for many unrelated people (maintainers, 
ftp-masters..)


2) binNMU campaign

- during the upgrade armel sid users packages will be broken (some 
already are)

- even after, partial upgrades for armel users risk broken setups
+ does not disturb !armel users
+ no extra work for others but porters and release team

3) g++ downgrade or reverting to the old va_list mangling within g++4.4 
for armel


- A bunch of libraries and binaries have already been compiled with the 
new g++

- I think this is a bad idea anyway

What way should we proceed? The list of supposedly affected packages 
follow (haven't had time to check myself).


Jakub Wilk wrote:

[Please Cc me, I'm not subscribed.]

Indeed, I believe that the following binary packages, which ship 
shared libraries, are affected (i.e. linking to them will cause 
problems):


beast
boinc-dev
coinor-libipopt0
csladspa
htdig
icedove
kompozer
libace-5.6.3
libassa3.5-5
libavifile-0.7c2
libclthreads2
libclucene0ldbl
libcsnd-java
libcsnd5.2
libcsoundac5.2
libcwidget3
libdar64-4
libebml0
libfox-1.6-0
libfreehdl0
libgdal1-1.6.0
libggadget-1.0-0
libggadget-1.0-0a
libgnomecanvasmm-2.6-1c2a
libgnuradio-core0
libinsighttoolkit3.16
libkbluetooth0
libkwwidgets1.0.0908
liblog4cpp5
libmailutils2
libmrpt-core0.8
libnewpki2
liborsa0c2a
libparagui1.1
libpoppler-qt4-3
libpoppler5
libpt-1.10.10
libpt-1.11.2-plugins-avc
libpt-1.11.2
libpt2.6.5
libqtcore4
librlog5
libsefs4
libsetools-jni
libsetools-tcl
libusbprog0
libvtk5.2
libwfnetobjs0c2
libwvstreams4.6-extras
libwxbase2.6-0
libwxbase2.6-dbg
libwxbase2.8-0
libwxbase2.8-dbg
libwxgtk2.6-0
libwxgtk2.6-dbg
libwxgtk2.8-0
libwxgtk2.8-dbg
nemiver
octave3.0
octave3.2
paraview
python-csound
python-setools
python-xpcom
setools
vlc
xorsa




--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: the mangling of ‘va_lis t’ has changed in GCC 4.4

[Riku Voipio]

On Wed, Jan 27, 2010 at 11:19:35PM +0200, Modestas Vainius wrote:
 Hello,
 
 On trečiadienis 27 Sausis 2010 22:47:55 Riku Voipio wrote:
  There is a major problem with gcc 4.4 and armel - the ABI of va_list
  changed (for c++ libraries). We need to decide one of the following:
  
  1) library package name rename (like c2a rename previously)
  
  + the right thing to do
  + partial upgrades work as expected
  - Some hassle for !armel sid users while transition happens
  - Quite a bit of extra work for many unrelated people (maintainers,
  ftp-masters..)
  
  2) binNMU campaign
  
  - during the upgrade armel sid users packages will be broken (some
  already are)
  - even after, partial upgrades for armel users risk broken setups
  + does not disturb !armel users
  + no extra work for others but porters and release team
  
  3) g++ downgrade or reverting to the old va_list mangling within g++4.4
  for armel
  
  - A bunch of libraries and binaries have already been compiled with the
  new g++
  - I think this is a bad idea anyway
  
  What way should we proceed? The list of supposedly affected packages
  follow (haven't had time to check myself).
 
 4) it is also possible to manually create aliases that are mangled in the old 
 way (va_list as void*) next to the symbols which g++-4.4 will auto-generate. 
 This means some work for the maintainers (and porters) of the directly 
 affected library packages (fortunately, the list of which does not seem to be 
 huge). However, we win:
 
 1) no painful transitions or disturbance on any arch including armel (i.e. it 
 won't be worse than it is now);
 2) no massive binNMUs of rdeps;
 3) less work for the release team except tracking how affected libraries are 
 being fixed;
 4) no extra work for other teams.

Interesting. Do you have a example on howto do that?


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: gcl and reverse dependencies on arm

[Riku Voipio]

On Wed, Jan 27, 2010 at 04:56:22PM -0500, Camm Maguire wrote:
 Greetings!  OK I think we've found it.
 
 A long time ago, some very helpful arm developer told me how to clear
 the instruction and data caches.  GCL needs to do this as it loads
 compiled code into its .data section, relocates it, clears the cache,
 and then executes.  
 
 Here is the arm bit:
 
 #define CLEAR_CACHE do {\
   void *v=memory-cfd.cfd_start,*ve=v+memory-cfd.cfd_size; \
   register unsigned long _beg __asm (a1) = (unsigned long)(v);  \
   register unsigned long _end __asm (a2) = (unsigned long)(ve);\
   register unsigned long _flg __asm (a3) = 0;   \
   __asm __volatile (swi 0x9f0002 @ sys_cacheflush   \
   : =r (_beg)   \
   : 0 (_beg), r (_end), r(_flg));   \
 } while (0)

swi 0x9f0002 is a old way to call syscalls. in EABI things were changed.
Some buildd's still have old-abi compat enabled in kernel, which is why
the code works on them.

But we now have a gcc built-in that does the right thing on both old and
new abi:

  __clear_cache (beg, end);
 
 
 Since this time, many architectures use more portable alternatives
 like mprotect.  In any case, the above seems to be fine on agricola:
 
 =
 Processor : XScale-80219 rev 0 (v5l)
 BogoMIPS  : 593.10
 Features  : swp half thumb fastmult edsp 
 CPU implementer   : 0x69
 CPU architecture: 5TE
 CPU variant   : 0x0
 CPU part  : 0x2e3
 CPU revision  : 0
 Cache type: undefined 5
 Cache clean   : undefined 5
 Cache lockdown: undefined 5
 Cache format  : Harvard
 I size: 32768
 I assoc   : 32
 I line length : 32
 I sets: 32
 D size: 32768
 D assoc   : 32
 D line length : 32
 D sets: 32
 
 Hardware  : Thecus N2100
 Revision  : 
 Serial: 
 =
 and muscat
 =
 Processor : XScale-80219 rev 0 (v5l)
 BogoMIPS  : 593.10
 Features  : swp half thumb fastmult edsp 
 CPU implementer   : 0x69
 CPU architecture: 5TE
 CPU variant   : 0x0
 CPU part  : 0x2e3
 CPU revision  : 0
 
 Hardware  : Thecus N2100
 Revision  : 
 Serial: 
 =
 but not your machine:
 =
 Processor : Feroceon rev 0 (v5l)
 BogoMIPS  : 999.42
 Features  : swp half thumb fastmult vfp edsp 
 CPU implementer   : 0x41
 CPU architecture: 5TE
 CPU variant   : 0x1
 CPU part  : 0x926
 CPU revision  : 0
 
 Hardware  : Marvell DB-78x00-BP Development Board
 Revision  : 
 Serial: 
 =
 
 Oddly, it works for many addresses, but faults on some.  This is even
 with the /proc/cpu/alignment flag being 0 (ignored).
 
 Suggestions?
 
 Thanks again!
 
 Riku Voipio riku.voi...@iki.fi writes:
 
  Greetings and sorry for the delay,
 
  ssh -p 2224 c...@kos.to
  sudo /usr/sbin/chroot /home/camm/chroot su - camm
 
  gcl, maxima and acl and extracted there already and have
  ther build-deps installed.
 
  On Mon, Jan 25, 2010 at 10:52:30AM -0500, Camm Maguire wrote:
  Greetings!  This might be a duplicate -- if so, my apologies!
  
  Thanks again!
  
  Riku Voipio riku.voi...@iki.fi writes:
  
   On Sat, Jan 23, 2010 at 11:36:30AM -0500, Camm Maguire wrote:
   Thank you so much.  I'll wait to here from you then.  The issues of
   importance are segafaults on object code loading, e.g.
  
   Ok. I can reproduce the issues on experimental buildd. Please send me
   a ssh key in a pgp signed mail with your preferred account name and I'll
   create a account for you.
  
   Riku
  
  
  
  
  
  -- 
  Camm Maguire   
  c...@maguirefamily.org
  ==
  The earth is but one country, and mankind its citizens.  --  Baha'u'llah
 
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
  
  Username: camm
  
  ssh-rsa 
  B3NzaC1yc2EBIwAAAIEAtseLLbrS7utxoresgHYJtfUCLckotAcc6SfOqjg1MVrV77GNSuNfR+6iX7ahLDnbNtGzauDJM+8/H0hx2dM0+UMy92betwF+2TYjHfSucsoWhb2kSNUwIFiq714NdSa1vdcEEV/jLQ2v4fDCMew9X2NnzAxovCTSEcRCmMEenaU=
   c...@wisdom
  -BEGIN PGP SIGNATURE-
  Version: GnuPG v1.4.10 (GNU/Linux)
  
  iEYEARECAAYFAktdvdgACgkQczG1wFfwRdwtRgCeOKbBmnQrvdVQsbGGUXjMNtmY
  FIAAoLh5uXAEFQGB5N1EKxJFmoYZsXR4
  =nDYr
  -END PGP SIGNATURE-
 
 
 
 
 
 
 -- 
 Camm Maguire  c...@maguirefamily.org

Re: debian install for KURO-SHEEVA

[Riku Voipio]

Hi Masakazu Asuma,

To the original poster - can you point us to the Linux kernel sources
and/or results of dmesg command on the KURO-SHEEVA?

On Thu, Dec 10, 2009 at 10:04:30AM +, Martin Michlmayr wrote:
 The SheevaPlug platform code does not initialize PCI since the
 SheevaPlug doesn't have PCI.  It probably makes sense to add a
 separate platform file for the KURO-SHEEVA but I don't know any
 details about this device so I cannot say for sure.

OTOH if the current SheevaPlug kernel in squeeze works otherwise
in kuro-sheeva (as from the original post it seems), it is probably
not worth adding another machine id for it? Would it break booting on
original sheevaplug, if we add probing the builtin kirkwood sata
controller to the current sheevaplug platform?


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Bug#547503: git-core: git clone fails on armel

[Riku Voipio]

On Sun, Nov 08, 2009 at 07:14:25PM -0600, Jonathan Nieder wrote:
 Hi arm porters,
 
 Can you reproduce this problem?  If so, any ideas on how to fix it?

mv78x00: git clone git://git.sugarlabs.org/sugar-jhbuild/mainline.git 
sugar-jhbuild
Initialized empty Git repository in /schroot/sugar-jhbuild/.git/
remote: Counting objects: 4728, done.
remote: Compressing objects: 100% (2095/2095), done.
remote: Total 4728 (delta 2798), reused 4376 (delta 2577)
Receiving objects: 100% (4728/4728), 1.87 MiB | 206 KiB/s, done.
Resolving deltas: 100% (2798/2798), done.
mv78x00: git clone git://git.gnome.org/jhbuild
Initialized empty Git repository in /schroot/jhbuild/.git/
remote: Counting objects: 20162, done.
remote: Compressing objects: 100% (6726/6726), done.
remote: Total 20162 (delta 15845), reused 16820 (delta 13378)
Receiving objects: 100% (20162/20162), 3.52 MiB | 118 KiB/s, done.
Resolving deltas: 100% (15845/15845), done.
mv78x00:

At the original report:

Kernel: Linux 2.6.31-rc9-flatty-ocf-1-00293-g53a104c (PREEMPT)

Whats this kernel? Which CPU and machine is it on? Zlib is heavily used
throughout debian, so any breakage should have been noted before by others.

Versions of packages git-core depends on:
ii  libc6   2.9-25   GNU C Library: Shared libraries

Seems you have quite old sqeeze setup. Can you try updating?

 Gerrit Pape wrote:
  On Sun, Sep 20, 2009 at 02:08:20PM +0200, Sascha Silbe wrote:
 
  git clone fails on my Debian armel system:
  
  sascha.si...@flatty:~$ git clone 
  git://git.sugarlabs.org/sugar-jhbuild/mainline.git sugar-jhbuild
  Initialized empty Git repository in /home/sascha.silbe/sugar-jhbuild/.git/
  remote: Counting objects: 4772, done.
  remote: Compressing objects: 100% (2079/2079), done.
  error: inflate: data stream error (invalid distance too far back)
  fatal: pack has bad object at offset 616818: inflate returned -3
  fatal: index-pack failed
  sascha.si...@flatty:~$ git clone git://git.gnome.org/jhbuild
  Initialized empty Git repository in /home/sascha.silbe/jhbuild/.git/
  remote: Counting objects: 19804, done.
  remote: Compressing objects: 100% (6374/6374), done.
  fatal: pack has bad object at offset 487227: inflate returned -5
  fatal: index-pack failed
  sascha.si...@flatty:~$ 
  
  Hi Sascha, the bug seems to be in zlib, not git.  git uses the inflate()
  function from zlib, which, in your case, returns the errors -3
  (Z_DATA_ERROR) and -5 (Z_BUF_ERROR).  See /usr/include/zlib.h.
 
 Thanks,
 Jonathan
 
 Please CC me on replies, as I’m not subscribed.
 
 
 -- 
 To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: ext2 file system: moving between armel and amd64 etc.

[Riku Voipio]

Hi Osamu,

On Mon, Oct 26, 2009 at 09:25:36PM +0900, Osamu Aoki wrote:
 I realized that mkfs.ext2 creates different superblock depending on which
 system it is run under.  The difference can be observed by tune2fs -l:
 
  ext2 created by Debian lenny on amd64: 
   Filesystem flags: signed_directory_hash
 
  ext2 created by Ubuntu 09.4 armel: 
   Filesystem flags: unsigned_directory_hash 
 
 It seems it comes from the fact that armel uses unsigned for char.

Ted, can you check if e2fsprogs expects signed char in the code that
checks for signed directory hash?

 Since kernel support of this flag is new and lenny or jaunty one seems
 to ignore it, I could move file between these 2 system.  (I do fsck -p
 to get hash fixed every time I move, first.)  So it works now but this
 is sloppy.
 
 What is the right tool to change this Filesystem flags setting.  I do
 not see in lenny or jaunty.  Can new tune2fs adjust this parameter?
 What is the right way to move ext2 filesystem between system? 

Rather, lets try to get it fixed instead. There should be no reason
to run tune2fs when moving a filesystem from armel to x86 machine.

 PS: I am playing with Sharp PC-Z1.  
   http://wiki.debian.org/InstallingDebianOn/Sharp/PC-Z1NetWalker

Seems like a very interesting device :)


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: arm port plans for the squeeze cycle

[Riku Voipio]

On Tue, Aug 18, 2009 at 08:27:32AM -1000, Martin Michlmayr wrote:
 * Marc Brockschmidt m...@marcbrockschmidt.de [2009-08-16 14:40]:
  Do you have any big changes planned? How much time would they take, and
  what consequences are there for the rest of the project?

  How many big transitions will the upcoming changes cause? When should 
  those
  happen? Can we do something to make them easier?

 Do we have anything to report here?  IMHO, any release date will work
 fine for the ARM port since there are no major issues or transitions.

As mentioned elsewhere on the thread, the biggest deal is getting
openmoko supprted. But I believe it's more of a kernel and d-i team
issue than ARM port issue.

I'd like to throw the ball back to our ARM port users - what are missing
from Debian ARM port?


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: GHC 6.10 for Debian armel?

[Riku Voipio]

On Sun, May 03, 2009 at 11:22:39PM +0300, Riku Voipio wrote:
 On Thu, Apr 30, 2009 at 01:00:35PM +0200, Rickard Nilsson wrote:
  I notice there is a GHC 6.8 package for armel, while 6.10 exists for  
  most other architectures. Is there anything I can do to help getting  
  6.10 to armel?

 ghc 6.10 + newer toolchain bumped the size of ghc binary to over 32MB,
 thus pushing us to the need of using -mlong-calls gcc option - which, in
 turn exposed some problems in long-calls support in the toolchain..

sorry for the delay.

Now upstream has fixed the -mlong-calls problem in binutils, and I was
able to build ghc6 using the binutils from experimental.

The build packages can be found from: http://people.debian.org/~riku/ghc6/

This would leave the following problems with ghc6:

1) build failure on hppa and ia64 machines (looks very similar)
2) incorrect(?) dep-wait in mips
3) getting fixed binutils to unstable for armel..


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: GHC 6.10 for Debian armel?

[Riku Voipio]

On Thu, Apr 30, 2009 at 01:00:35PM +0200, Rickard Nilsson wrote:
 I notice there is a GHC 6.8 package for armel, while 6.10 exists for  
 most other architectures. Is there anything I can do to help getting  
 6.10 to armel?

ghc 6.10 + newer toolchain bumped the size of ghc binary to over 32MB,
thus pushing us to the need of using -mlong-calls gcc option - which, in
turn exposed some problems in long-calls support in the toolchain..

I will retry this again when we have gcc-4.4 to test with.


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: problem building gerris on armel: Illegal instruction

[Riku Voipio]

On Tue, Apr 14, 2009 at 10:13:35PM +1000, Drew Parsons wrote:
 On Mon, 2009-04-13 at 17:06 +0300, Riku Voipio wrote:
  On Sat, Apr 11, 2009 at 01:24:57AM +1000, Drew Parsons wrote:
   
   gerris is FTBFS failing to build from source on armel, 
  
  I didnt see this on my rebuild attempt (on a different machine).
  You can try to reproduce this on allegri.debian.org - Ask Debian
  admins[1] to install gerris build-dependencies into unstable
  chroot.

 allegri is restricted access, not open to general DDs.

Sorry, agricola I meant.

-- 
rm -rf only sounds scary if you don't have backups


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: problem building gerris on armel: Illegal instruction

[Riku Voipio]

On Sat, Apr 11, 2009 at 01:24:57AM +1000, Drew Parsons wrote:
 Dear armel experts,
 cc: Debian Science, Gerris upstream
 
 gerris is FTBFS failing to build from source on armel, see
 https://buildd.debian.org/build.php?pkg=gerris
 https://buildd.debian.org/fetch.cgi?pkg=gerrisver=0.9.2%
 2Bdarcs081022-dfsg.1-3arch=armelstamp=1238595409file=log

I didnt see this on my rebuild attempt (on a different machine).
You can try to reproduce this on allegri.debian.org - Ask Debian
admins[1] to install gerris build-dependencies into unstable
chroot.

[1] debian-ad...@lists.debian.org

 The symptom in the log looks like:
 make[4]: Entering directory `/build/buildd/gerris-0.9.2
 +darcs081022-dfsg.1/doc/examples'
 /bin/sh ../../libtool --silent --mode=link cc  -I../../src -I/usr/include 
 -DG_LOG_DOMAIN=\Gfs-tools\ -I/usr/include/glib-2.0 
 -I/usr/lib/glib-2.0/include -I/usr/include -DFTT_2D=1 \
   classes.c -o classes ../../src/libgfs2D.la -L/usr/lib -lgts 
 -Wl,--export-dynamic -lgmodule-2.0 -ldl -lglib-2.0 -lm 
 ./classes  gfs.lang
 /bin/sh: line 1:  8434 Illegal instruction ./classes  gfs.lang
 make[4]: *** [gfs.lang] Error 132
 make[4]: Leaving directory 
 `/build/buildd/gerris-0.9.2+darcs081022-dfsg.1/doc/examples'
 make[3]: *** [all-recursive] Error 1

 It's not clear to me why an Illegal instruction is occurring.  From
 the previous cc line, ./classes would appear to have been compiled
 successfully, so it should exist.  There's nothing obviously machine
 specific in classes.c (../../src/libgfs2D.la could be a different
 matter).

It could also originate from one of the external libraries gerris links
against.


-- 
rm -rf only sounds scary if you don't have backups


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: GCC bug when -ffast-math is set on armel

[Riku Voipio]

On Thu, Mar 19, 2009 at 09:40:47AM +, Martin Guy wrote:
   I thought I should mention this here too in case anyone else gets
 bitten by this armel-specific bug.

A GCC bug has just turned up that affects the arm-*-gnueabi
 architecture in gcc-4.[123]. While debugging libvorbisenc (which
 produces silent output files on armel), it turns out that when -O
 -ffast-math are set, GCC can produce incorrect code for the max(x,y)
 macro applied to floating point values.

Thanks for finding this out. Has a bug been filed to the GCC bugtracker?

   Thanks to Erik de Castro Lopo for some incisive debugging and for
 producing a minimal example (should print 0 0 but doesn't)
 
 /*
 **This file is in the Public Domain.
 **
 **This program demonstrates a bug in the -ffast-math option of the gcc
 **armel compiler : gcc version 4.3.2 (Debian 4.3.2-1.1)
 **
 **This works as expected:
 **
 ** gcc -Wall -O3 gcc-test.c -o gcc-test  ./gcc-test
 **min :   0.max :   0.
 **
 **Compile with -ffast-math and things goes screwy.
 **
 ** gcc -Wall -O3 -ffast-math gcc-test.c -o gcc-test  ./gcc-test
 **min :   9.max :   0.
 */
 
 #include stdio.h
 
 #define   COUNT   10
 
 #define test_max(x,y)   ((x)   (y) ? (y) : (x))
 #define test_min(x,y)   ((x)   (y) ? (y) : (x))
 
 int
 main (void)
 { /* C Standard says static data gets initialized to zero. */
   static float data [COUNT] ;
   float max = -9.0, min = 9.0 ;
   int k ;
 
   for (k = 0 ; k  COUNT ; k++)
   {   max = test_max (max, data [k]) ;
   min = test_min (min, data [k]) ;
   } ;
 
   printf (min : %12.4fmax : %12.4f\n, min, max) ;
 
   return 0 ;
 }
 
 Full details at http://bugs.debian.org/515949
 
  M
 
 
 -- 
 To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

-- 
rm -rf only sounds scary if you don't have backups


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: ARM hardware available for developers

[Riku Voipio]

On Tue, Mar 17, 2009 at 08:05:50PM +0100, Martin Michlmayr wrote:
 I have a number of ARM devices/boards that I no longer need and I'm
 looking for developers or testers who can do something useful with
 them.  Those devices have been given to me to improve Debian support,
 and so they should be used for Debian related activities
 (debian-installer tests and development, kernel work, or other things
 you can think of).

In a similar tune, I have the following gear to offer:

  - 1x Allnet ALL6500 (Thecus N2100)
  - 1x Kurobox HG (266Mhz powerpc)
  - 1x IO-Data lan tank (266Mhz superH)

All of them have a serial port available.

 Since I somehow have to get the hardware to you, I'd prefer to hear
 from people in Europe or the US but this is no absolute requirement.

 Note that none of these devices come with hard drives.

 If you're interested, please contact me privately and tell me the
 following information:

  - What you would like to do with the device - if you don't clearly
show that you'll do something useful with the device, you definitely
won't get it.  People who will actively contribute to Debian's ARM
port get bonus points.
  - What kind of experience you have.
  - Is there one device you'd prefer?
  - Where are you located?

Same instructions. If you are coming to debconf this yead, it doesn't matter
where you are located.

 If I decide to send you a device, the following rule applies: this
 device is to be used for Debian related work.  If you no longer have
 the time or interest in doing something useful with the device, it's
 your obligation to find another person who will do something useful
 (and Debian related) with it and give it to them.

The ALLNET was donated for debian work, the rest are more flexibly
available for any kind of free software work.

-- 
rm -rf only sounds scary if you don't have backups


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Architecture usertags

[Riku Voipio]

On Tue, Mar 03, 2009 at 08:52:03PM +0100, Wouter Verhelst wrote:
 so that maintainers could apply them to architecture-specific bugs when
 necessary. The format, suggested by Steve Langasek, was to use the
 porters mailinglist as the user, and the architecture name as the
 usertag (e.g., 'debian-m...@lists.debian.org' as user, and 'm68k' as
 tag).

Armel has already been using something similar:

http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-...@lists.debian.orgtag=eabi

usertags would certainly be used a much more if there were a easy
way to set/search them on BTS web interface.

-- 
rm -rf only sounds scary if you don't have backups


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Some advice on iMX31

[Riku Voipio]

On Wed, Feb 25, 2009 at 11:57:34AM +0100, Ruediger Leibrandt wrote:
 I got some advertisement-material from one of the chinese companies producing 
 the new generation of ARM based Netbooks.

 I uploaded the advertisement - a pdf - to my homepage, so, when you have a 
 spare moment or two, have a look and maybe you can tell me then if such a 
 device will be worth the money and time to try and natively install a Debian 
 Linux on it.

 http://www.tzi.de/~quitex/KINGYUNG%20G-Netbook_GL-750_spec V1_0117.pdf

Unless the vendor is providing a high-quality linux port, it's probably not
worth to invest much effor on a i.MX31 based netbook. It is effectively
current generation, and new, i.MX51 based netbooks should come out
to the market soon.

That said, if the price is low enough, and kingyung provides the kernel
sources (in a clean, mainline-friendly way), it might still be a interesting
project.


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Debian 5.0 armel installation question

[Riku Voipio]

On Wed, Feb 18, 2009 at 01:09:32PM +0100, Yegor Yefremov wrote:
 For Etch I used initrd.gz from netwinder, but as far as I understand it  
 supports only ARM and not EABI ARM. I need a cdrom installer and not  
 the netboot one. What were the best way to install Lenny on my device?

What you want is a versatile image:

http://ftp.fi.debian.org/debian/dists/lenny/main/installer-armel/current/images/versatile/netboot/

See the unnoficial howto:

http://wiki.debian.org/DebianInstaller/Arm/OtherPlatforms

My (limited) impression is that the netboot image should support any debian 
cd/dvd
image available, as long as the kernel and bootloader initrd have already been 
loaded
via other means.

-- 
rm -rf only sounds scary if you don't have backups


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Instructions for building iceweasel for arm?

[Riku Voipio]

On Sat, Jan 31, 2009 at 11:34:32PM +0800, John wrote:
You may try to compile it in scratchbox.
But Iceweasel (Debian Firefox) still segfaults under Debian Sid Arm EABI

It works for me and others... If it does segfault, we'd like to know about it.

port,See [1]http://flickr.com/photos/qole2/2291554485/

This is one year old picture, things have improved quite a bit since
that. 

On *, 2009-01-30 at 08:42 -0800, Weidong Li wrote:
 
  Hi,
 
 
 
  Does anyone have instructions for building iceweasel with a cross
  compiler for ARM target?  Where can I find a top level mozconfig file to
  start with?
 
  Regards,
 
  Weidong
 
 
 
--
**
John Lee
No.2 Xin Xiu Street. Hun Nan New District,
Shenyang 110179, PRC
Tel*(86 24) 8366 1105
Mobile*(86) 138 4024 2051
email*[2]li-qi...@neusoft.com
[3]Http://www.neusoft.com
 
  
 ---
  Confidentiality Notice: The information contained in this e-mail and any 
 accompanying attachment(s)
  is intended only for the use of the intended recipient and may be 
 confidential and/or privileged of
  Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader 
 of this communication is
  not the intended recipient, unauthorized use, forwarding, printing,  
 storing, disclosure or copying
  is strictly prohibited, and may be unlawful.If you have received this 
 communication in error,please
  immediately notify the sender by return e-mail, and delete the original 
 message and all copies from
  your system. Thank you.
  
 ---
 
 References
 
Visible links
1. http://flickr.com/photos/qole2/2291554485/
2. mailto:li-qi...@neusoft.com
3. http://www.neusoft.com/

-- 
rm -rf only sounds scary if you don't have backups


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: versatile architecture image suitable for qemu usage?

[Riku Voipio]

On Thu, Jan 08, 2009 at 11:35:22PM +0900, Junichi Uekawa wrote:
 I tried to test qemubuilder armel support and realized that I don't
 have the latest kernel.

 initrd isn't distributed inside a package, and I don't think there's a 
 kernel which doesn't work without a initrd.

 Is there a kernel which contains minimal support for ext2/3 and/or
 initrd which contains them ? (and supports parsing init= kernel
 command-line option).

I think it's better to make qemubuilder support booting with initrd.
Then you can extend support from just armel/versatile to any arch/kernel
provided by debian (and, of course, supported by qemu).


-- 
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: [PATCH] Move i2c work to a workqueque

[Riku Voipio]

On Thu, Nov 20, 2008 at 10:44:05AM +0100, Martin Michlmayr wrote:
 * Martin Michlmayr [EMAIL PROTECTED] [2008-11-20 08:02]:
  Sorry, I take this back.  While it fixes the oops when beeping, I now
  get this:

 Riku pointed out on IRC that I didn't apply his patch correctly.  I
 fixed this and now everything works fine.  I can control the LEDs
 and the bug reported by Ross is fixed.  Please apply, thanks.

 Tested-by: Martin Michlmayr [EMAIL PROTECTED]

To clarify, '[PATCH] leds-pca9532: Fix memory leak and properly handle errors'
needs to be applied first to get this patch to apply. if you choose to
omit the memory leak fix patch, you need to add by hand the rejected hunk
with a vital INIT_WORK() call.

-- 
rm -rf only sounds scary if you don't have backups


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

[PATCH] leds-pca9532: Fix memory leak and properly handle errors

[Riku Voipio]

From: Sven Wegener [EMAIL PROTECTED]

When the registration fails, we need to release the memory we allocated. Also
we need to save the error from led_classdev_register and propagate it up, else
we'll return success, even if we failed.

Signed-off-by: Riku Voipio [EMAIL PROTECTED]
---
 drivers/leds/leds-pca9532.c |   22 +-
 1 files changed, 13 insertions(+), 9 deletions(-)

I don't have the hardware. Riku, can you please test if it still works as 
expected.

diff --git a/drivers/leds/leds-pca9532.c b/drivers/leds/leds-pca9532.c
index 4064d4f..16af817 100644
--- a/drivers/leds/leds-pca9532.c
+++ b/drivers/leds/leds-pca9532.c
@@ -204,8 +204,8 @@ static int pca9532_configure(struct i2c_client *client,
led-ldev.brightness = LED_OFF;
led-ldev.brightness_set = pca9532_set_brightness;
led-ldev.blink_set = pca9532_set_blink;
-   if (led_classdev_register(client-dev,
-   led-ldev)  0){
+   err = led_classdev_register(client-dev, led-ldev);
+   if (err  0) {
dev_err(client-dev,
couldn't register LED %s\n,
led-name);
@@ -263,7 +263,6 @@ exit:
}
 
return err;
-
 }
 
 static int pca9532_probe(struct i2c_client *client,
@@ -271,12 +270,16 @@ static int pca9532_probe(struct i2c_client *client,
 {
struct pca9532_data *data = i2c_get_clientdata(client);
struct pca9532_platform_data *pca9532_pdata = client-dev.platform_data;
+   int err;
+
+   if (!pca9532_pdata)
+   return -EIO;
 
if (!i2c_check_functionality(client-adapter,
I2C_FUNC_SMBUS_BYTE_DATA))
return -EIO;
 
-   data = kzalloc(sizeof(struct pca9532_data), GFP_KERNEL);
+   data = kzalloc(sizeof(*data), GFP_KERNEL);
if (!data)
return -ENOMEM;
 
@@ -285,12 +288,13 @@ static int pca9532_probe(struct i2c_client *client,
data-client = client;
mutex_init(data-update_lock);
 
-   if (pca9532_pdata == NULL)
-   return -EIO;
-
-   pca9532_configure(client, data, pca9532_pdata);
-   return 0;
+   err = pca9532_configure(client, data, pca9532_pdata);
+   if (err) {
+   kfree(data);
+   i2c_set_clientdata(client, NULL);
+   }
 
+   return err;
 }
 
 static int pca9532_remove(struct i2c_client *client)


-- 
rm -rf only sounds scary if you don't have backups


signature.asc
Description: Digital signature

[PATCH] Move i2c work to a workqueque

[Riku Voipio]

Apparently these might be called under atomic context,
and i2c operations may sleep. BUG found by
Ross Burton [EMAIL PROTECTED]

Signed-off-by: Riku Voipio [EMAIL PROTECTED]
---
 drivers/leds/leds-pca9532.c  |   51 +++--
 include/linux/leds-pca9532.h |2 +
 2 files changed, 45 insertions(+), 8 deletions(-)

diff --git a/drivers/leds/leds-pca9532.c b/drivers/leds/leds-pca9532.c
index 62b60a0..cb8e517 100644
--- a/drivers/leds/leds-pca9532.c
+++ b/drivers/leds/leds-pca9532.c
@@ -16,6 +16,7 @@
 #include linux/leds.h
 #include linux/input.h
 #include linux/mutex.h
+#include linux/workqueue.h
 #include linux/leds-pca9532.h
 
 static const unsigned short normal_i2c[] = { /*0x60,*/ I2C_CLIENT_END};
@@ -34,6 +35,7 @@ struct pca9532_data {
struct pca9532_led leds[16];
struct mutex update_lock;
struct input_dev*idev;
+   struct work_struct work;
u8 pwm[2];
u8 psc[2];
 };
@@ -63,7 +65,7 @@ static struct i2c_driver pca9532_driver = {
  * as a compromise we average one pwm to the values requested by all
  * leds that are not ON/OFF.
  * */
-static int pca9532_setpwm(struct i2c_client *client, int pwm, int blink,
+static int pca9532_calcpwm(struct i2c_client *client, int pwm, int blink,
enum led_brightness value)
 {
int a = 0, b = 0, i = 0;
@@ -84,11 +86,17 @@ static int pca9532_setpwm(struct i2c_client *client, int 
pwm, int blink,
b = b/a;
if (b  0xFF)
return -EINVAL;
-   mutex_lock(data-update_lock);
data-pwm[pwm] = b;
+   data-psc[pwm] = blink;
+   return 0;
+}
+
+static int pca9532_setpwm(struct i2c_client *client, int pwm)
+{
+   struct pca9532_data *data = i2c_get_clientdata(client);
+   mutex_lock(data-update_lock);
i2c_smbus_write_byte_data(client, PCA9532_REG_PWM(pwm),
data-pwm[pwm]);
-   data-psc[pwm] = blink;
i2c_smbus_write_byte_data(client, PCA9532_REG_PSC(pwm),
data-psc[pwm]);
mutex_unlock(data-update_lock);
@@ -124,11 +132,11 @@ static void pca9532_set_brightness(struct led_classdev 
*led_cdev,
led-state = PCA9532_ON;
else {
led-state = PCA9532_PWM0; /* Thecus: hardcode one pwm */
-   err = pca9532_setpwm(led-client, 0, 0, value);
+   err = pca9532_calcpwm(led-client, 0, 0, value);
if (err)
return; /* XXX: led api doesn't allow error code? */
}
-   pca9532_setled(led);
+   schedule_work(led-work);
 }
 
 static int pca9532_set_blink(struct led_classdev *led_cdev,
@@ -137,6 +145,7 @@ static int pca9532_set_blink(struct led_classdev *led_cdev,
struct pca9532_led *led = ldev_to_led(led_cdev);
struct i2c_client *client = led-client;
int psc;
+   int err = 0;
 
if (*delay_on == 0  *delay_off == 0) {
/* led subsystem ask us for a blink rate */
@@ -148,7 +157,11 @@ static int pca9532_set_blink(struct led_classdev *led_cdev,
 
/* Thecus specific: only use PSC/PWM 0 */
psc = (*delay_on * 152-1)/1000;
-   return pca9532_setpwm(client, 0, psc, led_cdev-brightness);
+   err = pca9532_calcpwm(client, 0, psc, led_cdev-brightness);
+   if (err)
+   return err;
+   schedule_work(led-work);
+   return 0;
 }
 
 static int pca9532_event(struct input_dev *dev, unsigned int type,
@@ -165,13 +178,28 @@ static int pca9532_event(struct input_dev *dev, unsigned 
int type,
else
data-pwm[1] = 0;
 
-   dev_info(dev-dev, setting beep to %d \n, data-pwm[1]);
+   schedule_work(data-work);
+
+   return 0;
+}
+
+static void pca9532_input_work(struct work_struct *work)
+{
+   struct pca9532_data *data;
+   data = container_of(work, struct pca9532_data, work);
mutex_lock(data-update_lock);
i2c_smbus_write_byte_data(data-client, PCA9532_REG_PWM(1),
data-pwm[1]);
mutex_unlock(data-update_lock);
+}
 
-   return 0;
+static void pca9532_led_work(struct work_struct *work)
+{
+   struct pca9532_led *led;
+   led = container_of(work, struct pca9532_led, work);
+   if (led-state == PCA9532_PWM0)
+   pca9532_setpwm(led-client, 0);
+   pca9532_setled(led);
 }
 
 static int pca9532_configure(struct i2c_client *client,
@@ -204,6 +232,7 @@ static int pca9532_configure(struct i2c_client *client,
led-ldev.brightness = LED_OFF;
led-ldev.brightness_set = pca9532_set_brightness;
led-ldev.blink_set = pca9532_set_blink;
+   INIT_WORK(led-work, pca9532_led_work);
err = led_classdev_register(client-dev, led-ldev);
if (err  0) {
dev_err(client-dev,
@@ -233,9 +262,11 @@ static int pca9532_configure(struct i2c_client *client

Re: BUG booting 2.6.26-1-iop32x on Thecus N2100

[Riku Voipio]

On Tue, Nov 18, 2008 at 01:37:11PM +0100, Martin Michlmayr wrote:
 It happens because of Riku's LED driver.  When I compile a kernel
 without the driver, I can start ifplugd just fine.

 Riku, the best way to reproduce this is to install ifplugd (but _not_
 change INTERFACES in /etc/default/ifplugd to auto) and then you can
 trigger it with:
   /usr/sbin/ifplugd -i eth0

I see, ifplugd tries to beep. Why when ifplugd is calling it ends up
in atomic context is unclear to me, using schedule_work should make
it more safe anyway. will convert when back at device to test..

-- 
rm -rf only sounds scary if you don't have backups


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

beagleboard kernel for debian

[Riku Voipio]

On Wed, Nov 12, 2008 at 11:31:50PM +0100, Martin Michlmayr wrote:
 * Robert Nelson [EMAIL PROTECTED] [2008-11-12 10:46]:
  Which reminds me, it's too late for lenny, but what's the best way to
  get this board's kernel added to lenny+1?

The best way is to get omap3 support rolled into mainline (Linus's)
kernel. The Debian kernel is based Linus's kernel, and the kernel
maintainers are understandably reluctant to add external patches
on top of that.

I believe Current status is that basic OMAP3 and some OMAP2 support
is in mainline kernel now. The biggest bit missing ATM is the
TWL4030 driver. And then the big stream of power managment stuff
that is still WiP...

 The fundamental problem we have on arm is that we have to restrict the
 number of kernels we build because otherwise the kernel package takes
 too long to build.  So you'd have to come up with a good argument as
 to why we should add an OMAP kernel (e.g. how many users are there
 going to be; which devices use such a CPU, etc).

 However, we'd like to replace the versatile kernel (used for QEMU)
 with a kernel that runs on common hardware as well as QEMU, and OMAP
 is one possible candiate.  See
 http://lists.debian.org/debian-arm/2008/06/msg00075.html
 Looking at this message, my questions would be: are multi-omap kernels
 (omap2+omap3) possible now? 

Tony can probably answer, but the answer is probably not quite there
yet

 How good is OMAP2 and OMAP3 support in
 QEMU these days?

OMAP2 is relatively good, yet you'll probably want svn version of qemu.
setting up networking and mass storage for the N800 qemu is a bit
of a hassle compared to the versatile emulation.

-- 
rm -rf only sounds scary if you don't have backups


signature.asc
Description: Digital signature

Re: Please test debian-installer rc1 images

[Riku Voipio]

On Mon, Nov 10, 2008 at 12:12:55PM +0530, Sivakumar.R.J wrote:
We are trying to create initrd and zImage for our customized IMX31 armel
board ( in which we have tested debian chroot successfully). We need to
boot the debian from the redboot. Is it possible to boot the debian with
you provided initrd and kernel image. If not please provide me the
information to create our own initrd and kernel zImage to boot the debian
filesystem from redboot.We are using freescale LTIB provided cross
compiler tool ,zImage and rootfs.jffs2 and we are going to use the same
drivers .kindly direct me in correct path.

Installing debian using custom kernel and standard d-i initrd is
possible:

http://wiki.debian.org/DebianInstaller/Arm/OtherPlatforms

Notice that d-i does not support installing to NAND and does not support
jffs2 filesystem at the moment, so this is mostly usefull on installing
to a MMC/SD compatible card or USB connected mass storage device.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: How much mobileSDRAM do I need for OOo?

[Riku Voipio]

On Thu, Oct 23, 2008 at 05:28:46PM +0200, Michelle Konzack wrote:
 I see, OOo 2.4.1 does exist for Lenny and ARMEL and I like to know,  how
 much Memory I must have to run it since I have
 
   1)  Atmel AT91SAM9G20 (400 MHz)
   256 MByte mobileSDRAM
   2x 512 MByte NAND Flash
 
   2)  Freescale i.MX31 (532 MHz)
   512 MByte mobileSDRAM
   512 MByte (I need 3 times more of it) of NAND Flash

 On none of those two machines I can run OOo. [SEGV]

People run OOo on Nokia N800, omap2 330Mhz 128MiB of RAM
(+ swap, obciously). So it certainly should be possible on your
hardware too.

You might want to try to install openoffice.org-dbg and
use gdb to see where is exactly it's segfaulting.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Bug#503144: FTBFS on armel: gsf-scan, ** ERROR **: Compilation trouble with endianess.

[Riku Voipio]

On Thu, Oct 23, 2008 at 10:29:54AM +0300, Riku Voipio wrote:
 The error is coming from gsf-init. Reassigning accordingly.

Thanks for fixing this promptly.

 gsf thinks only vfp enabled arm uses natural endian doubles. However,
 eabi does that as well. As anyone using vfp is also using eabi,
 the correct change is to switch the define.
 
 I believe libgsf is actually broken on armel on older versions too,
 it just that someone added runtime float detection to gsf-init that
 exposes this br0kenness.

If you (and upstream) agree with my analysis, then the current
lenny/armel version is broken too? In that case, we need to
prepare a upload to testing-proposed-updates (or convince release
team that the upstream release between 1.14.8 .. 1.14.10 consist
only of carefully done bugfixes)

Is there some way to test libgsf double loading? I notice there
is a testsuite in sources, but isn't getting built/run during
build time, and I didn't find a quick way to run it..

 diff -ur old/libgsf-1.14.10/gsf/gsf-utils.c libgsf-1.14.10/gsf/gsf-utils.c
 --- old/libgsf-1.14.10/gsf/gsf-utils.c  2008-07-01 12:56:53.0 +
 +++ libgsf-1.14.10/gsf/gsf-utils.c  2008-10-23 07:03:25.0 +
 @@ -73,7 +73,7 @@
   * mixture.
   */
  #define G_ARMFLOAT_ENDIAN 56781234
 -#if defined(__arm__)  !defined(__vfp__)  (G_BYTE_ORDER == 
 G_LITTLE_ENDIAN)
 +#if defined(__arm__)  !defined(__ARM_EABI__)  (G_BYTE_ORDER == 
 G_LITTLE_ENDIAN)
  #define G_FLOAT_BYTE_ORDER G_ARMFLOAT_ENDIAN
  #else
  #define G_FLOAT_BYTE_ORDER G_BYTE_ORDER
 
 
 -- 
 rm -rf only sounds scary if you don't have backups

-- 
rm -rf only sounds scary if you don't have backups


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Java + Tomcat slow on TS 109

[Riku Voipio]

On Wed, Oct 15, 2008 at 11:55:08PM +0200, Vegar Neshaug wrote:
 The QNAP TS-109 has a Marvell 5182 500MHz processor. Specifications
 can be found here: http://www.qnap.com/pro_detail_hardware.asp?p_id=91

 I have installed lenny versions of openjdk 6 headless and mysql.
 Tomcat 6 was downloaded from the tomcat webpages and installed
 locally.

 I have a small web application which outputs image files stored as
 blobs in the mysql database.
 
 The output of the binary data is done in a loop similar to the
 following, where in is the mysql binary stream and out is the
 servlet outputstream.
 byte[] rbuf = new byte[1024];
 while ((nbytes = in.read(rbuf)) != -1) {
 out.write(rbuf, 0, nbytes);
 }
 
 
 On the TS-109 this gives me speeds around 25 KB/s with top showing
 the java process working at around 90-100 %.
 For a 2,3M image this takes around 90 seconds.
 On a 2GHz pentium 4, the same download using the same software and
 binary data output implementation uses much less, maybe around 1
 second.

 What might be the reason for this difference in performance?
 Is the java implementation on debian-arm particularly slow?
 Is it possible to get better performance?

You might want to try cacao-oj6-jre-headless, which is openjdk
using cacao JIT. plain openjdk on arm is intepreted, and thus
quite slow.

-- 
rm -rf only sounds scary if you don't have backups


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: [EMAIL PROTECTED]: Bug#497165: amiga-fdisk-cross is not being built on any architecture other than i386]

[Riku Voipio]

On Wed, Oct 08, 2008 at 08:52:31PM +0200, Christian T. Steigies wrote:
 could the buildd admins please enable building for amiga-fdisk and upload
 the resulting packages (powerpc has been built, but it seems it was never
 uploaded).

It's not upto buildd admins, it's upto packages-arch-specific[1]
maintainers (cc:'d).

Please change the atari-fdisk p-a-s entry to match what's on the
package sources:

amiga-fdisk-cross: !m68k !poweprc # 
Everything but m68k/ppc
amiga-fdisk: m68k powerpc # 
m68k/ppc specific

[1] http://cvs.debian.org/srcdep/Packages-arch-specific?cvsroot=dakrev=HEAD


signature.asc
Description: Digital signature

Re: Help with uic segfault on ARM (RC-bug)

[Riku Voipio]

On Wed, Oct 08, 2008 at 08:19:13PM +0200, Michael Hanke wrote:
 I have no clue what causes this behavior, especially as uic-qt3 works
 nicely on all other platforms. AFAIK uic simply generates the sources to
 be compiled later on, so I cannot easily see a reason for it to
 segfault, due to a bug in fslview.

the problem is in vtk, being looked at.

 that is in lenny. The most recent version in unstable seems to have an
 additional problem on ARMEL. It is also Qt-related (missing references)
 and strangly also limited to that platform.

this seems to get fixed by not using the -Wl,--as-needed LDFLAG.
can you upload a version of fslview that doesn't use -Wl,--as-needed ?

-- 
rm -rf only sounds scary if you don't have backups


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]