Re: Bug#1042428: lintian.debian.org off ?

[Lucas Nussbaum]

On 22/11/23 at 09:09 +0100, Aurélien COUDERC wrote:
> Any chance to get back a front page with the complete list of tags, linking 
> to the individual tag pages ?
> 
> The best I could find for now is [1] but it's not very practical.
> 
> 
> [1] https://salsa.debian.org/lintian/lintian/-/tree/master/tags

Hi,

Done at https://udd.debian.org/lintian-tag.cgi

(and sorry for the delay)

Lucas

Re: Ability to further support 32bit architectures

[Aurelien Jarno]

On 2024-01-11 13:24, Adrian Bunk wrote:
> On Thu, Jan 11, 2024 at 11:28:19AM +0100, Bastian Blank wrote:
> >...
> > On Thu, Jan 11, 2024 at 09:48:34AM +, Dimitri John Ledkov wrote:
> > > Disabling debug symbols, enabling debug symbol zstd compression, using
> > > split debug symbols (disabled BTF usage) should help here.
> > 
> > Okay, maybe more workarounds exist.  But none of them look really
> > promising.
> >...
> 
> gcc being a memory hog on for C++ code is a hard problem,
> and debug symbols for C++ code can be a problem since
> they might be > 1 GB for some binaries.
> 
> But gcc needing more than 4 GB for a small C kernel driver is not
> a problem for the "Ability to further support 32bit architectures",
> that's a gcc bug that should be reported upstream just like you wouldn't
> suggest dropping amd64 if gcc would ICE on one kernel driver on that
> architecture.

Or maybe just blame the kernel instead:
https://lore.kernel.org/lkml/CAHk-=whkGHOmpM_1kNgzX1UDAs10+UuALcpeEWN29EE0m-my=w...@mail.gmail.com/

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net

Re: Ability to further support 32bit architectures

[Jeffrey Walton]

On Thu, Jan 11, 2024 at 5:45 AM Bastian Blank  wrote:
>
> On Thu, Jan 11, 2024 at 09:48:34AM +, Dimitri John Ledkov wrote:
> > Disabling debug symbols, enabling debug symbol zstd compression, using
> > split debug symbols (disabled BTF usage) should help here.
>
> Okay, maybe more workarounds exist.  But none of them look really
> promising.

Also see .

> > Separately, I wish we had cross-builders available, and cross-build
> > i386/armhf kernels from amd64/arm64 and thus having access to 64-bit
> > compiler.
>
> Real cross-builders would use some fast amd64/arm64/ppc64el (and for
> amd64 also reasonably cheap) machines to build all other architectures.

Jeff

Re: Bug#1060439: ITP: network-event-broker -- run scripts on systemd network events

[Michael Biebl]

Hi

Am 11.01.24 um 13:55 schrieb Tobias Schaffner:

Package: wnpp
Severity: wishlist
Owner: Tobias Schaffner 

* Package name: network-event-broker
   Version : 0.3.1+ds-1
   Upstream Author : Susant Sahani 
* URL : https://github.com/vmware/network-event-broker
* License : Apache 2.0
   Programming Lang: Go
   Description : run scripts on systemd network events

  The network-event-broker is a daemon that configures network interfaces
  and executes scripts based on network events such as address changes and
  link additions/removals. It also enables the configuration of multiple
  interfaces in the same network by automatically adding a secondary routing
  table and routing policies.

Reasoning: I already created the debian packaging and I am willing to maintain
this.


That seems very similar to 
https://tracker.debian.org/pkg/networkd-dispatcher


Could you go into more detail, where they differ and why we would want a 
second dispatcher service for networkd connection changes.


Regards,
Michael



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060439: ITP: network-event-broker -- run scripts on systemd network events

[Tobias Schaffner]

Package: wnpp
Severity: wishlist
Owner: Tobias Schaffner 

* Package name: network-event-broker
  Version : 0.3.1+ds-1
  Upstream Author : Susant Sahani 
