Bug#997919: pipewire: Automatich profile selection for bluetooth headsets fails since 0.3.39
Hi Bastian, Le mer. 27 oct. 2021 à 08:33, Bastian Venthur a écrit : > > since the upgrade from pipewire 0.3.38 to 0.3.39 the automatic profile > selection for my bluetooth headset does not work anymore. Since this upgrade > also included the change from pipewire-media-session to wireplumber it might > rather be related to that package. I noticed the > /etc/pipewire/media-session.d/bluez-monitor.conf is not present but I'm not > sure if it was, when pipewire-media-session was still installed, though. > > So what is the problem? The headset has two modes: A2DP which you use when you > listen-only and the HSP/HFP mode which you need if you want to use the > headphone's microphone. Pipewire was able to switch back and forth between the > two modes automatically depending on whether a microphone input was requested > by an application, however since the last update it does not anymore and I > have to switch manually. > Could you check if you have both wireplumber and libspa-0.2-bluetooth installed on your system? bluez-hardware.conf has moved from pipewire-media-session to libspa-0.2-bluetooth in 0.3.37-1 Best, Dylan
Bug#995116: 0.3.39-1 No soundcard anymore
Le lun. 25 oct. 2021 à 13:15, Thomas Renard a écrit : > > > I tested 0.3.39 and there no soundcard is found anymore. With pw-top no > soundcard is listed: No internal laptop card and no external (here > Focusrite Starlett 2i2). Because of this all sound dependend services > are blocked (no video starting, no audio) > > When going back to 0.3.38-2 everything is listed up fine and working as > expected. > Do you have pipewire-pulse 0.3.39 installed, but not wireplumber?
Bug#997862: wireplumber: Bluetooth is not supported, breaking audio of existing systems
Control: severity -1 normal Hi Vincent, Le mar. 26 oct. 2021 à 10:30, Vincent Lefevre a écrit : > > Oct 26 10:18:29 zira wireplumber[1701]: SPA handle 'api.bluez5.enum.dbus' > could not be loaded; is it installed? > Oct 26 10:18:29 zira wireplumber[1701]: PipeWire's BlueZ SPA missing or > broken. Bluetooth not supported. > Oct 26 10:18:34 zira bluetoothd[844]: src/service.c:btd_service_connect() > a2dp-sink profile connect failed for 7C:96:D2:4E:98:41: Protocol not available > Wireplumber needs the libspa-0.2-bluetooth package to support bluetooth. I guess it was missing from your system. libspa-0.2-bluetooth is only a plugin, wireplumber can work without it. This is why it is not a dependency. Best, Dylan
Bug#997818: wireplumber: Failed to preset unit, file /etc/systemd/user/pipewire-session-manager.service already exists
Hi Chris, Thanks for your report! Le lun. 25 oct. 2021 à 12:30, Chris Halls a écrit : > > Setting up wireplumber (0.4.4-1) ... > Failed to preset unit, file > /etc/systemd/user/pipewire-session-manager.service already exists and is a > symlink to /lib/systemd/user/pipewire-media-session.service. > Created symlink /etc/systemd/user/pipewire.service.wants/wireplumber.service > → /usr/lib/systemd/user/wireplumber.service. > /usr/bin/deb-systemd-helper: error: systemctl preset failed on > wireplumber.service: No such file or directory > That was introduced by this commit: > https://gitlab.freedesktop.org/pipewire/wireplumber/-/commit/1b48e068cee i will discuss with upstream devs to see how we can solve that. Best, Dylan
Bug#996994: [Pkg-utopia-maintainers] Bug#996994: Bug#996994: pipewire-bin: Recent pipewire upgrade lacks WirePlumber
Le ven. 22 oct. 2021 à 12:27, Michael Biebl a écrit : > > Now you have me confused. > If pipewire-media-session is going away soon anyway, being replaced by > wireplumber, why introduce it as a new source package? > Is wireplumber not ready it or are there other reasons to keep > pipewire-media-session installed? > To avoid complaints from people :) and because wireplumber is still not able to build on some architectures.
Bug#997001: ITP: pipewire-media-session -- PipeWire example session manager
Package: wnpp Owner: Dylan Aïssi Severity: wishlist Package name: pipewire-media-session URL: https://gitlab.freedesktop.org/pipewire/media-session/ License: MIT Description: PipeWire example session manager PipeWire Media Session is an example session manager for PipeWire. . Note that it is recommended the use of WirePlumber instead. It was previously part of pipewire package itself, but it moved to a separate module to accelerate its deprecation in favor of WirePlumber.
Bug#996994: [Pkg-utopia-maintainers] Bug#996994: pipewire-bin: Recent pipewire upgrade lacks WirePlumber
Hi, Le ven. 22 oct. 2021 à 08:54, Michael Biebl a écrit : > > > pipewire 0.3.39 replaces pipewire-media-session with wireplumber and recent > > upgrade removes media-session. > > > > Maybe pipewire-media-mession should be an empty transitional package, > depending on wireplumber and in bookworm+1 this empty transitional is > dropped? > I will upload today the new version of pipewire-media-session as an independent package that should fix this issue. And because the new pipewire-media-session has a build-dep on libpipewire-0.3-dev (>= 0.3.39), this transitional was a bit tricky. Sorry about that. Best, Dylan
Bug#996884: Ambiguous licenses for files in debian/patches/ folder
Hi Santiago, Le mer. 20 oct. 2021 à 14:03, Santiago Ruano Rincón a écrit : > > Thanks for pointing this out. Hopefully, this change solves the > ambiguity: > https://salsa.debian.org/debian/libcgroup/-/blob/8476aa90da599fe59ad33d6a9911b931291b84f4/debian/copyright#L17 > Indeed, thanks :) The copyright holders are probably wrong, you should add the patches authors. Best, Dylan
Bug#996884: Ambiguous licenses for files in debian/patches/ folder
Package: libcgroup Severity: important Dear Maintainer, The license of debian/patches/* files is ambiguous as defined in the debian/copyright file. libcg is under LGPL-2.1 license whereas all files into the debian/ folder are under GPL-3 including all patches. That means either the whole package is relicensed under GPL-3 (which seems wrong) or better all patches are under the same license of the targeted files. Could you clarify the license of these patches in d/copyright? Thanks Best, Dylan
Bug#996883: Ambiguous licenses for files in debian/patches/ folder
Package: rpcbind Severity: important Dear Maintainer, The license of debian/patches/* files is ambiguous as defined in the debian/copyright file. RPCBind is under BSD-3-Clause license whereas all files into the debian/ folder are under GPL-3 including all patches. That means either the whole package is relicensed under GPL-3 (which seems wrong) or better all patches are under the same license of the targeted files. Could you clarify the license of these patches in d/copyright? Thanks Best, Dylan
Bug#996882: Ambiguous licenses for files in debian/patches/ folder
Package: protobuf Severity: important Dear Maintainer, The license of debian/patches/* files is ambiguous as defined in the debian/copyright file. Protobuf is under BSD-3-Clause license whereas all files into the debian/ folder are under GPL-3 including all patches. That means either the whole package is relicensed under GPL-3 (which seems wrong) or better all patches are under the same license of the targeted files. Could you clarify the license of these patches in d/copyright? Thanks Best, Dylan
Bug#993573: transition: libdav1d
Hi, Le lun. 6 sept. 2021 à 17:07, Sebastian Ramacher a écrit : > > Please go ahead > Thanks, uploaded! Best, Dylan
Bug#993573: transition: libdav1d
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Dear Release Team, Please schedule a transition slot for libdav1d. The auto-generated ben tracker looks good: https://release.debian.org/transitions/html/auto-dav1d.html The 4 reverse deps (ffmpeg, libavif, libheif and vlc) build fine with the new version in experimental. Thanks, Dylan
Bug#993237: ITP: svt-av1 -- Scalable Video Technology for AV1
Package: wnpp Severity: wishlist Owner: Dylan Aïssi X-Debbugs-Cc: debian-de...@lists.debian.org, debian-multime...@lists.debian.org * Package name: svt-av1 Version: 0.8.7 * URL : https://gitlab.com/AOMediaCodec/SVT-AV1/ * License : BSD-2-clause Description: Scalable Video Technology for AV1 (SVT-AV1 Encoder and Decoder) The Scalable Video Technology for AV1 (SVT-AV1 Encoder and Decoder) is an AV1-compliant encoder/decoder library core. The SVT-AV1 encoder development is a work-in-progress targeting performance levels applicable to both VOD and Live encoding / transcoding video applications. The SVT-AV1 decoder implementation is targeting future codec research activities. Remark: This package is maintained by Debian Multimedia Team at https://salsa.debian.org/multimedia-team/svt-av1
Bug#992686: pipewire-pulse: Please have pipewire-pulse Provide pulseaudio
Hi, Thanks for your bug report! On Sun, 22 Aug 2021 13:50:24 +0300 Arto Jantunen wrote: > > Please add Provides: pulseaudio to the pipewire-pulse package so that the > pulseaudio daemon which this replaces can be removed (a lot of tools have > dependencies on pulseaudio, but work just as well or better with > pipewire-pulse). > > I don't think Conflicts, Replaces or Breaks are needed here as there are no > file conflicts and there is no real harm that comes from having both installed > (except perhaps difficulties in making sure that the right daemon is started > and the wrong one isn't). Pulseaudio and pipewire-pulse are not fully compatible (pipewire-pulse can't load pulse modules, doesn't have /usr/bin/pulseaudio or other Pulse executable interfaces, ...). The best way to deal with that issue is to update all packages that Depends, Recommends or Suggests pulseaudio to depend either on pulseaudio or pipewire-pulse (i.e. pulseaudio | pipewire-pulse). (Thanks to smcv for the suggestion!) Best, Dylan
Bug#992604: closed by Debian FTP Masters (reply to Dylan Aïssi ) (Bug#992604: fixed in wireplumber 0.4.2-2)
Hi Paul, Le jeu. 26 août 2021 à 08:27, Paul Wise a écrit : > > On Tue, 2021-08-24 at 10:51 +, Dylan Aïssi wrote: > > > * Remove conffiles that moved to /usr/share/wireplumber/ (Closes: #992604) > > Unfortunately this still didn't work for me, but given wireplumber is > only available in experimental, maybe it doesn't make sense to fix it. > Sorry to hear that it doesn't work for you. I just tried again in a clean sid VM and conffiles are removed, only empty directories (/etc/wireplumber/...) are kept. Best, Dylan
Bug#991919: Bioconductor API Bump to 3.13
Hi, Le jeu. 26 août 2021 à 09:49, Paul Gevers a écrit : > > If this question is to the release team, than the following question we > asked earlier requires an answer: > > What's the status wrt. to the reverse dependencies. Do those that are > > binNMU-able build against the new version? > No, all these reverse dependencies need a manual upgrade with the new upstream releases, they are not binNMU-able. The Debian R Packages team will upgrade to the new upstream releases all of the reverse dependencies. Best, Dylan
Bug#991919: transition: r-api-bioc-3.13
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-CC: debia...@lists.debian.org, debian-...@lists.debian.org Hi, Bioconductor 3.13 was released in May [1]. All r-bioc-* packages need a manual upgrade (after the release of bullseye). [1] https://bioconductor.org/news/bioc_3_13_release/ Please set up a tracker manually, since this is a transition of a virtual package name. Ben file: - title = "r-api-bioc-3.13"; is_affected = .depends ~ /r-api-bioc/; is_good = .depends ~ "r-api-bioc-3.13"; is_bad = .depends ~ "r-api-bioc-3.12"; ----- Best, Dylan
Bug#988689: ITP: 7zip -- 7-Zip file archiver
Hi Yokota, Le mar. 22 juin 2021 à 01:30, yokota a écrit : > > My changes are held on "experimental" branch. Please marge it. > Or, give me write permission to "master" branch. Because "master" > branch is protected and can only writable by project maintainer. > Check https://salsa.debian.org/help/user/project/protected_branches.md > for this issue. Thanks! I have merged your branch and granted you push permission to the master branch. I have reverted one of your commit [1], because pre-dependency should be discussed on debian-devel mailing list [2] and it is not used by 7zip. So, I don't want to introduce a pre-deps by mistake ;-) I just uploaded it to NEW. Feel free to ping me if you need to upload a new version of 7zip. And thanks again for your work on 7zip! Best, Dylan [1] https://salsa.debian.org/debian/7zip/-/commit/10f56c7a60c6e6e485ff9ed7b6e8704453bc7c98 [2] https://www.debian.org/doc/debian-policy/ch-relationships.html#binary-dependencies-depends-recommends-suggests-enhances-pre-depends
Bug#988689: ITP: 7zip -- 7-Zip file archiver
Hi, I started to work on 7zip [1] before realizing you already started a package of it. Are you still working on it? Should we combine our efforts to finish the package? Best, Dylan [1] https://salsa.debian.org/debian/7zip
Bug#966301: guile oom test fails (but currently not on buildds)
Le mar. 15 juin 2021 à 09:02, Rob Browning a écrit : > > I'm fairly uneasy with disabling them all, if that's what we're > currently doing. I'll plan to take a look and/or talk to upstream soon, > though I might not get to it in depth until the weekend. > I agree it would be better to skip specific tests instead to ignore failures for all tests. I did not propose a debdiff to skip only test-out-of-memory for all arches because it would re-enable other failing tests for other arches. I did not want to introduce new FTBFS at this step of freeze. I let you deal with it :-) Best, Dylan
Bug#966301: guile oom test fails (but currently not on buildds)
Hi, It looks like we have to ignore test failures on all arches. Should we do a NMU for bullseye? See attached debdiff. Best, Dylan guile-2.2_2.2.7+1-5.5_NMU.debdiff Description: Binary data
Bug#987248: highlight.js: FTBFS due to a test timeout
tag 987248 + patch
thanks
Hi,
Please find attached a small patch which increase the timeout for
armhf and arm64 (both failing on the Reproducible Builds project as
well).
Best,
Dylan
From: Dylan Aïssi
Date: Thu, 10 Jun 2021 17:54:13 +0200
Subject: [PATCH] Increase dh_auto_test timeout for slow arch (Closes: #987248)
---
debian/rules | 9 +
debian/tests/pkg-js/test | 2 +-
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/debian/rules b/debian/rules
index a28cb81..b28cd9a 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,6 +1,15 @@
#!/usr/bin/make -f
export DH_VERBOSE=1
+# Increase dh_auto_test timeout for slow arch
+# https://bugs.debian.org/987248
+include /usr/share/dpkg/architecture.mk
+ifneq (,$(findstring $(DEB_BUILD_ARCH), armhf arm64))
+ export MOCHA_TIMEOUT=--timeout 4000
+endif
+
+
+
js-compressor := $(or $(notdir $(shell which uglifyjs)),yui-compressor)
%:
diff --git a/debian/tests/pkg-js/test b/debian/tests/pkg-js/test
index a58a668..f749291 100644
--- a/debian/tests/pkg-js/test
+++ b/debian/tests/pkg-js/test
@@ -1,2 +1,2 @@
ln -s . build
-mocha --globals document
+mocha --globals document ${MOCHA_TIMEOUT}
--
2.30.2
Bug#987370: node-pbkdf2: tests fail on armhf
tag 987370 + patch thanks Hi, Please find attached a small patch which increase the timeout only for armhf. Best, Dylan From: Dylan Aïssi Date: Thu, 10 Jun 2021 16:53:36 +0200 Subject: [PATCH] Increase dh_auto_test timeout for slow arch (Closes: #987370) --- debian/rules | 7 +++ 1 file changed, 7 insertions(+) diff --git a/debian/rules b/debian/rules index 218df65..e7c5ca0 100755 --- a/debian/rules +++ b/debian/rules @@ -4,5 +4,12 @@ # Uncomment this to turn on verbose mode. #export DH_VERBOSE=1 +# Increase dh_auto_test timeout for slow arch +# https://bugs.debian.org/987370 +include /usr/share/dpkg/architecture.mk +ifeq ($(DEB_BUILD_ARCH),armhf) + export TAP_TIMEOUT=50 +endif + %: dh $@ -- 2.30.2
Bug#987816:
tag 987816 fixed-upstream + patch thanks Upstream patch is available at: https://github.com/dask/distributed/commit/668f3f1d38
Bug#989601: ITP: vulkan-volk -- Meta-loader for Vulkan API
Package: wnpp Owner: Dylan Aïssi Severity: wishlist Package name: vulkan-volk URL: https://github.com/zeux/volk License: MIT Description: Meta-loader for Vulkan API Volk allows you to dynamically load entrypoints required to use Vulkan without linking to vulkan-1.dll or statically linking Vulkan loader. Additionally, volk simplifies the use of Vulkan extensions by automatically loading all associated entrypoints. Finally, volk enables loading Vulkan entrypoints directly from the driver which can increase performance by skipping loader dispatch overhead.
Bug#989464: ITP: gfxreconstruct -- Improved version of LunarG's vktrace software
Package: wnpp Owner: Dylan Aïssi Severity: wishlist Package name: gfxreconstruct Upstream Author : LunarG URL: https://github.com/LunarG/gfxreconstruct License: MIT Description: Improved version of LunarG's vktrace software The primary goal for the GFXReconstruct project is to create an improved version of LunarG's vktrace software for capture and replay of Vulkan API calls. As development progresses, existing vktrace functionality such as trimming and client-server mode will be integrated with the GFXReconstruct codebase. When GFXReconstruct reaches feature parity with vktrace, vktrace will be deprecated in favor of GFXReconstruct.
Bug#976010: Homebank: team upload of new release before the soft freeze
Hi Francesco, Le dim. 7 févr. 2021 à 08:48, Francesco namuri a écrit : > > have you already made some changes? If not, please, can you wait? > I have only imported the new release in my repo, nothing else. So, no problem, I let you upload it ;-) Best, Dylan
Bug#976010: Homebank: team upload of new release before the soft freeze
Hi Francesco, Is it okay for you if I do a team upload the last upstream release (5.5) of homebank? The soft freeze for Bullseye is in less than 1 week and it would be bad to have an outdated version of homebank. BTW, I have created a clean git repo for homebank [1], if you agree I will ask to salsa maintainers to replace the old one with it? Best, Dylan [1] https://salsa.debian.org/daissi/homebank
Bug#980865:
severity 980865 minor thanks Thanks for this bug report. Indeed, the upstream website is dead, but I am not convinced to define pypi as the new upstream website. It is only an alternative repository.
Bug#976570: libstatgen: FTBFS on arm64: E: Build killed with signal TERM after 150 minutes of inactivity
severity 976570 normal thanks Hi, arm64 is not on the architecture list for libstatgen, so I decrease the severity of the bug. Best, Dylan
Bug#974200: RM: plink2 [ppc64el] -- ROM; architecture not supported upstream
Package: ftp.debian.org Severity: normal I'm making this request as part of the Debian Med Team, which is the maintainer of plink2. Missing build of plink2 for this architecture is preventing its migration to testing. The ppc64el binary was built only once during the transition to support SIMD-Everywhere for plink2 and this artefact (not upstream supported) can safely be removed. Thanks. Best regards. Dylan
Bug#973805: ITP: r-bioc-tcgabiolinksgui.data -- Data for the TCGAbiolinksGUI package
Package: wnpp Severity: wishlist Subject: ITP: r-bioc-tcgabiolinksgui.data -- Data for the TCGAbiolinksGUI package Package: wnpp Owner: Dylan Aïssi Severity: wishlist * Package name: r-bioc-tcgabiolinksgui.data Version : 1.10.0 Upstream Author : Tiago Chedraoui Silva * URL : https://bioconductor.org/packages/data/experiment/TCGAbiolinksGUI.data/ * License : GPL-3 Programming Lang: GNU R Description : Data for the TCGAbiolinksGUI package Supporting data for the TCGAbiolinksGUI package. Remark: This package is maintained by Debian R Packages Maintainers at https://salsa.debian.org/r-pkg-team/r-bioc-tcgabiolinksgui.data
Bug#973407: transition: r-api-bioc-3.12
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-CC: debia...@lists.debian.org Hi, Bioconductor 3.12 was released 2 days ago [1]. All r-bioc-* packages need a manual upgrade. [1] https://www.bioconductor.org/news/bioc_3_12_release/ Please set up a tracker manually, since this is a transition of a virtual package name. Ben file: - title = "r-api-bioc-3.12"; is_affected = .depends ~ /r-api-bioc/; is_good = .depends ~ "r-api-bioc-3.12"; is_bad = .depends ~ "r-api-bioc-3.11"; ----- Best, Dylan
Bug#857454: qtltools: please make the build reproducible
Hi Chris, On Mon, 12 Oct 2020 16:58:03 - "Chris Lamb" wrote: > > Friendly ping on this? > This package seems now reproducible. Could you confirm? Best, Dylan
Bug#968381:
severity 968381 serious thanks bpytop is now in testing and in buster-backports
Bug#969943: ITP: r-cran-isospecr -- GNU R IsoSpec Algorithm
Package: wnpp Severity: wishlist Subject: ITP: r-cran-isospecr -- GNU R IsoSpec Algorithm Package: wnpp Owner: Dylan Aïssi Severity: wishlist * Package name: r-cran-isospecr Version : 2.1.2 Upstream Author : Mateusz Krzysztof Lacki and Michal Startek * URL : https://cran.r-project.org/package=IsoSpecR * License : BSD-2-clause Programming Lang: GNU R Description : GNU R IsoSpec Algorithm IsoSpec is a fine structure calculator used for obtaining the most probable masses of a chemical compound given the frequencies of the composing isotopes and their masses. It finds the smallest set of isotopologues with a given probability. The probability is assumed to be that of the product of multinomial distributions, each corresponding to one particular element and parametrized by the frequencies of finding these elements in nature. These numbers are supplied by IUPAC - the International Union of Pure and Applied Chemistry. Remark: This package is maintained by Debian R Packages Maintainers at https://salsa.debian.org/r-pkg-team/r-cran-isospecr
Bug#969636: bashtop: Please require python3-psutil or soften error message
Hi Felix, I am CCing Jonathan as he did the backport. Le dim. 6 sept. 2020 à 12:21, Felix Lechner a écrit : > > Thanks for packaging an attractive new tool for Debian! I ran bashtop > recently (from backports) and received this error message: > > % bashtop > Error: Missing python3 psutil module! > > The program works fine, but the relatively strong error message seems > inconsistent with the maintainer's decision to merely recommend > python3-psutil. Please require the missing module or soften the > message. > If you have the other tools for data collection, bashtop doesn't require python3-psutil with Linux but it requires it with kFreeBSD and Hurd (though untested :-). I agree the dependencies of bashtop can be improved. I just realized python3-psutil is enabled by default. To temporarily fix that you can disable python3-psutil in your config file ($HOME/.config/bashtop). To fix the package, we have two possibilities. The first one is to patch bashtop to disable python3-psutil by default and the usage of python3-psutil is up to the users. The second option is to switch the dependency on python3-psutil from "recommend" to "require", but we will have to backport a newer version of python3-psutil as upstream declares that psutil >= 5.7.0 is needed (in Buster we have psutil 5.5.1 and in testing we have 5.7.2). bpytop, the successor of bashtop and already in the NEW queue, also requires psutil >= 5.7.0. So, if we want bpytop in buster-backports, we will have to backport psutil anyway. Any preference? Best, Dylan
Bug#602396: Long fixed
close 602396 thanks This bug has long since been fixed, in both stable and unstable versions of okular.
Bug#904839: bsdmainutils: cal still highlights though -h option is gone
Package: ncal Followup-For: Bug #904839 This is really a follow-up bug, but the '-h' option is still documented in the man page (as an option for both cal and ncal). -- System Information: Debian Release: bullseye/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.7.0-2-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ncal depends on: ii libc6 2.31-3 ii libtinfo6 6.2-1 ncal recommends no packages. ncal suggests no packages. -- no debconf information
Bug#968128: feh: Desktop file missing webp
Package: feh Version: 3.4.1-1 Severity: minor Dear Maintainer, The file /usr/share/applications/feh.desktop does not list 'image/webp' as a MIME type, despite the support that is compiled in. (I have not checked if there are other image types missing.) --Dylan Thurston -- System Information: Debian Release: bullseye/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.7.0-2-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages feh depends on: ii libc6 2.31-3 ii libcurl4 7.68.0-1+b1 ii libexif12 0.6.22-2 ii libimlib2 1.6.1-2 ii libpng16-16 1.6.37-2 ii libx11-6 2:1.6.10-3 ii libxinerama1 2:1.1.4-2 ii yudit-common 3.0.7-3 Versions of packages feh recommends: ii libjpeg-progs 1:9d-1 feh suggests no packages. -- no debconf information
Bug#967110: ITP: bpytop -- Resource monitor that shows usage and stats
Package: wnpp Severity: wishlist Subject: ITP: bpytop -- Resource monitor that shows usage and stats Package: wnpp Owner: Dylan Aïssi Severity: wishlist * Package name: bpytop Version : 1.0.2 Upstream Author : Aristocratos * URL : https://github.com/aristocratos/bpytop * License : Apache-2.0 Programming Lang: Python Description : Resource monitor that shows usage and stats Resource monitor that shows usage and stats for processor, memory, disks, network and processes. Python port of bashtop. Remark: This package is maintained at: https://salsa.debian.org/debian/bpytop
Bug#964371: dh-r: generate wrong dependencies for source package with multiple binary packages
Package: dh-r We have more and more source packages generating more than a unique R binary package (i.e. they also generate python, library, ...) like isospec, rosa and r-bioc-mofa. Currently, dh-r assigns substvars to the first binary package from d/control. If this package is not the R package but a python or whatever, then dependencies of the generated R binary package will be wrong (empty). dh-r should assign substvars to the first **R** binary package in d/control. See: https://lists.debian.org/debian-med/2020/07/msg00045.html
Bug#964191: RoSA ante portas - happily pass this on
Le sam. 4 juil. 2020 à 11:27, Andreas Tille a écrit : > > While I think your changes are pretty sensible it does not solve the > problem. > :-( I will investigate this again later today Dylan
Bug#964191: RoSA ante portas - happily pass this on
Hi Andreas, Le sam. 4 juil. 2020 à 09:43, Andreas Tille a écrit : > @Dylan: Any idea how to fix > > E: r-other-rosa: requires-r-api \o/ this tag is finally useful :-) I pushed a change that should fix this issue. I was not able to test because r-cran-lsd is not available (still in NEW). Could you try this change for me? Best, Dylan
Bug#916333: ITP: dav1d -- fast and small AV1 video stream decoder
Hi, Le jeu. 2 juil. 2020 à 10:34, Sebastian Ramacher a écrit : > > Did you try re-upload since the rejection? If not, why not? > > > > If that was the only reason given by ftpmasters for rejecting, then I > > would suggest to simply a) make sure that the licensing/patenting > > situation as you understand it is explicitly laid out in > > debian/copyright file, and then b) re-release the package. > > I'm not the maintainer, but it is currently in NEW with d/changelog > fixed. Yep, I fixed it with the help of James Cowgill (he maintains aom with the same patent license) and re-upload the new version in January (~ 2 weeks after the reject). > > > When re-uploaded, I can suggest to try nudge ftpmasters by logging into > > irc channel #debian-ftp and kindly request a review of the package. > > I've done that repeatedly without any progress. > I did not ping them about this package but if Sebastian already tried to do it without any success, I guess I will not have more luck. Since the version 0.7.0 (the last version in NEW queue), there is no longer any files with Alliance-for-Open-Media-Patent-License-1.0 in their header. This AOM-Patent-License-1.0 is only provided in doc/PATENTS, so maybe this will simplify the approval. Best, Dylan
Bug#916333: ITP: dav1d -- fast and small AV1 video stream decoder
Hi, (Please keep #916333 in CC ;-) Le jeu. 2 juil. 2020 à 09:44, Vasyl Gello a écrit : > So you have no objection against me doing a team upload and picking it for my > kodi work? > Jean-Batiste Kempf from VideoLAN also is very motivated to have dav1d in > Debian, so I will talk with Mattia & maybe even reach Joerg > on that matter. Feel free to do a team upload, but dav1d is still not in Debian and I don't know if it will be accepted one day... So, an upload now will have no real effect (at least for Debian). This situation is annoying because the reject was only about the AOM patent license but we already have the aom package in Debian with the same license. Best, Dylan
Bug#916333: ITP: dav1d -- fast and small AV1 video stream decoder
Hi Vasyl, On Tue, 30 Jun 2020 03:38:20 + Vasyl Gello wrote: > There is a new upstream release 0.7.1 for a week or so. > Can you please package it? dav1d is in the NEW queue since 1,5 years. It was rejected after 1 year in the NEW queue and I still don't have news about the last attempt. I am losing motivation for this package, I will probably convert this ITP to RFP... Best, Dylan
Bug#921559: MTP broken for number of phones with "LIBMTP PANIC: Unable to initialize device"
Hi, I am really annoyed by this issue! It seems to be present in other distrib at least in Fedora but I am not able to reproduce... I have no problem with my android phones. Le ven. 19 juin 2020 à 11:51, Tobias Bora a écrit : > > I can confirm the bug also with libmtp9 1.1.17 and a Samsung Galaxy A3 > (2015, A300FU). Is there at least meanwhile a solution independant of > libmtp and a bit faster than installing a FTP server on my phone? You can try to use "android-file-transfer" (available in Debian repo), it should work because it doesn't use libmtp. Best, Dylan
Bug#962802: Installation Report
Package: installation-reports Boot method: USB Image version: http://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/debian-testing-amd64-xfce-CD-1.iso Date: 2020-06-14 Machine: Lenovo Yoga S730 Processor: Intel(R) Core(TM) i7-10510U CPU @ 1.80GHz Memory: 16GB Partitions: Filesystem Type 1K-blocks Used Available Use% Mounted on udev devtmpfs 80312240 8031224 0% /dev tmpfs tmpfs 1617052 1476 1615576 1% /run /dev/nvme0n1p5 ext4 47797996 4501564 40838680 10% / tmpfs tmpfs 8085244 102396 7982848 2% /dev/shm tmpfs tmpfs 51204 5116 1% /run/lock tmpfs tmpfs 80852440 8085244 0% /sys/fs/cgroup /dev/nvme0n1p1 vfat26214442100220044 17% /boot/efi /dev/nvme0n1p7 ext4 342852932 15011212 310356052 5% /home tmpfs tmpfs 1617048 16 1617032 1% /run/user/1000 Output of lspci -knn (or lspci -nn): 00:00.0 Host bridge [0600]: Intel Corporation Device [8086:9b61] (rev 0c) 00:02.0 VGA compatible controller [0300]: Intel Corporation UHD Graphics [8086:9b41] (rev 02) 00:04.0 Signal processing controller [1180]: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem [8086:1903] (rev 0c) 00:08.0 System peripheral [0880]: Intel Corporation Xeon E3-1200 v5/v6 / E3-1500 v5 / 6th/7th/8th Gen Core Processor Gaussian Mixture Model [8086:1911] 00:12.0 Signal processing controller [1180]: Intel Corporation Comet Lake Thermal Subsytem [8086:02f9] 00:14.0 USB controller [0c03]: Intel Corporation Device [8086:02ed] 00:14.2 RAM memory [0500]: Intel Corporation Device [8086:02ef] 00:15.0 Serial bus controller [0c80]: Intel Corporation Serial IO I2C Host Controller [8086:02e8] 00:16.0 Communication controller [0780]: Intel Corporation Comet Lake Management Engine Interface [8086:02e0] 00:1c.0 PCI bridge [0604]: Intel Corporation Device [8086:02b8] (rev f0) 00:1c.4 PCI bridge [0604]: Intel Corporation Device [8086:02bc] (rev f0) 00:1d.0 PCI bridge [0604]: Intel Corporation Device [8086:02b0] (rev f0) 00:1d.1 PCI bridge [0604]: Intel Corporation Device [8086:02b1] (rev f0) 00:1d.4 PCI bridge [0604]: Intel Corporation Device [8086:02b4] (rev f0) 00:1f.0 ISA bridge [0601]: Intel Corporation Device [8086:0284] 00:1f.3 Audio device [0403]: Intel Corporation Device [8086:02c8] 00:1f.4 SMBus [0c05]: Intel Corporation Device [8086:02a3] 00:1f.5 Serial bus controller [0c80]: Intel Corporation Comet Lake SPI (flash) Controller [8086:02a4] 6c:00.0 Network controller [0280]: Realtek Semiconductor Co., Ltd. RTL8822CE 802.11ac PCIe Wireless Network Adapter [10ec:c822] 6d:00.0 Non-Volatile memory controller [0108]: Samsung Electronics Co Ltd NVMe SSD Controller SM981/PM981/PM983 [144d:a808] Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[E] Configure network: [O] Detect CD: [ ] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Clock/timezone setup: [O] User/password setup:[O] Install tasks: [O] Install boot loader:[O] Overall install:[O] Comments/Problems: The laptop uses the relatively new Realtek 8822CE card, which the firmware-realtek package doesn't include yet. Running `dmesg | grep network` contained an error about the rtw_pci module not being able to find the driver (I didn't record the precise error). I was able to get the WiFi working in the installer by downloading the latest linux-firmware tarball[1] from git.kernel.org, and replacing the files in /lib/firmware/rtw88 in a shell. [1] https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/snapshot/linux-firmware-20200519.tar.gz
Bug#962130: r-cran-isospec: wrong name for R package
Package: r-cran-isospec
Version: 1.9.1-1
Severity: important
Hi,
isospec provides an R package (r-cran-isospec), but looking at the
IsoSpecR/DESCRIPTION file the name should be r-cran-isospecr (i.e.
with a final "R"). This is also confirmed by the package name at CRAN
(https://cran.r-project.org/package=IsoSpecR). This binary package
must be renamed.
Moreover, the d/rules file is bugged (would required another bug
report but lets talk a bit about it here for now) because the variable
{R:Depends} is not substituted. Consequently, the binary R package has
wrong dependencies (no dependency to r-base-core, r-api-, etc). As you
need to upload to NEW to fix the name of the package, it is possible
to split the source package and to use the archive from CRAN for the R
package. This will simplify the d/rules and fix the second issue.
Your package, your decision ;-)
Best,
Dylan
Bug#961709: lintian: Warn if R binary packages don't depend on virtual r-api-* package
Hi Dirk,
Le jeu. 28 mai 2020 à 18:03, Dirk Eddelbuettel a écrit :
>
> OTOH the way we implement the tag doesn't it get added automagically by the
> r-base-core package when constructing an r-{cran,bioc,...}-* package?
>
Yes, it is.
But, in one week I found by chance two packages (r-cran-isospec and
r-bioc-mofa) with similar problem.These packages are not simple, the
Debian source package generates more than one binary package. In
addition to the binary R package, isospec generates libraries packages
and a python package and r-bioc-mofa generates a python package. They
have a non standard d/rules file that induce a bug.
I would say if I have found this bug twice in one week, it will happen
again :-(.
Best,
Dylan
Bug#955211: release.debian.org: Transition r-base for 4.0.0
Hi, Le jeu. 28 mai 2020 à 18:58, Dirk Eddelbuettel a écrit : > > Thanks everybody for the help with the transition: 4.0.0-3 is now in testing. > \o/ Both transition trackers (r-api-4.0 and r-api-bioc-3.11) were not very useful to determine the order to update Bioconductor packages. Some Bioconductor packages were green in the first tracker but red in the second one, because they were automatically rebuild without an upgrade. So, it was not possible to use the first tracker to follow the upgrade order of Bioconductor packages. And the second tracker did not consider the r-api-4.0 rebuild order, so some packages in the first levels were not buildable until the dependency chain was ready for r-api-4.0. Next time there is a transition with these two r-api virtual packages, we should use a unique ben file for them, something like this: title = "r-api"; is_affected = .depends ~ "r-api-3.5" | .depends ~ "r-api-4.0" | .depends ~ "r-api-bioc-3.10" | .depends ~ "r-api-bioc-3.11"; is_good = .depends ~ "r-api-4.0" | .depends ~ "r-api-bioc-3.11"; is_bad = .depends ~ "r-api-3.5" | .depends ~ "r-api-bioc-3.10"; Best, Dylan
Bug#961709: lintian: Warn if R binary packages don't depend on virtual r-api-* package
Hi, Le jeu. 28 mai 2020 à 10:15, Dylan Aïssi a écrit : > > I just saw a R binary package (r-cran-isospec) with wrong dependencies > Some days ago, I found another package with similar bug (r-bioc-mofa). Already fixed in unstable but the version in testing has wrong dependencies. This tag will help to identify these packages. With the recent r-api-4.0 transition, it would be quite bad to leave behind these packages. Best, Dylan
Bug#961709: lintian: Warn if R binary packages don't depend on virtual r-api-* package
Package: lintian
Version: 2.77.1
Severity: wishlist
X-Debbugs-CC: debia...@lists.debian.org
Hi,
I just saw a R binary package (r-cran-isospec) with wrong dependencies
(bug not yet opened). Lintian doesn't warn about a problem in its
dependencies, so it would be cool to add a new warning (maybe
"missing-dependency-on-r-api") to warn if any R binary packages (
r-{cran|bioc|other}-* ) don't depend at least to a virtual r-api-*
package.
Thanks
Best,
Dylan
Bug#961591: [RFS] r-bioc-graph
Hi, Le mer. 27 mai 2020 à 20:04, Nilesh Patra a écrit : > > The second test (needing the library) failed on gitlab-ci, w/o adding > r-cran-xml and r-cran-runit, possible because this doesn't pick up depends > from test-depends. > This passed on my local machine though. Since I wanted to be sure, I moved > this there. There is probably a bug on the salsa-ci side, because both tests passed on my computer. Let's skip salsa-ci for now. I have moved back these dependencies to test-deps and I have updated your patch (str_replace_all --> gsub) to not add a new dependency. You probably already noticed, the debian/test/control files for R packages require a lot of manual work to keep the list of test-deps up-to-date. Because I don't want to do this manually, I moved the code to tests these packages into pkg-r-autopkgtest. The list of test-deps is automatically generated at run time from the DESCRIPTION file. Currently, it is enabled only for bioconductor packages, if there is no big bug with this transition, we will be able to remove the debian/test/control files and to enable this for other R packages. Thanks again for #961591. Best, Dylan
Bug#961591: [RFS] r-bioc-graph
Hi Nilesh, Le mer. 27 mai 2020 à 19:36, Nilesh Patra a écrit : > > Hi, > Currently r-bioc-graph has failing tests, and has RC bug - #961591 filed > against this. > I have fixed this and pushed my changes to the team repo here[1]. > Need review and sponsorship. > Thanks for #961591 !!! I don't understand why you moved some test-deps to deps ? Best, Dylan
Bug#961592: r-bioc-gviz: autopkgtest regression
Hi, Le mer. 27 mai 2020 à 11:12, Andreas Tille a écrit : > > Ahhh, its new to me that pkg-r-autopkgtest does more than just > loading the library. Hmmm, Dylan, do you have any idea besides > patching the test suite? > I am testing my patch that skip the test if "BSgenome.Hsapiens.UCSC.hg19" is not available, so this bug should be fixed soon. But, regarding https://bugs.debian.org/961591 , I have no idea how to fix it. Best, Dylan
Bug#961576: RM: r-cran-treescape [ppc64el] -- ROM; FTBFS
Package: ftp.debian.org Severity: normal Hi, In the recent rebuild for r-api4.0, r-cran-treescape FTBFS on ppc64el (https://bugs.debian.org/961234). Upstream has replaced r-cran-treescape with r-cran-treespace (already in Debian). Because r-cran-treescape has still some users, I am asking to remove only the ppc64el binary to avoid a missing build and to finish the r-api4.0 transition. Thanks. Best, Dylan
Bug#961234:
Hi, I think we should not spend time to try to fix this FTBFS as treescape is depreciated in favor of treespace (already in Debian). Because treescape has still some users (popcon 82), I will ask to remove only the ppc64el binary to avoid a missing build. Best, Dylan
Bug#960375: ITP: r-cran-rstatix -- Pipe-Friendly Framework for Basic Statistical Tests
Package: wnpp Severity: wishlist Subject: ITP: r-cran-rstatix -- Pipe-Friendly Framework for Basic Statistical Tests Package: wnpp Owner: Dylan Aïssi Severity: wishlist * Package name: r-cran-rstatix Version : 0.5.0 Upstream Author : Alboukadel Kassambara * URL : https://cran.r-project.org/package=rstatix * License : GPL-2 Programming Lang: GNU R Description : Pipe-Friendly Framework for Basic Statistical Tests Provides a simple and intuitive pipe-friendly framework, coherent with the 'tidyverse' design philosophy, for performing basic statistical tests, including t-test, Wilcoxon test, ANOVA, Kruskal-Wallis and correlation analyses. The output of each test is automatically transformed into a tidy data frame to facilitate visualization. Additional functions are available for reshaping, reordering, manipulating and visualizing correlation matrix. Functions are also included to facilitate the analysis of factorial experiments, including purely 'within-Ss' designs (repeated measures), purely 'between-Ss' designs, and mixed 'within-and-between-Ss' designs. It's also possible to compute several effect size metrics, including "eta squared" for ANOVA, "Cohen's d" for t-test and 'Cramer V' for the association between categorical variables. The package contains helper functions for identifying univariate and multivariate outliers, assessing normality and homogeneity of variances. Remark: This package is maintained by Debian R Packages Maintainers at https://salsa.debian.org/r-pkg-team/r-cran-rstatix
Bug#958702: bashtop
Hi Jonathan, The VCS fields on the ITP are wrong, the repo is there: > https://salsa.debian.org/debian/bashtop And bashtop (outdated) is in the NEW queue. > https://ftp-master.debian.org/new/bashtop_0.8.5-1.html Feel free to add yourself as comaintainer ;-) Best, Dylan
Bug#959468: Add a DEP-8 test
Package: jbig2dec
Severity: wishlist
Tags: patch
Hi,
Please find attached a patch that add a basic DEP-8 test for jbig2dec.
Best,
Dylan
From 7441b13d5a60db0f6c7564c57a1061fafa1a89ed Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Dylan=20A=C3=AFssi?=
Date: Sat, 2 May 2020 13:19:32 +0200
Subject: [PATCH] Add a DEP-8 test
---
debian/tests/control | 2 ++
debian/tests/run-unit-test | 13 +
2 files changed, 15 insertions(+)
create mode 100644 debian/tests/control
create mode 100644 debian/tests/run-unit-test
diff --git a/debian/tests/control b/debian/tests/control
new file mode 100644
index 000..7082497
--- /dev/null
+++ b/debian/tests/control
@@ -0,0 +1,2 @@
+Tests: run-unit-test
+Depends: @
diff --git a/debian/tests/run-unit-test b/debian/tests/run-unit-test
new file mode 100644
index 000..98a7f2a
--- /dev/null
+++ b/debian/tests/run-unit-test
@@ -0,0 +1,13 @@
+#!/bin/sh -e
+
+export LC_ALL=C.UTF-8
+
+if [ "$AUTOPKGTEST_TMP" = "" ] ; then
+AUTOPKGTEST_TMP=`mktemp -d /tmp/${debname}-test.XX`
+trap "rm -rf $AUTOPKGTEST_TMP" 0 INT QUIT ABRT PIPE TERM
+fi
+
+cp -a annex-h.jbig2 $AUTOPKGTEST_TMP
+cd $AUTOPKGTEST_TMP
+
+jbig2dec annex-h.jbig2 -o annex-h.png
--
2.20.1
Bug#958702: ITP: bashtop -- Resource monitor that shows usage and stats
Package: wnpp Severity: wishlist Subject: ITP: bashtop -- Resource monitor that shows usage and stats Package: wnpp Owner: Dylan Aïssi Severity: wishlist * Package name: bashtop Version : 0.8.4 Upstream Author : Aristocratos * URL : https://github.com/aristocratos/bashtop * License : Apache-2.0 Programming Lang: (C, C++, C#, Perl, Python, etc.) Description : Resource monitor that shows usage and stats Resource monitor that shows usage and stats for processor, memory, disks, network and processes. Remark: This package is maintained by Dylan Aïssi at https://salsa.debian.org/daissi/bashtop
Bug#958562: texlive-extra-utils: missing man page for pdfcrop
Package: texlive-extra-utils Version: 2020.20200417-1 Severity: normal Dear Maintainer, The 'pdfcrop' utility is included in texlive-extra-utils in /usr/bin, but there is no man page (even a stub) for it. ## List of ls-R files -rw-r--r-- 1 root root 1591 Apr 20 17:26 /var/lib/texmf/ls-R lrwxrwxrwx 1 root root 29 Apr 16 21:25 /usr/share/texmf/ls-R -> /var/lib/texmf/ls-R-TEXMFMAIN lrwxrwxrwx 1 root root 31 Apr 16 21:33 /usr/share/texlive/texmf-dist/ls-R -> /var/lib/texmf/ls-R-TEXLIVEDIST lrwxrwxrwx 1 root root 31 Apr 16 21:33 /usr/share/texlive/texmf-dist/ls-R -> /var/lib/texmf/ls-R-TEXLIVEDIST ## Config files -rw-r--r-- 1 root root 475 Apr 20 17:23 /etc/texmf/web2c/texmf.cnf lrwxrwxrwx 1 root root 33 Apr 16 21:33 /usr/share/texmf/web2c/fmtutil.cnf -> /var/lib/texmf/fmtutil.cnf-DEBIAN lrwxrwxrwx 1 root root 32 Apr 16 21:33 /usr/share/texmf/web2c/updmap.cfg -> /var/lib/texmf/updmap.cfg-DEBIAN -rw-r--r-- 1 root root 3032 Apr 20 17:25 /var/lib/texmf/tex/generic/config/language.dat ## Files in /etc/texmf/web2c/ total 8 -rw-r--r-- 1 root root 283 Feb 28 2019 mktex.cnf -rw-r--r-- 1 root root 475 Apr 20 17:23 texmf.cnf ## md5sums of texmf.d ca40c66f144b4bafc3e59a2dd32ecb9c /etc/texmf/texmf.d/00debian.cnf -- System Information: Debian Release: bullseye/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.5.0-1-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages texlive-extra-utils depends on: ii libunicode-linebreak-perl 0.0.20190101-1+b2 ii python33.8.2-3 ii tex-common 6.14 ii texlive-base 2020.20200417-1 ii texlive-binaries 2020.20200327.54578-4 ii texlive-latex-base 2020.20200417-1 ii texlive-luatex 2020.20200417-1 ii texlive-plain-generic 2020.20200417-1 Versions of packages texlive-extra-utils recommends: ii ghostscript9.52~dfsg-1 ii libfile-homedir-perl 1.004-1 ii liblog-log4perl-perl 1.49-1 ii libyaml-tiny-perl 1.73-1 ii ruby 1:2.7+1 ii texlive-latex-recommended 2020.20200417-1 Versions of packages texlive-extra-utils suggests: pn chktex ii default-jre-headless 2:1.11-72 pn dvidvi pn dvipng pn fragmaster pn lacheck pn latexdiff pn latexmk pn purifyeps pn xindy Versions of packages tex-common depends on: ii dpkg 1.19.7 ii ucf 3.0038+nmu1 Versions of packages tex-common suggests: ii debhelper 13 Versions of packages texlive-extra-utils is related to: ii tex-common6.14 ii texlive-binaries 2020.20200327.54578-4 -- no debconf information
Bug#958309: ITP: r-bioc-bioccheck -- Bioconductor-specific package checks
Package: wnpp Severity: wishlist Subject: ITP: r-bioc-bioccheck -- Bioconductor-specific package checks Package: wnpp Owner: Dylan Aïssi Severity: wishlist * Package name: r-bioc-bioccheck Version : 1.22.0 Upstream Author : Copyright: (FIXME: year)-2019 Bioconductor Package Maintainer, * URL : https://bioconductor.org/packages/BiocCheck/ * License : Artistic-2.0 Programming Lang: GNU R Description : Bioconductor-specific package checks Executes Bioconductor-specific package checks. Remark: This package is maintained by Debian R Packages Maintainers at https://salsa.debian.org/r-pkg-team/r-bioc-bioccheck
Bug#958308: ITP: r-bioc-biocviews -- Categorized views of R package repositories
Package: wnpp Severity: wishlist Subject: ITP: r-bioc-biocviews -- Categorized views of R package repositories Package: wnpp Owner: Dylan Aïssi Severity: wishlist * Package name: r-bioc-biocviews Version : 1.54.0 Upstream Author : Copyright: (FIXME: year)-2019 VJ Carey , * URL : https://bioconductor.org/packages/biocViews/ * License : Artistic-2.0 Programming Lang: GNU R Description : Categorized views of R package repositories Infrastructure to support 'views' used to classify Bioconductor packages. 'biocViews' are directed acyclic graphs of terms from a controlled vocabulary. There are three major classifications, corresponding to 'software', 'annotation', and 'experiment data' packages. Remark: This package is maintained by Debian R Packages Maintainers at https://salsa.debian.org/r-pkg-team/r-bioc-biocviews
Bug#949361: r-cran-ranger: autopkgtest regression on some architectures
Hi Andreas, Le ven. 17 avr. 2020 à 16:48, Andreas Tille a écrit : > > I wonder whether it might make sense to exclude this single test and > reduce severity of the bug from serious to important. > Yes, this is my plan. Best, Dylan
Bug#956716: ITP: r-cran-rematch2 -- Tidy Output from Regular Expression Matching
Package: wnpp Severity: wishlist Subject: ITP: r-cran-rematch2 -- Tidy Output from Regular Expression Matching Package: wnpp Owner: Dylan Aïssi Severity: wishlist * Package name: r-cran-rematch2 Version : 2.1.1 Upstream Author : Mango Solutions, Gábor Csárdi, Matthew Lincoln * URL : https://cran.r-project.org/package=rematch2 * License : MIT Programming Lang: GNU R Description : Tidy Output from Regular Expression Matching Wrappers on 'regexpr' and 'gregexpr' to return the match results in tidy data frames. Remark: This package is maintained by Debian R Packages Maintainers at https://salsa.debian.org/r-pkg-team/r-cran-rematch2
Bug#955167:
Hi, The autopkgtest regression is now fixed in the new version 0.9-1+dfsg-1 which passes according to debci [1]. BUT, if we look at the log file there are a lot of errors which are not detected (?) by debci [2]. By looking at the history of tests, it seems this behavior was already present in the oldest log (2019-12-14). So, probably there are not a regression, but anyway these errors should be fixed as well. Best, Dylan [1] https://ci.debian.net/packages/r/r-cran-sf/ [2] https://ci.debian.net/data/autopkgtest/unstable/amd64/r/r-cran-sf/4877284/log.gz
Bug#955211: Bioconductor transition
Hi, Le ven. 3 avr. 2020 à 22:49, Graham Inggs a écrit : > > Would you please update #955211 with an updated version of the > r-api-bioc ben file? > Please find below a ben file for the r-api-bioc transition. This "part" of the r-base transition doesn't need only a rebuild of packages but also an upgrade with new upstream versions. Ben file: title = "r-api-bioc-3.11"; is_affected = .depends ~ /r-api-bioc/; is_good = .depends ~ "r-api-bioc-3.11"; is_bad = .depends ~ "r-api-bioc-3.10"; Best, Dylan
Bug#955274: ITP: r-bioc-wrench -- GNU R wrench normalization for sparse count data
Package: wnpp Severity: wishlist Subject: ITP: r-bioc-wrench -- GNU R wrench normalization for sparse count data Package: wnpp Owner: Dylan Aïssi Severity: wishlist * Package name: r-bioc-wrench Version : 1.4.0 Upstream Author : Senthil Kumar Muthiah, * URL : https://bioconductor.org/packages/Wrench/ * License : Artistic-2.0 Programming Lang: GNU R Description : GNU R wrench normalization for sparse count data Wrench is a package for normalization sparse genomic count data, like that arising from 16s metagenomic surveys. Remark: This package is maintained by Debian R Packages Maintainers at https://salsa.debian.org/r-pkg-team/r-bioc-wrench
Bug#954853: ITP: r-cran-isoband -- Generate Isolines and Isobands from Regularly Spaced Elevation
Package: wnpp Severity: wishlist Subject: ITP: r-cran-isoband -- Generate Isolines and Isobands from Regularly Spaced Elevation Package: wnpp Owner: Dylan Aïssi Severity: wishlist * Package name: r-cran-isoband Version : 0.2.0 Upstream Author : Claus Wilke * URL : https://cran.r-project.org/package=isoband * License : MIT Programming Lang: GNU R Description : Generate Isolines and Isobands from Regularly Spaced Elevation Grids A fast C++ implementation to generate contour lines (isolines) and contour polygons (isobands) from regularly spaced grids containing elevation data. Remark: This package is maintained by Debian R Packages Maintainers at https://salsa.debian.org/r-pkg-team/r-cran-isoband
Bug#952695: Request for sponsorship or upload rights Re: r-cran-xml2: autopkgtest failure against libxml2 2.9.10
Hi Michael, On Tue, 3 Mar 2020 16:22:47 +0100 "Michael R. Crusoe" wrote: > I've commited a fix for this bug. > > > If a DD could sponsor that upload or grant me upload rights, I would > appreciate it. > Thanks for this! Just uploaded! I got an error when I tried to grant you upload rights for this package, but probably only from my side. I will try to fix it before the next time. Best, Dylan
Bug#950253: linux-image-5.4.0-3-amd64: Short freezes and lockups, perhaps related to Elan touchpad
Package: src:linux Version: 5.4.13-1 Severity: important My Asus Zenbook UX3600c has been behaving badly recently. Observed behaviour: * Occasional short freezes (a few seconds), during which the mouse and keyboard are not responsive. I looked after one such incident and didn't see anything that looked relevant in the logs. * Complete hangs and kernel oops. I've attached one kernel oops below; there are other very similar oopses. * Poor trackpad performance. Specifically, two-finger mouse-wheel scrolling will sometimes jump around. This seems to develop as the computer runs, and is fine right after the computer boots. * Occasional failures to boot, with many copies of the following message: [time] i2c_hid i2c-ELAN1200:00: i2c_hid_get_input: incomplete report (16/16466) (This was copied down by hand.) I'm not sure exactly when this started happening. I upgraded to my current kernel version (linux-image-5.4.0-3-amd64:amd64 5.4.13-1) on January 20, it's possible the problems started then. (It's possible that some of these problems are unrelated or that there is a hardware problem, of course.) Best, Dylan Thurston Kernel oops below: Jan 30 09:54:06 localhost kernel: [22010.103475] Oops: [#1] SMP PTI Jan 30 09:54:06 localhost kernel: [22010.103480] CPU: 2 PID: 1163 Comm: xfwm4 Not tainted 5.4.0-3-amd64 #1 Debian 5.4.13-1 Jan 30 09:54:06 localhost kernel: [22010.103482] Hardware name: ASUSTeK COMPUTER INC. UX360CA/UX360CA, BIOS UX360CA.202 02/17/2016 Jan 30 09:54:06 localhost kernel: [22010.103549] RIP: 0010:i915_active_acquire+0x9/0x70 [i915] Jan 30 09:54:06 localhost kernel: [22010.103554] Code: 00 00 00 48 c7 46 58 00 00 00 00 c7 46 38 00 00 00 00 48 c7 c6 0a 60 6b c0 e9 f3 cf 30 f8 0f 1f 00 0f 1f 44 00 00 41 54 55 53 <8b> 47 38 48 89 fb 85 c0 74 15 8d 50 01 f0 0f b1 53 38 75 f2 45 31 Jan 30 09:54:06 localhost kernel: [22010.103556] RSP: 0018:b3d840957a40 EFLAGS: 00010286 Jan 30 09:54:06 localhost kernel: [22010.103559] RAX: RBX: 9c2ca1a77540 RCX: Jan 30 09:54:06 localhost kernel: [22010.103561] RDX: 9c2c33542ac0 RSI: 9c2ca1a77540 RDI: 0008 Jan 30 09:54:06 localhost kernel: [22010.103562] RBP: 9c2c33542ac0 R08: 9c2c9cbf4288 R09: 9c2c9cbf4288 Jan 30 09:54:06 localhost kernel: [22010.103564] R10: a000 R11: R12: 0008 Jan 30 09:54:06 localhost kernel: [22010.103566] R13: 0004 R14: 9c2c33542ac0 R15: 401c Jan 30 09:54:06 localhost kernel: [22010.103569] FS: 7f71216c9f00() GS:9c2cac10() knlGS: Jan 30 09:54:06 localhost kernel: [22010.103571] CS: 0010 DS: ES: CR0: 80050033 Jan 30 09:54:06 localhost kernel: [22010.103573] CR2: 0040 CR3: 00025863c001 CR4: 003606e0 Jan 30 09:54:06 localhost kernel: [22010.103575] Call Trace: Jan 30 09:54:06 localhost kernel: [22010.103635] i915_active_ref+0x21/0x210 [i915] Jan 30 09:54:06 localhost kernel: [22010.103673] i915_vma_move_to_active+0x6e/0xf0 [i915] Jan 30 09:54:06 localhost kernel: [22010.103730] i915_gem_do_execbuffer+0xc62/0x1520 [i915] Jan 30 09:54:06 localhost kernel: [22010.103740] ? _cond_resched+0x15/0x30 Jan 30 09:54:06 localhost kernel: [22010.103743] ? mutex_lock+0xe/0x30 Jan 30 09:54:06 localhost kernel: [22010.103748] ? unix_stream_read_generic+0x1f7/0x8f0 Jan 30 09:54:06 localhost kernel: [22010.103753] ? __kmalloc_node+0x1f5/0x300 Jan 30 09:54:06 localhost kernel: [22010.103792] i915_gem_execbuffer2_ioctl+0x1df/0x3d0 [i915] Jan 30 09:54:06 localhost kernel: [22010.103841] ? i915_gem_madvise_ioctl+0x13a/0x290 [i915] Jan 30 09:54:06 localhost kernel: [22010.103879] ? i915_gem_execbuffer_ioctl+0x2e0/0x2e0 [i915] Jan 30 09:54:06 localhost kernel: [22010.103908] drm_ioctl_kernel+0xaa/0xf0 [drm] Jan 30 09:54:06 localhost kernel: [22010.103926] drm_ioctl+0x208/0x390 [drm] Jan 30 09:54:06 localhost kernel: [22010.103971] ? i915_gem_execbuffer_ioctl+0x2e0/0x2e0 [i915] Jan 30 09:54:06 localhost kernel: [22010.103978] do_vfs_ioctl+0x40e/0x670 Jan 30 09:54:06 localhost kernel: [22010.103981] ksys_ioctl+0x5e/0x90 Jan 30 09:54:06 localhost kernel: [22010.103984] __x64_sys_ioctl+0x16/0x20 Jan 30 09:54:06 localhost kernel: [22010.103989] do_syscall_64+0x52/0x160 Jan 30 09:54:06 localhost kernel: [22010.103995] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Jan 30 09:54:06 localhost kernel: [22010.104000] RIP: 0033:0x7f7122ba15b7 Jan 30 09:54:06 localhost kernel: [22010.104004] Code: 00 00 90 48 8b 05 d9 78 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a9 78 0c 00 f7 d8 64 89 01 48 Jan 30 09:54:06 localhost kernel: [22010.104007] RSP: 002b:7ffcc7eac3d8 EFLAGS: 0246 ORIG_RAX: 0010 Jan 30 09:54:
Bug#945821: stretch-pu: package libofx/1:0.9.10-2+deb9u2
Hi, Le mar. 28 janv. 2020 à 23:52, Adam D. Barratt a écrit : > Please go ahead; sorry for the delay. Thanks, uploaded! Best, Dyla,
Bug#950201: texlive-pictures-doc: pgfmanual.pdf has incorrect page numbers
Package: texlive-pictures-doc Version: 2019.20191208-4 Severity: minor The file /usr/share/doc/texlive-doc/generic/pgf/pgfmanual.pdf doesn't seem to have been TeXed enough times: the page numbers are far off. For instance, according to the table of contents (p. 6), page 100 is the start of Chapter 11, "Design Principles". But p. 100 in the PDF is the start of Part II, "Installation on Configuration", which according to the table of contents starts on p. 78. (This is both the 100th page of the PDF and labeled as p. 100 on the printed page.) The mistake seems to be that 20+ pages of the table of contents aren't counted. ## List of ls-R files -rw-r--r-- 1 root root 1383 Jan 11 13:25 /var/lib/texmf/ls-R lrwxrwxrwx 1 root root 29 Dec 3 05:04 /usr/share/texmf/ls-R -> /var/lib/texmf/ls-R-TEXMFMAIN lrwxrwxrwx 1 root root 31 Dec 8 18:15 /usr/share/texlive/texmf-dist/ls-R -> /var/lib/texmf/ls-R-TEXLIVEDIST lrwxrwxrwx 1 root root 31 Dec 8 18:15 /usr/share/texlive/texmf-dist/ls-R -> /var/lib/texmf/ls-R-TEXLIVEDIST ## Config files -rw-r--r-- 1 root root 475 Jan 11 13:20 /etc/texmf/web2c/texmf.cnf lrwxrwxrwx 1 root root 33 Dec 8 18:15 /usr/share/texmf/web2c/fmtutil.cnf -> /var/lib/texmf/fmtutil.cnf-DEBIAN lrwxrwxrwx 1 root root 32 Dec 8 18:15 /usr/share/texmf/web2c/updmap.cfg -> /var/lib/texmf/updmap.cfg-DEBIAN -rw-r--r-- 1 root root 2951 Jan 11 13:25 /var/lib/texmf/tex/generic/config/language.dat ## Files in /etc/texmf/web2c/ total 8 -rw-r--r-- 1 root root 283 Feb 28 2019 mktex.cnf -rw-r--r-- 1 root root 475 Jan 11 13:20 texmf.cnf ## md5sums of texmf.d ca40c66f144b4bafc3e59a2dd32ecb9c /etc/texmf/texmf.d/00debian.cnf -- System Information: Debian Release: bullseye/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-3-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages texlive-pictures-doc depends on: ii tex-common6.13 ii texlive-base 2019.20191208-4 texlive-pictures-doc recommends no packages. texlive-pictures-doc suggests no packages. Versions of packages tex-common depends on: ii dpkg 1.19.7 ii ucf 3.0038+nmu1 Versions of packages tex-common suggests: ii debhelper 12.8 Versions of packages texlive-pictures-doc is related to: ii tex-common6.13 ii texlive-binaries 2019.20190605.51237-3 -- no debconf information
Bug#949168:
Hi Jonatan, hi Francesco, @Jonatan, thanks for your bug reports. There is no need to open a new bug report for each new upstream release. Once there is one open, you can just update it to refer to the new release. @Francesco, thanks for maintaining this package. I saw there was no update since 2018/11 despite the Jonathan's bug reports. Do you need any help (co-maint, nmu or whatever) for this package? Thanks. Best, Dylan
Bug#949465: ITP: r-cran-tinytest -- Lightweight and Feature Complete Unit Testing Framework
Package: wnpp Severity: wishlist Subject: ITP: r-cran-tinytest -- Lightweight and Feature Complete Unit Testing Framework Package: wnpp Owner: Dylan Aïssi Severity: wishlist * Package name: r-cran-tinytest Version : 1.1.0 Upstream Author : Mark van der Loo * URL : https://cran.r-project.org/package=tinytest * License : GPL-3 Programming Lang: GNU R Description : Lightweight and Feature Complete Unit Testing Framework Provides a lightweight (zero-dependency) and easy to use unit testing framework. Main features: install tests with the package. Test results are treated as data that can be stored and manipulated. Test files are R scripts interspersed with test commands, that can be programmed over. Fully automated build-install-test sequence for packages. Skip tests when not run locally (e.g. on CRAN). Flexible and configurable output printing. Compare computed output with output stored with the package. Run tests in parallel. Extensible by other packages. Report side effects. Remark: This package is maintained by Debian R Packages Maintainers at https://salsa.debian.org/r-pkg-team/r-cran-tinytest
Bug#948654: ITP: thesias -- Testing Haplotype Effects In Association Studies
Package: wnpp Owner: Debian Med Packaging Team Severity: wishlist Package name: thesias Upstream Author : David-Alexandre Trégouët URL: https://github.com/daissi/thesias License: GPL-3+ Description: Testing Haplotype Effects In Association Studies The objectif of the THESIAS program is to performed haplotype-based association analysis in unrelated individuals. This program is based on the maximum likelihood model described in Tregouet et al. 2002 (Hum Mol Genet 2002,11: 2015-2023) and is linked to the SEM algorithm (Tregouet et al. Ann Hum Genet 2004,68: 165-177). THESIAS allows one to simultaneous estimate haplotype frequencies and their associate effects on the phenotype of interest. In this new THESIAS release, quantitative, qualitative (logistic and matched-pair analysis), categorical and survival outcomes can be studied. X-linked haplotype analysis is also feasible. Covariate-adjusted haplotype effects as well as haplotype x covariate interactions can also be investigated. This package will be maintained by the Debian Med Packaging Team at: https://salsa.debian.org/med-team/thesias
Bug#947001: Bug#947004: S4Vectors Segmentation fault after r-base-core update (Was: Bug#947004: Tests segfaults (since the r-base-core update?))
Hi,
Le ven. 10 janv. 2020 à 00:30, Pages, Herve a écrit :
> Based on the traceback the error happens during evaluation of the 1st
> argument ('target') passed to checkEqualsNumeric(), that is, during
> evaluation of 'runmed(y, 7)'. Since this involves base R code only
> (runmed() is implemented in the stats package) I would say that it's not
> immediately obvious that the problem is in my court.
Thanks Hervé for this.
I just updated how to run Debian autopkgtests [1-2] by replacing:
> LC_ALL=C R --no-save < require("S4Vectors")
> S4Vectors:::.test()
> EOT
with
> LC_ALL=C.UTF-8 R --no-save -e 'BiocGenerics:::testPackage("S4Vectors")'
which seems to be the recommended way to run tests for bioconductor
packages. And now, there is no segfault anymore for S4vectors but
IRanges is still crashing. Should we upload these fixes into
Debian/unstable?
Best,
Dylan
[1]
https://salsa.debian.org/r-pkg-team/r-bioc-s4vectors/commit/51b8ca2571dac1685e748679568edf4463cbfd59
[2]
https://salsa.debian.org/r-pkg-team/r-bioc-iranges/commit/06a76a22fa236f919fc0038c5c01aec35ec2ecda
[3]
https://bioconductor.org/developers/how-to/unitTesting-guidelines/#RUnitConventions
Bug#916333: dav1d_0.5.2-1_amd64.changes REJECTED
Hi, Le mar. 31 déc. 2019 à 21:50, James Cowgill a écrit : > > The AOM patent license is not a copyright license but rather an > "optional extra" which grants users patent rights under some extra > conditions. You would usually use it along with an additional license to > cover all the copyright related parts which the DFSG is more concerned > about. > > In aom, I put the patent license in a "Comment" section at the top and > don't mention it in any "License" clauses which I think makes this > distinction between copyright and patent issues a bit clearer. Thanks James for this explanation! The files from the package dav1d which are "covered" by the "optional extra" AOM patent license have exactly the same header as these from the package aom. So, I will write the d/copyright file like you did for aom. I hope this will be fine. Best, Dylan
Bug#948005: ITP: --
Package: wnpp Severity: wishlist Subject: ITP: -- Package: wnpp Owner: Dylan Aïssi Severity: wishlist * Package name: Version : Upstream Author : * URL : * License : Programming Lang: (C, C++, C#, Perl, Python, etc.) Description : Remark: This package is maintained by at
Bug#948006: ITP: r-cran-modeldata -- Data Sets Used Useful for Modeling Packages
Package: wnpp Severity: wishlist Subject: ITP: r-cran-modeldata -- Data Sets Used Useful for Modeling Packages Package: wnpp Owner: Dylan Aïssi Severity: wishlist * Package name: r-cran-modeldata Version : 0.0.1 Upstream Author : Max Kuhn, RStudio * URL : https://cran.r-project.org/package=modeldata * License : MIT Programming Lang: GNU R Description : Data Sets Used Useful for Modeling Packages Data sets used for demonstrating or testing model-related packages are contained in this package. Remark: This package is maintained by Debian R Packages Maintainers at https://salsa.debian.org/r-pkg-team/r-cran-modeldata
Bug#948007: ITP: r-cran-modeldata -- Data Sets Used Useful for Modeling Packages
Package: wnpp Severity: wishlist Subject: ITP: r-cran-modeldata -- Data Sets Used Useful for Modeling Packages Package: wnpp Owner: Dylan Aïssi Severity: wishlist * Package name: r-cran-modeldata Version : 0.0.1 Upstream Author : Max Kuhn, RStudio * URL : https://cran.r-project.org/package=modeldata * License : MIT Programming Lang: GNU R Description : Data Sets Used Useful for Modeling Packages Data sets used for demonstrating or testing model-related packages are contained in this package. Remark: This package is maintained by Debian R Packages Maintainers at https://salsa.debian.org/r-pkg-team/r-cran-modeldata
Bug#916333: dav1d_0.5.2-1_amd64.changes REJECTED
Hi Thorsten, Thanks for your work as ftpmaster! Le ven. 27 déc. 2019 à 00:00, Thorsten Alteholz a écrit : > > the list of grants does not contain the right to modify and distribute the > modifications of files under the Alliance-for-Open-Media-Patent-License-1.0. > I am afraid that this is not compatible woth the DFSG. I have re-read the license and did not find the relevant part, could you tag the problematic part of the Alliance-for-Open-Media-Patent-License-1.0 ? In case of the Alliance-for-Open-Media-Patent-License-1.0 is not compatible with the DFSG, what should we do for packages in the Debian archive with the same license (aom) ? Similar question for packages with embedded dav1d (firefox) ? Best, Dylan
Bug#945821: stretch-pu: package libofx/1:0.9.10-2+deb9u2
Package: release.debian.org Severity: normal Tags: stretch User: release.debian@packages.debian.org Usertags: pu Dear release team, Upstream has fixed CVE-2019-9656, this CVE is non-dsa. The patch is already applied in jessie/buster/testing/unstable (#924350) and now I would like to fix the Stretch version. Please find attached a debdiff. Best, Dylan libofx_0.9.10-2+deb9u2.debdiff Description: Binary data
Bug#939781: Please include Navi10 firmware files
Since Mesa,the kernel and LLVM9 are now on Debian testing,have you planned to also update the firmware-amd-graphics package to add Navi 10 firmware files in the future? Thanks.
Bug#943766: buster-pu: package libofx/1:0.9.14-1+deb10u1
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
Dear release team,
Upstream has fixed CVE-2019-9656, this CVE is non-dsa. I already
backported patches to unstable (#924350) and now I would like to fix
the Buster version. Please find attached a debdiff.
Best,
Dylan
diff -Nru libofx-0.9.14/debian/changelog libofx-0.9.14/debian/changelog
--- libofx-0.9.14/debian/changelog 2019-02-13 07:51:24.0 +0100
+++ libofx-0.9.14/debian/changelog 2019-10-23 08:04:35.0 +0200
@@ -1,3 +1,9 @@
+libofx (1:0.9.14-1+deb10u1) buster; urgency=medium
+
+ * Add upstream patch to fix CVE-2019-9656 (Closes: #924350).
+
+ -- Dylan Aïssi Wed, 23 Oct 2019 08:04:35 +0200
+
libofx (1:0.9.14-1) unstable; urgency=medium
[ Ondřej Nový ]
diff -Nru libofx-0.9.14/debian/patches/CVE-2019-9656.patch libofx-0.9.14/debian/patches/CVE-2019-9656.patch
--- libofx-0.9.14/debian/patches/CVE-2019-9656.patch 1970-01-01 01:00:00.0 +0100
+++ libofx-0.9.14/debian/patches/CVE-2019-9656.patch 2019-10-23 08:04:35.0 +0200
@@ -0,0 +1,17 @@
+Author: Christian Stimming
+Description: Fix CVE-2019-9656.
+Origin: upstream, https://github.com/libofx/libofx/commit/15d0511253
+Bug: https://github.com/libofx/libofx/issues/22
+Bug-Debian: https://bugs.debian.org/924350
+
+--- a/lib/ofx_sgml.cpp
b/lib/ofx_sgml.cpp
+@@ -126,7 +126,7 @@
+ {
+ message_out (PARSER, "Element " + identifier + " found");
+ //BANKTRANLIST ignored, we will process it's attributes directly inside the STATEMENT,
+-if (curr_container_element->type != "STATEMENT")
++if (curr_container_element && curr_container_element->type != "STATEMENT")
+ {
+ message_out(ERROR, "Element " + identifier + " found while not inside a STATEMENT container");
+ }
diff -Nru libofx-0.9.14/debian/patches/series libofx-0.9.14/debian/patches/series
--- libofx-0.9.14/debian/patches/series 1970-01-01 01:00:00.0 +0100
+++ libofx-0.9.14/debian/patches/series 2019-10-23 08:04:35.0 +0200
@@ -0,0 +1 @@
+CVE-2019-9656.patch
Bug#868884:
Hi, Same problem here with a fresh Buster install and up-to-date on a Dell inspiron Mini 1012. Can we do something to fix it? Best, Dylan
Bug#941849: librrds-perl: Cannot install / deleted by apt after perl upgrade to perl 5.30.0-5
Package: librrds-perl Version: 1.7.2-1 Severity: grave Justification: renders package unusable Dear Maintainer, * What led up to the situation? librrds-perl was removed by apt after upgrading to perl 5.30.0-5, after that became uninstallable because it requieres perlapi-5.28.1 * What exactly did you do (or not do) that was effective (or ineffective)? Just upgraded to perl 5.30.0-5 * What was the outcome of this action? It removed and render uninstallable librrds-perl * What outcome did you expect instead? Expected to not remove librrds-perl -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-3-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.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 librrds-perl depends on: ii libc6 2.29-2 ii librrd8 1.7.2-1 ii perl5.30.0-5 pn perlapi-5.28.1 librrds-perl recommends no packages. librrds-perl suggests no packages.
Bug#940611: fails to start because no wrapper missing
Hi, Le mar. 17 sept. 2019 à 23:08, Andreas Tille a écrit : > Thanks for your bug report including the patch. I've pushed it the the > packaging Git leaving the package for final inspection by Dylan. Thanks both. I will update autopkgtest tests to use the wrapper. @Andreas, I was too busy IRL and I let my gpg key expire. I have updated my key on the Debian server but I cannot upload any package until the next sync. Don't hesitate to upload any relevant changes. Best, Dylan
Bug#710297: Payment
This is a message from the Lunarpages Internet Solutions E-Mail Security Service -- The original e-mail attachment "Payment.gz" is on the list of unacceptable attachments for this site and has been replaced by this warning message. At Mon Sep 16 05:11:47 2019 the content scanner said: Lunarpages: Executable DOS/Windows programs are dangerous in email (anowai.exe) No programs allowed (anowai.exe) Please logon to baruwa.lunarpages.net to review the message with message id: 1i9plm-0004oK-Es. -- Postmaster Lunarpages Internet Solutions baruwa.lunarpages.net
Bug#939363: openssl: Older OpenSSL binaries crash on startup, no error messages are shown.
Package: openssl Version: 1.1.1c-1 Severity: important As title says. Using AppImages with older OpenSSL binaries instantly aborts the application and I get no error codes. I have tested this with Ripcord and it will not open. Hopefully this will be resolved soon. The developer of this application (ripcord) says that the OpenSSL package is broken and incompatible with older binaries. -- System Information: Debian Release: 10.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/16 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages openssl depends on: ii libc6 2.28-10 ii libssl1.1 1.1.1c-1 openssl recommends no packages. Versions of packages openssl suggests: ii ca-certificates 20190110 -- no debconf information
Bug#931122: haskell-mode: interactive mode fails to parse ghci start message
Package: haskell-mode Version: 16.1-6 Severity: normal Dear Maintainer, When starting interactive-haskell-mode with the current ghc (8.4.4), the mode does not correctly parse the line indicating how many modules are loaded. To reproduce: % emacs -q t.hs [attached, dummy file] * M-x interactive-haskell-mode * M-l results in Haskell Process command errored with: (error "Unexpected response from haskell process.") You can see the problem by running ghci manually: % ghci t.hs GHCi, version 8.4.4: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( t.hs, interpreted ) [flags changed] Ok, one module loaded. *Main> This response, "Ok, one module loaded", is not what the code in haskell-load.el is expecting. This is addressed upstream here: https://github.com/haskell/haskell-mode/issues/1553 That's from a previous iteration of the message, the current github code apparently handles up to GHC 8.6.3. This makes interactive-haskell-mode almost useless. -- System Information: Debian Release: 10.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.utf8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages haskell-mode depends on: ii elpa-haskell-mode 16.1-6 haskell-mode recommends no packages. haskell-mode suggests no packages. -- no debconf information module Main where import Data.Group main = print "Hello World"
Bug#929319: Move mkvtoolnix-gui.1 from package mkvtoolnix to mkvtoolnix-gui
Package: src:mkvtoolnix
Severity: minor
Tags: patch
Hi,
The manpage of mkvtoolnix-gui is not provided by the package which
provides the binary of mkvtoolnix-gui. Currently, manpage of
mkvtoolnix-gui is provided by mkvtoolnix. I guess is should be better
to move the manpage to the package which provides the binary. Please
find attached a patch to do this (you will have to adapt Breaks and
Replaces according to the new version).
Best,
Dylan
From 500f99b99dac97932d24c42164ad63c3a2a8a468 Mon Sep 17 00:00:00 2001
From: Dylan Aïssi
Date: Sat, 4 May 2019 09:34:07 +0200
Subject: [PATCH] Move mkvtoolnix-gui.1 from package mkvtoolnix to mkvtoolnix-gui
---
debian/control| 4 +++-
debian/mkvtoolnix-gui.install | 2 ++
debian/mkvtoolnix.install | 9 -
3 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/debian/control b/debian/control
index b5d3d766..172b40e8 100644
--- a/debian/control
+++ b/debian/control
@@ -15,6 +15,7 @@ Build-Depends: debhelper-compat (= 12), libboost-math-dev, libboost-regex-dev,
Package: mkvtoolnix
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
+Breaks: mkvtoolnix-gui (<< 31.0.0-2)
Suggests: mkvtoolnix-gui
Description: Set of command-line tools to work with Matroska files
Matroska is a new multimedia container format, based on EBML (Extensible
@@ -30,7 +31,8 @@ Description: Set of command-line tools to work with Matroska files
Package: mkvtoolnix-gui
Architecture: any
Depends: mkvtoolnix (= ${binary:Version}), ${shlibs:Depends}, ${misc:Depends}
-Replaces: mkvtoolnix (<= 4.6.0-1)
+Breaks: mkvtoolnix (<< 31.0.0-2)
+Replaces: mkvtoolnix (<< 31.0.0-2)
Description: Set of tools to work with Matroska files - GUI frontend
Matroska is a new multimedia container format, based on EBML (Extensible
Binary Meta Language), which is a kind of binary XML.
diff --git a/debian/mkvtoolnix-gui.install b/debian/mkvtoolnix-gui.install
index e9716086..179a142e 100644
--- a/debian/mkvtoolnix-gui.install
+++ b/debian/mkvtoolnix-gui.install
@@ -6,3 +6,5 @@ usr/share/mkvtoolnix/sounds/finished-2.ogg
usr/share/mkvtoolnix/sounds/finished-3.ogg
usr/share/mime/packages/org.bunkus.mkvtoolnix-gui.xml
usr/share/metainfo/org.bunkus.mkvtoolnix-gui.appdata.xml
+usr/share/man/man1/mkvtoolnix-gui.1
+usr/share/man/*/man1/mkvtoolnix-gui.1
diff --git a/debian/mkvtoolnix.install b/debian/mkvtoolnix.install
index 65a94d5f..5c174d53 100644
--- a/debian/mkvtoolnix.install
+++ b/debian/mkvtoolnix.install
@@ -2,7 +2,14 @@ usr/bin/mkvmerge
usr/bin/mkvinfo
usr/bin/mkvextract
usr/bin/mkvpropedit
-usr/share/man
+usr/share/man/man1/mkvextract.1
+usr/share/man/man1/mkvinfo.1
+usr/share/man/man1/mkvmerge.1
+usr/share/man/man1/mkvpropedit.1
+usr/share/man/*/man1/mkvextract.1
+usr/share/man/*/man1/mkvinfo.1
+usr/share/man/*/man1/mkvmerge.1
+usr/share/man/*/man1/mkvpropedit.1
usr/share/locale
usr/share/icons/hicolor/*/apps/mkvpropedit.png
usr/share/icons/hicolor/*/apps/mkvextract.png
--
2.11.0
Bug#897109: fastqc: htsjdk.samtools.util.RuntimeIOException: java.io.IOException: Stream closed
Control: severity -1 serious Hi, I have tested the testsuite with the upstream binary (FastQC 0.11.8) and there is no error, so the testsuite is fine. This bug was probably hidden before we added the test of bam and sam files. Currently, fastqc from our package is unable to process bam and sam files which is very annoying for Buster. I guess we have to modify htsjdk-api.patch, but I admit I have no clue how to fix it. The easiest way should be to add SAMFileReader like suggested in [1]. Any suggestion? Best, Dylan [1] https://github.com/samtools/htsjdk/issues/767#issuecomment-264843094
Bug#929008: unblock: cohomcalg/0.32+ds-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Dear release team, Please unblock package cohomcalg. cohomcalg (0.32+ds-2) unstable; urgency=medium * Team upload. [ Helmut Grohne ] * Fix FTCBFS: Pass C++ compiler as LD. (Closes: #928881) * Fix arch-only FTBFS: don't run pdflatex. (Closes: #928881) -- Dylan Aïssi Tue, 14 May 2019 22:29:08 +0200 Thanks. Best, Dylan cohomcalg_0.32+ds-2.debdiff Description: Binary data
Bug#928501: unblock: teeworlds/0.7.2-5
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Dear release team, Please unblock package teeworlds. * Add upstream patches to fix CVE-2019-10877 CVE-2019-10878 CVE-2019-10879 (Closes: #927152). * Add upstream patch to fix creation of recursive path. (Closes: #928110) Thanks. Best, Dylan teeworlds_0.7.2-5.debdiff Description: Binary data
Bug#928110:
tag 927152 pending tag 928110 pending thanks Hi, https://salsa.debian.org/games-team/teeworlds/merge_requests/1/diffs Not yet uploaded, I will do it later, excepted if someone is faster :-). Best, Dylan
