Bug#991756: linux-image-5.10.0-8-amd64: alsa regression: HDMI output does not work anymore

[Sergey Spiridonov]

Package: src:linux
Version: 5.10.46-3
Severity: normal
X-Debbugs-Cc: s...@s73.work

Dear Maintainer,

After upgrade from linux kernel linux-image-4.19.0-16-amd64 to
linux-image-5.10.0-8-amd64 HDMI sound does not work anymore.

That is HP EliteDesk 800 G1 desktop.

I also tried

# cat /etc/modprobe.d/alsa.conf
options snd-intel-dspcfg dsp_driver=1

that makes sound working, but not stable, sometimes it jumps,
sometimes produces clicks and sometimes disappears, video in
youtube or VLC does not behave stable too.

Downgrading kernel linux-image-4.19.0-16-amd64 solves the problem.

Quick googling shows that I am not alone, but know solution exists.

Output of alsainfo script follows


-- Package-specific info:
** Version:
Linux version 5.10.0-8-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP 
Debian 5.10.46-3 (2021-07-28)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.10.0-8-amd64 
root=UUID=8401bdfb-7c29-4f78-bc52-fb11e109580e ro quiet

** Not tainted

** Kernel log:
[2.850558] systemd[1]: Finished Create list of static device nodes for the 
current kernel.
[2.850765] systemd[1]: modprobe@configfs.service: Succeeded.
[2.850896] systemd[1]: Finished Load Kernel Module configfs.
[2.851055] systemd[1]: modprobe@drm.service: Succeeded.
[2.851187] systemd[1]: Finished Load Kernel Module drm.
[2.851858] systemd[1]: Mounting Kernel Configuration File System...
[2.857526] fuse: init (API version 7.32)
[2.864967] systemd[1]: modprobe@fuse.service: Succeeded.
[2.865136] systemd[1]: Finished Load Kernel Module fuse.
[2.865982] systemd[1]: Mounting FUSE Control File System...
[2.868942] lp: driver loaded but no devices found
[2.871223] EXT4-fs (sda2): re-mounted. Opts: errors=remount-ro
[2.872561] systemd[1]: Finished Remount Root and Kernel File Systems.
[2.872701] systemd[1]: Mounted Kernel Configuration File System.
[2.872785] systemd[1]: Mounted FUSE Control File System.
[2.872965] ppdev: user-space parallel port driver
[2.873755] systemd[1]: Condition check resulted in Rebuild Hardware 
Database being skipped.
[2.873788] systemd[1]: Condition check resulted in Platform Persistent 
Storage Archival being skipped.
[2.874323] systemd[1]: Starting Load/Save Random Seed...
[2.874877] systemd[1]: Starting Create System Users...
[2.878626] systemd[1]: Finished Load Kernel Modules.
[2.879244] systemd[1]: Starting Apply Kernel Variables...
[2.889290] RPC: Registered named UNIX socket transport module.
[2.889292] RPC: Registered udp transport module.
[2.889292] RPC: Registered tcp transport module.
[2.889293] RPC: Registered tcp NFSv4.1 backchannel transport module.
[2.890443] systemd[1]: Mounted RPC Pipe File System.
[2.891033] systemd[1]: Starting pNFS block layout mapping daemon...
[2.903567] systemd[1]: Started Journal Service.
[2.918507] systemd-journald[249]: Received client request to flush runtime 
journal.
[2.947414] Installing knfsd (copyright (C) 1996 o...@monad.swb.de).
[3.246563] pstore: Using crash dump compression: deflate
[3.246574] pstore: Registered efi as persistent store backend
[3.248365] input: HP WMI hotkeys as /devices/virtual/input/input22
[3.305818] input: PC Speaker as /devices/platform/pcspkr/input/input23
[3.306316] at24 0-0050: supply vcc not found, using dummy regulator
[3.307361] at24 0-0050: 256 byte spd EEPROM, read-only
[3.307375] at24 0-0051: supply vcc not found, using dummy regulator
[3.307897] at24 0-0051: 256 byte spd EEPROM, read-only
[3.307910] at24 0-0052: supply vcc not found, using dummy regulator
[3.308240] sd 0:0:0:0: Attached scsi generic sg0 type 0
[3.308426] at24 0-0052: 256 byte spd EEPROM, read-only
[3.308437] at24 0-0053: supply vcc not found, using dummy regulator
[3.309063] iTCO_vendor_support: vendor-support=0
[3.309132] at24 0-0053: 256 byte spd EEPROM, read-only
[3.315639] tpm_tis 00:08: 1.2 TPM (device-id 0xB, rev-id 16)
[3.341226] tpm tpm0: TPM is disabled/deactivated (0x7)
[3.345834] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11
[3.345873] iTCO_wdt: Found a Lynx Point TCO device (Version=2, 
TCOBASE=0x0460)
[3.346445] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
[3.375485] mc: Linux media interface: v0.10
[3.375770] RAPL PMU: API unit is 2^-32 Joules, 4 fixed counters, 655360 ms 
ovfl timer
[3.375772] RAPL PMU: hw unit of domain pp0-core 2^-14 Joules
[3.375772] RAPL PMU: hw unit of domain package 2^-14 Joules
[3.375773] RAPL PMU: hw unit of domain dram 2^-14 Joules
[3.375773] RAPL PMU: hw unit of domain pp1-gpu 2^-14 Joules
[3.404453] cryptd: max_cpu_qlen set to 1000
[3.449186] Adding 4081660k swap on /dev/sda3.  Priority:-2 extents:1 
across:4081660k SSFS
[3.449337] usbcore: registered new interface driver snd-usb-audio
[3.489649] AVX2 vers

Bug#860027: ITP: elpa-page-break-lines -- Emacs mode to display ugly ^L page breaks as tidy horizontal lines

[Nicholas D Steeves]

P.S. I am not blaming you, and I suspect that this policy is not easily
discoverable enough.  Assuming you weren't able to find it, where
would you have expected to find it? :-)



signature.asc
Description: PGP signature

Bug#860027: ITP: elpa-page-break-lines -- Emacs mode to display ugly ^L page breaks as tidy horizontal lines

[Nicholas D Steeves]

Hi Martin,

Martin  writes:

> Control: retitle -1 ITP: elpa-page-break-lines -- Emacs mode to display ugly 
> ^L page breaks as tidy horizontal lines
>
> Package is in NEW now:
> https://ftp-master.debian.org/new.html
>
> Packaging repository is here:
> https://salsa.debian.org/emacsen-team/elpa-page-break-lines

This src:package naming is not compliant with our team policy.  See:

  https://wiki.debian.org/Teams/DebianEmacsenTeam

I just made a minor addition "I.e. Do not add an 'elpa-' prefix to the
source package name." in case it wasn't previously clear.

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#901332: d-i: Offer to shut down / power off instead of reboot at the end

[Cyril Brulebois]

Thorsten Glaser  (2021-07-31):
> Did anything ever come from this, now that we’re nearing a release?

I'm not sure what you expect. If there had been progress, this would
have ended up in this bug report, wouldn't it?


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


signature.asc
Description: PGP signature

Bug#986527: Patches for flaky build and cython unavailability

[Ahzo]

Control: tags -1 patch

Hi,

the main problem making the sagemath testsuite flaky is that it randomly aborts 
due to 'Too many open files'.
Thus only a small part of the test suite gets actually run, when the build is 
heavily parallelized.
This can be seen by reporting not only the number of failed, but also that of 
run tests, which shows significant fluctuations.

The problem occurs, because every finished, but not yet logged worker, holds an 
open fd (a pipe used to read the output of the child actually doing the tests).
Thus when following a long running worker, i.e. logging its messages, while it 
is still running, so many finished tests can accumulate, that the open files 
limit (ulimit -n) is reached.

However, there should be no open pipe per finished worker, as the test suite 
calls 'os.close(self.rmessages)' before waiting for logging the messages.
So this seems to be caused by something that python does behind the scenes.
Removing the single line 'finished.append(w)' in src/sage/doctest/forker.py 
prevents the open fd increase, though at the cost of hardly logging any test 
output.

This problem can be avoided by simply logging every finished test, but no 
running one.

With only the 0001-Report-the-number-of-total-tests-run.patch, the result is 
something like:
Success: 5 of 71435 tests failed, up to 200 failures are tolerated

Adding the dt-Do-not-follow-a-running-worker.patch, the result becomes:
Success: 194 of 361139 tests failed, up to 200 failures are tolerated

These 194 failures are pretty close to the threshold of 200, so it is not 
particularly surprising, that this can fail in some environments.
Slightly passing this threshold triggered the build failure in this bug and 
also the one in bug #983931.

Increasing the threshold to 300 should make that rather unlikely, though.
And considering that there are more than 360 thousand tests, less then 300 
failures means more than 99.9 % of the tests succeeded.

The "cython: not found" issue is trivial to fix and important, because 
otherwise 'sage --cython' does not work and there is no '--cython3' option 
(unlike e.g. the '--ipython3' option).

After adding the 0002-Tolerate-up-to-300-failing-tests.patch and the 
u2-Adapt-to-python2-removal.patch the test result is:
Success: 189 of 361139 tests failed, up to 300 failures are tolerated

