Firefox ESR EOL

[piorunz]

Hello,

I noticed that Debian Stable uses Firefox ESR 78.15.0, which is final
update of 78 series. All further updates go to Firefox ESR 91, as
Mozilla page says:
https://www.mozilla.org/en-US/firefox/78.15.0/releasenotes

"Version 78.15.0, first offered to ESR channel users on October 5, 2021
This is the final planned ESR78 release. Eligible users will be
automatically updated to the ESR91 release on November 2."

Since 2 November, Firefox 78 is EOL and we all should upgrade. I use
Debian Bullseye on several of my computers, and they all are on ESR 78.

Firefox 91 should migrate to Stable as soon as possible, otherwise we
risk unpatched security vulnerabilities being present in Debian Stable,
there are several of them already.
https://security-tracker.debian.org/tracker/source-package/firefox-esr

Is there any remedy for this?

--
With kindest regards, Piotr.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄⠀⠀⠀⠀

[Georgi Naplatanov]

On 12/9/21 12:12, piorunz wrote:
> Hello,
>
> I noticed that Debian Stable uses Firefox ESR 78.15.0, which is final
> update of 78 series. All further updates go to Firefox ESR 91, as
> Mozilla page says:
> https://www.mozilla.org/en-US/firefox/78.15.0/releasenotes
>
> "Version 78.15.0, first offered to ESR channel users on October 5, 2021
> This is the final planned ESR78 release. Eligible users will be
> automatically updated to the ESR91 release on November 2."
>
> Since 2 November, Firefox 78 is EOL and we all should upgrade. I use
> Debian Bullseye on several of my computers, and they all are on ESR 78.
>
> Firefox 91 should migrate to Stable as soon as possible, otherwise we
> risk unpatched security vulnerabilities being present in Debian Stable,
> there are several of them already.
> https://security-tracker.debian.org/tracker/source-package/firefox-esr
>
> Is there any remedy for this?
>

Hey Piotr,

a new release of Firefox ESR was uploaded to Sid two days ago and
probably will be uploaded to stable soon.

https://buildd.debian.org/status/package.php?p=firefox-esr&suite=sid

Kind regards
Georgi

[Christian Britz]

Security is the reason why I download and install browser and mail
client directly from the vendor, not Debian repositories.

For Chromium the situation is (was) even worse IIRC.

Am 09.12.21 um 11:12 schrieb piorunz:

[piorunz]

On 09/12/2021 12:47, Georgi Naplatanov wrote:

> Hey Piotr,
>
> a new release of Firefox ESR was uploaded to Sid two days ago and
> probably will be uploaded to stable soon.
>
> https://buildd.debian.org/status/package.php?p=firefox-esr&suite=sid

ESR 91 was first uploaded to sid in November. It didn't migrated to
Testing, or Stable, due to problems. Package tracker show some details:
https://tracker.debian.org/pkg/firefox-esr

There is a bug here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001234

Rust compiler for Stable is not available? It means we have to continue
to use outdated, vulnerable Firefox ESR until this is resolved? When it
will be?

[Kenneth Parker]

I am testing Bookworm now, both on xfce and lxde.  

On Thu, Dec 9, 2021 at 8:01 AM Christian Britz <cbr...@t-online.de> wrote:

Security is the reason why I download and install browser and mail
client directly from the vendor, not Debian repositories.

For Chromium the situation is (was) even worse IIRC.

Indeed.   Apt "politely" told me that chromium was "replaced" by chromium-bsu, an Arcade Shoot-em-up Game!  :-) 

 > Am 09.12.21 um 11:12 schrieb piorunz:

<snip>

> Firefox 91 should migrate to Stable as soon as possible, otherwise we
> risk unpatched security vulnerabilities being present in Debian Stable,
> there are several of them already.
> https://security-tracker.debian.org/tracker/source-package/firefox-esr

(Obviously, Bookworm comes before Bullseye in this Process).

To test Firefox 91 in Bookworm, can I use *one* Repository in Unstable, as an "unofficial Backports"?  (And then only install Firefox 91 from there)?

Thanks in advance,

Kenneth Parker 

[Tixy]

On Thu, 2021-12-09 at 14:18 +0000, piorunz wrote:
> On 09/12/2021 12:47, Georgi Naplatanov wrote:
>
> > Hey Piotr,
> >
> > a new release of Firefox ESR was uploaded to Sid two days ago and
> > probably will be uploaded to stable soon.
> >
> > https://buildd.debian.org/status/package.php?p=firefox-esr&suite=sid
>
> ESR 91 was first uploaded to sid in November. It didn't migrated to
> Testing, or Stable, due to problems. Package tracker show some details:
> https://tracker.debian.org/pkg/firefox-esr
>
> There is a bug here:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001234
>
> Rust compiler for Stable is not available? It means we have to continue
> to use outdated, vulnerable Firefox ESR until this is resolved? When it
> will be?

Think it's more complicated than just a compiler [1]

Thanks for bringing this to our attention. I've just installed ESR 91
direct from Firefox, as it seems Debian are likely to leave us with an
insecure browser for a long time. Considering this was known about
before the last release, you would have thought we would have been
warned about it in the release notes, or through some other means.

The only mention of Firefox in the release notes is...

For general web browser use we recommend Firefox or Chromium.
They will be kept up-to-date by rebuilding the current ESR
releases for stable.

