lly until the time64 transition is over the hump.
Is yours actual ThunderX or ThunderX2? I recall the former being more or less
unobtanium.
Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
very useful
> >too to satisfy the self-dependency without more faff.
>
> Yes, that was their purpose.
And it worked beatifully. Thanks.
armhf and armel uploaded and accepted half an hour ago (armel built by Andrey
Rakhmatullin)
I'll try doing openjdk-20 next.
Wookey
--
Princip
On 2024-03-27 15:27 +, Wookey wrote:
> On 2024-03-26 22:28 +, Thorsten Glaser wrote:
>
> > I hacked that, and I tried to do armel and armhf as well but
> > dak stopped me, whereas mini-dak was not as strict.
>
> What was the actual problem with uploading th
enough, should it not?
or am I missing something?
Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
21 building each version
> with the previous one.
I presume the same, but don't actually know how old a java you can use
to bootstrap each newer java. Is it always just one version?
Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
problem
we really have, and then decide if we should revert it too until some
stuff if fixed. We should have a better idea of whether to go back or
forward farily soon. I look forward to some more details on what
actually broke (other than valgrind) soon.
Wookey
--
Principal hats: De
like this which is simply no
longer in use. If/when 'arm' is removed 'armeb' should certainly go
with it.
Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
lly doing that are pretty low, but correct code is a good thing.
Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
On 2023-09-05 08:23 +0200, Mathieu Malaterre wrote:
> On Mon, Sep 4, 2023 at 6:00 PM Wookey wrote:
> >
> > Abel is now back up.
>
> Here is what I see on my side right now:
>
> [...]
> debug1: Connecting to abel.debian.org [217.140.106.111] port 22.
> debug1: c
l.debian.org port 22: Connection timed out
> >
> > Yes. I think that's my fault.
> No rush. I'll try again sometime next week :)
Abel is now back up.
Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
until
Monday, but if you would like to use the box before that I can go take
a look this evening (it's a 10min bike ride).
Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
On 2023-05-03 21:50 +0100, Steve McIntyre wrote:
> If we're still seeing
> issues in packages today, then maybe we might find some help from
> Wookey or Emmanuel (who should both be reading this list!).
I am, and have noticed this issue and put it on our list of things to look
at. I
oad)? It's
worth paying something for more power-efficient kit, possibly quite a
lot for hardware like this that will run hard for years.
Are we running debian CI on this hardware or is that all done in the
cloud?
Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
On 2023-03-25 13:46 +0800, Paul Wise wrote:
> On Thu, 2023-03-23 at 23:33 +0000, Wookey wrote:
>
> > The arm64 servers debian uses for buildds are fine.
>
> DSA often complain on #debian-admin about how flaky they are and often
> have to reset them, there were a few jokes
r buildds are fine. We have a number
of Ampere and Applied Micro boxes.
You are probably thinking of the marvell 78000 32-bit hardware which
is getting pretty old and somewhat flaky and has mostly been retired
except for porter boxen.
Wookey
--
Principal hats: Debian, Wookware, ARM
http://woo
ose two machines are the only currently available candidates for
decent performance laptops, just as good as X86. There are also
expensive server-grade machines, and a range other devices which make
adequate computers. like the Pi4, and various rockchip, allwinner,
marvell etc devices.
Wookey
--
Prin
On 2023-02-15 17:08 +, Wookey wrote:
> On 2023-02-04 21:42 -0800, Steve Langasek wrote:
>
> Yes I think we should proceed with this analysis on debian to get a
> better handle on just how many libraries we are looking at.
OK. We have over 10,000 *-dev package in debian so this
On 2023-02-20 17:53 +0100, Diederik de Haas wrote:
> On Monday, 20 February 2023 16:24:37 CET Arnd Bergmann wrote:
> > On Wed, Feb 15, 2023, at 18:08, Wookey wrote:
> > > On 2023-02-04 21:42 -0800, Steve Langasek wrote:
> > >> On Thu, Oct 20, 2022 at 09:42:58
be a bad sign (no-one knows/is checking).
I have created a releasegoal page to discuss this transition in
general, and collect relevant info:
https://wiki.debian.org/ReleaseGoals/64bit-time
I think it would be useful do a bit more work on the ABI checking and
data-collecting (e.g. raspian in
break after being forced to update to
> the 64-bit version, even if they don't care about
> time_t.
>
> - Packages may hardcode the time_t/timeval/timespec
> definition. If they use __kernel_long_t, they would
> even work on x32, but break on any other 32-bit ABI.
>
> Arnd
>
Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
On 2022-09-29 12:24 +0200, Arnd Bergmann wrote:
> On Thu, Sep 29, 2022, at 11:49 AM, Wookey wrote:
> > On 2022-09-29 09:47 +0200, Arnd Bergmann wrote:
> >>
> >> I think the problem with using dpkg-buildflags is that it breaks
> >> any user building their own
ding properly. You wrote 'Alpine' and my
brain read 'Arch'. I have just repeated the error in my last mail.
The main ones
> I know are Alpine Linux, Adelie Linux and OpenWRT, but those all
> use musl-1.2, not glibc, and they have a much smaller set of packages.
OK. We still have plenty of
On 2022-09-29 09:47 +0200, Arnd Bergmann wrote:
> On Thu, Sep 29, 2022, at 2:14 AM, Wookey wrote:
>
> I think the problem with using dpkg-buildflags is that it breaks
> any user building their own applications against Debian provided
> libraries, unless they remember to set th
to
unconditionally set an _arch-specific_ flag.
dpkg-buildflags has functionality for this. See patch at bottom of:
https://lists.debian.org/debian-dpkg/2022/05/msg00022.html
Presumably the 'use 64-bit time_t' flag is the same for all arches,
but may only exist on 32-bit arches?
Wookey
--
Princi
ple as setting some flags and
doing a rebuild (and fixing whatever breaks).
Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
buildd.debian.org/status/package.php?p=gcc-12
https://deb.debian.org/debian/pool/main/g/gcc-12/
Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
oticing and fixing
things. We could certainly save ourselves some work by relegating it
to ports.
Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
ill the gaps in my skillset, but I guess
> >not.
>
> Argh. I used to do this, but I don't have the time or the inclination
> to step up any more. I'm very surprised to not see Wookey not list
> himself, tbh.
Yeah I should be on the list, but it looks like I wrote a reply to the
'cal
e message is correct that unaccelerated graphics is
being used. However in practie this seems to work pretty well.
Glad to hear that Debian is installale on this hardware.
Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
On 2022-07-15 13:40 -0400, gene heskett wrote:
> On 7/15/22 12:16, Wookey wrote:
> >
> > Clearly one normally does not run foreign-arch kernels on hardware so
> > we don't have to support it, and Ben is right to say 'this is not a
> > bug'.
> >
> > On t
86 kernels work on amd64 machines?
Sounds like something that might be worth discussion at debconf next week. I'll
mention it in the talk.
Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
at least another month
(on holiday away from computers).
Ah, but I see Bernhard has fixed it in the meantime.
Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
have to be built on real 32-bit hardware, but I don't know how much of
that would be fixed by this patch. Some, presumably.
So yes, cheers for this. It is helpful in the real world (or at least
it should be).
Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
On 2022-06-29 15:13 +0200, Mathieu Malaterre wrote:
> On Wed, Jun 29, 2022 at 2:48 PM Wookey wrote:
> > What exactly is going wrong when you try to use valgrind?
>
> Well you should see something like this on abel.d.o:
>
> * https://bugs.debian.org/cgi-bin/bugrep
it does have neon, so no they are not 'the same'. If you want
to see if this is the issue, try the 'harris' porterbox, which is
different v7 32-bit CPU (Freeescale i.MX53), but does have neon.
What exactly is going wrong when you try to use valgrind?
Wookey
--
Principal hats: Debian, Wookware, AR
. I just checked and in fact it doesn't do this optimisation if
built with -march=armv7-a+fp so I guess there is an implicit assumption that
everything not listed is disabled?
Do we actually know for sure or shall I try and find out from some compiler
engineers?
Wookey
--
Principal hats: Linaro,
We have embraced UEFI and if it's available the installer should use it.
It is my understanding that the current (testing) vanilla debian
installer does boot on a UEFI Pi4 (after we fixed #985956). Is that
understanding wrong?
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
ht
on innovation is just
one example illustrating that you are talking complete nonsense,
possibly just to see how many irate emails you could generate.
And yse there is no particular reason why hardware and software should be
treated differently in this area, even though manufacturers lov
On 2021-03-25 15:12 +0100, Uwe Kleine-König wrote:
>
> Update: Wookey reported a bug and mentioned via irc that imx8 is missing. I
> enabled a few settings (see https://deb.li/3fUTV) and I'm convinced that
> only ARCH_MXC is not enough.
That does look a lot more convincing. The
On 2021-03-24 21:05 +, Wookey wrote:
> On 2021-03-24 20:29 +0100, William Bonnet wrote:
> >
> > I own since a couple weeks a nitrogen iMX8 board I am currently using a
> > kernel and image provided by the manufacturer.
> >
> > I would be really happy to help
On 2021-03-24 20:29 +0100, William Bonnet wrote:
>
> I own since a couple weeks a nitrogen iMX8 board I am currently using a
> kernel and image provided by the manufacturer.
>
> I would be really happy to help on this task and join the effort. Please
> how can i help y
I discovered this week that iMX8 is not enabled in the debian
kernels. Does anyone know why not? It seems a rather major omission,
and too late to fix for bullseye now. Did just no-one ask? Or no-one
get round to it?
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org
mergency x86 box has been stuffed in until I work out what's wrong
with it/replace it.
> * Are you testing/patching d-i for the port(s)?
Yes. Added multiple console support for last release.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
e the
all the way back to gcc6, and it's been in bugzilla since 2012.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52830
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91590
Still, immediate issue worked around and hopefully the compiler will
get fixed one day.
Wookey
--
Principal hats: Linar
work out what's going on, so I am hopeful that we will
understand this reasonably soon, and can hopefully just backport a fix
into gcc-10.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
On 2020-11-14 16:33 +, Dominic Hargreaves wrote:
> On Sat, Nov 14, 2020 at 03:08:14PM +0000, Wookey wrote:
> > I have just tried it, and the file built OK, getting to a resident
> > footprint of about 3.5G before completing.
OK, reading the bug a bit more carefully, I se
On 2020-11-15 01:03 +0100, Christian Kastner wrote:
> On 11/14/20 4:08 PM, Wookey wrote:
> > Yes. I have a 64Gb machine. (emag).
>
> I wasn't aware that the Ampere stuff was generally available, and now I
> see that through a generous donation, they power our buildds [1].
could help test this theory (and maybe do a
> porter upload to unblock the issue for the perl transition?
Yes. I have a 64Gb machine. (emag).
I have just tried it, and the file built OK, getting to a resident
footprint of about 3.5G before completing.
I'll try a polymake build/upload, and rep
; Correction: The va_list problem seems to affect ARM architectures only.
This is a classic 'porting to arm' issue which used to catch people
out regularly 15 years ago because it was something where you could do
technically incorrect things that worked fine on other
architectures. It's a very long time sin
architecture not providing
> an optimized library [1].
Can you explain how this works please? I'm not familiar with this and
it seems like something worth understanding in this context.
How often is each binary checking for this file, and what exactly does
it indicate? And which binaries are checki
right at all.
>
> [1]
> https://lore.kernel.org/lkml/44156595-0eee-58da-4376-fd25b634d...@gmail.com/T/
Hmm. I have no idea if you are doing this right either, but it all
sounds plausible. I guess a reports with the s/#elif/#else fix is in
order anyway, and that might prompt a response from someone
) 204:64
What platform is this?
The idea is that the kernel should know (better than DI) what the
valid consoles are so we use that list (every 'enabled' console which
is what the 'E' indicates). But you have a machine with no tty0, but
it does have a framebuffer?
Wookey
--
Principal hats: Linaro, De
ding
cross-tools which have triplets in the name:
pkg-config-x86-64-linux-gnu
gcc-x86-64-linux-gnu
binutils-x86-64-linux-gnu
A simple substitution suffices. It does add another little bit of
tiresome complication to the already horrible complicated rules files
for gcc.
Wookey
--
Principal hats:
an can shift over time). So yes that makes
sense.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
s hard
to tell how this would go. But most have plumped for aarch64, so users
are exposed to both names.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
dless setup is fine by me.
>
> Is there some way for a somewhat experienced sysadmin to
> help in documenting this stuff, trying out things, filing bugs, etc?
Yep - get an account on the wiki and start editing.
Or file bugs if things are actually broken, but working in say,
Rasbian o
d so my success might not
> be indicative of general success.
Sure. I'll test it on eMAG and ThunderX.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
l have them on-board already).
It's capable hardware and proper server kit with UEFI and BMC etc, so we should
like it.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
requires a long answer.
Most of what you want to know should be on these pages:
https://wiki.debian.org/ArmPorts
armel: https://wiki.debian.org/ArmEabiPort
armhf: https://wiki.debian.org/ArmHardFloatPort
Come back with a more specific question if it's not covered there.
Wookey
--
Principal hats:
rub and UEFI you cn edit the grub config to set the kernel boot args.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
:-)
And you'd need a new kernel-tools too to get a working perf.
And the one testing will be in stable in a couple of months or three anyway.
Worth doing for the intervening few months? Does anyone else care?
https://github.com/Linaro/OpenCSD
https://tracker.debian.org/pkg/libopencsd
Wookey
erformance significantly for that
software.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
. I'll file
some bugs and patches. None of it is urgent, but worth noting before I
forget.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
diff --git b/debian/changelog a/debian/changelog
index a7c80c3..e23b91e 100644
--- b/debian/changelog
+++ a/debian/changelog
@@ -7,7
On 2019-02-21 00:55 +, Steve McIntyre wrote:
> Hey Wookey,
>
> Reviewing the code from your patches in sequence, I think the approach
> looks good *except* I think you've missed a patch or a commit or
> something.
>
> Trying to apply debian-installer-multiple-consoles
On 2019-02-21 00:55 +, Steve McIntyre wrote:
> Hey Wookey,
>
> Reviewing the code from your patches in sequence, I think the approach
> looks good *except* I think you've missed a patch or a commit or
> something.
>
> Trying to apply debian-installer-multiple-consoles
On 2019-02-09 04:11 +, Wookey wrote:
> Future work:
>
> All this faffage has made me realise that a better approach to all
> this would probably be to get rid of all this 'steal-ctty' bodgery,
> and use init to do it's job: it's designed to run multiple things on
> multiple
On 2019-01-19 11:08 +, Steve McIntyre wrote:
> On Sat, Jan 19, 2019 at 04:27:05AM +0000, Wookey wrote:
[Re: adding multiple console support to D-I, including changing
/var/run/console-device with one device line to be
/var/run/console-devices with 1 or more lines]
> >The only ot
On 2019-02-09 04:11 +, Wookey wrote:
> On 2019-01-25 03:45 +0000, Wookey wrote:
>
> Attached is a patch which provides working multiconsole support for
> linux (not hurd or bsd, sorry).
>
> One bug I just noticed in the bit we did today is that the 'default'
> prefer
On 2019-01-25 03:45 +, Wookey wrote:
> So, unless anyone can see a problem with this approach, I'll finish
> this off. Trying to do it with separate /var/run/consoles and
> /var/run/extra-consoles files was getting very messy.
OK. This took way longer than I hoped as it was not
On 2019-01-23 08:35 +, Ian Campbell wrote:
> On Wed, 2019-01-23 at 03:41 +0000, Wookey wrote:
> > Any idea how we should choose a D-I primary console when none of them
> > is marked 'preferred'? Or should D-i do away with the concept and try
> > to treat them all equally
On 2019-01-22 08:23 +, Ian Campbell wrote:
> On Tue, 2019-01-22 at 04:31 +0000, Wookey wrote:
> > On 2019-01-20 03:02 +, Ben Hutchings wrote:
> > > Reading /proc/consoles is exactly what you should do.
> >
> > Checking this on a booted thunderx machine (w
On 2019-01-19 11:12 +, Steve McIntyre wrote:
> [ Adding CC to debian-arm for interest ]
>
> On Sat, Jan 19, 2019 at 03:39:44AM +0000, Wookey wrote:
> >I've done some work on getting the graphical installer going on arm64.
>
> \o/
>
> >I was not able to demons
yone know what would it take to make tty0 appear as a valid console
on a thunderx machine without having to explicitly list it on the
kernel command line? This is what we'd ideally like to happen.
I've modified reopen-console-linux to use /proc/console and run D-I on all
found.
I'll test that on
records/uses all
enabled consoles on the command line, not just the last one, but
ideally we'd autodetect and/or hardcode all the sensible available
consoles and run on them.
If 'read /proc/consoles (and check the devices exist)' does this, then
that sounds very sensible.
Wookey
--
Pr
.
I think it's worth investing some effort in determining how practical
these routes are, and the above is something I think is within my
capabilities. I'm not overflowing with tuits, but I do think this is
important so I'm prepared to spend some cycles on it.
Wookey
--
Principal hats: Linaro
On 2018-11-23 23:10 -0300, Lisandro Damián Nicanor Pérez Meyer wrote:
> El viernes, 23 de noviembre de 2018 12:26:49 -03 Wookey escribió:
> >
> > My main desktop is now an arm64 machine with an nvidia PCI graphics
> > card. These are fairly new (and currently expensive),
to switch between GL and
GLES). Possibly that work never actually got done, just talked out.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
S and QNAP devices now?
I've just acquired a DNS-320, which I plan to use for some years. That
seems to be one generation newer than the 323 IIUC (kirkwood vs Orion).
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
othing related to ssh works until xfce is up and running.
The openssh dameon is independent of the desktop and will start
first. If you don't start the desktop ssh should still work.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
%c%a%M%S %p %Z %v %V
to
%c%a%M%S %p %Z %t %v %V
(IMHO this should be the default for everyone).
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
any
more' then it's quite reasonable for Debian to do the same.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
times. gcc will get this right (i.e
set the correct options for the ABI and for debian), for both
compiling and cross-compiling.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
k so I could well be
out-of-date or otherwise confused.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
st close this. In fact I still can't
see any reason not to let this build on arm64, (and ppc64el and s390x,
and ppc64 and sparc64, all of which have bowtie already built). So in
fact I think you should just remove the arch restriction.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
ontrol hardware attached. So I've not lost interest.
(It's currently still running 'arm', not 'armel', which of course is
no longer upgraded because we stopped maintaining it. It'd be nice to
have it less than 6 years out of date sometime.)
Wookey
--
Principal hats: Linaro, Debian, Wookware, AR
ailure appears if a source file uses
> "#include ".
>
> AFAIU the build tries to build a plugin with NEON instructions to be
> used depending on runtime detection.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
On 2016-12-15 15:41 +, Wookey wrote:
> On 2016-12-15 15:16 +, Alastair McKinstry wrote:
> > gfortran -c -O2 -mcmodel=large -O2 -fdefault-real-8
> > -fconvert=little-endian -frecord-marker=4 -I/usr/include par_mod.f90
> > f951: sorry, unimplemented: code mod
the compiler default was recently changed to be fPIC on
several arches, including arm64, which is presumably why you have
started seeing this. I guess we should either turn fPIC off for this
build or teach gfortran to deal with this 'large' model.
The first is presumably much easier. The sec
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! Unfortunatel
n to say so.
We are in the middle of the long process of adding this metadata to all
packages.
please file a bug about it with the trivial patch.
I thought there was a reminder to packagers about this recently added
to the pts page, but I don't see it.
Wookey
--
Principal hats: Linaro, Debian,
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.
Obviously something fancier and more centra
/libdrm_tegra.so.0
Can I use xserver-xorg-video-nouvea or is there an
xserver-xorg-video-tegra that needs building from something? Or does
tegra only work with wayland? Or...what...?
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
On 2016-10-13 15:56 +0200, Bas Couwenberg wrote:
> On 2016-10-13 15:52, Bas Couwenberg wrote:
> >On 2016-10-13 15:48, Wookey wrote:
> >>
> >>OK. Yep, just rebuilding gdal (and installing the resulting
> >>libgdal-dev, libgdal20), fixes the postgis configu
On 2016-10-12 18:57 +0100, Wookey wrote:
> On 2016-10-11 08:16 +0200, Sebastiaan Couwenberg wrote:
>
> > > Seems to me that the issue is probably actually in gdal, rather
> > > than postgis, although why the configure behaviour has changd
> > > remains a mystery.
far as I know one can't
test such a thing on the porter boxes (because there is no way to
unstall the local gdal you just built due to lack of root rights).
So I have got my local arm64 box going again and will test this theory
tomorrow (home time now).
Wookey
--
Principal hats: Linaro, Deb
but it no longer is, and so we are noticing some underlying
issue for the first time.
installing the dbgsym package for libgdal20, shows that
GDALAllRegister does exist. But for some reason the cryptoPP functions
(which postgis may not care about?) have a problem. Anything to do
with C++ symbols always m
ase CC me, I'm not on the list.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
nd it worked. You may need some --force-* to get it to play.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
sue.
If that is the problem, then the underlying issue here is a
combination of the manufacturer providing a duff DTB and the
preference of ARM kernel (people) for DTB over ACPI.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
needs to change in the
Debian kernel/installer to have this machine supported.
I don't actually know where the experts on this specific board are. I guess
there must be someone at Gigabyte who knows. But if the centos kernel
works then that's a Clue .
Wookey
--
Principal hats: Linaro, Debian, Woo
1 - 100 of 455 matches
Mail list logo
