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
> > > kernel release (see above), as both
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
> > > kernel release (see above), as both
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
> > > kernel release (see above), as both
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
> > > kernel release (see above), as both
On Thu, Oct 05, 2023 at 07:59:54AM -0600, Sam Hartman wrote:
> I think that's what you mean by the first-level error.
> If not, I'm still confused.
> In the second level error case you are talking about is:
No, the first level is always: but the new kernel does not work.
The second is: I need to
On Thu, Oct 05, 2023 at 07:59:54AM -0600, Sam Hartman wrote:
> I think that's what you mean by the first-level error.
> If not, I'm still confused.
> In the second level error case you are talking about is:
No, the first level is always: but the new kernel does not work.
The second is: I need to
On Thu, Oct 05, 2023 at 07:59:54AM -0600, Sam Hartman wrote:
> I think that's what you mean by the first-level error.
> If not, I'm still confused.
> In the second level error case you are talking about is:
No, the first level is always: but the new kernel does not work.
The second is: I need to
On Thu, Oct 05, 2023 at 07:59:54AM -0600, Sam Hartman wrote:
> I think that's what you mean by the first-level error.
> If not, I'm still confused.
> In the second level error case you are talking about is:
No, the first level is always: but the new kernel does not work.
The second is: I need to
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 d
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 d
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 d
[ 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
[ 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
[ 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
[ 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
On Thu, Oct 19, 2023 at 07:31:08PM +0200, Alexis CAMILLERI wrote:
> I suggest using grub-probe -t disk instead of grub-probe -t device.
> Disk param will return the disk name instead of the partition, so the sed
> command can be removed and raid device will work.
>
> local basedev=$(grub-probe -t
On Thu, Oct 19, 2023 at 07:31:08PM +0200, Alexis CAMILLERI wrote:
> I suggest using grub-probe -t disk instead of grub-probe -t device.
> Disk param will return the disk name instead of the partition, so the sed
> command can be removed and raid device will work.
>
> local basedev=$(grub-probe -t
On Thu, Oct 19, 2023 at 07:31:08PM +0200, Alexis CAMILLERI wrote:
> Installing grub on an i386 server with raid partitioning does not work
> because the script does not manage a raid mount for /boot, due to
>
On Thu, Oct 19, 2023 at 07:31:08PM +0200, Alexis CAMILLERI wrote:
> Installing grub on an i386 server with raid partitioning does not work
> because the script does not manage a raid mount for /boot, due to
>
Package: security-tracker
Severity: important
The security tracker currently uses the JSON feeds as linked from
https://nvd.nist.gov/vuln/data-feeds. Those data feeds will be retired
on December, 15th 2023, so in a bit more then two months. After that
the information will be only available via
Package: security-tracker
Severity: important
The security tracker currently uses the JSON feeds as linked from
https://nvd.nist.gov/vuln/data-feeds. Those data feeds will be retired
on December, 15th 2023, so in a bit more then two months. After that
the information will be only available via
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
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
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
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
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
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
Hi
On Sun, Sep 24, 2023 at 06:05:09PM +0200, Ben Hutchings wrote:
> > Multiple uploads of the same upstream version will have
> > the same package name, but those rarely happens.
> Those happen fairly often for urgent security updates.
We could encode that in the upstream version. Aka to have
Hi
On Sun, Sep 24, 2023 at 06:05:09PM +0200, Ben Hutchings wrote:
> > Multiple uploads of the same upstream version will have
> > the same package name, but those rarely happens.
> Those happen fairly often for urgent security updates.
We could encode that in the upstream version. Aka to have
Hi
On Sun, Sep 24, 2023 at 06:05:09PM +0200, Ben Hutchings wrote:
> > Multiple uploads of the same upstream version will have
> > the same package name, but those rarely happens.
> Those happen fairly often for urgent security updates.
We could encode that in the upstream version. Aka to have
Hi
On Sun, Sep 24, 2023 at 06:05:09PM +0200, Ben Hutchings wrote:
> > Multiple uploads of the same upstream version will have
> > the same package name, but those rarely happens.
> Those happen fairly often for urgent security updates.
We could encode that in the upstream version. Aka to have
Hi
On Sun, Sep 24, 2023 at 06:05:09PM +0200, Ben Hutchings wrote:
> > Multiple uploads of the same upstream version will have
> > the same package name, but those rarely happens.
> Those happen fairly often for urgent security updates.
We could encode that in the upstream version. Aka to have
Hi
On Sun, Sep 24, 2023 at 06:05:09PM +0200, Ben Hutchings wrote:
> > Multiple uploads of the same upstream version will have
> > the same package name, but those rarely happens.
> Those happen fairly often for urgent security updates.
We could encode that in the upstream version. Aka to have
On Tue, Oct 03, 2023 at 03:00:53PM -0500, Robert Nelson wrote:
> On Tue, Oct 3, 2023 at 2:54 PM Adrian Bunk wrote:
> > How will the user get the headers matching this previously-used kernel
> > that are required until we provide a kernel with the regression fixed?
The same as now: nowhere,
On Tue, Oct 03, 2023 at 03:00:53PM -0500, Robert Nelson wrote:
> On Tue, Oct 3, 2023 at 2:54 PM Adrian Bunk wrote:
> > How will the user get the headers matching this previously-used kernel
> > that are required until we provide a kernel with the regression fixed?
The same as now: nowhere,
On Tue, Oct 03, 2023 at 03:00:53PM -0500, Robert Nelson wrote:
> On Tue, Oct 3, 2023 at 2:54 PM Adrian Bunk wrote:
> > How will the user get the headers matching this previously-used kernel
> > that are required until we provide a kernel with the regression fixed?
The same as now: nowhere,
On Tue, Oct 03, 2023 at 03:00:53PM -0500, Robert Nelson wrote:
> On Tue, Oct 3, 2023 at 2:54 PM Adrian Bunk wrote:
> > How will the user get the headers matching this previously-used kernel
> > that are required until we provide a kernel with the regression fixed?
The same as now: nowhere,
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 the way
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 the way
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 the way
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 the way
Hi Sam
On Tue, Oct 03, 2023 at 08:31:57AM -0600, Sam Hartman wrote:
> I still think it would help if you would work more on articulating what
> problem you are trying to solve with the linux-headers versioning
> change. I have read multiple versions of this proposal, and your
> follow-ups, and I
Hi Sam
On Tue, Oct 03, 2023 at 08:31:57AM -0600, Sam Hartman wrote:
> I still think it would help if you would work more on articulating what
> problem you are trying to solve with the linux-headers versioning
> change. I have read multiple versions of this proposal, and your
> follow-ups, and I
Hi Sam
On Tue, Oct 03, 2023 at 08:31:57AM -0600, Sam Hartman wrote:
> I still think it would help if you would work more on articulating what
> problem you are trying to solve with the linux-headers versioning
> change. I have read multiple versions of this proposal, and your
> follow-ups, and I
Hi Sam
On Tue, Oct 03, 2023 at 08:31:57AM -0600, Sam Hartman wrote:
> I still think it would help if you would work more on articulating what
> problem you are trying to solve with the linux-headers versioning
> change. I have read multiple versions of this proposal, and your
> follow-ups, and I
Hi Michel
On Sun, Oct 01, 2023 at 12:19:22PM +0200, Michel Verdier wrote:
> On 2023-10-01, Bastian Blank wrote:
> > Ah, here lays the missconception. No, the 6.6 ones are not removed. Why
> > should they be? The system knows it can't rebuild them.
> As the old kernel dri
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
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
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
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
On Sun, Sep 24, 2023 at 04:09:31PM -0700, Noah Meyerhans wrote:
> I agree that it would be best to design something more cloud-oriented.
> However, if there's an existing infrastructure that can be moved as a
> "lift & shift" into AWS now, with architectural refactoring happening
> later, that's
On Sun, Sep 24, 2023 at 09:21:16PM +0200, Michael Kesper wrote:
> Be aware that AWS S3, while featuring negligible staorage cost,
> can become very expensive if ever the need arises to get the data back
> out of AWS:
>
Hi Ben
On Sun, Sep 24, 2023 at 06:05:09PM +0200, Ben Hutchings wrote:
> On Sun, 2023-09-24 at 15:01 +0200, Bastian Blank wrote:
> > The same upstream version in testing and backports will have the same
> > package name.
> This is not OK, because they will be incompatibl
Hi Ben
On Sun, Sep 24, 2023 at 06:05:09PM +0200, Ben Hutchings wrote:
> On Sun, 2023-09-24 at 15:01 +0200, Bastian Blank wrote:
> > The same upstream version in testing and backports will have the same
> > package name.
> This is not OK, because they will be incompatibl
Hi Ben
On Sun, Sep 24, 2023 at 06:05:09PM +0200, Ben Hutchings wrote:
> On Sun, 2023-09-24 at 15:01 +0200, Bastian Blank wrote:
> > The same upstream version in testing and backports will have the same
> > package name.
> This is not OK, because they will be incompatibl
Hi Ben
On Sun, Sep 24, 2023 at 06:05:09PM +0200, Ben Hutchings wrote:
> On Sun, 2023-09-24 at 15:01 +0200, Bastian Blank wrote:
> > The same upstream version in testing and backports will have the same
> > package name.
> This is not OK, because they will be incompatibl
Hi Ben
On Sun, Sep 24, 2023 at 06:05:09PM +0200, Ben Hutchings wrote:
> On Sun, 2023-09-24 at 15:01 +0200, Bastian Blank wrote:
> > The same upstream version in testing and backports will have the same
> > package name.
> This is not OK, because they will be incompatibl
Hi Ben
On Sun, Sep 24, 2023 at 06:05:09PM +0200, Ben Hutchings wrote:
> On Sun, 2023-09-24 at 15:01 +0200, Bastian Blank wrote:
> > The same upstream version in testing and backports will have the same
> > package name.
> This is not OK, because they will be incompatibl
Hi Andreas
On Sun, Sep 24, 2023 at 11:10:36PM +0200, Andreas Beckmann wrote:
> On 24/09/2023 15.01, Bastian Blank wrote:
> > ## Kernel modules will be signed with an ephemeral key
> >
> > The modules will not longer be signed using the Secure Boot CA like the
> &
Hi Andreas
On Sun, Sep 24, 2023 at 11:10:36PM +0200, Andreas Beckmann wrote:
> On 24/09/2023 15.01, Bastian Blank wrote:
> > ## Kernel modules will be signed with an ephemeral key
> >
> > The modules will not longer be signed using the Secure Boot CA like the
> &
Hi Andreas
On Sun, Sep 24, 2023 at 11:10:36PM +0200, Andreas Beckmann wrote:
> On 24/09/2023 15.01, Bastian Blank wrote:
> > ## Kernel modules will be signed with an ephemeral key
> >
> > The modules will not longer be signed using the Secure Boot CA like the
> &
Hi Andreas
On Sun, Sep 24, 2023 at 11:10:36PM +0200, Andreas Beckmann wrote:
> On 24/09/2023 15.01, Bastian Blank wrote:
> > ## Kernel modules will be signed with an ephemeral key
> >
> > The modules will not longer be signed using the Secure Boot CA like the
> &
Hi folks
Debian currently does Secure Boot signing using a shim chained to the
Microsoft key. This use requires that we follow certain rules. And one
of the recent changes to those rules state that our method of signing
kernel modules also with the same key will not be allowed anymore. Some
Hi folks
Debian currently does Secure Boot signing using a shim chained to the
Microsoft key. This use requires that we follow certain rules. And one
of the recent changes to those rules state that our method of signing
kernel modules also with the same key will not be allowed anymore. Some
Hi folks
Debian currently does Secure Boot signing using a shim chained to the
Microsoft key. This use requires that we follow certain rules. And one
of the recent changes to those rules state that our method of signing
kernel modules also with the same key will not be allowed anymore. Some
Hi folks
Debian currently does Secure Boot signing using a shim chained to the
Microsoft key. This use requires that we follow certain rules. And one
of the recent changes to those rules state that our method of signing
kernel modules also with the same key will not be allowed anymore. Some
Hi folks
Debian currently does Secure Boot signing using a shim chained to the
Microsoft key. This use requires that we follow certain rules. And one
of the recent changes to those rules state that our method of signing
kernel modules also with the same key will not be allowed anymore. Some
Hi folks
Debian currently does Secure Boot signing using a shim chained to the
Microsoft key. This use requires that we follow certain rules. And one
of the recent changes to those rules state that our method of signing
kernel modules also with the same key will not be allowed anymore. Some
Hi
On Wed, Sep 20, 2023 at 10:48:12AM +, Sathish Mathimaran wrote:
> I was testing out the Debian 12 release and found that the sources.list file
> is different from how it used to be in Debian 11. Our team has written
> automations around the sources.list to list the security packages and
Hi Lucas
On Fri, Sep 22, 2023 at 08:42:10AM +0200, Lucas Nussbaum wrote:
> Could we use the Debian AWS account to host that service?
I would assume that a service like snapshot would be within the scope
for our AWS usage. Noah?
> It
Hi Lucas
On Fri, Sep 22, 2023 at 08:42:10AM +0200, Lucas Nussbaum wrote:
> Could we use the Debian AWS account to host that service?
I would assume that a service like snapshot would be within the scope
for our AWS usage. Noah?
> It
Hi Lucas
On Fri, Sep 22, 2023 at 08:42:10AM +0200, Lucas Nussbaum wrote:
> Could we use the Debian AWS account to host that service?
I would assume that a service like snapshot would be within the scope
for our AWS usage. Noah?
> It
Control: tag -1 moreinfo
Hi Klaus
On Fri, Sep 15, 2023 at 10:18:55PM +0100, Klaus Ethgen wrote:
> Booting with the new kernel makes the display (1920x1200) heavily
> flckering, diplaying two times the same one above the other and only
> displaying about 1/4 of the screen smashed together on the
Control: tag -1 moreinfo
Hi Klaus
On Fri, Sep 15, 2023 at 10:18:55PM +0100, Klaus Ethgen wrote:
> Booting with the new kernel makes the display (1920x1200) heavily
> flckering, diplaying two times the same one above the other and only
> displaying about 1/4 of the screen smashed together on the
On Mon, Sep 11, 2023 at 03:43:05PM -0700, Ross Vandegrift wrote:
> Our next team meeting is scheduled for 2023-09-13 20:00 UTC. We'll be
> on jitsi: https://jitsi.debian.social/DebianCloudMeeting20230913.
I most likely won't be able to attend.
Regards,
Bastian
--
Superior ability breeds
On Mon, Sep 11, 2023 at 01:06:06PM +0100, Luca Boccassi wrote:
> As far as I understand dpkg's conffile machinery should recognize if
> you changed anything, and leave it in place. Upstream moved the
> default ones to /usr, so we just follow what they do.
Actually using rm_conffile is wrong.
On Mon, Sep 11, 2023 at 01:06:06PM +0100, Luca Boccassi wrote:
> As far as I understand dpkg's conffile machinery should recognize if
> you changed anything, and leave it in place. Upstream moved the
> default ones to /usr, so we just follow what they do.
Actually using rm_conffile is wrong.
Hi
On Sat, Sep 09, 2023 at 11:13:56AM +0200, Paul Gevers wrote:
> If we're now reaching the final limit and if it was foreseeable that we
> would reach that limit, then yes it would have made sense to drop armel
> *before* the bookworm release, but alas. If the kernel team can't support
> the
Hi
On Sat, Sep 09, 2023 at 11:13:56AM +0200, Paul Gevers wrote:
> If we're now reaching the final limit and if it was foreseeable that we
> would reach that limit, then yes it would have made sense to drop armel
> *before* the bookworm release, but alas. If the kernel team can't support
> the
Hi
On Sat, Sep 09, 2023 at 11:13:56AM +0200, Paul Gevers wrote:
> If we're now reaching the final limit and if it was foreseeable that we
> would reach that limit, then yes it would have made sense to drop armel
> *before* the bookworm release, but alas. If the kernel team can't support
> the
On Thu, Sep 07, 2023 at 05:50:41PM +0200, Bastian Blank wrote:
> When the following commit is includes:
Just for background information: cloud-init depends on isc-dhcp-client
because it uses the dhclient binary. So removing that as dependency is
not feasible right now.
Bastian
--
Fascinat
On Thu, Sep 07, 2023 at 05:50:41PM +0200, Bastian Blank wrote:
> When the following commit is includes:
Just for background information: cloud-init depends on isc-dhcp-client
because it uses the dhclient binary. So removing that as dependency is
not feasible right now.
Bastian
--
Fascinat
On Thu, Sep 07, 2023 at 05:36:06PM +0200, Michael Prokop wrote:
> Please consider adapting the Depends for the new cloud-init version
> in Debian accordingly, so one can use e.g. cloud-init with udhcpc
> (which also allows co-installation next to dhcpcd), but without
> having to also have
On Thu, Sep 07, 2023 at 05:36:06PM +0200, Michael Prokop wrote:
> Please consider adapting the Depends for the new cloud-init version
> in Debian accordingly, so one can use e.g. cloud-init with udhcpc
> (which also allows co-installation next to dhcpcd), but without
> having to also have
.
While the stock driver in 6.1 kind of works, it is not really usable for
end user workloads.
On Tue, May 02, 2023 at 01:38:40PM +0200, Bastian Blank wrote:
> Microsoft asked to backport the jumbo frame support in the Microsoft
> Azure Network Adapter from current master. The c
.
While the stock driver in 6.1 kind of works, it is not really usable for
end user workloads.
On Tue, May 02, 2023 at 01:38:40PM +0200, Bastian Blank wrote:
> Microsoft asked to backport the jumbo frame support in the Microsoft
> Azure Network Adapter from current master. The c
Hi Laurent
On Sun, Sep 03, 2023 at 11:16:03AM +0200, Laurent BRULET wrote:
> It's still not entirely clear to me, whether this transient issue (where
> linux-
> image-amd64 can be installed while the corresponding linux-headers-amd64
> can't)
> is a "standard case" for backports, or it is an
Hi Laurent
On Sun, Sep 03, 2023 at 11:16:03AM +0200, Laurent BRULET wrote:
> It's still not entirely clear to me, whether this transient issue (where
> linux-
> image-amd64 can be installed while the corresponding linux-headers-amd64
> can't)
> is a "standard case" for backports, or it is an
On Mon, Jul 24, 2023 at 10:36:47PM +0300, Adrian Bunk wrote:
> A policy question is that it might be a good idea to rename the packages
> when publishing a regression update for a DSA, that's the only place I see
> where this problem might otherwise reach production systems.
Adding another
On Sun, Jul 23, 2023 at 09:44:40AM +0200, Bastian Blank wrote:
> After a lot of thinking, maybe a solution that allows for incompatible
> package updates without renames would be more useful. Something like:
>
> We uncouple the package names and ABI. The ABI will include the
> c
On Sun, Sep 03, 2023 at 10:02:16AM +0200, Johannes Schauer Marin Rodrigues
wrote:
> so rebootstrap uses the stage1 build profile which should be building headers
> only. Still it fails with the same error I've reported for a full build:
The stage1 profile is deprecated according to the
On Sun, Sep 03, 2023 at 10:02:16AM +0200, Johannes Schauer Marin Rodrigues
wrote:
> so rebootstrap uses the stage1 build profile which should be building headers
> only. Still it fails with the same error I've reported for a full build:
The stage1 profile is deprecated according to the
On Fri, Sep 01, 2023 at 09:15:50AM +0200, Johannes Schauer Marin Rodrigues
wrote:
> Helmut informed me that bugs that break bootstrap (rebootstrap fails to
> cross-build linux-libc-dev because of this bug) are usually filed with serious
> severity, so doing that now. Thanks!
Cross-building
On Fri, Sep 01, 2023 at 09:15:50AM +0200, Johannes Schauer Marin Rodrigues
wrote:
> Helmut informed me that bugs that break bootstrap (rebootstrap fails to
> cross-build linux-libc-dev because of this bug) are usually filed with serious
> severity, so doing that now. Thanks!
Cross-building
On Fri, Sep 01, 2023 at 08:36:53AM +0200, Johannes Schauer Marin Rodrigues
wrote:
> diff -Nru linux-6.4.11/debian/rules.real linux-6.4.11/debian/rules.real
> --- linux-6.4.11/debian/rules.real 2023-08-17 09:05:43.0 +0200
> +++ linux-6.4.11/debian/rules.real 2023-09-01
On Fri, Sep 01, 2023 at 08:36:53AM +0200, Johannes Schauer Marin Rodrigues
wrote:
> diff -Nru linux-6.4.11/debian/rules.real linux-6.4.11/debian/rules.real
> --- linux-6.4.11/debian/rules.real 2023-08-17 09:05:43.0 +0200
> +++ linux-6.4.11/debian/rules.real 2023-09-01
Control: severity -1 normal
On Fri, Sep 01, 2023 at 09:15:50AM +0200, Johannes Schauer Marin Rodrigues
wrote:
> Helmut informed me that bugs that break bootstrap (rebootstrap fails to
> cross-build linux-libc-dev because of this bug) are usually filed with serious
> severity, so doing that now.
Control: severity -1 normal
On Fri, Sep 01, 2023 at 09:15:50AM +0200, Johannes Schauer Marin Rodrigues
wrote:
> Helmut informed me that bugs that break bootstrap (rebootstrap fails to
> cross-build linux-libc-dev because of this bug) are usually filed with serious
> severity, so doing that now.
Control: severity -1 normal
On Fri, Sep 01, 2023 at 09:15:50AM +0200, Johannes Schauer Marin Rodrigues
wrote:
> Helmut informed me that bugs that break bootstrap (rebootstrap fails to
> cross-build linux-libc-dev because of this bug) are usually filed with serious
> severity, so doing that now.
Control: tags -1 moreinfo
Hi Dmitry
On Wed, Aug 23, 2023 at 08:10:17PM +0300, Dmitry Baryshkov wrote:
> The linux-libc-dev package provides only a limited set of uAPI headers.
> For example, scsi, drm, video, etc. headers are missing from the
> package.
scsi headers are shipped by libc6-dev,
301 - 400 of 14586 matches
Mail list logo
