Bug#968589: Need to restart internet connections upon upgrade, else no names can be resolved

[積丹尼 Dan Jacobson]

Package: systemd
Version: 246.2-1

After installing this package,
one needs to restart their internet connection,
else no sites can be resolved:
$ w3m example.com
w3m: Can't load example.com.

Bug#968588: dovecot-gssapi: GSSAPI login broke

[Mikko Rasa]

Package: dovecot-gssapi
Version: 1:2.3.11.3+dfsg1-1
Severity: grave
Justification: renders package unusable

After upgrading dovecot to 1:2.3.11.3+dfsg1-1, GSSAPI login no longer works.
I'm using Thunderbird as client and it says the Kerberos ticket was not
accepted.  A downgrade back to 1:2.3.10.1+dfsg1-2 fixes the situation.

-- Package-specific info:

dovecot configuration
-
# 2.3.10.1 (a3d0e1171): /etc/dovecot/dovecot.conf
# Pigeonhole version 0.5.10 (bf8ef1c2)
# OS: Linux 5.4.35-core2-server x86_64 Debian bullseye/sid 
# Hostname: capybara.tdb.fi
auth_krb5_keytab = /etc/dovecot/private/dovecot.keytab
auth_mechanisms = plain gssapi
mail_location = maildir:~/Maildir
mail_privileged_group = mail
namespace inbox {
  inbox = yes
  location = 
  mailbox Drafts {
special_use = \Drafts
  }
  mailbox Junk {
special_use = \Junk
  }
  mailbox Sent {
special_use = \Sent
  }
  mailbox "Sent Messages" {
special_use = \Sent
  }
  mailbox Trash {
special_use = \Trash
  }
  prefix = 
}
passdb {
  args = scheme=CRYPT username_format=%u /etc/dovecot/users
  driver = passwd-file
}
passdb {
  driver = pam
}
plugin {
  sieve = file:~/sieve;active=~/.dovecot.sieve
}
protocols = " imap"
service auth {
  unix_listener /var/spool/postfix/private/auth {
group = postfix
mode = 0666
user = postfix
  }
}
ssl_cert = 
ii  dovecot-gssapi 1:2.3.10.1+dfsg1-2
ii  dovecot-imapd  1:2.3.10.1+dfsg1-2
pn  dovecot-ldap   
pn  dovecot-lmtpd  
pn  dovecot-managesieved   
pn  dovecot-mysql  
pn  dovecot-pgsql  
pn  dovecot-pop3d  
ii  dovecot-sieve  1:2.3.10.1+dfsg1-2
pn  dovecot-sqlite 

Bug#963659: pybind11: FTBFS with Sphinx 3.1: File "/usr/lib/python3/dist-packages/sphinx/domains/c.py", line 3093, in object_type / raise NotImplementedError())

[Drew Parsons]

The FTBFS is still happening with sphinx 3.2.1.

Bug#968587: RM: breeze-grub/experimental -- ROM; older version not autoremoved from experimental

[Pino Toscano]

Package: ftp.debian.org
Severity: normal

Hi,

please remove src:breeze-grub from experimental, as it is an older
version than what currently in unstable. Not sure why it was not
automatically removed.

Thanks,
-- 
Pino

Bug#968586: ifupdown: No way to require IN and PD with inet6 config

[Carl Perry]

Package: ifupdown
Version: 0.8.35
Severity: important
Tags: ipv6

Dear Maintainer,

My ISP (Spectrum in the US) no longer support SLAAC for IPv6 autoconfiguration. 
Instead, DHCPv6 is
required. However, a configuration stanza like:

iface eth1 inet6 dhcp
  accept_ra 0
  autoconf 0
  request_prefix 1

Will return a Prefix Deletgation (PD) but not an Interface Address (IN). The 
generated dhclient
command line was:

/sbin/dhclient -6 -v -pf /run/dhclient6.eth1.pid -lf 
/var/lib/dhcp/dhclient6.eth1.leases -I -P -N -df 
/var/lib/dhcp/dhclient.eth1.leases eth1

Adding the -R command line flag resolves the issue, but I could not find a way 
to add this via the
/etc/interfaces file (I tried adding `dhcp 1` but that had no effect). Running 
the command above with
the -R flag correctly configures the prefix delegation and the WAN interface. 
It did not add a default
route correctly, but that was probably because I did it manually. Using 
`rdisc6` and adding it
manually via `ip -6 route add default via` worked. 

I think the problem can be resolved by having a flag which will add the '-R' 
flag to require all
DHCPv6 components to get a response, as the ISP's server seems to require 
multiple queries to
get the PD and IN responses. I can provide logs of both with and without the 
`-R` flag if that
will help.

  -Carl


-- Package-specific info:
--- /etc/network/interfaces:
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
# The loopback network interface
auto lo eth1 eth2 he-ipv6 vlan1 vlan2 vlan3 vlan4 vlan5 vlan6 vlan7
iface lo inet loopback

# The primary network interface
iface eth1 inet dhcp
# This is an autoconfigured IPv6 interface
iface eth1 inet6 dhcp
  accept_ra 0
  autoconf 0
  request_prefix 1
  #post-up ip addr add 192.168.100.2/24 dev eth1
  #pre-down ip addr del 192.168.100.2/24 dev eth1

iface he-ipv6 inet6 v4tunnel
endpoint 184.105.253.10
address 2001:470:1f0e:296::2
netmask 64
ttl 64
post-up ip -6 route flush table he
post-up ip -6 route add default via 2001:470:1f0e:296::1 table he
post-up ip -6 rule add priority 15001 from 2001:470:1f0f:296::/64 to 
2000::/3 table he
post-up ip -6 rule add priority 15002 from 2001:470:b8b2::/48 to 
2000::/3 table he

# Internal network interface
iface eth2 inet manual
iface vlan1 inet static
address 192.168.123.1
netmask 255.255.255.0
vlan-raw-device eth2
dns-nameservers 192.168.123.4
iface vlan1 inet6 manual
accept_ra 0
privext 0
dhcp 0

iface vlan2 inet static
address 192.168.255.1
netmask 255.255.255.0
vlan-raw-device eth2
iface vlan2 inet6 static
address 2001:470:b8b2:2::1
netmask 64
accept_ra 0
privext 0

iface vlan3 inet static
address 192.168.203.1
netmask 255.255.255.0
vlan-raw-device eth2
iface vlan3 inet6 static
address 2001:470:b8b2:3::1
netmask 64
accept_ra 0
privext 0

iface vlan4 inet static
address 192.168.204.1
netmask 255.255.255.0
vlan-raw-device eth2
iface vlan4 inet6 static
address 2001:470:b8b2:4::1
netmask 64
accept_ra 0
privext 0

iface vlan5 inet static
address 192.168.205.1
netmask 255.255.255.0
vlan-raw-device eth2
iface vlan5 inet6 static
address 2001:470:b8b2:5::1
netmask 64
accept_ra 0
privext 0

iface vlan6 inet static
address 192.168.206.1
netmask 255.255.255.0
vlan-raw-device eth2
iface vlan6 inet6 static
address 2001:470:b8b2:6::1
netmask 64
accept_ra 0
privext 0

iface vlan7 inet static
address 192.168.207.1
netmask 255.255.255.0
vlan-raw-device eth2
iface vlan7 inet6 static
address 2001:470:b8b2:7::1
netmask 64
accept_ra 0
privext 0

--- up and down scripts installed:
/etc/network/if-down.d:
total 8
-rwxr-xr-x 1 root root 372 Dec  1  2014 openvpn
-rwxr-xr-x 1 root root 800 May 21  2017 postfix
lrwxrwxrwx 1 root root  33 Nov  3  2018 wide-dhcpv6-client -> 
../../wide-dhcpv6/dhcp6c-ifupdown

/etc/network/if-post-down.d:
total 4
-rwxr-xr-x 1 root root 1433 Feb  4  2019 vlan

/etc/network/if-pre-up.d:
total 8
-rwxr-xr-x 1 root root 4224 Feb 21  2019 vlan

/etc/network/if-up.d:
total 20
-rwxr-xr-x 1 root root  677 Feb  4  2019 ip
-rwxr-xr-x 1 root root 4948 Feb  3  2019 mountnfs
-rwxr-xr-x 1 root root  385 Nov 12  2015 openvpn
-rwxr-xr-x 1 root root 1117 May 21  2017 postfix
lrwxrwxrwx 1 root root   33 Nov  3  2018 wide-dhcpv6-client -> 
../../wide-dhcpv6/dhcp6c-ifupdown


