Bug#942413: [emacs] Installation of packages from GNU ELPA fails due to expired key

[Steve Suehs]

Is it upstream 26.3 that fixes this?  What process would bring 26.3 to 
buster?


On Tue, 15 Oct 2019 23:40:13 +0200 Michael Kesper wrote:

> Package: emacs
> Version: 1:26.1+1-3.2
> Severity: important
>
> --- Please enter the report below this line. ---
>
> The key for signing the emacs packages in the official GNU ELPA 
archive has changed.

> The key included in this emacs version has expired.
> This disables the download of the archive list as well as any package 
from elpa.

>
> The measures listed on 
https://elpa.gnu.org/packages/gnu-elpa-keyring-update.html

> can only partly fix this situation, it leads to:
>
> package-install-from-archive: 
https://elpa.gnu.org/packages/gnu-elpa-keyring-update-2019.3.tar: Bad 
Request

>
> Please update the included keyring (or use a newer upstream where 
it's included).

>
> --- System information. ---
> Architecture:
> Kernel: Linux 4.19.0-6-amd64
>
> Debian Release: 10.1
> 990 stable security.debian.org
> 990 stable ftp2.de.debian.org
> 500 stable-updates ftp2.de.debian.org
>
> --- Package information. ---
> Depends (Version) | Installed
> -+-=
> emacs-gtk (>= 1:26.1) | 1:26.1+1-3.2
> OR emacs-lucid (>= 1:26.1) |
> OR emacs-nox (>= 1:26.1) |
>
>
> Package's Recommends field is empty.
>
> Package's Suggests field is empty.
>

Bug#965002: mumble: New upstream version available (1.3.2)

[Chris Knadle]

Matthias Heinz:
> Package: mumble
> Version: 1.3.0+dfsg-1+b3
> Severity: wishlist
> 
> Hi!
> 
> There is a new version of mumble available upstream. It would be great if this
> could be packaged, because it would solve the slow startup of mumble (waiting
> for jack).
> 
> Thanks you!
> 
> - Matthias

Yes I'm aware of the 1.3.2 bugfix release.

I've also been wanting to fix the startup delay.  Prior to 1.3.1 which had a
long delay before release, I had attempted to include patches to the current
Debian package to fix the slow startup among other issues, but unfortunately
when I tested I found that the patches caused Mumble to fail to find internal
audio notification sound files.  This means backtracking the local Git changes
out and then trying again with a 1.3.2 tarball now that that's available.

  -- Chris

-- 
Chris Knadle
chris.kna...@coredump.us

Bug#957936: New stable Wine 5.0.1 released (May 2020) - fix building with GCC 10, please package

[Mantas Kriaučiūnas Baltix]

New stable Wine 5.0.1 released - fix building with GCC 10, please package

The Wine maintenance release 5.0.1 is available since end of May 2020

What's new in this release (see below for details):
  - Fix compilation with gcc 10
  - Add some timezones
  - Various bug fixes (37 total)

See https://www.winehq.org/announce/5.0.1

-- 
Naudokite laisvą Linux operacinę sistemą savo kompiuteryje - http://baltix.eu

Mantas Kriaučiūnas
Use Baltix GNU/Linux OS ! http://launchpad.net/baltix

Bug#964793: odd qemu/xen crashes + toolchain rings a bell

[‍小太]

On Wed, 15 Jul 2020 at 14:41, ‍小太  wrote:
>
> On Tue, 14 Jul 2020 at 19:21, ‍小太  wrote:
> >
> > On Tue, 14 Jul 2020 at 00:19, Hans van Kranenburg  wrote:
> > > 小太, can you do...
> > >
> > >   xl create -vvv 
> > >
> > > ...which should show how qemu is invoked. Can you show that command?
> > >
> > > I can provide you with some test packages with the mentioned upstream
> > > patch applied (on top of 4.11.4+24-gddaaccbbab-1), so you can test if
> > > your domU starts with them.
> > >
> > > If so, we can request the backport upstream and/or maybe pick it for
> > > Debian 4.11 into the patch queue, whatever happens earlier.
> >
> > I've updated Xen to 4.11.4+24-gddaaccbbab-1 now, but qemu is still at 
> > 1:5.0-5.
> > I'll update qemu again to 1:5.0-6 tomorrow and run a test
>
> I've tried qemu 1:5.0-6 with xen 4.11.4+24-gddaaccbbab-1 today, and
> attached is the full output of: xl -vvv create windows.xen.cfg -F
> It's a bit too long to directly include in this email :/
>
> The contents on windows.xen.cfg for this run were:
>
> name = "windows"
> builder = "hvm"
> vcpus = "4"
> memory = "1024"
> boot = "c"

And attached is the same command and config output, but with qemu 1:5.0-5

There appears to be no practical difference between the two logs (at
least before the crash)
Parsing config from windows.xen.cfg
libxl: debug: libxl_create.c:1671:do_domain_create: Domain 0:ao 0x5649af511270: create: how=(nil) callback=(nil) poller=0x5649af511300
libxl: debug: libxl_create.c:1007:initiate_domain_create: Domain 1:running bootloader
libxl: debug: libxl_bootloader.c:328:libxl__bootloader_run: Domain 1:not a PV/PVH domain, skipping bootloader
libxl: debug: libxl_event.c:686:libxl__ev_xswatch_deregister: watch w=0x5649af5165f0: deregister unregistered
domainbuilder: detail: xc_dom_allocate: cmdline="", features=""
domainbuilder: detail: xc_dom_kernel_file: filename="/usr/lib/xen-4.11/boot/hvmloader"
domainbuilder: detail: xc_dom_malloc_filemap: 174 kB
libxl: debug: libxl_dom.c:973:libxl__load_hvm_firmware_module: Loading BIOS: /usr/share/seabios/bios-256k.bin
domainbuilder: detail: xc_dom_boot_xen_init: ver 4.11, caps xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64
domainbuilder: detail: xc_dom_parse_image: called
domainbuilder: detail: xc_dom_find_loader: trying multiboot-binary loader ...
domainbuilder: detail: loader probe failed
domainbuilder: detail: xc_dom_find_loader: trying HVM-generic loader ...
domainbuilder: detail: loader probe OK
xc: detail: ELF: phdr: paddr=0x10 memsz=0x35104
xc: detail: ELF: memory: 0x10 -> 0x135104
domainbuilder: detail: xc_dom_mem_init: mem 1016 MB, pages 0x3f800 pages, 4k each
domainbuilder: detail: xc_dom_mem_init: 0x3f800 pages
domainbuilder: detail: xc_dom_boot_mem_init: called
domainbuilder: detail: range: start=0x0 end=0x3f80
domainbuilder: detail: xc_dom_malloc: 2032 kB
xc: detail: PHYSICAL MEMORY ALLOCATION:
xc: detail:   4KB PAGES: 0x0400
xc: detail:   2MB PAGES: 0x01fa
xc: detail:   1GB PAGES: 0x
domainbuilder: detail: xc_dom_build_image: called
domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn 0x100+0x36 at 0x7f39b5a7a000
domainbuilder: detail: xc_dom_alloc_segment:   kernel   : 0x10 -> 0x136000  (pfn 0x100 + 0x36 pages)
xc: detail: ELF: phdr 0 at 0x7f39b5a44000 -> 0x7f39b5a6f680
domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn 0x136+0x40 at 0x7f39b5a3a000
domainbuilder: detail: xc_dom_alloc_segment:   System Firmware module : 0x136000 -> 0x176000  (pfn 0x136 + 0x40 pages)
domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn 0x176+0x1 at 0x7f39b60b1000
domainbuilder: detail: xc_dom_alloc_segment:   HVM start info : 0x176000 -> 0x177000  (pfn 0x176 + 0x1 pages)
domainbuilder: detail: alloc_pgtables_hvm: doing nothing
domainbuilder: detail: xc_dom_build_image  : virt_alloc_end : 0x177000
domainbuilder: detail: xc_dom_build_image  : virt_pgtab_end : 0x0
domainbuilder: detail: xc_dom_boot_image: called
domainbuilder: detail: xc_dom_compat_check: supported guest type: xen-3.0-x86_64
domainbuilder: detail: xc_dom_compat_check: supported guest type: xen-3.0-x86_32p
domainbuilder: detail: xc_dom_compat_check: supported guest type: hvm-3.0-x86_32 <= matches
domainbuilder: detail: xc_dom_compat_check: supported guest type: hvm-3.0-x86_32p
domainbuilder: detail: xc_dom_compat_check: supported guest type: hvm-3.0-x86_64
domainbuilder: detail: domain builder memory footprint
domainbuilder: detail:allocated
domainbuilder: detail:   malloc : 2037 kB
domainbuilder: detail:   anon mmap  : 0 bytes
domainbuilder: detail:mapped
domainbuilder: detail:   file mmap  : 174 kB
domainbuilder: detail:   domU mmap  : 476 kB
domainbuilder: detail: vcpu_hvm: called
domainbuilder: detail: xc_dom_gnttab_hvm_seed: called, pfn=0xff000
domainbuilder: detail: xc_dom_gnttab_hvm_seed: called, 

Bug#890343: default qdisc

[Matt Taggart]

Regarding the default qdisc setting, here's an interesting article in 
Phoronix about fq_pie


Linux 5.9 To Allow Defaulting To FQ-PIE Queuing Discipline For Fighting 
Bufferbloat

https://www.phoronix.com/scan.php?page=news_item=Linux-5.9-FQ-PIE-QDISC

I think this only means it's possible for it to be set as the default in 
5.9, I don't know what the upstream kernel will ship with as a default.


The Debian default needs to be updated, fq_codel would be a good choice, 
maybe fq_pie is a good choice starting in 5.9 as well.


Any comments on this or my previous questions from April? What needs to 
happen for this to change?


Thanks,

--
Matt Taggart
tagg...@debian.org

Bug#964793: odd qemu/xen crashes + toolchain rings a bell

[‍小太]

On Tue, 14 Jul 2020 at 19:21, ‍小太  wrote:
>
> On Tue, 14 Jul 2020 at 00:19, Hans van Kranenburg  wrote:
> > 小太, can you do...
> >
> >   xl create -vvv 
> >
> > ...which should show how qemu is invoked. Can you show that command?
> >
> > I can provide you with some test packages with the mentioned upstream
> > patch applied (on top of 4.11.4+24-gddaaccbbab-1), so you can test if
> > your domU starts with them.
> >
> > If so, we can request the backport upstream and/or maybe pick it for
> > Debian 4.11 into the patch queue, whatever happens earlier.
>
> I've updated Xen to 4.11.4+24-gddaaccbbab-1 now, but qemu is still at 1:5.0-5.
> I'll update qemu again to 1:5.0-6 tomorrow and run a test

I've tried qemu 1:5.0-6 with xen 4.11.4+24-gddaaccbbab-1 today, and
attached is the full output of: xl -vvv create windows.xen.cfg -F
It's a bit too long to directly include in this email :/

The contents on windows.xen.cfg for this run were:

name = "windows"
builder = "hvm"
vcpus = "4"
memory = "1024"
boot = "c"
Parsing config from windows.xen.cfg
libxl: debug: libxl_create.c:1671:do_domain_create: Domain 0:ao 0x55aad1cfc270: create: how=(nil) callback=(nil) poller=0x55aad1cfc300
libxl: debug: libxl_create.c:1007:initiate_domain_create: Domain 2:running bootloader
libxl: debug: libxl_bootloader.c:328:libxl__bootloader_run: Domain 2:not a PV/PVH domain, skipping bootloader
libxl: debug: libxl_event.c:686:libxl__ev_xswatch_deregister: watch w=0x55aad1d015f0: deregister unregistered
domainbuilder: detail: xc_dom_allocate: cmdline="", features=""
domainbuilder: detail: xc_dom_kernel_file: filename="/usr/lib/xen-4.11/boot/hvmloader"
domainbuilder: detail: xc_dom_malloc_filemap: 174 kB
libxl: debug: libxl_dom.c:973:libxl__load_hvm_firmware_module: Loading BIOS: /usr/share/seabios/bios-256k.bin
domainbuilder: detail: xc_dom_boot_xen_init: ver 4.11, caps xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64
domainbuilder: detail: xc_dom_parse_image: called
domainbuilder: detail: xc_dom_find_loader: trying multiboot-binary loader ...
domainbuilder: detail: loader probe failed
domainbuilder: detail: xc_dom_find_loader: trying HVM-generic loader ...
domainbuilder: detail: loader probe OK
xc: detail: ELF: phdr: paddr=0x10 memsz=0x35104
xc: detail: ELF: memory: 0x10 -> 0x135104
domainbuilder: detail: xc_dom_mem_init: mem 1016 MB, pages 0x3f800 pages, 4k each
domainbuilder: detail: xc_dom_mem_init: 0x3f800 pages
domainbuilder: detail: xc_dom_boot_mem_init: called
domainbuilder: detail: range: start=0x0 end=0x3f80
domainbuilder: detail: xc_dom_malloc: 2032 kB
xc: detail: PHYSICAL MEMORY ALLOCATION:
xc: detail:   4KB PAGES: 0x0400
xc: detail:   2MB PAGES: 0x01fa
xc: detail:   1GB PAGES: 0x
domainbuilder: detail: xc_dom_build_image: called
domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn 0x100+0x36 at 0x7f3680f56000
domainbuilder: detail: xc_dom_alloc_segment:   kernel   : 0x10 -> 0x136000  (pfn 0x100 + 0x36 pages)
xc: detail: ELF: phdr 0 at 0x7f3680f2 -> 0x7f3680f4b680
domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn 0x136+0x40 at 0x7f3680f16000
domainbuilder: detail: xc_dom_alloc_segment:   System Firmware module : 0x136000 -> 0x176000  (pfn 0x136 + 0x40 pages)
domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn 0x176+0x1 at 0x7f368158d000
domainbuilder: detail: xc_dom_alloc_segment:   HVM start info : 0x176000 -> 0x177000  (pfn 0x176 + 0x1 pages)
domainbuilder: detail: alloc_pgtables_hvm: doing nothing
domainbuilder: detail: xc_dom_build_image  : virt_alloc_end : 0x177000
domainbuilder: detail: xc_dom_build_image  : virt_pgtab_end : 0x0
domainbuilder: detail: xc_dom_boot_image: called
domainbuilder: detail: xc_dom_compat_check: supported guest type: xen-3.0-x86_64
domainbuilder: detail: xc_dom_compat_check: supported guest type: xen-3.0-x86_32p
domainbuilder: detail: xc_dom_compat_check: supported guest type: hvm-3.0-x86_32 <= matches
domainbuilder: detail: xc_dom_compat_check: supported guest type: hvm-3.0-x86_32p
domainbuilder: detail: xc_dom_compat_check: supported guest type: hvm-3.0-x86_64
domainbuilder: detail: domain builder memory footprint
domainbuilder: detail:allocated
domainbuilder: detail:   malloc : 2037 kB
domainbuilder: detail:   anon mmap  : 0 bytes
domainbuilder: detail:mapped
domainbuilder: detail:   file mmap  : 174 kB
domainbuilder: detail:   domU mmap  : 476 kB
domainbuilder: detail: vcpu_hvm: called
domainbuilder: detail: xc_dom_gnttab_hvm_seed: called, pfn=0xff000
domainbuilder: detail: xc_dom_gnttab_hvm_seed: called, pfn=0xff001
domainbuilder: detail: xc_dom_release: called
libxl: debug: libxl_dm.c:1655:libxl__build_device_model_args_new: Domain 2:dm_restrict disabled, starting QEMU as root
libxl: debug: libxl_dm.c:2331:libxl__spawn_local_dm: Domain 2:Spawning device-model 

Bug#870641: light-locker: screen stays black after closing and opening laptop lid

[Aaron Lu]

Another weird thing: on 4.19.0-9, if I leave the screen/display off long
enough, like:
1 lock the screen
2 see the display off
3 go out for lunch
4 when return, typing or moving mouse can bring the display back on.

As comparison, if I leave the screen/display off not long enough, like
going to take some drink, when I get back, in 4), the display won't be
powered back on by typing or moving mouse.

I have no idea of what happened...

Bug#965051: proftpd-basic: Enable more modules

[Hilmar Preusse]

Package: proftpd-basic
Version: 1.3.6c-1
Severity: wishlist

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

Hilmar

[1] https://github.com/proftpd/proftpd/issues/931
-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux 10 (buster)
Release:10
Codename:   buster
Architecture: armv7l

Kernel: Linux 4.19.57-v7+ (SMP w/4 CPU cores)
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages proftpd-basic depends on:
ii  adduser3.118
ii  debianutils4.8.6.1
ii  libacl12.2.53-4
ii  libattr1   1:2.4.48-4
ii  libc6  2.28-10+rpi1
ii  libcap21:2.25-2
pn  libhiredis0.14 
pn  libmemcached11 
pn  libmemcachedutil2  
ii  libncursesw6   6.1+20181013-2+deb10u2
ii  libpam-runtime 1.3.1-5
ii  libpam0g   1.3.1-5
ii  libpcre3   2:8.39-12
ii  libssl1.1  1.1.1d-0+deb10u3
ii  libtinfo6  6.1+20181013-2+deb10u2
ii  libwrap0   7.6.q-28
ii  lsb-base   10.2019051400+rpi1
ii  netbase5.6
ii  sed4.7-1
ii  ucf3.0038+nmu1
ii  zlib1g 1:1.2.11.dfsg-1

Versions of packages proftpd-basic recommends:
pn  proftpd-doc  

Versions of packages proftpd-basic suggests:
pn  openbsd-inetd | inet-superserver  
ii  openssl   1.1.1d-0+deb10u3
pn  proftpd-mod-geoip 
pn  proftpd-mod-ldap  
pn  proftpd-mod-mysql 
pn  proftpd-mod-odbc  
pn  proftpd-mod-pgsql 
pn  proftpd-mod-snmp  
pn  proftpd-mod-sqlite

Bug#965049: linux-source-5.6 build issues for ARM64

[Elliott Mitchell]

On Tue, Jul 14, 2020 at 08:20:29PM -0700, Elliott Mitchell wrote:
> I'm speculating the build may work if I run the correct rule, but I
> haven't yet identified that.

To make things easier for others, "all" was sufficient.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#965050: python3-flask-babel: flask_babel broken after recent werkzeug update

[Raja R Harinath]

