Bug#977999: libcifpp: reproducible builds: Embeds build time in libcifpp.so.1.0.0

[Vagrant Cascadian]

Source: libcifpp
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps 
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The build time is embedded in /usr/lib/arm-linux-gnueabihf/libcifpp.so.1.0.0:

  
https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/armhf/diffoscope-results/libcifpp.html

  Date: 2020-12-22
  vs.
  Date: 2020-12-24


The attached patch fixes this by adjusting the date command in
GNUmakefile.in to use SOURCE_DATE_EPOCH for the timestamp.


Thanks for maintaining libcifpp!


live well,
  vagrant
From d6022f4c631e73daa597a47faa751c3b651d5437 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Thu, 24 Dec 2020 07:44:51 +
Subject: [PATCH] revision.hpp: Patch to use SOURCE_DATE_EPOCH.

https://reproducible-builds.org/docs/source-date-epoch/
---
 GNUmakefile.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/GNUmakefile.in b/GNUmakefile.in
index 08a29fb..1d9526c 100644
--- a/GNUmakefile.in
+++ b/GNUmakefile.in
@@ -162,7 +162,7 @@ else
 src/revision.hpp:
 	@ echo 'const char kRevision[] = R"(' > $@
 	@ echo libcifpp-version: $(VERSION) >> $@
-	@ echo Date:   $$(date --iso-8601) >> $@
+	@ echo Date:   $$(date --utc --date=@$(SOURCE_DATE_EPOCH) --iso-8601) >> $@
 	@ echo ')";' >> $@
 
 endif
-- 
2.30.0.rc1



signature.asc
Description: PGP signature

Bug#977998: RFS: opensurge/0.5.1.2-1 [ITP] -- Fun 2D retro platformer inspired by Sonic games

[Carlos Donizete Froes]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: opensurge
   Version : 0.5.1.2-1
   Upstream Author : Alexandre Martins 
 * URL : https://opensurge2d.org
 * License : GPL-3+
 * Vcs : https://salsa.debian.org/games-team/opensurge
   Section : games

It builds those binary packages:

  opensurge - Fun 2D retro platformer inspired by Sonic games

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/o/opensurge/opensurge_0.5.1.2-1.dsc

