Re: What to do with d-i on armel?

[Gerardo Ballabio]

Gianluca Renzi wrote:
> The same here. We never used the d-i but we are using Debian systems (kernel 
> and root file system) as daily bases of our line of products embedded 
> systems. Hundred of thousands of boards are using Debian since Debian Lenny 
> 5.0. From armel to armhf 32 bit systems.
> So a drop of the armel and/or armhf will force us to a very complicated 
> rearrangement of our build systems.
> Please don't do that if you can.

Hi Gianluca,
if that is so important for your business, you might consider
sponsoring some work on this issue.
The Debian Long Term Support project
 is about keeping "old stuff"
working so that might be the right place to ask.

Gerardo

Bug#1064041: linux-image-6.1.0-18-amd64: Resuming from suspend keyboard unresponsive (but sysrq OK , touchpad OK) on dell latitude 3340

[Jacques]

Hi Salvatore

Le 03/03/2024 à 16:25, Salvatore Bonaccorso a écrit :


Ok that is great to hear. So firstmost: Then this iwill be fixed in
the next upload for bookworm, as we do a rebase to at least 6.1.80.

Alternatively if we know which was the fixing commit that would be
helpful as well now, since we know 6.1.80 fixes the issue. Otherwise
we simply close later once the upload has happened.

Regards,
Salvatore



Here are the results of my tests on the various upstream kernels.

The problem appeared with kernel 6.1.74 and has been corrected in kernel 
6.1.78.



If possible, can we leave the bug report open until the next version of 
bookworm is released, to allow other users to find the workaround by 
adding the atkbd.reset option to the machine boot:


edit in /etc/default/grub:
GRUB_CMDLINE_LINUX_DEFAULT="quiet atkbd.reset"

followed by the command:
sudo update-grub

Best regards

Jacques

Processed: Re: Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely

[Debian Bug Tracking System]

Processing control commands:

> reassign -1 cross-toolchain-base
Bug #1065416 [linux-libc-dev] linux-libc-dev claims to provide 
linux-libc-dev-ARCH-cross, but it doesn't do that completely
Bug reassigned from package 'linux-libc-dev' to 'cross-toolchain-base'.
No longer marked as found in versions linux/6.7.7-1.
Ignoring request to alter fixed versions of bug #1065416 to the same values 
previously set
> forcemerge 1059786 -1
Bug #1059786 [cross-toolchain-base] cross-toolchain-base: Migrating 
linux-libc-dev
Bug #1059786 [cross-toolchain-base] cross-toolchain-base: Migrating 
linux-libc-dev
Added tag(s) sid and trixie.
Bug #1065416 [cross-toolchain-base] linux-libc-dev claims to provide 
linux-libc-dev-ARCH-cross, but it doesn't do that completely
Severity set to 'normal' from 'serious'
Added tag(s) patch.
Merged 1059786 1065416

-- 
1059786: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059786
1065416: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065416
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely

[Bastian Blank]

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 merging
those.

Bastian

-- 
There are always alternatives.
-- Spock, "The Galileo Seven", stardate 2822.3

Bug#1064838: marked as done (New package names break APT safety features, ability to co-install different ABIs)

[Debian Bug Tracking System]

Your message dated Mon, 4 Mar 2024 11:31:38 +0100
with message-id <20240304103138.jvussu4gqb2zv...@shell.thinkmo.de>
and subject line Re: Bug#1064838: New package names break APT safety features, 
ability to co-install different ABIs
has caused the Debian Bug report #1064838,
regarding New package names break APT safety features, ability to co-install 
different ABIs
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
1064838: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064838
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: linux
Severity: serious
X-Debbugs-Cc: j...@debian.org

After we had discussed the new proposal a couple months ago and were
left with severe open questions and concerns it seems that these have
been ignored and the packages uploaded anyway, breaking APT's algorithm
that ensures the currently booted kernel is not offered for removal, as
well as possibly others.

