m trying to help merely because packages I care about are
in trouble on mips64el...
Cheers!
--
Sergei Golovan
Dear mips64el porters,
This is a warning from a Release Team member regarding the state of
mips64el in Debian.
Unless Sergei considers himself a mips64el porter, I haven't seen
activity of the mips64el porters on bug 1093200 and similar bugs where
the porters were asked for help and thus cc-
hat, the test program from [1] started working on kernel
6.1.123 in qemu (on machine loongson3-virt).
I can't say I know what I'm doing, so can someone review and try the
attached patch
on real hardware and test if the bug from [1] is indeed connected to #1093200
(and also to #1093859, #108
Hi!
On Wed, Jan 29, 2025 at 10:45 PM Uwe Kleine-König wrote:
>
> Hello,
>
> I agree this looks like the kernel is at least involved in this problem.
> Is someone able to do a bisect to help the kernel team to pinpoint the
> issue?
>
> Or does someone has a reproducer that also works for someone w
Hello,
On Sun, Jan 19, 2025 at 11:41:04AM +, Simon McVittie wrote:
> Control: reassign -1 src:linux/6.1.76-1
I agree this looks like the kernel is at least involved in this problem.
Is someone able to do a bisect to help the kernel team to pinpoint the
issue?
Or does someone has a reproducer
Control: reassign -1 src:linux/6.1.76-1
On Thu, 16 Jan 2025 at 12:39:39 +, Simon McVittie wrote:
> Control: retitle -1 Some packages consistently FTBFS with EFAULT (Bad
> address) on most mips64el buildds
>
> On Thu, 16 Jan 2025 at 12:40:07 +0100, Fabian Grünbichler wrote:
&g
Your message dated Mon, 25 Nov 2024 10:47:09 +
with message-id
and subject line Bug#1087602: fixed in linux 6.1.119-1
has caused the Debian Bug report #1087602,
regarding nodejs: several nodejs packages hang the autobuilder
to be marked as done.
This means that you claim that the problem has
On Thu, 2024-09-12 at 02:42 +0200, Ben Hutchings wrote:
> Hello all,
>
> This is a heads-up that the kernel team is planning to stop building
> i386 kernel packages shortly (probably starting with Linux 6.11).
>
> As this was previously discussed at last year's Cambr
On Sat, 2024-09-14 at 01:37 +0200, Cyril Brulebois wrote:
> Hi,
>
> Ben Hutchings (2024-09-12):
> > This is a heads-up that the kernel team is planning to stop building
> > i386 kernel packages shortly (probably starting with Linux 6.11).
>
> Thanks, appreciated.
>
Hi,
Ben Hutchings (2024-09-12):
> This is a heads-up that the kernel team is planning to stop building
> i386 kernel packages shortly (probably starting with Linux 6.11).
Thanks, appreciated.
Just happened to spot that linux-signed-i386 is still around (and
outdated) in testing+unstable
Hello all,
This is a heads-up that the kernel team is planning to stop building
i386 kernel packages shortly (probably starting with Linux 6.11).
As this was previously discussed at last year's Cambridge mini-DebConf
and announced in
<https://lists.debian.org/debian-devel-announce
it heads-up.
I've made a team upload of iproute2 (version 6.10.0-2) with this change
reverted.
Luca, please leave the symlink in place at least as long as there are
packages that rely on it.
Ben.
--
Ben Hutchings
All the simple programs have been written, and all the good names taken
signature.asc
Description: This is a digitally signed message part
On Fri, Aug 16, 2024 at 04:54:02PM +0100, Colin Watson wrote:
Quite. If nothing else, I think the code actually in the Debian archive
that relies on the old path ought to be changed _first_, e.g. via an
MBF. I see a bunch of cases that are relatively subtle and might suck a
lot of other people'
On Fri, Aug 16, 2024 at 05:21:38PM +0200, Philip Hands wrote:
> I think it probably was just a coincidence, since it looks like the
> change was made in order to fix #1064795 which was reported on
> 25 Feb 2024.
Ah, good to know, thanks. I didn't notice that since it wasn't
mentioned in the iprou
is how debian works now. We used to
>> > > try to not break things, now the answer is "you should have read the
>> > > NEWS, and known that unrelated packages were going to break, and
>> > > reconfigured standard debian network tools to add non-default
>>
Your patch shows /bin/ip. Shouldn't it be /usr/bin/ip?
On Wed, 2024-08-14 at 20:45 +, Debian Bug Tracking System wrote:
> Processing control commands:
>
> > reassign -1 vlan 2.0.5+nmu2
> Bug #1078721 [iproute2] iproute2: removing /sbin/ip link breaks other
> pac
Processing control commands:
> reassign -1 vlan 2.0.5+nmu2
Bug #1078721 [iproute2] iproute2: removing /sbin/ip link breaks other packages
and possibly user scripts
Bug reassigned from package 'iproute2' to 'vlan'.
No longer marked as found in versions iproute2/6.10.0-1.
Ig
Control: reassign -1 vlan 2.0.5+nmu2
Control: tags -1 patch
On Wed, 14 Aug 2024 15:35:56 -0400 Michael Stone
wrote:
> Package: iproute2
> Version: 6.10.0-1
> Severity: critical
> Justification: breaks the whole system
>
> The first time I rebooted after iproute2 removed the /sbin/ip link,
my sys
Linux 6.10.4-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM:
Processing control commands:
> reopen -1
Bug #1077238 {Done: Diederik de Haas }
[firmware-misc-nonfree] Upgrade will break networking, thus unable to download
missing packages
Bug reopened
Ignoring request to alter fixed versions of bug #1077238 to the same values
previously set
> reti
network.
> 2. Not be able to see your screen.
> 3. Not be able to boot.
> and thus unable to install the new packages to fix it too.
> Therefore be sure to install the new packages ... now, unless you are
> sure you know what you are doing.
I guess it won't hurt to expand the NEWS
Yes. The news item needs to warn:
** Warning: if you take no action, upon the next boot you might
1. Not be able to network.
2. Not be able to see your screen.
3. Not be able to boot.
and thus unable to install the new packages to fix it too.
Therefore be sure to install the new packages ... now
ctly how it was implemented:
misc-nonfree Recommends all the packages where firmware files which were in
misc-nonfree before, but are now in one of the new packages.
Which allows them to remove the Recommended packages they don't need.
Next to the Recommends solution, you should have also rece
Your message dated Sat, 27 Jul 2024 10:12:00 +0200
with message-id <2628657.L8QfnQrbHx@bagend>
and subject line Re: Bug#1077238: Upgrade will break networking, thus unable to
download missing packages
has caused the Debian Bug report #1077238,
regarding Upgrade will break networking, thus
r
to remove the ones they don't want.
Else the upon next boot, they can no longer connect. And thus cannot
download the missing packages.
And must get help from a third party.
kernel build, so there was much less duplication between the signed
and unsigned binary packages.
> The vmlinuz between signed/unsigned is mostly the same (guess the main
> difference is the appended signature).
>
>
> So what if there were e.g.:
> - ONLY linux-image-6.9.7-amd64 (and n
Hello there.
I just wondered whether it has even been considered to make just one
package which contains the actual kernel+modules, and another one that
contains the signatures?
I'm not an expert when it comes to the binary layout of that, but
AFAIU, the modules are anyway the same between the
Processing control commands:
> tags -1 wontfix
Bug #1071430 [linux-headers-6.8.9-amd64] dkms modules compile twice when
installing new linux-image and linux-headers packages
Added tag(s) wontfix.
--
1071430: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1071430
Debian Bug Tracking Sys
Control: tags -1 wontfix
On Sun, May 19, 2024 at 03:09:03PM +1000, Craig Sanders wrote:
> When installing a new kernel (images & headers) packages, dkms modules for
> that kernel version are compiled twice - once for the linux image package, and
> again (almost immediately afterw
Your message dated Wed, 24 Apr 2024 11:00:10 +
with message-id
and subject line Bug#1068189: fixed in linux 6.7.12-1
has caused the Debian Bug report #1068189,
regarding debhelper: --link-doc checking for known packages makes linux-signed
build FTBFS
to be marked as done.
This means that
Processing control commands:
> reassign -1 src:linux 6.7.9-2
Bug #1068189 [src:debhelper] debhelper: --link-doc checking for known packages
makes linux-signed build FTBFS
Bug reassigned from package 'src:debhelper' to 'src:linux'.
No longer marked as found in versions de
nnoticed" by
> debhelper. That is, when people forgot to update --link-doc parameters
> (etc.).
>
> The code for `--link-doc` uses `${binary:Version}` for the dependency, so
> the package should really be from the same source[1]. In my view, it was
> never a case that was expecte
Source: debhelper
Version: 13.15
Severity: serious
Tags: ftbfs
Justification: Regression for other package builds, FTBFS
X-Debbugs-Cc: car...@debian.org,debian-kernel@lists.debian.org
Control: affects -1 + src:linux,src:linux-signed-amd64,src:linux-signed-arm64
Hi Niels,
Not fully investigated, b
Package: linux-image-6.1.0-14-rt-amd64
Version: 6.1.64-1
When I run apt upgrade command it shows Error 403 Access Denied
Here is a transcript:
E: Failed to fetch
http://ftp.debian.org/debian/pool/main/l/linux-signed-amd64/linux-image-6.1.0-14-rt-amd64_6.1.64-1_amd64.deb
403 Access denied - br
whole discussion to me even more strongly suggests that the
current way of trying to satisfy these requirements on kernels
availability shouldn't really be delegated only to packages content.
And that's before we get into ESP size issues. So the idea to split
these apart - packages in
On Fri, Oct 27, 2023 at 01:04:00PM +0300, Adrian Bunk wrote:
> > Sadly in Debian there is no way to make that happen. Think for example
> > about bin-nmu.
> Could you give a complete list of problems?
There are at least those problems:
- Bin-nmu can't change binary package names.
- There is no wa
On Fri, Oct 27, 2023 at 10:55:48AM +0200, Bastian Blank wrote:
> On Fri, Oct 27, 2023 at 08:43:46AM +0200, Julian Andres Klode wrote:
> > > > ## Image packages contains more version info
> > > >
> > > > Example: linux-image-6.5.3-cloud-arm64
> >
On Fri, Oct 27, 2023 at 08:43:46AM +0200, Julian Andres Klode wrote:
> > > ## Image packages contains more version info
> > >
> > > Example: linux-image-6.5.3-cloud-arm64
> >
> > > It will not longer be possible to reliably derive the package name from
stian Blank wrote:
> Moin
>
> On Sun, Sep 24, 2023 at 03:01:51PM +0200, Bastian Blank wrote:
> > ## Kernel modules will be signed with an ephemeral key
>
> This is now
> https://salsa.debian.org/kernel-team/linux/-/merge_requests/607.
>
> > ## Image packages cont
On Thu, Oct 26, 2023 at 01:36:50PM +0200, Bastian Blank wrote:
> On Fri, Oct 20, 2023 at 05:54:23PM +0200, Bastian Blank wrote:
> > Or would it be easier to re-use normal dependency resolving, like:
> > Kernel-Provides: linux (>> 6.6.1~), linux (<< 6.6.1.)
> > This would allow full flexibility and
lity.
For now it looks like a better solution is to just create more meta
packages and accept that they become uninstallable from time to time.
In the future we might want to split off the modules into it's own
package anyway. That will then allow
- a different image package containing preb
On Fri, Oct 20, 2023 at 05:54:23PM +0200, Bastian Blank wrote:
> Or would it be easier to re-use normal dependency resolving, like:
> Kernel-Provides: linux (>> 6.6.1~), linux (<< 6.6.1.)
> This would allow full flexibility and re-uses existing code to check
> such definitions.
Okay, noone complai
[ Removing some lists ]
On Sat, Oct 07, 2023 at 04:53:33PM +0200, Bastian Blank wrote:
> > ## Image packages contains more version info
> >
> > Example: linux-image-6.5.3-cloud-arm64
>
> > It will not longer be possible to reliably derive the package name from
> &g
Moin
On Sun, Sep 24, 2023 at 03:01:51PM +0200, Bastian Blank wrote:
> ## Kernel modules will be signed with an ephemeral key
This is now
https://salsa.debian.org/kernel-team/linux/-/merge_requests/607.
> ## Image packages contains more version info
>
> Example: linux-image-6.5.3
n. Aka to have
co-installable packages for security updates we do:
- 6.6.1-1
- 6.6.1+1-1
- 6.6.1+2-1
This allows for easy semantic, aka we only care for package names about
the upstream part of the version, which then needs to follow a certain
syntax.
Regards,
Bastian
--
A Vulcan can no sooner b
s. They can still
> build modules against that kernel, either because they installed a new
> dkms package, or because one of their dkms packages upgraded.
I am also really confused by this discussion and don't entirely understand
the motivation for the proposed change to kernel
>>>>> "Bastian" == Bastian Blank writes:
Bastian> The same as now: nowhere, because those packages have been
Bastian> removed from the archive already.
Bastian> And sadly you did not answer the question why a second
Bastian> degree error m
as now: nowhere, because those packages have been removed from
the archive already.
And sadly you did not answer the question why a second degree error must
not be worse then a worked around first degree error?
> I know there is a lot of history behind the linux-headers package in
> debian. Howev
Hi Andreas
On Tue, Oct 03, 2023 at 11:58:29PM +0200, Andreas Beckmann wrote:
> That should solve the problem where several source packages need to be
> updated together.
The problem does not come from multiple source packages that need to be
updated together. Instead it comes from t
On 03/10/2023 19.30, Bastian Blank wrote:
thread. Or freak out because meta packages remain uninstallable in
backports for days.
...
plus gcc or we change how backports works.
If uninstallable packages in backports are a problem, perhaps backports
needs something like britney to migrate
On Tue, Oct 3, 2023 at 2:54 PM Adrian Bunk wrote:
>
> On Tue, Oct 03, 2023 at 07:30:49PM +0200, Bastian Blank wrote:
> >...
> > The core problem is that people assume they can get headers matching the
> > currently running kernel, without upgrading first, see also the parallel
> > thread.
> >...
>
On Tue, Oct 03, 2023 at 07:30:49PM +0200, Bastian Blank wrote:
>...
> The core problem is that people assume they can get headers matching the
> currently running kernel, without upgrading first, see also the parallel
> thread.
>...
If the new kernel has a regression that affects the user, the use
w-ups, and I still do not understand what is prompting the
> linux-headers change.
The core problem is that people assume they can get headers matching the
currently running kernel, without upgrading first, see also the parallel
thread. Or freak out because meta packages remain uninstallable i
> "Bastian" == Bastian Blank writes:
Bastian> On Mon, Sep 25, 2023 at 04:35:08AM +0200, Andreas Beckmann wrote:
>> On 25/09/2023 00.50, Bastian Blank wrote:
>> > Already built modules remain until someone deletes it. So you
>> can also > switch back to the still installed old
On Mon, Sep 25, 2023 at 04:35:08AM +0200, Andreas Beckmann wrote:
> On 25/09/2023 00.50, Bastian Blank wrote:
> > Already built modules remain until someone deletes it. So you can also
> > switch back to the still installed older kernel version and it will have
> > the still working module availab
On Mon, Sep 25, 2023 at 02:03:35AM +0200, Bastian Blank wrote:
> The current way does not work. See all the bug reports about
> uninstallable packages and what not with dkms.
>
> To build modules against version x, you'll need to install version x of
> the headers, n
ould "automatically switch" to the with-headers variant, not sure
> how
> this could be done). The current scheme of having to install
> linux-image-$flavor AND linux-headers-$flavor is a bit tricky.
> I'm open to implement improvements on the dkms side.
I could not
install
linux-image-$flavor AND linux-headers-$flavor is a bit tricky.
I'm open to implement improvements on the dkms side.
Andreas
PS: the proposed "more versioning in the linux-image packages" will
solve some rare dkms issues where modules didn't get rebuilt after
linux-he
e on architectures
> supporting SB (and sometimes incompatible on others due to compiler
> differences or required config changes).
I don't know what you are talking about. Those two packages have
different versions, so won't contain anything compatible. It is the
same between 1.2.3-1
gt; EFI kernel image itself. Instead a key will be created during the build
> > and thrown away after.
>
> Do I correctly assume that change only affects the modules shipped by the
> linux-image packages and not third-party modules built with dkms?
Yes. Nothing calls for changes to MOK ke
change only affects the modules shipped by
the linux-image packages and not third-party modules built with dkms?
## Header and tool packages will not longer contain version
This means that only headers of one single version can be available on
the system at one time. This might be a bit
already unreproducible due to
inconsistent generation of BTF in both the kernel and modules.
Additionally, my "plan" would also get rid of signing modules with the
Secure Boot CA, so I'm not going to object to this.
[...]
> ## Image packages contains more version info
>
>
information are in #1040901.
We could just do the minimal change, sign the modules a different way
and let users walk into authenticated failures and other scary error
messages. Or we could change the existing ABI setting on every upload,
creating a new set of binary packages.
But maybe we can
Your message dated Sat, 26 Aug 2023 11:33:00 +
with message-id
and subject line Bug#871216: fixed in linux 5.10.191-1
has caused the Debian Bug report #871216,
regarding debian/bin/test-patches does not build arch-indep packages
to be marked as done.
This means that you claim that the
Your message dated Sat, 26 Aug 2023 11:33:00 +
with message-id
and subject line Bug#1035359: fixed in linux 5.10.191-1
has caused the Debian Bug report #1035359,
regarding linux: test-patches script produces uninstallable packages
to be marked as done.
This means that you claim that the
Your message dated Fri, 07 Jul 2023 07:32:09 +
with message-id
and subject line Bug#871216: fixed in linux 6.1.37-1
has caused the Debian Bug report #871216,
regarding debian/bin/test-patches does not build arch-indep packages
to be marked as done.
This means that you claim that the problem
Your message dated Fri, 07 Jul 2023 07:32:09 +
with message-id
and subject line Bug#1035359: fixed in linux 6.1.37-1
has caused the Debian Bug report #1035359,
regarding linux: test-patches script produces uninstallable packages
to be marked as done.
This means that you claim that the
Your message dated Sat, 01 Jul 2023 23:00:26 +
with message-id
and subject line Bug#871216: fixed in linux 6.3.11-1
has caused the Debian Bug report #871216,
regarding debian/bin/test-patches does not build arch-indep packages
to be marked as done.
This means that you claim that the problem
Your message dated Sat, 01 Jul 2023 23:00:26 +
with message-id
and subject line Bug#1035359: fixed in linux 6.3.11-1
has caused the Debian Bug report #1035359,
regarding linux: test-patches script produces uninstallable packages
to be marked as done.
This means that you claim that the
Processing control commands:
> reassign -1 src:linux
Bug #1037425 [linux-kbuild-6.1] linux-kbuild-6.1: please add Breaks against
obsolete *-dkms packages
Bug reassigned from package 'linux-kbuild-6.1' to 'src:linux'.
No longer marked as found in versions linux/6.1.27-1.
Ig
Control: reassign -1 src:linux
Control: severity -1 important
On Mon, Jun 12, 2023 at 05:31:53PM +0200, Andreas Beckmann wrote:
> As a consequence, if cruft *-dkms packages are still installed, but fail
> to build the module for current kernels, this may result in upgrade
> failures.
-headers---.postinst to fail.
(Up to bullseye, dkms returned 0 on failure and the failure was only
noticable when someone studied the install/upgrade log.)
As a consequence, if cruft *-dkms packages are still installed, but fail
to build the module for current kernels, this may result in upgrade
failures
On Tuesday, 2 May 2023 00:36:05 CEST Debian Bug Tracking System wrote:
> Processing commands for cont...@bugs.debian.org:
> > clone 1022061 -1
> > retitle -1 linux: test-patches script produces uninstallable packages
> > # First version with signed/unsigned Conflicts
> >
Processing control commands:
> severity -1 important
Bug #1036265 [firmware-iwlwifi, firmware-realtek, firmware-misc-nonfree] Wifi
deauthentications and complete connection loss with new packages:
firmware-iwlwifi, firmware-realtek, firmware-misc-nonfree in version
20190114+really2022091
Control: severity -1 important
On Thu, May 18, 2023 at 10:17:39AM +0200, 255.255.255.255 wrote:
> Package: firmware-iwlwifi, firmware-realtek, firmware-misc-nonfree
> Version: 20190114+really20220913-0+deb10u1
> Severity: Critical
>
> Kernel: 4.19.0-24-amd64 #1 SMP Debian 4.19.282-1 (2023-04-29)
Your message dated Tue, 09 May 2023 06:00:10 +
with message-id
and subject line Bug#871216: fixed in linux 6.1.27-1
has caused the Debian Bug report #871216,
regarding debian/bin/test-patches does not build arch-indep packages
to be marked as done.
This means that you claim that the problem
Processing commands for cont...@bugs.debian.org:
> clone 1022061 -1
Bug #1022061 [debian-kernel-handbook] debian-kernel-handbook: improve kernel
build steps for newbies
Bug 1022061 cloned as bug 1035359
> retitle -1 linux: test-patches script produces uninstallable packages
Bug #1035359 [
Hi,
On Tue, Apr 11, 2023 at 08:53:01AM +0200, Petr Mandys wrote:
> Dear maintainers,
>
> I have a problem with inconsistency of linux kernel related packages in
> bullseye-backports repository:
>
> linux-image-amd64 (6.1.*12*-1~bpo11+1)
> linux-source (6.1.*15*-1~bpo11+
Dear maintainers,
I have a problem with inconsistency of linux kernel related packages in
bullseye-backports repository:
linux-image-amd64 (6.1.*12*-1~bpo11+1)
linux-source (6.1.*15*-1~bpo11+1)
linux-config-6.1 (6.1.*15*-1~bpo11+1 and others)
Since the package linux-source-6.1_6.1.12-1~bpo11
Package: firmware-ath9k-htc
Version: 1.4.0-108-gd856466+dfsg1-1.2
Severity: grave
Tags: d-i
X-Debbugs-Cc: b...@debian.org, debian-b...@lists.debian.org,
debian-kernel@lists.debian.org
Hi,
While there have been some efforts around moving files between packages,
that's still insuffi
Hi,
Here's an update regarding firmware packages vs. non-free-firmware. I'm
extending the list of recipients a little; feel free to let me know if
you spot packages/teams that I would have missed!
Cyril Brulebois (2023-01-17):
> For this first round, I've checked on am
Your message dated Thu, 19 Jan 2023 14:12:50 +0100
with message-id <2632028.CedTxiVJjX@prancing-pony>
and subject line Re: linux-headers: dpkg-buildpackage -us -uc crashes while
trying to create rt packages
has caused the Debian Bug report #1029159,
regarding linux-headers: dpkg-buildpacka
an.org/debian-boot/2022/10/msg00044.html
>
> This mail is about moving packages from non-free to non-free-firmware,
> which will make it possible to install firmware packages (and configure
> apt to keep them up-to-date) from non-free-firmware without enabling
> non-free as a whole.
Hi folks,
First off: sorry I haven't been able to work on this sooner. For some
context, you can check the notes for the meeting I had with Steve
after the GR result was published:
https://lists.debian.org/debian-boot/2022/10/msg00044.html
This mail is about moving packages from non-fr
For what it's worth, I've done exactly that (installed the entire
suite of firmware packages from the testing repo) and as best I can
tell it has cured the problem I was having. Specifically after some
period of time of the laptop being up, the fan would speed up from
~2200RPM to ~3600
Then that is what I will do, thank you!
On Wed, Apr 20, 2022 at 1:41 PM Diederik de Haas wrote:
>
> On Wednesday, 20 April 2022 16:05:24 CEST Kevin P. Fleming wrote:
> > If it's not possible for the firmware packages to be included in the
> > backports repo then I can conf
On Wednesday, 20 April 2022 16:05:24 CEST Kevin P. Fleming wrote:
> If it's not possible for the firmware packages to be included in the
> backports repo then I can configure my system to grab them from
> 'testing', although at that point there may not be any value in usi
iGPU, it complains
that it can't find the firmware it is expecting. This is because the
kernel is in the backports repo, but the firmware packages are not.
If it's not possible for the firmware packages to be included in the
backports repo then I can configure my system to grab the
Hi Felix,
On Mon, Mar 14, 2022 at 10:33:22AM +, Moessbauer, Felix wrote:
> In general I agree, but here the situation is a bit different:
> The dependency to the host compiler (e.g. arm64) is too narrow.
Wrong. It certainly is not and beyond that, this aspect is not weakened.
It still require
Hi Helmut,
> From: Helmut Grohne
> Sent: Friday, March 11, 2022 2:49 PM
>
> Hi,
>
> On Thu, Mar 10, 2022 at 02:13:34PM +, Moessbauer, Felix wrote:
> > Many thanks for the patch.
> > I just (manually) backported that to Debian bullseye, tested it for arm64
> > and it
> worked like a charm.
Hi,
On Thu, Mar 10, 2022 at 02:13:34PM +, Moessbauer, Felix wrote:
> Many thanks for the patch.
> I just (manually) backported that to Debian bullseye, tested it for arm64 and
> it worked like a charm.
Can we please stop piling up workarounds and instead fix this once and
for all?
I see us
ght... thanks for the hint.
I just mixed that up, because the terminology in the "embedded world" (e.g.
yocto) is different (target=GNU host, host=GNU build).
>
> > The linux-headers packages cannot be co-installed due to the not co-
> installable cpp- packages.
> >
>
debian.org
> Subject: Re: Dependencies of linux-headers- packages
>
> On Thu, 2022-03-03 at 11:13 +, Moessbauer, Felix wrote:
> > Hi,
> >
> > the kernel header packages have a dependency to c/c++ compilers.
> > E.g. the "linux-headers-5.10.0-10-arm64"
Hi Felix,
Quoting Moessbauer, Felix (2022-03-10 11:02:44)
> > You cannot add :native to runtime dependencies. The :native qualifier only
> > makes sense for build dependencies. See
> > https://wiki.ubuntu.com/MultiarchCross
> >
> > You can find the answer to your question in this thread:
> >
> > E
On Thu, 2022-03-03 at 11:13 +, Moessbauer, Felix wrote:
> Hi,
>
> the kernel header packages have a dependency to c/c++ compilers.
> E.g. the "linux-headers-5.10.0-10-arm64" package depends on gcc-
> 10:arm64 -> cpp-10:arm64 (on bullseye).
>
> This bec
Hi Felix,
Quoting Moessbauer, Felix (2022-03-03 12:13:34)
> the kernel header packages have a dependency to c/c++ compilers. E.g. the
> "linux-headers-5.10.0-10-arm64" package depends on gcc-10:arm64 ->
> cpp-10:arm64 (on bullseye).
>
> This becomes an issue when cr
Hi,
the kernel header packages have a dependency to c/c++ compilers.
E.g. the "linux-headers-5.10.0-10-arm64" package depends on gcc-10:arm64 ->
cpp-10:arm64 (on bullseye).
This becomes an issue when cross-compiling kernel modules for other target
architectures:
The linux-hea
Your message dated Mon, 15 Nov 2021 10:00:20 +
with message-id
and subject line Bug#995466: fixed in linux 5.15.2-1~exp1
has caused the Debian Bug report #995466,
regarding linux-image-rt-amd64: Appears in "Obsolete and Locally Created
Packages" on aptitude
to be marked as done.
Hi,
On Oct 01 2021, Salvatore Bonaccorso wrote:
> > Now I tried to reinstall it and it says that a source to that download
> > version can't be found. There are newer versions of kernel available,
> > but no "preemption real time" patches set.
>
> Yes that's correct. The reason is that the rt fe
Hi,
On Fri, Oct 01, 2021 at 12:24:01PM -0300, Alexandre Lymberopoulos wrote:
> Package: linux-image-rt-amd64
> Version: 5.10.46-4
> Severity: normal
>
> Dear Maintainer,
>
> In aptitude this package appears in "Obsolete and Locally Created
> Packages", as w
1 - 100 of 915 matches
Mail list logo