* URL : https://github.com/vmware/network-event-broker
* License : Apache 2.0
  Programming Lang: Go
  Description : run scripts on systemd network events

 The network-event-broker is a daemon that configures network interfaces
 and executes scripts based on network events such as address changes and
 link additions/removals. It also enables the configuration of multiple
 interfaces in the same network by automatically adding a secondary routing
 table and routing policies.

Reasoning: I already created the debian packaging and I am willing to maintain
this.

Re: Ability to further support 32bit architectures

[Adrian Bunk]

On Thu, Jan 11, 2024 at 11:28:19AM +0100, Bastian Blank wrote:
>...
> On Thu, Jan 11, 2024 at 09:48:34AM +, Dimitri John Ledkov wrote:
> > Disabling debug symbols, enabling debug symbol zstd compression, using
> > split debug symbols (disabled BTF usage) should help here.
> 
> Okay, maybe more workarounds exist.  But none of them look really
> promising.
>...

gcc being a memory hog on for C++ code is a hard problem,
and debug symbols for C++ code can be a problem since
they might be > 1 GB for some binaries.

But gcc needing more than 4 GB for a small C kernel driver is not
a problem for the "Ability to further support 32bit architectures",
that's a gcc bug that should be reported upstream just like you wouldn't
suggest dropping amd64 if gcc would ICE on one kernel driver on that
architecture.

> Bastian

cu
Adrian

Re: Ability to further support 32bit architectures

[Bastian Blank]

On Thu, Jan 11, 2024 at 10:50:31AM +0100, John Paul Adrian Glaubitz wrote:
> > As it is now, we will not be able to provide a kernel for maybe all
> > 32bit architectures for Trixie.
> I don't think that this would be a reasonable decision. We're preparing to 
> switch
> 32-bit architectures over to time64_t. Disabling 32-bit kernel builds would 
> make
> this whole work moot.

This is completely unrelated.  Userland != kernel.  And people already
talked about only supporting userland for those architectures.

> FWIW, both m68k and powerpc are not affected by this bug, the powerpc build 
> fails
> because of a packaging problem.

Actually powerpc fails for exactly the same reason:

| cc1: out of memory allocating 135266296 bytes after a total of 244908032 bytes
| make[9]: *** [/<>/scripts/Makefile.build:248: 
drivers/media/pci/solo6x10/solo6x10-p2m.o] Error 1

https://buildd.debian.org/status/fetch.php?pkg=linux&arch=powerpc&ver=6.7-1%7Eexp1&stamp=1704796355&raw=0

Bastian

-- 
Earth -- mother of the most beautiful women in the universe.
-- Apollo, "Who Mourns for Adonais?" stardate 3468.1

Re: Ability to further support 32bit architectures

[Bastian Blank]

Hi

On Thu, Jan 11, 2024 at 09:48:34AM +, Dimitri John Ledkov wrote:
> Disabling debug symbols, enabling debug symbol zstd compression, using
> split debug symbols (disabled BTF usage) should help here.

Okay, maybe more workarounds exist.  But none of them look really
promising.

> Separately, I wish we had cross-builders available, and cross-build
> i386/armhf kernels from amd64/arm64 and thus having access to 64-bit
> compiler.

Real cross-builders would use some fast amd64/arm64/ppc64el (and for
amd64 also reasonably cheap) machines to build all other architectures.

Bastian

-- 
You're dead, Jim.
-- McCoy, "Amok Time", stardate 3372.7

Ability to further support 32bit architectures

[Bastian Blank]

Hi

Linux 6.7 fails to build on at least i386 and armhf.  Even it now
manages to make the compiler fail to allocate memory:
| cc1: out of memory allocating 135266296 bytes after a total of 235675648 bytes

Right now both fail on the same driver, so a short team workaround would
be to disable it.  But we need a long term fix, and quickly.

As it is now, we will not be able to provide a kernel for maybe all
32bit architectures for Trixie.

Bastian

-- 
No one can guarantee the actions of another.
-- Spock, "Day of the Dove", stardate unknown