In addition, this means that the ABI changes within the same package
names, causing different ABIs to no longer be co-installable, which can
have drastic effect on thef function of systems:

- modules will fail to load until you reboot
- modules needed to reboot will fail to load until you reboot (if any)

I do not believe fucking up our users for convenience of the maintainers
and lacking of tools on the ftpmaster side to automatically approve new
ABI renames is the right call here.

As such if this change is not reverted, I intend to reassign this to
the technical committee for deliberation.

-- System Information:
Debian Release: trixie/sid
  APT prefers noble
  APT policy: (500, 'noble'), (500, 'mantic-security')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.8.0-11-generic (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
C.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en
--- End Message ---
--- Begin Message ---
On Mon, Feb 26, 2024 at 07:52:10PM +0100, Bastian Blank wrote:
> The change for that is not even in.  Where do you see it?

No new information where the mentioned change is actually, closing until
any is provided.

Bastian

-- 
Humans do claim a great deal for that particular emotion (love).
-- Spock, "The Lights of Zetar", stardate 5725.6--- End Message ---

Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package

[Colm Buckley]

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). Am I missing
something else? I confess I have only a very small amount of experience
with BPF code; I played with building a few modules, but I don't use it
regularly.

Colm

Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package

[Bastian Blank]

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 Machine", stardate 4202.1

Re: What to do with d-i on armel?

[Adrian Bunk]

On Mon, Mar 04, 2024 at 09:52:14AM +0100, Gerardo Ballabio wrote:
> Gianluca Renzi wrote:
> > The same here. We never used the d-i but we are using Debian systems 
> > (kernel and root file system) as daily bases of our line of products 
> > embedded systems. Hundred of thousands of boards are using Debian since 
> > Debian Lenny 5.0. From armel to armhf 32 bit systems.
> > So a drop of the armel and/or armhf will force us to a very complicated 
> > rearrangement of our build systems.
> > Please don't do that if you can.
> 
> Hi Gianluca,
> if that is so important for your business, you might consider
> sponsoring some work on this issue.
> The Debian Long Term Support project
>  is about keeping "old stuff"
> working so that might be the right place to ask.

That's not the right place, LTS is about keeping *old Debian versions*
security supported for 2 additional years (and has dropped armel since stretch).

LTS is not doing anything at all regarding keeping older/unusual 
hardware supported, such work has to be done directly in Debian
(and upstream).

> Gerardo

cu
Adrian

Re: What to do with d-i on armel?

[Bastian Blank]

[ 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 being trivial.)

i would remove the d-i package itself (don't we already set the
supported architectures?)

Cleanup installer-armel.

Remove armel specific udeb sources (I doubt we hve any).

I would not try to remove udebs itself but just continue to build them.

Bastian

-- 
No one wants war.
-- Kirk, "Errand of Mercy", stardate 3201.7

Processed (with 1 error): Re: Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely

[Debian Bug Tracking System]

Processing control commands:

> unmerge 1059786 -1
Unknown command or malformed arguments to command.

> reassign -1 linux-libc-dev
Bug #1065416 [cross-toolchain-base] linux-libc-dev claims to provide 
linux-libc-dev-ARCH-cross, but it doesn't do that completely
Bug #1059786 [cross-toolchain-base] cross-toolchain-base: Migrating 
linux-libc-dev
Bug reassigned from package 'cross-toolchain-base' to 'linux-libc-dev'.
Bug reassigned from package 'cross-toolchain-base' to 'linux-libc-dev'.
Ignoring request to alter found versions of bug #1065416 to the same values 
previously set
Ignoring request to alter found versions of bug #1059786 to the same values 
previously set
Ignoring request to alter fixed versions of bug #1065416 to the same values 
previously set
Ignoring request to alter fixed versions of bug #1059786 to the same values 
previously set
> found -1 6.7.7-1
Bug #1065416 [linux-libc-dev] linux-libc-dev claims to provide 
linux-libc-dev-ARCH-cross, but it doesn't do that completely
Bug #1059786 [linux-libc-dev] cross-toolchain-base: Migrating linux-libc-dev
Marked as found in versions linux/6.7.7-1.
Marked as found in versions linux/6.7.7-1.
> severity -1 serious
Bug #1065416 [linux-libc-dev] linux-libc-dev claims to provide 
linux-libc-dev-ARCH-cross, but it doesn't do that completely
Bug #1059786 [linux-libc-dev] cross-toolchain-base: Migrating linux-libc-dev
Severity set to 'serious' from 'normal'
Severity set to 'serious' from 'normal'

