Bug#999644: RM: tumgreyspf -- RoQA; RC buggy, upstream vanished

[Thomas Goirand]

On 11/14/21 9:29 AM, Scott Kitterman wrote:
> Package: ftp.debian.org
> Severity: normal
> 
> This missed the last release and requires porting to a newer Python.
> Upstream has also shutdown.  I don't think it serves a point to keep
> this in Debian anymore.
> 
> Maintainer is cc'ed in case he has a different view.
> 
> Scott K
> 

I'm fine with it going away. I have to recognize I haven't done the work
in time and probably wont have time to do it later.

Cheers,

Thomas Goirand (zigo)

Bug#950938: Character range comparison bug

[Kimmo Suominen]

This bug has been fixed upstream since 29 July 2019.

I've replied to bug #999754 earlier today linking to the necessary patch.
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=999754#10

Kind regards,
+ Kimmo

Bug#999385: python-pyalsa ftbfs with Python 3.10

[Steve Langasek]

Package: python-pyalsa
Followup-For: Bug #999385
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jammy ubuntu-patch
Control: tags -1 patch

Please find attached a patch that fixes this build failure.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru python-pyalsa-1.1.6/debian/patches/python-3.10.patch 
python-pyalsa-1.1.6/debian/patches/python-3.10.patch
--- python-pyalsa-1.1.6/debian/patches/python-3.10.patch1969-12-31 
16:00:00.0 -0800
+++ python-pyalsa-1.1.6/debian/patches/python-3.10.patch2021-11-15 
23:21:21.0 -0800
@@ -0,0 +1,21 @@
+Description: Fix build failure with python 3.10.
+ PyTuple_SET_ITEM returns void; don't try to check its return value
+Author: Steve Langasek 
+Bug-Debian: https://bugs.debian.org/999385
+Last-Update: 2021-11-15
+
+Index: python-pyalsa-1.1.6/pyalsa/alsahcontrol.c
+===
+--- python-pyalsa-1.1.6.orig/pyalsa/alsahcontrol.c
 python-pyalsa-1.1.6/pyalsa/alsahcontrol.c
+@@ -1543,8 +1543,8 @@
+ 
+   t = PyTuple_New(2);
+   if (t) {
+-  if (PyTuple_SET_ITEM(t, 0, (PyObject *)pyhelem))
+-  Py_INCREF(pyhelem);
++  PyTuple_SET_ITEM(t, 0, (PyObject *)pyhelem);
++  Py_INCREF(pyhelem);
+   PyTuple_SET_ITEM(t, 1, PyInt_FromLong(mask));
+   r = PyObject_CallObject(o, t);
+   Py_DECREF(t);
diff -Nru python-pyalsa-1.1.6/debian/patches/series 
python-pyalsa-1.1.6/debian/patches/series
--- python-pyalsa-1.1.6/debian/patches/series   1969-12-31 16:00:00.0 
-0800
+++ python-pyalsa-1.1.6/debian/patches/series   2021-11-15 23:16:57.0 
-0800
@@ -0,0 +1 @@
+python-3.10.patch

Bug#992104: q2-diversity-lib_2021.8.0-1_amd64.changes REJECTED

[Andreas Tille]

Hi Thorsten,

Am Mon, Nov 15, 2021 at 07:00:09PM + schrieb Thorsten Alteholz:
> please mention versioneer and _version.py in your debian/coypright.

This is fixed in new upload.

Thanks for thorough checking

  Andreas. 

-- 
http://fam-tille.de

Bug#999754: tcsh: character class expansion is badly broken

[Kimmo Suominen]

Please consider applying the following three patches as a minimal fix.

1) To fix the character range comparison bug:
https://github.com/tcsh-org/tcsh/commit/4679bde3e1ceca63d6eb4de5ce41c996405e61aa.patch

2) To pass the current more stringent compiler options:
https://github.com/tcsh-org/tcsh/commit/6974bc35a5cda6eab748e364bd76a860ca66968b.patch

3) To silence the warnings about _DEFAULT_SOURCE:
https://github.com/tcsh-org/tcsh/commit/3a6eadd6a30e40667be14b374a234ddcdeb1e638.patch

Kind regards,
+ Kimmo

Bug#999756: lintian: False positive bashism in posix shell after "exec"

[Rafael Laboissière]

Package: lintian
Version: 2.112.0
Severity: normal

Dear Maintainer,

Litian is triggering bash-term-in-posix-shell warnings (use of "source" 
command) for some files of the plplot package, like this one:


https://salsa.debian.org/science-team/plplot/-/blob/master/examples/tcl/x00.in

This is a false positive, because this file contains an "exec" command 
and the "source" command is placed after it.  These are the contents of 
the file above, after substitution by the configure script and after 
stripping away comments and blank lines:

#!/bin/sh
exec "/usr/bin/pltcl" -f "$0" ${1+"$@"}
source x00.tcl
plinit
x00
plend

Lintian should stop looking for bashisms after the exec command.

Best,

Rafael Laboissière

 -- System Information:
 Debian Release: bookworm/sid
   APT prefers unstable
   APT policy: (650, 'unstable'), (600, 'experimental'), (550, 'testing'), 
(500, 'oldoldstable'), (500, 'stable')
 Architecture: amd64 (x86_64)

 Kernel: Linux 5.10.0-8-amd64 (SMP w/2 CPU threads)
 Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
 Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8
 Shell: /bin/sh linked to /bin/bash
 Init: systemd (via /run/systemd/system)
 LSM: AppArmor: enabled

 Versions of packages lintian depends on:
 ii  binutils2.37-7
 ii  bzip2   1.0.8-4
 ii  diffstat1.64-1
 ii  dpkg1.20.9
 ii  dpkg-dev1.20.9
 ii  file1:5.39-3
 ii  gettext 0.21-4
 ii  gpg 2.2.27-2
 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.20.9
 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-2
 ii  libmoox-aliases-perl0.001006-1.1
 ii  libnamespace-clean-perl 0.27-1
 ii  libpath-tiny-perl   0.118-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-1
 ii  libtext-levenshteinxs-perl  0.03-4+b8
 ii  libtext-markdown-discount-perl  0.13-1
 ii  libtext-xslate-perl 3.5.8-1+b1
 ii  libtime-duration-perl   1.21-1
 ii  libtime-moment-perl 0.44-1+b3
 ii  libtimedate-perl2.3300-2
 ii  libtry-tiny-perl0.30-1
 ii  libtype-tiny-perl   1.012004-1
 ii  libunicode-utf8-perl0.62-1+b2
 ii  liburi-perl 5.08-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:
 ii  binutils-multiarch 2.37-7
 ii  libtext-template-perl  1.60-1

 -- no debconf information

Bug#999755: [RFP] fusenfs -- fuse command to mount nfs shares

[Don Smith]

Package: wnpp
Severity: wishlist

This is a GPL 3.0 application located at
https://github.com/sahlberg/fuse-nfs

Bug#999754: tcsh: character class expansion is badly broken

[Jon Leech]

Package: tcsh
Version: 6.21.00-1.1
Severity: grave
Tags: newcomer
Justification: causes non-serious data loss

Dear Maintainer,

tcsh does not respect character classes. Minimal example:

$ mkdir a
$ touch a/a a/B
$ echo a/[a-z]
a/a a/B

I expect the result to simply be 'a/a' since 'B' is not in [a-z]. The behavior
generalizes to character classes in wildcards - it is not just about the
trivial one-character filename example seen here.

This is in locale en_US.UTF-8, but switching to locale "C" has the same
behavior.

This behavior can result in data loss with e.g. 'rm [a-z]*' removing unexpected
files, and can also result in operating on the wrong files, so I have
tentatively
classified it 'grave'. tcsh as packaged is unusable for my purposes.

I have verified that tcsh built from the current upstream (version 6.23.00)
with

$ git clone g...@github.com:tcsh-org/tcsh.git
$ cd tcsh
$ configure && make

Does NOT suffer this behavior, while tcsh built from the Debian source package
with

$ apt-get --build source tcsh

DOES suffer this behavior. The 6.23.00 built from upstream has the same
$version
string options as the Debian 6.21.00 except for "nd" (NODOT).

I attempted to build from the upstream repository at version 6.21.00 but could
not successfully build after 'configure', so I cannot tell if this is a bug
introduced by the Debian-specific changes, or a bug in the upstream 6.21.00.
The differences between the Debian source package with patches applied vs.
upstream 6.21.00 source are smallish and don't obviously implicate character
classes but that proves nothing.

Suggested resolutionn is to update the buster package to tcsh 6.23.00. I
believe
this will also result in elimination of a large number of warning messages
during
the build of form

/usr/include/features.h:187:3: warning: #warning "_BSD_SOURCE and _SVID_SOURCE
are deprecated, use _DEFAULT_SOURCE" [-Wcpp]
  187 | # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use
_DEFAULT_SOURCE"
  |   ^~~


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

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

Versions of packages tcsh depends on:
ii  libc6  2.31-13+deb11u2
ii  libcrypt1  1:4.4.18-4
ii  libtinfo6  6.2+20201114-2

tcsh recommends no packages.

tcsh suggests no packages.

Bug#913079: Strawberry ITP status

[Louis-Philippe Véronneau]

Hello!

I was wondering what was the status of this ITP. I don't currently see
the package in NEW...

Cheers, and thanks for your packaging efforts.

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄


OpenPGP_signature
Description: OpenPGP digital signature

Bug#999753: wine-development: unsatisfiable build-dependency on unicode-data (< 14)

[Ralf Treinen]

Source: wine-development
Version: 6.0+repack-1
Severity: serious
Usertag: edos-uninstallable

Hi, 

wine-development build-deoends on unicode-data (< 14) but the version in
testing and in sid is 14.0.0-1.1.

-Ralf.

Bug#992214: RFS: nemo-compare/5.0.1-1 [ITP] -- Context menu comparison extension for Nemo file manager

[Norbert Preining]

Hi Joshua,

please send me the details (git repo) and I will look into it.

Best

Norbert

--
PREINING Norbert  https://www.preining.info
Fujitsu Research  +  IFMGA Guide  +  TU Wien  +  TeX Live  + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#995653: django-mailman3 breaks hyperkitty autopkgtest: 'str' object has no attribute 'display_name'

[Adrian Bunk]

Control: reassign -1 src:hyperkitty 1.3.4-4
Control: retitle -1 hyperkitty FTBFS with django-mailman3 1.3.7
Control: tags -1 ftbfs bookworm sid