Package: python3-flask-babel
Version: 0.11.2-3
Severity: normal
Tags: upstream
X-Debbugs-Cc: harin...@hurrynot.org

Dear Maintainer,

I use 'fava' which appears to use 'flask_babel'.  Recently, 'fava' started
crashing with the following backtrace:

--8<--
Traceback (most recent call last):
  File "/usr/bin/fava", line 11, in 
load_entry_point('fava==1.14', 'console_scripts', 'fava')()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 490, in
load_entry_point
return get_distribution(dist).load_entry_point(group, name)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2859,
in load_entry_point
return ep.load()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2450,
in load
return self.resolve()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2456,
in resolve
module = __import__(self.module_name, fromlist=['__name__'], level=0)
  File "/usr/lib/python3/dist-packages/fava/cli.py", line 11, in 
from fava.application import app
  File "/usr/lib/python3/dist-packages/fava/application.py", line 35, in

from flask_babel import Babel
  File "/usr/lib/python3/dist-packages/flask_babel/__init__.py", line 19, in

from werkzeug import ImmutableDict
ImportError: cannot import name 'ImmutableDict' from 'werkzeug'
(/usr/lib/python3/dist-packages/werkzeug/__init__.py)
--8<--

Turns out werkzeug was recently updated:

--8<--
python-werkzeug (1.0.1+dfsg1-2) unstable; urgency=medium

  * Uploading to unstable.

 -- Ondřej Nový   Tue, 14 Jul 2020 09:40:21 +0200
--8<--

The origin of the bug seems to be the use of deprecated exports from werkzeug,
which were removed:

https://github.com/pallets/werkzeug/commit/d50618e3651ad5d4d3118e903a040b733c4d0233#diff-9ab9cda90dbf882c5f053820bffc3d15

The fix appears to be:

  https://github.com/python-babel/flask-
babel/commit/fcc347b8e4c751f4cbe36d2a7652bc250f780c99



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

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

Versions of packages python3-flask-babel depends on:
ii  python3 3.8.2-3
ii  python3-babel   2.8.0+dfsg.1-3
ii  python3-flask   1.1.2-1
ii  python3-jinja2  2.11.2-1

python3-flask-babel recommends no packages.

Versions of packages python3-flask-babel suggests:
pn  python-flask-babel-doc  

-- no debconf information

Bug#965049: linux-source-5.6 build issues for ARM64

[Elliott Mitchell]

Package: src:linux
Version: 5.6.14-2~bpo10+1
Severity: important

I'm guessing this is isolated to ARM64 targets as I don't see other
reports.  I'm having difficulty trying to taget "bindeb-pkg" with
linux-source-5.6.

During the initial phase build was terminating quickly, complaining about
missing System.map.  I managed to work around this via
`make vmlinux modules`.  Now I'm to the error
"cp: cannot stat 'arch/arm64/boot/Image.gz': No such file or directory"

I'm speculating the build may work if I run the correct rule, but I
haven't yet identified that.

Kind of feels like all dependancies got lost for ARM64 targets.  This
may not warrant grave severity as some architectures build, but if you're
on ARM64 there is a major problem.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#870641: light-locker: screen stays black after closing and opening laptop lid

[Aaron Lu]

On Tue, Jul 14, 2020 at 07:38:21PM -0400, David Farrier wrote:
> 
> On Tue, 14 Jul 2020, Aaron Lu wrote:
> > 
> > Anyway, I downloaded this package directly from the mirror's pool:
> > linux-image-4.19.0-10-amd64-unsigned_4.19.131-2_amd64.deb
> > Is the above package correct?
> > 
> > And the good news is, this kernel also works fine :-)
> > 
> 
> I tried something similar, but am having mixed results. I added
> "buster-proposed-updates main" to sources.list, and installed
> linux-image-4.19.0-10-amd64. Which I think should be the same as Aaron Lu
> retrieved, except I have the signed variant. I installed on a Panasonic
> CF-19 laptop running Debian 10.4 and xfce.
> 
> Recovering from screen blanking and locking does work with that version of
> the kernel. So, on my computer, it does work better than the standard buster
> kernel 4.19.0-9. However, suspend and hibernate still don't work. I haven't

I never tried suspend/hibernation before but I just gave it a shot.
Interestingly, the display can be powered back on after resume even with
4.19.0-9 and I can then input my password and unlock the screen.

My gut feeling is that, in the case of suspend/resume, the display is
powered by the gpu dirver which is i915 in my case while in the normal
lock/unlock case, the display is controlled by light-locker through some
mechanism and the communication between light-locker and the gpu driver
broke somehow.

> had a chance to try Aaron Lu's suggestion of backported kernel 5.6.0.

Not a suggestion, just installed what is available in the backport repo
of that time :-)

> However, I have been using 5.4.0 for a while, and blanking, locking,
> suspend, and hibernate all work with that version.
> 
> Hope this information is helpful.

Bug#965048: elpa-magithub: Dependency on deprecated ‘magit-popup’ causes warning, should migrate to ‘transient’

[Ben Finney]

Package: elpa-magithub
Version: 0.1.7-2
Severity: important
Tags: upstream

When using current Magit (release “2.99.0.git0957.ge8c7bd03-1” from
Debian) while Magithub is installed, Magit repeatedly interrupts with
a warning:

Warning (magit): Magit no longer uses Magit-Popup.
It now uses Transient.
See https://emacsair.me/2019/02/14/transient-0.1.

However your configuration and/or some third-party package that
you use still depends on the `magit-popup' package. But because
`magit' no longer depends on that, `package' has removed it from
your system.

If some package that you use still depends on `magit-popup' but
does not declare it as a dependency, then please contact its
maintainer about that and install `magit-popup' explicitly.

[…]

(the full text is from function ‘magit--magit-popup-warning’ in
‘/usr/share/emacs/site-lisp/elpa-src/magit-2.99.0/magit-obsolete.el’.)

The interruption is often enough that the Magit user interface becomes
effectively unusable, hence this bug is “Severity: important”.

This warning occurs on my system is because Magithub has a dependency
on ‘magit-popup’, but does not declare it in a way that the Emacs
package manager can detect. A debugging backtrace shows:

=
Debugger entered--entering a function:
* magit--magit-popup-warning()
  magit-define-popup-action(magit-dispatch-popup 72 "Magithub" 
magithub-dispatch-popup 33)
  (progn (magit-define-popup-action (quote magit-dispatch-popup) 72 "Magithub" 
(function magithub-dispatch-popup) 33) (define-key magit-status-mode-map "H" 
(function magithub-dispatch-popup)))
  (lambda nil (progn (magit-define-popup-action (quote magit-dispatch-popup) 72 
"Magithub" (function magithub-dispatch-popup) 33) (define-key 
magit-status-mode-map "H" (function magithub-dispatch-popup()
  
eval-after-load-helper("/usr/share/emacs/site-lisp/elpa/magit-2.99.0/magit.elc")
  run-hook-with-args(eval-after-load-helper 
"/usr/share/emacs/site-lisp/elpa/magit-2.99.0/magit.elc")
  
do-after-load-evaluation("/usr/share/emacs/site-lisp/elpa/magit-2.99.0/magit.elc")
  require(magit)
  
byte-code("\300\301!\210\302\303\304\305\306\307%\210\310\311\312\313\314DD\315\306\303\316\317\320\321&\011\207"
 [require magit custom-declare-group magit-extras nil "Additional functionality 
for Magit." :group magit-extensions custom-declare-variable 
magit-gitk-executable funcall function #f(compiled-function () #) "The Gitk executable." :set-after (magit-git-executable) :type 
string] 10)
  autoload-do-load((autoload "magit-extras" "Like `next-line' but with 
Magit-specific shift-selection.\n\nMagit's selection mechanism is based on the 
region but selects\nan area that is larger than the region.  This causes 
`next-line'\nwhen invoked while holding the shift key to move down one 
line\nand thereby select two lines.  When invoked inside a hunk body\nthis 
command does not move point on the first invocation and\nthereby it only 
selects a single line.  Which inconsistency you\nprefer is a matter of 
preference.\n\n(fn  ARG TRY-VSCROLL)" t nil) magit-next-line)
  command-execute(magit-next-line)
=

According to the warning message:

=
* If you use `magit-popup' to define your own popups but do not
  modify any of Magit's old popups, then you have to install
  `magit-popup' explicitly.  (You can also migrate to Transient,
  but there is no need to rush that.)
=

So according to that, either of those resolutions would be sufficient
to avoid this breakage.


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

Kernel: Linux 5.7.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_AU.UTF-8), LANGUAGE=en_AU.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_AU.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages elpa-magithub depends on:
ii  elpa-ghub+  0.3-5
ii  elpa-git-commit 2.99.0.git0957.ge8c7bd03-1
ii  elpa-magit  2.99.0.git0957.ge8c7bd03-1
ii  elpa-markdown-mode  2.4-1
ii  elpa-s  1.12.0-3
ii  emacsen-common  3.0.4

Versions of packages elpa-magithub recommends:
ii  emacs  1:26.3+1-2
ii  emacs-gtk [emacs]  1:26.3+1-2

elpa-magithub suggests no packages.

-- no debconf information

-- 
 \“If you go to a costume party at your boss's house, wouldn't |
  `\ you think a good costume would be to dress up like the boss's |
_o__)  wife? Trust me, it's not.” —Jack Handey |
Ben Finney 

signature.asc
Description: PGP signature

Bug#962159: I'd consider this release fit for Debian unstable

[Richard Hansen]

retitle 962159 RFS: ddclient/3.9.1-3 [ITA] -- address updating utility for 
dynamic DNS services
thanks

I just uploaded ddclient 3.9.1-3 to mentors:
https://mentors.debian.net/package/ddclient
https://salsa.debian.org/debian/ddclient/-/tags/debian%2F3.9.1-3
I decided to abandon my attempts to support easy backports to Ubuntu 16.04 
(Xenial) and upgraded debhelper-compat to 12. For the rationale, see 
https://salsa.debian.org/debian/ddclient/-/commit/ff5c74c7984472155c7cac1fc356d53ef1e3cb73.

Bug#965047: jtreg won't run as it can't locate its own jar file

[Tiago Daitx]

Please consider the attached debdiff to fix this issue.


jtreg-5.1-b01-1_5.1-b01-2.debdiff
Description: Binary data

Bug#965047: jtreg won't run as it can't locate its own jar file

[Tiago Stürmer Daitx]

Package: jtreg
Version: 5.1-b01-1
Severity: important

Dear Maintainer,

Since jtreg 5.1-b01-1 it will no longer run without having JTREG_HOME (or
JT_HOME) explicitly set on the environment, previous versions worked ok.

It will exit 1 when trying to run it:
$ jtreg
Cannot determine JTREG_HOME; please set it explicitly

The reason is a change in debian/patches/launcher.patch that adds the check

 if [ -z "${JTREG_HOME}" ]; then
 JTREG_HOME="/usr/share/jtreg"
 fi

too further down compared to the previous jtreg version. This causes the code
to search for lib/jtreg.jar in the script's path (/usr/bin) first, which does
not work and then calls exit 1.

That check is added exclusively for Debian/Ubuntu by d/p/launcher.patch and
should come before jtreg will try to look for lib/jtreg.jar by itself.

This also affects openjdk autopkgtests, which don't get run becuse jtreg
fails to start.

Thanks!

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

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

Bug#964910: RM: jigl -- ROM; dead upstream, low popcon, alternatives exist

[Sean Whitton]

Hello Nicholas,

On Mon 13 Jul 2020 at 10:23PM -07, Nicholas Breen wrote:

> It does still work (modulo #936008, which requires rewriting one script
> -- though the package is basically just two scripts).  However, there's
> nothing it does that other packages don't do equally well or better; it
> could be orphaned and remain for another release or two, but I'm not
> convinced it's helping anyone trying to decide between all the results
> of "apt-cache search galler(y|ies)".

Fair point, but the popcon is far from zero, and it would surely help
existing users to keep it around.  Going ahead and closing the bug.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#965046: cmake: compiler_id_detection fails for armhf when using QEMU user-mode emulation

[David Lechner]

Package: cmake
Version: 3.16.3-1ubuntu1
Severity: normal

Dear Maintainer,


   * What led up to the situation? Trying to build a package using pbuilder and
qemu on travis-ci.org
   * What exactly did you do (or not do) that was effective (or
 ineffective)? Works for nativie arcitecture but fails when run using qemu
   * What was the outcome of this action? https://travis-
ci.org/github/ev3dev/ev3devKit/jobs/708160450
   * What outcome did you expect instead? Building should complete without
error as with previous versions of cmake


This is likely caused by upstream bug
https://gitlab.kitware.com/cmake/cmake/-/issues/20568 (regrission introduced in
cmake 3.15)


This can probably be fixed by adding something similar to this in debian/rules:

export CFLAGS="-D_FILE_OFFSET_BITS=64"
export CXXFLAGS="-D_FILE_OFFSET_BITS=64"




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

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

Versions of packages cmake depends on:
ii  cmake-data3.16.3-1ubuntu1
ii  libarchive13  3.4.0-2ubuntu1
ii  libc6 2.31-0ubuntu9
ii  libcurl4  7.68.0-1ubuntu2.1
ii  libexpat1 2.2.9-1build1
ii  libgcc-s1 10-20200411-0ubuntu1
ii  libjsoncpp1   1.7.4-3.1ubuntu2
ii  librhash0 1.3.9-1
ii  libstdc++610-20200411-0ubuntu1
ii  libuv11.34.2-1ubuntu1
ii  procps2:3.3.16-1ubuntu2
ii  zlib1g1:1.2.11.dfsg-2ubuntu1

Versions of packages cmake recommends:
ii  gcc   4:9.3.0-1ubuntu2
ii  make  4.2.1-1.2

Versions of packages cmake suggests:
pn  cmake-doc
ii  ninja-build  1.10.0-1build1

-- no debconf information

Bug#870641: light-locker: screen stays black after closing and opening laptop lid

[David Farrier]

On Tue, 14 Jul 2020, Aaron Lu wrote:


Anyway, I downloaded this package directly from the mirror's pool:
linux-image-4.19.0-10-amd64-unsigned_4.19.131-2_amd64.deb
Is the above package correct?

And the good news is, this kernel also works fine :-)



I tried something similar, but am having mixed results. I added 
"buster-proposed-updates main" to sources.list, and installed 
linux-image-4.19.0-10-amd64. Which I think should be the same as Aaron Lu 
retrieved, except I have the signed variant. I installed on a Panasonic 
CF-19 laptop running Debian 10.4 and xfce.


Recovering from screen blanking and locking does work with that version of 
the kernel. So, on my computer, it does work better than the standard 
buster kernel 4.19.0-9. However, suspend and hibernate still don't work. 
I haven't had a chance to try Aaron Lu's suggestion of backported kernel 
5.6.0. However, I have been using 5.4.0 for a while, and blanking, 
locking, suspend, and hibernate all work with that version.


Hope this information is helpful.

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

[florine]

I still get the same error with sbcl 2:2.0.6-2.

I don't get an error (no matter which sbcl version) with

(with-state-monad
  (with-input-from-string (in "1")
  (run!
   (lambda (s) (cons (read s) s))
  in)))

instead of

(with-input-from-string (in "1")
(with-state-monad
(run!
(lambda (s) (cons (read s) s))
in)))

Am Monday, den 07/13/2020 um 12:19:42 PM +0200 schrieb Sébastien Villemot 
:
> Control: tags -1 + upstream moreinfo
> 
> Dear Florine,
> 
> Le mercredi 08 juillet 2020 à 21:24 +, florine forine a écrit :
> > Package: sbcl
> > Version: 2:2.0.5-1
> > Severity: normal
> 
> > I describe actions that lead to a "Memory fault" in sbcl.
> > Same error happens with sbcl 2.0.6.59-e802114ba.
> > No error with clisp and abcl.
> > 
> >* What led up to the situation?
> > 
> > in sbcl repl:
> > 
> >(ql:quickload "cl-monad-macros")
> >(in-package :cl-monad-macros)
> >(with-input-from-string (in "1")
> >(with-state-monad
> >(run!
> >(lambda (s) (cons (read in) in))
> >in)))
> > 
> >* What was the outcome of this action?
> > 
> > CORRUPTION WARNING in SBCL pid 31499(tid 0x7f9abea152c0):
> > Memory fault at 0x7faf (pc=0x5219f454 [code 0x5219f350+0x104 ID
> > 0x5933], fp=0x7f9abe77f5b8, sp=0x7f9abe77f5a0) tid 0x7f9abea152c0
> > The integrity of this image is possibly compromised.
> > Continuing with fingers crossed.
> > 
> > debugger invoked on a SB-SYS:MEMORY-FAULT-ERROR in thread
> > #:
> >   Unhandled memory fault at #x7FAF.
> 
> I can replicate this problem with sbcl 2:2.0.5-1, but not with sbcl
> 2:2.0.6-2.
> 
> Can you confirm that the latest sbcl upload fixes it for you too?
> 
> Best,
> 
> -- 
> ⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
> ⣾⠁⢠⠒⠀⣿⡁  Debian Developer
> ⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
> ⠈⠳⣄  https://www.debian.org
> 



-- 


signature.asc
Description: PGP signature

Bug#965028: systemd: journalctl does not work for normal users at all

[Daniel Blaschke]

OK, so now it works after rebooting - logging out and back in was not 
enough after adding myself to the groups apparently; sorry for the noise.

Could this bug perhaps be reassigned to the debian-installer?
Kind of think the primary admin user (which is set up during a fresh 
install) should be added to those groups by default.

Cheers,
Daniel

On Tue, 14 Jul 2020, Michael Biebl wrote:


Control: tags -1 + moreinfo unreproducible

Am 14.07.20 um 18:50 schrieb Daniel Blaschke:

Package: systemd
Version: 241-7~deb10u4
Severity: important

Dear Maintainer,

$ journalctl
Hint: You are currently not seeing messages from other users and the system.
  Users in the 'systemd-journal' group can see all messages. Pass -q to
  turn off this notice.
No journal files were opened due to insufficient permissions.


therefore, gnome-logs is empty and does not display any logs
This happened for the primary (=admin) user of a fresh debian 10 install

I added myself to the adm group and also to the systemd-journal group:
$ groups daniel
daniel : daniel adm cdrom floppy sudo audio dip video plugdev systemd-journal
netdev bluetooth lpadmin scanner data


I can't reproduce this issue:

pi@raspberrypi ~ $ groups
pi adm dialout cdrom sudo audio video plugdev games users netdev
systemd-journal input spi gpio

pi@raspberrypi ~ $ ls -la /run/log/journal/
insgesamt 0
drwxr-sr-x  3 root systemd-journal  60 Jul  6 23:39 .
drwxr-xr-x  3 root root 60 Jul  6 23:39 ..
drwxr-s---+ 2 root systemd-journal 100 Jul 14 00:39
92e74c0bd699cc0d17d48ad852cc73e2

pi@raspberrypi ~ $ journalctl -f
-- Logs begin at Mon 2020-07-06 23:39:50 CEST. --
Jul 14 20:00:23 raspberrypi systemd[23434]: Reached target Sockets.
Jul 14 20:00:23 raspberrypi systemd[23434]: Reached target Paths.
Jul 14 20:00:23 raspberrypi systemd[23434]: Reached target Basic System.
Jul 14 20:00:23 raspberrypi systemd[1]: Started User Manager for UID 0.
Jul 14 20:00:23 raspberrypi systemd[23434]: Reached target Default.
Jul 14 20:00:23 raspberrypi systemd[23434]: Startup finished in 796ms.
Jul 14 20:00:23 raspberrypi systemd[1]: Started Session c8 of user root.
Jul 14 20:00:58 raspberrypi gpasswd[23485]: user pi added by root to
group systemd-journal
Jul 14 20:01:01 raspberrypi su[23492]: (to pi) root on pts/1
Jul 14 20:01:01 raspberrypi su[23492]: pam_unix(su-l:session): session
opened for user pi by root(uid=0)


Are you using persistent journal or volatile journal?
What are the file permissions of the journal directory?

Bug#965045: REFCLOCK: refclock_newpeer: clock type 46 invalid

[Fernando Lucas]

Package: ntpsec
Version: 1.1.8+dfsg1-6
Severity: important

Dear Maintainer,

Is the refclock driver 46 (GSPD NG) included during the build process?
I have the error "REFCLOCK: refclock_newpeer: clock type 46 invalid" when 
trying to uses it.

Thanks



-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 
'oldstable-updates'), (500, 'unstable'), (400, 'stable'), (200, 'oldstable'), 
(50, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages ntpsec depends on:
ii  adduser  3.118
ii  init-system-helpers  1.58
ii  libc62.30-8
ii  libcap2  1:2.36-1
ii  libssl1.11.1.1g-1
ii  lsb-base 11.1.0
ii  netbase  6.1
ii  python3  3.8.2-3
ii  python3-ntp  1.1.8+dfsg1-6
ii  tzdata   2020a-1

Versions of packages ntpsec recommends:
ii  cron [cron-daemon]  3.0pl1-136
ii  systemd 245.6-2

Versions of packages ntpsec suggests:
ii  apparmor   2.13.4-3
ii  certbot1.6.0-1
pn  ntpsec-doc 
pn  ntpsec-ntpviz  

-- Configuration Files:
/etc/apparmor.d/usr.sbin.ntpd changed [not included]
/etc/ntpsec/ntp.conf changed [not included]

-- no debconf information

Bug#961230: add patch

[Matthias Klose]

Control: tags -1 + patch

patch at
http://launchpadlibrarian.net/488576218/guile-2.2_2.2.7+1-5build1_2.2.7+1-5ubuntu1.diff.gz

Bug#960762: [Pkg-libvirt-maintainers] Bug#960762: libvirt: random (?) test hangs

[Andrea Bolognani]

On Fri, Jul 03, 2020 at 12:04:16AM +0200, Andrea Bolognani wrote:
> On Wed, Jul 01, 2020 at 09:24:00AM +0200, Guido Günther wrote:
> > On Tue, Jun 30, 2020 at 09:28:34PM +0200, Andrea Bolognani wrote:
> > > Has anyone managed to reproduce this? I've built 6.0.0-7 from source
> > > in a tight loop 100 times, both in a sid:i386 chroot via cowbuilder
> > > and in a sid:i386 VM, without encountering a single failure.
> > 
> > I tried to reproduce too when this came in and couldn't.
> 
> Okay, let's assume it was a temporary glitch then - at least until
> another build fails for the same reason.

We've made three uploads in a row now with zero issues on i386, so
at this point I would say it's fair to assume this one failure was
just a fluke. I vote for closing the bug and unblocking migrations
to testing.

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


signature.asc
Description: PGP signature

Bug#964986: buster-pu: package ksh/93u+20120801-3.4

[Anuradha Weeraman]

On Tue, Jul 14, 2020 at 06:16:30AM +0200, Salvatore Bonaccorso wrote:
> Small change is needed in the debdiff:
> 
> > diff -Nru ksh-93u+20120801/debian/changelog 
> > ksh-93u+20120801/debian/changelog
> > --- ksh-93u+20120801/debian/changelog   2018-12-14 02:26:58.0 
> > -0500
> > +++ ksh-93u+20120801/debian/changelog   2020-07-12 11:26:07.0 
> > -0400
> > @@ -1,3 +1,15 @@
> > +ksh (93u+20120801-4+deb10u1) buster-security; urgency=high
>  
> The target distribution would need to be 'buster' in this case of the
> upload for the point release.

Noted, thanks, will consider along with any input from the release team.

Anuradha

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

[Rahulkrishnan R A]

Package: wnpp
Severity: wishlist
Owner: 'Rahulkrishnan R A' 

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


This Package implements the LightStep OpenTracing client for Go.

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

[Graweeld - (grwd)]

Package: gnome-podcasts

RFP
Severity: wishlist

A simple, and responsive podcast feed player for the GNOME desktop.

License: GPL

Source: https://gitlab.gnome.org/World/podcasts#contributing

P.S. A package for the aarch64 would be also very neat. Much thanks!

Marek Ľach, Bc.

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

[jspricke]

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

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

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

Or would there be a better way?


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

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

I uploaded the new version.

Cheers Jochen


signature.asc
Description: PGP signature

Bug#964438: apt-listbugs: dns error when running from cron job

[Francesco Poli]

On Tue, 14 Jul 2020 10:36:23 +0200 Oswald Buddenhagen wrote:

> On Mon, Jul 13, 2020 at 11:25:21PM +0200, Francesco Poli wrote:
> >I haven't found a satisfying strategy to get what I wanted.
> >
> ok, fair enough. please make sure the maintainers know about this 
> requirement if you haven't done so yet.

That's a sensible suggestion: unfortunately, I haven't yet got around
to it.
But I would love to see the mechanism more implemented on the systemd
side, and less on the script side...

> 
> >Could it be that the timer was just about to be triggered, when the
> >machine woke up?
> >
> that's implausible, because the suspensions and wakeups are essentially 
> random (measured against "your" schedule), while the problem appears 
> with utter regularity (whenever the wakeup happens on the next day, as 
> defined by your mechanism).

Do you mean that your "no network when apt-listbugs timer runs" only
happens immediately after a wake-up from a suspended state and only
when the system has had no chance to run the timer between 7:00 a.m.
and the wake-up itself?

If this is the case, then I apologize for not understanding before!

Since I do not use any suspend mechanism on my boxes, this could well
explain why I do not experience the same issue...

[...]
> here's a log of the wakeup:
> 
[...]
> Jul 14 09:53:46 ugly systemd-sleep[789697]: System resumed.
> Jul 14 09:53:46 ugly kernel: Restarting tasks ... done.
> Jul 14 09:53:46 ugly kernel: PM: suspend exit
> Jul 14 09:53:46 ugly systemd[1]: Starting Daily apt upgrade and clean 
> activities...
> Jul 14 09:53:46 ugly systemd[1]: Starting Daily apt-listbugs preferences 
> cleanup...
[...]
> Jul 14 09:53:47 ugly systemd[1]: apt-listbugs.service: Succeeded.
> Jul 14 09:53:47 ugly systemd[1]: Finished Daily apt-listbugs preferences 
> cleanup.
> Jul 14 09:53:50 ugly kernel: e1000e :00:19.0 eth0: NIC Link is Up 1000 
> Mbps Full Duplex, Flow Control: Rx/Tx
[...]
> Jul 14 09:53:51 ugly dhclient[1005]: DHCPDISCOVER on eth0 to 255.255.255.255 
> port 67 interval 8
> Jul 14 09:53:51 ugly dhclient[1005]: DHCPOFFER of 192.168.178.20 from 
> 192.168.178.1
> Jul 14 09:53:51 ugly dhclient[1005]: DHCPREQUEST for 192.168.178.20 on eth0 
> to 255.255.255.255 port 67
> Jul 14 09:53:51 ugly dhclient[1005]: DHCPACK of 192.168.178.20 from 
> 192.168.178.1
[...]

Well, it really looks like the apt-listbugs timer is run before the
network is brought up again.

> 
> today's fail-mail is dated '14 Jul 2020 09:53:47 +0200'.

And I suppose /var/spool/apt-listbugs/lastprefclean modification time
is somewhat later, between 10:20 and 10:40 a.m.

> 
> >If you do not reply to my questions, I will not be able to investigate
> >and I will have no other choice than closing this bug report as
> >unreproducible...
> >
> i think i'm quite capable of judging what's relevant in cases like this, 
> so don't make it too easy for yourself to dismiss the issue. ;)

No offense was intended: I was just saying that replying to questions
may (sometimes) help in understanding the issue and in investigating
the cause...


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


pgpJKuGS76HrC.pgp
Description: PGP signature

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

[Kurt Roeckx]

On Tue, Jul 14, 2020 at 06:22:50PM +0100, Dimitri John Ledkov wrote:
> Package: libssl3
> Version: 3.0.0~~alpha4-1
> Severity: important
> 
> Dear Maintainer,
> 
> Please stop building legacy provider. None of the algorithms it
> provides are useful, or needed at all.
> 
> Please do not not build it nor ship it. Those who need to access that,
> can self build that code.
> 
> Alternatively you may choose to provide legacy provider in a separate
> binary package, but imho it must not enter testing or stable releases.

Applications that want to use the legacy provider will need to
get changed to load them. By default the algorithms will not be
available.

I'm not sure that not shipping the file improves anything.


Kurt

Bug#964926: systemd: systemctl show prints "Failed to parse bus message: Invalid argument" before output

[Michael Biebl]

Control: tags -1 + fixed-upstream
Control: forwarded -1 https://github.com/systemd/systemd/pull/16424

Am 14.07.20 um 22:13 schrieb Hugh Cole-Baker:
> It turns out this is just caused by running a 5.8-rc kernel with systemd
> compiled against linux-libc-dev 5.7, there's a new capability cap_bpf
> that systemctl fails to display since it's not in linux/capability.h.
> 
> The same issue is described here, with a link to the upstream fix:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1853736

Thanks, marking the bug report accordingly.




signature.asc
Description: OpenPGP digital signature

Bug#963628: [Pkg-javascript-devel] Bug#963628: Bug#963628: Node-jest fails with: Error: Cannot find module 'import-local'

[Xavier]

Le 14/07/2020 à 22:06, Xavier a écrit :
> Le 28/06/2020 à 09:32, Xavier a écrit :
>> Control: severity -1 grave
>>
>> Le 27/06/2020 à 23:31, Nilesh Patra a écrit :
>>>
>>>
>>> On Sun, 28 Jun 2020, 02:45 Xavier, >> > wrote:
>>>
>>> Control: severity -i grave
>>>
>>>
>>> Thanks.
>>>
>>>
>>> Le 24/06/2020 à 21:18, Nilesh Patra a écrit :
>>> > Package: node-jest
>>> > Severity: serious
>>> >
>>> > Dear Maintainer,
>>> >
>>> > Node-jest fails with the following on all the node-modules I've
>>> tried yet.
>>> > Sample examples on
>>>
>>> Work needed for node-jest:
>>>  * add babel-plugin-istanbul; proposition: add it in node-babel7
>>>
>>>
>>> It's good.
>>> Would you mind discussing this bit on the list?
>>
>> pkg-js list receives messages related to this bug
>>
>>>  * update and fix node-jsdom
>>>  * add missing components
>>>
>>>
>>> Noted.
>>>
>>>
>>> Here is the list of missing modules (mix of node-jest and node-jsdom):
>>
>> jsdom:
>>  * data-urls
>>  * domexception
>>  * html-encoding-sniffer
>>  * w3c-hr-time
>>  * whatwg-encoding
>>  * whatwg-mimetype
>>  * whatwg-url
>>  * xml-name-validator
> 
> Hi all,
> 
> after fixing node-jsdom, these modules are required for jest:
>  * astral-regex
>  * babel-plugin-istanbul
>  * babel-preset-current-node-syntax
>  * fast-json-stable-stringify
>  * is-generator-fn
>  * makeerror
>  * natural-compare
>  * p-each-series
>  * p-reduce
>  * sane
>  * string-length
>  * supports-hyperlinks
>  * terminal-link
>  * throat
>  * tmpl
>  * walker

+ import-local and realpath-native

> I suggests to embed babel* in node-babel7 and others in node-jest. What
> are your advises ?
> 

Bug#965042: kdenlive: Should suggest vlc or xine-ui

[Jacob Kauffmann]

Package: kdenlive
Version: 20.04.3-1
Severity: wishlist

Dear Maintainer,

Kdenlive requires either VLC or Xine in order to preview a created .iso DVD
image. You can observe this requirement by:

1. Installing Kdenlive on a fresh system (without vlc or xine-ui installed)
2. Navigate to File -> DVD Wizard and proceed through the first three pages of
the wizard
3. On the final page of the wizard (Creating DVD Image), click "Create ISO
image"
4. Click the "Preview" button

If neither of these applications are installed, Kdenlive shows a dialog box
stating that "Previewing requires one of these applications (xine,vlc)".

It makes sense not to have the kdenlive package depend on or recommend either
of these packages, since DVD image previewing is a less-than-prominent feature
of Kdenlive, and Kdenlive handles the lack of these programs well by displaying
a dialog box. However, it seems semantically correct to have the kdenlive
package suggest vlc or xine-ui since they can "enhance its usefulness," as
section 7.2 of the Debian policy manual puts it.

I would suggest "vlc | xine-ui" since VLC is already more popular than xine-ui
according to popcon and shows a simpler interface the first time it's started,
although "xine-ui | vlc" would also be an improvement over no suggestions.



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

Versions of packages kdenlive depends on:
ii  ffmpeg 7:4.3-3
ii  gstreamer1.0-plugins-bad   1.16.2-2.1+b1
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.30-8
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-1
ii  libkf5coreaddons5  5.70.0-1
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.20.0-2+b1
ii  libmlt66.20.0-2+b1
ii  libqt5concurrent5  5.14.2+dfsg-4
ii  libqt5core5a   5.14.2+dfsg-4
ii  libqt5dbus55.14.2+dfsg-4
ii  libqt5gui5 5.14.2+dfsg-4
ii  libqt5multimedia5  5.14.2-2
ii  libqt5network5 5.14.2+dfsg-4
ii  libqt5qml5 5.14.2+dfsg-2
ii  libqt5quick5   5.14.2+dfsg-2
ii  libqt5quickcontrols2-5 5.14.2+dfsg-2
ii  libqt5quickwidgets55.14.2+dfsg-2
ii  libqt5svg5 5.14.2-2
ii  libqt5webkit5  5.212.0~alpha4-4
ii  libqt5widgets5 5.14.2+dfsg-4
ii  libqt5xml5 5.14.2+dfsg-4
ii  librttr-core0.9.6  0.9.6+dfsg1-3
ii  libstdc++6 10.1.0-4
ii  melt   6.20.0-2+b1
ii  qml-module-qtgraphicaleffects  5.14.2-2
ii  qml-module-qtqml-models2   5.14.2+dfsg-2
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-2
ii  qml-module-qtquick-window2 5.14.2+dfsg-2
ii  qml-module-qtquick25.14.2+dfsg-2

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  

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

[Thorsten Glaser]

Michael Meskes dixit:

>> >Could you please elaborate what (n)cal miss? "ncal -w" does give you
>> >week numbers
>>
>> But which ones? American? German? ISO? (Turns out the latter two are
>
>Depends on the locale you use.

The locale doesn’t contain enough information to calculate calendar weeks:
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap07.html

There’s neither a data field for the first day of the week, nor one for
the various ways to calculate a calendar week.

>No idea what you are saying, sorry, please elaborate.

There are multiple ways to calculate calendar weeks, see above.

>> I understand if you find this too bothersome to do in Debian for
>> such a (corner?) case, but that is why this is of wishlist severity
>> ;)
>
>Na, the problem is understanding what's missing, or wrong. :)

I think that while ncal may be a usable provider for cal, it’s not
suitable in all situations whereas the other implementation has its
benefit in some of these (but on the other hand lacking in cases
ncal supports) so we maybe should just have both?

Currently I just install kwal and call it as kwal, but with ncal
now being its separate package I just don’t need to install it any
more. This leaves cal(1) unprovided though so I came to consider
alternatives for it. Of course I could locally symlink it, but that
doesn’t scale, and Conflicts isn’t useful either so I can’t add the
symlinks to the kwal package.

In the end I just need a reliable way to get at German (= ISO)
calendar weeks, for use in business environments, and found that,
rather than having to write code myself, I could use OpenBSD’s cal,
which has an option for specifically this (although only for years
1753‥, same as ncal).

bye,
//mirabilos
-- 
(gnutls can also be used, but if you are compiling lynx for your own use,
there is no reason to consider using that package)
-- Thomas E. Dickey on the Lynx mailing list, about OpenSSL

Bug#963628: [Pkg-javascript-devel] Bug#963628: Bug#963628: Node-jest fails with: Error: Cannot find module 'import-local'

[Xavier]

Le 28/06/2020 à 09:32, Xavier a écrit :
> Control: severity -1 grave
> 
> Le 27/06/2020 à 23:31, Nilesh Patra a écrit :
>>
>>
>> On Sun, 28 Jun 2020, 02:45 Xavier, > > wrote:
>>
>> Control: severity -i grave
>>
>>
>> Thanks.
>>
>>
>> Le 24/06/2020 à 21:18, Nilesh Patra a écrit :
>> > Package: node-jest
>> > Severity: serious
>> >
>> > Dear Maintainer,
>> >
>> > Node-jest fails with the following on all the node-modules I've
>> tried yet.
>> > Sample examples on
>>
>> Work needed for node-jest:
>>  * add babel-plugin-istanbul; proposition: add it in node-babel7
>>
>>
>> It's good.
>> Would you mind discussing this bit on the list?
> 
> pkg-js list receives messages related to this bug
> 
>>  * update and fix node-jsdom
>>  * add missing components
>>
>>
>> Noted.
>>
>>
>> Here is the list of missing modules (mix of node-jest and node-jsdom):
> 
> jsdom:
>  * data-urls
>  * domexception
>  * html-encoding-sniffer
>  * w3c-hr-time
>  * whatwg-encoding
>  * whatwg-mimetype
>  * whatwg-url
>  * xml-name-validator

Hi all,

after fixing node-jsdom, these modules are required for jest:
 * astral-regex
 * babel-plugin-istanbul
 * babel-preset-current-node-syntax
 * fast-json-stable-stringify
 * is-generator-fn
 * makeerror
 * natural-compare
 * p-each-series
 * p-reduce
 * sane
 * string-length
 * supports-hyperlinks
 * terminal-link
 * throat
 * tmpl
 * walker

I suggests to embed babel* in node-babel7 and others in node-jest. What
are your advises ?

Bug#964926: systemd: systemctl show prints "Failed to parse bus message: Invalid argument" before output

[Hugh Cole-Baker]

It turns out this is just caused by running a 5.8-rc kernel with systemd
compiled against linux-libc-dev 5.7, there's a new capability cap_bpf
that systemctl fails to display since it's not in linux/capability.h.

The same issue is described here, with a link to the upstream fix:

https://bugzilla.redhat.com/show_bug.cgi?id=1853736

Bug#965026: grub-emu is unusable with orca nor BRLTTY

[Patrick ZAJDA]

Package: grub-emu
Version: 2.02+dfsg1-20
Severity: critical
Tags: a11y
Justification: breaks the whole system

Dear Maintainer,

I use Debian with Orca and BRLTTY and executed grub-emu.
When ran on mate-terminal, it shows an interface where BRLTTY displays "Screen 
not in text mode" and Orca doesn't speak at all.
The only solution to stop it is to killall -9 grub-emu from another terminal.

The most critical situation is when I run grub-emu from a TTY session. In this 
case, BRLTTY displays again "Screen not in text mode" and my system locked, I 
was not able to close grub-emu nor to use another TTY to kill it.
The only solution I found to reboot correctly was use SSH.

-- Package-specific info:

*** BEGIN /proc/mounts
/dev/nvme0n1p3 / ext4 rw,noatime,nodiratime,errors=remount-ro 0 0
/dev/nvme0n1p2 /boot ext2 rw,noatime,nodiratime 0 0
/dev/sda4 /var/vm ext4 rw,noatime,nodiratime,quota,usrquota,grpquota 0 0
/dev/nvme0n1p1 /boot/efi vfat 
rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
 0 0
/dev/sdb1 /home ext4 rw,relatime,quota,usrquota,grpquota 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="${saved_entry}"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_gpt
insmod ext2
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root  c520d8e3-9caa-45e3-9dc0-664205763df9
else
  search --no-floppy --fs-uuid --set=root c520d8e3-9caa-45e3-9dc0-664205763df9
fi
font="/usr/share/grub/unicode.pf2"
fi

if loadfont $font ; then
  set gfxmode=auto
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set lang=fr_FR
  insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
  set timeout=30
else
  if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=1
  # Fallback normal timeout code in case the timeout_style feature is
  # unavailable.
  else
set timeout=1
  fi
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu 
--class os $menuentry_id_option 
'gnulinux-simple-c520d8e3-9caa-45e3-9dc0-664205763df9' {
savedefault
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod ext2
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root  
1891f72e-62a2-4314-98c7-79626e392794
else
  search --no-floppy --fs-uuid --set=root 
1891f72e-62a2-4314-98c7-79626e392794
fi
echo'Chargement de Linux 5.6.0-0.bpo.2-amd64…'
linux   /vmlinuz-5.6.0-0.bpo.2-amd64 
root=UUID=c520d8e3-9caa-45e3-9dc0-664205763df9 ro  splash splash
echo'Chargement du disque mémoire initial…'
initrd  /initrd.img-5.6.0-0.bpo.2-amd64
}
submenu 'Options avancées pour Debian GNU/Linux' $menuentry_id_option 
'gnulinux-advanced-c520d8e3-9caa-45e3-9dc0-664205763df9' {
menuentry 'Debian GNU/Linux, avec Linux 5.6.0-0.bpo.2-amd64' --class 
debian --class gnu-linux --class gnu --class os $menuentry_id_option 
'gnulinux-5.6.0-0.bpo.2-amd64-advanced-c520d8e3-9caa-45e3-9dc0-664205763df9' {
savedefault
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; 
fi
insmod part_gpt
insmod ext2
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root  
1891f72e-62a2-4314-98c7-79626e392794
else
  search --no-floppy --fs-uuid --set=root 

Bug#965041: libssl3: Please stop building legacy provider

[Dimitri John Ledkov]

Package: libssl3
Version: 3.0.0~~alpha4-1
Severity: important

Dear Maintainer,

Please stop building legacy provider. None of the algorithms it
provides are useful, or needed at all.

Please do not not build it nor ship it. Those who need to access that,
can self build that code.

Alternatively you may choose to provide legacy provider in a separate
binary package, but imho it must not enter testing or stable releases.

Regards,

Dimitri.

Bug#965040: singularity-container: CVE-2020-13845 CVE-2020-13846 CVE-2020-13847

[Salvatore Bonaccorso]

Source: singularity-container
Version: 3.5.2+ds1-1
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: Debian Security Team 

Hi,

The following vulnerabilities were published for singularity-container.

CVE-2020-13845[0]:
| Sylabs Singularity 3.0 through 3.5 has Improper Validation of an
| Integrity Check Value. Image integrity is not validated when an ECL
| policy is enforced. The fingerprint required by the ECL is compared
| against the signature object descriptor(s) in the SIF file, rather
| than to a cryptographically validated signature.


CVE-2020-13846[1]:
| Sylabs Singularity 3.5.0 through 3.5.3 fails to report an error in a
| Status Code.


CVE-2020-13847[2]:
| Sylabs Singularity 3.0 through 3.5 lacks support for an Integrity
| Check. Singularity's sign and verify commands do not sign metadata
| found in the global header or data object descriptors of a SIF file.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-13845
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-13845
[1] https://security-tracker.debian.org/tracker/CVE-2020-13846
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-13846
[2] https://security-tracker.debian.org/tracker/CVE-2020-13847
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-13847

Regards,
Salvatore

Bug#965027: 回复：Bug#965027: libreoffice-impress: libreoffice impress crashes when dragging image inserted

[Junyue]

6.4.5-1 works good on my mips64el stable.thanks!
sorry not quite familiar with how to report bug.

On 2020/7/14 下午2:20, Rene Engelhard wrote:

[ please
   a) use proper mail quoting, and don't fullquote
   b) Cc the bug itherwise stuff doesn't get recorded
]

Hi,

On Wed, Jul 15, 2020 at 02:14:33AM +0800, Junyue Wang 王寯越 wrote:

As you see in the screenshot, an image was inserted in a slide, if I click
and try to drag the image, the libreoffice will crash, and a file recovery
dialog will come out saying: due to accidental error, libreoffice crashed.
All files you are working on will be saved. Next time libreoffice starts
your files will be recovered automatically.
The output of terminal is:
(soffice:32472): GLib-GObject-CRITICAL **: 14:02:47.310:
g_object_get_data: assertion 'G_IS_OBJECT (object)' failed


You did not even answer my question.

Please try a uptodate version.

I am not going to deal with 6.1.5 on mips64el.
[ And: There's no mips64el machine at hand with GUI to even be able to try
(and no sane way to have it emulated). ]

Regards,

Rene

Bug#963808: ruby-sanitize: CVE-2020-4054: HTML sanitization bypass in Sanitize

[Salvatore Bonaccorso]

Hi Antonio,

On Tue, Jul 14, 2020 at 09:41:21AM -0300, terce...@debian.org wrote:
> On Mon, Jul 13, 2020 at 10:04:10PM +0200, Salvatore Bonaccorso wrote:
> > Hi Antonio,
> > 
> > On Mon, Jul 13, 2020 at 11:19:38AM -0300, terce...@debian.org wrote:
> > > On Sun, Jul 12, 2020 at 03:11:30PM +0200, Salvatore Bonaccorso wrote:
> > > > On Sat, Jun 27, 2020 at 09:10:01PM +0200, Salvatore Bonaccorso wrote:
> > > > > Source: ruby-sanitize
> > > > > Version: 4.6.6-2
> > > > > Severity: grave
> > > > > Tags: security upstream
> > > > > Justification: user security hole
> > > > > 
> > > > > Hi,
> > > > > 
> > > > > The following vulnerability was published for ruby-sanitize.
> > > > > 
> > > > > CVE-2020-4054[0]:
> > > > > | In Sanitize (RubyGem sanitize) greater than or equal to 3.0.0 and 
> > > > > less
> > > > > | than 5.2.1, there is a cross-site scripting vulnerability. When HTML
> > > > > | is sanitized using Sanitize's "relaxed" config, or a custom config
> > > > > | that allows certain elements, some content in a math or svg element
> > > > > | may not be sanitized correctly even if math and svg are not in the
> > > > > | allowlist. You are likely to be vulnerable to this issue if you use
> > > > > | Sanitize's relaxed config or a custom config that allows one or more
> > > > > | of the following HTML elements: iframe, math, noembed, noframes,
> > > > > | noscript, plaintext, script, style, svg, xmp. Using carefully 
> > > > > crafted
> > > > > | input, an attacker may be able to sneak arbitrary HTML through
> > > > > | Sanitize, potentially resulting in XSS (cross-site scripting) or 
> > > > > other
> > > > > | undesired behavior when that HTML is rendered in a browser. This has
> > > > > | been fixed in 5.2.1.o
> > > > 
> > > > Attached ist a preliminary debdiff with the fix, but two prerequisites
> > > > before "fix: Don't treat :remove_contents as `true` when it's an
> > > > Array" and "feat: Remove useless filtered element content by default".
> > > > 
> > > > Antonio, would it be possible to let it go trough your second pair of
> > > > eyes, with the pre-knolege that I'm not familiar with the package but
> > > > trying to address the CVE-2020-4054.
> > > > 
> > > > If those look correct, the plan would be to do 4.6.6-2.1~deb10u1 based
> > > > on that for buster-security.
> > > 
> > > Yes, those patches look OK.
> > > 
> > > Thanks for your work.
> > 
> > Thanks for your review! So propsing to upload the NMU first, and then
> > later handle the DSA for it based on that version if no negative
> > reports come in.
> 
> Sure, just do it.

NMU done (in delayed queue). Will try to have later an eye on the
reports but if you notice something odd just let me know.

Regards,
Salvatore

Bug#965039: platformio: not migrating to testing

[Reiner Herrmann]

Source: platformio
Version: 4.2.1-1

Dear maintainer,

thanks for bringing platformio into Debian!

Currently it is not migrating to testing, as it has been uploaded
as a binary upload. Can you please do a source-only upload to
allow it to migrate?

Thanks in advance!

Kind regards,
  Reiner


signature.asc
Description: PGP signature

Bug#965020: command-not-found: local variable 'cnf' referenced before assignment

[Curtis]

Package: command-not-found
Version: 18.04.5-1
Severity: important

Dear Maintainer,

After powering up my PureOS computer, after having been in sleep mode, I 
attempted to execute the "rox" command, knowing that I'd get a message if it 
wasn't installed.  I was presented with the following:

--
curtis@living-room-pc:~$ rox
Could not find the database of available applications, run 
update-command-not-found as root to fix this
Sorry, command-not-found has crashed! Please file a bug report at:
http://www.debian.org/Bugs/Reporting
Please include the following information with the report:

command-not-found version: 0.3
Python version: 3.7.3 final 0
Distributor ID: PureOS
Description:PureOS
Release:9.0
Codename:   amber
Exception information:

local variable 'cnf' referenced before assignment
Traceback (most recent call last):
  File "/usr/share/command-not-found/CommandNotFound/util.py", line 23, in 
crash_guard
callback()
  File "/usr/lib/command-not-found", line 93, in main
if not cnf.advise(args[0], options.ignore_installed) and not 
options.no_failure_msg:
UnboundLocalError: local variable 'cnf' referenced before assignment
--


-- System Information:
Distributor ID: PureOS
Description:PureOS
Release:9.0
Codename:   amber
Architecture: x86_64

Kernel: Linux 4.19.0-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA.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 command-not-found depends on:
ii  apt-file 3.2.2
ii  lsb-release  10.2019031300pureos1
ii  python3  3.7.3-1
ii  python3-apt  1.8.4pureos3

command-not-found recommends no packages.

Versions of packages command-not-found suggests:
ii  snapd  2.37.4-1+b1

-- no debconf information

Bug#961195: transition: glibc

[Emilio Pozuelo Monfort]

On 13/07/2020 21:39, Aurelien Jarno wrote:
> On 2020-07-13 20:43, Emilio Pozuelo Monfort wrote:
>> Control: tags -1 confirmed
>>
>> Hi Aurelien,
>>
>> On 13/07/2020 19:54, Aurelien Jarno wrote:
>>> On 2020-07-11 18:09, Emilio Pozuelo Monfort wrote:
 block 961195 with 955368 964223 964225 964226 964220 964227 964229 964231
 thanks
>>>
>>> Does it mean that we need to have those bugs fixed before starting the
>>> transition?
>>
>> No, I just wanted to get them in the BTS, as that would tell me at any given
>> time how many are still open.
> 
> Ok, thanks for the explanation. I'll upload fixes to the delayed queue
> to fix them.
> 
>>> Or can we start the transition and fix them at the same
>>> time?
>>
>> Yeah, let's go ahead and do that.
> 
> Ok, thanks. I have just uploaded the package to unstable.

It's built on all release architectures now. I have scheduled the binNMUs with
the --extra-depends on libc-bin as usual.

Cheers,
Emilio

Bug#965038: ITP: golang-github-alexcesaro-log -- Logging packages for Go (library)

[Francisco Vilmar Cardoso Ruviaro]

Package: wnpp
Severity: wishlist
Owner: Francisco Vilmar Cardoso Ruviaro 

* Package name: golang-github-alexcesaro-log
  Version : 0.0~git20150915.61e6862-1
  Upstream Author : Alexandre Cesaro 
* URL : https://github.com/alexcesaro/log
* License : Expat
  Programming Lang: Go
  Description : Logging packages for Go (library)

Package log provides a common interface for logging libraries.
.
This package contains:
 - buflog: provides a buffered logging class that accumulates logs in
   memory until the flush threshold is reached which release stored
   logs, the buffered logger then act as a normal logger.
 - golog: provides a customizable logging class which can be used as
   a standalone or as a building block for other loggers.
 - logtest: provides utilities for logging testing.
 - stdlog: provides simple and fast logging to the standard output
   (stdout) and is optimized for programs launched via a shell or cron.
Logger is a common interface for logging libraries.

Bug#965037: RM: vg [mips64el] -- ROM; mips64el is not supported by upstream

[Michael R. Crusoe]

Package: ftp.debian.org
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Thanks!

-BEGIN PGP SIGNATURE-

iQJGBAEBCgAwFiEEck1gkzcRPHEFUNdHPCZ2P2xn5uIFAl8OAdwSHGNydXNvZUBk
ZWJpYW4ub3JnAAoJEDwmdj9sZ+bieqMP/3aUixFCi/aBIM3gbrSVAP0hhxAhne1F
Dg2YyZDIdVWwMEVvp590OQ6IemOJnTLDgRapfoSULTs1IzAV0dyv7g5jHJKzNfyB
TI5NC03MBtBNB3koYxZjLcBePW92JuLiG23rHw5PA44ub/+qiqQTtAS0vHgk1qol
NDQPv8ew4AGRZA0m76vgCc9dNqHRwEWm2rOcj/LO1m1M/8Khxq9zaiaYVXAXWhub
Lw1GqhognFt88+Bzu7sMWjYbii0k9TzHYnfI/SBPfiyYe5xSCdOHpf/dMAtpvFH/
YyWGz7zjVHKGFppIaq0+CA3Y/3Xr1J0SHTHabG0CTWAxjBVeHroG60vbMoRm7dnM
y+EFouMVT6zsQWAhrC/IvZwWZihMytxWDq17tahIuXOiFP0zyIAro6vdHOewLH9W
JmFa/sQRJn7BS6uBBVgI0B0p8LYG4831JXCjIIdYgBPtY6Bg4w8thcVkZ+oiVDE7
U+pwc/qXQW0nG6/g18ETagKcktrHsPl7ldxERjM8oh3DiEbEyLUTIs348fGE5h7t
fPn00oCWdHteacEa4Tsk49PlGlyfG+0L+wf4bft7INsTHiF1eSUUmCU9H/U0dle7
7uIls8XZVKbdZZ7Wt/yij5y36lnys2+xrcUdkIALv4hiERe8umhDfyTSusbsox/Z
xDftUXPWv4Yz
=H4l7
-END PGP SIGNATURE-

Bug#965036: RM: mapbox-geometry -- ROM; Obsolete

[Bas Couwenberg]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: pkg-grass-de...@lists.alioth.debian.org
Control: block -1 by 965035

Please remove mapbox-geometry from the archive, it's obsolete.

Kind Regards,

Bas

Bug#965027: 回复：Bug#965027: libreoffice-impress: libreoffice impress crashes when dragging image inserted

[Rene Engelhard]

[ please
  a) use proper mail quoting, and don't fullquote
  b) Cc the bug itherwise stuff doesn't get recorded
]

Hi,

On Wed, Jul 15, 2020 at 02:14:33AM +0800, Junyue Wang 王寯越 wrote:
>As you see in the screenshot, an image was inserted in a slide, if I click
>and try to drag the image, the libreoffice will crash, and a file recovery
>dialog will come out saying: due to accidental error, libreoffice crashed.
>All files you are working on will be saved. Next time libreoffice starts
>your files will be recovered automatically. 
>The output of terminal is:
>(soffice:32472): GLib-GObject-CRITICAL **: 14:02:47.310:
>g_object_get_data: assertion 'G_IS_OBJECT (object)' failed

You did not even answer my question.

Please try a uptodate version.

I am not going to deal with 6.1.5 on mips64el.
[ And: There's no mips64el machine at hand with GUI to even be able to try
(and no sane way to have it emulated). ]

Regards,

Rene

Bug#965035: RM: mapbox-wagyu -- ROM; Obsolete

[Bas Couwenberg]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: pkg-grass-de...@lists.alioth.debian.org

Please remove mapbox-wagyu from the archive, it's obsolete.

Kind Regards,

Bas

Bug#965023: transition: re2

[Sebastian Ramacher]

Control: forwarded -1 
https://release.debian.org/transitions/html/auto-protobuf.html

On 2020-07-14 08:29:21 -0700, Stefano Rivera wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Public ABI Breakage:
> An entry was inserted into an enum, rather than appended to the end.
> 
> Public API Breakage:
> None
> 
> Reverse Dependencies:
> * dnsdist seems to have had uninstallable Build-Dependencies, in my testing
>   yesterday, but built fine on the 5th.

dnsdist is currently involved in the protobuf transition, so this may
have been a temporary issue. But let's wait until protobuf migrated to
not entagle these two transitions.

Cheers

> * Everything else builds without error.
> 
> Ben file:
> 
> title = "re2";
> is_affected = .depends ~ "libre2-7" | .depends ~ "libre2-8";
> is_good = .depends ~ "libre2-8";
> is_bad = .depends ~ "libre2-7";
> 
> https://release.debian.org/transitions/html/auto-re2.html LGTM
> 
> SR
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#965034: snmpd: Default not sourced, SNMPDOPTS not changed, 'ia_addr' error resurrected

[Alessandro Vesely]

Package: snmpd
Version: 5.7.3+dfsg-5
Severity: normal

Dear Debian Maintainer,

after upgrading to Beowulf, daemon.log gets filled with these:

Jul 14 18:31:46 31 north snmpd[27013]: error on subcontainer 'ia_addr' insert 
(-1)
Jul 14 18:31:46 31 north snmpd[27013]: error on subcontainer 'ia_addr' insert 
(-1)
Jul 14 18:31:46 31 north snmpd[27013]: error on subcontainer 'ia_addr' insert 
(-1)
Jul 14 18:31:46 31 north snmpd[27013]: error on subcontainer 'ia_addr' insert 
(-1)
Jul 14 18:31:46 31 north snmpd[27013]: error on subcontainer 'ia_addr' insert 
(-1)
Jul 14 18:31:46 31 north snmpd[27013]: error on subcontainer 'ia_addr' insert 
(-1)
Jul 14 18:31:46 31 north snmpd[27013]: error on subcontainer 'ia_addr' insert 
(-1)
[...]

It is an old bug, with a known "solution" consisting in lowering the log level.

However, the original init.d/snmpd must have been changed, so that 
/etc/default/snmpd 
does not get sourced.  Hence the logs.

I just changed /etc/init.d/snmpd (lazy me).

-- System Information:
Distributor ID: Debian
Description:Devuan GNU/Linux 3 (beowulf)
Release:3
Codename:   beowulf
Architecture: x86_64

Kernel: Linux 4.19.0-9-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages snmpd depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.71
ii  libc6  2.28-10
ii  libmariadb31:10.3.22-0+deb10u1
ii  libsnmp-base   5.7.3+dfsg-5
ii  libsnmp30  5.7.3+dfsg-5
ii  libssl1.1  1.1.1d-0+deb10u3
ii  lsb-base   10.2019051400
ii  zlib1g 1:1.2.11.dfsg-1

snmpd recommends no packages.

Versions of packages snmpd suggests:
pn  snmptrapd  

-- Configuration Files:
/etc/default/snmpd changed:
export MIBS=
SNMPDRUN=yes
SNMPDOPTS='-LS6d -Lf /dev/null -u snmp -g snmp -I 
-smux,mteTrigger,mteTriggerConf -p /run/snmpd.pid'

/etc/init.d/snmpd changed:
if [ true != "$INIT_D_SCRIPT_SOURCED" ] ; then
set "$0" "$@"; INIT_D_SCRIPT_SOURCED=true . /lib/init/init-d-script
fi
DESC="SNMP Services"
DAEMON=/usr/sbin/snmpd
PIDFILE="/run/snmpd.pid"
OLD_MIBS_DIR="/usr/share/mibs/site:/usr/share/snmp/mibs:/usr/share/mibs/iana:/usr/share/mibs/ietf:/usr/share/mibs/netsnmp"
MIBS_DIR="/usr/share/snmp/mibs:/usr/share/snmp/mibs/iana:/usr/share/snmp/mibs/ietf"
export MIBDIRS="$MIBS_DIR:$OLD_MIBS_DIR"
DEFAULT_SNMPDOPTS="-Ls6d -Lf /dev/null -u Debian-snmp -g Debian-snmp -I 
-smux,mteTrigger,mteTriggerConf"
[ -z "$SNMPDOPTS" ] && SNMPDOPTS=$DEFAULT_SNMPDOPTS
DAEMON_ARGS="$SNMPDOPTS -p $PIDFILE"
do_start_prepare()
{
# remove old symlink with previous version
if [ -L /var/run/agentx ]; then
rm -f /var/run/agentx
fi
if [ ! -d /var/run/agentx ]; then
mkdir -p /var/run/agentx
fi
}

/etc/snmp/snmpd.conf [Errno 13] Permission denied: '/etc/snmp/snmpd.conf'
/etc/snmp/snmptrapd.conf [Errno 13] Permission denied: 
'/etc/snmp/snmptrapd.conf'

-- debconf information:
  snmpd/upgradefrom36:
  snmpd/upgradefrom521:

Bug#965028: systemd: journalctl does not work for normal users at all

[Michael Biebl]

Control: tags -1 + moreinfo unreproducible

Am 14.07.20 um 18:50 schrieb Daniel Blaschke:
> Package: systemd
> Version: 241-7~deb10u4
> Severity: important
> 
> Dear Maintainer,
> 
> $ journalctl
> Hint: You are currently not seeing messages from other users and the system.
>   Users in the 'systemd-journal' group can see all messages. Pass -q to
>   turn off this notice.
> No journal files were opened due to insufficient permissions.
> 
> 
> therefore, gnome-logs is empty and does not display any logs
> This happened for the primary (=admin) user of a fresh debian 10 install
> 
> I added myself to the adm group and also to the systemd-journal group:
> $ groups daniel
> daniel : daniel adm cdrom floppy sudo audio dip video plugdev systemd-journal
> netdev bluetooth lpadmin scanner data

I can't reproduce this issue:

pi@raspberrypi ~ $ groups
pi adm dialout cdrom sudo audio video plugdev games users netdev
systemd-journal input spi gpio

pi@raspberrypi ~ $ ls -la /run/log/journal/
insgesamt 0
drwxr-sr-x  3 root systemd-journal  60 Jul  6 23:39 .
drwxr-xr-x  3 root root 60 Jul  6 23:39 ..
drwxr-s---+ 2 root systemd-journal 100 Jul 14 00:39
92e74c0bd699cc0d17d48ad852cc73e2

pi@raspberrypi ~ $ journalctl -f
-- Logs begin at Mon 2020-07-06 23:39:50 CEST. --
Jul 14 20:00:23 raspberrypi systemd[23434]: Reached target Sockets.
Jul 14 20:00:23 raspberrypi systemd[23434]: Reached target Paths.
Jul 14 20:00:23 raspberrypi systemd[23434]: Reached target Basic System.
Jul 14 20:00:23 raspberrypi systemd[1]: Started User Manager for UID 0.
Jul 14 20:00:23 raspberrypi systemd[23434]: Reached target Default.
Jul 14 20:00:23 raspberrypi systemd[23434]: Startup finished in 796ms.
Jul 14 20:00:23 raspberrypi systemd[1]: Started Session c8 of user root.
Jul 14 20:00:58 raspberrypi gpasswd[23485]: user pi added by root to
group systemd-journal
Jul 14 20:01:01 raspberrypi su[23492]: (to pi) root on pts/1
Jul 14 20:01:01 raspberrypi su[23492]: pam_unix(su-l:session): session
opened for user pi by root(uid=0)


Are you using persistent journal or volatile journal?
What are the file permissions of the journal directory?



signature.asc
Description: OpenPGP digital signature

Bug#955271: libreoffice-common: AppArmor profile blocks gpg's tofu.db, causes hang opening Options

[Rene Engelhard]

user pkg-apparmor-t...@lists.alioth.debian.org

usertag - buggy-profile
thanks

Hi,

Am 14.07.20 um 17:13 schrieb John Scott:
> I think there's a misunderstanding. I realize with no GnuPG 2
> abstraction it's
> not your job to work around this. The usertag 'buggy-profile' merely 
> indicates 
> that it is an issue caused by AppArmor, not that you're responsible to fix 
> it. 
> Please see their usertag definitions [1].

Except that it says "buggy-profile". That's enough to have me not want
it as a tag. There is no buggy profile here.

It simply doesn't allow non-default config. AppArmor allows only
explicitely allowed stuff, and you can't simply allow anything as that
would defeat the sense of apparmor.

And especially for gpg which is security-sensitive

So it's the job or whoever set tofu as trust model for whatever reason
to fix it ;-)

