Bug#1017497: closed by Debian FTP Masters (reply to Jochen Sprickerhof ) (Bug#1017497: fixed in pnc 0.9.4-1)

2023-01-22 Thread Paul Wise
On Mon, 2023-01-23 at 06:58 +0100, Jochen Sprickerhof wrote:

> Sorry, I should have added more information. Upstream development of pn 
> stalled and we are switching to the active pnc fork.
> Given that pn was never part of a release and the name is rather short 
> and non explaining, I would just drop it. This also means that the 
> executable is now named pnc.

I see, thanks for the explanation. Switching locally now.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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


Bug#1029485: RFS: runit/2.1.2-53 [RC] -- system-wide service supervision

2023-01-22 Thread Lorenzo
Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name : runit
   Version  : 2.1.2-53
   Upstream contact : Gerrit Pape 
 * URL  : http://smarden.org/runit/
 * License  : CC0-1.0, BSD-3-clause, GPL-3+
 * Vcs  : https://salsa.debian.org/debian/runit
   Section  : admin

The source builds the following binary packages:

  runit - system-wide service supervision
  runit-run - service supervision (systemd and sysv integration)
  runit-systemd - transitional package for runit-systemd users
  getty-run - runscripts to supervise getty processes
  runit-init - system-wide service supervision (as init system)

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

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

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

  dget -x
  https://mentors.debian.net/debian/pool/main/r/runit/runit_2.1.2-53.dsc

Git repo:

  https://salsa.debian.org/debian/runit/-/tree/next

