El 7/12/24 a las 12:31, Bjørn Mork escribió:
But shouldn't those clang packages alsoe be avaiable from
bookworm-security then?
Yes, they should.
Don't worry, this is known and I'm sure that Andres and the security team
are already working on it:
https://bugs.debian.org/cgi-bi
b http://security.debian.org/debian-security bookworm-security main contrib
non-free non-free-firmware
deb http://deb.debian.org/debian/ sid non-free-firmware
The switch seems intentional, looking at the salsa commit log:
commit 1e8c9f1decd28b51c2957463326618e458b911fb (tag:
debian/131.0.6778.10
ed).
> >
> > This sounds like the solution proposal A2, quoting it:
> > > ## A2) Add a new mutually exclusive state to the set:
> > "not-affected-build-artifacts"
> >
> > Would this be aligned to what you're looking for?
>
> Could you check if
Hello Salvatore,
On Sat, 2 Nov 2024 at 20:02, Samuel Henrique wrote:
> On Tue, 29 Oct 2024 at 19:43, Salvatore Bonaccorso wrote:
> > As mentioned in an earlier message: What I would love to see is to
> > actually have a substate which makes the situation clear, and still
> > beeing technically c
packages) in an incomplete
> manner
> and leaves too much room for confusion.
Right, so as a part of this change, we need to make sure we always allow older
releases to still be marked as affected or any other status.
I assume all the code that needs to be updated for this lives under the
se
mplete solution is needed for this use
> case, we could change the parsing logic to allow this to happen as well.
>
> > In general though, I think this is sensible.
>
> Thank you Emilio,
>
> 2 months have passed since my last email, so I would like to ping the security
>
s have passed since my last email, so I would like to ping the security
team for feedback on this.
To confirm the expectations from this change, I've recently scanned a debian
minimal image for CVEs and found out:
18 out of 67 affected packages/CVE are false positives due to this issue, thi
On 31/08/2024 20:07, Samuel Henrique wrote:
Hello everyone,
I've written another revision of my proposal, this is version 3 of it, the
previous ones are on this email thread on debian-security@lists.debian.org.
I did get some feedback from the Security Team privately, it wasn'
Hello everyone,
I've written another revision of my proposal, this is version 3 of it, the
previous ones are on this email thread on debian-security@lists.debian.org.
I did get some feedback from the Security Team privately, it wasn't
anything confidential, it's just that some
Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: debian-security@lists.debian.org, j...@debian.org
salt was removed from oldstable in 11.10 and needs cleaning up from the
security repo please.
Thanks,
Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: debian-security@lists.debian.org, j...@debian.org
snort was removed from oldstable in 11.10 and needs cleaning up from the
security repo please.
Thanks,
Hello everyone,
Just wondering if the Security team could spend some time availiating my
proposal.
Feedback from others is always welcomed too, but in order to go ahead I would
like to understand where the team stands.
Cheers,
--
Samuel Henrique
Alternatively, I mention an option to create a new state to indicate that the
resulting package is not affected due to the build options. I also explain why
that's not my prefered approach.
# Problem statement
The possible outcomes of a CVE assessment in our security-tracker are[0]:
> | |
* [Wed, Apr 03, 2024 at 11:11:20PM +0100] Samuel Henrique:
On the proposed solution I also mention that we can use the "(free text
comment)" section to indicate that, while sticking to "not-affected", this
would simplify things as no new value is needed. But parsing the cases where
only the sourc
On Wed, 3 Apr 2024 at 17:04, Gian Piero Carrubba wrote:
>
> * [Wed, Apr 03, 2024 at 09:21:41AM +0100] Samuel Henrique:
> ># Alternative solutions:
> >If we really want to distinguish the case when we don't produce any affected
> >packages but the source contains the vulnerability (a build with dif
* [Wed, Apr 03, 2024 at 09:21:41AM +0100] Samuel Henrique:
# Alternative solutions:
If we really want to distinguish the case when we don't produce any affected
packages but the source contains the vulnerability (a build with different
flags might result in an affected package), we can create a n
-- Forwarded message --
From: Samuel Henrique <samuel...@debian.org>
Date: On Wed, Apr 3, 2024 at 3:21 AM
Subject: Fw: security-tracker: A proposal to significantly reduce reported
false-positives (no affected-code shipped)
To: <debian-security@lists.debian.org>
he possible outcomes of a CVE assessment in our security-tracker are[0]:
> | | | |
We also have the following severity levels [0]:
> SEVERITY_LEVEL : (unimportant) | (low) | (medium) | (high)
"unimportant" being defined as:
> unimportant: This problem does not affect the
Hi Thomas,
On Fri, Jan 05, 2024 at 12:06:58AM +0100, Thomas Lange wrote:
> Hi all,
>
> we now redirect all DSA/DLA URLs under security and lts/security with
> or without having the year in the path and with or without a version
> to their announcement mail:
> Examples:
&g
Hi all,
we now redirect all DSA/DLA URLs under security and lts/security with
or without having the year in the path and with or without a version
to their announcement mail:
Examples:
/security/dsa-5576
/security/2023/dsa-5576-2
lts/security/2023/dla-3686-1
lts/security/dla-3686
All URLs like
Hello,
On Fri, 21 Jul 2023, Daniel Gröber wrote:
> One mention I found is in Raphaël and Roland's DAH (now in CC):
> https://debian-handbook.info/browse/stable/sect.apt-get.html#sect.apt-upgrade
I also saw your associated bug report. Thanks for highlighting this
issue to me. I updated
https://sa
On Sat, 2023-07-22 at 17:45 +0200, Hannes von Haugwitz wrote:
> What about to add a warning to apt if *-security or *-updates is
> configured in the sources list and `APT::Default-Release` is set but
> does not match the security or updates repo?
That seems like the right solution her
to add a warning to apt if *-security or *-updates is
configured in the sources list and `APT::Default-Release` is set but
does not match the security or updates repo?
Best regards
Hannes
tracked.
Ah, I didn't realise debian-handbook has a package in the archive :)
Done, Bug#1041706: debian-handbook: Wrong advice on APT::Default-Release
preventing security updates.
> > What I don't understand is why the security repo codename wasn't changed to
> > $cod
sily fixed unfortunately. Advice to set this is splattered all
> over the web, I really don't understand why we made a change so seemingly
> ill advised as this?
>
> A web search for "Debian Default-Release security" didn't reveal anything
> talking about this prob
Hi Paul,
On Fri, Jul 21, 2023 at 10:17:28AM +0800, Paul Wise wrote:
> On Thu, 2023-07-20 at 22:12 +0200, Daniel Gröber wrote:
>
> > It seems packages from the debian-security repository are not affected by
> > this increased priority and will not get intalled as a res
On Thu, 2023-07-20 at 22:12 +0200, Daniel Gröber wrote:
> It seems packages from the debian-security repository are not affected by
> this increased priority and will not get intalled as a result.
This was documented in the release notes for Debian bullseye:
https://www.debian.org/re
Hi debian-security,
I've just noticed something rather distressing. As part of my usual Debian
installation I set `APT::Default-Release "stable";` which causes a change
of apt priorities for packages from this release (or so I thought) from the
usual 500 to 990. This is recomme
package: developers-reference
x-debbugs-cc: debian-security@lists.debian.org
hi,
On Tue, Jul 11, 2023 at 10:46:20PM +0200, Moritz Mühlenhoff wrote:
> > I found the Securing Debian Manual
> > (https://www.debian.org/doc/manuals/securing-debian-manual/index.en.html).
> > This ve
Hi Paul,
On Mon, May 29, 2023 at 02:36:22PM +0200, Paul Gevers wrote:
> Dear security team,
>
> I know it's a bit late, but are you aware of issues that are worth
> mentioning in the release notes from your point of view?
>
> We have updated the text about golang
Dear security team,
I know it's a bit late, but are you aware of issues that are worth
mentioning in the release notes from your point of view?
We have updated the text about golang and rustc in this cycle, chromium
got a mention about reduce support time wise and I updated the op
On 2023-05-12 16:27:59 -0700 (-0700), Jeffrey Chimene wrote:
[...]
> So far, this official Debian list is in line with my expectations.
> For every 1 person on a Debian list, there are 10 who will tell
> you it's a waste of time. So far, the best "stop wasting our time"
> line is that Debian is unl
There aren't a lot of active readers on this list.
These days "security" seems to consist of installing and enabling
every item you can find that's labeled "security". A huge amount of
it is pure waste, addressing mythical scenarios that no ordinary user
will ever
On 2023-01-19 14:04:52 + (+), Jeremy Stanley wrote:
[...]
> The only patch my colleagues and I found which needed adjustment
> was 0012, and for that I was able to apply upstream commit 3c50032
> directly instead.
Ubuntu has issued https://ubuntu.com/security/notices/USN-5
On 2023-01-18 23:34:37 + (UTC), Thorsten Glaser wrote:
[...]
> The versions in Debian and *buntu don’t exactly match, but perhaps
> appropriate patches for the respective versions are available, or
> they apply with little fuzz?
[...]
Just a data point around this, I spent a good chunk of yest
Hi Jonathan,
are you planning to fix the open security issues in git?
In addition to the two new ones from… last week I think,
given Ubuntu LTS-security has been carrying the fixes for
8 days now, there’s another four issues in stable that
are fixed in testing/sid (newer versions?) and oldstable
Hi,
You may want to read this thread:
https://lists.debian.org/debian-security/2021/05/msg00010.html
https://lists.debian.org/debian-security/2021/05/msg00012.html
I'd suggest you also explain your context, you seem to use the Debian
tracker to trigger some action on your part, whil
Hello!
My name is Hadas, I'm in the Snyk Security Group. I've been in contact with
you a while back regarding the `no-dsa` field and its different tags.
I just want to further confirm if our understanding of the usage of the
various terms (`no-dsa`, `ignored`, `postponed`, "M
Am 09.04.22 um 23:31 schrieb Moritz Mühlenhoff:
Friedhelm Waitzmann wrote:
For the oldstable distribution (buster), these problems have
been fixed in version 91.8.0esr-1~deb10u1.
Where can I get this from for buster and architecture i386?
<http://security.debian.org/debian-security/di
On 2022-08-26 at 05:02 -0400, Chris Penalver wrote:
> Hi Debian Security Team,
>
> I am inquiring on Debian Bullseye as it relates to:
>
> https://security-tracker.debian.org/tracker/CVE-2019-8457
>
> Specifically, it is noted the team has put in a good faith effor
Hi Debian Security Team,
I am inquiring on Debian Bullseye as it relates to:
https://security-tracker.debian.org/tracker/CVE-2019-8457
Specifically, it is noted the team has put in a good faith effort in
analyzing the feasibility of backporting relevant patches to Bullseye,
and classifying
Hello to Debian's security team.
I'm researching the Debian's security feed
<https://security-tracker.debian.org/tracker> and I have a couple of
questions about the meaning of some of the keys included on the JSON feed.
Below are the keys in question.
- *repositories *k
leased at the same time, but I uploaded linux-latest
> on 30th June and the binaries are certainly available now.
In fact all the packages were pushed out at the same time and the
advisory went out only after dak confirmed they are installed; maybe
there was an issue on syncing up on some securit
On Mon, 2022-07-04 at 22:17 +0200, Kurt Roeckx wrote:
> On Sun, Jul 03, 2022 at 03:49:12PM +, Ben Hutchings wrote:
> >
> > For the oldstable distribution (buster), these problems have been
> > fixed in version 4.19.249-2.
>
> It seems that linux-image-amd64 does not depend on
> linux-image-4.
On Sun, Jul 03, 2022 at 03:49:12PM +, Ben Hutchings wrote:
>
> For the oldstable distribution (buster), these problems have been
> fixed in version 4.19.249-2.
It seems that linux-image-amd64 does not depend on
linux-image-4.19.0-21-amd64 but still on linux-image-4.19.0-20-amd64,
so the fixed
On Wed, Jun 29, 2022 at 1:46 PM Ravi Dwivedi wrote:
> Since the below mentioned analysis of Debian's security, and that too
> compared to other distros, is not very well-known outside of Debian
> project
honestly i don't believe it's even widely known *in* the debian
Since the below mentioned analysis of Debian's security, and that too
compared to other distros, is not very well-known outside of Debian
project(it didn't come up in any internet searches, the web of trust
gets mentioned but there is not much explanation on it), I suggest
writing in
services on the Internet, or fixes
for packages that were initially broken but that wasn't found.
All what you described here is not important for OP who wants to reduce
his attack surface from malicious developer attack scenario.
And I argue, not important for typical security conscious home
ant updates:
bullseye: read-only except during point releases
bullseye-security: receives security updates regularly
bullseye-updates: receives occasional time-sensitive and important
updates, such as updates to the timezone database, which often happen
just days before the timezone changes, or f
ckage?
Debian Stable is not affected by this. All new packages are first coming
to experimental and unstable, then testing, only at the end packages are
landing in stable release. Sometimes many months later.
Exceptions to this are:
1. Security Team updates
2. General point-release updates
3. Backports.
On Mon, May 23, 2022 at 7:59 PM Adam McKenna wrote:
> You are talking about a deterrent though. I think the question is,
> what if someone cares more about their political cause than
> retaining their uploader access?
they get one and only one chance to do something that stupid.
> What if someo
> they get one and only one chance to do something that stupid.
So the answer is that we have no way of preventing a developer from
intentionally sabotaging a package in any / as many ways as they choose and
the only risk to them is losing their uploader access after the fact?
>the response is sw
> anyone stupid enough to abuse their position may only do so once, at
which point their GPG key is revoked.
You are talking about a deterrent though. I think the question is, what if
someone cares more about their political cause than retaining their
uploader access?
What if someone's keys are
On Mon, May 23, 2022 at 6:28 PM Adam McKenna wrote:
>
> > i believe the answer is in the question. debian is based on distributed
> > trust. i did the analysis (took 3 weeks): it is literally the only distro
> > in the world with an inviolate chain of trust from a large keyring dating
> > back
> i believe the answer is in the question. debian is based on distributed
trust. i did the analysis (took 3 weeks): it is literally the only distro
in the world with an inviolate chain of trust from a large keyring dating
back 20 years that is itself GPG-signed as a package, with a package
distrib
Am 19.04.22 um 12:15 schrieb Elmar Stellnberger:
Today I have received response on my g++ bug report at gcc.gnu.org.
Gcc 8.3.0 as used in Debian 10 is no longer supported as the 8 branch
has a newer version which is gcc 8.5. Why do Debian maintainers not
update gcc, if there is a known bug t
Today I have received response on my g++ bug report at gcc.gnu.org.
Gcc 8.3.0 as used in Debian 10 is no longer supported as the 8 branch
has a newer version which is gcc 8.5. Why do Debian maintainers not
update gcc, if there is a known bug that prevents updated sources like
firefox-esr-91.8
> i did the analysis (took 3 weeks)
Do you have a publication of that analysis? I was thinking the same
about the organization of Debian for some time but never did analysis
or compared it to other distros.
Also I like to add that reproducible builds are an excellent addition
to the mechanisms yo
The patch from yesterday could be tested by manually shipping the
executable. Today I have developed another patch (since the first one
did not resolve it), one that compares against the backtrace with Debian
11 which is known to have a working gcc. The assumption that the Firefox
and Qt5/moc
On 17/04/2022 19:26, Satvik Sinha wrote:
> abusing your OS's reputation?
i believe the answer is in the question. debian is based on distributed trust.
i did the analysis (took 3 weeks): it is literally the only distro in the world
with an inviolate chain of trust from a large keyring datin
On Fri, Apr 15, 2022 at 09:07:10AM +0200, Elmar Stellnberger wrote:
> That is not correct. You can make use of SSE instructions also in
> x86_32/i386 mode.
>
> I found f.i.:
> https://gcc.gcc.gnu.narkive.com/k0KqaZF2/i386-sse-test-question
Well x86_64 uses it all the time, not just optionally,
Hi,guys and Good Day! So in recent days ,it was observed that many open
source contributors vandalised their or someone else's project's
reputation to show agendas of Russia-Ukraine war, Some even vandalised
their project to destroy system in Russia and Belarus (Node-ipc being one
of them) that af
Just make sure you comment out the tests. It will greatly speed up
compilation and one of these tests was even hanging two times:
./a.out -test.short -test.timeout=240s
It is a known Debian Bug that the Go tests (a programming language)
fail with with gcc-8. If not you would have to connect
Likely it is possible to comment out the tournament checks after
compilation (which did not succeed to find this error any way) in
debian/rules; I would do it like this:
check:
check22: $(check_stamp)
$(check_stamp): $(build_stamp)
$(MAKE) -f debian/rules2 $@
(here I have renamed chec
I have now downloaded the source package and examined the backtrace
of building Firefox and examined all the differences between gcc 8.3.0-1
(known bad from Debian10) and gcc 9.2.0 with gcc 9.2.1 being known to be
good for moc/Qt5 from Ubuntu 19.10. There was only one difference I
found along
Why not?
On 16.04.22 16:05, Elmar Stellnberger wrote:
>Given that this should not be possible for some reason, please
> share your knowledge about these bugs, so that people like me
> can try to find a fix.
>
> Elmar
On 11.04.22 23:57, Moritz Muehlenhoff wrote:
It is possible; if someone t
235.html
It would be a general question of mine regarding both bugs why
you do not simply up/downgrade to the last known good version.
The i386 target would work well including the required security
updates and it would not be necessary to develop a patch for
these issues.
Given that this sho
On Fri, Apr 15, 2022 at 04:52:55PM +0200, Elmar Stellnberger wrote:
> ...
> exist. It truely is this g++ bug that prevents Firefox and any
> Qt programs from building under Buster/i586. I have noted that
> there are also some amd64 targets on the OBS that expose the
> exact same g++ bug. My questio
On 14.04.22 15:45, Levis Yarema wrote:
Is there in deed any reason to prefer amd64 over i586 if you have the
choice and a machine with 2GB RAM or less, apart from perhaps long term
support?
Depends on the application. Encryption and decryption
requiring the simulation of very larger integers
On 15.04.22 04:50, Lennart Sorensen wrote:
On Thu, Apr 14, 2022 at 03:45:37PM +0200, Levis Yarema wrote:
Is there in deed any reason to prefer amd64 over i586 if you have the
choice and a machine with 2GB RAM or less, apart from perhaps long term
support?
Twice the registers and sse instructio
On Thu, Apr 14, 2022 at 03:45:37PM +0200, Levis Yarema wrote:
> Is there in deed any reason to prefer amd64 over i586 if you have the
> choice and a machine with 2GB RAM or less, apart from perhaps long term
> support?
Twice the registers and sse instructions for fpu rather than x87?
--
Len Sore
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Elmar Stellnberger on Thursday., 2022-04-14T18:51:01+0200:
Where can I get this from for buster and architecture i386?
<http://security.debian.org/debian-security/dists/buster/updates/main/binary-i386/Packages.xz>
does not h
On 14.04.22 14:52, Elmar Stellnberger wrote:
I am also running Debian 10 on my Asus eeePC (Pentium M). I
am mainly using it as a dictionary. Although I am performing
security updates quite regularly I have not run into this
issue. Having updated just now I am with Firefox
78.15.0-esr-1
Is there in deed any reason to prefer amd64 over i586 if you have the
choice and a machine with 2GB RAM or less, apart from perhaps long term
support?
Am Do., 14. Apr. 2022 um 10:38 Uhr schrieb Paul Wise :
> On Tue, 2022-04-12 at 05:59 +0200, Friedhelm Waitzmann wrote:
>
> > And if it is indeed p
to my knowledge can.
There's no reason to believe netburst systems are not affected by any of the
cpu issues identified in the past few years, but they are obsolete and
unsupported so nobody is making official statements about them. These
systems also lack a number of security features present in
ed in version 91.8.0esr-1~deb10u1.
> > >
> > > Where can I get this from for buster and architecture i386?
> > > <http://security.debian.org/debian-security/dists/buster/updates/main/binary-i386/Packages.xz>
> > >
> > > does not have it.
> >
nd architecture i386?
> > <http://security.debian.org/debian-security/dists/buster/updates/main/binary-i386/Packages.xz>
> >
> > does not have it.
>
> The Firefox ESR91 series triggers an internal compiler error
> with the GCC version included in Debian 10, so there&#
ason to believe netburst systems are not affected by any of the
> cpu issues identified in the past few years, but they are obsolete and
> unsupported so nobody is making official statements about them. These
> systems also lack a number of security features present in modern CPUs;
> p
On Thu, Apr 14, 2022 at 11:01:06AM +0200, Maurice Dirr wrote:
> Are you running KDE programs on a Pentium 4?
> How can that work without hardware acceleration?
>
Well QCoan is a plain Qt program, not a KDE app, but Yes I am
running KDE apps on that PIV. You have to use
> export LIBGL_ALWAYS_SO
Are you running KDE programs on a Pentium 4?
How can that work without hardware acceleration?
On 14.04.22 10:52, Elmar Stellnberger wrote:
>Could it be that also other programs are affected by this issue?
> > I have been building Coan (one of my programs) recently on the OBS and it
> > did n
On 14.04.22 10:37, Paul Wise wrote:
On Tue, 2022-04-12 at 05:59 +0200, Friedhelm Waitzmann wrote:
And if it is indeed possible, how can I switch from i386 to
amd64? Can this be done with the apt tools? Then during the
migrating some packages will be from amd64 already while others
will be sti
On Tue, 2022-04-12 at 05:59 +0200, Friedhelm Waitzmann wrote:
> And if it is indeed possible, how can I switch from i386 to
> amd64? Can this be done with the apt tools? Then during the
> migrating some packages will be from amd64 already while others
> will be still i386. How does that go r
; >>
> >> Where can I get this from for buster and architecture i386?
> >> <http://security.debian.org/debian-security/dists/buster/updates/main/binary-i386/Packages.xz>
>
> >> does not have it.
> >
> > The Firefox ESR91 series triggers an i
gt;
<http://security.debian.org/debian-security/dists/buster/updates/main/binary-i386/Packages.xz>
>> does not have it.
>
> The Firefox ESR91 series triggers an internal compiler error
> with the GCC version included in Debian 10, so there's no build
> available currently
What security features do P3/P4/PM systems lack? I only know that the Intel
ME was introduced with early Core 2 systems and that is well known to have
security issues. Today people spend extra money for a system where you can
disable the ME in the UEFI though it is only disabled by a setting then
years, but they are obsolete
and unsupported so nobody is making official statements about them.
These systems also lack a number of security features present in modern
CPUs; picking an ancient chip for "security reasons" is likely
misguided. Also, in the context of this thread, not
On Wed, Apr 13, 2022 at 07:18:53PM +0200, Levis Yarema wrote:
If I would get an x64 CPU from a Linux pro, sure I would take it. Otherwise I
would not recommend to just take any old hardware for exchange with my working
one since not all of it was easily well supported by Linux these days, as far
On 13.04.22 16:44, piorunz wrote:
On 12/04/2022 04:59, Friedhelm Waitzmann wrote:
And if it is indeed possible, how can I switch from i386 to amd64? Can
this be done with the apt tools? Then during the migrating some packages
will be from amd64 already while others will be still i386. How does
On 13.04.22 19:18, Levis Yarema wrote:
If I would get an x64 CPU from a Linux pro, sure I would take it.
Otherwise I would not recommend to just take any old hardware for
exchange with my working one since not all of it was easily well
supported by Linux these days, as far as I can remember.
On 13.04.22 17:11, piorunz wrote:
> On 13/04/2022 15:57, Michael Stone wrote:
>
>> family 15 model 2 is northwood based. no amd64. the best option for that
>> one is to find a cheap second hand box with a CPU that's only 10 years
>> old instead of (literally) 20 years old and retire it; those old p
On Wed, Apr 13, 2022 at 05:32:10PM +0200, Odo Poppinger wrote:
I have a beloved P4 Gericom Frontman and I do not want to give it
away.
and that's fine, but it's increasingly unreasonable to try to run a
modern general purpose OS on hardware that's 20 years old. if the driver
is nostalgia, som
I have a beloved P4 Gericom Frontman and I do not want to give it away.
It had a new game changing design as can today be found with many Apple
computers. I also have a P4 notebook and some i386 desktops, some of
which I am dual booting with some Windows and OS/2. New computers with a
setup fro
On 13/04/2022 15:57, Michael Stone wrote:
family 15 model 2 is northwood based. no amd64. the best option for that
one is to find a cheap second hand box with a CPU that's only 10 years
old instead of (literally) 20 years old and retire it; those old p4's
were really power hungry, and it shouldn
On Wed, Apr 13, 2022 at 03:44:00PM +0100, piorunz wrote:
On 12/04/2022 04:59, Friedhelm Waitzmann wrote:
You mean, that it is possible to run amd64 on my old hardware
1#
vendor_id : GenuineIntel
cpu family : 6
model : 22
model name : Intel(R) Celeron(R) CPU 4
On 12/04/2022 04:59, Friedhelm Waitzmann wrote:
You mean, that it is possible to run amd64 on my old hardware
1#
vendor_id : GenuineIntel
cpu family : 6
model : 22
model name : Intel(R) Celeron(R) CPU 440 @ 2.00GHz
stepping : 1
microcode : 0x43
c
ttp://security.debian.org/debian-security/dists/buster/updates/main/binary-i386/Packages.xz>
does not have it.
The Firefox ESR91 series triggers an internal compiler error
with the GCC version included in Debian 10, so there's no build
available currently.
Thank you for defining this.
Ther
On Mon, Apr 11, 2022 at 01:45:56PM +0200, Odo Poppinger wrote:
> > The Firefox ESR91 series triggers an internal compiler error
> > with the GCC version included in Debian 10, so there's no build
> > available currently.
>
> I am still using i386 on some machines. Isn´t it possible to build with
>
get this from for buster and architecture i386?
<http://security.debian.org/debian-security/dists/buster/updates/main/binary-i386/Packages.xz>
does not have it.
The Firefox ESR91 series triggers an internal compiler error
with the GCC version included in Debian 10, so there's no buil
Friedhelm Waitzmann wrote:
>> For the oldstable distribution (buster), these problems have
>> been fixed in version 91.8.0esr-1~deb10u1.
>
> Where can I get this from for buster and architecture i386?
> <http://security.debian.org/debian-security/dists/buster/
On Wed, 2022-04-06 at 17:11:21 + Moritz Muehlenhoff wrote in the mailing
list debian-security-announce:
For the oldstable distribution (buster), these problems have
been fixed in version 91.8.0esr-1~deb10u1.
Where can I get this from for buster and architecture i386?
<h
1 - 100 of 2275 matches
Mail list logo
