I see that this dependency is persisting in the new BPO release of
linux-headers 6.7.12, and it still causes significant trouble for me on my
build system.
I still can't understand what problem it's supposed to be fixing. Was there
ever an original bug report indicating the issue?
Colm
e precise meaning of "significant functionality" in
the Debian policy.
Colm
On Tue, 2 Apr 2024 at 17:57, Colm Buckley wrote:
> Please explain. I am really sorry to be dragging this discussion out, but
> I honestly think there is some information I'm missing. Please tell me what
both image and headers packages. Users who
regularly build new modules should be encouraged to install this package
and have it pull in suitable versions of both headers and image.
Is this correct, Bastian? I'm sorry for taking so long to understand what
problem was being addressed here.
Colm
--
Colm Buckley | c...@tuatha.org
Control: reopen 1064976
My apologies for the ping-pong; I do want to keep this open until the
discussion has completed. I will set out my thoughts below. I'm afraid this
is fairly long.
A brief history of this issue: in December 2023, the control file for
linux-headers-* was altered to include a
Package: linux-headers-amd64
Version: 6.6.13-1~bpo12+1
Followup-For: Bug #1064976
X-Debbugs-Cc: c...@tuatha.org
Can I suggest in the interim that Depends: be replaced with Recommends:
or Suggests: given that most installations won't actually need the image
package?
Colm
Hey folks -
I see that linux-headers-* has been promoted to 6.6 in the BPO channel, but
this dependency is still in place.
Is it really the case that we want to drag in the image binaries and other
machinery as a dependency for a source package like linux-headers.
I feel that the BPF use case shou
As per the discussion in
https://salsa.debian.org/kernel-team/linux/-/merge_requests/1005 - once
vmlinux.h is included with linux-headers, the warning about cmd_btf_ko etc.
should be harmless, as that file should already be available (ie: there's
no need to generate it again as part of kernel build
On Thu, 29 Feb 2024 13:38:12 +0100 Bastian Blank wrote:
> On Thu, Feb 29, 2024 at 12:12:21PM +, Luca Boccassi wrote:
> > With the new vmlinux.h shipped in the headers package, the BTF case
> > should be covered.
>
> The relevant code in Linux is:
>
> | quiet_cmd_btf_ko = BTF [M] $@
> | c
ges
wouldn't even run on this build server).
Colm
On Thu 29 Feb 2024, 11:03 Colm Buckley, wrote:
> Why was this never the case before? And can you be more precise about what
> "stuff" is missing? Is there a previous bug report I can reference?
>
> DKMS shou
sponding images.
Colm
On Thu 29 Feb 2024, 10:31 Bastian Blank, wrote:
> Control: tags -1 wontfix
>
> On Wed, Feb 28, 2024 at 05:19:39PM +, Colm Buckley wrote:
> > The linux-headers packages for kernel version 6.6 seem to depend on the
> corresponding
> > linux-image p
Some previous versions, for contrast:
% apt-cache depends linux-headers-6.5.0-0.deb12.4-amd64
linux-headers-6.5.0-0.deb12.4-amd64
Depends: linux-headers-6.5.0-0.deb12.4-common
Depends: linux-kbuild-6.5.0-0.deb12.4
Depends: linux-compiler-gcc-12-x86
% apt-cache depends linux-headers-6.1.0-18
Package: linux-headers-6.6.13+bpo-amd64
Severity: normal
X-Debbugs-Cc: c...@tuatha.org
Dear Maintainer,
The linux-headers packages for kernel version 6.6 seem to depend on the
corresponding
linux-image packages, but I believe that this should not be the case (and was
not the
case in previous ve
> Pkg-zfsonlinux-devel mailing list
> pkg-zfsonlinux-de...@alioth-lists.debian.net
>
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-zfsonlinux-devel
>
--
Colm Buckley | c...@tuatha.org
Package: libcurl3-gnutls
Version: 7.74.0-1.2~bpo10+1
Severity: important
Dear Maintainer,
This bug - https://github.com/curl/curl/issues/6825 - is possibly the
underlying cause of #831756 and #987187. Given the importance of
the git workflow in particular, I'd like to request that you consider
pa
Package: raspi-firmware
Version: 1.20200601-3~bpo10+1
Severity: normal
Tags: patch
Dear Maintainer,
The /etc/kernel/postinst.d/z50-raspi-firmware script which copies the kernel
and initrd to /boot/firmware, fails to ignore any old initrds which were renamed
by DKMS (usually of the form initrd.img
and it considers that particular situation
> not an error. Then you could also remove the "|| true" again which has
> potential of hiding errors where it should not.
>
> Christoph
> ___
> Pkg-zfsonlinux-devel mailing list
>
sonlinux-de...@alioth-lists.debian.net
>
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-zfsonlinux-devel
--
Colm Buckley | c...@tuatha.org
Package: systemd
Version: 246.4-1~bpo10+1
Followup-For: Bug #969599
Hey folks -
I had a productive conversation with one of the upstream authors at
https://github.com/systemd/systemd/issues/16719;
we think we have found the root cause of this issue. A new version of the
upstream PR is being mer
The PR referenced earlier does ameliorate the issue; however I don't think
it's a complete fix, as there are worrying messages in the debug log, and
there is still nonzero packet loss. I will follow up with upstream.
I would encourage Debian users to remain with systemd 245, and not to
migrate thi
That PR patches cleanly against the Debian source; so I'm building a local
package version now to test.
Will follow up here and with upstream.
Colm
On Sat, 5 Sep 2020 at 20:48, Michael Biebl wrote:
> Am 05.09.20 um 21:31 schrieb Colm Buckley:
> > Package: systemd
> > Vers
Package: systemd
Version: 246.4-1~bpo10+1
Severity: important
Tags: ipv6
Dear Maintainer,
I see 0.8.1 in buster-bpo now. Thank you!
, Nov 20, 2019 at 8:05 PM Colm Buckley wrote:
> I configure it using the command line; I have found some of the new
> features and bugfixes in 0.7 to be useful for my setup, so I've been
> building a samizdat 0.7.2 package myself, which "seems to work". However, I
> onl
onfig_xxx
Colm
On Wed, Nov 20, 2019 at 8:00 PM Michael Biebl wrote:
> Am 20.11.19 um 20:57 schrieb Colm Buckley:
> > Hum. I can validate the operations of firewalld itself, but I don't use
> > either the applet or the config package.
>
> How exactly do you intend to us
Hum. I can validate the operations of firewalld itself, but I don't use
either the applet or the config package.
Colm
On Wed, Nov 20, 2019 at 6:55 PM Michael Biebl wrote:
> Am 20.11.19 um 19:45 schrieb Colm Buckley:
> > I feel that the answer is both yes and no. The *packaging*
details are taken care of.
Colm
On Wed, Nov 20, 2019 at 6:36 PM Michael Biebl wrote:
> Am 20.11.19 um 19:24 schrieb Colm Buckley:
> > @biebl - looks as though stable-bpo's nftables package tracks upstream
> > pretty closely; if https://github.com/firewalld/firewalld/issues
@biebl - looks as though stable-bpo's nftables package tracks upstream
pretty closely; if https://github.com/firewalld/firewalld/issues/540 is
resolved, would you consider looking at packaging 0.8.0 for backports?
Gerhard tells me that this is fixed in the latest upstream version -
1.7.3.3.
Can this be packaged for Debian shortly? I can look into an NMU if
necessary.
Colm
--
Colm Buckley / c...@tuatha.org / +353 87 2469146
Package: firewalld
Version: 0.7.1-1
Severity: wishlist
Dear Maintainer,
firewalld 0.7 introduces sufficient new capabilities that it would be great to
see
it more widely available in the stable distribution. I would like to suggest
that it be added to buster-backports.
It does not appear to hav
Package: src:linux
Version: 5.2.9-2
Severity: normal
Dear Maintainer,
This system is an Intel NUC with an onboard Intel I219-LM
Ethernet adapter (e1000e) and an additional dual Intel I210
Ethernet adapter (igb) connected via the onboard M.2 interface
(M.2 Dual Ethernet supplied by G2 Digital; I s
Package: src:linux
Version: 4.18.6-1~bpo9+1
Severity: important
Tags: upstream patch
Please see
https://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git/commit/?h=for-linus
- invalidating
filesystems can cause dentry table corruption leading to busy loop in kernel.
Easily tri
Per upstream; this seems to be a kernel bug which is fixed in 4.18.20.
Unclear whether the fix (1e9c75fb9c47a75a9aec0cd17db5f6dc36b58e00) can be
cherrypicked back to current stable / bpo kernels; investigating.
This is fixed by https://github.com/att/ast/pull/63/ - should be ok to pull
from upstream.
Colm
--
Colm Buckley / c...@tuatha.org / +353 87 2469146
... which is exactly what the patch does.
On Fri 19 Oct 2018, 18:45 Petter Reinholdtsen
>
> [Richard Laager]
> > The sysvinit scripts are already in the upstream tree and the released
> > tarballs. You can see them in the package's .orig.tar.gz in the
> > etc/init.d directory. The patch simply ca
Source: zfs-linux
Version: v0.7.11-1
Severity: important
Tags: upstream
Descendent filesystems which have out-of-tree mount points are not
correctly recovered on 'zfs send | zfs receive', leading to apparent
corruption of the mount table. With kernel 4.18, processes accessing
problematic parts of
In an ideal world, this need not be a problem; we typically see ZoL
releases supporting new kernels well before those kernels hit Debian
backports. Unfortunately, however, there is a chicken-and-egg problem; the
Debian package maintainers need to be confident that the zfs-linux packages
will work w
I don't wish to be rude - but there has been an unusually long period with
no developer activity regarding this package; and the developers' mailing
list seems to have been removed or reconfigured. Is everything in order?
Are more maintainers needed?
Colm
Package: zfsutils-linux
Version: 0.7.3-1
As 'zfs allow' now allows certain functions to be executed by any user, I
suggest a symbolic link from /usr/bin/zfs to /usr/sbin/{zfs, zpool} be
included.
ch in turn calls the current crontab generator, but it strikes me that
there might be a more elegant way.
Any takers?
Colm
--
Colm Buckley / c...@tuatha.org / +353 87 2469146
Package: openssh-server
Version: 1:3.9p1-2
Severity: wishlist
The high-performance patches from PSC
(http://www.psc.edu/networking/projects/hpn-ssh/) should be included as
part of standard SSH; these patches make an *enormous* difference when
transferring large quantities of data over a high-band
40 matches
Mail list logo
