Bug#904422: npm: complains about too-new nodejs
Package: npm Version: 5.8.0+ds-1 Severity: minor npm WARN npm npm does not support Node.js v10.4.0 npm WARN npm You should probably upgrade to a newer version of node as we npm WARN npm can't make any promises that npm will work with this version. npm WARN npm Supported releases of Node.js are the latest release of 4, 6, 7, 8, 9. npm WARN npm You can find the latest version at https://nodejs.org/ -- System Information: Debian Release: 9.4 APT prefers stable APT policy: (800, 'stable'), (750, 'testing'), (700, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.17.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages npm depends on: ii node-abbrev1.0.9-1 ii node-ansi 0.3.0-2 ii node-ansi-color-table 1.0.0-1 ii node-ansi-regex2.0.0-1 ii node-ansistyles0.1.3-1 ii node-aproba1.2.0-1 ii node-archy 1.0.0-1 ii node-are-we-there-yet 1.1.4-1 ii node-aws-sign2 0.7.1-1 ii node-block-stream 0.0.9-1 ii node-bluebird 3.5.1+dfsg2-2 ii node-caseless 0.12.0-1 ii node-chalk 1.1.3-2 ii node-config-chain 1.1.11-1 ii node-detect-indent 5.0.0-1 ii node-editor1.0.0-1 ii node-encoding 0.1.12-2 ii node-fs-vacuum 1.2.10-2 ii node-fstream 1.0.10-1 ii node-fstream-ignore0.0.6-2 ii node-gauge 2.7.4-1 ii node-github-url-from-git 1.4.0-1 ii node-glob 7.1.1-1 ii node-graceful-fs 4.1.11-1 ii node-gyp 3.4.0-1 ii node-har-validator 5.0.2-1 ii node-has-unicode 2.0.1-2 ii node-hawk 6.0.1+dfsg-1 ii node-hosted-git-info 2.1.5-1 ii node-iferr 1.0.0-1 ii node-import-lazy 3.0.0.REALLY.2.1.0-1 ii node-inflight 1.0.6-1 ii node-inherits 2.0.3-1 ii node-ini 1.3.4-1 ii node-is-npm1.0.0-1 ii node-is-typedarray 1.0.0-2 ii node-isstream 0.1.2+dfsg-1 ii node-jsonstream1.0.3-4 ii node-latest-version3.1.0-1 ii node-lazy-property 1.0.0-1 ii node-lockfile 0.4.1-1 ii node-lru-cache 4.0.2-1 ii node-minimatch 3.0.3-1 ii node-mkdirp0.5.1-1 ii node-move-concurrently 1.0.1-1 ii node-nopt 3.0.6-3 ii node-normalize-package-data2.3.5-2 ii node-npmlog4.1.2-1 ii node-once 1.4.0-2 ii node-opener1.4.3-1 ii node-osenv 0.1.0-1 ii node-path-is-inside1.0.2-1 ii node-performance-now 2.1.0+debian-1 ii node-promise-inflight 1.0.1-1 ii node-read 1.0.7-1 ii node-read-package-json 1.2.4-1 ii node-readable-stream 2.3.6-1 ii node-request 2.26.1-1 ii node-retry 0.6.0-1 ii node-rimraf2.6.2-1 ii node-safe-buffer 5.1.2-1 ii node-semver5.3.0-1 ii node-semver-diff 2.1.0-2 ii node-set-blocking 2.0.0-1 ii node-sha 1.2.3-1 ii node-slide 1.1.4-1 ii node-sorted-object 2.0.1-1 ii node-stringstream 0.0.6-1 ii node-strip-ansi3.0.1-1 ii node-tar 4.4.4+ds1-1 ii node-tough-cookie 2.3.2+dfsg-1 ii node-uid-number0.0.6-1 ii node-underscore1.8.3~dfsg-1 ii node-unique-filename 1.1.0+ds-2 ii node-unpipe1.0.0-1 ii node-validate-npm-package-license 3.0.1-1 ii node-which 1.2.11-1 ii node-wrappy1.0.2-1 ii node-yargs 6.4.0-2 ii nodejs 10.4.0~dfsg-1 npm recommends no packages. npm suggests no packages. -- no debconf information
Bug#904421: installation-report
Package: installation-reports Boot method: DVD-1 Image version: https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-9.5.0-amd64-netinst.iso Date: 23 July 2018, 03:30 UTC Machine: Fujitsu Lifebook T4410 Processor: Intel(R) Core(TM)2 Duo CPU P8700 @ 2.53GHz Memory: 4GB Partitions:FilesystemType 1K-blocks Used Available Use% Mounted on udev devtmpfs 197 0 197 0% /dev tmpfs tmpfs 398148 11380386768 3% /run /dev/mapper/jdeb--vg-root ext4 148479768 44795480 96072284 32% / tmpfs tmpfs 1990736277064 1713672 14% /dev/shm tmpfs tmpfs 5120 4 5116 1% /run/lock tmpfs tmpfs 1990736 0 1990736 0% /sys/fs/cgroup /dev/sda1 ext2240972 37468191063 17% /boot tmpfs tmpfs 39814416398128 1% /run/user/118 tmpfs tmpfs 39814448398096 1% /run/user/1000 Output of lspci -knn (or lspci -nn):00:00.0 Host bridge [0600]: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub [8086:2a40] (rev 07) Subsystem: Fujitsu Limited. Mobile 4 Series Chipset Memory Controller Hub [10cf:144e] 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42] (rev 07) Subsystem: Fujitsu Limited. Mobile 4 Series Chipset Integrated Graphics Controller [10cf:1458] Kernel driver in use: i915 Kernel modules: i915 00:02.1 Display controller [0380]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a43] (rev 07) Subsystem: Fujitsu Limited. Mobile 4 Series Chipset Integrated Graphics Controller [10cf:1458] 00:1a.0 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 [8086:2937] (rev 03) Subsystem: Fujitsu Limited. 82801I (ICH9 Family) USB UHCI Controller [10cf:1472] Kernel driver in use: uhci_hcd Kernel modules: uhci_hcd 00:1a.1 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 [8086:2938] (rev 03) Subsystem: Fujitsu Limited. 82801I (ICH9 Family) USB UHCI Controller [10cf:1472] Kernel driver in use: uhci_hcd Kernel modules: uhci_hcd 00:1a.2 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 [8086:2939] (rev 03) Subsystem: Fujitsu Limited. 82801I (ICH9 Family) USB UHCI Controller [10cf:1472] Kernel driver in use: uhci_hcd Kernel modules: uhci_hcd 00:1a.7 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 [8086:293c] (rev 03) Subsystem: Fujitsu Limited. 82801I (ICH9 Family) USB2 EHCI Controller [10cf:1473] Kernel driver in use: ehci-pci Kernel modules: ehci_pci 00:1b.0 Audio device [0403]: Intel Corporation 82801I (ICH9 Family) HD Audio Controller [8086:293e] (rev 03) Subsystem: Fujitsu Limited. 82801I (ICH9 Family) HD Audio Controller [10cf:1475] Kernel driver in use: snd_hda_intel Kernel modules: snd_hda_intel 00:1c.0 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 [8086:2940] (rev 03) Kernel driver in use: pcieport Kernel modules: shpchp 00:1c.1 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2 [8086:2942] (rev 03) Kernel driver in use: pcieport Kernel modules: shpchp 00:1c.2 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 3 [8086:2944] (rev 03) Kernel driver in use: pcieport Kernel modules: shpchp 00:1d.0 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 [8086:2934] (rev 03) Subsystem: Fujitsu Limited. 82801I (ICH9 Family) USB UHCI Controller [10cf:1472] Kernel driver in use: uhci_hcd Kernel modules: uhci_hcd 00:1d.1 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 [8086:2935] (rev 03) Subsystem: Fujitsu Limited. 82801I (ICH9 Family) USB UHCI Controller [10cf:1472] Kernel driver in use: uhci_hcd Kernel modules: uhci_hcd 00:1d.2 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 [8086:2936] (rev 03) Subsystem: Fujitsu Limited. 82801I (ICH9 Family) USB UHCI Controller [10cf:1472] Kernel driver in use: uhci_hcd Kernel modules: uhci_hcd 00:1d.7 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 [8086:293a] (rev 03) Subsystem: Fujitsu Limited. 82801I (ICH9 Family) USB2 EHCI Controller [10cf:1473] Kernel driver in use: ehci-pci Kernel modules: ehci_pci 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge [8086:2448] (rev 93) 00:1f.0 ISA bridge [0601]
Bug#904111: [Pkg-clamav-devel] Bug#904111: clamav-daemon causing deadlocks/blocking I/O
On 2018-07-23 17:54:44 [+0900], Marc Dequènes wrote: > Quack, Hi, > I just upgraded and cannot reproduce this problem. I'm not using the > ScanOnAccess feature. just to confirm: you can not reproduce the problem. > Follows collected config info. > \_o< Sebastian
Bug#904111: [Pkg-clamav-devel] Bug#904111: clamav-daemon causing deadlocks/blocking I/O.
On 2018-07-23 18:26:04 [+0200], Richard Lucassen wrote: > Same here (6 Postfix front-end servers), non-systemd, non-GUI system > running Debian Stretch. Downgrading to 0.99 is a workaround. > ScanOnAccess is set to false. Is the kernel complaining about something like in the other report where it claimed something about a deadlock? > R. Sebastian
Bug#904420: lintian: Warn about empty fields in source package control files
Package: lintian Version: 2.5.93 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I just encountered a source package with Vcs-Browser: Vcs-Git: (Vcs-Browser: has only whitespace, and Vcs-Git: is empty). This seems like something lintian should complain about. This is related to, but I think simpler than #879809 - -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (900, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.16.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian depends on: ii binutils 2.31.1-1 ii bzip2 1.0.6-8.1 ii diffstat 1.61-1+b1 ii dpkg 1.19.0.5+b1 ii file 1:5.33-3 ii gettext0.19.8.1-6+b1 ii intltool-debian0.35.0+20060710.4 ii libapt-pkg-perl0.1.34 ii libarchive-zip-perl1.60-1 ii libclass-accessor-perl 0.51-1 ii libclone-perl 0.39-1 ii libdpkg-perl 1.19.0.5 ii libemail-valid-perl1.202-1 ii libfile-basedir-perl 0.08-1 ii libipc-run-perl20180523.0-1 ii liblist-moreutils-perl 0.416-1+b3 ii libparse-debianchangelog-perl 1.2.0-12 ii libtext-levenshtein-perl 0.13-1 ii libtimedate-perl 2.3000-2 ii liburi-perl1.74-1 ii libxml-simple-perl 2.25-1 ii libyaml-libyaml-perl 0.69+repack-1 ii man-db 2.8.3-2 ii patchutils 0.3.4-2 ii perl [libdigest-sha-perl] 5.26.2-6 ii t1utils1.41-2 ii xz-utils 5.2.2-1.3 Versions of packages lintian recommends: ii libperlio-gzip-perl 0.19-1+b4 Versions of packages lintian suggests: pn binutils-multiarch ii dpkg-dev 1.19.0.5 ii libhtml-parser-perl3.72-3+b2 ii libtext-template-perl 1.53-1 - -- no debconf information -BEGIN PGP SIGNATURE- iQGzBAEBCAAdFiEE3VS2dnyDRXKVCQCp8gKXHaSnniwFAltWxA0ACgkQ8gKXHaSn niwE+Av/d3La9jmFiNp1RA8ccohQ+dgT+Io+buv0+jZpYTt2Pq3nJjcSXdK71Az+ zC43LG3GVhdHhBGm7wpXXrplasOCzPkLYA99MXOnYPB76VMe2kaC6QlcJ/RFa65b CvalN/SZHAgLpC4SUfYJomIU6sAN8jDPGm+aXgU3rMKS+Vf6cc52tb0SCA8YtTL+ a39soBf0NW+px1Bkpp2HzUk8hHHIo18s/qM7+osDFEOytkXxJGBVGtrJB0/E1yqI dfONMQM1+PgUkGLtBkoccdNMU4CAxvWvrO4MDb3PwSJDH5O4gYSzIMIrWOaZOlDC T6w8HwsRbDKLVyBk7znQKfAv+gismv4JArSjvgfi3AP0Hzj4E4/vrMWF/+6i7Vwo eU4gOHKcSenWGDNYNNLWaB9c+Hbeu0EV+qhcJyxlYDi09gDld3iS8irUav7UBsY1 tn242lLB2Yl1eGvnv5weqVHvOIqWbeRHyesNwlXryQlR7+dC+iF9QMgYt1XkuUfe sLkk4cRX =/st/ -END PGP SIGNATURE-
Bug#901726: RFS: json-c/0.13.1+dfsg-1 [QA] -- JSON manipulation library
Hi Gianfranco ! Sorry for getting back to you so late, I was a bit broken and overburdened by some non-Debian difficulties :( On Sun, Jun 17, 2018 at 08:58:00PM +, Gianfranco Costamagna wrote: > 1) why are you repacking it? is really bundled jquery a "dfsg" problem? > In general, repack with dfsg is done to solve licensing issues, not because > of bundled deps. > You might use "ds" (Debian source), if you think you can save useful bits, > but I think > this is not really the case. The issue is that it's a bundled, build artefact of jquery, not the jquery source, and there is no indication I could find of which version of jquery it comes from. I believe this violates DFSG's rule number 2 (inclusion & distribution of source code). > 2) missing copyrights: > + * Copyright (c) 2016 Alexandru Ardelean. > + * Copyright (c) 2016 Eric Haszlakiewicz > (and probably more) Thanks for the catch; I will address this in a second upload to experimental. > also, don't forget to request a transition slot! Done, and this bug was X-Debbugs-CC'd. Greetings from Hsinchu, nicoo signature.asc Description: PGP signature
Bug#904419: RM: php-zend-db -- NPOASR; Useless in Debian
Package: ftp.debian.org Severity: normal Hi, As documented in #835902, there is AFAICT no point in keeping php-zend-db in Debian, it’s not even been part of any stable release. Thanks in advance. David signature.asc Description: PGP signature
Bug#904418: transition: json-c
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Control: block 844452 by -1 Control: retitle 844452 Orphan json-c Hi, I need to request a transition slot for json-c; the autogenerated tracker [0] seems correct, and I will also need someone to schedule binNMUs for impacted packages (on all architectures) once the transition starts. While I didn't yet rebuild all impacted packages, I expect all (or most) to rebuild cleanly as the removed APIs have been deprecated for a while. The reason for the transition is an API change upstream (and resulting soname change). Note that this is a QA upload, and also orphans the package. Best, nicoo [0]: https://release.debian.org/transitions/html/auto-json-c.html
Bug#904417: network-manager fails to check connectivity and fills disk
Package: network-manager Version: 1.12.0-5 Severity: normal Dear Maintainer, After connecting to a wireless or wired network, sometimes network-manager fails to check connectivity after a while and begins spitting this messages to syslog and user.log: Jul 11 19:03:42 Amtrak NetworkManager[1109]: [1531328622.0589] connectivity: connectivity check failed: 4 Besides this being an error, since I can browse and use network normally, the amount of errors (hundreds per second, it seems) makes logs grow upt o several GB in few hours. The problem appears randomly and I'm unable to correlate it to any other event, but once it triggers it keeps spitting error messages on logs. -- System Information: Release:Buster Architecture: x86_64 Versions of packages network-manager depends on: ii adduser3.117 ii dbus 1.12.8-3 ii libaudit1 1:2.8.3-1+b1 ii libbluetooth3 5.49-4 ii libc6 2.27-5 ii libcurl3-gnutls7.60.0-2 ii libglib2.0-0 2.56.1-2 ii libgnutls303.5.18-1 ii libjansson42.11-1 ii libmm-glib01.7.990-1 ii libndp01.6-1+b1 ii libnewt0.520.52.20-5 ii libnm0 1.12.0-5 ii libpam-systemd 239-6 ii libpolkit-agent-1-00.105-21 ii libpolkit-gobject-1-0 0.105-21 ii libpsl50.20.2-1 ii libreadline7 7.0-5 ii libselinux12.8-1+b1 ii libsystemd0239-6 ii libteamdctl0 1.26-1+b1 ii libudev1 239-6 ii libuuid1 2.32-0.1 ii lsb-base 9.20170808 ii policykit-10.105-21 ii udev 239-6 ii wpasupplicant 2:2.6-17 Versions of packages network-manager recommends: ii crda 3.18-1 ii dnsmasq-base [dnsmasq-base] 2.79-1 ii iptables 1.6.2-1 ii isc-dhcp-client 4.3.5-4 ii modemmanager 1.7.990-1 ii ppp 2.4.7-2+3 Versions of packages network-manager suggests: ii libteam-utils 1.26-1+b1 -- no debconf information
Bug#904414: lintian: check for Perl scripts with a shebang not using /usr/bin/perl (Policy 10.4)
tags 904414 + pending thanks Fixed in Git, pending upload: https://salsa.debian.org/lintian/lintian/commit/8b85be8c379c73e40e072cb99e6b6eedcaac943e checks/scripts.pm | 6 ++ debian/changelog | 4 t/tests/scripts-interpreters/debian/debian/install | 2 ++ t/tests/scripts-interpreters/debian/debian/links | 2 ++ t/tests/scripts-interpreters/debian/usr-bin-env-perl | 3 +++ t/tests/scripts-interpreters/debian/usr-local-bin-perl | 3 +++ t/tests/scripts-interpreters/tags | 2 ++ 7 files changed, 22 insertions(+) Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#902985: python3-taskflow: incompatibility between python3-taskflow 3.1.0-3 and python3-networkx 2.1-1
control: severity -1 serious On Wed, 04 Jul 2018 15:50:12 +0200 Alexandre SKRZYNIARZ wrote: > Package: python3-taskflow > Version: 3.1.0-3 > Severity: important > > Dear Maintainer, > > *** Reporter, please consider answering these questions, where appropriate *** > >* What led up to the situation? > > I was trying to set up openstack/cinder for self-teaching purpose from buster > Debian packages. > > I got an error when trying to create a cinder volume from openstack web > interface. This is the relevant extract from cinder-api logs: > last time I tried the package was not even rebuildable or installable. Bumping to RC, the patch is already available in Ubuntu G.
Bug#904416: ITP: mfoc - MIFARE Classic offline cracker
Package: wnpp Owner: "Samuel Henrique" Severity: wishlist User: samuel...@debian.org Usertags: gsoc2018-portkalipackages * Package name: mfoc * URL : https://github.com/nfc-tools/mfoc * License : GPL-2+, BSD-2-clause Programming Lang: C Description : This package includes the mfoc program which cracks the encryption keys of the MIFARE Classic chip and dumps the chip's memory contents to a file. I intend to maintain this package under the Debian Security Tools Packaging Team (pkg-security). -- Samuel Henrique
Bug#904405: routino-www: fails to install: chown: cannot access '/var/lib/routino/results/*': No such file or directory
Control: tags -1 confirmed On 07/24/2018 05:26 AM, Andreas Beckmann wrote: > + chown www-data:www-data /var/lib/routino/results/* > chown: cannot access '/var/lib/routino/results/*': No such file or directory If only we could keep using `chown -R`, but that had security issues. I'll need to look into a different solution. Kind Regards, Bas
Bug#904415: coturn should not be run as root
Package: coturn Version: 4.5.0.7-1 After I installed coturn, it created a turnserver user, but it actually run as root. I think the start-stop-daemon command in /etc/init.d/coturn is wrong. It should specify the user to run the daemon. I'm using Debian GNU/Linux buster. signature.asc Description: PGP signature
Bug#904414: lintian: check for Perl scripts with a shebang not using /usr/bin/perl (Policy 10.4)
Package: lintian Version: 2.5.93 Severity: wishlist Debian Policy 10.4 states: All command scripts, including the package maintainer scripts inside the package and used by dpkg, should have a #! line naming the shell to be used to interpret them. In the case of Perl scripts this must be #!/usr/bin/perl. It would be nice if lintian could detect scripts that are Perl scripts (text/x-perl MIME type or "Perl script text executable" file type) but do not use the /usr/bin/perl binary in the shebang. While arguments in shebangs are usually a bad idea, lintian should accept them here: Debian Policy 10.4 compliant: #!/usr/bin/perl #!/usr/bin/perl -T #! /usr/bin/perl #! /usr/bin/perl -T Not Debian Policy 10.4 compliant: #!/usr/bin/env perl #!/usr/local/bin/perl -- System Information: Debian Release: buster/sid APT prefers testing-debug APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.17.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE=en_AU.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages lintian depends on: ii binutils 2.31.1-1 ii bzip2 1.0.6-8.1 ii diffstat 1.61-1+b1 ii dpkg 1.19.0.5+b1 ii file 1:5.33-3 ii gettext0.19.8.1-6+b1 ii intltool-debian0.35.0+20060710.4 ii libapt-pkg-perl0.1.34 ii libarchive-zip-perl1.60-1 ii libclass-accessor-perl 0.51-1 ii libclone-perl 0.39-1 ii libdpkg-perl 1.19.0.5 ii libemail-valid-perl1.202-1 ii libfile-basedir-perl 0.08-1 ii libipc-run-perl20180523.0-1 ii liblist-moreutils-perl 0.416-1+b3 ii libparse-debianchangelog-perl 1.2.0-12 ii libtext-levenshtein-perl 0.13-1 ii libtimedate-perl 2.3000-2 ii liburi-perl1.74-1 ii libxml-simple-perl 2.25-1 ii libyaml-libyaml-perl 0.69+repack-1 ii man-db 2.8.3-2 ii patchutils 0.3.4-2 ii perl [libdigest-sha-perl] 5.26.2-6 ii t1utils1.41-2 ii xz-utils 5.2.2-1.3 Versions of packages lintian recommends: ii libperlio-gzip-perl 0.19-1+b4 Versions of packages lintian suggests: ii binutils-multiarch 2.31.1-1 ii dpkg-dev 1.19.0.5 ii libhtml-parser-perl3.72-3+b2 ii libtext-template-perl 1.53-1 -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#904413: debian-policy: HTML: link from section numbers in upgrading checklist to policy sections
Package: debian-policy Version: 4.1.5.0 Severity: wishlist In the HTML version of Policy it would be nice to have links from the section numbers in the upgrading checklist to the corresponding sections in the Policy document. This would help developers read the full sections as well as the description of the change. Currently that requires searching the single-page version (or the Table of Contents for the multi-page version) to find the right section. -- System Information: Debian Release: buster/sid APT prefers testing-debug APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.17.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE=en_AU.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages debian-policy depends on: ii libjs-sphinxdoc 1.7.6-1 debian-policy recommends no packages. Versions of packages debian-policy suggests: pn doc-base -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#904412: debian-policy: HTML: add secondary anchors for section numbers
Package: debian-policy Version: 4.1.5.0 Severity: wishlist It would be nice to have secondary anchors for section numbers so that I could just add #10.4 or #s10.1 (for example) to my browser URL to jump to the right section when someone references a particular Policy section on IRC or elsewhere. These could be like this: -- System Information: Debian Release: buster/sid APT prefers testing-debug APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.17.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE=en_AU.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages debian-policy depends on: ii libjs-sphinxdoc 1.7.6-1 debian-policy recommends no packages. Versions of packages debian-policy suggests: pn doc-base -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#904410: debhelper: automatically convert Perl script shebangs to /usr/bin/perl (Policy 10.4)
Package: debhelper Version: 11.3.5 Severity: wishlist Debian Policy 10.4 states: All command scripts, including the package maintainer scripts inside the package and used by dpkg, should have a #! line naming the shell to be used to interpret them. In the case of Perl scripts this must be #!/usr/bin/perl. https://www.debian.org/doc/debian-policy/#scripts It would be nice if debhelper would automatically convert shebangs of installed Perl scripts (including maintainer scripts and $PATH scripts) to /usr/bin/perl in order to increase compliance with the second sentence, which was added in Debian Policy Version 4.1.2: https://www.debian.org/doc/debian-policy/#version-4-1-2 -- System Information: Debian Release: buster/sid APT prefers testing-debug APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.17.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE=en_AU.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages debhelper depends on: ii autotools-dev20180224.1 ii dh-autoreconf19 ii dh-strip-nondeterminism 0.042-1 ii dpkg 1.19.0.5+b1 ii dpkg-dev 1.19.0.5 ii dwz 0.12-2 ii file 1:5.33-3 ii libdpkg-perl 1.19.0.5 ii man-db 2.8.3-2 ii perl 5.26.2-6 ii po-debconf 1.0.20 debhelper recommends no packages. Versions of packages debhelper suggests: ii dh-make 2.201801 -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#904409: debhelper: automatically convert Perl script shebangs to /usr/bin/perl (Policy 10.4)
Package: debhelper Version: 11.3.5 Severity: wishlist Debian Policy 10.4 states: All command scripts, including the package maintainer scripts inside the package and used by dpkg, should have a #! line naming the shell to be used to interpret them. In the case of Perl scripts this must be #!/usr/bin/perl. https://www.debian.org/doc/debian-policy/#scripts It would be nice if debhelper would automatically convert shebangs of installed Perl scripts (including maintainer scripts and $PATH scripts) to /usr/bin/perl in order to increase compliance with the second sentence, which was added in Debian Policy Version 4.1.2: https://www.debian.org/doc/debian-policy/#version-4-1-2 -- System Information: Debian Release: buster/sid APT prefers testing-debug APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 'experimental-debug'), (700, 'experimental'), (690, 'buildd- experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.17.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE=en_AU.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages debhelper depends on: ii autotools-dev20180224.1 ii dh-autoreconf19 ii dh-strip-nondeterminism 0.042-1 ii dpkg 1.19.0.5+b1 ii dpkg-dev 1.19.0.5 ii dwz 0.12-2 ii file 1:5.33-3 ii libdpkg-perl 1.19.0.5 ii man-db 2.8.3-2 ii perl 5.26.2-6 ii po-debconf 1.0.20 debhelper recommends no packages. Versions of packages debhelper suggests: ii dh-make 2.201801 -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#904408: RFS: pidgin-gmchess/0.02-2 [QA]
Package: sponsorship-requests Severity: wishlist X-Debbugs-CC: mike.gabr...@das-netzwerkteam.de Hi, Please **don't sponsor and upload** this package because my AM (Mike Gabriel) will review it. * Package name: pidgin-gmchess Version : 0.02-2 Upstream Author : lerosua and xihes * URL : https://code.google.com/archive/p/gmchess * License : GPL-2+ Section : net It builds those binary packages: pidgin-gmchess - pidgin integration with gmchess To access further information about this package, please visit the following URL: https://mentors.debian.net/package/pidgin-gmchess Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/pidgin-gmchess/pidgin-gmchess_0.02-2.dsc More information about ppump can be obtained from https://code.google.com/archive/p/gmchess Best regards, -- Paulo Henrique de Lima Santana (phls) Curitiba - Brasil Membro da Comunidade Curitiba Livre Site: http://www.phls.com.br GNU/Linux user: 228719 GPG ID: 0443C450 Apoie a campanha pela igualdade de gênero #HeForShe (#ElesPorElas) http://www.heforshe.org/pt -- Paulo Henrique de Lima Santana (phls) Curitiba - Brasil Membro da Comunidade Curitiba Livre Site: http://www.phls.com.br GNU/Linux user: 228719 GPG ID: 0443C450 Apoie a campanha pela igualdade de gênero #HeForShe (#ElesPorElas) http://www.heforshe.org/pt pgpltZEjYNgWn.pgp Description: PGP signature
Bug#904254: python-gevent, python-greenlet, debug packages, hurd, and testing.
On Mon, Jul 23, 2018 at 2:35 AM peter green wrote: > python-gevent cannot currently be built in testing because it has a > build-dependency on python-greenlet (>= 0.4.13) but testing only has > 0.4.12-2. This is technically a RC bug (violates "Packages must be buildable > within the same release." but AIUI in such cases it is generally considered > more productive to investigate why there is a delta between testing and > unstable than file a bug against the victim of the delta. > > After digging into the britney update output it seems that the new > python-gevent is not migrating to testing because the python-greenlet no > longer builds -dbg packages but the old -dbg packages are still in unstable. [...] > Following the general principle that issues affecting release architectures > in testing (python-gevent being unbuildable in testing) are more important > than issues that only affect non-release architectures in unstable (some > uninstallable -dbg packages on hurd) I filed a removal request asking for the > old -dbg packages to be removed so that python-greenlet could migrate to > testing. I cc'd the removal request to the > "python-green...@packages.debian.org" maintainer alias in case the maintainer > had any concerns. I plan to add back -dbg packages to python-greenlet. > Anyway Scott Kitterman (a ftp assistant) replied to my removal request with > the following. > >> It appears these are not being removed automatically because they are > >> depended on by out of date binaries on hurd. Can you clean them up > >> manually? > > This is certainly possible, but is deleting the -dbg packages really the > > best solution? > > For python debug packages to work, they need to run with the debug version > > of the python > > interpreter, which -dbgsym packages make no provision for. He is right, I shouldn't remove the -dbg packages from a Python package. > > Generally, for python packages, it's desirable to keep the traditional -dbg > > packages. > > I am far from a python expert, I am just a random dd pushing on an issue that > I noticed as > a result of running a downstream distribution. > > So I am passing Scott's comment on to the package maintainer and to Debian's > python > experts so that hopefully a descision can be taken to either tell the > ftpmasters to > go ahead with the removal of the old dbg packages or to reintroduce the -dbg > packages > to the python-gevent and python-greenlet source packages. I didn't receive a reply from others, but I plan to re-add the -dbg packages for reasons mentioned above. > More generally I find it surprising that given that python apparently has > special > requirements regarding dbg packages this does not seem to be addressed in the > python > policy. It would be nice to add this to the Python policy. Regards, Laszlo/GCS
Bug#832127: Test::Aggregate: pending removal from Debian
Hi, The Debian perl group is reviewing packages with bugs which make them un-releasable; in particular when they are not heavily used by Debian users. We would like to remove such modules from Debian if we don't think they are likely to be fixed. Test::Aggregate is one such module, owing to https://rt.cpan.org/Public/Bug/Display.html?id=100035 (aka. https://github.com/rwstauner/test-aggregate/issues/2 and https://bugs.debian.org/832127), and we would like to know whether you have any plans to look at the bug in the foreseeable future before we remove the package from Debian. If we don't hear anything we will remove the package from Debian around the end of August. This of course does not affect the standing of your module on CPAN. Thank you for maintaining this module so far! -- intrigeri
Bug#904379: problem with get_identifier_with_length
Control: tags -1 + moreinfo On 23.07.2018 20:10, Carlos Carvalho wrote: > Package: gcc-8-plugin-dev > Version: 8.1.0-12 > > I get this when I try to compile the 4.14.57 kernel: > > CHK include/config/kernel.release > CHK include/generated/uapi/linux/version.h > DESCEND objtool > CHK include/generated/utsrelease.h > In file included from ./scripts/gcc-plugins/gcc-common.h:101, > from :1: > /usr/lib/gcc/x86_64-linux-gnu/8/plugin/include/attribs.h: In function > ‘tree_node* canonicalize_attr_name(tree)’: > /usr/lib/gcc/x86_64-linux-gnu/8/plugin/include/attribs.h:118:12: error: > ‘get_identifier_with_length’ was not declared in this scope > return get_identifier_with_length (s + 2, l - 4); > ^~ > /usr/lib/gcc/x86_64-linux-gnu/8/plugin/include/attribs.h:118:12: note: > suggested alternative: ‘get_attr_min_length’ > return get_identifier_with_length (s + 2, l - 4); > ^~ > get_attr_min_length > Cannot use CONFIG_GCC_PLUGINS: your gcc installation does not support > plugins, perhaps the necessary headers are missing? > make: *** [scripts/Makefile.gcc-plugins:70: gcc-plugins-check] Error 1 > > Any ideas? no. Please provide the source, and the command line options used.
Bug#868253: POE::Component::Client::MPD: pending removal from Debian
Hi Jérôme, The Debian perl group is reviewing packages with bugs which make them un-releasable; in particular when they are not heavily used by Debian users. We would like to remove such modules from Debian if we don't think they are likely to be fixed. POE::Component::Client::MPD is one such module, owing to https://rt.cpan.org/Public/Bug/Display.html?id=122469 (aka. https://bugs.debian.org/868253), and we would like to know whether you have any plans to look at the bug in the foreseeable future before we remove the package from Debian. If we don't hear anything we will remove the package from Debian around the end of August. This of course does not affect the standing of your module on CPAN. Thank you for maintaining this module so far! -- intrigeri
Bug#904406: isc-dhcp-client: isc dhcp client is declining the assigned address
Package: isc-dhcp-client Version: 4.3.5-4 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? I run a virtual machine that sets its address using isc-dhcp-client. The dhcp server is dnsmasq spawned by libvirt. The virtual machine is assigned a static ip address 192.168.208.2 based on its MAC. * What exactly did you do (or not do) that was effective (or ineffective)? I start a virtual machine. * What was the outcome of this action? The dhcp client inquires for an address, it receives the address 192.168.208.2 from libvirt dnsmasq. It assigns the address 192.168.208.2 to the interface, but it also sends a "decline" message. dnsmasq responds to the decline message and assigns a different address on next virtual machine reboot. The result is that the virtual machine can't be reached with the assigned address. * What outcome did you expect instead? The dhcp client should accept the offered address and shouldn't send the decline message. *** End of the template - remove these template lines *** This is the packet log on the virbr0 interface: 05:29:23.694664 52:54:00:e3:9b:73 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328) 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 52:54:00:e3:9b:73, length 300, xid 0xc3b5cf4f, Flags [none] Client-Ethernet-Address 52:54:00:e3:9b:73 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Hostname Option 12, length 10: "debian-a64" Parameter-Request Option 55, length 13: Subnet-Mask, BR, Time-Zone, Default-Gateway Domain-Name, Domain-Name-Server, Option 119, Hostname Netbios-Name-Server, Netbios-Scope, MTU, Classless-Static-Route NTP 05:29:23.694942 52:54:00:9c:a3:fc > 52:54:00:e3:9b:73, ethertype IPv4 (0x0800), length 346: (tos 0xc0, ttl 64, id 50448, offset 0, flags [none], proto UDP (17), length 332) 192.168.208.1.67 > 192.168.208.2.68: BOOTP/DHCP, Reply, length 304, xid 0xc3b5cf4f, Flags [none] Your-IP 192.168.208.2 Server-IP 192.168.208.1 Client-Ethernet-Address 52:54:00:e3:9b:73 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Offer Server-ID Option 54, length 4: 192.168.208.1 Lease-Time Option 51, length 4: 3600 RN Option 58, length 4: 1800 RB Option 59, length 4: 3150 Subnet-Mask Option 1, length 4: 255.255.255.0 BR Option 28, length 4: 192.168.208.255 Default-Gateway Option 3, length 4: 192.168.208.1 Domain-Name-Server Option 6, length 4: 192.168.208.1 Hostname Option 12, length 10: "debian-a64" 05:29:23.695319 52:54:00:e3:9b:73 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328) 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 52:54:00:e3:9b:73, length 300, xid 0xc3b5cf4f, Flags [none] Client-Ethernet-Address 52:54:00:e3:9b:73 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Request Server-ID Option 54, length 4: 192.168.208.1 Requested-IP Option 50, length 4: 192.168.208.2 Hostname Option 12, length 10: "debian-a64" Parameter-Request Option 55, length 13: Subnet-Mask, BR, Time-Zone, Default-Gateway Domain-Name, Domain-Name-Server, Option 119, Hostname Netbios-Name-Server, Netbios-Scope, MTU, Classless-Static-Route NTP 05:29:23.695515 52:54:00:9c:a3:fc > 52:54:00:e3:9b:73, ethertype IPv4 (0x0800), length 346: (tos 0xc0, ttl 64, id 50449, offset 0, flags [none], proto UDP (17), length 332) 192.168.208.1.67 > 192.168.208.2.68: BOOTP/DHCP, Reply, length 304, xid 0xc3b5cf4f, Flags [none] Your-IP 192.168.208.2 Server-IP 192.168.208.1 Client-Ethernet-Address 52:54:00:e3:9b:73 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: ACK Server-ID Option 54, length 4: 192.168.208.1 Lease-Time Option 51, length 4: 3600 RN Option 58, length 4: 1800 RB Option 59, length 4: 3150 Subnet-Mask Option 1, length 4: 255.255.255.0 BR Option 28, length 4: 192.168.208.255 Default-Gateway Option 3, length 4: 192.168.208.1 Domain-Name-Server Option 6, length 4: 192.168.208.1 Hostname Option 12, length 10: "debian-a64" 05:29:23.713203 52:54:00:e3:9b:73 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: (tos
Bug#904407: Please modify the debian/copyright to follow DEP-5
Package: tmux
Version: 2.7-1+b1
Severity: wishlist
Recently I got a task to statistic the license infomation of all packages
is installed in my computer. It is become difficult since I've found
that few package don't follow the DEP-5. tmux is one of them. As a
result, I made some changes to the copyright file to let it follow the
DEP-5 and be more machine-readable. A patch file is attached.
Please consider merge it.
--
Yanhao Mo
From 229da47dc161193f79ed360558786da65f5eba5c Mon Sep 17 00:00:00 2001
From: Yanhao Mo
Date: Tue, 24 Jul 2018 11:47:36 +0800
Subject: [PATCH] modify copyright file to follow DEP-5
---
debian/copyright | 171 ++-
1 file changed, 95 insertions(+), 76 deletions(-)
diff --git a/debian/copyright b/debian/copyright
index 995df43..00823d5 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -1,37 +1,101 @@
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Upstream-Name: tmux
-Upstream-Source: http://sf.net/projects/tmux
-Upstream Author: Nicholas Marriott
+Source: http://sf.net/projects/tmux
Files: *
-Copyright:
- Copyright (c) 2007-2010 Nicholas Marriott on
- everything not listed thereunder
- Copyright (c) 2009 Joshua Elsasser on
- attributes.c
- osdep-darwin.c
- Copyright (c) 2008-2009 Tiago Cunha on
- cmd-confirm-before.c
- cmd-copy-buffer.c
- cmd-display-message.c
- cmd-if-shell.c
- cmd-load-buffer.c
- cmd-save-buffer.c
- cmd-source-file.c
- examples/tmux.vim
- Copyright (c) 2002 Todd C. Miller on
- getopt_long.c
- Copyright (c) 2004, 2005, 2007 Darren Tucker (dtucker at zip com au) on
- bsd-poll.c
- Copyright (c) 1998 Todd C. Miller on
- strlcat.c
- Copyright (c) 1998 Todd C. Miller on
- strlcpy.c
- Copyright (c) 2004 Ted Unangst and Todd Miller on
- strtonum.c
- Copyright (c) 2010 Romain Francoise on
- signal.c
-
-License:
+Copyright: 2007-2010 Nicholas Marriott
+License: ISC
+
+Files: attributes.c
+ osdep-darwin.c
+Copyright: 2009 Joshua Elsasser
+License: ISC
+
+Files: cmd-confirm-before.c
+ cmd-copy-buffer.c
+ cmd-display-message.c
+ cmd-if-shell.c
+ cmd-load-buffer.c
+ cmd-save-buffer.c
+ cmd-source-file.c
+ examples/tmux.vim
+Copyright: 2008-2009 Tiago Cunha
+License: ISC
+
+Files: getopt_long.c
+Copyright: 2002 Todd C. Miller
+License: ISC
+
+Files: bsd-poll.c
+Copyright: 2004, 2005, 2007 Darren Tucker (dtucker at zip com au)
+License: ISC
+
+Files: strlcat.c
+Files: strlcpy.c
+Copyright: 1998 Todd C. Miller
+License: ISC
+
+Files: strtonum.c
+Copyright: 2004 Ted Unangst and Todd Miller
+License: ISC
+
+Files: signal.c
+Copyright: 2010 Romain Francoise
+License: ISC
+
+Files: bitstring.h
+ unvis.c
+ vis.c
+Copyright: 1989, 1993 The Regents of the University of California
+License: BSD-3
+
+Files: strcasestr.c
+ strsep.c
+ daemon.c
+Copyright: 1990, 1993 The Regents of the University of California
+License: BSD-3
+
+Files: vis.h
+Copyright: 1990 The Regents of the University of California
+License: BSD-3
+
+Files: fgetln.c
+Copyright: 1998 The NetBSD Foundation, Inc.
+License: BSD-3
+
+Files: queue.h
+Copyright: 1991, 1993 The Regents of the University of California
+License: BSD-3
+
+Files: bsd-poll.h
+Copyright: 1996 Theo de Raadt
+License: BSD-2
+
+Files: imsg-buffer.c
+ imsg.c
+Copyright: 2003, 2004 Henning Brauer
+License: BSD-2
+
+Files: imsg.h
+Copyright: 2006, 2007 Pierre-Yves Ritschard
+ 2006, 2007, 2008 Reyk Floeter
+ 2003, 2004 Henning Brauer
+License: BSD-2
+
+Files: getopt.h
+ getopt_long.c
+Copyright: 2000 The NetBSD Foundation, Inc.
+License: BSD-2
+
+Files: tree,h
+Copyright: 2002 Niels Provos
+License: BSD-2
+
+Files: debian/*
+Copyright: 2008, 2009, 2010, 2011 Karl Ferdinand Ebert
+License: BSD-2.
+
+License: ISC
Permission to use, copy, modify, and distribute this software for any
purpose with or without fee is hereby granted, provided that the above
copyright notice and this permission notice appear in all copies.
@@ -44,26 +108,6 @@ License:
IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING
OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
-Files: compat/{bitstring.h,daemon.c,fgetln.c,queue.h,str{casestr,sep}.c,
- unvis.h,vis.h,vis.c}
-Copyright:
- Copyright (c) 1989, 1993 The Regents of the University of California on
- bitstring.h
- unvis.c
- Copyright (c) 1990, 1993 The Regents of the University of California on
- strcasestr.c
- strsep.c
- Copyright (c) 1989, 1993 The Regents of the University of California on
- vis.c
- Copyright (c) 1990 The Regents of the University of California on
- vis.h
- Copyright (c) 1990, 1993 The Regents of the University of California on
- daemon.c
- Copyright (c) 1998 The NetBSD Foundation, Inc. on
- fgetln.c
- Copyright (c) 1991, 1993 The Regents of the University of California on
- queue.h
-
License: BSD-3
Redistribution and use in source and binary forms, with or
Bug#864800: Mail::DeliveryStatus::BounceParser contains a live virus and some real spam/phishing mails
Hi Ricardo, Paul Wise: > The Mail::DeliveryStatus::BounceParser source contains a live virus and > some real spam/phishing mails. This is leading to Netcraft and other > virus detection systems on the Internet reporting Debian mirrors as > malicious, which potentially reduces the reputation of debian.org on > various anti-spam and anti-malware services. The Debian perl group is reviewing packages with bugs which make them un-releasable; in particular when they are not heavily used by Debian users. We would like to remove such modules from Debian if we don't think they are likely to be fixed. Mail::DeliveryStatus::BounceParser is one such module, owing to https://rt.cpan.org/Public/Bug/Display.html?id=122559, and we would like to know whether you have any plans to look at the bug in the foreseeable future before we remove the package from Debian. If we don't hear anything we will remove the package from Debian around the end of August. This of course does not affect the standing of your module on CPAN. Thank you for maintaining this module so far! -- intrigeri
Bug#904405: routino-www: fails to install: chown: cannot access '/var/lib/routino/results/*': No such file or directory
Package: routino-www Version: 3.2-3 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package failed to install. As per definition of the release team this makes the package too buggy for a release, thus the severity. >From the attached log (scroll to the bottom...): Selecting previously unselected package routino-www. (Reading database ... (Reading database ... 7563 files and directories currently installed.) Preparing to unpack .../routino-www_3.2-3_all.deb ... Unpacking routino-www (3.2-3) ... Setting up routino-www (3.2-3) ... + set -e + [ = developer ] + [ ! -d /var/lib/routino/data ] + mkdir -p /var/lib/routino/data + [ ! -d /var/lib/routino/results ] + mkdir -p /var/lib/routino/results + chown www-data:www-data /var/lib/routino/results + chown www-data:www-data /var/lib/routino/results/* chown: cannot access '/var/lib/routino/results/*': No such file or directory dpkg: error processing package routino-www (--configure): installed routino-www package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: routino-www cheers, Andreas routino-www_3.2-3.log.gz Description: application/gzip
Bug#857316: dgit: please make --build-products-dir configurable
Hello Ian,
On Mon 23 Jul 2018 at 11:16AM +0100, Ian Jackson wrote:
> Why does the setting of $buildproductsdir need to be done in
> build_or_push_prep_early, before pushing or notpushing ? I guess it
> wouldn't make sense to have different settings, but the business with
> localising $access_forpush is a wrinkle which is best avoided where
> possible.
>
> So I think it might be better to introduce build_or_push_prep,
> which I guess would be called in prep_push after pushing and in
> build_prep after build_prep_early.
Good, I'm happy to avoid localising $access_forpush indeed.
> Style: I normally spell:
>
> +my $bpd_from_cfg = access_cfg('build-products-dir', 'RETURN-UNDEF');
> +$buildproductsdir = $bpd_from_cfg // '..';
>
> like this:
>
> +$buildproductsdir = access_cfg('build-products-dir', 'RETURN-UNDEF')
> // '..';
>
> And then,
>
> +if (!defined $buildproductsdir) {
> *$buildproductsdir = access_cfg('build-products-dir', 'RETURN-UNDEF')
> // '..';
> +}
>
> could be spelled
>
> *$buildproductsdir //= access_cfg('build-products-dir', 'RETURN-UNDEF')
> // '..';
>
> or
>
> *$buildproductsdir //= access_cfg('build-products-dir', 'RETURN-UNDEF');
> *$buildproductsdir //= '..';
I find this style obscure. But I guess it is good to be consistent with
the rest of the script. Changed.
> I don't much like the new test case because it's a whole new test case
> just for this. I think it would be better to add the configuration
> option for a cross-section of existing tests.
>
> Probably, that would be,
> * introduce a new t-buildproductsdir-config subroutine
> * add it to the top of a selection of existing tests
>
> Do you want me to do that ?
I've written the routine; it is probably best if you choose where to add
it.
--
Sean Whitton
From fe2c1726319f0702a5c715f5204e3b64d9d07509 Mon Sep 17 00:00:00 2001
From: Sean Whitton
Date: Mon, 23 Jul 2018 12:10:02 +0800
Subject: [PATCH 1/2] dgit: add dgit.default.build-products-dir git
configuration key
Signed-off-by: Sean Whitton
---
dgit | 9 -
dgit.1 | 11 +++
2 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/dgit b/dgit
index 357adc9..a3d3b6b 100755
--- a/dgit
+++ b/dgit
@@ -63,7 +63,7 @@ our @ropts;
our $sign = 1;
our $dryrun_level = 0;
our $changesfile;
-our $buildproductsdir = '..';
+our $buildproductsdir;
our $new_package = 0;
our $ignoredirty = 0;
our $rmonerror = 1;
@@ -4715,6 +4715,7 @@ sub prep_push () {
parseopts();
build_or_push_prep_early();
pushing();
+build_or_push_prep();
check_not_dirty();
my $specsuite;
if (@ARGV==0) {
@@ -6088,6 +6089,11 @@ sub cmd_clean () {
maybe_unapply_patches_again();
}
+sub build_or_push_prep () {
+$buildproductsdir //= access_cfg('build-products-dir', 'RETURN-UNDEF');
+$buildproductsdir //= '..';
+}
+
sub build_or_push_prep_early () {
our $build_or_push_prep_early_done //= 0;
return if $build_or_push_prep_early_done++;
@@ -6106,6 +6112,7 @@ sub build_prep_early () {
sub build_prep () {
build_prep_early();
+build_or_push_prep();
clean_tree();
build_maybe_quilt_fixup();
if ($rmchanges) {
diff --git a/dgit.1 b/dgit.1
index 1460938..ddb0c0a 100644
--- a/dgit.1
+++ b/dgit.1
@@ -842,6 +842,11 @@ regardless of this option.
Specifies where to find the built files to be uploaded.
By default, dgit looks in the parent directory
.RB ( .. ).
+
+Also see the
+.BI dgit.default.build-products-dir
+configuration option
+(which this command line option overrides).
.TP
.BI --no-rm-on-error
Do not delete the destination directory if clone fails.
@@ -1096,6 +1101,12 @@ on the dgit command line.
.LP
Settings likely to be useful for an end user include:
.TP
+.BI dgit.default.build-products-dir
+Specifies where to find the built files to be uploaded,
+when --build-products-dir is not specified. The default is
+the parent directory
+.RB ( .. ).
+.TP
.BR dgit-suite. \fIsuite\fR .distro " \fIdistro\fR"
Specifies the distro for a suite. dgit keys off the suite name (which
appears in changelogs etc.), and uses that to determine the distro
--
2.11.0
From 2551bbde4f9fed0732e10defa7e2ed2191a12775 Mon Sep 17 00:00:00 2001
From: Sean Whitton
Date: Tue, 24 Jul 2018 11:15:56 +0800
Subject: [PATCH 2/2] test suite lib: add t-buildproductsdir-config
Signed-off-by: Sean Whitton
---
tests/lib | 5 +
1 file changed, 5 insertions(+)
diff --git a/tests/lib b/tests/lib
index 99345ce..3fda1bc 100644
--- a/tests/lib
+++ b/tests/lib
@@ -1164,3 +1164,8 @@ for import in ${autoimport-gnupg}; do
;;
esac
done
+
+t-buildproductsdir-config () {
+ # use --local, not t-git-config, because the value is relative
+ git config --local dgit.default.build-products-dir ../bpd
+}
--
2.11.0
signature.asc
Description: PGP signature
Bug#904404: liece-dcc: fails to install with emacs25
Package: liece-dcc Version: 2.0+0.20030527cvs-11.2 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package failed to install. As per definition of the release team this makes the package too buggy for a release, thus the severity. >From the attached log (scroll to the bottom...): Setting up emacs25 (25.2+1-6+b3) ... update-alternatives: using /usr/bin/emacs25-x to provide /usr/bin/emacs (emacs) in auto mode update-alternatives: using /usr/bin/emacs25 to provide /usr/bin/editor (editor) in auto mode Install emacsen-common for emacs25 emacsen-common: Handling install of emacsen flavor emacs25 Install liece for emacs25 install/liece: Handling emacs25, logged in /tmp/elc_Mb8V4E.log ERROR: install script from liece package failed dpkg: error processing package emacs25 (--configure): installed emacs25 package post-installation script subprocess returned error exit status 1 The logfile contains: emacs25 -q -no-site-file --no-site-file -batch -l liece-make.el -f autoload-liece Loading /usr/share/emacs25/site-lisp/liece/liece-config.el (source)... Cannot open load file: No such file or directory, install cheers, Andreas liece-dcc_2.0+0.20030527cvs-11.2+b1.log.gz Description: application/gzip
Bug#825231: Devel-BeginLift: pending removal from Debian
Dear Maintainer, The Debian perl group is reviewing packages with bugs which make them un-releasable; in particular when they are not heavily used by Debian users. We would like to remove such modules from Debian if we don't think they are likely to be fixed. Devel::BeginLift is one such module, due to: https://rt.cpan.org/Ticket/Display.html?id=114663 https://rt.cpan.org/Ticket/Display.html?id=115272 We would like to know whether you have any plans to look at the bug in the foreseeable future before we remove the package from Debian. If we don't hear anything we will remove the package from Debian in ~1 month. This of course does not affect the standing of your module on CPAN. Thank you for maintaining this module so far! -- intrigeri
Bug#904308: [PATCH] test suite: unset VISUAL, which interferes.
Hello, On Mon 23 Jul 2018 at 10:43AM +0100, Ian Jackson wrote: > Sean, can you test it please ? Works. Thanks! -- Sean Whitton signature.asc Description: PGP signature
Bug#904403: goiardi: fails to install: chown: cannot access '/var/lib/goiardi/lfs/*': No such file or directory
Package: goiardi Version: 0.11.8-1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package failed to install. As per definition of the release team this makes the package too buggy for a release, thus the severity. >From the attached log (scroll to the bottom...): Selecting previously unselected package goiardi. (Reading database ... (Reading database ... 4469 files and directories currently installed.) Preparing to unpack .../goiardi_0.11.8-1_amd64.deb ... Unpacking goiardi (0.11.8-1) ... Setting up goiardi (0.11.8-1) ... adduser: Warning: The home directory `/var/lib/goiardi' does not belong to the user you are currently creating. chown: cannot access '/var/lib/goiardi/lfs/*': No such file or directory dpkg: error processing package goiardi (--configure): installed goiardi package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: goiardi cheers, Andreas goiardi_0.11.8-1.log.gz Description: application/gzip
Bug#904402: libdevel-beginlift-perl: FTBFS with perl 5.25+: 'OP' {aka 'struct op'} has no member named 'op_sibling'
Package: libdevel-beginlift-perl
Severity: serious
Version: 0.001003-1
Running Mkbootstrap for BeginLift ()
chmod 644 "BeginLift.bs"
"/usr/bin/perl" "-Iinc" -MExtUtils::Command::MM -e 'cp_nonempty' --
BeginLift.bs blib/arch/auto/Devel/BeginLift/BeginLift.bs 644
"/usr/bin/perl" "-Iinc" "/usr/share/perl/5.26/ExtUtils/xsubpp" -typemap
'/usr/share/perl/5.26/ExtUtils/typemap' -typemap
'/usr/lib/x86_64-linux-gnu/perl5/5.26/B/Utils/Install/typemap' BeginLift.xs >
BeginLift.xsc
mv BeginLift.xsc BeginLift.c
x86_64-linux-gnu-gcc -c
-I/usr/lib/x86_64-linux-gnu/perl5/5.26/B/Hooks/OP/Check/Install
-I/usr/lib/x86_64-linux-gnu/perl5/5.26/B/Hooks/OP/Check/EntersubForCV/Install
-I/usr/lib/x86_64-linux-gnu/perl5/5.26/B/Utils/Install -D_REENTRANT
-D_GNU_SOURCE -DDEBIAN -fwrapv -fno-strict-aliasing -pipe -I/usr/local/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -g -O2
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2
-DVERSION=\"0.001003\" -DXS_VERSION=\"0.001003\" -fPIC
"-I/usr/lib/x86_64-linux-gnu/perl/5.26/CORE" BeginLift.c
BeginLift.xs:13: warning: "LINKLIST" redefined
#define LINKLIST(o) ((o)->op_next ? (o)->op_next : linklist((OP*)o))
In file included from /usr/lib/x86_64-linux-gnu/perl/5.26/CORE/perl.h:3921,
from BeginLift.xs:4:
/usr/lib/x86_64-linux-gnu/perl/5.26/CORE/op.h:641: note: this is the location
of the previous definition
#define LINKLIST(o) ((o)->op_next ? (o)->op_next : op_linklist((OP*)o))
BeginLift.xs: In function 'THX_linklist':
BeginLift.xs:27:16: error: 'OP' {aka 'struct op'} has no member named
'op_sibling'; did you mean 'op_sibparent'?
if (kid->op_sibling) {
^~
op_sibparent
BeginLift.xs:28:33: error: 'OP' {aka 'struct op'} has no member named
'op_sibling'; did you mean 'op_sibparent'?
kid->op_next = LINKLIST(kid->op_sibling);
^~
BeginLift.xs:13:23: note: in definition of macro 'LINKLIST'
#define LINKLIST(o) ((o)->op_next ? (o)->op_next : linklist((OP*)o))
^
BeginLift.xs:28:33: error: 'OP' {aka 'struct op'} has no member named
'op_sibling'; did you mean 'op_sibparent'?
kid->op_next = LINKLIST(kid->op_sibling);
^~
BeginLift.xs:13:38: note: in definition of macro 'LINKLIST'
#define LINKLIST(o) ((o)->op_next ? (o)->op_next : linklist((OP*)o))
^
BeginLift.xs:28:33: error: 'OP' {aka 'struct op'} has no member named
'op_sibling'; did you mean 'op_sibparent'?
kid->op_next = LINKLIST(kid->op_sibling);
^~
BeginLift.xs:16:41: note: in definition of macro 'linklist'
# define linklist(o) THX_linklist(aTHX_ o)
^
BeginLift.xs:28:19: note: in expansion of macro 'LINKLIST'
kid->op_next = LINKLIST(kid->op_sibling);
^~~~
BeginLift.xs:29:15: error: 'OP' {aka 'struct op'} has no member named
'op_sibling'; did you mean 'op_sibparent'?
kid = kid->op_sibling;
^~
op_sibparent
BeginLift.xs: In function 'lift_cb':
BeginLift.xs:64:24: error: 'OP' {aka 'struct op'} has no member named
'op_sibling'; did you mean 'op_sibparent'?
for ( arg = curop->op_sibling; arg->op_sibling; arg = arg->op_sibling ) {
^~
op_sibparent
BeginLift.xs:64:41: error: 'OP' {aka 'struct op'} has no member named
'op_sibling'; did you mean 'op_sibparent'?
for ( arg = curop->op_sibling; arg->op_sibling; arg = arg->op_sibling ) {
^~
op_sibparent
BeginLift.xs:64:64: error: 'OP' {aka 'struct op'} has no member named
'op_sibling'; did you mean 'op_sibparent'?
for ( arg = curop->op_sibling; arg->op_sibling; arg = arg->op_sibling ) {
^~
op_sibparent
BeginLift.xs:99:12: error: 'OP' {aka 'struct op'} has no member named
'op_sibling'; did you mean 'op_sibparent'?
new->op_sibling = NULL;
^~
op_sibparent
make[1]: *** [Makefile:340: BeginLift.o] Error 1
make[1]: Leaving directory '/<>'
dh_auto_build: make -j1 returned exit code 2
Bug#870418: How much longer should Shutter remain in sid?
Hi,
(status update on top, specific questions for Jeremy and Dominique at
the bottom)
Jeremy Bicha:
> As announced [1], we do not intend to release Debian 10 "Buster" with
> the old libgnome (and related) libraries. As part of this process, I
> am now raising the severity of these bugs.
Almost a year has now passed since I've filed this bug report during
DebCamp17. Shutter is now the only blocker that currently prevents us
from removing 7 obsolete lib*-perl packages from the archive, which in
turns blocks removing obsolete GNOME 2 libraries. Since then, calls
for help were sent to the gtk-perl list (9 months ago) and to
debian-{devel,user}@ (6.5 months ago).
My understanding of the upstream situation [1] is:
- A patch was proposed by Dominique Dumont 4 months ago, that ports
file handling from VFS to GIO. Thanks Dominique!
- As a follow-up to this patch submission, on March 11 the only
active upstream maintainer of Shutter wrote "I'm not a developer
and in particular I never learnt Pearl and never worked with GTK
libraries", cannot review patches, and proposed to give Dominique
access to the upstream BZR repo so he can fix stuff directly there
(and de facto become the only person active upstream with
development skills). Dominique did not reply to this offer.
- I'm not aware of any WIP to port Shutter away from its other
lib{gtk,gnome}2-*-perl dependencies (see the list of RC bugs
blocked by this one for details).
[1] https://bugs.launchpad.net/shutter/+bug/1006290
At this point, it looks quite clear that nobody has the skills,
motivation and time to take over Shutter development upstream and port
its codebase to non-obsolete libraries during the Buster development
cycle. shutter and lib*-perl packages were removed from testing a few
months ago and it's unlikely they'll be part of the Buster release.
What I'm now wondering is how long we want to keep them in sid.
With my pkg-perl team member hat on, I'm not very comfortable with
keeping, under the team umbrella, 7 obsolete lib{gtk,gnome}2-*-perl
packages in the archive, themselves depending on libraries that have
been declared unmaintained upstream for years. I'm fine with keeping
them in sid a little longer (say, until the end of 2018) if Dominique
thinks that waiting some more has any chance to bring a new Shutter
version that does not depend on these obsolete libraries. Dominique,
what do you think?
Jeremy, what's the plan wrt. obsolete GNOME libraries in sid?
Cheers,
--
intrigeri
Bug#904401: ITP: python-uinput -- Pythonic API to Linux uinput kernel module.
Package: wnpp Severity: wishlist Owner: "أحمد المحمودي (Ahmed El-Mahmoudy)" * Package name: python-uinput Version : 0.11.2 Upstream Author : Tuomas Räsänen * URL : http://tjjr.fi/sw/python-uinput/ * License : GPL-3+ Programming Lang: Python Description : Pythonic API to Linux uinput kernel module. Python-uinput is Python interface to Linux uinput kernel module which allows attaching userspace device drivers into kernel. In practice, Python-uinput makes it dead simple to create virtual joysticks, keyboards and mice for generating arbitrary input events programmatically. - This package is needed by new versions of xpra - I intend to maintain the package under Python modules team -- أحمد المحمودي (Ahmed El-Mahmoudy) Digital design engineer GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7 GPG Fingerprints: 6E2E E4BB 72E2 F417 D066 6ABF 7B30 B496 A7EF 5761 8206 A196 2084 7E6D 0DF8 B176 BC19 6A94 EDDD A1B7 signature.asc Description: PGP signature
Bug#904400: catdoc.1: Some formatting fixes in the manual
Package: catdoc Version: 1:0.95-4.1 Severity: minor Tags: patch The patch is in the attachment Summary: Remove space at end of lines. Fix warnings from test-groff. Change - to \- if it shall be printed as a minus. Change \\ to \e to print the escape character. Change a HYPHEN-MINUS (code 0x55, 2D) to a dash (minus) if it matches " -[:alpha:]" or \(aq-[:alpha:] (for options). Add a small space around "|" to increases readability. Add a comma (or \&) after "e.g." and "i.e.", or use English words. Increase space between sentences to two space characters. Split long lines (> 80). Use \(en for a dash where appropriate. Split a punctuation from a single argument for a two-fonts marco ### Details: Input file is catdoc.1 mandoc: catdoc.1:6:38: STYLE: unterminated quoted argument mandoc: catdoc.1:6:40: STYLE: whitespace at end of input line Many such lines ### Test nr. 2: Enable and fix warnings from 'test-groff'. :125 (macro BR): only 1 argument, but more are expected :241 (macro BR): only 1 argument, but more are expected Output is from: test-groff -b -e -mandoc -T utf8 -rF0 -t -w w -z [ "test-groff" is a developmental version of "groff" ] Test nr. 18: Change - to \- if it shall be printed as a minus sign. 132:.B -8 # Test nr. 20: Use "\e" to print the escape character instead of "\\" (which gets interpreted in copy mode). 145:causes catdoc to output unknown UNICODE character as \\x, instead # Test nr. 25: Change a HYPHEN-MINUS (code 0x55, 2D) to a minus (\-), if in front of a name for an option. 6:.BR catdoc " [" -vlu8btawxV "] [" -m " 9:.B -s 12:.B -d 15:.B -f 60:.B -w 70:.B -a 71:- shortcut for -f ascii. Produces ASCII text as output. 74:.B -b 84:.BI -d charset 92:.BI -f format 98:.B -l 103:.BI -m number 105:.B -m 0 107:.B -w 109:.BI -s charset 119:.B -t 121:.B -f tex 127:.B -u 136:.B -w 144:.B -x 148:.B -v 152:.B -V 247:.B -s # Test nr. 34: Add a space around "|" to increase readability 284:.BI "use_locale =" "(yes|no)" # Test nr. 40: Add a comma (or \&) after "e.g." and "i.e.", or use English words (man-pages(7) [package "manpages"]). 261:with directory of executable file. Empty element in list (i.e. two # Test nr. 41: Wrong distance between sentences or protect the indicator. 1) Separate the sentences and subordinate clauses; each begins on a new line. See man-pages(7) [package "manpages"] and "info groff". Or 2) Adjust space between sentences (two spaces), 3) or protect the indicator by adding "\&" after it. The "indicator" is an "end-of-sentence character" (.!?). 29:tries to write correct headers for LaTeX tabular environment. Additional 36:missing from output charset. See CHARACTER SUBSTITUTION below 48:processes its standard input unless it is terminal. It is unlikely that 59:blank lines. This behavior can be turned of by 61:switch. In 71:- shortcut for -f ascii. Produces ASCII text as output. 75:- process broken MS-Word file. Normally, 77:of file is Microsoft OLE signature. If so, it processes file, otherwise 78:it just copies it to stdin. It is intended to use 85:- specifies destination charset name. Charset file has format described in 95:comes with two output formats - ascii and tex. You can add your own if you 110:Specifies source charset. (one used in Word document), if Word document 111:doesn't contain UTF-16 text. When reading rtf documents, it is 113:specification. But it can be set wrong by Word (I've seen RTF documents 114:on Russian, where cp1252 was specified). In this case this option would 115:take precedence over charset, specified in the document. But 124:into appropriate control sequences. Separates table columns by 129:of text (as some Word-97 documents). If catdoc fails to correct Word document 133:- declares is Word document is 8 bit. Just in case that catdoc 137:disables word wrapping. By default 141:are separated by blank line. With this option each paragraph is one 159: - input and output. They are stored in plain text files in 161:library directory. Character set files should contain two whitespace-separated 166:distribution includes some of these character sets. Additional character set 169:can be obtained from ftp.unicode.org. Charset files have 176:is distributed with Cyrillic charsets as default. If you are not 181:that Microsoft never uses ISO charsets. While letters in, say cp1252 are 183:lost, if you specify ISO-8859-1 as input charset. If you use cp1252, 191:1. Paragraphs are separated by ASCII Line Feed symbol (0x000A) 193:2. Table cells within row are separated by ASCII Field Separator symbol 196:3. Table rows are separated by ASCII Record Separator (0x001E) 198:4. All printable characters, including whitespace are represented with their 204:1. List of special characters is searched for given Unicode character. 208:2. If there is an equivalent in target character set, it is output. 210:3. Otherwise, replacement list is searched and, if there is multi-chara
Bug#904399: wordview.1: Some formatting fixes in the manual
Package: catdoc
Version: 1:0.95-4.1
Severity: minor
Tags: patch
The patch is in the attachment.
Summary:
Correct spelling.
Remove space at end of lines.
Change - to \- if it shall be printed as a minus.
Begin a sentence on a new line.
Use \(en for a dash where appropriate.
###
Details:
Input file is wordview.1
Correct spelling of "specifis" and "behavoir".
###
mandoc: wordview.1:18:19: STYLE: whitespace at end of input line
mandoc: wordview.1:20:42: STYLE: whitespace at end of input line
mandoc: wordview.1:26:42: STYLE: whitespace at end of input line
mandoc: wordview.1:30:47: STYLE: whitespace at end of input line
mandoc: wordview.1:48:17: STYLE: whitespace at end of input line
mandoc: wordview.1:51:34: STYLE: whitespace at end of input line
mandoc: wordview.1:52:19: STYLE: whitespace at end of input line
mandoc: wordview.1:58:54: STYLE: whitespace at end of input line
mandoc: wordview.1:78:48: STYLE: whitespace at end of input line
mandoc: wordview.1:79:17: STYLE: whitespace at end of input line
###
Test nr. 41:
Wrong distance between sentences or protect the indicator.
1) Separate the sentences and subordinate clauses; each begins on a new
line. See man-pages(7) [package "manpages"] and "info groff".
Or
2) Adjust space between sentences (two spaces),
3) or protect the indicator by adding "\&" after it.
The "indicator" is an "end-of-sentence character" (.!?).
14:which allows to browse through word file interactively. It doesn't allow
47:Font to display text. We recommend to use fixed-width font, such as
50:is intended to convert Word into text. Either XLFD font names or
54:specifying font. If you use XLFD font names, usage of unicode
58:How to search text. This option can have value either
61:expression by default. This behavoir can be toggled interactively via
77:Width (in pixels) of border around highlighted menu item. Default
78:is 0, which differs from Tk global default. See
83:widgets can affect wordview. See Tcl/Tk manual pages for more
#
-- System Information:
Debian Release: buster/sid
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500,
'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.110-3 (SMP w/2 CPU cores)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1),
LANGUAGE=is_IS.iso88591 (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages catdoc depends on:
ii libc6 2.27-5
catdoc recommends no packages.
Versions of packages catdoc suggests:
pn tk | wish
-- no debconf information
--
Bjarni I. Gislason
--- wordview.1 2017-11-05 22:48:29.0 +
+++ wordview.1.new 2018-07-23 20:53:32.0 +
@@ -3,31 +3,32 @@
wordview \- displays text contained in MS-Word file in X window
.SH SYNOPSIS
-.BR wordview " ["
-.IR filename "]"
+.B wordview
+.RI [ filename ]
.SH DESCRIPTION
.B wordview
is simple GUI wrapper around
.BR catdoc (1)
-which allows to browse through word file interactively. It doesn't allow
+which allows to browse through word file interactively.
+It doesn't allow
to edit file, but allows to save plain text representation (or version
with some TeX commands) into the file.
.PP
-If for some reason
+If for some reason
.B catdoc
-doesn't recognize file encoding properly,
+doesn't recognize file encoding properly,
.B wordview
allows to specify encoding interactively.
.SH OPTIONS
.B wordview
-supports standard X options, supported by
+supports standard X options, supported by
.BR wish (1)
.SH X RESOURCES
-Following X resources can be used to customize
+Following X resources can be used to customize
.BR wordview look:
.TP 8
@@ -44,21 +45,26 @@ Background color of selected text
Foreground color of selected text
.TP 8
.B Wordview.Text.Font
-Font to display text. We recommend to use fixed-width font, such as
-Courier, becouse
+Font to display text.
+We recommend to use fixed-width font, such as
+Courier, because
.BR catdoc (1)
-is intended to convert Word into text. Either XLFD font names or
-Tk-style font specifications like
-.B {Courier 12pt}
+is intended to convert Word into text.
+Either XLFD font names or
+Tk-style font specifications like
+.B {Courier 12pt}
can be used for
-specifying font. If you use XLFD font names, usage of unicode
+specifying font.
+If you use XLFD font names, usage of unicode
(iso10646-1) fonts is recommended.
.TP 8
.B Wordview.Text.findMode
-How to search text. This option can have value either
+How to search text.
+This option can have value either
.BR exact " or " regexp
-and specifis whether text is searched for exact match or for regular
-expression by default. This behavoir can be toggled interactively via
+and specifies whether text is searched for exact match or for regular
+expression by default.
+This behaviour can be toggled interactively via
checkbox in the search dialog.
.TP 8
.B Wordv
Bug#904398: catppt.1: Some formatting fixes in the manual
Package: catdoc Version: 1:0.95-4.1 Severity: minor Tags: patch The patch is in the attachment. Summary: Remove space at end of lines. Change a two-fonts macro to an one-font macro for a single argument. Change a HYPHEN-MINUS (code 0x55, 2D) to a dash (minus) if it matches " -[:alpha:]" or \(aq-[:alpha:] (for options). Begin a sentence on a new line. Use \(en for a dash where appropriate. ### Details: Input file is catppt.1 mandoc: catppt.1:6:23: STYLE: whitespace at end of input line mandoc: catppt.1:9:10: STYLE: whitespace at end of input line mandoc: catppt.1:10:19: STYLE: whitespace at end of input line mandoc: catppt.1:11:10: STYLE: whitespace at end of input line mandoc: catppt.1:12:19: STYLE: whitespace at end of input line mandoc: catppt.1:18:67: STYLE: whitespace at end of input line mandoc: catppt.1:31:26: STYLE: whitespace at end of input line mandoc: catppt.1:39:65: STYLE: whitespace at end of input line ### Test nr. 2: Enable and fix warnings from 'test-groff'. :21 (macro BR): only 1 argument, but more are expected Output is from: test-groff -b -e -mandoc -T utf8 -rF0 -t -w w -z [ "test-groff" is a developmental version of "groff" ] Test nr. 16: Use the correct macro for the font change of a single argument. 21:.BR -l # Test nr. 25: Change a HYPHEN-MINUS (code 0x55, 2D) to a minus (\-), if in front of a name for an option. 6:.BR "catppt " [ -lV ] 7:.RB [ -b 9:.RB [ -s 11:.RB [ -d 21:.BR -l 24:.BI -b string 29:.BI -d charset` 37:.BI -s charset 43:.B -V # Test nr. 41: Wrong distance between sentences or protect the indicator. 1) Separate the sentences and subordinate clauses; each begins on a new line. See man-pages(7) [package "manpages"] and "info groff". Or 2) Adjust space between sentences (two spaces), 3) or protect the indicator by adding "\&" after it. The "indicator" is an "end-of-sentence character" (.!?). 25:slides break string. This string (by default - formfeed) would be output 30:- specifies destination charset name. Charset file has format described in 33:manual page. By default, current locale 38:- specifies source charset. Typically, PowerPoint files use UNICODE # Test nr. 44: Use \(en for a dash (en-dash) between space characters, not a minus (\-) or a hyphen (-), except in the NAME section. 25:slides break string. This string (by default - formfeed) would be output # -- System Information: Debian Release: buster/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.110-3 (SMP w/2 CPU cores) Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), LANGUAGE=is_IS.iso88591 (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages catdoc depends on: ii libc6 2.27-5 catdoc recommends no packages. Versions of packages catdoc suggests: pn tk | wish -- no debconf information -- Bjarni I. Gislason --- catppt.12017-11-05 22:48:29.0 + +++ catppt.1.new2018-07-23 20:36:20.0 + @@ -3,44 +3,48 @@ catppt \- reads MS-PowerPoint file and puts its content on standard output .SH SYNOPSIS -.BR "catppt " [ -lV ] -.RB [ -b -.IR " string " ] -.RB [ -s -.IR " charset " ] -.RB [ -d -.IR " charset " ] +.BR "catppt " [ \-lV ] +.RB [ \-b +.IR string " ]" +.RB [ \-s +.IR charset " ]" +.RB [ \-d +.IR charset " ]" .I files .SH DESCRIPTION .B catppt -reads MS-PowerPoint presentations and dumps its content to stdout. +reads MS-PowerPoint presentations and dumps its content to stdout. .SH "OPTIONS" .TP 8 -.BR -l +.B \-l list known charsets and exit successfully .TP 8 -.BI -b string -slides break string. This string (by default - formfeed) would be output +.BI \-b string +slides break string. +This string (by default \(en formfeed) would be output at the end of each slide page. .TP 8 -.BI -d charset` -- specifies destination charset name. Charset file has format described in -CHARACTER SETS section of +.BI \-d charset +\(en specifies destination charset name. +Charset file has format described in +CHARACTER SETS section of .BR catdoc (1) -manual page. By default, current locale +manual page. +By default, current locale charset would be used if langinfo support was enabled at the compile time. .TP 8 -.BI -s charset -- specifies source charset. Typically, PowerPoint files use UNICODE -strings with known charsets, but for some reason you may wish to +.BI \-s charset +\(en specifies source charset. +Typically, PowerPoint files use UNICODE +strings with known charsets, but for some reason you may wish to override it. .TP 8 -.B -V +.B \-V outputs version number .SH "SEE ALSO"
Bug#904397: man pages: Missing value for a build variable in the manuals
Package: catdoc Version: 1:0.95-4.1 Severity: minor A value for the "build" variable "@catdoc_version@" is missing in the man pages for "catdoc.1", "catppt.1", and "wordview.1". .TH catdoc 1 "Version @catdoc_version@" "MS-Word reader" .TH ppt2text 1 "Version @catdoc_version@" "MS-PowerPoint reader" .TH wordview 1 "Version @catdoc_version@" "MS-Word reader" -- System Information: Debian Release: buster/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.110-3 (SMP w/2 CPU cores) Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), LANGUAGE=is_IS.iso88591 (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages catdoc depends on: ii libc6 2.27-5 catdoc recommends no packages. Versions of packages catdoc suggests: pn tk | wish -- no debconf information -- Bjarni I. Gislason
Bug#799176: libspeexdsp1: Severe clipping of audio when libspeex resampler is used by ALSA or pulse audio
Is there any plan to update the speexdsp library and fix the issue? It's still a issue on debian stretch for armhf. Or how can I help to get it done? Thanks Yihui
Bug#904319: FTBFS when building binary-packages only
Hi, On 07/23/2018 05:58 PM, Graham Inggs wrote: > dpkg-buildpackage -b works fine for me. it does if the upstream tarball is present in the parent directory, which is not a requirement when building a binary package from the source tree, no? Regards, Daniel
Bug#881845: [Pkg-rust-maintainers] Bug#881845: rustc: FTBFS on mips*: test failures
1.27.1+dfsg1-1~exp4 still FTBFS.
As rustc seems need big got.
--- a/src/bootstrap/bootstrap.py
+++ b/src/bootstrap/bootstrap.py
@@ -590,7 +590,7 @@
env["LIBRARY_PATH"] = os.path.join(self.bin_root(), "lib") + \
(os.pathsep + env["LIBRARY_PATH"]) \
if "LIBRARY_PATH" in env else ""
-env["RUSTFLAGS"] = "-Cdebuginfo=2"
+env["RUSTFLAGS"] = "-Cdebuginfo=2 -Cllvm-args=-mxgot"
env["PATH"] = os.path.join(self.bin_root(), "bin") + \
os.pathsep + env["PATH"]
if not os.path.isfile(self.cargo()):
--- a/src/vendor/cc/src/lib.rs
+++ b/src/vendor/cc/src/lib.rs
@@ -1106,6 +1106,8 @@
cmd.args.push("-mx32".into());
} else if target.contains("x86_64") ||
target.contains("powerpc64") {
cmd.args.push("-m64".into());
+} else if target.contains("mips") {
+cmd.args.push("-mxgot".into());
}
if self.static_flag.is_none() {
John Paul Adrian Glaubitz 于2018年7月20日周五
下午11:30写道：
>
> Blacklisting doesn’t fix the transition block.
>
> Once the package is outdated on any of the release architectures, transition
> is blocked.
>
> > On Jul 20, 2018, at 5:15 PM, YunQiang Su wrote:
> >
> > On Tue, 17 Jul 2018 18:10:14 +0200 John Paul Adrian Glaubitz
> > wrote:
> >> On 07/17/2018 06:03 PM, Ximin Luo wrote:
> >>> Aron, the next version 1.27.1 is already in binary-NEW so the same issue
> >>> will block testing migration again, when that gets accepted.
> >>
> >> Well, I have to partially take my criticism back. Aron has pointed out on
> >> IRC
> >> that rustc was not yet removed for mips64el, I thought that had happened
> >> but
> >> indeed that wasn't the case, just cargo was removed.
> >>
> >> So, his upload didn't really change anything in this regard.
> >>
> >>> Earlier you said "Binary only upload from porter is allowed [..]" but I
> >>> am not sure the other porters have access to a loongson-3a box. Will you
> >>> continue to run builds of new rustc versions on your box? I think that is
> >>> the key point here.
> >>
> >> DSA could blacklist rustc from being built on buildds other than eberlin
> >> but I assume they won't agree to applying such a hack.
> >
> > I have asked Aurelien to blacklist rustc.
> > @Aurelien, oh the rustc problem is not about `make', it is about llvm.
> >
> >>
> >> Adrian
> >>
> >> --
> >> .''`. John Paul Adrian Glaubitz
> >> : :' : Debian Developer - glaub...@debian.org
> >> `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
> >> `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
> >>
> >>
> >
> > ___
> > Pkg-rust-maintainers mailing list
> > pkg-rust-maintain...@alioth-lists.debian.net
> > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rust-maintainers
>
--
YunQiang Su
Bug#903092: [RSVP] php-elisp: permission to relicense contributions required from past contributors
Dear Tierry and Pontus, > On Thu, Jul 05, 2018 at 09:01:30PM -0400, Nicholas D Steeves wrote: >> Package: php-elisp >> Version: 1.13.5-3 >> Severity: normal >> >> Dear Ola, Moritz, Thierry, and Pontus, >> >> The Debian Emacsen team is adopting php-elisp. At this time we would >> like to move to machine-readable copyright format 1.0 and harmonise >> update the copyright of debian/* to GPL-3+, which upstream has >> migrated to. >> >> Please reply to this bug to confirm that you consent to GPL-3+ >> relicensing of your past contributions. Php-elisp is ready to upload. Would you please confirm if GPL-3+ is an acceptable license for your contributions to this package? Thank you, Nicholas signature.asc Description: PGP signature
Bug#903092: permission to relicense php-mode/debian/* required for past contributors
On Fri, Jul 06, 2018 at 08:48:36AM +0200, Moritz Mühlenhoff wrote: > On Thu, Jul 05, 2018 at 09:01:30PM -0400, Nicholas D Steeves wrote: > > Package: php-elisp > > Version: 1.13.5-3 > > Severity: normal > > > > Dear Ola, Moritz, Thierry, and Pontus, > > > > The Debian Emacsen team is adopting php-elisp. At this time we would > > like to move to machine-readable copyright format 1.0 and harmonise > > update the copyright of debian/* to GPL-3+, which upstream has > > migrated to. > > > > Please reply to this bug to confirm that you consent to GPL-3+ > > relicensing of your past contributions. > > Confirmed! > > Cheers, > Moritz Thank you! :-) signature.asc Description: PGP signature
Bug#903092: permission to relicense php-mode/debian/* required for past contributors
On Fri, Jul 06, 2018 at 09:45:28AM +0200, Ola Lundqvist wrote: >Confirmed! > >Sent from a phone >Den fre 6 juli 2018 08:51Moritz Mühlenhoff skrev: > > On Thu, Jul 05, 2018 at 09:01:30PM -0400, Nicholas D Steeves wrote: > > Package: php-elisp > > Version: 1.13.5-3 > > Severity: normal > > > > Dear Ola, Moritz, Thierry, and Pontus, > > > > The Debian Emacsen team is adopting php-elisp. At this time we would > > like to move to machine-readable copyright format 1.0 and harmonise > > update the copyright of debian/* to GPL-3+, which upstream has > > migrated to. > > > > Please reply to this bug to confirm that you consent to GPL-3+ > > relicensing of your past contributions. > > Confirmed! > > Cheers, >     Moritz Thank you! :-) signature.asc Description: PGP signature
Bug#902658: apache2: apachectl graceful/restart results in segfault
Similar problem here. My apache2 server goes into a reload loop every
time /etc/logrotate.d/apache2 is called. That is, daily a few minutes
after midnight. The loop is triggered by the reload statement in the
logrotate script.
As a band-aid I just replaced "reload" by "restart" in the logrotate script.
In my case kern.log attributes the segfault to libglib-2.0:
# tail -n 1 /var/log/kern.log
Jul 24 02:22:39 bibo kernel: [175623.347801] /usr/sbin/apach[8662]: segfault at
7fb516473660 ip 7fb516473660 sp 7ffe8b10e508 error 14 in
libglib-2.0.so.0.5600.1[7fb516dac000+113000]
If I apply the /proc/$pid/maps|sort search with ldd I get:
# pid=770; for i in $(awk '{ print $6 }' < /proc/$pid/maps|sort -u|grep /) ; do
ldd -d $i|grep libglib && echo $i ; done
ldd: /dev/zero: not regular file
ldd: /SYSV6405bf18: No such file or directory
libglib-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
(0x7fcfb3308000)
/usr/lib/php/20170718/imagick.so
libglib-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
(0x7f0a395be000)
/usr/lib/x86_64-linux-gnu/liblqr-1.so.0.3.2
libglib-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
(0x7f2b15ea5000)
/usr/lib/x86_64-linux-gnu/libMagickCore-6.Q16.so.5.0.0
libglib-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
(0x7fa7bdb1c000)
/usr/lib/x86_64-linux-gnu/libMagickWand-6.Q16.so.5.0.0
---<)kaimartin(>---
--
Kai-Martin Knaak
Email: k...@familieknaak.de
Öffentlicher PGP-Schlüssel:
https://keyserver.ubuntu.com/pks/lookup?op=index&search=0x7B0F9882
pgpSsBAWbqJD8.pgp
Description: OpenPGP digital signature
Bug#902935: units_cur: missing input validation
On Mon, Jul 23, 2018 at 05:11:04PM +0200, Jakub Wilk wrote:
> * Adrian Mariano , 2018-07-22, 18:04:
> > > > I'm not sure about exactly the right way to validate the metals.
> > > > I took the most relaxed route of just banning '!',
> > > Enumerating badness makes me nervous. It is generally considered a
> > > bad security practice.
> >
> > What do you mean by "enumerating badness"?
>
> I mean forbidding only things that are known to be unsafe (as opposed to
> only allowing things that are known to be safe). The term was popularized by
> this essay:
> https://www.ranum.com/security/computer_security/editorials/dumb/
>
> > for metal, price in metals.items():
> > if metal in validmetals:
> >metallist.append('{:19}{} US$/troyounce'.format( metal + 'price', price))
>
> Price is not validated here.
>
> >stderr.write('Got unknown metal "{}" with value "{}"\n',metal,price)
>
> I think this message should be printed only if --verbose was enabled, for
> consistency how unknown currencies are handled.
Ok. Trying yet again. New version attached. I had sort of figured
that getting bogus price data was a more serious error than having
extra or missing currencies, so I had made that error message
unconditional. Do you think it's the wrong choice? (The errors about
failed network connections are also unconditional.)
#!/usr/bin/python
#
# units_cur for units, a program for updated currency exchange rates
#
# Copyright (C) 2017-2018
# Free Software Foundation, Inc
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
#
#
# This program was written by Adrian Mariano (adri...@gnu.org)
#
# For Python 2 & 3 compatibility
from __future__ import absolute_import, division, print_function
#
#
version = '4.3'
# Version 4.3: 20 July 2018
#
# Validate rate data from server
#
# Version 4.2: 18 April 2018
#
# Handle case of empty/malformed entry returned from the server
#
# Version 4.1: 30 October 2017
#
# Fixed to include USD in the list of currency codes.
#
# Version 4: 2 October 2017
#
# Complete rewrite to use Yahoo YQL API due to removal of TimeGenie RSS feed.
# Switched to requests library using JSON. One program now runs under
# Python 2 or Python 3. Thanks to Ray Hamel for some help with this update.
# Normal imports
import requests
import codecs
from argparse import ArgumentParser
from collections import OrderedDict
from datetime import date
from os import linesep
from sys import exit, stderr, stdout
outfile_name = 'currency.units'
# valid metals
validmetals = ['silver','gold','platinum']
# This exchange rate table lists the currency ISO 4217 codes, their
# long text names, and any fixed definitions. If the definition is
# empty then units_cur will query the server for a value.
currency = OrderedDict([
('ATS', ['austriaschilling', '1|13.7603 euro']),
('BEF', ['belgiumfranc', '1|40.3399 euro']),
('CYP', ['cypruspound', '1|0.585274 euro']),
('EEK', ['estoniakroon', '1|15.6466 euro # Equal to 1|8 germanymark']),
('FIM', ['finlandmarkka', '1|5.94573 euro']),
('FRF', ['francefranc', '1|6.55957 euro']),
('DEM', ['germanymark', '1|1.95583 euro']),
('GRD', ['greecedrachma', '1|340.75 euro']),
('IEP', ['irelandpunt', '1|0.787564 euro']),
('ITL', ['italylira', '1|1936.27 euro']),
('LVL', ['latvialats','1|0.702804 euro']),
('LTL', ['lithuanialitas','1|3.4528 euro']),
('LUF', ['luxembourgfranc', '1|40.3399 euro']),
('MTL', ['maltalira', '1|0.4293 euro']),
('SKK', ['slovakiakornua','1|30.1260 euro']),
('SIT', ['sloveniatolar', '1|239.640 euro']),
('ESP', ['spainpeseta', '1|166.386 euro']),
('NLG', ['netherlandsguilder','1|2.20371 euro']),
('PTE', ['portugalescudo','1|200.482 euro']),
('CVE', ['capeverdeescudo', '1|110.265 euro']),
('BGN', ['bulgarialev', '1|1.9558 euro']),
('BAM', ['bosniaconvertiblemark','germanymark']),
('KMF', ['comorosfranc', '1|491.96775 euro']),
('XOF', ['westafricanfranc', '1|655.957 euro']),
('XPF', ['cfpfranc', '1|119.33 euro']),
('XAF', ['centralafricancfafranc','1|655.957 euro']),
('AED', ['uaedirham','']),
('AFN', ['afghanafghani','']),
('ALL', ['albanialek','']),
('AMD', ['armeniadram','']),
('AO
Bug#904396: foma: fails to upgrade from 'sid' - trying to overwrite /usr/bin/cgflookup
Package: foma Version: 1:0.9.18~r248-1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package fails to upgrade from 'sid' to 'experimental'. It installed fine in 'sid', then the upgrade to 'experimental' fails because it tries to overwrite other packages files without declaring a Breaks+Replaces relation. See policy 7.6 at https://www.debian.org/doc/debian-policy/#overwriting-files-and-replacing-packages-replaces >From the attached log (scroll to the bottom...): Preparing to unpack .../foma_1%3a0.9.18~r248-1_amd64.deb ... Unpacking foma (1:0.9.18~r248-1) ... dpkg: error processing archive /var/cache/apt/archives/foma_1%3a0.9.18~r248-1_amd64.deb (--unpack): trying to overwrite '/usr/bin/cgflookup', which is also in package foma-bin 0.9.18+r243-1+b3 dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) Errors were encountered while processing: /var/cache/apt/archives/foma_1%3a0.9.18~r248-1_amd64.deb cheers, Andreas foma-bin=0.9.18+r243-1+b3_foma=1%0.9.18~r248-1.log.gz Description: application/gzip
Bug#904395: gdebi: fails to install .deb packages
Package: gdebi Version: 0.9.5.7+nmu2 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.16.8-towo.1-siduction-amd64 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gdebi depends on: ii gdebi-core0.9.5.7+nmu2 ii gir1.2-gtk-3.03.22.30-1 ii gir1.2-vte-2.91 0.52.2-1 ii gnome-icon-theme 3.12.0-3 ii policykit-1 0.105-20 ii python3 3.6.5-3 ii python3-gi3.28.2-1+b1 Versions of packages gdebi recommends: ii libgtk2-perl 2:1.24992-1+b1 ii lintian 2.5.93 ii shared-mime-info 1.9-2 gdebi suggests no packages. -- no debconf information
Bug#813471: Seeking seconds for patch to permit some network access to localhost
On Mon, 2018-07-23 at 20:16 +0100, Ian Jackson wrote: > LGTM. It might be worth saying "the apt repository (both source and > binaries)". There are both packages which fetch .debs explicitly, and > packages which fetch sources explicitly (yes, this is not very good, > but consensus in a discussion of relevant people in ? Nicaragua I > think was that there isn't a better way right now, and that making a > better way would be a *lot* of work). Sean and I discussed this at DebCamp and he mentioned that udeb building packages have an exception from (most?) of policy, so we probably do not need this particular apt repo network exception? The only other reason I can think of to need access to the apt repo from the build scripts is as an alternative workaround to the "cannot build-dep on source packages" problem, which is usually worked around via -source binary packages. The -source workaround is used by toolchain packages, external Linux kernel drivers and some other things. It seems to be working OK so I suggest that we deprecate all access to the apt repo except for d-i and installing Build-Depends. > If you access the archive to fetch .debs or .dscs, you almost > certainly needed to put in a Built-Using. Maybe we should mention > that ? Since Built-Using is *only* for license compliance (and folks strongly discourage its use for other things such as static linking), that is completely dependent on the license of the source/binary being fetched. It is probably worth mentioning if we add the apt repo exception. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#902026: systemd: "systemctl start systemd-timesyncd.service" kills chrony
Am 23.07.2018 um 19:53 schrieb Francesco Poli: > Control: reopen -1 > Control: retitle -1 systemd: systemd-timesyncd should not run, when chronyd > is running > > > On Fri, 22 Jun 2018 23:46:57 +0200 Francesco Poli wrote: > > [...] >> I'll try to keep an eye on the two daemons, to find out which one is >> running and whether something unexpected happens. > > Well, something weird is indeed happening. > > At each reboot, both daemons (chrony and systemd-timesyncd) are running > simultaneously! > Please take a look at the attached transcripts. > > > I have to manually stop systemd-timesyncd with > > # service systemd-timesyncd stop > > after each boot. > I am again pondering whether I should mask systemd-timesyncd with > > # systemctl --now mask systemd-timesyncd systemctl disable systemd-timesyncd should be sufficient -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#904394: netperf: cannot run netserver as non-root due to logging in /var/log/
Package: netperf Version: 2.6.0-2.1 Severity: normal I'd prefer to run short-lived instances of netserver as a normal user, not root, but that fails because netserver insists on trying to create /var/log/netserver.debug_, which it can't. A simple way to specify an alternate logfile or log directory would fix this, I think. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (400, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.16.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages netperf depends on: ii libc6 2.27-3 netperf recommends no packages. netperf suggests no packages. -- no debconf information
Bug#904393: qemu-kvm: CLOCK_MONOTONIC jumps during suspend of the host Linux
Package: qemu-kvm Version: 1:2.12+dfsg-3 Severity: normal Dear Maintainer, CLOCK_MONOTONIC should not jump during sleep, according to the systemd developer https://github.com/systemd/systemd/issues/9538#issuecomment-405901335 When the host Linux is supended by "systemctl suspend", CLOCK_MONOTONIC of the host does not include the time during suspend and does not jump, but CLOCK_MONOTONIC in the linux running on qemu-kvm jumps, as follows: root@debian-unstable:/var/tmp# while true; do python3 -c "import time; print(time.monotonic())"; sleep 100; done 19938.840492947 20038.868252082 20138.894991601 20238.91993227 20338.948723988 20995.602910365 This leads to loss of systemd-journald logs as described in https://github.com/systemd/systemd/issues/9538 -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.16.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), LANGUAGE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages qemu-kvm depends on: ii qemu-system-x86 1:2.12+dfsg-3 qemu-kvm recommends no packages. qemu-kvm suggests no packages. -- no debconf information
Bug#904392: openssh-client: The ssh client doesn't reset working directory when it daemonizes itself
Package: openssh-client Version: 1:7.4p1-10+deb9u3 Severity: normal Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? The OpenSSH client has a possibility that it daemonizes itself and multiplexes multiple sessions through a single connection. This improves connection setup time if the user makes multiple connections to the same machine. When the OpenSSH client daemonizes itself, it doesn't reset current working directory to some safe location. Consequently, if the user is in some directory that is on an external mounted device, the device can't be unmounted because the openssh client keeps its working directory on that device. * What exactly did you do (or not do) that was effective (or ineffective)? 1. add these three lines to the end of /etc/ssh/ssh_config ControlMaster auto ControlPath ~/.ssh/socket-%h-%p-%r ControlPersist 60 2. mount some external device 3. go to the mounted directory 4. use openssh to connect to some remote host 5. close the connection 6. go to your home directory 7. try to unmount the external device - it fails * What was the outcome of this action? The unmount fails because the openssh client keeps the current working directory on the external device. * What outcome did you expect instead? The openssh client should reset the current working directory to a root directory (or perhaps the user's home directory) when it daemonizes itself, so that the user may unmount the external device. *** End of the template - remove these template lines *** -- System Information: Debian Release: 9.5 APT prefers stable APT policy: (500, 'stable') Architecture: arm64 (aarch64) Foreign Architectures: armel, armhf Kernel: Linux 4.17.4 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8), LANGUAGE=cs_CZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages openssh-client depends on: ii adduser 3.115 ii dpkg 1.18.25 ii libc6 2.24-11+deb9u3 ii libedit2 3.1-20160903-3 ii libgssapi-krb5-2 1.15-1+deb9u1 ii libselinux1 2.6-3+b3 ii libssl1.0.2 1.0.2l-2+deb9u3 ii passwd1:4.4-4.1 ii zlib1g1:1.2.8.dfsg-5 Versions of packages openssh-client recommends: ii xauth 1:1.0.9-1+b2 Versions of packages openssh-client suggests: pn keychain pn libpam-ssh pn monkeysphere pn ssh-askpass -- Configuration Files: /etc/ssh/ssh_config changed [not included] -- no debconf information
Bug#904391: reportbug: crash with AttributeError: module 'reportbug.ui.urwid_ui' has no attribute 'spawn_editor'
Package: reportbug Version: 7.1.7+deb9u2 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? I tried to report a bug on Debian Sid * What exactly did you do (or not do) that was effective (or ineffective)? 1. Run "reportbug -u urwid" 2. Type "reportbug" as the package 3. Select "New bug" 4. Select "OK" 5. Type something in to the input field and select "OK" 6. Select "Normal" and "OK" 7. Select "OK" * What was the outcome of this action? reportbug crashes with: Gathering additional data, this may take a while... Traceback (most recent call last): File "/usr/bin/reportbug", line 2266, in main() File "/usr/bin/reportbug", line 1109, in main return iface.user_interface() File "/usr/bin/reportbug", line 2182, in user_interface package, severity, mode, charset=charset, tags=tags) File "/usr/bin/reportbug", line 181, in handle_editing (message, changed) = ui.spawn_editor(message or dmessage, filename, AttributeError: module 'reportbug.ui.urwid_ui' has no attribute 'spawn_editor' * What outcome did you expect instead? It shouldn't crash. Another way how to crash reportbug: 1. Modify the file /etc/ssh/ssh_config 2. Run reportbug -u urwid 3. Type "openssh-client" as the package 4. Select "New bug" 5. Select "Display modified configuration files" you'll get this crash: Traceback (most recent call last): File "/usr/bin/reportbug", line 2266, in main() File "/usr/bin/reportbug", line 1109, in main return iface.user_interface() File "/usr/bin/reportbug", line 1831, in user_interface ui.system(PAGER + ' ' + ' '.join(changed)) AttributeError: module 'reportbug.ui.urwid_ui' has no attribute 'system' Note - I'm reporting this bug from Debian Stretch, because reportbug on Debian Sid is unuseable. But the bug happenes on Sid, reportbug works correcly on Stretch. *** End of the template - remove these template lines *** -- Package-specific info: ** Environment settings: INTERFACE="urwid" ** /home/mikulas/.reportbugrc: reportbug_version "7.1.7" mode standard ui urwid -- System Information: Debian Release: 9.5 APT prefers stable APT policy: (500, 'stable') Architecture: arm64 (aarch64) Foreign Architectures: armel, armhf Kernel: Linux 4.17.4 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8), LANGUAGE=cs_CZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages reportbug depends on: ii apt1.4.8 ii python33.5.3-1 ii python3-reportbug 7.1.7+deb9u2 reportbug recommends no packages. Versions of packages reportbug suggests: pn claws-mail pn debconf-utils pn debsums pn dlocate pn emacs24-bin-common | emacs25-bin-common ii exim4 4.89-2+deb9u3 ii exim4-daemon-light [mail-transport-agent] 4.89-2+deb9u3 ii file 1:5.30-1+deb9u2 ii gir1.2-gtk-3.0 3.22.11-1 ii gir1.2-vte-2.910.46.1-1 ii gnupg 2.1.18-8~deb9u2 ii python3-gi 3.22.0-2 pn python3-gi-cairo pn python3-gtkspellcheck ii python3-urwid 1.3.1-2+b1 ii xdg-utils 1.1.1-1+deb9u1 Versions of packages python3-reportbug depends on: ii apt1.4.8 ii file 1:5.30-1+deb9u2 ii python33.5.3-1 ii python3-apt1.4.0~beta3 ii python3-debian 0.1.30 ii python3-debianbts 2.6.1 ii python3-requests 2.12.4-1 python3-reportbug suggests no packages. -- no debconf information
Bug#889056: [update] Re: Bug#889056: replace apache-mode.el with elpa package
Hi! On Mon, Jul 23, 2018 at 03:31:00PM +0500, Lev Lamberov wrote: > Пн 23 июл 2018 @ 16:52 Sean Whitton : > > > Found what I had in mind, in the REJECT-FAQ: > > > > "If the upstream tarball does not include a copy of the license, > > debian/copyright must document when and how the license information was > > obtained (i.e. include "Downloaded by John Doe on 2008-12-24 from > > http://example.net/license"; or reproduce email correspondence including > > some header) in addition to reproducing the license itself. In the past > > there were uploads where one couldn't find the license statement in the > > tarball or on the website from upstream, which is bad." > > Thank you, Sean! Yes, thank you :-) > Still I find it ambiguous. It worth to note that this particular point > was revised last time in Dec 2008. Then, in the first sentence it > mentions "a copy of the license", but the second sentece talks about a > "license statement". In emacs-php's apache-mode we have only the second. > > Nevertheless,the most interesting thing about emacs-php's apache-mode is > that its license statement says: > > > You should have received a copy of the GNU General Public License along > > with your copy of Emacs; see the file COPYING. I agree that's interesting, because apache-mode is GPL-2+ and Emacs is distributing a copy of GPL-3+. Thankfully Usami Kenta resolved the issue. It's ready to sponsor from here: g...@salsa.debian.org:emacsen-team/apache-mode-el.git Cheers, Nicholas
Bug#883950: Next steps on "[GPL-3+]" proposal
Hello, Am 29.12.2017 um 10:18 schrieb Sean Whitton: > user debian-pol...@packages.debian.org > usertags 883950 = normative discussion > thanks > > Hello, > > On Thu, Dec 28 2017, Markus Koschany wrote: > >> the Policy editors request your attention and a decision regarding >> Debian bug #883950: debian-policy: allow specifying common licenses >> with only the identifier. >> >> Summary of the proposal [...] > > Thank you Markus for a great summary. > > We now know that we can go ahead with the main proposal to introduce the > "[GPL-3+]" notation into our machine-readable copyright format. > > However, we still need to decide how we are going to hint to the local > admin that "GPL-3+" means "GPL version 3 or any later version at your > option". (The purpose is to keep the machine-readable copyright format > basically readable without reference to the copy of the spec on the > Debian web mirrors. So it's not the square brackets that we need to > hint about. It's the '+'.) > > I suggested shipping the copyright format in base-files and referring to > it using the Format: header. Joerg thinks that a shorter/smaller hint > would be adequate and better than "duplicating" the copyright format -- > though do note that we might be able to find a way to ship it that > avoids any inconvenient duplication. > > I still think my proposal is best because it is forward-compatible with > the introduction of other abbreviations into the copyright format. Once > we know that the local admin has access to the full spec, we need worry > much less about any new abbreviation which saves developer time but > reduces the readability of copyright files. > > What are our alternatives here? What might a "README", as Joerg puts > it, look like? All I can think of is a standard snippet to include in > the Comment: field in the first paragraph of the copyright file, saying > that foo-N+ means foo version N or any later version of the license at > your option. > > Let's not rush choosing how we're going to provide this hint to the > local admin. We want to be sure we get this decision right because it > will be difficult to change it once the new abbreviation appears in > copyright files across the archive. AFAICT Jörg prefers a "keep it simple" solution and I'm absolutely with him. In my opinion the simplest solution is to update the copyright format 1.0 document at https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ and document the new abbreviation. Although I think that the + sign is already explained and understood, we can probably add one or two sentences to better explain it. We should not overthink this. We should definitely avoid creating a copyright format 1.1 document which would require an update of debian/copyright files. I can't contribute much to the further discussion because I believe the quintessential points were already discussed and approved and the only thing left is merely to document and announce it. Regards, Markus signature.asc Description: OpenPGP digital signature
Bug#904390: python3-exabgp: fails to install with Python 3.7
Package: python3-exabgp Version: 4.0.6-2 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Control: block 902788 with -1 Hi, during a test with piuparts I noticed your package failed to install. As per definition of the release team this makes the package too buggy for a release, thus the severity. >From the attached log (scroll to the bottom...): Setting up python3-exabgp (4.0.6-2) ... update-alternatives: using /usr/sbin/python3-exabgp to provide /usr/sbin/exabgp (exabgp) in auto mode File "/usr/lib/python3/dist-packages/exabgp/reactor/api/command/announce.py", line 63 reactor.async.schedule(service,line,callback()) ^ SyntaxError: invalid syntax File "/usr/lib/python3/dist-packages/exabgp/reactor/api/command/neighbor.py", line 165 reactor.async.schedule(service,command,callback_summary()) ^ SyntaxError: invalid syntax File "/usr/lib/python3/dist-packages/exabgp/reactor/api/command/reactor.py", line 84 reactor.async.clear(service) ^ SyntaxError: invalid syntax File "/usr/lib/python3/dist-packages/exabgp/reactor/api/command/rib.py", line 89 reactor.async.schedule(service,line,callback()) ^ SyntaxError: invalid syntax File "/usr/lib/python3/dist-packages/exabgp/reactor/api/command/watchdog.py", line 34 reactor.async.schedule(service,line,callback(name)) ^ SyntaxError: invalid syntax File "/usr/lib/python3/dist-packages/exabgp/reactor/listener.py", line 195 reactor.async.schedule(str(uuid.uuid1()),'sending notification (6,5)',connection.notification(6,5,'could not accept the connection (more than one neighbor match)')) ^ SyntaxError: invalid syntax File "/usr/lib/python3/dist-packages/exabgp/reactor/loop.py", line 24 from exabgp.reactor.async import ASYNC ^ SyntaxError: invalid syntax File "/usr/lib/python3/dist-packages/exabgp/reactor/network/incoming.py", line 5 from .tcp import async ^ SyntaxError: invalid syntax File "/usr/lib/python3/dist-packages/exabgp/reactor/network/outgoing.py", line 11 from .tcp import async ^ SyntaxError: invalid syntax File "/usr/lib/python3/dist-packages/exabgp/reactor/network/tcp.py", line 222 def async (io, ip): ^ SyntaxError: invalid syntax dpkg: error processing package python3-exabgp (--configure): installed python3-exabgp package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: python3-exabgp "async" has become a reserved keyword in Python 3.7 cheers, Andreas python3-exabgp=4.0.6-2.log.gz Description: application/gzip
Bug#904389: python3-glance: fails to install with Python 3.7
Package: python3-glance Version: 2:16.0.1-6 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Control: block 902788 with -1 Hi, during a test with piuparts I noticed your package failed to install. As per definition of the release team this makes the package too buggy for a release, thus the severity. >From the attached log (scroll to the bottom...): Setting up python3-glance (2:16.0.1-6) ... File "/usr/lib/python3/dist-packages/glance/async/flows/api_image_import.py", line 26 import glance.async.flows._internal_plugins as internal_plugins ^ SyntaxError: invalid syntax File "/usr/lib/python3/dist-packages/glance/async/flows/base_import.py", line 33 from glance.async import utils ^ SyntaxError: invalid syntax File "/usr/lib/python3/dist-packages/glance/async/flows/introspect.py", line 24 from glance.async import utils ^ SyntaxError: invalid syntax File "/usr/lib/python3/dist-packages/glance/async/flows/plugins/plugin_opts.py", line 17 import glance.async.flows.plugins.inject_image_metadata ^ SyntaxError: invalid syntax File "/usr/lib/python3/dist-packages/glance/async/taskflow_executor.py", line 26 import glance.async ^ SyntaxError: invalid syntax File "/usr/lib/python3/dist-packages/glance/opts.py", line 31 import glance.async.flows._internal_plugins ^ SyntaxError: invalid syntax File "/usr/lib/python3/dist-packages/glance/tests/unit/async/flows/plugins/test_inject_image_metadata.py", line 22 import glance.async.flows.plugins.inject_image_metadata as inject_metadata ^ SyntaxError: invalid syntax File "/usr/lib/python3/dist-packages/glance/tests/unit/async/flows/test_api_image_import.py", line 20 import glance.async.flows.api_image_import as import_flow ^ SyntaxError: invalid syntax File "/usr/lib/python3/dist-packages/glance/tests/unit/async/flows/test_convert.py", line 25 from glance.async.flows import convert ^ SyntaxError: invalid syntax File "/usr/lib/python3/dist-packages/glance/tests/unit/async/flows/test_import.py", line 28 import glance.async.flows.base_import as import_flow ^ SyntaxError: invalid syntax File "/usr/lib/python3/dist-packages/glance/tests/unit/async/flows/test_introspect.py", line 23 from glance.async.flows import introspect ^ SyntaxError: invalid syntax File "/usr/lib/python3/dist-packages/glance/tests/unit/async/flows/test_ovf_process.py", line 27 from glance.async.flows import ovf_process ^ SyntaxError: invalid syntax File "/usr/lib/python3/dist-packages/glance/tests/unit/async/test_async.py", line 19 import glance.async ^ SyntaxError: invalid syntax File "/usr/lib/python3/dist-packages/glance/tests/unit/async/test_taskflow_executor.py", line 22 from glance.async import taskflow_executor ^ SyntaxError: invalid syntax File "/usr/lib/python3/dist-packages/glance/tests/unit/test_domain.py", line 24 import glance.async ^ SyntaxError: invalid syntax File "/usr/lib/python3/dist-packages/glance/tests/unit/test_notifier.py", line 25 import glance.async ^ SyntaxError: invalid syntax dpkg: error processing package python3-glance (--configure): installed python3-glance package post-installation script subprocess returned error exit status 1 "async" has become a reserved keyword in Python 3.7 cheers, Andreas python3-glance=2%16.0.1-6.log.gz Description: application/gzip
Bug#904388: python3-gbulb: fails to install with Python 3.7
Package: python3-gbulb Version: 0.5.3-2 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Control: block 902788 with -1 Hi, during a test with piuparts I noticed your package failed to install. As per definition of the release team this makes the package too buggy for a release, thus the severity. >From the attached log (scroll to the bottom...): Setting up python3-gbulb (0.5.3-2) ... File "/usr/lib/python3/dist-packages/gbulb/glib_events.py", line 126 future = tasks.async(future, loop=self) ^ SyntaxError: invalid syntax dpkg: error processing package python3-gbulb (--configure): installed python3-gbulb package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: python3-gbulb "async" has become a reserved keyword in Python 3.7 cheers, Andreas python3-gbulb=0.5.3-2.log.gz Description: application/gzip
Bug#904387: geary: please update geary to 0.12.3
Package: geary Version: 0.12.2-2 Severity: wishlist Geary upstream has released 0.12.3. please update the version in debian. thanks! --dkg -- System Information: Debian Release: buster/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (500, 'oldstable'), (200, 'unstable-debug'), (200, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.16.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages geary depends on: ii dconf-gsettings-backend [gsettings-backend] 0.28.0-2 ii gnome-keyring3.28.0.2-1 ii libc62.27-5 ii libcairo21.15.10-3 ii libcanberra0 0.30-6 ii libenchant1c2a 1.6.0-11.1 ii libgcr-base-3-1 3.28.0-1 ii libgdk-pixbuf2.0-0 2.36.11-2 ii libgee-0.8-2 0.20.1-1 ii libglib2.0-0 2.56.1-2 ii libgmime-2.6-0 2.6.23+dfsg1-2 ii libgtk-3-0 3.22.30-2 ii libjavascriptcoregtk-4.0-18 2.20.3-1 ii libnotify4 0.7.7-3 ii libpango-1.0-0 1.42.1-2 ii libpangocairo-1.0-0 1.42.1-2 ii libsecret-1-00.18.6-1 ii libsoup2.4-1 2.62.2-2 ii libsqlite3-0 3.24.0-1 ii libwebkit2gtk-4.0-37 2.20.3-1 ii libxml2 2.9.4+dfsg1-7+b1 geary recommends no packages. geary suggests no packages. -- no debconf information
Bug#904381: python3-dns: fails to install with Python 3.7
On Mon, 23 Jul 2018 20:40:29 +0200 Andreas Beckmann wrote: > Package: python3-dns > Version: 3.1.1-1 > Severity: serious > Tags: sid buster > User: debian...@lists.debian.org > Usertags: piuparts > Control: block 902788 with -1 > > Hi, > > during a test with piuparts I noticed your package failed to install. As > per definition of the release team this makes the package too buggy for > a release, thus the severity. > > From the attached log (scroll to the bottom...): > > Setting up python3-dns (3.1.1-1) ... > File "/usr/lib/python3/dist-packages/DNS/Base.py", line 96 > self.async=None >^ > SyntaxError: invalid syntax > > dpkg: error processing package python3-dns (--configure): >installed python3-dns package post-installation script subprocess returned error exit status 1 > > > "async" has become a reserved keyword in Python 3.7 Fixed upstream. The next upstream version will be 3.2.0, so the breaks can be << 3.2.0. Scott K
Bug#904378: python-graphviz: autopkgtest failure: /usr/bin/python3.6: No module named pytest
Hi Diane, On 23-07-18 22:08, Diane Trout wrote: > (By any chance do you know a good way to get push notices about CI > failures?) Pull: ci.debian.net has RSS feeds per package (linked on each page and like so: https://ci.debian.net/data/feeds/p/python-graphviz.xml) Pull: tracker.debian.org shows these results after some time for your package in the migration excuses. I don't think tracker already pushes those, but that could be a feature request. Push: me and others in the ci-team, mostly via bugs. Paul signature.asc Description: OpenPGP digital signature
Bug#904122: iproute2: Please install bpf_api.h and bpf_elf.h to help develop bpf objects
On 07/23/2018 10:00 PM, Luca Boccassi wrote: > On Mon, 2018-07-23 at 21:51 +0200, Daniel Borkmann wrote: >> On 07/23/2018 06:26 PM, Stephen Hemminger wrote: >>> On Mon, 23 Jul 2018 16:58:39 +0100 >>> Luca Boccassi wrote: >>> On Mon, 2018-07-23 at 15:49 +, 张 敬强 wrote: > 在 2018年7月23日星期一 CST 下午6:50:06，Luca Boccassi 写道： >> Are those headers intended as _public_ API, with all that >> entails >> (no >> breakages, etc etc)? > > bpf_elf.h is installed in the Makefile line 92, so I guess yes. > > bpf_api.h is not installed, but macro `__section_tail` is > useful for > tail calls, which is the only one in that file that may fail > between > different > iproute2 ABI. > According to the Note section in that file, I guess yes. But > upstream > didn't > install it, it really confuse me. Do you know how to contact > upstream > for a > verification? Hi Stephen, Is bpf_api.h supposed to be installed by make install? Are bpf_api.h and bpf_elf.h public API that should be shipped by distros? >>> >>> Not sure how much of BPF iproute2 should be installing, versus >>> allowing other >>> packages to do it. Daniel? >> >> The bpf_elf.h should be the only one, which is the case today already >> for >> the `make install`. The bpf_api.h can be used by BPF program writers, >> but >> it's not mandatory at all to do this, so I would prefer to leave this >> up >> to program authors instead and not install it. >> >> Thanks, >> Daniel > > Hi Daniel, > > Thanks. So if the bpf_elf.h API can be considered stable (backward > compatibility, etc) then I'll talk with the other Debian maintainers > and consider shipping it in Debian 10. Great, sounds good! Thanks a lot!
Bug#785651: glibc: test run times out on ci.debian.net; maybe don't force a build every time
On Sun, 01 Apr 2018 21:56:33 +0200 Florian Weimer wrote: > > I have no idea. On a fast 4-cores amd64 machine and for the 3 flavours > > built on amd64, the glibc takes around 20 minutes to build and the > > testsuite around 2h to run. > > This is still rather slow. I see native builds on relatively current > hardware taking 2 minutes, plus 12 to 15 minutes to build and run the > test suite (all with parallel make, although parallel make for tests > is disabled automatically for some subdirectories). 200 minutes on > current (amd64) hardware sounds quite excessive. I just did a retry on our infrastructure and it ran in 57 minutes. But it ran on one of the two big workers (8 cores and 30 GB memory). We want to make all workers equal and we are going down to 2 cores and 7.2 GB. Could it be that the memory is the actual problem and/or also an issue? Paul signature.asc Description: OpenPGP digital signature
Bug#882584: OpenBoard packaging in Debian
Hi, sorry, I forgot to reply to your first mail. I am Cc:ing the ITP bug so others take notice of our discussion. On Mo 23 Jul 2018 19:47:26 CEST, Franciscarlos Santos Soares wrote: Hello Mike! I am a chemistry teacher and I use openboard in my classes. As I use Debian SID and had to compile this application, I needed to package it. It is true! With many lintians. Enough.! Lol After gaining a little more confidence in the packaging process, I researched the BTS for some open ITP for this package and it was and it was good to find out that yes, there already is one. Yes. It is on my list. However, it has been a while since you registered this ITP bug, stating that you intended to package it. I still have the intention to package it. Before the buster freeze. That's why I get in touch. As I worked on my own package, I would like to to collaborate with you, because for me it would be not only a challenge, but a great learning opportunity. What do you think? The main problems are: * fonts (they need to be package separately) * xpdf embedded code (should be converted to libpoppler) Please send me your tarball and I take a look (I'll be on VAC starting on Friday, so I'll probably get to it after Aug 12th. Sorry that things take so long here. Mike -- mike gabriel aka sunweaver (Debian Developer) mobile: +49 (1520) 1976 148 landline: +49 (4354) 8390 139 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: sunwea...@debian.org, http://sunweavers.net pgpNewKs6LFe0.pgp Description: Digitale PGP-Signatur
Bug#904122: iproute2: Please install bpf_api.h and bpf_elf.h to help develop bpf objects
On 07/23/2018 06:26 PM, Stephen Hemminger wrote: > On Mon, 23 Jul 2018 16:58:39 +0100 > Luca Boccassi wrote: > >> On Mon, 2018-07-23 at 15:49 +, 张 敬强 wrote: >>> 在 2018年7月23日星期一 CST 下午6:50:06，Luca Boccassi 写道： Are those headers intended as _public_ API, with all that entails (no breakages, etc etc)? >>> >>> bpf_elf.h is installed in the Makefile line 92, so I guess yes. >>> >>> bpf_api.h is not installed, but macro `__section_tail` is useful for >>> tail calls, which is the only one in that file that may fail between >>> different >>> iproute2 ABI. >>> According to the Note section in that file, I guess yes. But upstream >>> didn't >>> install it, it really confuse me. Do you know how to contact upstream >>> for a >>> verification? >> >> Hi Stephen, >> >> Is bpf_api.h supposed to be installed by make install? Are bpf_api.h >> and bpf_elf.h public API that should be shipped by distros? > > Not sure how much of BPF iproute2 should be installing, versus allowing other > packages to do it. Daniel? The bpf_elf.h should be the only one, which is the case today already for the `make install`. The bpf_api.h can be used by BPF program writers, but it's not mandatory at all to do this, so I would prefer to leave this up to program authors instead and not install it. Thanks, Daniel
Bug#904381: python3-dns: fails to install with Python 3.7
On Mon, 23 Jul 2018 20:40:29 +0200 Andreas Beckmann wrote: > Package: python3-dns > Version: 3.1.1-1 > Severity: serious > Tags: sid buster > User: debian...@lists.debian.org > Usertags: piuparts > Control: block 902788 with -1 > > Hi, > > during a test with piuparts I noticed your package failed to install. As > per definition of the release team this makes the package too buggy for > a release, thus the severity. > > From the attached log (scroll to the bottom...): > > Setting up python3-dns (3.1.1-1) ... > File "/usr/lib/python3/dist-packages/DNS/Base.py", line 96 > self.async=None >^ > SyntaxError: invalid syntax > > dpkg: error processing package python3-dns (--configure): >installed python3-dns package post-installation script subprocess returned error exit status 1 > > > "async" has become a reserved keyword in Python 3.7 Python 3.7 isn't installed by default, so this was not a normal piuparts test. Adjusted priority to normal since this is not an RC issue until python3.7 is the default python3. Note that addition of python3.7 to supported versions in Unstable was not coordinated, so it's no surprise it breaks things. Scott K
Bug#885947: marco: After updating, restart (user or pc) and log in, desktop fails
Hi, On Mo 23 Jul 2018 20:25:14 CEST, Santiago wrote: Package: marco Version: 1.18.1-3 Followup-For: Bug #885947 Dear Maintainer, if I upgrade the following retained packages to the latest version, follow the same problem. marco (1.18.1-3 => 1.20.2-1) marco-common (1.18.1-3 => 1.20.2-1) libmarco-private1 (1.18.1-3 => 1.20.2-1) Other retained and related packages are: mate-desktop-environment (1.18.0+4 => 1.20.0+5) mate-desktop-environment-core (1.18.0+4 => 1.20.0+5) The actual versions of the underlying Xserver: What happens if you replace marco some other window manager? E.g. metacity. Launch the corrupted session. Switch to tty1, login as same user. $ export DISPLAY=:0 $ metacity --replace Switch back to tty7. Mike -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby mobile: +49 (1520) 1976 148 landline: +49 (4354) 8390 139 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de pgpqMkwScckJL.pgp Description: Digitale PGP-Signatur
Bug#904378: python-graphviz: autopkgtest failure: /usr/bin/python3.6: No module named pytest
On Mon, 2018-07-23 at 20:10 +0200, Paul Gevers wrote: > Source: python-graphviz > Version: 0.8.4-1 > X-Debbugs-CC: debian...@lists.debian.org > User: debian...@lists.debian.org > Usertags: regression > > Dear maintainers, > > Thanks for fixing bug 904245 so swiftly. However, your new version > fails > with the error copied below. > Grumble (about the pbuilder autopkgtest script). Thank you for spotting this and letting me know. > Could you please investigate? Does the test miss a test dependency? > Currently this failure is delaying the migration to testing by 13 > days. Yes, the problem is my autopkgtests run in a chroot that is still contaminated by the build environment build-deps so I missed specifying some dependencies in the autopkgtest tests/control file. I just pushed a 0.8.4-2 that'll hopefully fix it. (By any chance do you know a good way to get push notices about CI failures?) Diane signature.asc Description: This is a digitally signed message part
Bug#900722: go-mode.el: diff for NMU version 3:1.5.0-1.1
* Sean Whitton: > I've prepared an NMU for go-mode.el (versioned as 3:1.5.0-1.1) and > uploaded it to DELAYED/5. Please feel free to tell me if I should delay > it longer. So you didn't change anything other than the changelog, not even added a versioned dh-elpa build-dependency? Wouldn't requesting a rebuild have been enough in that case? Cheers, -Hilko
Bug#904386: sshguard: Version 2.2.0 available
Package: sshguard Version: 1.7.1-1 Severity: minor Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** The latest version released is 2.2.0, while Debian stretch only have 1.7.x, ditto for buster & sid. Seems thhat the requests for the maintainer to relinquish control to another also have been falling on deaf ears *** End of the template - remove these template lines *** -- System Information: Debian Release: 9.5 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.15.17-3-pve (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C), LANGUAGE=en_US.UTF-8 (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages sshguard depends on: ii init-system-helpers 1.48 ii iptables 1.6.0+snapshot20161117-6 ii libc62.24-11+deb9u3 ii lsb-base 9.20161125 sshguard recommends no packages. sshguard suggests no packages. -- Configuration Files: /etc/sshguard/whitelist changed [not included] -- no debconf information
Bug#882556: Remnant ntp's Apparmor profile prevents openntpd from working
Hi Simon && Christian Thanks for providing this report! I was wondering... isn't this behaviour to be performed as a postrm script by the package that carries the original apparmor profile, in this case, ntp? If we think about this for a moment, what we will end up with might be removing and reinstalling an apparmor profile on every openntpd's upgrade, which seems odd, instead of prunning ntp's currently attach kernel policy running. This seems also a good idea from the ntp's perspective, since It helps restoring the system on a proper state (unloading stuff that is not longer needed to be load such us a kernel loaded apparmor profile). I might be missing something here, so please excuse and clarify. Cheers, Dererk On 23/11/17 19:02, Simon Deziel wrote: Package: openntpd Version: 1:6.2p3-1 Severity: low Hi, When someone purges the ntp package to then install openntpd, it is possible for ntp's Apparmor profile to remain loaded in the kernel after the corresponding /etc/apparmor.d/ file was removed. This prevents openntpd's from working or even detecting the old profile's file. For all the details, please see the original bug as reported to Ubuntu [1]. Please consider applying the patch from Christian Ehrhardt [2] to ensure a smoother transition from ntp to openntpd. Thank you, Simon [1] https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1689585 [2] https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1689585/comments/13 -- BOFH excuse #154: You can tune a file system, but you can't tune a fish (from most tunefs man pages)
Bug#904122: iproute2: Please install bpf_api.h and bpf_elf.h to help develop bpf objects
On Mon, 2018-07-23 at 21:51 +0200, Daniel Borkmann wrote: > On 07/23/2018 06:26 PM, Stephen Hemminger wrote: > > On Mon, 23 Jul 2018 16:58:39 +0100 > > Luca Boccassi wrote: > > > > > On Mon, 2018-07-23 at 15:49 +, 张 敬强 wrote: > > > > 在 2018年7月23日星期一 CST 下午6:50:06，Luca Boccassi 写道： > > > > > Are those headers intended as _public_ API, with all that > > > > > entails > > > > > (no > > > > > breakages, etc etc)? > > > > > > > > bpf_elf.h is installed in the Makefile line 92, so I guess yes. > > > > > > > > bpf_api.h is not installed, but macro `__section_tail` is > > > > useful for > > > > tail calls, which is the only one in that file that may fail > > > > between > > > > different > > > > iproute2 ABI. > > > > According to the Note section in that file, I guess yes. But > > > > upstream > > > > didn't > > > > install it, it really confuse me. Do you know how to contact > > > > upstream > > > > for a > > > > verification? > > > > > > Hi Stephen, > > > > > > Is bpf_api.h supposed to be installed by make install? Are > > > bpf_api.h > > > and bpf_elf.h public API that should be shipped by distros? > > > > Not sure how much of BPF iproute2 should be installing, versus > > allowing other > > packages to do it. Daniel? > > The bpf_elf.h should be the only one, which is the case today already > for > the `make install`. The bpf_api.h can be used by BPF program writers, > but > it's not mandatory at all to do this, so I would prefer to leave this > up > to program authors instead and not install it. > > Thanks, > Daniel Hi Daniel, Thanks. So if the bpf_elf.h API can be considered stable (backward compatibility, etc) then I'll talk with the other Debian maintainers and consider shipping it in Debian 10. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#904200: RM: acccheck -- ROM; Insecure, unmaintained, better alternatives
Hello I am agree with this. Some days ago -when this bugs were published- I contacted upstream but i get no answer. Greetings, Marcos On 21/07/18 15:02, Raphaël Hertzog wrote: > Package: ftp.debian.org > Severity: normal > > Please remove the acccheck package. It is affected by multiple security > vulnerabilities that are unlikely to be fixed by upstream as this was a > script written and shared a long time ago, upstream is not actively > maintaining it. > > The feature set of this package is also redundant with other better tools: > metasploit, hydra, medusa, ncrack and patator > > FWIW the package has been dropped from Debian Testing due to #901572 > and Kali followed suite, it has been dropped from their meta-package too. > > Thank you in advance. > > PS: I first tried to patch the security vulnerability but when I looked at > the code more closely, it's literaly riddled with shell injection > vulnerabilities and it would be time-consuming to fix them all. > > PS: I'm requesting this as a member of the pkg-security packaging team > even though I'm not listed in Uploaders of the package. I have put Marcos > Fouces in copy of the bug. >
Bug#904385: arm64: sigaltstack fails with MINSIGSTKSZ for 32-bit processes
control: affects -1 glibc control: found linux/4.17.6-2 On 2018-07-23 21:31, Aurelien Jarno wrote: > Package: src:linux > Version: 4.9.110-1 > Severity: normal > > Dear Maintainer, > > The arm64 kernel allows one to run aarch32 processes on an aarch64 > processor (if it has support for it), using the standard 32/64-bit > syscall compatibility. However this compat layer does not correctly > validate the arguments of the sigaltstack syscall. > I forgot to say that the problem is reproducible with kernel 4.17.6. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#902981: Font-Awesome 5 no build system DFSG compatibility
Simon McVittie writes ("Re: Font-Awesome 5 no build system DFSG compatibility"):
> I think this is a technical issue, but not a DFSG violation; and I think
> it would be appropriate to track it as a bug, but not a release-critical
> bug.
I have a different analysis, at least, as far as I currently
understand the situation.
What is going on here is that upstream are keeping some of the actual
source code (and yes, I think the Makefiles count - I agree with the
GPL's definition of source in this context) secret (perhaps
unintentionally). We need to obtain it. If we can't, then perhaps we
can produce an equivalent build sequence to replace the missing parts.
IMO for files which are built automatically by upstream, they should
be built automatically in Debian too.
> The same situation exists in any package where some hard-to-modify,
> non-executable data file (perhaps an icon) is accompanied by its
> easier-to-modify source form (perhaps in GIMP format or as a SVG) but
> a manual export step is required to transform the source form into the
> modifiable form.
This is quite different. In those cases there is no other build
system. When there is no other build system, then upstream are doing
the same manual thing that we are expecting ourselves, our users, and
our downstreams to do.
Thanks,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#904269: RFS: rurple-ng/0.5+16-2, only packaging updates
Re: Thomas Koch 2018-07-22 <153227007588.243719.10944164547288454279.report...@thk1.roam.corp.google.com> > Alternatively, one can download the package with dget using this command: > > dget -x > https://mentors.debian.net/debian/pool/main/r/rurple-ng/rurple-ng_0.5+16-2.dsc Hi Thomas, the package on mentors uses a tarball that differs from the one in the archive. (But the package seems to build fine with the archive one.) > Changes since the last upload: > > * also build and ship the html manual The "build" entry in debian/clean is bogus: dh clean --with python2 dh_clean rm: cannot remove './build': Is a directory dh_clean: rm -f -- debian/rurple-ng.substvars ./build debian/files returned exit code 1 Could you fix that? (You can just put "rm -rf build" into the override_dh_auto_clean target you already have.) Christoph signature.asc Description: PGP signature
Bug#904385: arm64: sigaltstack fails with MINSIGSTKSZ for 32-bit processes
Package: src:linux
Version: 4.9.110-1
Severity: normal
Dear Maintainer,
The arm64 kernel allows one to run aarch32 processes on an aarch64
processor (if it has support for it), using the standard 32/64-bit
syscall compatibility. However this compat layer does not correctly
validate the arguments of the sigaltstack syscall.
arch/arm64/include/uapi/asm/signal.h defines SIGSTKSZ and MINSIGSTKSZ
as follow:
| #define MINSIGSTKSZ 5120
| #define SIGSTKSZ16384
arch/arm/include/uapi/asm/signal.h defines SIGSTKSZ and MINSIGSTKSZ as
follow:
| #define MINSIGSTKSZ 2048
| #define SIGSTKSZ8192
It seems to be the only 32/64-bit architecture for which those constants
differ. The do_compat_sigaltstack function in kernel/signal.c passes
ss.ss_size to do_sigaltstack unchanged, and the latter validates it
against the native MINSIGSTKSZ.
This causes the glibc test nptl/tst-signal6 to fail, but I guess it can
also affects other packages at runtime. This is also reproducible with
the following simple testcase:
| #include
| #include
| #include
|
| int main(int argc, char *argv[])
| {
| stack_t ss;
|
| ss.ss_sp = malloc(MINSIGSTKSZ);
| if (ss.ss_sp == NULL) {
| perror("malloc");
| exit(EXIT_FAILURE);
| }
|
| ss.ss_size = MINSIGSTKSZ;
| ss.ss_flags = 0;
| if (sigaltstack(&ss, NULL)) {
| perror("sigaltstack");
| exit(EXIT_FAILURE);
| }
|
| return 0;
| }
| $ ./sigaltstack
| sigaltstack: Cannot allocate memory
| $ strace ./sigaltstack
| execve("./sigaltstack", ["./sigaltstack"], [/* 23 vars */]) = 0
| strace: [ Process PID=694 runs in 32 bit mode. ]
| uname({sysname="Linux", nodename="arm64", ...}) = 0
| brk(NULL) = 0x35d000
| brk(0x35dd00) = 0x35dd00
| set_tls(0x35d4c0, 0x78f7c, 0, 0x24, 0x78f6c) = 0
| readlink("/proc/self/exe", "/home/aurel32/sigaltstack", 4096) = 25
| brk(0x37ed00) = 0x37ed00
| brk(0x37f000) = 0x37f000
| access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or
directory)
| sigaltstack({ss_sp=0x35e8b0, ss_flags=0x800 /* SS_??? */, ss_size=67191},
NULL) = -1 ENOMEM (Cannot allocate memory)
| dup(2) = 3
| fcntl64(3, F_GETFL) = 0x20002 (flags O_RDWR|0x2)
| fstat64(3, 0xff96bf28) = 0
| write(3, "sigaltstack: Cannot allocate mem"..., 36sigaltstack: Cannot
allocate memory
| ) = 36
| close(3)= 0
| exit_group(1) = ?
| +++ exited with 1 +++
-- System Information:
Debian Release: 9.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: arm64 (aarch64)
Kernel: Linux 4.9.0-7-arm64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8),
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Bug#867451: python-pysolr/python3-pysolr: missing dependencies
I don't mind at all, on the other hand. Thanks! Cheers, Dererk On 23/07/18 16:10, Andreas Beckmann wrote: On 2018-07-23 20:41, Dererk wrote: Hi Andreas. Just for me to understand, should I re-build, upload to proposed-updates && request d-release@ ? It has been some time since the last I did that, that why I wanted to avoid any mistakes from my end. Let's wait for an ACK from the release team on the PU request. If you don't mind, I'll upload it since I've already prepared it some time ago. Andreas -- BOFH excuse #154: You can tune a file system, but you can't tune a fish (from most tunefs man pages)
Bug#900816: cdargs: diff for NMU version 1.35-11.1
On Mon, Jul 23, 2018 at 20:27:04 +0800, David Bremner wrote: > I've prepared an NMU for cdargs (versioned as 1.35-11.1) and > uploaded it to DELAYED/05. Please feel free to tell me if I > should delay it longer. Thank you for the fix, this is fine with me. I did get around to installing emacs/experimental so far, but didn't have time to look into the reason for the error. -- mike signature.asc Description: PGP signature
Bug#813471: Seeking seconds for patch to permit some network access to localhost
Paul Wise writes ("Bug#813471: Seeking seconds for patch to permit some network
access to localhost"):
> For clarity, how about we separate the two types of network access?
>
> In addition, d-i relies on access to the apt repo for the system.
> I can imagine other uses of that, so I added a carve-out for that.
>
>For packages in the main archive, no required targets may attempt
>network access on non-loopback interfaces, except to the apt
>repositoryused by the system.
LGTM. It might be worth saying "the apt repository (both source and
binaries)". There are both packages which fetch .debs explicitly, and
packages which fetch sources explicitly (yes, this is not very good,
but consensus in a discussion of relevant people in ? Nicaragua I
think was that there isn't a better way right now, and that making a
better way would be a *lot* of work).
If you access the archive to fetch .debs or .dscs, you almost
certainly needed to put in a Built-Using. Maybe we should mention
that ?
>For packages in the main archive, no required targets may attempt
>network access on the loopback interface, except to services that
>were started by the build process. Services started by the build
>process must be shut down after use.
LGTM.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#813471: Seeking seconds for patch to permit some network access to localhost
Sean Whitton: > Here is a revised patch; David, hopefully you will renew your second. > >> diff --git a/policy/ch-source.rst b/policy/ch-source.rst >> index 9e7d79c..890c479 100644 >> --- a/policy/ch-source.rst >> +++ b/policy/ch-source.rst >> @@ -278,7 +278,8 @@ non-interactive. It also follows that any target that >> these targets >> depend on must also be non-interactive. >> >> For packages in the main archive, no required targets may attempt >> -network access. >> +network access, except, via the loopback interface, to services on the >> +build host that have been started by the build. >> >> The targets are as follows: >> Seconded. Thanks for the proposal, ~Niels
Bug#867451: python-pysolr/python3-pysolr: missing dependencies
On 2018-07-23 20:41, Dererk wrote: > Hi Andreas. > > Just for me to understand, should I re-build, upload to proposed-updates > && request d-release@ ? > > It has been some time since the last I did that, that why I wanted to > avoid any mistakes from my end. Let's wait for an ACK from the release team on the PU request. If you don't mind, I'll upload it since I've already prepared it some time ago. Andreas
Bug#904162: yubikey-luks: keyscript not run during boot
tags -1 + pending thanks On 21.07.2018 00:16, Matt Patey wrote: > I got it working again by changing /usr/share/initramfs-tools/scripts/local- > top/yubikey-luks as follows: I've adapted your path in a slightly different ways, see https://salsa.debian.org/auth-team/yubikey-luks/commit/af092665b9628956ba5318935b66584665fda978 Thanks for submitting, I'm preparing a release. Cheers Markus Frosch -- mar...@lazyfrosch.de / lazyfro...@debian.org http://www.lazyfrosch.de signature.asc Description: OpenPGP digital signature
Bug#904384: tpm2-tools: New upstream release (3.x) available
Package: tpm2-tools Version: 2.1.0-1 Severity: wishlist Dear Maintainer, tpm2-tools upstream released a new (major) release, please consider packaging it. Wearing the clevis package maintainer's head: The current version in Debian is too old to build some features needed for clevis-tpm. So the current situation isn't quite the best one. Regards, Christoph -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.14.56 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages tpm2-tools depends on: ii libc62.27-5 ii libcurl3-gnutls 7.60.0-2 pn libsapi-utils pn libsapi0 ii libssl1.11.1.0h-4 tpm2-tools recommends no packages. tpm2-tools suggests no packages. signature.asc Description: PGP signature
Bug#897792: [Pkg-kde-extras] Bug#897792: Bug#897792: libqaccessibilityclient: ftbfs with GCC-8
In data lunedì 23 luglio 2018 15:38:47 CEST, Maximiliano Curia ha scritto: > ¡Hola! > > El 2018-05-04 a las 12:22 +, Matthias Klose escribió: > > Package: src:libqaccessibilityclient > > Version: 0.1.1-5 > > Severity: normal > > Tags: sid buster > > User: debian-...@lists.debian.org > > Usertags: ftbfs-gcc-8 > > > Please keep this issue open in the bug tracker for the package it > > was filed for. If a fix in another package is required, please > > file a bug for the other package (or clone), and add a block in this > > package. Please keep the issue open until the package can be built in > > a follow-up test rebuild. > > > The package fails to build in a test rebuild on at least amd64 with > > gcc-8/g++-8, but succeeds to build with gcc-7/g++-7. The > > severity of this report will be raised before the buster release. > > > The full build log can be found at: > > http://aws-logs.debian.net/2018/05/01/gcc8/libqaccessibilityclient_0.1.1-5_unstable_gcc8.log.gz > > The last lines of the build log are at the end of this report. > > > To build with GCC 8, either set CC=gcc-8 CXX=g++-8 explicitly, > > or install the gcc, g++, gfortran, ... packages from experimental. > > > apt-get -t=experimental install g++ > > > Common build failures are new warnings resulting in build failures with > > -Werror turned on, or new/dropped symbols in Debian symbols files. > > For other C/C++ related build failures see the porting guide at > > http://gcc.gnu.org/gcc-8/porting_to.html > > It seems to me that src:libqaccessibilityclient currently has not reverse > dependencies, and since it's still qt4 based, we might want to get rid of it. We actually do want to use it. > Although, there is an "unstable" qt5 release > (https://download.kde.org/unstable/libqaccessibilityclient/), and recent > versions of kmag seem to be trying to use that. It seems misnamed, and actually the latest release in a while. > Sandro, if you plan to upload libqaccessibilityclient 0.2 please close this > issue with it. You could have checked this bug, see that I marked it as "pending", and possibly imagined the issue was taken care already. You could have checked its VCS: https://salsa.debian.org/qt-kde-team/extras/libqaccessibilityclient and noticing work on it, including this bug, and the Qt4 bug mentioned above. You could have also checked the kde-extras ML for possible uploads: https://alioth-lists.debian.net/pipermail/pkg-kde-extras/2018-July/029275.html ... and its NEW entry: https://ftp-master.debian.org/new/libqaccessibilityclient_0.2.0-1.html But you did not, as usual, check for things. Sad. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#867451: python-pysolr/python3-pysolr: missing dependencies
Hi Andreas. Just for me to understand, should I re-build, upload to proposed-updates && request d-release@ ? It has been some time since the last I did that, that why I wanted to avoid any mistakes from my end. Thanks in advance. \d On 14/01/18 19:10, Andreas Beckmann wrote: Followup-For: Bug #867451 stretch-pu request: https://bugs.debian.org/887321 Andreas -- BOFH excuse #154: You can tune a file system, but you can't tune a fish (from most tunefs man pages)
Bug#904383: python3-engineio: fails to install with Python 3.7
Package: python3-engineio
Version: 1.6.1-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Control: block 902788 with -1
Hi,
during a test with piuparts I noticed your package failed to install. As
per definition of the release team this makes the package too buggy for
a release, thus the severity.
>From the attached log (scroll to the bottom...):
Setting up python3-engineio (1.6.1-1) ...
File "/usr/lib/python3/dist-packages/engineio/server.py", line 357
ret = self._trigger_event('connect', sid, environ, async=False)
^
SyntaxError: invalid syntax
File "/usr/lib/python3/dist-packages/engineio/socket.py", line 56
async=self.server.async_handlers)
^
SyntaxError: invalid syntax
dpkg: error processing package python3-engineio (--configure):
installed python3-engineio package post-installation script subprocess
returned error exit status 1
Errors were encountered while processing:
python3-engineio
"async" has become a reserved keyword in Python 3.7
cheers,
Andreas
python3-engineio=1.6.1-1.log.gz
Description: application/gzip
Bug#891410: RFH: initramfs support for clevis
On Mon, 23 Jul 2018 at 18:32:44 +0200, Guilhem Moulin wrote:
> * /scripts/local-top/clevis: some bits look quite brittle, for
> instance
>
> psinfo=$(ps) # Doing this so I don't end up matching myself
> echo "$psinfo" | awk "/$cryptkeyscript/ { print \$1 }" | \
>
> and
>
> local $(grep '^CRYPTTAB_SOURCE=' /proc/$pid/environ)
Oh, I see these have been addressed in
https://github.com/latchset/clevis/pull/18#issuecomment-364683203 .
The reason why cryptsetup's cryptroot-unlock doesn't use pidof(1) is
because busybox's implementation doesn't support full pathnames, and
since we don't own the namespace there is nothing preventing another
package from running a program with that name.
And replacing NUL bytes with linefeeds in the environment will lead to
unexpected behavior if there are other variables set to a value
containing a linefeed, for instance if your crypttab(5)'s 4th column
contains an option set to value “blah\012CRYPTTAB_SOURCE=blah”. (Yes,
doing so is asking for trouble, but…)
So the following still holds:
> I believe that cryptroot-unlock's approach [0] is a lot more robust.
However I don't mean to dilute the main point of my former message:
| that code uses undocumented bits, which […] MUST NOT be used outside
| of src:cryptsetup. […] We have a documented interface for using the
| output of a program as key or passphrase, and clevis should use that
| instead of clevisloop().
--
Guilhem.
signature.asc
Description: PGP signature
Bug#904382: python3-doublex: fails to install with Python 3.7
Package: python3-doublex Version: 1.8.2-1 Severity: serious Tags: sid buster User: debian...@lists.debian.org Usertags: piuparts Control: block 902788 with -1 Hi, during a test with piuparts I noticed your package failed to install. As per definition of the release team this makes the package too buggy for a release, thus the severity. >From the attached log (scroll to the bottom...): Setting up python3-doublex (1.8.2-1) ... File "/usr/lib/python3/dist-packages/doublex/matchers.py", line 129 def async(self, timeout): ^ SyntaxError: invalid syntax File "/usr/lib/python3/dist-packages/doublex/test/async_race_condition_test.py", line 39 assert_that(spy.write, called().async(1)) ^ SyntaxError: invalid syntax File "/usr/lib/python3/dist-packages/doublex/test/unit_tests.py", line 1333 assert_that(spy.write, called().async(timeout=1)) ^ SyntaxError: invalid syntax dpkg: error processing package python3-doublex (--configure): installed python3-doublex package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: python3-doublex "async" has become a reserved keyword in Python 3.7 cheers, Andreas python3-doublex=1.8.2-1.log.gz Description: application/gzip
Bug#904381: python3-dns: fails to install with Python 3.7
Package: python3-dns Version: 3.1.1-1 Severity: serious Tags: sid buster User: debian...@lists.debian.org Usertags: piuparts Control: block 902788 with -1 Hi, during a test with piuparts I noticed your package failed to install. As per definition of the release team this makes the package too buggy for a release, thus the severity. >From the attached log (scroll to the bottom...): Setting up python3-dns (3.1.1-1) ... File "/usr/lib/python3/dist-packages/DNS/Base.py", line 96 self.async=None ^ SyntaxError: invalid syntax dpkg: error processing package python3-dns (--configure): installed python3-dns package post-installation script subprocess returned error exit status 1 "async" has become a reserved keyword in Python 3.7 cheers, Andreas python3-dns=3.1.1-1.log.gz Description: application/gzip
Bug#904380: [PATCH] Flash partitions not showing up on PowerNV systems
Package: linux-image-4.17.0-1-powerpc64le Version: 4.17.8-1 The MTD partitions of the main firmware Flash device are not exposed as MTD device nodes on PowerNV systems. This makes firmware updates difficult, requiring manual intervention on the loader shell. This issue has been fixed upstream via a one-line kernel patch (attached, see also [1]). Debian kernels should include this patch to allow firmware updates to be applied to PowerNV machines. Thank you! [1] https://patchwork.ozlabs.org/patch/943327/ >From patchwork Fri Jul 13 08:15:59 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: mtd: powernv_flash: set of_node in mtd's dev X-Patchwork-Submitter: =?utf-8?b?UmFmYcWCIE1pxYJlY2tp?= X-Patchwork-Id: 943327 X-Patchwork-Delegate: boris.brezil...@free-electrons.com Message-Id: <20180713081559.4373-1-zaj...@gmail.com> To: David Woodhouse , Brian Norris , Boris Brezillon , Marek Vasut , Richard Weinberger Cc: Benjamin Herrenschmidt , Timothy Pearson , linux-...@lists.infradead.org, Michael Ellerman , Miquel Raynal , =?utf-8?b?UmFmYcWCIE1pxYJlY2tp?= , Paul Mackerras , linuxppc-...@lists.ozlabs.org, Cyril Bur Date: Fri, 13 Jul 2018 10:15:59 +0200 From: =?utf-8?b?UmFmYcWCIE1pxYJlY2tp?= List-Id: Linux MTD discussion mailing list From: RafaÅ MiÅecki This enables some features implemented in mtd subsystem like reading label and partitioning info from DT. Reported-by: Timothy Pearson Signed-off-by: RafaÅ MiÅecki --- drivers/mtd/devices/powernv_flash.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/mtd/devices/powernv_flash.c b/drivers/mtd/devices/powernv_flash.c index c1312b141ae0..33593122e49b 100644 --- a/drivers/mtd/devices/powernv_flash.c +++ b/drivers/mtd/devices/powernv_flash.c @@ -223,6 +223,7 @@ static int powernv_flash_set_driver_info(struct device *dev, mtd->_read = powernv_flash_read; mtd->_write = powernv_flash_write; mtd->dev.parent = dev; + mtd_set_of_node(mtd, dev->of_node); return 0; }
Bug#875606: AutoReply: Re: Bug#875606: Debian mirror ftp-nyc.osuosl.org, ftp-chi.osuosl.org: does not sync correctly 4 times a day
Greetings, This message has been automatically generated in response to the creation of a support ticket call: "Re: Bug#875606: Debian mirror ftp-nyc.osuosl.org, ftp-chi.osuosl.org: does not sync correctly 4 times a day", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [support.osuosl.org #30182]. Please include this string in the subject line of all future correspondence about this issue. You may also catch us on irc (irc.freenode.net) in #osuosl. Thank you. supp...@osuosl.org - On Fri, 20 Jul 2018, Lance Albertson via RT wrote: > On Tue Sep 19 08:35:32 2017, ramereth wrote: > > On Mon Sep 18 13:12:07 2017, ramereth wrote: > > > I'm not sure what's causing this however they seem to be in sync as of > > > right > > > now. We've added nagios monitoring for the trace files on each host so we > > > can hopefully have better insight into the issue. Please let us know if we > > > start lagging behind again but I will do my best to check your mirror > > > status > > > site in the coming days. > > > > Very strange. I just got in the office and noticed that chi and nyc were > > behind again so I went looking to compare the trace files. After I ran 'cat' > > on the files, I went to look at the mirror report again and suddenly it > > decides to resolve itself at that point. I'm starting to wonder if this > > might > > be a filesystem issue and I need to run a fsck on the volume. I'm going to > > keep an eye on it later today and see if it does it again. > > Hi all, > > I finally got around to looking into this again. I've updated our ftpsync to > version 20180513 and made a few other adjustments. I've been checking your > mirror tracker [1][2][3] and it seems all three hosts are now keeping up > normally. Can you please verify that on your end as well? I'm hoping this > finally resolves the issue :) > > [1] > https://mirror-master.debian.org/status/mirror-info/ftp-osl.osuosl.org.html > [2] > https://mirror-master.debian.org/status/mirror-info/ftp-nyc.osuosl.org.html > [3] > https://mirror-master.debian.org/status/mirror-info/ftp-chi.osuosl.org.html Looks good for now. If not, I'll open a new issue. Thanks -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal https://www.palfrader.org/ | `. `' Operating System | `-https://www.debian.org/
Bug#904379: problem with get_identifier_with_length
Package: gcc-8-plugin-dev Version: 8.1.0-12 I get this when I try to compile the 4.14.57 kernel: CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h DESCEND objtool CHK include/generated/utsrelease.h In file included from ./scripts/gcc-plugins/gcc-common.h:101, from :1: /usr/lib/gcc/x86_64-linux-gnu/8/plugin/include/attribs.h: In function ‘tree_node* canonicalize_attr_name(tree)’: /usr/lib/gcc/x86_64-linux-gnu/8/plugin/include/attribs.h:118:12: error: ‘get_identifier_with_length’ was not declared in this scope return get_identifier_with_length (s + 2, l - 4); ^~ /usr/lib/gcc/x86_64-linux-gnu/8/plugin/include/attribs.h:118:12: note: suggested alternative: ‘get_attr_min_length’ return get_identifier_with_length (s + 2, l - 4); ^~ get_attr_min_length Cannot use CONFIG_GCC_PLUGINS: your gcc installation does not support plugins, perhaps the necessary headers are missing? make: *** [scripts/Makefile.gcc-plugins:70: gcc-plugins-check] Error 1 Any ideas?
Bug#904378: python-graphviz: autopkgtest failure: /usr/bin/python3.6: No module named pytest
Source: python-graphviz Version: 0.8.4-1 X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: regression Dear maintainers, Thanks for fixing bug 904245 so swiftly. However, your new version fails with the error copied below. Could you please investigate? Does the test miss a test dependency? Currently this failure is delaying the migration to testing by 13 days. Paul ¹ https://release.debian.org/transitions/html/python3.7.html https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-graphviz/657811/log.gz autopkgtest [09:15:08]: test command1: set -e ; for py in $(py3versions -r 2>/dev/null) ; do pushd "tests" ; echo "Testing with $py:" ; $py -m pytest -k 'not test_pipe_pipe_invalid_data_mocked' ; popd ; done autopkgtest [09:15:08]: test command1: [--- /tmp/autopkgtest-lxc.43526zes/downtmp/build.8Qz/src/tests /tmp/autopkgtest-lxc.43526zes/downtmp/build.8Qz/src Testing with python3.6: /usr/bin/python3.6: No module named pytest autopkgtest [09:15:09]: test command1: ---] signature.asc Description: OpenPGP digital signature
Bug#874810: RM: alt-key -- ROM; Upstream dead; Depends on deprecated Qt4
Package: ftp.debian.org Severity: normal X-Debbugs-CC: da...@debian.org Dear FTP Masters, Please remove alt-key. As discussed in https://bugs.debian.org/cgi-bin/874810, the maintainer of package alt-key has requested this package to be removed from Debian archive. Package alt-key has a dead upstream (upstream homepage wrote that the software is no longer maintained) and its last release was made 6 years ago. It is now affected by Debian's Qt4 Removal. Package alt-key is a leaf package and has no reverse dependencies. -- Regards, Boyuan Yang signature.asc Description: This is a digitally signed message part.
Bug#904335: fixed in upstream
Control: tags -1 + fixed-upstream According to https://github.com/systemd/systemd/issues/9702#issuecomment-407144025 this is fixed in the upstream. Ryutaroh
Bug#903583: Acknowledgement (liferea: Liferea ignores "accels" configuration and unable to change default ones)
Control: tags -1 - wontfix Control: tags -1 fixed-upstream On 21-07-18 13:46, Paul Gevers wrote: > On 21-07-18 11:26, Paul Gevers wrote: >> On 19-07-18 11:19, jEsuSdA 8) wrote: > I am sorry to tell you this but this is the upstream response: > > ''' > That is by design. Despite not being clearly marked as deprecated > GtkAccelMap doesn't work with GAction. So using gtk_accel_map_load > doesn't work any more, we would have to parse the file ourselves ... > > Custom shortcuts can be set from a python plugin. A very minimal one > would look like this : Upstream actually added this plugin to their repo. So it will be fixed after all. (But please read the report, mapping of accels won't be one-to-one.) When somebody has time, we could add the patch (it's trivial). Paul signature.asc Description: OpenPGP digital signature
