Bug#979622: Wayland: No image on external display when reconnecting

[Oliver Sander]

Package: kscreen
Version: 4:5.20.5-1
Severity: normal

Apologies if I am not reporting this for the correct package.

I try the following steps:

1) Reboot my laptop (ThinkPad X1 Yoga) with external monitor plugged in.
   The external monitor works as expected.
2) At the SDDM prompt, log into Plasma Wayland.
   The external monitor still works as it should.
3) Disconnect the external monitor
   Still everything appears to work as it should.
4) Reconnect the monitor -- it remains black and tells me 'no signal'
   Nevertheless, the system settings dialog shows me that the
   external display is correctly recognized.  From looking
   at that dialog everything seems to be in order.
5) Log out of Plasma Wayland, and log back in.
6) The external display is back!

This does not happen with Plasma X11.



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

Kernel: Linux 5.10.0-1-amd64 (SMP w/8 CPU threads)
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 kscreen depends on:
ii  kde-cli-tools  4:5.20.5-2
ii  libc6  2.31-9
ii  libkf5configcore5  5.77.0-2
ii  libkf5coreaddons5  5.77.0-2
ii  libkf5dbusaddons5  5.77.0-2
ii  libkf5declarative5 5.77.0-2
ii  libkf5globalaccel-bin  5.77.0-3
ii  libkf5globalaccel5 5.77.0-3
ii  libkf5i18n55.77.0-2
ii  libkf5plasma5  5.77.0-2
ii  libkf5plasmaquick5 5.77.0-2
ii  libkf5quickaddons5 5.77.0-2
ii  libkf5screen-bin   4:5.20.5-1
ii  libkf5screen7  4:5.20.5-1
ii  libkf5xmlgui5  5.77.0-2
ii  libqt5core5a   5.15.2+dfsg-2
ii  libqt5dbus55.15.2+dfsg-2
ii  libqt5gui5 5.15.2+dfsg-2
ii  libqt5qml5 5.15.2+dfsg-2
ii  libqt5quick5   5.15.2+dfsg-2
ii  libqt5sensors5 5.15.2-2
ii  libqt5widgets5 5.15.2+dfsg-2
ii  libstdc++6 10.2.1-3
ii  plasma-framework   5.77.0-2
ii  qml-module-qtgraphicaleffects  5.15.2-2

Versions of packages kscreen recommends:
ii  upower  0.99.11-2

kscreen suggests no packages.

-- no debconf information



smime.p7s
Description: S/MIME Cryptographic Signature

Bug#979621: pandas: autopkgtest regression in testing: No tables found

[Paul Gevers]

Source: pandas
Version: 1.1.5+dfsg-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent change in testing the autopkgtest of your package started
to fail. I copied some of the output at the bottom of this report. Can
you please investigate the situation and fix it?

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

Paul
By the way: as your test is accessing the internet, you should add a
"needs-internet" restriction

https://ci.debian.net/data/autopkgtest/testing/amd64/p/pandas/9462264/log.gz

=== FAILURES
===
_ TestReadHtml.test_banklist_url_positional_match[bs4]
_

self = 

@tm.network
def test_banklist_url_positional_match(self):
url = "http://www.fdic.gov/bank/individual/failed/banklist.html;
# Passing match argument as positional should cause a FutureWarning.
with tm.assert_produces_warning(FutureWarning):
>   df1 = self.read_html(
url, "First Federal Bank of Florida", attrs={"id": "table"}
)



OpenPGP_signature
Description: OpenPGP digital signature

Bug#979135: chromium: GPU hw-accel: ANGLE libs cause a lot of errors and warnings

[Sedat Dilek]

Hi,

Jan Luca is working on a patch "Use desktop gl implementation as default"...

What about placing "--use-gl=desktop" in /etc/chromium.d/default-flags
as an alternative?

# Default for GPU hardware-acceleration (Debian bug #979135)
export CHROMIUM_FLAGS="$CHROMIUM_FLAGS --use-gl=desktop"

Cannot say if this is wanted behaviour - to enable GPU hw-accel by default?
Looks like a safer methon when GPU hw-accel is wanted.

In my logs I found references to Skia renderer...

[ chrome://flags ]

Skia API for compositing
If enabled, the display compositor will use Skia as the graphics API
instead of OpenGL ES. – Mac, Windows, Linux, Android
Here set to "Default"

[ chrome://gpu ]
Graphics Feature Status > Skia Renderer: Enabled

Cannot judge when not using ANGLE libs if there is a fallback to OpenGL ES.
Might be OpenGL ES renderer is the better choice?

I have not looked for the parameters and cannot say I will play with them.

( BTW, I played with Vulkan support enabled - slow performance here
with Intel Sandy Bridge GPU. )

Regards,
- Sedat -

[1] https://salsa.debian.org/janluca-guest/chromium/-/commits/angle_fix
[2] https://wiki.archlinux.org/index.php/chromium#Force_GPU_acceleration
[3] https://wiki.archlinux.org/index.php/chromium#Hardware_video_acceleration

Bug#979620: sonic-pi: flaky armhf and arm64 autopkgtest on ci.debian.net: unknown bpm

[Paul Gevers]

Source: sonic-pi
Version: 3.2.2~repack-6
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: flaky

Dear maintainer(s),

The autopkgtest of your package turned up as blocking xorg-server. I
looked into the history of your autopkgtest and it fails regularly on
arm64 and armhf [1, 2]. I copied some of the output at the bottom of
this report.

Because the unstable-to-testing migration software now blocks on
regressions in testing, flaky tests, i.e. tests that flip between
passing and failing without changes to the list of installed packages,
are causing people unrelated to your package to spend time on these
tests.

Please do get in touch if we need to dive into this together. Or if you
want to discuss this issue.

Paul

[1] https://ci.debian.net/packages/s/sonic-pi/testing/arm64/
[2] https://ci.debian.net/packages/s/sonic-pi/testing/armhf/

https://ci.debian.net/data/autopkgtest/testing/arm64/s/sonic-pi/9392735/log.gz

Source: sonic-pi
Version: 3.2.2~repack-6
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: flaky

Dear maintainer(s),

The autopkgtest of your package turned up as blocking xorg-server. I
looked into the history of your autopkgtest and it fails regularly on
arm64 and armhf [1, 2]. I copied some of the output at the bottom of
this report.

Because the unstable-to-testing migration software now blocks on
regressions in testing, flaky tests, i.e. tests that flip between
passing and failing without changes to the list of installed packages,
are causing people unrelated to your package to spend time on these
tests.

Please do get in touch if we need to dive into this together. Or if you
want to discuss this issue.

Paul

[1] https://ci.debian.net/packages/s/sonic-pi/testing/arm64/
[2] https://ci.debian.net/packages/s/sonic-pi/testing/armhf/

https://ci.debian.net/data/autopkgtest/testing/arm64/s/sonic-pi/9392735/log.gz

Buffer: 4.03s./4.03sTime: 0.09m.   DHP: [ ]  Overruns: 0
Xruns: 0
00:|
  |
01:| |
Buffer: 4.03s./4.03sTime: 0.09m.   DHP: [ ]  Overruns: 0
Xruns: 0
00:|
  |
01:| |
Buffer: 4.03s./4.03sTime: 0.09m.   DHP: [ ]  Overruns: 0
Xruns: 0


>>> Please wait while writing all data to disk. (shouldn't take long)
   |"|
00:|
  |
01:| |
Buffer: 4.05s./4.05sTime: 0.10m.   DHP: [ ]  Overruns: 0
Xruns: 0
00:|
  |
01:| |
Buffer: 4.05s./4.05sTime: 0.10m.   DHP: [ ]  Overruns: 0
Xruns: 0
Finished.
unknown bpm
autopkgtest [17:56:12]: test gui: ---]



OpenPGP_signature
Description: OpenPGP digital signature

Bug#892001: ITP: dbus-broker -- Linux D-Bus Message Broker

[Alex ARNAUD]

Le 08/01/2021 à 17:30, Luca Boccassi a écrit :

Gentle ping reg.
https://salsa.debian.org/utopia-team/dbus/-/merge_requests/8  as
deadlines are fast approaching - dbus-broker has cleared NEW, so I'd
like to sort out the details regarding repository and team
maintainership and make it available in unstable/testing. As a recap,
I'm totally on board with having it as part of the same team area as
dbus and with the same maintainers/uploaders.
We don't need to sort out the package split immediately or even for
bullseye, as it's made to be co-installable out of the box.

Thanks!

Hello Luca and thanks again for working on this,

I don't know if my request / question is too early in the process: do 
you plan to wrote a wiki page explaining how to enable it and replace 
gdbus with dbus-broker?


I'm pretty sure in the Debian a11y team we'll have some early adopter 
able to verify if everything works as Orca relies exclusively on dbus to 
work.


Best regards and happy new year all.

Bug#979612: firefox-esr: after upgrade from 78.6.0esr-1~deb10u1 to 78.6.1esr-1~deb10u1 gnome interface behave erratically

[Damien]

Package: firefox-esr
Version: 78.6.1esr-1~deb10u1
Severity: serious
Justification: 4

Dear Maintainer,

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

   * What led up to the situation?
I executed package updates and upgrades using apt

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I tried loggin out and back in, rebooting the host, none helped. 

   After running an apt upgrade on Debian 10 (Buster) running a Gnome Desktop, 
when Firefox is running, strange behavior takes place. 
1. Unable to grab and move windows of other applications like gedit. 
2. Unable to click or activate menu items of TorBrowser
3. Unable to close, click or access menu items of a multiple other application. 

When Firefox-ESR is closed, all above issues go away. 
When Firefox-ESR version  78.6.1esr-1~deb10u1 running, all kind of strange and 
unexpected behavior of the Gnome UI takes place.




-- Package-specific info:

-- Extensions information
Name: Amazon.com
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: Bing
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: Dark theme
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: user-disabled

Name: Default theme
Location: /usr/lib/firefox-esr/omni.ja
Package: firefox-esr
Status: enabled

Name: DoH Roll-Out
Location: /usr/lib/firefox-esr/browser/features/doh-roll...@mozilla.org.xpi
Package: firefox-esr
Status: enabled

Name: DuckDuckGo
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: eBay
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: Firefox Screenshots
Location: /usr/lib/firefox-esr/browser/features/screensh...@mozilla.org.xpi
Package: firefox-esr
Status: enabled

Name: Form Autofill
Location: /usr/lib/firefox-esr/browser/features/formautof...@mozilla.org.xpi
Package: firefox-esr
Status: enabled

Name: Google
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: HTTPS Everywhere
Location: ${PROFILE_EXTENSIONS}/https-everywh...@eff.org.xpi
Status: enabled

Name: Light theme
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: user-disabled

Name: uBlock Origin
Location: ${PROFILE_EXTENSIONS}/ublo...@raymondhill.net.xpi
Status: enabled

Name: Web Compat
Location: /usr/lib/firefox-esr/browser/features/webcom...@mozilla.org.xpi
Package: firefox-esr
Status: enabled

Name: WebCompat Reporter
Location: 
/usr/lib/firefox-esr/browser/features/webcompat-repor...@mozilla.org.xpi
Package: firefox-esr
Status: user-disabled

Name: Wikipedia (en)
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

-- Plugins information

-- Addons package information
ii  firefox-esr78.6.1esr-1~deb10u1 amd64Mozilla Firefox web browser 
- Extended Support Release (ESR)

-- 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-13-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages firefox-esr depends on:
ii  debianutils 4.8.6.1
ii  fontconfig  2.13.1-2
ii  libatk1.0-0 2.30.0-2
ii  libc6   2.28-10
ii  libcairo-gobject2   1.16.0-4
ii  libcairo2   1.16.0-4
ii  libdbus-1-3 1.12.20-0+deb10u1
ii  libdbus-glib-1-20.110-4
ii  libevent-2.1-6  2.1.8-stable-4
ii  libffi6 3.2.1-9
ii  libfontconfig1  2.13.1-2
ii  libfreetype62.9.1-3+deb10u2
ii  libgcc1 1:8.3.0-6
ii  libgdk-pixbuf2.0-0  2.38.1+dfsg-1
ii  libglib2.0-02.58.3-2+deb10u2
ii  libgtk-3-0  3.24.5-1
ii  libpango-1.0-0  1.42.4-8~deb10u1
ii  libstdc++6  8.3.0-6
ii  libx11-62:1.6.7-1+deb10u1
ii  libx11-xcb1 2:1.6.7-1+deb10u1
ii  libxcb-shm0 1.13.1-2
ii  libxcb1 1.13.1-2
ii  libxcomposite1  1:0.4.4-2
ii  libxdamage1 1:1.1.4-3+b3
ii  libxext62:1.3.3-1+b2
ii  libxfixes3  1:5.0.3-1
ii  libxrender1 1:0.9.10-1
ii  procps  2:3.3.15-2
ii  zlib1g  1:1.2.11.dfsg-1

Versions of packages firefox-esr recommends:
ii  libavcodec58  7:4.1.6-1~deb10u1

Versions of packages firefox-esr suggests:
pn  fonts-lmodern  
pn  fonts-stix | otf-stix  
ii  libcanberra0   0.30-7
ii  libgssapi-krb5-2   1.17-3+deb10u1
ii  libgtk2.0-02.24.32-3
ii  pulseaudio 12.2-4+deb10u1

-- no debconf information

Bug#979524: debian-reference: build-depends on libopencc2-data, which no longer exists

[Osamu Aoki]

Hi,

I think it is time to fix this bug and upload package.  Let me make
final check.  Osamu

On Fri, 2021-01-08 at 23:28 -0500, Boyuan Yang wrote:
> Hi,
> 
> 在 2021-01-08星期五的 09:49 +0800，xiao sheng wen(肖盛文)写道：
> > Hi,
> > 
> >  libopencc2-data had change name to libopencc-data in bullseye
> > sid.
> > 
> > As the opencc upstream had changed the version number, SONAME, etc.
> > 
> > Update debian-reference build-depends on libopencc-data should fix
> > this bug.
> 
> This bug as well as the python2->3 migration has long been fixed in
> git
> trunk. We just need another upload.
> 
> Osamu: do you have time to review all changes after 2.76 tag and make
> another upload for debian-reference package? This will fix at least
> one
> RC-buggy bug so it might be worthwhile to get fixed before freeze.
> 
> Thanks,
> Boyuan Yang
> 
> 
> > 在 2021/1/8 上午12:55, Ivo De Decker 写道:
> > > package: src:debian-reference
> > > version: 2.76
> > > tags: bullseye sid ftbfs
> > > severity: serious
> > > 
> > > Hi,
> > > 
> > > It seems debian-reference build-depends on libopencc2-data, which
> > > no longer
> > > exists.
> > > 
> > > Cheers,
> > > 
> > > Ivo
> > > 
> 
> 

Bug#979618: chromium freezes on start, triggering a force quit by gnome

[Lee Garrett]

Package: chromium
Version: 87.0.4280.88-0.4
Severity: grave
X-Debbugs-Cc: deb...@rocketjump.eu

Hi,

starting chromium on bullseye will render a window (with various elements
shifted down by half a screen), which is impossible to interact with, and causes
gnome to offer a "force quit" prompt after a few seconds.

Output from the CLI:
->8-->8-->8-->8-->8-->8-->8-->8-->8-->8-->8-
$ chromium
libva error: vaGetDriverNameByIndex() failed with unknown libva error, 
driver_name = (null)
[9413:9413:0109/060426.733876:ERROR:vaapi_wrapper.cc(541)] vaInitialize failed: 
unknown libva error
[9413:9413:0109/060426.735693:ERROR:sandbox_linux.cc(374)] InitializeSandbox() 
called with multiple threads in process gpu-process.
[9413:9413:0109/060426.855283:ERROR:shared_context_state.cc(74)] Skia shader 
compilation error


Errors:

[9413:9413:0109/060426.858413:ERROR:shared_context_state.cc(74)] Skia shader 
compilation error


Errors:

[9413:9413:0109/060426.860282:ERROR:shared_context_state.cc(74)] Skia shader 
compilation error


Errors:

[9413:9413:0109/060426.867099:ERROR:shared_context_state.cc(74)] Skia shader 
compilation error


Errors:

[9413:9413:0109/060426.869489:ERROR:shared_context_state.cc(74)] Skia shader 
compilation error


Errors:

[9415:9428:0109/060426.876651:ERROR:nss_util.cc(283)] After loading Root Certs, 
loaded==false: NSS error code: -8018
[9413:9413:0109/060426.993836:ERROR:shared_context_state.cc(74)] Skia shader 
compilation error


Errors:

[9413:9413:0109/060430.833703:ERROR:gl_surface_presentation_helper.cc(259)] 
GetVSyncParametersIfAvailable() failed for 1 times!
[9413:9413:0109/060430.839756:ERROR:gl_surface_presentation_helper.cc(259)] 
GetVSyncParametersIfAvailable() failed for 2 times!
Killed
->8-->8-->8-->8-->8-->8-->8-->8-->8-->8-->8-

Various things I've tried:
- reverting to chromium(,-common,-sandbox) to 87.0.4280.88-0.3 -> same problem
- reverting to chromium(,-common,-sandbox) to 87.0.4280.88-0.3 -> same problem
- starting chromium with a fresh profile -> same problem

Installing debug symbols and starting `chromium -g` will result in the same
errors, except for chromium complaining about being started in single-process
mode.

One user on #debian-next IRC reported no such errors on sid and KDE, so it might
not effect all users. I *think* about a week ago chromium still ran fine (I only
use it for debugging purposes). Checking /var/log/apt/history.log, I don't see
any libva* packages being updated in that timeframe.

Regards,
Lee


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

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

Versions of packages chromium depends on:
ii  chromium-common  87.0.4280.88-0.4
ii  libasound2   1.2.4-1.1
ii  libatk-bridge2.0-0   2.38.0-1
ii  libatk1.0-0  2.36.0-2
ii  libatomic1   10.2.1-3
ii  libatspi2.0-02.38.0-2
ii  libavcodec58 7:4.3.1-5
ii  libavformat587:4.3.1-5
ii  libavutil56  7:4.3.1-5
ii  libc62.31-6
ii  libcairo21.16.0-5
ii  libcups2 2.3.3op1-4
ii  libdbus-1-3  1.12.20-1
ii  libdrm2  2.4.103-2
ii  libevent-2.1-7   2.1.12-stable-1
ii  libexpat12.2.10-1
ii  libflac8 1.3.3-2
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.4+dfsg-1
ii  libgbm1  20.3.2-1
ii  libgcc-s110.2.1-3
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.4-1
ii  libgtk-3-0   3.24.24-1
ii  libharfbuzz0b2.6.7-1
ii  libicu67 67.1-5
ii  libjpeg62-turbo  1:2.0.5-2
ii  libjsoncpp24 1.9.4-4
ii  liblcms2-2   2.9-4+b1
ii  libminizip1  1.1-8+b1
ii  libnspr4 2:4.29-1
ii  libnss3  2:3.60-1
ii  libopenjp2-7 2.3.1-1
ii  libopus0 1.3.1-0.1
ii  libpango-1.0-0   1.46.2-3
ii  libpangocairo-1.0-0  1.46.2-3
ii  libpng16-16  1.6.37-3
ii  libpulse014.0-2
ii  libre2-9 20201101+dfsg-2
ii  libsnappy1v5 1.1.8-1
ii  libstdc++6   10.2.1-3
ii  libwebp6 0.6.1-2+b1
ii  libwebpdemux20.6.1-2+b1
ii  libwebpmux3  0.6.1-2+b1
ii  libx11-6 2:1.6.12-1
ii  libx11-xcb1  2:1.7.0-1
ii  libxcb1  1.14-2.1
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1   

Bug#979617: tcplay: VeraCrypt support

[KenichiroMATOHARA]

Package: tcplay
Version: 1.1-6
Severity: normal

Dear Maintainer,

It seems that VeraCrypt is supported in 3.0 in the upstream of tcplay.
https://github.com/bwalex/tc-play/blob/master/CHANGELOG#L15

I hope it will be updated so that VeraCrypt can be used.



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

Kernel: Linux 5.10.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_CRAP, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.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 tcplay depends on:
ii  libc6   2.31-9
ii  libdevmapper1.02.1  2:1.02.173-1
ii  libgcrypt20 1.8.7-2
ii  libgpg-error0   1.38-2
ii  libuuid12.36.1-4

tcplay recommends no packages.

tcplay suggests no packages.

-- no debconf information

Bug#979546: docker.io: version in Bullseye does not support "rootless mode", makes privilege escalation trivial

[El boulangero]

On Sat, Jan 9, 2021 at 2:00 AM Chris Mitchell  wrote:

> On Fri, 8 Jan 2021 11:38:59 +0700
> El boulangero  wrote:
>
> > Hi Chris,
> >
> > I believe what you refer to is a well-known issue with docker. I have
> > this reference from Apr. 2015:
> > https://fosterelli.co/privilege-escalation-via-docker.html
> >
> > This is how docker works. The most easy mitigation is NOT to add a
> > user to the docker group. This way, you will always invoke docker
> > with 'sudo docker', and then it's explicit that you're running
> > something as root. Explicit better than implicit maybe, at least no
> > more "accidental".
>
> This makes some sense. Given that it's apparently well-known that
> allowing a user to run Docker essentially gives them unrestricted root
> access, I'm rather surprised that no warning was presented at any point
> in this process.
>
> > Second thing, as you noted, docker can access a directory on the host
> > only if you share it with '--volume' or '--mount' or something. So
> > it's not really accidental if then the process in the container
> > writes to the host directory. It's something that you authorized
> > explicitly. And the fact that it's a root access is due to the fact
> > that the container is run as root, as you correctly noted.
>
> Ah, okay. This, I think, is where I fundamentally misunderstood the
> situation. I was picturing the "containerized app" as a single entity,
> presenting an all-or-nothing choice between "accept that anything you
> run in a Docker container has root access to your whole filesystem" or
> "don't use Docker". If Docker is providing meaningful enforcement and
> limiting the access of the "contained" app to only the directory(ies)
> you share with it in the container config (though not subject to the
> host system's *permissions*) that's a very different proposition.
>
> Trusting *myself* not to abuse Docker's privilege-escalation abilities
> (on a system where I already have root), checking carefully what paths
> are shared via the container configs, and making sure that the path
> containing those configs is never shared... That's within the realm of
> reasonable expectations.
>
> > If you download and run a containerized app as root, and share your
> > /home with the container, then you'd better trust this app 100%.
>
> To be clear, I did not knowingly or explicitly do any of these things
> except "download and run a containerized app". I downloaded the app as
> a regular user, used my sudo powers to add said user to the docker group
> (because all the "getting started" instructions just say that you need
> to be in the docker group to use Docker) and ran, as a regular user,
> "docker-compose -d up". Now that I know to go looking for it, I see
> that the "volumes" directive appears in one of the config files. While
> I acknowledge that the responsibility for understanding the tools I use
> ultimately falls to me, nothing in this sequence jumps out to me as
> "you are granting unrestricted root access!" or "you'd better trust
> this app 100%".
>

I never used docker-compose, only the docker command itself, so I've always
known more or less what was going on :)

docker-compose is a layer on top of docker, so it hides things away from
the user (in this case, the arguments for the docker command are in a
config file apparently). So things are even less explicit, for the sake of
simplicity.

I think two important things are 1) *which user* is running in the
container (root or non-root), and what volumes are shared. These are the
arguments that you would use the most often with 'docker run', and also the
king of things you'd want to check in a docker compose file.

There are many ways to run container with docker, depending on the
use-case. If you want to run a container manually, as your own user, and
while sharing only the current directory, you can do this:

sudo docker run -it --rm \
-u $(id -u):$(id -g) \
-v /etc/group:/etc/group:ro \
-v /etc/passwd:/etc/passwd:ro \
-v $(pwd):$(pwd) -w $(pwd) \
$YOUR_DOCKER_IMAGE

Note that the two first -v arguments are optional, but they allow that you
user id is known in the container. Try with and without, both work.

This is a command that I use often, but when you get started with docker,
it's unlikely you'll find that by yourself at the first try :)