Changes for the initial release:

 opensurge (0.5.1.2-1) unstable; urgency=medium
 .
   * Initial release (Closes: #943676)

Regards,
-- 
  Carlos Donizete Froes [a.k.a coringao]

Bug#977978: libdatetime-timezone-perl 2.23-1+2020e flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 977978 = buster pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: libdatetime-timezone-perl
Version: 2.23-1+2020e

Explanation: update for new tzdata version

Bug#794410: Still encounters this bug when installing buster

[Dashi Cao]

An unattended installation of Debian 10.6 through preseeding still
hangs at "Select and Install Software". Alt+F4 displays dpkg-divert ...

Dashi Cao

Bug#972149: buster-pu: package net-snmp/5.7.3+dfsg-5+deb10u1

[Salvatore Bonaccorso]

Hi Craig,

On Sun, Nov 22, 2020 at 07:09:29PM +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Tue, 2020-10-13 at 21:30 +1100, Craig Small wrote:
> > The security release in deb10u1 made EXTEND-MIB read-only
> > to close a security hole (CVE-2020-15862/Bug #9651166)
> > However this meant the cacheTime and execType could not be
> > changed which caused problems with some SNMP managers or setups.
> > 
> > [ Impact ]
> > The cachetime and execType cannot be set anywhere as these
> > parameters appear in net-snmp 5.8 which is in sid but not
> > buster.
> 
> +net-snmp (5.7.3+dfsg-5+deb10u2) buster-security; urgency=high
> 
> The distribution wants to simply be "buster" for a stable upload.
> 
> +  * snmpd: Add cacheTime and execType flags to EXTEND-MIB.
> +Previous security release made EXTEND-MIB read-only which meant
> +it was not possible to set the timeout of the cache. This patch
> +allows administrator to set the value in the snmpd.conf file.
> 
> s/administrator// (or "the administrator", I guess).
> 
> Bearing the above in mind, please go ahead.

Did you saw this ack from Adam to upload it for buster-pu?

Regards,
Salvatore

Bug#977995: dislocker: only recommend ruby, is only used to run dislocker-find

[Simon Heimberg]

Package: dislocker
Version: 0.7.1-4+b1
Severity: wishlist

Dear Maintainer,

please only recommend the dependency on ruby. The main parts of dislocker work
without it. Mentioning that ruby is used for dislocker-find in the package
description would be a plus of course.

In Readme of the project is written, that ruby is only needed to run dislocker-
find (https://github.com/Aorimn/dislocker#note).
So I created a dummy package for ruby (with equivs) and installed dislocker
without ruby.
It works as expected, only dislocker-find fails.

Details what works (and what I have checked):
The binary dislocker (which is dislocker-fuse) does work (the partition is
mounted and can be read). dislocker-find fails reporting /usr/bin/env "ruby"
could not be found. The other binaries show help, so they seem to work.

Kind Regards,
Simon Heimberg



-- 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)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8),
LANGUAGE=de_CH:de (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dislocker depends on:
ii  libc6  2.28-10
ii  libdislocker0.70.7.1-4+b1
ii  libfuse2   2.9.9-1+deb10u1
ii  libmbedcrypto3 2.16.0-1
ii  ruby-dummy [ruby]  0.1

dislocker recommends no packages.

dislocker suggests no packages.

Bug#975372: minidlna: "rm: cannot remove '/var/log/minidlna': Is a directory" on purge

[Salvatore Bonaccorso]

Hi Alexander,

On Tue, Dec 22, 2020 at 07:57:15PM +0300, Alexander Gerasiov wrote:
> On Sun, 20 Dec 2020 11:50:42 +0200
> Adrian Bunk  wrote:
> > this is a regression in 1.2.1+dfsg-2 that is currently in both 
> > buster-security (which was done on top of 1.2.1+dfsg-2 that
> > introduced the regression, not on top of 1.2.1+dfsg-1 in buster) and
> > in unstable/testing (which currently misses the CVE fixes).
> > 
> > It would be good if you could make an upload to unstable with this
> > bug fixed on top of 1.2.1+dfsg-2+deb10u1, and then backport that
> > change to buster.
> > 
> > Please coordinate with the security team whether this would warrant a 
> > regression update to the DSA or should be done through the next point 
> > release.
> 
> Hi, Team.
> 
> Does anyone mind against uploading fix to stable-proposed-update?
> The fix is here:
> https://salsa.debian.org/debian/minidlna/-/commits/buster-security/
> Or should it go to buster-security?

Fixing it via buster-proposed-updates in the next point release works.

As regression from the last DSA, given we all have not spotted it was
based on the testing version, I think we can as well release it via a
regression update via buster-security.

This will be only an issue if someone decides to purge the package in
stable.

The other issue: As the update was based on -2 rather than -1 it
contains several more (packaging) changes as well and wonder if
current stable users might have any issue with those (I suspect not
because systemd service addition is probably ok, the move of
logdiretory might be though suprising in a stable update and the fix
for #941410 is probably just a benefit).

Do you anticipate any problems which would arise from this that we did
release it on top of the "wrong" version?

Regards,
Salvatore

Bug#974779: [Pkg-julia-devel] Bug#974779: severity - Julia: Please upgrade to llvm-toolchain-11

[Norbert Preining]

> Either you go back to -9 or move to -11

I will try to go to -9

Norbert

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

Bug#976788: 5.9.0-5-amd64 also affected

[proctor]

just got the 5.9.0-5-amd64 kernel and tested -- it is also susceptible and
can be triggered by the method described in my earlier email/post.


-- 
.this message has been rot26 encrypted for security reasons.
gpg 0x385E2954CE572CADE8C091C09479B105A6770473

Bug#969372: INFO: Bug#969372: uwsgi-emperor: SysV init script does nothing

[Sam]

Thanks Houben, I appreciate your efforts!

Sam

Quoting Rens Houben (2020-12-22 16:07:00)
> Hello,
> 
> I've come across the same bug while trying to set up a new service at work.
> 
> After some digging (we've currently got a mishmash of Jessie and Buster
> systems, not all of them have been upgraded yet) I discovered that the init
> script, such as it is, is identical in all versions, and it is not actually 
> the
> problem.
> 
> Running the init script manually gave the following output:
> 
> rhouben@networking-lab-rh:/var/log/uwsgi$ sudo  /etc/init.d/uwsgi-emperor 
> start
> [ ok ] Starting uwsgi-emperor (via systemctl): uwsgi-emperor.service.
> 
> 
> ... Whereas on a system still running Jessie I got:
> shadur@radius-srv-dc25:~$ sudo /etc/init.d/uwsgi-emperor restart
> [] Restarting uWSGI Emperor server: uwsgi[uWSGI] getting INI configuration
> from /etc/uwsgi-emperor/emperor.ini
> setting capability setgid [6]
> setting capability setuid [7]
> . ok
> 
> 
> The issue arose because the init script isn't so much a script as it's a set 
> of
> variables plugged into the init.d helper scripts, and /those/ have changed
> drastically from Jessie to Buster and onwards to call systemctl -- but in
> uwsgi-emperor's case there doesn't appear to /be/ a systemd service file to
> call on, so it quietly fails and does nothing at all.
> 
> I'm currently writing at least a rudimentary systemd service file for
> uwsgi-emperor to see if that makes it work; I can share it once I finish if
> you'd like.
> 
> --Rens Houben.
> 
> 
> 
> SYSTEMEC BV
> 
> Marinus Dammeweg 25, 5928 PW Venlo
> Postbus 3290, 5902 RG Venlo
> Industrienummer: 6817
> Nederland
> 
> T: 077-3967572 (Support)
> K.V.K. nummer: 12027782 (Venlo)
> 
> Neem een kijkje op onze vernieuwde website
> 
> Systemec Datacenter Venlo, Nettetal en Düsseldorf
> 
> ISO/IEC 27001:2017 gecertificeerd door
> Digitrust, registratienummer DGT2020092101
> NEN 7510-01:2017 gecertificeerd door
> Digitrust, registratienummer DGTN2020092101
> 
> Systemec Helpdesk  Helpdesk
> 
> Aanmelden nieuwsbrief  Aanmelden nieuwsbrief
> 
> Volg ons op: Systemec Twitter Systemec Facebook Systemec Linkedin Systemec
> Youtube
> 


signature.asc
Description: signature

Bug#977996: xserver-xorg-input-libinput: for the middle button, reports press only when the button is released

[Vincent Lefevre]

Package: xserver-xorg-input-libinput
Version: 0.30.0-1
Severity: normal

On my HP ZBook 15 G2 laptop, I have a pointstick with associated
mouse buttons and a touchpad with associated mouse buttons. There
is no issue with the touchpad buttons, but for the middle button
associated with the pointstick, I get the press event only when
the button is released, as shown by xev, for instance:

ButtonPress event, serial 33, synthetic NO, window 0x621,
root 0x2ec, subw 0x0, time 484856111, (73,106), root:(3030,1381),
state 0x0, button 2, same_screen YES

ButtonRelease event, serial 33, synthetic NO, window 0x621,
root 0x2ec, subw 0x0, time 484856111, (73,106), root:(3030,1381),
state 0x200, button 2, same_screen YES

You can see that I got both events at the same time. A consequence
is that under fvwm, popups bound to the middle button do not work
at all when I use the middle button associated with the pointstick.

Some details...

With the input-events utility, I get:

* For the pointstick (associated with /dev/input/event2):

# input-events 2
/dev/input/event2
   bustype : BUS_I8042
   vendor  : 0x2
   product : 0x1
   version : 0
   name: "PS/2 Generic Mouse"
   phys: "isa0060/serio2/input0"
   bits ev : (null) (null) (null)

* For the touchpad (associated with /dev/input/event3):

# input-events 3
/dev/input/event3
   bustype : BUS_I8042
   vendor  : 0x2
   product : 0x7
   version : 433
   name: "SynPS/2 Synaptics TouchPad"
   phys: "isa0060/serio3/input0"
   bits ev : (null) (null) (null)

In both cases, when I test the 3 buttons, the "pressed" and "released"
events are reported exactly at the time I press or release the button.
In particular, with the middle button of the pointstick:

03:39:35.613850: (null) ??? (0x112) pressed
03:39:35.613850: (null) code=0 value=0
03:39:36.941501: (null) ??? (0x112) released
03:39:36.941501: (null) code=0 value=0

So, no problems at this level. I get the issue only under X.

Note that these input devices do not use the same driver, so that
I suppose that the issue comes from the driver. /var/log/Xorg.0.log
contains in particular:

[...]
[21.243] (II) config/udev: Adding input device PS/2 Generic Mouse 
(/dev/input/event2)
[21.243] (**) PS/2 Generic Mouse: Applying InputClass "evdev pointer 
catchall"
[21.243] (**) PS/2 Generic Mouse: Applying InputClass "libinput pointer 
catchall"
[21.243] (II) Using input driver 'libinput' for 'PS/2 Generic Mouse'
[21.243] (**) PS/2 Generic Mouse: always reports core events
[21.243] (**) Option "Device" "/dev/input/event2"
[21.243] (**) Option "_source" "server/udev"
[21.244] (II) event2  - PS/2 Generic Mouse: is tagged by udev as: Mouse
[21.244] (II) event2  - PS/2 Generic Mouse: device is a pointer
[21.245] (II) event2  - PS/2 Generic Mouse: device removed
[21.316] (**) Option "config_info" 
"udev:/sys/devices/platform/i8042/serio2/input/input7/event2"
[21.316] (II) XINPUT: Adding extended input device "PS/2 Generic Mouse" 
(type: MOUSE, id 11)
[21.316] (**) Option "AccelerationScheme" "none"
[21.316] (**) PS/2 Generic Mouse: (accel) selected scheme none/0
[21.316] (**) PS/2 Generic Mouse: (accel) acceleration factor: 2.000
[21.316] (**) PS/2 Generic Mouse: (accel) acceleration threshold: 4
[21.317] (II) event2  - PS/2 Generic Mouse: is tagged by udev as: Mouse
[21.317] (II) event2  - PS/2 Generic Mouse: device is a pointer
[21.318] (II) config/udev: Adding input device PS/2 Generic Mouse 
(/dev/input/mouse0)
[21.318] (II) No input driver specified, ignoring this device.
[21.318] (II) This device may have been added with another device file.
[21.318] (II) config/udev: Adding input device SynPS/2 Synaptics TouchPad 
(/dev/input/event3)
[21.318] (**) SynPS/2 Synaptics TouchPad: Applying InputClass "evdev 
touchpad catchall"
[21.318] (**) SynPS/2 Synaptics TouchPad: Applying InputClass "libinput 
touchpad catchall"
[21.318] (**) SynPS/2 Synaptics TouchPad: Applying InputClass "touchpad 
catchall"
[21.318] (**) SynPS/2 Synaptics TouchPad: Applying InputClass "Default 
clickpad buttons"
[21.318] (**) SynPS/2 Synaptics TouchPad: Applying InputClass "touchpad"
[21.318] (II) LoadModule: "synaptics"
[21.319] (II) Loading /usr/lib/xorg/modules/input/synaptics_drv.so
[21.320] (II) Module synaptics: vendor="X.Org Foundation"
[21.320]compiled for 1.20.8, module version = 1.9.1
[21.320]Module class: X.Org XInput Driver
[21.320]ABI class: X.Org XInput driver, version 24.1
[21.320] (II) Using input driver 'synaptics' for 'SynPS/2 Synaptics 
TouchPad'
[21.320] (**) SynPS/2 Synaptics TouchPad: always reports core events
[21.320] (**) Option "Device" "/dev/input/event3"
[21.388] (--) synaptics: SynPS/2 Synaptics TouchPad: x-axis range 1324 - 
5660 (res 42)
[21.388] (--) synaptics: SynPS/2 Synaptics TouchPad: y-axis range 1248 - 
4730 (res 63)
[

Bug#961283: libhttp-tiny-perl: Don't release with bullseye

[gregor herrmann]

On Fri, 18 Dec 2020 19:43:40 +0100, Paul Gevers wrote:

> On 18-12-2020 16:47, Dominic Hargreaves wrote:
> > It sounds like we should file a bug with the release team for
> > manual removal from testing instead in this case? What makes the package
> > "key" OOI? The package is provided by perl so removal from testing
> > should be safe.
> I already added the hint yesterday, so the package is gone.

Thank you!
 
> For key packages and their reason:
> https://udd.debian.org/cgi-bin/key_packages.yaml.cgi
> 
> In this case: popcon of devscripts
> devscripts build-depends libgitlab-api-v4-perl
> libgitlab-api-v4-perl depends libhttp-tiny-perl

So this looks like a potential for improvement for the tooling to
detect "key packages", namely to take Provides into account.

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: Cat Stevens: Morning has Broken


signature.asc
Description: Digital Signature

Bug#977984: cron.d and cron.daily jobs may run in parallel and conflict

[Ben Hutchings]

On Wed, 2020-12-23 at 23:43 +0100, Bill Allombert wrote:
> On Wed, Dec 23, 2020 at 09:36:49PM +0100, Ben Hutchings wrote:
> > Package: popularity-contest
> > Version: 1.70
> > Severity: important
> > 
> > From time to time I've been seeing cron failure mails relating to
> > popularity-contest on my laptop.  I have seen this with both Vixie
> > cron and systemd-cron.
> 
> Hello Ben,
> By chance do you have the log for Vixie cron too ?

No, I haven't used it for quite a while.

Ben.

-- 
Ben Hutchings
Nothing is ever a complete failure;
it can always serve as a bad example.


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

Bug#977994: apt: Output from sandboxed methods should not be trusted

[Demi M. Obenour]

Package: apt
Version: 1.8.2.2
Severity: important

Dear Maintainer,

As far as I can tell, APT still trusts the output of its methods.  This
means that while they are sandboxed in theory, this sandbox is trivially
escapable in practice.

This would be Severity: critical except that no vulnerability in the
respective methods is known.  Nevertheless, this is what made
CVE-2019-3462 a devastating remote code execution vulnerability, rather
than a minor annoyance.

-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Sandbox::Seccomp "1";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-4\.19\.0-12-amd64$";
APT::NeverAutoRemove:: "^linux-image-4\.19\.0-13-amd64$";
APT::NeverAutoRemove:: "^linux-image-5\.4\.80-1\.qubes\.x86_64$";
APT::NeverAutoRemove:: "^linux-headers-4\.19\.0-12-amd64$";
APT::NeverAutoRemove:: "^linux-headers-4\.19\.0-13-amd64$";
APT::NeverAutoRemove:: "^linux-headers-5\.4\.80-1\.qubes\.x86_64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.19\.0-12-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.19\.0-13-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-5\.4\.80-1\.qubes\.x86_64$";
APT::NeverAutoRemove:: "^linux-modules-4\.19\.0-12-amd64$";
APT::NeverAutoRemove:: "^linux-modules-4\.19\.0-13-amd64$";
APT::NeverAutoRemove:: "^linux-modules-5\.4\.80-1\.qubes\.x86_64$";
APT::NeverAutoRemove:: "^linux-modules-extra-4\.19\.0-12-amd64$";
APT::NeverAutoRemove:: "^linux-modules-extra-4\.19\.0-13-amd64$";
APT::NeverAutoRemove:: "^linux-modules-extra-5\.4\.80-1\.qubes\.x86_64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.19\.0-12-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.19\.0-13-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-5\.4\.80-1\.qubes\.x86_64$";
APT::NeverAutoRemove:: "^linux-image-unsigned-4\.19\.0-12-amd64$";
APT::NeverAutoRemove:: "^linux-image-unsigned-4\.19\.0-13-amd64$";
APT::NeverAutoRemove:: "^linux-image-unsigned-5\.4\.80-1\.qubes\.x86_64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.19\.0-12-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.19\.0-13-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-5\.4\.80-1\.qubes\.x86_64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.19\.0-12-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.19\.0-13-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-5\.4\.80-1\.qubes\.x86_64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.19\.0-12-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.19\.0-13-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-5\.4\.80-1\.qubes\.x86_64$";
APT::NeverAutoRemove:: "^.*-modules-4\.19\.0-12-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.19\.0-13-amd64$";
APT::NeverAutoRemove:: "^.*-modules-5\.4\.80-1\.qubes\.x86_64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.19\.0-12-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.19\.0-13-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-5\.4\.80-1\.qubes\.x86_64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.19\.0-12-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.19\.0-13-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-5\.4\.80-1\.qubes\.x86_64$";
APT::NeverAutoRemove:: "^linux-modules-.*-4\.19\.0-12-amd64$";
APT::NeverAutoRemove:: "^linux-modules-.*-4\.19\.0-13-amd64$";
APT::NeverAutoRemove:: "^linux-modules-.*-5\.4\.80-1\.qubes\.x86_64$";
APT::NeverAutoRemove:: "^linux-tools-4\.19\.0-12-amd64$";
APT::NeverAutoRemove:: "^linux-tools-4\.19\.0-13-amd64$";
APT::NeverAutoRemove:: "^linux-tools-5\.4\.80-1\.qubes\.x86_64$";
APT::NeverAutoRemove:: "^linux-cloud-tools-4\.19\.0-12-amd64$";
APT::NeverAutoRemove:: "^linux-cloud-tools-4\.19\.0-13-amd64$";
APT::NeverAutoRemove:: "^linux-cloud-tools-5\.4\.80-1\.qubes\.x86_64$";
APT::NeverAutoRemove:: "^linux-buildinfo-4\.19\.0-12-amd64$";
APT::NeverAutoRemove:: "^linux-buildinfo-4\.19\.0-13-amd64$";
APT::NeverAutoRemove:: "^linux-buildinfo-5\.4\.80-1\.qubes\.x86_64$";
APT::NeverAutoRemove:: "^linux-source-4\.19\.0-12-amd64$";
APT::NeverAutoRemove:: "^linux-source-4\.19\.0-13-amd64$";
APT::NeverAutoRemove:: "^linux-source-5\.4\.80-1\.qubes\.x86_64$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-image";
APT::VersionedKernelPackages:: "linux-headers";
APT::VersionedKernelPackages:: "linux-image-extra";
APT::VersionedKernelPackages:: "linux-modules";
APT::VersionedKernelPackages:: "linux-modules-extra";
APT::VersionedKernelPackages:: "linux-signed-image";
APT::VersionedKernelPackages:: "linux-image-unsigned";
APT::VersionedKernelPackages:: "kfreebsd-image";
APT::VersionedKernelPackages:: "kfreebsd-headers";
APT::VersionedKernelPackages:: "gnumach-image";

Bug#977993: RFP: sfizz -- SFZ parser and synth c++ library

[Olivier Humbert]

Package: wnpp
Severity: wishlist

* Package name: sfizz
  Version : 0.5.1
  Upstream Author : Paul Ferrand 
* URL : https://sfz.tools/sfizz/
* License : BSD 2-Clause License
  Programming Lang: C++/C
  Description : Sampler plugin and library for SFZ instruments

sfizz is a SFZ parser and synth c++ library to play audio in SFZ format, 
providing LV2 / VST3 plugins and JACK standalone client.

Bug#977894: gui is broken, python3-xdo

[Joey Hess]

Daniel Kahn Gillmor wrote:
> I'm seeing comparable weird behavior, including the invocations of
> ldconfig and gcc, even if i don't see your particular failure.  yikes.
> But, a simple file like this produces the same behavior (with ldconfig
> and gcc):
> 
> ~~~
> #!/usr/bin/python3
> import xdo
> ~~~

> I still don't understand why we're seeing that xdo isn't found, though.
> Perhaps you could try applying the diff below to __main__.py in impass,
> removing liblibc.a, and trying impass gui again?
> 
> -except:
> +except ModuleNotFoundError:

> This is testing the hypothesis that there's some other error that
> happens when importing the xdo module, and we're imagining that it means
> the module isn't found.

Yes, I get the same backtrace from both the 2 line script and the
modified impass:

joey@darkstar:~>impass gui
Traceback (most recent call last):
  File "/usr/bin/impass", line 11, in 
load_entry_point('impass==0.12', 'console_scripts', 'impass')()
  File "/usr/lib/python3/dist-packages/impass/__main__.py", line 620, in main
func(args)
  File "/usr/lib/python3/dist-packages/impass/__main__.py", line 350, in gui
import xdo
  File "/usr/lib/python3/dist-packages/xdo/__init__.py", line 8, in 
from ._xdo import libxdo as _libxdo
  File "/usr/lib/python3/dist-packages/xdo/_xdo.py", line 14, in 
libc = ctypes.CDLL(ctypes.util.find_library('libc'))
  File "/usr/lib/python3.9/ctypes/util.py", line 341, in find_library
_get_soname(_findLib_gcc(name)) or _get_soname(_findLib_ld(name))
  File "/usr/lib/python3.9/ctypes/util.py", line 147, in _findLib_gcc
if not _is_elf(file):
  File "/usr/lib/python3.9/ctypes/util.py", line 99, in _is_elf
with open(filename, 'br') as thefile:
FileNotFoundError: [Errno 2] No such file or directory: b'liblibc.a'

And so I modified /usr/lib/python3/dist-packages/xdo/_xdo.py as follows,
which fixed the problem:

- libc = ctypes.CDLL(ctypes.util.find_library('libc'))
+ libc = ctypes.CDLL(ctypes.util.find_library('c'))

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#977977: libreoffice: a large part of the window appears off-screen

[Vincent Lefevre]

Control: forwarded -1 https://bugs.documentfoundation.org/show_bug.cgi?id=139200
Control: retitle -1 libreoffice: a large part of the window might appear 
off-screen if resolution/monitor config changes

I've reported the bug upstream and fixed a typo in the bug title.

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

Bug#977914:

[Sudip Mukherjee]

Control: tags 977914 + pending
--

Uploaded to NEW queue.


-- 
Regards
Sudip

Bug#971253: marked as pending in libpod

[Antonio Terceiro]

On Fri, 04 Dec 2020 11:56:58 + Reinhard Tartler  
wrote:
> Control: tag -1 pending
> 
> Hello,
> 
> Bug #971253 in libpod reported by you has been fixed in the
> Git repository and is awaiting an upload. You can see the commit
> message below and you can check the diff of the fix at:
> 
> https://salsa.debian.org/debian/libpod/-/commit/f4ee966e6638ebbd7d0324bedbeac1a277a28a23
> 
> 
> Install runc by default, Closes: #971253
> 
> Podman default configuration points ot runc, which is the better tested
> implementation and supports cgroupsv2. crun remains a possible
> configuration, but requires manual configuration.
> 

This change makes podman not work at all for me. I did not do any
customization in /etc/containers/ at all.

$ podman images
Error: default OCI runtime "crun" not found: invalid argument


it seems that `crun` is the default in the podman code even though it
looks like runc is the default based on the (commented) contents of the
config file?


signature.asc
Description: PGP signature

Bug#977894: gui is broken, python3-xdo

[Daniel Kahn Gillmor]

Control: affects 977894 python3-xdo

On Wed 2020-12-23 15:50:43 -0400, Joey Hess wrote:
> Ok, this is super weird, and I'm afraid also likely a security hole.

ugh, thanks for digging around on this with us, Joey.

it looks to me like the liblibc.a business is happening due to gobject
introspection, since it doesn't happen when impass isn't in gui mode.

> openat(AT_FDCWD, "liblibc.a", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file 
> or directory)
> write(2, "The xdo module is not found, so "..., 100The xdo module is not 
> found, so the 'xdo' paste method is not available.
> Please install python3-xdo.) = 100
> write(2, "\n", 1
> )   = 1
> rt_sigaction(SIGINT, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, 
> sa_restorer=0x7f56ccd6a140}, {sa_handler=0x63fb20, sa_mask=[], 
> sa_flags=SA_RESTORER, sa_restorer=0x7f56ccd6a140}, 8) = 0
> munmap(0x7f56cc405000, 135168)  = 0
> exit_group(1)   = ?
> +++ exited with 1 +++
>
> What is this "liblibc.a" from CWD?! I have no clue at all, but if it
> does anything with it after opening it, then there would be security
> consequences.
>
> The strace -f also shows it execing ldconfig and gcc. I've attached the whole
> thing.

I'm seeing comparable weird behavior, including the invocations of
ldconfig and gcc, even if i don't see your particular failure.  yikes.
But, a simple file like this produces the same behavior (with ldconfig
and gcc):

~~~
#!/usr/bin/python3
import xdo
~~~

Perhaps this is related to how python's ctypes module works?
(python3-xdo depends on ctypes)

I still don't understand why we're seeing that xdo isn't found, though.
Perhaps you could try applying the diff below to __main__.py in impass,
removing liblibc.a, and trying impass gui again?

diff --git a/impass/__main__.py b/impass/__main__.py
index 236e4c5..29957d6 100755
--- a/impass/__main__.py
+++ b/impass/__main__.py
@@ -332,7 +332,7 @@ def gui(args, method=os.getenv('IMPASS_XPASTE', 'xdo')):
 if method == 'xdo':
 try:
 import xdo
-except:
+except ModuleNotFoundError:
 error(1, """The xdo module is not found, so the 'xdo' paste method 
is not available.
 Please install python3-xdo.""")
 # initialize xdo


This is testing the hypothesis that there's some other error that
happens when importing the xdo module, and we're imagining that it means
the module isn't found.

we should probably have a more conservative exception handler here anyway.

> I am cautious about sending a strace with that file created, because the GUI
> did open and sanitizing my password info would take time,

yes, please be cautious about sending straces with impass!

Regards,

--dkg


signature.asc
Description: PGP signature

Bug#966555: tuned: please update the package to a recent version

[gustavo panizzo]

Hello all

On Wed, Dec 23, 2020 at 07:13:55PM +, Evgeni Golov wrote:

Yeah, I think I added gustavo to uploaders because of the ITP and our 
discussions before the initial upload.

Gustavo, if you want, I can drop you in the 2.15 upload I am preparing?



yes please, remove me from uploaders


thanks!

--
IRC: gfa
GPG: 0x27263FA42553615F904A7EBE2A40A2ECB8DAD8D5
OLD GPG: 0x44BB1BA79F6C6333

Bug#974779: [Pkg-julia-devel] Bug#974779: severity - Julia: Please upgrade to llvm-toolchain-11

[Norbert Preining]

Hi,

> Control: severity -1 serious

Pushing severity will not change the fact that the released version of
Julia does not support llvm11 and cannot be built with it.
As far as I see support for llvm11 is included in the 1.6.0 branch of
Julia, but that is probbly far off, and definitely not ready to be
released.

That leaves either Julia being removed from testing/bullseye (very bad
idea) and keeping llvm10 in bullseye (nothing I can evaluate).

Best

Norbert

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

Bug#977992: hyphy: FTBFS on hurd-i386: wrong reference to the build directory

[Pino Toscano]

Source: hyphy
Version: 2.5.18+dfsg-1
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd

Hi,

currently hyphy fails to build on hurd-i386 [1].

The problem is that, in the dh_auto_test override, the "obj-*-*-*" glob
pattern is used to refer to the build directory. The default build
directory for cmake is "obj-$DEB_HOST_GNU_TYPE", and considering that
DEB_HOST_GNU_TYPE for hurd-i386 is "i686-gnu", then the pattern does not
match the build directory.

The fix is simple: use the right variable to refer directly to the build
directory, with no need to use globbing at all. Patch attached for this.

[1] 
https://buildd.debian.org/status/fetch.php?pkg=hyphy=hurd-i386=2.5.24%2Bdfsg-1=1608548780=0

Thanks,
-- 
Pino
--- a/debian/rules
+++ b/debian/rules
@@ -33,7 +33,7 @@ override_dh_auto_build:
 
 override_dh_auto_test:
 ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
-   find "$$(echo obj-*-*-*/)" \
+   find "obj-$(DEB_HOST_GNU_TYPE)/" \
-not -path "*/CMakeFiles/*" \
-type f,l \
-executable \

Bug#977990: os-autoinst: FTBFS on i386: 3/3 Test #3: test-perl-testsuite ..............***Failed 332.81 sec

[Sebastian Ramacher]

Source: os-autoinst
Version: 4.6.1604525166.912dfbd-0.2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

os-autoinst FTBFS on i386:
| 3: ./29-backend-generalhw.t . ok
| 3: 
| 3: #   Failed test 'Result in testresults/result-reload_needles.json is ok'
| 3: #   at ./99-full-stack.t line 86.
| 3: #  got: 'fail'
| 3: # expected: 'ok'
| 3: Bailout called.  Further testing stopped:  
testresults/result-reload_needles.json failed
| 3: FAILED--Further testing stopped: testresults/result-reload_needles.json 
failed
| 3/3 Test #3: test-perl-testsuite ..***Failed  332.81 sec

See
https://buildd.debian.org/status/fetch.php?pkg=os-autoinst=i386=4.6.1604525166.912dfbd-0.2=1608714762=0

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#977988: /usr/bin/spectacle: does not start (libkImageAnnotator.so.0.3.2 not found)

[Pino Toscano]

reassign 977988 src:kimageannotator
forcemerge 977649 977988
thanks

In data mercoledì 23 dicembre 2020 22:26:13 CET, Dominik George ha scritto:
> Package: kde-spectacle
> Version: 20.12.0-1
> Severity: grave
> File: /usr/bin/spectacle
> Justification: renders package unusable
> 
> After a recent update, spectacle stoppede working, and errors out on start 
> with:
> 
>   spectacle: error while loading shared libraries: 
> libkImageAnnotator.so.0.3.2: cannot open shared object file: No such file or 
> directory
> 
> Maybe it needs a binNMU?

No, it needs a fixed SONAME and a fixed Debian package name matching
it. See also #977649 (which this bug will be merged to).

In the meanwhile, I will disable the kimageannotator-related features,
as at least there will be a functional Spectacle.

-- 
Pino Toscano

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

Bug#957037: biboumi: ftbfs with GCC-10

[Michel Le Bihan]

Hello,

I opened a merge request, but merging all branches into your repo might cause 
issues in the upstream branch in the future due to the merge commits. Instead, 
it will be best to pull all branches from my repo into branches of your repo, 
but without adding merge commits or at least without adding them to the 
upstream and pristine tar branches.

Michel Le Bihan

Le 23 décembre 2020 04:58:21 GMT+01:00, Vasudev Kamath  a 
écrit :
>Michel Le Bihan  writes:
>
>> Le mardi 22 décembre 2020 à 17:35 +0530, Vasudev Kamath a écrit :
>>> Jonas Smedegaard  writes:
>>> 
>>> > Quoting Michel Le Bihan (2020-12-20 17:15:29)
>>> > > Le dimanche 20 décembre 2020 à 16:50 +0100, Jonas Smedegaard a
>>> > > écrit :
>>> > > > Quoting Michel Le Bihan (2020-12-20 16:06:27)
>>> > > > > A quick summary of the differences between both repos:
>>> > > > 
>>> > > > Thanks, that is no doubt helpful!
>>> > > > 
>>> > > > [ beware: commenting without actually having looked at the
>>> > > > code! ]
>>> > > Please look at it when you will have time.
>>> > 
>>> > Most likely no: Instead, please wait for Vasudev to look at it.
>>> 
>>> I was looking at biboumi repository and did not see any merge
>>> requests
>>> on it. Jonas do we need to enable something in repo to allow merge
>>> requests?.
>>> 
>> Yes. You need to enable merge requests in the repository settings. They
>> are currently disabled.
>
>Done, it took me a while to navigate around the settings. Please raise
>MR so I can review.
>
>Cheers,
>Vasudev

Bug#977984: cron.d and cron.daily jobs may run in parallel and conflict

[Bill Allombert]

On Wed, Dec 23, 2020 at 09:36:49PM +0100, Ben Hutchings wrote:
> Package: popularity-contest
> Version: 1.70
> Severity: important
> 
> From time to time I've been seeing cron failure mails relating to
> popularity-contest on my laptop.  I have seen this with both Vixie
> cron and systemd-cron.

Hello Ben,
By chance do you have the log for Vixie cron too ?

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#977870: Failed to load /usr/lib/chromium/libGLESv2.so

[Michel Le Bihan]

Hello,

I also added the symlinks:
```
sudo ln -s /usr/lib/x86_64-linux-gnu/libGLESv2.so /usr/lib/chromium/
sudo ln -s /usr/lib/x86_64-linux-gnu/libEGL.so /usr/lib/chromium/
```
but in my case it did not help much as I got:
```
libva error: /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so init failed
[1297931:1297931:1223/212509.293016:ERROR:sandbox_linux.cc(374)]
InitializeSandbox() called with multiple threads in process gpu-
process.
libva error: /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so init failed
[1297931:1297931:1223/212509.318240:ERROR:gl_surface_egl.cc(773)] EGL
Driver message (Error) eglCreateContext: eglCreateContext
[1297931:1297931:1223/212509.318348:ERROR:gl_context_egl.cc(259)]
eglCreateContext failed with error EGL_BAD_ATTRIBUTE
[1297931:1297931:1223/212509.318718:ERROR:gpu_channel_manager.cc(749)]
ContextResult::kFatalFailure: Failed to create shared context for
virtualization.
[1297931:1297931:1223/212509.318833:ERROR:shared_image_stub.cc(470)]
SharedImageStub: unable to create context
[1297931:1297931:1223/212509.318939:ERROR:gpu_channel.cc(449)]
GpuChannel: Failed to create SharedImageStub
```

Maybe it's an issue with my GPU then. What GPU do you have? Could you
run some WebGL tests and check if they succeed or render correctly?

Of course the correct fix would be to patch Chromium to make it load
the system libs from the correct location.

Michel Le Bihan

Bug#977989: qcengine: Please make another source-only upload for testing migration

[Boyuan Yang]

Source: qcengine
Version: 0.16.0-1
Severity: important
X-Debbugs-CC: mba...@debian.org

Dear Debian qcengine maintainer,

Looking at https://tracker.debian.org/pkg/qcengine , it seems that this
package never migrated to Debian Testing. With Debian 11 release freeze
approaching, this means that your package will miss Debian 11 if no
action is taken.

The reason for blocked migration is non-source-only upload. Please make
another source-only upload as described in
https://wiki.debian.org/SourceOnlyUpload to fix this issue.

Thanks,
Boyuan Yang


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

Bug#977901: chromium: Inconsistent SEGV

[Michel Le Bihan]

Hello,

My build just finished. Could you please test if you are still getting
this issue in https://lebihan.pl/files/chromium.tar.gz ?

Michel Le Bihan

Bug#977963: [Pkg-javascript-devel] node-commander ≥ 6

[Jonas Smedegaard]

Quoting Xavier (2020-12-23 22:15:27)
> can I upload node-commander to unstable or do you prefer to push 
> node-terser first ?

Please go ahead!


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#977977: libreoffice: a large part of the window appears off-screen

[Vincent Lefevre]

On 2020-12-23 20:48:33 +0100, Rene Engelhard wrote:
> Am 23.12.20 um 20:34 schrieb Vincent Lefevre:
> > On 2020-12-23 19:53:09 +0100, Rene Engelhard wrote:
> >> Am 23.12.20 um 18:59 schrieb Vincent Lefevre:
> >>> A large part of the window appears off-screen, including the menu
> >>> and window controls. Basically, the only thing I can do is to type
> >>> Ctrl-Q to quit Libreoffice!
> >> And why is that? Obviously works on one-monitor setups.
> > My machine is a laptop, sometimes with only its screen, sometimes
> > with 2 external 4K monitors, depending on where I am.
> Aha. I have none of these. (Besides that my laptop has a sane graphics
> card.)
> >> And given you apparently use the nvidia driver (see below) No way to
> >> reproduce this here.
> > The nouveau driver is unusable with an external monitor (even when
> > used in mirror mode). The nvidia driver is the only solution with
> > such a configuration.
> 
> In Germany we have an idiom amongst IT people: "Augen auf beim
> Hardwarekauf" (which roughly translates to
> 
> "open your eyes when buying hardware"). You got into this situation
> yourself.

This was what I did when buying my laptop 5 years ago, but couldn't
find any reliable information (and obviously it wasn't possible to
test with future additional hardware and future Linux kernels).
And it now seems that nouveau information has been removed from the
Debian wiki, which is in some mess, e.g. section
  https://wiki.debian.org/GraphicsCard#nVidia_and_nouveau
just provides a link to NvidiaGraphicsDrivers, which says "This page
describes how to install the NVIDIA proprietary display driver on
Debian systems."

> > I did not set anything special. I rarely use LibreOffice (only when I
> > need to). And I don't think I have ever changed anything explicitly in
> > the preferences. In short, I let LibreOffice handle the config on its
> > own.
> 
> OK, but I believe it saves it's dimensions when closed, I at laest get
> this when williy-nilly dragging the window.
> 
> It probably also saves the location..
> 
> 
> This would explain your problem. I don't think there is a senseful way
> to fix this though.

I would have thought that in such a case, it would also save the
screen dimensions (or save the window position/size in percentages).
This is rather obvious to me.

If I run and quit LibreOffice several times with manually moving the
window, then after a few times, it becomes partly off-screen (there's
the same issue for some other applications).

> In any case, this is something for upstream - not Debian to change. And
> for that there's reportbug mentioning that upstream bugs should go upstream.

I'll have a look.

> > That's the default for unstable, except that I added experimental. 
> 
> No, it's not.
> 
> Adding stable and testing is not. (unstable-debug is understandable, but
> also not default.)

IIRC, it was the default or needed or recommended many years ago.
At least for testing. And concerning stable, I can see in my logs,
from 2005:

  * Added the stable distribution since the version of a package
in stable may be more recent than the version in testing (in
particular during a freeze).

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

Bug#976891: [Android-tools-devel] Bug#976891: fastboot exits with "fake placeholder until fastboot builds" message

[Hans-Christoph Steiner]

As far as I know, the blocker for fastbook is android-platform-art.  It 
has a crazy upstream build system.  Right now, it almost building, but 
the build is currently dying on this error:


clang++ -o runtime/compiler_filter.o -g -O2 
-fdebug-prefix-map=/build/android-platform-art-10.0.0+r36=. 
-fstack-protector-strong -Wformat -Werror=format-security -fPIC -c 
-std=gnu++17 -Wno-invalid-offsetof -Wno-invalid-partial-specialization 
-D__STDC_FORMAT_MACROS -D__STDC_CONSTANT_MACROS -fno-rtti 
-fstrict-aliasing -fvisibility=protected -fno-omit-frame-pointer 
-Wdate-time -D_FORTIFY_SOURCE=2 -DNDEBUG -I/usr/include/android -UDEBUG 
-Umips -DART_BASE_ADDRESS_MAX_DELTA=0x100 
-DART_BASE_ADDRESS_MIN_DELTA=-0x100 -DART_BASE_ADDRESS=0x6000 
-DART_DEFAULT_COMPACT_DEX_LEVEL=fast -DART_DEFAULT_GC_TYPE_IS_CMS 
-DART_ENABLE_ADDRESS_SANITIZER=1 -DART_ENABLE_CODEGEN_arm 
-DART_ENABLE_CODEGEN_arm64 -DART_ENABLE_CODEGEN_mips 
-DART_ENABLE_CODEGEN_mips64 -DART_ENABLE_CODEGEN_x86 
-DART_ENABLE_CODEGEN_x86_64 -DART_FRAME_SIZE_LIMIT=1736 
-DART_READ_BARRIER_TYPE_IS_BAKER=1 -DART_STACK_OVERFLOW_GAP_arm=8192 
-DART_STACK_OVERFLOW_GAP_arm64=8192 -DART_STACK_OVERFLOW_GAP_mips=16384 
-DART_STACK_OVERFLOW_GAP_mips64=16384 
-DART_STACK_OVERFLOW_GAP_x86_64=8192 -DART_STACK_OVERFLOW_GAP_x86=8192 
-DART_USE_READ_BARRIER=1 -DBUILDING_LIBART=1 -DIMT_SIZE=43 
-DUSE_D8_DESUGAR=1 -I. -I/usr/include/android/nativehelper 
-I/usr/include/valgrind -Icmdline -Iruntime -Iruntime/generated 
-Ilibartbase -Ilibartpalette/include -Ilibdexfile -Ilibelffile 
-Ilibprofile -Isigchainlib -I/usr/include/android 
-Itools/cpp-define-generator -Idebian/out  runtime/compiler_filter.cc

In file included from tools/cpp-define-generator/asm_defines.cc:36:
In file included from tools/cpp-define-generator/asm_defines.def:21:
In file included from tools/cpp-define-generator/globals.def:23:
In file included from runtime/gc/accounting/card_table.h:22:
In file included from runtime/base/locks.h:25:
In file included from libartbase/base/atomic.h:27:
In file included from libartbase/base/macros.h:24:
/usr/include/android/android-base/thread_annotations.h:139:42: error: 
'acquire_capability' attribute requires arguments whose type is 
annotated with 'capability' attribute; type here is 'std::mutex' 
[-Werror,-Wthread-safety-attributes]

  ScopedLockAssertion(std::mutex& mutex) ACQUIRE(mutex) {}
 ^
/usr/include/android/android-base/thread_annotations.h:57:37: note: 
expanded from macro 'ACQUIRE'

  THREAD_ANNOTATION_ATTRIBUTE__(acquire_capability(__VA_ARGS__))
^
In file included from tools/cpp-define-generator/asm_defines.cc:36:
In file included from tools/cpp-define-generator/asm_defines.def:21:
In file included from tools/cpp-define-generator/globals.def:23:
In file included from runtime/gc/accounting/card_table.h:23:
libartbase/base/mem_map.h:71:35: error: 'requires_capability' attribute 
requires arguments whose type is annotated with 'capability' attribute; 
type here is 'bool' [-Werror,-Wthread-safety-attributes]

  MemMap(MemMap&& other) noexcept REQUIRES(!MemMap::mem_maps_lock_);
  ^
/usr/include/android/android-base/thread_annotations.h:51:37: note: 
expanded from macro 'REQUIRES'



A full build log is available here:
https://salsa.debian.org/android-tools-team/android-platform-art/-/jobs/1274438

Bug#977988: /usr/bin/spectacle: does not start (libkImageAnnotator.so.0.3.2 not found)

[Dominik George]

Package: kde-spectacle
Version: 20.12.0-1
Severity: grave
File: /usr/bin/spectacle
Justification: renders package unusable

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

After a recent update, spectacle stoppede working, and errors out on start with:

  spectacle: error while loading shared libraries: libkImageAnnotator.so.0.3.2: 
cannot open shared object file: No such file or directory

Maybe it needs a binNMU?

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

Kernel: Linux 5.9.0-4-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=nb_NO.UTF-8, LC_CTYPE=nb_NO.UTF-8 (charmap=UTF-8), 
LANGUAGE=nb_NO:nb:no_NO:no:nn_NO:nn:da:sv
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages kde-spectacle depends on:
ii  kio5.77.0-2
ii  libc6  2.31-6
ii  libkf5configcore5  5.77.0-2
ii  libkf5configgui5   5.77.0-2
ii  libkf5configwidgets5   5.77.0-2
ii  libkf5coreaddons5  5.77.0-2
ii  libkf5dbusaddons5  5.77.0-2
ii  libkf5globalaccel-bin  5.77.0-2
ii  libkf5globalaccel5 5.77.0-2
ii  libkf5i18n55.77.0-2
ii  libkf5kiocore5 5.77.0-2
ii  libkf5kiogui5  5.77.0-2
ii  libkf5kiowidgets5  5.77.0-2
ii  libkf5kipi32.0.0   4:20.08.0-1
ii  libkf5newstuff55.77.0-3
ii  libkf5notifications5   5.77.0-2
ii  libkf5purpose-bin  5.77.0-2
ii  libkf5purpose5 5.77.0-2
ii  libkf5service-bin  5.77.0-2
ii  libkf5service5 5.77.0-2
ii  libkf5waylandclient5   4:5.77.0-2
ii  libkf5widgetsaddons5   5.77.0-4
ii  libkf5windowsystem55.77.0-2
ii  libkf5xmlgui5  5.77.0-2
ii  libkimageannotator00.4.0-1
ii  libqt5core5a   5.15.2+dfsg-2
ii  libqt5dbus55.15.2+dfsg-2
ii  libqt5gui5 5.15.2+dfsg-2
ii  libqt5printsupport55.15.2+dfsg-2
ii  libqt5widgets5 5.15.2+dfsg-2
ii  libqt5x11extras5   5.15.2-2
ii  libstdc++6 10.2.1-1
ii  libxcb-cursor0 0.1.1-4
ii  libxcb-image0  0.4.0-1+b3
ii  libxcb-util1   0.4.0-1+b1
ii  libxcb-xfixes0 1.14-2
ii  libxcb11.14-2
ii  qdbus-qt5  5.15.2-3

kde-spectacle recommends no packages.

kde-spectacle suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJ+BAEBCgBoFiEEPJ1UpHV1wCb7F/0mt5o8FqDE8pYFAl/jtdYxGmh0dHBzOi8v
d3d3LmRvbWluaWstZ2VvcmdlLmRlL2dwZy1wb2xpY3kudHh0LmFzYxgcbmF0dXJl
c2hhZG93QGRlYmlhbi5vcmcACgkQt5o8FqDE8pavGQ/+LbBxRuQdz7GeHZabCmTo
GlYBc/60XxcqG7y1SIJdkuxPKoLz5TJrG+87Qy2U6O701g+CIgWCEUhrGWjnXuEC
E2uRQj66m2R9UbIz7s4mgEV9fxfZVZwwQafEH1RXXuvWkSbaslVQuNTbgC1P5zaw
C5YFNtiLuN3BAlJSa3lAi0hZUnD5+KcTzxWYKNKq2fCKd8Wex/tAd+YAeD623htS
OR/CwklxtUrtPPCapMPWBhMzk5dvWpunD4A7j1WF3nptkKA2nk+Jio1qbbqUwlW/
ha/p6LByqwT9CRI4JAyFxwy62nOP1pVfraaOrB9/7fxABJmxsS0wNNUL0Hxsx5we
NSO80AqM34JwRp5ho7f4ZKn9jviAIr7UvInUo46Ng3RjX8hRRw04Y/R43lv+vYQD
aq2gts5t+MQB2HwM+p+4Qz/6Vn+xwkQSh4reQixIo2UoSjNsyMc0GstDzdB8ZHyc
ulyFA0FEvz4AoJiSDCRuJ6tgVXqP4EI2DkdDck4H31bt7WZwYOV5MJzX93U9QXyd
pt0Q8Aav4ya+A3lfRjwAvCPpDqH8PgiT5XLLF/rUB2W7z50MNO3LonJKz2UGxtgu
TvzHNDPosEx0BnbX5Li0u8OgRHizttC23IbR9hld4A0o8C/iz07IbMSP8nqED6CT
gNlsZMEbF2LYl9GutLcbq44=
=KbJh
-END PGP SIGNATURE-

Bug#977567: jruby-utils-clojure blocked by jruby bugs

[Louis-Philippe Véronneau]

block 977567 by 895837
block 977567 by 977979
thanks

My work on this package can be found at:

https://salsa.debian.org/clojure-team/jruby-utils-clojure

Sadly, the testsuite currently fails pretty badly. I believe it's in
part because of the jruby version in Debian being too old, but I could
be wrong.

#977979 is certainly making things complex to debug too :(

FWIW, the testsuite failure starts with:

--
lein test puppetlabs.services.jruby-pool-manager.jruby-agents-test
LoadError: no such file to load -- jar-dependencies
  require at org/jruby/RubyKernel.java:956
at 

Bug#977963: [Pkg-javascript-devel] node-commander ≥ 6

[Xavier]

Le 23/12/2020 à 13:28, Jonas Smedegaard a écrit :
> Quoting Jonas Smedegaard (2020-12-23 13:06:40)
>> Quoting Xavier (2020-12-23 12:28:53)
>>> Le 23/12/2020 à 12:19, Jonas Smedegaard a écrit :
 Quoting Xavier (2020-12-23 11:34:41)
> node-commander 6 is ready in experimental. It seems that all is 
> OK, except a little change in uglifyjs.terser help output 
> detected by your Perl test.
> I posted a simple MR, could you see if this is acceptable 
> (compatible with node-commander 5)?

 Please attach proposed patch to an email.  Preferably as a 
 bugreport.
>>
>>> With commander 6, uglifyjs.terser displays:
>>>
>>>   Usage: uglifyjs [options]...
>>>
>>> instead of:
>>>
>>>   Usage: uglifyjs.terser [options]...
>>>
>>> I don't know if my patch is useful here: it replaced your test regex 
>>> with a more tolerant one without fixing the real issue (if this is an 
>>> issue?).
>>
>> Ah, thanks - that is a helpful detail.
>>
>> No, I don't think that is an issue needed any further work than 
>> wriggling the terser test a bit.
>>
>> Please go ahead (assuming no issues elsewhere) with the node-commander 
>> upgrade - i.e. don't wait for terser, I will handle that from there.
> 
> Oh!  This still is just a mailinglist conversation, not a bugreport :-(
> 
> @Xavier, would you mind filing this as a proper bugreport, please?
> 
> Or tell me if that is too uch hassle for you, then I will do it, but 
> prefor to give you credit for your work.
> 
> In case you wonder: No, this is not just bureaucratic busywork: I am in 
> the middle of other work with the terser package (and a pile of other 
> work with other packages, including the mess I made with symlink-to-dir 
> removals), and tracking issues with the bugtracker truly helps.

Hi,

can I upload node-commander to unstable or do you prefer to push
node-terser first ?

Regards,
Xavier

Bug#977982: mirrors.ptisp.pt: 403 Forbidden error

[Eduardo Silvestre]

Hello Sebastian,

This is strange because all files and permissions are synced from master.

I will fixed and update you soon.

Best Regards,

Sent from mobile

> On 23 Dec 2020, at 20:19, Sebastian Haderecker 
>  wrote:
> 
> Package: mirrors
> Severity: normal
> User: mirr...@packages.debian.org
> Usertags: mirror-problem
> 
> Hi,
> 
> The mirror mirrors.ptisp.pt throws a 403 error.
> 
> This results in the mirror being unavailable during updates or package 
> installations:
> 
> E: Failed to fetch http://mirrors.ptisp.pt/debian/dists/stable/InRelease 403 
> Forbidden [IP: 2a00:1650:1000:0:8fc7:3f4f:8629:b7fc 80]
> E: The repository 'http://mirrors.ptisp.pt/debian stable InRelease' is not 
> signed.
> 
> It seems like the "InRelease", "Release" and "Release.gpg" files all give the 
> 403 error.
> This is not only for dists/stable, I also checked in dists/buster and 
> dists/stretch and a couple more.
> They all give the same 403 error, so this issue affects almost every dist 
> that is on the mirror.
> 
> Can you please fix the access to those files.
> 
> Thanks,
> Sebastian

Bug#977987: esnacc: problem with homepage + new version

[Davide Prina]

Source: esnacc
Version: 1.8.1-1
Severity: normal

I have see that the project https homepage have a certificate issued not 
for that site:

https://esnacc.org/

I think that it is better to use the http address for the homepage:
http://esnacc.org/

and/or point to the github site
https://github.com/esnacc/esnacc-ng/

Note that there is a new version: 1.8.2

Ciao
Davide

Bug#977986: insighttoolkit4: FTBFS in sid

[Gianfranco Costamagna]

Source: insighttoolkit4
Version: 4.13.3withdata-dfsg1-3
Severity: serious

Hello, looks like itk4 ftbfs in sid because of test failures (at least on 
amd64).
You can download the build log here:
http://debomatic-amd64.debian.net/distribution#unstable/insighttoolkit4/4.13.3withdata-dfsg1-3/buildlog

or here:

https://launchpad.net/ubuntu/+source/insighttoolkit4/4.13.3withdata-dfsg1-3build2/+build/20375321

However it might get deleted after few days
(the log is too huge to be added to an email, sorry)

thanks for having a look,

Gianfranco

Bug#977985: uefi secure boot instructions

[phil]

Package: installation-reports

> dear developers and staff!
> i struggled booting into a new install
> as it hanged on 'loading initial ramdisk'
> then at the end of a forum thread
> came across this instruction,
>
> http://bernaerts.dyndns.org/linux/74-ubuntu/340-ubuntu-install-acer-aspire-cloudbook-431/
> wich saved the day finally
> my actual machine was also an acer, ES1-131 series
> sorry i didnt fill the report form, as this is somewhat outside the
> install report
> in a nutshell: had to enable certain file(s) for uefi, to then show up in
> boot list, all in secure boot mode
> legacy and secure boot did not do it
> i wish others would find above information, its very frustrating scrolling
> the forum entries to no avail
>
> all best, and merry christmas
> fulop
>
>

Bug#974779: severity - Julia: Please upgrade to llvm-toolchain-11

[Sebastian Ramacher]

Control: severity -1 serious

On 2020-12-23 09:41:26 +0100, Sylvestre Ledru wrote:
> severity 974779 important
> thanks
> 
> Hello,
> 
> I am increasing the severity of this bug. Julia is the last blocker to
> remove llvm-toolchain-10 from the Debian archive.
> 
> Either you go back to -9 or move to -11
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974788

That's the only remaining bug before llvm-toolchain-10 can be removed.
Hence I'm raising the severity to serious. We want to ship bullseye
without llvm-toolchain-10.

Cheers

> 
> Cheers
> 
> S

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#977984: cron.d and cron.daily jobs may run in parallel and conflict

[Ben Hutchings]

Package: popularity-contest
Version: 1.70
Severity: important

From time to time I've been seeing cron failure mails relating to
popularity-contest on my laptop.  I have seen this with both Vixie
cron and systemd-cron.

Today I opened my laptop at around 17:53, and systemd-cron started
running cron jobs that were scheduled to run during the time it was
suspended.  That included both cron.d and cron.daily jobs for
popularity-contest:

# systemctl status cron-popularity-contest-root-0.service
● cron-popularity-contest-root-0.service - [Cron] "10 5 * * * root test -x 
/etc/cron.daily/popularity-contest && /etc/cron.daily/popularity-contest 
--crond"
 Loaded: loaded (/etc/cron.d/popularity-contest; generated)
 Active: inactive (dead) since Wed 2020-12-23 17:53:54 CET; 3h 12min ago
TriggeredBy: ● cron-popularity-contest-root-0.timer
   Docs: man:systemd-crontab-generator(8)
Process: 97570 ExecStart=/bin/sh 
/run/systemd/generator/cron-popularity-contest-root-0.sh (code=exited, 
status=0/SUCCESS)
   Main PID: 97570 (code=exited, status=0/SUCCESS)

Dec 23 17:53:49 deadeye systemd[1]: Starting [Cron] "10 5 * * * root test -x 
/etc/cron.daily/popularity-contest && /etc/cron.daily/popularity-contest 
--crond"...
Dec 23 17:53:54 deadeye popularity-contest[97891]: unable to submit report to 
http://popcon.debian.org/cgi-bin/popcon.cgi.
Dec 23 17:53:54 deadeye systemd[1]: cron-popularity-contest-root-0.service: 
Succeeded.
Dec 23 17:53:54 deadeye systemd[1]: cron-popularity-contest-root-0.service: 
Unit process 97896 (exim4) remains running after unit stopped.
Dec 23 17:53:54 deadeye systemd[1]: Finished [Cron] "10 5 * * * root test -x 
/etc/cron.daily/popularity-contest && /etc/cron.daily/popularity-contest 
--crond".
# systemctl status cron-daily.service
● cron-daily.service - systemd-cron daily script service
 Loaded: loaded (/lib/systemd/system/cron-daily.service; static)
 Active: failed (Result: exit-code) since Wed 2020-12-23 17:53:55 CET; 3h 
8min ago
   Docs: man:systemd.cron(7)
Process: 97569 ExecStartPre=/lib/systemd-cron/boot_delay 5 (code=exited, 
status=0/SUCCESS)
Process: 97615 ExecStart=/bin/run-parts --report /etc/cron.daily 
(code=exited, status=1/FAILURE)
   Main PID: 97615 (code=exited, status=1/FAILURE)

Dec 23 17:53:50 deadeye runuser[97819]: pam_unix(runuser:session): session 
opened for user www-data by (uid=0)
Dec 23 17:53:50 deadeye runuser[97819]: pam_unix(runuser:session): session 
closed for user www-data
Dec 23 17:53:55 deadeye run-parts[97615]: /etc/cron.daily/popularity-contest:
Dec 23 17:53:55 deadeye run-parts[97615]: gpg: can't open 
'/var/log/popularity-contest.new': No such file or directory
Dec 23 17:53:55 deadeye run-parts[97615]: gpg: /var/log/popularity-contest.new: 
encryption failed: No such file or directory
Dec 23 17:53:55 deadeye run-parts[97615]: run-parts: 
/etc/cron.daily/popularity-contest exited with return code 2
Dec 23 17:53:55 deadeye systemd[1]: cron-daily.service: Main process exited, 
code=exited, status=1/FAILURE
Dec 23 17:53:55 deadeye systemd[1]: cron-daily.service: Failed with result 
'exit-code'.
Dec 23 17:53:55 deadeye systemd[1]: Failed to start systemd-cron daily script 
service.
Dec 23 17:53:55 deadeye systemd[1]: cron-daily.service: Triggering OnFailure= 
dependencies.

This seems to be likely to happen on any system that remains suspended
across the times of both cron jobs.  Some kind of serialisation is
required, so that only one job at a time will manipulate the log
files.

Ben.

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

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

Versions of packages popularity-contest depends on:
ii  debconf [debconf-2.0]  1.5.74
ii  dpkg   1.20.5

Versions of packages popularity-contest recommends:
ii  exim4-daemon-light [mail-transport-agent]  4.94-9+b1
ii  gnupg  2.2.20-1
ii  systemd-cron [cron-daemon] 1.5.15-1

Versions of packages popularity-contest suggests:
ii  systemd-cron [anacron]  1.5.15-1
pn  tor 
ii  torsocks2.3.0-3

-- debconf-show failed

Bug#970635: moosic: new upstream now supports Python 3

[The Wanderer]

First, the bad news.

In trying to test the playlist-file compatibility concern, I've
discovered that at least on my system as it now exists, the default
moosic configuration in the published codebase doesn't play WAV files
(or anything else that relies on sox) correctly. IIRC it did work back
in September, but I'm guessing something may have changed in the
meantime; I've certainly done enough package upgrades for that to be
plausible.

The moosic configuration from the Python-2-based instance I've been
running for all these years, however, does play the files correctly.
Trouble is, I don't know whether it's likely to work on a standard
Debian install, or whether mine is special in some way.

The difference is that the default ~/.moosic/config defines WAV files as
being played by invoking 'sox $item -t ossdsp /dev/dsp' (and fails with
"no handler for given file type 'ossdsp'"), and the live-environment one
defines them to be played by invoking 'play $item'.

This can be tested either via moosic, by adjusting the config file, or
simply by invoking sox with that syntax on a WAV file which sox knows
how to play. If you get a chance to test with either method on a
known-baseline Debian system, and it turns out that the observed
behavior is indeed not specific to my environment, please let me know;
I'll be happy to either spin up a minor (micro?) release which adjusts
the default config, or if preferred, just provide a patch without making
a new release yet.


Second, two pieces of good news.

One: although the playlist-queue file doesn't seem to be identical in
format to the one from the Python 2 daemon, it does seem to be quite
similar, and the code which generates it hasn't changed (except for the
exact syntax of catching errors). I was able to take a moosic
configuration directory generated with the Python 2 daemon and load it
with the Python 3 daemon, and it seems to work without issues.

Two: it looks like either I was wrong in remembering that the Py2 daemon
and Py3 client don't talk to one another cleanly, or I managed to fix
the problem before and forgot about it. I accidentally invoked the Py3
client in a way which seems to have made it interact with the Py2
daemon, and aside from one text-encoding error message which might be
cosmetic, it seems to have worked fine - including adding a file to the
existing daemon's playlist in a way which the existing daemon was able
to parse and handle without issues.

So my previously mentioned upgrade-scenario concerns may indeed not be a
problem in practice.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Bug#977983: Should not build-depend on composer

[David Prévot]

Package: phpmyadmin
Version: 4:4.9.7+dfsg1-1
Severity: normal
X-Debbugs-Cc: pkg-php-p...@lists.alioth.debian.org

phpmyadmin build-depends on composer but does not use it AFAICT. Please,
drop the build-dependency on composer.

Regards

David


signature.asc
Description: PGP signature

Bug#977957: spamassassin: installing sa-compile during debian installation (custom) fails on chmod

[Noah Meyerhans]

Control: severity -1 wishlist

> We have included spamassassin in a custom installer. During installation 
> 'start-stop-daemon' is not available (fake)
> sa-compile relies on start-stop-daemon to be working (sa-compile.postinst 
> line 17-19)
> or it wil error trying to 'chmod' a directory which does not exist. 
> (sa-compile.postinst line 23-24).
> This was changed with commit 446572164382f2ab4e6781ba751b6ca90364da9

start-stop-daemon is provided by dpkg, which is Priority: required.
Thus, the assumption that it is available during the postinst execution
is a valid one.  As stated in the policy document, "Removing a required
package may cause your system to become totally broken"  If you
choose to break your system in this way, that's fine, but it's not a bug
in spamassassin.

My recommendation is that you don't break dpkg in your custom installer.
This can probably be fixed in spamassassin, and it's probably not too
difficult to do, so I'll leave this open with a wishlist severity.
However, it's very likely that you'll find other packages that also
break when you remove (parts of) required packages.

noah

Bug#977901: chromium: Inconsistent SEGV

[Michel Le Bihan]

Hello,

I made
https://salsa.debian.org/mimi8/chromium/-/commit/6d21c52698147ca072d223e4e6c2854053319531
and still am waiting for it to build. Is it OK?

Michel Le Bihan

Le mercredi 23 décembre 2020 à 14:13 -0600, Boyd Stephen Smith Jr. a
écrit :
> On Wednesday, December 23, 2020 4:30:48 AM CST Boyd Stephen Smith Jr.
> wrote:
> > On Wednesday, December 23, 2020 4:19:43 AM CST Michel Le Bihan
> > wrote:
> > > The Debian patch for #963548
> > > https://salsa.debian.org/mimi8/chromium/-/blob/ece23b4ca107cd968ac9a40
> > > 9f
> > > 40eb11edf8a0266/debian/patches/fixes/serviceworker-double-
> > > destruction.pat
> > > ch is clearly in upstream 87.0.4280.88:
> > > https://source.chromium.org/chromium/chromium/src/+/refs/tags/87.0.4280.88
> > > :c
> > > ontent/browser/service_worker/service_worker_container_host.cc;l=
> > > 671-679
> > 
> > Different destructor.  The old patch is for
> > ServiceWorkerObjectHost, but we
> > need a new patch for ServiceWorker*Registration*ObjectHost.
> 
> In particular, just above where you linked to, at line 629 (https://
> source.chromium.org/chromium/chromium/src/+/refs/tags/87.0.4280.88:co
> ntent/
> browser/service_worker/service_worker_container_host.cc;l=629) is the
> crashing 
> line.
> 
> The fix for the back trace I finally got is to change that line like
> so: 
> https://source.chromium.org/chromium/chromium/src/+/
> f27ad210062f61d06eb782214ee4fc8c19a1725b:content/browser/service_work
> er/
> service_worker_container_host.cc;l=623-647
> 
> The f27ed21 commit does contain the fix for #963548, but lower down
> at line 
> 689: https://source.chromium.org/chromium/chromium/src/+/
> f27ad210062f61d06eb782214ee4fc8c19a1725b:content/browser/service_work
> er/
> service_worker_container_host.cc;l=689-697
> 

Bug#977901: chromium: Inconsistent SEGV

[Boyd Stephen Smith Jr.]

On Wednesday, December 23, 2020 4:30:48 AM CST Boyd Stephen Smith Jr. wrote:
> On Wednesday, December 23, 2020 4:19:43 AM CST Michel Le Bihan wrote:
> > The Debian patch for #963548
> > https://salsa.debian.org/mimi8/chromium/-/blob/ece23b4ca107cd968ac9a40
> > 9f
> > 40eb11edf8a0266/debian/patches/fixes/serviceworker-double-destruction.pat
> > ch is clearly in upstream 87.0.4280.88:
> > https://source.chromium.org/chromium/chromium/src/+/refs/tags/87.0.4280.88
> > :c
> > ontent/browser/service_worker/service_worker_container_host.cc;l=671-679
>
> Different destructor.  The old patch is for ServiceWorkerObjectHost, but we
> need a new patch for ServiceWorker*Registration*ObjectHost.

In particular, just above where you linked to, at line 629 (https://
source.chromium.org/chromium/chromium/src/+/refs/tags/87.0.4280.88:content/
browser/service_worker/service_worker_container_host.cc;l=629) is the crashing 
line.

The fix for the back trace I finally got is to change that line like so: 
https://source.chromium.org/chromium/chromium/src/+/
f27ad210062f61d06eb782214ee4fc8c19a1725b:content/browser/service_worker/
service_worker_container_host.cc;l=623-647

The f27ed21 commit does contain the fix for #963548, but lower down at line 
689: https://source.chromium.org/chromium/chromium/src/+/
f27ad210062f61d06eb782214ee4fc8c19a1725b:content/browser/service_worker/
service_worker_container_host.cc;l=689-697

-- 
Boyd Stephen Smith Jr.   ,= ,-_-. =.
b...@iguanasuicide.net   ((_/)o o(\_))
Twitter: @DaTwinkDaddy   `-'(. .)`-'
http://iguanasuicide.net/\_/


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

Bug#977982: mirrors.ptisp.pt: 403 Forbidden error

[Sebastian Haderecker]

Package: mirrors
Severity: normal
User: mirr...@packages.debian.org
Usertags: mirror-problem

Hi,

The mirror mirrors.ptisp.pt throws a 403 error.

This results in the mirror being unavailable during updates or package 
installations:

E: Failed to fetch http://mirrors.ptisp.pt/debian/dists/stable/InRelease 403 
Forbidden [IP: 2a00:1650:1000:0:8fc7:3f4f:8629:b7fc 80]
E: The repository 'http://mirrors.ptisp.pt/debian stable InRelease' is not 
signed.

It seems like the "InRelease", "Release" and "Release.gpg" files all give the 
403 error.
This is not only for dists/stable, I also checked in dists/buster and 
dists/stretch and a couple more.
They all give the same 403 error, so this issue affects almost every dist that 
is on the mirror.

Can you please fix the access to those files.

Thanks,
Sebastian

Bug#977981: jruby should probably not have /usr/lib/ruby/vendor_ruby in its LOAD_PATH

[Louis-Philippe Véronneau]

Package: jruby
Severity: important
Version: 9.1.17.0-3

Dear maintainers,

The current version of jruby in Debian is compatible with ruby 2.3,
while Debian runs ruby 2.7. This means a lot of the ruby gems packaged
in Debian will not work with jruby.

A good example of this is bug #977979.

Worse, this cannot simply be fixed by updating to the latest upstream
version, as it currently only supports ruby 2.5. Apparently, the ruby
team plans to move to 3.x after Bullseye. I don't think it's realistic
to think jruby can keep up with the ruby version in Debian.

It is my opinion /usr/lib/ruby/vendor_ruby should probably not be added
to the jruby LOAD_PATH, as it is currently done via path
0007-Add-usr-lib-ruby-vendor-ruby-to-load-path.

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#977894: gui is broken, python3-xdo

[Joey Hess]

Jameson Graef Rollins wrote:
> Hey, Joey.  Sorry you're having trouble.  What is the error when you try
> to execute "impass gui"?  It should pop up a small context dialog
> window.  That winodw is not appearing?  Is there a python exception?

No gui. All I see it the output I pasted.

> What does your environment look like?  You don't happen to be running
> wayland, do you?

No, X with xfce and xmonad.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#977977: libreoffice: a large part of the window appears off-screen

[Rene Engelhard]

retitle 977977 libreoffice: a large part of the window might appear
off-screen if resultion/monitor config changes

Hi,

Am 23.12.20 um 20:34 schrieb Vincent Lefevre:
> On 2020-12-23 19:53:09 +0100, Rene Engelhard wrote:
>> Am 23.12.20 um 18:59 schrieb Vincent Lefevre:
>>> A large part of the window appears off-screen, including the menu
>>> and window controls. Basically, the only thing I can do is to type
>>> Ctrl-Q to quit Libreoffice!
>> And why is that? Obviously works on one-monitor setups.
> My machine is a laptop, sometimes with only its screen, sometimes
> with 2 external 4K monitors, depending on where I am.
Aha. I have none of these. (Besides that my laptop has a sane graphics
card.)
>> And given you apparently use the nvidia driver (see below) No way to
>> reproduce this here.
> The nouveau driver is unusable with an external monitor (even when
> used in mirror mode). The nvidia driver is the only solution with
> such a configuration.

In Germany we have an idiom amongst IT people: "Augen auf beim
Hardwarekauf" (which roughly translates to

"open your eyes when buying hardware"). You got into this situation
yourself.


> I did not set anything special. I rarely use LibreOffice (only when I
> need to). And I don't think I have ever changed anything explicitly in
> the preferences. In short, I let LibreOffice handle the config on its
> own.

OK, but I believe it saves it's dimensions when closed, I at laest get
this when williy-nilly dragging the window.

It probably also saves the location..


This would explain your problem. I don't think there is a senseful way
to fix this though. Always start maximized (and automatically on the
current monitor/display)? Probably not.

In any case, this is something for upstream - not Debian to change. And
for that there's reportbug mentioning that upstream bugs should go upstream.


> That's the default for unstable, except that I added experimental. 

No, it's not.

Adding stable and testing is not. (unstable-debug is understandable, but
also not default.)

> Currently everything has been installed
> from unstable
Sure.
>  (or testing or stable, when this was the latest package
> version).
But there's no need for stable or testing here.
>>> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
>>> TAINT_UNSIGNED_MODULE
>> Try with a sane system?
> AFAIK, that's just due to the nvidia driver, for the reason explained
> above.

Which proves my point. (I do not care about nvidia.)


Regards,


Rene

Bug#976493: ruby-psych blocked by jruby

[Louis-Philippe Véronneau]

block 976493 by 977979
thanks

This is caused by a bug in jruby and can probably by fixed by exporting
the DEBIAN_DISABLE_RUBYGEMS_INTEGRATION environment variable in d/rules.

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#977980: RFS: budgie-desktop-view/1.1-1 -- Desktop Icons for the Budgie-Desktop

[David Mohammed]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "budgie-desktop-view":

 * Package name: budgie-desktop-view
   Version : 1.1-1
   Upstream Author : Josh Strobl 
 * URL : https://github.com/getsolus/budgie-desktop-view
 * License : Apache-2.0
 * Vcs :
https://github.com/UbuntuBudgie/budgie-desktop-view/tree/debian
   Section : misc

It builds those binary packages:

  budgie-desktop-view - Desktop Icons for the Budgie-Desktop

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

  https://mentors.debian.net/package/budgie-desktop-view/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/b/budgie-desktop-view/budgie-desktop-view_1.1-1.dsc

Notes:
I am the Debian Maintainer of budgie-desktop & budgie-extras (plus
several other packages).  This package Is currently in Testing.

I have spot checked the diff between the previous version 1.0.2 and
this to to ensure they contain no changes to the copyright header.

I have sbuild this package against unstable and all information &
warning lintian issues have been resolved.  The build has been tested
and confirmed working as per the upstream release note - a simplified
version of which is described below.

In addition to sponsoring this package update - if appropriate I would like
to continue maintainership of this package
(assuming that it is acceptable to Debian) in a similar manner as my
current maintainership packages (dak fossfree...@ubuntu.com)

Changes since the last upload:

 budgie-desktop-view (1.1-1) unstable; urgency=medium
 .
   * New upstream release
 - Implemented Drag & Drop support.
 - Implemented keyboard-based navigation using arrow keys.
 - Implemented right-click Move to Trash option for items where applicable.
 - Implemented a max-thumbnail-size option to increase the size of the files
   to make thumbnails for. Changed default from 1MB to 10MB.
 - Fix segfault when failing to acquire mount or volume UUIDs.
 - Implemented dismissing of Raven when clicking on Budgie Desktop View.
   * Packaging Changes:
 - control: fix spurious character in vcs-git
 - regenerate man-page without texinfo via help2man --no-info

Regards,
-- 
  David Mohammed

Bug#977894: gui is broken, python3-xdo

[Joey Hess]

Daniel Kahn Gillmor wrote:
> this is odd, and it makes me think that there's some python module path
> failure happening.  if it can't find the system xdo, maybe it also can't
> find the gobject introspection libraries that are used to interface with
> GTK?
> 
> is it possible that this is being run from within some sort of python
> virtualenv?

No, definitely not. It is possible something got broken on disk (SSH) somehow.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#926280: Don't bundle rubygems

[Louis-Philippe Véronneau]

On Tue, 02 Apr 2019 22:23:13 +0200 Moritz Muehlenhoff 
wrote:
> Package: jruby
> Severity: important
> 
> (This bug isn't really actionable yet, as it depends on #926278 getting fixed
> in src:ruby2.5)
> 
> Please don't use the bundled rubygems any longer, but instead a copy shared
> with the C-based Ruby interpreter.
> 
> Given that most of the security issues in the C-based interpreter don't
> affect Jruby (apart from the rubygems) this will considerably reduce the
> overhead for keeping jruby updated in stable/oldstable.
> 
> I spoke to upstream (CCed) earlier and they confirmed that jruby bundles
> the rubygems unmodified, so that should not cause any run time issues.

The latest upstream release of jruby is only compatible with ruby 2.5
(see [1] for the progress on 2.7), so I don't think this is feasible.

The ruby team is planning on uploading ruby 3.x after the bullseye
freeze and I don't believe jruby can keep up.

[1]: https://github.com/jruby/jruby/issues/6464

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#977977: libreoffice: a large part of the window appears off-screen

[Vincent Lefevre]

On 2020-12-23 19:53:09 +0100, Rene Engelhard wrote:
> Am 23.12.20 um 18:59 schrieb Vincent Lefevre:
> > A large part of the window appears off-screen, including the menu
> > and window controls. Basically, the only thing I can do is to type
> > Ctrl-Q to quit Libreoffice!
> 
> And why is that? Obviously works on one-monitor setups.

My machine is a laptop, sometimes with only its screen, sometimes
with 2 external 4K monitors, depending on where I am.

> And given you apparently use the nvidia driver (see below) No way to
> reproduce this here.

The nouveau driver is unusable with an external monitor (even when
used in mirror mode). The nvidia driver is the only solution with
such a configuration.

> > As a workaround, I had to remove my configs (~/.config/libreoffice).
> 
> And then it works? What did you set specifically in  that profile
> which might got reset and made it working? Did you change something
> inbetween which might make LO remember where it was and saved it
> somehow?

I did not set anything special. I rarely use LibreOffice (only when I
need to). And I don't think I have ever changed anything explicitly in
the preferences. In short, I let LibreOffice handle the config on its
own.

> > Debian Release: bullseye/sid
> >   APT prefers unstable-debug
> >   APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
> > 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
> 
> I never will understand the sense in this configuration. Anything you
> will get is from unstable anyway.

That's the default for unstable, except that I added experimental. But
I almost never install packages from experimental, just when I'm asked
to test particular packages. Currently everything has been installed
from unstable (or testing or stable, when this was the latest package
version).

> > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
> > TAINT_UNSIGNED_MODULE
> 
> Try with a sane system?

AFAIK, that's just due to the nvidia driver, for the reason explained
above.

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

Bug#977979: jruby fails to run without declaring the DEBIAN_DISABLE_RUBYGEMS_INTEGRATION environment variable

[Louis-Philippe Véronneau]

Package: jruby
Version: 9.1.17.0-3
Severity: grave

Dear maintainers,

It seems jruby fails to run without declaring the
DEBIAN_DISABLE_RUBYGEMS_INTEGRATION environment variable:

jruby -e "puts 'Hello World'"
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by jnr.posix.JavaLibCHelper$ReflectiveAccess 
to method sun.nio.ch.SelChImpl.getFD()
WARNING: Please consider reporting this to the maintainers of 
jnr.posix.JavaLibCHelper$ReflectiveAccess
WARNING: Use --illegal-access=warn to enable warnings of further illegal 
reflective access operations
WARNING: All illegal access operations will be denied in a future release
NameError: undefined method `default_specifications_dir' for class 
`#'
  singleton class at 
/usr/lib/ruby/vendor_ruby/rubygems/defaults/operating_system.rb:84
at 
/usr/lib/ruby/vendor_ruby/rubygems/defaults/operating_system.rb:58
  require at org/jruby/RubyKernel.java:956
at /usr/share/jruby/lib/ruby/stdlib/rubygems.rb:1
  require at org/jruby/RubyKernel.java:956
at /usr/share/jruby/lib/ruby/stdlib/rubygems.rb:1347
 load at org/jruby/RubyKernel.java:974
at uri:classloader:/jruby/kernel/gem_prelude.rb:1

Any value for DEBIAN_DISABLE_RUBYGEMS_INTEGRATION makes it work again:

DEBIAN_DISABLE_RUBYGEMS_INTEGRATION=hamburger jruby -e "puts 'Hello World'"
Hello World

Talking with Antonio Terceiro, it seems the underlying problem comes
from the current jruby version in Debian bundling an old version of
rubygems, that isn't compatible with the code in
/usr/lib/ruby/vendor_ruby/rubygems/defaults/operating_system.rb.

Setting DEBIAN_DISABLE_RUBYGEMS_INTEGRATION seems like a cheap
trick, as ruby gems in debian are 2.7 compatible, and our
jruby is 2.3 compatible.

Really, jruby shouldn't load gems from /usr/lib/ruby/vendor_ruby
(but I'll open another bug about this).

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





OpenPGP_signature
Description: OpenPGP digital signature

Bug#977978: buster-pu: package libdatetime-timezone-perl/1:2.23-1+2020e

[gregor herrmann]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: debian-p...@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I've uploaded libdatetime-timezone-perl/1:2.23-1+2020e to buster.
It includes the data from tzdata 2020e as a quilt patch.

The changes are:

Volgograd switches to Moscow time on 2020-12-27 at 02:00.


Attached is a manually stripped down debdiff.


Cheers,
gregor

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAl/jmetfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgZycg/8CKshOE5vOjZFss9Y9gJkur9p9CpbsYIybcqmkI0EnCfC1ZwfF/kLrcJd
RLEF6Z4b8JiAEdLPXy51YpWHuOA50kNFG07vFF27bjlY+dIpimomIDxbfKP+LhuF
RfD938pJYjpg2vXI8KeDeFWAJTRHJ1Ma9PBw+3tE0yJlFDvq+N+IPFsA36TbF/EH
l1Ps5RUvQD+ieV+8oNBhBhGovZvB9h61IBNLniKhoFpxaYWCiugscDdUzzla+Y3q
7s7UBUSBIMNkeQlkKlqD3tXxDx40Skg3djKnyM5LQpnAzlreD3EpXfhZbFFJIWxM
Pdqw6WJTlsQqgORE8Dci+IdRRhDB/yThCBnhmA0mmLiYPDVuxrBaNsv1xqqQgTIv
iIwZUmQKu/3Fvp9Ng8NuFAdm+Nr36lIbv613o9VU17tey/jRFyPIa1OA5v0NTzEx
7/G+yNq6mMOdWVHbeB8wggfQ+OEUpgut0sx+2u5EHJz0yg0JakQp4xgTuPWjmQQg
+8/EFl1tpD0uj/1Lf7JmFBapXSiwdoRN4bghJNbB/o76rmatrmdG5oS72rKy4Pko
A5oApXAlok629H0RbOm1CqI2eC4MhNazw5+qjlpMUFs4rLD6t0iPuOBo0vPZIhmE
xPTnQN9R2XUbXFi0D7wirAq5ebBZAV88uAlEObqxH9Jks8W3yl0=
=k//j
-END PGP SIGNATURE-
diff -Nru libdatetime-timezone-perl-2.23/debian/changelog 
libdatetime-timezone-perl-2.23/debian/changelog
--- libdatetime-timezone-perl-2.23/debian/changelog 2020-10-23 
02:37:03.0 +0200
+++ libdatetime-timezone-perl-2.23/debian/changelog 2020-12-23 
20:17:40.0 +0100
@@ -1,3 +1,10 @@
+libdatetime-timezone-perl (1:2.23-1+2020e) buster; urgency=medium
+
+  * Update to Olson database version 2020e.
+This update includes contemporary changes for Russia (Volograd).
+
+ -- gregor herrmann   Wed, 23 Dec 2020 20:17:40 +0100
+
 libdatetime-timezone-perl (1:2.23-1+2020d) buster; urgency=medium
 
   * Update to Olson database version 2020d.
diff -Nru libdatetime-timezone-perl-2.23/debian/patches/olson-2020e 
libdatetime-timezone-perl-2.23/debian/patches/olson-2020e
--- libdatetime-timezone-perl-2.23/debian/patches/olson-2020e   1970-01-01 
01:00:00.0 +0100
+++ libdatetime-timezone-perl-2.23/debian/patches/olson-2020e   2020-12-23 
20:17:40.0 +0100
@@ -0,0 +1,14690 @@
+Description: Update to Olson DB 2020e
+Origin: vendor
+Author: gregor herrmann 
+Last-Update: 2020-12-23
+
+--- a/lib/DateTime/TimeZone/Africa/Abidjan.pm
 b/lib/DateTime/TimeZone/Africa/Abidjan.pm
+@@ -3,7 +3,7 @@
+ # DateTime::TimeZone module distribution in the tools/ directory
+ 
+ #
+-# Generated from debian/tzdata/africa.  Olson data version 2020d
++# Generated from debian/tzdata/africa.  Olson data version 2020e
+ #
+ # Do not edit this file directly.
+ #
+@@ -43,7 +43,7 @@
+ ],
+ ];
+ 
+-sub olson_version {'2020d'}
++sub olson_version {'2020e'}
+ 
+ sub has_dst_changes {0}
+ 
+--- a/lib/DateTime/TimeZone/Europe/Volgograd.pm
 b/lib/DateTime/TimeZone/Europe/Volgograd.pm