:-(

[1] https://www.google.com/url?q=http://techrights.org/2021/11/10/firefox-esr-91-issues/&sa=D&source=hangouts&ust=1639153687425000&usg=AOvVaw2wBZnDhgCrL9Id5BzyH5hE

--
Tixy

[Roberto C. Sánchez]

Work on this is nearing completion.

Please note that Mozilla is constantly updating to newer rustc and LLVM
versions. That means that preparing a new major ESR release for Debian
requires not just the packaging of the firefox-esr and thunderbird
updates, but also some very complex toolchain components. Those
components are usually already in unstable/testing, but for stable,
oldstable, and LTS, the toolchain must be backported first.

Regards,

-Roberto

--
Roberto C. Sánchez

[Kenneth Parker]

On Thu, Dec 9, 2021, 11:37 AM Tixy <ti...@yxit.co.uk> wrote:

On Thu, 2021-12-09 at 14:18 +0000, piorunz wrote:
> On 09/12/2021 12:47, Georgi Naplatanov wrote:
>
> > Hey Piotr,
> >
> > a new release of Firefox ESR was uploaded to Sid two days ago and
> > probably will be uploaded to stable soon.
> >
> > https://buildd.debian.org/status/package.php?p=firefox-esr&suite=sid
>
> ESR 91 was first uploaded to sid in November. It didn't migrated to
> Testing, or Stable, due to problems. Package tracker show some details:
> https://tracker.debian.org/pkg/firefox-esr
>
> There is a bug here:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001234
>
> Rust compiler for Stable is not available? It means we have to continue
> to use outdated, vulnerable Firefox ESR until this is resolved? When it
> will be?

Think it's more complicated than just a compiler [1]

Thanks for bringing this to our attention. I've just installed ESR 91
direct from Firefox, as it seems Debian are likely to leave us with an
insecure browser for a long time. Considering this was known about
before the last release, you would have thought we would have been
warned about it in the release notes, or through some other means.

Thanks, Tixy.  I will, also, install Firefox 91 directly from Firefox [into my Bookworm test environments]. 

The only mention of Firefox in the release notes is...

    For general web browser use we recommend Firefox or Chromium.
    They will be kept up-to-date by rebuilding the current ESR
    releases for stable.

:-(

[1] https://www.google.com/url?q=http://techrights.org/2021/11/10/firefox-esr-91-issues/&sa=D&source=hangouts&ust=1639153687425000&usg=AOvVaw2wBZnDhgCrL9Id5BzyH5hE

--
Tixy

Kenneth Parker 

[Georgi Naplatanov]

As far as I know Ubuntu has no such problem with Firefox.

Kind regards
Georgi

[piorunz]

On 09/12/2021 17:15, Michael Castellon wrote:
> wget -O firefox.tar
> "https://download.mozilla.org/?product=firefox-latest&os=linux64
> <https://download.mozilla.org/?product=firefox-latest&os=linux64>"

Thanks!

Can you generate the same, but for Firefox-ESR?

[piorunz]

On 09/12/2021 17:18, Roberto C. Sánchez wrote:
> On Thu, Dec 09, 2021 at 05:11:05PM +0000, piorunz wrote:
>> https://www.phoronix.com/scan.php?page=news_item&px=Web-Browser-Packages-Debian
>>
>> :(
>>
> What utter trash.
>
What is trash?

[Michael Castellon]

wget -O firefox.tar "https://download.mozilla.org/?product=firefox-latest&os=linux64"

tar xf firefox.tar
./firefox/firefox

·info·

https://ftp.mozilla.org/pub/firefox/releases/latest/README.txt

·dependency·

apt install libdbus-glib-1-2

Regards

[Roberto C. Sánchez]

On Thu, Dec 09, 2021 at 05:11:05PM +0000, piorunz wrote:
> https://www.phoronix.com/scan.php?page=news_item&px=Web-Browser-Packages-Debian
>
> :(
>
What utter trash.

--
Roberto C. Sánchez

[Roberto C. Sánchez]

Debian also supports additional hardware architectures and the toolchain
components sometimes require specific work in order to support those
additional architectures. In fact, that was the case with this current
update that is underway.

However, the point is not about arguing which is better, Debian or
Ubuntu. Naturally, Debian is better.

Rather, the point was simply to offer assurance that this work is
underway and that it is near completion.

It is lamentable that it has taken this long, but that is not an
indication of a lack of effort on the part of the people in Debian
working on this.

[piorunz]

https://www.phoronix.com/scan.php?page=news_item&px=Web-Browser-Packages-Debian

:(

[Georgi Naplatanov]

Hi Roberto


thanks for the explanation. I didn't want to offend anybody. I use both
- Debian and Kubuntu and like more Debian and I have been using it for
almost 2 decades. The idea was that somehow Ubuntu handles well with
this problem. This is all I meant.

Kind regards
Georgi

[piorunz]

Got it!!

wget -O firefox.tar.bz2
"https://download.mozilla.org/?product=firefox-esr-latest&os=linux64&lang=en-GB"

tar vxf firefox.tar.bz2

firefox/firefox

You can add switch -P after firefox, it allows you to create new
profile, in case you even want to go back to older ESR. Once updated by
ESR91, it is likely your Fx profile won't work with ESR78 any more. I
recommend backing up .mozilla folder before proceeding.

Sad thing is, /$HOME/firefox/firefox doesn't work with firejail profile
anymore. So I have either vulnerable ESR78 with firejail, or new vanilla
ESR91 without firejail. 😭

[Roberto C. Sánchez]

No offense was taken.

I think what is important is to understand is that a statement like "As
far as I know Ubuntu has no such problem with Firefox" implies an
inappopriate value judgment. That is to say, the circumstances that
have led to Ubuntu being in a "better" position (by your estimation) are
necessarily different than those which have led to Debian being in a
"worse" position.

I was simply trying to shed light on the differences in circumstances,
because they are important and because I think it is unkind to devalue
the work of those in Debian just because we happen to strive to a
different set of criteria than perhaps what Ubuntu strives for. The
discussion, both in this thread and in the Phoronix "article" and its
associated discussion seem to be overly negative without good cause.
I'm glad that the other sub-threads in this discussion seem to be
focusing on alternative solutions that allow users to achieve their
objectives until the firefox packaging situation in Debian improves.

[Nicholas Geovanis]

On Thu, Dec 9, 2021, 7:01 AM Christian Britz <cbr...@t-online.de> wrote:

Security is the reason why I download and install browser and mail
client directly from the vendor, not Debian repositories.

And you may have heard yesterday a young woman on a separate thread advised NOT to do that. With an audio package IIRC. On general Debian administration and package management grounds.. No one corrected that statement later.

[Dan Ritter]

Nicholas Geovanis wrote:
> On Thu, Dec 9, 2021, 7:01 AM Christian Britz <cbr...@t-online.de> wrote:
>
> > Security is the reason why I download and install browser and mail
> > client directly from the vendor, not Debian repositories.
> >
>
> And you may have heard yesterday a young woman on a separate thread advised
> NOT to do that. With an audio package IIRC. On general Debian
> administration and package management grounds.. No one corrected that
> statement later.

Here's the main thing that people like to forget: When you run a Debian
system, you are in charge of it.

You can do anything you like to it. You get to live with the
consequences.

If you ask for help here, people will recommend that you do
things in a way which minimizes the likelihood that you will
break more things. You don't have to take that advice. But if
you want more useful help here, you should.

It is absolutely okay to create a FrankenDebian with repos from
testing, unstable, Ubuntu Jovial Jackrabbit and a cronjob that
looks for changes to a webpage somewhere in oracle.com and
automatically downloads and installs a new Java Runtime on
alternate Thursdays, then recompiles the kernel with a
bleeding-edge GLIBC-alternative.

But if you want help with that, you should expect to pay someone
for the privilege of dealing with it.

-dsr-

[Georgi Naplatanov]

Hey Roberto,

here is no devalue by my side. It was "go see how Ubunto does the stuff
and backport to Debian if it's appropriate". It was the idea.


Kind regards
Georgi

[Greg Wooledge]

On Thu, Dec 09, 2021 at 01:27:56PM -0500, Dan Ritter wrote:
> It is absolutely okay to create a FrankenDebian with repos from
> testing, unstable, Ubuntu Jovial Jackrabbit and a cronjob that
> looks for changes to a webpage somewhere in oracle.com and
> automatically downloads and installs a new Java Runtime on
> alternate Thursdays, then recompiles the kernel with a
> bleeding-edge GLIBC-alternative.
>
> But if you want help with that, you should expect to pay someone
> for the privilege of dealing with it.

I wouldn't say it's "okay" to do that. It's possible to do that. But
it's very far from O.K.

[Andrew M.A. Cater]

On Thu, Dec 09, 2021 at 05:11:05PM +0000, piorunz wrote:

Yes: not great but also not informed. We do package the latest versions as
we can - the latest dependency on Rust is a problem and the point about
needing to build toolchains is very valid.

Too many comments there are just Debian-bashing with no real understanding.

The one thing that would be good would be a backport of the mesa-utils to
Bullseye as that would also solve problems with Debian and GUI apps under
WSL2 and Windows :)

All the very best, as ever,

Andy Cater

[Michael Castellon]

all versions:
https://ftp.mozilla.org/pub/firefox/releases/

version esr:

wget -O firefox-esr.tar "https://download.mozilla.org/?product=firefox-esr-latest&os=linux64"

remember, delete cookies, etc:

rm -r ~/.mozilla

Regards.

[Tixy]

On Thu, 2021-12-09 at 16:28 -0500, Michael Castellon wrote:
> all versions:
> https://ftp.mozilla.org/pub/firefox/releases/
>
> version esr:
> wget -O firefox-esr.tar "
> https://download.mozilla.org/?product=firefox-esr-latest&os=linux64"
>
> remember, delete cookies, etc:
> rm -r ~/.mozilla

That will delete your profile too, so all your settings, plugins and
bookmarks will be gone!

I just made a backup of ~/.mozilla (just in case) and let the latest
ESR use what was there. Well, it actually created a new profile so I
changed the default to old one and deleted the new one it created.
(Using the URL "about:profiles")

--
Tixy

[Jonathan Dowland]

On Thu, Dec 09, 2021 at 08:44:12PM +0000, Andrew M.A. Cater wrote:
>The one thing that would be good would be a backport of the mesa-utils to
>Bullseye as that would also solve problems with Debian and GUI apps under
>WSL2 and Windows :)

I've seen that proposed a few times: backport Mesa to get EGL support to
solve this problem. Is it definitely the case that there is no hardware
for which GLX is supported and EGL is not?

--
Please do not CC me for listmail.

👱🏻 Jonathan Dowland
✎ jm...@debian.org
🔗 https://jmtd.net

[piorunz]

On 09/12/2021 22:06, Jonathan Dowland wrote:
> On Thu, Dec 09, 2021 at 08:44:12PM +0000, Andrew M.A. Cater wrote:
>> The one thing that would be good would be a backport of the mesa-utils to
>> Bullseye as that would also solve problems with Debian and GUI apps under
>> WSL2 and Windows :)
>
> I've seen that proposed a few times: backport Mesa to get EGL support to
> solve this problem. Is it definitely the case that there is no hardware
> for which GLX is supported and EGL is not?
>

Could firefox-esr and mesa be updated in backports? If that makes is any
easier? So main repository is not messed that much with?

[Andrew M.A. Cater]

It will be updated soon - there are problems getting some components to
build but as soon as that's done, it'll move from unstable -> stable, I
think.

Andy C.

[Marco Möller]

It's a pity that Debian cannot be flexible to offer more secure and
already available binary versions of software for the assumed many users
only caring for installing a binary from the official Debian repository
on some very typical PC hardware, and marking the rest of the job, like
providing all the toolchain for those who want to compile software
themselves, or providing binaries for less frequently used hardware, to
still be on delay.

I mean, GUI web browsers and GUI email clients like Firefox and
Thunderbird are more likely used on Intel or AMD powered PCs and
laptops, than on other architectures, right? This is at least my guess.
In my opinion and in this particular case it would be good to get a vast
of users as quickly as possible into secure waters instead of putting
most of them on risk of grounding in order to treat all possible victims
the same.

I know that a toolchain is needed to get a published source code for
everyone reproducible compiled into an executable binary, and that this
is a very important part of the security to not become fooled. But if
the toolchain is available already for one platform, then the delivery
of the more secure software should not be delayed for that platform
because other platforms are still not ready, at least not for user
clients of so central importance in nowadays desktop and internet usage.

The "Debian-bashing comments with no real understanding" might not
provide correct insights into the complex machinery which the Debian
project is, and I also might not have understood and above commented on
the situation correctly. But these comments for sure point out that all
the excellent work of all the active maintainers seems to occasionally
stumble over a too rigid project policy. I know that the huge Debian
project will (can? should?) not easily change its way of doing things,
but some more flexibility at least for some few selected desktop apps
could improve the Debian project and especially its reputation also as a
desktop operating system.

Well, just my comment on the situation from a desktop user's
perspective. Please, I do not wish to discuss (this would hijack this
thread and create a monster thread on the Debian philosophy). I simply
thought it is the correct moment and place to leave this comment to the
Debian developers, and I want to support the original concern brought up
by this thread that apps like Firefox really need faster publishing of
available updates. I suggest to consider publishing available updates
for a platform as soon as available and not delaying this by obstacles
still being an issue on some other platforms - if I understood the cause
for the delay correctly.

Thanks for developing and maintaining Debian!
Marco

[Roberto C. Sánchez]

On Thu, Dec 09, 2021 at 10:26:33PM +0000, Andrew M.A. Cater wrote:
>
> It will be updated soon - there are problems getting some components to
> build but as soon as that's done, it'll move from unstable -> stable, I
> think.
>

Sort of. There will be builds prepared specifically for stable,
oldstable, and LTS. Each will be uploaded to the -security archive for
the respective distribution.

[Michael Castellon]

easier than this?

$su
#cd /opt
#wget -O firefox.tar "https://download.mozilla.org/?product=firefox-esr-latest&os=linux64"
#tar xf firefox.tar
#ln -s /opt/firefox/firefox /usr/bin/
#exit
$firefox

*info*
https://ftp.mozilla.org/pub/firefox/releases/latest-esr/README.txt

Firefox is a web browser developed by Mozilla.

Regards

[Nicholas Geovanis]

Am I allowed to top-post myself :-)

If we want to make comparisons, why not talk about the BSD flavors? Or Slackware?

Those are more apples-to-apples comparison.

On Thu, Dec 9, 2021, 5:03 PM Nicholas Geovanis <nickge...@gmail.com> wrote:

And there's an even better example than the one I mentioned. But none of them are negatives on Debian or its maintainers. Who could have predicted the constant churn in linux GUI and graphics and X-Windows since, say, 1996 when I first started-up twm on a German distro's real MIT X-Windows at home. Just like on high end Unix workstations in office and lab.

That churn is all across Linux, not Debian.

Debian tries to cover every base there. And it simply isn't humanly possible. But the maintainers march forward, covering as much ground as they can.

[Nicholas Geovanis]

On Thu, Dec 9, 2021, 2:44 PM Andrew M.A. Cater <amac...@einval.com> wrote:

And there's an even better example than the one I mentioned. But none of them are negatives on Debian or its maintainers. Who could have predicted the constant churn in linux GUI and graphics and X-Windows since, say, 1996 when I first started-up twm on a German distro's real MIT X-Windows at home. Just like on high end Unix workstations in office and lab.

That churn is all across Linux, not Debian.

Debian tries to cover every base there. And it simply isn't humanly possible. But the maintainers march forward, covering as much ground as they can.

[Nate Bargmann]

* On 2021 09 Dec 15:29 -0600, Michael Castellon wrote:
> all versions:
> https://ftp.mozilla.org/pub/firefox/releases/
>
> version esr:
> wget -O firefox-esr.tar "
> https://download.mozilla.org/?product=firefox-esr-latest&os=linux64"
>
> remember, delete cookies, etc:
> rm -r ~/.mozilla

I agree with Tixy, this dumps too much. Of course, a profile and other
stuff can be recovered via Firefox sync to an extent but not certain
customizations such as setting zoom to text only.

I suppose the other question is why? Over the years I've gone back and
forth between Mozilla provided binaries and Debian installed packages
and have never deleted nor modified ~/.mozilla

Perhaps you intended to remove the cache which is found under
~/.cache/mozilla? FF will rebuild it automatically when it is missing.

- Nate

--
"The optimist proclaims that we live in the best of all
possible worlds. The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819

[Christian Britz]

On 2021-12-09 19:09 UTC+0100, Nicholas Geovanis wrote:
> On Thu, Dec 9, 2021, 7:01 AM Christian Britz <cbr...@t-online.de
> <mailto:cbr...@t-online.de>> wrote:
>
> Security is the reason why I download and install browser and mail
> client directly from the vendor, not Debian repositories.
>
>
> And you may have heard yesterday a young woman on a separate thread
> advised NOT to do that. With an audio package IIRC. On general Debian
> administration and package management grounds.. No one corrected that
> statement later.

I read it and I don't care about that questionable absolute statement. I
am using Debian about 20 years now and of course it runs well together
with external software, if you know what you are doing.

I dfinitely won't put my system on risk by using outdated browser and
mail client packages full of security holes.

Best Regards,
Christian

[Christian Britz]

On 2021-12-09 19:27 UTC+0100, Dan Ritter wrote:

> It is absolutely okay to create a FrankenDebian with repos from
> testing, unstable, Ubuntu Jovial Jackrabbit and a cronjob that
> looks for changes to a webpage somewhere in oracle.com and
> automatically downloads and installs a new Java Runtime on
> alternate Thursdays, then recompiles the kernel with a
> bleeding-edge GLIBC-alternative.

You really want to compare that to untarring a mail client to /opt and
linking the executable to /usr/local/bin ? (OK, as a bonus you might
create a .desktop file in /usr/share/applications).

You prefer to live with
https://security-tracker.debian.org/tracker/source-package/thunderbird ?

Regards,
Christian

[Eric S Fraga]

On Thursday, 9 Dec 2021 at 20:44, Andrew M.A. Cater wrote:
> Too many comments there are just Debian-bashing with no real understanding.

Indeed, and with absolutely no appreciation for the effort put in by all
of you Debian folk. Especially in having "stable" *mean* stable!

Thank you all.

--
Eric S Fraga with org 9.5.1 in Emacs 29.0.50 on Debian 11.0

[Andrei POPESCU]

On Jo, 09 dec 21, 23:24:11, Marco Möller wrote:
>
> It's a pity that Debian cannot be flexible to offer more secure and already
> available binary versions of software for the assumed many users only caring
> for installing a binary from the official Debian repository on some very
> typical PC hardware, and marking the rest of the job, like providing all the
> toolchain for those who want to compile software themselves, or providing
> binaries for less frequently used hardware, to still be on delay.
>
> I mean, GUI web browsers and GUI email clients like Firefox and Thunderbird
> are more likely used on Intel or AMD powered PCs and laptops, than on other
> architectures, right? This is at least my guess. In my opinion and in this
> particular case it would be good to get a vast of users as quickly as
> possible into secure waters instead of putting most of them on risk of
> grounding in order to treat all possible victims the same.

$ apt list firefox-esr
firefox-esr/oldstable,now 78.15.0esr-1~deb10u1 arm64 [installed]

One of Debian's strengths is treating all release architectures as first
class citizens. Without that the Project might as well just drop
"problematic" architectures.

ARM64 is likely to see *more* (not less) use in desktops and laptops,
and RISC V might also be an option in the future.

The additional competition is healthy also for x86 (even if less so for
Intel's and AMD's bottom line).

Kind regards,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser

[Christian Britz]

On 2021-12-10 10:25 UTC+0100, Eric S Fraga wrote:
> Indeed, and with absolutely no appreciation for the effort put in by all
> of you Debian folk. Especially in having "stable" *mean* stable!

I love Debian and I appreciate the work of the developers, but I don't
like stability in the sense of leaving security holes unfixed constantly.

There surely must be a better solution or Debian should put packages
like Chromium, Firefox and Thunderbird on the list of packages without
security support.

[Andrei POPESCU]

On Vi, 10 dec 21, 07:46:34, Christian Britz wrote:
> On 2021-12-09 19:09 UTC+0100, Nicholas Geovanis wrote:
> > On Thu, Dec 9, 2021, 7:01 AM Christian Britz <cbr...@t-online.de
> > <mailto:cbr...@t-online.de>> wrote:
> >
> > Security is the reason why I download and install browser and mail
> > client directly from the vendor, not Debian repositories.
> >
> >
> > And you may have heard yesterday a young woman on a separate thread
> > advised NOT to do that. With an audio package IIRC. On general Debian
> > administration and package management grounds.. No one corrected that
> > statement later.
>
> I read it and I don't care about that questionable absolute statement. I
> am using Debian about 20 years now and of course it runs well together
> with external software, if you know what you are doing.

In my opinion this is the important part ("know what you are doing").

As far as I'm concerned, I'll try to help posters deal with whatever
FrankenDebian they created as long as they are putting real effort in
helping themselves first, describing the problem accurately, etc.

Of course, in practice this means most will have solved their own
problems without needing any assistance from the list ;)

