[Arm-netbook] What do 1,000 EOMA68-A20 PCBs look like?

[Paul Boddie]

Hello,

Nice to see the progress being made in the recent update:

https://www.crowdsupply.com/eoma68/micro-desktop/updates/what-do-1-000-eoma68-a20-pcbs-look-like

It's a shame that you have to redo your Parabola bootstrapping. I experimented
with bootstrapping Parabola on MIPS a few months ago using two different
approaches - (1) try and cross-compile packages, (2) try and native build in
another environment - and it was rather frustrating either way. Ultimately, I
didn't regard it as a great way to spend my time.

Paul

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phcom

[Luke Kenneth Casson Leighton]

Post by Paul Boddie
Hello,
https://www.crowdsupply.com/eoma68/micro-desktop/updates/what-do-1-000-eoma68-a20-pcbs-look-like
It's a shame that you have to redo your Parabola bootstrapping. I experimented
with bootstrapping Parabola on MIPS a few months ago using two different
approaches - (1) try and cross-compile packages, (2) try and native build in
another environment - and it was rather frustrating either way. Ultimately, I
didn't regard it as a great way to spend my time.

:)

it was quite hilarious to get up and running.
https://wiki.parabola.nu/MIPS_Installation - oh. discontinued.
that's not going to help *sigh*.

basically it's a hell of a lot easier if you have a native x86
parabola install, as you can then use the equivalent of debian foriegn
arch debootstrap, and the --second-stage you run a qemu emulator to
finish off the install.

that's basically exactly what i did... except because i didn't have
native x86 parabola i ran in qemu.

it worked really well and makes for a hilarious story.

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phcomp.co

[Paul Boddie]

Post by Luke Kenneth Casson Leighton
it was quite hilarious to get up and running.
https://wiki.parabola.nu/MIPS_Installation - oh. discontinued.
that's not going to help *sigh*.

Yes, it seems that people got enthusiastic when Stallman started using that
Lemote laptop, but when he stopped using it, they all dropped MIPS as soon as
they could. So, gNewSense and Parabola both supported the MIPS architecture on
some level, and Guix still does, I think, although since the Lemote stuff
supported mips64el, any remaining support in these distributions is not useful
for 32-bit devices, amongst which is the Ingenic SoC that you were looking at.

Of course, Debian supports everything of interest, but then there has to be a
process of weeding out non-free packages and content. Since your EOMA68
campaign, PureOS has become a candidate for a suitable Debian-based FSF-
endorsed distribution (ignoring systemd concerns). If Trisquel hadn't switched
to Ubuntu as its base, it would also have been a candidate, but instead it
suffers from Ubuntu's arbitrary architecture selection policy.

Post by Luke Kenneth Casson Leighton
basically it's a hell of a lot easier if you have a native x86
parabola install, as you can then use the equivalent of debian foriegn
arch debootstrap, and the --second-stage you run a qemu emulator to
finish off the install.
that's basically exactly what i did... except because i didn't have
native x86 parabola i ran in qemu.
it worked really well and makes for a hilarious story.

I guess you are able to rely on the existing ARM port of Arch, though. What I
found was that for building packages from scratch you have to combine Parabola
and Arch repositories, and the mechanisms for doing this are not very
coherent.

I ended up having to write tools to look up packages in different packaging
repositories, first trying one place, then another, and so on. Some of these
tools I ran in an appropriate x86 Parabola installation because they won't
work in a "portable" way in other environments.

What I learned is that there is a considerable difference between genuine
multi-architecture distributions and the kind of architecture-and-a-half
distribution that Arch seems to be, with Parabola being under that umbrella. I
think Arch has already thrown i386 over the side, so I wonder whether Parabola
will also have to do so in time as well.

Generally, I think that the Arch maintainers make some pretty questionable
decisions: switching the default version of Python to version 3 very early on
in the 3.x lifespan being one notable example. But having the choice is good
for people who can get along with such decisions, I guess.

Paul

P.S. It is also pretty frustrating that people seem to need Richard Stallman
to tell them what to do. When I asked people supposedly interested in porting
the Hurd to L4-based systems about such matters, one of the responses
indicated that Stallman didn't think that working on operating system
fundamentals was worthwhile compared to doing other things.

But if something is worth doing, even if not everyone agrees, why does anyone
need some kind of "sign off" from someone they've heard of? Just do what you
think is right or interesting or enjoyable or useful, already! I honestly
don't know why anyone would follow a mailing list on a topic if they didn't
already know it was worthwhile.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send lar

[Luke Kenneth Casson Leighton]

Post by Paul Boddie
But if something is worth doing, even if not everyone agrees, why does anyone
need some kind of "sign off" from someone they've heard of? Just do what you
think is right or interesting or enjoyable or useful, already! I honestly
don't know why anyone would follow a mailing list on a topic if they didn't
already know it was worthwhile.