-- System Information:
Debian Release: 10.5
  APT prefers stable
  APT policy: (1000, 'stable'), (995, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-8-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: 

Bug#968585: aptly: `aptly version` shows unknown

[Shengjing Zhu]

Package: aptly
Version: 1.4.0+ds1-1
Severity: wishlist

Dear Maintainer,

`aptly version` shows:

aptly version: unknown

Please populate the version info when building.

https://github.com/aptly-dev/aptly/blob/v1.4.0/Makefile#L30

With dh-golang, you can:

```
override_dh_auto_build:
dh_auto_build -- -ldflags "-X main.Version=$(VERSION)"
```

Bug#968584: vim-nox requires sound libraries and freedesktop stuff that doesn't belong in -nox

[Scott Mcdermott]

Package: vim-nox
Version: 2:8.2.0716-3

The package named "vim-nox" now requires an abstract sound library
that uses XDG specification for sound, is packaged by GNOME
maintainers, and pulls in audio libraries and freedesktop sound theme?
What does this have to do with editing files, and how is that "nox"?
The reason we use vim-nox is so all the desktop/gui/X nonsense isn't
needed or installed on our systems. We don't want a stripped vim-tiny
that's barely functional, no syntax highlighting, etc.

Many people install vim-nox on headless systems and it makes no sense
to pull all this stuff in, it appears to be from 0aaaf024.
sound-theme-freedesktop? libasound2? libvorbisfile3? How is that "nox"
? Just because it's not "graphics" doesn't mean it should be included.
Nobody running servers (or even minimal systems like my laptop that's
not running a desktop environment) wants to install sound libraries
and freedesktop themes.

Please revert this dependency and put it in the vim gui package where
it belongs.  Thanks.

Bug#968583: RFS: ukui-notification-daemon/1.0.0-1 [ITP] -- daemon to display passive popup notifications

[handsome_feng]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-Cc: jianfen...@ubuntukylin.com

Dear mentors,

I am looking for a sponsor for my package "ukui-notification-daemon":

 * Package name: ukui-notification-daemon
   Version : 1.0.0-1
   Upstream Author : liushan...@kylinos.cn
 * URL : https://github.com/ukui/ukui-notification-daemon.git
 * License : GPL-3+
 * Vcs : https://github.com/ukui/ukui-notification-daemon
   Section : x11

It builds those binary packages:

  ukui-notification-daemon - daemon to display passive popup notifications

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

  https://mentors.debian.net/package/ukui-notification-daemon/

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

  dget -x https://mentors.debian.net/debian/pool/main/u/ukui-notification-
daemon/ukui-notification-daemon_1.0.0-1.dsc

Changes for the initial release:

 ukui-notification-daemon (1.0.0-1) unstable; urgency=medium
 .
   * Initial release. (Closes: #968552)

Regards,
--
  handsome_feng



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

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

Bug#968416: lintian: Gives ridiculous warning about spelling in overrides file

[Felix Lechner]

Hi Robert,

> Most of the spelling tags
> will be reduced to 'info' severities next week.

Please see 
https://salsa.debian.org/lintian/lintian/-/commit/93e50254ef683200a9433f69035813cf0509eef1

> We'll try to address the line number too

Please see 
https://salsa.debian.org/lintian/lintian/-/commit/69565d4cb9e20542edfc705bd270eb52f9f3a15c

> Aside from those observations, there is an underlying false positive.

We are still working on the underlying false positive.

Kind regards
Felix Lechner

Bug#968578: picard: Tag removal does not work

[eb]

Package: picard
Version: 2.4.1-1
Severity: important
X-Debbugs-Cc: electron.bad...@tutanota.com

Dear Maintainer,

After the latest update, tags cannot be removed from audio files. In order to 
replicate the bug:
1. Add one or more file(s)
2. Select a file
3. Select one of the file tags
4. Right click and select Remove or use Alt-Shift-R shortcut

As a result of the bug, the tag is not removed. This applies to any of the 
tags, also to multiple tags selected.

Kind regards,
eb

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

Kernel: Linux 5.7.0-1-amd64 (SMP w/48 CPU threads)
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:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages picard depends on:
ii  libc6 2.31-3
ii  libchromaprint-tools  1.5.0-1
ii  python3   3.8.2-3
ii  python3-dateutil  2.8.1-4
ii  python3-libdiscid 1.1-1+b2
ii  python3-mutagen   1.44.0-1
ii  python3-pyqt5 5.15.0+dfsg-1+b1

Versions of packages picard recommends:
ii  libqt5multimedia5-plugins   5.14.2-2
ii  python3-pyqt5.qtmultimedia  5.15.0+dfsg-1+b1

Versions of packages picard suggests:
ii  hicolor-icon-theme  0.17-2

-- no debconf information

Bug#968437: xindy-rules: Incorrect Norwegian sorting of č and š

[Norbert Preining]

Hi Bruno,

> From your description, it looks like an issue in xindy, not in GNU clisp
> on which xindy is based in TeX Live.
> 
> Therefore the proper place to report this issue is with the xindy
> developer Joachim Schrod. Probably at https://github.com/jschrod/xindy.ctan .

Indeed, thanks a lot! Sorry for the noise.

Norbert

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

Bug#340947: Xác minh địa chỉ email của bạn

[Nhóm tài khoản Microsoft]

Tài khoản Microsoft

Xác minh địa chỉ email của bạn

Để hoàn thành thiết lập tài khoản Microsoft, chúng tôi chỉ cần đảm 
bảo địa chỉ email này là của bạn.

Để xác minh địa chỉ email của bạn, hãy sử dụng mã bảo mật này: 4601

Nếu không yêu cầu mã này thì bạn có thể bỏ qua email này một cách an toàn. Có 
thể ai đó khác đã nhập địa chỉ email của bạn do nhầm lẫn.

Xin cám ơn,
Nhóm tài khoản Microsoft 

Bug#966400: sublime-music: fails to create new server

[Louis-Philippe Véronneau]

severity 966400 normal
thanks

Hi,

Thanks for reporting this bug.

I'm downgrading the severity, as I'm not able to reproduce the issue on
my machine running sid, although I'm sure it's real.

The pip version working isn't really relevant, as pip doesn't use Debian
dependencies. That and there's been quite a lot of changes on between
0.9.1 and 0.11.1.

I'd be interested in knowing what desktop environment you are using?
Maybe it doesn't crash on my side because I have packages installed that
are required but not listed in the dependencies?

Could you try running the package in debug mode to try to get see if you
get more info?

$ sublime-music -m debug

Anyway, I guess I'm going to have to test this in a clean sid VM to try
to reproduce your crash.

Cheers,

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



signature.asc
Description: OpenPGP digital signature

Bug#968582: RFS: eqonomize/1.5.0-1 -- personal accounting software for the small household economy

[Fabio Augusto De Muzio Tobich]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: eqonomize
   Version : 1.5.0-1
   Upstream Author : Hanna Knutsson 
 * URL : https://eqonomize.github.io/
 * License : GPL-3+, MIT, GFDL-1.2+
 * Vcs : https://salsa.debian.org/debian/eqonomize
   Section : kde

It builds those binary packages:

  eqonomize-doc - documentation for the Eqonomize! accounting software
  eqonomize - personal accounting software for the small household economy

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/e/eqonomize/eqonomize_1.5.0-1.dsc

Changes since the last upload:

 eqonomize (1.5.0-1) unstable; urgency=medium
 .
   * New upstream release.
   * debian/control: rearranged Build-Depends field.
   * debian/copyright:
   - Removed BSD-3-Clause license text.
   - Removed create-man.sh block.
   * debian/eqonomize-doc.install: rearranged.
   * debian/eqonomize.manpages: updated manpage path.
   * debian/manpages/: removed, upstream provide a manpage now.
   * debian/patches/:
   - 020-add-desktop-entry-keywords.patch: removed, incorporated upstream.
   - 030-enable-pt-br-translation.patch: removed, incorporated upstream.
   - 040-update-pt-br-translation.patch: removed, incorporated upstream.
   * debian/source/lintian-overrides: removed, not needed anymore.

Regards,
-- 
⢀⣴⠾⠻⢶⣦⠀ Fabio A. De Muzio Tobich
⣾⠁⢰⠒⠀⣿⡁ 9730 4066 E5AE FAC2 2683
⢿⡄⠘⠷⠚⠋⠀ D03D 4FB3 B4D3 7EF6 3B2E
⠈⠳⣄  GPG:rsa4096/7EF63B2E

Bug#964162: trousers: tcsd segfault crash when dns server is not available

[Bernhard Übelacker]

Hello Novak Frantisek,
I am just trying to reproduce crashes on random packages,
so I tried on this bug report, too. But I was not able
to come anywhere near the crash you are describing.

You might want to add some more information to that report,
about which TPM version you have 'dmesg | grep -i tpm',
and maybe some details how you did integrate trousers+tpmtools
into your initramfs.

You might also be able to retrieve the crash line
and the following code line from dmesg?

Kind regards,
Bernhard

Bug#967487: libubootenv: Cannot build libubootenv with dpkg-buildpackage

[Nobuhiro Iwamatsu]

severity 967487 important
thanks

Hi,

2020年8月17日(月) 17:15 Gylstorff Quirin :

>
>
>
> On 8/12/20 4:29 AM, Nobuhiro Iwamatsu wrote:
> > Hi,
> >
> > Thanks for your report.
> >
> > 2020年8月4日(火) 19:50 Gylstorff Quirin :
> >>
> >> Package: libubootenv-tool
> >> Version: 0.2-1
> >> Severity: serious
> >> Tags: patch ftbfs
> >> Justification: fails to build from source
> >>
> >> Dear Maintainer,
> >>
> >> I tried to  build libubootenv-tool with dpkg-buildpackage and the 
> >> following error
> >> did occur:
> >> ```
> >> -- Detecting C compile features - done
> >> CMake Error at src/CMakeLists.txt:29 (install):
> >>install TARGETS given no RUNTIME DESTINATION for executable target
> >>"fw_printenv".
> >>
> >>
> >> CMake Error at src/CMakeLists.txt:30 (install):
> >>install TARGETS given no RUNTIME DESTINATION for executable target
> >>"fw_setenv".
> >> ```
> >
> > Hmm, I checked this on unstable but didn't reproduce it.
> > I attached a build log.
> > Could you tell me the environment you have confirmed?
> >
>
> Sure, I tried to build it on stable(Debian 10.5) with  cmake version 3.13.4.
>
> Attached is the complete log.

This package is not provided in stable, so the bug severity will not
be set in serious. I change to important.
Could you check this patch in unstable environment as well?
If everything is okay, I will apply.

>
> Kind regards
> Quirin

Best regards,
  Nobuhiro


--
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6

Bug#966610: systemd: autopkgtest-virt-lxc fails in timedated on arm64

[Ryutaroh Matsumoto]

Hi Michael,

Recently, Debian kernel package started to support Raspberry Pi 4B,
which I am using.
On the standard Debian kernel package (in testing),
the autopkgtest failure did not occur.
All tests passed.

I am now wondering which package/distribution I should file a but report to...

Best regards, Ryutaroh

> Can you raise this upstream or do you suspect any Debian specific patch
> causing this issue?


From: Michael Biebl 
Subject: Re: systemd: autopkgtest-virt-lxc fails in timedated on arm64
Date: Mon, 17 Aug 2020 22:07:07 +0200

> On Fri, 31 Jul 2020 21:24:59 +0900 Ryutaroh Matsumoto
>  wrote:
>> Package: systemd
>> Version: 245.7-1
>> Severity: minor
>> 
>> Dear Maintainer,
>> 
>> I ran autopkgtest-virt-lxc on systemd in unstable on arm64
>> (Raspberry Pi 4B). It failed in timedated test as shown below.
>> My configuration is a bit exotic.
>> LXC is 4.0.2 from unstable.
>> Unified Cgourp hierarchy.
>> Kernel is from the Raspberry Pi Foundation (see below).
>> The testbed was built by autopkgtest-build-lxc debian sid
>> (the standard way).
>> 
>> timedated-stderr shows:
>> FAIL: 'boolean false' not found in:
>> signal time=1596194518.252811 sender=org.freedesktop.DBus -> 
>> destination=:1.38 serial=2 path=/org/freedesktop/DBus; 
>> interface=org.freedesktop.DBus; member=NameAcquired
>>string ":1.38"
>> signal time=1596194518.253030 sender=org.freedesktop.DBus -> 
>> destination=:1.38 serial=4 path=/org/freedesktop/DBus; 
>> interface=org.freedesktop.DBus; member=NameLost
>>string ":1.38"
>> 
> 
> 
> Can you raise this upstream or do you suspect any Debian specific patch
> causing this issue?
> 

Bug#911815: /usr/bin/perf_4.18: Please build perf against libbfd

[Steinar H. Gunderson]

On Fri, Oct 26, 2018 at 01:12:51AM +0100, Ben Hutchings wrote:
> For future reference, that's the comment:
> 
> # perf can link against libbfd if available, but the result is
> # undistributable as they are licenced under GPL v2 and v3+
> # respectively.  Override detection of libbfd and insist that
> # cplus_demangle() can be found in libiberty (LGPL v2.1+).
> 
> Tagging this wontfix since we can't fix that problem.

But we can probably make the addr2line solution much faster?
perf runs:

scnprintf(cmd, sizeof(cmd), "addr2line -e %s %016"PRIx64,
  dso_name, addr);

fp = popen(cmd, "r");

but the normal way of running addr2line is to run it and then start feeding
it addresses on stdin (ie. don't start the program anew for each and every
address we want to look up). I haven't tried, but it sounds like that would
reduce overhead significantly?

I also don't know if there's a cache somewhere in front of this? It seems to
look up the same addresses over and over and over again, at least in my case
(decoding a processor trace).

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

Bug#968581: RFS: golang-github-emersion-go-imap-idle-dev/0.0~git20200601.f05f546-1 -- IMAP IDLE extension for Go

[Ben Fiedler]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package 
"golang-github-emersion-go-imap-idle-dev",

found on salsa [1]. There has been an upstream bugfix for a memory leak.

Changelog:

golang-github-emersion-go-imap-idle (0.0~git20200601.f05f546-1) 
unstable; urgency=medium


  * New upstream version

 -- Ben Fiedler   Sat, 15 Aug 2020 23:52:37 
+0200


Regards,
Ben Fiedler

[1]: 
https://salsa.debian.org/go-team/packages/golang-github-emersion-go-imap-idle

Bug#968580: transition: ilmbase/openexr

[Matteo F. Vescovi]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-CC: pkg-phototools-de...@lists.alioth.debian.org, ma...@debian.org

Dear Release Team,

I'm filing this bug for a new transition of ilmbase/openexr packages.

On August 15th, 2020 good-shaped testing-purpose packages (2.5.3-1) for
both ilmbase and openexr have been uploaded to experimental.

So, following a checklist obtained via 'reverse-depends', here is the
list of source packages depending on ilmbase and openexr and the results
of the test builds (honoring the dependency levels as reported in the
checklist, as relevant for the correct order):

### Dependency level 2 ###
 * aqsis_1.8.2-12 => OK
 * calligra_1:3.2.1+dfsg-2 => OK
 * darktable_3.2.1-2 => OK
 * exactimage_1.0.2-7 => FTBFS (possibly OpenEXR-related)
 * field3d_1.7.2-1 => OK
 * freeimage_3.18.0+ds2-5 => OK
 * gegl_0.4.24-1 => OK
 * imagemagick_8:6.9.11.24+dfsg-1 => OK
 * kimageformats_5.70.0-1 => OK
 * kio-extras_4:19.12.3-1 => OK
 * krita_1:4.3.0+dfsg-1 => OK
 * libvigraimpex_1.11.1+dfsg-7 => OK
 * luminance-hdr_2.6.0+dfsg-2 => OK
 * mia_2.4.7-1 => OK
 * nvidia-texture-tools_2.0.8-1+dfsg-8.2 => OK
 * opencv_4.2.0+dfsg-6 => OK
 * openexr-viewers_2.3.0-1 => OK
 * openvdb_7.0.0-3 => FTBFS (not OpenEXR-related)
 * pink-pony_1.4.1-2.1 => OK
 * povray_1:3.7.0.8-4 => OK
 * slic3r-prusa_2.2.0+dfsg1-2 => OK

### Dependency level 3 ###
 * gimp_2.10.18-1 => OK
 * gst-plugins-bad1.0_1.16.2-2.3 => OK
 * hugin_2019.2.0+dfsg-2 => OK
 * k3d_0.8.0.6-8 => FTBFS (missing B-D)
 * openimageio_2.1.18.1~dfsg0-1 => OK
 * pfstools_2.1.0-5 => FTBFS (not OpenEXR-related)
 * synfig_1.2.2+dfsg-3 => OK

### Dependency level 4 ###
 * blender_2.83.4+dfsg-1 => OK
 * gmic_2.4.5-1.1 => OK
 * olive-editor_20200528-1 => OK

I'll follow-up this bug report with any progress in fixing the packages
that are FTBFS.

Thanks for your time and patience.

mfv


Ben file:

title = "ilmbase";
is_affected = .depends ~ "libilmbase24" | .depends ~ "libilmbase25";
is_good = .depends ~ "libilmbase25";
is_bad = .depends ~ "libilmbase24";

title = "openexr";
is_affected = .depends ~ "libopenexr24" | .depends ~ "libopenexr25";
is_good = .depends ~ "libopenexr25";
is_bad = .depends ~ "libopenexr24";


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

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

-- 
Matteo F. Vescovi || Debian Developer
GnuPG KeyID: 4096R/0x8062398983B2CF7A


signature.asc
Description: PGP signature

Bug#968579: RFS: golang-github-emersion-go-pgpmail-dev/0.0~git20200817.b51138e-1 [ITP] -- PGP library in Go

[Ben Fiedler]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package 
"golang-github-emersion-go-pgpmail-dev",

found on salsa [1]. It depends on an update of go-message [3], for which
I will submit another RFS.

It is a required dependency of aerc 0.4.0 [2].

This is a new package:

golang-github-emersion-go-pgpmail (0.0~git20200817.b51138e-1) unstable; 
urgency=medium


  * Initial release (Closes: #958409)

 -- Ben Fiedler   Mon, 17 Aug 2020 22:02:32 
+0200


Regards,
Ben Fiedler

[1]: https://salsa.debian.org/bfiedler/golang-github-emersion-go-pgpmail
[2]: https://aerc-mail.org
[3]: 
https://salsa.debian.org/go-team/packages/golang-github-emersion-go-message/-/merge_requests/2

Bug#968577: python-django DEP-8 test failure

[Lucas Kanashiro]

Source: python-django
Version: 2:2.2.15-1
Severity: normal

Dear Maintainer,

The DEP-8 tests have been failing for a while:

https://ci.debian.net/packages/p/python-django/

At the moment this is the failure:

==
ERROR: test_i18n_app_dirs (i18n.tests.WatchForTranslationChangesTests)
--
Traceback (most recent call last):
  File "/tmp/autopkgtest.XjvsW0/autopkgtest_tmp/tests/i18n/tests.py",
line 1884, in test_i18n_app_dirs
    with self.settings(INSTALLED_APPS=['tests.i18n.sampleproject']):
  File "/usr/lib/python3/dist-packages/django/test/utils.py", line 338,
in __enter__
    return self.enable()
  File "/usr/lib/python3/dist-packages/django/test/utils.py", line 402,
in enable
    apps.set_installed_apps(self.options['INSTALLED_APPS'])
  File "/usr/lib/python3/dist-packages/django/apps/registry.py", line
353, in set_installed_apps
    self.populate(installed)
  File "/usr/lib/python3/dist-packages/django/apps/registry.py", line
91, in populate
    app_config = AppConfig.create(entry)
  File "/usr/lib/python3/dist-packages/django/apps/config.py", line 116,
in create
    mod = import_module(mod_path)
  File "/usr/lib/python3.8/importlib/__init__.py", line 127, in
import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "", line 1014, in _gcd_import
  File "", line 991, in _find_and_load
  File "", line 961, in _find_and_load_unlocked
  File "", line 219, in
_call_with_frames_removed
  File "", line 1014, in _gcd_import
  File "", line 991, in _find_and_load
  File "", line 973, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'tests'

-- 
Lucas Kanashiro

Bug#968575: RFS: golang-github-emersion-go-imap-dev/1.0.5-1 -- IMAP library for Go

[Ben Fiedler]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package 
"golang-github-emersion-go-imap-dev",

found on salsa [1]. There has been an upstream bugfix for a memory leak.

Changelog:

golang-github-emersion-go-imap (1.0.5-1) unstable; urgency=medium

  * New upstream version

 -- Ben Fiedler   Sat, 15 Aug 2020 21:50:29 
+0200


Regards,
Ben Fiedler

[1]: 
https://salsa.debian.org/go-team/packages/golang-github-emersion-go-imap

Bug#968576: RFS: golang-github-emersion-go-message-dev/0.12.0-1 -- dependency of aerc 0.4.0

[Ben Fiedler]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package 
"golang-github-emersion-go-message-dev",
found on salsa [1]. I've submitted a merge request [2], and would like 
to request

Maintainer access to the salsa repo as well (for future updates).

This package is a required dependency of aerc 0.4.0 [3].

Changelog:

golang-github-emersion-go-message (0.12.0-1) unstable; urgency=medium

  * New upstream version

 -- Ben Fiedler   Sat, 15 Aug 2020 21:32:15 
+0200



Regards,
Ben Fiedler

[1]: 
https://salsa.debian.org/go-team/packages/golang-github-emersion-go-message
[2]: 
https://salsa.debian.org/go-team/packages/golang-github-emersion-go-message/-/merge_requests/2

[3]: https://aerc-mail.org

Bug#968235: texlive-base: missing file /usr/share/doc/texlive-base/README.tlmgr-on-Debian.md

[Hilmar Preuße]

Control: tags -1 + pending

On 8/11/20 2:59 PM, Norbert Preining wrote:

>> but the file /usr/share/doc/texlive-base/README.tlmgr-on-Debian.md
>> is missing.
> 
> Indeed indeed, fix in git, will be in the next upload.
> 
Tag pending.

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



signature.asc
Description: OpenPGP digital signature

Bug#968574: ffmpeg: Please backport upstream patch to fix build on powerpc and ppc64

[John Paul Adrian Glaubitz]

Source: ffmpeg
Version: 7:4.3.1-2
Severity: important
Tags: patch
User: debian-powe...@lists.debian.org
Usertags: powerpc ppc64
X-Debbugs-Cc: debian-powe...@lists.debian.org

Hello!

ffmpeg currently FTBFS on powerpc and ppc64 [1]:

src/libswscale/ppc/yuv2rgb_altivec.c: In function ‘altivec_yuv2_abgr’:
src/libswscale/ppc/yuv2rgb_altivec.c:338:18: error: implicit declaration of 
function ‘vec_xl’; did you mean ‘vec_rl’? 
[-Werror=implicit-function-declaration]
  338 | y0 = vec_xl(0, y1i);
  \
  |  ^~
src/libswscale/ppc/yuv2rgb_altivec.c:437:1: note: in expansion of macro 
‘DEFCSP420_CVT’
  437 | DEFCSP420_CVT(yuv2_abgr,  out_abgr)
  | ^
gcc -I. -Isrc/ -Wdate-time -D_FORTIFY_SOURCE=2 -U_FORTIFY_SOURCE 
-D_FORTIFY_SOURCE=2 -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE 
-D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DPIC -DZLIB_CONST 
-DHAVE_AV_CONFIG_H -DBUILDING_swscale -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -fno-strict-overflow -fstack-protector-all -fPIE   
-std=c11 -fomit-frame-pointer -fPIC -maltivec -mabi=altivec -pthread  
-I/usr/include/p11-kit-1  -I/usr/include/lilv-0 -I/usr/include/sratom-0 
-I/usr/include/sord-0 -I/usr/include/serd-0 -I/usr/include/harfbuzz 
-I/usr/include/glib-2.0 -I/usr/lib/powerpc64-linux-gnu/glib-2.0/include 
-I/usr/include/uuid -I/usr/include/fribidi -I/usr/include/freetype2 
-I/usr/include/libpng16 -I/usr/include/libxml2 -I/usr/include/uuid 
-I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/bs2b
-I/usr/include/libdrm -I/usr/include/uuid -I/usr/include/freetype2 
-I/usr/include/libpng16 -I/usr/include/freetype2 -I/usr/include/libpng16 
-I/usr/include/fribidi  -I/usr/include/openjpeg-2.3  -I/usr/include/opus 
-I/usr/include/opus -D_REENTRANT  -pthread -I/usr/include/librsvg-2.0 
-I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libmount -I/usr/include/blkid 
-I/usr/include/cairo -I/usr/include/glib-2.0 
-I/usr/lib/powerpc64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 
-I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/libpng16 
-I/usr/include/srt -I/usr/include/p11-kit-1   -isystem 
/usr/include/mit-krb5 -I/usr/include/pgm-5.2  -I/usr/include/libxml2
-g -Wdeclaration-after-statement -Wall -Wdisabled-optimization -Wpointer-arith 
-Wredundant-decls -Wwrite-strings -Wtype-limits -Wundef -Wmissing-prototypes 
-Wno-pointer-to-int-cast -Wstrict-prototypes -Wempty-body -Wno-parentheses 
-Wno-switch -Wno-format-zero-length -Wno-pointer-sign 
-Wno-unused-const-variable -Wno-bool-operation -Wno-char-subscripts -O3 
-fno-math-errno -fno-signed-zeros -fno-tree-vectorize -Werror=format-security 
-Werror=implicit-function-declaration -Werror=missing-prototypes 
-Werror=return-type -Werror=vla -Wformat -fdiagnostics-color=auto 
-Wno-maybe-uninitialized -D_REENTRANT -I/usr/include/SDL2  -MMD -MF 
libswscale/swscale_unscaled.d -MT libswscale/swscale_unscaled.o -c -o 
libswscale/swscale_unscaled.o src/libswscale/swscale_unscaled.c
src/libswscale/ppc/yuv2rgb_altivec.c:338:18: error: incompatible types when 
assigning to type ‘__vector unsigned char’ {aka ‘__vector(16) unsigned char’} 
from type ‘int’
  338 | y0 = vec_xl(0, y1i);
  \
  |  ^~
src/libswscale/ppc/yuv2rgb_altivec.c:437:1: note: in expansion of macro 
‘DEFCSP420_CVT’
  437 | DEFCSP420_CVT(yuv2_abgr,  out_abgr)
  | ^
src/libswscale/ppc/yuv2rgb_altivec.c:340:18: error: incompatible types when 
assigning to type ‘__vector unsigned char’ {aka ‘__vector(16) unsigned char’} 
from type ‘int’
  340 | y1 = vec_xl(0, y2i);
  \
  |  ^~
src/libswscale/ppc/yuv2rgb_altivec.c:437:1: note: in expansion of macro 
‘DEFCSP420_CVT’
  437 | DEFCSP420_CVT(yuv2_abgr,  out_abgr)
  | ^
src/libswscale/ppc/yuv2rgb_altivec.c:437:1: error: cannot convert a value of 
type ‘int’ to vector type ‘__vector(16) signed char’ which has different size
src/libswscale/ppc/yuv2rgb_altivec.c:437:1: error: cannot convert a value of 
type ‘int’ to vector type ‘__vector(16) signed char’ which has different size
src/libswscale/ppc/yuv2rgb_altivec.c: In function ‘altivec_yuv2_bgra’:
src/libswscale/ppc/yuv2rgb_altivec.c:338:18: error: incompatible types when 
assigning to type ‘__vector unsigned char’ {aka ‘__vector(16) unsigned char’} 
from type ‘int’
  338 | y0 = vec_xl(0, y1i);
  \
  |  ^~
src/libswscale/ppc/yuv2rgb_altivec.c:438:1: note: in expansion of macro 
‘DEFCSP420_CVT’
  438 | DEFCSP420_CVT(yuv2_bgra,  out_bgra)
  | ^
src/libswscale/ppc/yuv2rgb_altivec.c:340:18: error: incompatible types when 
assigning to type ‘__vector unsigned char’ {aka ‘__vector(16) unsigned char’} 
from 

Bug#968485: vagrant-libvirt: Please re-introduce the create_box.sh example script

[Antonio Terceiro]

Hi,

On Sun, Aug 16, 2020 at 09:35:11AM +0200, intrig...@debian.org wrote:
> Package: vagrant-libvirt
> Version: 0.1.2-1
> Severity: wishlist
> Tags: patch
> User: tails-...@boum.org
> Usertags: build-system
> 
> Hi,
> 
> a few years back, in #823317 we added the create_box.sh example script
> to the Debian package: the Tails build system needs it.
> 
> But 0.1.2-1 stopped including this script¹, presumably because the
> upstream tarball does not include that script anymore, which I believe
> is in turn caused by a change Hans-Christoph did upstream².
> 
> How about we do this:
> 
> 1. Bring back create_box.sh into the upstream tarball.
>I suppose the untested attached patch, generated against current
>upstream master branch, could suffice.
> 
> 2. Bring back create_box.sh into the Debian package.
>I suppose it boils down to reverting 
> e767deba89c8cabb26c2706e1d4f0b6475fd1070.
> 
> ?
> 
> [1] 
> https://salsa.debian.org/ruby-team/vagrant-libvirt/-/commit/e767deba89c8cabb26c2706e1d4f0b6475fd1070
> [2] 
> https://github.com/vagrant-libvirt/vagrant-libvirt/commit/2ca5603ad2e4e7cd90951d2064226de7eec1214b

That script was shipped as an example in /usr/share/docs/, and that is
not a published interface.

We can even re-introduce it at some point, but IMO if you want to rely
on it for any kind of automation, you should copy it into your own
system.


signature.asc
Description: PGP signature

Bug#964609: pyxdg: Proposed solution for pyxdg test failure and ftbfs

[Matthieu Clemenceau]

Package: pyxdg
Version: 0.26-3
Followup-For: Bug #964609
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu groovy ubuntu-patch

Dear Maintainer,

While reviewing GCC10 FTBFS with ubuntu 20.10 Groovy, I worked on pyxdg failure.
After reproducing the failure in a sbuild environment I noticed that this wasn't
a ftbfs issue but more likely an issue introduced with python 3.8.4

In Python 3.8.4 rc1, Custom AST constant naming became more strict and raised 
ValueError when True, False and Node are used within a ast.Name node [1]

After some research I found a similar issue reported here [2] and inspired from
it to write a solution for pyxdg

This patch has been submitted for groovy and is in proposed. This test failure
was also blocking nose to migrate from proposed which shoudl now be able to 
migrate to groovy devel

  * Fix compatibility issue with python 3.8.4 (Closes: #964609, #968399)

Thanks for considering the patch.

Matthieu

[1] https://bugs.python.org/issue40870
[2] https://github.com/nestorsalceda/mamba/pull/151

-- System Information:
Debian Release: bullseye/sid
  APT prefers focal-updates
  APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), 
(100, 'focal-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-42-generic (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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru pyxdg-0.26/debian/patches/python384compat.diff 
pyxdg-0.26/debian/patches/python384compat.diff
--- pyxdg-0.26/debian/patches/python384compat.diff  1969-12-31 
18:00:00.0 -0600
+++ pyxdg-0.26/debian/patches/python384compat.diff  2020-08-12 
17:41:44.0 -0500
@@ -0,0 +1,57 @@
+Description: Fix Pytyhon 3.8.4 compatibility Issue
+ Starting with Python 3.8.4 rc1, Custom AST constant naming became more strict 
+ and raised ValueError when True, False and Noe are used within a ast.Name 
node 
+ Solution inspired from https://github.com/nestorsalceda/mamba/pull/151 
+Author: Matthieu Clemenceau 
+Origin: vendor
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964609
+Last-Update: 2020-08-17
+
+--- pyxdg-0.26.orig/xdg/Menu.py
 pyxdg-0.26/xdg/Menu.py
+@@ -21,6 +21,8 @@ import os
+ import locale
+ import subprocess
+ import ast
++import sys
++
+ try:
+ import xml.etree.cElementTree as etree
+ except ImportError:
+@@ -34,6 +36,17 @@ from xdg.util import PY3
+ import xdg.Locale
+ import xdg.Config
+ 
++def _ast_const(name):
++# fixes compat issue with python 3.8.4+
++# c.f https://github.com/pytest-dev/pytest/issues/7322
++if sys.version_info >= (3, 4):
++name = ast.literal_eval(name)
++if sys.version_info >= (3, 8):
++return ast.Constant(name)
++else:
++return ast.NameConstant(name)
++else:
++return ast.Name(id=name, ctx=ast.Load())
+ 
+ def _strxfrm(s):
+ """Wrapper around locale.strxfrm that accepts unicode strings on Python 2.
+@@ -763,7 +776,8 @@ class XMLMenuBuilder(object):
+ if expr:
+ tree.body = expr
+ else:
+-tree.body = ast.Name('False', ast.Load())
++#tree.body = ast.Name('False', ast.Load())
++tree.body = _ast_const('False')
+ ast.fix_missing_locations(tree)
+ return Rule(type, tree)
+ 
+@@ -790,7 +804,7 @@ class XMLMenuBuilder(object):
+ expr = self.parse_bool_op(node, ast.Or())
+ return ast.UnaryOp(ast.Not(), expr) if expr else None
+ elif tag == 'All':
+-return ast.Name('True', ast.Load())
++return _ast_const('True')
+ elif tag == 'Category':
+ category = node.text
+ return ast.Compare(
diff -Nru pyxdg-0.26/debian/patches/series pyxdg-0.26/debian/patches/series
--- pyxdg-0.26/debian/patches/series2020-03-27 09:30:55.0 -0500
+++ pyxdg-0.26/debian/patches/series2020-08-12 17:41:44.0 -0500
@@ -2,3 +2,4 @@
 set-default-menu.patch
 gettext-support.patch
 test_mime_skip_symlink.patch
+python384compat.diff

Bug#340947:

[Phuong Phạm]

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=340947

Bug#968573: wham-align: autopkgtest arm64 failure: times out after ./sequences:,chr1_100k.fa,Test 1

[Paul Gevers]

Source: wham-align
Version: 0.1.5-3.1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: fails-always timesout

Dear maintainer(s),

Your package wham-align has an autopkgtest, great. However, it fails on
arm64 because it times out. I copied some of the output at the bottom of
this report.

Paul

https://ci.debian.net/data/autopkgtest/testing/arm64/w/wham-align/6682709/log.gz

autopkgtest [11:12:08]: test run-unit-test: [---
.:
reads
ref
sequences

./reads:
sample.fq
sample_pair_1.fq
sample_pair_2.fq

./ref:
README.test_data
output1
output2
output3
output4
output5
output6
output7

./sequences:
chr1_100k.fa
Test 1
autopkgtest [13:58:48]: ERROR: timed out on command "su -s /bin/bash
debci -c set -e; export USER=`id -nu`; . /etc/profile >/dev/null 2>&1 ||
true;  . ~/.profile >/dev/null 2>&1 || true;
buildtree="/tmp/autopkgtest-lxc.n87033z5/downtmp/build.wq5/src"; mkdir
-p -m 1777 --
"/tmp/autopkgtest-lxc.n87033z5/downtmp/run-unit-test-artifacts"; export
AUTOPKGTEST_ARTIFACTS="/tmp/autopkgtest-lxc.n87033z5/downtmp/run-unit-test-artifacts";
export ADT_ARTIFACTS="$AUTOPKGTEST_ARTIFACTS"; mkdir -p -m 755
"/tmp/autopkgtest-lxc.n87033z5/downtmp/autopkgtest_tmp"; export
AUTOPKGTEST_TMP="/tmp/autopkgtest-lxc.n87033z5/downtmp/autopkgtest_tmp";
export ADTTMP="$AUTOPKGTEST_TMP"; export DEBIAN_FRONTEND=noninteractive;
export LANG=C.UTF-8; export DEB_BUILD_OPTIONS=parallel=4; unset LANGUAGE
LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE   LC_MONETARY LC_MESSAGES
LC_PAPER LC_NAME LC_ADDRESS   LC_TELEPHONE LC_MEASUREMENT
LC_IDENTIFICATION LC_ALL;rm -f /tmp/autopkgtest_script_pid; set -C; echo
$$ > /tmp/autopkgtest_script_pid; set +C; trap "rm -f
/tmp/autopkgtest_script_pid" EXIT INT QUIT PIPE; cd "$buildtree"; chmod
+x
/tmp/autopkgtest-lxc.n87033z5/downtmp/build.wq5/src/debian/tests/run-unit-test;
touch /tmp/autopkgtest-lxc.n87033z5/downtmp/run-unit-test-stdout
/tmp/autopkgtest-lxc.n87033z5/downtmp/run-unit-test-stderr;
/tmp/autopkgtest-lxc.n87033z5/downtmp/build.wq5/src/debian/tests/run-unit-test
2> >(tee -a /tmp/autopkgtest-lxc.n87033z5/downtmp/run-unit-test-stderr
>&2) > >(tee -a
/tmp/autopkgtest-lxc.n87033z5/downtmp/run-unit-test-stdout);" (kind: test)
autopkgtest [13:58:48]: test run-unit-test: ---]



signature.asc
Description: OpenPGP digital signature

Bug#966610: systemd: autopkgtest-virt-lxc fails in timedated on arm64

[Michael Biebl]

On Fri, 31 Jul 2020 21:24:59 +0900 Ryutaroh Matsumoto
 wrote:
> Package: systemd
> Version: 245.7-1
> Severity: minor
> 
> Dear Maintainer,
> 
> I ran autopkgtest-virt-lxc on systemd in unstable on arm64
> (Raspberry Pi 4B). It failed in timedated test as shown below.
> My configuration is a bit exotic.
> LXC is 4.0.2 from unstable.
> Unified Cgourp hierarchy.
> Kernel is from the Raspberry Pi Foundation (see below).
> The testbed was built by autopkgtest-build-lxc debian sid
> (the standard way).
> 
> timedated-stderr shows:
> FAIL: 'boolean false' not found in:
> signal time=1596194518.252811 sender=org.freedesktop.DBus -> 
> destination=:1.38 serial=2 path=/org/freedesktop/DBus; 
> interface=org.freedesktop.DBus; member=NameAcquired
>string ":1.38"
> signal time=1596194518.253030 sender=org.freedesktop.DBus -> 
> destination=:1.38 serial=4 path=/org/freedesktop/DBus; 
> interface=org.freedesktop.DBus; member=NameLost
>string ":1.38"
> 


Can you raise this upstream or do you suspect any Debian specific patch
causing this issue?



signature.asc
Description: OpenPGP digital signature

Bug#968087: systemd-tmpfiles fails on fchownat() systcall for /var/log/journal with -ENOENT on installation

[Michael Biebl]

Am 08.08.20 um 12:48 schrieb Vasyl Gello:
> Package: systemd
> Version: 246-2
> 
> Dear colleagues,
> 
> I am observing strange issue with installation / upgrade of systemd in
> pbuilder chroot. The environment I do use is somewhat not standard
> (it is an nsjail chroot for portable Debian development with pbuilder
> nested chroot working inside the user namespace) but all versions of
> systemd before 245-1 were installed just fine.

Maybe you can run git bisect to find the commit which changed the behaviour?

> As an author and maintainer of the aforementioned tool, I tracked
> down the issue to the following command:
> 
> systemd-tmpfiles --create --prefix /var/log/journal
> 
> in the systemd.postinst script. Appending this particular line
> as follows:
> 
> systemd-tmpfiles --create --prefix /var/log/journal || true
> 
> solves the issue for me.
> 

Well, this is just hiding the error.



signature.asc
Description: OpenPGP digital signature

Bug#943866: kdenlive: Crash when add an audio clip to the session

[Phil Morrell]

Control: fixed -1 20.04.3-1
Control: tags -1 + moreinfo
thanks

I could not reproduce this crash in current testing, please can you
provide an example file and steps if this is still happening or I've not
tested it correctly:

1. https://file-examples-com.github.io/uploads/2017/11/file_example_WAV_1MG.wav
2. Project -> Add Clip or Folder -> file_example_WAV_1MG.wav -> OK
3.  Bin -> wav has thumbnail and no crash



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

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

Versions of packages kdenlive depends on:
ii  ffmpeg 7:4.3.1-1
ii  gstreamer1.0-plugins-bad   1.16.2-2.3
ii  kded5  5.70.0-1
ii  kdenlive-data  20.04.3-1
ii  kinit  5.70.0-1
ii  kio5.70.1-1
ii  libc6  2.31-3
ii  libkf5archive5 5.70.0-1
ii  libkf5bookmarks5   5.70.0-1
ii  libkf5completion5  5.70.0-1
ii  libkf5configcore5  5.70.0-1
ii  libkf5configgui5   5.70.0-1
ii  libkf5configwidgets5   5.70.0-2
ii  libkf5coreaddons5  5.70.0-2
ii  libkf5crash5   5.70.0-1
ii  libkf5dbusaddons5  5.70.0-1
ii  libkf5declarative5 5.70.0-1
ii  libkf5filemetadata35.70.0-1
ii  libkf5guiaddons5   5.70.0-2
ii  libkf5i18n55.70.0-1
ii  libkf5iconthemes5  5.70.0-1
ii  libkf5itemviews5   5.70.0-1
ii  libkf5jobwidgets5  5.70.0-1
ii  libkf5kiocore5 5.70.1-1
ii  libkf5kiofilewidgets5  5.70.1-1
ii  libkf5kiowidgets5  5.70.1-1
ii  libkf5newstuff55.70.0-1
ii  libkf5notifications5   5.70.0-1
ii  libkf5notifyconfig55.70.0-1
ii  libkf5purpose-bin  5.70.0-1
ii  libkf5purpose5 5.70.0-1
ii  libkf5service-bin  5.70.0-1
ii  libkf5service5 5.70.0-1
ii  libkf5solid5   5.70.0-1
ii  libkf5widgetsaddons5   5.70.0-1
ii  libkf5xmlgui5  5.70.0-1+b1
ii  libmlt++3  6.22.1-2
ii  libmlt66.22.1-2
ii  libqt5concurrent5  5.14.2+dfsg-5
ii  libqt5core5a   5.14.2+dfsg-5
ii  libqt5dbus55.14.2+dfsg-5
ii  libqt5gui5 5.14.2+dfsg-5
ii  libqt5multimedia5  5.14.2-2
ii  libqt5network5 5.14.2+dfsg-5
ii  libqt5qml5 5.14.2+dfsg-3
ii  libqt5quick5   5.14.2+dfsg-3
ii  libqt5quickcontrols2-5 5.14.2+dfsg-2
ii  libqt5quickwidgets55.14.2+dfsg-3
ii  libqt5svg5 5.14.2-2
ii  libqt5webkit5  5.212.0~alpha4-5
ii  libqt5widgets5 5.14.2+dfsg-5
ii  libqt5xml5 5.14.2+dfsg-5
ii  librttr-core0.9.6  0.9.6+dfsg1-3
ii  libstdc++6 10.2.0-5
ii  melt   6.22.1-2
ii  qml-module-qtgraphicaleffects  5.14.2-2
ii  qml-module-qtqml-models2   5.14.2+dfsg-3
ii  qml-module-qtquick-controls5.14.2-2
ii  qml-module-qtquick-controls2   5.14.2+dfsg-2
ii  qml-module-qtquick-dialogs 5.14.2-2
ii  qml-module-qtquick-layouts 5.14.2+dfsg-3
ii  qml-module-qtquick-window2 5.14.2+dfsg-3
ii  qml-module-qtquick25.14.2+dfsg-3

Versions of packages kdenlive recommends:
ii  breeze-icon-theme  4:5.70.0-1
ii  dvdauthor  0.7.2-1+b3
ii  dvgrab 3.5+git20160707.1.e46042e-1+b1
ii  frei0r-plugins 1.7.0-1
ii  genisoimage9:1.1.11-3.1
ii  oxygen-icon-theme  5:5.70.0-1
ii  recordmydesktop0.3.8.1+svn602-1.1
ii  swh-plugins0.4.17-2

Versions of packages kdenlive suggests:
pn  khelpcenter  

-- no debconf information


signature.asc
Description: PGP signature

Bug#968015: resolvconf-pull-resolved.service fails with systemd 246-2

[Michael Biebl]

Am 17.08.20 um 10:41 schrieb Michael Biebl:

> I've attached a prospective patch.
> 
> Dan, Dimitri, would welcome your feedback here, since most of the
> resolvconf/resolved integration is seemingly coming from you.

Btw, I'll add a versioned Breaks: resolvconf (<< 1.83) to systemd,
assuming the next resolvconf upload will have a fix for this issue




signature.asc
Description: OpenPGP digital signature

Bug#170850: Hello

[Sophia]

Hello Dear,

How are you doing.
i am Sophia by name, i will be more glad if we get to know each other more 
better, thank you.

Bug#968437: xindy-rules: Incorrect Norwegian sorting of č and š

[Bruno Haible]

Hi Norbert,

>From your description, it looks like an issue in xindy, not in GNU clisp
on which xindy is based in TeX Live.

Therefore the proper place to report this issue is with the xindy
developer Joachim Schrod. Probably at https://github.com/jschrod/xindy.ctan .

Bruno

Bug#968572: find: ‘/usr/lib/python2.7’: No such file or directory

[積丹尼 Dan Jacobson]

Package: libpython2.7-minimal
Version: 2.7.18-1
Severity: minor

Seen upon purge:
find: ‘/usr/lib/python2.7’: No such file or directory

The following packages will be REMOVED:
  gcc-9-base{p}  getmail{a} (D: python:any)  libpython-stdlib{ap} (D: 
libpython2-stdlib, D: libpython2.7-stdlib)  libpython2-stdlib{p}  
libpython2.7-minimal{p}  libpython2.7-stdlib{p}
  postnews{a} (D: python)  python{a} (P: python-minimal, D: libpython-stdlib, 
D: python2, D: python2.7)  python-minimal{a} (D: python2-minimal, D: 
python2.7-minimal, R: python)  python2{p}
  python2-minimal{p}  python2.7{p}  python2.7-minimal{p}  resolvconf{p}
0 packages upgraded, 0 newly installed, 14 to remove and 0 not upgraded.
Need to get 0 B of archives. After unpacking 17.8 MB will be freed.
Do you want to continue? [Y/n/?]
(Reading database ... 131244 files and directories currently installed.)
Removing gcc-9-base:amd64 (9.3.0-16) ...
Removing getmail (5.13-1) ...
Removing postnews (0.7-1) ...
Removing python (2.7.17-2) ...
Removing libpython-stdlib:amd64 (2.7.17-2) ...
Removing python2 (2.7.17-2) ...
Removing libpython2-stdlib:amd64 (2.7.17-2) ...
Removing python2.7 (2.7.18-1) ...
Removing libpython2.7-stdlib:amd64 (2.7.18-1) ...
Removing python-minimal (2.7.17-2) ...
Removing python2-minimal (2.7.17-2) ...
Removing python2.7-minimal (2.7.18-1) ...
Unlinking and removing bytecode for runtime python2.7
Removing libpython2.7-minimal:amd64 (2.7.18-1) ...
find: ‘/usr/lib/python2.7’: No such file or directory
Removing resolvconf (1.82) ...
resolvconf.postrm: Reboot recommended
Processing triggers for doc-base (0.10.9) ...
Processing 1 removed doc-base file...
Processing triggers for man-db (2.9.3-2) ...
Processing triggers for mime-support (3.64) ...
(Reading database ... 130365 files and directories currently installed.)
Purging configuration files for resolvconf (1.82) ...
Purging configuration files for libpython2.7-minimal:amd64 (2.7.18-1) ...
Purging configuration files for python2.7-minimal (2.7.18-1) ...

Bug#968571: apt: print-uri and apt-helper documentation enhancements

[Johannes 'josch' Schauer]

Package: apt
Version: 2.1.10
Severity: wishlist

Hi,

some possible improvements to documentation as mentioned on IRC.

1. add more information to the --help output of apt-helper:

a) multiple things can be downloaded in the same call

17:05 < juliank> download-file [ uri target-path  [hash...] ]...

b) Checksum-FileSize: or SHA256: can be added at the end

c) target is the output filename and not a directory

2. make it clear that nothing will be printed with --print-uris in case
   the file that is to be downloaded already exists. Currently the docs
   say "Instead of fetching the files to install their URIs are
   printed". Independent of whether the resulting files already exists,
   they will not get downloaded and thus my expectation from reading
   this sentence is, that nothing gets downloaded with --print-uris
   anyways, then their URIs are *always* printed. With the current
   behavior the only reliable way to retrieve filenames is to execute
   "apt-get download --print-uris" in a new and empty directory. Since
   this is the *only* reliable way, maybe that information should also
   be documented.

Thanks!

cheers, josch

Bug#968502: buster-pu: arch-test needs to be updated in stable to include s390x fix

[Adam D. Barratt]

Control: retitle -1 buster-pu: package arch-test/0.15-2
Control: tags -1 + confirmed

On Sun, 2020-08-16 at 15:43 +0200, Adam Borowski wrote:

+arch-test (0.15-2+deb10u1) buster; urgency=medium
+
+  * Fix s390x detection sometimes failing (Alexander Efremkin).

Please go ahead.

Regards,

Adam

Bug#968570: ITP: ruby-wait-for-it -- Stop sleeping in your tests, instead wait for it

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 
Control: block 968566 by -1

* Package name : ruby-wait-for-it
Version : 0.1.1
Upstream Author : schneems
* URL : https://github.com/zombocom/wait_for_it
* License : Expat
Programming Lang: Ruby
Description : Stop sleeping in your tests, instead wait for it...
Make your complicated integration tests more deterministic with wait 
for it.

.
It spawns processes and waits for them so you can integration test 
really
complicated things with determinism. It allows testing long running 
processes
such as webservers, or features that require concurrency or libraries 
that use

global configuration.
.
Don't add `sleep` to your tests, instead read a log file or stdout and 
match

specific strings.

Bug#968569: cryptsetup-suspend: Set OOMScoreAdjust to -1000 to disable OOM killing for the modified systemd-suspend service

[ಚಿರಾಗ್ ನಟರಾಜ್]

Package: cryptsetup-suspend
Version: 2:2.3.3-3+exp1
Severity: wishlist
X-Debbugs-Cc: debb...@chiraag.me

Dear Maintainer,

The OOMScoreAdjust for the modified systemd-suspend.service is -999. The 
minimum possible is -1000, which should competely disable the OOM Killer. Is 
there a reason -1000 wasn't chosen?

-- Package-specific info:

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

Kernel: Linux 5.7.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=kn_IN.UTF-8, LC_CTYPE=kn_IN.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 cryptsetup-suspend depends on:
ii  cryptsetup-initramfs  2:2.3.3-3+exp1
ii  libc6 2.31-3
ii  libcryptsetup12   2:2.3.3-3+exp1
ii  systemd   246.1-1

cryptsetup-suspend recommends no packages.

cryptsetup-suspend suggests no packages.

-- no debconf information

Bug#968528: multipath-tools: probably shouldn't use install -s

[Chris Hofstaedtler]

Hi Simon,

* Simon McVittie  [200817 00:39]:
> d/rules in multipath-tools sets INSTALL_PROGRAM to 'install -s'. However,
> invoking 'install -s' is usually only harmful for a Debian package,
> not helpful: it discards debugging symbols that could otherwise
> have gone into a -dbgsym package, and when cross-compiling it uses
> the wrong strip(1) implementation (from the build rather than host
> architecture). Unconditionally using INSTALL_PROGRAM = install would
> likely be better.

Right. I'll see about changing this.

Thanks for your effort & bug report!

Chris

Bug#968568: ipp-usb: Should depend on avahi-daemon

[Brian Potkin]

Package: ipp-usb
Version: 0.9.10-2
Severity: normal



An installation of ipp-usb is crippled when the device is not discoverable
on the the loopback interface. avahi-daemon is needed to expose it on any
interface.

I also wonder whether ipp-usb.service should have

  Wants=avahi-daemon.service

replaced by

  Requires=avahi-daemon.service

There is a precedent in #82745.

Regards,

Brian.

Bug#968548: buster-pu: package s390-tools/2.3.0-2~deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed d-i

On Mon, 2020-08-17 at 10:16 +0200, Philipp Kern wrote:
> debootstrap fails to install Debian buster on s390x because of a
> multi-arch "perl:any" dependency it fails to parse (bug #960265).
> This update to s390-tools hardcodes the dependency on "perl" without
> that, which should make the installation possible again. I already
> validated that this fixed the issue on unstable and I could
> successfully install it using debian-installer.

That looks OK to me, thanks, but will need a kibi-ack due to the udeb.

> My assumption is that this is not fixable through -updates but
> requires a point release to be properly fixed.

I would assume so, yes.

Regards,

Adam

Bug#961444: marked as done (grcompiler FTBFS on architectures where char is unsigned)

[Bobby de Vos]

Greetings,

Is there a reason that the second commit [1] to handle this bug is not
included in the patches? If it is, and I missed it, please point me to
the patch.

[1]
https://github.com/silnrsi/grcompiler/commit/a02b9a8fbac211051472815b52ae3600a197b7ca

On 2020-08-16 4:06 a.m., Debian Bug Tracking System wrote:
> Your message dated Sun, 16 Aug 2020 10:03:29 +
> with message-id 
> and subject line Bug#961444: fixed in grcompiler 5.2-2
> has caused the Debian Bug report #961444,
> regarding grcompiler FTBFS on architectures where char is unsigned
> to be marked as done.
> 
> This means that you claim that the problem has been dealt with.
> If this is not the case it is now your responsibility to reopen the
> Bug report if necessary, and/or fix the problem forthwith.
> 
> (NB: If you are a system administrator and have no idea what this
> message is talking about, this may indicate a serious mail system
> misconfiguration somewhere. Please contact ow...@bugs.debian.org
> immediately.)
> 
> 

-- 
Bobby de Vos
/bobby_de...@sil.org/



signature.asc
Description: OpenPGP digital signature

Bug#936880: Bug#966753: fixed in libiptcdata 1.0.5-2.2

[Jann Haber]

The package still depends on python2, so this bug is not yet fixed.

Bug#968566: ITP: ruby-puma-worker-killer -- kill memory leaking puma workers

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 

* Package name : ruby-puma-worker-killer
Version : 0.1.1
Upstream Author : Richard Schneeman
* URL : https://github.com/schneems/puma_worker_killer
* License : Expat
Programming Lang: Ruby
Description : kill memory leaking puma workers
Memory leaks in web code can be checked using puma_worker_killer.
.
When there is a memory leak in a code, finding and plugging it can be a
herculean effort. Instead what if processes are just killed when they 
got to
be too large? The Puma Worker Killer does just that. It is similar to 
Unicorn

Worker Killer but for the Puma web server.
.
Puma worker killer can only function cluster mode or hybrid mode 
(threads +
worker cluster) is enabled. If only using threads (and not workers) 
then puma

worker killer cannot help keep memory in control.

This is a dependency of gitlab 13.x (gitlab switched to puma from 
unicorn as default).

Bug#968079: [Python-modules-team] Bug#968079: libapache2-mod-wsgi: Package is not installable. Needs older Python2.

[Simon McVittie]

On Mon, 17 Aug 2020 at 18:44:58 +0200, Jann Haber wrote:
> Wouldn't the easiest fix for this bug and also #937062, #966763 and
> #967043 be to just drop the binary package libapache2-mod-wsgi and only
> keeping the py3 version around?
> 
> There seem to be no more rdeps in testing, so no other packages are
> blocking the removal (right?). This would help the python2 removal
> efforts.

I asked the Debian-developer-accessible mirror of the Debian archive,
and it said there is nothing in either testing or unstable that Depends or
Build-Depends on libapache2-mod-wsgi - so from a dependency point of view,
that binary package can be removed from the mod-wsgi source package at any
time. (Unless its maintainer knows of other reasons why it must be kept?)

I hope this helps,
smcv

smcv@coccia ~ % dak rm -R -n -b libapache2-mod-wsgi
...
No dependency problem found.

smcv@coccia ~ % dak rm -R -n -b -s testing libapache2-mod-wsgi
...
No dependency problem found.

Bug#968440: gnome-shell 3.36.5-1 crashes on screen lock.

[Simon McVittie]

Control: forwarded -1 
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1411

On Mon, 17 Aug 2020 at 06:51:15 -0700, Zephaniah E. Loss-Cutler-Hull wrote:
> On 8/15/20 4:26 AM, Simon McVittie wrote:
> > Are you using any GNOME Shell extensions?
> 
> I am, currently enabled:
> 
> Applications Menu, Caffeine, Native Window Placement, No Topleft Hot Corner,
> NoAnnoyance v2, Notifications Alert, ShellTile, Sound Input & Output Device
> Chooser, Status Area Horizontal Spacing, Unite, and User Themes.

It might be worthwhile to disable some or all of those and see whether that
resolves the crash; it's entirely possible that the "no blur" case cannot
happen in the upstream gnome-shell codebase, in which case it might be felt
to be more appropriate to avoid it in the extension that triggers it, rather
than in Shell itself.

I've forwarded your patch to
 and
.

smcv

Bug#968079: [Python-modules-team] Bug#968079: libapache2-mod-wsgi: Package is not installable. Needs older Python2.

[Jann Haber]

Wouldn't the easiest fix for this bug and also #937062, #966763 and #967043 be 
to just drop the binary package libapache2-mod-wsgi and only keeping the py3 
version around?

There seem to be no more rdeps in testing, so no other packages are blocking 
the removal (right?). This would help the python2 removal efforts.

On Tue, 11 Aug 2020 12:18:37 -0300 Emmanuel Arias  
wrote:
> Hi,
> 
> The package needs some more work.
> 
> I plan work on it this week, I hope have some news
> in the next few days.
> 
> 
> Cheers,
> Arias Emmanuel
> @eamanu
> http://eamanu.com
> 
> El mar., 11 de ago. de 2020 a la(s) 12:15, nb (n...@dagami.org) escribió:
> >
> > How much time does it take to come to sid?
> >
> > ___
> > Python-modules-team mailing list
> > python-modules-t...@alioth-lists.debian.net
> > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team
> 
> 

Bug#968425: mount cgroupv2 by default, similar to systemd

[Harald Dunkel]

On 8/15/20 11:29 AM, Mark Hindley wrote:


As far as I know this is already available by installing the cgroupfs-mount
package.



Nope, thats just cgroup v1.

Anyway, having the same cgroup/cgroupv2 setup as for systemd would
be an improvement, independent from cgroupfs-mount, elogind and
maybe others.


Regards
Harri

Bug#968565: ITP: r-cran-cmstatr -- GNU R Statistical Methods for Composite Material Data

[Shayan Doust]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-cmstatr -- GNU R Statistical Methods for Composite 
Material Data
Package: wnpp
Owner: Shayan Doust 
Severity: wishlist

* Package name: r-cran-cmstatr
  Version : 0.7.0
  Upstream Author : Stefan Kloppenborg ,
* URL : https://cran.r-project.org/package=cmstatr
* License : AGPL-3
  Programming Lang: GNU R
  Description : GNU R Statistical Methods for Composite Material Data
 An implementation of the statistical methods commonly
 used for advanced composite materials in aerospace applications.
 This package focuses on calculating basis values (lower tolerance
 bounds) for material strength properties, as well as performing the
 associated diagnostic tests. This package provides functions for
 calculating basis values assuming several different distributions,
 as well as providing functions for non-parametric methods of computing
 basis values. Functions are also provided for testing the hypothesis
 that there is no difference between strength and modulus data from an
 alternate sample and that from a "qualification" or "baseline" sample.
 For a discussion of these statistical methods and their use, see the
 Composite Materials Handbook, Volume 1 (2012, ISBN: 978-0-7680-7811-4).
 Additional details about this package are available in the paper by
 Kloppenborg (2020, ).

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

Bug#968379: wireshark-common: versioned dependency on libsystemd0 breaks installability with elogind

[Thorsten Glaser]

On Mon, 17 Aug 2020, Cristian Ionescu-Idbohrn wrote:

> > As a workaround you can use equivs to install a dummy package that
> > Provides: libsystemd0 (99:99) to satisfy wireshark-common's

> I would have expected such a dummy package to be provided in the 

No, this does not belong into the distribution. Because the
dependency comes from dpkg-shlibdeps it’s also fully correct.
Missing symbols may cause trouble.

libelogind0 actually *does* implement much of libsystemd0’s ABI.
Just wait for the new version.

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”  (#nosec)‣‣‣ Please let MySQL and MariaDB finally die!

Bug#950198: Jami: watch file

[Amy Kos]

Hi,

please update the watch file.


--- watch   2019-02-19 04:46:25.0 +0100
+++ watch   2020-08-17 04:46:25.0 +0100
@@ -1,3 +1,3 @@
-version=3
+version=4
 opts=dversionmangle=s/\~ds\d*$// \
-https://dl.ring.cx/ring-release/tarballs/ ring_(\d\S*)\.tar\.gz
+https://dl.jami.net/release/tarballs/ jami_(\d\S*)\.tar\.gz


Cheers,
Amy

Bug#957646: openvas-manager: ftbfs with GCC-10

[Luis Paulo Linares]

Control: tags -1 + patch

Hi,

the attached patch fixes the FTBFS with GCC-10.

Regards,
-- 
Luis Paulo (lpfll)
diff -Nru openvas-manager-7.0.3/debian/patches/010_fix-ftbfs-with-gcc-10.patch openvas-manager-7.0.3/debian/patches/010_fix-ftbfs-with-gcc-10.patch
--- openvas-manager-7.0.3/debian/patches/010_fix-ftbfs-with-gcc-10.patch   1969-12-31 21:00:00.0 -0300
+++ openvas-manager-7.0.3/debian/patches/010_fix-ftbfs-with-gcc-10.patch   2020-08-17 12:24:49.0 -0300
@@ -0,0 +1,15 @@
+Description: Fix FTBFS with GCC-10.
+Author: Luis Paulo Linares 
+Bug-Debian: https://bugs.debian.org/957646
+
+--- openvas-manager-7.0.3.orig/src/manage_sql.c
 openvas-manager-7.0.3/src/manage_sql.c
+@@ -117,7 +117,7 @@ manage_scap_loaded ();
+  *
+  * 1 if set via scheduler, 2 if set via event, else 0.
+  */
+-int authenticate_allow_all;
++extern int authenticate_allow_all;
+ 
+ const char *threat_message_type (const char *);
+ 
diff -Nru openvas-manager-7.0.3/debian/patches/series openvas-manager-7.0.3/debian/patches/series
--- openvas-manager-7.0.3/debian/patches/series 1969-12-31 21:00:00.0 -0300
+++ openvas-manager-7.0.3/debian/patches/series 2020-08-17 12:24:49.0 -0300
@@ -0,0 +1 @@
+010_fix-ftbfs-with-gcc-10.patch

Bug#968379: wireshark-common: versioned dependency on libsystemd0 breaks installability with elogind

[Cristian Ionescu-Idbohrn]

On Mon, 17 Aug 2020, Balint Reczey wrote:
> 
> Hi Cristian,

Balint,

> As a workaround you can use equivs to install a dummy package that
> Provides: libsystemd0 (99:99) to satisfy wireshark-common's
> dependencies and lose only the ability to dissect journals which most
> likely you are not interested in ;-).

I would have expected such a dummy package to be provided in the 
distribution, as a proper solution for everyone using another init, 
instead of suggesting they'd roll their own.

> I think there is an agreement with elogind's maintainer and upstream
> about the way this should be fixed so there is no need for workarounds
> in wireshark.

But, as said, I'd rather avoid using any of them, unless forced to do 
so.  It's all about freedom of choice, as long as there is one.

sysvinit has served me well during the passed 20+ years I used it and 
will hopefully continue to do so.  On my debian installations I have:

,[ /etc/apt/preferences.d/no-systemd ]
| Package: systemd systemd-sysv libsystemd0 libpam-systemd
| Pin: release o=Debian
| Pin-Priority: -1
`


Cheers,

-- 
Cristian

Bug#968446: file:///usr/share/doc/ghc-doc/html/libraries/index.html missing all base libraries

[Ilias Tsitsimpis]

Control: tags -1 + pending

Hey Joey,

On Sat, Aug 15, 2020 at 09:55AM, Joey Hess wrote:
> This involves ghc-pkg --global outputting this:
> 
> base
> 4.13.0.0
> /usr/share/doc/ghc-doc/html/libraries/base-4.13.0.0/base.haddock
> /usr/share/doc/ghc-doc/html/libraries/base-4.13.0.0
> 
> But /usr/share/doc/ghc-doc/html/libraries/base-4.13.0.0/base.haddock
> does not exist. The actual location is 
> /usr/lib/ghc-doc/haddock/ghc/base-4.13.0.0/base.haddock

Oops, this seems to be another case where we fail to correctly parse
ghc's package database. I fixed it here:

  https://salsa.debian.org/haskell-team/DHG_packages/-/commit/e62495ba6b

Please take a look and let me know if it works for you.

Thanks,

-- 
Ilias

Bug#957860: tcpick: ftbfs with GCC-10

[Luis Paulo Linares]

Control: tags -1 + patch

Hi,

the attached patch fixes the FTBFS with GCC-10.

Regards,
-- 
Luis Paulo (lpfll)
diff -Nru tcpick-0.2.1/debian/patches/fix-ftbfs-with-gcc-10.patch tcpick-0.2.1/debian/patches/fix-ftbfs-with-gcc-10.patch
--- tcpick-0.2.1/debian/patches/fix-ftbfs-with-gcc-10.patch 1969-12-31 21:00:00.0 -0300
+++ tcpick-0.2.1/debian/patches/fix-ftbfs-with-gcc-10.patch 2020-08-17 11:18:47.0 -0300
@@ -0,0 +1,27 @@
+Description: Fix FTBFS with GCC-10.
+Author: Luis Paulo Linares 
+Bug-Debian: https://bugs.debian.org/957860
+Last-Update: 2020-08-17
+
+--- tcpick-0.2.1.orig/src/conn.h
 tcpick-0.2.1/src/conn.h
+@@ -80,5 +80,5 @@ struct CONN
+ };
+ 
+ 
+-struct ip * ip_last_header; /* FIXME: check */
+-struct tcphdr * tcp_last_header;
++extern struct ip * ip_last_header; /* FIXME: check */
++extern struct tcphdr * tcp_last_header;
+--- tcpick-0.2.1.orig/src/globals.h
 tcpick-0.2.1/src/globals.h
+@@ -39,7 +39,7 @@ int datalink_size  = 0;
+ int ip_size  = 0;
+ int tcp_size = 0;
+ 
+-struct CONN * first_conn;
+-struct CONN * last_conn;
++extern struct CONN * first_conn;
++extern struct CONN * last_conn;
+ 
+ enum EXPIRED_FLAG expired_flag;
diff -Nru tcpick-0.2.1/debian/patches/series tcpick-0.2.1/debian/patches/series
--- tcpick-0.2.1/debian/patches/series  2018-11-04 10:48:34.0 -0200
+++ tcpick-0.2.1/debian/patches/series  2020-08-17 11:18:47.0 -0300
@@ -6,3 +6,4 @@
 fix-man-invocation.patch
 fix-build-with-gcc5.patch
 set-timestamp-pcap-header-structure.patch
+fix-ftbfs-with-gcc-10.patch

Bug#968379: wireshark-common: versioned dependency on libsystemd0 breaks installability with elogind

[Balint Reczey]

Hi Cristian,

On Sun, Aug 16, 2020 at 6:42 PM Cristian Ionescu-Idbohrn
 wrote:
>
> On Fri, 14 Aug 2020, Balint Reczey wrote:
> >
> > Wireshark parses systemd journals and for doing so it depends on
> > libsystemd0.
> > The version it depends on is controlled only by the used symbols and
> > wireshark only build-depends on libsystemd-dev.
>
> But Balint, reassigning that bug to elogind won't help Thorsten, nor
> me, nor anyone else using another init.
>
> Is that a poor upstream decision?  Isn't there a way to package
> wireshark with that troublesome filter in a separate package?  After
> all, _nothing_ should depend on the init system choice.

As a workaround you can use equivs to install a dummy package that
Provides: libsystemd0 (99:99) to satisfy wireshark-common's
dependencies and lose only the ability to dissect journals which most
likely you are not interested in ;-).

I think there is an agreement with elogind's maintainer and upstream
about the way this should be fixed so there is no need for workarounds
in wireshark.

Cheers,
Balint

-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#968560: unison-2.48: Bad alternative link for unison

[Stéphane Glondu]

tags 968560 + confirmed
reassign 968560 unison
thanks

Le 17/08/2020 à 15:04, frydo bugdeb a écrit :
> I don't have unison installed.
> Only unison-gtk, unison-2.48 and unison-2.48-gtk
> 
> version for unison-gtk is 2.48.4+3
> and for both unison-2.48 and unison-2.48-gtk is 2.48.4-7

Right. I will remove unison and unison-gtk from the alternatives system
in the unison package preinst, and make unison-gtk depend on unison.

Meanwhile, installing unison yourself should solve your problem.


Cheers,

-- 
Stéphane

Bug#968440: gnome-shell 3.36.5-1 crashes on screen lock.

[Zephaniah E. Loss-Cutler-Hull]

On 8/15/20 4:26 AM, Simon McVittie wrote:

On Sat, 15 Aug 2020 at 03:23:27 -0700, Zephaniah E. Loss-Cutler-Hull wrote:

When the screen locks on gnome-shell 3.36.5-1, I get the following errors in
my logs, and the screen ends up black with a cursor but never going to
sleep, and moving the mouse brings the old screen contents up but does not
let me unlock.


Are you using any GNOME Shell extensions?


I am, currently enabled:

Applications Menu, Caffeine, Native Window Placement, No Topleft Hot 
Corner, NoAnnoyance v2, Notifications Alert, ShellTile, Sound Input & 
Output Device Chooser, Status Area Horizontal Spacing, Unite, and User 
Themes.


Regards,
Zephaniah E. Loss-Cutler-Hull.

Bug#863507: test collection crashes/errors out [armel]

[Drew Parsons]

Source: numba
Version: 0.50.1-2
Followup-For: Bug #863507

ppc64el is now collecting (and passing) tests fine on ppc64el.

test collection is still a problem on armel.

Bug#968437: xindy-rules: Incorrect Norwegian sorting of č and š

[Norbert Preining]

Hi Bruno

Norbert from the TeX Live (and Debian TeX Team) here.

(please keep Cc)

here in Debian we got a bug report about using xindy with Norwegian and
Saami words:

On Sat, 15 Aug 2020, Petter Reinholdtsen wrote:
> I ran into this problem when using dblatex and xindy to typeset a book,
> where the index ended up with the wrong sorting order.  This is a
> Norwegian book with some North Saami words in the body and index.  Every
> Saami word starting with č and š are incorrectly sorted as starting with
> a symbol, while they should be sorted with c and s, respectively.


The reported also provided a patch how to fix this, see below.

Could you please comment on whether this is valid or not? If yes, I
would also update the xindy rules in TeX Live.

Thanks a lot for your time

Norbert

On Sat, 15 Aug 2020, Petter Reinholdtsen wrote:
> I tested a but further, and can confirm that this patch solve the
> problem:
> 
> --- xindy-2.5.1.20160104.orig/make-rules/alphabets/norwegian/utf8.pl.in   
> 2020-08-15 11:41:26.0 +0200
> +++ xindy-2.5.1.20160104/make-rules/alphabets/norwegian/utf8.pl.in
> 2020-08-15 11:46:27.976538044 +0200
> @@ -11,10 +11,9 @@
> [], # a with ogonek (polish)
>  ['B',  ['b','B']],
> [], # b with hook (hausa)
> -['C',  ['c','C'],['ç','Ç']],
> +['C',  ['c','C'],@u{['č','Č'],}['ç','Ç']],
> [], # ch (spanish/traditional)
> [], # cs (hungarian)
> -   [], # c with caron (many)
> [], # c with acute (croatian, lower sorbian, polish)
> [], # c with circumflex (esperanto)
> [], # c with cedilla (albanian, kurdish, turkish)
> @@ -85,10 +84,9 @@
> [], # r with caron (czech, slovak/large, upper sorbian)
> [], # r with acute (lower sorbian)
> [], # r with cedilla/comma (latvian)
> -['S',  ['s','S']],
> +['S',  ['s','S'], @u{['š', 'Š']}],
> [], # sh (albanian)
> [], # sz (hungarian)
> -   [], # s with caron (many)
> [], # s with acute (lower sorbian, polish)
> [], # s with circumflex (esperanto)
> [], # s with comma below (romanian)
> 
> I had to wrap using @u{} as the caron characters are missing in
> ISO-8859-1 (aka latin1).


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

Bug#956982: adns package is undermaintained and needs comaintainers

[Ian Jackson]

Hi.  I decided to CC the FTBFS bug report so the discussion about the
`data' symbol is properly public.  I hope that's OK with you.

Magnus Holmgren writes ("Re: adns package is undermaintained and needs 
comaintainers"):
> Sorry for not following up on this for almost a year. I felt that I
> had to get around to it now since the version in sid/testing FTBFS
> and needs to be fixed.  I'm still willing to take over
> maintainership in Debian.

That would be great.

> Tuesday 27 August 2019 at 15:14:27 CEST, Ian Jackson wrote:
> > Gianfranco, is your work in git somewhere ?  I'm not sure I agree with
> > the decision to change the source package format but since I have been
> > doing little work on this package, I don't feel I ought to try to veto
> > it.  I would like to hear what Magnus thinks.
> 
> I'm not used to the dgit philosophy, but if I understand correctly
> the reason you don't like the quilt format is that with dgit you
> base the Debian packaging on the upstream git repository, and
> changes to the upstream source can be extracted as commits that can
> be cherry-picked. Managing quilt patch files is then redundant.

You can use whatever packaging format (including quilt) with dgit, if
you want.  But I expect the upstream delta to be generally small so
quilt seems like a lot of work.

I would suggest this workflow
  https://manpages.debian.org/buster/dgit/dgit-maint-merge.7.en.html

> Anyway, currently it seems that there are no changes applied in
> Debian to the upstream code, and since you are the upstream author,
> hopefully any bugs can be patched upstream before too many
> Debian-specific changes accumulate.

Yes.

> I did take a look at 1.6.0 and found that it compiles with GCC 10, but it 
> removes a symbol: data.

Yes.

> That doesn't look like a symbol that should be public, though, so hopefully 
> adns users depend on it and it can be safely ignored?

Indeed it should.

This symbol is public by accident and not useful to any application.
It doesn't have an appropriately namespaced name.  If any application
is using it it will be accidental, and hazardous.

So IMO deleting it from the symbols file is the right fix.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#965007: pitivi: ships a copy of gstreamer libraries

[Antonio Terceiro]

Control: reassign -1 pitivi
Control: retitle -1 pitivi: ships a copy of gstreamer libraries
Control: found -1 0.999-2

On Mon, Aug 17, 2020 at 03:27:21PM +0300, Sebastian Dröge wrote:
> On Mon, 2020-08-17 at 09:10 -0300, Antonio Terceiro wrote:
> > 
> > This file is already present in pitivi on stable, and
> > gstreamer1.0-plugins-bad-apps is only present in experimental.  testing
> > and unstable are unaffected by this, or testing would be unaffected if
> > this hadn't caused pitivi to be removed.
> > 
> > I'm reassigning to gstreamer1.0-plugins-bad-apps.
> 
> It's a bug in pitivi. It should've never shipped these files outside
> its private library directory.
> 
> It will be fixed once there's a new pitivi release, which I'm waiting
> for currently. Please reassign this back to pitivi, thanks.

That's a funny way of seeing it, but it's your call.

Thanks for you work.


signature.asc
Description: PGP signature

Bug#968564: ITP: puppet-module-voxpupuli-posix-acl -- Puppet resource for managing posix-acl

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: puppet-module-voxpupuli-posix-acl
  Version : 1.0.1
  Upstream Author : Vox Pupuli
* URL : https://github.com/voxpupuli/puppet-posix_acl
* License : Apache-2.0
  Programming Lang: Puppet
  Description : Puppet resource for managing posix-acl

 Puppet lets you centrally manage every important aspect of your system using a
 cross-platform specification language that manages all the separate elements
 normally aggregated in different files, like users, cron jobs, and hosts,
 along with obviously discrete elements like packages, services, and files.
 .
 This plugin module provides a way to set POSIX 1.e (and other standards) file
 ACLs via Puppet.

Bug#968560: unison-2.48: Bad alternative link for unison

[frydo bugdeb]

On Mon, 17 Aug 2020 14:56:58 +0200 =?UTF-8?Q?St=c3=a9phane_Glondu?= 
 wrote:

There is no version 2.48.4-7 for package *unison* (there is for package
*unison-2.48*. I am asking the version of package *unison* which is
installed on your system.


Sorry.
I don't have unison installed.
Only unison-gtk, unison-2.48 and unison-2.48-gtk

version for unison-gtk is 2.48.4+3
and for both unison-2.48 and unison-2.48-gtk is 2.48.4-7

Bug#968560: unison-2.48: Bad alternative link for unison

[Stéphane Glondu]

Le 17/08/2020 à 14:53, frydo bugdeb a écrit :
> I guess I had it at some time, but now it's 2.48.4-7, for which the bug
> appeared to me.

There is no version 2.48.4-7 for package *unison* (there is for package
*unison-2.48*. I am asking the version of package *unison* which is
installed on your system.


Cheers,

-- 
Stéphane

Bug#968560: unison-2.48: Bad alternative link for unison

[frydo bugdeb]

I guess I had it at some time, but now it's 2.48.4-7, for which the bug 
appeared to me.

Le 17/08/2020 à 14:40, Stéphane Glondu a écrit :

Le 17/08/2020 à 14:21, frydo bugdeb a écrit :

Using unison though network with ssh, since last update I could not have it
work.
Connection was lost right after I give my password.

Launching unison from a shell, I could see that it was looking for a file,
unison, that could not be found.

I found out that it came from the fact that a link
/usr/etc/alternatives/unison
(where /usr/bin/unison points to) was pointing on an invalid file,
/usr/bin/unison-latest-stable-gtk, that does not exist.

In my case I had to change that link to point on /usr/bin/unison-gtk


I suspect you have unison-gtk 2.48.4-4 (or earlier) installed. Can you
confirm that?

I would fix that by adding "Breaks: unison (<< 2.48.4-5~)" to
unison-2.48 and similarly to unison-2.48-gtk.


Cheers,

Bug#968560: unison-2.48: Bad alternative link for unison

[Stéphane Glondu]

Le 17/08/2020 à 14:21, frydo bugdeb a écrit :
> Using unison though network with ssh, since last update I could not have it
> work.
> Connection was lost right after I give my password.
> 
> Launching unison from a shell, I could see that it was looking for a file,
> unison, that could not be found.
> 
> I found out that it came from the fact that a link
> /usr/etc/alternatives/unison
> (where /usr/bin/unison points to) was pointing on an invalid file,
> /usr/bin/unison-latest-stable-gtk, that does not exist.
> 
> In my case I had to change that link to point on /usr/bin/unison-gtk

I suspect you have unison-gtk 2.48.4-4 (or earlier) installed. Can you
confirm that?

I would fix that by adding "Breaks: unison (<< 2.48.4-5~)" to
unison-2.48 and similarly to unison-2.48-gtk.


Cheers,

-- 
Stéphane

Bug#968563: python3-electrum: Please version dependency on python3-attr

[intrigeri]

Package: python3-electrum
Version: 4.0.2-0.1
Severity: normal
User: tails-...@boum.org
Usertags: misc-reported

Hi,

trying to start Electrum 4.0.2-0.1 on Buster, with python3-attr
18.2.0-1 installed, fails with an exception:

  ValueError: Non keyword-only attributes are not allowed after
  a keyword-only attribute.

This problem goes away after upgrading python3-attr to 19.3.0-3~bpo10+1
from buster-backports.

Please consider versioning this dependency: this would help support
partial upgrades and using Electrum on Buster :)

(And in passing Electrum 4.0.2-0.1 fails to start on a Buster system,
saying it needs one of pycryptodomex and cryptography.
Installing python3-cryptography fixes it. I did not verify if this
dependency problem is also present on sid, so I'm not reporting a bug
just yet about a potentially missing dependency, but it might be worth
investigating :)

Bug#965067: googler: "No results"

[Jakub Wilk]

* SZ Lin , 2020-08-17, 17:29:

After investigating this issue, I cherry-picked 6 commits [1] to fix this.
It works for me now, and it would be great if you can have a test 
before uploading.


debian/patches/series looks broken: every patch name is mentioned 
twice!?


I wasn't able to apply patches using "QUILT_PATCHES=debian/patches quilt 
push -a" because of this brokenness. (But curiously, dpkg-source's 
implementation of quilt seemed to be happy with it.)


Other than that, 8fcac9bcbcfa13e2 works for me.

--
Jakub Wilk

Bug#965007: pitivi: ships a copy of gstreamer libraries

[Antonio Terceiro]

Control: retitle -1 gstreamer1.0-plugins-bad-apps: /usr/bin/gst-transcoder-1.0 
already provided by pitivi

Adjusting the bug title accordingly.


signature.asc
Description: PGP signature

Bug#968561: O: ibus-unikey -- Vietnamese Input Method Engine for IBus using Unikey Engine

[Mattia Rizzolo]

Package: wnpp

The current maintainer of ibus-unikey, Lê Quốc Tuấn ,
is apparently not active anymore.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: ibus-unikey
Binary: ibus-unikey
Version: 0.7.0~beta1-0.1
Maintainer: Lê Quốc Tuấn 
Build-Depends: cmake, debhelper-compat (= 12), libgtk-3-dev, libibus-1.0-dev 
(>= 1.5.22-2)
Architecture: any
Standards-Version: 4.5.0
Format: 3.0 (quilt)
Files:
 a79acf7c89668ff67c38348a1024e75b 1855 ibus-unikey_0.7.0~beta1-0.1.dsc
 a07a4f4e8368a69b6336902f278f9b92 92243 ibus-unikey_0.7.0~beta1.orig.tar.gz
 aa824a26b2b13cb1ec78060509ed380f 5168 ibus-unikey_0.7.0~beta1-0.1.debian.tar.xz
Checksums-Sha256:
 51a476b4f1fe1476f21016af0b767d8e7f7ee378dd9ebd1569722c1518785669 1855 
ibus-unikey_0.7.0~beta1-0.1.dsc
 962cb0b1e76b46ae6e6b4b694da005d13344bcfae1a65b33b5908223c04620a7 92243 
ibus-unikey_0.7.0~beta1.orig.tar.gz
 5a11dff73ff0751e9645ee9f45e556747c9e61d990465bef6de531e2ccdf01a0 5168 
ibus-unikey_0.7.0~beta1-0.1.debian.tar.xz
Homepage: https://github.com/vn-input/ibus-unikey
Package-List: 
 ibus-unikey deb utils optional arch=any
Directory: pool/main/i/ibus-unikey
Priority: source
Section: utils

Package: ibus-unikey
Version: 0.7.0~beta1-0.1
Installed-Size: 310
Maintainer: Lê Quốc Tuấn 
Architecture: amd64
Depends: libc6 (>= 2.14), libgcc-s1 (>= 3.0), libglib2.0-0 (>= 2.26.0), 
libgtk-3-0 (>= 3.0.0), libibus-1.0-5 (>= 1.5.22-2), libstdc++6 (>= 5.2), 
dconf-gsettings-backend | gsettings-backend, ibus (>= 1.5.22-2), ibus-gtk, 
ibus-gtk3
Description: Vietnamese Input Method Engine for IBus using Unikey Engine
Description-md5: 985e023e854ac292f0b39058569a0321
Homepage: https://github.com/vn-input/ibus-unikey
Tag: uitoolkit::gtk
Section: utils
Priority: optional
Filename: pool/main/i/ibus-unikey/ibus-unikey_0.7.0~beta1-0.1_amd64.deb
Size: 70968
MD5sum: 8be7187e7302f050d3657440d244b9e7
SHA256: e47e2e880c38e1dac626daf33a5d58c0fdc5dfb63069460436f2f6b61d4afa24


-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#965007: pitivi: ships a copy of gstreamer libraries

[Sebastian Dröge]

On Mon, 2020-08-17 at 09:10 -0300, Antonio Terceiro wrote:
> 
> This file is already present in pitivi on stable, and
> gstreamer1.0-plugins-bad-apps is only present in experimental.  testing
> and unstable are unaffected by this, or testing would be unaffected if
> this hadn't caused pitivi to be removed.
> 
> I'm reassigning to gstreamer1.0-plugins-bad-apps.

It's a bug in pitivi. It should've never shipped these files outside
its private library directory.

It will be fixed once there's a new pitivi release, which I'm waiting
for currently. Please reassign this back to pitivi, thanks.


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

Bug#968562: O: scim-unikey -- Vietnamese Input Method Engine for SCIM using Unikey Engine

[Mattia Rizzolo]

Package: wnpp

The current maintainer of scim-unikey, Lê Quốc Tuấn ,
is apparently not active anymore.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: scim-unikey
Binary: scim-unikey
Version: 0.3.1+debian-3.2
Maintainer: Lê Quốc Tuấn 
Build-Depends: debhelper (>= 7), autotools-dev, pkg-config, libscim-dev, 
autoconf, automake, autopoint, gettext, libtool, libltdl-dev
Architecture: any
Standards-Version: 3.9.1
Format: 3.0 (quilt)
Files:
 dc00ac2ae481dc9ffa725b7012fe42fb 1929 scim-unikey_0.3.1+debian-3.2.dsc
 e44fc9962c002124e137dcfc9028b0f7 484006 scim-unikey_0.3.1+debian.orig.tar.gz
 17d43b84c12414be17da52b89099142d 6540 
scim-unikey_0.3.1+debian-3.2.debian.tar.xz
Checksums-Sha256:
 697ef0d3a331120f5d4efe384675660726c095d4304904b86ad901715e008141 1929 
scim-unikey_0.3.1+debian-3.2.dsc
 ddc170308ade5e4239c8c2ab961ea7b24d8e5fa237bd28a3800914e45b9036bb 484006 
scim-unikey_0.3.1+debian.orig.tar.gz
 9a79e0f4dd96a7f1b3c79372bd81485063d52635b0c10fa3bb5c2563ec02 6540 
scim-unikey_0.3.1+debian-3.2.debian.tar.xz
Homepage: http://scim-unikey.googlecode.com/
Package-List: 
 scim-unikey deb utils extra arch=any
Directory: pool/main/s/scim-unikey
Priority: source
Section: utils

Package: scim-unikey
Version: 0.3.1+debian-3.2
Installed-Size: 313
Maintainer: Lê Quốc Tuấn 
Architecture: amd64
Depends: libc6 (>= 2.14), libgcc1 (>= 1:3.0), libglib2.0-0 (>= 2.16.0), 
libgtk-3-0 (>= 3.0.0), libscim8v5 (>= 1.4), libstdc++6 (>= 5.2), scim | skim
Description: Vietnamese Input Method Engine for SCIM using Unikey Engine
Description-md5: d1a972ca8eda60015b97b22cba4dcbd6
Homepage: http://scim-unikey.googlecode.com/
Tag: uitoolkit::gtk
Section: utils
Priority: optional
Filename: pool/main/s/scim-unikey/scim-unikey_0.3.1+debian-3.2_amd64.deb
Size: 82392
MD5sum: 291e996aac6982f154d365f2460b8047
SHA256: a39d6c38ef7dfc8b657f0f6d44262695780a94224905695879f652dfdf514ddb


-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#937665: Waiting for Python 2-depending reverse dependencies

[Jann Haber]

On 8/17/20 12:50 AM, Ben Finney wrote:
> Control: forcemerge -1 967200
> Control: block -1 by 933750
> Control: outlook -1 0
> 
> The updated package is ready, and waiting for reverse-dependencies (as
> described in bug reports blocking this one) to drop Python 2 support.
> 
> On 16-Aug-2020, Jann Haber wrote:
>> It seems like, there are no more rdeps of python-coverage now. Not
>> sure about pypy-coverage.
> 
> Yes, I see no reverse dependencies for Python 2 ‘pypy-coverage’:
> 
> $ aptitude search '~Dpypy-coverage'
> 
> But one remaining for Python 2 ‘python-coverage’:
> 
> $ aptitude search '~Dpython-coverage'
> p   paleomix
> 
> So, it seems we are waiting for ‘paleomix’ to drop Python 2 support. I
> am recording bug#933750 as a blocker for bug#933750.

Mhmm.. my statement was considering only the rdeps which are currently in 
testing.

paleomix was removed from testing in May for not supporting Python 3. Since 
then, the following b-ds of paleomix have already been dropped: python-nose, 
python-flexmock, python-pysam and python-setproctitle - so it is already 
impossible to be build from source in sid.
Also dropping python-coverage doesn't seem to do a lot of harm, considering 
that paleomix is not in testing and already broken.

Anyway it's your decision :)

Bug#968560: unison-2.48: Bad alternative link for unison

[frydo bugdeb]

Package: unison-2.48
Version: 2.48.4-7
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Using unison though network with ssh, since last update I could not have it
work.
Connection was lost right after I give my password.

Launching unison from a shell, I could see that it was looking for a file,
unison, that could not be found.

I found out that it came from the fact that a link /usr/etc/alternatives/unison
(where /usr/bin/unison points to) was pointing on an invalid file,
/usr/bin/unison-latest-stable-gtk, that does not exist.

In my case I had to change that link to point on /usr/bin/unison-gtk



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

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

Versions of packages unison-2.48 depends on:
ii  libc6  2.31-3

Versions of packages unison-2.48 recommends:
ii  openssh-client [ssh-client]  1:8.3p1-1

Versions of packages unison-2.48 suggests:
pn  unison-all  

-- no debconf information

Bug#965007: pitivi: ships a copy of gstreamer libraries

[Antonio Terceiro]

Control: reassign -1 gstreamer1.0-plugins-bad-apps

On Tue, Jul 14, 2020 at 01:16:03PM +0200, Andreas Beckmann wrote:
> Package: pitivi
> Version: 0.999-2
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> Hi,
> 
> during a test with piuparts I noticed your package fails to upgrade from
> 'sid' to 'experimental'.
> It installed fine in 'sid', then the upgrade to 'experimental' fails
> because it tries to overwrite other packages files without declaring a
> Breaks+Replaces relation.
> 
> See policy 7.6 at
> https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces
> 
> From the attached log (scroll to the bottom...):
> 
>   Selecting previously unselected package libunwind8:amd64.
>   Preparing to unpack .../1-libunwind8_1.2.1-9_amd64.deb ...
>   Unpacking libunwind8:amd64 (1.2.1-9) ...
>   Preparing to unpack .../2-libgstreamer1.0-0_1.17.2-1_amd64.deb ...
>   Unpacking libgstreamer1.0-0:amd64 (1.17.2-1) over (1.16.2-2) ...
>   Preparing to unpack .../3-libgstreamer-plugins-base1.0-0_1.17.2-1_amd64.deb 
> ...
>   Unpacking libgstreamer-plugins-base1.0-0:amd64 (1.17.2-1) over (1.16.2-4) 
> ...
>   Preparing to unpack .../4-libgstreamer-gl1.0-0_1.17.2-1_amd64.deb ...
>   Unpacking libgstreamer-gl1.0-0:amd64 (1.17.2-1) over (1.16.2-4) ...
>   Preparing to unpack .../5-gstreamer1.0-plugins-bad_1.17.2-1_amd64.deb ...
>   Unpacking gstreamer1.0-plugins-bad:amd64 (1.17.2-1) over (1.16.2-2.1+b1) ...
>   dpkg: error processing archive 
> /tmp/apt-dpkg-install-GE87Dh/5-gstreamer1.0-plugins-bad_1.17.2-1_amd64.deb 
> (--unpack):
>trying to overwrite 
> '/usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgsttranscode.so', which is also 
> in package pitivi 0.999-2
>   dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
>   Preparing to unpack .../6-libgstreamer-plugins-bad1.0-0_1.17.2-1_amd64.deb 
> ...
>   Unpacking libgstreamer-plugins-bad1.0-0:amd64 (1.17.2-1) over 
> (1.16.2-2.1+b1) ...
>   dpkg: error processing archive 
> /tmp/apt-dpkg-install-GE87Dh/6-libgstreamer-plugins-bad1.0-0_1.17.2-1_amd64.deb
>  (--unpack):
>trying to overwrite '/usr/lib/x86_64-linux-gnu/libgsttranscoder-1.0.so.0', 
> which is also in package pitivi 0.999-2
>   dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
>   Selecting previously unselected package libltc11:amd64.
>   Preparing to unpack .../7-libltc11_1.3.1-1_amd64.deb ...
>   Unpacking libltc11:amd64 (1.3.1-1) ...
>   Selecting previously unselected package libopenni2-0.
>   Preparing to unpack .../8-libopenni2-0_2.2.0.33+dfsg-13_amd64.deb ...
>   Unpacking libopenni2-0 (2.2.0.33+dfsg-13) ...
>   Selecting previously unselected package gstreamer1.0-plugins-bad-apps.
>   Preparing to unpack .../9-gstreamer1.0-plugins-bad-apps_1.17.2-1_amd64.deb 
> ...
>   Unpacking gstreamer1.0-plugins-bad-apps (1.17.2-1) ...
>   dpkg: error processing archive 
> /tmp/apt-dpkg-install-GE87Dh/9-gstreamer1.0-plugins-bad-apps_1.17.2-1_amd64.deb
>  (--unpack):
>trying to overwrite '/usr/bin/gst-transcoder-1.0', which is also in 
> package pitivi 0.999-2
>   dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
>   Errors were encountered while processing:
>/tmp/apt-dpkg-install-GE87Dh/5-gstreamer1.0-plugins-bad_1.17.2-1_amd64.deb
>
> /tmp/apt-dpkg-install-GE87Dh/6-libgstreamer-plugins-bad1.0-0_1.17.2-1_amd64.deb
>
> /tmp/apt-dpkg-install-GE87Dh/9-gstreamer1.0-plugins-bad-apps_1.17.2-1_amd64.deb
> 
> Once this has been solved in pitivi, gstreamer in experimental needs
> corresponding Breaks+Replaces to take back the files it owns.

This file is already present in pitivi on stable, and
gstreamer1.0-plugins-bad-apps is only present in experimental.  testing
and unstable are unaffected by this, or testing would be unaffected if
this hadn't caused pitivi to be removed.

I'm reassigning to gstreamer1.0-plugins-bad-apps.


signature.asc
Description: PGP signature

Bug#964536: mutrace should not depend on the shared binutils libraries

[Sudip Mukherjee]

Hi Doko,

Another ping for this bug report since you have reopened it saying its
still found in mutrace/0.2.0-3.4. Can you please let me know what am I
missing here or is it good to close the bug report?


-- 
Regards
Sudip

Bug#961438: merge request

[Bastian Germann]

https://salsa.debian.org/fonts-team/grcompiler/-/merge_requests/2
includes the proposed upstream patches.

Bug#966291: More details

[Alexey Kuznetsov]

Debian run of hwprobe: https://linux-hardware.org/?probe=a0a3771b15

It feels like debian writes a random sectors with random data at SSD for no
reason.

This is common apt error (package name varying) while SSD failing under
Debian:


...

Preconfiguring packages ...
dpkg: warning: files list file for package 'golang-1.11-go' missing;
assuming package has no files currently installed
dpkg: unrecoverable fatal error, aborting:
 files list file for package 'bison' is missing final newline
E: Sub-process /usr/bin/dpkg returned an error code (2)

...

Smartmon 6.6:  NVMe Status 0x02



root@axet-laptop:/home/axet# smartctl -a /dev/nvme0n1
smartctl 6.6 2017-11-05 r4594 [x86_64-linux-5.4.0-0.bpo.4-amd64] (local
build)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Number:   HFM512GDJTNG-8310A
Serial Number:  CD9AN74501410AR62
Firmware Version:   80001C00
PCI Vendor/Subsystem ID:0x1c5c
IEEE OUI Identifier:0xace42e
Controller ID:  1
Number of Namespaces:   1
Namespace 1 Size/Capacity:  512 110 190 592 [512 GB]
Namespace 1 Formatted LBA Size: 512
Local Time is:  Mon Aug 17 14:38:11 2020 MSK
Firmware Updates (0x16):3 Slots, no Reset required
Optional Admin Commands (0x0017):   Security Format Frmw_DL Self_Test
Optional NVM Commands (0x0016): Wr_Unc DS_Mngmt Sav/Sel_Feat
Maximum Data Transfer Size: 64 Pages
Warning  Comp. Temp. Threshold: 81 Celsius
Critical Comp. Temp. Threshold: 82 Celsius
Namespace 1 Features (0x02):NA_Fields

Supported Power States
St Op Max   Active Idle   RL RT WL WT  Ent_Lat  Ex_Lat
 0 +   3.5000W   --0  0  0  05   5
 1 +   2.4000W   --1  1  1  1   30  30
 2 +   1.9000W   --2  2  2  2  100 100
 3 -   0.0350W   --3  3  3  3 10001000
 4 -   0.0035W   --3  3  3  3 10005000

Supported LBA Sizes (NSID 0x1)
Id Fmt  Data  Metadt  Rel_Perf
 0 + 512   0 0
 1 -4096   0 0

=== START OF SMART DATA SECTION ===
Read NVMe SMART/Health Information failed: NVMe Status 0x02



Smartmon 7.1



smartctl 7.1 2019-12-30 r5022 [x86_64-linux-5.4.0-0.bpo.4-amd64] (local
build)
Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Number:   HFM512GDJTNG-8310A
Serial Number:  CD9AN74501410AR62
Firmware Version:   80001C00
PCI Vendor/Subsystem ID:0x1c5c
IEEE OUI Identifier:0xace42e
Controller ID:  1
Number of Namespaces:   1
Namespace 1 Size/Capacity:  512 110 190 592 [512 GB]
Namespace 1 Formatted LBA Size: 512
Local Time is:  Mon Aug 17 14:43:03 2020 MSK
Firmware Updates (0x16):3 Slots, no Reset required
Optional Admin Commands (0x0017):   Security Format Frmw_DL Self_Test
Optional NVM Commands (0x0016): Wr_Unc DS_Mngmt Sav/Sel_Feat
Maximum Data Transfer Size: 64 Pages
Warning  Comp. Temp. Threshold: 81 Celsius
Critical Comp. Temp. Threshold: 82 Celsius
Namespace 1 Features (0x02):NA_Fields

Supported Power States
St Op Max   Active Idle   RL RT WL WT  Ent_Lat  Ex_Lat
 0 +   3.5000W   --0  0  0  05   5
 1 +   2.4000W   --1  1  1  1   30  30
 2 +   1.9000W   --2  2  2  2  100 100
 3 -   0.0350W   --3  3  3  3 10001000
 4 -   0.0035W   --3  3  3  3 10005000

Supported LBA Sizes (NSID 0x1)
Id Fmt  Data  Metadt  Rel_Perf
 0 + 512   0 0
 1 -4096   0 0

=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

SMART/Health Information (NVMe Log 0x02)
Critical Warning:   0x00
Temperature:38 Celsius
Available Spare:100%
Available Spare Threshold:  10%
Percentage Used:27%
Data Units Read:37 476 420 [19,1 TB]
Data Units Written: 26 897 901 [13,7 TB]
Host Read Commands: 513 568 341
Host Write Commands:506 327 841
Controller Busy Time:   3 846
Power Cycles:   478
Power On Hours: 621
Unsafe Shutdowns:   56
Media and Data Integrity Errors:0
Error Information Log Entries:  0
Warning  Comp. Temperature Time:0
Critical Comp. Temperature Time:0
Temperature Sensor 1:   38 Celsius
Temperature Sensor 2:   37 Celsius

Error Information (NVMe Log 0x01, max 256 entries)
No Errors Logged


root@axet-laptop:/home/axet# 

Bug#968559: libhdf5-openmpi-dev: hdf5-mpi.pc alternative sometimes goes missing

[Drew Parsons]

Package: libhdf5-openmpi-dev
Version: 1.10.6+repack-2
Severity: normal

We've set up libhdf5-openmpi-dev (and libhdf5-mpich-dev) to use the
alternatives mechanism to configure a symlink from a generic pkgconfig
file hdf5-mpi.pc to the specific hdf5-openmpi.pc (or hdf5-mpich.pc).
This allows client programs to get libs with 'pkg-config --libs hdf5-mpi'
without needing to know which specific MPI implementation is being
used.

It's a good and useful service, I think we should keep it.

But we should document (or fix if possible) that this alternatives
mechanism is a little fragile, and sometimes the link needs to be
refresh with
  sudo dpkg-reconfigure libhdf5-openmpi-dev

What I mean is that sometimes the link seem to just disappear, so we get
  $ pkg-config --libs hdf5-mpi
  Package hdf5-mpi was not found in the pkg-config search path.
  Perhaps you should add the directory containing `hdf5-mpi.pc'
  to the PKG_CONFIG_PATH environment variable
  No package 'hdf5-mpi' found

It gets restored by 'dpkg-reconfigure libhdf5-openmpi-dev'
(update-alternative --config hdf5-mpi would also enable it to be reset).

I'm not sure why exactly the link is being lost or if it's feasible to
make the mechanism for it more robust. I presume it happens when
openmpi gets updated (e.g. recently updated to openmpi 4.0.4).
libhdf5-openmpi-dev.postinst of course is setting the alternatives
link, though I don't understand why the link would be lost just
because openmpi got upgraded.

Filing this bug so we can document and keep watch on the problem.
Again, the workaround is to run

  sudo dpkg-reconfigure libhdf5-openmpi-dev

(or dpkg-reconfigure libhdf5-mpich-dev)


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

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

Versions of packages libhdf5-openmpi-dev depends on:
ii  libaec-dev 1.0.4-1
ii  libhdf5-openmpi-103-1  1.10.6+repack-2
ii  libhdf5-openmpi-cpp-103-1  1.10.6+repack-2
ii  libhdf5-openmpi-fortran-1021.10.6+repack-2
ii  libhdf5-openmpi-hl-100 1.10.6+repack-2
ii  libhdf5-openmpi-hl-cpp-100 1.10.6+repack-2
ii  libhdf5-openmpi-hl-fortran-100 1.10.6+repack-2
ii  libjpeg-dev1:2.0.5-1.1
ii  libjpeg62-turbo-dev [libjpeg-dev]  1:2.0.5-1.1
ii  libopenmpi-dev 4.0.4-2
ii  zlib1g-dev 1:1.2.11.dfsg-2

libhdf5-openmpi-dev recommends no packages.

Versions of packages libhdf5-openmpi-dev suggests:
pn  libhdf5-doc  

-- no debconf information

Bug#968508: blender-data: Please only recommend blender instead of python3

[Elrond]

On Sun, Aug 16, 2020 at 18:07:11 +0200, Jonas Smedegaard wrote:
> No: blends-data is data for blends to use (not data that uses blends).

Okay. Got it.


What's about :any for python3?


>  - Jonas


Elrond

Bug#968555: ffmpeg: please disable build dep on libpocketsphinx-dev for alpha

[Jonas Smedegaard]

Quoting Fabian Greffrath (2020-08-17 12:48:15)
> Am 2020-08-17 11:30, schrieb Michael Cree:
> > Ffmpeg does not build on alpha as it currently depends on
> > libpocketsphinx-dev but pocketsphinx does not build on alpha
> > due to long standing test suite failures.  I see the build
> > dependency has been removed on many other arches including
> > some release arches, and it would be nice if the same could
> > be done for alpha.
> 
> Too bad we don't have architecture wildcards for use in Build-Depends 
> that provide more detail of the used architecture, like e.g. 
> [any-littleendian] or [any-32bit]. Or do we?

I specifically looked for that but failed to find it.  So I doubt it.

 - Jonas

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

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

signature.asc
Description: signature

Bug#945404: hard coded workaround for 945404

[Thomas Stewart]

Hi,

As a nasty workaround I created /etc/grub.d/06_debian_theme_fix[0] with
hard coded content. I've got a separate LUKS1 crypted /boot, hence
"(crypto0)", update with appropriate grub device name for /boot (eg
hd0,1) and remember to delete this when a proper fix appears. If
/boot/grub/.background_cache.png resides on a LUKS2 this will not work.

Kind Regards
--
Tom

[0]
"""
#!/bin/sh
set -e

cp /usr/share/images/desktop-base/desktop-grub.png 
/boot/grub/.background_cache.png

cat << EOF
background_image (crypto0)/grub/.background_cache.png
set color_normal=white/black
set color_highlight=black/white
set menu_color_normal=white/black
set menu_color_highlight=black/white
EOF
"""

Bug#968558: ansible: MySQL user module fails to detect existing mysql grants

[Tomas Kuliavas]

Package: ansible
Version: 2.7.7+dfsg-1
Severity: minor

Dear Maintainer,

Ansible playbooks that use mysql user module fail on second playbook
execution with "InvalidPrivsError unable to parse the MySQL grant
string" errors. Upstream fixed it in 
https://github.com/ansible/ansible/pull/51909.
I don't recall having this problem several months ago on same system
with same playbook. Maybe recent Buster updates changed something in
ansible or mariadb started behaving differently on target buster host.

Example mysql user task
---
- name: Setup MariaDB sqlgrey user
  mysql_user:
name: sqlgrey
password: "{{mariadb_sqlgrey_password}}"
priv: 'sqlgrey.*:ALL'
---

Problem fixed by installing updated mysql_user.py module in user space.
I don't have plans to activate backports repositories just for ansible 2.9.

Any plans on backporting upstream fix into buster stable?



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

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

Versions of packages ansible depends on:
ii  python33.7.3-1
ii  python3-crypto 2.6.1-9+b1
ii  python3-cryptography   2.6.1-3+deb10u2
ii  python3-httplib2   0.11.3-2
ii  python3-jinja2 2.10-2
ii  python3-netaddr0.7.19-1
ii  python3-paramiko   2.4.2-0.1
ii  python3-pkg-resources  40.8.0-1
ii  python3-yaml   3.13-2

Versions of packages ansible recommends:
ii  python3-jmespath   0.9.4-1
ii  python3-kerberos   1.1.14-2
ii  python3-libcloud   2.4.0-1
ii  python3-selinux2.8-1+b1
ii  python3-winrm  0.3.0-2
ii  python3-xmltodict  0.11.0-2

Versions of packages ansible suggests:
pn  cowsay   
pn  sshpass  

-- no debconf information

Bug#968555: ffmpeg: please disable build dep on libpocketsphinx-dev for alpha

[Fabian Greffrath]

Am 2020-08-17 11:30, schrieb Michael Cree:

Ffmpeg does not build on alpha as it currently depends on
libpocketsphinx-dev but pocketsphinx does not build on alpha
due to long standing test suite failures.  I see the build
dependency has been removed on many other arches including
some release arches, and it would be nice if the same could
be done for alpha.


Too bad we don't have architecture wildcards for use in Build-Depends 
that provide more detail of the used architecture, like e.g. 
[any-littleendian] or [any-32bit]. Or do we?


 - Fabian

Bug#968557: tpot: please make the build reproducible

[Chris Lamb]

Source: tpot
Version: 0.11.5+dfsg-2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
tpot could not be built reproducibly.

This is because it ships progress_verbose_1.log and
progress_verbose_2.log under /usr/lib/python3* and the second of these
is not reproducible.

Patch attached that does not ship these files - we probably should not
be shipping logfiles into this directory anyway. I note that you
already prevent a similar test being run with a --exclude argument to
nose(1) but I wasn't sure why you were doing that so did not extend
that to the tests that generate the above files.

 [0] https://reproducible-builds.org/


Regards,

--
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   ` a/debian/rules  2020-08-17 11:23:32.101143990 +0100
--- b/debian/rules  2020-08-17 11:37:15.354949925 +0100
@@ -33,6 +33,10 @@
cp -r images docs/
sed -i -e 's,$(url_strip),,' docs/index.html
 
+override_dh_auto_install:
+   dh_auto_install
+   rm -f debian/python3-tpot/usr/lib/python3*/dist-packages/*.log
+
 override_dh_installdocs:
dh_installdocs --package=python-tpot-doc --doc-main-package=python3-tpot
dh_installdocs --remaining-packages

Bug#968555: ffmpeg: please disable build dep on libpocketsphinx-dev for alpha

[Jonas Smedegaard]

Hi Michael,

Quoting Michael Cree (2020-08-17 11:30:52)
> Ffmpeg does not build on alpha as it currently depends on
> libpocketsphinx-dev but pocketsphinx does not build on alpha
> due to long standing test suite failures.  I see the build
> dependency has been removed on many other arches including
> some release arches, and it would be nice if the same could
> be done for alpha.

Has those test suite failures been investigated?

I would prefer to reference a bugreport where that underlying issue is 
tracked, so that we can be notified when (hopefully) it is later solved.


Kind regards,

 - Jonas

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

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

signature.asc
Description: signature

Bug#963150: Bug can be closed

[Pete Batard]

We confirm that this bug, which is a duplicate of 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=967918, can be closed 
as we validated that the latest Debian testing netsint.iso resolves the 
aforementioned issue.

Bug#968556: torbrowser-launcher: Will not update with french locale

[Olivier Berger]

Package: torbrowser-launcher
Version: 0.3.2-11
Severity: normal

Dear Maintainer,

When I'm launching torbrowser-launcher from a shell, I get :

$ locale
LANG=fr_FR.UTF-8
LANGUAGE=
LC_CTYPE="fr_FR.UTF-8"
LC_NUMERIC="fr_FR.UTF-8"
LC_TIME="fr_FR.UTF-8"
LC_COLLATE="fr_FR.UTF-8"
LC_MONETARY="fr_FR.UTF-8"
LC_MESSAGES="fr_FR.UTF-8"
LC_PAPER="fr_FR.UTF-8"
LC_NAME="fr_FR.UTF-8"
LC_ADDRESS="fr_FR.UTF-8"
LC_TELEPHONE="fr_FR.UTF-8"
LC_MEASUREMENT="fr_FR.UTF-8"
LC_IDENTIFICATION="fr_FR.UTF-8"
LC_ALL=
$ torbrowser-launcher 
Tor Browser Launcher
Par Micah Lee, sous licence MIT
version 0.3.2
https://github.com/micahflee/torbrowser-launcher
Votre version du Navigateur Tor est obsolète. Téléchargement de la nouvelle 
version.
Télécharger à travers Tor
Téléchargement 
https://aus1.torproject.org/torbrowser/update_3/release/Linux_x86_64-gcc3/x/en-US

Which terminates immediately without doing anything else... not starting
torbrowser :-/

When removing the locale, it works, with :

LANG=C torbrowser-launcher
Tor Browser Launcher
By Micah Lee, licensed under MIT
version 0.3.2
https://github.com/micahflee/torbrowser-launcher
Launching Tor Browser.
Running 
/home/olivier/.local/share/torbrowser/tbb/x86_64/tor-browser_en-US/start-tor-browser.desktop
Launching './Browser/start-tor-browser --detach'...

Which opens torbrowser.

Hope this helps,

Best regards,

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

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

Versions of packages torbrowser-launcher depends on:
ii  ca-certificates   20200601
ii  libdbus-glib-1-2  0.110-5
ii  python3   3.8.2-3
ii  python3-gpg   1.14.0-1
ii  python3-pyqt5 5.15.0+dfsg-1+b1
ii  python3-requests  2.23.0+dfsg-2
ii  python3-socks 1.6.8+dfsg-1.1

Versions of packages torbrowser-launcher recommends:
ii  tor  0.4.3.6-1

Versions of packages torbrowser-launcher suggests:
ii  apparmor  2.13.4-3

-- debconf-show failed

-- 
Olivier BERGER
https://www-public.imtbs-tsp.eu/~berger_o/ - OpenPGP 2048R/0xF9EAE3A65819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)

Bug#968554: live-build: install in uefi mode without internet

[otyugh]

Package: live-build
Severity: wishlist
Tags: upstream

Dear Maintainer,

My feature request is : could we have a offline installer fore the UEFI mode
installation ?

I found that the UEFI installation process requires an internet connexion (to
install grub-efi-$arch so it seems).

It can be a problem in a few scenarios :
- When you don't have an internet connexion, so you can't install
- When the live-build image is oldish : upgrades can't be made on the
livesystem (lack of space), so grub-efi fail and the whole installation process
fails
- When installing a lot of computers in a row, even with a good internet
connexion, everything get slowed down

I'd like to know :
- if I'm asking the right place to contact upstream devs ? (I found a git, but
ticket were disabled)
- if there is a "worakround" you'd suggest to use for the time being ? (some
people found ways, but in so much step that it's very scary to get into)


Thanks again for all the great work.



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

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

Bug#968555: ffmpeg: please disable build dep on libpocketsphinx-dev for alpha

[Michael Cree]

Package: ffmpeg
Version: 7:4.3.1-2
Severity: normal

Dear Maintainer,

Ffmpeg does not build on alpha as it currently depends on
libpocketsphinx-dev but pocketsphinx does not build on alpha
due to long standing test suite failures.  I see the build
dependency has been removed on many other arches including
some release arches, and it would be nice if the same could
be done for alpha.

Regards,
Michael

Bug#968265: g++: asymptote fails to compile on m68k

[Hilmar Preuße]

Control: block -1 by 968553

Am 12.08.2020 um 08:05 teilte Hilmar Preusse mit:

Hi,

> the package fails to build on m68k inside a qemu vm. I'm able to
> reproduce the issue localle, a core dump was generated, here is the
> back trace. The issue was first visible w/ 2.66-1.
> 
Probably caused by issue in libgc. Add blocking bug.

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



signature.asc
Description: OpenPGP digital signature

Bug#968553: libgc: FTBFS on m68k

[Hilmar Preusse]

Source: libgc
Version: 1:8.0.4-2
Severity: important
Tags: ftbfs

Dear Maintainer,

I'm trying to build the package for m68k inside a qemu vroot. The package
fails to build in the test suite, log is attached. Due to this issue we
(probably) get an FTBFS on package asymptote. I tried already the
latest github checkout of libgc, problem still present.

Hilmar
-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 5.7.0-1-686-pae (SMP w/2 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_GB.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
(m68k-sid)root@debian-amd64-sid:~/libgc-8.0.4# less test-suite.log

threadkey_test: /usr/include/atomic_ops/sysdeps/loadstore/atomic_load.h:31: 
AO_load: Assertion `((size_t)addr & (sizeof(*addr) - 1)) == 0' failed.
qemu: uncaught target signal 6 (Aborted) - core dumped
FAIL threadkey_test (exit status: 134)

FAIL: subthreadcreate_test
==

subthreadcreate_test: 
/usr/include/atomic_ops/sysdeps/loadstore/atomic_load.h:31: AO_load: Assertion 
`((size_t)addr & (sizeof(*addr) - 1)) == 0' failed.
qemu: uncaught target signal 6 (Aborted) - core dumped
FAIL subthreadcreate_test (exit status: 134)

FAIL: initsecondarythread_test
==

initsecondarythread_test: 
/usr/include/atomic_ops/sysdeps/loadstore/atomic_load.h:31: AO_load: Assertion 
`((size_t)addr & (sizeof(*addr) - 1)) == 0' failed.
qemu: uncaught target signal 6 (Aborted) - core dumped
FAIL initsecondarythread_test (exit status: 134)

FAIL: test_cpp
==

test_cpp: /usr/include/atomic_ops/sysdeps/loadstore/atomic_load.h:31: AO_load: 
Assertion `((size_t)addr & (sizeof(*addr) - 1)) == 0' failed.
qemu: uncaught target signal 6 (Aborted) - core dumped
FAIL test_cpp (exit status: 134)

FAIL: disclaim_test
===

disclaim_test: /usr/include/atomic_ops/sysdeps/loadstore/atomic_load.h:31: 
AO_load: Assertion `((size_t)addr & (sizeof(*addr) - 1)) == 0' failed.
qemu: uncaught target signal 6 (Aborted) - core dumped
FAIL disclaim_test (exit status: 134)

FAIL: disclaim_bench


disclaim_bench: /usr/include/atomic_ops/sysdeps/loadstore/atomic_load.h:31: 
AO_load: Assertion `((size_t)addr & (sizeof(*addr) - 1)) == 0' failed.
qemu: uncaught target signal 6 (Aborted) - core dumped
FAIL disclaim_bench (exit status: 134)

FAIL: disclaim_weakmap_test
===

disclaim_weakmap_test: 
/usr/include/atomic_ops/sysdeps/loadstore/atomic_load.h:31: AO_load: Assertion 
`((size_t)addr & (sizeof(*addr) - 1)) == 0' failed.
qemu: uncaught target signal 6 (Aborted) - core dumped
FAIL disclaim_weakmap_test (exit status: 134)

(END)
(m68k-sid)root@debian-amd64-sid:~/libgc-8.0.4# less test-suite.log

threadkey_test: /usr/include/atomic_ops/sysdeps/loadstore/atomic_load.h:31: 
AO_load: Assertion `((size_t)addr & (sizeof(*addr) - 1)) == 0' failed.
qemu: uncaught target signal 6 (Aborted) - core dumped
FAIL threadkey_test (exit status: 134)

FAIL: subthreadcreate_test
==

subthreadcreate_test: 
/usr/include/atomic_ops/sysdeps/loadstore/atomic_load.h:31: AO_load: Assertion 
`((size_t)addr & (sizeof(*addr) - 1)) == 0' failed.
qemu: uncaught target signal 6 (Aborted) - core dumped
FAIL subthreadcreate_test (exit status: 134)

FAIL: initsecondarythread_test
==

initsecondarythread_test: 
/usr/include/atomic_ops/sysdeps/loadstore/atomic_load.h:31: AO_load: Assertion 
`((size_t)addr & (sizeof(*addr) - 1)) == 0' failed.
qemu: uncaught target signal 6 (Aborted) - core dumped
FAIL initsecondarythread_test (exit status: 134)

FAIL: test_cpp
==

test_cpp: /usr/include/atomic_ops/sysdeps/loadstore/atomic_load.h:31: AO_load: 
Assertion `((size_t)addr & (sizeof(*addr) - 1)) == 0' failed.
qemu: uncaught target signal 6 (Aborted) - core dumped
FAIL test_cpp (exit status: 134)

FAIL: disclaim_test
===

disclaim_test: /usr/include/atomic_ops/sysdeps/loadstore/atomic_load.h:31: 
AO_load: Assertion `((size_t)addr & (sizeof(*addr) - 1)) == 0' failed.
qemu: uncaught target signal 6 (Aborted) - core dumped
FAIL disclaim_test (exit status: 134)

FAIL: disclaim_bench


disclaim_bench: /usr/include/atomic_ops/sysdeps/loadstore/atomic_load.h:31: 
AO_load: Assertion `((size_t)addr & (sizeof(*addr) - 1)) == 0' failed.
qemu: uncaught target signal 6 (Aborted) - core dumped
FAIL disclaim_bench (exit status: 134)

FAIL: disclaim_weakmap_test
===

disclaim_weakmap_test: 
/usr/include/atomic_ops/sysdeps/loadstore/atomic_load.h:31: AO_load: Assertion 
`((size_t)addr & (sizeof(*addr) - 1)) == 0' failed.
qemu: uncaught target signal 6 (Aborted) - core dumped
FAIL disclaim_weakmap_test (exit status: 134)


signature.asc
Description: PGP signature

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

[John Paul Adrian Glaubitz]

Hello!

Sorry for being late to the party.

Thorsten is right that pandoc should not be an arch-any build dependency.

The problem with pandoc is that it requires a very large number of Haskell 
packages
to be built before it can be built itself. This means, that pandoc comes very 
very
late when bootstrapping Debian for a new target.

However, since a fundamental package like bind9 is transitively build-depending
on pandoc now, this particular bug makes bootstrapping Debian on a new target
harder.

Therefore, in order to keep Debian bootstappable, please try to get rid of this
arch-any build dependency and move it to arch-all.

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#961438: Fix for: grcompiler FTBFS on i386: compare_PigLatinTest_v2 failed

[Tim Eves]

A fix for this bug is in upstream commit a9e6dec
,
and has been tested against 32 and 64 bit xenial boxes which were both
exhibiting the same bug described here.
--
Tim Eves
Writing Systems Technology - SIL International

Bug#964248: marked as done (base-installer: Pass "--extra-suites=unreleased" to debootstrap on ports arches)

[Samuel Thibault]

I have reverted the change for now.

But we need to discuss among various porters, I have really seen desire
for enabling the unreleased suite in ports other than the hurd port.

Samuel

Bug#968552: ITP: ukui-notification-daemon -- daemon to display passive popup notifications

[handsome_feng]

Package: wnpp
Severity: wishlist

* Package name: ukui-notification-daemon
  Version : 1.0.0
  Upstream Author : liu shanwen 
* URL : www.github.com/ukui/ukui-notification-daemon
* License : GPL-3+
  Programming Lang: C++
  Description : daemon to display passive popup notifications

 ukui-notification-daemon displays passive popup notifications
 on the Linux desktop without interrupting user's work.
 
 It is a part of UKUI desktop environment.

 Regards,
 handsome_feng