date:20231110

Source: symfony
Version: 5.4.30+dfsg-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 5.4.29+dfsg-1
Control: found -1 5.4.23+dfsg-1

Hi,

The following vulnerability was published for symfony.

CVE-2023-46733[0]:
| Symfony is a PHP framework for web and console applications and a
| set of reusable PHP components. Starting in versions 5.4.21 and
| 6.2.7 and prior to versions 5.4.31 and 6.3.8,
| `SessionStrategyListener` does not migrate the session after every
| successful login. It does so only in case the logged in user changes
| by means of checking the user identifier. In some use cases, the
| user identifier doesn't change between the verification phase and
| the successful login, while the token itself changes from one type
| (partially-authenticated) to another (fully-authenticated). When
| this happens, the session id should be regenerated to prevent
| possible session fixations, which is not the case at the moment. As
| of versions 5.4.31 and 6.3.8, Symfony now checks the type of the
| token in addition to the user identifier before deciding whether the
| session id should be regenerated.


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-2023-46733
https://www.cve.org/CVERecord?id=CVE-2023-46733
[1] https://github.com/symfony/symfony/security/advisories/GHSA-m2wj-r6g3-fxfx
[2] 
https://github.com/symfony/symfony/commit/dc356499d5ceb86f7cf2b4c7f032eca97061ed74

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.5.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
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

Bug#1055774: symfony: CVE-2023-46734

Source: symfony
Version: 5.4.30+dfsg-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 5.4.29+dfsg-1
Control: found -1 5.4.23+dfsg-1
Control: found -1 4.4.19+dfsg-2+deb11u3
Control: found -1 4.4.19+dfsg-2
Control: found -1 3.4.22+dfsg-2+deb10u2
Control: found -1 3.4.22+dfsg-2

Hi,

The following vulnerability was published for symfony.

CVE-2023-46734[0]:
| Symfony is a PHP framework for web and console applications and a
| set of reusable PHP components. Starting in versions 2.0.0, 5.0.0,
| and 6.0.0 and prior to versions 4.4.51, 5.4.31, and 6.3.8, some Twig
| filters in CodeExtension use `is_safe=html` but don't actually
| ensure their input is safe. As of versions 4.4.51, 5.4.31, and
| 6.3.8, Symfony now escapes the output of the affected filters.


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-2023-46734
https://www.cve.org/CVERecord?id=CVE-2023-46734
[1] https://github.com/symfony/symfony/security/advisories/GHSA-q847-2q57-wmr3
[2] 
https://github.com/symfony/symfony/commit/9da9a145ce57e4585031ad4bee37c497353eec7c

Regards,
Salvatore

Bug#1055773: esptool: CVE-2023-46894

Source: esptool
Version: 4.6.2+dfsg-0.1
Severity: normal
Tags: security upstream
Forwarded: https://github.com/espressif/esptool/issues/926
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for esptool.

CVE-2023-46894[0]:
| An issue discovered in esptool 4.6.2 allows attackers to view
| sensitive information via weak cryptographic algorithm.

If I undestand the upstream discussion[1] correctly this is not
something hich is going to be fixed until the oldest earliest chips
are not supported anymore. So this bug is merely for documentation
purpose and can be closed once this support vanishes (or feel free to
aswer the above, we might then simply mark it as unimportant in the
security-tracker.


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-2023-46894
https://www.cve.org/CVERecord?id=CVE-2023-46894
[1] https://github.com/espressif/esptool/issues/926

Regards,
Salvatore

Bug#1055772: hoteldruid: CVE-2023-47164

Source: hoteldruid
Version: 3.0.5-1
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for hoteldruid.

CVE-2023-47164[0]:
| Cross-site scripting vulnerability in HOTELDRUID 3.0.5 and earlier
| allows a remote unauthenticated attacker to execute an arbitrary
| script on the web browser of the user who is logging in to the
| product.


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-2023-47164
https://www.cve.org/CVERecord?id=CVE-2023-47164

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1055694: initramfs-tools: After updating coreutils cp: not replacing in console when running update-initramfs

2023-11-10 Thread Sven Joachim

On 2023-11-11 01:32 +0100, Thorsten Glaser wrote:

> On Fri, 10 Nov 2023, Sven Joachim wrote:
>
>>|   'cp -n' and 'mv -n' now exit with nonzero status if they skip their
>>|   action because the destination exists, and likewise for 'cp -i',
>
> Ouch! Nonzero? That’s harsh, and bad as it’s impossible to distinguish
> between error and declining to copy/move.
>
> There is a good example in diff(1) for how to handle this better:
> use distinct errorlevels for each case.
>
> Michael, could you perhaps throw that upstream?

There is already an upstream bug report for this, see
https://debbugs.gnu.org/62572.

Cheers,
   Sven

Bug#1055771: sysvinit script corrections

2023-11-10 Thread Jerzy Sobczyk

Package: radicale
Version: 3.1.8-2

Radicale 3 which is installed from python3-radicale 3.1.8-2 is using
different base directory than previous versions and different way of
logging (STDERR istead of a file).
As a consequence /etc/init.d/radicale script requires modifications:

1. It is necessary to replace $dir/collections with $dir/collection-root in
few places.

2. After --background option there should be --output $LOGDIR/$NAME.log to
redirect logs (which are printed to STDERR) to a file.

Thanks for Your work.

My system version: Debian 6.1.55-1  kernel 6.1.0-13-amd64 #1 SMP
PREEMPT_DYNAMIC

With Best Regards,
Jerzy

Bug#1041248: keepass update

2023-11-10 Thread Julian Andres Klode

On Fri, Nov 10, 2023 at 11:36:18PM +0100, Matthias Geiger wrote:
> debdiff attached, I will upload this as a delayed NMU.

I will remove or overwrite any attempt to upload a new version.

As I have explained in the previous comment, this is highly security
sensitive and requires careful review, hence updates aside from CVEs
can only happen during Christmas break when there's time to review
the code.

I do not appreciate an NMU when I have clearly outlined my position
on the topic and am generally responsive.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en


signature.asc
Description: PGP signature

Bug#1054633: kitty: The CTRL-SHIFT-F5 and CTRL-SHIFT-F6 options only operate on config files

Control: forwarded -1 https://github.com/kovidgoyal/kitty/issues/6801

Nilesh Patra  forwarded this upstream.


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

Bug#1055770: kitty: no manual page for kitten binary

Control: forwarded -1 https://github.com/kovidgoyal/kitty/issues/6808

Forwarded to upstream.


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

Bug#1055770: kitty: no manual page for kitten binary

Package: kitty
Version: 0.30.1-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: nil...@debian.org

The Debian package for kitty needs to conform to the Debian Policy section 12.1,
which states that "each program, utility, and function should have an associated
manual page included in the same package or a dependency" and that "if no manual
page is available, this is considered as a bug and should be reported to the
Debian Bug Tracking System."

The kitty package is currently in violation of this part of the policy, as
lintian reports there is no manual page present for the "kitten" binary.

Bug#1055347: ITA: kitty -- fast, featureful, GPU based terminal

On Sat, Nov 11, 2023 at 12:57:38PM +0800, Maytham Alsudany wrote:
> Upstream uses sphinx to generate both the HTML docs and the manpages,
> so perhaps we should update sphinx's man_pages[4] option in
> docs/conf.py[5] in a PR and/or patch, adding a kitten manpage that
> points to an existing/new RST file.

Ah, right!

> > > Regarding the inconsistent shebangs in the Python files, I've opened an
> > > issue upstream regarding that[3].
> > 
> > Yep, and it seems to have been changed to "usr/bin/env python" instead in 
> > the fixing commit :-/
> > 
> > Seems like we will have to keep the `sed` call for a while.
> 
> With the experience you have packaging software written in Python, is
> it standard to use "python" or "python3" in shebangs? The fixing commit
> references PEP 394[6], which allows either shebang.

I have seen python as being more common. Possibly because people use
venv for python stuff and that always has a bin/python executable.

> > > Regarding splitting up the kitty and kitten components, I've opened an
> > > issue upstream[2], but the upstream author promptly closed it, stating
> > 
> > Something similar happened with me when I forwarded
> > 
> > 
> > 
> > Upstream which I can reproduce and it was closed very quickly.
> > 
> > My impression is that the upstream is somewhat tricky to deal with - but I 
> > guess with time, we will manage somehow.
> 
> I guess we'll have to stick to patching bugs ourselves.

For now, I suppose that'd be the case.

> > > that "the Go code depends on the rest of the code so splitting it is
> > > not going to happen."
> > 
> > I've added a comment there. Let's see if they consider to do something 
> > about it.
> 
> I'm assuming you've seen upstream's reply.

I did. Maybe we will switch to a non-dhgolang layout if this continues
to be an issue. I used this because it avoid symlinking everything
that'd there in usr/share/gocode and automates the built-using field
thingy etc.
We will re-evaluate this at a later point.

> Hopefully we can get kitty to be stable enough to move into unstable,
> I'm excited to see it propagate into testing!

I will meanwhile ask a couple of people to test out the new kitty
package.

BTW, oddly enough kitty is failing its build on ppc64el[7] which will
block migration. The tests failing in the question are trying to open a
PTY, which I suppose ppc64 does not like. I am in favor of skipping
these on that architecture, if you're fine with that.

> Regarding lintian's errors, would you like me to add descriptions to
> your patches (by that, I mean copy-paste your commit messages)?

Ah, sure. I had been lazy to not do that.

> Additionally, I keep forgetting to mention that lintian.debian.org
> seems to not work,

I am also involved with lintian maintenance in "some" capacity and
while getting lintian.d.o is in TODO, no-one realistically has the time
for that.

Lintian.d.o has been effectively replaced with its UDD counterpart[7]

> so I've had to resort to `lintian-explain-tags`. I
> don't think it's supposed to be that way.

Agreed. There's a plan to implement tag explanations within UDD at some
point as has been pointed out in this thread[8].

> > > [1]: https://github.com/kovidgoyal/kitty/issues/6808
> > > [2]: https://github.com/kovidgoyal/kitty/issues/6809
> > > [3]: https://github.com/kovidgoyal/kitty/issues/6810
> [4]:
> https://www.sphinx-doc.org/en/master/usage/configuration.html#confval-man_pages
> [5]: https://github.com/kovidgoyal/kitty/blob/master/docs/conf.py#L178
> [6]: https://peps.python.org/pep-0394/
[7]: https://wiki.debian.org/UltimateDebianDatabase/ReplacingLintianDebianOrg
[8]: https://lists.debian.org/debian-devel/2023/09/msg00394.html

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1055347: ITA: kitty -- fast, featureful, GPU based terminal

Hi Nilesh,

On Sat, 2023-11-11 at 09:44 +0530, Nilesh Patra wrote:
> On 11 November 2023 8:31:25 am IST, Maytham Alsudany 
>  wrote:
> > On Sat, 2023-11-11 at 02:31 +0530, Nilesh Patra wrote:
> > > My personal experience is that maintainer maintained manpages are
> > > seldom well-maintained and tend to get outdated with new versions
> > > if the maintainer forgets to update these regularly.
> > > Also, that manpages keep introducing new lintian warnings with new
> > > version of troff/groff.
> > > 
> > > Since this package already requires some maintenance, I feel it would be
> > > an additional burden on me and you. It is IMHO the best case scenario if
> > > the upstream maintains a manpage themselves.
> > 
> > Opened an issue upstream[1].
> 
> Since they said PRs are welcome, maybe we could send them a manpage and a 
> script to recreate it everytime.
> I think createmanpages script could be handy
> 
> 

Upstream uses sphinx to generate both the HTML docs and the manpages,
so perhaps we should update sphinx's man_pages[4] option in
docs/conf.py[5] in a PR and/or patch, adding a kitten manpage that
points to an existing/new RST file.

> > Regarding the inconsistent shebangs in the Python files, I've opened an
> > issue upstream regarding that[3].
> 
> Yep, and it seems to have been changed to "usr/bin/env python" instead in the 
> fixing commit :-/
> 
> Seems like we will have to keep the `sed` call for a while.

With the experience you have packaging software written in Python, is
it standard to use "python" or "python3" in shebangs? The fixing commit
references PEP 394[6], which allows either shebang.

> > Regarding splitting up the kitty and kitten components, I've opened an
> > issue upstream[2], but the upstream author promptly closed it, stating
> 
> Something similar happened with me when I forwarded
> 
> 
> 
> Upstream which I can reproduce and it was closed very quickly.
> 
> My impression is that the upstream is somewhat tricky to deal with - but I 
> guess with time, we will manage somehow.

I guess we'll have to stick to patching bugs ourselves.

> > that "the Go code depends on the rest of the code so splitting it is
> > not going to happen."
> 
> I've added a comment there. Let's see if they consider to do something about 
> it.

I'm assuming you've seen upstream's reply.

> 

> > Would you like me to bump the version of the package to 0.31.0 now that
> > 0.30.1 has been uploaded to experimental?
> 
> Sure, if you have the time! :)

Hopefully we can get kitty to be stable enough to move into unstable,
I'm excited to see it propagate into testing!

Regarding lintian's errors, would you like me to add descriptions to
your patches (by that, I mean copy-paste your commit messages)?

Additionally, I keep forgetting to mention that lintian.debian.org
seems to not work, so I've had to resort to `lintian-explain-tags`. I
don't think it's supposed to be that way.

> > [1]: https://github.com/kovidgoyal/kitty/issues/6808
> > [2]: https://github.com/kovidgoyal/kitty/issues/6809
> > [3]: https://github.com/kovidgoyal/kitty/issues/6810
[4]:
https://www.sphinx-doc.org/en/master/usage/configuration.html#confval-man_pages
[5]: https://github.com/kovidgoyal/kitty/blob/master/docs/conf.py#L178
[6]: https://peps.python.org/pep-0394/


Kind regards,
Maytham


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

Bug#1042386: Please upgrade to or separately provide newer upstream branch v0.10.

2023-11-10 Thread Peter Green


On 09/08/2023 11:30, Jonas Smedegaard wrote:

Quoting Peter Green (2023-08-09 10:55:07)

2. hashbrown has moved to ahash 0.8, ahash 0.8 is available in
 unstable, but is not in testing due to autopkgtest failures.
 Jonas, since ahash is one of your packages can you investigate
 and deal with these.

Thanks for nudging.  rust-ahash should be fixed now.

Unfortuntaly the "fix" upload FTBFS. Any ETA on a fix?
do you need help fixing it?

Bug#1055347: ITA: kitty -- fast, featureful, GPU based terminal




On 11 November 2023 8:31:25 am IST, Maytham Alsudany  
wrote:
>On Sat, 2023-11-11 at 02:31 +0530, Nilesh Patra wrote:
>> My personal experience is that maintainer maintained manpages are
>> seldom well-maintained and tend to get outdated with new versions
>> if the maintainer forgets to update these regularly.
>> Also, that manpages keep introducing new lintian warnings with new
>> version of troff/groff.
>> 
>> Since this package already requires some maintenance, I feel it would be
>> an additional burden on me and you. It is IMHO the best case scenario if
>> the upstream maintains a manpage themselves.
>
>Opened an issue upstream[1].

Since they said PRs are welcome, maybe we could send them a manpage and a 
script to recreate it everytime.
I think createmanpages script could be handy



>Regarding the inconsistent shebangs in the Python files, I've opened an
>issue upstream regarding that[3].

Yep, and it seems to have been changed to "usr/bin/env python" instead in the 
fixing commit :-/

Seems like we will have to keep the `sed` call for a while.

>Regarding splitting up the kitty and kitten components, I've opened an
>issue upstream[2], but the upstream author promptly closed it, stating

Something similar happened with me when I forwarded



Upstream which I can reproduce and it was closed very quickly.

My impression is that the upstream is somewhat tricky to deal with - but I 
guess with time, we will manage somehow.

>that "the Go code depends on the rest of the code so splitting it is
>not going to happen."

I've added a comment there. Let's see if they consider to do something about it.

>I may open PRs for [1] and [3] to ensure they're fixed quickly.
>
>Would you like me to bump the version of the package to 0.31.0 now that
>0.30.1 has been uploaded to experimental?

Sure, if you have the time! :)

>[1]: https://github.com/kovidgoyal/kitty/issues/6808
>[2]: https://github.com/kovidgoyal/kitty/issues/6809
>[3]: https://github.com/kovidgoyal/kitty/issues/6810

Best,
Nilesh

Bug#1055769: blag: add dependency “Suggests” for documentation

2023-11-10 Thread Ben Finney

Source: blag
Version: 2.2.0
Severity: minor

Dear Maintainer,

Working with the ‘blag’ package requires understanding how it works and
what it does.

Please set a “Suggests: blag-doc” dependency to the binary package ‘blag’.

This will present the suggestion to administrators choosing which packages
to install.

