Bug#946193: Refuses to use profiles from stretch after upgrade to buster 68.2.0esr-1~deb9u2 -> 68.2.0esr-1~deb10u1
Package: firefox-esr Version: 68.2.0esr-1~deb10u1 Severity: important After upgrade from stretch to buster and starting firefox-esr, I was greeted with a dialog box saying "You've launched an older version of Firefox", refusing to use the existing profile. Turns out that as a result of using the latest stretch version, the file .mozilla/firefox/d0e3mzzp.default/compatibility.ini contained: [Compatibility] LastVersion=68.2.0_20191106112211/20191106112211 After upgrade to buster, a newly created profile contained: LastVersion=68.2.0_20191022215001/20191022215001 I was able to work around the issue by hand-editing the file in the older profile and pasting the newer version string, however: - not all users might be savvy enough to perfom this trick - there is still a chance I might face corruption due to using a profile creaed by the older version It would be great if a version equivalent to the stretch one could be uploaded to buster, to prevent this issue. -- Package-specific info: -- Addons package information -- System Information: Debian Release: 10.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.3.0-0.bpo.2-amd64 (SMP w/8 CPU cores) Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8), LANGUAGE=pl_PL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages firefox-esr depends on: ii debianutils 4.8.6.1 ii fontconfig2.13.1-2 ii libasound21.1.8-1 ii libatk1.0-0 2.30.0-2 ii libc6 2.28-10 ii libcairo-gobject2 1.16.0-4 ii libcairo2 1.16.0-4 ii libdbus-1-3 1.12.16-1 ii libdbus-glib-1-2 0.110-4 ii libevent-2.1-62.1.8-stable-4 ii libffi6 3.2.1-9 ii libfontconfig12.13.1-2 ii libfreetype6 2.9.1-3+deb10u1 ii libgcc1 1:8.3.0-6 ii libgdk-pixbuf2.0-02.38.1+dfsg-1 ii libglib2.0-0 2.58.3-2+deb10u2 ii libgtk-3-03.24.5-1 ii libjsoncpp1 1.7.4-3 ii libpango-1.0-01.42.4-7~deb10u1 ii libstartup-notification0 0.12-6 ii libstdc++68.3.0-6 ii libvpx5 1.7.0-3+deb10u1 ii libx11-6 2:1.6.7-1 ii libx11-xcb1 2:1.6.7-1 ii libxcb-shm0 1.13.1-2 ii libxcb1 1.13.1-2 ii libxcomposite11:0.4.4-2 ii libxdamage1 1:1.1.4-3+b3 ii libxext6 2:1.3.3-1+b2 ii libxfixes31:5.0.3-1 ii libxrender1 1:0.9.10-1 ii libxt61:1.1.5-1+b3 ii procps2:3.3.15-2 ii zlib1g1:1.2.11.dfsg-1 Versions of packages firefox-esr recommends: ii libavcodec58 7:4.1.4-1~deb10u1 Versions of packages firefox-esr suggests: pn fonts-lmodern pn fonts-stix | otf-stix ii libcanberra0 0.30-7 ii libgssapi-krb5-2 1.17-3 ii libgtk2.0-02.24.32-3 ii pulseaudio 12.2-4+deb10u1 -- no debconf information
Bug#943042: gitso: Python2 removal in sid/bullseye
Hi Scott, > > > The package doesn't look all that complicated. I can take a stab at > > > trying > > > to port it to Python 3. If I get it working, perhaps I can ask you to > > > test > > > it? > > > > that would be awesome! I can definitely do the testing. > > I submitted a merge request on salsa: > https://salsa.debian.org/debian/gitso/merge_requests/2 > > Let me know if you run into any problems or have any comments. that was fast! In my testing, the package behaves just like the old version, so I'll prepare an upload in a minute. Thanks a TON! Florian
Bug#946178: mercurial: FTBFS on hurd-i386: Testsuite failures
Hello, Am Mittwoch, den 04.12.2019, 23:26 +0100 schrieb Samuel Thibault: > Paul Sonnenschein, le mer. 04 déc. 2019 21:45:14 +0100, a ecrit: > > The test-http-bad-server.t fails due to an unexpected behaviour of > > local sockets in the Hurd. This seems to be a bug in the Hurd > > itself > > (pflocal specifically), being in violation of the POSIX > > specification > > Issue 6 and newer. > > Which violation is happening here? According to POSIX, both read and recv shall set errno to ECONNRESET if "[a] read was attempted on a socket and the connection was forcibly closed by its peer." As far as I can tell, pflocal will never return ECONNRESET. After further study however, I do no longer believe that this is the reason of the observed test failure, since connect already should fail. I now have no idea why this test is failing. Paul signature.asc Description: This is a digitally signed message part
Bug#922246: www/lts: if DLA-1234-1 and DLA-1234-2 exist, only that last one shows up in indexes
Brian May writes: > Is it OK if we simply delete this line? Done by https://salsa.debian.org/webmaster-team/webwml/merge_requests/298 -- Brian May
Bug#914821: libio-pty-perl: New upstream version - 1.12
Hi, This new version is required by Lintian, would you accept an NMU to update libio-pty-perl? Felix Lechner (Lintian maintainer) prepared it. Also if you want, package maintainance can be taken under Pkg-Perl umbrella. Cheers, Xavier
Bug#945917: jh_build: JH_JAR_EXTRA is ignored
On Sun, Dec 01, 2019 at 01:34:08AM +, Frédéric Perrin wrote:
> Package: javahelper
> Version: 0.72.9
> Severity: normal
>
> Dear Maintainer,
>
> Option JH_JAR_EXTRA is ignored by jh_build. When setting the script
> variable from the environment, the code looks at the existing value,
> rather than the env. IOW, it should be:
>
> diff -U0 jh_build.orig jh_build
> --- jh_build.orig 2019-12-01 00:25:24.162770395 +
> +++ jh_build 2019-12-01 00:35:58.528043183 +
> @@ -121 +121 @@
> -@JH_JAR_EXTRA = split(' ', $ENV{'JH_JAR_EXTRA'}) if @JH_JAR_EXTRA;
> +@JH_JAR_EXTRA = split(' ', $ENV{'JH_JAR_EXTRA'}) if $ENV{JH_JAR_EXTRA};
Indeed - thank you for spotting this and providing a patch. This was
introduced when jh_build was ported from shell to perl, as the env var
used to be interpolated directly [1].
We will address this in the next upload.
Thanks!
tony
[1]
https://salsa.debian.org/java-team/javatools/commit/b54816d93fd2e70b25902bfa97e890f3c87f8b8b#778240bd31b577096d826a2f46944192b1498411_170_253
signature.asc
Description: PGP signature
Bug#942914: caja-mediainfo: Python2 removal in sid/bullseye
Hi, This extension seems to work with Python 3 after one import change: -from MediaInfoDLL import * +from MediaInfoDLL3 import * After that, it also needs a dependency change from python-mediainfodll to python3-mediainfodll.
Bug#946192: ITP: golang-github-bep-tmc -- provides round-trip serialization of typed Go maps
Package: wnpp
Severity: wishlist
Owner: Anthony Fok
* Package name: golang-github-bep-tmc
Version : 0.5.1-1
Upstream Author : Bjørn Erik Pedersen
* URL : https://github.com/bep/tmc
* License : Expat
Programming Lang: Go
Description : provides round-trip serialization of typed Go maps
Codec for a Typed Map
.
bep/tmc provides basic roundtrip JSON etc. encoding/decoding of a
map[string]interface{} with custom type adapters.
.
Text based serialization formats like JSON and YAML are convenient, but
when used with Go maps, most type information gets lost in translation.
For structs, one can work around some of the limitations with custom
MarshalJSON, UnmarshalJSON, MarshalText and UnmarshalText.
For the commonly used flexible and schema-less "map[string]interface {}",
this is, as the author is aware of, not an option.
This library provides a solution to this problem.
.
See the GoDoc at https://godoc.org/github.com/bep/tmc for some
basic examples and how to configure custom codec, adapters, etc.
Reason for packaging: Needed by Hugo
Bug#875250: Intend to port to Qt 5
Hi Moritz, I started to work on qt5 port of SCIM. There is some remaining blocks. I will work on it for another 10 days. I want to postpone to deadline to Dec 15, if that does not drag the QT5 migration too much. Thank you for your understanding! Yours, Benda
Bug#946191: wavemon: Signal level reprted incorrectly
Package: wavemon Version: 0.8.2-1+b1 Severity: normal Signal level reported incorrectly. Unit mesure does not seem to reflect the reality. Unit mesure shows -50 dBm, and right next to it it shown as 0.5 nW. This is extremely low value and not consisten with a wifi link that performs as expected wit out any issues. 1 nW is = to 0.01 mW It seems that actual numeric value should be shown in mW and not in nW. That is all. Thank you for development efforts for this package. It's very useful. Please take a look at the units of mesure used to display the signal levels in mW. Thank you. Damien -- System Information: Debian Release: 10.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-6-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 /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages wavemon depends on: ii libc6 2.28-10 ii libncurses6 6.1+20181013-2+deb10u2 ii libnl-3-200 3.4.0-1 ii libnl-genl-3-200 3.4.0-1 ii libtinfo6 6.1+20181013-2+deb10u2 wavemon recommends no packages. wavemon suggests no packages. -- no debconf information
Bug#945985: [Debichem-devel] problem with python3-rdkit in Debian Sid
On 12/3/19 5:25 PM, mer...@debian.org wrote: > Hi Francois, > > On 2019-12-03 02:43, Francois Berenger wrote: >> Where can I follow this bug? > > I have filed a bug report [1] for this issue. By the way, could you try > installing 'libschroedinger-maeparser1' package and rerunning the > failing code? > > [1] https://bugs.debian.org/945985 > >> Also, how can I get and test the package in the NEW queue? > > You can clone the packaging repository [2], switch to > 'debian/201909.1-1' tag and build the binary packages with 'gbp > buildpackage -uc -us --git-ignore-branch', for example. > > [2] https://tracker.debian.org/pkg/rdkit Hello, Thanks for your feedback. The correct git URL that can be cloned looks like this one: [2] https://salsa.debian.org/debichem-team/rdkit.git I had to install the git-buildpackage program in order to run gbp. I am unable to run your proposed command: --- gbp buildpackage -uc -us --git-ignore-branch gbp:error: Currently not on a branch --- I did checkout 'debian/201909.1-1'. But this is a tag... Can you give me the exact sequence of commands that need to be run after a fresh checkout in order to run gbp? Thanks, F.
Bug#877783: Please provide python3-spyne
Bastian, I did see your email about 2.13.2-alpha, but it is alpha and thus belongs in experimental. I don't know if it is (the URL you gave for the .dsc is returning 404's) so I've removed the NMU. As for the removal for Python2 - they have made a lot of noise for something they haven't secured broad agreement on. I personally doubt it will happen. There are a lot of python2 programs out there running on debian boxes, most which is just scripts written by sysadmins. Removing Python2 would force a lot of users to not upgrade bullseye, or move away from Debian to something that still does support Python2. Note that just about all major distro's do - Debian's stance is peculiar in this regard. Removing programs that depend on Python2 in the archive may be possible, but it still sounds too hard to me. So my attitude for now is wait and see. If a stable version of spyne that supports python3 is released in the mean time it will end up in Debian stable, and the problem will disappear. I'll leave this bug open for now to remind me to look for a stable version of python3 spyne. signature.asc Description: This is a digitally signed message part
Bug#936834: ledger: Python2 removal in sid/bullseye
Control: severity -1 serious
--
ChangZhuo Chen (陳昌倬) czchen@{czchen,debconf,debian}.org
http://czchen.info/
Key fingerprint = BA04 346D C2E1 FE63 C790 8793 CC65 B0CD EC27 5D5B
signature.asc
Description: PGP signature
Bug#936834: ledger: Python2 removal in sid/bullseye
severity -1 serious
Currently we cannot run ledger due to libboost_python27.so.1.67.0. Looks
like ledger need to migrate to Python3 to make it useable.
$ ledger
ledger: error while loading shared libraries: libboost_python27.so.1.67.0:
cannot open shared object file: No such file or directory
--
ChangZhuo Chen (陳昌倬) czchen@{czchen,debconf,debian}.org
http://czchen.info/
Key fingerprint = BA04 346D C2E1 FE63 C790 8793 CC65 B0CD EC27 5D5B
signature.asc
Description: PGP signature
Bug#946190: RFS: lebiniou/3.32-1 -- displays images that evolve with sound
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "lebiniou": * Package name: lebiniou Version : 3.32-1 Upstream Author : Olivier Girondel * URL : https://biniou.net * License : GPL-2+ Section : graphics It builds this binary package: lebiniou - displays images that evolve with sound The package appears to be lintian-clean. To access further information about this package, please visit the following URL: https://mentors.debian.net/package/lebiniou Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/l/lebiniou/lebiniou_3.32-1.dsc Changes since the last upload: * New upstream release 3.32. * debian/control: Standards-Version: 4.4.1. * debian/lebiniou.lintian-overrides: Added. * debian/control: Build-Depends: Update debhelper-compat (= 12). * debian/control: Add Rules-Requires-Root: no. * debian/compat: Remove. * debian.rules: Add override_dh_shlibdeps. Regards, Olivier Girondel
Bug#740373: fetchmail: Generated emails about authentication failure is missing message-id
Am 04.12.19 um 10:14 schrieb Petter Reinholdtsen: > [Matthias Andree 2014-05-20] > While it sure is optional according to RFC5322, it is considered best > practice to include in in emails. What is the reason the fetchmail > developers do not want to include Message-ID into these notification? > I currently use fetchmail+procmail to receive emails from IMAP servers, > and the IMAP servers seem to make sure Message-ID is present. The > issue at hand here are emails not originating from the IMAP servers, > unfortunatly. What is the reason people use inferior software and then only to a small stretch of its possibilities, and then try to put convenience features into other packages? What is the new argument that could sway the original decision? Or think that the fetchmail developers would have to answer such questions at all? If the issue is with procmail + notmuch not generating that header, or coping without, then fix that. So? If you must use that unmaintained piece from the museum of anti-designs called "procmail", you can as well rig it to pipe all ingress mail through "formail -a Message-ID" if notmuch still fails without such a header. formail is part of the procmail package. Or you could use reformail from the maildrop package. Other options might exist.
Bug#946189: python-numpy: blas -> blis
Package: python-numpy Version: 1.16.0 Severity: wishlist Since version 1.17.0, numpy's own blas detection order is mkl,blis,openblas,atlas,accelerate,blas The first one available on Debian is BLIS, so perhaps it's time to think about replacingthe BLAS dependency with BLIS. Cheers, Nico -- System Information: Debian Release: bullseye/sid APT prefers focal APT policy: (500, 'focal') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.3.0-19-generic (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python-numpy depends on: ii libblas3 [libblas.so.3] 3.9.0-1 ii libc62.30-0ubuntu2 ii liblapack3 [liblapack.so.3] 3.9.0-1 pn python-pkg-resources pn python2 pn python2.7 python-numpy recommends no packages. Versions of packages python-numpy suggests: ii gcc 4:9.2.1-3.1ubuntu1 ii gfortran 4:9.2.1-3.1ubuntu1 pn python-dev pn python-numpy-dbg pn python-numpy-doc pn python-pytest
Bug#900171: debian-installer: include free firmware-ath9k-htc
Ping :). AR9271 dominates modern free-software-friendly wireless dongles and I would love to see their support in Bullseye. Please let me know if I can help. signature.asc Description: This is a digitally signed message part.
Bug#944294: buster-pu: package libvirt-daemon/5.0.0-4
Hi, On Wed, Nov 27, 2019 at 05:52:33PM +0100, Guido Günther wrote: > Hi, > On Wed, Nov 27, 2019 at 04:17:13PM +, Adam D. Barratt wrote: > > Control: tags -1 -confirmed +moreinfo > > > > Hi, > > > > On 2019-11-27 16:07, Guido Günther wrote: > > > Hi Adam, > > > On Wed, Nov 27, 2019 at 01:21:40PM +, Adam D. Barratt wrote: > > > > Control: tags -1 + confirmed > > > > > > > > On 2019-11-27 13:05, Michal Arbet wrote: > > > > > I've added a patch from upstream ( sid already included it in new > > > > > version ). > > > > > Check current debdiff in attachment. > > > > > > > > That looks OK, assuming it's been build- and runtime-tested on a > > > > buster > > > > system. > > > > > > It would be nice to coordinate such things with the package > > > maintainers. I've had question's regarding these patches which weren't > > > answered yet: > > > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944248#26 > > > > Apologies for that, we tend to assume that people making such requests > > either work on the package or have had that co-ordination discussion > > already. > > > > In this case I'll put the request on hold until we hear back. > > Thanks.I intend to look at the particular issue and fold it into the > update with > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939036 > > which is still pending. Attached is the debdiff with #933036 included as well. O.k. to upload to stable-p-u? Cheers, -- Guido > -- Guido > > > > > Regards, > > > > Adam > >
Bug#946188: RM: tilix [armhf] -- ROM; FTBFS due to GDC bug and blocks other architecture fixes
Package: ftp.debian.org Severity: normal Hi! Please remove the tilix package binaries for the armhf architecture temporarily. The armhf arch is affected by GDC bug #944380 for a while now, and the package does not migrate to testing while it's not built on armhf. Meanwhile, all packages depending on it are broken on all architectures until the new version migrates (due to LDC ABI issues), so in this particular instance I think it is justified that the package is removed on armhf temporarily, to allow it to migrate. The armhf binaries will highly likely be reintroduces as soon as the issue is fixed in GDC or worked around there, and glib-d built on armhf with gdc. RM issues were filed against appstream-generator, glib-d and gtk-d as well in the past, but tilix was missed out somehow until now. With GDC 10, these issues will hopefully be fixed and we can have armhf back, but until then having a working Tilix in testing on the other architectures would be nice. Thanks for considering! Cheers, Matthias -- I welcome VSRE emails. See http://vsre.info/
Bug#946187: ITP: starship -- Minimal, blazing fast, and extremely customizable prompt for any shell
Package: wnpp Severity: wishlist Owner: Daniele Tricoli * Package name: starship Version : 0.27.0 Upstream Author : Matan Kushner * URL : https://starship.rs * License : ISC License Programming Lang: Rust Description : Minimal, blazing fast, and extremely customizable prompt for any shell starship is a cross-shell prompt extremely customizable. Features - Prompt character turns red if the last command exits with non-zero code - Current username if not the same as the logged-in user - Current Java/Node.js/Rust/Ruby/Python/Go version - Nix-shell environment detection - Current battery level and status - Current Git branch and rich repo status - Execution time of the last command if it exceeds the set threshold - Indicator for jobs in the background - Current Kubernetes Cluster and Namespace - Current AWS profile This will be packaged via the Rust packaging team using the debcargo-conf workflow. -- Daniele Tricoli 'eriol' https://mornie.org
Bug#940138:
I've just checked; the problem is still present in 5.3.0-2. Any news from your side? Thanks Kendy
Bug#910823: upstream has closed https://github.com/docker/docker-credential-helpers/issues/105
Please fix the dependencies for this package. https://github.com/docker/docker-credential-helpers/issues/105#issuecomment-561573736
Bug#910822: upstream has closed https://github.com/docker/docker-credential-helpers/issues/105
Please fix the dependencies for this package. https://github.com/docker/docker-credential-helpers/issues/105#issuecomment-561573736
Bug#946184: buster-pu: package fig2dev/1:3.2.7a-5+deb10u2
Hi Adam! On Mi, 04 Dez 2019, Adam D. Barratt wrote: > Control: tags -1 + moreinfo > > On Wed, 2019-12-04 at 22:50 +0100, Roland Rosenfeld wrote: > > This fixes CVE-2019-19555 in buster. Since this is tagged > > "unimportant" by the security team on > > https://security-tracker.debian.org/tracker/CVE-2019-19555 they won't > > publish a DSA, so I tend to send this into the next point release of > > buster. > The Security Tracker and BTS suggest this issue is not yet resolved in > unstable - is that correct? Seems, that the systems are slower than me today :-) According to https://tracker.debian.org/news/1084412/accepted-fig2dev-1327b-2-source-into-unstable/ the upload to unstable proceeded. But it seems that I have a typo (brace at wrong position) in the changelog, so the bug was not closed :-( I'll just send out a closing mail by hand and will fix the wrong brace in the patches against buster and stretch soon. Greetings Roland
Bug#946186: RFS: trace-cmd/2.8.3-2 -- Utility for retrieving and analyzing function tracing in the kernel
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "trace-cmd" * Package name: trace-cmd Version : 2.8.3-2 Upstream Author : Steven Rostedt * URL : http://kernelshark.org/ * License : GPL-2 * Vcs : https://github.com/sudipm-mukherjee/trace-cmd.git Section : devel It builds those binary packages: trace-cmd - Utility for retrieving and analyzing function tracing in the kernel kernelshark - Utilities for graphically analyzing function tracing in the kernel. To access further information about this package, please visit the following URL: https://mentors.debian.net/package/trace-cmd Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/t/trace-cmd/trace-cmd_2.8.3-2.dsc Changes since the last upload: * build should be verbose by default (Closes: #946067) * Add the watch file -- Regards Sudip
Bug#946178: mercurial: FTBFS on hurd-i386: Testsuite failures
Hello, Paul Sonnenschein, le mer. 04 déc. 2019 21:45:14 +0100, a ecrit: > The test-http-bad-server.t fails due to an unexpected behaviour of > local sockets in the Hurd. This seems to be a bug in the Hurd itself > (pflocal specifically), being in violation of the POSIX specification > Issue 6 and newer. Which violation is happening here? Samuel
Bug#946184: buster-pu: package fig2dev/1:3.2.7a-5+deb10u2
Control: tags -1 - moreinfo Hi Adam, On Wed, Dec 04, 2019 at 10:04:04PM +, Adam D. Barratt wrote: > Control: tags -1 + moreinfo > > On Wed, 2019-12-04 at 22:50 +0100, Roland Rosenfeld wrote: > > This fixes CVE-2019-19555 in buster. Since this is tagged > > "unimportant" by the security team on > > https://security-tracker.debian.org/tracker/CVE-2019-19555 they won't > > publish a DSA, so I tend to send this into the next point release of > > buster. > > The Security Tracker and BTS suggest this issue is not yet resolved in > unstable - is that correct? The package has been uploaded to unstable, but it's only just not yet installed and the tracker data thus knowing the version. Cf. https://tracker.debian.org/news/1084412/accepted-fig2dev-1327b-2-source-into-unstable/ and https://salsa.debian.org/security-tracker-team/security-tracker/commit/08d5562d87450a464efa5fbecaa792a38bee6123 Regards, Salvatore
Bug#921220: xchat stops autoconnecting, complaining about "%U" and "host unknown", broken .desktop entry ?
The control email got bounced before unarchiving, here are the details of new findings. - Mail original - > unarchive 921220 > reopen 921220 > retitle 921220 xchat.desktop makes invalid use of %U, breaks at least > lxqt and flwm > affects 921220 + lxqt flwm > severity 921220 grave > thanks > I've switched away from lxqt and forgot to follow up on this issue, > but now I'm stumbling on a configure error of flwm, > which qualifies as grave under the "breaks other package" rule. > E: Sub-process /usr/bin/dpkg returned an error code (1) > Setting up flwm (1.02+git2015.10.03+7dbb30-6) ... > Exec key for 'XChat IRC' contains '%F', '%U' or '%D' at the wrong > place > dpkg: error processing package flwm (--configure): > installed flwm package post-installation script subprocess returned > error exit status 255 > Errors were encountered while processing: > flwm > Note that the freedesktop standard [1] says "Field codes must not be > used inside a quoted argument, the result of field code expansion > inside a > quoted argument is undefined", this could possibly be the reason for > any complaint. > If I replace the faulty line by just "Exec=xchat --existing --url %U" > the flwm configure step does succeed, which seems to confirm this > diagnostic. > Probably the better solution would be to use a wrapper script, which > could have saner behaviour (the current behaviour lauches "exec > xchat" > on any error of the first try, where it looks like what we really > want is to launch it if %U is empty. > https://specifications.freedesktop.org/desktop-entry-spec/latest/ar01s07.html > - Mail original - > > De: "Gianfranco Costamagna" > > > À: ydir...@free.fr, 921220-d...@bugs.debian.org > > > Envoyé: Mardi 5 Février 2019 11:13:35 > > > Objet: Re: Bug#921220: xchat stops autoconnecting, complaining > > about > > "%U" and "host unknown", broken .desktop entry ? > > > Hello, > > > >OTOH when launched from cmdline the problem does not appear. > > > > > > > >And indeed the provided .desktop file shows: > > > > > > > >Exec=sh -c "xchat --existing --url %U || exec xchat" > > > > > > > >Could it be that there was a fix in a recently-dropped patch ? > > > I didn't drop any patch (you didn't even tell me which was your > > previous version, so its difficult to say) > > > but looks like a network error to me > > I guess at that time I made assumptions on not-so-recent "Drop old > and useless patch" changelog entry, my bad.
Bug#946184: buster-pu: package fig2dev/1:3.2.7a-5+deb10u2
Control: tags -1 + moreinfo On Wed, 2019-12-04 at 22:50 +0100, Roland Rosenfeld wrote: > This fixes CVE-2019-19555 in buster. Since this is tagged > "unimportant" by the security team on > https://security-tracker.debian.org/tracker/CVE-2019-19555 they won't > publish a DSA, so I tend to send this into the next point release of > buster. The Security Tracker and BTS suggest this issue is not yet resolved in unstable - is that correct? Regards, Adam
Bug#946185: stretch-pu: package fig2dev/1:3.2.6a-2+deb9u3
Package: release.debian.org Severity: normal Tags: stretch User: release.debian@packages.debian.org Usertags: pu This fixes CVE-2019-19555 in stretch. Since this is tagged "unimportant" by the security team on https://security-tracker.debian.org/tracker/CVE-2019-19555 they won't publish a DSA, so I tend to send this into the next point release of buster. Attached you'll find the diff against 3.2.6a-2+deb9u2. Greetings Roland diff -Nru fig2dev-3.2.6a/debian/changelog fig2dev-3.2.6a/debian/changelog --- fig2dev-3.2.6a/debian/changelog 2019-07-27 10:22:45.0 +0200 +++ fig2dev-3.2.6a/debian/changelog 2019-12-04 22:22:00.0 +0100 @@ -1,3 +1,10 @@ +fig2dev (1:3.2.6a-2+deb9u3) stretch; urgency=medium + + * 41_CVE-2019-19555: Allow Fig v2 text strings ending with multiple ^A. +This fixes CVE-2019-19555. Closes (#946176). + + -- Roland Rosenfeld Wed, 04 Dec 2019 22:22:00 +0100 + fig2dev (1:3.2.6a-2+deb9u2) stretch; urgency=medium * 40_circle_arrowhead: Do not segfault on circle/half circle arrowheads diff -Nru fig2dev-3.2.6a/debian/patches/41_CVE-2019-19555.patch fig2dev-3.2.6a/debian/patches/41_CVE-2019-19555.patch --- fig2dev-3.2.6a/debian/patches/41_CVE-2019-19555.patch 1970-01-01 01:00:00.0 +0100 +++ fig2dev-3.2.6a/debian/patches/41_CVE-2019-19555.patch 2019-12-04 22:22:00.0 +0100 @@ -0,0 +1,27 @@ +From: Thomas Loimer +Date: Wed Dec 4 17:56:04 2019 +0100 +Bug: https://sourceforge.net/p/mcj/tickets/55 +Bug-Debian: https://bugs.debian.org/946176 +Origin: https://sourceforge.net/p/mcj/fig2dev/ci/19db5fe6f77ebad91af4b4ef0defd61bd0bb358f/ +Subject: Allow Fig v2 text strings ending with multiple ^A. + This fixes CVE-2019-19555 + +--- a/fig2dev/read.c b/fig2dev/read.c +@@ -3,6 +3,7 @@ + * Copyright (c) 1991 by Micah Beck + * Parts Copyright (c) 1985-1988 by Supoj Sutanthavibul + * Parts Copyright (c) 1989-2002 by Brian V. Smith ++ * Parts Copyright (c) 2015-2019 by Thomas Loimer + * + * Any party obtaining a copy of these files is granted, free of charge, a + * full and unrestricted irrevocable, world-wide, paid up, royalty-free, +@@ -1223,7 +1224,7 @@ read_textobject(FILE *fp) + If we do not find the CONTROL-A on this line then this must + be a multi-line text object and we will have to read more. */ + +- n = sscanf(buf,"%*d%d%d%lf%d%d%d%lf%d%lf%lf%d%d%[^\1]%[\1]", ++ n = sscanf(buf,"%*d%d%d%lf%d%d%d%lf%d%lf%lf%d%d%[^\1]%1[\1]", + >type, >font, >size, >pen, + >color, >depth, >angle, + >flags, >height, >length, diff -Nru fig2dev-3.2.6a/debian/patches/series fig2dev-3.2.6a/debian/patches/series --- fig2dev-3.2.6a/debian/patches/series 2019-07-27 10:22:45.0 +0200 +++ fig2dev-3.2.6a/debian/patches/series 2019-12-04 22:22:00.0 +0100 @@ -5,3 +5,4 @@ 31_input_sanitizing.patch 32_fill-style-overflow.patch 40_circle_arrowhead.patch +41_CVE-2019-19555.patch
Bug#936886: Bug#946174: libktoblzcheck: Python2 removal in sid/bullseye
Status update: I started working on removing the python 2 package, which turned out to be more complicated than necessary. I had to rip out a broken chunk from CMakeLists.txt that caused the build to fail when no Python interpreter is installed. This made at least the build succeed again, but for some reason now the very basic autopkgtest is failing. The work in progress code to fix this bug is currently tracked in branch python_removal on Salsa: https://salsa.debian.org/aqbanking-team/pkg-ktoblzcheck/tree/python_removal Check the autopkgtest log from Salsa CI for details about how bad it fails: https://salsa.debian.org/aqbanking-team/pkg-ktoblzcheck/-/jobs/440456 The way how bad the autopkgtest fails... Could not read directory "": No such file or directory Oops, no bank data file was found in directory ""! The ktoblzcheck library will not work. ... reminds how the package broke in my first attempts of using CMake for building libktoblzcheck 1.50. At that time I added -DINSTALL_RAW_BANKDATA_FILE=1 to dh_auto_configure in debian/rules. Now it looks as if this flag no longer causes the correct bank data path to be hard-coded. We will need to look into the code to see what's different this time.
Bug#946184: buster-pu: package fig2dev/1:3.2.7a-5+deb10u2
Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu This fixes CVE-2019-19555 in buster. Since this is tagged "unimportant" by the security team on https://security-tracker.debian.org/tracker/CVE-2019-19555 they won't publish a DSA, so I tend to send this into the next point release of buster. Attached you'll find the diff against 3.2.7a-5+deb10u1. Greetings Roland diff -Nru fig2dev-3.2.7a/debian/changelog fig2dev-3.2.7a/debian/changelog --- fig2dev-3.2.7a/debian/changelog 2019-07-27 09:51:53.0 +0200 +++ fig2dev-3.2.7a/debian/changelog 2019-12-04 22:12:49.0 +0100 @@ -1,3 +1,10 @@ +fig2dev (1:3.2.7a-5+deb10u2) buster; urgency=medium + + * 41_CVE-2019-19555: Allow Fig v2 text strings ending with multiple ^A. +This fixes CVE-2019-19555. Closes (#946176). + + -- Roland Rosenfeld Wed, 04 Dec 2019 22:12:49 +0100 + fig2dev (1:3.2.7a-5+deb10u1) buster; urgency=medium * 40_circle_arrowhead: Do not segfault on circle/half circle arrowheads diff -Nru fig2dev-3.2.7a/debian/patches/41_CVE-2019-19555.patch fig2dev-3.2.7a/debian/patches/41_CVE-2019-19555.patch --- fig2dev-3.2.7a/debian/patches/41_CVE-2019-19555.patch 1970-01-01 01:00:00.0 +0100 +++ fig2dev-3.2.7a/debian/patches/41_CVE-2019-19555.patch 2019-12-04 22:12:49.0 +0100 @@ -0,0 +1,28 @@ +From: Thomas Loimer +Date: Wed Dec 4 17:56:04 2019 +0100 +Bug: https://sourceforge.net/p/mcj/tickets/55 +Bug-Debian: https://bugs.debian.org/946176 +Origin: https://sourceforge.net/p/mcj/fig2dev/ci/19db5fe6f77ebad91af4b4ef0defd61bd0bb358f/ +Subject: Allow Fig v2 text strings ending with multiple ^A. + This fixes CVE-2019-19555 + +--- a/fig2dev/read.c b/fig2dev/read.c +@@ -3,7 +3,7 @@ + * Copyright (c) 1991 by Micah Beck + * Parts Copyright (c) 1985-1988 by Supoj Sutanthavibul + * Parts Copyright (c) 1989-2015 by Brian V. Smith +- * Parts Copyright (c) 2015-2018 by Thomas Loimer ++ * Parts Copyright (c) 2015-2019 by Thomas Loimer + * + * Any party obtaining a copy of these files is granted, free of charge, a + * full and unrestricted irrevocable, world-wide, paid up, royalty-free, +@@ -1318,7 +1318,7 @@ read_textobject(FILE *fp) + If we do not find the CONTROL-A on this line then this must + be a multi-line text object and we will have to read more. */ + +- n = sscanf(buf,"%*d%d%d%lf%d%d%d%lf%d%lf%lf%d%d%[^\1]%[\1]", ++ n = sscanf(buf,"%*d%d%d%lf%d%d%d%lf%d%lf%lf%d%d%[^\1]%1[\1]", + >type, >font, >size, >pen, + >color, >depth, >angle, + >flags, >height, >length, diff -Nru fig2dev-3.2.7a/debian/patches/series fig2dev-3.2.7a/debian/patches/series --- fig2dev-3.2.7a/debian/patches/series 2019-07-27 09:51:53.0 +0200 +++ fig2dev-3.2.7a/debian/patches/series 2019-12-04 22:12:49.0 +0100 @@ -12,3 +12,4 @@ 37_pgf-etex.patch 38_omit_showpage.patch 40_circle_arrowhead.patch +41_CVE-2019-19555.patch signature.asc Description: PGP signature
Bug#945595: New mpv in sid breaks smplayer
On Wed, 27 Nov 2019 17:17:32 +0100 Alf Gaida wrote: > new mpv 0.30* don't play well with smplayer in sid - new 19.10.* will solve > that problem. > > No action needed right now, will work on it. Salsa shows as latest commit "prepare to upload" (of version 19.10.2). Why hasn't it been uploaded already? signature.asc Description: This is a digitally signed message part.
Bug#946160: hwloc: please round PCIe link values
Le 04/12/2019 à 18:51, Laurent Bonnaud a écrit : > On 04/12/2019 16.15, Brice Goglin wrote: > >> PCIe links (since Gen3) are encoded 128 data rate over 130 signal rate. >> That's why you get 3.93 (truncated to 3.9). We decided to keep that >> value exact in hwloc because the data/signal rate is different among >> PCIe generations. We could round it up to 4 in the lstopo output, but I >> am not sure where to start (PCIe Gen4 16x is 31.5GB/s instead of 32 and >> Gen5 will be 63 instead of 64, those are harder to round up). > Thanks for the detailed explanation! > > How about displaying the PCIe generation and number of links? We often get similar requests for various hardware attributes. Unfortunately, hwloc is not an exhaustive inventory tool. lstopo is the visible part of a library for managing hardware locality. Adding many somehow-unrelated hardware details might be risky (slow down the discovery process, make the API larger, make the ABI harder to maintain, etc). We rather tell people to use dedicated tools for getting hardware-specific details. In the case of PCI Gen + number of lanes, there's a notion of "supported maximal" rate per lane and "current" rate (high-end GPUs slowdown PCI lanes when idle). I'd rather not handle all these details in hwloc. Brice
Bug#936199: fixed in bedtools 2.28.0+dfsg1-1
reopen 936199 thanks > bedtools (2.28.0+dfsg1-1) unstable; urgency=medium > . >* Use 2to3 to port to Python3 > Closes: #936199 Hi Andreas, The build dependency still uses python and also needs to be switched to python3. Cheers, Moritz
Bug#946183: Should fusionforge be removed?
Source: fusionforge Severity: serious There hasn't been an upload since two years and fusionforge missed the last two stable releases and has gathered five RC bugs at this point. Should it be removed? Cheers, Moritz
Bug#946182: RM: disper -- RoQA; unmaintained, broken, dead upstream, depends on Python 2
Package: ftp.debian.org Severity: normal Please remove disper, it's unmaintained (last upload in 2014), broken since 2016 (#844505), dead upstream (last activity in 2013) and depends on Python 2. Cheers, Moritz
Bug#927137: src:tumgreyspf: Please port to python3 or remove
On Sat, Aug 24, 2019 at 02:07:26AM -0400, Scott Kitterman wrote: > On Mon, 15 Apr 2019 09:01:29 -0400 Scott Kitterman > wrote: > > Package: src:tumgreyspf > > Version: 1.36-4.1 > > Severity: important > > > > Python2.7 will go out of upstream security support during the Bullseye > > development cycle. It is not safe to assume it will be included in the > > next release, so if you want to be sure tumgreyspf can stay in Debian, > please > > port it to python3. > > > > Alternately, it's close to 8 years without a new release and there are > > certainly alternatives for SPF checking and greylisting. Removal might be > in > > order. > > > > Personally, I want to remove some packages I maintain, particularly python- > > ipaddr, which tumgreyspf depends on (indirectly via python-spf - which I > will > > change to python3 only) during the Bullseye cycle, regardless of what > > happens to python2.7, so please update (python3 includes the ipaddress > module, > > which was developed from ipaddr, in the standard library). > > Bumping to serious since python2 removals are going on in earnest and this > will need to be ported or removed soon. Thomas, tumgreyspf seems dead upstream, the last commit on Github is from April 2015, should we remove it from the archive? Cheers, Moritz
Bug#946181: knot-resolver: CVE-2019-19331
Source: knot-resolver Version: 3.2.1-3 Severity: grave Tags: security upstream Hi, The following vulnerability was published for knot-resolver. CVE-2019-19331[0], but see [1] for more details. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2019-19331 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-19331 [1] https://www.openwall.com/lists/oss-security/2019/12/04/4 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#946180: openssh-server: Occasionally missing privilege separation directory with ssh.socket
Package: openssh-server Version: 1:7.9p1-10+deb10u1 Severity: important Using RuntimeDirectory in ssh.service and ssh@.service creates the needed directory /run/sshd but there are issues in two cases: 1. After switching from ssh.socket to ssh.service while a ssh connection is open, results in future logins to fail. Closing the existing ssh.socket connection let systemd to remove /run/sshd despite ssh.service already running. Subsequent logins fail as it has no runtime directory anymore. This is especially bad as it will lock an administrator out. Even testing logins before closing the last connection does not highlight this issue. SSH login works again after the directory is created manually or the host or service is restarted (directory is recreated by ssh). 2. Testing sshd configuration (using `sshd -t`) while neither ssh.service or ssh@.service are running fails. It complains that the privilege separation directory /run/sshd does not exist. I tried different things: - Adding RuntimeDirectoryPreserve=yes to ssh@.service to ensure the directory is kept. This address case one but `sshd -t` still fails until ssh.service is started or a connection has been established. Otherwise systemd has not yet created the directory. - Using tempfiles.d to create the directory on system boot. Combining both might work to create the directory in just every case. -- Demo case 1: # systemctl status ssh.socket Active: active (listening) # systemctl start ssh.service # systemctl status ssh@0.service Active: active (running) # logout $ ssh sshbug ssh_exchange_identification: read: Connection reset by peer # systemctl status ssh@0.service Active: inactive (dead) # systemctl status ssh Active: active (running) sshd[6641]: Server listening on :: port 22. systemd[1]: Started OpenBSD Secure Shell server. sshd[6654]: fatal: Missing privilege separation directory: /run/sshd -- Demo case 2 # systemctl start ssh.service # systemctl status ssh Active: active (running) # systemctl status ssh.socket Active: inactive (dead) # sshd -t # systemctl start ssh.socket # systemctl status ssh.socket Active: active (listening) # systemctl status ssh.service Active: inactive (dead) # sshd -t Missing privilege separation directory: /run/sshd -- System Information: Debian Release: 10.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-cloud-amd64 (SMP w/1 CPU core) 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) LSM: AppArmor: enabled Versions of packages openssh-server depends on: ii adduser3.118 ii debconf [debconf-2.0] 1.5.71 ii dpkg 1.19.7 ii libaudit1 1:2.8.4-3 ii libc6 2.28-10 ii libcom-err21.44.5-1+deb10u2 ii libgssapi-krb5-2 1.17-3 ii libkrb5-3 1.17-3 ii libpam-modules 1.3.1-5 ii libpam-runtime 1.3.1-5 ii libpam0g 1.3.1-5 ii libselinux12.8-1+b1 ii libssl1.1 1.1.1d-0+deb10u2 ii libsystemd0241-7~deb10u2 ii libwrap0 7.6.q-28 ii lsb-base 10.2019051400 ii openssh-client 1:7.9p1-10+deb10u1 ii openssh-sftp-server1:7.9p1-10+deb10u1 ii procps 2:3.3.15-2 ii ucf3.0038+nmu1 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages openssh-server recommends: ii libpam-systemd [logind] 241-7~deb10u2 pn ncurses-term pn xauth Versions of packages openssh-server suggests: pn molly-guard pn monkeysphere pn rssh pn ssh-askpass pn ufw -- debconf information: openssh-server/permit-root-login: true
Bug#946179: [lxcfs] lxcfs tries to delete systemd cgroup folders, fails stopping lxc
Package: lxcfs Version: 2.0.7-1+deb9u1 Severity: grave Here's lxc log: lxc-start 20191204112931.787 INFO lxc_cgroup - cgroups/cgroup.c:cgroup_init:68 - cgroup driver cgroupfs initing for debian-test lxc-start 20191204112931.790 ERRORlxc_cgfs - cgroups/cgfs.c:lxc_cgroupfs_create:901 - Could not find writable mount point for cgroup hierarchy 11 while trying to create cgroup. lxc-start 20191204112931.802 ERRORlxc_cgfs - cgroups/cgfs.c:cgroup_rmdir:209 - Device or resource busy - cgroup_rmdir: failed to delete /sys/fs/cgroup/systemd//user/root/0 lxc-start 20191204112931.807 ERRORlxc_cgfs - cgroups/cgfs.c:cgroup_rmdir:209 - Device or resource busy - cgroup_rmdir: failed to delete /sys/fs/cgroup/systemd//user/root lxc-start 20191204112931.808 ERRORlxc_cgfs - cgroups/cgfs.c:cgroup_rmdir:209 - Device or resource busy - cgroup_rmdir: failed to delete /sys/fs/cgroup/systemd//user lxc-start 20191204112931.808 ERRORlxc_cgfs - cgroups/cgfs.c:cgroup_rmdir:209 - Device or resource busy - cgroup_rmdir: failed to delete /sys/fs/cgroup/systemd//user.slice/user-135.slice/session-1.scope lxc-start 20191204112931.808 ERRORlxc_cgfs - cgroups/cgfs.c:cgroup_rmdir:209 - Device or resource busy - cgroup_rmdir: failed to delete /sys/fs/cgroup/systemd//user.slice/user-135.slice lxc-start 20191204112931.808 ERRORlxc_cgfs - cgroups/cgfs.c:cgroup_rmdir:209 - Device or resource busy - cgroup_rmdir: failed to delete /sys/fs/cgroup/systemd//user.slice/user-0.slice/session-c1.scope lxc-start 20191204112931.809 ERRORlxc_cgfs - cgroups/cgfs.c:cgroup_rmdir:209 - Device or resource busy - cgroup_rmdir: failed to delete /sys/fs/cgroup/systemd//user.slice/user-0.slice lxc-start 20191204112931.817 ERRORlxc_cgfs - cgroups/cgfs.c:cgroup_rmdir:209 - Device or resource busy - cgroup_rmdir: failed to delete /sys/fs/cgroup/systemd//user.slice/user-1000.slice/session-2.scope lxc-start 20191204112931.817 ERRORlxc_cgfs - cgroups/cgfs.c:cgroup_rmdir:209 - Device or resource busy - cgroup_rmdir: failed to delete /sys/fs/cgroup/systemd//user.slice/user-1000.slice lxc-start 20191204112931.817 ERRORlxc_cgfs - cgroups/cgfs.c:cgroup_rmdir:209 - Device or resource busy - cgroup_rmdir: failed to delete /sys/fs/cgroup/systemd//user.slice lxc-start 20191204112931.817 ERRORlxc_cgfs - cgroups/cgfs.c:cgroup_rmdir:209 - Device or resource busy - cgroup_rmdir: failed to delete /sys/fs/cgroup/systemd/ lxc-start 20191204112931.817 ERRORlxc_start - start.c:lxc_spawn:1108 - Failed creating cgroups. lxc-start 20191204112931.857 INFO lxc_conf - conf.c:lxc_delete_network:3015 - Removed interface "(null)" with index 18. lxc-start 20191204112931.883 WARN lxc_conf - conf.c:lxc_delete_network:3038 - Failed to remove "vethXD8GPK" from host: Invalid argument. lxc-start 20191204112931.883 WARN lxc_monitor - monitor.c:lxc_monitor_fifo_send:111 - Failed to open fifo to send message: No such file or directory. lxc-start 20191204112931.883 ERRORlxc_start - start.c:__lxc_start:1346 - Failed to spawn container "debian-test". lxc-start 20191204112931.884 WARN lxc_monitor - monitor.c:lxc_monitor_fifo_send:111 - Failed to open fifo to send message: No such file or directory. lxc-start 20191204112931.884 WARN lxc_monitor - monitor.c:lxc_monitor_fifo_send:111 - Failed to open fifo to send message: No such file or directory. lxc-start 20191204112931.884 INFO lxc_conf - conf.c:run_script_argv:424 - Executing script "/usr/share/lxcfs/lxc.reboot.hook" for container "debian-test", config section "lxc". lxc-start 20191204112932.401 ERRORlxc_start_ui - tools/lxc_start.c:main:366 - The container failed to start. lxc-start 20191204112932.401 ERRORlxc_start_ui - tools/lxc_start.c:main:370 - Additional information can be obtained by setting --- System information. --- Architecture: Kernel: Linux 4.9.0-5-amd64 Debian Release: 9.11 500 oldstable-updates deb.debian.org 500 oldstable security.debian.org 500 oldstable deb.debian.org 100 stretch-backports deb.debian.org --- Package information. --- Depends (Version) | Installed ==-+-=== libc6(>= 2.17) | libfuse2 (>= 2.6) | init-system-helpers (>= 1.18~) | lsb-base(>= 3.0-6) | Package's Recommends field is empty. Package's Suggests field is empty.
Bug#946178: mercurial: FTBFS on hurd-i386: Testsuite failures
Source: mercurial
Severity: important
Version: 5.2-1
User: debian-h...@lists.debian.org
Usertags: hurd
X-Debbugs-CC: debian-h...@lists.debian.org
Hello,
mercurial fails to build from source on hurd-i386 due to five failing
tests.
Of these tests, four fail due to unexpected error numbers.
This should be fixed in mercurial, because error numbers are not
standardized.
The test-http-bad-server.t fails due to an unexpected behaviour of
local sockets in the Hurd. This seems to be a bug in the Hurd itself
(pflocal specifically), being in violation of the POSIX specification
Issue 6 and newer.
This could be fixed by
* Fixing the Hurd itself
* Making the test more permissive
* Blacklisting the test
The attached patch replaces the error number in the offending tests
with a * glob.
Thanks!
Excerpts from build log [0]:
> test-http-bad-server.t
> test-http-bad-server.t ... # Test test-http-bad-server.t
> # Running sh "/tmp/hgtests.7iB8Fk/child58/test-http-bad-server.t.sh"
>
> --- /<>/tests/test-http-bad-server.t
> +++ /<>/tests/test-http-bad-server.t.err
> @@ -38,7 +38,7 @@
>$ cat hg.pid > $DAEMON_PIDS
>
>$ hg clone http://localhost:$HGPORT/ clone
> - abort: error: (\$ECONNRESET\$|\$EADDRNOTAVAIL\$) (re)
> + abort: error: bad HTTP status line: No status line received - the
> server has closed the connection
>[255]
>
> (The server exits on its own, but there is a race between that and
> starting a new server.
>
> ERROR: test-http-bad-server.t output changed
> !# Ret was: 0 (test-http-bad-server.t)
> test-lfs.t
> test-lfs.t ... # Test test-lfs.t
> # Running sh "/tmp/hgtests.7iB8Fk/child104/test-lfs.t.sh"
>
> --- /<>/tests/test-lfs.t
> +++ /<>/tests/test-lfs.t.err
> @@ -40,7 +40,7 @@
>> EOF
>
>$ hg config extensions
> - *** failed to import extension lfs from missing.py: [Errno 2]
> $ENOENT$: 'missing.py'
> + *** failed to import extension lfs from missing.py: [Errno
> 1073741826] $ENOENT$: 'missing.py'
>abort: repository requires features unknown to this Mercurial:
> lfs!
>(see https://mercurial-scm.org/wiki/MissingRequirement for more
> information)
>[255]
>
> ERROR: test-lfs.t output changed
> !# Ret was: 0 (test-lfs.t)
(Analogous failures exist for test-largefiles-misc.t, test-lfs-serve-
access.t and test-repair-strip.t)
[0]:
https://buildd.debian.org/status/fetch.php?pkg=mercurial=hurd-i386=5.2-1=1573130161=0
From: Paul Sonnenschein
Description: Fix test failures on hurd-i386 (Errno values)
Forwarded: no
diff --git a/tests/test-largefiles-misc.t b/tests/test-largefiles-misc.t
index 11b9de3a..eed33f44 100644
--- a/tests/test-largefiles-misc.t
+++ b/tests/test-largefiles-misc.t
@@ -41,7 +41,7 @@ common commands affecting largefile.
> EOF
$ hg config extensions
- *** failed to import extension largefiles from missing.py: [Errno 2] $ENOENT$: 'missing.py'
+ \*\*\* failed to import extension largefiles from missing.py: [Errno *] $ENOENT$: 'missing.py' (glob)
abort: repository requires features unknown to this Mercurial: largefiles!
(see https://mercurial-scm.org/wiki/MissingRequirement for more information)
[255]
diff --git a/tests/test-lfs-serve-access.t b/tests/test-lfs-serve-access.t
index 940b6e78..b789462f 100644
--- a/tests/test-lfs-serve-access.t
+++ b/tests/test-lfs-serve-access.t
@@ -341,13 +341,13 @@ Test a checksum failure during the processing of the GET request
$LOCALIP - - [$ERRDATE$] HG error: Traceback (most recent call last): (glob)
$LOCALIP - - [$ERRDATE$] HG error: verifies = store.verify(oid) (glob)
$LOCALIP - - [$ERRDATE$] HG error: raise IOError(errno.EIO, r'%s: I/O error' % oid.decode("utf-8")) (glob)
- $LOCALIP - - [$ERRDATE$] HG error: *Error: [Errno 5] f03217a32529a28a42d03b1244fe09b6e0f9fd06d7b966d4d50567be2abe6c0e: I/O error (glob)
+ $LOCALIP - - [$ERRDATE$] HG error: *Error: [Errno *] f03217a32529a28a42d03b1244fe09b6e0f9fd06d7b966d4d50567be2abe6c0e: I/O error (glob)
$LOCALIP - - [$ERRDATE$] HG error: (glob)
$LOCALIP - - [$ERRDATE$] HG error: Exception happened while processing request '/.git/info/lfs/objects/batch': (glob)
$LOCALIP - - [$ERRDATE$] HG error: Traceback (most recent call last): (glob)
$LOCALIP - - [$ERRDATE$] HG error: verifies = store.verify(oid) (glob)
$LOCALIP - - [$ERRDATE$] HG error: raise IOError(errno.EIO, r'%s: I/O error' % oid.decode("utf-8")) (glob)
- $LOCALIP - - [$ERRDATE$] HG error: *Error: [Errno 5] b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c: I/O error (glob)
+ $LOCALIP - - [$ERRDATE$] HG error: *Error: [Errno *] b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c: I/O error (glob)
$LOCALIP - - [$ERRDATE$] HG error: (glob)
$LOCALIP - - [$ERRDATE$] HG error: Exception happened while processing request '/.hg/lfs/objects/b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c': (glob)
$LOCALIP - - [$ERRDATE$] HG error: Traceback (most recent call last): (glob)
@@ -369,7
Bug#946177: RFS: pdf2djvu/0.9.14-1 [ITA] -- PDF to DjVu converter
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "pdf2djvu" * Package name: pdf2djvu Version : 0.9.14-1 Upstream Author : Jakub Wilk * URL : http://jwilk.net/software/pdf2djvu * License : GPL-2 * Vcs : https://salsa.debian.org/debian/pdf2djvu Section : text It builds those binary packages: pdf2djvu - PDF to DjVu converter To access further information about this package, please visit the following URL: https://mentors.debian.net/package/pdf2djvu Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/pdf2djvu/pdf2djvu_0.9.14-1.dsc Changes since the last upload: * New upstream release * New maintainer. (Closes: #945185) * deb/control: + bump standards to 4.4.1 (no changes needed). Regards, -- Sebastien CHAVAUX
Bug#946176: fig2dev: CVE-2019-19555
Source: fig2dev Version: 1:3.2.7b-1 Severity: normal Tags: security upstream Forwarded: https://sourceforge.net/p/mcj/tickets/55/ Hi, The following vulnerability was published for fig2dev. CVE-2019-19555[0]: | read_textobject in read.c in Xfig fig2dev 3.2.7b has a stack-based | buffer overflow because of an incorrect sscanf. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2019-19555 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-19555 [1] https://sourceforge.net/p/mcj/tickets/55/ [2] https://sourceforge.net/p/mcj/fig2dev/ci/19db5fe6f77ebad91af4b4ef0defd61bd0bb358f/ Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#943042: gitso: Python2 removal in sid/bullseye
On Wed, 4 Dec 2019, Florian Schlichting wrote: The package doesn't look all that complicated. I can take a stab at trying to port it to Python 3. If I get it working, perhaps I can ask you to test it? that would be awesome! I can definitely do the testing. I submitted a merge request on salsa: https://salsa.debian.org/debian/gitso/merge_requests/2 Let me know if you run into any problems or have any comments. Scott
Bug#946175: buster-pu: package uif/1.1.9-1+deb10u1
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
Hi,
only after the buster release I became aware of the nftables shift. I
totally missed that.
+ * debian/patches:
++ Add 1001_use-iptables-legacy.patch. Work-around iptables->nftables switch
+ in Debian. Full nftables support is being worked on on the upstream side.
+ (Closes: #932265).
For Debian buster, I added a patch to uif so that it uses the
iptables-legacy commands directly.
For Debian bullseye, I (with upstream hat on) work on proper nftables
integration.
Please ACK the already uploaded uif 1.1.9-1+deb10u1, so that people can
still use uif in Debian buster.
Thanks,
Mike
-- System Information:
Debian Release: 10.2
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru uif-1.1.9/debian/changelog uif-1.1.9/debian/changelog
--- uif-1.1.9/debian/changelog 2018-08-19 02:15:35.0 +0200
+++ uif-1.1.9/debian/changelog 2019-12-04 21:06:28.0 +0100
@@ -1,3 +1,12 @@
+uif (1.1.9-1+deb10u1) buster; urgency=medium
+
+ * debian/patches:
++ Add 1001_use-iptables-legacy.patch. Work-around iptables->nftables switch
+ in Debian. Full nftables support is being worked on on the upstream side.
+ (Closes: #932265).
+
+ -- Mike Gabriel Wed, 04 Dec 2019 21:06:28 +0100
+
uif (1.1.9-1) unstable; urgency=medium
* New upstream release.
diff -Nru uif-1.1.9/debian/patches/1001_use-iptables-legacy.patch
uif-1.1.9/debian/patches/1001_use-iptables-legacy.patch
--- uif-1.1.9/debian/patches/1001_use-iptables-legacy.patch 1970-01-01
01:00:00.0 +0100
+++ uif-1.1.9/debian/patches/1001_use-iptables-legacy.patch 2019-12-04
21:06:13.0 +0100
@@ -0,0 +1,38 @@
+--- a/uif.pl
b/uif.pl
+@@ -1475,9 +1475,9 @@
+
+ @$Listing=map { $_."\n" } @$Listing;
+ if ($ipv6) {
+- open (IPT, '/sbin/ip6tables-save|');
++ open (IPT, '/usr/sbin/ip6tables-legacy-save|');
+ } else {
+- open (IPT, '/sbin/iptables-save|');
++ open (IPT, '/usr/sbin/iptables-legacy-save|');
+ }
+ @oldrules = ;
+ close (IPT);
+@@ -1488,9 +1488,9 @@
+ $SIG{'TERM'} = 'signalCatcher';
+
+ if ($ipv6) {
+- open (IPT, '|/sbin/ip6tables-restore');
++ open (IPT, '|/usr/sbin/ip6tables-legacy-restore');
+ } else {
+- open (IPT, '|/sbin/iptables-restore');
++ open (IPT, '|/usr/sbin/iptables-legacy-restore');
+ }
+ print IPT @$Listing;
+ close (IPT);
+@@ -1501,9 +1501,9 @@
+ }
+ if ($timeout || $SignalCatched || $error) {
+ if ($ipv6) {
+- open (IPT, '|/sbin/ip6tables-restore');
++ open (IPT, '|/usr/sbin/ip6tables-legacy-restore');
+ } else {
+- open (IPT, '|/sbin/iptables-restore');
++ open (IPT, '|/usr/sbin/iptables-legacy-restore');
+ }
+ print IPT @oldrules;
+ close (IPT);
diff -Nru uif-1.1.9/debian/patches/series uif-1.1.9/debian/patches/series
--- uif-1.1.9/debian/patches/series 1970-01-01 01:00:00.0 +0100
+++ uif-1.1.9/debian/patches/series 2019-12-04 21:06:13.0 +0100
@@ -0,0 +1 @@
+1001_use-iptables-legacy.patch
Bug#946174: RFS: streamlink/1.3.0+dfsg-1~bpo10+1
Package: sponsorship-requests Severity: wishlist X-Debbugs-CC: debian-backpo...@lists.debian.org Dear mentors, I am looking for a sponsor for my package "streamlink" into Debian buster-backports repository. * Package name: streamlink Version : 1.3.0+dfsg-1~bpo10+1 Upstream Author : Streamlink Team * URL : https://streamlink.github.io/ * License : BSD-2-clause, Apache-2.0, MIT/Expat, SIL-OFL-1.1 Section : python It builds those binary packages: python3-streamlink - Python module for extracting video streams from various websites python3-streamlink-doc - CLI for extracting video streams from various websites (documentation) streamlink - CLI for extracting video streams from various websites to a video player To access further information about this package, please visit the following URL: https://mentors.debian.net/package/streamlink Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/s/streamlink/streamlink_1.3.0+dfsg-1~bpo10+1.dsc More information about streamlink can be obtained at https://streamlink.github.io/ Changes since the last upload to buster-backports: streamlink (1.3.0+dfsg-1~bpo10+1) buster-backports; urgency=medium * Rebuild for buster-backports. -- Alexis Murzeau Wed, 04 Dec 2019 20:28:29 +0100 streamlink (1.3.0+dfsg-1) unstable; urgency=medium * Vcs-Git: move from github to salsa * New upstream version 1.3.0+dfsg * Remove pixiv typo patch, applied upstream * Bump standard version to 4.4.1, no change required * Use debhelper-compat in B-D instead of d/compat * Add "Rules-Requires-Root: no" in d/rules -- Alexis Murzeau Sun, 24 Nov 2019 20:09:58 +0100 Differences from testing package (1.3.0+dfsg-1): * Update d/README.source for buster-backports Regards, -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F signature.asc Description: OpenPGP digital signature
Bug#945185: O: pdf2djvu -- PDF to DjVu converter
Hello, I wanted to know if pdf2djvu is still orphaned and in this case I will make a request to adopt it. Thank you Cordialy, Sebastien CHAVAUX
Bug#946173: ddgr: Please include zsh and fish completions in package
Package: ddgr Version: 1.7+git20190928.bccdc92-1 Severity: wishlist Dear Maintainer, The ddgr upstream includes completion files for zsh and fish in addition to bash which is currently the only one included in the Debian package. Please consider including these files. Since I am still only a Debian Maintainer I do not have direct access to the repo, so I have opened a merge request which includes this change: https://salsa.debian.org/debian/ddgr/merge_requests/1
Bug#946172: lxc-checkconfig gives incorrect warnings with cgroupv2 / unified hierarchy
Package: lxc Version: 1:3.1.0+really3.0.4-2 Severity: minor Tags: upstream User: pkg-systemd-maintain...@lists.alioth.debian.org Usertags: cgroupv2 Control: -1 forwarded https://github.com/lxc/lxc/issues/3208 Dear Maintainer, Under cgroup2 / unified hierarchy, lxc-checkconfig gives some incorrect warnings in red color as # lxc-checkconfig Kernel configuration not found at /proc/config.gz; searching... Kernel configuration found at /boot/config-5.3.0-2-amd64 Cgroup v1 systemd controller: missing Cgroup v1 freezer controller: missing Cgroup namespace: required It was reported to https://github.com/lxc/lxc/issues/3208 Best regards, Ryutaroh Matsumoto -- System Information: Debian Release: 10.1 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.3.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) LSM: AppArmor: enabled Versions of packages lxc depends on: ii debconf [debconf-2.0] 1.5.71 ii libc6 2.29-3 ii libgcc11:8.3.0-6 ii liblxc11:3.1.0+really3.0.4-2 ii lsb-base 10.2019051400 Versions of packages lxc recommends: ii apparmor 2.13.2-10 ii bridge-utils 1.6-2 ii debootstrap 1.0.114 ii dirmngr 2.2.12-1+deb10u1 ii dnsmasq-base [dnsmasq-base] 2.80-1 ii gnupg2.2.12-1+deb10u1 ii iproute2 4.20.0-2 ii iptables 1.8.2-4 ii libpam-cgfs 1:3.1.0+really3.0.4-2 ii lxc-templates3.0.4-1 pn lxcfs ii nftables 0.9.0-2 ii openssl 1.1.1c-1 ii rsync3.1.3-8 ii uidmap 1:4.5-1.1 Versions of packages lxc suggests: pn btrfs-progs ii lvm2 2.03.02-3 pn python3-lxc -- debconf information: lxc/auto_update_config:
Bug#946171: RM: uglifyjs/experimental -- ROM; confuses vcswatch (will never enter unstable)
Package: ftp.debian.org Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi ftpmasters, Please drop src:uglifyjs 3.3.10-1 from experimental. It is a no longer maintained branch of uglifyjs, confusing vcswatch (apparently vcswatch ignores the later released 2.x.x package where Vcs-* fields has been corrected). Thanks, - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl3oBEoACgkQLHwxRsGg ASHoqRAAgSQzY7GrBJNakY4Zs6etd3OqJaXux3PtuHs1ZDb0e8LJkAtYGwJWCbDq m0uLUmXpECRRbZPiYVY2f00jD86oqYXUGUhGzuxo/TQ2c5Enz06U7YOH2SOCeE/Y 97NVHw6mroopKDEPBAorMCJ7ulJDmkc55UB+9qfOfSL5zlcvQuHMAvn6+xXguJ4v yapKKMuV6ZFHE5mEF+2ARsx0E24/t+KXSQhB1ZmfjbPbkYLBxaNAg8ew6lkR363b OF2DbaME2H0hVefQZHk2lUQDBSFXjs8D1UF2U10lxhT9aTLHhQjpAKMzAENNsOR7 +t3yN+FlRLWBerfordbRN3p7PPSjnHR55gFmRNGtNS6C5+kmuW6Ej3EyZ0hk1a7U 4zYwqbAiQ9lsTtsvyswcxkOXiReTCEF4UUcSkG2Po5PvQcGa6kis1z5VJofvsUTg Orrt9pGmq0iFIbJjBqfM30+796RokoAz9AXWNQf1QdMS9GhRQkfZDjI+yo9ZusOl CN0EkHiwFiltf5VmX5FP2DEA3KbjJwvfwm780yFGxbyrBAUiMs7BTYPXAoS7INmj glSGCnAHs3jIOb7d36xVf/QkiNFC2xLXf2IyBKFEqMEX+mDnVdqP7aBYeGBgSE5d yUYHxdcF9HVyO6yJJJIanSbaao/ge3s/zGvks58h5ju/sB/yTIk= =zS2Z -END PGP SIGNATURE-
Bug#946170: libpam-cgfs: does nothing under cgroupv2 / unified hierarchy
Package: libpam-cgfs Version: 1:3.1.0+really3.0.4-2 Severity: important Tags: upstream User: pkg-systemd-maintain...@lists.alioth.debian.org Usertags: cgroupv2 Control: -1 forwarded https://github.com/lxc/lxc/issues/3198 Control: block 943981 by -1 Dear Maintainer, According to https://github.com/lxc/lxc/blob/master/doc/pam_cgfs.sgml.in libpam_cgfs chowns some cgroup directories to a login user, but actually it does nothing under cgroup2 unified hierarchy, as $ ls -l /sys/fs/cgroup/user.slice/user-1000.slice /sys/fs/cgroup/user.slice/user-1000.slice/session-2.scope /sys/fs/cgroup/user.slice/user-1000.slice: total 0 -r--r--r-- 1 root root 0 Dec 5 03:40 cgroup.controllers -r--r--r-- 1 root root 0 Dec 5 03:40 cgroup.events -rw-r--r-- 1 root root 0 Dec 5 03:40 cgroup.freeze -rw-r--r-- 1 root root 0 Dec 5 03:40 cgroup.max.depth -rw-r--r-- 1 root root 0 Dec 5 03:40 cgroup.max.descendants -rw-r--r-- 1 root root 0 Dec 5 03:40 cgroup.procs -r--r--r-- 1 root root 0 Dec 5 03:40 cgroup.stat -rw-r--r-- 1 root root 0 Dec 5 03:40 cgroup.subtree_control -rw-r--r-- 1 root root 0 Dec 5 03:40 cgroup.threads -rw-r--r-- 1 root root 0 Dec 5 03:40 cgroup.type -rw-r--r-- 1 root root 0 Dec 5 03:40 cpu.pressure -r--r--r-- 1 root root 0 Dec 5 03:40 cpu.stat -rw-r--r-- 1 root root 0 Dec 5 03:40 io.max -rw-r--r-- 1 root root 0 Dec 5 03:40 io.pressure -r--r--r-- 1 root root 0 Dec 5 03:40 io.stat -r--r--r-- 1 root root 0 Dec 5 03:40 memory.current -r--r--r-- 1 root root 0 Dec 5 03:40 memory.events -r--r--r-- 1 root root 0 Dec 5 03:40 memory.events.local -rw-r--r-- 1 root root 0 Dec 5 03:40 memory.high -rw-r--r-- 1 root root 0 Dec 5 03:40 memory.low -rw-r--r-- 1 root root 0 Dec 5 03:40 memory.max -rw-r--r-- 1 root root 0 Dec 5 03:40 memory.min -rw-r--r-- 1 root root 0 Dec 5 03:40 memory.oom.group -rw-r--r-- 1 root root 0 Dec 5 03:40 memory.pressure -r--r--r-- 1 root root 0 Dec 5 03:40 memory.stat -r--r--r-- 1 root root 0 Dec 5 03:40 pids.current -r--r--r-- 1 root root 0 Dec 5 03:40 pids.events -rw-r--r-- 1 root root 0 Dec 5 03:40 pids.max drwxr-xr-x 2 root root 0 Dec 5 03:40 session-2.scope drwxr-xr-x 4 ryutaroh ryutaroh 0 Dec 5 03:40 user@1000.service /sys/fs/cgroup/user.slice/user-1000.slice/session-2.scope: total 0 -r--r--r-- 1 root root 0 Dec 5 03:42 cgroup.controllers -r--r--r-- 1 root root 0 Dec 5 03:40 cgroup.events -rw-r--r-- 1 root root 0 Dec 5 03:42 cgroup.freeze -rw-r--r-- 1 root root 0 Dec 5 03:42 cgroup.max.depth -rw-r--r-- 1 root root 0 Dec 5 03:42 cgroup.max.descendants -rw-r--r-- 1 root root 0 Dec 5 03:40 cgroup.procs -r--r--r-- 1 root root 0 Dec 5 03:42 cgroup.stat -rw-r--r-- 1 root root 0 Dec 5 03:40 cgroup.subtree_control -rw-r--r-- 1 root root 0 Dec 5 03:42 cgroup.threads -rw-r--r-- 1 root root 0 Dec 5 03:42 cgroup.type -rw-r--r-- 1 root root 0 Dec 5 03:42 cpu.pressure -r--r--r-- 1 root root 0 Dec 5 03:40 cpu.stat -rw-r--r-- 1 root root 0 Dec 5 03:42 io.max -rw-r--r-- 1 root root 0 Dec 5 03:42 io.pressure -r--r--r-- 1 root root 0 Dec 5 03:42 io.stat -r--r--r-- 1 root root 0 Dec 5 03:42 memory.current -r--r--r-- 1 root root 0 Dec 5 03:42 memory.events -r--r--r-- 1 root root 0 Dec 5 03:42 memory.events.local -rw-r--r-- 1 root root 0 Dec 5 03:40 memory.high -rw-r--r-- 1 root root 0 Dec 5 03:40 memory.low -rw-r--r-- 1 root root 0 Dec 5 03:40 memory.max -rw-r--r-- 1 root root 0 Dec 5 03:40 memory.min -rw-r--r-- 1 root root 0 Dec 5 03:42 memory.oom.group -rw-r--r-- 1 root root 0 Dec 5 03:42 memory.pressure -r--r--r-- 1 root root 0 Dec 5 03:42 memory.stat -r--r--r-- 1 root root 0 Dec 5 03:42 pids.current -r--r--r-- 1 root root 0 Dec 5 03:42 pids.events -rw-r--r-- 1 root root 0 Dec 5 03:40 pids.max Best regards, Ryutaroh Matsumoto -- System Information: Debian Release: 10.1 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.3.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) LSM: AppArmor: enabled Versions of packages libpam-cgfs depends on: ii libc6 2.29-3 ii libgcc1 1:8.3.0-6 ii libpam-runtime 1.3.1-5 ii libpam0g1.3.1-5 libpam-cgfs recommends no packages. libpam-cgfs suggests no packages. -- no debconf information
Bug#945943: exim4: FTBFS on hurd-i386: "operating system GNU is not supported"
On 2019-12-04 Samuel Thibault wrote: > Control: tags -1 + patch fixed-upstream > Hello, > Here are the patches which were applied upstream. Thank you!
Bug#918163: Broken in Stretch
Control: tags -1 stretch Control: tags -1 buster Control: tags -1 sid Control: severity - 1 serious Hi, and once again this package isn't working anymore due the API change for AddOns that are introduced by Thunderbird 68.x Thunderbird now requires AddOns that are build as webextension. So far I've seen this package needs to get updated to version 0.3.1 to get it working in Thunderbird 68.x. This will requiring changes to the Debian packaging. Examples how the packaging needs to be done to fit the requirements to get system wide installed Thunderbird AddOns recognized by Thunderbird can be found on these packages e.g. https://salsa.debian.org/webext-team/compactheader/tree/debian/sid/debian https://salsa.debian.org/webext-team/tbsync/tree/debian/experimental/debian Please also move over the binary package name to webext-sieve-extension as this was discussed and wantied naming schema within the Mozilla Packaging Team. This will require to make the old binary name a transitional package. If you want or need help please say so. Thanks! Regards Carsten
Bug#946168: [Pkg-netmeasure-discuss] Bug#946168: flent: Please make a new source-only upload to allow testing migration
Hi Toke, 在 2019-12-04三的 19:22 +0100，Toke Høiland-Jørgensen写道： > > On 4 December 2019 19:09:01 CET, Boyuan Yang wrote: > > Package: flent > > Version: 1.3.2-1 > > Severity: important > > X-Debbugs-CC: t...@toke.dk > > > > Dear flent maintainer, > > > > Your previous uploads of package flent were not source-only uploads; as > > a > > result, the new verison of flent will not be able to migrate to Debian > > Testing. The restriction on non-source-only upload went into effect > > since the > > release of Debian Buster; you may find the detailed announcement at > > https://lists.debian.org/debian-devel-announce/2019/07/msg2.html . > > > > Please make another source-only upload. Details about how to make > > source-only > > uploads can be found at https://wiki.debian.org/SourceOnlyUpload . > > Since you > > have been granted the DM upload permission, you should be able to make > > source- > > only uploads by yourself. > > Can do. Does this mean I can skip the binary uploads completely in the > future, or should I do both? > > -Toke Please always do source-only uploads in the future unless you are required to upload binary packages (e.g., having your package go through the NEW queue). By uploading only the source package, the Debian Buildd Network ( https://buildd.debian.org/) will catch your source package and build any necessary binary packages. Thanks, Boyuan
Bug#940165: speedtest-cli: Wrong upload speed
Dear Mantainer, I have checked and the same python script /usr/lib/python3/dist-packages/speedtest.py that comes with the package gives the correct result if run with python2 instead of the default python3. In my case: $ python3 /usr/lib/python3/dist-packages/speedtest.py --no-download Retrieving speedtest.net configuration... Testing from Vodafone Spain (79.108.127.65)... Retrieving speedtest.net server list... Selecting best server based on ping... Hosted by ServiHosting Networks (Madrid) [2.22 km]: 26.667 ms Skipping download test Testing upload speed.. Upload: 1.63 Mbit/s And with python2: $ python2 /usr/lib/python3/dist-packages/speedtest.py --no-download Retrieving speedtest.net configuration... Testing from Vodafone Spain (79.108.127.65)... Retrieving speedtest.net server list... Selecting best server based on ping... Hosted by ServiHosting Networks (Madrid) [2.22 km]: 27.954 ms Skipping download test Testing upload speed Upload: 91.16 Mbit/s So it seems to be some issue with the way it runs under the python3 interpreter. signature.asc Description: PGP signature
Bug#938009: pytest help needed
On Wed, 4 Dec 2019, Andreas Tille wrote:
Hi,
I try to prepare the latest git commit from upstream of python-pbcore[1].
Unfortunately the build time test fails with:
...
dh_auto_test
I: pybuild base:217: python3.8 setup.py test
running pytest
running egg_info
writing pbcore.egg-info/PKG-INFO
writing dependency_links to pbcore.egg-info/dependency_links.txt
writing entry points to pbcore.egg-info/entry_points.txt
writing requirements to pbcore.egg-info/requires.txt
writing top-level names to pbcore.egg-info/top_level.txt
reading manifest file 'pbcore.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
/usr/lib/python3.8/distutils/dist.py:274: UserWarning: Unknown distribution
option: 'test_requires'
warnings.warn(msg)
warning: no files found matching '*.txt'
writing manifest file 'pbcore.egg-info/SOURCES.txt'
running build_ext
ERROR: usage: setup.py [options] [file_or_dir] [file_or_dir] [...]
setup.py: error: unrecognized arguments: -n --dist=loadscope --cov=./pbcore
--cov-report=xml:coverage.xml
inifile: /build/python-pbcore-1.7.1+git20191121.7947eb7+dfsg/pytest.ini
rootdir: /build/python-pbcore-1.7.1+git20191121.7947eb7+dfsg
E: pybuild pybuild:341: test: plugin custom failed with: exit code=4: python3.8
setup.py test
dh_auto_test: pybuild --test --test-pytest -i python{version} -p "3.8 3.7"
returned exit code 13
...
Those arguments are mentioned in pytest.ini which reads:
[pytest]
markers =
pbtestdata: requires the 'PacBioTestData' package to be installed
internal_data: requires access to internal data on
'/pbi/dept/secondary/siv/testdata'
constools: requires 'pbindex', 'samtools' and 'pbmerge' in PATH
addopts =
-v -n auto --dist=loadscope --durations=20 --junitxml=nosetests.xml
--cov=./pbcore --cov-report=xml:coverage.xml
Any hints what options I should use instead?
I think you also need pytest plugins xdist and cov (Debian packages
python3-pytest-xdist and python3-pytest-cov).
Scott
Bug#946168: [Pkg-netmeasure-discuss] Bug#946168: flent: Please make a new source-only upload to allow testing migration
On 4 December 2019 19:09:01 CET, Boyuan Yang wrote: >Package: flent >Version: 1.3.2-1 >Severity: important >X-Debbugs-CC: t...@toke.dk > >Dear flent maintainer, > >Your previous uploads of package flent were not source-only uploads; as >a >result, the new verison of flent will not be able to migrate to Debian >Testing. The restriction on non-source-only upload went into effect >since the >release of Debian Buster; you may find the detailed announcement at >https://lists.debian.org/debian-devel-announce/2019/07/msg2.html . > >Please make another source-only upload. Details about how to make >source-only >uploads can be found at https://wiki.debian.org/SourceOnlyUpload . >Since you >have been granted the DM upload permission, you should be able to make >source- >only uploads by yourself. Can do. Does this mean I can skip the binary uploads completely in the future, or should I do both? -Toke
Bug#938009: pytest help needed
Hi,
I try to prepare the latest git commit from upstream of python-pbcore[1].
Unfortunately the build time test fails with:
...
dh_auto_test
I: pybuild base:217: python3.8 setup.py test
running pytest
running egg_info
writing pbcore.egg-info/PKG-INFO
writing dependency_links to pbcore.egg-info/dependency_links.txt
writing entry points to pbcore.egg-info/entry_points.txt
writing requirements to pbcore.egg-info/requires.txt
writing top-level names to pbcore.egg-info/top_level.txt
reading manifest file 'pbcore.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
/usr/lib/python3.8/distutils/dist.py:274: UserWarning: Unknown distribution
option: 'test_requires'
warnings.warn(msg)
warning: no files found matching '*.txt'
writing manifest file 'pbcore.egg-info/SOURCES.txt'
running build_ext
ERROR: usage: setup.py [options] [file_or_dir] [file_or_dir] [...]
setup.py: error: unrecognized arguments: -n --dist=loadscope --cov=./pbcore
--cov-report=xml:coverage.xml
inifile: /build/python-pbcore-1.7.1+git20191121.7947eb7+dfsg/pytest.ini
rootdir: /build/python-pbcore-1.7.1+git20191121.7947eb7+dfsg
E: pybuild pybuild:341: test: plugin custom failed with: exit code=4: python3.8
setup.py test
dh_auto_test: pybuild --test --test-pytest -i python{version} -p "3.8 3.7"
returned exit code 13
...
Those arguments are mentioned in pytest.ini which reads:
[pytest]
markers =
pbtestdata: requires the 'PacBioTestData' package to be installed
internal_data: requires access to internal data on
'/pbi/dept/secondary/siv/testdata'
constools: requires 'pbindex', 'samtools' and 'pbmerge' in PATH
addopts =
-v -n auto --dist=loadscope --durations=20 --junitxml=nosetests.xml
--cov=./pbcore --cov-report=xml:coverage.xml
Any hints what options I should use instead?
Kind regards
Andreas.
[1] https://salsa.debian.org/med-team/python-pbcore
--
http://fam-tille.de
Bug#946169: acpi-override: Please make another source-only upload to allow testing migration
Source: acpi-override Version: 0.1 Severity: important X-Debbugs-CC: casca...@debian.org Dear acpi-override maintainer, Your package just passed NEW queue and the only upload was not a source-only upload. After Buster cycle, all uploads must be source-only to be able to migrate to Testing. Please make another source-only upload to fix this issue. You may find more information about source-only upload on https://wiki.debian.org/SourceOnlyUpload . -- Best, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#945310:
Please close this bug. It was reported upstream: https://github.com/google/sanitizers/issues/1172#issuecomment-561409759
Bug#946160: hwloc: please round PCIe link values
On 04/12/2019 16.15, Brice Goglin wrote: > PCIe links (since Gen3) are encoded 128 data rate over 130 signal rate. > That's why you get 3.93 (truncated to 3.9). We decided to keep that > value exact in hwloc because the data/signal rate is different among > PCIe generations. We could round it up to 4 in the lstopo output, but I > am not sure where to start (PCIe Gen4 16x is 31.5GB/s instead of 32 and > Gen5 will be 63 instead of 64, those are harder to round up). Thanks for the detailed explanation! How about displaying the PCIe generation and number of links? -- Laurent.
Bug#941198: In support of mandatory unit files
Hi, chiming in as I've been pointed to this bug: I agree with Ansgar in that adding unit files does not hurt sysvinit support in the least, provided we still get to ignore them. I'd even be in favour of making them mandatory (i.e. upgrading the lintian warning to an error), and I don't see how the GR outcome would affect the question of whether we want to ship unit files in packages, so I'd be fine with going ahead with this change even while the GR is still running. As long as we support sysv-rc, init scripts will have to remain mandatory as well, though. IMO, an ideal outcome would be that systemd can completely ignore any init scripts from Debian packages, i.e. the compatibility generator, if installed, would only have to generate units for init scripts that didn't come from a package, and default installations would not include this generator. The same should be done for cron files vs timer units -- ideally, we'd get to a state where cron files can be completely ignored by systemd because it is a bug to not have a timer unit with the same settings. That would allow systemd users to get rid of the spurious wakeups as well, which I'd consider a major win. Simon
Bug#946168: flent: Please make a new source-only upload to allow testing migration
Package: flent Version: 1.3.2-1 Severity: important X-Debbugs-CC: t...@toke.dk Dear flent maintainer, Your previous uploads of package flent were not source-only uploads; as a result, the new verison of flent will not be able to migrate to Debian Testing. The restriction on non-source-only upload went into effect since the release of Debian Buster; you may find the detailed announcement at https://lists.debian.org/debian-devel-announce/2019/07/msg2.html . Please make another source-only upload. Details about how to make source-only uploads can be found at https://wiki.debian.org/SourceOnlyUpload . Since you have been granted the DM upload permission, you should be able to make source- only uploads by yourself. Please let me know if there are any questions or issues. -- Regards, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#946131: Apparmor breaks Send -> Email depending on settings
severity 946131 minor tag 946131 + wontfix thanks Hi, On Tue, Dec 03, 2019 at 11:09:20PM -0500, Anthony DeRobertis wrote: > Attempting to use any of the email options under File->Send results in > (in the terminal I started LibreOffice from, just silently doing nothing > as far as the GUI is concerned): > > /usr/lib/libreoffice/program/senddoc: line 62: /usr/bin/file: Permission > denied > /usr/lib/libreoffice/program/senddoc: line 70: /usr/bin/thunderbird: > Permission denied > > This is because I have Thunderbird selected in Options→Internet→Email, > which has a nice 'Browse...' button to select an arbitrary program. That > isn't really compatible with the AppArmor profile. (When I set it to > sensible-lomua instead of /usr/bin/thunderbird it worked, still using Exactly. Use that. > thunderbird, but through xdg-email instead, I presume.) It's the default, yes. case `basename "$MAILER"` in sensible-lomua) if [ -x /usr/bin/xdg-email ] ; then MAILER=/usr/bin/xdg-email elif [ -n "$KDE_FULL_SESSION" -a -x /usr/bin/kde-open ] \ || [ -x /usr/bin/gnome-open ] \ || [ -x /usr/bin/xdg-open ]; then # use an undefined mailer, to trigger the default handling MAILER=undefined elif [ -n "$GNOME_DESKTOP_SESSION_ID" -a -x /usr/bin/evolution ]; then MAILER=/usr/bin/evolution elif [ -n "$KDE_FULL_SESSION" -a -x /usr/bin/kmail ]; then MAILER=/usr/bin/kmail elif [ -x /usr/bin/evolution ]; then # default MAILER=/usr/bin/evolution elif [ -x /usr/bin/icedove ]; then # fallback MAILER=/usr/bin/icedove elif [ -x /usr/bin/thunderbird ]; then # fallback MAILER=/usr/bin/thunderbird fi ;; esac > I'm not sure how to fix this other than add a bunch of possible email > programs to the AppArmor program and a warning to the settings box that > if you pick a weird one, you'll need to edit the AppArmor profile. Not And I am definitely not going to do that. > ideal, and AFAIK you need root to edit the profile. Exactly. Regards, Rene
Bug#945962: libgl1: still uses Priority: extra
On 4.12.2019 19.23, Thorsten Glaser wrote: > Timo Aaltonen dixit: > >> That was done over two years ago in 1.0.0-1, so you are looking at the >> wrong package? Same thing with the other bug. > > No, definitely checked the two packages. > > Did you remember to request ftpmasters to change Priority > in the override file after you changed them in the package? > ftpmasters determine Section and Priority in the archive, > not the packages themselves. No, I didn't change the package myself back then, and in any case, it's not a package bug anymore. -- t
Bug#946167: audacity: Track volume and panning slider's pop-up invisible
Package: audacity Version: 2.2.2-1+b1 Severity: normal Dear Maintainer, When I try to adjust the volume or panning of a track, the pop-up that shows the amount is just one pixel high and thus unreadable. So I can't make multitrack songs any more, which makes me sad. I've made a lot of music on Audacity, so I must thank you for your wonderful work. -- System Information: Debian Release: 10.2 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages audacity depends on: ii audacity-data 2.2.2-1 ii libasound2 1.1.8-1 ii libavcodec-extra58 [libavcodec58] 7:4.1.4-1~deb10u1 ii libavformat58 7:4.1.4-1~deb10u1 ii libavutil567:4.1.4-1~deb10u1 ii libc6 2.28-10 ii libexpat1 2.2.6-2+deb10u1 ii libflac++6v5 1.3.2-3 ii libflac8 1.3.2-3 ii libgcc11:8.3.0-6 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libglib2.0-0 2.58.3-2+deb10u2 ii libgtk2.0-02.24.32-3 ii libid3tag0 0.15.1b-14 ii liblilv-0-00.24.2~dfsg0-2 ii libmad00.15.1b-10 ii libmp3lame03.100-2+b1 ii libogg01.3.2-1+b1 ii libportaudio2 19.6.0-1 ii libportsmf00.1~svn20101010-5 ii libsndfile11.0.28-6 ii libsoundtouch1 2.1.2+ds1-1 ii libsoxr0 0.1.2-3 ii libstdc++6 8.3.0-6 ii libsuil-0-00.10.0~dfsg0-1 ii libtwolame00.3.13-4 ii libvamp-hostsdk3v5 2.7.1~repack0-1 ii libvorbis0a1.3.6-2 ii libvorbisenc2 1.3.6-2 ii libvorbisfile3 1.3.6-2 ii libwxbase3.0-0v5 3.0.4+dfsg-8 ii libwxgtk3.0-0v53.0.4+dfsg-8 audacity recommends no packages. Versions of packages audacity suggests: ii calf-ladspa [ladspa-plugin] 1.1.3-8.1 ii caps [ladspa-plugin] 0.9.26-1 ii cmt [ladspa-plugin] 1.16-2 ii swh-plugins [ladspa-plugin] 0.4.17-2 ii tap-plugins [ladspa-plugin] 1.0.0-1 -- no debconf information
Bug#945962: libgl1: still uses Priority: extra
Timo Aaltonen dixit: >That was done over two years ago in 1.0.0-1, so you are looking at the >wrong package? Same thing with the other bug. No, definitely checked the two packages. Did you remember to request ftpmasters to change Priority in the override file after you changed them in the package? ftpmasters determine Section and Priority in the archive, not the packages themselves. bye, //mirabilos -- Beware of ritual lest you forget the meaning behind it. yeah but it means if you really care about something, don't ritualise it, or you will lose it. don't fetishise it, don't obsess. or you'll forget why you love it in the first place.
Bug#944242: Test issues with BioPython 1.75
Yes, ignore that one please. That test has since been disabled (and replaced with a more robust one). We eventually traced test_chapter_align_line_02819 failing on 32 bit systems with a different overflow error: https://github.com/biopython/biopython/pull/2297 Thanks, Peter On Wed, Dec 4, 2019 at 4:22 PM Andreas Tille wrote: > > On Wed, Dec 04, 2019 at 01:55:26PM +, Peter Cock wrote: > > Good. If you are still missing Tests/Fasta/flowers.pro.gz that's odd, > > since it was in the official tar ball: > > > > https://files.pythonhosted.org/packages/33/55/becf2b99556588d22b542f3412990bfc79b674e198d9bc58f7bbc333439e/biopython-1.75.tar.gz > > Arghh again. The test script is unzipping all files before running the > test since in the Debian doc dir most files are gzipped. After gzipping > it again this test is fine. > > So the only remaining issue is: > > == > ERROR: test_doctests (test_Tutorial.TutorialTestCase) > Run tutorial doctests. > -- > Traceback (most recent call last): > File "/tmp/autopkgtest.hiPio2/autopkgtest_tmp/Tests/test_Tutorial.py", line > 260, in test_doctests > (len(failures), ", ".join(failures))) > ValueError: 1 Tutorial doctests failed: test_chapter_align_line_02819 > > -- > Ran 194 tests in 204.479 seconds > > > and I think we agreed that I'll ignore this test. > > Kind regards > > Andreas. > > -- > http://fam-tille.de
Bug#945943: exim4: FTBFS on hurd-i386: "operating system GNU is not supported"
Control: tags -1 + patch fixed-upstream
Hello,
Here are the patches which were applied upstream.
Samuel
commit b30930a554edd087932dbff2d4d32f340de28ed1
Author: Heiko Schlittermann (HS12-RIPE)
Date: Tue Dec 3 07:23:25 2019 +0100
Build: Enable *GNU (Hurd) Bug 2476
diff --git a/src/OS/Makefile-Base b/src/OS/Makefile-Base
index f8c6ebb53..9ecde1d3e 100644
--- a/src/OS/Makefile-Base
+++ b/src/OS/Makefile-Base
@@ -97,6 +97,7 @@ Makefile: ../OS/Makefile-Base ../OS/Makefile-Default \
os.h: $(SCRIPTS)/Configure-os.h \
$(O)/os.h-FreeBSD \
+ $(O)/os.h-GNU \
$(O)/os.h-Linux \
$(O)/os.h-OpenBSD \
$(O)/os.h-SunOS5
@@ -113,6 +114,7 @@ os.h: $(SCRIPTS)/Configure-os.h \
os.c: ../src/os.c \
$(SCRIPTS)/Configure-os.c \
+ $(O)/os.c-GNU \
$(O)/os.c-Linux
$(SHELL) $(SCRIPTS)/Configure-os.c
diff --git a/src/OS/Makefile-GNU b/src/OS/Makefile-GNU
new file mode 100644
index 0..e46434187
--- /dev/null
+++ b/src/OS/Makefile-GNU
@@ -0,0 +1,29 @@
+# Exim: OS-specific make file for GNU and variants.
+
+HAVE_ICONV=yes
+
+BASENAME_COMMAND=look_for_it
+CHOWN_COMMAND=look_for_it
+CHGRP_COMMAND=look_for_it
+CHMOD_COMMAND=look_for_it
+
+CFLAGS ?= -O -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
+
+DBMLIB = -ldb
+USE_DB = yes
+
+LIBS = -lnsl -lcrypt -lm
+LIBRESOLV = -lresolv
+
+X11=/usr/X11R6
+XINCLUDE=-I$(X11)/include
+XLFLAGS=-L$(X11)/lib
+X11_LD_LIB=$(X11)/lib
+
+EXIWHAT_PS_ARG=ax
+EXIWHAT_EGREP_ARG='/exim( |$$)'
+EXIWHAT_MULTIKILL_CMD=killall
+EXIWHAT_MULTIKILL_ARG=exim
+EXIWHAT_KILL_SIGNAL=-USR1
+
+# End
diff --git a/src/OS/os.c-GNU b/src/OS/os.c-GNU
new file mode 100644
index 0..e5d6ff66c
--- /dev/null
+++ b/src/OS/os.c-GNU
@@ -0,0 +1,55 @@
+/*
+* Exim - an Internet mail transport agent*
+*/
+
+/* See the file NOTICE for conditions of use and distribution. */
+
+/* GNU-specific code. This is concatenated onto the generic src/os.c file.
+GNU/Hurd has approximately the same way to determine the load average as NeXT,
+so a variant of this could also be in the generic os.c file. See the GNU EMacs
+getloadavg.c file, from which this snippet was derived. getloadavg.c from Emacs
+is copyrighted by the FSF under the terms of the GPLv2 or any later version.
+Changes are hereby placed under the same license, as requested by the GPL. */
+
+#ifndef OS_LOAD_AVERAGE
+#define OS_LOAD_AVERAGE
+
+#include
+
+static processor_set_t default_set;
+static int getloadavg_initialized;
+
+int
+os_getloadavg (void)
+{
+host_t host;
+struct processor_set_basic_info info;
+unsigned info_count;
+
+if (!getloadavg_initialized)
+ {
+ if (processor_set_default (mach_host_self(), _set) == KERN_SUCCESS)
+getloadavg_initialized = 1;
+ }
+
+if (getloadavg_initialized)
+ {
+ info_count = PROCESSOR_SET_BASIC_INFO_COUNT;
+ if (processor_set_info(default_set, PROCESSOR_SET_BASIC_INFO, ,
+ (processor_set_info_t), _count) != KERN_SUCCESS)
+getloadavg_initialized = 0;
+ else
+{
+#if LOAD_SCALE == 1000
+return info.load_average;
+#else
+return (int) (((double) info.load_average * 1000) / LOAD_SCALE));
+#endif
+}
+ }
+
+return -1;
+}
+#endif /* OS_LOAD_AVERAGE */
+
+/* End of os.c-GNU */
diff --git a/src/OS/os.h-GNU b/src/OS/os.h-GNU
new file mode 100644
index 0..44993163d
--- /dev/null
+++ b/src/OS/os.h-GNU
@@ -0,0 +1,23 @@
+/* Exim: OS-specific C header file for GNU/Hurd */
+
+#define CRYPT_H
+#define GLIBC_IP_OPTIONS
+#define HAVE_BSD_GETLOADAVG
+#define HAVE_MMAP
+#define HAVE_SYS_VFS_H
+#define NO_IP_VAR_H
+#define SIG_IGN_WORKS
+#define SIOCGIFCONF_GIVES_ADDR
+
+#define F_FREESP O_TRUNC
+typedef struct flock flock_t;
+
+#define os_strsignal strsignal
+#define OS_STRSIGNAL
+
+/* Hurd-specific bits below */
+
+/* default is non-const */
+#define ICONV_ARG2_TYPE const char **
+
+/* End */
diff --git a/src/OS/unsupported/Makefile-GNU b/src/OS/unsupported/Makefile-GNU
deleted file mode 100644
index e46434187..0
--- a/src/OS/unsupported/Makefile-GNU
+++ /dev/null
@@ -1,29 +0,0 @@
-# Exim: OS-specific make file for GNU and variants.
-
-HAVE_ICONV=yes
-
-BASENAME_COMMAND=look_for_it
-CHOWN_COMMAND=look_for_it
-CHGRP_COMMAND=look_for_it
-CHMOD_COMMAND=look_for_it
-
-CFLAGS ?= -O -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
-
-DBMLIB = -ldb
-USE_DB = yes
-
-LIBS = -lnsl -lcrypt -lm
-LIBRESOLV = -lresolv
-
-X11=/usr/X11R6
-XINCLUDE=-I$(X11)/include
-XLFLAGS=-L$(X11)/lib
-X11_LD_LIB=$(X11)/lib
-
-EXIWHAT_PS_ARG=ax
-EXIWHAT_EGREP_ARG='/exim( |$$)'
-EXIWHAT_MULTIKILL_CMD=killall
-EXIWHAT_MULTIKILL_ARG=exim
-EXIWHAT_KILL_SIGNAL=-USR1
-
-# End
diff --git a/src/OS/unsupported/os.c-GNU b/src/OS/unsupported/os.c-GNU
deleted file mode 100644
index e5d6ff66c..0
--- a/src/OS/unsupported/os.c-GNU
+++ /dev/null
@@ -1,55 +0,0 @@
Bug#945411: pyfai fails tests with Python 3.8
Package: pyfai
Version: 0.18.0+dfsg1-3
Followup-For: Bug #945411
"pocl error: lt_dlopen("(null)") or lt_dlsym() failed with 'can't close
resident module'"
That suggests pocl is not yet built against python3.8
Bug#945411: pyfai: 1
Package: pyfai Followup-For: Bug #945411 On the other hand, python3-pyopencl is indeed built against python3.8. So need to dig deeper.
Bug#946166: lightdm-gtk-greeter segfaults on hostname changes
Package: lightdm-gtk-greeter
Version: 2.0.6-1
This is a long-standing bug (see, e.g.,
https://bugs.launchpad.net/ubuntu/+source/lightdm-gtk-greeter/+bug/1422794
https://bugs.launchpad.net/ubuntu/+source/lightdm-gtk-greeter/+bug/1677058
https://bugzilla.redhat.com/show_bug.cgi?id=1399811
https://bugzilla.redhat.com/show_bug.cgi?id=1394472
) but still unfixed in buster (and upstream, I believe).
The symptom is a
lightdm-gtk-gre[920]: segfault at 10 ip 7f011974ecc0 sp 7ffe6f799768
error 4 in licairo.so.2.11600.0[7f01196eb000+cc000]
on the first login attempt after boot; the user ends up having to authenticate
twice. seat0-greeter.log mentions
Invalid MIT-MAGIC-COOKIE-1 key
[Background] Failed to create root pixmap
in that order. Setting a static hostname for the machine suppresses the problem.
As far as I can tell, the immediate cause for the segfault is a missing check
for src/greeterbackground.c:create_root_surface() returning NULL (which it does
here, as evidenced by the "Failed to create root pixmap" message). One could add
if (!surface) return;
in the obvious place in greeter_background_save_xroot() to avoid segfaulting at
this point. I wonder if one shouldn't also emit a more explicit hint ("has the
hostname changed?" or "see ") in the log when this happens.
This still won't address the Xauthority issue, though.
/var/run/lightdm/root/:0, created by lightdm and not by the greeter, apparently
contains a cookie for /unix:0 which is not being updated when the
hostname changes (e.g., due to DHCP activity after lightdm starts up). I'm
filing this report against the greeter due to the segfault, but feel free to
reassign/clone it to lightdm if need be.
I guess the reason this doesn't bite more people is that a static hostname is
usually set at installation time. The machine on which I had this issue was
installed from USB media, with the network connection non-functional during
installation (due to a Thunderbolt support bug in the 4.19 kernel, fixed in
5.3.9 and hopefully in 4.19.82; but I digress) and ended up using localhost as
the boot-time hostname.
Bug#946165: nmu: usb-modeswitch_2.5.2+repack0 | openocd_0.10.0-6
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Hello, the micro-transition for jimtcl (SONAME bump from 0.77 to 0.79) is in progress; two packages need to be rebuilt: https://release.debian.org/transitions/html/auto-jimtcl.html nmu usb-modeswitch_2.5.2+repack0-2 . ANY . unstable . -m "Rebuild against libjim0.79" nmu openocd_0.10.0-6 . ANY . unstable . -m "Rebuild against libjim0.79" I have manually tested the two builds on amd64. Many thanks for your work; OdyX -- System Information: Debian Release: bullseye/sid APT prefers buildd-unstable APT policy: (990, 'buildd-unstable'), (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (100, 'experimental'), (1, 'experimental-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.3.0-2-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.UTF-8 (charmap=UTF-8), LANGUAGE=fr_CH:fr (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#943042: gitso: Python2 removal in sid/bullseye
Hi Scott, > The package doesn't look all that complicated. I can take a stab at trying > to port it to Python 3. If I get it working, perhaps I can ask you to test > it? that would be awesome! I can definitely do the testing. Florian
Bug#944242: Test issues with BioPython 1.75
On Wed, Dec 04, 2019 at 01:55:26PM +, Peter Cock wrote: > Good. If you are still missing Tests/Fasta/flowers.pro.gz that's odd, > since it was in the official tar ball: > > https://files.pythonhosted.org/packages/33/55/becf2b99556588d22b542f3412990bfc79b674e198d9bc58f7bbc333439e/biopython-1.75.tar.gz Arghh again. The test script is unzipping all files before running the test since in the Debian doc dir most files are gzipped. After gzipping it again this test is fine. So the only remaining issue is: == ERROR: test_doctests (test_Tutorial.TutorialTestCase) Run tutorial doctests. -- Traceback (most recent call last): File "/tmp/autopkgtest.hiPio2/autopkgtest_tmp/Tests/test_Tutorial.py", line 260, in test_doctests (len(failures), ", ".join(failures))) ValueError: 1 Tutorial doctests failed: test_chapter_align_line_02819 -- Ran 194 tests in 204.479 seconds and I think we agreed that I'll ignore this test. Kind regards Andreas. -- http://fam-tille.de
Bug#943042: gitso: Python2 removal in sid/bullseye
On Wed, 4 Dec 2019, Florian Schlichting wrote: Do you have any plans to port gitso to Python 3? If not, I will probably just convert this to an RM request as it seems gitso is unmaintained upstream for many years. I have in fact started to look into porting gitso to Python 3, but haven't spent enough time on it to be able to say how long it will take or if it will be doable with my (very limited) python skills. However I still use gitso occasionally and would love to keep it around. Do you have a time frame until such a project would have to be completed? I was of the impression that I had until the bullseye release, but the Python 2 removal seems to be progressing with a lot of energy lately... Hey Florian, Yes, the target for Python 2 removal is bullseye release, but since the removal is going to take a long time, work is progressing steadily. Since gitso is a 'leaf' Python 2 package, that's why I poked this bug report. The package doesn't look all that complicated. I can take a stab at trying to port it to Python 3. If I get it working, perhaps I can ask you to test it? Scott
Bug#946164: Build-Depends is missing
Hi, On Wed, 4 Dec 2019 at 16:39, Sebastien Bacher wrote: > The package fails to build because it wants to install > librust-gumdrop-derive-0.6+default-dev which doesn't exist currently in > Debian > (there is also a new 0.8 upstream version available for packaging) It’s a known issue, and I’m working on getting it fixed, but unfortunately it’s a lot of work and I don’t know how soon it is going to be done. -- Cheers, Andrej
Bug#943042: gitso: Python2 removal in sid/bullseye
Hi Scott, > Do you have any plans to port gitso to Python 3? > > If not, I will probably just convert this to an RM request as it seems gitso > is unmaintained upstream for many years. I have in fact started to look into porting gitso to Python 3, but haven't spent enough time on it to be able to say how long it will take or if it will be doable with my (very limited) python skills. However I still use gitso occasionally and would love to keep it around. Do you have a time frame until such a project would have to be completed? I was of the impression that I had until the bullseye release, but the Python 2 removal seems to be progressing with a lot of energy lately... Florian
Bug#819341: Updated patch
Hi Stéphane, > Binary packages have a cost. They are useful when [...] Ok, that's your domain, I don't know nothing about the policies here. > My remark was not related to the python version. I was just wondering if > unison-fsmonitor could be provided by existing packages instead. Sure. My primary interest is just that it is installable somehow, so that we do not have to continue to build our own at some point. I was just taking what John Lenton had already been offering and tweaking it. Anyway, let me know if I can be of further help. Thanks, benny
Bug#946164: Build-Depends is missing
Package: resvg Version: 0.5.0-2 The package fails to build because it wants to install librust-gumdrop-derive-0.6+default-dev which doesn't exist currently in Debian (there is also a new 0.8 upstream version available for packaging)
Bug#946013: ITS: rss2email
gustavo panizzo wrote: > I intend to NMU, co-maintain, or salvage rss2email if necessary. No problem from my side, please go ahead. -- .''`.Work like you don't need the money : :' : Love like you've never been hurt `. `' Dance like nobody's watching `- Proudly running Debian GNU/Linux
Bug#946163: ITP: liblist-someutils-xs-perl -- module providing XS implementation for List::SomeUtils
Package: wnpp Owner: Nick Morrott Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org * Package name: liblist-someutils-xs-perl Version : 0.58 Upstream Author : Dave Rolsky * URL : https://metacpan.org/release/List-SomeUtils-XS * License : Artistic-2.0 Programming Lang: Perl Description : module providing XS implementation for List::SomeUtils List::SomeUtils::XS provides a fast, compiled XS implementation of key functionality found in List::SomeUtils. There are no user-facing parts here; please install the liblist-someutils-perl package for the user-facing module and API details. The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.
Bug#946160: hwloc: please round PCIe link values
Le 04/12/2019 à 15:30, Laurent Bonnaud a écrit : > Package: hwloc > Version: 2.1.0+dfsg-2 > Severity: normal > > > Dear Maintainer, > > my system has a NVMe SSD. It is displayed correctly in lstopo. However the > PCIe link has a value of "3.9" (see attached file) whereas it should probably > be "4.0". Hello PCIe links (since Gen3) are encoded 128 data rate over 130 signal rate. That's why you get 3.93 (truncated to 3.9). We decided to keep that value exact in hwloc because the data/signal rate is different among PCIe generations. We could round it up to 4 in the lstopo output, but I am not sure where to start (PCIe Gen4 16x is 31.5GB/s instead of 32 and Gen5 will be 63 instead of 64, those are harder to round up). Brice
Bug#946061: landslide: FTBFS; Package should be removed instead of being made into compat pkg
Hi, On Wed, 4 Dec 2019 at 16:03, Boyuan Yang wrote: > I have no idea why the package would have to go through NEW. Removing package > does not need to go throught NEW and it's much faster (usually needs only 1 or > 2 days). No, I’m talking about a compat package in darkslide. I still want it to be a separate binary package, which means I’d have to add it to darkslide, which I don’t (yet) want to do. -- Cheers, Andrej
Bug#946061: landslide: FTBFS; Package should be removed instead of being made into compat pkg
在 2019-12-04三的 15:00 +0100，Andrej Shadura写道： > Hi, > > On Tue, 3 Dec 2019 at 15:54, Boyuan Yang wrote: > > Currently package landslide FTBFS in Sid. I noticed that it was just made > > into > > a compatibility package with nothing inside. This is unnecessary, plus > > that > > current setup actually fails to build from source. > > > > Since python-landslide has no reverse dependency and no reverse build- > > dependency, please consider removing it from the Debian archive instead of > > making a compatibility package. Please let me know if that works for you. > > I’d like to avoid going through NEW needlessly. I will convert it at > some point in future, but now just now yet. Hi Andrej, I have no idea why the package would have to go through NEW. Removing package does not need to go throught NEW and it's much faster (usually needs only 1 or 2 days). Or are you talking about uploading python3-landslide? In this case it should be pushed into the NEW queue sooner rather than later since the NEW queue is always being processed slowly. We can make uploads onto Experimental with the new package and let it stay in the NEW queue. This is harmless since the Sid uploads are not affected by experimental/NEW at all. -- Thanks, Boyuan Yang
Bug#945962: libgl1: still uses Priority: extra
On 1.12.2019 21.37, Thorsten Glaser wrote: > Package: libgl1 > Version: 1.1.0-1+b1 > Severity: normal > > Please change Priority extra to optional, in accordance with latest > Policy, as to not make packages depending on libgl1 but of a conforming > priority violate Policy’s requirement of not depending on packages with > a lower priority. That was done over two years ago in 1.0.0-1, so you are looking at the wrong package? Same thing with the other bug. -- t
Bug#946162: Builds fails on some architectures due to cpp symbols
Package: libofx Version: 1:0.9.15-2 The build fails on some (Ubuntu) architecture due to cpp symbols, the attached patch mark some extra ones that fixes the build Build log example https://launchpadlibrarian.net/449705134/buildlog_ubuntu-focal-ppc64el.libofx_1%3A0.9.15-2_BUILDING.txt.gz +#MISSING: 1:0.9.15-2# (c++|optional)"std::__cxx11::basic_string, std::allocator > std::operator+, std::allocator >(std::__cxx11::basic_string, std::allocator >&&, char const*)@Base" 0.9.14 +#MISSING: 1:0.9.15-2# (c++)"void std::__cxx11::basic_string, std::allocator >::_M_construct(char const*, char const*, std::forward_iterator_tag)@Base" 0.9.14 (c++)"void std::__cxx11::basic_string, std::allocator >::_M_construct(char*, char*, std::forward_iterator_tag)@Base" 0.9.14 dh_makeshlibs: failing due to earlier errors diff -Nru libofx-0.9.15/debian/changelog libofx-0.9.15/debian/changelog --- libofx-0.9.15/debian/changelog 2019-10-15 11:38:50.0 +0200 +++ libofx-0.9.15/debian/changelog 2019-12-04 15:48:20.0 +0100 @@ -1,3 +1,10 @@ +libofx (1:0.9.15-3) unstable; urgency=medium + + * debian/libofx7.symbols: +- flag extra cpp symbols as optional + + -- Sebastien Bacher Wed, 04 Dec 2019 15:12:39 +0100 + libofx (1:0.9.15-2) unstable; urgency=medium * Update symbols file. diff -Nru libofx-0.9.15/debian/libofx7.symbols libofx-0.9.15/debian/libofx7.symbols --- libofx-0.9.15/debian/libofx7.symbols2019-10-15 11:38:50.0 +0200 +++ libofx-0.9.15/debian/libofx7.symbols2019-12-04 15:39:27.0 +0100 @@ -1,9 +1,9 @@ libofx.so.7 #PACKAGE# #MINVER# * Build-Depends-Package: #PACKAGE# - (c++)"void std::__cxx11::basic_string, std::allocator >::_M_construct(char const*, char const*, std::forward_iterator_tag)@Base" 0.9.14 - (c++)"void std::__cxx11::basic_string, std::allocator >::_M_construct(char*, char*, std::forward_iterator_tag)@Base" 0.9.14 + (c++|optional)"void std::__cxx11::basic_string, std::allocator >::_M_construct(char const*, char const*, std::forward_iterator_tag)@Base" 0.9.14 + (c++|optional)"void std::__cxx11::basic_string, std::allocator >::_M_construct(char*, char*, std::forward_iterator_tag)@Base" 0.9.14 (c++|optional)"std::__cxx11::basic_string, std::allocator > std::operator+, std::allocator >(std::__cxx11::basic_string, std::allocator >&&, char const*)@Base" 0.9.14 - (c++)"std::__cxx11::basic_string, std::allocator > std::operator+, std::allocator >(char const*, std::__cxx11::basic_string, std::allocator > const&)@Base" 0.9.14 + (c++|optional)"std::__cxx11::basic_string, std::allocator > std::operator+, std::allocator >(char const*, std::__cxx11::basic_string, std::allocator > const&)@Base" 0.9.14 libofx_free_context@Base 0.9.14 libofx_get_file_format_description@Base 0.9.14 libofx_get_file_format_from_str@Base 0.9.14
Bug#946161: dia: CVE-2019-19451: Endless loop on filenames with invalid encoding can be used for denial-of-service
Package: dia Version: 0.97.3+git20160930-8.1 Severity: critical Tags: security upstream Justification: breaks the whole system Dear Maintainer, when GNOME Dia before 2019-11-27 is launched with a filename argument that is not a valid codepoint in the current encoding, it enters an endless loop, thus endlessly writing text to stdout. (The filename can be for a nonexistent file.) If this launch is from a thumbnailer service, this output will usually be written to disk via the system's logging facility (potentially with elevated privileges), thus filling up the disk and eventually rendering the system unusable. Further details are available in the upstream bugreport [1] and the CVE description [2]. Upstream (the GNOME Dia developers) has not tagged any official release versions since 2011 (0.97.2), so Debian currently ships a more recent state as 0.97.3+git20160930-8.2. The vulnerability was introduced after the release of 0.97.2, and is contained in all 0.97.3+* versions in Debian. Could you please package the current development version of Dia, or apply the (one-line) patch [3], to fix this vulnerability? Kind regards, Nils Steinger [1]: https://gitlab.gnome.org/GNOME/dia/issues/428 [2]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-19451 [3]: https://gitlab.gnome.org/GNOME/dia/commit/baa2df853f9fb770eedcf3d94c7f5becebc90bb9?merge_request_iid=50 -- System Information: Debian Release: 10.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (90, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-6-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dia depends on: ii dia-common 0.97.3+git20160930-8.1 ii libart-2.0-2 2.3.21-4 ii libatk1.0-0 2.30.0-2 ii libc62.28-10 ii libcairo21.16.0-4 ii libfontconfig1 2.13.1-2 ii libfreetype6 2.9.1-3+deb10u1 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libglib2.0-0 2.58.3-2+deb10u2 ii libgtk2.0-0 2.24.32-3 ii libpango-1.0-0 1.42.4-7~deb10u1 ii libpangocairo-1.0-0 1.42.4-7~deb10u1 ii libpangoft2-1.0-01.42.4-7~deb10u1 ii libpng16-16 1.6.36-6 ii libpython2.7 2.7.16-2+deb10u1 ii libxml2 2.9.4+dfsg1-7+b3 ii libxslt1.1 1.1.32-2.2~deb10u1 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages dia recommends: ii dia-shapes 0.6.0-3 ii gsfonts-x11 0.26 dia suggests no packages. -- no debconf information
Bug#946160: hwloc: please round PCIe link values
Package: hwloc Version: 2.1.0+dfsg-2 Severity: normal Dear Maintainer, my system has a NVMe SSD. It is displayed correctly in lstopo. However the PCIe link has a value of "3.9" (see attached file) whereas it should probably be "4.0". -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-trunk-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAG> Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages hwloc depends on: ii libc6 2.29-4 ii libcairo2 1.16.0-4 ii libhwloc15 2.1.0+dfsg-2 ii libtinfo6 6.1+20191019-1 ii libx11-62:1.6.8-1 hwloc recommends no packages. hwloc suggests no packages. -- no debconf information -- Laurent. lstopo.pdf Description: Adobe PDF document
Bug#946159: stretch-pu: package libxslt/1.1.29-2.1+deb9u2
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu
Hi
This update adresses CVE-2019-18197 as well for stretch (was alredy
done for buster in the last point release). Attaching the resulting
debdiff.
Regards,
Salvatore
diff -Nru libxslt-1.1.29/debian/changelog libxslt-1.1.29/debian/changelog
--- libxslt-1.1.29/debian/changelog 2019-08-24 14:04:13.0 +0200
+++ libxslt-1.1.29/debian/changelog 2019-12-04 15:41:16.0 +0100
@@ -1,3 +1,10 @@
+libxslt (1.1.29-2.1+deb9u2) stretch; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix dangling pointer in xsltCopyText (CVE-2019-18197) (Closes: #942646)
+
+ -- Salvatore Bonaccorso Wed, 04 Dec 2019 15:41:16 +0100
+
libxslt (1.1.29-2.1+deb9u1) stretch; urgency=medium
* Non-maintainer upload.
diff -Nru
libxslt-1.1.29/debian/patches/0012-Fix-dangling-pointer-in-xsltCopyText.patch
libxslt-1.1.29/debian/patches/0012-Fix-dangling-pointer-in-xsltCopyText.patch
---
libxslt-1.1.29/debian/patches/0012-Fix-dangling-pointer-in-xsltCopyText.patch
1970-01-01 01:00:00.0 +0100
+++
libxslt-1.1.29/debian/patches/0012-Fix-dangling-pointer-in-xsltCopyText.patch
2019-12-04 15:41:16.0 +0100
@@ -0,0 +1,35 @@
+From: Nick Wellnhofer
+Date: Sat, 17 Aug 2019 16:51:53 +0200
+Subject: Fix dangling pointer in xsltCopyText
+Origin:
https://gitlab.gnome.org/GNOME/libxslt/commit/2232473733b7313d67de8836ea3b29eec6e8e285
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2019-18197
+Bug-Debian: https://bugs.debian.org/942646
+Bug: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=15746
+Bug: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=15768
+Bug: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=15914
+
+xsltCopyText didn't reset ctxt->lasttext in some cases which could
+lead to various memory errors in relation with CDATA sections in input
+documents.
+
+Found by OSS-Fuzz.
+---
+ libxslt/transform.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/libxslt/transform.c b/libxslt/transform.c
+index 95ebd0732f95..d7ab0b6677cc 100644
+--- a/libxslt/transform.c
b/libxslt/transform.c
+@@ -1094,6 +1094,8 @@ xsltCopyText(xsltTransformContextPtr ctxt, xmlNodePtr
target,
+ if ((copy->content = xmlStrdup(cur->content)) == NULL)
+ return NULL;
+ }
++
++ ctxt->lasttext = NULL;
+ } else {
+ /*
+* normal processing. keep counters to extend the text node
+--
+2.20.1
+
diff -Nru libxslt-1.1.29/debian/patches/series
libxslt-1.1.29/debian/patches/series
--- libxslt-1.1.29/debian/patches/series2019-08-24 14:04:13.0
+0200
+++ libxslt-1.1.29/debian/patches/series2019-12-04 15:41:16.0
+0100
@@ -9,3 +9,4 @@
0009-Fix-security-framework-bypass.patch
0010-Fix-uninitialized-read-of-xsl-number-token.patch
0011-Fix-uninitialized-read-with-UTF-8-grouping-chars.patch
+0012-Fix-dangling-pointer-in-xsltCopyText.patch
Bug#819341: Updated patch
Le 03/12/2019 à 10:11, Benjamin Riefenstahl a écrit : >> Is there any practical benefit in adding a new binary package? > > What is the problem with binary packages? Binary packages have a cost. They are useful when they have additional dependencies (that are optional for the main package) or when better sharing is achieved (typical cases: -doc, or -common packages). Maybe other cases. > If you are asking, why not the python version instead, I already said My remark was not related to the python version. I was just wondering if unison-fsmonitor could be provided by existing packages instead. Since this needs to go through the NEW queue, I will take the opportunity to create a package co-installable with the one in stable, as Vincent suggested. Cheers, -- Stéphane
Bug#945534: virtualbox-source: Module FTBFS on Linux 5.4 due to set_pages_x
close 945534 6.0.14-dfsg-4 thanks Thanks for releasing 6.0.14-dfsg-4 with the patch for 5.4. Works great for me. Best, Kevin
Bug#946017: gvfs: FTBFS on hurd-i386: Used configuration depends on unavailable libraries
Hi Paul, On Mon, Dec 02, 2019 at 11:27:07PM +0100, Paul Sonnenschein wrote: > Source: gvfs [...] > with the default build options, gvfs requires systemd, fuse and other > libraries to build successfully. [...] Patches are very easily missed by the Gnome maintainers among all the noise. Could you please push your patch as a merge-request on salsa.debian.org instead? This should help increase its visibility, make review easier (and allow potential CI tests), and make the merge process smoother. Please use gbp-dch style meta-tags in your commit message (i.e. Closes: #...) so a correct debian/changelog entry will automatically be generated later. >From my quick glance your patch looks sane and safe to me. Regards, Andreas Henriksson
Bug#873651: O: flask-openid -- OpenID support for Flask applications
Hi Sandro, I think python-flask-openid is ready [1]. Please, could you sponsor it? Thanks! [1] https://salsa.debian.org/python-team/modules/python-flask-openid Cheers, Arias Emmanuel @eamanu http://eamanu.com El jue., 28 de nov. de 2019 a la(s) 08:57, Emmanuel Arias (emmanuelaria...@gmail.com) escribió: > > Hi Sandro, > > I will work on that. > > Cheers > > El mié., 27 de nov. de 2019 23:15, Sandro Tosi escribió: >> >> On Sat, 2 Nov 2019 20:51:44 -0300 Emmanuel Arias >> wrote: >> > Hi! >> > >> > I am interest to adopt it :-) >> >> did you get to it? please drop its py2 package when you do so, hopefully soon
Bug#946061: landslide: FTBFS; Package should be removed instead of being made into compat pkg
Hi, On Tue, 3 Dec 2019 at 15:54, Boyuan Yang wrote: > Currently package landslide FTBFS in Sid. I noticed that it was just made into > a compatibility package with nothing inside. This is unnecessary, plus that > current setup actually fails to build from source. > > Since python-landslide has no reverse dependency and no reverse build- > dependency, please consider removing it from the Debian archive instead of > making a compatibility package. Please let me know if that works for you. I’d like to avoid going through NEW needlessly. I will convert it at some point in future, but now just now yet. -- Cheers, Andrej
Bug#944242: Test issues with BioPython 1.75
Good. If you are still missing Tests/Fasta/flowers.pro.gz that's odd,
since it was in the official tar ball:
https://files.pythonhosted.org/packages/33/55/becf2b99556588d22b542f3412990bfc79b674e198d9bc58f7bbc333439e/biopython-1.75.tar.gz
Peter
On Tue, Dec 3, 2019 at 9:13 PM Andreas Tille wrote:
>
> Hi Peter,
>
> On Mon, Dec 02, 2019 at 03:42:21PM +, Peter Cock wrote:
> > This was included in Biopython 1.74 and 1.75, yet your copy of
> > Tests/test_psw.py
> > would seem to date from Biopython 1.73 or older.
> >
> > I suspect an old cached copy of the test folder is largely to blame?
>
> Arghhh, sorry for wasting your time. The test examples are in
> python-biopython-doc package which I forgot to update on my local
> machine. I just get:
>
> ==
> ERROR: test_gzip_fasta (test_SeqIO.TestZipped)
> Testing FASTA with gzip.
> --
> Traceback (most recent call last):
> File "/tmp/autopkgtest.vFO6HI/autopkgtest_tmp/Tests/test_SeqIO.py", line
> 156, in test_gzip_fasta
> with gzip.open("Fasta/flowers.pro.gz", mode) as handle:
> File "/usr/lib/python2.7/gzip.py", line 34, in open
> return GzipFile(filename, mode, compresslevel)
> File "/usr/lib/python2.7/gzip.py", line 94, in __init__
> fileobj = self.myfileobj = __builtin__.open(filename, mode or 'rb')
> IOError: [Errno 2] No such file or directory: 'Fasta/flowers.pro.gz'
>
> ==
>
>
> (now with the real data).
>
> Kind regards
>
> Andreas.
>
> --
> http://fam-tille.de
Bug#946158: lightdm-gtk-greeter or libcairo2 segfault immediately after submitting password, unlocking session
package: lightdm-gtk-greeter version: 2.0.6-1 lightdm-gtk-greeter or libcairo2 segfault immediately after submitting password, unlocking session. (i do not understand the segfault message). part of syslog: Dec 4 14:28:08 localhost lightdm[9304]: Error getting user list from org.freedesktop.Accounts: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Accounts was not provided by any .service files Dec 4 14:28:08 localhost kernel: [ 5707.165413] lightdm-gtk-gre[9162]: segfault at 8 ip b73a92e4 sp bfa6f59c error 4 in libcairo.so.2.11600.0[b733d000+dd000] Dec 4 14:28:08 localhost kernel: [ 5707.165431] Code: 51 14 89 54 24 04 e9 1b e5 fa ff 8d 76 00 31 c0 c3 8d 74 26 00 90 89 d0 c3 8d b4 26 00 00 00 00 8d b6 00 00 00 00 8b 44 24 04 <8b> 40 08 c3 8d b4 26 00 00 00 00 90 8b 44 24 04 8b 40 0c c3 8d b4 Dec 4 14:28:08 localhost systemd[1]: session-c2.scope: Succeeded. Dec 4 14:28:18 localhost systemd[1]: Stopping User Manager for UID 115... should i report a bug for a single segfault? i do not know how to reproduce it. i think it may be for hdd surface errors. if so, it is not really a bug. i think maybe somebody can find appropriate source code, check it, and find a bug. so i report. using debian 10 with xfce.
Bug#946149: please update build-deps on iptables
Am 04.12.19 um 14:28 schrieb Michael Biebl: > Btw, if you move those headers, don't forget to add a Breaks/Replaces: > libiptc-dev to libip4tc-dev. This seems to be missing currently. A versioned Breaks/Replaces, obviously... -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