Changes since the last upload:

 runit (2.1.2-53) unstable; urgency=medium
 .
   * runit-init:
   - depends on mount [linux-any] (Closes: #1028181)
   - change architecture field to any, because of mount
   - recommends runit-services
   * runit: suggests runit-services
   * getty-run:
   - enable the serial getty-ttyS0 by default
   - make getty-ttyS0 device configurable
   - automatically set device for getty-ttyS0 from
 kernel `console=' command line (Closes: #1028270)
   * d/copyright: update copyright years
   * d/tests: update init-switch test

Regards,
Lorenzo



Bug#985631:

2023-01-22 Thread c . buhtz

Seems to be a duplicate of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985256



Bug#985256:

2023-01-22 Thread c . buhtz

Looks like a duplicate of this to me:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985631



Bug#1029234: lyx: Graphic problems editing a lyx file

2023-01-22 Thread Stefano Simonucci
OK. However I would like to point out that even the version flagged as 
bad works fine with the xfce desktop environment.


Stefano

On 22/01/23 20:04, Dr. Tobias Quathamer wrote:

control: tag -1 unreproducible
control: severity -1 important

Am 20.01.23 um 15:21 schrieb Stefano Simonucci:

I get the following messages:

sudo apt build-dep lyx
[sudo] password di stefano:
Lettura elenco dei pacchetti... Fatto
Lettura elenco dei pacchetti... Fatto
Generazione albero delle dipendenze... Fatto
Lettura informazioni sullo stato... Fatto
Alcuni pacchetti non possono essere installati. Questo può voler dire
che è stata richiesta una situazione impossibile oppure, se si sta
usando una distribuzione in sviluppo, che alcuni pacchetti richiesti
non sono ancora stati creati o sono stati rimossi da Incoming.
Le seguenti informazioni possono aiutare a risolvere la situazione:

I seguenti pacchetti hanno dipendenze non soddisfatte:
  libboost-iostreams1.74-dev : Dipende: libboost1.74-dev (= 1.74.0-9) 
ma la versione 1.74.0-18.1 sta per essere installata
   Dipende: libboost-regex1.74-dev (= 
1.74.0-9) ma la versione 1.74.0-18.1 sta per essere installata
   Dipende: libboost-iostreams1.74.0 (= 
1.74.0-9) ma la versione 1.74.0-18.1 sta per essere installata
  libenchant-2-dev : Dipende: libenchant-2-2 (= 2.2.15-1) ma la 
versione 2.3.3-2 sta per essere installata

 Dipende: libglib2.0-dev ma non è installabile
  libmagic-dev : Dipende: libmagic1 (= 1:5.39-3) ma la versione 
1:5.41-4 sta per essere installata
  libmythes-dev : Dipende: libmythes-1.2-0 (= 2:1.2.4-3+b1) ma la 
versione 2:1.2.5-1 sta per essere installata
E: Impossibile correggere i problemi, ci sono pacchetti danneggiati 
bloccati.



Maybe I must downgrade also these packages!

Stefano


Hi Stefano,

unfortunately, I'm not able to reproduce the error you're seeing. 
Therefore, I'm downgrading the bug's severity to important, to avoid 
LyX being removed from the next Debian stable release.


I suspect that the error you're experiencing comes from another 
package, which has to do with the graphic environment you're using. I 
have no idea, which package that might be, though.


Sorry that I cannot provide any more useful ideas to narrow down this 
bug.


Regards,
Tobias





Bug#919348: bring it in for Bookworm?

2023-01-22 Thread Adam Borowski
Hi!
Would you be willing to reconsider for Bookworm?

While you do have reservations about xfce4-screensaver, the question is
not whether it's perfect, but how it fares against alternatives.  And
lightm-locker is so buggy it's outright useless for a good deal of users
while reports for xfce4-screensaver are better.

Thus even if not default, it'd be good to have it as an alternative --
at least installable.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Let's make a Debian conference in Yalta, Ukraine.
⢿⡄⠘⠷⠚⠋⠀
⠈⠳⣄



Bug#1029484: linux: Enable Intel Uncore frequency control driver

2023-01-22 Thread Miguel Bernal Marin
Source: linux
Version: 6.1.7-1
Severity: wishlist
X-Debbugs-Cc: miguel.bernal.ma...@linux.intel.com, 
jair.de.jesus.gonzalez.plascen...@intel.com

Dear Maintainer,

Please enable the Intel Uncore frequency control driver.
This driver allows control of uncore frequency limits on
supported server platforms.

# Intel Uncore frequency control driver

  CONFIG_INTEL_UNCORE_FREQ_CONTROL=m

  Some server users set limits on the uncore frequency using MSR 620H, while
  running latency sensitive workloads. This driver "the uncore frequency",
  controls RING/LLC (last-level cache) clocks.

  But MSR control is not always possible from the user space, so this driver
  provides a sysfs interface to set max and min frequency limits. This MSR
  620H is a die scoped in multi-die system or package scoped in non multi-die
  systems.

  When this driver is loaded, a new directory is created under
   /sys/devices/system/cpu.

  For example on a two package Skylake server:
  $ cd /sys/devices/system/cpu/intel_uncore_frequency

  $ ls
  package_00_die_00 package_01_die_00

  $ ls package_00_die_00
  max_freq_khz  min_freq_khz  initial_max_freq_khz
  initial_min_freq_khz

  $ grep . *
  max_freq_khz:240
  min_freq_khz:120
  initial_max_freq_khz:240
  initial_min_freq_khz:120

  Here, initial_max_freq_khz and initial_min_freq_khz are read only
  attributes to show power up or initial values of max and min frequencies
  respectively. Other attributes are read-write, so that users can modify.

A merge request was created at:

https://salsa.debian.org/kernel-team/linux/-/merge_requests/645

Thanks,
Miguel



Bug#1023752: visidata: New upstream version: v2.10.2 (Oct 8, 2022)

2023-01-22 Thread Anja
Oh! Ty! What's your personal deadline so you have time to review?

I will talk with the author, Saul. Nothing is coming up that is a
dealbreaker for 2.11, so as far as I understand it that is the one we are
going to go with. Either that or 2.10.2.

On Sat, 21 Jan 2023 at 16:47, Martin  wrote:

> Hi,
>
> now is almost the last chance to get a current visidata into the next
> Debian release. What's the state of the package?
>
> Cheers
>


Bug#1017497: closed by Debian FTP Masters (reply to Jochen Sprickerhof ) (Bug#1017497: fixed in pnc 0.9.4-1)

2023-01-22 Thread Jochen Sprickerhof

Hi Paul,

* Paul Wise  [2023-01-23 08:46]:

On Sun, 2023-01-22 at 14:09 +, Debian Bug Tracking System wrote:


 pnc (0.9.4-1) unstable; urgency=medium
 .
   [ Tzafrir Cohen ]
   * Include READMEs in docs dir (Closes: #1017497)


I think this was closed by the wrong package?
I filed it against pn not pnc.


Sorry, I should have added more information. Upstream development of pn 
stalled and we are switching to the active pnc fork.
Given that pn was never part of a release and the name is rather short 
and non explaining, I would just drop it. This also means that the 
executable is now named pnc.


Cheers Jochen


signature.asc
Description: PGP signature


Bug#1029483: mmdebstrap: ld.so.cache unreproducible inside initrd for --mode=fakechroot

2023-01-22 Thread Helmut Grohne
Package: mmdebstrap
Version: 1.3.1-2
Severity: minor
Tags: patch

Hi Johannes,

while this is not the cause for my funny ppc64el and s390x boot
failures, I think this is worth fixing anyhow, so here we go:

When --mode=chroot wraps ldconfig, it overwrites and -r argument. As it
happens mkinitramfs passes -r to ldconfig. When mmdebstrap's ldconfig
intercepts that, it overwrites that -r and the initramfs ends up missing
a ld.so.cache, which should be non-fatal, but is a difference anyhow.

I've tried fixing this and my final solution ended up with a ld.so.cache
(even though it still wouldn't boot, but that's another problem). Please
take this patch with a grain of salt.

Helmut
--- a/ldconfig.fakechroot
+++ b/ldconfig.fakechroot
@@ -106,10 +106,24 @@
 for d in get_libdirs(chroot, [chroot / "etc" / "ld.so.conf"]):
 make_relative(d)
 
+rootarg = chroot
+argv = sys.argv[1:]
+for arg in sys.argv[1:]:
+if arg == "-r":
+rootarg = None
+elif rootarg is None:
+argpath = Path(arg)
+if argpath.is_absolute():
+rootarg = chroot / argpath.relative_to("/")
+else:
+rootarg = Path.cwd() / argpath
+if rootarg is None:
+rootarg = chroot
+
 # we add any additional arguments before "-r" such that any other "-r"
 # option will be overwritten by the one we set
 subprocess.check_call(
-[chroot / "sbin" / "ldconfig"] + sys.argv[1:] + ["-r", chroot]
+[chroot / "sbin" / "ldconfig"] + sys.argv[1:] + ["-r", rootarg]
 )
 
 


Bug#960272: postfix: message_size_limit ignored if set to 0, and maximum is 2GiB

2023-01-22 Thread Scott Kitterman
On Thu, 23 Dec 2021 22:25:32 -0500 Scott Kitterman  
wrote:
> On Mon, 11 May 2020 13:40:28 +0200 Peter Keel  wrote:
> > Package: postfix
> > Version: 3.4.10-0+deb10u1
> > Severity: wishlist
> > Tags: upstream
> > 
> > Hello
> > 
> > Trying to set the postfix message_size_limit to 0 (educated guess
> > for unlimited) will just have it use the compile-time-default of
> > 1024.
> > 
> > And then it turns out if you set it quite high, it will complain: 
> > fatal: bad numerical configuration: message_size_limit = 2147483648 
> > 
> > Because the maximum is actually 2147483647 (one less than 2 GiB)
> > Why would it have a maximum? 
> 
> It turns out that's LONG_MAX on a 32 bit machine.  Upstream has updated the 
> documentation for Postfix 3.7 to explain this.  I think for a limitation like 
> this a documentation update is the appropriate solution.

We have 3.7 in Unstable/Testing now, so this has been addressed.

Scott K

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


Bug#989901: re: postfix: ipv6 CIDR not correct in mynetwork documentation

2023-01-22 Thread Scott Kitterman
On Mon, 03 Jan 2022 14:32:45 -0500 Scott Kitterman  
wrote:
> Proposed documentation changes will be included in postfix 3.7 when it is 
> released.

3.7 is in Unstable/Testing now, so this is resolved.

Scott K

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


Bug#1021713: CalyxOS cannot be installed from Debian 11 since it has very old fastboot version

2023-01-22 Thread Roger Shimizu
control: severity -1 wishlist

src:android-platform-tools provides binary fastboot, and you can
easily install version 29, which is even in bullseye backports.
if you need version 30 or above, it's in experimental only.



Bug#1029476: tuxguitar: arch-any build fails with current build system

2023-01-22 Thread tony mancill
On Sun, Jan 22, 2023 at 05:48:21PM -0800, tony mancill wrote:
> Package: tuxguitar
> Version: 1.5.6+dfsg1-3
> Severity: important
> 
> The build system doesn't correctly build the arch-any packages when only
> the arch specific targets are invoked.  

In the interest of getting the package into shape quickly for bullseye,
I'm considering switching the arch-all packages to arch-any. This
resolves the arch-any build issue until the upstream build system can be
patched to work better with a separate arch-all and arch-any builds.
The package has never been multi-arch.

If any is opposed or would like to put up a patch, please speak up.



Bug#1029482: git-cola: New upstream version 4.1.0

2023-01-22 Thread David Aguilar
Package: git-cola
Version: 4.1.0-1
Severity: wishlist

Dear Maintainer,

git-cola has not been recently updated due to Breaking Changes in its Python
build system (distutils deprecations, PEP-517/518).

https://github.com/git-cola/git-cola/issues/1231#issuecomment-1136733246


I took at stab at updating the debian packaging and have made the updates
available in this public repository:

https://github.com/davvid/git-cola-debian/

The new packaging should get us over the 3.x -> 4.x breaking changes hurdle.

https://github.com/davvid/git-cola-debian/commits/main

The "debian: update packaging to 3.12.0-2" commit synced the repository with
the latest version in debian, last packaged by g...@debian.org.

The new commits (post the 3.12.0 import) got it to deal with issues in
setuptools_scm and pip install --prefix=/usr.


An interesting detail is that the updated packaging contains two workarounds
for issues that affect Debian. Any project using setuptools_scm [1] or "pip
install --prefix=/usr" [2] may be in a similar boat until the upstream issues
are resolved. Hopefully these workarounds are acceptable for now.

https://github.com/davvid/git-cola-debian/blob/main/debian/rules#L8

https://github.com/davvid/git-cola-debian/blob/main/debian/rules#L17


History:

The git-cola-debian packaging repository is derived from the debian packaging
originally hosted on aioth.debian.org:

https://alioth-archive.debian.org/git/collab-maint/git-cola.git.tar.xz

git-cola-debian's history is truncated. I did not have the sources for any of
the intermediate versions from gcs that were being managed using quilt so there
are no commits corresponding to them.

I'm also the upstream for this package so I'd like to help keep the Debian
packaging up to date.

Thanks!


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

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

Versions of packages git-cola depends on:
ii  git [git-core]  1:2.39.0-1
ii  libjs-jquery3.6.1+dfsg+~3.5.14-1
ii  libjs-modernizr 2.6.2+ds1-5
ii  libjs-underscore1.13.4~dfsg+~1.11.4-3
ii  node-html5shiv  3.7.3+dfsg-5
ii  python3 3.10.6-3+b1
ii  python3-importlib-metadata  4.12.0-1
ii  python3-pyqt5   5.15.7+dfsg-3+b3
ii  python3-qtpy2.3.0-1
ii  python3-send2trash  1.8.1~b0-2

Versions of packages git-cola recommends:
ii  gitk 1:2.39.0-1
ii  tcl [tclsh]  8.6.11+1
ii  xxdiff   1:5.1+git20220924+dfsg-1

git-cola suggests no packages.

-- no debconf information



Bug#1029481: yq: unmodified incorrect package description from debmake template

2023-01-22 Thread Paul Wise
Package: yq
Version: 3.1.0-1
Severity: serious

The current description of the yq package is rather bogus.
It appears that the debmake template was not modified.

   $ apt-cache show yq | grep-dctrl -s Description-en .
   Description-en: auto-generated package by debmake
This Debian binary package was auto-generated by the
debmake(1) command provided by the debmake package.

   $ chronic apt source -qq yq
   $ head -n1 yq*/README*
   yq: Command-line YAML/XML/TOML processor - jq wrapper for YAML, XML, TOML 
documents
   
   $ dgrep -A5 'auto-generated' debmake
   /usr/lib/python3/dist-packages/debmake/control.py:desc = 
"auto-generated package by debmake"
   /usr/lib/python3/dist-packages/debmake/control.py-#
   /usr/lib/python3/dist-packages/debmake/control.py-if 
para["desc_long"].rstrip():
   /usr/lib/python3/dist-packages/debmake/control.py-desc_long = 
para["desc_long"].rstrip()
   /usr/lib/python3/dist-packages/debmake/control.py-elif 
para["desc"].strip():
   /usr/lib/python3/dist-packages/debmake/control.py-desc_long = " " + 
para["desc"].strip()
   --
   /usr/lib/python3/dist-packages/debmake/para.py:help="pedantically 
check auto-generated files",
   /usr/lib/python3/dist-packages/debmake/para.py-)
   /usr/lib/python3/dist-packages/debmake/para.py-p.add_argument(
   /usr/lib/python3/dist-packages/debmake/para.py-"-T",
   /usr/lib/python3/dist-packages/debmake/para.py-"--tutorial",
   /usr/lib/python3/dist-packages/debmake/para.py-action="store_true",
   --
   /usr/share/debmake/extra0desc_long/_long: This Debian binary package was 
auto-generated by the
   /usr/share/debmake/extra0desc_long/_long- debmake(1) command provided by the 
debmake package.
   --
   /usr/share/debmake/extra0desc_long/_long_tutorial: This Debian binary 
package was auto-generated by the
   /usr/share/debmake/extra0desc_long/_long_tutorial- debmake(1) command 
provided by the debmake package.
   /usr/share/debmake/extra0desc_long/_long_tutorial- .
   /usr/share/debmake/extra0desc_long/_long_tutorial- = This comes from the 
unmodified template file =
   /usr/share/debmake/extra0desc_long/_long_tutorial- .
   /usr/share/debmake/extra0desc_long/_long_tutorial- Please edit this template 
file (debian/control) and other package files

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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


Bug#1026200: Please package LilyPond 2.24.0 if possible

2023-01-22 Thread Rob Browning
Anthony Fok  writes:

> Thank you so much for Cc'ing Rob regarding Guile-2.2.
>
> Rob, as you can see, there is a real need for Guile 2.2 for LilyPond
> 2.24.0 (December 2022), this coming from LilyPond's Core Developer
> Jonas Hahnfeld and "Factotum" and Jean Abou Samra.  If it is OK with
> you, Rob, I would be more than happy to adopt guile-2.2 and maintain
> it for the entire lifetime of Debian 12 (bookworm), and hopefully by
> Debian 13 (trixie), LilyPond will be ready for guile-3.0.  :-)\
> Many thanks for your understanding!

I'd be very hesitant to include Guile 2.2 in bookworm since I believe
it's explicitly not supported upstream and hasn't had a single commit
in over two years.

If there's any chance LilyPond will support something newer in a
reasonable time-frame, I might suggest just waiting, and then
introducing the new version via backports.

But I don't really understand the situation and constraints.

That said, I won't oppose reintroducing 2.2, as long as I'm not
responsible for it, and you're willing to herd all the cats to get it
removed again as soon as possible.  That was a good bit of work I'd
prefer not to repeat.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4



Bug#1029480: python3-poetry should depend on python3-importlib-metadata (>= 3.6.0)

2023-01-22 Thread Puzzlet Chung
Package: python3-poetry
Version: 1.3.2+dfsg-2

Having installed python3-poetry  1.3.2+dfsg-2 (from bookworm) and
python3-importlib-metadata 1.6.0-2 (from bullseye), running poetry gives
following error:


$ poetry -v

  TypeError

  entry_points() got an unexpected keyword argument 'group'

  at /usr/lib/python3/dist-packages/poetry/plugins/plugin_manager.py:57 in
get_plugin_entry_points
   53│ self, env: Env | None = None
   54│ ) -> list[metadata.EntryPoint]:
   55│ return [
   56│ ep
→  57│ for ep in metadata.entry_points(group=self._group)
   58│ if self._is_plugin_candidate(ep, env)
   59│ ]
   60│
   61│ def add_plugin(self, plugin: Plugin) -> None:


metadata.entry_point() has allowed arguments since 3.6.0; [1] so dependency
should be added to the package metadata.

[1]
https://github.com/python/importlib_metadata/commit/8320adef797d5f14d9fff7b58ebc2a31a2a6a437


Bug#1029479: lintian: reject packages with debmake default description

2023-01-22 Thread Paul Wise
Package: lintian
Severity: wishlist
X-Debbugs-CC: ftp-master 

yq was just accepted into Debian with a completely bogus description
that is the default from the debmake automatic package generator.

Please add a lintian tag and add it to the ftp-master auto-rejects.

   $ apt-cache show yq | grep-dctrl -s Description-en .
   Description-en: auto-generated package by debmake
This Debian binary package was auto-generated by the
debmake(1) command provided by the debmake package.

   $ dgrep -A5 'auto-generated' debmake
   /usr/lib/python3/dist-packages/debmake/control.py:desc = 
"auto-generated package by debmake"
   /usr/lib/python3/dist-packages/debmake/control.py-#
   /usr/lib/python3/dist-packages/debmake/control.py-if 
para["desc_long"].rstrip():
   /usr/lib/python3/dist-packages/debmake/control.py-desc_long = 
para["desc_long"].rstrip()
   /usr/lib/python3/dist-packages/debmake/control.py-elif 
para["desc"].strip():
   /usr/lib/python3/dist-packages/debmake/control.py-desc_long = " " + 
para["desc"].strip()
   --
   /usr/lib/python3/dist-packages/debmake/para.py:help="pedantically 
check auto-generated files",
   /usr/lib/python3/dist-packages/debmake/para.py-)
   /usr/lib/python3/dist-packages/debmake/para.py-p.add_argument(
   /usr/lib/python3/dist-packages/debmake/para.py-"-T",
   /usr/lib/python3/dist-packages/debmake/para.py-"--tutorial",
   /usr/lib/python3/dist-packages/debmake/para.py-action="store_true",
   --
   /usr/share/debmake/extra0desc_long/_long: This Debian binary package was 
auto-generated by the
   /usr/share/debmake/extra0desc_long/_long- debmake(1) command provided by the 
debmake package.
   --
   /usr/share/debmake/extra0desc_long/_long_tutorial: This Debian binary 
package was auto-generated by the
   /usr/share/debmake/extra0desc_long/_long_tutorial- debmake(1) command 
provided by the debmake package.
   /usr/share/debmake/extra0desc_long/_long_tutorial- .
   /usr/share/debmake/extra0desc_long/_long_tutorial- = This comes from the 
unmodified template file =
   /usr/share/debmake/extra0desc_long/_long_tutorial- .
   /usr/share/debmake/extra0desc_long/_long_tutorial- Please edit this template 
file (debian/control) and other package files

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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


Bug#273194: xterm: characters from paste buffer lost at roughly 4kB intervals [kernel pty bug?]

2023-01-22 Thread Vincent Lefevre
On 2006-10-14 15:56:10 -0400, Thomas Dickey wrote:
> On Sat, Oct 14, 2006 at 08:20:14PM +0200, Andrew Moise wrote:
> >  I still see this misbehavior with xterm 210-3.1 and
> > linux-image-2.6.17-2-686 2.6.17-9.
> 
> I can see it (now) with a 2.6.15 kernel (814 lines copied).
> I also note that Branden got no followup from the kernel people.

This also occurs with

Linux zira 6.1.0-2-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.7-1 (2023-01-18) 
x86_64 GNU/Linux

and xterm, mlterm and GNOME Terminal at least. This would confirm
a kernel pty bug (unless this is a documented pty limitation, in
which case the applications would have to take it into account...
but they could try to implement a workaround in any case).

For me, with the above kernel, the limit is 4095 bytes.

An annoying consequence is that Ctrl-C no longer works, which can
yield buggy commands executed by the shell after an accidental
paste while a foreground X command is running (presumably because
bracketed paste is not in effect, so that each newline character
validates each line as a command). See
  https://lists.debian.org/debian-user/2023/01/msg00520.html

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



Bug#1029478: RM: skesa [i386 x32] -- ANAIS; build dependencies unavailable

2023-01-22 Thread Aaron M. Ucko
Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: sk...@packages.debian.org
Control: affects -1 + src:skesa

Per other recent removal requests[1][2][3], skesa's build dependencies
are available only on amd64 and (now) arm64 at this point; as such,
please remove skesa (and skesa-dbg) on i386 and x32.  Thanks!

[1] https://bugs.debian.org/1029472
[2] https://bugs.debian.org/1029474
[3] https://bugs.debian.org/1029475



Bug#1029477: RM: dictionary-el -- ROM; redundant as of emacs 28

2023-01-22 Thread Aaron M. Ucko
Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: dictionary...@packages.debian.org
Control: affects -1 + src:dictionary-el

Because dictionary-el uses dh-elpa these days, it integrates only with
GNU Emacs, which however incorporated the package into its standard
library as of version 28.  Upstream has been inactive, so there's not
even any marginal benefit to having a second copy at this point.
(There would be some marginal benefit with XEmacs, which ships an
older version, but that older version is good enough as far as I'm
concerned, particularly given that I'd have to revert to old-school
packaging to do anything about it.)

Please go ahead and remove this package at your convenience.

Thanks!



Bug#1029476: tuxguitar: arch-any build fails with current build system

2023-01-22 Thread tony mancill
Package: tuxguitar
Version: 1.5.6+dfsg1-3
Severity: important

The build system doesn't correctly build the arch-any packages when only
the arch specific targets are invoked.  


signature.asc
Description: PGP signature


Bug#1029475: RM: ngs-sdk -- ROM; subsumed by sra-sdk 3.x

2023-01-22 Thread Aaron M. Ucko
Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: sra-...@packages.debian.org
Control: affects -1 + src:sra-sdk

sra-sdk 3.x subsumed ngs-sdk, albeit with only partial overlap because
the C library changed both its basename and its SO version along the
way.  Also, the two binary packages that carried over became
architecture-independent.  As such, please remove libngs-sdk2,
libngs-sdk2-dbg, and libngs-sdk-dev altogether, and libngs-java and
python3-ngs for all architectures *EXCEPT* all.

Thanks!



Bug#1029474: RM: sra-sdk [i386 x32] -- ANAIS; requires a 64-bit address space

2023-01-22 Thread Aaron M. Ucko
Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: sra-...@packages.debian.org
Control: affects -1 + src:sra-sdk

Fully building sra-sdk requires a 64-bit address space these days.
It might be possible to contrive to build some of its binary packages
on architectures with 32-bit address spaces, or even on architectures
ncbi-vdb doesn't support, but I'm not convinced it's worth the
effort.  As such, could you please remove sra-toolkit (and
sra-toolkit-dbg) on i386 and x32?  (I mentioned plural packages above,
but that's only the case for 3.x, which had this requirement all along.)

Thanks!



Bug#1029473: gnome-session: Automatic Suspend should not be enabled by default

2023-01-22 Thread Witold Baryluk
Package: gnome-session
Version: 43.0-1
Severity: normal
X-Debbugs-Cc: witold.bary...@gmail.com


Rather annoying issue. In my opinion it might even deserve "grave" severity.

It appears in Power settings, Automatic Suspend is On by default (with 20
minutes delay).

Here is the problem.

I am on a desktop PC, always on, and have programs in a background that
must run non stop or for many hours (i.e. data acquisition / monitoring,
long running scripts, simulations, etc). I often use Live-CD (custom
built Debian iso using live-build), so I relay on defaults a lot. But
suspend to RAM is often broken on computers I use, and it often never
recovers, needing me to power cycle the computer, or even disconnect
power, waiting and connect power again. (long pressing power button does
not help). And even if it works, often a state of USB devices is lost,
which I have few (including the root file system).

So last time I used my system, after almost 10 hours of work, I went for
a break and some food, while some processes were running in a background.
Then came back about 30 minutes later, system was not responding
(monitors off, USB devices off, keyboard not doing anything), and power
button was blinking. Pressing it did not help, and needed to remove power
(at power supply), and connect back. Many hours of work lost.

I do not normally use Gnome Shell (I normally use MATE), but I accidently
logged into Gnome Shell, and wanted to give it a try. First time this
occured, I was really surprised, and I was thinking maybe it was a kernel
bug (I often use rc kernels). But it happened again on another kernel
version.

As I use Live-CD quite often, just changing a value is not an option
manually, as these settings will be lost after reboot. Not to mention
they are not intuitive for a novice user of Gnome Shell.

I do not understand why Automatic Suspend would be On by default.
Especially if the default power mode profile is Balanced (not Power
Saver).

A way better idea would be to detect a computer form factor, and power
source. If it is battery (i.e. not AC and not charging), then maybe do
enable a suspend. Otherwise no.

I also do not understand why Screen Blank in Power Saving Options is
"Never". A default should be few minutes.


Regards,
Witold



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

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

Versions of packages gnome-session depends on:
ii  gnome-session-bin  43.0-1
ii  gnome-session-common   43.0-1
ii  gnome-settings-daemon  43.0-3
ii  gnome-shell43.1-2
ii  xdg-desktop-portal-gnome [xdg-desktop-portal-backend]  43.1-2
ii  xdg-desktop-portal-gtk [xdg-desktop-portal-backend]1.14.1-1
ii  xdg-desktop-portal-kde [xdg-desktop-portal-backend]5.26.4-1+b1
ii  xdg-desktop-portal-wlr [xdg-desktop-portal-backend]0.6.0-1

gnome-session recommends no packages.

Versions of packages gnome-session suggests:
ii  desktop-base   12.0.2
ii  gnome-keyring  42.1-1+b1

-- no debconf information



Bug#1029472: RM: ncbi-vdb [i386] -- ANAIS; upstream fully dropped i386 support

2023-01-22 Thread Aaron M. Ucko
Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: ncbi-...@packages.debian.org
Control: affects -1 + src:ncbi-vdb

ncbi-vdb 3.x switched to a new build system that supports only a
narrow list of architectures, with specific associated settings.  i386
isn't on the list, and arranging to add it isn't worth the trouble,
particularly given that ncbi-vdb's reverse dependencies mostly require
a 64-bit address space these days anyway.  (I'll file selective
removal requests for them shortly.)

As such, could you please remove i386 packages built from ncbi-vdb?
FTR, the relevant binary packages are

libncbi-vdb2
libncbi-vdb2-dbg
libncbi-vdb-dev
libkdf5-2
libkdf5-2-dbg
libkdf5-dev
libncbi-wvdb2
libncbi-wvdb2-dbg
libncbi-wvdb-dev
libvdb-sqlite2
libvdb-sqlite2-dbg
libvdb-sqlite-dev

Thanks!



Bug#1014885: lintian wrongly complains about XS-Go-Import-Path

2023-01-22 Thread Axel Beckert
Control: clone -1 2
Control: retitle -2 lintian: Needs to distinguish between valid field names for 
.dsc files and for debian/control files (with vs without "XS-" prefix)
Control: tag -1 + pending
Control: tag -2 + help

Hi,

Holger Levsen wrote:
> I can confirm this issue for lintian 2.116.0 against src:piuparts
> as it is in git or unstable.

I can confirm as well. Unfortunately this is not as trivial to fix
properly as it seems:

A) Lintian currently doesn't seem to make a difference between the
   fields in the .dsc file and those in the debian/control file. But
   especially these XS-* fields exactly need that differentiation.

B) If I add Autobuild, Go-Import-Path, and Ruby-Versions to
   data/common/source-fields, the test suite shows that then these
   lintian tags would fire although they shouldn't (according to the
   test suite):

   adopted-extended-field (in section for source) XS-Go-Import-Path
   adopted-extended-field (in section for source) XS-Autobuild

So for now I have no idea except for hardcoding these three inside the
source function in lib/Lintian/Check/Fields/Unknown.pm. But this feels
wrong.

This though might lead to false negatives if someone uses e.g.
Go-Import-Path without the "XS-" prefix in debian/control.

What would be worse: The current false positives or the potential
false negatives?

I assume that any potential false negative on these
three fields will cause package breakage at build time (wrong Ruby
versions, some Go stuff not working, non-free packages not
autobuilding, etc.), so that we can cope with them.

Cloning this bug report to document that we need a rewrite of
Lintian::Check::Fields::Unknown and module dependencies to distinguish
between .dsc fields and debian/control fields with a common subset.
And maybe with the one set being calculated from the other set by
stripping the XS- prefix.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE



Bug#1017497: closed by Debian FTP Masters (reply to Jochen Sprickerhof ) (Bug#1017497: fixed in pnc 0.9.4-1)

2023-01-22 Thread Paul Wise
On Sun, 2023-01-22 at 14:09 +, Debian Bug Tracking System wrote:

>  pnc (0.9.4-1) unstable; urgency=medium
>  .
>    [ Tzafrir Cohen ]
>    * Include READMEs in docs dir (Closes: #1017497)

I think this was closed by the wrong package?
I filed it against pn not pnc.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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


Bug#421307: wmusic should work audacious

2023-01-22 Thread Paul Wise
On Fri, 27 Apr 2007 11:46:44 -0700 Huaqing Zheng wrote:

> Package: wmusic
> 
> It would be nice if wmusic could detect the presence of audacious and
> work with audacious as well as xmms.

wmusic 2.1.0-2 has been reintroduced into Debian unstable.

Please try it and see if the issue has been fixed.

If the issue has been fixed, please let us know on this bug.

If the issue has not been fixed, please search the upstream bug
databases to see if the issue is already reported and if it is not
reported, then report a new issue upstream and or contact the upstream
mailing lists. Please let us know about any new or existing upstream
bugs you file or find.

https://www.windowmaker.org/lists/
https://github.com/window-maker/dockapps/issues

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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


Bug#348581: wmusic: segmentation falut on xmms with crossfade

2023-01-22 Thread Paul Wise
On Tue, 17 Jan 2006 14:02:45 -0600 Jerome Verleyen wrote:

> Package: wmusic
> 
> When using crossfade ouptut plugin on xmms, i can't use
> wmusic. As soon as wmusic start, the xmms stay fridged.
> And i see a "segmentation fault" on the screen.

wmusic 2.1.0-2 has been reintroduced into Debian unstable.

Please try it and see if the issue has been fixed.

If the issue has been fixed, please let us know on this bug.

If the issue has not been fixed, please search the upstream bug
databases to see if the issue is already reported and if it is not
reported, then report a new issue upstream and or contact the upstream
mailing lists. Please let us know about any new or existing upstream
bugs you file or find.

https://www.windowmaker.org/lists/
https://github.com/window-maker/dockapps/issues

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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


Bug#326608: wmusic: -u does not work

2023-01-22 Thread Paul Wise
On Sun, 04 Sep 2005 15:10:57 +0200 Stefan Märkl wrote:

> Package: wmusic
> 
> The -u options does not close the xmms window. Neither when using -r/-R,
> nor the window of an already running xmms.
> 
> Window manager: openbox

wmusic 2.1.0-2 has been reintroduced into Debian unstable.

Please try it and see if the issue has been fixed.

If the issue has been fixed, please let us know on this bug.

If the issue has not been fixed, please search the upstream bug
databases to see if the issue is already reported and if it is not
reported, then report a new issue upstream and or contact the upstream
mailing lists. Please let us know about any new or existing upstream
bugs you file or find.

https://www.windowmaker.org/lists/
https://github.com/window-maker/dockapps/issues

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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


Bug#231357: wmusic: could not allocate -1073742836 bytes

2023-01-22 Thread Paul Wise
On Thu, 05 Feb 2004 20:25:13 -0500 Moses Moore wrote:

> Package: wmusic
> 
> Program occassionally crashes, with error message on stderr:
>   GLib-ERROR **: could not allocate -1073742836 bytes
>   aborting...

wmusic 2.1.0-2 has been reintroduced into Debian unstable.

Please try it and see if the issue has been fixed.

If the issue has been fixed, please let us know on this bug.

If the issue has not been fixed, please search the upstream bug
databases to see if the issue is already reported and if it is not
reported, then report a new issue upstream and or contact the upstream
mailing lists. Please let us know about any new or existing upstream
bugs you file or find.

https://www.windowmaker.org/lists/
https://github.com/window-maker/dockapps/issues

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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


Bug#1029250: meson: FTBFS: ./b 52a78b9866/../test cases/failing build/2 hidden symbol/bobuser.c:4: undefined reference to `hidden_function'

2023-01-22 Thread Jussi Pakkanen
On Fri, 20 Jan 2023 at 13:06, Lucas Nussbaum  wrote:

> Relevant part (hopefully):
> > /usr/bin/ld: bobuser.p/bobuser.c.o: in function `main':
> > ./b 52a78b9866/../test cases/failing build/2 hidden symbol/bobuser.c:4: 
> > undefined reference to `hidden_function'
> > collect2: error: ld returned 1 exit status

This is the umpteenth time this has been reported and the error
message is as wrong as always. The actual error has to do with TAP
parsing. It should be fixed by this, which will be in the next point
release:

https://github.com/mesonbuild/meson/pull/11324



Bug#1022843: Bug#1029352: Bug#1022843: ifupdown: network down after systemctl restart

2023-01-22 Thread Pascal Hambourg

Oleg A. Arkhangelsky wrote:

Note that we have to use '--ignore-errors'. Otherwise if we have real
hotplug interface that is not present at the moment of restart, `ifup`
returns non-zero and systemd unit fail.


"--ignore-errors" marks missing interfaces as configured, so ifup will 
not configure them when invoked by udev. In order to not fail the 
systemd unit start on ifup error, you can prefix the command with "-".


On 22/01/2023 at 20:58, Cyril Brulebois wrote:


with an extra ens3 declared as auto, the following seems to work fine
for boot-up, stop and start, and restart:

 [Service]
 Type=oneshot
 EnvironmentFile=-/etc/default/networking
 ExecStart=/sbin/ifup -a --read-environment
 ExecStart=/bin/sh -c 'if [ -f /run/network/restart-hotplug ]; then 
/sbin/ifup -a --read-environment --allow=hotplug; fi'
 ExecStop=/sbin/ifdown -a --read-environment --exclude=lo
 ExecStopPost=/usr/bin/touch /run/network/restart-hotplug
 RemainAfterExit=true
 TimeoutStartSec=5min


That seems needlessly convoluted. What about this:

[Service]
Type=oneshot
EnvironmentFile=-/etc/default/networking
ExecStart=/sbin/ifup -a --read-environment
ExecStart=-/sbin/ifup -a --read-environment --allow=hotplug
ExecStop=/sbin/ifdown -a --read-environment --exclude=lo
RemainAfterExit=true
TimeoutStartSec=5min

"start" and "restart" configure all existing "auto" and "allow-hotplug" 
interfaces.
Missing "allow-hotplug" interfaces do not be marked as configured (so 
that they can be configured by udev) and do not make "start" or 
"restart" fail.




Bug#1018235: sgt-puzzles: Updated German man page / halibut translation

2023-01-22 Thread Ben Hutchings
On Sat, 2022-08-27 at 17:21 +0200, Helge Kreutzmann wrote:
> Package: sgt-puzzles
> Version: 20220801.89391ba-1
> Severity: wishlist
> Tags: patch l10n
> 
> The last update reminded me to actually use sgt-puzzles (had not done
> so for quite some time) and since I had forgotten the rules, I read my
> own translation and spotted some typos. Once you upload your next
> version, could you include the updated de.po (attached)?

Thanks, I've now applied these changes in Git.


> Finally I noticed that you are in quite close contact with upstream. I
> noticed that some links in the documentation are broken, e.g.
> http://www.nikoli.com/en/puzzles/slitherlink.html
> 
> Maybe upstream wants to review this? (I can open a separate bug if
> you want).

These have since been fixed upstream (without my intervention).

I've prepared an update to the current upstream version and pushed that
to Salsa.  Note that I gave up on using git-debrebase, so you again
need to run "QUILT_PATCHES=debian/patches quilt push -a" to create the
po/de.po file.

I've updated the translations for some strings that became fuzzy
(commit dfcf98bb) but there is still one new untranslated string. 
Could you have a look at that?

Ben.

-- 
Ben Hutchings
Beware of bugs in the above code;
I have only proved it correct, not tried it. - Donald Knuth


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


Bug#1015123: latex-cjk-chinese-arphic: FTBFS: E: Build killed with signal TERM after 150 minutes of inactivity

2023-01-22 Thread Hilmar Preuße

Am 21.01.2023 um 16:05 teilte Danai SAE-HAN (韓達耐) mit:

Hi Danai,


Indeed, I have tested it yesterday too and the scripts now breeze through
without bailing out.
I would like to keep the bug, and will solve it by adding a versioned
build-dependency on Fontforge to ensure it will always build properly.


Please keep in mind, that I've accepted a pull request from Janitor for
the package. So, please issue "git pull" before working on the package.

Hilmar
--
sigfault



Bug#1024041: mariadb-10.6: FTBFS on riscv64: rocksdb/db/memtable.cc:129: undefined reference to `__atomic_compare_exchange_1'

2023-01-22 Thread Otto Kekäläinen
Control: tags -1 patch

Hi!

You are right, I missed
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1024041;filename=mariadb-fix-ftbfs-riscv64.patch;msg=20

I will try this on next upload


Bug#1006130: ITP: sioyek -- Sioyek is a PDF viewer designed for reading research papers and technical books

2023-01-22 Thread James Addison
Package: wnpp
Followup-For: Bug #1006130

Thank you, Victor!



Bug#1029373: kernel panic on Odroid U2 with default environment

2023-01-22 Thread Joost van Zwieten


On Sat, Jan 21, 2023 at 17:46, Vagrant Cascadian  
wrote:

On 2023-01-21, Joost van Zwieten wrote:

 Booting a kernel with initrd using U-Boot from bullseye with default
 environment results in a kernel panic, because U-Boot loads the 
initrd
 in highmem [1]. The problem has been fixed upstream [2]. Please 
consider

 including the fix in bullseye. I've tested the attached patch, which
 applies to v2021.01 and which is a backport of the fix (variable
 `CONFIG_SYS_BOOTMAPSZ` has been renamed to `CFG_SYS_BOOTMAPSZ` in
 v2023.01).


Thanks!

Could you please also test against the version in unstable? Generally 
we

need fixes to go to unstable before backporting them to stable... and
given that bookworm will likely release this year, I would like for 
the

version in bookworm (currently based on upstream v2023.01) to work as
well...


Unfortunately I can't. In v2021.10 and v2023.01 two separate problems
were introduced [1], [2]. A fix for one of them is pending. For the
other I don't have an idea how to fix this yet (reverting a commit works
for me, but might break other boards).