-- 
1059786: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059786
1065416: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065416
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Re: What to do with d-i on armel?

[Cyril Brulebois]

Bastian Blank  (2024-03-04):
> 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 being trivial.)
> 
> i would remove the d-i package itself (don't we already set the
> supported architectures?)

No, at least not in debian/control, that's why I'm asking. I would love
to avoid having to maintain a list of architectures…

> Cleanup installer-armel.

ACK.

> Remove armel specific udeb sources (I doubt we hve any).

Doesn't ring a bell.

> I would not try to remove udebs itself but just continue to build them.

Sure, nothing to gain there.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package

[Luca Boccassi]

On Mon, 4 Mar 2024 at 10:32, Bastian Blank  wrote:
>
> 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

There are kernel modules using BPF stuff? Never seen one, do you have
an example?

Bug#1059786: cross-toolchain-base: Migrating linux-libc-dev

[Matthias Klose]

Control: tags -1 - patch

The headers have to be provided in the /usr//include location.

Currently, that is not possible, because linux-libc-dev provides the 
linux-libc-dev-cross-* packages, without providing these headers in the 
old locations.


The assumption to include the headers for the target from the header 
location of the host is wrong.

Processed: Re: cross-toolchain-base: Migrating linux-libc-dev

[Debian Bug Tracking System]

Processing control commands:

> tags -1 - patch
Bug #1059786 [linux-libc-dev] cross-toolchain-base: Migrating linux-libc-dev
Bug #1065416 [linux-libc-dev] linux-libc-dev claims to provide 
linux-libc-dev-ARCH-cross, but it doesn't do that completely
Removed tag(s) patch.
Removed tag(s) patch.

-- 
1059786: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059786
1065416: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065416
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1065416: [Cross-toolchain-base-devs] Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely

[Bastian Blank]

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.
> > 
> > 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: /usr/alpha-linux-gnu/include/asm/a.out.h
> > | # find /usr/alpha-linux-gnu/include/ -type l
> > | #
> yes, that is the problem. the cross gcc expects these headers in
> /usr/alpha-linux-gnu/include, not in the header location for the host.

Please show your problem with a log, my crystal ball is broken.

arm-linux-gnueabihf-cpp-13 tells me:

| #include <...> search starts here:
|  /usr/lib/gcc-cross/arm-linux-gnueabihf/13/include
|  
/usr/lib/gcc-cross/arm-linux-gnueabihf/13/../../../../arm-linux-gnueabihf/include
|  /usr/include/arm-linux-gnueabihf
|  /usr/include
| End of search list.

So clearly /usr/include/arm-linux-gnueabihf is used.

Regards,
Bastian

-- 
It would be illogical to assume that all conditions remain stable.
-- Spock, "The Enterprise Incident", stardate 5027.3

Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package

[Bastian Blank]

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 fight must stop themselves -- otherwise it is not stopped.
-- Spock, "Day of the Dove", stardate unknown

Bug#1064035: [regression 5.10.y] linux-doc builds: Global symbol "$args" requires explicit package name (did you forget to declare "my $args"?) at ./scripts/kernel-doc line 1236.

[Greg Kroah-Hartman]

