Bug#1002513: ITP: ppx-import -- OCaml extension to import declarations
Package: wnpp Owner: Julien Puydt X-Debbugs-Cc: Debian OCaml Maintainers Severity: wishlist * Package name: ppx-import Version : 1.8.0 Upstream Author : Peter Zotov * URL : https://github.com/ocaml-ppx/ppx_import * License : Expat Programming Lang: OCaml Description : OCaml extension to import declarations This package provides a ppx rewriter to import declarations from interface files. It's a dep for coq-serapi, which is a dep for alectryon, a collection of tools to process coq snippets embedded in text documents. Cheers, J.Puydt
Bug#941214: mutt zsh completion broken, -a does not take email address
martin f krafft writes: > Package: notmuch > Version: 0.29.1-2 > Severity: normal > File: /usr/share/zsh/vendor-completions/_email-notmuch > > mutt has a command-line switch '-a' for attachments, and the Zsh > completer offers files and directories for its argument. > > As of late, _email-notmuch also adds all addresses into the mix: > > % mutt -a ^D > directory > […] > file attachment > […] > email address (notmuch) > […] > > > In the context of '-a', no email addresses should be offered. Maybe > this is actually a problem with Zsh or Mutt, I can't figure it out. > But since I see mainly notmuch in the output, I am filing here… As far as I can tell, the whole point of _email-notmuch is to provide addresses, so maybe it shouldn't be called there? To me that suggests the bug should be reassigned to mutt. I am CCing the mutt maintainers, in case they want to weigh in. d
Bug#1002512: Please remove Build-Depends on r-cran-multicore
Package: r-other-mott-happy.hbrem Severity: normal I am currently cleaning up a little and removing a handful of r-cran-* packages that have vanished from CRAN years ago. One of those is 'multicore' which was subsumed in package 'parallel' which is part of base R. Package r-other-mott-happy.hbrem uses it -- and can in all likelihood just use 'parallel'. It would be kind if you could update it accordingly. Thanks, Dirk -- https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1002511: podget: maybe use ugrep as preferred alternative to grep
Source: podget Version: 0.8.10-1 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I notice that podget depends on grep. An alternative to grep, ugrep, should be radically faster and should support command-line options of GNU grep, so I encourage testing if it works as a drop-in replacement - with a speed gain. - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmHEkIYACgkQLHwxRsGg ASHoqQ//ZumsSqA1Kdhsi+j7ge1VEYvs/MA4A58JjkqNjp+cXX3UFakxjjL39Exk q9xZnP5CJUBl9xm1qODrrYYyAREOnlm7lw08InNOHNx2L0nAAXWWDqVdmzVuPiWs 3jeW2f3RfTcYUYP+sQvA5TezToDOQ+kleBftaw65OHAkfm6MYJUNnW70m2YRJlZ+ FlaASbTuD6GBv6rbgIBTsTEwSL+gyPkFLDXoRkB+DQvYwrwMdxOeRC/+rcuA0v/w l0yMqVxfKxlsL/JQpyZi20FJ6hSD8MZ4w/sp/shtdJQ/2nubLkXF7oerZBcNwRPc 3gKgsWItlzc2tJk6Md+D401aAxT/FrrBFUwvwBkelIeuDZsBxCXs37ItG/E47VDK Y0X4TlCvMewmlqkCl2SICcVG1ZuPTAvc6a3bOAbgjPIjFAmEI1pdNNWXMY+xNsTF YVKxKO2d4xtjT2uE+XwoXtSPiZpkkLHdfoI7CgucxN1vEB/QWEvVBgp/I2WQjz6V NScWRU19bN3CxJwFoozWG6YwyLmYy7RzOTGHCjpx3N0FhvqBdoMuYuqYjzNFfZfH vRNLSugcA6Fa9X9IdYVgDinCfn0XL0WCrDuwISUBH/Mf3cOoUMCbxMa2nMxI4Diz Vn/2ofy255rVK71n/LCg0+HhtJrQnE1nPrW8vwNImjTkBGd34cE= =e1PB -END PGP SIGNATURE-
Bug#1002510: RM: iem-plugin-suite [armel mipsel] -- ROM; FTBFS
Package: ftp.debian.org Severity: normal As reported in #1002500, JUCE no longer builds on "armel" and there are no plans to make it do so. As a consequence, projects depending on JUCE can no longer be built on "armel". For similar reasons JUCE no longer builds on "mipsel", many projects (including iem-plugin-suite) fail to build on "mipsel": the architecture does not provide means for working atomically with certain types (in this case: int64) cheers
Bug#1002509: misspell-fixer: maybe use ugrep as preferred alternative to grep
Package: misspell-fixer Version: 0.4-1 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I notice that misspell-fixer depends on grep. An alternative to grep, ugrep, should be radically faster and should support command-line options of GNU grep, so I encourage testing if it works as a drop-in replacement - with a speed gain. - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmHEkCYACgkQLHwxRsGg ASHAEg/8DO95SkL3Vxq4Zyq3ryrVputX9NXm6KYUB2Cjoa1yPb2b0zTzclOuZqOO ZkOkTTF/i0dCr7NasxMapL2ngRqABPwwPJZStl08OZkBwVNOC/VJzPS0MMPmC3tA qtVE0Jlb5Muh7r71qPTqIhx+PPjSI8tRWW0/DXvDK3boM80t30VGM3oEXSn0iJIy Z7E0z0QDPchcZd5cMQIDcMAso4P6zAeRqRBqmec9vBWf3b1GQ6Fl+hJw+WAsm4aS fkWWd9O8RM2w1ResEn5z3RXoHmdv8wHOHXmexzmiYevwNVfv15zasqEHUQZF9UII qxE+aexJBwe4emEWyH/79GhMajcvniCb67Lje5NBfyhOszCp8uNQoC9Ier+a6yWV khoGLqm04Do4nms05hmL6WsyeUPVgzykvRiuMKeW1MBsDn/sgmVGJHeDDlWSqfQF R/+bITjPy22vRicFWF/HxjOfrBzXQfkAdb/L2gD6prm8t40cmI/LnKi1vHXY+u7m RKVRSipe8I6G15PFBNuHEOuQdg/64quznme4HzCxxj2SPW0USM0hte0vaR8COUHe Zi3Y601CKI/fcGVV8ozMLQiLG1ZPZ/6TiRMQxVIrBA0BIH+WwdXY4XCUfJe11izH tspCo4B+vbRITECpg+5PhqhdrIM9HbFRE03LpacgBYXXco+rcLA= =GNya -END PGP SIGNATURE-
Bug#920148: RFP: mapillary-tools -- Useful tools and scripts related to Mapillary
[cc:ing debian-python in case anyone happens to know enough about
python3-contruct to provide some clues]
OK, so it turns out that there are problems packaging pymp4.
It depends on construct, a (nice) library for parsing binary
formats. However said library seems to have little interest in
maintaining any sort of stable API so there have been significant
changes between 2.8, 2.9 and 2.10 (and in fact pymp4 needs 2.8.8 quite
specifically, and doesn't even work with 2.8.16).
2.8.8 is from October 2016 and Debian now has 2.10.x in stable, testing and
unstable.
There is a bug in construct 2.8.8 which means that pymp4 fails 5 out of 30-odd
tests even with that.
A python class moved, so that is trivially fixed with:
--- construct-2.8.8.orig/construct/core.py
+++ construct-2.8.8/construct/core.py
@@ -997,7 +997,7 @@ class Range(Subconstruct):
max = self.max(context) if callable(self.max) else self.max
if not 0 <= min <= max <= sys.maxsize:
raise RangeError("unsane min %s and max %s" % (min, max))
-if not isinstance(obj, collections.Sequence):
+if not isinstance(obj, collections.abc.Sequence):
raise RangeError("expected sequence type, found %s" % type(obj))
if not min <= len(obj) <= max:
raise RangeError("expected from %d to %d elements, found %d" %
(min, max, len(obj)))
But as no-one cares about 2.8.x anyway this fix doesn't help much.
What's really needed is updating pymp4 to use construct 2.10 (or
switch to a more stable library if such a thing exists ('Kaitai
Struct' was mentioned)).
There is an upstream issue for this:
https://github.com/beardypig/pymp4/issues/3
Which I've just added some info to.
2.9 changes the way Strings work: an encoding is always required, and
explicit flavours of padding (left/right, specifiable padding char)
have been removed. pymp4 uses these padding options (specifying spaces
and right-padding), but may still work fine with the remaining default
behaviour of 'PaddedString' (nulls and rightpading). I don't know
enough about either the MP4 format or the codebase to be sure. I did
know up a patch to update to the new string API.
2.9 also loses Embedded bitwise structs. And 2.10 loses 'Embedded' completely.
I have not really managed to work out exactly what 'Embedded' does. I
can't really work out what the difference between putting a bitwise
struct in the middle of a struct and putting an Embedded bitwise
struct in the middle of a struct is. Mostly this is because the online
docs only cover 2.10, not 2.8 so I don't know what the old definition
was. I spent a couple of hours trying to work it out. It's made more
complicated by the fact that construct also switched from 'bits by
default' to 'bytes by default' for efficiency reasons.
I've put a half-arsed patch in the github issue which is probably OK
for the strings part and almost certainly wrong for the Embedded
part. So example I have no idea how to deal with this which selects
one struct depending on a string:
Box = PrefixedIncludingSize(Int32ub, Struct(
"offset" / TellMinusSizeOf(Int32ub),
"type" / Peek(String(4, padchar=b" ", paddir="right")),
Embedded(Switch(this.type, {
b"ftyp": FileTypeBox,
b"styp": SegmentTypeBox,
b"mvhd": MovieHeaderBox,
b"moov": ContainerBoxLazy,
...
b'afrt': HDSFragmentRunBox
}, default=RawBox)),
"end" / Tell
))
changing
-"type" / Peek(String(4, padchar=b" ", paddir="right")),
to
+"type" / Peek(PaddedString(4,"ascii")),
is probably equivalent, but what is the equivalent syntax for choosing
the right struct for the 'type' field according to the 1st 4 bytes of
it, without using 'Embedded'? This was where I decided it was bedtime
and admitted defeat for the time being.
If someone familiar with construct 2.8 to 2.10 upgrades wanted to take
a look at this that would be very helpful. For some things we might
need to know something about the mp4 format too. I'm not sure to what
degree we need to understand the format, or if we can more or less
mechanically update the syntax.
So, for now there is no mapillary-tools in Debian, and without a
response from upstream or some help I'm stuck.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
Bug#931113: cflow: wierd Info node with emacs
Control: tags 931113 confirmed fixed-upstream patch pending upstream Hi Dmitry! First, thanks for your report! I talked with the upstream and he gently fixed this in the commit: https://git.savannah.gnu.org/cgit/cflow.git/commit/?id=7aa2a89af63849736df6a230927d54cf25e3bf51 The fix will be part of the incoming release. Cheers, mt signature.asc Description: PGP signature
Bug#1002508: readline: Please provide a udeb
Source: readline
Version: 8.1-2
Severity: normal
Tags: d-i a11y patch
Hello,
So as to provide better support for the text installer for speakup-based
accessibility, we need libreadline in d-i. Here is a patch to add the
udeb build, could you apply it?
Thanks,
Samuel
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500,
'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'),
(500, 'proposed-updates'), (500, 'oldstable-proposed-updates-debug'), (500,
'oldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'),
(500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1,
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.15.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--
Samuel
mdiym42: note to self
mdiym42: make sure your cat is not sleeping in the bass drum before you start
playing them
--- debian/control.original 2021-12-23 14:14:29.494489058 +0100
+++ debian/control 2021-12-23 15:03:01.596025090 +0100
@@ -23,6 +23,21 @@
The GNU history library provides a consistent user interface for
recalling lines of previously typed input.
+Package: libreadline8-udeb
+Architecture: any
+Depends: readline-common-udeb, ${shlibs:Depends}, ${misc:Depends}
+Pre-Depends: ${misc:Pre-Depends}
+Package-Type: udeb
+Build-Profiles:
+Section: debian-installer
+Description: GNU readline and history libraries, run-time libraries (d-i)
+ The GNU readline library aids in the consistency of user interface
+ across discrete programs that need to provide a command line
+ interface.
+ .
+ The GNU history library provides a consistent user interface for
+ recalling lines of previously typed input.
+
Package: lib64readline8
Architecture: i386 powerpc s390 sparc
Depends: readline-common, ${shlibs:Depends}, ${misc:Depends}
@@ -47,6 +62,21 @@
The GNU readline library aids in the consistency of user interface
across discrete programs that need to provide a command line
interface.
+ .
+ The GNU history library provides a consistent user interface for
+ recalling lines of previously typed input.
+
+Package: readline-common-udeb
+Architecture: all
+Multi-Arch: foreign
+Depends: ${misc:Depends}
+Package-Type: udeb
+Build-Profiles:
+Section: debian-installer
+Description: GNU readline and history libraries, common files (d-i)
+ The GNU readline library aids in the consistency of user interface
+ across discrete programs that need to provide a command line
+ interface.
.
The GNU history library provides a consistent user interface for
recalling lines of previously typed input.
--- debian/rules.original 2021-12-23 14:14:33.018490312 +0100
+++ debian/rules2021-12-23 15:08:20.460279596 +0100
@@ -17,6 +17,10 @@
CROSS=gcc
endif
+ifeq (,$(filter noudeb,$(DEB_BUILD_PROFILES)))
+ buildudeb = yes
+endif
+
ifneq (,$(findstring /$(DEB_HOST_ARCH)/,/i386/powerpc/sparc/s390/))
build64 = yes
CC64 = $(CROSS) -m64
@@ -69,9 +73,11 @@
SHELL = bash
p_rl = libreadline$(soversion)
+p_rlu = libreadline$(soversion)-udeb
p_rl32 = lib32readline$(soversion)
p_rl64 = lib64readline$(soversion)
p_comm = readline-common
+p_commu= readline-common-udeb
p_rld = libreadline-dev
p_rld32= lib32readline-dev
p_rld64= lib64readline-dev
@@ -79,12 +85,15 @@
p_rlfe = rlfe
d = debian/tmp
+du = debian/tmp-udeb
d32= debian/tmp32
d64= debian/tmp64
d_rl = debian/$(p_rl)
+d_rlu = debian/$(p_rlu)
d_rl32 = debian/$(p_rl32)
d_rl64 = debian/$(p_rl64)
d_comm = debian/$(p_comm)
+d_commu= debian/$(p_commu)
d_rld = debian/$(p_rld)
d_rld32= debian/$(p_rld32)
d_rld64= debian/$(p_rld64)
@@ -93,6 +102,7 @@
srcdir = $(CURDIR)
builddir = $(CURDIR)/build
+builddiru = $(CURDIR)/buildudeb
builddir32 = $(CURDIR)/build32
builddir64 = $(CURDIR)/build64
@@ -111,6 +121,16 @@
--host=$(DEB_HOST_GNU_TYPE) \
--libdir=/usr/lib/$(DEB_HOST_MULTIARCH)
+ifneq ($(buildudeb),)
+ rm -rf $(builddiru)
+ mkdir $(builddiru)
+ cd $(builddiru) && \
+ CFLAGS="$(CFLAGS) -Os" CPPFLAGS="$(CPPFLAGS)" $(srcdir)/configure \
+ --prefix=/usr\
+ --host=$(DEB_HOST_GNU_TYPE) \
+ --libdir=/usr/lib/$(DEB_HOST_MULTIARCH)
+endif
+
ifneq ($(build32),)
rm -rf $(builddir32)
mkdir $(builddir32)
@@ -141,6 +161,14 @@
SHOBJ_LDFLAGS='$(LDFLAGS) -shared' \
SHLIB_LIBS="-ltinfo"
+ifneq ($(buildudeb),)
+ $(MAKE) -C $(builddiru) \
+
Bug#1002460: linux-image-amd64: Missing kernel configuration for Microsoft Laptops and Surface devices
Hi, On Thu, Dec 23, 2021 at 02:37:50PM +0100, Maximilian Luz wrote: > On Wed, 22 Dec 2021 23:47:10 +0100 Vincent Blut > wrote: > > Le 2021-12-22 14:07, Matthias Brennwald a écrit : > > > Full details (including a suggested fix) are available here: > > > https://github.com/linux-surface/linux-surface/issues/683 > > > > I need a clarification about CONFIG_SURFACE_AGGREGATOR_CDEV. This > > options' help text mentions that it is intended for debugging and > > development only, and should not be used otherwise. Is it really needed? > > It's not needed for normal support, no. It's quite useful for debugging > and adding support for new devices, though. > > You can compare it a bit with USB Raw Gadget or HIDRAW (except that we > don't want anyone writing user-space drivers against that interface), > i.e. it provides a direct channel from user-space to the EC. Setting > this option to M provides a module that needs to be loaded in explicitly > when someone wants to use it. > > I've added it to the list because other distros (Ubuntu, Arch) have > enabled it. Feel free to keep it disabled. Thank you. I have merged Vincent's MR (keeping for now the other discussion option disabled), and it will be in the next 5.16.y upload. Regards, Salvatore
Bug#1002460: linux-image-amd64: Missing kernel configuration for Microsoft Laptops and Surface devices
On Wed, 22 Dec 2021 23:47:10 +0100 Vincent Blut wrote: Le 2021-12-22 14:07, Matthias Brennwald a écrit : > Full details (including a suggested fix) are available here: > https://github.com/linux-surface/linux-surface/issues/683 I need a clarification about CONFIG_SURFACE_AGGREGATOR_CDEV. This options' help text mentions that it is intended for debugging and development only, and should not be used otherwise. Is it really needed? It's not needed for normal support, no. It's quite useful for debugging and adding support for new devices, though. You can compare it a bit with USB Raw Gadget or HIDRAW (except that we don't want anyone writing user-space drivers against that interface), i.e. it provides a direct channel from user-space to the EC. Setting this option to M provides a module that needs to be loaded in explicitly when someone wants to use it. I've added it to the list because other distros (Ubuntu, Arch) have enabled it. Feel free to keep it disabled. Regards, Max
Bug#978149: ITP: pyenv -- Simple Python version management
On Wed, Dec 22, 2021 at 07:22:54PM +0530, karthek wrote: > On Wed, Dec 22, 2021, 6:03 PM Julian Gilbey wrote: > > That makes sense, then. Good luck packaging this! > > Thanks. > I need a sponser though Good luck! I'm afraid I can't take it on though - I'm too overloaded already. Best wishes, Julian
Bug#1002507: RM: giada [armel mipsel] -- ROM; FTBFS
Package: ftp.debian.org Severity: normal As reported in #1002500, JUCE no longer builds on "armel" and there are no plans to make it do so. As a consequence, projects depending on JUCE can no longer be built on "armel". For similar reasons JUCE no longer builds on "mipsel", many projects (including giada) fail to build on "mipsel": the architecture does not provide means for working atomically with certain types (in this case: int64) cheers
Bug#1002506: Sage crash report
--
Jean-Paul Vincent
***
IPython post-mortem report
{'commit_hash': '',
'commit_source': '(none found)',
'default_encoding': 'utf-8',
'ipython_path': '/usr/lib/python3/dist-packages/IPython',
'ipython_version': '7.27.0',
'os_name': 'posix',
'platform': 'Linux-5.15.0-2-amd64-x86_64-with-glibc2.33',
'sys_executable': '/usr/bin/python3',
'sys_platform': 'linux',
'sys_version': '3.9.9 (main, Dec 16 2021, 23:13:29) \n[GCC 11.2.0]'}
***
***
Crash traceback:
--
--
ImportError Python 3.9.9: /usr/bin/python3
Thu Dec 23 12:51:59 2021
A problem occurred executing Python code. Here is the sequence of function
calls leading up to the error, with the most recent (innermost) call last.
/usr/share/sagemath/bin/sage-ipython in
1 #!/usr/bin/env sage-python
2 # -*- coding: utf-8 -*-
3 """
4 Sage IPython startup script.
5 """
6
7 # Display startup banner. Do this before anything else to give the user
8 # early feedback that Sage is starting.
9 from sage.misc.banner import banner
10 banner()
11
12 from sage.repl.interpreter import SageTerminalApp
13
14 app = SageTerminalApp.instance()
---> 15 app.initialize()
global app.initialize = >
16 app.start()
/usr/lib/python3/dist-packages/traitlets/config/application.py in
inner(app=, *args=(), **kwargs={})
73 else:
74 raise ValueError("Unsupported value for environment variable:
'TRAITLETS_APPLICATION_RAISE_CONFIG_FILE_ERROR' is set to '%s' which is none of
{'0', '1', 'false', 'true', ''}."% _envvar )
75
76
77 def catch_config_error(method):
78 """Method decorator for catching invalid config
(Trait/ArgumentErrors) during init.
79
80 On a TraitError (generally caused by bad config), this will print
the trait's
81 message, and exit the app.
82
83 For use on init methods, to prevent invoking excepthook on invalid
input.
84 """
85 @functools.wraps(method)
86 def inner(app, *args, **kwargs):
87 try:
---> 88 return method(app, *args, **kwargs)
global method = undefined
app =
args = ()
kwargs = {}
89 except (TraitError, ArgumentError) as e:
90 app.log.fatal("Bad config encountered during
initialization: %s", e)
91 app.log.debug("Config at the time: %s", app.config)
92 app.exit(1)
93
94 return inner
95
96 class ApplicationError(Exception):
97 pass
98
99
100 class LevelFormatter(logging.Formatter):
101 """Formatter with additional `highlevel` record
102
103 This field is empty if log level is less than highlevel_limit,
/usr/lib/python3/dist-packages/IPython/terminal/ipapp.py in
initialize(self=, argv=None)
302
303 return super(TerminalIPythonApp, self).parse_command_line(argv)
304
305 @catch_config_error
306 def initialize(self, argv=None):
307 """Do actions after construct, but before starting the app."""
308 super(TerminalIPythonApp, self).initialize(argv)
309 if self.subapp is not None:
310 # don't bother initializing further, starting subapp
311 return
312 # print self.extra_args
313 if self.extra_args and not self.something_to_run:
314 self.file_to_run = self.extra_args[0]
315 self.init_path()
316 # create the shell
--> 317 self.init_shell()
self.init_shell = >
318 # and draw the banner
319 self.init_banner()
320 # Now a variety of things that happen after the banner is
printed.
321 self.init_gui_pylab()
322 self.init_extensions()
323 self.init_code()
324
325 def init_shell(self):
326 """initialize the InteractiveShell instance"""
327 # Create an InteractiveShell instance.
328 # shell.display_banner should always be False for the terminal
329 # based app, because we call shell.show_banner() by hand below
330 # so the banner shows *before* all extension loading stuff.
331 self.shell = self.interactive_shell_class.instance(parent=self,
332 profile_dir=self.profile_dir,
/usr/lib/python3/dist-packages/sage/repl/interpreter.py in
init_shell(self=)
776
Bug#1002506: sagemath: sage dont start with ImportError in matrix_space.py
Package: sagemath Version: 9.2-2 Severity: important Tags: a11y Dear Maintainer, Sage is unusable for me at least and crash with a report log. I dont used it for weeks, so I cant say when this began. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (900, 'testing'), (800, 'unstable'), (200, 'stable'), (100, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.15.0-2-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages sagemath depends on: ii curl 7.79.1-2 ii cysignals-tools 1.11.2+ds-1 ii cython3 0.29.24-1+b1 ii ecl 21.2.1+ds-1 ii eclib-tools 20210625-1+b2 ii fflas-ffpack 2.5.0-1 ii flintqs 1:1.0-3+b1 ii gap-atlasrep 2.1.0-3 ii gap-dev 4.11.1-1 ii gap-online-help 4.11.1-1 ii gap-primgrp 3.4.0-1 ii gap-smallgrp 1.4.1-2 ii gap-table-of-marks1.2.9-1 ii gap-transgrp 2.0.6-2 ii gfan 0.6.2-6 ii glpk-utils5.0-1 ii gmp-ecm 7.0.4+ds-6 ii ipython3 7.27.0-1 ii iso-codes 4.8.0-1 ii jmol 14.32.3+dfsg1-1 ii lcalc 2.0.4-2 ii less 551-2 ii libatlas3-base [libblas.so.3] 3.10.3-11 ii libblas3 [libblas.so.3] 3.10.0-2 ii libbraiding0 1.0-1+b1 ii libbrial-groebner31.2.10-1+b2 ii libbrial3 1.2.10-1+b2 ii libc6 2.33-1 ii libcdd-tools 094l-2 ii libcliquer1 1.21-3 ii libec520190909-3+b1 ii libecm1 7.0.4+ds-6 ii libflint-2.6.32.6.3-3 ii libflint-arb2 1:2.21.1-2 ii libgap7 4.11.1-1 ii libgcc-s1 11.2.0-12 ii libgd32.3.0-2 ii libgiac0 1.7.0.39+dfsg2-1 ii libgivaro94.2.0-1 ii libglpk40 5.0-1 ii libgmp10 2:6.2.1+dfsg-3 ii libgmpxx4ldbl 2:6.2.1+dfsg-3 ii libgomp1 11.2.0-12 ii libgsl25 2.6+dfsg-2 ii libhomfly01.02r6-1 ii libiml0 1.0.5-1 ii libjs-mathjax 2.7.9+dfsg-1 ii libjs-three 111+dfsg1-2 ii liblfunction0 1.23+dfsg-11+b1 ii liblrcalc11.2-2+b1 ii libm4ri-0.0.20200125 20200125-1+b1 ii libm4rie-0.0.20200125 20200125-1+b2 ii libmpc3 1.2.1-1 ii libmpfi0 1.5.3+ds-6 ii libmpfr6 4.1.0-3 ii libntl43 11.4.3-1+b1 ii libopenblas0 0.3.18+ds-2 ii libopenblas0-pthread [libblas.so.3] 0.3.18+ds-2 ii libpari-gmp-tls7 2.13.3-1 ii libplanarity0 3.0.1.1-1 ii libpynac18py3 0.7.29-2 ii libratpoints-2.1.31:2.1.3-2 ii libreadline8 8.1-2 ii librw00.9+ds1-1 ii libsingular4m11:4.1.1-p2+ds-4+b3 ii libstdc++611.2.0-12 ii libsymmetrica2
Bug#1002505: gcc internal compiler error related to VLAs
Package: gcc-11 Version: 11.2.0-12 GCC 11 crashes on armel und s390x for certain code involving VLAs. Same code builds with older GCC: https://buildd.debian.org/status/package.php?p=bart-view This may also be related to a build failure on i386 for a different package: https://salsa.debian.org/med-team/bart/-/jobs/2121098 I recently filed an upstream bug for a problem which may also be related (but affects x86_64): https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103770 Best, Martin
Bug#1002504: php-swiftmailer: Failing testsuite with PHP 8.1
Package: php-swiftmailer Version: 6.2.4-1 Severity: important Control: block 976811 by -1 Hi, The testsuite is currently failing with PHP 8: […] There were 2 failures: 1) Swift_MessageTest::testCloning Property `�Swift_Mime_SimpleHeaderFactory�addressEncoder` cloning error: source and cloned objects property is referencing same object Failed asserting that true is false. /tmp/autopkgtest-lxc.c__nkzh0/downtmp/build.MVM/src/tests/unit/Swift/MessageTest.php:78 /tmp/autopkgtest-lxc.c__nkzh0/downtmp/build.MVM/src/tests/unit/Swift/MessageTest.php:89 /tmp/autopkgtest-lxc.c__nkzh0/downtmp/build.MVM/src/tests/unit/Swift/MessageTest.php:89 /tmp/autopkgtest-lxc.c__nkzh0/downtmp/build.MVM/src/tests/unit/Swift/MessageTest.php:11 2) Swift_MessageTest::testCloningWithSigners Property `�Swift_Mime_SimpleHeaderFactory�addressEncoder` cloning error: source and cloned objects property is referencing same object Failed asserting that true is false. /tmp/autopkgtest-lxc.c__nkzh0/downtmp/build.MVM/src/tests/unit/Swift/MessageTest.php:78 /tmp/autopkgtest-lxc.c__nkzh0/downtmp/build.MVM/src/tests/unit/Swift/MessageTest.php:89 /tmp/autopkgtest-lxc.c__nkzh0/downtmp/build.MVM/src/tests/unit/Swift/MessageTest.php:89 /tmp/autopkgtest-lxc.c__nkzh0/downtmp/build.MVM/src/tests/unit/Swift/MessageTest.php:26 -- signature.asc Description: PGP signature
Bug#1002082: mpi4py: FTBFS: testJoin socket.gaierror: Name or service not known
Source: mpi4py Followup-For: Bug #1002082 Control: tags -1 moreinfo What's strange is that your error log says it failed only on one process, ok ok testJoin (test_dynproc.TestDPM) ... testJoin (test_dynproc.TestDPM) ... testJoin (test_dynproc.TestDPM) ... testJoin (test_dynproc.TestDPM) ... ok testJoin (test_dynproc.TestDPM) ... ERROR The others seem to be returning ok. Maybe this was just a passing glitch on the test system? Reproducibility tests are still running fine, https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/mpi4py.html Can you reproduce the build error?
Bug#1002503: false reports skip-systemd-native-flag-missing-pre-depends
Control: reopen -1 Control: retitle -1 lintian: Clarify all tags about missing Pre-Depends Hi Marc, On Thu, Dec 23, 2021 at 3:57 AM Marc Haber wrote: > > No, a false bug report. Sorry. Confusing tag descriptions are also bugs in Lintian! We strive to please all. Note for later: This is about Depends vs Pre-Depends. Kind regards Felix Lechner
Bug#984401: vtk7: diff for NMU version 7.1.1+dfsg2-10.1
Dear maintainer,
I've prepared an NMU for vtk7 (versioned as 7.1.1+dfsg2-10.1). The diff
is attached to this message.
Cheers
--
Sebastian Ramacher
diff -Nru vtk7-7.1.1+dfsg2/debian/changelog vtk7-7.1.1+dfsg2/debian/changelog
--- vtk7-7.1.1+dfsg2/debian/changelog 2021-03-03 21:36:23.0 +0100
+++ vtk7-7.1.1+dfsg2/debian/changelog 2021-12-23 10:00:11.0 +0100
@@ -1,3 +1,12 @@
+vtk7 (7.1.1+dfsg2-10.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+
+ [ Steve Langasek ]
+ * Fix build with GCC 11 (Closes: #984401)
+
+ -- Sebastian Ramacher Thu, 23 Dec 2021 10:00:11 +0100
+
vtk7 (7.1.1+dfsg2-10) unstable; urgency=medium
* Team Upload
diff -Nru vtk7-7.1.1+dfsg2/debian/patches/gcc-11.patch vtk7-7.1.1+dfsg2/debian/patches/gcc-11.patch
--- vtk7-7.1.1+dfsg2/debian/patches/gcc-11.patch 1970-01-01 01:00:00.0 +0100
+++ vtk7-7.1.1+dfsg2/debian/patches/gcc-11.patch 2021-12-23 09:59:32.0 +0100
@@ -0,0 +1,53 @@
+Description: gcc-11 compatibility
+Author: Steve Langasek
+Bug-Debian: https://bugs.debian.org/984401
+Last-Update: 2021-11-18
+
+Index: vtk7-7.1.1+dfsg2/ThirdParty/xdmf2/vtkxdmf2/libsrc/XdmfDsmComm.cxx
+===
+--- vtk7-7.1.1+dfsg2.orig/ThirdParty/xdmf2/vtkxdmf2/libsrc/XdmfDsmComm.cxx
vtk7-7.1.1+dfsg2/ThirdParty/xdmf2/vtkxdmf2/libsrc/XdmfDsmComm.cxx
+@@ -52,7 +52,7 @@
+ XdmfErrorMessage("Cannot Receive Message of Length = " << Msg->Length);
+ return(XDMF_FAIL);
+ }
+-if(Msg->Data <= 0 ){
++if(!Msg->Data){
+ XdmfErrorMessage("Cannot Receive Message into Data Buffer = " << Msg->Length);
+ return(XDMF_FAIL);
+ }
+@@ -66,7 +66,7 @@
+ XdmfErrorMessage("Cannot Send Message of Length = " << Msg->Length);
+ return(XDMF_FAIL);
+ }
+-if(Msg->Data <= 0 ){
++if(!Msg->Data){
+ XdmfErrorMessage("Cannot Send Message from Data Buffer = " << Msg->Length);
+ return(XDMF_FAIL);
+ }
+Index: vtk7-7.1.1+dfsg2/Rendering/Label/vtkLabelHierarchyPrivate.h
+===
+--- vtk7-7.1.1+dfsg2.orig/Rendering/Label/vtkLabelHierarchyPrivate.h
vtk7-7.1.1+dfsg2/Rendering/Label/vtkLabelHierarchyPrivate.h
+@@ -66,7 +66,7 @@
+ {
+ }
+
+-bool operator () ( const vtkIdType& a, const vtkIdType& b )
++bool operator () ( const vtkIdType& a, const vtkIdType& b ) const
+ {
+ if (0 == this->Hierarchy)
+ {
+Index: vtk7-7.1.1+dfsg2/Rendering/Label/vtkLabelHierarchy.cxx
+===
+--- vtk7-7.1.1+dfsg2.orig/Rendering/Label/vtkLabelHierarchy.cxx
vtk7-7.1.1+dfsg2/Rendering/Label/vtkLabelHierarchy.cxx
+@@ -525,7 +525,7 @@
+ {
+ public:
+ bool operator()(const vtkHierarchyNode & a,
+-const vtkHierarchyNode & b)
++const vtkHierarchyNode & b) const
+ {
+ if (a.Level != b.Level)
+ {
diff -Nru vtk7-7.1.1+dfsg2/debian/patches/series vtk7-7.1.1+dfsg2/debian/patches/series
--- vtk7-7.1.1+dfsg2/debian/patches/series 2020-12-15 20:51:51.0 +0100
+++ vtk7-7.1.1+dfsg2/debian/patches/series 2021-12-23 09:59:32.0 +0100
@@ -23,3 +23,4 @@
mysq8_my_bool.patch
3edc0de2b04ae1e100c229e592d6b9fa94f2915a.patch
581d9eb874b2b80a3fb21c739a96fa6f955ffb5e.patch
+gcc-11.patch
signature.asc
Description: PGP signature
Bug#1002503: false reports skip-systemd-native-flag-missing-pre-depends
Hi Marc, On Thu, Dec 23, 2021 at 3:57 AM Marc Haber wrote: > > Depends: [...] init-system-helpers (>= 1.54~) The tag is asking for Pre-Depends though, isn't it? [1][2] > ippl_1.4.14-12.2_amd64.deb I do not see a declaration for Pre-Depends in your control file. [3] Is Lintian too strict? Kind regards Felix Lechner [1] https://lintian.debian.org/tags/skip-systemd-native-flag-missing-pre-depends [2] https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Check/Systemd/Native/Prerequisites.pm#L49 [3] https://tracker.debian.org/media/packages/i/ippl/control-1.4.14-12.2
Bug#919052: python-pbcore: some docs for pbcore are not found
Hi, despite I changed the call to create the docs from $(MAKE) doc to PYTHONPATH=$(shell pybuild --print build_dir --interpreter python3) $(MAKE) doc (OK, I appended '|| true' to get the package built) the doc creation is not properly done as you can see in Salsa CI[1]: ... WARNING: autodoc: failed to import module 'chemistry.chemistry' from module 'pbcore'; the following exception was raised: Traceback (most recent call last): File "/usr/lib/python3/dist-packages/sphinx/ext/autodoc/importer.py", line 70, in import_module return importlib.import_module(modname) File "/usr/lib/python3.9/importlib/__init__.py", line 127, in import_module return _bootstrap._gcd_import(name[level:], package, level) File "", line 1030, in _gcd_import File "", line 1007, in _find_and_load File "", line 986, in _find_and_load_unlocked File "", line 680, in _load_unlocked File "", line 850, in exec_module File "", line 228, in _call_with_frames_removed File "/builds/med-team/python-pbcore/debian/output/source_dir/.pybuild/cpython3_3.9_pbcore/build/pbcore/chemistry/__init__.py", line 1, in from .chemistry import * File "/builds/med-team/python-pbcore/debian/output/source_dir/.pybuild/cpython3_3.9_pbcore/build/pbcore/chemistry/chemistry.py", line 51, in _BARCODE_MAPPINGS = _loadBarcodeMappings() File "/builds/med-team/python-pbcore/debian/output/source_dir/.pybuild/cpython3_3.9_pbcore/build/pbcore/chemistry/chemistry.py", line 37, in _loadBarcodeMappings mappingFname = resource_filename(Requirement.parse( File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 1135, in resource_filename return get_provider(package_or_requirement).get_resource_filename( File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 347, in get_provider return working_set.find(moduleOrReq) or require(str(moduleOrReq))[0] File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 891, in require needed = self.resolve(parse_requirements(requirements)) File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 777, in resolve raise DistributionNotFound(req, requirers) pkg_resources.DistributionNotFound: The 'pbcore' distribution was not found and is required by the application WARNING: autodoc: failed to import module 'chemistry' from module 'pbcore'; the following exception was raised: I can confirm if I install the package I can easily import pbcore.chemistry.chemistry so something is wrong when seeking the proper Python3 module at doc time creation. Any hint would be welcome. Kind regards Andreas. [1] https://salsa.debian.org/med-team/python-pbcore/-/jobs/2304143#L1657 -- http://fam-tille.de
Bug#1000172: upstream issue fixed
I reported the bug upstream at gnome-shell: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4883 Upstream bug solved with merge-request: https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2072 https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2074
Bug#1001981: [Pkg-privacy-maintainers] Bug#1001981: onioncircuits: Doesn't start: Permission denied: '/usr/local/lib/python3.9/dist-packages/usb-0.0.83.dev0.dist-info'
Hi Richard, thanks for your report. Let's see what I can do. > clicking then launcher results in no visible action. This is just in bullseye? Unfortunately I can't reproduce this, onioncircuits opens fine for me. > Starting from shell > results in this: > > rz@rz-debian:~$ onioncircuits > PermissionError: [Errno 13] Permission denied: '/usr/local/lib/python3.9/dist- > packages/usb-0.0.83.dev0.dist-info' This is quite suspicious. There should no Python code installed by Debian packages in /usr/local [1]. It looks like something installed alongside the Debian-provided Python modules is interfering with operation of the pycountry module, which is a dependency of onioncircuits. Did you install any Python packages system-wide using pip or other means other than Debian packaging, maybe even using sudo? This may leave files around with permissions not including the rz user. Can you please try uninstalling these files in /usr/local/lib/python3.9/dist-packages and try again? Thanks! Cheers Sascha [1] See Policy 9.1.2: https://www.debian.org/doc/debian-policy/ch-opersys.html#site-specific-programs
Bug#1002503: false reports skip-systemd-native-flag-missing-pre-depends
Package: lintian Version: 2.114.0 Severity: normal Hi, [208/5813]mh@drop:~/packages/ippl/build-area $ lintian ippl_1.4.14-12.2_amd64.deb W: ippl: missing-systemd-service-for-init.d-script ippl [etc/init.d/ippl] W: ippl: skip-systemd-native-flag-missing-pre-depends (does not satisfy init-system-helpers (>= 1.54~)) [postinst:19] W: ippl: skip-systemd-native-flag-missing-pre-depends (does not satisfy init-system-helpers (>= 1.54~)) [prerm:5] [209/5814]mh@drop:~/packages/ippl/build-area $ However, the Dependency IS there in the source and the binary package: [209/5814]mh@drop:~/packages/ippl/build-area $ dpkg --ctrl-tarfile ippl_1.4.14-12.2_amd64.deb | tar --extract --to-stdout ./control | grep Depends Depends: adduser (>> 3.51), logrotate, lsb-base (>= 3.0-6), init-system-helpers (>= 1.54~), libc6 (>= 2.32) [210/5815]mh@drop:~/packages/ippl/build-area $ I think that's a false warning. Greetings Marc -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.10-zgws1 (SMP w/4 CPU threads) Kernel taint flags: TAINT_DIE, TAINT_OOT_MODULE Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages lintian depends on: ii binutils2.37-10 ii bzip2 1.0.8-5 ii diffstat1.64-1 ii dpkg1.21.1 ii dpkg-dev1.21.1 ii file1:5.41-2 ii gettext 0.21-4 ii gpg 2.2.27-3 ii intltool-debian 0.35.0+20060710.5 ii libapt-pkg-perl 0.1.40 ii libarchive-zip-perl 1.68-1 ii libcapture-tiny-perl0.48-1 ii libclass-xsaccessor-perl1.19-3+b7 ii libclone-perl 0.45-1+b1 ii libconfig-tiny-perl 2.27-1 ii libconst-fast-perl 0.014-1.1 ii libcpanel-json-xs-perl 4.27-1 ii libdata-dpath-perl 0.58-1 ii libdata-validate-domain-perl0.10-1.1 ii libdata-validate-uri-perl 0.07-1 ii libdevel-size-perl 0.83-1+b2 pn libdigest-sha-perl ii libdpkg-perl1.21.1 ii libemail-address-xs-perl1.04-1+b3 ii libfile-basedir-perl0.09-1 ii libfile-find-rule-perl 0.34-1 ii libfont-ttf-perl1.06-1.1 ii libhtml-html5-entities-perl 0.004-1.1 ii libio-interactive-perl 1.023-1 ii libio-prompt-tiny-perl 0.003-1 ii libipc-run3-perl0.048-2 ii libjson-maybexs-perl1.004003-1 ii liblist-compare-perl0.55-1 ii liblist-someutils-perl 0.58-1 ii liblist-utilsby-perl0.11-1 ii libmoo-perl 2.005004-3 ii libmoox-aliases-perl0.001006-1.1 ii libnamespace-clean-perl 0.27-1 ii libpath-tiny-perl 0.120-1 ii libperlio-gzip-perl 0.19-1+b7 ii libperlio-utf8-strict-perl 0.008-1+b1 ii libproc-processtable-perl 0.634-1 ii libsereal-decoder-perl 4.018+ds-1+b1 ii libsereal-encoder-perl 4.018+ds-1+b1 ii libsort-versions-perl 1.62-1 ii libsyntax-keyword-try-perl 0.26-1 ii libterm-readkey-perl2.38-1+b2 ii libtext-glob-perl 0.11-2 ii libtext-levenshteinxs-perl 0.03-4+b8 ii libtext-markdown-discount-perl 0.13-1 ii libtext-xslate-perl 3.5.9-1 ii libtime-duration-perl 1.21-1 ii libtime-moment-perl 0.44-1+b3 ii libtimedate-perl2.3300-2 ii libunicode-utf8-perl0.62-1+b2 ii liburi-perl 5.10-1 ii libxml-libxml-perl 2.0134+dfsg-2+b1 ii libyaml-libyaml-perl0.83+ds-1 ii lzip1.22-4 ii lzop1.04-2 ii man-db 2.9.4-2 ii patchutils 0.4.2-1 ii perl [libencode-perl] 5.32.1-6 ii t1utils 1.41-4 ii unzip 6.0-26 ii xz-utils5.2.5-2 lintian recommends no packages. Versions of packages lintian suggests: pn binutils-multiarch ii libtext-template-perl 1.60-1 -- no debconf information
Bug#1002502: webpack: Cannot read property 'fullySpecified' of undefined
Package: webpack Version: 5.65.0+dfsg+~cs9.20.9-1 Severity: important Tags: ftbfs During webpack test, I saw this error: /usr/share/nodejs/webpack/lib/NormalModuleFactory.js:873 if (!resolver.options.fullySpecified) return callback(); ^ TypeError: Cannot read property 'fullySpecified' of undefined at Array. (/usr/share/nodejs/webpack/lib/NormalModuleFactory.js:873:28) at arrayEachFunc (/usr/share/nodejs/neo-async/lib/async.js:2517:19) at Object.parallel (/usr/share/nodejs/neo-async/lib/async.js:6858:9) at NormalModuleFactory._resolveResourceErrorHints (/usr/share/nodejs/webpack/lib/NormalModuleFactory.js:870:12) at /usr/share/nodejs/webpack/lib/NormalModuleFactory.js:831:18 at /usr/share/nodejs/enhanced-resolve/lib/Resolver.js:184:12 at /usr/share/nodejs/enhanced-resolve/lib/Resolver.js:238:5 at eval (eval at create (/usr/share/nodejs/tapable/lib/HookCodeFactory.js:24:12), :22:1) at /usr/share/nodejs/enhanced-resolve/lib/Resolver.js:238:5 at eval (eval at create (/usr/share/nodejs/tapable/lib/HookCodeFactory.js:24:12), :10:1)
Bug#1002501: release-notes: Quotes (" and ') in commands in PDF release notes are "smart" (”*” / ’hold$’) so don't copy/paste
Package: release-notes
Severity: important
Dear Maintainer,
As the subject says really. Quotes (" and ') in commands in the PDF Release
Notes are "smart"/slanted (e.g. ”*” / ’hold$’) so when commands are copied from
the pdf and pasted into a shell, they don't work. It's necessary to edit the
command to put "straight" quotes into the command instead.
(Annoying and unnecessary!)
PDF I used: "Release Notes for Debian 11 (bullseye), 64-bit PC | December 14,
2021"
Thanks
Alan
Bug#579938:
שלום צהריים טובים, אנא התקשר אליי עכשיו או השב למייל ששלחתי לך מאתמול
Bug#1002298: clamav 0.103.4+dfsg-0+deb11u1 flagged for acceptance
package release.debian.org tags 1002298 = 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: clamav Version: 0.103.4+dfsg-0+deb11u1 Explanation: new upstream stable release
Bug#1002500: RM: juce [armel] -- ROM; FTBFS
Package: ftp.debian.org Severity: normal please remove the 'armel' binary package produced by src:juce. The latest upstream (just uploaded to unstable; currently being rebuilt) FTBFS on this architecture. I've played around with fixing the FTBFS, but my attempts where hackish at best (the build succeeded by commenting out an assertion; but the assertion was certainly there for a reason in the first place), and given the nature of JUCE (creating audio plugins with a nice GUI) and the power of armel, i came to the conclusion that it makes more sense to just drop the armel package altogether. cheers
Bug#1002297: clamav 0.103.4+dfsg-0+deb10u1 flagged for acceptance
package release.debian.org tags 1002297 = buster pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian buster. Thanks for your contribution! Upload details == Package: clamav Version: 0.103.4+dfsg-0+deb10u1 Explanation: new upstream stable release
Bug#1002499: RM: libfile-rsyncp-perl -- RoQA/RoM; No more used, 3 RC bugs
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: Ludovic Drolez , Debian BackupPC Team , MIA Team Disclaimer: I'm not the maintainer of libfile-rsyncp-perl but I'm one of the maintainers of BackupPC (X-Debbugs-Cc'ed the team) to which this package belonged before Ludovic (X-Debbugs-Cc'ed) orphaned BackupPC (see https://bugs.debian.org/887490) but seems to have forgotten to orphan the related libfile-rsyncp-perl as well. So this request is half RoQA (as I'm not really the maintainer), half RoM (with my Debian BackupPC Team hat on). Anyway, please remove libfile-rsyncp-perl from Debian Unstable: * It currently has 3 RC bugs without any reaction from the package maintainer: Missing required d/rules targets, dh compat 5 or 6, missing source for a configure script. The oldest one is over 2 years old. * It FTBFS since the recent debhelper 13.6 upload due to the removal of support for dh compat levels 5 and 6. * It has no reverse dependencies (verified with "dak rm -n -R libfile-rsyncp-perl") as it was only ever needed by BackupPC ≤ 3.x (at least inside Debian) and also was written by the BackupPC upstream, see https://metacpan.org/pod/File::RsyncP and https://backuppc.github.io/backuppc/BackupPC.html#BackupPC-4.0 And Bullseye already has BackupPC 4.x. So the current Debian BackupPC Team doesn't really care as we don't need it anymore. It has been replaced (function-wise, not file-wise) by the backuppc-rsync package, maintained by the Debian BackupPC Team. * It was not part of the Bullseye release due to at least one of the mentioned RC bugs. * Last upload was in late 2015 and was an NMU. (Last maintainer upload was in spring 2015.) And it's missing one new upstream release from 2020, see https://metacpan.org/dist/File-RsyncP/changes Thanks in advance.
Bug#964090: Error when converting from "jpg" to "pdf" since security upgrade "8:6.9.10.23+dfsg-2.1+deb10u1"
Package: imagemagick Version: 8:6.9.11.60+dfsg-1.3 Followup-For: Bug #964090 X-Debbugs-Cc: matthiasg...@gmail.com Dear Maintainer, I am still running into this issue when using pdfsandwich to do automatic ocr on my pdf files. Since the security issues seem to be fixed, I would also appreciate allowing editing of pdfs by default again. Thanks for your efforts! Regards from Germany, MGies -- Package-specific info: ImageMagick program version --- animate: ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org compare: ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org convert: ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org composite: ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org conjure: ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org display: ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org identify: ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org import: ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org mogrify: ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org montage: ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org stream: ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org -- System Information: Debian Release: 11.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-10-amd64 (SMP w/8 CPU threads) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages imagemagick depends on: ii imagemagick-6.q16 8:6.9.11.60+dfsg-1.3 imagemagick recommends no packages. imagemagick suggests no packages. -- no debconf information
Bug#1002498: FTBFS with ocamlgraph 2.0.0
Source: dose3 Version: 6.0.1-2 Severity: serious Tags: ftbfs Dear Maintainer, Your package FTBFS with ocamlgraph 2.0.0, recently uploaded to unstable: https://buildd.debian.org/status/package.php?p=dose3=sid Tail of log: > $ (cd _build/default && /usr/bin/ocamlc.opt -w -40 -g -bin-annot -I > src/algo/.dose_algo.objs/byte -I /usr/lib/ocaml/bytes -I /usr/lib/ocaml/bz2 > -I /usr/lib/ocaml/cudf -I /usr/lib/ocaml/extlib -I /usr/lib/ocaml/ocamlgraph > -I /usr/lib/ocaml/re -I /usr/lib/ocaml/re/pcre -I /usr/lib/ocaml/seq -I > /usr/lib/ocaml/stdlib-shims -I /usr/lib/ocaml/zip -I > src/common/.dose_common.objs/byte -no-alias-deps -open Dose_algo -o > src/algo/.dose_algo.objs/byte/dose_algo__Dominators.cmo -c -impl > src/algo/dominators.ml) > File "src/algo/dominators.ml", line 123, characters 40-41: > 123 | let module Dom = Dominator.Make_graph(G) in > ^ > Error: Signature mismatch: >... >The value `empty' is required but not provided >File "src/dominator.mli", line 131, characters 2-22: > Expected declaration > make[1]: *** [debian/rules:16: override_dh_auto_build-arch] Error 1 > make[1]: Leaving directory '/<>' > make: *** [debian/rules:8: binary-arch] Error 2 I've tried fixing it, but it looks non-trivial: adding the `empty' value leads to another error... However, a new upstream version is available: 7.0.0. Maybe it fixes the issue. Cheers, -- Stéphane -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-2-amd64 (SMP w/4 CPU threads) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1002471: RFS: xapp/2.2.6-1 [RC] -- Libraries and common resources for multiple desktop environments
Control: retritle -1 RFS: xapp/2.2.6-1 [RC] -- Libraries and common resources for multiple desktop environments Did a small improvements and new upload to mentors: xapp (2.2.6-1) experimental; urgency=medium . [ Joshua Peisach ] * Add dh-sequence-gir to build deps * Bump Standards-Version to 4.6.0.1 * Specify that rules don't require root * Update debian/watch . [ Fabio Fantoni ] * New upstream version 2.2.6 * Use dh-sequence-python3 * Use /usr/libxec as default in compat >=12 and FHS 3.0 * Create new xapp package and move some files from libxapp1 to respect shared libraries policy (Closes: #1000824) * d/copyright: add Upstream-Contact and missed entries * add myself to uploaders field, missed some years ago Regards, -- Fabio Fantoni OpenPGP_signature Description: OpenPGP digital signature
Bug#1002488: barrier not longer start after programstart
Howdy, On Thu, 23 Dec 2021, Jörg Frings-Fürst wrote: Hello, since the last update barrier does not start after programstart. Does going to the main interface and clicking Barrier →Change settings → " Start Barrier on Startup" Help? On the local machine this is just a nuisance, but on the remote machines without their own keyboard and/or mouse it is a significant error. For further questions I am available. ~Unit 193 Unit193 @ Libera Unit193 @ OFTC
Bug#1002497: FTBFS Arch-All with interactive rm
Package: postfix Version: 3.6.3-2 Severity: normal Hi, there seems to be 'rm' missing the '-f', which makes the package fail to build from source if the building system has rm aliased to 'rm -i'. Since all other 'rm' calls in rules have a '-f' too, it though I'd report it. A patch can be found here: https://git.progress-linux.org/packages/fuchur-backports/postfix/commit/?id=2827fbd3f7701b7a8e6ee23c03cac94f0af552d4 Regards, Daniel
Bug#1002029: postgresql-14 JIT failure with LLVM 13 on s390x: ERROR: failed to JIT module: Added modules have incompatible data layouts
Le 20/12/2021 à 18:19, Christoph Berg a écrit : > Source: llvm-toolchain-13 > Version: 1:13.0.0-9 > Severity: important > > Hi, > > after switching from LLVM 11 to LLVM 13 for postgresql-14's JIT > mechanism, JIT fails on s390x with > > 2021-12-03 11:07:38.194 UTC client backend[815426] pg_regress/tablespace > ERROR: failed to JIT module: Added modules have incompatible data layouts: > E-m:e-i1:8:16-i8:8:16-i64:64-f128:64-a:8:16-n32:64 (module) vs > E-m:e-i1:8:16-i8:8:16-i64:64-f128:64-v128:64-a:8:16-n32:64 (jit) > > https://buildd.debian.org/status/fetch.php?pkg=postgresql-14=s390x=14.1-3=1638529682=0 It seems to be an upstream issue. Could you please report it? I won't be able to do anything here. https://github.com/llvm/llvm-project/issues/new Cheers S
Bug#1000336: Upgrading tbb
On 2021-12-23 10:24, Drew Parsons wrote: On 2021-12-23 06:57, Andreas Tille wrote: Hi, Am Wed, Dec 22, 2021 at 05:09:35PM -0800 schrieb Diane Trout: On Wed, 2021-12-22 at 22:24 +0530, Nilesh Patra wrote: > > Actually because of the current state of numba, several reverse > depends are FTBFS so it's > bit urgent to push. Apologies for getting on your nerves, though. I tried. but numba needs tbb version >= 2021. I tried to update tbb but ran into problems trying to build it. Diane is testing a python3.10-compatibility branch for us in numba. At the same time numba upstream has released 0.55.0rc1 which contains their python3.10 fix. Should we just jump straight to it (and not wait for the final 0.55 release)? I don't know how it goes with tbb though. Actually I guess 0.55.0rc1 won't help so easily. It needs llvmlite 0.38.0rc1, and we've only just got 0.37 packaged. numba is a kind of ouroboros, can never get to the end of it. Drew
Bug#999448: [External] Re: Bug#999448: atop: Two fixes for debian/rules: activate atopacctd before activating atop, load atop.default into pkg
Hi Marc, Sorry for the late reply. Yes, this is weird. - When I run `dpkg-buildpackage -us -uc` using code from https://salsa.debian.org/debian/atop/-/tree/debian/2.6.0-1, atopacct service do run earlier than atop. The issue gone. - When I run `dpkg-buildpackage -us -uc` using code from https://github.com/bytedance/atop/tree/bytedance-internal-v2.6.0+byted3, and *revert the execution order of override_dh_installinit[1] in debian/rules*, atop service do run earlier than atopacct. The issue exists. [1] *--- a/debian/rules* *+++ b/debian/rules* @@ -9,8 +9,8 @@ override_dh_auto_clean: rm -f atop atopsar override_dh_installinit: - dh_installinit --name=atopacct dh_installinit --name=atop + dh_installinit --name=atopacct I tried to compare with these two branches' compilation process[2], but not quite sure which command guarantees atopacct run eariler then atop. Could you help to confirm? Thanks. [2] Some segments of the diff of these two branches' compilation process (log-from-bytedance-branch v.s. log-from-debian-branch) make[2]: Leaving directory '/root/fei-gitcode/atop' | make[2]: Leaving directory '/root/fei-gitcode/ *debian-atop-github/*atop' cp atop.service debian/atop.service | cp atop.service debian/atop.service cp atop.default debian/atop.default | - cp atopacct.service debian/atopacct.service | cp atopacct.service debian/atopacct.service cp atop.init debian/atop.init | cp atop.init debian/atop.init cp atopacct.init debian/atopacct.init | cp atopacct.init debian/atopacct.init make[1]: Leaving directory '/root/fei-gitcode/atop' | make[1]: Leaving directory '/root/fei-gitcode/ *debian-atop-github/*atop' dh_install | dh_install dh_installdocs | dh_installdocs dh_installchangelogs | dh_installchangelogs dh_installman | dh_installman dh_*systemd_enable* | dh_*installcron* debian/rules override_dh_installinit | debian/rules override_dh_installinit make[1]: Entering directory '/root/fei-gitcode/atop' | make[1]: Entering directory '/root/fei-gitcode/ *debian-atop-github/*atop' dh_installinit --name=atop | dh_installinit --name=atop dh_installinit --name=atopacct | dh_installinit --name=atopacct make[1]: Leaving directory '/root/fei-gitcode/atop' | make[1]: Leaving directory '/root/fei-gitcode/ *debian-atop-github/*atop' dh_*systemd_start* | dh_*installsystemd* dh_perl | dh_perl dh_link | dh_link dh_strip_nondeterminism | dh_strip_nondeterminism dh_compress | dh_compress dh_fixperms | dh_fixperms dh_missing | dh_missing - | dh_dwz dh_strip | dh_strip dh_makeshlibs | dh_makeshlibs dh_shlibdeps | dh_shlibdeps dh_installdeb | dh_installdeb dh_gencontrol | dh_gencontrol dh_md5sums | dh_md5sums dh_builddeb | dh_builddeb dpkg-deb: building package 'atop' in '../atop_2.6.0*+byted3*_amd64.deb'. | dpkg-deb: building package 'atop' in '../atop_2.6.0*-1*_amd64.deb'. dpkg-deb: building package 'atop-dbgsym' in '../atop-dbgsym_2.6.0*+byted3*_amd64.deb'. | dpkg-deb: building package 'atop-dbgsym' in '../atop-dbgsym_2.6.0*-1*_amd64.deb'. dpkg-genbuildinfo | dpkg-genbuildinfo dpkg-genchanges >../atop_2.6.0*+byted3*_amd64.changes | dpkg-genchanges >../atop_2.6.0*-1*_amd64.changes dpkg-genchanges: info: including full source code in upload | dpkg-genchanges: info: including full source code in upload dpkg-source --after-build . | dpkg-source --after-build . - | dpkg-source: info: using options from atop/debian/source/local-options: --unapply-patches - | dpkg-source: warning: --unapply-patches is not a valid option for Dpkg::Source::Package:: dpkg-buildpackage: info: full upload; Debian-native package (full source is included)| dpkg-buildpackage: info: full upload; Debian-native package (full source is included) log-bytedance
Bug#1000336: Upgrading tbb
On 2021-12-23 06:57, Andreas Tille wrote: Hi, Am Wed, Dec 22, 2021 at 05:09:35PM -0800 schrieb Diane Trout: On Wed, 2021-12-22 at 22:24 +0530, Nilesh Patra wrote: > > Actually because of the current state of numba, several reverse > depends are FTBFS so it's > bit urgent to push. Apologies for getting on your nerves, though. I tried. but numba needs tbb version >= 2021. I tried to update tbb but ran into problems trying to build it. Diane is testing a python3.10-compatibility branch for us in numba. At the same time numba upstream has released 0.55.0rc1 which contains their python3.10 fix. Should we just jump straight to it (and not wait for the final 0.55 release)? I don't know how it goes with tbb though. Drew
Bug#1002464: DH_VERBOSE does not show calls to dpkg-buildflags
Hi Niels, thanks for your explanation. On Thu, Dec 23, 2021 at 04:45:54AM +0100, Niels Thykier wrote: > Marc Haber: > > while debugging a package build process, I would have liked to see what > > debhelper does with dpkg-buildflags. Setting DH_VERBOSE didn't give any > > results, so I chmodded dpkg-buildflags to 000. This shows that debhelper > > calls dpkg-buildflags but doesn't show that in DH_VERBOSE mode: > > > > [...] > > > > I think that those calls should be part of verbose output, and it should > > be shown what debhelper does with dpkg-buildflag's output. > My answer is going into several directions here. First off, DH_VERBOSE > (or --verbose) has conflicting documentation. I will amend that and > close this bug with it. My understanding is that the definition from > --verbose is prevailing, but I will check up on that. Thank you. At least I was able to move something in the right direction. > I hope this email answered your question to satisfaction and led you to > the root of your issue. At least it has given some insight. I should have looked at that include myself. Now I can find out why those QA chains complain that the package does not have evidence of dpkg-buildflags or whether this is a false alert. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#1002200: merge with same bug report
Control: forcemerge 1002290 -1 Merge with similar bug
Bug#1002496: perl6-readline: Strange files under /usr/lib/perl6/vendor/dist?
Package: perl6-readline Version: 0.1.5-3 Severity: minor User: reproducible-bui...@lists.alioth.debian.org Usertags: randomness X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org Hi, Dear Maintainer, The latest version of perl6-readline seems to ship a number of interesting-looking files under /usr/lib/perl6/vendor, such as: /usr/lib/perl6/vendor/dist/A8475E6287F45455F9F68569C07ADC25AA5BEFDF Is this some kind of .pyc equivalent for Perl 6? Either way, I'd love to know more as these files appear to be unreproducible. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#1002200: this is not a bug of wfuzz but dh-python
Control: reassign -1 dh-python Control: severity -1 grave Control: merge 1002290 -1 Control: affects -1 + wfuzz Hi, this bug seems to be a bug in dh-python. Sophie OpenPGP_signature Description: OpenPGP digital signature
Bug#559423: delgroup: incorrect exit status
On Fri, Dec 04, 2009 at 10:17:42AM +0100, Gabor Kiss wrote: > Deluser(8) writes: >--system > Only delete if user/group is a system user/group. This avoids > accidentally deleting non-system users/groups. Additionally, if > the user does not exist, no error value is returned. This option > is mainly for use in Debian package maintainer scripts. > > Actually in case of deleting non-existent group the exit code is 3 even > if I give --system option. I agree with that twelve years later. Maybe we should deluser --force have this behavior even for non-system users since people using deluser probably only care about the result, the user being gone after the call. Greetings Marc
Bug#1002495: deluser --force should be --no-preserve-root
Package: adduser Version: 3.118 Severity: minor File: /usr/sbin/deluser Hi, to my surprise, I found out that deluser --force does not what I think¹ but it allows to delete the root user. It's documented that way, but it's misnamed in my opinion. In fact, https://codesearch.debian.net/search?q=deluser.*force=0 clearly shows that all pacakge maintainers who use deluser --force are using it wrong. The safeguard against removing root should be relaxed with an option like --no-preserve-root (see, man 1 rm), so that --force can be used for the analogon to rm --force as to not returning an error when a user to be deleted didnt expect in the first place. This can then be used if the author of a script just cares about the result (e.g. user gone) after the deluser call without caring for whether the user existed before the call or not. Greetings Marc ¹ I expected it to make deleting a user that does not exist not an error
Bug#1002494: webpack 5 unusable: TypeError: this.program.configureOutput
Package: webpack Version: 5.65.0+dfsg+~cs9.20.9-1 Severity: grave Justification: renders package unusable When trying to use webpack5, I got the following error: make[1]: Entering directory '/<>' webpack --mode production (node:647989) UnhandledPromiseRejectionWarning: TypeError: this.program.configureOutput is not a function at new WebpackCLI (/usr/share/nodejs/webpack-cli/lib/webpack-cli.js:19:18) at runCLI (/usr/share/nodejs/webpack-cli/lib/bootstrap.js:5:15) at Object. (/usr/share/nodejs/webpack-cli/bin/cli.js:17:1) at Module._compile (internal/modules/cjs/loader.js:999:30) at Object.Module._extensions..js (internal/modules/cjs/loader.js:1027:10) at Module.load (internal/modules/cjs/loader.js:863:32) at Function.Module._load (internal/modules/cjs/loader.js:708:14) at Module.require (internal/modules/cjs/loader.js:887:19) at require (internal/modules/cjs/helpers.js:74:18) at runCli (/usr/share/nodejs/webpack/bin/webpack.js:69:2) (node:647989) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1) (node:647989) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code. make[1]: Leaving directory '/<>' By the way at least to dependencies are missing: * node-execa * node-import-local (provided by node-jest-bundle) Cheers, Yadd
Bug#892222: seqan2: FTBFS on hppa: app_test_seqan_tcoffee fails on 2trx.mlcs.fasta
Hi Aaron, I had a quick look at this bug and realises that currently the source code does not even build any more[1] thus not even reaching the test you spotted as failing: ... [ 3%] Building CXX object apps/pair_align/lib/CMakeFiles/pair_align_global_1011.dir/pair_align_global.cpp.o cd /<>/obj-hppa-linux-gnu/apps/pair_align/lib && /usr/bin/c++ -DSEQAN_APP_VERSION=\"1.3.8\" -DSEQAN_DATE=\"\" -DSEQAN_DISABLE_VERSION_CHECK -DSEQAN_HAS_BZIP2=1 -DSEQAN_HAS_EXECINFO=1 -DSEQAN_HAS_OPENMP=1 -DSEQAN_HAS_ZLIB=1 -DSEQAN_REVISION=\"tarball\" -DSUFFIX_GAP_BOTTOM=1 -DSUFFIX_GAP_LEFT=0 -DSUFFIX_GAP_RIGHT=1 -DSUFFIX_GAP_TOP=1 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I/<>/include -g -O2 -fdebug-prefix-map=/<>=. -Wformat -Werror=format-security -DNDEBUG -O3 -Wdate-time -D_FORTIFY_SOURCE=2 -W -Wall -pedantic -fopenmp -DSEQAN_GLOBAL_EXCEPTION_HANDLER=1 -MD -MT apps/pair_align/lib/CMakeFiles/pair_align_global_1011.dir/pair_align_global.cpp.o -MF CMakeFiles/pair_align_global_1011.dir/pair_align_global.cpp.o.d -o CMakeFiles/pair_align_global_1011.dir/pair_align_global.cpp.o -c /<>/apps/pair_align/lib/pair_align_global.cpp malloc(): unaligned tcache chunk detected malloc(): unaligned tcache chunk detected c++: internal compiler error: Aborted signal terminated program cc1plus Please submit a full bug report, with preprocessed source if appropriate. Kind regards Andreas. [1] https://buildd.debian.org/status/fetch.php?pkg=seqan2=hppa=2.4.0%2Bdfsg-14=1638150140=0 -- http://fam-tille.de
Bug#1001961: fakeroot: diff for NMU version 1.26-1.1
Control: tags 995393 + pending
Control: tags 1001961 + pending
Dear maintainer,
to fix the two pressing problems for this package, I've prepared an NMU
for fakeroot (versioned as 1.26-1.1), upload it to DELAYED/3 will follow
shortly. Please feel free to tell me if I should delay it longer.
Regards.
Christoph
diff -Nru fakeroot-1.26/debian/changelog fakeroot-1.26/debian/changelog
--- fakeroot-1.26/debian/changelog 2021-09-07 03:41:37.0 +0200
+++ fakeroot-1.26/debian/changelog 2021-12-23 08:19:30.0 +0100
@@ -1,3 +1,11 @@
+fakeroot (1.26-1.1) unstable; urgency=high
+
+ * Non-maintainer upload
+ * Also wrap the "stat" library call. Closes: #1001961
+ * Work around segfault on ppc64el. Closes: #995393
+
+ -- Christoph Biedl Thu, 23 Dec 2021
08:19:30 +0100
+
fakeroot (1.26-1) unstable; urgency=medium
[ Helmut Grohne ]
diff -Nru fakeroot-1.26/debian/patches/also-wrap-stat-library-call.patch
fakeroot-1.26/debian/patches/also-wrap-stat-library-call.patch
--- fakeroot-1.26/debian/patches/also-wrap-stat-library-call.patch
1970-01-01 01:00:00.0 +0100
+++ fakeroot-1.26/debian/patches/also-wrap-stat-library-call.patch
2021-12-23 08:17:43.0 +0100
@@ -0,0 +1,63 @@
+Subject: Also wrap the "stat" library call
+Author: Christoph Biedl
+Date: 2021-12-20
+Bug-Debian: https://bugs.debian.org/1001961
+Forwarded: Yes
+
+Seems changes in glibc 2.33 caused the stat() function to be mapped
+into a stat() library call instead of __xstat() as it used to be.
+
+However, fakeroot does not wrap this, causing files to be reported
+with the real owner, not 0 as expected.
+
+The fix for this got a bit ugly as the abstraction in configure.ac
+would not allow wrapping both "stat" and "__xstat". So enhance the
+search list capabilities with an optional symbol how the wrapped
+function is named internally. Also hack the parser so "stat" gets
+actually probed and not mistaken for __xstat.
+
+Using "realstat" as a symbol is not the best choice as it might be
+confusing, but "statstat" seemed even worse.
+
+--- a/configure.ac
b/configure.ac
+@@ -353,9 +353,13 @@
+
+ :>fakerootconfig.h.tmp
+
+-for SEARCH in %stat f%stat l%stat f%statat %stat64 f%stat64 l%stat64
f%statat64 %mknod %mknodat; do
+- FUNC=`echo $SEARCH|sed -e 's/.*%//'`
++for SEARCH in %stat s%tat@realstat f%stat l%stat f%statat %stat64 f%stat64
l%stat64 f%statat64 %mknod %mknodat; do
++ FUNC=`echo $SEARCH|sed -e 's/.*%// ; s/@.*//'`
+ PRE=`echo $SEARCH|sed -e 's/%.*//'`
++ SYMBOL=`echo $SEARCH|sed -e 's/.*@//'`
++ if test "$SYMBOL" = "$SEARCH" ; then
++SYMBOL="${PRE}${FUNC}"
++ fi
+ FOUND=
+ for WRAPPED in __${PRE}x${FUNC} _${PRE}x${FUNC} __${PRE}${FUNC}13
${PRE}${FUNC}; do
+ AC_CHECK_FUNCS($WRAPPED,FOUND=$WRAPPED)
+@@ -366,8 +370,8 @@
+ dnl for WRAPPED in _${PRE}${FUNC}; do
+ dnlFOUND=$WRAPPED
+ if test -n "$FOUND"; then
+- PF=[`echo ${PRE}${FUNC}| tr '[a-z]' '[A-Z]'`]
+- DEFINE_WRAP=[`echo wrap_${PRE}${FUNC}| tr '[a-z]' '[A-Z]'`]
++ PF=[`echo $SYMBOL | tr '[a-z]' '[A-Z]'`]
++ DEFINE_WRAP=[`echo wrap_${SYMBOL}| tr '[a-z]' '[A-Z]'`]
+ DEFINE_NEXT=[`echo wrap_${FOUND}| tr '[a-z]' '[A-Z]'`]
+ DEFINE_ARG=[`echo wrap_${FOUND}| tr '[a-z]' '[A-Z]'`]
+ AC_DEFINE_UNQUOTED(WRAP_${PF}, $FOUND)
+@@ -509,6 +513,12 @@
+ #define TMP_STAT __astat
+ #define NEXT_STAT_NOARG next___astat
+
++#define WRAP_REALSTAT __astat
++#define WRAP_REALSTAT_QUOTE __astat
++#define WRAP_REALSTAT_RAW __astat
++#define TMP_REALSTAT __astat
++#define NEXT_REALSTAT_NOARG next___astat
++
+ #define WRAP_LSTAT_QUOTE __astat
+ #define WRAP_LSTAT __astat
+ #define WRAP_LSTAT_RAW __astat
diff -Nru fakeroot-1.26/debian/patches/ppc64el-workaround.patch
fakeroot-1.26/debian/patches/ppc64el-workaround.patch
--- fakeroot-1.26/debian/patches/ppc64el-workaround.patch 1970-01-01
01:00:00.0 +0100
+++ fakeroot-1.26/debian/patches/ppc64el-workaround.patch 2021-12-23
08:18:30.0 +0100
@@ -0,0 +1,31 @@
+Subject: Work around segfault on ppc64el
+Author: Christoph Biedl
+Date: 2021-12-20
+Bug-Debian: https://bugs.debian.org/995393
+Forwarded: Yes
+
+For whatever reason the generated code segfaults on ppc64el when
+built with the usual optimizations. The root cause is not clear,
+might be a compiler bug or the result of improperly generated
+function prototypes.
+
+As a workaround, disable optimizations for the affected function.
+
+This should be re-visted upon any major compiler release whether
+it's still needed.
+
+--- a/libfakeroot.c
b/libfakeroot.c
+@@ -2596,7 +2596,11 @@
+ #endif
+
+ #ifdef HAVE_OPENAT
+-int openat(int dir_fd, const char *pathname, int flags, ...)
++int
++#if HAVE_OPENAT && defined(__powerpc__) && defined(__powerpc64__) &&
__BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
++__attribute__((optimize("O0")))
++#endif
++openat(int dir_fd, const char *pathname,
Bug#1002493: RM: libjs-rtcpeerconnection-shim -- ROM; unmaintained upstream and no longer needed
Package: ftp.debian.org Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, Please drop libjs-rtcpeerconnection-shim from unstable: It was previously a build-dependency of libjs-webrtc-adapter but not anymore, and there is no other need for it. - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmHELt8ACgkQLHwxRsGg ASF/Rw//dZqiyNGmR+5wfyWsJTpEvdcFX1jl3BrUDb/vAYlOz9vh9H735BBiXMoQ U7q/xhUJiEBTgbqF3WA8Hm5h/QWFClhIwbgUxSA13wY3OG7B5syHjC0AHgNVOj/9 VC8BwEMOSRnRv0ULoaJf3fTX+O/C9jKQaGoACp4uoR1wQ4aNJI0av70RTeDDhNXu NFvTO9xzC8NYG/XXPWd9Ef/PeX5PnYfkqVsru2wCtHqMqMD684jE8vk0l+9tQ7tS AAQlxzkjKajxsAJS4FLxD3jYteMu3wj1czggbvnhT/KO/ppL9qD0z7lrTGRUnl2S sQo936Y3Bn/TOLWSB5Q4rmwKvOUK+NxEEWAeVQvU7StTY5Puoec+kXg2e0O5iaUT O2zBJd2ZNOZyN6+4ygp9kt8jB3kh7hG6ipbyQl4MS/Qqj4ZIrI/A2WuVkXvQGBHa FwRVABmfVVofEAzCFnrkg3GKXHADi6SE7nzquf9N6nkc5xnqmUtOWmQs2HWiD0cr meLQABq7lf7b2kxQOtilILakFWX8ce3OE33glIwppIV3NRIndl0vaozfdJq2zkTY aCTL72YqMK3GFEG1BcsjcF4q6KDFVSm2L9YGtWQ8ISTTV03g2sVMv5JBMudDIKPA FXmAYOnl4gnlwTUNWfexTqWVJ8JrwhyL7DZOS7B1e2UTsbVZcss= =MtO7 -END PGP SIGNATURE-