[Anssi Saari]

piorunz <pio...@gmx.com> writes:

> https://www.phoronix.com/scan.php?page=news_item&px=Web-Browser-Packages-Debian

They mention the Thunderbird situation as well. Looks like the
Thunderbird Debian package has 22 open security issue and is version
78.14 in stable.

As I've found an AppImage of Librewolf as a reasonable solution to the
browser problem on my Bullseye desktop, I'm left wondering what to do
about Thunderbird? Other than downloading the tarball? Or are these 22
issues too minor to matter? I don't really want to go through all of
them myself.

[Jonathan Dowland]

On Thu, Dec 09, 2021 at 05:51:49PM -0500, Michael Castellon wrote:
>easier than this?

You're comparing apples and oranges, here, because your solution (which
is perfectly fine, by the way, for those who are happy with it: I do
something very similar for myself) doesn't compile Firefox from source
and is specific to amd64, Debian needs to do something that works for
all 9 architectures we support. We also apply 22 patches (currently) to
the source tree, every patch needs to be individually checked and
possibly removed or rebased for on every version update. And a
substantial chunk of the work is in getting the (new) build dependencies
sorted out.

[Roberto C. Sánchez]

On Fri, Dec 10, 2021 at 11:03:50AM +0100, Christian Britz wrote:
>
>
> On 2021-12-10 10:25 UTC+0100, Eric S Fraga wrote:
> > Indeed, and with absolutely no appreciation for the effort put in by all
> > of you Debian folk. Especially in having "stable" *mean* stable!
>