+@@ -3,7 +3,7 @@
+ # DateTime::TimeZone module distribution in the tools/ directory
+ 
+ #
+-# Generated from debian/tzdata/europe.  Olson data version 2020d
++# Generated from debian/tzdata/europe.  Olson data version 2020e
+ #
+ # Do not edit this file directly.
+ #
+@@ -610,16 +610,25 @@
+ ],
+ [
+ 63676364400, #utc_start 2018-10-27 23:00:00 (Sat)
+-DateTime::TimeZone::INFINITY, #  utc_end
++63744703200, #  utc_end 2020-12-26 22:00:00 (Sat)
+ 63676378800, #  local_start 2018-10-28 03:00:00 (Sun)
+-DateTime::TimeZone::INFINITY, #local_end
++63744717600, #local_end 2020-12-27 02:00:00 (Sun)
+ 14400,
+ 0,
+ '+04',
+ ],
++[
++63744703200, #utc_start 2020-12-26 22:00:00 (Sat)
++DateTime::TimeZone::INFINITY, #  utc_end
++63744714000, #  local_start 2020-12-27 01:00:00 (Sun)
++DateTime::TimeZone::INFINITY, #local_end
++10800,
++0,
++'+03',
++],
+ ];
+ 
+-sub olson_version {'2020d'}
++sub olson_version {'2020e'}
+ 
+ sub has_dst_changes {29}
+ 
diff -Nru libdatetime-timezone-perl-2.23/debian/patches/series 
libdatetime-timezone-perl-2.23/debian/patches/series
--- libdatetime-timezone-perl-2.23/debian/patches/series2020-10-23 
02:37:03.0 +0200
+++ libdatetime-timezone-perl-2.23/debian/patches/series2020-12-23 
20:17:40.0 +0100
@@ -5,3 +5,4 @@
 olson-2020b
 olson-2020c
 olson-2020d