-- 
 \“There are no significant bugs in our released software that |
  `\ any significant number of users want fixed.” —Bill Gates, |
_o__)   1995-10-23 |
Ben Finney 

signature.asc
Description: PGP signature

Bug#1055763: QXL VGA does not work

2023-11-10 Thread Michael Tokarev


11.11.2023 06:19, Michael Tokarev:

Read the fine NEWS entries and install qemu-system-modules-spice
(which is a recommended package and should be installed automatically
unless you know what you're doing).


..unless you turned off install-recommends, knowing what you're doing,
that is.

/mjt

Bug#1055347: ITA: kitty -- fast, featureful, GPU based terminal

On Sat, 2023-11-11 at 02:31 +0530, Nilesh Patra wrote:
> > If would be good to get a second pair of eyes on my commits, since I've made
> > some decisive patches.
> 
> I have removed all commits adding manpage. Furthermore you added a
> compress command to dh_auto_test this would lead to installing different
> manpage based on whether or not tests are run (for instance skipped via
> nocheck). This is a bug, IMHO.

Yep, that's my mistake, I meant to put it in dh_auto_build or
dh_auto_install.

> My personal experience is that maintainer maintained manpages are
> seldom well-maintained and tend to get outdated with new versions
> if the maintainer forgets to update these regularly.
> Also, that manpages keep introducing new lintian warnings with new
> version of troff/groff.
> 
> Since this package already requires some maintenance, I feel it would be
> an additional burden on me and you. It is IMHO the best case scenario if
> the upstream maintains a manpage themselves.

Opened an issue upstream[1].

Regarding the inconsistent shebangs in the Python files, I've opened an
issue upstream regarding that[3].

Regarding splitting up the kitty and kitten components, I've opened an
issue upstream[2], but the upstream author promptly closed it, stating
that "the Go code depends on the rest of the code so splitting it is
not going to happen."

I may open PRs for [1] and [3] to ensure they're fixed quickly.

Would you like me to bump the version of the package to 0.31.0 now that
0.30.1 has been uploaded to experimental?
> 

[1]: https://github.com/kovidgoyal/kitty/issues/6808
[2]: https://github.com/kovidgoyal/kitty/issues/6809
[3]: https://github.com/kovidgoyal/kitty/issues/6810

Kind regards,
Maytham


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

Bug#1054657: transition: r-bioc-biocgenerics

2023-11-10 Thread Charles Plessy

Le Fri, Nov 10, 2023 at 11:30:13PM +0100, Sebastian Ramacher a écrit :
> 
> Can you please clarify whether you are talking about new dependencies or
> reverse dependencies above? Thanks.

Hi Sebastian,

I am talking about the reverse-dependencies of the packages that we need
to upload to NEW.  These are new dependencies of packages that need to
go through the Bioconductor transition.

Here is an example:

In Bioconductor 3.17, the new package S4Arrays was depended on by
DelayedArray.  This reverse dependency of a new package in Bioconductor
is a new dependency on a new package in Debian (r-bioc-delayed array
started to depend on r-bioc-s4arrays).  The upload of r-bioc-s4arrays
during the 3.17 transition is one of the causes of the delays.

Last week I thought that looking at the reverse-dependencies of packages
that are new in Bioconductor 3.18 would be a good heuristic to find if
we will need to introduce new packages in Debian.  This is the main
reason I expresesd my thoughts in terms of reverse-dependency of new
packages, instead of new dependencies on new packages.  However
yesterday me and Andreas figured out that this was not a good heuristic.

Here is an example:

In Bioconductor 3.18, DelayedArray starts to depend on SparseArray.
However, SparseArray is not new in Bioconductor 3.18.  It was
introudced in Bioconductor 3.17 but we did not notice and package it
because nothing was depending on it.

In conclusion, taking the point of view of reverse-dependencies of new
packages in Bioconductor was not as fruitful as I thought and I will try
to stick to the point of view of new dependencies on new packages in
Debian to avoid further confusions.

I hope it clarifies.

-- 
Charles

Bug#1055694: initramfs-tools: After updating coreutils cp: not replacing in console when running update-initramfs

2023-11-10 Thread Thorsten Glaser

On Fri, 10 Nov 2023, Sven Joachim wrote:

>|   'cp -n' and 'mv -n' now exit with nonzero status if they skip their
>|   action because the destination exists, and likewise for 'cp -i',

Ouch! Nonzero? That’s harsh, and bad as it’s impossible to distinguish
between error and declining to copy/move.

There is a good example in diff(1) for how to handle this better:
use distinct errorlevels for each case.

Michael, could you perhaps throw that upstream?

bye,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)

Bug#1054642: Failing ARP relay from external -> Linux bridge -> veth port --> NS veth port

Hi Peter,

looking at the ip/bridge dumps I don't see anything obviously broken so I
started by building a reproducer using two netns'en and a bridge on the
host to simulate your setup, leaving out the vlan stuff for now.

I setup two namespaces ns0/ns1 with a veth pair each connected to br0 on
the host. I assign MAC addresses statically to make looking at `bridge fdb`
easier (grep ^aa:). The script looks like this (trimmed, full version
attached):

ip netns add ns0
ip link add  veth0 type veth \
   peer name veth0 address aa:00:00:00:00:00 netns ns0

ip netns add ns1
ip link add  veth1 type veth \
   peer name veth1 address aa:00:00:00:00:01 netns ns1

ip link add br0 address aa:bb:bb:bb:bb:bb type bridge forward_delay 0
#^ forward_delay=0 to disable STP as this delays interfaces coming up
ip link set dev veth0 master br0
ip link set dev veth1 master br0

ip -n ns0 addr add 10.0.0.100/24 dev veth0
ip -n ns1 addr add 10.0.0.101/24 dev veth1

iplink set br0 up
iplink set dev veth0 up
ip -n ns0 link set dev veth0 up
iplink set dev veth1 up
ip -n ns1 link set dev veth1 up

ip -n ns0 link set dev lo up
ip -n ns1 link set dev lo up

ip netns exec ns0 ping -c4 10.0.0.101

Seems to work fine. So we can establish the basic functionality does work
and we need to go deeper.

Peter, can you confirm this script works on your system? If so the next
step is introducing vlans.

On Mon, Oct 30, 2023 at 07:25:38PM +, peter.gasparo...@orange.com wrote:
> 1) As was reported, foreign external world MAC@ does not pass into
> network namespace, just external border point "vlan199"

How did you check this?

> 2) now collecting data for you, honestly I don’t see external mac address
> on "inet-br" object, so my previous statement was incorrect.. {ossibly I
> might mixed this up with another "labinet-br" (working in its limited
> scope) which is IP-defined, while "inet-br" in question is not.
>
> 3) so question is, if the MACs learnt via vlan199 are supposed to be
> paired (displayed) with "inet-br" object and all way up into NS

I want to make sure we're on the same page, how do you check if the MAC is
reaching into the NS? I assume using `ip neigh`? I'd have a look at tcpdump
this will tell you whether ARP is even reaching the NS or not.

Something simple like

$ tcpdump -enli $IFACE 'arp or icmp'

optionally you can filter by MAC (`ether host` in pcap-filter speak):

$ tcpdump -enli $IFACE ('arp or icmp) and ether host aa:00:00:00:00:01

Oh and one last thing: please double and tripple check that a firewall
isn't interfering.

--Daniel

repro.sh
Description: Bourne shell script

signature.asc
Description: PGP signature

Bug#1055529: pdns-server: Spams journal after installation because it is configured to automatically restart

2023-11-10 Thread Chris Hofstaedtler

Hello Uwe,

* Uwe Kleine-König  [231107 22:06]:
> on installation of pdns-server the pdns.service is automatically
> started. However in my case port 53 is already bound and so it fails to
> start. (That might also happen if port 53 isn't blocked because the
> default config isn't suitable to successfully run pdns? I didn't check.)
> 
[..]
> to the journal. If you don't notice this immediately and stop the
> service this effectively spams your journal in a very short time.
> 
> IMHO the above mentioned settings are not suitable as a default for a
> distribution's package even if the default configuration worked. It
> should be an administrator's choice to configure such a behaviour.

I respectfully disagree. If users have pdns-server installed and
running, they want it restarted ASAP. This is the correct behaviour.

Now, I believe Debian's default of "start various daemons on
install" is just wrong nowadays.

For a long time there was nothing we could do in pdns-server (and
pdns-recursor) to change this without breaking existing installs,
but I'll think about passing --no-enable to dh_installsystemd.
I think this should be safe for upgrades, and new installs then need
to systemctl enable pdns-server.service explicitly.

Chris

Bug#1055755: transition: libre/rem/baresip


Am 10.11.23 um 22:34 schrieb Sebastian Ramacher:

Did you coordinate this plan with the maintainer of libre?


Not yet, but as they are copied, let's just wait for their comment.

Bug#1041248: keepass update

2023-11-10 Thread Matthias Geiger


debdiff attached, I will upload this as a delayed NMU.

best,

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

diff -Nru keepassxc-2.7.4+dfsg.1/debian/changelog 
keepassxc-2.7.6+dfsg.1/debian/changelog
--- keepassxc-2.7.4+dfsg.1/debian/changelog 2022-12-28 15:32:38.0 
+0100
+++ keepassxc-2.7.6+dfsg.1/debian/changelog 2023-11-10 19:34:47.0 
+0100
@@ -1,3 +1,22 @@
+keepassxc (2.7.6+dfsg.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * New upstream release (Closes: #1041248)
+  * Drop upstream/0001-Fix-appdata.xml-formatting.patch; this has been
+fixed upstream
+  * Drop upstream/0002-Set-password-input-field-font-correctly.-
+8732.patch; this has been fixed upstream
+  * Drop unused license paragraphs from d/copyright:
+- LGPL-3
+- BSD-3-clause
+  * Updated d/watch to version 4
+  * Updated copyright info for cmake/*.cmake files
+  * Add lintian override for no-manual-page warning
+  * Stop excuding pdf files; they are not present in the tarball anymore
+  * Version dependencies in d/control according to CMakelists.txt
+
+ -- Matthias Geiger   Fri, 10 Nov 2023 19:34:47 +0100
+
 keepassxc (2.7.4+dfsg.1-2) unstable; urgency=medium
 
   * Do not require version of Qt we built against at runtime (Closes: #1027140)
diff -Nru keepassxc-2.7.4+dfsg.1/debian/control 
keepassxc-2.7.6+dfsg.1/debian/control
--- keepassxc-2.7.4+dfsg.1/debian/control   2022-12-28 15:32:38.0 
+0100
+++ keepassxc-2.7.6+dfsg.1/debian/control   2023-11-10 19:33:38.0 
+0100
@@ -3,11 +3,11 @@
 Priority: optional
 Maintainer: Julian Andres Klode 
 Build-Depends: asciidoctor,
-   cmake,
+   cmake (>= 3.3.0),
dbus-daemon  | dbus ,
debhelper-compat (= 13),
libargon2-dev | libargon2-0-dev,
-   libbotan-2-dev,
+   libbotan-2-dev (>= 2.11.0),
libcurl4-gnutls-dev,
libminizip-dev,
libpcsclite-dev,
@@ -18,14 +18,14 @@
libusb-1.0-0-dev,
libxtst-dev,
libzxcvbn-dev,
-   qtbase5-dev,
+   qtbase5-dev (>= 5.2.0),
qtbase5-private-dev,
qttools5-dev,
qttools5-dev-tools,
xauth ,
xclip ,
xvfb ,
-   zlib1g-dev
+   zlib1g-dev (>= 1.2.0)
 Standards-Version: 4.6.2
 Homepage: https://www.keepassxc.org/
 Vcs-Git: https://salsa.debian.org/debian/keepassxc.git
diff -Nru keepassxc-2.7.4+dfsg.1/debian/copyright 
keepassxc-2.7.6+dfsg.1/debian/copyright
--- keepassxc-2.7.4+dfsg.1/debian/copyright 2022-12-28 15:32:38.0 
+0100
+++ keepassxc-2.7.6+dfsg.1/debian/copyright 2023-11-10 19:33:14.0 
+0100
@@ -1,7 +1,7 @@
 Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 Upstream-Name: KeePassXC
 Source: https://www.keepassxc.org/
-Files-Excluded: src/zxcvbn *.pdf
+Files-Excluded: src/zxcvbn
 
 Files: *
 Copyright: 2010-2015, Felix Geyer 
@@ -40,12 +40,14 @@
  Every other contributor is listed on 
https://github.com/keepassxreboot/keepassxc/graphs/contributors
 
 Files: cmake/CodeCoverage.cmake
-Copyright: 2012 - 2015, Lars Bilke
+Copyright: 2012 - 2017, Lars Bilke
+   2021 KeePassXC Team
 License: BSD-3-clause-CopyrightHolders
 
-Files: cmake/FindBotan2.cmake
-Copyright: 2018 Ribose Inc.
-License: BSD-2-clause
+Files: cmake/FindBotan.cmake
+Copyright: none
+License: public-domain
+Comment: Taken from 
https://github.com/vistle/vistle/blob/master/cmake/Modules/FindBOTAN.cmake
 
 Files: cmake/GenerateProductVersion.cmake
 Copyright: 2015 halex2005 
@@ -363,30 +365,6 @@
  ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
  POSSIBILITY OF SUCH DAMAGE.
 
-License: BSD-3-clause
- Redistribution and use in source and binary forms, with or without
- modification, are permitted provided that the following conditions
- are met:
- .
- 1. Redistributions of source code must retain the copyright
-notice, this list of conditions and the following disclaimer.
- 2. Redistributions in binary form must reproduce the copyright
-notice, this list of conditions and the following disclaimer in the
-documentation and/or other materials provided with the distribution.
- 3. The name of the author may not be used to endorse or promote products
-derived from this software without specific prior written permission.
- .
- THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
- IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
- OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
- IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
- INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
- NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;

Bug#1054657: transition: r-bioc-biocgenerics

On 2023-11-10 17:43:43 +0900, Charles Plessy wrote:
> Hi Paul and everybody,
> 
> we are finding a way to compare the R dependencies of the Bioconductor
> packages in Debian and in Bioc 3.18.  It uncovers some core packages
> introduced in Bioc 3.17, but which only start to have
> reverse-dependencies in 3.18, meaning that they are not in Debian yet
> since we did not have a reason to package them at that time.
> 
> It seems that I was too confident that no new core dependencies would be
> introduced, and I feel guilty for that.  Still I need to add that
> despite the stress on both sides, I really would like no not be told "We
> do not care about [the information you sent]" again, while "I am sorry
> but I do not see the relevance" or "I am sorry but this is not enough"
> is so much more informative and less conflictual.  I did appreciate a lot
> the care you took in expressing your criticisms in your email yesterday.

I am sorry that my terse mail crossed you the wrong way.

I am afraid that your first paragraph keeps me confused and I wonder if
we are talking past each other. For this transition we are interested in
packages that have to go through NEW since they are new (Build-)Depends
of packages involved in the r-bioc-transition. New reverse dependencies,
i.e., NEW packages that depend on packages that are part of the
transition, but are not (Build-)Depends of the current set of packages
in the archive, do not affect this transition.

Can you please clarify whether you are talking about new dependencies or
reverse dependencies above? Thanks.

Cheers
-- 
Sebastian Ramacher

Bug#1054657: transition: r-bioc-biocgenerics

Hi Paul,

Am Fri, Nov 10, 2023 at 08:39:18PM +0100 schrieb Paul Gevers:
> On 10-11-2023 11:56, Andreas Tille wrote:
> > The only new dependency we need is SparseArray.  However, we cannot
> > upload the package to new since it needs r-bioc-s4arrays (>= 1.1.6) for
> > building it.  In other words: We need to start the transition before we
> > can package SparseArray.
> 
> You're totally free use experimental for that to get SparseArray through
> NEW. I assume you don't need 100% of the transition, but only a (hopefully
> tiny) bit. So you could upload the newer version of r-bioc-biocgenerics and
> reverse depending packages up to where you need it to build SparseArray.
> ...

What about a compromise.  We start the transition, r-bioc-s4arrays is in
level 3 and given that ftpmaster might accept the new package in 3-5 days
when we ping kindly it will be available before we are in the last level.

I'd like to remind that quite some delays are caused by autopkgtest
errors on rarely used architectures.  My experience of past transitions
tells me that a single new package in the beginning will not have some
measurable effect on the total length of the transition.

Kind regards and thanks for your work as release team
   Andreas.

-- 
http://fam-tille.de

Bug#1055616: ansible-core: ansible.builtin.setup does not include facts from facter.

2023-11-10 Thread Lee Garrett


Hi Andy,

On 10.11.23 20:31, andrew bezella wrote:

On Fri, 2023-11-10 at 12:39 +0100, Lee Garrett wrote:

Hi Andrew,


hello -


On 08.11.23 22:40, andrew bezella wrote:


[...]
i was eventually able to build an updated version of bookworm's
ansible-core .deb including commit id 4b0d014.  this task was made
more difficult by the current FTBFS status of ansible-core but the
patch allowed ansible.builtin.setup to include facts from facter:


Can you elaborate please? AFAICS ansible-core builds fine in stable
and sid.


it wouldn't build in pbuilder and it shows up on the "Packages in
bookworm/amd64 which failed to build from source" page[1].  but from
the changelog it looks like you found and fixed the locale issue that i
was running up against:
ERROR: Ansible requires the locale encoding to be UTF-8; Detected None.


Indeed! I didn't notice it before because the reproducible build daemons 
apparently set a different locale than the regular build daemons. But it should 
be fixed now.




i spent a bunch of time fiddling w/pbuilder to find the "right" answer
but eventually just brute-forced it[2].  your solution is much better!

thank you for the prompt turnaround.  i would suggest/ask that the
facter fix be included in bookworm, too; the lack of expected facts can
have unexpected and significant impact on a playbook's run.


I'm working on the upload right now. It should hopefully be available in 
bookworm-proposed-updates in the next few days.




thanks again!

andy

1. https://tests.reproducible-builds.org/debian/bookworm/amd64/index_FTBFS.html
2. https://bugs.launchpad.net/ubuntu/+source/pbuilder/+bug/1947424/comments/10



Greetings,
Lee

Bug#1042406: dh-r: throws "Use of uninitialized value $dep_line in substitution" warnings with some packages

Am Fri, Nov 10, 2023 at 12:53:57AM +0530 schrieb Nilesh Patra:
> > Thanks a lot for the warning.  I'll leave the bug open as a reminder
> > and will sleep over it for a couple of nights to decide what might be
> > the best solution for the problem.
> 
> I guess it has been a little bit longer than a couple of nights since
> the bug report :)

For me a couple can be a bit more. ;-P
 
> We digressed discussing adding test depends as recommends - which was
> not the purpose of this bug or even patch. It was rather to fix a
> warning that dh-r spews sometimes and AFAICS, there is no regression.
> 
> have you thought about merging or rejecting the patch yet?

Git pull ...
I manually added the patch instead of `git am` since it did not apply
cleanly any more.

Kind regards
 Andreas.

-- 
http://fam-tille.de

Bug#1055755: transition: libre/rem/baresip

Control: tags -1 moreinfo

On 2023-11-10 17:56:31 +0100, Bastian Germann wrote:
> Package: release.debian.org
> Control: affects -1 libre
> X-Debbugs-Cc: li...@packages.debian.org
> User: release.debian@packages.debian.org
> Usertags: transition
> Severity: normal
> Control: forwarded -1 
> https://release.debian.org/transitions/html/auto-libre.html
> 
> libre, rem, and baresip are available in experimental, details on the update 
> at #967266.
> I suggest to upload libre, then rem, then baresip to unstable.
> The auto-generated Ben files of auto-libre and auto-rem are okay and
> the packages build fine but are relying on being updated together (the
> experimental baresip does not build with unstable libre/rem, while
> experimental libre/rem break baresip).

Did you coordinate this plan with the maintainer of libre?

Cheers
-- 
Sebastian Ramacher

Bug#1055699: transition: spglib

Control: tags -1 confimred

On 2023-11-10 10:42:38 +0200, Andrius Merkys wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hello,
> 
> I would like to request a transition slot for spglib
> (experimental -> unstable) due to soname bump. Current ben tracker [1]
> is OK.

Please go ahead.

Cheers
-- 
Sebastian Ramacher

Bug#1051833: python3-poetry-core: does not work, i.e. "import poetry" fails at Python prompt, without python3-pep517

2023-11-10 Thread Emmanuel Arias

Hi Dima, 

Thanks for report this.

I will try to figure out what happen here, I could not test it yet. But
poetry-core 1.0.7-2 has python3-pep517 as a B-Depends [0]. In new
versions that dependency was removed from upstream.

The thing that sounds strange for me is that installing a dependency
fixed you error. I will try to reproduce it.

[0] https://sources.debian.org/src/poetry-core/1.0.7-2~bpo11%2B1/debian/control/

Cheers,
Emmanuel


signature.asc
Description: PGP signature

Bug#1055767: release-notes and sphinx: incompatible formatting of manpage links in bookworm and trixie

2023-11-10 Thread Holger Wansing

Package: release-notes

Now that the release-notes for trixie are based on and built with Sphinx /
restructedText, we got an issue with manpage links.

The manpage links are created with the Sphinx extension "extlinks" with a line
like this

extlinks = {'url-man-stable': ('https://manpages.debian.org/trixie/%s', '%s')}

in source/conf.py.

A sentence like
"Further information about this are in :url-man-stable:`rsyslog.conf(5)`. "
leads to html output
"Further information about this are in rsyslog.conf(5). "
where "rsyslog.conf(5)" is a link to
https://manpages.debian.org/trixie/rsyslog.conf(5).

extlinks has just introduced a change, that makes it impossible to build the
release-notes on both bookworm and unstable systems, and getting the same
result with both builds.

Above example is the state of the r-n we actually have in git on Salsa, and
the gitlab CI pipelines running via Salsa are happily building like shown above.

But now looking at the Debian website, for example
https://www.debian.org/releases/testing/release-notes/issues.en.html#rsyslog-changes-affecting-log-analyzers-such-as-logcheck
you find the link to manpages.debian.org crippled, showing "%srsyslog.conf(5)"
as link text.
This is because *this* build of release-notes is happening on wolkenstein,
which is currently a Bullseye system.
wolkenstein will of course upgraded to Bookworm some time, but when Trixie
is released, wolkenstein will still be a Bookworm system, and the Sphinx
version in Bookworm suffers from the same issue as today under Bullseye.

So the situation is: with the current source code we cannot have the
release-notes
correct on the Debian website and at the same time have succeeding pipelines
on Salsa, when people are doing changes.
(If we change the source code in a way, that the links are showing up ok
on the Debian website, every r-n pipeline on Salsa will fail. See
https://salsa.debian.org/ddp-team/release-notes/-/commit/281b371e731f8abd4a0ea755eea8165e1991bad0/pipelines?ref=master
for an example of such a failure.)

Need to investigate, how to proceed here...

Holger

--
Holger Wansing
PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076

Bug#1055751: transition: wolfssl

Control: tags -1 = confirmed

On 2023-11-10 19:13:22 +0100, Bastian Germann wrote:
> Am 10.11.23 um 18:03 schrieb Sebastian Ramacher:
> > Control: tags -1 moreinfo
> > 
> > On 2023-11-10 15:57:27 +0100, Bastian Germann wrote:
> > > The auto-generated Ben file is okay and all reverse dependencies build 
> > > fine.
> > 
> > What's the status of the reverse dependencies? Do they build
> > successfully with the new version of wolfssl?
> 
> Yes, as I have written.

I should have finished with reading that sentence. Please go ahead.

Cheers
-- 
Sebastian Ramacher

Bug#1055766: ITP: python-cykhash -- cython wrapper for khash-sets/maps, efficient implementation of isin and unique

Package: wnpp
Severity: wishlist

Subject: ITP: python-cykhash -- cython wrapper for khash-sets/maps, efficient 
implementation of isin and unique
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: python-cykhash
  Version : 2.0.0
  Upstream Author : realead
* URL : https://github.com/realead/cykhash
* License : MIT
  Programming Lang: Python
  Description : cython wrapper for khash-sets/maps, efficient 
implementation of isin and unique
 Cykhash is a cython wrapper for khash-sets/maps, efficient
 implementation of isin and unique.
 .
   * Brings functionality of khash to Python and Cython and can be used
 seamlessly in numpy or pandas.
   * Numpy's world is lacking the concept of a (hash-)set. This
 shortcoming is fixed and efficient (memory- and speedwise compared
 to pandas') unique and isin are implemented.
   * Python-set/dict have big memory-footprint. For some datatypes the
 overhead can be reduced by using khash by factor 4-8.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/python-cykhash

Bug#1055765: chromium: Error: Can't open display (armhf) while other platforms (amd64, arm64, i386) are OK

2023-11-10 Thread Andres Salomon


Hi,

Can you please try other versions if possible?  
119.0.6045.123-1~deb12u1 is currently in bookworm-security. 
116.0.5845.180-1~deb12u1 is still in bookworm. It would be helpful to 
know if this is a bookworm-specific regression, since it worked on 
bullseye's 116, or something broken in general with chromium 119.


It looks like a version of 117 and 118 also successfully built for 
armhf, as other option to try:

https://snapshot.debian.org/package/chromium/118.0.5993.70-1~deb12u1/
https://snapshot.debian.org/package/chromium/117.0.5938.149-1~deb12u1/

On Fri, Nov 10 2023 at 09:49:00 PM +01:00:00, Julien Neuhart 
 wrote:

Package: chromium
Version: 119.0.6045.105-1~deb12u1

Dear maintainers,

While building with QEMU a Docker image based on Debian bookworm 
using the chromium package, I found out that the « armhf » variant 
seems broken, which is not the case for others platforms.


Indeed, after having installed chromium with:
DEBIAN_FRONTEND=noninteractive apt-get install -y -qq 
--no-install-recommends chromium


Running « chromium —version » failed on armhf (Error: Can't open 
display) while working as expected in others platform (amd64, arm64, 
i386).


Please note it is working fine in Debian 11 & package version 
116.0.5845.180.


Full installation logs may be found here: 
https://github.com/gulien/chromium/actions/runs/6829257786


armhf:

Distributor ID: Debian
Description: Debian GNU/Linux 12 (bookworm)
Release:12
Codename: bookworm
Kernel: Linux buildkitsandbox 6.2.0-1015-azure #15~22.04.1-Ubuntu SMP 
Fri Oct  6 13:20:44 UTC 2023 armv7l GNU/Linux

Architecture: armhf

chromium —version:
Error: Can't open display:

i386:

Distributor ID: Debian
Description: Debian GNU/Linux 12 (bookworm)
Release:12
Codename: bookworm
Kernel: Linux buildkitsandbox 6.2.0-1015-azure #15~22.04.1-Ubuntu SMP 
Fri Oct  6 13:20:44 UTC 2023 x86_64 GNU/Linux

Architecture: i386

chromium —version:
find: '/root/.config/chromium/Crash Reports/pending/': No such file 
or directory

Chromium 119.0.6045.123 built on Debian 12.2, running on Debian 12.2

arm64:

Distributor ID: Debian
Description: Debian GNU/Linux 12 (bookworm)
Release:12
Codename: bookworm
Kernel: Linux buildkitsandbox 6.2.0-1015-azure #15~22.04.1-Ubuntu SMP 
Fri Oct  6 13:20:44 UTC 2023 aarch64 GNU/Linux

Architecture: arm64

chromium --version:
find: '/root/.config/chromium/Crash Reports/pending/': No such file 
or directory

Chromium 119.0.6045.105 built on Debian 12.2, running on Debian 12.2

amd64:

Distributor ID: Debian
Description: Debian GNU/Linux 12 (bookworm)
Release:12
Codename: bookworm
Kernel: Linux buildkitsandbox 6.2.0-1015-azure #15~22.04.1-Ubuntu SMP 
Fri Oct  6 13:20:44 UTC 2023 x86_64 GNU/Linux

Architecture: amd64

chromium --version:
find: '/root/.config/chromium/Crash Reports/pending/': No such file 
or directory

Chromium 119.0.6045.123 built on Debian 12.2, running on Debian 12.2

Thanks,

Julien

Bug#1055347: ITA: kitty -- fast, featureful, GPU based terminal

Hi Maytham,

On Fri, Nov 10, 2023 at 05:15:22PM +0800, Maytham Alsudany wrote:
> On Thu, 2023-11-09 at 00:32 +0530, Nilesh Patra wrote:
> > * Can you please clean up some of the lintian stuff? And then we could
> >   upload the new release.
> 
> Letting you know that I've fixed the majority of lintian's errors/warnings, 
> and
> the latest report now looks like this[1].

Awesome, thank you!

> If would be good to get a second pair of eyes on my commits, since I've made
> some decisive patches.

I have removed all commits adding manpage. Furthermore you added a
compress command to dh_auto_test this would lead to installing different
manpage based on whether or not tests are run (for instance skipped via
nocheck). This is a bug, IMHO.

My personal experience is that maintainer maintained manpages are
seldom well-maintained and tend to get outdated with new versions
if the maintainer forgets to update these regularly.
Also, that manpages keep introducing new lintian warnings with new
version of troff/groff.

Since this package already requires some maintenance, I feel it would be
an additional burden on me and you. It is IMHO the best case scenario if
the upstream maintains a manpage themselves.

You may wonder that it might be possible to add a help2man directive in
d/rules to fix this problem, but then this gets the package to not be
able to cross-build and the problem with troff still remains. Go
binaries do not natively cross-build via debian way of cross-compilation
via hostarch yet but I suppose it would one day.

> If all's good, then I reckon that the new release is ready to be uploaded.

Pushed to experimental; thank you for your work! \o/

> You probably already know, but upstream released version 0.31.0 a few days 
> ago,
> which makes the version we're working on (0.30.1) outdated. I think we should 
> do
> a version bump after we upload 0.30.1 so we have a working package uploaded,
> even if it's one version old. The version bump can also act as a stability
> check, to see if the package still builds successfully when the version gets
> bumped.

Agreed, and thanks again! :D

Best,
Nilesh

signature.asc
Description: PGP signature

Bug#1055764: falcosecurity-libs: Please ship libscap and lbsinsp

2023-11-10 Thread Bálint Réczey

Control: notfound -1 0.11.3+repack-6

Sorry, they are already shipped in libfalcosecurity0.

Thanks,
Balint

On Fri, 10 Nov 2023 21:45:57 +0100 =?UTF-8?B?QsOhbGludCBSw6ljemV5?=
 wrote:
> Source: falcosecurity-libs
> Version: 0.11.3+repack-6
> Severity: wishlist
> Affects: wireshark
>
> Dear Maintainer,
>
> Please ship the shared libraries to let logray to be built and shipped
> from wireshark's source.
>
> Thanks,
> Balint
>
>

Bug#1054345: usbcore call trace

2023-11-10 Thread ael

I now seem to have captured a call trace which may be related:


INFO: task kworker/0:0:7395 blocked for more than 120 seconds.
[ 1088.815089]   Not tainted 6.5.0-3-amd64 #1 Debian 6.5.8-1
[ 1088.815093] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[ 1088.815095] task:kworker/0:0 state:D stack:0 pid:7395  ppid:2  
flags:0x4000
[ 1088.815105] Workqueue: usb_hub_wq hub_event [usbcore]
[ 1088.815183] Call Trace:
[ 1088.815186]  
[ 1088.815192]  __schedule+0x3df/0xb80
[ 1088.815205]  schedule+0x61/0xe0
[ 1088.815211]  schedule_timeout+0x98/0x160
[ 1088.815218]  ? __pfx_process_timeout+0x10/0x10
[ 1088.815227]  wait_for_completion_timeout+0x83/0x170
[ 1088.815236]  usb_start_wait_urb+0xa7/0x180 [usbcore]
[ 1088.815299]  usb_control_msg+0xef/0x150 [usbcore]
[ 1088.815359]  get_bMaxPacketSize0+0x5f/0xc0 [usbcore]
[ 1088.815410]  hub_port_init+0x418/0xff0 [usbcore]
[ 1088.815465]  hub_event+0x1207/0x1c10 [usbcore]
[ 1088.815521]  ? __schedule+0x3e7/0xb80
[ 1088.815528]  process_one_work+0x1e1/0x3f0
[ 1088.815537]  worker_thread+0x51/0x390
[ 1088.815542]  ? _raw_spin_lock_irqsave+0x27/0x60
[ 1088.815549]  ? __pfx_worker_thread+0x10/0x10
[ 1088.815554]  kthread+0xf7/0x130
[ 1088.815562]  ? __pfx_kthread+0x10/0x10
[ 1088.815570]  ret_from_fork+0x34/0x50
[ 1088.815578]  ? __pfx_kthread+0x10/0x10
[ 1088.815584]  ret_from_fork_asm+0x1b/0x30
[ 1088.815597]  
[ 1209.646327] INFO: task kworker/0:0:7395 blocked for more than 241 seconds.
[ 1209.646341]   Not tainted 6.5.0-3-amd64 #1 Debian 6.5.8-1
[ 1209.646345] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[ 1209.646348] task:kworker/0:0 state:D stack:0 pid:7395  ppid:2  
flags:0x4000
[ 1209.646363] Workqueue: usb_hub_wq hub_event [usbcore]
[ 1209.646465] Call Trace:
[ 1209.646469]  
[ 1209.646476]  __schedule+0x3df/0xb80
[ 1209.646493]  schedule+0x61/0xe0
[ 1209.646501]  schedule_timeout+0x98/0x160
[ 1209.646509]  ? __pfx_process_timeout+0x10/0x10
[ 1209.646520]  wait_for_completion_timeout+0x83/0x170
[ 1209.646532]  usb_start_wait_urb+0xa7/0x180 [usbcore]
[ 1209.646620]  usb_control_msg+0xef/0x150 [usbcore]
[ 1209.646703]  get_bMaxPacketSize0+0x5f/0xc0 [usbcore]
[ 1209.646772]  hub_port_init+0x418/0xff0 [usbcore]
[ 1209.646849]  hub_event+0x1207/0x1c10 [usbcore]
[ 1209.646925]  ? __schedule+0x3e7/0xb80
[ 1209.646935]  process_one_work+0x1e1/0x3f0
[ 1209.646946]  worker_thread+0x51/0x390
[ 1209.646954]  ? _raw_spin_lock_irqsave+0x27/0x60
[ 1209.646962]  ? __pfx_worker_thread+0x10/0x10
[ 1209.646969]  kthread+0xf7/0x130
[ 1209.646980]  ? __pfx_kthread+0x10/0x10
[ 1209.646990]  ret_from_fork+0x34/0x50
[ 1209.647002]  ? __pfx_kthread+0x10/0x10
[ 1209.647011]  ret_from_fork_asm+0x1b/0x30
[ 1209.647028]  
[ 1330.478037] INFO: task kworker/0:0:7395 blocked for more than 362 seconds.
[ 1330.478048]   Not tainted 6.5.0-3-amd64 #1 Debian 6.5.8-1
[ 1330.478052] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[ 1330.478055] task:kworker/0:0 state:D stack:0 pid:7395  ppid:2  
flags:0x4000
[ 1330.478066] Workqueue: usb_hub_wq hub_event [usbcore]
[ 1330.478149] Call Trace:
[ 1330.478152]  
[ 1330.478158]  __schedule+0x3df/0xb80
[ 1330.478172]  schedule+0x61/0xe0
[ 1330.478179]  schedule_timeout+0x98/0x160
[ 1330.478186]  ? __pfx_process_timeout+0x10/0x10
[ 1330.478196]  wait_for_completion_timeout+0x83/0x170
[ 1330.478206]  usb_start_wait_urb+0xa7/0x180 [usbcore]
[ 1330.478276]  usb_control_msg+0xef/0x150 [usbcore]
[ 1330.478342]  get_bMaxPacketSize0+0x5f/0xc0 [usbcore]
[ 1330.478397]  hub_port_init+0x418/0xff0 [usbcore]
[ 1330.478458]  hub_event+0x1207/0x1c10 [usbcore]
[ 1330.478520]  ? __schedule+0x3e7/0xb80
[ 1330.478527]  process_one_work+0x1e1/0x3f0
[ 1330.478536]  worker_thread+0x51/0x390
[ 1330.478542]  ? _raw_spin_lock_irqsave+0x27/0x60
[ 1330.478549]  ? __pfx_worker_thread+0x10/0x10
[ 1330.478555]  kthread+0xf7/0x130
[ 1330.478564]  ? __pfx_kthread+0x10/0x10
[ 1330.478572]  ret_from_fork+0x34/0x50
[ 1330.478580]  ? __pfx_kthread+0x10/0x10
[ 1330.478588]  ret_from_fork_asm+0x1b/0x30
[ 1330.478601]  

However this was on hotplugging a garmin Etrex 20 which is always very
slow and after increasing 
/sys/module/usbcore/parameters/initial_descriptor_timeout
to a very large value (60 !), so it may not be related.

Bug#1055765: chromium: Error: Can't open display (armhf) while other platforms (amd64, arm64, i386) are OK

2023-11-10 Thread Julien Neuhart

Package: chromium
Version: 119.0.6045.105-1~deb12u1

Dear maintainers,

While building with QEMU a Docker image based on Debian bookworm using the 
chromium package, I found out that the « armhf » variant seems broken, which is 
not the case for others platforms.

Indeed, after having installed chromium with:
DEBIAN_FRONTEND=noninteractive apt-get install -y -qq --no-install-recommends 
chromium

Running « chromium —version » failed on armhf (Error: Can't open display) while 
working as expected in others platform (amd64, arm64, i386).

Please note it is working fine in Debian 11 & package version 116.0.5845.180.

Full installation logs may be found here: 
https://github.com/gulien/chromium/actions/runs/6829257786

armhf:

Distributor ID: Debian 
Description: Debian GNU/Linux 12 (bookworm) 
Release:12 
Codename: bookworm 
Kernel: Linux buildkitsandbox 6.2.0-1015-azure #15~22.04.1-Ubuntu SMP Fri Oct  
6 13:20:44 UTC 2023 armv7l GNU/Linux
Architecture: armhf 

chromium —version:
Error: Can't open display:

i386:

Distributor ID: Debian 
Description: Debian GNU/Linux 12 (bookworm) 
Release:12 
Codename: bookworm 
Kernel: Linux buildkitsandbox 6.2.0-1015-azure #15~22.04.1-Ubuntu SMP Fri Oct  
6 13:20:44 UTC 2023 x86_64 GNU/Linux 
Architecture: i386

chromium —version:
find: '/root/.config/chromium/Crash Reports/pending/': No such file or 
directory 
Chromium 119.0.6045.123 built on Debian 12.2, running on Debian 12.2

arm64:

Distributor ID: Debian 
Description: Debian GNU/Linux 12 (bookworm) 
Release:12 
Codename: bookworm 
Kernel: Linux buildkitsandbox 6.2.0-1015-azure #15~22.04.1-Ubuntu SMP Fri Oct  
6 13:20:44 UTC 2023 aarch64 GNU/Linux 
Architecture: arm64 

chromium --version: 
find: '/root/.config/chromium/Crash Reports/pending/': No such file or 
directory 
Chromium 119.0.6045.105 built on Debian 12.2, running on Debian 12.2

amd64:

Distributor ID: Debian 
Description: Debian GNU/Linux 12 (bookworm) 
Release:12 
Codename: bookworm 
Kernel: Linux buildkitsandbox 6.2.0-1015-azure #15~22.04.1-Ubuntu SMP Fri Oct  
6 13:20:44 UTC 2023 x86_64 GNU/Linux
Architecture: amd64

chromium --version: 
find: '/root/.config/chromium/Crash Reports/pending/': No such file or directory
Chromium 119.0.6045.123 built on Debian 12.2, running on Debian 12.2

Thanks,

Julien

Bug#1055764: falcosecurity-libs: Please ship libscap and lbsinsp

2023-11-10 Thread Bálint Réczey

Source: falcosecurity-libs
Version: 0.11.3+repack-6
Severity: wishlist
Affects: wireshark

Dear Maintainer,

Please ship the shared libraries to let logray to be built and shipped
from wireshark's source.

Thanks,
Balint

Bug#1055763: QXL VGA does not work

2023-11-10 Thread Nikolay Kyx

Package: qemu-system-x86
Version: 8.1.2+ds-1
Severity: normal

Steps to reproduce:
$ qemu-system-x86_64 -vga help
none no graphic card
std  standard VGA (default)
cirrus   Cirrus VGA
vmware   VMWare SVGA
qemu-system-x86_64: type is NULL
qemu-system-x86_64: type is NULL
qemu-system-x86_64: type is NULL
virtio   Virtio VGA
$ qemu-system-x86_64 -vga qxl
qemu-system-x86_64: type is NULL
qemu-system-x86_64: QXL VGA not available

So I can't run my Windows VM anymore (e.g. using virt-manager).

Bug#1055347: ITA: kitty -- fast, featureful, GPU based terminal

Hi Maytham,

On Fri, Nov 10, 2023 at 01:38:05PM +0800, Maytham Alsudany wrote:
> On Thu, 2023-11-09 at 22:53 +0530, Nilesh Patra wrote:
> > > Regarding commit 7020dd5d:
> > > Are the ldflags necessary, since the binary builds fine without them set?
> > > Especially the kitty.VCSRevision option, which is only really used in 
> > > --version,
> > > as shown in this upstream commit[9].
> > 
> > I do not find any commit at [9] but rather the lintian output. I simply
> > decided to emulate the way in which upstream buildsystem would behave to
> > avoid surprises so I'd be OK with keeping it that way. LMK if you
> > disagree.
> 
> Sorry, wrong link. I meant [10]. But I don't think this applies anymore, as 
> the
> tools/cli/infrastructure.go file has been removed.
> 
> I cloned the upstream repo, built it using setup.py, and passed the build 
> option
> `--vcs-rev=VCS_REV_GOES_HERE`. After running `strings ./kitty/launchers/kitty 
> |
> grep -i VCS_REV_GOES_HERE`, and the same with the kitten binary, no mention of
> the VCS revision was found, except for the following in "kitten":
> 
> build   -ldflags="-X kitty.VCSRevision=VCS_REV_GOES_HERE"
> build   -ldflags="-X kitty.VCSRevision=VCS_REV_GOES_HERE"
> 
> So I don't think it matters whether we pass the VCSRevision in ldlags or not,
> nor what value we pass, since it's not being used.
> 
> I agree with passing the other ldflags though, in order to emulate setup.py 
> and
> the upstream buildsystem.
> 
> Forgive me for overemphasizing this, but I wanted to get to the bottom of 
> this.

No worries, thank you for pushing this. I am convinced that this serves
no real purpose so I removed in from d/rules.

> > That said I do see a directive to "/usr/bin/env python3" in specific
> > files for instance in "kittens/tui/handler.py" "kitty/fonts/render.py"
> > but not in others. IMHO we should ask upstream to maintain uniformity by
> > fixing this.
> 
> I agree. Should we open an issue and/or PR upstream?

Yes, if you could open an issue, it'd be nice!

> I'm fine with that. You've got more experience, whereas this is my first time
> contributing to a Debian package, so I reckon you should be the "Maintainer" 
> of
> the package, if you're fine with it.

It is hard for me to believe that you are contributing to debian package
for the first time, as all your contributions seem to be of high quality
which is not something I see in newcomers, so kudos for that!

> Just a thought: should we get the Python and Golang teams involved, since both
> programming langs are being used and both dh buildsystems are being used?

As such no, all packages in the debian/ namespace as such belong to a
particular language and we will keep involving maintainer teams for all
such packages.
IMHO there's nothing these two teams would do
together for such a package, and I'm (very) active in both the teams
so I say this with some confidence :)

> > > Perhaps splitting up the kitty and kittens components into separate
> > > folders/repos? Or make it so that these components can build 
> > > independently of
> > > each other (setup.py builds kitty only, `go build` builds kittens only)?
> > 
> > Yes, I agree. While I was doing the work of making the go part work, I
> > felt that it'd indeed be more sensible if "kitten" was a separate repo
> > altogether.
> 
> Should we bring this up on upstream's issue tracker?

Absolutely!

> Another option would be to split the repos ourselves on GitHub (under the 
> Debian
> org), which requires more work on our part but is more likely to get the
> upstream author to accept our proposal:
>  1. Fork github.com/kovidgoyal/kitty to github.com/debian/kitty

As such I don't think the debian namespace has got anything to do with
this. You could just fork it to your own :)

>  2. Remove all "kitten" components from the fork
>  3. Create github.com/debian/kitten and move all the Golang "kitten" 
> components
> to it
>  4. Open a PR to merge debian/kitty to kovidgoyal/kitty
>  5. In the PR, offer to transfer ownership of debian/kitten (or let the 
> upstream
> author just copy/fork it themselves)

I think this is a little hurried and upstream may not even want
something like that. I suppose it'd be more sensible to first *ask* the
upstream as to what they think about the concerns and we can go about
sending patches once we reach some concensus.

> > > > > [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037440#37
> > > > > [2]: https://salsa.debian.org/Maytha8/kitty-dh-golang
> > > > > [3]: https://salsa.debian.org/Maytha8/kitty
> > > > > [4]: 
> > > > > https://src.fedoraproject.org/rpms/kitty/blob/rawhide/f/kitty.spec#_268
> > > > [5]: 
> > > > https://salsa.debian.org/debian/kitty/-/tree/debian/experimental?ref_type=heads
> > > [6]:
> > > https://salsa.debian.org/debian/kitty/-/blob/15a00c9b73f1008520c49f8c795f3bada3eed171/setup.py#L972
> > > [7]:
> > >

Bug#1055759: tcl-tls: EOF's are sometimes treated as errors

2023-11-10 Thread Jeremy Sowden

On 2023-11-10, at 18:39:10 +, Jeremy Sowden wrote:
> Package: tcl-tls
> Version: 1.7.22-3+b1
> Severity: normal
> Tags: patch upstream
> 
> OpenSSL 3.0 introduced a new option `SSL_OP_IGNORE_UNEXPECTED_EOF`.  If
> this is not set, it handles unexpected EOF's as fatal errors.  Since
> TclTLS does not currently set it, some EOF's are treated as errors.  I
> have reported this upstream here:
> 
>   
> https://core.tcl-lang.org/tcltls/tktview/c5811f0d433d34ca16ccecdec10fb61e2f3ba657
> 
> I've attached the patch I proposed in the upstream bug report.  I'll add
> some DEP-3 metadata and create an MR against the tcltls Salsa repo.

Having given this a bit more thought (and looked into why openssl added
this option), I think that the patch needs a bit more work.  The openssl
s_client command, for example, has a command-line option to control this
behaviour.

J.


signature.asc
Description: PGP signature

Bug#1055762: ITP: botan3 -- multiplatform crypto library (3.x version)

2023-11-10 Thread GCS

Package: wnpp
Severity: wishlist
Owner: Laszlo Boszormenyi (GCS) 

* Package name: botan
  Version : 3.2.0
  Upstream Author : The Botan Authors
* URL : https://botan.randombit.net/
* License : BSD-2-clause
  Programming Lang: C++
  Description : multiplatform crypto library (3.x version)

Botan is a C++ library which provides support for many common cryptographic
operations, including encryption, authentication, and X.509v3 certificates and
CRLs. A wide variety of algorithms is supported, including RSA, DSA, DES, AES,
MD5, and SHA-1.

Bug#1055228: plplot: FTBFS on armhf (test segfault)

2023-11-10 Thread Rafael Laboissière


* Rafael Laboissière  [2023-11-09 17:11]:


[snip]

There may be a programming error in x09f.f90 or this may be a problem 
with gfortran on armhf. My knowledge of Fortran is almost non existent 
and I will need the help of experts, in order to fix the issue.


Regarding this issue, I filed a bug against the gfortran package: 
https://bugs.debian.org/1055750


Best,

Rafael Laboissière

Bug#1055616: ansible-core: ansible.builtin.setup does not include facts from facter.

2023-11-10 Thread andrew bezella

On Fri, 2023-11-10 at 12:39 +0100, Lee Garrett wrote:
> Hi Andrew,

hello -

> On 08.11.23 22:40, andrew bezella wrote:
> 
> > [...]
> > i was eventually able to build an updated version of bookworm's
> > ansible-core .deb including commit id 4b0d014.  this task was made
> > more difficult by the current FTBFS status of ansible-core but the
> > patch allowed ansible.builtin.setup to include facts from facter:
> 
> Can you elaborate please? AFAICS ansible-core builds fine in stable
> and sid.

it wouldn't build in pbuilder and it shows up on the "Packages in
bookworm/amd64 which failed to build from source" page[1].  but from
the changelog it looks like you found and fixed the locale issue that i
was running up against:
   ERROR: Ansible requires the locale encoding to be UTF-8; Detected None.

i spent a bunch of time fiddling w/pbuilder to find the "right" answer
but eventually just brute-forced it[2].  your solution is much better!

thank you for the prompt turnaround.  i would suggest/ask that the
facter fix be included in bookworm, too; the lack of expected facts can
have unexpected and significant impact on a playbook's run.

thanks again!

andy

1. https://tests.reproducible-builds.org/debian/bookworm/amd64/index_FTBFS.html
2. https://bugs.launchpad.net/ubuntu/+source/pbuilder/+bug/1947424/comments/10

-- 
andrew bezella 
internet archive

Bug#1054657: transition: r-bioc-biocgenerics

2023-11-10 Thread Paul Gevers


Hi,

On 10-11-2023 11:56, Andreas Tille wrote:

The only new dependency we need is SparseArray.  However, we cannot
upload the package to new since it needs r-bioc-s4arrays (>= 1.1.6) for
building it.  In other words: We need to start the transition before we
can package SparseArray.


You're totally free use experimental for that to get SparseArray through 
NEW. I assume you don't need 100% of the transition, but only a 
(hopefully tiny) bit. So you could upload the newer version of 
r-bioc-biocgenerics and reverse depending packages up to where you need 
it to build SparseArray.


Alternatively, you can send packages to NEW that you build with locally 
newer versions (however you create them). Once accepted, the buildds 
will only build the non-uploaded archs once the right version becomes 
available. In other words, uploads to NEW don't require all their build 
dependencies already (at the right version) in Debian. We need to 
rebuild that package anyways to make it eligible for migration, so an 
(maybe from your perspective) early upload is not more waste of time 
with the current archive settings, but of course the preparation in 
experimental is a bit more work from your side. However, that's what we 
request in nearly all transitions: prepare as much as possible *before* 
we actually start the transition.


On 09-11-2023 14:59, Charles Plessy wrote:

But if this is important for you we can
surely write ack messages faster.
I'm convinced it would help. Having said that, that doesn't need to be 
long proza, mostly a sign "we're on top of this and that". (Which 
doesn't mean you have to work 24/7 to fix it, of course you are also a 
volunteer). When we know what's on your radar, we can also more 
effectively point at potential gaps that we may spot.



This is what I feel when I see the new request from your team coming
at the last minute and not as a debriefing of the previous
transition.
I'm sorry to hear that it felt like a new request. I think for us it 
felt more like "lets treat this more like we do other transitions". And 
yes, maybe we should do debriefings once in a while, but we are not 
accustomed to do that and I believe that in the cases that would benefit 
most from a debriefing those involved rather want to move on.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1055761: python3-selenium: WebKit/RemoteWebDriver init skew

2023-11-10 Thread Aaron M. Ucko

Package: python3-selenium
Version: 4.14.0+dfsg-1
Severity: normal
Tags: upstream

python3-selenium's WebKitGTK and WPEWebKit backends are both unusable
even when supplied explicit executable paths to keep them from trying
to go through the (understandably) unpackaged driver manager, because
*WebKit*WebDriver.__init__ both call super().__init__ with an
unsupported desired_capabilities argument (where super() amounts to
RemoteWebDriver).  With WebKitGTK, for instance, I get

  Traceback (most recent call last):
[...]
File 
"/usr/lib/python3/dist-packages/selenium/webdriver/webkitgtk/webdriver.py", 
line 66, in __init__
  super().__init__(
  TypeError: WebDriver.__init__() got an unexpected keyword argument 
'desired_capabilities'

Could you please take a look?

Thanks!

-- System Information:
Debian Release: trixie/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'stable-security'), (500, 
'stable-debug'), (500, 'proposed-updates-debug'), (500, 'oldstable-security'), 
(500, 'testing'), (300, 'unstable-debug'), (300, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, x32

Kernel: Linux 6.5.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
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 python3-selenium depends on:
ii  python3 3.11.4-5+b1
ii  python3-certifi 2023.7.22-1
ii  python3-trio0.22.2-1
ii  python3-trio-websocket  0.11.1-1
ii  python3-urllib3 1.26.18-1

Versions of packages python3-selenium recommends:
ii  chromium-driver  119.0.6045.123-1

python3-selenium suggests no packages.

-- debconf-show failed

Bug#1052803: golang-github-gosexy-gettext: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && go test -vet=off -v -p 8 github.com/gosexy/gettext returned exit code 1

2023-11-10 Thread Mathias Gibbens

  I have uploaded a fix for this as a NMU to the DELAYED/10 queue. A
diff of the changes is attached.

Mathias
diff --git a/debian/changelog b/debian/changelog
index ef627bd..3c5bb15 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+golang-github-gosexy-gettext (0~git20130221-2.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Run tests with LC_ALL=en_US.utf8 (Closes: #1052803)
+
+ -- Mathias Gibbens   Fri, 10 Nov 2023 19:12:55 +
+
 golang-github-gosexy-gettext (0~git20130221-2.1) unstable; urgency=medium
 
   [ Dr. Tobias Quathamer ]
diff --git a/debian/control b/debian/control
index d1364e1..414b835 100644
--- a/debian/control
+++ b/debian/control
@@ -5,6 +5,7 @@ Maintainer: Steve Langasek 
 Build-Depends: debhelper (>= 11~),
dh-golang,
golang-any,
+   locales-all
 Standards-Version: 4.2.1
 Homepage: https://github.com/gosexy/gettext
 XS-Go-Import-Path: github.com/gosexy/gettext
diff --git a/debian/rules b/debian/rules
index 2d9b72c..1451b07 100755
--- a/debian/rules
+++ b/debian/rules
@@ -20,7 +20,7 @@ override_dh_auto_build:
rm obj-*/src/github.com/gosexy/gettext/examples/*/*.pot
 
 override_dh_auto_test:
-   LC_ALL=C.UTF-8 dh_auto_test
+   LC_ALL=en_US.utf8 dh_auto_test
 
 get-orig-source:
rm -rf $(PKG)

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

Bug#1055625: pyzoltan: FTBFS (not enough slots available)

2023-11-10 Thread Santiago Vila


tags 1055625 + patch
thanks

Ok, thanks to the fact that the package is reproducible, I've just
checked that the package builds the same regardless of NPROCS
being set to 1 or 2 in debian/rules.

Therefore, we can build it using NPROCS = 1 for everybody,
and nothing is lost. As I said before, this is a small
package and there is no real benefit by running the
tests in parallel.

Proposed patch follows.

Thanks.--- a/debian/rules
+++ b/debian/rules
@@ -4,7 +4,8 @@ export DEB_BUILD_MAINT_OPTIONS=hardening=+all
 export USE_TRILINOS=1
 export ZOLTAN_INCLUDE=/usr/include/trilinos
 export ZOLTAN_LIBRARY=/usr/lib
-NPROCS?=2
+
+NPROCS = 1
 export NPROCS
 
 export PYBUILD_NAME=pyzoltan

Bug#1055665: usr-is-merged: prevents upgrade of unstable chroot and install of usrmerge

On Thu, Nov 09, 2023 at 09:12:57PM +0100, Marco d'Itri wrote:
> Duplicate of #1055413.

Did you perhaps mean #1055066 (usrmerge: Cannot update to version 38 on
sbuild) that one describes exactly the issue I was seeing.

--Daniel


signature.asc
Description: PGP signature

Bug#1055556: RFS: diff-pdf-wx/0.5.1-1 [ITP] -- Simple tool for visually comparing two PDF files

2023-11-10 Thread Boyuan Yang

Control: tags -1 +moreinfo

On Wed, 8 Nov 2023 07:29:32 + 陈 晟祺  wrote:
> Package: sponsorship-requests
> Severity: wishlist
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "diff-pdf-wx":
> 
> * Package name : diff-pdf-wx
> Version : 0.5.1-1
> Upstream contact : vac...@slavik.io
> * URL : https://vslavik.github.io/diff-pdf/
> * License : GPL-2, LGPL-2.1+
> * Vcs : https://salsa.debian.org/harry/diff-pdf-wx
> Section : utils
> 
> The source builds the following binary packages:
> 
> diff-pdf-wx - Simple tool for visually comparing two PDF files
> 
> To access further information about this package, please visit the following 
> URL:
> 
> https://mentors.debian.net/package/diff-pdf-wx/
> 
> Alternatively, you can download the package with 'dget' using this command:
> 
> dget -x 
> https://mentors.debian.net/debian/pool/main/d/diff-pdf-wx/diff-pdf-wx_0.5.1-1.dsc
> 
> Changes for the initial release:
> 
> diff-pdf-wx (0.5.1-1) unstable; urgency=medium
> .
> * Initial packging for upstream version 0.5.1 (closes: #1055543).
> 
> You may also find my git repo at:
> 
> https://salsa.debian.org/harry/diff-pdf-wx

Three issues:

* Please verify whether the project is mainly GPL-2.0-only or GPL-2.0-or-later.
I see that most of the source code files mention "or later" in their header 
files.
Please use SPDX license identifiers to avoid confusions.

* All copyright holders should be listed in debian/copyright. I believe your 
current
version is missing those holders shown in some source code comments.

* Please do not disable autoreconf whenever possible. This helps ensure the 
support of
future hardware architectures that are not present in the old configure 
scripts, e.g.
loong64 or riscv64. If autoreconf fails -- please contact upstream to fix it or 
do
some patches.

Thanks,
Boyuan Yang

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

Bug#1055760: debian-policy,dpkg: Please document maintscript flow with `prerm deconfigure`

2023-11-10 Thread Niels Thykier


Package: debian-policy,dpkg
Severity: wishlist
X-Debbugs-Cc: ni...@thykier.net,debian-d...@lists.debian.org

Hi

The flow charts at 
https://www.debian.org/doc/debian-policy/ap-flowcharts.html 
unfortunately does not cover the `prerm deconfigure [...]`


This makes it hard to figure whether a package needs to consider 
`deconfigure` when it needs to have `prerm` code.


Like if a `prerm deconfigure` will be followed by a `prerm remove` then 
doing anything in `prerm deconfigure` is basically redundant (?) as you 
can just do it in `prerm remove` instead. Or does `deconfigure` imply a 
`remove` (despite the name suggesting it would only move the package to 
"configured -> unpacked")


This would also be relevant to understand whether postinst need to react 
to `abort-deconfigure` or can one assume that a `configure` will always 
(timely) follow an `abort-deconfigure`?


I had a look at `deb-prerm` and `deb-postinst`. Sadly, these does not 
answer my questions (they say when the action occurs). However, I am 
missing an overview and the terse descriptions do not give me that (nor 
tell me what state the package is in after success/failure, which could 
have helped in some cases).


Best regards,
Niels

PS: In debhelper, I have liberally sprinkled in `abort-*` cases in to 
the postinst and avoided any conditions in the prerm scripts. But it is 
not out of understanding but out of assumptions.

Bug#1055665: usr-is-merged: prevents upgrade of unstable chroot and install of usrmerge)

On Fri, Nov 10, 2023 at 05:51:05PM +, Luca Boccassiwrote:
> Please stop playing ping-pong with the bug tracker. It's already been
> explained to you what you need to do.

Luca, thanks your response. However I would appreciate it if we could just
simply let a discussion come to a conclusion before slamming it shut on a
whim. Doing so is just bad manners and doesn't contribute to making Debian
better. Thanks.

After some more poking I found /etc/unsupported-skip-usrmerge-conversion
somhow got created in this chroot and removing it seems to have helped to
allow usrmerge to be installed but I'm still not happy about the fact that
manual intervention is needed here.

I might have tracked down why/how this got created how to do better here
but given the lack of tact displayed by the both of you I really just don't
feel like it.

Please do consider being a bit more friendly in the future, such
short/harsh responses really aren't conducive to encouraging people to
contribute to making Debian better for all of us.

Thanks,
--Daniel

signature.asc
Description: PGP signature

Bug#1055759: tcl-tls: EOF's are sometimes treated as errors

2023-11-10 Thread Jeremy Sowden

Package: tcl-tls
Version: 1.7.22-3+b1
Severity: normal
Tags: patch upstream

OpenSSL 3.0 introduced a new option `SSL_OP_IGNORE_UNEXPECTED_EOF`.  If
this is not set, it handles unexpected EOF's as fatal errors.  Since
TclTLS does not currently set it, some EOF's are treated as errors.  I
have reported this upstream here:

  
https://core.tcl-lang.org/tcltls/tktview/c5811f0d433d34ca16ccecdec10fb61e2f3ba657

I've attached the patch I proposed in the upstream bug report.  I'll add
some DEP-3 metadata and create an MR against the tcltls Salsa repo.

-- System Information:
Debian Release: trixie/sid
  APT prefers testing-debug
  APT policy: (990, 'testing-debug'), (990, 'testing'), (900, 
'stable-updates'), (900, 'stable-security'), (900, 'stable-debug'), (900, 
'stable'), (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 
'oldstable-debug'), (500, 'oldstable'), (99, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages tcl-tls depends on:
ii  libc6   2.37-12
ii  libssl3 3.0.11-1
ii  libtcl8.6 [libtcl]  8.6.13+dfsg-2

tcl-tls recommends no packages.

tcl-tls suggests no packages.

-- no debconf information
--- a/tls.c
+++ b/tls.c
@@ -1214,6 +1214,9 @@
 SSL_CTX_set_app_data( ctx, (VOID*)interp); /* remember the interpreter */
 SSL_CTX_set_options( ctx, SSL_OP_ALL); /* all SSL bug workarounds */
 SSL_CTX_set_options( ctx, off);/* all SSL bug workarounds */
+#ifdef SSL_OP_IGNORE_UNEXPECTED_EOF
+SSL_CTX_set_options( ctx, SSL_OP_IGNORE_UNEXPECTED_EOF);
+#endif
 SSL_CTX_sess_set_cache_size( ctx, 128);
 
 if (ciphers != NULL)

Bug#967845: yersinia: depends on deprecated GTK 2


Am 12.08.23 um 04:17 schrieb Bastian Germann:

Please build with configure --disable-gtk and drop the build dependency.


I am uploading a NMU to DELAYED/10 in order to fix this.
Please find the debdiff attached.diff -Nru yersinia-0.8.2/debian/changelog yersinia-0.8.2/debian/changelog
--- yersinia-0.8.2/debian/changelog 2020-10-06 01:42:32.0 +0200
+++ yersinia-0.8.2/debian/changelog 2023-11-10 16:14:01.0 +0100
@@ -1,3 +1,13 @@
+yersinia (0.8.2-2.2) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Replace source URLs, closes: #1055738
+
+  [ Vagrant Cascadian ]
+  * Avoid embedding build path, closes: #1021512
+
+ -- Bastian Germann   Fri, 10 Nov 2023 16:14:01 +0100
+
 yersinia (0.8.2-2.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru yersinia-0.8.2/debian/control yersinia-0.8.2/debian/control
--- yersinia-0.8.2/debian/control   2020-10-06 01:42:32.0 +0200
+++ yersinia-0.8.2/debian/control   2023-11-10 16:14:01.0 +0100
@@ -2,9 +2,9 @@
 Section: admin
 Priority: optional
 Maintainer: Noël Köthe 
-Build-Depends: debhelper (>= 9.0.0), dh-autoreconf, libncurses5-dev (>=5.4), 
libnet1-dev (>=1.1.2), libpcap0.8-dev, libgtk2.0-dev, lsb-release
+Build-Depends: debhelper (>= 9.0.0), dh-autoreconf, libncurses5-dev (>=5.4), 
libnet1-dev (>=1.1.2), libpcap0.8-dev, libglib2.0-dev
 Standards-Version: 4.1.0
-Homepage: http://www.yersinia.net/
+Homepage: https://github.com/tomac/yersinia
 
 Package: yersinia
 Architecture: any
diff -Nru yersinia-0.8.2/debian/copyright yersinia-0.8.2/debian/copyright
--- yersinia-0.8.2/debian/copyright 2016-07-03 19:26:37.0 +0200
+++ yersinia-0.8.2/debian/copyright 2023-11-10 16:14:01.0 +0100
@@ -2,9 +2,7 @@
 Raphael Enrici  on Wed,  1 Mar 2006 21:47:00 +0100
 Noël Köthe  on Wed, 30 Oct 2013 18:53:19 +0100
 
-It was downloaded from
-http://yersinia.sf.net/
-http://www.yersinia.net/download/
+Source: https://github.com/tomac/yersinia
 
 Upstream authors (contents of AUTHORS file):
- Alfredo Andres Omella 
diff -Nru yersinia-0.8.2/debian/patches/gcc10.patch 
yersinia-0.8.2/debian/patches/gcc10.patch
--- yersinia-0.8.2/debian/patches/gcc10.patch   2020-10-05 05:26:28.0 
+0200
+++ yersinia-0.8.2/debian/patches/gcc10.patch   2023-11-10 16:14:01.0 
+0100
@@ -44,18 +44,17 @@
  
  void   protocol_init(void);
  int8_t protocol_register(u_int8_t, const char *, const char *, const char *,
 a/src/gtk-gui.c
-+++ b/src/gtk-gui.c
-@@ -70,6 +70,9 @@
- #include "gtk-interface.h"
- #include "gtk-support.h"
+--- a/src/ncurses-gui.c
 b/src/ncurses-gui.c
+@@ -93,6 +93,8 @@
+ #include "ncurses-interface.h"
+ #include "ncurses-callbacks.h"
  
 +u_int8_t pointer[MAX_PROTOCOLS];
 +
-+
- void
- gtk_gui (void *args)
- {
+ /*
+  * Initialization routines for the GUI
+  */
 --- a/src/interfaces.c
 +++ b/src/interfaces.c
 @@ -102,7 +102,7 @@
diff -Nru yersinia-0.8.2/debian/rules yersinia-0.8.2/debian/rules
--- yersinia-0.8.2/debian/rules 2017-09-17 21:00:46.0 +0200
+++ yersinia-0.8.2/debian/rules 2023-11-10 16:14:01.0 +0100
@@ -16,6 +16,8 @@
 DPKG_EXPORT_BUILDFLAGS = 1
 include /usr/share/dpkg/buildflags.mk
 CFLAGS = -Wall -g
+# Avoid embedding build path for reproducible builds
+CFLAGS += -ffile-prefix-map=$(CURDIR)=.
 
 config.status:
dh_testdir
@@ -24,6 +26,7 @@
CFLAGS="$(CFLAGS)" ./configure --host=$(DEB_HOST_GNU_TYPE) \
--build=$(DEB_BUILD_GNU_TYPE) \
--prefix=/usr \
+   --disable-gtk \
--mandir=\$${prefix}/share/man \
--infodir=\$${prefix}/share/info
 
@@ -37,7 +40,7 @@
dh_testdir
 
# Add here commands to compile the package.
-   $(MAKE)
+   $(MAKE) CFLAGS="$(CFLAGS)"
#docbook-to-man debian/yersinia.sgml > yersinia.1
 
touch build-stamp
diff -Nru yersinia-0.8.2/debian/watch yersinia-0.8.2/debian/watch
--- yersinia-0.8.2/debian/watch 2016-07-02 19:13:15.0 +0200
+++ yersinia-0.8.2/debian/watch 2023-11-10 16:14:01.0 +0100
@@ -1,2 +1,2 @@
-version=3
-http://www.yersinia.net/download/yersinia-(.*)\.tar\.gz
+version=4
+https://github.com/tomac/yersinia/tags .*/tags/v(.+)\.tar\.gz

Bug#1055751: transition: wolfssl


Am 10.11.23 um 18:03 schrieb Sebastian Ramacher:

Control: tags -1 moreinfo

On 2023-11-10 15:57:27 +0100, Bastian Germann wrote:

The auto-generated Ben file is okay and all reverse dependencies build fine.


What's the status of the reverse dependencies? Do they build
successfully with the new version of wolfssl?


Yes, as I have written.

Bug#1055758: opensmtpd: OpenSMTPD release in stable (bookworm) is useless due to #1037359

2023-11-10 Thread Mike Swanson

Package: opensmtpd
Version: 6.8.0p2-4+b4
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: mikeonthecompu...@gmail.com

Dear Maintainer,

Due to the bug mentioned in the subject (#1037359), OpenSMTPD fails to utilize
TLS certificates with OpenSSL >= 3.0.0.  As such, the program is a total
non-starter for any internet-facing mail solution (perhaps an internal mail
server without encryption would be fine).  While the issue has been resolved
upstream and in the sid and trixie repositories, it remains unusable in
bookworm.

Even if the resolution is to upgrade the version in bookworm (normally a
violation of Debian policy, I know), it would at least restore the package
to a fully-functional state, as it is on both bullseye and trixie.

-- System Information:
Debian Release: 12.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: arm64 (aarch64)

Kernel: Linux 6.1.0-13-cloud-arm64 (SMP w/2 CPU threads)
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 opensmtpd depends on:
ii  adduser3.134
ii  debconf [debconf-2.0]  1.5.82
ii  ed 1.19-1
ii  init-system-helpers1.65.2
ii  libc6  2.36-9+deb12u3
ii  libcrypt1  1:4.4.33-2
ii  libdb5.3   5.3.28+dfsg2-1
ii  libevent-2.1-7 2.1.12-stable-8
ii  libpam0g   1.5.2-6+deb12u1
ii  libssl33.0.11-1~deb12u2
ii  sysvinit-utils [lsb-base]  3.06-4
ii  zlib1g 1:1.2.13.dfsg-1

Versions of packages opensmtpd recommends:
ii  opensmtpd-extras  6.7.1-2

Versions of packages opensmtpd suggests:
ii  ca-certificates  20230311

-- Configuration Files:
/etc/smtpd.conf changed [not included]

-- debconf information excluded

Bug#1055745: [INTL:sv] Swedish strings for atftp debconf

2023-11-10 Thread Anders Jonsson


Hi Martin,
did some simple typo fixes in the translation.

Regards,
Anders

# Translation of atftp debconf template to Swedish
# Copyright (C) 2008-2023 Martin Bagge 
# This file is distributed under the same license as the atfp package.
#
# Martin Bagge , 2008, 2023
msgid ""
msgstr ""
"Project-Id-Version: atftp 0.7-9\n"
"Report-Msgid-Bugs-To: at...@packages.debian.org\n"
"POT-Creation-Date: 2022-02-11 12:31+0100\n"
"PO-Revision-Date: 2023-11-10 14:53+0100\n"
"Last-Translator: Martin Bagge \n"
"Language-Team: Swedish \n"
"Language: sv\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: string
#. Description
#: ../atftpd.templates:1001
msgid "Server timeout:"
msgstr "Tid till avslut:"

#. Type: string
#. Description
#: ../atftpd.templates:1001
msgid "How many seconds the main thread waits before exiting."
msgstr "Hur många sekunder huvudtråden väntar innan den avslutas."

#. Type: string
#. Description
#: ../atftpd.templates:2001
msgid "Retry timeout:"
msgstr "Tid mellan försök:"

#. Type: string
#. Description
#: ../atftpd.templates:2001
msgid "How many seconds to wait for a reply before retransmitting a packet."
msgstr ""
"Hur många sekunder vi väntar på ett svar innan vi skickar paketet igen."

#. Type: string
#. Description
#: ../atftpd.templates:3001
msgid "Maximum number of threads:"
msgstr "Maximalt antal trådar:"

#. Type: string
#. Description
#: ../atftpd.templates:3001
msgid "Maximum number of concurrent threads that can be running."
msgstr "Maximalt antal trådar som kan köras parallellt."

#. Type: select
#. Description
#: ../atftpd.templates:4001
msgid "Verbosity level:"
msgstr "Förklaringsnivå:"

#. Type: select
#. Description
#: ../atftpd.templates:4001
msgid ""
"Level of logging. 7 logs everything including debug logs. 1 will log only "
"the system critical logs. 5 (LOG_NOTICE) is the default value."
msgstr ""
"Hur informativ loggarna är. 7 loggar allt. 1 loggar bara systemkritiska "
"meddelanden. 5 (LOG_NOTICE) är standardvärdet."

#. Type: boolean
#. Description
#: ../atftpd.templates:5001
msgid "Enable 'timeout' support?"
msgstr "Aktivera 'timeout' stöd?"

#. Type: boolean
#. Description
#: ../atftpd.templates:6001
msgid "Enable 'tsize' support?"
msgstr "Aktivera 'tsize' stöd?"

#. Type: boolean
#. Description
#: ../atftpd.templates:7001
msgid "Enable 'blksize' support?"
msgstr "Aktivera 'block size' stöd?"

#. Type: boolean
#. Description
#: ../atftpd.templates:8001
msgid "Enable 'windowsize' support?"
msgstr "Aktivera 'windowsize' stöd?"

#. Type: boolean
#. Description
#: ../atftpd.templates:9001
msgid "Enable multicast support?"
msgstr "Aktivera multicast stöd?"

#. Type: string
#. Description
#: ../atftpd.templates:10001
msgid "TTL for multicast packets:"
msgstr "TTL för multicast-paket"

#. Type: string
#. Description
#: ../atftpd.templates:11001
msgid "Port to listen for tftp request:"
msgstr "Port för att lyssna på tftp-anslutningar:"

#. Type: string
#. Description
#: ../atftpd.templates:12001
msgid "Port range for multicast file transfer:"
msgstr "Portrymd för multicast-överföringar:"

#. Type: string
#. Description
#: ../atftpd.templates:12001
msgid ""
"Multicast transfer will use any available port in a given set. For example, "
"\"2000-2003, 3000\" allow atftpd to use port 2000 to 2003 and 3000."
msgstr ""
"Multicast-överföring kommer att använda de tillgängliga portar som angivits. "
"Till exempel, \"2000-2003, 3000\" kommer atftpd att använda portarna 2000 "
"till 2003 och 3000."

#. Type: string
#. Description
#: ../atftpd.templates:13001
msgid "Address range for multicast transfer:"
msgstr "Adressrymd för multicast-överföring:"

#. Type: string
#. Description
#: ../atftpd.templates:13001
msgid ""
"Multicast transfer will use any available addresses from a given set of "
"addresses. Syntax is \"a.b.c.d-d,a.b.c.d,...\""
msgstr ""
"Multicast-överföring kommer att använda adresser ur adressrymden som "
"specificeras enligt följande, \"a.b.c.d-d,a.b.c.d,...\""

#. Type: boolean
#. Description
#: ../atftpd.templates:14001
msgid "Log to file instead of journal/syslog?"
msgstr "Logga till fil istället för journal/syslog?"

#. Type: string
#. Description
#: ../atftpd.templates:15001
msgid "Log file:"
msgstr "Loggfil:"

#. Type: string
#. Description
#: ../atftpd.templates:15001
msgid ""
"A file where atftpd will write its logs. This file will be made writable for "
"the user 'nobody' and group 'nogroup'."
msgstr ""
"Filen som atftpd skriver sin logg till. Filen kommer att vara skrivbar av "
"användaren 'nobody' och gruppen 'nogroup'."

#. Type: string
#. Description
#: ../atftpd.templates:16001
msgid "Base directory:"
msgstr "Hemkatalog:"

#. Type: string
#. Description
#: ../atftpd.templates:16001
msgid ""
"The directory tree from where atftpd can serve files. That directory must be "
"world readable."
msgstr ""
"Katalogträdet med filer som atftpd erbjuder. Katalogen måste vara läsbar av "
"alla."

Bug#1055753: debci: --config option is broken

2023-11-10 Thread Christian Kastner

Hi Antonio,

On 2023-11-10 18:10, Antonio Terceiro wrote:
> Some shared options are defined in lib/environment.sh, I think that's
> why it currently loads lib/environment.sh before processing the command
> line options.
> 
> OTH your analysis is correct, as this causes the --config option to be
> useless. A solution to this would be to break the common options into
> their own file, include that in the scripts, call getopt, process
> --config before anything else, then load lib/environment.sh for default
> values, and only then process the rest of the options.

unless I'm misreading something badly, both default values *and* option
processing are in lib/environment.sh -- it's just that getopt is called
somewhat after some defaults have been set, like config_dir, arch, etc.

My gut says moving getopt to the top of lib/environment.sh would fix
this, but its current position seemed like a deliberate choice, so I
assumed I was missing something.

Best,
Christian

Bug#1055740: ITP: golang-github-humanlogio-humanlog -- Logs for humans to read.

2023-11-10 Thread Jongmin Kim

Hi again, Maytham o/

On Fri, 10 Nov 2023 at 22:45, Maytham Alsudany  wrote:
> This is a dependency of the upcoming lazygit package, and I intend to maintain
> it within the Debian Go Packaging team.

Because you mentioned the lazygit as a packaging purpose, I am sending
this mail.

Although this mail **does not follow Debian procedure**, I want to let
you know there is a person named Anoop who is fixing this package to
be compatible[1] with the upcoming lazygit Debian package.

[1] https://github.com/jesseduffield/lazygit-debian/issues/31

I already shared [1] with you, privately, before you filed your ITP.
I am not sure you let him know you will take this package. :S

Thanks \o/

--
Jongmin Kim

OpenPGP key located at https://jongmin.dev/pgp
OpenPGP fingerprint: 012E 4A06 79E1 4EFC DAAE  9472 D39D 8D29 BAF3 6DF8

Bug#1055757: webext-browserpass: extension shows warning in browser: "Update native host app"

2023-11-10 Thread Ralf Jung

Package: webext-browserpass
Version: 3.7.2-1+b13
Severity: normal

Dear Maintainer,

When activating the extension in Firefox, I now get a warning in the "pass" 
menu. It says in red text "Update native host app".

The package here in Debian has not been updated in over 2 years, so I assume 
this simply needs the latest upstream version to be packaged.

Kind regards,
Ralf

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

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

Versions of packages webext-browserpass depends on:
ii  fonts-open-sans  1.11-2
ii  libc62.37-12

Versions of packages webext-browserpass recommends:
pn  firefox | firefox-esr | chromium  

webext-browserpass suggests no packages.

-- no debconf information

Bug#1055756: libasound2: some legacy midi apps (e.g. Chromium WebMIDI) are broken by alsa-lib 1.2.10

2023-11-10 Thread Clément Hermann

Package: libasound2
Version: 1.2.10-1
Severity: normal
Tags: patch upstream

Dear Alsa team,

alsa-lib 1.2.10 implements UMP support for seq.

Unfortunately, it breaks chromium WebMIDI at least partially.

This is a chromium bug, actually, but since it is a regression, upstream
has implemented a workaround for it:

Upstream Issue: https://github.com/alsa-project/alsa-lib/issues/360
Upstream fix: 
https://github.com/alsa-project/alsa-lib/commit/2fca03e792ef1b740e8a7370fdd360d0b627c84c

I have a fixed version available at
https://salsa.debian.org/nodens/alsa-lib.

(I'd have applied to join the team or proposed a NMU, but I forgot to update
my key in time and can't upload right now).

Cheers,

nodens

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

Kernel: Linux 6.5.0-3-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 libasound2 depends on:
ii  libasound2-data  1.2.10-1
ii  libc62.37-12

libasound2 recommends no packages.

Versions of packages libasound2 suggests:
ii  libasound2-plugins  1.2.7.1-1+b1

-- no debconf information

Bug#1055753: debci: --config option is broken

2023-11-10 Thread Antonio Terceiro

On Fri, Nov 10, 2023 at 04:42:10PM +0100, Christian Kastner wrote:
> Package: debci
> Version: 3.7
> Severity: normal
> 
> The --config option to the debci subcommands does not work:
> 
> $ mkdir /tmp/foo
> $ echo 'debci_arch="i386"' > /tmp/foo/debci.conf
> 
> $ debci config --config /tmp/foo config_dir
> config_dir=/tmp/foo
> 
> $ debci config --config /tmp/foo arch
> arch=amd64
> 
> I believe that this is because it is processed too late.
> 
> It is first processed at the top lib/environment.sh, where it is used to read
> the config, and set important variables, like debci_arch above.
> 
> Only after this has happened, its getopt(1) called. And I believe that all 
> that
> --config does at that point, is to update debci_config_dir.
> 
> 
> In fact, I believe all of the option parsing should be moved to the very top,
> as least some other options are also broken this way:
> 
> $ echo 'debci_arch_list="arm64 i386"' >> /tmp/foo/debci.conf
> $ debci config --config /tmp/foo --arch=i386 arch
> arch=i386
> $ debci config --config /tmp/foo --arch=i386 arch_list
> arch_list=amd64
> 
> 
> I didn't want to file an MR outright, as I don't know the background behind 
> the
> current solution, and there might be a good reason for it.

Some shared options are defined in lib/environment.sh, I think that's
why it currently loads lib/environment.sh before processing the command
line options.

OTH your analysis is correct, as this causes the --config option to be
useless. A solution to this would be to break the common options into
their own file, include that in the scripts, call getopt, process
--config before anything else, then load lib/environment.sh for default
values, and only then process the rest of the options.


signature.asc
Description: PGP signature

Bug#1055751: transition: wolfssl

Control: tags -1 moreinfo

On 2023-11-10 15:57:27 +0100, Bastian Germann wrote:
> Package: release.debian.org
> Control: affects -1 wolfssl
> X-Debbugs-Cc: wolf...@packages.debian.org
> User: release.debian@packages.debian.org
> Usertags: transition
> Severity: normal
> Control: forwarded -1 
> https://release.debian.org/transitions/html/auto-wolfssl.html
> 
> wolfssl is available in experimental with libwolfssl41.
> This transition is from libwolfssl35.
> The auto-generated Ben file is okay and all reverse dependencies build fine.

What's the status of the reverse dependencies? Do they build
successfully with the new version of wolfssl?

Cheers
-- 
Sebastian Ramacher

Bug#1055755: transition: libre/rem/baresip


Package: release.debian.org
Control: affects -1 libre
X-Debbugs-Cc: li...@packages.debian.org
User: release.debian@packages.debian.org
Usertags: transition
Severity: normal
Control: forwarded -1 
https://release.debian.org/transitions/html/auto-libre.html

libre, rem, and baresip are available in experimental, details on the update at 
#967266.
I suggest to upload libre, then rem, then baresip to unstable.
The auto-generated Ben files of auto-libre and auto-rem are okay and
the packages build fine but are relying on being updated together (the experimental baresip does not 
build with unstable libre/rem, while experimental libre/rem break baresip).

Bug#1055752: `groupadd --force --system sambashare` in samba.postinst is wrong

2023-11-10 Thread Michael Tokarev


Control: tag -1 + moreinfo

10.11.2023 18:04, Osamu Aoki:

Source: samba
Severity: normal

Problem: `groupadd --force --system sambashare` in samba.postinst is wrong

Versions:  2:4.17.12+dfsg-0+deb12u1, 2:4.19.2+dfsg-1
Salsa: 0610d7670c6 ("update changelog; upload version 4.19.2+dfsg-1 to 
unstable", 2023-10-16)

groupadd is in essential but command syntax is not the same as addgroup
from adduser package.  Simply replacing adduser is not the right fix.

I see you committed on this happened from:
   1eb07efc2fb ("d/winbind.postinst: switch addgroup => groupadd and eliminate 
getent", 2022-11-03)

What happened was adduser is not essential.  So if you don't depend on
it, piuparts fails.  (Yes, there may have been some transitional problem
etc.  But this is the core of the issue.)  So please add depends to
adduser and use the older good code.

If you insist on using groupadd from shadow package, you need to use
something along (but this may still fail on some corner cases:

groupadd -f -K MIN_GID=100 -K MAX_GID=999 sambashare

I still think this use of groupadd is bad idea.

Use of getent in old code should be no problem since it is in libc-bin
which is priority required.


Why are you saying it all?  I don't follow.  Sure thing, groupadd does not
have the same syntax as addgroup, but this is irrelevant.

From groupadd manpage:

   --force
   This option causes the command to simply exit with success status
   if the specified group already exists

So this eliminates the need for getent, I can use just a single call to
groupadd, it will do nothing if the group is already exists.

   --system
   Create a system group.

   The numeric identifiers of new system groups are chosen in the
   SYS_GID_MIN-SYS_GID_MAX range, defined in login.defs, instead of
   GID_MIN-GID_MAX.

Why do you suggest to hard-code -K MIN_GID && MAX_GID instead of using
whatever values are configured in login.defs?  I'd say the opposite:
if addgroup always used 100 & 999 here, instead of values from login.defs,
it is a bug in addgroup, and I don't want to use buggy software.

I don't see the point. groupadd suits the task perfectly.

/mjt

Bug#1055665: usr-is-merged: prevents upgrade of unstable chroot and install of usrmerge

Control: reopen 1055665

Hi Marco,

On Fri, Nov 10, 2023 at 04:00:13PM +0100, Marco d'Itri wrote:
> On Nov 10, Daniel Gröber  wrote:
> 
> > I can't say that it is. The other bug is about keeping an unmerged
> > system. I'm trying to switch this chroot to *be* usr-merged but the problem
> > is that installing usrmerge fails as usr-is-merged still errors and
> > prevents installation of usrmerge. See bottom part of log in my initial
> > report.
>
> No, same thing. You obviously have to make sure that usrmerge is 
> installed before you attemp to update usr-is-merged.

Where is that obviousness documented? I find that highly counter-intutive.

Do note that I didn't intentionally install usr-is-merged, this is a
minimal build chroot we're talking about after all. It got pulled in by
something:

$ apt-cache rdepends usr-is-merged
usr-is-merged
Reverse Depends:
  dbus
  init-system-helpers
usrmerge

I have dbus=1.14.10-1 and init-system-helpers=1.65.2.

I can't say I entirely understand the purpose of usr-is-merged other than
to brick systems with unattended upgrades. Could you explain?

Thanks,
--Daniel

signature.asc
Description: PGP signature

Bug#1043161: i2p: CVE-2023-36325

2023-11-10 Thread Pierre Gruet


Hi again,

Just for the sake of clarity: below I suggested a path to removal but I 
want to make it clear I don't intend to undertake such action, 
disrespecting the maintainer. Debian processes have to be respected.


Best,

--
Pierre

Le 10/11/2023 à 10:05, Pierre Gruet a écrit :

Hi Salvatore,

I am doing some QA overseeeing, I am not the maintainer of i2p. I NMUed 
it one year and a half ago, nothing has happened since then.


On Sun, 06 Aug 2023 21:26:51 +0200 Salvatore Bonaccorso 
 wrote:

 > Source: i2p
 > Version: 0.9.48-1.1
 > Tags: security upstream
 > Justification: user security hole
 > X-Debbugs-Cc: car...@debian.org, Debian Security Team 


 >
 > Hi,
 >
 > The following vulnerability was published for i2p.
 >
 > CVE-2023-36325[0]:
 > | Attackers can de-anonymize i2p hidden services with a message replay
 > | attack
 >
 > Should i2p be removed from unstable?

- I feel fixing the CVE would require packaging last upstream version 
(which fixed it), Debian version is far behind it, upstream has changed 
its build system so a simple NMU is not the solution;
- I don't feel the maintainer still has interest into this package, 
which he has not touched for 3 years;
- There is another RC bug #1031817 needing being worked on, upstream has 
not addressed it yet;

- i2p has not been in a Debian release since buster;
- its popcon is quickly decreasing;
- there is only one rdep, syndie, with the same maintainer, it has not 
seen an upload in 4 years and has a near-zero popcon.


I would indeed suggest removing the package and syndie (RoQA) after 
letting some time to the maintainer to respond. Keeping these two 
packages in unstable seems only harmful right now.


What do you think?

 >
 > 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-2023-36325
 > https://www.cve.org/CVERecord?id=CVE-2023-36325
 > [1] https://xeiaso.net/blog/CVE-2023-36325
 >
 > Regards,
 > Salvatore
 >
 >

Best,



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1055753: debci: --config option is broken

2023-11-10 Thread Christian Kastner

Package: debci
Version: 3.7
Severity: normal

The --config option to the debci subcommands does not work:

$ mkdir /tmp/foo
$ echo 'debci_arch="i386"' > /tmp/foo/debci.conf

$ debci config --config /tmp/foo config_dir
config_dir=/tmp/foo

$ debci config --config /tmp/foo arch
arch=amd64

I believe that this is because it is processed too late.

It is first processed at the top lib/environment.sh, where it is used to read
the config, and set important variables, like debci_arch above.

Only after this has happened, its getopt(1) called. And I believe that all that
--config does at that point, is to update debci_config_dir.


In fact, I believe all of the option parsing should be moved to the very top,
as least some other options are also broken this way:

$ echo 'debci_arch_list="arm64 i386"' >> /tmp/foo/debci.conf
$ debci config --config /tmp/foo --arch=i386 arch
arch=i386
$ debci config --config /tmp/foo --arch=i386 arch_list
arch_list=amd64


I didn't want to file an MR outright, as I don't know the background behind the
current solution, and there might be a good reason for it.

Best,
Christian

Bug#1055694: initramfs-tools: After updating coreutils cp: not replacing in console when running update-initramfs

2023-11-10 Thread Sven Joachim

Control: reassign -1 klibc-utils
Control: affects -1 initramfs-tools

On 2023-11-10 19:17 +1100, Konomi wrote:

> Package: initramfs-tools
> Version: 0.142
> Severity: normal
> X-Debbugs-Cc: konomikit...@gmail.com
>
> Dear Maintainer,
>
> After updating coreutils from 9.1-1 to 9.4-1+b1 the following lines appear 
> when
> running update-initramfs -u:
>
> cp: not replacing '/var/tmp/mkinitramfs_vZS3YW/bin/cat'
> cp: not replacing '/var/tmp/mkinitramfs_vZS3YW/bin/cpio'
> cp: not replacing '/var/tmp/mkinitramfs_vZS3YW/bin/dd'
> cp: not replacing '/var/tmp/mkinitramfs_vZS3YW/bin/dmesg'
> cp: not replacing '/var/tmp/mkinitramfs_vZS3YW/bin/false'
> cp: not replacing '/var/tmp/mkinitramfs_vZS3YW/bin/gunzip'
> cp: not replacing '/var/tmp/mkinitramfs_vZS3YW/bin/kill'
> cp: not replacing '/var/tmp/mkinitramfs_vZS3YW/bin/ln'
> cp: not replacing '/var/tmp/mkinitramfs_vZS3YW/bin/ls'
> cp: not replacing '/var/tmp/mkinitramfs_vZS3YW/bin/mkdir'
> cp: not replacing '/var/tmp/mkinitramfs_vZS3YW/bin/mkfifo'
> cp: not replacing '/var/tmp/mkinitramfs_vZS3YW/bin/mknod'
> cp: not replacing '/var/tmp/mkinitramfs_vZS3YW/bin/mount'
> cp: not replacing '/var/tmp/mkinitramfs_vZS3YW/bin/mv'
> cp: not replacing '/var/tmp/mkinitramfs_vZS3YW/bin/nuke'
> cp: not replacing '/var/tmp/mkinitramfs_vZS3YW/bin/readlink'
> cp: not replacing '/var/tmp/mkinitramfs_vZS3YW/bin/resume'
> cp: not replacing '/var/tmp/mkinitramfs_vZS3YW/bin/sh'
> cp: not replacing '/var/tmp/mkinitramfs_vZS3YW/bin/sleep'
> cp: not replacing '/var/tmp/mkinitramfs_vZS3YW/bin/sync'
> cp: not replacing '/var/tmp/mkinitramfs_vZS3YW/bin/true'
> cp: not replacing '/var/tmp/mkinitramfs_vZS3YW/bin/umount'
> cp: not replacing '/var/tmp/mkinitramfs_vZS3YW/bin/uname'

FWIW, this has been triggered by the following changes in coreutils:

,
| * Noteworthy changes in release 9.3 (2023-04-18) [stable]
|
| ** Changes in behavior
|
|   'cp -n' and 'mv -n' now issue an error diagnostic if skipping a file,
|   to correspond with -n inducing a nonzero exit status as of coreutils 9.2.
|
| * Noteworthy changes in release 9.2 (2023-03-20) [stable]
|
| ** Changes in behavior
|
|   'cp -n' and 'mv -n' now exit with nonzero status if they skip their
|   action because the destination exists, and likewise for 'cp -i',
|   'ln -i', and 'mv -i' when the user declines.  (POSIX specifies this
|   for 'cp -i' and 'mv -i'.)
`