Indeed! For those who would rather have "lastest" instead of "stable",
there are many available solutions, both within and without Debian.

> I love Debian and I appreciate the work of the developers, but I don't
> like stability in the sense of leaving security holes unfixed constantly.
>

Please note that, as Jonathan pointed out in another message, the
firefox-esr/thunderbird packages specifically have a great deal of
complexity associated with them. On the whole, security vulnerabilities
in Debian are fixed quite quickly and usually by a group of people made
up mostly of volunteers.

> There surely must be a better solution or Debian should put packages
> like Chromium, Firefox and Thunderbird on the list of packages without
> security support.
>

That was the case in the past. In particular, when Mozilla was much
more hostile to downstream distributions concerning things like security
support, branding, and building "modified" packages (e.g., carrying
distribution-specific packages). The problem with that, of course, is
that Debian buster, the current oldstable distrubtion (still in fairly
active use), was initially released in July 2019. Firefox ESR 68 was
also released that same month, meaning that the initial buster release
would have contained at best Firefox 60 ESR (initially released May
2018).

If the security team was not making an effort to update to the lastest
ESR release, anyone using buster would have to choose between Firefox 60
ESR from the official repository, a current ESR from an external
provider, or a manual download (as has been discussed in this thread).
None of those seem to be good options.

I remember the "good old days" when the security team didn't support FF
in stable/oldstable. I remember having no choice but to install from
upstream binary tarballs. I'd rather not go back to that being the only
choice.