Regards,


Rene

Bug#965033: meson: Missing dependency on python3-pkg-resources

[Adrian Bunk]

Package: meson
Version: 0.55.0-1
Severity: serious
Tags: ftbfs
Control: affects -1 src:systemd

$ meson
Traceback (most recent call last):
  File "/usr/bin/meson", line 17, in 
from mesonbuild import mesonmain
  File "/usr/lib/python3/dist-packages/mesonbuild/mesonmain.py", line 25, in 

from . import mconf, mdist, minit, minstall, mintro, msetup, mtest, 
rewriter, msubprojects, munstable_coredata, mcompile
  File "/usr/lib/python3/dist-packages/mesonbuild/mconf.py", line 16, in 

from . import coredata, environment, mesonlib, build, mintro, mlog
  File "/usr/lib/python3/dist-packages/mesonbuild/build.py", line 26, in 

from . import dependencies
  File "/usr/lib/python3/dist-packages/mesonbuild/dependencies/__init__.py", 
line 15, in 
from .boost import BoostDependency
  File "/usr/lib/python3/dist-packages/mesonbuild/dependencies/boost.py", line 
25, in 
from .base import DependencyException, ExternalDependency, 
PkgConfigDependency
  File "/usr/lib/python3/dist-packages/mesonbuild/dependencies/base.py", line 
