Bug#919348: It's been a while...

[Timothy Kenno Handojo]

Hi all, just bumping this since it's been lacking attention lately.

Can we merge this thing to testing? I'm sure things have improved since
then.

It's been included in a lot of other distros already. I know debian aims
for
stability and this package is not the most stable, but this is what testing
is
for, right?

Bug#1015832: msi-keyboard: does not work on MSI GP76

[ioanndev]

Package: msi-keyboard
Version: 1.1-2+b1
Severity: minor
X-Debbugs-Cc: ioann...@gmail.com

Hello! The msi-keyboard does not work on the "GP76 LEOPARD" notebook.

Example:
# msi-keyboard -m normal -c left,red,high -c middle,purple,high -c
right,sky,high
cannot open usb device

I tried as root and as a normal user.

# lsusb | grep -i steelseries
Bus 003 Device 003: ID 1038:113a SteelSeries ApS SteelSeries KLC


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

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

Versions of packages msi-keyboard depends on:
ii  libc62.33-8
ii  libgcc-s1 [libgcc1]  12.1.0-5
ii  libhidapi-libusb00.11.2-1
ii  libqt5core5a 5.15.4+dfsg-4
ii  libstdc++6   12.1.0-5

msi-keyboard recommends no packages.

msi-keyboard suggests no packages.

-- no debconf information

Bug#900244: similar errors on Micron 3400

[Hamish Moffatt]

I am also seeing spurious errors on a Micron 3400 1Tb NVME.


$ sudo smartctl -l error /dev/nvme0
smartctl 7.2 2020-12-30 r5155 [x86_64-linux-5.18.0-0.bpo.1-amd64] (local 
build)

Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF SMART DATA SECTION ===
Error Information (NVMe Log 0x01, 16 of 256 entries)
Num   ErrCount  SQId   CmdId  Status  PELoc  LBA  NSID VS
  0 70 0  0x3011  0x8004  0x000    0 0 -


However the nvme error log is full of non-errors:


$ sudo nvme error-log /dev/nvme0

...

.
 Entry[63]
.
error_count    : 0
sqid        : 0
cmdid        : 0
status_field    : 0(SUCCESS: The command completed successfully)
parm_err_loc    : 0
lba        : 0
nsid        : 0
vs        : 0
trtype        : The transport type is not indicated or the error is not 
transport related.

cs        : 0
trtype_spec_info: 0
.


There's an enhancement request open for smartmontools to ignore this: 
https://www.smartmontools.org/ticket/1222





Hamish

Bug#1004793: vtk7: FTBFS with ffmpeg 5.0

[Peter Green]

vtk7 is one of the (possiblly the) last blockers for the ffmpeg transition
that is in testing and is not marked for autoremoval.
The last 7.x upstream release was over 5 years ago. The last vtk7 upload
by someone listed in "uploaders" was  over 2 years ago. Since then the
package has been kept on life-supportby team-uploads and a NMU.


Control: tags -1 upstream confirmed fixed-upstream

https://gitlab.kitware.com/vtk/vtk/-/commit/34276346ac379fecbd615322f18de837bd2c9ea2


unfortunately it is not that simple, that upstream fix is for a much newer 
version
of vtk and the code seems to have had major restructuring. I could not find
any evidence of a vtk 7 branch in upstreams git repository

It seems that if this code is to survive it needs to be ground through by 
someone
with experiance with the code and with ffmpeg. I had a quick go, but it quickly
became clear that it was non-triial andeven if I got it to compile I would have 
no
idea how to test it. I've attatched a patch reflecting the state of my 
development
tree at the point I gave up.

I have not investigated whether it is feasible to build vtk7 without ffmpeg 
support.

The following source packages or the binaries they produce declare relationships
on vtk7 packages that do not have alternatives.

depends and/or build-depends:
binoculars
camitk
dune-grid
facet-analyser
gdcm
mayavi2
nifti2dicom
openems
python-mne
siconos
vistrails
vtk-dicom

recommends:
debian-science
dipy

suggests:
debian-med

In particular gdcm is a key package due to the fact that opencv build-depends 
on it.
Description: Support ffmpeg 5.
 This patch is inspired by https://gitlab.kitware.com/vtk/vtk/-/commit/34276346ac379fecbd615322f18de837bd2c9ea2
 but practically rewritten due to differences between the two versions.
Author: Peter Michael Green 

---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:

Origin: , 
Bug: 
Bug-Debian: https://bugs.debian.org/
Bug-Ubuntu: https://launchpad.net/bugs/
Forwarded: 
Reviewed-By: 
Last-Update: 2022-07-21

