| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 43 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 94:15:58 |
| Calls: | 290 |
| Calls today: | 1 |
| Files: | 904 |
| Messages: | 76,378 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
On 28.12.2024 00:22, Kalevi Kolttonen wrote:
[...]
No need to be skeptical, we live in modern ages
where things have been made quite convenient for us.
LOL. :-)
My comment above was a reference to the bad old
days when you had to manually download tar.gz packages
and compile them to satisfy dependencies. Now the
builds are super easy with the help of package management.
Compiling Thunderbird should be very easy indeed
when we use Linux distro's package management.
You expect _users_ of tools to use a _development_
environment to fix *inherent* shortcomings of a tool?
(Shortcomings that should not be there in the first
place!)
Why would you think so? This is just one way to
solve the problem. [...]
./mach build -v
with
./mach build -j6 -v
On 28.12.2024 00:22, Kalevi Kolttonen wrote:
[...]
No need to be skeptical, we live in modern ages
where things have been made quite convenient for us.
LOL. :-)
Compiling Thunderbird should be very easy indeed
when we use Linux distro's package management.
You expect _users_ of tools to use a _development_
environment to fix *inherent* shortcomings of a tool?
(Shortcomings that should not be there in the first
place!)
I cannot understand this because all references to
patches 416 and 419 are commented out in the Fedora
41 spec file. I now completely removed them and will
try again...
It is really painful but I guess I have to use
just a single CPU:
./mach build -j1 -v
Because of this, the build takes forever to complete.
Personally I don't think that package managers contribute a lot since
for ordinary users it's the same whether the package managers install a binary package or a source that is compiled under the hood.
The difference is that source package needs a development
environment (compiler, etc.) that "ordinary users" might not have
installed or may not want to get installed (just for that).
Kalevi Kolttonen <kalevi@kolttonen.fi> wrote:
I cannot understand this because all references to
patches 416 and 419 are commented out in the Fedora
41 spec file. I now completely removed them and will
try again...
I am having massive problems with having only 16GB of
RAM.
Using 'top', I was able to see that Rust compiler 'rustc'
was hogging something like 11GB of memory, and then
after a while OOM killer got rid of the Rust compiler
process. I am also seeing swapping take place when I
attempt the build.
Why TF is the rust compiler involved in the process at all?
Because these builds take four hours, I have to admit defeat.
I simply do not have the time to make more modification
attempts.
Kalevi Kolttonen <kalevi@kolttonen.fi> wrote:*SKIP* [ 14 lines 1 level deep]
./mach build -vOkay, I am finally back at home and it is 21:43 o'clock.
with
./mach build -j6 -v
I cannot understand this because all references to patches 416 and 419
are commented out in the Fedora 41 spec file. I now completely removed
them and will try again...
Yay! The joy of building redhat. Expect your
build dependencies being inadequate, missing,
or plainly wrong. Just saying.
On 12/27/24 18:44, Janis Papanagnou wrote:
On 28.12.2024 00:22, Kalevi Kolttonen wrote:
Compiling Thunderbird should be very easy indeed
when we use Linux distro's package management.
You expect _users_ of tools to use a _development_
environment to fix *inherent* shortcomings of a tool?
(Shortcomings that should not be there in the first
place!)
IIRC, this is in reference to my difficulty when Thunderbird changed the Reply button to mean "Reply" rather than "Followup", and instead added a
new button that is labelled "Followup". I have never complained about
that change - it was an entirely sensible one. I'm just having trouble re-training myself to use the newer, more sensible interface in a few
years after spending a couple of decades using the older, less sensible
one. And I fully appreciate other people's irritation at my difficulty
with re-training.
I wouldn't mind if they reinstated the ability, which existed in older versions of Thunderbird, to rearrange the list of buttons that are
displayed. I do complain about the removal of that customization
ability. I don't want to go back to those older versions because that
would mean undoing other improvements. I'm especially worried about
undoing security bug fixes.
I don't like the idea of creating my own personal version of Thunderbird
by modifying their source code, because it means I would have to re-do
the build every time they put out a new version. I want quick and easy upgrades to newer versions, especially security bug fixes, and that
desire conflicts with the desire for customization.
Without my hack, the build process took four hours to complete
and it produced a working TB. However, with my tiny JavaScript
modification, the build failed.
Because these builds take four hours, I have to admit defeat.
I simply do not have the time to make more modification
attempts.
What is more, James Kuyper said that he does not want to
build his own TB so it was all in vain anyway.
Eric Pozharski <apple.universe@posteo.net> wrote:
Yay! The joy of building redhat. Expect your
build dependencies being inadequate, missing,
or plainly wrong. Just saying.
After some minor spec file tweaking, I managed to do
*one* successful TB build, but because Rust compiler can
hog almost 16GB of memory, most of the time I just
cannot build TB using my modest Lenovo laptop. OOM
killer kicks in and destroys the build.
I never could have believed that having 16GB of
RAM and 8GB of swap is not enough for building TB!
kalevi@kolttonen.fi (Kalevi Kolttonen) writes:
Eric Pozharski <apple.universe@posteo.net> wrote:
Yay! The joy of building redhat. Expect your
build dependencies being inadequate, missing,
or plainly wrong. Just saying.
After some minor spec file tweaking, I managed to do
*one* successful TB build, but because Rust compiler can
hog almost 16GB of memory, most of the time I just
cannot build TB using my modest Lenovo laptop. OOM
killer kicks in and destroys the build.
I never could have believed that having 16GB of
RAM and 8GB of swap is not enough for building TB!
You did it. Thanks for sharing the experience.
Salvador Mirzo <smirzo@example.com> wrote:
kalevi@kolttonen.fi (Kalevi Kolttonen) writes:
Eric Pozharski <apple.universe@posteo.net> wrote:
Yay! The joy of building redhat. Expect your
build dependencies being inadequate, missing,
or plainly wrong. Just saying.
After some minor spec file tweaking, I managed to do
*one* successful TB build, but because Rust compiler can
hog almost 16GB of memory, most of the time I just
cannot build TB using my modest Lenovo laptop. OOM
killer kicks in and destroys the build.
I never could have believed that having 16GB of
RAM and 8GB of swap is not enough for building TB!
You did it. Thanks for sharing the experience.
With some incredible luck, it worked out *once*. :-)
That also explains why some people were skeptical here. Even with a sophisticated system to make the compilation succeed, it's still not
without a thrill.
Eric Pozharski <apple.universe@posteo.net> wrote:
Yay! The joy of building redhat. Expect your
build dependencies being inadequate, missing,
or plainly wrong. Just saying.
After some minor spec file tweaking, I managed to do
*one* successful TB build, but because Rust compiler can
hog almost 16GB of memory, most of the time I just
cannot build TB using my modest Lenovo laptop. OOM
killer kicks in and destroys the build.
I never could have believed that having 16GB of
RAM and 8GB of swap is not enough for building TB!
br,
KK
On Sun, 12/29/2024 1:59 PM, Kalevi Kolttonen wrote:
Eric Pozharski <apple.universe@posteo.net> wrote:
Yay! The joy of building redhat. Expect your
build dependencies being inadequate, missing,
or plainly wrong. Just saying.
After some minor spec file tweaking, I managed to do
*one* successful TB build, but because Rust compiler can
hog almost 16GB of memory, most of the time I just
cannot build TB using my modest Lenovo laptop. OOM
killer kicks in and destroys the build.
I never could have believed that having 16GB of
RAM and 8GB of swap is not enough for building TB!
br,
KK
Try a chain saw next time :-)
It's one of the first practical tests the machine got.
The RPMBuild phase was awfully slow (it spoiled the fun).
But the compiles and linking behaved well. RPM compression
seems to run on one core.
[Picture] During compile phase...
https://i.postimg.cc/44qRrgxb/Thunderbird-Fedora41-Build-From-Source-via-Mock.gif
I think it's possible the build slows down, the longer it runs.
Like "something" is fragmenting.
Even on this machine, the process does not encourage
interactive operation. It takes too long. Adjusting the
command a bit so it just compiles and links, would be
better, if that's possible.
mock --resultdir=/tmp/results --rootdir=/tmp/mock --rebuild thunderbird-128.5.2-1.fc41.src.rpm | tee /tmp/build_out.txt
I picked Fedora for the job, because it only takes two commands
in a terminal, to do it. In simplified terms...
dnf download --source packagename # Downloading source doesn't need root. >mock --rebuild packagename # User account belongs to "mock" group, doesn't build as root
But I need to do something else to that Mock command,
to get what I want (a "portable" copy of Thunderbird,
there should be a dir created with that sitting in it).
Summary: No question, a bit of RAM helps. Some of the RAM
accounting in Linux is just weird (process resident
seen rising, graph in system monitor remains flat).
I was expecting to see a "hump" while linking, but
the graph was relatively flat and featureless.
Paul
Why would you expect the link step to require a lot of
memory? The linker builds an elf executable from the contents
of ELF object files, one ELF section at a time. It doesn't
construct the entire ELF executable in memory before writing it out.
I've built Thunderbird on both Windows and Linux.
It was the Windows build that left a bad taste.
Once you repeatedly have build failures during linking, you are always looking for it.
Kalevi Kolttonen <kalevi@kolttonen.fi> wrote:
...
Thunderbird is open source, maybe even free software.
I am sure it is extremely easy to either remove the
"reply" button or to bind it to the "followup" function.
I doubt it is any simple matter to find it in the massive source code,
much less to figure out how to fix it, much less figure out how to successfully re-build (and test!) it after making your changes.
Generally, most complicated GUI software, even if technically Open
Source, is difficult, if not impossible, for ordinary people using
ordinary machines, to re-build from source. Among other things, you
will generally end up spending many hours, if not days, getting all
the dependencies installed.
On Debian-derived platforms, thats what apt-get build-dep is for.
Source package rebuild is also standardized. It looks like the RH world
has something pretty similar.
In article <wwvh66p9ntv.fsf@LkoBDZeT.terraraq.uk>,
Richard Kettlewell <invalid@invalid.invalid> wrote:
...
On Debian-derived platforms, thats what apt-get build-dep is for.
Source package rebuild is also standardized. It looks like the RH world >>has something pretty similar.
I know all that - and, in theory, it should "just work".
But my experience is that theory and practice diverge.
Now, I may not be the most capable person in the world, probably not even
in the top 10 (or 100). But that's exactly my point. It's just not an
easy task for ordinary people under ordinary circumstances.
In article <wwvh66p9ntv.fsf@LkoBDZeT.terraraq.uk>,
Richard Kettlewell <invalid@invalid.invalid> wrote:
...
On Debian-derived platforms, thats what apt-get build-dep is for.
Source package rebuild is also standardized. It looks like the RH world
has something pretty similar.
I know all that - and, in theory, it should "just work".
But my experience is that theory and practice diverge.
Now, I may not be the most capable person in the world, probably not even
in the top 10 (or 100). But that's exactly my point. It's just not an
easy task for ordinary people under ordinary circumstances.
If I were not full of tasks right now, I would set up a VM with Debian
and try it out---build-dep for Thunderbird. Just to see if compiles successfully without much hacking involved.
If I were not full of tasks right now, I would set up a VM with Debian
and try it out---build-dep for Thunderbird. Just to see if compiles successfully without much hacking involved. I am also skeptical of such things. It usually works on smaller projects; I'd be surprised and
happy to find out that it works with no hacking involved.
[...]
No need to be skeptical, we live in modern ages
where things have been made quite convenient for us.
Compiling Thunderbird should be very easy indeed
when we use Linux distro's package management.
[ snip suggested 8-step development process ]
I got 16GM of RAM. Maybe the build parameters in the
spec file are too aggressive for this modest laptop,
but I did not find any "make -j" invocation.
Now I have to sleep and maybe try it again tomorrow.
On 28.12.2024 00:22, Kalevi Kolttonen wrote:
[...]
No need to be skeptical, we live in modern ages
where things have been made quite convenient for us.
LOL. :-)
Compiling Thunderbird should be very easy indeed
when we use Linux distro's package management.
You expect _users_ of tools to use a _development_
environment to fix *inherent* shortcomings of a tool?
(Shortcomings that should not be there in the first
place!)
Kalevi Kolttonen <kalevi@kolttonen.fi> wrote:
I got 16GM of RAM. Maybe the build parameters in the
spec file are too aggressive for this modest laptop,
but I did not find any "make -j" invocation.
Now I have to sleep and maybe try it again tomorrow.
Still awake for a while. I looked at the spec file
and replaced:
./mach build -v
with
./mach build -j6 -v
Maybe in the morning we have a complete build.
On Thu, 1/2/2025 11:29 AM, Scott Lurndal wrote:
Why would you expect the link step to require a lot of
memory? The linker builds an elf executable from the contents
of ELF object files, one ELF section at a time. It doesn't
construct the entire ELF executable in memory before writing it out.
It's based on experience, not imagination.
I've built Thunderbird on both Windows and Linux.
It was the Windows build that left a bad taste.
Once you repeatedly have build failures during linking,
you are always looking for it.
Paul <nospam@needed.invalid> writes:
On Thu, 1/2/2025 11:29 AM, Scott Lurndal wrote:
Why would you expect the link step to require a lot of
memory? The linker builds an elf executable from the contents
of ELF object files, one ELF section at a time. It doesn't
construct the entire ELF executable in memory before writing it out.
It's based on experience, not imagination.
I've built Thunderbird on both Windows and Linux.
It was the Windows build that left a bad taste.
Once you repeatedly have build failures during linking,
you are always looking for it.
Ah, well windows. You need not elaborate.
I've been fortunate to have never built software in a
microsoft environment (aside an optical jukebox driver
for NT3.51 once on a contract job - even then I did
all the editing on unix and just compiled and tested
on the windows box).