On Sun, Oct 03, 2021 at 07:15:18PM +0200, Paul Gevers wrote:
>...
>passfail
> django-mailman3from testing1.3.7-1
> hyperkitty from testing1.3.4-4
> all others from testingfrom testing
>...
> ==
> ERROR: test_basic_reply (hyperkitty.tests.lib.test_posting.PostingTestCase)
> --
> Traceback (most recent call last):
>   File
> "/usr/lib/python3/dist-packages/hyperkitty/tests/lib/test_posting.py",
> line 69, in test_basic_reply
> self.user.save()
>   File
> "/usr/lib/python3/dist-packages/django/contrib/auth/base_user.py", line
> 66, in save
> super().save(*args, **kwargs)
>   File "/usr/lib/python3/dist-packages/django/db/models/base.py", line
> 743, in save
> self.save_base(using=using, force_insert=force_insert,
>   File "/usr/lib/python3/dist-packages/django/db/models/base.py", line
> 791, in save_base
> post_save.send(
>   File "/usr/lib/python3/dist-packages/django/dispatch/dispatcher.py",
> line 173, in send
> return [
>   File "/usr/lib/python3/dist-packages/django/dispatch/dispatcher.py",
> line 174, in 
> (receiver, receiver(signal=self, sender=sender, **named))
>   File "/usr/lib/python3/dist-packages/django_mailman3/signals.py", line
> 101, in create_profile
> address.display_name = new_display_name
> AttributeError: 'str' object has no attribute 'display_name'
>...

This is also a FTBFS:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/hyperkitty.html

cu
Adrian

Bug#999677: RFP: popcon-stats-data -- Debian's Popularity Contest statistics

[Paul Wise]

On Tue, 2021-11-16 at 08:38 +0800, Paul Wise wrote:

> I think a better approach would be to ship this data in the Debian
> apt repository metadata, either in the Packages files or in
> Popularity files in the dists/ dir

I note that debtags.debian.org uses this approach, data is gathered on
the site, then uploaded to ftp-master, which integrates the data and
distributes it via the Packages files. So it should work if the FTP
Team and Popcon teams are willing to support the idea.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#990280: RFS: lg-gpio/0.1.7.0-1 [ITP] -- Control GPIO pins remotely

[Bastian Germann]

Hi Dave,

On 15.11.21 13:19, Dave Jones wrote:

Hi Bastian,

On Sun, Nov 14, 2021 at 01:58:54AM +0100, Bastian Germann wrote:

On Mon, 1 Nov 2021 14:43:14 + Dave Jones wrote:
Filed bug #998243 against wnpp, and took the opportunity to bump the packaging to 0.2.0.0 while 
doing so; packaging is updated on salsa, and the source package is also uploaded to mentors.

d/watch
===
debian-watch-file-is-missing

This is very important when you have several packages to maintain. It keeps 
track of new releases.


Unfortunately in this case, upstream's form of distribution doesn't work with Debian's uscan 
tooling. Specifically, they distribute their various libraries and tools (including lg) as a zip 
file named after the project without a version component. The version component is stored as an 
empty file within the root of the zip file.


In other words, it's not possible (or more accurately I couldn't work out how) to get uscan to 
determine a new version is available and download it.


However, I agree entirely that this is an important piece of tooling for any maintainer, hence my 
inclusion of a simple "get-orig-source" script in the debian/ directory (also referenced as the 
"get-orig-source" target of d/rules) which does the equivalent job to uscan in this case (downloads 
the appropriate zip archive from upstream, checks if it matches the present one, and calls 
mk-origtargz on the result as necessary).


I just checked http://abyz.me.uk/lg/lg.zip against the GitHub releases/tags provided archive. They 
are not bit-by bit identical but contain the same source. As .zip cannot be used as an orig tarball 
directly, it is actually preferrable in this case not to get the author-uploaded zip but to use the 
GitHub tar.gz archive.


You can use one of uscan's versionmangle options to add the .0.0 but in my opinion you can also just 
go with the GitHub tag version. So, please replace your get-orig-source script by d/watch.


Actually, you are already claiming in d/copyright that Source is 
https://github.com/joan2937/lg.


d/copyright
===
Please consider relicensing debian/* or at least debian/patches/* to the 
Unlicense as well.
The effective license of your patched package is GPL-3+ now, given that your patches are actually 
copyrightable. Also, upstream would not take your patches.


Good point -- certainly happy to relicense the debian/* bits as Unlicense (I was surprised to learn 
that on Debian SQLite, a famously public domain piece of software, is likewise GPL licensed as a 
result of this).



Please rename what is now called public-domain to Unlicense.


Fixed (though I'm slightly dis-heartened that unlicensed stuff can't be trivially labelled 
public-domain).


On reading the license text you will find out that there are jurisdictions that do not have a 
concept of explicitly putting a work into the public domain. It is not equivalent in those 
jurisdictions.



d/control
=
duplicate-short-description liblgpio-dev liblgpio1 python3-lgpio


Fixed.


python3-rgpio: package-contains-no-arch-dependent-files


Ah yes, the rgpio Python bit should indeed be "all". Fixing that caused a 
"not-binnmuable-all-depends-any" tag to pop up in lintian, which is something new to me (and led to 
some "what is binnmu?" googling). I *appear* to have fixed that by cargo-culting the tag's 
recommendation to change the dependency to >= source:Version but I wonder if there's some subtlety 
I'm missing. Would be grateful if you (or anyone) could verify this is indeed correct now.


This is okay in this case. One can upload rebuilds of binary packages which are not arch=all. The 
version changes in this case. An all package depending on that would then not install anymore.



d/changelog
===
Why are the .0.0 in your upstream version? I see 0.2 on GitHub.


The GitHub repo doesn't have the definitive list of versions (e.g. 0.1.6.1 and 0.1.7.0, which were 
released, are missing); the author's versioning scheme (within the source archive) always includes 
four components, so I assumed the upstream component of the debian version number should do likewise?


As I said, I am fine with both options (two or four components). For versions that end on something 
!= .0.0, you can still extend to four components.


Though, in light of the "not-binnmuable-all-depends-any" tag I encountered above, I wonder if they 
should be left off to permit a stronger Depends line for python3-rgpio?


One is independent of the other.


symbols
===
symbols-file-missing-build-depends-package-field liblgpio.so.1 librgpio.so.1


Fixed.


Thanks,
Bastian

Bug#999752: libtsan2: libtsan_preinit.o is also in package libtsan0:amd64 11.2.0-10

[Arthur Marsh]

Package: libtsan2
Version: 12-2023-1
Severity: important

Dear Maintainer,

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

   * What led up to the situation?

Performing actions...
Selecting previously unselected package cpp-12.
(Reading database ... 631827 files and directories currently installed.)
Preparing to unpack .../cpp-12_12-2023-1_amd64.deb ...
Unpacking cpp-12 (12-2023-1) ...
Selecting previously unselected package libasan8:amd64.
Preparing to unpack .../libasan8_12-2023-1_amd64.deb ...
Unpacking libasan8:amd64 (12-2023-1) ...
Selecting previously unselected package libtsan2:amd64.
Preparing to unpack .../libtsan2_12-2023-1_amd64.deb ...
Unpacking libtsan2:amd64 (12-2023-1) ...
dpkg: error processing archive 
/var/cache/apt/archives/libtsan2_12-2023-1_amd64.deb (--unpack):
 trying to overwrite '/usr/lib/x86_64-linux-gnu/libtsan_preinit.o', which is 
also in package libtsan0:amd64 11.2.0-10
Selecting previously unselected package libgcc-12-dev:amd64.
Preparing to unpack .../libgcc-12-dev_12-2023-1_amd64.deb ...
Unpacking libgcc-12-dev:amd64 (12-2023-1) ...
Selecting previously unselected package gcc-12.
Preparing to unpack .../gcc-12_12-2023-1_amd64.deb ...
Unpacking gcc-12 (12-2023-1) ...
Errors were encountered while processing:
 /var/cache/apt/archives/libtsan2_12-2023-1_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
Setting up cpp-12 (12-2023-1) ...
dpkg: dependency problems prevent configuration of libgcc-12-dev:amd64:
 libgcc-12-dev:amd64 depends on libtsan2 (>= 12-2023-1); however:
  Package libtsan2:amd64 is not installed.

dpkg: error processing package libgcc-12-dev:amd64 (--configure):
 dependency problems - leaving unconfigured
Setting up libasan8:amd64 (12-2023-1) ...
dpkg: dependency problems prevent configuration of gcc-12:
 gcc-12 depends on libgcc-12-dev (= 12-2023-1); however:
  Package libgcc-12-dev:amd64 is not configured yet.

dpkg: error processing package gcc-12 (--configure):
 dependency problems - leaving unconfigured
Processing triggers for man-db (2.9.4-2) ...
Processing triggers for libc-bin (2.32-4) ...
Errors were encountered while processing:
 libgcc-12-dev:amd64
 gcc-12
Press Return to continue, 'q' followed by Return to quit.


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

Cancelling the installation of gcc-12 removed the conflict.

   * What was the outcome of this action?
   * What outcome did you expect instead?

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


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

Kernel: Linux 5.16.0-rc1+ (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages libtsan2 depends on:
ii  gcc-12-base  12-2023-1
ii  libc62.32-4
ii  libgcc-s112-2023-1

libtsan2 recommends no packages.

libtsan2 suggests no packages.

Bug#999751: di-netboot-assistant: please drop shellcheck autopkgtest

[Samuel Henrique]

Source: di-netboot-assistant
Version: 0.71
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org, shellch...@packages.debian.org
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:shellcheck

Dear maintainer(s),

With a recent upload of shellcheck the autopkgtest of di-netboot-assistant
fails in testing when that autopkgtest is run with the binary packages
of shellcheck from unstable. It passes when run with only packages from
testing. In tabular form:

   passfail
shellcheck from testing0.8.0-2
di-netboot-assistantfrom testing0.71
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of shellcheck to
testing [1]. Of course, shellcheck shouldn't just break your autopkgtest
(or even worse, your package), but in this case shellcheck just evolved.
Static analysis tools are intended to run on source code, while
autopkgtest is intended to run against installed packages, where source
code is in principle not relevant; we want to know whether the binary
packages, as provided in the Debian archive, work correctly. In our
opinion running this type of tools as integration tests in autopkgtest,
or even as build-time tests is Wrong™, and should not be done. (Having
them run in salsaci or equivalent is of course totally great.)

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

[1] https://qa.debian.org/excuses.php?package=shellcheck

https://ci.debian.net/data/autopkgtest/testing/amd64/d/di-netboot-assistant/16684224/log.gz

autopkgtest [03:27:30]: test command1: shellcheck -x
/usr/bin/di-netboot-assistant ;   shellcheck -x -s dash
/var/lib/dpkg/info/di-netboot-assistant.post*
/var/lib/dpkg/info/di-netboot-assistant.pre*
autopkgtest [03:27:30]: test command1: [---

In /usr/bin/di-netboot-assistant line 452:
echo -e "MENU BACKGROUND ::${s#$TFTP_ROOT}\n" >> pxelinux.cfg/default
   ^^ SC2295 (info):
Expansions inside ${..} need to be quoted separately, otherwise they
match as patterns.

Did you mean:
echo -e "MENU BACKGROUND ::${s#"$TFTP_ROOT"}\n" >> pxelinux.cfg/default

For more information:
  https://www.shellcheck.net/wiki/SC2295 -- Expansions inside ${..} need to b...
autopkgtest [03:27:32]: test command1: ---]
autopkgtest [03:27:32]: test command1:  - - - - - - - - - - results -
- - - - - - - - -
command1 FAIL non-zero exit status 1

I took the liberty to base the body of this email on bugreport
#992798, from Paul Gevers,

-- 
Samuel Henrique 

Bug#999745: systemd: `systemd-run --scope --user` fails with 'No PIDs left'

[Michael Biebl]

Control: tags -1 = upstream

On 16.11.21 00:39, Michał Dominiak wrote:
On Mon, Nov 15, 2021 at 11:28 PM Michael Biebl > wrote:


Control: tags -1 + moreinfo unreproducible

On 15.11.21 23:08, Michał Dominiak wrote:
 > systemd-run --scope --user tmux

Hm, works fine here.
Can you provide more detailed steps how this can be reproduced.


I have done a fresh install of sid (installed 11.1 and upgraded all 
packages to unstable versions) in a VM just to verify that this is not 
something caused by my system's configuration. I was able to reproduce 
this after rebooting into sid.


I couldn't reproduce it with gnome-terminal and tilix, which I typically 
use. But I could reproduce it within sakura and on the console. Thus 
removing the the unreproducible tag again.


Michał, could you forward this to upstream and report it as a recent 
regression?

The upstream bug tracker is at https://github.com/systemd/systemd/issues

Thanks a lot.

Michael


OpenPGP_signature
Description: OpenPGP digital signature

Bug#999677: RFP: popcon-stats-data -- Debian's Popularity Contest statistics

[Paul Wise]

[Forwarded to and CCing the debian-popcon mailing list]

On Sun, 2021-11-14 at 21:43 +0100, Bálint Réczey wrote:

> The shipped data would let package managers show the popularity of
> packages which could let users make more informed decisions when
> choosing between packages to install.
...
> Ideally the stats would be shipped in a format from which APT and
> other package managers could efficiently look up the percentage of
> Debian systems a particular binary package was used.

This package would be very Debian specific and would give the wrong
data when installed in Ubuntu, I think a better approach would be to
ship this data in the Debian apt repository metadata, either in the
Packages files or in Popularity files in the dists/ dir (similar to the
Contents files used by apt-file) so that the data is directly available
to apt clients like aptitude/etc. This way Ubuntu and other derivatives
could also ship popularity data for their users too.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#994556: RFS: cpp-httplib/0.9.7+ds-1 [ITP] -- C++ HTTP/HTTPS server and client library

[Bastian Germann]

FTBFS on i386:

[--] 1 test from ClientProblemDetectionTest
[ RUN  ] ClientProblemDetectionTest.ContentProvider
../test/test.cc:3726: Failure
Value of: success
  Actual: true
Expected: false
[  FAILED  ] ClientProblemDetectionTest.ContentProvider (1002 ms)
[--] 1 test from ClientProblemDetectionTest (1002 ms total)

Apart from that, please do not limit libssl-dev versions. The package will still build with 
libssl-dev v3 (with deprecation warnings) once you just remove the upstream version limit.

Bug#999750: lix FTBFS with ldc 1.28.0

[peter green]

Source: lix
Version: 0.9.29-1.1
Severity: serious
Tags: ftbfs

The attempts to rebuild lix against ldc 1.28.0 failed, on amd64, i386 and armhf 
the build failed with.


/usr/lib/ldc/x86_64-linux-gnu/include/d/std/algorithm/comparison.d(1531,6): 
Warning: skipping definition of function `std.algorithm.comparison.max!(int, 
int).max` due to previous definition for the same mangled name: 
_D3std9algorithm10comparison__T3maxTiTiZQjFNaNbNiNfiiZi
Error: warnings are treated as errors


While on arm64 it failed with

dub build -f -b releaseXDG --cache=local --compiler=ldc2
make[1]: *** [debian/rules:23: override_dh_auto_build] Segmentation fault

Bug#992437: libgetdata8: Patch for CVE-2021-20204 breaks many regression tests

[D. V. Wiebe]

A new version of GetData (0.11.0) has been released to address
CVE-2021-20204:

https://github.com/ketiltrout/getdata/releases/tag/v0.11.0

which I think should solve the underlying problem here, assuing the
current debpatch for the vulnerability can be retired.


signature.asc
Description: PGP signature

Bug#999694: postfix: postconf outputs 2 bounce_notice_recipient lines

[Vincent Lefevre]

Control: tags -1 upstream patch

On 2021-11-15 03:25:10 +0100, Vincent Lefevre wrote:
> zira:~> postconf | grep '^bounce_notice_recipient'
> bounce_notice_recipient = postmaster
> bounce_notice_recipient = postmaster

Attached Wietse Venema's patch from
  https://marc.info/?l=postfix-users&m=163698504624352&w=2

  Bugfix (introduced: 20210708): duplicate bounce_notice_recipient
  entries in postconf output. The fix to send SMTP session
  transcripts to bounce_notice_recipient was incomplete.
  Reported by Vincent Lefevre. File: smtpd/smtpd.c.

I've tested it and everything is OK.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Description: Fix duplicate bounce_notice_recipient entries in postconf output.
 Bug introduced on 2021-07-08. Reported by Vincent Lefevre.
 https://marc.info/?l=postfix-users&m=163698504624352&w=2
Bug-Debian: https://bugs.debian.org/999694
Author: Wietse Venema 
Last-Update: 2021-11-15

Index: postfix-3.5.13/src/smtpd/smtpd.c
===
--- postfix-3.5.13.orig/src/smtpd/smtpd.c
+++ postfix-3.5.13/src/smtpd/smtpd.c
@@ -6419,7 +6419,7 @@ int main(int argc, char **argv)
 	VAR_EOD_CHECKS, DEF_EOD_CHECKS, &var_eod_checks, 0, 0,
 	VAR_MAPS_RBL_DOMAINS, DEF_MAPS_RBL_DOMAINS, &var_maps_rbl_domains, 0, 0,
 	VAR_RBL_REPLY_MAPS, DEF_RBL_REPLY_MAPS, &var_rbl_reply_maps, 0, 0,
-	VAR_BOUNCE_RCPT, DEF_ERROR_RCPT, &var_bounce_rcpt, 1, 0,
+	VAR_BOUNCE_RCPT, DEF_BOUNCE_RCPT, &var_bounce_rcpt, 1, 0,
 	VAR_ERROR_RCPT, DEF_ERROR_RCPT, &var_error_rcpt, 1, 0,
 	VAR_REST_CLASSES, DEF_REST_CLASSES, &var_rest_classes, 0, 0,
 	VAR_CANONICAL_MAPS, DEF_CANONICAL_MAPS, &var_canonical_maps, 0, 0,

Bug#999463: bind9-dyndb-ldap: bind9 will not start with bind9-dyndb-ldap

[Martin Pegler]

Hi team, with a bit more time to diagnose I managed to get bind9 to run with 
the bind9-dyndb-ldap module.
I downloaded the following packages and installed them over the 9.16.22 
versions with no dependency issues or warnings or errors:

bind9_9.16.15-1_amd64.deb

bind9-dnsutils_9.16.15-1_amd64.deb

bind9-host_9.16.15-1_amd64.deb

bind9-libs_9.16.15-1_amd64.deb

bind9utils_9.16.15-1_all.deb

bind9-utils_9.16.15-1_amd64.deb

dnsutils_9.16.15-1_all.deb

If you need me to get any other details or check / test anything else please 
let me know.

 
Kind regards

Martin

Bug#999749: $PATH is reset because of Debian patch

[Jochen Sprickerhof]

Package: fish
Version: 3.3.1+ds-1
Severity: normal
X-Debbugs-Cc: jspri...@debian.org

Hi,

thanks for uploading the new fish version. Sadly it has a regression for
me due to the patch for #985153.
I set $PATH in my ~/.xsession¹ so all fish open below it will get it
from the environment. The patch for #985153 in /etc/fish/config.fish
resets $PATH so this does not work anymore.

You can reproduce the same with:

$ PATH="/tmp:$PATH" fish -c 'echo $PATH'
/usr/local/bin /usr/bin /bin /usr/local/games /usr/games

The patch can be disabled with FISH_UNIT_TESTS_RUNNING=1:

FISH_UNIT_TESTS_RUNNING=1 PATH="/tmp:$PATH" fish -c 'echo $PATH'
/tmp /usr/local/bin /usr/bin /bin /usr/local/games /usr/games

Whereas other shells:

$ PATH=/bin dash -c 'echo $PATH'
/bin
$ PATH=/bin bash -c 'echo $PATH'
/bin

This is because /etc/profile is only read for login shells:

$ PATH=/bin:/usr/bin dash -l -c 'echo $PATH'
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

So we should encapsulate the patch in `if status is-login`.

Also /usr/share/fish/vendor_conf.d is probably a better home then
/etc/fish/config.fish.

I will test this locally tomorrow and upload a new version (due to
LowNMU) if you don't disagree.

Also, the new version is missing the man pages, I will try to recover
them as well.

Cheers Jochen

¹: Actually I set it in ~/.profile and use a variable to make sure it is
only set once but that should not matter for this bug report.

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

Kernel: Linux 5.14.0-4-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 fish depends on:
ii  bc  1.07.1-3+b1
ii  chromium [www-browser]  93.0.4577.82-1
ii  dpkg1.20.9
ii  firefox [www-browser]   94.0-2
ii  fish-common 3.3.1+ds-1
ii  libc6   2.32-4
ii  libpcre2-32-0   10.39-2
ii  libstdc++6  11.2.0-10
ii  libtinfo6   6.3-1
ii  lynx [www-browser]  2.9.0dev.10-1
ii  man-db  2.9.4-2
ii  python3 3.9.7-1
ii  python3-distutils   3.9.8-1
ii  w3m [www-browser]   0.5.3+git20210102-6

Versions of packages fish recommends:
pn  xsel  

Versions of packages fish suggests:
pn  doc-base  

-- no debconf information

Bug#999748: linux: Please enable CONFIG_BT_HCIBTUSB_MTK

[Alberto Garcia]

Source: linux
Version: 5.15.2-1~exp1
Severity: normal

This option is necessary for some USB Bluetooth adapters, such as the
Foxconn / Hon Hai (0489:e0cd) present in some recent ThinkPad models.

Thanks,

Berto

-- System Information:
Debian Release: 11.1
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.15.0-trunk-amd64 (SMP w/16 CPU threads)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#999747: sasview: broken Help links to documentation

[Drew Parsons]

Package: sasview
Version: 5.0.4-1
Severity: normal

The Help menu points to Documentation and Tutorial.

But the link is set to file:///usr/bin/doc/index.html, while the
documentation is located at /usr/share/doc/sasview/html/index.html

Likewise Tutorial points to file:///usr/bin/doc/user/tutorial.html
instead of /usr/share/doc/sasview/html/user/tutorial.html

Bug#996103: debian-edu-config: missing real support for LTSP chroot creation and maintenance

[Wolfgang Schweer]

[ Wolfgang Schweer, 2021-11-12 ]
> I noticed that a wrapper tool is also needed for the new LTSP 'ltsp 
> initrd' command (which generates /srv/tftp/ltsp/ltsp.img for all use 
> cases).
> 
> The Debian Edu LTSP setup (with X2Go thin client support included) needs 
> to use case specific LTSP initrds located in case related directories 
> (as opposed to vanilla LTSP). Updating ltsp.img is eg. needed after the 
> /etc/ltsp/ltsp.conf [clients] section has been modified. This is 
> supposed to be the case for LTSP clients running in real world 
> deployments.
> 
> The tool is now available in Git [1] and should IMO also go into 
> bullseye once tested.

The wrapper script is available in sid (and about to show up in 
bookworm).

Testing all above changes for bullseye (modifications inside d-i) 
revealed that the 'share/debian-edu-config/tools/run-at-firstboot' tool 
needs to be adjusted to make sure the SquashFS image from the server's 
filesystem is generated. The adjusted file is already used for bookworm 
since some time:

diff --git a/share/debian-edu-config/tools/run-at-firstboot 
b/share/debian-edu-config/tools/run-at-firstboot
index 7e3bb335..fa31786d 100755
--- a/share/debian-edu-config/tools/run-at-firstboot
+++ b/share/debian-edu-config/tools/run-at-firstboot
@@ -64,7 +64,7 @@ fi
 # needs to include the krb5.keytab file which isn't available at this time.
 if echo "$PROFILE" | grep -Eq 'Main-Server.*LTSP-Server' && \
[ ! -f /srv/ltsp/images/$ltspimg ] ; then
-   /usr/sbin/debian-edu-ltsp-install --dist $dist
+   /usr/sbin/debian-edu-ltsp-install --diskless_workstation yes
 fi
 
 # Update PXE setup on LTSP servers with proxy values set in environment

Wolfgang


signature.asc
Description: PGP signature

Bug#999745: systemd: `systemd-run --scope --user` fails with 'No PIDs left'

[Michael Biebl]

Control: tags -1 + moreinfo unreproducible

On 15.11.21 23:08, Michał Dominiak wrote:

systemd-run --scope --user tmux


Hm, works fine here.
Can you provide more detailed steps how this can be reproduced.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#985421: Adding DEP8 tests for at package

[Paride Legovini]

Hi,

On Sat, 28 Aug 2021 Jose M Calhariz  wrote:> Now I 
have the repo full updated and I am preparing a new upstream

release of at, with many changes
and bug fixes.  Do you mind to do a MR at salsa?


I just opened a salsa MP cherry-picking Utkarsh's commit:

https://salsa.debian.org/debian/at/-/merge_requests/26/

I testes it locally (via autopkgtest-virt-schroot) and it works fine.

Paride

Bug#999746: shim-signed: Shim seems to fail during startup, but boot continues and modules fail

[Paul Mabileau]

Package: shim-signed
Version: 1.38+15.4-7
Severity: important

Dear Maintainer,

First of all, I am not exactly sure `shim-signed` is the correct package
to report this bug for, but it still seems the most appopriate. Please
do correct it if I am actually wrong.

I currently have this weird problem where my computer initiates the boot
process correctly, but right after the BIOS starts loading my Debian
installation, shim prints quite the amount of messages, then GRUB is
called as per usual and the rest carries on normally, except that no
unsigned and registered kernel modules may be loaded: SecureBoot forbids
it. The details of these messages are available as pictures
[here](https://imgur.com/a/9cBQL6M) -- I couldn't copy-paste by
definition, sorry if it is hard to read. From what I can see among these
logs, I can't really spot any error messages, except for
`LibDeleteVariable("MokSBStateRT", ...) => Not Found` (images 5 and 6).

I am running Debian using a Dell XPS 9560, with UEFI and SecureBoot
activated in the BIOS setup.

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

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

Versions of packages shim-signed depends on:
ii  grub-efi-amd64-bin 2.04-20
ii  grub2-common   2.04-20
ii  shim-helpers-amd64-signed  1+15.4+7
ii  shim-signed-common 1.38+15.4-7

Versions of packages shim-signed recommends:
pn  secureboot-db  

shim-signed suggests no packages.
-- no debconf information

The problem started to occur a few months ago already, when I was still
under Buster but couldn't find much time to investigate this, so I am
not sure exactly when it arose. I remember however seeing an update of
shim in the APT logs around that time, which is consistent with the
release of 1.34 I think I indeed saw in said logs. Before that, things
worked well: I was able to generate certificates, register them with
`mokutil` and sign the modules with them. The modules ran fine and no
messages were printed at startup before GRUB. But when the bug appeared,
suddenly both `mokutil` and `efibootmgr` reported `MokList` and
`MokListRT` as empty while the messages at boot printed some very long
dumps of certificates as if present in the `MokListRT`: it seems as if
the problem deleted some variables which removed the certificates and
thus the modules couldn't be loaded. Trying to register the certificates
again resulted in the same: after rebooting and completing the
registration process, all lists appeared emtpy again.

One of the first things I remember trying was to rollback to an old
version prior to 1.34, but as debs didn't exist anymore and I couldn't
find them anywhere, it was not possible to try this easily, except for
downloading the 1.33 version of the signed files directly from Salsa and
replacing them in the file system. That did not work, but I will have to
try again as things have changed since then. I tried fiddling around
with versions as such for some time, including going forward to 1.38,
but nothing worked. The recent upgrades to Bullseye and Bookworm didn't
change anything either. I then tried to re-install some packages linked
to this or `dpkg-reconfigure` them, in vain. I also tried to disable
SecureBoot in the BIOS setup in order to avoid the problem, but that
didn't work either as something during startup seemed to expect it to be
activated -- the blue screen MOK dialogs: is there something to do on
the Debian side of things as well?

A small step I was able to achieve recently was to discover the
generated inconsistency between what EFI tools reported and what the
boot messages showed. I searched and found the pseudo-files in
`/sys/firmware/efi/mok-variables/` reflecting some system variables such
as `MokListRT`. That one was most definitely not empty and contained the
certificates I was seeing dumped during startup. I then ran `mokutil
--reset`, rebooted and completed the process in order to force a fresh
configuration which helped reduce the length of the logs. The images
show the state after that operation. I couldn't do much more than this,
however.

I will now include the output of some of the EFI tools, starting with:

 * `mokutil --sb-state`: `SecureBoot enabled`
 * `mokutil --list-new`: `MokNew is empty`
 * `mokutil --list-enrolled`: `MokListRT is empty`
 * `mokutil --list-delete`: `MokDel is empty`

Then `efivar -l`:

```
0a602c5b-05a0-40c4-9181-edcd891d0036-SMBIOS_ENTRY_ADDR
8be4df61-93ca-11d2-aa0d-00e098032b8c-BootCurrent
66b36b33-8094-424d-ba45-e876d62c45c1-ePSAVersion
8be4df61-93ca-11d2-aa0d-00e098032b8c-ErrOutDev
8be4df61-93ca-11d2-aa0d-00e098032b8c-BootOptionSupport
8be4df61-93ca-11d2-aa0d-00e098032b8c-PlatformLangCodes
65cbd9d9-ab77-4a61-

Bug#999745: systemd: `systemd-run --scope --user` fails with 'No PIDs left'

[Michał Dominiak]

Package: systemd
Version: 249.6-2
Severity: normal
Tags: upstream

Dear Maintainer,

With systemd 249.6-2, the following command does not work:

> systemd-run --scope --user tmux

It fails and logs the following to the journal:

> run-r18e03cbe0b0b4dc19c9093f94edd6310.scope: No PIDs left to attach to the 
> scope's control group, refusing: Success

This used to work on prior versions of systemd. It also fails in an
identical way with any program that I've tried, including /usr/bin/true.
It works without the `--user` flag.

This appears to be related to this commit in upstream:

https://github.com/systemd/systemd-stable/commit/7ecb1b82d9b55a081d81b2802695fd21293ce029

Thanks,
Michał

-- Package-specific info:

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

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

Versions of packages systemd depends on:
ii  adduser  3.118
ii  libacl1  2.3.1-1
ii  libapparmor1 3.0.3-5
ii  libaudit11:3.0.6-1
ii  libblkid12.37.2-4
ii  libc62.32-4
ii  libcap2  1:2.44-1
ii  libcrypt11:4.4.26-1
ii  libcryptsetup12  2:2.4.1-1
ii  libgcrypt20  1.9.4-3+b1
ii  libgnutls30  3.7.2-2
ii  libgpg-error01.42-3
ii  libip4tc21.8.7-1
ii  libkmod2 29-1
ii  liblz4-1 1.9.3-2
ii  liblzma5 5.2.5-2
ii  libmount12.37.2-4
ii  libpam0g 1.4.0-10
ii  libseccomp2  2.5.2-2
ii  libselinux1  3.3-1
ii  libsystemd0  249.6-2
ii  libzstd1 1.4.8+dfsg-3
ii  mount2.37.2-4
ii  util-linux   2.37.2-4

Versions of packages systemd recommends:
ii  dbus [default-dbus-system-bus]   1.12.20-3
ii  systemd-timesyncd [time-daemon]  249.6-2

Versions of packages systemd suggests:
ii  policykit-10.105-31
ii  systemd-container  249.6-2

Versions of packages systemd is related to:
ii  dracut   051-1
pn  initramfs-tools  
ii  libnss-systemd   249.6-2
ii  libpam-systemd   249.6-2
ii  udev 249.6-2

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

-- no debconf information

Bug#990401: Status

[Ryan Pavlik]

A new upstream release solves this. A package is currently in progress.

Ryan



OpenPGP_signature
Description: OpenPGP digital signature

Bug#999686: added suggested fix

[Gert van de Kraats]

In fact this bug is a problem at wireplumber, not at pipewire-pulse.

Program wireplumber uses config-file

/usr/share/alsa-card-profile/mixer/paths/analog-output-speaker.conf .

Like at pulseaudio the problem can be solved by commenting out thye next 
lines:


; Make sure the internal speakers are not auto-muted once the system has
speakers
[Element Auto-Mute Mode]
enumeration = select

[Option Auto-Mute Mode:Disabled]
name = analog-output-speaker

Bug#999744: wget on 32-bit bullseye systems silently truncates files to 2GB.

[Peter Green]

Package: wget
Severity: important
Version: 1.21-1

When downloading a file greater than 2GB on a 32-bit system wget on bullseye 
will truncate
it to 2GB. No error is reported, the length of the file is simply reported as 
less than it's
true length. This was reported to me by raspberry pi staff, but I can reproduce
it in a Debian i386 environment, so it's not raspberry pi, raspbian or arm 
specific.

I confirmed that the issue did not affect bookworm and after some searching 
found the
upstream commit and bug report that fix it. 
https://gitlab.com/gnuwget/wget/-/commit/90631a6fe54eabd9c80ede5c70bc916719e76cfe

I have applied the patch to the Debian package, built it in a raspbian bullseye 
environment,
tested that the issue is fixed and uploaded the fix to raspbian. I have also 
attatched
a debdiff.

I have rated this issue as important, being unable to download large files (for 
example
OS images) is a significant restriction on the usefulness of wget. There is a 
possible
argument that it deserves grave severity based on "non-serious data loss" (for 
example
if someone used wget to copy a file to another system before deleting the 
original)
but I think that argument is tenuous, so I decided to stick with important.

I believe this issue is important enough to fix in Debian stable. Do you agree 
and if
so do you want to handle the proposed-updates process or should I do it. If I 
get no
response I will start the PU process in a week or so.

diff -Nru wget-1.21/debian/changelog wget-1.21/debian/changelog
--- wget-1.21/debian/changelog  2021-01-02 10:58:25.0 +
+++ wget-1.21/debian/changelog  2021-11-15 20:06:53.0 +
@@ -1,3 +1,9 @@
+wget (1.21-1rpi1) bullseye-staging; urgency=medium
+
+  * Apply upstream patch to fix downloads over 2GB on 32-bit systems.
+
+ -- Peter Michael Green   Mon, 15 Nov 2021 20:06:53 
+
+
 wget (1.21-1) unstable; urgency=medium
 
   * new upstream release from 2020-12-31
diff -Nru wget-1.21/debian/patches/fix-large-downloads-on-32-bit 
wget-1.21/debian/patches/fix-large-downloads-on-32-bit
--- wget-1.21/debian/patches/fix-large-downloads-on-32-bit  1970-01-01 
00:00:00.0 +
+++ wget-1.21/debian/patches/fix-large-downloads-on-32-bit  2021-11-15 
20:06:53.0 +
@@ -0,0 +1,26 @@
+Debian patch based on the upstream commit below, defuzzed
+in the context of the debian package.
+
+commit 90631a6fe54eabd9c80ede5c70bc916719e76cfe
+Author: Tim Rühsen 
+Date:   Sun Apr 11 12:53:16 2021 +0200
+
+* src/wget.h: Use strtoll() for str_to_wgint
+
+This fixes a regression reported at https://savannah.gnu.org/bugs/?60353.
+
+Reported-by: Michal Ruprich
+
+Index: wget-1.21/src/wget.h
+===
+--- wget-1.21.orig/src/wget.h
 wget-1.21/src/wget.h
+@@ -144,7 +144,7 @@ typedef int64_t wgint;
+ #define WGINT_MAX INT64_MAX
+ typedef wgint SUM_SIZE_INT;
+ 
+-#define str_to_wgint strtol
++#define str_to_wgint strtoll
+ 
+ #include "options.h"
+ 
diff -Nru wget-1.21/debian/patches/series wget-1.21/debian/patches/series
--- wget-1.21/debian/patches/series 2019-07-20 16:10:06.0 +
+++ wget-1.21/debian/patches/series 2021-11-15 20:06:53.0 +
@@ -1,3 +1,4 @@
 wget-doc-remove-usr-local-in-sample.wgetrc
 wget-doc-remove-usr-local-in-wget.texi
 wget-passive_ftp-default
+fix-large-downloads-on-32-bit

Bug#984232: status

[Ryan Pavlik]

Upstream has fixed this, and I have a package with the latest upstream
sources in progress, happy to accept help to put it over the edge.

Ryan



OpenPGP_signature
Description: OpenPGP digital signature

Bug#984403: warzone2100 version 3.4.0 to 4.2.1 CMake build problem

[Markus Koschany]

Hi Russell,

is your build problem related to Debian bug #984403 "FTBFS with GCC 11" ?

I don't intend to investigate this problem soon. We need a new upstream version
too. I presume this will fix the current build failures.

Regards,

Markus



#Am Samstag, dem 13.11.2021 um 15:57 +1100 schrieb Russell Coker:
> I've got a build problem with warzone2100 that affects all versions from
> 3.4.0 
> to 4.2.1.  I tried various versions in the hope that I could find out where 
> the error started, but it turns out that it started when CMake started being 
> used.
> 
> /usr/bin/ld: src/CMakeFiles/warzone2100.dir/data.cpp.o: in function 
> `dataAudioCfgLoad(char const*, void**)':
> ./debian/build/../../src/data.cpp:605: undefined reference to 
> `ParseResourceFile(PHYSFS_File*)'
> 
> Above is what seems to be the root cause of the problem, which appears to be 
> due to lib/gamelib/audp_parser.ypp not being compiled due to CMake stuff I 
> don't understand.
> 
> I've attached the debian.tar.xz file for 4.2.1 for anyone who would like to 
> have a go at it.  I could also provide a debian.tar.xz file for 3.4.0 if 
> someone wants to try that (same problem but less disk space and compile
> time).
> 
> 4.2.1 takes 4.5 minutes of elapsed time and 17.5 minutes of CPU time to 
> compile on my workstation (which is moderately fast but a system that is 3* 
> faster is affordable).  3.4.0 takes 3 minutes of elapsed time and 9.5 minutes
> of CPU time.
> 
> Any suggestions would be appreciated.  I can provide an account on a VM with 
> all the dependencies etc installed if that's more convenient (but the VM has
> a 
> single core and will take 9 minutes or 17 minutes to compile).
> 



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

Bug#999743: xfsprogs FTBFS: .gitcensus: No such file or directory

[Adrian Bunk]

Source: xfsprogs
Version: 5.14.0-rc1-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=xfsprogs&ver=5.14.0-rc1-1

...
cat: .gitcensus: No such file or directory
/bin/tar: .gitcensus: Cannot stat: No such file or directory
/bin/tar: Exiting with failure status due to previous errors
gmake[2]: *** [Makefile:187: xfsprogs-5.14.0-rc1.tar.gz] Error 2

Bug#999670: nvidia module parameters NVreg_RegistryDwords is not applied which breaks DDC/CI

[Binay Devkota]

The issue was module renaming,  using nvidia-current fixed the issue. 

Thanks.

On Sun, 14 Nov 2021 20:15:38 +0100 Andreas Beckmann 
wrote:
> On 14/11/2021 17.30, themightydeity wrote:
> > Package: nvidia-driver
> > Version: 470.82.00-1
> > Severity: normal
> > Tags: newcomer
> > X-Debbugs-Cc: themightyde...@gmail.com
> > 
> > As mentioned here: https://www.ddcutil.com/nvidia/ for ddcutil
(DDC/CI) (i2c
> > communication) to work properly in nvidia's proprietary driver.
This conf is
> > needed in modprobe:
> > 
> > options nvidia NVreg_RegistryDwords=RMUseSwI2c=0x01;RMI2cSpeed=100
> 
> You have these settings in /etc/modprobe.d/nvidia-extra.conf
> 
> Please try
>    options nvidia-current key=value...
> Perhaps the options don't get activated because of the module
renaming ...
> 
> I noticed you have a /etc/modules-load.d/nouveau.conf ... does it 
> somehow interfere?
> 
> 
> Andreas
> 
> 

Bug#999741: ITP: sphinxext-opengraph -- Sphinx extension to generate OpenGraph metadata

[Chiara Marmo]

Package: wnpp
Severity: whishlist
X-Debbugs-CC: debian-pyt...@lists.debian.org

   * Package name: sphinxext-opengraph Version : 0.4.2
Upstream Author : Itay Ziv , Dalton Smith
* URL : https://github.com/wpilibsuite/sphinxext-opengraph
  * License : Expat MIT style Programming Lang: Python
Description : Sphinx extension to generate OpenGraph metadata

This Sphinx extension generate OpenGraph metadata (https://ogp.me/) to
enable any web page to become a
rich object in a social graph.
Since scikit-learn 1.0 this extension is a dependency for the
scikit-learn documentation.

Packaging this extension is then necessary to the update of the
scikit-learn package.
I intend to maintain this package in collaboration with Norbert
Preining, and I would like to do it under
the umbrella of the debian python team.

Best regards,

Chiara

Bug#999738: runtime deps on -dev library symlinks not caught

[Felix Lechner]

Hi Bdale,

On Mon, Nov 15, 2021 at 11:06 AM Bdale Garbee  wrote:
>
> Makefile.am ... resulted in binaries ... having
> a run-time dependency on the symlinks provided in the library -dev
> package instead of the ".0" version .. in the
> actual library packages.

Do you have the output of 'readelf --all --wide' [1] for one of those binaries?

I am especially interested in the NEEDED field from the "Dynamic
Section." [2][3] The tag 'undeclared-elf-prerequisites' [4] can
probably be expanded to cover your condition of insufficient
prerequisites (instead of none at all).

Your condition involves sonames that I believe are customarily
provided by links in '-dev' installables instead of regular shared
library packages.

I would adjust that logic there. [5] In particular, I would refine the
conditional:

if @{$item->elf->{NEEDED} // [] }
&& $depends->is_empty;

What do you think, please? Thanks!

Kind regards
Felix Lechner

[1] 
https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Index/Elf.pm#L85
[2] 
https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Index/Elf.pm#L215
[3] 
https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Index/Elf.pm#L445
[4] 
https://salsa.debian.org/lintian/lintian/-/blob/master/tags/u/undeclared-elf-prerequisites.tag
[5] 
https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Check/Binaries/Prerequisites.pm#L108-113

Bug#999739: fai-setup-storage: BTRFS-RAID on NVMe fails to install

[Maximilian Stein]

Package: fai-setup-storage
Version: 5.8.4
Severity: normal
Tags: patch

Dear Maintainer,

I observed an issue trying to setup an BTRFS RAID on NVMe disks. I
have used FAI version 5.8.4, however, I think that the bug is still
present in version 5.10.3.

My disk configuration (I deliberately have the 2nd partition
unconfigured):

disk_config disk1 disklabel:gpt-bios fstabkey:uuid
primary -   32G -   -
primary -   -100%   -   -

disk_config disk2 sameas:disk1

disk_config btrfs fstabkey:uuid
btrfs raid1 /   disk1.1,disk2.1 
rw,degraded,noatime,nodiratime,compress=lzo,subvol=@ createopts="-L root"

Installing this on a machine with two disks /dev/nvme0n1 and
/dev/nvme1n1 terminated with the error:

Cannot satisfy pre-depends for mkfs.btrfs -d raid1 -L root -f   \
/dev/nvme1n1p1 /dev/nvme0n1p1: pt_complete_/dev/nvmen1p1, --\
system left untouched.

Looking into /usr/share/fai/setup-storage/Commands.pm, sub
"build_btrfs_commands", I noticed that line 365 (`$tmp =~ s/\d//;`)
apparently tries to strip the partition number off a partition path.
This is, unfortunately, too simple for these NVMe disks. I changed the
regular expression to only strip the partition no at the end, including
any preceding "p":

$tmp =~ s/p?\d+$//;

At least my system could install successfully with this patch. It
would, however, now fail for "/dev/sdpX", so maybe the regex should
explicitly handle NVMe disks.

Best,
Maximilian

Bug#999738: runtime deps on -dev library symlinks not caught

[Bdale Garbee]

Package: lintian
Severity: wishlist

I've had a couple bugs recently, including 999699, where upstream
Makefile.am content has resulted in binaries delivered in a .deb having
a run-time dependency on the symlinks provided in the library -dev
package instead of the ".0" version of those files provided in the
actual library packages.

It would be nice if lintian were to notice and warn about these cases,
particularly if the -dev package isn't explicitly specified as a binary
package dependency (as it probably shouldn't be in most cases?).

Bdale


signature.asc
Description: PGP signature

Bug#999737: initramfs-tools: root filesystem fails to mount until I "zpool import rpool"

[Ken Teague]

Package: initramfs-tools
Version: 0.140
Severity: normal
X-Debbugs-Cc: kteague+rpool.mount.bug.debian@pobox.com

Dear Maintainer,

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

   * What led up to the situation?
   * Upgrading to linux-kernel-5.10.0-9-amd64
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * During boot, it fails to mount the root filesystem and forces me to
login to single user mode.  "zpool import rpool" followed by CTRL-D allows me
to complete my boot process.  "zpool status" shows bpool but not rpool.
   * I used these instructions (slightly altered for Bullseye) for
installing Debian with ZFS root: https://openzfs.github.io/openzfs-
docs/Getting%20Started/Debian/Debian%20Buster%20Root%20on%20ZFS.html
   * What was the outcome of this action?
   * Workstation boots properly after "zpool import rpool".
   * What outcome did you expect instead?
   * To my recollection, there were previous upgrades of the kernel since
I've installed Bullseye and I didn't have any problems booting to them.


ken@sobo$ uname -a
Linux sobo 5.10.0-9-amd64 #1 SMP Debian 5.10.70-1 (2021-09-30) x86_64 GNU/Linux


ken@sobo$ sudo dkms status
[sudo] password for ken:
zfs, 2.0.3, 5.10.0-8-amd64, x86_64: installed
zfs, 2.0.3, 5.10.0-9-amd64, x86_64: installed


## I think something may be missing here?
## Referencing step 5 listed at https://github.com/openzfs/zfs/issues/10355
## but, then again, my workstation seems to boot without these modules...
ken@sobo$ lsinitramfs /boot/initrd.img-`uname -r` | grep -E '(zfs|spl).ko'
ken@sobo$
## The modules exist
ken@sobo$ ls -l /usr/lib/modules/`uname -r`/updates/dkms
total 3305
-rw-r--r-- 1 root root  501216 Oct  9 09:56 icp.ko
-rw-r--r-- 1 root root  221920 Oct  9 09:56 spl.ko
-rw-r--r-- 1 root root   20616 Oct  9 09:56 zavl.ko
-rw-r--r-- 1 root root  173320 Oct  9 09:56 zcommon.ko
-rw-r--r-- 1 root root 5748128 Oct  9 09:56 zfs.ko
-rw-r--r-- 1 root root  353472 Oct  9 09:56 zlua.ko
-rw-r--r-- 1 root root  180344 Oct  9 09:56 znvpair.ko
-rw-r--r-- 1 root root  342496 Oct  9 09:56 zunicode.ko
-rw-r--r-- 1 root root  723024 Oct  9 09:56 zzstd.ko
## and I can modprobe -i them, but they still don't show up
ken@sobo$ sudo modprobe -i spl
ken@sobo$ sudo modprobe -i zfs
ken@sobo$ lsinitramfs /boot/initrd.img-`uname -r` | grep -E '(zfs|spl).ko'
ken@sobo$


I apologize if this should be submitted to the linux-image package
maintainer(s).  Please let me know if I need to resubmit to them.


-- Package-specific info:
-- initramfs sizes
-rw-r--r-- 1 root root 67M Nov 15 11:32 /boot/initrd.img-5.10.0-8-amd64
-rw-r--r-- 1 root root 67M Nov 15 12:13 /boot/initrd.img-5.10.0-9-amd64
-rw-r--r-- 1 root root 65M Oct  9 09:56 /boot/initrd.img-5.10.0-9-amd64.old-dkms
-- /proc/cmdline
BOOT_IMAGE=/BOOT/debian@/vmlinuz-5.10.0-9-amd64 root=ZFS=/ROOT/debian ro 
root=ZFS=rpool/ROOT/debian

-- resume
RESUME=none
-- /proc/filesystems
fuseblk
vfat
squashfs

-- lsmod
Module  Size  Used by
dm_mod163840  0
rfkill 28672  3
squashfs   69632  16
loop   40960  32
intel_rapl_msr 20480  0
intel_rapl_common  28672  1 intel_rapl_msr
x86_pkg_temp_thermal20480  0
intel_powerclamp   20480  0
coretemp   20480  0
nls_ascii  16384  1
kvm_intel 327680  0
snd_hda_codec_conexant24576  1
snd_hda_codec_generic98304  1 snd_hda_codec_conexant
ledtrig_audio  16384  1 snd_hda_codec_generic
snd_hda_codec_hdmi 73728  2
nls_cp437  20480  1
snd_hda_intel  57344  4
iTCO_wdt   16384  0
snd_intel_dspcfg   28672  1 snd_hda_intel
vfat   20480  1
soundwire_intel45056  1 snd_intel_dspcfg
intel_pmc_bxt  16384  1 iTCO_wdt
fat86016  1 vfat
at24   24576  0
soundwire_generic_allocation16384  1 soundwire_intel
kvm   921600  1 kvm_intel
iTCO_vendor_support16384  1 iTCO_wdt
snd_soc_core  315392  1 soundwire_intel
mei_hdcp   24576  0
watchdog   28672  1 iTCO_wdt
irqbypass  16384  1 kvm
snd_usb_audio 315392  2
snd_compress   32768  1 snd_soc_core
soundwire_cadence  36864  1 soundwire_intel
rapl   20480  0
snd_usbmidi_lib40960  1 snd_usb_audio
dell_wmi   20480  0
snd_hda_codec 172032  4 
snd_hda_codec_generic,snd_hda_codec_conexant,snd_hda_codec_hdmi,snd_hda_intel
intel_cstate   20480  0
snd_hda_core  110592  5 
snd_hda_codec_generic,snd_hda_codec_conexant,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec
snd_rawmidi45056  1 snd_usbmidi_lib
dell_smbios32768  1 dell_wmi
intel_uncore  176128  0
snd_seq_device 16384  1 snd_rawmidi
snd_hwdep  16384  2 snd_usb_audio,snd_hda_codec
dcdbas  

Bug#999682: [Pkg-erlang-devel] Bug#999682: erlang-mode: Broken symlinks in man/man3

[Sebas Olsson]

For full disclosure it's already tracked in this issue.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973885

Best regards

On Mon, 15 Nov 2021 at 16:28, Sebas Olsson  wrote:

> Ah, thank you so much for quick response.
>
> I'll look into manpages-dev and potentially file an issue there instead.
>
> Best regards
>
> On Mon, 15 Nov 2021 at 15:50, Sergei Golovan  wrote:
>
>> Hi Sebastian.
>>
>> On Mon, Nov 15, 2021 at 12:57 AM Sebastian Olsson 
>> wrote:
>> >
>> > Package: erlang-mode
>> > Version: 1:23.2.6+dfsg-1
>> > Severity: normal
>> > X-Debbugs-Cc: vis...@gmail.com
>> >
>> > Dear Maintainer,
>> >
>> > I installed the erlang package on an Debian bullseye docker container
>> to perform the following escript:
>>
>> Erlang packages do not come with these manpages. In fact, erlang-mode
>> just contains a link /usr/lib/erlang/man -> /usr/share/man, so I guess
>> your script just tries to copy all manpages to the container. And it
>> breaks if it can't dereference a link.
>>
>> I'm not sure I can do anything about it. But you're welcome to submit
>> bugs to the packages with these symlinks
>> (/usr/share/man/man3/LIST_EMPTY.3 is in manpages-dev for example).
>>
>> Cheers!
>> --
>> Sergei Golovan
>>
>

Bug#990280: RFS: lg-gpio/0.1.7.0-1 [ITP] -- Control GPIO pins remotely

[Bastian Germann]

Control: tags -1 - moreinfo

New revision available for review.

Bug#999736: RM: rust-tokio-signal -- ROM; uninstallable/unbuildable, superseeded upstream

[peter green]

Package: ftp.debian.org
Severity: normal

rust-tokio-signal depends on an old version of rust-futures and as-such
it's dependencies and build-dependencies are unsatisfiable.

Upstream the features of the tokio-process crate have been integrated into
the tokio crate. The only reverse dependency in Debian is rust-tokio-process
for which I have also filed a removal request.

Bug#999735: RM: rust-tokio-process -- ROM; uninstallable/unbuildable, superseeded upstream, no reverse dependencies.

[plugwash]

Package: ftp.debian.org
Severity: normal

rust-tokio-process depends on an old version of rust-futures and as-such
it's dependencies and build-dependencies are unsatisfiable.

Upstream the features of the tokio-process crate have been integrated into
the tokio crate and here are no reverse dependencies in debian, so it's time
for this package to go.

Bug#999734: RFS: qtractor/0.9.24-1 -- MIDI/Audio multi-track sequencer application

[Dennis Braun]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: qtractor
   Version : 0.9.24-1
   Upstream Author : Rui Nuno Capela 
 * URL : https://qtractor.sourceforge.io/
 * License : other, FSFAP, GPL-2+
 * Vcs : https://salsa.debian.org/multimedia-team/qtractor
   Section : sound

It builds those binary packages:

  qtractor - MIDI/Audio multi-track sequencer application

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/q/qtractor/qtractor_0.9.24-1.dsc

Changes since the last upload:

 qtractor (0.9.24-1) unstable; urgency=medium
 .
   * New upstream version 0.9.24

Regards,
Dennis

Bug#999699: [Pkg-electronics-devel] Bug#999699: Start of lepton-schematic failed

[Bdale Garbee]

tags 999699 +pending
thanks

Bernhard  writes:

> The start of lepton-schematic failed because of missing
> libglib-2.0.so.

The underlying problem is with the way the lepton-eda developers refer
to shared libs in the Makefile.am content in scheme library build
directories.  The side effect is that the binary looks for the name of 
the library as presented in the -dev package, not the actual runtime
binary library.  I'd already found and fixed a couple such bugs, but
upstream hasn't (yet?) changed their approach so I'm carrying the
patches along for now.  It's hard for me to catch these before upload
since I always tend to have the dev libs installed on my laptop which
allows the binaries to work here.  Sorry about that!

In the short term, you can install libglib2.0-dev and things will work.
For the longer term, I've added another patch to to the lepton-eda
Debian package build and will report this case upstream.  Look for
1.9.16-2 to be uploaded shortly.

Bdale


signature.asc
Description: PGP signature

Bug#998210: gst-plugins-good1.0: Stop trying to build wayland support on non-linux architectures

[Samuel Thibault]

Control: tags -1 + patch

Hello,

Laurent Bigonville, le lun. 01 nov. 2021 02:05:19 +0100, a ecrit:
> Since 1.18.5-1, gst-plugins-good1.0 build-depends against
> libqt5waylandclient5-dev, but wayland is linux only, meaning that
> gst-plugins-good1.0 does not build anymore.
> 
> Please mark at least libqt5waylandclient5-dev (and maybe
> qtbase5-private-dev also) as linux-any

I can confirm that the attached patch fixes the issue.

Samuel
--- debian/control.original 2021-11-15 16:52:56.0 +
+++ debian/control  2021-11-15 16:53:02.0 +
@@ -46,7 +46,7 @@
qtbase5-private-dev,
qtdeclarative5-dev,
libqt5x11extras5-dev,
-   libqt5waylandclient5-dev,
+   libqt5waylandclient5-dev [linux-any],
libraw1394-dev (>= 2.0.0) [linux-any],
libiec61883-dev (>= 1.0.0) [linux-any],
libavc1394-dev [linux-any],

Bug#999363: Shouldn't replace pulseaudio by pipewire by default

[Michael Biebl]

On Thu, 11 Nov 2021 13:22:20 +0100 Sebastien Bacher  
wrote:

Hey Dylan, thanks for the reply!

Le 10/11/2021 à 17:56, Dylan Aïssi a écrit :
> I re-added pipewire-media-service as an alternative to wireplumber in
> pipewire Recommends in the last upload 0.3.39-4.
> Could this fix the issue?
It might help some users who are upgrading and already had 
pipewire-media-service installed but isn't really a solution. The first 
option in the recommend is wireplumber so new install will default to 
that one. Also if wireplumber is the recommended session manager letting 
user get it is probably right

> I totally agree, that was not my aim to switch the default sound service.
> Having wireplumber installed without pipewire-pulse is not enough to
> get back pulseaudio as a sound service, we need to modify
> /usr/share/wireplumber/wireplumber.conf
> I am not sure how to correctly handle that. Any suggestion?

No suggestion sorry, I don't know pipewire well enough for that. I tried 
to ask on their IRC channel yesterday, Wim basically suggested that the 
right way to keep pulseaudio in charge of audio was to not load the alsa 
and bluetooth monitors by changing the configuration, maybe that's the 
right thing to do until we decide to make pipewire replace pulseaudio?


Wouldn't it be sufficient to not make wireplumber recommend 
pipewire-pulse resp. demoting it to suggests?


I suppose, if someone (deliberately) installs pipewire-pulse, they want 
pipewire-pulse to replace pulseaudio.

By patching wireplumber you would make this use case harder iiuc?

Bug#994833: OpenCL programs abort when intel-opencl-icd is installed

[Yuri D'Elia]

Is there any progress on the FTBS?

libigc is now at 1.0.8744-2 which breaks 21.32.20609-1, making the icd
uninstallable.

Bug#999733: -fillscreen vs. < and > and 100% zoom

[積丹尼 Dan Jacobson]

Package: xli
Version: 1.17.0+20061110-6

(Not sure where to report this.)
If one uses
$ xli -forall -fillscreen *.jpg
then the < and > keys will never take one to 100%.
They skip over it!

Bug#999731: cryptsetup-suspend: fails to wake up screen after suspend

[Jonas Smedegaard]

Package: cryptsetup-suspend
Version: 2:2.4.1-1
Followup-For: Bug #999731

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Seems reportbug lost the attachment - should be attached here.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmGSmKUACgkQLHwxRsGg
ASFGtA/+ODLA+ekYi/2t8rWNwpjRWhFLC05Gb/NfYX2S5F2PBVjSmQBpmDvGtCWg
7Td82VSfzbhDqmpJQt6poCF8dUoH4cmpZtjORdYCNu2M0GuwWrD35xjQINNuj5BW
DV02y5cvjjAYceCfdD/RDkrTvhQ0r+jAWjTboiCkvpeOpEskEl2uza78y7whQFig
UJD7PdE0gnnPd/ueDOZcpdOOL1wO+HSOtzYF6RBoKCemwY0sh+TzwBT2UlL9yFKB
W/lVHWiuYk9qFHweoo5w6sy3zECao92JYoUamVpfgB0w7z7/nz4hxKc8RssQ1UkX
ulQJHNf21mt4McBoYTe3Aj8IdFwVLriJ96ZlyQmVk3d3o5EVqdJwb21N58C6unp3
PYfHtG4Ie0+fpHum+bIbF+XU9+JmwhgzInMXADbpDXJ4VQ+FZxdYAFB3jUNpuMbI
cizE48cQmejhlRg7vjTkpgWnknsCQhUOlRYB0VUJoDad4xaOeFNVMa7wP6rcuY7N
EAR7iYNjTY88mmsHQEzUSi+QnsNnyDGwFbvkhRX6C5KdDJTgWDjXd6OBKrYaJ9jK
YM37EaljrueGqEBs2L1AsVF3bHVbVwsvAg6u80sQEOsYuJ5s8x8n5yWQ5slzin3K
EZnH74O9sSDBKzml9W4O/A3Y2J9e0CM6ZbprgoNDjgkIVTmFdgs=
=WqVV
-END PGP SIGNATURE-


suspend-fail.gz
Description: application/gzip

Bug#999732: libreoffice-dictionaries: Please adopt hunspell-an

[Agustin Martin]

Source: libreoffice-dictionaries
Version: 1:7.1.0~rc3-3
Severity: important
X-Debbugs-Cc: dm...@hotmail.com

Dear Maintainer,

Please enable hunspell-an build from libreoffice-dictionaries sources.

This was originally requested by Dimitrij Mijoski in #991966 hunspell-an bug
report, I am copying his reasoning,

  Package: hunspell-an

  The current package shows a Firefox extension as Homepage (and probably
  upstream). This is not a very good upstream. The Aragonese dictionary is
  unmaintained (no updates since 2011) and it has no real upstream. It would
  be best to use https://cgit.freedesktop.org/libreoffice/dictionaries/
  as upstream and
  https://packages.debian.org/source/sid/libreoffice-dictionaries as source
  package.

  Why this should be done? Because there are certain bugs with the
  dictionary and the libreoffice repository is the only place where the bug
  can be fixed. I certanly can not fix it in the Firefox extension [1] or
  the Libreoffice extension [2].

  [1]: 
https://addons.mozilla.org/mk/firefox/addon/corrector-ortografico-aragones/
  [2]: 
https://extensions.libreoffice.org/en/extensions/show/corrector-ortografico-aragones

  The LibreOffice extension, the Firefox extension and  the Libreoffice
  collection all provide exactly the same files, no information will be lost
  with this transition.

I read the bug report too quickly and just changed upstream homepage, but
after reading it more carefully I agree with him.

Thanks,

-- 
Agustin

Bug#981350: Closing this bug

[Thomas Goirand]

Hi,

As this is a known problem which IMO should be address upstream, there's
little I can do as a package maintainer, so I'm closing this bug.

Cheers,

Thomas Goirand (zigo)

Bug#999731: cryptsetup-suspend: fails to wake up screen after suspend

[Jonas Smedegaard]

Package: cryptsetup-suspend
Version: 2:2.4.1-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

cryptsetup-suspend looks promising, but unfortunately failed for me so
far on my ARM-based laptop - TERES-I - running an up-to-date bookwork
sytem with with the Wayland-based window-manager Sway: Without
cryptsetup-suspend, waking up leads to screen being backlit-black where
I can either hit ESC and get visual feedback from sway-lock, or
CTRL+ALT+F2 and get a text console; with cryptsetup-suspend installed,
waking up also leads to screen being backlit-black but not responding to
keyboard entry - system is however enough restored that I can power it
down and then examine the journal.

Attached is a log extracted from the journal, where key events are...
 * 16:21:42 power key pressed, resulting in power up
 * 16:21:46 log in to Sway
 * 16:23:00 trigger lid events resulting in deep sleep
 * 16:23:20 trigger lid events resulting in succesful wakeup
 * 16:29:36 install cryptsetup-suspend
 * 16:29:50 trigger lid events resulting in deep sleep
 * 16:30:32 trigger lid events resulting in backlit-but-black screen
 * 16:30:52 power key pressed, resulting in power down


 - Jonas


- -- Package-specific info:
- -- /proc/cmdline
UUID=a58783c9-b793-44e2-86cf-1964a5208d40 ro loglevel=3 console=ttyS0,115200 
console=tty0 clk_ignore_unused

- -- /etc/crypttab
# 
luksroot UUID=a58783c9-b793-44e2-86cf-1964a5208d40 none luks

- -- /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
#
# / was on /dev/mapper/vg_sys-lv_root during installation
UUID=c2411576-7d13-42ee-bdb2-5339f9f5d396 /   ext4
errors=remount-ro   0   1
# /boot was on /dev/mmcblk2p1 during installation
UUID=69cc7768-265f-4176-a131-fe092ef49d9d /boot   ext4defaults  
  0   2
# /home was on /dev/mapper/vg_sys-lv_home during installation
UUID=7aab2183-f9d5-4dec-9037-325b81479a6e /home   ext4defaults  
  0   2
# /tmp was on tmpfs during installation
tmpfs/tmptmpfsdefaults0 0
# /var/tmp was on tmpfs during installation
tmpfs/var/tmptmpfsdefaults0 0
# swap was on /dev/mapper/vg_sys-lv_swap during installation
UUID=763f7ad1-5f58-496f-a258-100aef3ad6c1 noneswapsw
  0   0

- -- lsmod
Module  Size  Used by
snd_seq_dummy  16384  0
snd_hrtimer20480  1
snd_seq90112  7 snd_seq_dummy
snd_seq_device 20480  1 snd_seq
aes_ce_ccm 20480  0
algif_aead 20480  0
algif_skcipher 20480  0
sha512_generic 16384  0
sha512_arm64   20480  0
md416384  0
algif_hash 24576  0
af_alg 28672  3 algif_hash,algif_skcipher,algif_aead
ecb16384  0
r8723bs   557056  0
axp20x_battery 16384  0
axp20x_adc 20480  0
axp20x_ac_power16384  0
industrialio   77824  3 axp20x_battery,axp20x_ac_power,axp20x_adc
des_generic16384  0
axp20x_pek 16384  0
sunxi_cedrus   49152  0
libdes 24576  1 des_generic
v4l2_mem2mem   28672  1 sunxi_cedrus
uvcvideo  110592  0
snd_soc_simple_card24576  1
cfg80211  741376  1 r8723bs
snd_soc_simple_card_utils24576  1 snd_soc_simple_card
videobuf2_dma_contig24576  1 sunxi_cedrus
videobuf2_vmalloc  20480  1 uvcvideo
videobuf2_memops   20480  2 videobuf2_vmalloc,videobuf2_dma_contig
sun50i_codec_analog32768  1
videobuf2_v4l2 24576  3 sunxi_cedrus,uvcvideo,v4l2_mem2mem
sun8i_adda_pr_regmap16384  1 sun50i_codec_analog
lima   65536  2
videobuf2_common   53248  7 
sunxi_cedrus,videobuf2_vmalloc,videobuf2_dma_contig,videobuf2_v4l2,uvcvideo,v4l2_mem2mem,videobuf2_memops
gpu_sched  40960  1 lima
sun4i_i2s  24576  2
sun8i_codec49152  1
rfkill 32768  3 cfg80211
snd_soc_simple_amplifier16384  1
libarc416384  1 r8723bs
sun8i_thermal  16384  0
sunxi_wdt  20480  0
snd_soc_core  204800  6 
sun4i_i2s,sun50i_codec_analog,sun8i_codec,snd_soc_simple_amplifier,snd_soc_simple_card_utils,snd_soc_simple_card
videodev  229376  5 
sunxi_cedrus,videobuf2_v4l2,uvcvideo,videobuf2_common,v4l2_mem2mem
sun8i_ce   32768  0
nvmem_sunxi_sid16384  1
snd_pcm_dmaengine  20480  1 snd_soc_core
crypto_engine  20480  1 sun8i_ce
mc 53248  6 
sunxi_cedrus,videodev,videobuf2_v4l2,uvcvideo,videobuf2_common,v4l2_mem2mem
evdev  32768  13
snd_pcm   114688  4 
sun4i_i2s,sun8i_codec,snd_soc_core,snd_p

Bug#999729: freecad: Reproducible sigsement at create new or open existing file

[Tobias Frost]

Control: severity -1 wishlist
Control: close -1

Hi,

> Distributor ID:   Raspbian
> Description:  Raspbian GNU/Linux 10 (buster)

Raspian is not Debian...

Please report this bug at Raspian or try to reproduce it on a Debian 
installation.
In the latter case, please feel free to reopen the bug.

Thanks.

--
tobi

Bug#999730: mtr: Fix FTBFS with glib2.0 >= 2.70 and deprecated GTimeVal of gtk+2.0

[Lukas Märdian]

Package: mtr
Version: 0.94-2
Severity: serious
Tags: patch ftbfs
Justification: fails to build from source (but built successfully in the past)
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jammy ubuntu-patch
X-Debbugs-Cc: sl...@ubuntu.com

Hi Robert,

mtr fails to build from source, if compiled against glib2.0 >= v2.70, due to 
usage of deprecated GTimeVal in gtk+2.0 headers (that's a dependency of mtr).

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

  * Fix FTBFS with glib >= 2.70 & deprecated definitions of GTimeVal in gtk+2.0


Thanks for considering the patch.

Cheers,
  Lukas

Build log:
gcc -DHAVE_CONFIG_H -I. -I..   -Wdate-time -D_FORTIFY_SOURCE=2 -pthread 
-I/usr/include/gtk-2.0 -I/usr/lib/s390x-linux-gnu/gtk-2.0/include 
-I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/gdk-pixbuf-2.0 
-I/usr/include/libpng16 -I/usr/include/s390x-linux-gnu -I/usr/include/pango-1.0 
-I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/libmount 
-I/usr/include/blkid -I/usr/include/fribidi -I/usr/include/cairo 
-I/usr/include/pixman-1 -I/usr/include/harfbuzz -I/usr/include/glib-2.0 
-I/usr/lib/s390x-linux-gnu/glib-2.0/include -I/usr/include/uuid 
-I/usr/include/freetype2 -I/usr/include/libpng16-g -O2 
-ffile-prefix-map=/<>=. -flto=auto -ffat-lto-objects 
-fstack-protector-strong -Wformat -Werror=format-security -Wall 
-Wno-pointer-sign -c -o ui/mtr-gtk.o `test -f 'ui/gtk.c' || echo '../'`ui/gtk.c
../ui/curses.c: In function ‘mtr_curses_hosts’:
../ui/curses.c:435:17: error: format not a string literal and no format 
arguments [-Werror=format-security]
  435 | printw(fmt_ipinfo(ctl, addr));
  | ^~
../ui/curses.c:488:21: error: format not a string literal and no format 
arguments [-Werror=format-security]
  488 | printw(fmt_ipinfo(ctl, addrs));
  | ^~
../ui/curses.c: In function ‘mtr_curses_graph’:
../ui/curses.c:653:17: error: format not a string literal and no format 
arguments [-Werror=format-security]
  653 | printw(fmt_ipinfo(ctl, addr));
  | ^~
../ui/curses.c: In function ‘mtr_curses_redraw’:
../ui/curses.c:703:5: error: format not a string literal and no format 
arguments [-Werror=format-security]
  703 | mvprintw(1, maxx - 25, iso_time(&t));
  | ^~~~
../ui/curses.c:763:42: error: format not a string literal and no format 
arguments [-Werror=format-security]
  763 | mvprintw(rowstat - 1, startstat, msg);
  |  ^~~
gcc -DHAVE_CONFIG_H -I. -I..   -Wdate-time -D_FORTIFY_SOURCE=2  -g -O2 
-ffile-prefix-map=/<>=. -flto=auto -ffat-lto-objects 
-fstack-protector-strong -Wformat -Werror=format-security -Wall 
-Wno-pointer-sign -c -o packet/packet.o ../packet/packet.c
gcc -DHAVE_CONFIG_H -I. -I..   -Wdate-time -D_FORTIFY_SOURCE=2  -g -O2 
-ffile-prefix-map=/<>=. -flto=auto -ffat-lto-objects 
-fstack-protector-strong -Wformat -Werror=format-security -Wall 
-Wno-pointer-sign -c -o packet/cmdparse.o ../packet/cmdparse.c
gcc -DHAVE_CONFIG_H -I. -I..   -Wdate-time -D_FORTIFY_SOURCE=2  -g -O2 
-ffile-prefix-map=/<>=. -flto=auto -ffat-lto-objects 
-fstack-protector-strong -Wformat -Werror=format-security -Wall 
-Wno-pointer-sign -c -o packet/command.o ../packet/command.c
gcc -DHAVE_CONFIG_H -I. -I..   -Wdate-time -D_FORTIFY_SOURCE=2  -g -O2 
-ffile-prefix-map=/<>=. -flto=auto -ffat-lto-objects 
-fstack-protector-strong -Wformat -Werror=format-security -Wall 
-Wno-pointer-sign -c -o packet/probe.o ../packet/probe.c
In file included from /usr/include/gtk-2.0/gtk/gtkobject.h:37,
 from /usr/include/gtk-2.0/gtk/gtkwidget.h:36,
 from /usr/include/gtk-2.0/gtk/gtkcontainer.h:35,
 from /usr/include/gtk-2.0/gtk/gtkbin.h:35,
 from /usr/include/gtk-2.0/gtk/gtkwindow.h:36,
 from /usr/include/gtk-2.0/gtk/gtkdialog.h:35,
 from /usr/include/gtk-2.0/gtk/gtkaboutdialog.h:32,
 from /usr/include/gtk-2.0/gtk/gtk.h:33,
 from ../ui/gtk.c:31:
/usr/include/gtk-2.0/gtk/gtktypeutils.h:236:1: warning: ‘GTypeDebugFlags’ is 
deprecated [-Wdeprecated-declarations]
  236 | voidgtk_type_init   (GTypeDebugFlagsdebug_flags);
  | ^~~~
In file included from /usr/include/glib-2.0/gobject/gobject.h:24,
 from /usr/include/glib-2.0/gobject/gbinding.h:29,
 from /usr/include/glib-2.0/glib-object.h:22,
 from /usr/include/glib-2.0/gio/gioenums.h:28,
 from /usr/include/glib-2.0/gio/giotypes.h:28,
 from /usr/include/glib-2.0/gio/gio.h:26,
 from /usr/include/gtk-2.0/gdk/gdkapplaunchcontext.h:30,
 from /usr/include/gtk-2.0/gdk/gdk.h:32,
 from /usr/include/gtk-2.0/gtk/gtk.h:32,
 from ../ui/gtk.c:31:
/usr/include/glib-2.0/gobject/gtype.

Bug#998718: Brasero fails (on Testing) burning an ISO image on a CD-RW

[Thomas Schmitt]

Hi,

i wrote:
> > My only idea which does not need a code change is to employ the wodim
> > plugin of Brasero and to hope that it burns by write type SAO.

Mauro Sacchetto wrote:
> Which way?

Good question.
I have wodim installed. But last time when i tried, the wodim item was
greyed out in the plugin list window which i somehow managed to pop up.

Google brings me to
  https://github.com/lmedinas/brasero
which in "Notes on plugins for advanced users" proposes to remove
libburn (bleh !) or to use something named Gconf for changing plugin
priorities.
Wikipedia says: "GConf was a system used by the GNOME desktop".

The riddle remains, i fear.


Have a nice day :)

Thomas

Bug#983421: init-system-helpers: please respect DPKG_ROOT when checking for /usr/sbin/policy-rc.d

[Johannes Schauer Marin Rodrigues]

Quoting Johannes Schauer Marin Rodrigues (2021-11-15 10:28:49)
> > This is the test I'd like. More precisely, that the tools are doing what
> > they are supposed to do.
> 
> I see that the test suite is using an unpackaged Perl module and requires root
> to execute. I can rewrite the testsuite to be runnable without root and to not
> require that unpackaged Perl module. Would you like me to do that? Then I'd
> first file a merge request for the improved test suite and then rebase my
> DPKG_ROOT patch on top of that once you are satisfied with the testsuite
> improvements.

https://salsa.debian.org/debian/init-system-helpers/-/merge_requests/17

If you like those changes, I can rebase the DPKG_ROOT patch on top of it and
run the entire test suite with DPKG_ROOT enabled instead of fakechroot.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#999590: pkg_resources.DistributionNotFound: The 'contextvars' distribution was not found and is required by salt

[Benjamin Drung]

Am Freitag, dem 12.11.2021 um 17:14 -0500 schrieb David Mandelberg:
> Package: salt-common
> Version: 3004+dfsg1-2
> 
> When I run `sudo salt-call state.apply` I get two tracebacks, both 
> ending in the line below.
> 
> pkg_resources.DistributionNotFound: The 'contextvars' distribution
> was 
> not found and is required by salt
> 
> Upstream has a bug with more information: 
> https://github.com/saltstack/salt/issues/60483

I cannot reproduce this issue on unstable, since Python 3.9 provides
the contextvars module. What setup do you have and what Python version?

-- 
Benjamin Drung

Senior DevOps Engineer and Debian & Ubuntu Developer
Compute Platform Operations Cloud

IONOS SE | Revaler Str. 30 | 10245 Berlin | Deutschland
E-Mail: benjamin.dr...@ionos.com | Web: www.ionos.de

Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498

Vorstand: Hüseyin Dogan, Dr. Martin Endreß, Claudia Frese, Henning
Kettler, Arthur Mai, Britta Schmidt, Achim Weiß
Aufsichtsratsvorsitzender: Markus Kadelke


Member of United Internet

Bug#999729: freecad: Reproducible sigsement at create new or open existing file

[pi]

Package: freecad
Version: 0.18~pre1+dfsg1-5+rpi1
Severity: important

Dear Maintainer,

install on RaspberryPi 4 freecad.
Start freecad
Create new file crashes freecad with:

Coin warning in cc_glglue_instance(): Error when setting up the GL context. 
This can happen if there is no current context, or if the context has been set 
up incorrectly.
Program received signal SIGSEGV, Segmentation fault.
#0  /lib/arm-linux-gnueabihf/libc.so.6(__default_sa_restorer+0) [0xb33e4110]


-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux 10 (buster)
Release:10
Codename:   buster
Architecture: armv7l

Kernel: Linux 5.10.63-v7l+ (SMP w/4 CPU cores)
Kernel taint flags: TAINT_CRAP
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to de_DE.UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to de_DE.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages freecad depends on:
ii  freecad-python2  0.18~pre1+dfsg1-5+rpi1
ii  freecad-python3  0.18~pre1+dfsg1-5+rpi1

Versions of packages freecad recommends:
pn  calculix-ccx  
pn  graphviz  

Versions of packages freecad suggests:
pn  freecad-doc 
pn  povray  
pn  python-collada  

-- no debconf information

Bug#999682: [Pkg-erlang-devel] Bug#999682: erlang-mode: Broken symlinks in man/man3

[Sebas Olsson]

Ah, thank you so much for quick response.

I'll look into manpages-dev and potentially file an issue there instead.

Best regards

On Mon, 15 Nov 2021 at 15:50, Sergei Golovan  wrote:

> Hi Sebastian.
>
> On Mon, Nov 15, 2021 at 12:57 AM Sebastian Olsson 
> wrote:
> >
> > Package: erlang-mode
> > Version: 1:23.2.6+dfsg-1
> > Severity: normal
> > X-Debbugs-Cc: vis...@gmail.com
> >
> > Dear Maintainer,
> >
> > I installed the erlang package on an Debian bullseye docker container to
> perform the following escript:
>
> Erlang packages do not come with these manpages. In fact, erlang-mode
> just contains a link /usr/lib/erlang/man -> /usr/share/man, so I guess
> your script just tries to copy all manpages to the container. And it
> breaks if it can't dereference a link.
>
> I'm not sure I can do anything about it. But you're welcome to submit
> bugs to the packages with these symlinks
> (/usr/share/man/man3/LIST_EMPTY.3 is in manpages-dev for example).
>
> Cheers!
> --
> Sergei Golovan
>

Bug#995339: Clarify complete d/copyright vs extra custom header for applicable licenses

[Bastian Germann]

Just to make the case a bit stronger: There are packages in the archive that neither have a complete d/copyright nor a 
custom header in this regard. To name an example: glslang-dev is a build dependency of vulkan-validationlayers and 
renderdoc. Their licenses do not require a Built-Using. Having vulkan-validationlayers or renderdoc installed does not 
give you any hint that glslang-dev's distribution license also applies. If you want to know that you have to look at the 
source package.

Bug#998662: picocli: Please update to newer upstream version >= 4.6.1

[tony mancill]

On Fri, Nov 05, 2021 at 09:49:47PM +, Jonathan Dowland wrote:
> Source: picocli
> Version: 3.9.6-3
> Severity: normal
> 
> I'd like to package some software that depends upon the picocli
> API from 4.x onwards (specifically the latest upstream version
> 4.6.1, I haven't experimented to see whether I could get away
> with earlier 4.x versions). 3.9.6 is too old for this software.
> Please consider updating the Debian package.

Hello Jonathan,

Thank you for the bug report.  Please excuse long response time.  I
started the  of updating picocli a while back but got side-tracked.  I
will resume that effort.

Cheers,
tony

Bug#999728: RFP: mepo -- Fast, simple, and hackable OSM map viewer for Linux

[Antoine Beaupre]

Package: wnpp
Severity: wishlist

* Package name: mepo
  Version : 0.1
  Upstream Author : Miles Alan
* URL : https://sr.ht/~mil/Mepo/
* License : GPL-3+
  Programming Lang: Zig
  Description : Fast, simple, and hackable OSM map viewer for Linux

Mepo is a fast, simple, and hackable OSM map viewer for desktop linux
& mobile linux devices (like the Pinephone, Librem 5 etc.) and both
environment's various user interfaces (Wayland & X inclusive). Mepo
works both offline and online, features a minimalist both touch/mouse
and keyboard compatible interface, and offers a UNIX-philosophy
inspired underlying design, exposing a powerful command language
called mepolang capable of being scripted to provide things like
custom bounding-box search scripts, bookmarks, and more.

Bug#999695: systemd: emergency/rescue targets fail to stop journald

[Michael Biebl]

Am 15.11.21 um 03:44 schrieb westlake:
Upon booting up with "systemd.unit=emergency.target" to the kernel 
bootline, there are no systemd-journald services running.


I'd say this is expected, as sockets.target is not started. See below

However if the user boots normally into multi-user or graphical targets, 
and types "systemctl isolate emergency" or "systemctl emergency", debian 
does not stop systemd-journald services.




I think, what you see is that systemd-journald.service *is* actually 
stopped when you run `systemctl emergency`.

But systemd-journald.service is socket activated.
So there might be a race condition or a problem with the corresponding 
systemd-journald sockets:


$ systemctl show -P TriggeredBy systemd-journald.service
systemd-journald-audit.socket systemd-journald-dev-log.socket 
systemd-journald.socket


Could you check the following:
- When you enter the emergency shell, check the journal if 
systemd-journald.service has been stopped (and started again)

- If any of the above sockets are active?

In any case, this doesn't appear to be a Debian specific issue, so I 
would kindly ask you to file this upstream at


https://github.com/systemd/systemd and report back with the issue number.


Regards,
Michael

Bug#999693: php8.1: Regular expression functions warn "Compilation failed" and return null

[Matthew Vernon]

Hi,

On 15/11/2021 14:34, Ondřej Surý wrote:


This appears when built with 10.39, but the runtime version is less than that. 
My guess is that this needs manual debian/libpcre2-8.shlibs override. (Or just 
mangle the symbols file, so it always generates correct versioned dependency.)


I've had a look at the Changelog from 10.36 (previous packaged version), 
and there's nothing obvious there.


Is it possible to work out what is happening lower down the stack to 
cause this error message? I don't feel I have something I can even refer 
to upstream yet...


Thanks,

Matthew

Bug#999682: [Pkg-erlang-devel] Bug#999682: erlang-mode: Broken symlinks in man/man3

[Sergei Golovan]

Hi Sebastian.

On Mon, Nov 15, 2021 at 12:57 AM Sebastian Olsson  wrote:
>
> Package: erlang-mode
> Version: 1:23.2.6+dfsg-1
> Severity: normal
> X-Debbugs-Cc: vis...@gmail.com
>
> Dear Maintainer,
>
> I installed the erlang package on an Debian bullseye docker container to 
> perform the following escript:

Erlang packages do not come with these manpages. In fact, erlang-mode
just contains a link /usr/lib/erlang/man -> /usr/share/man, so I guess
your script just tries to copy all manpages to the container. And it
breaks if it can't dereference a link.

I'm not sure I can do anything about it. But you're welcome to submit
bugs to the packages with these symlinks
(/usr/share/man/man3/LIST_EMPTY.3 is in manpages-dev for example).

Cheers!
-- 
Sergei Golovan

Bug#998718: Brasero fails (on Testing) burning an ISO image on a CD-RW

[Mauro Sacchetto]

Il 15/11/21 14:58, Thomas Schmitt ha scritto:

My only idea which does not need a code change is to employ the wodim
plugin of Brasero and to hope that it burns by write type SAO.
If so, then the drive would not get lost after a successful burn run.



Which way?
Thanx!
m

Bug#924139: OVAL python3

[Sébastien Delafond]

With https://salsa.debian.org/webmaster-team/webwml/-/merge_requests/737
now merged, python3 support is in
https://salsa.debian.org/webmaster-team/webwml/-/merge_requests/740. I'll
open an RT ticket to get
https://salsa.debian.org/seb/debian.org/-/commit/72fbf295abfd042835ce786344a13bcf8a81148b
included so python3-lxml is available on the server side.

Bug#999693: php8.1: Regular expression functions warn "Compilation failed" and return null

[Matthew Vernon]

Hi,

On 15/11/2021 14:03, Ondřej Surý wrote:
It’s still a bug, but I think it might be a bug in pcre2. The other 
Matthew (in CC) might need to bump the shlibs on the shared lib to >= 10.39


I'm slightly confused - this appears to be an issue in a php function 
that went away after an upgrade? Or, at least, I'm not sure what you are 
suggesting needs changing...


[the .symbols files are automatically checked during build]

Regards,

Matthew

Bug#999693: php8.1: Regular expression functions warn "Compilation failed" and return null

[Ondřej Surý]

This appears when built with 10.39, but the runtime version is less than that. 
My guess is that this needs manual debian/libpcre2-8.shlibs override. (Or just 
mangle the symbols file, so it always generates correct versioned dependency.)

We can also as upstream, perhaps this is something that should be solved there?

Ondřej 
--
Ondřej Surý  (He/Him)

> On 15. 11. 2021, at 15:17, Matthew Vernon  wrote:
> 
> Hi,
> 
>> On 15/11/2021 14:03, Ondřej Surý wrote:
>> It’s still a bug, but I think it might be a bug in pcre2. The other Matthew 
>> (in CC) might need to bump the shlibs on the shared lib to >= 10.39
> 
> I'm slightly confused - this appears to be an issue in a php function that 
> went away after an upgrade? Or, at least, I'm not sure what you are 
> suggesting needs changing...
> 
> [the .symbols files are automatically checked during build]
> 
> Regards,
> 
> Matthew

Bug#998565: Errors due to changes in iso-codes data

[Stuart Prescott]

Hi Scott & Tobias

On Monday, 15 November 2021 21:13:09 AEDT Dr. Tobias Quathamer wrote:
> On Sun, 14 Nov 2021 20:30:06 -0500 Scott Kitterman 
> 
> wrote:
> > I looked at this a bit today and it looks like the test failures are due
> > to
> > updates in the iso-codes data used by the tests, not any real failures.  I
> > think disabling the failing tests for now would be a reasonable way to
> > keep
> > this in testing (I'm interested to avoid transitive removal of xml2rfc).
> > 
> > Unless there's some objection to this, I will probably NMU later in the
> > week.
> > 
> > Scott K
> 
> Hi Scott,
> 
> iso-codes maintainer here -- I've just seen this bug and your mail. Your
> analysis is correct, from my point of view, you should go ahead with the
> NMU.

The tests look easy enough to fix, so it's worth trying to do that. (and it's 
in the Debian group on salsa to make that easy :)

I'm a bit surprised by some of the data changes though -- apparently England 
is no longer a part of the UK. Yes, that's quite complicated, but the 
ISO-3166-2 info does still list ENG and EAW. As the pycountry tests highlight, 
those divisions disappeared from iso_3166-2.json with the switch over to a 
different data harvester.

https://www.iso.org/obp/ui/#iso:code:3166:GB 

Is that correct and intended?

cheers
Stuart


-- 
Stuart Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

Bug#999727: freerdp2: Latest version contains security fixes

[Stephen Quinney]

Source: freerdp2
Severity: important
X-Debbugs-Cc: step...@jadevine.org.uk

The latest version of the freerdp software (2.4.1) which was released
a few weeks ago contains important fixes for two security issues:

CVE-2021-41159: Improper client input validation for gateway connections allows 
to overwrite memory

CVE-2021-41160: Improper region checks in all clients allow out of bound write 
to memory


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

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

Bug#990316: Add GLFW_IM_MODULE=fcitx on ibus and fcitx5 to enable IME in kitty

[Gunnar Hjalmarsson]

Control: tag -1 patch

Thanks for your patch, Chen Shijie. As Osamu said, adding that variable 
would be trivial and without a risk to affect other applications.


Reading  makes me still 
hesitate, though. If I understand it correctly, the principal kitty 
developer has intentionally not enabled IME input by default due to 
claimed efficiency issues and bugs.


im-config works the other way around. As soon as some input method 
framework such as IBus or fcitx5 is installed, im-config sets the 
related variables and launches the daemon. And it does so by default.


In the light of that, I'm wondering if letting im-config set 
GLFW_IM_MODULE is the right thing to do.


--
Regards,
Gunnar Hjalmarsson

Bug#999693: php8.1: Regular expression functions warn "Compilation failed" and return null

[Ondřej Surý]

It’s still a bug, but I think it might be a bug in pcre2. The other Matthew (in 
CC) might need to bump the shlibs on the shared lib to >= 10.39

--
Ondřej Surý  (He/Him)

> On 15. 11. 2021, at 14:54, Matthew Krauss  wrote:
> 
> After running apt upgrade, it works fine. I honestly thought I had upgraded 
> everything earlier, but had somehow missed doing that one machine. Very 
> embarrassing, sorry for the waste of time!
> 
> Sent from Yahoo Mail on Android
> 
> On Mon, Nov 15, 2021 at 2:04 AM, Ondřej Surý
>  wrote:
> Hi,
> 
> is your system fully upgraded?
> 
> What’s libpcre2 version?
> 
> Ondřej
> --
> Ondřej Surý  (He/Him)
> 
> > On 15. 11. 2021, at 2:51, Matthew Krauss  wrote:
> > 
> > Package: php8.1-common
> > Version: 8.1.0~rc5-1
> > Severity: grave
> > Justification: renders package unusable
> > X-Debbugs-Cc: zeros0and1o...@yahoo.com
> > 
> > Dear Maintainer,
> > 
> > After installing php8.1 on testing, I found that most PHP packages are
> > failing. For instance, composer, whether installed directly from
> > getcomposer.org, or through the Debian package, is broken by this bug,
> > as well as likely the vast majority of PHP based software.
> > 
> > The problem seems to be in an underlying regexp library, I *think*,
> > and seems to break most of the built in php regexp functions.
> > 
> > Simple demonstration, with both php7.4 and php8.1 installed:
> > 
> > $ php7.4 -r 'var_export(preg_replace("/foo/", "bar", "some foo here")); 
> > echo "\ndone\n";'
> > 'some bar here'
> > done
> > 
> > $ php8.1 -r 'var_export(preg_replace("/foo/", "bar", "some foo here")); 
> > echo "\ndone\n";'
> > PHP Warning:  preg_replace(): Compilation failed: unrecognised compile-time 
> > option bit(s) at offset 0 in Command line code on line 1
> > NULL
> > done
> > 
> > The php7.4 command runs correctly and is what I would expect. The php8.1 
> > command generates a warning, as well as incorrect output.
> > 
> > 
> > -- System Information:
> > Debian Release: bookworm/sid
> >  APT prefers testing
> >  APT policy: (500, 'testing')
> > Architecture: amd64 (x86_64)
> > 
> > Kernel: Linux 5.4.0-4-amd64 (SMP w/2 CPU threads)
> > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE 
> > not set
> > Shell: /bin/sh linked to /bin/dash
> > Init: systemd (via /run/systemd/system)
> > LSM: AppArmor: enabled
> > 
> > Versions of packages php8.1 depends on:
> > ii  libapache2-mod-php8.1  8.1.0~rc5-1
> > ii  php8.1-common  8.1.0~rc5-1
> > 
> > php8.1 recommends no packages.
> > 
> > php8.1 suggests no packages.
> > 
> > Versions of packages php8.1-common depends on:
> > ii  libc6  2.31-17
> > ii  libffi83.4.2-3
> > ii  libssl1.1  1.1.1l-1
> > ii  php-common  2:76
> > ii  ucf3.0043
> > 
> > -- no debconf information
> > 
> 

Bug#999726: ruby-omniauth-shibboleth: FTBFS with ruby-omniauth 2.0.x: ERROR: Test "ruby2.7" failed: Failure/Error: expect(last_response.status).to eq(302)

[Antonio Terceiro]

Source: ruby-omniauth-shibboleth
Version: 1.3.0-1
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby-omniauth-2.0

Hi,

I would like to upload ruby-omniauth 2.0.4 to unstable soon. During a test
rebuild, ruby-omniauth-shibboleth was found to fail to build in that situation.

To reproduce this locally, you need to install ruby-omniauth from experimental
on an unstable system or build chroot. I would expect a new upstream version to
work against the latest ruby-omniauth just fine.

Relevant part (hopefully):
>  Failure/Error: expect(last_response.status).to eq(302)
> 
>expected: 302
> got: 200
> 
>(compared using ==)
>  # ./spec/omniauth/strategies/shibboleth_spec.rb:42:in `block (3 levels) 
> in '
> 
> Finished in 0.06473 seconds (files took 0.14061 seconds to load)
> 16 examples, 1 failure
> 
> Failed examples:
> 
> rspec ./spec/omniauth/strategies/shibboleth_spec.rb:41 # 
> OmniAuth::Strategies::Shibboleth request phase is expected to redirect to 
> callback_url
> 
> /usr/bin/ruby2.7 
> -I/usr/share/rubygems-integration/all/gems/rspec-support-3.9.3/lib:/usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/lib
>  /usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/exe/rspec 
> --pattern ./spec/\*\*/\*_spec.rb --format documentation failed
> ERROR: Test "ruby2.7" failed: 


The full build log is available at
https://people.debian.org/~terceiro/rebuilds/ruby-omniauth-2.0/ruby-omniauth-shibboleth.log


signature.asc
Description: PGP signature

Bug#999725: ruby-omniauth-saml: FTBFS with ruby-omniauth 2.0.x: ERROR: Test "ruby2.7" failed: /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1404:in `rescue in block in activate_dependencies': Co

[Antonio Terceiro]

Source: ruby-omniauth-saml
Version: 1.10.0-1
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby-omniauth-2.0

Hi,

I would like to upload ruby-omniauth 2.0.4 to unstable soon. During a test
rebuild, ruby-omniauth-saml was found to fail to build in that situation.

To reproduce this locally, you need to install ruby-omniauth from experimental
on an unstable system or build chroot. I would expect a new upstream version to
work against the latest ruby-omniauth just fine.

Relevant part (hopefully):
> /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1404:in `rescue in block 
> in activate_dependencies': Could not find 'omniauth' (~> 1.3, >= 1.3.2) among 
> 77 total gem(s) (Gem::MissingSpecError)
> Checked in 
> 'GEM_PATH=/<>/debian/ruby-omniauth-saml/usr/share/rubygems-integration/all:/var/lib/gems/2.7.0:/usr/local/lib/ruby/gems/2.7.0:/usr/lib/ruby/gems/2.7.0:/usr/lib/x86_64-linux-gnu/ruby/gems/2.7.0:/usr/share/rubygems-integration/2.7.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0'
>  at: 
> /<>/debian/ruby-omniauth-saml/usr/share/rubygems-integration/all/specifications/omniauth-saml-1.10.0.gemspec,
>  execute `gem env` for more information
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1401:in `block 
> in activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in `each'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in 
> `activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1372:in 
> `activate'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `block in gem'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `synchronize'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `gem'
>   from -e:1:in `'
> /usr/lib/ruby/vendor_ruby/rubygems/dependency.rb:313:in `to_specs': Could not 
> find 'omniauth' (~> 1.3, >= 1.3.2) - did find: [omniauth-2.0.4] 
> (Gem::MissingSpecVersionError)
> Checked in 
> 'GEM_PATH=/<>/debian/ruby-omniauth-saml/usr/share/rubygems-integration/all:/var/lib/gems/2.7.0:/usr/local/lib/ruby/gems/2.7.0:/usr/lib/ruby/gems/2.7.0:/usr/lib/x86_64-linux-gnu/ruby/gems/2.7.0:/usr/share/rubygems-integration/2.7.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0'
>  , execute `gem env` for more information
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1402:in `block 
> in activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in `each'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in 
> `activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1372:in 
> `activate'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `block in gem'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `synchronize'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `gem'
>   from -e:1:in `'
> benchmark (default: 0.1.0)
> bigdecimal (default: 2.0.0)
> bundler (default: 2.1.4)
> cgi (default: 0.1.0)
> csv (default: 3.1.2)
> date (default: 3.0.0)
> dbm (default: 1.1.0)
> delegate (default: 0.1.0)
> did_you_mean (default: 1.4.0)
> diff-lcs (1.4.4)
> docile (1.1.5)
> etc (default: 1.1.0)
> fcntl (default: 1.0.0)
> fiddle (default: 1.0.0)
> fileutils (default: 1.4.1)
> forwardable (default: 1.3.1)
> gdbm (default: 2.1.0)
> getoptlong (default: 0.1.0)
> hashie (3.5.5)
> io-console (default: 0.5.6)
> ipaddr (default: 1.2.2)
> irb (default: 1.2.6)
> json (default: 2.3.0)
> logger (default: 1.4.2)
> macaddr (1.7.1)
> matrix (default: 0.2.0)
> minitest (5.13.0)
> mutex_m (default: 0.1.0)
> net-pop (default: 0.1.0)
> net-smtp (default: 0.1.0)
> net-telnet (0.1.1)
> nokogiri (1.11.7)
> observer (default: 0.1.0)
> omniauth (2.0.4)
> open3 (default: 0.1.0)
> openssl (default: 2.1.2)
> ostruct (default: 0.2.0)
> pkg-config (1.4.6)
> power_assert (1.1.7)
> prime (default: 0.1.1)
> pstore (default: 0.1.0)
> psych (default: 3.1.0)
> racc (default: 1.4.16)
> rack (2.1.4)
> rack-protection (2.0.8.1)
> rack-test (0.7.0)
> rake (13.0.3)
> rdoc (default: 6.2.1.1)
> readline (default: 0.0.2)
> readline-ext (default: 0.1.0)
> reline (default: 0.1.5)
> rexml (default: 3.2.3.1)
> rspec (3.9.0)
> rspec-core (3.9.2)
> rspec-expectations (3.9.2)
> rspec-mocks (3.9.1)
> rspec-support (3.9.3)
> rss (default: 0.2.8)
> ruby-saml (1.13.0)
> rubygems-update (3.2.27)
> sdbm (default: 1.0.0)
> simplecov (0.19.1)
> simplecov-html (0.12.3)
> singleton (default: 0.1.0)
> stringio (default: 0.1.0)
> strscan (default: 1.0.3)
> systemu (2.6.5)
> test-unit (3.3.9)
> timeout (default: 0.1.0)
> tracer (default: 0.1.0)
> uri (default: 0.10.0)
> uuid (2.3.9)
> webrick (default: 1.6.1)
> xmlrpc (0.3.2)
> yaml (default: 0.1.0)

Bug#999724: ruby-omniauth-salesforce: FTBFS with ruby-omniauth 2.0.x: ERROR: Test "ruby2.7" failed: /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1404:in `rescue in block in activate_dependencie

[Antonio Terceiro]

Source: ruby-omniauth-salesforce
Version: 1.0.5-2
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby-omniauth-2.0

Hi,

I would like to upload ruby-omniauth 2.0.4 to unstable soon. During a test
rebuild, ruby-omniauth-salesforce was found to fail to build in that situation.

To reproduce this locally, you need to install ruby-omniauth from experimental
on an unstable system or build chroot. I would expect a new upstream version to
work against the latest ruby-omniauth just fine.

Relevant part (hopefully):
> /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1404:in `rescue in block 
> in activate_dependencies': Could not find 'omniauth' (~> 1.0) among 85 total 
> gem(s) (Gem::MissingSpecError)
> Checked in 
> 'GEM_PATH=/<>/debian/ruby-omniauth-salesforce/usr/share/rubygems-integration/all:/var/lib/gems/2.7.0:/usr/local/lib/ruby/gems/2.7.0:/usr/lib/ruby/gems/2.7.0:/usr/lib/x86_64-linux-gnu/ruby/gems/2.7.0:/usr/share/rubygems-integration/2.7.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0'
>  at: 
> /<>/debian/ruby-omniauth-salesforce/usr/share/rubygems-integration/all/specifications/omniauth-salesforce-1.0.5.gemspec,
>  execute `gem env` for more information
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1401:in `block 
> in activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in `each'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in 
> `activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1372:in 
> `activate'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `block in gem'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `synchronize'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `gem'
>   from -e:1:in `'
> /usr/lib/ruby/vendor_ruby/rubygems/dependency.rb:313:in `to_specs': Could not 
> find 'omniauth' (~> 1.0) - did find: [omniauth-2.0.4] 
> (Gem::MissingSpecVersionError)
> Checked in 
> 'GEM_PATH=/<>/debian/ruby-omniauth-salesforce/usr/share/rubygems-integration/all:/var/lib/gems/2.7.0:/usr/local/lib/ruby/gems/2.7.0:/usr/lib/ruby/gems/2.7.0:/usr/lib/x86_64-linux-gnu/ruby/gems/2.7.0:/usr/share/rubygems-integration/2.7.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0'
>  , execute `gem env` for more information
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1402:in `block 
> in activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in `each'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in 
> `activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1372:in 
> `activate'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `block in gem'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `synchronize'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `gem'
>   from -e:1:in `'
> addressable (2.8.0)
> benchmark (default: 0.1.0)
> bigdecimal (default: 2.0.0)
> bundler (default: 2.1.4)
> cgi (default: 0.1.0)
> crack (0.4.4)
> csv (default: 3.1.2)
> date (default: 3.0.0)
> dbm (default: 1.1.0)
> delegate (default: 0.1.0)
> did_you_mean (default: 1.4.0)
> diff-lcs (1.4.4)
> docile (1.1.5)
> etc (default: 1.1.0)
> faraday (1.1.0)
> fcntl (default: 1.0.0)
> fiddle (default: 1.0.0)
> fileutils (default: 1.4.1)
> forwardable (default: 1.3.1)
> gdbm (default: 2.1.0)
> getoptlong (default: 0.1.0)
> hashdiff (1.0.1)
> hashie (3.5.5)
> io-console (default: 0.5.6)
> ipaddr (default: 1.2.2)
> irb (default: 1.2.6)
> json (default: 2.3.0)
> jwt (2.2.2)
> logger (default: 1.4.2)
> matrix (default: 0.2.0)
> minitest (5.13.0)
> multi_json (1.14.1)
> multi_xml (0.6.0)
> multipart-post (2.0.0)
> mutex_m (default: 0.1.0)
> net-pop (default: 0.1.0)
> net-smtp (default: 0.1.0)
> net-telnet (0.1.1)
> oauth2 (1.4.4)
> observer (default: 0.1.0)
> omniauth (2.0.4)
> omniauth-oauth2 (1.7.1)
> open3 (default: 0.1.0)
> openssl (default: 2.1.2)
> ostruct (default: 0.2.0)
> power_assert (1.1.7)
> prime (default: 0.1.1)
> pstore (default: 0.1.0)
> psych (default: 3.1.0)
> public_suffix (4.0.6)
> racc (default: 1.4.16)
> rack (2.1.4)
> rack-protection (2.0.8.1)
> rack-test (0.7.0)
> rake (13.0.3)
> rdoc (default: 6.2.1.1)
> readline (default: 0.0.2)
> readline-ext (default: 0.1.0)
> reline (default: 0.1.5)
> rexml (default: 3.2.3.1)
> rspec (3.9.0)
> rspec-core (3.9.2)
> rspec-expectations (3.9.2)
> rspec-mocks (3.9.1)
> rspec-support (3.9.3)
> rss (default: 0.2.8)
> ruby2_keywords (0.0.2)
> rubygems-update (3.2.27)
> safe_yaml (1.0.5)
> sdbm (default: 1.0.0)
> simplecov (0.19.1)
> simplecov-html (0.12.3)
> singleton (default: 0.1.0)
> stringio (default: 0.1.0)
> strscan (default: 1.0

Bug#999723: ruby-omniauth-remote-user: FTBFS with ruby-omniauth 2.0.x: ERROR: Test "ruby2.7" failed: /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1404:in `rescue in block in activate_dependenci

[Antonio Terceiro]

Source: ruby-omniauth-remote-user
Version: 0.1.3-1
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby-omniauth-2.0

Hi,

I would like to upload ruby-omniauth 2.0.4 to unstable soon. During a test
rebuild, ruby-omniauth-remote-user was found to fail to build in that situation.

To reproduce this locally, you need to install ruby-omniauth from experimental
on an unstable system or build chroot. I would expect a new upstream version to
work against the latest ruby-omniauth just fine.

Relevant part (hopefully):
> /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1404:in `rescue in block 
> in activate_dependencies': Could not find 'omniauth' (~> 1.0) among 68 total 
> gem(s) (Gem::MissingSpecError)
> Checked in 
> 'GEM_PATH=/<>/debian/ruby-omniauth-remote-user/usr/share/rubygems-integration/all:/var/lib/gems/2.7.0:/usr/local/lib/ruby/gems/2.7.0:/usr/lib/ruby/gems/2.7.0:/usr/lib/x86_64-linux-gnu/ruby/gems/2.7.0:/usr/share/rubygems-integration/2.7.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0'
>  at: 
> /<>/debian/ruby-omniauth-remote-user/usr/share/rubygems-integration/all/specifications/omniauth-remote-user-0.1.3.gemspec,
>  execute `gem env` for more information
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1401:in `block 
> in activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in `each'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in 
> `activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1372:in 
> `activate'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `block in gem'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `synchronize'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `gem'
>   from -e:1:in `'
> /usr/lib/ruby/vendor_ruby/rubygems/dependency.rb:313:in `to_specs': Could not 
> find 'omniauth' (~> 1.0) - did find: [omniauth-2.0.4] 
> (Gem::MissingSpecVersionError)
> Checked in 
> 'GEM_PATH=/<>/debian/ruby-omniauth-remote-user/usr/share/rubygems-integration/all:/var/lib/gems/2.7.0:/usr/local/lib/ruby/gems/2.7.0:/usr/lib/ruby/gems/2.7.0:/usr/lib/x86_64-linux-gnu/ruby/gems/2.7.0:/usr/share/rubygems-integration/2.7.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0'
>  , execute `gem env` for more information
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1402:in `block 
> in activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in `each'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in 
> `activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1372:in 
> `activate'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `block in gem'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `synchronize'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `gem'
>   from -e:1:in `'
> benchmark (default: 0.1.0)
> bigdecimal (default: 2.0.0)
> bundler (default: 2.1.4)
> cgi (default: 0.1.0)
> csv (default: 3.1.2)
> date (default: 3.0.0)
> dbm (default: 1.1.0)
> delegate (default: 0.1.0)
> did_you_mean (default: 1.4.0)
> diff-lcs (1.4.4)
> etc (default: 1.1.0)
> fcntl (default: 1.0.0)
> fiddle (default: 1.0.0)
> fileutils (default: 1.4.1)
> forwardable (default: 1.3.1)
> gdbm (default: 2.1.0)
> getoptlong (default: 0.1.0)
> hashie (3.5.5)
> io-console (default: 0.5.6)
> ipaddr (default: 1.2.2)
> irb (default: 1.2.6)
> json (default: 2.3.0)
> logger (default: 1.4.2)
> matrix (default: 0.2.0)
> minitest (5.13.0)
> mutex_m (default: 0.1.0)
> net-pop (default: 0.1.0)
> net-smtp (default: 0.1.0)
> net-telnet (0.1.1)
> observer (default: 0.1.0)
> omniauth (2.0.4)
> open3 (default: 0.1.0)
> openssl (default: 2.1.2)
> ostruct (default: 0.2.0)
> power_assert (1.1.7)
> prime (default: 0.1.1)
> pstore (default: 0.1.0)
> psych (default: 3.1.0)
> racc (default: 1.4.16)
> rack (2.1.4)
> rack-protection (2.0.8.1)
> rack-test (0.7.0)
> rake (13.0.3)
> rdoc (default: 6.2.1.1)
> readline (default: 0.0.2)
> readline-ext (default: 0.1.0)
> reline (default: 0.1.5)
> rexml (default: 3.2.3.1)
> rspec (3.9.0)
> rspec-core (3.9.2)
> rspec-expectations (3.9.2)
> rspec-mocks (3.9.1)
> rspec-support (3.9.3)
> rss (default: 0.2.8)
> rubygems-update (3.2.27)
> sdbm (default: 1.0.0)
> singleton (default: 0.1.0)
> stringio (default: 0.1.0)
> strscan (default: 1.0.3)
> test-unit (3.3.9)
> timeout (default: 0.1.0)
> tracer (default: 0.1.0)
> uri (default: 0.10.0)
> webrick (default: 1.6.1)
> xmlrpc (0.3.2)
> yaml (default: 0.1.0)
> zlib (default: 1.1.0)
> ERROR: Test "ruby2.7" failed: 


The full build log is available at
https://people.debian.org/~terceiro/rebuilds/ruby-omniauth-2.0/

Bug#999722: ruby-omniauth-openid: FTBFS with ruby-omniauth 2.0.x: ERROR: Test "ruby2.7" failed: /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1404:in `rescue in block in activate_dependencies':

[Antonio Terceiro]

Source: ruby-omniauth-openid
Version: 1.0.1-4
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby-omniauth-2.0

Hi,

I would like to upload ruby-omniauth 2.0.4 to unstable soon. During a test
rebuild, ruby-omniauth-openid was found to fail to build in that situation.

To reproduce this locally, you need to install ruby-omniauth from experimental
on an unstable system or build chroot. I would expect a new upstream version to
work against the latest ruby-omniauth just fine.

Relevant part (hopefully):
> /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1404:in `rescue in block 
> in activate_dependencies': Could not find 'omniauth' (~> 1.0) among 77 total 
> gem(s) (Gem::MissingSpecError)
> Checked in 
> 'GEM_PATH=/<>/debian/ruby-omniauth-openid/usr/share/rubygems-integration/all:/var/lib/gems/2.7.0:/usr/local/lib/ruby/gems/2.7.0:/usr/lib/ruby/gems/2.7.0:/usr/lib/x86_64-linux-gnu/ruby/gems/2.7.0:/usr/share/rubygems-integration/2.7.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0'
>  at: 
> /<>/debian/ruby-omniauth-openid/usr/share/rubygems-integration/all/specifications/omniauth-openid-1.0.1.gemspec,
>  execute `gem env` for more information
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1401:in `block 
> in activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in `each'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in 
> `activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1372:in 
> `activate'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `block in gem'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `synchronize'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `gem'
>   from -e:1:in `'
> /usr/lib/ruby/vendor_ruby/rubygems/dependency.rb:313:in `to_specs': Could not 
> find 'omniauth' (~> 1.0) - did find: [omniauth-2.0.4] 
> (Gem::MissingSpecVersionError)
> Checked in 
> 'GEM_PATH=/<>/debian/ruby-omniauth-openid/usr/share/rubygems-integration/all:/var/lib/gems/2.7.0:/usr/local/lib/ruby/gems/2.7.0:/usr/lib/ruby/gems/2.7.0:/usr/lib/x86_64-linux-gnu/ruby/gems/2.7.0:/usr/share/rubygems-integration/2.7.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0'
>  , execute `gem env` for more information
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1402:in `block 
> in activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in `each'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in 
> `activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1372:in 
> `activate'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `block in gem'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `synchronize'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `gem'
>   from -e:1:in `'
> addressable (2.8.0)
> benchmark (default: 0.1.0)
> bigdecimal (default: 2.0.0)
> bundler (default: 2.1.4)
> cgi (default: 0.1.0)
> crack (0.4.4)
> csv (default: 3.1.2)
> date (default: 3.0.0)
> dbm (default: 1.1.0)
> delegate (default: 0.1.0)
> did_you_mean (default: 1.4.0)
> diff-lcs (1.4.4)
> etc (default: 1.1.0)
> fcntl (default: 1.0.0)
> fiddle (default: 1.0.0)
> fileutils (default: 1.4.1)
> forwardable (default: 1.3.1)
> gdbm (default: 2.1.0)
> getoptlong (default: 0.1.0)
> hashdiff (1.0.1)
> hashie (3.5.5)
> io-console (default: 0.5.6)
> ipaddr (default: 1.2.2)
> irb (default: 1.2.6)
> json (default: 2.3.0)
> logger (default: 1.4.2)
> matrix (default: 0.2.0)
> minitest (5.13.0)
> mutex_m (default: 0.1.0)
> net-pop (default: 0.1.0)
> net-smtp (default: 0.1.0)
> net-telnet (0.1.1)
> observer (default: 0.1.0)
> omniauth (2.0.4)
> open3 (default: 0.1.0)
> openssl (default: 2.1.2)
> ostruct (default: 0.2.0)
> power_assert (1.1.7)
> prime (default: 0.1.1)
> pstore (default: 0.1.0)
> psych (default: 3.1.0)
> public_suffix (4.0.6)
> racc (default: 1.4.16)
> rack (2.1.4)
> rack-openid (1.4.2)
> rack-protection (2.0.8.1)
> rack-test (0.7.0)
> rake (13.0.3)
> rdoc (default: 6.2.1.1)
> readline (default: 0.0.2)
> readline-ext (default: 0.1.0)
> reline (default: 0.1.5)
> rexml (default: 3.2.3.1)
> rspec (3.9.0)
> rspec-core (3.9.2)
> rspec-expectations (3.9.2)
> rspec-mocks (3.9.1)
> rspec-support (3.9.3)
> rss (default: 0.2.8)
> ruby-hmac (0.4.0)
> ruby-openid (2.9.2)
> rubygems-update (3.2.27)
> safe_yaml (1.0.5)
> sdbm (default: 1.0.0)
> singleton (default: 0.1.0)
> stringio (default: 0.1.0)
> strscan (default: 1.0.3)
> test-unit (3.3.9)
> timeout (default: 0.1.0)
> tracer (default: 0.1.0)
> uri (default: 0.10.0)
> webmock (3.8.3)
> webrick (default: 1.6.1)
> xmlrpc (0.3.2)
> yaml (default: 0.1.0)
> zl

Bug#999721: ruby-omniauth-openid-connect: FTBFS with ruby-omniauth 2.0.x: ERROR: Test "ruby2.7" failed: /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1404:in `rescue in block in activate_depende

[Antonio Terceiro]

Source: ruby-omniauth-openid-connect
Version: 0.4.0-2
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby-omniauth-2.0

Hi,

I would like to upload ruby-omniauth 2.0.4 to unstable soon. During a test
rebuild, ruby-omniauth-openid-connect was found to fail to build in that 
situation.

To reproduce this locally, you need to install ruby-omniauth from experimental
on an unstable system or build chroot. I would expect a new upstream version to
work against the latest ruby-omniauth just fine.

Relevant part (hopefully):
> /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1404:in `rescue in block 
> in activate_dependencies': Could not find 'omniauth' (~> 1.9) among 106 total 
> gem(s) (Gem::MissingSpecError)
> Checked in 
> 'GEM_PATH=/<>/debian/ruby-omniauth-openid-connect/usr/share/rubygems-integration/all:/<>/debian/.debhelper/generated/_source/home/.local/share/gem/ruby/2.7.0:/var/lib/gems/2.7.0:/usr/local/lib/ruby/gems/2.7.0:/usr/lib/ruby/gems/2.7.0:/usr/lib/x86_64-linux-gnu/ruby/gems/2.7.0:/usr/share/rubygems-integration/2.7.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0'
>  at: 
> /<>/debian/ruby-omniauth-openid-connect/usr/share/rubygems-integration/all/specifications/gitlab-omniauth-openid-connect-0.4.0.gemspec,
>  execute `gem env` for more information
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1401:in `block 
> in activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in `each'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in 
> `activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1372:in 
> `activate'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `block in gem'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `synchronize'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `gem'
>   from -e:1:in `'
> /usr/lib/ruby/vendor_ruby/rubygems/dependency.rb:313:in `to_specs': Could not 
> find 'omniauth' (~> 1.9) - did find: [omniauth-2.0.4] 
> (Gem::MissingSpecVersionError)
> Checked in 
> 'GEM_PATH=/<>/debian/ruby-omniauth-openid-connect/usr/share/rubygems-integration/all:/<>/debian/.debhelper/generated/_source/home/.local/share/gem/ruby/2.7.0:/var/lib/gems/2.7.0:/usr/local/lib/ruby/gems/2.7.0:/usr/lib/ruby/gems/2.7.0:/usr/lib/x86_64-linux-gnu/ruby/gems/2.7.0:/usr/share/rubygems-integration/2.7.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0'
>  , execute `gem env` for more information
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1402:in `block 
> in activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in `each'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in 
> `activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1372:in 
> `activate'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `block in gem'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `synchronize'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `gem'
>   from -e:1:in `'
> activemodel (6.0.3.7)
> activesupport (6.0.3.7)
> addressable (2.8.0)
> aes_key_wrap (1.0.1)
> atomic (1.1.16)
> attr_required (1.0.0)
> benchmark (default: 0.1.0)
> bigdecimal (default: 2.0.0)
> bindata (2.4.8)
> bundler (default: 2.1.4)
> cgi (default: 0.1.0)
> concurrent-ruby (1.1.6)
> concurrent-ruby-edge (0.6.0)
> coveralls (0.8.23)
> csv (default: 3.1.2)
> date (default: 3.0.0)
> dbm (default: 1.1.0)
> delegate (default: 0.1.0)
> did_you_mean (default: 1.4.0)
> docile (1.1.5)
> domain_name (0.5.20190701)
> etc (default: 1.1.0)
> faker (1.9.1)
> fcntl (default: 1.0.0)
> fiddle (default: 1.0.0)
> fileutils (default: 1.4.1)
> forwardable (default: 1.3.1)
> gdbm (default: 2.1.0)
> getoptlong (default: 0.1.0)
> hashie (3.5.5)
> http-accept (1.7.0)
> http-cookie (1.0.3)
> httpclient (2.8.3)
> i18n (1.8.11)
> io-console (default: 0.5.6)
> ipaddr (default: 1.2.2)
> irb (default: 1.2.6)
> json (default: 2.3.0)
> json-jwt (1.11.0)
> logger (default: 1.4.2)
> mail (2.7.1)
> matrix (default: 0.2.0)
> metaclass (0.0.4)
> mime-types (3.3.1)
> mime-types-data (3.2015.1120)
> mini_mime (1.1.1)
> minitest (5.13.0)
> mocha (1.7.0)
> multi_json (1.14.1)
> mutex_m (default: 0.1.0)
> net-pop (default: 0.1.0)
> net-smtp (default: 0.1.0)
> net-telnet (0.1.1)
> netrc (0.11.0)
> observer (default: 0.1.0)
> omniauth (2.0.4)
> open3 (default: 0.1.0)
> openid_connect (1.2.0)
> openssl (default: 2.1.2)
> ostruct (default: 0.2.0)
> power_assert (1.1.7)
> prime (default: 0.1.1)
> pstore (default: 0.1.0)
> psych (default: 3.1.0)
> public_suffix (4.0.6)
> racc (default: 1.4.16)
> rack (2.1.4)
> rack-oauth2 (1.16.0)
> rack-pro

Bug#999712: ruby-omniauth-azure-oauth2: FTBFS with ruby-omniauth 2.0.x: ERROR: Test "ruby2.7" failed: /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1404:in `rescue in block in activate_dependenc

[Antonio Terceiro]

Source: ruby-omniauth-azure-oauth2
Version: 0.0.10-1
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby-omniauth-2.0

Hi,

I would like to upload ruby-omniauth 2.0.4 to unstable soon. During a test
rebuild, ruby-omniauth-azure-oauth2 was found to fail to build in that 
situation.

To reproduce this locally, you need to install ruby-omniauth from experimental
on an unstable system or build chroot.

Relevant part (hopefully):
> /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1404:in `rescue in block 
> in activate_dependencies': Could not find 'omniauth' (~> 1.0) among 78 total 
> gem(s) (Gem::MissingSpecError)
> Checked in 
> 'GEM_PATH=/<>/debian/ruby-omniauth-azure-oauth2/usr/share/rubygems-integration/all:/var/lib/gems/2.7.0:/usr/local/lib/ruby/gems/2.7.0:/usr/lib/ruby/gems/2.7.0:/usr/lib/x86_64-linux-gnu/ruby/gems/2.7.0:/usr/share/rubygems-integration/2.7.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0'
>  at: 
> /<>/debian/ruby-omniauth-azure-oauth2/usr/share/rubygems-integration/all/specifications/omniauth-azure-oauth2-0.0.10.gemspec,
>  execute `gem env` for more information
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1401:in `block 
> in activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in `each'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in 
> `activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1372:in 
> `activate'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `block in gem'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `synchronize'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `gem'
>   from -e:1:in `'
> /usr/lib/ruby/vendor_ruby/rubygems/dependency.rb:313:in `to_specs': Could not 
> find 'omniauth' (~> 1.0) - did find: [omniauth-2.0.4] 
> (Gem::MissingSpecVersionError)
> Checked in 
> 'GEM_PATH=/<>/debian/ruby-omniauth-azure-oauth2/usr/share/rubygems-integration/all:/var/lib/gems/2.7.0:/usr/local/lib/ruby/gems/2.7.0:/usr/lib/ruby/gems/2.7.0:/usr/lib/x86_64-linux-gnu/ruby/gems/2.7.0:/usr/share/rubygems-integration/2.7.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0'
>  , execute `gem env` for more information
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1402:in `block 
> in activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in `each'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in 
> `activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1372:in 
> `activate'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `block in gem'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `synchronize'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `gem'
>   from -e:1:in `'
> benchmark (default: 0.1.0)
> bigdecimal (default: 2.0.0)
> bundler (default: 2.1.4)
> cgi (default: 0.1.0)
> csv (default: 3.1.2)
> date (default: 3.0.0)
> dbm (default: 1.1.0)
> delegate (default: 0.1.0)
> did_you_mean (default: 1.4.0)
> diff-lcs (1.4.4)
> etc (default: 1.1.0)
> faraday (1.1.0)
> fcntl (default: 1.0.0)
> fiddle (default: 1.0.0)
> fileutils (default: 1.4.1)
> forwardable (default: 1.3.1)
> gdbm (default: 2.1.0)
> getoptlong (default: 0.1.0)
> hashie (3.5.5)
> io-console (default: 0.5.6)
> ipaddr (default: 1.2.2)
> irb (default: 1.2.6)
> json (default: 2.3.0)
> jwt (2.2.2)
> logger (default: 1.4.2)
> matrix (default: 0.2.0)
> minitest (5.13.0)
> multi_json (1.14.1)
> multi_xml (0.6.0)
> multipart-post (2.0.0)
> mustermann (1.1.1)
> mutex_m (default: 0.1.0)
> net-pop (default: 0.1.0)
> net-smtp (default: 0.1.0)
> net-telnet (0.1.1)
> oauth2 (1.4.4)
> observer (default: 0.1.0)
> omniauth (2.0.4)
> omniauth-oauth2 (1.7.1)
> open3 (default: 0.1.0)
> openssl (default: 2.1.2)
> ostruct (default: 0.2.0)
> power_assert (1.1.7)
> prime (default: 0.1.1)
> pstore (default: 0.1.0)
> psych (default: 3.1.0)
> racc (default: 1.4.16)
> rack (2.1.4)
> rack-protection (2.0.8.1)
> rake (13.0.3)
> rdoc (default: 6.2.1.1)
> readline (default: 0.0.2)
> readline-ext (default: 0.1.0)
> reline (default: 0.1.5)
> rexml (default: 3.2.3.1)
> rspec (3.9.0)
> rspec-core (3.9.2)
> rspec-expectations (3.9.2)
> rspec-mocks (3.9.1)
> rspec-support (3.9.3)
> rss (default: 0.2.8)
> ruby2_keywords (0.0.2)
> rubygems-update (3.2.27)
> sdbm (default: 1.0.0)
> sinatra (2.0.8.1)
> singleton (default: 0.1.0)
> stringio (default: 0.1.0)
> strscan (default: 1.0.3)
> test-unit (3.3.9)
> tilt (2.0.10)
> timeout (default: 0.1.0)
> tracer (default: 0.1.0)
> uri (default: 0.10.0)
> webrick (default: 1.6.1)
> xmlrpc (0.3.2)
> yaml (default: 0.1.0)
> zlib (default: 1.1.0)
> ERROR: T

Bug#999713: ruby-omniauth-cas3: FTBFS with ruby-omniauth 2.0.x: ERROR: Test "ruby2.7" failed: /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1404:in `rescue in block in activate_dependencies': Co

[Antonio Terceiro]

Source: ruby-omniauth-cas3
Version: 1.1.4-2
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby-omniauth-2.0

Hi,

I would like to upload ruby-omniauth 2.0.4 to unstable soon. During a test
rebuild, ruby-omniauth-cas3 was found to fail to build in that situation.

To reproduce this locally, you need to install ruby-omniauth from experimental
on an unstable system or build chroot.

Relevant part (hopefully):
> /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1404:in `rescue in block 
> in activate_dependencies': Could not find 'omniauth' (~> 1.2) among 77 total 
> gem(s) (Gem::MissingSpecError)
> Checked in 
> 'GEM_PATH=/<>/debian/ruby-omniauth-cas3/usr/share/rubygems-integration/all:/var/lib/gems/2.7.0:/usr/local/lib/ruby/gems/2.7.0:/usr/lib/ruby/gems/2.7.0:/usr/lib/x86_64-linux-gnu/ruby/gems/2.7.0:/usr/share/rubygems-integration/2.7.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0'
>  at: 
> /<>/debian/ruby-omniauth-cas3/usr/share/rubygems-integration/all/specifications/omniauth-cas3-1.1.4.gemspec,
>  execute `gem env` for more information
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1401:in `block 
> in activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in `each'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in 
> `activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1372:in 
> `activate'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `block in gem'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `synchronize'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `gem'
>   from -e:1:in `'
> /usr/lib/ruby/vendor_ruby/rubygems/dependency.rb:313:in `to_specs': Could not 
> find 'omniauth' (~> 1.2) - did find: [omniauth-2.0.4] 
> (Gem::MissingSpecVersionError)
> Checked in 
> 'GEM_PATH=/<>/debian/ruby-omniauth-cas3/usr/share/rubygems-integration/all:/var/lib/gems/2.7.0:/usr/local/lib/ruby/gems/2.7.0:/usr/lib/ruby/gems/2.7.0:/usr/lib/x86_64-linux-gnu/ruby/gems/2.7.0:/usr/share/rubygems-integration/2.7.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0'
>  , execute `gem env` for more information
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1402:in `block 
> in activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in `each'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in 
> `activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1372:in 
> `activate'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `block in gem'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `synchronize'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `gem'
>   from -e:1:in `'
> addressable (2.8.0)
> awesome_print (1.8.0)
> benchmark (default: 0.1.0)
> bigdecimal (default: 2.0.0)
> bundler (default: 2.1.4)
> cgi (default: 0.1.0)
> crack (0.4.4)
> csv (default: 3.1.2)
> date (default: 3.0.0)
> dbm (default: 1.1.0)
> delegate (default: 0.1.0)
> did_you_mean (default: 1.4.0)
> diff-lcs (1.4.4)
> etc (default: 1.1.0)
> fcntl (default: 1.0.0)
> fiddle (default: 1.0.0)
> fileutils (default: 1.4.1)
> forwardable (default: 1.3.1)
> gdbm (default: 2.1.0)
> getoptlong (default: 0.1.0)
> hashdiff (1.0.1)
> hashie (3.5.5)
> io-console (default: 0.5.6)
> ipaddr (default: 1.2.2)
> irb (default: 1.2.6)
> json (default: 2.3.0)
> logger (default: 1.4.2)
> matrix (default: 0.2.0)
> minitest (5.13.0)
> mutex_m (default: 0.1.0)
> net-pop (default: 0.1.0)
> net-smtp (default: 0.1.0)
> net-telnet (0.1.1)
> nokogiri (1.11.7)
> observer (default: 0.1.0)
> omniauth (2.0.4)
> open3 (default: 0.1.0)
> openssl (default: 2.1.2)
> ostruct (default: 0.2.0)
> pkg-config (1.4.6)
> power_assert (1.1.7)
> prime (default: 0.1.1)
> pstore (default: 0.1.0)
> psych (default: 3.1.0)
> public_suffix (4.0.6)
> racc (default: 1.4.16)
> rack (2.1.4)
> rack-protection (2.0.8.1)
> rack-test (0.7.0)
> rake (13.0.3)
> rdoc (default: 6.2.1.1)
> readline (default: 0.0.2)
> readline-ext (default: 0.1.0)
> reline (default: 0.1.5)
> rexml (default: 3.2.3.1)
> rspec (3.9.0)
> rspec-core (3.9.2)
> rspec-expectations (3.9.2)
> rspec-mocks (3.9.1)
> rspec-support (3.9.3)
> rss (default: 0.2.8)
> rubygems-update (3.2.27)
> safe_yaml (1.0.5)
> sdbm (default: 1.0.0)
> singleton (default: 0.1.0)
> stringio (default: 0.1.0)
> strscan (default: 1.0.3)
> test-unit (3.3.9)
> timeout (default: 0.1.0)
> tracer (default: 0.1.0)
> uri (default: 0.10.0)
> webmock (3.8.3)
> webrick (default: 1.6.1)
> xmlrpc (0.3.2)
> yaml (default: 0.1.0)
> zlib (default: 1.1.0)
> ERROR: Test "ruby2.7" failed: 


The full build log is available at
https://peo

Bug#999720: ruby-omniauth-oauth: FTBFS with ruby-omniauth 2.0.x: ERROR: Test "ruby2.7" failed: /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1404:in `rescue in block in activate_dependencies': C

[Antonio Terceiro]

Source: ruby-omniauth-oauth
Version: 1.1.0-2.1
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby-omniauth-2.0

Hi,

I would like to upload ruby-omniauth 2.0.4 to unstable soon. During a test
rebuild, ruby-omniauth-oauth was found to fail to build in that situation.

To reproduce this locally, you need to install ruby-omniauth from experimental
on an unstable system or build chroot. I would expect a new upstream version to
work against the latest ruby-omniauth just fine.

Relevant part (hopefully):
> /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1404:in `rescue in block 
> in activate_dependencies': Could not find 'omniauth' (~> 1.0) among 78 total 
> gem(s) (Gem::MissingSpecError)
> Checked in 
> 'GEM_PATH=/<>/debian/ruby-omniauth-oauth/usr/share/rubygems-integration/all:/var/lib/gems/2.7.0:/usr/local/lib/ruby/gems/2.7.0:/usr/lib/ruby/gems/2.7.0:/usr/lib/x86_64-linux-gnu/ruby/gems/2.7.0:/usr/share/rubygems-integration/2.7.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0'
>  at: 
> /<>/debian/ruby-omniauth-oauth/usr/share/rubygems-integration/all/specifications/omniauth-oauth-1.1.0.gemspec,
>  execute `gem env` for more information
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1401:in `block 
> in activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in `each'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in 
> `activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1372:in 
> `activate'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `block in gem'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `synchronize'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `gem'
>   from -e:1:in `'
> /usr/lib/ruby/vendor_ruby/rubygems/dependency.rb:313:in `to_specs': Could not 
> find 'omniauth' (~> 1.0) - did find: [omniauth-2.0.4] 
> (Gem::MissingSpecVersionError)
> Checked in 
> 'GEM_PATH=/<>/debian/ruby-omniauth-oauth/usr/share/rubygems-integration/all:/var/lib/gems/2.7.0:/usr/local/lib/ruby/gems/2.7.0:/usr/lib/ruby/gems/2.7.0:/usr/lib/x86_64-linux-gnu/ruby/gems/2.7.0:/usr/share/rubygems-integration/2.7.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0'
>  , execute `gem env` for more information
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1402:in `block 
> in activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in `each'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in 
> `activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1372:in 
> `activate'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `block in gem'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `synchronize'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `gem'
>   from -e:1:in `'
> addressable (2.8.0)
> benchmark (default: 0.1.0)
> bigdecimal (default: 2.0.0)
> bundler (default: 2.1.4)
> cgi (default: 0.1.0)
> crack (0.4.4)
> csv (default: 3.1.2)
> date (default: 3.0.0)
> dbm (default: 1.1.0)
> delegate (default: 0.1.0)
> did_you_mean (default: 1.4.0)
> diff-lcs (1.4.4)
> docile (1.1.5)
> etc (default: 1.1.0)
> fcntl (default: 1.0.0)
> fiddle (default: 1.0.0)
> fileutils (default: 1.4.1)
> forwardable (default: 1.3.1)
> gdbm (default: 2.1.0)
> getoptlong (default: 0.1.0)
> hashdiff (1.0.1)
> hashie (3.5.5)
> io-console (default: 0.5.6)
> ipaddr (default: 1.2.2)
> irb (default: 1.2.6)
> json (default: 2.3.0)
> logger (default: 1.4.2)
> matrix (default: 0.2.0)
> minitest (5.13.0)
> mutex_m (default: 0.1.0)
> net-pop (default: 0.1.0)
> net-smtp (default: 0.1.0)
> net-telnet (0.1.1)
> oauth (0.5.4)
> observer (default: 0.1.0)
> omniauth (2.0.4)
> open3 (default: 0.1.0)
> openssl (default: 2.1.2)
> ostruct (default: 0.2.0)
> power_assert (1.1.7)
> prime (default: 0.1.1)
> pstore (default: 0.1.0)
> psych (default: 3.1.0)
> public_suffix (4.0.6)
> racc (default: 1.4.16)
> rack (2.1.4)
> rack-protection (2.0.8.1)
> rack-test (0.7.0)
> rake (13.0.3)
> rdoc (default: 6.2.1.1)
> readline (default: 0.0.2)
> readline-ext (default: 0.1.0)
> reline (default: 0.1.5)
> rexml (default: 3.2.3.1)
> rspec (3.9.0)
> rspec-core (3.9.2)
> rspec-expectations (3.9.2)
> rspec-mocks (3.9.1)
> rspec-support (3.9.3)
> rss (default: 0.2.8)
> rubygems-update (3.2.27)
> safe_yaml (1.0.5)
> sdbm (default: 1.0.0)
> simplecov (0.19.1)
> simplecov-html (0.12.3)
> singleton (default: 0.1.0)
> stringio (default: 0.1.0)
> strscan (default: 1.0.3)
> test-unit (3.3.9)
> timeout (default: 0.1.0)
> tracer (default: 0.1.0)
> uri (default: 0.10.0)
> webmock (3.8.3)
> webrick (default: 1.6.1)
> xmlrpc (0.3.2)
> yaml (default:

Bug#999719: ruby-omniauth-multipassword: FTBFS with ruby-omniauth 2.0.x: ERROR: Test "ruby2.7" failed: NoMethodError:

[Antonio Terceiro]

Source: ruby-omniauth-multipassword
Version: 0.4.2-1.1
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby-omniauth-2.0

Hi,

I would like to upload ruby-omniauth 2.0.4 to unstable soon. During a test
rebuild, ruby-omniauth-multipassword was found to fail to build in that 
situation.

To reproduce this locally, you need to install ruby-omniauth from experimental
on an unstable system or build chroot. I would expect a new upstream version to
work against the latest ruby-omniauth just fine.

Relevant part (hopefully):
>  NoMethodError:
>undefined method `[]' for nil:NilClass
>  # ./spec/omniauth/strategy/multi_password_spec.rb:32:in `block (4 
> levels) in '
>  # 
> /usr/share/rubygems-integration/all/gems/omniauth-2.0.4/lib/omniauth/strategy.rb:202:in
>  `call!'
>  # 
> /usr/share/rubygems-integration/all/gems/omniauth-2.0.4/lib/omniauth/strategy.rb:169:in
>  `call'
>  # 
> /usr/share/rubygems-integration/all/gems/omniauth-2.0.4/lib/omniauth/test/phony_session.rb:11:in
>  `call'
>  # ./spec/omniauth/strategy/multi_password_spec.rb:37:in `block (2 
> levels) in '
> 
> Finished in 0.03768 seconds (files took 0.14531 seconds to load)
> 11 examples, 2 failures
> 
> Failed examples:
> 
> rspec ./spec/omniauth/multipassword/base_spec.rb:61 # 
> OmniAuth::MultiPassword::Base single strategy shows login FORM
> rspec ./spec/omniauth/strategy/multi_password_spec.rb:36 # 
> OmniAuth::Strategies::MultiPassword shows login FORM
> 
> Randomized with seed 13795
> 
> /usr/bin/ruby2.7 
> -I/usr/share/rubygems-integration/all/gems/rspec-support-3.9.3/lib:/usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/lib
>  /usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/exe/rspec 
> --pattern ./spec/\*\*/\*_spec.rb failed
> ERROR: Test "ruby2.7" failed: 


The full build log is available at
https://people.debian.org/~terceiro/rebuilds/ruby-omniauth-2.0/ruby-omniauth-multipassword.log


signature.asc
Description: PGP signature

Bug#999718: ruby-omniauth-ldap: FTBFS with ruby-omniauth 2.0.x: ERROR: Test "ruby2.7" failed: /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1404:in `rescue in block in activate_dependencies': Co

[Antonio Terceiro]

Source: ruby-omniauth-ldap
Version: 2.1.1-1
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby-omniauth-2.0

Hi,

I would like to upload ruby-omniauth 2.0.4 to unstable soon. During a test
rebuild, ruby-omniauth-ldap was found to fail to build in that situation.

To reproduce this locally, you need to install ruby-omniauth from experimental
on an unstable system or build chroot.

Relevant part (hopefully):
> /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1404:in `rescue in block 
> in activate_dependencies': Could not find 'omniauth' (~> 1.3) among 71 total 
> gem(s) (Gem::MissingSpecError)
> Checked in 
> 'GEM_PATH=/<>/debian/ruby-omniauth-ldap/usr/share/rubygems-integration/all:/var/lib/gems/2.7.0:/usr/local/lib/ruby/gems/2.7.0:/usr/lib/ruby/gems/2.7.0:/usr/lib/x86_64-linux-gnu/ruby/gems/2.7.0:/usr/share/rubygems-integration/2.7.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0'
>  at: 
> /<>/debian/ruby-omniauth-ldap/usr/share/rubygems-integration/all/specifications/gitlab_omniauth-ldap-2.1.1.gemspec,
>  execute `gem env` for more information
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1401:in `block 
> in activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in `each'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in 
> `activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1372:in 
> `activate'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `block in gem'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `synchronize'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `gem'
>   from -e:1:in `'
> /usr/lib/ruby/vendor_ruby/rubygems/dependency.rb:313:in `to_specs': Could not 
> find 'omniauth' (~> 1.3) - did find: [omniauth-2.0.4] 
> (Gem::MissingSpecVersionError)
> Checked in 
> 'GEM_PATH=/<>/debian/ruby-omniauth-ldap/usr/share/rubygems-integration/all:/var/lib/gems/2.7.0:/usr/local/lib/ruby/gems/2.7.0:/usr/lib/ruby/gems/2.7.0:/usr/lib/x86_64-linux-gnu/ruby/gems/2.7.0:/usr/share/rubygems-integration/2.7.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0'
>  , execute `gem env` for more information
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1402:in `block 
> in activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in `each'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in 
> `activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1372:in 
> `activate'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `block in gem'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `synchronize'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `gem'
>   from -e:1:in `'
> benchmark (default: 0.1.0)
> bigdecimal (default: 2.0.0)
> bundler (default: 2.1.4)
> cgi (default: 0.1.0)
> csv (default: 3.1.2)
> date (default: 3.0.0)
> dbm (default: 1.1.0)
> delegate (default: 0.1.0)
> did_you_mean (default: 1.4.0)
> diff-lcs (1.4.4)
> etc (default: 1.1.0)
> fcntl (default: 1.0.0)
> fiddle (default: 1.0.0)
> fileutils (default: 1.4.1)
> forwardable (default: 1.3.1)
> gdbm (default: 2.1.0)
> getoptlong (default: 0.1.0)
> hashie (3.5.5)
> io-console (default: 0.5.6)
> ipaddr (default: 1.2.2)
> irb (default: 1.2.6)
> json (default: 2.3.0)
> logger (default: 1.4.2)
> matrix (default: 0.2.0)
> minitest (5.13.0)
> mutex_m (default: 0.1.0)
> net-ldap (0.16.3)
> net-pop (default: 0.1.0)
> net-smtp (default: 0.1.0)
> net-telnet (0.1.1)
> observer (default: 0.1.0)
> omniauth (2.0.4)
> open3 (default: 0.1.0)
> openssl (default: 2.1.2)
> ostruct (default: 0.2.0)
> power_assert (1.1.7)
> prime (default: 0.1.1)
> pstore (default: 0.1.0)
> psych (default: 3.1.0)
> pyu-ruby-sasl (0.0.3.3)
> racc (default: 1.4.16)
> rack (2.1.4)
> rack-protection (2.0.8.1)
> rack-test (0.7.0)
> rake (13.0.3)
> rdoc (default: 6.2.1.1)
> readline (default: 0.0.2)
> readline-ext (default: 0.1.0)
> reline (default: 0.1.5)
> rexml (default: 3.2.3.1)
> rspec (3.9.0)
> rspec-core (3.9.2)
> rspec-expectations (3.9.2)
> rspec-mocks (3.9.1)
> rspec-support (3.9.3)
> rss (default: 0.2.8)
> rubygems-update (3.2.27)
> rubyntlm (0.6.3)
> sdbm (default: 1.0.0)
> singleton (default: 0.1.0)
> stringio (default: 0.1.0)
> strscan (default: 1.0.3)
> test-unit (3.3.9)
> timeout (default: 0.1.0)
> tracer (default: 0.1.0)
> uri (default: 0.10.0)
> webrick (default: 1.6.1)
> xmlrpc (0.3.2)
> yaml (default: 0.1.0)
> zlib (default: 1.1.0)
> ERROR: Test "ruby2.7" failed: 


The full build log is available at
https://people.debian.org/~terceiro/rebuilds/ruby-omniauth-2.0/ruby-omniauth-ldap.log


signature.asc
Description: PGP sign

Bug#999717: ruby-omniauth-jwt: FTBFS with ruby-omniauth 2.0.x: ERROR: Test "ruby2.7" failed: /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1404:in `rescue in block in activate_dependencies': Cou

[Antonio Terceiro]

Source: ruby-omniauth-jwt
Version: 0.0.2-1.1
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby-omniauth-2.0

Hi,

I would like to upload ruby-omniauth 2.0.4 to unstable soon. During a test
rebuild, ruby-omniauth-jwt was found to fail to build in that situation.

To reproduce this locally, you need to install ruby-omniauth from experimental
on an unstable system or build chroot.

Relevant part (hopefully):
> /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1404:in `rescue in block 
> in activate_dependencies': Could not find 'omniauth' (~> 1.1) among 68 total 
> gem(s) (Gem::MissingSpecError)
> Checked in 
> 'GEM_PATH=/<>/debian/ruby-omniauth-jwt/usr/share/rubygems-integration/all:/var/lib/gems/2.7.0:/usr/local/lib/ruby/gems/2.7.0:/usr/lib/ruby/gems/2.7.0:/usr/lib/x86_64-linux-gnu/ruby/gems/2.7.0:/usr/share/rubygems-integration/2.7.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0'
>  at: 
> /<>/debian/ruby-omniauth-jwt/usr/share/rubygems-integration/all/specifications/omniauth-jwt-0.0.2.gemspec,
>  execute `gem env` for more information
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1401:in `block 
> in activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in `each'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in 
> `activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1372:in 
> `activate'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `block in gem'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `synchronize'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `gem'
>   from -e:1:in `'
> /usr/lib/ruby/vendor_ruby/rubygems/dependency.rb:313:in `to_specs': Could not 
> find 'omniauth' (~> 1.1) - did find: [omniauth-2.0.4] 
> (Gem::MissingSpecVersionError)
> Checked in 
> 'GEM_PATH=/<>/debian/ruby-omniauth-jwt/usr/share/rubygems-integration/all:/var/lib/gems/2.7.0:/usr/local/lib/ruby/gems/2.7.0:/usr/lib/ruby/gems/2.7.0:/usr/lib/x86_64-linux-gnu/ruby/gems/2.7.0:/usr/share/rubygems-integration/2.7.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0'
>  , execute `gem env` for more information
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1402:in `block 
> in activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in `each'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in 
> `activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1372:in 
> `activate'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `block in gem'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `synchronize'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `gem'
>   from -e:1:in `'
> benchmark (default: 0.1.0)
> bigdecimal (default: 2.0.0)
> bundler (default: 2.1.4)
> cgi (default: 0.1.0)
> csv (default: 3.1.2)
> date (default: 3.0.0)
> dbm (default: 1.1.0)
> delegate (default: 0.1.0)
> did_you_mean (default: 1.4.0)
> diff-lcs (1.4.4)
> etc (default: 1.1.0)
> fcntl (default: 1.0.0)
> fiddle (default: 1.0.0)
> fileutils (default: 1.4.1)
> forwardable (default: 1.3.1)
> gdbm (default: 2.1.0)
> getoptlong (default: 0.1.0)
> hashie (3.5.5)
> io-console (default: 0.5.6)
> ipaddr (default: 1.2.2)
> irb (default: 1.2.6)
> json (default: 2.3.0)
> jwt (2.2.2)
> logger (default: 1.4.2)
> matrix (default: 0.2.0)
> minitest (5.13.0)
> mutex_m (default: 0.1.0)
> net-pop (default: 0.1.0)
> net-smtp (default: 0.1.0)
> net-telnet (0.1.1)
> observer (default: 0.1.0)
> omniauth (2.0.4)
> open3 (default: 0.1.0)
> openssl (default: 2.1.2)
> ostruct (default: 0.2.0)
> power_assert (1.1.7)
> prime (default: 0.1.1)
> pstore (default: 0.1.0)
> psych (default: 3.1.0)
> racc (default: 1.4.16)
> rack (2.1.4)
> rack-protection (2.0.8.1)
> rake (13.0.3)
> rdoc (default: 6.2.1.1)
> readline (default: 0.0.2)
> readline-ext (default: 0.1.0)
> reline (default: 0.1.5)
> rexml (default: 3.2.3.1)
> rspec (3.9.0)
> rspec-core (3.9.2)
> rspec-expectations (3.9.2)
> rspec-mocks (3.9.1)
> rspec-support (3.9.3)
> rss (default: 0.2.8)
> rubygems-update (3.2.27)
> sdbm (default: 1.0.0)
> singleton (default: 0.1.0)
> stringio (default: 0.1.0)
> strscan (default: 1.0.3)
> test-unit (3.3.9)
> timeout (default: 0.1.0)
> tracer (default: 0.1.0)
> uri (default: 0.10.0)
> webrick (default: 1.6.1)
> xmlrpc (0.3.2)
> yaml (default: 0.1.0)
> zlib (default: 1.1.0)
> ERROR: Test "ruby2.7" failed: 


The full build log is available at
https://people.debian.org/~terceiro/rebuilds/ruby-omniauth-2.0/ruby-omniauth-jwt.log


signature.asc
Description: PGP signature

Bug#999716: ruby-omniauth-google-oauth2: FTBFS with ruby-omniauth 2.0.x: ERROR: Test "ruby2.7" failed: NoMethodError:

[Antonio Terceiro]

Source: ruby-omniauth-google-oauth2
Version: 0.6.0-2
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby-omniauth-2.0

Hi,

I would like to upload ruby-omniauth 2.0.4 to unstable soon. During a test
rebuild, ruby-omniauth-google-oauth2 was found to fail to build in that 
situation.

To reproduce this locally, you need to install ruby-omniauth from experimental
on an unstable system or build chroot.

Relevant part (hopefully):
>  NoMethodError:
>undefined method `[]' for nil:NilClass
>  # 
> /usr/share/rubygems-integration/all/gems/omniauth-2.0.4/lib/omniauth/strategy.rb:501:in
>  `script_name'
>  # 
> /usr/share/rubygems-integration/all/gems/omniauth-2.0.4/lib/omniauth/strategy.rb:450:in
>  `callback_path'
>  # ./spec/omniauth/strategies/google_oauth2_spec.rb:293:in `block (3 
> levels) in '
> 
> Finished in 0.09861 seconds (files took 0.22631 seconds to load)
> 102 examples, 1 failure
> 
> Failed examples:
> 
> rspec ./spec/omniauth/strategies/google_oauth2_spec.rb:292 # 
> OmniAuth::Strategies::GoogleOauth2#callback_path has the correct default 
> callback path
> 
> /usr/bin/ruby2.7 
> -I/usr/share/rubygems-integration/all/gems/rspec-support-3.9.3/lib:/usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/lib
>  /usr/share/rubygems-integration/all/gems/rspec-core-3.9.2/exe/rspec 
> --pattern ./spec/\*\*/\*_spec.rb --format documentation failed
> ERROR: Test "ruby2.7" failed: 


The full build log is available at
https://people.debian.org/~terceiro/rebuilds/ruby-omniauth-2.0/ruby-omniauth-google-oauth2.log


signature.asc
Description: PGP signature

Bug#999715: ruby-omniauth-github: FTBFS with ruby-omniauth 2.0.x: ERROR: Test "ruby2.7" failed: /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1404:in `rescue in block in activate_dependencies':

[Antonio Terceiro]

Source: ruby-omniauth-github
Version: 1.4.0-1
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby-omniauth-2.0

Hi,

I would like to upload ruby-omniauth 2.0.4 to unstable soon. During a test
rebuild, ruby-omniauth-github was found to fail to build in that situation.

To reproduce this locally, you need to install ruby-omniauth from experimental
on an unstable system or build chroot.

Relevant part (hopefully):
> /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1404:in `rescue in block 
> in activate_dependencies': Could not find 'omniauth' (~> 1.5) among 82 total 
> gem(s) (Gem::MissingSpecError)
> Checked in 
> 'GEM_PATH=/<>/debian/ruby-omniauth-github/usr/share/rubygems-integration/all:/var/lib/gems/2.7.0:/usr/local/lib/ruby/gems/2.7.0:/usr/lib/ruby/gems/2.7.0:/usr/lib/x86_64-linux-gnu/ruby/gems/2.7.0:/usr/share/rubygems-integration/2.7.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0'
>  at: 
> /<>/debian/ruby-omniauth-github/usr/share/rubygems-integration/all/specifications/omniauth-github-1.4.0.gemspec,
>  execute `gem env` for more information
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1401:in `block 
> in activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in `each'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in 
> `activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1372:in 
> `activate'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `block in gem'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `synchronize'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `gem'
>   from -e:1:in `'
> /usr/lib/ruby/vendor_ruby/rubygems/dependency.rb:313:in `to_specs': Could not 
> find 'omniauth' (~> 1.5) - did find: [omniauth-2.0.4] 
> (Gem::MissingSpecVersionError)
> Checked in 
> 'GEM_PATH=/<>/debian/ruby-omniauth-github/usr/share/rubygems-integration/all:/var/lib/gems/2.7.0:/usr/local/lib/ruby/gems/2.7.0:/usr/lib/ruby/gems/2.7.0:/usr/lib/x86_64-linux-gnu/ruby/gems/2.7.0:/usr/share/rubygems-integration/2.7.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0'
>  , execute `gem env` for more information
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1402:in `block 
> in activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in `each'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in 
> `activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1372:in 
> `activate'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `block in gem'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `synchronize'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `gem'
>   from -e:1:in `'
> addressable (2.8.0)
> benchmark (default: 0.1.0)
> bigdecimal (default: 2.0.0)
> bundler (default: 2.1.4)
> cgi (default: 0.1.0)
> crack (0.4.4)
> csv (default: 3.1.2)
> date (default: 3.0.0)
> dbm (default: 1.1.0)
> delegate (default: 0.1.0)
> did_you_mean (default: 1.4.0)
> diff-lcs (1.4.4)
> etc (default: 1.1.0)
> faraday (1.1.0)
> fcntl (default: 1.0.0)
> fiddle (default: 1.0.0)
> fileutils (default: 1.4.1)
> forwardable (default: 1.3.1)
> gdbm (default: 2.1.0)
> getoptlong (default: 0.1.0)
> hashdiff (1.0.1)
> hashie (3.5.5)
> io-console (default: 0.5.6)
> ipaddr (default: 1.2.2)
> irb (default: 1.2.6)
> json (default: 2.3.0)
> jwt (2.2.2)
> logger (default: 1.4.2)
> matrix (default: 0.2.0)
> minitest (5.13.0)
> multi_json (1.14.1)
> multi_xml (0.6.0)
> multipart-post (2.0.0)
> mutex_m (default: 0.1.0)
> net-pop (default: 0.1.0)
> net-smtp (default: 0.1.0)
> net-telnet (0.1.1)
> oauth2 (1.4.4)
> observer (default: 0.1.0)
> omniauth (2.0.4)
> omniauth-oauth2 (1.7.1)
> open3 (default: 0.1.0)
> openssl (default: 2.1.2)
> ostruct (default: 0.2.0)
> power_assert (1.1.7)
> prime (default: 0.1.1)
> pstore (default: 0.1.0)
> psych (default: 3.1.0)
> public_suffix (4.0.6)
> racc (default: 1.4.16)
> rack (2.1.4)
> rack-protection (2.0.8.1)
> rack-test (0.7.0)
> rake (13.0.3)
> rdoc (default: 6.2.1.1)
> readline (default: 0.0.2)
> readline-ext (default: 0.1.0)
> reline (default: 0.1.5)
> rexml (default: 3.2.3.1)
> rspec (3.9.0)
> rspec-core (3.9.2)
> rspec-expectations (3.9.2)
> rspec-mocks (3.9.1)
> rspec-support (3.9.3)
> rss (default: 0.2.8)
> ruby2_keywords (0.0.2)
> rubygems-update (3.2.27)
> safe_yaml (1.0.5)
> sdbm (default: 1.0.0)
> singleton (default: 0.1.0)
> stringio (default: 0.1.0)
> strscan (default: 1.0.3)
> test-unit (3.3.9)
> timeout (default: 0.1.0)
> tracer (default: 0.1.0)
> uri (default: 0.10.0)
> webmock (3.8.3)
> webrick (default: 1.6.1)
> xmlrpc (0.3.2)
> yaml (default

Bug#999714: ruby-omniauth-crowd: FTBFS with ruby-omniauth 2.0.x: ERROR: Test "ruby2.7" failed: /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1404:in `rescue in block in activate_dependencies': C

[Antonio Terceiro]

Source: ruby-omniauth-crowd
Version: 2.4.0-1.1
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby-omniauth-2.0

Hi,

I would like to upload ruby-omniauth 2.0.4 to unstable soon. During a test
rebuild, ruby-omniauth-crowd was found to fail to build in that situation.

To reproduce this locally, you need to install ruby-omniauth from experimental
on an unstable system or build chroot.

Relevant part (hopefully):
> /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1404:in `rescue in block 
> in activate_dependencies': Could not find 'omniauth' (~> 1.0) among 84 total 
> gem(s) (Gem::MissingSpecError)
> Checked in 
> 'GEM_PATH=/<>/debian/ruby-omniauth-crowd/usr/share/rubygems-integration/all:/var/lib/gems/2.7.0:/usr/local/lib/ruby/gems/2.7.0:/usr/lib/ruby/gems/2.7.0:/usr/lib/x86_64-linux-gnu/ruby/gems/2.7.0:/usr/share/rubygems-integration/2.7.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0'
>  at: 
> /<>/debian/ruby-omniauth-crowd/usr/share/rubygems-integration/all/specifications/omniauth_crowd-2.4.0.gemspec,
>  execute `gem env` for more information
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1401:in `block 
> in activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in `each'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in 
> `activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1372:in 
> `activate'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `block in gem'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `synchronize'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `gem'
>   from -e:1:in `'
> /usr/lib/ruby/vendor_ruby/rubygems/dependency.rb:313:in `to_specs': Could not 
> find 'omniauth' (~> 1.0) - did find: [omniauth-2.0.4] 
> (Gem::MissingSpecVersionError)
> Checked in 
> 'GEM_PATH=/<>/debian/ruby-omniauth-crowd/usr/share/rubygems-integration/all:/var/lib/gems/2.7.0:/usr/local/lib/ruby/gems/2.7.0:/usr/lib/ruby/gems/2.7.0:/usr/lib/x86_64-linux-gnu/ruby/gems/2.7.0:/usr/share/rubygems-integration/2.7.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0'
>  , execute `gem env` for more information
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1402:in `block 
> in activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in `each'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1390:in 
> `activate_dependencies'
>   from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1372:in 
> `activate'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `block in gem'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `synchronize'
>   from /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
> `gem'
>   from -e:1:in `'
> activesupport (6.0.3.7)
> addressable (2.8.0)
> atomic (1.1.16)
> benchmark (default: 0.1.0)
> bigdecimal (default: 2.0.0)
> bundler (default: 2.1.4)
> cgi (default: 0.1.0)
> concurrent-ruby (1.1.6)
> concurrent-ruby-edge (0.6.0)
> crack (0.4.4)
> csv (default: 3.1.2)
> date (default: 3.0.0)
> dbm (default: 1.1.0)
> delegate (default: 0.1.0)
> did_you_mean (default: 1.4.0)
> diff-lcs (1.4.4)
> etc (default: 1.1.0)
> fcntl (default: 1.0.0)
> fiddle (default: 1.0.0)
> fileutils (default: 1.4.1)
> forwardable (default: 1.3.1)
> gdbm (default: 2.1.0)
> getoptlong (default: 0.1.0)
> hashdiff (1.0.1)
> hashie (3.5.5)
> i18n (1.8.11)
> io-console (default: 0.5.6)
> ipaddr (default: 1.2.2)
> irb (default: 1.2.6)
> json (default: 2.3.0)
> logger (default: 1.4.2)
> matrix (default: 0.2.0)
> minitest (5.13.0)
> mutex_m (default: 0.1.0)
> net-pop (default: 0.1.0)
> net-smtp (default: 0.1.0)
> net-telnet (0.1.1)
> nokogiri (1.11.7)
> observer (default: 0.1.0)
> omniauth (2.0.4)
> open3 (default: 0.1.0)
> openssl (default: 2.1.2)
> ostruct (default: 0.2.0)
> pkg-config (1.4.6)
> power_assert (1.1.7)
> prime (default: 0.1.1)
> pstore (default: 0.1.0)
> psych (default: 3.1.0)
> public_suffix (4.0.6)
> racc (default: 1.4.16)
> rack (2.1.4)
> rack-protection (2.0.8.1)
> rack-test (0.7.0)
> rake (13.0.3)
> rdoc (default: 6.2.1.1)
> readline (default: 0.0.2)
> readline-ext (default: 0.1.0)
> reline (default: 0.1.5)
> rexml (default: 3.2.3.1)
> rspec (3.9.0)
> rspec-core (3.9.2)
> rspec-expectations (3.9.2)
> rspec-mocks (3.9.1)
> rspec-support (3.9.3)
> rss (default: 0.2.8)
> rubygems-update (3.2.27)
> safe_yaml (1.0.5)
> sdbm (default: 1.0.0)
> singleton (default: 0.1.0)
> stringio (default: 0.1.0)
> strscan (default: 1.0.3)
> test-unit (3.3.9)
> thread_safe (0.3.6)
> timeout (default: 0.1.0)
> tracer (default: 0.1.0)
> tzinfo (1.2.6)
> uri (default: 0.10.0)
> webmock (3.8.3)
> webrick (default: 1.6.1)
> xmlr

Bug#998476: autoconf-archive: AX_PYTHON_DEVEL version checks fail with Python 3.10

[roucaries bastien]

Hi,

Can I have the debdiff ? I can do the upload

Bastien (ro...@debian.org)


Le jeu. 11 nov. 2021 à 11:48, Matthias Klose  a écrit :
>
> uploaded to the delayed queue to prepare for Python 3.10.

Bug#998718: Brasero fails (on Testing) burning an ISO image on a CD-RW

[Thomas Schmitt]

Hi,

Mauro Sacchetto wrote:
> sg_raw /dev/sr0 be 00 ff ff ff ff 00 00 01 10 00 00 --outfile=tdb_data.bin
> After this, the drive is unavailable

Well, then we have found:

- The immediate cause of the problem: READ CD with LBA -1.

- A good suspect in Brasero: Function brasero_medium_track_written_SAO()

https://sources.debian.org/src/brasero/3.12.3-1/libbrasero-media/brasero-medium.c/?hl=1565#L1565

- The generally problematic expectation of Brasero that it can determine
  whether a CD track was written by write type SAO (and not by TAO).

-

We have not explored yet:

- Why does Brasero believe to see 2 tracks on a closed CD-RW with a
  single TAO track ?
BraseroMedia: (at brasero-medium.c:2062) 2 track(s) found
  This misperception triggers the call to brasero_medium_track_written_SAO().

- Why does brasero_medium_track_get_info() want to distinguish SAO from
  TAO only if its parameter multisession is set to "true". Its only caller
  has a strange comment before setting multisession:

https://sources.debian.org/src/brasero/3.12.3-1/libbrasero-media/brasero-medium.c/?#L2052

num = (size - sizeof (BraseroScsiFormattedTocData)) /
   sizeof (BraseroScsiTocDesc);

/* remove 1 for leadout */
multisession = !(priv->info & BRASERO_MEDIUM_BLANK) && num > 0;

  If the leadout is counted as surplus track, then why not "num > 1" ?

-

So the Brasero "Copy" task of TAO CDs is not possible with the ASUS drive.
The code of Brasero would have to be changed for that.

We have no workaround yet for the case of burning the netinst ISO by
Brasero.
I found no way to tell Brasero that its libburn plugin shall ask libburn
for SAO. libburn would of course be able to avoid SAO if it is told to do
so. It would propose SAO if being asked to find a suitable write type for
track input of which the size is known in advance.

My only idea which does not need a code change is to employ the wodim
plugin of Brasero and to hope that it burns by write type SAO.
If so, then the drive would not get lost after a successful burn run.

Of course you would have to carefully avoid to show Brasero a TAO CD in
the ASUS drive.
Best would be to blank any CD-RW before giving it to Brasero.

-

Have a nice day :)

Thomas

Bug#998867: debootstrap: --no-merged-usr became a no-op

[Dimitri John Ledkov]

There are multiple issues reported in a single bug.

> This means that I cannot create a Debian chroot from Debian unstable from 10 
> years ago from snapshot.debian.org without merged-/usr and thus my chroot 
> will behave differently as it did back then.
> Please re-enable --no-merged-usr so that I can re-create old chroots from 
> snapshot.d.o again.

I don't think debootstrap has such goals, or requirement to be able to
bootstrap rolling release without a changing codename like
unstable/sid. debootstrap already sets options that may not be
supported or lead to incorrect chroots if debootstrap & scripts are
used from too far away time window for a rolling release. If you
desire to re-create a debootstrap of unstable as it looked 10 years
ago, it is best to do it using 10 years old debootstrap from the said
snapshot archive too.

Note that stable/testing are not affected as much, because the rolling
alias is resolved to a codename, and hence doing debootstrap from an
old snapshot of "stable" will do what the codename "lenny" wants,
although there is no guarantee that current debootstrap will resolve
things the same way as the 10 year old debootstrap did.

Allowing --no-merged-usr option unguarded may lead to users creating
incorrect installations and chroots for the future releases,
especially since packages can assume merged-usr in the upcoming
releases.

I wonder if I can do some further checks, I.e. if unstable, and the
InRelease / Release Date is old, do split-usr. I.e. anything before
2022. Effectively implement a time guard "old-sid" vs "new-sid", since
the codename for sid has not changed. Thus allowing to bootstrap old
sid snapshots in a manner closer to what old debootstrap from said
snapshot would do. But still wIthout any guarantees that it will be
identical.

> Also, build chroots must still be created without merged-usr for 
> sid/bookworm, until something's been done to migrate user systems.

But Julien, you said that buildds run stable, meaning they are
unaffected by this debootstrap change in sid/bookworm.

> Please point out what you plan to do about this change in debootstrap so that 
> I can adapt the mmdebstrap autopkgtest accordingly.

I did notice the mmdebstrap autopkgtest regression. I also noticed
that mmdebstrap does not support --merged-usr flag, and instead offers
three ways of creating chroots that are merged-usr.
To match the current debootstrap behaviour in sid, as currently
implemented in debootstrap in sid, it seems to me that mmdebstrap
should auto-enable
`--setup-hook=/usr/share/mmdebstrap/hooks/merged-usr/setup00.sh` for
sid/bookworm, but somehow continue to honor user supplied
--setup-hooks (append? override?) I was going to file a bug report
about that after using mmdebstrap, as I have not used it yet and not
sure how that would fit into UX and user expectations.

-- 
Regards,

Dimitri.

Bug#999705: fusiondirectory: Provide version 1.3.1 for Bullseye ? (fix dashboard crash)

[Adrien Grellier]

Hi,

Thanks for the answer.


> The way to fix this for you is: I bring FD to Debian testing/unstable  
and provide a 1.3.1 backport. Would that work for you?

The Backport solution is good for me, and less intrusive in the Debian process 
indeed. For upstream, it may be also a better option, to avoid strange 
configuration, not 1.3 and still not fully 1.3.1 :-)


If you prefer to go with the patches solution, I need this one for sure :
https://gitlab.fusiondirectory.org/fusiondirectory/fd/-/commit/1103808bd3015ae37333e60625fae1262b8dd89a
 

and maybe this one, about the expiration date on the Dashboard:
https://gitlab.fusiondirectory.org/fusiondirectory/fd/-/commit/549d6143c8e1d3e614b3d3c2a522f1bd671161d2
 

Kind regards,

Adrien


-- 

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de

Bug#999701: fish-common: Error in /usr/share/doc-base/fish-common.fish

[David Adam]

On Mon, 15 Nov 2021, Vincent Lefevre wrote:
> Package: fish-common
> Version: 3.3.1+ds-1
> Severity: normal
> 
> When upgrading:
> 
> Processing triggers for doc-base (0.11.1) ...
> Processing 1 removed doc-base file, 1 added doc-base file...
> Error in `/usr/share/doc-base/fish-common.fish', line 12: all `Format' 
> sections are invalid.
> Note: `install-docs --verbose --check file_name' may give more details about 
> the above error.
> 
> /usr/share/doc-base/fish-common.fish contains:
> 
> Format: HTML
> Index: /usr/share/doc/fish/index.html
> Files: /usr/share/doc/fish/*.html
> 
> and indeed, there are no html files under /usr/share/doc/fish.

This is because the documentation is stripped from the rebuilt tarball, 
but the correct documentation system is not included as a build 
dependency.

I have submitted a patch through Salsa; I hope that's ok.
  https://salsa.debian.org/debian/fish/-/merge_requests/4

David Adam
fish committer
zanc...@ucc.gu.uwa.edu.au

Bug#987052: timidity: Piano sounds from the right side instead of the center.

[Hans de Goede]

I believe that you are right that this is caused by:
0005-fix-drum-panning.patch

I've just filed a related bug-report about this myself:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=999710

Bug#999710: timidity patch 0005-fix-drum-panning.patch appears to be wrong

[Hans de Goede]

A quick follow-up I just noticed this bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987052

Which is complaining about wrong pan with Debian's
timidity and with Fedora's timidty (without the patch)
this problem does not happen.