Rather, the fact the security is making the effort says a great deal
about Debian and those who are so committed to it that rather than just
look at this situation (the difficulty of integrating new FF ESR into
Debian stable/oldstable) and "nope", they dedicate themselves to solving
the problems so that Debian users can benefit from a properly supported
web browser.

All the hate in this thread is really very tiresome. I'm not directing
this specifically to you, Christian, rather speaking of the general tone
of this thread. Discussing alternatives for users who are concerned
about still being on FF 78 ESR and who would like options for running
the latest ESR is fine. But bashing on the people who have been working
literally for months on sorting out all of the issues (and there are
many) to bring the latest FF ESR into Debian stable/oldstable is not
productive. Nor is it productive to point at Debian and other distros
and say things like "they do it, how come Debian can't?" Each distro
has slightly different objectives, operating frameworks, etc. Debian's
goals are different from Ubuntu's goals, are different from Fedora's
goals, are different from Mozilla upstream's goals. Let's just accept
that (or work constructively to adjust the goals to better suit you) and
support the people doing the work.

[piorunz]

My new manual - put together thanks to you guys here on this mailing
list. Thanks to all of you 😍. Now I run newest Thunderbird, and newest
Firefox ESR, both with firejail just like before. I will wait for Debian
versions to appear, I keep them installed, but I won't hold my breath.
My TB & Fx are safe now, without dozens of security vulnerabilities open.

-----
How to download & maintain new Firefox ESR & Thunderbird (from Mozilla):

Shutdown both TB & Fx. Backup their profiles now:
cp -r .mozilla .mozilla-debian
cp -r .thunderbird .thunderbird-debian

cd /usr/bin
sudo mv thunderbird thunderbird.bak
sudo mv firefox firefox.bak

From now, Debian ESR versions are unavailable. You can restore them by
moving /usr/bin/firefox.bak to /usr/bin/firefox (and same with
thunderbird) and restoring their old profiles, as older version won't
read profile modified by newer version.

Run instructions below each time there is new upstream version of
Firefox or Thunderbird:
/cd opt
sudo wget -O firefox.tar.bz2
"https://download.mozilla.org/?product=firefox-esr-latest&os=linux64&lang=en-GB"
sudo tar vxf firefox.tar.bz2
sudo rm firefox.tar.bz2
sudo ln -fs /opt/firefox/firefox /usr/bin/

sudo wget -O thunderbird.tar.bz2
"https://download.mozilla.org/?product=thunderbird-latest&os=linux64&lang=en-GB"
sudo tar vxf thunderbird.tar.bz2
sudo rm thunderbird.tar.bz2
sudo ln -fs /opt/thunderbird/thunderbird /usr/bin/

On first thunderbird launch, run it via "thunderbird -P" instead of
clicking your usual shortcut, because it creates empty profile by
default, you don't need that, you want your old profile selected as
default and loaded each time.

[Michael Castellon]

👊

[Tixy]

On Fri, 2021-12-10 at 13:48 +0000, piorunz wrote:
[...]

> Run instructions below each time there is new upstream version of
> Firefox or Thunderbird:
> /cd opt
> sudo wget -O firefox.tar.bz2
> "https://download.mozilla.org/?product=firefox-esr-latest&os=linux64&lang=en-GB"
> sudo tar vxf firefox.tar.bz2
> sudo rm firefox.tar.bz2
> sudo ln -fs /opt/firefox/firefox /usr/bin/

Will Firefox be able to update itself with security updates?
One HowTo on the web I saw said to change permissions of files
extracted from the tarball to allow this, (using chmod 755). Though to
me, it seems that wouldn't help without changing the owner too, which
I've done (to my user). Will see how things go on the next ESR release.

--
Tixy

[piorunz]

On 10/12/2021 15:27, Tixy wrote:

> Will Firefox be able to update itself with security updates?
> One HowTo on the web I saw said to change permissions of files
> extracted from the tarball to allow this, (using chmod 755). Though to
> me, it seems that wouldn't help without changing the owner too, which
> I've done (to my user). Will see how things go on the next ESR release.

For me it won't work, as I put these files as root deliberately, and I
run firefox executable in firejail. Firefox cannot modify anything apart
from it's own .mozilla folder and Downloads folder. I am happy to
redownload manually when there is an update from Mozilla.

[Tixy]

On Fri, 2021-12-10 at 15:45 +0000, piorunz wrote:
> On 10/12/2021 15:27, Tixy wrote:
>
> > Will Firefox be able to update itself with security updates?
> > One HowTo on the web I saw said to change permissions of files
> > extracted from the tarball to allow this, (using chmod 755). Though to
> > me, it seems that wouldn't help without changing the owner too, which
> > I've done (to my user). Will see how things go on the next ESR release.
>
> For me it won't work, as I put these files as root deliberately, and I
> run firefox executable in firejail. Firefox cannot modify anything apart
> from it's own .mozilla folder and Downloads folder. I am happy to
> redownload manually when there is an update from Mozilla.

And I guess Firefox will let you know there's a new version, time will
tell. I mainly wanted to mention this issue in case other people follow
your recipe and don't consider updates. Now they'll know from our
discussion :-)

--
Tixy

[Rainer Dorsch]

Am Freitag, 10. Dezember 2021, 13:25:17 CET schrieb Roberto C. Sánchez:
> [...]

> All the hate in this thread is really very tiresome. I'm not directing
> this specifically to you, Christian, rather speaking of the general tone
> of this thread. Discussing alternatives for users who are concerned
> about still being on FF 78 ESR and who would like options for running
> the latest ESR is fine. But bashing on the people who have been working
> literally for months on sorting out all of the issues (and there are
> many) to bring the latest FF ESR into Debian stable/oldstable is not
> productive. Nor is it productive to point at Debian and other distros
> and say things like "they do it, how come Debian can't?" Each distro
> has slightly different objectives, operating frameworks, etc. Debian's
> goals are different from Ubuntu's goals, are different from Fedora's
> goals, are different from Mozilla upstream's goals. Let's just accept
> that (or work constructively to adjust the goals to better suit you) and
> support the people doing the work.

Hi Roberto,

thanks and I agree with all you wrote. But also be aware that not all critics
is bashing and not everybody has the skills and/or time to actively help to
backport the necessary packages. I do not intend to bash anybody, I understand
that Debian is based on volunteer work (which is tremendous), and I hope that
you consider the feedback as constructive.

What I am missing is transparency, but it might be my fault that I just do not
find the right information. What would help me feeling more comfortable with
the situation is