interesting insights that you raise, paul (all of them), this one
caught my attention in particular. occasionally i encounter people
who follow some logical conclusion that i, personally, have reached...
*without* themselves having reviewed the facts / data and associated
logic. this completely freaks me out.

the second part is: i think that people know / feel that without
"sign-off", the person (e.g. dr stallman) acting as a diplomatic
gateway / channel to other resources and other people will not put
them in touch with other people / resources if that person doesn't
believe the proposal is workable.

given that large projects succeed based on collaboration, the
high-profile person, who will have a lot more experience than them,
becomes not just a "reviewer" of the proposal, but a channel and
potential advocate as well.

put another way: if someone's not strongly convinced of the value of
their idea, they're not going to stand up and make it happen when
faced with someone who says "no", are they? :)

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.ph

[Elena ``of Valhalla'']

Post by Paul Boddie
Of course, Debian supports everything of interest, but then there has to be a
process of weeding out non-free packages and content.

Note that this "process" simply involves not adding the 'non-free'
repository to /etc/apt/sources.list. It's not silently added by default,
the user/admin needs to make an explicit choice to add it.

[Paul Boddie]

Post by Elena ``of Valhalla''

Post by Paul Boddie
Of course, Debian supports everything of interest, but then there has to
be a process of weeding out non-free packages and content.

Note that this "process" simply involves not adding the 'non-free'
repository to /etc/apt/sources.list. It's not silently added by default,
the user/admin needs to make an explicit choice to add it.

Sorry, I meant in the context of being free enough for FSF endorsement.
Otherwise, there would be no need for distributions like PureOS, gNewSense,
and so on.

Discussion can be had about the FSF criteria, of course, but since Luke is
actually seeking such endorsement, the only thing that might be helpful for
him is to indicate to him that various FSF concerns are now addressed in the
more mainstream distributions, such as there not being random firmware
binaries in kernel packages, and so on. Since I don't track what Debian's
policy on such things is, bringing any new developments to his attention could
be useful and save him a lot of time and effort.

I tend to be wary about making any statements about Debian policy these days
since it tends to get me flamed by random people.

Paul

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phco

[Luke Kenneth Casson Leighton]

Post by Paul Boddie
Discussion can be had about the FSF criteria, of course, but since Luke is
actually seeking such endorsement, the only thing that might be helpful for
him is to indicate to him that various FSF concerns are now addressed in the
more mainstream distributions, such as there not being random firmware
binaries in kernel packages, and so on.

the RYF Criteria are extremely specific: it's not enough to have a non-free
section that's "disabled", it must be *not possible* for an average end-user
to *accidentally* end up installing non-free software by complete accident
such as "running a GUI and arbitrarily clicking random buttons".

the absolute worst-case is where an inexperienced end-user, running
e.g. synaptics, goes "i have no idea what this does, i'm just gonna click it"
and it happens to enable the "non-free" section, happens to silently and
happily perform an apt-get update, and wow, suddenly there's binary
firmware available... all WITHOUT warning the user of the consequences.

the "convenience" scripts that download mstruetypefonts.

the "convenience" script that gets the latest adobe flash player.

the broadcom wifi firmware extractor scripts

my feeling is, here, that if aptitude, apt, synaptics and other apt front-ends
added a simple warning dialog "hello you are adding the non-free section,
this can have severe consequences as the source is not available for
review", that would quite likely eliminate one of the FSF's major concerns.

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@file

[Julie Marchant]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Post by Luke Kenneth Casson Leighton

Post by Paul Boddie
Discussion can be had about the FSF criteria, of course, but
since Luke is actually seeking such endorsement, the only thing
that might be helpful for him is to indicate to him that various
FSF concerns are now addressed in the more mainstream
distributions, such as there not being random firmware binaries
in kernel packages, and so on.

the RYF Criteria are extremely specific: it's not enough to have a
non-free section that's "disabled", it must be *not possible* for
an average end-user to *accidentally* end up installing non-free
software by complete accident such as "running a GUI and
arbitrarily clicking random buttons".
the absolute worst-case is where an inexperienced end-user,
running e.g. synaptics, goes "i have no idea what this does, i'm
just gonna click it" and it happens to enable the "non-free"
section, happens to silently and happily perform an apt-get update,
and wow, suddenly there's binary firmware available... all WITHOUT
warning the user of the consequences.
the "convenience" scripts that download mstruetypefonts.
the "convenience" script that gets the latest adobe flash player.
the broadcom wifi firmware extractor scripts
my feeling is, here, that if aptitude, apt, synaptics and other apt
front-ends added a simple warning dialog "hello you are adding the
non-free section, this can have severe consequences as the source
is not available for review", that would quite likely eliminate one
of the FSF's major concerns.