+olson-2020e

Bug#966555: tuned: please update the package to a recent version

[Evgeni Golov]

Yeah, I think I added gustavo to uploaders because of the ITP and our 
discussions before the initial upload.

Gustavo, if you want, I can drop you in the 2.15 upload I am preparing?

On December 23, 2020 6:49:40 PM UTC, Nicholas D Steeves  
wrote:
>Hi,
>
>gustavo panizzo  writes:
>
>> Hello Nicholas
>>
>> On Fri, Dec 04, 2020 at 11:26:00AM -0500, Nicholas D Steeves wrote:
>>>Dear Evgeni and Gustavo,
>> [snip]
>>>
>>>Would you please consider updating the package, or orphaning it so someone
>>>will see the wnpp alert and can adopt it without delay?  As you prefer!
>>
>> my only involvement with tuned was filing the initial ITP bug
>>
>
>That's odd, you're listed as an Uploader:
>https://salsa.debian.org/debian/tuned/-/blob/debian/unstable/debian/control#L5
>
>> I offer to perform an upload before the freeze and orphan
>> the package after the release for someone else to pick it up, unless
>> someone else is doing it already/wants to do it/has a better idea.
>>
>>
>
>Since you're not periodically working on the package, have you
>considered dropping yourself from Uploaders?  Evgeni are you ok with
>being the only Maintainer?  If you're looking for more active
>comaintenance, these days it seems like teams are more active than the
>debian/old-collab-maint group.
>
>It looks like v2.15 was closer to release than expected, and appears to
>have been released since this bug was closed.  Oh, and regarding
>salvaging, the clock was reset by the 2.14 upload, so no need to worry
>about that :-)
>
>Best,
>Nicholas

