om the kernel RA implementation.
> Thoughts?
Agreed, the less surprises here, the better.
--
Henrique de Moraes Holschuh
om the kernel RA implementation.
> Thoughts?
Agreed, the less surprises here, the better.
--
Henrique de Moraes Holschuh
Uploaded! Thank you!
On Sat, Aug 24, 2024, at 10:01, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
>
> On Sat, 2024-08-24 at 09:51 -0300, Henrique de Moraes Holschuh wrote:
>> I would like to bring the *firmware* update level for AMD processors
>> in Bullseye and B
Uploaded! Thank you!
On Sat, Aug 24, 2024, at 10:01, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
>
> On Sat, 2024-08-24 at 09:51 -0300, Henrique de Moraes Holschuh wrote:
>> I would like to bring the *firmware* update level for AMD processors
>> in Bullseye and B
+
+ * Rebuild for bullseye
+ * Revert merged-usr changes from unstable
+ * Revert move to non-free-firmware
+
+ -- Henrique de Moraes Holschuh Sat, 24 Aug 2024 09:28:39 -0300
+
+amd64-microcode (3.20240820.1) unstable; urgency=high
+
+ * Update package data from linux-firmware 20240820
+* New AMD-SEV
+
+ * Rebuild for bullseye
+ * Revert merged-usr changes from unstable
+ * Revert move to non-free-firmware
+
+ -- Henrique de Moraes Holschuh Sat, 24 Aug 2024 09:28:39 -0300
+
+amd64-microcode (3.20240820.1) unstable; urgency=high
+
+ * Update package data from linux-firmware 20240820
+* New AMD-SEV
+
+ * Rebuild for bookworm (revert merged-usr changes from unstable)
+
+ -- Henrique de Moraes Holschuh Sat, 24 Aug 2024 09:24:14 -0300
+
+amd64-microcode (3.20240820.1) unstable; urgency=high
+
+ * Update package data from linux-firmware 20240820
+* New AMD-SEV firmware from AMD upstream (20240820
+
+ * Rebuild for bookworm (revert merged-usr changes from unstable)
+
+ -- Henrique de Moraes Holschuh Sat, 24 Aug 2024 09:24:14 -0300
+
+amd64-microcode (3.20240820.1) unstable; urgency=high
+
+ * Update package data from linux-firmware 20240820
+* New AMD-SEV firmware from AMD upstream (20240820
tream issue and saw you had already commented there. :-)
Yeah, I was a bit late and that helped us this time :-)
--
Henrique de Moraes Holschuh
On Tue, Aug 20, 2024, at 13:28, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> Please go ahead.
Uploaded, thank you!
--
Henrique de Moraes Holschuh
tream issue and saw you had already commented there. :-)
Yeah, I was a bit late and that helped us this time :-)
--
Henrique de Moraes Holschuh
On Tue, Aug 20, 2024, at 13:28, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> Please go ahead.
Uploaded, thank you!
--
Henrique de Moraes Holschuh
ium
+
+ * Build for bullseye (no changes from 3.20240813.1)
+
+ -- Henrique de Moraes Holschuh Mon, 19 Aug 2024 22:26:47 -0300
+
+intel-microcode (3.20240813.1) unstable; urgency=medium
+
+ * New upstream microcode datafile 20240813 (closes: #1078742)
+- Mitigations for INTEL-SA-0
ium
+
+ * Build for bookworm (no changes from 3.20240813.1)
+
+ -- Henrique de Moraes Holschuh Mon, 19 Aug 2024 21:59:40 -0300
+
+intel-microcode (3.20240813.1) unstable; urgency=medium
+
+ * New upstream microcode datafile 20240813 (closes: #1078742)
+- Mitigations for INTEL-SA-0
ium
+
+ * Build for bullseye (no changes from 3.20240813.1)
+
+ -- Henrique de Moraes Holschuh Mon, 19 Aug 2024 22:26:47 -0300
+
+intel-microcode (3.20240813.1) unstable; urgency=medium
+
+ * New upstream microcode datafile 20240813 (closes: #1078742)
+- Mitigations for INTEL-SA-0
ium
+
+ * Build for bookworm (no changes from 3.20240813.1)
+
+ -- Henrique de Moraes Holschuh Mon, 19 Aug 2024 21:59:40 -0300
+
+intel-microcode (3.20240813.1) unstable; urgency=medium
+
+ * New upstream microcode datafile 20240813 (closes: #1078742)
+- Mitigations for INTEL-SA-0
Uploaded.
Thank you!
On Sat, Aug 17, 2024, at 13:47, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
--
Henrique de Moraes Holschuh
Uploaded!
Thank you!
On Sat, Aug 17, 2024, at 13:46, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
Uploaded!
Thank you!
On Sat, Aug 17, 2024, at 13:46, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
Uploaded.
Thank you!
On Sat, Aug 17, 2024, at 13:47, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
--
Henrique de Moraes Holschuh
ebian.org alerts that the upload had reintroduced bugs in Trixie,
when I got your email on this bug report.
I have uploaded 3.20240813.2 a few minutes ago merging in the NMU changes and
hopefully fixing the oversight and closing this bug once again. Sorry about
that!
--
Henrique de Moraes Holschuh
ebian.org alerts that the upload had reintroduced bugs in Trixie,
when I got your email on this bug report.
I have uploaded 3.20240813.2 a few minutes ago merging in the NMU changes and
hopefully fixing the oversight and closing this bug once again. Sorry about
that!
--
Henrique de Moraes Holschuh
+not supported in Debian.
RECOVERY PROCEDURE:
@@ -97,4 +91,4 @@ the initramfs images for every installed kernel.
Please report any issues caused by microcode updates to the mailing-list or
to the Debian bug tracker.
- -- Henrique de Moraes Holschuh , 2016-04-05
+ -- Henrique de Moraes Hols
orted in Debian.
RECOVERY PROCEDURE:
@@ -97,4 +91,4 @@ the initramfs images for every installed kernel.
Please report any issues caused by microcode updates to the mailing-list or
to the Debian bug tracker.
- -- Henrique de Moraes Holschuh , 2016-04-05
+ -- Henrique de Moraes Hols
+not supported in Debian.
RECOVERY PROCEDURE:
@@ -97,4 +91,4 @@ the initramfs images for every installed kernel.
Please report any issues caused by microcode updates to the mailing-list or
to the Debian bug tracker.
- -- Henrique de Moraes Holschuh , 2016-04-05
+ -- Henrique de Moraes Hols
orted in Debian.
RECOVERY PROCEDURE:
@@ -97,4 +91,4 @@ the initramfs images for every installed kernel.
Please report any issues caused by microcode updates to the mailing-list or
to the Debian bug tracker.
- -- Henrique de Moraes Holschuh , 2016-04-05
+ -- Henrique de Moraes Hols
...
--
Henrique de Moraes Holschuh
(uploaded, not updated).
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2077080
Title:
upstream release 20240813 was updated without version bump
To manage notifications about this bug go to:
https:
The packages updated a few minutes ago to Debian unstable (which still
need a few hours to be installed into the archive, autobuilt, etc) are
based on the *REVISED* release.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.
that ~deb sorts later than ~bpo, as that updates a backport
to a stable / oldstable / oldoldstable update. But that was sheer luck. This
is not true for ~pre, but would work for ~~pre or ~~~~whatever...
--
Henrique de Moraes Holschuh
that ~deb sorts later than ~bpo, as that updates a backport
to a stable / oldstable / oldoldstable update. But that was sheer luck. This
is not true for ~pre, but would work for ~~pre or ~~~~whatever...
--
Henrique de Moraes Holschuh
e amd64-microcode package has no
relationship to the dates on any of the microcode updates inside it. It is the
date of the latest commit in linux-firmware that changed any of the several
firmware files (AMD ucode, AMD SEV, AMD TEE) inside it.
I hope this information solves any lingering doubts about how it works?
--
Henrique de Moraes Holschuh
uot;usbmisc" hotplug does *not* look good, hopefully the
wiki is incomplete. Otherwise, procd should be improved and meanwhile,
you need to deploy a script to handle that event that does the
follow-the-symlinks game in sysfs to go from usblp to usb endpoint, and
get the necessary device data
I have uploaded it source-only a few days ago, but missed emailing this bug
report about it :-(
Thank you, and sorry for the delay!
On Wed, Jun 5, 2024, at 18:19, Jonathan Wiltshire wrote:
> Please go ahead.
--
Henrique de Moraes Holschuh
I have uploaded it source-only a few days ago, but missed emailing this bug
report about it :-(
Thank you, and sorry for the delay!
On Wed, Jun 5, 2024, at 18:18, Jonathan Wiltshire wrote:
> Please go ahead.
--
Henrique de Moraes Holschuh
I have uploaded it source-only a few days ago, but missed emailing this bug
report about it :-(
Thank you, and sorry for the delay!
On Wed, Jun 5, 2024, at 18:19, Jonathan Wiltshire wrote:
> Please go ahead.
--
Henrique de Moraes Holschuh
I have uploaded it source-only a few days ago, but missed emailing this bug
report about it :-(
Thank you, and sorry for the delay!
On Wed, Jun 5, 2024, at 18:18, Jonathan Wiltshire wrote:
> Please go ahead.
--
Henrique de Moraes Holschuh
ould still test it
to be sure.
Dracut, I haven't looked into what it is doing. Hopefully it also uses
iucode_tool nowadays...
--
Henrique de Moraes Holschuh
0c06f2, pf_mask 0x87, 2024-02-05, rev 0x21000230, size 552960
+ sig 0x000c06f1, pf_mask 0x87, 2024-02-05, rev 0x21000230
+ * source: update symlinks to reflect id of the latest release, 20240514
+
+ -- Henrique de Moraes Holschuh Thu, 16 May 2024 21:40:52 -0300
+
intel-microcode (3.20240312
0c06f2, pf_mask 0x87, 2024-02-05, rev 0x21000230, size 552960
+ sig 0x000c06f1, pf_mask 0x87, 2024-02-05, rev 0x21000230
+ * source: update symlinks to reflect id of the latest release, 20240514
+
+ -- Henrique de Moraes Holschuh Thu, 16 May 2024 21:40:52 -0300
+
intel-microcode (3.20240312
Bullseye
+ * debian/control: revert non-free-firmware change
+
+ -- Henrique de Moraes Holschuh Wed, 29 May 2024 23:31:29 -0300
+
+intel-microcode (3.20240514.1) unstable; urgency=medium
+
+ * New upstream microcode datafile 20240514
+* Mitigations for INTEL-SA-01051 (CVE-2023-45733)
+ Har
Bullseye
+ * debian/control: revert non-free-firmware change
+
+ -- Henrique de Moraes Holschuh Wed, 29 May 2024 23:31:29 -0300
+
+intel-microcode (3.20240514.1) unstable; urgency=medium
+
+ * New upstream microcode datafile 20240514
+* Mitigations for INTEL-SA-01051 (CVE-2023-45733)
+ Har
On Mon, Apr 22, 2024, at 13:58, Jonathan Wiltshire wrote:
> Control: tag -1 confirmed
>
> On Sat, Mar 30, 2024 at 07:50:45AM -0300, Henrique de Moraes Holschuh wrote:
>> As requested by the security team, I would like to bring the microcode
>> update level for Intel proce
On Mon, Apr 22, 2024, at 13:58, Jonathan Wiltshire wrote:
> Control: tag -1 confirmed
>
> On Sat, Mar 30, 2024 at 07:50:45AM -0300, Henrique de Moraes Holschuh wrote:
>> As requested by the security team, I would like to bring the microcode
>> update level for Intel proce
links
to the libc and that's it...
And that benefits everything that links to TCP wrappers...
I also like to have the (old-school) standard extra layer of protection that
libwrap can provide. I'd like to find a way to keep it useful for sshd.
--
Henrique de Moraes Holschuh
links
to the libc and that's it...
And that benefits everything that links to TCP wrappers...
I also like to have the (old-school) standard extra layer of protection that
libwrap can provide. I'd like to find a way to keep it useful for sshd.
--
Henrique de Moraes Holschuh
Uploaded.
On Mon, Apr 1, 2024, at 08:48, Jonathan Wiltshire wrote:
> Control: tag -1 confirmed
>
> On Sat, Mar 30, 2024 at 07:47:05AM -0300, Henrique de Moraes Holschuh wrote:
>> As requested by the security team, I would like to bring the microcode
>> update level fo
Uploaded.
On Mon, Apr 1, 2024, at 08:48, Jonathan Wiltshire wrote:
> Control: tag -1 confirmed
>
> On Sat, Mar 30, 2024 at 07:47:05AM -0300, Henrique de Moraes Holschuh wrote:
>> As requested by the security team, I would like to bring the microcode
>> update level fo
d a VM though, when stable + container is not enough.
--
Henrique de Moraes Holschuh
elog
+++ b/debian/changelog
@@ -1,3 +1,91 @@
+intel-microcode (3.20240312.1~deb12u1) bookworm; urgency=medium
+
+ * Build for bookworm (no changes)
+
+ -- Henrique de Moraes Holschuh Sat, 30 Mar 2024 07:01:52 -0300
+
+intel-microcode (3.20240312.1) unstable; urgency=medium
+
+ * New upstream
elog
+++ b/debian/changelog
@@ -1,3 +1,91 @@
+intel-microcode (3.20240312.1~deb12u1) bookworm; urgency=medium
+
+ * Build for bookworm (no changes)
+
+ -- Henrique de Moraes Holschuh Sat, 30 Mar 2024 07:01:52 -0300
+
+intel-microcode (3.20240312.1) unstable; urgency=medium
+
+ * New upstream
an/changelog
index fa702cb..317fad2 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,92 @@
+intel-microcode (3.20240312.1~deb11u1) bullseye; urgency=medium
+
+ * Backport to Debian Bullseye
+ * debian/control: revert non-free-firmware change
+
+ -- Henrique de Moraes Holschuh Sat,
elog
+++ b/debian/changelog
@@ -1,3 +1,92 @@
+intel-microcode (3.20240312.1~deb11u1) bullseye; urgency=medium
+
+ * Backport to Debian Bullseye
+ * debian/control: revert non-free-firmware change
+
+ -- Henrique de Moraes Holschuh Sat, 30 Mar 2024 07:06:46 -0300
+
+intel-microcode (3.20240312.1)
elog
+++ b/debian/changelog
@@ -1,3 +1,92 @@
+intel-microcode (3.20240312.1~deb11u1) bullseye; urgency=medium
+
+ * Backport to Debian Bullseye
+ * debian/control: revert non-free-firmware change
+
+ -- Henrique de Moraes Holschuh Sat, 30 Mar 2024 07:06:46 -0300
+
+intel-microcode (3.20240312.1)
an/changelog
index fa702cb..317fad2 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,92 @@
+intel-microcode (3.20240312.1~deb11u1) bullseye; urgency=medium
+
+ * Backport to Debian Bullseye
+ * debian/control: revert non-free-firmware change
+
+ -- Henrique de Moraes Holschuh Sat,
e.
May I humbly suggest "dns-assetfinder" ?
It might be a very good idea to talk to upstream first.
--
Henrique de Moraes Holschuh
e.
May I humbly suggest "dns-assetfinder" ?
It might be a very good idea to talk to upstream first.
--
Henrique de Moraes Holschuh
o early to even guess which one would
make sense to stick to)...
There are other potential issues as well, it is best to wait a couple months at
the very least.
--
Henrique de Moraes Holschuh
o early to even guess which one would
make sense to stick to)...
There are other potential issues as well, it is best to wait a couple months at
the very least.
--
Henrique de Moraes Holschuh
On Thu, Feb 15, 2024, at 15:45, Mario Limonciello wrote:
> On 2/15/2024 12:39, Henrique de Moraes Holschuh wrote:
>> While adding linux-firmware's amdtee/ directory to the Debian
>> amd64-microcode package, I have noticed that the linux-firmware WHENCE file
>> mentio
On Thu, Feb 15, 2024, at 15:45, Mario Limonciello wrote:
> On 2/15/2024 12:39, Henrique de Moraes Holschuh wrote:
>> While adding linux-firmware's amdtee/ directory to the Debian
>> amd64-microcode package, I have noticed that the linux-firmware WHENCE file
>> mentio
8543.bin
Is the amd_pmf driver functional without that symlink ?
--
Henrique de Moraes Holschuh
8543.bin
Is the amd_pmf driver functional without that symlink ?
--
Henrique de Moraes Holschuh
otherwise AFAIK, and I could not find the newer revisions listed in any AMD
advisories. If you know otherwise, drop us a note privately (e.g. inform the
Debian security team, or inform me directly) and we will issue it as a security
update.
--
Henrique de Moraes Holschuh
otherwise AFAIK, and I could not find the newer revisions listed in any AMD
advisories. If you know otherwise, drop us a note privately (e.g. inform the
Debian security team, or inform me directly) and we will issue it as a security
update.
--
Henrique de Moraes Holschuh
made it to any linux-firmware packages ?
And I need to know what I should do about it on the backport branches and
security update branches.
--
Henrique de Moraes Holschuh
risk of *regressions* is greatly reduced.
--
Henrique de Moraes Holschuh
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Uploaded (source).
Thank you!
On Sun, Oct 1, 2023, at 05:53, Adam D. Barratt wrote:
> Control: tags -1 confirmed
--
Henrique de Moraes Holschuh
Uploaded (source + amd64 binaries).
Thank you!
--
Henrique de Moraes Holschuh
Uploaded (source).
Thank you!
On Sun, Oct 1, 2023, at 05:53, Adam D. Barratt wrote:
> Control: tags -1 confirmed
--
Henrique de Moraes Holschuh
Uploaded (source + amd64 binaries).
Thank you!
--
Henrique de Moraes Holschuh
is a group of patches that are already
+present in the Linux stable/LTS trees since versions: v4.19.289,
+v5.4.250, v5.10.187, v5.15.120, v6.1.37, v6.3.11 and v6.4.1. These
+patches are also present in Linux v6.5-rc1.
+
+ -- Henrique de Moraes Holschuh Thu, 10 Aug 2023 09:32:37 -0300
+
a
is a group of patches that are already
+present in the Linux stable/LTS trees since versions: v4.19.289,
+v5.4.250, v5.10.187, v5.15.120, v6.1.37, v6.3.11 and v6.4.1. These
+patches are also present in Linux v6.5-rc1.
+
+ -- Henrique de Moraes Holschuh Thu, 10 Aug 2023 09:32:37 -0300
+
a
is a group of patches that are already
+present in the Linux stable/LTS trees since versions: v4.19.289,
+v5.4.250, v5.10.187, v5.15.120, v6.1.37, v6.3.11 and v6.4.1. These
+patches are also present in Linux v6.5-rc1.
+
+ -- Henrique de Moraes Holschuh Thu, 10 Aug 2023 09:32:37 -0300
+
a
is a group of patches that are already
+present in the Linux stable/LTS trees since versions: v4.19.289,
+v5.4.250, v5.10.187, v5.15.120, v6.1.37, v6.3.11 and v6.4.1. These
+patches are also present in Linux v6.5-rc1.
+
+ -- Henrique de Moraes Holschuh Thu, 10 Aug 2023 09:32:37 -0300
+
a
versions in
stable is far higher.
--
Henrique de Moraes Holschuh
when they are about to execve() anything.
PS: I have attached an example of how one could do generic self-healing
of the standard low FDs in C in a POSIX environment where fcntl() and
dup2() are available. Note that FD 2 is expected to be R/W, according
to the C specification for stdio.h s
On Fri, 10 Mar 2023, Tobias Frost wrote:
> just a heads-up: I'm planning to fix those CVEs for LTS and ELTS, and fix them
> in the order unstable -> bookworm -> bullseye -> buster -> stretch -> jessie.
>
> For unstable, I plan to do an NMU.
>
> Staging area will be my fork on salsa:
> https://sa
issue, hunt down its Specification Update documentation, and
check for known errata, etc.
Do note the 16-byte alignment requirement for all buffers involved.
--
Henrique de Moraes Holschuh
Analista de Projetos
Centro de Estudos e Pesquisas em Tecnologias de Redes e Operações
(Ceptro.br)
+55 11
to still update older, EOLd processors (and we sometimes disable some microcode
updates as well).
--
Henrique de Moraes Holschuh
to stable (rather than going via
> backports) would be permissible?
Yes, they usually are. We can even send them in as security updates when we
get enough data to know it is going to fix a security issue **even when loaded
by the O.S.* (see remark above) and that it is not causing serious
re
(maintainer: Henrique de Moraes Holschuh)
> - amd64-microcode (maintainer: Henrique de Moraes Holschuh)
Please email me directly when it is time to do such upload changing the archive
section.
I assume we (maintainers) don't need to do the usual dance of opening a bug to
change the
personally feel it makes sense to group it with the processor firmware,
though.
Meanwhile, if there is an important SEV update pending, please file a bug
requesting an update on amd64-microcode.
--
Henrique de Moraes Holschuh
:16, Hauke Mehrtens escreveu:
* Update Linux kernel from 5.10.138 to 5.10.146
5.10.149 is out with a few extra wifi fixes, including a change in one
of the already backported commits.
Same for 5.4.y FWIW.
--
Henrique de Moraes Holschuh
Analista de Projetos
Centro de Estudos e Pesquisas em Tecn
On Tue, 26 Apr 2022, Aleksander Mihov wrote:
> 2. iucode_tool -Sv
> iucode_tool: system has processor(s) with signature 0x0001067a
> iucode_tool: assuming all processors have the same type, family and model
> root@del40:~#
>
> 3. root@del40:~# iucode-tool -tr -Lv /boot/initrd.img*
> microcode bund
On Fri, 13 May 2022, Salvatore Bonaccorso wrote:
> The following vulnerability was published for intel-microcode.
>
> CVE-2022-21151[0]:
> | Processor optimization removal or modification of security-critical
> | code for some Intel(R) Processors may allow an authenticated user to
> | potentially
WAN circuit suddenly becomes a bridge, and connects
that WAN circuit to the LAN circuit. And yes, obviously applies to
VLANs as well. Switching a port from LAN to WAN is also bad, and it can
be just as dangerous depending on several factors.
--
Henrique de Moraes Holsch
On Tue, 19 Apr 2022, ilexa wrote:
> I have started updating the system via apt-get update and upgrade. New
> version of intel-microcode was buster/non-free: 3.20220207.1~deb10u1
>
> System booted normally but started to crash/freeze with garbadge screen and
> did not response to any keyboard com
On Fri, 04 Mar 2022, Ottavio Caruso wrote:
> ~$ sudo find /lib/modules/ -iname "*z3fold*"
> /lib/modules/4.19.0-17-amd64/kernel/mm/z3fold.ko
> /lib/modules/4.19.0-14-amd64/kernel/mm/z3fold.ko
> /lib/modules/4.19.0-8-amd64/kernel/mm/z3fold.ko
>
>
> Then why doesn't it load up?
update-initramfs -u
On Sun, 17 Apr 2022, Friedhelm Waitzmann wrote:
> > > You mean, that it is possible to run amd64 on my old hardware
I had quite a lot of trouble mapping this a long time ago for
intel-microcode. I ended up using several sources including, but not
limited to: ark.intel.com, the processor specifica
l critical "functional issues" (i.e. processor errata).
+There were no reports to date of regressions introduced by this microcode
+ drelease.
+
+ -- Henrique de Moraes Holschuh Sun, 20 Mar 2022 17:40:05 -0300
+
+intel-microcode (3.20220207.1) unstable; urgency=medium
+
+ * ups
l critical "functional issues" (i.e. processor errata).
+There were no reports to date of regressions introduced by this microcode
+ drelease.
+
+ -- Henrique de Moraes Holschuh Sun, 20 Mar 2022 17:40:05 -0300
+
+intel-microcode (3.20220207.1) unstable; urgency=medium
+
+ * ups
sues" (i.e. processor errata).
+There were no reports to date of regressions introduced by this microcode
+drelease.
+
+ -- Henrique de Moraes Holschuh Sun, 20 Mar 2022 18:19:10 -0300
+
+intel-microcode (3.20220207.1) unstable; urgency=medium
+
+ * upstream changelog: new upstream da
sues" (i.e. processor errata).
+There were no reports to date of regressions introduced by this microcode
+drelease.
+
+ -- Henrique de Moraes Holschuh Sun, 20 Mar 2022 18:19:10 -0300
+
+intel-microcode (3.20220207.1) unstable; urgency=medium
+
+ * upstream changelog: new upstream da
** Changed in: autotools-dev (Ubuntu)
Status: New => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1743051
Title:
package autotools-dev 20150820.1 failed to install/upgrade: le paq
On Wed, 02 Feb 2022, Vincent Lefevre wrote:
> When I want to connect with SSH (ssh/scp) to some machine, I sometimes
> get errors, either
>
> kex_exchange_identification: Connection closed by remote host
>
> or
>
> kex_exchange_identification: read: Connection reset by peer
That's a very early
k firmware ID for the TP-Link Archer C6v3.0 (BR),
which is currently sold in Brazil. It uses exactly the same vendor
firmware as the A6v3 and C6v3.20.
Signed-off-by: Henrique de Moraes Holschuh
---
src/tplink-safeloader.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/
-) Adding the mentioned PROVIDES would make life
easier for [third-party] packages that support older OpenWRT releases,
and which can't simply "drop" those dependencies because they are needed
on older OpenWRT.
--
Henrique de Moraes Holschuh
Analista de Projetos
Centro
On Wed, 01 Sep 2021, Bjørn Mork wrote:
> ifupdown has this extremely annoying misfeature that it forces a release
> on shutdown, both for DHCP and DHCPv6. The automatic release on every
This is *highly* desired *on IPv4*, wherever address pools are scarce.
The correct thing would likely be: do n
an issue by just doing a binary (arch) upload, yes.
But I am not involved directly with the ELTS upload, and I don't know what's
acceptable/accepted there.
> On Wed, 15 Sept 2021 at 12:54, Henrique de Moraes Holschuh
> wrote:
>> Hello,
>>
>> The microcode p
1 - 100 of 10815 matches
Mail list logo