It would also be a good idea to include a backport of commit 5cf493ca51 ("Avoid 
libgmp's new lazy allocation") in the next sagemath upload, as that fixes a 
severe memory leak (see bug #964848).

As to the crashes, I can't reproduce any crash when testing 
interfaces/singular.py:
sage -t --long --random-seed=0 src/sage/interfaces/singular.py
    [404 tests, 3.87 s]

This crash also does not always happen for the reproducible builds either, e.g. 
the following log shows it first crashing and then passing this test:
https://tests.reproducible-builds.org/debian/rbuild/bullseye/amd64/sagemath_9.2-2.rbuild.log.gz
[...]
sage -t --long --random-seed=0 src/sage/interfaces/singular.py
    Killed due to segmentation fault
[...]
sage -t --long --random-seed=0 src/sage/interfaces/singular.py
    [404 tests, 21.06 s]
[...]

However, a number of other crashes happen during every test run, but only one 
of them causes a test failure:
sage -t --long --random-seed=0 src/sage/interfaces/tests.py
**
File "src/sage/interfaces/tests.py", line 34, in sage.interfaces.tests
Failed example:
    subprocess.call("echo syntax error | ecl", **kwds) in (0, 255)
Expected:
    True
Got:
    False
**

Similar crashes sometimes also occur when testing interfaces/lisp.py, but 
without causing the test to fail.
This is a problem in ecl, which crashes when both stdout and stderr are full, 
see bug #710953.

Then there is a crash in nauty-gentourng triggered by 
src/sage/graphs/digraph_generators.py.
For details see bug #991750.

There are also two SIGABRT crashes in mwrank triggered by 
src/sage/interfaces/mwrank.py.
These seem to be intentional due to invalid input.

Finally, there are some python crashes (5 SIGQUIT, 1 SIGABRT, 1 SIGSEGV) that 
are all caused intentionally by the test suite.

So none of these crashes are problems in sagemath itself.

Regards,
Ahzo
>From 5c741b0066c861504483b5ed66915b01ddd078b0 Mon Sep 17 00:00:00 2001
From: Ahzo 
Date: Sat, 31 Jul 2021 13:15:51 +0200
Subject: [PATCH 1/2] Report the number of total tests run

This makes it easier to notice when tests get skipped.
---
 debian/rules| 10 ++
 debian/tests.mk |  4 
 2 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/debian/rules b/debian/rules
index f984695..9e904e2 100755
--- a/debian/rules
+++ b/debian/rules
@@ -163,11 +163,12 @@ endif
 had-few-failures:
 	if ! test -f $(LOGFILE); then echo "Error: log file $(LOGFILE) not found"; false; fi
 	N_TEST_FAILURES="$$($(TESTS_MK) failed-tests-total-normal)";

Bug#710953: ecl: segfault when both stdout and stderr are full

[Ahzo]

Control: retitle -1 ecl: segfault when both stdout and stderr are full
Control: found -1 ecl/20.4.24+ds-2
Control: forwarded -1 https://gitlab.com/embeddable-common-lisp/ecl/-/issues/634
Control: affects -1 sagemath

Hi,

the originally reported problem is already fixed, i.e. only redirecting stderr 
to /dev/full no longer causes a crash:
$ echo "syntax error" | ecl 2>/dev/full
ECL (Embeddable Common-Lisp) 20.4.24 (git:UNKNOWN)
Copyright (C) 1984 Taiichi Yuasa and Masami Hagiya
Copyright (C) 1993 Giuseppe Attardi
Copyright (C) 2013 Juan J. Garcia-Ripoll
Copyright (C) 2018 Daniel Kochmanski
Copyright (C) 2020 Daniel Kochmanski and Marius Gerbershagen
ECL is free software, and you are welcome to redistribute it
under certain conditions; see file 'Copyright' for details.
Type :h for Help. 
Top level in: #.
>
Available restarts:

1. (RESTART-TOPLEVEL) Go back to Top-Level REPL.

Broken at SI:BYTECODES. [Evaluation of: SYNTAX] In: #.
>>
$ echo $?
0

However, the sagemath testsuite still triggers a related crash in ecl:
sage -t --long --random-seed=0 src/sage/interfaces/tests.py
**
File "src/sage/interfaces/tests.py", line 34, in sage.interfaces.tests
Failed example:
    subprocess.call("echo syntax error | ecl", **kwds) in (0, 255)
Expected:
    True
Got:
    False
**

This crash is easy to reproduce:
$ ecl &> /dev/full
Segmentation fault (core dumped)

Occasionally, similar crashes also occur in other sagemath tests, e.g. 
src/sage/interfaces/lisp.py.
This can be reproduced as follows:
$ sage
sage: l = Lisp()
sage: l._start()
sage: l.quit()

The problem is that ecl crashes when it cannot write to both stdout and stderr.
Therefore I'm reusing this bug for that related problem.

There is already an open upstream issue about this (see the forwarded URL).

Regards,
Ahzo

Bug#991750: nauty: segfaults during sagemath testsuite

[Ahzo]

Package: nauty
Version: 2.7r1+ds-2
Severity: important
Control: affects -1 sagemath

Hi,

during the sagemath testsuite, a nauty crash occurs. Nonetheless, the sagemath 
test passes:
sage -t --long --random-seed=0 src/sage/graphs/digraph_generators.py
    [150 tests, 6.44 s]

The crash can be easily reproduced:
$ nauty-gentourng -d0 -D1 -c 2
>A nauty-gentourng -cd1D0 n=2
Segmentation fault (core dumped)

Anyway, nauty should not crash like this, particularly since the input seems 
valid.

Regards,
Ahzo

Bug#913997: [Pkg-javascript-devel] Bug#940511: yarnpkg: Package symlink yarn -> yarnpkg

[Maël Nison]

Hi,

> Just to be clear, personally, I agree with the both original and the
> current cmdtest maintainers that this issue has been caused by the other
> upstream, and the other upstream's collaboration on a resolution has
> been poor.

I'd like to point out that no one in the current Yarn development team was
there when the project name was coined. Myself only joined it in 2017, far
too late to have any weight in its naming (2015 / 2016). By this time
changing the binary name was already quite difficult (we actually
experimented with it by also shipping a `yarnpkg` binary through npm, but
noone in our community really used it; and we couldn't remove `yarn` by
fear of breaking a lot of CIs - as a package manager, Yarn is often one of
the entry points to JavaScript, and keeping it stable is very important
...).

> I agree with the original maintainer that this namespace takeover attempt
> feels like bullying. "Mine is bigger than yours" is not a good argument
for
> anything in Debian.

I can't speak on behalf of the former Yarn team, but I can assure you that
the current one had no intent to bully anyone. We're all open-source
maintainers, and I'm sure you can resonate if I tell you that our only goal
is to make things as smooth as possible for our users - even people who
want to use both Yarn and cmdtest! My understanding was that these binary
conflict situations, although impractical for everyone, sometimes happen,
and my hope was that we could find a solution together. I initially
contacted Lars in 2019 and was given reasons to think that a renaming would
be possible, but our exchange was short and I failed to see how much
frustration you had with this situation - which I can understand.

Best regards,
Maël

Bug#991754: SpeechSynthesisVoice.lang is incorrect

[Juliusz Chroboczek]

Package: firefox
Version: 88.0.1-1

Run the following code:

voices = window.speechSynthesis.getVoices();
voices[0].lang;

This returns something like:

"sk-STEPH3"

which is not a correct language code, and breaks language matching against
e.g. navigator.languages.

Bug#950609: systemd: backlight service messes with screen brightness

[Michael Biebl]

On Fri, 7 Feb 2020 20:29:25 +0100 Valerio Passini
 wrote:
> Hi Michael,
> 
> Il Ven 7 Feb 2020, 19:05 Michael Biebl  ha scritto:
> 
> > Control: tags -1 = moreinfo
> >
> > What exactly was not working? What did you do, what did you expect, what
> > did (not) happen.
> >
> 
> Screen brightness controls (the two keyboard buttons designed to tune
> brightness and the sliders in GNOME and KDE) are ineffective. If I press
> the buttons or I move the slider, the OSD shows that brightness is
changing
> while actually it's not. I expect that brightness is being regulated by my
> actions.
> 
> systemd-backlight@.service simply stores the current backlight value on
> > shutdown and restores it on boot.
> > It reads from /sys/class/backlight/*/brightness and writes accordingly.
> > If that somehow confuses the hardware, this smells like a driver/kernel
> > issue.
> >
> > Michael
> >
> 
> I know that it seems unrelated to systemd-backlight, that service should
> store and restore brightness through reboots, but here:
>
https://devtalk.nvidia.com/default/topic/1061387/linux/screen-brightness-resets-to-max-after-reboot-linux-/
> I have found that systemd-backlight is keeping brightness to maximum and
so
> I tried to disable it just to see if my problem would be fixed, and so it
> is.
> The real culprit might be something else as you said previously, but at
the
> moment it is a decent workaround for me and it might be worth
investigating
> it further.
> 
> Tell me if you need more info. Best regards

Is this problem still reproducible?
If so, is it specific to the proprietary NVIDIA driver or also reproducible
with the noveau driver?



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

Bug#947688: systemd-networkd: Python socket.getfqdn() not working properly when resolv.conf lacks "domain" key

[Michael Biebl]

On Wed, 25 Nov 2020 03:27:20 +0100 Michael Biebl  wrote:
> If it's still reproducible, can you raise this upstream please at
> https://github.com/systemd/systemd/issues
> 


Any updates here?



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

Bug#991753: python3-scipy: build with pythran support

[Drew Parsons]

Package: python3-scipy
Version: 1.7.0-1
Severity: normal
Control: block -1 by 991143

Build scipy with pythran support by dropping SCIPY_USE_PYTHRAN=0 from
debian/rules as soon as possible, in order to enhance scipy runtime
performance.

Bug#991752: python-scipy-doc: build docs with sphinx-panels

[Drew Parsons]

Package: python-scipy-doc
Version: 1.7.0-1
Severity: normal
Control: block -1 by 991684

Remove debian patch docs_skip_panels.patch as soon as possible.

Otherwise parts of doc layout is incomplete.

Bug#960231: kubernetes: provision of 'kubeadm' command-line utility

[James Addison]

Hello - adding a small reminder/bump on this bug; it would be useful
to have the kubeadm command available as a package alongside the other
Kubernetes tools and binaries.  If there's an alternative plan for how
to provide that, please let me know - or I can refresh the patch soon.

Thanks,
James

Bug#991751: ITP: golang-github-traefik-paerser -- CLI commands handling system

[Alois Micard]

Package: wnpp
Severity: wishlist
Owner: Aloïs Micard 

* Package name: golang-github-traefik-paerser
  Version : 0.1.4-1
  Upstream Author : Traefik Labs
* URL : https://github.com/traefik/paerser
* License : Apache-2.0
  Programming Lang: Go
  Description : CLI commands handling system

This package is needed for Traefik.
Cheers,

Bug#970546: RFP: golang-github-cli-cli -- GitHub’s official command line tool

[Anthony Fok]

Control: merge 951374 970546

On Fri, Sep 18, 2020 at 5:57 AM Vipul  wrote:
> Package: wnpp
> Severity: wishlist
>
> * Package name: golang-github-cli-cli
>   Version : 1.0.0
>   Upstream Author : Github 
> * URL : https://cli.github.com/
> * License : MIT License
>   Programming Lang: Go
>   Description : GitHub’s official command line tool
>
> Github CLI brings Github to terminal. It reduces context switching,
> helps focus and create own workflows. With lastest stable version of
> Github CLI 1.0, we can:
> - Run entire Github workflow from terminal from issues to releases
> - Call the Github APIs to script any action
> - Set custom aliases, etc...
>
> See Github's blog post on Github CLI 1.0 release[1] for more
> information.
>
> [1]: https://github.blog/2020-09-17-github-cli-1-0-is-now-available/

Hi Vipul and João Paulo,

There is an earlier RFP in Bug #970546, so I am merging these two
RFP/ITP requests.
The proposed package names differ.
We may end up naming the package as either "gh" or "github-cli".
We'll see.  :-)

Cheers,

Anthony

Bug#981045: ITP: golang-github-yuin-goldmark-emoji -- Emoji extension for the goldmark markdown parser

[Anthony Fok]

Control: owner -1 !

On Mon, Jan 25, 2021 at 10:54 AM Joao Paulo Lima de Oliveira
 wrote:
> * Package name: golang-github-yuin-goldmark-emoji
>   Version : 1.0.1-1
>   Upstream Author : Yusuke Inuzuka
> * URL : https://github.com/yuin/goldmark-emoji
> * License : MIT
>   Programming Lang: Go
>   Description : Emoji extension for the goldmark markdown parser
>
>  Provide an emoji extension for the gold mark marking analyzer.

Hi João Paulo,

Thank you for your ITP!

As I needed this package too, so I packaged and uploaded it to Salsa
and to the NEW queue:

* https://salsa.debian.org/go-team/packages/golang-github-yuin-goldmark-emoji
* https://ftp-master.debian.org/new.html

Cheers,

Anthony

Bug#982541: ITP: golang-github-shurcool-graphql -- Provides a GraphQL client implementation

[Anthony Fok]

Control: owner -1 !

On Thu, Feb 11, 2021 at 4:30 AM Joao Paulo Lima de Oliveira
 wrote:
> * Package name: golang-github-shurcool-graphql
>   Version : 0.0~git20200928.18c5c31-1
>   Upstream Author : Dmitri Shuralyov 
>   Description : Provides a GraphQL client implementation

Hi João Paulo,

Thank you for your ITP!

As I needed this package too, so I packaged and uploaded it to Salsa
and to the NEW queue:

* https://salsa.debian.org/go-team/packages/golang-github-shurcool-graphql
* https://ftp-master.debian.org/new.html

Cheers,

Anthony

Bug#991704: [Pkg-pascal-devel] Bug#991704: lazarus-ide-qt5-2.0: lazarus-qt5 does not depend on lcl-qt5

[Paul Gevers]

Hi Hannah,

On 30-07-2021 14:44, Hannah Rittich wrote:
> On a fresh install of Bullseye, installing lazarus-ide-qt5 does not
> install lcl-qt5.

This is by design. As the Lazarus IDE *can* be used as an editor we have
chosen to not have it depend on lcl-qt5.

> Starting Lazarus und trying to execute a new GUI
> project fails with a linker error ("cannot find -lQt5Pas"). Installing
> the package lcl-qt5 allows for a proper compilation. For a better
> usability, the Qt version of Lazarus should depend on lcl-qt5.

However, I do agree we should have it somehow pulled in on systems that
use Lazarus with Qt5 instead of Gtk2. Or maybe we should just simply
complement the "Depends: lcl-gtk2-2.0 (= ${binary:Version}) |
lcl-qt5-2.0 (= ${binary:Version}" in lcl-units-2.0 with a "Recommends:
lcl-gtk2-2.0 (= ${binary:Version}), lcl-qt5-2.0 (= ${binary:Version}" to
have them both installed by default.

Abou, what do you think?

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#982538: ITP: golang-github-shurcool-githubv4 -- Client library for accessing GitHub GraphQL API v4

[Anthony Fok]

Control: owner -1 !

On Thu, Feb 11, 2021 at 4:18 AM Joao Paulo Lima de Oliveira
 wrote:
> * Package name: golang-github-shurcool-githubv4
>   Version : 0.0~git20201206.234843c-1
>   Upstream Author : Dmitri Shuralyov 
> * URL : https://github.com/shurcooL/githubv4
> * License : MIT
>   Programming Lang: Go
>   Description : Client library for accessing GitHub GraphQL API v4

Hi João Paulo,

Thank you for your ITP!

As I needed this package too, so I packaged and uploaded it to NEW and
to Salsa.  See:

* https://ftp-master.debian.org/new.html
* https://salsa.debian.org/go-team/packages/golang-github-shurcool-githubv4

Cheers,

Anthony

Bug#981074: ITP: golang-github-muesli-reflow -- Collection of ANSI-aware methods

[Anthony Fok]

Control: owner -1 !

On Mon, Jan 25, 2021 at 4:51 PM Joao Paulo Lima de Oliveira
 wrote:
> * Package name: golang-github-muesli-reflow
>   Version : 0.2.0-1
>   Upstream Author : Christian Muehlhaeuser 
> * URL : https://github.com/muesli/reflow
> * License : MIT
>   Programming Lang: Go
>   Description : Collection of ANSI-aware methods

Hi João Paulo,

Thank you for your ITP!

As I needed this package too, so I packaged and uploaded it to NEW and
to Salsa.  See:

* https://ftp-master.debian.org/new.html
* https://salsa.debian.org/go-team/packages/golang-github-muesli-reflow

Cheers,

Anthony

Bug#901332: d-i: Offer to shut down / power off instead of reboot at the end

[Thorsten Glaser]

Package: debian-installer
Followup-For: Bug #901332
X-Debbugs-Cc: t...@mirbsd.de

Did anything ever come from this, now that we’re nearing a release?


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

Kernel: Linux 5.10.0-8-amd64 (SMP w/2 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Bug#991750: nauty: segfaults during sagemath testsuite

[Torrance, Douglas]

Control: forwarded -1 na...@anu.edu.au

FYI, the segfault below was just reported in Debian.

On Sat, 31 Jul 2021 21:11:10 +0200 (CEST) Ahzo  wrote:
> Package: nauty
> Version: 2.7r1+ds-2
> Severity: important
> Control: affects -1 sagemath
> 
> Hi,
> 
> during the sagemath testsuite, a nauty crash occurs. Nonetheless, the 
> sagemath test passes:
> sage -t --long --random-seed=0 src/sage/graphs/digraph_generators.py
>     [150 tests, 6.44 s]
> 
> The crash can be easily reproduced:
> $ nauty-gentourng -d0 -D1 -c 2
> >A nauty-gentourng -cd1D0 n=2
> Segmentation fault (core dumped)
> 
> Anyway, nauty should not crash like this, particularly since the input seems 
> valid.
> 
> Regards,
> Ahzo

Bug#991715: screen: zombie child

[Vincent Lefevre]

As I don't remember having such an issue in the past, a possible cause
might have been one of the following recent upgrades:

krb5 1.17-3+deb10u1 → 1.17-3+deb10u2
linux-signed-amd64 4.19.194-2 → 4.19.194-3
systemd 241-7~deb10u7 → 241-7~deb10u8

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

Bug#991738: unblock: gdcm/3.0.8-2 (pre-approval)

[Étienne Mollier]

Hi again,

I confirm the remaining tests results are consistent with the
yet to be uploaded gdcm/3.0.8-2:
> Build   Tests   Package (remark)
> --  --  
> [ OK ]  [ OK ]  auto-multiple-choice (autopkgtest needs writable home)
> [ OK ]  [NONE]  itksnap
> [ OK ]  [NONE]  kylin-scanner
> [ OK ]  [(OK)]  monado (superficial)
> [ OK ]  [NONE]  mrpt
> [ OK ]  [NONE]  nifti2dicom
> [ OK ]  [ OK ]  node-opencv
> [ OK ]  [ OK ]  octave-dicom
> [ OK ]  [NONE]  opencfu
> [ OK ]  [FAIL]  openimageio (unhandled autodep8-python3, not a regression)
> [ OK ]  [NONE]  orthanc-gdcm
> [ OK ]  [NONE]  os-autoinst
> [ OK ]  [NONE]  otb
> [ OK ]  [NONE]  php-facedetect
> [ OK ]  [NONE]  pitivi
> [ OK ]  [NONE]  plastimatch
> [ OK ]  [NONE]  pragha
> [ OK ]  [NONE]  pulseeffects
> [ OK ]  [ OK ]  pytorch
> [ OK ]  [NONE]  qimgv
> [ OK ]  [ OK ]  ros-image-pipeline
> [ OK ]  [(OK)]  ros-opencv-apps (superficial)
> [ OK ]  [(OK)]  ros-vision-opencv (superficial)
> [ OK ]  [NONE]  sayonara
> [ OK ]  [NONE]  siril
> [ OK ]  [NONE]  slowmovideo
> [ OK ]  [NONE]  uprightdiff
> [ OK ]  [ OK ]  visp (must run against version 3.3.0-5+d1 and not 3.3.0-5)
> [ OK ]  [(OK)]  vtk-dicom (superficial)

Have a nice day,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/3, please excuse my verbosity.


signature.asc
Description: PGP signature

Bug#991747: dh-make-golang: create-salsa-project gives unexpected HTTP status code

[Anthony Fok]

Package: dh-make-golang
Version: 0.4.0-1+b6
Severity: normal
X-Debbugs-Cc: f...@debian.org

This is probably a rather recent phenomenon:

$ dh-make-golang create-salsa-project golang-github-muesli-reflow
2021/07/31 13:03:02 unexpected HTTP status code: got 500, want 200 
(response: POST https://salsa.debian.org/api/v4/projects/61855/runners: 404 
{message: 404 Not found}
)

The git repo on Salsa is created, but probably the CI/CD runner set up
is incomplete.  I suspect that the default runner for go-team is no
longer available.

Perhaps either dh-make-golang or some Salsa setting needs to be updated.
To be investigated.

-- System Information:
Debian Release: 11.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages dh-make-golang depends on:
ii  git   1:2.32.0-1
ii  git-buildpackage  0.9.22
ii  golang-any2:1.15~1
ii  libc6 2.31-13
ii  pristine-tar  1.49

Versions of packages dh-make-golang recommends:
ii  exim4-daemon-light [mail-transport-agent]  4.94.2-7
ii  golang-golang-x-tools  1:0.1.0+ds-1+b5

dh-make-golang suggests no packages.

-- no debconf information

Bug#991748: ITP: r-cran-vroom -- GNU R package to read and write rectangular data quickly

[Dirk Eddelbuettel]

Package: wnpp
Owner: Dirk Eddelbuettel 
Severity: wishlist

* Package name: r-cran-vroom
  Version : 1.5.3
  Upstream Author : James Hester and Hadley Wickham
* URL or Web page : https://cran.r-project.org/package=vroom
* License : MIT
  Description : GNU R package to read and write rectangular data quickly

This is now a build-depends of (r-cran-)readr which has long been part of
Debian.  This package depends on (r-cran-)tzdb which is still in the NEW
queue so I won't upload it for now, but the packaging is all done in the
salsa repo at https://salsa.debian.org/edd/r-cran-vroom -- it also needs
r-cran-cpp11 from experimental.

Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#991613: DHCPv6 problem in our image: needs "-D LL" when spawning dhclient

[Bastian Blank]

Hi

Looking again at the DUID reported by Ubuntu:
| 00:02:00:00:ab:11:11:16:f0:97:0e:c5:c9:b6

00:02: the type is enterprise number
00:00:ab:11, aka 43793: systemd
11:16:f0:97:0e:c5:c9:b6: this is by default a hash of the machine id, so
does change as well, or is this using the UUID set by the firmware?

Does /etc/machine-id have different contents if you rebuild the system
using different but similar enough Ubuntu images?

On Sat, Jul 31, 2021 at 06:03:33PM +0200, Thomas Goirand wrote:
> > So dnsmasq is wrongly configured to take the DUID into account, even if
> > it does not matter for the address selection, because the address is
> > fixed?
> Do you have any suggestion on how to start dnsmasq, so it doesn't take
> DUID into account? Is there any parameter to do that?

I have no idea.  You should talk to Neutron(?) upstream for that.  It is
quiet possible that dnsmasq does not support this usecase at all.  I
wasn't able to find anything with reading sources within some minutes.

> FYI, I've just opened a thread in the openstack-discuss list to see if
> this can be fixed. Though ideally, it'd be nice to have both my
> deployment AND the image fixed for this problem, so nobody can ever
> encounter the issue again.

At least it needs to be added to the documentation prominently, because
regardless of what we do, a server rebuild will randomly drop systems
out of the ipv6 net.

Bastian

-- 
Spock: The odds of surviving another attack are 13562190123 to 1, Captain.

Bug#918812:

[Alex Bennée]

I've hit what I think is a thin related issue on upgrading to
bullseye/testing. My boot hangs on fsck timing out on the 3 thin
provisioned partitions. I manually did a vgchange -ay to active them but it
didn't solve the problem. If I drop into maintenance mode and manually
"mount -a" things do mount and I can exit and continue the boot.

I'm not sure the best way to further diagnose this and see if it's really
related.

-- 
Alex Bennée
KVM/QEMU Hacker for Linaro

Bug#963742: spl-dkms missing makefile

[Ryan Richter]

In installing the latest kernel update on buster-LTS, I had this same
problem.  The file /var/lib/dkms/spl/0.6.5.9/build/make.log says:

DKMS make.log for spl-0.6.5.9 for kernel 4.19.0-0.bpo.17-amd64 (x86_64)
Sat Jul 31 12:49:28 EDT 2021
make: *** No targets specified and no makefile found.  Stop.




ls /var/lib/dkms/spl/0.6.5.9/build/
aclocal.m4   cmd/configure.ac   DISCLAIMER  Makefile.am  META
spl_config.h.in
AUTHORS  config/ copy-builtin*  dkms.conf   Makefile.in  module/
spl.release.in
autogen.sh*  config.log  COPYINGinclude/make.log rpm/
build/   configure*  cp*lib/man/
scripts/



So indeed there appears to be no makefile.

This is a very serious bug as it makes it impossible to install kernel
security updates without losing zfs!

Thanks,
-ryan

Bug#991746: RM: gitlab-workhorse/8.54.2+debian-1

[praveen]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm
Control: block 990889 by -1

Affected by rc bug 990889 but not needed in bullseye (it's only reverse 
dependency is gitlab)

See #991745 for an explanation why it can't be removed from unstable yet even 
though it is now
built from src:gitlab now.

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

Kernel: Linux 4.19.0-10-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_IN:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#991727: cryptsetup: insserv: FATAL: service cryptdisks-early has to be enabled to use service cryptdisks

[Thorsten Glaser]

Dixi quod…

>I was just installing cryptsetup and cryptsetup-bin to move to
>encrypted swap and got this:

>Setting up cryptsetup-bin (2:2.3.5-1) ...
>Setting up cryptsetup (2:2.3.5-1) ...
>insserv: FATAL: service cryptdisks-early has to be enabled to use service 
>cryptdisks

An interesting observation:

When I did 'sudo cleanenv / /etc/init.d/cryptdisks-early start' after
the installation, I needed to manually confirm that, yes, I want to
overwrite the existing signature (swap) from the block device. Maybe
this is what caused that error? I had changed /etc/crypttab before
installing the packages so maybe that…

… though, on the other hand, insserv is just for ordering init scripts,
right? Perhaps something else was the cause — I’m just noting my ob‐
servation.

bye,
//mirabilos
-- 
 exceptions: a truly awful implementation of quite a nice idea.
 just about the worst way you could do something like that, afaic.
 it's like anti-design.   that too… may I quote you on that?
 sure, tho i doubt anyone will listen ;)

Bug#991745: RM: src:gitlab-workhorse -- ROM; gitlab-workhorse binary package is now built from src:gitlab

[Pirate Praveen]

Package: ftp.debian.org
Severity: normal
Control: block 990889 by -1
Control: block -1 by 989084

gitlab-workhorse binary package is now built by src:gitlab, but since 
ruby-declarative-policy is still in NEW, we can't upload the src:gitlab 
package to the archive yet (this is currently served from my personal 
repo https://people.debian.org/~praveen/staging/). So once 
ruby-declarative-policy is accepted and src:gitlab including 
gitlab-workhorse binary package hits the archive src:gitlab-workhorse 
can be removed.


Since 990889 is affecting the version in bullseye, it can be removed 
from bullseye already (since it is an rc bug). I'm filing a bug with 
release team for this.

Bug#990889: gitlab-workhorse: contains non-free image testdata/image.svg

[Pirate Praveen]

Control: clone -1 -2
Control: reassign -2 gitlab

On Sat, 10 Jul 2021 18:20:03 +0200 Jonas Smedegaard  wrote:
> Package: gitlab-workhorse
> Version: 8.54.2+debian-1
> Severity: serious
> Justification: Policy 2.3
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> The SVG image testdata/image.svg in the source package declares in 
its
> RDF metadata that 
http://www.w3.org/2007/10/sw-logos.html#LogoWithoutW3C

> is its license.
>
> That license is limited to non-commercial distribution.

Forwarded it upstream 
https://gitlab.com/gitlab-org/gitlab/-/issues/337373


Though gitlab-workhorse binary is now built from gitlab source package, 
so src:gitlab-workhorse should be removed (I'll file a removal request).

Bug#991738: unblock: gdcm/3.0.8-2 (pre-approval)

[Étienne Mollier]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Hello Release Team,

Please unblock package gdcm

This is a pre-approval request, because I am waiting for a
double check of my test results, and there are notorious CPU
cycles hogs in the queue.  I hope to be able to upload this
evening UTC+0200.

[ Reason ]
libgdcm-dev, a binary package from the source package gdcm, is
affected by the serious bug #989296; this update ought to
address it.

[ Impact ]
gdcm has more than ten thousand installations reported by
popcon.  libgdcm-dev has numerous reverse dependencies, and
reverse build dependencies.  A removal might seriously cripple
the distribution, as it might pull out a handful of Gnome
components, scientific and medical imaging tools, or OpenCV and
related packages.

[ Tests ]
The package has been tested against the default Salsa CI:
  * lintian fails on errors unrelated to the present change:
E: gdcm source: invalid-profile-name-in-build-profiles-field nocil
  * the package building is known to not be reproducible to day;
  * otherwise all jobs went alright.

I tried to make sure my change did not impede the buildability
of libgdcm-dev reverse build dependencies, nor their
autopkgtest.  So far, I have not seen any build failure when
testing all reverse dependencies in Testing, and none of the few
failure in autopkgtest I could witness were actual regressions.
The test below have been double checked against the version in
the debdiff attached:

Build   Tests   Package (remark)
--  --  
[ OK ]  [NONE]  actiona
[ OK ]  [ OK ]  beads
[ OK ]  [ OK ]  caffe
[ OK ]  [ OK ]  camitk
[ OK ]  [(OK)]  cheese (superficial)
[ OK ]  [NONE]  cimg
[ OK ]  [NONE]  darknet
[ OK ]  [NONE]  digikam
[ OK ]  [NONE]  elastix
[ OK ]  [NONE]  empathy
[ OK ]  [NONE]  eviacam
[ OK ]  [ OK ]  freecad
[ OK ]  [NONE]  ginkgocadx
[ OK ]  [NONE]  gmic
[ OK ]  [NONE]  gnome-contacts
[ OK ]  [NONE]  gnome-control-center
[ OK ]  [NONE]  gnome-dvb-daemon
[ OK ]  [NONE]  gnome-initial-setup
[ OK ]  [NONE]  gnome-sound-recorder
[ OK ]  [NONE]  gst-plugins-bad1.0
[ OK ]  [NONE]  gst-rtsp-server1.0
[ OK ]  [FAIL]  gstreamer-editing-services1.0 (unhandled autodep8-python3, not 
a regression)
[ OK ]  [NONE]  gstreamer-vaapi
[ OK ]  [ OK ]  opencv
[ OK ]  [NONE]  sight
[ OK ]  [NONE]  insighttoolkit4

The tests below have been verified against a slightly different
version which was deemed uncorrect while discussing the issue in
bug #989296.  They are pending a second verification at the time
of writing this unblock request:

Build   Tests   Package (remark)
--  --  
[ OK ]  [ OK ]  auto-multiple-choice (autopkgtest needs writable home)
[ OK ]  [NONE]  itksnap
[ OK ]  [NONE]  kylin-scanner
[ OK ]  [(OK)]  monado (superficial)
[ OK ]  [NONE]  mrpt
[ OK ]  [NONE]  nifti2dicom
[ OK ]  [ OK ]  node-opencv
[ OK ]  [ OK ]  octave-dicom
[ OK ]  [NONE]  opencfu
[ OK ]  [FAIL]  openimageio (unhandled autodep8-python3, not a regression)
[ OK ]  [NONE]  orthanc-gdcm
[ OK ]  [NONE]  os-autoinst
[ OK ]  [NONE]  otb
[ OK ]  [NONE]  php-facedetect
[ OK ]  [NONE]  pitivi
[ OK ]  [NONE]  plastimatch
[ OK ]  [NONE]  pragha
[ OK ]  [NONE]  pulseeffects
[ OK ]  [ OK ]  pytorch
[ OK ]  [NONE]  qimgv
[ OK ]  [ OK ]  ros-image-pipeline
[ OK ]  [(OK)]  ros-opencv-apps (superficial)
[ OK ]  [(OK)]  ros-vision-opencv (superficial)
[ OK ]  [NONE]  sayonara
[ OK ]  [NONE]  siril
[ OK ]  [NONE]  slowmovideo
[ OK ]  [NONE]  uprightdiff
[ OK ]  [ OK ]  visp (must run against version 3.3.0-5+d1 and not 3.3.0-5)
[ OK ]  [(OK)]  vtk-dicom (superficial)

[ Risks ]
gdcm is a quite complex package.  libgdcm-dev has 5 reverse
dependencies and more than 50 reverse build dependencies.  I
estimate risks related to gdcm upload to be much higher than the
average unblock request, hence the extensive test report.  That
being said, the change is very targeted.

[ Checklist ]
  [*] all changes are documented in the d/changelog
  [*] I reviewed all changes and I approve them
  [*] attach debdiff against the package in testing

[ Other info ]
I'm sorry for the change in a package of that magnitude this
late in the release cycle.  Thank you very much for your titan
work on releasing Debian 11!

unblock gdcm/3.0.8-2

Have a nice day,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/3, please excuse my verbosity.
diff -Nru gdcm-3.0.8/debian/changelog gdcm-3.0.8/debian/changelog
--- gdcm-3.0.8/debian/changelog 2020-12-17 20:30:50.0 +0100
+++ gdcm-3.0.8/debian/changelog 2021-07-31 10:32:44.0 +0200
@@ -1,3 +1,12 @@
+gdcm (3.0.8-2) unstable; urgency=medium
+
+  * Team upload.
+  * d/rules: adjust GDCMTargets-*.cmake to detect libvtkgdcmsharpglue.so and
+vtkgdcmPython.cpython-*-*.so properly.
+Closes: #989296
+
+ -- Étienne Mollier   Sat, 31 Jul 2021 10:32:44 +0200
+
 gdcm (3.0.8-1) unstable; urgency=medium
 
   [ 

Bug#991613: DHCPv6 problem in our image: needs "-D LL" when spawning dhclient

[Thomas Goirand]

Hi Bastian,

Thanks for replying.

On 7/30/21 10:03 AM, Bastian Blank wrote:
> Hi
> 
> On Wed, Jul 28, 2021 at 05:22:43PM +0200, Thomas Goirand wrote:
>> - Initial boot:
>> 2021-07-28T12:26:38.804683+00:00 pub1-network-3 dnsmasq-dhcp[3765807]: 
>> DHCPSOLICIT(tap67fa8c3f-8d) 00:01:00:01:28:94:09:7b:fa:16:3e:f1:a9:da
>> 2021-07-28T12:26:38.805023+00:00 pub1-network-3 dnsmasq-dhcp[3765807]: 
>> DHCPADVERTISE(tap67fa8c3f-8d) 00:01:00:01:28:94:09:7b:fa:16:3e:f1:a9:da no 
>> addresses available
>>
>> - Server side:
>> /var/lib/neutron/dhcp/dcf25c41-9057-4bc2-8475-a2e3c5d8c662/host:fa:16:3e:f1:a9:da,tag:dhcpv6,host---143.dc3-a.pub1.infomaniak.cloud.,[::143]
>> /var/lib/neutron/dhcp/dcf25c41-9057-4bc2-8475-a2e3c5d8c662/leases:1627481056 
>> 1056025050 2001:1600:10:100::143 host---143 
>> 00:01:00:01:28:94:03:11:fa:16:3e:f1:a9:da
> 
> So dnsmasq is wrongly configured to take the DUID into account, even if
> it does not matter for the address selection, because the address is
> fixed?

Do you have any suggestion on how to start dnsmasq, so it doesn't take
DUID into account? Is there any parameter to do that?

> 
>> We see here that DHCPv6 fails because the DUID sent by the distro isn't the
>> same as the initial build of the VM:
> 
> Well, the pending change in network machinery will scramble the DUID
> anyway.  So you can't rely on it.

Ok, so probably I can fix the way dnsmasq start. In OpenStack, there's
enough options to add whatever I want.

Here's how currently, dnsmasq starts for me (anonymised though...):

dnsmasq --no-hosts --no-resolv \

--pid-file=/var/lib/neutron/dhcp/dcf25c41-9057-4bc2-8475-a2e3c5d8c662/pid 
--dhcp-hostsfile=/var/lib/neutron/dhcp//host
\
  --addn-hosts=/var/lib/neutron/dhcp//addn_hosts \
  --dhcp-optsfile=/var/lib/neutron/dhcp//opts \
  --dhcp-leasefile=/var/lib/neutron/dhcp//leases \
  --dhcp-match=set:ipxe,175 \
  --dhcp-userclass=set:ipxe6,iPXE \
  --local-service \
  --bind-dynamic \

--dhcp-range=set:subnet-,,static,255.255.255.0,86400s
\

--dhcp-range=set:subnet-,::,static,64,86400s
\
  --dhcp-option-force=option:mtu,1500 \
  --dhcp-lease-max=16777216 \
  --conf-file=/dev/null \
  --domain=something.example.com.

In dhcp_agent.ini it's possible to set dnsmasq_config_file = to some
value, and then if I can set anything that avoids the problem there...

So far, I haven't found a way (even after reading dnsmasq's man page,
but I may have missed something...).

FYI, I've just opened a thread in the openstack-discuss list to see if
this can be fixed. Though ideally, it'd be nice to have both my
deployment AND the image fixed for this problem, so nobody can ever
encounter the issue again.

Cheers,

Thomas Goirand (zigo)

Bug#991531: marked as done (unblock: nvidia-graphics-drivers/470.57.02-2 et.al. (pre-approval))

[Sebastian Ramacher]

Control: reopen -1

On 2021-07-31 15:45:03 +, Debian Bug Tracking System wrote:
> Your message dated Sat, 31 Jul 2021 15:41:27 +
> with message-id 
> and subject line unblock nvidia-graphics-drivers
> has caused the Debian Bug report #991531,
> regarding unblock: nvidia-graphics-drivers/470.57.02-2 et.al. (pre-approval)
> to be marked as done.
> 
> This means that you claim that the problem has been dealt with.
> If this is not the case it is now your responsibility to reopen the
> Bug report if necessary, and/or fix the problem forthwith.
> 
> (NB: If you are a system administrator and have no idea what this
> message is talking about, this may indicate a serious mail system
> misconfiguration somewhere. Please contact ow...@bugs.debian.org
> immediately.)
> 
> 
> -- 
> 991531: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991531
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

> Date: Mon, 26 Jul 2021 23:56:39 +0200
> From: Andreas Beckmann 
> To: Debian Bug Tracking System 
> Subject: unblock: nvidia-graphics-drivers/470.57.02-2 et.al. (pre-approval)
> Message-ID: 
> <162733659966.23021.11404777187079415217.report...@zam504.zam.kfa-juelich.de>
> 
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Hi,
> 
> I'd like to upgrade the "current" nvidia driver in sid from the 460 to
> the 470 series. The 470 series was promoted to release state with the
> CVE fixes last week.
> 
> The 460 series is a production branch with update support for 1 year.
> The 470 series is (supposed to be) a long term support branch with
> updates for 3 years.
> https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-470-Ends-Kepler
> So we will be switching to 470 during the lifetime of bullseye anyway,
> therefore let's better start there right away.
> Post-470 nvidia plans to drop support for some ancient cards, so it is
> very unlikely that we will switch to a post-470 driver in bullseye.
> In previous stable releases we also sticked to such a long term support
> branch once we had reached it (390 in stretch, 418 in buster)
> 
> nvidia-graphics-drivers and nvidia-settings (and an older 470 version of
> nvidia-modprobe) are already available in experimental. The other ones
> are quickly uploadable to sid, too. The packages need to be kept in sync
> at the major version to avoid confusion.
> 
> Anyway, I'd like to see 460.91.03-1 migrate first before I upload 470.*
> to sid.
> 
> (there are intentionally no diffs attached, yet)
> 
> unblock nvidia-graphics-drivers/470.57.02-2
> unblock nvidia-settings/470.57.02-2
> unblock nvidia-modprobe/470.57.02-1
> unblock nvidia-persistenced/470.57.02-1
> unblock nvidia-xconfig/470.57.02-1
> 
> Andreas

> Date: Sat, 31 Jul 2021 15:41:27 +
> From: Sebastian Ramacher 
> To: 991531-d...@bugs.debian.org
> Subject: unblock nvidia-graphics-drivers
> Message-Id: 
> 
> Unblocked.

That went to the wrong bug.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#991701: unblock: python-a38/0.1.3-2

[Sebastian Ramacher]

Control: tags -1 moreinfo confirmed

On 2021-07-30 14:06:10 +0200, Elena ``of Valhalla'' wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please unblock package python-a38
> 
> [ Reason ]
> The attached debdiff provides a fix for bug
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991648 , a test suite
> failure caused by an expired certificate that causes an FTBFS.
> 
> Upstream fixed this by updating the certificate used by the tests, but
> as in this context a certificate with no expiration wouldn't work they
> also added code to let the tests be skipped when even that certificate
> expires.
> 
> Since backporting that patch resulted in an unwieldy debdiff, I opted to
> just skip the affected tests in the resulting package.
> 
> Both upstream and me are sure that this is purely a broken test issue,
> and not a hint of a problem in the code.
> 
> [ Tests ]
> [ Risks ]
> The change only affects the unit tests of the package, and won't change
> the behaviour of the library.
> 
> The only risk I can see is that this would make the automated tests less
> effective at detecting potential future breakage, but I'd expect that to
> happen in testing rather than stable, and I intend to upload a version
> that re-enables the tests (by using the upstream fix) as soon as
> development for bookworm starts.
> 
> [ Checklist ]
>   [✓] all changes are documented in the d/changelog
>   [✓] I reviewed all changes and I approve them
>   [✓] attach debdiff against the package in testing
> 
> [ Other info ]
> thanks in advance
> 
> unblock python-a38/0.1.3-2

This appears to be a pre-approval request. Please go ahead, but keep in
mind that the window for bullseye is closing.

Cheers


> diff -Nru python-a38-0.1.3/debian/changelog python-a38-0.1.3/debian/changelog
> --- python-a38-0.1.3/debian/changelog 2020-12-18 11:44:31.0 +0100
> +++ python-a38-0.1.3/debian/changelog 2021-07-30 12:01:58.0 +0200
> @@ -1,3 +1,9 @@
> +python-a38 (0.1.3-2) unstable; urgency=medium
> +
> +  * Skip tests that fail because of an expired certificate. (Closes: #991648)
> +
> + -- Elena Grandi   Fri, 30 Jul 2021 12:01:58 +0200
> +
>  python-a38 (0.1.3-1) unstable; urgency=medium
>  
>[ Ondřej Nový ]
> diff -Nru 
> python-a38-0.1.3/debian/patches/0001-Skip-tests-that-fail-because-of-an-expired-certifica.patch
>  
> python-a38-0.1.3/debian/patches/0001-Skip-tests-that-fail-because-of-an-expired-certifica.patch
> --- 
> python-a38-0.1.3/debian/patches/0001-Skip-tests-that-fail-because-of-an-expired-certifica.patch
>1970-01-01 01:00:00.0 +0100
> +++ 
> python-a38-0.1.3/debian/patches/0001-Skip-tests-that-fail-because-of-an-expired-certifica.patch
>2021-07-30 12:01:58.0 +0200
> @@ -0,0 +1,30 @@
> +From: Elena Grandi 
> +Date: Fri, 30 Jul 2021 12:00:27 +0200
> +Forwarded: not-needed
> +Subject: Skip tests that fail because of an expired certificate.
> +
> +---
> + tests/test_p7m.py | 6 --
> + 1 file changed, 4 insertions(+), 2 deletions(-)
> +
> +diff --git a/tests/test_p7m.py b/tests/test_p7m.py
> +index e955bd4..fe982e7 100644
> +--- a/tests/test_p7m.py
>  b/tests/test_p7m.py
> +@@ -1,4 +1,4 @@
> +-from unittest import TestCase
> ++from unittest import TestCase, skip
> + import tempfile
> + from contextlib import contextmanager
> + import os
> +@@ -39,7 +39,9 @@ WGPH+t5X7ZMMERXn8Z/2LTYWuj9w1+WeieY=
> + 
> + CA_CERT_HASH = "af603d58.0"
> + 
> +-
> ++# The following tests are failing because of an expired certificate, and
> ++# a certificate with no expiration wouldn't work in this context.
> ++@skip("certificate expired")
> + class TestAnagrafica(TestCase):
> + @contextmanager
> + def capath(self):
> diff -Nru python-a38-0.1.3/debian/patches/series 
> python-a38-0.1.3/debian/patches/series
> --- python-a38-0.1.3/debian/patches/series1970-01-01 01:00:00.0 
> +0100
> +++ python-a38-0.1.3/debian/patches/series2021-07-30 12:01:58.0 
> +0200
> @@ -0,0 +1 @@
> +0001-Skip-tests-that-fail-because-of-an-expired-certifica.patch


-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#991311: cancelation bug report 991311

[Lucien Gentis]

Please ignore this bug report.

File version mismatch.

Lucien Gentis

Bug#990069: openssh-server: Not accepting new connections during Debian 10 -> 11 upgrade

[Ron]

Hi,

Sadly I can confirm this problem still persists in 2.31-13 too.  I found
it (before I found this report of it) yesterday upgrading a fully up to
date buster vm to bullseye ...

In my case I noticed it at the first conffile prompt when trying to ssh
a new connection into the vm failed, which was after the first prompting
from libc to restart services (and ssh was not included in the list of
services to restart then).

I can confirm that manually restarting ssh (while the upgrade was still
in progress) did fix it to enable logins again.

The interesting bit of the upgrade log is included below - I'm not sure
offhand exactly how the libc restart logic is coded, but at first blush
I'd note the new openssh-server is unpacked but not set up at the time
the libc service restart takes place ...

  Cheers,
  Ron

Unpacking openssh-sftp-server (1:8.4p1-5) over (1:7.9p1-10+deb10u2) ...
Preparing to unpack .../openssh-client_1%3a8.4p1-5_amd64.deb ...
Unpacking openssh-client (1:8.4p1-5) over (1:7.9p1-10+deb10u2) ...
Preparing to unpack .../runit-helper_2.10.3_all.deb ...
Unpacking runit-helper (2.10.3) ...
Preparing to unpack .../openssh-server_1%3a8.4p1-5_amd64.deb ...
Unpacking openssh-server (1:8.4p1-5) over (1:7.9p1-10+deb10u2) ...
Preparing to unpack .../libc6_2.31-13_amd64.deb ...
Checking for services that may need to be restarted...
Checking init scripts...
Unpacking libc6:amd64 (2.31-13) over (2.28-10) ...
Setting up libc6:amd64 (2.31-13) ...
Checking for services that may need to be restarted...
Checking init scripts...
Services to restart for GNU libc library upgrade:
cron atd
Restarting services possibly affected by the upgrade:
  cron: restarting...done.
  atd: restarting...done.
Services restarted successfully.
Preparing to unpack .../libc-bin_2.31-13_amd64.deb ...
Unpacking libc-bin (2.31-13) over (2.28-10) ...
Setting up libc-bin (2.31-13) ...
 ...
 
 ...
Setting up openssh-server (1:8.4p1-5) ...

Bug#991743: dh-cargo-built-using: abort: could not find static lib

[Christian Marillat]

Package: dh-cargo
Version: 24
Severity: normal

Dear Maintainer,

I'm trying to build rav1e 0.4.1 with debcargo :

debcargo package rav1e 0.4.1

But the build fail (from debian side) with :

Finished release [optimized + debuginfo] target(s) in 2m 09s
  Installing ./debian/rav1e/usr/bin/rav1e
   Installed package `rav1e v0.4.1 (/home/marillat/rust-rav1e-0.4.1)` 
(executable `rav1e`)
warning: be sure to add `./debian/rav1e/usr/bin` to your PATH to be able to run 
the installed binaries
debian cargo wrapper: running subprocess (['rm', '-f', 
'./debian/rav1e/usr/.crates.toml'],) {}
debian cargo wrapper: running subprocess (['rm', '-f', 
'./debian/rav1e/usr/.crates2.json'],) {}
debian cargo wrapper: running subprocess ('ls -td 
"target/x86_64-unknown-linux-gnu/release/build/rav1e"-*/out 2>/dev/null | head 
-n1',) {'shell': True, 'stdout': -1}
debian cargo wrapper: running subprocess (['ln', '-sfT', 
'../target/x86_64-unknown-linux-gnu/release/build/rav1e-1d850cd7bcbee84b/out', 
'debian/cargo_out_dir'],) {'check': True}
/usr/share/cargo/bin/dh-cargo-built-using: abort: could not find static lib 
'rav1easm'; rustc should have failed already?
dh_auto_install: error: /usr/share/cargo/bin/dh-cargo-built-using rav1e 
returned exit code 1
make: *** [debian/rules:4: binary-arch] Error 25

But :

$ find -name librav1easm.a
./target/x86_64-unknown-linux-gnu/release/build/rav1e-1d850cd7bcbee84b/out/librav1easm.a


Christian

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

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dh-cargo depends on:
ii  cargo  0.47.0-3+b1
ii  debhelper  13.3.4
ii  perl   5.32.1-4
ii  python33.9.2-3

dh-cargo recommends no packages.

dh-cargo suggests no packages.

-- no debconf information

Bug#991742: ITP: r-cran-gprofiler2 -- Interface to the 'g:Profiler' Toolset

[Nilesh Patra]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: nil...@debian.org

Subject: ITP: r-cran-gprofiler2 -- Interface to the 'g:Profiler' Toolset
Package: wnpp
Owner: Nilesh Patra 
Severity: wishlist

* Package name: r-cran-gprofiler2
  Version : 0.2.0
  Upstream Author : Liis Kolberg , Uku Raudvere 

* URL : https://cran.r-project.org/package=gprofiler2
* License : GPL-2+
  Programming Lang: GNU R
  Description : Interface to the 'g:Profiler' Toolset
 A toolset for functional enrichment analysis and visualization,
 gene/protein/SNP identifier conversion and mapping orthologous genes
 across species via 'g:Profiler' (). The
 main tools are:
 (1) 'g:GOSt' - functional enrichment analysis and visualization of
 gene lists;
 (2) 'g:Convert' - gene/protein/transcript identifier conversion across
 various namespaces;
 (3) 'g:Orth' - orthology search across species;
 (4) 'g:SNPense' - mapping SNP rs identifiers to chromosome positions,
 genes and variant effects This package is an R interface
 corresponding to the 2019 update of 'g:Profiler' and provides access
 to 'g:Profiler' for versions 'e94_eg41_p11' and higher. See the
 package 'gProfileR' for accessing older versions from the
 'g:Profiler' toolset.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-gprofiler2

Bug#991741: libtgowt: forward the utf8 "fix" ?

[Mattia Rizzolo]

Source: libtgowt
Version: 0~git20201218.6eaebec+ds-1
Severity: wishlist

Hi,

d/rules has this line:

|execute_after_dh_auto_install:
|# Cut non UTF-8 bytes off to silence national-encoding Lintian warning. Regex 
taken from https://stackoverflow.com/a/1401716/5000805
|   find $(INCLUDE_DIR) -type f -print0 | xargs -0 perl -pi -e 
's/((?:[\x00-\x7F]|[\xC0-\xDF][\x80-\xBF]|[\xE0-\xEF][\x80-\xBF]{2}|[\xF0-\xF7][\x80-\xBF]{3}){1,100})|./$$1/g'

I personally find such line in the debianization somewhat of an eyesore
every time I see it.

I wonder if it would be possible to instead forward it upstream in the
form of a proper patch?

Likewise, I think it should be trivial to get the upstream build system
to stop creating empty dirs.  (Somewhat unsure about the third one.)

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#991592: nvidia-cuda-toolkit: NVVMIR_LIBRARY_DIR on ppc64le points to wrong location

[Andreas Beckmann]

On 28/07/2021 12.42, Alex Waite wrote:

The ppc64el machines I have are all in production (and running buster), so I 
can't test this on a real system. But I unpacked 
nvidia-cuda-toolkit_11.2.2-3_ppc64el.deb and the config file looks to be sane 
in that version.


Can you use the packages from buster-backports?


Andreas

Bug#991740: ITP: graphql-core -- GraphQL implementation for Python

[Carsten Schoenert]

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

* Package name: graphql-core
  Version : 3.1.5
  Upstream Author : Christoph Zwerschke 
* URL : https://github.com/graphql-python/graphql-core
* License : MIT
  Programming Lang: Python
  Description : GraphQL implementation for Python

 GraphQL-core 3 is a Python 3.6+ port of GraphQL.js, the JavaScript reference
 implementation for GraphQL, a query language for APIs created by Facebook.
 GraphQL-core provides a reference implementation for the GraphQL
 specification but is also a useful utility for operating on GraphQL files
 and building sophisticated tools.

This package is an direct dependency for the next major version of
NetBox (will be version 3) which I consider to package.

The package will get maintained within the Debian Python Team.

Bug#989296: [RFR] libgdcm-dev/3.0.8-2 (to close #989296)

[Étienne Mollier]

Salut Mathieu,

Mathieu Malaterre, on 2021-07-31:
> On Fri, Jul 30, 2021 at 9:21 PM Étienne Mollier  wrote:
> > So, if I understood correctly #711214 and #989296, then it seems
> > to me that, once vtkgdcmsharpglue and vtkgdcmPython are detected
> > properly, the remaining messages will be warnings only.  They
> > won't impede the build; that is, until the shared objects are
> > effectively needed, in which case one should install the
> > components independently.  So the fix to d/rules is sufficient,
> > no need to touch d/control to address that bug, I guess.
> 
> Right ! The point is that on some arch you still want to be able to
> install libgdcm-dev without the cil (C# binding is not available
> everywhere) or vtk (may require opengl related package which would be
> hard to install on headless server).

Thanks for the confirmation, I wait for my batch of tests to
finish and will proceed to upload and unblock request today.

Have a nice day,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/3, please excuse my verbosity.


signature.asc
Description: PGP signature

Bug#991737: unblock: node-url-parse/1.5.3-1

[Yadd]

Le 31/07/2021 à 13:25, Yadd a écrit :
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please unblock package node-url-parse
> 
> [ Reason ]
> node-url-parse 1.5.1 is vulnerable to URL redirection to untrusted
> sites.
> 
> [ Impact ]
> Medium security issue
> 
> [ Tests ]
> Test passed (both build & autopkgtest)
> 
> [ Risks ]
> Low risk: node-url-parse is a reverse dependency of:
>  * node-miragejs (Build only)
>  * node-original
>* node-eventsource
> 
> I tested rebuild & autopkgtest with success:
>   rebuild  node-miragejs ... PASS
>   autopkgtest  node-original ... PASS
>   rebuild  node-original ... PASS
> 
> [ Checklist ]
>   [X] all changes are documented in the d/changelog
>   [X] I reviewed all changes and I approve them
>   [X] attach debdiff against the package in testing
> 
> [ Other info ]
> I prefered to update node-url-parse instead of backporting changes since
> all changes are related to this vulnerabilities (including test updates)

References:
 * commits list: https://github.com/unshiftio/url-parse/commits/master
 * 1.5.2 changes:
   - Sanitize only special URLs (#209)
 https://github.com/unshiftio/url-parse/pull/209
 * 1.5.3 changes:
   - Fix host parsing for file URLs (#210)
 https://github.com/unshiftio/url-parse/commit/c7984617

1.5.3 changes are based on 1.5.2 changes, that's why I can't backport
only security fix.

Cheers,
Yadd

Bug#991737: unblock: node-url-parse/1.5.3-1

[Yadd]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package node-url-parse

[ Reason ]
node-url-parse 1.5.1 is vulnerable to URL redirection to untrusted
sites.

[ Impact ]
Medium security issue

[ Tests ]
Test passed (both build & autopkgtest)

[ Risks ]
Low risk: node-url-parse is a reverse dependency of:
 * node-miragejs (Build only)
 * node-original
   * node-eventsource

I tested rebuild & autopkgtest with success:
  rebuild  node-miragejs ... PASS
  autopkgtest  node-original ... PASS
  rebuild  node-original ... PASS

[ Checklist ]
  [X] all changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in testing

[ Other info ]
I prefered to update node-url-parse instead of backporting changes since
all changes are related to this vulnerabilities (including test updates)

You will find 2 debdiff:
 * full debdiff
 * relevant debdiff (only index.js changes)

Cheers,
Yadd

unblock node-url-parse/1.5.3-1
diff --git a/index.js b/index.js
index 72b27c0..c6052d5 100644
--- a/index.js
+++ b/index.js
@@ -2,8 +2,9 @@
 
 var required = require('requires-port')
   , qs = require('querystringify')
-  , slashes = /^[A-Za-z][A-Za-z0-9+-.]*:[\\/]+/
-  , protocolre = /^([a-z][a-z0-9.+-]*:)?([\\/]{1,})?([\S\s]*)/i
+  , slashes = /^[A-Za-z][A-Za-z0-9+-.]*:\/\//
+  , protocolre = /^([a-z][a-z0-9.+-]*:)?(\/\/)?([\\/]+)?([\S\s]*)/i
+  , windowsDriveLetter = /^[a-zA-Z]:/
   , whitespace = 
'[\\x09\\x0A\\x0B\\x0C\\x0D\\x20\\xA0\\u1680\\u180E\\u2000\\u2001\\u2002\\u2003\\u2004\\u2005\\u2006\\u2007\\u2008\\u2009\\u200A\\u202F\\u205F\\u3000\\u2028\\u2029\\uFEFF]'
   , left = new RegExp('^'+ whitespace +'+');
 
@@ -32,8 +33,8 @@ function trimLeft(str) {
 var rules = [
   ['#', 'hash'],// Extract from the back.
   ['?', 'query'],   // Extract from the back.
-  function sanitize(address) {  // Sanitize what is left of the address
-return address.replace('\\', '/');
+  function sanitize(address, url) { // Sanitize what is left of the address
+return isSpecial(url.protocol) ? address.replace(/\\/g, '/') : address;
   },
   ['/', 'pathname'],// Extract from the back.
   ['@', 'auth', 1], // Extract from the front.
@@ -98,6 +99,24 @@ function lolcation(loc) {
   return finaldestination;
 }
 
+/**
+ * Check whether a protocol scheme is special.
+ *
+ * @param {String} The protocol scheme of the URL
+ * @return {Boolean} `true` if the protocol scheme is special, else `false`
+ * @private
+ */
+function isSpecial(scheme) {
+  return (
+scheme === 'file:' ||
+scheme === 'ftp:' ||
+scheme === 'http:' ||
+scheme === 'https:' ||
+scheme === 'ws:' ||
+scheme === 'wss:'
+  );
+}
+
 /**
  * @typedef ProtocolExtract
  * @type Object
@@ -110,20 +129,56 @@ function lolcation(loc) {
  * Extract protocol information from a URL with/without double slash ("//").
  *
  * @param {String} address URL we want to extract from.
+ * @param {Object} location
  * @return {ProtocolExtract} Extracted information.
  * @private
  */
-function extractProtocol(address) {
+function extractProtocol(address, location) {
   address = trimLeft(address);
+  location = location || {};
+
+  var match = protocolre.exec(address);
+  var protocol = match[1] ? match[1].toLowerCase() : '';
+  var forwardSlashes = !!match[2];
+  var otherSlashes = !!match[3];
+  var slashesCount = 0;
+  var rest;
+
+  if (forwardSlashes) {
+if (otherSlashes) {
+  rest = match[2] + match[3] + match[4];
+  slashesCount = match[2].length + match[3].length;
+} else {
+  rest = match[2] + match[4];
+  slashesCount = match[2].length;
+}
+  } else {
+if (otherSlashes) {
+  rest = match[3] + match[4];
+  slashesCount = match[3].length;
+} else {
+  rest = match[4]
+}
+  }
 
-  var match = protocolre.exec(address)
-, protocol = match[1] ? match[1].toLowerCase() : ''
-, slashes = !!(match[2] && match[2].length >= 2)
-, rest =  match[2] && match[2].length === 1 ? '/' + match[3] : match[3];
+  if (protocol === 'file:') {
+if (slashesCount >= 2) {
+  rest = rest.slice(2);
+}
+  } else if (isSpecial(protocol)) {
+rest = match[4];
+  } else if (protocol) {
+if (forwardSlashes) {
+  rest = rest.slice(2);
+}
+  } else if (slashesCount >= 2 && isSpecial(location.protocol)) {
+rest = match[4];
+  }
 
   return {
 protocol: protocol,
-slashes: slashes,
+slashes: forwardSlashes || isSpecial(protocol),
+slashesCount: slashesCount,
 rest: rest
   };
 }
@@ -214,7 +269,7 @@ function Url(address, location, parser) {
   //
   // Extract protocol information before running the instructions.
   //
-  extracted = extractProtocol(address || '');
+  extracted = extractProtocol(address || '', location);
   relative = !extracted.protocol && 

Bug#991512: unblock: flatpak/1.10.2-3 (pre-approval)

[Simon McVittie]

Control: retitle -1 unblock: flatpak/1.10.2-3
Control: tags -1 - moreinfo

On Thu, 29 Jul 2021 at 19:46:18 +0200, Paul Gevers wrote:
> As we're getting very close to the release, the upload needs to happen
> soon. If it does, let's have this. Please remove the moreinfo tag once
> the upload happened.

Uploaded (sorry for the delay, I've been ill) and built on all release
architectures. If this is too late for 11.0 then so be it; it can turn
into a bullseye-pu request for 11.1.

smcv

Bug#991736: ITP: graphql-relay -- Relay Library for GraphQL Python

[Carsten Schoenert]

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

* Package name: graphql-relay
  Version : 3.1.0
  Upstream Author : Syrus Akbary 
* URL : https://github.com/graphql-python/graphql-relay-py
* License : MIT
  Programming Lang: Python
  Description : Relay Library for GraphQL Python

 This package contains the Relay (https://relay.dev/) library for GraphQL-core.
 .
 It allows the easy creation of Relay-compliant servers using GraphQL-core.
 GraphQL-Relay-Py is a Python port of graphql-relay-js
 (https://github.com/graphql/graphql-relay-js), while GraphQL-Core is a
 Python port of GraphQL.js (https://github.com/graphql/graphql-js), the
 reference implementation of GraphQL for JavaScript.

This package is an direct dependency for the next major version of
NetBox (will be version 3) which I consider to package.

The package will get maintained within the Debian Python Team.

Bug#991735: unblock: node-esquery/1.3.1~ds-4

[Yadd]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package node-esquery

[ Reason ]
FTBFS due to STDERR warning

[ Impact ]
FTBFS

[ Tests ]
Fixed

[ Risks ]
No risk

[ Checklist ]
  [X] all changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in testing

Cheers,
Yadd

unblock node-esquery/1.3.1~ds-4
diff --git a/debian/changelog b/debian/changelog
index 8ef57fa..e291d89 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+node-esquery (1.3.1~ds-4) unstable; urgency=medium
+
+  * Team upload
+  * Allow STDERR in autopkgtest
+
+ -- Yadd   Sat, 31 Jul 2021 12:46:10 +0200
+
 node-esquery (1.3.1~ds-3) unstable; urgency=medium
 
   * fix have autopkgtest depend on nodejs
diff --git a/debian/tests/control b/debian/tests/control
index dbf0d2d..05a9604 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -12,3 +12,4 @@ Depends:
  node-babel-register (>= 7),
  node-chai,
  node-esquery,
+Restrictions: allow-stderr

Bug#991734: unblock: node-caniuse-api/3.0.0-3

[Yadd]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package node-caniuse-api

[ Reason ]
FTBFS due to STDERR warning

[ Impact ]
autopkgtest fails

[ Tests ]
Fixed

[ Risks ]
No risk

[ Checklist ]
  [X] all changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in testing

Cheers,
Yadd

unblock node-caniuse-api/3.0.0-3
diff --git a/debian/changelog b/debian/changelog
index 5661f1f..24df880 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+node-caniuse-api (3.0.0-3) unstable; urgency=medium
+
+  * Team upload
+  * Fix GitHub tags regex
+  * Allow stderr in autopkgtest
+
+ -- Yadd   Sat, 31 Jul 2021 12:39:34 +0200
+
 node-caniuse-api (3.0.0-2) unstable; urgency=medium
 
   * Build with Babel 7
diff --git a/debian/tests/autopkgtest-pkg-nodejs.conf 
b/debian/tests/autopkgtest-pkg-nodejs.conf
new file mode 100644
index 000..f7694bb
--- /dev/null
+++ b/debian/tests/autopkgtest-pkg-nodejs.conf
@@ -0,0 +1 @@
+extra_restrictions=allow-stderr
diff --git a/debian/watch b/debian/watch
index e878e7a..0b7b347 100644
--- a/debian/watch
+++ b/debian/watch
@@ -2,4 +2,4 @@ version=3
 opts=\
 dversionmangle=s/\+(debian|dfsg|ds|deb)(\.\d+)?$//,\
 filenamemangle=s/.*\/v?([\d\.-]+)\.tar\.gz/node-caniuse-api-$1.tar.gz/ \
- https://github.com/nyalab/caniuse-api/tags .*/archive/v?([\d\.]+).tar.gz
+ https://github.com/nyalab/caniuse-api/tags .*/archive/.*/v?([\d\.]+).tar.gz

Bug#991733: unblock: node-browserslist/4.16.3+~cs5.4.72-3

[Yadd]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package node-browserslist

[ Reason ]
FTBFS due to STDERR warning

[ Impact ]
Fixes autopkgtest

[ Tests ]
autopkgtest fixed by this patch

[ Risks ]
No risk

[ Checklist ]
  [X] all changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in testing

Cheers,
Yadd

unblock node-browserslist/4.16.3+~cs5.4.72-3
diff --git a/debian/changelog b/debian/changelog
index f53ddc3..cd122a7 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+node-browserslist (4.16.3+~cs5.4.72-3) unstable; urgency=medium
+
+  * Team upload
+  * Add "allow-stderr" to autopkgtest
+
+ -- Yadd   Sat, 31 Jul 2021 12:27:44 +0200
+
 node-browserslist (4.16.3+~cs5.4.72-2) unstable; urgency=medium
 
   * Team upload
diff --git a/debian/tests/control b/debian/tests/control
index 7fa009c..ec2ee3a 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -1,8 +1,9 @@
 Test-Command: browserslist
 Depends: @
 Features: test-name=binary-test
+Restrictions: allow-stderr
 
 Test-Command: node debian/tests/CVE-2021-23364.js
 Depends: @
 Features: test-name=CVE-2021-23364
-Restrictions: superficial
+Restrictions: superficial, allow-stderr

Bug#990315: buster-pu: package gcc-mingw-w64/21.3~deb10u1

[Stephen Kitt]

On Sun, 18 Jul 2021 18:35:52 +0100, "Adam D. Barratt"
 wrote:
> On Fri, 2021-06-25 at 15:08 +0200, Stephen Kitt wrote:
> > 
> > Would it be possible to upload the backported fix for gcc-mingw-w64’s
> > #989862 to Buster? The debdiff is attached; it’s a minimal, targeted
> > fix for gcov support.
> 
> Please go ahead; sorry for the delay.

Done, thanks!

Regards,

Stephen


pgpWwqky08sSw.pgp
Description: OpenPGP digital signature

Bug#979460: xfce4-panel: Multiple problems in Status Tray plugin (Xfce 4.16)

[jaroslav]

Hello,

I am affected by this bug as well and I think as more people migrate to 
Bullseye, they will be affected too.


For me, the system tray is losing icons. I usually have 3 programs 
supposed to be shown in there: kalarm, psi and kteatime. Sometimes all 3 
of them are shown for a while but sometimes the tray doesn't even pick 
them up and shows only two (kalarm being the one affected the most and 
not showing most of the time.)


After some time of using the PC more icons gradually disappear, psi 
being the second most affected one. Since those programs are supposed to 
be minimized to tray most of the time, the only way to access them after 
this happens is restarting them (luckily, both programs detect their 
previous instance and make it appear - if that wasn't the case, only way 
to gain access to the program would be killing it from console and 
restarting it altogether)


When this happens, the following can be observed in system tray 
settings: right click panel - menu item "Panel" - "Panel Preferences..." 
- "Items" tab - double click "Status Tray Plugin". In the "Known Items" 
area, there are items for each application and those affected by this 
show light grey icon with darker gray exclamation mark in a triangle 
instead of their own icon - not sure how relevant this is though.


There is also a bug that affects kteatime. When it shows an "tea is 
ready" event, its icon changes to a light bulb and never reverts back, 
making it non-usable since there is no possibility to distinguish last 
event from a new one. This is reported at 
https://gitlab.xfce.org/xfce/xfce4-panel/-/issues/340 . I am not sure if 
this bug is related to the previous one.


I believe - if anyone has the time - that this bug should get some 
attention because, in my opinion, it has significant impact on usability 
of Xfce as a whole. If there are some patches to test and the 
xfce4-panel package can be rebuilt from source using apt-get source and 
dpkg-buildpackage, I should be able to provide testing and feedback.


Thanks

Bug#991732: python3-pcbasic: package description says Python2 instead of 3

[Daniele Forsi]

Package: python3-pcbasic
Severity: minor
X-Debbugs-Cc: dfo...@gmail.com

Dear maintainer,

the short package descriptoin says "Python2", but this package is for Python 3.
IMO, "Python 3" and "python3" would be correct, "Python3" is a thing that do 
not exist, just like "Python2".

tanks,
Daniele

Bug#989296: [RFR] libgdcm-dev/3.0.8-2 (to close #989296)

[Andreas Tille]

Hi Étienne,

On Sat, Jul 31, 2021 at 10:16:12AM +0200, Étienne Mollier wrote:
> 
> Thanks for the confirmation, I wait for my batch of tests to
> finish and will proceed to upload and unblock request today.

Thanks a lot.  That's very valuable work

 Andreas.


-- 
http://fam-tille.de

Bug#991731: unblock: fetchmail/6.4.16-4

[GCS]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Hi RMs,

I would like to ask for unblocking fetchmail, fixing a security issue.

[ Reason ]
When logging long messages, fetchmail might segfault or leak
information to logs.

[ Impact ]
Normal logging in all cases.

[ Tests ]
Local tests.

[ Risks ]
None.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

unblock fetchmail/6.4.16-4

Thanks for considering,
Laszlo/GCS
diff -Nru fetchmail-6.4.16/debian/changelog fetchmail-6.4.16/debian/changelog
--- fetchmail-6.4.16/debian/changelog	2021-06-26 23:53:00.0 +0200
+++ fetchmail-6.4.16/debian/changelog	2021-07-29 00:18:56.0 +0200
@@ -1,3 +1,10 @@
+fetchmail (6.4.16-4) unstable; urgency=high
+
+  * Backport upstream security fix for CVE-2021-36386: denial of service or
+information disclosure when logging long messages.
+
+ -- Laszlo Boszormenyi (GCS)   Thu, 29 Jul 2021 00:18:56 +0200
+
 fetchmail (6.4.16-3) unstable; urgency=medium
 
   * Fix operation autopkgtest.
diff -Nru fetchmail-6.4.16/debian/patches/11_fix_CVE-2021-38386.patch fetchmail-6.4.16/debian/patches/11_fix_CVE-2021-38386.patch
--- fetchmail-6.4.16/debian/patches/11_fix_CVE-2021-38386.patch	1970-01-01 01:00:00.0 +0100
+++ fetchmail-6.4.16/debian/patches/11_fix_CVE-2021-38386.patch	2021-07-29 00:18:56.0 +0200
@@ -0,0 +1,258 @@
+From c546c8299243a10a7b85c638e0e61396ecd5d8b5 Mon Sep 17 00:00:00 2001
+From: Matthias Andree 
+Date: Wed, 7 Jul 2021 16:22:57 +0200
+Subject: [PATCH] Fix SIGSEGV when resizing report*() buffer.
+
+Reported (with a different patch suggestion) by
+Christian Herdtweck .
+
+Note that vsnprintf() calls va_arg(), and depending on operating system,
+compiler, configuration, this will invalidate the va_list argument
+pointer, so that va_start has to be called again before a subsequent
+vsnprintf(). However, it is better to do away with the loop and the
+trial-and-error, and leverage the return value of vsnprintf instead for
+a direct one-off resizing, whilst taking into account that on SUSv2
+systems, the return value can be useless if the size argument to
+vsnprintf is 0.
+---
+ NEWS |  18 
+ report.c | 138 +++
+ 2 files changed, 95 insertions(+), 61 deletions(-)
+
+diff --git a/NEWS b/NEWS
+index 04239b16..67dc1f9e 100644
+--- a/NEWS
 b/NEWS
+@@ -64,6 +64,24 @@ removed from a 6.5.0 or newer release.)
+   for end-of-life OpenSSL versions may be removed even from patchlevel releases.
+ 
+ 
++fetchmail-6.4.20 (not yet released):
++
++# SECURITY FIX:
++* When a log message exceeds c. 2 kByte in size, for instance, with very long 
++  header contents, and depending on verbosity option, fetchmail can crash or
++  misreport each first log message that requires a buffer reallocation.
++  fetchmail then reallocates memory and re-runs vsnprintf() without another 
++  call to va_start(), so it reads garbage. The exact impact depends on 
++  many factors around the compiler and operating system configurations used and 
++  the implementation details of the stdarg.h interfaces of the two functions
++  mentioned before. To fix CVE-2021-38386.
++
++  Reported by Christian Herdtweck of Intra2net AG, Tübingen, Germany.
++
++  He also offered a patch, which I could not take for fetchmail 6.4 because
++  it required a C99 system and I'd promised earlier that 6.4 would remain
++  compatible with C89 systems.
++
+ fetchmail-6.4.16 (released 2021-02-08, 27707 LoC):
+ 
+ # BUG FIXES
+diff --git a/report.c b/report.c
+index 1466802a..aea6b3ea 100644
+--- a/report.c
 b/report.c
+@@ -44,6 +44,8 @@ static unsigned int partial_message_size = 0;
+ static unsigned int partial_message_size_used = 0;
+ static char *partial_message;
+ static int partial_suppress_tag = 0;
++/* default size for the allocation of the report buffer */
++const size_t defaultsize = 4096;
+ 
+ static unsigned unbuffered;
+ static unsigned int use_syslog;
+@@ -177,6 +179,27 @@ void report_init(int mode /** 0: regular output, 1: unbuffered output, -1: syslo
+ }
+ }
+ 
++static void rep_ensuresize(size_t increment) {
++if (partial_message_size == 0)
++{
++	/* initialization */
++	partial_message_size_used = 0;
++	/* avoid too many small allocations initially */
++	if (increment < defaultsize) increment = defaultsize;
++	partial_message_size = increment;
++	partial_message = (char *)MALLOC (partial_message_size);
++}
++else /* already have buffer -> resize if too little room */
++{
++	if (increment < defaultsize) increment = defaultsize;
++	if (partial_message_size - partial_message_size_used < increment)
++	{
++	partial_message

Bug#989296: [RFR] libgdcm-dev/3.0.8-2 (to close #989296)

[Mathieu Malaterre]

Salut Étienne,

On Fri, Jul 30, 2021 at 9:21 PM Étienne Mollier  wrote:
>
> Hi Mathieu,
>
> Mathieu Malaterre, on 2021-07-30:
> > Hi all,
> >
> > I've reviewed commit 92bee7344b774b45b66185ed17b040f12fe31c43. I've
> > not verified it fixes the OP symptoms, but this is the right fix IMHO.
> >
> > I've also reviewed cddfeab955f486fba72745b66130480dfec1a2b6 and this
> > is not the right fix, sorry. See #711214 for more context.
>
> No worries, Thank you for your review!  :)
>
> So, if I understood correctly #711214 and #989296, then it seems
> to me that, once vtkgdcmsharpglue and vtkgdcmPython are detected
> properly, the remaining messages will be warnings only.  They
> won't impede the build; that is, until the shared objects are
> effectively needed, in which case one should install the
> components independently.  So the fix to d/rules is sufficient,
> no need to touch d/control to address that bug, I guess.

Right ! The point is that on some arch you still want to be able to
install libgdcm-dev without the cil (C# binding is not available
everywhere) or vtk (may require opengl related package which would be
hard to install on headless server).

Debian packages should not be monolithic just because upstream failed
to implement proper *.cmake components packaging.

2cts

Bug#978727: bpfcc: Provide separate package for libbpf-tools?

[Vasudev Kamath]

Hello guys,

Sorry for delaying uploading this version. So I started working on the
libbpf-tools but I'm facing weird error when trying to build the package
in sbuild.

> /usr/sbin/bpftool gen skeleton .output/biolatency.bpf.o > 
> .output/biolatency.skel.h
> libbpf: failed to find BTF for extern 'KERNEL_VERSION': -2
> Error: failed to open BPF object file: No such file or directory

I'm not sure what is happening package builds fine on laptop so I'm
missing something. If you guys know what might be going wrong please let
me know :-).

Thanks and Regards
Vasudev

Bug#991730: libapache2-mod-auth-mellon: CVE-2021-3639: open redirect vulnerability

[Salvatore Bonaccorso]

Source: libapache2-mod-auth-mellon
Version: 0.17.0-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for libapache2-mod-auth-mellon.

CVE-2021-3639[0]:
| Prevent redirect to URLs that begin with '///'

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-3639
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3639
[1] 
https://github.com/latchset/mod_auth_mellon/commit/42a11261b9dad2e48d70bdff7c53dd57a12db6f5

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#891205: 私に戻ってください。 Please get back to me.

[Helen Brown]

私に戻ってください。
Please get back to me.

Bug#838137: 私に戻ってください。 Please get back to me.

[Helen Brown]

私に戻ってください。
Please get back to me.

Bug#971991: 私に戻ってください。 Please get back to me.

[Helen Brown]

私に戻ってください。
Please get back to me.

Bug#991729: fakeroot-ng: Breaks python asyncio.subprocess

[Daniel Schepler]

Package: fakeroot-ng
Version: 0.18-4.1
Severity: normal

As a small reproduction case (on amd64, using kernel 5.10.0-8-amd64):

daniel@frobnitz:/tmp$ cat asyncproc.py
import asyncio

async def task():
   proc = await asyncio.create_subprocess_exec('sleep', '1')
   await proc.wait()
   if proc.returncode != 0:
   raise RuntimeError('subprocess failed')

asyncio.run(task())
daniel@frobnitz:/tmp$ python3 asyncproc.py
daniel@frobnitz:/tmp$ fakeroot-ng python3 asyncproc.py

[1]+  Stopped fakeroot-ng python3 asyncproc.py
daniel@frobnitz:/tmp$ Unknown child process pid 34258, will report
returncode 255
Traceback (most recent call last):
 File "/tmp/asyncproc.py", line 9, in 
   asyncio.run(task())
 File "/usr/lib/python3.9/asyncio/runners.py", line 44, in run
   return loop.run_until_complete(main)
 File "/usr/lib/python3.9/asyncio/base_events.py", line 642, in
run_until_complete
   return future.result()
 File "/tmp/asyncproc.py", line 7, in task
   raise RuntimeError('subprocess failed')
RuntimeError: subprocess failed

[1]+  Exit 1  fakeroot-ng python3 asyncproc.py

-- 
Daniel Schepler

Bug#991688: mention improved/added man page translations

[Helge Kreutzmann]

Hello Justin,
hello Joost,
thanks a lot, I agree.

Greetings

Helge
-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#969952: 私に戻ってください。 Please get back to me.

[Helen Brown]

私に戻ってください。
Please get back to me.

Bug#890057: 私に戻ってください。 Please get back to me.

[Helen Brown]

私に戻ってください。
Please get back to me.

Bug#662064: 私に戻ってください。 Please get back to me.

[Helen Brown]

私に戻ってください。
Please get back to me.

Bug#581639: 私に戻ってください。 Please get back to me.

[Helen Brown]

私に戻ってください。
Please get back to me.

Bug#990069: openssh-server: Not accepting new connections during Debian 10 -> 11 upgrade

[Olaf van der Spek]

Package: libc6
Version: 2.31-13
Followup-For: Bug #990069
X-Debbugs-Cc: olafvds...@gmail.com

Dear Maintainer,

The original issue of not being able to open a new SSH connection during the 
upgrade still seems to be present.

Greetings,

Olaf

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

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

Versions of packages libc6 depends on:
ii  libcrypt1  1:4.4.18-4
ii  libgcc-s1  10.2.1-6

Versions of packages libc6 recommends:
ii  libidn2-0   2.3.0-5
ii  libnss-nis  3.1-4
ii  libnss-nisplus  1.3-4

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0]  1.5.77
pn  glibc-doc  
ii  libc-l10n  2.31-13
ii  locales2.31-13

-- debconf information:
  glibc/disable-screensaver:
  glibc/kernel-not-supported:
* libraries/restart-without-asking: true
  glibc/upgrade: true
  glibc/kernel-too-old:
  glibc/restart-services:
  glibc/restart-failed:

Bug#940230: 私に戻ってください。 Please get back to me.

[Helen Brown]

私に戻ってください。
Please get back to me.

Bug#821093: 私に戻ってください。 Please get back to me.

[Helen Brown]

私に戻ってください。
Please get back to me.

Bug#878289: 私に戻ってください。 Please get back to me.

[Helen Brown]

私に戻ってください。
Please get back to me.