Bug#977857: libreoffice-common: On Wayland, it doesn't work without the xwayland pkg but installation does not pull xwayland as a dependency

[Rene Engelhard]

Hi,

Am 22.12.20 um 01:07 schrieb jman:
> In order to make Libreoffice work, the package `xwayland` should be installed 
> as a dependency.
It doesn't scale to add a xwayland dependency on every package doing X
operations.

> Unless I'm wrong, I believe the real issue is that Libreoffice does not work 
> on a pure Wayland
> installation, but this fact is not very clear to the user.

Is this common? I mean this would haven been reported far earlier/in
many more cases? Isn't the "GNOME" Session defaulting to wayland nowadays?

rene@frodo:~$ grep-dctrl -FRecommends xwayland
/var/lib/apt/lists/deb.debian.org_debian_dists_sid_main_binary-amd64_Packages
-sPackage
Package: mir-demos
Package: mir-test-tools
rene@frodo:~$ grep-dctrl -FDepends xwayland
/var/lib/apt/lists/deb.debian.org_debian_dists_sid_main_binary-amd64_Packages
-sPackage
Package: gnome-session-bin
Package: kwin-wayland
rene@frodo:~$

Ah, both GNOME and KDE depend on xwayland. Which DE/WM do you use?

>  I've tried searching for related issue on
> the Libreoffice buttracker but found none.

