Bug#1093185: ITP: libpdl-graphics-trid-perl -- PDL 3D interface

[Ed J]

Package: wnpp
Owner: Ed J 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org

* Package name: libpdl-graphics-trid-perl
  Version : 2.099
  Upstream Author : PerlDL Developers 
* URL : https://metacpan.org/release/PDL-Graphics-TriD
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : PDL 3D interface

Provides a 3D plotting capability to PDL, using OpenGL.

Can currently plot lines, points, meshes, and arbitrary triangles, both
with and without smoothing.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1093186: ITP: libpdl-io-hdf-perl -- PDL interface to read and write HDF4 files with the SD, VS, and V interfaces.

[Ed J]

Package: wnpp
Owner: Ed J 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org

* Package name: libpdl-io-hdf-perl
  Version : 2.003
  Upstream Author : PerlDL Developers 
* URL : https://metacpan.org/release/PDL-IO-HDF
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : PDL interface to read and write HDF4 files with the SD, VS, 
and V interfaces.


For more information on HDF, see http://hdf.ncsa.uiuc.edu/

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Re: Removing manpages from libpam-modules to improve multi-arch

[Helmut Grohne]

Hi Sam,

On Wed, Jan 15, 2025 at 09:43:36AM -0700, Sam Hartman wrote:
> My proposal is to move the man pages into libpam-doc.
> I'm not actually convinced that normal Debian users need man pages for
> all the pam modules on all Debian systems, and a suggests relationship
> should be sufficient.

I've actually used those pages more than once and appreciated their
presence by default, but I also appreciate the ability to not install
them. Sounds like I'll end up installing libpam-doc where I need them.

>From a package building pov, I'd appreciate if you could also move the
tools for building the manual pages to Build-Depends-Indep while you
move them.

> I think there are no usrmerge implications. While libpam-modules did
> move files from /lib/multiarch_tripple/security to
> /usr/lib/multiarch_tripple/security, the man pages have always been in
> /usr/share/man, which lives on /usr.

I confirm. Their presence inside the /usr/share hierarchy makes them
fully independent of any /usr-merge or /usr-move concerns.

Helmut

Re: Bug#1091394: nproc: add new option to reduce emitted processors by system memory

[Helmut Grohne]

Hi Julien,

On Mon, Jan 13, 2025 at 07:00:01PM +0100, Julien Plissonneau Duquène wrote:
> Let's start with this then. I implemented a PoC prototype [1] as a shell
> script that is currently fairly linux-specific and doesn't account for
> cgroup limits (yet?). Feedback is welcome (everything is open for discussion
> there, including the name) and if there is enough interest I may end up
> packaging it or submitting it to an existing collection (I am thinking about
> devscripts).

I'm sorry for not having come back earlier and thus caused duplicaton of
work. I had started a Python-based implementation last year and then
dropped the ball over other stuff. It also implements the --require-mem
flag in the way you suggested. It parses DEB_BUILD_OPTIONS,
RPM_BUILD_NCPUS and CMAKE_BUILD_PARALLEL_LEVEL and also considers cgroup
memory limits. I hope this captures all of the feedback I got during
discussions and research.

I'm attaching my proof of concept. Would you join forces and turn either
of these PoCs into a proper Debian package that could be used during
package builds? Once accepted, we may send patches to individual Debian
packages making use of it and call OOM FTBFS a packaging bug eventually.

Helmut
#!/usr/bin/python3
# Copyright 2024 Helmut Grohne 
# SPDX-License-Identifier: GPL-3

import argparse
import itertools
import os
import pathlib
import subprocess
import sys
import typing


def positive_integer(decstr: str) -> int:
"""Parse a positive, integral number from a string and raise a ValueError
otherwise.

>>> positive_integer(-1)
Traceback (most recent call last):
...
ValueError: integer must be positive
>>> positive_integer(0)
Traceback (most recent call last):
...
ValueError: integer must be positive
>>> positive_integer(1)
1
"""
value = int(decstr)  # raises ValueError
if value < 1:
raise ValueError("integer must be positive")
return value


def parse_size(expression: str) -> int:
"""Parse an expression representing a data size with an optional unit
suffix into an integer. Raises a ValueError on failure.

>>> parse_size("5")
5
>>> parse_size("4KB")
4096
>>> parse_size("0.9g")
966367641
>>> parse_size("-1")
Traceback (most recent call last):
...
ValueError: number must be positive
"""
expression = expression.lower()
if expression.endswith("b"):
expression = expression[:-1]
suffixes = {
"k": 2**10,
"m": 2**20,
"g": 2**30,
"t": 2**40,
"e": 2**50,
}
factor = 1
if expression[-1:] in suffixes:
factor = suffixes[expression[-1]]
expression = expression[:-1]
fval = float(expression)  # propagate ValueError
value = int(fval * factor)  # propagate ValueError
if value < 1:
raise ValueError("number must be positive")
return value


def guess_python() -> int | None:
"""Estimate the number of processors using Python's os.cpu_count().

>>> guess_python() > 0
True
"""
return os.cpu_count()


def guess_nproc() -> int:
"""Estimate number of processors using coreutils' nproc.

>>> guess_nproc() > 0
True
"""
return positive_integer(
subprocess.check_output(["nproc"], encoding="ascii")
)


def guess_deb_build_parallel(
environ: typing.Mapping[str, str] = os.environ
) -> int | None:
"""Parse a possible parallel= assignment in a DEB_BUILD_OPTIONS environment
variable.

>>> guess_deb_build_parallel({})
>>> guess_deb_build_parallel({"DEB_BUILD_OPTIONS": "nocheck parallel=3"})
3
"""
try:
options = environ["DEB_BUILD_OPTIONS"]
except KeyError:
return None
for option in options.split():
if option.startswith("parallel="):
option = option.removeprefix("parallel=")
try:
return positive_integer(option)
except ValueError:
pass
return None


def guess_from_environment(
variable: str, environ: typing.Mapping[str, str] = os.environ
) -> int | None:
"""Read a number from an environment variable.

>>> guess_from_environment("CPUS", {"CPUS": 4})
4
>>> guess_from_environment("CPUS", {"other": 3})
"""
try:
return positive_integer(environ[variable])
except (KeyError, ValueError):
return None


def guess_memavailable() -> int:
"""Estimate the available memory from /proc/meminfo in bytes."""
with open("/proc/meminfo", encoding="ascii") as fh:
for line in fh:
if line.startswith("MemAvailable:"):
line = line.removeprefix("MemAvailable:").strip()
return 1024 * positive_integer(line.removesuffix("kB"))
raise RuntimeError("no MemAvailable line found in /proc/meminfo")


