Bug#977026: Evince: denie /opt/firefox/firefox in apparmor profile

[GT]

Package: evince
Version: 3.38.0-3
Severity: normal

Dear Maintainer,

When clicking on a http link in a pdf file Firefox, locally installed, don't
open
#
Evince Apparmor profile denied it:
#
I added:
#
/opt/firefox/firefox ixr,
/opt/firefox/firefox-bin ixr,
#
But remains
#
VC apparmor="DENIED" operation="open" profile="/usr/bin/evince"
name="/proc/11602/task/11604/stat" pid=11602 comm="firefox-bin"
requested_mask="r" denied_mask="r" fsuid=1001 ouid=1001
#
How can I allow a /proc ?



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

Kernel: Linux 5.9.0-4-amd64 (SMP w/2 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 evince depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-1
ii  evince-common3.38.0-3
ii  gsettings-desktop-schemas3.38.0-2
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-5
ii  libcairo-gobject21.16.0-4
ii  libcairo21.16.0-4
ii  libevdocument3-4 3.38.0-3
ii  libevview3-3 3.38.0-3
ii  libgdk-pixbuf-2.0-0  2.40.0+dfsg-8
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-8
ii  libglib2.0-0 2.66.3-2
ii  libgnome-desktop-3-193.38.2-1
ii  libgtk-3-0   3.24.23-3
ii  libnautilus-extension1a  3.38.1-1
ii  libpango-1.0-0   1.46.2-3
ii  libpangocairo-1.0-0  1.46.2-3
ii  libsecret-1-00.20.3-1
ii  shared-mime-info 2.0-1

Versions of packages evince recommends:
ii  dbus-user-session [default-dbus-session-bus]  1.12.20-1
ii  dbus-x11 [dbus-session-bus]   1.12.20-1

Versions of packages evince suggests:
ii  gvfs 1.46.1-1
pn  nautilus-sendto  
ii  poppler-data 0.4.10-1
ii  unrar1:5.9.4-1

-- Configuration Files:
/etc/apparmor.d/usr.bin.evince changed:
/usr/bin/evince {
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  # For now, let evince talk to any session services over dbus. We can
  # blacklist any problematic ones (but note, evince uses libsecret :\)
  #include 
  #include 
  dbus (receive) bus=system,
  # Allow getting information from various system services
  dbus (send)
  bus=system
  member="Get*"
  peer=(label=unconfined),
  # Allow talking to avahi with whatever polkit allows
  dbus (send)
  bus=system
  interface="org.freedesktop.Avahi{,.*}",
  # Allow talking to colord with whatever polkit allows
  dbus (send)
  bus=system
  interface="org.freedesktop.ColorManager{,.*}",
  # Terminals for using console applications. These abstractions should ideally
  # have 'ix' to restrict access to what only evince is allowed to do
  #include 
  # By default, we won't support launching a terminal program in Xterm or
  # KDE's konsole. It opens up too many unnecessary files for most users.
  # People who need this functionality can uncomment the following:
  ##include 
  ##include 
  /usr/bin/evince rmPx,
  /usr/bin/evince-previewer Px,
  /usr/bin/yelp Cx -> sanitized_helper,
  /usr/bin/bug-buddy px,
  # 'Show Containing Folder' (LP: #1022962)
  /usr/bin/nautilus Cx -> sanitized_helper, # Gnome
  /usr/bin/pcmanfm Cx -> sanitized_helper,  # LXDE
  /usr/bin/krusader Cx -> sanitized_helper, # KDE
  /usr/bin/thunar Cx -> sanitized_helper,   # XFCE
  # For Xubuntu to launch the browser
  /usr/bin/exo-open ixr,
  /usr/lib/@{multiarch}/xfce4/exo-1/exo-helper-1 ixr,
  /etc/xdg/xdg-xubuntu/xfce4/helpers.rc r,
  /etc/xdg/xfce4/helpers.rc r,
  # For Guy launches Firefox
  /opt/firefox/firefox ixr, 
  /opt/firefox/firefox-bin ixr, 
  # For text attachments
  /usr/bin/gedit ixr,
  # For Send to
  /usr/bin/nautilus-sendto Cx -> sanitized_helper,
  # GLib desktop launch helper (used under the hood by g_app_info_launch)
  /usr/lib/@{multiarch}/glib-[0-9]*/gio-launch-desktop rmix,
  /usr/bin/env ixr,
  # allow directory listings (ie 'r' on directories) so browsing via the file
  # dialog works
  / r,
  /**/ r,
  # This is need for saving files in your home directory without an extension.
  # Changing this to '@{HOME}/** r' makes it require an extension and more
  # secure (but with 'rw', we still have abstractions/private-files-strict in
  # effect).
  owner @{HOME}/** rw,
  owner /media/**  rw,
  owner 

Bug#977025: ITP: node-create-require -- polyfill for Node.js' module.createRequire

[Julien Puydt]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: Debian Javascript Maintainers


* Package name: node-create-require
  Version: 1.1.1
  Upstream Author: Maël Nison, Pooya Parsa and Paul Soporan
* URL: https://github.com/nuxt-contrib/create-require
* License: Expat
  Programming lang: JavaScript & TypeScript
  Description: polyfill for Node.js' module.createRequire

It's a new dependency of the last version of ts-node.

I plan to maintain it within the Debian JavaScript Team.

Cheers,

JP

Bug#977024: marble-data and marble-qt-data are not m-a: foreign which blocks cross-building

[Andrey Loukhnov]

Package: marble-data
Version: 4:17.08.3-3.2
Severity: important

Dear Maintainer,

we are cross-compiling our internal packages, which depend on marble.

Cross-compilation is failing because of an issue described in the subject.
Please add m-a: foreign to the -data packages.



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

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

Versions of packages marble-data depends on:
ii  marble-qt-data  4:17.08.3-3.2

marble-data recommends no packages.

marble-data suggests no packages.

-- no debconf information

Bug#976899: More details

[Meelis Roos]

I wrote: Upgraded texlive-latex-base texlive-latex-recommended as they came 
together and it breaks. So probably i's one of these two that can take over the 
bug report.

Today I upgraded all other packages except these two and it still works so it 
must be one of these.

--
Meelis Roos

Bug#966395: Any plans on doing this for Bullseye?

[Amos Jeffries]

On 9/12/20 12:35 pm, Luigi Gangitano wrote:

Hi Amos,

Can you please tell me more about the technicalities needed to support 
libssl1?


By "technicality" I was referring to the GPL clause which allows us to 
violate the OpenSSL advertising requirement simply by Debian considering 
OpenSSL part of the OS libraries.




I would like to make a plan for finally enable SSL/TLS in 
squid, if possible.




Okay.

People who don't want the SSL-Bump feature and have already configured 
with GnuTLS specific options in squid.conf will find Squid no longer 
able to load or not running correctly with the OpenSSL-enabled binary.


What do you think of an squid-sslbump package that installs squid built 
against openssl ?


Can we build twice in the same source packaging?


Amos

Bug#977023: symbol lookup error in libbacktrace.so.0

[di dit]

Package: aapt
Version: 1:8.1.0+r23-3+b2
Severity: grave

aapt crashes on startup since the last update of android-libbacktrace
with the following message:

symbol lookup error:
/usr/lib/x86_64-linux-gnu/android/libbacktrace.so.0: undefined symbol:
_ZN11unwindstack12ElfInterfaceD2Ev

Regards

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

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

Versions of packages aapt depends on:
ii  android-libaapt1:8.1.0+r23-3+b2
ii  android-libandroidfw   1:8.1.0+r23-3+b2
ii  android-libbase1:10.0.0+r36-1~stage1.3
ii  android-libutils   1:10.0.0+r36-1~stage1.3
ii  android-libziparchive  1:10.0.0+r36-1~stage1.3
ii  libc6  2.31-5
ii  libexpat1  2.2.10-1
ii  libgcc-s1  10.2.1-1
ii  libpng16-161.6.37-3
ii  libprotobuf-lite23 3.12.3-2+b2
ii  libstdc++6 10.2.1-1

aapt recommends no packages.

aapt suggests no packages.

-- no debconf information

Bug#977022: qxl does not work

[Michael Tokarev]

Control: forcemerge -1 976996

10.12.2020 09:15, Marc Haber wrote:

Package: qemu-system-x86
Version: 1:5.2+dfsg-1
Severity: important

Hi,

upgrading to qemu-system-x86 1:5.2+dfsg-1 breaks VMs using qxl video.
virsh start says
error: unsupported configuration: domain configuration does not support 'video 
model' value 'qxl'
while kvm -vga qxl says
Failed to open module: /usr/lib/x86_64-linux-gnu/qemu/ui-spice-core.so: 
undefined symbol: console_gl_check_format
Failed to open module: /usr/lib/x86_64-linux-gnu/qemu/hw-display-qxl.so: 
undefined symbol: qemu_spice_cursor_refresh_bh
kvm: QXL VGA not available


This is #976996, and the workaround is the same.

Thanks,

/mjt

Bug#976366: Upgrade to 247 broke keyboard input on Wayland session

[duck]

Quack,

On 2020-12-10 07:39, Michael Biebl wrote:

It might be, that ckb-next is affected by this, especially when it 
deals with handling/creating (input) devices.


I'm inclined to reassign this to ckb-next. WDYT?


Indeed it seems the change described in this article would affect 
ckb-next.


I made the fix on my system but it did not solve anything. Then I looked 
deeper and it seems there is a syntax error in the rule, so I fixed it 
too. The resulting file is:

--
ACTION=="remove", GOTO="ckb_end"

# Mark ckb devices as not a joystick and create symlinks to the virtual 
input devices
SUBSYSTEM=="input", ATTRS{name}=="ckb[0-9]: [A-Za-z0-9]*", 
ENV{ID_INPUT_JOYSTICK}="", PROGRAM="/usr/bin/env sed 's/[0-9]: /-/' 
/sys/class/input/%k/device/name", ENV{.INPUT_NAME}="%c", 
SYMLINK+="input/by-id/%E{.INPUT_NAME}-event"


LABEL="ckb_end"
--

But if the symlinks look better (there was some kind of underscore or 
something before "-event"), that does not solve anything. In fact it 
seems these rules are really not that important to make the device work.


So we're back to square one, there is no reason to think the bug is in 
ckb-next, so I would wait a bit more before reassigning. Also if you 
don't mind I'd be happy to get your help some more :-).


If the comments in the upstream ticket are right, is it not strange that 
the way you present available keys affect its availability?


Regards.
\_o<

--
Marc Dequènes

Bug#977022: qxl does not work

[Marc Haber]

Package: qemu-system-x86
Version: 1:5.2+dfsg-1
Severity: important

Hi,

upgrading to qemu-system-x86 1:5.2+dfsg-1 breaks VMs using qxl video.
virsh start says
error: unsupported configuration: domain configuration does not support 'video 
model' value 'qxl'
while kvm -vga qxl says
Failed to open module: /usr/lib/x86_64-linux-gnu/qemu/ui-spice-core.so: 
undefined symbol: console_gl_check_format
Failed to open module: /usr/lib/x86_64-linux-gnu/qemu/hw-display-qxl.so: 
undefined symbol: qemu_spice_cursor_refresh_bh
kvm: QXL VGA not available

Going back to 1:5.1+dfsg-4+b2 from testing fixes the issue for me. The
following system configuration information was generated after the
downgrade.

Greetings
Marc


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

Kernel: Linux 5.9.12-zgws1 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages qemu-system-x86 depends on:
ii  ipxe-qemu 1.0.0+git-20190125.36a4c85-5
ii  libaio1   0.3.112-8
ii  libc6 2.31-5
ii  libcapstone3  4.0.1+really+3.0.5-2+b1
ii  libepoxy0 1.5.4-1
ii  libfdt1   1.6.0-1
ii  libgbm1   20.2.4-1
ii  libgcc-s1 10.2.1-1
ii  libglib2.0-0  2.66.3-2
ii  libgnutls30   3.7.0-3
ii  libibverbs1   32.0-1+b1
ii  libjpeg62-turbo   1:2.0.5-1.1
ii  libnettle83.6-2
ii  libnuma1  2.0.12-1+b1
ii  libpixman-1-0 0.40.0-1
ii  libpmem1  1.10-1
ii  libpng16-16   1.6.37-3
ii  librdmacm132.0-1+b1
ii  libsasl2-22.1.27+dfsg-2
ii  libseccomp2   2.5.0-3+b1
ii  libslirp0 4.3.1-1
ii  libspice-server1  0.14.3-2
ii  liburing1 0.7-2
ii  libusb-1.0-0  2:1.0.23-3
ii  libvdeplug2   4.0.1-2
ii  libvirglrenderer1 0.8.2-5
ii  libxendevicemodel14.14.0+80-gd101b417b7-1
ii  libxenevtchn1 4.14.0+80-gd101b417b7-1
ii  libxenforeignmemory1  4.14.0+80-gd101b417b7-1
ii  libxengnttab1 4.14.0+80-gd101b417b7-1
ii  libxenmisc4.144.14.0+80-gd101b417b7-1
ii  libxenstore3.04.14.0+80-gd101b417b7-1
ii  libxentoolcore1   4.14.0+80-gd101b417b7-1
ii  qemu-system-common1:5.1+dfsg-4+b2
ii  qemu-system-data  1:5.2+dfsg-1
ii  seabios   1.14.0-2
ii  zlib1g1:1.2.11.dfsg-2

Versions of packages qemu-system-x86 recommends:
ii  ovmf 2020.08-1
pn  qemu-system-gui  
ii  qemu-utils   1:5.2+dfsg-1

Versions of packages qemu-system-x86 suggests:
ii  qemu-block-extra1:5.2+dfsg-1
ii  qemu-system-data [sgabios]  1:5.2+dfsg-1
pn  samba   
pn  vde2

-- no debconf information

Bug#977021: bus errors on armhf running on a 64bit kernel

[Matthias Klose]

Package: src:libsis-base-java
Version: 18.09~pre1+git20180928.45fbd31+dfsg-2
Severity: important
Tags: sid bullseye

building libsis-base-java (or running the jni) leads to a bus error, usually
caused by unaligned memory accesses.

[...]
LC_ALL=C java -Djava.library.path=source/c/.libs -classpath sis-base-test.jar
ch.systemsx.cisd.base.AllTests
Application: base
Version: UNKNOWN*
Java VM: OpenJDK Server VM (v11.0.9.1+1-Debian-1)
CPU Architecture: arm
OS: Linux (v4.15.0-126-generic)
Test class: NativeDataTests

Running testFloatToByteNonNativeByteOrderPartialOutputArray
Running testIntToByteToInt
 Arguments: [0, 0]
 Arguments: [0, 1]
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGBUS (0x7) at pc=0xf74b1d1c, pid=10186, tid=10187

Bug#977020: RFS: surgescript/0.5.4.4-1 -- Scripting language for games

[Carlos Donizete Froes]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: surgescript
   Version : 0.5.4.4-1
   Upstream Author : Alexandre Martins 
 * URL : https://docs.opensurge2d.org
 * License : Apache-2.0, BSD-2-Clause
 * Vcs : https://salsa.debian.org/games-team/surgescript
   Section : libs

It builds those binary packages:

  libsurgescript-dev - Scripting language for games (development files)
  libsurgescript0.5.4.4 - Scripting language for games (library files)
  surgescript - Scripting language for games

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/surgescript/surgescript_0.5.4.4-1.dsc

Changes since the last upload:

 surgescript (0.5.4.4-1) unstable; urgency=medium
 .
   * New upstream release.
   * Changed debian/clean.
   * debian/docs:
 + CHANGES.md file included.
   * debian/control:
 + Changed section to 'libs'.
 + Switch to debhelper-compat = 13.
 + Declare compliance with Debian Policy: 4.5.1.
 + Added new packages: libsurgescript0.5.4.4 and libsurgescript-dev.
   * Added d/libsurgescript0.5.4.4.install
   * Added d/libsurgescript-dev.install
   * Added d/surgescript.install
   * debian/rules:
 - Changed override_dh_auto_install.
 + Added DEB_CFLAGS_MAINT_APPEND and DEB_LDFLAGS_MAINT_APPEND.
 + Added override_dh_auto_configure.
 + Added override_dh_missing.

Regards,
--
  Carlos Donizete Froes [a.k.a coringao]

Bug#977006: packages.debian.org: filelist is currently broken for some packages

[Louis-Philippe Véronneau]

Ok, so more debug info, as apparently as a DD I do have access to
picconi.debian.org

1. The file list data is stored in Berkeley DBs in
srv/packages.debian.org/files/db/contents/filelists_${suite}_${arch}.db

2. The packages I referenced before are missing, but only in certain
archs. For example, both "supysonic" and "isbg" are arch "all" packages,
but only end up in:

* filelists_sid_alpha.db
* filelists_sid_riscv64.db
* filelists_sid_ppc64.db
* filelists_sid_sh4.db
* filelists_sid_x32.db
* filelists_sid_hppa.db
* filelists_sid_sparc64.db
* filelists_sid_m68k.db

libprismatic-schema-clojure (also arch "all) ends up in:

* filelists_sid_alpha.db
* filelists_sid_riscv64.db
* filelists_sid_ppc64.db
* filelists_sid_sh4.db
* filelists_sid_x32.db
* filelists_sid_hppa.db
* filelists_sid_sparc64.db
* filelists_sid_m68k.db
* filelists_sid_mips.db
* filelists_sid_hurd-i386.db
* filelists_sid_powerpcspe.db
* filelists_sid_kfreebsd-amd64.db
* filelists_sid_kfreebsd-i386.db

So it's not a fixed list of archs being processed correctly.

3. _Something_ clearly is wrong with the filelists.db files generated,
as some are _much_ smaller that other. For example, one would expect
amd64 to be the largest file...

31M ../filelists_sid_all.db
31M ../filelists_sid_armel.db
31M ../filelists_sid_s390x.db
32M ../filelists_sid_mips64el.db
32M ../filelists_sid_mipsel.db
33M ../filelists_sid_armhf.db
34M ../filelists_sid_ppc64el.db
35M ../filelists_sid_i386.db
36M ../filelists_sid_amd64.db
81M ../filelists_sid_s390.db
84M ../filelists_sid_ia64.db
89M ../filelists_sid_sparc.db
107M../filelists_sid_powerpc.db
110M../filelists_sid_hurd-i386.db
111M../filelists_sid_kfreebsd-amd64.db
111M../filelists_sid_kfreebsd-i386.db
117M../filelists_sid_arm64.db
121M../filelists_sid_mips.db
122M../filelists_sid_sh4.db
123M../filelists_sid_powerpcspe.db
127M../filelists_sid_hppa.db
127M../filelists_sid_m68k.db
128M../filelists_sid_alpha.db
128M../filelists_sid_riscv64.db
128M../filelists_sid_sparc64.db
129M../filelists_sid_x32.db
131M../filelists_sid_ppc64.db

4. /srv/packages.debian.org/bin/parse-contents L101-181 is the code
responsible for generating the filelists.db files.

5. /srv/packages.debian.org/bin/daily is the script calling
parse-contents. My guess is it's called by a cron job or triggers on an
archive refresh, but I don't have the permissions to find out.

6. looking at the cron logs in /srv/packages.debian.org/files/logs,
parse-contents seems to run correctly and update the filelists on a
frequent basis without outputting errors in the log.

7. the local debian mirror seems to be up to date, so the error doesn't
come from there.

As to why those packages aren't listed in the filelists, no clue!

Hopefully that'll help someone if I don't get around fixing this bug
myself (chances I won't...)

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#977019: ITP: golang-golang-x-term -- Go terminal and console support

[Arnaud Rebillout]

Package: wnpp
Severity: wishlist
Owner: Arnaud Rebillout 

* Package name: golang-golang-x-term
  Version : 0.0~git20201207.ee85cb9-1
  Upstream Author : Go
* URL : https://github.com/golang/term
* License : BSD-3-clause-Google
  Programming Lang: Go
  Description : Go terminal and console support

 This repository provides Go terminal and console support packages.



Why packaging: this is a new build dependency of docker.io 20.10.0

Bug#977008: RFS: inkscape-textext/1.3.0-2 -- Re-editable LaTeX graphics for Inkscape

[Antonio Russo]

Package: sponsorship-requests
Severity: normal
X-Debbugs-Cc: aeru...@aerusso.net

Dear mentors,

I am looking for a sponsor for my package "inkscape-textext"

 * Package name: inkscape-textext
   Version : 1.3.0-2
   Upstream Author : Jan Winkler 
 * URL : https://textext.github.io/textext
 * License : BSD-3-clause
 * Vcs : https://salsa.debian.org/aerusso-guest/textext
   Section : graphics
   Description : Re-editable LaTeX graphics for Inkscape

TexText is a Python plugin for the vector graphics editor Inkscape
providing the possibility to add and re-edit LaTeX generated SVG
elements to your drawing.

 Key features
 . Windows/Linux/MacOS support
 . LaTeX generated SVG elements can be re-edited later
 . Multi-line editor with syntax highlighting
 . Compilation with PdfLaTeX, XeLaTeX or LuaLaTex
 . Interoperable scaling in TexText and Inkscape
 . Font size match with Inkscape text
 . Customizable TeX preamble (additional packages, parskip, parindent, etc.)
 . Colorization via TeX commands/Inkscape is kept after re-editing
 . Alignment anchor of the produced output
 . Preview images

It builds the binary packages:

  inkscape-textext - Re-editable LaTeX graphics for Inkscape
  inkscape-textext-doc - Re-editable LaTeX graphics for Inkscape (documentation)

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

  https://mentors.debian.net/package/inkscape-textext/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/i/inkscape-textext/inkscape-textext_1.3.0-2.dsc

Since my last upload, I have addressed comments regarding debian/copyright 
raised
by the ftp team, as well as performing some minor package cleanup (bumped to the
new standards version 4.5.1 and aligning gbp.conf with my salsa layout).

Best,
Antonio Russo


OpenPGP_0xB01C53D5DED4A4EE.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Bug#976791: Acknowledgement (Enable CONFIG_SOUNDWIRE (and related drivers))

[Matt Corallo]

Saw the commits in salsa and went and tested them. Looks like to get audio working config also needs (but definitely 
works now)


CONFIG_SND_SOC_INTEL_USER_FRIENDLY_LONG_NAMES=y
CONFIG_SND_SOC_INTEL_SOUNDWIRE_SOF_MACH=m
CONFIG_SND_SOC_MAX98373_SDW=m
CONFIG_SND_SOC_RT1308=m
CONFIG_SND_SOC_RT1308_SDW=m
CONFIG_SND_SOC_RT5682_SDW=m

Why you have to enable "User Friendly Long Names" in order to enable drivers, I 
have no idea.

On 12/7/20 6:18 PM, Debian Bug Tracking System wrote:

Thank you for filing a new Bug report with Debian.

You can follow progress on this Bug here: 976791: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976791.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
  Debian Kernel Team 

If you wish to submit further information on this problem, please
send it to 976...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

Bug#977018: deltachat-core: reproducible builds: Embedded build paths in html documentation

[Vagrant Cascadian]

Source: deltachat-core
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Numerous html documentation files embed the build path:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/deltachat-core.html

For example:

  ./usr/share/doc/libdeltachat0/html/classdc__array__t.html
  673 
/build/1st/deltachat-core-0.45.0+ds/src/deltachat.h
  673   
/build/2/deltachat-core-0.45.0+ds/2nd/src/deltachat.h

  674 /build/1st/deltachat-core-0.45.0+ds/src/dc_array.c   
  674 
/build/2/deltachat-core-0.45.0+ds/2nd/src/dc_array.c


The attached patch fixes this by setting FULL_PATH_NAMES = NO in the
Doxyfile used by doxygen to generate the documentation:

  
https://tests.reproducible-builds.org/debian/issues/build_dir_in_documentation_generated_by_doxygen_issue.html


Thanks for maintaining deltachat-core!


live well,
  vagrant
From 717622a04812c114bb6e02bd23102031e51757b3 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Thu, 10 Dec 2020 04:05:24 +
Subject: [PATCH] Disable FULL_PATH_NAMES in doxyfile, to generate
 documentation reproducibly regardless of build path.

  https://tests.reproducible-builds.org/debian/issues/unstable/build_dir_in_documentation_generated_by_doxygen_issue.html
---
 docs/Doxyfile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/Doxyfile b/docs/Doxyfile
index 24ee698..6c381b3 100644
--- a/docs/Doxyfile
+++ b/docs/Doxyfile
@@ -144,7 +144,7 @@ INLINE_INHERITED_MEMB  = NO
 # shortest path that makes the file name unique will be used
 # The default value is: YES.
 
-FULL_PATH_NAMES= YES
+FULL_PATH_NAMES= NO
 
 # The STRIP_FROM_PATH tag can be used to strip a user-defined part of the path.
 # Stripping is only done if one of the specified strings matches the left-hand
-- 
2.29.2



signature.asc
Description: PGP signature

Bug#977017: /usr/bin/j2: No manpage

[eingousef]

Package: j2cli
Version: 0.3.12b-2
Severity: normal
File: /usr/bin/j2
X-Debbugs-Cc: eingousef+debb...@rhizogen.es.eu.org

Dear Maintainer,

j2cli doesn't have a manpage, only a --help.

It should have one. Ideally, the manpage could be invoqued with
`man j2` as well as `man j2cli`.

Regards,

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

Kernel: Linux 5.9.0-4-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: OpenRC (via /run/openrc), PID 1: init
LSM: AppArmor: enabled

Versions of packages j2cli depends on:
ii  python3 3.9.0-4
ii  python3-jinja2  2.11.2-1
ii  python3-markupsafe  1.1.1-1+b3
ii  python3-setuptools  50.3.0-1
ii  python3-yaml5.3.1-3+b1

j2cli recommends no packages.

j2cli suggests no packages.

-- no debconf information

Bug#977016: ionit: Doesn't create /etc/ionit at install

[eingousef]

Package: ionit
Version: 0.3.6-1
Severity: normal
X-Debbugs-Cc: eingousef+debb...@rhizogen.es.eu.org

Dear Maintainer,

ionit displays a warning message stating it can't find the default
conf at /etc/ionit right after install :

$ ionit
2020-12-10 01:02:19,016 ionit WARNING: Failed to read configuration directory: 
[Errno 2] No such file or directory: '/etc/ionit'

The ionit package should probably create this default config file at 
installation.

Regards,

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

Kernel: Linux 5.9.0-4-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: OpenRC (via /run/openrc), PID 1: init
LSM: AppArmor: enabled

Versions of packages ionit depends on:
ii  python3 3.9.0-4
ii  python3-jinja2  2.11.2-1
ii  python3-yaml5.3.1-3+b1

ionit recommends no packages.

ionit suggests no packages.

-- no debconf information

Bug#974857: new upstream version v20.10.0

[Ryutaroh Matsumoto]

Control: retitle -1 new upstream version v20.10.0

The much awaited official release v20.10.0 of docker.io
appeared at
https://docs.docker.com/engine/release-notes/#20100

It should fully support cgroup v2.

Best regards, Ryutaroh

Bug#958604: ircd-irc2: diff for NMU version 2.11.2p3~dfsg-5.1

[Nicholas D Steeves]

Resending the nmudiff with both Maintainer and Uploader in CC, just in
case they didn't see previous emails to this bug, and because nmudiff
does not appear to have CCed anyone.


Dear maintainer,

I've prepared an NMU for ircd-irc2 (versioned as 2.11.2p3~dfsg-5.1)
and am seeking a sponsor to have it uploaded it to DELAYED/7. Please
feel free to tell me if I should delay it longer.

Regards,
Nicholas

diff -Nru ircd-irc2-2.11.2p3~dfsg/debian/changelog ircd-irc2-2.11.2p3~dfsg/debian/changelog
--- ircd-irc2-2.11.2p3~dfsg/debian/changelog	2017-07-26 04:49:18.0 -0400
+++ ircd-irc2-2.11.2p3~dfsg/debian/changelog	2020-12-09 21:13:51.0 -0500
@@ -1,3 +1,14 @@
+ircd-irc2 (2.11.2p3~dfsg-5.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop unnecessary dh-systemd build-dep, because debhelper (>= 9.20160709)
+already provides this (Closes: #958604).
+  * ircd-irc2.lintian-overrides:
+"package-contains-upstream-install-documentation" no longer exists, so
+use its replacement "package-contains-upstream-installation-documentation".
+
+ -- Nicholas D Steeves   Wed, 09 Dec 2020 21:13:51 -0500
+
 ircd-irc2 (2.11.2p3~dfsg-5) unstable; urgency=medium
 
   * Update defaults to production use case
diff -Nru ircd-irc2-2.11.2p3~dfsg/debian/control ircd-irc2-2.11.2p3~dfsg/debian/control
--- ircd-irc2-2.11.2p3~dfsg/debian/control	2017-07-26 04:49:18.0 -0400
+++ ircd-irc2-2.11.2p3~dfsg/debian/control	2020-11-24 08:02:48.0 -0500
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Kurt Roeckx 
 Uploaders: Kilian Krause 
-Build-Depends: debhelper (>= 9.20160709~), dh-systemd (>= 1.5), zlib1g-dev, autotools-dev
+Build-Depends: debhelper (>= 9.20160709~), zlib1g-dev, autotools-dev
 Standards-Version: 3.9.5
 Homepage: http://www.irc.org/
 Vcs-Svn: https://anonscm.debian.org/collab-maint/deb-maint/ircd-irc2/
diff -Nru ircd-irc2-2.11.2p3~dfsg/debian/ircd-irc2.lintian-overrides ircd-irc2-2.11.2p3~dfsg/debian/ircd-irc2.lintian-overrides
--- ircd-irc2-2.11.2p3~dfsg/debian/ircd-irc2.lintian-overrides	2014-09-01 15:56:18.0 -0400
+++ ircd-irc2-2.11.2p3~dfsg/debian/ircd-irc2.lintian-overrides	2020-11-24 08:09:45.0 -0500
@@ -1,5 +1,5 @@
-ircd-irc2: package-contains-upstream-install-documentation usr/share/doc/ircd-irc2/INSTALL.appendix.gz
-ircd-irc2: package-contains-upstream-install-documentation usr/share/doc/ircd-irc2/INSTALL.sgml.gz
-ircd-irc2: package-contains-upstream-install-documentation usr/share/doc/ircd-irc2/INSTALL.txt.gz
+ircd-irc2: package-contains-upstream-installation-documentation usr/share/doc/ircd-irc2/INSTALL.appendix.gz
+ircd-irc2: package-contains-upstream-installation-documentation usr/share/doc/ircd-irc2/INSTALL.sgml.gz
+ircd-irc2: package-contains-upstream-installation-documentation usr/share/doc/ircd-irc2/INSTALL.txt.gz
 ircd-irc2: description-synopsis-starts-with-article
 


signature.asc
Description: PGP signature


signature.asc
Description: PGP signature

Bug#976799: [pkg-php-pear] Bug#976799: Please update php-doctrine-inflector autoloader’s path

[Robin Gustafsson]

> Sure, I’m happy to fix my mess ;). I’ll assume the repository on salsa
> is up to date and ready for upload (if not, please come back to me as
> soon as you can, hopefully before the weekend). As everything /seems/
> ready, I hope to take care of the final bits of this
> php-doctrine-[stuff] update this weekend.

Yes, the repo on Salsa is fit for upload. You can go ahead whenever suits you.

Note that I haven't yet merged your MR, just in case something were to
delay the uploads.

Thanks, David.

Regards,
Robin

Bug#976865: Fwd: Bug#974900: dash removes trailing slash from script arguments

[Herbert Xu]

Aurelien Jarno  wrote:
>
> Can you please describe more precisely what is the problem with glob(3)?

It's stripping trailing slashes from the pattern, even when the
name in question is a regular file.

https://patchwork.kernel.org/project/dash/patch/20201116025222.ga28...@gondor.apana.org.au/

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Bug#977015: qemu-user-static: binfmts: qemu-ppc64abi32: no executable qemu-ppc64abi32-static found

[Paul Wise]

Package: qemu-user-static
Version: 1:5.2+dfsg-1
Severity: normal
File: /usr/share/binfmts/qemu-ppc64abi32
User: debian...@lists.debian.org
Usertags: adequate broken-binfmt-interpreter

The recent upgrade dropped the qemu-ppc64abi32-static binfmt
interpreter but did not drop qemu-ppc64abi32 from binfmts.
This bug report brought to you by adequate:

https://bonedaddy.net/pabs3/log/2013/02/23/inadequate-software/

   $ apt upgrade
   ...
   Preparing to unpack .../qemu-user-static-dbgsym_1%3a5.2+dfsg-1_amd64.deb ...
   Unpacking qemu-user-static-dbgsym (1:5.2+dfsg-1) over (1:5.1+dfsg-4+b2) ...
   Preparing to unpack .../qemu-user-static_1%3a5.2+dfsg-1_amd64.deb ...
   Unpacking qemu-user-static (1:5.2+dfsg-1) over (1:5.1+dfsg-4+b2) ...
   Setting up qemu-user-static (1:5.2+dfsg-1) ...
   update-binfmts: warning: /usr/share/binfmts/qemu-ppc64abi32: no executable 
/usr/bin/qemu-ppc64abi32-static found, but continuing anyway as you request
   update-binfmts: warning: unable to close /proc/sys/fs/binfmt_misc/register: 
No such file or directory
   update-binfmts: warning: unable to enable binary format qemu-ppc64abi32
   Setting up qemu-user-static-dbgsym (1:5.2+dfsg-1) ...
   Processing triggers for man-db (2.9.3-2) ...
   ...
   
   $ adequate qemu-user-static
   qemu-user-static: broken-binfmt-interpreter qemu-ppc64abi32 => 
/usr/bin/qemu-ppc64abi32-static (No such file or directory)
   
   $ apt-get changelog qemu-user-static | grep ppc64abi32
 * remove deprecated ppc64abi32 and tilegx linux-user emulators
   
   $ find /usr/bin/qemu-ppc*
   /usr/bin/qemu-ppc64le-static
   /usr/bin/qemu-ppc64-static
   /usr/bin/qemu-ppc-static
   
   $ dpkg -L qemu-user-static | grep ppc64abi32
   /usr/share/binfmts/qemu-ppc64abi32
   
   $ apt-file search ppc64abi32
   qemu-user: /usr/bin/qemu-ppc64abi32   
   qemu-user: /usr/share/man/man1/qemu-ppc64abi32.1.gz
   qemu-user-binfmt: /usr/share/binfmts/qemu-ppc64abi32
   qemu-user-static: /usr/bin/qemu-ppc64abi32-static
   qemu-user-static: /usr/share/binfmts/qemu-ppc64abi32
   qemu-user-static: /usr/share/man/man1/qemu-ppc64abi32-static.1.gz 
   
   $ apt download -qq qemu-user-static/unstable
   $ apt download -qq qemu-user-static/testing
   
   $ ls qemu-user-static*.deb
   qemu-user-static_1%3a5.1+dfsg-4+b2_amd64.deb  
qemu-user-static_1%3a5.2+dfsg-1_amd64.deb
   
   $ dpkg-deb --contents qemu-user-static_1%3a5.1+dfsg-4+b2_amd64.deb | grep 
ppc64abi32
   -rwxr-xr-x root/root   7626376 2020-11-26 05:59 
./usr/bin/qemu-ppc64abi32-static
   -rw-r--r-- root/root   282 2020-11-26 05:59 
./usr/share/binfmts/qemu-ppc64abi32
   lrwxrwxrwx root/root 0 2020-11-26 05:59 
./usr/share/man/man1/qemu-ppc64abi32-static.1.gz -> qemu-user-static.1.gz
   
   $ dpkg-deb --contents qemu-user-static_1%3a5.2+dfsg-1_amd64.deb | grep 
ppc64abi32
   -rw-r--r-- root/root   282 2020-12-09 13:57 
./usr/share/binfmts/qemu-ppc64abi32
   
   $ apt policy qemu-user-static
   qemu-user-static:
 Installed: 1:5.2+dfsg-1
 Candidate: 1:5.2+dfsg-1
 Version table:
*** 1:5.2+dfsg-1 800
   800 https://deb.debian.org/debian unstable/main amd64 Packages
   100 /var/lib/dpkg/status
1:5.1+dfsg-4+b2 900
   900 https://deb.debian.org/debian testing/main amd64 Packages

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

qemu-user-static depends on no packages.

Versions of packages qemu-user-static recommends:
ii  binfmt-support  2.2.1-1

Versions of packages qemu-user-static suggests:
ii  sudo  1.9.4-1

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#977014: apache2-doc: please do not enable apache2-doc site (or even better: remove it at all)

[Christoph Anton Mitterer]

Package: apache2-doc
Version: 2.4.46-2
Severity: wishlist


Hi.

I'd like to propose not to enable the apache2-doc "site" or
even better completely remove it's config or move it to some location
in /u/s/d/apache2/examples/ .

Why?

First, there is typically never every any reason to actually host it.
People who really want this online and not just locally available (where it's
"more secure") can always just use https://httpd.apache.org/docs/ .
And any admin who wants to have access to the very specific version for
his current package, can just use the local files.

The current config places a pretty generic alias, "/manual", into the main
server, which will be active in any vhost, unless specifically overridden.
Absolutely no reason to do this, and in fact it's even like that this
could disturb other content being served.

There's a long standing history of needlessly automatically enabled stuff
causing security issues (e.g. mod_status).
The same principle applies here: why enabling something without any need?


Cheers,
Chris.

Bug#977013: octave-communications FTBFS with Octave 6.1.0: error: print: 'epstool' is required for specified output format, but binary is not available in PATH

[Adrian Bunk]

Source: octave-communications
Version: 1.2.2-3
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=octave-communications

...
octave --path=/<>/doc/../inst -f -q -H --eval "commsimages 
('awgn', 'eps');"
error: print: 'epstool' is required for specified output format, but binary is 
not available in PATH
error: called from
print>epstool at line 864 column 7
__gnuplot_print__ at line 77 column 18
print at line 739 column 14
commsimages at line 41 column 5
make[2]: *** [images.mk:6: awgn.eps] Error 1

Bug#977012: octave-level-set FTBFS with Octave 6.1.0: error: ‘const class Array’ has no member named ‘length’

[Adrian Bunk]

Source: octave-level-set
Version: 0.3.0-11
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=octave-level-set

...
In file included from /usr/include/c++/10/cassert:44,
 from internal_fastmarching.cpp:29:
internal_fastmarching.cpp: In lambda function:
internal_fastmarching.cpp:77:51: error: ‘const class Array’ has no 
member named ‘length’
   77 |   && static_cast (idx.length ()) == D);
  |   ^~
internal_fastmarching.cpp: In lambda function:
internal_fastmarching.cpp:102:51: error: ‘const class Array’ has no 
member named ‘length’
  102 |   && static_cast (idx.length ()) == D);
  |   ^~
...

Bug#977011: RFS: ircd-irc2/2.11.2p3~dfsg-5.1 [NMU] [RC] -- The original IRC server daemon

[Nicholas D Steeves]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "ircd-irc2":

 * Package name: ircd-irc2
   Version : 2.11.2p3~dfsg-5.1
   Upstream Author : Jarkko Oikarinen and University of Oulu, Computing Center
 * URL : http://www.irc.org/
 * License : GPL-1+
 * Vcs : 
https://anonscm.debian.org/viewvc/collab-maint/deb-maint/ircd-irc2/
   Section : net

It builds those binary packages:

  ircd-irc2 - The original IRC server daemon

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

  https://mentors.debian.net/package/ircd-irc2/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/i/ircd-irc2/ircd-irc2_2.11.2p3~dfsg-5.1.dsc

Changes since the last upload:

 ircd-irc2 (2.11.2p3~dfsg-5.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Drop unnecessary dh-systemd build-dep, because debhelper (>= 9.20160709)
 already provides this (Closes: #958604).
   * ircd-irc2.lintian-overrides:
 "package-contains-upstream-install-documentation" no longer exists, so
 use its replacement "package-contains-upstream-installation-documentation".

Regards,
Nicholas

Bug#977010: octave-optim FTBFS with Octave 6.1.0: test failures

[Adrian Bunk]

Source: octave-optim
Version: 1.6.0-5
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=octave-optim

...
[inst/quadprog.m]
> /<>/inst/quadprog.m
* test
 H= diag([1; 0]);
 f = [3; 4];
 A= [-1 -3; 2 5; 3 4];
 b = [-15; 100; 80];
 l= zeros(2,1);
 [x,fval,exitflag,output] = quadprog(H,f,A,b,[],[],l,[]);
 assert(x,[0;5])
 assert(fval,20)
 assert(exitflag,1)
 assert(output.iterations,1)
! test failed
Invalid call to __qp__.  Correct usage is:

 -- [X, LAMBDA, INFO, ITER] = __qp__ (X0, H, Q, AEQ, BEQ, AIN, BIN,
  MAXIT, RTOL)
* demo
  C = [0.95010.76200.61530.4057
  0.23110.45640.79190.9354
  0.60680.01850.92180.9169
  0.48590.82140.73820.4102
  0.89120.44470.17620.8936];
  %% Linear Inequality Constraints
  d = [0.0578; 0.3528; 0.8131; 0.0098; 0.1388];
  A =[0.20270.27210.74670.4659
  0.19870.19880.44500.4186
  0.60370.01520.93180.8462];
  b =[0.5251; 0.2026; 0.6721];
  %% Linear Equality Constraints
  Aeq = [3 5 7 9];
  beq = 4;
  %% Bound constraints
  lb = -0.1*ones(4,1);
  ub = ones(4,1);
  H = C' * C;
  f = -C' * d;
  [x, obj, flag, output, lambda]=quadprog (H, f, A, b, Aeq, beq, lb, ub)
1 test, 0 passed, 0 known failure, 0 skipped
...
[inst/lsqlin.m]
> /<>/inst/lsqlin.m
* test
* shared C,d,A,b
 C = [0.9501,0.7620,0.6153,0.4057;...
 0.2311,0.4564,0.7919,0.9354;...
 0.6068,0.0185,0.9218,0.9169;...
 0.4859,0.8214,0.7382,0.4102;...
 0.8912,0.4447,0.1762,0.8936];
 d = [0.0578;0.3528;0.8131;0.0098;0.1388];
 A =[0.2027,0.2721,0.7467,   0.4659;...
0.1987,0.1988,0.4450,   0.4186;...
0.6037 , 0.0152,0.9318,0.8462];
 b =[0.5251;0.2026;0.6721];
 Aeq = [3, 5, 7, 9];
 beq = 4;
 lb = -0.1*ones(4,1);
 ub = 2*ones(4,1);
 [x,resnorm,residual,exitflag] = lsqlin(C,d,A,b,Aeq,beq,lb,ub);
 assert(x,[-0.1;  -0.1;   0.15991;   0.40896],10e-5)
 assert(resnorm,0.16951,10e-5)
 assert(residual, [0.035297; 0.087623;  -0.353251;   0.145270;   
0.121232],10e-5)
 assert(exitflag,1)
warning: colon arguments should be scalars
warning: called from
null at line 67 column 14
quadprog at line 302 column 13
lsqlin at line 123 column 21
__test__ at line 17 column 32
test at line 677 column 11
/tmp/tmp.Kmq0GnniXr at line 78 column 31

! test failed
Invalid call to __qp__.  Correct usage is:

 -- [X, LAMBDA, INFO, ITER] = __qp__ (X0, H, Q, AEQ, BEQ, AIN, BIN,
  MAXIT, RTOL)
shared variables   scalar structure containing the fields:

C = [](0x0)
d = [](0x0)
A = [](0x0)
b = [](0x0)
* test
 Aeq = [];
 beq = [];
 lb = [];
 ub = [];
 x0 = 0.1*ones(4,1);
 x = lsqlin(C,d,A,b,Aeq,beq,lb,ub,x0);
 [x,resnorm,residual,exitflag] = lsqlin(C,d,A,b,Aeq,beq,lb,ub,x0);
 assert(x,[ 0.12986;  -0.57569 ;  0.42510;   0.24384],10e-5)
 assert(resnorm,0.017585,10e-5)
 assert(residual, [-0.0126033;  -0.0208040;  -0.1295084;  -0.0057389;   
0.01372462],10e-5)
 assert(exitflag,1)
! test failed
quadprog: initial guess has incorrect length
shared variables   scalar structure containing the fields:

C = [](0x0)
d = [](0x0)
A = [](0x0)
b = [](0x0)
* demo
  C = [0.95010.76200.61530.4057
  0.23110.45640.79190.9354
  0.60680.01850.92180.9169
  0.48590.82140.73820.4102
  0.89120.44470.17620.8936];
  d = [0.0578; 0.3528; 0.8131; 0.0098; 0.1388];
  %% Linear Inequality Constraints
  A =[0.20270.27210.74670.4659
  0.19870.19880.44500.4186
  0.60370.01520.93180.8462];
  b =[0.5251; 0.2026; 0.6721];
  %% Linear Equality Constraints
  Aeq = [3 5 7 9];
  beq = 4;
  %% Bound constraints
  lb = -0.1*ones(4,1);
  ub = ones(4,1);
  [x, resnorm, residual, flag, output, lambda] = lsqlin (C, d, A, b, Aeq, beq, 
lb, ub)
2 tests, 1 passed, 0 known failure, 0 skipped
...

Bug#958604: ircd-irc2: diff for NMU version 2.11.2p3~dfsg-5.1

[Nicholas D Steeves]

Control: tags 958604 + pending


Dear maintainer,

I've prepared an NMU for ircd-irc2 (versioned as 2.11.2p3~dfsg-5.1)
and am seeking a sponsor to have it uploaded it to DELAYED/7. Please
feel free to tell me if I should delay it longer.

Regards,
Nicholas

diff -Nru ircd-irc2-2.11.2p3~dfsg/debian/changelog ircd-irc2-2.11.2p3~dfsg/debian/changelog
--- ircd-irc2-2.11.2p3~dfsg/debian/changelog	2017-07-26 04:49:18.0 -0400
+++ ircd-irc2-2.11.2p3~dfsg/debian/changelog	2020-12-09 21:13:51.0 -0500
@@ -1,3 +1,14 @@
+ircd-irc2 (2.11.2p3~dfsg-5.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop unnecessary dh-systemd build-dep, because debhelper (>= 9.20160709)
+already provides this (Closes: #958604).
+  * ircd-irc2.lintian-overrides:
+"package-contains-upstream-install-documentation" no longer exists, so
+use its replacement "package-contains-upstream-installation-documentation".
+
+ -- Nicholas D Steeves   Wed, 09 Dec 2020 21:13:51 -0500
+
 ircd-irc2 (2.11.2p3~dfsg-5) unstable; urgency=medium
 
   * Update defaults to production use case
diff -Nru ircd-irc2-2.11.2p3~dfsg/debian/control ircd-irc2-2.11.2p3~dfsg/debian/control
--- ircd-irc2-2.11.2p3~dfsg/debian/control	2017-07-26 04:49:18.0 -0400
+++ ircd-irc2-2.11.2p3~dfsg/debian/control	2020-11-24 08:02:48.0 -0500
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Kurt Roeckx 
 Uploaders: Kilian Krause 
-Build-Depends: debhelper (>= 9.20160709~), dh-systemd (>= 1.5), zlib1g-dev, autotools-dev
+Build-Depends: debhelper (>= 9.20160709~), zlib1g-dev, autotools-dev
 Standards-Version: 3.9.5
 Homepage: http://www.irc.org/
 Vcs-Svn: https://anonscm.debian.org/collab-maint/deb-maint/ircd-irc2/
diff -Nru ircd-irc2-2.11.2p3~dfsg/debian/ircd-irc2.lintian-overrides ircd-irc2-2.11.2p3~dfsg/debian/ircd-irc2.lintian-overrides
--- ircd-irc2-2.11.2p3~dfsg/debian/ircd-irc2.lintian-overrides	2014-09-01 15:56:18.0 -0400
+++ ircd-irc2-2.11.2p3~dfsg/debian/ircd-irc2.lintian-overrides	2020-11-24 08:09:45.0 -0500
@@ -1,5 +1,5 @@
-ircd-irc2: package-contains-upstream-install-documentation usr/share/doc/ircd-irc2/INSTALL.appendix.gz
-ircd-irc2: package-contains-upstream-install-documentation usr/share/doc/ircd-irc2/INSTALL.sgml.gz
-ircd-irc2: package-contains-upstream-install-documentation usr/share/doc/ircd-irc2/INSTALL.txt.gz
+ircd-irc2: package-contains-upstream-installation-documentation usr/share/doc/ircd-irc2/INSTALL.appendix.gz
+ircd-irc2: package-contains-upstream-installation-documentation usr/share/doc/ircd-irc2/INSTALL.sgml.gz
+ircd-irc2: package-contains-upstream-installation-documentation usr/share/doc/ircd-irc2/INSTALL.txt.gz
 ircd-irc2: description-synopsis-starts-with-article
 


signature.asc
Description: PGP signature

Bug#976348: debian-faq: reproducible builds: Embedded timestamps in PDF files

[Joost van Baal-Ilić]

Hi Vagrant,

Thanks a lot, just commited.

Bye,

Joost

Bug#962122: Resolved

[Adam Croft]

This is not a bug. It's a known issue with Asus TUF VG27AQ monitors.

Bug#976934: [PATCH] build/docs: move docstring prereq to file targets

[David Bremner]

Under a sufficiently high level of parallelism [1] there seems to be a
a race condition that allows sphinx-build to start running before the
docstrings are extracted. This change moves the docstring stamp from
the phony targets sphinx-html and sphinx-info to the file targets that
they depend on. I'm not sure why this makes things better, but I am
fairly confident it does not make things worse, and experimentally it
seems to eliminate the race condition.

[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976934
---
 doc/Makefile.local | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/Makefile.local b/doc/Makefile.local
index 60bd7184..f476d1da 100644
--- a/doc/Makefile.local
+++ b/doc/Makefile.local
@@ -43,7 +43,7 @@ INFO_INFO_FILES := $(INFO_TEXI_FILES:.texi=.info)
rm -f $@ && gzip --no-name --stdout $^ > $@
 
 ifeq ($(WITH_EMACS),1)
-$(DOCBUILDDIR)/.roff.stamp sphinx-html sphinx-texinfo: docstring.stamp
+$(DOCBUILDDIR)/.roff.stamp $(DOCBUILDDIR)/.html.stamp 
$(DOCBUILDDIR)/.texi.stamp : docstring.stamp
 endif
 
 sphinx-html: $(DOCBUILDDIR)/.html.stamp
-- 
2.29.2

Bug#974669: bug analysis

[Felix C. Stegerman]

Hi!

I've looked into this:

* readline 8.1 enables bracketed-paste by default;

* when bracketed-paste is enabled, rl_deprep_terminal() prints
  BRACK_PASTE_FINI ("\033[?2004l\r") to rl_outstream;

* this moves the cursor to the beginning of the line (instead of the
  position after the prompt), which causes the rlwrap prompt to be
  overwritten during rl_redisplay().

* thus, adding "set enable-bracketed-paste off" to my ~/.inputrc fixes
  the problem;

* THB I'm not entirely sure whether this is a bug in readline or in
  rlwrap, so I'll report it to both upstream projects.

- Felix

Bug#973467: vmdb2 tries to install grub-pc or grub-efi-amd64 on arm64 and does not work on arm64

[Ryutaroh Matsumoto]

Hi everyone interested in vmdb2!

Short comments: David's approach for vmdb2 multi-arch supports
re-uses the architecture specified for qemu-debootstrap for that of "grub: 
uefi".
My approach requires a user to specify the architecture twice for
qemu-debootstrap and "grub: uefi".
So, David's approach seems cleaner than mine.

In his approach, the architecture of grub defaults to the host architecuture,
which also seems more reasonable than mine, but it could break backward 
compatibility
that vmdb2 0.19 and earlier always assumes amd64 architecture for
"grub: uefi" even on non-amd64 hosts. It could cause a minor regression
from 0.19.

Best regards, Ryutaroh

Bug#977009: vtk7: FTBFS on hurd-i386 due to Applism

[Samuel Thibault]

Package: vtk7
Version: 7.1.1+dfsg2-4
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd

Hello,

Could you apply the attached upstream patch from

https://gitlab.kitware.com/diatomic/diy/-/commit/bb0d55c8ae34a43354b1002262dad722c410d8cb.patch

to fix the build on hurd-i386?

Thanks,
Samuel

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

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

Versions of packages vtk7 depends on:
ii  libc62.31-5
ii  libgcc-s1 [libgcc1]  10.2.0-19
ii  libstdc++6   10.2.0-19
ii  libtcl8.68.6.10+dfsg-1
ii  libtk8.6 8.6.10-1
pn  libvtk7.1
pn  libvtk7.1p   

vtk7 recommends no packages.

Versions of packages vtk7 suggests:
pn  vtk7-doc   
pn  vtk7-examples  

-- 
Samuel
 le y est un animal discret se logeant facilement dans un terminal
*** c has changed the topic on channel #ens-mim to ne pas jeter de cacahuetes 
aux ys, svp
 -+- #ens-mim - n'oubliez pas le guide -+-
>From bb0d55c8ae34a43354b1002262dad722c410d8cb Mon Sep 17 00:00:00 2001
From: Samuel Thibault 
Date: Sat, 13 Jun 2020 13:59:31 +0200
Subject: [PATCH] Fix build on mach-based OS which are not OS X

---
 include/diy/time.hpp | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/ThirdParty/diy2/vtkdiy2/include/vtkdiy/time.hpp 
b/ThirdParty/diy2/vtkdiy2/include/vtkdiy/time.hpp
index 692cf36..671e69d 100644
--- a/ThirdParty/diy2/vtkdiy2/include/vtkdiy/time.hpp
+++ b/ThirdParty/diy2/vtkdiy2/include/vtkdiy/time.hpp
@@ -3,10 +3,10 @@
 
 #include 
 
-#ifdef __MACH__
+#if defined(__MACH__) && defined(__APPLE__)
 #include 
 #include 
-#endif
+#endif
 
 namespace diy
 {
@@ -16,7 +16,7 @@ typedef unsigned long   time_type;
 
 inline time_type get_time()
 {
-#ifdef __MACH__ // OS X does not have clock_gettime, use clock_get_time
+#if defined(__MACH__) && defined(__APPLE__) // OS X does not have 
clock_gettime, use clock_get_time
 clock_serv_t cclock;
 mach_timespec_t ts;
 host_get_clock_service(mach_host_self(), CALENDAR_CLOCK, );
-- 
GitLab

Bug#973467: vmdb2 tries to install grub-pc or grub-efi-amd64 on arm64 and does not work on arm64

[Ryutaroh Matsumoto]

Hi Gunnar,
CC: Christian,

Thank you for your message.
Since I am in To: field of your email,
I assume your last email is somewhat directed to me.
In short, I am not qualified to do NMU, a detailed excuse follows.

I have no right or expertise to NMU...
As your email is publicly appearing to BTS,
I CC'ed my reply to Christian.

I know he is also very busy now, but he has experience of packaging
and maintaining Debian packages, so he seems much more qualified than me...

For me, maybe the first required task is to learn proper packaging of
a Debian package, then I have to submit application to obtain the privilege
to upload an NMU'ed package...
It can possibly/probably be done in my year-end holidays,
but I am unsure if I can meet the Debian freeze deadline...

Best regards, Ryutaroh

Bug#971570: julia: libgit2 1.0 transition

[Norbert Preining]

Hi Utkarsh,

On Thu, 10 Dec 2020, Utkarsh Gupta wrote:
> I've recently uploaded libgit2 1.1.0 to unstable and built julia
> against it. The build went fine and everything seemed to be in its
> place. Therefore, I am closing this bug now.

Thanks for checking back and confirmation, good to hear that it worked
out. I got a binNMU of julia today onto my computer.

All the best

Norbert

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

Bug#975931: libgpuarray autopkgtest using pocl on armhf triggers segfault in LLVM

[Andreas Beckmann]

Control: reassign -1 libllvm10,libllvm11
Control: found -1 1:10.0.1-8
Control: found -1 1:11.0.0-5
Control: retitle -1 libgpuarray autopkgtest using pocl on armhf triggers 
segfault in LLVM
Control: affects -1 + src:pocl

This bug is reproducible with pocl built against llvm-10 (in sid)
and pocl built against llvm-11 (in experimental), while no error
occurrs with pocl built against llvm-9 (in testing).

I managed to create a reproducer in C with an embedded OpenCL kernel
that hopefully helps debugging the issue. (Removing python,
libgpuarray, libclblas, ... from the path triggering the issue.)

Installing the following packages should be sufficient:
  pocl-opencl-icd libpocl2-dbgsym libllvm10-dbgsym ocl-icd-opencl-dev 
ocl-icd-libopencl1-dbgsym

The 975931.sh script builds the ./975931 binary and runs it with an
empty pocl kernel cache, resulting in a segmentation fault with this backtrace:

#0  getEmissionKind () at 
/build/llvm-toolchain-10-cW4tHW/llvm-toolchain-10-10.0.1/llvm/include/llvm/IR/DebugInfoMetadata.h:1244
#1  initialize () at 
/build/llvm-toolchain-10-cW4tHW/llvm-toolchain-10-10.0.1/llvm/lib/CodeGen/LexicalScopes.cpp:53
#2  0xb14102f0 in computeIntervals () at 
/build/llvm-toolchain-10-cW4tHW/llvm-toolchain-10-10.0.1/llvm/lib/CodeGen/LiveDebugVariables.cpp:979
#3  runOnMachineFunction () at 
/build/llvm-toolchain-10-cW4tHW/llvm-toolchain-10-10.0.1/llvm/lib/CodeGen/LiveDebugVariables.cpp:996
#4  runOnMachineFunction () at 
/build/llvm-toolchain-10-cW4tHW/llvm-toolchain-10-10.0.1/llvm/lib/CodeGen/LiveDebugVariables.cpp:1023
#5  0xb14856c8 in runOnFunction () at 
/build/llvm-toolchain-10-cW4tHW/llvm-toolchain-10-10.0.1/llvm/lib/CodeGen/MachineFunctionPass.cpp:73
#6  0xb12ff494 in runOnFunction () at 
/build/llvm-toolchain-10-cW4tHW/llvm-toolchain-10-10.0.1/llvm/lib/IR/LegacyPassManager.cpp:1481
#7  0xb12ff750 in runOnModule () at 
/build/llvm-toolchain-10-cW4tHW/llvm-toolchain-10-10.0.1/llvm/lib/IR/LegacyPassManager.cpp:1517
#8  0xb12ffba8 in runOnModule () at 
/build/llvm-toolchain-10-cW4tHW/llvm-toolchain-10-10.0.1/llvm/lib/IR/LegacyPassManager.cpp:1582
#9  run () at 
/build/llvm-toolchain-10-cW4tHW/llvm-toolchain-10-10.0.1/llvm/lib/IR/LegacyPassManager.cpp:1694
#10 0xb6e64c82 in pocl_llvm_codegen (Device=Device@entry=0xdb0010, 
Modp=0x1361838, Output=Output@entry=0xbefde86c, 
OutputSize=OutputSize@entry=0xbefde880) at ./lib/CL/pocl_llvm_wg.cc:624
#11 0xb6e291de in llvm_codegen (output=output@entry=0xdeb898 
"pocl-kernel-cache-2020-12-10T00:06:19+00:00-hPVZwM/AP/PNFEAPBKBFEAKGGNMALGHGJEEKGMJFBFBMDHA/Sdot_kernel/0-0-0/Sdot_kernel.so",
 device_i=device_i@entry=0, kernel=kernel@entry=0xbefe0240, 
device=0xdb0010, command=command@entry=0xbefe0278, 
specialize=specialize@entry=0) at ./lib/CL/devices/common.c:158
#12 0xb6e2ae44 in pocl_check_kernel_disk_cache 
(command=command@entry=0xbefe0278, specialized=specialized@entry=0) at 
./lib/CL/devices/common.c:958
#13 0xb6e2b262 in pocl_check_kernel_dlhandle_cache (command=0xbefe0278, 
initial_refcount=0, specialize=0) at ./lib/CL/devices/common.c:1081
#14 0xb6e033d4 in program_compile_dynamic_wg_binaries 
(program=program@entry=0xd8ab88) at ./lib/CL/pocl_build.c:179
#15 0xb6e13f20 in get_binary_sizes (sizes=0xbefe0384, program=0xd8ab88) at 
./lib/CL/clGetProgramInfo.c:36
#16 POclGetProgramInfo (program=0xd8ab88, param_name=4453, 
param_value_size=128, param_value=0xbefe0384, param_value_size_ret=0xbefe0380) 
at ./lib/CL/clGetProgramInfo.c:115
#17 0x00473070 in main () at 975931.c:238

Then it runs the binary again, this time with the pocl kernel cache contents
from previous failure, resulting in

inlinable function call in a function with debug info must have a !dbg location
  %11 = call i32 @_Z12get_local_idj(i32 0)
inlinable function call in a function with debug info must have a !dbg location
  %19 = call i32 @_Z12get_local_idj(i32 1)
inlinable function call in a function with debug info must have a !dbg location
  %27 = call i32 @_Z12get_local_idj(i32 2)
binary size: 52077
OK

It may well be that pocl calls llvm with some invalid input
(the fact that the second run does not segfault seems to
indicate something like this), but still a compiler (library)
should not segfault in this case.
I hope you can shed some light on whether llvm or pocl is to
blame here.


Andreas
#define CL_TARGET_OPENCL_VERSION 220

#include 
#include 
#include 
#include 

const char source[] =
"#ifdef DOUBLE_PRECISION\n"
"#ifdef cl_khr_fp64\n"
"#pragma OPENCL EXTENSION cl_khr_fp64 : enable\n"
"#else\n"
"#pragma OPENCL EXTENSION cl_amd_fp64 : enable\n"
"#endif\n"
"#endif\n"
"\n"
"__kernel void Sdot_kernel( __global float *_X, __global float *_Y, __global float *scratchBuff,\n"
"uint N, uint offx, int incx, uint offy, int incy, int doConj )\n"
"{\n"
"__global float *X = _X + offx;\n"
"__global float *Y = _Y + offy;\n"
"float dotP = (float) 0.0;\n"
"\n"
"if ( incx < 0 ) {\n"
"X = X + (N - 1) 

Bug#977007: ppmrainbow: Attempts to create tmpfile at /

[Mike Edwards]

Package: netpbm
Version: 2:10.0-15.3+b2
Severity: important
Tags: patch

Dear Maintainer,

   * What led up to the situation?
   Running ppmrainbow followed by any colors causes it to throw an error when
attempting to create a temporary file
   * What was the outcome of this action?
   Use of uninitialized value $tmpdir in sprintf at /usr/bin/ppmrainbow.orig
line 58.
   sh: 1: cannot create /000.ppm: Permission denied
   * What outcome did you expect instead?
   ppmrainbow to output a ppm file

Bug is caused by putting output from tempdir() in $tempdir, instead of expected
$tmpdir (note missing 'e' in latter).

See attached patch for fix.


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

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

Versions of packages netpbm depends on:
ii  libc62.28-10
ii  libjpeg62-turbo  1:1.5.2-2+deb10u1
ii  libnetpbm10  2:10.0-15.3+b2
ii  libpng16-16  1.6.36-6
ii  libtiff5 4.1.0+git191117-2~deb10u1
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages netpbm recommends:
ii  ghostscript  9.27~dfsg-2+deb10u4

netpbm suggests no packages.
--- ppmrainbow.orig 2016-01-30 10:51:10.0 -0500
+++ ppmrainbow  2020-12-09 18:21:16.490547774 -0500
@@ -49,7 +49,7 @@
 my $numcol = scalar @ARGV;
 push @ARGV, $ARGV[0];
 
-my $tempdir = tempdir("$myname.XXX", CLEANUP => 1)
+my $tmpdir = tempdir("$myname.XXX", CLEANUP => 1)
 || die "Cant create tmpdir"; #219019
 my @outlist = ();
 my $n = 0;

Bug#976402: Proposed official virtual packages - todo and todo.txt

[Ansgar Burchardt]

David Steele writes:
> On Wed, Dec 9, 2020 at 3:21 AM Ansgar  wrote:
>> Given topydo just provides/conflicts with devtodo to provide the "todo"
>> binary, this seems to violate Policy 10.1 "Binaries" unless they provide
>> the same functionality.
[...]
> From where I stand, I would expect the Policy to use a different word to
> indicate something along the lines of greater API compatibility. I have no
> additional background information, though. Are you aware of any expansions
> on this text, or of any precedents that could help with a consensus process?

My understanding is that different alternatives for a binary in PATH
should provide a compatible command-line interface as one might not know
which alternative is installed.  See for example the description of
x-terminal-emulator in Policy 11.8.3 or requirements for the sendmail
program.

It is sufficient to only require some subset to be guaranteed to be
provided (as is the case for both x-terminal-emulator and sendmail: any
provider will usually also accept provider-specific options in addition
to the general ones).

David Steele writes in another mail:
> That leaves todo.txt, implemented by topydo and (hopefully, soon)
> todotxt-cli. Unfortunately, (1) has been invoked here as well - the command
> sets of the two packages are close, but not identical. Also, I'm on record
> saying an emacs script could comply if:
>   - it properly supports the "--info" argument
>   - it supports calling the hooks in the optional todo.txt-base package
>   - it provides a means to add/modify/delete/show tasks housed in a
> todo.txt-format file, noting that the format does not have to be strictly
> enforced by the package.
>
> My latest stake in the ground - I claim that the functionality of the
> todo.txt virtual package, from a Policy perspective, is defined, here, and
> that the candidates are compliant.

I think "todo.txt" is okay if providers of the "todo.txt" virtual
package provide a "/usr/bin/todo.txt" alternative that provides some
reasonable subset of the command-line interface that topydo / todo.sh /
similar tools share so that "todo.txt list", "todo.txt add laundry" and
so work.  That seems to be the case between topydo and todotxt-cli; just
opening emacs wouldn't be valid.

(As with the examples above providers can implement more than just the
common interface.)

Something like this maybe?

  - name: todo.txt
description: command-line task management utility compatible with todo.txt 
CLI (http://todotxt.org)
alternatives: [/usr/bin/todo.txt]

Ansgar

Bug#976996: qemu-system: qemu doesn't support video mode qxl anymore and fails to load spice libraries

[bauen1]

Package: qemu-system
Version: 1:5.2+dfsg-1
Severity: important
X-Debbugs-Cc: j24...@gmail.com

Dear Maintainer,

I've just upgraded qemu-system and related packages, now I can't launch any 
libvirt virtual machiness with the virtual machine manager frontend anymore.
It appears that this is caused by qemu no longer being build with support for 
the qxl video mode, or at least not advertising it anymore.
When ran with spice qemu now also fails to load the 
/usr/lib/x86_64-linux-gnu/qemu/ui-spice-core.so library due to unresolved 
symbols `console_gl_check_format`.

This appears to be a regression from 1:5.1+dfsg-4+b2

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

Kernel: Linux 5.9.0-4-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: bauen1-policy

Versions of packages qemu-system depends on:
ii  qemu-system-arm1:5.2+dfsg-1
ii  qemu-system-mips   1:5.2+dfsg-1
ii  qemu-system-misc   1:5.2+dfsg-1
ii  qemu-system-ppc1:5.2+dfsg-1
ii  qemu-system-sparc  1:5.2+dfsg-1
ii  qemu-system-x861:5.2+dfsg-1

qemu-system recommends no packages.

qemu-system suggests no packages.

-- no debconf information

Bug#976427: Partial fix Re: Bug#976427 closed by Debian FTP Masters (reply to se...@debian.org (Steinar H. Gunderson)) (Bug#976427: fixed in plocate 1.1.1-2)

[Steinar H. Gunderson]

On Thu, Dec 10, 2020 at 12:58:09AM +0100, GSR wrote:
> The solution I meant is "try working with less concurrently opened
> files" or something similar.

Yes, and that's fundamentally hard without creating races and still
maintaining the desired ordering of locate output. updatedb.mlocate
tries, and has to do a very complicated dance with chdir() back and forth.
It runs into lots of icky cases and has to just silently ignore some errors
(with associated races); the only winning move is not to play.

> I understand the concept beyond io_uring,
> but I have not checked any code, so maybe it can be asked to behave
> inside the limits, or the calling code must limit the requests or the
> processing of the answers, or maybe something else completly.

There's no io_uring in updatedb, so this isn't it.

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

Bug#976427: Partial fix Re: Bug#976427 closed by Debian FTP Masters (reply to se...@debian.org (Steinar H. Gunderson)) (Bug#976427: fixed in plocate 1.1.1-2)

[GSR]

Hi,
se...@debian.org (2020-12-08 at 0109.08 +0100):
> On Tue, Dec 08, 2020 at 01:04:07AM +0100, GSR wrote:
> > And the ulimit line is missing, so when testing manually it fails with
> > ---8<---
> > /some/dir/somewhere: Too many open files
> > Hint: Try `ulimit -n 8192' or similar (current limit is 4096).
> > --->8---
> 
> That's odd; it should do setrlimit() itself at startup (LimitNOFILE=
> in the systemd unit is just to set the hard limit). How can ulimit
> in the shell succeed but setrlimit() fail?

That bash ulimit call (just -n, without -H or -S) sets both hard and
soft at the same time (see bash(1)), and as it is run as root, it can
change to anything including beyond current hard. If setrlimit() only
request a change of rlim_cur, hard will act as ceiling.

> > When run for personal databases the solution must come from the
> > binary, as users will not be able to raise limit beyond the hard
> > number.
> 
> updatedb isn't privileged, so it's no more able to raise the hard limit than
> the user is.

The solution I meant is "try working with less concurrently opened
files" or something similar. I understand the concept beyond io_uring,
but I have not checked any code, so maybe it can be asked to behave
inside the limits, or the calling code must limit the requests or the
processing of the answers, or maybe something else completly. mlocate
seems to work fine with 1024 as limit (or 4096 if it is also raising
soft to hard).

I just tried to create a private db of the troublesome tree using
"/usr/sbin/updatedb.plocate -l 0 -o /tmp/ploc.db -U /path/" and failed
again. "/usr/bin/updatedb.mlocate -l 0 -o /tmp/mloc.db -U /path/"
created the database without issues. I would need to use root to
generate the plocate db for normal accounts (not good, even if I have
access to root), or keep mlocate and convert.

BTW, notice sbin vs bin. Also plocate-build is under sbin. They are
supposed to be usable by normal accounts.

Cheers,
GSR
 

Bug#977006: packages.debian.org: filelist is currently broken for some packages

[Louis-Philippe Véronneau]

Package: www.debian.org
Severity: important
User: www.debian@packages.debian.org
Usertag: packages

Dear maintainers,

The "filelist" feature on packages.debian.org has been broken for a
number for days on some packages. I sadly cannot find a common
denominator. It doesn't seem to be upload-date specific,
language-specific nor architecture-specific.

Only packages in bullseye and sid seem to be affected.

The error message I get is:

-
Error

No such package in this suite on this architecture.
-

Here are some examples:

https://packages.debian.org/sid/all/supysonic/filelist
https://packages.debian.org/bullseye/all/isbg/filelist
https://packages.debian.org/bullseye/all/libprismatic-schema-clojure/filelist

At first I though the problem might be upload-date specific, but firefox
was uploaded to unstable on 2020/11/18 (after isbg) and filelist still
works:

https://packages.debian.org/sid/amd64/firefox/filelist

It's not a question of architecture either. For example, xorg-server
works, was uploaded to buster on 2020/12/01 and is an arch "all" package:

https://packages.debian.org/buster/all/xorg-server-source/filelist

Without access to server logs, I don't think I can really debug this
further :(

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#976887: texlive-base: Should not migrate to testing for now.

[Norbert Preining]

On Thu, 10 Dec 2020, Hilmar Preuße wrote:
> Hence I'd assume the issue is in some changes in the LaTeX kernel. Testing
> has "LaTeX2e <2020-02-02> patch level 5" unstable is "LaTeX2e <2020-10-01>
> patch level 2".

Thanks, I will forward this to the LaTeX Team for check.
Having a minimal example helps a lot, very much appreciated.

Best

Norbert

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

Bug#977005: cloud: Additional modules to disable

[Noah Meyerhans]

Package: src:linux
Version: 5.9.11-1
Severity: wishlist

Per discussion in the recent cloud-team meeting, there are several
additional modules that can be disabled in the cloud kernel.  The
proposed candidates for removal is below; please feel free to critique
specific entries if you think there's a need to leave them enabled.

fs/coda/coda.ko (CODA_FS)
fs/reiserfs/reiserfs.ko (REISERFS_FS)
fs/hpfs/hpfs.ko (HPFS_FS)
fs/hfsplus/hfsplus.ko   (HFSPLUS_FS)
fs/hfs/hfs.ko   (HFS_FS)
fs/jfs/jfs.ko   (JFS_FS)
fs/nilfs2/nilfs2.ko (NILFS2_FS)
fs/minix/minix.ko   (MINIX_FS)
fs/ecryptfs/ecryptfs.ko (ECRYPT_FS)

Thanks
noah

Bug#976901: nvidia-tesla-450-kernel-dkms: Fails to build DKMS kernel module on ppc64le 450.80.02

[Andreas Beckmann]

On 12/9/20 9:30 AM, Konstantinos Margaritis wrote:
> Hi, I am trying to use a Titan X on a Talos II Power9 system on bullseye
> and the nvidia module fails to compile. Build log attached:

The error:

/var/lib/dkms/nvidia-tesla-450/450.80.02/build/nvidia/nv-pci.c:891:10: warning: 
'enum pci_channel_state' declared inside parameter list will not be visible 
outside of this definition or declaration
/var/lib/dkms/nvidia-tesla-450/450.80.02/build/nvidia/nv-pci.c:891:28: error: 
parameter 2 ('error') has incomplete type
/var/lib/dkms/nvidia-tesla-450/450.80.02/build/nvidia/nv-pci.c:889:1: error: 
function declaration isn't a prototype [-Werror=strict-prototypes]

Similar errors happen building the 418 and 440 tesla driver modules
for Linux 5.9 on ppc64el.

There are changes in 455.45.01-1 to mitigate this kernel change:

# pci_channel_state was removed by commit 16d79cd4e23b ("PCI: Use
# 'pci_channel_state_t' instead of 'enum pci_channel_state'") in
# v5.9-rc1 (2020-07-02).

but I'm not sure whether it is worth backporting them,
since you most likely will be affected by
#973729 - nvidia-uvm does not work with Linux 5.9
which is fixed in 455.45.01

Unfortunately there is no separate 455.xx driver release available
for ppc64el.


Andreas

PS: you could try s/enum pci_channel_state/pci_channel_state_t/g
on the dkms tree

PPS: the first time I hear that someone is actually trying to use
the ppc64el packages ;-)

Bug#976402: Bug#976902: topydo: provides /usr/bin/todo with incompatible interface compared to devtodo

[Dave Steele]

I see two complaints about the "todo" virtual package:
  1) it encompasses applications that may not have sufficiently identical
interfaces, and/or
  2) it uses Conflicts as a transition mechanism.

Resolving (2) exceeds my threshold. I'll drop the todo package.

That leaves todo.txt, implemented by topydo and (hopefully, soon)
todotxt-cli. Unfortunately, (1) has been invoked here as well - the command
sets of the two packages are close, but not identical. Also, I'm on record
saying an emacs script could comply if:
  - it properly supports the "--info" argument
  - it supports calling the hooks in the optional todo.txt-base package
  - it provides a means to add/modify/delete/show tasks housed in a
todo.txt-format file, noting that the format does not have to be strictly
enforced by the package.

My latest stake in the ground - I claim that the functionality of the
todo.txt virtual package, from a Policy perspective, is defined, here, and
that the candidates are compliant.

I'm trying to do this in good faith.

Any objections? Actions? Suggestion for the description?

>

Bug#976887: texlive-base: Should not migrate to testing for now.

[Hilmar Preuße]

Am 09.12.2020 um 00:07 teilte Hilmar Preusse mit:

Hi Norbert,


The new texlive-base has an impact on docbook based documentations,
see

If you intend to work on this: attached is what I call a minimal xml 
file. The file can be processed using "docbook2tex test.xml" to get the 
tex source code. The resulting file can be processed in Debian testing 
using "pdfjadetex test.tex" and one gets an pdf file.
The same fails on unstable w/ the known messages. The (intermediate) TeX 
input file are identical on testing and unstable.


Hence I'd assume the issue is in some changes in the LaTeX kernel. 
Testing has "LaTeX2e <2020-02-02> patch level 5" unstable is "LaTeX2e 
<2020-10-01> patch level 2".


Hilmar
--
sigfault


http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd; [

]>

  Box Backup administrator's guide

  
Configuration


  System configuration

  
Server

After you've downloaded and compiled the programs you need to
install the programs on your server. As root do the following:

  


  



OpenPGP_signature
Description: OpenPGP digital signature

Bug#976799: [pkg-php-pear] Bug#976799: Please update php-doctrine-inflector autoloader’s path

[David Prévot]

Hi Robin,

Le 08/12/2020 à 19:41, Robin Gustafsson a écrit :


Looks like you’ve made a nice script to generate the autoload.php files
for the binary packages! It would be awesome to make something like that
part of pkg-php-tools

[…]

Sounds good to me! I'll look into contributing an improved/generalized
version to pkg-php-tools when I find the time.


Great! Feel free to push a WIP branch when you’ll have something ready 
for us to test and eventually help with.


[…]

Could you please test that your packages work correctly with this patch
and the php-doctrine-inflector package from experimental?



I've tested it now and it seems to be all good.


If all goes well, I intend to upload php-doctrine-[stuff] >> [from] 
experimental). It would be nice to have an updated
php-laravel-framework uploaded in sync too

[…]

I'm fine with this. My ability to sync the upload is limited though as
I cannot upload packages myself. If you have the time, you could
upload this change too of course.


Sure, I’m happy to fix my mess ;). I’ll assume the repository on salsa 
is up to date and ready for upload (if not, please come back to me as 
soon as you can, hopefully before the weekend). As everything /seems/ 
ready, I hope to take care of the final bits of this 
php-doctrine-[stuff] update this weekend.


Regards

David

Bug#960788: Intel SOF audio firmware packaging

[James Healy]

Lovely, that worked. After a reboot and un-muting in alsamixer, the
laptop speakers work great.

cheers,
James

On Thu, 10 Dec 2020 at 09:22, Barak A. Pearlmutter
 wrote:
>
> No need for anything so complex. This should work:
>
> $ fakeroot debian/rules binary
>
> Or sudo if you don't have fakeroot.

Bug#977004: Please enable CONFIG_ATH11K for the XPS 13 9310

[Paul Tagliamonte]

Package: linux
Severity: wishlist
thanks

Hello Linux maintainers,

The spiffy new Dell XPS 13 9310 is shipping, but is not sold as supporting
linux yet -- but appears to work great, with the exception of the Qualcomm
Technologies 802.11ax chipset.

I installed Linux from experimental, and am able to confirm the driver is
not loaded. I believe CONFIG_ATH11K could be enabled to support this
platform.

Happy to reproduce and/or try images out to confirm! This isn't a daily
machine yet.

Thank you very much!
  Paul

Bug#976405: texlive-latex-base: pdflatex command fails while building doxygen

[Hilmar Preuße]

Control: reassign -1 src:doxygen

Am 04.12.2020 um 18:40 teilte Paolo Greppi mit:

Hi Paolo,


doxygen FTBFS due to a failure to run pdflatex.

See this recent salsa build:
https://salsa.debian.org/debian/doxygen/-/jobs/1213110

The error is:

   /usr/bin/pdflatex: Not writing to 
../html/examples/group/latex//group__group2.aux (openout_any = p).
   make[4]: *** [doc/CMakeFiles/doxygen_pdf.dir/build.make:81: 
doc/CMakeFiles/doxygen_pdf] Error 1


I attach the complete pdflatex log file.

I am no latex expert, so this could well be a doxygen issue.
Can you advise ? thanks in advance,

As explained this issue is probably not related to changed in TL base, 
hence I'm reassigning to src:doxygen .


For the other build failures, w/ docbook based documents I've opened 
Bug#976887 w/ criticality serious to make sure the new TL packages do 
not migrate to testing until the issue is sorted out.


Hilmar
--
sigfault






OpenPGP_signature
Description: OpenPGP digital signature

Bug#974646: W: Possible missing firmware /lib/firmware/i915/rkl_dmc_ver2_01.bin for module i915

[Markus Koller]

Was wondering about this error as well, looks like it's a benign warning
and can be ignored:
https://unix.stackexchange.com/questions/618869/debian-bullseye-firmware-for-i915

> rkl is apparently Rocket Lake, the codename for an Intel chipset that is
> supposed to be released in early 2021.
>  So this is the Linux i915
> driver already getting support for hardware that is not released yet.
>
> The i915 driver covers a wide range of Intel iGPUs, including all the
> current ones and sometimes even near-future ones if they follow a design
> similar to their predecessors.
>
> The kernel modules like i915 include metadata indicating the firmware
> files they *may* need: the i915 module needs to declare the firmware
> files for all supported Intel iGPU versions this way.
>
> The update-initramfs tool is not smart enough to cross-check the hardware
> information to find out which of the various firmware files declared by the
> i915 driver are *actually needed* by your hardware, so it will simply
> attempt to include all of them into initramfs.
>
> Unless you have installed firmware files for *all* the Intel iGPU
> variants, you may get some nuisance messages from update-initramfs; but
> if they don't refer to the iGPU/chipset version you're actually using, you
> can simply ignore them.
>

Bug#976366: Upgrade to 247 broke keyboard input on Wayland session

[Michael Biebl]

Am 08.12.20 um 16:07 schrieb Michael Biebl:

Am 08.12.20 um 06:14 schrieb Marc Dequènes (duck):
I was wondering what make my system so peculiar and stumbled onto this 
bug report:

   https://github.com/ckb-next/ckb-next/issues/671

I haven't tried the ckb-next git version yet but it seems strange that 
simply presenting a device's features differently would break things. 
If there is a problem in udev or libinput I think it would be good to 
track before jumping to an easy workaround. So I'm not reassigning yet 
and I'd be happy to have your input.




Interesting find. That might indeed explain why I was not able to 
reproduce the issue (and why we were not flooded with bug reports from 
other users).
I'm not too familiar with the input stack myself, to conclude where this 
should be handled.

One significant change in systemd 247 is
https://lwn.net/Articles/837033/

It might be, that ckb-next is affected by this, especially when it deals 
with handling/creating (input) devices.


I'm inclined to reassign this to ckb-next. WDYT?

Bug#976405: texlive-latex-base: pdflatex command fails while building doxygen

[Hilmar Preuße]

reassign -1 src:doxygen

Am 04.12.2020 um 18:40 teilte Paolo Greppi mit:

Hi Paolo,


doxygen FTBFS due to a failure to run pdflatex.

See this recent salsa build:
https://salsa.debian.org/debian/doxygen/-/jobs/1213110

The error is:

   /usr/bin/pdflatex: Not writing to 
../html/examples/group/latex//group__group2.aux (openout_any = p).
   make[4]: *** [doc/CMakeFiles/doxygen_pdf.dir/build.make:81: 
doc/CMakeFiles/doxygen_pdf] Error 1


I attach the complete pdflatex log file.

I am no latex expert, so this could well be a doxygen issue.
Can you advise ? thanks in advance,

As explained this issue is probably not related to changed in TL base, 
hence I'm reassigning to src:doxygen .


For the other build failures, w/ docbook based documents I've opened 
Bug#976887 w/ criticality serious to make sure the new TL packages do 
not migrate to testing until the issue is sorted out.


Hilmar
--
sigfault




OpenPGP_signature
Description: OpenPGP digital signature

Bug#972645: gnome-builder does not start without flatpak package installed

[nodiscc]

Hello,

> This might mean that gnome-builder has an undeclared dependency on
something else that is depended on by flatpak.

I just ran sudo apt purge flatpak, which resulted in flatpak* and
flatpak-builder*
being removed. After this, I can reproduce the problem again (crash at
startup)

> Those look like messages from gdb?

It seems related as after uninstalling gdb, I no longer get these messages.
Instead:

$ gnome-builder
Segmentation fault

> If you create a new user account on the same system (so your home
> directory and personal configuration are not in use), can you run
> gnome-builder successfully as that user?

No, it also crashes with the same error messages

Bug#976973: RFS: fonts-aenigma/0.0.20080510.dfsg-3 -- 465 free TrueType fonts by Brian Kent

[martin f krafft]

* License : madduck-special-license 


I am very thankful for Gürkan to take over this very cool collection 
of fonts, and I stand by to answer any questions about its history 
or this "madduck-special-licence" (happy for that to be renamed, but 
don't care either way).


If you don't find a sponsor, I'll upload this too, but give it a few 
days, ok?


--
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#960788: Intel SOF audio firmware packaging

[Barak A. Pearlmutter]

No need for anything so complex. This should work:

$ fakeroot debian/rules binary

Or sudo if you don't have fakeroot.

Bug#953415: Now gitlab work with newer version of libsass?

[Dragos Jarca]

Hi

Some news about this bug?

There are a lot of packages that depend of libsass and I cannot install 
updates because use libsass 3.6.1 because of gitlab workaround.


Now gitlab work with newer version of libsass?

--
Best regards,
Dragos Jarca
General manager
Dynamic Puzzle S.R.L.
www.dynamicpuzzle.ro

Bug#976996: qemu-system: qemu doesn't support video mode qxl anymore and fails to load spice libraries

[Michael Tokarev]

09.12.2020 23:14, bauen1 wrote:

Package: qemu-system
Version: 1:5.2+dfsg-1
Severity: important
X-Debbugs-Cc: j24...@gmail.com

Dear Maintainer,

I've just upgraded qemu-system and related packages, now I can't launch any 
libvirt virtual machiness with the virtual machine manager frontend anymore.
It appears that this is caused by qemu no longer being build with support for 
the qxl video mode, or at least not advertising it anymore.
When ran with spice qemu now also fails to load the 
/usr/lib/x86_64-linux-gnu/qemu/ui-spice-core.so library due to unresolved 
symbols `console_gl_check_format`.


This missing symbol is in /usr/lib/x86_64-linux-gnu/qemu/ui-opengl.so module
which is shipped in qemu-system-gui package. This is a bug indeed, this module
should be in qemu-system-common, but this bug is relatively easy to work around
(yes, installing this package pulls quite a few X11 libraries).

I'll fix it tomorrow.

BTW, why do you have installed whole qemu-system, are you using all of them?
Just curious.

Thanks,

/mjt

Bug#973610: Install from buster-backports

[Michael Fladischer]

Hi Kimiaki,

the "cairosvg" package is only available in buster-backports on your 
installation. So when running "apt install cairosvg" you are 
automatically selecting cairosvg-2.4.2-1~bpo10+1 from the 
buster-backports archive.


python3-cairosvg is not found because you told apt to only use the main 
archive. Instead please run:


apt -t buster-backports install cairosvg

Regards,
Michael

Bug#972789: qemu: FTBFS on arm{el,hf}: /<>/linux-user/m68k/signal.c:44:1: error: ‘TYPE_CANONICAL’ is not compatible

[Michael Tokarev]

On Wed, 28 Oct 2020 12:30:41 +0100 Sebastian Ramacher  
wrote:

On 2020-10-24 07:38:39 +0300, Michael Tokarev wrote:

...

> Hmm. So this looks like a gcc ICE bug. Here's the code in question:
> ...
> > | /<>/linux-user/m68k/signal.c:44:1: internal compiler error: 
‘verify_type’ failed
> 
> I'm not sure what I have to do with this, besides reassigning it to gcc.
> 
> BTW, symbol TYPE_CANONICAL is not used/referenced by qemu sources.


Indeed, that's a bug in gcc which was already reported upstream.
Reassigning accordingly.


I dunno what happened, either it was new gcc or new qemu, but this issue
is gone - as of today's upload of qemu 5.2 it built successfully on both
armhf and armel.

Guess we can close this bugreport, what do you think?

/mjt

Bug#960788: Intel SOF audio firmware packaging

[James Healy]

Thanks Barak,

I'm keen to try your repo to build a package for my Lenovo X1 Carbon,
but my debian packaging skills are a few years out of date.

Should I use dpkg-buildpackage? Or maybe gbp buildpackage?

James

On Thu, 10 Dec 2020 at 04:36, Barak A. Pearlmutter
 wrote:
>
> My Dell Inspiron 7591 2n1 required the SOF audio firmware, so I did a
> quick packaging for my own purposes, to be sure I had the latest. See
>
>  https://github.com/barak/sof-bin
>  branch: debian
>
> Works for me, and of course my packaging scripts are free for use in
> whole or in part etc (I hereby place them in the public domain.)
>
> Cheers,
>
> --Barak.
>
> --
> To unsubscribe, send mail to 960788-unsubscr...@bugs.debian.org.

Bug#779269: opensmtpd boot issues

[Ryan Kavanagh]

Control: tags -1 + moreinfo

Dear David, Harald,

I wanted to follow up and see if you were still having issues with
opensmtpd not starting at boot.

Could you please update the init script to start smtpd with the -v flag,
and send me the verbose startup output for smtpd after a reboot?

I think it should be sufficient to apply the attached patch to
/etc/init.d/opensmtpd before rebooting. The output should be in
/var/log/mail.log .

I suspect this bug might be related to this one:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976194

Thanks,
Ryan

-- 
|)|/  Ryan Kavanagh  | GPG: 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac |  BD95 8F7B F8FC 4A11 C97A


signature.asc
Description: PGP signature

Bug#977002: Python3 version available

[Michael Reed]

Package: gjots2
Version: 3.0.2-0.1

gjots2 is stuck here at an old version that is python2 and therefore
dropped from testing.  Upstream has v3.1+ available that has been
converted to python3.

Bug#834822: Opensmtpd charset issue

[Ryan Kavanagh]

Control: tags -1 + moreinfo unreproducible

Hi Xavier,

I wasn't able to reproduce this bug when you filed it, and I still can't
seem to reproduce it. Are you still experiencing it?

Thanks,
Ryan

-- 
|)|/  Ryan Kavanagh  | GPG: 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac |  BD95 8F7B F8FC 4A11 C97A


signature.asc
Description: PGP signature

Bug#977003: blitz++: reproducible builds: Embeded kernel version and hostname in bzconfig.h

[Vagrant Cascadian]

Source: blitz++
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: uname hostname
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The file /usr/include/blitz/gnu/bzconfig.h contains the running kernel
version and hostname of the system:

  
https://tests.reproducible-builds.org/debian/issues/captures_kernel_version_issue.html

  425   
#define·BZ__os_name·"Linux·ionos1-amd64·4.19.0-13-amd64·#1·SMP·Debian·4.19.160-2·(2020-11-28)·x86_64·GNU/Linux"·

  425   
#define·BZ__os_name·"Linux·i-capture-the-hostname·5.9.0-0.bpo.2-amd64·#1·SMP·Debian·5.9.6-1~bpo10+1·(2020-11-19)·x86_64·GNU/Linux"·

The attached patch fixes this by using dpkg-architecture's multiarch
value instead of using "uname -a".  It looks like this is just data
embedded in the built bzconfig.h file, but I do not know if this results
in other issues, so someone more familiar with blitz++ should test that
the change is valid.


This also depends on the previously submitted patch for timestamps,
although would be easy to refactor it independently if for some reason
the timestamp patch could not be applied.

With both patches applied blitz++ should build reproducibly once it
reaches bullseye where the build path is not varied between builds,
although unstable also varies the build path which results in additional
issues.


Thanks for maintaining blitz++


live well,
  vagrant

From 4d577dd6b8f56f6c9f55e0a494809eff99ba2362 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Wed, 9 Dec 2020 21:37:47 +
Subject: [PATCH 2/2] debian/patches: Set OS using dpkg-architectue multiarch
 value to avoid embedding running kernel version.

https://tests.reproducible-builds.org/debian/issues/captures_kernel_version_issue.html
---
 ...g-architectue-multiarch-value-to-avo.patch | 27 +++
 debian/patches/series |  1 +
 2 files changed, 28 insertions(+)
 create mode 100644 debian/patches/Set-OS-using-dpkg-architectue-multiarch-value-to-avo.patch

diff --git a/debian/patches/Set-OS-using-dpkg-architectue-multiarch-value-to-avo.patch b/debian/patches/Set-OS-using-dpkg-architectue-multiarch-value-to-avo.patch
new file mode 100644
index 000..b17d20e
--- /dev/null
+++ b/debian/patches/Set-OS-using-dpkg-architectue-multiarch-value-to-avo.patch
@@ -0,0 +1,27 @@
+From b2f583f708e2bcbd12a8c1cfae659e9af4c0d211 Mon Sep 17 00:00:00 2001
+From: Vagrant Cascadian 
+Date: Wed, 9 Dec 2020 21:27:23 +
+Subject: [PATCH 2/2] Set OS using dpkg-architectue multiarch value to avoid
+ embedding running kernel version.
+
+https://tests.reproducible-builds.org/debian/issues/captures_kernel_version_issue.html
+---
+ m4/ac_check_cxx_features.m4 | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/m4/ac_check_cxx_features.m4 b/m4/ac_check_cxx_features.m4
+index 3a8a274..be80516 100644
+--- a/m4/ac_check_cxx_features.m4
 b/m4/ac_check_cxx_features.m4
+@@ -7,7 +7,7 @@ C++ compiler ($CXX $CXXFLAGS $LDFLAGS) characteristics
+ 
+ ])
+ 
+-OS=`uname -a`
++OS=`dpkg-architecture -qDEB_HOST_MULTIARCH`
+ AC_SUBST(OS)
+ DATE=`LC_ALL=C date --utc --date=@$SOURCE_DATE_EPOCH`
+ AC_SUBST(DATE)
+-- 
+2.29.2
+
diff --git a/debian/patches/series b/debian/patches/series
index b37ff35..12606e2 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -5,3 +5,4 @@ debianization-python.patch
 debianization-examples.patch
 debianization-examples-neutralization.patch
 Specify-DATE-using-SOURCE_DATE_EPOCH-in-m4-ac_check_.patch
+Set-OS-using-dpkg-architectue-multiarch-value-to-avo.patch
-- 
2.29.2



signature.asc
Description: PGP signature

Bug#977001: blitz++: reproducible builds: build time embedded in bzconfig.h

[Vagrant Cascadian]

Source: blitz++
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The file /usr/include/blitz/gnu/bzconfig.h contains an embedded timestamp:

  
https://tests.reproducible-builds.org/debian/rb-pkg/buster/amd64/diffoscope-results/blitz++.html

  421 #define·BZ__config_date·"Sun·Dec··6·02:21:14·-12·2020"·   421 
#define·BZ__config_date·"Sun·Jan··9·11:08:27·+14·2022"·


The attached patch fixes this by patching to use the SOURCE_DATE_EPOCH
environment variable to set the value for DATE.

  https://reproducible-builds.org/docs/source-date-epoch/

The patch relies on gnu date extensions/syntax (--utc, --date) and may
need further work to make it portable across multiple date
implementations for upstream.


Thanks for maintaining blitz++


live well,
  vagrant

From 15a9ee2e96ae41bceb9b7aba4e90f5209d34355f Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Wed, 9 Dec 2020 21:36:25 +
Subject: [PATCH 1/2] debian/patches: Patch to use SOURCE_DATE_EPOCH to set
 DATE.

https://reproducible-builds.org/docs/source-date-epoch/
---
 ...ng-SOURCE_DATE_EPOCH-in-m4-ac_check_.patch | 30 +++
 debian/patches/series |  1 +
 2 files changed, 31 insertions(+)
 create mode 100644 debian/patches/Specify-DATE-using-SOURCE_DATE_EPOCH-in-m4-ac_check_.patch

diff --git a/debian/patches/Specify-DATE-using-SOURCE_DATE_EPOCH-in-m4-ac_check_.patch b/debian/patches/Specify-DATE-using-SOURCE_DATE_EPOCH-in-m4-ac_check_.patch
new file mode 100644
index 000..d49c49c
--- /dev/null
+++ b/debian/patches/Specify-DATE-using-SOURCE_DATE_EPOCH-in-m4-ac_check_.patch
@@ -0,0 +1,30 @@
+From 2175a0ad78db56f50f22a0483f6e249ecf17e14c Mon Sep 17 00:00:00 2001
+From: Vagrant Cascadian 
+Date: Wed, 9 Dec 2020 21:25:18 +
+Subject: [PATCH 1/2] Specify DATE using SOURCE_DATE_EPOCH in
+ m4/ac_check_cxx_features.m4 for reproducible timestamp.
+
+This uses the gnu date features of --date and --utc, so may not be
+widely portable.
+
+https://reproducible-builds.org/docs/source-date-epoch/
+---
+ m4/ac_check_cxx_features.m4 | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/m4/ac_check_cxx_features.m4 b/m4/ac_check_cxx_features.m4
+index abd6916..3a8a274 100644
+--- a/m4/ac_check_cxx_features.m4
 b/m4/ac_check_cxx_features.m4
+@@ -9,7 +9,7 @@ C++ compiler ($CXX $CXXFLAGS $LDFLAGS) characteristics
+ 
+ OS=`uname -a`
+ AC_SUBST(OS)
+-DATE=`date`
++DATE=`LC_ALL=C date --utc --date=@$SOURCE_DATE_EPOCH`
+ AC_SUBST(DATE)
+ 
+ AH_TOP([
+-- 
+2.29.2
+
diff --git a/debian/patches/series b/debian/patches/series
index 24132a8..b37ff35 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -4,3 +4,4 @@ debianization.patch
 debianization-python.patch
 debianization-examples.patch
 debianization-examples-neutralization.patch
+Specify-DATE-using-SOURCE_DATE_EPOCH-in-m4-ac_check_.patch
-- 
2.29.2



signature.asc
Description: PGP signature

Bug#977000: python3-apt: dak crashes after security update

[Ansgar]

Package: python3-apt
Version: 1.8.4.2
Severity: grave
Tags: security
Justification: renders package unusable

dak crashes with a segmentation fault in python3-apt when processing
uploads or processing the NEW queue on ftp-master; and also on my
playground server (used to generate the backtrace).

$ gdb --batch -n -ex 'set pagination off' -ex run -ex bt -ex 'bt full' \
-args /usr/bin/python3 ~dak/dak/dak/dak.py examine-package \
python3-apt_1.8.4.2_amd64.deb &> dak-segfault.txt

produced the attached backtrace.

The problematic line seems to be:

+---
| return apt_inst.DebFile(fh).control.extractdata("control")
+---[ 
https://salsa.debian.org/ftp-team/dak/-/blob/891420d6c0c46472f25585ac05760dabc84e74ad/daklib/utils.py#L939
 ]

and indeed

$ gdb --args python3 -c 'import apt_inst; 
apt_inst.DebFile(open("python3-apt_1.8.4.2_amd64.deb")).control.extractdata("control")'

also reproduces the segmentation fault.

Ansgar

-- System Information:
Debian Release: 10.7
Architecture: amd64 (x86_64)

Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages python3-apt depends on:
ii  libapt-inst2.0 1.8.2.2
ii  libapt-pkg5.0  1.8.2.2
ii  libc6  2.28-10
ii  libgcc11:8.3.0-6
ii  libstdc++6 8.3.0-6
ii  python-apt-common  1.8.4.2
ii  python33.7.3-1

Versions of packages python3-apt recommends:
pn  iso-codes
pn  lsb-release  

Versions of packages python3-apt suggests:
ii  apt  1.8.2.2
pn  python-apt-doc   
ii  python3-apt-dbg  1.8.4.2

-- no debconf information
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Detaching after fork from child process 1948]

Program received signal SIGSEGV, Segmentation fault.
0x768b90e6 in ararchive_new (type=0x768c00a0 , 
args=, kwds=) at /usr/include/c++/8/new:169
169 { return __p; }
#0  0x768b90e6 in ararchive_new (type=0x768c00a0 , 
args=, kwds=) at /usr/include/c++/8/new:169
#1  0x768b973d in debfile_new (type=type@entry=0x768c00a0 
, args=args@entry=(<_io.TextIOWrapper at remote 
0x75a461f8>,), kwds=kwds@entry=0x0) at python/arfile.cc:613
#2  0x005ce067 in type_call (kwds=0x0, args=(<_io.TextIOWrapper at 
remote 0x75a461f8>,), type=0x768c00a0 ) at 
../Objects/typeobject.c:929
#3  _PyObject_FastCallKeywords (callable=, 
stack=0x75a89a10, nargs=, kwnames=) at 
../Objects/call.c:199
#4  0x0053ed81 in call_function (pp_stack=0x7fffd7b0, 
oparg=, kwnames=) at ../Python/ceval.c:4619
#5  0x0054653a in _PyEval_EvalFrameDefault (f=, 
throwflag=) at ../Python/ceval.c:3093
#6  0x005cd68c in PyEval_EvalFrameEx (throwflag=0, f=Frame 
0x75a89890, for file /mnt/data/srv/dak/dak/daklib/utils.py, line 939, in 
deb_extract_control (fh=<_io.TextIOWrapper at remote 0x75a461f8>)) at 
../Python/ceval.c:547
#7  function_code_fastcall (globals=, nargs=, 
args=, co=) at ../Objects/call.c:283
#8  _PyFunction_FastCallKeywords (func=, stack=, 
nargs=, kwnames=) at ../Objects/call.c:408
#9  0x0053ebb0 in call_function (pp_stack=0x7fffd990, 
oparg=, kwnames=) at ../Python/ceval.c:4616
#10 0x0054653a in _PyEval_EvalFrameDefault (f=, 
throwflag=) at ../Python/ceval.c:3093
#11 0x005cd68c in PyEval_EvalFrameEx (throwflag=0, f=Frame 0xedcd38, 
for file /mnt/data/srv/dak/dak/dak/examine_package.py, line 261, in 
read_control (filename='python3-apt_1.8.4.2_amd64.deb', recommends=[], 
predepends=[], depends=[], section='', maintainer='', arch='', 
deb_file=<_io.TextIOWrapper at remote 0x75a461f8>)) at ../Python/ceval.c:547
#12 function_code_fastcall (globals=, nargs=, 
args=, co=) at ../Objects/call.c:283
#13 _PyFunction_FastCallKeywords (func=, stack=, 
nargs=, kwnames=) at ../Objects/call.c:408
#14 0x0054207c in call_function (kwnames=0x0, oparg=, 
pp_stack=) at ../Python/ceval.c:4616
#15 _PyEval_EvalFrameDefault (f=, throwflag=) at 
../Python/ceval.c:3124
#16 0x0053f732 in PyEval_EvalFrameEx (throwflag=0, f=Frame 0xee9778, 
for file /mnt/data/srv/dak/dak/dak/examine_package.py, line 444, in 
output_deb_info (suite='unstable', filename='python3-apt_1.8.4.2_amd64.deb', 
packagename='python3-apt', session=None)) at ../Python/ceval.c:547
#17 _PyEval_EvalCodeWithName (_co=, globals=, 
locals=, args=, argcount=, 
kwnames=0x0, kwargs=0xe93838, kwcount=, kwstep=1, 
defs=0x75a4a2c8, defcount=1, kwdefs=0x0, closure=0x0, 
name='output_deb_info', qualname='output_deb_info') at ../Python/ceval.c:3930
#18 0x005cd982 in _PyFunction_FastCallKeywords (func=, 
stack=0xe93818, nargs=4, kwnames=) at ../Objects/call.c:433
#19 0x0054207c in call_function (kwnames=0x0, oparg=, 
pp_stack=) at ../Python/ceval.c:4616
#20 _PyEval_EvalFrameDefault (f=, throwflag=) at 

Bug#976991: libldap-2.4-2:amd64: Please consider building with openssl instead of gnutls

[Quanah Gibson-Mount]

I read over the source of the rlm_ldap module and the freeradius 
src/lib/ldap code, and it does specifically require functionality that's 
only implemented for OpenSSL inside of libldap (such as the TLS Min 
protocol) that are ignored for GnuTLS.


So for freeradius to work with a GnuTLS compiled libldap would require 
modifying the freeradius source code accordingly, which may be a bit of 
work.  It also seems unlikely the freeradius project would be interested in 
taking any such work back as they are only implementing on OpenSSL.


The best solution long term may simply be to switch to OpenSSL for OpenLDAP 
starting with the 2.5 release series in Debian.


Regards,
Quanah

--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:

Bug#976194: opensmtpd: Fails to start on boot with systemd

[Ryan Kavanagh]

Control: forwarded -1 https://github.com/OpenSMTPD/OpenSMTPD/issues/1106

On Wed, Dec 09, 2020 at 04:05:02PM +0100, Yvan Masson wrote:
> Le 09/12/2020 à 13:54, Ryan Kavanagh a écrit :
> > Dear Yvan,
> > 
> > On Tue, Dec 01, 2020 at 11:46:08AM +0100, Yvan Masson wrote:
> > >smtpd[473]: pony express: listen: Address already in use
> > 
> > Could you please send me a copy of /etc/smtpd.conf? In particular, I'm
> > curious what "listen on" stanzas you have?
> 
> I have a very simple configuration:
> 
> listen on localhost
>
> [...]
>
> déc. 09 15:56:56 myserver smtpd[463]: debug: smtp: listen on 127.0.0.1 port 
> 25 flags 0x400 pki "" ca ""
> déc. 09 15:56:56 myserver smtpd[463]: debug: smtp: listen on 127.0.0.1 port 
> 25 flags 0x400 pki "" ca ""

Interesting: smtpd tries to listen on 127.0.0.1 twice. I can reproduce
this by adding two identical entries to my /etc/hosts, i.e., by having

127.0.0.1   localhost
127.0.0.1   localhost

in my /etc/hosts. By any chance, does your /etc/hosts contain multiple
entries for localhost? In any case, I'll forward this bug upstream now
that I can reproduce it.

Best,
Ryan

-- 
|)|/  Ryan Kavanagh  | GPG: 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac |  BD95 8F7B F8FC 4A11 C97A


signature.asc
Description: PGP signature

Bug#976996: qemu-system: qemu doesn't support video mode qxl anymore and fails to load spice libraries

[Stefan Pietsch]

On 12/9/20 8:14 PM, bauen1 wrote:

Package: qemu-system
Version: 1:5.2+dfsg-1
Severity: important
X-Debbugs-Cc: j24...@gmail.com

Dear Maintainer,

I've just upgraded qemu-system and related packages, now I can't launch any 
libvirt virtual machiness with the virtual machine manager frontend anymore.
It appears that this is caused by qemu no longer being build with support for 
the qxl video mode, or at least not advertising it anymore.
When ran with spice qemu now also fails to load the 
/usr/lib/x86_64-linux-gnu/qemu/ui-spice-core.so library due to unresolved 
symbols `console_gl_check_format`.

This appears to be a regression from 1:5.1+dfsg-4+b2


I can confirm this.

Steps to reproduce:

$ qemu-system-x86_64 -vga qxl
Failed to open module: /usr/lib/x86_64-linux-gnu/qemu/ui-spice-core.so: 
undefined symbol: console_gl_check_format
Failed to open module: /usr/lib/x86_64-linux-gnu/qemu/hw-display-qxl.so: 
undefined symbol: qemu_spice_cursor_refresh_bh
qemu-system-x86_64: QXL VGA not available


To use "vga qxl" you have to downgrade to 1:5.1+dfsg-4.

Bug#971209: rust-redox-syscall: FTBFS: dh_auto_test: error: /usr/share/cargo/bin/cargo build returned exit code 101

[Paul Gevers]

Hi

On Sun, 27 Sep 2020 20:57:05 +0200 Lucas Nussbaum  wrote:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.

And it failed on all buildd's too. Your package is a key package and we
are getting close to the freeze. Can you please look into this and
upload a fix?

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#970463: rust-log: autopkgtest regression can't find crate for `serde_test`

[Paul Gevers]

Hi,

On Wed, 16 Sep 2020 21:14:24 +0200 Paul Gevers  wrote:
> With a recent upload of rust-log the autopkgtest of rust-log fails in
> testing when that autopkgtest is run with the binary packages of
> rust-log from unstable. It passes when run with only packages from
> testing. In tabular form:
> 
>passfail
> rust-log   from testing0.4.11-1
> all others from testingfrom testing
> 
> Currently this regression is blocking the migration to testing [1]. Can
> you please investigate the situation and fix it?

You package is a key package and we're getting close to the freeze. Can
you please fix the situation here? Worse case, just disable the
autopkgtest please.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#976999: libfastahack: make .symbols file more resilient in handling of template symbols

[Steve Langasek]

Package: libfastahack
Version: 1.0.0+dfsg-6
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu hirsute ubuntu-patch

Hi Andreas,

The libfastahack package has been failing to build on ppc64el in Ubuntu due
to mismatched symbols file.  This is probably due to the fact that Ubuntu
builds all packages on ppc64el with -O3 by default, causing some symbols to
be inlined and optimized out of the symbol table.

Surprisingly, this build failure also includes some symbols that are *added*
on ppc64el relative to other architectures, which I can't say I've ever seen
before.  However, since these are also template symbols, they are irrelevant
to the ABI and can safely be marked as optional as well.

Please find attached a patch that allows the libfastahack build to succeed
on ppc64el in Ubuntu.

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 libfastahack-1.0.0+dfsg/debian/libfastahack0.symbols 
libfastahack-1.0.0+dfsg/debian/libfastahack0.symbols
--- libfastahack-1.0.0+dfsg/debian/libfastahack0.symbols2020-07-23 
05:51:27.0 -0700
+++ libfastahack-1.0.0+dfsg/debian/libfastahack0.symbols2020-12-09 
12:51:45.0 -0800
@@ -32,11 +32,14 @@
  _ZN15FastaIndexEntryD1Ev@Base 0.0+git20160702.bbc645f
  _ZN15FastaIndexEntryD2Ev@Base 0.0+git20160702.bbc645f
  _ZNKSt5ctypeIcE8do_widenEc@Base 0.0+git20160702.bbc645f
+ 
(optional)_ZNSt12_Destroy_auxILb0EE9__destroyIPNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEvT_S9_@Base
 1.0.0+dfsg
+ 
(optional)_ZNSt4pairINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE15FastaIndexEntryED1Ev@Base
 1.0.0+dfsg
+ 
(optional)_ZNSt4pairINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE15FastaIndexEntryED2Ev@Base
 1.0.0+dfsg
  
_ZNSt6vectorI15FastaIndexEntrySaIS0_EE17_M_realloc_insertIJRKS0_EEEvN9__gnu_cxx17__normal_iteratorIPS0_S2_EEDpOT_@Base
 0.0+git20160702.bbc645f
  
_ZNSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS5_EE17_M_realloc_insertIJRKS5_EEEvN9__gnu_cxx17__normal_iteratorIPS5_S7_EEDpOT_@Base
 0.0+git20160702.bbc645f
  
(optional)_ZNSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS5_EE17_M_realloc_insertIJS5_EEEvN9__gnu_cxx17__normal_iteratorIPS5_S7_EEDpOT_@Base
 0.0+git20160702.bbc645f
- 
_ZNSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS5_EEC1ERKS7_@Base
 1.0.0+dfsg
- 
_ZNSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS5_EEC2ERKS7_@Base
 1.0.0+dfsg
+ 
(optional)_ZNSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS5_EEC1ERKS7_@Base
 1.0.0+dfsg
+ 
(optional)_ZNSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS5_EEC2ERKS7_@Base
 1.0.0+dfsg
  
_ZNSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS5_EED1Ev@Base
 0.0+git20160702.bbc645f
  
_ZNSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS5_EED2Ev@Base
 0.0+git20160702.bbc645f
  
_ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_15FastaIndexEntryESt10_Select1stIS9_ESt4lessIS5_ESaIS9_EE17_M_emplace_uniqueIJS6_IS5_S8_S6_ISt17_Rb_tree_iteratorIS9_EbEDpOT_@Base
 0.0+git20160702.bbc645f
@@ -48,7 +51,7 @@
  
_ZSt13__heap_selectIN9__gnu_cxx17__normal_iteratorIP15FastaIndexEntrySt6vectorIS2_SaIS2_NS0_5__ops15_Iter_comp_iterIPFbS2_S2_vT_SD_SD_T0_@Base
 1.0.0+dfsg
  
_ZSt16__insertion_sortIN9__gnu_cxx17__normal_iteratorIP15FastaIndexEntrySt6vectorIS2_SaIS2_NS0_5__ops15_Iter_comp_iterIPFbS2_S2_vT_SD_T0_@Base
 0.0+git20160702.bbc645f
  
_ZSt16__introsort_loopIN9__gnu_cxx17__normal_iteratorIP15FastaIndexEntrySt6vectorIS2_SaIS2_lNS0_5__ops15_Iter_comp_iterIPFbS2_S2_vT_SD_T0_T1_@Base
 0.0+git20160702.bbc645f
- 
_ZSt22__move_median_to_firstIN9__gnu_cxx17__normal_iteratorIP15FastaIndexEntrySt6vectorIS2_SaIS2_NS0_5__ops15_Iter_comp_iterIPFbS2_S2_vT_SD_SD_SD_T0_@Base
 1.0.0+dfsg
+ 
(optional)_ZSt22__move_median_to_firstIN9__gnu_cxx17__normal_iteratorIP15FastaIndexEntrySt6vectorIS2_SaIS2_NS0_5__ops15_Iter_comp_iterIPFbS2_S2_vT_SD_SD_SD_T0_@Base
 1.0.0+dfsg
  
_ZSt25__unguarded_linear_insertIN9__gnu_cxx17__normal_iteratorIP15FastaIndexEntrySt6vectorIS2_SaIS2_NS0_5__ops14_Val_comp_iterIPFbS2_S2_vT_T0_@Base
 0.0+git20160702.bbc645f
  _ZlsRSoR10FastaIndex@Base 0.0+git20160702.bbc645f
  _ZlsRSoRK15FastaIndexEntry@Base 0.0+git20160702.bbc645f

Bug#969297: FTBFS: undefined reference to symbol 'pthread_join@@GLIBC_2.2.5'

[Gianfranco Costamagna]

control: tags -1 patch pending

--- kopanocore-8.7.0/debian/changelog   2020-03-15 11:05:50.0 +0100
+++ kopanocore-8.7.0/debian/changelog   2020-12-09 22:02:13.0 +0100
@@ -1,3 +1,10 @@
+kopanocore (8.7.0-7.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Fix build by linking correctly pthread (Closes: #969297)
+
+ -- Gianfranco Costamagna   Wed, 09 Dec 2020 
22:02:13 +0100
+
 kopanocore (8.7.0-7) unstable; urgency=medium
 
   [ Matthias Klose ]
diff -Nru kopanocore-8.7.0/debian/patches/fix-build.patch 
kopanocore-8.7.0/debian/patches/fix-build.patch
--- kopanocore-8.7.0/debian/patches/fix-build.patch 1970-01-01 
01:00:00.0 +0100
+++ kopanocore-8.7.0/debian/patches/fix-build.patch 2020-12-09 
22:02:11.0 +0100
@@ -0,0 +1,16 @@
+Description: Fix build by linking pthread
+Author: Gianfranco Costamagna 
+Bug-Debian: https://bugs.debian.org/969297
+Last-Update: 2020-12-09
+
+--- kopanocore-8.7.0.orig/Makefile.am
 kopanocore-8.7.0/Makefile.am
+@@ -769,7 +769,7 @@ dist_phpdata_DATA = \
+ kscriptrun_SOURCES = ECtools/scriptrun.cpp
+ mapitime_SOURCES = ECtools/mapitime.cpp
+ mapitime_LDADD = ${clock_LIBS} libmapi.la libkcutil.la \
+-  ${curl_LIBS} ${icu_uc_LIBS}
++  -lpthread ${curl_LIBS} ${icu_uc_LIBS}
+ rosie_test_SOURCES = librosie/test.cpp
+ rosie_test_LDADD = libkcrosie.la
+ tests_ablookup_SOURCES = tests/ablookup.cpp
diff -Nru kopanocore-8.7.0/debian/patches/series 
kopanocore-8.7.0/debian/patches/series
--- kopanocore-8.7.0/debian/patches/series  2020-02-02 13:08:39.0 
+0100
+++ kopanocore-8.7.0/debian/patches/series  2020-12-09 22:01:33.0 
+0100
@@ -31,3 +31,4 @@
 dbadm-pass-shared_ptr-KDatabase-consistently.patch
 dbadm-add-corrective-procedure-for-bug-KC-1444.patch
 freebusy-avoid-out-of-bounds-access-in-HrAddFBBlock.patch
+fix-build.patch


Done.

Bug#966680: src:acpica-unix: fails to migrate to testing for too long: FTBFS on s390x

[Paul Gevers]

Hi Al,

On Thu, 5 Nov 2020 22:26:08 +0100 Paul Gevers  wrote:
> Hi Al,
> 
> On 24-09-2020 18:57, Al Stone wrote:
> > Yup, working on it.  I may have to turn off s390x support for the
> > short term; the issue is that this package is solely little-endian
> > upstream and it has been patched and bodged so many times for
> > big-endian support, it has been become unmaintainable for big-
> > endian.  These patches are being re-done and made straightforward
> > but it is taking a lot longer than hoped; ideally, I can get them
> > upstreamed and simplify further.
> 
> In case you didn't notice; s390x is fixed now. The package FTBFS on
> armhf and mips64el.

Friendly ping.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#976975: vtk9 FTBFS with freetype 2.10.4

[Gianfranco Costamagna]

control: tags -1 patch

https://github.com/Kitware/VTK/commit/3edc0de2b04ae1e100c229e592d6b9fa94f2915a

This upstream commit should do the trick

G.

On Wed, 09 Dec 2020 16:19:41 +0200 Adrian Bunk  wrote:
> Source: vtk9
> Version: 9.0.1+dfsg1-2
> Severity: serious
> Tags: ftbfs
> 
> https://buildd.debian.org/status/package.php?p=vtk9
> 
> ...
> cd /<>/debian/build/Rendering/FreeType && /usr/bin/mpic++ 
> -DRenderingFreeType_EXPORTS -DVTK_IN_VTK 
> -I/<>/debian/build/Rendering/FreeType 
> -I/<>/Rendering/FreeType 
> -I/<>/debian/build/Common/Core -I/<>/Common/Core 
> -I/<>/debian/build/Common/ExecutionModel 
> -I/<>/Common/ExecutionModel 
> -I/<>/debian/build/Common/DataModel 
> -I/<>/Common/DataModel 
> -I/<>/debian/build/Common/Math -I/<>/Common/Math 
> -I/<>/debian/build/Common/Transforms 
> -I/<>/Common/Transforms 
> -I/<>/debian/build/Rendering/Core 
> -I/<>/Rendering/Core 
> -I/<>/debian/build/Filters/Core -I/<>/Filters/Core 
> -I/<>/debian/build/Common/Misc -I/<>/Common/Misc 
> -I/<>/debian/build/Filters/General 
> -I/<>/Filters/General -isystem 
> /<>/debian/build/Utilities/KWIML -isystem 
> /<>/Utilities/KWIML -isystem 
> /<>/debian/build/Utilities/KWSys -isystem 
> /<>/Utilities/KWSys -isystem 
> /<>/debian/build/ThirdParty/freetype -isystem 
> /<>/ThirdParty/freetype -isystem /usr/include/freetype2 -g -O2 
> -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2  -O2 -g -DNDEBUG 
> -Wnon-virtual-dtor -Wno-long-long -ansi -Wcast-align -Wchar-subscripts -Wall 
> -Wextra -Wpointer-arith -Wformat-security -Woverloaded-virtual -Wshadow 
> -Wunused-parameter -fno-check-new -fno-common -Werror=undef -fPIC 
> -fvisibility=hidden -fvisibility-inlines-hidden -std=c++11 -o 
> CMakeFiles/RenderingFreeType.dir/vtkFreeTypeTools.cxx.o -c 
> /<>/Rendering/FreeType/vtkFreeTypeTools.cxx
> /<>/Rendering/FreeType/vtkFreeTypeTools.cxx:382:1: error: 
> expected constructor, destructor, or type conversion before 
> ‘vtkFreeTypeToolsFaceRequester’
>   382 | vtkFreeTypeToolsFaceRequester(
>   | ^
> /<>/Rendering/FreeType/vtkFreeTypeTools.cxx: In member function 
> ‘virtual FT_Error vtkFreeTypeTools::CreateFTCManager()’:
> /<>/Rendering/FreeType/vtkFreeTypeTools.cxx:1154:61: error: 
> ‘vtkFreeTypeToolsFaceRequester’ was not declared in this scope; did you mean 
> ‘vtkFreeTypeToolsCleanupCounter’?
>  1154 | this->MaximumNumberOfSizes, this->MaximumNumberOfBytes, 
> vtkFreeTypeToolsFaceRequester,
>   | 
> ^
>   | 
> vtkFreeTypeToolsCleanupCounter
> make[4]: *** 
> [Rendering/FreeType/CMakeFiles/RenderingFreeType.dir/build.make:267: 
> Rendering/FreeType/CMakeFiles/RenderingFreeType.dir/vtkFreeTypeTools.cxx.o] 
> Error 1

Bug#974678: OpenH2634 also used to received

[Adam Cécile]

Hello,


OpenH264 is also used to receive H264 WebRTC streams. I can confirm this 
100% sure.



Adam.

Bug#972134: OpenH264 needed for WebRTC

[Adam Cécile]

Hello,


I can confirm OpenH264 is absolutely needed for both receiving and 
sending H264 WebRTC streams.


See my report here #974678


Regards, Adam.

Bug#976402: Bug#976902: topydo: provides /usr/bin/todo with incompatible interface compared to devtodo

[Dave Steele]

On Wed, Dec 9, 2020 at 12:40 PM Bill Allombert  wrote:

> On Wed, Dec 09, 2020 at 12:00:23PM -0500, Dave Steele wrote:
>
> /usr/bin/todo is not registered as an alternative by devtodo,
> so you cannot register it as an alternative in another package.
> The conflict between devtodo and topydo is not justified.
>

Well, OK, but that's not the issue this bug introduced.

> I would have preferred a discussion on #976402 in advance of an RC bug
> > report.
>
> Sorry, policy does not work that way. A policy proposal never delays a RC
> bug.
>

I thought we were having an active discussion on the validity of the policy
claim.
That discussion is moot?

Bug#739108: cpufrequtils: Wrong upstream Homepage URL

[Davide Prina]

Hi,

I think that the actual homepage is this:
https://cdn.kernel.org/pub/linux/utils/kernel/cpufreq/

Ciao
Davide

Bug#976991: libldap-2.4-2:amd64: Please consider building with openssl instead of gnutls

[Ryan Tandy]

Control: severity -1 wishlist

Hi Matt,

On Wed, Dec 09, 2020 at 01:07:11PM -0600, Matt Zagrabelny wrote:

Unfortunately FreeRADIUS is linked against openssl and cannot properly use
Debian's libldap-2.4-2, which is linked against gnutls, for TLS communication.


I'm missing a lot of context here. Why does libldap's TLS library matter 
to freeradius? Is there a bug against freeradius I should read?



From what I understand Fedora is building openldap with openssl.

If the licensing is a concern (due to OpenLDAP's license), Debian now considers 
openssl
to be a system library.

Thank you for considering this change.


For avoidance of doubt: I would rather not consider it for bullseye at 
this point, as the freeze is beginning soon. For bookworm it's 
definitely a possibility.


I have indeed heard that we consider openssl to be a system library now, 
and a couple of people pointed out that it's no longer mentioned in 
ftp-master's REJECT-FAQ. On the other hand at least one person has 
raised concerns[1] about whether it's a valid approach.


The main concern for me is a painful transition for users. The 
TLSCipherSuite setting is completely incompatible between the two 
(OpenSSL cipher lists and GnuTLS priority strings have completely 
different syntax) and the last time this was changed, there were bugs 
being reported about it for a long time afterward[2][3]. There are also 
some other, smaller differences in how they handle certificates[4] and 
probably other things.


When Red Hat transitioned from NSS to OpenSSL, they wrote an entire 
TLS shim module (tls_mc) to provide backward compatibility with existing 
NSS setups. Not sure if we'd actually need that much support, but that's 
to give you an idea of the amount of effort they considered justified.


I'm not saying the upgrade pain needs to block a transition, only that 
the benefits of the transition need to outweigh the pain, and that we 
need a better upgrade story than "oh btw your slapd/sssd/etc doesn't 
start anymore".


cheers,
Ryan

[1] https://lists.debian.org/debian-devel/2020/10/msg00168.html
[2] https://bugs.debian.org/541256
[3] https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1103353/comments/19
[4] https://bugs.openldap.org/show_bug.cgi?id=8586#c6

Bug#976899: Additional information

[Meelis Roos]

Might be a problem in some other package - I downgraded texlive-latex-extra to 
2020.20200925-1, 2020.20200804-3 and finally to 2020.20200629-1 (that one along 
with old texlive-luatex) and nothing changed.

Output file timestamps show I have successfully used powersem package on
2020-09-08 21:39
2020-09-29 20:58
2020-10-28 09:05
2020-11-11 10:30
2020-11-17 18:16
2020-11-24 21:13
2020-12-02 08:54 maybe too but I remember some trouble so perhaps I took 
earlier output file

Times of texlive-latex-extra updates from dpkg logs

2020-08-06 13:05:45 upgrade texlive-latex-extra:all 2020.20200629-1 
2020.20200804-1
2020-08-10 14:11:07 upgrade texlive-latex-extra:all 2020.20200804-1 
2020.20200804-2
2020-08-13 09:16:38 upgrade texlive-latex-extra:all 2020.20200804-2 
2020.20200804-3
2020-10-01 13:15:11 upgrade texlive-latex-extra:all 2020.20200804-3 
2020.20200925-1
2020-12-01 10:29:39 upgrade texlive-latex-extra:all 2020.20200925-1 
2020.20201129-1
2020-12-09 09:23:18 upgrade texlive-latex-extra:all 2020.20201129-1 
2020.20201129-1
2020-12-09 10:35:42 upgrade texlive-latex-extra:all 2020.20201129-1 
2020.20200925-1
2020-12-09 10:37:52 upgrade texlive-latex-extra:all 2020.20200925-1 
2020.20200804-3
2020-12-09 10:39:21 upgrade texlive-latex-extra:all 2020.20200804-3 
2020.20200629-1


Therefore full texlive sets from 2020.20200804-3 and 2020.20200925-1 should 
have been good (always upgraded all possible packages)

Downgraded/upgraded all of texlive-extra packages and texlive-luatex for deps 
to 2020.20200925-1, did not help.

Downgraded all texlive packages except older texlive-binaries and texlive-lang* 
to 2020-09-25, it works!


Upgraded texlive-base texlive-latex-extra texlive texlive-font-utils 
texlive-fonts-extra-links texlive-fonts-extra texlive-fonts-recommended to 
current 20201203 and tex-common 6.15
Still works.


Upgraded texlive-latex-base texlive-latex-recommended as they came together and 
it breaks.

So probably i's one of these two that can take over the bug report.
 


--
Meelis Roos

Bug#976998: coolkey: Wrong homepage

[Davide Prina]

Source: coolkey
Version: 1.1.0-16
Severity: normal

I have see that the homepage
http://directory.fedoraproject.org/wiki/CoolKey
do not respond anymore

I think that the new homepage is:
https://github.com/dogtagpki/coolkey

as reported from the FSF site:
https://directory.fsf.org/wiki/Coolkey

Ciao
Davide

Bug#976934: notmuch: FTBFS on ppc64el: FileNotFoundError: [Errno 2] No such file or directory: '/<>/emacs/notmuch.rsti'

[Lucas Nussbaum]

On 09/12/20 at 12:38 -0400, David Bremner wrote:
> 
> Control: tag -1 confirmed
> Lucas Nussbaum  writes:
> 
> > Source: notmuch
> > Version: 0.31.2-3
> > Severity: serious
> > Justification: FTBFS on ppc64el
> > Tags: bullseye sid ftbfs
> > Usertags: ftbfs-20201209 ftbfs-bullseye ftbfs-ppc64el
> >
> > Hi,
> >
> > During a rebuild of all packages in sid, your package failed to build
> > on ppc64el. At the same time, it did not fail on amd64.
> >
> > I'm marking this bug as severity:serious since your package currently has
> > ppc64el binary packages in unstable (so this is a regression).
> 
> Thanks for the report. It looks like it is some combination of an arch
> all build, and fairly high degree of parlellism in the build. I only
> managed to duplicate it on plummer with -j32. For future runs it would
> be great if the sbuild flags could be in the actual bug report (it took
> me a while to realize you were doing sbuild -A),

Oh, sorry about this. this is the first time this cames up, I think (the
sbuild command line is at the top of the log, third line)

> and if possible the
> amount of parallelism (parallel=whatever, or equivalent).

That's a bit harder to do since I don't do anything special (dh just
picks $(nproc) jobs). I did not expect that many failures related to
parallelism, or else I would have mentioned the 160 "cpus" (according to
/proc/cpuinfo, but that's just 2 sockets, 10 cores per socket, 8 threads
per core)

Lucas

Bug#976997: haproxy: flaky ppc64el autopkgtest on ci.debian.net: 503 Service Unavailable

[Paul Gevers]

Source: mpi4py
Version: 3.0.3-7
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: flaky

Dear maintainer(s),

The autopkgtest of your package turned up as blocking gcc-10. I looked
into the history of your autopkgtest and it fails regularly on ppc64el
[1]. I copied the output at the bottom of this report. I noticed that
all the failures in testing were the same and all ran on our
ci-worker-ppc64el-01. This worker is a bit slower than the rest, so I
suspect your test (or code) just fails to wait for the service to come
up properly. All the successful runs that I checked were on other workers.

Because the unstable-to-testing migration software now blocks on
regressions in testing, flaky tests, i.e. tests that flip between
passing and failing without changes to the list of installed packages,
are causing people unrelated to your package to spend time on these
tests.

Please do get in touch if we need to dive into this together. Or if you
want to discuss this issue.

Paul

[1] https://ci.debian.net/packages/h/haproxy/testing/ppc64el/
https://ci.debian.net/data/autopkgtest/testing/ppc64el/h/haproxy/8726704/log.gz

autopkgtest [18:08:36]: test proxy-localhost: [---
+ cat
+ service haproxy restart
+ wget -t1 http://localhost:8080+ cmp /var/www/html/index.html -
 -O-
--2020-12-08 18:09:02--  http://localhost:8080/
Resolving localhost (localhost)... ::1, 127.0.0.1
Connecting to localhost (localhost)|::1|:8080... failed: Connection refused.
Connecting to localhost (localhost)|127.0.0.1|:8080... connected.
HTTP request sent, awaiting response... 503 Service Unavailable
2020-12-08 18:09:05 ERROR 503: Service Unavailable.

cmp: EOF on - which is empty
+ echo FAIL: downloaded index.html via haproxy is different from the
+ echo   file delivered by apache.
+ exit 1
FAIL: downloaded index.html via haproxy is different from the
  file delivered by apache.



OpenPGP_signature
Description: OpenPGP digital signature

Bug#976995: Error importing plugin "pytest_tornasync": No module named 'pytest_tornasync'

[Julien Puydt]

Package: python3-pytest
Version: 4.6.11-1
Severity: grave

I was trying to update another package in the Debian Python Team, and
couldn't understand why its testsuite failed with the above error.

After some failed poking around, I put the following in a file named
test_foo.py:

def test_foo():
pass

and ran 'pytest-3 test_foo.py' : same error. So I think the problem is
with python3-pytest and not with the original package.

I'm setting the severity to grave since it makes the package unusable.

Cheers,

JP

PS: the full trace is:
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py",
line 572, in import_plugin
__import__(importspec)
ModuleNotFoundError: No module named 'pytest_tornasync'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/pytest-3", line 11, in 
load_entry_point('pytest==4.6.11', 'console_scripts', 'pytest')()
  File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py",
line 65, in main
config = _prepareconfig(args, plugins)
  File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py",
line 213, in _prepareconfig
return pluginmanager.hook.pytest_cmdline_parse(
  File "/usr/lib/python3/dist-packages/pluggy/hooks.py", line 286, in
__call__
return self._hookexec(self, self.get_hookimpls(), kwargs)
  File "/usr/lib/python3/dist-packages/pluggy/manager.py", line 92, in
_hookexec
return self._inner_hookexec(hook, methods, kwargs)
  File "/usr/lib/python3/dist-packages/pluggy/manager.py", line 83, in

self._inner_hookexec = lambda hook, methods, kwargs:
hook.multicall(
  File "/usr/lib/python3/dist-packages/pluggy/callers.py", line 203, in
_multicall
gen.send(outcome)
  File "/usr/lib/python3/dist-packages/_pytest/helpconfig.py", line 94,
in pytest_cmdline_parse
config = outcome.get_result()
  File "/usr/lib/python3/dist-packages/pluggy/callers.py", line 80, in
get_result
raise ex[1].with_traceback(ex[2])
  File "/usr/lib/python3/dist-packages/pluggy/callers.py", line 187, in
_multicall
res = hook_impl.function(*args)
  File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py",
line 789, in pytest_cmdline_parse
self.parse(args)
  File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py",
line 997, in parse
self._preparse(args, addopts=addopts)
  File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py",
line 943, in _preparse
self.pluginmanager.load_setuptools_entrypoints("pytest11")
  File "/usr/lib/python3/dist-packages/pluggy/manager.py", line 298, in
load_setuptools_entrypoints
self.register(plugin, name=ep.name)
  File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py",
line 335, in register
self.consider_module(plugin)
  File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py",
line 540, in consider_module
self._import_plugin_specs(getattr(mod, "pytest_plugins", []))
  File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py",
line 545, in _import_plugin_specs
self.import_plugin(import_spec)
  File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py",
line 581, in import_plugin
six.reraise(ImportError, new_exc, tb)
  File "/usr/lib/python3/dist-packages/six.py", line 702, in reraise
raise value.with_traceback(tb)
  File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py",
line 572, in import_plugin
__import__(importspec)
ImportError: Error importing plugin "pytest_tornasync": No module named
'pytest_tornasync'

Bug#976991: libldap-2.4-2:amd64: Please consider building with openssl instead of gnutls

[Matt Zagrabelny]

On Wed, Dec 9, 2020 at 1:45 PM Steve Langasek  wrote:

> On Wed, Dec 09, 2020 at 01:07:11PM -0600, Matt Zagrabelny wrote:
> > Unfortunately FreeRADIUS is linked against openssl and cannot properly
> use
> > Debian's libldap-2.4-2, which is linked against gnutls, for TLS
> > communication.
>
> Independent of questions of whether openldap should switch to openssl,
> could
> you elaborate why FreeRADIUS being linked against openssl causes a problem
> for a module linked against gnutls?  The two implementations should be
> entirely independent and able to operate independently within the same
> process.
>

I agree. It should work. Why it doesn't...

Short answer. I don't know.

Medium answer: Upstream states that gnutls claims to be compatible with
openssl, but it isn't compatible. If you search the net for "Alan DeKok
openssl gnutls ldap" you'll get hits.

Long guessing answer: Perhaps the FR LDAP module (rlm_ldap) makes library
calls that it expects to behave a certain way. If gnutls is providing those
function endpoints, it might be failing because the module (rlm_ldap) is
using openssl specific semantics.

I can confirm empirically that FR using libldap* works when openldap is
built with openssl and fails when libldap* uses gnutls. It fails at the TLS
layer - that is, the TLS connection fails.

I would wager that upstream has no interest in modifying its code to work
with gnutls (or Mozilla NSS).

-m

Bug#976994: ccls: autopkgtest regression in testing: FAIL: test_response (__main__.TestLSP) [$ccls/info]

[Paul Gevers]

Source: ccls
Version: 0.20201025-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent change in testing the autopkgtest of your package started
to fail. I copied some of the output at the bottom of this report. Can
you please investigate the situation and fix it?

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

Paul

https://ci.debian.net/data/autopkgtest/testing/amd64/c/ccls/8701788/log.gz

autopkgtest [13:23:44]: test lsp-test: [---
test_index (__main__.TestLSP) ... ok
test_response (__main__.TestLSP) ...
==
FAIL: test_response (__main__.TestLSP) [initialize]
--
Traceback (most recent call last):
  File
"/tmp/autopkgtest-lxc.jn191c8j/downtmp/build.gr1/src/debian/tests/lsp-test",
line 167, in test_response
one(tt)
  File
"/tmp/autopkgtest-lxc.jn191c8j/downtmp/build.gr1/src/debian/tests/lsp-test",
line 154, in one
self.assertEqual(case[1], got)
AssertionError: {'jsonrpc': '2.0', 'id': 1, 'result': {'capabilities':
{'text[1146 chars]1'}}} != {'jsonrpc': '2.0', 'method': '$/progress',
'params': {'token'[88 chars]58}}}
- {'id': 1,
-  'jsonrpc': '2.0',
? ^

+ {'jsonrpc': '2.0',
? ^

+  'method': '$/progress',
+  'params': {'token': 'index',
+ 'value': {'kind': 'report',
+   'message': '37/38',
+   'percentage': 97.36842105263158}}}
-  'result': {'capabilities': {'codeActionProvider': {'codeActionKinds':
['quickfix']},
-  'codeLensProvider': {'resolveProvider':
False},
-  'completionProvider': {'resolveProvider':
False,
-
'triggerCharacters': ['.',
-
':',
-
'>',
-
'#',
-
'<',
-
'"',
-
'/']},
-  'declarationProvider': True,
-  'definitionProvider': True,
-  'documentFormattingProvider': True,
-  'documentHighlightProvider': True,
-  'documentLinkProvider':
{'resolveProvider': True},
-  'documentOnTypeFormattingProvider':
{'firstTriggerCharacter': '}',
-
'moreTriggerCharacter': []},
-  'documentRangeFormattingProvider': True,
-  'documentSymbolProvider': True,
-  'executeCommandProvider': {'commands':
['ccls.xref']},
-  'foldingRangeProvider': True,
-  'hoverProvider': True,
-  'implementationProvider': True,
-  'referencesProvider': True,
-  'renameProvider': True,
-  'signatureHelpProvider':
{'triggerCharacters': ['(',
-
   ',']},
-  'textDocumentSync': {'change': 2,
-   'openClose': True,
-   'save':
{'includeText': False},
-   'willSave': False,
-   'willSaveWaitUntil':
False},
-  'typeDefinitionProvider': True,
-  'workspace': {'workspaceFolders':
{'changeNotifications': True,
-
'supported': True}},
-  'workspaceSymbolProvider': True},
- 'serverInfo': {'name': 'ccls', 'version': '0.20201025-1'}}}

==
FAIL: test_response (__main__.TestLSP) [$ccls/info]
--
Traceback (most recent call last):
  File
"/tmp/autopkgtest-lxc.jn191c8j/downtmp/build.gr1/src/debian/tests/lsp-test",
line 167, in test_response
one(tt)
  File
"/tmp/autopkgtest-lxc.jn191c8j/downtmp/build.gr1/src/debian/tests/lsp-test",
line 154, in one
self.assertEqual(case[1], got)
AssertionError: {'jso[30 chars]': {'db': {'files': 1, 'funcs': 0,
'types': 1,[95 chars] 1}}} != {'jso[30 chars]': {'capabilities':
{'textDocumentSync': {'ope[1129 chars]1'}}}
  {'id': 1,
   'jsonrpc': '2.0',
-  'result': {'db': {'files': 1, 'funcs': 0, 'types': 1, 'vars': 1},
- 'pipeline': {'completed': 1, 'enqueued': 1, 'lastIdle': 0},
- 'project': {'entries': 1}}}
+  'result': {'capabilities': {'codeActionProvider': {'codeActionKinds':
['quickfix']},
+  'codeLensProvider': {'resolveProvider':
False},
+  'completionProvider': {'resolveProvider':
False,
+
'triggerCharacters': ['.',
+
':',
+
'>',
+
'#',
+
'<',
+
'"',
+

Bug#976993: RFS: python-vttlib/0.9.1+dfsg.1-1 [ITP] -- extract VTT (Microsoft Visual TrueType) font hinting data

[Romain Porte]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-Cc: debian-pyt...@lists.debian.org,
 debian-fo...@lists.debian.org

Dear mentors,

I am looking for a sponsor for my package "python-vttlib":

 * Package name: python-vttlib
   Version : 0.9.1+dfsg.1-1
   Upstream Author : Nikolaus Waxweiler 
 * URL : https://github.com/daltonmaag/vttLib
 * License : MIT
 * Vcs : 
   Section : python

It builds those binary packages:

  python3-vttlib - extract VTT (Microsoft Visual TrueType) font hinting data

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

  https://mentors.debian.net/package/python-vttlib/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/python-vttlib/python-vttlib_0.9.1+dfsg.1-1.dsc

Changes for the initial release:

 python-vttlib (0.9.1+dfsg.1-1) unstable; urgency=medium
 .
   * Initial release (Closes: #976883)

Regards,
--
  Romain Porte


signature.asc
Description: PGP signature

Bug#976402: Proposed official virtual packages - todo and todo.txt

[David Steele]

On Wed, Dec 9, 2020 at 2:44 PM David Steele  wrote:

>
>
> On Wed, Dec 9, 2020 at 3:21 AM Ansgar  wrote:
>
>>
>>
>> Should emacs provide a "todo" script to open ~/TODO (with say org-mode)?
>>
>
In regards to org mode. I'd add a third criteria - the expectation that the
underlying
file complies with the todo.txt format, though there is no requirement that
the provider
enforce that.

Bug#973096: python-bleach: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.9 3.8" returned exit code 13

[Paul Gevers]

Control: found -1 3.1.5-2

On Tue, 27 Oct 2020 18:10:53 +0100 Lucas Nussbaum  wrote:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.

This now fails in bullseye too [1]. This needs to be fixed, but let's
not block the migration on the version.

Paul

[1]
https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/python-bleach.html



OpenPGP_signature
Description: OpenPGP digital signature

Bug#976402: Proposed official virtual packages - todo and todo.txt

[David Steele]

On Wed, Dec 9, 2020 at 3:21 AM Ansgar  wrote:

>
> Given topydo just provides/conflicts with devtodo to provide the "todo"
> binary, this seems to violate Policy 10.1 "Binaries" unless they provide
> the same functionality.
>

Note that there is a Conflicts because the current devtodo
does not support alternatives.

As I've said elsewhere, I claim they do provide the same functionality, and
are
not in violation of 10.1. I say "topydo and devtodo provide the same
functionality - the ability to add, delete, modify, and display discrete
tasking information". That is not a false statement. The question is, does
it reflect the intent of the Policy?

>From where I stand, I would expect the Policy to use a different word to
indicate something along the lines of greater API compatibility. I have no
additional background information, though. Are you aware of any expansions
on this text, or of any precedents that could help with a consensus process?


> Different "todo" managers should be coinstallable as different users
> might want to use different ones.
>

The scheme I propose allows that.


> From the messages I thought todo.txt is a standard *text* format, but
> now you say it is a standard command-line interface?  What can they do
> if they depend on todo.txt?
>

Todo.txt is an ecosystem of tools built around a file format. There is a
canonical
CLI implementation. Topydo was built as an alternative to that. I'm sorry,
but I'm
not sure I understand your question beyond that.

For the most part, todo.txt is an end user tool. As for a theoretical
package
that depends on todo.txt, I believe that the core capabilities it requires
of
todo.txt are:
  - a mechanism for discovering the location of the active tasking file
  - an optional mechanism for adding pre and post processing hooks to
task modification activities

These capabilities are present in topydo, with the help of todo.txt-base.


> This seems to imply I can manage tasks from the command-line like "todo
> new-task eat breakfast"?  What interface to do so is provided?  Can I
> call "todo ", "todo", "todo new-task ", ...?
>

It depends. Topydo can run one-off commands (arg[1] is the command, with a
default of "ls" - the same as devtodo). It also has an interpreter mode and
a
GUI mode, which I do not believe are pertinent to the discussion.. Devtodo
has one-off commands as well, along with other end point to support specific
commands.


> Should emacs provide a "todo" script to open ~/TODO (with say org-mode)?
>

Again, not sure I understand. To be sure, emacs could be used to edit the
file,
if it knows where it is. Note that part of the virtual packages work-up
involves
automatic discovery of the file location across providers (see
todo.txt-base -
https://manpages.debian.org/unstable/todo.txt-base/index.html).

I'm adding a common "--info" argument to all todo.txt providers. An emacs
todo script could use that to identify a todo file to open. But, the core
 "todo{.txt}" command does not open the file for editing. See the vitodo
and edittodo commands in todo.txt-base for something similar to what
you are talking about.

All of this is in preparation for another layer of capabilities for todo.txt
providers which is not submitted yet.

If your theoretical emacs script met the criterion I listed above ("--info"
and hooks), I'd say it is worth discussing if that could be a
todo.txt provider.

It appears that a virtual package, or at least these virtual packages in
particular,
need a distinct spec separate from their implementations. Where would
you expect to find that documentation? Should that spec be part of this
list application process?


> If it is just to have "todo" open a user-chosen program they like to
> manage their todo lists with, why not just have the user add a "todo"
> alias to their shell or $HOME/bin?
>

This standardizes that process. Part of the challenge with these tool sets
is the variety of things you have to do to get them to a common working
level. My goal in packaging them is to simplify that as much as
possible


> >   - name: todo.txt
> > description: task management based on a standard free-form text
> format
>
> This description seem to vague to me: it doesn't even mention what file
> format.  Does a package providing todo.txt provide any specific user
> interface?  Emacs can edit todo.txt files: would it qualify (even
> without a "todo" executable in $PATH)?
>
> Ansgar
>

Ok ... does anyone have guidance on the line length limit in that yaml file?
Could you take a stab at a replacement?

BTW - https://salsa.debian.org/debian/todotxt-cli/-/merge_requests/2

I'll just say here that your stance feels unnecessarily aggressive from the
viewpoint of my inbox. I'm just trying to add value here.

-- 
AE0D BF5A 92A5 ADE4 9481  BA6F 8A31 71EF 3661 50CE

Bug#976991: libldap-2.4-2:amd64: Please consider building with openssl instead of gnutls

[Steve Langasek]

On Wed, Dec 09, 2020 at 01:07:11PM -0600, Matt Zagrabelny wrote:
> Unfortunately FreeRADIUS is linked against openssl and cannot properly use
> Debian's libldap-2.4-2, which is linked against gnutls, for TLS
> communication.

Independent of questions of whether openldap should switch to openssl, could
you elaborate why FreeRADIUS being linked against openssl causes a problem
for a module linked against gnutls?  The two implementations should be
entirely independent and able to operate independently within the same
process.

-- 
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


signature.asc
Description: PGP signature

Bug#976992: libtpms: possible use of variables before assignment

[Steve Langasek]

Package: libtpms
Version: 0.8.0~dev1-1.2
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu hirsute ubuntu-patch

Hi Seunghun,

The libtpms package is failing to build from source on s390x in Ubuntu,
because the compiler detects that certain variables may be used before they
have been initialized.  Due to some oddities in the toolchain configuration,
the compiler output is not shown in the build logs, however I've manually
analyzed the failure and identified the attached patch which will fix the
build failure.

While the issue was only detected on Ubuntu/s390x, it is a generic issue
with the code, so I think the patch should be applied for correctness.

Thanks for considering,
-- 
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 libtpms-0.8.0~dev1/debian/patches/series 
libtpms-0.8.0~dev1/debian/patches/series
--- libtpms-0.8.0~dev1/debian/patches/series2020-08-08 10:31:09.0 
-0700
+++ libtpms-0.8.0~dev1/debian/patches/series2020-12-09 08:57:06.0 
-0800
@@ -2,3 +2,4 @@
 0002-fix-man-page-longline-typo.patch
 0003-set-man-page-date-to-last-changelog.patch
 0004-fix-ftbfs-bug.patch
+uninitialized-variable.patch
diff -Nru libtpms-0.8.0~dev1/debian/patches/uninitialized-variable.patch 
libtpms-0.8.0~dev1/debian/patches/uninitialized-variable.patch
--- libtpms-0.8.0~dev1/debian/patches/uninitialized-variable.patch  
1969-12-31 16:00:00.0 -0800
+++ libtpms-0.8.0~dev1/debian/patches/uninitialized-variable.patch  
2020-12-09 11:31:11.0 -0800
@@ -0,0 +1,31 @@
+Description: fix issues of variables that may be used before initialization
+ Detected by gcc on Ubuntu/s390x
+Author: Steve Langasek 
+Last-Update: 2020-12-09
+
+Index: libtpms-0.8.0~dev1/src/tpm12/tpm_nvram.c
+===
+--- libtpms-0.8.0~dev1.orig/src/tpm12/tpm_nvram.c
 libtpms-0.8.0~dev1/src/tpm12/tpm_nvram.c
+@@ -1997,7 +1997,7 @@
+ TPM_BOOL  done = FALSE;
+ TPM_BOOL  dir = FALSE;
+ TPM_BOOL  writeAllNV = FALSE; /* flag to write back 
NV */
+-TPM_NV_DATA_SENSITIVE *d1NvdataSensitive;
++TPM_NV_DATA_SENSITIVE *d1NvdataSensitive = NULL;
+ uint32_t  s1Last;
+ TPM_BOOL  physicalPresence;
+ TPM_BOOL  isGPIO = FALSE;
+Index: libtpms-0.8.0~dev1/src/tpm2/Marshal.c
+===
+--- libtpms-0.8.0~dev1.orig/src/tpm2/Marshal.c
 libtpms-0.8.0~dev1/src/tpm2/Marshal.c
+@@ -2219,7 +2219,7 @@
+ TPM2B_CREATION_DATA_Marshal(TPM2B_CREATION_DATA *source, BYTE **buffer, INT32 
*size)
+ {
+ UINT16 written = 0;
+-BYTE *sizePtr;
++BYTE *sizePtr = NULL;
+ 
+ if (buffer != NULL) {
+   sizePtr = *buffer;

Bug#976227: O: breathe -- Sphinx autodox support for languages with doxygen support

[Chris Knadle]

Melvin Vermeeren:

Hi Chris,

On Saturday, 5 December 2020 01:20:07 CET Chris Knadle wrote:

[...]

And assuming you'd like to take over for maintenance of the breathe Debian
package yourself and have sponsored uploads, the next step for that would be
to file an "ITA" (Intent To Adopt) bug, I believe. It seems you've got some
Debian package development experience already, so this seems quite fitting.
There's some additional explanation of the "ITA:" bug subject here:

 https://wiki.debian.org/how-can-i-help


Yeah I'd say going for ITA makes most sense here so that's what I would like
to do. Reading around a bit I find WNPP wiki page[1], the "ITA" entry of the
"Removing entries" seems appropriate. However not being an Debian maintainer
currently it seems inappropriate for me to actually do this.

[1] https://www.debian.org/devel/wnpp/


In the WNPP page [1] above the suggestion is to rename the "O:" bug with "ITA:" 
and set ownership of the bug to yourself in order to start the process.


In terms of not being a Debian Maintainer ... no, that isn't required. I know 
because I did this myself in 2014 for Mumble when its maintainer neglected it 
and then did not respond to communication about the package being broken:


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

I filed to become a Debian Maintainer in 2015 after taking care of a couple of 
packages in Debian for a while. That's the typical path to becoming a Debian 
Maintainer (and eventually Developer) today -- so it's expected to start off 
with taking care of one or more packages without being a DM first.



The mentor system also seems to have some overlap with GitLab's merge
requests. I know Salsa is relatively new in Debian and am guessing it's mostly
a maintainer preference which tooling and flow to use. So far I am most
comfortable with the gbp tooling, as it nicely integrates with a git-based
workflow which I'm used to.


As far as I'm aware Git-Buildpackage is what is still most often recommended. 
There are some further details like whether or not to use dgit. I wanted to try 
dgit but didn't like the way it worked with patches, because I like my patches 
to contain comment headers for what the patch is for, and last I spoke to DDs 
about it this was something that dgit conflicted with. The basic idea with dgit 
is that everything is a direct commit, so there wouldn't be any use of quilt for 
patch creation. There's also some new 'git' package format that I haven't 
investigated much. (I'm still most comfortable with the '3.0 quilt' format.)



I am used to working with GitLab and prefer direct merge requests as the
ability to iterate with inline diffs with explicit thread resolution is a very
nice review process in my opinion.

Typically in a situation where a non-privileged user is contributing (that
would be me) I would either fork the project and submit merge requests to
upstream. Somewhat more comfortable is being granted developer permissions[2]
on the project and then protecting[3] the primary branches so that only a
maintainer can push/merge to those.

[2] https://docs.gitlab.com/ee/user/permissions.html
[3] https://docs.gitlab.com/ee/user/project/protected_branches.html

Currently the Breathe repository is under Sebastian's namespace[4]. For the
above workflow to work the repository would ideally be owned by the actual
uploader/sponsor or possibly the python team[5]? That way it is ensured that
the main branches contain finalised and reviewed work.

[4] https://salsa.debian.org/sramacher/breathe
[5] https://salsa.debian.org/python-team/packages



Mostly just writing some ideas down above, hopefully it is somewhat relevant.
Perhaps a starting point would be to fork the project inside my personal
namespace on Salsa and create a merge request internally there for reviewing?


A project on Salsa is usually made available on request; so if you wanted the 
project to exist under the python-team/ area then it makes sense to join that 
team and then request creation of the project in order to have a Git repo 
location for the package. That way the package can be team maintained rather 
than it being under a personal area.


Although it's nice to have an online Git repo available for a package, it's also 
not a requirement. For instance I typically do an upload to Debian and /then/ 
push to the repo, so that if I have to back out changes in my local repo that it 
won't mess up the online repo. To start with when taking over a package I'll 
usually do the first upload with no listed Git: location in the debian/control 
file. Then usually I find a Git repo location to store the package repo, push, 
then update the Git: location in the debian/control file on the next upload. All 
of the work is done in Git-Buildpackage and made available later, it's just not 
available for the first upload. That's at least the path I've used so far ... 
having an online Git repo immediately for the first upload would be nice, but so 
far 

Bug#947431: xerces-c: CVE-2018-1311: use-after-free vulnerability processing external DTD

[Bill Blough]

Looks good to me.  Thanks.

Bug#976982: telegram-desktop: Segmentation fault at start on Wayland GNOME

[Nicholas Guriev]

severity important
merge 976982 976894
stop

I daresay the bug you reported relates to screensaver integration that
revealed today[1]. But if a workaround with QT_QPA_PLATFORM=wayland does
not work for you, it could be something else. Can you please describe
the crash more comprehensive and attach logs and terminal output of
telegram-desktop to identify the issue?

 [1]: https://bugs.debian.org/976894



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