Marc Haber wrote:
> [37/5247]mh@swivel:~/git/zg2dns $ grep -E 'class|import' get-root zg2dns/*
> get-root:from zg2dns.rootdata import DNSRootDataParser
> zg2dns/query.py:from rootdata import DNSRootDataParser
> zg2dns/query.py:class Zg2DNSQuery:
> zg2dns/rootdata.py:class DNSRootDataParser:
On Tue, Apr 23, 2024 at 09:06:47AM +0200, Bastian Blank wrote:
> On Tue, Apr 23, 2024 at 08:12:28AM +0200, bouv...@buxtehude.debian.org wrote:
> > FWIW, and following Jacob Rhoads' remark, we are also running CrowdStrike
> > Falcon Sensor on all our machines, virtuals servers an
On Tue, Apr 23, 2024 at 09:06:47AM +0200, Bastian Blank wrote:
> On Tue, Apr 23, 2024 at 08:12:28AM +0200, bouv...@buxtehude.debian.org wrote:
> > FWIW, and following Jacob Rhoads' remark, we are also running CrowdStrike
> > Falcon Sensor on all our machines, virtuals servers an
Control: reassign -1 src:linux
Control: severity -1 normal
Control: tags -1 moreinfo
On Mon, Apr 22, 2024 at 09:12:59AM +0200, bouv...@buxtehude.debian.org wrote:
> Something seems wrong in 6.1.0-20, but it is not immediately wrong: it waits
> until some sort of trigger. After that, rebooting
Control: reassign -1 src:linux
Control: severity -1 normal
Control: tags -1 moreinfo
On Mon, Apr 22, 2024 at 09:12:59AM +0200, bouv...@buxtehude.debian.org wrote:
> Something seems wrong in 6.1.0-20, but it is not immediately wrong: it waits
> until some sort of trigger. After that, rebooting
Control: reassign -1 src:linux
Control: severity -1 normal
Control: tags -1 moreinfo
On Mon, Apr 22, 2024 at 09:12:59AM +0200, bouv...@buxtehude.debian.org wrote:
> Something seems wrong in 6.1.0-20, but it is not immediately wrong: it waits
> until some sort of trigger. After that, rebooting
Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: s...@packages.debian.org, bdr...@debian.org, on...@debian.org,
wa...@debian.org
Control: affects -1 + src:salt
User: ftp.debian@packages.debian.org
Usertags: remove
Please remove package salt. It was not released in stable. No response
Package: python-glance-store
Version: 4.7.0-2
Severity: serious
python-glance-store build-depends on deprecated package python3-boto.
See #1058652
Also it seems to not build at all:
| dpkg-buildpackage: info: source package python-glance-store
| dpkg-buildpackage: info: source version 4.7.0-2
|
Package: python-glance-store
Version: 4.7.0-2
Severity: serious
python-glance-store build-depends on deprecated package python3-boto.
See #1058652
Also it seems to not build at all:
| dpkg-buildpackage: info: source package python-glance-store
| dpkg-buildpackage: info: source version 4.7.0-2
|
On Mon, Apr 15, 2024 at 11:45:33AM -0700, Noah Meyerhans wrote:
> The Debian cloud team also builds and ships images with buster-backports
> enabled, and will need to deal with this change.
I just disabled it:
https://salsa.debian.org/cloud-team/debian-cloud-images/-/merge_requests/403
Bastian
On Tue, Apr 09, 2024 at 06:37:23PM +, Holger Levsen wrote:
> - I very much dislike git-buildpackage, too much magic. I try to avoid it
> where I can.
We still like those VCS-in-VCS workflows over everything else. Those
debian/patches, where you need to call something special and can't just
On Mon, Apr 08, 2024 at 04:32:37PM -0700, Ross Vandegrift wrote:
> Apologies, I didn't pay enough attention. Bastian- would 4/18 work?
Sure.
Bastian
--
Emotions are alien to me. I'm a scientist.
-- Spock, "This Side of Paradise", stardate 3417.3
On Thu, Apr 04, 2024 at 11:24:22AM -0700, Ross Vandegrift wrote:
> Tues 4/9, Thurs 4/11, or Fri 4/12 @ 20:00 UTC would work with me.
I could do thursday and friday.
Bastian
--
Sometimes a man will tell his bartender things he'll never tell his doctor.
-- Dr. Phillip Boyce, "The
On Tue, Apr 02, 2024 at 05:38:01PM +0100, Colm Buckley wrote:
> ... but the proposed dependency wouldn't address that, right?
Actually it does. It ties all packages together with = dependencies.
For an upgrade, all packages need to be unpacked first and only then the
maintainer scripts can run.
Hi
On Tue, Apr 02, 2024 at 03:26:32PM +, Colm Buckley wrote:
> This is a real problem - however I think it is *not* one which the change
> in dependency addresses; even if -headers-Y depends on -image-Y, step 3
> above will proceed without any conflicts (because the reverse dependency is
>
Hi
On Tue, Apr 02, 2024 at 03:26:32PM +, Colm Buckley wrote:
> This is a real problem - however I think it is *not* one which the change
> in dependency addresses; even if -headers-Y depends on -image-Y, step 3
> above will proceed without any conflicts (because the reverse dependency is
>
On Tue, Apr 02, 2024 at 03:59:25PM +0100, Luca Boccassi wrote:
> Let's look at this the other way around: if there was no dependency, in
> what scenario would things break and how?
- linux-headers-bla and linux-image-bla are installed
- linux-image-bla is uipgraded
- no modules will be built,
On Tue, Apr 02, 2024 at 03:59:25PM +0100, Luca Boccassi wrote:
> Let's look at this the other way around: if there was no dependency, in
> what scenario would things break and how?
- linux-headers-bla and linux-image-bla are installed
- linux-image-bla is uipgraded
- no modules will be built,
On Mon, Apr 01, 2024 at 09:25:40PM +, Luca Boccassi wrote:
> Why do dkms modules need the image installed to be built? At the very
> least they didn't use to, the headers were enough last time I had to
> deal with that stuff for the nvidia drivers
dkms is used to build modules for the kernel
On Mon, Apr 01, 2024 at 09:25:40PM +, Luca Boccassi wrote:
> Why do dkms modules need the image installed to be built? At the very
> least they didn't use to, the headers were enough last time I had to
> deal with that stuff for the nvidia drivers
dkms is used to build modules for the kernel
On Mon, Apr 01, 2024 at 08:39:06PM +, Debian Bug Tracking System wrote:
> No. We need to make sure someone installing linux-image-bla and
> linux-headers-bla have the same version, so the modules are compatible.
Revisiting this bug, I might have been not explicit enough. This
dependency is
On Mon, Apr 01, 2024 at 08:39:06PM +, Debian Bug Tracking System wrote:
> No. We need to make sure someone installing linux-image-bla and
> linux-headers-bla have the same version, so the modules are compatible.
Revisiting this bug, I might have been not explicit enough. This
dependency is
Control: tags -1 wontfix
On Thu, Feb 29, 2024 at 01:38:12PM +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.
As said, this dependency is to m
Control: tags -1 wontfix
On Thu, Feb 29, 2024 at 01:38:12PM +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.
As said, this dependency is to m
On Mon, Apr 01, 2024 at 07:39:18PM +0200, Jonathan Carter wrote:
> As far as I know, this doesn't happen until after d-i asked the question "Do
> you want to use a network mirror?" and the user answered "Yes", in which
> case I think that would count as informed consent.
During build, not during
On Mon, Apr 01, 2024 at 06:36:30PM +0200, Vincent Bernat wrote:
> On 2024-04-01 12:44, Bastian Blank wrote:
> > So in the end you still need to manually review all the stuff that the
> > tarball contains extra to the git. And for that I don't see that it
> > actually giv
On Sat, Mar 30, 2024 at 12:44:35PM -0700, Ross Vandegrift wrote:
> Finally, apologies for not being able to do this myself - I still do not have
> my account setup for access to core machines.
Tasks related to this incident are tracked here:
On Sat, Mar 30, 2024 at 12:44:35PM -0700, Ross Vandegrift wrote:
> Finally, apologies for not being able to do this myself - I still do not have
> my account setup for access to core machines.
Tasks related to this incident are tracked here:
Hi
On Mon, Apr 01, 2024 at 12:40:51PM +0200, Ansgar wrote:
> For OpenSSH it might also be more convenient to use Webauthn, that is,
> the keys generated using `ssh-keygen -t ed25519-sk` or `-t ecdsa-sk`.
Also those key types allow two different uses. Persistent or
non-persistent keys differ
On Mon, Apr 01, 2024 at 12:03:48PM +0200, Bastian Blank wrote:
> On Mon, Apr 01, 2024 at 02:31:47AM +0200, gregor herrmann wrote:
> > That's not mutually exclusive. When adding an additional git remote
> > and using gbp-import-orig's --upstream-vcs-tag you get the best of
On Mon, Apr 01, 2024 at 02:31:47AM +0200, gregor herrmann wrote:
> That's not mutually exclusive. When adding an additional git remote
> and using gbp-import-orig's --upstream-vcs-tag you get the best of
> both worlds.
And this will error out if there are unexpected changes in the tarball?
How
Hi
On Sun, Mar 31, 2024 at 07:48:35PM +0300, Adrian Bunk wrote:
> > What we can do unilaterally is to disallow vendoring those files.
> These files are supposed to be vendored in release tarballs,
> the sane approach for getting rid of such vendored files would
> be to discourage tarball uploads
Hi
binNMU are known to not work on the signing side of the archive.
dpkg contains special handling for binNMU style versions. If it sees a
1-1+b1 as version, it will search some source files with version 1-1.
This means you can never properly have a source package with such a
version.
As the
Hi
binNMU are known to not work on the signing side of the archive.
dpkg contains special handling for binNMU style versions. If it sees a
1-1+b1 as version, it will search some source files with version 1-1.
This means you can never properly have a source package with such a
version.
As the
4-01-15 10:54:55.0 +0100
+++ grub2-2.12/debian/changelog 2024-04-01 10:20:09.0 +0200
@@ -1,3 +1,10 @@
+grub2 (2.12-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * No change rebuild. (closes: #1067486)
+
+ -- Bastian Blank Mon, 01 Apr 2024 10:20:09 +0200
+
gru
4-01-15 10:54:55.0 +0100
+++ grub2-2.12/debian/changelog 2024-04-01 10:20:09.0 +0200
@@ -1,3 +1,10 @@
+grub2 (2.12-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * No change rebuild. (closes: #1067486)
+
+ -- Bastian Blank Mon, 01 Apr 2024 10:20:09 +0200
+
gru
Control: severity -1 serious
Control: reopen -1
Hi
As you might have found out, binnmu don't work with signed packages.
This needs a source rebuild.
Bastian
--
Totally illogical, there was no chance.
-- Spock, "The Galileo Seven", stardate 2822.3
On Sun, Mar 31, 2024 at 11:59:35AM +0100, Colin Watson wrote:
> > What we can do unilaterally is to disallow vendoring those files.
> > Does it help? At least in the case of autoconf it removes one common
> > source of hard to read files.
> That's doable unilaterally to some extent, using the
On Sat, Mar 30, 2024 at 08:15:10PM +, Colin Watson wrote:
> On Sat, Mar 30, 2024 at 05:12:17PM +0100, Sirius wrote:
> > I have seen discussion about shifting away from the whole auto(re)conf
> > tooling to CMake or Meson with there being a reasonable drawback to CMake.
> > Is that something
On Sun, Mar 31, 2024 at 12:05:54PM +0500, Andrey Rakhmatullin wrote:
> On Sat, Mar 30, 2024 at 11:22:33PM -0300, Santiago Ruano Rincón wrote:
> > As others have said, the best solution is to relay on HSW for handling
> > the cryptographic material.
> Aren't these answers to different questions?
>
On Sat, Mar 30, 2024 at 07:15:28PM -0700, Otto Kekäläinen wrote:
> I am doing all my builds inside a (Podman) container with the sources
> loop-mounted.
You do, but Debian itself (aka DSA) does not. They still prefer to
trust all 100k packages and run them as root in the init namespace over
the
On Sat, Mar 30, 2024 at 01:30:07PM +0100, Jan-Benedict Glaw wrote:
> On Sat, 2024-03-30 08:02:04 +0100, Gioele Barabucci wrote:
> > On 30/03/24 01:21, Antonio Russo wrote:
> > > 3. Have tooling that automatically checks the sanitized sources against
> > > the development RCSs.
> >
On Sat, Mar 30, 2024 at 10:28:04AM +0100, Bastian Blank wrote:
> We have a suite with some project management capabilities: salsa. Let's
> just use it instead of ad-hoc tools. I don't think we have something
> better right now?
This is now https://salsa.debian.org/ftp-team/xz-2024
On Sat, Mar 30, 2024 at 10:28:04AM +0100, Bastian Blank wrote:
> We have a suite with some project management capabilities: salsa. Let's
> just use it instead of ad-hoc tools. I don't think we have something
> better right now?
This is now https://salsa.debian.org/ftp-team/xz-2024
On Fri, Mar 29, 2024 at 11:59:38PM +0100, Ansgar wrote:
> Should we also reset the archive to some prior state and rebuilt
> packages like Ubuntu? Do we need to revert to an earlier date as
> vulnerable versions have been uploaded to experimental on 2024-02-01
> (but the earlier version might
On Fri, Mar 29, 2024 at 11:59:38PM +0100, Ansgar wrote:
> Should we also reset the archive to some prior state and rebuilt
> packages like Ubuntu? Do we need to revert to an earlier date as
> vulnerable versions have been uploaded to experimental on 2024-02-01
> (but the earlier version might
Hi
On Thu, Mar 21, 2024 at 08:48:01PM +0100, Helmut Grohne wrote:
> I was recently working on gcc builds and this disagreement currently
> makes stuff unbuildable. Hence I looked into solutions and/or
> workarounds.
Care to just share what you actually found? Where is it broken and how
to see
Hi
On Thu, Mar 21, 2024 at 08:48:01PM +0100, Helmut Grohne wrote:
> I was recently working on gcc builds and this disagreement currently
> makes stuff unbuildable. Hence I looked into solutions and/or
> workarounds.
Care to just share what you actually found? Where is it broken and how
to see
Hi
On Thu, Mar 21, 2024 at 08:48:01PM +0100, Helmut Grohne wrote:
> I was recently working on gcc builds and this disagreement currently
> makes stuff unbuildable. Hence I looked into solutions and/or
> workarounds.
Care to just share what you actually found? Where is it broken and how
to see
Hi
On Thu, Mar 21, 2024 at 08:48:01PM +0100, Helmut Grohne wrote:
> I was recently working on gcc builds and this disagreement currently
> makes stuff unbuildable. Hence I looked into solutions and/or
> workarounds.
Care to just share what you actually found? Where is it broken and how
to see
On Tue, Mar 26, 2024 at 12:53:42PM +0100, Alessandro Vesely wrote:
> I compiled the example program given in the inet_pton(3) man page, and obtain
> the following:
> $ ./a.out i6 0:0:0::5.6.7.8
> Not in presentation format
This is no valid IPv6 address. Where did you find that?
Bastian
--
On Tue, Mar 26, 2024 at 12:53:42PM +0100, Alessandro Vesely wrote:
> I compiled the example program given in the inet_pton(3) man page, and obtain
> the following:
> $ ./a.out i6 0:0:0::5.6.7.8
> Not in presentation format
This is no valid IPv6 address. Where did you find that?
Bastian
--
On Sun, Mar 24, 2024 at 12:04:35AM -0700, Kingsley G. Morse Jr. wrote:
> As you can see below, lines 25 and 26 of the hook
> script look in a path starting with "/lib"
>
> [...]
> 25 elif [ -e /lib/udev/rules.d/$rules ]; then
> 26 cp -p /lib/udev/rules.d/$rules
On Sat, Mar 23, 2024 at 12:36:23PM +0100, Matthias Nagel via Postfix-users
wrote:
> I am currently assessing the TLS security of a Postfix mail server and among
> other things sslscan reported that the server allows a (non-EC) DH exchange
> with only 1024 bits. While one solution would be to
On Fri, Mar 22, 2024 at 10:03:29AM +0100, Stephan Müller wrote:
> Can this be related to the underlying genericcloud image? So far, I was
> unable to find anything with "computeMetadata" in the systemlogs of the VMs.
> I checked the boot log (including cloud-init process) using virsh console
>
Control: reassign -1 tech-ctte
Control: severity -1 normal
Hi
I don't see any way to solve this issue right now. Please decide this
matter according to 6.1 nr 2 Debian Constitution.
Background: linux-libc-dev provides the Linux API for consumption by
all userspace stuff.
This package was
Control: reassign -1 tech-ctte
Control: severity -1 normal
Hi
I don't see any way to solve this issue right now. Please decide this
matter according to 6.1 nr 2 Debian Constitution.
Background: linux-libc-dev provides the Linux API for consumption by
all userspace stuff.
This package was
Control: reassign -1 tech-ctte
Control: severity -1 normal
Hi
I don't see any way to solve this issue right now. Please decide this
matter according to 6.1 nr 2 Debian Constitution.
Background: linux-libc-dev provides the Linux API for consumption by
all userspace stuff.
This package was
On Wed, Mar 20, 2024 at 09:59:31PM +0100, Matthias Klose wrote:
> Independent of any technical issues, this is a hijacking of a package name.
> Please revert that change.
Okay. Please prepare to take over linux-libc-dev alltogether then,
there can be only one copy.
Bastian
--
Insufficient
On Wed, Mar 20, 2024 at 09:59:31PM +0100, Matthias Klose wrote:
> Independent of any technical issues, this is a hijacking of a package name.
> Please revert that change.
Okay. Please prepare to take over linux-libc-dev alltogether then,
there can be only one copy.
Bastian
--
Insufficient
On Wed, Mar 20, 2024 at 09:59:31PM +0100, Matthias Klose wrote:
> Independent of any technical issues, this is a hijacking of a package name.
> Please revert that change.
Okay. Please prepare to take over linux-libc-dev alltogether then,
there can be only one copy.
Bastian
--
Insufficient
Control: unmerge 1059786
Control: reassign 1059786 cross-toolchain-base
Hi
I'm going forward with the provided plan and will add Breaks with Linux
6.8.
Regards,
Bastian
--
Insults are effective only where emotion is present.
-- Spock, "Who Mourns for Adonais?" stardate 3468.1
Control: unmerge 1059786
Control: reassign 1059786 cross-toolchain-base
Hi
I'm going forward with the provided plan and will add Breaks with Linux
6.8.
Regards,
Bastian
--
Insults are effective only where emotion is present.
-- Spock, "Who Mourns for Adonais?" stardate 3468.1
Control: unmerge 1059786
Control: reassign 1059786 cross-toolchain-base
Hi
I'm going forward with the provided plan and will add Breaks with Linux
6.8.
Regards,
Bastian
--
Insults are effective only where emotion is present.
-- Spock, "Who Mourns for Adonais?" stardate 3468.1
Hi
Not a single piece of evidence of a breakage showed up within the last
weeks. I'm therefor closing this bug report.
Regards,
Bastian
--
You! What PLANET is this!
-- McCoy, "The City on the Edge of Forever", stardate 3134.0
Control: severity -1 important
On Sun, Mar 10, 2024 at 11:47:17AM +0100, Eric Valette wrote:
> And then it correctly builds the kernel and modules .ko file, then sign the
> ko and xz compress it to get foo.ko.xz. Here are extracts
>
> But then it tries to sign again the modules using the .ko
Control: severity -1 important
On Sun, Mar 10, 2024 at 11:47:17AM +0100, Eric Valette wrote:
> And then it correctly builds the kernel and modules .ko file, then sign the
> ko and xz compress it to get foo.ko.xz. Here are extracts
>
> But then it tries to sign again the modules using the .ko
Control: severity -1 important
On Sun, Mar 10, 2024 at 11:47:17AM +0100, Eric Valette wrote:
> And then it correctly builds the kernel and modules .ko file, then sign the
> ko and xz compress it to get foo.ko.xz. Here are extracts
>
> But then it tries to sign again the modules using the .ko
Control: severity -1 minor
> Because this is an x32 host.
x32 is multi-arch kernel only architecture. Debian still don't have
proper support for multi-arch for compilers.
Just use amd64.
Bastian
--
Bones: "The man's DEAD, Jim!"
Control: severity -1 minor
> Because this is an x32 host.
x32 is multi-arch kernel only architecture. Debian still don't have
proper support for multi-arch for compilers.
Just use amd64.
Bastian
--
Bones: "The man's DEAD, Jim!"
Control: severity -1 minor
> Because this is an x32 host.
x32 is multi-arch kernel only architecture. Debian still don't have
proper support for multi-arch for compilers.
Just use amd64.
Bastian
--
Bones: "The man's DEAD, Jim!"
Hi Helmut
On Tue, Mar 05, 2024 at 09:50:27AM +0100, Helmut Grohne wrote:
> The problem arises in the reverse sense. If a file does not exist in
> one, it is searched in the second and erroneously may be found. That may
> make tests pass that should not pass and typically causes a link failure
>
Hi Helmut
On Tue, Mar 05, 2024 at 09:50:27AM +0100, Helmut Grohne wrote:
> The problem arises in the reverse sense. If a file does not exist in
> one, it is searched in the second and erroneously may be found. That may
> make tests pass that should not pass and typically causes a link failure
>
Hi Helmut
On Tue, Mar 05, 2024 at 09:50:27AM +0100, Helmut Grohne wrote:
> The problem arises in the reverse sense. If a file does not exist in
> one, it is searched in the second and erroneously may be found. That may
> make tests pass that should not pass and typically causes a link failure
>
On Mon, Mar 04, 2024 at 11:04:23PM +0100, Bastian Blank wrote:
> At least to show where it breaks.
And I actually tried it and can not show the expected breakage from
missing /usr/include in the search path. gcc-13-cross builds fine with
only linux-libc-dev/6.7.7-1.
| -rw-r--r-- 1 bast
On Mon, Mar 04, 2024 at 11:04:23PM +0100, Bastian Blank wrote:
> At least to show where it breaks.
And I actually tried it and can not show the expected breakage from
missing /usr/include in the search path. gcc-13-cross builds fine with
only linux-libc-dev/6.7.7-1.
| -rw-r--r-- 1 bast
On Mon, Mar 04, 2024 at 11:04:23PM +0100, Bastian Blank wrote:
> At least to show where it breaks.
And I actually tried it and can not show the expected breakage from
missing /usr/include in the search path. gcc-13-cross builds fine with
only linux-libc-dev/6.7.7-1.
| -rw-r--r-- 1 bast
On Mon, Mar 04, 2024 at 01:49:24PM +0100, Helmut Grohne wrote:
> The packaged gcc cross toolchain uses a sysroot during its own build
> still. As it is implemented now, it searches /usr//include, but
> not /usr/include/. So quite fundamentally, the Provides that
> we two agreed do break the build
On Mon, Mar 04, 2024 at 01:49:24PM +0100, Helmut Grohne wrote:
> The packaged gcc cross toolchain uses a sysroot during its own build
> still. As it is implemented now, it searches /usr//include, but
> not /usr/include/. So quite fundamentally, the Provides that
> we two agreed do break the build
On Mon, Mar 04, 2024 at 01:49:24PM +0100, Helmut Grohne wrote:
> The packaged gcc cross toolchain uses a sysroot during its own build
> still. As it is implemented now, it searches /usr//include, but
> not /usr/include/. So quite fundamentally, the Provides that
> we two agreed do break the build
Control: tags -1 moreinfo
On Mon, Mar 04, 2024 at 08:53:11AM +0100, Matthias Klose wrote:
> linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't
> do that completely
> However the links in /usr/DEB_HOST_GNU_TYPE/include are missing.
So you claim that
Control: tags -1 moreinfo
On Mon, Mar 04, 2024 at 08:53:11AM +0100, Matthias Klose wrote:
> linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't
> do that completely
> However the links in /usr/DEB_HOST_GNU_TYPE/include are missing.
So you claim that
Control: tags -1 moreinfo
On Mon, Mar 04, 2024 at 08:53:11AM +0100, Matthias Klose wrote:
> linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't
> do that completely
> However the links in /usr/DEB_HOST_GNU_TYPE/include are missing.
So you claim that
On Mon, Mar 04, 2024 at 11:28:12AM +, Luca Boccassi wrote:
> > But we where talking about kernel modules.
> There are kernel modules using BPF stuff? Never seen one, do you have
> an example?
No idea, but they get linked BTF information, so you could use them.
Bastian
--
Those who hate and
On Mon, Mar 04, 2024 at 11:28:12AM +, Luca Boccassi wrote:
> > But we where talking about kernel modules.
> There are kernel modules using BPF stuff? Never seen one, do you have
> an example?
No idea, but they get linked BTF information, so you could use them.
Bastian
--
Those who hate and
On Mon, Mar 04, 2024 at 12:07:15PM +0100, Matthias Klose wrote:
> On 04.03.24 11:29, Bastian Blank wrote:
> > On Mon, Mar 04, 2024 at 08:53:11AM +0100, Matthias Klose wrote:
> > > However the links in /usr/DEB_HOST_GNU_TYPE/include are missing.
> >
> >
On Mon, Mar 04, 2024 at 12:07:15PM +0100, Matthias Klose wrote:
> On 04.03.24 11:29, Bastian Blank wrote:
> > On Mon, Mar 04, 2024 at 08:53:11AM +0100, Matthias Klose wrote:
> > > However the links in /usr/DEB_HOST_GNU_TYPE/include are missing.
> >
> >
On Mon, Mar 04, 2024 at 12:07:15PM +0100, Matthias Klose wrote:
> On 04.03.24 11:29, Bastian Blank wrote:
> > On Mon, Mar 04, 2024 at 08:53:11AM +0100, Matthias Klose wrote:
> > > However the links in /usr/DEB_HOST_GNU_TYPE/include are missing.
> >
> >
[ Remove -arm and -release }
Hi
On Sun, Mar 03, 2024 at 09:01:06PM +0100, Cyril Brulebois wrote:
> Maybe have it marked Not-For-Us on armel, also requesting the binary to
> be dropped there? And maybe poke the ftp team to have installer-armel/
> cleaned up? (The “disabling daily builds” part
[ Remove -arm and -release }
Hi
On Sun, Mar 03, 2024 at 09:01:06PM +0100, Cyril Brulebois wrote:
> Maybe have it marked Not-For-Us on armel, also requesting the binary to
> be dropped there? And maybe poke the ftp team to have installer-armel/
> cleaned up? (The “disabling daily builds” part
On Mon, Mar 04, 2024 at 08:53:11AM +0100, Matthias Klose wrote:
> However the links in /usr/DEB_HOST_GNU_TYPE/include are missing.
Please be a bit more precise, there are no symlinks in this directory.
| # dpkg -S /usr/alpha-linux-gnu/include/asm/a.out.h
| linux-libc-dev-alpha-cross:
On Sat, Mar 02, 2024 at 12:40:07AM +, Luca Boccassi wrote:
> Yes precisely, the bpf program source can just include vmlinux.h and it
> should build and run as expected.
But we where talking about kernel modules.
Bastian
--
Vulcans never bluff.
-- Spock, "The Doomsday
On Sat, Mar 02, 2024 at 12:40:07AM +, Luca Boccassi wrote:
> Yes precisely, the bpf program source can just include vmlinux.h and it
> should build and run as expected.
But we where talking about kernel modules.
Bastian
--
Vulcans never bluff.
-- Spock, "The Doomsday
On Mon, Mar 04, 2024 at 08:53:11AM +0100, Matthias Klose wrote:
> However the links in /usr/DEB_HOST_GNU_TYPE/include are missing.
Please be a bit more precise, there are no symlinks in this directory.
| # dpkg -S /usr/alpha-linux-gnu/include/asm/a.out.h
| linux-libc-dev-alpha-cross:
Control: reassign -1 cross-toolchain-base
Control: forcemerge 1059786 -1
On Mon, Mar 04, 2024 at 08:53:11AM +0100, Matthias Klose wrote:
> linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't
> do that completely
This is #1059786. This lacks a response from you. So I'm
Control: reassign -1 cross-toolchain-base
Control: forcemerge 1059786 -1
On Mon, Mar 04, 2024 at 08:53:11AM +0100, Matthias Klose wrote:
> linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't
> do that completely
This is #1059786. This lacks a response from you. So I'm
Control: reassign -1 cross-toolchain-base
Control: forcemerge 1059786 -1
On Mon, Mar 04, 2024 at 08:53:11AM +0100, Matthias Klose wrote:
> linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't
> do that completely
This is #1059786. This lacks a response from you. So I'm
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] $@
| cmd_btf_ko = \
|
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] $@
| cmd_btf_ko = \
|
On Thu, Feb 29, 2024 at 11:03:11AM +, 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?
It complains loudly about BTF.
> DKMS should handle its own dependencies, I'd have
1 - 100 of 14547 matches
Mail list logo
