n for £180 right now
https://www.ebay.co.uk/itm/235791120381
They have loads of machines to choose from. There are other similar
suppliers I have used in the past - I've been buying thinkpads this
way for a couple of decades now.
New Thinkpads from lenovo are extortionate.
Wookey
--
P
th the keyboard/mouse and buy a machine with
enough welly for your purposes then yes it's a viable setup. A bit of
nerding is still required, although I expect the next debian stable
release will have pretty good out-of-the-box support for these
machines with minimal faffing.
My experien
at the whole world is not x86. I'm impressed
to see such a bug still existing in the wild.
Wookey
--
Principal hats: Debian, Wookware
http://wookware.org/
signature.asc
Description: PGP signature
0-arm64-netinst.iso
I'm not convinced that that is really 'not easy to find', but I agree
it could be fewer clicks, and we have too heavy an emphasis on x86_64
for the modern age, and arm64 images should be on the 'other
downloads' page, so thanks for bringing that to
t of tuits,
especuially 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
inaries is 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.
Woo
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 the imag
d be enough, should it not?
or am I missing something?
Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
rough 18,19,20,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
ed rebuild to see how much of a 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) so
uld be applied to tidying up stuff 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
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
er room) again 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 wonder
(efficient hardware lowers emissions, for a given workload)? 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
ildds 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
ent release.
https://asahilinux.org/blog/
Those 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, all
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
r there have not been
many things suggested, my list of tests I can run to check has zero
entries. That may be good sign (there just aren't that many), or it
might be a bad sign (no-one knows/is checking).
I have created a releasegoal page to discuss this transition in
general, and colle
ny package that currently relies on having a 32-bit
> off_t/ino_t will 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
t reading 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
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
it smarter 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
we can check that stuff
basically works before patching toolchain builds. Given that arch have
it working it should be (?) as simple 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
ps://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
ke things work on v5 so debian ends up noticing 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 t
so the 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'.
> >
t 32-bit kernels on
other 64-bit machines?
Do i386 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
#x27;t for 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
it kernels and
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
but 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
-
=armv7-a+fp
OK. 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
--
t;).
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, Wookwa
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.
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
emergency 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
o reproduce 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
--
Princip
ecting to 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
hat 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/uploa
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&#x
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
n't know if I did anything wrong or anything 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 anyw
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
--
Princip
ve to when building
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
--
ine ISA than can shift over time). So yes that makes
sense.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
ard
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
purely headless 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,
chromebook hardware to be weird 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
hopefully you'll 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 h
le. But
someone else may know better.
With grub 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
user :-)
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/libopencs
pport it if it improves performance significantly for that
software.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
due to chronic undermanning in D-I land. 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/de
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-con
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-con
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 thin
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'
&
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 wa
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 a
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 d
tell it to look.
Anyone 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
y current code leaves all this alone and just 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)
available.
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
--
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), but
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
ou can just uninstall
that.
> And nothing 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
play to include the suite name:
change (in 'preferences') 'display format' from:
%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
; bit in the package migration
rules. If upstream has given up and said 'we don't support that 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
nges over 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
hics stack is weak 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
On 2017-09-14 12:58 +0800, Paul Wise wrote:
> Wookey, could you add something about the motivation for arm64ilp32 to
> the wiki page about it?
Will do. But the short version is that it's only useful if you need to
run 32-bit code on hardware that only supports the 64-bit execution
no I don't think you should just 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
heating-control 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
--
with this properly.
> AFAICS the build failure appears if a source file uses
> "#include ".
>
> AFAIU the build tries to build a plugin with NEON instructions to be
> used depending on runtime detection.
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
proceed?
I believe that 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
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! Unfortu
d it's just data) but it's forgotten 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 se
ly 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.
Obviously something fancier
/arm-linux-gnueabihf/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
g stable. The catch is
that it may not work without some messing about (depending what has
changed).
* Ask if someone (normally the maintainer) will do/upload a backport for
stable.
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 configure.
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.
1 - 100 of 538 matches
Mail list logo