On Fri, Mar 01, 2024 at 01:31:10PM +0100, Salvatore Bonaccorso wrote:
> Hi,
> 
> Ben Hutchings reported in https://bugs.debian.org/1064035 a problem
> with the kernel-doc builds once 3080ea5553cc ("stddef: Introduce
> DECLARE_FLEX_ARRAY() helper") got applied in 5.10.210 (as
> prerequisite of another fix in 5.10.y):
> 
> > The backport of commit 3080ea5553cc "stddef: Introduce
> > DECLARE_FLEX_ARRAY() helper" modified scripts/kernel-doc and
> > introduced a syntax error:
> > 
> > Global symbol "$args" requires explicit package name (did you forget to 
> > declare "my $args"?) at ./scripts/kernel-doc line 1236.
> > Global symbol "$args" requires explicit package name (did you forget to 
> > declare "my $args"?) at ./scripts/kernel-doc line 1236.
> > Execution of ./scripts/kernel-doc aborted due to compilation errors.
> > 
> > This doesn't stop the documentation build process, but causes the
> > documentation that should be extracted by kernel-doc to be missing
> > from linux-doc-5.10.
> > 
> > We should be able to fix this by eithering backport commit
> > e86bdb24375a "scripts: kernel-doc: reduce repeated regex expressions
> > into variables" or replacing /$args/ with /([^,)]+)/.
> > 
> > Ben.
> 
> What would be prefered here from stable maintainers point of view?
> AFAICS e86bdb24375a ("scripts: kernel-doc: reduce repeated regex
> expressions into variables") won't apply cleanly and needs some
> refactoring. The alternative pointed out by Ben would be to replace
> the /$args/ with  /([^,)]+)/.

I'll take a patch that does either, your call :)

thanks,

greg k-h

Bug#1064035: [regression 5.10.y] linux-doc builds: Global symbol "$args" requires explicit package name (did you forget to declare "my $args"?) at ./scripts/kernel-doc line 1236.

[Jonathan Corbet]

Salvatore Bonaccorso  writes:

> Hi,
>
> Ben Hutchings reported in https://bugs.debian.org/1064035 a problem
> with the kernel-doc builds once 3080ea5553cc ("stddef: Introduce
> DECLARE_FLEX_ARRAY() helper") got applied in 5.10.210 (as
> prerequisite of another fix in 5.10.y):
>
>> The backport of commit 3080ea5553cc "stddef: Introduce
>> DECLARE_FLEX_ARRAY() helper" modified scripts/kernel-doc and
>> introduced a syntax error:
>> 
>> Global symbol "$args" requires explicit package name (did you forget to 
>> declare "my $args"?) at ./scripts/kernel-doc line 1236.
>> Global symbol "$args" requires explicit package name (did you forget to 
>> declare "my $args"?) at ./scripts/kernel-doc line 1236.
>> Execution of ./scripts/kernel-doc aborted due to compilation errors.
>> 
>> This doesn't stop the documentation build process, but causes the
>> documentation that should be extracted by kernel-doc to be missing
>> from linux-doc-5.10.
>> 
>> We should be able to fix this by eithering backport commit
>> e86bdb24375a "scripts: kernel-doc: reduce repeated regex expressions
>> into variables" or replacing /$args/ with /([^,)]+)/.
>> 
>> Ben.
>
> What would be prefered here from stable maintainers point of view?
> AFAICS e86bdb24375a ("scripts: kernel-doc: reduce repeated regex
> expressions into variables") won't apply cleanly and needs some
> refactoring. The alternative pointed out by Ben would be to replace
> the /$args/ with  /([^,)]+)/.

Hmm...this is the first I see of any of this...

The latter fix seems like the more straightforward of the two.  The only
concern might be if there are other kernel-doc backports that might run
afoul of the same problem, hopefully not.

But this makes me wonder if there are other stable kernels that are
affected as well.  I guess that, despite all of the testing being done
on stable updates, nobody is testing the docs build?