[1]: https://lists.denx.de/pipermail/u-boot/2023-January/504116.html
[2]: https://lists.denx.de/pipermail/u-boot/2023-January/504115.html


Looks like the patch got merged upstream:

  
https://source.denx.de/u-boot/u-boot/-/commit/ace75d642fa71034b248cde30709c79e06c52d61


Would be good to include a link to the upstream fix in the comments of
the patch, and also explain that it is backported with regards to
CFG_SYS_BOOTMAPSZ vs. CONFIG_SYS_BOOTMAPSZ in the patch itself... it 
was

a little confusing to see the text of patch use one and the patch
describe another...


I've attached an updated patch.



live well,
  vagrant


>From 9926ea7e2103ad4ce390797c170aaf6993f5cb81 Mon Sep 17 00:00:00 2001
From: Joost van Zwieten 
Date: Sun, 15 Jan 2023 00:57:30 +0100
Subject: [PATCH] odroid: limit boot memory to lowmem

This patch prevents a kernel panic on the Odroid U2/U3 when booting a
kernel with initrd and default U-Boot environment (Debian bug #1029373,
discussion upstream: [1]). This patch is a backport of
ace75d642fa71034b248cde30709c79e06c52d61 [2] which has been merged into
upstream master *after* tagging v2023.01. Between v2022.10 and v2023.01
the variable `CONFIG_SYS_BOOTMAPSZ` has been renamed to
`CFG_SYS_BOOTMAPSZ`, which is accounted for in this backport.

[1]: https://lists.denx.de/pipermail/u-boot/2023-January/504469.html
[2]: https://source.denx.de/u-boot/u-boot/-/commit/ace75d642fa71034b248cde30709c79e06c52d61

The original (backported) commit message:

In commit 4963f63fe61f ("image: Use gd->ram_base/_size in
env_get_bootm_size()") the size of the available memory for U-Boot to
use when relocating images, and not otherwise constrained, was changed
to include all known memory banks. In the case of this platform however,
all of the memory known to U-Boot is not also part of the Linux kernel
"lowmem" and so we must use CONFIG_SYS_BOOTMAPSZ to limit where we
relocate images to. We set a conservative limit of 256MB here to mirror
the previous behavior.

Signed-off-by: Joost van Zwieten 
[trini: Reword the commit messsage]
Signed-off-by: Tom Rini 
---
 include/configs/odroid.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/odroid.h b/include/configs/odroid.h
index 1367d13891..dfb1eeb784 100644
--- a/include/configs/odroid.h
+++ b/include/configs/odroid.h
@@ -21,6 +21,7 @@
 
 #define CONFIG_MACH_TYPE	4289
 
+#define CONFIG_SYS_BOOTMAPSZ	0x1000
 #define CONFIG_SYS_SDRAM_BASE	0x4000
 #define SDRAM_BANK_SIZE		(256 << 20)	/* 256 MB */
 #define PHYS_SDRAM_1		CONFIG_SYS_SDRAM_BASE
-- 
2.30.2



Bug#1026503: libembperl-perl: FTBFS: Expected 6 more error(s) in logfile, tagging 1026503

2023-01-22 Thread Axel Beckert
Control: tag -1 + pending patch

Hi again.

Axel Beckert wrote:
> Axel Beckert wrote:
> > > Expected 6 more error(s) in logfile
[…]
> I looked a bit deeper into it, but didn't yet understand the issue
> fully yet.
> 
> Not forgotten, but I will only continue on it in the next days, […]

This took me quite a few hours to figure out. Not sure what exactly
changed in Debian Sid/Bookworm, but it might be even kernel or gcc
related.

The cause was intercepting STDERR into a file and reading from it
while the writing file handle is still open for the purpose analyzing
STDERR's content.

The relevant hint was this one in "perldoc -f seek":

  Due to the rules and rigors of ANSI C, on some systems you have
  to do a seek whenever you switch between reading and writing.
  Amongst other things, this may have the effect of calling
  stdio's clearerr(3). A WHENCE of 1 ("SEEK_CUR") is useful for
  not moving the file position:

  seek($fh, 0, 1);

So adding a "seek(ERR, 0, 1);" before "while () {" in test.pl
fixes the issue and doesn't open any new one.

Will upload soon. Will first need to clean up all the printf debug
mess I added to many places in test.pl. :-)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE



Bug#1029269: gio-2.0.pc references the wrong glib-compile-schemas again

2023-01-22 Thread Simon McVittie
On Fri, 20 Jan 2023 at 20:45:06 +0100, Helmut Grohne wrote:
> I had not questions the use of glib-compile-schemas. Thank you for doing
> it. Your arguments look reasonable to me. As far as I can see,
> ibus-unikey does not install a .compiled schema, so the call to
> glib-compile-schemas is probably redundant and questionable.

ibus-unikey does install
/usr/share/glib-2.0/schemas/org.freedesktop.ibus.engine.unikey.gschema.xml,
so in the absence of triggers, yes it would have to run
glib-compile-schemas. The function of g-c-s is to collect all the
*.gschema.xml (and possibly some less common files describing enums),
and summarize them in a single mmap'able binary file that doesn't require
spending time, malloc/free cycles and readdir calls on parsing multiple
XML files at runtime.

However, in a well-integrated distribution, dpkg triggers or equivalent
should be responsible for doing that - not individual packages.

A pattern I've often seen in GNOME is to run glib-compile-schemas as a
post-install hook if and only if $DESTDIR is empty or unset, so that when
compiling a dpkg/rpm/etc. package with something like

./configure --prefix=/usr   # or CMake/Meson equivalent
DESTDIR=$(pwd)/debian/tmp make install

we wouldn't run glib-compile-schemas (on the assumption that the package
manager will take responsibility), and would maybe show a warning "you
need to run glib-compile-schemas later" instead; but when doing a local
installation that is installed directly into place with something like

./configure --prefix=$HOME/jhbuild  # or CMake/Meson equivalent
make install

or

./configure --prefix=/opt/gnome # or CMake/Meson equivalent
make
sudo make install

each package would re-run glib-compile-schemas for convenience. This
mirrors how ldconfig tends to work, and I think this would be the ideal
thing for ibus-unikey to do as well.

Looking at
https://sources.debian.org/src/ibus-unikey/0.7.0~beta1-1/cmake/GSettings.cmake/
it seems that the build should be specifying -DGSETTINGS_COMPILE=OFF in
debian/rules, as a way to let the dpkg triggers take responsibility for
doing this later.

The other common reason to run glib-compile-schemas is so that unit tests
can find schemas in a temporary ($builddir) location at build-time, and
I think this should only be done if the build-time tests are actually going
to be run. In Debian terms, looking at
https://sources.debian.org/src/ibus-unikey/0.7.0~beta1-1/cmake/GSettings.cmake/
I think the nocheck build profile should be specifying
-DGSETTINGS_COMPILE_IN_PLACE=OFF (or maybe this particular package should
just have -DGSETTINGS_COMPILE_IN_PLACE=OFF unconditionally, I don't know
whether it even has build-time tests that want the schemas).

> Your
> request to disable such calls seems very reasonable to me. Would you
> prefer me trying to generally remove calls to glib-compile-schemas over
> changing glib2.0?

In the medium to long term, yes I would.

> After all of this insightful conversation, I see three ways of moving
> forward:
> 
> a. Accept the dependency cycle and make the per-architecture paths
>reference the one in /usr/bin.
> b. Change gio-2.0.pc to reference the /usr/bin one.
> c. Change upstream project to avoid unnecessary calls to
>glib-compile-schemas.
> 
> Do you concur that these are the options on the table? Which of them do
> you prefer? I admit that c looks appealing as it means least work for
> you and some work for me while a or b shifts that burden to you. ;)