>
> As a fairly experienced Debian user, I've been accustomed to add myself
> to all sorts of groups over the years, and the only one that has ever
> been presented as "this grants full root powers" is sudo, which then
> pops up a stern warning the first time you use it. Also it's sudo. Its
> singular, stated purpose is to grant root powers. The fact that no
> warning popped up anywhere along the way to discovering that my
> supposedly sandboxed Docker app was creating files as root on the host
> strikes me as alarming.
>
> In my defence, I knew I was playing with things I didn't understand, so
> the "regular user" in question 

Bug#979524: debian-reference: build-depends on libopencc2-data, which no longer exists

[Boyuan Yang]

Hi,

在 2021-01-08星期五的 09:49 +0800，xiao sheng wen(肖盛文)写道：
> Hi,
> 
>  libopencc2-data had change name to libopencc-data in bullseye
> sid.
> 
> As the opencc upstream had changed the version number, SONAME, etc.
> 
> Update debian-reference build-depends on libopencc-data should fix
> this bug.

This bug as well as the python2->3 migration has long been fixed in git
trunk. We just need another upload.

Osamu: do you have time to review all changes after 2.76 tag and make
another upload for debian-reference package? This will fix at least one
RC-buggy bug so it might be worthwhile to get fixed before freeze.

Thanks,
Boyuan Yang


> 在 2021/1/8 上午12:55, Ivo De Decker 写道:
> > package: src:debian-reference
> > version: 2.76
> > tags: bullseye sid ftbfs
> > severity: serious
> > 
> > Hi,
> > 
> > It seems debian-reference build-depends on libopencc2-data, which
> > no longer
> > exists.
> > 
> > Cheers,
> > 
> > Ivo
> > 

Bug#979616: cmake-fedora: Homepage has moved

[Boyuan Yang]

Source: cmake-fedora
Version: 2.7.2-1
Severity: normal
X-Debbugs-CC: czc...@debian.org

Dear Debian cmake-fedora package maintainer,

The upstream of cmake-fedora has migrated from fedorahosted.org to
pagure.io. Please use https://pagure.io/cmake-fedora/ as the new
upstream.

Since all reverse build dependencies are input method packages, it
would also be great if the package can be team-maintained under Debian
Input Method Team.

Thanks,
Boyuan Yang


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

Bug#979615: cmake-fedora: New version available (2.9.3)

[Boyuan Yang]

Source: cmake-fedora
Version: 2.7.2-1
Severity: normal
X-Debbugs-CC: czc...@debian.org

Dear cmake-fedora maintainer,

A new upstream release is available at
https://pagure.io/cmake-fedora/releases . Please consider packaging
this new version.

Regards,
Boyuan Yang


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

Bug#978192: xfce4-sensors-plugin: FTBFS: NVCtrlLib.h:42:1: error: unknown type name ‘Bool’; did you mean ‘bool’?

[Andreas Beckmann]

Followup-For: Bug #978192
Control: reassign -1 libxnvctrl-dev
Control: affects -1 + src:xfce4-sensors-plugin

NVCtrlLib.h uses macros from X11/Xlib.h but does not include that header.
So including NVCtrlLib.h only worked if X11/Xlib.h was accidentally
included earlier, which no longer is the case: rebuilding
xfce4-sensors-plugin/sid fails in sid and bullseye, but works in buster.

In buster the include chain was
  /usr/include/xfce4/libxfce4panel-2.0/libxfce4panel/xfce-panel-macros-46.h
  /usr/include/gtk-3.0/gdk/gdkx.h
  /usr/include/X11/Xlib.h
but in bullseye
  /usr/include/xfce4/libxfce4panel-2.0/libxfce4panel/xfce-panel-macros.h
no longer includes gdkx.h
And nvidia.c itself includes NVCtrlLib.h and X11/Xlib.h in the wrong^Wunlucky
order.


Andreas

Bug#979312: Processed: Reassigning to proper package

[handsome_feng]

reassign 979312 vokoscreen-ng
thanks 




Sorry, I didn't notice the maintainer's reply. It's really from vokoscreen-ng, 
so reassign back.

Bug#979104: installation-reports: Intel Wireless 8265 / 8275 has no firmware in nonfree iso

[Holger Wansing]

Hi,

Ben Hutchings  wrote:
> On Sun, 2021-01-03 at 14:30 +0100, Holger Wansing wrote:
> > Hi,
> > 
> > liangyue  wrote:
> > >   My wifi can not connect. The installer told me that I missing
> > > firmware files are
> > > regulatory.db, and I solved it by add package named wireless-regdb.
> > > I think the package
> > > wireless-regdb should be add to nonfree iso.
> > >   By the way, my amd gpu rx590 also need firmware, because I can't
> > > enter desktop 
> > > environment until I install the package firmware-amd-graphics. I
> > > think the two firmware
> > > should included in nonfree iso for everyone like my haardware.
> > 
> > Two different issues here:
> > 
> > 1. regulatory.db from wireless-regdb package is not included in non-free 
> > firmware-including d-i images.
> [...]
> 
> regulatory.db is free, and is packaged in wireless-regdb-udeb which
> should be included in most installer builds since 20201202.  So I don't
> know why it's not being found.

Hmm, you stated that wireless-regdb-udeb should be included in most installer
builds now.
That goes down to commit
https://salsa.debian.org/installer-team/debian-installer/-/commit/2b615f42bd7745ac9add0a36b1630812f95840fb
which adds wireless-regdb-udeb to netboot images.

Yes, that works fine, using a netboot image, I am NOT asked to provide
firmware for regulatory.db file, because it's already included in the d-i
image.

However, that's only true for netboot images!

My wireless card (on an IBM Thinkpad T60) is also usable with DVD/CD netinst 
images 
(so related kernel modules seem to be included in those images; I have 
explicitly
tested that with said images on that T60), so probably wireless-regdb-udeb 
should just 
be added to all Linux d-i images?


Holger



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

Bug#979614: seamly2d: virtually dead fork of valentina

[Jonas Smedegaard]

Package: seamly2d
Version: 0.6.0.2+20201207+ds-1
Severity: grave
Justification: renders package unusable

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Seamly2D is a fork of Valentina.  Valentina is already in Debian.

Original author Roman Telezhynskyi a.k.a. dismine developed the code
until git commit a7cadff on August 27, 2017.

Since then, he continued develop under original project name Valentina,
whereas Seamly2D virtually stalled with no substantial code changes ,
only superficial changes to build infrastructure, locales, and icons.

Check for yourself:

  git clone https://github.com/FashionFreedom/Seamly2D
  cd Seamly2D
  git diff --stat -p --ignore-all-space a7cadff..

...compared to Valentina:

  git clone https://gitlab.com/smart-pattern/valentina.git
  cd valentina
  git diff --stat -p --ignore-all-space 3ea3371..

Or skim through those histories e.g. with "tig".


I recommend that Debian does not carry Seamly3D, and encourage helping
out with maintaining Valentina instead.

If you disagree, then I just wish you the best of luck with Seamly3D.
I admit the severity is bloated - feel free to lower as you see fit.


Kind regards,

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl/5GPIACgkQLHwxRsGg
ASEzJA//QzXmeEZOhHcQ/qUJVtXoepXcWCmSnSxHI+4e0vR+ruDEaQhzM6teA4Bj
WakhTeIvg3mUE3QYpzI1JhD+YbDao3ifZ17zJ7TmLzEdA30NBzk5DXkjR0Eza2Lp
o8PQEqBNPoGd7yU1LdfdlzbSezaR/KHZswPWSRsmPqmTxMWUAknQykxj3Tmd4bb/
jyf+Bels7bBbnkRf1nluKnIbI+KpjL3/2lIq2WOskS8aoMYWhFjCRj22BxT6KxQI
33dgEn+rJGsqfHPKDfvdRZK/LbvS7gb0uoLc6aUbsA7dqNH37DEcXS2tfmm54l2F
jkIQJZR50SToVDTMmal9XNim1aDj870OogjdZHQKVecCmEaTrQgdAJg+B8vTt+ks
5K8MtvGHThaz5nymos6f27qUilvxw19w0DJnUobtCRocwL//dkSmxfW/l3J0qQQo
3J3p85Y16xycP90Z7v442wEYCNJ4NuPfA/qML9o1tqH//KJEk5rYYZAVKbMLUBbC
JhRpCA2fGe6wc3NaAaza4V/26lYrgUDBAAJiYqDXRFQ6lKst3+4wrpj4bywI058k
ZTAhyleLmeyvYDNwrghEbqJDevOouBh4n10J84itLGF/YDH7gsFpMxA/hK5X8FS5
GyVoh1M7N0/vXBqrT+8iJnrFIyIn58CorZl/HHcRhp+Hbblxc6o=
=OVq+
-END PGP SIGNATURE-

Bug#979613: virt-manager: i386 UEFI disk/CDROM image cannot be started on x86_64 host

[Ryutaroh Matsumoto]

Package: virt-manager
Version: 1:3.2.0-3
Severity: normal
Tags: upstream
Control: forwarded -1 https://github.com/virt-manager/virt-manager/issues/209

Dear Maintainer,

I strongly believe that this is an upstream issue, and
have reported this as
https://github.com/virt-manager/virt-manager/issues/209
For detail, please have a look at the upstream report.

Best regards, Ryutaroh Matsumoto

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

Kernel: Linux 5.9.0-5-amd64 (SMP w/12 CPU threads)
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 virt-manager depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-1
ii  gir1.2-gtk-3.0   3.24.24-1
ii  gir1.2-gtk-vnc-2.0   1.0.0-1
ii  gir1.2-gtksource-4   4.8.0-1
ii  gir1.2-libosinfo-1.0 1.7.1-1
ii  gir1.2-libvirt-glib-1.0  3.0.0-1
ii  gir1.2-vte-2.91  0.62.1-1
ii  python3  3.9.1-1
ii  python3-dbus 1.2.16-4+b1
ii  python3-gi   3.38.0-1+b2
ii  python3-gi-cairo 3.38.0-1+b2
ii  python3-libvirt  6.1.0-1+b3
ii  virtinst 1:3.2.0-3

Versions of packages virt-manager recommends:
ii  gir1.2-appindicator3-0.10.4.92-8
ii  gir1.2-spiceclientglib-2.0  0.39-1
ii  gir1.2-spiceclientgtk-3.0   0.39-1
ii  libvirt-daemon-system   6.9.0-1+b2

Versions of packages virt-manager suggests:
ii  gir1.2-secret-1  0.20.4-1
ii  gnome-keyring3.36.0-1
pn  python3-guestfs  
pn  ssh-askpass  
ii  virt-viewer  7.0-2

Versions of packages virt-manager is related to:
ii  libvirt-clients  6.9.0-1+b2
ii  libvirt-daemon   6.9.0-1+b2
ii  libvirt0 6.9.0-1+b2
ii  osinfo-db0.20201218-1

-- no debconf information

Bug#979611: Add comment in /etc/resolv.conf saying that pppd added these lines

[積丹尼 Dan Jacobson]

Package: ppp
Version: 2.4.9-1+1
Severity: wishlist
File: /etc/ppp/ip-up.d/usepeerdns

Regarding this part of /etc/ppp/ip-up.d/usepeerdns,

# merge the new nameservers with the other options from the old 
configuration
{
  cat /etc/ppp/resolv.conf
  grep --invert-match '^nameserver[[:space:]]' "$REALRESOLVCONF" || true
} > "$REALRESOLVCONF.tmp"

It would be a good idea to put into /etc/resolv.conf:

   The following section was added by /etc/ppp/ip-up.d/usepeerdns:

That would often eliminate the mysteries of who wrote what there, and is
indeed the practice of many other programs these days. It could save
months of wild goose chases.

Bug#962708:

[KeyofBlueS]

Dear mainteiners,

I see USB_DUMMY_HCD is finally enabled in kernel 5.10. Now we just need
USB_MASS_STORAGE module.

Thanks and best regards.

Bug#978954: pepperflashplugin-nonfree: should not be part of next stable Debian release

[Gunnar Hjalmarsson]

Another reminder about why it's important to handle this also in the 
supported releases:


https://askubuntu.com/q/1306202

--
Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj

Bug#922677: Please update this package for Bullseye

[Diederik de Haas]