32, in 
import pkg_resources
ModuleNotFoundError: No module named 'pkg_resources'
$

Bug#965027: libreoffice-impress: libreoffice impress crashes when dragging image inserted

[Rene Engelhard]

tag 965027 + moreinfo

thanks

Hi,

Am 14.07.20 um 18:11 schrieb junyue:
> After inserted an image into a slide in libreoffice impress, dragging the 
> image
> with the mouse will cause libreoffice impress to crash and exit, and then asks
> if want to recover the file. I have tried many times, it happens every time.

Please try with a non-ancient version?

7.0.0 rcX is not available yet for buster, but 6.4.5-1 is in
buster-backports.

(stable won't get any updates for this - except for RC bugs or real
important issues or security updates.)

Regards,


Rene

> Thanks!
>
>
>
> -- System Information:
> Debian Release: bullseye/sid
Erm? Then it should say "buster"
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')

... if you use stable.

What are you using really? At least your packages are stable, but...

> Architecture: mips64el (mips64)


Wow :)

Regards,

Rene

Bug#680148: python-pam: Please include python3 support

[Florian Best]

Dear Feri,

I would be interested in maintaining this package.
I am not yet a Debian Maintainer and don't yet know how to get one. But
I'll read about it.

Best regards
Florian

-- 
Florian Best
Open Source Software Engineer

Univention GmbH
be open.
Mary-Somerville-Str.1
28359 Bremen
Tel. : +49 421 22232-0
Fax : +49 421 22232-99

b...@univention.de
http://www.univention.de

Geschäftsführer: Peter H. Ganten
HRB 20755 Amtsgericht Bremen
Steuer-Nr.: 71-597-02876

Bug#965031: python3-numpy: please clarify the license for some files in debian/copyright

[Sandro Tosi]

> Please let me know,

feel free to reach out directly to upstream at
https://github.com/numpy/numpy/issues and bring your licence/copyright
concerns there.

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#965032: Obsolete Suggests on Python 2 packages

[Moritz Muehlenhoff]

Package: bcftools
Severity: normal

bcftools suggests python, python-numpy, python-matplotlib

python-matplotlib is already gone from the archive, python-numpy will be very 
soon
and eventuall python as well. The 1.7 release notes mention "Improve python3
compatibility in plotting scripts", so this can probably simply be replaced
with the python3 counterparts.

Cheers,
Moritzt

Bug#963669: RM: python-numpy -- ROM; python2-only; superseeded by src:numpy; no rdeps

[Moritz Mühlenhoff]

On Sat, Jul 11, 2020 at 11:06:20AM -0700, Sean Whitton wrote:
> Hello,
> 
> On Thu 09 Jul 2020 at 05:14PM -04, Sandro Tosi wrote:
> 
> > Hello FTP Masters,
> >
> > On Wed, Jun 24, 2020 at 11:57 PM Sandro Tosi  wrote:
> >>
> >> Package: ftp.debian.org
> >> Severity: normal
> >>
> >> cython has just been removed, and the remaining rdeps are not in testing 
> >> as RC
> >> for other reasons, so let's not wait on them
> >
> > can you please proceed with this removal? thanks!
> 
> Just to explain the hold up, since there are rdeps, it needs an ftp team
> member with python2 transition-specific knowledge to process the
> removal.  So it might take a bit longer.

See the breakdown below, TLDR: All remaining rdeps are already removed from
testing (sometimes for > 2 years) and 9/14 are already uninstallable or
FTBFS in unstable due to removed Py2 packages. As such, please let's go
ahead with the removal, this is inline how we've dealt with other rdeps
as well at this stage.

Cheers,
Moritz


snowball
-> Removed from testing since 2020-04-04
-> Already uninstallable due to python-opengl gone

brian
-> Removed from testing since 2017-10-28
-> Already FTBFS #948040, #876920

code-aster-run
-> Removed from testing since 2019-12-15

dipy
-> Removed from testing since 2017-01-14
-> FTBFS for a long time: #851048, #896620

python-neuroshare
-> Removed from testing since 2019-11-07
-> FTBFS due to python-sphinx, python-h5py gone already

openopt
-> Removed from testing since 2020-01-05
-> Already uninstallable due to python-setproctitle gone

ola
-> Removed from testing since 2019-09-07
-> Already uninstallable due to python-protobuf gone

unanimity
-> Removed from testing since 2019-10-21

pbgenomicconsensus
-> Removed from testing since 2019-09-23
-> Already uninstallable due to python-pytest gone

gnucap-python
-> Removed from testing since 2019-12-15

pd-py
-> Removed from testing since 2020-04-23

nipype
-> Removed from testing since 2019-08-20
-> Already uninstallable due to python-nibabel and several others gon

displaycal
-> Removed from testing since 2020-06-06

childsplay
-> Removed from testing since 2020-04-22
-> Already uninstallable due to python-sqlalchemy gone


  

Bug#965031: python3-numpy: please clarify the license for some files in debian/copyright

[Francesco Poli (wintermute)]

Package: python3-numpy
Version: 1:1.19.0-1
Severity: important

Hello and thanks for maintaining NumPy in Debian!

While reviewing the package debian/copyright file, I noticed
some files for which only the copyright holder seems to be
documented, but not the license.

