Bug#965099: XWayland: Won't startup session with my specific GNOME configuration

2020-07-15 Thread Adrian Immanuel Kiess
Package: xwayland
Version: 2:1.20.8-2
Severity: normal

Dear Maintainer,

   * What led up to the situation?
 Updated the system
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 apt -u dist-upgrade
   * What was the outcome of this action?
 GNOME does not start any longer with my own GNOME configuration. Using
GNOME on Xorg from the GDM3 login manager works fine, other account with not
much changed GNOME settings do work also
   * What outcome did you expect instead?
 Running GNOME on Wayland

currently in Debian/testing I want to report the following problem/bug:

I have a good one year old GNOME configuration for my own user account I am
using on this system.

I can't login to XWayland using GNOME (on Wayland) using the GDM3 login
manager. After the password got accepted it loads services like tracker fine,
but then  halts and also the mouse pointer gets to an hold.

I can login to two other accounts to this system with GNOME on XWayland fine,
but those have a not much changed GNOME default configuration.

I can also login with that GNOME configuration of my own user account to GNOME
on Xorg fine.

I have no clue why it won't work, I tried to monitor the logs with journalctl
-f but I couldn't find anything suspicious.

Maybe you can try to login to GNOME on XWayland using an user account with used
and changed config files.

Yours sincereley,

Adrian Kieß



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

Kernel: Linux 5.7.0-1-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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 xwayland depends on:
ii  libaudit1   1:2.8.5-3+b1
ii  libbsd0 0.10.0-1
ii  libc6   2.30-8
ii  libdrm2 2.4.102-1
ii  libepoxy0   1.5.4-1
ii  libgbm1 20.1.2-1
ii  libgcrypt20 1.8.5-5
ii  libgl1  1.3.1-1
ii  libpixman-1-0   0.36.0-1
ii  libselinux1 3.0-1+b3
ii  libsystemd0 245.6-2
ii  libunwind8  1.2.1-9
ii  libwayland-client0  1.18.0-1
ii  libxau6 1:1.0.8-1+b2
ii  libxdmcp6   1:1.1.2-3
ii  libxfont2   1:2.0.3-1
ii  libxshmfence1   1.3-1
ii  xserver-common  2:1.20.8-2

xwayland recommends no packages.

xwayland suggests no packages.

-- no debconf information


Bug#965098: please remove geda-gaf from the archive

2020-07-15 Thread Bdale Garbee
Package: ftp.debian.org

I'm a member of the Debian Electronics team, and have been one of the
maintainers of Debian's geda-gaf package for the last few years.

The geda-gaf package is holding back guile-2.0 removal, and I see little
chance that upstream will care about this any time soon.  There's a
newer upstream release than what's in Debian, and it still hard depends
on guile-2.0.

For users, the lepton-eda package which is well maintained upstream and
in Debian is a complete replacement, with no change in file formats so
existing designs can just continue to be worked on.  The current
lepton-eda package supports guile-2.2, and I understand guile-3.0
support will be included in the next upstream version.

There are two reverse dependencies on geda-gaf, gspiceui, and
contrib/easyspice.  Both appear to be maintained by Gudjon
I. Gudjonsson, who I will CC.

It looks like the last gspiceui upstream release was in late 2018, and
the only reason it depends on geda-gaf is that it wants to use gnetlist
to import schematic data from gschem.  Updating that to use
lepton-netlist to import schematic data from lepton-schematic should be
a pretty simple search and replace operation if keeping gspiceui seems
worthwhile (I don't know, I've never used it).

The situation with easyspice seems similar, and it can probably be made
to work with lepton-eda just as easily.  However, since it's in contrib
and not main, I'm not particularly concerned about what happens to it.

Bottom line, I think it's time we remove geda-gaf from the archive, and
focus the attention of geda-gaf users towards lepton-eda as a replacement.

Bdale


signature.asc
Description: PGP signature


Bug#885195: [Pkg-electronics-devel] Bug#885195: Bug#885195: geda-gaf: please migrate to guile-2.2

2020-07-15 Thread Bdale Garbee
Rob Browning  writes:

> Bdale Garbee  writes:
>
>> I'm not interested in maintaining pcb any more.
>
> Does that mean geda-gaf etc?  If so might it make sense for you (or
> who?) to file a removal request, i.e. ROM or similar?

Sorry, you make a good point, geda-gaf and pcb aren't the same thing.
While I no longer use either (choosing to use the forks lepton-eda and
pcb-rnd instead), there's no immediate need to shove pcb out of the
archive.

However, I see little chance of geda-gaf upstream working on the things
needed to keep it viable in Debian any time soon, and with lepton-eda in
my mind a complete replacement that still works with the same file
formats, etc, I see no reason to go nuts trying to make geda-gaf better. 

I'll file a removal request for geda-gaf.

Bdale


signature.asc
Description: PGP signature


Bug#965062: systemd: Cannot resolve user name systemd-network: No such process

2020-07-15 Thread Marc Lehmann
On Wed, Jul 15, 2020 at 03:30:30PM +0200, Michael Biebl  
wrote:
> systemctl status systemd-networkd

● systemd-networkd.service - Network Service
   Loaded: loaded (/lib/systemd/system/systemd-networkd.service; enabled; 
vendor preset: enabled)
   Active: failed (Result: exit-code) since Thu 2020-07-16 04:15:32 UTC; 23s ago
 Docs: man:systemd-networkd.service(8)
  Process: 854 ExecStart=/lib/systemd/systemd-networkd (code=exited, 
status=1/FAILURE)
 Main PID: 854 (code=exited, status=1/FAILURE)

Jul 16 04:15:32 pxe systemd[1]: systemd-networkd.service: Main process exited, 
code=exited, status=1/FAILURE
Jul 16 04:15:32 pxe systemd[1]: systemd-networkd.service: Failed with result 
'exit-code'.
Jul 16 04:15:32 pxe systemd[1]: Failed to start Network Service.
Jul 16 04:15:32 pxe systemd[1]: systemd-networkd.service: Service has no 
hold-off time (RestartSec=0), scheduling restart.
Jul 16 04:15:32 pxe systemd[1]: systemd-networkd.service: Scheduled restart 
job, restart counter is at 5.
Jul 16 04:15:32 pxe systemd[1]: Stopped Network Service.
Jul 16 04:15:32 pxe systemd[1]: systemd-networkd.service: Start request 
repeated too quickly.
Jul 16 04:15:32 pxe systemd[1]: systemd-networkd.service: Failed with result 
'exit-code'.
Jul 16 04:15:32 pxe systemd[1]: Failed to start Network Service.

> getent passwd systemd-network

systemd-network:x:101:103:systemd Network 
Management,,,:/run/systemd/netif:/bin/false

> systemctl cat systemd-networkd
> And your /etc/nsswitch.conf

Attached.

Additionally, when I run /lib/systemd/systemd-networkd manually, it works (as
root), so maybe it's a permissions problem:

   # /lib/systemd/systemd-networkd
   eth0: Gained IPv6LL
   Enumeration completed
   eth0: DHCPv4 address 10.0.0.73/25 via 10.0.0.5
   lo: Configured
   eth0: Configured

However, even non-root users can resolve the passwd entry just fine it seems:

   # su -c "getent passwd systemd-network" -s /bin/sh nobody
   systemd-network:x:101:103:systemd Network 
Management,,,:/run/systemd/netif:/bin/false

Lastly, "No such process" seems to be a peculiar error, but it seems to be
generated by logic in the systemd code (which, btw., seems to errornously
assume that errno is 0 when a library call succeeds, in a lot of places -
fortunately only for error reporting it seems).

-- 
The choice of a   Deliantra, the free code+content MORPG
  -==- _GNU_  http://www.deliantra.net
  ==-- _   generation
  ---==---(_)__  __   __  Marc Lehmann
  --==---/ / _ \/ // /\ \/ /  schm...@schmorp.de
  -=/_/_//_/\_,_/ /_/\_\
# /lib/systemd/system/systemd-networkd.service
#  SPDX-License-Identifier: LGPL-2.1+
#
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

[Unit]
Description=Network Service
Documentation=man:systemd-networkd.service(8)
ConditionCapability=CAP_NET_ADMIN
DefaultDependencies=no
# systemd-udevd.service can be dropped once tuntap is moved to netlink
After=systemd-udevd.service network-pre.target systemd-sysusers.service 
systemd-sysctl.service
Before=network.target multi-user.target shutdown.target
Conflicts=shutdown.target
Wants=network.target

[Service]
AmbientCapabilities=CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_NET_BROADCAST 
CAP_NET_RAW
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_NET_BROADCAST 
CAP_NET_RAW
ExecStart=!!/lib/systemd/systemd-networkd
LockPersonality=yes
MemoryDenyWriteExecute=yes
NoNewPrivileges=yes
ProtectControlGroups=yes
ProtectHome=yes
ProtectKernelModules=yes
ProtectSystem=strict
Restart=on-failure
RestartSec=0
RestrictAddressFamilies=AF_UNIX AF_NETLINK AF_INET AF_INET6 AF_PACKET
RestrictNamespaces=yes
RestrictRealtime=yes
RuntimeDirectory=systemd/netif
RuntimeDirectoryPreserve=yes
SystemCallArchitectures=native
SystemCallErrorNumber=EPERM
SystemCallFilter=@system-service
Type=notify
User=systemd-network
WatchdogSec=3min

[Install]
WantedBy=multi-user.target
Also=systemd-networkd.socket
Alias=dbus-org.freedesktop.network1.service

# We want to enable systemd-networkd-wait-online.service whenever this service
# is enabled. systemd-networkd-wait-online.service has
# WantedBy=network-online.target, so enabling it only has an effect if
# network-online.target itself is enabled or pulled in by some other unit.
Also=systemd-networkd-wait-online.service
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd: files systemd
group:  files systemd
shadow: files
gshadow:files

hosts:  files dns
networks:   files

protocols:  db files
services: 

Bug#965096: lxqt: LXQt Mount dialog hangs unresponsive when inserting LUKS encrypted USB volume

2020-07-15 Thread Bernhard Bodenstorfer
Package: lxqt
Version: 29
Severity: normal
Tags: a11y

Dear Maintainer,

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

The issue appeared from the beginning, right after the fresh installations of 
Debian 10.3 and 10.4 likewise with LXQt.

I have prepared a USB memory stick with two partitions shown as sdb1 and sdb4.
(The problem also affects at least one other similar USB-disk.)
The former partition sdb1 is just plain ext2, the latter is LUKS encrypted dos 
or ext2 file system
(I tried both file systems, both yield the hang, as I would expect, because 
before decryption the filesystem should be unknown to LXQt).
Note: When at earlier times, sdb4 carried just a plain ext2, the bug did not 
appear, so the memory stick appears physically undamaged.

The commands to create the encrypted drive were on the root command line (4 
being the alias for /dev/dm-0)
/sbin/cryptsetup luksFormat /dev/sdb4
/sbin/cryptsetup open /dev/sdb4 4
/sbin/mkdosfs -n SDIG4 /dev/dm-0
/sbin/cryptsetup close 4

Note that in the same session, directly after creation of the encrypted 
partition, unplugging and re-plugging the device did work fine and LXQt would 
properly ask for password and mount the encrypted partition as expected.

The bug, however, shows after a re-start of the computer. In this case, when I 
plug in the device, a Mount dialog comes up, but is immediately frozen (see 
attached unresponsive dialog screenshot). When I switch desktops hence and 
forth, the hanging dialog window keeps the background from the other desktop, 
i.e. does not refresh with its own content (see attached black dialog 
screenshot).