I'd be OK with doing (b) as Debian downstream delta in the short term if
it would help, but in the medium to long term, I think the right way is
(c) (combined with Meson "native: true" or equivalent tool discovery if
feasible, but I realise that's probably only viable in Meson-world).

> >for triggers
> > libglib2.0-0 ---> glib-compile-schemas
> >  M-A: same   <---   M-A: foreign
> > via dpkg-shlibdeps
> 
> Is such a circular dependency actually a problem?

I would say yes if it can be avoided. Any time apt breaks a cycle, it's
doing something that's out-of-spec for the guarantees that we normally
use to reason about what is safe to assume.

Circular dependencies also make it harder to clean up unused packages,
because each package in the circle prevents the next one round the circle
from being diagnosed as unused...

> A popular example is libdevmapper1.02.1 <-> dmsetup

... and as it happens, I ran into this exact example last week while
cleaning up cruft that had accumulated in one of the development chroots I
use for my day job (I think it got there via a Recommends chain involving
cryptsetup and systemd, but removing those was not sufficient to hint
aptitude into also removing the dmsetup/libdevmapper cycle).

> > Because you have argued that glib-compile-schemas is an
> > architecture-independent interface, I think if other packages want
> > to run 

Bug#1024041: mariadb-10.6: FTBFS on riscv64: rocksdb/db/memtable.cc:129: undefined reference to `__atomic_compare_exchange_1'

2023-01-22 Thread Manuel A. Fernandez Montecelo
Hi Otto,

On Sat, 21 Jan 2023 at 23:28, Otto Kekäläinen  wrote:
>
> Control: retitle -1 mariadb: FTBFS on riscv64:
> rocksdb/db/memtable.cc:129: undefined reference to
> `__atomic_compare_exchange_1' to misc functions and files
> Control: reassign -1 mariadb
> Control: found -1 mariadb-10.6/1:10.6.9-1
> Control: found -1 mariadb/1:10.11.1-1
>
> I reviewed recent builds of the new MariaDB 10.11[1] and similar
> failures still exist.
>
> If you have a suggestion for a fix - Merge Requests[2] on Salsa are
> very welcome!

Not sure I understand or if you missed some of the messages to this
bug report, but from what I understand you request a patch to fix the
info, and Bo Yu provided a patch on 2022-11-14 on this bug report [1],
and in subsequent messages also to this bug report I provided more
info that it works when building it locally with the patch, and later
I sent another message as a kind of "ping".

  [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024041#20

If you prefer a MergeRequest in Salsa I suppose that Bo Yu will create
one, if it makes things easier for you; if not I'll try to do it in
the next days.


But yeah, in any case we're very interested in getting this fixed,
thanks for your interest!


Cheers.
-- 
Manuel A. Fernandez Montecelo 



Bug#1029469: RFP: anarch -- oldschool first-person-shooter game

2023-01-22 Thread Miloslav Ciz
Package: wnpp
Severity: wishlist

* package name: anarch
  upstream author: Miloslav Číž (drummyfish)
* URL: https://codeberg.org/drummyfish/Anarch
* license: CC0
* description: oldschool first-person-shooter game

Anarch is an oldschool first-person-shooter game mildly
inspired by the game Doom. It is completely public
domain, made to be as free as possible. It is also unique
in being very small, efficient, portable, dependency-free
and hackable.

This is my own software and I would be glad if someone
could package it for me as I have absolutely no experience
with packaging or maintaining packages. It gained some
attention and I got a lot of feedback from people that
told me they liked it, so I think it would be helpful to
include the game in Debian so that more people can find it
and play it.

Building is very easy, without requirement for any build
system (there is a shell script in the repository that
helps to compile the game with correct flags etc.). The only
modification that will probably need to be made is changing
the path to save file to some absolutely located file (e.g.
~/.anarch/anarch.sav) in settings.h before compiling
(currently the game saves its progress in the directory it
is run from). The only dependency is SDL2-dev (alternatively
csfml can also be used).



Bug#1029234: lyx: Graphic problems editing a lyx file

2023-01-22 Thread Pavel Sanda
On Sun, Jan 22, 2023 at 08:04:09PM +0100, Dr. Tobias Quathamer wrote:
> Sorry that I cannot provide any more useful ideas to narrow down this bug.

We discovered meantime with Stefano the offending commit in 2.3.7 and
opened the issue on lyx devel list.

Pavel



Bug#1029468: RFS: sioyek/2.0.0+dfsg-3 -- PDF viewer with a focus on technical books and research papers

2023-01-22 Thread Victor Westerhuis
Package: sponsorship-requests
Severity: normal
X-Debbugs-Cc: elb...@debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear mentors,

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

 * Package name : sioyek
   Version  : 2.0.0+dfsg-3
   Upstream contact : https://github.com/ahrm/sioyek/issues
 * URL  : https://sioyek.info/
 * License  : BSL-1.0, GFDL-NIV-1.2+ or CC-BY-SA-3.0 or CC-BY-SA-2.5 
and CC-BY-SA-2.0 and CC-BY-SA-1.0, GPL-3.0+, forrest-smith-license
 * Vcs  : https://salsa.debian.org/viccie30/sioyek
   Section  : misc

The source builds the following binary packages:

  sioyek - PDF viewer with a focus on technical books and research papers

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/sioyek/sioyek_2.0.0+dfsg-3.dsc

Changes since the last upload:

 sioyek (2.0.0+dfsg-3) unstable; urgency=medium
 .
   * Update standards version to 4.6.2, no changes needed.
   * Change B-D from sphinx:native to python3-sphinx:native
 to workaround #971739.

Regards, Groet,
- -- 
  Victor Westerhuis

-BEGIN PGP SIGNATURE-

iQJHBAEBCAAxFiEE6OxII3T+o0Ujs6ECQz2Rq5dHQPsFAmPNrHwTHHZpY3RvckB3
ZXN0ZXJodS5pcwAKCRBDPZGrl0dA+5I7EAChWerngHr1K/DVX331qWBzfFh1r1dX
912A5ev1NwQKKYtjItyvVwjn19GeuTqDcDpDbPCEPLsUSlhJoXwjTZEfx6KwaJw2
DceB3hndVOl2Ipcd4IqBShRCwpe9czuf07oo5WFEilWl89z9n1Y3Pxqyk2t52u/d
dvjGYJS6zCxml7X/W1GKyal1pVf1dlTClpXTC+DJFJDi+itXMzfzRO5IvaObWgRV
fAVMzc6FNjzGOJPcVsvc3dViUo30D5P1MZCKVMrsIwA0R/F9XFKH4+k/QdTAl84n
Xwl5BIlfqxpNW4mvPGAb1OJZBbAG/9wxNm+0cInXGSZRXQrczIVQ4RQOI+7e1sis
TIzVi0HrE3Z86K72up/Ux8MG2S5jXsHYt9MTkuqrC/eshZGdGJxcWFiWNRgsYztC
Cwq0moqa6Kxe8t2QY2b1HROI7DaBUkXqrtt1JeMjyhHP5cALj7k8E5zwCGk6Y2Pm
V/r6bqgg3WLCvkYv9Qt0ZCDlsTPYVAxzh9f63F5W09i9FPCASreMgT/pbZ6sSy/7
Ifd6BdjQY1ADnod40MR+YQspkDhWnDHiq/IdFMOO5LONryxJElthMALEANZVtiPm
l89oOdJzfGtZ9lVucF04tYrp/YstSKuxsMBLX4dRGTAgWtTsPk+tQvpnYlgTcby4
Eqtm+OVedVlq0Q==
=u4sM
-END PGP SIGNATURE-



Bug#1029467: ifupdown: dhclient failed to send packet (DHCPRELEASE)

2023-01-22 Thread Brandon Applegate
Package: ifupdown
Version: 0.8.36
Severity: normal

Dear Maintainer,

   * What led up to the situation?

Running "ifdown enp1s0f4"

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

N/A

   * What was the outcome of this action?

N/A

   * What outcome did you expect instead?

No error message.


Here is the error I get:

#
Jan 21 04:17:30 ice dhclient[303659]: DHCPRELEASE of 1.1.1.1 on enp1s0f4 to 
2.2.2.2 port 67
Jan 21 04:17:30 ice dhclient[303659]: send_packet: Invalid argument
Jan 21 04:17:30 ice dhclient[303659]: dhclient.c:2879: Failed to send 300 byte 
long packet over fallback interface.
#

I also had started a thread on the ISC dhcp-users mailing list:

https://lists.isc.org/pipermail/dhcp-users/2023-January/022820.html

>From what I can tell (I could be wrong) - the logic to make dhclient send a 
>RELEASE is compiled into ifup via inet.defn.

To me it looks like dhclient release happens first, before the "ip link" 
command shuts down the interface.

Nevertheless I still get this issue.

-- Package-specific info:
--- /etc/network/interfaces:
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

auto dummy0
iface dummy0 inet manual
pre-up ifconfig $IFACE up
post-down ifconfig $IFACE down

# The primary network interfaces
auto enp1s0f4 enp1s0f4d1.10 enp1s0f4d1.10:0 enp1s0f4d1.11 enp1s0f4d1.14 
enp1s0f4d2
#
# internet
#
iface enp1s0f4 inet dhcp
dns-nameservers 127.0.0.1
dns-search internal.burn.net
post-up ip route add 192.168.100.1/32 dev enp1s0f4

# private
#
iface enp1s0f4d1.10 inet static
address 192.168.64.1
netmask 255.255.255.0

iface enp1s0f4d1.10:0 inet static
address 192.168.64.10
netmask 255.255.255.0

#
# guest
#
iface enp1s0f4d1.11 inet static
address 192.168.65.1
netmask 255.255.255.0

# phone tether
iface usb0 inet dhcp

# wep test
iface enp1s0f4d1.13 inet static
address 192.168.66.1
netmask 255.255.255.0

# dmz
iface enp1s0f4d1.14 inet static
address 192.168.69.1
netmask 255.255.255.0

# fw mgmt
iface enp6s0 inet static
address 192.168.68.1
netmask 255.255.255.248

# freenas priv
iface enp1s0f4d2 inet static
address 10.255.255.1
netmask 255.255.255.0
mtu 9000

--- up and down scripts installed:
/etc/network/if-down.d:
total 12
-rwxr-xr-x 1 root root 289 Sep 21 06:40 bind9
-rwxr-xr-x 1 root root 372 May 14  2021 openvpn
-rwxr-xr-x 1 root root 800 Jan  7  2022 postfix

/etc/network/if-post-down.d:
total 4
-rwxr-xr-x 1 root root 1433 Feb  4  2019 vlan
lrwxrwxrwx 1 root root   33 Sep  6  2020 wide-dhcpv6-client -> 
../../wide-dhcpv6/dhcp6c-ifupdown

/etc/network/if-pre-up.d:
total 12
-rwxr-xr-x 1 root root  344 Jun 30  2016 ethtool
-rwxr-xr-x 1 root root 4224 Feb 21  2019 vlan

/etc/network/if-up.d:
total 24
-rwxr-xr-x 1 root root  289 Sep 21 06:40 bind9
-rwxr-xr-x 1 root root 1685 Jun 30  2016 ethtool
-rwxr-xr-x 1 root root  677 Feb  4  2019 ip
-rwxr-xr-x 1 root root  385 May 14  2021 openvpn
-rwxr-xr-x 1 root root 1183 Jan  7  2022 postfix
-rwxr-xr-x 1 root root  312 Dec 10 17:30 sqm
lrwxrwxrwx 1 root root   33 Sep  6  2020 wide-dhcpv6-client -> 
../../wide-dhcpv6/dhcp6c-ifupdown


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

Kernel: Linux 5.10.0-19-amd64 (SMP w/12 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 ifupdown depends on:
ii  adduser   3.118
ii  iproute2  5.10.0-4
ii  libc6 2.31-13+deb11u5
ii  lsb-base  11.1.0

Versions of packages ifupdown recommends:
ii  isc-dhcp-client [dhcp-client]  4.4.1-2.3+deb11u1

Versions of packages ifupdown suggests:
pn  ppp 
pn  rdnssd  

-- no debconf information



Bug#1029466: esda: FTBFS with current numba version

2023-01-22 Thread Bastian Germann

Source: esda
Version: 0.1.0-1
Severity: serious

The package cannot be built due to the unit tests:

 short test summary info 

FAILED esda/tests/test_getisord.py::G_Local_Tester::test_G_Local_Binary - numba.core.errors.TypingError: Failed in 
nopython mode pipeline (step: nopython frontend)
FAILED esda/tests/test_getisord.py::G_Local_Tester::test_G_Local_Row_Standardized - numba.core.errors.TypingError: 
Failed in nopython mode pipeline (step: nopython frontend)
FAILED esda/tests/test_getisord.py::G_Local_Tester::test_G_star_Local_Binary - numba.core.errors.TypingError: Failed in 
nopython mode pipeline (step: nopython frontend)
FAILED esda/tests/test_getisord.py::G_Local_Tester::test_G_star_Row_Standardized - numba.core.errors.TypingError: Failed 
in nopython mode pipeline (step: nopython frontend)
FAILED esda/tests/test_getisord.py::G_Local_Tester::test_by_col - numba.core.errors.TypingError: Failed in nopython mode 
pipeline (step: nopython frontend)
FAILED esda/tests/test_getisord.py::i::test_G_Local_Binary - numba.core.errors.TypingError: Failed in nopython mode 
pipeline (step: nopython frontend)
FAILED esda/tests/test_getisord.py::i::test_G_Local_Row_Standardized - numba.core.errors.TypingError: Failed in nopython 
mode pipeline (step: nopython frontend)
FAILED esda/tests/test_getisord.py::i::test_G_star_Local_Binary - numba.core.errors.TypingError: Failed in nopython mode 
pipeline (step: nopython frontend)
FAILED esda/tests/test_getisord.py::i::test_G_star_Row_Standardized - numba.core.errors.TypingError: Failed in nopython 
mode pipeline (step: nopython frontend)
FAILED esda/tests/test_getisord.py::i::test_by_col - numba.core.errors.TypingError: Failed in nopython mode pipeline 
(step: nopython frontend)
FAILED esda/tests/test_ljc.py::Join_Counts_Locals_Tester::test_Join_Counts_Locals - numba.core.errors.TypingError: 
Failed in nopython mode pipeline (step: nopython frontend)
FAILED esda/tests/test_ljc.py::i::test_Join_Counts_Locals - numba.core.errors.TypingError: Failed in nopython mode 
pipeline (step: nopython frontend)
FAILED esda/tests/test_ljc_bv.py::Local_Join_Counts_BV_Tester::test_Local_Join_Counts_BV - 
numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
FAILED esda/tests/test_ljc_bv.py::i::test_Local_Join_Counts_BV - numba.core.errors.TypingError: Failed in nopython mode 
pipeline (step: nopython frontend)
FAILED esda/tests/test_ljc_mv.py::Local_Join_Counts_MV_Tester::test_Local_Join_Counts_MV - 
numba.core.errors.TypingError: Failed in nopython mode pipeline (step: nopython frontend)
FAILED esda/tests/test_ljc_mv.py::i::test_Local_Join_Counts_MV - numba.core.errors.TypingError: Failed in nopython mode 
pipeline (step: nopython frontend)
FAILED esda/tests/test_moran.py::Moran_Tester::test_z_consistency - numba.core.errors.TypingError: Failed in nopython 
mode pipeline (step: nopython frontend)
FAILED esda/tests/test_moran.py::Moran_Local_Tester::test_Moran_Local - numba.core.errors.TypingError: Failed in 
nopython mode pipeline (step: nopython frontend)
FAILED esda/tests/test_moran.py::Moran_Local_Tester::test_Moran_Local_parallel - numba.core.errors.TypingError: Failed 
in nopython mode pipeline (step: nopython frontend)
FAILED esda/tests/test_moran.py::Moran_Local_Tester::test_local_moments - numba.core.errors.TypingError: Failed in 
nopython mode pipeline (step: nopython frontend)
FAILED esda/tests/test_moran.py::Moran_Local_BV_Tester::test_Moran_Local_BV - numba.core.errors.TypingError: Failed in 
nopython mode pipeline (step: nopython frontend)
FAILED esda/tests/test_moran.py::Moran_Local_Rate_Tester::test_moran_rate - numba.core.errors.TypingError: Failed in 
nopython mode pipeline (step: nopython frontend)
FAILED esda/tests/test_moran.py::i::test_moran_rate - numba.core.errors.TypingError: Failed in nopython mode pipeline 
(step: nopython frontend)
FAILED esda/tests/test_util.py::Fdr_Tester::test_fdr - numba.core.errors.TypingError: Failed in nopython mode pipeline 
(step: nopython frontend)
FAILED esda/tests/test_util.py::i::test_fdr - numba.core.errors.TypingError: Failed in nopython mode pipeline (step: 
nopython frontend)

 25 failed, 57 passed, 11 skipped, 37 warnings in 
13.53s 


Most of them end in a stack trace like the following:
E   numba.core.errors.TypingError: Failed in nopython mode pipeline 
(step: nopython frontend)
E   No implementation of function Function() 
found for signature:
E
E>>> seed(int64)
E
E   There are 4 candidate implementations:
E - Of which 4 did not match due to:
E Overload in function '_OverloadWrapper._build..ol_generated': File: numba/core/overload_glue.py: 
Line 129.

E   With argument(s): '(int64)':
E  Rejected as the implementation raised a specific error:
ETypeError: 

Bug#1018811: [Debian-pan-maintainers] Bug#1018811: Three new test issues preventing upload of patch (Was: pyfai: autopkgtest regression on armel and i386)

2023-01-22 Thread Andreas Tille
Am Sun, Jan 22, 2023 at 06:58:53PM +0100 schrieb Jerome Kieffer:
> On Sun, 22 Jan 2023 16:56:46 +0100
> Andreas Tille  wrote:
> 
> > Thanks for commenting on this.  Would you be able to push the needed changes
> > to Salsa (and preferably upload)?
> 
> Hi Andreas,
> 
> I know a bit about debian packaging and also about the gitlab-CI, but I never 
> used the later for the former.
> 
> I just re-acetivated my salsa account and forked the project.
> 
> Now what should I do ?
> * I guess replace the content of the master branch with the newest release
> * should I update the content of any other branch ?

You deel only with the master branch

> * then perform a merge-request on the scient-team 

If its easier for you simply send me a patch.

> Maybe (probably) there is a documentation existing, but as usual a
> quick googling did not provide the adequate answer.

I wrongly assumed that you were comfortable with Salsa.  I think I
can live with any form of patch or MR.

Kind regards
Andreas. 

-- 
http://fam-tille.de



Bug#996799: twitterwatch - upload needed

2023-01-22 Thread Malik
Hello Emmanuel,

I updated the watch file and added 2 tests to the package, it would be nice
if you can review it [1] before I release it.

[1]
https://salsa.debian.org/python-team/packages/twitterwatch/-/merge_requests/2

best regards,
Malik

Am Di., 17. Jan. 2023 um 22:57 Uhr schrieb Emmanuel Arias <
eam...@yaerobi.com>:

> Hi,
>
> On Tue, Jan 17, 2023 at 6:16 PM Malik  wrote:
>
>> Hello Emmanuel,
>>
>> currently upstream-author has no plan to update or release any further
>> releases for this project [1]
>>
> Ok
>
>>
>>
>
>> [1] https://gitlab.com/chaica/twitterwatch/-/issues/1
>>
>> kind regards,
>> Malik
>>
>
> If you leave the package as is it now, when a new release exists, d/watch
> won't note it.
> So, I'd change the d/watch to the Gitlab repository. Also Homepage link.
>
> Cheers,
> Emmanuel
>


-- 
Malik Mlitat


Bug#1029398: ben: "tracker --archs" is not honoured

2023-01-22 Thread Adrian Bunk
On Sun, Jan 22, 2023 at 03:43:24PM +0100, Stéphane Glondu wrote:
> Le 22/01/2023 à 14:21, Adrian Bunk a écrit :
> > > > > I see two approches to solving this bug:
> > > > > - make the command-line options override the configuration specified 
> > > > > in
> > > > > global.conf
> > > > > - reject command-line options when they are read in global.conf
> > > > > 
> > > > > What do you think?
> > > > > ...
> > > > 
> > > > The behaviour of "ben download" of having some sane defaults[1]
> > > > or configuration file that can be overridden on the command line
> > > > is IMHO pretty good, and I'd expect "ben tracker" to behave the
> > > > same way.
> > > 
> > > I'll see what I can do.
> > 
> > Thanks!
> 
> Actually, my initial understanding of what was happening was wrong. No
> default global.conf is read.
> 
> I've pushed a tentative fix:
> 
> https://salsa.debian.org/debian/ben/-/commit/7b882e6c090828babb677b258f1e64f287d631e8
> 
> Can you check that it does what you want?

Thanks a lot, this works for me.

> Cheers,

cu
Adrian



Bug#1029465: RFS: swapspace/1.18-1 -- dynamic swap space manager

2023-01-22 Thread Jacob Adams
Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : swapspace
   Version  : 1.18-1
   Upstream contact : Jacob Adams 
 * URL  : https://github.com/Tookmund/Swapspace
 * License  : GPL-2+
 * Vcs  : https://salsa.debian.org/tookmund/swapspace-deb
   Section  : admin

The source builds the following binary packages:

  swapspace - dynamic swap space manager

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/swapspace/swapspace_1.18-1.dsc

Changes since the last upload:

 swapspace (1.18-1) unstable; urgency=medium
 .
   * New upstream version
   * Bump standards version to 4.6.2, no changes required

Regards,
-- 
  Jacob Adams


Bug#1029464: gnucash: Missing Dependency or Suggestion

2023-01-22 Thread Stephen R. Marenka

Package: gnucash
Version: 1:4.4-1
Severity: minor
X-Debbugs-Cc: none, step...@marenka.net

Dear Maintainer,

gnucash throws the following error on launch from cli, although I'm not 
aware of anything that doesn't work.


| Traceback (most recent call last):
|   File "/usr/share/gnucash/python/init.py", line 6, in 
| from gi import require_version
| ModuleNotFoundError: No module named 'gi'

Installing python3-gi yields the following.

| Traceback (most recent call last):
|   File "/usr/share/gnucash/python/init.py", line 7, in 
|require_version('Gtk', '3.0')
|  File "/usr/lib/python3/dist-packages/gi/__init__.py", line 126, in 
require_version

|raise ValueError('Namespace %s not available' % namespace)
| ValueError: Namespace Gtk not available

Installing gobject-introspection gir1.2-gtk-3.0 remediates that but 
brings quite a few dependencies (FWIW). At least now we get no errors.


Maybe add a Suggests: python3-gi gobject-introspection gir1.2-gtk-3.0?

Thanks,

Stephen


-- System Information:
Debian Release: 11.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable')

Architecture: amd64 (x86_64)

Kernel: Linux 5.10.153-20432-gaa06ea936644 (SMP w/4 CPU threads; 
PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE 
not set

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gnucash depends on:
ii  gnucash-common 1:4.4-1
ii  guile-3.0  3.0.5-4
ii  guile-3.0-libs 3.0.5-4
ii  libaqbanking44 6.2.10-1
ii  libboost-filesystem1.74.0  1.74.0-9
ii  libboost-locale1.74.0  1.74.0-9
ii  libboost-program-options1.74.0 1.74.0-9
ii  libboost-regex1.74.0 [libboost-regex1.74.0-icu67]  1.74.0-9
ii  libc6  2.31-13+deb11u5
ii  libcairo2  1.16.0-5
ii  libcrypt-ssleay-perl   0.73.06-1+b3
ii  libdate-manip-perl 6.83-1
ii  libdbi10.9.0-6
ii  libfinance-quote-perl  1.50~rc2-2
ii  libgcc-s1  10.2.1-6
ii  libgdk-pixbuf-2.0-0
2.42.2+dfsg-1+deb11u1

ii  libglib2.0-0   2.66.8-1
ii  libgtk-3-0 3.24.24-4+deb11u2
ii  libgwengui-gtk3-79 5.6.0-2
ii  libgwenhywfar795.6.0-2
ii  libhtml-tableextract-perl  2.15-1.1
ii  libhtml-tree-perl  5.07-2
ii  libicu67   67.1-7
ii  libofx71:0.9.15-3
ii  libpango-1.0-0 1.46.2-3
ii  libpangocairo-1.0-01.46.2-3
ii  libpython3.9   3.9.2-1
ii  libsecret-1-0  0.20.4-2
ii  libstdc++6 10.2.1-6
ii  libwebkit2gtk-4.0-37   2.38.3-1~deb11u1
ii  libwww-perl6.52-1
ii  libxml2
2.9.10+dfsg-6.7+deb11u3

ii  perl   5.32.1-4+deb11u2
ii  zlib1g 
1:1.2.11.dfsg-2+deb11u2


Versions of packages gnucash recommends:
ii  gnucash-docs 4.4-1
ii  python3-gnucash  1:4.4-1
ii  yelp 3.38.3-1

Versions of packages gnucash suggests:
pn  libdbd-mysql
pn  libdbd-pgsql
pn  libdbd-sqlite3  

--
Stephen R. Marenka If life's not fun, you're not doing it right!




Bug#1029462: golang-github-nats-io-jwt: FTBFS in bookworm (undeclared build-dependency on tzdata)

2023-01-22 Thread Santiago Vila

Package: src:golang-github-nats-io-jwt
Version: 2.3.0-1
Severity: serious
Tags: ftbfs patch

Dear maintainer:

During a rebuild of all packages in bookworm, your package failed to build:


[...]
 debian/rules binary-indep
dh binary-indep --buildsystem=golang --with=golang
   dh_update_autotools_config -i -O--buildsystem=golang
   dh_autoreconf -i -O--buildsystem=golang
   dh_auto_configure -i -O--buildsystem=golang
   dh_auto_build -i -O--buildsystem=golang
dh_auto_build: warning: github.com/nats-io/jwt/v2/test contains no non-test Go 
files, removing it from build
cd obj-x86_64-linux-gnu && go install -trimpath -v -p 1 
github.com/nats-io/jwt github.com/nats-io/jwt/v2
internal/goarch
internal/unsafeheader
internal/abi
internal/cpu
internal/bytealg
internal/goexperiment
internal/goos
runtime/internal/atomic
runtime/internal/math
runtime/internal/sys
runtime/internal/syscall
runtime
internal/reflectlite
errors
internal/race
sync/atomic
sync
io
unicode
unicode/utf8
bytes
hash
math/bits
math
strconv
crypto
crypto/internal/subtle
crypto/subtle
internal/itoa
reflect
encoding/binary
crypto/cipher
crypto/internal/boring/sig
crypto/internal/boring
crypto/sha256
crypto/sha512
encoding/base32
encoding/base64
encoding
sort
internal/fmtsort
internal/oserror
syscall
internal/syscall/unix
time
internal/poll
internal/safefilepath
internal/syscall/execenv
internal/testlog
path
io/fs
os
fmt
strings
unicode/utf16
encoding/json
crypto/internal/randutil
math/rand
math/big
crypto/rand
crypto/internal/edwards25519/field
crypto/internal/edwards25519
crypto/ed25519
golang.org/x/crypto/ed25519
regexp/syntax
regexp
github.com/nats-io/nkeys
io/ioutil
context
vendor/golang.org/x/net/dns/dnsmessage
internal/godebug
internal/nettrace
internal/singleflight
internal/intern
net/netip
runtime/cgo
net
bufio
compress/flate
hash/crc32
compress/gzip
container/list
crypto/aes
crypto/des
crypto/internal/nistec/fiat
embed
crypto/internal/nistec
crypto/elliptic
crypto/internal/boring/bbig
encoding/asn1
vendor/golang.org/x/crypto/cryptobyte/asn1
vendor/golang.org/x/crypto/cryptobyte
crypto/ecdsa
crypto/hmac
crypto/md5
crypto/rc4
crypto/rsa
crypto/sha1
crypto/dsa
encoding/hex
crypto/x509/pkix
encoding/pem
net/url
path/filepath
crypto/x509
vendor/golang.org/x/crypto/internal/subtle
vendor/golang.org/x/crypto/chacha20
vendor/golang.org/x/crypto/internal/poly1305
vendor/golang.org/x/sys/cpu
vendor/golang.org/x/crypto/chacha20poly1305
vendor/golang.org/x/crypto/curve25519/internal/field
vendor/golang.org/x/crypto/curve25519
vendor/golang.org/x/crypto/hkdf
crypto/tls
vendor/golang.org/x/text/transform
log
vendor/golang.org/x/text/unicode/bidi
vendor/golang.org/x/text/secure/bidirule
vendor/golang.org/x/text/unicode/norm
vendor/golang.org/x/net/idna
net/textproto
vendor/golang.org/x/net/http/httpguts
vendor/golang.org/x/net/http/httpproxy
vendor/golang.org/x/net/http2/hpack
mime
mime/quotedprintable
mime/multipart
net/http/httptrace
net/http/internal
net/http/internal/ascii
net/http
github.com/nats-io/jwt
github.com/nats-io/jwt/v2
   dh_auto_test -i -O--buildsystem=golang
cd obj-x86_64-linux-gnu && go test -vet=off -v -p 1 
github.com/nats-io/jwt github.com/nats-io/jwt/v2 github.com/nats-io/jwt/v2/test
=== RUN   TestNewAccountClaims
--- PASS: TestNewAccountClaims (0.00s)
=== RUN   TestAccountCanSignOperatorLimits
--- PASS: TestAccountCanSignOperatorLimits (0.00s)
=== RUN   TestAccountCanSignIdentities
--- PASS: TestAccountCanSignIdentities (0.00s)
=== RUN   TestOperatorCanSignClaims
--- PASS: TestOperatorCanSignClaims (0.00s)
=== RUN   TestInvalidAccountClaimIssuer
--- PASS: TestInvalidAccountClaimIssuer (0.00s)
=== RUN   TestInvalidAccountSubjects
--- PASS: TestInvalidAccountSubjects (0.00s)
=== RUN   TestAccountImports
--- PASS: TestAccountImports (0.00s)
=== RUN   TestNewNilAccountClaim
--- PASS: TestNewNilAccountClaim (0.00s)
=== RUN   TestLimitValidationInAccount
--- PASS: TestLimitValidationInAccount (0.00s)
=== RUN   TestWildcardExportLimit
--- PASS: TestWildcardExportLimit (0.00s)
=== RUN   TestAccountSigningKeyValidation
--- PASS: TestAccountSigningKeyValidation (0.00s)
=== RUN   TestAccountSignedBy
--- PASS: TestAccountSignedBy (0.00s)
=== RUN   TestAddRemoveSigningKey
--- PASS: TestAddRemoveSigningKey (0.00s)
=== RUN   TestUserRevocation
--- PASS: TestUserRevocation (0.00s)
=== RUN   TestUserRevocationAll
--- PASS: TestUserRevocationAll (0.00s)
=== RUN   TestNewActivationClaims
--- PASS: TestNewActivationClaims (0.00s)
=== RUN   TestInvalidActivationTargets
--- PASS: TestInvalidActivationTargets (0.00s)
=== RUN   TestInvalidActivationClaimIssuer
--- PASS: TestInvalidActivationClaimIssuer (0.00s)
=== RUN   TestPublicIsNotValid
--- PASS: TestPublicIsNotValid (0.00s)
=== RUN   TestNilActivationClaim
--- PASS: TestNilActivationClaim (0.00s)
=== RUN   TestActivationImportSubjectValidation
--- PASS: TestActivationImportSubjectValidation (0.00s)
=== RUN   

Bug#1029463: remind: FTBFS in bookworm (undeclared build-dependency on tzdata)

2023-01-22 Thread Santiago Vila

Package: src:remind
Version: 04.02.01-1
Severity: serious
Tags: ftbfs patch

Dear maintainer:

During a rebuild of all packages in bookworm, your package failed to build:


[...]
 debian/rules binary-indep
dh binary-indep
   dh_update_autotools_config -i
   dh_autoreconf -i
autoreconf: warning: autoconf input should be named 'configure.ac', not 
'configure.in'
aclocal: warning: autoconf input should be named 'configure.ac', not 
'configure.in'
configure.in:15: warning: The macro `AC_CONFIG_HEADER' is obsolete.
configure.in:15: You should run autoupdate.
./lib/autoconf/status.m4:719: AC_CONFIG_HEADER is expanded from...
configure.in:15: the top level
configure.in:45: warning: The macro `AC_HEADER_TIME' is obsolete.
configure.in:45: You should run autoupdate.
./lib/autoconf/headers.m4:743: AC_HEADER_TIME is expanded from...
configure.in:45: the top level
configure.in:88: warning: AC_OUTPUT should be used without arguments.
configure.in:88: You should run autoupdate.
autoheader: warning: autoconf input should be named 'configure.ac', not 
'configure.in'
   dh_auto_configure -i
./configure --build=x86_64-linux-gnu --prefix=/usr 
--includedir=\${prefix}/include --mandir=\${prefix}/share/man 
--infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var 
--disable-option-checking --disable-silent-rules 
--libdir=\${prefix}/lib/x86_64-linux-gnu --runstatedir=/run 
--disable-maintainer-mode --disable-dependency-tracking

**
**
* Configuring REMIND *
**
**

checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether the compiler supports GNU C... yes
checking whether gcc accepts -g... yes
checking for gcc option to enable C11 features... none needed
checking for a BSD-compatible install... /usr/bin/install -c
checking whether ln -s works... yes
checking whether make sets $(MAKE)... yes
checking for perl... /usr/bin/perl
checking for sqrt in -lm... yes
checking for stdio.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for strings.h... yes
checking for sys/stat.h... yes
checking for sys/types.h... yes
checking for unistd.h... yes
checking for utime.h... yes
checking for sys/time.h... yes
checking size of unsigned int... 4
checking size of unsigned long... 8
checking for sys/types.h... (cached) yes
checking for sys/file.h... yes
checking for glob.h... yes
checking for wctype.h... yes
checking for locale.h... yes
checking for langinfo.h... yes
checking whether struct tm is in sys/time.h or time.h... time.h
checking whether utime accepts a null argument... yes
checking whether gcc supports -flto=auto... yes
checking whether gcc supports -ffat-lto-objects... yes
checking for setenv... yes
checking for unsetenv... yes
checking for glob... yes
checking for mbstowcs... yes
checking for setlocale... yes
checking for initgroups... yes
configure: creating ./config.status
config.status: creating src/Makefile
config.status: creating www/Makefile
config.status: creating src/version.h
config.status: creating rem2html/Makefile
config.status: creating rem2pdf/Makefile.PL
config.status: creating rem2pdf/Makefile.top
config.status: creating rem2pdf/bin/rem2pdf
config.status: creating man/rem.1
config.status: creating man/rem2ps.1
config.status: creating man/remind.1
config.status: creating man/tkremind.1
config.status: creating src/config.h
   dh_auto_build -i
make -j1
make[1]: Entering directory '/<>'

***
* *
* Building REMIND *
* *
***

make[2]: Entering directory '/<>/src'
gcc -c -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wall -Wextra -Wstrict-prototypes -flto=auto -ffat-lto-objects 
-DHAVE_CONFIG_H   -DSYSDIR=/usr/share/remind -I. -I. calendar.c
gcc -c -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wall -Wextra -Wstrict-prototypes -flto=auto -ffat-lto-objects 
-DHAVE_CONFIG_H   -DSYSDIR=/usr/share/remind -I. -I. dynbuf.c
gcc -c -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wall -Wextra -Wstrict-prototypes -flto=auto -ffat-lto-objects 
-DHAVE_CONFIG_H   -DSYSDIR=/usr/share/remind -I. -I. dorem.c
gcc -c -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wall -Wextra -Wstrict-prototypes -flto=auto -ffat-lto-objects 
-DHAVE_CONFIG_H   -DSYSDIR=/usr/share/remind -I. -I. dosubst.c
gcc -c 

Bug#1029461: xemacs21-packages: FTBFS in bookworm (LaTeX Error: File `pdftexcmds.sty' not found)

2023-01-22 Thread Santiago Vila

Package: src:xemacs21-packages
Version: 2009.02.17.dfsg.3-1
Severity: serious
Tags: ftbfs

Dear maintainer:

During a rebuild of all packages in bookworm, your package failed to build:


[...]
 debian/rules build-indep
chmod +x debian/makevarfile
debian/makevarfile "debian/./var_file.pl" \
"MAJVERSION" "21" \
"VERSION" "2009.02.17.dfsg.3" \
"SUBNAME" "" \
"CONF_NAME" "amd64-debian-linux" \
"ARCH" "amd64" \
"HTML_FILE_LOC" "debian/html" \
"TMP_FILE_LOC" "debian/tmp" \
"PREFIX" "usr" \
"TOPDIR" "/<>"

[...]

Loading /usr/lib/xemacs-21.4.24/lisp/auto-autoloads...
Loading /<>/xemacs-packages/edit-utils/auto-autoloads...
Loading /<>/xemacs-packages/mail-lib/auto-autoloads...
Loading /<>/xemacs-packages/fsf-compat/auto-autoloads...
Loading /<>/xemacs-packages/texinfo/auto-autoloads...
Loading /<>/xemacs-packages/xemacs-base/auto-autoloads...
Compiling /<>/xemacs-packages/auctex/style/frenchb.el...
While compiling toplevel forms in file 
/<>/xemacs-packages/auctex/style/frenchb.el:
  ** reference to free variable TeX-quote-after-quote
  ** assignment to free variable TeX-quote-language
While compiling the end of the data:
  ** The following functions are not known to be defined:
TeX-add-style-hook, TeX-add-symbols
Wrote /<>/xemacs-packages/auctex/style/frenchb.elc
Done
xemacs21-mule -no-autoloads -vanilla -batch -eval '(setq stack-trace-on-error t load-always-display-messages t 
load-ignore-out-of-date-elc-files t load-show-full-path-in-messages t)' -eval '(setq load-path (list (expand-file-name 
"mule" lisp-directory) lisp-directory))' -l /<>/package-compile.el -- xemacs-base 
texinfo fsf-compat mail-lib edit-utils -- -eval '(setq load-path (cons "." (cons "preview" 
load-path)))' -f batch-byte-compile style/francais.el
Loading /usr/lib/xemacs-21.4.24/lisp/auto-autoloads...
Loading /<>/xemacs-packages/edit-utils/auto-autoloads...
Loading /<>/xemacs-packages/mail-lib/auto-autoloads...
Loading /<>/xemacs-packages/fsf-compat/auto-autoloads...
Loading /<>/xemacs-packages/texinfo/auto-autoloads...
Loading /<>/xemacs-packages/xemacs-base/auto-autoloads...
Compiling /<>/xemacs-packages/auctex/style/francais.el...
While compiling the end of the data in file 
/<>/xemacs-packages/auctex/style/francais.el:
  ** The following functions are not known to be defined:
TeX-add-style-hook, TeX-run-style-hooks
Wrote /<>/xemacs-packages/auctex/style/francais.elc
Done
xemacs21-mule -no-autoloads -vanilla -batch -eval '(setq stack-trace-on-error t load-always-display-messages t 
load-ignore-out-of-date-elc-files t load-show-full-path-in-messages t)' -eval '(setq load-path (list (expand-file-name 
"mule" lisp-directory) lisp-directory))' -l /<>/package-compile.el -- xemacs-base 
texinfo fsf-compat mail-lib edit-utils -- -eval '(setq load-path (cons "." (cons "preview" 
load-path)))' -f batch-byte-compile style/MinionPro.el
Loading /usr/lib/xemacs-21.4.24/lisp/auto-autoloads...
Loading /<>/xemacs-packages/edit-utils/auto-autoloads...
Loading /<>/xemacs-packages/mail-lib/auto-autoloads...
Loading /<>/xemacs-packages/fsf-compat/auto-autoloads...
Loading /<>/xemacs-packages/texinfo/auto-autoloads...
Loading /<>/xemacs-packages/xemacs-base/auto-autoloads...
Compiling /<>/xemacs-packages/auctex/style/MinionPro.el...
While compiling toplevel forms in file 
/<>/xemacs-packages/auctex/style/MinionPro.el:
  ** reference to free variable TeX-install-font-lock
  ** reference to free variable font-latex-match-textual-keywords-local
  ** assignment to free variable font-latex-match-textual-keywords-local
While compiling the end of the data:
  ** The following functions are not known to be defined:
TeX-add-style-hook, TeX-add-symbols,
font-latex-match-textual-make, font-latex-match-variable-make
Wrote /<>/xemacs-packages/auctex/style/MinionPro.elc
Done
xemacs21-mule -no-autoloads -vanilla -batch -eval '(setq stack-trace-on-error t load-always-display-messages t 
load-ignore-out-of-date-elc-files t load-show-full-path-in-messages t)' -eval '(setq load-path (list (expand-file-name 
"mule" lisp-directory) lisp-directory))' -l /<>/package-compile.el -- xemacs-base 
texinfo fsf-compat mail-lib edit-utils -- -eval '(setq load-path (cons "." (cons "preview" 
load-path)))' -f batch-byte-compile style/pdfsync.el
Loading /usr/lib/xemacs-21.4.24/lisp/auto-autoloads...
Loading /<>/xemacs-packages/edit-utils/auto-autoloads...
Loading /<>/xemacs-packages/mail-lib/auto-autoloads...
Loading /<>/xemacs-packages/fsf-compat/auto-autoloads...
Loading /<>/xemacs-packages/texinfo/auto-autoloads...
Loading /<>/xemacs-packages/xemacs-base/auto-autoloads...
Compiling /<>/xemacs-packages/auctex/style/pdfsync.el...
While compiling LaTeX-pdfsync-output-page in file 
/<>/xemacs-packages/auctex/style/pdfsync.el:
  ** variable sync-line bound but not referenced
While compiling toplevel forms:
  ** assignment to free variable 

Bug#1029460: glosstex: FTBFS in bookworm (LaTeX Error: File `pdftexcmds.sty' not found)

2023-01-22 Thread Santiago Vila

Package: src:glosstex
Version: 0.4.dfsg.1-4
Severity: serious
Tags: ftbfs

Dear maintainer:

During a rebuild of all packages in bookworm, your package failed to build:


[...]
 debian/rules build-arch
test -x debian/rules
mkdir -p "."
/usr/bin/make -C . CFLAGS="-g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security" CXXFLAGS="-g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security" CPPFLAGS="-Wdate-time -D_FORTIFY_SOURCE=2" LDFLAGS="-Wl,-z,relro"
make[1]: Entering directory '/<>'
cc -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2  -c -o database.o 
database.c
cc -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2  -c -o error.o error.c
cc -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2  -c -o labels.o labels.c
cc -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2  -c -o list.o list.c
cc -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2  -c -o main.o main.c
cc -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2  -c -o version.o version.c
cc -Wl,-z,relro database.o error.o labels.o list.o main.o version.o  -o glosstex
TEXINPUTS=.: latex glosstex.ins
This is pdfTeX, Version 3.141592653-2.6-1.40.24 (TeX Live 2022/Debian) 
(preloaded format=latex)
 restricted \write18 enabled.