def guess_cgroup_memory() -> int | None:
"""Return the smalles "memory.high" or "memory.max" limit of the current
cgroup or any pare

Re: Removing manpages from libpam-modules to improve multi-arch

[Marvin Renich]

[Please don't CC me]

* Sam Hartman  [250115 14:45]:
> Do you actually have a system on which you want these man pages and on
> which the extra space of libpam-doc would be a problem?

No.

> Unless there's a compelling need, my answer is that I don't understand
> why manpages should be separated from other documentation in this instance.

I have a strong aversion to the mantras "disk space is cheap", "memory
is cheap", "network bandwidth is cheap", or any other denigration of
seemingly abundant resources.  They are the enemy of good programming
principles.

In this particular case, I don't think putting the man pages in with the
other docs is a problem.  But if every package did this, the bloat would
be significant.  I think it sets a bad precedent.

My original message was really responding to:

* Sam Hartman  [250115 11:44]:
> I'm not actually convinced that normal Debian users need man pages for
> all the pam modules on all Debian systems, and a suggests relationship
> should be sufficient.

I think you underestimate the amount these man pages are used and their
value.

The suggestion to create a new libpam-manpages was really just one way
to keep the status quo without bringing in the additional doc'n.  With a
Recommends relationship, it would allow installing libpam-modules
without the man pages, if desired, but would include them by default
(except where the user had opted out of installing Recommends by
default).

I am fine with putting the man pages in with libpam-modules-bin.

...Marvin

Bug#1093213: ITP: teakra -- DSi/3DS DSP emulator, (dis)assembler, and tester

[Andrea Pappacoda]

Package: wnpp
Severity: wishlist
Owner: Andrea Pappacoda 
X-Debbugs-Cc: debian-devel@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: teakra
  Version : 0.0+git20250115.6a173f5
  Upstream Contact: Weiyi Wang 
* URL : https://github.com/wwylele/teakra
* License : MIT (Expat)
  Programming Lang: C/C++
  Description : DSi/3DS DSP emulator, (dis)assembler, and tester

Teakra is an emulator, assembler, disassembler, and tester for XpertTeak, the
DSP used by the DSi and 3DS game consoles.

This package is a dependency of several Nintendo DS and 3DS emulators, like
melonDS (ITP bug #1050348) and Mikage.


-BEGIN PGP SIGNATURE-

iIoEARYIADIWIQS6VuNIvZRFHt7JcAdKkgiiRVB3pwUCZ4kJBBQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRBKkgiiRVB3p6ACAP93cuOWP6ocB5quNZksKWP7wqOsaFDx
xQhgzr0blhgPCQEAwDWmfxlU9UiVouhXKOcTYlpdott8Qs6+lv4bdMFwLA4=
=vtbQ
-END PGP SIGNATURE-

Bug#1093183: ITP: libpdl-opt-simplex-perl -- PDL implementation of simplex optimization algorithm

[Ed J]

Package: wnpp
Owner: Ed J 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org

* Package name: libpdl-opt-simplex-perl
  Version : 2.097
  Upstream Author : PerlDL Developers 
* URL : https://metacpan.org/release/PDL-Opt-Simplex
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : PDL implementation of simplex optimization algorithm


The algorithm is to move a "simplex" of N+1 points in the
N-dimensional search space according to certain rules. The main benefit of
the algorithm is that you do not need to calculate the derivatives of your
function.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Re: How to conditionally patch a package based on architecture with debhelper?

[Ben Collins]

On Thu, Jan 16, 2025 at 09:48:53AM -0500, Chris Knadle wrote:
> Greetings.
> 
> I have a situation with mumble where the build is breaking on armel
> architecture. Upstream has identified that this bug is due to the mumble
> "link" plugin containing atomic memory operations. I would like to
> conditionally patch the source plugins/CMakeLists.txt file based on
> architecutre to not build that one plugin for armel. CDBS apparently has a
> way of doing this [1] and I would like to find a solution for doing this
> with debhelper. I've been searching and haven't found anything quite
> fitting.

Can the patched code just look like:

#ifdef __ARMEL__
// Patched code
#else
// original code with atomic memory ops
#endif



-- 
 Ben Collins
 https://debian.org | https://ubuntu.com
 https://ben-collins.blogspot.com
 https://catchmobilehealth.com
 --
 3EC9 7598 1672 961A 1139  173A 5D5A 57C7 242B 22CF


signature.asc
Description: PGP signature

How to conditionally patch a package based on architecture with debhelper?

[Simon Richter]

Hi,

atomic operations require linking against libatomic — always have. Some 
architectures inline a few functions, which is how you get away with omitting 
the library on amd64 most of the time, but this is incorrect.

No architecture specific patch should be required here, adding libatomic 
everywhere is fine, possibly via
-Wl,--push-options,--as-needed,-latomic,--pop-options

(although as-needed is likely default anyway)

   Simon

Re: How to conditionally patch a package based on architecture with debhelper?

[Andrey Rakhmatullin]

On Thu, Jan 16, 2025 at 09:48:53AM -0500, Chris Knadle wrote:
> I have a situation with mumble where the build is breaking on armel
> architecture. Upstream has identified that this bug is due to the mumble
> "link" plugin containing atomic memory operations. I would like to
> conditionally patch the source plugins/CMakeLists.txt file based on
> architecutre to not build that one plugin for armel.

Consider instead unconditionally patching it in a way that disables the
building of that plugin on that arch.

> CDBS apparently has a way of doing this [1] and I would like to find a
> solution for doing this with debhelper. 

Nowadays changing the upstream source is handled by dpkg, not by d/rules.

> I suppose in a pinch I could build-depend on the 'patch' command and do
> something like this in debian/rules:
> 
> ifeq ($(DEB_HOST_ARCH),armel)
>         patch < debian/patches/armel/95-fix-build-armel.patch
> endif

If you do this don't forget to do the opposite in clean, as mandated by
the Policy.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1093223: RFH: tbsync -- Thunderbird/Lightning Add-On to support MS Exchange Calendar etc.

[Mechtilde Stehmann]

Package: wnpp
Severity: normal
X-Debbugs-Cc: tbs...@packages.debian.org, debian-devel@lists.debian.org, 
mechti...@debian.org
Control: affects -1 + src:tbsync

I request assistance with maintaining the tbsync package.

This should expand 6to dav-4-tbsync and eas-4-tbsync

The package description is:
 Synchronize Exchange ActiveSync accounts (contacts, tasks and
 calendars) to Thunderbird, supports Office 365, Outlook.com,
 Freenet, Strato, Hotmail, Kopano and other EAS compatible servers.

I have no longer access to an Exchange-Calender.

I need help to test the updates also for stable-proposal.

Re: Bug#1091394: nproc: add new option to reduce emitted processors by system memory

[Julien Plissonneau Duquène]

(trimming the Cc: list a bit now that the announcements are done, last 
Cc: to #1091394, followup on debian-devel)


Hi Helmut,

Le 2025-01-16 10:18, Helmut Grohne a écrit :


I'm attaching my proof of concept. Would you join forces and turn 
either

of these PoCs into a proper Debian package that could be used during
package builds? Once accepted, we may send patches to individual Debian
packages making use of it and call OOM FTBFS a packaging bug 
eventually.


I'm fine with that idea, and both PoCs use mostly the same logic (yours 
is a bit more advanced). Besides my personal distaste for Python ;) I 
implemented mine as a shell script so it can just be copied into 
packages for testing without introducing additional dependencies.


Before introducing a whole new package for either of the candidates I 
would try to submit it to devscripts though, rereading the thread it 
seems that you didn't try that yet, and a Python implementation is 
probably better suited for there (larger pool of potential contributors, 
easier to implement testing etc). Maybe you could open a draft merge 
request there and see how it goes?


Some comments about the PoC itself:
- for at least the Java builds, I would like to have a way to ignore x86 
"threads" in the number of processing units as once all actual cores are 
saturated with worker processes no further gains in throughput are 
expected with additional processes, with a risk of negative gain and a 
high memory cost; these Java processes are often heavily multithreaded 
anyway and already benefit from SMT where it's available
- exposing nproc options and processing further options from environment 
variables may make it easier to replace nproc invocations with the new 
script in existing Makefiles and build scripts.


Cheers,

--
Julien Plissonneau Duquène

Re: Bug#1093222: Minimizing build-arch for pam

[Simon McVittie]

On Thu, 16 Jan 2025 at 09:38:38 -0700, Sam Hartman wrote:
> But the meson setup call is in override_dh_auto_configure.
> I don't know at that point how to figure out of I am building arch all
> packages.

I find that it's often better to do this in terms of "am I building
package X?" instead of "am I building arch: all packages?" because that
way, you will also get the correct answer when dealing with build-profiles.

We do this a lot in GNOME and GNOME-adjacent packages. Something like this
(in this case taken from gobject-introspection, and enabling/disabling
the gtk_doc option depending on whether we are building the -doc package):

built_binaries := $(shell dh_listpackages)

configure_options = ... options you use unconditionally ...

ifeq ($(filter %-doc,$(built_binaries)),)
configure_options += -Dgtk_doc=false
else
configure_options += -Dgtk_doc=true
endif

override_dh_auto_configure:
dh_auto_configure -- $(configure_options)

Re: Bug#1091394: nproc: add new option to reduce emitted processors by system memory

[Niels Thykier]

Julien Plissonneau Duquène:
(trimming the Cc: list a bit now that the announcements are done, last 
Cc: to #1091394, followup on debian-devel)


Hi Helmut,

Le 2025-01-16 10:18, Helmut Grohne a écrit :


I'm attaching my proof of concept. Would you join forces and turn either
of these PoCs into a proper Debian package that could be used during
package builds? Once accepted, we may send patches to individual Debian
packages making use of it and call OOM FTBFS a packaging bug eventually.


I'm fine with that idea, and both PoCs use mostly the same logic (yours 
is a bit more advanced). Besides my personal distaste for Python ;) I 
implemented mine as a shell script so it can just be copied into 
packages for testing without introducing additional dependencies.


Before introducing a whole new package for either of the candidates I 
would try to submit it to devscripts though, rereading the thread it 
seems that you didn't try that yet, and a Python implementation is 
probably better suited for there (larger pool of potential contributors, 
easier to implement testing etc). Maybe you could open a draft merge 
request there and see how it goes?


Some comments about the PoC itself:
[...]

Cheers,




Putting the scripts into `devscripts` package would imply that 
`devscripts` becomes part of the `bootstrap essential` set of packages. 
I am not sure the `devscripts` maintainers are interested in that, 
because it implies you cannot arbitrarily add new Dependencies. As an 
example, if `devscripts` depends on even a single `arch:any` perl 
package, then the next `perl` transition could have `debhelper` become 
uninstallable, which is not going to be fun for anyone around at that time.


Additionally, `devscripts` seems to have a bit of "come and go"-style 
maintainership, so the average contributor will not have this caveat in 
mind making it even more likely that problem would occur down the line. 
the problem does not become visible immediately when you add the 
dependency. It first appears when `debhelper` is suddenly uninstallable 
and then it is too late.


Therefore, I strongly recommend *against* putting it into `devscripts`.

Other than that, I am looking forward to seeing this in sid (and later 
stable-backports).


Best regards,
Niels

PS: The `python` dependency of Helmut script is not a deal breaker 
itself. We have other bootstrap critical packages depending on python 
just as we have with perl. It is really about perl XS modules and python 
C modules maintained outside the interpreter packages, since they would 
need to be rebuilt during a transition (but then wait for `debhelper` to 
become installable, except `debhelper` needs the rebuilt version to be 
installable).





OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Removing manpages from libpam-modules to improve multi-arch

[Simon McVittie]

On Thu, 16 Jan 2025 at 09:41:51 -0700, Sam Hartman wrote:
> (We'd also need to do something about libpam0g-dev man pages).

Moving user-facing documentation from libpam0g into either
libpam-modules-bin or libpam-doc (depending how often you expect users to
need it), and developer documentation from libpam0g-dev into libpam-doc,
seems like it would make sense to me?

API reference material for C libraries is often in a -doc package, whether
its format is HTML, PDF or man pages.

smcv

Re: Bug#1093222: Minimizing build-arch for pam

[Niels Thykier]

Sam Hartman:

"Simon" == Simon McVittie  writes:


 Simon> On Thu, 16 Jan 2025 at 09:38:38 -0700, Sam Hartman wrote:
 >> But the meson setup call is in override_dh_auto_configure.  I
 >> don't know at that point how to figure out of I am building arch
 >> all packages.

 Simon> I find that it's often better to do this in terms of "am I
 Simon> building package X?" instead of "am I building arch: all
 Simon> packages?" because that way, you will also get the correct
 Simon> answer when dealing with build-profiles.

 Simon> We do this a lot in GNOME and GNOME-adjacent
 Simon> packages. Something like this (in this case taken from
 Simon> gobject-introspection, and enabling/disabling the gtk_doc
 Simon> option depending on whether we are building the -doc
 Simon> package):

 Simon> built_binaries := $(shell dh_listpackages)

Okay, so dh_listpackages is smart enough to know what kind of build it
is in even when called from override_dh_auto_configure?
I didn't know that, and yes it makes this easy.

I also had somehow missed the Build-Profiles binary package control
field.
To confirm, it would be reasonable to mark libpam-doc with

Build-Profiles:  



With some limitations, yes. The limitations for `dh_listpackages` are 
not applicable to this case, but it is a "here by dragons" area that can 
be confusing when you accidentally run into the dragon's nest. This mail 
is mostly to serve as a "caveat" for other participants, since the 
concrete case is fine.



The caveat:

When used **inside** an override or hook target as in this case, Yes. 
When used **outside** of a override or hook target, you might end up 
with surprising result.


See "Caveats with hook targets and makefile conditionals" from "man dh", 
which applies equally to variables used outside hook targets.


The implementation details is that `dh` exposes an internal ENV variable 
that any `Debian::Debhelper::Dh_Lib` based `dh_*` command reacts to that 
makes it pick up the `-a` or `-i` implied by `build-arch` or 
`build-indep` that triggered the build for `dh`.


However, `debian/rules` is run once **outside** a hook target (when `dh` 
scans for hook targets) in dry-run mode. During this parsing, 
`dh_listpackages` does not know which kind of build it is (`-b`, `-A`, 
or `-B`) and it therefore assumes a `-b` build listing all binary 
packages not excluded by Build-Profiles. The conditional must not cause 
any harm like shadowing a hook target during this dry-run, because then 
`dh` does not see the hook target and you will end up very confused by 
why `debhelper` is ignoring your override.


As said in the beginning, the example Simon gave does not have this 
problem, so that example should be fine. But be careful with 
`dh_listpackages` based conditionals outside override/hook targets. it 
is probably not what you want to spend your Debian time debugging. :)


Best regards,
Niels



OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Bug#1091394: nproc: add new option to reduce emitted processors by system memory

[Julien Plissonneau Duquène]

Hi,

Le 2025-01-16 18:36, Niels Thykier a écrit :
Putting the scripts into `devscripts` package would imply that 
`devscripts` becomes part of the `bootstrap essential` set of packages.


I didn't think about that and it effectively rules out devscripts for 
that purpose. Is there any existing "bootstrap essential" package that 
wasn't yet approached by Helmut and that could be interested in hosting 
that new tool?


Cheers,

--
Julien Plissonneau Duquène

Re: Removing manpages from libpam-modules to improve multi-arch

[Sam Hartman]

> "Guillem" == Guillem Jover  writes:

Guillem> Hi!
Guillem> On Wed, 2025-01-15 at 09:43:36 -0700, Sam Hartman wrote:
>> My proposal is to move the man pages into libpam-doc.  I'm not
>> actually convinced that normal Debian users need man pages for
>> all the pam modules on all Debian systems, and a suggests
>> relationship should be sufficient.  If people really want to
>> maintain the current level of man page presence, we could move
>> the manpages into libpam-modules-bin which is M-A: foreign.

Guillem> ISTM that moving them to libpam-modules-bin would be the
Guillem> better path forward, as it would not regress with missing
Guillem> man pages. I think having no man pages by default when
Guillem> installing programs, config or other such content, that
Guillem> previously had them would be rather unexpected (I certainly
Guillem> miss them when packages have no man pages at all or even
Guillem> provide no man pages by default). I don't think size should
Guillem> be considered an issue here given that the man pages were
Guillem> already shipped (and we expect them to be installed as per
Guillem> policy), and as mentioned in the thread people can filter
Guillem> them out if desired.

Helmut has argued for moving the docs into arch: all packages to
hopefully be able to reduce arch all build dependencies.
That sounds like a good argument to me.
(We'd also need to do something about libpam0g-dev man pages).

Guillem> (Perhaps if you are shuffling files around you could also
Guillem> consider whether moving /etc/security and
Guillem> /usr/share/pam-configs into libpam-modules-bin as well also
Guillem> makes sense, to avoid potentially weird semantics with
Guillem> refcounted conffiles and M-A:same? Not a blocker though,
Guillem> just a thought, while checking the contents.)

Will moving conffiles around like /etc/security just work even if they
are modified, or will that trigger a bunch of what to do about modified
conffile at install time warnings?


signature.asc
Description: PGP signature

Bug#1093222: Minimizing build-arch for pam

[Sam Hartman]

package: pam
version: 1.5.3-1
severity: wishlist
tags: help

> "Helmut" == Helmut Grohne  writes:
[talking about pam manpages]

Helmut> From a package building pov, I'd appreciate if you could
Helmut> also move the tools for building the manual pages to
Helmut> Build-Depends-Indep while you move them.

I think we still end up with a bunch of manpages in libpam0g-dev.
Although that's also M-A: same, so probably has similar issues, although
probably they come up less frequently than libpam-modules.

But let's say we move those man pages too.

I'd love to minimize build-depends-arch, but I don't know how.
In my meson setup call, I want to either enable or disable the docs
feature.
I realize I could leave it auto, but that has been too fragile in the
past as upstream changes their doc dependencies. So it is too easy to
get into a situation where upstream builds none of the docs because some
tool is not present.

But the meson setup call is in override_dh_auto_configure.
I don't know at that point how to figure out of I am building arch all
packages.

If someone can either give me some hints here or provide a patch, I'd
love to review it.


signature.asc
Description: PGP signature

Re: Bug#1093222: Minimizing build-arch for pam

[Sam Hartman]

> "Simon" == Simon McVittie  writes:

Simon> On Thu, 16 Jan 2025 at 09:38:38 -0700, Sam Hartman wrote:
>> But the meson setup call is in override_dh_auto_configure.  I
>> don't know at that point how to figure out of I am building arch
>> all packages.

Simon> I find that it's often better to do this in terms of "am I
Simon> building package X?" instead of "am I building arch: all
Simon> packages?" because that way, you will also get the correct
Simon> answer when dealing with build-profiles.

Simon> We do this a lot in GNOME and GNOME-adjacent
Simon> packages. Something like this (in this case taken from
Simon> gobject-introspection, and enabling/disabling the gtk_doc
Simon> option depending on whether we are building the -doc
Simon> package):

Simon> built_binaries := $(shell dh_listpackages)

Okay, so dh_listpackages is smart enough to know what kind of build it
is in even when called from override_dh_auto_configure?
I didn't know that, and yes it makes this easy.

I also had somehow missed the Build-Profiles binary package control
field.
To confirm, it would be reasonable to mark libpam-doc with

Build-Profiles:  

Re: How to conditionally patch a package based on architecture with debhelper?

[Chris Knadle]

On 1/16/25 11:10, Ben Collins wrote:

On Thu, Jan 16, 2025 at 09:48:53AM -0500, Chris Knadle wrote:

Greetings.

I have a situation with mumble where the build is breaking on armel
architecture. Upstream has identified that this bug is due to the mumble
"link" plugin containing atomic memory operations. I would like to
conditionally patch the source plugins/CMakeLists.txt file based on
architecutre to not build that one plugin for armel. CDBS apparently has a
way of doing this [1] and I would like to find a solution for doing this
with debhelper. I've been searching and haven't found anything quite
fitting.

Can the patched code just look like:

#ifdef __ARMEL__
// Patched code
#else
// original code with atomic memory ops
#endif


Thank you. From this good hint I found an additional [1] piece that may 
get the rest of the way
[And, ironic that this particular post on stackoverflow only received 
downvotes.]


--

# Store in CMAKE_DEB_HOST_ARCH var the current build architecture
# (Note: See link [2] below for details for this section)
execute_process(COMMAND
  dpkg-architecture
    -qDEB_HOST_ARCH
  OUTPUT_VARIABLE
    CMAKE_DEB_HOST_ARCH
  OUTPUT_STRIP_TRAILING_WHITESPACE
)

#And use that information later in CMakeLists

if(${CMAKE_DEB_HOST_ARCH} MATCHES "armhf")
  ...
elseif(${CMAKE_DEB_HOST_ARCH} MATCHES "i386")
  ...
else()
  ...
endif()

--

Looking at the manpage for dpkg-architecture, the variable I may want to 
conditionally build upon might be DEB_TARGET_ARCH rather than DEB_HOST_ARCH.


[1] 
https://stackoverflow.com/questions/11944060/how-to-detect-target-architecture-using-cmake


[2] https://cmake.org/cmake/help/latest/command/execute_process.html

   -- Chris

--
Chris Knadle
chris.kna...@coredump.us

Bug#1093226: ITP: golang-github-coder-quartz -- A Go time testing library for writing deterministic unit tests

[Daniel Swarbrick]

Package: wnpp
Severity: wishlist
Owner: Daniel Swarbrick 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian...@lists.debian.org

* Package name: golang-github-coder-quartz
  Version : 0.1.3-1
  Upstream Contact: Spike Curtis 
* URL : https://github.com/coder/quartz
* License : CC0-1.0
  Programming Lang: Go
  Description : A Go time testing library for writing deterministic unit 
tests

Quartz is a Go library that aims to facilitate the writing of deterministic
unit tests that:
.
1. execute quickly
2. don't flake
3. are straightforward to write and understand

This package is a new dependency of prometheus-alertmanager v0.28.0. I
will co-maintain this package as a member of the Debian Go Packaging Team.

Bug#1093218: ITP: image-garden -- tool for creating test virtual machines

[Zygmunt Krynicki]

Package: wnpp
Severity: wishlist
Owner: Zygmunt Krynicki 
X-Debbugs-Cc: debian-devel@lists.debian.org, m...@zygoon.pl

* Package name: image-garden
  Version : 0.1
  Upstream Contact: Zygmunt Krynicki 
* URL : http://gitlab.com/zygoon/image-garden 
* License : Apache-2.0 
  Programming Lang: Shell, Make
  Description : tool for creating test virtual machines

Image garden downloads and initializes operating system images, so that they
can be easily started with qemu, used for interactive login and exploratin or
connected remotely over ssh with a well-known username and password.

The package is useful for creating integration tests that run against
popular Linux distributions. It has been adopted by the upstream
AppArmor developers for exactly this purpose.

I plan to maintain it myself following the wider standards set by the
Debian community.

I will need a sponsor and I have an offer from a friendly DD already.

Re: Documentation field? (Was: Removing manpages from libpam-modules to improve multi-arch)

[Ben Collins]

On Wed, Jan 15, 2025 at 06:24:39PM -0500, Gioele Barabucci wrote:
> On 15/01/25 17:43, Sam Hartman wrote:
> > My proposal is to move the man pages into libpam-doc.
> > I'm not actually convinced that normal Debian users need man pages for
> > all the pam modules on all Debian systems, and a suggests relationship
> > should be sufficient.
> 
> Unrelated to the question at hand, but I was wondering: why doesn't
> d/control contain a "Documentation:" field?

Is there a proposal on this field at all? I ask because I'm interested
in knowning more about what you're suggesting. I can think of some syntax
that would be helpful. One that comes to mind is:

Package: libfoo-dev
Documentation: any(foo), rfc(2549)

Package: libfoo-doc
Provides-Documentation: doc-base(foo), manpages(foo)

It just seems to me that documentation would be topical and media-
grouped rather than a package naming paradigm. The RFC type could be
expanded to https://www.rfc-editor.org/rfc/rfc{ID}, for example.

-- 
 Ben Collins
 https://debian.org | https://ubuntu.com
 https://ben-collins.blogspot.com
 https://catchmobilehealth.com
 --
 3EC9 7598 1672 961A 1139  173A 5D5A 57C7 242B 22CF


signature.asc
Description: PGP signature

Re: Removing manpages from libpam-modules to improve multi-arch

[Bálint Réczey]

Hi,

On 2025. Jan 16., Thu at 8:17, Simon Richter  wrote:

> Hi,
>
> On 1/16/25 13:22, Russ Allbery wrote:
>
> > There are various things one can do to try to make the output of a man
> > page generator like that more consistent, but they don't fix the problem,
> > just reduce its frequency, unless Debian sets up to do a fully
> > reproducible build with pinned versions of everything (which I don't
> think
> > we want to do).
>
> Agreed, it's not a complete fix, but I'd expect the frequency of changes
> in the output besides the version number to be low enough for this to be
> the least-effort solution.
>
> If it means we need to trigger a rebuild of a few packages every few
> years, then this thread has already used more time.


I agree. It is very easy to detect file differences between multiarch
packages and scheduling binNMUs.

Since the described problem potentially affects all packages shipping man
pages with the binaries - which is the best practice - splitting man pages
from a single package to solve that particular problem sounds misdirected
effort.

Cheers,
Balint


>
> Simon
>
>

Re: Removing manpages from libpam-modules to improve multi-arch

[Guillem Jover]

Hi!

On Wed, 2025-01-15 at 09:43:36 -0700, Sam Hartman wrote:
> My proposal is to move the man pages into libpam-doc.
> I'm not actually convinced that normal Debian users need man pages for
> all the pam modules on all Debian systems, and a suggests relationship
> should be sufficient.
> If people really want to maintain the current level of man page
> presence,  we could move the manpages into libpam-modules-bin which is
> M-A: foreign.

ISTM that moving them to libpam-modules-bin would be the better
path forward, as it would not regress with missing man pages. I
think having no man pages by default when installing programs,
config or other such content, that previously had them would be
rather unexpected (I certainly miss them when packages have no man
pages at all or even provide no man pages by default). I don't think
size should be considered an issue here given that the man pages were
already shipped (and we expect them to be installed as per policy),
and as mentioned in the thread people can filter them out if desired.

(Perhaps if you are shuffling files around you could also consider
whether moving /etc/security and /usr/share/pam-configs into
libpam-modules-bin as well also makes sense, to avoid potentially
weird semantics with refcounted conffiles and M-A:same? Not a blocker
though, just a thought, while checking the contents.)

Thanks,
Guillem

How to conditionally patch a package based on architecture with debhelper?

[Chris Knadle]

Greetings.

I have a situation with mumble where the build is breaking on armel 
architecture. Upstream has identified that this bug is due to the mumble 
"link" plugin containing atomic memory operations. I would like to 
conditionally patch the source plugins/CMakeLists.txt file based on 
architecutre to not build that one plugin for armel. CDBS apparently has 
a way of doing this [1] and I would like to find a solution for doing 
this with debhelper. I've been searching and haven't found anything 
quite fitting.


I suppose in a pinch I could build-depend on the 'patch' command and do 
something like this in debian/rules:


ifeq ($(DEB_HOST_ARCH),armel)
        patch < debian/patches/armel/95-fix-build-armel.patch
endif

... but I'm hoping something else already exists for doing this with the 
normal build system or debhelper/dh.


If someone has a better solution, please let me know.

Thanks much.

[1] https://lists.debian.org/debian-devel/2006/11/msg01005.html

   -- Chris

--
Chris Knadle
chris.kna...@coredump.us
Debian developer

Re: Removing manpages from libpam-modules to improve multi-arch

[Russ Allbery]

Bálint Réczey  writes:
> On 2025. Jan 16., Thu at 8:17, Simon Richter  wrote:

>> Agreed, it's not a complete fix, but I'd expect the frequency of
>> changes in the output besides the version number to be low enough for
>> this to be the least-effort solution.

>> If it means we need to trigger a rebuild of a few packages every few
>> years, then this thread has already used more time.

> I agree. It is very easy to detect file differences between multiarch
> packages and scheduling binNMUs.

> Since the described problem potentially affects all packages shipping
> man pages with the binaries - which is the best practice - splitting man
> pages from a single package to solve that particular problem sounds
> misdirected effort.

Hm, I would say that the energy put into finding workarounds for varying
content in multiarch packages and scheduling binNMUs would be the more
wasted effort in the long run. I would advise every multiarch package
shipping man pages to move them into a separate package, which is a
one-time fix that makes the problem go away for that package.

To me, this is an extension of the long-standing advice that every shared
library should be isolated in its own package and not include other files.
It's for a somewhat similar reason, too: for shared libraries, this is to
avoid conflicts on SONAME bumps, and in this case, it's to avoid conflicts
on binNMUs.

There has never been a best-practice requirement that the man pages be in
the same binary package, only that they be installed when the package is
installed, so putting them in a dependency has always been fine. I think
the concern here may just be that the effective dependency on libpam-doc
is Suggests and people would rather it be something stronger. That's an
argument for putting them in libpam-runtime, even though it's not a
perfect semantic fit, because that package is Priority: required.

-- 
Russ Allbery (r...@debian.org)  

Re: How to conditionally patch a package based on architecture with debhelper?

[Andrey Rakhmatullin]

On Thu, Jan 16, 2025 at 01:26:39PM -0500, Chris Knadle wrote:
> Looking at the manpage for dpkg-architecture, the variable I may want to
> conditionally build upon might be DEB_TARGET_ARCH rather than DEB_HOST_ARCH.

No, it should be DEB_HOST_ARCH.
https://gcc.gnu.org/onlinedocs/gccint/Configure-Terms.html (required
reading for everyone)


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: How to conditionally patch a package based on architecture with debhelper?

[Chris Knadle]

On 1/16/25 10:52, Simon Richter wrote:

Hi,

atomic operations require linking against libatomic — always have. 
Some architectures inline a few functions, which is how you get away 
with omitting the library on amd64 most of the time, but this is 
incorrect.


No architecture specific patch should be required here, adding 
libatomic everywhere is fine, possibly via

-Wl,--push-options,--as-needed,-latomic,--pop-options

(although as-needed is likely default anyway)

   Simon


I'm assuming this also requires adding libatomic1 as a build dependency.
Huh. So there's a chance this an fix the build for armel too. Nice.

Thanks.

  -- Chris

Chris Knadle
chris.kna...@coredump.us

Re: How to conditionally patch a package based on architecture with debhelper?

[Johannes Schauer Marin Rodrigues]

Quoting Chris Knadle (2025-01-16 19:26:39)
> Looking at the manpage for dpkg-architecture, the variable I may want to
> conditionally build upon might be DEB_TARGET_ARCH rather than DEB_HOST_ARCH.

above the VARIABLES section in that man page there is the TERMS section which
explains:


   target machine
   The machine the compiler is building for, or the emulator will run
   code for.  This is only needed when building a cross-toolchain (or
   emulator), one that will be built on the build architecture, to be
   run on the host architecture, and to build (or run emulated) code
   for the target architecture.

Unless you are building a compiler, you do not need to concern yourself with
the "target" architecture. Debian is using the GNU terminology and wRAR already
linked the relevant GNU documentation in the other mail.

Thanks!

cheers, josch

signature.asc
Description: signature

What is going on with atomics? (was: How to conditionally patch a package based on architecture with debhelper?)

[Johannes Schauer Marin Rodrigues]

Hi Simon,

Quoting Simon Richter (2025-01-16 16:52:19)
> atomic operations require linking against libatomic — always have. Some
> architectures inline a few functions, which is how you get away with omitting
> the library on amd64 most of the time, but this is incorrect.
> 
> No architecture specific patch should be required here, adding libatomic 
> everywhere is fine, possibly via
> -Wl,--push-options,--as-needed,-latomic,--pop-options
> 
> (although as-needed is likely default anyway)

I find this very interesting. I am fighting -latomic linking issues for quite a
while now and what you just said makes me think that I am in severe lack of
understanding here. Can you elaborate?

My specific situation is:

src:vcmi FTBFS on armel unless I apply this patch:

https://sources.debian.org/src/vcmi/1.5.7%2Bdfsg-1/debian/patches/fix-armel-atomics.patch/

After more research together with vcmi upstream involvement I found out that
linking vcmi against atomic is *only* required because it uses
tbb::parallel_for from oneTBB: 
https://github.com/uxlfoundation/oneTBB/issues/1454

And then others have linked me to this GCC bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358

So I'm at a loss at deciding who is at fault and who should be fixing
something. You say this should work out-of-the-box on amd64 mostly but
everything I have come across handling std::atomic types builds fine on all
architectures -- except armel. So which is the thing that gets things wrong
here?

 - armel?
 - g++?
 - cmake?
 - oneTBB?
 - vcmi?

Who should be patched? Relevant Debian bugs are #1089991 and #1088922

I'd very much welcome to be enlightened by you or anybody else on this list. :)

Thanks!

cheers, josch

signature.asc
Description: signature

Re: Removing manpages from libpam-modules to improve multi-arch

[Sam Hartman]

> "Simon" == Simon Richter  writes:

Simon> Hi,
Simon> On 1/16/25 01:43, Sam Hartman wrote:

>> For a while we just built the man pages but if any of the docbook
>> tools changed between one arch build and another, we'd end up
>> with m-a uninstallable packages.

Simon> Can this be fixed by removing the "Generator:" comment in the
Simon> generated manpage, and possibly clamping the included date to
Simon> SOURCE_DATE_EPOCH?

Patches welcome for clamping the included date if that's not already
being done by something.
I agree with Russ that I want to move the man pages out of multi-arch:
same packages, but would welcome patches to make the build more
reproducible.

You raised the issue that we want man pages to accompany their binary.
It's fairly rare for binaries in /usr/bin or /usr/sbin to be in m-a:
same packages.
I think for libraries, we want the man page to be in the -dev package,
and that's where I think we really start running into trouble.
Cross building encourages us to make those -dev packages M-A: same.
I think that I might generally agree with you that scheduling bin NMUs
when -dev packages get out of sync might be sufficient.
If you can give me clean patches to make libpam0g-dev's man pages
reproducible (or spend the effort to confirm they already are), I'll
leave the dev man pages there even though it is M-A: same.

pages 


signature.asc
Description: PGP signature

Re: What is going on with atomics? (was: How to conditionally patch a package based on architecture with debhelper?)

[Andrey Rakhmatullin]

On Thu, Jan 16, 2025 at 08:16:46PM +0100, Johannes Schauer Marin Rodrigues 
wrote:
> > atomic operations require linking against libatomic — always have. Some
> > architectures inline a few functions, which is how you get away with 
> > omitting
> > the library on amd64 most of the time, but this is incorrect.
> > 
> > No architecture specific patch should be required here, adding libatomic 
> > everywhere is fine, possibly via
> > -Wl,--push-options,--as-needed,-latomic,--pop-options
> > 
> > (although as-needed is likely default anyway)
> 
> I find this very interesting. I am fighting -latomic linking issues for quite 
> a
> while now and what you just said makes me think that I am in severe lack of
> understanding here. Can you elaborate?
> 
> My specific situation is:
> 
> src:vcmi FTBFS on armel unless I apply this patch:
> 
> https://sources.debian.org/src/vcmi/1.5.7%2Bdfsg-1/debian/patches/fix-armel-atomics.patch/
> 
> After more research together with vcmi upstream involvement I found out that
> linking vcmi against atomic is *only* required because it uses
> tbb::parallel_for from oneTBB: 
> https://github.com/uxlfoundation/oneTBB/issues/1454
> 
> And then others have linked me to this GCC bug:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358
> 
> So I'm at a loss at deciding who is at fault and who should be fixing
> something. You say this should work out-of-the-box on amd64 mostly but
> everything I have come across handling std::atomic types builds fine on all
> architectures -- except armel. So which is the thing that gets things wrong
> here?
> 
>  - armel?
>  - g++?
>  - cmake?
>  - oneTBB?
>  - vcmi?

Without having any special knowledge about this and skimming through the
linked GCC bug I assume that until (unless?) GCC starts adding -latomic
implicitly (which is what the bug and patches linked in it are about)
it's the software upstream's fault, and no upstreams actually care about
armel (and why would they).

See also the armel/upstream-support cell on
https://release.debian.org/testing/arch_qualify.html


-- 
WBR, wRAR


signature.asc
Description: PGP signature

lintian.debian.org is ON (Re: lintian.debian.org off ?)

[Otto Kekäläinen]

Hi all!

If you haven't noticed, lintian.debian.org has been online now for
almost 4 months.

A special thanks for that goes to Nicolas Peugnet for creating
lintian-ssg that generates the site, and Louis-Philippe Véronneau
(pollo) for taking care of Lintian!

After lintian.debian.org went offline in the fall of 2023, and it was
raised on this mailing list on Sept 22, 2023 by Jérémy, I volunteered
to fix the same week, and repeated that offer in November and again in
May 2024, but was basically told repeatedly that it is impossible for
me to help with anything.

Thus, the fact that Louis-Philippe and Nicolas eventually still
managed to push enough later in 2024 to get it back online is no small
achievement.

I want to thank them once more publicly for their efforts, and I hope
they continue their work on Lintian and related software for a long
time.

On Fri, 22 Sept 2023 at 03:05, Jérémy Lal  wrote:
>
> Hi,
>
> Host lintian.debian.org not found: 3(NXDOMAIN)
>
> is this expected ?
>
> Jérémy
>

Re: Canonical way for a package to set an environment variable

[Soren Stoutner]

Santiago,

On Thursday, January 16, 2025 1:50:15 PM MST Santiago Vila wrote:
> El 16/1/25 a las 21:01, Soren Stoutner escribió:
> > Is there a canonical way for a package to set an environment variable?
> 
> You should try to find another way, because Debian Policy 9.9 says this:
> > Programs installed on the system PATH (/bin, /usr/bin, /sbin, /usr/sbin, 
or
> > similar directories) must not > depend on custom environment variable
> > settings to get reasonable defaults.

Thanks for the Debian policy reference.  I will patch the Qt WebEngine source 
to achieve this without the need for an environment variable.

-- 
Soren Stoutner
so...@debian.org

signature.asc
Description: This is a digitally signed message part.

Re: Removing manpages from libpam-modules to improve multi-arch

[Simon Richter]

Hi,

On 1/17/25 05:14, Sam Hartman wrote:


With the exception of Simon Richter, we appear to be agreed that
avoiding man pages in m-a: same packages is good.


I mean, this is specifically about the manpages included in 
libpam-modules, which are at the intersection of


 - likely to be useful when the full -doc package is not installed
 - in a m-a:same package
 - built with a tool that insists on inserting a comment with its own 
version number into output files


So generalizing this to a rule to not ship manpages in m-a:same packages 
is overly broad -- basically we'd have to give every -dev package 
containing manual pages a -doc package, which is not really economical, 
especially when it's only a problem for generated manpages, and the 
differences between versions of the file are in comment lines.


For libpam-modules itself, because there is a -runtime package already, 
moving the manpages there is a good solution, but it's not something I 
believe should become a general rule, because there absolutely are use 
cases for user facing documentation shipped with library packages.


   Simon

Bug#1093266: ITP: golang-github-owenrumney-go-sarif -- Sarif: Static Analysis Results Interchange Format (Go library)

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: golang-github-owenrumney-go-sarif
  Version : 2.3.3-1
  Upstream Author : Owen
* URL : https://github.com/owenrumney/go-sarif
* License : public domain / unlicense.org
  Programming Lang: Go
  Description : Sarif: Static Analysis Results Interchange Format (Go 
library)

 SARIF is the Static Analysis Results Interchange Format, this project
 seeks to provide a simple interface to generate reports in the SARIF
 format.

This package is used by github.com/in-toto/go-witness which is used by
github.com/in-toto/witness that I'm packaging.

https://salsa.debian.org/go-team/packages/golang-github-owenrumney-go-sarif
https://salsa.debian.org/jas/golang-github-owenrumney-go-sarif/-/pipelines

/Simon


signature.asc
Description: PGP signature

Re: How to conditionally patch a package based on architecture with debhelper?

[Chris Knadle]

On 1/16/25 14:50, Andrey Rakhmatullin wrote:

On Thu, Jan 16, 2025 at 01:54:05PM -0500, Chris Knadle wrote:

atomic operations require linking against libatomic — always have. Some
architectures inline a few functions, which is how you get away with
omitting the library on amd64 most of the time, but this is incorrect.

No architecture specific patch should be required here, adding libatomic
everywhere is fine, possibly via
-Wl,--push-options,--as-needed,-latomic,--pop-options

(although as-needed is likely default anyway)

    Simon

I'm assuming this also requires adding libatomic1 as a build dependency.

ITYM libgcc-14-dev, and it's in build-essential.


i.e. no new build depends needed. Understood, thanks

Chris Knadle
chris.kna...@coredump.us

Bug#1093262: ITP: golang-github-spdx-tools-golang -- Collection of Go packages to work with SPDX files

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: golang-github-spdx-tools-golang
  Version : 0.5.5-1
  Upstream Author : SPDX
* URL : https://github.com/spdx/tools-golang
* License : Apache-2.0 or GPLv2+, CC-BY-4.0
  Programming Lang: Go
  Description : Collection of Go packages to work with SPDX files

 SPDX tools-golang is a collection of Go packages intended to make it
 easier for Go programs to work with SPDX® files: https://spdx.dev/

This package is used by github.com/in-toto/go-witness which is used by
github.com/in-toto/witness that I'm packaging.

https://salsa.debian.org/go-team/packages/golang-github-spdx-tools-golang
https://salsa.debian.org/jas/golang-github-spdx-tools-golang/-/pipelines

/Simon


signature.asc
Description: PGP signature

Canonical way for a package to set an environment variable

[Soren Stoutner]

Is there a canonical way for a package to set an environment variable?

Background:

Systemd parses files in /etc/environment.d/
Sysvinit parses the single file /etc/environment
Finit parses file in /etc/finit.d/

  Why can’t we all just get along?

It is easy for a package to add or remove files from /etc/environment.d/.  It 
is more tricky to edit /etc/environment.  And having to do it in (potentially) 
three locations seems inefficient.


1.  Is there some other way for a package to set a global environment 
variable?

2.  If not, would it be advisable or possible to patch Sysvinit and Finit to 
parse /etc/environment.d so this could all be handled from one place?


Specific problem prompting the question (you can skip this part unless you like 
the gory details):

Qt WebEngine is an HTML rendering engine based on the Chromium source code 
shipped as part of Qt (and KDE) that renders things like HTML documentation, 
HTML emails, and is also used by various web browsers.  Chromium uses a spell 
checking system based on Hunspell, but in their “wisdom” they decided to 
customize it by creating a binary dictionary format instead of using the plain 
text Hunspell format.  Qt WebEngine inherits this design.  Chromium ships a 
tool that converts the standard Hunspell files into the binary .bdic format.  
Trixie will release with most Hunspell packages shipping these files in /usr/
share/hunspell-bdic/.

Qt WebEngine contains a section of code that looks for these dictionaries in a 
number of locations, including individual user profiles.  One of the locations 
it checks is the directory defined by the QTWEBENGINE_DICTIONARIES_PATH 
variable.  The revelant code is at:

https://sources.debian.org/src/qt6-webengine/6.7.2%2Bdfsg2-1/src/core/
web_engine_library_info.cpp/#L243

The initial discussion about how to ship .bdic binary dictionary files in 
Debian was at:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020387

The result of this was the following policy:

The Qt packages will install the following system-wide environment variable in 
/etc/environment.d/ so that programs that use Qt WebEngine will be able to find 
the .bdic dictionaries:

QTWEBENGINE_DICTIONARIES_PATH=/usr/share/hunspell-bdic/

https://salsa.debian.org/debian/dictionaries-common/-/blob/master/policy/dsdt-policy.xml.in?ref_type=heads#L1437

At the time we assumed that would be sufficient for any Debian system, but we 
later learned that init systems besides Systemd don’t parse /etc/
environment.d/.

There are several ways we could proceed with this particular problem.

1.  Patch Qt WebEngine on Debian to always look in /usr/share/hunspell-bdic/.
2.  Add the environment variable to /etc/environment.d/ and document in 
README.Debian that users need to handle their own environment variable with 
other init systems.
3.  Add the environment variable to all known init environment variable 
locations.
4.  Add the environment variable somewhere else, like /etc/X11/Xsession.d/.

It would be possible to do 1, but it isn’t my first choice because it would 
modify upstream Qt WebEngine behavior in a way that some user might expect not 
to be modified.  Also, this would only solve the problem for this package.  I 
assume that at some point some other Debian package will have a need to set a 
system-wide environment variable.

I have already implemented 2 for Privacy Browser, one of the packages I 
maintain.  But it seems suboptimal to require users to set this environment 
variable themselves, even for uncommon init systems.

https://salsa.debian.org/soren/privacybrowser/-/blob/master/debian/
README.Debian?ref_type=heads

Option 3 gets a bit complex, because there are two current packages providing 
Qt WebEngine that could be concurrently installed (Qt 5 WebEngine and Qt 6 
WebEngine), both of them need to set this variable.  There isn’t a problem 
with it being set twice by two separate files in /etc/environment.d/, but using 
sed or some other tool to edit /etc/environment could get a little dicey as 
one or both of the packages are installed and uninstalled.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1092726

Option 4 is fine with me in this case if it works (does Wayland parse 
environment variables from /etc/X11/Xsession.d?), but it is only a solution 
for graphical programs.  And again, I would imagine that at some point there 
will be a Debian package that needs a way to set an environment variable 
system-wide, even when no graphical environment is running.

-- 
Soren Stoutner
so...@debian.org

signature.asc
Description: This is a digitally signed message part.

Re: Canonical way for a package to set an environment variable

[Santiago Vila]

El 16/1/25 a las 21:01, Soren Stoutner escribió:

Is there a canonical way for a package to set an environment variable?


You should try to find another way, because Debian Policy 9.9 says this:

Programs installed on the system PATH (/bin, /usr/bin, /sbin, /usr/sbin, or similar directories) must not > depend on custom environment variable settings to get reasonable defaults. 


Thanks.

Bug#1093248: ITP: golang-github-bahlo-generic-list-go -- Go container/list but with generics

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: golang-github-bahlo-generic-list-go
  Version : 0.2.0-1
  Upstream Author : Arne Bahlo
* URL : https://github.com/bahlo/generic-list-go
* License : BSD-3-clause
  Programming Lang: Go
  Description : Go container/list but with generics

 Go container/list (https://pkg.go.dev/container/list) but with generics.
 .
 The code is based on container/list in go1.18beta2.

This packages is a build dependency of github.com/wk8/go-ordered-map
which is a build dependency of github.com/invopop/jsonschema which is a
build dependency of github.com/in-toto/witness that I'm packaging.

https://salsa.debian.org/go-team/packages/golang-github-bahlo-generic-list-go
https://salsa.debian.org/jas/golang-github-bahlo-generic-list-go/-/pipelines

/Simon


signature.asc
Description: PGP signature

Bug#1093249: ITP: golang-github-wk8-go-ordered-map -- Optimal implementation of ordered maps for Golang

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: golang-github-wk8-go-ordered-map
  Version : 2.1.8-1
  Upstream Author : Jean Rougé
* URL : https://github.com/wk8/go-ordered-map
* License : Apache-2.0
  Programming Lang: Go
  Description : Optimal implementation of ordered maps for Golang

 Golang Ordered Maps
 .
 Same as regular maps, but also remembers the order in which keys were
 inserted, akin to Python's collections.OrderedDicts
 (https://docs.python.org/3.7/library/collections.html#ordereddict-
 objects).
 .
 It offers the following features:
 .
  * optimal runtime performance (all operations are constant time)
  * optimal memory usage (only one copy of values, no unnecessary memory
allocation)
  * allows iterating from newest or oldest keys indifferently, without
memory copy, allowing to break the iteration, and in time linear to the
number of keys iterated over rather than the total length of the
ordered map
  * supports any generic types for both keys and values. If you're
running go < 1.18, you can use version 1 (https://github.com/wk8/go-
ordered-map/tree/v1) that takes and returns generic interface{}s instead
of using generics
  * idiomatic API, akin to that of container/list
(https://golang.org/pkg/container/list)
  * support for JSON and YAML marshalling
 .
 Documentation
 .
 The full documentation is available on pkg.go.dev
 (https://pkg.go.dev/github.com/wk8/go-ordered-map/v2).

This packages is a build dependency of github.com/invopop/jsonschema
which is a build dependency of github.com/in-toto/witness that I'm
packaging.

https://salsa.debian.org/go-team/packages/golang-github-wk8-go-ordered-map
https://salsa.debian.org/jas/golang-github-wk8-go-ordered-map/-/pipelines

/Simon


signature.asc
Description: PGP signature

Bug#1093250: ITP: golang-github-invopop-jsonschema -- Generate JSON Schemas from Go types

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: golang-github-invopop-jsonschema
  Version : 0.13.0-1
  Upstream Author : Invopop
* URL : https://github.com/invopop/jsonschema
* License : Expat
  Programming Lang: Go
  Description : Generate JSON Schemas from Go types

 This package can be used to generate JSON Schemas (http://json-
 schema.org/latest/json-schema-validation.html) from Go types through
 reflection.
 .
  * Supports arbitrarily complex types, including interface{}, maps,
slices, etc.
  * Supports json-schema features such as minLength, maxLength, pattern,
format, etc.
  * Supports simple string and numeric enums.
  * Supports custom property fields via the jsonschema_extras struct tag.
 .
 This repository is a fork of the original jsonschema
 (https://github.com/alecthomas/jsonschema) by @alecthomas
 (https://github.com/alecthomas). At Invopop (https://invopop.com) we use
 jsonschema as a cornerstone in our GOBL library
 (https://github.com/invopop/gobl), and wanted to be able to continue
 building and adding features without taking up Alec's time. There have
 been a few significant changes that probably mean this version is a not
 compatible with with Alec's:
 .
  * The original was stuck on the draft-04 version of JSON Schema, we've
now moved to the latest JSON Schema Draft 2020-12.
  * Schema IDs are added automatically from the current Go package's URL
in order to be unique, and can be disabled with the Anonymous option.
  * Support for the FullyQualifyTypeName option has been removed. If you
have conflicts, you should use multiple schema files with different
IDs, set the DoNotReference option to true to hide definitions
completely, or add your own naming strategy using the Namer property.
  * Support for yaml tags and related options has been dropped for the
sake of simplification. There were a few inconsistencies
(https://github.com/invopop/jsonschema/pull/21) around this that have
now been fixed.

This packages is a build dependency of github.com/in-toto/witness that
I'm packaging.

https://salsa.debian.org/go-team/packages/golang-github-invopop-jsonschema
https://salsa.debian.org/jas/golang-github-invopop-jsonschema/-/pipelines

/Simon


signature.asc
Description: PGP signature

Re: Bug#1091394: nproc: add new option to reduce emitted processors by system memory

[Ángel]

On 2025-01-16 at 10:18 +0100, Helmut Grohne wrote:
> Hi Julien,
> 
> On Mon, Jan 13, 2025 at 07:00:01PM +0100, Julien Plissonneau Duquène
> wrote:
> > Let's start with this then. I implemented a PoC prototype [1] as a
> > shell
> > script that is currently fairly linux-specific and doesn't account
> > for
> > cgroup limits (yet?). Feedback is welcome (everything is open for
> > discussion
> > there, including the name) and if there is enough interest I may
> > end up
> > packaging it or submitting it to an existing collection (I am
> > thinking about
> > devscripts).
> 
> I'm sorry for not having come back earlier and thus caused duplicaton
> of
> work. I had started a Python-based implementation last year and then
> dropped the ball over other stuff. It also implements the --require-
> mem
> flag in the way you suggested. It parses DEB_BUILD_OPTIONS,
> RPM_BUILD_NCPUS and CMAKE_BUILD_PARALLEL_LEVEL and also considers
> cgroup
> memory limits. I hope this captures all of the feedback I got during
> discussions and research.
> 
> I'm attaching my proof of concept. Would you join forces and turn
> either
> of these PoCs into a proper Debian package that could be used during
> package builds? Once accepted, we may send patches to individual
> Debian
> packages making use of it and call OOM FTBFS a packaging bug
> eventually.
> 
> Helmut

The script looks good, and easy to read. It wouldn't be hard to
translate it to another language if needed to drop the python
dependency (but that would increase the nloc)

I find this behavior a bit surprising:

$ python3 guess_concurrency.py --min 10 --max 2
10

If there is a minimum limit, it is returned, even if that violates the
max. It makes some sense to pick something but I as actually expecting
an error to the above.

The order of processing the cpus is a bit awkward as well.

The order it uses is CMAKE_BUILD_PARALLEL_LEVEL, DEB_BUILD_OPTIONS,
RPM_BUILD_NCPUS, --detect , nproc/os.cpu_count()

But the order in the code is 4, 5, 3, 2, 1
Not straightforward.
Also, it is doing actions such as running external program nproc even
it if's going to be discarded later. (nproc is in an essential package,
I know, but still)

Also, why would the user want to manually specify between nptoc and
os.cpu_count()?

I would unconditionally call nproc, with a fallback to os.cpu_count()
if that fails (I'm assuming nproc may be smarter than os.cpu_count(),
otherwise one could use cpu_count() always)

I suggest doing:

def main() -> None:
parser = argparse.ArgumentParser()
parser.add_argument(
"--count",
action="store",
default=None,
metavar="NUMBER",
help="supply a processor count",
)

(...)

args = parser.parse_args()
guess = None
try:
if args.count:
guess = positive_integer(args.count)
except ValueError:
parser.error("invalid argument to --count")
guess = guess or guess_from_environment("CMAKE_BUILD_PARALLEL_LEVEL")
guess = guess or guess_deb_build_parallel()
guess = guess or guess_from_environment("RPM_BUILD_NCPUS")
if not guess:
try:
guess = guess_nproc()
finally:
guess = guess or guess_python()



Additionally, the --ignore argument of nproc(1) might be of use for
this script as well.


Best regards

Ángel

Bug#1093257: ITP: golang-github-edwarnicke-gitoid -- Golang libraries for computing git object ids (gitoids)

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: golang-github-edwarnicke-gitoid
  Version : 0.0~git20220710.1be5bfd-1
  Upstream Author : Ed Warnicke
* URL : https://github.com/edwarnicke/gitoid
* License : Apache-2.0
  Programming Lang: Go
  Description : Golang libraries for computing git object ids (gitoids)

 Gitoid provides a simple library to compute gitoids (git object ids)

This package is needed by github.com/in-toto/go-witness

https://salsa.debian.org/go-team/packages/golang-github-edwarnicke-gitoid
https://salsa.debian.org/jas/golang-github-edwarnicke-gitoid/-/pipelines

/Simon


signature.asc
Description: PGP signature

Re: How to conditionally patch a package based on architecture with debhelper?

[Andrey Rakhmatullin]

On Thu, Jan 16, 2025 at 01:54:05PM -0500, Chris Knadle wrote:
> > atomic operations require linking against libatomic — always have. Some
> > architectures inline a few functions, which is how you get away with
> > omitting the library on amd64 most of the time, but this is incorrect.
> > 
> > No architecture specific patch should be required here, adding libatomic
> > everywhere is fine, possibly via
> > -Wl,--push-options,--as-needed,-latomic,--pop-options
> > 
> > (although as-needed is likely default anyway)
> > 
> >    Simon
> 
> I'm assuming this also requires adding libatomic1 as a build dependency.

ITYM libgcc-14-dev, and it's in build-essential.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Let's make 2025 a year when code reviews became common in Debian

[Andreas Tille]

Hi Gioele,

Am Wed, Jan 15, 2025 at 06:38:48PM +0100 schrieb Gioele Barabucci:
> Please note that although the package has a repo on Salsa, MRs there
> are/were explicitly disabled, at least for non-DDs (see the postscriptum in
> [1], I see they are available now). Therefore were the commits in my
> personal repo linked in the report in the BTS.

I guess this is due to some unfortunate default.  MRs are possible now in
this repository.

Kind regards
   Andreas. 

-- 
https://fam-tille.de

Bug#1093252: ITP: witness -- pluggable framework for software supply chain risk management

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: witness
  Version : 0.7.0-1
  Upstream Author : in-toto
* URL : https://witness.dev/
https://github.com/in-toto/witness
* License : Apache-2.0
  Programming Lang: Go
  Description : pluggable framework for software supply chain risk 
management

 What does Witness do?
 .
 ✏️ **Attests** - Witness is a dynamic CLI tool that integrates into
 pipelines and infrastructure to create an audit trail for your
 software's entire journey through the software development lifecycle
 (SDLC) using the in-toto specification.
 .
 **🧐 Verifies** - Witness also features its own policy engine with
 embedded support for OPA Rego, so you can ensure that your software was
 handled safely from source to deployment.
 .
 What can you do with Witness?
 .
  * Verify how your software was produced and what tools were used
  * Ensure that each step of the supply chain was completed by authorized
users and machines
  * Detect potential tampering or malicious activity
  * Distribute attestations and policy across air gaps
 .
 Key Features
 .
  * Integrations with GitLab, GitHub, AWS, and GCP.
  * Designed to run in both containerized and non-containerized
environments **without** elevated privileges.
  * Implements the in-toto specification (including ITE-5, ITE-6 and ITE-7)
  * An embedded OPA Rego policy engine for policy enforcement
  * Keyless signing with Sigstore and SPIFFE/SPIRE
  * Integration with RFC3161 compatible timestamp authorities
  * Process tracing and process tampering prevention (Experimental)
  * Attestation storage with Archivista (https://github.com/in-
toto/archivista)

https://salsa.debian.org/go-team/packages/witness
https://salsa.debian.org/jas/witness/-/pipelines

/Simon


signature.asc
Description: PGP signature

Bug#1093259: ITP: golang-github-spdx-gordf -- parse RDF files using RDF/XML format (Go library)

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: golang-github-spdx-gordf
  Version : 0.0~git20221230.b735bd5-1
  Upstream Author : SPDX
* URL : https://github.com/spdx/gordf
* License : Expat
  Programming Lang: Go
  Description : parse RDF files using RDF/XML format (Go library)

 gordf is a package which provides a parser for RDF files linearized
 using RDF/XML format. It will be used to represent the rdf files in
 memory and write back in possibly different formats like json, and xml.

This package is used by github.com/spdx/tools-golang which is used by
github.com/in-toto/go-witness which is used by
github.com/in-toto/witness that I'm packaging.

https://salsa.debian.org/go-team/packages/golang-github-spdx-gordf
https://salsa.debian.org/jas/golang-github-spdx-gordf/-/pipelines

/Simon


signature.asc
Description: PGP signature

Bug#1093260: ITP: golang-github-kimmachinegun-automemlimit -- Automatically set GOMEMLIMIT to match Linux cgroups(7) memory limit

[Daniel Swarbrick]

Package: wnpp
Severity: wishlist
Owner: Daniel Swarbrick 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian...@lists.debian.org

* Package name: golang-github-kimmachinegun-automemlimit
  Version : 0.7.0-1
  Upstream Contact: Geon Kim 
* URL : https://github.com/KimMachineGun/automemlimit
* License : Expat
  Programming Lang: Go
  Description : Automatically set GOMEMLIMIT to match Linux cgroups(7) 
memory limit

Go library to automatically set GOMEMLIMIT based on cgroups(7) v1/v2.
Alternatively, the limit can be sourced from an environment variable, or
set manually.

This package is a new dependency of prometheus-alertmanager v0.28.0. I
will co-maintain the package as a member of the Debian Go Packaging
Team.

Bug#1093261: ITP: golang-github-anchore-go-struct-converter -- help migrate between different versioned Go structs (Go library)

[Simon Josefsson]

Package: wnpp
Severity: wishlist
Owner: Simon Josefsson 

* Package name: golang-github-anchore-go-struct-converter
  Version : 0.0~git20240925.a088364-1
  Upstream Author : Anchore, Inc.
* URL : https://github.com/anchore/go-struct-converter
* License : Apache-2.0
  Programming Lang: Go
  Description : help migrate between different versioned Go structs (Go 
library)

 Go struct Converter - A library for converting between Go structs.

This package is used by github.com/spdx/tools-golang which is used by
github.com/in-toto/go-witness which is used by
github.com/in-toto/witness that I'm packaging.

https://salsa.debian.org/go-team/packages/golang-github-anchore-go-struct-converter
https://salsa.debian.org/jas/golang-github-anchore-go-struct-converter/-/pipelines

/Simon


signature.asc
Description: PGP signature

Re: How to conditionally patch a package based on architecture with debhelper?

[Guillem Jover]

Hi!

On Thu, 2025-01-16 at 13:26:39 -0500, Chris Knadle wrote:
> Looking at the manpage for dpkg-architecture, the variable I may want to
> conditionally build upon might be DEB_TARGET_ARCH rather than DEB_HOST_ARCH.

Others have already given pointers about this confusion. I'm more
interested in trying to see whether we can improve the man page to
avoid it.

I think if you search for stuff and end up in the VARIABLES section,
from there it's hard to notice the TERMS one, but in the past it
seemed excessive to me to either repeat the same or back-reference
the TERMS section on each variable definition. Perhaps a middle ground
would be adding a reference in the DEB_BUILD_ARCH and DEB_TARGET_ARCH,
like in the attached patch? Do you think that would have helped?

(I've gone over those two sections to try to further clarify and update
things I noticed, although I think the «Debian architecture» one could
do with some major update.)

Thanks,
Guillem
diff --git i/man/dpkg-architecture.pod w/man/dpkg-architecture.pod
index ae26b6d5c..a74716fd7 100644
--- i/man/dpkg-architecture.pod
+++ w/man/dpkg-architecture.pod
@@ -185,27 +185,30 @@ The machine the package is built for.
 
 =item target machine
 
 The machine the compiler is building for, or the emulator will run code for.
 This is only needed when building a cross-toolchain (or emulator), one that
 will be built on the build architecture, to be run on the host architecture,
-and to build (or run emulated) code for the target architecture.
+and that itself will build (or run emulated) code for the target architecture.
 
 =item Debian architecture
 
-The Debian architecture string, which specifies the binary tree in the
-FTP archive.
+The Debian architecture string,
+used in binary packages,
+which specifies the binary tree in a package repository.
+
 Examples: i386, sparc, hurd-i386.
 
 =item Debian architecture tuple
 
 A Debian architecture tuple is the fully qualified architecture with all its
 components spelled out.
 This differs with Debian architectures in that at least the I
 component does not embed the I.
 The current tuple has the form I-I-I-I.
+
 Examples: base-gnu-linux-amd64, eabihf-musl-linux-arm.
 
 =item Debian architecture wildcard
 
 A Debian architecture wildcard is a special architecture string that will
 match any real architecture being part of it.
@@ -227,22 +230,30 @@ the following pairs are equivalent:
 Examples: linux-any, any-i386, hurd-any, eabi-any-any-arm,
 musl-any-any.
 
 =item GNU system type
 
 An architecture specification string consisting of two parts separated by
-a hyphen: cpu and system.
+a hyphen: CPU and system.
+
+The CPU part never contains a hyphen,
+while the system part might itself contain a hyphen to separate a kernel
+from its general ABI,
+where the general ABI might contain both runtime (such as libc) and
+executable ABI specifiers joined without a hyphen.
+
 Examples: i586-linux-gnu, sparc-linux-gnu, i686-gnu, x86_64-netbsd.
 
 =item multiarch triplet
 
 The clarified GNU system type, used for filesystem paths.
 This triplet does not change even when the baseline ISA gets bumped,
 so that the resulting paths are stable over time.
 The only current difference with the GNU system type is that the CPU part
 for i386 based systems is always i386.
+
 Examples: i386-linux-gnu, x86_64-linux-gnu.
 Example paths: /lib/powerpc64le-linux-gnu/, /usr/lib/i386-kfreebsd-gnu/.
 
 =back
 
 =head1 VARIABLES
@@ -254,12 +265,16 @@ section for a description of the naming scheme):
 =over
 
 =item B
 
 The Debian architecture of the build machine.
 
+B: If you are not building tools that need to run during the build,
+these are probably not the variables you are looking for.
+Please see L section for the meanings of these terms.
+
 =item B
 
 The Debian ABI name of the build machine (since dpkg 1.18.11).
 
 =item B
 
@@ -344,12 +359,16 @@ The clarified GNU system type of the host machine, used for filesystem
 paths (since dpkg 1.16.0).
 
 =item B
 
 The Debian architecture of the target machine (since dpkg 1.17.14).
 
+B: If you are not building cross-toolchains (or emulators),
+these are probably not the variables you are looking for.
+Please see L section for the meanings of these terms.
+
 =item B
 
 The Debian ABI name of the target machine (since dpkg 1.18.11).
 
 =item B
 

Re: Removing manpages from libpam-modules to improve multi-arch

[Sam Hartman]

> "Simon" == Simon McVittie  writes:

Simon> On Thu, 16 Jan 2025 at 09:41:51 -0700, Sam Hartman wrote:
>> (We'd also need to do something about libpam0g-dev man pages).

Simon> Moving user-facing documentation from libpam0g into either
Simon> libpam-modules-bin or libpam-doc (depending how often you
Simon> expect users to need it), and developer documentation from
Simon> libpam0g-dev into libpam-doc, seems like it would make sense
Simon> to me?

I got enough requests from people who  want the sysadmin-facing
documentation installed by default (including a mild preference from
Helmut who I generally align with on issues like this).

I got a request from Helmut to minimize build dependencies.

With the exception of Simon Richter, we appear to be agreed that
avoiding man pages in m-a: same packages is good.

So what I'm going to do is move the developer man pages into libpam-doc
and the sysadmin man pages into libpam-runtime.
I'll be open to requests from people who want to minimize essential set
to move the sysadmin man pages to libpam-doc, but so far I'm not seeing
that.

I think this means:

* build-arch will not need the doc tools

* nodoc alone isn't enough to avoid the doc tools because of
  libpam-runtime

* bootstrapping can reuse libpam-runtime so  pam at least won't bring
  the xml docbook stack into bootstrapping essential.

* I will recommend libpam-doc from libpam0g-dev

Re: What is going on with atomics? (was: How to conditionally patch a package based on architecture with debhelper?)

[Ángel]

On 2025-01-16 at 20:16 +0100, Johannes Schauer Marin Rodrigues wrote:
> Hi Simon,
> 
> Quoting Simon Richter (2025-01-16 16:52:19)
> > atomic operations require linking against libatomic — always have..
> > Some
> > architectures inline a few functions, which is how you get away
> > with omitting
> > the library on amd64 most of the time, but this is incorrect.
> > 
> > No architecture specific patch should be required here, adding
> > libatomic everywhere is fine, possibly via
> > -Wl,--push-options,--as-needed,-latomic,--pop-options
> > 
> > (although as-needed is likely default anyway)
> 
> I find this very interesting. I am fighting -latomic linking issues
> for quite a while now and what you just said makes me think that I am
> in severe lack of understanding here. Can you elaborate?

Hi Josch,

It's not that complex.¹ If you use an atomic, you should also be
linking  with atomic (i.e. -latomic). This is similar to using
-pthreads if you are using multiple threads, or -lresolv if you use
gethostbyname()

What makes things complicated here is that in most architectures, gcc
is able to inline everything, and libatomic is not really needed, so
you don't need to add -latomic and it just works.

...until it doesn't, such as in armel.

Just like you can use gethostbyname() directly, since this is provided
by libc, which is implicitly linked by default.
But you would need to specify -lresolv in Solaris, or it won't link.

So the solution would be just to add -latomic

Saying instead 
-Wl,--push-options,--as-needed,-latomic,--pop-options

is an advanced way to make the linker not to depend on libatomic if it
isn't actually needed.



> 
> 
> So I'm at a loss at deciding who is at fault and who should be fixing
> something. You say this should work out-of-the-box on amd64 mostly but
> everything I have come across handling std::atomic types builds fine on all
> architectures -- except armel. So which is the thing that gets things wrong
> here?
> 
>  - armel?
>  - g++?
>  - cmake?
>  - oneTBB?
>  - vcmi?
> 
> Who should be patched? Relevant Debian bugs are #1089991 and #1088922
> 
> I'd very much welcome to be enlightened by you or anybody else on
> this list.. :)

I think the bug is in oneTBB, it is that that should be patched.
Your last patch at 
https://github.com/uxlfoundation/oneTBB/issues/1454#issuecomment-2267455977
seems appropriate.


vcmi should not need to care if oneTBB uses atomics or not.


armel is not strictly at fault (although you might blame the
architecture for not providing a way as easy as amd does)

g++ (actually gcc has the same issue) can be partially to blame.
gcc made an interface which is not too usable. Then it was reused for
g++, albeit the language specification doesn't state that requirement.
It *should* be improved at gcc level, but at the present time the spec
is that you will need to link to libatomic, and that's what oneTBB
should be doing.


Best regards


¹ Ok, after writing this whole email, maybe a bit 😅