Bug#960997: RM: libterm-editoredit-perl -- ROM; uses deprecated Any::Moose, inactive upstream, sole reverse-dependency migrated away
Package: ftp.debian.org Severity: normal Hi, with my Debian Perl group hat on, I'm trying to decrease the amount of packages that depend on Any::Moose, which is deprecated since 5 years. For more context, see https://bugs.debian.org/960909 Term::EditorEdit authors never commented on the upstream bug report about this since 5 years. The last upstream release happened in 2011. AFAICT the only reason why we had libterm-editoredit-perl in the archive is that pinto used to depend on it, which is not the case anymore. Cheers!
Bug#960998: r-cran-av: broken symlink /usr/lib/R/site-library/av/samples/Synapsis-Wonderland.mp3
Package: r-cran-av Version: 0.5.0+dfsg-2 Severity: serious Control: affects -1 src:r-cran-av The autopkgtest fails: https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-av/4902405/log.gz This is due to: /usr/lib/R/site-library/av/samples/Synapsis-Wonderland.mp3: broken symbolic link to ../../../../../share/doc/libmp3-tag-perl/examples/empty_10sec.mp3 The test passes after installing libmp3-tag-perl, but shipping a broken link created in debian/rules is wrong in any case. And depending on libmp3-tag-perl does not make sense for that. I would suggest to remove the override_dh_link, add test dependency on libmp3-tag-perl and then copy the file from libmp3-tag-perl at the start of the test.
Bug#960996: please provide a manual page
Package: pipx
Version: 0.12.3.1-3
There is no manual page, which is sad, it could be generated from -h for
example (and -h for each subcommand).
% man pipx
No manual entry for pipx
% pipx -h
usage: pipx [-h] [--version]
{install,inject,upgrade,upgrade-all,uninstall,uninstall-all,reinstall-all,list,run,ensurepath}
...
Install and execute binaries from Python packages.
Binaries can either be installed globally into isolated Virtual Environments
or run directly in an temporary Virtual Environment.
[...]
Bug#960995: RM: libalt-alien-ffi-system-perl -- ROM; deprecated upstream, not needed anymore
Package: ftp.debian.org Severity: normal Hi, Quoting my team-mate gregoa: "intrigeri: in case you're looking for rm candidates: libalt-alien-ffi-system-perl can go away, it was needed for ffi-platypus only and is not anymore". I confirm that the sole reason why this module existed is gone, upstream marked it as deprecated, removed it from CPAN, and archived the GitHub repository: https://github.com/Perl5-FFI/Alt-Alien-FFI-System Thanks in advance, cheers!
Bug#960994: [INTL:es] Spanish translation of the debconf template
Package: postgresql-common
Severity: wishlist
Tags: patch l10n
Hello,
You can find enclosed the Spanish translation template to be uploaded
with the latest package build.
Greetings,
--
Camaleón
# postgresql-common po-debconf translation to Spanish
# Copyright (C) 2010 Software in the Public Interest
# This file is distributed under the same license as the ocsinventory-server
package.
#
# Changes:
# - Initial translation
# Manuel \"Venturi\" Porras Peralta , 2016
#
# - Updates
# Camaleón , 2020
#
# Traductores, si no conocen el formato PO, merece la pena leer la
# documentación de gettext, especialmente las secciones dedicadas a este
# formato, por ejemplo ejecutando:
# info -n '(gettext)PO Files'
# info -n '(gettext)Header Entry'
#
# Equipo de traducción al español, por favor lean antes de traducir
# los siguientes documentos:
#
# - El proyecto de traducción de Debian al español
# http://www.debian.org/intl/spanish/
# especialmente las notas y normas de traducción en
# http://www.debian.org/intl/spanish/notas
#
# - La guía de traducción de po's de debconf:
# /usr/share/doc/po-debconf/README-trans
# o http://www.debian.org/intl/l10n/po-debconf/README-trans
#
msgid ""
msgstr ""
"Project-Id-Version: postgresql-common\n"
"Report-Msgid-Bugs-To: postgresql-com...@packages.debian.org\n"
"POT-Creation-Date: 2016-03-05 11:47+0100\n"
"PO-Revision-Date: 2020-05-03 15:56+\n"
"Last-Translator: Camaleón \n"
"Language-Team: Debian Spanish \n"
"Language: es\n"
"Plural-Forms: nplurals=2; plural=n != 1;\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#. Type: error
#. Description
#: ../postgresql-common.templates:1001
msgid "Obsolete major version ${old}"
msgstr "Versión principal ${old} obsoleta"
#. Type: error
#. Description
#: ../postgresql-common.templates:1001
msgid ""
"The PostgreSQL version ${old} is obsolete, but the server or client packages "
"are still installed. Please install the latest packages (postgresql-${latest}"
" and postgresql-client-${latest}) and upgrade the existing ${oldversion} "
"clusters with pg_upgradecluster (see manpage)."
msgstr ""
"La versión de PostgreSQL ${old} está obsoleta, pero el paquete del cliente o "
"del servidor aún están instalados. Debe instalar las últimas versiones de "
"los paquetes (postgresql-${latest} y postgresql-client-${latest}) y "
"actualizar sus clústers ${oldversion} con la orden «pg_upgradecluster» "
"(consulte la página del manual)."
#. Type: error
#. Description
#: ../postgresql-common.templates:1001
msgid ""
"Please be aware that the installation of postgresql-${latest} will "
"automatically create a default cluster ${latest}/main. If you want to "
"upgrade the ${old}/main cluster, you need to remove the already existing "
"${latest} cluster (pg_dropcluster --stop ${latest} main, see manpage for "
"details)."
msgstr ""
"Tenga en cuenta que la instalación de postgresql-${latest} creará "
"automáticamente un clúster por omisión ${latest}/main. Tiene que borrar el "
"clúster ${latest} existente («pg_dropcluster --stop ${latest}) si desea "
"actualizar el clúster ${old}/main, consulte la página de manual para conocer "
"los detalles."
#. Type: error
#. Description
#: ../postgresql-common.templates:1001
msgid ""
"The old server and client packages are no longer supported. After the "
"existing clusters are upgraded, the postgresql-${old} and postgresql-client-"
"${old} packages should be removed."
msgstr ""
"Ya no se da soporte a los paquetes antiguos de cliente y servidor. Debería "
"eliminar los paquetes postgresql-${old} y postgresql-client-${old} después "
"de actualizar los clústers que tenga."
#. Type: error
#. Description
#: ../postgresql-common.templates:1001
msgid ""
"Please see /usr/share/doc/postgresql-common/README.Debian.gz for details."
msgstr ""
"Para más información consulte «/usr/share/doc/postgresql-common/README."
"Debian.gz»."
#. Type: boolean
#. Description
#: ../postgresql-common.templates:2001
msgid "Enable SSL by default in new PostgreSQL clusters?"
msgstr ""
"¿Desea activar SSL como predeterminado en los nuevos clústers de PostgreSQL?"
#. Type: boolean
#. Description
#: ../postgresql-common.templates:2001
msgid ""
"PostgreSQL supports SSL-encrypted connections. This is usually a good thing. "
"However, if the database is solely accessed using TCP connections on "
"localhost, SSL can be turned off without introducing security issues."
msgstr ""
"PostgreSQL admite conexiones cifradas SSL. Esto suele ser una buena idea. "
"Aún así, si se accede a la base de datos exclusivamente usando conexiones "
"TCP en «localhost», se puede desactivar el SSL sin provocar problemas de "
"seguridad."
#. Type: boolean
#. Description
#: ../postgresql-common.templates:2001
msgid ""
"UNIX domain socket connections (called \"local\" in pg_hba.conf) are not "
"affected by this setting. This setting concerns new PostgreSQL clusters "
"created during package install, or by using the pg_createcl
Bug#954472: firefox: regression: webext-* packaged addons are not loaded in new profiles
Control: fixed -1 76.0.1-2 I can confirm that the bug has been fixed by adding --allow-addon-sideload option for mozconfig script. The bug was pretty severe because even none of firefox-l10n-* langpacks were working. Now the problem has been solved, at least webext-noscript, webext-ublock-origin and webext-debianbuttons, and those langpacks are just working. signature.asc Description: This is a digitally signed message part
Bug#960993: [INTL:es] Spanish translation of the debconf template
Package: ocsinventory-agent Severity: wishlist Tags: patch l10n Hello, You can find enclosed the Spanish translation template to be uploaded with the latest package build. Greetings, -- Camaleón # ocsinventory-agent po-debconf translation to Spanish # Copyright (C) 2010 Software in the Public Interest # This file is distributed under the same license as the ocsinventory-server package. # # Changes: # - Initial translation # Maria Germana Oliveira Blazetic , 2018 # # - Updates # Camaleón , 2020 # # Traductores, si no conocen el formato PO, merece la pena leer la # documentación de gettext, especialmente las secciones dedicadas a este # formato, por ejemplo ejecutando: # info -n '(gettext)PO Files' # info -n '(gettext)Header Entry' # # Equipo de traducción al español, por favor lean antes de traducir # los siguientes documentos: # # - El proyecto de traducción de Debian al español # http://www.debian.org/intl/spanish/ # especialmente las notas y normas de traducción en # http://www.debian.org/intl/spanish/notas # # - La guía de traducción de po's de debconf: # /usr/share/doc/po-debconf/README-trans # o http://www.debian.org/intl/l10n/po-debconf/README-trans # msgid "" msgstr "" "Project-Id-Version: ocsinventory-agent 1:0.0.8-1\n" "Report-Msgid-Bugs-To: ocsinventory-ag...@packages.debian.org\n" "POT-Creation-Date: 2018-04-12 19:34+0200\n" "PO-Revision-Date: 2020-05-03 15:38+\n" "Last-Translator: Camaleón \n" "Language-Team: Debian Spanish \n" "Language: es\n" "Plural-Forms: nplurals=2; plural=n!=1;\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" #. Type: select #. Choices #: ../ocsinventory-agent.templates:2001 msgid "local" msgstr "local" #. Type: select #. Choices #: ../ocsinventory-agent.templates:2001 msgid "http" msgstr "http" #. Type: select #. Description #: ../ocsinventory-agent.templates:2002 msgid "Method used to generate the inventory:" msgstr "Método usado para generar el inventario:" #. Type: select #. Description #: ../ocsinventory-agent.templates:2002 msgid "Choose the 'local' method if you do not have a network connection." msgstr "Seleccione el método «local» si no posee una conexión de red." #. Type: select #. Description #: ../ocsinventory-agent.templates:2002 msgid "Choose the 'http' method if an OCS Inventory server is set up." msgstr "Seleccione el método «http» si posee un servidor de inventario OCS." #. Type: string #. Description #: ../ocsinventory-agent.templates:3001 msgid "OCS Inventory server URL:" msgstr "Dirección URL del servidor de inventario OCS:" #. Type: string #. Description #: ../ocsinventory-agent.templates:3001 msgid "Please enter the URL of the OCS inventory server." msgstr "" "Introduzca el nombre de la dirección URL del servidor de inventario OCS." #. Type: string #. Description #: ../ocsinventory-agent.templates:4001 msgid "Tag for the generated inventory:" msgstr "Etiqueta del inventario generado:" #. Type: string #. Description #: ../ocsinventory-agent.templates:4001 msgid "" "Each inventory can have an associated tag. Please enter the tag you would " "like for the new inventory." msgstr "" "Cada inventario puede tener una etiqueta asociada. Introduzca la etiqueta a " "utilizar con el nuevo inventario." #. Type: string #. Description #: ../ocsinventory-agent.templates:4001 msgid "" "This field can be left blank to continue without setting a new tag for the " "inventory." msgstr "" "Puede dejar este campo en blanco para continuar sin asignar una nueva " "etiqueta al inventario."
Bug#960950: support cloned chroot with unshare backend
On Tue, May 19, 2020 at 1:23 PM Johannes Schauer wrote:
>
> Hi,
>
> Quoting Shengjing Zhu (2020-05-19 05:35:23)
> > >Your two sentences don't tell me what you'd like sbuild to do. In your
> > >follow-up email please be specific about what you propose and why it would
> > >be useful and an improvement over the status-quo.
> > The second sentence is a possible implementation. Mounting an overlay needs
> > privileged permission. But the beauty of the unshare backend is that it
> > doesn't need privilege. So I just propose the fuse-overlayfs.
>
> even the unshare backend needs some privilege. To setup the unshared namespace
> it needs newuidmap and newgidmap which are suid binaries and thus you briefly
> work with root privileges (there already were two CVEs against these tools:
> CVE-2016-6252 and CVE-2018-7169).
>
> Also, for fuse-overlayfs to make sense you need an *unpacked* rootfs
> somewhere.
> Creating this unpacked rootfs needs superuser privileges or otherwise the
> ownership information will be all off.
>
I'm not expert at this. But the fuse-overlayfs says it supports
overlay+shiftfs. So I think you can create rootfs in a user namespace.
I test it in a rootless container, and successfully debootstrap a
rootfs and do an overlay mount.
(Since I'm not sure how to use unshare and newuidmap/newgidmap, so I
take a tool[1] which is similar to them)
[1] https://github.com/rootless-containers/rootlesskit
Below is my experiment.
$ rootlesskit --net=host bash
$ export container=lxc # just pretend as a contaner, so debootstrap doesn't fail
$ debootstrap unstable ./rootfs/ http://127.0.0.1:3142/deb.debian.org/debian/
$ mkdir -p overlay/{upper,work,merged}
$ fuse-overlayfs -o
lowerdir=rootfs,upperdir=overlay/upper,workdir=overlay/work
overlay/merged
$ chroot overlay/merged/
$ touch a
$ chown root:staff a
$ ls -lh a
-rw-r--r-- 1 root staff 0 May 19 06:10 a
things like the group is kept as well.
And on the host, I see
$ ls -lh //overlay/upper/a
-rw-r--r-- 1 zhsj 100049 0 May 19 14:10 /tmp/t/overlay/upper/a
> So the advantage of using an overlay is:
>
> - faster than unpacking a tarball (which usually takes below 2 seconds)
>
> The disadvantage of using an overlay is:
>
> - root is needed to have the lowerdir unpacked somewhere
In my experiment, it doesn't need root.
> - if anything fails or gets killed, a stale mount is leftover
> - additional dependencies
> - fuse has to be setup (user must be in fuse group)
I'm not sure, but I'm not in fuse group.
$ id
uid=1000(zhsj) gid=1000(zhsj)
groups=1000(zhsj),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),101(systemd-journal),105(kvm),108(netdev),112(sbuild),113(docker),115(lpadmin),120(libvirt),997(mock)
> - fuse is not available everywhere (for example inside containers, like
> Debian
>CI)
> - more command line options + associated complexity
>
> Thanks!
>
> cheers, josch
--
Shengjing Zhu
Bug#960992: javapoet: Please update javapoet to version 1.12
Source: javapoet Severity: wishlist Dear Maintainers, Please update javapoet to version 1.12. This version is a dependency for Google Auto Factory [1] that I'm trying to package for Debian. Thanks! -Olek [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960991
Bug#960983: apt-cudf: silently skips installing systemd from Build-Depends
Control: tags -1 moreinfo Hi, On Mon, May 18, 2020 at 07:19:27PM -0700, Ross Vandegrift wrote: > apt-build build-dep with apt-cudf does not install systemd, even when it > appears directly in the Build-Depends of the requested package. Example: > > $ apt-get --simulate build-dep --solver aspcud enlightenment > > No error/warning tells the user that they didn't get everything they wanted. Please provide the output of the command, to show what exactly was proposed by apt-get as a solution. I suspect this might be caused by this bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959828 Cheers, Ivo
Bug#960988: installation-report: Installation report for HP Pavillion X360 14-cd0004la
Package: installation-reports Version: 2.71 Severity: minor The Buster installer could not find my wireless card (RTL 8821CE). I performed the install using a spare external wireless interface; after booting to the installed system, I found an unofficial module supporting this hardware at: https://github.com/tomaspinho/rtl8821ce Installed it via dkms, even happily signed it with mok. All is fine and dandy with a stock Buster install! (even stylus and touchscreen support, automatic screen rotation, ...) -- Package-specific info: Boot method: USB netinstall Image version: https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-10.4.0-amd64-netinst.iso Date: 2020.05.19 Machine: HP Pavillion X360 14-CD0004LA Partitions: Command (m for help): Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors Disk model: WDC WD10SPZX-60Z Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: gpt Disk identifier: BBF313A0-56AF-4048-9847-7C9D8D0070CF DeviceStartEndSectors Size Type /dev/sda1 204810506231048576 512M EFI System /dev/sda2 1050624 59643903 5859328028G Linux filesystem /dev/sda3 59643904 675020797858176 3.8G Linux swap /dev/sda4 67502080 1953523711 1886021632 899.3G Linux filesystem Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[E] Configure network: [E] Detect CD: [O] Load installer modules: [O] Clock/timezone setup: [O] User/password setup:[O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Install tasks: [O] Install boot loader:[O] Overall install:[O] Comments/Problems: Wifi card not detected nor reported as missing in any way. No support available for this card in the 4.19 kernel. Will later check if it appears in a kernel from backports. -- Please make sure that the hardware-summary log file, and any other installation logs that you think would be useful are attached to this report. Please compress large files using gzip. Once you have filled out this report, mail it to sub...@bugs.debian.org. == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION="Debian GNU/Linux installer" DISTRIB_RELEASE="10 (buster) - installer build 20190702+deb10u4" X_INSTALLATION_MEDIUM=cdrom == Installer hardware-summary: == uname -a: Linux hipopotama 4.19.0-9-amd64 #1 SMP Debian 4.19.118-2 (2020-04-29) x86_64 GNU/Linux lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation Device [8086:5904] (rev 08) lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:8486] lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation Device [8086:5917] (rev 07) lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:8486] lspci -knn: 00:04.0 Signal processing controller [1180]: Intel Corporation Skylake Processor Thermal Subsystem [8086:1903] (rev 08) lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:8486] lspci -knn: 00:13.0 Non-VGA unclassified device []: Intel Corporation Device [8086:9d35] (rev 21) lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:8486] lspci -knn: Kernel driver in use: intel_ish_ipc lspci -knn: Kernel modules: intel_ish_ipc lspci -knn: 00:14.0 USB controller [0c03]: Intel Corporation Sunrise Point-LP USB 3.0 xHCI Controller [8086:9d2f] (rev 21) lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:8486] lspci -knn: Kernel driver in use: xhci_hcd lspci -knn: Kernel modules: xhci_pci lspci -knn: 00:14.2 Signal processing controller [1180]: Intel Corporation Sunrise Point-LP Thermal subsystem [8086:9d31] (rev 21) lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:8486] lspci -knn: 00:15.0 Signal processing controller [1180]: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #0 [8086:9d60] (rev 21) lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:8486] lspci -knn: 00:15.1 Signal processing controller [1180]: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #1 [8086:9d61] (rev 21) lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:8486] lspci -knn: 00:15.2 Signal processing controller [1180]: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #2 [8086:9d62] (rev 21) lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:8486] lspci -knn: 00:16.0 Communication controller [0780]: Intel Corporation Sunrise Point-LP CSME HECI #1 [8086:9d3a] (rev 21) lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:8486] lspci -knn: 00:17.0 SATA controller [0106]: Intel Corporation
Bug#960987: RFS: inkscape/1.0-1~bpo10+1 -- vector-based drawing program
On Tue, 2020-05-19 at 11:42 +0630, Ko Ko Ye` wrote: > same with > > https://packages.debian.org/sid/inkscape ?\ > > update or fix This is a backport from Debian testing with a couple of build fixes. Backports are only allowed from this distribution in most cases and for sid (unstable) very rarely. See below for information on backports. https://wiki.debian.org/Backports Regards Phil -- *** Playing the game for the games sake. *** WWW: https://kathenas.org Twitter: @kathenasorg IRC: kathenas GPG: 724AA9B52F024C8B signature.asc Description: This is a digitally signed message part
Bug#960950: support cloned chroot with unshare backend
Hi, Quoting Shengjing Zhu (2020-05-19 05:35:23) > >Your two sentences don't tell me what you'd like sbuild to do. In your > >follow-up email please be specific about what you propose and why it would > >be useful and an improvement over the status-quo. > The second sentence is a possible implementation. Mounting an overlay needs > privileged permission. But the beauty of the unshare backend is that it > doesn't need privilege. So I just propose the fuse-overlayfs. even the unshare backend needs some privilege. To setup the unshared namespace it needs newuidmap and newgidmap which are suid binaries and thus you briefly work with root privileges (there already were two CVEs against these tools: CVE-2016-6252 and CVE-2018-7169). Also, for fuse-overlayfs to make sense you need an *unpacked* rootfs somewhere. Creating this unpacked rootfs needs superuser privileges or otherwise the ownership information will be all off. So the advantage of using an overlay is: - faster than unpacking a tarball (which usually takes below 2 seconds) The disadvantage of using an overlay is: - root is needed to have the lowerdir unpacked somewhere - if anything fails or gets killed, a stale mount is leftover - additional dependencies - fuse has to be setup (user must be in fuse group) - fuse is not available everywhere (for example inside containers, like Debian CI) - more command line options + associated complexity Thanks! cheers, josch signature.asc Description: signature
Bug#917941: Installation Buster on HP 17-by Notebook
Hi, Just adding some info to this bug, for whoever stumbles upon it - I just got a new HP laptop (HP Pavillion X360, 14", specific model 14-cd0004la) with this same wifi chip. I was able to install and use the (very not official, run at your own risk!) drivers available at https://github.com/tomaspinho/rtl8821ce via DKMS. So far, so good (not that it's been very far yet ;-) ) Other than this driver, the laptop works very well with a stock Debian Buster 10.4. Will submit a separate installation report, of course. Thanks!
Bug#960987: RFS: inkscape/1.0-1~bpo10+1 -- vector-based drawing program
same with https://packages.debian.org/sid/inkscape ?\ update or fix On Tue, May 19, 2020 at 11:00 AM Phil Wyett wrote: > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for my package "inkscape" > > * Package name: inkscape >Version : 1.0-1~bpo10+1 >Upstream Author : Too numerous to list, see website > * URL : https://inkscape.org > * License : GPL-2+ > * Vcs : https://salsa.debian.org/multimedia-team/inkscape >Section : graphics > > It builds those binary packages: > > inkscape - vector-based drawing program > inkscape-tutorials - vector-based drawing program - tutorials > > To access further information about this package, please visit the > following URL: > > https://mentors.debian.net/package/inkscape > > Alternatively, one can download the package with dget using this > command: > > dget -x > > https://mentors.debian.net/debian/pool/main/i/inkscape/inkscape_1.0-1~bpo10+1.dsc > > Changes since the last upload: > >* Rebuild for buster-backports. >* d/control: Use build dep 'debhelper-compat (=12)'. >* d/rules: Use 'override_dh_dwz' to disable debug symbol compression. > > Regards > > Phil > > -- > > *** Playing the game for the games sake. *** > > WWW: https://kathenas.org > > Twitter: @kathenasorg > > IRC: kathenas > > GPG: 724AA9B52F024C8B > > -- with regards *Ko Ko Ye`* +95 97989 22022 +95 94500 22022 +95 9731 47907 kokoye2...@gmail.com kokoye2...@ubuntu.com skype: kokoye2007 jitsi: kokoye2007 http://ubuntu-mm.net http://wiki.ubuntu.com/kokoye2007 http://wiki.ubuntu.com/MyanmarTeam http://loco.ubuntu.com/teams/ubuntu-mm
Bug#924290: [rfc] information about EFI partitions
On Sun, May 17, 2020 at 02:34:47PM +0200, Holger Wansing wrote:
>Hi,
>
> wrote:
>> Package: installation-guide
>> Version: 20180930
>> Severity: wishlist
>> Tags: patch
>>
>> Hi
>>
>> recently I was learning about presseding UEFI installs and
>> I think the install guide could use a small addition to make
>> that journey easier. I also sent a patch to partman-auto-recipe.txt
>> but I am sure the readership of that is much less than the d-i manual.
>
>I am unable to proof the patch correct or not, could anyone comment on that?
All I can say is It Works For Us, on plenty of amd64 installs
over the last year. The patch has evolved a little since then,
inline below. Please let me know if you'd rather a MR.
Vince
diff --git a/en/appendix/preseed.xml b/en/appendix/preseed.xml
index d7570d6b3..817749bb9 100644
--- a/en/appendix/preseed.xml
+++ b/en/appendix/preseed.xml
@@ -1206,6 +1211,20 @@ d-i partman-auto/choose_recipe select atomic
# system labels, volume group names and which physical devices to include
# in a volume group.
+## Partitioning for EFI
+# If your system needs an EFI partition you could add something like
+# this to the recipe above, as the first element in the recipe:
+# 538 538 1075 free \
+# $iflabel{ gpt } \
+# $reusemethod{ } \
+# method{ efi } \
+# format{ } \
+# . \
+#
+# The fragment above is for the amd64 architecture; the details may be
+# different on other architectures. The 'partman-auto' package in the
+# D-I source repository may have an example you can follow.
+
# This makes partman automatically partition without confirmation, provided
# that you told it what to do using one of the methods above.
d-i partman-partitioning/confirm_write_new_label boolean true
@@ -1213,6 +1232,16 @@ d-i partman/choose_partition select finish
d-i partman/confirm boolean true
d-i partman/confirm_nooverwrite boolean true
+# Force UEFI booting ('BIOS compatibility' will be lost). Default: false.
+#d-i partman-efi/non_efi_system boolean true
+# Ensure the partition table is GPT - this is required for EFI
+#d-i partman-basicfilesystems/choose_label string gpt
+#d-i partman-basicfilesystems/default_label string gpt
+#d-i partman-partitioning/choose_label string gpt
+#d-i partman-partitioning/default_label string gpt
+#d-i partman/choose_label string gpt
+#d-i partman/default_label string gpt
+
# When disk encryption is enabled, skip wiping the partitions beforehand.
#d-i partman-auto-crypto/erase_disks boolean false
Bug#960984: RFP: google-http-client-java -- Dependencies
This is my best guess as to the build dependencies for this package. Note that one has not been packaged yet, one needs an updated version (bugs listed), and two may not be required libjackson2-core-java libgoogle-gson-java junit4 libtruth-java (needs 0.42, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958539) libxpp3-java libhttpclient-java libguava-java libguava-testlib-java libjsr305-java libprotobuf-java libmockito-java libjdo-api-java libopencensus-java (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959838 ) mysql-connector-java (not packaged but maybe not strictly required?) j2objc-annotations (not packaged but maybe not strictly required?)
Bug#960987: RFS: inkscape/1.0-1~bpo10+1 -- vector-based drawing program
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "inkscape" * Package name: inkscape Version : 1.0-1~bpo10+1 Upstream Author : Too numerous to list, see website * URL : https://inkscape.org * License : GPL-2+ * Vcs : https://salsa.debian.org/multimedia-team/inkscape Section : graphics It builds those binary packages: inkscape - vector-based drawing program inkscape-tutorials - vector-based drawing program - tutorials To access further information about this package, please visit the following URL: https://mentors.debian.net/package/inkscape Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/i/inkscape/inkscape_1.0-1~bpo10+1.dsc Changes since the last upload: * Rebuild for buster-backports. * d/control: Use build dep 'debhelper-compat (=12)'. * d/rules: Use 'override_dh_dwz' to disable debug symbol compression. Regards Phil -- *** Playing the game for the games sake. *** WWW: https://kathenas.org Twitter: @kathenasorg IRC: kathenas GPG: 724AA9B52F024C8B signature.asc Description: This is a digitally signed message part
Bug#960986: RFS: fortune-zh/2.96 [ITA] -- Chinese Data files for fortune
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "fortune-zh" * Package name : fortune-zh Version : 2.96 Upstream Author : xiao sheng wen * URL : [fill in URL of upstream's web site] * License : GPL-3.0+ * Vcs : https://salsa.debian.org/chinese-team/fortunes-zh Section : games It builds those binary packages: fortunes-zh - Chinese Data files for fortune To access further information about this package, please visit the following URL: https://mentors.debian.net/package/fortune-zh Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/f/fortune-zh/fortune-zh_2.96.dsc Changes since the last upload: [ 肖盛文 ] * d/control: - Bump debhelper-compat (= 13) - Bump Standards-Version: 4.5.0 - add Rules-Requires-Root: no - add New Uploaders: xiao sheng wen * d/copyright: add Upstream-Contact: * New maintainer (Closes: #910181) Regards, -- 肖盛文 Faris Xiao 邮箱：atzli...@yeah.net 微信：atzlinux ＱＱ：909868357 铜豌豆 Linux 基于 Debian 的 Linux 中文桌面操作系统：https://www.atzlinux.com signature.asc Description: OpenPGP digital signature
Bug#960977: warning: $SAFE will become a normal global variable in Ruby 3.0
Hi Youhei, On 5/19/20 2:07 AM, Antonio Terceiro wrote: > The safe/taint mechanism was removed from Ruby in version 2.7. It's now > a no-op, and in Ruby 3.0 it will cause ruby-netcdf to crash. > > For example, you can reproduce the issue with this command: > > $ ruby -rnumru/netcdf -e 'puts NumRu::NetCDF.create_tmp' > /usr/lib/ruby/vendor_ruby/numru/netcdf.rb:144: warning: $SAFE will become a > normal global variable in Ruby 3.0 > # Since ruby-netcdf looks dead upstream with no new release since 2016, should we bother to patch this or just remove the package from the archive? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 signature.asc Description: OpenPGP digital signature
Bug#960674: golang-go: "fatal error: gc_trigger underflow" on mipsel
On Sat, May 16, 2020 at 1:46 AM Shengjing Zhu wrote:
>
> On Fri, May 15, 2020 at 6:03 PM Sascha Steinbiss wrote:
> >
> > Package: golang-go
> > Version: 2:1.14~1
> > Severity: important
> >
> > Dear Maintainer,
> >
> > the current go binary crashes on mipsel when running non-trivial calls
> > (a trivial call would be like 'go version', which succeeds) with the message
> > 'fatal error: gc_trigger underflow'. Here's an example from the mipsel
>
> I can confirm the go compiler is broken on mipsel currently.
> An simple go source, like
>
>
> $ cat test.go
> package main
>
> func main() {}
> ```
>
> Then `go build test.go` will trigger the fault.
>
> Looking at the buildd logs, it worked on 2020/4/26,
> https://buildd.debian.org/status/package.php?p=runc
>
> I suspect it's because the kernel is upgraded from 4.19.98-1 to 4.19.118-2.
>
FTR, after giving back golang-1.14 mipsel several times, it's finally
built, by a longson builder.
So I guess it only occurs on octeon. Since the porterbox eller is also
octeon, it also can't build any go program.
--
Shengjing Zhu
Bug#960950: support cloned chroot with unshare backend
On Tue, May 19, 2020 at 5:17 AM Johannes Schauer wrote: > > Hi, > > Quoting Shengjing Zhu (2020-05-18 19:35:38) > > It may be interesting to use cloned chroot as schroot when using unshare > > backend. > > > > I find fuse-overlayfs[1] claims it can be used in user namespace, as FUSE > > has supported user namespace since kernel 4.18. > > > > [1] https://tracker.debian.org/pkg/fuse-overlayfs > > I don't understand. What is it that you are proposing? What is the bug or the > feature request? It's a feature request. I wish the unshare backend can not only use tarball and untar it when building, but also support mounting an overlay when building, like schroot. I choose the wrong word, since the tarball mode also means cloned chroot. sorry for the confusion. >Your two sentences don't tell me what you'd like sbuild to do. In your >follow-up email please be specific about what you propose and why it would be >useful and an improvement over the status-quo. > The second sentence is a possible implementation. Mounting an overlay needs privileged permission. But the beauty of the unshare backend is that it doesn't need privilege. So I just propose the fuse-overlayfs. -- Shengjing Zhu
Bug#959829: RFP: google-api-client-java -- Dependencies
This is my best guess as to the build dependencies for this package. Note that two have not been packaged yet (RFP bugs listed) junit4 libxpp3-java libhttpclient-java libguava-java libjsr305-java libjdo-api-java libservlet-api-java libprotobuf-java libgoogle-auth-java ( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959830) libgoogle-http-client-java ( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960984)
Bug#960985: kvirc: Defunct homepage
Source: kvirc Severity: normal Version: 4:5.0.0+dfsg-1 X-Debbugs-CC: w...@debian.org Dear Debian kvirc maintainers, The current homepage field for package kvirc in Debian points to www.kvirc.de , which returns HTTP code 300 without specifying a Location header. As a result, this homepage cannot be opened. As far as I know the homepage for kvirc project should be http://www.kvirc.net/ . Please verify and fix the homepage information. Ideally please also mention https://github.com/kvirc/KVIrc as the Upstream- Repository. -- Regards, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#960984: RFP: google-http-client-java -- Google HTTP Client Library for Java
Package: wnpp Severity: wishlist * Package name: google-http-client-java Version : 1.35.0 Upstream Author : Google Inc. * URL : https://github.com/googleapis/google-http-java-client * License : Apache Programming Lang: Java Description : Google HTTP Client Library for Java Flexible, efficient, and powerful Java library written by Google for accessing any resource on the web via HTTP. The library has the following features: . Pluggable HTTP transport abstraction that allows you to use any low-level library such as java.net.HttpURLConnection, Apache HTTP Client, or URL Fetch on Google App Engine. Efficient JSON and XML data models for parsing and serialization of HTTP response and request content. The JSON and XML libraries are also fully pluggable, and they include support for Jackson and Android's GSON libraries for JSON. ** Dear Prospective Packager, This package is part of the dependency chain for medical and scientific community resources that the Debian Med team has identified as relevant to the COVID-19 pandemic. If you are able to participate in this endeavor [1], your assistance is greatly appreciated! -Olek On behalf of the Debian Bazel Team [1] https://salsa.debian.org/bazel-team/meta/-/wikis/Workplan-Part-1
Bug#960983: apt-cudf: silently skips installing systemd from Build-Depends
Package: apt-cudf Version: 5.0.1-14+b2 Severity: normal apt-build build-dep with apt-cudf does not install systemd, even when it appears directly in the Build-Depends of the requested package. Example: $ apt-get --simulate build-dep --solver aspcud enlightenment No error/warning tells the user that they didn't get everything they wanted. Ross -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'testing'), (40, 'unstable'), (30, 'experimental'), (1, 'experimental-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-4-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages apt-cudf depends on: ii aspcud [cudf-solver] 1:1.9.4-2 ii libbz2-1.01.0.8-2 ii libc6 2.30-7 ii perl 5.30.0-10 ii zlib1g1:1.2.11.dfsg-2 apt-cudf recommends no packages. apt-cudf suggests no packages. -- no debconf information
Bug#960892: po4a: --srcdir ignored by [po_directory]
Hi!
On Mon, 2020-05-18 at 11:04:27 +0200, Martin Quinson wrote:
> I tried to reproduce your bug with the integrated tests, but I failed
> to do so:
> https://travis-ci.org/github/mquinson/po4a/jobs/688267439#L2702
>
> In the test, I have a line "[po_directory] po" in the config file, and
> it works with --srcdir and --destdir, all combinaisons:
>
> Test44:
> Change directory to cfg/single-podirectory
> perl po4a -f BUILDPATH/t/cfg/single-podirectory/po4a.conf --destdir
> t/tmp/cfg/single-podirectory
> Test45:
> Change directory to tmp/cfg/single-podirectory-src
> perl po4a -f BUILDPATH/t/cfg/single-podirectory/po4a.conf --srcdir
> t/cfg/single-podirectory
> Test46:
> perl po4a -f BUILDPATH/t/cfg/single-podirectory/po4a.conf --srcdir
> cfg/single-podirectory --destdir tmp/cfg/single-podirectory-srcdst
> Test47:
> Change directory to tmp/cfg/single-podirectory-cur
> perl po4a -f BUILDPATH/t/cfg/single-podirectory/po4a.conf
>
> Maybe it's because I use the full path to the conf file, but it seems
> from your logs that this file is found, so I'm not sure.
Sven Joachim noticed that this was also happening while building dpkg,
when the man/po/dpkg-man.pot was newer than man/po/po4a.cfg, then also
noticed this bug report.
I started checking the code, and got the two attached patches which
fixes this for us. I've not checked further, whether any other
find_*_file() calls are swapped, nor whether there are other directory
creations missing, though, so that might be worth having a look over.
Thanks,
Guillem
From eaf4f65d4e57a06def62bf89db4f00dd4871be08 Mon Sep 17 00:00:00 2001
From: Guillem Jover
Date: Mon, 18 May 2020 23:39:11 +0200
Subject: [PATCH 1/2] po4a: Find the input .pot file for msgmerge in the srcdir
too
The .pot file was being looked only in the destdir locations, but in
this particular call this is in fact an input file.
---
po4a | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/po4a b/po4a
index 479d2aae..3426589a 100755
--- a/po4a
+++ b/po4a
@@ -1510,7 +1510,7 @@ if ( not $po4a_opts{"no-update"} ) {
foreach $lang ( sort keys %po_filename ) {
my ( $infile, $outfile ) =
( find_input_file( $po_filename{$lang} ), find_output_file( $po_filename{$lang} ) );
-my $updated_potfile = find_output_file($pot_filename);
+my $updated_potfile = find_input_file($pot_filename);
if ( -e $infile ) {
--
2.26.2.761.g0e0b3e54be
From 496662828737d9080dd94ac7166a7f3a761e8601 Mon Sep 17 00:00:00 2001
From: Guillem Jover
Date: Mon, 18 May 2020 23:40:09 +0200
Subject: [PATCH 2/2] po4a: Generate the directory for the .po file for the
msgmerge call
This is an output file, and if its directory is missing we need to
create it, otherwise msgmerge will fail.
---
po4a | 4
1 file changed, 4 insertions(+)
diff --git a/po4a b/po4a
index 3426589a..f831e3b4 100755
--- a/po4a
+++ b/po4a
@@ -1513,6 +1513,10 @@ if ( not $po4a_opts{"no-update"} ) {
my $updated_potfile = find_input_file($pot_filename);
if ( -e $infile ) {
+my $dir = dirname( $outfile );
+if ( not -d $dir ) {
+mkdir $dir or die wrap_msg( gettext("Can't create directory '%s': %s"), $dir, $! );
+}
my $msgmerge_opt = $po4a_opts{"msgmerge-opt"};
$msgmerge_opt =~ s/\$lang\b/$lang/g if scalar @langs;
--
2.26.2.761.g0e0b3e54be
Bug#960982: ITP: rocminfo -- ROCm Application for Reporting System Info
Package: wnpp Severity: wishlist Owner: Norbert Preining * Package name: rocminfo Version : 3.3.0 Upstream Author : AMD * URL : https://github.com/RadeonOpenCompute/rocminfo * License : University of Illinois/NCSA Open Source License Programming Lang: C++ Description : ROCm Application for Reporting System Info rocminfo gives information about the HSA system attributes and agents. This package is part of AMD ROCm software stack. Will be maintained under ROCm team.
Bug#960981: ITP: rocr-runtime -- HSA Runtime API and runtime for ROCm
Package: wnpp Severity: wishlist Owner: Norbert Preining * Package name: rocr-runtime Version : 3.3.0 Upstream Author : AMD * URL : https://github.com/RadeonOpenCompute/ROCR-Runtime/ * License : University of Illinois/NCSA Open Source License Programming Lang: C++ Description : HSA Runtime API and runtime for ROCm This library provides user-mode API interfaces necessary for host applications to launch compute kernels to available HSA ROCm kernel agents. Will be maintained under ROCm team.
Bug#960980: ITP: roc-smi -- AMD ROCm System Management Interface
Package: wnpp Severity: wishlist Owner: Norbert Preining * Package name: roc-smi Version : 3.3.0 Upstream Author : AMD * URL : https://github.com/RadeonOpenCompute/ROC-smi * License : MIT Programming Lang: Python Description : AMD ROCm System Management Interface This tool exposes functionality for clock and temperature management of your ROCm enabled system. Will be maintained under ROCm team.
Bug#960979: dpkg: cron job discards stderr bc of a limitation in tar 1.27.1, but tar 1.30 is in stable
Package: dpkg Version: 1.19.7 Severity: wishlist -- Package-specific info: System tainted due to merged-usr-via-symlinks. -- System Information: Debian Release: 10.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-9-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=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.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages dpkg depends on: ii libbz2-1.0 1.0.6-9.2~deb10u1 ii libc62.28-10 ii liblzma5 5.2.4-1 ii libselinux1 2.8-1+b1 ii tar 1.30+dfsg-6 ii zlib1g 1:1.2.11.dfsg-1 dpkg recommends no packages. Versions of packages dpkg suggests: ii apt1.8.2.1 pn debsig-verify -- no debconf information
Bug#960897: Update android-platform-external-libunwind and build for ppc64el
- Original Message - > From: "殷啟聰 | Kai-Chung Yan" > To: 960...@bugs.debian.org, "Timothy Pearson" > Sent: Sunday, May 17, 2020 11:13:32 PM > Subject: Re: Update android-platform-external-libunwind and build for ppc64el >> According to the source trees at both >> https://github.com/Unity-Technologies/android-libunwind and >> https://android.googlesource.com/platform/external/libunwind/, ppc64[le] >> systems are supported. > > I doubt it. Android never officially supported architectures other than x86, > ARM > or MIPS. And these days MIPS support is being removed. The source tree for > PowerPC is probably from the original `libunwind` and never touched by Google. > > Even if it builds successfully in PowerPC, I'm quite sure it was never tested. Is there any reason not to build the ppc64el version though, especially since there is no ppc64el Android version in existence? It's blocking adb, which I can confirm works fine on ppc64el *if* manually compiled.
Bug#957296: goaccess: ftbfs with GCC-10
Control: tag -1 + confirmed upstream pending On Fri, Apr 17, 2020 at 11:01:43AM +, Matthias Klose wrote: > The package fails to build in a test rebuild on at least amd64 with > gcc-10/g++-10, but succeeds to build with gcc-9/g++-9. The > severity of this report will be raised before the bullseye release, > so nothing has to be done for the buster release. > > The full build log can be found at: > http://people.debian.org/~doko/logs/gcc10-20200225/goaccess_1.3-1_unstable_gcc10.log > The last lines of the build log are at the end of this report. This bug has been already fixed in a new upstream version. I have it on the git repository, but I need to rework the autopkgtest test suite a bit. It should be uploaded soon. signature.asc Description: PGP signature
Bug#960945: po4a: Double spacing generated when source contains parens on EOL
Hello, On Tue, May 19, 2020 at 01:53:05AM +0200, Guillem Jover wrote: > Hi! > > On Mon, 2020-05-18 at 22:12:04 +0200, Martin Quinson wrote: > > - Le 18 Mai 20, à 18:58, Guillem Jover guil...@debian.org a écrit : > > > > When there is a closing parenthesis at the end of line, po4a parses it > > > and injects two spaces in the msgid text. I've noticed this when > > > reviewing the generated «.po» files from both troff and POD source. [...] > > actually, the POD parser in po4a is implemented with a third party > > library. I cannot do anything unless I completely reimplement the > > parser myself. > > But this affects also the man parser, so I assumed this would be a > problem with po4a itself, otherwise I'm happy to get this reassigned > to perl, as Pod::Parser seems to the external module used? Ahem, sorry, I read it too quickly earlier. In this case, I tend to blame libtext-wrapi18n-perl but I'll have to do some more tests before reassigning. > > I would rather advise to use asciidoc for a newly written documentation. > > I'm considering converting the po4a doc to this format, actually. > > For more complex documentation asciidoc would also be my preference. > But for man pages I think POD is fairly adequate, in terms of format > complexity, availability and dependency weight. For dpkg there's also > the additional constraint of not wanting to have to require new stuff, > and perl is already a build dependency. :) Ah. You mean you're not only translating the doc, you also want to display it to the users? Ok, fair enough, I forgot about this little detail :) Thanks for your interest into po4a, Mt. -- La moitié des chercheurs passe son temps à remplir des demandes que l’autre moitié perd beaucoup de temps à lire. -- André Brahic signature.asc Description: PGP signature
Bug#960978: popularity-contest: /var/lib/popularity-contest/lastsub is not deleted on purge
Package: popularity-contest Version: 1.70 Severity: minor /var/lib/popularity-contest/lastsub is not deleted on purge. This was not detected by piuparts because this file is created at runtime. Greetings, -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (450, 'unstable'), (400, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.6.0-1-amd64 (SMP w/6 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages popularity-contest depends on: ii debconf [debconf-2.0] 1.5.74 ii dpkg 1.19.7 Versions of packages popularity-contest recommends: ii gnupg 2.2.20-1 ii nullmailer [mail-transport-agent] 1:2.2-3 ii systemd-cron [cron-daemon] 1.5.14-2+b1 Versions of packages popularity-contest suggests: ii systemd-cron [anacron] 1.5.14-2+b1 pn tor pn torsocks -- debconf information: popularity-contest/submiturls: * popularity-contest/participate: true
Bug#960977: warning: $SAFE will become a normal global variable in Ruby 3.0
Package: ruby-netcdf Version: 0.7.2-4+b1 Severity: important Tags: upstream Dear Maintainer, The safe/taint mechanism was removed from Ruby in version 2.7. It's now a no-op, and in Ruby 3.0 it will cause ruby-netcdf to crash. For example, you can reproduce the issue with this command: $ ruby -rnumru/netcdf -e 'puts NumRu::NetCDF.create_tmp' /usr/lib/ruby/vendor_ruby/numru/netcdf.rb:144: warning: $SAFE will become a normal global variable in Ruby 3.0 # -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.6.0-1-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_CRAP Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), LANGUAGE=pt_BR:pt:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ruby-netcdf depends on: ii libc6 2.30-8 ii libnetcdf18 1:4.7.4-1 ii libruby2.72.7.1-3 ii ruby 1:2.7+1 ii ruby-narray 0.6.1.2-3+b2 ii ruby-narray-miss 1.4.0-2 ruby-netcdf recommends no packages. ruby-netcdf suggests no packages. -- no debconf information signature.asc Description: PGP signature
Bug#945641: python2 dependency
1. fio is an ELF binary, it MUST NOT depend on python 2. fio2gnuplot is an additional tool. fio should recommend python or fio2gnuplot should be the separate package 3. /usr/bin/fio2gnuplot is: # Note: this script is python2 and python3 compatible. -- sergio.
Bug#960945: po4a: Double spacing generated when source contains parens on EOL
Hi! On Mon, 2020-05-18 at 22:12:04 +0200, Martin Quinson wrote: > - Le 18 Mai 20, à 18:58, Guillem Jover guil...@debian.org a écrit : > > Package: po4a > > Version: 0.58.1 > > Severity: normal > > When there is a closing parenthesis at the end of line, po4a parses it > > and injects two spaces in the msgid text. I've noticed this when > > reviewing the generated «.po» files from both troff and POD source. > > > > Here's a test case: > > > > ,--- test.pod --- > > =head1 NAME > > > > test - some test > > > > =head1 DESCRIPTION > > > > Some B(5) > > some other (parenthetical text) > > which produce (only when at the end of line) double spacing, > > in the generated (.po) > > file. > > `--- > > > > ,--- sh --- > > $ po4a-gettextize -f pod -m test.pod > > […] > > #. type: textblock > > #: test.pod:7 > > msgid "" > > "Some B(5) some other (parenthetical text) which produce (only when > > " > > "at the end of line) double spacing, in the generated (.po) file." > > msgstr "" > > `--- > > > > Of course one problem that fixing this is that it will imply probably > > tons of fuzzying, which might even flip-flop depending on the po4a > > version used, so perhaps an explicit option would be required here to > > control the behavior, not sure. :/ > actually, the POD parser in po4a is implemented with a third party > library. I cannot do anything unless I completely reimplement the > parser myself. But this affects also the man parser, so I assumed this would be a problem with po4a itself, otherwise I'm happy to get this reassigned to perl, as Pod::Parser seems to the external module used? Here's the equivalent man test case: ,-- test.man --- .TH test 5 "2020-05-19" "1.0" "test case" .SH NAME test \- some test .SH DESCRIPTION Some \fBtext\fP(5) some other (parenthetical text) which produce (only when at the end of line) double spacing, in the generated (.po) file. `--- ,--- sh --- $ po4a-gettextize -f man -m test.man […] #. type: Plain text #: test.man:9 msgid "" "Some B(5) some other (parenthetical text) which produce (only when " "at the end of line) double spacing, in the generated (.po) file." msgstr "" `--- > I would rather advise to use asciidoc for a newly written documentation. > I'm considering converting the po4a doc to this format, actually. For more complex documentation asciidoc would also be my preference. But for man pages I think POD is fairly adequate, in terms of format complexity, availability and dependency weight. For dpkg there's also the additional constraint of not wanting to have to require new stuff, and perl is already a build dependency. :) Thanks, Guillem
Bug#960949: po4a: Cannot match some generic text in addenda header
On Mon, 2020-05-18 at 22:09:21 +0200, Martin Quinson wrote: > I was thinking about a specific mode=eof that would not need a > position nor a boundary to put the addendum at the end of the file. > Would it fit your needs? Oh, that would be even better yes! The fake boundaries always felt a bit hackish. :) Thanks, Guillem
Bug#960976: libguava-java: Generates unsatisfiable dependencies on libguava-java (>= 29.0-jre)
Package: libguava-java Version: 29.0-2 Severity: important For example, if I build guice_4.2.1-1 (using sbuild) then the resulting libguice-java package gets dependencies of: libguice-java_4.2.1-1_all.deb - new Debian package, version 2.0. size 963020 bytes: control archive=1896 bytes. 1100 bytes,23 lines control 3818 bytes,35 lines md5sums Package: libguice-java Source: guice Version: 4.2.1-1 Architecture: all Maintainer: Debian Java Maintainers Installed-Size: 1184 Depends: libaopalliance-java, libatinject-jsr330-api-java, libguava-java (>= 29.0-jre), libjsr305-java Suggests: libasm-java (>= 7.2), libcglib-java (>= 3.2.12) Built-Using: asm (= 7.2-1), cglib (= 3.2.12-1) Section: java Priority: optional Homepage: https://github.com/google/guice Description: lightweight dependency injection framework for Java 5 and above Guice provides support for dependency injection using annotations to configure Java objects. Dependency injection is a design pattern whose core principle is to separate behavior from dependency resolution. . Guice allows implementation classes to be programmatically bound to an interface, then injected into constructors, methods or fields using an @Inject annotation. When more than one implementation of the same interface is needed, the user can create custom annotations that identify an implementation, then use that annotation when injecting it. Which then obviously makes the resulting package uninstallable: daniel@frobnitz:~/rebuild$ apt-get -s install ./libguice-java_4.2.1-1_all.deb NOTE: This is only a simulation! apt-get needs root privileges for real execution. Keep also in mind that locking is deactivated, so don't depend on the relevance to the real current situation! Reading package lists... Done Building dependency tree Reading state information... Done Note, selecting 'libguice-java' instead of './libguice-java_4.2.1-1_all.deb' Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libguice-java : Depends: libguava-java (>= 29.0-jre) but 29.0-2 is to be installed E: Unable to correct problems, you have held broken packages. -- Daniel Schepler
Bug#960890: python-django: New upstream 3.x release
Hi Raphael, > > This is a bug to track the progress of uploading Django 3.x to > > unstable. > > Hum, this is a long term goal right? Because the next LTS in 3.x > is 3.2 and upstream has not yet released 3.1 and we will get 3.2 > only in 2021 AFAIK. Yes, this is a long-term goal. However, it would be nice to be able for people to elect to install 3.x from experimental, as well as to get started on the various small updates on the many leaf packages. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org 🍥 chris-lamb.co.uk `-
Bug#960975: django-taggit: FTBFS with Django 3.x
Source: django-taggit Version: 0.24.0-2 Severity: normal User: python-modules-t...@lists.alioth.debian.org Usertags: django-3.x Tags: fbtfs Dear Maintainer, The version of Django experimental is currently 3.0.6-1. I have built the 153 reverse-dependencies in unstable against this version. 114 of these build & pass their testsuite successfully. However, django-taggit fails to build. Please see: http://bugs.debian.org/960890 ... for more information. Please use this bug for all issues regarding Django 3.x that are not specific to this package to reduce duplicated work across all of the bugs. […] File "/django-taggit-0.24.0/taggit/models.py", line 6, in from django.utils.encoding import python_2_unicode_compatible ImportError: cannot import name 'python_2_unicode_compatible' from 'django.utils.encoding' (/usr/lib/python3/dist-packages/django/utils/encoding.py) […] The full build log is attached. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- django-taggit.0.24.0-2.unstable.amd64.log.txt.gz Description: Binary data
Bug#960974: buster-pu: package postfix/3.4.12-0+deb10u1
Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu This is the next in the series of normal postifx maintenance updates. I skipped postfix 3.4.11 since it had no changes that were relevant for Debian Buster. Of particular note, the last two listed TLS errors were reported upstream by a Debian Stable user who did a lot of work with the upstream developers to diagnose the problem and validate the solution. It would be nice to see the stable update out soon so that they can benefit. As usual, I have this running on multiple systems here without issue. I've also listed a few changes at the end that I did not put in debian/changelog because they have no effect on the binary or they have no effect given the gcc/glibc versions in Buster. Debdiff attached. Scott K Here are the details of the changes relative to Buster: [Scott Kitterman] * Updated debian/watch to track postfix 3.4 series for stable updates [Wietse Venema] * 3.4.11 - No changes that affect Debian 10 (Buster) * 3.4.12 - Bugfix: segfault in the tlsproxy client role when the server role was disabled. This typically happens on systems that do not receive mail, after configuring connection reuse for outbound TLS. Found during program maintenance. File: tlsproxy/tlsproxy.c. - Bugfix (introduced: Postfix 3.4): maillog_file_rotate_suffix default value used the minute instead of the month. Reported by Larry Stone. Files: conf/postfix-tls-script, proto/MAILLOG_README.html, proto/postconf.proto. global/mail_params.h, postfix/postfix.c. - Bitrot: avoid U_FILE_ACCESS_ERROR after chroot(), by initializing the ICU library before making the chroot() call. Files: util/midna_domain.[hc], global/mail_params.c. - Noise suppression: avoid "SSL_Shutdown:shutdown while in init" warnings. File: tls/tls_session.c. - Bugfix (introduced: Postfix 2.2): a TLS error for a PostgreSQL client caused a false 'lost connection' error for an SMTP over TLS session in the same Postfix process. Reported by Alexander Vasarab, diagnosed by Viktor Dukhovni. File: tls/tls_bio_ops.c. - Bugfix (introduced: Postfix 2.8): a TLS error for one TLS session may cause a false 'lost connection' error for a concurrent TLS session in the same tlsproxy process. File: tlsproxy/tlsproxy.c. Other changes not listed in debian/changelog: Workaround for broken builds after an incompatible change in GCC 10. Files: makedefs, Makefile.in. Workaround for broken DANE support after an incompatible change in GLIBC 2.31. This avoids the need for new options in /etc/resolv.conf. Files: dns/dns.h, dns/dns_lookup.c. Noise suppression: shut up a compiler that special-cases string literals. Viktor Dukhovni. File milter/milter.c. Security: disable DANE support on Alpine Linux because libc-musl provides no indication whether DNS responses are authentic. This broke DANE support without a clear explanation. File: makedefs. Noise suppression: shut up a compiler that special-cases string literals. Viktor Dukhovni. File smtpd/smtpd_check.c. diff -Nru postfix-3.4.10/debian/changelog postfix-3.4.12/debian/changelog --- postfix-3.4.10/debian/changelog 2020-03-16 15:43:44.0 -0400 +++ postfix-3.4.12/debian/changelog 2020-05-18 17:45:37.0 -0400 @@ -1,3 +1,47 @@ +postfix (3.4.12-0+deb10u1) buster; urgency=medium + + [Scott Kitterman] + + * Updated debian/watch to track postfix 3.4 series for stable updates + + [Wietse Venema] + + * 3.4.11 +- No changes that affect Debian 10 (Buster) + + * 3.4.12 +- Bugfix: segfault in the tlsproxy client role when the server + role was disabled. This typically happens on systems that + do not receive mail, after configuring connection reuse for + outbound TLS. Found during program maintenance. File: + tlsproxy/tlsproxy.c. + +- Bugfix (introduced: Postfix 3.4): maillog_file_rotate_suffix + default value used the minute instead of the month. Reported + by Larry Stone. Files: conf/postfix-tls-script, + proto/MAILLOG_README.html, proto/postconf.proto. + global/mail_params.h, postfix/postfix.c. + +- Bitrot: avoid U_FILE_ACCESS_ERROR after chroot(), by + initializing the ICU library before making the chroot() + call. Files: util/midna_domain.[hc], global/mail_params.c. + +- Noise suppression: avoid "SSL_Shutdown:shutdown while in + init" warnings. File: tls/tls_session.c. + +- Bugfix (introduced: Postfix 2.2): a TLS error for a PostgreSQL + client caused a false 'lost connection' error for an SMTP + over TLS session in the same Postfix process. Reported by + Alexander Vasarab, diagnosed by Viktor Dukhovni. File: + tls/tls_bio_ops.c. + +- Bugfix (
Bug#960973: RM: r-cran-roxygen2 [armel] -- RoQA; cannot be built on this architecture
Package: ftp.debian.org Severity: normal Control: block -1 by 960971 There is a package in unstable that was erroneously autobuilt due to #956507.
Bug#960972: RFS: cellwriter/1.3.6-2 [QA] -- grid-entry handwriting input panel
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "cellwriter" * Package name: cellwriter Version : 1.3.6-2 Upstream Author : Michael Levin * URL : https://github.com/risujin/cellwriter * License : GPL-2+ * Vcs : https://salsa.debian.org/debian/cellwriter Section : gnome It builds those binary packages: cellwriter - grid-entry handwriting input panel To access further information about this package, please visit the following URL: https://mentors.debian.net/package/cellwriter Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/c/cellwriter/cellwriter_1.3.6-2.dsc Changes since the last upload: * QA upload. . [ Debian Janitor ] * Trim trailing whitespace. * Bump debhelper from old 11 to 12. * Set upstream metadata fields: Bug-Submit, Repository. * Fix day-of-week for changelog entries 1.3.4-1, 1.3.3-1, 1.3.1-1, 1.3.0-1. . [ Sudip Mukherjee ] * Fix FTBFS with gcc-10. (Closes: #957075) * Update Standards-Version to 4.5.0 * Update compat level to 13. -- Regards Sudip
Bug#960819: squid command failure without systemd
On Monday, May 18 2020, I wrote: > Just a few more details I've been able to gather this afternoon. > > I'm using a Debian sid VM where I installed sysvinit to replace systemd. > I wasn't able to reproduce the problem reported above, even after > activating the apparmor profile before upgrading. > > If you look at the /etc/init.d/squid script, you can see that the > startup function does create the /run/squid/ directory. > > I will need more info to investigate this bug. I submitted https://salsa.debian.org/squid-team/squid/-/merge_requests/13 to fix the latent bug that I am experiencing when upgrading to the latest squid (unstable) and when the apparmor profile is enabled. It seems to me that the MR above might also fix the problem you're seeing. I can provide a .deb for you to test, if you're interested. Thanks, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible https://sergiodj.net/ signature.asc Description: PGP signature
Bug#960971: RM: r-cran-redland [armel] -- RoQA; cannot be built on this architecture
Package: ftp.debian.org Severity: normal r-cran-redland can no longer be built on armel (no nodejs).
Bug#960940: RFS: runit/2.1.2-37 [RC] -- system-wide service supervision
Hi, Disclaimer: Not sponsoring as I am oblivious to init systems of all kinds, so I don't feel confident reviewing changes in that area. (I am not stalking you – I promise! – I just couldn't let that opportunity pass by after pushing another set of apt resolver changes triggered by your packages :P) On Mon, May 18, 2020 at 05:43:55PM +0200, Lorenzo Puliti wrote: >* Merge runit-sysv and runit-systemd into runit-run (Closes: #953875) You are using unversioned Breaks+Replaces – please make them versioned. It is perhaps unlikely that packages with that name will reappear in the archive, but never say never… Related, but as a matter of style only, I would release package reorganisations always to experimental first: a) you need to clear NEW and b) there is usually at least one bug in it you want to fix quickly, but a) makes it unpredictable then that emergency will be. (also c) you need another upload to move to testing as NEW needs binaries to be uploaded, but they wont go into testing). Also, but that is bike shed material: "-run" ? I don't have a good suggestion, but I think for the uninitiated -run and -init will be indistinguishable (also: run-it-run, init!). | debian/runit-run.postinst I see that the same code was used before, but: a) make that a function instead of two code copies b) consider that a file might not have an ending newline: $ echo -n 'foo' > foo $ cat foo - < bar heredoc> EOF foobar $ Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#960970: lintian: confusing error message on missing file
Package: lintian Version: 2.74.0 Severity: minor $ lintian primus-vk_1.4-2_amd64.changes bad package file name primus-vk_1.4-2_amd64.changes (neither .deb, .udeb, .ddeb, .changes, .dsc or .buildinfo file) Hmm, it's a .changes file. But it wasn't in the current directory ... Andreas
Bug#945237: libwebkit2gtk-4.0-37: AAC streams stop after 1:42
On Thu, Nov 21, 2019 at 05:13:59PM +0100, Richard Lucassen wrote: > Open the this stream using "surf": > > surf http://tmp.xaq.nl/test-aac.html > > After 1 minute and 42 seconds the stream starts to hic and stops > completely after a few seconds. Tested on 3 Bullseye amd64 machines. This has been fixed in experimental (WebKitGTK 2.29.1) and is expected to be fixed in testing/unstable soon (when WebKitGTK 2.28.3 is released). I tested with 2.29.1 and it works fine. Berto
Bug#960969: sbuild: fail to work in unshare mode
Package: sbuild Version: 0.79.1-1 Severity: normal Hi, I have tried to get sbuild working in unshare mode. Here are the steps I have followed, from what I understood they should be sufficient: sudo sysctl kernel.unprivileged_userns_clone=1 sbuild-createchroot --chroot-mode=unshare --make-sbuild-tarball ~/.cache/sbuild/sid-amd64.tar.gz sid `mktemp -d` http://deb.debian.org/debian/ sbuild -d sid hello The last step is unsuccessful, it seems to fail to execute any comment. I have attached the output of the last command running with debug in case it could help. I have also tried to unpack the tarball and run the following command: unshare -f -U -r -p -m --mount-proc -R sid It works find, so it seems to show that the chroot creating is not totally broken. Thanks, Aurelien -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.6.0-1-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#960950: support cloned chroot with unshare backend
Hi, Quoting Shengjing Zhu (2020-05-18 19:35:38) > It may be interesting to use cloned chroot as schroot when using unshare > backend. > > I find fuse-overlayfs[1] claims it can be used in user namespace, as FUSE > has supported user namespace since kernel 4.18. > > [1] https://tracker.debian.org/pkg/fuse-overlayfs I don't understand. What is it that you are proposing? What is the bug or the feature request? Your two sentences don't tell me what you'd like sbuild to do. In your follow-up email please be specific about what you propose and why it would be useful and an improvement over the status-quo. Thanks! cheers, josch signature.asc Description: signature
Bug#959143: RFS: libgrokj2k/7.1.0-1 [ITP] -- JPEG 2000 image compression/decompression library
> > > Hi! > Sorry for the delay. > > There's one problem left: the .symbols file for libgrokj2k1 declares a > dependency on libgrokj2k (rather than 2k1). Please bump it a year ahead :) > Thanks! that was the last lintian warning :) All green now.
Bug#960726: firefox: connection failure to most https websites
On Sun, May 17, 2020 at 02:06:17AM +0200, Vincent Lefevre wrote: > On 2020-05-17 07:24:23 +0900, Mike Hommey wrote: > > Have you set security.OCSP.require to true in about:config? > > Yes, as I've said in my other message. Could you file an upstream bug? Mike
Bug#958504: libappindicator1:amd64: segfault for multiple apps like Discord
Hi Simon & folx, thanks for preparing those patches. I applied both to a local compile and have not experienced a crash of discord in the timeframe I would have expected several. Thanks a lot for preparing this! Cheers, David
Bug#933734: CRTL+ARROWS switch but does not really now
On Sun, 17 May 2020 23:15:01 +0200 Vincent Lefevre wrote: >On 2020-05-12 13:55:25 +0200, Andreas Ronnquist wrote: >> The default setting is Ctrl+Right/Ctrl+Left to switch tabs, > >I've just installed sakura to try it, and this is what I've noticed. >Ctrl+Right/Ctrl+Left works, but not Alt+Right/Alt+Left. > >The sakura(1) man page says about the default: > > Alt + Left cursor -> Previous tab > Alt + Right cursor -> Next tab > >So, either the default is buggy, or the man page is incorrect. > Thanks - I have submitted a Merge proposal upstream simply changing the man page, and will apply that patch to the Debian packaging and release a new Debian version as soon as it is accepted upstream. best /Andreas Rönnquist gus...@debian.org
Bug#960968: tpm2-pkcs11: FTBFS on hppa - broken configure test for -fstack-protector-all
Source: tpm2-pkcs11 Version: 1.2.0-1 Severity: normal Dear Maintainer, The build of tpm2-pkcs11 fails on hppa with the following error: libtool: compile: gcc -DHAVE_CONFIG_H -I. -I./src/lib -Wdate-time -D_FORTIFY_SOURCE=2 -I./src -I./src/lib -Wall -Wextra -Werror -Wformat -Wformat-security -Wstack-protector -fstack-protector-all -Wstrict-overflow=5 -O2 -fPIC -pthread -g -O2 -fdebug-prefix-map=/<>=. -Wformat -Werror=format-security -g -c src/lib/attrs.c -fPIC -DPIC -o src/lib/.libs/attrs.o cc1: error: ‘-fstack-protector’ not supported for this target [-Werror] cc1: all warnings being treated as errors make[1]: *** [Makefile:1577: src/lib/digest.lo] Error 1 See: https://buildd.debian.org/status/fetch.php?pkg=tpm2-pkcs11&arch=hppa&ver=1.2.0-1&stamp=1589690866&raw=0 The problem is the configure check for -fstack-protector-all is broken: configure:12151: checking whether C compiler accepts -fstack-protector-all configure:12170: gcc -c -g -O2 -fdebug-prefix-map=/home/dave/debian/tpm2-pkcs11/tpm2-pkcs11-1.2.0=. -Wformat -Werror=format-security -g -fstack-protector-all -Wdate-time -D_FORTIFY_SOURCE=2 conftest.c >&5 cc1: warning: '-fstack-protector' not supported for this target configure:12170: $? = 0 configure:12178: result: yes As you can see, there is a warning but -Werror is not passed in the configure check, so the test passes. There is a similar problem in tpm2-tools. This problem also affects alpha and ia64. Regards, Dave Anglin -- System Information: Debian Release: bullseye/sid APT prefers buildd-unstable APT policy: (500, 'buildd-unstable'), (500, 'unstable') Architecture: hppa (parisc64) Kernel: Linux 4.14.180+ (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#960819: squid command failure without systemd
Control: tags -1 + moreinfo On Monday, May 18 2020, I wrote: > On Monday, May 18 2020, I wrote: > >> On Sunday, May 17 2020, Amos Jeffries wrote: >> >>> Since the /run/squid directory now depends on systemd squid.service file >>> for existence the 'squid' binary cannot be run. >>> >>> This breaks all non-systemd init systems, multi-tenant installations, >>> and scripts running the squid binary for control commands. >>> >>> >>> When started without the "service squid" systemd-specific command Squid >>> produces: >>> >>> 2020/05/17 17:07:48| FATAL: failed to open /run/squid/squid.pid: (2) No >>> such file or directory >>> exception location: File.cc(190) open >> >> Thanks for the report. Can you please provide more info on how you're >> starting the service? Are you using the /etc/init.d/squid script? > > Also: I assume you have squid's apparmor profile enabled. If that's the > case, then could you please try to reload its profile? > > # apparmor_parser -r /etc/apparmor.d/usr.sbin.squid > > and try again? > > If this works, then it's the same bug I'm experiencing after upgrading > squid, and I have a fix for that. Just a few more details I've been able to gather this afternoon. I'm using a Debian sid VM where I installed sysvinit to replace systemd. I wasn't able to reproduce the problem reported above, even after activating the apparmor profile before upgrading. If you look at the /etc/init.d/squid script, you can see that the startup function does create the /run/squid/ directory. I will need more info to investigate this bug. Thanks, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible https://sergiodj.net/ signature.asc Description: PGP signature
Bug#960449: openldap: fix backup directory naming for multiple reconfigure calls
Oops
On Mon, May 18, 2020 at 5:12 PM Ryan Tandy wrote:
>
> Control: tag -1 moreinfo
>
> Hi Andreas, I think the patch is missing... :)
Here you go:
diff --git a/debian/slapd.scripts-common b/debian/slapd.scripts-common
index 9af6262f59..e11d2272de 100644
--- a/debian/slapd.scripts-common
+++ b/debian/slapd.scripts-common
@@ -365,6 +365,12 @@ compute_backup_path() { # {{{
id="$OLD_VERSION"
[ -n "$id" ] || id=`date +%Y%m%d-%H%M%S`
target="/var/backups/$basedn-$id.ldapdb"
+ # Configuration via dpkg-reconfigure.
+ # The backup directory already exists when reconfigured
+ # twice or more: append a timestamp.
+ if [ -e "${target}" ] && ([ "$MODE" = reconfigure ] || [ "$DEBCONF_RECONFIGURE" ]); then
+ target="$target-`date +%Y%m%d-%H%M%S`"
+ fi
if [ -e "$target" ] && [ -z "$ok_exists" ]; then
echo >&2
echo >&2 " Backup path $target exists. Giving up..."
Bug#960967: mark python3-soupsieve Multi-Arch: foreign
Package: python3-soupsieve
Version: 2.0-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
Control: affects -1 + src:ariba src:beancount src:calibre src:ceph src:lxml
src:opencv src:pandas src:qiskit-terra src:sunpy
The affected packages cannot satisfy their cross Build-Depends, because
they transitively Build-Depends on python3-soupsieve. In general,
Architecture: all packages can never satisfy cross Build-Depends unless
marked Multi-Arch: foreign or annotated :native. In the case of
python3-soupsieve, Multi-Arch: foreign is reasonable, because it is a
pure Python module without architecture-dependent dependencies. Please
consider applying the attached patch.
Helmut
diff --minimal -Nru soupsieve-2.0/debian/changelog
soupsieve-2.0/debian/changelog
--- soupsieve-2.0/debian/changelog 2020-04-13 18:48:31.0 +0200
+++ soupsieve-2.0/debian/changelog 2020-05-18 17:25:11.0 +0200
@@ -1,3 +1,10 @@
+soupsieve (2.0-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Mark python3-soupsieve Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne Mon, 18 May 2020 17:25:11 +0200
+
soupsieve (2.0-1) unstable; urgency=medium
* New upstream release
diff --minimal -Nru soupsieve-2.0/debian/control soupsieve-2.0/debian/control
--- soupsieve-2.0/debian/control2020-04-13 18:48:31.0 +0200
+++ soupsieve-2.0/debian/control2020-05-18 17:25:10.0 +0200
@@ -20,6 +20,7 @@
Package: python3-soupsieve
Architecture: all
+Multi-Arch: foreign
Depends: ${misc:Depends}, ${python3:Depends}
Description: modern CSS selector implementation for BeautifulSoup (Python 3)
Soup Sieve is a CSS selector library designed to be used with Beautiful Soup 4
Bug#960945: po4a: Double spacing generated when source contains parens on EOL
Hello Guillem, actually, the POD parser in po4a is implemented with a third party library. I cannot do anything unless I completely reimplement the parser myself. I would rather advise to use asciidoc for a newly written documentation. I'm considering converting the po4a doc to this format, actually. Sorry, Mt. - Le 18 Mai 20, à 18:58, Guillem Jover guil...@debian.org a écrit : > Package: po4a > Version: 0.58.1 > Severity: normal > > Hi! > > When there is a closing parenthesis at the end of line, po4a parses it > and injects two spaces in the msgid text. I've noticed this when > reviewing the generated «.po» files from both troff and POD source. > > Here's a test case: > > ,--- test.pod --- > =head1 NAME > > test - some test > > =head1 DESCRIPTION > > Some B(5) > some other (parenthetical text) > which produce (only when at the end of line) double spacing, > in the generated (.po) > file. > `--- > > ,--- sh --- > $ po4a-gettextize -f pod -m test.pod > […] > #. type: textblock > #: test.pod:7 > msgid "" > "Some B(5) some other (parenthetical text) which produce (only when " > "at the end of line) double spacing, in the generated (.po) file." > msgstr "" > `--- > > Of course one problem that fixing this is that it will imply probably > tons of fuzzying, which might even flip-flop depending on the po4a > version used, so perhaps an explicit option would be required here to > control the behavior, not sure. :/ > > Thanks, > Guillem
Bug#960449: openldap: fix backup directory naming for multiple reconfigure calls
Control: tag -1 moreinfo Hi Andreas, I think the patch is missing... :)
Bug#960965: kazoo: autopkgtest regression: kazoo.handlers.threading.KazooTimeoutError: Connection time-out
Source: kazoo
Version: 2.7.0-2
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
Dear maintainer(s),
With a recent upload of kazoo the autopkgtest of kazoo fails in testing
when that autopkgtest is run with the binary packages of kazoo from
unstable. It passes when run with only packages from testing. In tabular
form:
passfail
kazoo from testing2.7.0-2
all others from testingfrom testing
I copied some of the output at the bottom of this report.
Currently this regression is blocking the migration to testing [1]. 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
[1] https://qa.debian.org/excuses.php?package=kazoo
https://ci.debian.net/data/autopkgtest/testing/amd64/k/kazoo/5541537/log.gz
+ export ZOOKEEPER_PATH=/usr/share/java
+ + dpkgawk {print $3}
-l
+ grep libzookeeper-java
+ sed -E s/([0-9]+:)?([^-]+)([-~+].+)?/\2/
+ export ZOOKEEPER_VERSION=3.4.13
+ python3 -m nose -d -v kazoo.tests
/tmp/autopkgtest-lxc.c_g8cpxq/downtmp/build.xs6/src/kazoo/protocol/serialization.py:114:
SyntaxWarning: "is" with a literal. Did you mean "=="?
read_only = bool_struct.unpack_from(bytes, offset)[0] is 1
/tmp/autopkgtest-lxc.c_g8cpxq/downtmp/build.xs6/src/kazoo/protocol/serialization.py:449:
SyntaxWarning: "is" with a literal. Did you mean "=="?
return cls(t, done is 1, err), offset
test_barrier_exists (kazoo.tests.test_barrier.KazooBarrierTests) ...
SLF4J: Detected both log4j-over-slf4j.jar AND bound slf4j-log4j12.jar on
the class path, preempting StackOverflowError.
SLF4J: See also http://www.slf4j.org/codes.html#log4jDelegationLoop for
more details.
Exception in thread "main" java.lang.ExceptionInInitializerError
at org.slf4j.impl.StaticLoggerBinder.(StaticLoggerBinder.java:72)
at
org.slf4j.impl.StaticLoggerBinder.(StaticLoggerBinder.java:45)
at org.slf4j.LoggerFactory.bind(LoggerFactory.java:150)
at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:124)
at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:412)
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:357)
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:383)
at
org.apache.zookeeper.server.quorum.QuorumPeerMain.(QuorumPeerMain.java:67)
Caused by: java.lang.IllegalStateException: Detected both
log4j-over-slf4j.jar AND bound slf4j-log4j12.jar on the class path,
preempting StackOverflowError. See also
http://www.slf4j.org/codes.html#log4jDelegationLoop for more details.
at
org.slf4j.impl.Log4jLoggerFactory.(Log4jLoggerFactory.java:54)
... 8 more
SLF4J: Detected both log4j-over-slf4j.jar AND bound slf4j-log4j12.jar on
the class path, preempting StackOverflowError.
SLF4J: See also http://www.slf4j.org/codes.html#log4jDelegationLoop for
more details.
Exception in thread "main" java.lang.ExceptionInInitializerError
at org.slf4j.impl.StaticLoggerBinder.(StaticLoggerBinder.java:72)
at
org.slf4j.impl.StaticLoggerBinder.(StaticLoggerBinder.java:45)
at org.slf4j.LoggerFactory.bind(LoggerFactory.java:150)
at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:124)
at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:412)
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:357)
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:383)
at
org.apache.zookeeper.server.quorum.QuorumPeerMain.(QuorumPeerMain.java:67)
Caused by: java.lang.IllegalStateException: Detected both
log4j-over-slf4j.jar AND bound slf4j-log4j12.jar on the class path,
preempting StackOverflowError. See also
http://www.slf4j.org/codes.html#log4jDelegationLoop for more details.
at
org.slf4j.impl.Log4jLoggerFactory.(Log4jLoggerFactory.java:54)
... 8 more
SLF4J: Detected both log4j-over-slf4j.jar AND bound slf4j-log4j12.jar on
the class path, preempting StackOverflowError.
SLF4J: See also http://www.slf4j.org/codes.html#log4jDelegationLoop for
more details.
Exception in thread "main" java.lang.ExceptionInInitializerError
at org.slf4j.impl.StaticLoggerBinder.(StaticLoggerBinder.java:72)
at
org.slf4j.impl.StaticLoggerBinder.(StaticLoggerBinder.java:45)
at org.slf4j.LoggerFactory.bind(LoggerFactory.java:150)
at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:124)
at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:412)
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:357)
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:383)
at
org.apache.zookeeper.server.quorum.QuorumPeerMain.(QuorumPeerMain.java:67)
Caused by: java.lang.IllegalStateException: Detected both
log4j-over-slf4j.jar A
Bug#960949: po4a: Cannot match some generic text in addenda header
Hello Guillem, thanks for your interest. I was thinking about a specific mode=eof that would not need a position nor a boundary to put the addendum at the end of the file. Would it fit your needs? Bye, Mt. - Le 18 Mai 20, à 19:31, Guillem Jover guil...@debian.org a écrit : > Package: po4a > Version: 0.58.1-1 > Severity: normal > > Hi! > > While converting the dpkg man pages from troff to POD, I needed to > convert the addenda too, which was using this header for all addenda: > > ,--- > PO4A-HEADER:mode=after;position=^\.TH;beginboundary=FakePo4aBoundary > `--- > > Which is nice and generic. But for POD I had to use a different one per > locale, such as: > > ,--- > PO4A-HEADER:mode=after;position=^=head1 NOM;beginboundary=FakePo4aBoundary > `--- > > Because I was unable to match neither «^=encoding» nor the > «GENERATED FILE» string inserted by po4a on the output files. And while > the second might be fragile, as it could change, the former is part of > the source, so under the developer control, and it would be nice to be > able to use that. > > Using a localized section name works, but seems problematic as it depends > on the translation for that section not changing, and while certainly not > fatal, it's a bit annoying. :) > > Thanks, > Guillem
Bug#959143: RFS: libgrokj2k/7.1.0-1 [ITP] -- JPEG 2000 image compression/decompression library
On Fri, May 01, 2020 at 09:24:18PM -0400, Aaron Boxer wrote: > Hi Adam, > Thanks a lot for testing this I've fixed the build error - please try it > again when you have time. Hi! Sorry for the delay. There's one problem left: the .symbols file for libgrokj2k1 declares a dependency on libgrokj2k (rather than 2k1). Please bump it a year ahead :) Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good. ⢿⡄⠘⠷⠚⠋⠀ -- on #linux-sunxi ⠈⠳⣄
Bug#960964: Some files are not getting included in the non-PDF docs
Package: libgdal-doc Version: 3.0.4+dfsg-1 In https://github.com/OSGeo/gdal/issues/2574 we observe some files are not getting included in the non-PDF docs.
Bug#960842: add -go wrappers and golang-go-for-host
Hi,
On Mon, May 18, 2020 at 09:53:04AM -0700, Tianon Gravi wrote:
> I'm curious though, is there a technical reason we need so many extra
> binary packages, especially when each binary package amounts to
> essentially a single very short shell script? Couldn't we instead
> package them all together into one binary package, something like
> "golang-go-multiarch-wrappers" ?
We could try fusing the golang-go- either into
golang-go-for-host or into a shared golang-go-multiarch-wrappers. If we
try the former, golang-go-for-host would have to depend on a native
golang-go. My patch expresses that by going via arch:all m-a:foreign
packages. The golang-go-for-host -> golang-go- dependency
looses its architecture constraint due to Multi-Arch: foreign. If
golang-go-for-host were to depend on golang-go directly, we'd have to
make it Multi-Arch: foreign or we'd have to make it Multi-Arch: allowed
and annotate the dependency with :any. The outcome of that isn't
obvious.
So the other way would be golang-go-multiarch-wrappers. Unlike with gcc,
this is actually feasible, because we know the available targets ahead
of time. We cannot retroactively add architectures without rebuilding
all of go. So that actually works. It just didn't occur to me any
earlier. I'd prefer to have this package provide all the
golang-go- instances as virtual packages though.
Another issue with fusing into golang-go-for-host (but not the other
way) is that it requires adding the relevant target architecture using
dpkg --add-architecture.
A weak argument is consistency with gccgo. This is precisely the layout
that gccgo uses (except that gccgo uses Arch:any packages instead of
Arch:all). Keeping this layout as virtual packages seems sensible
though.
So yeah, I think it's actually possible to fuse them into a
golang-go-multiarch-wrappers package. Let me propose a different name
though: golang-go-for-build. That way it'd precisely mirrors what we do
for binutils already and what we will be doing for the gcc frontends.
Here you go. Thank you for the valuable question.
Helmut
diff --minimal -Nru golang-defaults-1.14~1/debian/changelog
golang-defaults-1.14~1.1/debian/changelog
--- golang-defaults-1.14~1/debian/changelog 2020-03-07 13:47:33.0
+0100
+++ golang-defaults-1.14~1.1/debian/changelog 2020-05-17 14:16:54.0
+0200
@@ -1,3 +1,10 @@
+golang-defaults (2:1.14~1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Introduce golang-go-for-host package. (Closes: #-1)
+
+ -- Helmut Grohne Sun, 17 May 2020 14:16:54 +0200
+
golang-defaults (2:1.14~1) unstable; urgency=medium
* Update to Go 1.14 (src:golang-1.14). Closes: #952831
diff --minimal -Nru golang-defaults-1.14~1/debian/control
golang-defaults-1.14~1.1/debian/control
--- golang-defaults-1.14~1/debian/control 2020-03-07 13:45:40.0
+0100
+++ golang-defaults-1.14~1.1/debian/control 2020-05-17 14:16:54.0
+0200
@@ -70,6 +70,54 @@
native toolchain ("gc compiler"). Packages that want to build with whichever
of gc or gccgo is available should depend on golang-any.
+Package: golang-go-for-build
+Architecture: all
+Multi-Arch: foreign
+Depends: golang-go (>= ${source:Version})
+Provides:
+ golang-go-x86-64-linux-gnu,
+ golang-go-aarch64-linux-gnu,
+ golang-go-arm-linux-gnueabi,
+ golang-go-arm-linux-gnueabihf,
+ golang-go-i686-linux-gnu,
+ golang-go-mips-linux-gnu,
+ golang-go-mips64el-linux-gnuabi64,
+ golang-go-mipsel-linux-gnu,
+ golang-go-powerpc64le-linux-gnu,
+ golang-go-riscv64-linux-gnu,
+ golang-go-s390x-linux-gnu,
+Description: Go programming language compiler wrappers
+ The Go programming language is an open source project to make programmers more
+ productive. Go is expressive, concise, clean, and efficient. Its concurrency
+ mechanisms make it easy to write programs that get the most out of multicore
+ and networked machines, while its novel type system enables flexible and
+ modular program construction. Go compiles quickly to machine code yet has the
+ convenience of garbage collection and the power of run-time reflection. It's a
+ fast, statically typed, compiled language that feels like a dynamically typed,
+ interpreted language.
+ .
+ This is a wrapper package. A dependency on golang-go-for-build provides a go
+ compiler for native builds. A dependency on golang-go- provides a
+ -go compiler wrapper for targeting the named architcture.
+
+Package: golang-go-for-host
+Architecture: amd64 arm64 armel armhf i386 mips mips64el mipsel ppc64el
riscv64 s390x
+Multi-Arch: same
+Depends: golang-go${archsuffix} (>= ${source:Version})
+Description: Go programming language compiler wrapper
+ The Go programming language is an open source project to make programmers more
+ productive. Go is expressive, concise, clean, and efficient. Its concurrency
+ mechanisms make it easy to write programs that get the most out of multicore
+ and networked machines
Bug#960963: dovecot: CVE-2020-10957 CVE-2020-10958 CVE-2020-10967
Source: dovecot Version: 1:2.3.7.2-1 Severity: grave Tags: security upstream Justification: user security hole Control: found -1 1:2.3.4.1-5+deb10u1 Control: found -1 1:2.3.2-1 Hi, The following vulnerabilities were published for dovecot. CVE-2020-10957[0]: | In Dovecot before 2.3.10.1, unauthenticated sending of malformed | parameters to a NOOP command causes a NULL Pointer Dereference and | crash in submission-login, submission, or lmtp. CVE-2020-10958[1]: | In Dovecot before 2.3.10.1, a crafted SMTP/LMTP message triggers an | unauthenticated use-after-free bug in submission-login, submission, or | lmtp, and can lead to a crash under circumstances involving many | newlines after a command. CVE-2020-10967[2]: | In Dovecot before 2.3.10.1, remote unauthenticated attackers can crash | the lmtp or submission process by sending mail with an empty | localpart. If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2020-10957 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-10957 [1] https://security-tracker.debian.org/tracker/CVE-2020-10958 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-10958 [2] https://security-tracker.debian.org/tracker/CVE-2020-10967 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-10967 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#960962: src:r-cran-roxygen2: fails to migrate to testing for too long: not installable on armel
Source: r-cran-roxygen2 Version: 7.0.2-1 Severity: serious Control: close -1 7.1.0-2 Tags: sid bullseye User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), As recently announced [1], the Release Team now considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing. Your package src:r-cran-roxygen2 in its current version in unstable has been trying to migrate for 60 days [2]. Hence, I am filing this bug. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bullseye, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Your package gained a new dependency (r-cran-knitr) which isn't installable on armel due to node lacking there. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=r-cran-roxygen2 signature.asc Description: OpenPGP digital signature
Bug#960961: Please update path to udisks2-inhibit
Package: gparted Version: 1.0.0-0.1 Severity: important Hi, in udisks2 2.8.4-2, the udisks2 binaries where moved from /usr/lib to /usr/libexec. According to https://codesearch.debian.net, the gparted script uses /usr/lib/udisks2/udisks2-inhibit Please change that to /usr/libexec/udisks2/udisks2-inhibit You might consider adding a versioned Breaks against udisks2 (<< 2.8.4-2) as well. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.6.0-1-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gparted depends on: ii gparted-common1.0.0-0.1 ii libatkmm-1.6-1v5 2.28.0-2 ii libc6 2.30-8 ii libcairomm-1.0-1v51.12.2-4 ii libgcc-s1 [libgcc1] 10.1.0-1 ii libgcc1 1:10.1.0-1 ii libglib2.0-0 2.64.2-1 ii libglibmm-2.4-1v5 2.64.2-1 ii libgtk-3-03.24.20-1 ii libgtkmm-3.0-1v5 3.24.2-1 ii libpangomm-1.4-1v52.42.1-1 ii libparted-fs-resize0 3.3-4 ii libparted23.3-4 ii libsigc++-2.0-0v5 2.10.2-1 ii libstdc++610.1.0-1 ii libuuid1 2.35.1-5 ii policykit-1 0.105-26 gparted recommends no packages. Versions of packages gparted suggests: pn dmraid ii dmsetup2:1.02.167-1+b1 ii dosfstools 4.1-2 ii e2fsprogs 1.45.6-1 ii gpart 1:0.3-8 pn jfsutils ii kpartx 0.8.3-1 ii mtools 4.0.24-1 ii ntfs-3g1:2017.3.23AR.3-3 pn reiser4progs ii reiserfsprogs 1:3.6.27-3+b1 pn udftools ii xfsprogs 5.6.0-1+b1 ii yelp 3.36.0-1 -- no debconf information
Bug#960960: Please update paths for upower and udisks2
Source: refpolicy Severity: normal Hi, the upower and udisks2 executables were moved to /usr/libexec in recent uploads. According to https://codesearch.debian.net your package still uses the old paths /usr/lib/udisks2/udisksd-- gen_context(system_u:object_r:devicekit_disk_exec_t,s0) /usr/lib/upower/upowerd -- gen_context(system_u:object_r:devicekit_power_exec_t,s0) Please consider updating them to use /usr/libexec/udisks2/udisksd /usr/libexec/upowerd -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.6.0-1-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#960649: Removed package(s) from unstable
On Mon, 2020-05-18 at 20:40 +0200, Mattias Ellert wrote: > 1. Have you removed the 2.6.8-1 version? It is still listed as being > part of unstable here: https://packages.debian.org/unstable/gfal2 > I know there is some delay in those pages to be updated, but getting > THAT VERSION removed was the purpose of filing the bug in the first > place. If it is not removed, the problem is not solved. That page looks suspicious as it claims arm64 is an "unoffical port". Someone on IRC suspects it might use an ancient Packages index from ports.d.o from 2014 for arm64 that gets shown when the main archive no longer has the package... I would recommend either using the Packages/Sources indices from mirrors (with delayed updates) or the `rmadison` tool from the devscripts package which accesses the authoritative database used by dak. `rmadison` is probably better as there are no delays with updates and sometimes a package is not shown in the Packages index. The current state in the archive is this: $ rmadison -S -s unstable gfal2 gfal2| 2.17.3-1 | unstable | source, all gfal2-doc| 2.17.3-1 | unstable | all gfal2-plugin-dcap| 2.17.3-1 | unstable | amd64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x gfal2-plugin-file| 2.17.3-1 | unstable | amd64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x gfal2-plugin-gridftp | 2.17.3-1 | unstable | amd64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x gfal2-plugin-http| 2.17.3-1 | unstable | amd64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x gfal2-plugin-mock| 2.17.3-1 | unstable | amd64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x gfal2-plugin-sftp| 2.17.3-1 | unstable | amd64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x gfal2-plugin-srm | 2.17.3-1 | unstable | amd64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x libgfal-transfer2| 2.17.3-1 | unstable | amd64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x libgfal2-2 | 2.17.3-1 | unstable | amd64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x libgfal2-dev | 2.17.3-1 | unstable | amd64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x > 2. Is a re-upload really necessary? A re-upload wouldn't end up in NEW > anyway, since no new binary packages would be created by the new upload > that are not already in unstable (except for on arm64). If the existing > binary arm64 build can't be put back in, a binnmu for arm64 should be > sufficient. It would be wasteful to rebuild the package for all > architectures. I restored the arm64 binaries (2.17.3-1). Ansgar
Bug#960371: fhist FTBFS with bison 3.6.1
Followup-For: Bug #960371
Control: tag -1 patch
Hi,
since I had to fix the same bug in libexplain, I'm quickly did a patch for
fhist as well.
Andreas
diff -Nru fhist-1.18/debian/changelog fhist-1.18/debian/changelog
--- fhist-1.18/debian/changelog 2015-07-01 09:41:29.0 +0200
+++ fhist-1.18/debian/changelog 2020-05-18 19:06:01.0 +0200
@@ -1,3 +1,11 @@
+fhist (1.18-3) UNRELEASED; urgency=medium
+
+ * Get rid of crude sed manipulation on bison output (breaking with bison
+3.6.1) and define api.prefix instead, thanks to Akim Demaille.
+(Closes: #960371)
+
+ -- Andreas Beckmann Mon, 18 May 2020 19:06:01 +0200
+
fhist (1.18-2) unstable; urgency=medium
* pass -fgnu89-inline to gcc to fix "FTBFS with GCC-5" (Closes: #777849)
diff -Nru fhist-1.18/debian/patches/sanitize-bison.patch
fhist-1.18/debian/patches/sanitize-bison.patch
--- fhist-1.18/debian/patches/sanitize-bison.patch 1970-01-01
01:00:00.0 +0100
+++ fhist-1.18/debian/patches/sanitize-bison.patch 2020-05-18
19:06:01.0 +0200
@@ -0,0 +1,36 @@
+Author: Andreas Beckmann
+Description: sanitize bison usage
+ use
+ %define api.prefix {...}
+ instead of crude
+ sed -e 's/[yY][yY]/.../g'
+
+ Thanks to Akim Demaille for the hint! (#960608)
+
+--- a/Makefile.in
b/Makefile.in
+@@ -567,11 +567,11 @@ common/sub/expr_gram.gen.c common/sub/ex
+ common/sub/expr_gram.y
+ @echo Expect no conflicts:
+ $(YACC) -d common/sub/expr_gram.y
+- sed -e 's/[yY][yY]/sub_expr_gram_/g' -e '/#include./d' \
++ sed -e '/#include./d' \
+ -e '/#include./d' -e '/#include./d' \
+ -e '/#include./d' y.tab.c > \
+ common/sub/expr_gram.gen.c
+- sed -e 's/[yY][yY]/sub_expr_gram_/g' y.tab.h > \
++ sed -e '' y.tab.h > \
+ common/sub/expr_gram.gen.h
+ rm y.tab.c y.tab.h
+
+--- a/common/sub/expr_gram.y
b/common/sub/expr_gram.y
+@@ -17,6 +17,8 @@
+ *
Bug#960046: transition: sane-backends
Hello Rene, Am Freitag, den 08.05.2020, 21:56 +0200 schrieb Rene Engelhard: > Hi, > > On Fri, May 08, 2020 at 07:11:09PM +0200, Jörg Frings-Fürst wrote: > > libreoffice > > Note libreoffice only Suggests it (and it dlopen()s libsane.so.1). > > A rebuild will change the Suggests since > https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/-/commit/a11f5b7381097ea0ae9a3e03db909f4075628935 > (2 years ago, when the last rename was attempted.) > but this hasn't to be done immediately. > > So you either can bin-NMU it or not, it will pick > the right library up on the next upload. > that's right.But it belongs in the list of packages to be checked. But if this leads to problems I can change the ben file. > regards, > > Rene CU Jörg -- New: GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB 30EE 09F8 9F3C 8CA1 D25D GPG key (long) : 09F89F3C8CA1D25D GPG Key: 8CA1D25D CAcert Key S/N : 0E:D4:56 Old pgp Key: BE581B6E (revoked since 2014-12-31). Jörg Frings-Fürst D-54470 Lieser git: https://jff.email/cgit/ Threema: SYR8SJXB Wire: @joergfringsfuerst Skype:joergpenguin Ring: jff Telegram: @joergfringsfuerst My wish list: - Please send me a picture from the nature at your home. signature.asc Description: This is a digitally signed message part
Bug#959236: Scripterrors in ifenslave
Hi,
I would like to second that priority grave, bonding is right now not
working at all.
I found several issues with the script:
1.
add_master()
{
# Return if $IFACE is already a bonding interface.
[ -f "/sys/class/net/$IFACE/bonding/slaves" ] && return
ip link add dev "$IFACE" type bond
BOND_MASTER="$IFACE"
--
Bond master can't be set in the config and isn't set in the script. Do I
miss something here?
}
2.
enslave_slaves()
{
[ "$VERBOSITY" = 1 ] && v=-v
# echo BOND_SLAVES=$BOND_SLAVES
for slave in $BOND_SLAVES ; do
# if ifquery --state $slave 2>/dev/null || [ -n
"IFUPDOWN_$IFACE" ]; then
# Skipping interface that's already up or being
configured
# continue
# else
# if ifquery -l $slave 2>/dev/null; then
# ifup $slave
# else
ip link set "$slave" down 2>/dev/null
if ! sysfs_add slaves "$slave"
2>/dev/null ; then
echo "Failed to enslave $slave
to $IFACE." >&2
fi
# fi
# fi
done
}
The script never reaches the actual add slaves, it always bails out.
There must be a better way than my fix, which is not good.
3.
setup_master() {
add_master
early_setup_master
setup_master1
BOND_SLAVES="all"
enslave_slaves
setup_primary
}
Again BOND_SLAVES isn't anywhere set.
My config looks like this:
source /etc/network/interfaces.d/*
auto lo eth0 eth1 eth2
iface lo inet loopback
iface eth0 inet manual
hwaddress ether 70:85:c2:63:a2:56
iface eth1 inet manual
hwaddress ether 70:85:c2:63:a2:58
iface eth2 inet manual
hwaddress ether 70:85:c2:63:a2:60
auto bond0
iface bond0 inet static
bond-miimon 100
bond_downdelay 200
bond_updelay 200
bond_mode 2
bond_slaves eth0 eth1 eth2
address 192.168.2.254
netmask 255.255.255.0
network 192.168.2.0
broadcast 192.168.2.255
dns-nameservers 192.168.2.254
dns-search althea.home althea.wlan
gateway 192.168.2.100
Any chance for a decent fix?
Cheers,
Dirk.
Bug#960959: RM: certificatepatrol -- ROM; No longer usable after xul deprecation, dead upstream
X-Debugs-CC: certificatepat...@packages.debian.org Package: ftp.debian.org Severity: normal Justification: No longer usable after xul deprecation, dead upstream Hello, please remove the certificatepatrol package from unstable, and possibly from oldstable (Debian 9, stretch) as well. FWIW, it is already missing in testing and stable (Debian 10, buster). Rationale - longer version in the ITR[1]: This package is one of the many affected by the Mozilla massacer, in other words, it is no longer usable with a Mozilla product where XUL support has been removed. Also, upstream hasn't shown any activity for a while, so I've given up hope we'll see a re-write for webext. Sadly.. Christoph, soon-to-be ex-maintainer of certificatepatrol [1] https://bugs.debian.org/958920 signature.asc Description: PGP signature
Bug#960958: src:diploma: fails to migrate to testing for too long: maintainer built arch:all
Source: diploma Version: 1.2.14 Severity: serious Control: close -1 1.2.15 Tags: sid bullseye pending User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), As recently announced [1], the Release Team now considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing. Your package src:diploma in its current version in unstable has been trying to migrate for 60 days [2]. Hence, I am filing this bug. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bullseye, so it doesn't affect (old-)stable. Your package is only blocked because the arch:all binary package(s) aren't built on a buildd. Unfortunately the Debian infrastructure doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will shortly do a no-changes source-only upload to DELAYED/15, closing this bug. Please let me know if I should delay or cancel that upload. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=diploma signature.asc Description: OpenPGP digital signature
Bug#960942: [Pkg-utopia-maintainers] Bug#960942: Bug#960942: Bug#960942: network-manager: only (undocumented) numeric values work for connection.mdns
Michael Biebl writes: > Am 18.05.20 um 20:40 schrieb David Bremner: >> Michael Biebl writes: >> I was looking at NetworkManager.conf(5). >>> >>> Hm, I don't find any reference to connection.mdns= in >>> NetworkManager.conf(5), which is not surprising, since >>> NetworkManager.conf is about configuring the NetworkManager daemon and >>> not about creating connection profiles. >> >> I guess the = breaks the search; it's discussed in CONNECTION SECTION >> >> line 389 >> >>connection.mdns >>If unspecified, the ultimate default values depends on the DNS >> plugin. With systemd-resolved the >>default currently is "no" (0) and for all other plugins also "no" >> (0). >> > > But "0" is listed there, so not undocumented here. > I'm confused. 1 and 2 are not documented here. I had to find the correct values by trial and error. I was unable to determine from the documentation if the behaviour I was seeing was intended or a bug. Hence the bug report.
Bug#960957: jackd2 producing a lot of xruns with anything lower than sample rate 88200 or buffer size 4096
Package: jackd2 Version: 1.9.12~dfsg-2+b1 Severity: important Hi, I can't reliably run jackd2 with anything lower than sample rate 88200 or buffer size of 4096 without a big amount of xruns, which make it unusuable. When connecting an external USB audio interface, it is working OK and performs as expected, which makes me believe that there might be something wrong with how jackd or alsa handle the hardware. The soundcard is integrated in my Gigabyte AORUS X399 Pro motherboard: lspci -vvs 0a:00.3 ✔ chiquitin_root ● 20:32:22 0a:00.3 Audio device: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) HD Audio Controller DeviceName: Audio Codec ALC1220 Subsystem: Gigabyte Technology Co., Ltd Family 17h (Models 00h-0fh) HD Audio Controller Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Capabilities: [50] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- Capabilities: [64] Express (v2) Endpoint, MSI 00 DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <4us, L1 unlimited ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit 0.000W DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+ MaxPayload 256 bytes, MaxReadReq 512 bytes DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend- LnkCap: Port #0, Speed 8GT/s, Width x16, ASPM L0s L1, Exit Latency L0s <64ns, L1 <1us ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp+ LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 8GT/s (ok), Width x16 (ok) TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- DevCap2: Completion Timeout: Not Supported, TimeoutDis-, NROPrPrP-, LTR- 10BitTagComp-, 10BitTagReq-, OBFF Not Supported, ExtFmt-, EETLPPrefix- EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit- FRS-, TPHComp-, ExtTPHComp- AtomicOpsCap: 32bit- 64bit- 128bitCAS- DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled AtomicOpsCtl: ReqEn- LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete-, EqualizationPhase1- EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest- Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Address: fee0b000 Data: 4023 Capabilities: [100 v1] Vendor Specific Information: ID=0001 Rev=1 Len=010 Kernel driver in use: snd_hda_intel Kernel modules: snd_hda_intel Please let me know if you need more info. Best regards. -- System Information: Debian Release: bullseye/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.6.0-1-amd64 (SMP w/24 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages jackd2 depends on: ii coreutils 8.30-3+b1 ii debconf [debconf-2.0] 1.5.74 ii libasound2 1.2.2-2.1 ii libc6 2.30-8 ii libdbus-1-31.12.16-2 ii libexpat1 2.2.9-1 ii libgcc-s1 [libgcc1]10.1.0-1 ii libgcc11:10.1.0-1 ii libjack-jackd2-0 1.9.12~dfsg-2+b1 ii libopus0 1.3-1+b1 ii libreadline8 8.0-4 ii libsamplerate0 0.1.9-2 ii libsndfile11.0.28-7 ii libstdc++6 10.1.0-1 ii python 2.7.17-2 ii python-dbus1.2.16-2 Versions of packages jackd2 recommends: pn jackd2-firewire ii libpam-modules 1.3.1-5 pn qjackctl Versions of packages jackd2 suggests: pn jack-tools pn meterbridge -- debconf information: * jackd/tweak_rt_limits: true dpkg -l | egrep 'alsa|asound' ✔ chiq
Bug#960942: [Pkg-utopia-maintainers] Bug#960942: Bug#960942: Bug#960942: network-manager: only (undocumented) numeric values work for connection.mdns
Am 18.05.20 um 20:48 schrieb David Bremner: > Michael Biebl writes: > >> Am 18.05.20 um 20:40 schrieb David Bremner: >>> Michael Biebl writes: >>> > > I was looking at NetworkManager.conf(5). Hm, I don't find any reference to connection.mdns= in NetworkManager.conf(5), which is not surprising, since NetworkManager.conf is about configuring the NetworkManager daemon and not about creating connection profiles. >>> >>> I guess the = breaks the search; it's discussed in CONNECTION SECTION >>> >>> line 389 >>> >>>connection.mdns >>>If unspecified, the ultimate default values depends on the DNS >>> plugin. With systemd-resolved the >>>default currently is "no" (0) and for all other plugins also >>> "no" (0). >>> >> >> But "0" is listed there, so not undocumented here. >> I'm confused. > > 1 and 2 are not documented here. I had to find the correct values by > trial and error. I was unable to determine from the documentation if the > behaviour I was seeing was intended or a bug. > > Hence the bug report. > It's documented in nm-settings. I'm not sure if it makes sense to duplicate it. Anyway, please convince upstream if you see a defiency in the man page. I obviously fail to do so, so I can't file an upstream bug report in your stead. signature.asc Description: OpenPGP digital signature
Bug#960942: [Pkg-utopia-maintainers] Bug#960942: Bug#960942: Bug#960942: network-manager: only (undocumented) numeric values work for connection.mdns
Am 18.05.20 um 20:40 schrieb David Bremner: > Michael Biebl writes: > >>> >>> I was looking at NetworkManager.conf(5). >> >> Hm, I don't find any reference to connection.mdns= in >> NetworkManager.conf(5), which is not surprising, since >> NetworkManager.conf is about configuring the NetworkManager daemon and >> not about creating connection profiles. > > I guess the = breaks the search; it's discussed in CONNECTION SECTION > > line 389 > >connection.mdns >If unspecified, the ultimate default values depends on the DNS > plugin. With systemd-resolved the >default currently is "no" (0) and for all other plugins also "no" > (0). > But "0" is listed there, so not undocumented here. I'm confused. signature.asc Description: OpenPGP digital signature
Bug#960942: [Pkg-utopia-maintainers] Bug#960942: Bug#960942: Bug#960942: network-manager: only (undocumented) numeric values work for connection.mdns
Michael Biebl writes: >> >> I was looking at NetworkManager.conf(5). > > Hm, I don't find any reference to connection.mdns= in > NetworkManager.conf(5), which is not surprising, since > NetworkManager.conf is about configuring the NetworkManager daemon and > not about creating connection profiles. I guess the = breaks the search; it's discussed in CONNECTION SECTION line 389 connection.mdns If unspecified, the ultimate default values depends on the DNS plugin. With systemd-resolved the default currently is "no" (0) and for all other plugins also "no" (0). There actually is a reference to nm-settings just above. line 369 Not all properties can be overwritten, only the following properties are supported to have their default values configured (see nm-settings(5) for details). A default value is only consulted if the corresponding per-connection value explicitly allows for that.
Bug#960956: RFS: zhcon/1:0.2.6-17 -- Fast console CJK system using FrameBuffer (main program)
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "zhcon" * Package name : zhcon Version : 1:0.2.6-17 Upstream Author : ejoy * URL : https://sourceforge.net/projects/zhcon/ * License : GPL-2.0+ * Vcs : https://salsa.debian.org/chinese-team/zhcon Section : utils It builds those binary packages: zhcon - Fast console CJK system using FrameBuffer (main program) zhcon-data - Fast console CJK system using FrameBuffer (data files) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/zhcon Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/z/zhcon/zhcon_0.2.6-17.dsc Changes since the last upload: [ Debian Janitor ] * Drop no longer supported add-log-mailing-address setting from debian/changelog. * Set debhelper-compat version in Build-Depends. * Set upstream metadata fields: Archive, Repository. * Fix day-of-week for changelog entry 1:0.2.6-2. . [ 肖盛文 ] * d/clean: add REVISION src/zhcon.ggo * d/control: - Bump debhelper-compat (= 13) - Bump Standards-Version: 4.5.0 - add Rules-Requires-Root: no - add New Uploaders: xiao sheng wen - add Homepage: https://sourceforge.net/projects/zhcon/ * d/rules: - delete dh_missing --fail-missing - fix lintian: no-dh-sequencer by add execute_before_dh_autoreconf: * d/copyright: add Upstream-Contact: * upstream/metadata: add Bug-Database: Regards, -- 肖盛文 Faris Xiao 邮箱：atzli...@yeah.net 微信：atzlinux ＱＱ：909868357 铜豌豆 Linux 基于 Debian 的 Linux 中文桌面操作系统：https://www.atzlinux.com signature.asc Description: OpenPGP digital signature
Bug#960954: qgis: FTBFS with Qt 5.14: undefined reference to `Qt3DExtras::Qt3DWindow::Qt3DWindow(QScreen*)'
Control: tags -1 pending Hi Dmitry, Thanks for reporting this issue. On 5/18/20 7:58 PM, Dmitry Shachnev wrote: > b) Make that block conditional and enable it only for Qt < 5.14. The rules have been updated to test for the existence of /usr/include/$(DEB_BUILD_MULTIARCH)/qt5/Qt3DExtras/qt3dextrasversion.h and won't use the embedded copy of the headers when it does. qgis (3.10.6+dfsg-1~exp1) is currently in NEW, this change will be included in the upload to unstable once it gets through NEW. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 signature.asc Description: OpenPGP digital signature
Bug#960933: python3-sasview: Package description says "Python 2"
Package: python3-sasview Severity: minor Dear Maintainer, The package description says: > Small Angle Scattering Analysis (Python 2) > > This package installs the library for Python 2. https://packages.debian.org/bullseye/python3-sasview This is rather confusing. N.B. I am writing this from a Debian 10 system but referring to the package in bullseye / sid (and Ubuntu focal). -- System Information: Debian Release: 10.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-8-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled signature.asc Description: This is a digitally signed message part.
Bug#960955: inkscape: crash when resizing canvas on a system running wayland
Package: inkscape Version: 1.0-1 Severity: normal Dear Maintainer, On a system running wayland with dual monitors, when I open an inkscape document and press 5 to resize to my screen inkscape crashes. Originally I thought it was my document that was causing problems but I could reproduce it with the default blank document you get when running inkscape with no arguments. Here's the output of: inkscape command: $inkscape ** (org.inkscape.Inkscape:16310): WARNING **: 11:07:16.617: Fonts dir '/usr/share/inkscape/fonts' does not exist and will be ignored. ** (org.inkscape.Inkscape:16310): WARNING **: 11:07:16.617: Fonts dir '/home/diane/.config/inkscape/fonts' does not exist and will be ignored. (org.inkscape.Inkscape:16310): Gtk-CRITICAL **: 11:07:17.965: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GdlSwitcher (org.inkscape.Inkscape:16310): Gtk-CRITICAL **: 11:07:18.167: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GdlSwitcher (org.inkscape.Inkscape:16310): Gtk-CRITICAL **: 11:07:18.639: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GdlSwitcher (org.inkscape.Inkscape:16310): Gtk-CRITICAL **: 11:07:18.720: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GdlSwitcher inkscape: /build/inkscape-lcFFbl/inkscape-1.0/src/display/sp-canvas.cpp:2631: void SPCanvas::scrollTo(const Geom::Point&, unsigned int, bool): Assertion `device_scale == _device_scale' failed. Emergency save activated! Emergency save completed. Inkscape will close now. If you can reproduce this crash, please file a bug at https://inkscape.org/report with a detailed description of the steps leading to the crash, so we can fix it. (org.inkscape.Inkscape:16310): Gtk-CRITICAL **: 11:07:20.010: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GdlSwitcher (org.inkscape.Inkscape:16310): Gtk-CRITICAL **: 11:07:20.245: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GdlSwitcher (org.inkscape.Inkscape:16310): Gtk-CRITICAL **: 11:07:20.453: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GdlSwitcher Aborted (core dumped) $ coredumpctl gdb gdb> thread apply all bt Thread 8 (Thread 0x7f86cbfff700 (LWP 16317)): #0 futex_wait_cancelable (private=0, expected=0, futex_word=0x7f86e149470c ) at ../sysdeps/unix/sysv/linux/futex-internal.h:80 #1 __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x7f86e14942e0 , cond=0x7f86e14946e0 ) at pthread_cond_wait.c:508 #2 __pthread_cond_wait (cond=0x7f86e14946e0 , mutex=0x7f86e14942e0 ) at pthread_cond_wait.c:638 #3 0x7f86e1473df7 in GC_wait_marker () at pthread_support.c:2200 #4 0x7f86e1469bb2 in GC_help_marker (my_mark_no=my_mark_no@entry=11) at mark.c:1231 #5 0x7f86e1473dac in GC_mark_thread (id=) at pthread_support.c:379 #6 0x7f86e03e1f27 in start_thread (arg=) at pthread_create.c:479 #7 0x7f86e1f892ef in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 7 (Thread 0x7f86d97ca700 (LWP 16315)): #0 futex_wait_cancelable (private=0, expected=0, futex_word=0x7f86e149470c ) at ../sysdeps/unix/sysv/linux/futex-internal.h:80 #1 __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x7f86e14942e0 , cond=0x7f86e14946e0 ) at pthread_cond_wait.c:508 #2 __pthread_cond_wait (cond=0x7f86e14946e0 , mutex=0x7f86e14942e0 ) at pthread_cond_wait.c:638 #3 0x7f86e1473df7 in GC_wait_marker () at pthread_support.c:2200 #4 0x7f86e1469bb2 in GC_help_marker (my_mark_no=my_mark_no@entry=11) at mark.c:1231 #5 0x7f86e1473dac in GC_mark_thread (id=) at pthread_support.c:379 #6 0x7f86e03e1f27 in start_thread (arg=) at pthread_create.c:479 #7 0x7f86e1f892ef in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 6 (Thread 0x7f86d8fc9700 (LWP 16316)): #0 futex_wait_cancelable (private=0, expected=0, futex_word=0x7f86e149470c ) at ../sysdeps/unix/sysv/linux/futex-internal.h:80 --Type for more, q to quit, c to continue without paging--c #1 __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x7f86e14942e0 , cond=0x7f86e14946e0 ) at pthread_cond_wait.c:508 #2 __pthread_cond_wait (cond=0x7f86e14946e0 , mutex=0x7f86e14942e0 ) at pthread_cond_wait.c:638 #3 0x7f86e1473df7 in GC_wait_marker () at pthread_support.c:2200 #4 0x7f86e1469bb2 in GC_help_marker (my_mark_no=my_mark_no@entry=11) at mark.c:1231 #5 0x7f86e1473dac in GC_mark_thread (id=) at pthread_support.c:379 #6 0x7f86e03e1f27 in start_thread (arg=) at pthread_create.c:479 #7 0x7f86e1f892ef in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 5 (Thread 0x7f86da1e6700 (LWP 16314)): #0 0x7f86e1f7eb4f in __GI___poll (fds=0x55df7040dc90, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 #1 0x7f86e32147fe in g_main_context_poll (priority=, n_fds=1, fds=0x55df7040dc90, timeout=, context=0x55df7040dd90) at ../../../glib/gmain.c:4346 #2 g_main_context_iterate (context=context@entry=0x55df7040dd90, block=block@entry=1, dispatch=dispatch@entry=1, self=) at
Bug#960702: [PATCH net] mlx4: Fix information leak on failure to read module EEPROM
On Mon, 2020-05-18 at 16:47 +, Saeed Mahameed wrote:
> On Sun, 2020-05-17 at 18:20 +0100, Ben Hutchings wrote:
> > mlx4_en_get_module_eeprom() returns 0 even if it fails. This results
> > in copying an uninitialised (or partly initialised) buffer back to
> > user-space.
[...]
> I am not sure i see the issue in here, and why we need the partial
> memset ?
> first thing in this function we do:
> memset(data, 0, ee->len);
>
> and then mlx4_get_module_info() will only copy valid data only on
> success.
Wow, sorry, I don't know how I missed that. So this is not the bug I
was looking for.
>
> > - if (!ret) /* Done reading */
> > + if (!ret) {
> > + /* DOM was not readable after all */
>
> actually if mlx4_get_module_info() returns any non-negative value it
> means how much data was read, so if it returns 0, it means that this
> was the last iteration and we are done reading the eeprom..
>
> so i would remove the above comment and the memset below is redundant
> since we already memset the whole buffer before the while loop.
Right.
> > + memset(data + i, 0, ee->len - i);
> > return 0;
> > + }
> >
> > if (ret < 0) {
> > en_err(priv,
> >"mlx4_get_module_info i(%d) offset(%d)
> > bytes_to_read(%d) - FAILED (0x%x)\n",
> >i, offset, ee->len - i, ret);
> > - return 0;
> > + return ret;
>
> I think returning error in here was the actual solution for your
> problem. you can verify by looking in the kernel log and verify you see
> the log message.
The original bug report (https://bugs.debian.org/960702) says that
ethtool reports different values depending on whether its output is
redirected. Although returning all-zeroes for the unreadable part
might be wrong, it doesn't explain that behaviour.
Perhaps if the timing of the I²C reads is marginal, varying numbers of
bytes of DOM information might be readable? But I don't see how
redirection of ethtool's output would affect that. It uses a single
ioctl to read everything, and the kernel controls timing within that.
So I am mystified about what is going on here. Maybe there is a bug in
ethtool, but I'm not seeing it.
Ben.
> > }
> >
> > i += ret;
--
Ben Hutchings
The two most common things in the universe are hydrogen and stupidity.
signature.asc
Description: This is a digitally signed message part
Bug#902643: buggy magic: dump previous vs current swapped
On Mon, May 18, 2020 at 10:56:06AM +0200, Christoph Biedl wrote: > Elliott Mitchell wrote... > > (for the level 0 is is reporting the epoch, > > "never", "none", or "No previous dump" would be better). Also noticing > > for the level 0 is is reporting "Level zero" instead of "Level 0". > > That's arguable. About the timestamp, the program just dumps the value > zero which gets printed as the epoch. The literal "zero" however is > result of an extra rule in libmagic's patterns. Personally, I'd either > have such an extra for either both cases or none at all. Any mix seems > weird. Perhaps. I'm going by the way /I/ read things and *both* seem wrong due to different interpretation. For the "Level" field the value is a base 10 number unless the value is 0. If one was writing a script which identified dump files the Level field is excellent, except for having "zero" instead of "0". The "Previous dump" field won't ever display as 0. Displaying the epoch is valid, though suboptimal for humans and would need special handling for scripts. As this is a string, having "No previous dump" or omitting the field would likely cause a script to save an empty string for the value which seems likely to result in correct behavior. Of the two, having "Level 0" seems, by far, the more important issue since it screws up both humans and scripts. Let us not forget the original report was the values for "This dump" and "Previous dump" are interchanged. -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+sig...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
Bug#960942: [Pkg-utopia-maintainers] Bug#960942: Bug#960942: Bug#960942: network-manager: only (undocumented) numeric values work for connection.mdns
Am 18.05.20 um 19:30 schrieb David Bremner: > Michael Biebl writes: > >> Am 18.05.20 um 18:53 schrieb Michael Biebl: >>> Am 18.05.20 um 18:02 schrieb David Bremner: Package: network-manager Version: 1.24.0-1 Severity: normal In order to get MulticastDNS working with nm and systemd-resolved, I had to set connection.mdns=1 # for 'resolve' connection.mdns=2 # for 'yes' I'm not sure if I missed something about the config file format. From the documentation it seemed that >>> >>> Which documentation? > > I was looking at NetworkManager.conf(5). Hm, I don't find any reference to connection.mdns= in NetworkManager.conf(5), which is not surprising, since NetworkManager.conf is about configuring the NetworkManager daemon and not about creating connection profiles. signature.asc Description: OpenPGP digital signature
Bug#960835: Debian Jessie site lists only 4 archs as supported
Hi,
Holger Wansing wrote:
> Package: www.debian.org
> Severity: normal
> X-Debbugs-CC: b...@decadent.org.uk
>
> Debians Jessie release page lists only 4 archs (i386, amd64, armel and armhf)
> as
> supported archs. These are the LTS-supported archs.
> This is inconsistent with the other release pages. They globally list all
> archs,
> which have been supported in the initial release (aka Debian 8.0 in this
> case).
>
> This situation was introduced with the last point release 8.11.1 in commit
> https://salsa.debian.org/webmaster-team/webwml/-/commit/0a388832cb4a7e9dfe1265fa04d1c441e9730e23
> (Ben as committer in x-debbugs-cc).
>
> To keep the webpage consistent, there is needed another concept to show the
> current state of archs (4 archs still supported via LTS, the other ones no
> longer supported).
I have prepared a patch, to deal with this.
1.
It adds a sentence to the "Jessie benefits from LTS" paragraph, to note that
only the four LTS archs are still supported in Jessie, but all the others not.
2.
Change "The following computer architectures are supported in this release"
into a variant without any sort of timing ("are suppported" as in "*are*NOW*
supported"), like "Computer architectures supported in this release".
That should be generic enough, to be understood as "are now supported" during
the lifetime of , but also as "were supported those days when
Jessie was released".
With that patch applied, the original list of archs could be reinstated.
(BTW: having the full list of archs there would be consistent with the
debian-installer pages, which still lists all archs NOW.)
diff --git a/english/releases/jessie/index.wml
b/english/releases/jessie/index.wml
index 5551b2b678b..d959ae46868 100644
--- a/english/releases/jessie/index.wml
+++ b/english/releases/jessie/index.wml
@@ -11,33 +11,34 @@ released press release and
the Release Notes.
Debian 8 has been superseded by
Debian 9 (stretch).
Regular security support updates have been discontinued as of
<:=spokendate('2018-06-17'):>.
-Jessie also benefits from Long Term Support (LTS) until
+However, Jessie benefits from Long Term Support (LTS) until
the end of June 2020. The LTS is limited to i386, amd64, armel and armhf.
+All other architectures listed below are no longer supported in Jessie.
For more information, please refer to the https://wiki.debian.org/LTS";>LTS section of the Debian Wiki.
To obtain and install Debian, see
the installation information page and the
Installation Guide. To upgrade from an older
Debian release, see the instructions in the
Release Notes.
-The following computer architectures are supported in this release:
+Computer architectures supported in this release:
<:
foreach $arch (@arches) {
print "$arches{$arch}\n";
}
:>
Contrary to our wishes, there may be some problems that exist in the
--
Holger Wansing
PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#960942: [Pkg-utopia-maintainers] Bug#960942: Bug#960942: Bug#960942: network-manager: only (undocumented) numeric values work for connection.mdns
Am 18.05.20 um 19:30 schrieb David Bremner: > Michael Biebl writes: > >>> man 5 nm-settings [1] has > > I was indeed creating text files to drop in /etc/NetworkManager/conf.d > as documented in that man page. Maybe "undocumented" is a bit unfair, > there are some hints about the numbers, but IMHO the section "FILE > FORMAT" could be improved. It clear to me when I re-read it that the > types of values are defined in nm-settings(5); the fact that the rest of > the NetworkManager.conf man page uses the symbolic values, sometimes but > not always accompanied by integer equivalents, does not help. > If you have ideas how the documentation can be improved, please consider sending a patch. Ideally it should be sent directly upstream as MR via https://gitlab.freedesktop.org/NetworkManager/NetworkManager/ Michael signature.asc Description: OpenPGP digital signature
Bug#960954: qgis: FTBFS with Qt 5.14: undefined reference to `Qt3DExtras::Qt3DWindow::Qt3DWindow(QScreen*)'
Source: qgis Version: 3.10.5+dfsg-2 Severity: important Tags: ftbfs User: debian-qt-...@lists.debian.org Usertags: qt5.14 Dear Maintainer, qgis fails to build with Qt 5.14, currently available in experimental: FAILED: output/lib/libqgis_3d.so.3.10.4 [...] /usr/bin/ld: src/3d/CMakeFiles/qgis_3d.dir/qgswindow3dengine.cpp.o: in function `QgsWindow3DEngine::QgsWindow3DEngine()': ./debian/build/../../src/3d/qgswindow3dengine.cpp:25: undefined reference to `Qt3DExtras::Qt3DWindow::Qt3DWindow(QScreen*)' collect2: error: ld returned 1 exit status This happens because we enabled Qt3DExtras headers and backported a commit from 5.15 branch [1] that changes Qt3DWindow constructor signature, to make sure we will not break ABI during 5.14 → 5.15 upgrade. However, qgis uses its own Qt3D headers: it has this block in debian/rules: ifneq (,$(findstring $(DISTRIBUTION),"sid buster eoan focal")) # Qt3DExtras intentionally removed from debian (#895386) and in turn ubuntu CMAKE_OPTS += \ -DCMAKE_PREFIX_PATH=$(realpath external/qt3dextra-headers/cmake) \ -DQT5_3DEXTRA_INCLUDE_DIR=$(realpath external/qt3dextra-headers) \ -DQT5_3DEXTRA_LIBRARY=/usr/lib/$(DEB_BUILD_MULTIARCH)/libQt53DExtras.so endif There are two ways to fix this problem: a) Wait until 5.15 reaches unstable and then remove that block from rules. b) Make that block conditional and enable it only for Qt < 5.14. In Ubuntu, I removed that block [2] and then the package built fine. [1]: https://salsa.debian.org/qt-kde-team/qt/qt3d/-/blob/experimental/debian/patches/qt3dwindow_constructor.diff [2]: https://launchpadlibrarian.net/480154819/qgis_3.10.4+dfsg-1ubuntu6_3.10.4+dfsg-1ubuntu7.diff.gz -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#960953: deepin-qt5dxcb-plugin: FTBFS with Qt 5.14: Project ERROR: Not support Qt Version: 5.14.2
Source: deepin-qt5dxcb-plugin Version: 5.0.1-3 Severity: important Tags: ftbfs User: debian-qt-...@lists.debian.org Usertags: qt5.14 Dear Maintainer, deepin-qt5dxcb-plugin fails to build with Qt 5.14, currently available in experimental: make[1]: Entering directory '/<>' [...] sh: 1: git: not found Project ERROR: Not support Qt Version: 5.14.2 make[1]: *** [Makefile:47: sub-platformplugin-qt5platform-plugin-pro-make_first] Error 3 You need to add Qt 5.14 headers to platformplugin/libqt5xcbqpa-dev/5.14.2. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#960952: dde-qt5integration: FTBFS with Qt 5.14: no matching function for call to ‘QHighDpiScaling::logicalDpi()’
Source: dde-qt5integration Version: 5.0.0-1 Severity: important Tags: ftbfs fixed-upstream User: debian-qt-...@lists.debian.org Usertags: qt5.14 Dear Maintainer, dde-qt5integration fails to build with Qt 5.14, currently available in experimental: qdeepintheme.cpp: In function ‘bool updateScreenScaleFactors(DThemeSettings*, const QByteArray&, bool)’: qdeepintheme.cpp:574:45: error: no matching function for call to ‘QHighDpiScaling::logicalDpi()’ 574 | qDebug() << QHighDpiScaling::logicalDpi(); | ^ In file included from qdeepintheme.cpp:45: /usr/include/x86_64-linux-gnu/qt5/QtGui/5.14.2/QtGui/private/qhighdpiscaling_p.h:117:17: note: candidate: ‘static QDpi QHighDpiScaling::logicalDpi(const QScreen*)’ 117 | static QDpi logicalDpi(const QScreen *screen); | ^~ /usr/include/x86_64-linux-gnu/qt5/QtGui/5.14.2/QtGui/private/qhighdpiscaling_p.h:117:17: note: candidate expects 1 argument, 0 provided This is fixed in upstream version 5.1.0.1. Or you can backport this patch: https://github.com/linuxdeepin/qt5integration/commit/efd0dda97034e297 -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#960951: qtav: FTBFS with Qt 5.14: invalid use of incomplete type ‘class QSGMaterial’
Source: qtav Version: 1.13.0+ds-1 Severity: important Tags: ftbfs fixed-upstream User: debian-qt-...@lists.debian.org Usertags: qt5.14 Dear Maintainer, qtav fails to build with Qt 5.14, currently available in experimental: SGVideoNode.cpp:56:32: error: invalid use of incomplete type ‘class QSGMaterial’ 56 | class SGVideoMaterial : public QSGMaterial |^~~ In file included from /usr/include/x86_64-linux-gnu/qt5/QtQuick/QSGGeometryNode:1, from QmlAV/SGVideoNode.h:25, from SGVideoNode.cpp:23: /usr/include/x86_64-linux-gnu/qt5/QtQuick/qsgnode.h:221:7: note: forward declaration of ‘class QSGMaterial’ 221 | class QSGMaterial; | ^~~ The following upstream commit fixes it: https://github.com/wang-bin/QtAV/commit/5abba7f0505e75fc -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#960485: Modified regex to strip comments in d/rules
Hi, > We believe that the bug you reported is fixed. The tag still showed when a test case was added for this bug report: https://salsa.debian.org/lintian/lintian/-/commit/5b09fbfde06638ca6b5415c01e372beaa459fdd9 The regex may not have stripped comments as intended. It was modified with: https://salsa.debian.org/lintian/lintian/-/commit/95feead477824f9b7b3d35e22cdc19f23259027b Kind regards Felix Lechner
Bug#892646: pvkrun already runs for both
Just FYI: currently "pvkrun" can be used for both opengl and vulkan games. And we are currently working on getting "optirun" and "primusrun" also working for both opengl and vulkan.
Bug#960950: support cloned chroot with unshare backend
Source: sbuild Severity: wishlist It may be interesting to use cloned chroot as schroot when using unshare backend. I find fuse-overlayfs[1] claims it can be used in user namespace, as FUSE has supported user namespace since kernel 4.18. [1] https://tracker.debian.org/pkg/fuse-overlayfs Thanks Shengjing Zhu signature.asc Description: PGP signature
Bug#960942: [Pkg-utopia-maintainers] Bug#960942: Bug#960942: network-manager: only (undocumented) numeric values work for connection.mdns
Michael Biebl writes: > Am 18.05.20 um 18:53 schrieb Michael Biebl: >> Am 18.05.20 um 18:02 schrieb David Bremner: >>> Package: network-manager >>> Version: 1.24.0-1 >>> Severity: normal >>> >>> In order to get MulticastDNS working with nm and systemd-resolved, I had to >>> set >>> >>> connection.mdns=1 # for 'resolve' >>> connection.mdns=2 # for 'yes' >>> >>> I'm not sure if I missed something about the config file format. From >>> the documentation it seemed that >> >> Which documentation? I was looking at NetworkManager.conf(5). >> >>> connection.mdns=yes >>> >>> should work, but it did not (i.e. resolvectl status did not show MDNS >>> enabled, and resolvectl query foo.local fails) >> >> man 5 nm-settings [1] has I was indeed creating text files to drop in /etc/NetworkManager/conf.d as documented in that man page. Maybe "undocumented" is a bit unfair, there are some hints about the numbers, but IMHO the section "FILE FORMAT" could be improved. It clear to me when I re-read it that the types of values are defined in nm-settings(5); the fact that the rest of the NetworkManager.conf man page uses the symbolic values, sometimes but not always accompanied by integer equivalents, does not help. cheers, d
Bug#960949: po4a: Cannot match some generic text in addenda header
Package: po4a Version: 0.58.1-1 Severity: normal Hi! While converting the dpkg man pages from troff to POD, I needed to convert the addenda too, which was using this header for all addenda: ,--- PO4A-HEADER:mode=after;position=^\.TH;beginboundary=FakePo4aBoundary `--- Which is nice and generic. But for POD I had to use a different one per locale, such as: ,--- PO4A-HEADER:mode=after;position=^=head1 NOM;beginboundary=FakePo4aBoundary `--- Because I was unable to match neither «^=encoding» nor the «GENERATED FILE» string inserted by po4a on the output files. And while the second might be fragile, as it could change, the former is part of the source, so under the developer control, and it would be nice to be able to use that. Using a localized section name works, but seems problematic as it depends on the translation for that section not changing, and while certainly not fatal, it's a bit annoying. :) Thanks, Guillem