1) a statement which is informing the users through a Debian channel about the
thread before that appears on Linux Blogs/news channels. Even now I have not
seen any comment on this topic. I am subscribed to the what I think are the
relevant Debian channels for Debian users (and some more).

2) an estimate for the ETA. That would it make easier for me to decide if I
can just wait for the update or if I need to work on another solution myself.


Regards
Rainer


--
Rainer Dorsch
http://bokomoko.de/

[Georgi Naplatanov]

I also think that if Debian project cannot handle with particular
security issue on time then Debian users should be informed.

Kind regards
Georgi

[Nicholas Geovanis]

On Fri, Dec 10, 2021, 3:56 AM Andrei POPESCU <andreim...@gmail.com> wrote:

On Jo, 09 dec 21, 23:24:11, Marco Möller wrote:
>
> It's a pity that Debian cannot be flexible to offer more secure and already
> available binary versions of software for the assumed many users only caring
> for installing a binary from the official Debian repository on some very

....

ARM64 is likely to see *more* (not less) use in desktops and laptops,
and RISC V might also be an option in the future.

Maybe I missed something. Why RISC V?

[Anssi Saari]

Nicholas Geovanis <nickge...@gmail.com> writes:

> Maybe I missed something. Why RISC V?

Just having an alternative is attractive to some. Having an open
alternative even more so.

I'd happily run ARM or RISC-V, if those were an alternative for a decent
desktop or laptop computer. Raspberry Pi is scratching and clawing its
way there little by little. As the Pi 4 has exposed a PCIe connection,
it has a viable storage now for a small system. But still slow and weird
form factor. Maybe in Pi 6 or maybe 10? Who knows.

RISC-V is better in the form factor part as there's a standard Mini-ITX
board but the price and performance aren't there yet. Not to mention
software support. I'd want an official Debian release first.

[David Newman]

On Dec 18, 2021, at 12:44, Nicholas Geovanis <nickge...@gmail.com> wrote:



On Fri, Dec 10, 2021, 3:56 AM Andrei POPESCU <andreim...@gmail.com> wrote:

On Jo, 09 dec 21, 23:24:11, Marco Möller wrote:
>
> It's a pity that Debian cannot be flexible to offer more secure and already
> available binary versions of software for the assumed many users only caring
> for installing a binary from the official Debian repository on some very
....

ARM64 is likely to see *more* (not less) use in desktops and laptops,
and RISC V might also be an option in the future.

Maybe I missed something. Why RISC V?

RISC V is open-source hardware, free of encumbrances from commercial licenses and fees. 

dn

[Dan Ritter]

Anssi Saari wrote:
> Nicholas Geovanis <nickge...@gmail.com> writes:
>
> > Maybe I missed something. Why RISC V?
>
> Just having an alternative is attractive to some. Having an open
> alternative even more so.
>
> I'd happily run ARM or RISC-V, if those were an alternative for a decent
> desktop or laptop computer. Raspberry Pi is scratching and clawing its
> way there little by little. As the Pi 4 has exposed a PCIe connection,
> it has a viable storage now for a small system. But still slow and weird
> form factor. Maybe in Pi 6 or maybe 10? Who knows.

Maybe. But Linux support for the Apple M1 CPU (an ARM variant)
is coming along nicely, and it could be a first-class
architecture in a year or two. Performance is not lacking,
though price is not wonderful.

-dsr-

[Andrei POPESCU]

On Sb, 18 dec 21, 14:22:58, David Newman wrote:
> On Dec 18, 2021, at 12:44, Nicholas Geovanis <nickge...@gmail.com> wrote:
> >
> > 
> >>> On Fri, Dec 10, 2021, 3:56 AM Andrei POPESCU <andreim...@gmail.com> wrote:
> >>> On Jo, 09 dec 21, 23:24:11, Marco Möller wrote:
> >>> >
> >>> > It's a pity that Debian cannot be flexible to offer more secure and already
> >>> > available binary versions of software for the assumed many users only caring
> >>> > for installing a binary from the official Debian repository on some very
> >>> ....
> >> ARM64 is likely to see *more* (not less) use in desktops and laptops,
> >> and RISC V might also be an option in the future.
> >
> >
> > Maybe I missed something. Why RISC V?
>
> RISC V is open-source hardware, free of encumbrances from commercial licenses and fees.

As well as free from embargoes, so it might be very interesting for chip
makers in countries affected by such.

It's also quite promising in the performance per watt area and
performance per square mm, even compared to ARM (which is already better
than x86 chips).

[Rainer Dorsch]

Am Samstag, 18. Dezember 2021, 23:24:02 CET schrieb Anssi Saari:
> Nicholas Geovanis <nickge...@gmail.com> writes:
> > Maybe I missed something. Why RISC V?
>
> Just having an alternative is attractive to some. Having an open
> alternative even more so.
>
> I'd happily run ARM or RISC-V, if those were an alternative for a decent
> desktop or laptop computer. Raspberry Pi is scratching and clawing its
> way there little by little. As the Pi 4 has exposed a PCIe connection,
> it has a viable storage now for a small system. But still slow and weird
> form factor. Maybe in Pi 6 or maybe 10? Who knows.
>

I want to order and test a Quartz64:

https://wiki.pine64.org/wiki/Quartz64

It comes with a sata and a pci-e port.

Although I think it is best supported under Manjaro

https://wiki.pine64.org/wiki/Quartz64#Manjaro_ARM

there is a Debian installer

https://wiki.pine64.org/wiki/Quartz64

and

Linux 5.15 brings Quartz64 device tree: https://www.pine64.org/2021/12/15/
december-update-a-year-in-review/ (you need to scroll a bit).


Rough comparison with the Raspberry Pi 4:

https://sbcfinder.com/compare.php?
sbconename=Quartz64%20B&sbconetwoname=Raspberry%20Pi%204

Thanks

[Polyna-Maude Racicot-Summerside]

On 2021-12-19 3:13 a.m., Andrei POPESCU wrote:
> On Sb, 18 dec 21, 14:22:58, David Newman wrote:
>> On Dec 18, 2021, at 12:44, Nicholas Geovanis <nickge...@gmail.com> wrote:
>>>
>>> 
>>>>> On Fri, Dec 10, 2021, 3:56 AM Andrei POPESCU <andreim...@gmail.com> wrote:
>>>>> On Jo, 09 dec 21, 23:24:11, Marco Möller wrote:
>>>>>>
>>>>>> It's a pity that Debian cannot be flexible to offer more secure and already
>>>>>> available binary versions of software for the assumed many users only caring
>>>>>> for installing a binary from the official Debian repository on some very
>>>>> ....
>>>> ARM64 is likely to see *more* (not less) use in desktops and laptops,
>>>> and RISC V might also be an option in the future.
>>>
>>>
>>> Maybe I missed something. Why RISC V?
>>
>> RISC V is open-source hardware, free of encumbrances from commercial licenses and fees.