Just a note, the only way to add the non-free section in Debian
involves typing the word "non-free" into a particular spot on a text
file, or if using the GUI interface, to edit the entry for the Debian
repo to type "non-free" into the "Components" textbox in the "Edit
Source" dialog box. So it's not really possible to accidentally enable
the non-free repository. I honestly tend to disagree with the FSF's
classification of Debian for this reason.

That being said, it's the FSF's rules, so Parabola is the only real
option regardless of what one might think of the FSF's classification.
And as for 32-bit MIPS... just outta luck, I guess, at least until an
FSF-approved distro starts supporting it.

- --
Julie Marchant
http://onpon4.github.io

Encrypt your emails with GnuPG:
https://emailselfdefense.fsf.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJcCd0yAAoJEObQhGZrE45FGdEQAJEz6C4zJVQxpw/6Vukf/4mX
hudsDdjEeublmAyzDhXbbWa5esalcsU1N78jK3Jcf+7J9wXsn1f41XQY39mAQFCq
9h+uWxm3kKON6c3Of/MQvKUSwB9T68Kno8QGbshlPMfRJvlxACu9vNxs83x2wm1U
Z+JJ0UFpOKMg0qLZJkMzw+6ewT8sNqShuiv3dltBfweAILACcqJXbIP95wgCpXWX
E0sDa+2LJqVzu/YKtLEPK3agDrJzb/Kwlc4MMo0+7xZSp8FHUqE0Qkg4KCjg/Vv1
B2lkdDvj/uVQKZEWcSQ2JXoUvBpho5CnOeqFJQpoIEuL/TFX1WNlN1XE0iNJMubC
keydF+8tDnc7rUhXwtuDLBQRlkrxLOZx8pqd1onY/vcuz6pjYmOtT4GfyQzOhIVd
m8ArLzLwgfu2ycyMHoNo97MyOUCzIbX/Ru1BESeG0ey5hY0VBxqMpUgJ7ZK9yVFW
gioJe446M6hZD7Owxz3CDQHNEUOFC39sbosPfjixk1muvGF2aICllHShggmBeZUa
m0TLJHK6ucPIfon7MfL3KUijJlKZqaV/0meVtMqhfnsR4PSkiqSm3ceBN5EdZ20T
HGlHamFLLsR+34cY3a7qcEaG6CFz8zIDON7aPO9SCPq0h9gQHCMWDc+X7acpI2EC
IhcEnoihFruV9z8l58eF
=tAm/
-----END PGP SIGNATURE-----

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachment

[Luke Kenneth Casson Leighton]

Post by Julie Marchant
And as for 32-bit MIPS... just outta luck, I guess, at least until an
FSF-approved distro starts supporting it.

all 32-bit OSes are on the ropes, but not for the reason that most
people think. it's down to the linker phase of binutils *running out
of memory*, due to a default option to keep the object files and the
binary being linked in memory:

https://marc.info/?l=binutils-bugs&m=153030202426968&w=2
https://sourceware.org/bugzilla/show_bug.cgi?id=22831

unfortunately this is quotes not anyone's responsibility quotes, it's
one of those little-known syndrome / underlying / indirect causes.

please please for goodness sake could people spread awareness about
this more widely, try out some very large builds including
comprehensive debug build options, adding the option advised in that
bugreport, and report back on the bugreport if it was successful or
not.

*without* that option, the fact that firefox now needs SEVEN
GIGABYTES of resident RAM in order to complete the linker phase (which
is obviously impossible on a 32-bit processor), armhf, mips32, and
many other 32-bit architectures are just going to get... dropped by
distros...

*for no good reason*.

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send l

[Paul Boddie]

Post by Luke Kenneth Casson Leighton

Post by Julie Marchant
And as for 32-bit MIPS... just outta luck, I guess, at least until an
FSF-approved distro starts supporting it.

From what people have said about Debian, I can envisage getting PureOS to work
on mipsel. It is just that I haven't dedicated any time to really looking into
it yet.

Post by Luke Kenneth Casson Leighton
all 32-bit OSes are on the ropes, but not for the reason that most
people think. it's down to the linker phase of binutils *running out
of memory*, due to a default option to keep the object files and the
https://marc.info/?l=binutils-bugs&m=153030202426968&w=2
https://sourceware.org/bugzilla/show_bug.cgi?id=22831
unfortunately this is quotes not anyone's responsibility quotes, it's
one of those little-known syndrome / underlying / indirect causes.

