Bug#941326: bug 941326

[Gary]

Running under gdb get:

Program received signal SIGSEGV, Segmentation fault.
0x776637da in _rl_update_final () at ../display.c:2972
2972  botline_length = VIS_LLEN(_rl_vis_botlin) - woff;
$2 = (struct line_state *) 0x77685640 
(gdb) p line_state_visible->lbreaks
$3 = (int *) 0x0
(gdb)

VIS_LLEN is defined as:

 #define VIS_LLEN(l) ((l) > _rl_vis_botlin ? 0 : (vis_lbreaks[l+1] -
vis_lbreaks[l]))

and vis_lbreaks as
#define vis_lbreaks (line_state_visible->lbreaks)

So attempting to dereference an NULL pointer




signature.asc
Description: OpenPGP digital signature

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

[Drew Parsons]

Hi Bastian, freetype-py builds fine with dpkg-buildpackage, but fails in 
chroot (pdebuild pbuilder):


$ pdebuild
dpkg-checkbuilddeps: error: Unmet build dependencies: 
python3-setuptools-scm

W: Unmet build-dependency in source
dh clean --with python3 --buildsystem=pybuild
   dh_auto_clean -O--buildsystem=pybuild
	install -d 
/projects/freetype-py/debian/.debhelper/generated/_source/home

pybuild --clean --test-pytest -i python{version} -p 3.8
I: pybuild base:217: python3.8 setup.py clean
# Will use the system-provided FreeType.
Traceback (most recent call last):
  File "setup.py", line 103, in 