There is https://bugs.documentfoundation.org/show_bug.cgi?id=121275 but
that one's closed and didn't (apparently) even get a console output.

And the fix was using gtk3, which you did...


(Wrt your other mail, that package list is so obviously incomplete - and
we TTBOMK don't patch any place which should affect this. What we do
differ in is using system-libraries where possible - so one of these
might affect this?=

Regards,


Rene

Bug#977977: libreoffice: a large part of the window appears off-screen

[Rene Engelhard]

tag 977977 + unreproducible

tag 977977 + moreinfo

thanks

Hi,


Am 23.12.20 um 18:59 schrieb Vincent Lefevre:

> Severity: important

Sigh.

> A large part of the window appears off-screen, including the menu
> and window controls. Basically, the only thing I can do is to type
> Ctrl-Q to quit Libreoffice!

And why is that? Obviously works on one-monitor setups.

And given you apparently use the nvidia driver (see below) No way to
reproduce this here.

> As a workaround, I had to remove my configs (~/.config/libreoffice).

And then it works? What did you set specifically in  that profile which
might got reset and made it working? Did you change something inbetween
which might make LO remember where it was and saved it somehow?

> Debian Release: bullseye/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
> 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')

I never will understand the sense in this configuration. Anything you
will get is from unstable anyway.


> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
> TAINT_UNSIGNED_MODULE

Try with a sane system?

Regards,


Rene

Bug#966555: tuned: please update the package to a recent version

[Nicholas D Steeves]

Hi,

gustavo panizzo  writes:

> Hello Nicholas
>
> On Fri, Dec 04, 2020 at 11:26:00AM -0500, Nicholas D Steeves wrote:
>>Dear Evgeni and Gustavo,
> [snip]
>>
>>Would you please consider updating the package, or orphaning it so someone
>>will see the wnpp alert and can adopt it without delay?  As you prefer!
>
> my only involvement with tuned was filing the initial ITP bug
>

That's odd, you're listed as an Uploader:
https://salsa.debian.org/debian/tuned/-/blob/debian/unstable/debian/control#L5

> I offer to perform an upload before the freeze and orphan
> the package after the release for someone else to pick it up, unless
> someone else is doing it already/wants to do it/has a better idea.
>
>

Since you're not periodically working on the package, have you
considered dropping yourself from Uploaders?  Evgeni are you ok with
being the only Maintainer?  If you're looking for more active
comaintenance, these days it seems like teams are more active than the
debian/old-collab-maint group.

It looks like v2.15 was closer to release than expected, and appears to
have been released since this bug was closed.  Oh, and regarding
salvaging, the clock was reset by the 2.14 upload, so no need to worry
about that :-)

Best,
Nicholas


signature.asc
Description: PGP signature

Bug#966555: tuned: please update the package to a recent version

[Nicholas D Steeves]

Hi Evgeni,

Evgeni Golov  writes:

> I can also try to do an upload (or we together, I don't mind either way).
>
> I thought the "debian" group on salsa was supposed to mean "collab maint" aka 
> "everyone can just upload"?
>

AFAICT there are still a few different views on this, and the closest
thing to consensus I've been heard of is that all DDs are free to commit
to repos in "debian", but anyone who wants to upload should ask first,
and then wait for an ACK from the maintainer before uploading, unless
the maintainer is LowNMU.  Also DMs can't commit to the repo, which may
or may not be intended (IIRC collab-maint was less restrictive for DMs).

Best,
Nicholas


signature.asc
Description: PGP signature

Bug#966555: closed by Debian FTP Masters (reply to Evgeni Golov ) (Bug#966555: fixed in tuned 2.14.0-1)

[Nicholas D Steeves]

Hi Evgeni,

"Debian Bug Tracking System"  writes:

> We believe that the bug you reported is fixed in the latest version of
> tuned, which is due to be installed in the Debian FTP archive.
>
> A summary of the changes between this version and the previous one is
> attached.
>
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 966...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
>
> Debian distribution maintenance software
> pp.
> Evgeni Golov  (supplier of updated tuned package)
>
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
>

Thank you for the quick upload!

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#977977: libreoffice: a large part of the window appears off-screen

[Vincent Lefevre]

Package: libreoffice
Version: 1:7.0.4~rc2-1+b1
Severity: important

A large part of the window appears off-screen, including the menu
and window controls. Basically, the only thing I can do is to type
Ctrl-Q to quit Libreoffice!

As a workaround, I had to remove my configs (~/.config/libreoffice).

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

Kernel: Linux 5.9.0-4-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=C.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 libreoffice depends on:
ii  libreoffice-base1:7.0.4~rc2-1+b1
ii  libreoffice-calc1:7.0.4~rc2-1+b1
ii  libreoffice-core1:7.0.4~rc2-1+b1
ii  libreoffice-draw1:7.0.4~rc2-1+b1
ii  libreoffice-impress 1:7.0.4~rc2-1+b1
ii  libreoffice-math1:7.0.4~rc2-1+b1
ii  libreoffice-report-builder-bin  1:7.0.4~rc2-1+b1
ii  libreoffice-writer  1:7.0.4~rc2-1+b1
ii  python3-uno 1:7.0.4~rc2-1+b1

Versions of packages libreoffice recommends:
ii  fonts-crosextra-caladea 20130214-2.1
ii  fonts-crosextra-carlito 20130920-1.1
ii  fonts-dejavu2.37-2
ii  fonts-liberation1:1.07.4-11
ii  fonts-liberation2   2.1.1-1
ii  fonts-linuxlibertine5.3.0-4
ii  fonts-noto-core 20201109-1
ii  fonts-noto-extra20201109-1
ii  fonts-noto-mono 20201109-1
ii  fonts-noto-ui-core  20201109-1
ii  fonts-sil-gentium-basic 1.102-1.1
ii  libreoffice-java-common 1:7.0.4~rc2-1
ii  libreoffice-nlpsolver   0.9+LibO7.0.4~rc2-1
ii  libreoffice-report-builder  1:7.0.4~rc2-1
ii  libreoffice-script-provider-bsh 1:7.0.4~rc2-1
ii  libreoffice-script-provider-js  1:7.0.4~rc2-1
ii  libreoffice-script-provider-python  1:7.0.4~rc2-1
ii  libreoffice-sdbc-mysql  1:7.0.4~rc2-1+b1
ii  libreoffice-sdbc-postgresql 1:7.0.4~rc2-1+b1
ii  libreoffice-wiki-publisher  1.2.0+LibO7.0.4~rc2-1

Versions of packages libreoffice suggests:
ii  cups-bsd2.3.3op1-3
ii  default-jre [java8-runtime] 2:1.11-72
ii  firefox 84.0-3
hi  firefox-esr 52.9.0esr-1~deb9u1
ii  ghostscript 9.53.3~dfsg-5
ii  gnupg   2.2.20-1
pn  gpa 
ii  gstreamer1.0-libav  1.18.2-1
pn  gstreamer1.0-plugins-bad
ii  gstreamer1.0-plugins-base   1.18.2-1
ii  gstreamer1.0-plugins-good   1.18.2-1
pn  gstreamer1.0-plugins-ugly   
ii  hunspell-en-us [hunspell-dictionary]1:2019.10.06-1
ii  hunspell-fr-classical [hunspell-dictionary] 1:7.0-1
pn  hyphen-hyphenation-patterns 
ii  imagemagick 8:6.9.11.24+dfsg-1+b2
ii  imagemagick-6.q16 [imagemagick] 8:6.9.11.24+dfsg-1+b2
ii  libgl1  1.3.2-1
pn  libofficebean-java  
pn  libreoffice-gnome | libreoffice-plasma  
pn  libreoffice-grammarcheck
pn  libreoffice-help
pn  libreoffice-l10n
pn  libreoffice-librelogo   
ii  libsane11.0.31-4
ii  libxrender1 1:0.9.10-1
pn  myspell-dictionary  
pn  mythes-thesaurus
pn  openclipart2-libreoffice | openclipart-libreoffice  
ii  openjdk-11-jre [java8-runtime]  11.0.9.1+1-1
ii  pstoedit3.75-1
ii  unixodbc2.3.6-0.1+b1

Versions of packages libreoffice-core depends on:
ii  fontconfig  2.13.1-4.2
ii  fonts-opensymbol2:102.11+LibO7.0.4~rc2-1
ii  libboost-locale1.74.0   1.74.0-5
ii  libc6   2.31-5
ii  libcairo2   1.16.0-4
ii  libclucene-contribs1v5  2.3.3.4+dfsg-1+b1
ii  libclucene-core1v5  2.3.3.4+dfsg-1+b1
ii  libcmis-0.5-5v5 

Bug#977976: lintian: "unknown-runtime-tests-field Architecture"

[Christoph Biedl]

Package: lintian
Version: 2.104.0
Severity: normal

Dear Maintainer,

tl;dr: lintian does not consider Architecture: a valid header field
in debian/tests/control, and I think that's not correct.

Full story: Creating an autopkgtest that requires systemd for execution,
I wanted to be extra-sure this will not cause trouble if ever someone
runs autopkgtest on !linux. So, after checking the specification at[1],
I wrote

Tests: run-testsuite
Depends: @,
systemd,
Architecture: linux-any

and lintian replied

P: (...) source: unknown-runtime-tests-field Architecture in line 4

So in my opionion, Architecture: (and also Classes:) should be added to
testsuite/known-fields.

Regards,

Christoph

[1] 
https://salsa.debian.org/ci-team/autopkgtest/raw/master/doc/README.package-tests.rst

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

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

Versions of packages lintian depends on:
ii  binutils2.35.1-5
ii  bzip2   1.0.8-4
ii  diffstat1.63-1
ii  dpkg1.20.5
ii  dpkg-dev1.20.5
ii  file1:5.39-3
ii  gettext 0.19.8.1-10
ii  gpg 2.2.20-1
ii  intltool-debian 0.35.0+20060710.5
ii  libapt-pkg-perl 0.1.36+b4
ii  libarchive-zip-perl 1.68-1
ii  libcapture-tiny-perl0.48-1
ii  libclass-xsaccessor-perl1.19-3+b6
ii  libclone-perl   0.45-1+b1
ii  libconfig-tiny-perl 2.24-1
ii  libcpanel-json-xs-perl  4.25-1+b1
ii  libdata-dpath-perl  0.58-1
ii  libdata-validate-domain-perl0.10-1
ii  libdevel-size-perl  0.83-1+b2
ii  libdpkg-perl1.20.5
ii  libemail-address-xs-perl1.04-1+b3
ii  libfile-basedir-perl0.08-1
ii  libfile-find-rule-perl  0.34-1
ii  libfont-ttf-perl1.06-1
ii  libhtml-html5-entities-perl 0.004-1
ii  libipc-run3-perl0.048-2
ii  libjson-maybexs-perl1.004003-1
ii  liblist-compare-perl0.55-1
ii  liblist-moreutils-perl  0.430-2
ii  liblist-utilsby-perl0.11-1
ii  libmoo-perl 2.004004-1
ii  libmoox-aliases-perl0.001006-1
ii  libnamespace-clean-perl 0.27-1
ii  libpath-tiny-perl   0.114-1
ii  libperlio-gzip-perl 0.19-1+b7
ii  libproc-processtable-perl   0.59-2+b1
ii  libsereal-decoder-perl  4.018+ds-1+b1
ii  libsereal-encoder-perl  4.018+ds-1+b1
ii  libtext-glob-perl   0.11-1
ii  libtext-levenshteinxs-perl  0.03-4+b8
ii  libtext-markdown-discount-perl  0.12-1+b1
ii  libtext-xslate-perl 3.5.8-1+b1
ii  libtime-duration-perl   1.21-1
ii  libtime-moment-perl 0.44-1+b3
ii  libtimedate-perl2.3300-1
ii  libtry-tiny-perl0.30-1
ii  libtype-tiny-perl   1.012000-1
ii  libunicode-utf8-perl0.62-1+b2
ii  liburi-perl 5.05-1
ii  libxml-libxml-perl  2.0134+dfsg-2+b1
ii  libyaml-libyaml-perl0.82+repack-1+b1
ii  lzip1.21-8
ii  lzop1.04-2
ii  man-db  2.9.3-2
ii  patchutils  0.4.2-1
ii  perl [libdigest-sha-perl]   5.32.0-6
ii  t1utils 1.41-4
ii  unzip   6.0-25
ii  xz-utils5.2.4-1+b1

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libtext-template-perl  1.59-1

-- no debconf information



signature.asc
Description: PGP signature

Bug#897936: libvirt-daemon-system should not depend on policykit-1

[Gianluigi Tiesi]

Package: libvirt-daemon-system
Followup-For: Bug #897936
X-Debbugs-Cc: sher...@netfarm.it

Please downgrade policykit-1 to recommends,
for root managed only runs without problems

I've used equivs to make a fake policykit-1 package


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

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

Versions of packages libvirt-daemon-system depends on:
ii  adduser  3.118
ii  debconf [debconf-2.0]1.5.74
ii  gettext-base 0.21-3
pn  iptables | firewalld 
ii  libc62.31-6
ii  libgcc-s110.2.1-1
ii  libglib2.0-0 2.66.4-1
pn  libvirt-clients  
pn  libvirt-daemon   
pn  libvirt-daemon-system-systemd | libvirt-daemon-system-s  
pn  libvirt0 
ii  libxml2  2.9.10+dfsg-6.3+b1
pn  logrotate
pn  policykit-1  

Versions of packages libvirt-daemon-system recommends:
pn  dmidecode 
pn  dnsmasq-base  
ii  iproute2  5.10.0-1
pn  mdevctl   
pn  parted

Versions of packages libvirt-daemon-system suggests:
pn  apparmor
pn  auditd  
pn  nfs-common  
pn  open-iscsi  
pn  pm-utils
pn  radvd   
pn  systemd 
pn  systemtap   
pn  zfsutils

Bug#977975: general: Root does not aknoledge root password

[Juhan]

Package: general
Severity: important

Dear Maintainer,

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

   * What led up to the situation?

I made several netinstalls of Debian Buster 10.7, via Netinst-cd-images. Used
eather Graphic or non-graphic, mostly expert install as I have used to make
partitions myself. Added to first Debian base item only Mate desktop and System
(tools) (the last item). About 3-4 times I chose in install also activate the
"Root login", gave the same password to Root as to my ordinary account: as the
only user I used 1-digit password, the same digit as ordinary Username login.
My internet connection did not fail all the time (lan, 10/10 MBit/s). I used to
make separate Boot, Root, Home partitions; Grub on MBR of GPT table, although
my PC is EFI-capable (Fujitsu Esprimo d756; Intel 6(5)00; 256 ssd Hynix (all
used ones before me for 3-4 years), no signs ever of harware deficiencies.
(I am writing the Report on MX Linux install, not Debian.)


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

After install and reboot I tried to gain root rights: su. Then the Terminal
told the password was not right one, and that this incidence would be reported.
Also tried to login as Root. Again was always told that the password was not
right (one digit!). Yet about in 1(2) install all about the logins were working
excellently! Yet then I had missed some other minor things, and did new
install, hoping that I eventually had caught the point of my own mistake...
 Installing Debian in case I did not determed Root-login, then, as if I
remember right (I made less such installs), at one install root privileges
worked faultlessly, at other not 100%. Also tried both 32-bit and 64-bit
installer; always Mate desktop adding just minimal selection.

   * What was the outcome of this action?

As I wanted to find out Linux distro allowing minimal graphic desktop install
(less unused programs (bloatedness)), I tried Debian install really a lot of
times, thinking that the cause has to be my unfamiliarity with Debian
installer. At most times I did clean install, also reformatted the Home-
partition. Yet I had to abandon each new install because I could not use the
Terminal. (I am not sure, but probably the Synaptic accepted my password.)

   * What outcome did you expect instead?

I expected my passwords working well. It is not so easy to get the su or sudo
working in Debian as I had used in Linux Mint -- but this is another question,
the question of convenience for newcomers. There was another thing also: the
wording (explaining) of the activating of Root login was quite different in
Graphic login and/or Graphic expert login and/or Non-graphic expert login. It
was quite hard for me get an idea what really I had chosen.
Nevertheless mostly I admire the detailness of Debian tutorial pages! Although,
hard to catch sometimes for simple mortals as I...


*** ***



-- System Information:
Debian Release: 10.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 4.19.0-12-686-pae (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Bug#976924: Test timeouts on ppc64el not RC

[Reinhard Tartler]

Control: severity -1 normal

Looking at the logs, it really looks like timeouts in the testsuite. We could 
disable the tests on problematic architectures, patches welcome. As a 
workaround, I'd suggest building the package with export 
DEB_BUILD_OPTIONS=notest. With this, I'm downgrading the severity to normal to 
avoid having dozens of packages removed from testing.

-rt

Bug#976891: [Android-tools-devel] Bug#976891: fastboot exits with "fake placeholder until fastboot builds" message

[Chirayu Desai]

Hello,

On Wed, Dec 23, 2020 at 10:12 PM Roger Shimizu  wrote:

> On Wed, Dec 23, 2020 at 5:38 AM Hans-Christoph Steiner 
> wrote:
> >
> > Thanks for jumping in Roger!  I reviewed it with cdesai, and we thought
> > those libraries were not used on the "host" version, only when built as
> > part of Android OS.  I do think libfec would be useful if someone wants
> > to package adbd for Debian.  The Google Android Tools builds do not
> > include adbd for the host, only for the Android OS.
>
> I uploaded my current work to branch rosh/fastboot
> and build log can be checked by:
> -
> http://debomatic-amd64.debian.net/distribution#unstable/android-platform-system-core/10.0.0+r36-1~stage2/buildlog
>
> From the build log, I think fastboot still depends on fs_mgr,
> which depends on the new libs I mentioned previously (such as
> android-libfec).
>

We discussed this on the channel previously, #debian-android-tools
I was trying to link logs from matrix but it couldn't work.

Anyway, from the discussion, only 'fastbootd' depends on 'fs_mgr' which is
what depended on 'libfec_rs'.
'fastbootd' is 'recovery: true' in the Android.bp, which means it's meant
to run in the recovery environment on an Android device. Anything we're
building / packaging here should be marked as 'host_supported: true' or a
`*_host*` target - otherwise the code is only meant to run on the device.


>
> Maybe you have workaround not building fs_mgr completely, but
> currently I don't have no idea.
>
> > Right now, the only blocker I know about is the assembler code in
> > android-platform-art, which Michel and I are working on now.
>
> Yes, I also noticed this part lately.
> Hope you have good news on this.
>
> Cheers
> --
> Roger Shimizu, GMT +9 Tokyo
> PGP/GPG: 4096R/6C6ACD6417B3ACB1
>
> ___
> Android-tools-devel mailing list
> android-tools-de...@alioth-lists.debian.net
>
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/android-tools-devel

Bug#880556: parse upstream metadata files like package.json or .gemspec files

[Dominique Dumont]

On Thu, 2 Nov 2017 14:28:12 +0530 Pirate Praveen  wrote:
> Most ruby gems have the license information in .gemspec file 

.gemspec files are written in Ruby. I don't really know how to extract the 
relevant information from this file. I don't think using regexp to parse the 
gemspec file would be reliable.

Do you have other ideas ?

All the best

Bug#977362: alsa-ucm-conf: No sound working after upgrade

[Jonathan]

On Wed, 16 Dec 2020 22:14:36 +0900 Yuya Nishihara  wrote:
> Hi, I have the same issue on Lenovo ThinkPad T14 AMD. Downgrading
> alsa-ucm-conf to 1.2.3-1 fixed the issue.
>
> There's an upstream bug report about this:
> https://github.com/alsa-project/alsa-ucm-conf/issues/61
>
>


Simply downgrading alsa-ucm-conf to 1.2.3-1 fixed the issue for me as 
well on Lenovo T14 AMD (Renoir) Intel HD Sound

Bug#977962: [Pkg-javascript-devel] Bug#977962: Bug#977962: Bug#977962: webpack: mkdirp > 1 patch seems broken

[Jonas Smedegaard]

Quoting Pirate Praveen (2020-12-23 16:13:02)
> 
> 
> On Wed, Dec 23, 2020 at 16:06, Jonas Smedegaard  wrote:
> > memfs?  Is Nodejs module "memfs" in Debian, or are you talking about 
> > something else here?
> 
> > 
> memfs is used by compression-webpack-plugin for tests, but it is not 
> yet packaged.

Ah, makes sense then - will be needed for newer eslint as well, and I 
tried search for it as embedded module without luck.

Thanks for clarifying :-)

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#976891: fastboot exits with "fake placeholder until fastboot builds" message

[Roger Shimizu]

On Wed, Dec 23, 2020 at 5:38 AM Hans-Christoph Steiner  wrote:
>
> Thanks for jumping in Roger!  I reviewed it with cdesai, and we thought
> those libraries were not used on the "host" version, only when built as
> part of Android OS.  I do think libfec would be useful if someone wants
> to package adbd for Debian.  The Google Android Tools builds do not
> include adbd for the host, only for the Android OS.

I uploaded my current work to branch rosh/fastboot
and build log can be checked by:
- 
http://debomatic-amd64.debian.net/distribution#unstable/android-platform-system-core/10.0.0+r36-1~stage2/buildlog

>From the build log, I think fastboot still depends on fs_mgr,
which depends on the new libs I mentioned previously (such as android-libfec).

Maybe you have workaround not building fs_mgr completely, but
currently I don't have no idea.

> Right now, the only blocker I know about is the assembler code in
> android-platform-art, which Michel and I are working on now.

Yes, I also noticed this part lately.
Hope you have good news on this.

Cheers
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Bug#977974: node-less: `lessc --clean-css` doesn't minify

[Guilhem Moulin]

Package: node-less
Version: 3.13.0+dfsg-2
Severity: normal

Dear Maintainer,

Running `apt install node-less node-clean-css` in a clean sid chroot I'm
unable to make lessc produce minified output.  I don't know if
`--clean-css` does any “cleaning” or if it's a no-op.

$ lessc --clean-css /tmp/example.less
/* from http://lesscss.org/#overview */
#header {
  width: 10px;
  height: 20px;
}

$ lessc /tmp/example.less
/* from http://lesscss.org/#overview */
#header {
  width: 10px;
  height: 20px;
}