It is a consequence of people not really valuing the longevity of hardware. A
decade or so ago, people still cared about whether GNU/Linux worked on old
hardware: it was even a selling point. Now people are probably prioritising
the corporate space where you can just request a new laptop with double the
memory from your manager and pretend that it was a cheap way of solving the
problem.

Post by Luke Kenneth Casson Leighton
please please for goodness sake could people spread awareness about
this more widely, try out some very large builds including
comprehensive debug build options, adding the option advised in that
bugreport, and report back on the bugreport if it was successful or
not.

It's interesting to search for the suggested linker options...

-Wl,--no-keep-memory

...to see where they also came up:

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

I like the way the reporter gets an internal compiler error. These things,
including linker assertion errors which the user shouldn't see, don't seem to
get adequately diagnosed or remedied in my experience: you just get told that
"you're holding it wrong" and WONTFIX. Still, since 2004 there should be some
test cases by now. ;-)

I see that you have been working hard to persuade people, though:

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

It really sounds like a classic database problem, and I wonder what the
dataset size is. Of course data processing is faster if you can shove
everything into memory, but the trick is to manage volumes that are larger
than memory.

Cross-building would be a workaround, but Debian appears fundamentally opposed
to that, even though the alternative is the abandonment of architectures. And
you even have the new and shiny arm64 support in jeopardy because the
appropriate server hardware never seems to get to market (or stick around).

Post by Luke Kenneth Casson Leighton
*without* that option, the fact that firefox now needs SEVEN
GIGABYTES of resident RAM in order to complete the linker phase (which
is obviously impossible on a 32-bit processor), armhf, mips32, and
many other 32-bit architectures are just going to get... dropped by
distros...
*for no good reason*.

Well, it sounds like the usual practice of greasing up a hippo and hoping that
the result will be as lean and as fast as a cheetah. The Web gets ever more
complicated and yet many of the tasks we need it for remain the same. Still,
the usual advocates of disposable computing would have us continually upgrade
to keep being able to do even the simplest things, finding a way of selling us
what we already have, as always.

Paul

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook

[Luke Kenneth Casson Leighton]

Post by Paul Boddie
I like the way the reporter gets an internal compiler error. These things,
including linker assertion errors which the user shouldn't see, don't seem to
get adequately diagnosed or remedied in my experience: you just get told that
"you're holding it wrong" and WONTFIX. Still, since 2004 there should be some
test cases by now. ;-)

you know how lobsters will sit in a pot that's boiling because the
temperature differential is not big enough? well... it's like that.

unfortunately, over the past decade+, nobody predicted that the
linker phase would go *anywhere near* 4GB in size. that would be
INSANE!! so of *course* they ripped out all of the historic archaic
techniques that dealt efficiently with linking when there's less
memory than can be addressed even by adding Virtual Memory.

regarding cross-compiling: if you've seen how openembedded uses
bitbake to do cross-compiling (which includes setting an automatic
qemu redirect of autoconf script running and even qemu-emulated gcc
running), you start to get a deep appreciation for the dangers of
cross-compiling.

the key one is, you have absolutely no idea if the host correctly
generated the autoconf settings correctly or not. even running under
qemu is not accepted, because of the risks of qemu giving the wrong
information when compared to native hardware.

L.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachme

[David Niklas]

On Fri, 7 Dec 2018 15:36:33 +0000
Luke Kenneth Casson Leighton <***@lkcl.net> wrote:
<snip>

Post by Luke Kenneth Casson Leighton
regarding cross-compiling: if you've seen how openembedded uses
bitbake to do cross-compiling (which includes setting an automatic
qemu redirect of autoconf script running and even qemu-emulated gcc
running), you start to get a deep appreciation for the dangers of
cross-compiling.
the key one is, you have absolutely no idea if the host correctly
generated the autoconf settings correctly or not. even running under
qemu is not accepted, because of the risks of qemu giving the wrong
information when compared to native hardware.
L.

Yuk. You saved me a lot of time. I trusted qemu too!

David
_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netboo

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

Post by David Niklas

Post by Luke Kenneth Casson Leighton
the key one is, you have absolutely no idea if the host correctly
generated the autoconf settings correctly or not. even running under
qemu is not accepted, because of the risks of qemu giving the wrong
information when compared to native hardware.
L.

Yuk. You saved me a lot of time. I trusted qemu too!

well... on the other hand... i heard archlinux and the parabola team
use the technique all the time, for building officially-released
packages.

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send l

[Wookey]

Post by Paul Boddie
Cross-building would be a workaround, but Debian appears fundamentally opposed
to that,

Do you mean 'as buildds'? Debian's support from cross-building has
improved hugely over the last 8 years, and you can now crossbuild a
_lot_ of debian. Helmut told me 'nearly 2/3rds' a while ago, although
I'm not sure if that's 2/3rds of _everything_, or some subset.