I looked for 'cp -n' in the initramfs-tools source and could not find
it.  It turns out that the actual culprit is the file
/usr/share/initramfs-tools/hooks/klibc-utils which uses the -n option,
apparently with good reason, namely not to overwrite files from busybox.

> The lines seem to be a cosmetic issue only, but I cannot be entirely sure.

There do not seem to be any ill effects beside the warnings.

Cheers,
   Sven

Bug#1055752: `groupadd --force --system sambashare` in samba.postinst is wrong

2023-11-10 Thread Osamu Aoki

Source: samba
Severity: normal

Problem: `groupadd --force --system sambashare` in samba.postinst is wrong

Versions:  2:4.17.12+dfsg-0+deb12u1, 2:4.19.2+dfsg-1
Salsa: 0610d7670c6 ("update changelog; upload version 4.19.2+dfsg-1 to 
unstable", 2023-10-16)

groupadd is in essential but command syntax is not the same as addgroup
from adduser package.  Simply replacing adduser is not the right fix.

I see you committed on this happened from:
  1eb07efc2fb ("d/winbind.postinst: switch addgroup => groupadd and eliminate 
getent", 2022-11-03)

What happened was adduser is not essential.  So if you don't depend on
it, piuparts fails.  (Yes, there may have been some transitional problem
etc.  But this is the core of the issue.)  So please add depends to
adduser and use the older good code.

If you insist on using groupadd from shadow package, you need to use
something along (but this may still fail on some corner cases:

groupadd -f -K MIN_GID=100 -K MAX_GID=999 sambashare

I still think this use of groupadd is bad idea.

Use of getent in old code should be no problem since it is in libc-bin
which is priority required.

If you still have problem with your local piuparts checks, please check
your base sid image used for it.  If it still has adduser package in it,
remove it.

-- Package-specific info:
* /etc/samba/smb.conf present, but not attached
* /var/lib/samba/dhcp.conf not present

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

Kernel: Linux 6.5.0-0.deb12.1-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- no debconf information

Bug#1055665: usr-is-merged: prevents upgrade of unstable chroot and install of usrmerge

Control: reopen 1055665

Hi Marco,

On Thu, Nov 09, 2023 at 09:12:57PM +0100, Marco d'Itri wrote:
> Duplicate of #1055413.

I can't say that it is. The other bug is about keeping an unmerged
system. I'm trying to switch this chroot to *be* usr-merged but the problem
is that installing usrmerge fails as usr-is-merged still errors and
prevents installation of usrmerge. See bottom part of log in my initial
report.

Are users expected to perform usr-merging manually in this case? That can't
be true.

How is this upgrade supposed to work for (end) users once this gets
released anyhow? This change would seems to brick upgrades for systems that
are still unmerged, no?

Thanks,
--Daniel


signature.asc
Description: PGP signature

Bug#1055751: transition: wolfssl


Package: release.debian.org
Control: affects -1 wolfssl
X-Debbugs-Cc: wolf...@packages.debian.org
User: release.debian@packages.debian.org
Usertags: transition
Severity: normal
Control: forwarded -1 
https://release.debian.org/transitions/html/auto-wolfssl.html

wolfssl is available in experimental with libwolfssl41.
This transition is from libwolfssl35.
The auto-generated Ben file is okay and all reverse dependencies build fine.

Bug#1055750: gfortran: [armhf] Yield SIGBUS when compiling with -fstack-clash-protection

2023-11-10 Thread Rafael Laboissière

Package: gfortran
Version: 13.2.0-1
Severity: normal

Dear Maintainer,

The motivation for the present bug report comes from Bug#1055228. Since 
version 1.22.1 of dpkg-dev was released (on October 30), the plplot 
package FTBFS due to a failing compilation of one of Fortran examples, 
which is exercised as a unit test during package building.

The package built fine previously. The problem is triggered by the change 
in dpkg-buildflags, which now includes -fstack-clash-protection in 
FFLAGS.

I am attaching to this bug message a shell script that can reliably 
trigger the bug on an armhf system. Here is the output:

$ ./gfortran-stack-clash-protection-armhf-bug.sh
[…]
Program received signal SIGBUS: Access to an undefined portion of a memory 
object.

Backtrace for this error:
Bus error

Note that the bug does not happen on amd64. Also, it does not happen on 
armhf when the option -fstack-clash-protection is not used in the 
invocation of gfortran.

As far as I can tell, the problem is due to a global variable (tr) that 
is not correctly accessed in a private function (mypltr) of the x09f 
program. Here is what gdb tells me:

$ gdb x09f
[…]
(gdb) run -dev ps -o /dev/null
Starting program: /home/rafael/fortran/x09f -dev ps -o /dev/null
[Thread debugging using libthread_db enabled]
Using host libthread_db library 
"/lib/arm-linux-gnueabihf/libthread_db.so.1".

Program received signal SIGBUS, Bus error.
0x00400dfe in x09f::mypltr (x=0, y=1, xt=1, yt=34) at x09f.f90:193
193 xt = tr(1) * x + tr(2) * y + tr(3)

My knowledge of Fortran and gfortran is way too scarce and, therefore, I 
cannot debug the problem deeper.  There may be a programming error in 
x09f.f90 or this may be a problem with gfortran on armhf when option 
-fstack-clash-protection is given.

Any help will be appreciated.

Best,

Rafael Laboissière


gfortran-stack-clash-protection-armhf-bug.sh
Description: Bourne shell script

Bug#1042406: dh-r: throws "Use of uninitialized value $dep_line in substitution" warnings with some packages

Am Fri, Nov 10, 2023 at 12:53:57AM +0530 schrieb Nilesh Patra:
> > > PS: Please mention my contribution in d/ch if you take this patch.
> > 
> > Sure. ;-)

Applied in Git, will do a couple of tests before uploading.

Thanks a lot for the patch
Andreas.

-- 
http://fam-tille.de

Bug#1055749: RFA: freetype-py -- Freetype Python bindings for Python 3


Package: wnpp

As I am no longer interested in the package, I request a new maintainer for 
freetype-py.

Description: Freetype Python bindings for Python 3
 Freetype Python provides bindings for the FreeType library.
 Only the high-level API is bound.

 All the font access is done through the FreeType2 library,
 which supports many formats.  It can render images of characters with
 high-quality hinting and antialiasing, extract metrics information, and
 extract the outlines of characters in scalable formats like TrueType.

Bug#1055748: RFA: swugenerator -- Generates SWU update packages for swupdate


Package: wnpp

As I am no longer interested in the package, I request a new maintainer for 
swugenerator.

Description: Generates SWU update packages for swupdate (Python 3)
 swugenerator is a command line tool to create and modify SWUpdate's
 SWU update files based on templates. openssl is used to sign the SWU.

 Features that swugenerator supports:
  * replace occurrencies of variables found in the CONFIG file
  * add sha256 to each artifact
  * check if an artifact should be encrypted and encrypts it
  * sign sw-description with one of the methods accepted by SWUpdate

Bug#1033482: debootstrap fails when invoked with --merged-usr

2023-11-10 Thread Alberto Garcia

On Fri, Nov 10, 2023 at 02:50:43PM +0100, Alberto Garcia wrote:
> I'm having this problem in bookworm, even with --no-merged-usr:

This works fine if I install the package from bookworm-backports
(1.0.133~bpo12+1) so the package in stable should be fixed

Berto

Bug#1055747: kcalc: Kcalc menu has graphical glitches.

2023-11-10 Thread Ilyas Arinov

Package: kcalc
Version: 4:22.12.3-1
Severity: minor

Dear Maintainer,

Open kcalc, use menu bar. Selected menu item has no colored selection in
default Breeze theme. This is cosmetic problem. Kcalc menu bar works
fine in Science mode only. The outcome I expect is the active menu item
has selection color on it without any glitches like it was in Debian 11.

Thanks.



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

Kernel: Linux 6.4.0-0.deb12.2-amd64 (SMP w/6 CPU threads; PREEMPT)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages kcalc depends on:
ii  libc6 2.36-9+deb12u3
ii  libgmp10  2:6.2.1+dfsg1-1.1
ii  libkf5configcore5 5.103.0-2
ii  libkf5configgui5  5.103.0-2
ii  libkf5configwidgets5  5.103.0-1
ii  libkf5coreaddons5 5.103.0-1
ii  libkf5crash5  5.103.0-1
ii  libkf5guiaddons5  5.103.0-1
ii  libkf5i18n5   5.103.0-1
ii  libkf5notifications5  5.103.0-1
ii  libkf5widgetsaddons5  5.103.0-1
ii  libkf5xmlgui5 5.103.0-1
ii  libmpfr6  4.2.0-1
ii  libqt5core5a  5.15.8+dfsg-11
ii  libqt5gui55.15.8+dfsg-11
ii  libqt5widgets55.15.8+dfsg-11
ii  libqt5xml55.15.8+dfsg-11
ii  libstdc++612.2.0-14

kcalc recommends no packages.

kcalc suggests no packages.

-- no debconf information

Bug#1055745: [INTL:sv] Swedish strings for atftp debconf

2023-11-10 Thread Martin Bagge / brother


package: atftp
severity: wishlist
tags: patch l10n

Please consider to add this file to translation of debconf.
--
brother# Translation of atftp debconf template to Swedish
# Copyright (C) 2008-2023 Martin Bagge 
# This file is distributed under the same license as the atfp package.
#
# Martin Bagge , 2008, 2023
msgid ""
msgstr ""
"Project-Id-Version: atftp 0.7-9\n"
"Report-Msgid-Bugs-To: at...@packages.debian.org\n"
"POT-Creation-Date: 2022-02-11 12:31+0100\n"
"PO-Revision-Date: 2023-11-10 14:53+0100\n"
"Last-Translator: Martin Bagge \n"
"Language-Team: Swedish \n"
"Language: sv\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: string
#. Description
#: ../atftpd.templates:1001
msgid "Server timeout:"
msgstr "Tid till avslut:"

#. Type: string
#. Description
#: ../atftpd.templates:1001
msgid "How many seconds the main thread waits before exiting."
msgstr "Hur många sekunder huvudtråden väntar innan den avslutas."

#. Type: string
#. Description
#: ../atftpd.templates:2001
msgid "Retry timeout:"
msgstr "Tid mellan försök:"

#. Type: string
#. Description
#: ../atftpd.templates:2001
msgid "How many seconds to wait for a reply before retransmitting a packet."
msgstr ""
"Hur många sekunder vi väntar på ett svar innan vi skickar paketet igen."

#. Type: string
#. Description
#: ../atftpd.templates:3001
msgid "Maximum number of threads:"
msgstr "Maximalt antal trådar:"

#. Type: string
#. Description
#: ../atftpd.templates:3001
msgid "Maximum number of concurrent threads that can be running."
msgstr "Maximalt antal trådar som kan köras parallellt."

#. Type: select
#. Description
#: ../atftpd.templates:4001
msgid "Verbosity level:"
msgstr "Förklaringsnivå:"

#. Type: select
#. Description
#: ../atftpd.templates:4001
msgid ""
"Level of logging. 7 logs everything including debug logs. 1 will log only "
"the system critical logs. 5 (LOG_NOTICE) is the default value."
msgstr ""
"Hur informativ loggarna är. 7 loggar allt. 1 loggar bara systemkritiska "
"meddelanden. 5 (LOG_NOTICE) är standardvärdet."

#. Type: boolean
#. Description
#: ../atftpd.templates:5001
msgid "Enable 'timeout' support?"
msgstr "Aktivera 'timeout' stöd?"

#. Type: boolean
#. Description
#: ../atftpd.templates:6001
msgid "Enable 'tsize' support?"
msgstr "Aktivera 'tsize' stöd?"

#. Type: boolean
#. Description
#: ../atftpd.templates:7001
msgid "Enable 'blksize' support?"
msgstr "Aktivera 'block size' stöd?"

#. Type: boolean
#. Description
#: ../atftpd.templates:8001
msgid "Enable 'windowsize' support?"
msgstr "Aktivera 'windowsize' stöd?"

#. Type: boolean
#. Description
#: ../atftpd.templates:9001
msgid "Enable multicast support?"
msgstr "Aktivera multicast stöd?"

#. Type: string
#. Description
#: ../atftpd.templates:10001
msgid "TTL for multicast packets:"
msgstr "TTL för multicast-paket"

#. Type: string
#. Description
#: ../atftpd.templates:11001
msgid "Port to listen for tftp request:"
msgstr "Port för att lyssna på tftp anslutningar:"

#. Type: string
#. Description
#: ../atftpd.templates:12001
msgid "Port range for multicast file transfer:"
msgstr "Portrymd för multicast-överföringar:"

#. Type: string
#. Description
#: ../atftpd.templates:12001
msgid ""
"Multicast transfer will use any available port in a given set. For example, "
"\"2000-2003, 3000\" allow atftpd to use port 2000 to 2003 and 3000."
msgstr ""
"Multicast-överföring kommer att använda de tillgängliga portar som angivets. "
"Till exempel, \"2000-2003, 3000\" kommer atftpd att använda portarna 2000 "
"till 2003 och 3000."

#. Type: string
#. Description
#: ../atftpd.templates:13001
msgid "Address range for multicast transfer:"
msgstr "Adressrymd för multicast-överföring:"

#. Type: string
#. Description
#: ../atftpd.templates:13001
msgid ""
"Multicast transfer will use any available addresses from a given set of "
"addresses. Syntax is \"a.b.c.d-d,a.b.c.d,...\""
msgstr ""
"Multicast-överföring kommer att använda adresser ur adressrymden som "
"specificeras enligt följande, \"a.b.c.d-d,a.b.c.d,...\""

#. Type: boolean
#. Description
#: ../atftpd.templates:14001
msgid "Log to file instead of journal/syslog?"
msgstr "Logga till fil istället för journal/syslog?"

#. Type: string
#. Description
#: ../atftpd.templates:15001
msgid "Log file:"
msgstr "Loggfil:"

#. Type: string
#. Description
#: ../atftpd.templates:15001
msgid ""
"A file where atftpd will write its logs. This file will be made writable for "
"the user 'nobody' and group 'nogroup'."
msgstr ""
"Filen som atftpd skriver sin logg till. Filen kommer att vara skribar av "
"användaren 'nobody' och gruppen 'nogroup'."

#. Type: string
#. Description
#: ../atftpd.templates:16001
msgid "Base directory:"
msgstr "Hemkatalog:"

#. Type: string
#. Description
#: ../atftpd.templates:16001
msgid ""
"The directory tree from where atftpd can serve files. That directory must be "
"world readable."
msgstr ""
"Katalogträdet med filer som atftpd erbjuder. Katalogen

Bug#1055746: [INTL:sv] Swedish strings for ucf debconf

2023-11-10 Thread Martin Bagge / brother


package: ucf
severity: wishlist
tags: patch l10n

Please consider to add this file to translation of debconf.
--
brother# Swedish translation for ucf.
# Copyright (C) 2009, 2014, 2023 Martin Bagge 
# This file is distributed under the same license as the ucf package.
#
# Martin Bagge , 2009, 2014, 2023.
# Daniel Nylander , 2007.
msgid ""
msgstr ""
"Project-Id-Version: ucf 2.002\n"
"Report-Msgid-Bugs-To: u...@packages.debian.org\n"
"POT-Creation-Date: 2018-02-16 15:56-0800\n"
"PO-Revision-Date: 2023-11-10 14:56+0100\n"
"Last-Translator: Martin Bagge / brother \n"
"Language-Team: Swedish \n"
"Language: Swedish\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Poedit 1.5.4\n"

#. Type: title
#. Description
#: ../templates:2001
msgid "Modified configuration file"
msgstr "Ändrad konfigurationsfil"

#. Type: select
#. Choices
#. Translators, please keep translations *short* (less than 65 columns)
#. Type: select
#. Choices
#: ../templates:3001 ../templates:4001
msgid "install the package maintainer's version"
msgstr "installera paketansvariges version"

#. Type: select
#. Choices
#. Translators, please keep translations *short* (less than 65 columns)
#. Type: select
#. Choices
#: ../templates:3001 ../templates:4001
msgid "keep the local version currently installed"
msgstr "behåll den lokalt installerade version"

#. Type: select
#. Choices
#. Translators, please keep translations *short* (less than 65 columns)
#. Type: select
#. Choices
#: ../templates:3001 ../templates:4001
msgid "show the differences between the versions"
msgstr "visa skillnaderna mellan versionerna"

#. Type: select
#. Choices
#. Translators, please keep translations *short* (less than 65 columns)
#. Type: select
#. Choices
#: ../templates:3001 ../templates:4001
msgid "show a side-by-side difference between the versions"
msgstr "visa skillnaderna sida vid sida mellan versionerna"

#. Type: select
#. Choices
#. Translators, please keep translations *short* (less than 65 columns)
#: ../templates:3001
msgid "show a 3-way difference between available versions"
msgstr "visa en 3-vägs skillnad mellan tillgängliga versioner"

#. Type: select
#. Choices
#. Translators, please keep translations *short* (less than 65 columns)
#: ../templates:3001
msgid "do a 3-way merge between available versions"
msgstr "försök genomföra en 3-vägs sammanslagning av tillgängliga versioner"

#. Type: select
#. Choices
#. Translators, please keep translations *short* (less than 65 columns)
#. Type: select
#. Choices
#: ../templates:3001 ../templates:4001
msgid "start a new shell to examine the situation"
msgstr "starta ett nytt skal för att undersöka situationen"

#. Type: select
#. Description
#. Type: select
#. Description
#: ../templates:3002 ../templates:4002
msgid "What do you want to do about modified configuration file ${BASENAME}?"
msgstr "Vad vill du göra med den uppdaterade filen ${BASENAME}?"

#. Type: select
#. Description
#: ../templates:3002
msgid ""
"A new version (${NEW}) of configuration file ${FILE} is available, but the "
"version installed currently has been locally modified."
msgstr ""
"En ny version (${NEW}) av konfigurationsfilen ${FILE} finns tillgänglig, men "
"versionen som är installerad har ändrats lokalt."

#. Type: select
#. Description
#: ../templates:4002
msgid ""
"${BASENAME}: A new version (${NEW}) of configuration file ${FILE} is "
"available, but the version installed currently has been locally modified."
msgstr ""
"${BASENAME}: En ny version (${NEW}) av konfigurationsfilen ${FILE} finns "
"tillgänglig, men versionen som är installerad har ändrats lokalt."

#. Type: note
#. Description
#: ../templates:5001
msgid "Line by line differences between versions"
msgstr "Visa skillnaderna rad för rad mellan versionerna"

#. Type: error
#. Description
#: ../templates:6001
msgid "Conflicts found in three-way merge"
msgstr "Konflikter i trevägssammanslagning"

#. Type: error
#. Description
#: ../templates:6001
msgid ""
"Conflicts found during three-way merge! Please edit `${dest_file}' and sort "
"them out manually."
msgstr ""
"En eller flera konflikter uppstod vid trevägssammanslagningen! Redigera "
"\"${dest_file}\" och lös konflikterna manuellt."

#. Type: error
#. Description
#: ../templates:6001
msgid ""
"The file `${dest_file}.${ERR_SUFFIX}' has a record of the failed merge of "
"the configuration file."
msgstr ""
"Filen \"${dest_file}.${ERR_SUFFIX}\"  innehåller en notering av den "
"misslyckade sammanslagningen av inställningsfilerna."

Bug#1055744: RFA: fonts-montserrat -- Font inspired by old urban posters and signs


Package: wnpp
X-Debbugs-Cc: debian-fo...@lists.debian.org

As I am no longer interested in the package, I request a new maintainer for 
fonts-montserrat.
You should keep it in the Fonts Team.

Description: Font inspired by old urban posters and signs
 The old posters and signs in the traditional neighborhood of Buenos Aires
 called Montserrat inspired the design of this typeface that rescues the beauty
 of urban typography from the first half of the twentieth century.
 These are the types that make the city look so beautiful.

Bug#1055742: libnginx-mod-http-cache-purge: Segmentation fault caused by PURGE requests

2023-11-10 Thread Aziz Kemyakov

Package: libnginx-mod-http-cache-purge
Version: 2.3-4
Severity: important

Dear Maintainer,

The module ngx_http_cache_purge_module is not working on nginx 1.22.1. Someone 
already fixed that, patch can be found here:
https://github.com/FRiCKLE/ngx_cache_purge/pull/51/commits/c8ca321b909cb3d9371db4509f1064045d7e0b1c

Thanks in advance!


-- System Information:
Debian Release: 12.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-13-amd64 (SMP w/64 CPU threads; PREEMPT)
Locale: LANG=C, LC_CTYPE=en_US.utf8 (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 libnginx-mod-http-cache-purge depends on:
ii  libc6   2.36-9+deb12u3
ii  nginx [nginx-abi-1.22.1-7]  1.22.1-9

Versions of packages libnginx-mod-http-cache-purge recommends:
ii  nginx  1.22.1-9

libnginx-mod-http-cache-purge suggests no packages.

Bug#1055743: RFA: junitparser -- Merges JUnit/xUnit Result XML files


Package: wnpp

As I am no longer interested in the package, I request a new maintainer for 
junitparser.

Description: Manipulates JUnit/xUnit Result XML files
 junitparser is a JUnit/xUnit result XML Parser. Use it to parse and manipulate
 existing Result XML files, or create new JUnit/xUnit result XMLs from scratch.

Bug#1033482: debootstrap fails when invoked with --merged-usr

2023-11-10 Thread Alberto Garcia

On Sat, Mar 25, 2023 at 10:05:54PM +0100, David Heidelberg wrote:
> W: Failure while unpacking required packages.  This will be attempted up to 
> five times.
> W: See /lava-files/rootfs-amd64/debootstrap/debootstrap.log for details 
> (possibly the package /var/cache/apt/archives/usr-is-merged_35_all.deb is at 
> fault)
> 
> Whole log: https://gitlab.freedesktop.org/okias/mesa/-/jobs/38725690
> 
> These errors can be prevented when using --no-merged-usr.

I'm having this problem in bookworm, even with --no-merged-usr:

$ debootstrap --no-merged-usr sid /var/tmp/chroot/
[...]
I: Unpacking tzdata...
I: Unpacking usr-is-merged...
I: Unpacking zlib1g:amd64...
W: Failure while unpacking required packages.  This will be attempted up to 
five times.
W: See /var/tmp/chroot/debootstrap/debootstrap.log for details (possibly the 
package /var/cache/apt/archives/usr-is-merged_38_all.deb is at fault)

Because of this I cannot use pbuilder.

Berto

Bug#1055741: ITP: golang-connectrpc-connect -- The Go implementation of Connect: Protobuf RPC that works.

Package: wnpp
Severity: wishlist
Owner: Maytham Alsudany 

* Package name: golang-connectrpc-connect
  Version : 1.12.0-1
  Upstream Author : Connect
* URL : https://github.com/connectrpc/connect-go
* License : Apache-2.0
  Programming Lang: Go
  Description : The Go implementation of Connect: Protobuf RPC that works.

 Connect is a slim library for building browser and gRPC-compatible HTTP
 APIs. You write a short Protocol Buffer schema and implement
 your application logic, and Connect generates code to handle marshaling,
 routing, compression, and content type negotiation. It also generates an
 idiomatic, type-safe client. Handlers and clients support three
 protocols: gRPC, gRPC-Web, and Connect's own protocol.
 .
 The Connect protocol is a simple
 protocol that works over HTTP/1.1 or HTTP/2. It takes the best portions
 of gRPC and gRPC-Web, including streaming, and packages them into a
 protocol that works equally well in browsers, monoliths, and
 microservices. Calling a Connect API is as easy as using curl.

This is an indirect dependency of the upcoming lazygit package.
I intend to maintain this package within the Debian Go Packaging team.

Bug#1055740: ITP: golang-github-humanlogio-humanlog -- Logs for humans to read.

Package: wnpp
Severity: wishlist
Owner: Maytham Alsudany 

* Package name: golang-github-humanlogio-humanlog
  Version : 0.7.6-1
  Upstream Author : Antoine Grondin 
* URL : https://github.com/humanlogio/humanlog
* License : Apache-2.0
  Programming Lang: Go
  Description : Logs for humans to read.

 Read structured logs from stdin and print them back to stdout, but in a
 prettier and more human-readable format.

This is a dependency of the upcoming lazygit package, and I intend to maintain
it within the Debian Go Packaging team.

Bug#1055702: pycuda ftbfs with Python 3.12

2023-11-10 Thread Andreas Beckmann


On 10/11/2023 10.43, Andreas Beckmann wrote:
Do you have the buildlog with the failure available, as building with 
python3.12 is currently non-trivial ;-)


https://launchpadlibrarian.net/696984549/buildlog_ubuntu-noble-amd64.pycuda_2022.2.2~dfsg-2build2_BUILDING.txt.gz

[...]
running build_ext
---
Sorry, your build failed. Try rerunning configure.py with different options.
---
Traceback (most recent call last):
  File "/<>/setup.py", line 270, in 
main()
  File "/<>/setup.py", line 190, in main
setup(
  File "/<>/aksetup_helper.py", line 24, in setup
setup(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line 107, in 
setup
return distutils.core.setup(**attrs)
   ^
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/core.py", line 
185, in setup
return run_commands(dist)
   ^^
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/core.py", line 
201, in run_commands
dist.run_commands()
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/dist.py", line 
969, in run_commands
self.run_command(cmd)
  File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 1233, in 
run_command
super().run_command(command)
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/dist.py", line 
988, in run_command
cmd_obj.run()
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/command/build.py", 
line 131, in run
self.run_command(cmd_name)
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/cmd.py", line 318, 
in run_command
self.distribution.run_command(command)
  File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 1233, in 
run_command
super().run_command(command)
  File "/usr/lib/python3/dist-packages/setuptools/_distutils/dist.py", line 
988, in run_command
cmd_obj.run()
  File "/usr/lib/python3/dist-packages/setuptools/command/build_ext.py", line 
88, in run
_build_ext.run(self)
  File 
"/usr/lib/python3/dist-packages/setuptools/_distutils/command/build_ext.py", 
line 345, in run
self.build_extensions()
  File 
"/usr/lib/python3/dist-packages/setuptools/_distutils/command/build_ext.py", 
line 467, in build_extensions
self._build_extensions_serial()
  File 
"/usr/lib/python3/dist-packages/setuptools/_distutils/command/build_ext.py", 
line 493, in _build_extensions_serial
self.build_extension(ext)
  File "/<>/aksetup_helper.py", line 91, in build_extension
numpy_incpath = get_numpy_incpath()
^^^
  File "/<>/aksetup_helper.py", line 38, in get_numpy_incpath
from imp import find_module
ModuleNotFoundError: No module named 'imp'
E: pybuild pybuild:395: build: plugin distutils failed with: exit code=1: 
/usr/bin/python3.12 setup.py build
Traceback (most recent call last):
  File "/usr/bin/pybuild", line 393, in main
run(func, i, version, c)
  File "/usr/bin/pybuild", line 331, in run
result = func(context, args)
 ^^^
  File "/usr/share/dh-python/dhpython/build/base.py", line 363, in wrapped_func
raise Exception(msg)
Exception: exit code=1: /usr/bin/python3.12 setup.py build
[...]

Bug#1055682: gdal b-d's on python3-all-dev, but only builds for the default python version

2023-11-10 Thread Sebastiaan Couwenberg


On 11/10/23 13:30, Matthias Klose wrote:

see
https://launchpadlibrarian.net/696024489/buildlog_ubuntu-noble-amd64.gdal_3.7.3+dfsg-1_BUILDING.txt.gz


That shows:

 for V in 3.12 3.11; do \

 -- Found Python: /usr/bin/python3.12 (found suitable exact version 
"3.12.0") found components: Interpreter Development NumPy 
Development.Module Development.Embed


 -- Found Python: /usr/bin/python3 (found suitable exact version 
"3.11.6") found components: Interpreter Development NumPy 
Development.Module Development.Embed


 copying 
build/lib.linux-x86_64-cpython-312/osgeo/_gdal.cpython-312-x86_64-linux-gnu.so 
-> osgeo
 copying 
build/lib.linux-x86_64-cpython-312/osgeo/_gdalconst.cpython-312-x86_64-linux-gnu.so 
-> osgeo
 copying 
build/lib.linux-x86_64-cpython-312/osgeo/_osr.cpython-312-x86_64-linux-gnu.so 
-> osgeo
 copying 
build/lib.linux-x86_64-cpython-312/osgeo/_ogr.cpython-312-x86_64-linux-gnu.so 
-> osgeo
 copying 
build/lib.linux-x86_64-cpython-312/osgeo/_gnm.cpython-312-x86_64-linux-gnu.so 
-> osgeo
 copying 
build/lib.linux-x86_64-cpython-312/osgeo/_gdal_array.cpython-312-x86_64-linux-gnu.so 
-> osgeo


 copying 
build/lib.linux-x86_64-cpython-311/osgeo/_gdal.cpython-311-x86_64-linux-gnu.so 
-> osgeo
 copying 
build/lib.linux-x86_64-cpython-311/osgeo/_gdalconst.cpython-311-x86_64-linux-gnu.so 
-> osgeo
 copying 
build/lib.linux-x86_64-cpython-311/osgeo/_osr.cpython-311-x86_64-linux-gnu.so 
-> osgeo
 copying 
build/lib.linux-x86_64-cpython-311/osgeo/_ogr.cpython-311-x86_64-linux-gnu.so 
-> osgeo
 copying 
build/lib.linux-x86_64-cpython-311/osgeo/_gnm.cpython-311-x86_64-linux-gnu.so 
-> osgeo
 copying 
build/lib.linux-x86_64-cpython-311/osgeo/_gdal_array.cpython-311-x86_64-linux-gnu.so 
-> osgeo


The extensions does get built for both.


python3-gdal_3.7.3+dfsg-1_amd64.deb doesn't have any extensions for 3.12.


The installation for 3.12 fails:

 Traceback (most recent call last):
   File "/<>/build-py3.12/swig/python/setup.py", line 14, 
in 

 from setuptools.command.build_ext import build_ext
   File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line 
9, in 

 import distutils.core
 ModuleNotFoundError: No module named 'distutils'

There is an issue with setuptools in your build environment.

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#1055682: gdal b-d's on python3-all-dev, but only builds for the default python version


On 10.11.23 13:30, Matthias Klose wrote:

see
https://launchpadlibrarian.net/696024489/buildlog_ubuntu-noble-amd64.gdal_3.7.3+dfsg-1_BUILDING.txt.gz

python3-gdal_3.7.3+dfsg-1_amd64.deb doesn't have any extensions for 3.12.


[...]
Install the project...
/usr/bin/cmake -P cmake_install.cmake
-- Install configuration: "None"
Traceback (most recent call last):
  File "/<>/build-py3.12/swig/python/setup.py", line 14, 
in 

from setuptools.command.build_ext import build_ext
  File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line 9, 
in 

import distutils.core
ModuleNotFoundError: No module named 'distutils'


so this fails because distutils is removed in 3.12.  And the build 
system ignores the build failure.

Bug#1055739: bson2json does not work

2023-11-10 Thread Stéphane Glondu

Package: reserialize
Version: 20220929-2
Severity: normal

Dear Maintainer,

The command

echo '{}' | json2bson | bson2json

fails with:

> Traceback (most recent call last):
>   File "/usr/bin/bson2json", line 84, in 
> data = fh_loaders[itype](ifh)
>^^
>   File "/usr/bin/bson2json", line 24, in 
> "bson": lambda fh: next(bson.decode_file_iter(fh)),
>^^^
>   File "/usr/lib/python3/dist-packages/bson/__init__.py", line 1159, in 
> decode_file_iter
> obj_size = _UNPACK_INT_FROM(size_data, 0)[0] - 4
>^^
> TypeError: a bytes-like object is required, not 'str'


Cheers,

-- 
Stéphane


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

Kernel: Linux 6.5.0-3-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 reserialize depends on:
ii  python3   3.11.4-5+b1
ii  python3-yaml  6.0.1-1

Versions of packages reserialize recommends:
ii  python3-bson  3.11.0-1+b5
pn  python3-toml  

reserialize suggests no packages.

-- no debconf information

Bug#1055682: gdal b-d's on python3-all-dev, but only builds for the default python version


see
https://launchpadlibrarian.net/696024489/buildlog_ubuntu-noble-amd64.gdal_3.7.3+dfsg-1_BUILDING.txt.gz

python3-gdal_3.7.3+dfsg-1_amd64.deb doesn't have any extensions for 3.12.

Bug#1055738: yersinia: Homepage not available


Source: yersinia

Please replace the Homepage and download source to 
https://github.com/tomac/yersinia

The website http://www.yersinia.net/ is not available anymore and the 
sourceforge project only holds old versions.

Bug#1052538: Merge request

2023-11-10 Thread Pushkar Kulkarni

Created https://salsa.debian.org/java-team/truffle/-/merge_requests/2
to fix this issue.

Thanks!
- Pushkar

Bug#1055616: ansible-core: ansible.builtin.setup does not include facts from facter.

2023-11-10 Thread Lee Garrett


Hi Andrew,

On 08.11.23 22:40, andrew bezella wrote:

Package: ansible-core
Version: 2.14.3-1
Severity: normal

Dear Maintainer,

i installed ansible-core and facter 4.3.0-2 in bookworm.  when testing
i found that the facts from facter were not being included by the
setup module:

% ansible -b localhost -m ansible.builtin.setup -a 'filter=facter_*'
[WARNING]: No inventory was parsed, only implicit localhost is available
localhost | SUCCESS => {
 "ansible_facts": {},
 "changed": false
}

this issue has appeared upstream and was resolved by:
setup module, retry facter to handle --puppet errors by bcoca · Pull Request 
#80645 · ansible/ansible · GitHub
https://github.com/ansible/ansible/pull/80645


Thank you for the bug report! I've been able to reproduce the bug and will 
prepare an upload for sid and bookworm shortly.




i was eventually able to build an updated version of bookworm's
ansible-core .deb including commit id 4b0d014.  this task was made
more difficult by the current FTBFS status of ansible-core but the
patch allowed ansible.builtin.setup to include facts from facter:


Can you elaborate please? AFAICS ansible-core builds fine in stable and sid.



% ansible -b localhost -m ansible.builtin.setup -a 'filter=facter_*'
[WARNING]: No inventory was parsed, only implicit localhost is available
localhost | SUCCESS => {
 "ansible_facts": {
 "facter_disks": {
 "sda": {
[...]
 "facter_timezone": "UTC",
 "facter_virtual": "physical"
 },
 "changed": false
}

thanks in advance for addressing this.

andy



Greetings,
Lee

Bug#1055392: wasmedge: autopkgtest regression: 'cstdint' file not found

2023-11-10 Thread Faidon Liambotis

Control: affects 1052002 - wasmedge
Control: affects 1052002 + src:wasmedge

On Thu, Nov 09, 2023 at 09:52:04AM +0100, Paul Gevers wrote:
> > Hi Paul,
> > Thank you for your report. This is caused #1052002, which I had marked
> > as affects: wasmedge previously.
> 
> Sorry for not checking that, but because you marked it as affecting the
> *binary* package wasmedge, it doesn't show up looking for bugs in the source
> package wasmedge (that may be a bts bug). Because this is a FTBFS issue, I
> recommend you to mark it affects src:wasmedge instead of wasmedge.

Alright, fair enough. Hopefully fixed above?

> > Also, I'm not sure I understand how clang migrated to testing when it
> > introduced an autopkgtest regression in another package. Isn't
> > autopkgtest integration in britney supposed to prevent this kind of
> > thing from happening?
> 
> britney prevents this kind of things currently only for *direct* reverse
> (test) dependencies. In this case we have:
> 
> test/Depends: clang (from src:llvm-defaults) -> (Depends) clang-16
> 
> As I'm pretty sure you meant not clang, but one of the versioned clang
> packages, britney didn't see the breakage. There are multiple ways to
> improve this:
> * britney should look at all transitive dependencies (we lack the resources
> and also not environmentally friendly)
> * britney could be taught to translate (automatically or via configuration)
> "-defaults" packages to their real packages. This would be good for multiple
> ecosystems, patches welcome.
> * Individual packages that are sensitive could use the
> `hint-testsuite-triggers` trick from the autopkgtest spec [1] and add the
> current real packages. That's a PITA to maintain though, and adding versions
> that you don't really test is wrong.

Hrm, that's useful context and in hindsight makes a lot of sense. Thanks
so much for spending the time to explain this to me!

In the meantime, I'll mark the embed-cxx test as flaky in the next
WasmEdge upload until the clang-16 bug gets fixed.

Best,
Faidon

Bug#1054657: transition: r-bioc-biocgenerics

Control: tags -1 - moreinfo

Hi,

Am Fri, Nov 10, 2023 at 05:43:43PM +0900 schrieb Charles Plessy:
> Hi Paul and everybody,

I admit Paul's mail was convincing enough to dive deeper into this.  I
also need to admit that hacking together some scripts doing the job was
less effort than I expected, finally.  Sorry for sounding stubborn in
the beginning.
 
> We will complete the checks and package the new dependencies and submit
> the to NEW next week

The only new dependency we need is SparseArray.  However, we cannot
upload the package to new since it needs r-bioc-s4arrays (>= 1.1.6) for
building it.  In other words: We need to start the transition before we
can package SparseArray.

Kind regards
Andreas.

-- 
http://fam-tille.de

Bug#1055510: Best way to coordinate this fix

2023-11-10 Thread Helmut Grohne

Hi Francois,

On Thu, Nov 09, 2023 at 10:27:51PM -0800, Francois Marier wrote:
> I've just uploaded to experimental. If there are any tests you can easily
> run there, please do so.

Thank you. The package built and dumat has imported it. I locally forked
its analysis database pretending that systemd would not declare a
conflict for molly-guard and reran it on that database. It does not
report any issues for molly-guard 0.8. I also checked the underlying
database and see that it recognizes the duplicated diversions there.

> I've upgraded in unstable from the current version to 0.8 without problems,
> so that should in theory work when I eventually upload to unstable.

>From a /usr-merge pov, I have no objections to uploading this to
unstable immediately. Do note that backporting 0.8 to bookworm should
not be done without reverting the file moves that I added. I hope that
backporting molly-guard is not an important user story.

Helmut

Bug#1055736: renpy b-d's on python3-all-dev, but only builds for the default python version


Package: src:renpy
Version: 8.0.3+dfsg-1
Severity: important
Tags: sid trixie
User: debian-pyt...@lists.debian.org
Usertags: python3.12

renpy b-d's on python3-all-dev, but only builds for the default python 
version. It probably should just build-depend on python3-dev, or build 
for all supported Python3 versions.

Bug#1055735: geventhttpclient ftbfs with Python 3.12