Would you have some suggestion if I'd like to try out a Risc-V board ?
Would be interested in building a test system on this architectures.
Do you have some links for buying already built board (and possibly that
would include some type of graphic hardware if it's possible). Something
like a Raspberry Pi but with a Risc-V chipset ?
Thanks

>
> As well as free from embargoes, so it might be very interesting for chip
> makers in countries affected by such.
>
> It's also quite promising in the performance per watt area and
> performance per square mm, even compared to ARM (which is already better
> than x86 chips).
>
> Kind regards,
> Andrei
>

--

Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development

[to...@tuxteam.de]

On Sun, Dec 19, 2021 at 01:44:35PM -0500, Polyna-Maude Racicot-Summerside wrote:

[...]

> Would you have some suggestion if I'd like to try out a Risc-V board ?

Feeding your fave search engine with, e.g. single board computer +"Risc-V"
yields some hits. A couple of examples:

https://liliputing.com/2021/05/nezha-is-a-99-single-board-pc-with-a-risc-v-processor.html
https://www.cnx-software.com/2021/04/13/allwinner-d1-linux-risc-v-sbc-processor/
https://marketresearchtelecast.com/tried-risc-v-single-board-computer-rvboards-nezha-with-debian-linux/98055/
https://www.reddit.com/r/RISCV/comments/kwgcx2/beaglev_the_first_affordable_riscv_computer/

Don't expect laptop-like or desktop-like performance yet -- rather
embedded-like performance. Those things haven't got the economy of scale
to justify vast caching architectures and other luxuries. That would
make them unaffordable. But things might change...

Cheers
--
tomás

[Curt]

On 2021-12-18, Anssi Saari <a...@sci.fi> wrote:
> Nicholas Geovanis <nickge...@gmail.com> writes:
>
>> Maybe I missed something. Why RISC V?
>
> Just having an alternative is attractive to some. Having an open
> alternative even more so.
>
> I'd happily run ARM or RISC-V, if those were an alternative for a decent
> desktop or laptop computer. Raspberry Pi is scratching and clawing its
> way there little by little. As the Pi 4 has exposed a PCIe connection,
> it has a viable storage now for a small system. But still slow and weird
> form factor. Maybe in Pi 6 or maybe 10? Who knows.

The 3.14159265359 is still popular.

> RISC-V is better in the form factor part as there's a standard Mini-ITX
> board but the price and performance aren't there yet. Not to mention
> software support. I'd want an official Debian release first.
>
>
>

--

[Jeremy Ardley]

There are a few ARM SBC that are very powerful - better than Pi 4. They
have NVME/PCiE disk interfaces and several USB 3.0 interfaces.

The NanoPi M4V2 is one such, but there are several competitors mostly
using RockChip chipsets.

They run Armbian and usually have integrated gigabit LAN (2.5 Gigabit
with the right drivers) and dual band wifi and bluetooth.

As a workstation they are more than adequate. As a home server they are
more than adequate.

--
Jeremy

[gene heskett]

Armbian on a rock64, an older version of the rockchip. is in fact much faster
than a pi4. If the interfaceing for linuxcnc was there it would be more than
capable of freezing out the pi. Unforch there is zero interest on the part of
armbian for realtime kernels, so you're on your own building one. That could
be done, I've done it for the pi3-4's. But this section of the market seems to
think their future is in multimedia, and has zero interest in machine control.
For going outside the Foundations fence, I am blacklisted on the raspian pi
forum.

As a home cnc machine builder, that attitude is killing the market these
devices could own if they wanted to. So I have one machine run by a pi,
drawing perhaps 25 watts with the lcd monitor. The other 4 are running on old
Dells, drawing 250 watts with monitors. Its the build cost that restricts the
pi's, over $200 to interface to a machine, The Dells are famously lacking in
real i/o, but a usable machine can be built for $65 in interfacing.

The first arm board builder to give us two pcie slots or two net ports. or
even 2 parports WILL OWN this market if the MSRP is under $100 with 2 gigs of
ram. Ideal would be one pci-e, and one net port. SSD's can be put on the pi4's
on either or both, usb-3 ports.

> As a workstation they are more than adequate. As a home server they are
> more than adequate.

Absolutely.

Take care and stay well all.

Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

[Stefan Monnier]

> The first arm board builder to give us two pcie slots or two net
> ports. or even 2 parports WILL OWN this market if the MSRP is under
> $100 with 2 gigs of ram. Ideal would be one pci-e, and one net port.
> SSD's can be put on the pi4's on either or both, usb-3 ports.

Something like the MochaBin, but a bit cheaper?


Stefan

[Nicholas Geovanis]

On Mon, Dec 20, 2021 at 4:00 AM Jeremy Ardley <jer...@ardley.org> wrote:

On 20/12/21 5:52 pm, Curt wrote:
> On 2021-12-18, Anssi Saari <a...@sci.fi> wrote:
>> Nicholas Geovanis <nickge...@gmail.com> writes:
>>
>>> Maybe I missed something. Why RISC V?
>> Just having an alternative is attractive to some. Having an open
>> alternative even more so.
>>
>> I'd happily run ARM or RISC-V, if those were an alternative for a decent
>> desktop or laptop computer. Raspberry Pi is scratching and clawing its
>> way there little by little. As the Pi 4 has exposed a PCIe connection,
>> it has a viable storage now for a small system. But still slow and weird
>> form factor. Maybe in Pi 6 or maybe 10? Who knows.
> The 3.14159265359 is still popular.
>
>> RISC-V is better in the form factor part as there's a standard Mini-ITX
>> board but the price and performance aren't there yet. Not to mention
>> software support. I'd want an official Debian release first.
>>
>>
>>
There are a few ARM SBC that are very powerful - better than Pi 4. They
have NVME/PCiE disk interfaces and several USB 3.0 interfaces.

For myself I've always been an Arduino fan over others. And I worked for British-owned

Premier-Farnell's American property which distributes RPi's here, Newark Element14 :-)

Helped move their datacenter :-) 

Arduino's are mostly ARM-based and models like the Mega are incredibly powerful and cheap.

Full OS's run on more advanced models, or just Arduino's open-source runtime. Program in 

their C++ environment, python, Java.... Hundreds of snap-on sensor boards are available. 

Italian-made models are on-the-shelf at certain retailers that serve the maker-community.

 

I have next to me a prototype synthpad based on an Arduino Uno. 5 years ago up at Michigan Tech

University, I saw a self-guided submarine drone that had both a Pi and Arduino on-board. Exploring

in the university's swimming pool.

[John Hasler]

Stefan writes:
> Something like the MochaBin, but a bit cheaper?

I have an ESPRESSObin board from that outfit up in the shop somewhere.
It never worked right due to a defect in the voltage regulator chain.
The published schematics for it are wrong, and all my attempts to get
support were ignored. I'm not sure I want to deal with that outfit
again.
--
John Hasler
jo...@sugarbit.com
Elmwood, WI USA

[gene heskett]

I, once I switched my attention to the pi, haven't paid that much attention.
Lets just say I got used to the pi's warts. It does have quite a few.
> Stefan
>

[Kushal Kumaran]

On Thu, Dec 09 2021 at 10:12:18 AM, piorunz <pio...@gmx.com> wrote:
> Hello,
>
> I noticed that Debian Stable uses Firefox ESR 78.15.0, which is final
> update of 78 series. All further updates go to Firefox ESR 91, as
> Mozilla page says:
> https://www.mozilla.org/en-US/firefox/78.15.0/releasenotes
>
> "Version 78.15.0, first offered to ESR channel users on October 5, 2021
> This is the final planned ESR78 release. Eligible users will be
> automatically updated to the ESR91 release on November 2."
>
> Since 2 November, Firefox 78 is EOL and we all should upgrade. I use
> Debian Bullseye on several of my computers, and they all are on ESR 78.
>
> Firefox 91 should migrate to Stable as soon as possible, otherwise we
> risk unpatched security vulnerabilities being present in Debian Stable,
> there are several of them already.
> https://security-tracker.debian.org/tracker/source-package/firefox-esr
>
> Is there any remedy for this?
>