There is lots more that could be done (not least educating upstreams
that like to do 'uncrossable things'), but we are the opposite of
'fundamentally opposed to it'.

Post by Paul Boddie
even though the alternative is the abandonment of architectures. And
you even have the new and shiny arm64 support in jeopardy because the
appropriate server hardware never seems to get to market (or stick around).

In what way is arm64 'in jeopardy'? I don't think it's going anywhere.

Wookey

[Paul Boddie]

Post by Wookey

Post by Paul Boddie
Cross-building would be a workaround, but Debian appears fundamentally
opposed to that,

Do you mean 'as buildds'?

I don't know. If that is the way the Debian archive is built then perhaps the
answer is "yes".

Post by Wookey
Debian's support from cross-building has improved hugely over the last 8
years, and you can now crossbuild a _lot_ of debian. Helmut told me 'nearly
2/3rds' a while ago, although I'm not sure if that's 2/3rds of _everything_,
or some subset.

It is certainly easier to perform cross-building activities, although I will
admit that I am not typically cross-building packages these days. I've
probably said before that when the cross-toolchains became available, it
helped a great deal with the things I tend to do, so I really appreciate them.

One thing that I do find frustrating, however, is the trail of pages on
various sites (wikis, typically) that describe the state of progress at
different points in time. It isn't particularly coherent and undermines the
impression of the progress that has been made.

Post by Wookey
There is lots more that could be done (not least educating upstreams
that like to do 'uncrossable things'), but we are the opposite of
'fundamentally opposed to it'.

Perhaps I should have clarified that Debian appears fundamentally opposed to
using cross-building as the means of building the archive for an architecture.
I understand that the aim is to ensure that people can run systems that are
able to build their own packages, but it seems that we will arrive at a point
where the imperfect result of natively-built packages needing to be
complemented by cross-built packages will become unavoidable.

Post by Wookey

Post by Paul Boddie
even though the alternative is the abandonment of architectures. And
you even have the new and shiny arm64 support in jeopardy because the
appropriate server hardware never seems to get to market (or stick around).

In what way is arm64 'in jeopardy'? I don't think it's going anywhere.

Maybe I got the wrong impression from this message:

https://groups.google.com/d/msg/linux.debian.devel.release/meYaIZR7Sm0/GtHUxlbGAQAJ

I guess that the main concerns are that some arm64 products aren't supporting
arm32 (of whichever flavour), that there are lots of "development board"
products but not so many "data centre" products, making automation and
management difficult. I might also add that when looking at ARM server
offerings, they seem to be pretty expensive (maybe to differentiate themselves
from existing offerings on traditional server architectures), and it probably
doesn't help that companies don't follow through on their roadmaps, meaning
that people end up waiting forever for something that might have been a usable
product.

But maybe there is no shortage of usable arm64 hardware for archive-building
purposes and that my perceptions of such shortages for other architectures are
also incorrect, too. If so, I stand corrected.

Paul

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@fil

[David Niklas]

On Fri, 7 Dec 2018 08:49:57 +0000

Post by Luke Kenneth Casson Leighton

Post by Julie Marchant
And as for 32-bit MIPS... just outta luck, I guess, at least until an
FSF-approved distro starts supporting it.

all 32-bit OSes are on the ropes, but not for the reason that most
people think. it's down to the linker phase of binutils *running out
of memory*, due to a default option to keep the object files and the
https://marc.info/?l=binutils-bugs&m=153030202426968&w=2
https://sourceware.org/bugzilla/show_bug.cgi?id=22831
unfortunately this is quotes not anyone's responsibility quotes, it's
one of those little-known syndrome / underlying / indirect causes.
please please for goodness sake could people spread awareness about
this more widely, try out some very large builds including
comprehensive debug build options, adding the option advised in that
bugreport, and report back on the bugreport if it was successful or
not.
*without* that option, the fact that firefox now needs SEVEN
GIGABYTES of resident RAM in order to complete the linker phase (which
is obviously impossible on a 32-bit processor), armhf, mips32, and
many other 32-bit architectures are just going to get... dropped by
distros...
*for no good reason*.
l.

HOLY COW!
Luke, there has been no progress on this for ~6 months. I could test 2
systems of my own and comment on the bug report. It would not be soon,
probably at least a week, but what's a week if you wait 6 months?
I have an RK3399 board by firefly and an HP Stream Notebook with
unupgreadable or replaceable RAM and disk. Perfect candidates for this
test.
I would preferably use Gentoo Linux, does it matter?

However, luke, have you, or anyone else, tried to trigger this with llvm's
gold linker?
I've no idea how to enable the gold linker in projects, or if it's a
"safe" thing to do. It was beta when last I looked.

