Re: perl and libclass-xsaccessor-perl conflict in experimental

[Niko Tyni]

On Sun, Jan 26, 2025 at 12:39:52AM +0500, Andrey Rakhmatullin wrote:
> On Sat, Jan 25, 2025 at 07:17:52PM +, Tim Woodall wrote:
> > I know this is experimental and so breakage is expected but it seems to
> > have been like this for a while now so I'm reporting it here in case
> > it's been missed.
> 
> You may be confused, as perl 5.40.1-1 was only uploaded to experimental a
> week ago, but also in general it's expected that stuff with a new ABI in
> experimental is not installable in unstable. That's why we have
> transitions. It also shouldn't be unique to libclass-xsaccessor-perl,
> there are several packages in unstable that aren't coinstallable with a
> too new perl.

Yes, this is indeed expected behaviour. We're using experimental as
a staging ground for testing out new upstream Perl releases to ensure
that the actual transition will be as painless as possible. Updating all
required reverse dependencies in experimental accordingly and keeping
them up to date would be too much of a burden however (and step on
other maintainers' toes), so we're using a separate test repository [1]
for that.

This is mostly geared for major Perl upstream releases, where 600+
packages need rebuilds. The minor Perl upstream releases (like 5.40.1
here) are ABI compatible, so most packages stay installable, but there's
still a handful of packages depending on the specific upstream version
they were built with for various reasons [2]. libclass-xsaccessor-perl
is one of these and will be rebuilt for Perl 5.40.1 when that enters
unstable.

FWIW my tests with 5.40.1 look good so far (both rebuilds and
autopkgtest), but I'm not quite finished yet.

[1] https://perl.debian.net/

[2] https://wiki.debian.org/PerlMaintenance#Point_releases_only

> I'd say you are just not supposed to install random packages from
> experimental...

Indeed.
-- 
Niko Tyni   nt...@debian.org

Re: how to fix lintian error: library-not-linked-against-libc

[Ahmad Khalifa]

On 26/01/2025 11:19, Andrey Rakhmatullin wrote:

On Sun, Jan 26, 2025 at 11:07:12AM +, Ahmad Khalifa wrote:

I do this to confirm if lintian is correct:

$ objdump -p file.so
   ...
   NEEDED   libc.so.6
   ...


No?
Lintian already says there is no "NEEDED   libc.so.6", the
question is whether that is an error or not.


I think we're on the same page, I just added an extra step out of caution :)

The lintian error is a great heads-up and it's up to the reader to 
decide whether it's a true error to fix or a false-positive to override.


--
Regards,
Ahmad

Re: how to fix lintian error: library-not-linked-against-libc

[David Kalnischkies]

Hi,

unrelated to your question, but there are things that jump out for me:

Am Sat, Jan 25, 2025 at 10:57:26PM -0600, schrieb Steven Robbins:
> The (CMake-generated) link line does have a bunch of options.  Nothing jumped 
> out at me:
> 
> /usr/bin/c++ -fPIC -g -O2 
> -ffile-prefix-map=/home/steve/Packages/insighttoolkit/build-area/
> insighttoolkit5-5.4.0=. -fstack-protector-strong -fstack-clash-protection 
> -Wformat -
> Werror=format-security -fcf-protection -Wdate-time
> -D_FORTIFY_SOURCE=2 -I/usr/include/nifti -g1  -mtune=generic -march=corei7 
> -Wall -

> Wcast-align -Wdisabled-optimization -Wextra -Wformat=2 -Winvalid-pch 
> -Wno-format-
> nonliteral -Wpointer-arith -Wshadow -Wunused -Wwrite-strings 
> -Wno-strict-overflow -Wno-deprecated -Wno-invalid-offsetof 
> -Woverloaded-virtual -Wctad-
> maybe-unsupported -Wstrict-null-sentinel  -fno-sized-deallocation -msse2 
> -Wl,--
^^
> dependency-file=CMakeFiles/ITKColormap.dir/link.d -Wl,-z,re
> lro  -shared -Wl,-soname,libITKColormap-5.4.so.1 -o 
> ../../../../lib/x86_64-linux-gnu/
> libITKColormap-5.4.so.1 CMakeFiles/ITKColormap.dir/
> itkScalarToRGBColormapImageFilter.cxx.o 

You are building the package only for amd64, but even for that corei7
might be a bit much to ask for.

You and/or upstream might be interested in some of the tipps and tricks
from https://wiki.debian.org/InstructionSelection to use more/less
instructions as needed than the baseline.

On a sidenote: I would have expected this thread on d-mentors.


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#1094303: ITP: triforce-lv2 -- LV2 beamformer plugin for Apple mic arrays

[NoisyCoil]

Package: wnpp
Severity: wishlist
Owner: NoisyCoil 
X-Debbugs-Cc: debian-devel@lists.debian.org, noisyc...@tutanota.com

* Package name: triforce-lv2
  Version : 0.1.0
  Upstream Contact: James Calligeros 
* URL : https://github.com/chadmed/triforce
* License : GPL-2.0-or-later
  Programming Lang: Rust
  Description : LV2 beamformer plugin for Apple mic arrays

Some Apple Silicon laptops have an array of microphones arranged in a
triangle. Without beamforming, the array is far too sensitive and
omnidirectional to be at all useful.

triforce implements a Minimum Variance Distortionless Response adaptive
beamformer for these microphone arrays.


This package (among other things) is needed for having working mics on
Apple Silicon laptops. I plan to maintain it within the Bananas Team.

Re: how to fix lintian error: library-not-linked-against-libc

[Andrey Rakhmatullin]

On Sun, Jan 26, 2025 at 11:07:12AM +, Ahmad Khalifa wrote:
> > The error description seems straightforward.  But how does one solve
> > this?  I have to assume that the linker would by default link with the
> > libc (?), so perhaps the linker invocation has options that suppress
> > this?  What would that be?
> 
> You may not need to solve it if it's intentional.
> For example, you have a "plugin" style library that only uses functions from
> the main library and nothing else.

Yes.


> I do this to confirm if lintian is correct:
> > $ objdump -p file.so
> >   ...
> >   NEEDED   libc.so.6
> >   ...

No?
Lintian already says there is no "NEEDED   libc.so.6", the
question is whether that is an error or not.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1094280: ITP: python-trubar -- Utility for translation of Python sources

[Roland Mas]

Package: wnpp
X-Debbugs-Cc: debian-devel@lists.debian.org, Debian Python Team 

Owner: Roland Mas 
Severity: wishlist

* Package name: python-trubar
  Version : 0.3.4
  Upstream Contact: Janez Demšar 
* URL : https://github.com/janezd/trubar
* License : MIT
  Programming Lang: Python
  Description : Utility for translation of Python sources

A tool for localization of Python messages via translating source
files.
.
Trubar supports f-strings and does not require any changes to the
original source code, such as marking strings for translation.

Re: Accepted firebird4.0 4.0.5.3140.ds6-11 (source) into unstable

[Rene Engelhard]

Hi,

Am 26.01.25 um 18:30 schrieb Rene Engelhard:

[build CUT] dbaccess_firebird_test
S=/home/rene/LibreOffice/git/libreoffice-25-2 && I=$S/instdir && W=$S/workdir &&  mkdir -p $W/CppunitTest/ && rm -fr $W/CppunitTest/dbaccess_firebird_test.test.user && cp -r $W/unittest $W/CppunitTest/dbaccess_firebird_test.test.user &&    rm -fr $W/CppunitTest/dbaccess_firebird_test.test.core && mkdir $W/CppunitTest/dbaccess_firebird_test.test.core && cd $W/CppunitTest/dbaccess_firebird_test.test.core &&   ( MAX_CONCURRENCY=4 MOZILLA_CERTIFICATE_FOLDER=dbm: SAL_DISABLE_SYNCHRONOUS_PRINTER_DETECTION=1 SAL_USE_VCLPLUGIN=svp LIBO_LANG=C LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/program:$I/program":$W/UnpackedTarball/cppunit/src/cppunit/.libs LO_RUNNING_UNIT_TEST=1  $W/LinkTarget/Executable/cppunittester $W/LinkTarget/CppunitTest/libtest_dbaccess_firebird_test.so --headless "-env:BRAND_BASE_DIR=file://$S/instdir" "-env:BRAND_SHARE_SUBDIR=share" "-env:BRAND_SHARE_RESOURCE_SUBDIR=program/resource" "-env:UserInstallation=file://$W/CppunitTest/ 
dbaccess_firebird_test.test.user" "-env:CONFIGURATION_LAYERS=xcsxcu:file://$I/share/registry xcsxcu:file://$W/unittest/registry-common xcsxcu:file://$W/unittest/registry-user-ui" "-env:UNO_TYPES=file://$I/program/types/offapi.rdb file://$I/program/types/oovbaapi.rdb file://$I/program/types.rdb" "-env:UNO_SERVICES=file://$W/Rdb/ure/services.rdb file://$W/ComponentTarget/basic/util/sb.component file://$W/ComponentTarget/comphelper/util/comphelp.component file://$W/ComponentTarget/configmgr/source/configmgr.component file://$W/ComponentTarget/connectivity/source/drivers/firebird/firebird_sdbc.component file://$W/ComponentTarget/connectivity/source/manager/sdbc2.component file://$W/ComponentTarget/dbaccess/util/dba.component file://$W/ComponentTarget/dbaccess/source/filter/xml/dbaxml.component file://$W/ComponentTarget/dbaccess/util/dbu.component file://$W/ComponentTarget/filter/source/config/cache/filterconfig1.component file://$W/ComponentTarget/framework/util/fwk.component 
file://$W/ComponentTarget/i18npool/util/i18npool.component file://$W/ComponentTarget/linguistic/source/lng.component file://$W/ComponentTarget/package/source/xstor/xstor.component file://$W/ComponentTarget/package/util/package2.component file://$W/ComponentTarget/sax/source/expatwrap/expwrap.component file://$W/ComponentTarget/sfx2/util/sfx.component file://$W/ComponentTarget/svl/source/fsstor/fsstorage.component file://$W/ComponentTarget/svl/util/svl.component file://$W/ComponentTarget/toolkit/util/tk.component file://$W/ComponentTarget/ucb/source/core/ucb1.component file://$W/ComponentTarget/ucb/source/ucp/file/ucpfile1.component file://$W/ComponentTarget/unotools/util/utl.component file://$W/ComponentTarget/uui/util/uui.component file://$W/ComponentTarget/xmloff/util/xo.component" -env:URE_BIN_DIR=file://$I/program -env:URE_INTERNAL_LIB_DIR=file://$I/program -env:LO_LIB_DIR=file://$I/program -env:LO_JAVA_DIR=file://$I/program/classes --protector $W/LinkTarget/Library/ 
unoexceptionprotector.so unoexceptionprotector --protector $W/LinkTarget/Library/unobootstrapprotector.so unobootstrapprotector   --protector $W/LinkTarget/Library/libvclbootstrapprotector.so vclbootstrapprotector "-env:CPPUNITTESTTARGET=$W/CppunitTest/dbaccess_firebird_test.test" )  2>&1

[_RUN_] FirebirdTest::testEmptyDBConnection
unknown:0:FirebirdTest::testEmptyDBConnection
An uncaught UNO exception
- com.sun.star.sdbc.SQLException: {Message: "firebird_sdbc error:
*Unable to complete network request to host "localhost".
*Failed to establish a connection.
caused by
'isc_create_database'
", Context: @0x7ffc97376570, SQLState: "", ErrorCode: 1, NextException: void: 
void}

[...]

Tried in a clean sid VM.

LibreOffice not rebuilt from clean sid, but as clean sid libfbclient2 4.0.5 is 
installed.

(Expectedly) the same when creating a new db when just 3.0-server-core is 
present. The creation of a database
and zthe "connection" to it only works with 4.0-server-core installed.

So even worse: The new libfbclient2 is forcing 4.0-server-core here. Even when 
no rebuild happened yet

Regards,

Rene

Re: Accepted firebird4.0 4.0.5.3140.ds6-11 (source) into unstable

[Rene Engelhard]

Hi,

Am 26.01.25 um 19:14 schrieb Rene Engelhard:

Tried in a clean sid VM.

LibreOffice not rebuilt from clean sid, but as clean sid libfbclient2 4.0.5 is 
installed.

(Expectedly) the same when creating a new db when just 3.0-server-core is 
present. The creation of a database
and zthe "connection" to it only works with 4.0-server-core installed.

So even worse: The new libfbclient2 is forcing 4.0-server-core here. Even when 
no rebuild happened yet


Filed #1094284: please add Breaks: libreoffice-sdbc-firebird (<< 4:24.8.4-2) to 
prevent that (even though firebird embedded
in LO is only available with Experimental features enabled).

Regards,
 
Rene

Re: DEP-14: Default branch name 'debian/latest' objections?

[Xiyue Deng]

Hi Colin,

Colin Watson  writes:

> On Fri, Jan 24, 2025 at 01:24:12PM -0800, Xiyue Deng wrote:
>> I would like to echo on this point.  I had worked on a repository that
>> has the "master" branch marked as the default branch on Salsa, which
>> lacks many changes compared to the released version.  I tried to
>> manually incorporate those changes, and only later found out that the
>> actual latest branch is "debian/sid" and it did have everything
>> up-to-date.  (Note that this has since been fixed[1]).  I think for new
>> repository, standardizing on a name (either "debian/latest" or people's
>> liking) helps identify where the latest work goes to.
>
> I find myself in this situation from time to time as well.  However, I
> disagree with your conclusion.  At least for me, and I'm going to guess
> for most contributors, I wouldn't reliably think to look for a
> non-default branch at all unless I was doing something a little more out
> of the ordinary such as preparing an update for a stable release; it
> wouldn't really matter whether that branch was called debian/master or
> debian/main or debian/sid or debian/latest.  I usually work on the
> assumption that the branch I get by "git clone" from Salsa is the one I
> should be working on for the usual case of developing on unstable, and
> since that assumption is nearly always correct, it saves me time and
> energy over explicitly looking around for different branch names every
> time I clone a repository (I work on a lot of different packages).
>
> In the situation you outlined, it wouldn't have mattered to me one bit
> whether the actual latest branch was called debian/sid or debian/latest;
> I probably wouldn't have noticed it either way.  What would have
> mattered to me was that it wasn't the default branch (HEAD on Salsa).
>
> So, rather than worrying about the _name_ of the default branch, I'd
> like to suggest a change to DEP-14 that I think would have broader
> consensus and be more useful.
>
> Currently, there's only one place where DEP-14 talks about the default
> branch: the "Native packages" section says "the default branch of the
> repository (as pointed by the HEAD reference) should be a development
> branch".  I suggest that this recommendation should not be just for
> native packages.  The "For development releases" section should say that
> the branch for uploads to the current development release of the
> furthest-upstream distribution handled in a given repository (typically
> Debian) should be the default branch, as pointed to by the HEAD
> reference.
>
> DEP-14 needn't prescribe exactly what the name of that branch should be,
> and if it does then we should pragmatically regard it only as an
> indication of what tools that _create_ Debian packaging repositories
> should do.  Renaming branches is intrusive (it still typically requires
> manual action from anyone who has an existing clone and wants to pull
> changes!), and so there can be no realistic expectation that existing
> repositories will reliably change to follow a new suggested default
> name.
>

Thanks for your comments!  I agree with you that with the improvements
on tooling (e.g. git), the default branch matters the most for avoiding
confusion.

However, there is an inconvenience if there is not a recommended default
branch name.  When I switch among several projects, the default branch
name changes between "master", "main", "debian/master", "debian/latest",
etc., which is kind of distracting.  I think recommending a name helps
to reduce this fragmentation in the long run.  This may not be an issue
for experienced git user, but helps newcomers a lot.

> -- 
> Colin Watson (he/him)  [cjwat...@debian.org]
>

-- 
Regards,
Xiyue Deng


signature.asc
Description: PGP signature

Re: DEP-14: Default branch name 'debian/latest' objections?

[Colin Watson]

On Fri, Jan 24, 2025 at 04:31:57PM -0800, Xiyue Deng wrote:
> tho...@goirand.fr writes:
> > What you experience shows one thing: having the default branch being
> > set correctly should be what we mandate.
> 
> Indeed.  Though IIRC the default branch was not a native git concept
> until 2.28, so user of older git may still get confused.

Firstly, 2.28 predates buster, so we're unlikely to have to worry about
it very much.

Secondly, while 2.28 fixed a number of problems that people ran into
when trying to change the default branch name for new repositories and
various other related corner cases, I don't think any of them applied to
the simple case of just cloning a repository where the remote HEAD
points to something other than "master".  I'm not sure exactly how long
that's worked for, but poking through "tig blame builtin/clone.c", I
think it's probably been supported to some extent at least as far back
as git 1.5.6.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#1094305: ITP: upub -- federated micro social network

[Jonas Smedegaard]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: upub
  Version : 0.5.0
  Upstream Contact: alemi 
* URL : https://join.upub.social/
* License : AGPL-3
  Programming Lang: Rust
  Description : federated micro social network

 μpub aims to be a private, lightweight, modular and secure
 ActivityPub server.
 .
 μpub is modeled around timelines
 but tries to be unopinionated in its implementation,
 allowing representing multiple different fediverse "modalities"
 together.
 .
 All client interactions happen with ActivityPub's client-server methods
 (basically POST your activities to your outbox),
 with appropriate extensions:
 μpub doesn't want to invent another API!

The package will be maintained in the collaborative debian section of
Salsa, at .


-BEGIN PGP SIGNATURE-

wsG7BAEBCgBvBYJnltD3CRAsfDFGwaABIUcUAAAeACBzYWx0QG5vdGF0aW9u
cy5zZXF1b2lhLXBncC5vcmczexBXLn8IymPt9lNymbw5D7zW0Ezy81455Ija6/dc
qRYhBJ/j6cNmkaaf9TzGhCx8MUbBoAEhAADSvA//e2nmJBkg+9lJmvujtq0NRjGd
JdDYcDyPMOMyvTQcoYkt1A1WzWC+2mJUpyL7dBlczfGU48atHXciP5IXH2nEh8je
0Ue8SjTVdfOmSZWaU9EwU6vZd8XG+H5zljsuf/VJVFQ8so4Cz1s0KqbvQN6frWzx
e4y3/fG2RHCfdNxTLvx6JLW3OgqcJuyA+au1knEswVQu7hb3vJpavuWwRt4oTWMv
PtNgZOj70/wwjsUbl7DNkh/csrKXf49+jZF/kX/SPewjnE37QW3lS9558bKfLlmI
2zLRT06FrcMS8nwOwpaKHBLC8sWm/byx4GdZXu8RDQ5OB/286sumKjiYLduszZVg
VpLJoHyUDnBLk9uu7KuGDLFwdmlzzMqzr2VUt//62bWZ7ivUE0chrZ5wO17BBmVf
Gwah43Qvwt/fNvJV2OPq8795tL/Zm3MlVW7+zcx6DL3jhE+sZxYhhLBqM7IxGQx0
bNBbrPGeJKSR573tXYOHChUQ647YKeAL97wyTUZ5M8HF1vookHoTUr0d4orOiLgV
0tH575X/ubEbSHNX31gggkBbH86Q3oj69kBpC8sf5Jzlp4+sytWn0HPRZO8o+ZI5
l+64ZHwd4ClIVAO6P1UeCZKpbLDklIdYeqv86AcKMfYW+uZVK4hD9hr098cp0p6n
xxdPDVrW5x/JYChVhsg=
=ZsDP
-END PGP SIGNATURE-

Re: how to fix lintian error: library-not-linked-against-libc

[Jeremy Bícha]

On Sun, Jan 26, 2025 at 6:28 AM Ahmad Khalifa  wrote:
> The lintian error is a great heads-up and it's up to the reader to
> decide whether it's a true error to fix or a false-positive to override.

I have never seen this Lintian error actually be useful. I think an
error is far too strong for this; I think even a warning is too
strong; maybe info would be ok.

Thank you,
Jeremy Bícha

Re: Bug#1094175: ITP: linux-os-updater -- Linux OS Updater. This is a package updating system designed to ease the update process for most Linux distributions efficiently.

[Henrik Ahlgren]

On Sat, 2025-01-25 at 15:34 +, Richard Lewis wrote:
> downloading and running a script from a random website seems a rather
> unhelpful approach and maybe not the best idea to suggest debian
> supports this?

Does this even work with Debian? 

The script

https://github.com/CrypticVerse/linux-os-updater/blob/master/linux-os-updater

tries to download a distro-specific script, but

https://raw.githubusercontent.com/CrypticVerse/linux-os-updater/refs/heads/master/os/update-debian.py

is 404 (Ubuntu is supported and a bunch of non-Debian related distros).


Anyway, I don't think Debian should ship with packages where the main
functionality relies on executing shell scripts downloaded from the master
branch of some github repository.

Re: how to fix lintian error: library-not-linked-against-libc

[Russ Allbery]

Jeremy Bícha  writes:
> On Sun, Jan 26, 2025 at 6:28 AM Ahmad Khalifa  wrote:

>> The lintian error is a great heads-up and it's up to the reader to
>> decide whether it's a true error to fix or a false-positive to
>> override.

> I have never seen this Lintian error actually be useful. I think an
> error is far too strong for this; I think even a warning is too strong;
> maybe info would be ok.

When we introduced it many years ago, it was definitely useful. It's
intended to catch plugin libraries that are linked with the main library
but not with libc explicitly, while still using libc symbols. This case
often works due to the implicit dependency up until it doesn't.

Maybe the tooling is now better in ways that make this much less likely to
happen? And maybe it's more common these days to have plugin libraries
that aren't linked with libc? Back in the day, it was very rare for people
to successfully manage to write code that never called a libc symbol.

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

Re: Accepted firebird4.0 4.0.5.3140.ds6-11 (source) into unstable

[Damyan Ivanov]

-=| Rene Engelhard, 25.01.2025 22:05:51 +0100 |=-
> > Changes:
> >  firebird4.0 (4.0.5.3140.ds6-11) unstable; urgency=medium
> >  .
> >    * Upload to unstable
> 
> Which now takes over firebird-dev.

True. As intented.

> Which now means reverse-dependencies build against 4.0 firebird but do have
> 
> Depends: libreoffice-core-nogui | libreoffice-core, firebird3.0-server-core, 
> ucf, libc6 (>= 2.14), libfbclient2 (>= 3.0.12~), libgcc-s1 (>= 3.3.1), 
> libstdc++6 (>= 11), libuno-cppu3t64 (>= 4.4.0~alpha), 
> libuno-cppuhelpergcc3-3t64 (>= 5.3.0~alpha), libuno-sal3t64 (>= 5.3.0~alpha), 
> libuno-salhelpergcc3-3t64 (>= 1.4.0), uno-libs-private

Which is fine.

Unlike previous major Firebird release, 4.0 in Debian is 
co-installable with 3.0, so depending on firebird3.0-server-core and 
libfbclient2 from src:firebird4.0 should work.

In fact, firebird3.0-server has dependencies exactly like this (and 
works).

Of course, there may be corner cases in LO's usage of firebird. Please 
let me know if you encounter some.

> And there is no firebird3.0-dev or firebird4.0-dev to choose. So 
> I probably need to change this Depends: to firebird4.0-sever-core in 
> the next upload but telling it to reverse-depends like any other 
> transition should have been done here...

This is not supposed to be a transition, not this time.

Using either of firebird3.0-server-core and firebird4.0-server-core 
should work. My plan is to have both in trixie so that users have 
a whole stable release cycle to upgrade their databases (that would be 
a first!).


-- Damyan

Bug#1094228: ITP: golang-github-jstemmer-go-junit-report -- Convert Go test output to JUnit XML

[Andrej Shadura]

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

* Package name: golang-github-jstemmer-go-junit-report
  Version : 2.1.0
  Upstream Contact: Joël Stemmer
* URL : https://github.com/jstemmer/go-junit-report
* License : MIT/X11
  Programming Lang: Go
  Description : Convert Go test output to JUnit XML

go-junit-report is a tool that converts go test output to a JUnit
compatible XML report, suitable for use with applications such as
Jenkins or GitLab CI.

I intend to maintain this within the Golang team.

Re: how to fix lintian error: library-not-linked-against-libc

[Andrey Rakhmatullin]

On Sun, Jan 26, 2025 at 01:02:25AM -0600, Steven Robbins wrote:
> > I've come to realise the ITK build has 15 libraries that lintian flags with
> > error library-not-linked-against-libc.
> 
> Someone suggested to run ldd -r.  Okay, so what does this tell me?
> 
> $ ldd -r /lib/x86_64-linux-gnu/libITKColormap-5.4.so 
>linux-vdso.so.1 (0x7f1b218a1000) 
>libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 
> (0x7f1b2140) 
>libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f1b21766000) 
>libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f1b2120a000) 
>/lib64/ld-linux-x86-64.so.2 (0x7f1b218a3000) 
>libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
> (0x7f1b21739000)