These files are:
  numpy/core/src/umath/{reduction.c, ufunc_type_resolution.c
  numpy/core/src/umath/ufunc_object.c
  numpy/core/arrayprint.py
  numpy/core/src/multiarray/{arrayobject.c, usertypes.c}
  numpy/core/src/multiarray/multiarraymodule.c
  numpy/core/src/multiarray/{lowlevel_strided_loops.c.src, nditer_api.c,
 nditer_constr.c, nditer_pywrap.c, 
nditer_templ.c.src}
  numpy/core/src/multiarray/{array_assign_array.c, array_assign.c,
 array_assign_scalar.c, datetime_busday.c,
 datetime_busdaycal.c, datetime.c, 
datetime_strings.c}
  doc/cython/c_numpy.pxd, doc/pyrex/c_numpy.pxd

Does the NumPy default license apply to the above files?
If so, it should be more explicitly documented in the debian/copyright
file.
If not, has there been any attempt to get in touch with the copyright
holders and obtain a license, so that these files explicitly meet the
DFSG?


Moreover, the following files
  numpy/oldnumeric/ma.py
  numpy/ma/*
just say "Released for unlimited redistribution.", which is kind
of laconic for a license.
It is it all the permission we are left with?
Has there been any attempt to get in touch with the copyright holders
and obtain a clearer license, so that these files more explicitly
meet the DFSG?


Please let me know, thanks for your time and dedication!

Bug#963763: debian/copyright discrepancies for some files

[Bill Allombert]

On Sat, Jun 27, 2020 at 04:14:22PM -0400, John Scott wrote:
> Control: severity -1 minor
> 
> > > ./src/systems/darwin/*: Expat license
> > 
> > Note that these files are not used by Debian build process,
> > and the file explicitly allow sublicensing to GPL2+.
> 
> If they were to be severed from the source tree, which is part of the FTP 
> archive, a user might want to know they can be used under more permissive 
> terms. This would be only informative.

For what is worth, these files are obsolete since MacOS 10.4.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#965030: packagekit: randomly prevents me from unlocking my screen

[Daniel Blaschke]

Package: packagekit
Version: 1.1.12-5
Severity: important

Dear Maintainer,

I'm actually not sure if this is a packagekit, policykit, or gnome-shell bug;
the symptoms are:

I unlock my screen for a logged-in user (which is as admin user), and
immediately get prompted for my sudo/admin password for a process that needs
admin access.
I have to click 'cancel' at least 5 times and sometimes it goes away, sometimes
I cannot get rid of it at all until I reboot my system.
The logs show the following:
***
Operator of unix-session: 2 FAILED to authenticate to gain authorization for
action org.freedesktop.packagekit.system-sources-refresh for system-bus-
name::1.337 [/user/bin/gnome-software --gapplication-service] (owned by unix-
user:daniel)




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

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

Versions of packages packagekit depends on:
ii  libappstream4   0.12.5-1
ii  libapt-inst2.0  1.8.2.1
ii  libapt-pkg5.0   1.8.2.1
ii  libc6   2.28-10
ii  libgcc1 1:8.3.0-6
ii  libglib2.0-02.58.3-2+deb10u2
ii  libglib2.0-bin  2.58.3-2+deb10u2
ii  libgstreamer1.0-0   1.14.4-1
ii  libpackagekit-glib2-18  1.1.12-5
ii  libpolkit-gobject-1-0   0.105-25
ii  libsqlite3-03.27.2-3
ii  libstdc++6  8.3.0-6
ii  libsystemd0 241-7~deb10u4
ii  policykit-1 0.105-25

Versions of packages packagekit recommends:
ii  packagekit-tools  1.1.12-5

Versions of packages packagekit suggests:
ii  appstream  0.12.5-1

-- no debconf information

Bug#963128: pandoc: conversion from docbook: missing space between firstname and lastname

[John MacFarlane]

Indeed, this also happens with the current dev version of
pandoc.  If you want this to be fixed, you'll get better
results if you submit the bug report for pandoc upstream
on our tracker: https://github.com/jgm/pandoc/issues.

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

[Nick Black]

Package: console-setup
Version: 1.196
Severity: wishlist
Tags: upstream

Dear Maintainer,

While working on Notcurses (https://notcurses.com), I realized that numerous
Unicode Box-Drawing Characters resolve to the missing glyph (U+FFFD), despite
being well-simulated by glyphs present in the font. I suggest that these
Unicode->font mappings be added to the various psf files. Notcurses currently
adds them (if not already present) at application start time, and I can verify
that it significantly improves the console experience.

I'm happy to make these patches and send them upstream, but Anton Zinoviev
requested that I file a bug here.

I consider the following wide strings to be acceptable fallback sets (taken
from Notcurses src/lib/linux.c):

  .ws = L"/╱",
  .ws = L"\\╲",
  .ws = L"X╳",
  .ws = L"└┕┖┗╘╙╚╰",
  .ws = L"┘┙┚┛╛╜╝╯",
  .ws = L"┌┍┎┏╒╓╔╭",
  .ws = L"┐┑┒┓╕╖╗╮",
  .ws = L"─━┄┅┈┉╌╍═╼╾",
  .ws = L"│┃┆┇┊┋╎╏║╽╿",
  .ws = L"├┝┞┟┠┡┢┣╞╟╠",
  .ws = L"┤┥┦┧┨┩┪┫╡╢╣",
  .ws = L"┬┭┮┯┰┱┲┳╤╥╦",
  .ws = L"┴┵┶┷┸┹┺┻╧╨╩",
  .ws = L"┼┽┾┿╀╁╂╃╄╅╆╇╈╉╊╋╪╫╬",

Let me know how I can make myself useful.



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

Kernel: Linux 5.7.8nlb (SMP w/64 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages console-setup depends on:
ii  console-setup-linux 1.196
ii  debconf 1.5.74
ii  keyboard-configuration  1.196
ii  xkb-data2.29-2

console-setup recommends no packages.

Versions of packages console-setup suggests:
ii  locales   2.30-8
ii  lsb-base  11.1.0

Versions of packages keyboard-configuration depends on:
ii  debconf 1.5.74
ii  liblocale-gettext-perl  1.07-4

Versions of packages console-setup-linux depends on:
ii  init-system-helpers 1.58
ii  kbd 2.0.4-4
ii  keyboard-configuration  1.196

console-setup-linux suggests no packages.

Versions of packages console-setup is related to:
pn  console-common
pn  console-data  
pn  console-tools 
ii  gnome-control-center  1:3.36.4-1
ii  kbd   2.0.4-4
ii  systemd   245.6-2

-- debconf information:
  console-setup/store_defaults_in_debconf_db: true
* keyboard-configuration/other:
  console-setup/codesetcode: Arabic
* keyboard-configuration/toggle: No toggling
  console-setup/guess_font:
  keyboard-configuration/unsupported_config_layout: true
* keyboard-configuration/modelcode: pc105
  console-setup/fontsize-text47: 8x16
* keyboard-configuration/store_defaults_in_debconf_db: true
* keyboard-configuration/variant: English (US)
* console-setup/codeset47: . Arabic
  keyboard-configuration/unsupported_layout: true
* console-setup/fontface47: VGA
* keyboard-configuration/ctrl_alt_bksp: true
* keyboard-configuration/altgr: The default for the keyboard layout
* console-setup/fontsize-fb47: 8x16
* keyboard-configuration/variantcode:
  keyboard-configuration/unsupported_config_options: true
* keyboard-configuration/optionscode: terminate:ctrl_alt_bksp
  console-setup/use_system_font:
* keyboard-configuration/compose: No compose key
* console-setup/charmap47: UTF-8
* keyboard-configuration/layout:
  debian-installer/console-setup-udeb/title:
  console-setup/fontsize: 8x16
* keyboard-configuration/xkb-keymap: us
  console-setup/framebuffer_only:
* keyboard-configuration/model: Generic 105-key PC (intl.)
  keyboard-configuration/unsupported_options: true
* keyboard-configuration/switch: No temporary switch
* keyboard-configuration/layoutcode: us

Bug#933687: ITP: golang-golang-x-arch -- Library with machine architecture information

[Roger Shimizu]

Dear Emanuel,

On Fri, Aug 2, 2019 at 6:27 AM Emanuel Krivoy  wrote:
>
> Package: wnpp
> Severity: wishlist
> Owner: Emanuel Krivoy 
>
> * Package name: golang-golang-x-arch
>   Version : 0.0~git20190312.788fe5f-1

I refreshed the packaging on salsa, and uploaded to NEW queue.
Latest gits are already pushed to salsa:
- https://salsa.debian.org/go-team/packages/golang-golang-x-arch.git

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

Bug#963771: nodejs breaks node-immutable-tuple autopkgtest: can handle a lot of strings: AssertionError

[Olivier Tilloy]

An upstream change in Node.js is causing this test failure:
https://github.com/nodejs/node/commit/a0f338ecc1

The solution is to remove the offending test:
https://salsa.debian.org/js-team/node-immutable-tuple/-/merge_requests/1

Bug#965027: libreoffice-impress: libreoffice impress crashes when dragging image inserted

[junyue]

Package: libreoffice-impress
Version: 1:6.1.5-3+deb10u6
Severity: important

Dear Maintainer,

After inserted an image into a slide in libreoffice impress, dragging the image
with the mouse will cause libreoffice impress to crash and exit, and then asks
if want to recover the file. I have tried many times, it happens every time.
Thanks!



-- System Information:
Debian Release: bullseye/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: mips64el (mips64)

Kernel: Linux 5.4.38-1.fc28.lemote.mips64el (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libreoffice-impress depends on:
ii  libc62.28-10
ii  libepoxy01.5.4-1
ii  libetonyek-0.1-1 0.1.9-1
ii  libgcc-s1 [libgcc1]  10.1.0-4
ii  libgcc1  1:8.3.0-6
ii  libmwaw-0.3-30.3.14-1
ii  libodfgen-0.1-1  0.1.7-1
ii  libreoffice-core 1:6.1.5-3+deb10u6
ii  libreoffice-draw 1:6.1.5-3+deb10u6
ii  librevenge-0.0-0 0.0.4-6+b1
ii  libstaroffice-0.0-0  0.0.6-1
ii  libstdc++6   8.3.0-6
ii  libxml2  2.9.4+dfsg1-7+b3
ii  uno-libs36.1.5-3+deb10u6
ii  ure  6.1.5-3+deb10u6
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages libreoffice-impress recommends:
ii  libreoffice-avmedia-backend-gstreamer  1:6.1.5-3+deb10u6

Versions of packages libreoffice-impress suggests:
ii  bluez  5.50-1.2

Versions of packages libreoffice-core depends on:
ii  fontconfig2.13.1-4.2
ii  fonts-opensymbol  2:102.11+LibO6.4.5-1
ii  libboost-date-time1.67.0  1.67.0-13+deb10u1
ii  libboost-locale1.67.0 1.67.0-13+deb10u1
ii  libc6 2.28-10
ii  libcairo2 1.16.0-4
ii  libclucene-contribs1v52.3.3.4+dfsg-1+b1
ii  libclucene-core1v52.3.3.4+dfsg-1+b1
ii  libcmis-0.5-5v5   0.5.2-2+b1
ii  libcups2  2.3.3-1
ii  libcurl3-gnutls   7.68.0-1
ii  libdbus-1-3   1.12.20-1
ii  libdbus-glib-1-2  0.110-5
ii  libdconf1 0.36.0-1
ii  libeot0   0.01-5+b1
ii  libepoxy0 1.5.4-1
ii  libexpat1 2.2.9-1
ii  libexttextcat-2.0-0   3.4.5-1
ii  libfontconfig12.13.1-4.2
ii  libfreetype6  2.9.1-3+deb10u1
ii  libgcc-s1 [libgcc1]   10.1.0-4
ii  libgcc1   1:8.3.0-6
ii  libglib2.0-0  2.58.3-2+deb10u2
ii  libgpgmepp6   1.13.1-9
ii  libgraphite2-31.3.14-1
ii  libharfbuzz-icu0  2.3.1-1
ii  libharfbuzz0b 2.6.4-1+b1
ii  libhunspell-1.7-0 1.7.0-3
ii  libhyphen02.8.8-7
ii  libice6   2:1.0.9-2
ii  libicu63  63.1-6+deb10u1
ii  libjpeg62-turbo   1:1.5.2-2+b1
ii  liblcms2-22.9-3
ii  libldap-2.4-2 2.4.50+dfsg-1
ii  libmythes-1.2-0   2:1.2.4-3+b1
ii  libneon27-gnutls  0.31.2-1
ii  libnspr4  2:4.25-1
ii  libnss3   2:3.53.1-1
ii  libnumbertext-1.0-0   1.0.6-1
ii  libodfgen-0.1-1   0.1.7-1
ii  liborcus-0.14-0   0.14.1-6
ii  libpng16-16   1.6.36-6
ii  libpoppler82  0.71.0-5
ii  librdf0   1.0.17-1.1+b1
ii  libreoffice-common1:6.1.5-3+deb10u6
ii  librevenge-0.0-0  0.0.4-6+b1
ii  libsm62:1.2.3-1
ii  libstdc++68.3.0-6
ii  libx11-6  2:1.6.9-2+b1
ii  libxext6  2:1.3.3-1+b2
ii  libxinerama1  2:1.1.4-2
ii  libxml2   2.9.4+dfsg1-7+b3
ii  libxmlsec11.2.28-2
ii  libxmlsec1-nss1.2.28-2
ii  libxrandr22:1.5.1-1
ii  libxrender1   1:0.9.10-1
ii  libxslt1.11.1.32-2.2~deb10u1
ii  uno-libs3 6.1.5-3+deb10u6
ii  ure   6.1.5-3+deb10u6
ii  zlib1g1:1.2.11.dfsg-2

Versions of packages libreoffice-core recommends:
ii  libpaper-utils  1.1.28+b1

Versions of packages libreoffice-draw depends on:
ii  libavahi-client3 0.8-3
ii  libavahi-common3 0.8-3
ii  libc62.28-10
ii  libcdr-0.1-1 0.1.5-1
ii  libdbus-1-3  1.12.20-1
ii  libdbus-glib-1-2 0.110-5
ii  libfreehand-0.1-10.1.2-3
ii  libgcc-s1 [libgcc1]  10.1.0-4
ii  libgcc1  1:8.3.0-6
ii  libglib2.0-0 2.58.3-2+deb10u2
ii  libicu63 63.1-6+deb10u1
ii  liblcms2-2   2.9-3
ii  libmspub-0.1-1   0.1.4-1+b2
ii  libmwaw-0.3-30.3.14-1
ii  libodfgen-0.1-1  0.1.7-1
ii  libpagemaker-0.0-0   0.0.4-1
ii  libpng16-16  1.6.36-6
ii  libqxp-0.0-0 0.0.2-1
ii  libreoffice-core 1:6.1.5-3+deb10u6
ii  librevenge-0.0-0 0.0.4-6+b1
ii  libstaroffice-0.0-0  0.0.6-1
ii  libstdc++6

Bug#964916: Option to allow packages from backports but without forcing it

[Pirate Praveen]

On Tue, Jul 14, 2020 at 17:23, Pirate Praveen 
 wrote:



On Tue, Jul 14, 2020 at 13:57, Pirate Praveen 
 wrote:

I think rebuilding ruby-json with ruby 2.7 might fix it.


But now we need to update our build scripts to build with ruby 2.7.

https://git.fosscommunity.in/praveen/debian-scripts/-/blob/master/sbuild-fto 
was how we used to build earlier. With apt priority 500, it used to 
pick up ruby 2.7, but now with a lower apt priority it picks up ruby 
2.5 from buster. I need to figure out the best way to force ruby 2.7. 
I think forcing it via gem2deb may be the best option.


I think the root cause for aptitude failing to resolve the situation 
automatically is because ruby-json is now provided by libruby2.7. I 
think that is a bug in aptitude (and possibly apt too).


aptitude now succeeds in second try for fresh installations and 
succeeds after 4 tries when upgrading


See 
https://git.fosscommunity.in/debian-ruby/TaskTracker/-/issues/166#note_6864

Bug#965025: gpsshogi-data: data does not seem to be provided in the preferred format for modification

[Yann Dirson]

Package: gpsshogi
Version: 0.7.0-2
Severity: serious

The .bin and .dat files in gpsshogi-data come as-is in SVN, with
no information as to what they are generated from.  This does not
look DFSG-compliant.

As to the impact on my work on resurrecting the package (#964730),
if this issue is not solve it looks to me like at the minimum the data
would have to be split into non-free, and gpsshogi itself move
to contrib.


-- System Information:
Debian Release: 10.4
  APT prefers stable
  APT policy: (990, 'stable'), (900, 'testing'), (500, 'stable-debug'), (500, 
'unstable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages gpsshogi depends on:
ii  gpsshogi-data   0.7.0-2
ii  libboost-date-time1.67.01.67.0-13+deb10u1
ii  libboost-filesystem1.67.0   1.67.0-13+deb10u1
ii  libboost-iostreams1.67.01.67.0-13+deb10u1
ii  libboost-program-options1.67.0  1.67.0-13+deb10u1
ii  libboost-serialization1.67.01.67.0-13+deb10u1
ii  libboost-system1.67.0   1.67.0-13+deb10u1
ii  libboost-thread1.67.0   1.67.0-13+deb10u1
ii  libc6   2.28-10
ii  libgcc1 1:8.3.0-6
ii  libgl1  1.1.0-1
ii  libgsl232.5+dfsg-6
ii  libosl1v5   0.8.0-2~deb10u0
ii  libpocofoundation60 1.9.0-5+b1
ii  libpoconet601.9.0-5+b1
ii  libqt5core5a5.11.3+dfsg1-1+deb10u3
ii  libqt5gui5  5.11.3+dfsg1-1+deb10u3
ii  libqt5network5  5.11.3+dfsg1-1+deb10u3
ii  libqt5widgets5  5.11.3+dfsg1-1+deb10u3
ii  libqt5xml5  5.11.3+dfsg1-1+deb10u3
ii  libreadline77.0-5
ii  libstdc++6  8.3.0-6
ii  libtcmalloc-minimal42.7-1

gpsshogi recommends no packages.

gpsshogi suggests no packages.

-- no debconf information

Bug#965022: ITP: apery -- Strong AI for playing Shogi

[ydirson]

> Package: wnpp
> Severity: wishlist
> Owner: Yann Dirson 
> 
> * Package name: apery
>   Version : WCSC28+git20191114
>   Upstream Author : Hiraoka Takuya 
> * URL : https://github.com/HiraokaTakuya/apery
> * License : GPL
>   Programming Lang: C++
>   Description : Strong AI for playing Shogi
> 
> Apery is a strong Shogi AI by today's standards, and was ranked
> 3rd at the 28th World Computer Shogi Championship (2018).
> 
> Relies on MIT-licensed evaluation function.

The evaluation function itself is quite a large thing (850MB), it looks like
a bad idea to include it in the same source package.

Even then, I'd like to check first whether such a near-gigagyte data package
would be allowed into the archive.  It could be worth to package an installer
for that data instead, what do you think ?

Bug#965024: ITP: gtherm -- simple daemon to monitor thermal zones and cooling devices

[Henry-Nicolas Tourneur]

Package: wnpp
Severity: wishlist
Owner: Henry-Nicolas Tourneur 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: gtherm
  Version : 0.0.2
  Upstream Author : Guido Gunther
* URL : https://source.puri.sm/Librem5/gtherm
* License : GPLv3+ and LGPLv2.1+
  Programming Lang: C
  Description : simple daemon to monitor thermal zones and cooling devices

gtherm provides a DBus daemon (gthd) to monitor thermal zones and cooling
devices. It offers a library (libgtherm) and GObject introspection bindings to
ease reading the values in applications.

This software will be packaged through the Debian On Mobile team on
salsa.

Bug#964997: simgear FTCBFS: does not pass cross flags for cmake

[Dr. Tobias Quathamer]

tag -1 pending

Am 13.07.20 um 19:53 schrieb Helmut Grohne:
> simgear fails to cross build from source, because it does not pass cross
> flags to cmake. The easiest way of doing so - using dh_auto_configure -
> makes simgear cross buildable. Please consider applying the attached
> patch.
> 
> Helmut

Hi Helmut,

thanks for the patch, I've committed it to git, it'll be part of the
next release.

Regards,
Tobias



signature.asc
Description: OpenPGP digital signature

Bug#965023: transition: re2

[Stefano Rivera]

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

Public ABI Breakage:
An entry was inserted into an enum, rather than appended to the end.

Public API Breakage:
None

Reverse Dependencies:
* dnsdist seems to have had uninstallable Build-Dependencies, in my testing
  yesterday, but built fine on the 5th.
* Everything else builds without error.

Ben file:

title = "re2";
is_affected = .depends ~ "libre2-7" | .depends ~ "libre2-8";
is_good = .depends ~ "libre2-8";
is_bad = .depends ~ "libre2-7";

https://release.debian.org/transitions/html/auto-re2.html LGTM

SR

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

[Sean Whitton]

Hello,

On Tue 14 Jul 2020 at 10:19AM +02, Markus Koschany wrote:

> I am reaching out to you because the Firefox/Chromium addon
> ublock-origin is still in the NEW queue despite being uploaded four
> months ago. The package is not really new in Debian and it is quite
> unusual that a binary-new package has been stuck in the queue for such a
> long time. The problem is that ublock-origin should be updated in stable
> releases as well and the new version in the queue is the solution for a
> couple of problems which I cannot address in a more effective way
> otherwise.
>
> Please clarify the status of ublock-origin and why it is still in the
> NEW queue.

Simply that we do not have enough active FTP team members.

Just to note that being in binary-NEW makes no difference; it gets a
full check as if it were a new source package.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#963061: nodejs breaks node-grunt-contrib-nodeunit autopkgtest: 1/24 assertions failed

[Olivier Tilloy]

This failure is caused by an unidentified change in upstream Node.js which
results in a test's output not being wrapped as expected. Simply modifying
that test to add some more data so that its output is wrapped does the
trick:

https://salsa.debian.org/js-team/node-grunt-contrib-nodeunit/-/merge_requests/1

Bug#965022: ITP: apery -- Strong AI for playing Shogi

[Yann Dirson]

Package: wnpp
Severity: wishlist
Owner: Yann Dirson 

* Package name: apery
  Version : WCSC28+git20191114
  Upstream Author : Hiraoka Takuya 
* URL : https://github.com/HiraokaTakuya/apery
* License : GPL
  Programming Lang: C++
  Description : Strong AI for playing Shogi

Apery is a strong Shogi AI by today's standards, and was ranked
3rd at the 28th World Computer Shogi Championship (2018).

Relies on MIT-licensed evaluation function.

Bug#965021: conntrackd: segfaults when not disabling internal cache

[Thomas Schneider]

Package: conntrackd
Version: 1:1.4.5-2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

I’m experiencing a problem with conntrackd.

* What led up to the situation?

I installed and configured conntrackd and simply started it.

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

I investigated the problem using gdb and valgrind.  As the segfault
happens in cache_ct_cmp(), by being passed a NULL pointer that it tries
to dereference, I tried to disable the caches.

Setting `DisableExternalCache on` led to the same behaviour.  Setting
`DisableInternalCache on` apparently fixed it, however this option is
only available in NOTRACK mode (and I want to use FTFW mode).

Since some hash related functions appear in the backtrace, I tried to
change the value of HashSize and HashLimit.  Based on more or less
similar reports I found online, I tried disabling TCPWindowTracking and
ExpectationSync.  Neither one fixed the problem.

* What was the outcome of this action?

It segfaulted right after starting.  Only with `DisableExternalCache
on`, it produced any output (see below), without that, no output was
produced.

* What outcome did you expect instead?

I expected it to work, or at least provide a sensible error message.


*** /tmp/gdb.log
# gdb -q --args conntrackd
Reading symbols from conntrackd...Reading symbols from 
/usr/lib/debug/.build-id/ce/01eee7370eaa2a78b30857a5478c1b7f600bfe.debug...done.
done.
(gdb) r
Starting program: /usr/sbin/conntrackd
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Tue Jul 14 16:48:55 2020] (pid=13845) [notice] disabling external cache

Program received signal SIGSEGV, Segmentation fault.
0x55564ba1 in cache_ct_cmp (data1=0x0, data2=0x555afd60) at 
cache-ct.c:104
104 cache-ct.c: No such file or directory.
(gdb) bt
#0  0x55564ba1 in cache_ct_cmp (data1=0x0, data2=0x555afd60) at 
cache-ct.c:104
#1  0xf633 in hashtable_find (table=0x555a9810, 
data=data@entry=0x555afd60,
id=) at hash.c:74
#2  0x5556434c in cache_find (c=c@entry=0x555a9710, 
ptr=ptr@entry=0x555afd60,
id=id@entry=0x7fff9ec4) at cache.c:304
#3  0x55564378 in cache_update_force (c=0x555a9710, 
ptr=0x555afd60) at cache.c:279
#4  0x555663b8 in dump_handler (type=NFCT_T_UPDATE, data=, ct=0x555afd60)
at ctnl.c:266
#5  dump_handler (type=NFCT_T_UPDATE, ct=0x555afd60, data=) 
at ctnl.c:257
#6  0x77ba47db in __callback (nlh=0x7fffa090, nfa=0x7fff9f50, 
data=0x555afd40)
at callback.c:58
#7  0x7778805c in nfnl_step (h=h@entry=0x555afa20, 
nlh=nlh@entry=0x7fffa090)
at libnfnetlink.c:1340
#8  0x77788823 in nfnl_process (h=h@entry=0x555afa20,
buf=buf@entry=0x7fffa090 , 
len=len@entry=3604) at libnfnetlink.c:1385
#9  0x77788b8e in nfnl_catch (h=0x555afa20) at libnfnetlink.c:1539
#10 0x77ba562f in nfct_query (h=0x555afc00, qt=qt@entry=NFCT_Q_DUMP,
data=data@entry=0x555772e4 ) at api.c:970
#11 0x55561f71 in nl_dump_conntrack_table (h=) at 
netlink.c:153
#12 0x5556661f in ctnl_init () at ctnl.c:456
#13 0xf505 in init () at run.c:301
#14 0xdf72 in main (argc=1, argv=0x7fffe428) at main.c:367

*** /tmp/valgrind.log
# valgrind conntrackd
==13777== Memcheck, a memory error detector
==13777== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==13777== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==13777== Command: conntrackd
==13777==
[Tue Jul 14 16:44:45 2020] (pid=13777) [notice] disabling external cache
==13777== Invalid read of size 8
==13777==at 0x113608: hashtable_find (hash.c:72)
==13777==by 0x118377: cache_update_force (cache.c:279)
==13777==by 0x11A3B7: dump_handler (ctnl.c:266)
==13777==by 0x11A3B7: dump_handler (ctnl.c:257)
==13777==by 0x4A5A7DA: __callback (callback.c:58)
==13777==by 0x4E8A05B: nfnl_step (libnfnetlink.c:1340)
==13777==by 0x4E8A822: nfnl_process (libnfnetlink.c:1385)
==13777==by 0x4E8AB8D: nfnl_catch (libnfnetlink.c:1539)
==13777==by 0x4A5B62E: nfct_query (api.c:970)
==13777==by 0x11A61E: ctnl_init (ctnl.c:456)
==13777==by 0x113504: init (run.c:301)
==13777==by 0x111F71: main (main.c:367)
==13777==  Address 0x54af660 is 0 bytes after a block of size 32 alloc'd
==13777==at 0x4837B65: calloc (vg_replace_malloc.c:752)
==13777==by 0x113577: hashtable_create (hash.c:39)
==13777==by 0x117E8D: cache_create (cache.c:102)
==13777==by 0x121796: internal_cache_init (internal_cache.c:26)
==13777==by 0x11ADAC: init_sync (sync-mode.c:396)
==13777==by 0x11A52A: ctnl_init (ctnl.c:414)
==13777==by 0x113504: init (run.c:301)
==13777==by 0x111F71: main (main.c:367)
==13777==
==13777== Invalid read of size 8
==13777==at 0x118BA1: cache_ct_cmp 

Bug#955271: libreoffice-common: AppArmor profile blocks gpg's tofu.db, causes hang opening Options

[John Scott]

user pkg-apparmor-t...@lists.alioth.debian.org
usertag + buggy-profile
thanks

On Sunday, March 29, 2020 4:42:18 AM EDT you wrote:
> user pkg-apparmor-t...@lists.alioth.debian.org
> usertag - buggy-profile
> thanks
> 
> On Sat, Mar 28, 2020 at 10:06:43PM -0400, John Scott wrote:
> > User: pkg-apparmor-t...@lists.alioth.debian.org
> > Usertags: buggy-profile
> 
> Sorry, no.
> Just because we didn't have the TOFU trust model in mind the
> profile is "buggy"?
> 
> It is *your* decision to set it. So *you* have to deal with fallout.
> One can't just support any possible configuration.
> 
> One of which is to file this report, the other one is to use the
> "default" trust model?
I think there's a misunderstanding. I realize with no GnuPG 2 abstraction it's 
not your job to work around this. The usertag 'buggy-profile' merely indicates 
that it is an issue caused by AppArmor, not that you're responsible to fix it. 
Please see their usertag definitions [1].

I hoped that filing a bug might would demonstrate the need to make a good 
abstraction and bring it to the AppArmor team's attention. I don't mean to 
play ping-pong, but since I think this was a misunderstanding I am reinstating 
the usertag. You are right to mark it as 'wontfix' since LibreOffice isn't the 
right place to enumerate the intricacies of GnuPG.

> > - -- Configuration Files:
> > /etc/apparmor.d/usr.lib.libreoffice.program.soffice.bin changed [not
> > included] * I had set it to complain mode
> 
> It is in complain mode per default anyway.
In general LibreOffice is in complain mode, but libreoffice-soffice//gpg is 
enforced 
by default. This was acknowledged in #899380 message 38 at the time, which 
happened to also be filed by me and was shown to cause LibreOffice to hang.

It got put into enforce mode again from my local modifications upgrading to 
LibreOffice 7 which reminded me of this bug today.

[1] https://wiki.debian.org/AppArmor/Reportbug#Usertags

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

Bug#962919: RFS: spyne/2.13.15-0.1 [NMU, RC] -- Python library for writing and calling soap web service

[Bastian Germann]

On Tue, 16 Jun 2020 00:58:10 +0200 Bastian Germann wrote:> I am looking
for a sponsor for the package "spyne" which has a
> py2removal RC and a grave bug and was autoremoved from testing. The
> package is Python 2 only but the current upstream version has Python 3
> support. I converted it to build a binary python3-spyne package. The
> bugs are open long enough for a NMU.
> 
>  * Package name: spyne
>Version : 2.13.15-0.1
>Upstream Author : Burak Arslan 
>  * URL : http://spyne.io/
>  * License : LGPL-2.1+
>Section : python
> 
> It builds those binary packages:
> 
>   python3-spyne - Python library for writing and calling soap web service
> 
> To access further information about this package, please visit the
> following URL:
> 
>   https://mentors.debian.net/package/spyne
> 
> Alternatively, one can download the package with dget using this command:
> 
>   dget -x
> https://mentors.debian.net/debian/pool/main/s/spyne/spyne_2.13.15-0.1.dsc

One month has passed and no new spyne package has been released. Please
consider sponsoring the package. The last upload is almost four years
ago and it is RC-buggy for 11 months. There are people who depend on the
package, so it would be great to have it back in Debian again.

Bug#964094: Video playback broken with AMD 5700 XT using amdgpu drivers

[Ski-lleR]

Hi,

I unhold the package, and apply the update again + reboot, the problem is gone. 
I do multiple reboot to test is the problem re-appear, no problem so far.

So i think that's was not caused by one of the updated package, my system may 
have an hardware problem i have to find :/

Well sorry for the misreport, you can clause the bug.

Have a nice day

Sent with ProtonMail Secure Email.

publickey - ski_ller@protonmail.ch - 0xC8010ECA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Bug#965019: mir FTBFS with protobuf 3.12.3

[Adrian Bunk]

Source: mir
Version: 1.7.0+dfsg1-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=mir=sid

...
/<>/src/server/frontend/protobuf_responder.cpp: In member function 
‘virtual void 
mir::frontend::detail::ProtobufResponder::send_response(google::protobuf::uint32,
 google::protobuf::MessageLite*, const FdSets&)’:
/<>/src/server/frontend/protobuf_responder.cpp:42:69: error: ‘int 
google::protobuf::MessageLite::ByteSize() const’ is deprecated: Please use 
ByteSizeLong() instead [-Werror=deprecated-declarations]
   42 | send_response_buffer{static_cast(response->ByteSize())};
  | ^
In file included from /usr/include/google/protobuf/generated_enum_util.h:36,
 from /usr/include/google/protobuf/map.h:55,
 from 
/usr/include/google/protobuf/generated_message_table_driven.h:34,
 from 
/<>/build-arm64/src/protobuf/mir_protobuf_wire.pb.h:26,
 from 
/<>/src/server/frontend/protobuf_responder.h:23,
 from 
/<>/src/server/frontend/protobuf_responder.cpp:19:
/usr/include/google/protobuf/message_lite.h:420:7: note: declared here
  420 |   int ByteSize() const { return internal::ToIntSize(ByteSizeLong()); }
  |   ^~~~
...

Bug#965018: RFS: freetype-py/2.2.0-1 -- Freetype Python bindings for Python 3

[Bastian Germann]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "freetype-py"

 * Package name: freetype-py
   Version : 2.2.0-1
   Upstream Author : Nicolas P. Rougier
 * URL : https://github.com/rougier/freetype-py
 * License : BSD-3-clause
 * Vcs :
https://salsa.debian.org/python-team/modules/freetype-py
   Section : python

It builds those binary packages:

  python3-freetype - Freetype Python bindings for Python 3

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

  https://mentors.debian.net/package/freetype-py

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

  dget -x
https://mentors.debian.net/debian/pool/main/f/freetype-py/freetype-py_2.2.0-1.dsc

Changes since the last upload:

   * Add tests control file
   * Update meta versions
   * gbp: Only keep pristine-tar config
   * New upstream version 2.2.0
   * d/control: Build-depend on toml
   * Drop patch

Regards,
Bastian Germann

Bug#819060: clamsmtp/proxsmtp does not handle lines with leading dots correctly

[Christoph Pleger]

Hello,

is there a chance that my patch will ever be integrated into the package?

Regards
  Christoph

Bug#964820: libwxgtk3.0-gtk3-0v5: AUI caption text is dark on a dark background

[Scott Talbert]

On Tue, 14 Jul 2020, Olly Betts wrote:


On Sat, Jul 11, 2020 at 11:31:51AM +0200, Michel Le Bihan wrote:

I opened https://github.com/wxWidgets/wxWidgets/pull/1946. It is still
very ugly, but at least the AUI caption text is readable.


This has now been applied upstream as:

https://github.com/wxWidgets/wxWidgets/commit/aae96a430609bacfa546f0a872cf1a94e8a0b073

Scott: Do you want to take care of this?


Sure, can do.

Scott

Bug#964975: ugrep: Wrong synopsis line

[Eriberto]

>
>
> Very good. Thanks!

Bug#965017: O: debian-builder -- Rebuild Debian packages from source code

[Boyuan Yang]

Package: wnpp
Severity: normal

As written in https://bugs.debian.org/962738 , I am orphaning package
debian-builder due to inactivity of original package maintainer.

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.  If you are still
uncertain about how to adopt the package, please feel free to let me
know or seek help from other Debian Developers. You do not need
anyone's permit to take over maintenance of this package.

Some information about this package:

Package: debian-builder
Version: 1.8
Installed-Size: 64
Maintainer: Deepak Tripathi 
Architecture: all
Depends: build-essential, devscripts, dpkg-dev, perl, perl-modules
Description-en: Rebuild Debian packages from source code
 This is a simple tool which is designed to allow a local
 administrator to rebuild individual Debian packages from
 their source code.
 .
 With the aid of a few included wrapper scripts this allows
 automatically rebuilding a package and all its dependencies.
 .
 Note: This software is not designed to enhance your installation
 by producing optimized binaries, however this may be achieved
 with the aid of companion packages such as 'pentium-builder',
 or 'athlon-builder'.
 .
 The prime purpose of this package is to ease the testing of
 compiler patches such as the Stack Smashing Protection patch
 available from IBM.
Description-md5: 252fd2b79a999abdb5d2b0e325b136af
Tag: devel::buildtools, devel::debian, devel::testing-qa,
 implemented-in::perl, interface::commandline, role::program,
 scope::utility, suite::debian, works-with::software:source
Section: admin
Priority: optional
Filename: pool/main/d/debian-builder/debian-builder_1.8_all.deb
Size: 15024
MD5sum: b35e8da0f3c12c2677cea406dcd6be55
SHA256:
0b8017fc96bf546c45a3a32cf3051c55363af4641dd856de31221391877ea062

Package: debian-builder
Binary: debian-builder
Version: 1.8
Maintainer: Deepak Tripathi 
Build-Depends: debhelper (>= 5)
Architecture: all
Standards-Version: 3.7.3
Format: 1.0
Files:
 3b2286ae5fc046f5eb0aac901e1cd379 511 debian-builder_1.8.dsc
 0e6f85f13c437f8588e5ad52b9139965 12455 debian-builder_1.8.tar.gz
Checksums-Sha256:
 3fac5f51f399a55d8ac53e94ddf19627a08af3eed35e7c4a8d3b50b9959beb3e 511
debian-builder_1.8.dsc
 86a6ca49c59683c67992d9aca7bfda5da27bc60f72b35fc1c86d4e8390b74b9e 12455
debian-builder_1.8.tar.gz
Directory: pool/main/d/debian-builder
Priority: source
Section: admin

-- 
Regards,
Boyuan Yang


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

Bug#965016: Manuskript crashes when browsing scenes

[Víctor Bedoya Ponte]

Package: Manuskript
Version: 0.8.0-1
Severity: grave

   * I start Manuskript
   * I try it first with a saved project; then I also try without a saved 
project, and the outcome is the same. In both cases, I browse some scenes, I 
modify some settings, or I start full-screen mode.
   * What was the outcome of this action? The program crashes.
   * What outcome did you expect instead? Change scenes, modify settings, 
start full-screen mode

-- Terminal output:

qt.qpa.xcb: QXcbConnection: XCB error: 5 (BadAtom), sequence: 672, resource 
id: 0, major code: 19 (DeleteProperty), minor code: 0
KCrash: crashing... crashRecursionCounter = 2
KCrash: Application Name = python3.7 path = /usr/bin pid = 5111
KCrash: Arguments: /usr/bin/python3.7 
KCrash: Attempting to start /usr/lib/x86_64-linux-gnu/libexec/drkonqi from 
kdeinit
sock_file=/run/user/1000/kdeinit5__0


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

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

Versions of packages manuskript depends on:
ii  libqt5svg5  5.11.3-2
ii  python3 3.7.3-1
ii  python3-enchant 2.0.0-1
ii  python3-lxml4.3.2-1
ii  python3-markdown3.0.1-3
ii  python3-pyqt5   5.11.3+dfsg-1+b3
ii  python3-pyqt5.qtwebkit  5.11.3+dfsg-1+b3
ii  zlib1g  1:1.2.11.dfsg-1


-- Python shows this message: 

Application: python3.7 (python3.7), signal: Segmentation fault
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Current thread is 1 (Thread 0x7f0a7ad4e740 (LWP 5111))]

Thread 6 (Thread 0x7f0a5e032700 (LWP 5117)):
#0  0x7f0a7b30a00c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/x86_64-
linux-gnu/libpthread.so.0
#1  0x7f0a5e620e83 in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#2  0x7f0a5e620bd7 in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#3  0x7f0a7b303fa3 in start_thread () from /lib/x86_64-linux-gnu/
libpthread.so.0
#4  0x7f0a7ae4a4cf in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 5 (Thread 0x7f0a6501f700 (LWP 5116)):
#0  0x7f0a75e6de69 in g_mutex_lock () from /lib/x86_64-linux-gnu/
libglib-2.0.so.0
#1  0x7f0a75e23ca6 in g_main_context_dispatch () from /lib/x86_64-linux-
gnu/libglib-2.0.so.0
#2  0x7f0a75e241c8 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7f0a75e2425c in g_main_context_iteration () from /lib/x86_64-linux-
gnu/libglib-2.0.so.0
#4  0x7f0a797dd743 in 
QEventDispatcherGlib::processEvents(QFlags) () 
from /lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x7f0a7978b15b in 
QEventLoop::exec(QFlags) () from /lib/x86_64-
linux-gnu/libQt5Core.so.5
#6  0x7f0a795dae76 in QThread::exec() () from /lib/x86_64-linux-gnu/
libQt5Core.so.5
#7  0x7f0a795e4a67 in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#8  0x7f0a7b303fa3 in start_thread () from /lib/x86_64-linux-gnu/
libpthread.so.0
#9  0x7f0a7ae4a4cf in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 4 (Thread 0x7f0a67fff700 (LWP 5114)):
#0  0x7f0a75e6de69 in g_mutex_lock () from /lib/x86_64-linux-gnu/
libglib-2.0.so.0
#1  0x7f0a75e23140 in g_main_context_acquire () from /lib/x86_64-linux-
gnu/libglib-2.0.so.0
#2  0x7f0a75e23ff5 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7f0a75e2425c in g_main_context_iteration () from /lib/x86_64-linux-
gnu/libglib-2.0.so.0
#4  0x7f0a797dd743 in 
QEventDispatcherGlib::processEvents(QFlags) () 
from /lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x7f0a7978b15b in 
QEventLoop::exec(QFlags) () from /lib/x86_64-
linux-gnu/libQt5Core.so.5
#6  0x7f0a795dae76 in QThread::exec() () from /lib/x86_64-linux-gnu/
libQt5Core.so.5
#7  0x7f0a6fbf4545 in ?? () from /lib/x86_64-linux-gnu/libQt5DBus.so.5
#8  0x7f0a795e4a67 in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#9  0x7f0a7b303fa3 in start_thread () from /lib/x86_64-linux-gnu/
libpthread.so.0
#10 0x7f0a7ae4a4cf in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 3 (Thread 0x7f0a6eabd700 (LWP 5113)):
#0  0x7f0a7ae3f819 in poll () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x7f0a71f6ecf7 in ?? () from /lib/x86_64-linux-gnu/libxcb.so.1
#2  0x7f0a71f7091a in xcb_wait_for_event () from /lib/x86_64-linux-gnu/
libxcb.so.1
#3  0x7f0a6fd01d79 in ?? () from /lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
#4  0x7f0a795e4a67 in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x7f0a7b303fa3 in start_thread () from /lib/x86_64-linux-gnu/
libpthread.so.0
#6  0x7f0a7ae4a4cf in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 2 (Thread 

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

[Bdale Garbee]

I'm not interested in maintaining pcb any more.

Bdale

On July 13, 2020 7:04:01 PM MDT, Rob Browning  wrote:
>Bdale Garbee  writes:
>
>> So... while I'm sure gEDA could be "saved" in Debian with enough
>effort,
>> I just don't see the point, and won't put any time or attention on it
>> myself.   
>
>I'd suggest we should do something "soonish".  This is the last package
>holding guile-2.0 in testing, and I'd *really* like to be able to
>finish
>the guile-2.0 removal.
>
>For what it's worth, I thought I'd see how hard it might be to update
>to
>guile-3.0, and the attached (very primitive/incomplete) diff does get
>the current package to build and pass all but one of the tests here
>(assuming that wasn't a short-circuit and there are more tests after
>that).
>
>However, unless someone's interested in maintaining the package,
>pursuing guile-3.0 support, upgrading to 1.10, etc.  Perhaps it's best
>to file for removal now.  We can always reintroduce it later, if the
>situation improves.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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

[Michael Meskes]

> >Could you please elaborate what (n)cal miss? "ncal -w" does give you
> >week numbers
> 
> But which ones? American? German? ISO? (Turns out the latter two are

Depends on the locale you use.

> identical.) This is completely underdocumented and doesn’t match
> expectations; even the “week begins with sunday/monday” knobs don’t
> promise anything as the American and ISO ways of counting weeks are
> still distinct.

No idea what you are saying, sorry, please elaborate.

> It also has a different output format from traditional.

As mentioned in my previous email, you can use the -b switch to get
back to traditional format.

> I understand if you find this too bothersome to do in Debian for
> such a (corner?) case, but that is why this is of wishlist severity
> ;)

Na, the problem is understanding what's missing, or wrong. :)

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

Bug#950488: buster-pu: package kronosnet/1.8-2

[wferi]

wf...@niif.hu writes:

> We'd be immensely grateful for your input on this matter, since your
> position more or less determines how we can plan to support the HA users
> in Debian.  We'd still prefer a stable update (either to 1.13 as in the
> original request or to a more recent stable release), but if that isn't
> possible, we'll move forward with backports.  (Which isn't a particularly
> appealing option in itself, because the imminent libqb 2 transition will
> cause much churn across the stack.)

Dear Stable Release Team,

Although we've uploaded 1.16-2~bpo10+1 to backports, we'd still be
interested in doing a stable update (as above) if possible.  Is there
anything we can do to that end?
-- 
Thanks,
Feri

Bug#964077: And another one for DEB_RULES_REQUIRES_ROOT

[Christian Ehrhardt]

Another patch on top (since you didn't commit any you can squash that with
the former one).
If not using fakeroot it needs to use DEB_RULES_REQUIRES_ROOT.

Patch attached

-- 
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd
From db4509f2dd3d1f5008eaf1325d882950d38b703e Mon Sep 17 00:00:00 2001
From: Christian Ehrhardt 
Date: Tue, 14 Jul 2020 14:41:21 +0200
Subject: [PATCH] d/rules: fix the DEB_GAIN_ROOT_CMD call to dh_auto_test

Signed-off-by: Christian Ehrhardt 
---
 debian/rules | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index 27f6f63..068c04d 100755
--- a/debian/rules
+++ b/debian/rules
@@ -36,7 +36,7 @@ override_dh_auto_test:
 ifeq (,$(findstring nocheck,$(DEB_BUILD_OPTIONS)))
  ifeq ($(DEB_RULES_REQUIRES_ROOT),dpkg/target-subcommand)
   ifeq (,$(findstring fakeroot,$(DEB_GAIN_ROOT_CMD)))
-	$(DEB_RULES_REQUIRES_ROOT) dh_auto_test -- runtests || true
+	$(DEB_GAIN_ROOT_CMD) dh_auto_test -- runtests || true
   else
 	@echo 'Warning: Tests require real root, not fakeroot.  Skipping.' >&2
   endif
-- 
2.27.0

Bug#963808: ruby-sanitize: CVE-2020-4054: HTML sanitization bypass in Sanitize

[terceiro]

On Mon, Jul 13, 2020 at 10:04:10PM +0200, Salvatore Bonaccorso wrote:
> Hi Antonio,
> 
> On Mon, Jul 13, 2020 at 11:19:38AM -0300, terce...@debian.org wrote:
> > On Sun, Jul 12, 2020 at 03:11:30PM +0200, Salvatore Bonaccorso wrote:
> > > On Sat, Jun 27, 2020 at 09:10:01PM +0200, Salvatore Bonaccorso wrote:
> > > > Source: ruby-sanitize
> > > > Version: 4.6.6-2
> > > > Severity: grave
> > > > Tags: security upstream
> > > > Justification: user security hole
> > > > 
> > > > Hi,
> > > > 
> > > > The following vulnerability was published for ruby-sanitize.
> > > > 
> > > > CVE-2020-4054[0]:
> > > > | In Sanitize (RubyGem sanitize) greater than or equal to 3.0.0 and less
> > > > | than 5.2.1, there is a cross-site scripting vulnerability. When HTML
> > > > | is sanitized using Sanitize's "relaxed" config, or a custom config
> > > > | that allows certain elements, some content in a math or svg element
> > > > | may not be sanitized correctly even if math and svg are not in the
> > > > | allowlist. You are likely to be vulnerable to this issue if you use
> > > > | Sanitize's relaxed config or a custom config that allows one or more
> > > > | of the following HTML elements: iframe, math, noembed, noframes,
> > > > | noscript, plaintext, script, style, svg, xmp. Using carefully crafted
> > > > | input, an attacker may be able to sneak arbitrary HTML through
> > > > | Sanitize, potentially resulting in XSS (cross-site scripting) or other
> > > > | undesired behavior when that HTML is rendered in a browser. This has
> > > > | been fixed in 5.2.1.o
> > > 
> > > Attached ist a preliminary debdiff with the fix, but two prerequisites
> > > before "fix: Don't treat :remove_contents as `true` when it's an
> > > Array" and "feat: Remove useless filtered element content by default".
> > > 
> > > Antonio, would it be possible to let it go trough your second pair of
> > > eyes, with the pre-knolege that I'm not familiar with the package but
> > > trying to address the CVE-2020-4054.
> > > 
> > > If those look correct, the plan would be to do 4.6.6-2.1~deb10u1 based
> > > on that for buster-security.
> > 
> > Yes, those patches look OK.
> > 
> > Thanks for your work.
> 
> Thanks for your review! So propsing to upload the NMU first, and then
> later handle the DSA for it based on that version if no negative
> reports come in.

Sure, just do it.


signature.asc
Description: PGP signature

Bug#965015: RFS: mpack/1.6-16 -- tools for encoding/decoding MIME messages

[Fabio Augusto De Muzio Tobich]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "mpack"

 * Package name: mpack
   Version : 1.6-16
   Upstream Author : https://gitlab.com/osdp/mpack/-/issues/new
 * URL : https://gitlab.com/osdp/mpack
 * License : MIT
 * Vcs : https://salsa.debian.org/debian/mpack
   Section : mail

It builds those binary packages:

  mpack - tools for encoding/decoding MIME messages

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/m/mpack/mpack_1.6-16.dsc

Changes since the last upload:

   * New upstream. Consequently:
   - debian/control: updated Homepage field. (Closes: #958199)
   - debian/copyright:
   ~ Added Comment field.
   ~ Added Upstream-Contact field.
   ~ Updated Source field.
   - debian/watch: updated.
   - debian/upstream/metadata: created.
   * debian/patches/:
   - 08_fix-mime-version.patch: added to fix non-standard use of
 MIME-Version in mail headers. Thanks to Sam Kemp .
 (Closes: #964959)
   - 09_remove-debugging-message.patch: added to remove a debugging message
 left behind. (Closes: #965008)
   * debian/tests/files: fixed a typo in the test files.

Regards,

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



signature.asc
Description: OpenPGP digital signature

Bug#965014: bsdmainutils: binaries uploaded

[Gianfranco Costamagna]

Source: bsdmainutils
Version: 12.1.4
Severity: serious
Justification: can't migrate per Britney policy.

Hello, thanks for fixing the bsdmainutils RC bugs, but without a source-only 
upload, the package
won't ever migrate to testing.
In specific, the arch:all packages can't be binNMUed, so please reupload if you 
want the fix to go in testing.

thanks!

Gianfranco

Bug#965013: quart FTBFS: no theme named 'pydata_sphinx_theme' found

[Adrian Bunk]

Source: quart
Version: 0.12.0-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=quart=all=0.12.0-1=1594718034=0

...
/usr/bin/make -C docs clean html SPHINXBUILD=sphinx-build SPHINXOPTS="-N -D 
html_last_updated_fmt=\"14 July 2020\""
make[2]: Entering directory '/<>/docs'
Running Sphinx v2.4.3
making output directory... done

Theme error:
no theme named 'pydata_sphinx_theme' found (missing theme.conf?)
make[2]: *** [Makefile:20: html] Error 2

Bug#965012: add. information

[Andreas Schulz]

Hi,

there is a little mistake in reporting. I build a own package and forgot
to replace it with the original one before opening the report:

was:
Package: squid
Version: 3.5.23-5+deb9u2.1
Severity: important
File: /usr/sbin/squid

correct:
Package: squid
Version: 3.5.23-5+deb9u2
Severity: important
File: /usr/sbin/squid

regards,
Andreas

Bug#944028: It is new released

[Yukiharu YABUKI]

Hello, Nicolas

You might know below.

Release 0.3.0 · dandavison/delta
https://github.com/dandavison/delta/releases/tag/0.3.0

git-delta looks better than the others.

FYI:

barnumbirr/delta-debian: Debian packages for delta.
https://github.com/barnumbirr/delta-debian

--
++++++++++++++
Yukiharu Yabuki (矢吹幸治)  I use Debian GNU/Linux
mail: yab...@netfort.gr.jp
++++++++++++++


pgpolmUI2Aqm6.pgp
Description: PGP signature

Bug#964803: Debian Sid Alpha architecture dbus-daemon(6913): unaligned trap at 0000000000000000: 0000000082eaf0e0 28 18

[smcv]

alpha is not a release architecture, so expect it to have issues.

On Sat, 11 Jul 2020 at 00:43:39 +0800, Антон Кочков wrote:
> Preparing to unpack .../16-libpython3.8-dev_3.8.4~rc1-1_alpha.deb ...
> Unpacking libpython3.8-dev:alpha (3.8.4~rc1-1) ...
> [  406.873815] dbus-daemon(6913): unaligned trap at :
> 82eaf0e0 28 18

Can alpha kernels be configured to make processes crash with a core dump
on unaligned access, like /proc/cpu/alignment on ARM?

It is unlikely to be possible to solve this in dbus without having a
backtrace for each unaligned access that indicates where the problem
occurred.

smcv

Bug#964975: ugrep: Wrong synopsis line

[Ricardo Ribalda Delgado]

Hi Joao

Thanks for your mail. It is already fixed on salsa:
https://salsa.debian.org/ribalda-guest/ugrep/-/blob/debian/debian/control

The next release will have a compliant text.

Best regards

On Mon, Jul 13, 2020 at 7:00 PM Joao Eriberto Mota Filho
 wrote:
>
> Package: ugrep
> Version: 2.1.1+dfsg-1
> Severity: normal
> X-Debbugs-Cc: eribe...@debian.org
>
> Dear Maintainer,
>
> The synopsis in your package is not compliant with Debian Policy §3.4.1. Using
> 'apt search ugrep' I can see:
>
>  ugrep/unstable 2.1.1+dfsg-1 amd64
>Universal grep: ultra fast searcher of file systems, text and
>
> Please, use an informative line to describe your package.
>
> Regards,
>
> Eriberto
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)



-- 
Ricardo Ribalda

Bug#965012: /usr/sbin/squid: ICAP-Error after Upgrade from 3.5.23-5+deb9u1 to 3.5.23-5+deb9u2

[Andreas Schulz]

Package: squid
Version: 3.5.23-5+deb9u2.1
Severity: important
File: /usr/sbin/squid

Dear Maintainer,

We installed the security update deb9u2 and learned that no more
http-access (with icap) was possible. No problem with https because
https is forwarded directly and with disabled icap feature http also no problem.

In access.log I found:
1594709099.638  0 x.x.x.x ICAP_ERR_OTHER/000 0 RESPMOD 
(http://www.google.de/) 127.0.0.1

After downgrade to deb9u1 everything worked fine again. I enabled debugging
(debug_options 93,3) and found some squid loglines:

essential ICAP service is down after an options fetch failure: 
icap://127.0.0.1:1344/virus_scan [down,!opt]
and
ServiceRep.cc(534) noteAdaptationAnswer: failed to fetch options 
[down,!opt,fail1]

With a tcpdump on lo interface I found a strange behaviour:
squid -> icap:
syn
syn ack
ack
rst

So squid is sending a rst package? I can provide the tracefile if desired.
Furthermore the cache.log of squid with content of debug_options as above
mentioned.

I checked applied patches and after some tests and rebuilds I found that without
patch CVE-2019-12523 it worked again. We have sev. stretch squids (with
and without parent squids) and all have the same problem. Quite unsure
why I can't find anything on mailing lists.

-- System Information:
Debian Release: 9.12
  APT prefers oldstable-updates
  APT policy: (990, 'oldstable-updates'), (990, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-12-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages squid depends on:
ii  adduser  3.115
ii  libc62.24-11+deb9u4
ii  libcap2  1:2.25-1
ii  libcomerr2   1.43.4-2+deb9u1
ii  libdb5.3 5.3.28-12+deb9u1
ii  libdbi-perl  1.636-1+b1
ii  libecap3 1.0.1-3.2
ii  libexpat12.2.0-2+deb9u3
ii  libgcc1  1:6.3.0-18+deb9u1
ii  libgssapi-krb5-2 1.15-1+deb9u1
ii  libkrb5-31.15-1+deb9u1
ii  libldap-2.4-22.4.44+dfsg-5+deb9u4
ii  libltdl7 2.4.6-2
ii  libnetfilter-conntrack3  1.0.6-2
ii  libnettle6   3.3-1+b2
ii  libpam0g 1.1.8-3.6
ii  libsasl2-2   2.1.27~101-g0780600+dfsg-3+deb9u1
ii  libstdc++6   6.3.0-18+deb9u1
ii  libxml2  2.9.4+dfsg1-2.2+deb9u2
ii  logrotate3.11.0-0.1
ii  lsb-base 9.20161125
ii  netbase  5.4
ii  squid-common 3.5.23-5+deb9u2

Versions of packages squid recommends:
ii  libcap2-bin  1:2.25-1

Versions of packages squid suggests:
pn  resolvconf   
pn  smbclient
pn  squid-cgi
pn  squid-purge  
ii  squidclient  3.5.23-5+deb9u2
pn  ufw  
pn  winbindd 

/etc/squid/squid.conf changed:
.snip.
logformat icap_squid-ext %ts.%03tu %6icap::tr %>a %icap::to/%03icap::Hs 
%icap::>st %icap::rm (%ru) %un %icap::