As of a day ago, Firefox 91 is now in stable. My thanks to the
maintainers of the firefox debian packages and the build toolchains for
working on this.

--
regards,
kushal

[Andrei POPESCU]

On Lu, 20 dec 21, 09:53:54, to...@tuxteam.de wrote:
> On Sun, Dec 19, 2021 at 01:44:35PM -0500, Polyna-Maude Racicot-Summerside wrote:
>
> [...]
>
> > Would you have some suggestion if I'd like to try out a Risc-V board ?
>
> Feeding your fave search engine with, e.g. single board computer +"Risc-V"
> yields some hits. A couple of examples:
>
> https://liliputing.com/2021/05/nezha-is-a-99-single-board-pc-with-a-risc-v-processor.html
> https://www.cnx-software.com/2021/04/13/allwinner-d1-linux-risc-v-sbc-processor/
> https://marketresearchtelecast.com/tried-risc-v-single-board-computer-rvboards-nezha-with-debian-linux/98055/
> https://www.reddit.com/r/RISCV/comments/kwgcx2/beaglev_the_first_affordable_riscv_computer/

https://www.pine64.org/2021/12/15/december-update-a-year-in-review/

> Don't expect laptop-like or desktop-like performance yet -- rather
> embedded-like performance. Those things haven't got the economy of scale
> to justify vast caching architectures and other luxuries. That would
> make them unaffordable. But things might change...

Agreed. This is something to keep an eye on as a potential future
competitor for ARM, which is starting to challenge x86 in various areas.

[Andrei POPESCU]

On Lu, 20 dec 21, 06:42:47, gene heskett wrote:
>
> The first arm board builder to give us two pcie slots or two net ports. or
> even 2 parports WILL OWN this market if the MSRP is under $100 with 2 gigs of
> ram. Ideal would be one pci-e, and one net port. SSD's can be put on the pi4's
> on either or both, usb-3 ports.

https://pine64.com/product/rockpro64-2gb-single-board-computer/

[gene heskett]

On Saturday, December 25, 2021 6:06:56 AM EST Andrei POPESCU wrote:
> On Lu, 20 dec 21, 06:42:47, gene heskett wrote:
> > The first arm board builder to give us two pcie slots or two net ports. or
> > even 2 parports WILL OWN this market if the MSRP is under $100 with 2 gigs
> > of ram. Ideal would be one pci-e, and one net port. SSD's can be put on
> > the pi4's on either or both, usb-3 ports.
>
> https://pine64.com/product/rockpro64-2gb-single-board-computer/
>

Possibly but out of stock and never will be restocked and they will have a new
one, probably incompatible, by the time I run my underware thru the washing
machine. If I'm going to develop an application, I want the stuff to build
that application available yet 4 or 5 years from now even if I've missed
morning roll call for good. At 87 yo, I don't even buy green bananas.

Generally, I can do that when I design around a pi. They (rockchip) got me for
a pair of rock64's around 4 years ago but offered zero support, no emails
asking boot or realtime linux questions were ever given the courtesy of a
reply.

> Kind regards,
> Andrei
Take care Andrei, and have a merry Christmas.

[piorunz]

On 21/12/2021 01:06, Kushal Kumaran wrote:

> As of a day ago, Firefox 91 is now in stable. My thanks to the
> maintainers of the firefox debian packages and the build toolchains for
> working on this.

I extend my thanks to Debian maintainers also! On both my machines I
have removed Mozilla's ESR binary and all downloaded files, and reverted
back to using Debian's ESR, process was smooth and easy, all my profiles
are working just fine.

Now, I just wait for Thunderbird. I continue to use Thunderbird 91.4.0
from Mozilla, Debian TB is still 78.14.0 which is dangerous and should
not be used. I use mine with firejail which strengthens the security
further.
I still advocate for Debian to send a warning in some form to all TB
users, in Release Notes, Errata, or somewhere... TB in Stable is
vulnerable to security bugs and users should know.

[Tixy]

On Sun, 2021-12-26 at 22:17 +0000, piorunz wrote:
> On 21/12/2021 01:06, Kushal Kumaran wrote:
>
> > As of a day ago, Firefox 91 is now in stable. My thanks to the
> > maintainers of the firefox debian packages and the build toolchains for
> > working on this.
>
> I extend my thanks to Debian maintainers also! On both my machines I
> have removed Mozilla's ESR binary and all downloaded files, and reverted
> back to using Debian's ESR, process was smooth and easy, all my profiles
> are working just fine.

I've done the same, however graphics acceleration doesn't work for me,
so to avoid screen tearing when watching video, I have had to start
using a Chrome based browser (Vivaldi). Hopefully the Firefox graphics
situation will be fixed at a point before Google removes the APIs ad
blockers and I can continue to enjoy a tear and ad free browsing
experience.

--
Tixy

[Andrew M.A. Cater]

Hi Tixy,

What's the machine / graphics chipset. Other people are experiencing lockups
occasionally.

All the very best, as ever,

Andrew Cater

> --
> Tixy
>

[Tixy]

CPU is Intel i7-9700 and graphics is what's built into that. I'm
running X server not Weyland.

Old ESR Firefox would do acceleration if I went to about:config and set
layers.acceleration.force-enabled = true
That doesn't work on the new ESR Firefox (or the Mozilla binary for
same version).

Vivaldi and Google Chrome happily do tearfree video rendering out of
the box (when running fullscreen). As do media players like VLC.

Kernel messages for graphics driver...

# journalctl | grep i915
Dec 27 07:50:52 computer7 kernel: i915 0000:00:02.0: [drm] VT-d active for gfx access
Dec 27 07:50:52 computer7 kernel: i915 0000:00:02.0: vgaarb: deactivate vga console
Dec 27 07:50:52 computer7 kernel: i915 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem
Dec 27 07:50:52 computer7 kernel: mei_hdcp 0000:00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: bound 0000:00:02.0 (ops i915_hdcp_component_ops [i915])
Dec 27 07:50:52 computer7 kernel: i915 0000:00:02.0: firmware: direct-loading firmware i915/kbl_dmc_ver1_04.bin
Dec 27 07:50:52 computer7 kernel: i915 0000:00:02.0: [drm] Finished loading DMC firmware i915/kbl_dmc_ver1_04.bin (v1.4)
Dec 27 07:50:52 computer7 kernel: i915 0000:00:02.0: [drm] failed to retrieve link info, disabling eDP
Dec 27 07:50:52 computer7 kernel: [drm] Initialized i915 1.6.0 20200917 for 0000:00:02.0 on minor 0
Dec 27 07:50:52 computer7 kernel: snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
Dec 27 07:50:52 computer7 kernel: fbcon: i915drmfb (fb0) is primary device
Dec 27 07:50:53 computer7 kernel: i915 0000:00:02.0: [drm] fb0: i915drmfb frame buffer device

--
Tixy