Kalevi Kolttonen <[email protected]> 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 <[email protected]>,
Richard Kettlewell <[email protected]d> 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 <[email protected]>,
Richard Kettlewell <[email protected]d> 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.
On Debian-derived platforms, that’s what apt-get build-dep is for.
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 <[email protected]> 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 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?
Janis Papanagnou <[email protected]> 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. [...]
On Sat, 28 Dec 2024 00:44:10 +0100, 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?
On Linux, there is no “development environment” versus “user environment”.
The same packaging tools work with both source code and built binaries.
./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).
You think it's normal that on a Linux installation where, say, no 'cc'
(as prominent example of a development tool) is installed the package
manager would first install ALL the necessary compilers and scripting languages just to create a binary (as opposed to just installing the
binary)?
On Sat, 28 Dec 2024 19:40:46 +0100, Janis Papanagnou wrote:
You think it's normal that on a Linux installation where, say, no 'cc'
(as prominent example of a development tool) is installed the package
manager would first install ALL the necessary compilers and scripting
languages just to create a binary (as opposed to just installing the
binary)?
The discussion has to do with creating your own version of the binary,
rather than using the repo-provided version.
This codebase is absolutely massive! I am beginning to lose patience.
Lawrence D'Oliveiro <[email protected]d> wrote:
On Sat, 28 Dec 2024 19:40:46 +0100, Janis Papanagnou wrote:
You think it's normal that on a Linux installation where, say, no 'cc'
(as prominent example of a development tool) is installed the package
manager would first install ALL the necessary compilers and scripting
languages just to create a binary (as opposed to just installing the
binary)?
The discussion has to do with creating your own version of the binary,
rather than using the repo-provided version.
Right.
Anyway, to be honest, I never realized how bloated Thunderbird is.
The source RPM thunderbird-128.5.2-1.fc41.src.rpm is 690MB and
the main source directory unpacked is:
~/tmp/tb/thunderbird-128.5.2 $ du -sh
4.2G .
Building TB with the help of a pre-made spec file on Fedora is
probably very much easier than doing 'git clone' and trying to
build it from there. Using 'dnf', it was just one command to
download all the dependencies. I suppose the size of the
dependency packages was 260MB in total. It would be a nightmare
having to download them manually and then building them.
Packages are just so handy.
Fedora and Red Hat have already done the hard work so it
is wise to use their source RPM as a basis for your own
modifications when you are on Fedora or Red Hat Enterprise
Linux.
My single CPU Thunderbird build has now lasted for over two
and half hours and I have no clue when it will be ready.
This codebase is absolutely massive! I am beginning to
lose patience.
br,
KK
Kalevi Kolttonen <[email protected]> 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.
Lawrence D'Oliveiro <[email protected]d> wrote:
On Sat, 28 Dec 2024 19:40:46 +0100, Janis Papanagnou wrote:
You think it's normal that on a Linux installation where, say, no 'cc'
(as prominent example of a development tool) is installed the package
manager would first install ALL the necessary compilers and scripting
languages just to create a binary (as opposed to just installing the
binary)?
The discussion has to do with creating your own version of the binary,
rather than using the repo-provided version.
Right.
Anyway, to be honest, I never realized how bloated Thunderbird is.
The source RPM thunderbird-128.5.2-1.fc41.src.rpm is 690MB and
the main source directory unpacked is:
~/tmp/tb/thunderbird-128.5.2 $ du -sh
4.2G .
Why TF is the rust compiler involved in the process at all?
On Sat, 28 Dec 2024 23:32:37 -0000 (UTC)
[email protected] (Kalevi Kolttonen) gabbled:
Lawrence D'Oliveiro <[email protected]d> wrote:
On Sat, 28 Dec 2024 19:40:46 +0100, Janis Papanagnou wrote:
You think it's normal that on a Linux installation where, say, no 'cc' >>>> (as prominent example of a development tool) is installed the package
manager would first install ALL the necessary compilers and scripting
languages just to create a binary (as opposed to just installing the
binary)?
The discussion has to do with creating your own version of the binary,
rather than using the repo-provided version.
Right.
Anyway, to be honest, I never realized how bloated Thunderbird is.
The source RPM thunderbird-128.5.2-1.fc41.src.rpm is 690MB and
the main source directory unpacked is:
~/tmp/tb/thunderbird-128.5.2 $ du -sh
4.2G .
Welcome to Lego brick style programming where the main application devs are incompetant halfwits unable to implement even simple things themselves beyond designing (if that applies to Thunderbird) a GUI so have to import 101 libraries
to do everything for them.
I've written my own newsreader system and while admittedly its command line only it requires only one 3rd party library which is OpenSSL.
Because these builds take four hours, I have to admit defeat.
I simply do not have the time to make more modification
attempts.
Is the whole thing obscene ? Yes. You won't find too many
software creations, this distorted. Still, people are using it.
Most people are not aware what is under the hood. It's
a herd of elephants :-)
Kalevi Kolttonen <[email protected]> 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.
On Sun, 12/29/2024 4:54 AM, [email protected] wrote:
[...]
I've written my own newsreader system and while admittedly its command line >> only it requires only one 3rd party library which is OpenSSL.
[ snip explanations of some TB internals ]
Is the whole thing obscene ? Yes. You won't find too many
software creations, this distorted. Still, people are using it.
Most people are not aware what is under the hood. It's
a herd of elephants :-)
In article <vkrfue$vl1b$[email protected]>, Paul <[email protected]d> wrote:
...
Is the whole thing obscene ? Yes. You won't find too many
software creations, this distorted. Still, people are using it.
Most people are not aware what is under the hood. It's
a herd of elephants :-)
Just out curiosity, does all of this apply to the Windows version as well?
I know this thread is mostly about the Linux version, and although I
actually don't use TB at all, I know someone who uses the Windows version.
On Sun, 12/29/2024 4:54 AM, [email protected] wrote:
[...]
I've written my own newsreader system and while admittedly its command line >>> only it requires only one 3rd party library which is OpenSSL.
That's a fine property. - Too bad one has to write one's own piece
of software to get a more sensibly defined product.
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.
In article <vkrfue$vl1b$[email protected]>, Paul <[email protected]d> wrote:
...
Is the whole thing obscene ? Yes. You won't find too many
software creations, this distorted. Still, people are using it.
Most people are not aware what is under the hood. It's
a herd of elephants :-)
Just out curiosity, does all of this apply to the Windows version as well?
I know this thread is mostly about the Linux version, and although I
actually don't use TB at all, I know someone who uses the Windows version.
Eric Pozharski <[email protected]> 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!
[email protected] (Kalevi Kolttonen) writes:
Eric Pozharski <[email protected]> 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 <[email protected]> wrote:
[email protected] (Kalevi Kolttonen) writes:
Eric Pozharski <[email protected]> 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 <[email protected]> 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 <[email protected]> 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.
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 <[email protected]d> 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).
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 714 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 141:56:27 |
| Calls: | 12,088 |
| Calls today: | 1 |
| Files: | 14,998 |
| Messages: | 6,517,448 |