On zaterdag 12 december 2020 15:17:26 CET you wrote:
> Release 6.10 (https://github.com/nhorman/rng-tools/releases/tag/v6.10) would
> already be a great improvement, but if you'd use a recent snapshot
> (ceb30b2ea or later), that would also fix bug #847962.
> I already tried to entice upstream maintainer to release a new version in
> https://github.com/nhorman/rng-tools/issues/105#issuecomment-732994509 but
> coming from the maintainer of Debian's package of it may likely carries more
> weight.


Version 6.11 has just been released :)
The tag is V6.11 (capital 'V'), but another tag with lowercase 'v' should be 
added this weekend or Monday (https://github.com/nhorman/rng-tools/issues/114)

Having 6.11 in Bullseye would be great.

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

Bug#978973:

[Sudip Mukherjee]

Control: tags -1 pending
--

Uploaded to NEW for experimental. Will upload to unstable after it has
passed NEW queue and upstream has tagged the new 1.0.0 version.


-- 
Regards
Sudip

Bug#979570: Updating dpkg-buildflags to enable reproducible=+fixfilepath by default

[Lisandro Damián Nicanor Pérez Meyer]

On Fri, 8 Jan 2021 at 21:15, Lisandro Damián Nicanor Pérez Meyer
 wrote:
>
> Hi! Explicitely CCing my bug, since it seems it missed my previous reply.
>
> On Fri, 8 Jan 2021 at 20:49, Guillem Jover  wrote:
> >
> > On Fri, 2021-01-08 at 19:23:13 -0300, Lisandro Damián Nicanor Pérez Meyer 
> > wrote:
> > > [snip]
> > > > We did a full archive rebuild testing this change, and I provided
> > > > patches to all known affected packages several months ago. It is a
> > > > one-line change in debian/rules in most cases:
> > > >
> > > >   
> > > > https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=reproducible-builds%40lists.alioth.debian.org=fixfilepath
> > > >
> > > > It seems there are less than 10 packages left that have not applied the
> > > > patch.
> > > >
> > > > Longer-term, it would be nice to be able to fix QFINDTESTDATA to be
> > > > compatible, sure.
> > >
> > > >From a couple of "fixes":
> > >
> > > -export DEB_BUILD_MAINT_OPTIONS = hardening=+all
> > > +# Disable fixfilepath feature, as it triggers build failures when
> > > +# enabled.
> > > +export DEB_BUILD_MAINT_OPTIONS = hardening=+all reproducible=-fixfilepath
> > >
> > > That's not a fix but hiding the dirt under the carpet. You are not
> > > fixing the root issue nor the reproducibility one.
> >
> > I'm not sure I understand this objection. Reverting the patch from
> > dpkg would do the same but at a global scale, which would make many
> > packages that would benefit from the new default, not reproducible,
> > and would still "hide the dirt under the carpet" for the very few
> > that would otherwise need the option disabled.

In fact most of those packages would not be unreproducible if the
environment would be the same as the original build. That includes the
build path.

I do understand that it is *desirable* to be able to reproducibly
build a package no matter the build path, but that's just desirable.

The real fix here is to do the right thing, ie, provide the very same
environment as the original build, including the build path.

So again, mangling __FILE__ should not be a default.


-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

Bug#979570: Updating dpkg-buildflags to enable reproducible=+fixfilepath by default

[Lisandro Damián Nicanor Pérez Meyer]

Hi! Explicitely CCing my bug, since it seems it missed my previous reply.

On Fri, 8 Jan 2021 at 20:49, Guillem Jover  wrote:
>
> On Fri, 2021-01-08 at 19:23:13 -0300, Lisandro Damián Nicanor Pérez Meyer 
> wrote:
> > [snip]
> > > We did a full archive rebuild testing this change, and I provided
> > > patches to all known affected packages several months ago. It is a
> > > one-line change in debian/rules in most cases:
> > >
> > >   
> > > https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=reproducible-builds%40lists.alioth.debian.org=fixfilepath
> > >
> > > It seems there are less than 10 packages left that have not applied the
> > > patch.
> > >
> > > Longer-term, it would be nice to be able to fix QFINDTESTDATA to be
> > > compatible, sure.
> >
> > >From a couple of "fixes":
> >
> > -export DEB_BUILD_MAINT_OPTIONS = hardening=+all
> > +# Disable fixfilepath feature, as it triggers build failures when
> > +# enabled.
> > +export DEB_BUILD_MAINT_OPTIONS = hardening=+all reproducible=-fixfilepath
> >
> > That's not a fix but hiding the dirt under the carpet. You are not
> > fixing the root issue nor the reproducibility one.
>
> I'm not sure I understand this objection. Reverting the patch from
> dpkg would do the same but at a global scale, which would make many
> packages that would benefit from the new default, not reproducible,
> and would still "hide the dirt under the carpet" for the very few
> that would otherwise need the option disabled.

__FILE__ has defined behaviour: the path the preprocessor finds. The
only place where __FILE__ is mangled, to the best of my knowledge, is
Debian. So expecting that any developer out there makes code that runs
with this Debian specific variation is unreasonable. In other words:
breaking perfectly valid code *by default*, even in the name of
reproducibility, is not right.

>
> Disabling this option in these few places gives you room to possibly
> look for a fix, or not, w/o the pressure of the freeze, while not
> affecting the other packages.

But still breaking perfectly valid code.


> As stated in the thread in d-d, I still fail to see the weight of the
> objections, TBH. And given this I'm planning on closing the bug in
> dpkg.

In that case we at least should agree that we disagree, so I would ask
the tech-ctte to review this case.



-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

Bug#979592: RFS: openrct2/0.3.2+ds-1 [ITP] -- Open-source re-implementation of RollerCoaster Tycoon 2

[Mathias Gibbens]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name: openrct2
   Version : 0.3.2+ds-1
   Upstream Author : https://github.com/OpenRCT2/OpenRCT2
 * URL : https://openrct2.io/
 * License : BSD-2-Clause and Zlib, Expat, 
__NO_COPYRIGHT_NOR_LICENSE__, permissive, GPL-3, CC0-1.0
 * Vcs : https://salsa.debian.org/gibmat/openrct2
   Section : games

It builds those binary packages:

  openrct2-data - Required game data for openrct2
  openrct2 - Open-source re-implementation of RollerCoaster Tycoon 2

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/o/openrct2/openrct2_0.3.2+ds-1.dsc

Changes for the initial release:

 openrct2 (0.3.2+ds-1) unstable; urgency=medium
 .
   * Initial release. (Closes: #808945)

I am waiting on upstream to formally declare a license for some of the game 
assets (thus the
"__NO_COPYRIGHT_NOR_LICENSE__" currently in the License field), but other than 
that I believe
this package is ready for review.

Thanks,
Mathias


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

Bug#959469: buster-pu: package openssl/1.1.1g-1

[Kurt Roeckx]

On Fri, Jan 08, 2021 at 11:39:13PM +0100, Sebastian Andrzej Siewior wrote:
> On 2020-11-24 20:18:15 [+], Adam D. Barratt wrote:
> 
> > At some point, could we please have a combined / single diff between
> > the current 1.1.1d-0+deb10u3 and the proposed 1.1.1h-0+deb10u1 (I
> > assume)?
> 
> Please find attached the diff between 1.1.1d-0+deb10u4 and the proposed
> 1.1.1i-0+deb10u1.
> 
> The i release in unstable managed to migrate to testing. It was blocked
> due to ci by m2crypto and swi-prolog. The swi-prolog issue got fixed in
> unstable (the testuite was updated) and is not an issue in stable (the
> package builds, the testsuite gets ignored).
> The m2crypto issue is a different story and is still open in BTS
> (#977655). I *think* someone added an override or the ci-system was kind
> to Kurt/me and looked the other way :)
> The m2crypto package in stable and bpo will FTBFS with the updated
> openssl package.
> 
> I'm not aware of other issues.

I think there are at least 2 upstream issues since the 1.1.1i
release we want to fix first. As far as I know, they haven't been
fixed upstream yet.


Kurt

Bug#979610: v4l-utils: vendors ancient version of libbpf

[Luca Boccassi]

Source: v4l-utils
Version: 1.16.3-3
Severity: important
Tags: patch bullseye

Dear Maintainer(s),

v4l-utils embeds sources from a very old version of libbpf, from
before it split from the kernel. This version is mostly compatible
with the public standalone release, minus a small change.
It would be great to unvendorize it and use libbpf from the archive,
now that it's available.

A patch to this effect, build-tested only as I unfortunately do not
possess any IR-capable hardware that runs Linux, as been pushed as a
merge request on Salsa:

https://salsa.debian.org/debian/libv4l/-/merge_requests/2

I will also forward the patch upstream.

Kind regards,
Luca Boccassi

Bug#979602: grub2: /boot/grub/i386-pc/ is left empty

[Colin Watson]

On Fri, Jan 08, 2021 at 11:10:31PM +0100, Val Lorentz wrote:
> I just tried to install a Bullseye system with these commands:
> 
>   debootstrap bullseye .
>   mount --bind /dev dev
>   mount --bind /proc proc
>   mount --bind /sys sys
>   chroot .
> 
> Then, inside the chroot:
> 
>   apt install grub2

Normally you should explicitly select a platform package (grub-pc,
grub-efi-amd64, etc.) - grub2 is a dummy transitional package.  But I'll
assume you wrote grub-pc here instead.

>   grub-install /dev/sdd

If you add --debug to this, what's the output?  There'll be quite a lot
of it, so you might want to write something like this to capture it:

  grub-install --debug /dev/sdd >grub-install.out 2>&1

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#979135: No dont do this

[karthek]

Package: chromium
Version: 87.0.4280.88-0.4
Followup-For: Bug #979135
X-Debbugs-Cc: frustra...@karthek.com

Hey,

Making desktopgl default seems like a good idea at first(even for me).
But in practical I cant even run chromium without ANGLE for even a few
minutes, it just segfaults with a bunch of errors and no corefile.
I dont no if im the only one facing issues with desktopgl but its a
matter of adding "--use-gl=desktop" to /etc/chromium.d/default-flags.

But the source shouldnt be patched to do this.For now just leave ANGLE
as default gl even though it had issues with optimus systems like mine.

Cuz it just works.

Bug#940406: RFA: golang-github-oschwald-maxminddb-golang

[Cyril Brulebois]

Hi Alexandre,

Alexandre Viau  (2019-09-15):
> I'd like to find new maintainers for some of my packages because I have
> had less time for Debian. I'd like to focus the small amount of time
> that I have for Debian on other things.
> 
> For now, I intend to do my best to keep maintaining this package.
> However, I will probably retitle this bug with the 'O:' prefix at some
> point, indicating that I have orphaned it.
> 
> Feel free to upload a new version of the package and remove me from
> the uploaders in debian/control.
> 
> Feel free to contact me with any questions. Also note that I always
> willing to sponsor uploads!

I've refreshed this package as part of my crowdsec packaging effort:
  https://lists.debian.org/debian-go/2020/12/msg00060.html

but for some reasons, I managed to miss the RFA until checking tracker
to see how things were looking regarding migration to testing/QA, etc.

It seems to be a package simple enough, and with a very limited set of
reverse dependencies, that I think I should be able to manage further
updates. If that looks good enough for you, I can indeed drop you from
Uploaders and close this bug report.


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/


signature.asc
Description: PGP signature

Bug#940405: RFA: golang-github-oschwald-geoip2-golang

[Alexandre Viau]

On Fri, 8 Jan 2021 at 18:02, Cyril Brulebois  wrote:
> It seems to be a package simple enough, and with a very limited set of
> reverse dependencies, that I think I should be able to manage further
> updates. If that looks good enough for you, I can indeed drop you from
> Uploaders and close this bug report.

Looks good to me! Thanks!

Cheers,

Bug#940405: RFA: golang-github-oschwald-geoip2-golang

[Cyril Brulebois]

Hi Alexandre,

Alexandre Viau  (2019-09-15):
> I'd like to find new maintainers for some of my packages because I have
> had less time for Debian. I'd like to focus the small amount of time
> that I have for Debian on other things.
> 
> For now, I intend to do my best to keep maintaining this package.
> However, I will probably retitle this bug with the 'O:' prefix at some
> point, indicating that I have orphaned it.
> 
> Feel free to upload a new version of the package and remove me from
> the uploaders in debian/control.
> 
> Feel free to contact me with any questions. Also note that I always
> willing to sponsor uploads!

I've refreshed this package as part of my crowdsec packaging effort:
  https://lists.debian.org/debian-go/2020/12/msg00060.html

but for some reasons, I managed to miss the RFA until checking tracker
to see how things were looking regarding migration to testing/QA, etc.

It seems to be a package simple enough, and with a very limited set of
reverse dependencies, that I think I should be able to manage further
updates. If that looks good enough for you, I can indeed drop you from
Uploaders and close this bug report.


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/


signature.asc
Description: PGP signature

Bug#956041: libmaxminddb: FTBFS (BD-Uninstallable): Build-Depends-Arch on pandoc

[Faidon Liambotis]

On Wed, Aug 19, 2020 at 05:00:24PM +0200, Thorsten Glaser wrote:
> > I must admit that I find the trade-off proposed by Adrian and Thorsten
> > quite reasonable. I've also looked for more options, but none came to my
> > mind.
> 
> I’m actually in favour of one of the other solutions,
> not the package split.

I filed a few more ronn-ng bugs (#69, #70, #72); upstream was fairly
responsive and they're currently being worked on. I had mentioned #57
previously (that was fixed since), as well as #33 that upstream seems
willing to address. These look like they may get fixed in 0.11.

However, I went down a different path in the meantime, and worked on
packaging lowdown instead:
  https://kristaps.bsd.lv/lowdown/ (ITP #896816)
I had to work with upstream to add some features to make this more
viable for both inclusion into Debian, and for this particular use case.
With the latest changes that landed in the upstream repository today,
generating libmaxminddb's manpages with lowdown should be possible. I
also pushed the lowdown package to NEW, so hopefully by the time that
reaches the archive, I'll be able to push an even newer upstream that
can be used by libmaxminddb.

You may be delighted to hear that lowdown is a small codebase, written
in C, with only libbsd as an (optional) dependency. Hopefully this will
make things a bit more portable for libmaxminddb and possibly other use
cases you may have.

Finally, I also made a PR against upstream libmaxminddb, that allows one
to use translators different than pandoc, starting with lowdown:
  https://github.com/maxmind/libmaxminddb/pull/248

All in all, this is going to take a little while longer, but is on track
to get fixed by having a smaller build-dependency tree. Hopefully this
will alleviate any issues you may have had in the past with
porting/bootstrapping.

Regards,
Faidon

Bug#966877: termtris: FTBFS: ld: src/game.o:/<>/src/game.h:21: multiple definition of `quit'; src/ansi.o:/<>/src/game.h:21: first defined here

[Logan Rosen]

Package: termtris
Version: 1.3-1
Followup-For: Bug #966877
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu hirsute ubuntu-patch
X-Debbugs-Cc: lo...@ubuntu.com
Control: tags -1 patch

Hi,

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

  * d/p/gcc-10.patch: Fix compilation with GCC 10.

Thanks for considering the patch.

Logan
diff -Nru termtris-1.3/debian/patches/gcc-10.patch 
termtris-1.3/debian/patches/gcc-10.patch
--- termtris-1.3/debian/patches/gcc-10.patch1969-12-31 19:00:00.0 
-0500
+++ termtris-1.3/debian/patches/gcc-10.patch2021-01-08 17:44:33.0 
-0500
@@ -0,0 +1,46 @@
+--- a/src/game.h
 b/src/game.h
+@@ -18,12 +18,12 @@
+ #ifndef GAME_H_
+ #define GAME_H_
+ 
+-int quit;
+-long tick_interval;
+-int use_bell;
+-int monochrome;
++extern int quit;
++extern long tick_interval;
++extern int use_bell;
++extern int monochrome;
+ 
+-int term_width, term_height;
++extern int term_width, term_height;
+ 
+ int init_game(void);
+ void cleanup_game(void);
+--- a/src/game.c
 b/src/game.c
+@@ -26,6 +26,9 @@
+ #include "ansi.h"
+ #include "scoredb.h"
+ 
++int quit;
++long tick_interval;
++
+ enum {
+   G_DIAMOND   = 0x04,
+   G_CHECKER   = 0xb1,
+--- a/src/main.c
 b/src/main.c
+@@ -35,6 +35,11 @@
+ #define USE_JOYSTICK
+ #endif
+ 
++int use_bell;
++int monochrome;
++
++int term_width, term_height;
++
+ int init(void);
+ void cleanup(void);
+ int parse_args(int argc, char **argv);
diff -Nru termtris-1.3/debian/patches/series termtris-1.3/debian/patches/series
--- termtris-1.3/debian/patches/series  2019-06-06 03:01:11.0 -0400
+++ termtris-1.3/debian/patches/series  2021-01-08 17:44:04.0 -0500
@@ -1 +1,2 @@
 0001_install_to_usr_game.patch
+gcc-10.patch

Bug#896816: ITP: lowdown -- Simple markdown translator

[Faidon Liambotis]

owner 896816 !
thanks

On Tue, Apr 24, 2018 at 10:24:06AM -0400, Jon Bernard wrote:
> * Package name: lowdown

It seems this ITP has been pending for 2½ years, and looks abandoned.

I was interested in this package, so I worked with upstream to resolve a
bunch of integration issues with both lowdown and oconfigure (its build
system), plus a PR to libbsd, and prepared a package suitable for
inclusion into Debian.

I pushed the repository to Salsa, under the Debian project:
  https://salsa.debian.org/debian/lowdown

I'll upload to unstable momentarily; Jon or anyone else, if you want to
comaintain you're more than welcome!

Regards,
Faidon

Bug#976651: protobuf-compiler-grpc: Multi-arch protobuf-compiler-grpc

[Helmut Grohne]

Control: affects -1 + src:bear src:sysdig

Hi,

On Sun, Dec 06, 2020 at 03:14:56PM +0100, Andreas Henriksson wrote:
> Package: protobuf-compiler-grpc
> Version: 1.16.1-1
> Severity: normal
> 
> Dear Maintainer,
> 
> I'm having a problem with grpc_cpp_plugin in my cross-build environment.
> 
> ```
> $ apt-get build-dep -aarmhf . -y
> Note, using directory '.' to get the build dependencies
> Reading package lists...
> Building dependency tree...
> Reading state information...
> The following packages were automatically installed and are no longer 
> required:
>   libc-ares2 libgoogle-perftools4 libtcmalloc-minimal4 libunwind8
> Use 'apt autoremove' to remove them.
> The following packages will be REMOVED:
>   protobuf-compiler-grpc
> The following NEW packages will be installed:
>   [...] protobuf-compiler-grpc:armhf [...]
> ```

This is a practical problem affecting packages inside Debian. Both bear
and sysdig fail to cross build from source, because they
protobuf-compiler-grpc is installed for the host architecture and cannot
be run.

> If I'm not mistaken the protobuf-compiler-grpc package should be marked
> `Multi-Arch: foreign` just like for example protobuf-compiler package is.

Yes, this is the most obvious cure of the problem. However, it is not
entirely clear that doing so is correct. The foreign marking is less of
a method to make things cross buildable. It is a guarantuee on the
interface provided by a package. Unless that guarantuee is warranted,
the marking is quite simply wrong and shouldn't be issued. If the
marking is correct, it does solve the cross building issues.

In order to evaluate correctness, one has to figure out what the
"interface" of the protobuf-compiler-grpc package is. It provides a
number of plugins for protoc's plugin mechanism. A bit of testing and
googling later, I found that those plugins use a binary protocol on
stdin and stdout to communicate with protoc. Binary protocols may or may
not be architecture dependent. It seems like the one being used here is
based on protocol buffers, which hints that is indeed architecture
independent. Furthermore, the output of the plugins is program source,
which tends to be architecture independent.

To validate this, I've attempted combining protobuf-compiler:amd64 with
protobuf-compiler-grpc:armhf. Using qemu-user-static, I plugged the
grpc_cpp_plugin into protoc. It just worked. This is a minor
confirmation of the hypothesis.

>From my pov, this is sufficient to issue the Multi-Arch: foreign
marking as it requires that you can mix and match protobuf-compiler and
protobuf-compiler-grpc for various architectures (so long as you can
actually run the code) and expect them to work together.

Helmut

Bug#979606: mariadb-10.5: reduce Build-Depends

[Helmut Grohne]

Source: mariadb-10.5
Version: 1:10.5.8-3
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

Hi,

mariadb-10.5 is involved in a number of dependency cycles relevant to
architecture bootstrap. Instead of looking into particular cycles, I
looked into easily droppable dependencies to reduce the size of the
problem. Here we go:

 * chrpath seems entirely unused.
 * cracklib-runtime is referenced in a number of tests, but not
   elsewhere. I think it can be annotated .
 * apparmor is disabled. I think that means dh-apparmor can be dropped.
 * gdb is referenced from tests only. I also propose  here.
 * libarchive-dev is only used in ds_archive.cc, which is not built.

I've compared the resulting .debs of a build with these dependencies and
a nocheck build that turned these into Build-Conflicts. Given that
mariadb-10.5 is normally reproducible, these matched exactly. As such it
seems relatively safe to just apply my patch.

Helmut
--- mariadb-10.5-10.5.8/debian/changelog
+++ mariadb-10.5-10.5.8/debian/changelog
@@ -1,3 +1,15 @@
+mariadb-10.5 (1:10.5.8-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Reduce Build-Depends: (Closes: #-1)
++ chrpath is not used at all.
++ cracklib-runtime is only used for testing.
++ apparmor is disabled. dh-apparmor is unused.
++ gdb is only used for testing.
++ libarchive-dev is only used in ds_archive.cc, which is not built.
+
+ -- Helmut Grohne   Fri, 08 Jan 2021 16:29:19 +0100
+
 mariadb-10.5 (1:10.5.8-3) unstable; urgency=medium
 
   * Re-introduce deprecated transitional libmariadbclient-dev package
--- mariadb-10.5-10.5.8/debian/control
+++ mariadb-10.5-10.5.8/debian/control
@@ -4,15 +4,12 @@
 Maintainer: Debian MySQL Maintainers 
 Uploaders: Otto Kekäläinen 
 Build-Depends: bison,
-   chrpath,
cmake,
-   cracklib-runtime,
+   cracklib-runtime ,
debhelper (>= 10),
-   dh-apparmor,
dh-exec,
-   gdb,
+   gdb ,
libaio-dev [linux-any],
-   libarchive-dev,
libboost-dev,
libcrack2-dev (>= 2.9.0),
libcurl4-openssl-dev | libcurl4-dev,

Bug#979607: texlive-bin: reduce Build-Depends

[Helmut Grohne]

Source: texlive-bin
Version: 2020.20200327.54578-5
User: helm...@debian.org
Usertags: rebootstrap

Hi Norbert et al,

as discussed on irc, I'm working on reducing Build-Depends on packages
relevant to architecture bootstrap. texlive-bin is one of the more
difficult packages and we agreed that I'm not providing a patch here.
What I can tell is:

If you perform a full amd64 build of texlive-bin and then turn the
following Build-Depends into Build-Conflicts, then a
DEB_BUILD_OPTIONS=nocheck build produces bit-identical .deb files (as
texlive-bin is otherwise reproducible).

 * libgd-dev
 * libgs-dev
 * libncurses5-dev
 * libpotrace-dev
 * libwoff-dev
 * libxxhash-dev
 * sharutils
 * texinfo
 * time

The reason for being apparently unused can vary. I've seen the following
reasons:
 * A dependency is really unneeded. It was needed earlier, but is no
   longer needed and someone forgot to drop it. For instance
   libpotrace-dev has a use in a component that is explicitly being
   opted out of building. Maybe it can be dropped entirely.
 * A dependency is only used for unit testing. If that's what you think,
   annotate it "". Any dependency thus tagged becomes
   irrelevant to architecture bootstrap. However, please ensure that the
   final result is buildable with DEB_BUILD_OPTIONS=nocheck and
   DEB_BUILD_PROFILES=nocheck (use the --profiles option of sbuild or
   pbuilder).
 * Sometimes, a dependency has fallback code. For instance if you depend
   on xxd to locate it and fall back to using /usr/bin/xxd, then
   building without this dependency is reproducible, but it should be
   kept. Similarly, absence of flex or bison can result into source
   files not being rebuilt. When the previously generated output is
   close enough, the package will appear to remain reproducible. Please
   keep such dependencies. Even better, please delete the intermediate
   results (if possible) before build to ensure that they are rebuilt and
   to ensure that future tests of droppable dependencies will identify
   the relevant depenencies as necessary.

When in doubt, let us discuss. Thank you for looking into this.

Helmut

Bug#979603: dbskkd-cdb FTCBFS: uses the build architecture compiler

[Helmut Grohne]

Source: dbskkd-cdb
Version: 1:3.00-3
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

dbskkd-cdb fails to cross build from source, because it uses the build
architecture compiler. It is debian/rules that hard codes gcc. The usual
solution of letting dh_auto_build pass cross tools does not work here as
debian/rules stuffs CFLAGS into the CC variable. One usually separates
them out to CFLAGS. Please consider applying the attached patch to
implement that and make dbskkd-cdb cross buildable. Alternatively,
please pass $(CC) as CC after including /usr/share/dpkg/buildtools.mk.
That also works.

Helmut
diff --minimal -Nru dbskkd-cdb-3.00/debian/changelog 
dbskkd-cdb-3.00/debian/changelog
--- dbskkd-cdb-3.00/debian/changelog2021-01-02 09:37:03.0 +0100
+++ dbskkd-cdb-3.00/debian/changelog2021-01-08 17:21:38.0 +0100
@@ -1,3 +1,12 @@
+dbskkd-cdb (1:3.00-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ cross.patch: Don't stuff CFLAGS into CC.
++ Let dh_auto_build pass cross tools to make.
+
+ -- Helmut Grohne   Fri, 08 Jan 2021 17:21:38 +0100
+
 dbskkd-cdb (1:3.00-3) unstable; urgency=medium
 
   [ Jelmer Vernooij ]
diff --minimal -Nru dbskkd-cdb-3.00/debian/patches/cross.patch 
dbskkd-cdb-3.00/debian/patches/cross.patch
--- dbskkd-cdb-3.00/debian/patches/cross.patch  1970-01-01 01:00:00.0 
+0100
+++ dbskkd-cdb-3.00/debian/patches/cross.patch  2021-01-08 17:20:58.0 
+0100
@@ -0,0 +1,32 @@
+--- dbskkd-cdb-3.00.orig/Makefile
 dbskkd-cdb-3.00/Makefile
+@@ -1,12 +1,13 @@
+ # dbskkd-cdb Makefile
+ 
+-CC = cc -Wall -O2 -g -I/usr/local/include
++CC = cc
++CFLAGS = -Wall -O2 -g -I/usr/local/include
+ COMPAT =
+ CDBLIB = /usr/local/lib/libcdb.a
+ INSTALLDIR = /usr/local/libexec
+ 
+ .c.o:
+-  $(CC) $(COMPAT) $(PRIVATE) -c $*.c
++  $(CC) $(CFLAGS) $(COMPAT) $(PRIVATE) -c $*.c
+ 
+ all:  dbskkd-cdb 
+ 
+@@ -14,11 +15,11 @@
+   /bin/rm -f dbskkd-cdb *.o
+ 
+ dbskkd-cdb: dbskkd-cdb.o 
+-  $(CC) $(COMPAT) $(PRIVATE) -o dbskkd-cdb \
++  $(CC) $(CFLAGS) $(COMPAT) $(PRIVATE) -o dbskkd-cdb \
+   dbskkd-cdb.o ${CDBLIB}
+ 
+ dbskkd-cdb.o: dbskkd-cdb.c 
+-  $(CC) $(COMPAT) $(PRIVATE) -c dbskkd-cdb.c
++  $(CC) $(CFLAGS) $(COMPAT) $(PRIVATE) -c dbskkd-cdb.c
+ 
+ error.o: error.c error.h
+ 
diff --minimal -Nru dbskkd-cdb-3.00/debian/patches/series 
dbskkd-cdb-3.00/debian/patches/series
--- dbskkd-cdb-3.00/debian/patches/series   1970-01-01 01:00:00.0 
+0100
+++ dbskkd-cdb-3.00/debian/patches/series   2021-01-08 17:20:27.0 
+0100
@@ -0,0 +1 @@
+cross.patch
diff --minimal -Nru dbskkd-cdb-3.00/debian/rules dbskkd-cdb-3.00/debian/rules
--- dbskkd-cdb-3.00/debian/rules2018-11-26 17:02:05.0 +0100
+++ dbskkd-cdb-3.00/debian/rules2021-01-08 17:21:36.0 +0100
@@ -15,7 +15,7 @@
 build-arch: build-arch-stamp
 build-arch-stamp:
dh_testdir
-   $(MAKE) CC='gcc $(CFLAGS) $(CPPFLAGS)' \
+   dh_auto_build -- CFLAGS='$(CFLAGS) $(CPPFLAGS)' \
 COMPAT='-DJISYO_FILE=\"/usr/share/skk/SKK-JISYO.cdb\"' \
CDBLIB='$(LDFLAGS) -lcdb'
touch $@

Bug#979605: gpac: drop unused Build-Depends

[Helmut Grohne]

Source: gpac
Version: 1.0.1+dfsg1-3
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

gpac is involved in a number of dependency cycles relevant to
architecture bootstrap. Rather than looking into this difficult problem,
I looked into easily droppable dependencies to reduce the size of the
problem. I found some for gpac:

 * I couldn't find any use of freeglut3-dev.
 * libfreenect-dev was formerly used, but it is no longer used.
 * libusb-1.0-0-dev was required for libfreenect-dev.
 * libxml2-dev is mostly removed except for one directory, which is not
   built.

I've compared the resulting .debs for a normal build and a nocheck build
with all of these dependencies turned into Build-Conflicts. The
resulting binaries were bit-identical as gpac is normally reproducible.
That suggests that applying my patch is relatively safe.

Helmut
--- gpac-1.0.1+dfsg1/debian/changelog
+++ gpac-1.0.1+dfsg1/debian/changelog
@@ -1,3 +1,15 @@
+gpac (1.0.1+dfsg1-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop unused Build-Depends: (Closes: #-1)
++ freeglut3-dev is not used anywhere.
++ libfreenect-dev was formerly used but is no longer.
++ libusb-1.0-0-dev was required for libfreenect-dev.
++ libxml2-dev is mostly removed except for one directory, which is not
+  built.
+
+ -- Helmut Grohne   Fri, 08 Jan 2021 16:58:45 +0100
+
 gpac (1.0.1+dfsg1-3) unstable; urgency=medium
 
   * Clean share/gpac.desktop (Closes: #975779)
--- gpac-1.0.1+dfsg1/debian/control
+++ gpac-1.0.1+dfsg1/debian/control
@@ -7,7 +7,6 @@
  Alessio Treglia 
 Build-Depends:
  debhelper-compat (= 13),
- freeglut3-dev,
  liba52-0.7.4-dev,
  libasound2-dev,
  libavcodec-dev (>= 6:10~),
@@ -15,7 +14,6 @@
  libavformat-dev (>= 6:10~),
  libavutil-dev (>= 6:10~),
  libfaad-dev,
- libfreenect-dev,
  libfreetype6-dev,
  libjack-dev,
  libjpeg-dev,
@@ -26,9 +24,7 @@
  libsdl1.2-dev,
  libswscale-dev (>= 6:10~),
  libtheora-dev,
- libusb-1.0-0-dev,
  libvorbis-dev,
- libxml2-dev,
  libxv-dev,
  libxvidcore-dev
 Standards-Version: 3.9.8

Bug#979604: ebook2cw FTCBFS: hard codes the build architecture compiler

[Helmut Grohne]

Source: ebook2cw
Version: 0.8.3-1
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

Thanks for applying my previous cross build patch. Unfortunately,
upstream regressed in another way. They turned the $(CC) invocations
into hard coded gcc calls. That's the build architecture compiler and it
needs to be changed back to $(CC). Please consider applying the attached
patch.

Helmut
--- ebook2cw-0.8.3.orig/Makefile
+++ ebook2cw-0.8.3/Makefile
@@ -26,17 +26,17 @@
 all: ebook2cw
 
 ebook2cw: ebook2cw.c codetables.h
-	gcc ebook2cw.c -pedantic -Wall -lm $(LDFLAGS) $(CFLAGS) -o ebook2cw
+	$(CC) ebook2cw.c -pedantic -Wall -lm $(LDFLAGS) $(CFLAGS) -o ebook2cw
 	msgfmt -o po/de.mo po/de.po
 
 cgi: ebook2cw.c codetables.h
-	gcc -static ebook2cw.c $(LDFLAGS) -lm $(CFLAGS) -D CGI -o cw.cgi
+	$(CC) -static ebook2cw.c $(LDFLAGS) -lm $(CFLAGS) -D CGI -o cw.cgi
 
 cgibuffered: ebook2cw.c codetables.h
-	gcc -static ebook2cw.c $(LDFLAGS) -lm $(CFLAGS) -D CGI -D CGIBUFFERED -o cw.cgi
+	$(CC) -static ebook2cw.c $(LDFLAGS) -lm $(CFLAGS) -D CGI -D CGIBUFFERED -o cw.cgi
 
 static:
-	gcc -static ebook2cw.c $(LDFLAGS) -lm $(CFLAGS) -o ebook2cw
+	$(CC) -static ebook2cw.c $(LDFLAGS) -lm $(CFLAGS) -o ebook2cw
 
 install:
 	$(INSTALL) -d -v  $(DESTDIR)/share/man/man1/

Bug#976439: wminput: Aborts with "undefined symbol: PyVarObject_CallFunction"

[Omar Jair Purata Funes]

Package: wminput
Version: 0.6.91-2+b1
Followup-For: Bug #976439
X-Debbugs-Cc: omarpura...@gmail.com

Also experiencing this on bullseye. I'm trying to use the mentioned forks above 
but none of them seem to work properly yet. Would be glad to help patch testing 
in case something turns out.


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

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

Versions of packages wminput depends on:
ii  libbluetooth3  5.55-3
ii  libc6  2.31-6
ii  libcwiid1  0.6.91-2+b1
ii  libpython3.9   3.9.1-1
ii  python3-cwiid  0.6.91-2+b1

wminput recommends no packages.

wminput suggests no packages.

-- Configuration Files:
/etc/cwiid/wminput/gamepad changed:
Classic.Dpad.X = ABS_X
Classic.Dpad.Y = ABS_Y
Classic.LStick.X = ABS_HAT0X
Classic.LStick.Y = ABS_HAT0Y
Classic.RStick.X = ABS_HAT1X
Classic.RStick.Y = ABS_HAT1Y
Classic.LAnalog = ABS_GAS
Classic.RAnalog = ABS_BRAKE
Classic.A = BTN_A
Classic.B = BTN_B
Classic.X = BTN_X
Classic.Y = BTN_Y
Classic.Minus = BTN_SELECT
Classic.Plus  = BTN_START
Classic.Home  = BTN_MODE
Classic.L  = BTN_TL
Classic.R  = BTN_TR
Classic.ZL = BTN_TL2
Classic.ZR = BTN_TR2
Classic.Down = BTN_THUMBL
Classic.Up = BTN_THUMBR
 
 
Wiimote.Up = KEY_U
Wiimote.Down = KEY_D
Wiimote.Left = KEY_L
Wiimote.Right = KEY_R
Wiimote.1 = KEY_1
Wiimote.2 = KEY_2
Wiimote.A = KEY_A
Wiimote.B = KEY_B
Wiimote.Plus = KEY_EQUAL
Wiimote.Minus = KEY_MINUS
Wiimote.Home = KEY_H
Wiimote.Dpad.X = ABS_HAT2X
Wiimote.Dpad.Y = ABS_HAT2Y


-- no debconf information

Bug#967988: tnat64: Removal of sys_errlist

[Logan Rosen]

Package: tnat64
Version: 0.05-1
Followup-For: Bug #967988
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu hirsute ubuntu-patch
X-Debbugs-Cc: lo...@ubuntu.com
Control: tags -1 patch

Hi,

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

  * d/p/glibc_2.32.patch: Use strerror() instead of sys_errlist to fix FTBFS
with glibc 2.32.

Thanks for considering the patch.

Logan
diff -Nru tnat64-0.05/debian/control tnat64-0.05/debian/control
--- tnat64-0.05/debian/control  2018-04-03 08:47:37.0 -0400
+++ tnat64-0.05/debian/control  2021-01-08 17:30:34.0 -0500
@@ -1,8 +1,7 @@
 Source: tnat64
 Section: net
 Priority: optional
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: Andrew O. Shadura 
+Maintainer: Andrew O. Shadura 
 Build-Depends: debhelper (>= 8), dh-autoreconf
 Standards-Version: 3.9.2
 Vcs-Hg: http://hg.debian.org/hg/collab-maint/tnat64/#debian
diff -Nru tnat64-0.05/debian/patches/glibc_2.32.patch 
tnat64-0.05/debian/patches/glibc_2.32.patch
--- tnat64-0.05/debian/patches/glibc_2.32.patch 1969-12-31 19:00:00.0 
-0500
+++ tnat64-0.05/debian/patches/glibc_2.32.patch 2021-01-08 17:30:23.0 
-0500
@@ -0,0 +1,17 @@
+--- a/tnat64.c
 b/tnat64.c
+@@ -251,12 +251,12 @@
+ }
+ if (errno != ENETUNREACH)
+ {
+-show_msg(MSGDEBUG, "Error: %d (%s)\n", errno, 
sys_errlist[errno]);
++show_msg(MSGDEBUG, "Error: %d (%s)\n", errno, 
strerror(errno));
+ return -1;
+ }
+ else
+ {
+-show_msg(MSGDEBUG, "Error: %d (%s)\n", errno, 
sys_errlist[errno]);
++show_msg(MSGDEBUG, "Error: %d (%s)\n", errno, 
strerror(errno));
+ current_af = AF_INET6;
+ failed++;
+ }
diff -Nru tnat64-0.05/debian/patches/series tnat64-0.05/debian/patches/series
--- tnat64-0.05/debian/patches/series   1969-12-31 19:00:00.0 -0500
+++ tnat64-0.05/debian/patches/series   2021-01-08 17:30:32.0 -0500
@@ -0,0 +1 @@
+glibc_2.32.patch

Bug#896816: ITP: lowdown -- Simple markdown translator

[Jon Bernard]

On Fri, Jan 8, 2021, at 4:44 PM, Faidon Liambotis wrote:
> owner 896816 !
> thanks
> 
> On Tue, Apr 24, 2018 at 10:24:06AM -0400, Jon Bernard wrote:
> > * Package name: lowdown
> 
> It seems this ITP has been pending for 2½ years, and looks abandoned.
> 
> I was interested in this package, so I worked with upstream to resolve a
> bunch of integration issues with both lowdown and oconfigure (its build
> system), plus a PR to libbsd, and prepared a package suitable for
> inclusion into Debian.
> 
> I pushed the repository to Salsa, under the Debian project:
>   https://salsa.debian.org/debian/lowdown
> 
> I'll upload to unstable momentarily; Jon or anyone else, if you want to
> comaintain you're more than welcome!

That’d be great, thanks.

— 
Jon

Bug#957902: uronode: ftbfs with GCC-10

[Logan Rosen]

Package: uronode
Version: 2.10-1
Followup-For: Bug #957902
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu hirsute ubuntu-patch
X-Debbugs-Cc: lo...@ubuntu.com
Control: tags -1 patch

Hi,

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

  * d/p/gcc-10.patch: Fix compilation with GCC 10.

Thanks for considering the patch.

Logan
diff -Nru uronode-2.10/debian/patches/gcc-10.patch 
uronode-2.10/debian/patches/gcc-10.patch
--- uronode-2.10/debian/patches/gcc-10.patch1969-12-31 19:00:00.0 
-0500
+++ uronode-2.10/debian/patches/gcc-10.patch2021-01-08 17:16:03.0 
-0500
@@ -0,0 +1,13 @@
+--- a/util.c
 b/util.c
+@@ -17,8 +17,8 @@
+ #include "procinfo.h"
+ 
+ static char buf[256];
+-char *HostName;
+-char *Prompt;
++extern char *HostName;
++extern char *Prompt;
+ 
+ void node_msg(const char *fmt, ...)
+ {
diff -Nru uronode-2.10/debian/patches/series uronode-2.10/debian/patches/series
--- uronode-2.10/debian/patches/series  2019-08-17 17:43:25.0 -0400
+++ uronode-2.10/debian/patches/series  2021-01-08 17:15:15.0 -0500
@@ -4,3 +4,4 @@
 install-dir-creation
 makefile-install-locations
 
+gcc-10.patch

Bug#956041: libmaxminddb: FTBFS (BD-Uninstallable): Build-Depends-Arch on pandoc

[Thorsten Glaser]

Hi Faidon,

> generating libmaxminddb's manpages with lowdown should be possible. I
> also pushed the lowdown package to NEW, so hopefully by the time that
> reaches the archive, I'll be able to push an even newer upstream that
> can be used by libmaxminddb.

good idea!

> You may be delighted to hear that lowdown is a small codebase, written
> in C, with only libbsd as an (optional) dependency. Hopefully this will

Yeah, I know Kristaps Džonsons’ stuff. A bit sad it translates to man(7)
not mdoc(7) but the source format lacks the required semantic markup
anyway so there’s not much one can do here :/

> Finally, I also made a PR against upstream libmaxminddb, that allows one
> to use translators different than pandoc, starting with lowdown:
>   https://github.com/maxmind/libmaxminddb/pull/248

☺

> All in all, this is going to take a little while longer, but is on track
> to get fixed by having a smaller build-dependency tree. Hopefully this
> will alleviate any issues you may have had in the past with
> porting/bootstrapping.

Thank you for the extra effort and the status update!

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

Bug#979602: grub2: /boot/grub/i386-pc/ is left empty

[Val Lorentz]

Package: grub2
Version: 2.04-12


Dear maintainers,


I just tried to install a Bullseye system with these commands:

  debootstrap bullseye .
  mount --bind /dev dev
  mount --bind /proc proc
  mount --bind /sys sys
  chroot .

Then, inside the chroot:

  apt install grub2
  grub-install /dev/sdd
  update-grub


Then unmounting everything and booting on the disk just created, I get this:

  file /boot/grub/i386-pc/normal.mod not found

and /boot/grub/i386-pc/ is indeed empty.


Running the exact same commands with "buster" instead of "bullseye" on
the first line causes /boot/grub/i386-pc/ to be non-empty.


In both cases, the whole filesystem is on a single LVM logical volume on
/dev/sdd1 (no separate partition for /boot)


Val



OpenPGP_signature
Description: OpenPGP digital signature

Bug#962451:

[Andreas Hasenack]

Hello,

this looks like it's the upstream fix:
https://github.com/linux-audit/audit-userspace/commit/ee6608eca034494fc2597b2990852adec236e486

I'm trying that patch in an Ubuntu update for bionic, which is also
affected by this bug.

Bug#979601: git-lfs: autopkgtest failure

[Sebastian Ramacher]

Source: git-lfs
Version: 2.13.1-1
Severity: serious
X-Debbugs-Cc: sramac...@debian.org

git-lfs is currently unable to migrate to testing because it fails its
autopkgtest:
| rm obj-x86_64-linux-gnu/bin/cmd
| rm: cannot remove 'obj-x86_64-linux-gnu/bin/cmd': No such file or directory
| make[1]: *** [debian/rules:22: override_dh_auto_build] Error 1
| make[1]: Leaving directory 
'/tmp/autopkgtest-lxc.yac8wpzf/downtmp/autopkgtest_tmp'
| make: *** [debian/rules:12: build] Error 2
| autopkgtest [21:23:16]: test dh-golang-autopkgtest: ---]
| autopkgtest [21:23:16]: test dh-golang-autopkgtest:  - - - - - - - - - - 
results - - - - - - - - - -
| dh-golang-autopkgtest FAIL non-zero exit status 2

See
https://ci.debian.net/data/autopkgtest/testing/amd64/g/git-lfs/9492689/log.gz

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#979562: lightdm session termination does not stop xscreensaver

[Jamie Zawinski]

> In xscreensaver (or maybe lightdm).
> Why is xscreensaver started in the lightdm session anyway?
> Is xscreensaver really usable as a per user service or should it be per 
> session?
> Why is the lightdm xscreensaver instance interfering with the xscreensaver 
> instance of the logged in user?
> Questions that only the xscreensaver maintainer can answer.
> 
> If he thinks there is a genuine systemd issue, then I'd appreciate if it was 
> reassigned back with more details.

XScreenSaver author here. I know nothing about lightdm, and didn't write the 
code attempting to integrate the two. However:

1) XScreenSaver should be running as the logged-in user, and terminate when 
they log out. Typically this happens when the X server dies and the $DISPLAY 
socket is closed, but SIGTERM works just as well.

2) It is also reasonable to configure things so that XScreenSaver is running 
when no one is logged in (so that there is a screensaver atop the login 
screen). If it is launched as root, it will setuid to "nobody" at startup, etc. 
But in this case, when a user logs in, it must be killed and re-started as that 
user.

Bug#979600: src:ucx: invalid maintainer address

[Ansgar]

Source: ucx
Version: 1.10.0~rc1-1
Severity: serious
X-Debbugs-Cc: Alastair McKinstry 

The maintainer address is invalid, see below.

Ansgar

 Start of forwarded message 
From: Mail Delivery System 
Subject: Mail delivery failed: returning message to sender
Date: Fri, 08 Jan 2021 19:49:42 +

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  debian-science-maintain...@lists.alioth.debian.net
Unrouteable address
Reporting-MTA: dns; mailly.debian.org

Action: failed
Final-Recipient: rfc822;debian-science-maintainers@lists.alioth.debian.net
Status: 5.0.0

Bug#979139: Answering calls

[ael]

After my last post there was a reply on the linphone list.

I tried again in a completely new session, and this time a small window
popped up in the bottom right hand side of the screen.

I find it hard to believe that I missed that before, but perhaps I was
concentrating on the main linphone window and somehow escaped my notice.

ael

Bug#979175: fixed in zeromq3 4.3.3-5

[Luca Boccassi]

On Fri, 8 Jan 2021 at 17:21, László Böszörményi (GCS)  wrote:
>
> On Fri, Jan 8, 2021 at 11:12 AM Laurent Bigonville  wrote:
> > On Thu, 07 Jan 2021 20:35:39 + Debian FTP Masters
> >  wrote:
> >  > Source: zeromq3
> >  > Source-Version: 4.3.3-5
> > [...]
> >  > - FTBFS on kFreeBSD (closes: #979175).
> > [...]
> >
> > Unfortunately this was not enough to fix the FTBFS on kfreebsd:
> > https://buildd.debian.org/status/fetch.php?pkg=zeromq3=kfreebsd-amd64=4.3.3-5=1610053267=0
>  Yeah, noticed already. Luca, may you do a complete check and fix for
> kFreeBSD builds?
>
> Thanks,
> Laszlo/GCS

Hi,

I cannot seem to be able to access the kfreebsd porterbox
lemon.debian.net (ssh key not recognised, asks for password, other
porterboxes work just fine), so I do not have a way to test this.
Opened another PR based on bug report:

https://github.com/zeromq/libzmq/pull/4121

Kind regards,
Luca Boccassi

Bug#979599: trscripts: Incorrect build xfonts-bolkhov-misc

[nefedov]

Package: trscripts
Version: 1.18
Severity: normal
X-Debbugs-Cc: nefedov.y...@jinr.ru

 I installed the "new" version of xfonts-bolkhov-misc
 (xfonts-bolkhov-misc), and noticed that the russian letter 'у' is
 displayed as latin u. This was strange, since according to changelog:
  * Non maintainer upload by the Reproducible Builds team.
  * No source change upload to rebuild on buildd with .buildinfo files.

 I rebuilt from the source package and the problem disappeared.
 However, I noticed that the awk program was used. I have the default
 gawk version. After I installed the default mawk, the error
 reproduced. I also noticed that the file rfx-unicode-conv (created
 when building the package:
 trbdf --foundry=rfx -f unicode -t unicode_small -s >rfx-unicode-conv )
 is significantly different when using different versions of the gwk.

 I am not sure that this behavior can be called as the bug, but
 apparently it is necessary to strictly directed which version of the
 'awk' should be used.

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (400, 'unstable')
Architecture: amd64 (x86_64)

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

-- no debconf information

Bug#979597: cairosvg: CVE-2021-21236: Regular Expression Denial of Service (REDoS)

[Salvatore Bonaccorso]

Source: cairosvg
Version: 2.5.0-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for cairosvg.

CVE-2021-21236[0]:
| CairoSVG is a Python (pypi) package. CairoSVG is an SVG converter
| based on Cairo. In CairoSVG before version 2.5.1, there is a regular
| expression denial of service (REDoS) vulnerability. When processing
| SVG files, the python package CairoSVG uses two regular expressions
| which are vulnerable to Regular Expression Denial of Service (REDoS).
| If an attacker provides a malicious SVG, it can make cairosvg get
| stuck processing the file for a very long time. This is fixed in
| version 2.5.1. See Referenced GitHub advisory for more information.


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-21236
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-21236
[1] https://github.com/Kozea/CairoSVG/security/advisories/GHSA-hq37-853p-g5cf
[2] 
https://github.com/Kozea/CairoSVG/commit/063185b60588a41d4df661ad70f9f7b699901abc

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#961814: marked as pending in golang-google-protobuf

[Alberto Bertogli]

On Fri, Jan 08, 2021 at 11:30:21PM +0800, Shengjing Zhu wrote:

On Fri, Jan 8, 2021 at 11:17 PM Alberto Bertogli
 wrote:


On Thu, Jan 07, 2021 at 11:12:24PM +0800, Shengjing Zhu wrote:
>On Thu, Jan 7, 2021 at 10:59 PM Alberto Bertogli
> wrote:
>> But those issues are not made worse by allowing golang-google-protobuf
>> to go in, right?
>>
>
>Let golang-google-protobuf go in is one thing, it's not difficult.
>However without golang-goprotobuf 1.4.x it's not useful currently. But
>it will be changed if upstream has switched to golang-google-protobuf
>only.

But IIUC that's what foka@'s lastest changes do - now the two packages
are independent so golang-google-protobuf can go in?

This would unblock:
1) Some upstream packages that have upgraded to the new library and are
using pregenerated pb.go without the dependency.
2) Packages that have moved/want to move to the new library and generate
pb.go as part of the build (without needing grpc).

And no packages are forced into anything, since upstream needs to do the
update explicitly anyway, the ones using golang-goprotobuf will continue
to function just fine.

I understand not all problems are fixed and some things remain, but it
seems it'd be a step in the right direction since at least some packages
will be able to move forward, without causing any new
complications/regressions.

Or am I missing something?



You are right. The only concern from my side is the usefulness of
golang-google-protobuf without upgrading golang-goprotobuf to 1.4.
If some packages are already ready for using golang-google-protobuf
solely, sure we should try.


Yeah, the reason I'm personally interested in this is I have one package 
I'm upstream for (chasquid) in this situation. I've already done the 
required patching and is blocked on this package.


I am also waiting on the change to move other projects forward for the 
same reason :)


Let me know if there's anything I can do, or how can I help!

Thanks again!
Alberto

Bug#959117: Unable to mount with fuse3 (fusermount: unknown option 'nonempty')

[Nikolaus Rath]

Hi Graham,

It might be fixed, I'm afraid I can't tell any better than you. I am no longer 
using the Debian packages.

Best,
-Nikolaus

--
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

On Fri, 8 Jan 2021, at 17:54, Graham Cobb wrote:
> Package: s3ql
> Followup-For: Bug #959117
> 
> Thanks Nikolaus.
> 
> I am unable to reproduce this problem with s3ql 3.3.2+dfsg-2+b2 and
> fuse3 3.10.1-1 (the versions currently in unstable).
> 
> I am using:
> 
> mount.s3ql s3://eu-west-1/my-bucket-location/s3ql/sub-bucket/ /mnt/a
> umount.s3ql /mnt/a
> 
> I have tried both with and without files in /mnt/a.
> 
> Is this fixed or am I not reproducing it properly?
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (990, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.8.0-3-amd64 (SMP w/8 CPU threads)
> Kernel taint flags: TAINT_WARN
> Locale: LANG=en_IE.utf8, LC_CTYPE=en_IE.utf8 (charmap=UTF-8) (ignored: 
> LC_ALL set to en_IE.utf8), LANGUAGE=en_GB
> Shell: /bin/sh linked to /bin/bash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages s3ql depends on:
> ii  fuse3 [fuse]   3.10.1-1
> ii  libc6  2.31-6
> ii  libjs-sphinxdoc3.4.1-1
> ii  libsqlite3-0   3.34.0-1
> ii  procps 2:3.3.16-5
> ii  psmisc 23.3-1
> ii  python33.9.1-1
> ii  python3-apsw   3.32.2-r1-1+b1
> ii  python3-cryptography   3.2.1-1
> ii  python3-defusedxml 0.6.0-2
> ii  python3-dugong 3.7.4+dfsg-2
> ii  python3-google-auth1.5.1-2
> ii  python3-llfuse 1.3.6+dfsg-2+b3
> ii  python3-pkg-resources  51.1.0-1
> ii  python3-requests   2.25.1+dfsg-2
> 
> Versions of packages s3ql recommends:
> ii  python3-systemd  234-3+b3
> 
> s3ql suggests no packages.
> 
> -- no debconf information
>

Bug#979596: Missing fonts from package

[Phillip Susi]

Package: kbd
Version: 2.3.0-3

The t and drdos fonts provided by the upstream kbd package are missing
in the debian binary package.

Bug#570623: reprepro: please add multiple version management

[Marek Marczykowski-Górecki]

On Tue, 24 Mar 2020 15:36:39 +0100 Michael Prokop  wrote:
> Hi,
> 
> * Michael Prokop [Wed Jul 03, 2019 at 11:59:23AM +0200]:
> > * Benjamin Drung [Wed Apr 03, 2019 at 12:11:55PM +0200]:
> 
> > > I refreshed the patches on top of version 5.3.0 and pushed it to 
> > > https://salsa.debian.org/bdrung/reprepro/ and 
> > > https://github.com/profitbricks/reprepro
> 
> > Thanks for your efforts, Benjamin, highly appreciated.

I have tested the above branch (mostly 'include' and 'export' commands)
and generally it works fine. I've found one weird corner case related to
updating from older reprepro (5.1.1, without the patches), possibly db
format:
 - packages that were in the db before update, are no longer included in
   generated metadata ('export' command), unless added again with
   'include' command
 - 'dumpreferences' _does_ include those missing packages

It may be also that I'm missing some explicit db conversion step (I
haven't done anything, just updated reprepro package).

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?


signature.asc
Description: PGP signature

Bug#892664: dpkg: Please add support for zstd (Zstandard) compressed packages

[Balint Reczey]

On Fri, Jan 8, 2021 at 8:54 PM Balint Reczey
 wrote:
>
> Control: retitle -1 dpkg: Please add decompression support for zstd
> (Zstandard) compressed packages

And the updated patch I forgot to attach.

-- 
Balint Reczey
Ubuntu & Debian Developer
From b32b384666cd7ef61f61d7ba4761b03bd61af776 Mon Sep 17 00:00:00 2001
From: Balint Reczey 
Date: Thu, 8 Mar 2018 09:53:36 +0100
Subject: [PATCH] dpkg: Add Zstandard compression and decompression support for
 binary packages

---
 README   |   1 +
 configure.ac |   2 +
 debian/control   |   3 +
 debian/rules |   1 +
 dpkg-deb/Makefile.am |   1 +
 dpkg-deb/extract.c   |   1 +
 dpkg-deb/main.c  |   7 ++
 lib/dpkg/compress.c  | 157 ++-
 lib/dpkg/compress.h  |   1 +
 m4/dpkg-libs.m4  |   7 ++
 man/deb.pod  |   6 +-
 t-func/deb-format.at |  26 +++
 12 files changed, 210 insertions(+), 3 deletions(-)

diff --git a/README b/README
index dd5a70fac..898369b7c 100644
--- a/README
+++ b/README
@@ -73,6 +73,7 @@ To enable optional functionality or programs, this software might be needed:
 
   libmd (used by libdpkg, currently falling back to embedded code)
   libz (from zlib, used instead of gzip command-line tool)
+  libzstd (from libzstd, used instead of zstd command-line tool)
   liblzma (from xz utils, used instead of xz command-line tool)
   libbz2 (from bzip2, used instead of bzip2 command-line tool)
   libselinux
diff --git a/configure.ac b/configure.ac
index 10d2ad278..7d9151376 100644
--- a/configure.ac
+++ b/configure.ac
@@ -88,6 +88,7 @@ AC_SYS_LARGEFILE
 # Checks for libraries.
 DPKG_LIB_MD
 DPKG_LIB_Z
+DPKG_LIB_ZSTD
 DPKG_LIB_BZ2
 DPKG_LIB_LZMA
 DPKG_LIB_SELINUX
@@ -279,6 +280,7 @@ Configuration:
 libselinux  . . . . . . . . . : $have_libselinux
 libmd . . . . . . . . . . . . : $have_libmd
 libz  . . . . . . . . . . . . : $have_libz
+libzstd  . . . . . . . . . .  : $have_libzstd
 liblzma . . . . . . . . . . . : $have_liblzma
 libbz2  . . . . . . . . . . . : $have_libbz2
 libcurses . . . . . . . . . . : ${have_libcurses:-no}
diff --git a/debian/control b/debian/control
index 52f4d8986..0df054b0e 100644
--- a/debian/control
+++ b/debian/control
@@ -16,7 +16,9 @@ Build-Depends:
 # Needed for --porefs defaults, conditional addenda and mode=eof.
  po4a (>= 0.59),
  zlib1g-dev,
+ zstd,
  libbz2-dev,
+ libzstd-dev,
  liblzma-dev,
  libselinux1-dev [linux-any],
  libncurses-dev (>= 6.1+20180210) | libncursesw5-dev,
@@ -56,6 +58,7 @@ Multi-Arch: same
 Depends:
  ${misc:Depends},
  zlib1g-dev,
+ libzstd-dev,
  liblzma-dev,
  libbz2-dev,
 Description: Debian package management static library
diff --git a/debian/rules b/debian/rules
index fde5388a5..87c74bfee 100755
--- a/debian/rules
+++ b/debian/rules
@@ -65,6 +65,7 @@ build-tree/config.status:
 		--with-devlibdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH) \
 		--without-libmd \
 		--with-libz \
+		--with-libzstd \
 		--with-liblzma \
 		--with-libbz2
 
diff --git a/dpkg-deb/Makefile.am b/dpkg-deb/Makefile.am
index 02d79ed7d..bbd30e02c 100644
--- a/dpkg-deb/Makefile.am
+++ b/dpkg-deb/Makefile.am
@@ -21,5 +21,6 @@ dpkg_deb_LDADD = \
 	../lib/dpkg/libdpkg.la \
 	$(LIBINTL) \
 	$(Z_LIBS) \
+	$(ZSTD_LIBS) \
 	$(LZMA_LIBS) \
 	$(BZ2_LIBS)
diff --git a/dpkg-deb/extract.c b/dpkg-deb/extract.c
index d0f6cb6c4..bf2d782a4 100644
--- a/dpkg-deb/extract.c
+++ b/dpkg-deb/extract.c
@@ -180,6 +180,7 @@ extracthalf(const char *debar, const char *dir,
   decompressor = compressor_find_by_extension(extension);
   if (decompressor != COMPRESSOR_TYPE_NONE &&
   decompressor != COMPRESSOR_TYPE_GZIP &&
+  decompressor != COMPRESSOR_TYPE_ZSTD &&
   decompressor != COMPRESSOR_TYPE_XZ)
 ohshit(_("archive '%s' uses unknown compression for member '%.*s', "
  "giving up"),
diff --git a/dpkg-deb/main.c b/dpkg-deb/main.c
index 17ed92b18..d728af748 100644
--- a/dpkg-deb/main.c
+++ b/dpkg-deb/main.c
@@ -108,7 +108,11 @@ usage(const struct cmdinfo *cip, const char *value)
 "  --[no-]uniform-compression   Use the compression params on all members.\n"
 "  -z#  Set the compression level when building.\n"
 "  -Z Set the compression type used when building.\n"
+#ifdef ENABLE_ZSTD_COMPRESSOR
+" Allowed types: gzip, xz, zstd, none.\n"
+#else
 " Allowed types: gzip, xz, none.\n"
+#endif
 "  -S Set the compression strategy when building.\n"
 " Allowed values: none; extreme (xz);\n"
 " filtered, huffman, rle, fixed (gzip).\n"
@@ -245,6 +249,9 @@ int main(int argc, const char *const *argv) {
   if (opt_uniform_compression &&
   (compress_params.type != COMPRESSOR_TYPE_NONE &&
compress_params.type != COMPRESSOR_TYPE_GZIP &&
+#ifdef 

Bug#877946: #877946: ITP:cx_oracle - Python Interface for Oracle Database

[Joost van Baal-Ilić]

Hi,

Thanks to the work of Adam Cecile at
https://salsa.debian.org/python-team/packages/python-cx-oracle I've just
published

 python-cx-oracle_7.3.debian.orig.tar.gz
 python-cx-oracle_7.3.debian-0.1+deb9u1.dsc
 python-cx-oracle_7.3.debian-0.1+deb9u1.debian.tar.xz
 python3-cx-oracle_7.3.debian-0.1+deb9u1_amd64.deb

: backports to Debian 9/stretch of python-cx-oracle.  Available from
https://non-gnu.uvt.nl/debian/stretch/python-cx-oracle/ or

 deb http://non-gnu.uvt.nl/debian stretch python-cx-oracle

.

Bye,

Joost

-- 
Joost van Baal-Ilić   http://abramowitz.uvt.nl/
 Tilburg University
mailto:joostvb.uvt.nl   The Netherlands

Bug#892664: dpkg: Please add support for zstd (Zstandard) compressed packages

[Balint Reczey]

Control: retitle -1 dpkg: Please add decompression support for zstd
(Zstandard) compressed packages

Hi Guillem,

On Fri, Apr 20, 2018 at 5:04 AM Guillem Jover  wrote:
>
> Hi!
>
> On Wed, 2018-04-18 at 11:56:27 +0200, Balint Reczey wrote:
> > On Mon, Apr 16, 2018 at 3:51 AM, Balint Reczey
> >  wrote:
> > > On Sun, Mar 18, 2018 at 3:38 AM, Guillem Jover  wrote:
> > >> On Sun, 2018-03-11 at 21:51:05 +0100, Balint Reczey wrote:
> > >>> Package: dpkg
> > >>> Version: 1.19.0.5
> > >>> Severity: wishlist
> > >>> Tags: patch
> > >>
> > >>> Please add support for Zstandard compression to dpkg and other
> > >>> programs generated by the dpkg source package [1].
> > >>
> > >> Thanks. I started implementing this several weeks ago after having
> > >> discussed it with Julian Andres Klode on IRC, but stopped after seeing
> > >> the implementation getting messy given the current code structure.
> > >
> > > I think it is not that bad. :-)
>
> Well, that file is a mess already. :)
>
> > >> So, the items that come to mind (most from the dpkg FAQ [F]:
> > >>
> > >> * Availability in general Unix systems would be one. I think the code
> > >>   should be portable, but I've not checked properly.
> > >
> > > The libzstd package does not have any special dependency and there are
> > > packages for other Unix-like systems [2][3][4].
>
> Right, as suspected, but it's nice to get confirmation, thanks.
>
> > >> * Size of the shared library another, it would be by far the fattest
> > >>   compression lib used by dpkg. It's not entirely clear whether the
> > >>   shlib embeds a zlib library?
> > >
> > > I agree that the libzstd library is fairly big and I'd like to look
> > > into ways of making it leaner, maybe creating a variant with limited
> > > features covering what is needed in dpkg, apt, btrfs-progs and other
> > > system packages.
>
> That could be an option, ideally sanctioned by upstream to avoid a
> perpetual fork, and possible divergence from upstream format, encoding,
> etc.
>
> > > It does not seem to embed the zlib library, but it offers many
> > > features which may be obsolete for dpkg.
> > >
> > > I tried dropping support for legacy file formats for example
> > > (ZSTD_LEGACY_SUPPORT=8) and the size of the library dropped to 382K
> > > from the original 490K.
>
> Still a pretty fat. :)
>
> > >> * Increase in the (build-)essential set (directly and transitively).
> > >
> > > Yes, that's true, while apt also started supporting Zstd and .
>
> apt is not part of the essential-set though.
>
> > >> * It also seems the format has changed quite some times already, and
> > >>   it's probably the reason for the fat shlib. Not sure if the format
> > >>   has stabilized enough to use this as good long-term storage format,
> > >>   and what's the policy regarding supporting old formats for example,
> > >>   given that this is intended mainly to be used for real-time and
> > >>   streaming content and similar. For example the Makefile for libzstd
> > >>   defaults to supporting v0.4+ only, which does not look great.
> > >
> > > Format stability is a very valid concern and upstream claims the
> > > current format to be stable [5] (since zstd v0.8.1).
>
> I understand that to mean the current format will not change, but what
> will happen when and iff a new format is needed/wanted, what's their
> stability guarantees, etc.? As I mentioned, one thing is to target
> streaming compression, the other long-term storage; the time-frames
> expected from each of those might be completely opposite.
>
> > >> * The license seems fine, as being very permissive, or it could affect
> > >>   availability. This one I need to add to the FAQ.
> > >> * Memory usage seemed fine or slight better depending on the compression
> > >>   level, but not when wanting equal or less space used?
> > >> * Space used seemed worse.
> > >
> > > Yes, space used is worse than with xz compression, but I think the
> > > much better compression and decompression speed would make up for
> > > that.
>
> That still depends at least on the local hardware used and on the
> network speed.
>
> > >> * Compression and decompression speed seemed better depending on the
> > >>   compression and decompression levels.
> > >>
> > >> [F] 
> > >> 
> > >>
> > >> Overall I'm still not sure whether this is worth it. Also the
> > >> tradeoffs for stable are different to unstable/testing, or for
> > >> fast/slow networks, or long-term storage, one-time installations,
> > >> or things like CI and similar.
> > >>
> > >> In any case this would still need discussion on debian-devel, and
> > >> involvement from other parts of the project, at least ftp-masters for
> > >> example. And whether the added "eternal" support makes sense if we are
> > >> or not planning to eventually switch to the compressor as the default,
> > >> for example, etc.
> > >
> > > I agree that the tradeoffs are very 

Bug#960451: fixed in meteo-qt 2.1-1

[Pols12]

Hello Yao Wei,

Version in testing is fine, however version in stable is totally broken. 
Do you think it may be uploaded to stable?


Regards,

Pols12

Le 07/01/2021 à 15:57, Debian Bug Tracking System a écrit :

This is an automatic notification regarding your Bug report
which was filed against the meteo-qt package:

#960451: meteo-qt: Cannot connect to server anymore: version≥1.5 is needed

It has been closed by Debian FTP Masters  (reply to 
Yao Wei (魏銘廷) ).

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Debian FTP Masters 
 (reply to Yao Wei (魏銘廷) ) by
replying to this email.

Bug#979595: Cannot squash filename with literal backslash

[Trent W. Buck]

Package: squashfs-tools-ng
Version: 1.0.3-1
Severity: important
File: /usr/bin/gensquashfs

gensquashfs cannot understand filenames that include literal backslashes.
This occurs in the real world to anyone who clones systemd:

https://github.com/systemd/systemd/blob/master/test/fuzz/fuzz-unit-file/

https://github.com/systemd/systemd/blob/master/test/fuzz/fuzz-unit-file/dev-mapper-fedora_krowka%5Cx2dswap.swap

Here is a minimal test recipe:

root@not-omega:/# dpkg-query -W squashfs-tools-ng
squashfs-tools-ng   1.0.3-1
root@not-omega:/# mkdir a
root@not-omega:/# touch a/b\\c
root@not-omega:/# find a -ls
11806  0 drwxr-xr-x   2 root root   60 Jan  8 19:43 a
11807  0 -rw-r--r--   1 root root0 Jan  8 19:43 
a/b\\c
root@not-omega:/# gensquashfs -D a a.sq
packing b/c
b/c: No such file or directory

Note that original squashfs-tools can handle this file, and
squashfs-tools-ng can read the result:

root@not-omega:/# dpkg-query -W squashfs-tools
squashfs-tools  1:4.4-2
root@not-omega:/# mksquashfs a a.sq -noappend
[...]
root@not-omega:/# rdsquashfs --list / a.sq
-rw-r--r-- 0/0 0 b\c
root@not-omega:/# unsquashfs -ll a.sq
Parallel unsquashfs: Using 4 processors
1 inodes (0 blocks) to write

drwxr-xr-x root/root26 2021-01-08 19:43 squashfs-root
-rw-r--r-- root/root 0 2021-01-08 19:43 squashfs-root/b\c


This issue also occurs on squashfs-tools-ng 1.0.0-2.


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

Kernel: Linux 5.6.0-0.bpo.2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE=en_AU:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#979591: llvm-toolchain-11: Please enable libclc

[Sylvestre Ledru]

control: reassign -1 llvm-toolchain-snapshot

control: forcemerge -1 942709



Le 08/01/2021 à 20:10, Fabio Pedretti a écrit :

Source: llvm-toolchain-11
Version: 1:11.0.1-2
Severity: wishlist
X-Debbugs-Cc: pedretti.fa...@gmail.com


yeah, see #942709

Cheers

S

Bug#979593: rox: FTBFS under some locales

[Vagrant Cascadian]

Source: rox
Severity: important
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: username ftbfs
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org kilob...@angband.pl

The 2.11-3 version of calls iconv from debian/rules, which fails to
build under certain locales, as seen in the reproducible builds test
infrastructure:

  https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/rox.html

Fortunately, the locale on buildd.debian.org does successfully build, so
this is not a serious bug.

The attached patch fixes this by calling "iconv" under the C.UTF-8
locale in debian/rules.


live well,
  vagrant
From 8541e68d01354dbca56dc7178e1830c643ccd79a Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Fri, 8 Jan 2021 19:16:50 +
Subject: [PATCH] debian/rules: Run iconv using the C.UTF-8 locale.

Under some locales, iconv fails to run correctly, as shown in the
reproducible builds test infrastructure:

  https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/rox.html
---
 debian/rules | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index a18cc9c..5c8f2fd 100755
--- a/debian/rules
+++ b/debian/rules
@@ -66,7 +66,7 @@ install: build
 	/bin/sh debian/scripts/locale.sh
 	/bin/sh debian/scripts/manual.sh
 
-	iconv -f iso-8859-1 ${DESTDIR}/usr/share/doc/${PACKAGE}/README-es
+	LC_ALL=C.UTF-8 iconv -f iso-8859-1 ${DESTDIR}/usr/share/doc/${PACKAGE}/README-es
 
 # Build architecture-independent files here.
 binary-indep: build install
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#966861: vilistextum: FTBFS: ld: html.o:./src/text.h:16: multiple definition of `ch'; charset.o:./src/text.h:16: first defined here

[Logan Rosen]

Package: vilistextum
Version: 2.6.9-1.2
Followup-For: Bug #966861
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu hirsute ubuntu-patch
X-Debbugs-Cc: lo...@ubuntu.com
Control: tags -1 patch

Hi,

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

  * d/p/gcc-10.patch: Fix compilation with GCC 10.

Thanks for considering the patch.

Logan
diff -u vilistextum-2.6.9/debian/patches/series 
vilistextum-2.6.9/debian/patches/series
--- vilistextum-2.6.9/debian/patches/series
+++ vilistextum-2.6.9/debian/patches/series
@@ -1 +1,2 @@
 01-add-format-arguments.patch
+gcc-10.patch
only in patch2:
unchanged:
--- vilistextum-2.6.9.orig/debian/patches/gcc-10.patch
+++ vilistextum-2.6.9/debian/patches/gcc-10.patch
@@ -0,0 +1,120 @@
+--- a/src/main.h
 b/src/main.h
+@@ -3,22 +3,22 @@
+ 
+ #include "multibyte.h"
+ 
+-int palm;
+-int   convert_tags;
+-int errorlevel;
+-int convert_characters;
+-int shrink_lines;
+-int remove_empty_alt;
+-int option_links;
+-int option_links_inline;
+-int option_title;
+-int sevenbit;
+-int transliteration;
++extern int palm;
++extern intconvert_tags;
++extern int errorlevel;
++extern int convert_characters;
++extern int shrink_lines;
++extern int remove_empty_alt;
++extern int option_links;
++extern int option_links_inline;
++extern int option_title;
++extern int sevenbit;
++extern int transliteration;
+ 
+-int option_no_image;
+-int option_no_alt;
+-int option_output_utf8;
++extern int option_no_image;
++extern int option_no_alt;
++extern int option_output_utf8;
+ 
+-CHAR *default_image;
++extern CHAR *default_image;
+ 
+ #endif
+--- a/src/text.h
 b/src/text.h
+@@ -9,23 +9,23 @@
+ 
+ #include "multibyte.h"
+ 
+-int LEFT;  
+-int CENTER;
+-int RIGHT;
+-
+-CHAR ch;
+-
+-int paragraph;
+-int div_test;
+-int nooutput;
++extern int LEFT;  
++extern int CENTER;
++extern int RIGHT;
++
++extern CHAR ch;
++
++extern int paragraph;
++extern int div_test;
++extern int nooutput;
+ 
+-int breite;
+-int hr_breite;
++extern int breite;
++extern int hr_breite;
+ 
+ void status();
+ 
+-int tab;
+-int spaces;  
++extern int tab;
++extern int spaces;  
+ 
+ void print_zeile();
+ int is_zeile_empty();
+--- a/src/html.h
 b/src/html.h
+@@ -4,13 +4,13 @@
+ #include "text.h"
+ #include "multibyte.h"
+ 
+-int pre;
++extern int pre;
+ 
+ int get_attr();
+ int get_new_attr(CHAR *name, CHAR *content);
+ 
+-CHAR attr_name[DEF_STR_LEN];
+-CHAR attr_ctnt[DEF_STR_LEN];
++extern CHAR attr_name[DEF_STR_LEN];
++extern CHAR attr_ctnt[DEF_STR_LEN];
+ 
+ void html();
+ void check_for_center();
+--- a/src/text.c
 b/src/text.c
+@@ -47,6 +47,8 @@
+   anz_leere_zeilen=0, /* how many line were blank */
+   noleadingblanks=0;  /* remove blanks lines at the start of the output */
+ 
++CHAR ch;
++
+ /*  */
+ 
+ void center_zeile()
+--- a/src/main.c
 b/src/main.c
+@@ -134,6 +134,8 @@
+ CHAR *default_image=STRING("Image"); /* Default string for IMG without 
ALT-tag */
+ CHAR user_image[DEF_STR_LEN]; /* string supplied by user */
+ 
++int transliteration;
++
+ char help_text[] = 
+ "Usage: vilistextum [OPTIONS] [inputfile|-] [outputfile|-]\n"
+ "\n"

Bug#979591: llvm-toolchain-11: Please enable libclc

[Fabio Pedretti]

Source: llvm-toolchain-11
Version: 1:11.0.1-2
Severity: wishlist
X-Debbugs-Cc: pedretti.fa...@gmail.com

Debian has the libclc source package, but it looks like it is no longer
available upstream.
Actually the web page https://libclc.llvm.org/ points to a dead git
repository.

The mirror repo at https://github.com/llvm-mirror/libclc says:
Mirror kept for legacy. Moved to https://github.com/llvm/llvm-project

Indeed what was inside libclc git repo it is now inside
llvm-toolchain-11 package (see 
https://sources.debian.org/src/llvm-toolchain-11/1:11.0.1-2/libclc/)
and it also has some additional fixes.

So it would be nice to build updated libclc from llvm-toolchain-11 and
then remove the obsolete libclc source package from Debian.

Thanks

Bug#974779: closed by Debian FTP Masters (reply to Gianfranco Costamagna ) (Bug#974779: fixed in llvm-toolchain-9 1:9.0.1-16)

[Gianfranco Costamagna]

control: severity -1 important

I agree on reopening, but I don't think this is a serious issue anymore, since 
we plan to ship stable with
llvm-9 and llvm-11

G.

On Fri, 8 Jan 2021 13:21:40 +0100 Sylvestre Ledru  wrote:
> control: reopen -1
> 
> It isn't fixed for real as Julia needs to be updated!
> 
> S
> 
> 
> Le 08/01/2021 à 13:06, Debian Bug Tracking System a écrit :
> > This is an automatic notification regarding your Bug report
> > which was filed against the julia package:
> >
> > #974779: julia: Please upgrade to llvm-toolchain-11
> >
> > It has been closed by Debian FTP Masters  
> > (reply to Gianfranco Costamagna ).
> >
> > Their explanation is attached below along with your original report.
> > If this explanation is unsatisfactory and you have not received a
> > better one in a separate message then please contact Debian FTP Masters 
> >  (reply to Gianfranco Costamagna 
> > ) by
> > replying to this email.
> >
> >
> 
> 

Bug#979546: docker.io: version in Bullseye does not support "rootless mode", makes privilege escalation trivial

[Chris Mitchell]

On Fri, 8 Jan 2021 11:38:59 +0700
El boulangero  wrote:

> Hi Chris,
> 
> I believe what you refer to is a well-known issue with docker. I have
> this reference from Apr. 2015:
> https://fosterelli.co/privilege-escalation-via-docker.html
> 
> This is how docker works. The most easy mitigation is NOT to add a
> user to the docker group. This way, you will always invoke docker
> with 'sudo docker', and then it's explicit that you're running
> something as root. Explicit better than implicit maybe, at least no
> more "accidental".

This makes some sense. Given that it's apparently well-known that
allowing a user to run Docker essentially gives them unrestricted root
access, I'm rather surprised that no warning was presented at any point
in this process. 

> Second thing, as you noted, docker can access a directory on the host
> only if you share it with '--volume' or '--mount' or something. So
> it's not really accidental if then the process in the container
> writes to the host directory. It's something that you authorized
> explicitly. And the fact that it's a root access is due to the fact
> that the container is run as root, as you correctly noted.

Ah, okay. This, I think, is where I fundamentally misunderstood the
situation. I was picturing the "containerized app" as a single entity,
presenting an all-or-nothing choice between "accept that anything you
run in a Docker container has root access to your whole filesystem" or
"don't use Docker". If Docker is providing meaningful enforcement and
limiting the access of the "contained" app to only the directory(ies)
you share with it in the container config (though not subject to the
host system's *permissions*) that's a very different proposition.

Trusting *myself* not to abuse Docker's privilege-escalation abilities
(on a system where I already have root), checking carefully what paths
are shared via the container configs, and making sure that the path
containing those configs is never shared... That's within the realm of
reasonable expectations.

> If you download and run a containerized app as root, and share your
> /home with the container, then you'd better trust this app 100%.

To be clear, I did not knowingly or explicitly do any of these things
except "download and run a containerized app". I downloaded the app as
a regular user, used my sudo powers to add said user to the docker group
(because all the "getting started" instructions just say that you need
to be in the docker group to use Docker) and ran, as a regular user,
"docker-compose -d up". Now that I know to go looking for it, I see
that the "volumes" directive appears in one of the config files. While
I acknowledge that the responsibility for understanding the tools I use
ultimately falls to me, nothing in this sequence jumps out to me as
"you are granting unrestricted root access!" or "you'd better trust
this app 100%".

As a fairly experienced Debian user, I've been accustomed to add myself
to all sorts of groups over the years, and the only one that has ever
been presented as "this grants full root powers" is sudo, which then
pops up a stern warning the first time you use it. Also it's sudo. Its
singular, stated purpose is to grant root powers. The fact that no
warning popped up anywhere along the way to discovering that my
supposedly sandboxed Docker app was creating files as root on the host
strikes me as alarming.

In my defence, I knew I was playing with things I didn't understand, so
the "regular user" in question was a fresh, blank account in a KVM
virtual machine that has no shared storage or memory. I'm not
*entirely* naive. That said, am I the only one who finds it worrying
how easy it would be for a moderately naive desktop user to unwittingly
grant a malicious containerized app root access to the entire
filesystem of their real system without doing anything obviously
reckless or stupid or encountering any warning along the way? Is this a
thing that can and should be addressed somehow?

> > a search for "docker" on backports.debian.org returned no results
> 
> Indeed, docker sits on top of 100+ dependencies, backporting would
> mean backporting all those dependencies. Plus maybe the go compiler
> and the go library. It would be such a huge work that it's not
> realistic.
> 
> Since Go is a statically compiled language, there's little value in
> backporting anyway. You can just try your luck and install the docker
> from Debian unstable into your Debian stable. It might work. Maybe
> some bugs would be lurking here and there in the dark, maybe not, I
> just don't know.
> 
> As for rootless mode, it should be indeed supported in the 20.10
> version. I myself never tested it. If I'm not mistaken, everything is
> present in the 20.10 package provided in Debian unstable to run the
> rootless mode. You can give it a try :)

If being aware of — and careful with — the "volume" directive is the
key to running Docker containerized apps in a reasonably safe way, I
think I won't mess around 

Bug#979590: libx11-xcb1: Updating to 1.7.0-1 from 1.6.12-1 breaks chromium and google chrome

[Michel Le Bihan]

Package: libx11-xcb1
Version: 2:1.7.0-1
Severity: normal
X-Debbugs-Cc: mic...@lebihan.pl

Dear Maintainer,

After updating libx11-xcb1 chromium and google chrome UI is not
responding to any input and clicking anywhere on the app window causes
the GNOME app is not responding dialog to appear. The app actually is
not frozen because if you pass a URL with dynamic web content as a
parameter, it will be constantly updated. I didn't notice any other
affected app, but I didn't test much.

Michel Le Bihan

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (700, 'testing'), (650, 'unstable'), (600, 'experimental'), (500, 
'unstable-debug'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

-- no debconf information

Bug#979101: Legally problematic GPL-3+ readline dependency

[Francesco Poli]

On Thu, 7 Jan 2021 18:45:14 -0300 Carlos Henrique Lima Melara wrote:

> Hi, folks.

Hello Carlos.

> 
> I'm the new maintainer of devtodo and would appreciate an assistance of the
> debian-legal on the license matter. As noted, devtodo is licensed under
> GPL-2 only, although there is no boilerplate copyright on the source files.

Please note that asking upstream to switch from GPL-2 to GPL-2+ is
not the only way out from this license incompatibility issue.
See my [message] to debian-legal for more information.

[message]: 

Some of these alternative strategies have already been mentioned in the
original bug report...

> 
> Taking this into consideration, would a public mail from the upstream to
> this bug be enough to change the license to GPL-2+? Or it would be necessary
> to add the boilerplate to all source files indicating GPL-2+ licensing?

If you are going for option b (ask the copyright holders to re-license
the program from GPL-2 to GPL-2+), then the best possible outcome would
be to have them add the appropriate boilerplate to all the files.

Failing that, a centralized LICENSE or README file placed by the
copyright holders could suffice (or even a documented e-mail exchange
with all the copyright holders, as a last resort).

I hope this helps.
Thanks for taking care of this!


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgp34VXgoGJeZ.pgp
Description: PGP signature

Bug#979541: sylpheed: [regression] spell check no longer recognizes some correct Italian words

[Francesco Poli]

Control: tags -1 - moreinfo

On Fri, 8 Jan 2021 01:55:09 +0100 Ricardo Mones wrote:

[...]
> Hi Francesco,

Hello Ricardo, thanks a lot for your prompt reply!

> 
> On Thu, Jan 07, 2021 at 11:49:04PM +0100, Francesco Poli wrote:
[...]
> > I tried to downgrade the following packages:
> > 
> >   libaspell15:amd64 from 0.60.8-2 to 0.60.8-1
> >   aspell from 0.60.8-2 to 0.60.8-1
> >   aspell-it from 2.4-20070901-0-3.1 to 2.4-20070901-0-3
> > 
> > but this didn't help.
> > 
> > I am more and more puzzled...
> 
> Current version was not a very fortunate upload, though in theory should
> not have side effects like the ones you're describing here. Anyway, can
> you try to downgrade sylpheed itself to 3.7.0-7 and check?

I've just tried to downgrade sylpheed and sylpheed-i18n to version
3.7.0-7, but this didn't help.

To be honest, I was skeptical, since the new Debian revision (3.7.0-8)
migrated to testing a long ago (during last summer) and I upgraded at
that time.
I had not experienced this issue until very recently: that's why I
tried to downgrade libaspell15. It was the most obvious suspect.
But nothing seems to help...  :-(

> 
> thanks in advance,

Thanks to you, for any help you may provide.

Please take into account that I am experiencing the same exact issue
with claws-mail (which is known to be a fork of sylpheed, although the
two code bases have probably diverged significantly in so much time...)
and with libreoffice-writer (which really surprised me, as I thought it
was not even using the same spell checker library: libhunspell-1.7-0,
rather than libaspell15...).

There's something wrong with some recent upgrade on my Debian testing
boxes, but I really cannot understand where.

Above all, I am confused by the test with aspell (the command-line
program), which still seems to work perfectly.

Any idea?



P.S.: I am removing the moreinfo tag, since I think I replied to your
request for additional information, but, of course, feel free to re-add
the tag, in case you need some other reply from me.


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpEfUMiw8SAN.pgp
Description: PGP signature

Bug#979589: libfm-data: xarchiver command to create archives is wrong

[Ingo Brückl]

Package: libfm-data
Version: 1.3.1-1.1

The xarchiver command to create archives is wrong.
Rather than "--add-to", it must be "--compress".

The bug has been reported upstream (https://github.com/lxde/libfm/pull/69),
but I don't know whether it will be applied before the freeze for bullseye.

Debian GNU/Linux 10.0
Kernel 4.19.0-12-amd64

Bug#979562: lightdm session termination does not stop xscreensaver

[Michael Biebl]

Am 08.01.21 um 14:12 schrieb Eduard Bloch:

Hallo,

I don't fully agree. If you don't see a problem here, WHERE do you see
it?


In xscreensaver (or maybe lightdm).
Why is xscreensaver started in the lightdm session anyway?
Is xscreensaver really usable as a per user service or should it be per 
session?
Why is the lightdm xscreensaver instance interfering with the 
xscreensaver instance of the logged in user?

Questions that only the xscreensaver maintainer can answer.

If he thinks there is a genuine systemd issue, then I'd appreciate if it 
was reassigned back with more details.


Michael




OpenPGP_signature
Description: OpenPGP digital signature

Bug#959117: Unable to mount with fuse3 (fusermount: unknown option 'nonempty')

[Graham Cobb]

Package: s3ql
Followup-For: Bug #959117

Thanks Nikolaus.

I am unable to reproduce this problem with s3ql 3.3.2+dfsg-2+b2 and
fuse3 3.10.1-1 (the versions currently in unstable).

I am using:

mount.s3ql s3://eu-west-1/my-bucket-location/s3ql/sub-bucket/ /mnt/a
umount.s3ql /mnt/a

I have tried both with and without files in /mnt/a.

Is this fixed or am I not reproducing it properly?

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

Kernel: Linux 5.8.0-3-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_IE.utf8, LC_CTYPE=en_IE.utf8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_IE.utf8), LANGUAGE=en_GB
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages s3ql depends on:
ii  fuse3 [fuse]   3.10.1-1
ii  libc6  2.31-6
ii  libjs-sphinxdoc3.4.1-1
ii  libsqlite3-0   3.34.0-1
ii  procps 2:3.3.16-5
ii  psmisc 23.3-1
ii  python33.9.1-1
ii  python3-apsw   3.32.2-r1-1+b1
ii  python3-cryptography   3.2.1-1
ii  python3-defusedxml 0.6.0-2
ii  python3-dugong 3.7.4+dfsg-2
ii  python3-google-auth1.5.1-2
ii  python3-llfuse 1.3.6+dfsg-2+b3
ii  python3-pkg-resources  51.1.0-1
ii  python3-requests   2.25.1+dfsg-2

Versions of packages s3ql recommends:
ii  python3-systemd  234-3+b3

s3ql suggests no packages.

-- no debconf information

Bug#977814: fixed in llvm-toolchain-11 1:11.0.1-1

[Pino Toscano]

In data venerdì 8 gennaio 2021 12:38:20 CET, Gianfranco Costamagna ha scritto:
> llvm-toolchain-11 is now fixed, and clazy should be fixed too.

No, llvm-toolchain-11 is not fixed yet.

> Unfortunately clazy seems to be missing a "break" relationship against old 
> llvm, and britney uses
> the broken testing version to test it.

It makes no sense for clazy to break and old llvm, it should be rather
the other way round... but it shouldn't be needed.

Also, the version in testing is *not* broken. clazy in testing is
perfectly working, and it was the llvm-toolchain-11 upload that broke
it.

> I don't know if we can hint to let it migrate anyway,

Considering nothing was actually done to fix the problems I reported
earlier in this bug, I don't think that letting the newer
llvm-toolchain-11 migrate and break also testing is an acceptable way
forward. Even more so when there was *no* attempt by the Debian LLVM
Maintainers (of which you are part) to debug what was the issue.

All this "fix" did was to apply the diff I mentioned, which was to fix
only a small part of the problems I reported. Also, reading it further,
even the shlibs of all the other libraries need to be fixed: they all
specify old versions (like 9~something) that are satisfied by any
llvm-toolchain-11 version available, including prereleases.

> Let me know if you have a solution for this issue,

The Debian LLVM Maintainers ought to help debug why updating a new
version suddently breaks software built against old versions of it.
Sorry if I seem harsh: LLVM is a key component in a modern Debian
system, so uploading new versions and providing almost no help on
problems does not seem like a good idea for the distribution.

-- 
Pino Toscano

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

Bug#979570: Updating dpkg-buildflags to enable reproducible=+fixfilepath by default

[Vagrant Cascadian]

On 2021-01-08, Lisandro Damián Nicanor Pérez Meyer wrote:
> On Fri, 13 Nov 2020 at 17:40, Vagrant Cascadian
>  wrote:
>>
>> On 2020-11-13, Sune Vuorela wrote:
>> > On 2020-10-27, Vagrant Cascadian  wrote:
>> >> Though, of course, identifying the exact reproducibility problem would
>> >> be preferable. One of the common issues is test suites relying on the
>> >> behavior of __FILE__ returning a full path to find fixtures or other
>> >> test data.
>> >
>> > has QFIND_TESTDATA been adapted to work with this, or are we just
>> > "lucky" that most packages don't actually build and run test suites?
>>
>> Yes, QFINDTESTDATA is one of the primary (only?) issues with test suites
>> found in about 20-30 packages in the archive, according to the
>> archive-wide rebuild that was performed. For most of those packages
>> patches have been submitted, and some are already either fixed or marked
>> as pending.
>
> But QFINDTESTDATA is using __FILE__ in a valid way. It might not be
> what you are expecting, but still a valid usage.
>
> See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=876901 We have
> discussed this before.
>
>
>> If it could be fixed at the core for QFINDTESTDATA, that would be nicer
>> than fixing 20-30 packages individually, though we're not there right
>> now.
>
> In that case I would expect a valid patch from the people interested
> in enabling this. In the meantime the dpkg change broke a very valid
> usage. Inconvenient for reproducibility? yes, probably, but still very
> valid.

We did a full archive rebuild testing this change, and I provided
patches to all known affected packages several months ago. It is a
one-line change in debian/rules in most cases:

  
https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=reproducible-builds%40lists.alioth.debian.org=fixfilepath

It seems there are less than 10 packages left that have not applied the
patch.

Longer-term, it would be nice to be able to fix QFINDTESTDATA to be
compatible, sure.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#979565: /usr/lib/ispell/ogerman.aff: multiple errors

[Roland Rosenfeld]

Hi Thorsten!

Thorsten Glaser schrieb am Freitag, den 08. Januar 2021:

> Package: iogerman
> Version: 1:2-37
> Severity: important
> X-Debbugs-Cc: t...@mirbsd.de
> 
> During an upgrade:
> 
> […]
> Processing triggers for dictionaries-common (1.28.3) ...
> ispell-autobuildhash: Processing 'british' dict.
> ispell-autobuildhash: Processing 'ogerman' dict.
> /usr/lib/ispell/ogerman.aff line 242: No such string character
[...]
> /usr/lib/ispell/ogerman.aff line 782: Single characters must be
> separated by a blank
[...]

Thanks for your bug report, this is some regression of the update of
ispell from 3.4.00-8 to 3.4.01-1.
It breaks processing of the ispell affix files of igerman98 and
hkgerman.

See also https://bugs.debian.org/979575

Greetings
Roland


signature.asc
Description: PGP signature

Bug#977928: obs-studio: virtual camera not working, modinfo not in path

[gregor herrmann]

On Sat, 26 Dec 2020 15:00:38 -0500, Reinhard Tartler wrote:

> Hi Gregor,

Hi Reinhard,
 
> I've applied your patch to our git branch, I think it looks good.

Thank you (and sorry for the late reply).

There may or may not be a second place which might need a similar
change:

plugins/linux-v4l2/v4l2-output.c

53  static int loopback_module_load()
54  {
55  return system(
56  "pkexec modprobe v4l2loopback exclusive_caps=1 
card_label='OBS Virtual Camera' && sleep 0.5");
57  }
58

But that's just a guess, I don't know how pkexec tries to find
modprobe (and I don't have policykit-1 installed and can't test this
codepath)
 
> > The whole virtualcam support currently is a bit fragile (trying to
> > load kernel modules, always using the first of potentially several
> > /dev/video* devices … I wonder if a README would make sense, and I'd
> > be happy to provide a draft.
> I think that'd make a lot of sense, I'm not that familiar with this package.
> I'm happy to look over your draft and apply it with or without
> modifications :-)

Ok, let's try :)
Here are some notes or fragments -- feel free to change/use/… as you
see fit:

Since version 26.1.0+dfsg1-1, obs(1) has support for Virtual Camera
output. This means that it can not only stream or record but also
send the video to a loopback video device (/dev/videoXX) which can
then be used like a "real" webcam in video applications or WebRTC
video conference software.

For the Virtual Camera support the v4l2loopback-dkms package needs to
be installed. In theory this is enough to add a "Start Virtual
Camera" button to the interface; in practice things can go wrong, or
you might want to have more control over the whole process.

In general, if the feature doesn't work, start obs(1) in a terminal,
and it will output helpful diagnostic messages.

The feature is only enabled when obs(1) finds the v4l2loopback kernel
module installed at startup time. This should be guaranteed by having
the v4l2loopback-dkms package installed.

If the kernel module is not loaded, obs(1) will try to do so. For
that purpose it uses pkexec(1) from the policykit-1 package.

But you can also load the module yourself, with root privileges:
- Manually once with
  modprobe v4l2loopback exclusive_caps=1 card_label='OBS Virtual Camera'
- Or you can add 'v4l2loopback' to /etc/modules and
  options v4l2loopback exclusive_caps=1 card_label='OBS Virtual Camera'
  to a file like /etc/modprobe.d/v4l2loopback.conf, then the module
  will be loaded at boottime.

When you want to control which device is created, you can add e.g.
  video_nr=17
the the module options, which will create a /dev/video17 device.

obs(1) will always output to the first loopback video device it finds
(this might become configurable in the future). So if you have more
than one for other purposes make sure to list the one for obs(1)
first in the module options, e.g.
  options v4l2loopback devices=2 video_nr=23,42 card_label="OBS Virtual 
Camera,Some Other Cam" exclusive_caps=1,1
This will create /dev/video23 and /dev/video42 and give them nice
labels, and obs(1) will use the first one with the correct name.

(Cf. also /usr/share/doc/v4l2loopback-dkms/README.md.gz)



Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Leonard Cohen: Please Don't Pass Me By (A Disgrace)


signature.asc
Description: Digital Signature

Bug#978098: webkit2gtk: Re-enable build for hurd-i386?

[Samuel Thibault]

Alberto Garcia, le ven. 08 janv. 2021 17:54:25 +0100, a ecrit:
> realpath(3) says that passing NULL to that function is
> implementation-defined in POSIX.1-2001, and only properly specified in
> POSIX.1-2008, so I would expect that you need to check for a different
> version.

Mmm, indeed.

“
Issue 7

This function is updated for passing a null pointer to realpath() for the 
resolved_name argument.
”

that's posix2008 only then.

so even if the interpretation


> Either way, is there any modern system that does not implement
> POSIX.1-2008?

That can be an argument indeed! Some people may not buy it, but less and
less so :)

> I also saw that Samuel already sent the changes to computeRAMSize()
> upstream, and that earlier someone added support for FreeBSD, so maybe
> we can enable replace 'linux-any hurd-any' by simply 'any'.

Possibly indeed.

Samuel

Bug#979549: ingerman: Problems during ispell-autobuild

[Roland Rosenfeld]

Hi Thorsten!

Thorsten G. schrieb am Freitag, den 08. Januar 2021:

> Package: ingerman
> Version: 20161207-8
> Severity: normal

> during dist-upgrade I've got the following messeges
> 
> ispell-autobuildhash: Processing 'ngerman' dict.
> /usr/lib/ispell/ngerman.aff line 157: No such string character
[...]
> /ur/lib/ispell/ngerman.aff line 462: Single characters must be
> separated by a blank
[...]
> Word 'Attach�' contains illegal characters
[...]

Thanks for your bug report, this is some regression of the update of
ispell from 3.4.00-8 to 3.4.01-1.
It breaks processing of the ispell affix files of igerman98 and
hkgerman.

See also https://bugs.debian.org/979575

Greetings
Roland


signature.asc
Description: PGP signature

Bug#979139: linphone-desktop: Icons not shown

[ael]

I have just returned to testing linphone (after getting twinkle to
work as well), and I have hit another problem.

I can make outgoing calls, but I cannot answer incoming calls. Could
that be another missing icon?

When I make an incoming test tool, linphone plays the ringtone, but 
I can't see any change in the GUI, nor any way to answer the call.

I have just posted a message to the linphone mailing list
linphone-us...@nongnu.org

Bug#979588: viking: Update or Mapnik 3.1.0

[Bas Couwenberg]

Source: viking
Version: 1.8-3
Severity: important
Tags: patch upstream
User: debian-...@lists.debian.org
Usertags: mapnik-3.1

Dear Maintainer,

Mapnik 3.1.0 has been released and uploaded to experimental.

Because of the minor version bump a changes to your package are required
per the attached patch once Mapnik 3.1 is available in unstable.

Kind Regards,

Bas
diff -Nru viking-1.8/debian/changelog viking-1.8/debian/changelog
--- viking-1.8/debian/changelog 2020-07-29 07:06:21.0 +0200
+++ viking-1.8/debian/changelog 2021-01-08 17:39:52.0 +0100
@@ -1,3 +1,10 @@
+viking (1.8-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Rebuild with Mapnik 3.1.0.
+
+ -- Bas Couwenberg   Fri, 08 Jan 2021 17:39:52 +0100
+
 viking (1.8-3) unstable; urgency=medium
 
   * [ab621503] Add build-with-gcc-10.patch: src/babel.h
diff -Nru viking-1.8/debian/patches/mapnik-3.1.patch 
viking-1.8/debian/patches/mapnik-3.1.patch
--- viking-1.8/debian/patches/mapnik-3.1.patch  1970-01-01 01:00:00.0 
+0100
+++ viking-1.8/debian/patches/mapnik-3.1.patch  2021-01-08 17:39:52.0 
+0100
@@ -0,0 +1,14 @@
+Description: Add support for Mapnik 3.1.
+Author: Bas Couwenberg 
+
+--- a/src/vikmapniklayer.c
 b/src/vikmapniklayer.c
+@@ -219,6 +219,8 @@ static VikLayerParamData plugins_default
+   if ( g_file_test ( "/usr/lib/mapnik/input", G_FILE_TEST_EXISTS ) )
+   data.s = g_strdup ( "/usr/lib/mapnik/input" );
+   // Current Debian locations
++  else if ( g_file_test ( "/usr/lib/mapnik/3.1/input", G_FILE_TEST_EXISTS 
) )
++  data.s = g_strdup ( "/usr/lib/mapnik/3.1/input" );
+   else if ( g_file_test ( "/usr/lib/mapnik/3.0/input", G_FILE_TEST_EXISTS 
) )
+   data.s = g_strdup ( "/usr/lib/mapnik/3.0/input" );
+   else if ( g_file_test ( "/usr/lib/mapnik/2.2/input", G_FILE_TEST_EXISTS 
) )
diff -Nru viking-1.8/debian/patches/series viking-1.8/debian/patches/series
--- viking-1.8/debian/patches/series2020-07-29 07:06:21.0 +0200
+++ viking-1.8/debian/patches/series2021-01-08 17:39:52.0 +0100
@@ -5,3 +5,4 @@
 geocluelayer.xml_not_included.patch
 fix_build_without_mapnik.patch
 build-with-gcc-10.patch
+mapnik-3.1.patch

Bug#979587: ITP: ts-jest -- Node.js preprocessor with source maps support to help use TypeScript with Jest

[Xavier Guimard]

Package: wnpp
Severity: wishlist
Owner: Xavier Guimard 
X-Debbugs-Cc: debian-de...@lists.debian.org, 
pkg-javascript-de...@lists.alioth.debian.org

* Package name: ts-jest
  Version : 26.4.4
  Upstream Author : Kulshekhar Kabra 
* URL : https://github.com/kulshekhar/ts-jest
* License : Expat
  Programming Lang: JavaScript
  Description : Node.js preprocessor with source maps support to help use 
TypeScript with Jest

Jest is a popular test framework for JavaScript projects. ts-jest
extends jest to test projects written in Typescript.

For now, some Debian packages keep untested due to the lack of this
package (for example, all node-dom* packages). It was not possible to
build ts-jest until now, due to lack of Jest typescript definitions
(fixed now).

ts-jest will be maintained under JS Team umbrella.

Bug#979175: fixed in zeromq3 4.3.3-5

[GCS]

On Fri, Jan 8, 2021 at 11:12 AM Laurent Bigonville  wrote:
> On Thu, 07 Jan 2021 20:35:39 + Debian FTP Masters
>  wrote:
>  > Source: zeromq3
>  > Source-Version: 4.3.3-5
> [...]
>  > - FTBFS on kFreeBSD (closes: #979175).
> [...]
>
> Unfortunately this was not enough to fix the FTBFS on kfreebsd:
> https://buildd.debian.org/status/fetch.php?pkg=zeromq3=kfreebsd-amd64=4.3.3-5=1610053267=0
 Yeah, noticed already. Luca, may you do a complete check and fix for
kFreeBSD builds?

Thanks,
Laszlo/GCS

Bug#979463: crash when run for remote DISPLAY

[gregor herrmann]

On Thu, 07 Jan 2021 00:40:02 +0100, Andreas Ronnquist wrote:

> Thanks for your report. In this case I believe the fact that you are
> running remote isn't a factor of the crash - the backtrace is identical
> to what some people report in a upstream report with activity recently.

FWIW, I see the same after upgrading libx11-6 from 2:1.6.12-1 to
2:1.7.0-1. Downgrading to the former version makes geeqie work again.

(Rebuilding the package doesn't help.) 

Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: The Eagles: Witchy woman


signature.asc
Description: Digital Signature

Bug#977628: orage: FTBFS: build-dependency not installable: xfce4-panel (= 4.14.4-1)

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Fri, 2021-01-08 at 14:10 +0200, Juhani Numminen wrote:
> Thank you Yves-Alexis for implementing this in orage/4.12.1-8.
> 
> I noticed that the removal request still stands (
> https://bugs.debian.org/977628 ).
> Do you still intend to remove orage from Debian or are you happy to keep it
> for now?

I don't really think it's sustainable if upstream is gone. I think it's better
if the “last state” doesn't FTBFS, but I don't think we can ship it in
Bullseye since the last upstream version is so old.

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl/4ktMACgkQ3rYcyPpX
RFsGmAgA0QIwFK+q4h59CKfUxtctOlb1fxmK3wT8795VeePesR/zAFZOqta8BeUI
nQ7W6/RoCSMvfkvVogjB8A2sFrT/lD6OlwlsI+AxzfAaNUcqbiMaixlutGobIojd
wOATph21h908/pmPv9OGGb4JC+/xOP7myw50TzU6DQs2j0hu7FzsoOA5iEjIpfMe
D6QAe5wYATyLL/E5VuEdgqKvejm7ja0TAZEVqMLzYw7myGBg13xiTsJ6SYxKGNRS
eL9i8QHorYDLPzy6c/1/+vl9K6XiChqh73VOzzYq4qjGqXm7/ez7iG9r0wu/Xs2l
isupbJDgsg+kZuJGWR9CEpn6LroCug==
=Nu2L
-END PGP SIGNATURE-

Bug#979533: chromium: New 87.0.4280.141

[Michel Le Bihan]

Hello,

I'm working on the update, but I encountered an unexpected issue. The
update was easy. Patches did not require updating. The problem, is that
Chromium IU is frozen. Chromium itself isn't and the globe on
https://en.wikipedia.org/wiki/GIF spins, but Chromium doesn't react to
any UI input. I'm debugging that, but haven't made much progress.

Michel Le Bihan

Bug#977779: geary FTBFS on mipsel: test suite failure

[Alberto Garcia]

On Mon, Dec 21, 2020 at 11:30:14PM +0200, Adrian Bunk wrote:
> > I see that the build eventually succeeded:
> > 
> >
> > https://buildd.debian.org/status/logs.php?pkg=geary=3.38.1-1=mipsel
> > 
> > The webkit2gtk build is flaky itself in mipsel, we discussed this
> > already in the past (#962616), I wonder if this is the same root
> > problem?
> 
> This is the same problem.
> 
> Note that the build is not and never was flaky, it does 100%
> determinisitically fail on Loongson buildds and succeed on Octeon
> buildds.
> 
> Jiaxun Yang discovered this weekend that CeilingOnPageSize is wrong
> for Loongson which has 16 kB pagesize and this matches when the
> problems started in 2.28.1, but unfortunately fixing this does not
> seem to fix all problems.

But this a bug in the CPU, right? Do I understand correctly that the
package can fail depending on what CPU it is run on regardless of how
it was built?

I'm trying to understand what we can do in WebKit in order to fix or
work around this.

Berto

Bug#979586: python-mapnik: Update or Mapnik 3.1.0

[Bas Couwenberg]

Source: python-mapnik
Version: 1:0.0~20200224-7da019cf9-2
Severity: important
Tags: patch

Dear Maintainer,

Mapnik 3.1.0 has been released and uploaded to experimental.

Because of the minor version bump a changes to your package are required
per the attached patch once Mapnik 3.1 is available in unstable.

Kind Regards,

Bas
diff -Nru python-mapnik-0.0~20200224-7da019cf9/debian/changelog 
python-mapnik-0.0~20200224-7da019cf9/debian/changelog
--- python-mapnik-0.0~20200224-7da019cf9/debian/changelog   2020-06-04 
06:27:12.0 +0200
+++ python-mapnik-0.0~20200224-7da019cf9/debian/changelog   2021-01-08 
17:37:48.0 +0100
@@ -1,3 +1,9 @@
+python-mapnik (1:0.0~20200224-7da019cf9-3) UNRELEASED; urgency=medium
+
+  * Rebuild with Mapnik 3.1.0.
+
+ -- Bas Couwenberg   Fri, 08 Jan 2021 17:37:48 +0100
+
 python-mapnik (1:0.0~20200224-7da019cf9-2) unstable; urgency=medium
 
   * Bump debhelper compat to 10, changes:
diff -Nru python-mapnik-0.0~20200224-7da019cf9/debian/rules 
python-mapnik-0.0~20200224-7da019cf9/debian/rules
--- python-mapnik-0.0~20200224-7da019cf9/debian/rules   2020-06-04 
06:26:52.0 +0200
+++ python-mapnik-0.0~20200224-7da019cf9/debian/rules   2021-01-08 
17:37:13.0 +0100
@@ -16,7 +16,7 @@
 export SYSTEM_FONTS=/usr/share/fonts
 
 # Custom mapnik libraries
-export LIB_DIR_NAME=/mapnik/3.0
+export LIB_DIR_NAME=/mapnik/3.1
 
 %:
dh $@ \

Bug#979582: nageru: please drop the Build-Depends on libsrt-gnutls-dev which is RC-buggy

[Steinar H. Gunderson]

On Fri, Jan 08, 2021 at 05:36:58PM +0100, Paul Gevers wrote:
> The srt source package is RC buggy and has just been orphaned. We'll
> probably remove it soon from bullseye. nageru will go too then, unless
> it drop the (apparent optional) Build-Depends.

That's sad to hear. I'll drop the B-D in an upcoming upload; thanks for the
heads-up.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#978098: webkit2gtk: Re-enable build for hurd-i386?

[Alberto Garcia]

On Mon, Dec 28, 2020 at 09:01:21PM +0100, Samuel Thibault wrote:

> > Shouldn't the patch be applied in "official" package as well (and
> > maybe upstream)?
> 
> Debian maintainers usually prefer to see patches applied upstream
> before adding them to their packaging. They are already submitted
> upstream, see URLs in the patch file. Some of them are already
> applied, others need some rework, help welcome!
> 
> And they usually rather see a complete working set before changing
> debian/

Hi Laurent and Samuel,

I'm generally happy to make my packages work in as many architectures
as possible, and that includes the non-Linux ports.

WebKit is however a bit special because of its size, complexity and
fast development pace. We often find problems with architectures other
than the "main" ones (intel, arm) and it sometimes takes a while to
figure out what's going on. It's even harder with the Hurd or kFreeBSD
ports. Because of that I decided to stop building WebKit packages for
those systems some time ago.

However if someone has patches and can verify that the package builds
and works fine with them I'm happy to include them.

I had a quick look at this patch in particular and it seems that at
least parts of it could go upstream just fine, and I can try to help
wit that if you want. I'm happy to generally reduce or remove the
dependency on PATH_MAX in WebKit.

I have a question that maybe you can answer:

> ++#if _POSIX_VERSION >= 200112
> ++char *normalizedPath;
> ++normalizedPath =
> realpath(FileSystem::fileSystemRepresentation(filePath).data(),
> NULL);
> ++if (!normalizedPath)
> ++continue;
> ++
> ++filePath =
> FileSystem::stringFromFileSystemRepresentation(normalizedPath);
> ++free(normalizedPath);
> ++#else

I'm not familiar with the _POSIX_VERSION macro, but realpath(3) says
that passing NULL to that function is implementation-defined in
POSIX.1-2001, and only properly specified in POSIX.1-2008, so I would
expect that you need to check for a different version.

Either way, is there any modern system that does not implement
POSIX.1-2008?

   -

I also saw that Samuel already sent the changes to computeRAMSize()
upstream, and that earlier someone added support for FreeBSD, so maybe
we can enable replace 'linux-any hurd-any' by simply 'any'.

Regards,

Berto

Bug#979577: qtcreator: Clang Code Model no longer finds 'stddef.h' since version 4.14.0-2

[Michael Weghorn]

Thanks for the quick reply!

On 08/01/2021 17.28, Pino Toscano wrote:

qtcreator 4.14.0-2 has been available in unstable (which you use) for
more than two weeks, so reading this problem now seems slightly
awkward. Have you used qtcreator 4.14.0-2 (and it code model)
successfully so far in the past two weeks?


I'm usually using testing (and use unstable for double-checking before 
reporting bugs) and haven't really used qtcreator since Christmas as far 
as I can remember. (The package migrated to testing on 2020-12-28.)




My suspect is the upload of llvm-toolchain-11 done yesterday, and your
package list:

ii  libclang1-11   1:11.0.1-2

show you updated to it.
Can you please try to backport your LLVM/Clang 11 packages to the same
version used to build qtcreator? You can get the list of installed
packages using:
$ dpkg -l '*llvm*11*' | grep ^ii
$ dpkg -l '*clang*11*' | grep ^ii
and then use the `debsnap` tool, part of the devscripts package, to
download them, e.g.:
$ debsnap -d . -a amd64 libclang-11 1:11.0.1~+rc2-1
(you will need to repeat that for all the packages you have installed,
removing the :amd64 suffix in the packages that have multi-arch
annotations).


The issue is still reproducible after downgrading the LLVM/Clang 
packages this way.


It disappears when downgrading qtcreator and qtcreator-data to 4.14.0-1, 
though.


Michael

Bug#979585: libapache2-mod-tile: Update or Mapnik 3.1.0

[Bas Couwenberg]

Source: libapache2-mod-tile
Version: 0.5-1
Severity: important
Tags: patch

Dear Maintainer,

Mapnik 3.1.0 has been released and uploaded to experimental.

Because of the minor version bump a changes to your package are required
per the attached patch once Mapnik 3.1 is available in unstable.

Kind Regards,

Bas
diff -Nru libapache2-mod-tile-0.5/debian/changelog 
libapache2-mod-tile-0.5/debian/changelog
--- libapache2-mod-tile-0.5/debian/changelog2020-10-23 18:10:08.0 
+0200
+++ libapache2-mod-tile-0.5/debian/changelog2021-01-08 17:34:57.0 
+0100
@@ -1,3 +1,10 @@
+libapache2-mod-tile (0.5-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Rebuild with Mapnik 3.1.0.
+
+ -- Bas Couwenberg   Fri, 08 Jan 2021 17:34:57 +0100
+
 libapache2-mod-tile (0.5-1) unstable; urgency=medium
 
   * Use systemd-tmpfiles.
diff -Nru libapache2-mod-tile-0.5/debian/etc/renderd/renderd.conf 
libapache2-mod-tile-0.5/debian/etc/renderd/renderd.conf
--- libapache2-mod-tile-0.5/debian/etc/renderd/renderd.conf 2020-09-24 
18:23:20.0 +0200
+++ libapache2-mod-tile-0.5/debian/etc/renderd/renderd.conf 2021-01-08 
17:34:57.0 +0100
@@ -5,6 +5,6 @@
 tile_dir=/var/cache/renderd/tiles
 
 [mapnik]
-plugins_dir=/usr/lib/mapnik/3.0/input
+plugins_dir=/usr/lib/mapnik/3.1/input
 font_dir=/usr/share/fonts/truetype
 font_dir_recurse=true

Bug#978146: geary: Geary segfaults on startup after upgrade to 3.38.1-1

[debian]

Severity: important

Changing the severity to important as it turns out that a workaround 
exists (ie: remove the user's geary config).


Also, since Geary does not support POP accounts, I don't believe any 
data loss would happen (one just need to resync their imap emails).


Given those info, this bug doesn't qualify for severity grave imho.

Best regards,

Henry-Nicolas Tourneur

Bug#979584: New upstream release (fix uscan)

[Bastian Germann]

Source: lvm2
Version: lvm2/2.03.10-1
Tags: patch

The new version 2.03.11 is available. uscan currently fails for lvm2 
because it scans a password-protected FTP archive. A fix is enclosed.


Please import the new version and have a look at #966152 which can be 
closed easily with the new version.
From: Bastian Germann 
Date: Fri, 8 Jan 2021 17:35:18 +0100
Subject: Fix uscan files

The d/watch file has an old FTP location which is password protected now.
Use the new official FTP archive to obtain the source.

The releases are now signed by Marian Csontos.
Replace the public verification key.
---
 debian/upstream/signing-key.asc | 65 -
 debian/watch|  4 +-
 2 files changed, 41 insertions(+), 28 deletions(-)

diff --git a/debian/upstream/signing-key.asc b/debian/upstream/signing-key.asc
index 718e44321..5ccca4105 100644
--- a/debian/upstream/signing-key.asc
+++ b/debian/upstream/signing-key.asc
@@ -1,29 +1,42 @@
 -BEGIN PGP PUBLIC KEY BLOCK-
 
-mQGiBEAeeEERBADMj5KARh++lgyn6haaj0v28aSV6NEFPhOGNumJQ8buB5UmFX/V
-oHlkLf07d/1F01P/5z+ad9ujJxxNWIOVA6B+K1zjI0wUd2T5iCu/JRacLBYG0B1+
-oceGiPhvLkHZlNuLZAeAFCthKfRpSFWEYE5DnNsHupVaHBMJhxE1b9G09wCg/01M
-IY3p0V94YFvuOSyjbDEn2oMD/2kZz3t2WLYyUCB8BMg6JCyIXVAfCpTuZXVZipEe
-/vdHPtTfqtwcK2Fm/wndKbty/wMm1szyxGy4yXNykLc3Ly5uIaoJcKZcfkdiuIXX
-If55wS0EIhrBykZHqFhuP8fK63zl7SdWjE1c4YibeIuCWFTlZcPS+M/RKmvp3dMP
-rWZ0BADLsxd8F9YwuD+6OuJU/haRh61fZoTRtDjhH+N92Ibz1FwRKqZnZ5EWwLtT
-25BqlXvIYG3Zxg57Cuz5CKugDGo/xEr2XwXqRAdG8hh4FcrhbvBnsKLo/JpacjH/
-zYgZ5zyGoN12hu+Wwjxgq7E+K7YIW9l6gz8JvM6Q3gp8ZYZ4a7QiQWxhc2RhaXIg
-RyBLZXJnb24gPGFna0ByZWRoYXQuY29tPohfBBMRAgAXBQJAHnhBBQsHCgMEAxUD
-AgMWAgECF4AAEgkQIoGRwVZ+LBcHZUdQRwABAW9NAKC0E3fUI/bGv2P0dpQorPth
-8svSGgCeMPdrGxUunkY/E3Lx68VRkh+Ycai5Ag0EQB54VBAIAIyZDGgSWVTmbPFV
-2h85qxBbZpnc8PSycv8heg3qiZv2ZdDtQOA+ocyecT+SwzNBIF1kBPvBSglz6lLt
-4QM7/RUQi8IHTrvEakL+RUVJHjic+RzWNOgHbeZEX5Ksoe2sSRLpu30xa7pa+SYa
-uvDfh1KlsrLSwV+xYDZnlIVRlwaoBKZ0HvPZXGfQ+FpF3w3K4jPiJWuRpzyKk/e3
-6jpj4StKtrDOx9JVGJ00EC+KDTI41wMirLXdD5UfaQ0HBnDvdFg72gEpvjNg+D1d
-Kl0YJrXCRleuhgVHxuivTnD6rp3luYqleKVfnfgIVBfwTtP2g/CJ9U4Z9aQl5cHn
-1BM12VcAAwUIAIbfpkIZLwhy0MRmD1wDpeVeFy2Wt7r+wfrxXGF48qXxE9QELkSl
-vyDgpi8h9aozMnPDwHIlFerdtZnYi4soa7TJxMWgZFL44vNdz4vrzNFTAki1YpAl
-PZYrILoeV4Kr1MzUb+w/IuQVrbSg8AqaQpEkYV6Whecuoih/+p/56+vDIO1u80/T
-kcWml+F5y9z0F3XN0Byictu7VXLFiBFBZalWJg5eyaUuCasv8OHb9+/zFTHMjkjH
-Jju0RuVni0xuST743iuIvq39TgS7rahimNP1CW7GUz8bnFjYbevF2j5n4W6NGT7B
-bslKXSoCNpciYqYGkEYmGxVuzPNtc8+f8fWITgQYEQIABgUCQB54VAASCRAigZHB
-Vn4sFwdlR1BHAAEBb9sAoIVRdEtRyRiJkwIca4RahS2Gqo47AJ9j8kaGMhq/z2rL
-Qqp/t/dyu3xG1Q==
-=LnLx
+mQINBFsYvw8BEAD9MZoZVcmZ38YKbpfkzeOAnnegWtUl6GapKGwLQ/yOHGJd/P9s
+5hl8czimwe1z8q0K/YGRAynxOW84d8XwNGMOlowza52J9l8prNwjMSHytpHSms2C
+9IWV5nuSld1YzH1bLzCWVZX7ejFgZHRU0/WLQU7k6LZ+8886jOW1q6Bkgdk3/rfA
+EcOesh68uuBYoKd3s/6jNu/3k4cKICdueOV/zT393nmwvM8OjNQwO9Q8k9up+ac/
+jLvbXLQRKWkiekrRDoOFDsZZjRdvh+Lkxwq6fkrK3YOaZcbe7mteN3WUIYiryI4m
+EmVRTtSMb+43JYTFGNPdJk+KI24s01Vhf6s0w37tWCxSBnfQP0+ZHLIf0IjdV9I4
+5pGfMm1hONfOHuzMdNOUYq/lM6dgpdfyTSzWNdNdaaB0SD5tT8lJCHayn0fZmWuR
+7NFUIRepTuBb2wtfMwVeOI9Eq7gVbL53TIsHVSWnsEAxvMkNHQ68vp9JRSqBntyd
+bjyCMTwdN8Qqx8n15kE4DABdJczimnbEQLQHN4DJcyG28pPPscnAO8hYCn4t+4jS
+YEDZ/7wsIxovyK6VfaKz97dsGl3FUdJBPMG7LBLoDp3JZ2Z7Zd5vo2qa8roVNQTt
+Qog90g6sQz1jWTkBRal5mDDqMgnJndeKBBtomHbl5Rl6E8bH1EcrQCHGYQARAQAB
+tClNYXJpYW4gQ3NvbnRvcyA8bWFyaWFuLmNzb250b3NAZ21haWwuY29tPokCVAQT
+AQgAPhYhBNUBpHhECuL9Ewob6LkRJDHlCQOfBQJbGL8PAhsDBQkDwmcABQsJCAcC
+BhUKCQgLAgQWAgMBAh4BAheAAAoJELkRJDHlCQOfwQgQAOKbrW5pRqNtV4hKU0sk
+PvYY/+oNLZ5BBTFzAXxz3eXyp1Alt7g4WWApk0Vp+ZDwJ0SHESdCxKud2fSczQBF
+6KpR6hB7N7b9wcr3UbHwei8vFFP4vTORDd5APso7liFZ1NUcXDAMUnSeAB15UqKU
+MGxMrmGMj+YemFzD1eulF1f73h1bDbQkpl7IslgZy0sAUUpdVW1Oab+W0CZbKtGe
+OWCi37SzlbiYqb5F2AlZHJrQTC+PNrtOWO3EtTHn2tGEN1zjpYwMR/UFocdQfeG2
+qYtT7nu8IT5GVyJUfODKrknYuTJspC7hM8qu7YwY234nC0SpkWLxixT52r6tUgiW
+qvPDZpuLZCfuNI40jeGwtETsml4G2rk6lsQcOUONWzA+Q4UqX4lhsfTIEGRH92Gf
+YYktu0aR2ccxN73DNC98+ug9a5bK60aKeYRjwWZZmXda1hKhYTdUE5x/TNdXoRX6
+uX62t/nOzQw+92JTn8np8Ld6wPhvg9QWPRx0l31Oo9b8uVm56wOwLhnoJGRvSPQ7
+HkXwp5r0FY3u2FHma6aVFkTiObb6h+WNf4DSLeouxw1yl8q+LIYwpMCENXMcVFDP
+QU93WdGi1IjXgGeXE7FirBW9fGuaae3b8pFC3f4DXiyXvRYogbIhLKiSvdOFJK23
+61YMI26W9pbZqXQq+1uXECK8tCRNYXJpYW4gQ3NvbnRvcyA8bWNzb250b3NAcmVk
+aGF0LmNvbT6JAlQEEwEIAD4WIQTVAaR4RAri/RMKG+i5ESQx5QkDnwUCWxi/oQIb
+AwUJA8JnAAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRC5ESQx5QkDn6IyD/9u
+mvMSIv24d8ojEdOLb47wcu6dP93kpTsUeAktLlimXves/5VJlLkQOykMKFCo9/0c
+HdGs0pPLltjxqSw6MJ3RV4Edntsg+XWgMf/I/yvzi/IZh+5QIplur1EavbmQbnq0
+h/ap1IvIyXmDLRNCrdwHxdbEA6JzP6Zv3ZpfYyRaIQCRANIMYKgFjXMI9EiFA/RR
+irs+MGqr8qbWpWUEftn/ExeardG6wPGssXuAQwFkJCznLrM3cSl6fPhxVfN3q5KW
+UQzo+RPSLT2rcF+M5GpIjPOUfpSjIhBVEw2UCkq4ivPFfwJmaexd38ywgwyejXrk
+7+H3xpinABEIYM/8IpwfMWcPwmA2WQXmmClxoxmnBUc6Vz8a+3XWlv1Q3Y6Dsbud
+zQVLJb+HXvm2mP7HVuLbEs2BO4uXHk9eitWzXdWexFmRiCZWeYxFiKQzGfF9fAQs
+wXuIYAMh1AYUfJ6MP8980yazxiH1NEV23o52MDPLH84EvgdPrerEanbAix6G6dT9

Bug#977256: ITP: liquidctl -- Cross-platform CLI and Python drivers for AIO liquid coolers and other devices

[GCS]

Control: owner -1 !
Control: retitle -1 ITP: liquidctl -- Cross-platform CLI and Python
drivers for AIO liquid coolers and other devices

Packaged and going to upload it soon.

Bug#979583: golang-github-spf13-cobra: autopkgtest regression in testing: date of execution is capture in comparison

[Paul Gevers]

Source: golang-github-spf13-cobra
Version: 1.1.1-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With time moving the year to 2021, the autopkgtest of your package
started to fail. I copied some of the output at the bottom of this
report. Can you please investigate the situation and fix it?

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

Paul

https://ci.debian.net/data/autopkgtest/testing/amd64/g/golang-github-spf13-cobra/9459756/log.gz

=== RUN   TestGoldenAddCmd
add_test.go:26:
"/tmp/autopkgtest-lxc.0dv6r0gd/downtmp/autopkgtest_tmp/obj-x86_64-linux-gnu/src/github.com/spf13/cobra/cobra/cmd/testproject/cmd/test.go"
and "testdata/test.go.golden" are not equal!

$ diff -u
/tmp/autopkgtest-lxc.0dv6r0gd/downtmp/autopkgtest_tmp/obj-x86_64-linux-gnu/src/github.com/spf13/cobra/cobra/cmd/testproject/cmd/test.go
testdata/test.go.golden
---
/tmp/autopkgtest-lxc.0dv6r0gd/downtmp/autopkgtest_tmp/obj-x86_64-linux-gnu/src/github.com/spf13/cobra/cobra/cmd/testproject/cmd/test.go
2021-01-06 19:13:34.418670146 +
+++ testdata/test.go.golden 2020-10-24 09:28:37.0 +
@@ -1,5 +1,5 @@
 /*
-Copyright © 2021 NAME HERE 
+Copyright © 2020 NAME HERE 

 Licensed under the Apache License, Version 2.0 (the "License");
 you may not use this file except in compliance with the License.

exit status 1
--- FAIL: TestGoldenAddCmd (0.00s)



OpenPGP_signature
Description: OpenPGP digital signature