Index: vtk7-7.1.1+dfsg2.save/CMake/FindFFMPEG.cmake
===
--- vtk7-7.1.1+dfsg2.save.orig/CMake/FindFFMPEG.cmake
+++ vtk7-7.1.1+dfsg2.save/CMake/FindFFMPEG.cmake
@@ -107,13 +107,14 @@ FFMPEG_FIND(LIBAVFORMAT avformat avforma
 FFMPEG_FIND(LIBAVDEVICE avdevice avdevice.h)
 FFMPEG_FIND(LIBAVCODEC  avcodec  avcodec.h)
 FFMPEG_FIND(LIBAVUTIL   avutil   avutil.h)
+FFMPEG_FIND(LIBSWRESAMPLE swresample swresample.h)
 FFMPEG_FIND(LIBSWSCALE  swscale  swscale.h)  # not sure about the header to look for here.
 
 SET(FFMPEG_FOUND "NO")
 
 # Note we don't check FFMPEG_LIBSWSCALE_FOUND, FFMPEG_LIBAVDEVICE_FOUND,
 # and FFMPEG_LIBAVUTIL_FOUND as they are optional.
-IF (FFMPEG_LIBAVFORMAT_FOUND AND FFMPEG_LIBAVCODEC_FOUND AND STDINT_OK)
+IF (FFMPEG_LIBAVFORMAT_FOUND AND FFMPEG_LIBAVCODEC_FOUND AND FFMPEG_LIBSWRESAMPLE_FOUND AND STDINT_OK)
 
 SET(FFMPEG_FOUND "YES")
 
Index: vtk7-7.1.1+dfsg2.save/IO/FFMPEG/CMakeLists.txt
===
--- vtk7-7.1.1+dfsg2.save.orig/IO/FFMPEG/CMakeLists.txt
+++ vtk7-7.1.1+dfsg2.save/IO/FFMPEG/CMakeLists.txt
@@ -22,7 +22,7 @@ set_source_files_properties( vtkFFMPEGWr
   )
 
 set(_ffmpeg_libs ${FFMPEG_LIBAVFORMAT_LIBRARIES} ${FFMPEG_LIBAVCODEC_LIBRARIES}
-  ${FFMPEG_LIBAVUTIL_LIBRARIES}
+  ${FFMPEG_LIBAVUTIL_LIBRARIES} ${FFMPEG_LIBSWRESAMPLE_LIBRARIES}
   )
 
 if(NOT VTK_FFMPEG_HAS_IMG_CONVERT)
Index: vtk7-7.1.1+dfsg2.save/Examples/GUI/Qt/SimpleView/CMakeLists.txt
===
--- vtk7-7.1.1+dfsg2.save.orig/Examples/GUI/Qt/SimpleView/CMakeLists.txt
+++ vtk7-7.1.1+dfsg2.save/Examples/GUI/Qt/SimpleView/CMakeLists.txt
@@ -1,104 +1 @@
-cmake_minimum_required(VERSION 2.8.8)
-if(POLICY CMP0020)
-  cmake_policy(SET CMP0020 NEW)
-endif()
-if(POLICY CMP0025)
-  cmake_policy(SET CMP0025 NEW) # CMake 3.0
-endif()
-if(POLICY CMP0043)
-  cmake_policy(SET CMP0043 NEW) # CMake 3.0
-endif()
-if(POLICY CMP0053)
-  cmake_policy(SET CMP0053 NEW) # CMake 3.1
-endif()
-project(SimpleView)
 
-find_package(VTK COMPONENTS
-  vtkCommonCore
-  vtkFiltersCore
-  vtkInfovisCore
-  vtkInteractionStyle
-  vtkViewsQt
-)
-include(${VTK_USE_FILE})
-
-if("${VTK_QT_VERSION}" STREQUAL "")
-  message(FATAL_ERROR "VTK was not built with Qt")
-endif()
-
-# Use the include path and library for Qt that is used by VTK.
-include_directories(
-  ${CMAKE_CURRENT_BINARY_DIR}
-  ${CMAKE_CURRENT_SOURCE_DIR}
-)
-
-# Set your files and resources here
-set( Srcs main.cxx SimpleView.cxx )
-
-set( Hdrs SimpleView.h )
-
-set( MOC_Hdrs SimpleView.h )
-
-set( UIs SimpleView.ui )
-
-set( QRCs Icons/icons.qrc )
-
-
-# Instruct CMake to run moc automatically when needed.
-set(CMAKE_AUTOMOC ON)
-
-# The rest should just work (sure...)

Bug#1015831: [hddtemp] Please keep hddtemp in Debian

[Roman Mamedov]

Package: hddtemp
Severity: wishlist

Hello,

I have been surprised to see the changelog entry about the planned removal of
hddtemp. I would like to leave a couple of comments to that.

>  hddtemp has been dead upstream for many years and is therefore in a minimal
>  maintenance mode. It will be shipped in the Debian Bullseye release, but
>  will not be present in the Debian Bookworm release.

Could it be a case of a program that is basically _done_, i.e. it works, keeps
working, and doesn't need any changes or new features, other than "minimal
maintenance" in the first place?

Or could you give some examples of issues that arise and go unsolved because
of "dead" upstream? Seeing from next to no bugreports in Debian, doesn't seem
that there are many.

>  Nowadays the 'drivetemp' kernel module is a better alternative. It uses the
>  Linux Hardware Monitoring kernel API (hwmon), so the temperature is returned
>  the same way and using the same tools as other sensors.

Does not seem to be the case. Of course running "sensors" then returns:

> drivetemp-scsi-4-0
> Adapter: SCSI adapter
> temp1:+32.0°C  (low  =  +0.0°C, high = +60.0°C)
>(crit low = -40.0°C, crit = +65.0°C)
>(lowest = +28.0°C, highest = +42.0°C)

And what I wanted to know was the temperature of /dev/sda.

There is no "sensors /dev/sda" obviously, and not obvious for the user how to
easily convert sda to scsi-X-Y. Calling *this* the better alternative seems
extremely premature.

At least some wrapper should be introduced (or maybe there's already one?)
that would offer the exact command-line interface as hddtemp, but then
retrieve the temperature in "the better way" under the hood (if there's really
such a pressing need...)

Not to mention it would return 24 of these paragraphs when called
(interrupting all the drives to fetch temperature?), assuming e.g. 24 drives,
even if I wanted the temperature of just one.

>  Loading this module is as easy as creating a file in the /etc/modules-load.d
>  directory:
>
>echo drivetemp > /etc/modules-load.d/drivetemp.conf

Loading it might be easy, but as one proverb says, "only if you're not
interested in the results"...

-- 
With respect,
Roman

Bug#1015169: RFS: mir-eval/0.7-1 [ITP] -- Common metrics for common audio/music processing tasks

[Bastian Germann]

Control: tags -1 moreinfo

Disabling all of the tests is a bit of an overkill. Please only disable the 
ones that need those deprecated classes.
It should be enough to disable test_display and mpl_ic.

Bug#1015169: RFS: mir-eval/0.7-1 [ITP] -- Common metrics for common audio/music processing tasks

[Nilson Silva]

Control: tags -1 - moreinfo


Hello
package is already in salsa:
https://salsa.debian.org/debian/mir-eval

Nilson F. Silva



De: Bastian Germann 
Enviado: quinta-feira, 21 de julho de 2022 12:40
Para: Nilson Silva ; 1015...@bugs.debian.org 
<1015...@bugs.debian.org>
Assunto: Re: Bug#1015169: RFS: mir-eval/0.7-1 [ITP] -- Common metrics for 
common audio/music processing tasks

Control: tags -1 - moreinfo

Am 21.07.22 um 03:48 schrieb Nilson Silva:
> I forked it to my repository because I couldn't push directly to salsa as it 
> was saying I didn't have permission."

Now you should be able to.

Bug#1015830: ITP: python-update-checker -- Python module that checks for package updates

[Ben Westover]

Package: wnpp
X-Debbugs-Cc: debian-de...@lists.debian.org
Owner: Ben Westover 
X-Debbugs-Cc: kwestover...@gmail.com
Severity: wishlist

* Package name: python-update-checker
  Version : 0.18.0
  Upstream Author : Bryce Boe 
* URL : bbzbr...@gmail.com
* License : BSD-2-clause
  Programming Lang: Python
  Description : Python module that checks for package updates

update_checker is a python module that checks for package updates.
Only whitelisted packages can be checked for updates.
Contact update_checker's author for information on adding a package to
the whitelist.

I am packaging this module because it is a dependency of praw, which I
am updating. I will maintain it inside the Python team.

--
Ben Westover


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1015828: qt-gstreamer: has no upstream maintainer

[Simon McVittie]

Source: qt-gstreamer
Version: 1.2.0-5
Severity: important
Tags: upstream wontfix

qt-gstreamer is apparently unmaintained upstream since 2018, and was
never copied from freedesktop.org's old git infrastructure to their
newer Gitlab.

https://cgit.freedesktop.org/gstreamer/qt-gstreamer/commit/?id=a0e95b202a72b6d9e48bd1949ab6811c0f3c91c3:
> This code is unmaintained. You can use it at your own risk.
...
>  **Note**: This component has been closed as of May 5, 2018.
>See the maintenance notice at the top of this file

Bug#1015827:

[Frédéric Mesplède]

In fact I've just realised that the window was now reduced to a one pixel
wide vertical line, practically invisible to the eye. I noticed a white
line over the left panel and when I moved my cursor over it, it changed to
resizing mode, so I concluded that it was the Form Navigator window and
resized it to normal. The button works correctly. Sorry for disturbing you.

Bug#1015827: libreoffice-base: Form navigator button stopped working

[Frédéric Mesplède]

Package: libreoffice-base
Version: 1:7.0.4-4+deb11u1
Severity: normal
Tags: upstream
X-Debbugs-Cc: fredericmespl...@gmail.com

Dear Maintainer,

I was editing a form and I needed to check which form of sub-form grid I was
editing. I opened the from navigator, maximised it and tries to drag and drop
the grid from the sub-form to the form. I couldn't perform that action. I
closed the form navigator without reducing the windows size first. Then I tries
to reopen it again and it failed. The button is punched in but nothing happens.
I tried using a macro as indicated here ( https://ask.libreoffice.org/t/in-
libreoffice-base-5-3-0-3-the-form-navigation-button-stopped-working/23866/3 )
but that doesn't work either. I purged LibreOffice Base from my system,
reinstalled it, but the bug remains.

Thank you for your work.


-- Package-specific info:

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

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

Versions of packages libreoffice-base depends on:
ii  dpkg  1.20.11
ii  libc6 2.31-13+deb11u3
ii  libgcc-s1 10.2.1-6
ii  libreoffice-base-core 1:7.0.4-4+deb11u1
ii  libreoffice-base-drivers  1:7.0.4-4+deb11u1
ii  libreoffice-common1:7.0.4-4+deb11u1
ii  libreoffice-core  1:7.0.4-4+deb11u1
ii  libstdc++610.2.1-6
ii  libuno-cppu3  1:7.0.4-4+deb11u1
ii  libuno-cppuhelpergcc3-3   1:7.0.4-4+deb11u1
ii  libuno-sal3   1:7.0.4-4+deb11u1
ii  libuno-salhelpergcc3-31:7.0.4-4+deb11u1
ii  ucf   3.0043
ii  uno-libs-private  1:7.0.4-4+deb11u1

Versions of packages libreoffice-base recommends:
ii  default-jre [java8-runtime] 2:1.11-72
ii  libreoffice-java-common 1:7.0.4-4+deb11u1
ii  libreoffice-writer  1:7.0.4-4+deb11u1
ii  openjdk-11-jre [java8-runtime]  11.0.15+10-1~deb11u1

Versions of packages libreoffice-base suggests:
pn  libreoffice-report-builder  
ii  python3-uno 1:7.0.4-4+deb11u1
pn  unixodbc

Versions of packages libreoffice-core depends on:
ii  fontconfig  2.13.1-4.2
ii  fonts-opensymbol2:102.11+LibO7.0.4-4+deb11u1
ii  libboost-locale1.74.0   1.74.0-9
ii  libc6   2.31-13+deb11u3
ii  libcairo2   1.16.0-5
ii  libclucene-contribs1v5  2.3.3.4+dfsg-1+b1
ii  libclucene-core1v5  2.3.3.4+dfsg-1+b1
ii  libcmis-0.5-5v5 0.5.2-3
ii  libcups22.3.3op2-3+deb11u2
ii  libcurl3-gnutls 7.74.0-1.3+deb11u1
ii  libdbus-1-3 1.12.20-2
ii  libdconf1   0.38.0-2
ii  libeot0 0.01-5+b1
ii  libepoxy0   1.5.5-1
ii  libexpat1   2.2.10-2+deb11u3
ii  libexttextcat-2.0-0 3.4.5-1
ii  libfontconfig1  2.13.1-4.2
ii  libfreetype62.10.4+dfsg-1+deb11u1
ii  libgcc-s1   10.2.1-6
ii  libglib2.0-02.66.8-1
ii  libgpgmepp6 1.14.0-1+b2
ii  libgraphite2-3  1.3.14-1
ii  libgstreamer-plugins-base1.0-0  1.18.4-2
ii  libgstreamer1.0-0   1.18.4-2.1
ii  libharfbuzz-icu02.7.4-1
ii  libharfbuzz0b   2.7.4-1
ii  libhunspell-1.7-0   1.7.0-3
ii  libhyphen0  2.8.8-7
ii  libice6 2:1.0.10-1
ii  libicu6767.1-7
ii  libjpeg62-turbo 1:2.0.6-4
ii  liblcms2-2  2.12~rc1-2
ii  libldap-2.4-2   2.4.57+dfsg-3+deb11u1
ii  libmythes-1.2-0 2:1.2.4-3+b1
ii  libneon27-gnutls0.31.2-1
ii  libnspr42:4.29-1
ii  libnss3 2:3.61-1+deb11u2
ii  libnumbertext-1.0-0 1.0.7-1
ii  liborcus-0.16-0 0.16.1-3+b2
ii  liborcus-parser-0.16-0  0.16.1-3+b2
ii  libpng16-16 1.6.37-3
ii  libpoppler102   20.09.0-3.1
ii  libqrcodegencpp11.6.0-1
ii  libraptor2-02.0.14-1.2
ii  librdf0 1.0.17-1.1+b1
ii  libreoffice-common  1:7.0.4-4+deb11u1
ii  librevenge-0.0-00.0.4-6+b1
ii  libsm6  2:1.2.3-1
ii  libstdc++6  10.2.1-6
ii  libuno-cppu31:7.0.4-4+deb11u1
ii  libuno-cppuhelpergcc3-3 1:7.0.4-4+deb11u1
ii  libuno-sal3 

Bug#1015826: thunderbird: Thunderbird and Claws Mail (in sid/unstable) not connecting to imap.comcast.net

[epp]

Package: thunderbird
Version: 1:102.0.2-1
Severity: important
X-Debbugs-Cc: e...@mcom.com

Dear Maintainer,

Thunderbird and Claws mail (4.1.0) in sid/unstable wiil not connect to
imap.comcast.net when adding new accounts. Thunderbird will only 
connect to imap.comcast.net if IPv6 is disabled through its configuration
editor and IPv6 cannot be disabled in Claws Mail.

Previously reported under bug 1015225, but it likely is not the correct
package.


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

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

Versions of packages thunderbird depends on:
ii  debianutils  5.7-0.2
ii  fontconfig   2.13.1-4.4
ii  libasound2   1.2.7.1-1
ii  libatk1.0-0  2.38.0-1
ii  libc62.33-8
ii  libcairo-gobject21.16.0-6
ii  libcairo21.16.0-6
ii  libdbus-1-3  1.14.0-2
ii  libdbus-glib-1-2 0.112-2
ii  libevent-2.1-7   2.1.12-stable-5+b1
ii  libffi8  3.4.2-4
ii  libfontconfig1   2.13.1-4.4
ii  libfreetype6 2.12.1+dfsg-3
ii  libgcc-s112.1.0-7
ii  libgdk-pixbuf-2.0-0  2.42.8+dfsg-1
ii  libglib2.0-0 2.72.3-1
ii  libgtk-3-0   3.24.34-1
ii  libicu71 71.1-3
ii  libnspr4 2:4.34-1
ii  libnss3  2:3.79-1
ii  libpango-1.0-0   1.50.7+ds-1
ii  librnp0  0.16.0-1
ii  libstdc++6   12.1.0-7
ii  libvpx7  1.12.0-1
ii  libx11-6 2:1.7.5-1
ii  libx11-xcb1  2:1.7.5-1
ii  libxcb-shm0  1.14-3
ii  libxcb1  1.14-3
ii  libxext6 2:1.3.4-1
ii  libxrandr2   2:1.5.2-2+b1
ii  psmisc   23.5-2
ii  x11-utils7.7+5
ii  zenity   3.42.1-2
ii  zlib1g   1:1.2.11.dfsg-4

Versions of packages thunderbird recommends:
ii  hunspell-ar [hunspell-dictionary]3.2-1.2
ii  hunspell-be [hunspell-dictionary]0.53-3.1
ii  hunspell-bg [hunspell-dictionary]1:7.2.0-2
ii  hunspell-bs [hunspell-dictionary]1:7.2.0-2
ii  hunspell-ca [hunspell-dictionary]3.0.6+repack1-2
ii  hunspell-cs [hunspell-dictionary]1:7.2.0-2
ii  hunspell-da [hunspell-dictionary]1:7.2.0-2
ii  hunspell-de-at [hunspell-dictionary] 20161207-9
ii  hunspell-de-ch [hunspell-dictionary] 20161207-9
ii  hunspell-de-de [hunspell-dictionary] 20161207-9
ii  hunspell-el [hunspell-dictionary]1:7.2.0-2
ii  hunspell-en-gb [hunspell-dictionary] 1:7.2.0-2
ii  hunspell-en-us [hunspell-dictionary] 1:2020.12.07-2
ii  hunspell-eu [hunspell-dictionary]5.1-2
ii  hunspell-fr-classical [hunspell-dictionary]  1:7.0-1
ii  hunspell-gl [hunspell-dictionary]1:7.2.0-2
ii  hunspell-gu [hunspell-dictionary]1:7.2.0-2
ii  hunspell-hi [hunspell-dictionary]1:7.2.0-2
ii  hunspell-hr [hunspell-dictionary]1:7.2.0-2
ii  hunspell-hu [hunspell-dictionary]1:7.2.0-2
ii  hunspell-id [hunspell-dictionary]1:7.2.0-2
ii  hunspell-is [hunspell-dictionary]1:7.2.0-2
ii  hunspell-it [hunspell-dictionary]1:7.2.0-2
ii  hunspell-kk [myspell-dictionary] 1.1-2.1
ii  hunspell-kmr [hunspell-dictionary]   1:7.2.0-2
ii  hunspell-ko [hunspell-dictionary]0.7.92-1
ii  hunspell-lt [hunspell-dictionary]1:7.2.0-2
ii  hunspell-lv [hunspell-dictionary]1.4.0-1.1
ii  hunspell-ne [hunspell-dictionary]1:7.2.0-2
ii  hunspell-nl [hunspell-dictionary]2:2.20.19-2
ii  hunspell-pl [hunspell-dictionary]1:7.2.0-2
ii  hunspell-pt-br [hunspell-dictionary] 1:7.2.0-2
ii  hunspell-pt-pt [hunspell-dictionary] 1:7.2.0-2
ii  hunspell-ro [hunspell-dictionary]1:7.2.0-2
ii  hunspell-ru [hunspell-dictionary]1:7.2.0-2
ii  hunspell-si [hunspell-dictionary]1:7.2.0-2
ii  hunspell-sl [hunspell-dictionary]1:7.2.0-2
ii  hunspell-sr [hunspell-dictionary]1:7.2.0-2
ii  hunspell-sv [hunspell-dictionary]1:7.2.0-2
ii  hunspell-te [hunspell-dictionary]1:7.2.0-2
ii  hunspell-th [hunspell-dictionary]1:7.2.0-2
ii  hunspell-vi [hunspell-dictionary]1:7.2.0-2
ii  myspell-eo [myspell-dictionary]  2.1.2000.02.25-60
ii  myspell-es [myspell-dictionary]  1.11-19
ii  myspell-et [myspell-dictionary]  1:20030606-32
ii  myspell-fa [myspell-dictionary]  0.20070816-3.2
ii  myspell-ga [myspell-dictionary]  2.0-27.1
ii  myspell-he [myspell-dictionary]  1.4-3.1
ii  myspell-nb [myspell-dictionary]   

Bug#992651: Fwd: Bug#992651: sharutils: stores wrong path to bash if built on merged-/usr system

[Santiago Vila]

Hello.

I received the attached patch from the Debian bug system. It was taken 
from sharutils git repository and it allows to pass a value for 
POSIX_SHELL in the ./configure call. We need this for the usrmerge 
transition.


I plan to apply the patch mostly "as is" to the Debian source package, 
but as a result, I have to regenerate autoconf files during the package 
build. Some people do that as a normal thing, but I prefer to do that 
only when it's really necessary, so it would be more simple if there was 
a new sharutils release from upstream. Are there any plans for that?


After all, the last release was made in 2015, and there are even some 
CVE which are still not part of the last stable release.


Thanks.From: Simon McVittie 
Date: Sat, 21 Aug 2021 19:19:03 +0100
Subject: libopts.m4: accept POSIX_SHELL from the environment during
 the configure step

This lets us set it to the canonical path /bin/bash, even on systems
where both /bin/bash and /usr/bin/bash are available, and therefore
which(1) might return /usr/bin/bash (depending on PATH order).

Both copies of libopts.m4 are marked as generated files, but the files
from which they were generated do not seem to be present in the sharutils
package. This change is equivalent to part of a 2016 autogen commit
.

Origin: https://git.savannah.gnu.org/cgit/autogen.git/commit/?id=db064b9a
---
 libopts/m4/libopts.m4 | 1 +
 m4/libopts.m4 | 1 +
 2 files changed, 2 insertions(+)

--- a/libopts/m4/libopts.m4
+++ b/libopts/m4/libopts.m4
@@ -114,6 +114,7 @@
   AC_PROG_SED
   [while :
   do
+  test -x "$POSIX_SHELL" && break
   POSIX_SHELL=`which bash`
   test -x "$POSIX_SHELL" && break
   POSIX_SHELL=`which dash`
--- a/m4/libopts.m4
+++ b/m4/libopts.m4
@@ -114,6 +114,7 @@
   AC_PROG_SED
   [while :
   do
+  test -x "$POSIX_SHELL" && break
   POSIX_SHELL=`which bash`
   test -x "$POSIX_SHELL" && break
   POSIX_SHELL=`which dash`

Bug#1015823: trang: warning "Unable to locate saxonb in /usr/share/java"

[Vincent Lefevre]

On 2022-07-21 23:53:13 +0200, Vincent Lefevre wrote:
> Hi Samuel,
> 
> On 2022-07-21 23:45:49 +0200, Samuel Thibault wrote:
> > Vincent Lefevre, le jeu. 21 juil. 2022 23:28:23 +0200, a ecrit:
> > > When I run trang, I get the following warning:
> > > 
> > > [warning] /usr/bin/trang: Unable to locate saxonb in /usr/share/java
> > 
> > Ah, yes. Could you check that when replacing saxonb with Saxon-HE in
> > /usr/bin/trang, the warning disappears and the tool still works?
> 
> Well, after uninstalling libsaxonb-java (which I installed to
> make the warning disappear), and replacing saxonb with Saxon-HE,
> the warning disappears. But as I'm not using saxon, I don't know
> whether there are any other consequences when saxon is involved.

Actually, this does *not* really solve the problem. I have noticed
that some of the packages (which I don't use directly) were manually
installed, and after marking them as automatically installed, aptitude
proposed to remove them, which I accepted, and in particular, this
concerns libsaxonhe-java (as jing and libjing-java have been removed),
which provides "/usr/share/java/Saxon-HE.jar".

So with the above replacement of saxonb with Saxon-HE, I now get:

[warning] ./trang: Unable to locate Saxon-HE in /usr/share/java

So, I suppose that the fix should add a dependency on libsaxonhe-java
(libjing-java depends on it, but libtrang-java doesn't).

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

Bug#965901: xfonts-encodings: fix FTBFS and missing build-* targets

[Simon McVittie]

On Thu, 21 Jul 2022 at 13:30:19 +0100, Simon McVittie wrote:
> I've prepared merge requests for all the xfonts-* packages (except
> xfonts-utils which contains utilities rather than fonts)

Diffs for -encodings attached. There was no bug report for the missing
build-* targets, but they're also a RC bug.

smcv
>From 18a02f6b69f7b4b5ba9d86933f142ea9d58e3c38 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 21 Jul 2022 10:52:34 +0100
Subject: [PATCH 1/5] d/control: Update Vcs-* for migration to salsa.debian.org

---
 debian/control | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index 4244874..e7efb58 100644
--- a/debian/control
+++ b/debian/control
@@ -11,8 +11,8 @@ Build-Depends-Indep:
  automake,
  xutils-dev (>= 1:7.5+1),
 Standards-Version: 3.8.3
-Vcs-Git: https://anonscm.debian.org/git/pkg-xorg/font/xfonts-encodings.git
-Vcs-Browser: https://anonscm.debian.org/git/pkg-xorg/font/xfonts-encodings.git
+Vcs-Git: https://salsa.debian.org/xorg-team/font/xfonts-encodings.git
+Vcs-Browser: https://salsa.debian.org/xorg-team/font/xfonts-encodings
 
 Package: xfonts-encodings
 Architecture: all
-- 
2.36.1

>From df31d46de9bfc95235ddf7eacffd18297df8e1e2 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 21 Jul 2022 10:54:21 +0100
Subject: [PATCH 2/5] Use recommended debhelper compat level 13

Compat levels 5 and 6 can no longer be built in bookworm.

- d/rules: Replace deprecated dh_clean -k with dh_prep
- d/rules: Replace deprecated dh_install --list-missing with
  dh_missing --list-missing

According to diffoscope, the only change to the resulting binary package
is that this compat level adds the upstream changelog.

Closes: #965901
---
 debian/compat  | 1 -
 debian/control | 2 +-
 debian/rules   | 5 +++--
 3 files changed, 4 insertions(+), 4 deletions(-)
 delete mode 100644 debian/compat

diff --git a/debian/compat b/debian/compat
deleted file mode 100644
index 7ed6ff8..000
--- a/debian/compat
+++ /dev/null
@@ -1 +0,0 @@
-5
diff --git a/debian/control b/debian/control
index e7efb58..8b96496 100644
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,7 @@ Section: x11
 Priority: optional
 Maintainer: Debian X Strike Force 
 Build-Depends:
- debhelper (>= 5.0.0),
+ debhelper-compat (= 13),
 Build-Depends-Indep:
  pkg-config,
  xfonts-utils (>= 1:7.6~),
diff --git a/debian/rules b/debian/rules
index 8e65d61..6c5b69e 100755
--- a/debian/rules
+++ b/debian/rules
@@ -63,7 +63,7 @@ clean: xsfclean
 install: build
 	dh_testdir
 	dh_testroot
-	dh_clean -k
+	dh_prep
 	dh_installdirs
 	cd build && $(MAKE) DESTDIR=$(CURDIR)/debian/tmp install
 
@@ -77,7 +77,8 @@ binary-indep: build install
 	dh_testroot
 
 	dh_installdocs
-	dh_install --sourcedir=debian/tmp --list-missing
+	dh_install --sourcedir=debian/tmp
+	dh_missing --list-missing
 	dh_installchangelogs
 	dh_link
 	dh_strip
-- 
2.36.1

>From 08d314fe524135feadfd07112cc16128c358d16f Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 21 Jul 2022 11:03:13 +0100
Subject: [PATCH 3/5] =?UTF-8?q?d/rules:=20Add=20missing=20targets=20build-?=
 =?UTF-8?q?arch,=20build-indep=20(Policy=20=C2=A74.9)?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This resolves the equivalent of #999177 for this package.

diffoscope confirms that this does not alter the contents of the
resulting binary package.
---
 debian/rules | 4 
 1 file changed, 4 insertions(+)

diff --git a/debian/rules b/debian/rules
index 6c5b69e..c91421c 100755
--- a/debian/rules
+++ b/debian/rules
@@ -34,6 +34,7 @@ endif
 
 
 build: build-stamp
+build-indep: build-stamp
 build-stamp:
 	dh_testdir
 	autoreconf -vfi
@@ -45,6 +46,9 @@ build-stamp:
 	cd build && $(MAKE)
 	>$@
 
+build-arch:
+# Nothing to do
+
 clean: xsfclean
 	dh_testdir
 	dh_testroot
-- 
2.36.1

>From 85bea910a02802776ea51ef59b566a8c20b78cdc Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 21 Jul 2022 11:04:08 +0100
Subject: [PATCH 4/5] d/control: Declare that the build does not require
 (fake)root

diffoscope confirms that this does not alter the contents of the
resulting binary package.
---
 debian/control | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/control b/debian/control
index 8b96496..175e83c 100644
--- a/debian/control
+++ b/debian/control
@@ -13,6 +13,7 @@ Build-Depends-Indep:
 Standards-Version: 3.8.3
 Vcs-Git: https://salsa.debian.org/xorg-team/font/xfonts-encodings.git
 Vcs-Browser: https://salsa.debian.org/xorg-team/font/xfonts-encodings
+Rules-Requires-Root: no
 
 Package: xfonts-encodings
 Architecture: all
-- 
2.36.1

>From 9f73254a4913ef561232802807903716463c9182 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 21 Jul 2022 11:22:48 +0100
Subject: [PATCH 5/5] Update changelog

---
 debian/changelog | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index 136f8d6..df3999b 100644
--- a/debian/changelog
+++ 

Bug#965894: xfonts-scalable: fix FTBFS and missing required debian/rules targets

[Simon McVittie]

On Thu, 21 Jul 2022 at 13:30:19 +0100, Simon McVittie wrote:
> I've prepared merge requests for all the xfonts-* packages (except
> xfonts-utils which contains utilities rather than fonts)

Diffs for -scalable attached. As with -encodings, the missing build-arch
and build-indep targets are a second RC bug, but I'm not going to spend
time reporting a second RC bug and getting a second bug number just so
I can propose a patch to close it.

smcv
>From d8ae598f46674b56152f2a9347bf7712359648aa Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 21 Jul 2022 10:57:08 +0100
Subject: [PATCH 1/5] d/control: Update Vcs-* for migration to salsa.debian.org

---
 debian/control | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index 553de3b..5ffb6d3 100644
--- a/debian/control
+++ b/debian/control
@@ -10,8 +10,8 @@ Build-Depends:
  xutils-dev (>= 1:7.5+1),
  pkg-config,
 Standards-Version: 3.8.3
-Vcs-Git: https://anonscm.debian.org/git/pkg-xorg/font/xfonts-scalable.git
-Vcs-Browser: https://anonscm.debian.org/git/pkg-xorg/font/xfonts-scalable.git
+Vcs-Git: https://salsa.debian.org/xorg-team/font/xfonts-scalable.git
+Vcs-Browser: https://salsa.debian.org/xorg-team/font/xfonts-scalable
 
 Package: xfonts-scalable
 Architecture: all
-- 
2.36.1

>From 020b14f4ce6c9add3e4a7d71578771c66547656e Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 21 Jul 2022 11:05:23 +0100
Subject: [PATCH 2/5] Use recommended debhelper compat level 13

Compat levels 5 and 6 can no longer be built in bookworm.

- d/rules: Replace deprecated dh_clean -k with dh_prep
- d/rules: Replace deprecated dh_install --list-missing with
  dh_missing --list-missing

According to diffoscope, the only change to the resulting binary package
is that this compat level adds the upstream changelog.

Closes: #965894
---
 debian/compat  | 1 -
 debian/control | 2 +-
 debian/rules   | 5 +++--
 3 files changed, 4 insertions(+), 4 deletions(-)
 delete mode 100644 debian/compat

diff --git a/debian/compat b/debian/compat
deleted file mode 100644
index 7ed6ff8..000
--- a/debian/compat
+++ /dev/null
@@ -1 +0,0 @@
-5
diff --git a/debian/control b/debian/control
index 5ffb6d3..580c43a 100644
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,7 @@ Section: fonts
 Priority: optional
 Maintainer: Debian X Strike Force 
 Build-Depends:
- debhelper (>= 5.0.31),
+ debhelper-compat (= 13),
  xfonts-utils (>= 1:7.6~),
  automake,
  autoconf,
diff --git a/debian/rules b/debian/rules
index 478acb1..dc614d7 100755
--- a/debian/rules
+++ b/debian/rules
@@ -64,7 +64,7 @@ clean: xsfclean
 install: build
 	dh_testdir
 	dh_testroot
-	dh_clean -k
+	dh_prep
 	dh_installdirs
 
 	cd build && $(MAKE) DESTDIR=$(CURDIR)/debian/tmp install
@@ -81,7 +81,8 @@ binary-indep: build install
 	dh_testroot
 
 	dh_installdocs
-	dh_install --sourcedir=debian/tmp --fail-missing --exclude=fonts.dir --exclude=fonts.scale
+	dh_install --sourcedir=debian/tmp --exclude=fonts.dir --exclude=fonts.scale
+	dh_missing --fail-missing --exclude=fonts.dir --exclude=fonts.scale
 	dh_installxfonts
 	dh_installchangelogs
 	dh_compress
-- 
2.36.1

>From 1a905ea923b52829645dfa4244542b8723b88d20 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 21 Jul 2022 11:08:00 +0100
Subject: [PATCH 3/5] =?UTF-8?q?d/rules:=20Add=20missing=20build-arch,=20bu?=
 =?UTF-8?q?ild-indep=20targets=20(Policy=20=C2=A74.9)?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This resolves the equivalent of #999177 for this package.

diffoscope confirms that this does not alter the contents of the
resulting binary package.
---
 debian/rules | 4 
 1 file changed, 4 insertions(+)

diff --git a/debian/rules b/debian/rules
index dc614d7..81005dc 100755
--- a/debian/rules
+++ b/debian/rules
@@ -34,6 +34,7 @@ endif
 
 
 build: build-stamp
+build-indep: build-stamp
 build-stamp: $(STAMP_DIR)/prepare
 	dh_testdir
 	autoreconf -vfi
@@ -45,6 +46,9 @@ build-stamp: $(STAMP_DIR)/prepare
 	cd build && $(MAKE)
 	>$@
 
+build-arch:
+# Nothing to do
+
 clean: xsfclean
 	dh_testdir
 	dh_testroot
-- 
2.36.1

>From 8e6373344b0cf78e807c2fd52dba66e2524ce523 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 21 Jul 2022 11:08:23 +0100
Subject: [PATCH 4/5] d/control: Declare that the build does not require
 (fake)root

diffoscope confirms that this does not alter the contents of the
resulting binary package.
---
 debian/control | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/control b/debian/control
index 580c43a..f5a92b9 100644
--- a/debian/control
+++ b/debian/control
@@ -12,6 +12,7 @@ Build-Depends:
 Standards-Version: 3.8.3
 Vcs-Git: https://salsa.debian.org/xorg-team/font/xfonts-scalable.git
 Vcs-Browser: https://salsa.debian.org/xorg-team/font/xfonts-scalable
+Rules-Requires-Root: no
 
 Package: xfonts-scalable
 Architecture: all
-- 
2.36.1

>From 5410658a402f6825a93fcf82513ed47b0c433a7d Mon Sep 17 00:00:00 2001
From: Simon 

Bug#856271: Bug#999177: xfonts-*: missing required debian/rules targets build-arch and/or build-indep

[Thorsten Glaser]

Simon McVittie dixit:

>If that's what you want, here are diffs (these are only the xfonts-base
>subset, the remarkably similar diffs for the other packages will follow
>when I get round to it).

Thanks. Looking good.

>Or if you want to try the web UI, closing the file list/search on the
>left should give the content of the diff enough space to not wrap.

I couldn’t find a way to do that, only to change it between linear
and tree.

bye,
//mirabilos
-- 
  "Using Lynx is like wearing a really good pair of shades: cuts out
   the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL."
 -- Henry Nelson, March 1999

Bug#976571: Bug#999152: xfonts-100dpi: missing required debian/rules targets build-arch and/or build-indep

[Simon McVittie]

On Thu, 21 Jul 2022 at 13:30:19 +0100, Simon McVittie wrote:
> I've prepared merge requests for all the xfonts-* packages (except
> xfonts-utils which contains utilities rather than fonts)

-100dpi diffs attached.

smcv
>From bf4eb2eac34232a1ccf3ee994b48760a8f2c49ed Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 21 Jul 2022 10:30:03 +0100
Subject: [PATCH 1/4] =?UTF-8?q?d/rules:=20Add=20missing=20build-arch,=20bu?=
 =?UTF-8?q?ild-indep=20targets=20(Policy=20=C2=A74.9)?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

diffoscope confirms that this does not alter the contents of the
resulting binary package.

Closes: #999152
---
 debian/rules | 4 
 1 file changed, 4 insertions(+)

diff --git a/debian/rules b/debian/rules
index 6789d06..be92b35 100755
--- a/debian/rules
+++ b/debian/rules
@@ -48,9 +48,13 @@ $(STAMP_DIR)/build-%:
 	>$@
 
 build: build-stamp
+build-indep: build-stamp
 build-stamp: $(addprefix $(STAMP_DIR)/build-,$(SUBDIRS))
 	>$@
 
+build-arch:
+# Nothing to do
+
 clean:
 	dh_testdir
 	rm -f config.cache config.log config.status
-- 
2.36.1

>From eb1382d7797ab31de5846fdf258ff9d8d49b9ea7 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 21 Jul 2022 10:30:42 +0100
Subject: [PATCH 2/4] d/control: Declare that the build does not require
 (fake)root

diffoscope confirms that this does not alter the contents of the
resulting binary package.
---
 debian/control | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/control b/debian/control
index fbce30a..2ca266d 100644
--- a/debian/control
+++ b/debian/control
@@ -6,6 +6,7 @@ Build-Depends: debhelper (>= 7), pkg-config, xfonts-utils (>= 1:7.5)
 Standards-Version: 3.8.3
 Vcs-Git: https://anonscm.debian.org/git/pkg-xorg/font/xfonts-100dpi.git
 Vcs-Browser: https://anonscm.debian.org/cgit/pkg-xorg/font/xfonts-100dpi.git
+Rules-Requires-Root: no
 
 Package: xfonts-100dpi
 Architecture: all
-- 
2.36.1

>From 308ddf0a66269751ea07e5f92125af8182479c7f Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 21 Jul 2022 10:31:23 +0100
Subject: [PATCH 3/4] Use dh_update_autotools_config to update config.guess,
 config.sub

The originals will be put back automatically by dh_clean.

diffoscope confirms that this does not alter the contents of the
resulting binary package.

Closes: #976571
---
 debian/control | 2 +-
 debian/rules   | 6 +-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index 2ca266d..8feb4de 100644
--- a/debian/control
+++ b/debian/control
@@ -2,7 +2,7 @@ Source: xfonts-100dpi
 Section: fonts
 Priority: optional
 Maintainer: Debian X Strike Force 
-Build-Depends: debhelper (>= 7), pkg-config, xfonts-utils (>= 1:7.5)
+Build-Depends: debhelper (>= 10.8), pkg-config, xfonts-utils (>= 1:7.5)
 Standards-Version: 3.8.3
 Vcs-Git: https://anonscm.debian.org/git/pkg-xorg/font/xfonts-100dpi.git
 Vcs-Browser: https://anonscm.debian.org/cgit/pkg-xorg/font/xfonts-100dpi.git
diff --git a/debian/rules b/debian/rules
index be92b35..324aeac 100755
--- a/debian/rules
+++ b/debian/rules
@@ -35,8 +35,12 @@ else
 	confflags += --build=$(DEB_BUILD_GNU_TYPE) --host=$(DEB_HOST_GNU_TYPE)
 endif
 
-$(STAMP_DIR)/build-%:
+$(STAMP_DIR)/prepare:
 	mkdir -p $(STAMP_DIR)
+	dh_update_autotools_config
+	>$@
+
+$(STAMP_DIR)/build-%: $(STAMP_DIR)/prepare
 	mkdir -p $*-build
 	cd $*-build && \
 	../$*/configure \
-- 
2.36.1

>From 11e7a5f7bef7f5586c6ac6f389d32fed94bc04e2 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 21 Jul 2022 11:20:03 +0100
Subject: [PATCH 4/4] Update changelog

---
 debian/changelog | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index 5b66d9e..372c2ef 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,9 +1,17 @@
 xfonts-100dpi (1:1.0.5) UNRELEASED; urgency=medium
 
+  [ Julien Cristau ]
   * Add Vcs-* control fields.
   * Use https for xorg.freedesktop.org URLs in packaging.
 
- -- Julien Cristau   Mon, 02 Feb 2015 21:07:25 +0100
+  [ Simon McVittie ]
+  * d/rules: Add missing build-arch, build-indep targets (Policy §4.9)
+(Closes: #999152)
+  * d/control: Declare that the build does not require (fake)root
+  * Use dh_update_autotools_config to update config.guess, config.sub
+(Closes: #976571)
+
+ -- Simon McVittie   Thu, 21 Jul 2022 11:19:37 +0100
 
 xfonts-100dpi (1:1.0.4+nmu1) unstable; urgency=medium
 
-- 
2.36.1

Bug#976471: Bug#998997: xfonts-75dpi: missing required debian/rules targets build-arch and/or build-indep

[Simon McVittie]

On Thu, 21 Jul 2022 at 13:30:19 +0100, Simon McVittie wrote:
> I've prepared merge requests for all the xfonts-* packages (except
> xfonts-utils which contains utilities rather than fonts)

Diffs for -75dpi attached.

smcv
>From 1f5a1270c484a8e7b6a1ac4be8c09379de97613b Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 21 Jul 2022 10:02:26 +0100
Subject: [PATCH 1/5] d/control: Update Vcs-* for migration to salsa.debian.org

---
 debian/control | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index 43767b9..ed02504 100644
--- a/debian/control
+++ b/debian/control
@@ -7,8 +7,8 @@ Build-Depends:
  pkg-config,
  xfonts-utils (>= 1:7.5),
 Standards-Version: 3.8.3
-Vcs-Git: https://anonscm.debian.org/git/pkg-xorg/font/xfonts-75dpi.git
-Vcs-Browser: https://anonscm.debian.org/cgit/pkg-xorg/font/xfonts-75dpi.git
+Vcs-Git: https://salsa.debian.org/xorg-team/font/xfonts-75dpi.git
+Vcs-Browser: https://salsa.debian.org/xorg-team/font/xfonts-75dpi
 
 Package: xfonts-75dpi
 Architecture: all
-- 
2.36.1

>From d2253649ad53e5d2382d481dc463a5d930f30b08 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 21 Jul 2022 10:18:18 +0100
Subject: [PATCH 2/5] =?UTF-8?q?d/rules:=20Add=20missing=20build-arch,=20bu?=
 =?UTF-8?q?ild-indep=20targets=20(Policy=20=C2=A74.9)?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

diffoscope confirms that this does not alter the contents of the
resulting binary package.

Closes: #998997
---
 debian/rules | 4 
 1 file changed, 4 insertions(+)

diff --git a/debian/rules b/debian/rules
index ef5f2f4..ce29bc9 100755
--- a/debian/rules
+++ b/debian/rules
@@ -48,9 +48,13 @@ $(STAMP_DIR)/build-%:
 	>$@
 
 build: build-stamp
+build-indep: build-stamp
 build-stamp: $(addprefix $(STAMP_DIR)/build-,$(SUBDIRS))
 	>$@
 
+build-arch:
+# Nothing to do.
+
 clean:
 	dh_testdir
 	rm -f config.cache config.log config.status
-- 
2.36.1

>From 27e43c27acefcf2c9e8e5a9d44f6a5b903564b8b Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 21 Jul 2022 10:18:41 +0100
Subject: [PATCH 3/5] d/control: Declare that the build does not require
 (fake)root

diffoscope confirms that this does not alter the contents of the
resulting binary package.
---
 debian/control | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/control b/debian/control
index ed02504..a3cd302 100644
--- a/debian/control
+++ b/debian/control
@@ -9,6 +9,7 @@ Build-Depends:
 Standards-Version: 3.8.3
 Vcs-Git: https://salsa.debian.org/xorg-team/font/xfonts-75dpi.git
 Vcs-Browser: https://salsa.debian.org/xorg-team/font/xfonts-75dpi
+Rules-Requires-Root: no
 
 Package: xfonts-75dpi
 Architecture: all
-- 
2.36.1

>From d0e24c3c6238094c8f2ecb7c874ad38f3caebd06 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 21 Jul 2022 10:19:32 +0100
Subject: [PATCH 4/5] d/rules: Use dh_update_autotools_config to update
 config.guess, config.sub

The originals will be put back automatically by dh_clean.

diffoscope confirms that this does not alter the contents of the
resulting binary package.

Closes: #976471
---
 debian/rules | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index ce29bc9..1fd4653 100755
--- a/debian/rules
+++ b/debian/rules
@@ -35,8 +35,12 @@ else
 	confflags += --build=$(DEB_BUILD_GNU_TYPE) --host=$(DEB_HOST_GNU_TYPE)
 endif
 
-$(STAMP_DIR)/build-%:
+$(STAMP_DIR)/prepare:
 	mkdir -p $(STAMP_DIR)
+	dh_update_autotools_config
+	>$@
+
+$(STAMP_DIR)/build-%: $(STAMP_DIR)/prepare
 	mkdir -p $*-build
 	cd $*-build && \
 	../$*/configure \
-- 
2.36.1

>From e5390c3fe040f36be2ebecf0871f885076597c2a Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 21 Jul 2022 11:18:40 +0100
Subject: [PATCH 5/5] Update changelog

---
 debian/changelog | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index 19903bf..81b4358 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,9 +1,18 @@
 xfonts-75dpi (1:1.0.5) UNRELEASED; urgency=medium
 
+  [ Julien Cristau ]
   * Update Vcs-Git URL to https.
   * Switch xorg.freedesktop.org URLs in packaging to https.
 
- -- Julien Cristau   Sun, 21 Aug 2016 19:10:17 +0200
+  [ Simon McVittie ]
+  * d/control: Update Vcs-* for migration to salsa.debian.org
+  * d/rules: Add missing build-arch, build-indep targets (Policy §4.9)
+(Closes: #998997)
+  * d/control: Declare that the build does not require (fake)root
+  * d/rules: Use dh_update_autotools_config to update config.guess,
+config.sub (Closes: #976471)
+
+ -- Simon McVittie   Thu, 21 Jul 2022 11:18:20 +0100
 
 xfonts-75dpi (1:1.0.4+nmu1) unstable; urgency=medium
 
-- 
2.36.1

Bug#999227: xfonts-cyrillic: missing required debian/rules targets build-arch and/or build-indep

[Simon McVittie]

On Thu, 21 Jul 2022 at 13:30:19 +0100, Simon McVittie wrote:
> I've prepared merge requests for all the xfonts-* packages (except
> xfonts-utils which contains utilities rather than fonts) fixing the
> missing targets required by Policy §4.9

Here are diffs for xfonts-cyrillic as requested.

Because the reproducible builds NMU for xfonts-cyrillic was
mistakenly versioned like a maintainer/QA upload, the changelog
entry assumes that the NMU will be merged, since that seems like
the easiest way to avoid reusing a version number. Please see the MR
https://salsa.debian.org/xorg-team/font/xfonts-cyrillic/-/merge_requests/1
or fetch the qa branch from
https://salsa.debian.org/smcv/xfonts-cyrillic-qa.git for the actual merge
(since a merge as a proper git merge is not easily representable in
diffs), or resolve the changelogs in whatever way you see fit.

smcv
>From 41daa3f4c18e432827d67b771b8f9c5c1f9c624a Mon Sep 17 00:00:00 2001
From: Holger Levsen 
Date: Fri, 1 Jan 2021 17:23:03 +0100
Subject: [PATCH 1/6] Import Debian version 1.0.5

xfonts-cyrillic (1:1.0.5) unstable; urgency=medium
.
  * Non maintainer upload by the Reproducible Builds team.
  * No source change upload to rebuild on buildd with .buildinfo files.
---
 debian/changelog | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index 1f51b52..b8f7d69 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+xfonts-cyrillic (1:1.0.5) unstable; urgency=medium
+
+  * Non maintainer upload by the Reproducible Builds team.
+  * No source change upload to rebuild on buildd with .buildinfo files.
+
+ -- Holger Levsen   Fri, 01 Jan 2021 17:23:03 +0100
+
 xfonts-cyrillic (1:1.0.4) unstable; urgency=medium
 
   * Get rid of debian/xsfbs/.
-- 
2.36.1

>From bd08f1035f774974d2005e1182be680155c2b4ea Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 21 Jul 2022 10:36:27 +0100
Subject: [PATCH 2/6] d/control: Update Vcs-* for migration to salsa.debian.org

---
 debian/control | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index 6164ab6..62b7df3 100644
--- a/debian/control
+++ b/debian/control
@@ -7,8 +7,8 @@ Build-Depends:
  xfonts-utils (>= 1:7.5),
  pkg-config,
 Standards-Version: 3.8.3
-Vcs-Git: https://anonscm.debian.org/git/pkg-xorg/font/xfonts-cyrillic.git
-Vcs-Browser: https://anonscm.debian.org/git/pkg-xorg/font/xfonts-cyrillic.git
+Vcs-Git: https://salsa.debian.org/xorg-team/font/xfonts-cyrillic.git
+Vcs-Browser: https://salsa.debian.org/xorg-team/font/xfonts-cyrillic
 
 Package: xfonts-cyrillic
 Architecture: all
-- 
2.36.1

>From 4b2f9a5f220307fe94177f563af7ae7bfdba81d7 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 21 Jul 2022 10:34:58 +0100
Subject: [PATCH 3/6] =?UTF-8?q?d/rules:=20Add=20missing=20build-arch,=20bu?=
 =?UTF-8?q?ild-indep=20targets=20(Policy=20=C2=A74.9)?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

diffoscope confirms that this does not alter the contents of the
resulting binary package.

Closes: #999227
---
 debian/rules | 4 
 1 file changed, 4 insertions(+)

diff --git a/debian/rules b/debian/rules
index cbfa1f4..907896d 100755
--- a/debian/rules
+++ b/debian/rules
@@ -48,9 +48,13 @@ $(STAMP_DIR)/build-%:
 	>$@
 
 build: build-stamp
+build-indep: build-stamp
 build-stamp: $(addprefix $(STAMP_DIR)/build-,$(SUBDIRS))
 	>$@
 
+build-arch:
+# Nothing to do
+
 clean:
 	dh_testdir
 	rm -f config.cache config.log config.status
-- 
2.36.1

>From 29cffc196b0dd0846c2186a38d512c45f70e18aa Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 21 Jul 2022 10:36:52 +0100
Subject: [PATCH 4/6] d/control: Declare that the build does not require
 (fake)root

diffoscope confirms that this does not alter the contents of the
resulting binary package.
---
 debian/control | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/control b/debian/control
index 62b7df3..0da8a6b 100644
--- a/debian/control
+++ b/debian/control
@@ -9,6 +9,7 @@ Build-Depends:
 Standards-Version: 3.8.3
 Vcs-Git: https://salsa.debian.org/xorg-team/font/xfonts-cyrillic.git
 Vcs-Browser: https://salsa.debian.org/xorg-team/font/xfonts-cyrillic
+Rules-Requires-Root: no
 
 Package: xfonts-cyrillic
 Architecture: all
-- 
2.36.1

>From 1b9d9460084ab69873a4dda5d5dc7d343b065232 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 21 Jul 2022 10:38:10 +0100
Subject: [PATCH 5/6] d/rules: Use dh_update_autotools_config to update
 config.guess, config.sub

The originals will be put back automatically by dh_clean.

diffoscope confirms that this does not alter the contents of the
resulting binary package.

Fixes the equivalent of #856271, #976471, #976571 for this package.
---
 debian/control | 2 +-
 debian/rules   | 6 +-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index 0da8a6b..18deb4f 100644
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,7 

Bug#856271: Bug#999177: xfonts-*: missing required debian/rules targets build-arch and/or build-indep

[Simon McVittie]

On Thu, 21 Jul 2022 at 16:35:31 +, Thorsten Glaser wrote:
> Simon McVittie dixit:
> 
> >I've prepared merge requests for all the xfonts-* packages (except
>
> IMHO, things like this ought to be sent as diffs attached to
> the bugreport(s) in question.

If that's what you want, here are diffs (these are only the xfonts-base
subset, the remarkably similar diffs for the other packages will follow
when I get round to it).

Not all of the things I've fixed have bug reports on all the packages.

> Probably somewhat offtopic, but… Salsa isn’t an appropriate tool
> Or how would someone be able to review the diff like
> *that* (see attached screenshot)?

I had assumed that a team that has put repositories on Salsa is able to
receive commits from it. Each Gitlab MR can be fetched as a git branch,
if you prefer to use the CLI for review:

[remote "merge-requests"]
url = https://salsa.debian.org/xorg-team/font/xfonts-base.git
fetch = +refs/merge-requests/*/head:refs/remotes/merge-requests/*

Or if you want to try the web UI, closing the file list/search on the
left should give the content of the diff enough space to not wrap.

smcv
>From 0ecb409ab80272e5a8203ec93a4225b9e3a3d970 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 21 Jul 2022 09:47:34 +0100
Subject: [PATCH 1/4] =?UTF-8?q?d/rules:=20Add=20missing=20build-arch,=20bu?=
 =?UTF-8?q?ild-indep=20targets=20(Policy=20=C2=A74.9)?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

diffoscope confirms that this does not alter the contents of the
resulting binary package.

Closes: #999177
---
 debian/rules | 4 
 1 file changed, 4 insertions(+)

diff --git a/debian/rules b/debian/rules
index d73519e..99f313b 100755
--- a/debian/rules
+++ b/debian/rules
@@ -60,9 +60,13 @@ $(STAMP_DIR)/build-%:
 
 
 build: build-stamp
+build-indep: build-stamp
 build-stamp: $(addprefix $(STAMP_DIR)/build-,$(SUBDIRS))
 	>$@
 
+build-arch:
+# Nothing to do.
+
 clean:
 	dh_testdir
 	rm -f config.cache config.log config.status
-- 
2.36.1

>From a9dfb137281b58e92298403ef7a07f392b7ba2ab Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 21 Jul 2022 09:52:36 +0100
Subject: [PATCH 2/4] d/control: Declare that the build does not require
 (fake)root

diffoscope confirms that this does not alter the contents of the
resulting binary package.
---
 debian/control | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/control b/debian/control
index 856a54b..b0a9ff5 100644
--- a/debian/control
+++ b/debian/control
@@ -11,6 +11,7 @@ Build-Depends-Indep:
 Standards-Version: 3.8.3
 Vcs-Git: https://salsa.debian.org/xorg-team/font/xfonts-base.git
 Vcs-Browser: https://salsa.debian.org/xorg-team/font/xfonts-base
+Rules-Requires-Root: no
 
 Package: xfonts-base
 Architecture: all
-- 
2.36.1

>From 7b7691843c453886803a4a1fe1a5fa497a33e9d4 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 21 Jul 2022 10:15:54 +0100
Subject: [PATCH 3/4] d/rules: Use dh_update_autotools_config to update
 config.guess, config.sub

The originals will be put back automatically by dh_clean.

diffoscope confirms that this does not alter the contents of the
resulting binary package.

Closes: #856271
---
 debian/control | 2 +-
 debian/rules   | 6 +-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index b0a9ff5..2dcf9db 100644
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,7 @@ Section: fonts
 Priority: optional
 Maintainer: Debian X Strike Force 
 Build-Depends:
- debhelper (>= 7),
+ debhelper (>= 10.8),
 Build-Depends-Indep:
  pkg-config,
  xfonts-utils (>= 1:7.5),
diff --git a/debian/rules b/debian/rules
index 99f313b..4e548a7 100755
--- a/debian/rules
+++ b/debian/rules
@@ -45,8 +45,12 @@ else
 	confflags += --build=$(DEB_BUILD_GNU_TYPE) --host=$(DEB_HOST_GNU_TYPE)
 endif
 
-$(STAMP_DIR)/build-%:
+$(STAMP_DIR)/prepare:
 	mkdir -p $(STAMP_DIR)
+	dh_update_autotools_config
+	>$@
+
+$(STAMP_DIR)/build-%: $(STAMP_DIR)/prepare
 	mkdir -p $*-build
 	cd $*-build && \
 	../$*/configure \
-- 
2.36.1

>From 3b12af51d153637bd0e45967e47f1d47a616e162 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 21 Jul 2022 11:16:44 +0100
Subject: [PATCH 4/4] Update changelog

---
 debian/changelog | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index 7271df0..d8a5622 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+xfonts-base (1:1.0.6) UNRELEASED; urgency=medium
+
+  * d/rules: Add missing build-arch, build-indep targets (Policy §4.9)
+(Closes: #999177)
+  * d/control: Declare that the build does not require (fake)root
+  * d/rules: Use dh_update_autotools_config to update config.guess,
+config.sub (Closes: #856271)
+
+ -- Simon McVittie   Thu, 21 Jul 2022 11:15:36 +0100
+
 xfonts-base (1:1.0.5) unstable; urgency=medium
 
   * Add Vcs-* control fields.
-- 
2.36.1

Bug#1015823: trang: warning "Unable to locate saxonb in /usr/share/java"

[Samuel Thibault]

Vincent Lefevre, le ven. 22 juil. 2022 00:02:58 +0200, a ecrit:
> On 2022-07-21 23:54:26 +0200, Samuel Thibault wrote:
> > Vincent Lefevre, le jeu. 21 juil. 2022 23:45:55 +0200, a ecrit:
> > > - bin/dtdinst,jing,trang: Look for saxonb instead of saxon.
> > > 
> > > So trang expects /usr/share/java/saxonb.jar,
> > 
> > No, it's actually Saxon-HE, see build.gradle.kts, maven-jing.xml.
> 
> OK, if I understand correctly, the "Look for saxonb instead of saxon"
> (as mentioned in Debian's changelog file) was incorrect.

Yes, I was a bit confused between saxon, saxonb, saxon9, saxon-he, as to
what is supposed to be used nowadays.

Samuel

Bug#1015823: trang: warning "Unable to locate saxonb in /usr/share/java"

[Vincent Lefevre]

On 2022-07-21 23:54:26 +0200, Samuel Thibault wrote:
> Vincent Lefevre, le jeu. 21 juil. 2022 23:45:55 +0200, a ecrit:
> > - bin/dtdinst,jing,trang: Look for saxonb instead of saxon.
> > 
> > So trang expects /usr/share/java/saxonb.jar,
> 
> No, it's actually Saxon-HE, see build.gradle.kts, maven-jing.xml.

OK, if I understand correctly, the "Look for saxonb instead of saxon"
(as mentioned in Debian's changelog file) was incorrect.

> Nothing in the upstream source talks about saxonb any more.

Indeed, a "grep -r saxonb" finds matches only in the debian directory.

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

Bug#1015823: trang: warning "Unable to locate saxonb in /usr/share/java"

[Vincent Lefevre]

Hi Samuel,

On 2022-07-21 23:45:49 +0200, Samuel Thibault wrote:
> Vincent Lefevre, le jeu. 21 juil. 2022 23:28:23 +0200, a ecrit:
> > When I run trang, I get the following warning:
> > 
> > [warning] /usr/bin/trang: Unable to locate saxonb in /usr/share/java
> 
> Ah, yes. Could you check that when replacing saxonb with Saxon-HE in
> /usr/bin/trang, the warning disappears and the tool still works?

Well, after uninstalling libsaxonb-java (which I installed to
make the warning disappear), and replacing saxonb with Saxon-HE,
the warning disappears. But as I'm not using saxon, I don't know
whether there are any other consequences when saxon is involved.

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

Bug#1015823: trang: warning "Unable to locate saxonb in /usr/share/java"

[Samuel Thibault]

Control: retitle -1 trang: warning "Unable to locate saxonb in /usr/share/java"
Control: severity -1 normal

Hello,

Vincent Lefevre, le jeu. 21 juil. 2022 23:45:55 +0200, a ecrit:
> - bin/dtdinst,jing,trang: Look for saxonb instead of saxon.
> 
> So trang expects /usr/share/java/saxonb.jar,

No, it's actually Saxon-HE, see build.gradle.kts, maven-jing.xml.
Nothing in the upstream source talks about saxonb any more.

Samuel

Bug#982887: #982887: cross building Ruby extensions

[Antonio Terceiro]

Hi,

After a long time, I was able to finish a first version of this. The
solution has two parts:

1) Per Ruby version, per architecture rbconfig.rb provided by
ruby-all-dev:

$ dpkg -L ruby-all-dev:amd64 ruby-all-dev:arm64 | grep rbconfig
/usr/lib/x86_64-linux-gnu/ruby-crossbuild/3.0.0/rbconfig.rb
/usr/lib/aarch64-linux-gnu/ruby-crossbuild/3.0.0/rbconfig.rb

Packages that use Ruby by hand should add the corresponding directory to
the Ruby load path when calling ruby, like this (examples from an amd64
system):

$ ruby -e 'puts RbConfig::CONFIG["rubyarchhdrdir"]'
/usr/include/x86_64-linux-gnu/ruby-3.0.0
$ ruby -I/usr/lib/aarch64-linux-gnu/ruby-crossbuild/3.0.0 -e 'puts 
RbConfig::CONFIG["rubyarchhdrdir"]'
/usr/include/aarch64-linux-gnu/ruby-3.0.0

This will cause the rbconfig.rb of the desired host architecture to have
precedence over the native one, and things should generally work.

2) For standard Ruby packages, gem2deb 2.0 (about to be uploaded) should
handle the cross building itself automatically out of the box.

Most build dependencies in Ruby packages are used to run the tests, but
anotating them with   is still needed in other to
optimize bootstrapping.


signature.asc
Description: PGP signature

Bug#1015823: trang: warning "Unable to locate saxonb in /usr/share/java"

[Vincent Lefevre]

Control: retitle -1 trang: should depend on libsaxonb-java; otherwise, warning 
"Unable to locate saxonb in /usr/share/java"
Control: severity -1 serious

On 2022-07-21 23:28:23 +0200, Vincent Lefevre wrote:
> When I run trang, I get the following warning:
> 
> [warning] /usr/bin/trang: Unable to locate saxonb in /usr/share/java
> 
> even without arguments (this is incorrect usage, but this test shows
> that the warning is not due to some specific processing).

/usr/share/doc/trang/changelog.Debian.gz says:

jing-trang (20220510-1) unstable; urgency=medium

  * New upstream release.
- control: Drop libsaxon-java build-dep, now unused.
- bin/dtdinst,jing,trang: Look for saxonb instead of saxon.
  * control: Bump Standards-Version to 4.6.0 (no change)
  * gbp.conf: Fix filtering lib directory

 -- Samuel Thibault   Sun, 12 Jun 2022 13:34:50 +0200

So trang expects /usr/share/java/saxonb.jar, so that it should
depend on libsaxonb-java, which provides this file. And indeed,
the warning disappears after installing this package.

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

Bug#1015823: trang: warning "Unable to locate saxonb in /usr/share/java"

[Samuel Thibault]

Control: tags -1 + pending

Hello,

Vincent Lefevre, le jeu. 21 juil. 2022 23:28:23 +0200, a ecrit:
> When I run trang, I get the following warning:
> 
> [warning] /usr/bin/trang: Unable to locate saxonb in /usr/share/java

Ah, yes. Could you check that when replacing saxonb with Saxon-HE in
/usr/bin/trang, the warning disappears and the tool still works?

Samuel

Bug#1015823: trang: warning "Unable to locate saxonb in /usr/share/java"

[Vincent Lefevre]

Package: trang
Version: 20220510-1
Severity: normal

When I run trang, I get the following warning:

[warning] /usr/bin/trang: Unable to locate saxonb in /usr/share/java

even without arguments (this is incorrect usage, but this test shows
that the warning is not due to some specific processing).

Even if this is not due to a real issue, this is an annoying bug as
this warning is disturbing and may make scripts fail in case they
expect nothing on the standard error (fd 2). And if used in cron
commands, this would make cron send mail to the owner of the crontab.

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

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

Versions of packages trang depends on:
ii  default-jre [java-runtime] 2:1.11-72
ii  java-wrappers  0.3
ii  libtrang-java  20220510-1
ii  openjdk-11-jre [java-runtime]  11.0.16+8-1

trang recommends no packages.

trang suggests no packages.

-- no debconf information

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

Bug#1015096: 1015096 is caused by a newer version of mupdf

[Louis-Philippe Véronneau]

retitle 1015096 qpdfview: FTBFS with mupdf 1.20.0
forwarded 1015096 https://bugs.launchpad.net/qpdfview/+bug/1982513
thanks

I've confirmed this FTBFS is caused by the upgrade from mupdf from 
1.19.0 to 1.20.0.


I've forwarded this bug upstream.

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

Bug#1015240: Acknowledgement (linux: rejecting DMA map of vmalloc memory)

[Ben Hutchings]

Control: fixed -1 5.19~rc6-1~exp1
Control: tag -1 pending

On Tue, 2022-07-19 at 18:45 +0200, Kurt Roeckx wrote:
> On Tue, Jul 19, 2022 at 06:11:23PM +0200, Diederik de Haas wrote:
> > According to that bug report it should be fixed with 5.19-rc6 and that 
> > version 
> > is available in experimental. Can you verify whether it also fixes your 
> > issue?
> 
> With that version the error goes away.

The fix is also in 5.18.11 and will be included in the next unstable
upload.

Ben.

-- 
Ben Hutchings
Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer


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

Bug#1015817: Additional info

[John Wick]

Dear Maintainer,

When 'ignore noroot' is written  to .config/firejail/calibre.local 
Evince works from Calibre and Evince remembers metadata(the last open 
page) but firejail --list shows only Calibre.


Kind Regards,
John

-
This free account was provided by VFEmail.net - report spam to ab...@vfemail.net

ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the 
NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!  
15GB disk! No bandwidth quotas!
Commercial and Bulk Mail Options!  

Bug#1015781: autopkgtests fail if user foo exists or existed

[Marc Haber]

On Thu, Jul 21, 2022 at 08:37:32AM -0400, Jason Franklin wrote:
> On Thu, Jul 21, 2022 at 08:27:15AM +0200, Marc Haber wrote:
> > The tests expect the test environment to be fresh.
> 
> When I wrote the initial autopkgtests, my thought was that this was the
> entire design idea of the system.

I think it is, but test environments might be recycled instead of
rebuilding them, and stupid maintainers (=me) might check whether
adduser is operational at all by using adduser --system foo before
invoking autopkgtests.

> Each stanza in the debian/tests/control file results in the
> instantiation of a new chroot or container before its named collection
> of tests is run.

I don't think that is true if autopkgtest ish run with the null
virtualization method. I didn't automate that yet, so I log in to a new
container, invoke autopkgtest . -- null and then ditch the container. I
think in that case all stanzas in the control file run in the same
container, but I might be wrong.

> > They relay too much on uids being the same and do not preseed adduser
> > to provide reproducible uids.
> 
> I can understand that this is a problem.

Not a problem that needs to be worked on urgently.

> If new Debian system users or groups are added to the base files, or if
> default ID ranges change, we have an issue when specific ID numbers are
> relied upon.
> 
> This was why my tests mainly picked usernames and not ID numbers.
> 
> If Debian ever puts the user "foo" in the base system, we'll need to do
> a find and replace to change "foo" to something else. ID numbers will be
> harder to change, so they should be avoided or selected dynamically.

I'd fist migrate away from those easy user names like "test2a" and "foo"
and use something less likely to conflict such as "auapt-test2a"
(AddUser AutoPkgTest).

Second, we could configure adduser for the tests to use 900-999 instead
of 100-999 for system users and 5-5 for normal users, reducing
the chance to have UID clashes.

Third, we're allowed to break the environment, so we could just remove
all users occupying "our" names and "our" UIDs before running the tests.

Gee, this is going to be fun once adduser starts growing a memory and
not reassigning UIDs that have ever been used.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#1015820: ITP: amgcl -- C header-only C++ library for solving large sparse linear systems with algebraic multigrid method

[Dima Kogan]

Package: wnpp
Owner: Dima Kogan 
Severity: wishlist

* Package name: amgcl
  Version : 1.4.3
  Upstream Author : Denis Demidov
* URL or Web page : https://github.com/ddemidov/amgcl
* License : MIT
  Description : C header-only C++ library for solving large sparse linear 
systems with algebraic multigrid method

Bug#1003856: fatal rendering error

[Dominik Szmek]

Hi Ralph,

I cannot reproduce it. Could you provide more information about your
Perl installation?

best,
dominik

GPG: 0xB28A0AB9F13EFD61


signature.asc
Description: PGP signature

Bug#1015817: firejail: Calibre doesn't start Evince

[John]

Package: firejail
Version: 0.9.58.2-2+deb10u3
Severity: important
Tags: upstream

Dear Maintainer,

When trying to read a pdf book from Calibre, Calibre doesn't open it.

My terminal shows this:
evince: util.c:927: create_empty_file_as_root: Assertion `s.st_uid == 0'
failed.

When run /usr/bin/calibre as have been written at
https://github.com/netblue30/firejail/issues/5222 it opens it.

Also Evince doesn't save metadata - the last read page as an example.

Kind Regards,
John






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

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

Versions of packages firejail depends on:
ii  libapparmor1  2.13.2-10
ii  libc6 2.28-10+deb10u1

Versions of packages firejail recommends:
ii  firejail-profiles  0.9.58.2-2+deb10u3
ii  iproute2   4.20.0-2+deb10u1
ii  iptables   1.8.2-4
ii  xauth  1:1.0.10-1
ii  xpra   4.3.4-r0-1
ii  xserver-xephyr 2:1.20.4-1+deb10u4
ii  xvfb   2:1.20.4-1+deb10u4

firejail suggests no packages.

-- no debconf information

Bug#1015759: ovmf: OVMF_CODE_4M.ms.fd puts EFI shell first in boot order

[dann frazier]

tag 1015759 + confirmed
thanks

On Wed, Jul 20, 2022 at 04:45:03PM +, Robert wrote:
> Package: ovmf
> Version: 2022.05-2
> Severity: normal
> X-Debbugs-Cc: robert.schneide...@sap.com
> 
> Dear Maintainer,
> 
> I'm trying to test an image creation mechanism by booting the resulting
> image with QEMU with Secure Boot enforced. Unfortunately, the
> OVMF_VARS*.ms.fd seems to define a boot order where the EFI shell is
> placed before the disk.

Hm.. that must be a side effect of enrolling the keys, but I'm not
sure why that would be. Certainly we could clear the BootOrder
variable during that process, but I'd like to first understand what is
changing it to begin with.

> In other words, I land in an EFI shell when I try to boot. This only
> happens for the .ms.fd files; the OVMF_{CODE,VARS}_4M.fd directly boot
> the attached disk.
> 
> I can change the boot order manually, save a new vars file and then boot
> from the disk using that vars file. However that was not quite easy for
> me to find out, I would appreciate if the secure-boot-enforcing and
> non-enforcing files could behave similarly with regards to the boot order.
> 
> My qemu invocation:
> 
> qemu-system-x86_64 \
>   -machine q35 \
>   -global ICH9-LPC.disable_s3=1 \
>   -nodefaults \
>   -nographic \
>   -drive 
> if=pflash,format=raw,unit=0,readonly=on,file=/usr/share/OVMF/OVMF_CODE_4M.ms.fd
>  \
>   -drive 
> if=pflash,format=raw,unit=1,readonly=on,file=/usr/share/OVMF/OVMF_VARS_4M.ms.fd
>  \
>   -drive file=image.qcow2,media=disk,index=1 \
>   -serial mon:stdio
> 
> I'm not sure why the -machine and -global options are needed but I guess
> that's an unrelated issue.

Q35 is required for secure boot. The 4M images shouldn't need s3
disabled, but the 2M ones do (they use 64-bit PEI, which doesn't
support S3 w/ SMM).

Bug#1013420: corsix-th FTBFS with ffmpeg 5.0.1

[Steve Langasek]

Package: corsix-th
Followup-For: Bug #1013420
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic ubuntu-patch
Control: tags -1 patch

Upstream has committed a fix for this issue.  Please find attached a debdiff
that cherry-picks this fix and lets corsix-th build against ffmpeg 5.0.

I have uploaded this change to Ubuntu for the ffmpeg 5.0 transition.

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 corsix-th-0.65.1/debian/control corsix-th-0.65.1/debian/control
--- corsix-th-0.65.1/debian/control 2022-07-19 05:45:58.0 -0700
+++ corsix-th-0.65.1/debian/control 2022-07-21 10:46:54.0 -0700
@@ -1,8 +1,7 @@
 Source: corsix-th
 Section: contrib/games
 Priority: optional
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: Debian Games Team 

+Maintainer: Debian Games Team 
 Uploaders:
  Alexandre Detiste ,
  Phil Morrell ,
diff -Nru corsix-th-0.65.1/debian/patches/0001-Support-ffmpeg-5.patch 
corsix-th-0.65.1/debian/patches/0001-Support-ffmpeg-5.patch
--- corsix-th-0.65.1/debian/patches/0001-Support-ffmpeg-5.patch 1969-12-31 
16:00:00.0 -0800
+++ corsix-th-0.65.1/debian/patches/0001-Support-ffmpeg-5.patch 2022-07-21 
10:46:36.0 -0700
@@ -0,0 +1,61 @@
+From 95be4c96810818d05b668c373711cd8f38d4e8b4 Mon Sep 17 00:00:00 2001
+From: "Stephen E. Baker" 
+Date: Tue, 1 Mar 2022 06:24:01 -0500
+Subject: [PATCH] Support ffmpeg 5
+
+AVCodec* was made const in lavc 59.0.100 and lavf 59.0.100
+---
+ CorsixTH/Src/th_movie.cpp | 6 +++---
+ CorsixTH/Src/th_movie.h   | 8 +++-
+ 2 files changed, 10 insertions(+), 4 deletions(-)
+
+Index: corsix-th-0.65.1/CorsixTH/Src/th_movie.cpp
+===
+--- corsix-th-0.65.1.orig/CorsixTH/Src/th_movie.cpp
 corsix-th-0.65.1/CorsixTH/Src/th_movie.cpp
+@@ -414,8 +414,8 @@
+ 
+ bool movie_player::load(const char* szFilepath) {
+   int iError = 0;
+-  AVCodec* m_pVideoCodec;
+-  AVCodec* m_pAudioCodec;
++  av_codec_ptr m_pVideoCodec;
++  av_codec_ptr m_pAudioCodec;
+ 
+   unload();  // Unload any currently loaded video to free memory
+   aborting = false;
+@@ -457,7 +457,7 @@
+ }
+ 
+ AVCodecContext* movie_player::get_codec_context_for_stream(
+-AVCodec* codec, AVStream* stream) const {
++av_codec_ptr codec, AVStream* stream) const {
+ #if (defined(CORSIX_TH_USE_LIBAV) && \
+  LIBAVCODEC_VERSION_INT >= AV_VERSION_INT(57, 14, 0)) || \
+ (defined(CORSIX_TH_USE_FFMPEG) &&\
+Index: corsix-th-0.65.1/CorsixTH/Src/th_movie.h
+===
+--- corsix-th-0.65.1.orig/CorsixTH/Src/th_movie.h
 corsix-th-0.65.1/CorsixTH/Src/th_movie.h
+@@ -68,6 +68,12 @@
+ #define CORSIX_TH_MOVIE_USE_SEND_PACKET_API
+ #endif
+ 
++#if LIBAVCODEC_VERSION_INT < AV_VERSION_INT(59, 0, 100)
++using av_codec_ptr = AVCodec*;
++#else
++using av_codec_ptr = const AVCodec*;
++#endif
++
+ //! \brief Drop in replacement for AVPacketList
+ //!
+ //! AVPacketList which was deprecated with FFMpeg 4.4.
+@@ -330,7 +336,7 @@
+   1024;  ///< Buffer for audio playback
+ 
+   //! Get the AVCodecContext associated with a given stream
+-  AVCodecContext* get_codec_context_for_stream(AVCodec* codec,
++  AVCodecContext* get_codec_context_for_stream(av_codec_ptr codec,
+AVStream* stream) const;
+ 
+   //! Get the time the given frame should be played (from the start of the
diff -Nru corsix-th-0.65.1/debian/patches/series 
corsix-th-0.65.1/debian/patches/series
--- corsix-th-0.65.1/debian/patches/series  2021-08-29 18:48:58.0 
-0700
+++ corsix-th-0.65.1/debian/patches/series  2022-07-21 10:43:46.0 
-0700
@@ -1,2 +1,3 @@
 default_config.patch
 build-Remove-FindSDL2-find-module-use-sdl2-config.cmake-i.patch
+0001-Support-ffmpeg-5.patch

Bug#1015203: can't reproduce issue

[Andreas B. Mundt]

Control: tags -1 unreproducible

Hi Martin-Éric,

thanks for your bug report.  I tried to reproduce your issue, but it
works fine in my test setup.  I installed di-netboot-assistant and
created '/var/lib/tftpboot/'. Then I ran:

 'di-netboot-assistant install stable' 

and finally removed the package with:

  'apt purge di-netboot-assistant'.  

No errors, an empty '/var/lib/tftpboot/d-i/' remains, all other stuff
(i.e. the n-a directory) is removed.

Can you test again and provide more details about your scenario?
Is there anything special in your setup? 

Thanks,

  Andi

Bug#1015816: firejail: Unable to create a whitelisted config file

[anonymous coward]

Package: firejail
Version: 0.9.64.4-2
Severity: normal
X-Debbugs-Cc: debbug.firej...@sideload.33mail.com

The app “toot” generally needs to create and access this config file:

  ~/.config/toot/config.json

For organizational and backup reasons, I’ve taken these steps
(in effect):

  $ mv ~/.config ~/my_config_files
  $ ln -s ~/my_config_files ~/.config

So ~/.config is a symlink pointing to ~/my_config_files.  To avoid
supplying a symlink to Firejail, it’s launched as follows:

  $ firejail --env=XDG_CONFIG_HOME="$HOME"/my_config_files\
 --whitelist="$(readlink $HOME/.config)"toot/config.json\
 --noblacklist="$(readlink $HOME/.config)"toot/config.json\
 toot login

The readlink command substitution converts the symlink to a full
absolute pathname (not symbolic).  Passing the XDG_CONFIG_HOME
variable ensures that the app itself makes no reference to the
symbolic link, which is confirmed by the app’s output showing:

===8<--
  Creating config file at /home/user/my_config_files/toot/config.json
===8<--

The app runs without issue, but when the app terminates there is no
existing file /home/user/my_config_files/toot/config.json.

-- System Information:
Debian Release: 11.4
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'testing'), (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages firejail depends on:
ii  libapparmor1  2.13.6-10
ii  libc6 2.31-13+deb11u3
ii  libselinux1   3.1-3

Versions of packages firejail recommends:
ii  firejail-profiles  0.9.64.4-2+deb11u1
ii  iproute2   5.10.0-4
ii  iptables   1.8.7-1
ii  xauth  1:1.1-1
ii  xdg-dbus-proxy 0.1.2-2
ii  xpra   3.0.13+dfsg1-1
ii  xvfb   2:1.20.11-1+deb11u1

firejail suggests no packages.

-- Configuration Files:
/etc/firejail/firejail.config changed [not included]

-- no debconf information

Bug#1014429:

[Andreas Hasenack]

I created a salsa PR with my attempt at fixing this:

https://salsa.debian.org/kernel-team/nfs-utils/-/merge_requests/18

Bug#1014299: linux-image-5.10.0-15-amd64: No audio on Thinkpad Helix 2 (broadwell-rt286); "firmware ready timeout"

[Benjamin Moody]

The problem seems to be related to the IOMMU.

With kernel 5.10.0-16-amd64:

intel_iommu=off: sound and video both working
intel_iommu=on,intgpu_off (Debian default): video working, sound broken
intel_iommu=on: sound and video both broken

With kernel 4.19.0-21-amd64:

intel_iommu=off (Debian default): sound and video both working
intel_iommu=on,igfx_off: video working, sound broken
intel_iommu=on: sound working, video broken

So a workaround is to set 'intel_iommu=off' on the kernel command line.

However, given that the old driver (snd-soc-sst-haswell-pcm) works
with 'intel_iommu=on', perhaps this can be fixed for the new driver
(snd-soc-catpt) as well.

Bug#1015813: toot: User guide missing and man page should mention files & variables used by the app

[anonymous coward]

Package: toot
Version: 0.27.0-1
Severity: minor
X-Debbugs-Cc: debbug.t...@sideload.33mail.com

The default config file is apparently ~/.config/toot/config.json, but
this is not mentioned in the man page. The man page should also
mention how to change which config file is used, if possible.  It
should also include environment variables the app
uses. E.g. presumably the app looks at XDG_CONFIG_HOME, which might be
a way to at least change where the config file is rooted (if there is
no specific option).

Apart from the man page, there is:

  /usr/share/doc/toot/changelog.Debian.gz

There should ideally be a complete user guide there.  The upstream
repo directs users to this Cloudflare site:

  https://toot.readthedocs.io/

Cloudflare is an access restricted walled garden that excludes some
users, and it violates the privacy of users who unwittingly go there.
It also violates the FSF Free Documentation criteria, IIRC.  Therefore
the user guide should be imported into /usr/share/doc/toot/.  Apart
from Cloudflare abuses, it’s worth noting that it’s generally useful
to have local offline docs anyway.

-- System Information:
Debian Release: 11.4
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'testing'), (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages toot depends on:
ii  python3   3.9.2-3
ii  python3-bs4   4.9.3-1
ii  python3-requests  2.25.1+dfsg-2
ii  python3-urwid 2.1.2-1
ii  python3-wcwidth   0.1.9+dfsg1-2

toot recommends no packages.

toot suggests no packages.

-- no debconf information

Bug#1015810: dropbear-initramfs: dropbear runs for quite a while after boot if network fails to start

[Graham Cobb]

Package: dropbear-initramfs
Version: 2022.82-3
Severity: minor

While experimenting with the kernel 'ip=' parameter (see Bug#1015287),
I have been seeing strange errors on screen during bootup. Note that
these are cases in which the kernel networking initialisation fails but,
as I don't actually need initramfs dropbear access for the boot itself,
the system continues to boot anyway.

As an example of the strange error: part way through the main system boot
(at least a minute AFTER initramfs is over and the main startup is
running) I get this message:

/scripts/init-premount/dropbear: line 384: can't open '/run/net-*.conf': No 
such file or directory

Other messages and errors occur - in some circumstances I have seen many,
many screenfuls of errors complaining that many basic system utilities are
missing (although startup works despite the messages)! I assume the
initramfs busybox files have disappeared from the filesystem but has left
some script running.

I am guessing main issue is the one documented in "wait_for_dropbear" in
/usr/share/initramfs-tools/scripts/init-bottom/dropbear. wait_for_dropbear
seems to be waiting for a long time (longer than the initramfs takes to run
and well into the main system startup), before giving up and returning.
By the time it returns, the initramfs context has disappeared and the rest of
init-bottom/dropbear (and also /scripts/init-premount/dropbear ??) are
running in an environment where the initramfs is no longer available.

I assume that this will occur on any system which does not require user
interaction during initramfs but has dropbear-initramfs and an invalid 'ip='
specification.

I am setting the priority to minor because it seems the only impact is that
the console loses a load of startup messages because of the spurious messages
from the initramfs scripts still running after main boot is underway.

Graham

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

Kernel: Linux 5.18.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_IE.utf8, LC_CTYPE=en_IE.utf8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_IE.utf8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dropbear-initramfs depends on:
ii  busybox  1:1.35.0-1
ii  dropbear-bin 2022.82-3
ii  initramfs-tools  0.142
ii  udev 251.2-7

Versions of packages dropbear-initramfs recommends:
ii  cryptsetup-initramfs  2:2.4.3-1

dropbear-initramfs suggests no packages.

-- debconf-show failed

Bug#1015809: isc-dhcp-client: DHCPv6 doesn't work on ppp interface, got `Unsupported device type` error

[Yuxiang Zhu]

Package: isc-dhcp-client
Version: 4.4.1-2.3
Severity: important
Tags: ipv6 patch upstream
X-Debbugs-Cc: vfr...@gmail.com

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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

isc-dhcp-client can't be used on PPP interfaces:

```
$ sudo dhclient -6 -d -cf ./dhclient6_pppoe0.conf -pf
dhclient6_pppoe0.pid -lf $PWD/dhclient6_pppoe0.leases -N pppoe0 
 
Internet Systems Consortium DHCP Client 4.4.1
Copyright 2004-2018 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Unsupported device type 512 for "pppoe0"
```

My IPS assigns IPv6 addresses and prefixes using DHCPv6 over PPPoE.
WIDE DHCPv6 client supports DHCPv6 over PPP however it is not
feature-rich as ISC DHCP Client. I would like to use ISC DHCP if this
issue is fixed.

I found this thread
https://lists.isc.org/pipermail/dhcp-users/2020-February/021991.html on
ISC mailing list, which mentioned an old patch. I also found Fedora has
an up-to-date patch
https://src.fedoraproject.org/rpms/dhcp/blob/rawhide/f/0013-DHCPv6-over-PPP-support-626514.patch.

I tested this patch with
https://salsa.debian.org/debian/isc-dhcp/-/tree/master/debian/patches
locally and it is working fine.

I saw ISC has stopped maintaining the DHCP client. Is it possible to
accept this patch to Debian?

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

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

Versions of packages isc-dhcp-client depends on:
ii  debianutils4.11.2
ii  iproute2   5.10.0-4
ii  libc6  2.31-13+deb11u3
ii  libdns-export1110  1:9.11.19+dfsg-2.1
ii  libisc-export1105  1:9.11.19+dfsg-2.1

Versions of packages isc-dhcp-client recommends:
ii  isc-dhcp-common  4.4.1-2.3

Versions of packages isc-dhcp-client suggests:
pn  avahi-autoipd 
pn  isc-dhcp-client-ddns  
pn  resolvconf

-- no debconf information

Bug#1012597: aegisub: updating from libboost-regex1.74.0-14 to libboost-regex1.74.0-16 ask to remove aegisub

[KeyofBlueS]

This is fixed with aegisub 3.2.2+dfsg-6.3

Thanks and best regards.

Bug#1015819: src:litecoin: fails to migrate to testing for too long: FTBFS on i386

[Paul Gevers]

Source: litecoin
Version: 0.18.1-1.1
Severity: serious
Control: close -1 0.21.2-1
Tags: sid bookworm ftbfs
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:litecoin has been trying to migrate for 61 
days [2]. Hence, I am filing this bug. You package failed to build from 
source on i386 while it built there successfully in the past.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and bookworm, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=litecoin



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1015818: src:python-clevercsv: fails to migrate to testing for too long: unresolved RC bug

[Paul Gevers]

Source: python-clevercsv
Version: 0.7.1+ds-2
Severity: serious
Control: close -1 0.7.4+ds-1
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1011421

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:python-clevercsv has been trying to 
migrate for 61 days [2]. Hence, I am filing this bug. Your latest upload 
introduced an RC issue (and by that failing autopkgtests) which was 
reported earlier in bug 1011421.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and bookworm, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=python-clevercsv



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1004769: Processed: severity of 1004769 is important

[Steven Robbins]

On Thursday, July 21, 2022 11:24:03 A.M. CDT Debian Bug Tracking System wrote:
> Processing commands for cont...@bugs.debian.org:
> > severity 1004769 important
> 
> Bug #1004769 [src:digikam] Video support missing (FTBFS with ffmpeg 5.0)
> Severity set to 'important' from 'serious'

I had deliberately set the severity as serious to make it appear in apt-
listbugs.  Of course, one is free to disagree with my rationale, but it would 
be nice to document the reasons.  

I'm willing to concede that "important" is appropriate but: the concern 
expressed by Vincent Danjean is that folks may not be adequately alerted (by 
apt-listbugs) when upgrading that the video support is going away and there is 
no reasonable way to downgrade once you've installed this version.  

Is that  unreasonable?

Regards,
-Steve


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

Bug#1015808: linux-image-5.18.0-2-amd64: Please enable mt7921u module in order to support usb wireless card using this chipset

[Yaacov Akiba Slama]

Package: src:linux
Version: 5.18.5-1
Severity: wishlist
X-Debbugs-Cc: yaslama+bugs.debian@gmail.com

Thanks!

Bug#1012451: [Android-tools-devel] Bug#1012451: apksigner: Using PKCS11 keystore fails with NoSuchMethodException

[Hans-Christoph Steiner]

That was exactly what I was asking, thanks for the testing.  My guess is that 
upstream has fixed this in newer releases.  There is work underway to update 
this package.  Plus there is a newer version available in bullseye-backports: 
31.0.2-1~bpo11+1: all

Bug#1015807: haskell-free FTBFS: error: Expecting one more argument to ‘TyVarBndr’

[Adrian Bunk]

Source: haskell-free
Version: 5.1.3-1
Severity: serious
Tags: ftbfs bookworm sid

https://buildd.debian.org/status/fetch.php?pkg=haskell-free=amd64=5.1.3-1%2Bb2=1658416168=0

...
src/Control/Monad/Free/TH.hs:205:22: error:
• Expecting one more argument to ‘TyVarBndr’
  Expected a type, but ‘TyVarBndr’ has kind ‘* -> *’
• In the type signature:
liftCon' :: Bool
-> [TyVarBndr]
   -> Cxt -> Type -> Type -> [Type] -> Name -> [Type] -> Q 
[Dec]
|
205 | liftCon' :: Bool -> [TyVarBndr] -> Cxt -> Type -> Type -> [Type] -> Name 
-> [Type] -> Q [Dec]
|  ^

src/Control/Monad/Free/TH.hs:245:21: error:
• Expecting one more argument to ‘TyVarBndr’
  Expected a type, but ‘TyVarBndr’ has kind ‘* -> *’
• In the type signature:
liftCon :: Bool
   -> [TyVarBndr]
  -> Cxt -> Type -> Type -> [Type] -> Maybe [Name] -> Con 
-> Q [Dec]
|
245 | liftCon :: Bool -> [TyVarBndr] -> Cxt -> Type -> Type -> [Type] -> Maybe 
[Name] -> Con -> Q [Dec]
| ^

src/Control/Monad/Free/TH.hs:271:53: error:
• Expecting one more argument to ‘TyVarBndr’
  Expected a type, but ‘TyVarBndr’ has kind ‘* -> *’
• In the type signature:
liftGadtC :: Name
 -> [BangType]
-> Type -> Bool -> [TyVarBndr] -> Cxt -> Type -> Q [Dec]
|
271 | liftGadtC :: Name -> [BangType] -> Type -> Bool -> [TyVarBndr] -> Cxt -> 
Type -> Q [Dec]
| ^
 at /usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 107.

Debian::Debhelper::Buildsystem::Haskell::Recipes::run_quiet("debian/hlibrary.setup",
 "build", "--builddir=dist-ghc") called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 131

Debian::Debhelper::Buildsystem::Haskell::Recipes::run("debian/hlibrary.setup", 
"build", "--builddir=dist-ghc") called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 642
Debian::Debhelper::Buildsystem::Haskell::Recipes::build_recipe() called 
at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:160: build-ghc-stamp] Error 25

Bug#1015169: RFS: mir-eval/0.7-1 [ITP] -- Common metrics for common audio/music processing tasks

[Bastian Germann]

Control: tags -1 - moreinfo

Am 21.07.22 um 03:48 schrieb Nilson Silva:

I forked it to my repository because I couldn't push directly to salsa as it was 
saying I didn't have permission."


Now you should be able to.

Bug#1015806: haskell-th-desugar FTBFS: Encountered missing or private dependencies: template-haskell >=2.9 && <2.16

[Adrian Bunk]

Source: haskell-th-desugar
Version: 1.10-1
Severity: serious
Tags: ftbfs bookworm sid

https://buildd.debian.org/status/fetch.php?pkg=haskell-th-desugar=amd64=1.10-1%2B

...
hlibrary.setup: Encountered missing or private dependencies:
template-haskell >=2.9 && <2.16

 at /usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 107.

Debian::Debhelper::Buildsystem::Haskell::Recipes::run_quiet("debian/hlibrary.setup",
 "configure", "--ghc", "-v2", "--package-db=/var/lib/ghc/package.conf.d", 
"--prefix=/usr", "--libdir=/usr/lib/haskell-packages/ghc/lib", 
"--libexecdir=/usr/lib", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 131

Debian::Debhelper::Buildsystem::Haskell::Recipes::run("debian/hlibrary.setup", 
"configure", "--ghc", "-v2", "--package-db=/var/lib/ghc/package.conf.d", 
"--prefix=/usr", "--libdir=/usr/lib/haskell-packages/ghc/lib", 
"--libexecdir=/usr/lib", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 622
Debian::Debhelper::Buildsystem::Haskell::Recipes::configure_recipe() 
called at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:155: configure-ghc-stamp] Error 
25

Bug#1015805: scikit-learn tries to access network during documentation build

[M. Zhou]

Source: scikit-learn
Version: 1.1.1-1
Severity: serious
Justification: Policy section 4.9 violation

There are loads of similar traceback message saying the documentation build
has failed to retrieve some URL, like this:

```
generating gallery for auto_examples/decomposition... [ 30%] 
plot_faces_decomposition.py   
WARNING: /<>/examples/decomposition/plot_faces_decomposition.py 
failed to execute correctly: Traceback (most recent ca
ll last):   
   
  File "/<>/examples/decomposition/plot_faces_decomposition.py", 
line 36, in  
faces, _ = fetch_olivetti_faces(return_X_y=True, shuffle=True, 
random_state=rng)   
  File 
"/<>/.pybuild/cpython3_3.10/build/sklearn/datasets/_olivetti_faces.py",
 line 117, in fetch_olivetti_faces  
mat_path = _fetch_remote(FACES, dirname=data_home)  
   
  File 
"/<>/.pybuild/cpython3_3.10/build/sklearn/datasets/_base.py", line 
1511, in _fetch_remote  
urlretrieve(remote.url, file_path)  
   
  File "/usr/lib/python3.10/urllib/request.py", line 241, in urlretrieve
   
with contextlib.closing(urlopen(url, data)) as fp:  
   
  File "/usr/lib/python3.10/urllib/request.py", line 216, in urlopen
   
return opener.open(url, data, timeout)  
   
  File "/usr/lib/python3.10/urllib/request.py", line 519, in open   
   
response = self._open(req, data)
   
  File "/usr/lib/python3.10/urllib/request.py", line 536, in _open  
   
result = self._call_chain(self.handle_open, protocol, protocol +
   
  File "/usr/lib/python3.10/urllib/request.py", line 496, in _call_chain
   
result = func(*args)
   
  File "/usr/lib/python3.10/urllib/request.py", line 1391, in https_open
   
return self.do_open(http.client.HTTPSConnection, req,   
   
  File "/usr/lib/python3.10/urllib/request.py", line 1351, in do_open   
   
raise URLError(err)
urllib.error.URLError: 
```

This is clearly policy violation and should be patched.
This issue is found during the QEMU build on ppc64el machine for the armel 
architecture, and it extremly slows down the building
process likely due to URL access timeout.

As a result, the URL access timeout took the whole night and the doc build is 
not yet finished by a half.
Well, I guess I will have to wait for two or three days to see the discussed 
armel segfault in qemu with this problem unfixed.

Bug#1004801: cloudcompare: FTBFS with ffmpeg 5.0

[Steve Langasek]

Package: cloudcompare
Version: 2.11.3-5
Followup-For: Bug #1004801
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic ubuntu-patch
Control: tags -1 patch

Hi Gürkan,

The attached patch fixes the build failure with ffmpeg 5.0.  I have uploaded
this fix to Ubuntu.  Unfortunately there doesn't appear to be an upstream
test suite, so I'm not certain whether it works with this change.

-- 
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 cloudcompare-2.11.3/debian/control cloudcompare-2.11.3/debian/control
--- cloudcompare-2.11.3/debian/control  2022-07-19 05:45:18.0 -0700
+++ cloudcompare-2.11.3/debian/control  2022-07-21 08:00:54.0 -0700
@@ -1,8 +1,7 @@
 Source: cloudcompare
 Section: graphics
 Priority: optional
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: Gürkan Myczko 
+Maintainer: Gürkan Myczko 
 Build-Depends: debhelper-compat (= 13), cmake, libqt5opengl5-dev, libcgal-dev, 
libdxflib-dev (>= 2.5.0),
  libglew-dev, libfreenect-dev, libgdal-dev, libgomp1, libboost-all-dev, 
libavcodec-dev, libavformat-dev, libswscale-dev, libeigen3-dev,
  libjsoncpp-dev, libcurl4-gnutls-dev | libcurl4-openssl-dev, libcgal-qt5-dev, 
libqt5svg5-dev, qttools5-dev-tools, qttools5-dev
diff -Nru cloudcompare-2.11.3/debian/patches/ffmpeg-5.0.patch 
cloudcompare-2.11.3/debian/patches/ffmpeg-5.0.patch
--- cloudcompare-2.11.3/debian/patches/ffmpeg-5.0.patch 1969-12-31 
16:00:00.0 -0800
+++ cloudcompare-2.11.3/debian/patches/ffmpeg-5.0.patch 2022-07-21 
07:59:38.0 -0700
@@ -0,0 +1,144 @@
+Description: compatibility with ffmpeg 5.0.
+Author: Steve Langasek 
+Bug-Debian: https://bugs.debian.org/1004801
+Last-Update: 2022-07-21
+Forwarded: no
+
+Index: 
cloudcompare-2.11.3/plugins/core/Standard/qAnimation/src/QTFFmpegWrapper/QVideoEncoder.cpp
+===
+--- 
cloudcompare-2.11.3.orig/plugins/core/Standard/qAnimation/src/QTFFmpegWrapper/QVideoEncoder.cpp
 
cloudcompare-2.11.3/plugins/core/Standard/qAnimation/src/QTFFmpegWrapper/QVideoEncoder.cpp
+@@ -116,9 +116,6 @@
+   return false;
+   }
+ 
+-  //Initialize libavcodec, and register all codecs and formats
+-  av_register_all();
+-
+   // find the output format
+   avformat_alloc_output_context2(_ff->formatContext, NULL, NULL, 
qPrintable(m_filename));
+   if (!m_ff->formatContext)
+@@ -139,7 +136,7 @@
+   AVCodecID codec_id = m_ff->formatContext->oformat->video_codec;
+   //codec_id = AV_CODEC_ID_MPEG1VIDEO;
+   //codec_id = AV_CODEC_ID_H264;
+-  AVCodec *pCodec = avcodec_find_encoder(codec_id);
++  const AVCodec *pCodec = avcodec_find_encoder(codec_id);
+   if (!pCodec)
+   {
+   if (errorString)
+@@ -191,7 +188,9 @@
+   return false;
+   }
+   m_ff->videoStream->id = m_ff->formatContext->nb_streams-1;
+-  m_ff->videoStream->codec = m_ff->codecContext;
++  m_ff->videoStream->codecpar = avcodec_parameters_alloc();
++  avcodec_parameters_from_context(m_ff->videoStream->codecpar,
++  m_ff->codecContext);
+   m_ff->videoStream->time_base.num = 1;
+   m_ff->videoStream->time_base.den = m_fps;
+ 
+@@ -269,31 +268,28 @@
+   memset( , 0, sizeof( AVPacket ) );  
+   av_init_packet();
+ 
+-  int got_packet = 0;
+-  int ret = avcodec_encode_video2(m_ff->codecContext, , 0, 
_packet);
+-  if (ret < 0 || !got_packet)
+-  {
+-  break;
++  while (avcodec_receive_packet(m_ff->codecContext, ) > 0) {
++  write_frame(m_ff, );
+   }
+ 
+-  write_frame(m_ff, );
+-
+   av_packet_unref();
+   }
+ 
+   av_write_trailer(m_ff->formatContext);
+ 
+   // close the codec
+-  avcodec_close(m_ff->videoStream->codec);
++  avcodec_free_context(_ff->codecContext);
+ 
+   // free the streams and other data
+   freeFrame();
+   for(unsigned i = 0; i < m_ff->formatContext->nb_streams; i++)
+   {
+-  av_freep(_ff->formatContext->streams[i]->codec);
++  
avcodec_parameters_free(_ff->formatContext->streams[i]->codecpar);
+   av_freep(_ff->formatContext->streams[i]);
+   }
+ 
++  avcodec_parameters_free(_ff->videoStream->codecpar);
++
+   // close the file
+   avio_close(m_ff->formatContext->pb);
+ 
+@@ -325,39 +321,46 @@
+   av_init_packet();
+ 
+   // encode the image
+-  int got_packet = 0;
+-  {
+-  //compute correct timestamp based on the input frame index
+-  //int timestamp = 

Bug#1000245: new upstream required for ttyd

[Boyuan Yang]

Hi,

On Fri, 15 Jul 2022 05:57:14 +0200 Daniel Baumann
 wrote:
> Hi,
> 
> is there any news or ETA for an updated package?

For node-node-sass, please check
https://tracker.debian.org/pkg/node-node-sass to see if current version in
Debian Testing / Debian Unstable satisfies your need of package ttyd.

Thanks,
Boyuan Yang


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

Bug#1015804: Clean out conffile which is installed again by the package

[Sebastien Bacher]

Package: speech-dispatcher
Version: 0.11.1-3

The package includes a maintscript  entry to clean out 
/etc/speech-dispatcher/modules/mary-generic.conf on upgrade but that 
file is provided by the package again


The issue was initially reported on 
https://bugs.launchpad.net/ubuntu/+source/speech-dispatcher/+bug/1981611 
as triggering a conffile change prompt on upgrade from old versions


The attach patch fixes the issue by removing the entry

Cheers,
diff -Nru speech-dispatcher-0.11.1/debian/changelog speech-dispatcher-0.11.1/debian/changelog
--- speech-dispatcher-0.11.1/debian/changelog	2022-05-28 22:59:04.0 +0200
+++ speech-dispatcher-0.11.1/debian/changelog	2022-07-21 17:15:31.0 +0200
@@ -1,3 +1,11 @@
+speech-dispatcher (0.11.1-4) UNRELEASED; urgency=medium
+
+  * debian/speech-dispatcher.maintscript:
+- don't remove mary-generic.conf on upgrade, it's included in the
+  package again. Fix conffile prompt on update (lp: #1981611)
+
+ -- Sebastien Bacher   Thu, 21 Jul 2022 17:15:31 +0200
+
 speech-dispatcher (0.11.1-3) unstable; urgency=medium
 
   * patches/clibrary2: avoid iterating over each and every voice.
diff -Nru speech-dispatcher-0.11.1/debian/speech-dispatcher.maintscript speech-dispatcher-0.11.1/debian/speech-dispatcher.maintscript
--- speech-dispatcher-0.11.1/debian/speech-dispatcher.maintscript	2021-12-11 23:07:04.0 +0100
+++ speech-dispatcher-0.11.1/debian/speech-dispatcher.maintscript	2022-07-21 17:15:31.0 +0200
@@ -1,5 +1,4 @@
 rm_conffile /etc/speech-dispatcher/modules/mary-generic-disabled.conf 0.11.0~ speech-dispatcher
-rm_conffile /etc/speech-dispatcher/modules/mary-generic.conf 0.10.1-2~ speech-dispatcher
 rm_conffile /etc/speech-dispatcher/modules/espeak-generic.conf 0.10.2-1~ speech-dispatcher
 rm_conffile /etc/speech-dispatcher/modules/pico-generic.conf 0.10.2-1~ speech-dispatcher
 rm_conffile /etc/speech-dispatcher/modules/ivona.conf 0.10.2-3~ speech-dispatcher

Bug#1015803: gnome-control-center: Sound page has no "None" option for Alert Sound.

[Matt Barry]

Package: gnome-control-center
Version: 1:42.3-2
Severity: wishlist
Tags: upstream



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

Kernel: Linux 5.18.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
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 not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gnome-control-center depends on:
ii  accountsservice   22.08.8-1
ii  apg   2.2.3.dfsg.1-5+b2
ii  colord1.4.6-1
ii  desktop-base  11.0.3
ii  desktop-file-utils0.26-1
ii  gnome-control-center-data 1:42.3-2
ii  gnome-desktop3-data   42.3-1
ii  gnome-settings-daemon 42.2-1
ii  gsettings-desktop-schemas 42.0-1
ii  libaccountsservice0   22.08.8-1
ii  libadwaita-1-01.2~alpha-1
ii  libc6 2.33-8
ii  libcairo2 1.16.0-6
ii  libcolord-gtk4-1  0.3.0-3
ii  libcolord21.4.6-1
ii  libcups2  2.4.2-1
ii  libepoxy0 1.5.10-1
ii  libfontconfig12.13.1-4.4
ii  libgcr-base-3-1   3.41.1-1
ii  libgdk-pixbuf-2.0-0   2.42.8+dfsg-1
ii  libglib2.0-0  2.72.3-1
ii  libgnome-bg-4-1   42.3-1
ii  libgnome-bluetooth-ui-3.0-13  42.1-1
ii  libgnome-desktop-4-1  42.3-1
ii  libgnome-rr-4-1   42.3-1
ii  libgnutls30   3.7.6-2
ii  libgoa-1.0-0b 3.44.0-1
ii  libgoa-backend-1.0-1  3.44.0-1
ii  libgsound01.0.3-2
ii  libgtk-3-03.24.34-1
ii  libgtk-4-14.6.6+ds-1
ii  libgtop-2.0-112.40.0-2
ii  libgudev-1.0-0237-2
ii  libibus-1.0-5 1.5.26-4
ii  libkrb5-3 1.19.2-2+b2
ii  libmalcontent-0-0 0.10.5-1
ii  libmm-glib0   1.18.10-1
ii  libnm01.38.2-1
ii  libnma-gtk4-0 1.8.40-1
ii  libpango-1.0-01.50.7+ds-1
ii  libpangocairo-1.0-0   1.50.7+ds-1
ii  libpolkit-gobject-1-0 0.105-33
ii  libpulse-mainloop-glib0   15.0+dfsg1-4+b1
ii  libpulse0 15.0+dfsg1-4+b1
ii  libpwquality1 1.4.4-1+b1
ii  libsecret-1-0 0.20.5-2
ii  libsmbclient  2:4.16.3+dfsg-1
ii  libsnapd-glib11.60-1
ii  libudisks2-0  2.9.4-1
ii  libupower-glib3   0.99.20-1
ii  libwacom9 2.2.0-1
ii  libx11-6  2:1.7.5-1
ii  libxi62:1.8-1
ii  libxml2   2.9.14+dfsg-1

Versions of packages gnome-control-center recommends:
ii  cracklib-runtime  2.9.6-4
ii  cups-pk-helper0.2.6-1+b1
ii  gkbd-capplet  3.26.1-2
ii  gnome-online-accounts 3.44.0-1
ii  gnome-remote-desktop  42.3-1
ii  gnome-user-docs   42.0-1
ii  gnome-user-share  3.34.0-5
ii  iso-codes 4.10.0-1
ii  libnss-myhostname 251.3-1
ii  malcontent-gui0.10.5-1
ii  network-manager-gnome 1.28.0-1
ii  policykit-1   0.105-33
ii  power-profiles-daemon 0.11.1-1
ii  pulseaudio-module-bluetooth   15.0+dfsg1-4+b1
ii  realmd0.17.0-2
ii  rygel 0.40.4-1
ii  rygel-tracker 0.40.4-1
ii  system-config-printer-common  1.5.16-1

Versions of packages gnome-control-center suggests:
ii  gnome-software   42.3-1
ii  gstreamer1.0-pulseaudio  1.20.3-1
ii  x11-xserver-utils7.7+9

-- no debconf information

Bug#1015314: Suggestion for a solution

[Philippe Clérié]

I've tried to look at this a bit more closely and it seems to me that what
is missing is an alternative sqlite related dependency:

dep: default-mysql-client OR postgresql-client OR mariadb-client ??OR
SQLite related??

I think there are 3 possibilities:
- sqlite3
- php-sqlite3
- libsqlite3

I believe libsqlite3 is a default package so it wouldn't work. php-sqlite3
is best kept with the other php packages. The sqlite3 client being the
only option left, the dep would be:

dep: default-mysql-client OR postgresql-client OR mariadb-client OR sqlite3


Philippe


The trouble with common sense is that it is so uncommon.

Bug#1014177: qemu-user-static: QEMU aarch64 user mode emulation always segfaults

[Tony Garnock-Jones]

Hi,

I think I'm seeing the same thing. Reproduction from a fresh install of 
bookworm on an x86_64 host:


# dpkg --add-architecture arm64
# apt update
# apt install hello:arm64
# apt install qemu-user-static binfmt-support
# hello
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault

This is the probable cause of a problem I was trying to resolve with 
docker, namely that running an aarch64 container hangs. To reproduce 
*that*, follow the above steps, then:


# apt install docker.io
# docker run -it --rm --platform=linux/arm64 alpine:edge uname -m
(it hangs and never prints anything)
(which is different from the behaviour for e.g. 32 bit arm)

Could this be related to

 - Debian bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=999421
 - Upstream qemu issue https://gitlab.com/qemu-project/qemu/-/issues/555

?

Tony

Bug#1015802: RFP: qrcp -- transfer files by qrcode

[Antoine Beaupre]

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

* Package name: qrcp
  Version : 0.9.1
  Upstream Author : https://github.com/claudiodangelis
* URL : https://github.com/claudiodangelis/qrcp
* License : MIT
  Programming Lang: Golang
  Description : transfer files by qrcode

Transfer files over Wi-Fi from your computer to a mobile device by
scanning a QR code without leaving the terminal.

qrcp binds a web server to the address of your Wi-Fi network interface
on a random port and creates a handler for it. The default handler
serves the content and exits the program when the transfer is
complete. When used to receive files, qrcp serves an upload page and
handles the transfer.

The tool prints a QR code that encodes the text:

http://{address}:{port}/{random_path}

Most QR apps can detect URLs in decoded text and act accordingly
(i.e. open the decoded URL with the default browser), so when the QR
code is scanned the content will begin downloading by the mobile
browser.

It can send and receive files from other devices.



While there are tools that could be duct-taped together to do this in
Debian, there's no one-stop-shop that actually does like this, pretty
neat.

Bug#1015801: haskell-reactive-banana FTBFS: error: A pragma is not allowed in this position

[Adrian Bunk]

Source: haskell-reactive-banana
Version: 1.2.1.0-2
Severity: serious
Tags: ftbfs bookworm sid

https://buildd.debian.org/status/fetch.php?pkg=haskell-reactive-banana=amd64=1.2.1.0-2%2Bb3=1658412950=0

...
src/Reactive/Banana/Prim/Combinators.hs:29:29: error:
A pragma is not allowed in this position: {-# SCC mapP #-}
   |
29 | p2 <- newPulse "mapP" $ {-# SCC mapP #-} fmap f <$> readPulseP p1
   | ^^^

src/Reactive/Banana/Prim/Combinators.hs:46:36: error:
A pragma is not allowed in this position: {-# SCC filterJustP #-}
   |
46 | p2 <- newPulse "filterJustP" $ {-# SCC filterJustP #-} join <$> 
readPulseP p1
   |

src/Reactive/Banana/Prim/Combinators.hs:53:13: error:
A pragma is not allowed in this position: {-# SCC unsafeMapIOP #-}
   |
53 | {-# SCC unsafeMapIOP #-} eval =<< readPulseP p1
   | ^

src/Reactive/Banana/Prim/Combinators.hs:64:13: error:
A pragma is not allowed in this position: {-# SCC unionWithP #-}
   |
64 | {-# SCC unionWithP #-} eval <$> readPulseP px <*> readPulseP py
   | ^^^

src/Reactive/Banana/Prim/Combinators.hs:79:9: error:
A pragma is not allowed in this position: {-# SCC applyP #-}
   |
79 | {-# SCC applyP #-} fmap <$> readLatchP f <*> readPulseP x
   | ^^^

src/Reactive/Banana/Prim/Combinators.hs:88:27: error:
A pragma is not allowed in this position: {-# SCC mapL #-}
   |
88 | mapL f lx = cachedLatch $ {-# SCC mapL #-} f <$> getValueL lx
   |   ^^

src/Reactive/Banana/Prim/Combinators.hs:92:5: error:
A pragma is not allowed in this position: {-# SCC applyL #-}
   |
92 | {-# SCC applyL #-} getValueL lf <*> getValueL lx
   | ^^^

src/Reactive/Banana/Prim/Combinators.hs:118:37: error:
A pragma is not allowed in this position: {-# SCC executeP #-}
|
118 | p2 <- newPulse "executeP" $ {-# SCC executeP #-} eval =<< 
readPulseP p1
| ^
 at /usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 107.

Debian::Debhelper::Buildsystem::Haskell::Recipes::run_quiet("debian/hlibrary.setup",
 "build", "--builddir=dist-ghc") called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 131

Debian::Debhelper::Buildsystem::Haskell::Recipes::run("debian/hlibrary.setup", 
"build", "--builddir=dist-ghc") called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 642
Debian::Debhelper::Buildsystem::Haskell::Recipes::build_recipe() called 
at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:160: build-ghc-stamp] Error 25

Bug#1015794: behaviour of ?archive pattern inconsistent with aptitude

[Sébastien Villemot]

Le jeudi 21 juillet 2022 à 16:03 +0200, Julian Andres Klode a écrit :
> On Thu, Jul 21, 2022 at 02:36:06PM +0200, Sébastien Villemot wrote:
> > Package: apt
> > Version: 2.5.1
> > Severity: normal
> > 
> > My system has both unstable and experimental suites enabled (see below
> > debian.sources).
> > 
> > When I run:
> > 
> >   aptitude versions '~i~Aexperimental'
> > 
> > I get a list of those installed package versions that effectively come from
> > experimental (8 in total on my system, in particular I use GCC 12 by 
> > default):
> > 
> > Package cpp:   
> > i A 4:12-20211211-1 
> > experimental
> >  100
> > 
> > Package g++:
> > i   4:12-20211211-1 
> > experimental
> >  100
> > 
> > …
> > 
> > However, when I run:
> > 
> >   apt list '~i~Aexperimental'
> > 
> > I get a list of 297 packages. It seems to include all the installed packages
> > for which a more recent version exists in experimental, independently of
> > whether I installed that more recent version or not. For example, the output
> > contains:
> > 
> >  wfrench/unstable,now 1.2.6-1 all [installed,automatic]
> > 
> > wfrench 1.2.6-1 actually comes from unstable, but there is indeed a 1.2.7-1
> > currently in experimental (which I did not install).
> 
> That is correct. What you fail to realize is that apt list lists
> packages, not versions, so it matches like aptitude search, not aptitude
> versions. You'll have to wrap the search in ?any-version if you want
> operations to match against the same version, as in aptitude search.
> 
> The aptitude versions command I believe is the only thing in aptitude that
> actually matches versions and is very confusing. Because in your example, if
> you used `aptitude install` with your pattern, it would have installed those 
> same
> 297 packages that `apt list` lists.

Thanks for your feedback. I had overlooked the fact that `aptitude
versions` behaves in a special way.

However `apt list` does not behave as `aptitude search` either on my
system:

$ apt list '?any-version(~i~Aexperimental)'|wc
2971430   20645
$ aptitude search '?any-version(~i~Aexperimental)'|wc
  8  65 385

Am I still missing something?

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄  https://www.debian.org



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

Bug#1015794: behaviour of ?archive pattern inconsistent with aptitude

[Julian Andres Klode]

Control: clone -1 -2
Control: retitle -2 ?installed only matches package-level

On Thu, Jul 21, 2022 at 04:03:46PM +0200, Julian Andres Klode wrote:
> Control: severity -1 minor
> 
> On Thu, Jul 21, 2022 at 02:36:06PM +0200, Sébastien Villemot wrote:
> > Package: apt
> > Version: 2.5.1
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> > I noticed that the ?archive pattern does not behave the same in apt as in
> > aptitude.
> 
> That is incorrect.
> 
> > 
> > My system has both unstable and experimental suites enabled (see below
> > debian.sources).
> > 
> > When I run:
> > 
> >   aptitude versions '~i~Aexperimental'
> > 
> > I get a list of those installed package versions that effectively come from
> > experimental (8 in total on my system, in particular I use GCC 12 by 
> > default):
> > 
> > Package cpp:   
> > i A 4:12-20211211-1 
> > experimental
> >  100
> > 
> > Package g++:
> > i   4:12-20211211-1 
> > experimental
> >  100
> > 
> > …
> > 
> > However, when I run:
> > 
> >   apt list '~i~Aexperimental'
> > 
> > I get a list of 297 packages. It seems to include all the installed packages
> > for which a more recent version exists in experimental, independently of
> > whether I installed that more recent version or not. For example, the output
> > contains:
> > 
> >  wfrench/unstable,now 1.2.6-1 all [installed,automatic]
> > 
> > wfrench 1.2.6-1 actually comes from unstable, but there is indeed a 1.2.7-1
> > currently in experimental (which I did not install).
> 
> That is correct. What you fail to realize is that apt list lists
> packages, not versions, so it matches like aptitude search, not aptitude
> versions. You'll have to wrap the search in ?any-version if you want
> operations to match against the same version, as in aptitude search.

There actually is one more bug:

jak@jak-t480s:~:master$ aptitude search 
'?any-version(?installed?archive(kinetic)?name(^apt$))'
jak@jak-t480s:~:master$ apt list 
'?any-version(?installed?archive(kinetic)?name(^apt$))'
Listing... Done
apt/impish,now 2.5.1+0~202206301128~ubuntu21.10.1 amd64 [installed]
N: There is 1 additional version. Please use the '-a' switch to see it

It's unclear where aptitude implements ?installed for a version, my
impression was it was only implemented by checking if the installed
flag was set at the package level, hence how I implemented it. Sigh.


-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#1015799: haskell-assoc FTBFS: Encountered missing or private dependencies: base >=4.3 && <4.15

[Adrian Bunk]

Source: haskell-assoc
Version: 1.0.2-2
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=haskell-assoc=amd64=1.0.2-2=1658412394=0

...
hlibrary.setup: Encountered missing or private dependencies:
base >=4.3 && <4.15

 at /usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 107.

Debian::Debhelper::Buildsystem::Haskell::Recipes::run_quiet("debian/hlibrary.setup",
 "configure", "--ghc", "-v2", "--package-db=/var/lib/ghc/package.conf.d", 
"--prefix=/usr", "--libdir=/usr/lib/haskell-packages/ghc/lib", 
"--libexecdir=/usr/lib", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 131

Debian::Debhelper::Buildsystem::Haskell::Recipes::run("debian/hlibrary.setup", 
"configure", "--ghc", "-v2", "--package-db=/var/lib/ghc/package.conf.d", 
"--prefix=/usr", "--libdir=/usr/lib/haskell-packages/ghc/lib", 
"--libexecdir=/usr/lib", ...) called at 
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 622
Debian::Debhelper::Buildsystem::Haskell::Recipes::configure_recipe() 
called at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:155: configure-ghc-stamp] Error 
25

Bug#1015794: behaviour of ?archive pattern inconsistent with aptitude

[Julian Andres Klode]

Control: severity -1 minor

On Thu, Jul 21, 2022 at 02:36:06PM +0200, Sébastien Villemot wrote:
> Package: apt
> Version: 2.5.1
> Severity: normal
> 
> Dear Maintainer,
> 
> I noticed that the ?archive pattern does not behave the same in apt as in
> aptitude.

That is incorrect.

> 
> My system has both unstable and experimental suites enabled (see below
> debian.sources).
> 
> When I run:
> 
>   aptitude versions '~i~Aexperimental'
> 
> I get a list of those installed package versions that effectively come from
> experimental (8 in total on my system, in particular I use GCC 12 by default):
> 
> Package cpp:   
> i A 4:12-20211211-1   
>   experimental
>  100
> 
> Package g++:
> i   4:12-20211211-1   
>   experimental
>  100
> 
> …
> 
> However, when I run:
> 
>   apt list '~i~Aexperimental'
> 
> I get a list of 297 packages. It seems to include all the installed packages
> for which a more recent version exists in experimental, independently of
> whether I installed that more recent version or not. For example, the output
> contains:
> 
>  wfrench/unstable,now 1.2.6-1 all [installed,automatic]
> 
> wfrench 1.2.6-1 actually comes from unstable, but there is indeed a 1.2.7-1
> currently in experimental (which I did not install).

That is correct. What you fail to realize is that apt list lists
packages, not versions, so it matches like aptitude search, not aptitude
versions. You'll have to wrap the search in ?any-version if you want
operations to match against the same version, as in aptitude search.

To give an example on my weird Ubuntu install:

jak@jak-t480s:~:master$ apt policy apt
apt:
  Installed: 2.5.1+0~202206301128~ubuntu21.10.1
  Candidate: 2.5.1+0~202206301128~ubuntu21.10.1
  Version table:
 *** 2.5.1+0~202206301128~ubuntu21.10.1 500
500 http://ppa.launchpad.net/deity/sid/ubuntu impish/main amd64 Packages
100 /var/lib/dpkg/status
 2.5.1 500
500 mirror+file:/etc/apt/mirrors.list kinetic/main amd64 Packages
jak@jak-t480s:~:master$ apt list '?installed?archive(kinetic)?name(^apt$)'
Listing... Done
apt/impish,now 2.5.1+0~202206301128~ubuntu21.10.1 amd64 [installed]
N: There is 1 additional version. Please use the '-a' switch to see it
jak@jak-t480s:~:master$ aptitude search 
'?installed?archive(kinetic)?name(^apt$)'
i   apt 
   - commandline package manager
 
jak@jak-t480s:~:master$ aptitude versions 
'?installed?archive(kinetic)?name(^apt$)'
jak@jak-t480s:~:master$ aptitude search 
'?any-version(?installed?archive(kinetic)?name(^apt$))'
jak@jak-t480s:~:master$ aptitude install 
'?installed?archive(kinetic)?name(^apt$)' -s
apt is already installed at the requested version 
(2.5.1+0~202206301128~ubuntu21.10.1)
apt is already installed at the requested version  
(2.5.1+0~202206301128~ubuntu21.10.1)

The aptitude versions command I believe is the only thing in aptitude that
actually matches versions and is very confusing. Because in your example, if
you used `aptitude install` with your pattern, it would have installed those 
same
297 packages that `apt list` lists.
-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#1015798: RFP: battop -- interactive batteries viewer

[Antoine Beaupre]

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

* Package name: battop
  Version : 0.2.4
  Upstream Author : s...@svartalf.info
* URL : https://github.com/svartalf/rust-battop
* License : Apache-2, MIT
  Programming Lang: Rust
  Description : interactive batteries viewer

battop is an interactive viewer, similar to top, htop and other *top
utilities, but about the batteries installed in your notebook.

I am not aware of a similar tool already in Debian, but I might be
mistaken on that.

Bug#1015785: source only update issue

[Osamu Aoki]

Hi,

You are correct.

Since maint-guide is now deprecated and not actively updated, with next upload 
I only
mention as:

-Debian now requires source-only uploads for normal upload.  So this page is
outdated.
-
-

My updated debmake-doc is maint-guide replavement.  It mentions source-only 
uploads
but intentionally leaves when binary upload is needed.  I think security upload 
is
(was?) another one. Since this is moving target, I redirect reader to
https://wiki.debian.org/SourceOnlyUpload ,
So there is no bug in debmake-doc.

Since you know well, please update "RESTRICTION" section in the wiki page.

Thanks.

Osamu

Bug#1015797: ITP: chibicc -- small C compiler

[Gürkan Myczko]

Package: wnpp
Severity: wishlist
Owner: Gürkan Myczko 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: chibicc
  Version : 0+git20220719+ds
  Upstream Authors: Rui Ueyama
  URL : https://github.com/rui314/chibicc
* License : MIT
  Description : small C compiler
 This is yet another small C compiler that implements most C11 features.
 Even though it still probably falls into the "toy compilers" category 
just

 like other small compilers do, chibicc can compile several real-world
 programs, including Git, SQLite, libpng and chibicc itself, without 
making

 modifications to the compiled programs. Generated executables of these
 programs pass their corresponding test suites. So, chibicc actually 
supports
 a wide variety of C11 features and is able to compile hundreds of 
thousands

 of lines of real-world C code correctly.

Bug#1015786: Retitle #1015786

[Osamu Aoki]

Control: retitle -1 Update recommend and suggests for paste action
thanks

Bug#1015796: bullseye backport

[Andre Heider]

Source: redmine

Can we have a backport for bullseye please?

The wiki claims it'll come at some point [0], and Rails 6 is there, so 
are we there yet? :)


[0] https://wiki.debian.org/Redmine

Thanks!
Andre

Bug#1015781: autopkgtests fail if user foo exists or existed

[Jason Franklin]

On Thu, Jul 21, 2022 at 08:27:15AM +0200, Marc Haber wrote:
> The tests expect the test environment to be fresh.

When I wrote the initial autopkgtests, my thought was that this was the
entire design idea of the system.

Each stanza in the debian/tests/control file results in the
instantiation of a new chroot or container before its named collection
of tests is run.

The tests in each stanza, of course, use the same environment. That was
the reasoning behind saving and restoring /etc/passwd and friends in the
Perl BEGIN and END blocks of each test script. Not perfect, but it
speeds up the tests.

> They relay too much on uids being the same and do not preseed adduser
> to provide reproducible uids.

I can understand that this is a problem.

If new Debian system users or groups are added to the base files, or if
default ID ranges change, we have an issue when specific ID numbers are
relied upon.

This was why my tests mainly picked usernames and not ID numbers.

If Debian ever puts the user "foo" in the base system, we'll need to do
a find and replace to change "foo" to something else. ID numbers will be
harder to change, so they should be avoided or selected dynamically.

> Reproducer:
> - create test chroot
> - adduser --system foo
> - deluser foo
> - verify that foo is actually gone
> - run autopkgtests
> - see not just one test failing.

This seems like it shouldn't fail. However, there are probably side
effects here that the tests handle that aren't handled by doing this
interactively first.

In principle, I think that picking a set of canonical usernames to work
with in tests should be fine. Picking fixed ID numbers is probably not
fine.

-- 
Jason Franklin

Bug#1015794: behaviour of ?archive pattern inconsistent with aptitude

[Sébastien Villemot]

Package: apt
Version: 2.5.1
Severity: normal

Dear Maintainer,

I noticed that the ?archive pattern does not behave the same in apt as in
aptitude.

My system has both unstable and experimental suites enabled (see below
debian.sources).

When I run:

  aptitude versions '~i~Aexperimental'

I get a list of those installed package versions that effectively come from
experimental (8 in total on my system, in particular I use GCC 12 by default):

Package cpp:   
i A 4:12-20211211-1 
experimental
 100

Package g++:
i   4:12-20211211-1 
experimental
 100

…

However, when I run:

  apt list '~i~Aexperimental'

I get a list of 297 packages. It seems to include all the installed packages
for which a more recent version exists in experimental, independently of
whether I installed that more recent version or not. For example, the output
contains:

 wfrench/unstable,now 1.2.6-1 all [installed,automatic]

wfrench 1.2.6-1 actually comes from unstable, but there is indeed a 1.2.7-1
currently in experimental (which I did not install).

This behaviour seems to contradict the documentation, so I guess it is not
intended (or the documentation should probably be clarified otherwise, and this
be added to the incompatibilites with aptitude).

Thanks for your work,

Sébastien Villemot



-- Package-specific info:

-- (no /etc/apt/preferences present) --


-- (no /etc/apt/preferences.d/* present) --


-- (no /etc/apt/sources.list present) --


-- /etc/apt/sources.list.d/debian.sources --

Types: deb deb-src
URIs: http://deb.debian.org/debian
Suites: unstable experimental
Components: main contrib non-free
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

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

Kernel: Linux 5.18.0-2-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (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 apt depends on:
ii  adduser 3.122
ii  debian-archive-keyring  2021.1.1
ii  gpgv2.2.35-3
ii  libapt-pkg6.0   2.5.1
ii  libc6   2.33-8
ii  libgcc-s1   12.1.0-7
ii  libgnutls30 3.7.6-2
ii  libseccomp2 2.5.4-1
ii  libstdc++6  12.1.0-7
ii  libsystemd0 251.3-1

Versions of packages apt recommends:
ii  ca-certificates  20211016

Versions of packages apt suggests:
ii  apt-doc 2.5.1
ii  aptitude0.8.13-4
ii  dpkg-dev1.21.9
ii  gnupg   2.2.35-3
ii  gnupg2  2.2.35-3
ii  powermgmt-base  1.36
ii  synaptic0.91.2

-- no debconf information

Bug#1015793: RFS: opendkim/2.11.0~beta2-7 -- DomainKeys Identified Mail (DKIM) signing and verifying milter

[David Bürgin]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: opendkim
   Version : 2.11.0~beta2-7
   Upstream Author : The Trusted Domain Project
 * URL : http://www.opendkim.org/
 * License : GPL-3+ with AutoConf exception, ISC, BSD-3-clause and SOSL
 * Vcs : https://salsa.debian.org/debian/opendkim
   Section : mail

The source builds the following binary packages:

  opendkim - DomainKeys Identified Mail (DKIM) signing and verifying milter
  opendkim-tools - utilities for administering the OpenDKIM milter
  libopendkim11 - DomainKeys Identified Mail (DKIM) library
  libopendkim-dev - DomainKeys Identified Mail (DKIM) library (development 
files)
  libvbr2 - Vouch By Reference (VBR) library
  libvbr-dev - Vouch By Reference (VBR) library (development files)
  librbl1 - Real-time Blacklist (RBL) query library
  librbl-dev - Real-time Blacklist (RBL) query library (development files)
  miltertest - utility for testing milter applications

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/o/opendkim/opendkim_2.11.0~beta2-7.dsc

Changes since the last upload:

 opendkim (2.11.0~beta2-7) unstable; urgency=medium
 .
   * systemd: Start service after network is online (Closes: #1004394).
   * Bump Standards-Version to 4.6.1 without further changes.

Cheers,
David

Bug#856271: xfonts-*: missing required debian/rules targets build-arch and/or build-indep

[Simon McVittie]

Control: tags -1 + patch

I've prepared merge requests for all the xfonts-* packages (except
xfonts-utils which contains utilities rather than fonts) fixing the
missing targets required by Policy §4.9:

https://salsa.debian.org/xorg-team/font/xfonts-100dpi/-/merge_requests/1
https://salsa.debian.org/xorg-team/font/xfonts-75dpi/-/merge_requests/1
https://salsa.debian.org/xorg-team/font/xfonts-base/-/merge_requests/1
https://salsa.debian.org/xorg-team/font/xfonts-cyrillic/-/merge_requests/1
https://salsa.debian.org/xorg-team/font/xfonts-encodings/-/merge_requests/1
https://salsa.debian.org/xorg-team/font/xfonts-scalable/-/merge_requests/1

Adding the new targets does not affect the contents of any built .deb.

I took the opportunity to fix the Vcs-Git, Vcs-Browser fields where
necessary, and add Rules-Requires-Root: no to avoid needing fakeroot
(I checked that this does not affect the contents of any of these .debs).

For -base, -cyrillic, -75dpi and -100dpi I also fixed FTBFS on newer
architectures such as arm64 by using dh_update_autotools_config to update
config.guess and config.sub (-base: #856271, -cyrillic: no bug reported,
-75dpi: #976471, -100dpi: #976571). Again, this does not affect the
contents of any built .deb. I didn't base this on Andrew Shadura's patch
from #856271, because that patch did the update manually and didn't handle
the clean step, whereas this version uses dh_update_autotools_config
which seems generally nicer (and in particular, dh_clean automatically
reverses it).

For -encodings and -scalable, the package's debhelper compat level 5
is no longer supported and the package FTBFS in unstable, so I had to
fix that first (#965901, #965894). Instead of doing a minimal bump to
deprecated version 7, I went directly to the recommended compat level
13 (available since stable and oldstable-backports). I verified with
diffoscope that the only effect this has on the contents of the .deb is
to add the upstream ChangeLog as changelog.gz, which seems harmless.

These packages would probably all benefit from moving to short-form dh,
but I haven't done that here, because that's a matter of style/opinion
which should be left to the maintainer.

Thanks,
smcv

Bug#1015762: roundcube-core: Cannot be installed without pulling apache

[Guilhem Moulin]

On Thu, 21 Jul 2022 at 07:10:27 -0400, Philippe Clérié wrote:
> I would like to test that.

Well you can build the package from git and try to install the .deb :-)

FWIW the aforementioned patch also removes ‘Depends: php’ from the
‘lighttpd’ and ‘hardening-dedicated-user’ DEP-8 tests, and neither pulls
in apache2.  You can see it for yourself in the CI pipeline logs:
https://salsa.debian.org/roundcube-team/roundcube/-/jobs/3020894#L1201
https://salsa.debian.org/roundcube-team/roundcube/-/jobs/3020894#L1710

> On the other hand, if php-fpm is moved from the recommends into the
> depends, problem solved: php | php-fpm

‘php-cgi’ is also a viable alternative.  But enumerating PHP interpreters
isn't the job of the Roundcube package.  That's why the ‘php’ package
exists in the first place: it doesn't install anything meaningful and
only serves as a mean to specify package dependencies.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1014065: Working on Ubuntu 21.10 (Impish) OEM kernel

[Daniel Barta]

Resume from sleep is working fine on Ubuntu 21.10 Live with kernel 
5.13.0-19-generic 
(https://packages.ubuntu.com/impish/kernel/linux-image-5.13.0-19-generic).

Bug#1015781: autopkgtests fail if user foo exists or existed

[Matt Barry]

On Thu, 2022-07-21 at 08:27 +0200, Marc Haber wrote:
> Package: adduser
> Version: 3.122
> Severity: normal
> 
> The tests expect the test environment to be fresh. They relay too
> much
> on uids being the same and do not preseed adduser to provide
> reproducible uids.
> 
> Reproducer:
> - create test chroot
> - adduser --system foo
> - deluser foo
> - verify that foo is actually gone
> - run autopkgtests
> - see not just one test failing.

I have seen similar cases where running 'autopkgtest -- null' more than
inside a debspawn session fails; it ought to be idempotent.

mb

Bug#879665: ITP: node-prettier -- Prettier is an opinionated code formatter

[Yadd]

Hi,

I'm able to reproduce upstream build but this needs the following 
missing modules:


@angular/compiler
angular-estree-parser
angular-html-parser
bail
browserslist-to-esbuild
ccount
character-entities
character-entities-legacy
character-reference-invalid
cjk-regex
collapse-white-space
commenting
dashify
editorconfig-to-prettier
@esbuild-plugins/node-modules-polyfill
esbuild-visualizer
esm-utils
find-parent-dir
flatten
flow-parser
@glimmer/env
@glimmer/syntax
@glimmer/util
@handlebars/parser
html-styles
@iarna/toml
is-alphabetical
is-alphanumerical
is-decimal
is-hexadecimal
is-whitespace-character
is-word-character
linguist-languages
markdown-escapes
meriyah
n-readlines
outdent
package-name-regex
parse-entities
please-upgrade-node
postcss-less
postcss-media-query-parser
postcss-scss
postcss-values-parser
regenerate
regexp-util
remark-footnotes
remark-math
remark-parse
rollup-plugin-license
sdbm
semver-compare
simple-html-tokenizer
spdx-compare
spdx-expression-validate
spdx-ranges
spdx-satisfies
state-toggle
trim
trim-trailing-lines
trough
tsutils
@typescript-eslint/types
@typescript-eslint/typescript-estree
@typescript-eslint/visitor-keys
unherit
unicode-regex
unified
unist-util-is
unist-util-remove-position
unist-util-stringify-position
unist-util-visit
unist-util-visit-parents
url-or-path
vfile
vfile-location
vfile-message
vnopts
yaml-unist-parser

Bug#1015762: roundcube-core: Cannot be installed without pulling apache

[Philippe Clérié]

I would like to test that.

Meanwhile, assume we have already installed nginx and php-fpm. With the
current version:

$ apt install roundcube-core

will pull in libapache2-mod-php. We know that adding php suppresses that,
and I find that quite surprising.

Your change removes libapache2-mod-php, but there is still that php depend
that will pull it in. I think that adding php would still be necessary if
the above behavior is constant.

On the other hand, if php-fpm is moved from the recommends into the
depends, problem solved: php | php-fpm

Best regards,
Philippe


The trouble with common sense is that it is so uncommon.



On Wed, Jul 20, 2022 at 9:52 PM Guilhem Moulin  wrote:

> On Wed, 20 Jul 2022 at 15:57:08 -0400, Philippe Clérié wrote:
> > Ok. That looks like it works.
> >
> > It simply would never have occurred to me to add php to php-fpm.
>
> Fair enough, it's arguably an issue in APT's dependency resolver:
>
> $ apt show roundcube-core
> […]
> Depends: […], libapache2-mod-php | php, […]
> Recommends: apache2 | lighttpd | spawn-fcgi | php-fpm | httpd-cgi, […]
> […]
>
> $ apt show php
> […]
> Depends: php7.4
> […]
>
> $ apt show php7.4
> […]
> Depends: libapache2-mod-php7.4 | php7.4-fpm | php7.4-cgi, php7.4-common
> […]
>
> $ apt show php-fpm
> […]
> Depends: php7.4-fpm
> […]
>
> so in principle `apt install php-fpm roundcube-core` should be enough
> not to pull apache2, but it needs the ‘php’ hint apparently.  I just
> removed the redundant ‘libapache2-mod-php |’ in
>
> https://salsa.debian.org/roundcube-team/roundcube/-/commit/c1853219642ce3b29b5f4e74ef273538d1188b4a
> which seems to be help too.
>
> --
> Guilhem.
>

Bug#846050: libvirt-daemon-system: Cannot create VM - cannot load AppArmor profile

[Domenico Andreoli]

Hi,

  Today I solved a similar issue on my machine, or at least something
that was manifesting with the same error message.

The original problem is that my VM was referring to a file missing from
disk, the XML definition was valid but the VM was not.

This made some libvirtd child process die and, for reasons I ignore,
failed the AppArmor profile validation.

This is from syslog:

Jul 21 12:36:55 r9 libvirtd[1129]: internal error: Child process 
(LIBVIRT_LOG_OUTPUTS=3:stderr /usr/lib/libvirt/virt-aa-helper -c -u 
libvirt-ae75c26b-557a-4772-afe0-f820cfcdf410) unexpected exit status 1: 
virt-aa-helper: warning: path does not exist, skipping file type 
checks#012virt-aa-helper: error: 
/usr/share/AAVMF/AAVMF_VARS.fd#012virt-aa-helper: error: skipped restricted 
file#012virt-aa-helper: error: invalid VM definition
Jul 21 12:36:55 r9 libvirtd[1129]: internal error: cannot load AppArmor profile 
'libvirt-ae75c26b-557a-4772-afe0-f820cfcdf410'


Therefore if you get this "cannot load AppArmor profile" error, look
for the actual error in /var/log/syslog.

I also suggest to close this bug, it's of the kind catch-all and cannot
be solved in any way.

Dom

-- 
rsa4096: 3B10 0CA1 8674 ACBA B4FE  FCD2 CE5B CF17 9960 DE13
ed25519: FFB4 0CC3 7F2E 091D F7DA  356E CC79 2832 ED38 CB05


signature.asc
Description: PGP signature

Bug#1015784: source-only upload requirement not documented

[Holger Levsen]

control: tags -1 wishlist
thanks

On Thu, Jul 21, 2022 at 10:44:26AM +0200, Marc Haber wrote:
> for a few years now, the Debian archive wants to see source-only
> uploads. This is not documented in the Developer's Reference and also
> now in the New Maintainer's Guide. It should be there.

I agree & thanks for filing this bug report. Downgrading to wishlist,
as devref is not *wrong*, just missing information.

Not tagging 'help' because then I could tag all devref bugs with it.
(maybe I should??)

Help *is* much welcome, either via a patch or directly commiting
to the master branch in git, which anyone in the Debian group on
salsa can do.

(and for those who havent noticed: devref is now developed in plain
markdown, so no more xml...)

> Also, it should be documented that the first upload of a new package to
> debian MUST be a source+binary upload. Arch all packages need another
> source-only upload after being accepted into the archive to be allowed
> to migrate to testing. I THINK that arch any packages get an automatic
> binNMU to avoid that.

I *believe* the latter is due to release team people being nice and proactive,
so it's not fully automatic.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

The past is over.


signature.asc
Description: PGP signature

Bug#1015791: libreoffice: first start after boot takes more then 20 seconds, every following starts are much faster (< 2 seconds)

[Reiner Stallknecht]

Package: libreoffice-common
Version: 1:7.3.5~rc2-1
Severity: normal
X-Debbugs-Cc: stal...@t-online.de

Every time libreoffice (or the specific programs like libreoffice-calc,
libreoffice-writer etc.) starts for the very first time after a newly booted
pc,
it takes a long time until it is ready (> 20 seconds)

All following starts are much faster (< 2 seconds)

at the very end of the strace(first start), it takes most of the time before
libreoffice will start:
futex(0x5644f27beec8, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0,
{tv_sec=1658400717, tv_nsec=585408000}, FUTEX_BITSET_MATCH_ANY) = 0

then i closed libreoffice and restarted again (see second strace)

suspect is the message in the first strace:
futex(0x5644f27bf1a0, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, NULL,
FUTEX_BITSET_MATCH_ANY) = -1 EAGAIN (Die Ressource ist zur Zeit nicht
verfügbar)

I have tried with other users and fresh user profiles with no success.
Also if one user starts for the first time, and another user starts for the
second time
the startup is also < 2 seconds.


Below are strace output of the first start:

reiner@nathan:~$ strace libreoffice
execve("/usr/bin/libreoffice", ["libreoffice"], 0x7fff0b0fdb80 /* 45 vars */) =
0
brk(NULL)   = 0x55edd971b000
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (Datei oder Verzeichnis
nicht gefunden)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=153811, ...}, AT_EMPTY_PATH) =
0
mmap(NULL, 153811, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f1a8d9fd000
close(3)= 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`9\2\0\0\0\0\0"..., 832)
= 832
pread64(3, "\6\0\0\0\4\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0"...,
784, 64) = 784
pread64(3,
"\4\0\0\0\20\0\0\0\5\0\0\0GNU\0\2\200\0\300\4\0\0\0\1\0\0\0\0\0\0\0", 32, 848)
= 32
pread64(3,
"\4\0\0\0\24\0\0\0\3\0\0\0GNU\0\27\n\3\204\346\353\257Q\2\31\305\316\347\315F\250"...,
68, 880) = 68
newfstatat(3, "", {st_mode=S_IFREG|0755, st_size=1900960, ...}, AT_EMPTY_PATH)
= 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f1a8d9fb000
pread64(3, "\6\0\0\0\4\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0"...,
784, 64) = 784
mmap(NULL, 1934632, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x7f1a8d822000
mmap(0x7f1a8d844000, 1409024, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x22000) = 0x7f1a8d844000
mmap(0x7f1a8d99c000, 327680, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3,
0x17a000) = 0x7f1a8d99c000
mmap(0x7f1a8d9ec000, 24576, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1c9000) = 0x7f1a8d9ec000
mmap(0x7f1a8d9f2000, 34088, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f1a8d9f2000
close(3)= 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f1a8d82
arch_prctl(ARCH_SET_FS, 0x7f1a8d9fc600) = 0
mprotect(0x7f1a8d9ec000, 16384, PROT_READ) = 0
mprotect(0x55edd814, 8192, PROT_READ) = 0
mprotect(0x7f1a8da52000, 8192, PROT_READ) = 0
munmap(0x7f1a8d9fd000, 153811)  = 0
getuid()= 1000
getgid()= 1000
getpid()= 1867
rt_sigaction(SIGCHLD, {sa_handler=0x55edd8135ca0, sa_mask=~[RTMIN RT_1],
sa_flags=SA_RESTORER, sa_restorer=0x7f1a8d85a940}, NULL, 8) = 0
geteuid()   = 1000
brk(NULL)   = 0x55edd971b000
brk(0x55edd973c000) = 0x55edd973c000
getppid()   = 1864
newfstatat(AT_FDCWD, "/home/reiner", {st_mode=S_IFDIR|0755, st_size=7168, ...},
0) = 0
newfstatat(AT_FDCWD, ".", {st_mode=S_IFDIR|0755, st_size=7168, ...}, 0) = 0
openat(AT_FDCWD, "/usr/bin/libreoffice", O_RDONLY) = 3
fcntl(3, F_DUPFD, 10)   = 10
close(3)= 0
fcntl(10, F_SETFD, FD_CLOEXEC)  = 0
geteuid()   = 1000
getegid()   = 1000
rt_sigaction(SIGINT, NULL, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
rt_sigaction(SIGINT, {sa_handler=0x55edd8135ca0, sa_mask=~[RTMIN RT_1],
sa_flags=SA_RESTORER, sa_restorer=0x7f1a8d85a940}, NULL, 8) = 0
rt_sigaction(SIGQUIT, NULL, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) =
0
rt_sigaction(SIGQUIT, {sa_handler=SIG_DFL, sa_mask=~[RTMIN RT_1],
sa_flags=SA_RESTORER, sa_restorer=0x7f1a8d85a940}, NULL, 8) = 0
rt_sigaction(SIGTERM, NULL, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) =
0
rt_sigaction(SIGTERM, {sa_handler=SIG_DFL, sa_mask=~[RTMIN RT_1],
sa_flags=SA_RESTORER, sa_restorer=0x7f1a8d85a940}, NULL, 8) = 0
read(10, "#!/bin/sh\n#\n# This file is part "..., 8192) = 6731
pipe([3, 4])= 0
clone(child_stack=NULL, 

Bug#1007984: netpbm-free_10.98.00-1_amd64.changes REJECTED

[Andreas Tille]

Hi Thorsten,

Am Sat, May 28, 2022 at 07:00:08PM + schrieb Thorsten Alteholz:
> 
> please also mention Todd W. Fuqua and  Michael John Muuss in your 
> debian/copyright.

Added these two to d/copyright in a fresh upload.
 
> I stop processing when something is wrong/missing. Please make sure that your 
> debian/copyright is complete in order to avoid further REJECTs.

Please note: I've spent way more hours than intended on this package
which is somehow orphaned by its maintainers and also several hours to
enhance the d/copyright which is way better than what we had before I
started touching the package.  The package is obviously Free Software
and we are permitted to distribute it by the licenses.

The amount of time I volunteer to spent on this package is reached now.
In case the package will be rejected again I will stop trying to fix bug
#1007984 and revert the according change which will simply hide further
issues from ftpmaster view and does not make Debian better for its users
- but than it becomes other peoples problem.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#1006888: ITP: sasl-xoauth2 -- XOAUTH2 plugin for libsasl2

[Fabio Fantoni]

Hi, is there any news on this?

I saw the repository on salsa ( 
https://salsa.debian.org/debian/sasl-xoauth2 ) and from d/changelog 
seems marked as released on unstable (anb not UNRELEASED) in april but I 
don't see it and I don't see also in NEW queue ( 
https://ftp-master.debian.org/new.html ).


I suppose was not uploaded and Daniel Kahn Gillmor still waiting replies 
about the approch want to do related to postfix and ca-certificate, is 
right?


Thanks for any reply



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1015790: wavpack: CVE-2022-2476

[Moritz Mühlenhoff]

Source: wavpack
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for wavpack.

CVE-2022-2476[0]:
| A null pointer dereference bug was found in wavpack-5.4.0 The results
| from the ASAN log: AddressSanitizer:DEADLYSIGNAL =
| ==84257==ERROR:
| AddressSanitizer: SEGV on unknown address 0x (pc
| 0x561b47a970c6 bp 0x7fff13952fb0 sp 0x7fff1394fca0 T0) ==84257==The
| signal is caused by a WRITE memory access. ==84257==Hint: address
| points to the zero page. #0 0x561b47a970c5 in main cli/wvunpack.c:834
| #1 0x7efc4f5c0082 in __libc_start_main (/lib/x86_64-linux-
| gnu/libc.so.6+0x24082) #2 0x561b47a945ed in _start
| (/usr/local/bin/wvunpack+0xa5ed) AddressSanitizer can not provide
| additional info. SUMMARY: AddressSanitizer: SEGV cli/wvunpack.c:834 in
| main ==84257==ABORTING

https://github.com/dbry/WavPack/issues/121  
https://github.com/dbry/WavPack/commit/25b4a2725d8568212e7cf89ca05ca29d128af7ac

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-2022-2476
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-2476

Please adjust the affected versions in the BTS as needed.

Bug#1015789: mysql-8.0: CVE-2022-21569 CVE-2022-21556 CVE-2022-21553 CVE-2022-21550 CVE-2022-21547 CVE-2022-21539 CVE-2022-21538 CVE-2022-21537 CVE-2022-21535 CVE-2022-21534 CVE-2022-21531 CVE-2022-21

[Moritz Mühlenhoff]

Source: mysql-8.0
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerabilities were published for mysql-8.0.

All fixed in latest CPU:

CVE-2022-21569[0]:
| Vulnerability in the MySQL Server product of Oracle MySQL (component:
| Server: Optimizer). Supported versions that are affected are 8.0.29
| and prior. Easily exploitable vulnerability allows low privileged
| attacker with network access via multiple protocols to compromise
| MySQL Server. Successful attacks of this vulnerability can result in
| unauthorized ability to cause a hang or frequently repeatable crash
| (complete DOS) of MySQL Server. CVSS 3.1 Base Score 6.5 (Availability
| impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).

CVE-2022-21556[1]:
| Vulnerability in the MySQL Server product of Oracle MySQL (component:
| Server: Optimizer). Supported versions that are affected are 8.0.28
| and prior. Easily exploitable vulnerability allows high privileged
| attacker with network access via multiple protocols to compromise
| MySQL Server. Successful attacks of this vulnerability can result in
| unauthorized creation, deletion or modification access to critical
| data or all MySQL Server accessible data and unauthorized ability to
| cause a hang or frequently repeatable crash (complete DOS) of MySQL
| Server. CVSS 3.1 Base Score 6.5 (Integrity and Availability impacts).
| CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:H).

CVE-2022-21553[2]:
| Vulnerability in the MySQL Server product of Oracle MySQL (component:
| Server: Optimizer). Supported versions that are affected are 8.0.29
| and prior. Easily exploitable vulnerability allows high privileged
| attacker with network access via multiple protocols to compromise
| MySQL Server. Successful attacks of this vulnerability can result in
| unauthorized ability to cause a hang or frequently repeatable crash
| (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability
| impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).

CVE-2022-21550[3]:
| Vulnerability in the MySQL Cluster product of Oracle MySQL (component:
| Cluster: General). Supported versions that are affected are 7.4.36 and
| prior, 7.5.26 and prior, 7.6.22 and prior and and 8.0.29 and prior.
| Difficult to exploit vulnerability allows high privileged attacker
| with access to the physical communication segment attached to the
| hardware where the MySQL Cluster executes to compromise MySQL Cluster.
| Successful attacks require human interaction from a person other than
| the attacker. Successful attacks of this vulnerability can result in
| takeover of MySQL Cluster. CVSS 3.1 Base Score 6.3 (Confidentiality,
| Integrity and Availability impacts). CVSS Vector:
| (CVSS:3.1/AV:A/AC:H/PR:H/UI:R/S:U/C:H/I:H/A:H).

CVE-2022-21547[4]:
| Vulnerability in the MySQL Server product of Oracle MySQL (component:
| Server: Federated). Supported versions that are affected are 8.0.29
| and prior. Easily exploitable vulnerability allows high privileged
| attacker with network access via multiple protocols to compromise
| MySQL Server. Successful attacks of this vulnerability can result in
| unauthorized ability to cause a hang or frequently repeatable crash
| (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability
| impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).

CVE-2022-21539[5]:
| Vulnerability in the MySQL Server product of Oracle MySQL (component:
| InnoDB). Supported versions that are affected are 8.0.29 and prior.
| Difficult to exploit vulnerability allows low privileged attacker with
| network access via multiple protocols to compromise MySQL Server.
| Successful attacks of this vulnerability can result in unauthorized
| update, insert or delete access to some of MySQL Server accessible
| data as well as unauthorized read access to a subset of MySQL Server
| accessible data and unauthorized ability to cause a partial denial of
| service (partial DOS) of MySQL Server. CVSS 3.1 Base Score 5.0
| (Confidentiality, Integrity and Availability impacts). CVSS Vector:
| (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L).

CVE-2022-21538[6]:
| Vulnerability in the MySQL Server product of Oracle MySQL (component:
| Server: Security: Encryption). Supported versions that are affected
| are 8.0.29 and prior. Difficult to exploit vulnerability allows low
| privileged attacker with network access via multiple protocols to
| compromise MySQL Server. Successful attacks of this vulnerability can
| result in unauthorized ability to cause a partial denial of service
| (partial DOS) of MySQL Server. CVSS 3.1 Base Score 3.1 (Availability
| impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L).

CVE-2022-21537[7]:
| Vulnerability in the MySQL Server product of Oracle MySQL (component:
| InnoDB). Supported versions that are affected are 8.0.29 and prior.
| Easily exploitable vulnerability allows high privileged attacker 

Bug#1015788: gpac: CVE-2022-2453 CVE-2022-2454

[Moritz Mühlenhoff]

Source: gpac
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerabilities were published for gpac.

CVE-2022-2453[0]:
| Use After Free in GitHub repository gpac/gpac prior to 2.1-DEV.

https://huntr.dev/bounties/c8c964de-046a-41b2-9ff5-e25cfdb36b5a
https://github.com/gpac/gpac/commit/dc7de8d3d604426c7a6e628d90cb9fb88e7b4c2c

CVE-2022-2454[1]:
| Integer Overflow or Wraparound in GitHub repository gpac/gpac prior to
| 2.1-DEV.

https://huntr.dev/bounties/105d40d0-46d7-461e-9f8e-20c4cdea925f
https://github.com/gpac/gpac/commit/faa75edde3dfeba1e2cf6ffa48e45a50f1042096

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-2453
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-2453
[1] https://security-tracker.debian.org/tracker/CVE-2022-2454
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-2454

Please adjust the affected versions in the BTS as needed.

Bug#1015787: zycore-c: please add support for riscv64

[Bo YU]

Source: zycore-c
Version: 1.1.0-4
Severity: wishlist
Tags: patch
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: debian-ri...@lists.debian.org

Dear zycore-c Maintainer,

The zycore-c package can be built on real riscv64 hardware with the 
patch attached, could you please add supoort for riscv64 arch?
thanks.

Bo
-- 
Best Regards
diff -Nru zycore-c-1.1.0/debian/control zycore-c-1.1.0/debian/control
--- zycore-c-1.1.0/debian/control	2021-12-07 10:45:44.0 +
+++ zycore-c-1.1.0/debian/control	2021-12-07 11:43:25.0 +
@@ -12,7 +12,7 @@
 Rules-Requires-Root: no
 
 Package: libzycore1.1
-Architecture: any-amd64 any-arm any-arm64 any-i386
+Architecture: any-amd64 any-arm any-arm64 any-i386 riscv64
 Depends: ${misc:Depends},
  ${shlibs:Depends}
 Description: Zyan Core Library for C
@@ -23,7 +23,7 @@
 
 Package: libzycore-dev
 Section: libdevel
-Architecture: any-amd64 any-arm any-arm64 any-i386
+Architecture: any-amd64 any-arm any-arm64 any-i386 riscv64
 Depends: libzycore1.1 (= ${binary:Version}),
  ${misc:Depends}
 Description: Zyan Core Library for C - development
diff -Nru zycore-c-1.1.0/debian/patches/add-support-riscv64.patch zycore-c-1.1.0/debian/patches/add-support-riscv64.patch
--- zycore-c-1.1.0/debian/patches/add-support-riscv64.patch	1970-01-01 00:00:00.0 +
+++ zycore-c-1.1.0/debian/patches/add-support-riscv64.patch	2021-12-07 11:43:25.0 +
@@ -0,0 +1,31 @@
+--- a/include/Zycore/Defines.h
 b/include/Zycore/Defines.h
+@@ -131,6 +131,8 @@
+ #   define ZYAN_AARCH64
+ #elif defined(_M_ARM) || defined(_M_ARMT) || defined(__arm__) || defined(__thumb__)
+ #   define ZYAN_ARM
++#elif defined(_M_RISCV64) || defined(__riscv) && __riscv_xlen == 64
++#   define ZYAN_RISCV64
+ #elif defined(__EMSCRIPTEN__)
+ // Nothing to do, `ZYAN_EMSCRIPTEN` is both platform and arch macro for this one.
+ #else
+--- a/src/Format.c
 b/src/Format.c
+@@ -423,7 +423,7 @@
+ 
+ ZyanStatus ZyanStringAppendDecU(ZyanString* string, ZyanU64 value, ZyanU8 padding_length)
+ {
+-#if defined(ZYAN_X64) || defined(ZYAN_AARCH64)
++#if defined(ZYAN_X64) || defined(ZYAN_AARCH64) || defined(ZYAN_RISCV64)
+ return ZyanStringAppendDecU64(string, value, padding_length);
+ #else
+ // Working with 64-bit values is slow on non 64-bit systems
+@@ -464,7 +464,7 @@
+ ZyanStatus ZyanStringAppendHexU(ZyanString* string, ZyanU64 value, ZyanU8 padding_length,
+ ZyanBool uppercase)
+ {
+-#if defined(ZYAN_X64) || defined(ZYAN_AARCH64)
++#if defined(ZYAN_X64) || defined(ZYAN_AARCH64) || defined(ZYAN_RISCV64)
+ return ZyanStringAppendHexU64(string, value, padding_length, uppercase);
+ #else
+ // Working with 64-bit values is slow on non 64-bit systems
diff -Nru zycore-c-1.1.0/debian/patches/series zycore-c-1.1.0/debian/patches/series
--- zycore-c-1.1.0/debian/patches/series	2021-11-12 12:15:38.0 +
+++ zycore-c-1.1.0/debian/patches/series	2021-12-07 11:43:25.0 +
@@ -1,2 +1,3 @@
 test-make-tests-runnable-with-ctest.patch
 build-use-system-GTest-when-available.patch
+add-support-riscv64.patch


signature.asc
Description: PGP signature

Bug#1015786: rc

[Osamu Aoki]

Package: neovim
Version: 0.7.2-3
Severity: wishlist

neovim support modern pasting now.

In light of this updating dependency further with following packages may
be good idea.

* "wl-clipboard" (this is even higher priority than "xclip")
* "tmux"

Details:

Currently, neovim recommends:
  --\ Recommends (3)
--- python3-pynvim
--- xclip | xsel
--- xxd
  --\ Suggests (2)
--- ctags
--- vim-scripts

On the other hand, `:h clipboard-tool`  lists

  - g:clipboard
  - pbcopy, pbpaste (macOS)
  - wl-copy, wl-paste (if $WAYLAND_DISPLAY is set)
  - xclip (if $DISPLAY is set)
  - xsel (if $DISPLAY is set)
  - lemonade (for SSH) https://github.com/pocke/lemonade
  - doitclient (for SSH) http://www.chiark.greenend.org.uk/~sgtatham/doit/
  - win32yank (Windows)
  - termux (via termux-clipboard-set, termux-clipboard-set)
  - tmux (if $TMUX is set)

If I am not mistaken, it seems natural to add "wl-clipboard" as another
recommends entry

Also, it only lists "tmux" and no "screen".  If this is due to lack of
paste support by "screen", including "tmux" in recommends or suggests
may be a good idea.

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

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

Versions of packages neovim depends on:
ii  libc62.33-8
ii  libluajit-5.1-2  2.1.0~beta3+git20220320+dfsg-4
ii  libmsgpackc2 3.3.0-4
ii  libtermkey1  0.22-1
ii  libtree-sitter0  0.20.6-1
ii  libunibilium42.1.0-1
ii  libuv1   1.44.1-2
ii  libvterm00.1.4-1
ii  lua-luv  1.43.0-0-2
ii  neovim-runtime   0.7.2-3

Versions of packages neovim recommends:
ii  python3-pynvim  0.4.2-2
ii  xclip   0.13-2
ii  xxd 2:8.2.4793-1

Versions of packages neovim suggests:
ii  exuberant-ctags [ctags]  1:5.9~svn20110310-16
ii  vim-scripts  20210124.2

-- no debconf information

Bug#1000660: TKIVtk library missing

[Yuri D'Elia]

On Sat, Jul 16, 2022 at 11:39:55AM +0200, Tobias Frost wrote:

On Fri, 26 Nov 2021 16:15:32 +0100 Yuri D'Elia 
wrote:

libocct-visualization is supposed to include TKIVtk, but in reality

it doesnt.

Can you describe your use case a bit?

Otherwise, this is on purpose. See #978017 for rationale.


I didn't get any message from the BTS, so I only saw this by pure chance
now.

Anyway, I was trying to compile OCP from cadquery, which does require
TKIVtk. I was able to exclude this part from by modifying the sources
and get along, so you can say I was partially successful, but if a
regular user was supposed to build the package it would have just
failed.

I agree with #978017 and I'm quite happy about the solution for the
dependent packages (also using kicad myself, so the space savings are
quite welcome), but this solution breaks part of OCCT. If I would have
needed to have it then I would also have to build OCCT from sources,
which is.. more than annoying.


I'm not sure if Kurt has thought of an solution yet and also did not
look into it if it is e.g feasible to put it into its own package.


Splitting this into a separate package would make a lot of sense IMHO.
Looks like both headers and libraries are separate, so it should be
technically possible?

Bug#1015784: source-only upload requirement not documented

[Marc Haber]

Package: developers-reference
Version: 12.5
Severity: normal

Hi,

for a few years now, the Debian archive wants to see source-only
uploads. This is not documented in the Developer's Reference and also
now in the New Maintainer's Guide. It should be there.

Also, it should be documented that the first upload of a new package to
debian MUST be a source+binary upload. Arch all packages need another
source-only upload after being accepted into the archive to be allowed
to migrate to testing. I THINK that arch any packages get an automatic
binNMU to avoid that.

Greetings
Marc

Bug#1014745: Bug seems fixed in 102.0.3 (SMIME was activated for me)

[Eric Valette]

As I had SMIME configured on that specific account, I assume from 
changelog it could be fixed.


--eric

Bug#991478: shim-signed in buster fails to boot on Oracle Cloud arm64 with fatal crash in TianoCore

[Simon McVittie]

Control: retitle -1 shim-signed in buster fails to boot on Oracle Cloud arm64 
with fatal crash in TianoCore
Control: found -1 1.36~1+deb10u1
Control: found -1 1.36~1+deb10u1+15.4-5~deb10u1
Control: notfound -1 1.33
Control: notfound -1 1.33+15+1533136590.3beb971-7
Control: tags -1 + moreinfo

On Sun, 25 Jul 2021 at 16:52:27 +0100, Steve McIntyre wrote:
> In your next mail, I can see your log shows shim-signed version
> 1.36~1+deb10u1+15.4-5~deb10u1. Despite testing that version on various
> arm64 platforms before release, *after* the 10.10 point release we
> found that version can also crash and fail to boot in some
> circumstances. I think that's your problem here. :-(
> 
> When we found that problem, as an immediate workaround I released a
> newer shim-signed package into the buster-updates repo which solves
> it: version 1.36~1+deb10u2+15.4-5~deb10u1 (note the
> deb10u1->deb10u2).

I noticed that this is still showing up on the list of release-critical
bugs, despite subsequent updates; and the bug tracking system thinks it
applies to Debian 11 'bullseye' and to testing/unstable, although the
report seems to be specific to Debian 10 'buster'.

If the crash Steve mentioned is the same one described in #990082
and #990190, then it should be fixed in version 1.37 and up, which
were included in later point releases of buster (currently version
1.38~1+deb10u1) and also included in the bullseye stable release
(currently version 1.38). Please could you confirm whether these newer
versions can boot on Oracle Cloud machines?

Thanks,
smcv

Bug#1015783: Please update jupyter-notebook to 6.4.12

[Amr Ibrahim]

Package: jupyter-notebook

Hello,

Please update jupyter-notebook to 6.4.12, and change the watch file to track 
the 6.4.x and later 6.5.x releases before the major update to version 7.

https://github.com/jupyter/notebook/tree/6.4.x
https://github.com/jupyter/notebook/tree/6.5.x

Quoting from https://github.com/jupyter/notebook#maintained-versions:

Maintained versions
We maintain the two most recently released major versions of Jupyter Notebook, 
Notebook v5 and Classic Notebook v6. After Notebook v7.0 is released, we will 
no longer maintain Notebook v5. All Notebook v5 users are strongly advised to 
upgrade to Classic Notebook v6 as soon as possible.

The Jupyter Notebook project is currently undertaking a transition to a more 
modern code base built from the ground-up using JupyterLab components and 
extensions.

There is a new stream of work which was submitted and then accepted as a 
Jupyter Enhancement Proposal (JEP) as part of the next version (v7): 
https://jupyter.org/enhancement-proposals/79-notebook-v7/notebook-v7.html

There is also a plan to continue maintaining Notebook v6 with bug and security 
fixes only, to ease the transition to Notebook v7: 
jupyter/notebook-team-compass#5 (comment)

Notebook v7
The next major version of Notebook will be based on:

JupyterLab components for the frontend
Jupyter Server for the Python server
This represents a significant change to the jupyter/notebook code base.

To learn more about Notebook v7: 
https://jupyter.org/enhancement-proposals/79-notebook-v7/notebook-v7.html

Classic Notebook v6
Maintenance and security-related issues are now being addressed in the 6.4.x 
branch.

A 6.5.x branch will be soon created and will depend on nbclassic for the 
HTML/JavaScript/CSS assets.

New features and continuous improvement is now focused on Notebook v7 (see 
section above).

Best,
Amr

Bug#1015014: libgrokj2k: FTBFS on many architectures

[Niko Tyni]

On Sun, Jul 17, 2022 at 01:31:00AM +, Aaron Boxer wrote:

> Thanks for you bug update. I am guessing that the reason why
> Grok no longer builds on these architectures is due to inclusion
> of a library, Highway, for handling SIMD instructions. I don't believe 
> Highway supports the archs you mentioned. Can you elaborate on what you mean 
> by removing old binaries?

As seen in on tracker.debian.org the testing migration of 9.7.5-1 is
blocked because the binary packages from the last successful builds
(version 7.6.6-3) are still around on the failing architectures. The
package won't migrate until it either builds on those architectures again,
or the old packages are removed from unstable.

For more information on removal requests see

  https://wiki.debian.org/ftpmaster_Removals

Hope this helps,
-- 
Niko Tyni   nt...@debian.org

Bug#1012451: [Android-tools-devel] Bug#1012451: apksigner: Using PKCS11 keystore fails with NoSuchMethodException

[dev]

For the record, Debian's apksigner works without issues after installing Java 8 
and marking it as default with update-alternatives. This is definitely a 
compatibility issue that might need to be fixed either upstream or as a patch.

Danilo

Bug#924040: next steps

[Paolo Greppi]

I installed the package above and when I tried the archivebox command I 
got the same error about the missing atomicwrites module.


This is easy to fix by adding 
lib/python3.9/site-packages/atomicwrites/__init__.py from 
https://pypi.org/project/atomicwrites/ 1.4.1 as 
debian/vendor/atomicwrites.py.


A better way of vendoring dependencies would be to use gbp components, 
so that they are versioned, uscan looks for new versions etc.


Another issue is that if I try to "archivebox add" an url I get these 
warnings:


! SINGLEFILE_BINARY: single-file (unable to detect version)
! READABILITY_BINARY: readability-extractor (unable to detect version)
! MERCURY_BINARY: mercury-parser (unable to detect version)

Indeed the page is archived as (I have the recommended dep chromium):
- Chrome > PDF
- Chrome Screenshot
- wget > HTML
- Archive.org
- Headers
- Chrome > HTML
- MEdia
- Git

But these fail:
- Chrome > SingleFile
- Readability
- Mercury
- Git (not sure why)

Getting the first three to work would require installing the JS 
dependencies listed in package.json which is a mess.


But after the atomicwrites fix the package seems to be usable as-is and 
worth uploading!


Paolo

Bug#1015487: libfiu: ftbfs with LTO (link time optimization) enabled

[Chris Lamb]

Dear Alberto,

> From this it seems the issue is with the stack trace collection. If LTO 
> is doing some inlining for example (which wouldn't surprise me) then it 
> could cause the test to fail.
>
> I'll look in more detail at the beginning of August.

No problem; there is no rush. Enjoy your time away! :)


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-