Re: armel after Stretch (was: Summary of the ARM ports BoF at DC16)

On Wed, Dec 07, 2016 at 03:53:31PM +, Steve McIntyre wrote: > AFAIK there are potentially still similar problems with ARMv5 - lack > of architcture-defined barrier primitives for C++11 atomics to > work. (I'd love to be corrected on this if people know better!) This > is one of the key points

Re: Installing ntopng:armhf on arm64

On 2016-12-13 20:19 +, Phil Endecott wrote: > Wookey wrote: > > Yes. ntopng-data is missing a > > Multi-Arch=foreign > > line in it's control file. Add one and rebuild it and you should be in > > business. > > Thanks for your optimism Wookey! Unfortunately there's more. Yeah I did think

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

On 13/12/16 21:42, peter green wrote: I would guess at this point either a race condition or a power glitch (maybe powering the HDD off one of the USB ports wasn't such a good idea). OK, I found that adding ahci-imx.hotplug=1 to the kernel command line made it work. Checking the

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

On 13/12/16 19:59, peter green wrote: I have just bought a cubox i4x4 and installed Debian Jessie on it using D-I (concatenatable netboot). I am using a SD card for the rootfs and plan to use a hard drive to store chroots. Unfortunately while I can see the hard drive in D-I I can't see it

Re: Installing ntopng:armhf on arm64

Wookey wrote: > Yes. ntopng-data is missing a > Multi-Arch=foreign > line in it's control file. Add one and rebuild it and you should be in > business. Thanks for your optimism Wookey! Unfortunately there's more. $ apt-get source ntopng-data $ nano debian/control (add Multi-Arch: foreign for

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

I have just bought a cubox i4x4 and installed Debian Jessie on it using D-I (concatenatable netboot). I am using a SD card for the rootfs and plan to use a hard drive to store chroots. Unfortunately while I can see the hard drive in D-I I can't see it after installing. The ahci_imx module

Re: d-i on Firefly-rk3288

On Mon, 12 Dec 2016 22:26:43 + Luke Kenneth Casson Leighton wrote: > On 12/12/16, Diego Roversi wrote: > > On Mon, 12 Dec 2016 05:35:01 + > > Luke Kenneth Casson Leighton wrote: > > > >> add console=ttyS2 to the kernel parameters, also

Re: armel after Stretch

Roger Shimizu wrote: >On Thu, Dec 8, 2016 at 12:53 AM, Steve McIntyre wrote: >> >> There are kernel helpers available to provide some atomic support, but >> they'll be very slow compared to real hardware support at this level. > >Are those kernel helper already reached Debian?

Re: armel after Stretch

On Fri, Dec 09, 2016 at 06:42:19PM -1000, Julien Cristau wrote: >On 12/09/2016 05:22 PM, Wookey wrote: >> We can do poor-mans partial arch by just being fairly agressive about >> disabling armel for packages that are broken or not suitable. Not very >> clever or efficient, but it is easy to do and

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

Hi, On Tue, Dec 13, 2016 at 07:19:00PM +0900, Roger Shimizu wrote: > >> when discussing bug #800469 upstream thinks that armhf should work and > >> the question came up whether there is some chance to access an armhf > >> machine that is comparable to our autobuilders. > >> > > > > The porterbox

Re: d-i on Firefly-rk3288

On 2016-12-12 at 22:26:43 +, Luke Kenneth Casson Leighton wrote: > ok. right. so the next questions are: how flexible are you prepared > to be to get this working, and do you *absolutely* need to use > debian-installer to get this up-and-running? > [...] > the reason i ask is because the

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

On Tue, Dec 13, 2016 at 7:12 PM, peter green wrote: > On 13/12/16 07:37, Andreas Tille wrote: >> >> Hi, >> >> when discussing bug #800469 upstream thinks that armhf should work and >> the question came up whether there is some chance to access an armhf >> machine that is

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

On 13/12/16 07:37, Andreas Tille wrote: Hi, when discussing bug #800469 upstream thinks that armhf should work and the question came up whether there is some chance to access an armhf machine that is comparable to our autobuilders. The porterbox abel.debian.org runs the same hardware as the