Thanks,

jon

Bug#1065416: [Cross-toolchain-base-devs] Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely

[Bastian Blank]

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 bastian bastian 38157 Mar  5 06:40 
../gcc-13-cross_14_amd64.changes

Bastian

-- 
You're too beautiful to ignore.  Too much woman.
-- Kirk to Yeoman Rand, "The Enemy Within", stardate unknown

Bug#1064035: [regression 5.10.y] linux-doc builds: Global symbol "$args" requires explicit package name (did you forget to declare "my $args"?) at ./scripts/kernel-doc line 1236.

[Greg Kroah-Hartman]

On Mon, Mar 04, 2024 at 10:41:50PM +0100, Salvatore Bonaccorso wrote:
> Hi,
> 
> On Mon, Mar 04, 2024 at 01:05:09PM -0700, Jonathan Corbet wrote:
> > Salvatore Bonaccorso  writes:
> > 
> > > Ok. In the sprit of the stable series rules we might try the later and
> > > if it's not feasible pick the first variant?
> > 
> > Well, "the spirit of the stable series" is one of Greg's titles, and he
> > said either was good...:)
> 
> here we go. Please let me know if you need anything changed in the
> commit message to describe the situation better.
> 
> Greg, in the Fixes tag I added the 5.10.y commit as the issue is
> specific to the 5.10.y series. Is this the correct form to note this?

Looks good, I'll queue this up after the next round of releases goes
out, thanks for the patch!

greg k-h

Re: linux_6.7.7-1_source.changes is NEW

[Andrey Melnikov]

Salvatore Bonaccorso  wrote:
>
> Hi,
>
> On Tue, Mar 05, 2024 at 12:47:07AM +0300, Andrey Melnikov wrote:
> > Hello.
> >
> > Where are the linux-*-6.7.7-armmp packages lost? Nothing found on
> > incoming.debian.org and nothing present in unstable pool.
>
> See: https://buildd.debian.org/status/package.php?p=linux
>
> linux on armhf has not been built.

Great, and when buildd tried again to re-run build?

Re: linux_6.7.7-1_source.changes is NEW

[Salvatore Bonaccorso]

Hi,

On Tue, Mar 05, 2024 at 12:47:07AM +0300, Andrey Melnikov wrote:
> Hello.
> 
> Where are the linux-*-6.7.7-armmp packages lost? Nothing found on
> incoming.debian.org and nothing present in unstable pool.

See: https://buildd.debian.org/status/package.php?p=linux

linux on armhf has not been built.

Regards,
Salvatore

Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely

[Bastian Blank]

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 /usr/DEB_HOST_GNU_TYPE/include is critical part of the
API for this package name?  If you think so, please provide evidence.

This path is in violation of the Debian policy, so can't be provided by
linux-libc-dev.

Bastian

-- 
You canna change the laws of physics, Captain; I've got to have thirty minutes!

Processed: Re: Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely

[Debian Bug Tracking System]

Processing control commands:

> tags -1 moreinfo
Bug #1065416 [linux-libc-dev] linux-libc-dev claims to provide 
linux-libc-dev-ARCH-cross, but it doesn't do that completely
Bug #1059786 [linux-libc-dev] cross-toolchain-base: Migrating linux-libc-dev
Added tag(s) moreinfo.
Added tag(s) moreinfo.

-- 
1059786: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059786
1065416: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065416
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: tagging 1064035

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 1064035 + patch
Bug #1064035 [linux-doc-5.10] Missing documentation due to error in kernel-doc 
script
Added tag(s) patch.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1064035: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064035
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

re: linux_6.7.7-1_source.changes is NEW

[Andrey Melnikov]

Hello.

Where are the linux-*-6.7.7-armmp packages lost? Nothing found on
incoming.debian.org and nothing present in unstable pool.

Bug#1065416: [Cross-toolchain-base-devs] Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely

[Bastian Blank]

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 of cross toolchains right now.

Okay, so this problem is about the build of the toolchain, _not_ for
everything that comes after.

> Arguably, a cross toolchain build should probably search
> /usr/include/. I went back and forth a bit with Matthias
> about whether we could add this and did not fully understand his
> reasons, but there is one technical reason we want to avoid it for now.
> We can have both libc6-dev:TARGET and libc6-dev-TARGET-cross installed
> and these packages can have differing versions. When that happens and we
> search both /usr//include and /usr/include/, we'd
> mix two glibc versions with usually bad results (been there).

But this is a search path.  If a file exists in one, the second one is
not found.  So nothing can happen even from version skew.

> The other aspect here is that it is not sufficient to add
> /usr/include/ to the search path as you also need
> /usr/include to get a complete linux kernel headers experience. We
> definitely do not want to add /usr/include, because that is known to
> misguide configure tests performed for the target architecture.

We are talking about the toolchain itself.  What configure tests could
that be?  Or is that premature optimization of the gcc build?

> So at least for now, I am convinced that we will need
> /usr//include to be provided by the package providing
> linux-libc-dev-arch-cross.

You just said that the search path used during the build of the
toolchain and the one for everything else are unrelated.  So you are
free to create $BUILD/tmp-include with symlinks for asm, asm-generic,
linux.

The toolchain as installed already finds all headers.  So I still don't
see why we need this in the final system.

> That still leaves the question of which package would have to build that
> new linux-libc-dev-cross. The two obvious answers are linux and
> cross-toolchain-base. Do you have a preference here?

No, the gcc build itself, because it is the only part that needs it from
what you said here.

> I hope this all makes more sense now.

At least to show where it breaks.

Bastian

-- 
Each kiss is as the first.
-- Miramanee, Kirk's wife, "The Paradise Syndrome",
   stardate 4842.6

Bug#1064035: [regression 5.10.y] linux-doc builds: Global symbol "$args" requires explicit package name (did you forget to declare "my $args"?) at ./scripts/kernel-doc line 1236.

[Salvatore Bonaccorso]

Hi Jonathan,

On Mon, Mar 04, 2024 at 06:39:26AM -0700, Jonathan Corbet wrote:
> Salvatore Bonaccorso  writes:
> 
> > Hi,
> >
> > Ben Hutchings reported in https://bugs.debian.org/1064035 a problem
> > with the kernel-doc builds once 3080ea5553cc ("stddef: Introduce
> > DECLARE_FLEX_ARRAY() helper") got applied in 5.10.210 (as
> > prerequisite of another fix in 5.10.y):
> >
> >> The backport of commit 3080ea5553cc "stddef: Introduce
> >> DECLARE_FLEX_ARRAY() helper" modified scripts/kernel-doc and
> >> introduced a syntax error:
> >> 
> >> Global symbol "$args" requires explicit package name (did you forget to 
> >> declare "my $args"?) at ./scripts/kernel-doc line 1236.
> >> Global symbol "$args" requires explicit package name (did you forget to 
> >> declare "my $args"?) at ./scripts/kernel-doc line 1236.
> >> Execution of ./scripts/kernel-doc aborted due to compilation errors.
> >> 
> >> This doesn't stop the documentation build process, but causes the
> >> documentation that should be extracted by kernel-doc to be missing
> >> from linux-doc-5.10.
> >> 
> >> We should be able to fix this by eithering backport commit
> >> e86bdb24375a "scripts: kernel-doc: reduce repeated regex expressions
> >> into variables" or replacing /$args/ with /([^,)]+)/.
> >> 
> >> Ben.
> >
> > What would be prefered here from stable maintainers point of view?
> > AFAICS e86bdb24375a ("scripts: kernel-doc: reduce repeated regex
> > expressions into variables") won't apply cleanly and needs some
> > refactoring. The alternative pointed out by Ben would be to replace
> > the /$args/ with  /([^,)]+)/.
> 
> Hmm...this is the first I see of any of this...
> 
> The latter fix seems like the more straightforward of the two.  The only
> concern might be if there are other kernel-doc backports that might run
> afoul of the same problem, hopefully not.