FYI:
You should see what happens with gcc and graph-tool?
...
# bug 453544
CHECKREQS_DISK_BUILD="6G"
...
# most machines don't have enough ram for parallel builds
python_foreach_impl run_in_build_dir emake -j1
...
Yes, that's right, 6GB for 1 gcc process! And I've seen gcc use 7GB!


And that's not all, have a bunch of files to back up?
Dar-2.5.17 (Disk ARchiver)(latest).
Using bzip2 -9, NOT XZ -9! compression single threaded!
RSS (part way through!)
14.8GB
I have to talk to the dar devs.

RAM is not cheap, what is this FLOSS world coming to?

Sincerely,
David
_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

Post by David Niklas
HOLY COW!
Luke, there has been no progress on this for ~6 months. I could test 2
systems of my own and comment on the bug report. It would not be soon,
probably at least a week, but what's a week if you wait 6 months?
I have an RK3399 board by firefly and an HP Stream Notebook with
unupgreadable or replaceable RAM and disk. Perfect candidates for this
test.
I would preferably use Gentoo Linux, does it matter?

not in the slightest. the more the better

Post by David Niklas
However, luke, have you, or anyone else, tried to trigger this with llvm's
gold linker?

no.

Post by David Niklas
Yes, that's right, 6GB for 1 gcc process! And I've seen gcc use 7GB!

gcc is fine as (ok this is what i was told 15 years ago) there's
detection built-in to utilise available resident RAM, dynamically.

Post by David Niklas
And that's not all, have a bunch of files to back up?
Dar-2.5.17 (Disk ARchiver)(latest).
Using bzip2 -9, NOT XZ -9! compression single threaded!
RSS (part way through!)
14.8GB
I have to talk to the dar devs.
RAM is not cheap, what is this FLOSS world coming to?

the assumption is, you're on an x86 64-bit system, with 32-64GB of
RAM and a 3200mbytes/sec NVMe SSD, so why should you care?

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@file

[Lauri Kasanen]

On Sat, 8 Dec 2018 05:36:36 +0000

Post by Luke Kenneth Casson Leighton

Post by David Niklas
Yes, that's right, 6GB for 1 gcc process! And I've seen gcc use 7GB!

gcc is fine as (ok this is what i was told 15 years ago) there's
detection built-in to utilise available resident RAM, dynamically.

I've hit OOM with GCC 5 and 7, building Webkit with LTO (on 64-bit).

- Lauri

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-n

[Luke Kenneth Casson Leighton]

Post by Lauri Kasanen
I've hit OOM with GCC 5 and 7, building Webkit with LTO (on 64-bit).

hmmm that's new.... gcc 4 was fine.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send

[zap]

Post by Luke Kenneth Casson Leighton
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

Post by David Niklas
HOLY COW!
Luke, there has been no progress on this for ~6 months. I could test 2
systems of my own and comment on the bug report. It would not be soon,
probably at least a week, but what's a week if you wait 6 months?
I have an RK3399 board by firefly and an HP Stream Notebook with
unupgreadable or replaceable RAM and disk. Perfect candidates for this
test.
I would preferably use Gentoo Linux, does it matter?

not in the slightest. the more the better

Any plans to use rk3399 for a 2nd revision of the eoma68 standard? or
any alternative arm processor? Since risc-v is maybe 3+ years out of the
way?

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachme

[Eric Bavier]

On Fri, 7 Dec 2018 08:49:57 +0000

Post by Luke Kenneth Casson Leighton

Post by Julie Marchant
And as for 32-bit MIPS... just outta luck, I guess, at least until an
FSF-approved distro starts supporting it.

Until recently, GuixSD supported MIPS (specifically for yeelong
laptops, iirc). I believe the support has unfortunately lapsed due to a
lack of developer effort, but it could probably be resurected with some
more attention.

Post by Luke Kenneth Casson Leighton
all 32-bit OSes are on the ropes, but not for the reason that most
people think. it's down to the linker phase of binutils *running out
of memory*, due to a default option to keep the object files and the
https://marc.info/?l=binutils-bugs&m=153030202426968&w=2
https://sourceware.org/bugzilla/show_bug.cgi?id=22831
unfortunately this is quotes not anyone's responsibility quotes, it's
one of those little-known syndrome / underlying / indirect causes.
please please for goodness sake could people spread awareness about
this more widely, try out some very large builds including
comprehensive debug build options, adding the option advised in that
bugreport, and report back on the bugreport if it was successful or
not.

I recently added this flag to Guix's qtwebkit build, and it seems to
work well so far.

https://git.savannah.gnu.org/cgit/guix.git/commit/?id=ebdb15bc3540b1901f223bc0689bae51a2f88fc4