Oh right, this is not a useful check if the library is linked to anything
that is linked to libc. The correct way is, as lintian says, to check the
symbols imported by the library (with e.g. nm -D) to make sure none of
them are from libc.

> Thanks,
>  -Steve
> P.S.  Please CC, not subscribed, thanks!

Done.
And please use debian-mentors@ for packaging questions next time.



-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1094220: ITP: django-choices-field -- Set/Get Django's TextChoices/IntegerChoices enum

[Carsten Schoenert]

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

* Package name: django-choices-field
  Version : 2.3.0
  Upstream Contact: Thiago Bellini Ribeiro 
* URL : https://github.com/bellini666/django-choices-field
* License : Expat
  Programming Lang: Python
  Description : Set/Get Django's TextChoices/IntegerChoices enum

 Django's choices field option is a powerful feature that ensures data
 integrity and provides an intuitive interface for users.
 .
 This AddOn let you set a Django field that set/get django's new TextChoices
 and IntegerChoices enum.

This package is a dependency for strawberry-graphql-django that is then
a dependency for NetBox >= 4.x.

I plan to maintain this package within the DPT.

Regards
Carsten

Re: perl and libclass-xsaccessor-perl conflict in experimental

[Tim Woodall]

On Sun, 26 Jan 2025, Niko Tyni wrote:


On Sun, Jan 26, 2025 at 12:39:52AM +0500, Andrey Rakhmatullin wrote:

On Sat, Jan 25, 2025 at 07:17:52PM +, Tim Woodall wrote:

I know this is experimental and so breakage is expected but it seems to
have been like this for a while now so I'm reporting it here in case
it's been missed.


You may be confused, as perl 5.40.1-1 was only uploaded to experimental a
week ago, but also in general it's expected that stuff with a new ABI in
experimental is not installable in unstable. That's why we have
transitions. It also shouldn't be unique to libclass-xsaccessor-perl,
there are several packages in unstable that aren't coinstallable with a
too new perl.


Yes, this is indeed expected behaviour. We're using experimental as
a staging ground for testing out new upstream Perl releases to ensure
that the actual transition will be as painless as possible. Updating all
required reverse dependencies in experimental accordingly and keeping
them up to date would be too much of a burden however (and step on
other maintainers' toes), so we're using a separate test repository [1]
for that.

[1] https://perl.debian.net/

[2] https://wiki.debian.org/PerlMaintenance#Point_releases_only


I'd say you are just not supposed to install random packages from
experimental...


Indeed.



Thanks both for the explanation. I was assuming that the intention of
experimental was that it should work in theory but things uploaded might
have bugs or other unexpected side effects that maintainers wanted
testing and I thought this failure might have been missed.

Re: how to fix lintian error: library-not-linked-against-libc

[Ahmad Khalifa]

On 26/01/2025 04:57, Steven Robbins wrote:

I've come to realise the ITK build has 15 libraries that lintian flags with


...
The error description seems straightforward.  But how does one solve 
this?  I have to assume that the linker would by default link with the 
libc (?), so perhaps the linker invocation has options that suppress 
this?  What would that be?


You may not need to solve it if it's intentional.
For example, you have a "plugin" style library that only uses functions 
from the main library and nothing else.


I do this to confirm if lintian is correct:
> $ objdump -p file.so
>   ...
>   NEEDED   libc.so.6
>   ...

If it doesn't need libc, then lintian error is correct.
You would then sift through the code to see what that library 
includes/links against.
Is it intentional that it doesn't need libc? If yes, then override the 
error.



--
Regards,
Ahmad

Re: Accepted firebird4.0 4.0.5.3140.ds6-11 (source) into unstable

[Rene Engelhard]

Hi,

Am 26.01.25 um 18:19 schrieb Damyan Ivanov:

Which now means reverse-dependencies build against 4.0 firebird but do have

Depends: libreoffice-core-nogui | libreoffice-core, firebird3.0-server-core, ucf, libc6 (>= 2.14), 
libfbclient2 (>= 3.0.12~), libgcc-s1 (>= 3.3.1), libstdc++6 (>= 11), libuno-cppu3t64 (>= 
4.4.0~alpha), libuno-cppuhelpergcc3-3t64 (>= 5.3.0~alpha), libuno-sal3t64 (>= 5.3.0~alpha), 
libuno-salhelpergcc3-3t64 (>= 1.4.0), uno-libs-private

Which is fine.

No, it isn't. (Not with 4.0s libfbclient2), see below.

Unlike previous major Firebird release, 4.0 in Debian is
co-installable with 3.0, so depending on firebird3.0-server-core and
libfbclient2 from src:firebird4.0 should work.


Nope. From LOs testsuite:

[build CUT] dbaccess_hsql_binary_import
S=/home/rene/LibreOffice/git/libreoffice-25-2 && I=$S/instdir && W=$S/workdir &&  mkdir -p $W/CppunitTest/ && rm -fr $W/CppunitTest/dbaccess_hsql_binary_import.test.user && cp -r $W/unittest $W/CppunitTest/dbaccess_hsql_binary_import.test.user && rm -fr $W/CppunitTest/dbaccess_hsql_binary_import.test.core && mkdir $W/CppunitTest/dbaccess_hsql_binary_import.test.core && cd $W/CppunitTest/dbaccess_hsql_binary_import.test.core && (   MAX_CONCURRENCY=4 MOZILLA_CERTIFICATE_FOLDER=dbm: SAL_DISABLE_SYNCHRONOUS_PRINTER_DETECTION=1 SAL_USE_VCLPLUGIN=svp LIBO_LANG=C LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/program:$I/program":$W/UnpackedTarball/cppunit/src/cppunit/.libs LO_RUNNING_UNIT_TEST=1  $W/LinkTarget/Executable/cppunittester $W/LinkTarget/CppunitTest/libtest_dbaccess_hsql_binary_import.so --headless "-env:BRAND_BASE_DIR=file://$S/instdir" "-env:BRAND_SHARE_SUBDIR=share" "-env:BRAND_SHARE_RESOURCE_SUBDIR=program/resource" 
"-env:UserInstallation=file://$W/CppunitTest/dbaccess_hsql_binary_import.test.user" "-env:CONFIGURATION_LAYERS=xcsxcu:file://$I/share/registry xcsxcu:file://$W/unittest/registry-common xcsxcu:file://$W/unittest/registry-user-ui" "-env:UNO_TYPES=file://$I/program/types/offapi.rdb file://$I/program/types/oovbaapi.rdb file://$I/program/types.rdb" "-env:UNO_SERVICES=file://$W/Rdb/ure/services.rdb file://$W/ComponentTarget/basic/util/sb.component file://$W/ComponentTarget/comphelper/util/comphelp.component file://$W/ComponentTarget/configmgr/source/configmgr.component file://$W/ComponentTarget/connectivity/source/drivers/hsqldb/hsqldb.component file://$W/ComponentTarget/connectivity/source/drivers/firebird/firebird_sdbc.component file://$W/ComponentTarget/connectivity/source/manager/sdbc2.component file://$W/ComponentTarget/dbaccess/util/dba.component file://$W/ComponentTarget/dbaccess/util/dbu.component file://$W/ComponentTarget/dbaccess/util/sdbt.component 
file://$W/ComponentTarget/dbaccess/source/filter/xml/dbaxml.component file://$W/ComponentTarget/filter/source/config/cache/filterconfig1.component file://$W/ComponentTarget/forms/util/frm.component file://$W/ComponentTarget/framework/util/fwk.component file://$W/ComponentTarget/i18npool/util/i18npool.component file://$W/ComponentTarget/linguistic/source/lng.component file://$W/ComponentTarget/oox/util/oox.component file://$W/ComponentTarget/package/source/xstor/xstor.component file://$W/ComponentTarget/package/util/package2.component file://$W/ComponentTarget/sax/source/expatwrap/expwrap.component file://$W/ComponentTarget/scripting/source/basprov/basprov.component file://$W/ComponentTarget/scripting/util/scriptframe.component file://$W/ComponentTarget/sfx2/util/sfx.component file://$W/ComponentTarget/sot/util/sot.component file://$W/ComponentTarget/svl/source/fsstor/fsstorage.component file://$W/ComponentTarget/svl/util/svl.component 
file://$W/ComponentTarget/toolkit/util/tk.component file://$W/ComponentTarget/ucb/source/core/ucb1.component file://$W/ComponentTarget/ucb/source/ucp/file/ucpfile1.component file://$W/ComponentTarget/ucb/source/ucp/tdoc/ucptdoc1.component file://$W/ComponentTarget/unotools/util/utl.component file://$W/ComponentTarget/unoxml/source/rdf/unordf.component file://$W/ComponentTarget/unoxml/source/service/unoxml.component file://$W/ComponentTarget/uui/util/uui.component file://$W/ComponentTarget/xmloff/util/xo.component" -env:URE_BIN_DIR=file://$I/program -env:URE_INTERNAL_LIB_DIR=file://$I/program -env:LO_LIB_DIR=file://$I/program -env:LO_JAVA_DIR=file://$I/program/classes --protector $W/LinkTarget/Library/unoexceptionprotector.so unoexceptionprotector --protector $W/LinkTarget/Library/unobootstrapprotector.so unobootstrapprotector   --protector $W/LinkTarget/Library/libvclbootstrapprotector.so vclbootstrapprotector 
"-env:CPPUNITTESTTARGET=$W/CppunitTest/dbaccess_hsql_binary_import.test" )  2>&1

[_RUN_] HsqlBinaryImportTest::testBinaryImport
unknown:0:HsqlBinaryImportTest::testBinaryImport
An uncaught UNO exception
- com.sun.star.sdbc.SQLException: {Message: "firebird_sdbc error:
*Unable to complete network request to host "localhost".
*Failed to establish a connection.
caused by
'isc_create_database'
", Context: @0x7fff39ae

Re: how to fix lintian error: library-not-linked-against-libc

[Simon McVittie]

On Sun, 26 Jan 2025 at 09:14:30 -0800, Russ Allbery wrote:
> maybe it's more common these days to have plugin libraries
> that aren't linked with libc? Back in the day, it was very rare for people
> to successfully manage to write code that never called a libc symbol.

In ecosystems with a "platform" runtime library like GLib, Qt or even
SDL, and especially when intending to be portable to Windows and macOS
as well as Linux and other Unixy platforms, it's very common to write
code that only ever calls into that runtime library, and never directly
calls libc functions. I think the reason Jeremy is so negative about this
lintian check is that false positives are particularly common in GNOME,
where basically everything is linked to GLib and uses its functions in
preference to going directly to libc.

smcv

Re: Accepted firebird4.0 4.0.5.3140.ds6-11 (source) into unstable

[Rene Engelhard]

Hi,

Am 26.01.25 um 18:19 schrieb Damyan Ivanov:

Of course, there may be corner cases in LO's usage of firebird. Please
let me know if you encounter some.


LO usage is as-follows (quoting from 
https://gerrit.libreoffice.org/c/core/+/151214):

"Firebird has two primary file types:

Databases - FDB files. These are version-specific, platform-specific, optimized 
for performance, and thus incompatible between versions. These are what those 
comments are about. Initially, when FB integration was considered, these files 
were evaluated for ODBs, but were rejected because of the said incompatibility 
- even when the version is the same, it will differ on big endian architecture 
and little endian one. The problem discussed in those comments is when people 
open stand-alone FDBs that are shipped e.g. with FB installation itself, not 
when people open ODBs.

Database backups - FBKs. These are what we use inside ODBs. These are designed 
to be compatible, independent of architecture; and later versions of FB are 
always able to open FBKs created in older FB versions.

Our embedded FB is used like this:

1. FBK is extracted from ODB;
2. Embedded FB extracts the compatible FBK into an incompatible FDB (specific 
to this version of embedded FB DLL);
3. FB works with this temporary FDB;
4. When saving ODB, embedded FB backups the FDB into FBK again, and that is 
stored inside the ODB.

It, indeed, creates additional performance penalty, but makes the ODB readable by 
all the future LO versions, no matter what future FB version they embed."


And that apparently (not deep into it) needs libEngine12.so from 
-3.0-server-core (and now appantly -4.0-server-core, so probably 
libEngine13.so?) if build with 4.0s firebird-dev.


Regards,


Rene

Re: how to fix lintian error: library-not-linked-against-libc

[Russ Allbery]

Simon McVittie  writes:
> On Sun, 26 Jan 2025 at 09:14:30 -0800, Russ Allbery wrote:

>> maybe it's more common these days to have plugin libraries that aren't
>> linked with libc? Back in the day, it was very rare for people to
>> successfully manage to write code that never called a libc symbol.

> In ecosystems with a "platform" runtime library like GLib, Qt or even
> SDL, and especially when intending to be portable to Windows and macOS
> as well as Linux and other Unixy platforms, it's very common to write
> code that only ever calls into that runtime library, and never directly
> calls libc functions. I think the reason Jeremy is so negative about
> this lintian check is that false positives are particularly common in
> GNOME, where basically everything is linked to GLib and uses its
> functions in preference to going directly to libc.

I suspect what's changed since the introduction of this tag is that use of
as-needed is now much more common and as-needed is removing the libc
dependency. That specific pattern is safe, since the libc dependency would
be introduced if it were needed in the future. Unfortunately, Lintian
currently can't distinguish between that case and the case where the
linker was told not to link against libc at all.

In theory it would be possible to do better in Lintian by scanning the
symbol table to see if the libc dependency is really unneeded. But doing
that sounds at least a little annoying. Downgrading the tag is not really
a fix. That doesn't make the false positives go away; it just encourages
people to ignore more Lintian tags. If people think the problem the tag
was designed to detect is so rare as to warrant downgrading to pedantic, I
would just delete the check entirely.

I have a warning flag set in the back of my head that it's possible for
GCC to introduce calls into libc even if they're not present in the source
(memcpy, maybe?) unless you explicitly tell it to build things in
standalone mode, although maybe I'm misremembering. It's certainly easy to
introduce a libc dependency by writing normal C code and calling some
function that's universally available, including on Windows, without
thinking about it, thus making the state of "not using libc" somewhat
unstable. But problems like that combined with a build system error of
omitting libc entirely are probably much less common than as-needed
removing libc because it's not needed.

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

Re: DEP-14: Default branch name 'debian/latest' objections?

[Simon McVittie]

On Sun, 26 Jan 2025 at 09:04:52 +0100, Rene Engelhard wrote:
> Am 26.01.25 um 02:07 schrieb Otto Kekäläinen:
> > Personally if I have some features that are not ready to be uploaded
> > for a long time, I would maintain them in a 'feature branch'. In some
> > cases that feature branch might live as a MR that is open for a very
> > long time.
>
> But then it's not "latest". I would call whet is in experimental for
> libreoffice "latest". Especially next week when 25.2.0 will be released
> 25.2.0 is the "latest" upstream final release, and 24.8.x is not :)

DEP-14 has naming schemes for two reasonable workflows, and I think a
lot of criticisms of it are assuming that one of them is the only one
and disregarding the other.

In the GNOME team we use debian/latest (the default branch in the git
repo) for the newest upstream version that we're packaging (whether
that's for unstable or experimental), and if necessary we create a
debian/trixie or debian/unstable branch for updates that target testing
and unstable while we already have a version in experimental. src:gtk4
and src:mutter are good examples. This is good if most of the package's
Debian maintainers are mostly focused on the development branch and
making few changes to the more-stable branch, or if the lifetime of a
development branch is quite short (6 months for GNOME).

When maintaining dbus and flatpak I use a different workflow, where the
default branch in the git repo is debian/unstable, and there's a parallel
debian/experimental branch for newer upstream releases that aren't
ready for unstable. At the moment both are inactive because the latest
upstream release of both dbus and flatpak is a stable 1.16.x release
(this is not coincidence, with my upstream hat on I made sure both would
be ready in time for trixie), but use of the debian/experimental branch
will resume as soon as we get a 1.17.0 development release. This is good
if the lifetime of the development branch is relatively long (generally
more like 1-3 years for dbus and flatpak), and bug fixing in the stable
branch is getting more Debian-maintainer attention.

Both workflows make sense, DEP-14 explicitly allows for both, and I think
it's an oversimplification to dismiss either one as never appropriate. Our
workflows should be as simple as possible, but no simpler.

It sounds as though, if you were using DEP-14 for LO, you would want
the workflow used in dbus and flatpak (with no debian/latest branch),
and not the workflow used in GNOME (with a debian/latest branch as
default). And that's fine! If I didn't think that was fine, I wouldn't
have chosen it for dbus and flatpak.

I think the debian/latest workflow (as used by the GNOME team) is a
better default to suggest to new maintainers, and a better default for
typical non-key packages where the upstream developer doesn't maintain
long-lived stable branches and the package doesn't usually have a
version in experimental. dbus is not a typical package; neither is LO,
and neither are things like gcc, systemd and the kernel. We should make
sure our policies accommodate these atypical packages, because many of
them are very important OS components, but we shouldn't necessarily let
them determine the defaults that we use for 90% of the archive.

I hope that makes sense?

I think this is an example of a wider design principle: defaults are
for the common case, and for inexperienced users (or in this case,
inexperienced developers) who have no basis for choosing whether they
want something non-default. It's OK if experienced users/developers
will often want to do something non-default to accommodate their more
complicated situation, because by the time they find themselves in that
more complicated situation, hopefully they're experienced enough to
make good decisions about how they will move away from the defaults,
and understand the cost vs. benefit of doing so.

smcv

Re: how to fix lintian error: library-not-linked-against-libc

[Ahmad Khalifa]

On 26/01/2025 12:41, Jeremy Bícha wrote:

On Sun, Jan 26, 2025 at 6:28 AM Ahmad Khalifa  wrote:

The lintian error is a great heads-up and it's up to the reader to
decide whether it's a true error to fix or a false-positive to override.


I have never seen this Lintian error actually be useful. I think an
error is far too strong for this; I think even a warning is too
strong; maybe info would be ok.


Good point. As a heads-up, Info-level is more appropriate or even Pedantic.

Also looking at this partial list of affected packages, 40% have 
overridden it - which is pretty high if it were a real error.


https://udd.debian.org/lintian-tag/library-not-linked-against-libc?affected=yes


--
Regards,
Ahmad

Re: DEP-14: Default branch name 'debian/latest' objections?

[Colin Watson]

On Fri, Jan 24, 2025 at 01:24:12PM -0800, Xiyue Deng wrote:
> I would like to echo on this point.  I had worked on a repository that
> has the "master" branch marked as the default branch on Salsa, which
> lacks many changes compared to the released version.  I tried to
> manually incorporate those changes, and only later found out that the
> actual latest branch is "debian/sid" and it did have everything
> up-to-date.  (Note that this has since been fixed[1]).  I think for new
> repository, standardizing on a name (either "debian/latest" or people's
> liking) helps identify where the latest work goes to.

I find myself in this situation from time to time as well.  However, I
disagree with your conclusion.  At least for me, and I'm going to guess
for most contributors, I wouldn't reliably think to look for a
non-default branch at all unless I was doing something a little more out
of the ordinary such as preparing an update for a stable release; it
wouldn't really matter whether that branch was called debian/master or
debian/main or debian/sid or debian/latest.  I usually work on the
assumption that the branch I get by "git clone" from Salsa is the one I
should be working on for the usual case of developing on unstable, and
since that assumption is nearly always correct, it saves me time and
energy over explicitly looking around for different branch names every
time I clone a repository (I work on a lot of different packages).

In the situation you outlined, it wouldn't have mattered to me one bit
whether the actual latest branch was called debian/sid or debian/latest;
I probably wouldn't have noticed it either way.  What would have
mattered to me was that it wasn't the default branch (HEAD on Salsa).

So, rather than worrying about the _name_ of the default branch, I'd
like to suggest a change to DEP-14 that I think would have broader
consensus and be more useful.

Currently, there's only one place where DEP-14 talks about the default
branch: the "Native packages" section says "the default branch of the
repository (as pointed by the HEAD reference) should be a development
branch".  I suggest that this recommendation should not be just for
native packages.  The "For development releases" section should say that
the branch for uploads to the current development release of the
furthest-upstream distribution handled in a given repository (typically
Debian) should be the default branch, as pointed to by the HEAD
reference.

DEP-14 needn't prescribe exactly what the name of that branch should be,
and if it does then we should pragmatically regard it only as an
indication of what tools that _create_ Debian packaging repositories
should do.  Renaming branches is intrusive (it still typically requires
manual action from anyone who has an existing clone and wants to pull
changes!), and so there can be no realistic expectation that existing
repositories will reliably change to follow a new suggested default
name.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Re: DEP-14: Default branch name 'debian/latest' objections?

[Rene Engelhard]

Hi,

Am 26.01.25 um 02:07 schrieb Otto Kekäläinen:

  I would
also expect that if the man page for munch is *not* on the master
branch, then it means that nobody else has written it and solved the
bug yet.


And exactly that assumption is wrong. (And contradicts what you say later, like 
in have a debian/experimental and merge it back late..)

Stuff which is in development upstream or in experimental exists, even if it is 
not in master.

Sometimes it's the version where stuff happens - like in freeze time where all 
stuff happens there since sid is (basically) frozen for anything not supposed 
to be for the release.


That would confuse people and waste peoples time.
People look up debian/latest and see stuff not relevant for sid where they ae 
working on/for. Especially on freezes where stuff still happens for 
experimental.

Or even worse, as follows:
"Latest stuff"? That would in my case be a version which will only be released 
in August and has not even have a pre-release yet. The alpha
will be in May only.

Personally if I have some features that are not ready to be uploaded
for a long time, I would maintain them in a 'feature branch'. In some
cases that feature branch might live as a MR that is open for a very
long time.

But then it's not "latest". I would call whet is in experimental for libreoffice 
"latest". Especially next week when 25.2.0 will be released 25.2.0 is the "latest" 
upstream final release, and 24.8.x is not :)

Or I might call it debian/experimental and upload to
experimental, but not merge to debian/latest until post early June in
the context of your question.


And if it never ends up in sid for a release?

In your workflow described above people will  get confused why they get LO 25.2 
instead of 24.8. That doesn't help for contributing to sids 24.8 package.


Regards,


Rene