Bug#1064381: ITP: elfkickers -- collection of programs that access and manipulate ELF files

[Gürkan Myczko]

On 21.02.2024 17:12, David Bremner wrote:

Gürkan Myczko  writes:


On 21.02.2024 12:28, David Bremner wrote:


Being the universal operating system, these tools are certainly not 
for

normal users
but more like developers and people in the embedded area.



I include developers in people who don't care about the implementation,


I have found sstrip to squeeze away some more kilobytes from binaries.


A list of the tools with what they do would be more useful.

Similar like elfutils it will only be interesting to people that want 
to

use it.


Sure, I'm not talking about making it interesting for every user, just
having a description that helps someone in the target audience find the
package and/or know if they want to install it.


You're right the long description is not very good, I will need to 
improve

this, noted. Thanks,

Bug#1064346: Source is missing errors on HTML source files

[roucaries bastien]

Le jeu. 22 févr. 2024 à 06:07, Shriram Ravindranathan  a écrit :
>
> Thank you Bastien,
> I tried doing this but it appears that the scripts to build these
> example files all depend on having the highlight binary itself installed
> on the machine. I am unsure whether it is okay to have the package
> depend on itself for building.

Yes and no.

Best use the built package to generate the file

Other way is staged build

Bastien
>
> On 21/02/24 11:20 pm, roucaries bastien wrote:
> > You should rebuilt from source also... See for instance how I do with 
> > node-long
>
> --
> Shriram Ravindranathan
> ters
>

Bug#1052028: ITP: pydantic-core -- Rust implementation of pydantic core functionality

[Andreas Tille]

Hi Timo,

any progress with pydantic-core?  I've checked Salsa for the string
"pydantic" but did not found pydantic-core there.  It would be really
great to have pydantic 2.x (I stumbled upon python-semantic-release
which also needs it to easily fix #1056503 by upgrading to latest
upstream which seems to work with Python3.12)

I need to admit I have no experience in Rust packaging so I can't
really help here but pushing some start to Salsa could be the first
step.

Kind regards
   Andreas.

-- 
http://fam-tille.de

Bug#1064436: lintian-brush: Missing git commit + changelog entry for added upstream/metadata

[Andreas Tille]

Package: lintian-brush
Version: 0.152
Severity: normal

Hi,

if upstream/metadata are added this is not added+commited to
the packaging repository.  There is also no changelog created
which should be something like

  * Add upstream metadata

Kind regards
Andreas.


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (501, 'testing'), (50, 'buildd-unstable'), (50, 'unstable'), (5, 
'experimental'), (1, 'buildd-experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.6.13-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE:de
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lintian-brush depends on:
ii  devscripts   2.23.7
ii  libc62.37-15
ii  libgcc-s114-20240201-3
ii  liblzma5 5.4.5-0.3
ii  libpython3.113.11.8-1
ii  libssl3  3.1.5-1
ii  python3  3.11.6-1
ii  python3-breezy   3.3.4-1.1
ii  python3-debian   0.1.49
ii  python3-debmutate0.68
ii  python3-distro-info  1.7
ii  python3-dulwich  0.21.6-1+b1
ii  python3-iniparse 0.5-2
ii  python3-iso8601  1.0.2-1
ii  python3-levenshtein  0.12.2-2+b5
ii  python3-psycopg2 2.9.9-1+b1
ii  python3-pyinotify0.9.6-2
ii  python3-ruamel.yaml  0.17.21-1
ii  python3-semver   2.10.2-3
ii  python3-tomlkit  0.12.3-1
ii  python3-tqdm 4.64.1-2
ii  python3-upstream-ontologist  0.1.35-1

Versions of packages lintian-brush recommends:
ii  debhelper 13.13
ii  decopy0.2.4.8-0.1
ii  dos2unix  7.5.1-1
ii  gpg   2.2.40-1.1+b1
ii  lintian   2.117.0
ii  ognibuild 0.0.18+git20230208.1.9b890a2-1
ii  python3-bs4   4.12.3-1
ii  python3-docutils  0.20.1+dfsg-3
ii  python3-lxml  5.1.0-1
ii  python3-markdown  3.5.2-1

Versions of packages lintian-brush suggests:
ii  brz-debian 2.8.78
ii  git-buildpackage   0.9.33
pn  gnome-pkg-tools
ii  po-debconf 1.0.21+nmu1
ii  postgresql-common  257

-- no debconf information

Bug#1064435: gthumb: please package new upstream 3.12.5

[Martin-Éric Racine]

Package: gthumb
Version: 3:3.12.4-1~bpo12+1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Upstream released 3.12.5 on Februrary 18th 2024. Could you please package it?

Martin-Éric

PS: a backport to Bookworm would also be appreciated. :)

- -- System Information:
Debian Release: 12.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable-debug'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-18-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=fi_FI.utf8, LC_CTYPE=fi_FI.utf8 (charmap=UTF-8), LANGUAGE=fi:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gthumb depends on:
ii  gsettings-desktop-schemas   43.0-1
ii  gthumb-data 3:3.12.4-1~bpo12+1
ii  libbrasero-media3-1 3.12.3-2
ii  libc6   2.36-9+deb12u4
ii  libcairo2   1.16.0-7
ii  libcolord2  1.4.6-2.2
ii  libexiv2-27 0.27.6-1
ii  libgcc-s1   12.2.0-14
ii  libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1
ii  libgl1-mesa-dri 22.3.6-1+deb12u1
ii  libglib2.0-02.74.6-2
ii  libgstreamer-plugins-base1.0-0  1.22.0-3+deb12u1
ii  libgstreamer1.0-0   1.22.0-2
ii  libgtk-3-0  3.24.38-2~deb12u1
ii  libheif11.15.1-1
ii  libjpeg62-turbo 1:2.1.5-2
ii  libjxl0.7   0.7.0-10
ii  liblcms2-2  2.14-2
ii  libpango-1.0-0  1.50.12+ds-1
ii  libpangocairo-1.0-0 1.50.12+ds-1
ii  libpng16-16 1.6.39-2
ii  libraw200.20.2-2.1
ii  librsvg2-2  2.54.7+dfsg-1~deb12u1
ii  libstdc++6  12.2.0-14
ii  libtiff64.5.0-6+deb12u1
ii  libwebp71.2.4-0.2+deb12u1
ii  libx11-62:1.8.4-2+deb12u2
ii  zlib1g  1:1.2.13.dfsg-1

gthumb recommends no packages.

gthumb suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmXW9k4ACgkQrh+Cd8S0
17akgg//VWGfr+4sS/UuNHNKr/KHMAEq2EV1Cv00HzNq5yHl8Zokn8gpvy3Iyd4S
G0glnLly5gaLocdmOFX2+hHV/N80eA7luIOrT3uKdoVwGeJNWU5TJRGBaPetWgCv
SBkAVo8cfGHuMK0fwbZq5ENxBU/MITFDmpUl3pPI/ktdInXu13GpC3cjW8gJVgP5
xiXFq1/Rht0vb2dkccz6dV7rrkIO8n7WA8b8WRieIZXcApSZ16gNoimFYvtyjL3c
ifgtT17xXL7fHq4/1Nyg9QnvyCpGBsAswyux2TUDRBiMvPJ3BB1S8lLnze9tZgTm
hniG2xgd4EICNnX8sICNfxtmfwJ3xFcXvYwxb6+4dKQ+wos/juh0YOnKmZqS1GMQ
qcP6oI55UsRsSRYp6KFXRhnjUnPra/ATY/4RNNwiGzALOqWkXp1kUQ6qpfb4HPdn
YVG+tkw1C5/wBnrNR1r2TLgyi4wCPTSEG4qBzHAX+RmVOcT8w6iD/4cjRghvE5S+
6CKzy5+IryC2nAyhRkU/XMrPNRXehqwjKPz92V1G0lD1+O2U+7INLYJaBTrIH/XM
oPYyXDHVx5pjJfU0ERvncMp38CGTdGHXFjLmQItYL0r1LR5g0wi5xWnpCUQvWQ5e
brUa9dXEQ0ADDRQyFTjlAC0TAHI6kxZy6eH+fvrClCvjb2QTHQI=
=kvh7
-END PGP SIGNATURE-

Bug#1064402: texlive-binaries: tex-common configure: lua error : startup file: /bin/mtxrun.lua:2438: attempt to assign to const variable 'i'

[Preuße]

On 21.02.2024 16:15, Vincent Lefevre wrote:

Hi Vincent,


Indeed, I can reproduce the problem on another machine, only with
luametatex 2.11.01+ds-2:

qaa:~> mtxrun --generate
lua error : startup file: /bin/mtxrun.lua:2438: attempt to assign to const 
variable 'i'

You'll see the failure in an upgrade if you upgrade luametatex at the
same time as the TeX Live packages (at least, *not after* TeX Live).



Thanks for the report, I'll have a look at that soon.

Hilmar
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1036231: mbedtls: please update to 3.4.0 for cmake support

[Jakob Haufe]

On Wed, 17 May 2023 21:51:44 +0200 Andrea Pappacoda  wrote:

> I'd love to package the 3.x branch, but there currently isn't any LTS 
> release for it; the latest LTS is 2.28.x. I'm not going to package 
> non-LTS versions in Debian, since they don't fit nicely with the stable 
> release scheme.

I think that ship has sailed. According to [1], 2.28.x will be supported
until the end of 2024, so it will be EOL during the bookworm stable period.

Would you be open to package 3.x for experimental so ITPs depending on it can
progress?

If you intend to have 2.x around for longer, maybe a separate source package
(mbedtls3 ?) is necessary to allow packaging them in parallel.

Cheers,
sur5r

[1] https://github.com/Mbed-TLS/mbedtls/releases/tag/v2.28.7

-- 
ceterum censeo microsoftem esse delendam.


pgpfwggKfcNld.pgp
Description: OpenPGP digital signature

Bug#1064346: New upload with fixes

[Shriram Ravindranathan]

Thank you Soren and Bastien,

I have uploaded a new version of highlight

changes since last upload:
 - Add sources to d/missing-sources/
 - Add lintian overrides for all missing-sources with the paths to the 
sources

 - Add copyright stanzas for newly added missing-sources
 - Add d/p/0004-escape-groff-backslash.patch (Fixes groff syntax error 
and lintian warning)


--
Shriram Ravindranathan



OpenPGP_0xFC7E951A7BEF0836.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1062841: [debian-mysql] Bug#1062841: mariadb: NMU diff for 64-bit time_t transition

[Otto Kekäläinen]

Hi Graham!

I have your change pending at
https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/68.
Do you want me to put it into unstable now?

Bug#1064346: Source is missing errors on HTML source files

[Shriram Ravindranathan]

Thank you Bastien,
I tried doing this but it appears that the scripts to build these 
example files all depend on having the highlight binary itself installed 
on the machine. I am unsure whether it is okay to have the package 
depend on itself for building.


On 21/02/24 11:20 pm, roucaries bastien wrote:

You should rebuilt from source also... See for instance how I do with node-long


--
Shriram Ravindranathan
ters



OpenPGP_0xFC7E951A7BEF0836.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1064428: [Britney] does not migrate new arch:all packages after initial migration of same source

[Paul Gevers]

Hi Dalton,

Good to have this discussion. I'll add a few remarks on behavior in 
Debian in this e-mail.


On 21-02-2024 23:50, Dalton Durst wrote:

test-src migrated after its amd64 and i386 binaries appeared. It also
has architecture-independent binaries that miraculously only showed up
after migration was complete (maybe someone hinted through the package
too early).


Well, if somebody hinted a package to testing that's supposed to have an 
arch:all build, than they can keep the pieces ;) (or in other words, it 
should be on their radar and they could deal with it). Not saying that 
that's ok, but the hint is obviously wrong in that case.



If the
package were binNMU'd, though, britney would migrate everything
including the arch:all package if it passed checks.


In Debian, binNMU-ing a arch:all package is known to not work. I don't 
know if this bug is the reason why it doesn't work, but I've been taught 
this when I joined the Release Team. I think I tried once by accident 
(or ignorance) and the binNMU didn't work.



This behavior
instability might be undesirable.


But there _might_ be more infrastructure problems than britney2.


The code which skips arch:all packages dates all the way back to
britney2's original import[1], so it's not clear if it's still
load-bearing.


In the old days, an arch:all package was never build on a buildd, but 
uploaded by the uploader (together with the source). It's very possible 
that that fact is related to the original intent.



Should britney be given the ability to test arch:all packages in
ExcuseFinder by removing the block of code? If not, should it at least
give a REJECTED_CANNOT_DETERMINE_IF_PERMANENT output to help an archive
admin figure out what's going on?


I am currently working an a change to britney2 that (based on 
Package-List entries in the Sources) will prevent migration of sources 
which build arch:all binaries. That will also work around bug #915948 
(in dak) and fix bug #887060 (in britney2 for Sources build from 
source.changes files). From our conversation on IRC I take it that that 
wouldn't solve *your* case as you're using aptly and apparently that 
builds the Sources (with or without a Package-List) from what's in the 
archive so it would still run into this issue.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1064434: Missing "cryptsetup-initramfs" in the encrypted persistence example.

[sasha0552]

Package: live-manual
Version: 2:20151217.2
Severity: normal
Tags: patch

Please include cryptsetup-initramfs in the documentation, as it is 
essential for using LUKS-encrypted persistence partitions.


--- a/manual/en/user_customization-runtime.ssi
+++ b/manual/en/user_customization-runtime.ssi
@@ -209,7 +209,7 @@
 code{

  $ lb config
- $ echo "cryptsetup" > config/package-lists/encryption.list.chroot
+ $ echo "cryptsetup cryptsetup-initramfs" > 
config/package-lists/encryption.list.chroot


 }code

Bug#1062671:

[Michael Hudson-Doyle]

I have taken the patch from this bug, applied it to 1.3.5012+dfsg-2.1 from
unstable and uploaded it to experimental. Feel free to ignore this /
overwrite it if it interferes with other plans but we want to make sure it
passes binary NEW before we start uploading things to unstable.

Bug#1051582: Policy 9.3 (Starting system services) is largely obsolete

[Sean Whitton]

Hello,

On Mon 11 Sep 2023 at 01:04pm +02, Santiago Vila wrote:

> I wrote:
>> I believe that by choosing the wording appropriately, we can still keep this
>> desired property of Policy while still not mandating any given 
>> implementation.
>
> Sorry, that was terribly worded. I meant that we can avoid the hassle of
> documenting everything dh_installsystemd does and at the same time not
> *formally* mandating the use of dh_installsystemd.

In general, I agree with Santiago.  I find Policy's current scope and
working process effective, and not especially ambiguous.
I think everyone should read it during the NM process, if not sooner.

Russ has concretely considered these issues much more than me, and Niels
has worked extensively on an implementation, and I have not.
These things count, so my sense that things are broadly okay as they are
only goes so far.

I do think we should put weight on our actual experiences as Debian
contributors, and what's useful, and, as elsewhere in software, focus on
incremental improvements over rewrites.  For example, I think that the
knowledge of good documentation practices that's already implicit in how
we all actually write Policy text counts for more than abstract
discussions of best practice.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1058645: ITP: hare -- Hare is a systems programming language designed to be simple, stable, and robust.

[Amin Bandali]

X-Debbugs-Cc: martin.quin...@ens-rennes.fr, cla...@gmail.com

Hi all,

I too am interested in working on getting hare packaged and uploaded.
I also just sent a reply on https://bugs.debian.org/1058646 asking if
Miguel has a WIP repo for QBE packaging up on Salsa somewhere that
I could pull in and work on, otherwise I'll just start with a repo
under my account and later transfer it elsewhere (e.g. to 'debian').

We also need to package harec, the Hare bootstrap compiler, which
at the moment is a separate repo https://git.sr.ht/~sircmpwn/harec
but I believe upstream has plans to merge it into the hare repo:
https://lists.sr.ht/~sircmpwn/hare-rfc/%3CZdYKdoIWSUUpDeIX%40xha.li%3E

I'm not sure exactly how far into the future this will be though.
One of the main Hare developers said it will probably be done before
the next 0.24.1 release, but not sure.  Still, I held off on filing
a separate ITP for harec for now, to see if Drew chimes in with a
more concrete plan/timeline over the next day or two perhaps.

If there's no further feedback/timeline on the plans for the proposed
merge of the harec and hare repos, I plan on filing an ITP for harec
so we could go ahead with a separate harec source package for now
corresponding to the current repo structures, until if/when upstream
merges the two repos and we would re-evaluate our options then.

Any thoughts/feedback appreciated and welcome. :-)

Thanks,
-a

Bug#1058646: ITP: qbe -- Small embeddable C compiler backend

[Amin Bandali]

Hi Miguel,

I'm interested in helping with this.  Do you have the current state 
of your work available on Salsa or elsewhere that I could pull in
and work on?  Otherwise I'll just start with a repo under my own
account and we could later transfer it to the 'debian' group or
elsewhere.

Thanks,
-a

Bug#525813: apt-file: Doesn't work very well when multiple package versions are available

[Christoph Anton Mitterer]

Hey.

I took the liberty to forcemerge these two bugs (578727 and 525813) as
they seem to be about the same thing.

My suggestion would be that per default, the apt-file should print the
package name with =version.
Perhaps with the exception if only one version is available (or maybe
there should be an option, that causes the =version to be omitted, if
and only if, only on version is available).

When specifying the package name I think it should also allow =version
to be appended and follow the behaviour of e.g. apt-get cache, that is:
- if no version is given, match all available versions
- if one is given, match only that.


Cheers,
Chris.

Bug#1064433: RFS: golang-github-txthinking-runnergroup/0~git230325-1 [ITP] -- RunnerGroup library for golang

[Danial Behzadi]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package
"golang-github-txthinking-runnergroup":

* Package name : golang-github-txthinking-runnergroup
  Version  : 0~git230325-1
  Upstream contact : https://github.com/txthinking/runnergroup
* URL  : https://github.com/txthinking/runnergroup
* License  : MIT
* Vcs  :
https://salsa.debian.org/danialbehzadi/golang-github-txthinking-runnergroup
  Section  : golang

The source builds the following binary packages:

 golang-github-txthinking-runnergroup-dev - RunnerGroup library for
golang

To access further information about this package, please visit the
following URL:


https://mentors.debian.net/package/golang-github-txthinking-runnergroup/

Alternatively, you can download the package with 'dget' using this
command:

 dget -x
https://mentors.debian.net/debian/pool/main/g/golang-github-txthinking-runnergroup/golang-github-txthinking-runnergroup_0~git230325-1.dsc