entering extended mode
(./glosstex.ins
LaTeX2e <2022-06-01> patch level 5
L3 programming layer <2022-08-30>
(/usr/share/texlive/texmf-dist/tex/latex/base/docstrip.tex
Utility: `docstrip' v2.6a <2020-11-23>
English documentation<2020-11-23>

**
* This program converts documented macro-files into fast *
* loadable files by stripping off (nearly) all comments! *
**


* No Configuration file found, using default settings. *


(./glosstex.ins

Generating file(s) ./glosstex.sty ./glosstex.std ./glosstex.ist ./glosstex.gdf
./glosstex.cfg

Processing file glosstex.dtx (package) -> glosstex.sty
 (std) -> glosstex.std
 (ist) -> glosstex.ist
 (gdf) -> glosstex.gdf
 (cfg) -> glosstex.cfg
File glosstex.dtx ended by \endinput.
Lines  processed: 1768
Comments removed: 1092
Comments  passed: 16
Codelines passed: 646

**
*
* You will find the documentation in glosstex.dvi. You may remake it
* by running latex on glosstex.dtx or invoking `make doc'
*
* To finish the installation you have to move the following
* files (according to TDS):
*
* glosstex.sty to texmf/tex/latex/glosstex
* glosstex.std to texmf/tex/latex/glosstex
* glosstex.ist to texmf/makeindex
*
* and your own .gdf-files to texmf/glosstex.
*
* The files `glosstex.gdf' and `glosstex.cfg` are meant just for
* this document, so you won't want to install them, normally.
*
* Happy TeXing!
**
) ) )
No pages of output.
Transcript written on glosstex.log.
make[1]: Leaving directory '/<>'
touch debian/stamp-makefile-build
CDBS WARNING:  DEB_MAKE_CHECK_TARGET unset, not running checks
 fakeroot debian/rules binary-arch
test -x debian/rules
dh_testroot
dh_prep
dh_installdirs -A
dh_installdirs: warning: Compatibility levels before 10 are deprecated (level 9 
in use)
mkdir -p "."
CDBS WARNING:  DEB_MAKE_CHECK_TARGET unset, not running checks
CDBS WARNING:  DEB_MAKE_INSTALL_TARGET unset, skipping default makefile.mk 
common-install target
Adding cdbs dependencies to debian/glosstex.substvars
dh_installdirs -pglosstex \

dh_installdirs: warning: Compatibility levels before 10 are deprecated (level 9 
in use)
/usr/bin/make doc
make[1]: Entering directory '/<>'
TEXINPUTS=.: latex glosstex.dtx
This is pdfTeX, Version 3.141592653-2.6-1.40.24 (TeX Live 2022/Debian) 
(preloaded format=latex)
 restricted \write18 enabled.
entering extended mode
(./glosstex.dtx
LaTeX2e <2022-06-01> patch level 5
L3 programming layer <2022-08-30>
(/usr/share/texlive/texmf-dist/tex/latex/base/ltxdoc.cls
Document Class: ltxdoc 2022/06/22 v2.1h Standard LaTeX documentation class
*
* Local config file ltxdoc.cfg used
*
(/usr/share/texlive/texmf-dist/tex/latex/base/ltxdoc.cfg)

Bug#1029459: manually editing the file fixes the issue

2023-01-22 Thread Pirate Praveen



after replacing get_distro_std_name(os_name) with get_distro_name() in 
/usr/share/hplip/base/password.py


the plugin got installed


OpenPGP_0x8F53E0193B294B75.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1029459: after downloading the plugin manually and trying to install, it still fails

2023-01-22 Thread Pirate Praveen


Downloaded from 
https://www.openprinting.org/download/printdriver/auxfiles/HP/plugins/


$ ./hplip-3.22.10-plugin.run
Verifying archive integrity...  100%   All good.
Uncompressing HPLIP 3.22.10 Plugin Self Extracting Archive  100%

HP Linux Imaging and Printing System (ver. 3.22.10)
Plugin Installer ver. 3.0

Copyright (c) 2001-18 HP Development Company, LP
This software comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to distribute it
under certain conditions. See COPYING file for more details.

Plug-in version: 3.22.10
Installed HPLIP version: 3.22.10
Number of files to install: 64

note: Using PyQt5
QSocketNotifier: Can only be used with threads started with QThread
Traceback (most recent call last):
  File "/tmp/selfgz92927/./plugin_install.py", line 276, in 
ok = installPlugin()
 ^^^
  File "/tmp/selfgz92927/./plugin_install.py", line 85, in installPlugin
passwordObj = password.Password(mode)
  ^^^
  File "/usr/share/hplip/base/password.py", line 94, in __init__
self.__readAuthType()  # self.__authType
^
  File "/usr/share/hplip/base/password.py", line 119, in __readAuthType
distro_name = get_distro_std_name(os_name)
  ^^^
NameError: name 'get_distro_std_name' is not defined. Did you mean: 
'get_distro_name'?


OpenPGP_0x8F53E0193B294B75.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1028885: thunderbird: FTBFS: ValueError: invalid mode: 'rU'

2023-01-22 Thread James Addison
On Sun, Jan 22, 2023, 18:32 Carsten Schoenert 
wrote:

> I have locally already created a fix for this issue. Thunderbird 102.7.0
> has a known regression issue and currently we waiting for 102.7.1 which
> should be released the next days.
>

Ah, that makes sense; great - thank you, Carsten.

>


Bug#1029281: [Pkg-openssl-devel] Bug#1029281: openssl: loongarch64 is little endian

2023-01-22 Thread Sebastian Andrzej Siewior
On 2023-01-21 00:05:53 [+0800], Han Gao wrote:
>   Loongarch64 is little endian. So [1] should be removed.

Are you sure? I applied exactly what I received in #1024414. Please test
the patches that you send.

> [1]: 
> https://salsa.debian.org/debian/openssl/-/blob/debian/openssl-3.0.7-2/debian/patches/debian-targets.patch#L65

This is hppa and makes no sense. As a challange, please send a patch.

Sebastian



Bug#971739: Sioyek not migrating to testing because of britney limitation/bug

2023-01-22 Thread Paul Gevers

Hi Victor,

On 22-01-2023 16:08, Victor Westerhuis wrote:
This is bug #971739, I think, but I cannot find online what steps to 
take next. Should I switch the dependency to python3-sphinx:native? Or 
is this something that can be overridden someway?


I think for now (if you want progress) it's best to switch to B-D 
python3-spinx:native or accept that your package can't be cross-build 
for now (and drop the :native), until britney is fixed.


Paul


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1029459: hp-plugin crashes when trying to download plugin with error NameError: name 'get_distro_std_name' is not defined. Did you mean: 'get_distro_name'?

2023-01-22 Thread Pirate Praveen

Package: hplip
Version: 3.22.10+dfsg0-1
Severity: grave
Justification: makes it unusable

$ hp-plugin

HP Linux Imaging and Printing System (ver. 3.22.10)
Plugin Download and Install Utility ver. 2.1

Copyright (c) 2001-18 HP Development Company, LP
This software comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to distribute it
under certain conditions. See COPYING file for more details.


HP Linux Imaging and Printing System (ver. 3.22.10)
Plugin Download and Install Utility ver. 2.1

Copyright (c) 2001-18 HP Development Company, LP
This software comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to distribute it
under certain conditions. See COPYING file for more details.

QSocketNotifier: Can only be used with threads started with QThread
Checking for network connection...
Downloading plug-in from:
Traceback (most recent call last):
  File "/usr/share/hplip/ui5/plugindialog.py", line 248, in 
NextButton_clicked
status, download_plugin_file, error_str = 
self.pluginObj.download(self.plugin_path,self.plugin_download_callback)


^^^
  File "/usr/share/hplip/installer/pluginhandler.py", line 257, in download
core = core_install.CoreInstall()
   ^^
  File "/usr/share/hplip/installer/core_install.py", line 240, in __init__
self.passwordObj = password.Password(ui_mode)
   ^^
  File "/usr/share/hplip/base/password.py", line 94, in __init__
self.__readAuthType()  # self.__authType
^
  File "/usr/share/hplip/base/password.py", line 119, in __readAuthType
distro_name = get_distro_std_name(os_name)
  ^^^
NameError: name 'get_distro_std_name' is not defined. Did you mean: 
'get_distro_name'?

Aborted



OpenPGP_0x8F53E0193B294B75.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1004534: Please promote version 1.38.0-1 to unstable

2023-01-22 Thread Thomas Uhle

Dear maintainers of the Debian Go Packaging Team,

I would like to second Eric's wish to upload the version in experimental 
(or perhaps a newer one) to unstable too, so that it can make its way to 
bookworm before the freeze.  Or is there any reason (that of course I 
don't know) why it has to be a version like 1.33.3 instead?


AFAICS golang-google-grpc is the only dependency left that prevents the 
upgrade of golang-github-powerman-check whose previous version (that is 
still in sid) is known to FTBFS and so in turn prevents even the 
migration of dnscrypt-proxy's older version 2.0.45 that currently is in 
bullseye but is not going to be in bookworm unless anything is going to 
happen.
Would you agree to switch the severity of this ticket from "wishlist" to 
"normal" or even "important" to reflect this situation?


Best regards,

Thomas Uhle



Bug#1023472: Fix for double Window Manager in LXQt

2023-01-22 Thread Holger Wansing
Hi

Am 22. Januar 2023 18:27:18 MEZ schrieb Roland Clobus :
>sddm-theme-debian-elarun does not recommend sddm, it only suggests it.

In sddm's control I see:

Package: sddm-theme-debian-elarun Architecture: all 
Depends: desktop-base, ${misc:Depends} Recommends: sddm 
Provides: sddm-theme 
Breaks: sddm (<< ${source:Version}) 
Description: 'Debian Elarun' Theme for SDDM X11 display manager Elarun theme 
for SDDM, using the active desktop-base theme for the background. 

So a Recommends.


>In the default case of generating a live image (only depend and recommend is 
>followed), this is sufficient to fulfil the recommends 
>(sddm-theme-debian-breeze | sddm-theme) in sddm with sddm-theme-debian-elarun, 
>which is mentioned earlier and therefore the second part of the or-statement 
>will be met.

My tests in a freshly installed bookworm system showed,
that sddm is indeed installed by sddm-theme-debian-elarun 
installation (and that matches the Recommends),
so don't know, what is right.


Holger

-- 
Sent from /e/ OS on Fairphone3



Bug#1022843: Bug#1029352: Bug#1022843: ifupdown: network down after systemctl restart

2023-01-22 Thread Cyril Brulebois
Cyril Brulebois  (2023-01-22):
> The configuration found below manages to:
>  - let my allow-hotplug slow-to-appear wireless interface come up at
>boot-up, via the udev integration;
>  - allow me to stop and start networking, losing then regaining all
>relevant configs (main connection is wireless, with WPA, with DHCP,
>and SLAAC via RAs, without /e/n/i conf for SLAAC, see #1029352);
>  - allow me to restart networking, [same as previous entry].
> 
> This is just an example of something that seems to be working fine
> enough during my very limited testing, there might be cleaner ways to do
> this, better names to choose (I picked a neutral “environment” but my
> first thought was an explicit “maybe-redo-hotplug”), etc.:
> 
> [Service]
> Type=oneshot
> EnvironmentFile=-/etc/default/networking
> EnvironmentFile=-/run/network/environment
> ExecStart=/sbin/ifup -a --read-environment $ALLOW_HOTPLUG
> ExecStop=/sbin/ifdown -a --read-environment --exclude=lo
> ExecStopPost=/bin/sh -c "echo ALLOW_HOTPLUG=--allow=hotplug > 
> /run/network/environment"
> RemainAfterExit=true
> TimeoutStartSec=5min
> 
> Changes (compared to the original ifupdown service unit):
>  - an extra /run/network/environment is read if present, no errors
>otherwise; of course it doesn't exist during boot-up, since
>/run is brand new and nothing else is creating it;
>  - ExecStopPost populates that file with ALLOW_HOTPLUG=--allow=hotplug
>after each “stop” (possibly part of a “restart”) is done;
>  - ExecStart gets an extra $ALLOW_HOTPLUG parameter, that's either
>an empty string (at boot-up) or --allow=hotplug (after boot-up).

Of course I'm not familiar with the ifup interface so I fudged it. Now,
with an extra ens3 declared as auto, the following seems to work fine
for boot-up, stop and start, and restart:

[Service]
Type=oneshot
EnvironmentFile=-/etc/default/networking
ExecStart=/sbin/ifup -a --read-environment
ExecStart=/bin/sh -c 'if [ -f /run/network/restart-hotplug ]; then 
/sbin/ifup -a --read-environment --allow=hotplug; fi'
ExecStop=/sbin/ifdown -a --read-environment --exclude=lo
ExecStopPost=/usr/bin/touch /run/network/restart-hotplug
RemainAfterExit=true
TimeoutStartSec=5min

I have no opinions on how to best handle possible errors regarding the
hotplug interfaces; but again, that's secondary compared to fixing the
“start” use case.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature


Bug#1029458: RFP: sorr -- Remake of all the original Sega beat-'em-up games Streets of Rage 1, 2, and 3 - thrown into one complete package.

2023-01-22 Thread Fjords

Package: sorr
Severity: wishlist

Remake of all the original Sega beat-'em-up games Streets of Rage 1, 2, 
and 3 - thrown into one complete package.


The latest stable release upstream is 5.2. There exists a DEB package 
from the defunct ubuntugames.org for 5.1, and it runs without any issues 
on Debian. I'm aware there is no "source code" for this and would 
technically go under non-free, but I would hope if this could be 
packaged for Debian. Someone packaged 5.2 for Guix 
(https://sorr.forumotion.net/t858-version-5-2-for-gnu-linux-guix-package) 
and another one provides a Flatpak for it 
(https://sorr.forumotion.net/t708-sorr-flatpak-opengl-wrapper-for-linux), 
but an exclusive Debian build would be great. Providing a link to the 
DEB file for reference. Thank you in advance.


DEB: https://drive.google.com/file/d/0B0xypeLm7EKgNFpLMzRaZnlTMDQ/view

Upstream: 
https://sorr.forumotion.net/t838-new-streets-of-rage-remake-v5-2-download-and-info




Bug#1029457: bibletime: Build dependency on qtwebengine5-dev/libqt5webkit5-dev seems to be stale

2023-01-22 Thread Adrian Bunk
Source: bibletime
Version: 3.0.3-2
Severity: minor

Version 3.0 has removed all Qt5WebKit/Qt5WebEngineWidgets code:
https://github.com/bibletime/bibletime/commit/4a71e777248976dc748b0331ac7edb3e671a1b96



Bug#1029456: RFP: veracrypt -- Cross-platform on-the-fly encryption.

2023-01-22 Thread Fjords

Package: veracrypt
Severity: wishlist

Cross-platform on-the-fly encryption. VeraCrypt provides cross-platform 
on-the-fly encryption for Linux, MacOS X and Windows. It can encrypt 
filesystems stored either within a file or on disk partitions. Supported 
encryption algorithms include AES, Serpent and Twofish. The current 
version uses the XTS mode of disk encryption. In addition, VeraCrypt 
supports "hidden volumes" - unidentifiable volumes present in the 
free-space of a VeraCrypt volume.


VeraCrypt is a fork of the old TrueCrypt. I know there are official DEB 
files for VeraCrypt provided on their Web site (link below), but it's 
not a repository, and the only repositories I can find are unofficial 
OBS ones (such as 
https://download.opensuse.org/repositories/home:/unit193:/veracrypt). I 
think this would technically be in contrib, since it uses non-free 
code/licensing. Nonetheless, I think this would be a good addition to 
the Debian repositories, as there aren't that many other viable 
file/partition encryption alternatives. Thank you.


Upstream: https://veracrypt.fr/en/Downloads.html



Bug#1029388: linux-image-6.1.0-2-amd64: system does not boot up when swap partion is a file

2023-01-22 Thread Salvatore Bonaccorso
Control: reassign -1 dkms
Control: forcemerge 1029063 -1

Hi,

On Sun, Jan 22, 2023 at 05:17:39PM +0100, Salvatore Bonaccorso wrote:
> Control: severity -1 important
> Control: tags -1 + moreinfo
> 
> On Sun, Jan 22, 2023 at 11:12:37AM +0100, magnus wrote:
> > Package: src:linux
> > Version: 6.1.7-1
> > Severity: critical
> > Justification: breaks the whole system
> > X-Debbugs-Cc: magnus.ekd...@gmail.com
> > 
> > Dear Maintainer,
> > 
> > *** Reporter, please consider answering these questions, where appropriate 
> > ***
> > 
> >* What led up to the situation?
> > 
> > apt dist-upgrade from an older version of debian unstable
> > 
> >* What exactly did you do (or not do) that was effective (or
> >  ineffective)?
> > 
> > I got some errors (unfortunatly not saved) from upgrade process. I.e. the
> > script failed ***swap problem***, I assumed that meant the installation did 
> > not
> > finish and the old kernel would boot up.
> > 
> >* What was the outcome of this action?
> > 
> > After bootup I got kenel panic. A working workaround was to:
> > 
> > 1. boot into live debian (from the debian installer via usb)
> > 2. chroot into standard /
> > 3. comment out swapfile from /etc/fstab (from chroot)
> > 4. run apt upgrade again (this time it completed)
> > 5. reboot into standard /
> > 
> >* What outcome did you expect instead?
> > 
> > I expect that the kernel-package:
> > 
> > 1: can handle if fstab conain an entry like: /swapfile swap swap defaults 0 > > 0
> > 2: if the kenel installation script breaks, I expect the old kenerl to boot 
> > up.
> > If this is currently not technically possible I would expect a clear warning
> > that the system will be in a broken state if I reboot now.
> 
> Can you please try to get the respecive installation errors still from
> the log files, you might get sucessful from /var/log/apt/term.log .
> There was a similar issue reported earlier this week, but was not
> found to be reproducible. So if you can get to this information that
> would be helpful.

Got off-bug a reply from Magnus with the install log and it turns out
that it is actually the dkms issue in #1029063. Re-assigning and
merging the two bugs accordingly.

Regards,
Salvatore



Bug#1029455: RFP: easyrpg-player -- RPG Maker 2000/2003 and EasyRPG game interpreter.

2023-01-22 Thread Fjords

Package: easyrpg-player
Severity: wishlist

RPG Maker 2000/2003 and EasyRPG game interpreter. EasyRPG Player is a 
program that allows to play games created with RPG Maker 2000 and 2003. 
It aims to be a free (as in freedom) cross-platform RPG Maker 2000/2003 
interpreter. The main goal is to play all games created with them as the 
original game interpreter (RPG_RT.exe) does.


This would be a good package to include in Debian. It's fully compliant 
with the GPL-3.0 license, so I don't think that would be an issue. Only 
the loaded games themselves would be in any way proprietary and/or use 
copyrighted material, but the package doesn't feature any of them out of 
the box. There is an OBS repository 
(https://software.opensuse.org/download.html?project=home%3Aeasyrpg=easyrpg-player=ff=00=3C8025), 
but it's a third-party service. Thanks in advance.


Upstream: https://github.com/EasyRPG/Player



Bug#1022843: ifupdown: network down after systemctl restart

2023-01-22 Thread Cyril Brulebois
Control: reopen 1022843
Control: found 1022843 0.8.40
Control: severity 1022843 serious

Hi,

Cyril Brulebois  (2023-01-22):
> d-i believes that everything should be allow-hotplug, and we end up
> using that everywhere. I'm wondering whether to just use auto everywhere
> instead, since the hotplug detection is busted.
> 
> More details in:
>   https://bugs.debian.org/1029352
> 
> (which is mainly about wireless interfaces but ends up in the third
> issue about other kinds of interfaces as well.)

I've done some testing, and I think the patch is making matters worse:
 - networking.service can start very early, at which point interfaces
   might not be ready yet, firmware loaded, etc.
 - with the extra ExecStart, forcing allow-hotplug entries, and ignoring
   failures, I strongly suspect (but didn't triple-check) that we end up
   with interfaces getting considered up even if they aren't, which
   interfers with the udev integration (the /lib/udev/ifupdown-hotplug
   script no longer works: the interface is supposed to be up already!).

It looks to me that this patch should be reverted for bookworm, as it
aims to make “restart” work, but it breaks simple “start”.

It seems systemd supports an ExecReload directive, but no matching
ExecRestart, so I think we end up with restart forcingly calling
ExecStop then ExecStart (plus relevant Pre/Post if any).

I have no idea about ifupdown's architecture, but it looks to me that it
might make sense to have some way of knowing whether that's the first
time the unit is started, if which case stick to the working, existing
logic. And if it's not, add --allow=hotplug.

I don't think we can use systemd unit's NRestarts since it counts
restarts triggered via Restart=always and friends, so maintaining a flag
file instead might work?

The configuration found below manages to:
 - let my allow-hotplug slow-to-appear wireless interface come up at
   boot-up, via the udev integration;
 - allow me to stop and start networking, losing then regaining all
   relevant configs (main connection is wireless, with WPA, with DHCP,
   and SLAAC via RAs, without /e/n/i conf for SLAAC, see #1029352);
 - allow me to restart networking, [same as previous entry].

This is just an example of something that seems to be working fine
enough during my very limited testing, there might be cleaner ways to do
this, better names to choose (I picked a neutral “environment” but my
first thought was an explicit “maybe-redo-hotplug”), etc.:

[Service]
Type=oneshot
EnvironmentFile=-/etc/default/networking
EnvironmentFile=-/run/network/environment
ExecStart=/sbin/ifup -a --read-environment $ALLOW_HOTPLUG
ExecStop=/sbin/ifdown -a --read-environment --exclude=lo
ExecStopPost=/bin/sh -c "echo ALLOW_HOTPLUG=--allow=hotplug > 
/run/network/environment"
RemainAfterExit=true
TimeoutStartSec=5min

Changes (compared to the original ifupdown service unit):
 - an extra /run/network/environment is read if present, no errors
   otherwise; of course it doesn't exist during boot-up, since
   /run is brand new and nothing else is creating it;
 - ExecStopPost populates that file with ALLOW_HOTPLUG=--allow=hotplug
   after each “stop” (possibly part of a “restart”) is done;
 - ExecStart gets an extra $ALLOW_HOTPLUG parameter, that's either
   an empty string (at boot-up) or --allow=hotplug (after boot-up).

If people want to discuss this further, please feel free to, but I'd
welcome a quick revert of the initial patch for #1022843: unbreaking
“start” seems much more important than fixing a longstanding shortage
in “restart”. But I'm sure Oleg can help us figure out whether this
proposed change makes sense (maybe also testing on bullseye), so that
we can fix the regression and the original issue by keeping track of
this single bug report. Otherwise, I can file a different bug report
about the regression specifically. Reopening and bumping severity on
#1022843 for the time being.


This might mean considering the third issue listed in #1029352 as a
non-issue, at least for bookworm: we could keep listing (apparently)
all interfaces as “allow-hotplug”.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature


Bug#1029454: RFP: apt-fast -- A shellscript wrapper for apt that speeds up downloading of packages.

2023-01-22 Thread Fjords

Package: apt-fast
Severity: wishlist

A shellscript wrapper for apt that speeds up downloading of packages.

Just as we have nala as an alternative to using apt-get, could we please 
get apt-fast in the official repositories? Unless you compile, you'd 
have to install from an Ubuntu PPA 
(https://code.launchpad.net/~apt-fast/+archive/stable). Thank you in 
advance.


Upstream: https://github.com/ilikenwf/apt-fast



Bug#1027435: ncurses-base: Breaks pasting in vim within tmux

2023-01-22 Thread Sven Joachim
Control: tags -1 pending

On 2023-01-11 18:48 +0100, Sven Joachim wrote:

> On 2023-01-01 18:25 +0100, Sven Joachim wrote:
>
>> So far so good, and I have already prepared ncurses 6.4-1 in git.  Now
>> the bad news: it turned out that bracketed paste support in vim had
>> (always?) been broken without anybody noticing it, because no terminal
>> descriptions had included this feature.  Only two days ago Bram
>> Moolenaar fixed the problem in patch 9.0.1117[1].
>>
>> I have backported this patch to the debian/sid branch in vim's git
>> repository and can confirm that it fixes the problem, as long as
>> ncurses-base is also upgraded to version 6.4-1.
>
> James was so kind to upload this fix the next day, and so things have
> been fine in unstable since then.  However Bookworm is still broken,
> with vim currently unable to migrate because of vim-ultisnips'
> autopkgtest failure in #1028442.
>
> Once the fixed vim migrates to testing I intent to add versioned Breaks
> on vim-common to ncurses-base and ncurses-term, so that users do not
> experience the problem on partial upgrades from Bullseye, and close the
> current bug.

Vim has migrated to testing today (according to rmadison,
tracker.debian.org seems to be a bit behind), so I added the versioned
Breaks in git[1].  This should have sent out a mail which marks the bug
as pending and informs the submitter, but for some unknown reason it
didn't.  Anyway, good to see that things have been sorted out by now.

Cheers,
   Sven


1. 
https://salsa.debian.org/debian/ncurses/-/commit/12bb87e58cf0ad787b90281452404a9ee1240244



Bug#1029453: avahi-daemon fills log with Withdrawing address record / Registering address record for ipv6 address

2023-01-22 Thread Tobias Rupf
Package: avahi-daemon
Version: 0.8-5+deb11u1
Severity: normal
Tags: ipv6
X-Debbugs-Cc: t...@security.debian.org

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

As the headine nearly once every second a message is logged in the syslog that 
carrent ipv6 is withdraw
followed by one which tells it is regitered again. The issue is for ipv6 only 
and I have multipe addresses
assigned to the interface. The message is logged for the global and link local 
address which are auto-
generated, but not for the manually assigned ULA address.
I'm using current stable build and I haven't had the issue with the latest 
package before this version.
...and my DNS doesn't reslove the .local domain.
Resolving .local with avahi still works

*** End of the template - remove these template lines ***


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

Kernel: Linux 5.14.0-0.bpo.2-amd64 (SMP w/4 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages avahi-daemon depends on:
ii  adduser  3.118
ii  bind9-host [host]1:9.18.10-2~bpo11+1
ii  dbus 1.12.24-0+deb11u1
ii  init-system-helpers  1.64~bpo11+1
ii  libavahi-common3 0.8-5+deb11u1
ii  libavahi-core7   0.8-5+deb11u1
ii  libc62.31-13+deb11u5
ii  libcap2  1:2.44-1
ii  libdaemon0   0.14-7.1
ii  libdbus-1-3  1.12.24-0+deb11u1
ii  libexpat12.2.10-2+deb11u5
ii  lsb-base 11.1.0

Versions of packages avahi-daemon recommends:
ii  libnss-mdns  0.14.1-2

Versions of packages avahi-daemon suggests:
pn  avahi-autoipd  

-- no debconf information



Bug#1020641: dhcpcd5: dhcpcd fails to chroot during start

2023-01-22 Thread Martin-Éric Racine
On Sun, 22 Jan 2023 17:22:35 +0100  wrote:

> This is kind of a continuation from 1014277, where I have mentioned that
> it still logs some chroot related issues.
> Now I have the time to create a proper patch and attach it to this bug.
> It would be great if it could make it to bookworm, as the freeze is
> coming :)

Thanks! The fix seems simple enough. However, I'm a bit worried about
introducing it so close to the freeze.

> Reporting that to upstream does not make sense right now, as the systemd
> unit files are debian specific additions.

Agreed, although it would make sense for upstream to ship those
systemd units as well. However, this would probably require fixing
outstanding issues outlined in bug #1020641 first.

Martin-Éric



Bug#1029452: python-skbio: (autopkgtest) needs update for NumPy 1.24

2023-01-22 Thread Graham Inggs
Source: python-skbio
Version: 0.5.8-1
Severity: serious
User: debian...@lists.debian.org
Usertags: needs-update

Hi Maintainer

The autopkgtests of python-skbio fail with NumPy 1.24 [1].  I've
copied what I hope is the relevant part of the log below.

Regards
Graham


[1] https://ci.debian.net/packages/p/python-skbio/testing/amd64/


=== FAILURES ===
___ TestLoc.test_multiindex_complicated_axis ___

self = 

def test_multiindex_complicated_axis(self):
a = RNA("UUAG", metadata={0: 0}, positional_metadata={0: [1, 2, 3, 4]})
b = RNA("UAAG", metadata={1: 0}, positional_metadata={1: [1, 2, 3, 4]})
c = RNA("UAA-", metadata={2: 0}, positional_metadata={2: [1, 2, 3, 4]})
d = RNA("UA-G", metadata={3: 0}, positional_metadata={3: [1, 2, 3, 4]})
msa = TabularMSA([a, b, c, d], metadata={'x': 'y'},
 positional_metadata={'c': ['a', 'b', 'c', 'd']},
 index=[('a', 'x', 0), ('a', 'x', 1), ('a', 'y', 2),
('b', 'x', 0)])

>   self.assertEqual(self.get(msa, (([False, True, False, True],
 'x', 0), Ellipsis)),
 TabularMSA([d], metadata={'x': 'y'},
positional_metadata={'c': ['a', 'b', 'c',
   'd']},
index=[('b', 'x', 0)]))

skbio/alignment/tests/test_tabular_msa.py:1373:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
skbio/alignment/tests/test_tabular_msa.py:1271: in get
return obj.loc[indexable]
skbio/alignment/_indexing.py:39: in __getitem__
return self._handle_both_axes(*indexable)
skbio/alignment/_indexing.py:53: in _handle_both_axes
r = self._slice_on_first_axis(self._obj, seq_index)
skbio/alignment/_indexing.py:77: in _slice_on_first_axis
return self._slice_sequences(obj, indexable)
skbio/alignment/_indexing.py:202: in _slice_sequences
self._assert_bool_vector_right_size(indexable, axis=0)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

self = 
indexable = ([False, True, False, True], 'x', 0), axis = 0

def _assert_bool_vector_right_size(self, indexable, axis):
if isinstance(indexable, np.ndarray):
pass
elif hasattr(indexable, '__iter__'):
>   indexable = np.asarray(list(indexable))
E   ValueError: setting an array element with a sequence. The
requested array has an inhomogeneous shape after 1 dimensions. The
detected shape was (3,) + inhomogeneous part.

skbio/alignment/_indexing.py:116: ValueError
___ TestLoc.test_multiindex_complicated_axis_empty_selection ___

self = 

@unittest.skipIf(tuple(map(int, pd.__version__.split('.'))) < (1, 2, 5),
 "Old pandas will return empty frame")
def test_multiindex_complicated_axis_empty_selection(self):
a = RNA("UUAG", metadata={0: 0}, positional_metadata={0: [1, 2, 3, 4]})
b = RNA("UAAG", metadata={1: 0}, positional_metadata={1: [1, 2, 3, 4]})
c = RNA("UAA-", metadata={2: 0}, positional_metadata={2: [1, 2, 3, 4]})
d = RNA("UA-G", metadata={3: 0}, positional_metadata={3: [1, 2, 3, 4]})
msa = TabularMSA([a, b, c, d], metadata={'x': 'y'},
 positional_metadata={'c': ['a', 'b', 'c', 'd']},
 index=[('a', 'x', 0), ('a', 'x', 1), ('a', 'y', 2),
('b', 'x', 0)])
# Pandas will KeyError when the intersection is empty
# change appears to have happened in:
# https://github.com/pandas-dev/pandas/pull/42245
# but this was not bisected to confirm
with self.assertRaises(KeyError):
>   self.get(msa, (([False, True, False, True], 'x', 2), Ellipsis))

skbio/alignment/tests/test_tabular_msa.py:1396:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
skbio/alignment/tests/test_tabular_msa.py:1271: in get
return obj.loc[indexable]
skbio/alignment/_indexing.py:39: in __getitem__
return self._handle_both_axes(*indexable)
skbio/alignment/_indexing.py:53: in _handle_both_axes
r = self._slice_on_first_axis(self._obj, seq_index)
skbio/alignment/_indexing.py:77: in _slice_on_first_axis
return self._slice_sequences(obj, indexable)
skbio/alignment/_indexing.py:202: in _slice_sequences
self._assert_bool_vector_right_size(indexable, axis=0)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

def _assert_bool_vector_right_size(self, indexable, axis):
if isinstance(indexable, np.ndarray):
pass
elif hasattr(indexable, '__iter__'):
>   indexable = np.asarray(list(indexable))
E   ValueError: setting an array element with a sequence. The
requested 

Bug#1029269: gio-2.0.pc references the wrong glib-compile-schemas again

2023-01-22 Thread Helmut Grohne
Hi Simon,

thank you very much for your quick and detailed answer! Let me point out
though that this is not urgent nor is there an expectation to fix this
in bookworm.

On Fri, Jan 20, 2023 at 05:01:44PM +, Simon McVittie wrote:
> So that this is written down somewhere: this is because libglib2.0-0 needs
> to run (some version of) g-c-s via its triggers. The naive implementation
> of this would be to split out g-c-s into its own binary package, but
> as well as being a bit of a waste of space (g-c-s is only 64K), that
> would introduce a circular dependency, because glib-compile-schemas has
> DT_NEEDED on libgio-2.0.so.0 and others:
> 
>for triggers
> libglib2.0-0 ---> glib-compile-schemas
>  M-A: same   <---   M-A: foreign
> via dpkg-shlibdeps
> 
> Splitting up libglib2.0-0 into its separate SONAMEs with their
> Policy-compliant package names would not help here, because it's
> libgio-2.0.so.0 that makes most sense to "own" the trigger for schemas,
> but glib-compile-schemas depends on libgio-2.0.so.0. So the same circular
> dependency would exist for libgio-2.0-0.

Is such a circular dependency actually a problem? We do have such cycles
in a few places. A popular example is libdevmapper1.02.1 <-> dmsetup.
apt can handle such cycles. It breaks the configure loop in one way or
another. Either it decides to configure libglib2.0-0 first. It would run
its postinst, then libglib2.0-bin's postinst (noop) and then invoke
triggers. All seems fine. Or it would configure in the other order and
run triggers last as well. In this case, it may run glib-compile-schemas
before having run ldconfig after unpacking libglib2.0-0. That is a
little slower, but should also work. I fail to see what could break
here.

> Because you have argued that glib-compile-schemas is an
> architecture-independent interface, I think if other packages want
> to run glib-compile-schemas *at build-time*, and they want to be
> cross-compilable, then they ought to be looking for a build-architecture
> tool, similar to the way dbus-binding-tool was traditionally handled.

Outside the meson ecosystem, dealing with two pkg-config is very rare.
When looking beyond Debian, the expectation typically is a different
one: When cross building, you are expected to build packages (such as
glib2.0) specifically for a combination of build and host architecture
such that the one .pc file references the mixture of tools. It is only
meson that tries to change this picture with limited success.

> or some combination of the two (where "native: true" is the part that
> gets you a build-architecture dependency lookup, instead of the default
> host-architecture).

This is difficult to achieve with autoconf and next to impossible to
achieve with CMake. As it happens, ibus-unikey uses CMake.

> I don't think it's really reasonable to expect that querying a
> variable from a host-architecture pkg-config file will give you a
> build-architecture executable - how would that work in general, when the
> host-architecture pkg-config file is common to all build architectures,
> and generally specifies its tools by their absolute path? For instance, in
> traditional (pre-multiarch) cross-compilation, each architecture of GLib
> would have installed its own /usr/${tuple}/bin/glib-compile-schemas, and
> querying the ARM pkg-config file would always give you an ARM executable,
> never an x86 executable.

The way this works in general (outside Debian) is that you build your
toolchain specifically for your combination of build and host
architecture. That's how basically all qt cross toolchains (except
Debian's work). Of course this approach produces O(n^2) toolchains for n
architectures and for Debian that's very much not what we want. But it
happens to be what many upstreams expect.

> However, I'm aware that many build systems don't have as principled
> a dividing line between build- and host-architecture dependencies
> as Meson does; and for Debian specifically, given the organization
> of our GLib packaging, it would be harmless to go back to having
> glib_compile_schemas=${bindir}/glib-compile-schemas on all architectures,
> which would have the side-effect of it not mattering which architecture
> you ask for the appropriate path.

Yeah. I don't think we have to upstream this change. Carrying such a
difference as a Debian patch (even post-build) would seem reasonable to
me.

> Because this is not a recent regression, I'd prefer to
> let the recently-uploaded GLib 2.74.5 migrate to testing
> before fixing this, but I agree it would be pragmatic to use
> glib_compile_schemas=${bindir}/glib-compile-schemas in bookworm.

There is little urgency from my point of view. I'm looking for a
sustainable long-term solution here.

> This would likely be unappealing upstream, particularly in the short
> term, because it relies on the
> ${bindir}/glib-compile-schemas -> ${libdir}/glib-2.0/glib-compile-schemas
> symlink 

Bug#1029234: lyx: Graphic problems editing a lyx file

2023-01-22 Thread Dr. Tobias Quathamer

control: tag -1 unreproducible
control: severity -1 important

Am 20.01.23 um 15:21 schrieb Stefano Simonucci:

I get the following messages:

sudo apt build-dep lyx
[sudo] password di stefano:
Lettura elenco dei pacchetti... Fatto
Lettura elenco dei pacchetti... Fatto
Generazione albero delle dipendenze... Fatto
Lettura informazioni sullo stato... Fatto
Alcuni pacchetti non possono essere installati. Questo può voler dire
che è stata richiesta una situazione impossibile oppure, se si sta
usando una distribuzione in sviluppo, che alcuni pacchetti richiesti
non sono ancora stati creati o sono stati rimossi da Incoming.
Le seguenti informazioni possono aiutare a risolvere la situazione:

I seguenti pacchetti hanno dipendenze non soddisfatte:
  libboost-iostreams1.74-dev : Dipende: libboost1.74-dev (= 1.74.0-9) ma 
la versione 1.74.0-18.1 sta per essere installata
   Dipende: libboost-regex1.74-dev (= 
1.74.0-9) ma la versione 1.74.0-18.1 sta per essere installata
   Dipende: libboost-iostreams1.74.0 (= 
1.74.0-9) ma la versione 1.74.0-18.1 sta per essere installata
  libenchant-2-dev : Dipende: libenchant-2-2 (= 2.2.15-1) ma la versione 
2.3.3-2 sta per essere installata

     Dipende: libglib2.0-dev ma non è installabile
  libmagic-dev : Dipende: libmagic1 (= 1:5.39-3) ma la versione 1:5.41-4 
sta per essere installata
  libmythes-dev : Dipende: libmythes-1.2-0 (= 2:1.2.4-3+b1) ma la 
versione 2:1.2.5-1 sta per essere installata
E: Impossibile correggere i problemi, ci sono pacchetti danneggiati 
bloccati.



Maybe I must downgrade also these packages!

Stefano


Hi Stefano,

unfortunately, I'm not able to reproduce the error you're seeing. 
Therefore, I'm downgrading the bug's severity to important, to avoid LyX 
being removed from the next Debian stable release.


I suspect that the error you're experiencing comes from another package, 
which has to do with the graphic environment you're using. I have no 
idea, which package that might be, though.


Sorry that I cannot provide any more useful ideas to narrow down this bug.

Regards,
Tobias



OpenPGP_signature
Description: OpenPGP digital signature


Bug#1029451: gnome-remote-desktop FTBFS with nocheck profile: missing gudev-1.0.pc

2023-01-22 Thread Helmut Grohne
Source: gnome-remote-desktop
Version: 43.3-1
Tags: ftbfs
Severity: important
Justification: will be rc after bookworm

gnome-remote-desktop fails to build from source in unstable when built
with the nocheck build profile, because it misses a dependency for
gudev-1.0.pc as shipped by libgudev-1.0-dev, which is erroneously tagged
. Please remove the annotation and ensure that building with
the nocheck build profile actually works.

Helmut



Bug#935188: php-apcu: Missing apc.php script

2023-01-22 Thread Christian Kujau
Package: php-apcu
Version: 5.1.19+4.0.11-3
Followup-For: Bug #935188

Dear Maintainer,

the script is still missing from php-apcu 5.1.19.

Workaround: grab the missing script from PECL or from its source tree:

 wget https://github.com/krakjoe/apcu/raw/master/apc.php -O /var/www/apc.php

Adjust the target location as needed of course.

For some reason the Debian build process is trying to do some magic in 
https://salsa.debian.org/php-team/pecl/php-apcu/-/blob/debian/main/debian/php-apcu.docs:

  */apcu-*/NOTICE
  */apcu-*/README.md
  */apcu-*/TECHNOTES.txt
  */apcu-*/TODO
  */apcu-*/apc.php

but this fails: 
https://buildd.debian.org/status/fetch.php?pkg=php-apcu=amd64=5.1.19%2B4.0.11-3=1613327271=0

  dh_installdocs: warning: Cannot find (any matches for) "*/apcu-*/apc.php" 
(tried in .)

The whole build process feels overly complicated, but maybe I just don't 
understand it :-)
The fix would be just to copy the file into usr/share/doc/php-apcu and turn 
this into a tarball, or package, no?

Thanks,
Christian.

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

Kernel: Linux 6.2.0-rc1 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages php-apcu depends on:
ii  libapache2-mod-php7.4 [phpapi-20190902]  7.4.33-1+deb11u1
ii  libc62.31-13+deb11u5
ii  php-common   2:76
ii  php7.4-cli [phpapi-20190902] 7.4.33-1+deb11u1
ii  php7.4-fpm [phpapi-20190902] 7.4.33-1+deb11u1

Versions of packages php-apcu recommends:
pn  php-apcu-bc  

Versions of packages php-apcu suggests:
ii  php-gd  2:7.4+76
ii  php7.4-gd [php-gd]  7.4.33-1+deb11u1

-- no debconf information



Bug#1029450: datalad: FTBFS due to flaky build-time test

2023-01-22 Thread Graham Inggs
Source: datalad
Version: 0.18.1-1
Tags: ftbfs

Hi Maintainer

As can be seen on reproducible builds [1], datalad 0.18.1-1 often
FTBFS there.  I've copied what I hope is the relevant part of the log
below.

Regards
Graham


[1] https://tests.reproducible-builds.org/debian/rb-pkg/datalad.html


=== FAILURES ===
_ test_gracefull_death _

def test_gracefull_death():

def assert_provides_and_raises(pc, exception, target=None):
"""Helper to get all results before exception is raised"""
results = []
with assert_raises(exception):
for r in pc:
results.append(r)
# results should be sorted since we do not guarantee order
results = sorted(results)
if target is not None:
assert_equal(results, target)
return results

def interrupted_producer():
yield 1
raise ValueError()

def consumer(i):
sleep(0.001)
yield i

assert_provides_and_raises(
ProducerConsumer(interrupted_producer(), consumer,
jobs=3), ValueError, [1])

def faulty_consumer(i):
sleep(0.001)
if i == 1:
raise ValueError()
return i

# so we do not get failed, but other parallel ones finish their job
results = assert_provides_and_raises(
ProducerConsumer(range(1000), faulty_consumer, jobs=5), ValueError)
# and analysis of futures to raise an exception can take some
time etc, so
# we could get more, but for sure we should not get all 999
and not even a 100
if info_log_level:
>   assert_greater(100, len(results))

datalad/support/tests/test_parallel.py:177:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

first = 100, second = 245, msg = None

def assert_greater(first, second, msg=None):
if msg is None:
>   assert first > second
E   assert 100 > 245



Bug#1028885: thunderbird: FTBFS: ValueError: invalid mode: 'rU'

2023-01-22 Thread Carsten Schoenert

Control: tags -1 pending

Hi,

Am 22.01.23 um 18:26 schrieb James Addison:

Source: thunderbird
Followup-For: Bug #1028885

This looks like a similar/identical problem in the 'mozbuild' Python scripts
under Python 3.11 as experienced in Debian bug #1028716 for the mozjs102
package.

The contents of the (quilt) patch used to fix #1028716 can be cherry-picked
(with one conflict to resolve in the 'debian/patches/series' file) and do apply
cleanly using quilt against the thunderbird '1:102.6.0-1' tag using:

   git cherry-pick -x f51a1f902757c4f10f7c75dfa541fb673ecab6c2

(I haven't confirmed whether the build succeeds with those changes in place,
though)


I have locally already created a fix for this issue. Thunderbird 102.7.0 
has a known regression issue and currently we waiting for 102.7.1 which 
should be released the next days.


--
Regards
Carsten



Bug#1016937: atop: autopkgtest regression on arm64 and armhf and times out on s390x

2023-01-22 Thread Computer Enthusiastic

Hello,

Can something still be done to let atop make to Debian Bookworm ?

Thanks.



Bug#1028546: voms-api-java 3.3.2-1+deb11u1 flagged for acceptance

2023-01-22 Thread Adam D Barratt
package release.debian.org
tags 1028546 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: voms-api-java
Version: 3.3.2-1+deb11u1

Explanation: 



Bug#1028571: akregator 20.08.3-1+deb11u1 flagged for acceptance

2023-01-22 Thread Adam D Barratt
package release.debian.org
tags 1028571 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: akregator
Version: 20.08.3-1+deb11u1

Explanation: fix validity checks, including fixing deletion of feeds and folders



Bug#1028468: tomcat9 9.0.43-2~deb11u5 flagged for acceptance

2023-01-22 Thread Adam D Barratt
package release.debian.org
tags 1028468 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: tomcat9
Version: 9.0.43-2~deb11u5

Explanation: add OpenJDK 17 support to JDK detection



Bug#1028486: jersey1 1.19.3-6+deb11u1 flagged for acceptance

2023-01-22 Thread Adam D Barratt
package release.debian.org
tags 1028486 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: jersey1
Version: 1.19.3-6+deb11u1

Explanation: fix build failure with libjettison-java 1.5.3



Bug#1028054: macromoleculebuilder 3.2+dfsg-2+deb11u1 flagged for acceptance

2023-01-22 Thread Adam D Barratt
package release.debian.org
tags 1028054 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: macromoleculebuilder
Version: 3.2+dfsg-2+deb11u1

Explanation: fix build failure by adding build dependency on docbook-xsl



Bug#1009659: spyder 4.2.1+dfsg1-3+deb11u1 flagged for acceptance

2023-01-22 Thread Adam D Barratt
package release.debian.org
tags 1009659 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: spyder
Version: 4.2.1+dfsg1-3+deb11u1

Explanation: fix duplication of code when saving



Bug#1022843: ifupdown: network down after systemctl restart

2023-01-22 Thread Cyril Brulebois
Hi Oleg,

Greetings with my Debian Installer hat on.

Oleg A. Arkhangelsky  (2023-01-21):
> P.S.: Yes, probably Debian installer should add PCI NICs as auto, not
> as allow-hotplug, but in this case after fresh installing Debian and
> just adding your wlan0 configuration (not changing eth0 which will be
> auto) you'll get the same boot delay even without my change.

d-i believes that everything should be allow-hotplug, and we end up
using that everywhere. I'm wondering whether to just use auto everywhere
instead, since the hotplug detection is busted.

More details in:
  https://bugs.debian.org/1029352

(which is mainly about wireless interfaces but ends up in the third
issue about other kinds of interfaces as well.)


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature


Bug#1029449: ifupdown: boot delay if wired connection unplugged

2023-01-22 Thread Amy Kos

Package: ifupdown
Version: 0.8.40
Severity: minor


Hi,

systemd-analyze blame shows:
 1min 10.333s networking.service

reverting patch that closed: #1022843
https://salsa.debian.org/debian/ifupdown/-/merge_requests/17/diffs?commit_id=f374fcd776616315aae514729797349216482526

shows again expected:
 395ms networking.service

Cheers,
Amy



Bug#1027943: regina-normal FTBFS with Python 3.11 as default version

2023-01-22 Thread Graham Inggs
Control: tags -1 + patch fixed-upstream

There's an upstream commit [1] that seems to fix the build with Python 3.11.


[1] 
https://github.com/regina-normal/regina/commit/8a583ee4ed8066103c530b91c6df4efa512203aa
From 8a583ee4ed8066103c530b91c6df4efa512203aa Mon Sep 17 00:00:00 2001
From: Benjamin Burton 
Date: Thu, 17 Nov 2022 23:46:32 +1000
Subject: [PATCH] A quick hack for now to ensure that the basic embedded
 interpreter in the test suite (python/testsuite/basic.cpp) will respect
 PYTHONPATH, so that it can be run directly out of the build tree.

---
 python/pybind11/embed.h |  4 
 python/pybind11/regina.patch| 15 +++
 python/testsuite/CMakeLists.txt |  1 +
 3 files changed, 20 insertions(+)

diff --git a/python/pybind11/embed.h b/python/pybind11/embed.h
index d6999cd77..31dd7950b 100644
--- a/python/pybind11/embed.h
+++ b/python/pybind11/embed.h
@@ -150,6 +150,10 @@ inline void initialize_interpreter(bool init_signal_handlers = true,
 #else
 PyConfig config;
 PyConfig_InitIsolatedConfig();
+#if REGINA_PYTHON_USE_PYTHONPATH
+config.use_environment = 1;
+config.isolated = 0;
+#endif
 config.install_signal_handlers = init_signal_handlers ? 1 : 0;
 
 PyStatus status = PyConfig_SetBytesArgv(, argc, const_cast(argv));
diff --git a/python/pybind11/regina.patch b/python/pybind11/regina.patch
index a9a1cf4c1..6da9bd828 100644
--- a/python/pybind11/regina.patch
+++ b/python/pybind11/regina.patch
@@ -156,3 +156,18 @@ index d61dcd5c7..9675827af 100644
  pybind11::function override   \
  = pybind11::get_override(static_cast(this), name); \
  if (override) {   \
+diff --git a/python/pybind11/embed.h b/python/pybind11/embed.h
+index d6999cd77..31dd7950b 100644
+--- a/python/pybind11/embed.h
 b/python/pybind11/embed.h
+@@ -150,6 +150,10 @@ inline void initialize_interpreter(bool init_signal_handlers = true,
+ #else
+ PyConfig config;
+ PyConfig_InitIsolatedConfig();
++#if REGINA_PYTHON_USE_PYTHONPATH
++config.use_environment = 1;
++config.isolated = 0;
++#endif
+ config.install_signal_handlers = init_signal_handlers ? 1 : 0;
+ 
+ PyStatus status = PyConfig_SetBytesArgv(, argc, const_cast(argv));
diff --git a/python/testsuite/CMakeLists.txt b/python/testsuite/CMakeLists.txt
index fabf36891..4e01572f0 100644
--- a/python/testsuite/CMakeLists.txt
+++ b/python/testsuite/CMakeLists.txt
@@ -12,6 +12,7 @@ CONFIGURE_FILE(
 
 # A very basic interpreter to use for testing:
 INCLUDE_DIRECTORIES(${Python_INCLUDE_DIRS} ${ENGINE_INCLUDES} "${PROJECT_BINARY_DIR}/engine")
+ADD_COMPILE_DEFINITIONS(REGINA_PYTHON_USE_PYTHONPATH=1)
 ADD_LINK_OPTIONS(${Python_LINK_OPTIONS})
 add_executable(basic
   basic.cpp


Bug#1028721: khard: FTBFS: distutils.errors.DistutilsError: Command '['/usr/bin/python3.10', '-m', 'pip', '--disable-pip-version-check', 'wheel', '--no-deps', '-w', '/tmp/tmpyt_g2chc', '--quiet', 'tom

2023-01-22 Thread Félix Sipma

Hi,

I tried to reproduce the issue, but the package just built fine. Maybe 
it was a temporary issue with setuptools_scm? #1027947




On 2023-01-14 13:40+0100, Lucas Nussbaum wrote:

Source: khard
Version: 0.18.0-1
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20230113 ftbfs-bookworm

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.

Relevant part (hopefully):

make[1]: Entering directory '/<>'
dh_auto_clean
I: pybuild base:240: python3.10 setup.py clean
/usr/lib/python3/dist-packages/setuptools/installer.py:27: 
SetuptoolsDeprecationWarning: setuptools.installer is deprecated. Requirements 
should be satisfied by a PEP 517 installer.
 warnings.warn(
WARNING: The wheel package is not available.
/usr/bin/python3.10: No module named pip
Traceback (most recent call last):
 File "/usr/lib/python3/dist-packages/setuptools/installer.py", line 82, in 
fetch_build_egg
   subprocess.check_call(cmd)
 File "/usr/lib/python3.10/subprocess.py", line 369, in check_call
   raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['/usr/bin/python3.10', '-m', 'pip', 
'--disable-pip-version-check', 'wheel', '--no-deps', '-w', '/tmp/tmpyt_g2chc', 
'--quiet', 'tomli>=1.0.0']' returned non-zero exit status 1.

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
 File "/<>/setup.py", line 13, in 
   setup(
 File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line 86, in setup
   _install_setup_requires(attrs)
 File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line 80, in 
_install_setup_requires
   dist.fetch_build_eggs(dist.setup_requires)
 File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 874, in 
fetch_build_eggs
   resolved_dists = pkg_resources.working_set.resolve(
 File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 789, in 
resolve
   dist = best[req.key] = env.best_match(
 File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 1075, in 
best_match
   return self.obtain(req, installer)
 File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 1087, in 
obtain
   return installer(requirement)
 File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 944, in 
fetch_build_egg
   return fetch_build_egg(self, req)
 File "/usr/lib/python3/dist-packages/setuptools/installer.py", line 84, in 
fetch_build_egg
   raise DistutilsError(str(e)) from e
distutils.errors.DistutilsError: Command '['/usr/bin/python3.10', '-m', 'pip', 
'--disable-pip-version-check', 'wheel', '--no-deps', '-w', '/tmp/tmpyt_g2chc', 
'--quiet', 'tomli>=1.0.0']' returned non-zero exit status 1.
E: pybuild pybuild:388: clean: plugin distutils failed with: exit code=1: 
python3.10 setup.py clean
dh_auto_clean: error: pybuild --clean -i python{version} -p "3.10 3.11" 
returned exit code 13
make[1]: *** [debian/rules:13: override_dh_auto_clean] Error 25


The full build log is available from:
http://qa-logs.debian.net/2023/01/13/khard_0.18.0-1_unstable.log

All bugs filed during this archive rebuild are listed at:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20230113;users=lu...@debian.org
or:
https://udd.debian.org/bugs/?release=na=ign=7=7=only=ftbfs-20230113=lu...@debian.org=1=1=1=1#results

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

If you reassign this bug to another package, please mark it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects

If you fail to reproduce this, please provide a build log and diff it with mine
so that we can identify if something relevant changed in the meantime.


--
Félix


signature.asc
Description: PGP signature


Bug#1018811: [Debian-pan-maintainers] Bug#1018811: Three new test issues preventing upload of patch (Was: pyfai: autopkgtest regression on armel and i386)

2023-01-22 Thread Jerome Kieffer
On Sun, 22 Jan 2023 16:56:46 +0100
Andreas Tille  wrote:

> Thanks for commenting on this.  Would you be able to push the needed changes
> to Salsa (and preferably upload)?

Hi Andreas,

I know a bit about debian packaging and also about the gitlab-CI, but I never 
used the later for the former.

I just re-acetivated my salsa account and forked the project.

Now what should I do ?
* I guess replace the content of the master branch with the newest release
* should I update the content of any other branch ?
* then perform a merge-request on the scient-team 

Maybe (probably) there is a documentation existing, but as usual a
quick googling did not provide the adequate answer.

Cheers,

Jerome



Bug#1027952: pcre2 causes crashes in link-grammar

2023-01-22 Thread Simon McVittie
On Sun, 22 Jan 2023 at 17:07:05 +, Simon McVittie wrote:
> On Sat, 07 Jan 2023 at 22:07:31 +, Matthew Vernon wrote:
> > I'm struggling a bit here; I wanted to try and bisect pcre2 upstream commits
> > to see where this bug might have been introduced (or get to the bottom of
> > what link-grammar's test is doing wrong, I see they've been troublesome in
> > the past cf #975696).
> 
> # apt install git
> # git clone https://github.com/PCRE2Project/pcre2
> # cd /root/pcre2
> # git checkout pcre2-10.42
> # ./autogen.sh
> # ./configure CFLAGS="-fsanitize=address -fno-omit-frame-pointer 
> -fsanitize=undefined" --prefix=/usr
> # make
> # ( cd /root/link-grammar-5.11.0~dfsg && debuild 
> -eASAN_OPTIONS=detect_leaks=0 -eDEB_BUILD_OPTIONS="noopt 
> sanitize=+address,+undefined" -eLD_PRELOAD=libasan.so.8 
> -eLD_LIBRARY_PATH=/root/pcre2/.libs -us -uc -b )
>   ... tests fail ...

Bisection suggests that the first bad commit is d90fb238 "Refactor
match_data() to always use the heap instead of having an initial frames
vector on the stack; some consequential adjustmentsneeded.", which seems
like a plausible place to have introduced a heap overflow.

smcv



Bug#1028565: Acknowledgement (upgrade-reports: Audio breaks between 5.10.0-19-amd64 and 5.10.0-20-amd64)

2023-01-22 Thread Markus Kramer
Hi Salvatore,
Yes, I executed the steps in 4.2.1.

These is what I did:

###
sudo apt install build-essential fakeroot
sudo apt build-dep linux
sudo apt install devscripts

sudo apt install linux-source-5.10
sudo apt source linux

tar xaf /usr/src/linux-source-5.10.tar.xz
cd linux-source-5.10

sudo apt install libncurses-dev
make menuconfig
make
###

The first make resulted in the error
make[1]: *** No rule to make target
'debian/certs/debian-uefi-certs.pem', needed by
'certs/x509_certificate_list'.  Stop

which I solved by following
https://stackoverflow.com/questions/67530734/no-rule-to-make-target-when-compiling-linux-kernel-when-needed-by-certs-x509-cer


Best regards,
Markus

On Thu, Jan 19, 2023 at 11:34 PM Salvatore Bonaccorso  wrote:
>
> Hi Markus,
>
> On Thu, Jan 19, 2023 at 10:21:35PM +0100, Markus Kramer wrote:
> > Hi Diederik,
> > Thank you for 
> > 0001-Revert-ASoC-soc-pcm-Don-t-zero-TDM-masks-in-__soc_pc.patch
> >
> > Following chapter 4.2.2 of
> > https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html
> >
> > $sudo apt-get install devscripts
> > Reading package lists... Done
> > Building dependency tree... Done
> > Reading state information... Done
> > devscripts is already the newest version (2.21.3+deb11u1).
> > 0 upgraded, 0 newly installed, 0 to remove and 67 not upgraded.
> >
> > Next step would be to execute
> >
> > bash debian/bin/test-patches
> > 0001-Revert-ASoC-soc-pcm-Don-t-zero-TDM-masks-in-__soc_pc.patch
> >
> > But there is no file test-patches on my client and googled in vain.
> > How can I procure test-patches?
>
> Just to be sure, have you performed the steps preceding 4.2.2 and
> fetched the source, in particular 4.2.1 pareparation? When you invoke
> apt-get source linux, you will get the source package, unpacked it,
> and changing with the next step into the source directory you will
> find below debian/bin/test-patches.
>
> Hope this helps,
>
> Regards,
> Salvatore



Bug#1029352: netcfg: broken ifupdown support for wireless interfaces

2023-01-22 Thread Pascal Hambourg

Hello,

On 21/01/2023 at 17:14, Cyril Brulebois wrote:


# Second issue

Once that's fixed, if one gets both DHCP+SLAAC, the generated /e/n/i
looks like this (± comments/newlines):

 allow-hotplug wlXXX

 iface wlXXX inet dhcp

 iface wlXXX inet6 auto
   wpa-ssid my-home-network
   wpa-psk  my-very-secret-passphrase

At best, we get SLAAC to work (IPv6 via RAs) but not DHCP: the first
iface stanza is missing wpa-* parameters, and we get a huge delay at
boot-up until dhclient finally times out.

(...)

→ ifupdown & wpa maintainers, comments welcome!


Comment from a simple user: I hate so say, but IMO ifupdown and/or 
/etc/network/interfaces format is broken by design. Stanzas mix link 
layer and network layer parameters and this causes various issues when 
you have several stanzas for the same interface. Link layer parameters 
should be applied once per interface regardless of the address family.



# Third issue

netcfg has some hotplug detection, which was last touched in 2005; it
tries to identify interfaces that are hotpluggable, and lists them under
/etc/network/devhotplug (in the installer's context), which is then used
to determine whether interfaces should be declared “auto” or
“allow-hotplug”. My rtl8192cu-based Wi-Fi USB dongle (shared from the
host via libvirt) ends up as “allow-hotplug”, which is problematic
because the module gets loaded after networking.service has returned,
failing to raise the wireless interface. Using “auto” makes ifupdown
wait a little more, and I'm getting my wireless interface configured.


That should not happen. After reading Alf's reply, I suspect a 
regression introduced in the latest bookwork ifupdown release:


   * networking.service: Add ExecStart=/sbin/ifup -a --allow=hotplug.
 Patch by "Oleg A. Arkhangelsky" 
 (Closes: #1022843)

According to the bug report, the patch also adds '--ignore-errors' so 
that ifup and networking.service return success even if hotplug 
interfaces are missing. I'm afraid it has a side effect: it also marks 
the interface as brought up, and when invoked by udev after the 
interface is created, ifup will not do anything.




Bug#902605: d-shlibs: d-devlibdeps design is based on an obsolete -dev package naming convention

2023-01-22 Thread Simon McVittie
On Thu, 28 Jun 2018 at 12:11:29 +0100, Simon McVittie wrote:
> Bugs like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901771
> indicate that d-devlibdeps is based on the assumption that the -dev
> package for libfoo.so.2 will be libfoo2-dev. However, that naming
> convention is discredited, and was specifically removed from Policy
> 4.0.0
...
> Since d-devlibdeps is based on an assumption that does not hold, it
> will need to grow an increasingly long list of exceptions to the naming
> convention that it assumes.

A few years later, d-devlibdeps has a list of 182 overrides.

I was curious how big a problem this was, so I picked 20 random lib*-dev
libraries from those visible to my laptop (which has unstable, testing,
stable and oldstable apt sources, so some of these could be obsolete
packages), excluding Rust because those are not shared libraries:

$ grep-aptavail -e '^lib.*-dev$' -FPackage -sPackage -n | grep -v 'librust-' | 
sort -u | shuf | head -n20
libboost-timer1.74-dev
libwxsqlite3-3.2-dev
libkf5gravatar-dev
liblitehtml-dev
libs3d-dev
libgnatprj10-dev
libitpp-dev
libxcb-dri2-0-dev
libcanberra-gtk3-dev
libweston-5-dev
libxmlrpc-core-c3-dev
libid3-3.8.3-dev
libxmlada-schema12-dev
libpolylib64-dev
libukui-powerclient-dev
libunwind-dev
libfriso-dev
libghc-heterocephalus-dev
libkmod-dev
libvc-dev

Of these 20 libraries, only libgnatprj10-dev, libxcb-dri2-0-dev and
*maybe* libxmlada-schema12-dev match d-devlibdeps' assumption (I couldn't
find a libxmlada-schema12 shared library so I'll give it the benefit of
the doubt). Needing an override for around 85% of libraries doesn't seem
like a favourable hit rate.

https://packages.debian.org/testing/libdevel/ says there are 5979
packages in the libdevel section, so if my sample is representative,
I would expect d-devlibdeps to need a list of about 5000 overrides to
produce correct results for all libraries. Even if we assume half of those
are rarely-used or false positives (for example static-only libraries),
that's still 1 order of magnitude more than it actually has.

As I had expected, most of the other -dev libraries in my sample seem
to be following the convention in Policy §8.4, so that linking with
something like -lvc or -lpolylib64 (resulting in a DT_NEEDED dependency
on libvc.so.0 or libpolylib64.so.8, represented in dpkg as Depends:
libvc0 or libpolylib64-8) is done via a -dev package named libvc-dev or
libpolylib64-dev, as opposed to the libvc0-dev and libpolylib64-8-dev
that d-devlibdeps assumes is normal.

smcv



Bug#1029448: Debian package for Alire 1.2.1

2023-01-22 Thread Ludovic Brenta
OK, after a little struggling I managed to build the package (notably,
g...@github.com:alire-project/alire.git requires permissions which I
don't have, used https://github.com/alire-project/alire.git).

During the build I noticed that alire pulls and recompiles several
libraries it depends on.  This violates Debian policy; a Debian package
must never duplicate another.  I notice gnatcoll and xmlezout among the
dependencies that are already packaged for Debian.  There may be others
I didn't see.

Therefore, please update the packaging of alire to build-depend on these
existing packages and not to recompile them from source.

I have filed bug #1029448 to track the introduction of alire into
Debian.  A Debian bug is also a dedicated, public mailing list: in this
case, 1029...@bugs.debian.org.

-- 
Ludovic Brenta.



  1   2   3   >