Ok. In the sprit of the stable series rules we might try the later and
if it's not feasible pick the first variant?

> But this makes me wonder if there are other stable kernels that are
> affected as well.  I guess that, despite all of the testing being done
> on stable updates, nobody is testing the docs build?

Only 5.10.y is affected AFAICT, and the reaso nis that the cherry-pick
of ("stddef: Introduce DECLARE_FLEX_ARRAY() helper") in 5.10.y (as
requisite of the smb fixes) requires as well e86bdb24375a ("scripts:
kernel-doc: reduce repeated regex expressions into variables").

3080ea5553cc ("stddef: Introduce DECLARE_FLEX_ARRAY() helper") is in 
5.10.210, 5.15.54 and 5.16-rc1.

e86bdb24375a ("scripts: kernel-doc: reduce repeated regex expressions
into variables") is in 5.14-rc1.

So it's covered for the later series, but causes problems in the
5.10.y.

Regards,
Salvatore

Bug#1065416: [Cross-toolchain-base-devs] Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely

[Helmut Grohne]

Hi Bastian,

On Mon, Mar 04, 2024 at 12:30:09PM +0100, Bastian Blank wrote:
> 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.
> > > 
> > > 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: /usr/alpha-linux-gnu/include/asm/a.out.h
> > > | # find /usr/alpha-linux-gnu/include/ -type l
> > > | #
> > yes, that is the problem. the cross gcc expects these headers in
> > /usr/alpha-linux-gnu/include, not in the header location for the host.
> 
> Please show your problem with a log, my crystal ball is broken.

This very much was not obvious to me either. I've now talked to Matthias
and believe I can explain the problem.

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 of cross toolchains right now.

Arguably, a cross toolchain build should probably search
/usr/include/. I went back and forth a bit with Matthias
about whether we could add this and did not fully understand his
reasons, but there is one technical reason we want to avoid it for now.
We can have both libc6-dev:TARGET and libc6-dev-TARGET-cross installed
and these packages can have differing versions. When that happens and we
search both /usr//include and /usr/include/, we'd
mix two glibc versions with usually bad results (been there).

While we might consider adding /usr/include/ to the cross
toolchain build search path later, it is not something we can do now and
before doing that, we need to better understand Matthias' reasons for
keeping these separate as well.

The other aspect here is that it is not sufficient to add
/usr/include/ to the search path as you also need
/usr/include to get a complete linux kernel headers experience. We
definitely do not want to add /usr/include, because that is known to
misguide configure tests performed for the target architecture. In
principle, we could extend the symlink farm in linux-libc-dev to also
have a lot of /usr/include//linux -> ../linux symlinks
(assuming that no other package ever installs to /usr/include/linux,
which is a property violated by aufs-dev and oss4-dev).

So at least for now, I am convinced that we will need
/usr//include to be provided by the package providing
linux-libc-dev-arch-cross.

As these are only necessary for building the cross toolchains, we
probably don't want these in the main linux-libc-dev package. So how
about adding a linux-libc-dev-cross package with yet more symlinks? Then
we can move the provides over to the linux-libc-dev-cross package and
that way repair the cross toolchain builds.

I requested that linux-libc-dev provides these for bootstrapping to know
which architectures linux-libc-dev actually supports. I don't need these
provides exactly, I just need a mechanism to answer the question "Does
linux-libc-dev work for a particular architecture?" from the binary
package metadata, so we might just change the Provides there to
linux-libc-dev-arch dropping the -cross suffix that traditionally
identified packages putting stuff into /usr/. Does that sound
reasonable to you?

That still leaves the question of which package would have to build that
new linux-libc-dev-cross. The two obvious answers are linux and
cross-toolchain-base. Do you have a preference here?

I hope this all makes more sense now.

Helmut

Bug#1064035: [regression 5.10.y] linux-doc builds: Global symbol "$args" requires explicit package name (did you forget to declare "my $args"?) at ./scripts/kernel-doc line 1236.

[Jonathan Corbet]

Salvatore Bonaccorso  writes:

> Ok. In the sprit of the stable series rules we might try the later and
> if it's not feasible pick the first variant?

Well, "the spirit of the stable series" is one of Greg's titles, and he
said either was good...:)

jon

Bug#1064035: [regression 5.10.y] linux-doc builds: Global symbol "$args" requires explicit package name (did you forget to declare "my $args"?) at ./scripts/kernel-doc line 1236.

[Salvatore Bonaccorso]

Hi,

On Mon, Mar 04, 2024 at 01:05:09PM -0700, Jonathan Corbet wrote:
> Salvatore Bonaccorso  writes:
> 
> > Ok. In the sprit of the stable series rules we might try the later and
> > if it's not feasible pick the first variant?
> 
> Well, "the spirit of the stable series" is one of Greg's titles, and he
> said either was good...:)