I can close the dialog window (accepting the warning "This window might be busy 
and is not responding. Do you want to terminate the application?"), and the 
LXQt desktop will grey out, leaving only the panel and my active windows, but 
no desktop icons.

When I log out and log in again, I can repeat the freeze by plugging in the 
device again.

--- WORK-AROUND ---

When the device with the encrypted partition is connected, I can still 
explicitly mount the volume from the root command line:
/sbin/cryptsetup open /dev/sdb4 4
This subsequently triggers a dialog asking for the root password and then 
mounts the device.

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


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

Kernel: Linux 4.19.0-9-686 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lxqt depends on:
ii  featherpad 0.9.4-2
ii  lximage-qt 0.14.1-1
ii  lxqt-about 0.14.1-1
ii  lxqt-admin 0.14.1-1
ii  lxqt-branding-debian [lxqt-branding]   0.14.0.3
ii  lxqt-core  29
ii  lxqt-openssh-askpass   0.14.1-1
ii  lxqt-powermanagement   0.14.1-1
ii  lxqt-sudo  0.14.1-2
ii  openbox [x-window-manager] 3.6.1-8
ii  pavucontrol3.0-4
ii  pavucontrol-qt 0.14.1-1
ii  qlipper1:5.1.2-1
ii  qps1.10.20-1
ii  qterminal  0.14.1-1
ii  qttranslations5-l10n   5.11.3-2
ii  sddm-theme-debian-elarun [sddm-theme]  0.18.0-1
ii  sddm-theme-debian-maui [sddm-theme]0.18.0-1
ii  xarchiver  1:0.5.4.14-1
ii  xfwm4 [x-window-manager]   4.12.5-1

Versions of packages lxqt recommends:
ii  audacious  3.10.1-1
ii  cmst   2019.01.13-1
ii  feathernotes   0.4.6-1
ii  firefox-esr [www-browser]  68.10.0esr-1~deb10u1
ii  gucharmap  1:11.0.3-3
ii  lynx [www-browser] 2.8.9rel.1-3
ii  meteo-qt   1.0.0-1
ii  network-manager-gnome  1.8.20-1.1
pn  preload
ii  qpdfview   0.4.17~beta1+git20180709-2
ii  quassel1:0.13.1-1+deb10u2
ii  screengrab 1.101-1
ii  smplayer   18.10.0~ds0-1
ii  smtube 18.3.0-1
ii  thunderbird1:68.10.0-1~deb10u1

Versions of packages lxqt suggests:
pn  calibre
pn  compton-conf   
pn  juffed 
pn  nomacs 
pn  obconf-qt  
pn  qt5-style-kvantum  
pn  qtpass 
pn  shutter
pn  vokoscreen 

-- no debconf information



Bug#964494: File system corruption with ext3 + kernel-4.19.0-9-amd64

2020-07-15 Thread Sarah Newman

On 7/7/20 8:13 PM, Ben Hutchings wrote:

Control: reassign -1 src:linux
Control: tag -1 moreinfo

On Tue, 2020-07-07 at 17:30 -0700, Sarah Newman wrote:

Package: linux-signed-amd64
Version: 4.19.0-9-amd64

We've had two separate reports now of debian buster users running
4.19.0-9-amd64 who experienced serious file system corruption.


Which version?  (I.e. what does "uname -v" or
"dpkg -s linux-image-4.19.0-9-amd64" say?)


- Both were using ext3
- Both are running Xen HVM, but I do not have reason to believe this to be 
related



I doubt it matters, but the two observed failures were on hosts with Xeon v2's 
(we're currently working on fixing that.)

New reports:

* Buster 4.19.0-6-amd64, ext3, uptime ~36 weeks, Xeon v4, no failure
* Buster 4.19.0-9-amd64, ext4, uptime ~6 days, Xeon v2, no failure (but it 
hasn't even been a week)
* Arch Linux v5.6.11, ext3, uptime ~9 weeks, Xeon v2, no failure

--Sarah



Bug#965041: [Pkg-openssl-devel] Bug#965041: libssl3: Please stop building legacy provider

2020-07-15 Thread Dimitri John Ledkov
Maybe /usr location is better. As those snippets should not need to be user
editable.

Similarly we could ship "openssl-enable-tls1.0" snippet.

Somehow users find it easy to install/remove packages to enable/disable
configuration.

On Thu, 16 Jul 2020, 03:57 Dimitri John Ledkov,  wrote:

>
>
> On Tue, 14 Jul 2020, 21:37 Kurt Roeckx,  wrote:
>
>> On Tue, Jul 14, 2020 at 06:22:50PM +0100, Dimitri John Ledkov wrote:
>> > Package: libssl3
>> > Version: 3.0.0~~alpha4-1
>> > Severity: important
>> >
>> > Dear Maintainer,
>> >
>> > Please stop building legacy provider. None of the algorithms it
>> > provides are useful, or needed at all.
>> >
>> > Please do not not build it nor ship it. Those who need to access that,
>> > can self build that code.
>> >
>> > Alternatively you may choose to provide legacy provider in a separate
>> > binary package, but imho it must not enter testing or stable releases.
>>
>> Applications that want to use the legacy provider will need to
>> get changed to load them. By default the algorithms will not be
>> available.
>>
>> I'm not sure that not shipping the file improves anything.
>>
>
> To make installing them, automatically opt into using them by loading them
> into default context with config files without changing applications.
>
> openssl package could ship `.include /etc/ssl/providers.d/` in ssl.conf.
>
> then libssl3-legacy and libssl3-fips could ship snippets in
> /etc/ssl/providers.d/*.conf, that upon installation load those providers
> system wide, in the default context.
>
> Without changing applications, a simple purge/install of a package would
> disable/enable a provider and "make things work" (i.e. fips only, or legacy
> enabled, etc.).
>
> This would also open up to have GOST and SM9 providers.
>
> Regards,
>
> Dimitri.
>
>>


Bug#965041: [Pkg-openssl-devel] Bug#965041: libssl3: Please stop building legacy provider

2020-07-15 Thread Dimitri John Ledkov
On Tue, 14 Jul 2020, 21:37 Kurt Roeckx,  wrote:

> On Tue, Jul 14, 2020 at 06:22:50PM +0100, Dimitri John Ledkov wrote:
> > Package: libssl3
> > Version: 3.0.0~~alpha4-1
> > Severity: important
> >
> > Dear Maintainer,
> >
> > Please stop building legacy provider. None of the algorithms it
> > provides are useful, or needed at all.
> >
> > Please do not not build it nor ship it. Those who need to access that,
> > can self build that code.
> >
> > Alternatively you may choose to provide legacy provider in a separate
> > binary package, but imho it must not enter testing or stable releases.
>
> Applications that want to use the legacy provider will need to
> get changed to load them. By default the algorithms will not be
> available.
>
> I'm not sure that not shipping the file improves anything.
>

To make installing them, automatically opt into using them by loading them
into default context with config files without changing applications.

openssl package could ship `.include /etc/ssl/providers.d/` in ssl.conf.

then libssl3-legacy and libssl3-fips could ship snippets in
/etc/ssl/providers.d/*.conf, that upon installation load those providers
system wide, in the default context.

Without changing applications, a simple purge/install of a package would
disable/enable a provider and "make things work" (i.e. fips only, or legacy
enabled, etc.).

This would also open up to have GOST and SM9 providers.

Regards,

Dimitri.

>


Bug#965095: Searx 0.17.0 with uwsgi throws Internal Server Error

2020-07-15 Thread Joseph Nuthalapati
Package: searx
Severity: grave
Version: 0.17.0+dfsg1-1


There appears to be a missing Python dependency (werkzeug.contrib) in
the new Searx 17.0 package uploaded to unstable.

Tested in Debian unstable container.

Error log from /var/log/uwsgi/app/searx.log

---
Traceback (most recent call last):

  File "/usr/lib/python3/dist-packages/searx/webapp.py", line 50, in

from werkzeug.contrib.fixers import ProxyFix
ModuleNotFoundError: No module named 'werkzeug.contrib'
Thu Jul 16 07:22:32 2020 - unable to load app 0 (mountpoint='')
(callable not found or import error)
Thu Jul 16 07:22:32 2020 - *** no app loaded. going in full dynamic mode ***
Traceback (most recent call last):

  File "/usr/lib/python3/dist-packages/searx/webapp.py", line 50, in

from werkzeug.contrib.fixers import ProxyFix
ModuleNotFoundError: No module named 'werkzeug.contrib'


-- 
Regards,
Joseph Nuthalapati



signature.asc
Description: OpenPGP digital signature


Bug#961230: guile-2.2 FTBFS with make-dfsg/4.3-1: ERROR: alternatives priority expects min version < 1000.

2020-07-15 Thread Rob Browning
Helmut Grohne  writes:

> It is surprising that this didn't fail with earlier versions of make.
> The shell substitution is clearly wrong. It is unclear what it is
> supposed to achieve. In any case, deleting these lines makes the build
> proceed.
>

Hah, I just hit and fixed this last night when I was updating us to
3.0.4 (see 3.0.4-1).  And yeah, that was wrong.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4



Bug#885195: [Pkg-electronics-devel] Bug#885195: Bug#885195: geda-gaf: please migrate to guile-2.2

2020-07-15 Thread Rob Browning
Bdale Garbee  writes:

> I'm not interested in maintaining pcb any more.

Does that mean geda-gaf etc?  If so might it make sense for you (or
who?) to file a removal request, i.e. ROM or similar?

(I can of course, but I suspect it'll be more quickly accepted if one of
 the existing maintainers does.)

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4



Bug#965054: guile-2.0 ftbfs on unstable (test failure)

2020-07-15 Thread Rob Browning
Matthias Klose  writes:

> After fixing the build with make 4.3, the build then fails with a test 
> failure.
> Only seen on amd64, not on other architectures.
>
> [...]
> make  check-TESTS
> make[4]: Entering directory '/<>/guile-2.0-2.0.13+1'
> Testing /<>/guile-2.0-2.0.13+1/meta/guile ...
> with GUILE_LOAD_PATH=/<>/guile-2.0-2.0.13+1/test-suite
> Running 00-initial-env.test
> Running 00-repl-server.test
> ERROR: 00-repl-server.test: repl-server: HTTP inter-protocol attack - 
> arguments:
> ((system-error "fport_write" "~A" ("Broken pipe") (32)))

I'll try to remember to look in a bit, but that rings a vague bell -- we
may have added some patches (debian, and/or later upstream) for issues
there.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4



Bug#965091: glibc: setgroups: Bad address [2.31/x32, regression from 2.30]

2020-07-15 Thread H.J. Lu
On Wed, Jul 15, 2020 at 5:22 PM Jessica Clarke  wrote:
>
> [H.J. Lu Cc'ed as author of what looks like the problematic commit]
>
> On Wed, 15 Jul 2020 23:47:27 +0200 (CEST) Thorsten Glaser 
>  wrote:
> > Some more analysis:
> >
> > We enter libc from openssh code with the correct values in rsi and rdi:
> >
> >
> > (gdb) u
> > => 0x56560e45 : call   0x5655d0b0 
> > (gdb) info r
> > rax0xfffe  65534
> > rbx0x5663a000  1449369600
> > rcx0x0 0
> > rdx0x0 0
> > rsi0xd2e0  4294955744
> > rdi0x1 1
> > rbp0x56641b50  1449401168
> > rsp0xd260  4294955616
> > r8 0x0 0
> > r9 0x0 0
> > r100xf7a8  4155017352
> > r110x246   582
> > r120x565d71d1  1448964561
> > r130x3 3
> > r140xe2cc  58060
> > r150x5663c730  1449379632
> > rip0x56560e45  1448480325
> > eflags 0x282   [ SF IF ]
> > cs 0x3351
> > ss 0x2b43
> > ds 0x2b43
> > es 0x2b43
> > fs 0x0 0
> > gs 0x0 0
> >
> >
> > Inside glibc, there’s an indirect call:
> >
> >
> > => 0xf79949f4 <__GI_setgroups+100>: call   rax
> > rax0xf7833500  4152571136
> > => 0xf7833500 <__nptl_setxid>:  push   r15
> >
> >
> > Some time in __nptl_setxid later, here’s the bug:
> >
> >
> > 1162in allocatestack.c
> > rax0xf77ca840  4152141888
> > rbx0xd230  4294955568
> > rcx0x0 0
> > rdx0x1 1
> > rsi0xd2e0  4294955744
> > rdi0xf77ca840  4152141888
> > rbp0xf77ca840  4152141888
> > rsp0xd1d0  4294955472
> > r8 0x0 0
> > r9 0x0 0
> > r100xf77caac0  4152142528
> > r110x246   582
> > r120xf784a360  4152664928
> > r130xf784a360  4152664928
>
> Looks like df76ff3a446a787a95cf74cb15c285464d73a93d broke this upstream
> (x32: Properly pass long to syscall [BZ #25810]).
>
> setgroups uses INLINE_SETXID_SYSCALL, which in turn passes its
> arguments through the various id fields in xid_command. Unfortunately,
> those are `long int`, and so, when the `const gid_t *list` argument
> gets later passed through INTERNAL_SYSCALL_NCS, it's treated as an
> integer argument and thus sign-extended, despite actually being a
> pointer. I think xid_command's id fields need to become __kernel_ulong
> or equivalent, with ARGIFY happening inside INLINE_SETXID_SYSCALL when
> it still knows what the types are.
>

Please open a glibc bug with a small testcase.

-- 
H.J.



Bug#965094: mirror submission for mirror.cov.ukservers.com

2020-07-15 Thread Liam Fleet
Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirror.cov.ukservers.com
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
Archive-http: /debian/
Maintainer: Liam Fleet 
Country: GB United Kingdom
Location: London
Sponsor: UK Dedicated Servers https://www.ukservers.com/
Comment: No rsync




Trace Url: http://mirror.cov.ukservers.com/debian/project/trace/
Trace Url: 
http://mirror.cov.ukservers.com/debian/project/trace/ftp-master.debian.org
Trace Url: 
http://mirror.cov.ukservers.com/debian/project/trace/mirror.cov.ukservers.com



Bug#946201: ibus: some keystrokes are taken in account

2020-07-15 Thread Changwoo Ryu
Control: retitle -1 ibus: some keystrokes are not taken into account
Control: tag -1 + unreproducible

It is welcome to help in reproducing this.

I couldn't reproduce this in my system or in a newly installed one.



Bug#965091: glibc: setgroups: Bad address [2.31/x32, regression from 2.30]

2020-07-15 Thread Jessica Clarke
[H.J. Lu Cc'ed as author of what looks like the problematic commit]

On Wed, 15 Jul 2020 23:47:27 +0200 (CEST) Thorsten Glaser  
wrote:
> Some more analysis:
> 
> We enter libc from openssh code with the correct values in rsi and rdi:
> 
> 
> (gdb) u
> => 0x56560e45 : call   0x5655d0b0 
> (gdb) info r
> rax0xfffe  65534
> rbx0x5663a000  1449369600
> rcx0x0 0
> rdx0x0 0
> rsi0xd2e0  4294955744
> rdi0x1 1
> rbp0x56641b50  1449401168
> rsp0xd260  4294955616
> r8 0x0 0
> r9 0x0 0
> r100xf7a8  4155017352
> r110x246   582
> r120x565d71d1  1448964561
> r130x3 3
> r140xe2cc  58060
> r150x5663c730  1449379632
> rip0x56560e45  1448480325
> eflags 0x282   [ SF IF ]
> cs 0x3351
> ss 0x2b43
> ds 0x2b43
> es 0x2b43
> fs 0x0 0
> gs 0x0 0
> 
> 
> Inside glibc, there’s an indirect call:
> 
> 
> => 0xf79949f4 <__GI_setgroups+100>: call   rax
> rax0xf7833500  4152571136
> => 0xf7833500 <__nptl_setxid>:  push   r15
> 
> 
> Some time in __nptl_setxid later, here’s the bug:
> 
> 
> 1162in allocatestack.c
> rax0xf77ca840  4152141888
> rbx0xd230  4294955568
> rcx0x0 0
> rdx0x1 1
> rsi0xd2e0  4294955744
> rdi0xf77ca840  4152141888
> rbp0xf77ca840  4152141888
> rsp0xd1d0  4294955472
> r8 0x0 0
> r9 0x0 0
> r100xf77caac0  4152142528
> r110x246   582
> r120xf784a360  4152664928
> r130xf784a360  4152664928

Looks like df76ff3a446a787a95cf74cb15c285464d73a93d broke this upstream
(x32: Properly pass long to syscall [BZ #25810]).

setgroups uses INLINE_SETXID_SYSCALL, which in turn passes its
arguments through the various id fields in xid_command. Unfortunately,
those are `long int`, and so, when the `const gid_t *list` argument
gets later passed through INTERNAL_SYSCALL_NCS, it's treated as an
integer argument and thus sign-extended, despite actually being a
pointer. I think xid_command's id fields need to become __kernel_ulong
or equivalent, with ARGIFY happening inside INLINE_SETXID_SYSCALL when
it still knows what the types are.

Jess



Bug#959828: systemctl: `Provides: systemd`, but doesn't provide what systemd does

2020-07-15 Thread Samuel Thibault
Hello,

My 2¢ on this: speech-dispatcher build-depends on systemd in order to
get systemd.pc and read systemdsystemunitdir from it, but that fails on
experimental buildds because they currently have systemctl installed
instead of systemd:

https://buildd.debian.org/status/package.php?p=speech-dispatcher=experimental

Of course, I could just hardcode the systemdsystemunitdir variable
instead of letting ./configure read it from systemd.pc, and be done with
the issue, but that seems very wrong to me. Adding a Build-conflicts
also looks quite wrong to me: should we really make packages know what
package provides-but-not-completely systemd?

Samuel



Bug#965033: debdiff

2020-07-15 Thread Kunal Mehta
I'm happy to NMU this since it's affecting some of my packages (zimlib,
libkiwix, zim-tools, etc.). debdiff is attached.

It's not clear to me why the dependency was commented out in the first
place, but it fixes the immediate issue. Let me know if that's OK and if
you'd like me to go ahead.

-- Kunal


diff -Nru meson-0.55.0/debian/changelog meson-0.55.0/debian/changelog
--- meson-0.55.0/debian/changelog   2020-07-12 07:29:15.0 -0700
+++ meson-0.55.0/debian/changelog   2020-07-15 15:48:39.0 -0700
@@ -1,3 +1,10 @@
+meson (0.55.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add missing dependency on python3-pkg-resources Closes: #965033.
+
+ -- Kunal Mehta   Wed, 15 Jul 2020 15:48:39 -0700
+
 meson (0.55.0-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru meson-0.55.0/debian/control meson-0.55.0/debian/control
--- meson-0.55.0/debian/control 2020-07-12 07:29:07.0 -0700
+++ meson-0.55.0/debian/control 2020-07-15 15:48:37.0 -0700
@@ -94,7 +94,7 @@
  ${misc:Depends},
  ${python3:Depends},
  ninja-build(>=1.6),
-# python3-pkg-resources,
+ python3-pkg-resources,
 Description: high-productivity build system
  Meson is a build system designed to increase programmer
  productivity. It does this by providing a fast, simple and easy to


Bug#965093: Please demote gnome-user-share to Recommends or move it from gnome-core to gnome

2020-07-15 Thread Michael Biebl
Package: gnome-core
Version: 1:3.30+2
Severity: wishlist

Hi,

please consider demoting gnome-user-share to Recommends or moving it
from gnome-core to gnome.


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

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

Versions of packages gnome-core depends on:
ii  adwaita-icon-theme3.36.1-2
ii  at-spi2-core  2.36.0-2
ii  baobab3.34.0-1
ii  caribou   0.4.21-7
ii  dconf-cli 0.36.0-1
ii  dconf-gsettings-backend   0.36.0-1
ii  eog   3.36.3-1
ii  epiphany-browser  3.36.3-1+b1
ii  evince3.36.7-1
ii  evolution-data-server 3.36.4-1
ii  firefox   78.0.2-1
ii  fonts-cantarell   0.111-2
ii  gdm3  3.36.2-1
ii  gedit 3.36.2-1
ii  gkbd-capplet  3.26.1-1
ii  glib-networking   2.64.3-2
ii  gnome-backgrounds 3.36.0-1
ii  gnome-bluetooth   3.34.1-1
ii  gnome-calculator  3.36.0-1
ii  gnome-characters  3.34.0-1
ii  gnome-contacts3.36.1-1
ii  gnome-control-center  1:3.36.4-1
ii  gnome-disk-utility3.36.1-1+b1
ii  gnome-font-viewer 3.34.0-2+b1
ii  gnome-keyring 3.36.0-1
ii  gnome-logs3.36.0-2
ii  gnome-menus   3.36.0-1
ii  gnome-online-accounts 3.36.0-1
ii  gnome-online-miners   3.34.0-2
ii  gnome-session 3.36.0-2
ii  gnome-settings-daemon 3.36.1-1
ii  gnome-shell   3.36.3-1
ii  gnome-shell-extensions3.36.2-1
ii  gnome-software3.36.1-2
ii  gnome-sushi   3.34.0-2
ii  gnome-system-monitor  3.36.0-1
ii  gnome-terminal3.36.2-1
ii  gnome-themes-extra3.28-1
ii  gnome-user-docs   3.36.2-1
pn  gnome-user-share  
ii  gsettings-desktop-schemas 3.36.1-1
ii  gstreamer1.0-packagekit   1.1.13-2+b1
ii  gstreamer1.0-plugins-base 1.16.2-4
ii  gstreamer1.0-plugins-good 1.16.2-3
ii  gstreamer1.0-pulseaudio   1.16.2-3
ii  gvfs-backends 1.44.1-1
ii  gvfs-fuse 1.44.1-1
ii  libatk-adaptor2.34.1-3
ii  libcanberra-pulse 0.30-7
ii  libglib2.0-bin2.64.4-1
ii  libpam-gnome-keyring  3.36.0-1
ii  libproxy1-plugin-gsettings0.4.15-13
ii  libproxy1-plugin-webkit   0.4.15-13
ii  nautilus  3.36.3-1
ii  pulseaudio13.0-5
ii  pulseaudio-module-bluetooth   13.0-5
ii  sound-theme-freedesktop   0.8-2
ii  system-config-printer-common  1.5.12-1
ii  system-config-printer-udev1.5.12-1
ii  totem 3.34.1-2+b1
ii  tracker   2.3.4-1+b1
ii  yelp  3.36.0-1
ii  zenity3.32.0-5

Versions of packages gnome-core recommends:
ii  libproxy1-plugin-networkmanager  0.4.15-13
ii  network-manager-gnome1.18.0-1

Versions of packages gnome-core suggests:
pn  gnome  

-- no debconf information



Bug#965001: strange version 2.1.0 beta4 fails tests with mpfr4 4.1.0

2020-07-15 Thread Martin Kelly
On Tue, Jul 14, 2020, 3:15 AM Vincent Lefevre  wrote:

> On 2020-07-14 09:48:18 +0200, Matthias Klose wrote:
> > There is no 2.1.0 beta4, just a beta1, so I don't know what was packaged
> in
> > February 2020.  However the tests now fail with mpfr 4.1.0, seems to be
> > consistent across all architectures:
> >
> > **
> > File "test/test_gmpy2_format.txt", line 157, in test_gmpy2_format.txt
> > Failed example:
> > c.__format__('e')
> > Differences (ndiff with -expected +actual):
> > - '3.3331e-01+5e+00j'
> > + '3.3331e-01+5.e+00j'
> > ?  +
>
> FYI, the old MPFR behavior was regarded as a bug:
>
>
> https://gforge.inria.fr/tracker/index.php?func=detail=21816_id=136=619
>
> There were 2 reasonable interpretations of the description in the
> MPFR manual that did not leave the output partly unspecified, and
> for each of them, some outputs were incorrect. The one that has
> been chosen is the one that is closer to ISO C's %e and it does
> not change the numerical output value (the only difference is
> trailing zeros).
>
> --
> Vincent Lefèvre  - Web: 
> 100% accessible validated (X)HTML - Blog: 
> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
>

Hi all,

Thanks for the bug report. Unfortunately I'm on a long hiking vacation with
no computer access until October and won't be able to look at this until
then. I welcome a non-maintainer upload if this needs a fix sooner.

I'm also CCing the upstream maintainer, who may have an opinion on that to
do here.

>


Bug#959661: buster-pu: package borgbackup/1.1.9-2+deb10u1

2020-07-15 Thread Cyril Brulebois
Hi Andrej,

Andrej Shadura  (2020-05-03):
> I’m proposing to upload an upstream patch fixing an index corruption
> in borgbackup leading to a data loss, see #953615.

I know stretch is about to get archived, but I was wondering whether it
would make sense to upload either 1.1.9-2~bpo9+2 or 1.1.9-2+deb10u1~bpo9+1
to stretch-backports before that happens.

(In the process of migrating stuff out of stretch systems, it was
spotted the version there was affected by this issue, so I've prepared
1.1.9-2+deb10u1~bpo9+1 packages locally, replaying the backports diff on
top of the updated package available in buster-proposed-updates.)

Thanks for your input.


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


signature.asc
Description: PGP signature


Bug#965092: Please package newer version with support for EBS direct snapshot writes

2020-07-15 Thread Josh Triplett
Package: python3-botocore
Version: 1.17.9+repack-1
Severity: wishlist
X-Debbugs-Cc: j...@joshtriplett.org

There's a new version of botocore (and awscli) available, which adds
support for the new APIs to directly write an EBS snapshot
(StartSnapshot, PutSnapshotBlock, CompleteSnapshot).



Bug#961016: (no subject)

2020-07-15 Thread Dmitry Smirnov
On Thursday, 16 July 2020 5:41:43 AM AEST Emmanuel Kasper wrote:
> I think there is a problem in the Depends of podman:

More likely there is a problem in Podman configuration.
"io.podman.service" should be restarted to pick-up configuration changes.

"runc" and "crun" can be used interchangeably.

-- 
Best wishes,
 Dmitry Smirnov.

---

The one permanent emotion of the inferior man is fear — fear of the
unknown, the complex, the inexplicable. What he wants beyond everything
else is safety.
-- H. L. Mencken

---

The overall lethality of COVID-19 (IFR) is about 0.1% thus in the range
of a strong seasonal influenza (flu).
-- https://swprs.org/studies-on-covid-19-lethality/


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


Bug#851771: php-gettext: CVE-2016-6175

2020-07-15 Thread Sunil Mohan Adapa
I seem to have attached the wrong set of patches to this bug earlier.
Here are the correct ones. Upstream bug already has the correct set of
patches.

-- 
Sunil
From 0a325e7847daf150885911706926b7b8f5d7a66e Mon Sep 17 00:00:00 2001
From: Sunil Mohan Adapa 
Date: Wed, 17 Jun 2020 14:07:30 -0700
Subject: [PATCH 1/2] Use custom parser for parsing plural expressions instead
 of eval()

- A simple operator-precedence parser that prioritizes simplicity and
readability. Avoid using eval() for evaluating plural expressions.
  - Fixes CVE-2016-6175.
  - Fixes upstream bug https://bugs.launchpad.net/php-gettext/+bug/1606184
  - Fixes Debian bug https://bugs.debian.org/851771

- Grammar for parsing code is same as the grammar for GNU gettext library:
  http://git.savannah.gnu.org/cgit/gettext.git/tree/gettext-runtime/intl/plural.y

- Extensive tests for various locales with help from Unicode's plurals rules.
Tests for invalid syntax and expression parsing.

Signed-off-by: Sunil Mohan Adapa 
---
 Makefile  |   4 +-
 gettext.php   |  53 +
 plurals.php   | 461 ++
 tests/PluralsTest.php | 351 
 4 files changed, 823 insertions(+), 46 deletions(-)
 create mode 100644 plurals.php
 create mode 100644 tests/PluralsTest.php

diff --git a/Makefile b/Makefile
index b56394b..eda1408 100644
--- a/Makefile
+++ b/Makefile
@@ -5,6 +5,7 @@ DIST_FILES = \
 	gettext.php \
 	gettext.inc \
 	streams.php \
+	plurals.php \
 	AUTHORS \
 	README  \
 	COPYING \
@@ -18,7 +19,8 @@ DIST_FILES = \
 	examples/locale/de_CH/LC_MESSAGES/messages.mo \
 	examples/update \
 	tests/LocalesTest.php \
-	tests/ParsingTest.php
+	tests/ParsingTest.php \
+	tests/PluralsTest.php
 
 check:
 	phpunit --verbose tests
diff --git a/gettext.php b/gettext.php
index 171d14e..0a121f7 100755
--- a/gettext.php
+++ b/gettext.php
@@ -21,6 +21,8 @@
 
 */
 
+require('plurals.php');
+
 /**
  * Provides a simple gettext replacement that works independently from
  * the system's gettext abilities.
@@ -269,41 +271,6 @@ class gettext_reader {
 }
   }
 
-  /**
-   * Sanitize plural form expression for use in PHP eval call.
-   *
-   * @access private
-   * @return string sanitized plural form expression
-   */
-  function sanitize_plural_expression($expr) {
-// Get rid of disallowed characters.
-$expr = preg_replace('@[^a-zA-Z0-9_:;\(\)\?\|\&=!<>+*/\%-]@', '', $expr);
-
-// Add parenthesis for tertiary '?' operator.
-$expr .= ';';
-$res = '';
-$p = 0;
-for ($i = 0; $i < strlen($expr); $i++) {
-  $ch = $expr[$i];
-  switch ($ch) {
-  case '?':
-$res .= ' ? (';
-$p++;
-break;
-  case ':':
-$res .= ') : (';
-break;
-  case ';':
-$res .= str_repeat( ')', $p) . ';';
-$p = 0;
-break;
-  default:
-$res .= $ch;
-  }
-}
-return $res;
-  }
-
   /**
* Parse full PO header and extract only plural forms line.
*
@@ -330,14 +297,14 @@ class gettext_reader {
 $this->load_tables();
 
 // cache header field for plural forms
-if (! is_string($this->pluralheader)) {
+if ($this->pluralheader !== NULL) {
   if ($this->enable_cache) {
 $header = $this->cache_translations[""];
   } else {
 $header = $this->get_translation_string(0);
   }
   $expr = $this->extract_plural_forms_header_from_po_header($header);
-  $this->pluralheader = $this->sanitize_plural_expression($expr);
+  $this->pluralheader = new PluralHeader($expr);
 }
 return $this->pluralheader;
   }
@@ -354,16 +321,12 @@ class gettext_reader {
   throw new InvalidArgumentException(
 "Select_string only accepts integers: " . $n);
 }
-$string = $this->get_plural_forms();
-$string = str_replace('nplurals',"\$total",$string);
-$string = str_replace("n",$n,$string);
-$string = str_replace('plural',"\$plural",$string);
+$plural_header = $this->get_plural_forms();
+$plural = $plural_header->expression->evaluate($n);
 
-$total = 0;
-$plural = 0;
+if ($plural < 0) $plural = 0;
+if ($plural >= $plural_header->total) $plural = $plural_header->total - 1;
 
-eval("$string");
-if ($plural >= $total) $plural = $total - 1;
 return $plural;
   }
 
diff --git a/plurals.php b/plurals.php
new file mode 100644
index 000..1c6ce12
--- /dev/null
+++ b/plurals.php
@@ -0,0 +1,461 @@
+
+
+   Drop in replacement for native gettext.
+
+   This file is part of PHP-gettext.
+
+   PHP-gettext is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 2 of the License, or
+   (at your option) any later version.
+
+   PHP-gettext is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or 

Bug#965074: cdc_ncm: ethernet multicast traffic is filtered out

2020-07-15 Thread Wxcafé
Hey! Thank you so much for the resubmission

I just tested the patches on 5.7.8 and it works perfectly!

Cheers

-- 
Wxcafé 

On Wed, 2020-07-15 at 20:44 +0200, Bjørn Mork wrote:
> FWIW, I made an attempt resubmitting these patches since it looked
> like
> I was part of the problem back in 2018 ;-)
> 
> I'd CCed you, and would appreciate it if you could test the
> series.  I
> don't have any cdc_ncm devices with multicast filter support AFAIK.
> 
> 
> Bjørn



Bug#965086: ssh: setgroups: Bad address [preauth]

2020-07-15 Thread Thorsten Glaser
Hi Colin,

>sshd.c:privsep_preauth_child.  But its setgroups() call seems
>straightforward, and I don't see how it could produce EFAULT:

thanks for also looking at it, yes, I tracked it down in gdb,
and the __nptl_setxid code is compiled differently, and I’m
fresh out of ideas how to track it further down, but yes, this
is most likely a bug in only glibc, so closing this one is
probably right.

Sorry for the noise, it’s where I first detected it, and I
feared something with seccomp or so happened again. For now,
I downgraded glibc, so the system is at all reachable.

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



Bug#965091: glibc: setgroups: Bad address [2.31/x32, regression from 2.30]

2020-07-15 Thread Thorsten Glaser
> So something clearly changed…

Compiler output, most probably. I cannot reproduce it. I tried:

struct xid_command
{
  int syscall_no;
  long int id[3];
  volatile int cntr;
  volatile int error; /* -1: no call yet, 0: success seen, >0: error 
seen.  */
};

extern void a_barrier(int *);

# define REGISTERS_CLOBBERED_BY_SYSCALL "cc", "r11", "cx"

/* NB: This also works when X is an array.  For an array X,  type of
   (X) - (X) is ptrdiff_t, which is signed, since size of ptrdiff_t
   == size of pointer, cast is a NOP.   */
#define TYPEFY1(X) __typeof__ ((X) - (X))
/* Explicit cast the argument.  */
#define ARGIFY(X) ((TYPEFY1 (X)) (X))
/* Create a variable 'name' based on type of variable 'X' to avoid
   explicit types.  */
#define TYPEFY(X, name) __typeof__ (ARGIFY (X)) name


#undef INTERNAL_SYSCALL_NCS
#define INTERNAL_SYSCALL_NCS(number, err, nr, args...)  
\
internal_syscall##nr (number, err, args)

#undef internal_syscall3
#define internal_syscall3(number, err, arg1, arg2, arg3)
\
({  
\
unsigned long int resultvar;
\
TYPEFY (arg3, __arg3) = ARGIFY (arg3);  
\
TYPEFY (arg2, __arg2) = ARGIFY (arg2);  
\
TYPEFY (arg1, __arg1) = ARGIFY (arg1);  
\
register TYPEFY (arg3, _a3) asm ("rdx") = __arg3;   
\
register TYPEFY (arg2, _a2) asm ("rsi") = __arg2;   
\
register TYPEFY (arg1, _a1) asm ("rdi") = __arg1;   
\
asm volatile (  
\
"syscall\n\t"   
\
: "=a" (resultvar)  
\
: "0" (number), "r" (_a1), "r" (_a2), "r" (_a3) 
\
: "memory", REGISTERS_CLOBBERED_BY_SYSCALL);
\
(long int) resultvar;   
\
})

int
foo(struct xid_command *cmdp)
{
  int result;
  asm volatile ("xor rsi,rsi\n\txor rdi,rdi" : : : "rsi", "rdi");
  result = INTERNAL_SYSCALL_NCS (cmdp->syscall_no, err, 3,
 cmdp->id[0], cmdp->id[1], cmdp->id[2]);
  a_barrier();
  return result;
}


Save as x.c then:

x86_64-linux-gnux32-gcc-10 -c -std=gnu11 -fgnu89-inline  -pipe -O2 -g -Wall 
-Wwrite-strings -Wundef -Werror -fmerge-all-constants -frounding-math 
-fstack-protector-strong -Wstrict-prototypes -Wold-style-definition 
-fmath-errno   -fpie   -ftls-model=initial-exec -D_LIBC_REENTRANT -DPIC -S 
-masm=intel x.c -Wno-error

This doesn’t yield any “movsxd” in the output, like in glibc, though:

 b32:   67 48 63 73 08  movsxd rsi,DWORD PTR [ebx+0x8]
 b37:   67 48 63 7b 04  movsxd rdi,DWORD PTR [ebx+0x4]
 b3c:   67 48 63 53 0c  movsxd rdx,DWORD PTR [ebx+0xc]
 b41:   67 8b 03moveax,DWORD PTR [ebx]
 b44:   0f 05   syscall

(disassembly of pthread_create.o from libpthread.a 2.31)

I’m unsure whether this is a glibc or gcc issue… without a reproducer
I’m stuck.

I’ll have to downgrade to 2.30 for now, to keep the system ssh-in-able…

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



Bug#544013: mysql-server-5.1: logrotate script cannot handle stopped mysqld

2020-07-15 Thread Francesc Zacarias
Hi!

I'm experiencing the same issue as described in this bug with debian sid
and mysql-server-5.7 (5.7.26-1+b1). I noticed that one out of three times
my system boots, logrotate service fails with the following error:

```
Jul 09 07:12:01 baal systemd[1]: Starting Rotate log files...
Jul 09 07:12:01 baal logrotate[851]: error: error running shared postrotate
script for '/var/log/mysql.log /var/log/mysql/*log>
Jul 09 07:12:01 baal systemd[1]: logrotate.service: Main process exited,
code=exited, status=1/FAILURE
Jul 09 07:12:01 baal systemd[1]: logrotate.service: Failed with result
'exit-code'.
Jul 09 07:12:01 baal systemd[1]: Failed to start Rotate log files.
```

Looking at journalctl, I can see that every time this issue occurs, mysqld
is started and logrotate fails *at the same time*:

```
Jul 09 07:12:01 baal mysqld[847]: 2020-07-09T06:12:01.283924Z 0 [Note]
/usr/sbin/mysqld: ready for connections.
Jul 09 07:12:01 baal mysqld[847]: Version: '5.7.26-1+b1'  socket:
'/var/run/mysqld/mysqld.sock'  port: 3306  (Debian)
...
Jul 09 07:12:01 baal systemd[1]: logrotate.service: Main process exited,
code=exited, status=1/FAILURE
Jul 09 07:12:01 baal systemd[1]: logrotate.service: Failed with result
'exit-code'.
```

This and the fact that the issue does not reproduce every time makes me
suspect that is a race-condition between logrotate and mysqld. Looking at
the code in /etc/logrotate.d/mysql-server it seems like logrotate first
checks if mysql is running before issuing the "mysqladmin flush-logs"
command. That check is done by issuing "mysqladmin ping" (this also checks
that /etc/mysql/debian.cnf is valid). If this check fails, then it will try
to verify if the mysql process exists. If it does, then it will fail with
an exit code = 1, which causes the error messages in my logs above.
I'm sure you already noticed the issue here: what if mysqld has not started
yet by the time "mysqladmin ping" runs, but it's up right by the time
killall is executed? Apparently, this happens quite often in my system.

To fix this, I suggest reverting the checks: first validate that mysqld is
running. If not, then there is no reason to issue "mysqladmin flush-logs"
and the script can finish successfully. If mysqld is running *and*
"mysqladmin ping" fails, then it should definitely throw an error.

This approach is not completely free of race-conditions either, but it
should be more rare. I'm attaching a patch with the solution I just
described. I've had this patch applied to my system for a week and the
issue has not been reproduced since. The *best* solution would be to simply
attempt to apply "flush-logs" and react differently depending on the exit
code. Unfortunately, it seems like mysqladmin does not return different
exit codes on different errors (in my tests it always returns 1), so this
approach is not possible at the moment.

Please, apply this patch and fix this issue!

Kind regards,
Francesc
--- mysql-server	2019-06-14 16:19:35.0 +0100
+++ /etc/logrotate.d/mysql-server	2020-07-09 07:49:37.853383663 +0100
@@ -11,15 +11,14 @@
 	sharedscripts
 	postrotate
 		test -x /usr/bin/mysqladmin || exit 0
+		killall -q -s0 -umysql mysqld || exit 0
 		# If this fails, check debian.conf! 
 		MYADMIN="/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf"
 		if [ -z "`$MYADMIN ping 2>/dev/null`" ]; then
 		  # Really no mysqld or rather a missing debian-sys-maint user?
 		  # If this occurs and is not a error please report a bug.
 		  #if ps cax | grep -q mysqld; then
-		  if killall -q -s0 -umysql mysqld; then
- 		exit 1
-		  fi 
+		  exit 1
 		else
 		  $MYADMIN flush-logs
 		fi


Bug#965051: proftpd-basic: Enable more modules

2020-07-15 Thread Hilmar Preuße
Am 15.07.2020 um 06:12 teilte Hilmar Preusse mit:

Hi,

> We should go through the list of known modules and features and enable
> them if available. In [1] a user requested a module, we don't build out
> of the box yet. Well, bad example...it causes FTBFS, but we could look
> for others.
> 
Just for the records: FTBFS for mod_digest is solved in 1.3.7rc4.

H.
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature


Bug#965077: MySQL database with "SQLAUthTypes Backend" doesn't work anymore in buster

2020-07-15 Thread Hilmar Preuße
Control: tags -1 + fixed-upstream

Am 15.07.2020 um 19:11 teilte Andreas Trottmann mit:

Hi Andreas,

many thanks for the report and the patch!

> I am using an admin tool that saves account information in a MySQL /
> MariaDB-Datbase and uses the "password()" function to obfuscate stored
> passwords.
> 
This issue seems to be solved in the (to be released) 1.3.7 version [1]
& [2], but not in 1.3.6. We'll release next Debian release w/ 1.3.7.
Should we try to get the issue solved for next buster point release? In
this case the issue should be at least severity important.

Hilmar

[1]
https://github.com/proftpd/proftpd/commit/9ec86ef2db29ea9b89c7908934a6e877dd1bf6fa#diff-41d5e11169ba0306af3880fb87942edf
[2] http://bugs.proftpd.org/show_bug.cgi?id=4281
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature


Bug#835485: nsntrace: please upload to jessie-backports

2020-07-15 Thread Sudip Mukherjee
Control: close -1

On Fri, Aug 26, 2016 at 10:05:14AM +0100, Chris Lamb wrote:
> Source: nsntrace
> Version: 0~20160806-1
> Severity: wishlist
> 
> Hi,
> 
> Please backport to jessie-backports; would be very useful for me when
> building packages in stable.

As jessie has reached its EOL, this should not be required any more.
Closing this.

--
Regards
Sudip



Bug#965091: glibc: setgroups: Bad address [2.31/x32, regression from 2.30]

2020-07-15 Thread Thorsten Glaser
Some more analysis:

We enter libc from openssh code with the correct values in rsi and rdi:


(gdb) u
=> 0x56560e45 : call   0x5655d0b0 
(gdb) info r
rax0xfffe  65534
rbx0x5663a000  1449369600
rcx0x0 0
rdx0x0 0
rsi0xd2e0  4294955744
rdi0x1 1
rbp0x56641b50  1449401168
rsp0xd260  4294955616
r8 0x0 0
r9 0x0 0
r100xf7a8  4155017352
r110x246   582
r120x565d71d1  1448964561
r130x3 3
r140xe2cc  58060
r150x5663c730  1449379632
rip0x56560e45  1448480325
eflags 0x282   [ SF IF ]
cs 0x3351
ss 0x2b43
ds 0x2b43
es 0x2b43
fs 0x0 0
gs 0x0 0


Inside glibc, there’s an indirect call:


=> 0xf79949f4 <__GI_setgroups+100>: call   rax
rax0xf7833500  4152571136
=> 0xf7833500 <__nptl_setxid>:  push   r15


Some time in __nptl_setxid later, here’s the bug:


1162in allocatestack.c
rax0xf77ca840  4152141888
rbx0xd230  4294955568
rcx0x0 0
rdx0x1 1
rsi0xd2e0  4294955744
rdi0xf77ca840  4152141888
rbp0xf77ca840  4152141888
rsp0xd1d0  4294955472
r8 0x0 0
r9 0x0 0
r100xf77caac0  4152142528
r110x246   582
r120xf784a360  4152664928
r130xf784a360  4152664928
r140xf78482c8  4152656584
r150x40ca  1073742026
rip0xf7833752  4152571730
eflags 0x246   [ PF ZF IF ]
cs 0x3351
ss 0x2b43
ds 0x2b43
es 0x2b43
fs 0x0 0
gs 0x0 0

=> 0xf7833752 <__nptl_setxid+594>:  movsxd rsi,DWORD PTR [ebx+0x8]
   0xf7833757 <__nptl_setxid+599>:  movsxd rdi,DWORD PTR [ebx+0x4]
   0xf783375c <__nptl_setxid+604>:  movsxd rdx,DWORD PTR [ebx+0xc]
(gdb) t
=> 0xf7833752 <__nptl_setxid+594>:  movsxd rsi,DWORD PTR [ebx+0x8]

1162in allocatestack.c
rax0xf77ca840  4152141888
rbx0xd230  4294955568
rcx0x0 0
rdx0x1 1
rsi0xd2e0  -11552
rdi0xf77ca840  4152141888
rbp0xf77ca840  4152141888
rsp0xd1d0  4294955472
r8 0x0 0
r9 0x0 0
r100xf77caac0  4152142528
r110x246   582
r120xf784a360  4152664928
r130xf784a360  4152664928
r140xf78482c8  4152656584
r150x40ca  1073742026
rip0xf7833757  4152571735
eflags 0x246   [ PF ZF IF ]
cs 0x3351
ss 0x2b43
ds 0x2b43
es 0x2b43
fs 0x0 0
gs 0x0 0


Looking at the next instructions…


=> 0xf7833757 <__nptl_setxid+599>:  movsxd rdi,DWORD PTR [ebx+0x4]
   0xf783375c <__nptl_setxid+604>:  movsxd rdx,DWORD PTR [ebx+0xc]
   0xf7833761 <__nptl_setxid+609>:  moveax,DWORD PTR [ebx]
   0xf7833764 <__nptl_setxid+612>:  syscall 


… this most likely corresponds to this C source:


 1162   result = INTERNAL_SYSCALL_NCS (cmdp->syscall_no, err, 3,
 1163  cmdp->id[0], cmdp->id[1], cmdp->id[2]);


Diffing glibc-2.30..glibc-2.31 shows no noticeable delta
in nptl/allocatestack.c so going on.

struct xid_command (nptl/descr.h) also did not change.

Looking at pthread_create.o (whyever this is the file __nptl_setxid
ends up being in) from 2.30-8, the code in question looks like this:

 c3d:   67 8b 75 08 movesi,DWORD PTR [ebp+0x8]
 c41:   67 8b 7d 04 movedi,DWORD PTR [ebp+0x4]
 c45:   67 8b 55 0c movedx,DWORD PTR [ebp+0xc]
 c49:   67 8b 45 00 moveax,DWORD PTR [ebp+0x0]
 c4d:   0f 05   syscall 

So something clearly changed…

//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 

Bug#964631: diagnostics: FTBFS: FAIL: stacktrace

2020-07-15 Thread Sudip Mukherjee
On Thu, Jul 09, 2020 at 01:08:43PM +0200, Lucas Nussbaum wrote:
> Source: diagnostics
> Version: 0.3.3-12
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20200709 ftbfs-bullseye
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.

I was curious to see why it failed and did a bisect based on the snapshots.
It built fine with the snapshot of 20200706T204334Z but failed with the
snapshot of 20200707T024523Z. And the only change between these two snapshot
was 'binutils' which moved to 2.34.90.20200706-1.
Any idea what might have caused this?

--
Regards
Sudip



Bug#965086: ssh: setgroups: Bad address [preauth]

2020-07-15 Thread Colin Watson
On Wed, Jul 15, 2020 at 10:41:11PM +0200, Thorsten Glaser wrote:
> Package: openssh-server
> Version: 1:8.3p1-1
> Severity: grave
> Justification: renders package unusable
> 
> After an upgrade of libc6 today, I can no longer log into my
> system using ssh:

Would it perhaps make sense to reassign this to libc6 first, unless and
until it seems to be a definite bug in OpenSSH?  I'd have thought that
this sort of compatibility break would be a glibc bug in any event (if
nothing else it'd need a Breaks even if the fix is in OpenSSH), perhaps
unless OpenSSH is doing something clearly undefined.

Looking at your -ddd output, the failure must be within
sshd.c:privsep_preauth_child.  But its setgroups() call seems
straightforward, and I don't see how it could produce EFAULT:

gid_t gidset[1];
[...]
gidset[0] = privsep_pw->pw_gid;
if (setgroups(1, gidset) == -1)
fatal("setgroups: %.100s", strerror(errno));

Is it possible that this is x32-specific in some way?  I haven't been
able to reproduce it on amd64 so far.  The implementation of setgroups()
also doesn't seem to have changed between the glibc-2.30 and glibc-2.31
tags upstream, though I haven't looked at the Debian patches.

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



Bug#963750: RM: chef -- ROM; trademark issues

2020-07-15 Thread Sean Whitton
Hello Antonio, Stefano,

On Wed 15 Jul 2020 at 10:57AM -07, Stefano Rivera wrote:

> I think your analysis is correct. The source is Apache-2.0 licensed, but
> with a renaming requirement. There is a collaborative effort to maintain
> a renamed source, cinc, which we've been shipping, but we haven't
> followed through on a complete renaming.
>
> This is an RoM request, the maintainers have lost interest in working
> with an upstream that imposes rules like this.

Normally a maintainer losing interest in this way would mean orphaning,
not removal, which makes things easier for someone who wants to pick it
up.

In this case, however, it seems the package would have to go through NEW
anyway so that the packages could be renamed -- even if the arguments
posted to the Ubuntu bug by Steve Langasek are valid, and we don't
change binary paths, we would surely want to rename the source packages.

So I'm going ahead with removal.

This action by one member of the FTP Team should not be interpreted as
any sort of Debian project opinion, or even FTP Team opinion, about the
acceptability of the versions of the packages I'm removing.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#965091: glibc: setgroups: Bad address [2.31/x32, regression from 2.30]

2020-07-15 Thread Thorsten Glaser
Package: libc6
Version: 2.31-1
Severity: grave
Justification: renders package unusable

This is related to #965086 and #965087 (and, in fact, possibly
causing them). After a glibc upgrade half the system services
(postfix, sshd, apt-get(!)) don’t work any more.

Downgrading with dpkg -i the following set of packages fixes it:

libc-bin_2.30-8_x32.deb
libc-dev-bin_2.30-8_x32.deb
libc-l10n_2.30-8_all.deb
libc6-dbg_2.30-8_x32.deb
libc6-dev_2.30-8_x32.deb
libc6_2.30-8_amd64.deb
libc6_2.30-8_i386.deb
libc6_2.30-8_x32.deb
locales-all_2.30-8_x32.deb
locales_2.30-8_all.deb
unscd_0.53-1+b3_x32.deb

Snippet from strace:

[…]
9839  getpid()  = 9839
9839  chroot("/run/sshd")   = 0
9839  chdir("/")= 0
9839  write(7, "\0\0\0$\0\0\0\7\0\0\0\34privsep user:group 1"..., 40) = 40
9839  setgroups(1, 0xff866750 
9794  <... poll resumed>)   = 1 ([{fd=6, revents=POLLIN}])
9839  <... setgroups resumed>)  = -1 EFAULT (Bad address)
9794  read(6,  
9839  write(7, "\0\0\0\36\0\0\0\1\0\0\0\26setgroups: Bad addre"..., 34 

[…]

Noticeable: the sign-extended address.

I haven’t yet managed to reproduce this in a stand-alone program.

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

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

Versions of packages libc6 depends on:
ii  libcrypt1  1:4.4.16-1
ii  libgcc-s1  10.1.0-6

Versions of packages libc6 recommends:
ii  libidn2-0  2.3.0-1

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

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


Bug#962720: gst-plugins-bad1.0: diff for NMU version 1.16.2-2.2

2020-07-15 Thread Sebastian Ramacher
Control: tags 962720 + pending

Dear maintainer,

I've prepared an NMU for gst-plugins-bad1.0 (versioned as 1.16.2-2.2) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Cheers
-- 
Sebastian Ramacher
diff -Nru gst-plugins-bad1.0-1.16.2/debian/build-deps gst-plugins-bad1.0-1.16.2/debian/build-deps
--- gst-plugins-bad1.0-1.16.2/debian/build-deps	2019-12-04 14:34:03.0 +0100
+++ gst-plugins-bad1.0-1.16.2/debian/build-deps	2020-07-15 22:55:32.0 +0200
@@ -64,7 +64,7 @@
 libsndfile1-dev (>= 1.0.16)
 libsoundtouch-dev (>= 1.5.0)
 libspandsp-dev
-libsrt-dev
+libsrt-gnutls-dev
 libsrtp2-dev (>= 2.1)
 libssl-dev
 libtool (>= 2.2.6)
diff -Nru gst-plugins-bad1.0-1.16.2/debian/build-deps.in gst-plugins-bad1.0-1.16.2/debian/build-deps.in
--- gst-plugins-bad1.0-1.16.2/debian/build-deps.in	2019-12-04 14:34:01.0 +0100
+++ gst-plugins-bad1.0-1.16.2/debian/build-deps.in	2020-07-15 22:48:09.0 +0200
@@ -80,6 +80,6 @@
 libopenmpt-dev
 libnice-dev (>= 0.1.14)
 libpango1.0-dev (>= 1.22)
-libsrt-dev
+libsrt-gnutls-dev
 libaom-dev
 libusrsctp-dev
diff -Nru gst-plugins-bad1.0-1.16.2/debian/changelog gst-plugins-bad1.0-1.16.2/debian/changelog
--- gst-plugins-bad1.0-1.16.2/debian/changelog	2020-02-05 22:46:23.0 +0100
+++ gst-plugins-bad1.0-1.16.2/debian/changelog	2020-07-15 22:56:22.0 +0200
@@ -1,3 +1,16 @@
+gst-plugins-bad1.0 (1.16.2-2.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Gianfranco Costamagna ]
+  * Replace libsrt-dev with libsrt-gnutls-dev
+  * Fix build with make 4.3 (Closes: #962720)
+
+  [ Sebastian Ramacher ]
+  * Apply upstream patch to build with new vulkan
+
+ -- Sebastian Ramacher   Wed, 15 Jul 2020 22:56:22 +0200
+
 gst-plugins-bad1.0 (1.16.2-2.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru gst-plugins-bad1.0-1.16.2/debian/control gst-plugins-bad1.0-1.16.2/debian/control
--- gst-plugins-bad1.0-1.16.2/debian/control	2019-12-04 14:34:03.0 +0100
+++ gst-plugins-bad1.0-1.16.2/debian/control	2020-07-15 22:55:32.0 +0200
@@ -29,7 +29,6 @@
libdrm-dev (>= 2.4.55) [linux-any],
wayland-protocols (>= 1.4) [linux-any],
libvulkan-dev [linux-any],
-   libsrt-dev [linux-any],
libgstreamer1.0-dev (>= 1.16.2),
gstreamer1.0-doc,
gstreamer1.0-plugins-base (>= 1.16.2),
@@ -81,7 +80,7 @@
libsndfile1-dev (>= 1.0.16),
libsoundtouch-dev (>= 1.5.0),
libspandsp-dev,
-   libsrt-dev,
+   libsrt-gnutls-dev,
libsrtp2-dev (>= 2.1),
libssl-dev,
libtool (>= 2.2.6),
diff -Nru gst-plugins-bad1.0-1.16.2/debian/patches/29bf8d8528ec694f65c8fae310adac996322cc74.patch gst-plugins-bad1.0-1.16.2/debian/patches/29bf8d8528ec694f65c8fae310adac996322cc74.patch
--- gst-plugins-bad1.0-1.16.2/debian/patches/29bf8d8528ec694f65c8fae310adac996322cc74.patch	1970-01-01 01:00:00.0 +0100
+++ gst-plugins-bad1.0-1.16.2/debian/patches/29bf8d8528ec694f65c8fae310adac996322cc74.patch	2020-07-15 22:53:46.0 +0200
@@ -0,0 +1,46 @@
+From 29bf8d8528ec694f65c8fae310adac996322cc74 Mon Sep 17 00:00:00 2001
+From: "Jan Alexander Steffens (heftig)" 
+Date: Sat, 9 May 2020 19:59:46 +0200
+Subject: [PATCH] vulkan: Drop use of VK_RESULT_BEGIN_RANGE
+
+This was removed in Vulkan 1.2.140.
+
+> Shortly after 2020-04-24, we will be removing the automatically
+> generated `VK_*_BEGIN_RANGE`, `VK_*_END_RANGE`, and `VK_*_RANGE_SIZE`
+> tokens from the Vulkan headers. These tokens are currently defined for
+> some enumerated types, but are explicitly not part of the Vulkan API.
+> They existed only to support some Vulkan implementation internals,
+> which no longer require them. We will be accepting comments on this
+> topic in [#1230], but we strongly suggest any external projects using
+> these tokens immediately migrate away from them.
+
+[#1230]: https://github.com/KhronosGroup/Vulkan-Docs/issues/1230
+---
+ ext/vulkan/vkerror.c | 4 +---
+ 1 file changed, 1 insertion(+), 3 deletions(-)
+
+diff --git a/ext/vulkan/vkerror.c b/ext/vulkan/vkerror.c
+index 3fec27e4d..c91589d9b 100644
+--- a/ext/vulkan/vkerror.c
 b/ext/vulkan/vkerror.c
+@@ -27,7 +27,7 @@
+ #include "vkerror.h"
+ 
+ /* *INDENT-OFF* */
+-static const struct 
++static const struct
+ {
+   VkResult result;
+   const char *str;
+@@ -63,8 +63,6 @@ _vk_result_to_string (VkResult result)
+ 
+   if (result >= 0)
+ return NULL;
+-  if (result < VK_RESULT_BEGIN_RANGE)
+-return "Unknown Error";
+ 
+   for (i = 0; i < G_N_ELEMENTS (vk_result_string_map); i++) {
+ if (result == vk_result_string_map[i].result)
+-- 
+2.26.2
+
diff -Nru gst-plugins-bad1.0-1.16.2/debian/patches/fix-build-with-make-4.3.patch gst-plugins-bad1.0-1.16.2/debian/patches/fix-build-with-make-4.3.patch
--- gst-plugins-bad1.0-1.16.2/debian/patches/fix-build-with-make-4.3.patch	

Bug#965089: singular-ui-emacs: ESingular fails on fresh installation (missing .emacs-singular)

2020-07-15 Thread Volker Diels-Grabsch
Package: singular-ui-emacs
Version: 1:4.1.1-p2+ds-3
Severity: normal

Dear Maintainer,

On a fresh installation, the ESingular command fails with:

$ ESingular
Error: Can't find emacs load file for Singular mode.
 Expected it at /usr/bin/../share/singular/emacs/.emacs-singular

However, it does work when telling it to use "singular.el" instead
of that non-existing file:

$ ESingular --emacs-load /usr/share/singular/emacs/singular.el

To fix this issue, I propose to either make that one the default,
or to provide a new file /usr/share/singular/emacs/.emacs-singular
in the package.


Regards,
Volker



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

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

Versions of packages singular-ui-emacs depends on:
ii  emacs  1:26.1+1-3.2+deb10u1
ii  emacs-gtk [emacs]  1:26.1+1-3.2+deb10u1
ii  libc6  2.28-10
ii  libgcc11:8.3.0-6
ii  libmpfr6   4.0.2-1
ii  libncurses66.1+20181013-2+deb10u2
ii  libreadline7   7.0-5
ii  libsingular4m1 1:4.1.1-p2+ds-3
ii  libstdc++6 8.3.0-6
ii  libtinfo6  6.1+20181013-2+deb10u2
ii  singular-ui1:4.1.1-p2+ds-3

Versions of packages singular-ui-emacs recommends:
pn  singular-doc  

singular-ui-emacs suggests no packages.

-- no debconf information



Bug#965090: singular-ui-emacs: Wrong option name in error message

2020-07-15 Thread Volker Diels-Grabsch
Package: singular-ui-emacs
Version: 1:4.1.1-p2+ds-3
Severity: minor

Dear Maintainer,

When running ESingular and its Emacs load file is missing, the
following error message occurs:

Error: Can't find emacs load file for Singular mode.
 Expected it at /usr/bin/../share/singular/emacs/.emacs-singular
 Specify with --emacs_load option,
 or set ESINGULAR_EMACS_LOAD environment variable,
 or put file '.emacs-singular' in your home directory.
Use `ESingular --help' for a complete list of options

This error message mentions the option "--emacs_load", which
doesn't exist.  It is neamed "--emacs-load" instead.

It would be great if this error message was fixed.

As a side node, it wouldn't harm to run "realpath" over the
directory name, so that the error message points to
"/usr/share/singular/emacs/" rather than
"/usr/bin/../share/singular/emacs/".


Regards,
Volker



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

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

Versions of packages singular-ui-emacs depends on:
ii  emacs  1:26.1+1-3.2+deb10u1
ii  emacs-gtk [emacs]  1:26.1+1-3.2+deb10u1
ii  libc6  2.28-10
ii  libgcc11:8.3.0-6
ii  libmpfr6   4.0.2-1
ii  libncurses66.1+20181013-2+deb10u2
ii  libreadline7   7.0-5
ii  libsingular4m1 1:4.1.1-p2+ds-3
ii  libstdc++6 8.3.0-6
ii  libtinfo6  6.1+20181013-2+deb10u2
ii  singular-ui1:4.1.1-p2+ds-3

Versions of packages singular-ui-emacs recommends:
pn  singular-doc  

singular-ui-emacs suggests no packages.

-- no debconf information



Bug#965088: onionshare: please demote python3-pyqt5

2020-07-15 Thread Jakub Wilk

Package: onionshare
Version: 2.2-2
Severity: wishlist

onionshare has currently python3-pyqt5 in Depends. But as I understand 
it, this package is only needed for the GUI, whereas the CLI could work 
fine without it. I'd like to run onionshare on a headless system without 
installing hundreds of megabytes of X11 and Qt libraries.


Please consider either demoting python3-pyqt5 to Recommends or putting 
the GUI and the CLI in separate packages.


--
Jakub Wilk



Bug#965075: postfixadmin: wrong alias in postfixadmin conf-available for apache2

2020-07-15 Thread picca...@truelite.it
Package: postfixadmin
Version: 3.2.1-2
Severity: normal

Dear Maintainer,

The content of /etc/apache2/conf-available/postfixadmin.conf installed
by the package contain:

Alias /postfixadmin /usr/share/postfixadmin

not changed after upgrading from squeeze, and this configuration make
the package unusable when connecting with a browsed with an error:

The Postfix Admin directory layout changed. Please update your
webserver config so that the DocumentRoot or Alias points to the
directory

after I modified it in:

Alias /postfixadmin /usr/share/postfixadmin/public

as in the attached version of the file, it works. 

This make the software unusable and it's a trivial change, so I
strongly support a package upgrade.

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

Kernel: Linux 5.4.44-2-pve (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages postfixadmin depends on:
ii  apache2 [httpd] 2.4.38-3+deb10u3
ii  dbconfig-common 2.0.11+deb10u1
ii  debconf 1.5.71
ii  default-mysql-client1.0.5
ii  libapache2-mod-php  2:7.3+69
ii  libapache2-mod-php7.3 [libapache2-mod-php]  7.3.19-1~deb10u1
ii  php-imap2:7.3+69
ii  php-mbstring2:7.3+69
ii  php-mysql   2:7.3+69
ii  php7.3-imap [php-imap]  7.3.19-1~deb10u1
ii  php7.3-mbstring [php-mbstring]  7.3.19-1~deb10u1
ii  php7.3-mysql [php-mysqlnd]  7.3.19-1~deb10u1
ii  wwwconfig-common0.3.0

Versions of packages postfixadmin recommends:
ii  dovecot-core1:2.3.4.1-5+deb10u2
ii  mariadb-server  1:10.3.22-0+deb10u1
ii  mariadb-server-10.3 [virtual-mysql-server]  1:10.3.22-0+deb10u1
ii  php7.3-cli [php-cli]7.3.19-1~deb10u1
ii  postfix-mysql   3.4.10-0+deb10u1
pn  zendframework   

postfixadmin suggests no packages.

-- Configuration Files:
/etc/apache2/conf-available/postfixadmin.conf changed:
Alias /postfixadmin /usr/share/postfixadmin/public

/etc/postfixadmin/config.inc.php changed:
http://postfixadmin.sf.net 
 * 
 * @version $Id: config.inc.php 1876 2016-10-20 21:26:13Z christian_boltz $ 
 * @license GNU GPL v2 or later. 
 * 
 * File: config.inc.php
 * Contains configuration options.
 */
// Debian: This loads the automatic generated DB credentials from 
// /etc/postfixadmin/dbconfig.inc.php
require_once('dbconfig.inc.php');
if (!isset($dbserver) || empty($dbserver)) {
$dbserver='localhost';
}
/*
 *   
 * You have to set $CONF['configured'] = true; before the
 * application will run!
 * Doing this implies you have changed this file as required.
 * i.e. configuring database etc; specifying setup.php password etc.
 */
$CONF['configured'] = true;
// In order to setup Postfixadmin, you MUST specify a hashed password here.
// To create the hash, visit setup.php in a browser and type a password into 
the field,
// on submission it will be echoed out to you as a hashed value.
$CONF['setup_password'] = 
'd89c4dede234349e1a380f0ae5e468ec:15f91900f502220ea0fe410c951432326c5065a2';
// Language config
// Language files are located in './languages', change as required..
$CONF['default_language'] = 'it';
// Hook to override or add translations in $PALANG
// Set to the function name you want to use as hook function (see language_hook 
example function below)
$CONF['language_hook'] = '';
/*
language_hook example function
 
Called if $CONF['language_hook'] == ''
Allows to add or override $PALANG interface texts.
If you add new texts, please always prefix them with 'x_' (for example 
$PALANG['x_mytext'] = 'foo') to avoid they clash with texts that might be
added to languages/*.lang in future versions of PostfixAdmin.
Please also make sure that all your added texts are included in all
sections - that includes all 'case "XY":' sections and the 'default:'
section (for users that don't have any of the languages specified
in the 'case "XY":' section). 
Usually the 'default:' section should contain english text.
If you modify an existing text/translation, please consider to report it
to the bugtracker on http://sf.net/projects/postfixadmin so that all users
can benefit from the corrected text/translation.
Returns: modified $PALANG array

Bug#965085: reportbug: s to add x-debbugs-cc recipients is gone

2020-07-15 Thread Thorsten Glaser
Package: reportbug
Version: 7.7.0
Severity: normal

[…]
Report will be sent to Debian Bug Tracking System 
Submit this report on openssh-server (e to edit) [Y|n|a|c|e|i|l|m|p|q|d|t|?]? s
Invalid selection.

-- Package-specific info:
** Environment settings:
EDITOR="/usr/bin/sensible-editor"
VISUAL="/usr/bin/jupp"
DEBEMAIL="Thorsten Glaser "
INTERFACE="text"

** /home/tglase/.reportbugrc:
reportbug_version "6.6.6"
mode advanced
ui text

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

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

Versions of packages reportbug depends on:
ii  apt2.1.7
ii  python33.8.2-3
ii  python3-reportbug  7.7.0
ii  sensible-utils 0.0.12+nmu1

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail  
ii  debconf-utils   1.5.74
ii  debsums 3.0.0
pn  dlocate 
pn  emacs-bin-common
ii  file1:5.38-5
ii  gnupg   2.2.20-1
ii  postfix [mail-transport-agent]  3.5.4-1
pn  python3-urwid   
pn  reportbug-gtk   
ii  xdg-utils   1.1.3-2

Versions of packages python3-reportbug depends on:
ii  apt2.1.7
ii  file   1:5.38-5
ii  python33.8.2-3
ii  python3-apt2.1.3
ii  python3-debian 0.1.37
ii  python3-debianbts  3.0.2
ii  python3-requests   2.23.0+dfsg-2
ii  sensible-utils 0.0.12+nmu1

python3-reportbug suggests no packages.

-- no debconf information


Bug#965087: postfix/master[2632]: fatal: set_eugid: setgroups(137): Bad address

2020-07-15 Thread Thorsten Glaser
Package: postfix
Version: 3.5.4-1
Severity: grave
Justification: renders package unusable

After a glibc upgrade today, I cannot start postfix any more.
I first noticed that after reportbug syslog was strangely quiet,
and sudo mailq does say:

postqueue: warning: Mail system is down -- accessing queue directly

Trying to start Postfix results in:

Jul 15 22:40:24 tglase postfix/master[2632]: fatal: set_eugid: setgroups(137): 
Bad address

This may be related to the setgroups fatal failure I’m reporting
against OpenSSH :/

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

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

Versions of packages postfix depends on:
ii  adduser3.118
ii  cpio   2.13+dfsg-3
ii  debconf [debconf-2.0]  1.5.74
ii  dpkg   1.20.5
ii  e2fsprogs  1.45.6-1
ii  libc6  2.31-1
ii  libdb5.3   5.3.28+dfsg1-0.6
ii  libicu67   67.1-3
ii  libsasl2-2 2.1.27+dfsg-2
ii  libssl1.1  1.1.1g-1
ii  lsb-base   11.1.0
ii  netbase6.1
ii  ssl-cert   1.0.39

Versions of packages postfix recommends:
ii  ca-bundle [ca-certificates]  20190604
ii  python3  3.8.2-3

Versions of packages postfix suggests:
ii  bsd-mailx [mail-reader]  8.1.2-0.20180807cvs-1
ii  libsasl2-modules 2.1.27+dfsg-2
pn  postfix-cdb  
pn  postfix-doc  
pn  postfix-ldap 
pn  postfix-lmdb 
pn  postfix-mysql
pn  postfix-pcre 
pn  postfix-pgsql
pn  postfix-sqlite   
pn  procmail 
pn  resolvconf   
pn  ufw  

-- debconf information:
  postfix/procmail: false
  postfix/root_address:
  postfix/chattr: false
  postfix/destinations: tglase.lan.tarent.de, tglase.lan.tarent.de, 
localhost.lan.tarent.de, localhost
  postfix/main_cf_conversion_warning: true
  postfix/not_configured:
  postfix/compat_conversion_warning: true
  postfix/dynamicmaps_conversion_warning:
  postfix/protocols: all
  postfix/retry_upgrade_warning:
* postfix/mailname: tglase.lan.tarent.de
  postfix/kernel_version_warning:
  postfix/rfc1035_violation: false
  postfix/mynetworks: 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
  postfix/tlsmgr_upgrade_warning:
  postfix/sqlite_warning:
  postfix/newaliases: false
* postfix/main_mailer_type: Internet with smarthost
  postfix/bad_recipient_delimiter:
* postfix/relayhost: mail.lixid.net
  postfix/mailbox_limit: 0
  postfix/recipient_delim: +
  postfix/mydomain_warning:
  postfix/relay_restrictions_warning:
  postfix/lmtp_retired_warning: true


Bug#965086: ssh: setgroups: Bad address [preauth]

2020-07-15 Thread Thorsten Glaser
Package: openssh-server
Version: 1:8.3p1-1
Severity: grave
Justification: renders package unusable

After an upgrade of libc6 today, I can no longer log into my
system using ssh:

tglase@tglase:~ $ ssh localhost
Connection reset by 127.0.0.1 port 22

Jul 15 22:33:17 tglase sshd[27084]: fatal: setgroups: Bad address [preauth]

More debugging:

tglase@tglase:~ $ sudo cleanenv / /usr/sbin/sshd -p2000 -ddde
debug2: load_server_config: filename /etc/ssh/sshd_config
debug2: load_server_config: done config len = 329
debug2: parse_server_config_depth: config /etc/ssh/sshd_config len 329
debug2: /etc/ssh/sshd_config line 13: new include /etc/ssh/sshd_config.d/*.conf
debug2: /etc/ssh/sshd_config line 13: no match for /etc/ssh/sshd_config.d/*.conf
debug3: /etc/ssh/sshd_config:20 setting HostKey /etc/ssh/ssh_host_rsa_key
debug3: /etc/ssh/sshd_config:63 setting ChallengeResponseAuthentication no
debug3: /etc/ssh/sshd_config:86 setting UsePAM yes
debug3: /etc/ssh/sshd_config:91 setting X11Forwarding yes
debug3: /etc/ssh/sshd_config:95 setting PrintMotd no
debug3: /etc/ssh/sshd_config:113 setting AcceptEnv LANG LC_*
debug3: /etc/ssh/sshd_config:116 setting Subsystem sftp 
/usr/lib/openssh/sftp-server
debug1: sshd version OpenSSH_8.3, OpenSSL 1.1.1g  21 Apr 2020
debug1: private host key #0: ssh-rsa 
SHA256:9ae2/1t8U30Savg3XisO1ZCDuaH8IXQm18FdLpW3g8M
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-p2000'
debug1: rexec_argv[2]='-ddde'
debug3: oom_adjust_setup
debug1: Set /proc/self/oom_score_adj from 0 to -1000
debug2: fd 3 setting O_NONBLOCK
debug1: Bind to port 2000 on 0.0.0.0.
Server listening on 0.0.0.0 port 2000.
debug2: fd 4 setting O_NONBLOCK
debug3: sock_set_v6only: set socket 4 IPV6_V6ONLY
debug1: Bind to port 2000 on ::.
Server listening on :: port 2000.
debug3: fd 5 is not O_NONBLOCK
debug1: Server will not fork when running in debugging mode.
debug3: send_rexec_state: entering fd = 8 config len 329
debug3: ssh_msg_send: type 0
debug3: send_rexec_state: done
debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8
debug3: recv_rexec_state: entering fd = 5
debug3: ssh_msg_recv entering
debug3: recv_rexec_state: done
debug2: parse_server_config_depth: config rexec len 329
debug2: parse_server_config_depth: config  len 0
debug3: rexec:20 setting HostKey /etc/ssh/ssh_host_rsa_key
debug3: rexec:63 setting ChallengeResponseAuthentication no
debug3: rexec:86 setting UsePAM yes
debug3: rexec:91 setting X11Forwarding yes
debug3: rexec:95 setting PrintMotd no
debug3: rexec:113 setting AcceptEnv LANG LC_*
debug3: rexec:116 setting Subsystem sftp/usr/lib/openssh/sftp-server
debug1: sshd version OpenSSH_8.3, OpenSSL 1.1.1g  21 Apr 2020
debug1: private host key #0: ssh-rsa 
SHA256:9ae2/1t8U30Savg3XisO1ZCDuaH8IXQm18FdLpW3g8M
debug1: inetd sockets after dupping: 3, 3
Connection from 127.0.0.1 port 57626 on 127.0.0.1 port 2000 rdomain ""
debug1: Local version string SSH-2.0-OpenSSH_8.3p1 Debian-1
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.3p1 
Debian-1
debug1: match: OpenSSH_8.3p1 Debian-1 pat OpenSSH* compat 0x0400
debug2: fd 3 setting O_NONBLOCK
debug3: ssh_sandbox_init: preparing seccomp filter sandbox
debug2: Network child is on pid 2057
debug3: preauth child monitor started
debug3: privsep user:group 111:65534 [preauth]
setgroups: Bad address [preauth]
debug1: do_cleanup [preauth]
debug3: PAM: sshpam_thread_cleanup entering [preauth]
debug1: monitor_read_log: child log fd closed
debug3: mm_request_receive entering
debug1: do_cleanup
debug3: PAM: sshpam_thread_cleanup entering
debug1: Killing privsep child 2057
debug1: audit_event: unhandled event 12

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

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

Versions of packages openssh-server depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.74
ii  dpkg   1.20.5
ii  libaudit1  1:2.8.5-3+b1
ii  libc6  2.31-1
ii  libcom-err21.45.6-1
ii  libcrypt1  1:4.4.16-1
ii  libelogind0 [libsystemd0]  243.7-1+debian1
ii  libgssapi-krb5-2   1.17-10
ii  libkrb5-3  1.17-10
ii  libpam-modules 1.3.1-5
ii  libpam-runtime 1.3.1-5
ii  libpam0g   1.3.1-5
ii  libselinux13.1-1
ii  libssl1.1  1.1.1g-1
ii  libwrap0   7.6.q-30
ii  lsb-base   11.1.0
ii  openssh-client 1:8.3p1-1
ii  openssh-sftp-server1:8.3p1-1
ii  procps 2:3.3.16-5
ii  runit-helper   

Bug#961811: baresip: diff for NMU version 0.6.1-1.1

2020-07-15 Thread Sebastian Ramacher
Control: tags 961811 + patch
Control: tags 961811 + pending

Dear maintainer,

I've prepared an NMU for baresip (versioned as 0.6.1-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Cheers
-- 
Sebastian Ramacher
diff -Nru baresip-0.6.1/debian/changelog baresip-0.6.1/debian/changelog
--- baresip-0.6.1/debian/changelog	2019-02-18 13:30:38.0 +0100
+++ baresip-0.6.1/debian/changelog	2020-07-15 22:37:51.0 +0200
@@ -1,3 +1,12 @@
+baresip (0.6.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/patches:
+- Unbreak patch 1002 with make 4.3 (Closes: #961811)
+- Apply upstream patch to fix build of selftest
+
+ -- Sebastian Ramacher   Wed, 15 Jul 2020 22:37:51 +0200
+
 baresip (0.6.1-1) unstable; urgency=medium
 
   [ upstream ]
diff -Nru baresip-0.6.1/debian/patches/1002_system_header_locations.patch baresip-0.6.1/debian/patches/1002_system_header_locations.patch
--- baresip-0.6.1/debian/patches/1002_system_header_locations.patch	2019-02-11 20:42:25.0 +0100
+++ baresip-0.6.1/debian/patches/1002_system_header_locations.patch	2020-07-15 22:33:05.0 +0200
@@ -22,7 +22,7 @@
  
 -USE_ALSA  := $(shell [ -f $(SYSROOT)/include/alsa/asoundlib.h ] || \
 -	[ -f $(SYSROOT_ALT)/include/alsa/asoundlib.h ] && echo "yes")
-+USE_ALSA  := $(shell echo '\#include ' | \
++USE_ALSA  := $(shell echo '#include ' | \
 +	$(CC) -E - >/dev/null 2>&1 && echo yes)
 +USE_AMR   := $(shell pkg-config --exists opencore-amrnb && echo "yes")
 +ifeq ($(USE_AMR),)
@@ -39,9 +39,9 @@
 -	[ -f $(SYSROOT)/include/$(MACHINE)/libavformat/avformat.h ] || \
 -	[ -f $(SYSROOT_ALT)/include/libavformat/avformat.h ] && echo "yes")
 +endif
-+USE_AVCODEC := $(shell echo '\#include ' | \
++USE_AVCODEC := $(shell echo '#include ' | \
 +	$(CC) -E - >/dev/null 2>&1 && echo yes)
-+USE_AVFORMAT := $(shell echo '\#include ' | \
++USE_AVFORMAT := $(shell echo '#include ' | \
 +	$(CC) -E - >/dev/null 2>&1 && echo yes)
  USE_AVAHI := $(shell pkg-config --exists avahi-client && echo "yes")
 -USE_BV32  := $(shell [ -f $(SYSROOT)/include/bv32/bv32.h ] || \
@@ -69,21 +69,21 @@
 -	[ -f $(SYSROOT)/include/gsm/gsm.h ] || \
 -	[ -f $(SYSROOT)/local/include/gsm.h ] || \
 -	[ -f $(SYSROOT)/local/include/gsm/gsm.h ] && echo "yes")
-+USE_BV32  := $(shell echo '\#include ' | \
 +	$(CC) -E - >/dev/null 2>&1 && echo yes)
-+USE_CAIRO  := $(shell echo '\#include ' |\
++USE_CAIRO  := $(shell echo '#include ' |\
 +	$(CC) -E - >/dev/null 2>&1 && echo yes)
-+USE_DTLS := $(shell echo '\#include ' | \
++USE_DTLS := $(shell echo '#include ' | \
 +	$(CC) -E - >/dev/null 2>&1 && echo yes)
-+USE_DTLS_SRTP := $(shell echo '\#include ' | \
++USE_DTLS_SRTP := $(shell echo '#include ' | \
 +	$(CC) -E - >/dev/null 2>&1 && echo yes)
-+USE_G722 := $(shell echo '\#include ' | \
++USE_G722 := $(shell echo '#include ' | \
 +	$(CC) -E - >/dev/null 2>&1 && echo yes)
-+USE_G722_1 := $(shell echo '\#include ' | \
++USE_G722_1 := $(shell echo '#include ' | \
 +	$(CC) -E - >/dev/null 2>&1 && echo yes)
-+USE_G726 := $(shell echo '\#include ' | \
++USE_G726 := $(shell echo '#include ' | \
 +	$(CC) -E - >/dev/null 2>&1 && echo yes)
-+USE_GSM := $(shell echo '\#include ' | \
++USE_GSM := $(shell echo '#include ' | \
 +	$(CC) -E - >/dev/null 2>&1 && echo yes)
  USE_GST := $(shell pkg-config --exists gstreamer-0.10 && echo "yes")
  USE_GST1 := $(shell pkg-config --exists gstreamer-1.0 && echo "yes")
@@ -117,27 +117,27 @@
 -USE_PORTAUDIO := $(shell [ -f $(SYSROOT)/local/include/portaudio.h ] || \
 -		[ -f $(SYSROOT)/include/portaudio.h ] || \
 -		[ -f $(SYSROOT_ALT)/include/portaudio.h ] && echo "yes")
-+USE_H265  := $(shell echo '\#include ' | \
++USE_H265  := $(shell echo '#include ' | \
 +	$(CC) -E - >/dev/null 2>&1 && echo yes)
 +endif
-+USE_ILBC := $(shell echo '\#include ' | \
++USE_ILBC := $(shell echo '#include ' | \
 +	$(CC) -E - >/dev/null 2>&1 && echo yes)
-+USE_ISAC := $(shell echo '\#include ' | \
++USE_ISAC := $(shell echo '#include ' | \
 +	$(CC) -E - >/dev/null 2>&1 && echo yes)
-+USE_JACK := $(shell echo '\#include ' | \
++USE_JACK := $(shell echo '#include ' | \
 +	$(CC) -E - >/dev/null 2>&1 && echo yes)
-+USE_MPG123  := $(shell echo '\#include ' | \
++USE_MPG123  := $(shell echo '#include ' | \
 +	$(CC) -E - >/dev/null 2>&1 && echo yes)
-+USE_OPUS := $(shell echo '\#include ' | \
++USE_OPUS := $(shell echo '#include ' | \
 +	$(CC) -E - >/dev/null 2>&1 && echo yes)
-+USE_OSS := $(shell echo '\#include ' | \
++USE_OSS := $(shell echo '#include ' | \
 +	$(CC) -E - >/dev/null 2>&1 || \
-+	echo '\#include ' | $(CC) -E - >/dev/null 2>&1 || \
-+	echo '\#include ' | $(CC) -E - >/dev/null 2>&1 && \
++	echo '#include ' | $(CC) -E - >/dev/null 2>&1 || \
++	echo '#include ' | $(CC) -E - >/dev/null 2>&1 && \
 +	echo yes)
-+USE_PLC := $(shell echo '\#include ' | \
++USE_PLC := $(shell echo '#include ' | \
 +	$(CC) -E - >/dev/null 2>&1 && echo yes)
-+USE_PORTAUDIO := $(shell echo '\#include ' | \
++USE_PORTAUDIO := 

Bug#964256: libbrotli-dev not multiarch installable

2020-07-15 Thread Witold Baryluk
Package: libbrotli-dev
Version: 1.0.7-6.1
Followup-For: Bug #964256
X-Debbugs-Cc: witold.bary...@gmail.com

I discovered this issue today to when trying to compile wine and
installing libfreetype-dev for i386 and amd64.

I would really appreciate the -dev files to have Multi-Arch: same, and
the fixed package uploaded soon.

Thanks you!

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

Kernel: Linux 5.6.0-1-amd64 (SMP w/32 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)
LSM: AppArmor: enabled

Versions of packages libbrotli-dev depends on:
ii  libbrotli1  1.0.7-6.1

libbrotli-dev recommends no packages.

libbrotli-dev suggests no packages.

-- no debconf information



Bug#965084: ITP: golang-github-malfunkt-iprange -- IPv4 address parser for the nmap format

2020-07-15 Thread Francisco Vilmar Cardoso Ruviaro
Package: wnpp
Severity: wishlist
Owner: Francisco Vilmar Cardoso Ruviaro 
X-Debbugs-Cc: debian-de...@lists.debian.org, francisco.ruvi...@riseup.net

* Package name: golang-github-malfunkt-iprange
  Version : 0.9.0
  Upstream Author : José Nieto 
Arturo Vergara 
* URL : https://github.com/malfunkt/iprange
* License : Expat
  Programming Lang: Go
  Description : IPv4 address parser for the nmap format

IPrange is a library can use to parse IPv4 addresses from a string
in the nmap format.
.
IPrange takes a string, and returns a list of Min-Max pairs, which
can then be expanded and normalized automatically by the package.
.
Supported Formats:
 - 10.0.0.1
 - 10.0.0.0/24
 - 10.0.0.*
 - 10.0.0.1-10
 - 10.0.0.1, 10.0.0.5-10, 192.168.1.*, 192.168.10.0/24


Bug#963247: ignition-fuel-tools FTBFS with Protobuf 3.12.3

2020-07-15 Thread Sebastian Ramacher
On 2020-07-15 15:45:42 +0200, jspri...@debian.org wrote:
> Hi,
> 
> seems like this was not enough:
> 
> /usr/bin/ld: 
> /usr/lib/gcc/aarch64-linux-gnu/9/../../../aarch64-linux-gnu/libignition-fuel_tools4.so:
>  undefined reference to `ignition::msgs::FuelMetadata::FuelMetadata()'
> 
> https://ci.debian.net/data/autopkgtest/testing/arm64/i/ignition-fuel-tools/6276839/log.gz
> 
> Looks like the new protobuf drops a symbol.
> I'm not sure how to proceed:
> - patch protobuf to get the symbol back?
> - bump Sonames of all ign* packages?
> - Any other idea?

boost-regex and icu have a similar issue. There the symbols of
libboost-regex change with the SONAME of icu. As a solution,
libboost-regex has a Provides encoding icu's SONAME and a symbol files
that produces dependencies on that Provide. The same could be applied
here as well.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature


Bug#965080: Resignation + Call for votes for new Chair

2020-07-15 Thread Sean Whitton
Hello,

On Wed 15 Jul 2020 at 09:05PM +02, Margarita Manterola wrote:

> I am calling for the election of a new Chair of Debian Technical
> Committee by announcing my resignation as chair effective one week from
> now. In accordance with Section 6.1.7 of the Debian Constitution, the
> vote runs until all members have voted, or until my resignation takes
> effect.
>
> The ballot is the following:
>
> ===BEGIN===
>
> The chair of the Debian Technical Committee will be:
>
>  A : Philip Hands
>  B : Margarita Manterola
>  C : David Bremner
>  D : Niko Tyni
>  E : Gunnar Wolf
>  F : Simon McVittie
>  G : Sean Whitton
>  H : Elana Hashman
>
> ===END===

I vote: B > C > A = D = E = F > G = H

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#961016: (no subject)

2020-07-15 Thread Emmanuel Kasper
Hi Laurent
You can install the crun package to fix the service error ( I suppose
you found that out already)

You can find an intro about podman and varlink here:
https://podman.io/blogs/2019/01/16/podman-varlink.html

I think there is a problem in the Depends of podman:

https://salsa.debian.org/debian/libpod/-/blob/master/debian/control#L95
has a depends on crun OR runc but you need actually both, runc for the
command line tool, and crun for the varlink service.

$ podman list images
Error: could not get runtime: default OCI runtime "runc" not found:
invalid argument

is what you get when installing podman without runc.


Manu



Bug#965083: RM: golang-github-hashicorp-uuid -- RoQA; deprecated by upstream

2020-07-15 Thread Shengjing Zhu
Package: ftp.debian.org
Severity: normal

golang-github-hashicorp-uuid has been deprecated by upstream[1].
People should use golang-github-hashicorp-go-uuid, which has been in Debian
for a long time.

[1] https://github.com/hashicorp/uuid



Bug#965082: RM: golang-github-dgrijalva-jwt-go-v3 -- RoQA; duplicated with golang-github-dgrijalva-jwt-go

2020-07-15 Thread Shengjing Zhu
Package: ftp.debian.org
Severity: normal

After src:golang-github-dgrijalva-jwt-go has been updated to v3 from v2,
this src:golang-github-dgrijalva-jwt-go-v3 is no longer needed.

All build-rdeps have been updated.



Bug#965081: gccgo-10: fail to build Go program after upgrading from testing to sid

2020-07-15 Thread Shengjing Zhu
Source: gcc-10
Version: 10.1.0-6
Severity: important

Steps to reproduce:

git clone https://github.com/elves/elvish
cd elvish
go-10 build .

# github.com/elves/elvish
/usr/bin/ld: 
/root/.cache/go-build/f0/f0e9506d8a488f640fafc0e1b9367be18b83f9ed9e02b406d8a5ef7ed72dfdbe-d(_go_.o):
 warning: relocation against 
`github.x2ecom..z2felves..z2felvish..z2fpkg..z2fcli..z2faddons..z2fhistwalk.github.x2ecom..z2felves..z2felvish..z2fpkg..z2fcli..z2faddons..z2fhistwalk..thunk1..f'
 in read-only section `.text'
/usr/bin/ld: 
/root/.cache/go-build/f0/f0e9506d8a488f640fafc0e1b9367be18b83f9ed9e02b406d8a5ef7ed72dfdbe-d(_go_.o):
 in function 
`github.x2ecom..z2felves..z2felvish..z2fpkg..z2fcli..z2faddons..z2fhistwalk.Next':
/root/elvish/pkg/edit/ /root/elvish/pkg/cli/addons/histwalk/histwalk.go:93: 
undefined reference to 
`github.x2ecom..z2felves..z2felvish..z2fpkg..z2fcli..z2faddons..z2fhistwalk.github.x2ecom..z2felves..z2felvish..z2fpkg..z2fcli..z2faddons..z2fhistwalk..thunk3..f'
/usr/bin/ld: /root/elvish/pkg/edit/ 
/root/elvish/pkg/cli/addons/histwalk/histwalk.go:93: undefined reference to 
`github.x2ecom..z2felves..z2felvish..z2fpkg..z2fcli..z2faddons..z2fhistwalk.github.x2ecom..z2felves..z2felvish..z2fpkg..z2fcli..z2faddons..z2fhistwalk..thunk2..f'
/usr/bin/ld: /root/elvish/pkg/edit/ 
/root/elvish/pkg/cli/addons/histwalk/histwalk.go:93: undefined reference to 
`github.x2ecom..z2felves..z2felvish..z2fpkg..z2fcli..z2faddons..z2fhistwalk.github.x2ecom..z2felves..z2felvish..z2fpkg..z2fcli..z2faddons..z2fhistwalk..thunk3..f'
/usr/bin/ld: /root/elvish/pkg/edit/ 
/root/elvish/pkg/cli/addons/histwalk/histwalk.go:93: undefined reference to 
`github.x2ecom..z2felves..z2felvish..z2fpkg..z2fcli..z2faddons..z2fhistwalk.github.x2ecom..z2felves..z2felvish..z2fpkg..z2fcli..z2faddons..z2fhistwalk..thunk2..f'
/usr/bin/ld: 
/root/.cache/go-build/f0/f0e9506d8a488f640fafc0e1b9367be18b83f9ed9e02b406d8a5ef7ed72dfdbe-d(_go_.o):
 in function 
`github.x2ecom..z2felves..z2felvish..z2fpkg..z2fcli..z2faddons..z2fhistwalk.Prev':
/root/elvish/pkg/edit/ /root/elvish/pkg/cli/addons/histwalk/histwalk.go:86: 
undefined reference to 
`github.x2ecom..z2felves..z2felvish..z2fpkg..z2fcli..z2faddons..z2fhistwalk.github.x2ecom..z2felves..z2felvish..z2fpkg..z2fcli..z2faddons..z2fhistwalk..thunk1..f'
/usr/bin/ld: /root/elvish/pkg/edit/ 
/root/elvish/pkg/cli/addons/histwalk/histwalk.go:86: undefined reference to 
`github.x2ecom..z2felves..z2felvish..z2fpkg..z2fcli..z2faddons..z2fhistwalk.github.x2ecom..z2felves..z2felvish..z2fpkg..z2fcli..z2faddons..z2fhistwalk..thunk0..f'
/usr/bin/ld: warning: creating DT_TEXTREL in a PIE
collect2: error: ld returned 1 exit status

However it's fine in testing.

The situation is:

In bullseye/testing, both gcc-10/10.1.0-4 and gcc-snapshot/1:20200616-1 can 
build.
In sid, gcc-10/10.1.0-6 and gcc-snapshot/1:20200616-1 can't build, with same 
error above.

I'm really not sure which package causes this regression.
binutils is 2.34.90.20200706-1 in testing and sid.

Shengjing Zhu



Bug#965080: Resignation + Call for votes for new Chair

2020-07-15 Thread Margarita Manterola
Package: tech-ctte

[Resending as a bug rather than a mailing-list email. Sorry!]

Dear TC members,

I am calling for the election of a new Chair of Debian Technical
Committee by announcing my resignation as chair effective one week from
now. In accordance with Section 6.1.7 of the Debian Constitution, the
vote runs until all members have voted, or until my resignation takes
effect.

The ballot is the following:

===BEGIN===

The chair of the Debian Technical Committee will be:

 A : Philip Hands
 B : Margarita Manterola
 C : David Bremner
 D : Niko Tyni
 E : Gunnar Wolf
 F : Simon McVittie
 G : Sean Whitton
 H : Elana Hashman 

===END===

-- 
Regards,
Marga


signature.asc
Description: PGP signature


Bug#965079: ITP: graphbin -- refined binning of metagenomic contigs using assembly graphs

2020-07-15 Thread Shayan Doust
Package: wnpp
Severity: wishlist

Subject: ITP: graphbin -- refined binning of metagenomic contigs using assembly 
graphs
Package: wnpp
Owner: Shayan Doust 
Severity: wishlist

* Package name: graphbin
  Version : 1.1
  Upstream Author : Graphbin Project 
* URL : https://github.com/Vini2/GraphBin
* License : GPL-2.0+
  Programming Lang: Python
  Description : refined binning of metagenomic contigs using assembly graphs
 GraphBin is a NGS data-based metagenomic contig bin refinment tool that
 makes use of the contig connectivity information from the assembly graph
 to bin contigs. It utilizes the binning result of an existing binning
 tool and a label propagation algorithm to correct mis-binned contigs and
 predict the labels of contigs which are discarded due to short length.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/graphbin



Bug#964566: ncal: please handle /usr/bin/cal + manpage via alternatives

2020-07-15 Thread Thorsten Glaser
Michael Meskes dixit:

>> b& nor does ncal use the locale for this, so, no, it does not use
>> appropriate calendar week calculation rules.
>
>This is simply not true since it definitely does.

I looked before writing that eMail, so it’s true; ncal uses the locale
to look up a country code, which then is used to determine the date of
the julian→gregorian calendar switch. That’s it exactly, nothing more.

>Fair enough, but you could at least report these cases.

Sure… if I see them.

bye,
//mirabilos
-- 
22:20⎜ The crazy that persists in his craziness becomes a master
22:21⎜ And the distance between the craziness and geniality is
only measured by the success 18:35⎜ "Psychotics are consistently
inconsistent. The essence of sanity is to be inconsistently inconsistent



Bug#965074: cdc_ncm: ethernet multicast traffic is filtered out

2020-07-15 Thread Bjørn Mork
FWIW, I made an attempt resubmitting these patches since it looked like
I was part of the problem back in 2018 ;-)

I'd CCed you, and would appreciate it if you could test the series.  I
don't have any cdc_ncm devices with multicast filter support AFAIK.


Bjørn



Bug#965043: Acknowledgement (ITP: golang-github-lightstep-lightstep-tracer-go -- Distributed Tracing Library for Golang)

2020-07-15 Thread Rahulkrishnan R A
On Wed, Jul 15, 2020 at 6:43 PM Rahulkrishnan R A 
wrote:

> Package   : wnpp
> Severity  : wishlist
> Owner : 'Rahulkrishnan R A' 
>
> * Package Name: golang-github-lightstep-lightstep-tracer-go
>   Version : 0.0~git20190219.c0184d4-1
>   Upstream Author : Lightstep
> * URL :https://github.com/lightstep/lightstep-tracer-go
> * License : Expat
>   Programming Lang: Go
>   Description : Distributed Tracing Library for Golang
>
>
> This Package implements the LightStep OpenTracing client for Go.
>
>
>
>

-- 
Regards,

Rahulkrishnan R A


Bug#965078: ITP: golang-github-adrianmo-go-nmea -- Go library for the NMEA 0183 protocol

2020-07-15 Thread Francisco Vilmar Cardoso Ruviaro
Package: wnpp
Severity: wishlist
Owner: Francisco Vilmar Cardoso Ruviaro 
X-Debbugs-Cc: debian-de...@lists.debian.org, francisco.ruvi...@riseup.net

* Package name: golang-github-adrianmo-go-nmea
  Version : 1.2.0
  Upstream Author : Adrián Moreno 
* URL : https://github.com/adrianmo/go-nmea
* License : Expat
  Programming Lang: Go
  Description : Go library for the NMEA 0183 protocol

Go library for the National Marine Electronics Association 0183 protocol.
.
NMEA 0183 is a combined electrical and data specification for communication
between marine electronics such as echo sounder, sonars, anemometer,
gyrocompass, autopilot, GPS receivers and many other types of instruments.
.
Features include:
 * Parse individual NMEA 0183 sentences.
 * Register custom parser for unsupported sentence types.
.
Supported sentences:
 * Sentence type | Description
- RMC| Recommended Minimum Specific GPS/Transit data.
- PMTK   | Messages for setting and reading commands for MediaTek
   gps modules.
- GGA| GPS Positioning System Fix Data.
- GSA| GPS DOP and active satellites.
- GSV| GPS Satellites in view.
- GLL| Geographic Position, Latitude / Longitude and time.
- VTG| Track Made Good and Ground Speed.
- ZDA| Date & time data.
- HDT| Actual vessel heading in degrees True.
- GNS| Combined GPS fix for GPS, Glonass, Galileo, and BeiDou.
- PGRME  | Estimated Position Error (Garmin proprietary sentence).
- THS| Actual vessel heading in degrees True and status.
- VDM/VDO| Encapsulated binary payload.
- WPL| Waypoint location.
- RTE| Route.
- VHW| Water Speed and Heading.
- DPT| Depth of Water.
- DBS| Depth Below Surface.
- DBT| Depth below transducer.


Bug#963750: RM: chef -- ROM; trademark issues

2020-07-15 Thread Stefano Rivera
Hi Sean (2020.07.11_14:53:31_-0700)
> > However, Chef Inc. decided that Chef should no longer be free
> > software/open source. I no longer intend to use or maintain Chef, and
> > would like it to be removed from Debian.
> 
> I'm a bit confused here.  On the one hand you say that there's a
> copyright issue, but reading the Ubuntu bug it seems that Ubuntu's
> src:chef in fact contains cinc.  I take it Debian's doesn't?  In which
> case the copyright issue would seem not to be a relevant reason for
> removal?

Chef is in sync between Debian and Ubuntu. The current source package
contains cinc [0], but the packages are still contain the name chef.

That is the core of the trademark issue Chef Inc has with Debian [1].

[0]: 
https://tracker.debian.org/media/packages/c/chef/copyright-15.8.25.3.gcf41df6a2-6
[1]: https://bugs.debian.org/959981#5

> On the other hand you say you think that we should remove the Chef
> package because there are not going to be future upstream releases which
> are free software.  Could you provide me a reference, please?  All I can
> find online is that there is a new requirement to perform some renaming
> in the contents of the package, not that new releases will be
> DFSG-nonfree.

I think your analysis is correct. The source is Apache-2.0 licensed, but
with a renaming requirement. There is a collaborative effort to maintain
a renamed source, cinc, which we've been shipping, but we haven't
followed through on a complete renaming.

This is an RoM request, the maintainers have lost interest in working
with an upstream that imposes rules like this.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272



Bug#965043: Acknowledgement (ITP: golang-github-lightstep-lightstep-tracer-go -- Distributed Tracing Library for Golang)

2020-07-15 Thread Rahulkrishnan R A
Package   : wnpp
Severity  : wishlist
Owner : 'Rahulkrishnan R A' 

* Package Name: golang-github-lightstep-lightstep-tracer-go
  Version : 0.0~git20190219.c0184d4-1
  Upstream Author : Lightstep
* URL :https://github.com/lightstep/lightstep-tracer-go
* License : Expat
  Programming Lang: Go
  Description : Distributed Tracing Library for Golang


This Package implements the LightStep OpenTracing client for Go.


Bug#965076: Acknowledgement (ITP: golang-github-lightstep-lightstep-tracer-go -- Distributed Tracing Library for Golang)

2020-07-15 Thread Rahulkrishnan R A
Package   : wnpp

Severity  : wishlist

Owner : 'Rahulkrishnan R A' 

* Package Name: golang-github-@-lightstep-tracer-go
  Version : 0.0~git20190219.c0184d4-1
  Upstream Author : Lightstep
* URL : https://github.com/lightstep/lightstep-tracer-go
* License : Expat
  Programming Lang: Go
  Description : Distributed Tracing Library for Golang


This Package implements the LightStep OpenTracing client for Go.


Bug#965044: RFP: gnome-podcasts — A podcast client for GNOME

2020-07-15 Thread Andrei POPESCU
Control: reassign -1 wnpp

On Ma, 14 iul 20, 23:22:20, Graweeld - (grwd) wrote:
> Package: gnome-podcasts
> 
> RFP
> Severity: wishlist
> 
> A simple, and responsive podcast feed player for the GNOME desktop.
> 
> License: GPL
> 
> Source: https://gitlab.gnome.org/World/podcasts#contributing
> 
> P.S. A package for the aarch64 would be also very neat. Much thanks!
> 
> Marek Ľach, Bc.

-- 
Looking after bugs filled against unknown packages


signature.asc
Description: PGP signature


Bug#964577: sbcl: Memory fault, sb-kernel:output-ugly-object

2020-07-15 Thread florine
The error doesn't happen with Fedora 32 sbcl package 2.0.1.

The error happens independently of the cl-monad-package:

(with-input-from-string (in "1")
  (cons (read in) in))

I get a similar error with

(sb-vm:hexdump 0)


signature.asc
Description: PGP signature


Bug#965072: Attempting to reproduce

2020-07-15 Thread Anuradha Weeraman
Thanks for reporting the issue, Thorsten.

I'm attempting to reproduce the issue on stretch, in a container:

# cat repro.sh
#!/bin/ksh
cat TODO | while read line; do ls; done
# cat TODO
1
2
3
4
# ksh --version
  version sh (AT Research) 93u+ 2012-08-01
# dpkg -l | grep ksh
  ii  ksh 93u+20120801-3.1  amd64Real,
  AT version of the Korn shell
# ./repro.sh
  TODO  repro.sh
  TODO  repro.sh
  TODO  repro.sh
  TODO  repro.sh

Same with the latest on sid.

Did you have to do anything apart from the above to reproduce on your
end?

Anuradha



Bug#965077: MySQL database with "SQLAUthTypes Backend" doesn't work anymore in buster

2020-07-15 Thread Andreas Trottmann

Package: proftpd-mod-mysql
Version: 1.3.6-4+deb10u5
Tags: patch

I am using an admin tool that saves account information in a MySQL / 
MariaDB-Datbase and uses the "password()" function to obfuscate stored 
passwords.


This has been working "out of the box" in the Stretch version of ProFTPD 
using the configuration option "SQLAUthTypes Backend". It doesn't work 
anymore in the Buster version; users can't authenticate anymore.


Apparently, the function contrib/mod_sql_mysql.c tries to use an 
undocumented function of libmysqlclient to create the obfuscated 
password; it switches between my_make_scrambled_password,
my_make_scrambled_password_323, make_scrambled_password and 
make_scrammbed_password_323. It appears that in the Buster version of 
libmysqlcilent, none of these are available and thus it can't ever 
create an obfuscated password from what the user logging in has provided.




Googling led me to a similar problem in pure-ftpd that had a patch here:

https://serverfault.com/questions/861176/pure-ftpd-mysql-wont-start-after-updating-mariadb-to-10-2

This patch basically recreates the function of the 
*make_scrambled_password* functions using the SHA-1 implementation in libmd.


I have modified this to apply to ProFTPD and attached the patch to this 
e-mail. In my tests, this has worked.


Kind regards

--
Andreas Trottmann

--- proftpd-dfsg-1.3.6.orig/contrib/mod_sql_mysql.c
+++ proftpd-dfsg-1.3.6/contrib/mod_sql_mysql.c
@@ -23,7 +23,7 @@
  * the source distribution.
  *
  * -DO NOT EDIT-
- * $Libraries: -lm -lmysqlclient -lz$
+ * $Libraries: -lm -lmd -lmysqlclient -lz$
  */
 
 /* INTRO:
@@ -133,6 +133,8 @@
 
 #include 
 
+#include 
+
 /* The my_make_scrambled_password{,_323} functions are not part of the public
  * MySQL API and are not declared in any of the MySQL header files. But the
  * use of these functions are required for implementing the "Backend"
@@ -1624,6 +1626,27 @@ static int get_mysql_passwd_fmt(const ch
   return MYSQL_PASSWD_FMT_UNKNOWN;
 }
 
+char *hexify(char * const result, const unsigned char *digest,
+	const size_t size_result, size_t size_digest)
+{
+   static const char * const hexchars = "0123456789ABCDEF";
+   char *result_pnt = result;
+
+   if (size_digest <= (size_t) 0 ||
+   size_result <= (size_digest * (size_t) 2U)) {
+   return NULL;
+   }
+   do {
+   *result_pnt++ = hexchars[(*digest >> 4) & 0xf];
+   *result_pnt++ = hexchars[*digest & 0xf];
+   digest++;
+   size_digest--;
+   } while (size_digest > (size_t) 0U);
+   *result_pnt = 0;
+
+   return result;
+}
+
 static int match_mysql_passwds(const char *hashed, size_t hashed_len,
 const char *scrambled, size_t scrambled_len, const char *scramble_func) {
   int hashed_fmt = 0, scrambled_fmt = 0, matched = FALSE;
@@ -1831,6 +1854,27 @@ MODRET cmd_checkauth(cmd_rec *cmd) {
 #endif /* HAVE_MYSQL_MAKE_SCRAMBLED_PASSWORD_323 */
 
   if (success == FALSE) {
+SHA1_CTX  ctx;
+unsigned char h0[20], h1[20];
+SHA1Init();
+SHA1Update(, plaintxt, strlen(plaintxt));
+SHA1Final(h0, );
+SHA1Init();
+SHA1Update(, h0, sizeof h0);
+memset(h0, '\0', sizeof h0);
+SHA1Final(h1, );
+
+hexify(scrambled + 1U, h1, (sizeof scrambled) - 1U, sizeof h1);
+*scrambled = '*';
+sql_log(DEBUG_FUNC, "comparing scrambled password %s to %s", scrambled, hashed);
+
+scrambled_len = strlen(scrambled);
+   
+success = match_mysql_passwds(hashed, hashed_len, scrambled, scrambled_len,
+  "selfmade_sha1");
+  }
+
+  if (success == FALSE) {
 sql_log(DEBUG_FUNC, "%s", "password mismatch");
   }
 


Bug#964132: qgis: Please switch from sip4 to sip5

2020-07-15 Thread Dmitry Shachnev
Hi again Sebastiaan!

On Thu, Jul 02, 2020 at 08:00:38PM +0300, Dmitry Shachnev wrote:
> I am currently looking at krita (#964126) which uses similar FindSIP.py
> and FindPyQt5.py files, I will report back here when I get any success
> with it.

I have just forked QGIS on GitHub and created a sip5 branch in my fork,
partially based on what I have done for krita:

https://github.com/mitya57/QGIS/commits/sip5

This is completely untested so far, I will try to test/finalize it in the
next days, and then create a pull request upstream.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Bug#965076: ITP: golang-github-lightstep-tracer-go -- Distributed Tracing Library for Golang

2020-07-15 Thread Rahulkrishnan R A
Package: wnpp
Severity: wishlist
Owner: 'Rahulkrishnan R A' 

* Package Name   : golang-github-lightstep-lightstep-tracer-go
  Version: 0.0~git20190219.c0184d4-1
  Upstream Author : Lightstep
* URL :
https://github.com/lightstep/lightstep-tracer-go
* License: Expat
Programming Lang : Go
  Description  : Distributed Tracing Library for Golang


This Package implements the LightStep OpenTracing client for Go.


Bug#965052: RFP: bitlbee-libpurple -- Missing /var/lib/bitlbee

2020-07-15 Thread Andrei POPESCU
Control: reassign -1 bitlbee-libpurple 3.6-1.1+b2
Control: retitle -1 bitlbee-libpurple: missing directory /var/lib/bitlbee
Control: severity -1 normal

On Mi, 15 iul 20, 15:57:33, David Maslen wrote:
> Package: wnpp
> Severity: wishlist
> 
> * Package name: bitlbee-libpurple
>   Version : 3.6-1.1+b2
>   Upstream Author : 
> * URL or Web page : 
> * License : 
>   Description : Missing /var/lib/bitlbee
> 
> I've not yet configured bitl-bee, just installed it.
> I ran systemctl to check the status and noticed this error.
> I doubt this is a serious issue, but wondered whether the install should
> have created the config directory.
> 
> ~ [ sc-status bitlbee.service 
>   ] 
> 3:50 PM
> ● bitlbee.service - BitlBee IRC/IM gateway
>  Loaded: loaded (/lib/systemd/system/bitlbee.service; enabled; vendor 
> preset: enabled)
>  Active: active (running) since Tue 2020-07-07 08:45:51 AEST; 1 weeks 1 
> days ago
>Main PID: 1174384 (bitlbee)
>   Tasks: 1 (limit: 19021)
>  Memory: 2.2M
>  CGroup: /system.slice/bitlbee.service
>  └─1174384 /usr/sbin/bitlbee -F -n
> 
> Jul 07 08:45:51 trinity.maslen.id.au systemd[1]: Started BitlBee IRC/IM 
> gateway.
> Jul 07 08:45:51 trinity.maslen.id.au bitlbee[1174384]: Warning: The 
> configuration directory `/var/lib/bitlbee/' does not exist. Configuration 
> won't be saved.
> Jul 07 08:45:51 trinity.maslen.id.au bitlbee[1174384]: The configuration 
> directory `/var/lib/bitlbee/' does not exist. Configuration won't be saved.
> 

-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature


Bug#965074: cdc_ncm: ethernet multicast traffic is filtered out

2020-07-15 Thread Wxcafé
BTW, I reported this on one of my servers running 5.5.0 (installed
manually) but it affects every version up to 5.8.0-rc5, which is why I
reported to the meta-package linux-image-amd64.


-- 
Wxcafé 

On Wed, 2020-07-15 at 16:41 +, wxcafe wrote:
> Package: linux-image-amd64
> Version: 4.19+105+deb10u4
> Severity: important
> Tags: ipv6
> 
> Hey,
> 
> linux's cdc_ncm driver has a bug with multicast ethernet traffic,
> which breaks
> mDNS and ipv6, among other things. Miguel Rodríguez Pérez (
> mig...@det.uvigo.gal)
> wrote patches fixing that two years ago, but they never got merged
> even though
> as far as I can tell he fixed all the problems mentionned.
> (
> https://patchwork.kernel.org/project/linux-usb/list/?submitter=181339=%2A=both
> )
> 
> I tried rebasing them on current mainline (5.7.8/5.8.0-rc5) and
> submit them but
> have been met with a lot of trouble with my formatting, and also
> don't want to
> use my real name (see 
> https://marc.info/?l=linux-netdev=159467301013480=2 
> https://marc.info/?t=15947762502=1=2 
> https://marc.info/?t=15947764403=1=2 
> https://marc.info/?t=15947768081=1=2 
> https://marc.info/?t=15947764422=1=2 
> https://marc.info/?t=15947766241=1=2 etc)
> 
> As far as I know nothing should pose any problem with merging these,
> all the
> objections mentionned in the thread are resolved (as far as I can
> tell, I'm not
> a kernel dev), they build correctly on mainline, and work well.
> 
> Cheers.
> 
> -- System Information:
> Debian Release: 10.4
>   APT prefers stable
>   APT policy: (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.5.0-0.bpo.2-amd64 (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
> TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8
> (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages linux-image-amd64 depends on:
> ii  linux-image-4.19.0-9-amd64  4.19.118-2
> 
> linux-image-amd64 recommends no packages.
> 
> linux-image-amd64 suggests no packages.
> 
> -- no debconf information



Bug#964566: ncal: please handle /usr/bin/cal + manpage via alternatives

2020-07-15 Thread Michael Meskes
> >I haven't seen any error in ncal so far, but if you see some it
> might
> 
> … nor does ncal use the locale for this, so, no, it does not use
> appropriate calendar week calculation rules.

This is simply not true since it definitely does.

> >be more helpful to report and/or fix those as ncal should not show
> 
> I’m honestly not interested in working on ncal, given I don’t even
> use
> it and have a perfectly working implementation (I *did*, initially,
> plan on patching ncal to support various standards for calendar week
> calculation, until I found that OpenBSD’s cal already has them
> right).

Fair enough, but you could at least report these cases.

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes dot org
VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL



Bug#965074: cdc_ncm: ethernet multicast traffic is filtered out

2020-07-15 Thread wxcafe
Package: linux-image-amd64
Version: 4.19+105+deb10u4
Severity: important
Tags: ipv6

Hey,

linux's cdc_ncm driver has a bug with multicast ethernet traffic, which breaks
mDNS and ipv6, among other things. Miguel Rodríguez Pérez (mig...@det.uvigo.gal)
wrote patches fixing that two years ago, but they never got merged even though
as far as I can tell he fixed all the problems mentionned.
(https://patchwork.kernel.org/project/linux-usb/list/?submitter=181339=%2A=both)

I tried rebasing them on current mainline (5.7.8/5.8.0-rc5) and submit them but
have been met with a lot of trouble with my formatting, and also don't want to
use my real name (see https://marc.info/?l=linux-netdev=159467301013480=2 
https://marc.info/?t=15947762502=1=2 
https://marc.info/?t=15947764403=1=2 
https://marc.info/?t=15947768081=1=2 
https://marc.info/?t=15947764422=1=2 
https://marc.info/?t=15947766241=1=2 etc)

As far as I know nothing should pose any problem with merging these, all the
objections mentionned in the thread are resolved (as far as I can tell, I'm not
a kernel dev), they build correctly on mainline, and work well.

Cheers.

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

Kernel: Linux 5.5.0-0.bpo.2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages linux-image-amd64 depends on:
ii  linux-image-4.19.0-9-amd64  4.19.118-2

linux-image-amd64 recommends no packages.

linux-image-amd64 suggests no packages.

-- no debconf information


Bug#965029: console-setup: fonts missing numerous unicode->font mappings for box-drawing characters

2020-07-15 Thread Anton Zinoviev
On Tue, Jul 14, 2020 at 12:54:59PM -0400, Nick Black wrote:
> 
> I'm happy to make these patches and send them upstream, but Anton Zinoviev
> requested that I file a bug here.

In this way the requiest is documented.  More difficult to forget about it...
 
> I consider the following wide strings to be acceptable fallback sets (taken
> from Notcurses src/lib/linux.c):

Thanks.
 
> Let me know how I can make myself useful.

If you can, please test the fonts I have attached.

Anton Zinoviev


Arabic-VGA16.psf
Description: Binary data


Arabic-Fixed16.psf
Description: Binary data


Lat15-Terminus16.psf
Description: Binary data


Bug#952645: Please clarify the status of ublock-origin in NEW

2020-07-15 Thread Sean Whitton
Hello,

On Wed 15 Jul 2020 at 05:19PM +02, Markus Koschany wrote:

> Thanks for your reply. I'm glad that ublock-origin hasn't been simply
> forgotten. However I'd like to suggest to implement a strict FIFO queue
> because now it is more like FILO. This would automatically reduce
> support requests like this one to a minimum because everyone would be
> able to watch the progress.

We're all volunteers, and generally I think this sort of thing would
make NEW processing feel like drudgery.

More specifically, not sure this could work well because the amount of
time packages take to process varies considerably, so if we only have
time for some small packages, we want to be able to get those through,
and not be stopped just because of a rule that we have to process the
oldest item in the queue.

> I also recommend to prioritize binary-new packages because they should
> require less work than completely new ones since the check for DFSG
> compliance has already happened once before.  The focus should really
> be more on conflicting package names or binaries and I'm sure this
> could be automated.

My experience shows that they often take *more* time, unfortunately.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#965073: macs: shared library is not properly linked with libm

2020-07-15 Thread Aurelien Jarno
Package: macs
Version: 2.2.7.1-2
Severity: serious
Tags: patch

macs use the log() math function, but doesn't link link with libm.so.
This causes the non-versioned __log_finite symbol to be used, which in
turn causes issues when glibc version is upgraded:

https://ci.debian.net/data/autopkgtest/testing/amd64/m/macs/6261687/log.gz

The attached patch fixes that.
--- macs-2.2.7.1.orig/setup.py
+++ macs-2.2.7.1/setup.py
@@ -59,8 +59,8 @@ def main():
Extension("MACS2.IO.FixWidthTrack", 
["MACS2/IO/FixWidthTrack.pyx"], include_dirs=numpy_include_dir, 
extra_compile_args=extra_c_args),
Extension("MACS2.IO.PairedEndTrack", 
["MACS2/IO/PairedEndTrack.pyx"], include_dirs=numpy_include_dir, 
extra_compile_args=extra_c_args),
Extension("MACS2.IO.BedGraph", ["MACS2/IO/BedGraph.pyx"], 
libraries=["m"], extra_compile_args=extra_c_args),
-   Extension("MACS2.IO.ScoreTrack", 
["MACS2/IO/ScoreTrack.pyx"], include_dirs=numpy_include_dir, 
extra_compile_args=extra_c_args ),
-   Extension("MACS2.IO.CallPeakUnit", 
["MACS2/IO/CallPeakUnit.pyx"], include_dirs=numpy_include_dir, 
extra_compile_args=extra_c_args),
+   Extension("MACS2.IO.ScoreTrack", 
["MACS2/IO/ScoreTrack.pyx"], libraries=["m"], include_dirs=numpy_include_dir, 
extra_compile_args=extra_c_args ),
+   Extension("MACS2.IO.CallPeakUnit", 
["MACS2/IO/CallPeakUnit.pyx"], libraries=["m"], include_dirs=numpy_include_dir, 
extra_compile_args=extra_c_args),
#Extension("MACS2.Statistics", ["MACS2/Statistics.pyx"], 
libraries=["m"], include_dirs=["MACS2/",numpy_get_include()], 
extra_compile_args=extra_c_args),
 ]
 


Bug#964922: sudo: segmentation fault when include directive is active in /etc/sudoers

2020-07-15 Thread Bdale Garbee
tags 964922 +pending
thanks

Thorsten Glaser  writes:

> On Sun, 12 Jul 2020, Bdale Garbee wrote:
>
>> However, since your but report caused *me* to go read that and realize @
>> is now preferred to # for that directive, I'm updating the default
>> sudoers file for Debian to use @.  Perhaps that will help reduce this
>> particular form of confusion in the future.
>
> The file now reads:
>
> | # See sudoers(5) for more information on "#include" directives:
> |
> | @includedir /etc/sudoers.d
>
> Maybe you want to replace the other ‘#’ as well?

Good point.  In my repo for the next upload.

Bdale


signature.asc
Description: PGP signature


Bug#964566: ncal: please handle /usr/bin/cal + manpage via alternatives

2020-07-15 Thread Thorsten Glaser
Michael Meskes dixit:

>> The locale doesnbt contain enough information to calculate calendar
>> weeks:
>> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap07.html
>
>Well, our locales do I think.
>
>> Therebs neither a data field for the first day of the week, nor one
>> for
>> the various ways to calculate a calendar week.
>
>But there are, for instance:
>
>michael@feivel:~$ locale -kc week-1stweek
>LC_TIME
>week-1stweek=1

Hrm, locale(5) shows…

   week   followed  by a list of three values separated by semicolons: The
  number of days in a week (by default 7), a date of beginning  of
  the  week  (by  default  corresponds to Sunday), and the minimal
  length of the first week in year (by default 4).  Regarding  the
  start  of  the  week,  19971130  shall  be  used  for Sunday and
  19971201 shall be used for Monday.  See NOTES.

… but that’s neither accessible…

tglase@tglase-nb:~ $ locale -kc first_weekday
LC_TIME
first_weekday=1
tglase@tglase-nb:~ $ locale -kc week
locale: unknown name "week"

>I haven't seen any error in ncal so far, but if you see some it might

… nor does ncal use the locale for this, so, no, it does not use
appropriate calendar week calculation rules.

>be more helpful to report and/or fix those as ncal should not show

I’m honestly not interested in working on ncal, given I don’t even use
it and have a perfectly working implementation (I *did*, initially,
plan on patching ncal to support various standards for calendar week
calculation, until I found that OpenBSD’s cal already has them right).

bye,
//mirabilos
-- 
[...] if maybe ext3fs wasn't a better pick, or jfs, or maybe reiserfs, oh but
what about xfs, and if only i had waited until reiser4 was ready... in the be-
ginning, there was ffs, and in the middle, there was ffs, and at the end, there
was still ffs, and the sys admins knew it was good. :)  -- Ted Unangst über *fs



Bug#965061: qemu-system-common: Should have a way to specify passwords without being visible to ps without needing SASL

2020-07-15 Thread Michael Tokarev
Hi!

Russel, what's the purpose of this bugreport,
what you expect the maintainer to do with it?

Thanks,

/mjt



Bug#964780: libreoffice-writer crashes on startup after upgrade to 1:7.0.0~rc1-5

2020-07-15 Thread Rene Engelhard
Hi,

Am 15.07.20 um 17:34 schrieb Rene Engelhard:
>>
>> ,
>> | $ libreoffice 
>> | : CommandLine Error: Option 'polly' registered more than once!
>> | LLVM ERROR: inconsistency in registered CommandLine options
>> `
> 
> I'd have a look what causes this. Wherever this "polly" "command-line"
> option is set.
> 
> LO doesn't set it.

And given
https://www.google.com/search?q=LLVM+ERROR%3A+inconsistency+in+registered+CommandLine+options+LibreOffice

this also seems to happen in all possible situations. Also not only for
LibreOffice. Also in cmake usage, OpenCL stuff, ...

"Good", now we have two non-bugs mangled in one bug.

Actually I already wanted to ask Thorsten whether this "bug" could have
be closed...

Regards,

Rene



Bug#964780: libreoffice-writer crashes on startup after upgrade to 1:7.0.0~rc1-5

2020-07-15 Thread Rene Engelhard
Hi,

Am 15.07.20 um 16:10 schrieb Rogério Brito:

> I tried to find bug reports about this, found only this one and expected to
> find more, waited a few days, and this is still the only problem reported so
> far, which I found strange.

Why? That just shows it works in most cases, and breaks in "special" ones. And 
of course if it works in most cases people don't report a bug ;-)

> Nevertheless, what I am seeing may or may not be related to the bug that
> Thorsten reported (in which case a new bug should be filed, of course), but
> removing ~/.config/.libreoffice and invoking libreoffice on the command line

Given Thorsten says it works with a clean profile, how should it? You
said you removed it and got *AN OTHER* error.

Can "bugs" please be kept separate?

> briefly shows the splash screen and, then, shows the following message on my
> terminal:
>
> ,
> | $ libreoffice 
> | : CommandLine Error: Option 'polly' registered more than once!
> | LLVM ERROR: inconsistency in registered CommandLine options
> `

I'd have a look what causes this. Wherever this "polly" "command-line"
option is set.

LO doesn't set it.


(And only a subset of LO is built with clang but not linked with LLVM or
otherwise using it, so

that can't be it either, especially since googling for it (and I think
there was a similar bug months ago with an other option) predates 7.0s
clang usage)

Regards,

Rene



Bug#952645: Please clarify the status of ublock-origin in NEW

2020-07-15 Thread Markus Koschany
Hello,

Am 14.07.20 um 17:22 schrieb Sean Whitton:
[...]
>> Please clarify the status of ublock-origin and why it is still in the
>> NEW queue.
> 
> Simply that we do not have enough active FTP team members.
> 
> Just to note that being in binary-NEW makes no difference; it gets a
> full check as if it were a new source package.

Thanks for your reply. I'm glad that ublock-origin hasn't been simply
forgotten. However I'd like to suggest to implement a strict FIFO queue
because now it is more like FILO. This would automatically reduce
support requests like this one to a minimum because everyone would be
able to watch the progress. I also recommend to prioritize binary-new
packages because they should require less work than completely new ones
since the check for DFSG compliance has already happened once before.
The focus should really be more on conflicting package names or binaries
and I'm sure this could be automated.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature


Bug#965061: qemu-system-common: Should have a way to specify passwords without being visible to ps without needing SASL

2020-07-15 Thread Russell Coker
Package: qemu-system-common
Version: 1:5.0-6
Severity: normal
Tags: upstream

The spice video options includes "password=" which is visible on the 
kvm/qemu command-line.
While using SASL should solve this problem it is more complex to setup so most 
people who use
password authentication for Spice access will have it visible via ps to all 
users on the system.
I think it should be easy to secure systems, so something like a 
"passwordfile=" option would be
good to allow easily setting a password without using SASL and without exposing 
the password to
all users on the same system.

For an example of how other programs do it here's an exerpt from the mysql man 
page:

   Specifying a password on the command line should be considered 
insecure. You can use
   an option file to avoid giving the password on the command line.

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (800, 'testing'), (700, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: default

Versions of packages qemu-system-common depends on:
ii  libaio10.3.112-8
ii  libc6  2.30-8
ii  libcap-ng0 0.7.9-2.2
ii  libgbm120.1.2-1
ii  libgcc-s1  10.1.0-4
ii  libglib2.0-0   2.64.3-2
ii  libgnutls303.6.14-2
ii  libnettle7 3.5.1+really3.5.1-2
ii  libpixman-1-0  0.36.0-1
ii  libseccomp22.4.3-1+b1
ii  liburing1  0.6-3
ii  libvirglrenderer1  0.8.2-2
ii  zlib1g 1:1.2.11.dfsg-2

qemu-system-common recommends no packages.

qemu-system-common suggests no packages.

-- no debconf information



Bug#964922: sudo: segmentation fault when include directive is active in /etc/sudoers

2020-07-15 Thread Thorsten Glaser
On Sun, 12 Jul 2020, Bdale Garbee wrote:

> However, since your but report caused *me* to go read that and realize @
> is now preferred to # for that directive, I'm updating the default
> sudoers file for Debian to use @.  Perhaps that will help reduce this
> particular form of confusion in the future.

The file now reads:

| # See sudoers(5) for more information on "#include" directives:
|
| @includedir /etc/sudoers.d

Maybe you want to replace the other ‘#’ as well?

bye,
//mirabilos
-- 
«MyISAM tables -will- get corrupted eventually. This is a fact of life. »
“mysql is about as much database as ms access” – “MSSQL at least descends
from a database” “it's a rebranded SyBase” “MySQL however was born from a
flatfile and went downhill from there” – “at least jetDB doesn’t claim to
be a database”  ‣‣‣ Please, http://deb.li/mysql and MariaDB, finally die!



Bug#964970: RFP: dotpagemod -- Firefox add-on to load local CSS and JavaScript from your dotfiles into websites

2020-07-15 Thread David Kalnischkies
On Mon, Jul 13, 2020 at 05:16:22PM +0200, Jakub Wilk wrote:
> * Package name: dotpagemod

WOW.

As I am considering myself the only user I am not mentally
prepared for this… ò_O


>   Programming Lang: JavaScript

Additionally, the companion app is fumbled together in Python.

I initially wrote this in 2016 and then rewrote it in 2017 to be
a webextension – since then it does its job and hasn't required
many changes even through its in heavy use here (I am mildly
surprised webext API is really kept as stable as promised!).

That said, Firefox 68 introduced some new APIs (contentScripts and
userScripts) which might be an option for future changes – but they
don't seem to support local file access & currently I think the
extension could actually work in Chromium, too. Never tried though.
Upstream became a bit lazy after it worked as intended… 


I am not much of a packager myself and don't know ATM if¹ and how
webext-* are to be packaged. It tickles me enough to make me
try it eventually though, but no roadmap predictions as I have
other Debian-related projects I want to finish first.

So, no hard feelings if someone else wants to try before me.
Happy to help as upstream and/or sponsor (if needed) even.
[Even if I am still not really believing there are other users…]


Best regards

David Kalnischkies

¹ sometimes, I get the impression that side-loading browser add-ons
is on its way out upstream and hence heavily discouraged even here.


signature.asc
Description: PGP signature


Bug#965060: spice-client-gtk: Should have a way to specify passwords without being visible to ps

2020-07-15 Thread Russell Coker
Package: spice-client-gtk
Version: 0.38-2
Severity: normal
Tags: upstream

The spicy command (and related commands in this package) only allow scripting a 
password via the
-w parameter.  This means that any program that can run ps on the same system 
can see the password.
This may or may not be a security issue depending on what the goals are.  I 
think that users who
want to script connections but not allow ps to see the password should have an 
option.  For an
example of how other programs do it here's an exerpt from the mysql man page:

   Specifying a password on the command line should be considered 
insecure. You can use
   an option file to avoid giving the password on the command line.


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (800, 'testing'), (700, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: default

Versions of packages spice-client-gtk depends on:
ii  libc6   2.30-8
ii  libglib2.0-02.64.3-2
ii  libgstreamer1.0-0   1.16.2-2
ii  libgtk-3-0  3.24.20-1
ii  libspice-client-glib-2.0-8  0.38-2
ii  libspice-client-gtk-3.0-5   0.38-2
ii  libusbredirhost10.8.0-1+b1
ii  libusbredirparser1  0.8.0-1+b1

spice-client-gtk recommends no packages.

spice-client-gtk suggests no packages.

-- debconf-show failed



Bug#965072: ksh93: posix_spawn-related exec format error

2020-07-15 Thread Thorsten Glaser
Package: ksh
Version: 93u+20120801-3.1
Severity: important

(stretch-i386)tglase@tglase:~ $ ksh93
ksh93$ cat TODO | while read line; do ls; done
ls: ls: cannot execute [Exec format error]
[…]

We got this as bugreport in #ksh on IRC, and I can reproduce it, so
forwarding here:

22:43 -!- CrystalMath [~coderain@reactos/developer/theflash] has joined #ksh
22:43 < CrystalMath> hi all
22:43 < CrystalMath> sometimes, with ksh93, i get a strange NOEXEC error
22:43 < CrystalMath> err, ENOEXEC, i mean
23:03 < CrystalMath> looking at ksh through strace, it seems that it happens 
when setpgid() fails with -EPERM
23:03 < CrystalMath> possibly a race condition
23:35 < CrystalMath> seems to be a bug in posix_spawn()
23:35 < CrystalMath> i'll try a newer version of ksh93
23:41 < CrystalMath> nope, the latest version still fails
23:42 < CrystalMath> how did people miss such a glaring bug?
23:46 < twkm> i don't think i've ever seen such.  is this for a something with 
resource constraints?
23:47 < CrystalMath> no
23:48 < CrystalMath> regular normal computer
23:48 < CrystalMath> posix_spawn()'s strange failure appears to be -EPERM
23:48 < CrystalMath> i suspect a pid-related race condition
23:49 < twkm> so not a container, jail, or nproc (ulimit -u) set low?
23:49 < CrystalMath> ulimit -u is 61777
23:49 < CrystalMath> not a container, jail, nor chroot
23:53 < CrystalMath> just cat any file into while read line; do ls; done
23:53 < CrystalMath> ls: ls: cannot execute [Exec format error]
23:55 < CrystalMath> hm
23:55 < CrystalMath> can't seem to replicate in slackware
23:55 < CrystalMath> only happens in debian
23:55 < twkm> failing disk.
23:55 < CrystalMath> can't be
23:55 < twkm> not ksh at any rate.  that's the kernel whining.
23:55 < CrystalMath> it is ksh
23:55 < twkm> it's merely reported by ksh.
23:56 < CrystalMath> i traced it with strace
23:56 < CrystalMath> what happens
23:56 < CrystalMath> is that posix_spawn() fails
23:56 < CrystalMath> and ksh tries to interpret it as a script
23:56 < CrystalMath> but it's an ELF file
23:56 < CrystalMath> the weird part is the failure of posix_spawn() which i 
cannot explain
23:57 < CrystalMath> inside a slackware chroot i have, the bug does not occur, 
which is why i will look closely 
 at the version number now
23:57 < CrystalMath> both report: sh (AT Research) 93u+ 2012-08-01
23:59 < CrystalMath> how do i tell ksh not to load my ~/.kshrc?
Day changed to 15 Jul 2020
00:00 < twkm> if the kernel reports it can't exec the script ksh will attempt 
to interpret it.
00:01 < CrystalMath> but the error was EPERM
00:02 < twkm> picking the system i happen to be on at the moment:
00:02 < twkm>EPERM  The filesystem is mounted nosuid, the user is not 
the superuser,
00:02 < twkm>   and the file has the set-user-ID or set-group-ID 
bit set.
00:02 < twkm>EPERM  The  process  is being traced, the user is not the 
superuser and
00:02 < twkm>   the file has the set-user-ID or set-group-ID bit 
set.
00:03 < CrystalMath> 24899 setpgid(0, 24898) = -1 EPERM 
(Operation not permitted)
00:03 < CrystalMath> this is the strange failure
00:03 < CrystalMath> whenever this happens, down the line, ksh seems to try to 
interpret it as a script
00:04 < twkm> because [repeat:] if the kernel reports it can't exec the script 
ksh will attempt to interpret it.
00:04 < CrystalMath> there was no call to execve()
00:04 < twkm> your systems docs for why setpgid returned eperm are germane.
00:05 < twkm> no exec because something getting ready for the exec failed.
00:12 < CrystalMath> i changed the code of ksh to use something other than 
posix_spawn()
00:14 < CrystalMath> rebuilding now
00:14 < CrystalMath> it has several options in the code but it prefers 
posix_spawn() if it's available, if 
 removed that part with #if 0
00:20 < CrystalMath> that fixed it!
00:20 < CrystalMath> the modified version i made does not have the probelm
00:20 < CrystalMath> *problem
00:20 < CrystalMath> i have no idea why posix_spawn() is broken on my system
00:21 < CrystalMath> after quite of bit of hammering ksh, not a single exec 
format error!
00:21 < CrystalMath> before it was very common
00:35 < CrystalMath> either way i conclude that this bug was not in ksh but in 
glibc
00:36 < CrystalMath> because the call to posix_spawn() was correct, but didn't 
work as expected
14:26 < mirabilos> can reproduce on Debian
14:26 < mirabilos> also on stock ksh93u but not ksh93v
14:26 < mirabilos> ksh93t just stops itself
14:27 < mirabilos> $ ksh93t
14:27 < mirabilos> $ cat TODO | while read line; do ls; done
14:27 < mirabilos> [2] + Stopped (tty output) \ksh93t

This happens in stretch, buster and sid *AT LEAST*.

So, this might be a bug in ksh93 and/or one in glibc. If it’s just one
in glibc, I’d suggest cloning this bug and reassigning it against glibc
while treating the bug against ksh93 as a request to change building it
to avoid posix_spawn. 

Bug#965071: spamassassin 3.4.4-1 invalid home page link

2020-07-15 Thread Сергей Фёдоров
Package: spamassassin
Version: 3.4.4-1
Severity: normal
Tags: a11y

For the "spamassassin" package version 3.4.4-1

instead of " Home page: https://www.spamassassin.org/;

it should be " Home page: https://spamassassin.apache.org/;

otherwise, we see the content of the page "Apache OpenOffice - Official Site - 
The Free and Open Productivity Suite"



Bug#964790: libmicrohttpd: please make autopkgtests cross-friendly

2020-07-15 Thread Bertrand Marc
severity 964790 wishlist
thanks

Hi Gianfranco,

This looks fine to me, please go ahead.

Cheers,
Bertrand



Bug#965069: python3.8: Breaks at least python3-aioxmpp (CPython upstream bug 41295)

2020-07-15 Thread Jonas Schäfer
Package: python3.8
Version: 3.8.4-1
Severity: normal
Tags: upstream

Dear Maintainer,

Python 3.8.4 has a regression [1] (compared to Python 3.8.4~rc1 and earlier
versions) which break python3-aioxmpp [2] and potentially other packages [3].

The issue is being addressed upstream [4].

The impact is that importing or using the affected packages may fail with
an error message similar to:

TypeError: can't apply this __setattr__ to SomeTypeName

Please see the minimal reproducer in [4] or try to `import aioxmpp` with
python3.8-3.8.4-1 from experimental after installing python3-aioxmpp.

I’m not quite sure what can/should be done about this, but I wanted to file
this bug to track the issue, since it’ll cause build failures for
python-aioxmpp.

Kind regards & thanks,
Jonas Schäfer

   [1]: https://bugs.python.org/issue41295
   [2]: https://github.com/horazont/aioxmpp/issues/342
   [3]: https://github.com/pallets/flask-sqlalchemy/issues/852
   [4]: https://github.com/python/cpython/pull/21473



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

Kernel: Linux 5.6.0-2-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3.8 depends on:
ii  libpython3.8-stdlib  3.8.4-1
ii  mime-support 3.64
ii  python3.8-minimal3.8.4-1

python3.8 recommends no packages.

Versions of packages python3.8 suggests:
ii  binutils2.34-8
ii  python3.8-doc   3.8.4~rc1-1
ii  python3.8-venv  3.8.4-1

-- no debconf information


Bug#965070: python-certbot: [INTL:nl] Dutch translation of debconf messages

2020-07-15 Thread Frans Spiesschaert
 
 
Package: python-certbot 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch translation of python-certbot
debconf messages. 
It has been submitted for review to the debian-l10n-dutch mailing list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Kind regards,
Frans Spiesschaert



nl.po.gz
Description: application/gzip


Bug#965068: RFP: New Session Manager - Assists music production by grouping standalone programs into sessions.

2020-07-15 Thread Nils Hilbricht
Package: wnpp
Version: N/A; reported 2020-07-15
Severity: wishlist

* Package name : New Session Manager
Version : 1.4.0
Upstream Author : Hilbricht, Nils 
* URL : https://github.com/linuxaudio/new-session-manager
* License : (GPLv3, one ISC License header file, CC-By-Sa for Documentation)
Description : 

New Session Manager (NSM) is a tool to assist music production by grouping 
standalone programs into sessions. Your workflow becomes easy to manage, robust 
and fast by leveraging the full potential of cooperative applications.

It is a community version of the "NON Session Manager" and free in every sense 
of the word: free of cost, free to share and use, free of spyware or ads, 
free-and-open-source.

You can create a session, or project, add programs to it and then use commands 
to save, start/stop, hide/show all programs at once, or individually. At a 
later date you can then re-open the session and continue where you left off.


Dependencies are: liblo (OSC library), FLTK 1.3, JACK Audio Connection Kit 
(runtime)
Build system is meson.

This software already has been packaged for 

Fedora http://rpms.remirepo.net/rpmphp/zoom.php?rpm=new-session-manager
Archlinux 
https://www.archlinux.org/packages/community/x86_64/new-session-manager/
KXStudio https://kx.studio/Repositories:Applications
Ubuntu (Studio) approved, WIP


pgppoyZlGbuV0.pgp
Description: PGP signature


Bug#965067: googler: "No results"

2020-07-15 Thread Jakub Wilk

Package: googler
Version: 3.7.1-1
Severity: grave
Control: fixed -1 4.1-1

googler in buster seems completely broken.
I get "No results" every time.

--
Jakub Wilk



Bug#965064: pkg-haskell-tools: FTBFS in unstable

2020-07-15 Thread Iain Lane
On Wed, Jul 15, 2020 at 02:40:39PM +0100, Dimitri John Ledkov wrote:
> • No instance for (MonadFail Action) arising from a use of ‘fail’

AFAIK (slightly out of the loop), this is because fail is not a part of 
Monad any more

  
https://downloads.haskell.org/~ghc/8.8.1/docs/html/users_guide/8.8.1-notes.html

Upgrading shake will fix this, or it can be worked around in the 
meantime in pkg-haskell-tools by

import Control.Monad.Fail as fail

instance MonadFail Action where
  fail = Fail.fail

Don't have time to upload it myself, but HTH.

Cheers,

-- 
Iain Lane  [ i...@orangesquash.org.uk ]
Debian Developer   [ la...@debian.org ]
Ubuntu Developer   [ la...@ubuntu.com ]


signature.asc
Description: PGP signature


Bug#964780: libreoffice-writer crashes on startup after upgrade to 1:7.0.0~rc1-5

2020-07-15 Thread Rogério Brito
Hi there.

On Jul 10 2020, Rene Engelhard wrote:
> Am 10.07.20 um 16:44 schrieb Rene Engelhard:
> > You write "crashes". I didn't see a crash in strace? You it actually
> > crash and did you attach gdb as written in the reportbug message? Or did
> > it fail to start? (That isn't a crash.)
> Actually there's SIGSEGV at the end ...

Right after the upgrade to the version mentioned in the subject, I started
seeing the problem.

I tried to find bug reports about this, found only this one and expected to
find more, waited a few days, and this is still the only problem reported so
far, which I found strange.

Nevertheless, what I am seeing may or may not be related to the bug that
Thorsten reported (in which case a new bug should be filed, of course), but
removing ~/.config/.libreoffice and invoking libreoffice on the command line
briefly shows the splash screen and, then, shows the following message on my
terminal:

,
| $ libreoffice 
| : CommandLine Error: Option 'polly' registered more than once!
| LLVM ERROR: inconsistency in registered CommandLine options
`

I will send the compressed strace log to this bug right after this message.

If you need further information, please let me know.


Thanks,

Rogério Brito.

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br



Bug#948375: Debian Ceph maintenance release / support policy

2020-07-15 Thread Adam D. Barratt
On Wed, 2020-07-15 at 10:23 +0100, Tim Small wrote:
> What would the procedure be for getting Debian to adopt a similar
> policy with Ceph as it does with Chromium, Firefox, Thunderbird?
[...]
> My assumption is that the Debian Release team don't fully review
> every diff for Firefox or Chromium since neither the Debian
> maintainers nor release team have the bandwidth for this.

As a small note here, the Release Team don't really manage updates to
the packages you listed. They're released via the security archive, and
simply pulled into proposed-updates and therefore point releases from
there.

(I'm not suggesting anything about whether that would be a suitable
model for Ceph to follow, simply that it's perhaps not the best
comparison.)

Regards,

Adam



Bug#965066: googler: leaks MAC address

2020-07-15 Thread Jakub Wilk

Package: googler
Version: 4.1-1

Googler does this:

  self._query_dict = {
   # ...
   'sei': 
base64.encodebytes(uuid.uuid1().bytes).decode("ascii").rstrip('=\n').replace('/',
 '_'),
  }

This may leak the machine's MAC address to Google.
Please use random-based uuid.uuid4() instead.


-- System Information:
Architecture: i386

Versions of packages googler depends on:
ii  python3  3.8.2-3

--
Jakub Wilk



Bug#965065: ITP: golang-github-mmcloughlin-avo -- Generate x86 Assembly with Go

2020-07-15 Thread Roger Shimizu
Package: wnpp
Severity: wishlist
Owner: Roger Shimizu 

* Package name: golang-github-mmcloughlin-avo
  Version : 0.0~git20200523.4439b6b-1
  Upstream Author : Michael McLoughlin
* URL : https://github.com/mmcloughlin/avo
* License : BSD-3-clause
  Programming Lang: Go
  Description : Generate x86 Assembly with Go

 avo makes high-performance Go assembly easier to write, review and
 maintain. The avo package presents a familiar assembly-like interface
 that simplifies development without sacrificing performance:
 - Use Go control structures for assembly generation; avo programs
   are Go programs
 - Register allocation: write functions with virtual registers and avo
   assigns physical registers for you
 - Automatically load arguments and store return values: ensure memory
   offsets are correct for complex structures
 - Generation of stub files to interface with your Go package

This is the new dependency of latest golang-github-cloudflare-circl:
- https://tracker.debian.org/pkg/golang-github-cloudflare-circl
- https://github.com/cloudflare/circl



Bug#963247: ignition-fuel-tools FTBFS with Protobuf 3.12.3

2020-07-15 Thread jspricke

Hi,

seems like this was not enough:

/usr/bin/ld: 
/usr/lib/gcc/aarch64-linux-gnu/9/../../../aarch64-linux-gnu/libignition-fuel_tools4.so:
 undefined reference to `ignition::msgs::FuelMetadata::FuelMetadata()'

https://ci.debian.net/data/autopkgtest/testing/arm64/i/ignition-fuel-tools/6276839/log.gz

Looks like the new protobuf drops a symbol.
I'm not sure how to proceed:
- patch protobuf to get the symbol back?
- bump Sonames of all ign* packages?
- Any other idea?

Cheers Jochen

* jspri...@debian.org  [2020-07-14 23:15]:

* Sebastian Ramacher  [2020-07-13 13:21]:

Depends: libprotobuf-dev (>= ${protobuf:Upstream-Version}), libprotobuf-dev (< 
${protobuf:Upstream-Version}a)

override_dh_gencontrol:
   dh_gencontrol -- -Vprotobuf:Upstream-Version="$(shell dpkg-query -W -f 
'$${Source:Upstream-Version}' libprotobuf-dev | cut -d. -f1-2)"

Or would there be a better way?


This actually didn't work and I used awk instead:

https://salsa.debian.org/science-team/ignition-msgs/-/commit/2d7c4d4d3aeb384d60ab7116c60075b884a8ffba

I uploaded the new version.

Cheers Jochen





signature.asc
Description: PGP signature


Bug#965063: phototonic: Crashes on startup, if exifThumbRotationEnabled=true

2020-07-15 Thread RichTea
Package: phototonic
Version: 2.1-3
Severity: normal
Tags: upstream

Dear Maintainer,

   * What led up to the situation?
  Changed the option in Prefrances -> Thumbnails ->
  "Rotate thumbnail according to Exif orientation value" to enabled

   * What was the outcome of this action?
  This causes phototonic to segfault when atempting to rotate a Thumbnail
  with the message "Failed to read Exif metadata"

   * What outcome did you expect instead?
Thumbnailes to be displayed is the "correct" Exif defined orientation

While investegating the fault I Checked out and compiled HEAD from the upstream
repo.
Using HEAD the bug did not happen.
Found a fix in code that resolves the issue (gig commit
baa2a76881059df8d04f23f7c5175aee11c0cfbf)
Other updates could also be responcible to resolving this issue
This update has not been added to a tag or release upstream yet.

I have build and installed my own local copy of the deb
phototonic_2.1-3_amd64.deb and tested with sucess (this was probally a bad
idea!



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

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

Versions of packages phototonic depends on:
ii  libc6   2.28-10
ii  libexiv2-14 0.25-4
ii  libgcc1 1:8.3.0-6
ii  libgl1  1.1.0-1
ii  libqt5core5a5.11.3+dfsg1-1+deb10u3
ii  libqt5gui5  5.11.3+dfsg1-1+deb10u3
ii  libqt5widgets5  5.11.3+dfsg1-1+deb10u3
ii  libstdc++6  8.3.0-6

Versions of packages phototonic recommends:
ii  libqt5svg5 5.11.3-2
ii  qt5-image-formats-plugins  5.11.3-2

phototonic suggests no packages.

-- no debconf information



Bug#965062: systemd: Cannot resolve user name systemd-network: No such process

2020-07-15 Thread Michael Biebl
Am 15.07.20 um 14:00 schrieb Marc Lehmann:
> Package: systemd
> Version: 241-7~deb10u4
> Severity: normal
> 
> Dear Maintainer,
> 
> after upgrading multiple systems from jessie to buster, systemd-networkd
> and systemd-resolved no longer start on any of them, both with similar
> error messages:
> 
> Jul 15 11:42:17 pxe systemd-networkd[327]: Cannot resolve user name 
> systemd-network: No such process
> Jul 15 11:42:18 pxe systemd-resolved[472]: Cannot resolve user name 
> systemd-resolve: No such process
> 

Can you attach the full output of
systemctl status systemd-networkd
systemctl cat systemd-networkd
getent passwd systemd-network

And your /etc/nsswitch.conf



signature.asc
Description: OpenPGP digital signature


  1   2   >