setup(
  File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line 
143, in setup

_install_setup_requires(attrs)
  File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line 
138, in _install_setup_requires

dist.fetch_build_eggs(dist.setup_requires)
  File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 695, in 
fetch_build_eggs

resolved_dists = pkg_resources.working_set.resolve(
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 
781, in resolve

dist = best[req.key] = env.best_match(
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 
1066, in best_match

return self.obtain(req, installer)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 
1078, in obtain

return installer(requirement)
  File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 754, in 
fetch_build_egg

return fetch_build_egg(self, req)
  File "/usr/lib/python3/dist-packages/setuptools/installer.py", line 
83, in fetch_build_egg

raise DistutilsError('the `allow-hosts` option is not supported '
distutils.errors.DistutilsError: the `allow-hosts` option is not 
supported when using pip to install requirements.
E: pybuild pybuild:352: clean: plugin distutils failed with: exit 
code=1: python3.8 setup.py clean
dh_auto_clean: error: pybuild --clean --test-pytest -i python{version} 
-p 3.8 returned exit code 13

make: *** [debian/rules:8: clean] Error 25




Are you able to interpret that error, or do you have a clean chroot to 
inspect?


Drew

Bug#962050: sasmodels: regression in debian/patches/reproducible-c-models.patch

[Drew Parsons]

On 2020-07-29 11:37, Drew Parsons wrote:


It must be related to the  _constrained_ property.


Probably, sas64_constrained_ellipsoid_ is being generated by build-time 
tests.  The constrained tag is added by reparameterize() in core.py, and 
is called (twice) with ellipsoid by test_reparameterize() in 
test_reparameterize().


I think that means we should just delete 
sas64_constrained_ellipsoid_*.so. In sasview, there's only one listing 
for model Ellipsoid/ellipsoid (distinct from core_shell_ellipsoid), so 
the alternative constrained variants don't seem to be directly 
accessible anyway.


But the upstream build system should be cleaning up after itself if it's 
generating test reparameterisations that are not intended to be 
installed.

Bug#964810: gimp: Unable to start gimp in debian unstable

[felipe]

After investigating further, I found the problematic package to be 
mesa-opencl-icd.

After removing the package above, gimp works again.

Bug#962050: sasmodels: regression in debian/patches/reproducible-c-models.patch

[Drew Parsons]

So, with 1.0.4-1 the build seems to be reproducible, in the sense that 
it generates the same two

  sas64_constrained_ellipsoid_7FA82C95.so
  sas64_constrained_ellipsoid_9F860665.so
each time.

Not obvious to me why there is a double provisioning of 
sas64_constrained_ellipsoid. They're both generated right at the 
beginning of dh_auto_install (running build_py, before running 
install_lib). None of the other compiled_models are listed at that 
point.


All the other compiled_models are built earlier, during 
override_dh_auto_build.


It must be related to the  _constrained_ property.  The actual model is 
just "ellipsoid", "sas64" and "constrained" are build tags.  No other 
model is built as "_constrained_", only ellipsoid.  So it might be that 
_7FA82C95 and _9F860665 distinguish between two distinct constraint 
conditions.

Bug#966477: WARNING: at net/ipv4/tcp_input.c:2799 tcp_fastretrans_alert

[Aidan Gauland]

Package: src:linux
Version: 4.19.118-2+deb10u1
Severity: normal

Dear Maintainer,

During my semi-regular auditing of the system log, I noticed the below
warning
and stack trace.  I have no idea what may have caused it, and the system has
been operating normally for weeks (continuous uptime) and appears to
still be
operating normally.

Regards,
Aidan Gauland

Note: Some sensitive apparmor audit lines have been removed from the
kernel log here.

-- Package-specific info:
** Version:
Linux version 4.19.0-9-amd64 (debian-ker...@lists.debian.org) (gcc
version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.118-2+deb10u1
(2020-06-07)

** Command line:
BOOT_IMAGE=/BOOT/debian@/vmlinuz-4.19.0-9-amd64 root=ZFS=/ROOT/debian ro
root=ZFS=rpool/ROOT/debian quiet

** Tainted: PWOE (12801)
 * Proprietary module has been loaded.
 * Taint on warning.
 * Out-of-tree module has been loaded.
 * Unsigned module has been loaded.

** Kernel log:
[2513851.122581] kauditd_printk_skb: 10 callbacks suppressed
[2693086.705995] [ cut here ]
[2693086.706047] WARNING: CPU: 3 PID: 0 at net/ipv4/tcp_input.c:2799
tcp_fastretrans_alert.cold.86+0x19/0x74
[2693086.706049] Modules linked in: nft_reject_inet nft_reject nft_log
nft_ct rpcsec_gss_krb5 nf_tables_set nf_log_ipv6 ip6_tables ip6t_REJECT
nf_reject_ipv6 nf_log_ipv4 nf_log_common nft_limit nft_counter xt_LOG
xt_limit xt_comment xt_tcpudp ipt_REJECT nf_reject_ipv4 xt_conntrack
nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c crc32c_generic
nft_compat nf_tables nfnetlink nls_ascii nls_cp437 vfat fat intel_rapl
sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel
ipmi_ssif kvm ast ttm irqbypass drm_kms_helper crct10dif_pclmul
crc32_pclmul ghash_clmulni_intel intel_cstate mxm_wmi drm sg evdev
joydev intel_uncore mei_me efi_pstore ipmi_si mei intel_rapl_perf pcspkr
efivars pcc_cpufreq iTCO_wdt ipmi_devintf iTCO_vendor_support
intel_pch_thermal ioatdma ipmi_msghandler wmi button acpi_pad
[2693086.706102]  nfsd auth_rpcgss nfs_acl lockd grace sunrpc efivarfs
ip_tables x_tables autofs4 zfs(POE) zunicode(POE) zlua(POE) zavl(POE)
icp(POE) zcommon(POE) znvpair(POE) spl(OE) hid_generic usbhid hid sd_mod
crc32c_intel ahci xhci_pci libahci ehci_pci xhci_hcd ehci_hcd libata
ixgbe aesni_intel scsi_mod igb usbcore aes_x86_64 crypto_simd cryptd
glue_helper lpc_ich i2c_i801 i2c_algo_bit mfd_core dca usb_common mdio
[2693086.706142] CPU: 3 PID: 0 Comm: swapper/3 Tainted: P    W 
OE 4.19.0-9-amd64 #1 Debian 4.19.118-2+deb10u1
[2693086.706144] Hardware name: Supermicro Super
Server/X10SDV-4C+-TLN4F, BIOS 2.1 11/22/2019
[2693086.706150] RIP: 0010:tcp_fastretrans_alert.cold.86+0x19/0x74
[2693086.706154] Code: c7 48 f0 c3 96 e8 5a a8 a8 ff 0f 0b e9 ea ad ff
ff 48 c7 c7 48 f0 c3 96 48 89 4c 24 10 44 89 4c 24 08 89 14 24 e8 3a a8
a8 ff <0f> 0b 8b 14 24 44 8b 4c 24 08 48 8b 4c 24 10 e9 a9 b2 ff ff 48 c7
[2693086.706157] RSP: 0018:93d39fac3b10 EFLAGS: 00010246
[2693086.706160] RAX: 0024 RBX: 93d374724400 RCX:

[2693086.706163] RDX:  RSI: 00f6 RDI:
0300
[2693086.706165] RBP:  R08: 0011c6ad R09:
0004
[2693086.706166] R10:  R11: 0001 R12:
0001
[2693086.706168] R13: 93d39fac3ba8 R14:  R15:
0001
[2693086.706172] FS:  () GS:93d39fac()
knlGS:
[2693086.706174] CS:  0010 DS:  ES:  CR0: 80050033
[2693086.706176] CR2: 7f014aa2b000 CR3: 0007e840a001 CR4:
003606e0
[2693086.706179] DR0:  DR1:  DR2:

[2693086.706181] DR3:  DR6: fffe0ff0 DR7:
0400
[2693086.706182] Call Trace:
[2693086.706186]  
[2693086.706194]  tcp_ack+0x95d/0x1120
[2693086.706202]  ? sched_clock+0x5/0x10
[2693086.706208]  ? tcp_write_xmit+0x3cf/0x1000
[2693086.706214]  tcp_rcv_established+0x327/0x650
[2693086.706219]  tcp_v4_do_rcv+0x12a/0x1e0
[2693086.706223]  tcp_v4_rcv+0xb1a/0xc20
[2693086.706240]  ? nft_do_chain_inet+0x8a/0x100 [nf_tables]
[2693086.706248]  ip_local_deliver_finish+0x63/0x1e0
[2693086.706253]  ip_local_deliver+0xe0/0xf0
[2693086.706258]  ? ip_sublist_rcv_finish+0x80/0x80
[2693086.706263]  ip_rcv+0xbc/0xd0
[2693086.706268]  ? ip_rcv_finish_core.isra.18+0x360/0x360
[2693086.706275]  __netif_receive_skb_one_core+0x52/0x70
[2693086.706280]  netif_receive_skb_internal+0x2f/0xa0
[2693086.706285]  napi_gro_receive+0xba/0xe0
[2693086.706303]  igb_poll+0x481/0xeb0 [igb]
[2693086.706310]  net_rx_action+0x149/0x3b0
[2693086.706318]  __do_softirq+0xde/0x2d8
[2693086.706325]  irq_exit+0xba/0xc0
[2693086.706330]  do_IRQ+0x7f/0xe0
[2693086.706335]  common_interrupt+0xf/0xf
[2693086.706337]  
[2693086.706342] RIP: 0010:cpuidle_enter_state+0xb9/0x320
[2693086.706345] Code: e8 dc c0 b0 ff 80 7c 24 0b 00 74 17 9c 58 0f 1f
44 00 00 f6 c4 02 0f 85 3b 02 00 00 31 ff e8 ae b0 b6 

Bug#956259: ezgo: update section to `metapackages`

[Sandro Tosi]

any update here? it'd be extremely helpful to the py2removal effort if
this can be worked on soon.

On Thu, 09 Apr 2020 00:01:43 -0400 Sandro Tosi  wrote:
> Source: ezgo
> Severity: important
>
> Hello,
> all of the packages generated by this source are metapackages, please update
> the packages section to `metapackages`
>
> thanks!
>
> -- System Information:
> Debian Release: 10.0
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
> 'experimental-debug'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.19.0-5-amd64 (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= 
> (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
>

Bug#725484: A way to override blhc false-positives

[Eriberto]

Hi Simon,

(trying again because the last message was sent when being edited)

Em seg., 27 de jul. de 2020 às 03:10,  escreveu:
>
> Did you look at my approach about embedding the ignores inside
> the build log? This should work for local builds, CI and
> automatic build log parsing. And it can be fully controlled by
> the package maintainer. However, I never used the Salsa CI
> pipeline so feedback if that works (using my patch) is much
> appreciated.


Sorry for my delay and my apologies for don't understanding your
approach in first time.

I tested your patch and it is wonderful. I think it will work fine in
Salsa but we need a package to be updated there. Can you release a new
version? After this, we can reassign some bugs to the original
packages (as ngetty).

Thanks a lot for this improvement.

Regards,

Eriberto

Bug#725484: A way to override blhc false-positives

[Eriberto]

Hi Simon,

Em seg., 27 de jul. de 2020 às 03:10,  escreveu:
>
> Did you look at my approach about embedding the ignores inside
> the build log? This should work for local builds, CI and
> automatic build log parsing. And it can be fully controlled by
> the package maintainer. However, I never used the Salsa CI
> pipeline so feedback if that works (using my patch) is much
> appreciated.


Sorry for my delay and my apologies for don

Bug#966476: git-svn: dcommit doesn't preserve author field when authors file used

[Andrew Worsley]

Package: git-svn
Version: 1:2.20.1-2+deb10u3
Severity: important
Tags: patch



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

Kernel: Linux 4.19.0-9-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_CRAP
Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=ISO-8859-1), 
LANGUAGE=en_GB:en_AU:en (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages git-svn depends on:
ii  git   1:2.20.1-2+deb10u3
ii  libsvn-perl   1.10.4-1+deb10u1
ii  libterm-readkey-perl  2.38-1
ii  libyaml-perl  1.27-1

git-svn recommends no packages.

Versions of packages git-svn suggests:
pn  git-doc 
ii  subversion  1.10.4-1+deb10u1

-- no debconf information

  As described in stack overflow issue in 2011 and verified in this version
  as still present:


https://stackoverflow.com/questions/5327924/git-svn-dcommit-with-svn-usernames

  I find that the commit (at least for file URL subversion) just uses the 
default
  which is the last username used to submit changes to subversion.

  It is fairly easy to make up a simple subversion project to demonstrate the
  problem.

mkdir proj
touch proj/README.txt
svn import proj file://$(pwd)/repo -m "Initial checkin"
SVN_URL=file://$(pwd)/repo
svn co $SVN_URL proj.svn
echo "Change from fred" >> proj.svn/README.txt
svn commit --username fred proj.svn/README.txt -m "Change #1 from fred"
cat > authors.txt
amw = Andrew Worsley 
fred = Fred Smith 
^D

 # Export to git via git-svn
git svn clone --authors-file=authors.txt $SVN_URL proj.git-svn
 # The log shows the authors file is working svn => git
git -C proj.git-svn log

  # Add a change from user fred shows it appears as fred as
  # this was the last user to submit change into subversion:
echo "Change #2 from fred" >> proj.git-svn/README.txt
git -C proj.git-svn commit README.txt --author='Fred Smith 
' -m "2nd change from user fred"
git -C proj.git-svn log
commit 6c203a7022cd831fe505918967bda0534106cd09 (HEAD -> master)
Author: Fred Smith 
Date:   Wed Jul 29 10:52:36 2020 +1000

2nd change from user fred

commit 16b1728f0fe30a9c42098ad42b8da37a7b4405da (git-svn)
Author: Fred Smith 
Date:   Wed Jul 29 00:43:58 2020 +

Change #1 from fred

git-svn-id: file:///build/tmp/repo@2 bb13463d-1302-4b91-af5e-7ea19058a0f6

commit 2e2138b9af3bc8445f5fcba8e2e4c77e3ea78349
Author: Andrew Worsley 
Date:   Wed Jul 29 00:40:09 2020 +

Initial checkin

git-svn-id: file:///build/tmp/repo@1 bb13463d-1302-4b91-af5e-7ea19058a0f6

  # Now try it as user amw (which is my login user)
echo "Change #2 from amw" >> proj.git-svn/README.txt
git -C proj.git-svn commit README.txt -m "2nd change from user amw"
git -C proj.git-svn log
commit 5704bbe7bc60a3a6f29ca4122706fdc648cde2e1 (HEAD -> master)
Author: Andrew Worsley 
Date:   Wed Jul 29 10:54:48 2020 +1000

2nd change from user amw

commit 5398dbf30ee59d579bc7b2a60bab5f4088254cdf (git-svn)
Author: Fred Smith 
Date:   Wed Jul 29 00:53:20 2020 +

2nd change from user fred

git-svn-id: file:///build/tmp/repo@3 bb13463d-1302-4b91-af5e-7ea19058a0f6

commit 16b1728f0fe30a9c42098ad42b8da37a7b4405da
Author: Fred Smith 
Date:   Wed Jul 29 00:43:58 2020 +

Change #1 from fred

git-svn-id: file:///build/tmp/repo@2 bb13463d-1302-4b91-af5e-7ea19058a0f6

commit 2e2138b9af3bc8445f5fcba8e2e4c77e3ea78349
Author: Andrew Worsley 
Date:   Wed Jul 29 00:40:09 2020 +

Initial checkin

git-svn-id: file:///build/tmp/repo@1 bb13463d-1302-4b91-af5e-7ea19058a0f6

  # Now we dcommit this 2nd amw change
git -C proj.git-svn svn dcommit
Committing to file:///build/tmp/repo ...
M   README.txt
Committed r4
M   README.txt
r4 = bb626e195128d9582447a10d664f04323ae8c2b9 (refs/remotes/git-svn)
No changes between 5704bbe7bc60a3a6f29ca4122706fdc648cde2e1 and 
refs/remotes/git-svn
Resetting to the latest refs/remotes/git-svn

   # But it was commited into subversion as being from user fred !
 svn log -v $SVN_URL

r4 | fred | 2020-07-29 10:55:05 +1000 (Wed, 29 Jul 2020) | 1 line
Changed paths:
   M /README.txt

2nd change from user amw

r3 | fred | 2020-07-29 10:53:20 +1000 (Wed, 29 Jul 2020) | 1 line
Changed paths:
   M /README.txt

2nd change from user fred

r2 | fred | 2020-07-29 10:43:58 +1000 (Wed, 29 Jul 2020) | 1 line
Changed paths:
   M /README.txt

Change #1 from fred

r1 | amw | 2020-07-29 10:40:09 +1000 (Wed, 29 Jul 2020) | 1 line
Changed paths:
   A /README.txt

Initial checkin

Bug#962185: inkscape: Document properties dialog is too small and not resizable

[Phil Wyett]

On Thu, 2020-06-04 at 12:06 +0200, Michel Le Bihan wrote:
> Package: inkscape
> Version: 1.0-1
> Severity: normal
> Tags: upstream
> 
> The issue is already being tracked upstream:
> https://gitlab.com/inkscape/inkscape/-/issues/1343
> 
> 
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (700, 'testing'), (650, 'unstable'), (600,
> 'experimental'), (500, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.6.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8),
> LANGUAGE=fr_FR.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages inkscape depends on:
> ii  libatkmm-1.6-1v5   2.28.0-2
> ii  libc6  2.30-8
> ii  libcairo2  1.16.0-4
> ii  libcairomm-1.0-1v5 1.12.2-4
> ii  libcdr-0.1-1   0.1.6-1
> ii  libdbus-glib-1-2   0.110-5
> ii  libdouble-conversion3  3.1.5-5
> ii  libfontconfig1 2.13.1-4.2
> ii  libfreetype6   2.10.1-2
> ii  libgc1c2   1:7.6.4-0.4
> ii  libgcc-s1  10.1.0-3
> ii  libgdk-pixbuf2.0-0 2.40.0+dfsg-4
> ii  libgdl-3-5 3.34.0-1
> ii  libglib2.0-0   2.64.3-1
> ii  libglibmm-2.4-1v5  2.64.2-1
> ii  libgomp1   10.1.0-3
> ii  libgsl25   2.6+dfsg-2
> ii  libgtk-3-0 3.24.20-1
> ii  libgtkmm-3.0-1v5   3.24.2-1
> ii  libgtkspell3-3-0   3.0.10-1
> ii  libharfbuzz0b  2.6.4-1
> ii  libjpeg62-turbo1:1.5.2-2+b1
> ii  liblcms2-2 2.9-4+b1
> ii  libmagick++-6.q16-88:6.9.10.23+dfsg-2.1+b2
> ii  libpango-1.0-0 1.44.7-4
> ii  libpangocairo-1.0-01.44.7-4
> ii  libpangoft2-1.0-0  1.44.7-4
> ii  libpangomm-1.4-1v5 2.42.1-1
> ii  libpng16-161.6.37-2
> ii  libpoppler-glib8   0.71.0-6
> ii  libpoppler82   0.71.0-6
> ii  libpotrace01.16-2
> ii  librevenge-0.0-0   0.0.4-6+b1
> ii  libsigc++-2.0-0v5  2.10.2-1
> ii  libsoup2.4-1   2.70.0-1
> ii  libstdc++6 10.1.0-3
> ii  libvisio-0.1-1 0.1.7-1
> ii  libwpg-0.3-3   0.3.3-1
> ii  libx11-6   2:1.6.9-2+b1
> ii  libxml22.9.10+dfsg-5
> ii  libxslt1.1 1.1.34-4
> ii  python33.8.2-3
> ii  zlib1g 1:1.2.11.dfsg-2
> 
> Versions of packages inkscape recommends:
> ii  aspell   0.60.8-1
> ii  fig2dev  1:3.2.7b-4
> ii  imagemagick  8:6.9.10.23+dfsg-2.1+b2
> ii  imagemagick-6.q16 [imagemagick]  8:6.9.10.23+dfsg-2.1+b2
> ii  libimage-magick-perl 8:6.9.10.23+dfsg-2.1
> ii  libwmf-bin   0.2.8.4-17
> ii  python3-lxml 4.5.0-1.1
> ii  python3-numpy1:1.17.4-5
> ii  python3-scour0.37-4
> 
> Versions of packages inkscape suggests:
> pn  dia   
> pn  inkscape-tutorials
> pn  libsvg-perl   
> pn  libxml-xql-perl   
> ii  pstoedit  3.75-1
> pn  python3-uniconvertor  
> ii  ruby  1:2.7+1
> 
> -- no debconf information
> 

Hi,

This issue has was fixed in commit:

https://gitlab.com/speleo3/inkscape/-/commit/9569830407de9ae014bc5bc174d3ea9cc7b4c858

As this issue relates to usability. Can we include in current debian
inkscape packages that have 1.0-x please?

I have tested this fix and all seems well. It already appears in the
1.0.x upstream tree and would be able to be dropped with the release of
1.0.1, but no schedule for that is yet available.

Regards

Phil

-- 

*** Playing the game for the games sake. ***

WWW: https://kathenas.org

Twitter: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B



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

Bug#966475: rspamd ftbfs with gcc-10

[Steve Langasek]

Package: rspamd
Version: 2.5-2
Severity: serious
Tags: patch
Justification: ftbfs
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu groovy ubuntu-patch

Dear maintainers,

In Ubuntu, we've found that rspamd fails to build from source with the
current toolchain due to a missing C++ include file.  The attached patch
fixes the build failure in unstable.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru rspamd-2.5/debian/patches/gcc10-ftbfs.patch 
rspamd-2.5/debian/patches/gcc10-ftbfs.patch
--- rspamd-2.5/debian/patches/gcc10-ftbfs.patch 1969-12-31 16:00:00.0 
-0800
+++ rspamd-2.5/debian/patches/gcc10-ftbfs.patch 2020-07-28 16:51:48.0 
-0700
@@ -0,0 +1,16 @@
+Description: fix ftbfs with gcc 10 due to missing C++ header include
+Author: Steve Langasek 
+Last-Update: 2020-07-28
+
+Index: rspamd-2.5/contrib/replxx/src/io.cxx
+===
+--- rspamd-2.5.orig/contrib/replxx/src/io.cxx
 rspamd-2.5/contrib/replxx/src/io.cxx
+@@ -3,6 +3,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ 
+ #ifdef _WIN32
+ 
diff -Nru rspamd-2.5/debian/patches/series rspamd-2.5/debian/patches/series
--- rspamd-2.5/debian/patches/series2020-05-01 07:40:43.0 -0700
+++ rspamd-2.5/debian/patches/series2020-07-28 16:49:55.0 -0700
@@ -3,3 +3,4 @@
 0004-drop-js-scripts-packaged-by-Debian.patch
 0006-do-not-install-fonts-packaged-by-Debian.patch
 0007-license-problem-convert-utf-code.patch
+gcc10-ftbfs.patch

Bug#964164: RFS: org-drill/2.7.0-1 [ITP] -- spaced repetition drills in Emacs for accelerated study/learning

[Nicholas D Steeves]

DFSG-compliant orig.tarball has been created and an updated package
has been uploaded to mentors


signature.asc
Description: PGP signature

Bug#936251: bup: Python2 removal in sid/bullseye

[Sandro Tosi]

User: debian-pyt...@lists.debian.org
Usertags: -py2keep

the argument to set pykeep was that the app is popular enough;
according to https://qa.debian.org/popcon.php?package=bup it has ~230
installations, declining; removing the tag

On Fri, 30 Aug 2019 07:12:26 + Matthias Klose  wrote:
> Package: src:bup
> Version: 0.29.3-2
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal

Hey Robert, i looked at recent changes to the upstream repo, in
particular 
https://github.com/bup/bup/commit/64e04395957f148bd41d3506bc603a9b1122c7df
where they enabled tests on py3 too, as a good indication the code is
progressing in the right direction: do you think it's already at a
stage where a git snapshot could be uploaded to unstable?

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

Bug#966474: RM: freshplayerplugin -- RoQA; FTBFS, Obsolete, Unsupported by browsers, EOL upstream

[Dimitri John Ledkov]

Package: ftp.debian.org
Severity: normal

As per Adobe Flash Player EOL [1] flash player is going end of life by
end of this year. Similar statements are linked from that article by
Apple, Facebook, Google, Microsoft and Mozilla.

Currently browsers in Debian have already dropped NPAPI and the
package itself fails to build from source. [2] [3]

The time has come to kill Flash and remove this package from the archive.


[1] 
https://www.adobe.com/uk/products/flashplayer/end-of-life.html?cq_ck=1591175470736

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

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

Bug#962733: gmailieer: please package new upstream version 1.2 or later

[Nicholas D Steeves]

Hi Julian,

On Fri, Jun 12, 2020 at 09:48:20PM -0400, Nicholas D Steeves wrote:
> Package: gmailieer
> Version: 0.10-1
> Severity: normal
> 
> Hi,
> 
> We're now four releases behind upstream.  Highlights of the updates
> include many bug fixes, plus work on a new sendmail-compatible mode.
> Please package new upstream version 1.2 or later.
> 
> If 1.2 is packaged now then it looks worthwhile to cherry pick
> 05fcb58 "fix #157: use ValueError over argparse error"
> 
> Thanks!
> Nicholas

Gentle ping for an update :-)


signature.asc
Description: PGP signature

Bug#966473: okular: "Trim to selection" misbehaves in rotated view

[dpt]

Package: okular
Version: 4:20.04.2-1
Severity: minor

Dear Maintainer,

The menu item "View > Trim View > Trim to Selection" seems to do the
wrong thing for documents in a rotated view. It works fine if you trim
the page, then rotate the document, but if you open a document, rotate
it, and then trim, then (as best I can tell) Okular interprets the
trimming rectangle with respect to the original unrotated page, which
does the wrong thing.

Thanks,
Dylan Thurston

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

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

Versions of packages okular depends on:
ii  kinit 5.70.0-1
ii  kio   5.70.1-1
ii  libc6 2.31-1
ii  libfreetype6  2.10.2+dfsg-3
ii  libjpeg62-turbo   1:2.0.5-1
ii  libkf5activities5 5.70.0-1
ii  libkf5archive55.70.0-1
ii  libkf5bookmarks5  5.70.0-1
ii  libkf5codecs5 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  libkf5i18n5   5.70.0-1
ii  libkf5iconthemes5 5.70.0-1
ii  libkf5itemviews5  5.70.0-1
ii  libkf5jobwidgets5 5.70.0-1
ii  libkf5kexiv2-15.0.0   19.08.1-1+b2
ii  libkf5kiocore55.70.1-1
ii  libkf5kiowidgets5 5.70.1-1
ii  libkf5parts5  5.70.0-1
ii  libkf5pty55.70.0-1
ii  libkf5purpose-bin 5.70.0-1
ii  libkf5purpose55.70.0-1
ii  libkf5service-bin 5.70.0-1
ii  libkf5service55.70.0-1
ii  libkf5textwidgets55.70.0-1
ii  libkf5wallet-bin  5.70.0-1
ii  libkf5wallet5 5.70.0-1
ii  libkf5widgetsaddons5  5.70.0-1
ii  libkf5windowsystem5   5.70.0-1
ii  libkf5xmlgui5 5.70.0-1+b1
ii  libokular5core9   4:20.04.2-1
ii  libphonon4qt5-4   4:4.11.1-3
ii  libpoppler-qt5-1  0.71.0-6
ii  libqca-qt5-2  2.3.1-1
ii  libqmobipocket2   4:17.08.3-2+b1
ii  libqt5core5a  5.14.2+dfsg-4
ii  libqt5dbus5   5.14.2+dfsg-4
ii  libqt5gui55.14.2+dfsg-4
ii  libqt5printsupport5   5.14.2+dfsg-4
ii  libqt5svg55.14.2-2
ii  libqt5texttospeech5   5.14.2-2
ii  libqt5widgets55.14.2+dfsg-4
ii  libqt5xml55.14.2+dfsg-4
ii  libspectre1   0.2.8-2
ii  libstdc++610.1.0-1
ii  phonon4qt54:4.11.1-3
ii  zlib1g1:1.2.11.dfsg-2

Versions of packages okular recommends:
ii  cups-bsd  2.3.3-1

Versions of packages okular suggests:
ii  ghostscript9.52~dfsg-1
ii  okular-extra-backends  4:20.04.2-1
ii  poppler-data   0.4.9-2
ii  texlive-binaries   2020.20200327.54578-4+b1
pn  unrar  

-- no debconf information

Bug#966451: cloud.debian.org: systemd-growfs@-.service fails on arm64 instance types

[Noah Meyerhans]

Actually, the problem seems to have been caused by
https://salsa.debian.org/cloud-team/debian-cloud-images/-/merge_requests/192/

Prior to that MR, we weren't using systemd-growfs at all.

I've confirmed impact on amd64 instances as well as the arm64 instances
on which originally observed it.  It also seems like this could impact
our images on other cloud services besides Amazon EC2, but I haven't
tested there.

I'm a little surprised that nobody has reported this yet.  I suspect
that it's because although the service fails and the system is
"degraded", it generally is functional.  The people most likely to
experience problems because of this are relying on the filesystem to
successfully resize at launch; it could be that most are simply leaving
the root drive alone and attaching secondary EBS drives or EFS
filesystems for additional storage.

We should consider reverting that MR before we publish images for the
upcoming 10.5 release, unless we can identify and fix systemd-growfs by
then.

Bug#966395: Please support SSL bumping with '--with-openssl' configure option

[Amos Jeffries]

On Mon, 27 Jul 2020 17:54:01 -0400 Simon Deziel wrote:
> 
> Now that OpenSSL is available under the Apache License v. 2.0, there
> should no longer be any incompatibility with Debian.


Apache is not yet available with the new License and will likely not be
until the next Debian major release after it becomes available.


FWIW; Upstream is working on a few updates necessary for Squid to build
with libssl3 so this should happen normally when all the supporting
versions are available to install.

Amos

Bug#966472: bcbio: B-D biobambam2 not available in testing

[Andreas Beckmann]

Source: bcbio
Version: 1.2.0-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source
Control: block -1 with 966470

bcbio cannot be rebuilt in testing because the build-dependency biobambam2
is not in testing.


Andreas

Bug#966471: [qbittorrent-nox] Version kept from Stretch fails to launch after Buster upgrade

[Roman Mamedov]

Package: qbittorrent-nox
Version: 3.3.7-3
Severity: normal

I kept version 3.3.7-3 of the package from Stretch via 'aptitude hold' and
upgraded the rest of the system to Buster. Now it does not launch with the
error:

/usr/bin/qbittorrent-nox: symbol lookup error: /usr/bin/qbittorrent-nox:
undefined symbol: 
_ZN10libtorrent7session5startEiRKNS_13settings_packEPN5boost4asio10io_serviceE

All dependencies on the system are satisfied.

Downgrading libtorrent-rasterbar9 from 1.1.11-2 to 1.1.1-1+b1 (and adding the
libboost 1.62 packages that it requires) makes it work again.

It seems like the dependencies are poorly specified for this package.

-- 
With respect,
Roman

Bug#940413: syncthing: Please update to version 1.2.2

[Nicholas D Steeves]

Hi Simon,

Simon Frei  writes:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Upfront: The below is written from the perspective of a upstream
> maintainer and debian user (and very minor contributor if at all), I do
> not have much packaging experience - please excuse obvious oversights ;)
>

Of course, gladly! :-)

> On 21/07/2020 20:20, Nicholas D Steeves wrote:
>> Alexandre Viau  writes:
>>> On Sun, Jul 19, 2020 at 10:57 PM Nicholas D Steeves
 It seems to me that the most expedient path forward is to jump from
 1.2.x to 1.4.x.  ACK?
>>>
>>> Right, it looks like we will have too.
>>>
>>> I was trying to avoid it at first because it is a lot of work. I
>>> suggest that we move slowly and try to find the lowest version that
>>> works for now.
> What's the reason to expect more work when skipping more versions? My
> naive view is that it is more work to do more steps (e.g. because on
> every step you need to make sure all versions in debian are compatible).
> At the least I can strongly recommend to jump to the latest respective
> patch version (e.g. v1.7.1 is a minimal hotfix for an annoying issue in
> v1.7.0).
>
>> In other news, I can confirm that 1.4.0 ftbfs with the same qtls error
>> as 1.2.x.
> The quic dependency is unfortantely quite a moving target. As the
> version in debian is very recent (0.17) you'll need Syncthing >=1.6.0 or
> probably patches from
> https://github.com/syncthing/syncthing/commit/ac7338f1f2f10f67f16aa98b35fc97b4e043b7e5
> (no guarantees that's all, that's what came time to mind - untested and
> I'd anyway expect updating to be not much more of a pain than patching).
>

Thank you for confirming this; this saves a lot of time! :-D  I opened
#966466 to start building a picture of how much work it would be to jump
straight to v1.7.1.

For v1.6.1 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964363
For v1.7.1 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966466

> In general I am happy to help out with packaging - it just seemed that
> delays recently were mostly due to new dependencies, where I do not have
> any proficience thus my involvement would probably slow stuff down
> instead of speeding it up. Feel free to prod me anytime if there is
> useful task I can do or for any questions where I might have expertise :)
>

Thank you for your openness and willingness to help :-)

By the way, if ever you're interested in packaging here is a list of
relevant resources:

https://www.debian.org/social_contract (essential)
https://www.debian.org/doc/debian-policy (read relevant sections)
  * note that compliance with 100% of Policy is essential
https://go-team.pages.debian.net/ (obviously relevant)
https://www.debian.org/doc/devel-manuals (a nice overview of available docs)
https://mentors.debian.net/intro-maintainers/ (another nice overview)
  * includes solutions to common challenges
https://www.debian.org/doc/manuals/maint-guide/ (optional but recommended)
https://www.debian.org/doc/manuals/debmake-doc/ (optional but recommended)
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
  * recommended, probably required for Go Team policy

To be accepted into unstable, packages must pass through the NEW queue.
Here, packages require review by an ftpmaster.  Their criteria is thus:

https://ftp-master.debian.org/REJECT-FAQ.html
https://ftp-master.debian.org/NEW-checklist.html

Other resources are debian-ment...@lists.debian.org and
#debian-ment...@irc.oftc.net

I'd be happy to check your work and provide guidance if you can't find
anyone else!

Another way to help out would be manually check the diff in go.mod
between upstream/1.1.4_ds1 and upstream/1.7.1_ds1 for Bug #966466.  For
this you'll need a sid/unstable chroot and may use 'apt search', 'apt
policy', 'rmadison', plus the Debian bug tracker to see if there are any
missing deps that haven't been documented yet.  NEW packages will have
bugs filed against 'wnpp' and version upgrade requests are filed against
their respective packages.

The next step for my work at https://salsa.debian.org/sten/syncthing
will be to do this check, and then to remove any dependencies revealed
as "dropped" by the diff go.mod step from from debian/control.

If you'd like to work on that, please let me know soon.  The initial
investment of time and effort for NEW packages is really high, but
translating upstream deps to Debian deps is much faster and easier--and
also work that tends to need to be done for *every* new upstream golang
package release.


Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#966451: cloud.debian.org: systemd-growfs@-.service fails on arm64 instance types

[Noah Meyerhans]

Having done a bit of testing, this definitely seems to be a regression.
I've launched 63 instances of the 10.3 AMI in us-east-1
(ami-031d1abcdcbbfbd8f) and 63 of the current 10.4 AMI
(ami-0bb15d03913335eae) on a variety of 6g arm64 instance types.  Exacly
zero of the 10.3 launches ended up in degraded state because of
systemd-growfs failures, while 37/63 (59%) had systemd-growfs fail.

There was a systemd update in 10.4, to version 241-7~deb10u4, which may
be related.

Bug#965254: RM: openhackware/0.4.1+git-20140423.c559da7c-4.1

[Michael Tokarev]

28.07.2020 18:53, Paul Gevers wrote:
[]
> I admit it's confusing, but it states: Is the removal to be done in a
> suite other than "unstable"? Don't select anything for "unstable"
>  

Yes I've seen this. My thought was, - wait, I want it to be removed
from unstable _and_ testing too! Hence I selected something else
than nothing. At the time - and up to your previous reply, I haven't
realized removals are propagated to testing about the same way as
regular packages.  Maybe that's the reason people hit this trap, -
not realizing it starts at unstable and propagates to testing
the usual way.

> I guess we should request reportbug to fix the experience because you're
> not the first one to make the mistake.


Thank you for the patience and for the proper reassign!

I definitely learned something new today.

/mjt

Bug#966470: biobambam2: autopkgtest failures: Segmentation fault bamsormadup < SRR11728627.bam > SRR11728627.sorted.bam

[Andreas Beckmann]

Package: biobambam2
Version: 2.0.164+ds-1
Severity: serious

Hi,

biobambam2 fails its autopkg tests:

https://ci.debian.net/packages/b/biobambam2/testing/amd64/

autopkgtest [17:40:54]: test run-unit-test: [---
[93m[1mTest 1[0m
/tmp/autopkgtest-lxc.hkbkydv5/downtmp/build.3IE/src/debian/tests/run-unit-test: 
line 20:   794 Segmentation fault  bamsormadup < SRR11728627.bam > 
SRR11728627.sorted.bam
autopkgtest [17:40:55]: test run-unit-test: ---]
autopkgtest [17:40:55]: test run-unit-test:  - - - - - - - - - - results - - - 
- - - - - - -
run-unit-testFAIL non-zero exit status 139

Andreas

Bug#966469: RFS: platformio/4.3.4-1 -- open source ecosystem for IoT development

[Peter Zahradnik]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name : platformio
Version : 4.3.4-1
Upstream Author : cont...@platformio.org
* URL : https://platformio.org
* License : Apache-2.0
* Vcs : https://salsa.debian.org/python-team/applications/platformio
Section : electronics

It builds those binary packages:

platformio-doc - PlatformIO (common documentation)
platformio - open source ecosystem for IoT development

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


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

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

dget -x 
https://mentors.debian.net/debian/pool/main/p/platformio/platformio_4.3.4-1.dsc


Changes since the last upload:

platformio (4.3.4-1) unstable; urgency=medium
.
* New upstream version 4.3.4
* Move from subtrees to submodules
* debian/gbp.conf: submodules=True
* debian/control: change email for python-apps-team email list
* Build with --changes-option=-S (Closes: #965039)

Regards,
Peter Zahradnik

Bug#966468: util-linux: provide rename.ul again

[Asher Gordon]

Package: util-linux
Version: 2.36-1
Severity: normal
X-Debbugs-Cc: none, Asher Gordon 

Dear Maintainer,

I realize that rename.ul was removed because of #926637, but I think
that action was unnecessary. I believe the reporter of that bug wanted
rename.ul to be installed as an alternative for rename. Although you
provided a good reason for why this should not be done, I don't think
that's a reason to remove rename.ul entirely.

Personally, rename.ul was my rename of choice because of its simplicity,
and I was disappointed to see it go. I would appreciate it if you would
consider providing rename.ul in util-linux again.

Also, if you'd rather not provide rename.ul in util-linux, you might
consider building a separate binary package which provides rename.ul
from the util-linux source package. Then you might have the util-linux
binary package Suggest or Recommend rename.ul.

Thanks,
Asher

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

Kernel: Linux 5.7.0-1-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
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 util-linux depends on:
ii  libaudit1  1:2.8.5-3+b1
ii  libblkid1  2.36-1
ii  libc6  2.31-1
ii  libcap-ng0 0.7.9-2.2
ii  libcrypt1  1:4.4.16-1
ii  libmount1  2.36-1
ii  libpam0g   1.3.1-5
ii  libselinux13.1-2
ii  libsmartcols1  2.36-1
ii  libsystemd0245.6-2
ii  libtinfo6  6.2-2
ii  libudev1   245.6-2
ii  libuuid1   2.36-1
ii  login  1:4.8.1-1
ii  zlib1g 1:1.2.11.dfsg-2

util-linux recommends no packages.

Versions of packages util-linux suggests:
ii  dosfstools  4.1-2
ii  kbd 2.0.4-4
ii  util-linux-locales  2.36-1

-- no debconf information

-- 
The marvels of today's modern technology include the development of a
soda can, when discarded will last forever ... and a $7,000 car which
when properly cared for will rust out in two or three years.
   
I prefer to send and receive mail encrypted. Please send me your
public key, and if you do not have my public key, please let me
know. Thanks.

GPG fingerprint: 38F3 975C D173 4037 B397  8095 D4C9 C4FC 5460 8E68


signature.asc
Description: PGP signature

Bug#966467: please package 3.1.10 or newer

[Nicholas D Steeves]

Source: golang-github-go-ldap-ldap
Version: 2.5.1-4
Severity: normal
Control: block 966466 by -1

Sorry for the delay filing this bug.  I identified the blocking issue for 
Syncthing ≥ 1.5.0 but was slow to file it.

Bug#964433: libtomcat9-java: tomcatjss fails to build with the latest libtomcat9-java

[Timo Aaltonen]

On 28.7.2020 12.14, Timo Aaltonen wrote:
> On 7.7.2020 10.52, Timo Aaltonen wrote:
>> Package: libtomcat9-java
>> Version: 9.0.37-1
>> Severity: important
>>
>> Hi,
>>
>> A recent update has broke tomcatjss build:
>>
>> [javac] 
>> /<>/tomcat-8.5/src/org/dogtagpki/tomcat/JSSImplementation.java:25:
>>  error: package org.apache.tomcat.util.net.jsse does not exist
>> [javac] import org.apache.tomcat.util.net.jsse.JSSEImplementation;
>>
>> It built fine with 9.0.35-1 when 7.5.0~a1-1 was uploaded to experimental, 
>> now a new beta2
>> and the version in sid both fail.
>>
> 
> This is fixed upstream now:
> 
> https://marc.info/?l=tomcat-dev=159532237316863=2
> 
> I can upload a fix unless there are objections?

Bah, this is not enough as dogtag-pki instances fail to start, bnd would
need to be updated I'm told (bug 965201)


-- 
t

Bug#934619: libmaus2 FTBFS (mostly 32bit): error: no matching function for call

[Andreas Beckmann]

Followup-For: Bug #934619
Control: severity -1 normal

The outdated 32-bit binaries have been removed from the archive,
so this is no longer a regression.


Andreas

Bug#966466: tracking bug for syncthing 1.7.1 deps

[Nicholas D Steeves]

Package: syncthing
Version: 1.1.4~ds1-5
Severity: normal
Control: block -1 by 915649 966427

I was working on 1.5.1, but decided to do a quick check of what it would take 
to jump straight to 1.7.1.  My initial investigation showed the trip through 
NEW for blobloom would probably be the greatest delaying factor.

Next I'll diff go.mod between 1.2.0~ds1 and my WIP 1.7.1~ds1 and will manually 
check versions in sid, since I don't yet know a better way.

I'm also looking forward to the improvements in reducing the high load
issues that impact desktop interactivity (fixed in 1.6.x) :-)

Cheers,
Nicholas

Bug#925745: libgtextutils is marked for autoremoval from testing

[Pierre Gruet]

Hello,

C++11 introduced references on rvalues, which basically allows to use a
non-constant reference on a temporary object (ie waiting for
affectation). Before, temporary objects could only be references by a
const reference.

Thus, from there, it becomes a problem to have two implicit conversion
operators defined in the class TextLineReader (text_line_reader.h):

operator const std::string& () const { return line_string() ; }
operator std::string() const { return line_string(); }

A call such that

TextLineReader r(...);
std::string str=r;

becomes ambiguous as the compiler could use the affectation operator of
std::string that take a const std::string& as input (thus calling the
first above operator) *or* the affectation operator of std::string that
takes a reference on a rvalue as input (thus calling the second above
operator, which returns a temporary object).

I suggest removing the second one. The first one is needed, for instance, in

const std::string& str=r;

which is non-ambiguous, whereas

std::string str=r;

and

std::string str(r);

are ambiguous and can work with either of the two implicit conversion
operators of TextLineReader.


I will prepare an upload.

Bye,
Pierre

Bug#957914: Patch to fix linking with gcc-10

[Paul Gevers]

Control: tags -1 pending

Hi arnold,

On 28-07-2020 21:52, arnold metselaar wrote:
> Below and attached is a patch to make viking compile and link properly
> with gcc-10.

Awesome. Building right now.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#966422: bind9utils: dnssec-signzone -N unixtime behaves like increment

[Bernhard Schmidt]

On Tue, Jul 28, 2020 at 06:01:50PM +0200, Sven Strickroth wrote:

Dear Sven,

> > I think there is a (new in Buster?) protection against the serial of the
> > signed zone being lower than in the unsigned zone.
> 
> Thank you for digging into this!
> 
> This info helps me a least to quickly fix the issue by lowering the
> serial in the zone-template.
> 
> > So I'm reasonably sure upstream will see this as a feature.
> 
> Then upstream should issue a warning informing the user the requested
> option was ignored in order to prevent a lower serial number.

Please report this upstream at
https://gitlab.isc.org/isc-projects/bind9/-/issues . When you have a
bugid feel free to report back to we can tag this bug accordingly.

Bernhard


signature.asc
Description: PGP signature

Bug#966465: open-vm-tools-desktop: Stop recommending obsolete xserver-xorg-input-vmmouse

[Raphaël Hertzog]

Package: open-vm-tools-desktop
Version: 2:11.1.0-2
Severity: minor
User: de...@kali.org
Usertags: origin-kali

The package still recommends xserver-xorg-input-vmmouse but the package is
no longer available. It has been dropped a long time ago.

Please drop the recommends on this package.

Thank you!

Bug#957914: Patch to fix linking with gcc-10

[arnold metselaar]

Dear maintainer,

Below and attached is a patch to make viking compile and link properly with
gcc-10.

Suggested changelog entry:

src/babel.h (a_babel_file_list, a_babel_device_list): declare global
variables as extern, closes #957914

Kind regards,
Arnold Metselaar
---

diff --git a/src/babel.h b/src/babel.h
index ae2fa959..e2c18e6c 100644
--- a/src/babel.h
+++ b/src/babel.h
@@ -109,8 +109,8 @@ typedef struct {
 gchar *label;
 } BabelFile;

-GList *a_babel_file_list;
-GList *a_babel_device_list;
+extern GList *a_babel_file_list;
+extern GList *a_babel_device_list;

 void a_babel_foreach_file_with_mode (BabelMode mode, GFunc func, gpointer
user_data);
 void a_babel_foreach_file_read_any (GFunc func, gpointer user_data);
diff --git a/src/babel.h b/src/babel.h
index ae2fa959..e2c18e6c 100644
--- a/src/babel.h
+++ b/src/babel.h
@@ -109,8 +109,8 @@ typedef struct {
 gchar *label;
 } BabelFile;
 
-GList *a_babel_file_list;
-GList *a_babel_device_list;
+extern GList *a_babel_file_list;
+extern GList *a_babel_device_list;
 
 void a_babel_foreach_file_with_mode (BabelMode mode, GFunc func, gpointer user_data);
 void a_babel_foreach_file_read_any (GFunc func, gpointer user_data);

Bug#966462: apt: apt build-dep --download ... installs packages

[Jessica Clarke]

On Tue, Jul 28, 2020 at 12:14:12PM -0700, Vagrant Cascadian wrote:
> Package: apt
> Version: 1.8.2.1
> Severity: normal
>
> The behavior of "apt build-dep --download FOO" confusingly proceeds to
> install the build-deps of FOO. Seems like I wanted --download-only
> instead.
>
> The apt man page doesn't appear to even document the existence of "apt
> build-dep", or the --download flag.
>
> From a short dialog on IRC:
>
> 11:40 < vagrantc> TIL apt build-dep --download FOO ... installs the
> packages rather than just downloading them
> 11:42 < tumbleweed> sounds like a bug?
> 11:44 < _jwilk> Weird. --download-only does the right thing.
> 11:46 < tumbleweed> and that is what's in the manpage
> 11:47 < tumbleweed> is --download the inverse of --no-download then?
> 11:48 < vagrantc> i think i got the same with -d
> 11:48 < tumbleweed> nope , -d seems to do the right thing
> 11:49 < vagrantc> yes, i suppose it sounds like a bug
> 11:49 < vagrantc> e.g. it shouldn't work with unsupported options ...
> 11:49 < tumbleweed> I could imagine that that option has an effect when
> the config file sets the equivalent of --no-download
> 11:49 < tumbleweed> but I'm guessing
> 11:53 < vagrantc> right ...
> 11:54 < _jwilk> Not every --no-foo has a --foo counterpart. For example,
> there's --no-act, but --act is not a thing. So at the minimum
> the existence of --download should be documented, IMHO.

This technically true but slightly missing the point. There is an
inverse of --no-act, but it's --no-no-act, perhaps because of
implementation details for making it an alias of the *positive*
--simulate option. IMO that's one of the two real bugs.

> So I'm guessing the --download option needs to be documented, at
> least...

This is the other bug; the manpage just isn't overly helpful in how it
documents all the options. It always documents the option you need to
change the default, and expects you to work out based on:

> For boolean options you can override the config file by using
> something like -f-,--no-f, -f=no or several other variations.

that the opposite form exists (except for the --no-act weirdness). It's
consistent, but not always helpful. I think it would be best to just
list both options explicitly for everything, then searching always finds
it and there's never any doubt.

Jess

Bug#966464: opendmarc: CVE-2020-12460

[Salvatore Bonaccorso]

Source: opendmarc
Version: 1.4.0~beta1+dfsg-2
Severity: important
Tags: security upstream
Forwarded: https://github.com/trusteddomainproject/OpenDMARC/issues/64
X-Debbugs-Cc: Debian Security Team 
Control: found -1 1.3.2-6+deb10u1
Control: found -1 1.3.2-6

Hi,

The following vulnerability was published for opendmarc.

CVE-2020-12460[0]:
| OpenDMARC through 1.3.2 and 1.4.x through 1.4.0-Beta1 has improper
| null termination in the function opendmarc_xml_parse that can result
| in a one-byte heap overflow in opendmarc_xml when parsing a specially
| crafted DMARC aggregate report. This can cause remote memory
| corruption when a '\0' byte overwrites the heap metadata of the next
| chunk and its PREV_INUSE flag.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-12460
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-12460
[1] https://github.com/trusteddomainproject/OpenDMARC/issues/64

Regards,
Salvatore

Bug#966462: apt: apt build-dep --download ... installs packages

[Vagrant Cascadian]

Package: apt
Version: 1.8.2.1
Severity: normal

The behavior of "apt build-dep --download FOO" confusingly proceeds to
install the build-deps of FOO. Seems like I wanted --download-only
instead.

The apt man page doesn't appear to even document the existence of "apt
build-dep", or the --download flag.

From a short dialog on IRC:

11:40 < vagrantc> TIL apt build-dep --download FOO ... installs the
packages rather than just downloading them
11:42 < tumbleweed> sounds like a bug?
11:44 < _jwilk> Weird. --download-only does the right thing.
11:46 < tumbleweed> and that is what's in the manpage
11:47 < tumbleweed> is --download the inverse of --no-download then?
11:48 < vagrantc> i think i got the same with -d
11:48 < tumbleweed> nope , -d seems to do the right thing
11:49 < vagrantc> yes, i suppose it sounds like a bug
11:49 < vagrantc> e.g. it shouldn't work with unsupported options ...
11:49 < tumbleweed> I could imagine that that option has an effect when
the config file sets the equivalent of --no-download
11:49 < tumbleweed> but I'm guessing
11:53 < vagrantc> right ...
11:54 < _jwilk> Not every --no-foo has a --foo counterpart. For example,
there's --no-act, but --act is not a thing. So at the minimum
the existence of --download should be documented, IMHO.


So I'm guessing the --download option needs to be documented, at
least...

Thanks for maintaining apt!

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#966463: openblas breaks scipy autopkgtest: tests/test_vq.py::TestKMean::test_krandinit Segmentation fault

[Paul Gevers]

Source: openblas, scipy
Control: found -1 openblas/0.3.10+ds-1
Control: found -1 scipy/1.4.1-2
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of openblas the autopkgtest of scipy fails in
testing when that autopkgtest is run with the binary packages of
openblas from unstable. It passes when run with only packages from
testing. In tabular form:

   passfail
openblas   from testing0.3.10+ds-1
scipy  from testing1.4.1-2
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of openblas to
testing [1]. Due to the nature of this issue, I filed this bug report
against both packages. Can you please investigate the situation and
reassign the bug to the right package?

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

Paul

[1] https://qa.debian.org/excuses.php?package=openblas

https://ci.debian.net/data/autopkgtest/testing/amd64/s/scipy/6418132/log.gz

=== Testing: python3.8 scipy.cluster ===
= test session starts
==
platform linux -- Python 3.8.5, pytest-4.6.11, py-1.8.1, pluggy-0.13.0
-- /usr/bin/python3.8
cachedir: .pytest_cache
rootdir: /tmp/autopkgtest-lxc.5e7uwcse/downtmp/autopkgtest_tmp
collecting ... collected 111 items

tests/test_hierarchy.py::TestLinkage::test_linkage_non_finite_elements_in_distance_matrix
PASSED [  0%]
tests/test_hierarchy.py::TestLinkage::test_linkage_empty_distance_matrix
PASSED [  1%]
tests/test_hierarchy.py::TestLinkage::test_linkage_tdist PASSED
[  2%]
tests/test_hierarchy.py::TestLinkage::test_linkage_X PASSED
[  3%]
tests/test_hierarchy.py::TestLinkage::test_compare_with_trivial PASSED
[  4%]
tests/test_hierarchy.py::TestLinkage::test_optimal_leaf_ordering PASSED
[  5%]
tests/test_hierarchy.py::TestLinkageTies::test_linkage_ties PASSED
[  6%]
tests/test_hierarchy.py::TestInconsistent::test_inconsistent_tdist
PASSED [  7%]
tests/test_hierarchy.py::TestCopheneticDistance::test_linkage_cophenet_tdist_Z
PASSED [  8%]
tests/test_hierarchy.py::TestCopheneticDistance::test_linkage_cophenet_tdist_Z_Y
PASSED [  9%]
tests/test_hierarchy.py::TestMLabLinkageConversion::test_mlab_linkage_conversion_empty
PASSED [  9%]
tests/test_hierarchy.py::TestMLabLinkageConversion::test_mlab_linkage_conversion_single_row
PASSED [ 10%]
tests/test_hierarchy.py::TestMLabLinkageConversion::test_mlab_linkage_conversion_multiple_rows
PASSED [ 11%]
tests/test_hierarchy.py::TestFcluster::test_fclusterdata PASSED
[ 12%]
tests/test_hierarchy.py::TestFcluster::test_fcluster PASSED
[ 13%]
tests/test_hierarchy.py::TestFcluster::test_fcluster_monocrit PASSED
[ 14%]
tests/test_hierarchy.py::TestLeaders::test_leaders_single PASSED
[ 15%]
tests/test_hierarchy.py::TestIsIsomorphic::test_is_isomorphic_1 PASSED
[ 16%]
tests/test_hierarchy.py::TestIsIsomorphic::test_is_isomorphic_2 PASSED
[ 17%]
tests/test_hierarchy.py::TestIsIsomorphic::test_is_isomorphic_3 PASSED
[ 18%]
tests/test_hierarchy.py::TestIsIsomorphic::test_is_isomorphic_4A PASSED
[ 18%]
tests/test_hierarchy.py::TestIsIsomorphic::test_is_isomorphic_4B PASSED
[ 19%]
tests/test_hierarchy.py::TestIsIsomorphic::test_is_isomorphic_4C PASSED
[ 20%]
tests/test_hierarchy.py::TestIsIsomorphic::test_is_isomorphic_5 PASSED
[ 21%]
tests/test_hierarchy.py::TestIsIsomorphic::test_is_isomorphic_6 PASSED
[ 22%]
tests/test_hierarchy.py::TestIsIsomorphic::test_is_isomorphic_7 PASSED
[ 23%]
tests/test_hierarchy.py::TestIsValidLinkage::test_is_valid_linkage_various_size
PASSED [ 24%]
tests/test_hierarchy.py::TestIsValidLinkage::test_is_valid_linkage_int_type
PASSED [ 25%]
tests/test_hierarchy.py::TestIsValidLinkage::test_is_valid_linkage_empty
PASSED [ 26%]
tests/test_hierarchy.py::TestIsValidLinkage::test_is_valid_linkage_4_and_up
PASSED [ 27%]
tests/test_hierarchy.py::TestIsValidLinkage::test_is_valid_linkage_4_and_up_neg_index_left
PASSED [ 27%]
tests/test_hierarchy.py::TestIsValidLinkage::test_is_valid_linkage_4_and_up_neg_index_right
PASSED [ 28%]
tests/test_hierarchy.py::TestIsValidLinkage::test_is_valid_linkage_4_and_up_neg_dist
PASSED [ 29%]
tests/test_hierarchy.py::TestIsValidLinkage::test_is_valid_linkage_4_and_up_neg_counts
PASSED [ 30%]
tests/test_hierarchy.py::TestIsValidInconsistent::test_is_valid_im_int_type
PASSED [ 31%]
tests/test_hierarchy.py::TestIsValidInconsistent::test_is_valid_im_various_size
PASSED [ 32%]
tests/test_hierarchy.py::TestIsValidInconsistent::test_is_valid_im_empty
PASSED [ 33%]
tests/test_hierarchy.py::TestIsValidInconsistent::test_is_valid_im_4_and_up
PASSED [ 34%]
tests/test_hierarchy.py::TestIsValidInconsistent::test_is_valid_im_4_and_up_neg_index_left
PASSED [ 35%]

Bug#926808: fping: --timestamp should show missing responses too per host and line

[Axel Beckert]

Dear Witold,

Witold Baryluk wrote:
> In --loop or --count modes for example:
> 
> # fping --timestamp  -6 -A -d --count 10 2a00:1450:400a:802::3
> 
> 2a00:1450:400a:802::3 (2a00:1450:400a:802::3) : xmt/rcv/%loss = 10/0/100%
> #
> 
> Adding -u or -a doesn't help. Adding -u -a (both), is not supported.
> 
> I would expect something more useful, i.e.:
> 
> # fping --timestamp  -6 -A -d --count 10 2a00:1450:400a:802::3
> [1554914998.643838] 2a00:1450:400a:802::3 (2a00:1450:400a:802::3) : [0], 64 
> bytes, timeout, 1000ms (nan avg, 100% loss)
[...]
> or something like this.

Can you check if this upstream pull request implements what you ask
for? https://github.com/schweikert/fping/pull/175

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#966461: RFS: moc/1:2.6.0~svn-r3005-1 -- ncurses based console audio player

[Elimar Riesebieter]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: moc
   Version : 1:2.6.0~svn-r3005-1
   Upstream Author : Damian Pietras  
 * URL : https://moc.daper.net
 * License : GPL-2+
 * Vcs : https://salsa.debian.org/riesebie/moc
   Section : sound

It builds those binary packages:

  moc-ffmpeg-plugin - ncurses based console audio player - ffmpeg plugin
  moc - ncurses based console audio player

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

  https://mentors.debian.net/package/moc/
  https://salsa.debian.org/riesebie/moc

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

  dget -x 
https://mentors.debian.net/debian/pool/main/m/moc/moc_2.6.0~svn-r3005-1.dsc

Changes since the last upload:

 moc (1:2.6.0~svn-r3005-1) unstable; urgency=medium
 .
   * New upstream svn-version.
   * debian/control:
 Remove unused libdts-dev build dependency (Closes: 955293).
 Fix VCS-(Browser|Git):.
 Declare compliance with Debian Policy 4.5.0.
 Switched to debhelper (= 13).
   * Removed --as-needed linker flag.
 The bullseye toolchain defaults to linking with --as-needed and
 therefore it should no longer be necessary to inject this into the build.
   * Added metadata file.
   * Updated changelog.svn And witched to output locale en_US.utf8.

Thanks in advance
Elimar
-- 
  Alles, was viel bedacht wird, wird bedenklich!;-)
 Friedrich Nietzsche

Bug#966460: gradle: every taks fails with net/rubygrapefruit/platform/Memory

[Emilian Nowak]

Package: gradle
Version: 4.4.1-11
Severity: important

Dear Maintainer,
Each time I run gradle from package it fails the same way. Below example of
$ gradle help
FAILURE: Build failed with an exception.

* What went wrong:
net/rubygrapefruit/platform/Memory

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or
  --debug option to get more log output. Run with --scan to get full insights.

* Get more help at https://help.gradle.org



Adding --debug or --stacktrace gives same output.
I was trying with java-1.8 and java-11


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

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

Versions of packages gradle depends on:
ii  libgradle-core-java   4.4.1-11
ii  libgradle-plugins-java4.4.1-11
ii  openjdk-11-jre-headless [java8-runtime-headless]  11.0.5+10-1~bpo9+1
ii  oracle-java8-jdk [java8-runtime-headless] 8u171

gradle recommends no packages.

Versions of packages gradle suggests:
pn  gradle-doc  

-- no debconf information

Bug#966456: mutt: suddenly started ignoring $realname

[Antonio Terceiro]

On Tue, Jul 28, 2020 at 02:55:23PM -0300, Antonio Terceiro wrote:
> With this setup, I open mutt, hit "m" to compose, fill in "To:" and
> "Subject:", write something in $EDITOR, save, quit. Then I get:
> 
> From: f...@example.com
> 
> instead of
> 
> From: Foo Bar 
> 
> as expected. setting from to "Foo Bar " works, but this
> is a regression with regards to the bevavior of years or maybe decades.

I confirm that downgraging to 1.14.4-2 from snapshots.debian.org fixes
this. Indeed I just found #698267.

At the moment I am working around this by using:

set from="$realname "

in the config snippets source by my mbox-hooks.


signature.asc
Description: PGP signature

Bug#966459: linux: traffic class socket options (both IPv4/IPv6) inconsistent with docs/standards

[Thorsten Glaser]

Package: src:linux
Version: 5.7.6-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: t...@mirbsd.de

I’m using setsockopt to set the traffic class on sending and receive
it in control messages on receiving, for both IPv4 and IPv6.

The relevant documentation is the ip(7) manpage and, because the ipv6(7)
manpage doesn’t contain it, RFC3542.


For the receiving side, the corresponding socket options are:

• IPPROTO_IP ⇒ IP_RECVTOS, with an int argument 1 (as in the manpage)
• IPPROTO_IPV6 ⇒ IPV6_TCLASS, with an int argument 1 (as in the RFC)

The receiving CMSG is then supposed to contain the traffic class octet
as first byte in the corresponding CMSG_DATA:

   IP_RECVTOS (since Linux 2.2)
  If enabled, the IP_TOS ancillary message is passed with incoming
  packets.   It  contains  a byte which specifies the Type of Ser‐
  vice/Precedence field of the packet header.

… and…

   In the cmsghdr structure containing this ancillary data, the
   cmsg_level member will be IPPROTO_IPV6, the cmsg_type member will be
   IPV6_TCLASS, and the first byte of cmsg_data[] will be the first byte
   of the integer traffic class.

However, Linux has net/ipv6/datagram.c…

int tclass = ipv6_get_dsfield(ipv6_hdr(skb));
put_cmsg(msg, SOL_IPV6, IPV6_TCLASS, sizeof(tclass), );

… and net/ipv6/ipv6_sockglue.c…

int tclass = (int)ip6_tclass(np->rcv_flowinfo);
put_cmsg(, SOL_IPV6, IPV6_TCLASS, 
sizeof(tclass), );

… both setting them as int, breaking standards/documentation-compliant
code on all big endian platforms. Same in net/ipv4/ip_sockglue.c…

int tos = inet->rcv_tos;
put_cmsg(, SOL_IP, IP_TOS, sizeof(tos), );
… in one place, but…

put_cmsg(msg, SOL_IP, IP_TOS, 1, _hdr(skb)->tos);

… in ip_cmsg_recv_tos(), yielding inconsistent results for IPv4(!).


For the sending side, we use:

• IPPROTO_IP, IP_TOS, with an argument…
• IPPROTO_IPV6, IPV6_TCLASS, with an argument…

This is funny. The documentation says to use a byte for IPv4…

   IP_TOS (since Linux 1.0)
  Set or receive the Type-Of-Service (TOS) field that is sent with
  every IP packet originating from this socket.   It  is  used  to
  prioritize  packets  on  the network.  TOS is a byte.  There are

… and setsockopt works with a byte argument, but for IPv6, using a
byte causes EINVAL (but this is because RFC3542 says int, overriding
the itojun draft which said byte).

Looking at the kernel code, IP_TOS indeed reads a byte if the size
given is less than 4, an int otherwise… except bpf_setsockopt, which
expects an int. OK, should be no problem for my userspace code.
IPV6_TCLASS always expects an int. Unexpected but apparently okay
wrt. the documentation.


tl;dr: Receiving traffic class values from IP traffic is broken on
big endian platforms.

I place the following suggestion for discussion, to achieve maximum
portability: put 4 bytes into the CMSG for both IPv4 and IPv6, where
the first and fourth byte are, identically, traffic class, second and
third 0.

Please forward this upstream. Thanks!



-- Package-specific info:
** Version:
Linux version 5.7.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 9.3.0 
(Debian 9.3.0-14), GNU ld (GNU Binutils for Debian) 2.34) #1 SMP Debian 5.7.6-1 
(2020-06-24)

** Command line:
BOOT_IMAGE=/vmlinuz-5.7.0-1-amd64 root=/dev/sda4 ro rootdelay=5 syscall.x32=y 
vsyscall=emulate net.ifnames=0 kaslr pcie_aspm=force consoleblank=0

** Tainted: W (512)
 * kernel issued warning

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: LENOVO
product_name: 7673AG4
product_version: ThinkPad X61
chassis_vendor: LENOVO
chassis_version: Not Available
bios_vendor: LENOVO
bios_version: 7NET30WW (1.11 )
board_vendor: LENOVO
board_name: 7673AG4
board_version: Not Available

** Loaded modules:
ufs
hfs
dm_mod
loop
netlink_diag
snd_seq_dummy
cdc_acm
ctr
aes_generic
libaes
crypto_simd
cryptd
glue_helper
ccm
cpufreq_conservative
cpufreq_userspace
cpufreq_powersave
binfmt_misc
nft_counter
nft_chain_nat
xt_MASQUERADE
nf_nat
nf_conntrack
nf_defrag_ipv6
nf_defrag_ipv4
libcrc32c
nft_compat
nf_tables
x_tables
nfnetlink
tun
snd_seq_midi
snd_seq_midi_event
snd_rawmidi
snd_seq
snd_seq_device
snd_hda_codec_analog
snd_hda_codec_generic
ppdev
iwl4965
coretemp
snd_hda_intel
iwlegacy
kvm_intel
snd_intel_dspcfg
pcmcia
kvm
snd_hda_codec
mac80211
snd_hda_core
snd_hwdep
snd_pcm_oss
irqbypass
snd_mixer_oss
cfg80211
serio_raw
pcspkr
snd_pcm
sg
iTCO_wdt
yenta_socket
iTCO_vendor_support
thinkpad_acpi
pcmcia_rsrc
watchdog
pcmcia_core
snd_timer
libarc4
nvram
ledtrig_audio
snd
soundcore
ac
rfkill
parport_pc
evdev
parport
button
acpi_cpufreq
ext4
crc16
mbcache
jbd2
crc32c_generic
sd_mod
t10_pi
crc_t10dif
crct10dif_generic
crct10dif_common
ata_generic
i915
ata_piix
sdhci_pci
i2c_algo_bit
ahci

Bug#965230: closed by Felipe Sateler (Re: Bug#965230: pulseaudio: writes to mount point prior to /tmp being mounted)

[Felipe Sateler]

(Please keep the bug on CC).

On Tue, Jul 28, 2020 at 11:27 AM Edmund H. Ramm  wrote:

> Estimado Felipe,
>
> Felipe Sateler  writes:
>
> > [...]
> > Anyway, those directories are created when there is no runtime directory
> > for pulseaudio to use. That this is happening before /tmp is mounted, it
> > means that something is trying to use pulseaudio that early during boot.
> > That then it is created again, means some other user (or your own user,
> but
> > in an unclean environment) is trying to use pulseaudio.
> >
> > Who owns that directory? Do you have logs that may show who is creating
> > that?
>
>if I had, I'd supplied them. The user is (was) root, and the temporary
> directory is created from initramfs without leaving a trace in the journal.
> The only hint that something went wrong is when /tmp gets mounted on a then
> no longer clean mount point.
>

This is very weird. The initramfs should have an in-memory /tmp. Are you
sure it is created in the intiramfs?



-- 

Saludos,
Felipe Sateler

Bug#959910: dkms: improve dkms-autopkgtest

[Andreas Beckmann]

[resending after unarchiving]

On 7/28/20 6:55 PM, Gianfranco Costamagna wrote:
> Hello Andreas
> 
> 
> Unfortunately this dkms patch, while worked for most of the Ubuntu packages, 
> failed to work for 3 of them
> autopkgtest for broadcom-sta/6.30.223.271-14: amd64: Regression ♻ , arm64: 
> Ignored failure, armhf: Ignored failure, i386: Ignored failure, ppc64el: 
> Ignored failure, s390x: Ignored failure
> autopkgtest for iptables-netflow/2.5-2: amd64: Regression ♻ , arm64: 
> Regression ♻ , armhf: Regression ♻ , ppc64el: Regression ♻ , s390x: 
> Regression ♻
> autopkgtest for r8168/8.048.03-1: amd64: Regression ♻ , arm64: Regression ♻ , 
> armhf: Regression ♻ , i386: Ignored failure, ppc64el: Regression ♻ , s390x: 
> Regression ♻
> Additional info:
> 
> you can see e.g.
> https://autopkgtest.ubuntu.com/packages/b/broadcom-sta/groovy/amd64
> https://autopkgtest.ubuntu.com/packages/i/iptables-netflow/groovy/amd64
> https://autopkgtest.ubuntu.com/packages/r/r8168/groovy/amd64
> 
> I really don't know why they fail, I can see the stuff is not getting built, 
> and then something fails because of a parameter mismatch.
> 
> I uploaded 2.8.3 to sid some seconds ago, but I know it won't fix any of this 
> kind of issues.
> 
> Can you please have a look?
> 
> Also, dumping the failure log would be great in case of build failure...
> 
> G.
> 

I'll take a look ...

Bug#966458: ptpd: should provide time-daemon

[Bastian Germann]

Package: ptpd
Severity: normal

With bullseye, systemd depends on the virtual time-daemon package.
So if you have a bullseye system with systemd you end up with at least
one other time-daemon provider right now. Hence, ptpd should provide
time-daemon.

Bug#966457: jupyter-notebook: cannot open terminal - wrong URL 404

[Chad William Seys]

Package: jupyter-notebook
Version: 5.7.8-1
Severity: normal

Dear Maintainer,

When attempting to open a New->Terminal in a jupyter notebook a mostly 
blank page is displayed. (Page has header with Jupyter and Logout 
button, but rest is gray.)


At the console the following is displayed:
[I 11:46:46.037 NotebookApp] New terminal with automatic name: 1
[E 11:46:46.773 NotebookApp] Could not open static file ''
[W 11:46:47.095 NotebookApp] 404 GET 
/static/components/xterm.js-css/index.css (::1) 18.93ms 
referer=http://localhost:/terminals/1


These files may be located here instead:
/usr/lib/python3/dist-packages/notebook/static/components/term.js
/usr/lib/python3/dist-packages/notebook/static/components/term.js/term.js

A similar bug report is here:
https://github.com/jupyterhub/nbgitpuller/issues/45

Thanks!
C.


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

Kernel: Linux 4.19.0-9-amd64 (SMP w/2 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)
LSM: AppArmor: enabled

Versions of packages jupyter-notebook depends on:
ii  jupyter-core  4.4.0-2
ii  python3   3.7.3-1
ii  python3-notebook  5.7.8-1

jupyter-notebook recommends no packages.

jupyter-notebook suggests no packages.

-- no debconf information

Bug#966456: mutt: suddenly started ignoring $realname

[Antonio Terceiro]

Package: mutt
Version: 1.14.5-1
Severity: normal

Dear Maintainer,

I have, since several years, used a setup where I set $realname once in
my main configuration file, and set $from vi mbox-hooks depending on the
folder I have open. mutt has thus always used "$realname <$from>" as the
"From:" header in in my emails.

Suddenly, this stopped working. I have upgraded mutt on July 1st for the
last time, but this seems to have worked until some point in July 8th,
after which point all my outgoing emails went out with just "$from" in
"From:".

I can even reproduce this on a clean temporary account:

8<8<8<-
tmpuser@lemur:~$ whoami
tmpuser
tmpuser@lemur:~$ pwd
/home/tmpuser
tmpuser@lemur:~$ find
.
./.xauth
./.muttrc
./.bash_logout
./.viminfo
./.bash_profile
./Mail
./.cache
./.profile
./.bashrc
tmpuser@lemur:~$ cat .muttrc
set from="f...@example.com"
set realname="Foo Bar"
8<8<8<-

With this setup, I open mutt, hit "m" to compose, fill in "To:" and
"Subject:", write something in $EDITOR, save, quit. Then I get:

From: f...@example.com

instead of

From: Foo Bar 

as expected. setting from to "Foo Bar " works, but this
is a regression with regards to the bevavior of years or maybe decades.


-- Package-specific info:
Mutt 1.14.5 (2020-06-23)
Copyright (C) 1996-2020 Michael R. Elkins and others.
Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
Mutt is free software, and you are welcome to redistribute it
under certain conditions; type `mutt -vv' for details.

System: Linux 5.7.0-2-amd64 (x86_64)
ncurses: ncurses 6.2.20200212 (compiled with 6.2)
libidn2: 2.3.0 (compiled with 2.3.0)
hcache backend: tokyocabinet 1.4.48

Compiler:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 9.3.0-14' 
--with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs 
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr 
--with-gcc-major-version-only --program-suffix=-9 
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib 
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch 
--disable-werror --with-arch-32=i686 --with-abi=m64 
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
--enable-offload-targets=nvptx-none=/build/gcc-9-aHzuVo/gcc-9-9.3.0/debian/tmp-nvptx/usr,hsa
 --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu 
--host=x86_64-linux-gnu --target=x86_64-linux-gnu 
--with-build-config=bootstrap-lto-lean --enable-link-mutex
Thread model: posix
gcc version 9.3.0 (Debian 9.3.0-14) 

Configure options: '--build=x86_64-linux-gnu' '--prefix=/usr' 
'--includedir=\${prefix}/include' '--mandir=\${prefix}/share/man' 
'--infodir=\${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' 
'--disable-option-checking' '--disable-silent-rules' 
'--libdir=\${prefix}/lib/x86_64-linux-gnu' '--runstatedir=/run' 
'--disable-maintainer-mode' '--disable-dependency-tracking' 
'--with-mailpath=/var/mail' '--enable-compressed' '--enable-debug' 
'--enable-fcntl' '--enable-hcache' '--enable-gpgme' '--enable-imap' 
'--enable-smtp' '--enable-pop' '--enable-sidebar' '--enable-dotlock' 
'--enable-exact-address' '--disable-fmemopen' '--with-curses' '--with-gnutls' 
'--with-gss' '--with-idn2' '--with-mixmaster' '--with-sasl' '--without-gdbm' 
'--without-bdb' '--without-qdbm' '--with-tokyocabinet' 
'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 
-fdebug-prefix-map=/build/mutt-4iFDK5/mutt-1.14.5=. -fstack-protector-strong 
-Wformat -Werror=format-security' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now' 
'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'

Compilation CFLAGS: -Wall -pedantic -Wno-long-long -g -O2 
-fdebug-prefix-map=/build/mutt-4iFDK5/mutt-1.14.5=. -fstack-protector-strong 
-Wformat -Werror=format-security

Compile options:
-DOMAIN
+DEBUG
-HOMESPOOL  +USE_SETGID  +USE_DOTLOCK  +DL_STANDALONE  +USE_FCNTL  -USE_FLOCK   
+USE_POP  +USE_IMAP  +USE_SMTP  
-USE_SSL_OPENSSL  +USE_SSL_GNUTLS  +USE_SASL  +USE_GSS  +HAVE_GETADDRINFO  
+HAVE_REGCOMP  -USE_GNU_REGEX  
+HAVE_COLOR  +HAVE_START_COLOR  +HAVE_TYPEAHEAD  +HAVE_BKGDSET  
+HAVE_CURS_SET  +HAVE_META  +HAVE_RESIZETERM  +HAVE_FUTIMENS  
+CRYPT_BACKEND_CLASSIC_PGP  +CRYPT_BACKEND_CLASSIC_SMIME  +CRYPT_BACKEND_GPGME  
+EXACT_ADDRESS  -SUN_ATTACHMENT  
+ENABLE_NLS  -LOCALES_HACK  +HAVE_WC_FUNCS  +HAVE_LANGINFO_CODESET  

Bug#966455: support MIME digests

[John Scott]

Package: lists.debian.org
Severity: wishlist
X-Debbugs-Cc: 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

For clients that support it, MIME digests are much more clean. It keeps
header gobbledygook out of the mail body unless one opts to show it,
allows picking out a message to reply to so it's just like replying
to a non-digest mail (with proper headers and In-Reply-To, and without
needing to go fetch the link on lists.debian.org), and enables signatures
on OpenPGP/MIME and S/MIME mails to be preserved.

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

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

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT287WtmxUhmhucNnhyvHFIwKstpwUCXyBiqgAKCRByvHFIwKst
pxHDAQCx+z0usm2KoG5DzfSJakVpJXtYzV4Vtir6jkQiabUiEgEAvlu48VWVPTmR
x+I1CD2ITSYcAlMl3jptq6/6Gr2u0Q0=
=+JJi
-END PGP SIGNATURE-

Bug#966217: mystiq: Consider having package team-maintained in Debian Multimedia Team

[Pablo Mestre]

Hi Boyuan,

Thanks for your email. i will read the Debian Multimedia Team Wiki and
take a decition.

Regards,
Pablo


El 7/24/20 a las 4:21 PM, Boyuan Yang escribió:
> Source: mystiq
> Version: 20.03.23-1
> Severity: wishlist
>
> Dear Debian mystiq package maintainer,
>
> I believe mystiq is worthwhile to be team-maintained under Debian Multimedia
> Team (https://wiki.debian.org/DebianMultimedia). You may further read this
> Debian Wiki page on how the Multimedia Team works.
>
> If you are willing to have this package team-maintained in the multimedia-
> team, you are welcome to put "Debian Multimedia Maintainers <
> debian-multime...@lists.debian.org>" into the maintainer field or the
> uploaders field in your package. There is no need to further move the git
> packaging repo on Salsa GitLab since the current git repo can be made to be
> grant write permission to the multimedia-team members if necessary.
>
> Thanks,
> Boyuan Yang

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Pablo Mestre Drake
  ⣾⠁⢠⠒⠀⣿⡁  --
  ⢿⡄⠘⠷⠚⠋   https://debian.org
  ⠈⠳⣄  Debian, the universal operating system.




signature.asc
Description: OpenPGP digital signature

Bug#966220: ITP: golang-github-evilsocket-islazy -- Set of opinionated packages, objects, helpers and functions

[Francisco Vilmar Cardoso Ruviaro]

Hi,

I believe I didn't describe my doubt enough,
upstream mentions in README.md the message "This library was made with hearts by
Simone Margaritelli and it's released under the GPL 3 license" and in LICENSE.md
I find "GPL version 3 or later".

The upstream did not attach the license notices to the program at the beginning
of each source file.

So I wonder, when he mentions the GPL-3 in REAME.md, is it strictly? or would he
allow any later version?

As I was in doubt, I found it appropriate to ask if he could clarify whether the
correct license is GPL-3 or GPL-3+ (any later version) by changing the README.md
or LICENSE.md file.

> https://github.com/evilsocket/islazy/issues/11

Regards,
-- 
Francisco Vilmar Cardoso Ruviaro 
4096R: 1B8C F656 EF3B 8447 2F48 F0E7 82FB F706 0B2F 7D00

Bug#966215: mystiq: Please also enable build on other architectures

[Pablo Mestre]

Hi,

I will check this and update the package.

Thanks for the notice.


Pablo

El 7/24/20 a las 4:15 PM, Boyuan Yang escribió:
> Source: mystiq
> Version: 20.03.23-1
> Severity: minor
>
> Dear Debian mystiq maintainer,
>
> Thanks for maintaining package mystiq in Debian. I noticed that this software
> was instructed to only build on amd64 architecture. Ideally this package
> should be built on any architecture currently supported by Debian, not only
> limited to amd64. Is there any specific need in the package that can only be
> achieved on amd64?
>
> If the software can function well on other hardware architectures, please
> consider enabling build for them. This can be done by using "Architecture:
> any" instead of "Architecture: amd64" in debian/control file.
>
-- 
  ⢀⣴⠾⠻⢶⣦⠀  Pablo Mestre Drake
  ⣾⠁⢠⠒⠀⣿⡁  --
  ⢿⡄⠘⠷⠚⠋   https://debian.org
  ⠈⠳⣄  Debian, the universal operating system.




signature.asc
Description: OpenPGP digital signature

Bug#966454: RM: golang-github-unknwon-cae/0.0~git20160715.0.c6aac99-4

[Moritz Muehlenhoff]

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

Please remove 0.0~git20160715.0.c6aac99-4 from stable. There are
open security issues, upstream development has stopped and
there are no reverse deps.

Cheers,
Moritz

Bug#966453: RM: golang-github-unknwon-cae -- RoQA; Orphaned, open security issues, dead upstream, no rdeps

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please golang-github-unknwon-cae. It was once introduced for gitea, is 
security-buggy
and there are no remaining rdeps.

Cheers,
Moritz

Bug#964139: network-manager: Please restore removed init script.

[Martin Steigerwald]

Dear Michael!

Again I ask you to reconsider and put the init script back in. If that 
would be too much work for you, I am sure someone would be willing to 
provide a patch.

I like to remind you about the winning choice of last years GR¹. It is 
specifically labeled as:

Option 2 "B: Systemd but we support exploring alternatives"

Please note the "but we support exploring alternatives".

Also look at the following excerpt of the choice:

"""
The Debian project recognizes that systemd service units are the
preferred configuration for describing how to start a daemon/service.
However, Debian remains an environment where developers and users can
explore and develop alternate init systems and alternatives to systemd
features. Those interested in exploring such alternatives need to
provide the necessary development and packaging resources to do that
work. Technologies such as elogind that facilitate exploring
alternatives while running software that depends on some systemd
interfaces remain important to Debian. It is important that the project
support the efforts of developers working on such technologies where
there is overlap between these technologies and the rest of the project,
for example by reviewing patches and participating in discussions in a
timely manner.
"""

Not only in my point of view the GR last year¹ does not mean that 
"systemd has won!". Especially the GR does not endorse "drop all init 
scripts".

Additionally you provided no reason whatsoever for the removal of the 
init script in the changelog:

"""
network-manager (1.25.91-1) unstable; urgency=medium

  * New upstream version 1.25.91 (1.26 rc2)
  * Remove SysV init script

 -- Michael Biebl <[…]>  Thu, 02 Jul 2020 01:17:08 +0200
"""

And you did not answer to this bug report since almost a month except 
for setting its severity to "wishlist".

Removing the init script breaks existing systems using something else 
than systemd together with Network Manager. This is a use case that 
worked for a long, long time. It still does work once the init script is 
copied back after removal. There is no warning in debconf, no 
explanation in README.Debian or NEWS.Debian. All current Debian Buster 
users with something else than systemd as PID 1 and with Network Manager 
would be left in the dark about why the upgrade broke their networking 
setup.

On the other hand I do not see any benefit from removing the init script. 
All it caused up to now is further friction.

If you have doubts about maintaining and bug fixing the init script, in 
case there are bugs, I am sure someone would be willing to do that. 
Current support for sysvinit, runit, elogind and other alternatives to 
Systemd and (some of) it's parts is pretty good in Debian, to a great 
extent thanks to the wonderful cooperation with the Devuan project.

So please reconsider.

[1] https://www.debian.org/vote/2019/vote_002

Thank you,
-- 
Martin

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

Bug#964013: lintian: embedded-javascript-library should flag sphinx files too

[Andreas Beckmann]

Followup-For: Bug #964013
Control: reopen -1

Hi,

I stumbled upon this while trying to fix

W: pocl-doc: embedded-javascript-library 
usr/share/doc/pocl-doc/html/_static/language_data.js please use sphinx 

language_data.js seems to be a false positive as long as
sphinx^Wthe-correct-sphinx-js-package (libjs-sphinxdoc?) does not provide
a linkable "master" copy. (And then it should be handled by dh_sphinxdoc.)


Andreas

PS: doctools.js and searchtools.js are correctly identified :-)

Bug#966452: ITP: r-bioc-biocsingular -- Singular Value Decomposition for Bioconductor Packages

[Steffen Möller]

Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name    : r-bioc-biocsingular
 Version : 1.4.0
 Upstream Author : Aaron Lun
* URL : https://bioconductor.org/packages/BiocSingular/
* License : GPL-3
 Programming Lang: GNU R
 Description : Singular Value Decomposition for Bioconductor Packages
Implements exact and approximate methods for singular value
decomposition and principal components analysis, in a framework that
allows them to be easily switched within Bioconductor packages or
workflows. Where possible, parallelization is achieved using
the BiocParallel framework.

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

Bug#966451: cloud.debian.org: systemd-growfs@-.service fails on arm64 instance types

[Noah Meyerhans]

Package: cloud.debian.org
Severity: important
User: cloud.debian@packages.debian.org
Usertags: aws image

Testing the current buster releases for [mcr]6gd.* instance type support
reveals an issue that leads the instances to boot to "degraded" state in
systemd.  The failing unit is systemd-growfs@-.service:

admin@ip-172-31-13-14:~$ systemctl status systemd-growfs@-.service
● systemd-growfs@-.service - Grow File System on /
   Loaded: loaded (/run/systemd/generator/systemd-growfs@-.service; generated)
   Active: failed (Result: exit-code) since Tue 2020-07-28 16:14:54 UTC; 1min 
2s ago
 Docs: man:systemd-growfs@.service(8)
  Process: 271 ExecStart=/lib/systemd/systemd-growfs / (code=exited, 
status=1/FAILURE)
 Main PID: 271 (code=exited, status=1/FAILURE)

Jul 28 16:14:54 debian systemd-growfs[271]: Partition size 8455699968 is not a 
multiple of the blocksize 4096, ignoring 3584 bytes
Jul 28 16:14:54 debian systemd-growfs[271]: Failed to resize "/" to 2064379 
blocks (ext4): Read-only file system
Jul 28 16:14:54 debian systemd[1]: systemd-growfs@-.service: Main process 
exited, code=exited, status=1/FAILURE
Jul 28 16:14:54 debian systemd[1]: systemd-growfs@-.service: Failed with result 
'exit-code'.
Jul 28 16:14:54 debian systemd[1]: Failed to start Grow File System on /.

This does not seem limited to the local-NVMe instance types (with the "d" in
the first field), as I have reproduced the issue on c6g.xlarge as well:

admin@ip-172-31-14-76:~$ systemctl status systemd-growfs@-.service
● systemd-growfs@-.service - Grow File System on /
   Loaded: loaded (/run/systemd/generator/systemd-growfs@-.service; generated)
   Active: failed (Result: exit-code) since Tue 2020-07-28 16:24:22 UTC; 1min 
29s ago
 Docs: man:systemd-growfs@.service(8)
  Process: 256 ExecStart=/lib/systemd/systemd-growfs / (code=exited, 
status=1/FAILURE)
 Main PID: 256 (code=exited, status=1/FAILURE)

Warning: Journal has been rotated since unit was started. Log output is 
incomplete or unavailable.
admin@ip-172-31-14-76:~$ ec2metadata --instance-type
c6g.xlarge

Instances were tested in us-east-1.  I don't think this has always occurred
on the 6g arm64 instance types, but it seems to be reproducible
approximately 100% of the time right now.

Bug#966450: RFS: ipmitool/1.8.18-9 [RC] -- utility for IPMI control with kernel driver or LAN interface (daemon)

[Jörg Frings-Fürst]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

   Package name: ipmitool
   Version : 1.8.18-9
   Upstream Author : Alexander Amelkin 
   URL : https://github.com/ipmitool/ipmitool
   License : BSD-3-clause
   Vcs : https://jff.email/cgit/ipmitool.git
   Section : utils

It builds those binary packages:

  ipmitool - utility for IPMI control with kernel driver or LAN interface
(daemon)

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/i/ipmitool/ipmitool_1.8.18-9.dsc

or from git

 https://jff.email/cgit/ipmitool.git/?h=release%2Fdebian%2F1.8.18-9

Changes since the last upload:

 ipmitool (1.8.18-9) unstable; urgency=medium
 .
   * New debian/patches/0005-gcc10.patch: Fix ftbfs with gcc-10
 (Closes: #957371).
   * Refresh debian/patches/0115-typo.patch.
   * Remove not longer used patches:
 - 0605-manpage_typo.patch
 - 0105-typo.patch
 - 0610-readme_typo.patch
 - 0001-Dialect_change.patch
   * Declare compliance with Debian Policy 4.5.0 (No changes needed).
   * Switch to debhelper-compat level 13.
   * debian/ipmitool.maintscript:
 - Fix syntax (Closes: #947384).

CU
Jörg

-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema:  SYR8SJXB
Wire: @joergfringsfuerst
Skype:joergpenguin
Ring: jff
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.



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

Bug#966422: bind9utils: dnssec-signzone -N unixtime behaves like increment

[Sven Strickroth]

Am 28.07.2020 um 17:38 schrieb Bernhard Schmidt:
> I think there is a (new in Buster?) protection against the serial of the
> signed zone being lower than in the unsigned zone.

Thank you for digging into this!

This info helps me a least to quickly fix the issue by lowering the
serial in the zone-template.

> So I'm reasonably sure upstream will see this as a feature.

Then upstream should issue a warning informing the user the requested
option was ignored in order to prevent a lower serial number.

-- 
Best regards,
 Sven Strickroth
 PGP key id F5A9D4C4 @ any key-server

Bug#801522: Adding a man page

[Eric Mertens]

Hi,

I’m working on a simple man page inspired by what I found for irssi. I haven’t 
made a man page before and I’d appreciate any feedback.

https://github.com/glguy/irc-core/blob/v2/glirc.1 


Best regards,
Eric Mertens

Bug#966409: libjpeg-turbo: versions in debian/*.symbols files are missing the epochs

[Mike Gabriel]

Hi Pabs,

On  Di 28 Jul 2020 09:04:08 CEST, Paul Wise wrote:


Source: libjpeg-turbo
Version: 1:2.0.5-1
Severity: serious

The versions in the debian/*.symbols files are missing the epochs. This
means that packages using symbols newer than buster will not upgrade
libjpeg62-turbo and libturbojpeg0 when being upgraded to bullseye.

For example if I install bullseye libjpeg-turbo-progs on buster, the
programs will not work as libjpeg62-turbo and libturbojpeg0 will not be
upgraded so the new symbols like jpeg_write_icc_profile are missing.

$ rmadison -u debian libjpeg-turbo
libjpeg-turbo | 1:1.3.1-12| oldoldstable   | source
libjpeg-turbo | 1:1.5.1-2 | oldstable  | source
libjpeg-turbo | 1:1.5.2-2 | stable | source
libjpeg-turbo | 1:1.5.2-2 | testing| source
libjpeg-turbo | 1:1.5.2-2 | unstable   | source
libjpeg-turbo | 1:1.5.2-2 | unstable-debug | source
libjpeg-turbo | 1:2.0.5-1 | unstable   | source
libjpeg-turbo | 1:2.0.5-1 | unstable-debug | source

$ grep -v 1.3.1 debian/*.symbols | grep -v 1.2.90 | grep -v 1.4.0 |  
grep -v 1.5.0

debian/libjpeg62-turbo.symbols:libjpeg.so.62 libjpeg62-turbo #MINVER#
debian/libjpeg62-turbo.symbols:* Build-Depends-Package: libjpeg62-turbo-dev
debian/libjpeg62-turbo.symbols: jpeg_read_icc_profile@LIBJPEG_6.2 2.0.2
debian/libjpeg62-turbo.symbols: jpeg_write_icc_profile@LIBJPEG_6.2 2.0.2
debian/libturbojpeg0.symbols:libturbojpeg.so.0 libturbojpeg0 #MINVER#
debian/libturbojpeg0.symbols:* Build-Depends-Package: libturbojpeg0-dev
debian/libturbojpeg0.symbols: TURBOJPEG_2.0@TURBOJPEG_2.0 2.0.2
debian/libturbojpeg0.symbols: tjGetErrorCode@TURBOJPEG_2.0 2.0.2
debian/libturbojpeg0.symbols: tjGetErrorStr2@TURBOJPEG_2.0 2.0.2
debian/libturbojpeg0.symbols: tjLoadImage@TURBOJPEG_2.0 2.0.2
debian/libturbojpeg0.symbols: tjSaveImage@TURBOJPEG_2.0 2.0.2

# cat /etc/apt/sources.list
deb https://deb.debian.org/debian buster main

# apt -qq install libjpeg-turbo-progs
The following additional packages will be installed:
  libjpeg62-turbo libturbojpeg0
The following NEW packages will be installed:
  libjpeg-turbo-progs libjpeg62-turbo libturbojpeg0
0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 266 kB/399 kB of archives.
After this operation, 1275 kB of additional disk space will be used.
Do you want to continue? [Y/n]
debconf: delaying package configuration, since apt-utils is not installed
Selecting previously unselected package libjpeg62-turbo:amd64.
(Reading database ... 12518 files and directories currently installed.)
Preparing to unpack .../libjpeg62-turbo_1%3a1.5.2-2+b1_amd64.deb ...
Unpacking libjpeg62-turbo:amd64 (1:1.5.2-2+b1) ...
Selecting previously unselected package libturbojpeg0:amd64.
Preparing to unpack .../libturbojpeg0_1%3a1.5.2-2+b1_amd64.deb ...
Unpacking libturbojpeg0:amd64 (1:1.5.2-2+b1) ...
Selecting previously unselected package libjpeg-turbo-progs.
Preparing to unpack .../libjpeg-turbo-progs_1%3a1.5.2-2+b1_amd64.deb ...
Unpacking libjpeg-turbo-progs (1:1.5.2-2+b1) ...
Setting up libturbojpeg0:amd64 (1:1.5.2-2+b1) ...
Setting up libjpeg62-turbo:amd64 (1:1.5.2-2+b1) ...
Setting up libjpeg-turbo-progs (1:1.5.2-2+b1) ...
Processing triggers for libc-bin (2.28-10) ...

# cat /etc/apt/sources.list | grep buster | sed s/buster/sid/ >>  
/etc/apt/sources.list


# cat /etc/apt/sources.list
deb https://deb.debian.org/debian buster main
deb https://deb.debian.org/debian sid main

# apt update
Hit:1 https://deb.debian.org/debian buster InRelease
Get:2 https://deb.debian.org/debian sid InRelease [146 kB]
Get:3 https://deb.debian.org/debian sid/main amd64 Packages [8345 kB]
Fetched 8491 kB in 6s (1365 kB/s)
Reading package lists... Done
Building dependency tree
Reading state information... Done
126 packages can be upgraded. Run 'apt list --upgradable' to see them.

# apt policy libjpeg-turbo-progs
libjpeg-turbo-progs:
  Installed: 1:1.5.2-2+b1
  Candidate: 1:2.0.5-1
  Version table:
 1:2.0.5-1 500
500 https://deb.debian.org/debian sid/main amd64 Packages
 *** 1:1.5.2-2+b1 500
500 https://deb.debian.org/debian buster/main amd64 Packages
100 /var/lib/dpkg/status

# apt install libjpeg-turbo-progs=1:2.0.5-1
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be upgraded:
  libjpeg-turbo-progs
1 upgraded, 0 newly installed, 0 to remove and 125 not upgraded.
Need to get 131 kB of archives.
After this operation, 51.2 kB of additional disk space will be used.
Get:1 https://deb.debian.org/debian sid/main amd64  
libjpeg-turbo-progs amd64 1:2.0.5-1 [131 kB]

Fetched 131 kB in 1s (227 kB/s)
debconf: delaying package configuration, since apt-utils is not installed
(Reading database ... 12558 files and directories currently installed.)
Preparing to unpack .../libjpeg-turbo-progs_1%3a2.0.5-1_amd64.deb ...
Unpacking libjpeg-turbo-progs (1:2.0.5-1) over (1:1.5.2-2+b1) ...
Setting up libjpeg-turbo-progs (1:2.0.5-1) 

Bug#966421: libjpeg-turbo FTBFS on alpha/mips64el/powerpc/sparc64: test failures

[Mike Gabriel]

Hi Adrian,

On  Di 28 Jul 2020 13:43:34 CEST, Adrian Bunk wrote:


Source: libjpeg-turbo
Version: 1:2.0.2-1~exp1
Severity: serious
Tags: ftbfs patch

https://buildd.debian.org/status/package.php?p=libjpeg-turbo

...
177/302 Test  #83: djpeg-shared-3x2-float-prog-cmp  
...***Failed0.01 sec

testout_3x2_float.ppm: FAILED.  Checksum is f6bfab038438ed8f5522fbd33595dcdc
...
267/302 Test #234: djpeg-static-3x2-float-prog-cmp  
...***Failed0.01 sec

testout_3x2_float.ppm: FAILED.  Checksum is f6bfab038438ed8f5522fbd33595dcdc
...
99% tests passed, 2 tests failed out of 302

Total Test time (real) = 186.96 sec

The following tests FAILED:
 83 - djpeg-shared-3x2-float-prog-cmp (Failed)
234 - djpeg-static-3x2-float-prog-cmp (Failed)
Errors while running CTest
make[1]: *** [Makefile:121: test] Error 8


For determining the correct md5 of expected test results
libjpeg-turbo wrongly guesses for some architectures.

This is fixed by the first commit in
https://salsa.debian.org/debian/libjpeg-turbo/-/merge_requests/2


Thanks for finding patches for these issues. I will be on VAC over the  
next two weeks. Please NMU (ideally with commits to the packaging  
Git). Also coordinate with Paul Wise (see #966419).


I'll look into this in the second week of August, otherwise.

Thanks
Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpEzKAPOuNjL.pgp
Description: Digitale PGP-Signatur

Bug#966423: inkscape: Copy & Paste of objects is broken

[Alex]

Package: inkscape
Version: 1.0-3
Severity: important

Dear Maintainer,
in the current inkscape version in Debian testing, copy & paste (or at
least copy) is broken.

The log message on the console is

SPDocument::doUnref(): invalid ref count! -1

when I try to copy any object. The copy operation is not added to undo
history and I cannot paste the object.

with kind regards,
Alex


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

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

Versions of packages inkscape depends on:
ii  libatkmm-1.6-1v5   2.28.0-2
ii  libc6  2.31-1
ii  libcairo2  1.16.0-4
ii  libcairomm-1.0-1v5 1.12.2-4
ii  libcdr-0.1-1   0.1.6-1+b1
ii  libdbus-glib-1-2   0.110-5
ii  libdouble-conversion3  3.1.5-5
ii  libfontconfig1 2.13.1-4.2
ii  libfreetype6   2.10.2+dfsg-3
ii  libgc1c2   1:7.6.4-0.4
ii  libgcc-s1  10.1.0-6
ii  libgdk-pixbuf2.0-0 2.40.0+dfsg-5
ii  libgdl-3-5 3.34.0-1
ii  libglib2.0-0   2.64.4-1
ii  libglibmm-2.4-1v5  2.64.2-2
ii  libgomp1   10.1.0-6
ii  libgsl25   2.6+dfsg-2
ii  libgtk-3-0 3.24.20-1
ii  libgtkmm-3.0-1v5   3.24.2-1
ii  libgtkspell3-3-0   3.0.10-1
ii  libharfbuzz0b  2.6.4-1+b1
ii  libjpeg62-turbo1:1.5.2-2+b1
ii  liblcms2-2 2.9-4+b1
ii  libmagick++-6.q16-88:6.9.10.23+dfsg-2.1+b2
ii  libpango-1.0-0 1.44.7-4
ii  libpangocairo-1.0-01.44.7-4
ii  libpangoft2-1.0-0  1.44.7-4
ii  libpangomm-1.4-1v5 2.42.1-1
ii  libpng16-161.6.37-2
ii  libpoppler-glib8   0.71.0-6
ii  libpoppler82   0.71.0-6
ii  libpotrace01.16-2
ii  librevenge-0.0-0   0.0.4-6+b1
ii  libsigc++-2.0-0v5  2.10.2-1
ii  libsoup2.4-1   2.70.0-1
ii  libstdc++6 10.1.0-6
ii  libvisio-0.1-1 0.1.7-1+b1
ii  libwpg-0.3-3   0.3.3-1
ii  libx11-6   2:1.6.9-2+b1
ii  libxml22.9.10+dfsg-5+b1
ii  libxslt1.1 1.1.34-4
ii  python33.8.2-3
ii  zlib1g 1:1.2.11.dfsg-2

Versions of packages inkscape recommends:
ii  aspell   0.60.8-1
ii  fig2dev  1:3.2.7b-4
ii  imagemagick  8:6.9.10.23+dfsg-2.1+b2
ii  imagemagick-6.q16 [imagemagick]  8:6.9.10.23+dfsg-2.1+b2
ii  libimage-magick-perl 8:6.9.10.23+dfsg-2.1
ii  libwmf-bin   0.2.8.4-17
ii  python3-lxml 4.5.2-1
ii  python3-numpy1:1.18.4-1
ii  python3-scour0.37-4

Versions of packages inkscape suggests:
pn  dia   
pn  inkscape-tutorials
pn  libsvg-perl   
pn  libxml-xql-perl   
ii  pstoedit  3.75-1
pn  python3-uniconvertor  
ii  ruby  1:2.7+1

-- no debconf information

Bug#965254: RM: openhackware/0.4.1+git-20140423.c559da7c-4.1

[Paul Gevers]

Control: reassign -1 ftp.debian.org

Hi Michael,

On 28-07-2020 10:00, Michael Tokarev wrote:
> 28.07.2020 10:53, Paul Gevers wrote:
> ..
>> These request should normally be filed against ftp.debian.org and the
>> package should be removed from unstable first (and then it's
>> automatically removed from testing). Is there any reason why you request
>> the removal from testing or should the bug just be reassigned?
> 
> Hmm, now I'm confused.
> 
> Initially I was about to file the bugreport against ftp.d.o, but
> reportbug, after asking questions, told me I should use release.d.o
> instead and stopped.. so I did just that.. :)

I admit it's confusing, but it states: Is the removal to be done in a
suite other than "unstable"? Don't select anything for "unstable"
 

I guess we should request reportbug to fix the experience because you're
not the first one to make the mistake.

> Given this background, I'm kindly asking for little help on this,
> is just a reassign enough or should I do something else? reportbug
> does quite some housekeeping..

Done in the first line.

> Yes it definitely should be removed from unstable, not from testing,
> testing should follow.

Ack.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#966422: bind9utils: dnssec-signzone -N unixtime behaves like increment

[Bernhard Schmidt]

Control: found -1 1:9.11.5.P4+dfsg-5.1
Control: found -1 1:9.16.4-1

> I recently upgraded from Debian 9.13 to 10.4. Starting from this date 
> "dnssec-signzone -N unixtime" does not work any more causing my DNS slaves to 
> fail receiving changes.
> 
> With Debian 9 "dnssec-signzone -N unixtime" uses the current unix timestamp 
> as the serial numer for the generated signed zone, however, with the version 
> shipped with Debian 10 the serial number is just incremented from the to be 
> signd zone file. As I use a common zone-template for a huge nubmer of zones, 
> every further signing of the template will use the very same serial numer 
> (template serial number + 1).
> 
> I use the following command to sign my zones (using a script):
>  /usr/sbin/dnssec-signzone -o ZONE.TLD. -e +1209600 -N unixtime zone.db 
> K*.private
> 
> I don't get any warning or error. I checked that "-N date" uses the current 
> date, however, "date" does not fit the needs of my scenario 8see above). 
> Using "-N something" causes an error.

I have confirmed this in sid (BIND 9.16)

I think there is a (new in Buster?) protection against the serial of the
signed zone being lower than in the unsigned zone.

$ grep serial lrz.eu
2020072002 ; serial
$ /usr/sbin/dnssec-signzone -o lrz.eu -e +1209600 -N unixtime lrz.eu
K*.private
dnssec-signzone: warning: lrz.eu:16: using RFC1035 TTL semantics
Verifying the zone using the following algorithms: RSASHA256.
Zone fully signed:
Algorithm: RSASHA256: KSKs: 1 active, 0 stand-by, 0 revoked
  ZSKs: 1 active, 0 stand-by, 0 revoked
lrz.eu.signed

$ grep serial lrz.eu.signed
2020072003 ; serial

But

$ grep serial lrz.eu
1 ; serial
$ /usr/sbin/dnssec-signzone -o lrz.eu -e +1209600 -N unixtime lrz.eu
K*.private
dnssec-signzone: warning: lrz.eu:16: using RFC1035 TTL semantics
Verifying the zone using the following algorithms: RSASHA256.
Zone fully signed:
Algorithm: RSASHA256: KSKs: 1 active, 0 stand-by, 0 revoked
  ZSKs: 1 active, 0 stand-by, 0 revoked
lrz.eu.signed
$ grep serial lrz.eu.signed
1595950641 ; serial

So I'm reasonably sure upstream will see this as a feature.

Bernhard

Bug#966449: coreutils 8.32-3 FTBFS on arm64 (and proposed fix)

[Sergio Durigan Junior]

Package: coreutils
Version: 8.32-3
Severity: serious
Tags: patch ftbfs

Hi,

The current coreutils version FTBFS on arm64:

src/ls.c: In function 'print_dir':
src/ls.c:3026:24: error: 'SYS_getdents' undeclared (first use in this 
function); did you mean 'SYS_getdents64'?
 3026 |   if (syscall (SYS_getdents, dirfd (dirp), NULL, 0) == -1
  |^~~~
  |SYS_getdents64
src/ls.c:3026:24: note: each undeclared identifier is reported only once for 
each function it appears in

This has been reported upstream in
.
The fix upstream adopted is to restore the behaviour of ls on removed
directories back to what it was on 8.31.

I've backported the patches needed to fix the issue, so I'm proposing
them here.  Ubuntu coreutils is already carrying these patches and the
ARM64 build passes there.

Thanks!

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/

diff -Nru coreutils-8.32/debian/changelog coreutils-8.32/debian/changelog
--- coreutils-8.32/debian/changelog	2020-07-20 14:09:06.0 -0400
+++ coreutils-8.32/debian/changelog	2020-07-28 10:50:52.0 -0400
@@ -1,3 +1,16 @@
+coreutils (8.32-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS on ARM64.
+- d/p/restore-ls-behavior-8.31.patch: Upstream patch to restore
+  coreutils ls' 8.31 behavior on removed directories, which is
+  necessary to prevent using SYS_getdents that doesn't exist on
+  ARM64.
+- d/p/improve-removed-directory-test.patch: Upstream patch to
+  improve ls' removed-directory test.
+
+ -- Sergio Durigan Junior   Tue, 28 Jul 2020 10:50:52 -0400
+
 coreutils (8.32-3) unstable; urgency=low
 
   * build with libgmp now that apt pulls it in anyway (Closes: #64527)
diff -Nru coreutils-8.32/debian/patches/improve-removed-directory-test.patch coreutils-8.32/debian/patches/improve-removed-directory-test.patch
--- coreutils-8.32/debian/patches/improve-removed-directory-test.patch	1969-12-31 19:00:00.0 -0500
+++ coreutils-8.32/debian/patches/improve-removed-directory-test.patch	2020-07-28 10:50:23.0 -0400
@@ -0,0 +1,49 @@
+From: Paul Eggert 
+Date: Sat, 7 Mar 2020 10:29:51 -0800
+Subject: ls: improve removed-directory test
+
+* tests/ls/removed-directory.sh: Remove host_triplet test.
+Skip this test if one cannot remove the working directory.
+From a suggestion by Bernhard Voelker (Bug#39929).
+
+Author: Paul Eggert 
+Origin: upstream, https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=672819c73f2e94e61386dc0584bddf9da860cc26
+Bug: https://lists.gnu.org/archive/html/bug-coreutils/2020-03/msg5.html
+Last-Updated: 2020-07-24
+Reviewed-By: Sergio Durigan Junior 
+---
+ tests/ls/removed-directory.sh | 13 -
+ 1 file changed, 4 insertions(+), 9 deletions(-)
+
+diff --git a/tests/ls/removed-directory.sh b/tests/ls/removed-directory.sh
+index fe8f929..63b209d 100755
+--- a/tests/ls/removed-directory.sh
 b/tests/ls/removed-directory.sh
+@@ -1,7 +1,7 @@
+ #!/bin/sh
+-# If ls is asked to list a removed directory (e.g. the parent process's
+-# current working directory that has been removed by another process), it
+-# emits an error message.
++# If ls is asked to list a removed directory (e.g., the parent process's
++# current working directory has been removed by another process), it
++# should not emit an error message merely because the directory is removed.
+ 
+ # Copyright (C) 2020 Free Software Foundation, Inc.
+ 
+@@ -21,15 +21,10 @@
+ . "${srcdir=.}/tests/init.sh"; path_prepend_ ./src
+ print_ver_ ls
+ 
+-case $host_triplet in
+-  *linux*) ;;
+-  *) skip_ 'non linux kernel' ;;
+-esac
+-
+ cwd=$(pwd)
+ mkdir d || framework_failure_
+ cd d || framework_failure_
+-rmdir ../d || framework_failure_
++rmdir ../d || skip_ "can't remove working directory on this platform"
+ 
+ ls >../out 2>../err || fail=1
+ cd "$cwd" || framework_failure_
diff -Nru coreutils-8.32/debian/patches/restore-ls-behavior-8.31.patch coreutils-8.32/debian/patches/restore-ls-behavior-8.31.patch
--- coreutils-8.32/debian/patches/restore-ls-behavior-8.31.patch	1969-12-31 19:00:00.0 -0500
+++ coreutils-8.32/debian/patches/restore-ls-behavior-8.31.patch	2020-07-28 10:50:23.0 -0400
@@ -0,0 +1,126 @@
+From: Paul Eggert 
+Date: Thu, 5 Mar 2020 17:25:29 -0800
+Subject: ls: restore 8.31 behavior on removed directories
+
+* NEWS: Mention this.
+* src/ls.c: Do not include 
+(print_dir): Don't worry about whether the directory is removed.
+* tests/ls/removed-directory.sh: Adjust to match new (i.e., old)
+behavior.
+
+This patch is needed because coreutils 8.32 fails to build on ARM64
+with:
+
+src/ls.c: In function 'print_dir':
+src/ls.c:3026:24: error: 'SYS_getdents' undeclared (first use in this function); did you mean 'SYS_getdents64'?
+ 3026 |   if (syscall 

Bug#966448: liblbfgsb0: setulb doesn't handle bounds

[Drew Parsons]

Package: liblbfgsb0
Version: 3.0+dfsg.3-8
Severity: normal
Control: affects -1 src:scipy

The standalone lbfgsb shared library seems to be missing handling of
bounds in setulb, see
https://github.com/scipy/scipy/commit/cb9ed45d1a25d77204c737a8e1489dfb9606241f

cf. test failure in scipy/optimize/tests/test_lbfgsb_setulb.py at
https://ci.debian.net/data/autopkgtest/unstable/amd64/s/scipy/6438401/log.gz
-3.46944695e-18 is close to 0, but nevertheless is <0


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

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

Versions of packages liblbfgsb0 depends on:
ii  libatlas3-base [liblapack.so.3]3.10.3-10
ii  libblas3 [libblas.so.3]3.9.0-2
ii  libblis3-openmp [libblas.so.3] 0.7.0-1
ii  libblis3-pthread [libblas.so.3]0.7.0-1
ii  libc6  2.31-2
ii  libgfortran5   10.2.0-3
ii  liblapack3 [liblapack.so.3]3.9.0-2
ii  libopenblas0-openmp [liblapack.so.3]   0.3.10+ds-1
ii  libopenblas0-pthread [liblapack.so.3]  0.3.10+ds-1
ii  libopenblas0-serial [liblapack.so.3]   0.3.10+ds-1

liblbfgsb0 recommends no packages.

liblbfgsb0 suggests no packages.

-- no debconf information

Bug#966437: bambam: autopkgtest failure with imagemagick 8:6.9.11.24+dfsg-1

[Marcin Owsiany]

Just a quick note before I get a chance to look at this closer, in case
anyone else wants to take a stab at it.
It's one thing that the color output format changed in a way that the test
program does not know how to parse it. That's easy to fix.

It's more worrying that the reported average color stays at
"srgb(98.0209%,98.0209%,98.0209%)"
for 40 attempts. This means that either the screen color isn't in fact
changing (i.e. the game is broken) or that the way the average color is
calculated by imagemagick has changed in a way which makes it unusable :-/

wt., 28 lip 2020 o 16:36 Adrian Bunk  napisał(a):

> Source: bambam
> Version: 1.0.1+dfsg-1
> Severity: serious
> Tags: bullseye sid
>
> https://ci.debian.net/packages/b/bambam/unstable/amd64/
>
> Test success with imagemagick < 8:6.9.11.24+dfsg-1:
> ...
> On attempt 5 the average screen color was too close to white: 233,230,235.
> On attempt 6 the average screen color was too close to white: 225,223,231.
> On attempt 7 the average screen color was too close to white: 223,220,226.
> ...
>
> Test failure with imagemagick 8:6.9.11.24+dfsg-1:
> ...
> On attempt 37 the average screen color was
> srgb(98.0209%,98.0209%,98.0209%).
> On attempt 38 the average screen color was
> srgb(98.0209%,98.0209%,98.0209%).
> On attempt 39 the average screen color was
> srgb(98.0209%,98.0209%,98.0209%).
> Traceback (most recent call last):
>   File "./debian/tests/smoke-meat", line 101, in 
> main()
>   File "./debian/tests/smoke-meat", line 24, in main
> await_startup()
>   File "./debian/tests/smoke-meat", line 45, in await_startup
> raise Exception('Failed to see bambam start after %d attempts.' %
> attempt_count)
> Exception: Failed to see bambam start after 40 attempts.
>
>
> I suspect the output of convert changed that is parsed in
>
> https://sources.debian.org/src/bambam/1.0.1+dfsg-1/debian/tests/smoke-meat/#L83
>

Bug#966447: node-trust-jwa: FTBFS: Error: Cannot find module 'babel-helper-function-name'

[Andreas Beckmann]

Source: node-trust-jwa
Version: 0.4.6-1~exp1
Severity: serious
Tags: ftbfs
Justification: fails to build from source

Hi,

node-trust-jwa started to FTBFS after some changes in the node-babel ecosystem:

   debian/rules override_dh_auto_build
make[1]: Entering directory '/build/node-trust-jwa-0.4.6'
pandoc --from gfm-raw_html --to html --standalone --output README.html README.md
[WARNING] This document format requires a nonempty  element.
  Defaulting to 'README' as the title.
  To specify a title, use 'title' in metadata or --metadata title="...".
pandoc --from gfm-raw_html --to plain --output README.txt README.md
babeljs src -d lib
Error: Cannot find module 'babel-helper-function-name'
Require stack:
- /usr/share/nodejs/babel-plugin-transform-es2015-function-name/lib/index.js
- /usr/share/nodejs/babel-preset-es2015/lib/index.js
- /usr/share/nodejs/babel-core/lib/transformation/file/options/option-manager.js
- /usr/share/nodejs/babel-core/lib/transformation/file/index.js
- /usr/share/nodejs/babel-core/lib/api/node.js
- /usr/share/nodejs/babel-core/index.js
- /usr/share/nodejs/babel-cli/lib/babel/index.js
- /usr/share/nodejs/babel-cli/bin/babel.js (While processing preset: 
"/usr/share/nodejs/babel-preset-es2015/lib/index.js")
at Function.Module._resolveFilename (internal/modules/cjs/loader.js:966:15)
at Function.Module._load (internal/modules/cjs/loader.js:842:27)
at Module.require (internal/modules/cjs/loader.js:1026:19)
at require (internal/modules/cjs/helpers.js:72:18)
at Object. 
(/usr/share/nodejs/babel-plugin-transform-es2015-function-name/lib/index.js:28:32)
at Module._compile (internal/modules/cjs/loader.js:1138:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:1158:10)
at Module.load (internal/modules/cjs/loader.js:986:32)
at Function.Module._load (internal/modules/cjs/loader.js:879:14)
at Module.require (internal/modules/cjs/loader.js:1026:19)
make[1]: *** [debian/rules:14: override_dh_auto_build] Error 1
make[1]: Leaving directory '/build/node-trust-jwa-0.4.6'
make: *** [debian/rules:33: binary] Error 2


Andreas


node-trust-jwa_0.4.6-1~exp1.log.gz
Description: application/gzip

Bug#966446: node-solid-jose: FTBFS Error: Cannot find module 'babel-helper-function-name'

[Andreas Beckmann]

Source: node-solid-jose
Version: 0.4.0+dfsg-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source

Hi,

node-solid-jose started to FTBFS after some changes in the node-babel ecosystem:

   debian/rules override_dh_auto_build
make[1]: Entering directory '/build/node-solid-jose-0.4.0+dfsg'
pandoc --from gfm-raw_html --to html --standalone --output README.html README.md
[WARNING] This document format requires a nonempty  element.
  Defaulting to 'README' as the title.
  To specify a title, use 'title' in metadata or --metadata title="...".
pandoc --from gfm-raw_html --to plain --output README.txt README.md
babeljs src -d lib
Error: Cannot find module 'babel-helper-function-name'
Require stack:
- /usr/share/nodejs/babel-plugin-transform-es2015-function-name/lib/index.js
- /usr/share/nodejs/babel-preset-es2015/lib/index.js
- /usr/share/nodejs/babel-core/lib/transformation/file/options/option-manager.js
- /usr/share/nodejs/babel-core/lib/transformation/file/index.js
- /usr/share/nodejs/babel-core/lib/api/node.js
- /usr/share/nodejs/babel-core/index.js
- /usr/share/nodejs/babel-cli/lib/babel/index.js
- /usr/share/nodejs/babel-cli/bin/babel.js (While processing preset: 
"/usr/share/nodejs/babel-preset-es2015/lib/index.js")
at Function.Module._resolveFilename (internal/modules/cjs/loader.js:966:15)
at Function.Module._load (internal/modules/cjs/loader.js:842:27)
at Module.require (internal/modules/cjs/loader.js:1026:19)
at require (internal/modules/cjs/helpers.js:72:18)
at Object. 
(/usr/share/nodejs/babel-plugin-transform-es2015-function-name/lib/index.js:28:32)
at Module._compile (internal/modules/cjs/loader.js:1138:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:1158:10)
at Module.load (internal/modules/cjs/loader.js:986:32)
at Function.Module._load (internal/modules/cjs/loader.js:879:14)
at Module.require (internal/modules/cjs/loader.js:1026:19)
make[1]: *** [debian/rules:9: override_dh_auto_build] Error 1
make[1]: Leaving directory '/build/node-solid-jose-0.4.0+dfsg'
make: *** [debian/rules:30: binary] Error 2


Andreas


node-solid-jose_0.4.0+dfsg-1.log.gz
Description: application/gzip

Bug#966445: ITP: r-bioc-experimenthub -- Client to access ExperimentHub resources

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: r-bioc-experimenthub -- Client to access ExperimentHub resources
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: r-bioc-experimenthub
  Version : 1.14.0+ds
  Upstream Author : Bioconductor Package Maintainer,
* URL : https://bioconductor.org/packages/ExperimentHub/
* License : Artistic-2.0
  Programming Lang: GNU R
  Description : Client to access ExperimentHub resources
 This package provides a client for the Bioconductor ExperimentHub web
 resource. ExperimentHub provides a central location where curated data
 from experiments, publications or training courses can be accessed. Each
 resource has associated metadata, tags and date of modification. The
 client creates and manages a local cache of files retrieved enabling
 quick and reproducible access.

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

Bug#966444: RFS: iotjs/1.0-2 RC -- Javascript Framework for Internet of Things

[Philippe Coval]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name: iotjs
   Version : 1.0-2
   Upstream Author : JerryScript project
 * URL : https://github.com/jerryscript-project/iotjs/
 * License : Apache-2.0
 * Vcs : https://salsa.debian.org/rzr-guest/iotjs
   Section : web

It builds those binary packages:

  iotsjs - Javascript Framework for Internet of Things

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/i/iotjs/iotjs_1.0-2.dsc

Changes since the last upload:

iotjs (1.0-2) unstable; urgency=medium
 .
   * debian/control: Lint control file
   * debian/copyright: Update urls with duck
   * debian/copyright: Add upstream contact to debian/copyright
   * debian/control: Add Rules-Requires-Root field
   * debian/patches: Select python3 from env if needed
   * debian: Prefer python3 (Closes: #936738)
   * debian/patch: Relax compiler to continue on warnings (Closes: #957364)
   * debian: Bump standards to current
   * debian/upstream: Add metadata file
   * debian/control: Add Vcs fields to salsa
   * debian/gbp.conf: Support gbp custom branches
Regards,
-- 
http://rzr.online.fr/# gpg:0x467094BC mailto:r...@users.sf.net

   .

Bug#966443: plantuml depends on ditaa but uses embedded version of ditaa instead

[Tomas Janousek]

Package: plantuml
Version: 1:1.2020.2+ds-1
Severity: normal
X-Debbugs-Cc: 

I was a bit confused how could ditaa work in plantuml as the usage in there
doesn't match the API in ditaa:

https://sources.debian.org/src/plantuml/1:1.2020.2+ds-1/src/net/sourceforge/plantuml/ditaa/PSystemDitaa.java/#L121
vs
https://sources.debian.org/src/ditaa/0.10+ds1-1.2/src/org/stathissideris/ascii2image/graphics/Diagram.java/#L113

Turns out it only works because plantuml includes its own (patched) version of
ditaa:
https://sources.debian.org/src/plantuml/1:1.2020.2+ds-1/src/org/stathissideris/ascii2image/graphics/Diagram.java/#L109

Therefore I find it confusing and unnecessary to depend on ditaa and patch the
full path to ditaa.jar into classpath in
https://sources.debian.org/src/plantuml/1:1.2020.2+ds-1/debian/patches/pdf.patch/
(Depending on ditaa pulled in the jarwrapper dependency, which seems to
duplicate functionality already provided by
/usr/lib/jvm/java-11-openjdk-amd64/lib/jar.binfmt)

It's also worth noting that the included (patched) version of ditaa is, if I
remember correctly, a bit older than the 0.10 we have in Debian. So you may
want to drop the included ditaa and use the one shipped in Debian instead
(but that one also seems unmaintained and behind upstream, unfortunately). In
that case it'll be helpful to know that the patching done in plantuml is
unnecessary and PSystemDitaa.java can be made to work with vanilla ditaa:
https://salsa.debian.org/liskin/plantuml/-/commit/5ee7fe82b098fa1402eb43acfff0fcc1bd19dbc4#96bdf10a122277d146e589cf010af72842d73ddd

Alternatively you may just drop the dependency and let plantuml use its own
copy of ditaa as it does upstream. Or you can also update the embedded ditaa
in plantuml, which is what I do in https://salsa.debian.org/liskin/plantuml/
(I'm now in the process of rebasing onto current Debian version).

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

Kernel: Linux 5.7.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_USER, TAINT_WARN, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.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 plantuml depends on:
ii  default-jre-headless  2:1.11-72
pn  ditaa 
ii  libavalon-framework-java  4.2.0-10
ii  libbatik-java 1.12-1.1
ii  libcommons-io-java2.6-2
ii  libcommons-logging-java   1.2-2
ii  libfop-java   1:2.5-1
ii  libjlatexmath-java1.0.7-3
ii  libxml-commons-external-java  1.4.01-5
ii  libxmlgraphics-commons-java   2.4-1

Versions of packages plantuml recommends:
ii  graphviz  2.42.2-4

plantuml suggests no packages.

-- no debconf information

-- 
Tomáš Janoušek, a.k.a. Pivník, a.k.a. Liskni_si, https://work.lisk.in/

Bug#933031: pristine-tar: unable to unpack some deltas of version 2

[Steve McIntyre]

Control: severity -1 grave

On Thu, Jul 25, 2019 at 11:53:39PM +0300, Коля Гурьев wrote:
>Package: pristine-tar
>Version: 1.46
>Severity: important
>
>pristine-tar of version 1.46 available in Debian Unstable can't unpack
>deltas of versions 2 generated by pristine-tar 1.33 from Ubuntu Xenial.
>
>I've committed a tarball for the rlottie package into my Git repository
>using pristine-tar 1.33. Then I try to regenerate the tarball inside
>Debian chroot and get the next error.
>
>$ pristine-tar --debug --verbose checkout 
>../rlottie_0~git20190721.24346d0+dfsg.orig.tar.gz
>pristine-tar: git archive --format=tar 
>9fed0d3da5cfa7eabd4fa8c2590dd86e5b1442e1 | (cd '/tmp/pristine-tar.2a5pcCDc3n' 
>&& tar x)
>pristine-tar: tar xf /tmp/pristine-tar.cBbx8nKDp6/tmpin -C 
>/tmp/pristine-tar.Dvxlxlx8Qn
>pristine-tar: set subdir to rlottie
>pristine-tar: subdir is rlottie
>pristine-tar: mkdir /tmp/pristine-tar.o0lKEjWozz/workdir
>pristine-tar: mv /tmp/pristine-tar.2a5pcCDc3n 
>/tmp/pristine-tar.o0lKEjWozz/workdir/rlottie
>pristine-tar: rlottie/example/resource/360\302\272_degree.json is listed in 
>the manifest but may not be present in the source directory
>pristine-tar: creating missing rlottie/example/resource/360\302\272_degree.json
>pristine-tar: doing full tree sweep to catch missing files
>pristine-tar: tar cf /tmp/pristine-tar.o0lKEjWozz/recreatetarball --owner 0 
>--group 0 --numeric-owner -C /tmp/pristine-tar.o0lKEjWozz/workdir 
>--no-recursion --mode 0644 --verbatim-files-from --files-from 
>/tmp/pristine-tar.o0lKEjWozz/manifest
>pristine-tar: xdelta patch --pristine /tmp/pristine-tar.Dvxlxlx8Qn/delta 
>/tmp/pristine-tar.o0lKEjWozz/recreatetarball 
>/tmp/pristine-tar.i1k0xBo1aP/rlottie_0~git20190721.24346d0+dfsg.orig.tar.gz.tmp
>xdelta: expected from file (/tmp/pristine-tar.o0lKEjWozz/recreatetarball) of 
>length 12779520 bytes
>pristine-tar: tar cf /tmp/pristine-tar.o0lKEjWozz/recreatetarball --owner 0 
>--group 0 --numeric-owner -C /tmp/pristine-tar.o0lKEjWozz/workdir 
>--no-recursion --mode 0644 --verbatim-files-from --files-from 
>/tmp/pristine-tar.o0lKEjWozz/manifest
>pristine-tar: xdelta patch --pristine /tmp/pristine-tar.Dvxlxlx8Qn/delta 
>/tmp/pristine-tar.o0lKEjWozz/recreatetarball 
>/tmp/pristine-tar.i1k0xBo1aP/rlottie_0~git20190721.24346d0+dfsg.orig.tar.gz.tmp
>xdelta: expected from file (/tmp/pristine-tar.o0lKEjWozz/recreatetarball) of 
>length 12779520 bytes
>pristine-tar: set subdir to rlottie
>pristine-tar: subdir is rlottie
>pristine-tar: mkdir /tmp/pristine-tar.4XNCSF8pDG/workdir
>pristine-tar: mv /tmp/pristine-tar.o0lKEjWozz/workdir/rlottie 
>/tmp/pristine-tar.4XNCSF8pDG/workdir/rlottie
>pristine-tar: tar cf /tmp/pristine-tar.4XNCSF8pDG/recreatetarball --owner 0 
>--group 0 --numeric-owner -C /tmp/pristine-tar.4XNCSF8pDG/workdir 
>--no-recursion --mode 0644 --verbatim-files-from --files-from 
>/tmp/pristine-tar.4XNCSF8pDG/manifest -H gnu
>pristine-tar: xdelta patch --pristine /tmp/pristine-tar.Dvxlxlx8Qn/delta 
>/tmp/pristine-tar.4XNCSF8pDG/recreatetarball 
>/tmp/pristine-tar.i1k0xBo1aP/rlottie_0~git20190721.24346d0+dfsg.orig.tar.gz.tmp
>xdelta: expected from file (/tmp/pristine-tar.4XNCSF8pDG/recreatetarball) of 
>length 12779520 bytes
>pristine-tar: set subdir to rlottie
>pristine-tar: subdir is rlottie
>pristine-tar: mkdir /tmp/pristine-tar.SY9ZY0yfKg/workdir
>pristine-tar: mv /tmp/pristine-tar.4XNCSF8pDG/workdir/rlottie 
>/tmp/pristine-tar.SY9ZY0yfKg/workdir/rlottie
>pristine-tar: tar cf /tmp/pristine-tar.SY9ZY0yfKg/recreatetarball --owner 0 
>--group 0 --numeric-owner -C /tmp/pristine-tar.SY9ZY0yfKg/workdir 
>--no-recursion --mode 0644 --verbatim-files-from --files-from 
>/tmp/pristine-tar.SY9ZY0yfKg/manifest -H posix
>pristine-tar: xdelta patch --pristine /tmp/pristine-tar.Dvxlxlx8Qn/delta 
>/tmp/pristine-tar.SY9ZY0yfKg/recreatetarball 
>/tmp/pristine-tar.i1k0xBo1aP/rlottie_0~git20190721.24346d0+dfsg.orig.tar.gz.tmp
>xdelta: expected from file (/tmp/pristine-tar.SY9ZY0yfKg/recreatetarball) of 
>length 12779520 bytes
>pristine-tar: tar cf /tmp/pristine-tar.SY9ZY0yfKg/recreatetarball --owner 0 
>--group 0 --numeric-owner -C /tmp/pristine-tar.SY9ZY0yfKg/workdir 
>--no-recursion --mode 0644 --verbatim-files-from --files-from 
>/tmp/pristine-tar.SY9ZY0yfKg/manifest
>pristine-tar: xdelta patch --pristine /tmp/pristine-tar.Dvxlxlx8Qn/delta 
>/tmp/pristine-tar.SY9ZY0yfKg/recreatetarball 
>/tmp/pristine-tar.i1k0xBo1aP/rlottie_0~git20190721.24346d0+dfsg.orig.tar.gz.tmp
>xdelta: expected from file (/tmp/pristine-tar.SY9ZY0yfKg/recreatetarball) of 
>length 12779520 bytes
>pristine-tar: Failed to reproduce original tarball. Please file a bug report.
>pristine-tar: failed to generate tarball
>
>You'll find problematic delta in the repository of the rlottie package
>under the mymedia/weird-delta tag. Steps to reproduce:
>
>git clone https://salsa.debian.org/debian/rlottie.git
>git branch pristine-tar mymedia/weird-delta
>pristine-tar checkout 

Bug#966442: RM: golang-github-cbroglie-mapstructure -- RoQA; fork of golang-github-mitchellh-mapstructure; no rdepends

[Shengjing Zhu]

Package: ftp.debian.org
Severity: normal

This fork is used to build golang-github-docker-goamz.
After removing #966440 golang-github-docker-goamz, this can be removed as well.

Bug#960645: firefox: Please build with WebRTC pipewire support for GNOME Wayland

[Drew Parsons]

Package: firefox
Version: 78.0.2-1
Followup-For: Bug #960645

This bug is all the more important now that Gnome launches over
Wayland by default.  And more so again in COVID times when we're using
video conferencing more heavily.

There's more discussion of the issue at

https://bugzilla.mozilla.org/show_bug.cgi?id=1430775

https://github.com/emersion/xdg-desktop-portal-wlr/wiki/Screencast-Compatibility

Bug#966441: RM: golang-github-adroll-goamz -- RoQA; No update for a long time; official AWS Go sdk exists

[Shengjing Zhu]

Package: ftp.debian.org
Severity: normal

This package is pretty outdated with current AWS API.
There's no rdepends. All packages which previously used this library have
migrated to official AWS SDK, golang-github-aws-aws-sdk-go.

Bug#965138: Unable to disable decoded IDN output in host

[Bernhard Schmidt]

control: found -1 1:9.11.5.P4+dfsg-5.1
control: fixed -1 1:9.16.4-1

Thanks for the bug report. I can confirm this behaviour for Buster. I
can also confirm that this behaviour has been fixed for 9.16 (in
Bullseye) (apart from a missing newline)

$ host xn--linux-neuchtel-lhb.ch
linux-neuchâtel.ch has address 193.72.186.6
linux-neuchâtel.ch has address 46.140.72.222

$ env LC_CTYPE=C host xn--linux-neuchtel-lhb.ch
;; Warning: cannot represent 'xn--linux-neuchtel-lhb.ch' in the current
localexn--linux-neuchtel-lhb.ch has address 193.72.186.6
xn--linux-neuchtel-lhb.ch has address 46.140.72.222

$ env LC_CTYPE=C IDN_DISABLE=1 host xn--linux-neuchtel-lhb.ch
xn--linux-neuchtel-lhb.ch has address 193.72.186.6
xn--linux-neuchtel-lhb.ch has address 46.140.72.222

Not sure whether we can backport this easily. The +noidnout suggestion
is definitely bogus, that's dig style.

Bug#966440: RM: golang-github-docker-goamz -- RoQA; Upstream is gone

[Shengjing Zhu]

Package: ftp.debian.org
Severity: normal

The upstream repo https://github.com/docker/goamz was removed.
And there's no rdepends of this package.
It was used by docker-registry previously.

Bug#966439: clickhouse ftbfs with gcc-10

[Steve Langasek]

Package: clickhouse
Version: 18.16.1+ds-7.1
Severity: serious
Tags: patch
Justification: ftbfs
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu groovy ubuntu-patch

Hi Alexander,

In Ubuntu, we've found that clickhouse fails to build from source with the
current toolchain due to a missing C++ include file.  The attached patch
fixes the build failure in unstable.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru clickhouse-18.16.1+ds/debian/control 
clickhouse-18.16.1+ds/debian/control
--- clickhouse-18.16.1+ds/debian/control2020-07-27 08:39:42.0 
-0700
+++ clickhouse-18.16.1+ds/debian/control2020-07-27 17:59:57.0 
-0700
@@ -1,8 +1,7 @@
 Source: clickhouse
 Section: database
 Priority: optional
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: Alexander GQ Gerasiov 
+Maintainer: Alexander GQ Gerasiov 
 Build-Depends: cmake,
curl ,
debhelper (>= 10),
diff -Nru clickhouse-18.16.1+ds/debian/patches/gcc10-ftbfs.patch 
clickhouse-18.16.1+ds/debian/patches/gcc10-ftbfs.patch
--- clickhouse-18.16.1+ds/debian/patches/gcc10-ftbfs.patch  1969-12-31 
16:00:00.0 -0800
+++ clickhouse-18.16.1+ds/debian/patches/gcc10-ftbfs.patch  2020-07-27 
17:59:46.0 -0700
@@ -0,0 +1,16 @@
+Description: fix missing C++ include, exposed by toolchain changes
+Author: Steve Langasek 
+Last-Update: 2020-07-27
+
+Index: clickhouse-18.16.1+ds/dbms/src/Interpreters/addMissingDefaults.h
+===
+--- clickhouse-18.16.1+ds.orig/dbms/src/Interpreters/addMissingDefaults.h
 clickhouse-18.16.1+ds/dbms/src/Interpreters/addMissingDefaults.h
+@@ -1,6 +1,7 @@
+ #pragma once
+ 
+ #include 
++#include 
+ 
+ 
+ namespace DB
diff -Nru clickhouse-18.16.1+ds/debian/patches/series 
clickhouse-18.16.1+ds/debian/patches/series
--- clickhouse-18.16.1+ds/debian/patches/series 2020-03-29 19:55:51.0 
-0700
+++ clickhouse-18.16.1+ds/debian/patches/series 2020-07-27 16:26:21.0 
-0700
@@ -17,3 +17,4 @@
 0017-gcc9-mitigation-for-conditional-bug.patch
 fix-ftbfs.patch
 python3.patch
+gcc10-ftbfs.patch

Bug#966431: minetest: Unable to start (Segmentation fault) after upgrade

[Markus Koschany]

Am 28.07.20 um 16:41 schrieb Bruno BEAUFILS:
> On Tue, Jul 28, 2020 at 04:27:03PM +0200, Markus Koschany wrote:
>> Apparently you had installed custom main_menu sound files once and now
>> minetest is unable to find or open them.
>>
>> Try removing all sound files in /home/bruno/.minetest/sounds/
> 
> I tested that already (completely removing .minetest folder) without
> any success :-(
> 
> I, however, just find something. I am running Gnome on Xorg.
> 
> When I switch to Gnome (aka with Wayland) everything seems OK, no more
> segfault :-/
> 
> Do you think I need to signal that to some other package maintainer?
> 
> Thank's for your work and help.

It is likely related to some other package but without a proper
backtrace I can't give you any recommendations. You could follow the
instructions in Debian's wiki.

https://wiki.debian.org/HowToGetABacktrace

and look for error messages that show the segmentation fault.




signature.asc
Description: OpenPGP digital signature

Bug#966438: src:bambam: Autopkgtest fail wiht newer imagemagick*

[Bastien Roucariès]

Package: src:bambam
Version: 1.0.1+dfsg-1
Severity: serious
Justification: block imagemagick

Dear Maintainer,

Upgrading imagemagick fail due to autopkg test failling for your package. See 
https://ci.debian.net/data/autopkgtest/testing/amd64/b/bambam/6448023/log.gz

Could you :
1. Fix the failure
2. Please in case of error take a screenshot convert it to png and print the 
png as base64 (help debugging)

Bastien

Bug#837606: closed by Ansgar (Re: general: system freeze)

[Geert Stappers]

On Tue, Jul 28, 2020 at 04:06:13PM +0200, Rouven-Matthias Müller wrote:
>  [ ... ] Interesting, that nobody ever started to fix this problem.

This is a little story about four people
named Everybody, Somebody, Anybody, and Nobody.

There was an important job to be done and Everybody was sure that
Somebody would do it.  Anybody could have done it, but Nobody did it.
Somebody got angry about that because it was Everybody's job.
Everybody thought that Anybody could do it, but Nobody realized that
Everybody wouldn't do it.
It ended up that Everybody blamed Somebody when Nobody did what Anybody
could have done 

 
> have a good one.

Thanks


Regards
Geert Stappers
-- 
Silence is hard to parse

Bug#966431: minetest: Unable to start (Segmentation fault) after upgrade

[Bruno BEAUFILS]

On Tue, Jul 28, 2020 at 04:27:03PM +0200, Markus Koschany wrote:
> Apparently you had installed custom main_menu sound files once and now
> minetest is unable to find or open them.
> 
> Try removing all sound files in /home/bruno/.minetest/sounds/

I tested that already (completely removing .minetest folder) without
any success :-(

I, however, just find something. I am running Gnome on Xorg.

When I switch to Gnome (aka with Wayland) everything seems OK, no more
segfault :-/

Do you think I need to signal that to some other package maintainer?

Thank's for your work and help.

-- 
Bruno BEAUFILS


signature.asc
Description: PGP signature

Bug#966437: bambam: autopkgtest failure with imagemagick 8:6.9.11.24+dfsg-1

[Adrian Bunk]

Source: bambam
Version: 1.0.1+dfsg-1
Severity: serious
Tags: bullseye sid

https://ci.debian.net/packages/b/bambam/unstable/amd64/

Test success with imagemagick < 8:6.9.11.24+dfsg-1:
...
On attempt 5 the average screen color was too close to white: 233,230,235.
On attempt 6 the average screen color was too close to white: 225,223,231.
On attempt 7 the average screen color was too close to white: 223,220,226.
...

Test failure with imagemagick 8:6.9.11.24+dfsg-1:
...
On attempt 37 the average screen color was srgb(98.0209%,98.0209%,98.0209%).
On attempt 38 the average screen color was srgb(98.0209%,98.0209%,98.0209%).
On attempt 39 the average screen color was srgb(98.0209%,98.0209%,98.0209%).
Traceback (most recent call last):
  File "./debian/tests/smoke-meat", line 101, in 
main()
  File "./debian/tests/smoke-meat", line 24, in main
await_startup()
  File "./debian/tests/smoke-meat", line 45, in await_startup
raise Exception('Failed to see bambam start after %d attempts.' % 
attempt_count)
Exception: Failed to see bambam start after 40 attempts.


I suspect the output of convert changed that is parsed in
https://sources.debian.org/src/bambam/1.0.1+dfsg-1/debian/tests/smoke-meat/#L83

Bug#966436: ruby-mini-magick FTBFS with imagemagick 8:6.9.11.24+dfsg-1

[Adrian Bunk]

Source: ruby-mini-magick
Version: 4.9.5-2
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/ruby-mini-magick.html

...
Failures:

  1) With ImageMagick MiniMagick::Image#details when verbose information 
includes a clipping path does not hang when parsing verbose data
 Failure/Error: details_hash[last_key] << line

 NoMethodError:
   undefined method `<<' for #
   Did you mean?  <
 # ./lib/mini_magick/image/info.rb:139:in `block in details'
 # ./lib/mini_magick/image/info.rb:128:in `each'
 # ./lib/mini_magick/image/info.rb:128:in `each_with_object'
 # ./lib/mini_magick/image/info.rb:128:in `details'
 # ./lib/mini_magick/image/info.rb:31:in `[]'
 # ./lib/mini_magick/image.rb:141:in `block in attribute'
 # ./spec/lib/mini_magick/image_spec.rb:478:in `block (7 levels) in '
 # ./spec/lib/mini_magick/image_spec.rb:477:in `block (6 levels) in '
 # ./spec/spec_helper.rb:19:in `block (3 levels) in '

Finished in 1 minute 34.34 seconds (files took 21.52 seconds to load)
76 examples, 1 failure
...

Bug#966431: minetest: Unable to start (Segmentation fault) after upgrade

[Markus Koschany]

Hello,

Am 28.07.20 um 15:57 schrieb Bruno BEAUFILS:
> Package: minetest
> Version: 5.3.0+repack-1
> Severity: normal
> 
> Dear Maintainer,
> 
> I was able to run minetest (client) on my Debian Bullseye (testing)
> installation since some weeks. After one apt upgrade I am now unable to start
> it whatever I try.
> 
> I always get a Segmentation fault.
> 
> The window appear (black) and after some instant the segmentation fault comes
> and the software stops.
> 
> Using the `--verbose` option I only see some errors about some audio files not
> found.
> 
> Using strace I only a long list of `mmap` calls before the segmentation fault.
> 
> It may be some trouble with my installation but the only modification done 
> were
> upgrade through `apt`.

Apparently you had installed custom main_menu sound files once and now
minetest is unable to find or open them.

Try removing all sound files in /home/bruno/.minetest/sounds/

I also don't see any hint of a segfault in your log files.

https://wiki.minetest.net/Main_menu_music

Regards,

Markus










> 
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (990, 'testing')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.7.0-1-amd64 (SMP w/4 CPU threads)
> Kernel taint flags: TAINT_WARN
> Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages minetest depends on:
> ii  libc6 2.31-1
> ii  libcurl3-gnutls   7.68.0-1+b1
> ii  libfreetype6  2.10.2+dfsg-3
> ii  libgcc-s1 10.1.0-6
> ii  libgmp10  2:6.2.0+dfsg-6
> ii  libirrlicht1.81.8.4+dfsg1-1.1
> ii  libjsoncpp1   1.7.4-3.1
> ii  libleveldb1d  1.22-3
> ii  libluajit-5.1-2   2.1.0~beta3+dfsg-5.1
> ii  libncursesw6  6.2-1
> ii  libopenal11:1.19.1-1+b1
> ii  libpq512.3-1+b1
> ii  libspatialindex6  1.9.3-1
> ii  libsqlite3-0  3.32.3-1
> ii  libstdc++610.1.0-6
> ii  libtinfo6 6.2-1
> ii  libvorbisfile31.3.6-2
> ii  libx11-6  2:1.6.9-2+b1
> ii  minetest-data 5.3.0+repack-1
> ii  zlib1g1:1.2.11.dfsg-2
> 
> minetest recommends no packages.
> 
> Versions of packages minetest suggests:
> pn  minetest-mod-moreblocks  
> pn  minetest-mod-moreores
> pn  minetest-mod-pipeworks   
> pn  minetest-server  
> pn  minetestmapper   
> 
> 
> ___
> Pkg-games-devel mailing list
> pkg-games-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-games-devel
> 



signature.asc
Description: OpenPGP digital signature

Bug#966435: autopkg test fails on arm64, triggered by gcc-defaults

[Matthias Klose]

Package: sec:automake-1.16
Version: 1:1.16.2-3
Severity: serious
Tags: sid bullseye

Looking at the autopkg tests, I see:

FAIL: t/vala-mix2.sh

this looks unrelated to the gcc-defaults change

Bug#966434: use python3 instead of python2 in the autopkg tests

[Matthias Klose]

Package: sec:automake-1.16
Version: 1:1.16.2-3
Severity: important
Tags: sid bullseye

Looking at the autopkg tests, I see:

PASS: t/py-compile-env.sh
py-compile-option-terminate: skipped test: python interpreter not available
SKIP: t/py-compile-option-terminate.sh
PASS: t/py-compile-usage.sh
PASS: t/python.sh
PASS: t/python2.sh
python3: skipped test: python interpreter not available
SKIP: t/python3.sh
python10: skipped test: python interpreter not available


Please use python3 instead of python2.

Bug#966433: seqan autopkg test failures triggered by gcc-defaults

[Matthias Klose]

Package: src:seqan
Version: 3.0.1+ds-10
Severity: serious
Tags: sid bullseye

seqan autopkg test failures triggered by gcc-defaults, this doesn't seem to be
related to GCC 10.

https://ci.debian.net/data/autopkgtest/testing/amd64/s/seqan3/6396315/log.gz

/usr/include/seqan3/alphabet/concept.hpp:441:62: error: wrong number of template
arguments (2, should be 3)
  441 | remove_cvref_t,
  |  ^

Bug#966432: wcslib test failures with GCC 10

[Matthias Klose]

Package: src:wcslib
Version: 7.3+ds-2
Severity: serious
Tags: sid bullseye

gcc-defaults triggers test failures for wcslib, both on amd64 and arm64:

autopkgtest [01:49:15]: test wcslib-test-Fortran: [---
+ Test: tlin +
Testing WCSLIB linear transformation routines (tlin.f)
--

PIX 1:  303.  265.  112.4000  144.5000   28.2000
PIX 2:   19.   57.2.   15.   42.

IMG 1:   61.8000   74.7500  164.5600   74.2500  152.3200
IMG 2: -403.8000 -730.2500 -210.8000 -508.5000  229.6000

PIX 1:  303.  265.  112.4000  144.5000   28.2000
PIX 2:   19.   57.2.   15.   42.

LINP2X/LINX2P: Maximum closure residual = 5.7E-14 pixel.

PASS: All closure residuals are within reporting tolerance.
tdis1.f:151:37:

  143 |   STATUS = WCSGTI (WCS, WCS_LIN, LIN)
  | 2
..
  151 |   STATUS = WCSGTI (WCS, WCS_LNG, ILNG)
  | 1
Error: Rank mismatch between actual argument at (1) and actual argument at (2)
(rank-1 and scalar)
tdis1.f:152:37:

  143 |   STATUS = WCSGTI (WCS, WCS_LIN, LIN)
  | 2
..
  152 |   STATUS = WCSGTI (WCS, WCS_LAT, ILAT)
  | 1
Error: Rank mismatch between actual argument at (1) and actual argument at (2)
(rank-1 and scalar)

Bug#963760: new upstream release (1.4.10)

[Daniel Baumann]

severity 963760 serious
thanks

Hi,

what's the status of this?

Regards,
Daniel

Bug#837606: closed by Ansgar (Re: general: system freeze)

[Rouven-Matthias Müller]

Im not actually unsatisfied, but i like to point out, that this is pelated to 
bugs reported, to kernel.org, by other people, having similar problems with 
this kind of hardware, intel baytrail, random hang on video playback. it think 
this may be related to the intel hardware acceleration. if you use x11 as 
videoplayback device the video will run without problems, if you use 
accelerated playbackdevices it will hang and you will have the same problem i 
got rather often, mouse work, rest is frozen. Interesting, that nobody ever 
started to fix this problem...

have a good one.


Am Dienstag, 28. Juli 2020, 13:42:03 schrieben Sie:
> This is an automatic notification regarding your Bug report
> which was filed against the general package:
> 
> #837606: general: system freeze
> 
> It has been closed by Ansgar .
> 
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Ansgar
>  by replying to this email.
> 
> 
> --
> 837606: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837606
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

Bug#966430: salmon should be Architecture: amd64

[Adrian Bunk]

Source: salmon
Version: 1.3.0+ds1-2
Severity: important
Tags: ftbfs

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

Loooking at the code, I ended up at
https://sources.debian.org/src/salmon/1.3.0+ds1-1/debian/external/pufferfish/src/ksw2pp/KSW2Aligner.cpp/#L381

This is proper autodetection suitable for amd64, but trying to
build salmon on arm64/mips64el/powerpc brings little value.

Bug#966429: seahorse: Gnome Seahorse configuration bug does not work with HKP/HKPS

[Carlos Donizete Froes]

Package: seahorse
Version: 3.36-1
Severity: normal

Dear Maintainer,

 It doesn't seem possible to add the HKP/HKPS key server, where it
 returns me suspended and offers me only the "LDAP Key Server" with
 only ldap://keyserver.pgp.com set as the default.

 I tried several options to add the HKP/HKPS key servers, but only
 the "LDAP Key Server" and the custom server are available. When providing
 the server in "Custom" and does not accept it.

 Can someone else confirm that issue?

 Thanks and see you!

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

Versions of packages seahorse depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.36.0-1
ii  gcr  3.36.0-2
ii  gnome-keyring3.36.0-1
ii  gnupg2.2.20-1
ii  libatk1.0-0  2.36.0-2
ii  libavahi-client3 0.8-3
ii  libavahi-common3 0.8-3
ii  libavahi-glib1   0.8-3
ii  libc62.31-1
ii  libgck-1-0   3.36.0-2
ii  libgcr-base-3-1  3.36.0-2
ii  libgcr-ui-3-13.36.0-2
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-5
ii  libglib2.0-0 2.64.4-1
ii  libgpgme11   1.13.1-9
ii  libgtk-3-0   3.24.20-1
ii  libhandy-0.0-0   0.0.13-2
ii  libldap-2.4-22.4.50+dfsg-1+b1
ii  libpwquality11.4.2-1+b1
ii  libsecret-1-00.20.3-1
ii  libsoup2.4-1 2.70.0-1

Versions of packages seahorse recommends:
ii  openssh-client  1:8.3p1-1

seahorse suggests no packages.

-- no debconf information

Bug#966428: sbuild autopkg test fails with dpkg 1.20.x

[Matthias Klose]

Package: src_sbuild
Version: 0.79.1-1
Severity: serious
Tags: sid bullseye patch

The sbuild autopkg test fails with dpkg 1.20.x, preventing migration of dpkg.

patch at
http://launchpadlibrarian.net/490472280/sbuild_0.79.1-1ubuntu1_0.79.1-1ubuntu2.diff.gz

Bug#966427: RFP: golang-github-greatroar-blobloom -- blocked Bloom filter package for Go (golang) with no runtime dependencies

[Nicholas D Steeves]

Package: wnpp
Severity: wishlist

Package name: golang-github-greatroar-blobloom
Version : 0.2.1 (for syncthing 1.7.1)
URL : https://github.com/greatroar/blobloom
License : Apache-2.0
Programming Lang: Go
Description : blocked Bloom filter package for Go (golang) with no runtime 
dependencies

Blobloom is a blocked Bloom filter package for Go (golang) with no
runtime dependencies.
.
Blocked Bloom filters are a cache-efficient variant of Bloom filters,
the well-known approximate set data structure. To quote Daniel Lemire,
they have unbeatable speed. See the directory benchmarks/ to determine
exactly how fast Blobloom is compared to other packages.
.
Blobloom does not provide hash functions for use with the Bloom
filter. Instead, it requires client code to supply hash values. That
means you get to pick the hash algorithm that is fastest for your
data, use a secure hash such as SipHash or reuse hashes that you've
already computed. You only need to supply one 64-bit hash value as
Blobloom uses the enhanced double hashing algorithm to synthesize any
further hash values it needs.

When I investigated what dependencies were missing in Debian for
syncthing 1.7.1 I found this one.

Best,
Nicholas