Changes for the initial release:

golang-github-txthinking-runnergroup (0~git230325-1) unstable;
urgency=medium
.
  * Initial release. (Closes: #1064432)

Regards,
--
Danial Behzadi

Bug#1057538: lombok: java.lang.NoSuchFieldError - exception when building with Java 21 default

[Vladimir Petko]

Dear Maintainers,

  Would it be possible to consider a merge request[1] that addresses this issue?

Best Regards,
 Vladimir.

 [1] https://salsa.debian.org/java-team/lombok/-/merge_requests/3

Bug#1064432: ITP: golang-github-txthinking-runnergroup -- RunnerGroup library for Golang.

[Danial Behzadi]

Package: wnpp
Severity: wishlist
Owner: Danial Behzadi 
X-Debbugs-Cc: debian-de...@lists.debian.org, dani.be...@ubuntu.com

* Package name: golang-github-txthinking-runnergroup
  Version : 0
  Upstream Contact: txthinking 
* URL : https://github.com/txthinking/runnergroup
* License : MIT
  Programming Lang: Golang
  Description : RunnerGroup library for Golang

RunnerGroup is a library for Golang which is very simillar to sync.WaitGroup.
The diffrence is if one task stops, all of the task will be stopped.

This is a dependency for Socks5 library of Golang which itself is a
dependency for the package snowflake that I'm going to upgrade in
Debian.

Bug#1057538: lombok: java.lang.NoSuchFieldError - exception when building with Java 21 default

[Vladimir Petko]

Apologies for the wrong build link, the correct one is for jcabi-log[1]

[1] 
https://launchpadlibrarian.net/715257895/buildlog_ubuntu-noble-amd64.jcabi-log_0.19.0-1_BUILDING.txt.gz

On Thu, Feb 22, 2024 at 12:41 PM Vladimir Petko
 wrote:
>
> Dear Maintainers,
>
>  I apologise, in the previous MR I have forgotten to add  Java 21
> runtime support patch[1]  and the issue is still present[2]. I have
> reopened the bug.
>
> Best Regards,
>  Vladimir.
>
> [1] 
> https://github.com/projectlombok/lombok/commit/f6ca064d752a85ca799978b1afc87510c5e220f1
> [2] 
> https://launchpad.net/~vpa1977/+archive/ubuntu/october-21/+build/27797937/+files/buildlog_ubuntu-noble-amd64.ddogleg_0.22+ds-1_BUILDING.txt.gz

Bug#1057538: lombok: java.lang.NoSuchFieldError - exception when building with Java 21 default

[Vladimir Petko]

Dear Maintainers,

 I apologise, in the previous MR I have forgotten to add  Java 21
runtime support patch[1]  and the issue is still present[2]. I have
reopened the bug.

Best Regards,
 Vladimir.

[1] 
https://github.com/projectlombok/lombok/commit/f6ca064d752a85ca799978b1afc87510c5e220f1
[2] 
https://launchpad.net/~vpa1977/+archive/ubuntu/october-21/+build/27797937/+files/buildlog_ubuntu-noble-amd64.ddogleg_0.22+ds-1_BUILDING.txt.gz

Bug#1064431: mirror submission for mirror.fra.macarne.com

[Macarne LLC]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirror.fra.macarne.com
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 hurd-amd64 i386 
mips mips64el mipsel powerpc ppc64el riscv64 s390x
Archive-http: /debian/
Maintainer: Macarne LLC 
Country: DE Germany
Location: Frankfurt am Main
Sponsor: Macarne LLC https://macarne.com




Trace Url: http://mirror.fra.macarne.com/debian/project/trace/
Trace Url: 
http://mirror.fra.macarne.com/debian/project/trace/ftp-master.debian.org
Trace Url: 
http://mirror.fra.macarne.com/debian/project/trace/mirror.fra.macarne.com

Bug#1064430: android-sdk-meta: install udev rules into /usr

[Michael Biebl]

Source: android-sdk-meta
Version: 28.0.2+9
Severity: normal
Tags: patch trixie sid
User: helm...@debian.org
Usertags: dep17m2

We want to finalize the /usr-merge via DEP17 by moving all files to
/usr. android-sdk-meta installs files into /lib; these should be moved
into the respective canonical locations in /usr/.

Please find a patch attached. It has been build-tested.

This should not be backported to bookworm. If you intend to
backport, please use dh_movetousr instead.

If your package will change for the t64 transition or otherwise
rename/split/move its binaries (packages) during trixie, please
then upload to experimental and get in touch with the UsrMerge
driver, please see the wiki [1].

Michael

[1] https://wiki.debian.org/UsrMerge
diff -Nru 
android-sdk-meta-28.0.2+9/debian/android-sdk-platform-tools-common.install 
android-sdk-meta-28.0.2+9+nmu1/debian/android-sdk-platform-tools-common.install
--- android-sdk-meta-28.0.2+9/debian/android-sdk-platform-tools-common.install  
2023-01-24 07:07:40.0 +0100
+++ 
android-sdk-meta-28.0.2+9+nmu1/debian/android-sdk-platform-tools-common.install 
2024-02-22 00:34:35.0 +0100
@@ -1,3 +1,3 @@
-51-android.rules lib/udev/rules.d
+51-android.rules usr/lib/udev/rules.d
 debian/android-sdk.metainfo.xml  usr/share/metainfo
 platform-tools/* usr/lib/android-sdk/platform-tools
diff -Nru android-sdk-meta-28.0.2+9/debian/changelog 
android-sdk-meta-28.0.2+9+nmu1/debian/changelog
--- android-sdk-meta-28.0.2+9/debian/changelog  2023-01-24 07:07:40.0 
+0100
+++ android-sdk-meta-28.0.2+9+nmu1/debian/changelog 2024-02-22 
00:34:36.0 +0100
@@ -1,3 +1,10 @@
+android-sdk-meta (28.0.2+9+nmu1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Install udev rules into /usr. (Closes: #-1)
+
+ -- Michael Biebl   Thu, 22 Feb 2024 00:34:36 +0100
+
 android-sdk-meta (28.0.2+9) unstable; urgency=medium
 
   * Team upload.

Bug#1064429: ITP: glome -- Generic Low Overhead Message Exchange

[Valentin Vidic]

Package: wnpp
Severity: wishlist
Owner: Valentin Vidic 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: glome
  Version : 0.1
* URL : https://github.com/google/glome
* License : Apache-2.0
  Programming Lang: C
  Description : Generic Low Overhead Message Exchange

Generic Low Overhead Message Exchange (GLOME) is a protocol providing
secure authentication and authorization for low dependency environments.
It resembles one-time authorization codes (aka OTPs) but is different
from HOTP and TOTP in the following ways:
 * It is stateless (unlike HOTP).
 * It does not depend on time unlike TOTP).
 * It does not require predefined secret sharing (unlike HOTP and TOTP).

These properties make it a good choice for low dependency environments
(e.g., devices with no persistent storage a real-time clock). It can be
also useful for managing access to a large fleet of hosts where
synchronising state or sharing predefined secrets can be a challenge.

The package provides a PAM module, login(1) replacement, CLI utility and
a shared library.

Bug#1064428:

[Dalton Durst]

Sorry, missed the links mentioned by [1] and [2] in the above mail.

[1] 
https://salsa.debian.org/release-team/britney2/-/commit/b1603db2e459a2499de76d38179e49107d46be9d#7440b429abaafd59360558493c5473fab20e5088_0_425
[2] 
https://salsa.debian.org/release-team/britney2/-/blob/7544ecb2b24e00344f74912fa5dc236114aee515/britney2/excusefinder.py#L140-145

Bug#1064428: [Britney] does not migrate new arch:all packages after initial migration of same source

[Dalton Durst]

Package: release.debian.org
Severity: normal
Usertags: britney

Consider the following situation:

test-src migrated after its amd64 and i386 binaries appeared. It also
has architecture-independent binaries that miraculously only showed up
after migration was complete (maybe someone hinted through the package
too early).

When this occurs, you might expect the arch:all binaries to migrate
normally or to get information from britney why that couldn't happen.
Instead, britney2 outputs the empty list in its excuses. This occurs
because ExcuseFinder._should_upgrade_srcarch explicitly skips all
architecture-independent binaries. If there are no other changes to the
source which would cause excuses output, britney says nothing. If the
package were binNMU'd, though, britney would migrate everything
including the arch:all package if it passed checks. This behavior
instability might be undesirable.

The code which skips arch:all packages dates all the way back to
britney2's original import[1], so it's not clear if it's still
load-bearing. I've been researching the reason for the explicit ignore,
but I've come up empty. For my part, I removed the descendant of the
code[2] and only hit #1064427 when running britney2-tests against it.

This may also relate to bugs like #909555, but without a reproduction
case I wouldn't hold my breath on that.

Should britney be given the ability to test arch:all packages in
ExcuseFinder by removing the block of code? If not, should it at least
give a REJECTED_CANNOT_DETERMINE_IF_PERMANENT output to help an archive
admin figure out what's going on?

I've attached a patch to britney2-tests which adds a test case to
demonstrate this situation.

Thanks,
Dalton


0001-New-arch-all-binary-on-migrated-source.patch
Description: Binary data

Bug#1064394: release-notes: English language output for the commands into script session

[Justin B Rye]

I've just noticed that we're discussing this on debian-doc without
always Ccing the bug - see
https://lists.debian.org/debian-doc/2024/02/threads.html

Franco Martelli wrote:
>> immediately preceding line invoking screen with a 2>~/foo redirection*
>> won't work on csh (tested with bookworm's tcsh).
> 
> Yes, the redirection of only stderr is not allowed in csh but with the new
> "script" command syntax this will be solved:
> 
> # script -T ~/upgrade-trixie-step.time -a ~/upgrade-trixie-step.script

(We're imagining italic "variable" markup on "-step")
 
>> So I'm not sure there's any point using anything longer than:
>> 
>> # export LC_ALL=C.UTF-8 LANGUAGE=
> 
> Yes, but what's wrong if we have a syntax portable to all shells? If
> available.

What's wrong is that people might use csh!  Nobody's been checking the
Release Notes for csh-compatibility, so recipes assume you can say
things like "cd $(mktemp -d)".  Who are these people using csh, and
how do we stop them?

(In fact that use of $() is the only other incompatibility I can see
at the moment, but who's going to remember to check each new incoming
recipe next year?)
 
>> (But doing it separately from starting "script" does make sense, if
>> only to give us room for an explanation.)
> 
> Sorry I missed the sense, what explanation?

If we said "LC_ALL=C.UTF-8 LANGUAGE= script -T ..." it would have all
sorts of disadvantages, including the fact that we'd have to explain
all of it together.  Much easier to explain about script, then suggest
a "script -T..." commandline, *then* deal with locales separately.
 
>> I don't think the Release Notes ever mention the fact that we assume
>> a Bourne shell, but if you boot into an initrd rescue shell expecting
>> it to be csh then your day hasn't finished getting worse.
> 
> Again, only if available, why don't we use a portable syntax to all shells?

"Portable" in the sense of "POSIX-ish" (including things like ksh or
zsh) makes sense.  But the thing we should be recommending to anyone
doing a dist-upgrade under csh or fish or intercal is "please stop".

>> Ah, yes, avoiding the tricky redirection syntax (worthwhile even if
>> we don't care about csh).  But if we're assuming this is already a
>> root session, "~/foo" will  put that log in /root/; maybe we should
>> say that instead of using tilde-expansion?
> 
> I'm for tilde-expansion I find it more elegant and more widespread use for
> referring to the home directory.

The question is, will users realise that they're putting the files in
*root's* home directory, and will they even know where that is?

If we really can't suggest using /var/tmp for this, that seems a pity;
that location *shouldn't* be wiped on reboot, and it's usable whether
you're running "sudo; screen" or "sudo screen" or "screen; sudo".
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#1058645: Hare packages for Linux

[Martin Quinson]

Le mercredi 21 février 2024 à 14:50 +0200, Classic a écrit :
> Hello everyone,
> 
> I built deb package for Ubuntu 22.04
> https://alexey.nyc3.cdn.digitaloceanspaces.com/hare-dist/U22/hare_0.24.0-1_amd64.deb

Hello,

is the source package available somewhere? I happen to be a Debian developper
and could upstream your work, maybe. For the reference, previous attempt was
discussed here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1058645 (for
Hare) and here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1058646 (for
qbe). 

It would be nice if you could keep the 1058645 bug in CC when discussing of the
Debian packaging, please. 


Thanks,
Mt


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

Bug#1063789: RFS: anew/0.2-1 -- Tool for adding new lines to files, skipping duplicates (program)

[Phil Wyett]

On Mon, 2024-02-12 at 16:15 -0300, Marcos Rodrigues de Carvalho (aka oday) 
wrote:
> Package: sponsorship-requests
> Severity: wishlist
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "anew":
> 
>  * Package name : anew
>    Version  : 0.2-1
>    Upstream contact : m...@tomhudson.co.uk
>  * URL  : https://github.com/tomnomnom/anew
>  * License  : Expat
>  * Vcs  : https://salsa.debian.org/marcos.rcarvalho/anew
>    Section  : golang
> 
> The source builds the following binary packages:
> 
>   anew - Tool for adding new lines to files, skipping duplicates (program)
> 
> To access further information about this package, please visit the following 
> URL:
> 
>   https://mentors.debian.net/package/anew/
> 
> Alternatively, you can download the package with 'dget' using this command:
> 
>   dget -x https://mentors.debian.net/debian/pool/main/a/anew/anew_0.2-1.dsc
> 
> Changes for the initial release:
> 
>  anew (0.2-1) unstable; urgency=medium
> 
>    * New upstream release.
> 
> Regards,
> 
>   Marcos Rodrigues de Carvalho (aka oday)
> 

Hi,

Thank you for contributing to Debian.

This is a new package to Debian. Whatever version you upload to mentors as the 
latest, it
should be the only entry in the 'debian/changelog' with the initial release 
info and
closing the ITP bug. Once in Debian you will then add new 'debian/changelog' 
entries per
upload/release etc.

Regards

Phil

-- 
Playing the game for the games sake.

Web:

* Debian Wiki: https://wiki.debian.org/PhilWyett
* Website: https://kathenas.org
* Social Debian: https://pleroma.debian.social/kathenas/
* Social Instagram: https://www.instagram.com/kathenasorg/




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

Bug#1064427: [Britney] blocks a binNMU if a binary takeover of that package is in progress

[Dalton Durst]

Package: release.debian.org
Severity: normal
Usertags: britney

Consider the following situation:

  * pkga produces takeover and pkga1
- it is already in testing
  * pkgb is taking over takeover and also produces pkgb1
- it is not a candidate for migration because it is missing a build
  on i386 (that architecture still has old binaries from this
  source)
  * pkga has been binNMU'd

When this occurs, britney correctly declares pkgb unfit for migration.
However, it also declares pkga unfit for migration because pkgb's
'takeover' binary is considered pkga's cruft.

This condition only occurs when both source packages are considerable
for migration. If both source packages provide both binaries, pkgb is
found to supersede pkga, so pkga is not considered for migration. If
pkgb passes all policy, it will migrate and pkga will probably be
forgotten about (even though it considers pkgb its own cruft).

This may be expected behavior, but I exposed it in the bug-709460 test
case while trying to enable britney to check architecture-independent
packages. Currently the behavior is masked in that case because britney
skips the -doc package due to it being arch-indep. If this _is_ expected
behavior, bug-709460 is currently passing erroneously.

I've attached a patch to the britney2-tests repository adding a test
which demonstrates this situation. If britney2 is working as expected,
then bug-709460 may need to be changed so it does not cause this
situation. If not, what change is needed in britney?

Thanks,
Dalton

0001-WIP-Test-for-binNMU-occurring-during-a-halted-partia.patch
Description: Binary data

Bug#971673: node-jquery: build jquery.slim.js

[Praveen Arimbrathodiyil]

On Mon, 05 Oct 2020 00:25:37 +0530 Pirate Praveen 
 wrote:
A quick look in Gruntfile.js and a few tries of guessing the task name 
did not yeild any results.

https://stackoverflow.com/a/37750393 has,

Along with the regular version of jQuery that includes the ajax and 
effects modules, we’re releasing a “slim” version that excludes these 
modules. All in all, it excludes ajax, effects, and currently deprecated 
code.


though still not found how to build this version.


OpenPGP_0x8F53E0193B294B75.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1064426: evolver fails the last two autopkg tests with glibc 2.39 on amd64

[Matthias Klose]

Package: src:evolver
Version: 2.70+ds-8
Severity: important
Tags: sid trixie

evolver fails the last two autopkg tests with glibc 2.39 on amd64. 
Currently only seen in Ubuntu noble.


The segfaults are also seen when building without link time 
optimization, and when building with -O0.


https://bugs.launchpad.net/ubuntu/+source/evolver/+bug/2052929

However the build shows many format-overflow and stringop-overflow 
warnings already present in the Debian build.

Bug#1064425: src:breezy: fails to migrate to testing for too long: autopkgtest failure

[Paul Gevers]

Source: breezy
Version: 3.3.4-1.1
Severity: serious
Control: close -1 3.3.5-5
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:breezy has been trying to migrate for 31 
days [2]. Hence, I am filing this bug. The version in unstable fails its 
own autopkgtest: "No module named 'tzlocal'".


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=breezy



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1064424: src:castxml: fails to migrate to testing for too long: Build-Depends not available on mips64el

[Paul Gevers]

Source: castxml
Version: 0.6.2-2
Severity: serious
Control: close -1 0.6.3-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:castxml has been trying to migrate for 31 
days [2]. Hence, I am filing this bug. The version in unstable is 
missing it's build depends on mips64el and hence doesn't build. However, 
this package was build there in the past, so manual action is needed to 
resolve the matter (e.g. helping llvm-toolchain-17 maintainers to build 
for mips64el (bug #1062086) or by requesting castxml/mips64el removal 
from unstable).


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=castxml



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1064423: src:gnome-keyring: fails to migrate to testing for too long: FTBFS on s390x

[Paul Gevers]

Source: gnome-keyring
Version: 42.1-1
Severity: serious
Control: close -1 46.1-1
Tags: sid trixie ftbfs
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:gnome-keyring has been trying to migrate 
for 32 days [2]. Hence, I am filing this bug. The version in unstable 
(and version 42.2) failed to build on s390x.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=gnome-keyring



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#901631: Bug#901507: lintian: warn if debhelper is in B-D-Arch or B-D-Indep but not Build-Depends

[Niels Thykier]

On Mon, 18 Jun 2018 12:16:55 +0100 Simon McVittie  wrote:

On Sat, 16 Jun 2018 at 18:45:56 +0100, Chris Lamb wrote:
> I'm also seeing a bunch of false-positives in the addon checker -
> using the dh Python addon shouldn't mean that python can't be in
> Build-Depends-Indep. Or dpatch!

Sure - I hadn't intended that you'd add this mechanism for packages that
ship debhelper addons alongside other content, just the ones that have
little or no purpose other than their debhelper addons, like most/all
of the dh-$addon family, and maybe some of the pkg-$team-tools family.



Hi,

Drive by remark from the debhelper maintainer.

Some dh add-ons can be in ``Build-Depends-Indep`` now and is used to 
support cross-building in some cases. I do not remember when the feature 
was added though, so it might not have been possible at the time this 
was filed.


It is hard to tell which add-ons can be in B-D-I, and which cannot. If
lintian is going to warn about it, I would recommend a static data list
for this.
Best regards,
Niels

Bug#1064422: src:ohai: fails to migrate to testing for too long: uploader built arch:all binary

[Paul Gevers]

Source: ohai
Version: 17.9.0-2
Severity: serious
Control: close -1 18.1.3-2
Tags: sid trixie pending
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:ohai has been trying to migrate for 32 
days [2]. Hence, I am filing this bug.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


Your package is only blocked because the arch:all binary package(s) 
aren't built on a buildd. Unfortunately the Debian infrastructure 
doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will 
shortly do a no-changes source-only upload to DELAYED/15, closing this 
bug. Please let me know if I should delay or cancel that upload.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=ohai



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1064420: src:ruby-omniauth-alicloud: fails to migrate to testing for too long: uploader built arch:all binary

[Paul Gevers]

Source: ruby-omniauth-alicloud
Version: 2.0.1-2
Severity: serious
Control: close -1 3.0.0-2
Tags: sid trixie pending
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:ruby-omniauth-alicloud has been trying to 
migrate for 32 days [2]. Hence, I am filing this bug.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


Your package is only blocked because the arch:all binary package(s) 
aren't built on a buildd. Unfortunately the Debian infrastructure 
doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will 
shortly do a no-changes source-only upload to DELAYED/15, closing this 
bug. Please let me know if I should delay or cancel that upload.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=ruby-omniauth-alicloud



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1064421: refpolicy: show CIL warnings within semodule command

[Christian Göttsche]

Package: selinux-policy-default
Version: 2:2.20240202-1
Tags: patch

The invocation of semodule in the postinst maintanier script might
fail, e.g. due to conflicts with local modifications.
Since by default the CIL log level is error and those error messages
are rather generic the actual cause is most of the time not shown.
A solution is to run semodule in verbose mode, which increases the
verbosity of CIL from error to warning, see
https://github.com/SELinuxProject/selinux/blob/82195e77e317d322dd9b5fc31d402462d6845357/policycoreutils/semodule/semodule.c#L419:

--- debian/postinst.policy.bak  2024-02-21 21:56:04.383102610 +0100
+++ debian/postinst.policy  2024-02-21 21:56:09.307157364 +0100
@@ -117,7 +117,7 @@
   fi

   ret=0
-   semodule -X $priority $noreload -s $flavour $to_remove
$to_install $to_disable || ret=$?
+   semodule -v -X $priority $noreload -s $flavour $to_remove
$to_install $to_disable || ret=$?
   if [ $ret -eq 0 ]; then
   echo " done."
   else

Bug#1060829: fricas: please add support for loong64

[Camm Maguire]

Greetings!  I have gained access to a machine in the gcc compile farm
for this arch.  configure is failing due to missing header files.  If
you happen to be able to point me to a contact to address this I'd be
most appreciative!

Take care,

wuruilong  writes:

> Source: fricas
> Version: 1.3.8-8
> Severity: normal
> X-Debbugs-Cc: wuruil...@loongson.cn
>
> Dear Maintainer,
>
> Please refer to the attached patch to support the loong64 arch.
>
> wuruilong
>
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers unreleased
>   APT policy: (500, 'unreleased'), (500, 'unstable')
> Architecture: loong64 (loongarch64)
>
> Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads)
> Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: unable to detect
>
>

-- 
Camm Maguirec...@maguirefamily.org
==
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

Bug#1064394: release-notes: English language output for the commands into script session

[RL]

The following message is a courtesy copy of an article
that has been posted to gmane.linux.debian.devel.documentation as well.

Franco  writes:

> " If you are comfortable with English language it's strongly
> recommended that you run the following command as soon as you start
> the 'script' session:
>
>   # LC_ALL=C.UTF-8; LANGUAGE=; export LC_ALL LANGUAGE
>
>   This will allow you to get command output messages in English into
> the script session. By doing so, it will help you for searching the
> web, during discussions or to submit a bug report."

Are we *sure* this is a good idea - i have some doubts?

-- "strongly recommended" by who? where did anyone previously make this
recommendation and why do they feel so strongly that it is needed in
2024 when it has not been suggested before?

-- does anyone test the upgrade with this locale setting? telling people
to use something less tested seems like a bad idea.eg, i have
LANG=en_GB.UTF-8 would i still want to change locales?

-- why are we suggesting non-english message are somehow less clear? if
so, we should remove translations not hide them?

-- why are we making the output harder to read for the user - that will
make it harder for them to fix their own issue. isnt this is the
opposite of what we want?

-- isnt it better to say that if you get an error in non-english to
search the web for the english vesion? it's not like you cant look-up
the english version of the error message

-- are we suggesting errors are likely? that isnt my experience with debian
upgrades


(maybe it makes more sense to do this if the upgrade fails and you can't
debug)

Bug#1060682: __wrpll_calc_filter_range: post-divider reference freq out of range

[Aurelien Jarno]

Hi Heinrich,

On 2024-02-21 12:07, Heinrich Schuchardt wrote:
> the
> __wrpll_calc_filter_range: post-divider reference freq out of range
> issue is caused by corruption of the in memory device-tree.
> 
> The appended patch solves the issue.

Thanks a lot for debugging the issue. I have done a test with the debian
package and 3 different changelog entries to get 3 different
CONFIG_LOCALVERSION, and I can confirm that the bug is gone.

Regards
Aurelien

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

Bug#1064419: bookworm-pu: package node-neo-async/2.6.2+~cs3.0.0-2

[Praveen Arimbrathodiyil]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: node-neo-as...@packages.debian.org
Control: affects -1 + src:node-neo-async

[ Reason ]
#1064411 some files that are present in npm dist tarball was missing in 
the binary package (it was built but not included in the binary) shipped 
in debian. We noticed this only now since we are trying to integrate 
yarn-plugin-apt (which will use apt installed node modules when 
available) with gitlab in bookworm-fasttrack (fasttrack.debian.net) only 
now and which expects these missing files to be present.


[ Impact ]
We won't be able to switch to yarn-plugin-apt in bookworm.

[ Tests ]
This only includes files that were missing (gitlab's webpack build 
command was able to find the missing files after the fix).


[ Risks ]
It just adds files that were already built but not installed.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
Include all files in build directory also in the binary package (install 
them in /usr/share/nodejs/neo-async.


[ Other info ]
nothing more.
diff -Nru node-neo-async-2.6.2+~cs3.0.0/debian/changelog 
node-neo-async-2.6.2+~cs3.0.0/debian/changelog
--- node-neo-async-2.6.2+~cs3.0.0/debian/changelog  2021-08-14 
23:43:18.0 +0530
+++ node-neo-async-2.6.2+~cs3.0.0/debian/changelog  2024-02-22 
01:40:14.0 +0530
@@ -1,3 +1,9 @@
+node-neo-async (2.6.2+~cs3.0.0-2+deb12u1) bookworm; urgency=medium
+
+  * Include all files in build in the binary package (Closes: #1064411)
+
+ -- Pirate Praveen   Thu, 22 Feb 2024 01:40:14 +0530
+
 node-neo-async (2.6.2+~cs3.0.0-2) unstable; urgency=medium
 
   * Build asyncro commonjs format from ES module source
diff -Nru node-neo-async-2.6.2+~cs3.0.0/debian/node-neo-async.install 
node-neo-async-2.6.2+~cs3.0.0/debian/node-neo-async.install
--- node-neo-async-2.6.2+~cs3.0.0/debian/node-neo-async.install 1970-01-01 
05:30:00.0 +0530
+++ node-neo-async-2.6.2+~cs3.0.0/debian/node-neo-async.install 2024-02-22 
01:40:02.0 +0530
@@ -0,0 +1 @@
+build/* usr/share/nodejs/neo-async


OpenPGP_0x8F53E0193B294B75.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1007447: festlex-poslex: please consider upgrading to 3.0 source format

[Paul Gevers]

Hi Bastian,

On 21-02-2024 13:21, Bastian Germann wrote:

I am uploading a NMU to DELAYED/10 in order to fix this.
The debdiff is included.


Maybe you care to explain *why*?

Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1064394: release-notes: English language output for the commands into script session

[Franco Martelli]

On 21/02/24 at 16:00, Justin B Rye wrote:


I like this idea; but it might work better if we turn things around
and start with the possible problem before offering the solution.


Yes, my English is so scholastic.


A rephrased version:

 If you use a non-English locale during the upgrade, any progress
 or error messages are likely to be translated, so in the event of
 problems it may be difficult to get assistance from the Internet,
 or to submit a bug report. If you are comfortable using English
 then it is strongly recommended that you run the following command
 at the start of your 'script' session:

 # LC_ALL=C.UTF-8; LANGUAGE=; export LC_ALL LANGUAGE

 This will give you command output in English.


I agree


(Or do we also need to warn users to say "yes" and not "si"?)


It shouldn't be necessary, if the user is comfortable with English, 
already he should expect this. However end users behavior is unpredictable …



This change it has been discussed on debian-user mailing-list here. ²
The syntax of the command was designed to be portable to all shells,
csh included.


I'm sorry, but if you're doing vital root-privileged sysadmin tasks
under csh, things have already gone badly wrong; the instructions in
the Release Notes all assume a Bourne-family shell.  For instance, the
immediately preceding line invoking screen with a 2>~/foo redirection*
won't work on csh (tested with bookworm's tcsh).


Yes, the redirection of only stderr is not allowed in csh but with the 
new "script" command syntax this will be solved:


# script -T ~/upgrade-trixie-step.time -a ~/upgrade-trixie-step.script



So I'm not sure there's any point using anything longer than:

# export LC_ALL=C.UTF-8 LANGUAGE=


Yes, but what's wrong if we have a syntax portable to all shells? If 
available.



(But doing it separately from starting "script" does make sense, if
only to give us room for an explanation.)


Sorry I missed the sense, what explanation?


I don't think the Release Notes ever mention the fact that we assume
a Bourne shell, but if you boot into an initrd rescue shell expecting
it to be csh then your day hasn't finished getting worse.


Again, only if available, why don't we use a portable syntax to all shells?


Ah, yes, avoiding the tricky redirection syntax (worthwhile even if
we don't care about csh).  But if we're assuming this is already a
root session, "~/foo" will  put that log in /root/; maybe we should
say that instead of using tilde-expansion?


I'm for tilde-expansion I find it more elegant and more widespread use 
for referring to the home directory.


--
Franco Martelli

Bug#1064418: RFS: streamlink/6.6.2-1 -- CLI for extracting video streams from various websites to a video player

[Alexis Murzeau]

Package: sponsorship-requests
Severity: normal


Dear mentors,

I am looking for a sponsor for my package "streamlink" for a new
upstream version 6.6.2.

  * Package name: streamlink
Version : 6.6.2-1
Upstream Author : Streamlink Team
  * URL : https://streamlink.github.io/
  * License : BSD-2-clause, Apache-2.0, MIT/Expat, SIL-OFL-1.1
  * Vcs : https://salsa.debian.org/amurzeau/streamlink/
Section : python

It builds those binary packages:
  python3-streamlink - Python module for extracting video streams from
various websites
  python3-streamlink-doc - CLI for extracting video streams from
various websites (documentation)
  streamlink - CLI for extracting video streams from various websites
to a video player


To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/streamlink/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/s/streamlink/streamlink_6.6.2-1.dsc



Changes since the last upload to unstable:
streamlink (6.6.2-1) unstable; urgency=medium

  * New upstream version 6.6.2

 -- Alexis Murzeau   Wed, 21 Feb 2024 21:05:19 +0100

Regards,

--
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F|


OpenPGP_0xE7BD1904F480937F.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1064417: jansi1 misses actual jar with the library after rebuild

[Vladimir Petko]

Package: jansi1
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch

Dear Maintainer,

I apologise for sending this as a debdiff, since I think there is no branch for
jansi1 on salsa.

After maven-debian-helper changes to create a symlink to versioned jar instead
of vice-versa,
the actual jar is deleted during the package build.

This makes all gradle builds fail.

In Ubuntu, the attached patch was applied to achieve the following:

  * d/rules: do not delete versioned jar file (LP: #2054504).


Thanks for considering the patch.


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

Kernel: Linux 6.5.0-17-generic (SMP w/32 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru jansi1-1.18/debian/rules jansi1-1.18/debian/rules
--- jansi1-1.18/debian/rules2022-05-15 03:36:17.0 +1200
+++ jansi1-1.18/debian/rules2024-02-21 17:22:21.0 +1300
@@ -7,4 +7,3 @@
dh_auto_install
rm -Rf 
debian/libjansi1-java/usr/share/maven-repo/org/fusesource/jansi/jansi/1.18
rm -Rf 
debian/libjansi1-java/usr/share/maven-repo/org/fusesource/jansi/jansi-project/1.18
-   rm -Rf debian/libjansi1-java/usr/share/java/jansi1-1.18.jar

Bug#1064374: rust-gtk-layer-shell-sys: Depends on obsolete rust-gtk

[Matthias Geiger]

On Tue, 20 Feb 2024 17:22:36 -0500 =?UTF-8?Q?Jeremy_B=C3=ADcha?= 
 wrote:

> Source: rust-gtk-layer-shell-sys
> Version: 0.7.0-1
> Severity: serious
> X-Debbugs-CC: maytha8the...@gmail.com, sylves...@debian.org
>
> rust-gtk-layer-shell-sys (and rust-gtk-layer-shell) depends on
> rust-gtk which is the old GTK3 library that is no longer maintained.
> rust-gtk is only in Debian because of squeekboard.
>
> Please instead package https://crates.io/crates/gtk4-layer-shell and
> encourage apps using the old rust-gtk-layer-shell to switch to the
> gtk4 version.
>
> Please let me know if there is a reason we should not file a removal
> bug for rust-gtk-layer-shell-sys (which only appeared in Debian this
> month).
>
> On behalf of the Debian Rust Maintainers,
> Jeremy Bícha
>

>

Since this was packaged in preparation for swayosd (which I would like 
to see packaged in debian) I think the best way forward here is to 
vendor gtk-layershell(-sys) and its gtk3-rs related deps in (for 
swayosd) and remove it from debian.


GTK3-rs is eol upstream and building "mixed" is a good compromise imho 
until upstream switches to gtk4-layershell.


I will  try to prepare a MR for Maythams WIP packaging which does that.

best,

--
Matthias Geiger 
Debian Maintainer
"Freiheit ist immer Freiheit des anders Denkenden" -- Rosa Luxemburg



OpenPGP_0x18BD106B3B6C5475.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1046029: double build failures in libvitacilina-perl

[Étienne Mollier]

On both #1046029 and #1049522, the error shows:
> Error reading from file 'META.yml': UTF-8 "\xA1" does not map to Unicode
>  at /usr/share/perl5/Module/Install/Admin/Metadata.pm line 14.
> make[1]: *** [Makefile:832: realclean] Error 25

This is caused by the YAML parser to choke on the inverted
exclamation mark in the abstract which should be valid UTF-8[1]:

$ echo -e '\xC2\xA1'
¡

It looks like something in the parsing does not capture the C2A1
properly, and jumps straight to the A1, not sure what yet.  It
could be an issue in YAML::Tiny, or in perl (although I would
have expected much more fallouts if the latter).

[1]: https://www.utf8-chartable.de/

I will move on to lower hanging fruits for now,  ;)
-- 
  .''`.  Étienne Mollier 
 : :' :  pgp: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/5, please excuse my verbosity
   `-


signature.asc
Description: PGP signature

Bug#1064416: cbor2: CVE-2024-26134: Potential buffer overflow in CBOR2 decoder

[Salvatore Bonaccorso]

Source: cbor2
Version: 5.6.1-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for cbor2.

CVE-2024-26134[0]:
| cbor2 provides encoding and decoding for the Concise Binary Object
| Representation (CBOR) (RFC 8949) serialization format. Starting in
| version 5.5.1 and prior to version 5.6.2, an attacker can crash a
| service using cbor2 to parse a CBOR binary by sending a long enough
| object. Version 5.6.2 contains a patch for this issue.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-26134
https://www.cve.org/CVERecord?id=CVE-2024-26134
[1] https://github.com/agronholm/cbor2/security/advisories/GHSA-375g-39jq-vq7m
[2] 
https://github.com/agronholm/cbor2/commit/4de6991ba29bf2290d7b9d83525eda7d021873df

Regards,
Salvatore

Bug#1064415: prometheus-node-exporter-collectors: doesn't depend on prometheus-node-exporter really

[sergio]

Package: prometheus-node-exporter-collectors
Severity: normal

Dear Maintainer,

prometheus-node-exporter should be in Recommens, Suggests or even Enhances but 
not Depends.

prometheus-node-exporter-collectors works fine without prometheus-node-exporter,
it produces *.prom files that could be used by any other compatible
textfile exporter.

Bug#1064414: libcommons-compress-java: CVE-2024-26308

[Salvatore Bonaccorso]

Source: libcommons-compress-java
Version: 1.25.0-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 1.22-1

Hi,

The following vulnerability was published for libcommons-compress-java.

CVE-2024-26308[0]:
| Allocation of Resources Without Limits or Throttling vulnerability
| in Apache Commons Compress.This issue affects Apache Commons
| Compress: from 1.21 before 1.26.  Users are recommended to upgrade
| to version 1.26, which fixes the issue.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-26308
https://www.cve.org/CVERecord?id=CVE-2024-26308
[1] https://www.openwall.com/lists/oss-security/2024/02/19/2

Regards,
Salvatore

Bug#1064413: libcommons-compress-java: CVE-2024-25710

[Salvatore Bonaccorso]

Source: libcommons-compress-java
Version: 1.25.0-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 1.22-1
Control: found -1 1.20-1

Hi,

The following vulnerability was published for libcommons-compress-java.

CVE-2024-25710[0]:
| Loop with Unreachable Exit Condition ('Infinite Loop') vulnerability
| in Apache Commons Compress.This issue affects Apache Commons
| Compress: from 1.3 through 1.25.0.  Users are recommended to upgrade
| to version 1.26.0 which fixes the issue.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-25710
https://www.cve.org/CVERecord?id=CVE-2024-25710
[1] https://www.openwall.com/lists/oss-security/2024/02/19/1

Regards,
Salvatore

Bug#1032868: Bug#1064058: libxml-stream-perl: TLS/SSL broken with IO-Socket-SSL >= 2.078 when hostname verification is enabled

[gregor herrmann]

Control: reassign 1032868 libxml-stream-perl 1.24-4
Control: reassign 1050336 libxml-stream-perl 1.24-4
Control: fixed 1032868 1.24-5
Control: fixed 1050336 1.24-5
Control: tag 986971 bookworm sid trixie upstream
Control: tag 1032868 bookworm sid trixie upstream
Control: tag 1050336 bookworm sid trixie upstream


On Mon, 19 Feb 2024 20:48:26 +0100, Manfred Stock wrote:

> > I remember looking at #1050336 in libnet-xmpp-perl and having the
> > suspicion that the problem is actually in libxml-stream-perl, but
> > never managed to nail it down.
> It actually took me a while, too ;). 

Heh :)

> I think I ended up in XML-Stream
> because of the debug output, especially the binary part that was printed
> in the output of a read operation. A few detours later, I found the
> IO-Socket-SSL release where it stopped working and remembered that
> start_SSL() was called in XML::Stream and that an example in the
> documentation somewhere passed a hostname, which wasn't done in
> XML::Stream. 

And that was the nice finding.

> > I've uploaded libxml-stream-perl 1.24-5 to unstable right now.
> Thanks! I quickly tested this package and can confirm that it works for
> me.

Great, thanks.
 
> 
> > I'd like to invite the submitters of the other bugs to tests if there
> > problems are fixed with libxml-stream-perl 1.24-5.
> >
> > If yes, I'm happy to
> > - do some BTS manipulation
> > - more relevant: get this fix into bookworm for the next point
> >   release.
> 
> This would be great, thanks!

In #986971 Martin has already confirmed that libxml-stream-perl/1.24-5
fixes his issue, and the bug has been reassigned. I'm now reassigning
the other 2 bugs and will merge them later.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Bug#1064368: python-xarray: intermittent segfault in test_open_mfdataset_manyfiles[netcdf4-20-True-*-5]

[Rebecca N. Palmer]

Control: forwarded -1 https://github.com/pydata/xarray/issues/7079
(actually found independently)

The above upstream report suggests that this is because netcdf-python is 
no longer thread-safe.


The 3 random-autopkgtest-fail bugs (this, #1064326 and #1064370) 
together seem to be more common in pandas 2.  It's possible that some of 
them are actually the same underlying bug.

Bug#1064335: mutter-common: xwayland apps ignore scaling settings

[Austin Pringle]

This bug also appears to break window titles and window decorations 
under xwayland as well; now, server-side window controls no longer 
respect user preference for positioning, ie,  they always render on the 
left of the titlebar, even if the user has preferences set for them to 
be on the right, and it always draws minimize, maximize, and close, even 
if the user preferences only want the "close" button to be drawn.

On Tue, 20 Feb 2024 07:14:42 +0100 =?utf-8?q?Tam=C3=A1s_Golubov?= 
 wrote:

 > Package: mutter-common
 > Version: 44.8-3
 > Severity: normal
 > X-Debbugs-Cc: tamas.golu...@gmail.com
 >
 > Since the upgrade from 44.8-2 "legacy" apps that seem to use XWayland
 > completely ignore the scaling settings. I have a 4K monitor and 
scaling set to
 > 200%. When launching VLC, GIMP, synaptic, they appear very small, as they
 > ignore the scaling settings. Changing scaling on the fly doesn't change
 > anything, all other elements of the UI respond to the change but not 
the legacy
 > apps. Session type is set to Wayland, if I change it in GDM to X11, 
the same
 > behavior can be observed, but it's worse. When changing the scaling, 
the UI
 > responds, but even the settings app itself doesn't.
 >
 >
 > -- System Information:
 > Debian Release: trixie/sid
 > APT prefers stable-updates
 > APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'testing'), (500, 'stable')
 > Architecture: amd64 (x86_64)
 > Foreign Architectures: i386
 >
 > Kernel: Linux 6.6.15-amd64 (SMP w/6 CPU threads; PREEMPT)
 > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE not set
 > Shell: /bin/sh linked to /usr/bin/dash
 > Init: systemd (via /run/systemd/system)
 > LSM: AppArmor: enabled
 >
 > Versions of packages mutter-common depends on:
 > ii dconf-gsettings-backend [gsettings-backend] 0.40.0-4+b1
 >
 > mutter-common recommends no packages.
 >
 > mutter-common suggests no packages.
 >
 > -- no debconf information

-- 
--Austin Pringle
Email: arprin...@pm.me
Phone/Signal: (412) 951-3096

Bug#1064346: Source is missing errors on HTML source files

[roucaries bastien]

Le mer. 21 févr. 2024 à 15:38, Soren Stoutner  a écrit :
>
> Shriram,
>
> On Wednesday, February 21, 2024 8:30:54 AM MST Shriram Ravindranathan wrote:
> > Upon inspecting the embedded font, It seems to be a bespoke icon-font
> > generated using a tool called "Fontello" from one of the icons of the
> > octicons iconset from Atom  (MIT
> > Licensed SVGs)
> >
> > The font has only 1 glyph, Would it suffice to add this source image to
> > d/missing-souces and add that copyright info to d/copyright?
>
> I would assume so.  If anyone on mentors knows differently please speak up.
>
> > On 21/02/24 9:56 am, Soren Stoutner wrote:
> >
> > >
> > >
> > > Shriram,
> > >
> > >
> > >
> > >
> > > 1. For anything that has the unminified source in the upstream
> > > tarball, I would just create a lintian override with a comment listing
> > > the full path to the source for each file.  You can see an example of
> > > how this can be done here:
> > >
> > >
> > >
> > >
> > > https://salsa.debian.org/qt-kde-team/qt/qtwebengine/-/blob/master/debian/
> sou
> > > rce/lintian-overrides?ref_type=heads
> >
> > >
> > >
> > >
> > > Typically you only copy the source to the debian/missing-sources
> > > directory when it is not included in the upstream tarball and you have
> > > had to acquire it from another place.

You should rebuilt from source also... See for instance how I do with node-long
> > >
> > >
> > >
> > >
> > > 2. The github link below includes an embedded font in woff format.
> > > Typically, fonts like this would be considered compiled, so a separate
> > > font source would be needed.  However, I’m not sure what the Debian
> > > guidance for dealing with an HTML embedded font like this.  If someone
> > > else on mentors doesn’t know, I would recommend you ask on debian-legal.
> > >
> > >
> > >
> > >
> > > As these are mostly README files, and if it becomes difficult for you
> > > to acquire the source for some of them, you might consider excluding
> > > those you can’t get the source for, at least temporarily, using
> > > Files-Excluded in debian/copyright (and then running uscan, which will
> > > produce a modified tarball that does not include the problematic
> > > files).  For example, see:
> > >
> > >
> > >
> > >
> > > https://salsa.debian.org/cryptocoin-team/electrum/-/blob/master/debian/
> copyr
> > > ight?ref_type=heads
> >
> > >
> > >
> > >
> > > Whether this is a good option depends on how helpful those README
> > > files are for the users of your package.  If you go this route, you
> > > should add +dfsg to the version of your package to indicate that the
> > > upstream tarball has been repackaged to remove files that are not free
> > > (or for which the source is not available).
> > >
> > >
> > >
> > >
> > > Soren
> > >
> > >
> >
> > --
> > Shriram Ravindranathan
> > ters
> >
>
>
> --
> Soren Stoutner
> so...@debian.org

Bug#1064412: debian-edu-doc: Link errors in Bookworm doc

[Rafael Fontenelle]

Source: debian-edu-doc
Severity: normal

Dear Maintainer,

When building translated docs (although it's not a translation-specific issue), 
I noticed the following error output:

Error: no ID for constraint linkend: "DebianEdu".
Error: no ID for constraint linkend: 
"Installation--Installing_a_gateway_using_debian-edu-router".
Error: no ID for constraint linkend: 
"Administration--ldap-createuser-krb5.2C_a_command-line_tool_for_adding_users".

These errors did not prevented the docs from being built, but the links lead to 
the doc home instead of a specific section in the docs (undesired behavior, I 
suppose).

The above messages are related to these two paragraphs from the 
'debian-edu-bookworm-manual.xml' file:

In case you do not already have a router or your existing router cannot be set 
up accordingly, any machine which fulfills the requirements for a minimal 
Debian installation and which has at least two network interfaces can be turned 
into a gateway between the existing network and the DebianEdu one. See installation
 documentation for a simple way to install and set up a Debian machine 
using debian-edu-router-config.

User accounts can also be added from the command line using the 
ldap-createuser-krb5 tool, see the 
documentation in the Administration
 HowTo

Best regards,
Rafael

-- System Information:
Debian Release: 11.7
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 
'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.7.5-arch1-1 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Bug#1058890: test

[Dr . André Desgualdo Pereira]

I compiled the kernel 6.1.76 from Debian sources without applying any patch and 
it can't wake up from suspend :-( May be there is an specific driver or module 
that needs to be compiled for sedutil to work properly on waking up from S3.

Bug#1064411: node-neo-async: missing many files compared to npm dist tarball

[Praveen Arimbrathodiyil]

Package: node-neo-async
Version: 2.6.2+~cs3.0.0-2
Severity: important

When trying to use node-neo-async for gitlab (with in progress 
yarn-plugin-apt), webpack command fails with


ERROR in ./pages/admin/jobs/index/index.js
Module build failed (from 
/var/lib/gitlab/node_modules/thread-loader/dist/cjs.js):

Error: Cannot find module 'neo-async/queue'

and looks like this file is indeed missing from the package

pravi@mahishi:/tmp$ apt-file list node-neo-async
node-neo-async: /usr/share/doc/node-neo-async/README.md.gz
node-neo-async: /usr/share/doc/node-neo-async/changelog.Debian.gz
node-neo-async: /usr/share/doc/node-neo-async/copyright
node-neo-async: /usr/share/lintian/overrides/node-neo-async
node-neo-async: /usr/share/nodejs/asyncro/dist/asyncro.js
node-neo-async: /usr/share/nodejs/asyncro/package.json
node-neo-async: /usr/share/nodejs/asyncro/src/index.js
node-neo-async: /usr/share/nodejs/asyncro/src/util.js
node-neo-async: /usr/share/nodejs/neo-async/dist/async.js
node-neo-async: /usr/share/nodejs/neo-async/dist/async.min.js
node-neo-async: /usr/share/nodejs/neo-async/lib/async.js
node-neo-async: /usr/share/nodejs/neo-async/lib/async.min.js
node-neo-async: /usr/share/nodejs/neo-async/package.json

and full list of files shipped in npm dist tarball is

(debian-sid)pravi@mahishi:/tmp$ tar -zxvf neo-async-2.6.2.tgz
package/LICENSE
package/all.js
package/allLimit.js
package/allSeries.js
package/angelFall.js
package/any.js
package/anyLimit.js
package/anySeries.js
package/apply.js
package/applyEach.js
package/applyEachSeries.js
package/async.js
package/async.min.js
package/asyncify.js
package/auto.js
package/autoInject.js
package/cargo.js
package/compose.js
package/concat.js
package/concatLimit.js
package/concatSeries.js
package/constant.js
package/createLogger.js
package/detect.js
package/detectLimit.js
package/detectSeries.js
package/dir.js
package/doDuring.js
package/doUntil.js
package/doWhilst.js
package/during.js
package/each.js
package/eachLimit.js
package/eachOf.js
package/eachOfLimit.js
package/eachOfSeries.js
package/eachSeries.js
package/ensureAsync.js
package/every.js
package/everyLimit.js
package/everySeries.js
package/fast.js
package/filter.js
package/filterLimit.js
package/filterSeries.js
package/find.js
package/findLimit.js
package/findSeries.js
package/foldl.js
package/foldr.js
package/forEach.js
package/forEachLimit.js
package/forEachOf.js
package/forEachOfLimit.js
package/forEachOfSeries.js
package/forEachSeries.js
package/forever.js
package/groupBy.js
package/groupByLimit.js
package/groupBySeries.js
package/inject.js
package/iterator.js
package/log.js
package/map.js
package/mapLimit.js
package/mapSeries.js
package/mapValues.js
package/mapValuesLimit.js
package/mapValuesSeries.js
package/memoize.js
package/nextTick.js
package/omit.js
package/omitLimit.js
package/omitSeries.js
package/parallel.js
package/parallelLimit.js
package/pick.js
package/pickLimit.js
package/pickSeries.js
package/priorityQueue.js
package/queue.js
package/race.js
package/reduce.js
package/reduceRight.js
package/reflect.js
package/reflectAll.js
package/reject.js
package/rejectLimit.js
package/rejectSeries.js
package/retry.js
package/retryable.js
package/safe.js
package/select.js
package/selectLimit.js
package/selectSeries.js
package/seq.js
package/series.js
package/setImmediate.js
package/some.js
package/someLimit.js
package/someSeries.js
package/sortBy.js
package/sortByLimit.js
package/sortBySeries.js
package/timeout.js
package/times.js
package/timesLimit.js
package/timesSeries.js
package/transform.js
package/transformLimit.js
package/transformSeries.js
package/tryEach.js
package/unmemoize.js
package/until.js
package/waterfall.js
package/whilst.js
package/wrapSync.js
package/package.json
package/README.md


OpenPGP_0x8F53E0193B294B75.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1064410: cpdb-backend-file build depends on cruft libcpdb-libs-backend-dev

[Adrian Bunk]

Source: cpdb-backend-file
Version: 1.0.1-1
Severity: serious
Tags: ftbfs trixie sid

libcpdb-libs-backend-dev is no longer built by src:cpdb-libs

Bug#1064409: cpdb-backend-cups build depends on cruft libcpdb-libs-backend-dev

[Adrian Bunk]

Source: cpdb-backend-cups
Version: 1.1.1-1
Severity: serious
Tags: ftbfs trixie sid

libcpdb-libs-backend-dev is no longer built by src:cpdb-libs

Bug#1064408: [PATCH] duplicate aliased diversions for DEP17

[Helmut Grohne]

Package: live-build
Versrion: 1:20230502
User: helm...@debian.org
Usertags: dep17p3
Tags: patch

/bin/hostname and /sbin/start-stop-daemon are being moved from / to /usr
in trixie. Hence, these diversions become ineffective. Temporarily add
both diversions to handle both variants.
---
 scripts/build/chroot_dpkg | 15 ---
 scripts/build/chroot_hostname | 17 +
 2 files changed, 25 insertions(+), 7 deletions(-)

I note that while live-build has MRs on salsa, I cannot seem to create
one. Hence sending a patch via bugs.d.o.

diff --git a/scripts/build/chroot_dpkg b/scripts/build/chroot_dpkg
index c43c0eb01..d64820f72 100755
--- a/scripts/build/chroot_dpkg
+++ b/scripts/build/chroot_dpkg
@@ -38,8 +38,14 @@ case "${_ACTION}" in
Acquire_lockfile
 
# Create custom start-stop-daemon program
-   Chroot chroot dpkg-divert --rename --quiet --add 
/sbin/start-stop-daemon
-   ln -fs /bin/true chroot/sbin/start-stop-daemon
+   Chroot chroot dpkg-divert --rename --quiet --add 
/usr/sbin/start-stop-daemon
+   # begin-remove-after: released:trixie
+   # In the bookworm to trixie upgrade, dpkg moves
+   # start-stop-daemon from /sbin to /usr/sbin. Duplicate the
+   # diversion to cover both. DEP17 P3 M18
+   Chroot chroot dpkg-divert --rename --quiet --add --divert 
/sbin/start-stop-daemon.distrib.usr-is-merged
+   # end-remove-after
+   ln -fs /bin/true chroot/usr/sbin/start-stop-daemon
 
# Disable dpkg syncing
 
@@ -79,8 +85,11 @@ EOF
Chroot chroot dpkg-divert --rename --quiet --remove 
/usr/sbin/flash-kernel
 
# Remove custom start-stop-daemon program
-   rm -f chroot/sbin/start-stop-daemon
+   rm -f chroot/usr/sbin/start-stop-daemon
+   # begin-remove-after: released:trixie
Chroot chroot dpkg-divert --rename --quiet --remove 
/sbin/start-stop-daemon
+   # end-remove-after
+   Chroot chroot dpkg-divert --rename --quiet --remove 
/usr/sbin/start-stop-daemon
 
# Remove dpkg sync configuration
rm -f chroot/etc/dpkg/dpkg.cfg.d/live-build
diff --git a/scripts/build/chroot_hostname b/scripts/build/chroot_hostname
index 836ce09bb..befe58f43 100755
--- a/scripts/build/chroot_hostname
+++ b/scripts/build/chroot_hostname
@@ -43,15 +43,21 @@ case "${_ACTION}" in
# Create custom hostname
Echo_message "Configuring file /bin/hostname"
 
-   Chroot chroot dpkg-divert --rename --quiet --add /bin/hostname
-
-cat > chroot/bin/hostname << EOF
+   Chroot chroot dpkg-divert --rename --quiet --add 
/usr/bin/hostname
+   # begin-remove-after: released:trixie
+   # In the bookworm to trixie upgrade, hostname moves hostname
+   # from /bin to /usr/bin. Duplicate the diversion to cover both.
+   # DEP17 P3 M18
+   Chroot chroot dpkg-divert --rename --quiet --add --divert 
/bin/hostname.distrib.usr-is-merged /bin/hostname
+   # end-remove-after
+
+cat > chroot/usr/bin/hostname << EOF
 #!/bin/sh
 
 echo "localhost.localdomain"
 EOF
 
-   chmod 755 chroot/bin/hostname
+   chmod 755 chroot/usr/bin/hostname
 
# Creating stage file
Create_stagefile
@@ -84,7 +90,10 @@ EOF
 
# Remove custom hostname
rm -f chroot/bin/hostname
+   # begin-remove-after: released:trixie
Chroot chroot dpkg-divert --rename --quiet --remove 
/bin/hostname
+   # end-remove-after
+   Chroot chroot dpkg-divert --rename --quiet --remove 
/usr/bin/hostname
 
# Removing stage file
Remove_stagefile
-- 
2.39.2

Bug#1061967: RM: python-watchgod -- ROM; Replaced by python-watchfiles

[Michael Fladischer]

Hi Paul,

Am 18.02.2024 um 14:45 schrieb Paul Gevers:

src:python-watchgod has been superseded by src: python-watchfiles.


And should reverse (build) dependencies pick this up automatically? If 
so, a Provides (or transitional package) might be appropriate. If not, 
please file bugs against the reverse (build) dependencies, mark these 
bugs as blocking this bug and help the maintainers transition. This 
package can't be removed until reverse (build) dependencies are fixed or 
removed, but there are key packages among them so removal is not an 
option in all cases.


the only reverse-build-dep that I could find was src:python-uvicorn and 
I have uploaded 0.27.1-1 which replaces python3-watchgod with 
python3-watchfiles (uvicorn actually still supports both as a reloader).


Regards,
Michael

Bug#1064381: ITP: elfkickers -- collection of programs that access and manipulate ELF files

[David Bremner]

Gürkan Myczko  writes:

> On 21.02.2024 12:28, David Bremner wrote:

> Being the universal operating system, these tools are certainly not for 
> normal users
> but more like developers and people in the embedded area.
>

I include developers in people who don't care about the implementation,

> I have found sstrip to squeeze away some more kilobytes from binaries.

A list of the tools with what they do would be more useful.

> Similar like elfutils it will only be interesting to people that want to 
> use it.

Sure, I'm not talking about making it interesting for every user, just
having a description that helps someone in the target audience find the
package and/or know if they want to install it.

Bug#1064397: ITP: client-desktop-shell-integration-nautilus -- Nautilus, Nemo and Caja integration of the owncloud-client

[Simon Josefsson]

Pierre-Elliott Bécue  writes:

> Package: wnpp
> Severity: wishlist
> Owner: Pierre-Elliott Bécue 
> X-Debbugs-Cc: debian-de...@lists.debian.org
>
> * Package name: client-desktop-shell-integration-nautilus
>   Version : 5.0.0
>   Upstream Contact: Frank Müller 
> * URL : 
> https://github.com/owncloud/client-desktop-shell-integration-nautilus
> * License : GPL-2
>   Programming Lang: Python, Shell, ...
>   Description : Nautilus, Nemo and Caja integration for ownCloud Client.
>
> These three extensions were originally integrated in the owncloud-client
> source package. Upstream decided to extract them to create a new repo.
>
> The package will be maintained in the owncloud-team.

Hi - how about including 'owncloud' in the package name?
'owncloud-client-desktop-shell-integration-nautilus'?  Or
'owncloud-nautilus-integration'?

/Simon


signature.asc
Description: PGP signature

Bug#1064404: snapd: please make the build reproducible.

[Zygmunt Krynicki]

> Wiadomość napisana przez James Addison  w dniu 
> 21.02.2024, o godz. 15:49:
> 
> Source: snapd
> Version: 2.61.1-1
> Severity: wishlist
> 
> Dear Maintainer,
> 
> I'm an occasional volunteer with the Reproducible Builds[1] project, and
> recently noticed that the snapd package failed automated reproducible build
> testing[2] on Debian.
> 
> One cause of non-reproducibility for the package appears to be that the
> snap.8 manual page (compressed as snap.8.gz) contains a timestamp in the
> header that becomes timezone-localized, meaning that the Debian binary 
> packages
> built may vary based on the timezone they're built in.
> 
> Although one way to fix this could be to request and display a UTC timestamp,
> there's a comment[3] in the debian/rules file that hints at a better solution:
> from version 1.4.0-2 of golang-go-flags there is in-built support[4] for the
> SOURCE_DATE_EPOCH variable, a time-in-seconds since the Unix epoch 
> (interpreted
> in UTC[5]).
> 
> That means that it should be possible to generate reproducible manual pages
> directly by calling the compiled snap binary with the 'help --man' commandline
> arguments, omitting the sed expression as suggested by the comment.
> 
> I'll offer a merge request on Salsa to provide that change soon.


Thank you for bringing this to my attention and for offering a patch. I was 
aware of numerous TODOs in the packaging but have not yet managed to come up 
with a solution that would work both upstream and downstream (snapd CI system 
uses a copy of the debian packaging to check that a package can indeed be 
built), so any iteration on this is rather tedious.

In any case that should not be a problem that cannot be solved. I'm looking 
forward to your pull request or patches.

Best regards
ZK

Bug#1064407: Please add a symbols file

[Raul Tambre]

Source: libgstreamer-plugins-bad1.0-0
Version: 1.22.10-1
Severity: wishlist

Any packages using libgstreamer-plugins-bad1.0-0 end up with a >= 
dependency on the version they are built with. This makes upgrades and 
recovering broken installations harder that necessary due to the 
unnecessarily high version dependency.


Please add a symbols to help with this.
I've attached the one from my downstream, though I build a rather 
limited set of functionality.


And for a little further background... I package GStreamer, including 
the bad plugins, myself for a downstream Debian variant. 
libwebkit2gtk-4.1-0 after upstream rebuilds ends up depending on the 
latest libgstreamer-plugins-bad1.0-0. Our downstream packages override 
any from the Debian upstrean. If the repository is updated in such a 
state `apt dist-upgrade` ends up removing users' Gnome due to an 
unsatisfied dependency on libgstreamer-plugins-bad1.0-0.
The fix has been to be more on top with GStreamer upgrades and improve 
testing, but having a symbols file in Debian seems like a good idea anyway.libgstadaptivedemux-1.0.so.0 libgstreamer-plugins-bad1.0-0 #MINVER#
* Build-Depends-Package: libgstreamer-plugins-bad1.0-dev
 gst_adaptive_demux_find_stream_for_pad@Base 1.22
 gst_adaptive_demux_get_client_now_utc@Base 1.22
 gst_adaptive_demux_get_monotonic_time@Base 1.22
 gst_adaptive_demux_get_qos_earliest_time@Base 1.22
 gst_adaptive_demux_get_type@Base 1.22
 gst_adaptive_demux_is_running@Base 1.22
 gst_adaptive_demux_set_stream_struct_size@Base 1.22
 gst_adaptive_demux_stream_advance_fragment@Base 1.22
 gst_adaptive_demux_stream_fragment_clear@Base 1.22
 gst_adaptive_demux_stream_new@Base 1.22
 gst_adaptive_demux_stream_push_buffer@Base 1.22
 gst_adaptive_demux_stream_queue_event@Base 1.22
 gst_adaptive_demux_stream_set_caps@Base 1.22
 gst_adaptive_demux_stream_set_tags@Base 1.22
libgstbadaudio-1.0.so.0 libgstreamer-plugins-bad1.0-0 #MINVER#
* Build-Depends-Package: libgstreamer-plugins-bad1.0-dev
 gst_nonstream_audio_decoder_allocate_output_buffer@Base 1.22
 gst_nonstream_audio_decoder_get_downstream_info@Base 1.22
 gst_nonstream_audio_decoder_get_type@Base 1.22
 gst_nonstream_audio_decoder_handle_loop@Base 1.22
 gst_nonstream_audio_decoder_set_output_format@Base 1.22
 gst_nonstream_audio_decoder_set_output_format_simple@Base 1.22
 gst_planar_audio_adapter_available@Base 1.22
 gst_planar_audio_adapter_clear@Base 1.22
 gst_planar_audio_adapter_configure@Base 1.22
 gst_planar_audio_adapter_distance_from_discont@Base 1.22
 gst_planar_audio_adapter_dts_at_discont@Base 1.22
 gst_planar_audio_adapter_flush@Base 1.22
 gst_planar_audio_adapter_get_buffer@Base 1.22
 gst_planar_audio_adapter_get_type@Base 1.22
 gst_planar_audio_adapter_new@Base 1.22
 gst_planar_audio_adapter_offset_at_discont@Base 1.22
 gst_planar_audio_adapter_prev_dts@Base 1.22
 gst_planar_audio_adapter_prev_offset@Base 1.22
 gst_planar_audio_adapter_prev_pts@Base 1.22
 gst_planar_audio_adapter_pts_at_discont@Base 1.22
 gst_planar_audio_adapter_push@Base 1.22
 gst_planar_audio_adapter_take_buffer@Base 1.22
libgstbasecamerabinsrc-1.0.so.0 libgstreamer-plugins-bad1.0-0 #MINVER#
* Build-Depends-Package: libgstreamer-plugins-bad1.0-dev
 gst_base_camera_src_finish_capture@Base 1.22
 gst_base_camera_src_get_type@Base 1.22
 gst_base_camera_src_post_preview@Base 1.22
 gst_base_camera_src_set_mode@Base 1.22
 gst_base_camera_src_setup_preview@Base 1.22
 gst_base_camera_src_setup_zoom@Base 1.22
 gst_camerabin_create_preview_pipeline@Base 1.22
 gst_camerabin_destroy_preview_pipeline@Base 1.22
 gst_camerabin_mode_get_type@Base 1.22
 gst_camerabin_preview_pipeline_post@Base 1.22
 gst_camerabin_preview_set_caps@Base 1.22
 gst_camerabin_preview_set_filter@Base 1.22
libgstcodecparsers-1.0.so.0 libgstreamer-plugins-bad1.0-0 #MINVER#
* Build-Depends-Package: libgstreamer-plugins-bad1.0-dev
 gst_av1_parser_free@Base 1.22
 gst_av1_parser_identify_one_obu@Base 1.22
 gst_av1_parser_new@Base 1.22
 gst_av1_parser_parse_frame_header_obu@Base 1.22
 gst_av1_parser_parse_frame_obu@Base 1.22
 gst_av1_parser_parse_metadata_obu@Base 1.22
 gst_av1_parser_parse_sequence_header_obu@Base 1.22
 gst_av1_parser_parse_temporal_delimiter_obu@Base 1.22
 gst_av1_parser_parse_tile_group_obu@Base 1.22
 gst_av1_parser_parse_tile_list_obu@Base 1.22
 gst_av1_parser_reference_frame_update@Base 1.22
 gst_av1_parser_reset@Base 1.22
 gst_av1_parser_reset_annex_b@Base 1.22
 gst_av1_parser_set_operating_point@Base 1.22
 gst_buffer_add_mpeg_video_meta@Base 1.22
 gst_h263_parse@Base 1.22
 gst_h264_bit_writer_aud@Base 1.22
 gst_h264_bit_writer_convert_to_nal@Base 1.22
 gst_h264_bit_writer_pps@Base 1.22
 gst_h264_bit_writer_sei@Base 1.22
 gst_h264_bit_writer_slice_hdr@Base 1.22
 gst_h264_bit_writer_sps@Base 1.22
 gst_h264_create_sei_memory@Base 1.22
 gst_h264_create_sei_memory_avc@Base 1.22
 gst_h264_decoder_config_record_free@Base 1.22
 gst_h264_nal_parser_free@Base 1.22
 gst_h264_nal_parser_new@Base 1.22
 gst_h264_parse_pps@Base 1.22
 

Bug#1063274: pydevd: autopkgtest-failing warning with pandas 2.1

[Julian Gilbey]

On Tue, Feb 20, 2024 at 09:46:16PM +, Rebecca N. Palmer wrote:
> Is that a yes to>> Does just the patch (not the new upstream) also break
> debugpy?or have you not tried specifically that?
> 
> (I'm looking for a quick fix for the autopkgtest fail to unblock the pandas
> 2.x transition.  I agree that upgrading to a new upstream is a good idea in
> the long run.)

Fair point; I've just uploaded 2.10.0+ds-9.

Best wishes,

   Julian

Bug#1064346: Source is missing errors on HTML source files

[Soren Stoutner]

Shriram,

On Wednesday, February 21, 2024 8:30:54 AM MST Shriram Ravindranathan wrote:
> Upon inspecting the embedded font, It seems to be a bespoke icon-font 
> generated using a tool called "Fontello" from one of the icons of the 
> octicons iconset from Atom  (MIT 
> Licensed SVGs)
> 
> The font has only 1 glyph, Would it suffice to add this source image to 
> d/missing-souces and add that copyright info to d/copyright?

I would assume so.  If anyone on mentors knows differently please speak up.

> On 21/02/24 9:56 am, Soren Stoutner wrote:
> 
> >
> >
> > Shriram,
> >
> >
> >
> >
> > 1. For anything that has the unminified source in the upstream 
> > tarball, I would just create a lintian override with a comment listing 
> > the full path to the source for each file.  You can see an example of 
> > how this can be done here:
> >
> >
> >
> >
> > https://salsa.debian.org/qt-kde-team/qt/qtwebengine/-/blob/master/debian/
sou
> > rce/lintian-overrides?ref_type=heads
>
> >
> >
> >
> > Typically you only copy the source to the debian/missing-sources 
> > directory when it is not included in the upstream tarball and you have 
> > had to acquire it from another place.
> >
> >
> >
> >
> > 2. The github link below includes an embedded font in woff format. 
> > Typically, fonts like this would be considered compiled, so a separate 
> > font source would be needed.  However, I’m not sure what the Debian 
> > guidance for dealing with an HTML embedded font like this.  If someone 
> > else on mentors doesn’t know, I would recommend you ask on debian-legal.
> >
> >
> >
> >
> > As these are mostly README files, and if it becomes difficult for you 
> > to acquire the source for some of them, you might consider excluding 
> > those you can’t get the source for, at least temporarily, using 
> > Files-Excluded in debian/copyright (and then running uscan, which will 
> > produce a modified tarball that does not include the problematic 
> > files).  For example, see:
> >
> >
> >
> >
> > https://salsa.debian.org/cryptocoin-team/electrum/-/blob/master/debian/
copyr
> > ight?ref_type=heads
>
> >
> >
> >
> > Whether this is a good option depends on how helpful those README 
> > files are for the users of your package.  If you go this route, you 
> > should add +dfsg to the version of your package to indicate that the 
> > upstream tarball has been repackaged to remove files that are not free 
> > (or for which the source is not available).
> >
> >
> >
> >
> > Soren
> >
> >
> 
> -- 
> Shriram Ravindranathan
> ters
> 


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

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

Bug#1064346: Source is missing errors on HTML source files

[Shriram Ravindranathan]

Upon inspecting the embedded font, It seems to be a bespoke icon-font 
generated using a tool called "Fontello" from one of the icons of the 
octicons iconset from Atom  (MIT 
Licensed SVGs)


The font has only 1 glyph, Would it suffice to add this source image to 
d/missing-souces and add that copyright info to d/copyright?


On 21/02/24 9:56 am, Soren Stoutner wrote:


Shriram,


1. For anything that has the unminified source in the upstream 
tarball, I would just create a lintian override with a comment listing 
the full path to the source for each file.  You can see an example of 
how this can be done here:



https://salsa.debian.org/qt-kde-team/qt/qtwebengine/-/blob/master/debian/source/lintian-overrides?ref_type=heads


Typically you only copy the source to the debian/missing-sources 
directory when it is not included in the upstream tarball and you have 
had to acquire it from another place.



2. The github link below includes an embedded font in woff format. 
Typically, fonts like this would be considered compiled, so a separate 
font source would be needed.  However, I’m not sure what the Debian 
guidance for dealing with an HTML embedded font like this.  If someone 
else on mentors doesn’t know, I would recommend you ask on debian-legal.



As these are mostly README files, and if it becomes difficult for you 
to acquire the source for some of them, you might consider excluding 
those you can’t get the source for, at least temporarily, using 
Files-Excluded in debian/copyright (and then running uscan, which will 
produce a modified tarball that does not include the problematic 
files).  For example, see:



https://salsa.debian.org/cryptocoin-team/electrum/-/blob/master/debian/copyright?ref_type=heads


Whether this is a good option depends on how helpful those README 
files are for the users of your package.  If you go this route, you 
should add +dfsg to the version of your package to indicate that the 
upstream tarball has been repackaged to remove files that are not free 
(or for which the source is not available).



Soren


--
Shriram Ravindranathan
ters



OpenPGP_0xFC7E951A7BEF0836.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060016: packagekit: CVE-2024-0217

[Moritz Muehlenhoff]

On Wed, Feb 21, 2024 at 04:15:17PM +0100, Matthias Klumpp wrote:
> I'd read the "unaffected at 1.2.7" as version 1.2.7 and higher not
> having the bug... But then again, on another page it said that the
> respective patch only lowered the impact...
> I remember merging that patch, and it was a pretty good robustness
> improvement, we didn't talk about any use-after-free issue there
> though (so it's not obvious why this changes anything either).
> 
> Let's see if we get a reply from the CVE reporter!

Sounds good. If there's no further information provided I'll mark the
entry as non actionable in the Debian security tracker and deassociate
it from https://security-tracker.debian.org/tracker/source-package/packagekit

Cheers,
Moritz

Bug#1064406: RFS: ifstat/1.1.1-2 -- InterFace STATistics Monitoring

[Peter Blackman]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "ifstat":

 * Package name : ifstat
   Version  : 1.1.1-2
   Upstream contact : Matthieu Baerts 
 * URL  : http://gael.roualland.free.fr/ifstat/
 * License  : FSFUL, GPL-2+, HPND-sell-variant
 * Vcs  : https://salsa.debian.org/debian/ifstat
   Section  : net

The source builds the following binary packages:

  ifstat - InterFace STATistics Monitoring
  libifstat-dev - Ifstat Development Files

To access further information about this package, please visit the 
following URL:


  https://mentors.debian.net/package/ifstat/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/i/ifstat/ifstat_1.1.1-2.dsc


Changes since the last upload:

 ifstat (1.1.1-2) unstable; urgency=medium
 .
   * Update patch headers, remove unneeded patch file
   * d/copyright fixes

Regards,
--
  Peter Blackman

Bug#1064402: luametatex: "mtxrun --generate": lua error : startup file: /bin/mtxrun.lua:2438: attempt to assign to const variable 'i'

[Vincent Lefevre]

Control: retitle -1 luametatex: "mtxrun --generate": lua error : startup file: 
/bin/mtxrun.lua:2438: attempt to assign to const variable 'i'

More accurate title, as described below.

On 2024-02-21 16:15:31 +0100, Vincent Lefevre wrote:
> Indeed, I can reproduce the problem on another machine, only with
> luametatex 2.11.01+ds-2:
> 
> qaa:~> mtxrun --generate
> lua error : startup file: /bin/mtxrun.lua:2438: attempt to assign to const 
> variable 'i'
> 
> You'll see the failure in an upgrade if you upgrade luametatex at the
> same time as the TeX Live packages (at least, *not after* TeX Live).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1064402: texlive-binaries: tex-common configure: lua error : startup file: /bin/mtxrun.lua:2438: attempt to assign to const variable 'i'

[Vincent Lefevre]

Control: reassign -1 luametatex 2.11.01+ds-2
Control: severity -1 grave
Control: affects -1 texlive-binaries

On 2024-02-21 15:46:04 +0100, Vincent Lefevre wrote:
> On 2024-02-21 15:28:17 +0100, Vincent Lefevre wrote:
> > /tmp/mtxrun.gd7J0NKo just contains:
> > 
> > lua error : startup file: /bin/mtxrun.lua:2438: attempt to assign to const 
> > variable 'i'
> > 
> > Note: the tex-common and context (from which /bin/mtxrun.lua comes
> > from) are still old packages, and there were no issues with them
> > in the past. So I assume that the bug has been introduced in
> > /usr/bin/texlua (/bin/mtxrun.lua is a texlua script), which is
> > provided by texlive-binaries.
> 
> Or it could be due to luametatex, which appears in /bin/mtxrun.lua
> and has been upgraded:
> 
> 2024-02-21 14:47:52 upgrade luametatex:amd64 2.10.08+ds-1+b1 2.11.01+ds-2

Indeed, I can reproduce the problem on another machine, only with
luametatex 2.11.01+ds-2:

qaa:~> mtxrun --generate
lua error : startup file: /bin/mtxrun.lua:2438: attempt to assign to const 
variable 'i'

You'll see the failure in an upgrade if you upgrade luametatex at the
same time as the TeX Live packages (at least, *not after* TeX Live).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1060016: packagekit: CVE-2024-0217

[Matthias Klumpp]

Am Mi., 21. Feb. 2024 um 16:05 Uhr schrieb Moritz Muehlenhoff :
>
> On Tue, Feb 20, 2024 at 10:11:35PM +0100, Matthias Klumpp wrote:
> > The CVE page lists that commit as "patch" now, and given that emitting
> > a finished transaction as finished multiple times could indeed cause
> > issues (and use-after-free issues potentially as well), I am inclined
> > to think that that's indeed the issue here and that the patch fixes
> > it.
>
> Ok.
>
> > That would mean though that all PK versions starting from and
> > including 1.2.7 are not vulnerable... But the CVE tells otherwise.
> > Very odd.
>
> But https://www.cve.org/CVERecord?id=CVE-2024-0217 only states
> "unaffected at 1.2.7", which seems to be based on the git tag of
> the referenced commit?

We are all confused. Neal and I asked on the RHEL bug report again:
https://bugzilla.redhat.com/show_bug.cgi?id=2256624#c6
We really need more information here.

I'd read the "unaffected at 1.2.7" as version 1.2.7 and higher not
having the bug... But then again, on another page it said that the
respective patch only lowered the impact...
I remember merging that patch, and it was a pretty good robustness
improvement, we didn't talk about any use-after-free issue there
though (so it's not obvious why this changes anything either).

Let's see if we get a reply from the CVE reporter!
Best,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#1064405: yq: Please provide a manpage

[Andrej Shadura]

Package: yq
Version: 3.1.0-3
Severity: normal

Hi,

The package currently doesn’t ship any manpage, making it less
convenient to discover the command-line options.

Please provide a manpage containing at least the information
from /usr/share/doc/yq/cli-doc.txt.

Thanks.

-- 
Cheers,
  Andrej

Bug#1060016: packagekit: CVE-2024-0217

[Moritz Muehlenhoff]

On Tue, Feb 20, 2024 at 10:11:35PM +0100, Matthias Klumpp wrote:
> The CVE page lists that commit as "patch" now, and given that emitting
> a finished transaction as finished multiple times could indeed cause
> issues (and use-after-free issues potentially as well), I am inclined
> to think that that's indeed the issue here and that the patch fixes
> it.

Ok.

> That would mean though that all PK versions starting from and
> including 1.2.7 are not vulnerable... But the CVE tells otherwise.
> Very odd.

But https://www.cve.org/CVERecord?id=CVE-2024-0217 only states
"unaffected at 1.2.7", which seems to be based on the git tag of
the referenced commit?

Cheers,
Moritz

Bug#1064404: snapd: please make the build reproducible.

[James Addison]

Followup-For: Bug #1064404
Control: forwarded -1 https://salsa.debian.org/debian/snapd/-/merge_requests/7
Control: tags -1 patch
Control: submitter -1 reproducible-bui...@lists.alioth.debian.org
Control: user reproducible-bui...@lists.alioth.debian.org
Control: usertag -1 timezone

Bug#1064394: release-notes: English language output for the commands into script session

[Justin B Rye]

Franco wrote:
> Dear Debian Documentation Project staff,
> 
> I want to suggest to add a sentence like the following to the §4.4.1
> "Recording the session" paragraph. ¹  Below the "script" command:
> 
> --- BEGIN of the statement ---

I like this idea; but it might work better if we turn things around
and start with the possible problem before offering the solution.

> " If you are comfortable with English language it's strongly
> recommended that you run the following command as soon as you start
> the 'script' session:
>   # LC_ALL=C.UTF-8; LANGUAGE=; export LC_ALL LANGUAGE
> 
>   This will allow you to get command output messages in English into
>   the script session. By doing so, it will help you for searching the
>   web, during discussions or to submit a bug report."
> --- END of the statement ---

A rephrased version:

If you use a non-English locale during the upgrade, any progress
or error messages are likely to be translated, so in the event of
problems it may be difficult to get assistance from the Internet,
or to submit a bug report. If you are comfortable using English
then it is strongly recommended that you run the following command
at the start of your 'script' session:

# LC_ALL=C.UTF-8; LANGUAGE=; export LC_ALL LANGUAGE

This will give you command output in English.

(Or do we also need to warn users to say "yes" and not "si"?)

> This change it has been discussed on debian-user mailing-list here. ²
> The syntax of the command was designed to be portable to all shells,
> csh included.

I'm sorry, but if you're doing vital root-privileged sysadmin tasks
under csh, things have already gone badly wrong; the instructions in
the Release Notes all assume a Bourne-family shell.  For instance, the
immediately preceding line invoking screen with a 2>~/foo redirection*
won't work on csh (tested with bookworm's tcsh).

So I'm not sure there's any point using anything longer than:

   # export LC_ALL=C.UTF-8 LANGUAGE=

(But doing it separately from starting "script" does make sense, if
only to give us room for an explanation.)
 
> ¹ 
> https://www.debian.org/releases/testing/release-notes/upgrading.en.html#recording-the-session
> ² https://lists.debian.org/debian-user/2024/02/msg00562.html

I don't think the Release Notes ever mention the fact that we assume
a Bourne shell, but if you boot into an initrd rescue shell expecting
it to be csh then your day hasn't finished getting worse.

[--just as I was about to hit SEND:--]

> Could I suggest that the syntax of "script" command in the "4.4.1.
> Recording the session" section it should be:
>
> # script -T ~/upgrade-trixie-step.time -a ~/upgrade-trixie-step.script

Ah, yes, avoiding the tricky redirection syntax (worthwhile even if
we don't care about csh).  But if we're assuming this is already a
root session, "~/foo" will  put that log in /root/; maybe we should
say that instead of using tilde-expansion?
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#1055728: Segyio is lagging behind upstream (Was: segyio ftbfs with Python 3.12)

[Andreas Tille]

Hi Tino,

thanks for the hint which reduced the number of test suite failures to
one as you can see in Salsa CI[1].  In case someone might find a
solution for this one we might upload - if not I wonder whether this
package is a candidate for removal.

Please note: I have no interest into this package at all - just hunting
for Python3.12 issues.

Kind regards
Andreas.


[1]https://salsa.debian.org/science-team/segyio/-/jobs/5338110

Am Wed, Feb 21, 2024 at 11:42:58AM +0100 schrieb Tino Didriksen:
> std::uint16_t is in #include 
> 
> stdint.h is the C header, which doesn't import the symbols to the std::
> namespace. In general, the headers Standard C++ imports from Standard C
> snips the .h and prefixes c, so stdint.h -> cstdint, stdio.h -> cstdio, etc.
> 
> -- Tino Didriksen
> 
> 
> On Wed, 21 Feb 2024 at 11:16, Andreas Tille  wrote:
> 
> > Hi,
> >
> > I've found in the set of patches for segyio other cherry-picked patches
> > to adapt to certain Python3.x versions[1].  The patch kindly suggested
> > by s3v to fix this bug[2] would simply be another cherry-pick from upstream
> > who has meanwhile released a couple of new versions incorporating all
> > patches we seem to need for Python3.12 - thus by upgrading to latest
> > upstream the current bug would be fixed.
> >
> > Usually I would do this in case of team maintained packages but I faced
> > some problems with latest upstream and thus I simply created a branch
> > version_1.9.12 with all proposed changes including current packaging
> > standards and fixing a further bug.  Unfortunately the build system is
> > all but smooth compared to other packages and I finally stumbled upon
> > a C++ conversion issue[4] which is not solved by simply adding
> >#include 
> > and my further attempt leads to a test suite issue which seems to
> > indicate that my poor C++ understanding is wrong.
> >
> > So I'm giving up here by leaving two questions:
> >
> >1. Anybody up for fixing this package and bringing it to latest
> >   upstream?
> >2. Alternatively do we want to drop this package from Debian?
> >
> > Kind regards
> > Andreas.
> >
> >
> > [1]
> > https://salsa.debian.org/science-team/segyio/-/tree/master/debian/patches?ref_type=heads
> > [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055728#14
> > [3]
> > https://salsa.debian.org/science-team/segyio/-/tree/version_1.9.12?ref_type=heads
> > [4]
> > https://salsa.debian.org/science-team/segyio/-/blob/version_1.9.12/debian/patches/gcc-13.patch?ref_type=heads#L6-9
> >
> > --
> > http://fam-tille.de
> >
> >

-- 
http://fam-tille.de

Bug#1064402: texlive-binaries: tex-common configure: lua error : startup file: /bin/mtxrun.lua:2438: attempt to assign to const variable 'i'

[Vincent Lefevre]

On 2024-02-21 15:28:17 +0100, Vincent Lefevre wrote:
> /tmp/mtxrun.gd7J0NKo just contains:
> 
> lua error : startup file: /bin/mtxrun.lua:2438: attempt to assign to const 
> variable 'i'
> 
> Note: the tex-common and context (from which /bin/mtxrun.lua comes
> from) are still old packages, and there were no issues with them
> in the past. So I assume that the bug has been introduced in
> /usr/bin/texlua (/bin/mtxrun.lua is a texlua script), which is
> provided by texlive-binaries.

Or it could be due to luametatex, which appears in /bin/mtxrun.lua
and has been upgraded:

2024-02-21 14:47:52 upgrade luametatex:amd64 2.10.08+ds-1+b1 2.11.01+ds-2

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1059509: release-notes: script -t is deprecated, should we recommend --log-timing?

[Franco Martelli]

Could I suggest that the syntax of "script" command in the "4.4.1. 
Recording the session" section ¹  it should be:


  # script -T ~/upgrade-trixie-step.time -a ~/upgrade-trixie-step.script

¹ 
https://www.debian.org/releases/testing/release-notes/upgrading.en.html#recording-the-session

--
Franco Martelli

Bug#1064404: snapd: please make the build reproducible.

[James Addison]

Source: snapd
Version: 2.61.1-1
Severity: wishlist

Dear Maintainer,

I'm an occasional volunteer with the Reproducible Builds[1] project, and
recently noticed that the snapd package failed automated reproducible build
testing[2] on Debian.

One cause of non-reproducibility for the package appears to be that the
snap.8 manual page (compressed as snap.8.gz) contains a timestamp in the
header that becomes timezone-localized, meaning that the Debian binary packages
built may vary based on the timezone they're built in.

Although one way to fix this could be to request and display a UTC timestamp,
there's a comment[3] in the debian/rules file that hints at a better solution:
from version 1.4.0-2 of golang-go-flags there is in-built support[4] for the
SOURCE_DATE_EPOCH variable, a time-in-seconds since the Unix epoch (interpreted
in UTC[5]).

That means that it should be possible to generate reproducible manual pages
directly by calling the compiled snap binary with the 'help --man' commandline
arguments, omitting the sed expression as suggested by the comment.

I'll offer a merge request on Salsa to provide that change soon.

Regards,
James

[1] - https://reproducible-builds.org/

[2] - 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/snapd.html

[3] - https://sources.debian.org/src/snapd/2.61.1-1/debian/rules/#L281

[4] - https://sources.debian.org/src/golang-go-flags/1.4.0-2/man.go/#L180-L187

[5] - https://pkg.go.dev/time#Unix

Bug#1064403: python-cassandra-driver FTBFS on big endian

[Adrian Bunk]

Source: python-cassandra-driver
Version: 3.29.0-2
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=python-cassandra-driver=3.29.0-2

...
===
The optional C extensions are not supported on big-endian systems.
===
...
==
ERROR: Failure: DependencyException (The C extension needed to use libev was 
not found.  This probably means that you didn't have the required build 
dependencies when installing the driver.  See 
http://datastax.github.io/python-driver/installation.html#c-extensions for 
instructions on installing build dependencies and building the C extension.)
--
Traceback (most recent call last):
  File 
"/<>/.pybuild/cpython3_3.11_cassandra/build/cassandra/io/libevreactor.py",
 line 28, in 
import cassandra.io.libevwrapper as libev
ModuleNotFoundError: No module named 'cassandra.io.libevwrapper'
...
FAILED (SKIP=60, errors=1)
E: pybuild pybuild:391: test: plugin distutils failed with: exit code=1: cd 
/<>/.pybuild/cpython3_3.11_cassandra/build; python3.11 -m nose -v 
tests
dh_auto_test: error: pybuild --test -i python{version} -p "3.12 3.11" returned 
exit code 13
make[1]: *** [debian/rules:38: override_dh_auto_test] Error 25




The proper upstream fix would be to disable such a test when the C extensions
have been disabled.

A short-term workaround would be to ignore buildtime test failures on big 
endian:

--- debian/rules.old2024-02-21 14:38:24.180538878 +
+++ debian/rules2024-02-21 14:38:36.920528797 +
@@ -35,7 +35,11 @@
 ifeq ($(filter nocheck,$(DEB_BUILD_PROFILES)),)
rm tests/integration -rf
rm tests/stress_tests/test_multi_inserts.py 
tests/stress_tests/test_load.py tests/unit/io/test_eventletreactor.py 
tests/unit/cython/test_utils.py tests/unit/cython/test_bytesio.py
+ifeq ($(DEB_HOST_ARCH_ENDIAN),little)
dh_auto_test
+else
+   -dh_auto_test
+endif
 endif
 
 override_dh_auto_install:

Bug#1064373: [Debian-on-mobile-maintainers] Bug#1064373: squeekboard: Depends on obsolete rust-gtk

[Matthias Geiger]

On Wed, 21 Feb 2024 11:00:31 +0100 Guido =?iso-8859-1?Q?G=FCnther?= 
 wrote:
> Hi Jeremy,
> GTK4 lacks API to be make it usable as on screen keyboard (see
> https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/5628) so I assume
> this is unlikely to happen. It could switch to something like
> gtk4-layer-shell as work around though.
>
> (I'm not a squeekboard maintainer so this is just my PoV about the
> current state of affairs).
>
> Phosh has an alternative OSK (phosh-osk-stub) which would prevent
> removal of the whole stack from Debian when rust-gtk goes away.
>
> Cheers,
>  -- Guido
>
> On Tue, Feb 20, 2024 at 05:19:34PM -0500, Jeremy Bícha wrote:
> > Source: squeekboard
> > Version: 1.22.0-5
> > Severity: important
> > Tags: upstream trixie sid
> > Forwarded: https://gitlab.gnome.org/World/Phosh/squeekboard/-/issues/64
> >
> > rust-gtk (the old GTK3 bindings) are no longer maintained. Squeekboard
> > is the last thing keep rust-gtk in Debian. Please switch to rust-gtk4.
> >
> > Thank you,
> > Jeremy Bícha
> >
> > ___
> > Debian-on-mobile-maintainers mailing list
> > debian-on-mobile-maintain...@alioth-lists.debian.net
> > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-on-mobile-maintainers
>
>
Hi,
I think the best solution for now is to vendor the GTK3 crates for squeekboard 
and build "mixed", i.e. using debian crates plus the vendored GTK ones. This 
would allow removal of GTK3-rs in debian. Fwiw, the C gtk4-layershell packaging 
is already prepared (see #1054539).

I don't have the time to port squeekboard (or swayosd which will indirectly 
need GTK3-rs), but partially vendoring is a good solution imo.

best,

werdahias

Bug#1031557: uses a full CPU doing nothing in Wayland

[Antoine Beaupré]

Hello!

Nvidia is not involved here.

I must admit I haven't seen this bug in a while, maybe it was a one-off
thing?

Bug#1007286: lookup: please consider upgrading to 3.0 source format

[Bastian Germann]

I am uploading a NMU to DELAYED/10 in order to fix this.
Please find the debdiff attached.diff -Nru lookup-1.08b/Makefile lookup-1.08b/Makefile
--- lookup-1.08b/Makefile   2024-02-21 14:26:13.0 +
+++ lookup-1.08b/Makefile   1997-02-13 09:12:46.0 +
@@ -16,7 +16,7 @@
 CC_TRAD=$(CC) -traditional
 
 ## set to "gcc1", "gcc2" or leave blank
-gcc=gcc2
+gcc=gcc1
 
 ## selecte exactly "0" (no) or "1" (yes) for the following
 optimize=0
@@ -34,7 +34,7 @@
 ## it out if that's the case and you don't have a traditional compiler
 ## around.
 ##
-#COMPILE_WITH_TRAD=termset_trad.o
+COMPILE_WITH_TRAD=termset_trad.o
 
 RANLIB=/usr/bin/ranlib
 
@@ -154,22 +154,19 @@
echo '/* this file generated by Makefile */'  > tmp;
-echo '#ifndef __SYSTEM_H__ /*file wrapper*/'>> tmp;
-echo '#define __SYSTEM_H__' >> tmp;
-   if echo '#include ' | $(CC) -E - >/dev/null 2>&1; then\
+   if [ -f /usr/include/strings.h ]; then\
echo '#define _HAVE_STRINGS_H_'  >> tmp; \
else true; fi
-   if echo '#include ' | $(CC) -E - >/dev/null 2>&1; then\
+   if [ -f /usr/include/sys/termio.h ]; then\
echo '#define _HAVE_SYS_TERMIO_H_'   >> tmp; \
else true; fi
-   if echo '#include ' | $(CC) -E - >/dev/null 2>&1; then\
-   echo '#define _HAVE_TERMIO_H_'   >> tmp; \
-   else true; fi
-   if echo '#include ' | $(CC) -E - >/dev/null 2>&1; then\
+   if [ -f /usr/include/sys/stdtypes.h ]; then\
echo '#define _HAVE_SYS_STDTYPES_H_' >> tmp; \
else true; fi
-   if echo '#include ' | $(CC) -E - >/dev/null 2>&1; then\
+   if [ -f /usr/include/sys/fcntl.h ]; then\
echo '#define _HAVE_SYS_FCNTL_H_'>> tmp; \
else true; fi
-   if echo '#include ' | $(CC) -E - >/dev/null 2>&1; then\
+   if [ -f /usr/include/fcntl.h ]; then\
echo '#define _HAVE_FCNTL_H_'>> tmp; \
else true; fi
-echo '#endif /* file wrapper */'>> tmp;
diff -Nru lookup-1.08b/commands.c lookup-1.08b/commands.c
--- lookup-1.08b/commands.c 2024-02-21 14:26:13.0 +
+++ lookup-1.08b/commands.c 1997-01-23 03:53:14.0 +
@@ -262,7 +262,7 @@
 
 if (is_xterm == unchecked)
 {
-   /* extern const char *getenv(const char *); */
+   extern const char *getenv(const char *);
String *term = (String *)getenv("TERM");
if (term && (strNcmp(term, "kterm", 5) == 0 ||
 strNcmp(term, "xterm", 5) == 0 ||
diff -Nru lookup-1.08b/debian/changelog lookup-1.08b/debian/changelog
--- lookup-1.08b/debian/changelog   2024-02-21 14:26:13.0 +
+++ lookup-1.08b/debian/changelog   2024-02-21 14:17:29.0 +
@@ -1,3 +1,11 @@
+lookup (1.08b-13.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Convert to source format 3.0. Closes: #1007286
+  * d/copyright: Convert to machine-readable format.
+
+ -- Bastian Germann   Wed, 21 Feb 2024 14:17:29 +
+
 lookup (1.08b-13) unstable; urgency=medium
 
   * Fix future glibc FTBFS. Closes: #967989
diff -Nru lookup-1.08b/debian/copyright lookup-1.08b/debian/copyright
--- lookup-1.08b/debian/copyright   2024-02-21 14:26:13.0 +
+++ lookup-1.08b/debian/copyright   2024-02-21 14:17:29.0 +
@@ -1,21 +1,20 @@
-This package was debianized by Hayao Nakahara  on
-Tue, 19 Oct 1999 00:24:21 +0900.
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Comment:
+ This package was debianized by Hayao Nakahara  on
+ Tue, 19 Oct 1999 00:24:21 +0900.
+Source:
+ ftp://ftp.cc.monash.edu.au/pub/nihongo/
+Upstream-Contact:
+ Jeffrey Friedl 
 
-It was downloaded from
-   ftp://ftp.cc.monash.edu.au/pub/nihongo/
-
-Upstream Author: Jeffrey Friedl 
-
-Copyright: Each source file has the following copyright notice:
-
-/*
+Files: *
+Copyright:
  * jfri...@nff.ncl.omron.co.jp
  *
  * This work is placed under the terms of the GNU General Purpose Licence
  * (the "GNU Copyleft").
  *
  * December 1993.
- */
-
-On Debian GNU/Linux systems, the complete text of the GNU General  
 
-Public License can be found in `/usr/share/common-licenses/GPL'.
+License: GPL
+ On Debian GNU/Linux systems, the complete text of the GNU General 
  
+ Public License can be found in `/usr/share/common-licenses/GPL'.
diff -Nru lookup-1.08b/debian/patches/debian.patch 
lookup-1.08b/debian/patches/debian.patch
--- lookup-1.08b/debian/patches/debian.patch1970-01-01 00:00:00.0 
+
+++ lookup-1.08b/debian/patches/debian.patch2024-02-21 14:17:29.0 
+
@@ -0,0 +1,327 @@
+--- lookup-1.08b.orig/Makefile
 lookup-1.08b/Makefile
+@@ -16,7 +16,7 @@ CC=gcc
+ CC_TRAD=$(CC) -traditional
+ 
+ ## set to "gcc1", "gcc2" or leave blank
+-gcc=gcc1
++gcc=gcc2
+ 
+ ## selecte exactly "0" (no) or "1" (yes) for the following

Bug#1064402: texlive-binaries: tex-common configure: lua error : startup file: /bin/mtxrun.lua:2438: attempt to assign to const variable 'i'

[Vincent Lefevre]

Package: texlive-binaries
Version: 2023.20230311.66589-8+b1
Severity: serious

When upgrading TeX Live:

[...]
Processing triggers for tex-common (6.18) ...
Running mktexlsr. This may take some time... done.
Running mtxrun --generate. This may take some time... 
mtxrun --generate failed. Output has been stored in
/tmp/mtxrun.gd7J0NKo
Please include this file if you report a bug.
[...]
dpkg: error processing package tex-common (--configure):
 installed tex-common package post-installation script subprocess returned 
error exit status 1
Errors were encountered while processing:
 tex-common

/tmp/mtxrun.gd7J0NKo just contains:

lua error : startup file: /bin/mtxrun.lua:2438: attempt to assign to const 
variable 'i'

Note: the tex-common and context (from which /bin/mtxrun.lua comes
from) are still old packages, and there were no issues with them
in the past. So I assume that the bug has been introduced in
/usr/bin/texlua (/bin/mtxrun.lua is a texlua script), which is
provided by texlive-binaries.

-- Package-specific info:
IMPORTANT INFORMATION: We will only consider bug reports concerning
the packaging of TeX Live as relevant. If you have problems with
combination of packages in a LaTeX document, please consult your
local TeX User Group, the comp.text.tex user group, the author of
the original .sty file, or any other help resource. 

In particular, bugs that are related to up-upstream, i.e., neither
Debian nor TeX Live (upstream), but the original package authors,
will be closed immediately.

   *** The Debian TeX Team is *not* a LaTeX Help Desk ***

If you report an error when running one of the TeX-related binaries 
(latex, pdftex, metafont,...), or if the bug is related to bad or wrong
output, please include a MINIMAL example input file that produces the
error in your report.

Please run your example with
(pdf)latex -recorder ...
(or any other program that supports -recorder) and send us the generated
file with the extension .fls, it lists all the files loaded during
the run and can easily explain problems induced by outdated files in
your home directory.

Don't forget to also include minimal examples of other files that are 
needed, e.g. bibtex databases. Often it also helps
to include the logfile. Please, never send included pictures!

If your example file isn't short or produces more than one page of
output (except when multiple pages are needed to show the problem),
you can probably minimize it further. Instructions on how to do that
can be found at

http://www.minimalbeispiel.de/mini-en.html (english)

or 

http://www.minimalbeispiel.de/mini.html (german)

##
minimal input file


##
other files

##
 List of ls-R files

-rw-r--r-- 1 root root 4243 2024-02-21 14:57:26 /var/lib/texmf/ls-R
lrwxrwxrwx 1 root root 29 2022-10-12 23:25:33 /usr/share/texmf/ls-R -> 
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 2024-02-14 15:08:19 
/usr/share/texlive/texmf-dist/ls-R -> /var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 2024-02-14 15:08:19 
/usr/share/texlive/texmf-dist/ls-R -> /var/lib/texmf/ls-R-TEXLIVEDIST
##
 Config files
-rw-r--r-- 1 root root 475 2024-02-21 14:57:26 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 2024-02-14 15:08:19 
/usr/share/texmf/web2c/fmtutil.cnf -> /var/lib/texmf/fmtutil.cnf-DEBIAN
lrwxrwxrwx 1 root root 32 2024-02-14 15:08:19 /usr/share/texmf/web2c/updmap.cfg 
-> /var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 5334 2024-02-21 14:57:26 
/var/lib/texmf/tex/generic/config/language.dat
##
 Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 2014-10-21 02:46:09 mktex.cnf
-rw-r--r-- 1 root root 475 2024-02-21 14:57:26 texmf.cnf
##
 md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c  /etc/texmf/texmf.d/00debian.cnf

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), 
(500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages texlive-binaries depends on:
ii  libc6   2.37-15
ii  libcairo2   1.18.0-1+b1
ii  libfontconfig1  2.15.0-1
ii  libfreetype62.13.2+dfsg-1+b1
ii  libgcc-s1   14-20240201-3
ii  libgraphite2-3  1.3.14-2
ii  libharfbuzz0b   8.3.0-2
ii  libicu7272.1-4+b1
ii  libkpathsea62023.20230311.66589-8+b1
ii  libmpfr64.2.1-1
ii  libpaper1 

Bug#1063678: libmrss0: Memory leak while parsing an RSS2 feed

[b]

Thanks for reporting this! I fixed the memory leak and make a new release.
Best

On 10/02/24 23:36, Mikhail Kot wrote:

Package: libmrss0
Version: 0.19.2-7
Severity: important
X-Debbugs-Cc: to-debian-...@myrrc.dev

Dear Maintainer,

I have found a bug in libmrss0 leading to memory leak on parsing some of
files. Please find the details attached.

For the following program:

```c
int main(int argc, char **argv) {
   (void)argc, (void)argv;
   mrss_t *doc = NULL;

   FILE *rss = fopen("rss.xml", "r");
   fseek(rss, 0, SEEK_END);
   long len = ftell(rss);
   rewind(rss);

   char *str = malloc(len + 1);
   fread(str, len, 1, rss);
   fclose(rss);
   str[len] = 0;

   mrss_parse_buffer(str, len, );
   mrss_free(doc);
   free(str);
   return 0;
}
```

built with

```
gcc -o out -fsanitize=address nxml_err.c -lmrss
```

Given rss.xml is `wget https://blog.demofox.org/rss.xml`,

ASan reports the following error:

```
=
==967975==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 3 byte(s) in 1 object(s) allocated from:
 #0 0x7f87515749a7 in __interceptor_strdup 
../../../../src/libsanitizer/asan/asan_interceptors.cpp:454
 #1 0x7f87511cec70 in nxmle_find_attribute 
(/lib/x86_64-linux-gnu/libnxml.so.0+0x5c70)

SUMMARY: AddressSanitizer: 3 byte(s) leaked in 1 allocation(s).
```

The issue also reproduces on different files. On some other files,
a bigger leak is reported.

```
=
==966721==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 376010 byte(s) in 18 object(s) allocated from:
 #0 0x7ff5db6989a7 in __interceptor_strdup 
../../../../src/libsanitizer/asan/asan_interceptors.cpp:454
 #1 0x7ff5dad73029 in nxml_get_string 
(/lib/x86_64-linux-gnu/libnxml.so.0+0x5029)

Direct leak of 3 byte(s) in 1 object(s) allocated from:
 #0 0x7ff5db6989a7 in __interceptor_strdup 
../../../../src/libsanitizer/asan/asan_interceptors.cpp:454
 #1 0x7ff5dad73c70 in nxmle_find_attribute 
(/lib/x86_64-linux-gnu/libnxml.so.0+0x5c70)

SUMMARY: AddressSanitizer: 376013 byte(s) leaked in 19 allocation(s).
```

Libmrss0 uses nxml0 internally. For the following program,

```c
int main(int argc, char **argv) {
   (void)argc, (void)argv;
   nxml_t *doc = NULL;

   FILE *rss = fopen("rss.xml", "r");
   fseek(rss, 0, SEEK_END);
   long len = ftell(rss);
   rewind(rss);

   char *str = malloc(len + 1);
   fread(str, len, 1, rss);
   fclose(rss);
   str[len] = 0;

   if (nxml_new() != NXML_OK)
 return 1;
   nxml_parse_buffer(doc, str, len);
   nxml_free(doc);

   free(str);
   return 0;
}
```

built with

```
gcc -o out -fsanitize=address nxml_err.c -lnxml
```

the leak does not reproduce which makes me think the issue not related to
libnxml0.
If we modify the first program to parse an url instead,

```
mrss_parse_url("https://blog.demofox.org/rss.xml;, );
```

the error remains the same which makes me think the issue is not related
to libcurl.

According to libmrss0 sources
(https://github.com/bakulf/libmrss/blob/cc2f489ba698a2227065731b714905ab56b1de1a/test/parser.c#L27),
no invocation except `mrss_free` is required, so I believe
this is a bug indeed.


-- System Information:
Debian Release: bookworm/sid
   APT prefers jammy-updates
   APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 'jammy'), 
(100, 'jammy-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.15.0-25-generic (SMP w/12 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libmrss0 depends on:
ii  libc62.35-0ubuntu3.6
ii  libcurl3-gnutls  7.81.0-1ubuntu1.15
ii  libnxml0 0.18.4-1

libmrss0 recommends no packages.

libmrss0 suggests no packages.

-- no debconf information

Bug#1007036: linux86: please consider upgrading to 3.0 source format

[Bastian Germann]

I am uploading a NMU to DELAYED/10 in order to fix this.
Please find the debdiff attached.diff -Nru linux86-0.16.17/bcc/bcc.c linux86-0.16.17/bcc/bcc.c
--- linux86-0.16.17/bcc/bcc.c   2024-02-21 14:12:59.0 +
+++ linux86-0.16.17/bcc/bcc.c   2005-01-03 22:41:55.0 +
@@ -32,7 +32,6 @@
 #ifndef MSDOS
 #include 
 #include 
-#include 
 #endif
 #include "version.h"
 
@@ -601,12 +600,8 @@
 command_reset()
 {
 #ifndef MAXPATHLEN
-#ifdef PATH_MAX
-#define MAXPATHLEN PATH_MAX
-#else
 #define MAXPATHLEN 1024
 #endif
-#endif
char buf[MAXPATHLEN];
char ** prefix;
char * saved_cmd;
@@ -1313,7 +1308,11 @@
 
   for(d=s=ptr; d && *s; s=d)
   {
+#ifdef MAXPATHLEN
  char buf[MAXPATHLEN];
+#else
+ char buf[1024];
+#endif
 
 free(temp);
  d=strchr(s, ':');
diff -Nru linux86-0.16.17/bcc/const.h linux86-0.16.17/bcc/const.h
--- linux86-0.16.17/bcc/const.h 2024-02-21 14:12:59.0 +
+++ linux86-0.16.17/bcc/const.h 2004-06-20 19:49:37.0 +
@@ -76,8 +76,7 @@
 
 /* Unportable alignment needed for specific compilers */
 #ifndef VERY_SMALL_MEMORY
-/* # define S_ALIGNMENT (sizeof(long)) */ /* A little safer */
-# define S_ALIGNMENT (2*sizeof(size_t)) /* Even more safe: do as glibc malloc 
*/
+# define S_ALIGNMENT (sizeof(long)) /* A little safer */
 #endif
 
 /* local style */
diff -Nru linux86-0.16.17/copt/copt.c linux86-0.16.17/copt/copt.c
--- linux86-0.16.17/copt/copt.c 2024-02-21 14:12:59.0 +
+++ linux86-0.16.17/copt/copt.c 2003-10-07 19:46:35.0 +
@@ -174,7 +174,7 @@
   /* Delete leading white spaces */
   for (cp = buf; *cp && isspace(*cp); cp++) ;
   if (cp != buf && *cp)
-   memmove(buf, cp, strlen(cp) + 1);
+   strcpy(buf, cp);
 
   return(buf);
 }
diff -Nru linux86-0.16.17/debian/bcc.copyright 
linux86-0.16.17/debian/bcc.copyright
--- linux86-0.16.17/debian/bcc.copyright1970-01-01 00:00:00.0 
+
+++ linux86-0.16.17/debian/bcc.copyright2024-02-21 13:46:30.0 
+
@@ -0,0 +1,64 @@
+This package is part of the Debian GNU/Linux's version of the 8086
+Software development environment ``linux86''.
+
+It was packaged by Juan Cespedes , from
+sources obtained from:
+  http://homepage.ntlworld.com/robert.debath/
+
+
+Copyrights
+--
+Copyright 1992-1997 Bruce Evans 
+Copyright 1996-2007 Robert de Bath 
+
+unproto:
+Copyright 1993 Wietse Venema
+   wie...@wzv.win.tue.nl
+   Mathematics and Computing Science
+   Eindhoven University of Technology
+   The Netherlands
+
+Contributors:
+Alan Cox
+Nat Friedman
+Steven Huang
+Steffen Kaiser  
+Shane Kerr  
+Gero Kuhlmann   
+Chad Page   
+Dick Porter 
+Dale Schumacher 
+Wietse Venema   
+Joel Weber II   
+Claudio Matsuoka
+
+Modifications for Debian:
+  Copyright (C) 1996 Christoph Lameter 
+  Copyright (C) 1997 Siggy Brentrup 
+  Copyright (C) 1997-2007 Juan Cespedes 
+
+
+License
+---
+The `bcc' part of the distribution is now covered by the GPL.
+
+The programs elksemu and copt are under the GPL.
+
+unproto has the following license:
+
+> From: wie...@wzv.win.tue.nl (Wietse Venema)
+> Date: Sat, 25 Oct 1997 21:41:40 -0400 (EDT)
+> Message-Id: <199710260141.uaa17...@spike.porcupine.org>
+> Subject: Re: unproto license
+> 
+> Unproto pre-dates the wide-spread use of GPL and other schemes.
+> The software may be distributed as long I and my university get
+> proper credits, and as long as changes made to the software are
+> identified as such. So, there are no strings attached.
+
+A copy of the GNU General Public License is available as
+`/usr/share/common-licenses/GPL' in the Debian GNU/Linux distribution
+or on the World Wide Web at `http://www.gnu.org/copyleft/gpl.html'.
+You can also obtain them by writing to the Free Software Foundation,
+Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+
diff -Nru linux86-0.16.17/debian/bin86.copyright 
linux86-0.16.17/debian/bin86.copyright
--- linux86-0.16.17/debian/bin86.copyright  1970-01-01 00:00:00.0 
+
+++ linux86-0.16.17/debian/bin86.copyright  2024-02-21 13:46:30.0 
+
@@ -0,0 +1,43 @@
+This package is part of the Debian GNU/Linux's version of the 8086
+Software development environment ``linux86''.
+
+It was packaged by Juan Cespedes , from
+sources obtained from:
+  http://homepage.ntlworld.com/robert.debath/
+
+
+Copyrights
+--
+Copyright 1992-1997 Bruce Evans 
+Copyright 1996-2007 Robert de Bath 
+
+Contributors:
+Alan Cox
+Nat Friedman
+Steven Huang
+Steffen Kaiser  
+Shane Kerr  
+Gero Kuhlmann   
+Chad Page   
+Dick Porter 
+Dale Schumacher 
+Wietse Venema   
+Joel Weber II   
+Claudio Matsuoka
+
+Modifications for Debian:

Bug#1064401: python-requests-kerberos: please package version 0.14

[Alexandre Detiste]

Source: python-requests-kerberos
Version: 0.12.0-2
Severity: normal

v0.14 is available here:

https://github.com/requests/requests-kerberos/releases/tag/v0.14.0

Bug#1064395: logcheck: rsyslog produces two timestamp formats in latest version

[Ralf Schlatterbeck]

On Wed, Feb 21, 2024 at 02:24:03PM +0100, Ralf Schlatterbeck wrote:
> 
> Local log lines include the sub-seconds part like:
> 2024-02-16T22:05:52.315463+01:00 tux [...]
> 
> while remote logs (in that case from virtual machines on the same host) do not
> include the sub-seconds part:
> 2024-02-16T22:06:02+01:00 tux1 [...]
> 
> Logcheck currently deals only with the first format. This results in no
> logcheck pattern matching for remote host log entries.

I forgot to mention:
There is an upstream (rsyslog) bug-report at
https://github.com/rsyslog/rsyslog/issues/5332

And a debian bug report for rsyslog at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064385

Thanks
Ralf
-- 
Dr. Ralf Schlatterbeck  Tel:   +43/2243/26465-16
Open Source Consulting  www:   www.runtux.com
Reichergasse 131, A-3411 Weidling   email: off...@runtux.com

Bug#1064400: discover-data: install files into /usr

[Michael Biebl]

Source: discover-data
Version: 2.2013.01.13
Severity: normal
Tags: patch trixie sid
User: helm...@debian.org
Usertags: dep17m2

We want to finalize the /usr-merge via DEP17 by moving all files to
/usr. discover-data installs files into /lib; these should be moved into
the respective canonical locations in /usr/.

Please find a patch attached. It has been build-tested.

This should not be backported to bookworm. If you intend to
backport, please use dh_movetousr instead.

If your package will change for the t64 transition or otherwise
rename/split/move its binaries (packages) during trixie, please
then upload to experimental and get in touch with the UsrMerge
driver, please see the wiki [1].

Michael

[1] https://wiki.debian.org/UsrMerge
diff -Nru discover-data-2.2013.01.13/debian/changelog 
discover-data-2.2013.01.13+nmu1/debian/changelog
--- discover-data-2.2013.01.13/debian/changelog 2022-01-09 10:27:19.0 
+0100
+++ discover-data-2.2013.01.13+nmu1/debian/changelog2024-02-21 
14:53:10.0 +0100
@@ -1,3 +1,10 @@
+discover-data (2.2013.01.13+nmu1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Install files into /usr. (Closes: #-1)
+
+ -- Michael Biebl   Wed, 21 Feb 2024 14:53:10 +0100
+
 discover-data (2.2013.01.13) unstable; urgency=medium
 
   * Rewrite debian/rules using dh, keeping only a few directives.
diff -Nru discover-data-2.2013.01.13/debian/rules 
discover-data-2.2013.01.13+nmu1/debian/rules
--- discover-data-2.2013.01.13/debian/rules 2022-01-09 10:26:49.0 
+0100
+++ discover-data-2.2013.01.13+nmu1/debian/rules2024-02-21 
14:52:44.0 +0100
@@ -4,10 +4,10 @@
dh $@
 
 override_dh_auto_build:
-   dh_auto_build -- hwlistsdir=/lib/discover
+   dh_auto_build -- hwlistsdir=/usr/lib/discover
 
 override_dh_auto_install:
-   dh_auto_install -- hwlistsdir=/lib/discover
+   dh_auto_install -- hwlistsdir=/usr/lib/discover
 
 override_dh_installchangelogs:
dh_installchangelogs ChangeLog

Bug#1064399: openvpn: install systemd files into /usr

[Michael Biebl]

Source: openvpn
Version: 2.6.7-1
Severity: normal
Tags: patch trixie sid
User: helm...@debian.org
Usertags: dep17m2

We want to finalize the /usr-merge via DEP17 by moving all files to
/usr. openvpn installs files into /lib; these should be moved into
the respective canonical locations in /usr/.

Please find a patch attached. It has been build-tested.

This should not be backported to bookworm. If you intend to
backport, please use dh_movetousr instead or defer the placement of the
unit files to systemd.pc.

If your package will change for the t64 transition or otherwise
rename/split/move its binaries (packages) during trixie, please
then upload to experimental and get in touch with the UsrMerge
driver, please see the wiki [1].

Michael

[1] https://wiki.debian.org/UsrMerge
diff -Nru openvpn-2.6.7/debian/changelog openvpn-2.6.7/debian/changelog
--- openvpn-2.6.7/debian/changelog  2023-11-11 22:01:15.0 +0100
+++ openvpn-2.6.7/debian/changelog  2024-02-21 14:43:14.0 +0100
@@ -1,3 +1,10 @@
+openvpn (2.6.7-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Install systemd generator and units into /usr. (Closes: #-1)
+
+ -- Michael Biebl   Wed, 21 Feb 2024 14:43:14 +0100
+
 openvpn (2.6.7-1) unstable; urgency=medium
 
   [ Aquila Macedo ]
diff -Nru openvpn-2.6.7/debian/openvpn.install 
openvpn-2.6.7/debian/openvpn.install
--- openvpn-2.6.7/debian/openvpn.install2023-11-11 22:01:15.0 
+0100
+++ openvpn-2.6.7/debian/openvpn.install2024-02-21 14:40:37.0 
+0100
@@ -1 +1 @@
-debian/openvpn-generator /lib/systemd/system-generators
+debian/openvpn-generator /usr/lib/systemd/system-generators
diff -Nru openvpn-2.6.7/debian/rules openvpn-2.6.7/debian/rules
--- openvpn-2.6.7/debian/rules  2023-11-11 22:01:15.0 +0100
+++ openvpn-2.6.7/debian/rules  2024-02-21 14:39:48.0 +0100
@@ -5,7 +5,7 @@
 ENV_VARS   := IFCONFIG=/sbin/ifconfig ROUTE=/lib/freebsd/route
 EXTRA_ARGS :=
 else
-ENV_VARS   := SYSTEMD_ASK_PASSWORD=/bin/systemd-ask-password 
SYSTEMD_UNIT_DIR=/lib/systemd/system TMPFILES_DIR=/usr/lib/tmpfiles.d
+ENV_VARS   := SYSTEMD_ASK_PASSWORD=/usr/bin/systemd-ask-password 
SYSTEMD_UNIT_DIR=/usr/lib/systemd/system TMPFILES_DIR=/usr/lib/tmpfiles.d
 EXTRA_ARGS := --enable-systemd --enable-dco
 endif
 

Bug#1007575: libtcd: please consider upgrading to 3.0 source format

[Bastian Germann]

I am uploading a NMU to DELAYED/10 in order to fix this.
Please find the debdiff attached.diff -Nru libtcd-2.2.2/config.guess libtcd-2.2.2/config.guess
--- libtcd-2.2.2/config.guess   2024-02-21 13:43:50.0 +
+++ libtcd-2.2.2/config.guess   2006-11-19 15:39:28.0 +
@@ -1,10 +1,9 @@
 #! /bin/sh
 # Attempt to guess a canonical system name.
 #   Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
-#   2000, 2001, 2002, 2003, 2004, 2005, 2006 Free Software Foundation,
-#   Inc.
+#   2000, 2001, 2002, 2003, 2004, 2005 Free Software Foundation, Inc.
 
-timestamp='2007-07-22'
+timestamp='2005-12-13'
 
 # This file is free software; you can redistribute it and/or modify it
 # under the terms of the GNU General Public License as published by
@@ -107,7 +106,7 @@
 trap "exitcode=\$?; (rm -f \$tmpfiles 2>/dev/null; rmdir \$tmp 2>/dev/null) && 
exit \$exitcode" 0 ;
 trap "rm -f \$tmpfiles 2>/dev/null; rmdir \$tmp 2>/dev/null; exit 1" 1 2 13 15 
;
 : ${TMPDIR=/tmp} ;
- { tmp=`(umask 077 && mktemp -d "$TMPDIR/cgXX") 2>/dev/null` && test -n 
"$tmp" && test -d "$tmp" ; } ||
+ { tmp=`(umask 077 && mktemp -d -q "$TMPDIR/cgXX") 2>/dev/null` && test -n 
"$tmp" && test -d "$tmp" ; } ||
  { test -n "$RANDOM" && tmp=$TMPDIR/cg$$-$RANDOM && (umask 077 && mkdir $tmp) 
; } ||
  { tmp=$TMPDIR/cg-$$ && (umask 077 && mkdir $tmp) && echo "Warning: creating 
insecure temp directory" >&2 ; } ||
  { echo "$me: cannot create a temporary directory in $TMPDIR" >&2 ; exit 1 ; } 
;
@@ -161,7 +160,6 @@
arm*) machine=arm-unknown ;;
sh3el) machine=shl-unknown ;;
sh3eb) machine=sh-unknown ;;
-   sh5el) machine=sh5le-unknown ;;
*) machine=${UNAME_MACHINE_ARCH}-unknown ;;
esac
# The Operating System including object format, if it has switched
@@ -208,11 +206,8 @@
 *:ekkoBSD:*:*)
echo ${UNAME_MACHINE}-unknown-ekkobsd${UNAME_RELEASE}
exit ;;
-*:SolidBSD:*:*)
-   echo ${UNAME_MACHINE}-unknown-solidbsd${UNAME_RELEASE}
-   exit ;;
 macppc:MirBSD:*:*)
-   echo powerpc-unknown-mirbsd${UNAME_RELEASE}
+   echo powerppc-unknown-mirbsd${UNAME_RELEASE}
exit ;;
 *:MirBSD:*:*)
echo ${UNAME_MACHINE}-unknown-mirbsd${UNAME_RELEASE}
@@ -330,7 +325,7 @@
 sun4*:SunOS:5.*:* | tadpole*:SunOS:5.*:*)
echo sparc-sun-solaris2`echo ${UNAME_RELEASE}|sed -e 's/[^.]*//'`
exit ;;
-i86pc:SunOS:5.*:* | i86xen:SunOS:5.*:*)
+i86pc:SunOS:5.*:*)
echo i386-pc-solaris2`echo ${UNAME_RELEASE}|sed -e 's/[^.]*//'`
exit ;;
 sun4*:SunOS:6*:*)
@@ -769,19 +764,12 @@
echo ${UNAME_MACHINE}-unknown-bsdi${UNAME_RELEASE}
exit ;;
 *:FreeBSD:*:*)
-   case ${UNAME_MACHINE} in
-   pc98)
-   echo i386-unknown-freebsd`echo ${UNAME_RELEASE}|sed -e 
's/[-(].*//'` ;;
-   amd64)
-   echo x86_64-unknown-freebsd`echo ${UNAME_RELEASE}|sed -e 
's/[-(].*//'` ;;
-   *)
-   echo ${UNAME_MACHINE}-unknown-freebsd`echo ${UNAME_RELEASE}|sed 
-e 's/[-(].*//'` ;;
-   esac
+   echo ${UNAME_MACHINE}-unknown-freebsd`echo ${UNAME_RELEASE}|sed -e 
's/[-(].*//'`
exit ;;
 i*:CYGWIN*:*)
echo ${UNAME_MACHINE}-pc-cygwin
exit ;;
-*:MINGW*:*)
+i*:MINGW*:*)
echo ${UNAME_MACHINE}-pc-mingw32
exit ;;
 i*:windows32*:*)
@@ -791,15 +779,9 @@
 i*:PW*:*)
echo ${UNAME_MACHINE}-pc-pw32
exit ;;
-*:Interix*:[3456]*)
-   case ${UNAME_MACHINE} in
-   x86)
-   echo i586-pc-interix${UNAME_RELEASE}
-   exit ;;
-   EM64T | authenticamd)
-   echo x86_64-unknown-interix${UNAME_RELEASE}
-   exit ;;
-   esac ;;
+x86:Interix*:[345]*)
+   echo i586-pc-interix${UNAME_RELEASE}|sed -e 's/\..*//'
+   exit ;;
 [345]86:Windows_95:* | [345]86:Windows_98:* | [345]86:Windows_NT:*)
echo i${UNAME_MACHINE}-pc-mks
exit ;;
@@ -835,9 +817,6 @@
 arm*:Linux:*:*)
echo ${UNAME_MACHINE}-unknown-linux-gnu
exit ;;
-avr32*:Linux:*:*)
-   echo ${UNAME_MACHINE}-unknown-linux-gnu
-   exit ;;
 cris:Linux:*:*)
echo cris-axis-linux-gnu
exit ;;
@@ -872,11 +851,7 @@
#endif
#endif
 EOF
-   eval "`$CC_FOR_BUILD -E $dummy.c 2>/dev/null | sed -n '
-   /^CPU/{
-   s: ::g
-   p
-   }'`"
+   eval "`$CC_FOR_BUILD -E $dummy.c 2>/dev/null | sed -n '/^CPU/{s: 
::g;p;}'`"
test x"${CPU}" != x && { echo "${CPU}-unknown-linux-gnu"; exit; }
;;
 mips64:Linux:*:*)
@@ -895,11 +870,7 @@
#endif
#endif
 EOF
-   eval "`$CC_FOR_BUILD -E $dummy.c 2>/dev/null | sed -n '
-   /^CPU/{
-   s: ::g
-   p
-   }'`"
+   eval "`$CC_FOR_BUILD -E $dummy.c 2>/dev/null | sed -n '/^CPU/{s: 
::g;p;}'`"
test x"${CPU}" != x && { echo 

Bug#1064398: docker-compose: please remove obsolete build-dependency python3-mock

[Alexandre Detiste]

Source: docker-compose
Version: 1.29.2-6
Severity: normal

https://github.com/testing-cabal/mock

> mock is now part of the Python standard library, available as unittest.mock 
> in Python 3.3 onwards.

python3-mock is being slowly removed from the distribution.

this project has already switched to unittest.mock,
there's only the only the one line in debian/control to remove.

Greetings,

Alexandre

Bug#1064397: ITP: client-desktop-shell-integration-nautilus -- Nautilus, Nemo and Caja integration of the owncloud-client

[Pierre-Elliott Bécue]

Package: wnpp
Severity: wishlist
Owner: Pierre-Elliott Bécue 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: client-desktop-shell-integration-nautilus
  Version : 5.0.0
  Upstream Contact: Frank Müller 
* URL : 
https://github.com/owncloud/client-desktop-shell-integration-nautilus
* License : GPL-2
  Programming Lang: Python, Shell, ...
  Description : Nautilus, Nemo and Caja integration for ownCloud Client.

These three extensions were originally integrated in the owncloud-client
source package. Upstream decided to extract them to create a new repo.

The package will be maintained in the owncloud-team.

Bug#1064396: libinput: install udev files into /usr

[Michael Biebl]

Source: libinput
Version: 1.25.0-1
Severity: normal
Tags: patch trixie sid
User: helm...@debian.org
Usertags: dep17m2

We want to finalize the /usr-merge via DEP17 by moving all files to
/usr. libinput installs files into /lib; these should be moved into
the respective canonical locations in /usr/.

Please find a patch attached. It has been build-tested.

This should not be backported to bookworm. If you intend to
backport, please use dh_movetousr instead or defer the placement of the
unit files to udev.pc.

If your package will change for the t64 transition or otherwise
rename/split/move its binaries (packages) during trixie, please
then upload to experimental and get in touch with the UsrMerge
driver, please see the wiki [1].

Michael

[1] https://wiki.debian.org/UsrMerge
diff -Nru libinput-1.25.0/debian/changelog libinput-1.25.0/debian/changelog
--- libinput-1.25.0/debian/changelog2024-02-05 13:20:23.0 +0100
+++ libinput-1.25.0/debian/changelog2024-02-21 14:23:22.0 +0100
@@ -1,3 +1,10 @@
+libinput (1.25.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Install udev rules and helpers into /usr. (Closes: #-1)
+
+ -- Michael Biebl   Wed, 21 Feb 2024 14:23:22 +0100
+
 libinput (1.25.0-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru libinput-1.25.0/debian/libinput10-udeb.install 
libinput-1.25.0/debian/libinput10-udeb.install
--- libinput-1.25.0/debian/libinput10-udeb.install  2024-01-24 
16:25:22.0 +0100
+++ libinput-1.25.0/debian/libinput10-udeb.install  2024-02-21 
14:23:22.0 +0100
@@ -1,3 +1,3 @@
-lib/udev
+usr/lib/udev
 usr/lib/*/libinput.so.10*
 usr/share/libinput
diff -Nru libinput-1.25.0/debian/libinput-bin.install 
libinput-1.25.0/debian/libinput-bin.install
--- libinput-1.25.0/debian/libinput-bin.install 2024-01-24 16:25:22.0 
+0100
+++ libinput-1.25.0/debian/libinput-bin.install 2024-02-21 14:23:22.0 
+0100
@@ -1,2 +1,2 @@
-lib/udev
+usr/lib/udev
 usr/share/libinput
diff -Nru libinput-1.25.0/debian/rules libinput-1.25.0/debian/rules
--- libinput-1.25.0/debian/rules2024-01-24 16:25:22.0 +0100
+++ libinput-1.25.0/debian/rules2024-02-21 14:23:22.0 +0100
@@ -7,12 +7,12 @@
 override_dh_auto_configure:
dh_auto_configure -B build-deb -- \
-Ddocumentation=false \
-   -Dudev-dir=/lib/udev
+   -Dudev-dir=/usr/lib/udev
 
 ifeq ($(with_udeb),yes)
dh_auto_configure -B build-udeb -- \
-Ddocumentation=false \
-   -Dudev-dir=/lib/udev \
+   -Dudev-dir=/usr/lib/udev \
-Dlibwacom=false
 endif