It does minify if I pass `--compress`, however that flag is currently
deprecated.

$ lessc --compress /tmp/example.less
The compress option has been deprecated. We recommend you use a dedicated 
css minifier, for instance see less-plugin-clean-css.
#header{width:10px;height:20px}

The plugin appears to load, but I can't pass any parameters:

$ lessc --plugin=nonexistent /tmp/example.less
Unable to load plugin nonexistent please make sure that it is installed 
under or at the same level as less

$ lessc --plugin=clean-css /tmp/example.less
/* from http://lesscss.org/#overview */
#header {
  width: 10px;
  height: 20px;
}

$ lessc --plugin=clean-css="advanced" /tmp/example.less
undefinedError: Options have been provided but the plugin index.js does not 
support any options.

Thanks,
-- 
Guilhem.
/* from http://lesscss.org/#overview */
@width: 10px;
@height: @width + 10px;

#header {
  width: @width;
  height: @height;
}


signature.asc
Description: PGP signature

Bug#941248: Acknowledgement (bash.bashrc dereferences undefined variables)

[Marko Mäkelä]

Hi,

I reported this bug along with a simple fix more than a year ago. A 
similar patch to fix Bug#941247 in vte2.91 was applied some months ago.


As far as I can tell, the problem is still present in the file 
bash-5.1/debian/etc.bash.bashrc in the package that I get by running 
"apt source bash".


In my opinion, every security-conscious user should have "set -u" (or 
"set -eu") in their private configuration.


Could you please consider applying the patch?

With best regards,

Marko Mäkelä

Bug#977968: duplicate

[Mina Morcose Farage]

Control: close
i see
thank you for telling me
i will wait for the update i will close this bug

Bug#973885: manpages-dev: broken symlinks /usr/share/man/man3/LIST_*.3

[Thorsten Glaser]

Package: manpages-dev
Version: 5.10-1
Followup-For: Bug #973885
X-Debbugs-Cc: t...@mirbsd.de

This bug still exists.


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

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

Versions of packages manpages-dev depends on:
ii  manpages  5.10-1

manpages-dev recommends no packages.

Versions of packages manpages-dev suggests:
ii  konqueror [man-browser]  4:20.08.3-1
ii  man-db [man-browser] 2.9.3-2

-- no debconf information

Bug#977731: lintian-brush: Default committer identity doesn't always match `git config user.email`

[Guilhem Moulin]

On Wed, 23 Dec 2020 at 14:04:45 +, Jelmer Vernooij wrote:
>> If I understand the source correctly, this is because the gitconfig
>> library it's using doesn't understand these settings.  It might be a
>> wishlist bug for the library, however lintian-brush could maybe call
>> `git config user.email` instead and let the git binary take care of the
>> parsing and fallback logic?
> 
> Yep, that's correct. Right there is no dependency on C Git, so I'd
> prefer to fix this in Dulwich (the library being used to read
> ~/.gitconfig). That way, it also fixes this issue for other Git users.

Ack.  The downside being of course that the gitconfig semantics is a
moving target and it might be non-negligible work to keep it up to date.

> The reason for the current implementation is to be consistent with the
> the way that dch (using DEBEMAIL) and debcommit (using
> GIT_COMMITTER_EMAIL/GIT_COMMITER_NAME) work, so it's least
> controversial.

Oh I see.  Didn't realize debcommit was not honoring DEBEMAIL since it
uses C git which picks the correct user.email from the conditional
include :-)
 
> Would it make sense for e.g. debcommit to set GIT_COMMITTER_EMAIL to
> DEBEMAIL? Are there reasons why DEBEMAIL and GIT_COMMITTER_EMAIL
> should ever be different?

Not that I can think of, and same thing for GIT_AUTHOR_EMAIL and
GIT_{AUTHOR,COMMITTER}_NAME.  Filed the suggestion at #977973.

Thanks,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#977973: [debcommit] Please set GIT_{AUTHOR,COMMITTER}_EMAIL to $DEBEMAIL

[Guilhem Moulin]

Package: devscripts
Version: 2.20.5
Severity: wishlist
File: /usr/bin/debcommit

Dear Maintainer,

Many of the devscripts tools honor the values of the DEBEMAIL and
DEBFULLNAME environment variables for attribution, however debcommit
ignores these AFAICT and follows the git-commit(1) semantics instead:
use $GIT_{AUTHOR,COMMITTER}_{EMAIL,NAME} when set, otherwise use the
result from `git config user.email` and `git config user.name`.

Please consider setting GIT_{AUTHOR,COMMITTER}_EMAIL resp.
GIT_{AUTHOR,COMMITTER}_NAME to $(DEB)EMAIL resp. $(DEBFULL)NAME by
default for consistency with dch and other tools.  Per Jelmer's
(X-Debbugs-Cc'ed) https://bugs.debian.org/977731#10 ,

| Would it make sense for e.g. debcommit to set GIT_COMMITTER_EMAIL to
| DEBEMAIL? Are there reasons why DEBEMAIL and GIT_COMMITTER_EMAIL
| should ever be different?

Thanks,
Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#977890: libcinnamon-menu-3-0: Upgrade

[Max Minenko]

I have the same issue. Only Alt + F2 and keyboard shortcuts work.
The (cinnamon) menu doesn't do anything.

-- 
Regards,
Max Minenko

Bug#965486: debian-builder: Removal of obsolete debhelper compat 5 and 6 in bookworm

[Niels Thykier]

Control: notfound -1 debian-builder/1.8.0
Control: fixed -1 1.8.0

Correcting metadata.  Note if found version == fixed version then the
BTS assumes the bug is not fixed.

Bug#977962: [Pkg-javascript-devel] Bug#977962: Bug#977962: Bug#977962: webpack: mkdirp > 1 patch seems broken

[Pirate Praveen]

On Wed, Dec 23, 2020 at 16:06, Jonas Smedegaard  wrote:

memfs?  Is Nodejs module "memfs" in Debian, or are you talking about
something else here?




memfs is used by compression-webpack-plugin for tests, but it is not 
yet packaged.

Bug#977962: [Pkg-javascript-devel] Bug#977962: Bug#977962: webpack: mkdirp > 1 patch seems broken

[Jonas Smedegaard]

Quoting Xavier (2020-12-23 14:02:29)
> Control: severity -1 important
> Control: retitle -1 node-compression-webpack-plugin: enable test
> 
> Le 23/12/2020 à 13:27, Pirate Praveen a écrit :
> > Package: webpack,node-compression-webpack-plugin
> > Version: 4.43.0-6
> > Severity: serious
> > 
> > To reproduce this issue,
> > 
> > run
> > jest --ci test/CompressionPlugin.test.js
> > 
> > in node-compression-webpack-plugin
> > 
> > ● CompressionPlugin › should work and show compress assets in stats
> > 
> >    TypeError: callback must be a function
> > 
> >  491 | if (err) return callback(err);
> >  492 | outputPath = compilation.getPath(this.outputPath);
> >    > 493 | this.outputFileSystem.mkdirp(outputPath).then(() =>
> > {emitFiles()}).catch(er => {throw er});
> >  | ^
> >  494 | });
> >  495 | }
> >  496 |
> > 
> >  at validateCallback (node_modules/memfs/lib/volume.js:199:15)
> >  at Volume.mkdirp (node_modules/memfs/lib/volume.js:1579:24)
> >  at ../../../../../usr/share/nodejs/webpack/lib/Compiler.js:493:26
> >  at eval (eval at create
> > (../../../../../usr/share/nodejs/tapable/lib/HookCodeFactory.js:24:12),
> > :8:1)
> > 
> > It is also possible a bug in node-compression-webpack-plugin/memfs
> > module (this should be added as a test only component, I have not
> > committed this to repo as the tests are failing still). memfs does not
> > have any dependency on mkdirp hence I think the bug is in webpack.
> 
> The bug is that memfs adds hooks to simulate a filesystem and overrides
> webpack/mkdirp calls, simulating mkdirp 0.53.
> 
> You can fix this in memfs to return a promise instead of waiting for a
> callback

memfs?  Is Nodejs module "memfs" in Debian, or are you talking about 
something else here?

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#977972: transition: ppp

[Chris Boot]

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

Hi release team folks,

There has been a version of ppp in experimental since 2020-02-15. I've
got a very slightly revised version that I'd like to upload over the
holidays (mostly just cosmetic packaging updates) but I'll wait to
upload until I hear from you. This new version is an ABI break due to
the new upstream version, hence the transition.

As usual this isn't a traditional library package upload so the Ben file
looks a bit foreign. See #890204 for the (only) other time we did this.

Best regards,
Chris

Ben file:

title = "ppp";
is_affected = .build-depends ~ /ppp-dev/;
is_good = .depends ~ /ppp \(>= 2\.4\.8-1\+~\)/ | .breaks ~ /ppp \(<< 
2\.4\.8-1\+~\)/;
is_bad = .depends ~ /ppp \(>= 2\.4\.7-2\+~\)/ | .breaks ~ /ppp \(<< 
2\.4\.7-2\+~\)/;

Bug#977969: licensecheck: fails to detect "This file is licensed under GPLv2 or later"

[Jonas Smedegaard]

Control: retitle -1 licensecheck: fails to detect "Licensed under GPLv2 or 
later"

Quoting Jonas Smedegaard (2020-12-23 15:47:06)
> The file goo/GooTimer.h in project Poppler contains this:
> 
> //
> // This file is licensed under GPLv2 or later
> //
> 
> Which is undetected by licensecheck:
> 
> $ licensecheck GooTimer.cc 
> GooTimer.cc: UNKNOWN

Doesn't detect "Licensed under GPLv2 or later" either, found in 
poppler/JPEG2000Stream.cc but a far more common pattern.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#977971: openssh-client: ssh-keygen fails to create ed25519-sk

[Ingo Wichmann]

Package: openssh-client
Version: 1:8.4p1-2~bpo10+1
Severity: normal

Dear Maintainer,

I tried to create a ssh key pair with the command
ssh-keygen -t ed25519-sk

I got the following output:
Generating public/private ed25519-sk key pair.
You may need to touch your authenticator to authorize key generation.
Key enrollment failed: invalid format

No key was created.

So I tried again, this time with
ssh-keygen -t ecdsa-sk

I got the following output:
Generating public/private ecdsa-sk key pair.
You may need to touch your authenticator to authorize key generation.
Enter file in which to save the key (/home/iw/.ssh/id_ecdsa_sk): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/iw/.ssh/id_ecdsa_sk
Your public key has been saved in /home/iw/.ssh/id_ecdsa_sk.pub

As you can see, a key was created.

I tried the same on another machine running Debian. And on a machine
runnig Ubuntu 20.04. They showed the same behavior.

Regards,

Ingo

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

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

Versions of packages openssh-client depends on:
ii  adduser   3.118
ii  dpkg  1.19.7
ii  libc6 2.28-10
ii  libedit2  3.1-20181209-1
ii  libfido2-11.5.0-2~bpo10+1
ii  libgssapi-krb5-2  1.17-3+deb10u1
ii  libselinux1   2.8-1+b1
ii  libssl1.1 1.1.1d-0+deb10u4
ii  passwd1:4.5-1.1
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages openssh-client recommends:
ii  xauth  1:1.0.10-1

Versions of packages openssh-client suggests:
pn  keychain   
ii  ksshaskpass [ssh-askpass]  4:5.14.5-1
pn  libpam-ssh 
pn  monkeysphere   

-- no debconf information

Bug#977970: ITP: amdgcn-tools - linker tools for the amdgcn target

[Matthias Klose]

Package: wnpp

This is just a split-out of the amdgcn target tools from the
gcc-N-offload-amdgcn packages.

Package: amdgcn-tools
Description: linker tools for the amdgcn architecture
 The package provides the tools ar, as, ld and nm for the
 amdgcn target architecture (used in AMD gpus).  The tools
 are based on LLVM.
 .
 This is just a dependency package used by the gcc-N-offload-amdgcn
 offload compilers.

Bug#977969: licensecheck: fails to detect "This file is licensed under GPLv2 or later"

[Jonas Smedegaard]

Package: licensecheck
Version: 3.0.47-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The file goo/GooTimer.h in project Poppler contains this:

//
// This file is licensed under GPLv2 or later
//

Which is undetected by licensecheck:

$ licensecheck GooTimer.cc 
GooTimer.cc: UNKNOWN


 - Jonas