here we go. Please let me know if you need anything changed in the
commit message to describe the situation better.

Greg, in the Fixes tag I added the 5.10.y commit as the issue is
specific to the 5.10.y series. Is this the correct form to note this?

Regards,
Salvatore
>From ccddb9f4915f0dbf28fb72b6ff4c04977978ed3d Mon Sep 17 00:00:00 2001
From: Salvatore Bonaccorso 
Date: Mon, 4 Mar 2024 22:24:12 +0100
Subject: [PATCH] scripts: kernel-doc: Fix syntax error due to undeclared args
 variable

The backport of commit 3080ea5553cc ("stddef: Introduce
DECLARE_FLEX_ARRAY() helper") to 5.10.y (as a prerequisite of another
fix) modified scripts/kernel-doc and introduced a syntax error:

Global symbol "$args" requires explicit package name (did you forget to declare "my $args"?) at ./scripts/kernel-doc line 1236.
Global symbol "$args" requires explicit package name (did you forget to declare "my $args"?) at ./scripts/kernel-doc line 1236.
Execution of ./scripts/kernel-doc aborted due to compilation errors.

Note: The issue could be fixed in the 5.10.y series as well by
backporting e86bdb24375a ("scripts: kernel-doc: reduce repeated regex
expressions into variables") but just replacing the undeclared args back
to ([^,)]+) was the most straightforward approach. The issue is specific
to the backport to the 5.10.y series. Thus there is as well no upstream
commit for this change.

Fixes: 443b16ee3d9c ("stddef: Introduce DECLARE_FLEX_ARRAY() helper") # 5.10.y
Reported-by: Ben Hutchings 
Link: https://lore.kernel.org/regressions/zehkjjpgoyv_b...@eldamar.lan/T/#u
Link: https://bugs.debian.org/1064035
Signed-off-by: Salvatore Bonaccorso 
---
 scripts/kernel-doc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index 7a04d4c05326..8e3257f1ea2c 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -1233,7 +1233,7 @@ sub dump_struct($$) {
 	# replace DECLARE_KFIFO_PTR
 	$members =~ s/DECLARE_KFIFO_PTR\s*\(([^,)]+),\s*([^,)]+)\)/$2 \*$1/gos;
 	# replace DECLARE_FLEX_ARRAY
-	$members =~ s/(?:__)?DECLARE_FLEX_ARRAY\s*\($args,\s*$args\)/$1 $2\[\]/gos;
+	$members =~ s/(?:__)?DECLARE_FLEX_ARRAY\s*\(([^,)]+),\s*([^,)]+)\)/$1 $2\[\]/gos;
 	my $declaration = $members;
 
 	# Split nested struct/union elements as newer ones
-- 
2.43.0