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 here. More and more software is expecting to
> use these primitives, and a lack of them is a major problem. To
> demonstrate using gcc, you can see that lock-free atomics only started
> appearing in ARMv6 and were improved in ARMv7:
>
> $ for arch in 4 5 6 7-a; do echo ARMv${arch}; echo | g++ -march=armv${arch}
> -dM -E - | grep -i lock_free; done
> ARMv4
> #define __GCC_ATOMIC_CHAR_LOCK_FREE 1
> #define __GCC_ATOMIC_CHAR32_T_LOCK_FREE 1
> #define __GCC_ATOMIC_BOOL_LOCK_FREE 1
> #define __GCC_ATOMIC_POINTER_LOCK_FREE 1
> #define __GCC_ATOMIC_INT_LOCK_FREE 1
> #define __GCC_ATOMIC_WCHAR_T_LOCK_FREE 1
> #define __GCC_ATOMIC_LONG_LOCK_FREE 1
> #define __GCC_ATOMIC_CHAR16_T_LOCK_FREE 1
> #define __GCC_ATOMIC_LLONG_LOCK_FREE 1
> #define __GCC_ATOMIC_SHORT_LOCK_FREE 1
> ARMv5
> #define __GCC_ATOMIC_CHAR_LOCK_FREE 1
> #define __GCC_ATOMIC_CHAR32_T_LOCK_FREE 1
> #define __GCC_ATOMIC_BOOL_LOCK_FREE 1
> #define __GCC_ATOMIC_POINTER_LOCK_FREE 1
> #define __GCC_ATOMIC_INT_LOCK_FREE 1
> #define __GCC_ATOMIC_WCHAR_T_LOCK_FREE 1
> #define __GCC_ATOMIC_LONG_LOCK_FREE 1
> #define __GCC_ATOMIC_CHAR16_T_LOCK_FREE 1
> #define __GCC_ATOMIC_LLONG_LOCK_FREE 1
> #define __GCC_ATOMIC_SHORT_LOCK_FREE 1
> ARMv6
> #define __GCC_ATOMIC_CHAR_LOCK_FREE 1
> #define __GCC_ATOMIC_CHAR32_T_LOCK_FREE 2
> #define __GCC_ATOMIC_BOOL_LOCK_FREE 1
> #define __GCC_ATOMIC_POINTER_LOCK_FREE 2
> #define __GCC_ATOMIC_INT_LOCK_FREE 2
> #define __GCC_ATOMIC_WCHAR_T_LOCK_FREE 2
> #define __GCC_ATOMIC_LONG_LOCK_FREE 2
> #define __GCC_ATOMIC_CHAR16_T_LOCK_FREE 1
> #define __GCC_ATOMIC_LLONG_LOCK_FREE 1
> #define __GCC_ATOMIC_SHORT_LOCK_FREE 1
> ARMv7-a
> #define __GCC_ATOMIC_CHAR_LOCK_FREE 2
> #define __GCC_ATOMIC_CHAR32_T_LOCK_FREE 2
> #define __GCC_ATOMIC_BOOL_LOCK_FREE 2
> #define __GCC_ATOMIC_POINTER_LOCK_FREE 2
> #define __GCC_ATOMIC_INT_LOCK_FREE 2
> #define __GCC_ATOMIC_WCHAR_T_LOCK_FREE 2
> #define __GCC_ATOMIC_LONG_LOCK_FREE 2
> #define __GCC_ATOMIC_CHAR16_T_LOCK_FREE 2
> #define __GCC_ATOMIC_LLONG_LOCK_FREE 2
> #define __GCC_ATOMIC_SHORT_LOCK_FREE 2
What you're actually showing is that even for ARMv4 they are
sometimes lock free by using the kernel support.
> There are kernel helpers available to provide some atomic support, but
> they'll be very slow compared to real hardware support at this level.
I was under the impression that that's not the case:
https://lwn.net/Articles/314561/
Kurt
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 about a) actually testing this theory and b) pointing
out that it might just immediately get you to the next problem :-) but
I was busy and a quick look at deps sugested that you had a fighting
chance :-)
> $ apt-get source ntopng-data
> $ nano debian/control (add Multi-Arch: foreign for ntopng-data)
> # apt-get build-dep --host-architecture armhf ntopng-data
> ...
> The following packages have unmet dependencies:
> builddeps:ntopng:armhf : Depends: coffeescript:armhf but it is not
> installable
> Depends: libpcap-dev:armhf but it is not installable
>
> Both coffeescript and libpcap-dev are architecture=all packages which
> should maybe/possibly/probably have Multi-Arch=foreign.
Right, and if one has access to an armhf machine, such a debian
porterbox, one can just build the modified ntopng package nativaly and
avoid the typical 'computing story of woe' below.
> But I suspect these are actually only needed to build the ntopng package
> (i.e. the binaries), not ntopng-data. I install some other build-deps
> and try:
>
> $ dpkg-buildpackage --build=all --jobs=3 --no-check-builddeps
>
> Confusingly, "build=all" here doesn't mean build everything! It is
> supposed to mean build the architecture=all packages. This doesn't
> work as I hope though; it starts by doing some ./configures which are
> clearly checking for architecture-specific things - including the missing
> arm64 luajit. It ends up with make recursively disappearing up its
> own backside.
Right, because that's building for arm64
> So it looks like I will have to patch coffeescript and libpcap-dev, and
> then build ntopng-data for armhf.
>
> $ apt-get source coffeescript
> $ nano debian/control (add Multi-Arch: foreign in 3 places)
> # apt-get build-dep coffeescript
> $ dpkg-buildpackage --jobs=3
> # dpkg -i coffeescript_1.10.0~dfsg-1_all.deb
>
> OK
>
> $ dpkg -L libpcap-dev
> /.
> /usr
> /usr/share
> /usr/share/doc
> /usr/share/doc/libpcap-dev
> /usr/share/doc/libpcap-dev/changelog.Debian.gz
> /usr/share/doc/libpcap-dev/changelog.gz
> /usr/share/doc/libpcap-dev/copyright
>
> That should clearly be Multi-Arch=foreign - right? - so:
No because libpcap-dev depends on libpcap0.8-dev which is
arch-specific so when something depends on libpcap-dev it wants to get
the right architecture version of libpcap0.8-dev, so they should both
be MA:same and arch:any, as explained in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820829
>
> dpkg: error processing archive
> /tmp/apt-dpkg-install-B3DAh9/45-libcurl4-gnutls-dev_7.50.1-1_armhf.deb
> (--unpack):
> trying to overwrite shared '/usr/bin/curl-config', which is different from
> other instances of package libcurl4-gnutls-dev:armhf
>
> Comparing libcurl4-gnutls-dev_7.50.1-1_armhf.deb and
> libcurl4-gnutls-dev_7.50.1-1_arm64.deb,
> they both have /usr/bin/curl-config and those files do differ; they include
> architecture-specific paths:
>
> < if test "X${prefix}/lib/arm-linux-gnueabihf" != "X/usr/lib" -a
> "X${prefix}/lib/arm-linux-gnueabihf" != "X/usr/lib64"; then
> ---
> > if test "X${prefix}/lib/aarch64-linux-gnu" != "X/usr/lib" -a
> > "X${prefix}/lib/aarch64-linux-gnu" != "X/usr/lib64"; then
> >CURLLIBDIR="-L${prefix}/lib/aarch64-linux-gnu "
>
> How is multiarch supposed to cope with that?
Yes - those foo-config programs are a major pain for multiarch and
cross-building.
You have hit https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731998
> OK! Try to build ntopng-data again, something like:
>
> $ dpkg-buildpackage --host-arch=armhf --target-arch=armhf --build=all --jobs=3
>
> I'm not at all sure about those architecture options. I'd be happy to
> either build using a "native" armhf compiler, or a "cross" arm64-hosted,
> armhf-target compiler. It seems most promising with just --host-arch-armhf,
> which seems to be cross-compiling; it gets this far:
>
> checking for arm-linux-gnueabihf-gcc... no
>
> Presumably this is because the build-deps assume build-essential, which
> doesn't include the cross-compiler. (Is there a "cross build essential"
> package?)
yes. install crossbuild-essential-armhf (which will get you suitable
binutils, gcc, pkgconfig and cross-config toolchain components)
> # apt-get install gcc-arm-linux-gnueabihf
> $ dpkg-buildpackage --host-arch=armhf --build=all --jobs=3
>
> checking for pcap_open_live in -lpcap... no
> Please install libpcap(-dev) (http://tcpdump.org)
>
> Of course I do now have libpcap-dev, which is architecture-all and
> has no content. The actual libpcap seems to be in the v
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 schematic I notice that the USB ports seem to have power control, I wonder if they are power-cycled at some point during the boot process.
Re: cubox i4x4 hard drive seen in D-I but not in installed system.
On 13/12/16 19:59, peter green wrote: I have just bought a cubox i4x4 and installed Debian Jessie on it using D-I (concatenatable netboot). I am using a SD card for the rootfs and plan to use a hard drive to store chroots. Unfortunately while I can see the hard drive in D-I I can't see it after installing. The ahci_imx module seems to be loaded but sda doesn't appear in /dev. I upgraded to the kernel from backports. This made no difference. Any idea how to go about troubleshooting this issue? the box isn't much use to me if I can't make the hard drive work. Ok, after some discussions on irc I discovered some more. It seems that the system sees the port but fails to detect the drive. [2.694758] ahci-imx 220.sata: fsl,transmit-level-mV value 1104, using 0044 [2.694778] ahci-imx 220.sata: fsl,transmit-boost-mdB value 0, using [2.694791] ahci-imx 220.sata: fsl,transmit-atten-16ths value 9, using 2000 [2.694802] ahci-imx 220.sata: fsl,receive-eq-mdB not specified, using 0500 [2.698172] ahci-imx 220.sata: SSS flag set, parallel bus scan disabled [2.698208] ahci-imx 220.sata: AHCI 0001.0300 32 slots 1 ports 3 Gbps 0x1 impl platform mode [2.698223] ahci-imx 220.sata: flags: ncq sntf stag pm led clo only pmp pio slum part ccc apst [2.699973] scsi host0: ahci-imx [3.014679] ahci-imx 220.sata: no device found, disabling link. [3.014690] ahci-imx 220.sata: pass .hotplug=1 to enable hotplug However if I unload and reload the driver then it sees the drive successfully. I would guess at this point either a race condition or a power glitch (maybe powering the HDD off one of the USB ports wasn't such a good idea).
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 ntopng-data)
# apt-get build-dep --host-architecture armhf ntopng-data
...
The following packages have unmet dependencies:
builddeps:ntopng:armhf : Depends: coffeescript:armhf but it is not installable
Depends: libpcap-dev:armhf but it is not installable
Both coffeescript and libpcap-dev are architecture=all packages which
should maybe/possibly/probably have Multi-Arch=foreign.
But I suspect these are actually only needed to build the ntopng package
(i.e. the binaries), not ntopng-data. I install some other build-deps
and try:
$ dpkg-buildpackage --build=all --jobs=3 --no-check-builddeps
Confusingly, "build=all" here doesn't mean build everything! It is
supposed to mean build the architecture=all packages. This doesn't
work as I hope though; it starts by doing some ./configures which are
clearly checking for architecture-specific things - including the missing
arm64 luajit. It ends up with make recursively disappearing up its
own backside.
So it looks like I will have to patch coffeescript and libpcap-dev, and
then build ntopng-data for armhf.
$ apt-get source coffeescript
$ nano debian/control (add Multi-Arch: foreign in 3 places)
# apt-get build-dep coffeescript
$ dpkg-buildpackage --jobs=3
# dpkg -i coffeescript_1.10.0~dfsg-1_all.deb
OK
$ dpkg -L libpcap-dev
/.
/usr
/usr/share
/usr/share/doc
/usr/share/doc/libpcap-dev
/usr/share/doc/libpcap-dev/changelog.Debian.gz
/usr/share/doc/libpcap-dev/changelog.gz
/usr/share/doc/libpcap-dev/copyright
That should clearly be Multi-Arch=foreign - right? - so:
$ apt-get source libpcap-dev
# apt-get build-deps libpcap-dev
$ nano debian/control (Add Multi-Arch: foreign to libpcap-dev)
$ dpkg-buildpackage --jobs=3
# dpkg -i libpcap-dev_1.8.1-3_all.deb
Now try to install the ntopng-data armhf build-deps again:
# apt-get build-dep --host-architecture armhf ntopng-data
Reading package lists... Done
Picking 'ntopng' as source package instead of 'ntopng-data'
Building dependency tree
Reading state information... Done
The following package was automatically installed and is no longer required:
libmysqlclient18
Use 'apt autoremove' to remove it.
The following packages will be REMOVED:
libgeoip-dev libmysqlclient-dev libndpi-dev libndpi3
The following NEW packages will be installed:
libblkid1:armhf libc6-dev:armhf libcairo2:armhf libcurl3-gnutls:armhf
libcurl4-gnutls-dev:armhf libdatrie1:armhf
libdb5.3:armhf libdbi1:armhf libexpat1:armhf libffi6:armhf
libfontconfig1:armhf libfreetype6:armhf
libgcrypt20:armhf libgeoip-dev:armhf libgeoip1:armhf libglib2.0-0:armhf
libgmp10:armhf libgnutls30:armhf
libgpg-error0:armhf libgraphite2-3:armhf libgssapi-krb5-2:armhf
libharfbuzz0b:armhf libhiredis-dev:armhf
libhiredis0.13:armhf libhogweed4:armhf libicu57:armhf libidn11:armhf
libjson-c-dev:armhf libjson-c3:armhf
libk5crypto3:armhf libkeyutils1:armhf libkrb5-3:armhf libkrb5support0:armhf
libldap-2.4-2:armhf libmount1:armhf
libmysqlclient-dev:armhf libmysqlclient18:armhf libndpi-dev:armhf
libndpi3:armhf libnettle6:armhf
libnghttp2-14:armhf libp11-kit0:armhf libpango-1.0-0:armhf
libpangocairo-1.0-0:armhf libpangoft2-1.0-0:armhf
libpixman-1-0:armhf libpng16-16:armhf librrd-dev:armhf librrd8:armhf
librtmp1:armhf libsasl2-2:armhf
libsasl2-modules-db:armhf libsodium18:armhf libsqlite3-0:armhf
libsqlite3-dev:armhf libssh2-1:armhf
libstdc++6:armhf libtasn1-6:armhf libthai0:armhf libx11-6:armhf libxau6:armhf
libxcb-render0:armhf
libxcb-shm0:armhf libxcb1:armhf libxdmcp6:armhf libxext6:armhf libxml2:armhf
libxrender1:armhf libzmq3-dev:armhf
libzmq5:armhf linux-libc-dev:armhf zlib1g-dev:armhf
dpkg: error processing archive
/tmp/apt-dpkg-install-B3DAh9/45-libcurl4-gnutls-dev_7.50.1-1_armhf.deb
(--unpack):
trying to overwrite shared '/usr/bin/curl-config', which is different from
other instances of package libcurl4-gnutls-dev:armhf
Comparing libcurl4-gnutls-dev_7.50.1-1_armhf.deb and
libcurl4-gnutls-dev_7.50.1-1_arm64.deb,
they both have /usr/bin/curl-config and those files do differ; they include
architecture-specific paths:
< if test "X${prefix}/lib/arm-linux-gnueabihf" != "X/usr/lib" -a
"X${prefix}/lib/arm-linux-gnueabihf" != "X/usr/lib64"; then
if test "X${prefix}/lib/aarch64-linux-gnu" != "X/usr/lib" -a
> "X${prefix}/lib/aarch64-linux-gnu" != "X/usr/lib64"; then
>CURLLIBDIR="-L${prefix}/lib/aarch64-linux-gnu "
How is multiarch supposed to cope with that?
But I don't need the arm64 version, so I can:
# apt-get remove libcurl4-gnutls-dev:arm64
# apt-get build-dep --host-architecture ar
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 seems to be loaded but sda doesn't appear in /dev. I upgraded to the kernel from backports. This made no difference. Any idea how to go about troubleshooting this issue? the box isn't much use to me if I can't make the hard drive work. When trying to debug I wondered if the wrong dtb was being used. Unfortunately I can't seem to figure out what puts the dtb in /boot and how it selects which dtb to use.
Re: 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 earlyprintk is really > >> helpful (but you have to have the right options compiled in the kernel > >> to use it). > >> > > > > Ok, I retried with this, and now the serial console works (thanks): > > great! ok so now you have a feedback loop to monitor issues until success. > > > Except the ethernet doesn't works. There are errors in dmesg: > > 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? i,e, do you have some > hard requirement that *forces* you to use debian-installer or did you > choose it because you'd heard it was the "normal" way to install > debian? > It's not a hard requirement, but I thing it would be nice to have a working debian-installer, so it will be more easy to install linux on the firefly. And having a debian kernel means I don't have to upgrade manually the kernel, but I just do a "apt upgrade". > instead, i've resorted - reluctantly - to using either debootstrap or > qemu-arm to carry out the root filesystem preparation... then copied > that over. I used debootstrap too, the first time with allwinner boards. > > you could look for a debian-testing "weekly build" version of > debian-installer (which should have a more recent kernel) > It was just the latest I've found. > > you could ask around to see if someone else has a working (older or > newer) debian-installer from debian/testing or sid that is known to > work and they can provide a copy online for you. I hoped to found someone on the mailing list, but no luck... Anyway, I think that il follow to path in parallel. I will open a bug, and try a custom kernel. Thanks, Diego. -- Diego Roversi
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? >Or there's still some work here? As Ben said - they're in the kernel already. But various packages *may* still need port work to use them. >> It's a similar thing, but further up the curve - that's all. We added >> armhf (as the equivalent of i686, maybe) a while back, targeting >> ARMv7. The much older CPU designs based on ARMv4 and ARMv5 are getting >> harder to support than the i586 here. The world has moved on, >> basically. > >Just like the world already moves on to amd64, but Debian still >support i386 and i686, Not so much - we don't support *actual* i386 machines any more, nor i486 nor most i586. >I think the community need armel and armhf, for quite a long time if >it's feasible. > >> You're the first armel developer to offer to dive in here, so that's a >> good start! > >Thanks, but my knowledge don't cover the lower part such as building >toolchains, >still need someone with more experience. OK. >> * *If* we wanted to try the partial architecture thing, that will >>need some effort to make it work. That's not well-defined right >>now, as it's only a vague concept at best (sorry!) > >Maybe we can avoid to do partial arch? As it's still very much a vague concept that'd be easier, yes. :-) >> * There are going to be some packages that just won't work, >>particularly JIT compilers and other code generators that assume >>ARM == ARMv7. Fixing those up might raneg between feasible and >>~impossible depending on the size of the codebase... > >If something breaks, I guess it breaks now already. >We need to fix before Stretch. >If the issue is fixed, I think there's no need to remove armel >immediately after releasing Stretch. That will be up to the release team, basically. I'm not going to be actively pushing for the removal of armel personally, but as we've seen recently (with the removal of powerpc for stretch) what matters is having multiple active porters working on fixing things steadily throughout the release cycle. So long as we (you!) can demonstrate that, armel can survive. It's not wonderful for users that things go EOL over time, but it happens. We're also giving people plenty of warning that this might be coming, so interested people can step up and provide that support to keep things going. -- Steve McIntyre, Cambridge, UK.st...@einval.com < sladen> I actually stayed in a hotel and arrived to find a post-it note stuck to the mini-bar saying "Paul: This fridge and fittings are the correct way around and do not need altering"
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 requires no infra or >> tooling changes at all. So long as someone is volunteering for that >> (easy but unexciting) work that could work. >> >We wouldn't necessarily want to call the result a Debian release, though. Nod. Also (AIUI) fairly likely to break release work for testing migration etc. unless people are very careful... -- Steve McIntyre, Cambridge, UK.st...@einval.com < Aardvark> I dislike C++ to start with. C++11 just seems to be handing rope-creating factories for users to hang multiple instances of themselves.
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 abel.debian.org runs the same hardware as the buildds and has > > both armel and armhf chroots available. > > > > There is a procedure for guest accounts on porterboxes, though I haven't > > used it myself so I don't know how well it works in practice. > > The process has simplified, and just visit: https://nm.debian.org/wizard/ > and click "Request guest account". > > Just curious that this issue cannot be reproduced by pbuilder or > similar on self arm boxes? In the discussion of the according pull request[1] that was suggested in Debian bug #800469 quite at the end the following reason is given: plugwash commented 2 hours ago When it comes to alignment issues qemu favours performance over correctness. So code with alignment issues that will fail on real hardware will often work in qemu. Upstream possibly has no access to an arm box and I'm personally lacking the knowledge to track down the issue. If you want to fix #800469 - that's perfectly welcome ... Kind regards Andreas. [1] https://github.com/samtools/htslib/pull/99 -- http://fam-tille.de
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 last time i actually used > debian-installer on arm hardware was way back in 2010, Actually, I was used to use debootstrap to put debian with a custom kernel on various boards, but in the last couple of years I've moved to trying to use the installer as much as possible, the main reason for it being that it's the easiest way to make sure that the board is actually supported by a sane kernel and will continue to work in the future. Of course, the reason why I started doing it is that there are a number of boards where it *does* work out of the box (mostly the ones listed on InstallingDebianOn/Allwinner on the wiki), and this IMHO makes it worth the effort to investigate and document what it takes do to the same on boards where it doesn't work out of the box, but it can be made to work (including possibly opening bugs / proposing fixes to the testing installer, of course). I don't think this approach works when you are developing a new board and need it to work *right now*, of course, but I do believe that it may be worth as an aim for when the board is done and available to the public. -- Elena ``of Valhalla''
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 comparable to our autobuilders. >> > > The porterbox abel.debian.org runs the same hardware as the buildds and has > both armel and armhf chroots available. > > There is a procedure for guest accounts on porterboxes, though I haven't > used it myself so I don't know how well it works in practice. The process has simplified, and just visit: https://nm.debian.org/wizard/ and click "Request guest account". Just curious that this issue cannot be reproduced by pbuilder or similar on self arm boxes? Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
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 buildds and has both armel and armhf chroots available. There is a procedure for guest accounts on porterboxes, though I haven't used it myself so I don't know how well it works in practice.