Versions of packages licensecheck depends on:
ii  libarray-intspan-perl  2.004-1
ii  libgetopt-long-descriptive-perl0.105-1
ii  liblist-someutils-perl 0.58-1
ii  liblog-any-adapter-screen-perl 0.140-1
ii  liblog-any-perl1.708-1
ii  libmoo-perl2.004004-1
ii  libmoox-struct-perl0.020-1
ii  libnamespace-clean-perl0.27-1
ii  libpath-iterator-rule-perl 1.014-1
ii  libpath-tiny-perl  0.114-1
ii  libpod-constants-perl  0.19-2
ii  libre-engine-re2-perl  0.13-5+b5
ii  libregexp-pattern-license-perl 3.4.0-1
ii  libregexp-pattern-perl 0.2.14-1
ii  libsort-key-perl   1.33-2+b3
ii  libstrictures-perl 2.06-1
ii  libstring-copyright-perl   0.003006-1
ii  libstring-escape-perl  2010.002-2
ii  libtry-tiny-perl   0.30-1
ii  perl   5.32.0-6
ii  perl-base [libscalar-list-utils-perl]  5.32.0-6

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl/jWGgACgkQLHwxRsGg
ASGlqA/9Hx5E6Yg8cEvLHF0HN/A4l7g4ppvY06nb/8YKcmSAhenx4fs8W8lbrDnJ
YF5j1ol01FfaijxyI3gGWR9Athiipl/6JmGGSOXZsKL2wml3zhKMshVJxuoTgCU2
OSEqOV47Ma9QOaQ1ZLsZJV5ouxWnBA58kPNfY/065cFe9iuq26uOGcKTvXrkIJ8G
oT1JHDcMc88Fk6yjbmxOyAuvO0jUFsWYPeWgbf7JVS0KqmuPrEsYsRG1n5cCkFmm
xbYIzfXmXMc9Z586M1Pi2keZUl9Kywo24qbrUGGfLz/7NRVRJltpzyWvi3SDi/NH
N0VDuKsJdSqaO9QmJOOralxwoMho9RBxUjiNI3Uv7yaimt9m0Lx+1VJIEYXXkQ32
6vTKIwV8N+BUrLgF4pE/dPdBQk92omfsOKiHrD2VPSay1Cn2UWpIUTDQbp08kDW+
2K5Jbtj7hEjimYZovWmisiyDIjGKLsKun8y4XbfpIHOGY3/KWSxfYspiXM9OVELz
1eYI320e7fiYh7Uco3Jfc8LFkK7Vv0dbawKgpeg/rsFMrGyYuD3bS1KxNC9y2sSE
uf8gJU1yQuO2HlD4GQRAxdsnSKONHM7/aTSJN7jMJpn4Sr/0pHYs4+NDwUBFz/Tf
1XPk+Al8mKBjYAC+eC3xrzrNkJDBm9cA5zRAJ1AUngR07VMk0vk=
=8WoV
-END PGP SIGNATURE-

Bug#977968: cinnamon keep crashing after latest migration to testing

[Fabio Fantoni]

Il 23/12/2020 15:27, Mina Morcose Farage ha scritto:
> i also tried clean testing install on virtualbox to element any
> possibility of drive or package conflict and same error happened

should be the same of bug 977890, "solved" but need to wait new build
migrating to testing for solves it; unfortunately people like you have
already installed/updated with cinnamon-menus 4.8 should wait full
cinnamon migration some days more

Bug#977968: problem reproduce notice

[Mina Morcose Farage]

i also tried clean testing install on virtualbox to element any possibility
of drive or package conflict and same error happened

Bug#977731: lintian-brush: Default committer identity doesn't always match `git config user.email`

[Jelmer Vernooij]

On Sat, Dec 19, 2020 at 07:39:52PM +0100, Guilhem Moulin wrote:
> I use git-config(1)'s ‘include.path’ and ‘includeIf.*.path’ settings to
> set user.email to my @debian.org email address gobally for all my Debian
> repositories while keeping my private email address as general default:
> 
> $XDG_CONFIG_HOME/git/config:
> [user]
> email = guil...@example.net
> [includeIf "gitdir:/path/to/debian/**/.git"]
> path = debian.config
> 
> $XDG_CONFIG_HOME/git/debian.config:
> [user]
> email = guil...@debian.org
> [merge "dpkg-mergechangelogs"]
> name = debian/changelog merge driver
> driver = dpkg-mergechangelogs -m %O %A %B %A
> 
> This works just fine as far as the git binary is concerned: `git config
> user.email` returns ‘guil...@debian.org’ in repositories under
> ‘/path/to/debian’, and ‘guil...@example.net’ everywhere else.  (Unless
> overwritten in the repo config, of course.)
> 
> However lintian-brush doesn't seem to understand includeIf.*.path (nor
> include.path):
> 
> /path/to/debian/pkg $ lintian-brush --identity
> Committer identity: Guilhem Moulin 
> Changelog identity: Guilhem Moulin 
> 
> If I understand the source correctly, this is because the gitconfig
> library it's using doesn't understand these settings.  It might be a
> wishlist bug for the library, however lintian-brush could maybe call
> `git config user.email` instead and let the git binary take care of the
> parsing and fallback logic?

Yep, that's correct. Right there is no dependency on C Git, so I'd
prefer to fix this in Dulwich (the library being used to read
~/.gitconfig). That way, it also fixes this issue for other Git users.

> Alternatively, I see it honors the GIT_COMMITTER_EMAIL environment
> variable.  I don't want to set this variable globally though; devscripts
> use DEBEMAIL and I have DEBEMAIL=guil...@debian.org.  Since
> lintian-brush is Debian-specific, wouldn't it make sense to honor
> DEBEMAIL resp. DEBFULLNAME before GIT_COMMITTER_EMAIL resp.
> GIT_COMMITTER_NAME?
As you mention, the current behaviour is suboptimal because there are
two identities involved. The reason for the current implementation is
to be consistent with the the way that dch (using DEBEMAIL) and
debcommit (using GIT_COMMITTER_EMAIL/GIT_COMMITER_NAME) work, so it's
least controversial.

Would it make sense for e.g. debcommit to set GIT_COMMITTER_EMAIL to
DEBEMAIL? Are there reasons why DEBEMAIL and GIT_COMMITTER_EMAIL
should ever be different?

I'm open to other solutions, if people have preferences.

> If you don't like the above, how about new options username/email in
> lintian-brush.conf? :-)
That would certainly be an option, though if at all possible I'd like
to avoid extra configuration.

Jelmer

Bug#977967: php7.4: imageftbbox returns too small bounding box

[Thorsten Glaser]

Dixi quod…

>The values I get are:
>
>Array
>(
>[bbox] => Array
>(
>[0] => 1
>[1] => 0
>[2] => 185
>[3] => 0
>[4] => 185
>[5] => -11
>[6] => 1
>[7] => -11
>)
>
>[ascender] => 11
>[descender] => 0
>[size_w] => 186
>[size_h] => 11
>[x] => -1
>[y] => 11
>)

For comparison, php7.3-gd (7.3.19-1~deb10u1) on buster/i386 gives me:

Array
(
[bbox] => Array
(
[0] => 0
[1] => 1
[2] => 187
[3] => 1
[4] => 187
[5] => -13
[6] => 0
[7] => -13
)

[ascender] => 13
[descender] => 1
[size_w] => 187
[size_h] => 14
[x] => 0
[y] => 13
)

This is more in the expected range.

That being said, php7.3-gd:x32 (7.3.15-3) on sid gives me…

Array
(
[bbox] => Array
(
[0] => 1
[1] => 0
[2] => 185
[3] => 0
[4] => 185
[5] => -11
[6] => 1
[7] => -11
)

[ascender] => 11
[descender] => 0
[size_w] => 186
[size_h] => 11
[x] => -1
[y] => 11
)

… which matches php7.4, so this could also a problem
in a different package in sid, or fixed later in 7.3…

(php7.0 7.0.32-1 and php7.2 7.2.11-3 behave the same, too.)

bye,
//mirabilos
-- 
15:39⎜«mika:#grml» mira|AO: "mit XFree86® wär’ das nicht passiert" - muhaha
15:48⎜ also warum machen die xorg Jungs eigentlich alles
kaputt? :)15:49⎜ thkoehler: weil sie als Kinder nie den
gebauten Turm selber umschmeissen durften?  -- ~/.Xmodmap wonders…

Bug#977968: Fwd: cinnamon keep crashing after latest migration to testing

[Mina Morcose Farage]

Package: cinnamon
Version: 4.6.7-1
Severity: critical

after updating to this version which is the latest version in testing it
boot up but after trying to open any program it go to fallback mode and
offer a restart and after the restart if fail again and so on it closed
loop which make the desktop completely unusable and i have to install
another desktop environment to migrate th issue

to reproduce the bug just install latest cinnamon in testing

thank you in advance
Mina Morcose Farage

Bug#977967: php7.4: imageftbbox returns too small bounding box

[Thorsten Glaser]

Package: php7.4-gd
Version: 7.4.11-1
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de

I’m running the following script:

php -r '
$text = "2020-12-23T13:25:44Z";
$font = "Inconsolatazi4varl_qu-Regular.otf";// attached
$fontsize = 14;
$bbox = imageftbbox($fontsize, 0, $font, $text);
$ascender = abs($bbox[7]) /* +1 */;
$descender = abs($bbox[1]);
$size_w = abs($bbox[0]) + abs($bbox[2]);
$size_h = $ascender + $descender;
$x = -$bbox[0];
$y = $ascender;
//print_r(array("bbox"=>$bbox,"ascender"=>$ascender,"descender"=>$descender,"size_w"=>$size_w,"size_h"=>$size_h,"x"=>$x,"y"=>$y));
$im = imagecreatetruecolor($size_w, $size_h);
$bgcol = imagecolorallocate($im, 0xDD, 0xDD, 0xDD);
$fgcol = imagecolorallocate($im, 0x00, 0x00, 0x23);
imagefilledrectangle($im, 0, 0, $size_w - 1, $size_h - 1, $bgcol);
imagefttext($im, $fontsize, 0, $x, $y, $fgcol, $font, $text);
imagetruecolortopalette($im, FALSE, 256);
imagepng($im, NULL, 9);
' >TS.png

The values I get are:

Array
(
[bbox] => Array
(
[0] => 1
[1] => 0
[2] => 185
[3] => 0
[4] => 185
[5] => -11
[6] => 1
[7] => -11
)   

[ascender] => 11
[descender] => 0
[size_w] => 186
[size_h] => 11
[x] => -1
[y] => 11
)

However, these are too small. At least the upper horizontal bar
of the ‘T’ is completely cut off, and (as can be seen when the
/* +1 */ is uncommented) *all* digits have *significant* black
in the topmost line (ascender=12).

Adding 2 to both descender and ascender shows that that’s it.

I suspect rounding to be at fault: the bounding box is most
likely provided via floating point, then cut down to integers.
When dealing with bounding boxen, the correct rounding method
to use is “away from 0”, so that fractional pixels will also
be present.


-- Package-specific info:
 Additional PHP 7.4 information 

 PHP @PHP_VERSION SAPI (php7.4query -S): 

 PHP 7.4 Extensions (php7.4query -M -v): 

 Configuration files: 
 /etc/php/7.4/mods-available/gd.ini 
extension=gd.so


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

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

Versions of packages php7.4-gd depends on:
ii  libc6  2.31-6
ii  libgd3 2.3.0-2
ii  php-common 2:76
ii  php7.4-common  7.4.11-1
ii  ucf3.0043

php7.4-gd recommends no packages.

php7.4-gd suggests no packages.

Versions of packages php7.4-common depends on:
ii  libc6   2.31-6
ii  libffi7 3.3-5
ii  libssl1.1   1.1.1i-1
ii  php-common  2:76
ii  ucf 3.0043

Versions of packages php7.4-cli depends on:
ii  libargon2-1  0~20171227-0.2
ii  libc62.31-6
ii  libedit2 3.1-20191231-2
ii  libmagic11:5.39-3
ii  libpcre2-8-0 10.36-2
ii  libsodium23  1.0.18-1
ii  libssl1.11.1.1i-1
ii  libxml2  2.9.10+dfsg-6.3+b1
ii  mime-support 3.66
ii  php7.4-common7.4.11-1
ii  php7.4-json  7.4.11-1
ii  php7.4-opcache   7.4.11-1
ii  php7.4-readline  7.4.11-1
ii  tzdata   2020d-1
ii  ucf  3.0043
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages php7.4-cli suggests:
ii  php-pear  1:1.10.9+submodules+notgz-1.1

Versions of packages libapache2-mod-php7.4 depends on:
ii  apache2-bin [apache2-api-20120211]  2.4.46-2
ii  libargon2-1 0~20171227-0.2
ii  libc6   2.31-6
ii  libmagic1   1:5.39-3
ii  libpcre2-8-010.36-2
ii  libsodium23 1.0.18-1
ii  libssl1.1   1.1.1i-1
ii  libxml2 2.9.10+dfsg-6.3+b1
ii  mime-support3.66
ii  php7.4-cli  7.4.11-1
ii  php7.4-common   7.4.11-1
ii  php7.4-json 7.4.11-1
ii  php7.4-opcache  7.4.11-1
ii  tzdata  2020d-1
ii  ucf 3.0043
ii  zlib1g  1:1.2.11.dfsg-2

Versions of packages libapache2-mod-php7.4 recommends:
ii  apache2  2.4.46-2

Versions of packages libapache2-mod-php7.4 suggests:
ii  php-pear  1:1.10.9+submodules+notgz-1.1

-- no debconf information


Inconsolatazi4varl_qu-Regular.otf
Description: application/vnd.ms-opentype

Bug#951310: Note

[Alastair McKinstry]

This is a note that v4.0.0 did not involve any ABI breakages (which were 
originally anticipated)

so the SOVERSION bump and transition is indefinitely postponed.

v4.0.0 does involve dropping the libpmi1 and libpmi2 support, but these 
were not used in Debian;


an external package provides this functionality which may be included if 
it is later deemed necessary, but doesn't appear to be at this point.



Alastair

--
Alastair McKinstry, , , 
https://diaspora.sceal.ie/u/amckinstry
Misentropy: doubting that the Universe is becoming more disordered.

Bug#976669: lintian: please warn about autopkgtests that test rebuilt source, not as-installed, where possible

[Thorsten Glaser]

On Wed, 23 Dec 2020, Andrius Merkys wrote:

> false-positives. Even dh_auto_configure appears to be used legitimately

dh_auto_configure is the one I’d expect to be used (with autotools).

dh_auto_build is the one that raises red flags, and for *some*
buildsystems dh_auto_test invokes a make/maven/whatever target
that implies build if it was not built before. These uses, when
it can be done reliably, should also flag.

Examples for dh_auto_test:

• Many Makefiles for autotools-using packages contain lines like:

check: all

  If this is present, it should warn. But since this is not present
  everywhere, we can probably not warn due to too many false positives.

• With Maven, calling “mvn test” will *always* build the source
  if it was not already built and test the just-compiled sources.
  Here we CAN reliably flag.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

*

Mit unserem Consulting bieten wir Unternehmen maßgeschneiderte Angebote in
Form von Beratung, Trainings sowie Workshops in den Bereichen
Softwaretechnologie, IT Strategie und Architektur, Innovation und Umsetzung
sowie Agile Organisation.

Besuchen Sie uns auf https://www.tarent.de/consulting .
Wir freuen uns auf Ihren Kontakt.

*

Bug#977966: please consider merge request 1 "rule update"

[Marc Haber]

Package: aide-common
Version: 0.16.1-1
Severity: wishlist

Hi,

15 months ago, I filed a rather big merge requests with a lot of rule
updates: https://salsa.debian.org/debian/aide/-/merge_requests/1

Unfortunately, this has not been merged up to now.

I don't know how much the Debian system has evolved under those proposed
change, but I think it would be really good to have those changes in
bullseye. It will probably not be possible to do much more improvements
to the rules before the freeze.

Please consider merging this request and doing an upload, or at least
telling me that it's ok to merge and upload myself (I am a
co-maintainer of the Debian package). A review of the changes would be
appreciated. I am using them (or evolved, advanced versions) on my
systems for over a year, so I am pretty confident that they are not too
bad.

Greetings
Marc

Bug#977965: python3-user-agents: new upstream version available: v2.2.0

[Hans-Christoph Steiner]

Package: python3-user-agents
Version: 1.1.0-1
Severity: normal

Dear Maintainer,

There is a new upstream version v2.2.0 that is ~18 months newer than
what is currently in bullseye.  The freeze is coming soon, and I'd
love to have the latest version included.

.hc

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

[Mark Hindley]

Elana,

Thanks for passing this on.

On Mon, Dec 21, 2020 at 03:36:45PM -0800, Elana Hashman wrote:
> Less than 1% of users are installing sysvinit-core, with a steady
> downward trend.[1]

I accept that the number of users is small, although the figures referenced omit
users of openrc and runit. It is also worth noting that is is currently
moderately difficult to switch away from systemd to another init. Suggestions of
ways of making this more user friendly have been rejected[1]. In this case using
popcon as definitive evidence of the actual demand seems questionable.

> elogind is very difficult to support in its current state (see the
> following bugs: [2] [3] [4] [5]), which is why Michael does not want to
> maintain support for it.

He may not want to, but I still see no technical or other reason why this should
be blocked: elogind has been in the archive since buster; it is specifically
mentioned in the winning GR option as technology to explore; the logind and
default-logind virtual packages have been in the Policy since version 4.4.0 of
July 2019

My assessment of the bugs that Michael references is rather different.

 - #923244 was resolved in February 2019 and whilst I realise that Michael
remains unhappy with the way that resolution was achieved, the solution
works for both non-systemd users and systemd users and I am not aware of any
regressions.

 - #934491 was closed after being fixed by the resolution of #935910 in apt.

 - #959920 was really about systemctl providing systemd, and only indirectly
related to elogind (which conflicts with systemd, as you would expect).

 - #968379 was resolved with the latest upstream release of elogind.

Although elogind inclusion and support was controversial and hard-won, these
specific issues have been resolved. Making use of the default-logind and logind
virtual packages actually makes elogind rather easy to support.

Mark


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