Unfortunately, an possibly unrelated error is causing the build to fail
for i686 and dependency failures are preventing the armhf builds from
going through, currently:

https://hydra.gnu.org/job/gnu/master/qtwebkit-5.212.0-alpha2.i686-linux
https://hydra.gnu.org/job/gnu/master/qtwebkit-5.212.0-alpha2.armhf-linux

While the Guix projects has a nice build farm to provide users with
pre-built packages, I try to, when I can, make it less painful for folks
to build their packages locally.

Post by Luke Kenneth Casson Leighton
*without* that option, the fact that firefox now needs SEVEN
GIGABYTES of resident RAM in order to complete the linker phase (which
is obviously impossible on a 32-bit processor), armhf, mips32, and
many other 32-bit architectures are just going to get... dropped by
distros...
*for no good reason*.

I might do some exploration to see if this can fix some of Guix's
current build failures for i686 and armhf.

`~Eric
_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@f

[Pablo Rath]

Post by Julie Marchant
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Post by Luke Kenneth Casson Leighton
the RYF Criteria are extremely specific: it's not enough to have a
non-free section that's "disabled", it must be *not possible* for
an average end-user to *accidentally* end up installing non-free
software by complete accident such as "running a GUI and
arbitrarily clicking random buttons".
the absolute worst-case is where an inexperienced end-user,
running e.g. synaptics, goes "i have no idea what this does, i'm
just gonna click it" and it happens to enable the "non-free"
section, happens to silently and happily perform an apt-get update,
and wow, suddenly there's binary firmware available... all WITHOUT
warning the user of the consequences.

[...]

Post by Julie Marchant
Just a note, the only way to add the non-free section in Debian
involves typing the word "non-free" into a particular spot on a text
file, or if using the GUI interface, to edit the entry for the Debian
repo to type "non-free" into the "Components" textbox in the "Edit
Source" dialog box. So it's not really possible to accidentally enable
the non-free repository. I honestly tend to disagree with the FSF's
classification of Debian for this reason.

I have just checked synaptics on my Debian stable Laptop with only main
repos enabled and could not find a button to enable non-free with just
one (or a few) clicks.

But according to the points here:
https://www.gnu.org/distros/common-distros.en.html

there are other concerns besides "number of clicks" and "accidents of Joe
Average Enduser".
So in the foreseeable future FSF endorsement of Debian is unlikely.

Has anyone on this list attended:
https://www.fsf.org/events/molly-deblanc-john-sullivan-20180803-hsinchucity-debconf

The user group of the first (crowd supply) computer cards will split
into subgroups running the distributions mentioned in the campaign
rewards (Debian, Devuan, Parabola, Fedora). Some will try to stay as
close to the vanilla state of a fresh install. Some will use a state
working with linux-sunxi-kernel (as previously discussed on this list).
I think we can expect a lot of diversity. I am going to be in the Debian
group.

Post by Julie Marchant
That being said, it's the FSF's rules, so Parabola is the only real
option regardless of what one might think of the FSF's classification.

I agree.

kind regards
Pablo

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attac

[Stefan Monnier]

Post by Julie Marchant
Just a note, the only way to add the non-free section in Debian
involves typing the word "non-free" into a particular spot on a text
file, or if using the GUI interface, to edit the entry for the Debian
repo to type "non-free" into the "Components" textbox in the "Edit
Source" dialog box. So it's not really possible to accidentally enable
the non-free repository. I honestly tend to disagree with the FSF's
classification of Debian for this reason.

I'm not happy about the Debian<->FSF situation either, but note that if
you want your Emacs install to include all the online doc with which it
should normally be accompanied, you have to add the
`emacs-common-non-dfsg` package from the `non-free` section.

So, the FSF ends up wanting to encourage Debian users to add the
`non-free` section to access the docs of several important GNU packages.

There's also the fact that the wiki.debian.org includes several places
where they encourage users to install `non-free` packages.

I wish the two associations could take a more pragmatic look at the
situation to resolve these disagreements.


Stefan


_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to ar

[Luke Kenneth Casson Leighton]

Post by Stefan Monnier
There's also the fact that the wiki.debian.org includes several places
where they encourage users to install `non-free` packages.

ohh. yeah. that won't help :) that would be viewed as "endorsement
of the installation of non-free software", for sure.

Post by Stefan Monnier
I wish the two associations could take a more pragmatic look at the
situation to resolve these disagreements.

well, one simple practical way would be to follow the trick deployed
by devuan. what they did is extremely nifty: they created a proxy apt
service that, for the most part, is just a "pass-through" to the
standard debian mirrors.

one of the issues associated normally with maintaining a
debian-augmented distro is: it takes considerably deep pockets to
maintain a 160GB+ debian mirror.

a pass-through proxy that pre-vetted the repos, filtering out the
entirety of the non-free section, would actively prevent and prohibit
unintentional mistaken installations of non-free software by end-users
blindly following online documentation, "authoritative" wiki pages and
so on.

ultimately, their nightmare scenario is where *uninformed* end-users
en-masse end up installing proprietary software *without* being aware
of the consequences.

they genuinely don't care about the *intelligent* end-users that make
informed decisions and smash through all and any barriers to bypass
all and any limitations and restrictions placed in their path to get
at the non-free firmware [or whatever].

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send

[Ricardo Wurmus]

Post by Julie Marchant
That being said, it's the FSF's rules, so Parabola is the only real
option regardless of what one might think of the FSF's classification.

The EOMA68-A20 is an armhf board, isn’t it? Since GuixSD is available
for armhf, porting it to this board should not be too difficult. GuixSD
is also one of the FSF-endorsed GNU+Linux distributions.

[I don’t know if any Guix hackers have received an A20 board for porting
(I don’t have one), and if they have I don’t know what the status is.]

--
Ricardo


_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to

[Luke Kenneth Casson Leighton]

Post by Ricardo Wurmus
[I don’t know if any Guix hackers have received an A20 board for porting

i donated one to the key developers when i encountered them at fosdem 2017.

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Sen

[Denis 'GNUtoo' Carikli]

On Wed, 5 Dec 2018 03:38:59 +0000

Post by Luke Kenneth Casson Leighton
it was quite hilarious to get up and running.
https://wiki.parabola.nu/MIPS_Installation - oh. discontinued.
that's not going to help *sigh*.

You also have an ARM installation guide[1], however in your case that's
probably not the easiest way to deal with it.

There is a way to use LXC to do a cross-pacstrap, however it's a bit
tricky.

If you don't have Parabola installed already, install it on your
GNU/Linux distribution. It should be something like that (I didn't test
that though):
1) First install and setup virt-manager
2) Create a disk image that you can mount externally:
# cd /var/lib/libvirt/images/
# qemu-img create -f raw parabola.raw 1G
3) Run the installation with the install media
4) boot the installed rootfs and run
# pacstrap /mnt
5) power off the vm and copy the /mnt outside of the vm, then setup a
loop device
# udisksctl loop-setup \
-f /var/lib/libvirt/images/parabola.raw
6) Copy the /mnt outside of the rootfs
7) Setup LXC through virt-manager to be able to use systemd
8) Install and setup the OpenSSH server inside the LXC system vm
9) Install the required packages:
# pacman -S qemu-user-static-binfmt libretools

Then trick is to:
1) export the /proc/sys/fs/binfmt_misc/ from the host to
the /proc/sys/fs/binfmt_misc/ from the target in virt-manager.
2) run /usr/lib/systemd/systemd-binfmt by hand
(I didn't manage to make the binfmt systemd service start)

Once that is done you can then create a chroot for building packages[2]:
$ sudo librechroot -A armv7h -n parabola-armv7h make
# arch-chroot /var/lib/archbuild/parabola-armv7h

Or you could create an installation rootfs:
# mkdir parabola-armv7h
# pacstrap -C /usr/share/pacman/defaults/pacman.conf.armv7h \
parabola-armv7h/
# arch-chroot /var/lib/archbuild/parabola-armv7h

If you want to use a different kernel (like a deblobbed Allwinner Linux
kernel) that is way older it would be best to:
1) Make a PKGBUILD for it. That can be integrated in Parabola very
easily
2) libremakepkg is an abstraction on top of makepkg which enables you
to build in a chroot, including chroot of different architectures.
$ cd /path/to/directory/that/has/a/PKGBUILD
$ sudo libremakepkg -n parabola-armv7h
3) You will need to use OpenRC if systemd doesn't
support your old kernel version

I've verified that with librechroot under a Parabola LXC under a
Parabola host and I got:
# file[...]/usr/bin/bash [...]/usr/bin/bash:
ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically
linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0,
BuildID[sha1]=2ed90c858f8b750764b9ef6ebf6e23499640e3c9, stripped

If you need serial console with OpenRC, I've written some documentation
for it with another device in mind here:
https://libreplanet.org/wiki/Group:Hardware/Freest/e-readers/Aura_H2O_Edition_2#Serial_console_with_OpenRC

I hope that it's still useful, especially if you need to build things.
Also note that I'm new to Parabola development, so there might be even
easier ways that I don't know of yet.

References:
-----------
[1]https://wiki.parabola.nu/ARM_Installation_Guide
[2]There is no Linux image in it. You can use libremakepkg to build
packages in this chroot[3]
[3]https://wiki.parabola.nu/Package_maintainer_guide

Denis.
_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phcomp.co.u