Bug#956866: gnome-desktop3: GDM and GNOME fail to load.
Source: gnome-desktop3 Severity: important Dear Maintainer, After an update tonight GDM just showed a "white screen of death" and a suggestion that I contact my sysadmin. Switching to SLiM worked but then the GNOME desktop failed to load. It seems possible something in the transition to 3.36 is disagreeing with GDM/GNOME. Thanks for your work here! Damon -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (900, 'testing'), (300, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.5.0-1-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
Bug#956865: RM: vokoscreen -- ROM; Unmaintained; new upstream project: VokoscreenNG
Package: ftp.debian.org Severity: normal vokoscreen is no longer maintained. There is a new replacement called vokoscreenNG[1] from the same upstream. [1] https://github.com/vkohaupt/vokoscreenNG/ vokoscreen was based in ffmpeg; vokoscreenNG uses gstreamer. Thanks in advance. Regards, Eriberto
Bug#909806: libphonenumber: New upstream release 8.9.14
See #956863. Once the watch file is updated, messages will start coming through about newer versions.
Bug#954930: munin-plugins-core: missing dependency to libtest-lwp-useragent-perl
Hello Olaf, thank you for your report! On Wed, 25 Mar 2020 06:46:24 -0500 Olaf Zaplinski wrote: > the dependency to libtest-lwp-useragent-perl is missing: Indeed: at the moment the relevant package (libwww-perl) was only indirectly referenced by another "Suggest" (liblwp-useragent-determined-perl). I will add a direct "Suggest" for libwww-perl to fix this. Cheers, Lars
Bug#956864: python3-adios: alternative path adios_mpi.cpython-37m-x86_64-linux-gnu.so doesn't exist
Package: python3-adios Version: 1.13.1-21+b2 Severity: serious Justification: prevents package configuration binNMU 1.13.1-21+b2 removed python3.7 builds, and seems to have broken python3-adios: Errors were encountered while processing: python3-adios E: Sub-process /usr/bin/dpkg returned an error code (1) Setting up python3-adios (1.13.1-21+b2) ... update-alternatives: error: alternative path /usr/lib/python3/dist-packages/adios_openmpi/adios_mpi.cpython-37m-x86_64-linux-gnu.so doesn't exist dpkg: error processing package python3-adios (--configure): installed python3-adios package post-installation script subprocess returned error exit status 2 It's making the package uninstallable. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-adios depends on: ii libblosc1 1.17.1+ds1-1 ii libbz2-1.0 1.0.8-2 ii libc6 2.30-4 ii libgcc-s1 [libgcc-s1] 10-20200402-1 ii libhdf5-openmpi-103-1 1.10.6+repack-1 ii liblz4-1 1.9.2-2 ii libmpich12 3.4~a2+really3.3.2-1 ii libnetcdf-mpi-15 1:4.7.3-2+b1 ii libopenmpi34.0.3-5 ii libstdc++6 10-20200402-1 ii libsz2 1.0.4-1 ii python33.8.2-3 ii zlib1g 1:1.2.11.dfsg-2 python3-adios recommends no packages. python3-adios suggests no packages. -- no debconf information
Bug#956863: libphonenumber7: Update watch and Vcs package attributes
Package: libphonenumber7 Version: 7.1.0-5+b4 Severity: important Dear Maintainer, vcswatch and uscan both report high-priority actions needed in the package tracker. The attached patch fixes both of these. -- 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.107 (SMP w/16 CPU cores) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages libphonenumber7 depends on: ii libboost-atomic1.67.0 1.67.0-13+deb10u1 ii libboost-chrono1.67.0 1.67.0-13+deb10u1 ii libboost-date-time1.67.0 1.67.0-13+deb10u1 ii libboost-filesystem1.67.0 1.67.0-13+deb10u1 ii libboost-system1.67.0 1.67.0-13+deb10u1 ii libboost-thread1.67.0 1.67.0-13+deb10u1 ii libc6 2.28-10 ii libgcc11:8.3.0-6 ii libicu63 63.1-6+deb10u1 ii libprotobuf17 3.6.1.3-2 ii libstdc++6 8.3.0-6 libphonenumber7 recommends no packages. libphonenumber7 suggests no packages. -- no debconf information >From 6b6cb50e215f1f8e5ee4181a57c8cefc2c7e3f15 Mon Sep 17 00:00:00 2001 From: Neil Mayhew Date: Thu, 9 Apr 2020 17:51:54 -0600 Subject: [PATCH] Update VCS links and watch file Content-Type: text/plain; charset=utf-8 --- debian/control | 4 ++-- debian/watch | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/debian/control b/debian/control index 706d7b25..cc548520 100644 --- a/debian/control +++ b/debian/control @@ -32,8 +32,8 @@ Build-Depends: cdbs, Standards-Version: 3.9.8 Section: libs Homepage: https://github.com/googlei18n/libphonenumber/ -Vcs-Browser: https://anonscm.debian.org/cgit/collab-maint/libphonenumber.git/ -Vcs-Git: https://anonscm.debian.org/git/collab-maint/libphonenumber.git +Vcs-Browser: https://salsa.debian.org/debian/libphonenumber.git/ +Vcs-Git: https://salsa.debian.org/debian/libphonenumber.git Package: libphonenumber7-java Section: java diff --git a/debian/watch b/debian/watch index 9302262a..99d6d83f 100644 --- a/debian/watch +++ b/debian/watch @@ -1,3 +1,3 @@ version=3 https://github.com/googlei18n/libphonenumber/tags \ - .*/archive/libphonenumber-(\d[\d\.]+)\.tar\.gz + .*/libphonenumber/archive/.*?(\d[\d\.]+).*\.tar\.gz -- 2.25.1
Bug#956856: w3m-el fails to install
On April 16, 2020 at 6:47AM +1000, peter.chubb (at data61.csiro.au) wrote: > In attempting to install w3m-el I see: > Install w3m-el for emacs > install/w3m-el: byte-compiling for emacs, logged in /tmp/elc.9ZAzScQdF0F8 > ERROR: install script from w3m-el package failed ... > w3m-filter.el:40:1:Error: Wrong type argument: stringp, nil > And so on. It seems '(require 'w3m)' causes the error. Could you please provide the full log, "w3m.el:..." included? My local installation and piuparts tests succeeded, so the problem may be conditional. Thanks, -- Tatsuya Kinoshita pgp72wKlr3iRH.pgp Description: PGP signature
Bug#956844: RM: stardict -- RoQA; Orphaned; Upstream Inactive; Affected by dependency removals
这并不是上游代码能不能获得的问题，而是作者愿不愿意积极主动更新的问题。 debian 需要一些更新的库，用相应旧库的软件要么就跟着更新，要么就被移出。 具体到星际译王这里，或者上游更新，或者维护者改成新库后不断打补丁，这 两者都没实现，就只能移出了。 说实话如果上游不愿意，维护者一直维护一些较大的变动是也很费力的事。 On Thu, Apr 16, 2020 at 10:23 AM atzlinux wrote: > 叹息下！在开源社区，难得有几个中国人主导的 Linux 图形界面的软件。 > > 现在星际译王的上游源代码，还是可以获取的，最近一次更新是9 Dec 2019 。 > > 可能目前原作者胡正最近可能没有时间处理，其它有兴趣的爱好者，欢迎帮忙看下哈！ > > https://github.com/huzheng001/stardict-3 > > > 在 2020/4/16 上午3:58, Boyuan Yang 写道: > > Package: ftp.debian.org > > Severity: normal > > User: ftp.debian@packages.debian.org > > Usertags: remove > > X-Debbugs-CC: debian-chinese...@lists.debian.org > stard...@packages.debian.org > > > > Dear Debian FTP Masters, > > > > It seems that package src:stardict became unsupportable given that its > > upstream has been inactive for several years and that it (build-)depends > on > > several obsolete tools and libraries, including gnome-doc-utils and > > enchant(1). With the release work of Ubuntu 20.04 LTS largely done, I > believe > > we could remove this package from Debian side now. > > > > (Users of Ubuntu 20.04 LTS and Debian 10 can still find stardict in the > repos, > > in case anyone needs it.) > > > -- > 肖盛文 Faris Xiao > 微信：atzlinux > ＱＱ：909868357 > 铜豌豆 Linux > 基于 Debian 的 Linux 中文桌面操作系统：https://www.atzlinux.com > > -- Emfox Zhou GnuPG Public Key: 0x1DEB
Bug#956844: RM: stardict -- RoQA; Orphaned; Upstream Inactive; Affected by dependency removals
文档可以不提供，这样 gnome-doc-utils 就可以不要了。 enchant 是做拼写检查的吧? 应该好替换，比如 aspell 什么的。 就是需要有人花时间去做补丁。 On Thu, Apr 16, 2020 at 10:23 AM atzlinux wrote: > 叹息下！在开源社区，难得有几个中国人主导的 Linux 图形界面的软件。 > > 现在星际译王的上游源代码，还是可以获取的，最近一次更新是9 Dec 2019 。 > > 可能目前原作者胡正最近可能没有时间处理，其它有兴趣的爱好者，欢迎帮忙看下哈！ > > https://github.com/huzheng001/stardict-3 > > > 在 2020/4/16 上午3:58, Boyuan Yang 写道: > > Package: ftp.debian.org > > Severity: normal > > User: ftp.debian@packages.debian.org > > Usertags: remove > > X-Debbugs-CC: debian-chinese...@lists.debian.org > stard...@packages.debian.org > > > > Dear Debian FTP Masters, > > > > It seems that package src:stardict became unsupportable given that its > > upstream has been inactive for several years and that it (build-)depends > on > > several obsolete tools and libraries, including gnome-doc-utils and > > enchant(1). With the release work of Ubuntu 20.04 LTS largely done, I > believe > > we could remove this package from Debian side now. > > > > (Users of Ubuntu 20.04 LTS and Debian 10 can still find stardict in the > repos, > > in case anyone needs it.) > > > -- > 肖盛文 Faris Xiao > 微信：atzlinux > ＱＱ：909868357 > 铜豌豆 Linux > 基于 Debian 的 Linux 中文桌面操作系统：https://www.atzlinux.com > > -- Best Regards LI Daobing
Bug#937302: playonlinux: Python2 removal in sid/bullseye
On Wed, 8 Apr 2020, Markus Koschany wrote: So, I took an initial look at trying to package Phoenicis, but it looks like a rather large task (ie, lots of missing dependencies). On the other hand, I looked at the Python code, and at first glance, it doesn't look like it would be *that* difficult to port to Python 3. Would you be amenable to me developing a patch to port to Python 3, at least as an interim solution? sure feel free to work on a patch to fix #937302, no need to ask for my approval. OK, so it turns out the port to Python 3 was a bit harder than expected, but I think I've got something ready for further review / testing. I have done some initial testing, but I'm not that familiar with playonlinux so I would appreciate some additional testing. I submitted my patch as a merge request here: https://salsa.debian.org/games-team/playonlinux/-/merge_requests/1 Please do let me know if you encounter any bugs. I will fix them. Scott
Bug#956862: ho22bus: Consider removing this package
Source: ho22bus Version: 0.9.1-2 Severity: serious X-Debbugs-CC: cheny...@gmail.com Dear Debian ho22bus maintainer, After reviewing the ho22bus package [1] in Debian, I found that this package saw no upload in the past 8 years. Currently its upstream project is also defunct (previously hosted on Google Code).As a result, I think this package should be suitable for removal from Debian archive. I will submit a removal request 15 days later (after Apr. 30, 2020). If you have any thoughts, please feel free to let me know. [1] https://tracker.debian.org/pkg/ho22bus -- Best Regards, Boyuan Yang
Bug#956844: RM: stardict -- RoQA; Orphaned; Upstream Inactive; Affected by dependency removals
叹息下！在开源社区，难得有几个中国人主导的 Linux 图形界面的软件。 现在星际译王的上游源代码，还是可以获取的，最近一次更新是9 Dec 2019 。 可能目前原作者胡正最近可能没有时间处理，其它有兴趣的爱好者，欢迎帮忙看下哈！ https://github.com/huzheng001/stardict-3 在 2020/4/16 上午3:58, Boyuan Yang 写道: > Package: ftp.debian.org > Severity: normal > User: ftp.debian@packages.debian.org > Usertags: remove > X-Debbugs-CC: debian-chinese...@lists.debian.org stard...@packages.debian.org > > Dear Debian FTP Masters, > > It seems that package src:stardict became unsupportable given that its > upstream has been inactive for several years and that it (build-)depends on > several obsolete tools and libraries, including gnome-doc-utils and > enchant(1). With the release work of Ubuntu 20.04 LTS largely done, I believe > we could remove this package from Debian side now. > > (Users of Ubuntu 20.04 LTS and Debian 10 can still find stardict in the repos, > in case anyone needs it.) > -- 肖盛文 Faris Xiao 微信：atzlinux ＱＱ：909868357 铜豌豆 Linux 基于 Debian 的 Linux 中文桌面操作系统：https://www.atzlinux.com signature.asc Description: OpenPGP digital signature
Bug#898446: Please reconsider enabling the user namespaces by default
On Wed, 2020-04-15 at 08:32 +0100, Simon McVittie wrote: > On Wed, 15 Apr 2020 at 02:52:11 +0100, Ben Hutchings wrote: > > I think you've made a good case that user namespaces are likely to be a > > net positive for security on Debian desktop systems. > > > > This might not be true yet for servers that aren't container hosts. > > Perhaps Debian's kernel should continue to disable unprivileged creation > of user namespaces for now, but we should have a package that installs > a /etc/sysctl.d/*.conf fragment that will enable them, and packages > that benefit from them (bubblewrap, web browsers, sbuild) should have > a Depends or Recommends on that package instead of shipping a setuid-root > namespace-creation helper? [...] But if users install, say, Chrome or Docker from upstream, it won't know how to do this Debian magic. Also, I don't think we should keep patching in kernel.unprivileged_userns_clone forever, so the documented way to disable user namespaces should be setting user.max_user_namespaces to 0. But then there's no good way to have a drop-in file that changes back to the upstream default, because that's dependent on system memory size. So I think we should do something like this: * Document user.max_user_namespaces in procps's shipped /etc/sysctl.conf * Set kernel.unprivileged_userns_clone to 1 by default, and deprecate it (log a warning if it's changed) * Document the change in bullseye release notes Ben. -- Ben Hutchings Always try to do things in chronological order; it's less confusing that way. signature.asc Description: This is a digitally signed message part
Bug#944913: [Python-modules-team] Bug#944913: Bug#944913: Bug#944913: python3-sphinx: Please update to Sphinx 2.2.1
On Wed, Apr 15, 2020 at 7:03 AM Dmitry Shachnev wrote: > > On Wed, Apr 15, 2020 at 12:34:49AM -0400, Sandro Tosi wrote: > > looks like that bug has been fixed, wanna give this another try? thanks! > > Done. And bumped all bugs to RC. great, thanks! I've just uploaded qthelp and devhelp, i saw you already uploaded serializehtml so we should be goo do to onto numpy now, at long last :) -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Bug#955001: ITP: spdx-license-text -- Collection of license data provided by SPDX
Hi Michael, Not sure which formats you plan on including, so... Please ship also the turtle-formatted files in the binary package. That'd be useful for planned improvements to licensecheck. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#956861: buster-pu: package debian-edu-config/2.10.65+deb10u5
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
Dear SRMs,
we would like the following two 'important' bugs in buster:
debian-edu-config (2.10.65+deb10u5) buster; urgency=medium
[ Wolfgang Schweer ]
* Add policies files for Firefox-ESR and Thunderbird to fix the TLS/SSL setup.
This makes sure that the Debian-Edu_rootCA.crt file gets installed as
trusted certificate for Firefox-ESR and Thunderbird. (Already fixed in
Bullseye.)
- Add share/firefox-esr/distribution/policies.json (Closes: #944450).
- Add lib/thunderbird/distribution/policies.json (Closes: #955978).
- Adjust Makefile accordingly.
The full debdiff is attached and I haven't uploaded yet.
Thanks for your work on Debian!
--
cheers,
Holger
---
holger@(debian|reproducible-builds|layer-acht).org
PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
diff -Nru debian-edu-config-2.10.65+deb10u4/debian/changelog debian-edu-config-2.10.65+deb10u5/debian/changelog
--- debian-edu-config-2.10.65+deb10u4/debian/changelog 2020-01-30 17:23:38.0 +0100
+++ debian-edu-config-2.10.65+deb10u5/debian/changelog 2020-04-16 02:34:38.0 +0200
@@ -1,3 +1,16 @@
+debian-edu-config (2.10.65+deb10u5) buster; urgency=medium
+
+ [ Wolfgang Schweer ]
+ * Add policies files for Firefox-ESR and Thunderbird to fix the TLS/SSL setup.
+This makes sure that the Debian-Edu_rootCA.crt file gets installed as
+trusted certificate for Firefox-ESR and Thunderbird. (Already fixed in
+Bullseye.)
+- Add share/firefox-esr/distribution/policies.json (Closes: #944450).
+- Add lib/thunderbird/distribution/policies.json (Closes: #955978).
+- Adjust Makefile accordingly.
+
+ -- Holger Levsen Thu, 16 Apr 2020 02:34:38 +0200
+
debian-edu-config (2.10.65+deb10u4) buster; urgency=medium
[ Dominik George ]
diff -Nru debian-edu-config-2.10.65+deb10u4/lib/thunderbird/distribution/policies.json debian-edu-config-2.10.65+deb10u5/lib/thunderbird/distribution/policies.json
--- debian-edu-config-2.10.65+deb10u4/lib/thunderbird/distribution/policies.json 1970-01-01 01:00:00.0 +0100
+++ debian-edu-config-2.10.65+deb10u5/lib/thunderbird/distribution/policies.json 2020-04-16 02:34:30.0 +0200
@@ -0,0 +1,11 @@
+{
+ "policies": {
+"Certificates": {
+ "ImportEnterpriseRoots": true,
+ "Install": [
+"/etc/ssl/certs/Debian-Edu_rootCA.crt"
+ ]
+}
+ }
+}
+
diff -Nru debian-edu-config-2.10.65+deb10u4/Makefile debian-edu-config-2.10.65+deb10u5/Makefile
--- debian-edu-config-2.10.65+deb10u4/Makefile 2020-01-30 16:34:52.0 +0100
+++ debian-edu-config-2.10.65+deb10u5/Makefile 2020-04-16 02:34:30.0 +0200
@@ -161,6 +161,7 @@
nbd-server/conf.d/debian-edu.conf
LIBFILES = \
+ thunderbird/distribution/policies.json \
mime/packages/debian-edu-mailcap
SYSCONFSCRIPTS = \
@@ -246,6 +247,7 @@
install -d $(DESTDIR)$(ldapdir)
install -d $(DESTDIR)$(dhcpdir)
install -d $(DESTDIR)$(mailcapdir)
+ install -d $(DESTDIR)$(libdir)
# program's manpages are autodetected.
set -e ; for prog in $(PROGS); do \
@@ -399,6 +401,7 @@
share/debian-edu-config/pam-config-mkhomedir \
share/debian-edu-config/pam-config-nopwdchange \
share/debian-edu-config/pam-nopwdchange.py \
+ share/firefox-esr/distribution/policies.json \
; do \
$(INSTALL_DATA) $$f $(DESTDIR)/usr/$$f ; \
done
diff -Nru debian-edu-config-2.10.65+deb10u4/share/firefox-esr/distribution/policies.json debian-edu-config-2.10.65+deb10u5/share/firefox-esr/distribution/policies.json
--- debian-edu-config-2.10.65+deb10u4/share/firefox-esr/distribution/policies.json 1970-01-01 01:00:00.0 +0100
+++ debian-edu-config-2.10.65+deb10u5/share/firefox-esr/distribution/policies.json 2020-04-16 02:34:30.0 +0200
@@ -0,0 +1,12 @@
+{
+ "policies": {
+"Certificates": {
+ "ImportEnterpriseRoots": true,
+ "Install": [
+"/etc/ssl/certs/Debian-Edu_rootCA.crt"
+ ]
+},
+"NewTabPage": false,
+"OverrideFirstRunPage": ""
+ }
+}
\ Kein Zeilenumbruch am Dateiende.
signature.asc
Description: PGP signature
Bug#956703: linux-image-5.5: 5.5 kernel seems to break pulseaudio HDMI detection
On Tue, Apr 14, 2020 at 02:06:30PM +0100, Simon John wrote: > Package: src:linux > Version: 5.5.13-2 > > Booting into 5.5 on Sid gives me no audio out via HDMI. > HDMI audio seems fixed for me with 5.5.17, recently uploaded to unstable. Is it better for you?
Bug#864602: Double free or corruption error/segfault when trying to restore files from a specific partition
Hello Aleksey, since you tracked down the issue, were you able to solve it? Best and thanks, Simon
Bug#956860: ceph 14.x packages lost init script
Package: ceph-base Version: 14.2.7-1~bpo10+1 First of all thanks for the high activity in packaging recent versions of ceph, lately! ceph-base (or ceph) binary packages were supplying /etc/init.d/ceph, but beginning with 14.x versions neither of ceph binary packages seems to provide /etc/init.d/ceph any longer. Could you please consider to keep packaging a working init script file?
Bug#956131: [live-build] boot failure, broken bootloaders when not using syslinux
El 8/4/20 a las 17:42, jnq...@gmail.com escribió: Oh, one more thing I mean to say, @adrian, can you please confirm that this installation of a live-build (?) image in this HP system does not in fact include the /.disk/ files. Moving to a /.disk/info/ based detection is of course not going to improve things in that situation if the file exists in it anyway. I'm sure you probably thought of this, but I did not notice any explicit mention in your discussion in #924053... I have saved the original laptop partitions into my mediapc but I'm not sure I'm going to check on those on the mid-term. I guess there was not /.disk/ folder there but I cannot confirm it. On Wed, 2020-04-08 at 16:05 +0100, jnq...@gmail.com wrote: Oh, quick addition of something I forgot to put in the below message: So in the discussion of #924053 it was suggested that the /.disc/info based solution would only work for ISO/ISO-hybrid images because this file was created by xorriso. I added a comment just now pointing out that in fact this file is created by the binary_disc script, which generates it for iso, iso-hybrid and hdd image types. It does not create any such info for netboot and tar images types, though. I do not expect the tar image will be booted will it? and thus there's no concern there? I really do not know all that much about netboot, so I do not know whether or not there is a problem there. On Wed, 2020-04-08 at 15:56 +0100, jnq...@gmail.com wrote: Hi, Okay, so I've just take a cursory look at your liveid stuff which also led me to #924053 where you've already brought up the EFI failure side of things. I'll limit my response here (this bug report discussion) to matters relating to simply fixing the broken ability to get bootable images; discussion of a unique-disc identification solution can take place separately. To fix the issue of broken EFI booting when syslinux is not used (and thus binary_syslinux was not put in place /live/vmlinuz), I was intending to solve by moving creation of short filename kernel files out of binary_syslinux into somewhere common. The first problem with this though is that alone of course it is not enough because it does not cover the `/live/vmlinuz1` multi-flavour case, so a change to binaru_grub-efi would also be needed in order to dynamically change the searched for file to /live/vmlinuz1 where appropriate. However, I now understand from reading #924053 that although this would fix things in all/most cases, it's at risk of breaking for odd situations like your HP laptop case. Using /.disc/info as the searched for file as proposed in #924053 is much a better solution. My current intention is to take the patch of yours provided in #924053 that makes this change, though with a tweaked commit message (I think the problem is EFI specific not Secure Boot specific), and submit it in an MR, along with the fix for grub-pc, and some additional loosely related work, in one or more MRs. While the concept of correctly identifying discs (aka liveid type stuff) is interesting and of some potential value, priority should be given to simply fixing the ability to create working images first and foremost. I will have the patches mark this bug and #924053 as closed, and leave you to create a new wishlist bug to propose or re-start discussion of the unique-disc identification stuff as you wish. Regards, Lyndon On Wed, 2020-04-08 at 09:40 +0200, adrian15sgd wrote: I think what you need is liveid. https://github.com/rescatux/liveid Here you can find the technical details and commits: https://github.com/rescatux/liveid/blob/master/LIVEID_LIVE_BUILD_IMPLEMENTATION_1.md That way you won't longer depend on arbitrary files such as vmlinuz. Feedback is welcome. P.S.: I was going to do proper merge requests in about 5 or 6 months later but here you are. adrian15 El 8/4/20 a las 1:02, jnq...@gmail.com escribió: update: 1) from my notes, in fact I'd gone back as far as v5.0 confirming the presence of the grub-pc failure. 2) I've noticed the presence of the fixed path '/live/vmlinuz' in binary_grub-efi, and with a hack to have this replaced with the long name '/live/vmlinuz-4.19.0-8-amd64' this also fixes the EFI side of the problem, so that explains how the EFI stuff ends up checking that fixed /live/vmlinuz' path and presents an alternate opportunity for a fix. It seems the author of the EFI live-build functionality only tested it with syslinux.
Bug#956131: [live-build] boot failure, broken bootloaders when not using syslinux
El 8/4/20 a las 17:05, jnq...@gmail.com escribió: Oh, quick addition of something I forgot to put in the below message: So in the discussion of #924053 it was suggested that the /.disc/info based solution would only work for ISO/ISO-hybrid images because this file was created by xorriso. I added a comment just now pointing out that in fact this file is created by the binary_disc script, which generates it for iso, iso-hybrid and hdd image types. It does not create any such info for netboot and tar images types, though. I do not expect the tar image will be booted will it? and thus there's no concern there? I really do not know all that much about netboot, so I do not know whether or not there is a problem there. I'm neither an expert on netboot so I cannot advise. On Wed, 2020-04-08 at 15:56 +0100, jnq...@gmail.com wrote: Hi, Okay, so I've just take a cursory look at your liveid stuff which also led me to #924053 where you've already brought up the EFI failure side of things. I'll limit my response here (this bug report discussion) to matters relating to simply fixing the broken ability to get bootable images; discussion of a unique-disc identification solution can take place separately. To fix the issue of broken EFI booting when syslinux is not used (and thus binary_syslinux was not put in place /live/vmlinuz), I was intending to solve by moving creation of short filename kernel files out of binary_syslinux into somewhere common. The first problem with this though is that alone of course it is not enough because it does not cover the `/live/vmlinuz1` multi-flavour case, so a change to binaru_grub-efi would also be needed in order to dynamically change the searched for file to /live/vmlinuz1 where appropriate. However, I now understand from reading #924053 that although this would fix things in all/most cases, it's at risk of breaking for odd situations like your HP laptop case. Using /.disc/info as the searched for file as proposed in #924053 is much a better solution. My current intention is to take the patch of yours provided in #924053 that makes this change, though with a tweaked commit message (I think the problem is EFI specific not Secure Boot specific), and submit it in an MR, along with the fix for grub-pc, and some additional loosely related work, in one or more MRs. While the concept of correctly identifying discs (aka liveid type stuff) is interesting and of some potential value, priority should be given to simply fixing the ability to create working images first and foremost. I will have the patches mark this bug and #924053 as closed, and leave you to create a new wishlist bug to propose or re-start discussion of the unique-disc identification stuff as you wish. Regards, Lyndon On Wed, 2020-04-08 at 09:40 +0200, adrian15sgd wrote: I think what you need is liveid. https://github.com/rescatux/liveid Here you can find the technical details and commits: https://github.com/rescatux/liveid/blob/master/LIVEID_LIVE_BUILD_IMPLEMENTATION_1.md That way you won't longer depend on arbitrary files such as vmlinuz. Feedback is welcome. P.S.: I was going to do proper merge requests in about 5 or 6 months later but here you are. adrian15 El 8/4/20 a las 1:02, jnq...@gmail.com escribió: update: 1) from my notes, in fact I'd gone back as far as v5.0 confirming the presence of the grub-pc failure. 2) I've noticed the presence of the fixed path '/live/vmlinuz' in binary_grub-efi, and with a hack to have this replaced with the long name '/live/vmlinuz-4.19.0-8-amd64' this also fixes the EFI side of the problem, so that explains how the EFI stuff ends up checking that fixed /live/vmlinuz' path and presents an alternate opportunity for a fix. It seems the author of the EFI live-build functionality only tested it with syslinux.
Bug#956131: [live-build] boot failure, broken bootloaders when not using syslinux
El 8/4/20 a las 16:56, jnq...@gmail.com escribió: Hi, Okay, so I've just take a cursory look at your liveid stuff which also led me to #924053 where you've already brought up the EFI failure side of things. I'll limit my response here (this bug report discussion) to matters relating to simply fixing the broken ability to get bootable images; discussion of a unique-disc identification solution can take place separately. I see. To fix the issue of broken EFI booting when syslinux is not used (and thus binary_syslinux was not put in place /live/vmlinuz), I was intending to solve by moving creation of short filename kernel files out of binary_syslinux into somewhere common. The first problem with this though is that alone of course it is not enough because it does not cover the `/live/vmlinuz1` multi-flavour case, so a change to binaru_grub-efi would also be needed in order to dynamically change the searched for file to /live/vmlinuz1 where appropriate. You should also know that current isolinux/syslinux supports booting from long filenames. So we could ditch using short 8.3 names for the kernels. This problem about having to update binary_grub-efi for searching for long names would arise anyways. However, I now understand from reading #924053 that although this would fix things in all/most cases, it's at risk of breaking for odd situations like your HP laptop case. Using /.disc/info as the searched for file as proposed in #924053 is much a better solution. It collides with Ubuntu live usbs which also have /.disc/info but it would be a quick and easy fix for the current situation where HP laptop are involved. My current intention is to take the patch of yours provided in #924053 that makes this change, though with a tweaked commit message (I think the problem is EFI specific not Secure Boot specific), and submit it in an MR, along with the fix for grub-pc, and some additional loosely related work, in one or more MRs. The Secure Boot code works from an EFI sort-of-ramdisk so it needs to find its own root somehow. That's why it was Secure Boot specific. While the concept of correctly identifying discs (aka liveid type stuff) is interesting and of some potential value, priority should be given to simply fixing the ability to create working images first and foremost. I will have the patches mark this bug and #924053 as closed, and leave you to create a new wishlist bug to propose or re-start discussion of the unique-disc identification stuff as you wish. I don't think your solution is optimal (because you are postponing the actual fact that every live cd cannot detect itself). Liveid let's you find the correct live cd. I agree that if you finally add your code it could cose #924053 so that you force me to submit a liveid merge request. adrian15 Regards, Lyndon On Wed, 2020-04-08 at 09:40 +0200, adrian15sgd wrote: I think what you need is liveid. https://github.com/rescatux/liveid Here you can find the technical details and commits: https://github.com/rescatux/liveid/blob/master/LIVEID_LIVE_BUILD_IMPLEMENTATION_1.md That way you won't longer depend on arbitrary files such as vmlinuz. Feedback is welcome. P.S.: I was going to do proper merge requests in about 5 or 6 months later but here you are. adrian15 El 8/4/20 a las 1:02, jnq...@gmail.com escribió: update: 1) from my notes, in fact I'd gone back as far as v5.0 confirming the presence of the grub-pc failure. 2) I've noticed the presence of the fixed path '/live/vmlinuz' in binary_grub-efi, and with a hack to have this replaced with the long name '/live/vmlinuz-4.19.0-8-amd64' this also fixes the EFI side of the problem, so that explains how the EFI stuff ends up checking that fixed /live/vmlinuz' path and presents an alternate opportunity for a fix. It seems the author of the EFI live-build functionality only tested it with syslinux.
Bug#956131: [live-build] boot failure, broken bootloaders when not using syslinux
I suspect this would break Secure Boot support but it's only a guess. El 8/4/20 a las 2:23, jnq...@gmail.com escribió: update: I've just tried adding --prefix=/boot/grub to the grub-mkimage command in binary_iso (which should really be done in binary_grub-pc) that generates the core_img file that becomes part of grub_eltorito, and success! So now that I know how fundamentally to fix the problems, I'll follow up soon with patches.
Bug#895686: My ancient installation is mis-dated again.
bss@monster % installation-birthday --force I: Installation date: 2018-04-15 /usr/bin/installation-birthday:92: DeprecationWarning: dist() and linux_distribution() functions are deprecated in Python 3.5 distname=platform.linux_distribution()[0].title(), 0 0 | | |___| 0 |~ ~ ~ ~ ~ ~| 0 | | | | ___|__|___|___|__ |/\/\/\/\/\/\/\/\/\/\/\/| 0 | H a p p y | 0 | |/\/\/\/\/\/\/\/\/\/\/\/| | _|___|___|___|__ |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/| | | | B i r t h d a y! ! ! | | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ | |___| Congratulations, your Debian system "monster" was installed 2 year(s) ago today! Best wishes, Your local system administrator bss@monster % stat /var/lib/vim File: /var/lib/vim Size: 12 Blocks: 0 IO Block: 4096 directory Device: 3ah/58d Inode: 353 Links: 1 Access: (0755/drwxr-xr-x) Uid: (0/root) Gid: (0/root) Access: 2020-04-14 07:39:32.480422695 -0500 Modify: 2007-12-17 21:08:03.0 -0600 Change: 2011-05-06 15:21:12.74126 -0500 Birth: - --- I think somehow taking into account /var/lib/vim got reverted / back-leveled ? -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Bug#956661: PEBKAC
Sorry for this misleading report. The problem lay elsewhere and had no direct relationship to initramfs-tools.
Bug#515634: python-yaml: YAML loader complains about non-unique anchors
The proposed change in https://github.com/yaml/pyyaml/pull/394 resolves this issue. Scott K signature.asc Description: This is a digitally signed message part.
Bug#956859: [gnome-tweaks] gnome-tweaks needs gnome-shell-extension-prefs
Package: gnome-tweaks Version: 3.34.0-3 Severity: normal --- Please enter the report below this line. --- The program "gnome-tweaks" requires the program "gnome-shell-extension-prefs", but the package of the former doesn't have the later as dependency, so the user is unable to configure the preferences of the extensions installed in the system, unless (s)he manually installs it. --- System information. --- Architecture: Kernel: Linux 5.5.0-1-amd64 Debian Release: bullseye/sid 500 unstable-debug debug.mirrors.debian.org 500 unstable ftp.debian.org 500 suldr www.bchemnet.com 500 stable repo.skype.com 500 stable linux.teamviewer.com 500 stable dl.google.com --- Package information. --- Depends (Version) | Installed -+-=== python3:any | gsettings-desktop-schemas (>= 3.28) | 3.36.0-1 gnome-settings-daemon | 3.36.0-1 gnome-shell-common (>= 3.24) | 3.36.1-5 mutter-common | 3.36.1-4 python3-gi (>= 3.10) | 3.36.0-2 gir1.2-gtk-3.0 (>= 3.12) | 3.24.18-1 gir1.2-gnomedesktop-3.0 (>= 3.30) | 3.36.1-2 gir1.2-handy-0.0 | 0.0.13-2 gir1.2-soup-2.4 | 2.70.0-1 gir1.2-notify-0.7 | 0.7.9-1 gir1.2-glib-2.0 (>= 1.58) | 1.64.1-1 gir1.2-pango-1.0 | 1.44.7-3 Package's Recommends field is empty. Package's Suggests field is empty.
Bug#956858: firmware-b43-installer.postinst returns with error
Package: firmware-b43-installer Version: 1:019-5 Severity: normal Dear Maintainer, during update to the latest version 1:019-5, firmware-b43-installer.postinst returned with an error while trying to delete the old firmware. /var/lib/dpkg/info/firmware-b43-installer.postinst: Deleting old extracted firmware... rm: Removing '/lib/firmware/b43/lp0initvals14.fw' is not possible. File or directory not found. [snip a lot more errors] As a result, the firmware could not be loaded during boot. It seems that, for whatever reason, /lib/firmware/b43 was left behind with only the file 'firmware-b43-installer.catalog' in it during the update. This caused the postinst script to return with the error code 123 when trying to remove the old, non-existing firmware files. Removing (renaming) /lib/firmware/b43 and re-installing firmware-b43-installer fixed the problem. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.5.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages firmware-b43-installer depends on: ii b43-fwcutter 1:019-5 ii bzip21.0.8-2 ii ca-certificates 20190110 ii wget 1.20.3-1+b2 firmware-b43-installer recommends no packages. firmware-b43-installer suggests no packages. -- no debconf information
Bug#956605: texlive-bin: FTBFS on powerpc & sparc64
Control: reopen -1 Control: found -1 2020.20200327.54578-3 Am 13.04.2020 um 16:35 teilte Hilmar Preusse mit: > Dear Maintainer, > >* What led up to the situation? > May first attempt was wrong, the d/rules files needs to be fixed. Still tries to do a "make -j32". make[1]: Leaving directory '/<>' dh_auto_build -a -O--builddirectory=Work cd Work && make -j32 H. -- sigfault #206401 http://counter.li.org signature.asc Description: OpenPGP digital signature
Bug#956857: linux-image-5.5.0-1-amd64: 5.5 kernel seems to break pulseaudio HDMI detection
Package: src:linux
Version: 5.5.13-2
Severity: normal
Dear Maintainer,
Booting into 5.5 on Sid gives me no audio out via HDMI.
In Gnome Settings the GP108 isn't even listed until I run pulseaudio -k,
then I can select it and audio works again for an hour or so, then I
have to kill pulseaudio again to get it back.
Booting back into 5.4 solves the problem, confirmed by booting back into
5.5 and the problem is back again, nothing else is different.
Not using proprietary Nvidia drivers or anything obvious.
-- Package-specific info:
** Version:
Linux version 5.5.0-1-amd64 (debian-ker...@lists.debian.org) (gcc
version 9.3.0 (Debian 9.3.0-8)) #1 SMP Debian 5.5.13-2 (2020-03-30)
** Command line:
BOOT_IMAGE=/vmlinuz-5.5.0-1-amd64
root=UUID=2b82e6c4-442e-4700-a246-3b5c37a722b5 ro quiet
slab_common.usercopy_fallback=y
** Tainted: OE (12288)
* externally-built ("out-of-tree") module was loaded
* unsigned module was loaded
** Kernel log:
Unable to read kernel log; any relevant messages should be attached
** Model information
sys_vendor: Dell Inc.
product_name: Precision T5610
product_version: 00
chassis_vendor: Dell Inc.
chassis_version:
bios_vendor: Dell Inc.
bios_version: A19
board_vendor: Dell Inc.
board_name: 0WN7Y6
** Loaded modules:
vboxnetadp(OE)
vboxnetflt(OE)
vboxdrv(OE)
bridge
stp
llc
rfkill
binfmt_misc
jfs
intel_rapl_msr
intel_rapl_common
snd_hda_codec_hdmi
sb_edac
x86_pkg_temp_thermal
intel_powerclamp
kvm_intel
snd_hda_codec_realtek
snd_hda_codec_generic
ledtrig_audio
pktcdvd
kvm
snd_hda_intel
snd_intel_dspcfg
dcdbas
mei_wdt
snd_hda_codec
intel_cstate
dell_smm_hwmon
hwmon_vid
coretemp
snd_hda_core
joydev
intel_uncore
snd_hwdep
snd_pcm
intel_rapl_perf
snd_timer
mei_me
snd
iTCO_wdt
iTCO_vendor_support
serio_raw
pcspkr
sg
watchdog
mei
soundcore
evdev
nft_ct
nf_conntrack
nf_defrag_ipv6
nf_defrag_ipv4
nf_tables
nfsd
nfnetlink
loop
auth_rpcgss
parport_pc
ppdev
nfs_acl
lockd
lp
parport
grace
sunrpc
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
btrfs
blake2b_generic
zstd_decompress
zstd_compress
essiv
authenc
dm_crypt
dm_mod
raid10
raid456
async_raid6_recov
async_memcpy
async_pq
async_xor
async_tx
xor
raid6_pq
libcrc32c
crc32c_generic
raid1
raid0
multipath
linear
md_mod
uas
usb_storage
hid_generic
usbhid
hid
sr_mod
cdrom
sd_mod
nouveau
crct10dif_pclmul
crc32_pclmul
crc32c_intel
ghash_clmulni_intel
vfio_pci
vfio_virqfd
vfio_iommu_type1
vfio
irqbypass
mxm_wmi
video
i2c_algo_bit
ttm
ahci
drm_kms_helper
xhci_pci
libahci
xhci_hcd
aesni_intel
libata
ehci_pci
ehci_hcd
drm
e1000e
crypto_simd
usbcore
scsi_mod
cryptd
glue_helper
lpc_ich
ptp
i2c_i801
mfd_core
pps_core
usb_common
wmi
button
** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Xeon E7 v2/Xeon E5 v2/Core
i7 DMI2 [8086:0e00] (rev 04)
Subsystem: Dell Xeon E7 v2/Xeon E5 v2/Core i7 DMI2 [1028:05d3]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR-
Interrupt: pin A routed to IRQ 0
NUMA node: 0
Capabilities: [90] Express (v2) Root Port (Slot-), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0
ExtTag- RBE+
DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr-
TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x4, ASPM L1, Exit Latency L1
<16us
ClockPM- Surprise+ LLActRep+ BwNot+ ASPMOptComp+
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed unknown (downgraded), Width x0 (downgraded)
TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt-
RootCap: CRSVisible-
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna-
CRSVisible-
RootSta: PME ReqID , PMEStatus- PMEPending-
DevCap2: Completion Timeout: Range BCD, TimeoutDis+, NROPrPrP-,
LTR-
10BitTagComp-, 10BitTagReq-, OBFF Not Supported,
ExtFmt-, EETLPPrefix-
EmergencyPowerReduction Not Supported,
EmergencyPowerReductionInit-
FRS-, LN System CLS Not Supported, TPHComp+,
ExtTPHComp-, ARIFwd-
AtomicOpsCap: Routing- 32bit+ 64bit+ 128bitCAS+
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF
Disabled ARIFwd-
AtomicOpsCtl: ReqEn- EgressBlck-
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-
Transmit Margin: Normal Operating Range, EnterModifiedCompliance-
ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current
Bug#956856: w3m-el fails to install
Package: w3m-el Version: 1.4.632+0.20181112-2 Severity: important Dear Maintainer, In attempting to install w3m-el I see: Install w3m-el for emacs install/w3m-el: byte-compiling for emacs, logged in /tmp/elc.9ZAzScQdF0F8 ERROR: install script from w3m-el package failed dpkg: error processing package w3m-el (--configure): installed w3m-el package post-installation script subprocess returned error exit status 1 In the emacs compile log I see: emacs -q -no-site-file -batch -l __myinit.el -l w3mhack.el . -f w3mhack-generate-load-file emacs -q -no-site-file -batch -l __myinit.el -f batch-byte-compile bookmark-w3m.el w3m-antenna.el w3m-bookmark.el w3m-bug.el w3m-ccl.el w3m-cookie.el w3m-dtree.el w3m-ems.el w3m-favicon.el w3m-fb.el w3m-filter.el w3m-form.el w3m-hist.el w3m-image.el w3m-lnum.el w3m-mail.el w3m-namazu.el w3m-perldoc.el w3m-proc.el w3m-rss.el w3m-save.el w3m-search.el w3m-session.el w3m-symbol.el w3m-tabmenu.el w3m-util.el w3m-weather.el w3m.el mime-w3m.el octet.el In toplevel form: w3m-antenna.el:49:1:Error: Wrong type argument: stringp, nil In toplevel form: w3m-bookmark.el:40:1:Error: Wrong type argument: stringp, nil In toplevel form: w3m-cookie.el:45:1:Error: Wrong type argument: stringp, nil In toplevel form: w3m-dtree.el:35:1:Error: Wrong type argument: stringp, nil In toplevel form: w3m-filter.el:40:1:Error: Wrong type argument: stringp, nil And so on. w3m-el-snapshot installs successfully. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (300, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages w3m-el depends on: ii apel 10.8+0.20120427-21 ii dpkg 1.19.7 ii emacs1:26.3+1-1 ii emacs-lucid [emacs] 1:26.3+1-1 ii emacsen-common 3.0.4 ii install-info 6.7.0.dfsg.2-5 ii w3m 0.5.3-37+b1 Versions of packages w3m-el recommends: ii apel 10.8+0.20120427-21 ii flim 1:1.14.9+0.20120428-24 Versions of packages w3m-el suggests: ii bzip21.0.8-2 pn discount | libtext-markdown-perl | markdown ii imagemagick 8:6.9.10.23+dfsg-2.1+b2 ii imagemagick-6.q16 [imagemagick] 8:6.9.10.23+dfsg-2.1+b2 pn libmoe1.5 pn mule-ucs pn namazu2 pn perl-doc ii poppler-utils [xpdf-utils] 0.71.0-6 pn ppthtml pn wv pn xlhtml -- no debconf information
Bug#624438: network-manager will not connect to an USB WiFi
Package: network-manager Version: 1.14.6-2+deb10u1 Followup-For: Bug #624438 Dear Maintainer, * What led up to the situation Searching for an USB WiFi for Stretch, I found that the Panda PAU05 (PAU06) worked very nicely, provided that I backported the device driver from Buster (testing). Since Buster has been promoted to Stable, the devices no longer work. * What exactly did you do (or not do) that was effective (or ineffective) root@kilroy:/# uname -a Linux kilroy 4.19.0-8-amd64 #1 SMP Debian 4.19.98-1 (2020-01-26) x86_64 GNU/Linux root@kilroy:/# lsusb Bus 001 Device 002: ID 8087:8001 Intel Corp. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 004: ID 05e3:0620 Genesys Logic, Inc. Bus 003 Device 003: ID 05e3:0620 Genesys Logic, Inc. Bus 003 Device 002: ID 05e3:0620 Genesys Logic, Inc. Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 002 Device 007: ID 148f:5372 Ralink Technology, Corp. RT5372 Wireless Adapter Bus 002 Device 005: ID 2341:003d Arduino SA Bus 002 Device 003: ID 046d:c52b Logitech, Inc. Unifying Receiver Bus 002 Device 008: ID 05a3:9230 ARC International Camera Bus 002 Device 006: ID 05e3:0610 Genesys Logic, Inc. 4-port hub Bus 002 Device 004: ID 05e3:0610 Genesys Logic, Inc. 4-port hub Bus 002 Device 002: ID 05e3:0610 Genesys Logic, Inc. 4-port hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub root@kilroy:/# /sbin/iwconfig enp2s0no wireless extensions. enp3s0no wireless extensions. lono wireless extensions. wlx9cefd5fdec63 IEEE 802.11 ESSID:"C" Mode:Managed Frequency:2.412 GHz Access Point: Not-Associated Tx-Power=20 dBm Retry short long limit:2 RTS thr:off Fragment thr:off Encryption key:off Power Management:off root@kilroy:/# lsmod |grep rt2800usb rt2800usb 32768 0 rt2x00usb 24576 1 rt2800usb rt2800lib 118784 1 rt2800usb rt2x00lib 57344 3 rt2800usb,rt2x00usb,rt2800lib usbcore root@kilroy:~$ nmcli device wifi list IN-USE SSID MODE CHAN RATE SIGNAL BARS SECURITY root@kilroy:~$ nmcli connection show NAMEUUID TYPE DEVICE New 802-11-wireless connection 6a704f1b-e178-4602-beed-c77d34b298dd wifi -- Wired connection 1 bd80662b-4772-47f8-8303-d4e23d188df6 ethernet -- root@kilroy:/# /sbin/iw list Wiphy phy0 max # scan SSIDs: 4 max scan IEs length: 2257 bytes max # sched scan SSIDs: 0 max # match sets: 0 max # scan plans: 1 max scan plan interval: -1 max scan plan iterations: 0 Retry short long limit: 2 Coverage class: 0 (up to 0m) Device supports RSN-IBSS. Supported Ciphers: * WEP40 (00-0f-ac:1) * WEP104 (00-0f-ac:5) * TKIP (00-0f-ac:2) * CCMP-128 (00-0f-ac:4) * CCMP-256 (00-0f-ac:10) * GCMP-128 (00-0f-ac:8) * GCMP-256 (00-0f-ac:9) Available Antennas: TX 0 RX 0 Supported interface modes: * IBSS * managed * AP * AP/VLAN * monitor * mesh point Band 1: Capabilities: 0x2fe HT20/HT40 SM Power Save disabled RX Greenfield RX HT20 SGI RX HT40 SGI TX STBC RX STBC 2-streams Max AMSDU length: 3839 bytes No DSSS/CCK HT40 Maximum RX AMPDU length 65535 bytes (exponent: 0x003) Minimum RX AMPDU time spacing: 2 usec (0x04) HT TX/RX MCS rate indexes supported: 0-15, 32 Bitrates (non-HT): * 1.0 Mbps * 2.0 Mbps (short preamble supported) * 5.5 Mbps (short preamble supported) * 11.0 Mbps (short preamble supported) * 6.0 Mbps * 9.0 Mbps * 12.0 Mbps * 18.0 Mbps * 24.0 Mbps * 36.0 Mbps * 48.0 Mbps * 54.0 Mbps Frequencies: * 2412 MHz [1] (20.0 dBm) * 2417 MHz [2] (20.0 dBm) * 2422 MHz [3] (20.0 dBm) * 2427 MHz [4] (20.0 dBm) * 2432 MHz [5] (20.0 dBm) * 2437 MHz [6] (20.0 dBm) * 2442 MHz [7] (20.0 dBm) * 2447 MHz [8] (20.0 dBm) * 2452 MHz [9] (20.0 dBm)
Bug#955005: Relax requirements to copy copyright notices into d/copyright
Hello, On Fri 10 Apr 2020 at 10:45PM +02, Guillem Jover wrote: > On Tue, 2020-04-07 at 17:18:27 -0700, Sean Whitton wrote: >> On Wed 08 Apr 2020 at 01:18AM +02, Guillem Jover wrote: >> >> +The copyright information for files in a package must be copied >> >> +verbatim into ``/usr/share/doc/package/copyright``, when >> > ^ Shouldn't this and other instances >> > of "package" be marked as replaceable text? >> >> Possibly, though that's an issue with the existing Policy text not this >> patch -- perhaps I should just find and replace after applying the patch >> from this bug? > > Ah right, thought this was specific to this drafting. Sounds good. Now done. >> > I'm assuming the entire list is supposed to hold at the same time? If >> > so perhaps adding an «and» here would make this completely unambiguous. >> >> Hmm, thanks for the feedback, but I don't think "a; b; and c" is >> ambiguous in English, and "a; and b; and c" would be an irregular usage. > > I guess what I found ambiguous is that "; and" in English does not > necessarily have a logic connotation. So one can read it as "item a; > item b; and item c" where the and is just there to introduce the next > item instead of specifying the content is ANDed. The “when” should > make it somewhat clear, but on a quick read it just made me doubt. > > Take the example list in ch-source.rst > “Main building script: ``debian/rules``”: > > ,--- > There are sometimes good reasons to use a different approach. For > example, the standard tools for packaging software written in some > languages may use another tool; some rarer packaging patterns, such as > multiple builds of the same software with different options, are easier to > express with other tools; and a packager working on a different packaging > helper might want to use their tool. > `--- > > Which I'd take it as an “and” for the list, not for its contents holding > true at the same time. :) > > With the context I guess it is somewhat clearish, but I'd really like > to see text that is completely unambiguous for stuff that is normative. > >> If this really does need clarification it would be better to add "all of >> the following" or something before the list. > > Yes, clarifying before the list starts would work too, and I thought I > mentioned it in my reply, but apparently not. Now done. Thanks again for the feedback. -- Sean Whitton signature.asc Description: PGP signature
Bug#956855: consider reducing toolchain bootstrap stages
Source: cross-toolchain-base
Version: 45
Severity: wishlist
Tags: patch moreinfo
I'm not sure anymore who told me, but glibc has a build_many_glibcs.py
script and it does the toolchain bootstrap dance with fewer stages than
Debian (i.e. cross-toolchain-base and rebootstrap) does. The current
Debian toolchain bootstrap looks like this:
* binutils
* linux-libc-dev
* gcc stage1 (bare metal)
* glibc stage1 (headers + stub libc.so)
* gcc stage2
* glibc stage2 (libc without systemtap and other optional features)
* gcc stage3 (libc-integrated cross compiler)
* gcc rtlibs (runtime libraries for the cross compiler)
The assertion is that we can skip glibc stage1 and gcc stage2 and go
directly from gcc stage1 to glibc stage2.
I've implemented this in rebootstrap and it seems to work reasonably
well for a number of architectures. I've not run it on the full test
matrix yet. Some observations on rebootstrap:
* musl-linux-any already works like this since a while.
* hurd-any formerly needed libihash-dev for libpthread, but no longer
does. This sequence also works on hurd-i386.
* I've had success with arm64, armel, armhf, m68k, mips (nobiarch),
mipsel (nobiarch) and ppc64el thus far. Notably, these all lack
multilibs and I'm still sorting out multilib issues.
* I cannot tell about kfreebsd-any, since they didn't manage to get the
relevant kernel header source package back into unstable yet.
I've implemented this for cross-toolchain-base (patch attached) and a
performed a successful testbuild. Using diffoscope to compare the
resulting packages with the ones from the archive was not a useful thing
to do as the build-ids changed.
So what do you think about going to fewer stages? I'd like to solicit
explicit feedback from the involved parties:
gcc maintainers / Matthias:
* Do you have any objections to reducing stages?
* Should we delete gcc stage2?
* Should we rename gcc stage3 to gcc stage2?
glibc maintainers / Aurelien:
* Do you have any objections to reducing stages?
* Should we delete glibc stage1?
* Should we rename glibc stage2 to glibc stage1?
* Should we maybe split stage2 into a number of profiles
pkg.glibc.noselinux, pkg.glibc.noxen, pkg.glibc.noalphaev,
pkg.glibc.noxcryptdep?
Due to these open questions, I've tagged the bug moreinfo.
Helmut
diff --minimal -Nru cross-toolchain-base-45/debian/changelog
cross-toolchain-base-45+nmu1/debian/changelog
--- cross-toolchain-base-45/debian/changelog2020-03-22 14:02:54.0
+0100
+++ cross-toolchain-base-45+nmu1/debian/changelog 2020-04-15
11:35:18.0 +0200
@@ -1,3 +1,10 @@
+cross-toolchain-base (45+nmu1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Bootstrap with fewer stages. (Closes: #-1)
+
+ -- Helmut Grohne Wed, 15 Apr 2020 11:35:18 +0200
+
cross-toolchain-base (45) unstable; urgency=medium
* Build using glibc 2.30-2.
diff --minimal -Nru cross-toolchain-base-45/debian/rules
cross-toolchain-base-45+nmu1/debian/rules
--- cross-toolchain-base-45/debian/rules2020-03-22 14:02:01.0
+0100
+++ cross-toolchain-base-45+nmu1/debian/rules 2020-04-15 11:35:18.0
+0200
@@ -343,96 +344,6 @@
ln -sf ${CROSS_GNU_TYPE}-gcov-${VER_GCC_BASE} ${CROSS_GNU_TYPE}-gcov
endef
-$(stamp)build-gcc2.%: $(stamp)init-gcc $(stamp)install-glibc1.%
- @echo START $@
- cd debian/tmp.${CROSS_ARCH}/$(PF)/bin/ && \
- rm -f ${CROSS_GNU_TYPE}-gcc-${VER_GCC_BASE} ${CROSS_GNU_TYPE}-gcc && \
- rm -f ${CROSS_GNU_TYPE}-cpp-${VER_GCC_BASE} ${CROSS_GNU_TYPE}-cpp && \
- rm -f ${CROSS_GNU_TYPE}-gcov-${VER_GCC_BASE} ${CROSS_GNU_TYPE}-gcov
- cd gcc && \
- PATH=${CURDIR}/debian/tmp.${CROSS_ARCH}/$(PF)/bin:${PATH} \
- LD_LIBRARY_PATH=$(call
binutils_ldpath,$*):${CURDIR}/debian/tmp.${CROSS_ARCH}/usr/lib:${CURDIR}/debian/tmp.${CROSS_ARCH}/lib
\
- DH_VERBOSE=1 \
- WITH_SYSROOT=/ \
- WITH_BUILD_SYSROOT=${CURDIR}/debian/tmp.${CROSS_ARCH} \
- DEB_STAGE=stage2 \
- PKG_IGNORE_CURRENTLY_BUILDING=1 \
- BACKPORT=false \
- DEB_BUILD_OPTIONS="$(DEB_BUILD_OPTIONS) nocheck nopgo nolto nohppa64
nojit nonvptx" \
- WITHOUT_LANG="hppa64 jit nvptx" \
- $(if $(filter $(HOST_ARCH),$(CROSS_ARCH)),FORCE_CROSS_LAYOUT=yes
WITH_BOOTSTRAP=off) \
- dpkg-buildpackage -b -uc -us -d
- touch $@
-
-$(stamp)install-gcc2.%: $(stamp)build-gcc2.%
- @echo START $@
- $(call install_gcc)
- dpkg-deb -x libgcc[124]-${CROSS_ARCH}-cross_${DEB_VER_GCC}_all.deb \
- debian/tmp.${CROSS_ARCH}
-ifneq (,$(ARM32_MULTILIBS))
- $(if $(filter $(CROSS_ARCH),armhf), \
- dpkg-deb -x libsfgcc1-${CROSS_ARCH}-cross_${DEB_VER_GCC}_all.deb \
- debian/tmp.${CROSS_ARCH}; \
- dpkg-deb -x
libsfgcc-${VER_GCC_BASE}-dev-${CROSS_ARCH}-cross_${DEB_VER_GCC}_all.deb \
- debian/tmp.${CROSS_ARCH} \
- )
- $(if $(filter
Bug#956819: RFS: cachy/0.3.0-1 [ITP] -- Provide a simple yet effective caching library (Python 3)
Hi Sorry for the noise. For error I send RFS from my job email. That is incorrect. I will owner me using this email. Cheers, -- Emmanuel Arias @eamanu yaerobi.com 0xFA9DEC5DE11C63F1.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Bug#956851: Package supoerseeded by vlc-plugin-base
Thanks, reported in bug #956854 :) S Le 15/04/2020 à 22:28, martin f krafft a écrit : Untitled Package: vlc-plugin-vlsub Version: 0.10.2-2 Severity: normal vlc-plugin-base includes even a newer version of the VLSub plugin. This package can thus, and should thus be removed. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.5.0-rc5-amd64 (SMP w/8 CPU cores) Locale: LANG=en_NZ, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8), LANGUAGE=en_NZ:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages vlc-plugin-vlsub depends on: ii vlc 3.0.8-4+b1 vlc-plugin-vlsub recommends no packages. vlc-plugin-vlsub suggests no packages. -- no debconf information -- .''`. martin f. krafft @martinkrafft : :' : proud Debian developer `. `'` http://people.debian.org/~madduck `- Debian - when you have better things to do than fixing systems
Bug#956854: RM: vlc-plugin-vlsub -- ROM; Merged into vlc itself
Package: ftp.debian.org Severity: normal Thanks See bug #956851 for this
Bug#956853: ITP: python3-apiclient -- Tiny framework for building good API client libraries thanks to urllib3.
Package: wnpp Severity: wishlist Subject: ITP: python3-apiclient -- Tiny framework for building good API client libraries thanks to urllib3. Package: wnpp Owner: Malihe Asemani Severity: wishlist * Package name: python3-apiclient Version : 1.0.4 Upstream Author : , Shazow, Andry Petrov * URL : https://github.com/shazow/apiclient, https://pypi.org/project/apiclient/ * License : MIT Programming Lang: Python Description : Tiny framework for building good API client libraries thanks to urllib3. Tiny framework for building good API client libraries thanks to urllib3 Threadsafely reuses connections with Keep-Alive (via urllib3). Small and easy to understand codebase perfect for extending and building upon. Built-in support for rate limiting and request throttling. Functional examples for the Klout API and the Facebook OpenGraph API. Remark: This package is maintained by Debian Med Packaging Team at https://salsa.debian.org/med-team/python3-apiclient
Bug#956852: ITP: python3-apiclient -- Tiny framework for building good API client libraries thanks to urllib3.
Package: wnpp Severity: wishlist Subject: ITP: python3-apiclient -- Tiny framework for building good API client libraries thanks to urllib3. Package: wnpp Owner: Malihe Asemani Severity: wishlist * Package name: python3-apiclient Version : 1.0.4 Upstream Author : , Shazow, Andry Petrov * URL : https://github.com/shazow/apiclient, https://pypi.org/project/apiclient/ * License : MIT Programming Lang: Python Description : Tiny framework for building good API client libraries thanks to urllib3. Tiny framework for building good API client libraries thanks to urllib3 Threadsafely reuses connections with Keep-Alive (via urllib3). Small and easy to understand codebase perfect for extending and building upon. Built-in support for rate limiting and request throttling. Functional examples for the Klout API and the Facebook OpenGraph API. Remark: This package is maintained by Debian Med Packaging Team at https://salsa.debian.org/med-team/python3-apiclient
Bug#956851: Package supoerseeded by vlc-plugin-base
Package: vlc-plugin-vlsub Version: 0.10.2-2 Severity: normal vlc-plugin-base includes even a newer version of the VLSub plugin. This package can thus, and should thus be removed. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.5.0-rc5-amd64 (SMP w/8 CPU cores) Locale: LANG=en_NZ, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8), LANGUAGE=en_NZ:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages vlc-plugin-vlsub depends on: ii vlc 3.0.8-4+b1 vlc-plugin-vlsub recommends no packages. vlc-plugin-vlsub suggests no packages. -- no debconf information -- .''`. martin f. krafft @martinkrafft : :' : proud Debian developer `. `'` http://people.debian.org/~madduck `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Bug#956850: ncbi-blast+: Please provide /usr/bin/legacy_blast
Package: ncbi-blast+ Version: 2.9.0-4 Severity: normal Hi, I'm aware that language extensions in Debian are not conform to policy. However, as we discussed in https://lists.debian.org/debian-med/2018/06/msg00043.html only stripping the extension is sometimes hard for rdepends of our packages. In this case the lack of blastpgp.pl requires heavy patching of t-coffee which could be avoided if we would provide both versions - legacy_blast.pl and legacy_blast - one of both as symlink. Kind regards and thanks for maintaining ncbi-blast+ Andreas. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (501, 'testing'), (50, 'buildd-unstable'), (50, 'unstable'), (5, 'experimental'), (1, 'buildd-experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=de_DE:de (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ncbi-blast+ depends on: ii libbz2-1.0 1.0.8-2 ii libc6 2.30-4 ii libgcc-s1 10-20200324-1 ii libgomp110-20200324-1 ii liblmdb00.9.24-1 ii libmbedcrypto3 2.16.5-1 ii libmbedtls122.16.5-1 ii libpcre32:8.39-12+b1 ii libstdc++6 10-20200324-1 ii ncbi-data 6.1.20170106+dfsg1-8 ii perl5.30.0-9 ii python3 3.8.2-3 ii zlib1g 1:1.2.11.dfsg-2 ncbi-blast+ recommends no packages. ncbi-blast+ suggests no packages. -- no debconf information
Bug#956414: #956414: Upload a partially fixed version?
On 4/13/20 12:36 AM, Svante Signell wrote: > Hi again, > > I saw that there was some complaints from lintian of the uploaded > version. I've fixed some of them. Upload again? > > BTW: running lintian with the --pedantic flag does not show all issues > as 956...@bugs.debian.org does. Which option(s) trigger all the output > at the link? > > Thanks! > Hi Svante, I think 'lintian -EviI --pedantic --show-overrides' should do that, with some extra info displayed. Cheers, Lorenzo
Bug#956849: retroarch does nothing when statrted from console
Package: retroarch Version: 1.7.3+dfsg1-1 Severity: important Dear Maintainer, running retroarch from text console does nothing, retroarch just stop without saying/complaining nothing. Works fine under X -- System Information: Debian Release: 10.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-0.bpo.4-amd64 (SMP w/6 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=es_CL.UTF-8, LC_CTYPE=es_CL.UTF-8 (charmap=UTF-8), LANGUAGE=es (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages retroarch depends on: ii fonts-dejavu-core 2.37-1 ii libasound21.1.8-1 ii libavcodec58 10:4.1.5-dmo1+deb10u1 ii libavformat58 10:4.1.5-dmo1+deb10u1 ii libavutil56 10:4.1.5-dmo1+deb10u1 ii libc6 2.28-10 ii libdrm2 2.4.97-1 ii libegl1 1.1.0-1 ii libfreetype6 2.9.1-3+deb10u1 ii libgbm1 18.3.6-2+deb10u1 ii libgcc1 1:8.3.0-6 ii libgl11.1.0-1 ii libjack-jackd2-0 [libjack-0.125] 1.9.12~dfsg-2 ii libminiupnpc172.1-1+b1 ii libopenal11:1.19.1-1 ii libpulse0 12.2-4+deb10u1 ii libqt5core5a 5.11.3+dfsg1-1+deb10u3 ii libqt5gui55.11.3+dfsg1-1+deb10u3 ii libqt5widgets55.11.3+dfsg1-1+deb10u3 ii libretro-core-info1.3.6+git20160816-1 ii libsdl2-2.0-0 2.0.9+dfsg1-1 ii libstdc++68.3.0-6 ii libswresample310:4.1.5-dmo1+deb10u1 ii libswscale5 10:4.1.5-dmo1+deb10u1 ii libudev1 241-7~deb10u3 ii libusb-1.0-0 2:1.0.22-2 ii libv4l-0 1.16.3-3 ii libwayland-client01.16.0-1 ii libwayland-cursor01.16.0-1 ii libwayland-egl1 1.16.0-1 ii libx11-6 2:1.6.7-1 ii libx11-xcb1 2:1.6.7-1 ii libxcb1 1.13.1-2 ii libxext6 2:1.3.3-1+b2 ii libxinerama1 2:1.1.4-2 ii libxkbcommon0 0.8.2-1 ii libxv12:1.0.11-1 ii libxxf86vm1 1:1.1.4-1+b2 ii retroarch-assets 1.3.6+git20160731+dfsg1-2 ii zlib1g1:1.2.11.dfsg-1 retroarch recommends no packages. retroarch suggests no packages. -- no debconf information
Bug#956848: ncbi-blast+-legacy: Please provide /usr/bin/blastpgp.pl (including .pl extension)
Package: ncbi-blast+-legacy Version: 2.9.0-4 Severity: normal Hi, I'm aware that language extensions in Debian are not conform to policy. However, as we discussed in https://lists.debian.org/debian-med/2018/06/msg00043.html only stripping the extension is sometimes hard for rdepends of our packages. In this case the lack of blastpgp.pl requires heavy patching of t-coffee which could be avoided if we would provide both versions - blastpgp.pl and blastpgp - one of both as symlink. Kind regards and thanks for maintaining ncbi-blast+-legacy Andreas. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (501, 'testing'), (50, 'buildd-unstable'), (50, 'unstable'), (5, 'experimental'), (1, 'buildd-experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=de_DE:de (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ncbi-blast+-legacy depends on: ii ncbi-blast+ 2.9.0-4 ncbi-blast+-legacy recommends no packages. ncbi-blast+-legacy suggests no packages. -- no debconf information
Bug#956847: freeglut3-dev: Intel OpenGL device driver has unintiated variables
Package: freeglut3-dev Version: 2.8.1-3 Severity: normal Dear Maintainer, * What led up to the situation? Using the diagnostic program Valgrind on a program under development, I got several pages of "uninitated variable" * What exactly did you do (or not do) that was effective (or ineffective)? I compiled an absolute minimum OpenGL (Hello_World) program and tested it with Valgrind. * What was the outcome of this action? Multiple pages of "unitiated write of size (4 or 8) at (address): ??? (in /usr/lig/x86_84-linux-gnu/dri/i965_dri.so) This program was run without change on an AMD machine without error. -- System Information: Debian Release: 10.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-8-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages freeglut3-dev depends on: ii freeglut3 2.8.1-3 ii libgl1-mesa-dev [libgl-dev]18.3.6-2+deb10u1 ii libglu1-mesa-dev [libglu-dev] 9.0.0-2.1+b3 ii libxext-dev2:1.3.3-1+b2 ii libxt-dev 1:1.1.5-1+b3 freeglut3-dev recommends no packages. freeglut3-dev suggests no packages. -- no debconf information
Bug#952200: libvirt-dbus: FTBFS: dh_auto_test: error: make -j4 check VERBOSE=1 returned exit code 2
On Tue, Apr 14, 2020 at 08:25:53PM +0300, Adrian Bunk wrote: > On Sun, Mar 29, 2020 at 10:18:05PM +0200, Andrea Bolognani wrote: > >... > > Adrian, I see you tagged the bug as fixed-upstream: can you please > > share any additional information you might have and that convinced > > you the bug is no longer present upstream? Thanks in advance! > > Sorry for failing to include this information, > please see the commit linked above. Thanks Adrian! I had already tracked down the commit myself in the meantime, and I have prepared an updated libvirt-dbus package that's pending review: https://salsa.debian.org/libvirt-team/libvirt-dbus/-/merge_requests/1 Hopefully we'll be able to upload it soon :) -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: PGP signature
Bug#956840: Acknowledgement (pympress: Raise an error at start)
A workaround is to start it with python3 -m pympress file.pdf It seems there is a conflict between python3.7 (used by default by pympress) and python3.8 (used by most other programs).
Bug#956846: debarchiver: Please make another source-only upload to allow testing migration
Source: debarchiver Version: 0.11.4 Severity: important X-Debbugs-CC: o...@debian.org Dear debarchiver maintainer, Your previous upload of package debarchiver was not source-only upload; as a result, the new verison 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 . 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#956749: Removing support for an arch (cf. bug#956749: odil: FTBFS on mips64el)
Le 15/04/2020 à 11:15, Andreas Tille a écrit : > Hi Julien, > > On Wed, Apr 15, 2020 at 10:19:11AM +0200, Julien Lamy wrote: >> Following the build failures of Odil on mips64el (which never really >> built correctly, due to timeouts), I'd like to remove the support for >> mips64el. From what I've understood, I'll need to change the >> Architectures entries in d/control replacing "any" with everything but >> mips64el (so basically "amd64 arm64 armel armhf i386 mipsel ppc64el >> s390x") and release a new version. > > That's correct. Thanks for the confirmation. The code is ready in the Git repo. Andreas, could you upload? -- Julien signature.asc Description: OpenPGP digital signature
Bug#956795: libpam-systemd: fills the logs with messages about pam_systemd.so
$ ldd /usr/sbin/cron linux-vdso.so.1 (0x7ffdbad7f000) libpam.so.0 => /lib/x86_64-linux-gnu/libpam.so.0 (0x7f9c76d08000) libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x7f9c76cdd000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f9c76b1a000) libaudit.so.1 => /lib/x86_64-linux-gnu/libaudit.so.1 (0x7f9c76aef000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f9c76aea000) libpcre2-8.so.0 => /usr/lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x7f9c76a5a000) /lib64/ld-linux-x86-64.so.2 (0x7f9c76d5f000) libcap-ng.so.0 => /lib/x86_64-linux-gnu/libcap-ng.so.0 (0x7f9c76a5) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f9c76a2f000) $ apt-cache policy libpam0g libpam0g: Installed: 1.3.1-5 Candidate: 1.3.1-5 Version table: *** 1.3.1-5 990 990 http://ftp.it.debian.org/debian testing/main amd64 Packages 101 http://ftp.it.debian.org/debian unstable/main amd64 Packages 100 /var/lib/dpkg/status
Bug#956844: RM: stardict -- RoQA; Orphaned; Upstream Inactive; Affected by dependency removals
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-CC: debian-chinese...@lists.debian.org stard...@packages.debian.org Dear Debian FTP Masters, It seems that package src:stardict became unsupportable given that its upstream has been inactive for several years and that it (build-)depends on several obsolete tools and libraries, including gnome-doc-utils and enchant(1). With the release work of Ubuntu 20.04 LTS largely done, I believe we could remove this package from Debian side now. (Users of Ubuntu 20.04 LTS and Debian 10 can still find stardict in the repos, in case anyone needs it.) -- Regards, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#956845: freehep-graphicsio: New upstream version available
Source: freehep-graphicsio Severity: normal Hi, as explained in bug #956843 the cdk package can not build with all components since some of these need freehep-graphicsio 2.4. This is available at https://github.com/freehep It would be great if all freehep-* packages would be upgraded to their latest upstream version. Kind regards Andreas. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (501, 'testing'), (50, 'buildd-unstable'), (50, 'unstable'), (5, 'experimental'), (1, 'buildd-experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=de_DE:de (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#956843: cdk: Please package cdk-depict.jar
Source: cdk Version: 1:2.3-2 Severity: normal Hi, I have read the line debian/libcdk-java.poms:# depict requires freehep-graphicsio-* 2.4 (Debian has older) which explains why cdk-depict.jar is not build. However, as I explain in bug #956841 classes from this are needed by other software. In this case we even have some relevance for new packages that are considered relevant vor COVID-19 research. So I drop this bug report here as a reminder and as a blocker for continuing with the R interface. I hope we can upgrade freehep soon to continue with this. Kind regards and thanks for maintaining cdk Andreas. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (501, 'testing'), (50, 'buildd-unstable'), (50, 'unstable'), (5, 'experimental'), (1, 'buildd-experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=de_DE:de (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#956842: printrun: FTBFS with python 3.8
Source: printrun Version: 2.0.0~rc5-1 Severity: grave Justification: FTBFS X-Debbugs-CC: rockst...@gmx.com Tags: patch Dear Debian printrun maintainers, The current printrun package FTBFS with python 3.8. As a result, it is blocking the transition from python3.7 to python3.8. Please consider fixing this issue. Downstream Ubuntu already prepared corresponding patches; please review the patch and apply if possible. If you need package sponsorship in order to upload the package, please feel free to let me know. -- Regards, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#925554: fixed in gzip 1.10-1
Control: reopen -1 On Wed, 26 Feb 2020 00:35:02 + Debian FTP Masters wrote: > gzip (1.10-1) unstable; urgency=medium > . >* new upstream version, closes: #925554 Nope, that was #952554 Andreas
Bug#956841: r-cran-rcdklibs: Debian packaged libcdk-java is not exposing all classes
Package: r-cran-rcdklibs
Version: 2.3+dfsg-4
Severity: important
Hi,
when running the test suite of r-cran-rcdk (ITP #956838) it becomes
obvious that not all classes from cdk source are available. For
instance cdk-depict.jar is not build which results in the failure
Executing test function test.depictiongenerator ... Timing stopped at: 0.005
0.004 0.004
Error in .jnew("org.openscience.cdk.depict.DepictionGenerator") :
java.lang.ClassNotFoundException
done successfully.
in the r-cran-rcdk test suite.
Kind regards
Andreas.
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (501, 'testing'), (50, 'buildd-unstable'), (50, 'unstable'), (5,
'experimental'), (1, 'buildd-experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=de_DE:de
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages r-cran-rcdklibs depends on:
ii libcdk-java 1:2.3-2
ii r-base-core [r-api-3.5] 3.6.3-2
ii r-cran-rjava 0.9-12-1
r-cran-rcdklibs recommends no packages.
r-cran-rcdklibs suggests no packages.
-- no debconf information
Bug#954851: Blocked by Bug#956838: ITP: r-cran-rcdk
Control: block -1 by 956838 Uploading r-cran-rcdk is delayed since r-cran-rcdklibs needs a full libcdk-java. The Debian packaged version is not exposing all classes.
Bug#954490: systemd: resolved.conf "allow-downgrade" doesn't work
On Sat, Apr 04, 2020 at 10:41:31AM +0300, Fanis Dokianakis wrote: > I confirm that this bug exists after upgrading systemd. Systemd-resolved > *sometimes* does not downgrade and SERVERFAILS on all domains that do not > have a signature dns record. That's not what "allow-downgrade" means. The downgrade happens when the configured DNS server does not support DNSSEC, not when some domain has an invalid signature. > The error with resolvectl query is > $ resolvectl query example.domain > example.domain: resolve call failed: DNSSEC validation failed: no-signature Please give an actual domain name that fails resolution. Not providing a reproducer just makes this harder for anyone trying to resolve this. Zbyszek
Bug#956840: pympress: Raise an error at start
Package: pympress
Version: 1.5.1+dfsg-3
Severity: critical
Dear Maintainer,
After installing pympress, I try to run it and get the trace below. This makes
the package unusable.
Best,
C.
Traceback (most recent call last):
File "/usr/bin/pympress", line 11, in
load_entry_point('pympress==1.5.1', 'gui_scripts', 'pympress')()
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 489, in
load_entry_point
return get_distribution(dist).load_entry_point(group, name)
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2852,
in load_entry_point
return ep.load()
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2443,
in load
return self.resolve()
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2449,
in resolve
module = __import__(self.module_name, fromlist=['__name__'], level=0)
File "/usr/lib/python3/dist-packages/pympress/__main__.py", line 66, in
import gi
File "/usr/lib/python3/dist-packages/gi/__init__.py", line 42, in
from . import _gi
ImportError: cannot import name '_gi' from 'gi'
(/usr/lib/python3/dist-packages/gi/__init__.py)
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (900, 'testing'), (400, 'unstable'), (300, 'stable'), (100,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.4.31 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages pympress depends on:
ii python3 3.8.2-3
ii python3-vlc 3.0.7110-2
ii python3-watchdog 0.9.0-3
ii python3.7 3.7.7-1+b1
pympress recommends no packages.
pympress suggests no packages.
-- no debconf information
smime.p7s
Description: S/MIME cryptographic signature
Bug#955403: bedtools ftbfs, failing tests on armel, armhf, i386, mipsel
On Tue, Mar 31, 2020 at 03:55:42PM +0200, Andreas Tille wrote: > On Tue, Mar 31, 2020 at 03:48:02PM +0200, Michael Crusoe wrote: > > > > I don't think dropping the 32bit archs is urgent right now. > > I'm happy if you have a better solution, Andreas. I'm not sure what qualifies for "urgent" but we have now: Bug#956828: src:bedtools: fails to migrate to testing for too long: FTBFS on several archs Is there any progress on this? Kind regards Andreas. -- http://fam-tille.de
Bug#956830: quantlib-swig: FTBFS on mipsel
On 15 April 2020 at 20:44, Sebastian Ramacher wrote: | Source: quantlib-swig | Version: 1.18-1 | Severity: serious | Tags: ftbfs sid bullseye | Justification: fails to build from source (but built successfully in the past) Yes ... but it also failed before. See e.g. #909725 (per a quick scan in my debian-bugs folder). Can you possibly try a fix (in dialing down down compiler greedyness, and/or give the builder a bigger allocation) as the error is virtual memory exhausted: Cannot allocate memory Dirk | | The last upload of quantlib-swig failed to build on mipsel: | https://buildd.debian.org/status/fetch.php?pkg=quantlib-swig=mipsel=1.18-1=1586885285=0 | | Cheers | -- | Sebastian Ramacher | [DELETED ATTACHMENT signature.asc, application/pgp-signature] -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#956837: libwebkit2gtk-4.0-37: excess wakeups since 2.28.0-2
Package: libwebkit2gtk-4.0-37
Version: 2.28.1-1
Severity: normal
Tags: upstream
Forwarded: https://bugs.webkit.org/show_bug.cgi?id=210561
Since upgrading to 2.28.0-2,
/usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/WebKitWebProcess
polls like mad and causes excessive wakeups, draining my laptop battery:
$ ps axfu
[...]
tomi 243322 15.0 0.2 102683612 96224 ? Sl 17:53 0:00 liferea
tomi 243332 4.7 0.2 102722076 90816 ? SLl 17:53 0:00 \_
/usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/WebKitWebProcess 7 19
tomi 24 1.5 0.1 103007620 53204 ? SLl 17:53 0:00 \_
/usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/WebKitNetworkProcess 8 1
$ LANG=C strace -f -p 243332
strace: Process 243332 attached with 11 threads
[pid 243360] restart_syscall(<... resuming interrupted read ...>
[pid 243359] restart_syscall(<... resuming interrupted read ...>
[pid 243357] restart_syscall(<... resuming interrupted read ...>
[pid 243356] restart_syscall(<... resuming interrupted read ...>
[pid 243355] restart_syscall(<... resuming interrupted read ...>
[pid 243344] restart_syscall(<... resuming interrupted read ...>
[pid 243343] restart_syscall(<... resuming interrupted read ...>
[pid 243342] restart_syscall(<... resuming interrupted read ...>
[pid 243341] restart_syscall(<... resuming interrupted read ...>
[pid 243340] futex(0x7f14fb18c7cc, FUTEX_WAIT_PRIVATE, 0, NULL
[pid 243332] restart_syscall(<... resuming interrupted read ...>) = 0
[pid 243332] recvmsg(3, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily
unavailable)
[pid 243332] poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}], 2, 17) = 0
(Timeout)
[pid 243332] recvmsg(3, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily
unavailable)
[pid 243332] poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}], 2, 16) = 0
(Timeout)
[pid 243332] recvmsg(3, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily
unavailable)
[pid 243332] poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}], 2, 16) = 0
(Timeout)
[pid 243332] recvmsg(3, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily
unavailable)
[pid 243332] poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}], 2, 16) = 0
(Timeout)
[pid 243332] recvmsg(3, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily
unavailable)
[pid 243332] poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}], 2, 15) = 0
(Timeout)
[pid 243332] recvmsg(3, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily
unavailable)
[pid 243332] poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}], 2, 16) = 0
(Timeout)
[pid 243332] recvmsg(3, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily
unavailable)
[pid 243332] poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}], 2, 16) = 0
(Timeout)
[pid 243332] recvmsg(3, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily
unavailable)
[pid 243332] poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}], 2, 16) = 0
(Timeout)
I originally thought this is a regression since 2.26.4-1~deb10u2, as that
works just fine:
$ LANG=C strace -f -p 253200
strace: Process 253200 attached with 11 threads
[pid 253226] restart_syscall(<... resuming interrupted read ...>
[pid 253223] restart_syscall(<... resuming interrupted read ...>
[pid 253222] restart_syscall(<... resuming interrupted read ...>
[pid 253221] restart_syscall(<... resuming interrupted read ...>
[pid 253220] restart_syscall(<... resuming interrupted read ...>
[pid 253212] restart_syscall(<... resuming interrupted read ...>
[pid 253211] restart_syscall(<... resuming interrupted read ...>
[pid 253210] restart_syscall(<... resuming interrupted read ...>
[pid 253209] restart_syscall(<... resuming interrupted read ...>
[pid 253208] futex(0x7fcbcfee040c, FUTEX_WAIT_PRIVATE, 0, NULL
[pid 253200] restart_syscall(<... resuming interrupted read ...>) = 0
[pid 253200] recvmsg(3, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily
unavailable)
[pid 253200] poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}], 2, 19885
But it turns out visiting
https://en.wikipedia.org/wiki/GIF#/media/File:Rotating_earth_(large).gif using
surf and webkit 2.26.4-1~deb10u2 makes its WebKitWebProcess start polling like
crazy as well, and forever, even after switching to about:blank.
I went a bit further, found a probable cause and filed this upstream at
https://bugs.webkit.org/show_bug.cgi?id=210561 as I'm quite certain this is
affecting all distributions that use webgit2gtk.
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (990, 'testing'), (990, 'stable'), (500, 'unstable-debug'), (500,
'testing-debug'), (500, 'stable-debug'), (500, 'unstable'), (500, 'stable'),
(1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_USER, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8),
LANGUAGE=cs_CZ.UTF-8 (charmap=UTF-8)
Shell:
Bug#956838: ITP: r-cran-rcdk -- GNU R interface to the 'CDK' libraries
Package: wnpp Severity: wishlist Subject: ITP: r-cran-rcdk -- GNU R interface to the 'CDK' libraries Package: wnpp Owner: Andreas Tille Severity: wishlist * Package name: r-cran-rcdk Version : 3.5.0 Upstream Author : Rajarshi Guha, * URL : https://cran.r-project.org/package=rcdk * License : LGPL-2 Programming Lang: GNU R Description : GNU R interface to the 'CDK' libraries Allows the user to access functionality in the 'CDK', a Java framework for chemoinformatics. This allows the user to load molecules, evaluate fingerprints, calculate molecular descriptors and so on. In addition, the 'CDK' API allows the user to view structures in 2D. Remark: This package is maintained by Debian R Packages Maintainers at https://salsa.debian.org/r-pkg-team/r-cran-rcdk
Bug#956839: ITP: kgx -- Simple user-friendly terminal emulator for the GNOME desktop
Package: wnpp Severity: wishlist Owner: Arnaud Ferraris * Package name: kgx Version : 0.2.1 Upstream Author : Zander Brown * URL : https://gitlab.gnome.org/ZanderBrown/kgx * License : GPL-3+ Programming Lang: C Description : Simple user-friendly terminal emulator for the GNOME desktop Kings Cross is a simple terminal emulator for GNOME that adjusts nicely to small screen sizes and touch usage. For those running Debian on mobile phones, it will be a useful addition to Phosh, which I'm packaging too. I take the responsibility for maintaining this package.
Bug#895037: Bug#895038: libappindicator: deprecated in Debian; AppIndicator based applications, please switch to Ayatana (App)Indicator(s)
On Wed, 15 Apr 2020 at 19:06:59 +, Mike Gabriel wrote: > On Mi 15 Apr 2020 10:49:03 CEST, Simon McVittie wrote: > > I've done that for you. > > Thanks for that. What is the exact BTS query to list those bugs? Sorry, I don't know the CLI for it, but I made them block 895037/895038 as appropriate, and applied the same usertags you mentioned earlier in the bug(s). For pre-existing bugs I just added blocks, so some of them might not be usertagged correctly. libappindicator: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895037 (look at "Fix blocked by") https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=ayatana-appindicator=pkg-ayatana-devel%40lists.alioth.debian.org libindicator: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895038 https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=ayatanaindicators=pkg-ayatana-devel%40lists.alioth.debian.org smcv
Bug#956836: ITP: bitwarden -- fully open-source, cross-platform password manager
Package: wnpp Severity: wishlist Owner: Calum McConnell * Package name: bitwarden Version : 1.17.2 * URL : http://www.bitwarden.com/ * License : GPL-3 Programming Lang: Typescript Description : fully open-source, cross-platform password manager == Long description == Bitwarden is an open-source password manager that syncs securly between devices. The full stack is libre software, including the server, meaning one can host their own passwords instead of storing them for free on bitwarden.com's service. Passwords are stored encrypted on the server and on the client using an encryption key derived from the master password by PKBDF2 SHA-256, and encrypted using AES-256. Passwords are encrypted by the client before being sent to the cloud server: it is not possible to determine the unencrypted passwords from the cloud server, unless an attacker already knows the user's master password. Bitwarden also supports saving of other data within the vault. However, saving large files on the bitwarden.com servers requires a premium subscription. This package contains the bitwarden client, which connects to a bitwarden server. == Justifications/Plans == Note: New to the world of packaging I think this package is very useful and relevant, because password managers are a must in order to remain secure using online accounts, and this is the only cross-platform, FOSS manager of which I am aware. I, for one, use it: I do have the premium subscription, but only to support the authors. This is my first Debian package, and as such I would appreciate support. I will need a sponsor: I do plan on finding one thru debian-mentors. I am not aware of any teams which would maintain this: it is a Node.js+electron application, though they also distribute a C# port for mobile devices. I would be happy to work with a team on this package, for I have little javascript experiance and no Electron experience. I plan on using Git and Git-buildpackage to maintain this, because I have grown used to having a full revision history, and I quite like working on several devices. Salsa link is here: https://salsa.debian.org/CalumMcConnell-guest/bitwarden. The branch structure is that recommended by gbp documentation: master is upstream, debian/sid is the contents of the up-to-date debian packaging. I plan on using debmake to make the debian/ files.
Bug#956831: RFS: feedbackd/0.0.0+git20200305-1 [ITP] -- DBus service for haptic/visual/audio feedback
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "feedbackd" * Package name: feedbackd Version : 0.0.0+git20200305-1 Upstream Author : Guido Günther * URL : https://source.puri.sm/Librem5/feedbackd * License : GPL-3+ * Vcs : https://salsa.debian.org/awai-guest/feedbackd Section : x11 It builds those binary packages: feedbackd - DBus service for haptic/visual/audio feedback feedbackd-common - Shared files for feedbackd libfeedback-0.0-0 - Library for managing haptic/visual/audio feedback libfeedback-dev - Development files for libfeedback gir1.2-lfb-0.0 - GObject introspection data for libfeedback To access further information about this package, please visit the following URL: https://mentors.debian.net/package/feedbackd Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/f/feedbackd/feedbackd_0.0.0+git20200305-1.dsc Changes since the last upload: * Initial Debian release (Closes: #956682) Regards, -- Arnaud Ferraris
Bug#956832: mysql-5.7: Security fixes from the April 2020 CPU
Source: mysql-5.7 Version: 5.7.26-1 Severity: grave Tags: security upstream Justification: user security hole Hi See https://www.oracle.com/security-alerts/cpuapr2020.html#AppendixMSQL for a list of CVEs affecting src:mysql-5.7. Regards, Salvatore
Bug#902180: RM: golang-github-docker-engine-api -- ROM; obsolete
> The new version of kubernetes is not a reverse build-dependency anymore. > There are individual RM requests for the remaining blockers: #956741 and > #956743. I removed the moreinfo tag to signal that the FTP masters can go > ahead and remove golang-github-docker-engine-api in the same batch with > those two. Thank you for taking the time to get it sorted out. Scott K signature.asc Description: This is a digitally signed message part.
Bug#895037: Bug#895038: libappindicator: deprecated in Debian; AppIndicator based applications, please switch to Ayatana (App)Indicator(s)
Hi Simon, hi Ivo, I am currently drowned in customer requests. Sorry for the late reply. On Mi 15 Apr 2020 10:49:03 CEST, Simon McVittie wrote: > > To help the overview of what's still missing, it might be good to add > > blocking > > bugs for every package to this one. It seems this wasn't done. Please add blocking bugs to this bug, so it's easy to see what's missing. I've done that for you. Thanks for that. What is the exact BTS query to list those bugs? If you want to get this done for bullseye, please upgrade these bugs to serious. Autoremovals will take care of some of the packages. The rest will need manual fixes. I haven't done that. I think the severity of these bugs is a decision for the maintainer of the replacement to make. I think we should start with important and raise to serious after 8 weeks or so. Mike -- mike gabriel aka sunweaver (Debian Developer) mobile: +49 (1520) 1976 148 landline: +49 (4351) 486 14 27 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: sunwea...@debian.org, http://sunweavers.net pgpHepwfHFLnw.pgp Description: Digitale PGP-Signatur
Bug#956835: RFS: phosh/0.2.2-1 [ITP] -- Pure Wayland shell for mobile devices
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "phosh" * Package name: phosh Version : 0.2.2-1 Upstream Author : Guido Günther * URL : https://source.puri.sm/Librem5/phosh * License : GPL-3+ * Vcs : https://salsa.debian.org/awai-guest/phosh Section : x11 It builds those binary packages: phosh - Pure Wayland shell for mobile devices phosh-osk-stub - OSK stub to fulfill session dependencies To access further information about this package, please visit the following URL: https://mentors.debian.net/package/phosh Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/phosh/phosh_0.2.2-1.dsc Changes since the last upload: * Initial Debian release (Closes: #907641) Regards, -- Arnaud Ferraris
Bug#956834: insighttoolkit4: installs Python 3.8 extensions in the folder for Python 3.7
Source: insighttoolkit4 Version: 4.13.2-dfsg1-8 Severity: serious https://salsa.debian.org/med-team/insighttoolkit/-/blob/master/debian/rules#L138 This line installs the Python extension always for Python 3.7. This means the rebuilt for Python 3.8 installed the extensions incorrectly and produced a broken packages. Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#956833: RFS: phoc/0.1.7-1 [ITP] -- Wayland compositor for mobile phones
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "phoc" * Package name: phoc Version : 0.1.7-1 Upstream Author : Guido Günther * URL : https://source.puri.sm/librem5/phoc * License : MIT * Vcs : https://salsa.debian.org/awai-guest/phoc Section : x11 It builds those binary packages: phoc - Wayland compositor for mobile phones To access further information about this package, please visit the following URL: https://mentors.debian.net/package/phoc Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/phoc/phoc_0.1.7-1.dsc Changes since the last upload: * Initial Debian release (Closes: #956797) Regards, -- Arnaud Ferraris
Bug#956830: quantlib-swig: FTBFS on mipsel
Source: quantlib-swig Version: 1.18-1 Severity: serious Tags: ftbfs sid bullseye Justification: fails to build from source (but built successfully in the past) The last upload of quantlib-swig failed to build on mipsel: https://buildd.debian.org/status/fetch.php?pkg=quantlib-swig=mipsel=1.18-1=1586885285=0 Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#955416: hedgewars: FTBFS with newer SDL
control: notfound -1 hedgewars/1.0.0-4 On Tue, 31 Mar 2020 14:48:06 +0200 Tobias Frost wrote: > Source: hedgewars > Severity: serious > Justification: FTBFS > > Dear Maintainer, > > hedgewars is also affected by #951087, but it seems that no bug has been > filed. > > The quoted bugs above has some hints how to fix the issue. > > -- > tobi > > -- System Information: > Debian Release: bullseye/sid > APT prefers unstable > APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, > 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 5.4.0-3-amd64 (SMP w/4 CPU cores) > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, > TAINT_UNSIGNED_MODULE > Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), > LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > >
Bug#956829: tumiki-fighters: Crash with undefined symbol
Package: tumiki-fighters
Version: 0.2.dfsg1-9
Severity: important
Hi,
tumiki-fighters crashes immediately with:
tumiki-fighters: symbol lookup error: tumiki-fighters: undefined symbol:
_D3std5stdio24__T10makeGlobalS6stderrZ10makeGlobalFNbNcNdNiZS3std5stdio4File
A bit of strace from the crashing thread:
[pid 1239200] openat(AT_FDCWD, "timidity.cfg", O_RDONLY
[pid 1239200] <... openat resumed>) = -1 ENOENT (No such file or directory)
[pid 1239200] openat(AT_FDCWD, "/usr/local/lib/timidity/timidity.cfg",
O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 1239200] openat(AT_FDCWD, "/usr/local/share/timidity/timidity.cfg",
O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 1239200] openat(AT_FDCWD, "/usr/share/timidity/timidity.cfg", O_RDONLY) =
-1 ENOENT (No such file or directory)
[pid 1239200] openat(AT_FDCWD, "/etc/timidity/timidity.cfg", O_RDONLY) = -1
ENOENT (No such file or directory)
[pid 1239200] openat(AT_FDCWD, "/etc/timidity.cfg", O_RDONLY) = -1 ENOENT (No
such file or directory)
[pid 1239200] openat(AT_FDCWD, "/etc/timidity/freepats.cfg", O_RDONLY) = -1
ENOENT (No such file or directory)
[pid 1239200] openat(AT_FDCWD, "/usr/share/sounds/sf3/default-GM.sf3",
O_RDONLY) = 11
[pid 1239200] close(11) = 0
[pid 1239200] openat(AT_FDCWD, "/usr/share/games/tumiki-fighters/barrage",
O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 11
[pid 1239200] fstat(11, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
[pid 1239200] getdents64(11, /* 8 entries */, 32768) = 224
[pid 1239200] openat(AT_FDCWD,
"/usr/share/games/tumiki-fighters/barrage/spread",
O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 12
[pid 1239200] fstat(12, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
[pid 1239200] brk(0x555d1610d000) = 0x555d1610d000
[pid 1239200] getdents64(12, /* 10 entries */, 32768) = 312
[pid 1239200] fstat(2, {st_mode=S_IFREG|0644, st_size=308343, ...}) = 0
[pid 1239200] lseek(2, 0, SEEK_CUR) = 308426
[pid 1239200] write(2, "tumiki-fighters: symbol lookup e"...,
150tumiki-fighters: symbol lookup error: tumiki-fighters: undefined symbol:
_D3std5stdio24__T10makeGlobalS6stderrZ10makeGlobalFNbNcNdNiZS3std5stdio4File
[pid 1239200] exit_group(127) = ?
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (600, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, riscv64
Kernel: Linux 5.4.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8),
LANGUAGE=en_IE:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages tumiki-fighters depends on:
ii libbulletml0v50.0.6-7
ii libc6 2.30-4
ii libgcc-s1 [libgcc1] 10-20200402-1
ii libgcc1 1:10-20200402-1
ii libgl11.3.0-7
ii libgphobos76 9.3.0-10
ii libsdl-mixer1.2 1.2.12-16+b1
ii libsdl1.2debian 1.2.15+dfsg2-5
ii tumiki-fighters-data 0.2.dfsg1-9
tumiki-fighters recommends no packages.
tumiki-fighters suggests no packages.
-- debconf-show failed
Bug#956821: igraph: FTBFS on arm64, armel, armhf, i386, mipsel, ppc64el, s390x
Control: tags -1 upstream Control: forwarded -1 https://github.com/igraph/igraph/issues/1370
Bug#956828: src:bedtools: fails to migrate to testing for too long: FTBFS on several archs
Source: bedtools Version: 2.27.1+dfsg-4 Severity: serious Control: close -1 2.29.2+dfsg-3 Tags: sid bullseye User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 955403 Dear maintainer(s), As recently announced [1], the Release Team now considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing. Your package src:bedtools in its current version in unstable has been trying to migrate for 60 days [2]. Hence, I am filing this bug. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bullseye, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=bedtools signature.asc Description: OpenPGP digital signature
Bug#884095: stretch
oops sorry, it moved to the archive: * https://f-droid.org/archive/eu.faircode.email_914.apk signature.asc Description: OpenPGP digital signature
Bug#956827: schleuder: fails to handle mails with attached, quoted-printable encoded keys
Package: schleuder Version: 3.5.0-3 Forwarded: https://0xacab.org/schleuder/schleuder/-/issues/467 Tags: fixed-upstream x-add-key fails for mails with attached, quoted-printable encoded keys, and yields In the message you sent, no key could be found. A fix was released upstream.
Bug#956826: cfingerd FTCBFS: does not pass cross tools to make
Source: cfingerd Version: 1.4.3-3.2 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs cfingerd fails to cross build from source, because it does not pass cross tools to make. The easiest way of doing so - using dh_auto_build - does not entirely fix the build. One also needs to skip stripping during install. This is a good idea anyway as such stripping breaks DEB_BUILD_OPTIONS=nostrip as well as generation of -dbgsym packages. Please consider applying the attached patch. Helmut diff -u cfingerd-1.4.3/debian/changelog cfingerd-1.4.3/debian/changelog --- cfingerd-1.4.3/debian/changelog +++ cfingerd-1.4.3/debian/changelog @@ -1,3 +1,12 @@ +cfingerd (1.4.3-3.3) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: (Closes: #-1) ++ Let dh_auto_build pass cross tools to make. ++ Defer stripping to dh_strip. + + -- Helmut Grohne Wed, 15 Apr 2020 16:42:41 +0200 + cfingerd (1.4.3-3.2) unstable; urgency=medium * Non-maintainer upload. diff -u cfingerd-1.4.3/debian/rules cfingerd-1.4.3/debian/rules --- cfingerd-1.4.3/debian/rules +++ cfingerd-1.4.3/debian/rules @@ -32,15 +32,12 @@ else CFLAGS = -O2 -Wall endif -ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS))) -STRIP = -s -endif build: -test -f Makefile.cfg || ./Configure -c config=/etc/cfingerd/cfingerd.conf \ -c mandir=/usr/share/man -c man_owner=root -c man_group=root \ -c cflags="$(CFLAGS)" - $(MAKE) all + dh_auto_build -- all touch stamp-build clean: debclean
Bug#956825: pd-boids FTCBFS: strips with the wrong strip
Source: pd-boids Version: 1.1.1-4 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs pd-boids fails to cross build from source, because it strips with the build architecture strip during make install. Such stripping also breaks DEB_BUILD_OPTIONS=nostrip as well as generation of -dbgsym packages. Therefore it is best to leave stripping to dh_strip. Please consider applying the attached patch. Helmut diff --minimal -Nru pd-boids-1.1.1/debian/changelog pd-boids-1.1.1/debian/changelog --- pd-boids-1.1.1/debian/changelog 2018-01-29 21:22:54.0 +0100 +++ pd-boids-1.1.1/debian/changelog 2020-04-15 19:42:57.0 +0200 @@ -1,3 +1,10 @@ +pd-boids (1.1.1-4.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Defer stripping to dh_strip. (Closes: #-1) + + -- Helmut Grohne Wed, 15 Apr 2020 19:42:57 +0200 + pd-boids (1.1.1-4) unstable; urgency=medium * Added (CPP|C|LD)FLAGS to build and simplified d/rules diff --minimal -Nru pd-boids-1.1.1/debian/rules pd-boids-1.1.1/debian/rules --- pd-boids-1.1.1/debian/rules 2018-01-29 21:22:54.0 +0100 +++ pd-boids-1.1.1/debian/rules 2020-04-15 19:42:56.0 +0200 @@ -12,6 +12,6 @@ $(empty) override_dh_auto_install: - dh_auto_install -- prefix=/usr pkglibdir=$(pkglibdir) + dh_auto_install -- prefix=/usr pkglibdir=$(pkglibdir) STRIP=true # replace license file with link to the Debian license file rm -f -- $(CURDIR)/debian/*/$(pkglibdir)/*/LICENSE.txt
Bug#956823: RM: jaxml -- RoQA; Depends on Python 2, dead upstream, unmaintained
Package: ftp.debian.org Severity: normal Please remove jaxml. It depends on Python 2, is dead upstream, there are no reverse deps and the last maintainer upload was in 2010. Cheers, Moritz
Bug#956824: RM: slowaes -- RoQA; Depends on Python 2, dead upstream
Package: ftp.debian.org Severity: normal Please remove slowaes. It depends on Python 2, is dead upstream (last commit in 2011) and there are no reverse deps anymore. Cheers, Moritz
Bug#740070: Updating the sendmail Maintainer field
Debian's Sendmail package has been orphaned for several years. The amount of work which might be involved in maintainership is a little scary, but I should like to take it on. To control unwanted mail, I primarily use milters. In the early years (I've used Sendmail in production for more than 25 years) I tried many milters, but after a decade or so I settled on about seven, which did most of what I wanted - but with varying degrees of pain, because of differences in design, configuration syntax etc. Finally I wrote my own milter (in Perl), which replaced all the rest, and which I've now been using for about four years. I won't bore you with the details of the milter's capabilities unless you're interested in them, but it is now nearing the point where I could let someone else see it. :) For those who would like to use milters but who have perhaps found the Sendmail Milter API daunting, I hope that my milter will make things easier. Coding a milter in Perl is much easier, and much safer, and very much quicker and more productive than is coding a milter in C. Hopefully one day my milter might be incorporated into a teaching aid. My Perl milter uses a CPAN module, Sendmail::PMilter, which provides the Perl interface to Sendmail's Milter API. Sendmail::PMilter is in the development stages, but I have been using the latest development version for a year. A couple of years ago I took on maintainership of Sendmail::PMilter myself, initially so that I could remove dependence on another CPAN module, Sendmail::Milter. That module is in a very unsatisfactory state, having been unmaintained for well over 15 years. For more than a year I tried to take on the CPAN maintainership of the Sendmail::Milter module too, but it seemed that the present maintainer was being deliberately obstructive and I abandoned that effort. The Sendmail::PMilter development version no longer uses Sendmail::Milter, and I think I've fixed all the outstanding Sendmail::PMilter issues, although it could all use a lot more testing (especially the threaded interface, which I have not used at all - it blew up spectacularly at my first attempt, and although I've patched it according to others who have used it, I've never been back there). Eventually I should like Sendmail, Sendmail::PMilter and my own milter all to install and work together seamlessly on a Debian installation. Although I'm comfortable with C, Perl and building software generally, on the subject of Debian packaging I am a novice and the documentation that I have found about using the bug tracking system seems to me to be inadequate. Andreas has offered to help me get up to speed with the Debian specifics, and this gives me much more confidence of being able to handle the maintainership. I should not expect that Andreas would need to do very much more than answer occasional emails from me in the early stages of my involvement; thereafter he can expect to be able to take a seat at the back if he so wishes. There are offers of help from several others in this thread (740070) too. Anyone who'd like to chip in will be very welcome, even if it's just installing the odd .deb now and again for testing; I'll be more than happy to act as a concentration/triage point. 73, Ged.
Bug#956822: xpra: FTBFS on armel and armhf
Source: xpra Version: 3.0.8+dfsg1-1 Severity: serious Tags: ftbfs sid bullseye Justification: fails to build from source (but built successfully in the past) xpra failed to build on armel and armhf. See https://buildd.debian.org/status/fetch.php?pkg=xpra=armel=3.0.8%2Bdfsg1-1=1586872010=0 Cheers -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (650, 'unstable-debug'), (650, 'unstable'), (601, 'testing'), (600, 'experimental-debug'), (600, 'buildd-unstable'), (600, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.5.0-1-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#956821: igraph: FTBFS on arm64, armel, armhf, i386, mipsel, ppc64el, s390x
Source: igraph Version: 0.8.0-1 Severity: serious Tags: ftbfs sid bullseye Justification: fails to build from source (but built successfully in the past) igraph failed to build almost everywhere. See https://buildd.debian.org/status/package.php?p=igraph=sid Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#956177: fail2ban: daemon startup should not access /root/.local
On Thursday, 16 April 2020 1:01:56 AM AEST Sylvestre Ledru wrote: > Le 15/04/2020 à 15:51, Russell Coker a écrit : > > Environment="PYTHONNOUSERSITE=yes" > > > > Putting the above in the service file fixes the problem. > > OK, many thanks :) > As you did 90 % of the work, would you like to submit a MR ? > https://salsa.debian.org/python-team/applications/fail2ban I'm not the greatest at Git and I'm not bothered about getting credit for such things so I'm happy for you to do it. This is a small part of my work writing SE Linux policy. -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/
Bug#956709: libglom-1.30-0: upgrade of boost packages makes libglom-1.30-0 uninstallable
Control: severity -1 important Control: retitle -1 glom: ensure build with ocmpatible libpython and libboost-python On 2020-04-14 16:27:13 +0200, Giacomo Mulas wrote: > Package: libglom-1.30-0 > Version: 1.30.4-6 > Severity: grave > Justification: renders package unusable > > Dear Maintainer, > > the upgrade of libboost-python1.67.0 breaks a dependency of libglom-1.30-0, > thereby making it uninstallable. To fix this, it must be rebuilt with the > new libraries _and_ with python 3.8 instead of 3.7. glom's build system does not ensure that libpython and libboost-python are compatible. Please make sure that they are compatible in future to avoid the same issues for thne Python 3 transition. Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#956819: RFS: cachy/0.3.0-1 [ITP] -- Provide a simple yet effective caching library (Python 3)
Package: sponsorship-requests Severity: wishlist X-Debug-Cc: python-modules-t...@lists.alioth.debian.org Dear mentors, I am looking for a sponsor for my package "cachy" * Package name: cachy Version : 0.3.0-1 Upstream Author : Sébastien Eustace * URL : https://github.com/sdispater/cachy * License : MIT * Vcs : https://salsa.debian.org/python-team/modules/python3-cachy Section : python It builds those binary packages: python3-cachy - Provide a simple yet effective caching library (Python 3) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/cachy Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/c/cachy/cachy_0.3.0-1.dsc Changes since the last upload: * Initial release (Closes: #956607) Regards, -- Emmanuel Arias signature.asc Description: OpenPGP digital signature
Bug#956807: [Debian GNUstep maintainers] Bug#956807: terminal.app: terminal does not start
Dear Anna, The screenshot looks a lot like GNOME, not GNUstep, do you really have terminal.app installed? Can you start it from xterm as Terminal? It starts for me normally. Can you check you don't mean gnome-terminal? dpkg -l terminal.app gives what output? *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? I got the messages that a system update is available, so i click install and restart. afterwards the system told me that the language has changed and if I want to rename the folders "Documents" "Pictures" etc. Since i am used to have these folders in english I decided to click okay (i am not sure if this is relevant). Then I wanted to launch Terminal but only in the top left corner a loading circle appeared which disappeared after a while. Also part of my Desktop is english and part of it is german. * What exactly did you do (or not do) that was effective (or ineffective)? I tried to reboot multiple times I tried to reset language settings I tried to launch Terminal via xterm * What was the outcome of this action? nothing * What outcome did you expect instead? that terminal launches xterm works, but Terminal.app not, can you give the output of strace Terminal ? Best, -- System Information: Debian Release: 10.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-8-amd64 (SMP w/2 CPU cores) Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8), LANGUAGE=de_AT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled ___ Debian GNUstep maintainers mailing list pkg-gnustep-maintain...@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-gnustep-maintainers
Bug#956820: gccgo does not implement syscall in hurd-i386
Package: gccgo-9 Version: 9.3.0-9 Severity: important X-debbugs-cc: debian-h...@lists.debian.org golang-github-nsf-termbox-go is failing to build with gcc-go (changed Build-Depends to golang-any and built on hurd-i386 latest sid). There are many failures like this, src/github.com/nsf/termbox-go/termbox.go:507:37: error: reference to undefined identifier ‘syscall.SYS_FCNTL’ 507 | r, _, e := syscall.Syscall(syscall.SYS_FCNTL, uintptr(fd), uintptr(cmd), | ^ src/github.com/nsf/termbox-go/termbox.go:50:17: error: use of undefined type ‘syscall_Termios’ 50 | orig_tios syscall_Termios $ go version go version go1.12.2 gccgo (Debian 9.3.0-9) 9.3.0 hurd/386 Discussion with hurd maintainers https://lists.debian.org/debian-hurd/2020/04/msg00026.html Full build log attached. I think gccgo needs to implement these syscall interfaces for hurd. golang-github-nsf-termbox-go-0.0~git20160914$ dpkg-buildpackage dpkg-buildpackage: info: source package golang-github-nsf-termbox-go dpkg-buildpackage: info: source version 0.0~git20160914-3 dpkg-buildpackage: info: source distribution unstable dpkg-buildpackage: info: source changed by Michael Stapelberg dpkg-buildpackage: info: host architecture hurd-i386 dpkg-source --before-build . fakeroot debian/rules clean I: golang-github-nsf-termbox-go_0.0~git20160914 dh clean --buildsystem=golang --with=golang dh_auto_clean -O--buildsystem=golang dh_clean -O--buildsystem=golang dpkg-source -b . dpkg-source: info: using source format '3.0 (quilt)' dpkg-source: info: building golang-github-nsf-termbox-go using existing ./golang-github-nsf-termbox-go_0.0~git20160914.orig.tar.gz dpkg-source: info: building golang-github-nsf-termbox-go in golang-github-nsf-termbox-go_0.0~git20160914-3.debian.tar.xz dpkg-source: info: building golang-github-nsf-termbox-go in golang-github-nsf-termbox-go_0.0~git20160914-3.dsc debian/rules build I: golang-github-nsf-termbox-go_0.0~git20160914 dh build --buildsystem=golang --with=golang dh_update_autotools_config -O--buildsystem=golang dh_auto_configure -O--buildsystem=golang dh_auto_build -O--buildsystem=golang cd obj-i686-gnu && go install -gcflags=all=\"-trimpath=/home/pravi/golang-github-nsf-termbox-go-0.0\~git20160914/obj-i686-gnu/src\" -asmflags=all=\"-trimpath=/home/pravi/golang-github-nsf-termbox-go-0.0\~git20160914/obj-i686-gnu/src\" -v -p 1 github.com/nsf/termbox-go github.com/mattn/go-runewidth github.com/nsf/termbox-go # github.com/nsf/termbox-go src/github.com/nsf/termbox-go/termbox.go:507:37: error: reference to undefined identifier âsyscall.SYS_FCNTLâ 507 | r, _, e := syscall.Syscall(syscall.SYS_FCNTL, uintptr(fd), uintptr(cmd), | ^ src/github.com/nsf/termbox-go/termbox.go:50:17: error: use of undefined type âsyscall_Termiosâ 50 | orig_tios syscall_Termios | ^ src/github.com/nsf/termbox-go/api.go:57:6: error: reference to field âIflagâ in object which has no fields or methods 57 | tios.Iflag &^= syscall_IGNBRK | syscall_BRKINT | syscall_PARMRK | | ^ src/github.com/nsf/termbox-go/api.go:57:17: error: reference to undefined name âsyscall_IGNBRKâ 57 | tios.Iflag &^= syscall_IGNBRK | syscall_BRKINT | syscall_PARMRK | | ^ src/github.com/nsf/termbox-go/api.go:57:34: error: reference to undefined name âsyscall_BRKINTâ 57 | tios.Iflag &^= syscall_IGNBRK | syscall_BRKINT | syscall_PARMRK | | ^ src/github.com/nsf/termbox-go/api.go:57:51: error: reference to undefined name âsyscall_PARMRKâ 57 | tios.Iflag &^= syscall_IGNBRK | syscall_BRKINT | syscall_PARMRK | | ^ src/github.com/nsf/termbox-go/api.go:58:3: error: reference to undefined name âsyscall_ISTRIPâ 58 | syscall_ISTRIP | syscall_INLCR | syscall_IGNCR | | ^ src/github.com/nsf/termbox-go/api.go:58:20: error: reference to undefined name âsyscall_INLCRâ 58 | syscall_ISTRIP | syscall_INLCR | syscall_IGNCR | |^ src/github.com/nsf/termbox-go/api.go:58:36: error: reference to undefined name âsyscall_IGNCRâ 58 | syscall_ISTRIP | syscall_INLCR | syscall_IGNCR | |^ src/github.com/nsf/termbox-go/api.go:59:3: error: reference to undefined name âsyscall_ICRNLâ 59 | syscall_ICRNL | syscall_IXON | ^ src/github.com/nsf/termbox-go/api.go:59:19: error: reference to undefined name âsyscall_IXONâ 59 | syscall_ICRNL | syscall_IXON | ^ src/github.com/nsf/termbox-go/api.go:60:6: error: reference to field âLflagâ in object which has no fields or methods 60 | tios.Lflag &^= syscall_ECHO | syscall_ECHONL | syscall_ICANON | | ^ src/github.com/nsf/termbox-go/api.go:60:17: error: reference to undefined name âsyscall_ECHOâ 60 | tios.Lflag &^=
Bug#956795: libpam-systemd: fills the logs with messages about pam_systemd.so
Can you also send me the output of ldd /usr/sbin/cron and apt-cache policy libpam0g signature.asc Description: OpenPGP digital signature
Bug#956605: texlive-bin: FTBFS on powerpc & sparc64
On 4/15/20 6:17 PM, Hilmar Preuße wrote: > I expected something like this, as the -1 package built fine. Hence I > did not really expect an issue, which needed to be addressed by the porters. Well, you put the architecture names in the subject, so it would have been useful to CC us ;). As for the -1 package building fine, it's a race condition. It may fail, but it doesn't have to fail. As you can see, it now built fine on sparc64 since it was picked up by the buildd "nvg5120" which has fewer vCPUs than landau which has 128 vCPUs. >> I recommend forwarding this issue upstream and limiting the parallel jobs >> for texlive-bin to 16 or even 8. >> > We have to perform another upload anyway, so I'll try to change that > parameter and do another upload ASAP. Seems that anybody triggered a > rebuild on sparc, which run on nvg5120 with -j16 and was successful. So > I'll limit to -16 I did that :). Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#956818: developers-reference: contradictory information about removing packages from Incoming
On Wed, Apr 15, 2020 at 06:33:29PM +0200, Bill Allombert wrote: > > In section 5.6.1, it is mentioned that the dcut command can be used to > > remove packages from the upload queue. > > However, section 5.9.2.1 states that it is no longer possible to remove > > packages from incoming. > > This seems contradictory. > It is not. The upload queue and incoming are separate entities. > Package are uploaded to the upload queue, then the signature are checked > and they are moved to incoming. I'd still happily take a patch which clarifies this. -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Bug#956818: developers-reference: contradictory information about removing packages from Incoming
On Wed, Apr 15, 2020 at 06:22:07PM +0200, Vincent Prat wrote: > Package: developers-reference > Version: 11.0.10 > > In section 5.6.1, it is mentioned that the dcut command can be used to > remove packages from the upload queue. > However, section 5.9.2.1 states that it is no longer possible to remove > packages from incoming. > This seems contradictory. It is not. The upload queue and incoming are separate entities. Package are uploaded to the upload queue, then the signature are checked and they are moved to incoming. Cheers, -- Bill. Imagine a large red swirl here.
Bug#956605: texlive-bin: FTBFS on powerpc & sparc64
Am 15.04.2020 um 10:04 teilte John Paul Adrian Glaubitz mit: Hi Adrian, > Please always CC the arch-specific mailing lists when filing arch-specific > bugs. > > Looking at the issue, it seems that texlive-bin has issues when built with > many jobs in parallel. On both powerpc and sparc64, the package was built > with "make -j32" [1, 2]. Both kapitsa and landau are systems with many > virtual CPUs (both are VMs on POWER and SPARC servers) something that > is still unusual on x86_64. > I expected something like this, as the -1 package built fine. Hence I did not really expect an issue, which needed to be addressed by the porters. > I recommend forwarding this issue upstream and limiting the parallel jobs > for texlive-bin to 16 or even 8. > We have to perform another upload anyway, so I'll try to change that parameter and do another upload ASAP. Seems that anybody triggered a rebuild on sparc, which run on nvg5120 with -j16 and was successful. So I'll limit to -16 H. -- sigfault #206401 http://counter.li.org signature.asc Description: OpenPGP digital signature
Bug#956818: developers-reference: contradictory information about removing packages from Incoming
Package: developers-reference Version: 11.0.10 In section 5.6.1, it is mentioned that the dcut command can be used to remove packages from the upload queue. However, section 5.9.2.1 states that it is no longer possible to remove packages from incoming. This seems contradictory. Best regards, Vincent
Bug#956757: mstflint FTCBFS: bad Makefile dependencies
Hi, Am Mittwoch, den 15.04.2020, 07:26 +0200 schrieb Helmut Grohne: > Source: mstflint > Version: 4.13.3+2-2 > Tags: patch upstream > User: debian-cr...@lists.debian.org > Usertags: ftcbfs > > mstflint fails to cross build from source, because it includes > -lboost_regex in Makefile dependencies. Including such flag in a > Makefile dependency causes make to look it up using its > architecture-dependent library search path. When cross building, it > fails to find the library and errors out. In general, it doesn't make > sense to include system libraries in Makefile dependencies, so we can > simply skip the flag there. Please consider applying the attached > patch > to make mstflint cross buildable again. Thanks for the patch? Can you submit this change upstream on https://github.com/Mellanox/mstflint ? -- Benjamin Drung DevOps Engineer and Debian & Ubuntu Developer Platform Integration (IONOS Cloud) 1&1 IONOS SE | Greifswalder Str. 207 | 10405 Berlin | Germany E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498 Vorstand: Dr. Christian Böing, Hüseyin Dogan, Dr. Martin Endreß, Hans- Henning Kettler, Arthur Mai, Matthias Steinberg, Achim Weiß Aufsichtsratsvorsitzender: Markus Kadelke Member of United Internet Diese E-Mail kann vertrauliche und/oder gesetzlich geschützte Informationen enthalten. Wenn Sie nicht der bestimmungsgemäße Adressat sind oder diese E-Mail irrtümlich erhalten haben, unterrichten Sie bitte den Absender und vernichten Sie diese E-Mail. Anderen als dem bestimmungsgemäßen Adressaten ist untersagt, diese E-Mail zu speichern, weiterzuleiten oder ihren Inhalt auf welche Weise auch immer zu verwenden. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient of this e-mail, you are hereby notified that saving, distribution or use of the content of this e-mail in any way is prohibited. If you have received this e-mail in error, please notify the sender and delete the e-mail.
Bug#956456: [covid-19] Packaging idseq-dag (Was: [covid] New Contributor for biohackathon)
Hi Andreas, Thanks for the notice that pytz is already on Debian. And thanks so much for the patch :) I will continue working on that and trying to fix the issue. I will keep you updated Cheers, Arias Emmanuel @eamanu yaerobi.com On Wed, Apr 15, 2020 at 12:24 PM Andreas Tille wrote: > Hi Emmanuel, > > I've seen your ITP of idseq-dag. You mentioned > >idseq-dag depends on pytz. I will send the ITP for that package. > > I admit its a bit confusing but that package is python3-tz in Debian, is > packaged and I've added it to Build-Depends (amongst other changes). > > The current packaging is suffering from failures inside the test suite > looking like this: > > > == > ERROR: test_step_single > (tests.generate_alignment_viz.GenerateAlignmentVizTest) > -- > Traceback (most recent call last): > File > "/build/idseq-dag-4.2.3/.pybuild/cpython3_3.8_idseq-dag/build/tests/generate_alignment_viz.py", > line 9, in test_step_single > run_step = > IdseqStepSetup.get_step_object(PipelineStepGenerateAlignmentViz, > "alignment_viz_out", paired=False) > File > "/build/idseq-dag-4.2.3/.pybuild/cpython3_3.8_idseq-dag/build/tests/idseq_step_setup.py", > line 47, in get_step_object > PipelineFlow.fetch_input_files_from_s3( > File > "/build/idseq-dag-4.2.3/.pybuild/cpython3_3.8_idseq-dag/build/idseq_dag/engine/pipeline_flow.py", > line 179, in fetch_input_files_from_s3 > output_file = idseq_dag.util.s3.fetch_from_s3(s3_file, local_dir, > allow_s3mi=True) > File > "/build/idseq-dag-4.2.3/.pybuild/cpython3_3.8_idseq-dag/build/idseq_dag/util/s3.py", > line 286, in fetch_from_s3 > if is_reference or os.path.abspath(dst).startswith(config["REF_DIR"]): > TypeError: startswith first arg must be str or a tuple of str, not NoneType > > > The issue is that I had to replace some default dir in a patch[1]. > Unfortunately this did not propagated into the config dictionary and > the key "REF_DIR" is not set. For the moment I gave up here - may > be you want to continue by either fixing my patch or finding a better > way to convince the test suite to write to some place where this is > permitted. > > Kind regards > >Andreas. > > [1] > https://salsa.debian.org/med-team/idseq-dag/-/blob/master/debian/patches/set_default_output_dir_var_tmp.patch > > On Sat, Apr 11, 2020 at 12:38:13AM -0300, Emmanuel Arias wrote: > > Hello everybody, > > > > I am available to help. I will be working on the TODO list [0]. > > > > [0] > > > https://salsa.debian.org/med-team/community/2020-covid19-hackathon/-/wikis/COVID-19-Hackathon-packages-needing-work > > > > Cheers, > > Arias Emmanuel > > @eamanu > > yaerobi.com > > > > > > On Fri, Apr 10, 2020 at 3:10 AM Olek Wojnar wrote: > > > > > On 4/9/20 7:37 PM, fancycade wrote: > > > > Thank you for the assistance with this! > > > > > > > > I have uploaded my package to the appropriate repository under the > > > > Python Modules team and will reach out for a RFS. > > > > > > Great, thanks for your contribution! > > > > > > -Olek > > > > > > > > > > > > > > -- > http://fam-tille.de >
