Bug#949788: s390-dasd FTCBFS: strips with the build architecture strip
Moin On Sat, Jan 25, 2020 at 05:50:40AM +0100, Helmut Grohne wrote: > s390-dasd fails to cross build from source, because it strips using the > build architecture strip during build. Beyond breaking cross > compilation, this also breaks DEB_BUILD_OPTIONS=nostrip as well as > generation of -dbgsym packages. It is best to defer all stripping to > dh_strip. Please consider applying the attached patch. This is the wrong fix. Take a look at the Makefile. Bastian -- Time is fluid ... like a river with currents, eddies, backwash. -- Spock, "The City on the Edge of Forever", stardate 3134.0
Bug#949792: ITP: merkaartor -- map editor for OpenStreetMap.org
Package: wnpp Severity: wishlist Owner: Jerome Benoit * Package name: merkaartor Version : 0.18.4 Upstream Author : Merkaartor Developers * URL : https://github.com/openstreetmap/merkaartor * License : GPL-2+ Programming Lang: C++ Description : map editor for OpenStreetMap.org Merkaartor is a map editor for OpenStreetMap.org, the free editable map of the whole world. Features: * download from and upload to the OpenStreetMap server * open .osm and .gpx files * create and move trackpoints, ways, and areas * add tags, delete features * reverse, split and join ways * visualize some leisure/landuse areas and road types * displaying GPS information I plan to reintroduce and maintain Merkaartor on behalf of the Debian GIS Project team. This is motivated by the recent update of Merkaartor (which occured after its remove from Sid). Jerome
Bug#948378: transition: boost-python
Hi Andreas, On 08-01-2020 00:03, Andreas Beckmann wrote: [...] > So let's rebuild all rdepends of libboost-python1.67.0 and friends to > tighten the dependencies and properly document which python support is > being used. That should help with the python2 removal (and a future > removal of python3.7 as a supported version). > > I don't know how to express something like > "depends on libboost-python1.67.0 >AND NOT depends on libboost-python1.67.0-py.*" I used this: .depends ~ /\blibboost-(mpi-python|python|numpy)[0-9.]*\b/ & !.depends ~ /\blibboost-(mpi-python|python|numpy)[0-9.]*-py[0-9]*\b/ > in ben, so the below ben file will only generate "unknown" and "good" > states. (Is ".false" the correct syntax for that?) > You can exclude src:boost1.67 and src:boost1.71 if you want. > Please binNMU the remaining "unknown" packages once, hopefully they > should all turn green. Since this is not a real transition, all could be > scheduled at the same time. [...] All rebuilds have been scheduled. There are 2 packages (python-escript (sid only) and pythonmagick) that FTBFS now, but didn't before. Can you please check? Especially pythonmagick looks suspicious to my untrained eyes. Paul signature.asc Description: OpenPGP digital signature
Bug#949789: libcdb-file-perl FTCBFS: computes a build architecture ARCHLIB
Le 25/01/2020 à 06:09, Helmut Grohne a écrit : > Source: libcdb-file-perl > Version: 1.00-1 > Tags: patch > User: debian-cr...@lists.debian.org > Usertags: ftcbfs > > libcdb-file-perl fails to cross build from source, because its ARCHLIB > variable is computed for the build architecture rather than the host > architecture. We've already seen this pattern in #949266. The same fix > works here. > > Can we take the opportunity to step back? Clearly embodying these runes > into many packages is going to cause pain down the road. They're hard to > remember and longish. If setting up ARCHLIB is a common thing, then > maybe it should be centralized somehow? dpkg provides > /usr/share/dpkg/*.mk. Maybe perl should do something similar? Could > there be some perl.mk to be included in debian/rules that sets up > ARCHLIB? > > I've X-Debbugs-Cced debian-perl@l.d.o to get an answer to the latter. > Please wait a little before applying my patch: I hope we can centralize > it somehow. > > Helmut Hi, pkg-js-tools is the Debian installer for Node.js packages. It currently use DEB_HOST_GNU_TYPE to find the place to install arch-dependent Node.js packages. Do we have to replace DEB_HOST_GNU_TYPE by DEB_HOST_MULTIARCH ? (Then a duplication of this bug could be nice) Cheers, Xavier
Bug#949444: depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/lib/modules/[...]/modules.builtin.bin'
I can perfectly confirm the issue with my two bullseye instances, one on bare metal and the other virtualized with kvm. Chris
Bug#949791: can foomatic-db-engine be marked Multi-Arch: foreign?
Package: foomatic-db-engine Version: 4.0.13-4 User: debian-cr...@lists.debian.org Control: tags -1 + moreinfo Usertags: ftcbfs Control: affects -1 + src:foo2zjs Hi Didier, foo2zjs fails to cross build from source, because it fails running foomatic-perl-data and foomatic-combo-xml with an "Exec format error". Usually that means that it needs the corresponding package (foomatic-db-engine) for the build architecture rather than the host architecture. The simplest way to do that is marking foomatic-db-engine Multi-Arch: foreign. Unfortunately, sometimes such a marking is wrong and that can cause breakage elsewhere, so one should be careful not to blindly add it. To understand whether it is correct, one needs someone with deep multiarch and foomatic knowledge to look at it. Unfortunately, I think there are about zero persons on this planet that match the criterion. For instance, I certainly lack the foomatic knowledge. So let's try the second best approach: Have someone with multiarch knowledge talk to someone with foomatic knowledge. Can I ask you to be the one who talks about foomatic? The question to ask here is: If I'm installing foomatic-db-engine one a different computer with a different architecture, would i notice any difference when interacting with the provided interfaces? In this case interfaces are non-private components contained in foomatic-db-engine. Typically the contained programs (/usr/bin/*) count towards the interface. For the shipped perl modules it is less clear. Sometimes, packages ship private perl modules. Are the perl modules shipped in foomatic-db-engine considered public? If you consider them an implementation detail and no other package uses them, we can disregard them for our analysis. I suppose that printing stuff generally operates with architecture-independent file formats. Is that the case here? For instance textual file formats (such as xml) are generally assumed to be architecture-independent. Is there some way of learning the processor architecture, bits or endianess by interacting with these tools? (Note that inspecting the binary files with binutils does not count here.) We also need to look into dependencies. Sometimes packages wrap other packages (e.g. foo depends on foo-data, but foo-data's content generally counts towards the interface of foo as foo-data is an implementation detail to save archive space). The dependencies to consider here are cups-filters | foomatic-filters, wget | curl and possibly perl. I guess perl is being added by debhelper due to the perl module. wget and curl are also used by the perl module. So how about the filters? Are they used internally or exposed? Possibly we need to consider whether cups-filters can be marked Multi-Arch: foreign, before we can come up with an answer for foomatic-db-engine. This is not one of the bugs where you can blindly apply a patch unfortunately. Please help me find the correct solution. Helmut
Bug#949789: libcdb-file-perl FTCBFS: computes a build architecture ARCHLIB
Source: libcdb-file-perl
Version: 1.00-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
libcdb-file-perl fails to cross build from source, because its ARCHLIB
variable is computed for the build architecture rather than the host
architecture. We've already seen this pattern in #949266. The same fix
works here.
Can we take the opportunity to step back? Clearly embodying these runes
into many packages is going to cause pain down the road. They're hard to
remember and longish. If setting up ARCHLIB is a common thing, then
maybe it should be centralized somehow? dpkg provides
/usr/share/dpkg/*.mk. Maybe perl should do something similar? Could
there be some perl.mk to be included in debian/rules that sets up
ARCHLIB?
I've X-Debbugs-Cced debian-perl@l.d.o to get an answer to the latter.
Please wait a little before applying my patch: I hope we can centralize
it somehow.
Helmut
diff --minimal -Nru libcdb-file-perl-1.00/debian/changelog
libcdb-file-perl-1.00/debian/changelog
--- libcdb-file-perl-1.00/debian/changelog 2020-01-24 14:28:12.0
+0100
+++ libcdb-file-perl-1.00/debian/changelog 2020-01-25 06:03:25.0
+0100
@@ -1,3 +1,10 @@
+libcdb-file-perl (1.00-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix FTCBFS: Correctly compute ARCHLIB. (Closes: #-1)
+
+ -- Helmut Grohne Sat, 25 Jan 2020 06:03:25 +0100
+
libcdb-file-perl (1.00-1) unstable; urgency=medium
* Team upload.
diff --minimal -Nru libcdb-file-perl-1.00/debian/rules
libcdb-file-perl-1.00/debian/rules
--- libcdb-file-perl-1.00/debian/rules 2020-01-24 14:28:12.0 +0100
+++ libcdb-file-perl-1.00/debian/rules 2020-01-25 06:03:23.0 +0100
@@ -4,7 +4,9 @@
PACKAGE = $(shell dh_listpackages)
TMP = $(CURDIR)/debian/$(PACKAGE)
-ARCHLIB := $(shell perl -MConfig -e 'print $$Config{vendorarch}')
+include /usr/share/dpkg/architecture.mk
+PERLVER := $(shell perl -MConfig -e 'print $$Config{version}')
+ARCHLIB := $(shell perl
-I/usr/lib/$(DEB_HOST_MULTIARCH)/perl/cross-config-$(PERLVER) -MConfig -e
'print $$Config{vendorarch}')
%:
dh $@
Bug#949790: libxaw3dxft FTCBFS: does not pass --host to ./configure
Source: libxaw3dxft
Version: 1.6.2e-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
libxaw3dxft fails to cross build from source, because it does not pass
--host to ./configure. The easiest way of doing so - using
dh_auto_configure - makes it cross buildable. Please consider applying
the attached patch.
Helmut
diff --minimal -Nru libxaw3dxft-1.6.2e/debian/changelog
libxaw3dxft-1.6.2e/debian/changelog
--- libxaw3dxft-1.6.2e/debian/changelog 2018-12-31 17:35:18.0 +0100
+++ libxaw3dxft-1.6.2e/debian/changelog 2020-01-25 05:45:20.0 +0100
@@ -1,3 +1,10 @@
+libxaw3dxft (1.6.2e-2.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix FTCBFS: Let dh_auto_configure pass --host to ./configure. (Closes: #-1)
+
+ -- Helmut Grohne Sat, 25 Jan 2020 05:45:20 +0100
+
libxaw3dxft (1.6.2e-2) unstable; urgency=medium
* Bump debhelper compat level from 9 to 11:
diff --minimal -Nru libxaw3dxft-1.6.2e/debian/rules
libxaw3dxft-1.6.2e/debian/rules
--- libxaw3dxft-1.6.2e/debian/rules 2018-12-31 17:35:18.0 +0100
+++ libxaw3dxft-1.6.2e/debian/rules 2020-01-25 05:45:20.0 +0100
@@ -7,7 +7,7 @@
dh $@
override_dh_auto_configure:
- ./configure --prefix=/usr --enable-internationalization \
+ dh_auto_configure -- --libdir='$${prefix}/lib'
--enable-internationalization \
--enable-arrow-scrollbars
override_dh_auto_install:
Bug#949788: s390-dasd FTCBFS: strips with the build architecture strip
Source: s390-dasd Version: 0.0.65 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs s390-dasd fails to cross build from source, because it strips using the build architecture strip during build. Beyond breaking cross compilation, this also breaks DEB_BUILD_OPTIONS=nostrip as well as generation of -dbgsym packages. It is best to defer all stripping to dh_strip. Please consider applying the attached patch. Helmut diff --minimal -Nru s390-dasd-0.0.65/debian/changelog s390-dasd-0.0.65+nmu1/debian/changelog --- s390-dasd-0.0.65/debian/changelog 2019-11-13 23:43:24.0 +0100 +++ s390-dasd-0.0.65+nmu1/debian/changelog 2020-01-25 05:44:17.0 +0100 @@ -1,3 +1,10 @@ +s390-dasd (0.0.65+nmu1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Defer stripping to dh_strip. (Closes: #-1) + + -- Helmut Grohne Sat, 25 Jan 2020 05:44:17 +0100 + s390-dasd (0.0.65) unstable; urgency=medium * Team upload diff --minimal -Nru s390-dasd-0.0.65/debian/rules s390-dasd-0.0.65+nmu1/debian/rules --- s390-dasd-0.0.65/debian/rules 2018-08-10 21:25:00.0 +0200 +++ s390-dasd-0.0.65+nmu1/debian/rules 2020-01-25 05:44:16.0 +0100 @@ -1,3 +1,6 @@ #! /usr/bin/make -f %: dh $@ + +override_dh_auto_build: + dh_auto_build -- STRIP=true
Bug#949787: ITP: python-certbot-dns-gandi -- Gandi LiveDNS plugin for Certbot
Package: wnpp Severity: wishlist Owner: Unit 193 * Package name: python-certbot-dns-gandi Version : 1.2.5 Upstream Author : Yohann Leon * URL : https://github.com/obynio/certbot-plugin-gandi/ * License : Expat Programming Lang: Python Description : Gandi LiveDNS plugin for Certbot The objective of Certbot, Let's Encrypt, and the ACME (Automated Certificate Management Environment) protocol is to make it possible to set up an HTTPS server and have it automatically obtain a browser-trusted certificate, without any human intervention. This is accomplished by running a certificate management agent on the web server. . This is a plugin for Certbot that uses the Gandi LiveDNS API to allow Gandi customers to prove control of a domain name.
Bug#944826: RFP: libjs-jquery-stickytableheaders -- stick table headers to the top of a viewport when scrolling
Dear JavaScript Team, I would sincerely appreciate it if someone would take a look at this RFP :-) Please CC this bug for any replies. Thanks! Nicholas On Fri, Nov 15, 2019 at 09:16:41PM -0500, Nicholas D Steeves wrote: > Package: wnpp > Severity: wishlist > Control: block 944704 by -1 > > Package name: libjs-jquery-stickytableheaders > Version : 0.1.24 > Upstream Author : Jonas Mosbech > URL : https://github.com/jmosbech/StickyTableHeaders > License : MIT > Programming Lang: JS > Description : stick table headers to the top of a viewport when scrolling > > StickyTableHeaders is a jQuery plugin that sticks table headers to the > top of a viewport. When scrolling through a long vertical list it > is easy for forget what header each column refers to. > StickyTableHeaders solves this issue by keeping column headers visible > at all times so that the user doesn't need to regularly scroll to the > top of a table. > > Upstream demo: https://jsfiddle.net/jmosbech/stFcx/ > > I discovered this package while working on org-html-themes, which > depends on StickyTableHeaders. Other than that, I am frequently > frustrated by websites that exhibit the issue this software solves > (eg: Wikipedia has this issue). While I'm generally sympathetic to > the "nojs" approach to web browsing, I believe that most users of > "nojs" would probably white-list StickyTableHeaders, because of how it > dramatically enhances the experience of reading long tables. I am not > aware of other packages that provide this functionality. > > Please consider packaging it soon! :-) > > > Thank you, > Nicholas signature.asc Description: PGP signature
Bug#944826: RFP: libjs-jquery-stickytableheaders -- stick table headers to the top of a viewport when scrolling
Hi Thorsten, Thorsten Glaser writes: > On Fri, 24 Jan 2020, Nicholas D Steeves wrote: > >> I would sincerely appreciate it if someone would take a look at this >> RFP :-) > > Wrong team? JavaScript has absolutely nothing to do with Java. > Oh my, indeed! Sorry, I confess to not checking to see if there was a separate JS team... Apologies for making noise on debian-java, Nicholas signature.asc Description: PGP signature
Bug#937321: presage: Python2 removal in sid/bullseye
Hi Matteo, I don't know if you saw, but I sent you a merge request[1] to remove the Python subpackages in presage. They don't have any rdeps and have very low popcon so it seems reasonable to remove them now (and they can be added back later when Python 3 support is ready). Let me know if you are good with this change. Thanks, Scott [1] https://sourceforge.net/p/presage/presage-debian/merge-requests/1/ On Tue, 3 Dec 2019, Matteo Vescovi wrote: Hi Scott, Someone approached me and volunteered to port presage to Python 3 in late October, but I haven't heard back since them. Let me take a look at what kind of an effort it would be to port to python 3: that would be my preferred option if I can find the time to do. Else, the suggestion to remove the python pieces sound like the next best thing, if I can't find the time to port to python 3 now, we can then later reintroduce the python pieces. What are the planned timelines for the python 2 removal? Cheers, - Matteo On Tuesday, 3 December 2019, 05:02:48 CET, Scott Talbert wrote: On Mon, 2 Dec 2019, Scott Talbert wrote: >> Python2 becomes end-of-live upstream, and Debian aims to remove >> Python2 from the distribution, as discussed in >> https://lists.debian.org/debian-python/2019/07/msg00080.html >> >> Your package either build-depends, depends on Python2, or uses Python2 >> in the autopkg tests. Please stop using Python2, and fix this issue >> by one of the following actions. > > Hi Matteo, > > Do you plan to port presage to Python 3? If not, I'll probably convert this > to an RM request as the package seems to be mostly unmaintained and is > blocking the removal of Python 2. Alternatively, perhaps just the Python pieces of presage can be removed, as those don't seem to have any rdepends? Scott
Bug#917128: udev 240 breaks network interface naming
I have the same problem Failed to rename network interface 2 from 'enxXXX to 'wan': Device or resource busy I noticed the following line in the journal that before udevd fails, systemd-networkd[293]: enxXXX : IPv6 successfully enabled so I tried to disable ipv6 in /etc/sysctl.conf by setting net.ipv6.conf.all.disable_ipv6 = 1 net.ipv6.conf.default.disable_ipv6 = 1 net.ipv6.conf.lo.disable_ipv6 = 1 which after rebooting solved the problem. Not sure if I stumbled upon the right solution but I hope it helps.
Bug#885928: (no subject)
For me fixed with this: sudo chown -R _apt:root /var/lib/apt/lists
Bug#948501: [Pkg-roundcube-maintainers] Bug#948501: Wrong Dependency
Hi, On Sat, 25 Jan 2020 at 02:16:01 +0100, mar...@mitzlaff.eu wrote: > I just faced a similar problem. I tried to install the roundcube 1.4.2 from > Sid into my Buster system. Doesn't seem to match Marc's environment. > I think roundcube 1.4.2 needs a dependency to libjs-bootstrap4 (>=4.4.1). See https://bugs.debian.org/948011#15 . Cheers, -- Guilhem. signature.asc Description: PGP signature
Bug#948501: Wrong Dependency
Hallo, I just faced a similar problem. I tried to install the roundcube 1.4.2 from Sid into my Buster system. This symlinks in /usr/share/roundcube/skins/elastic/deps did not resolve: lrwxrwxrwx 1 root root 60 Jan 1 23:09 bootstrap.bundle.min.js -> ../../../../nodejs/bootstrap/dist/js/bootstrap.bundle.min.js lrwxrwxrwx 1 root root 55 Jan 1 23:09 bootstrap.min.css -> ../../../../nodejs/bootstrap/dist/css/bootstrap.min.css The problem is in Buster there is libjs-bootstrap4 (4.3.1+dfsg2-1) and in Sid there is libjs-bootstrap4 (4.4.1+dfsg1-1). The 4.3.1 stores the nodejs in /usr/lib/nodejs/ and 4.4.1 in /usr/share/nodejs/. I think roundcube 1.4.2 needs a dependency to libjs-bootstrap4 (>=4.4.1). Greetings Martin
Bug#903552: /var/lib/apt/lists must be owned by '_apt'.
|/var/lib/apt/lists must be owned by '_apt'. | ** *So for me this fix worked: * |sudo chown -R _apt:root /var/lib/apt/lists |
Bug#949786: thunar: "Use a custom command" doesn't work to open a file
Package: thunar Version: 1.8.4-1 Severity: normal Dear Maintainer, In thunar (debian stable), right clicking a file and entering something in "use a custom command" does not open the file. I was trying to open image files with feh -B black but I suspect this is true of any file. XFCE's "mime type editor" in the applications menu does work to set all future associations, but anyway, this does not -- System Information: Debian Release: 10.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages thunar depends on: ii desktop-file-utils 0.23-4 ii exo-utils 0.12.4-1 ii libatk1.0-0 2.30.0-2 ii libc6 2.28-10 ii libcairo2 1.16.0-4 ii libexo-2-0 0.12.4-1 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libglib2.0-02.58.3-2+deb10u2 ii libgtk-3-0 3.24.5-1 ii libgudev-1.0-0 232-2 ii libice6 2:1.0.9-2 ii libnotify4 0.7.7-4 ii libpango-1.0-0 1.42.4-7~deb10u1 ii libsm6 2:1.2.3-1 ii libthunarx-3-0 1.8.4-1 ii libxfce4ui-2-0 4.12.1-3 ii libxfce4util7 4.12.1-3 ii libxfconf-0-2 4.12.1-1 ii shared-mime-info1.10-1 ii thunar-data 1.8.4-1 Versions of packages thunar recommends: ii dbus-user-session [default-dbus-session-bus] 1.12.16-1 ii dbus-x11 [dbus-session-bus] 1.12.16-1 ii gvfs 1.38.1-5 ii libcairo-gobject2 1.16.0-4 ii libpangocairo-1.0-0 1.42.4-7~deb10u1 ii libxfce4panel-2.0-4 4.12.2-1 ii policykit-1-gnome [polkit-1-auth-agent] 0.105-7 ii thunar-volman 0.9.1-1 ii tumbler 0.2.3-1 ii udisks2 2.8.1-4 ii xdg-user-dirs 0.17-2 Versions of packages thunar suggests: ii thunar-archive-plugin 0.4.0-2 ii thunar-media-tags-plugin 0.3.0-2 -- no debconf information
Bug#944826: RFP: libjs-jquery-stickytableheaders -- stick table headers to the top of a viewport when scrolling
On Fri, 24 Jan 2020, Nicholas D Steeves wrote: > I would sincerely appreciate it if someone would take a look at this > RFP :-) Wrong team? JavaScript has absolutely nothing to do with Java. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Bug#949785: Unable extract with --files-from archieve members with space symbols in their names
If the names of archive members contain spaces, then when you try to extract them using --files-from=file-name -T file-name an error message is displayed and the operation is canceled. I am sorry, slip-up. True Example: $ mkdir "test 1" $ echo "asdfghh" > "test 1/test 1.txt" $ tar -czv -f "test 1.tar.xz" "test 1" $ echo "test 1/" > "list.txt" $ echo "test 1/test 1.txt" >> "list.txt" $ tar -xv -f "test 1.tar.xz" -T list.txt" test 1/ test 1/test 1.txt tar: test 1/list.txt: Not found in archive tar: Exiting with failure status due to previous errors But it's OK running: $ tar -xv -f "test 1.tar.xz" "test 1/test 1.txt" test 1/test 1.txt
Bug#949785: Tar - Unable extract with --files-from archieve members with space symbols in their names
Package: tar Version: 1.30+dfsg-6+b1 Severity: normal -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-6-amd64 (SMP w/8 CPU cores) Locale: LANG=ru_RU.utf8, LC_CTYPE=ru_RU.utf8 (charmap=UTF-8), LANGUAGE=ru_RU.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages tar depends on: ii libacl1 2.2.53-5 ii libc62.29-9 ii libselinux1 3.0-1 tar recommends no packages. Versions of packages tar suggests: ii bzip21.0.8-2 pn ncompress pn tar-doc pn tar-scripts ii xz-utils 5.2.4-1+b1 -- no debconf information If the names of archive members contain spaces, then when you try to extract them using --files-from=file-name -T file-name an error message is displayed and the operation is canceled. Example: $ mkdir "test 1" $ echo "asdfghh" > "test 1/test 1.txt" $ tar -czv -f "test 1.tar.xz" "test 1" $ echo "test 1/" > "list.txt" $ echo "test 1/test 1.txt" >> "list.txt" $ tar -xv -f "test 1.tar.xz" "test 1/list.txt" test 1/ test 1/test 1.txt tar: test 1/list.txt: Not found in archive tar: Exiting with failure status due to previous errors But it's OK running: $ tar -xv -f "test 1.tar.xz" "test 1/test 1.txt" test 1/test 1.txt
Bug#949784: ITP: pep517 -- Specifies a standard API for systems which build Python packages
Package: wnpp Severity: wishlist Owner: Scott Kitterman * Package name: pep517 Version : 0.7.0 Upstream Author : Thomas Kluyver * URL : https://pypi.org/project/pep517/ * License : Expat Programming Lang: Python Description : Specifies a standard API for systems which build Python packages This package contains wrappers around the hooks specified by PEP 517. It provides: . - A mechanism to call the hooks in a subprocess, so they are isolated from the current process. - Fallbacks for the optional hooks, so that frontends can call the hooks without checking which are defined. - Higher-level functions which install the build dependencies into a temporary environment and build a wheel/sdist using them. . This is the Python 3 version of the package. This is needed as a dependency for newer version of Python's pip. It will be maintained in the DPMT. There is a newer version available, but 0.7.0 is the version pip specifies as a requirement, so I intend to match that as there are no other users. This is part of Debian's effort to not use vendored modules that upstream pip uses. Scott K
Bug#944826: RFP: libjs-jquery-stickytableheaders -- stick table headers to the top of a viewport when scrolling
Dear Java Team, I would sincerely appreciate it if someone would take a look at this RFP :-) Please CC this bug for any replies. Thanks! Nicholas On Fri, Nov 15, 2019 at 09:16:41PM -0500, Nicholas D Steeves wrote: > Package: wnpp > Severity: wishlist > Control: block 944704 by -1 > > Package name: libjs-jquery-stickytableheaders > Version : 0.1.24 > Upstream Author : Jonas Mosbech > URL : https://github.com/jmosbech/StickyTableHeaders > License : MIT > Programming Lang: JS > Description : stick table headers to the top of a viewport when scrolling > > StickyTableHeaders is a jQuery plugin that sticks table headers to the > top of a viewport. When scrolling through a long vertical list it > is easy for forget what header each column refers to. > StickyTableHeaders solves this issue by keeping column headers visible > at all times so that the user doesn't need to regularly scroll to the > top of a table. > > Upstream demo: https://jsfiddle.net/jmosbech/stFcx/ > > I discovered this package while working on org-html-themes, which > depends on StickyTableHeaders. Other than that, I am frequently > frustrated by websites that exhibit the issue this software solves > (eg: Wikipedia has this issue). While I'm generally sympathetic to > the "nojs" approach to web browsing, I believe that most users of > "nojs" would probably white-list StickyTableHeaders, because of how it > dramatically enhances the experience of reading long tables. I am not > aware of other packages that provide this functionality. > > Please consider packaging it soon! :-) > > > Thank you, > Nicholas signature.asc Description: PGP signature
Bug#949783: RFS: milter-greylist/4.6.2-1 [QA] -- Greylist milter for sendmail
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "milter-greylist" * Package name: milter-greylist Version : 4.6.2-1 Upstream Author : Emmanuel Dreyfus * URL : http://hcpnet.free.fr/milter-greylist/ * License : BSD * Vcs : https://salsa.debian.org/debian/milter-greylist Section : mail It builds those binary packages: milter-greylist - Greylist milter for sendmail To access further information about this package, please visit the following URL: https://mentors.debian.net/package/milter-greylist Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/m/milter-greylist/milter-greylist_4.6.2-1.dsc Changes since the last upload: * QA upload. * Update to v4.6.2 (Closes: #881154) * Add dependency on lsb-base. * Disable init.d script using dh_installinit. - Ref. Debian Policy Manual section 9.3.3.1 * Use proper home with adduser. * Orphan the package (See: #889305) * Update compat level to 12. * Remove dependency on autotools-dev and quilt. * Update Standards-Version to 4.4.1 - Change priority to optional. * Add dependency on init-system-helpers. * Add predends on misc. * Maintainer script should not use recursive chown. * Add commented patch file in series. * Add vcs link to salsa. -- Regards Sudip
Bug#949782: ITP: python-ezcolor -- Python colorizing strings library (Python 3)
Package: wnpp Severity: wishlist Owner: Marcos Fouces * Package name: python-ezcolor Version : 0.7 Upstream Author : Fardin Allahverdinazhand <0x0ptim...@gmail.com> * URL : https://github.com/0x0ptim0us/ezcolor * License : MIT Programming Lang: Python Description : Python colorizing strings library (Python 3) A lightweight library for applying color and HTML text styles to the strings that uses the builder pattern for configuration. The ezcolor lets you have nice colorized output with extra HTML text styles like bold/italic/underline. compatible with bash/sh/zsh. This package is needed for the new release of websploit. I plan to maintain it under DPMT umbrella.
Bug#949779: stunnel4: fails to work as client when stdin is a pipe
Dixi quod…
>>This is a showstopper for using stunnel in client mode…
Hrm… doing it like this works; I was deep in yak shaving
and probably should have thought of this earlier:
$ { cat a; sleep 1; } | stunnel4 x
Basically, I was chasing a lot of issues at the same time.
If you don’t see anything in error, I think this can be closed.
Sorry,
//mirabilos
--
Beware of ritual lest you forget the meaning behind it.
yeah but it means if you really care about something, don't
ritualise it, or you will lose it. don't fetishise it, don't
obsess. or you'll forget why you love it in the first place.
Bug#898246: git-lab requires golang-github-xanzy-go-gitlab
Hi Julian, On Fri, Jan 24, 2020 at 3:39 AM Julian Gilbey wrote: > > The version of xanzy in debian/sid on salsa is very out of date - the > upstream version is now 0.22, but debian/sid is lagging on 0.15. State of package on Mentors (based on upstream's version 0.22) was pushed to the golang team repo. Kind regards Felix Lechner
Bug#949779: stunnel4: fails to work as client when stdin is a pipe
Control: notfound -1 3:4.29-1+squeeze1 Thorsten Glaser dixit: >$ cat a | stunnel4 x >$ stunnel4 x This is a showstopper for using stunnel in client mode… The client configuration looks like this: client = yes connect = host:port socket = r:SO_KEEPALIVE=1 socket = r:TCP_KEEPCNT=4 socket = r:TCP_KEEPIDLE=40 socket = r:TCP_KEEPINTVL=5 sslVersion = TLSv1 Adding “foreground = yes” merely makes the logging come back to stderr, as it was in squeeze. -- System Information: Debian Release: bullseye/sid APT prefers buildd-unstable APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) Versions of packages stunnel4 depends on: ii adduser3.118 ii libc6 2.29-9 ii libelogind0 [libsystemd0] 241.3-1+debian2 ii libssl1.1 1.1.1d-2 ii libwrap0 7.6.q-30 ii lsb-base 11.1.0 ii netbase6.0 ii openssl1.1.1d-2 ii perl 5.30.0-9 stunnel4 recommends no packages. Versions of packages stunnel4 suggests: pn logcheck-database -- no debconf information //mirabilos -- Stéphane, I actually don’t block Googlemail, they’re just too utterly stupid to successfully deliver to me (or anyone else using Greylisting and not whitelisting their ranges). Same for a few other providers such as Hotmail. Some spammers (Yahoo) I do block.
Bug#948730: stretch-pu: package libtest-mocktime-perl/0.17-0+deb9u1
Control: tags -1 + confirmed On Sun, 2020-01-12 at 18:47 +0200, Adrian Bunk wrote: > * New upstream release. > - Only change is a fix for a build failure in the year 2020 > and later. (Closes: #948669) > Please go ahead. Regards, Adam
Bug#948737: stretch-pu: package python-pgmagick/0.6.4-1+deb9u1
Control: tags -1 + confirmed On Sun, 2020-01-12 at 20:27 +0200, Adrian Bunk wrote: > * Backport upstream FTBFS fix to handle version detection > of graphicsmagick security updates that identify themself > as version 1.4. > Please go ahead. Regards, Adam
Bug#948855: buster-pu: package iputils/3:20180629-2
Control: tags -1 + moreinfo On Mon, 2020-01-13 at 19:12 -0500, Noah Meyerhans wrote: > I'd like to fix > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947921 in > buster. Ping has some issues coping with explicitly specified source > interfaces when pinging DNS names and DNS returns multiple addresses > via getaddrinfo(). Please see the commit messages and the bug report > for in-depth explanation of what's going on. The metadata for that bug report suggests that it affects the iputils package in unstable, and is not currently fixed there. Is that correct? Regards, Adam
Bug#949781: RFH: mawk
Package: wnpp Severity: normal X-Debbugs-CC: debian-de...@lists.debian.org Hi all, TL;DR: I'm looking for people to help with packaging the new upstream release of mawk into Debian. Co-maintainers are also welcome. Mawk is an important implementation of AWK and is of Priority: required. However, Debian's mawk hasn't been updated even if there's a new upstream since 2009. You can find some of the new upstream's comments over this issue at https://invisible-island.net/mawk/ . Currently as the new package maintainer, I believe it's necessary to find more co-maintainers and uploaders who are more familiar with AWK than me. Tasks include packaging new upstream releases, testing possible regressions and going through everything currently lying in the Bug Tracking System. The previous work can be found on Salsa packaging repo. I'm open to direct git commits on Salsa and NMUs as long as they do not introduce obvious regression （and break all reverse build-dependencies, a.k.a. almost everything in the archive :-). -- Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#948899: buster-pu: package libspreadsheet-wright-perl/0.105-1~deb10u1
Control: tags -1 + confirmed On Tue, 2020-01-14 at 18:26 +0200, mer...@debian.org wrote: > libspreadsheet-wright-perl in Buster has a bunch of obvious bugs that > render parts of its functionality unusable. This update contains > patches for three bugs: Does that imply that no-one actually uses the package, or are these simply not commonly used areas? > * fixes previously unusable OpenDocument Spreadsheets [1]; > * fixes previously unusable multisheet OpenDocument Spreadsheets [2]; > * fixes passing JSON formatting options [3]. +libspreadsheet-wright-perl (0.105-1~deb10u1) buster; urgency=medium + + * Patching https://rt.cpan.org/Ticket/Display.html?id=128919. + * Patching https://rt.cpan.org/Ticket/Display.html?id=131334. + * Patching https://github.com/tobyink/p5-spreadsheet-wright/issues/5 . The changelog entries here would probably benefit from being more similar to your descriptions in this report, given that they will be displayed to users. Please go ahead. Regards, Adam
Bug#948898: stretch-pu: package libidn/1.33-1
Control: tags -1 + confirmed On Tue, 2020-01-14 at 17:01 +0100, Santiago R.R. wrote: > as suggested by Salvatore, I would like to propose fixing CVE-2017- > 14062 (#873903) in libidn via an update to stretch. Please find the > debdiff attached. The tests I have made are described above. > Please go ahead. Regards, Adam
Bug#948991: buster-pu: package schleuder/3.4.0-2+deb10u2
Control; tags -1 + confirmed On Wed, 2020-01-15 at 18:01 +, Georg Faerber wrote: > Schleuder in buster (proposed-updates) is affected by various > problems, which I would like to fix: > > - Add missing List-Id header to notification mails sent to admins: > This should help with filtering such messages, which is currently > not easy to do in a reliable way. (Closes: #948980) > > - Handle various exceptions due to decryption problems gracefully: > Handle incoming mails encrypted to an absent key, using symmetric > encryption or containing PGP-garbage in a more graceful manner: > Don't throw an exception, don't notify (and annoy) the admins, > instead inform the sender of the mail how to do better. > (Closes: #948981) > > - Default to ASCII-8BIT encoding for external data: > This should ensure Schleuder is able to handle incoming mails in > different character sets. Currently Schleuder may run into a fatal > error due to "invalid byte sequence in US-ASCII". (Closes: #948982) > Please go ahead. Regards, Adam
Bug#948910: buster-pu: package qwinff/0.2.1-1+deb10u1
Control: tags -1 + confirmed On Tue, 2020-01-14 at 12:41 -0500, Boyuan Yang wrote: > As discussed in https://bugs.debian.org/945602 , I'd like to make an > upload of qwinff/0.2.1-1+deb10u1 to address this bug in Buster. This > bug caused the software to crash every time it starts thus it's worth > fixing. > It's a little worrying (and/or suggestive of low use) that we managed to release the package with such an issue, but please go ahead. Regards, Adam
Bug#949779: stunnel4: fails to work as client when stdin is a pipe
Package: stunnel4 Version: 3:5.56-1 Severity: important Watch this: $ cat a GET /cgi-bin/conninfo.cgi HTTP/1.0 Host: XXX $ cat a | stunnel4 x $ stunnel4 x https://www.stunnel.org/pipermail/stunnel-users/2009-January/002223.html This is a showstopper for using stunnel in client mode… -- System Information: Debian Release: bullseye/sid APT prefers buildd-unstable APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) Versions of packages stunnel4 depends on: ii adduser3.118 ii libc6 2.29-9 ii libelogind0 [libsystemd0] 241.3-1+debian2 ii libssl1.1 1.1.1d-2 ii libwrap0 7.6.q-30 ii lsb-base 11.1.0 ii netbase6.0 ii openssl1.1.1d-2 ii perl 5.30.0-9 stunnel4 recommends no packages. Versions of packages stunnel4 suggests: pn logcheck-database -- no debconf information
Bug#949780: maptool: Maptool segfaults
Package: maptool Version: 0.5.3+dfsg.1-2+b1 Severity: grave Justification: renders package unusable Trying to use maptool with a .pbf file gave a segfault almost immediately. Compiling my own maptool directly from the navit git gave a working version. This was encountered while looking at the issues with navit on wince: see https://github.com/navit-gps/navit/issues/953#issuecomment-578313710 Search down that page to see the problem with the Debian testing maptool: maptool --protobuf -i /ssdback1/ael/mapping/mkgmap/great-britain-latest.osm.pbf test.bin but that SEGFAULTED almost immediately after writing some empty *.tmp files. gdb shows Program terminated with signal SIGSEGV, Segmentation fault. #0 0x55c63a68cf30 in osmpbf.blob_header.init () Backtrace showed: (gdb) bt #0 0x55c63a68cf30 in osmpbf.blob_header.init () #1 0x55c63a6917da in protobuf_c_message_unpack () #2 0x55c63a68a7ec in ?? () #3 0x55c63a68abb8 in map_collect_data_osm_protobuf () #4 0x55c63a679e73 in main () I see that there is a new version in unstable but I have not tried that version as yet. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages maptool depends on: ii libc6 2.29-9 ii libglib2.0-0 2.62.4-1 ii zlib1g1:1.2.11.dfsg-1+b1 maptool recommends no packages. Versions of packages maptool suggests: pn navit -- no debconf information
Bug#949121: buster-pu: package node-kind-of/6.0.2+dfsg-1+deb10u1
Control: tags -1 + confirmed On Fri, 2020-01-17 at 06:25 +0100, Xavier Guimard wrote: > node-kind-of is vulnerable to CVE-2019-20149: it allows external user > input to overwrite certain internal attributes via a conflicting > name. > Please go ahead. Regards, Adam
Bug#554167: New mawk upstream version
Control: tags -1 + help 在 2020-01-24五的 10:22 +0100，Laurent Bigonville写道： > On Tue, 3 Nov 2009 22:16:42 +0800 Trafire Arcanegrin > wrote: > > > Hello, > > 1.3.3-20090920 is here: > > ftp://invisible-island.net/mawk > > > > Please consider update it. :-) > > > > Hello, > > Now that the package has been salvaged, are there any plans to update > mawk to the latest release? > > I've at least one issue in one of my packages that is fixed in the > latest release The latest work is at https://salsa.debian.org/debian/mawk . Personally I am not a frequent user of *awk at all and for packaging there are also more work to do before uploading a new version. Any help would be welcome, including becoming a co-maintainer. (I think I will file a RFH bug later.) -- Thanks, Boyuan Yang
Bug#949745: firefox-esr 68.4 don't start if installed gcc 9.2.1-24
Package: gcc-9-base Version: 9.2.1-24 With GCC version 9.2.1-25 firefox-esr 68.4.1 esr-1 firefox-esr 68.4.2 esr-1 normally start and work. Thanks.
Bug#949704: buster-pu: package opensmtpd/6.0.3p1-5
Control: tags -1 + confirmed On Thu, 2020-01-23 at 16:44 -0500, Ryan Kavanagh wrote: > The proposed change fixes bug #948824, which rendered the package > uninstallable when `hostname --fqdn` exited with a non-zero exit > code. I've tested it locally and the bug reporter has also confirmed > that the patch fixes the bug. The bug was fixed by opensmtpd 6.6.1p1- > 5 (already in unstable). > Please go ahead. Regards, Adam
Bug#949778: ruby-oembed: autopkgtest needs update for new version of gem2deb: missing skippable restriction
Source: ruby-oembed Version: 0.12.0-2 Severity: serious X-Debbugs-CC: debian...@lists.debian.org, gem2...@packages.debian.org Tags: sid bullseye User: debian...@lists.debian.org Usertags: needs-update Control: affects -1 src:gem2deb Dear maintainers, With a recent upload of gem2deb the autopkgtest of ruby-oembed fails in testing when that autopkgtest is run with the binary packages of gem2deb from unstable. It passes when run with only packages from testing. In tabular form: passfail gem2debfrom testing1.0.3 ruby-oembedfrom testing0.12.0-2 all others from testingfrom testing I copied some of the output at the bottom of this report. The cause of this is that gem2deb started to exit with code 77 to indicate that there is no test to run. This is meant to be used in conjunction with the skippable restriction, to avoid giving the wrong information to the migration software. Please add the skippable restriction to your package, or better, add a real test. Currently this regression is blocking the migration of gem2deb to testing [1]. Of course, gem2deb shouldn't just break your autopkgtest (or even worse, your package), but it seems to me that the change in gem2deb was intended and your package needs to update to the new situation. If needed, please change the bug's severity. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=gem2deb https://ci.debian.net/data/autopkgtest/testing/amd64/r/ruby-oembed/4079292/log.gz autopkgtest [21:12:45]: test command1: gem2deb-test-runner --autopkgtest 2>&1 autopkgtest [21:12:45]: test command1: [--- ┌──┐ │ Run tests for ruby2.5: no test suite! │ └──┘ autopkgtest [21:12:45]: test command1: ---] autopkgtest [21:12:46]: test command1: - - - - - - - - - - results - - - - - - - - - - command1 FAIL non-zero exit status 77 signature.asc Description: OpenPGP digital signature
Bug#949777: pngnq: should not log to syslog
Package: pngnq Version: 1.0-2.3+b1 Severity: normal Dear Maintainer, pngnq unconditionally logs most errors and warnings tgo syslog. This makes little sense in most circumstances. It would nice if pngnq wouldn't log to syslog by default. -- System Information: Debian Release: 10.2 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-updates'), (500, 'stable-debug'), (500, 'oldstable-updates'), (500, 'oldstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 5.4.12-050412-generic (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), LANGUAGE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages pngnq depends on: ii libc62.28-10 ii libpng16-16 1.6.36-6 ii zlib1g 1:1.2.11.dfsg-1 pngnq recommends no packages. pngnq suggests no packages. -- no debconf information
Bug#949728: buster-pu: package modsecurity/3.0.3-1
Control: tags -1 + confirmed On Fri, 2020-01-24 at 09:42 +0100, Alberto Gonzalez Iniesta wrote: > A security issue (CVE-2019-19886) was found in Modsecurity 3.0.3. [1] > A fixed package is already in unstable. This upload only applies > upstream patch to fix that. Please consider 3.0.3-1+deb10u1 for the > next buster update. > Please go ahead. Regards, Adam
Bug#949638: tesseract: uses -march=native
Am 24.01.20 um 21:53 schrieb peter green: > I still don't think -march=native is appropriate for a binary > distribution though. If you want to offer different versions of the > code built with different CPU requirements, that is fine, but please > don't let them depend on what CPU happens to be in the autobuilder. Better ideas are welcome. Tesseract is used for mass processing of books which can take many weeks or even months. Therefore it is very important that the time critical code (dot product calculation) runs as fast as possible. For x86_64 we know the available SIMD instructions (SSE, AVX, ...) which can be used, add code for all variants and check at runtime what is supported by the CPU. For all other architectures (including ARM) there is currently no such special code, and the default code is rather slow. By using -march=native for the alternate code, hopefully the compiler will produce code which runs faster on any machine which is similar to the build machine. Users who build Tesseract on the machine which is also used for the mass production will get the best result like that. Users using a distribution can try the "native" option and either crash the program or get a possibly faster result. I see the problem of builds which depend on an autobuilder which may be different for each build. What would be the best solution for distributions? Suppress the code using a new configure option or some magic which detects that the build is for a Debian distribution? Choose compiler flags manually for the "native" option (that is already possible, see my previous answer)? Other solutions? Stefan
Bug#941126: stretch-pu: package dehydrated/0.6.2-2+deb9u1
On Sat, 2020-01-18 at 15:51 +0100, Mattia Rizzolo wrote: [...] > On Wed, Sep 25, 2019 at 10:59:58AM +0200, Mattia Rizzolo wrote: [...] > > From what I can see, the breakages would pretty much account to the > > following: > > * you need a new --accept-terms flag while creating a new account > >(might break autoamted deployments who need to create a new > > account?) > > * only since v0.6.0 the upstream developer made clear that users > > should not hardcode a list of hook, and it's known many users did > > it, so hook scripts may break due to unknown hook types > > * this also changes the default endpoint to ACMEv2. It should be > >totally transparent for most users, and those who really need > > ACMEv1 (why?) would need to explicitly specify it. > To this list I need to add that apparently the DNS verification might > break if the user used a single TXT record that the several > _acme_challenge.* CNAMEd to., as now dehydrated deployes all the > challenges in one go and then asks LE to check, instead of doing one > at a time. There is a simple workaround to this by using HOOK_CHAIN > plus a forgiving hook script. > > I still consider the above "breakages" totally acceptable, as we > really ought to welcome ACMEv2 in face of those 4 trivialities above. I'm aware that you both called them trivialities and quoted "breakages", but is it worth documenting any of them somewhere in the package? Regards, Adam
Bug#949326: [Pkg-kde-extras] Bug#949326: transition: libgwenhywfar
Control: tags -1 confirmed Hi Micha, On 23-01-2020 22:22, Micha Lenk wrote: > I think we are now ready to start the transition (moreinfo tag removed). > Let me summarize again the planned transition actions: > - micha: upload libgwenhywfar/5.1.2-1 (in experimental) to unstable > - micha: upload libaqbanking/6.0.1-1 (in experimental) to unstable > - micha: upload libchipcard/5.1.5rc2-3 (in experimental) to unstable > - micha(?): schedule binNMU for gnucash to pickup the new SONAMEs. > - pino: upload kmymoney/5.0.8-1 to unstable > > Please let me know if you have any comments or suggestions. Release > team, your turn. :) Please go ahead with this set in unstable. Paul signature.asc Description: OpenPGP digital signature
Bug#949638: tesseract: uses -march=native
Severity 949638 normal Thanks On 24/01/2020 19:16, Stefan Weil wrote: As far as I know all Linux distributions use the autoconf based build, Debian certainly does appear to be using the autoconf based build. The default autoconf build uses -march=native only if it is supported by the compiler Which, of course it is. and only for a single file, but not for the rest of the code. The code from that single file is not executed by default, but only if an advanced user runs Tesseract with a special command line option (-c dotproduct=native). Ok, that dramatically reduces the impact of this issue. Downgrading the bug to normal. I still don't think -march=native is appropriate for a binary distribution though. If you want to offer different versions of the code built with different CPU requirements, that is fine, but please don't let them depend on what CPU happens to be in the autobuilder.
Bug#949775: libsimgrid-java: missing (unversioned) Breaks+Replaces: simgrid-java
Package: libsimgrid-java Version: 3.24+dfsg-4 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package fails to upgrade from 'testing'. It installed fine in 'testing', then the upgrade to 'sid' fails because it tries to overwrite other packages files without declaring a Breaks+Replaces relation. See policy 7.6 at https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces >From the attached log (scroll to the bottom...): Preparing to unpack .../libsimgrid-java_3.24+dfsg-4_amd64.deb ... Unpacking libsimgrid-java (3.24+dfsg-4) ... dpkg: error processing archive /var/cache/apt/archives/libsimgrid-java_3.24+dfsg-4_amd64.deb (--unpack): trying to overwrite '/usr/lib/libsimgrid-java.so.3.24', which is also in package simgrid-java 3.24+dfsg-1.1 dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) Errors were encountered while processing: /var/cache/apt/archives/libsimgrid-java_3.24+dfsg-4_amd64.deb Since the simgrid-java package is gone from sid, the B+R should be unversioned. cheers, Andreas simgrid-java=3.24+dfsg-1.1_libsimgrid-java=3.24+dfsg-4.log.gz Description: application/gzip
Bug#949776: wiredtiger FTBFS
Source: wiredtiger Version: 3.2.0-1 Severity: serious Tags: ftbfs https://buildd.debian.org/status/package.php?p=wiredtiger https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/wiredtiger.html Seems there was a test failure, and now there is additionally a build failurre.
Bug#949743: ceph-osd crashes when osd_memory_target is set in config
Hi Martin, > When osd_memory_target is present in config ceph-osd refuses to start: > > # ceph config set osd osd_memory_target 2147483648 > > # /usr/bin/ceph-osd -d --cluster ceph --id 0 --setuser ceph --setgroup ceph > (cut) I gave this a try in bullseye, with the same result. The first idea I have is a that a patch, that fixes the build on 32bit systems, introduced this bug. Although I fail to understand why as should not make a difference on 64bit systems. I'm building a version without these patches and see what happens. Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#949774: votca-tools: missing Breaks+Replaces: libvotca-tools-dev (<< 1.6~)
Package: votca-tools Version: 1.6~rc1-1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package fails to upgrade from 'testing'. It installed fine in 'testing', then the upgrade to 'sid' fails because it tries to overwrite other packages files without declaring a Breaks+Replaces relation. See policy 7.6 at https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces >From the attached log (scroll to the bottom...): Preparing to unpack .../votca-tools_1.6~rc1-1_amd64.deb ... Unpacking votca-tools (1.6~rc1-1) ... dpkg: error processing archive /var/cache/apt/archives/votca-tools_1.6~rc1-1_amd64.deb (--unpack): trying to overwrite '/usr/share/man/man1/votca_property.1.gz', which is also in package libvotca-tools-dev 1.5.1-1 Errors were encountered while processing: /var/cache/apt/archives/votca-tools_1.6~rc1-1_amd64.deb cheers, Andreas libvotca-tools-dev=1.5.1-1_votca-tools=1.6~rc1-1.log.gz Description: application/gzip
Bug#935070: [lintian] Tags are too similar
Control: reopen -1 > > Did you see a d/changelog that triggered the latter but not the former? > > Yes:packagename (upstreamversion-1~wtf1) > followed by packagename (upstreamversion-1) > > (or even ~bpo10+1, when there was not the word “backport” in the > changelog text) Reopening for further examination.
Bug#949773: ns3: unsatisfiable cross Build-Depends
Source: ns3 Version: 3.30+dfsg-3.1 Tags: patch User: debian-cr...@lists.debian.org Usertags: cross-satisfiability ns3 cannot satisfy its cross Build-Depends for lots of reasons. It turns out that many of its Build-Depends are only needed for ns3-doc, which happens to be Architecture: all. By slightly tweaking debian/rules, we can move a good chunk of Build-Depends to Build-Depends-Indep making them irrelevant to cross building. This does not make ns3 cross buildable, but is a significant step in that direction. Please consider applying the attached patch and close this bug when doing so. Helmut diff --minimal -Nru ns3-3.30+dfsg/debian/changelog ns3-3.30+dfsg/debian/changelog --- ns3-3.30+dfsg/debian/changelog 2020-01-20 00:21:22.0 +0100 +++ ns3-3.30+dfsg/debian/changelog 2020-01-24 16:45:47.0 +0100 @@ -1,3 +1,12 @@ +ns3 (3.30+dfsg-3.2) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Don't build documentation during arch-only. + * Drop support for DEB_BUILD_OPTIONS=nodoc, build indep-only instead. + * Demote a lot of dependencies to B-D-I. (Closes: #-1) + + -- Helmut Grohne Fri, 24 Jan 2020 16:45:47 +0100 + ns3 (3.30+dfsg-3.1) unstable; urgency=medium * Non-maintainer upload. diff --minimal -Nru ns3-3.30+dfsg/debian/control ns3-3.30+dfsg/debian/control --- ns3-3.30+dfsg/debian/control2020-01-20 00:21:21.0 +0100 +++ ns3-3.30+dfsg/debian/control2020-01-24 16:45:47.0 +0100 @@ -13,19 +13,20 @@ flex, libboost-filesystem-dev, libboost-signals-dev, - libgraphviz-dev, libgsl-dev, libopenmpi-dev [alpha amd64 hurd-i386 i386 ia64 kfreebsd-amd64 kfreebsd-i386 powerpc sparc], libsqlite3-dev, libxml2-dev, pkg-config, python3-dev, - quilt (>= 0.46-7~), gir1.2-goocanvas-2.0, python3-gi, python3-gi-cairo, python3-pygraphviz, gir1.2-gtk-3.0, +Build-Depends-Indep: + libgraphviz-dev, + quilt (>= 0.46-7~), ipython3, dia, dvipng, diff --minimal -Nru ns3-3.30+dfsg/debian/rules ns3-3.30+dfsg/debian/rules --- ns3-3.30+dfsg/debian/rules 2019-09-16 11:18:03.0 +0200 +++ ns3-3.30+dfsg/debian/rules 2020-01-24 16:45:47.0 +0100 @@ -26,18 +26,10 @@ %: dh $@ --with python3 -build-indep: build-doc-stamp - -build-doc-stamp: -ifeq (,$(filter nodoc,$(DEB_BUILD_OPTIONS))) +override_dh_auto_build-indep: make html man -C ./$(NS3_DIR)/doc/manual/ SPHINXOPTS="$(SPHINXOPTS)" make html man -C ./$(NS3_DIR)/doc/models/ SPHINXOPTS="$(SPHINXOPTS)" make html man -C ./$(NS3_DIR)/doc/tutorial/ SPHINXOPTS="$(SPHINXOPTS)" -else - mkdir -p ./$(NS3_DIR)/doc/manual/build/html - mkdir -p ./$(NS3_DIR)/doc/models/build/html - mkdir -p ./$(NS3_DIR)/doc/tutorial/build/html -endif rm -f ns-3.*/doc/*/build/*/_static/jquery.js rm -f ns-3.*/doc/*/build/*/_static/underscore.js touch $@ @@ -48,7 +40,7 @@ --libexecdir=/usr/lib/$(DEB_HOST_MULTIARCH) \ --libdir=/usr/lib/$(DEB_HOST_MULTIARCH) -override_dh_auto_build: build-doc-stamp +override_dh_auto_build-arch: ### build and install shared libraries, python bindings for default python. cd $(NS3_DIR) ; ./waf build $(BUILD_OPTION)
Bug#949771: mark isoquery Multi-Arch: foreign
Package: isoquery
Version: 3.2.3-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
Control: affects -1 + src:efi-reader
efi-reader fails to cross build from source, because it fails running
isoquery with an Exec format error. Usually that means that the isoquery
dependency should be annotated :native or that isoquery should be marked
Multi-Arch: foreign. If the latter is correct, it is to be preferred. I
think in this case Multi-Arch: foreign is warranted, because isoquery is
a command line utility that deals with textual file formats (json
mostly). As such its behaviour does not differ when being run on a
different architecture. Please consider applying the attached patch.
Helmut
diff --minimal -Nru isoquery-3.2.3/debian/changelog
isoquery-3.2.3/debian/changelog
--- isoquery-3.2.3/debian/changelog 2018-08-18 22:22:21.0 +0200
+++ isoquery-3.2.3/debian/changelog 2020-01-24 16:20:44.0 +0100
@@ -1,3 +1,10 @@
+isoquery (3.2.3-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Mark isoquery Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne Fri, 24 Jan 2020 16:20:44 +0100
+
isoquery (3.2.3-1) unstable; urgency=medium
* New upstream version 3.2.3
diff --minimal -Nru isoquery-3.2.3/debian/control isoquery-3.2.3/debian/control
--- isoquery-3.2.3/debian/control 2018-01-21 16:39:17.0 +0100
+++ isoquery-3.2.3/debian/control 2020-01-24 16:20:43.0 +0100
@@ -13,6 +13,7 @@
Package: isoquery
Architecture: any
+Multi-Arch: foreign
Depends: ${shlibs:Depends}, ${misc:Depends}
Recommends: iso-codes
Description: Search and display various ISO codes (country, language, ...)
Bug#949772: convert python-cylc to Architecture: all
Package: python-cylc
Version: 7.8.4-1
Tags: patch
I looked into cross building cylc and noticed that the only
architecture-dependent package it contains - python-cylc - is not
actually architecture-dependent. All of its files are exactly equal
across all release architectures. It's a pure Python module. I found no
explanation as to why it must be Architecture: any. Please switch it to
Architecture: all. By doing so, cylc becomes irrelevant to cross
building. We also save some buildd time and archive space.
Helmut
diff --minimal -Nru cylc-7.8.4/debian/changelog cylc-7.8.4/debian/changelog
--- cylc-7.8.4/debian/changelog 2019-09-24 13:19:44.0 +0200
+++ cylc-7.8.4/debian/changelog 2020-01-24 16:51:56.0 +0100
@@ -1,3 +1,10 @@
+cylc (7.8.4-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Convert python-cylc to Architecture: all. (Closes: #-1)
+
+ -- Helmut Grohne Fri, 24 Jan 2020 16:51:56 +0100
+
cylc (7.8.4-1) unstable; urgency=medium
* New upstream release
diff --minimal -Nru cylc-7.8.4/debian/control cylc-7.8.4/debian/control
--- cylc-7.8.4/debian/control 2019-09-24 13:19:44.0 +0200
+++ cylc-7.8.4/debian/control 2020-01-24 16:51:56.0 +0100
@@ -35,7 +35,7 @@
Package: python-cylc
Section: python
-Architecture: any
+Architecture: all
Breaks: xdot (<< 0.7-2)
Replaces: xdot (<< 0.7-2)
Depends: ${python:Depends}, ${misc:Depends}, pyro, fonts-glewlwyd,
Bug#949770: ufo2otf: Please recommend or depend on python3-fontforge by default
Source: ufo2otf Version: 0.2.2-1.2 Severity: important Since Fontforge is an important (optional) dependency for ufo2otf, it should at least be listed in the Recommends: list. Considering its importance, it might also be a good idea to have it put into the Depends: list. -- Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#949769: the examples need to be modified to work
Package: arduino-mk Version: 1.5.2-1 Severity: normal The examples included in the package have the wrong path to Arduino.mk, so the user has to hunt it down and modify an example to get it to work. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-3-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_USER, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages arduino-mk depends on: ii arduino-core 2:1.0.5+dfsg2-4.1 ii make 4.2.1-1.2 ii python 2.7.17-2 ii python-serial 3.4-5 Versions of packages arduino-mk recommends: ii screen 4.7.0-1 arduino-mk suggests no packages. -- no debconf information -- see shy jo signature.asc Description: PGP signature
Bug#949768: say in release notes about that login screen of xfce desktop environment does not work well
package: release-notes xfce4 login screen becomes black and, unresponsive except to ctrl+alt+fN. see bug #870641 . i think such important bug should be mentioned in "known issues" or "release notes".
Bug#949638: tesseract: uses -march=native
It is not necessary to patch Tesseract code if for whatever reason -march=native is completely unwanted. `make libtesseract_native_la_CXXFLAGS=` will override the extra compiler flags which are used to produce the native code, so only the default flags which don't include -march=native will be used. Stefan
Bug#949638: tesseract: uses -march=native
> The URL for the patch is 404. s/tessarect/tesseract/ The fixed URL is https://debdiffs.raspbian.org/main/t/tesseract/. Stefan
Bug#764081: debci log and test-depends
Paul Gevers wrote: Unfortunately, old data on ci.d.n is flushed (too much disk space), so I need a new incident to properly investigate what is going on, as I haven't spotted the issue yet in the code. libgpuarray #949767, unstable 2020-01-24: https://ci.debian.net/packages/libg/libgpuarray/unstable/amd64/ src:pocl (pocl-opencl-icd, libpocl2-common, libpocl2) changed from 1.3-10 to 1.4-3 according to "test log"s, but isn't mentioned in "debci log". These (pocl-opencl-icd directly, the others via it) are test dependencies, not package dependencies. This isn't #812856 (diffing the wrong pair of logs), as the python-six versions listed are correct. As a temporary measure until we can really fix this, would it make sense to put a "This is NOT a complete diff of installed packages, see #764081" notice at the top of the debci log?
Bug#949747: closed by Simon McVittie (Re: Bug#949747: gimp: dependency versions missing)
thank you simon, i've passed that on to christian. l.
Bug#949638: tesseract: uses -march=native
Am 24.01.20 um 19:55 schrieb Jeff Breidenbach: > > Regarding: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949638 > > Thank you, Peter. > > 1. The URL for the patch is 404. > > 2. There may be some subtlety with -march=native, specifically related to > detection of SIMD instructions like AVX2. There's been an enormous > amount of back & forth on this topic in upstream over the years, so > I'd like > to take this bug there and let them weigh in. > > Jeff That might be a false alarm. Tesseract supports two different build systems, one based on cmake, one based on autoconf. As far as I know all Linux distributions use the autoconf based build, so they should not be affected by the existing problems from the cmake build. The default autoconf build uses -march=native only if it is supported by the compiler and only for a single file, but not for the rest of the code. The code from that single file is not executed by default, but only if an advanced user runs Tesseract with a special command line option (-c dotproduct=native). Stefan
Bug#949767: causes autopkgtest regression in libgpuarray
Source: libffi Version: 3.3-3 Severity: serious (This is a "block migration while I investigate" bug: it may well be downgraded or reassigned when I know more.) https://ci.debian.net/packages/libg/libgpuarray/unstable/amd64/ libffi is one of the few that changed: https://ci.debian.net/data/packages/unstable/amd64/libg/libgpuarray/4085247.log
Bug#949638: tesseract: uses -march=native
BCC: Stefan Weil since I don't know if he wants his email posted in bugs.debian.org Regarding: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949638 Thank you, Peter. 1. The URL for the patch is 404. 2. There may be some subtlety with -march=native, specifically related to detection of SIMD instructions like AVX2. There's been an enormous amount of back & forth on this topic in upstream over the years, so I'd like to take this bug there and let them weigh in. Jeff
Bug#949711: Build-depends on sgmltools-lite, which is being removed
On Thu, Jan 23, 2020 at 11:34:12PM +0100, Moritz Muehlenhoff wrote: > Source: aboot > Severity: serious > sgmltools-lite is scheduled for removal and aboot is the last package > build depending on it. > There hasn't been any aboot upload since 2013 and it's RC-buggy for a > long time, should we simply remove it? Yes, the arch: all binaries can only be built on an alpha toolchain, for which we have no official builders in Debian. I think it should probably just be removed. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Bug#949766: task-sinhala-desktop: Please replace obsolete metapackage fonts-noto-hinted with real packages
Package: task-sinhala-desktop Version: 3.58 Severity: normal Dear tasksel maintainers, Currently package task-sinhala-desktop depends on fonts-noto-hinted, which is an obsolete metapackage of Noto Fonts. Please replace it with fonts-noto-core and fonts-noto-ui-core. Thanks! -- Best, Boyuan Yang
Bug#949754: libreoffice-writer: cannot open an existing document after an update and subsequent saving (corrupt document?)
After several tests I found that the problem depended on the libreoffice user profile of the previous installed version. To solve this problem I manually removed the file: $ rm -f /home/user/.config/libreoffice/4/user/registrymodifications.xcu which will then be recreated when the program restarts. In doing so the problem is solved, but the documents saved before this change are unfortunately no longer recoverable. Perhaps could be evaluated an action in the installation trigger of the new version to avoid this eventuality...
Bug#912325: glamor0: GL error: GL_OUT_OF_MEMORY in glBufferData, GL_INVALID_OPERATION, X server crashes
Hi Michel, >You're probably using the modesetting driver already, since the Xorg >nouveau driver doesn't support glamor. The fundamental problem is in the >kernel and/or Mesa nouveau drivers. ah okay, thanks for the explanation… my X knowledge is a bit rusty (XFree86*cough*), and this is news to me. So this needs to be fixed in the kernel and/or mesa, or I have to switch to the non-free packages ☹ Are there corresponding bugreports in linux/mesa already? bye, //mirabilos -- ch: good, you corrected yourself. ppl tend to tweet such news immediately, sth. like "grml devs seem to be buyable" dileks: we _are_. if you throw enough money in our direction, things will happen everyone is buyable, it's just a matter of priceand now comes [mira] and uses this as a signature ;0 -- they asked for it…
Bug#935070: [lintian] Tags are too similar
On Fri, 24 Jan 2020, Felix Lechner wrote: > > - latest-debian-changelog-entry-reuses-existing-version checks that ^^^ > > - latest-debian-changelog-entry-without-new-version checks that the ^^^ > As you point out, the former strips the epoch before comparing. It > seemed to include the latter (and both tags had the same severity). Does it? > > PS: Personally I’m not negatively affected by removal of the latter, > > it was always annoying for local backports, but it might have > >saved someone else from a brown paper bag upload… > > Did you see a d/changelog that triggered the latter but not the former? Yes:packagename (upstreamversion-1~wtf1) followed by packagename (upstreamversion-1) (or even ~bpo10+1, when there was not the word “backport” in the changelog text) bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Bug#949677: mesa breaks build of kcrash, konsole and libkscreen as tested in autopkgtest migration setup
On 23.1.2020 23.08, Paul Gevers wrote: > Hi Timo, > > On 23-01-2020 22:01, Timo Aaltonen wrote: >> Look at the error above, the file shipped by qtbase5-dev requires >> libEGL.so which the libegl-dev dependency provides. It used to be in >> libglvnd-dev but moved to a new package when the EGL headers were added >> upstream. > > So, libglvnd-dev should add a versioned breaks on the old qtbase5-dev, > right? Uh no... The old qtbase5-dev (5.12.5+dfsg-2, in testing) depends on libgl1-mesa-dev. libgl1-mesa-dev (in testing) used to pull in libglvnd-dev which had libEGL.so. New libgl1-mesa-dev depends only on libgl-dev, so you don't get the libEGL.so symlink anymore. I guess libgl1-mesa-dev should depend on libegl-dev too, for now.
Bug#943991: Bug #943991: behave: failing tests with python3.8
Hi, Am Freitag, den 01.11.2019, 22:05 -0700 schrieb Steve Langasek: > For the moment I have worked around the failure in Ubuntu by changing the > packaging to test only against the current version of python3 and not > against all supported versions, but this is a very short-term fix given that > python3.8 will become the default in the next 6 months. I tried to adapt the upstream changes to 1.2.5, but there's just too much change since 2015 to make this feasible. So I've updated behave to 1.2.6 and added the patch there, see attached (debian/-only) debdiff (which includes the unreleased changes), or the MR here: https://salsa.debian.org/python-team/modules/behave/merge_requests/1 Michael -- Michael Banck Projektleiter / Senior Berater Tel.: +49 2166 9901-171 Fax: +49 2166 9901-100 Email: michael.ba...@credativ.de credativ GmbH, HRB Mönchengladbach 12080 USt-ID-Nummer: DE204566209 Trompeterallee 108, 41189 Mönchengladbach Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer Unser Umgang mit personenbezogenen Daten unterliegt folgenden Bestimmungen: https://www.credativ.de/datenschutz diff -Nru behave-1.2.5/debian/changelog behave-1.2.6/debian/changelog --- behave-1.2.5/debian/changelog 2019-09-13 15:19:10.0 +0200 +++ behave-1.2.6/debian/changelog 2019-10-18 16:03:41.0 +0200 @@ -1,3 +1,21 @@ +behave (1.2.6-1) UNRELEASED; urgency=medium + + * New upstream relesae. + + [ Ondřej Nový ] + * Bump Standards-Version to 4.4.1. + + [ Michael Banck ] + * debian/patches/0001-docs-disable-use-of-sphincontrib.cheeseshop.patch: +Removed, no longer needed. + * debian/patches/0002-Python-3.6-compatibility-patch-re.LOCALE-removed.patch: +Removed, no longer needed. + * debian/patches/0003-Backport-for-py38-fixes.patch: New patch, provides +compatibility with Python 3.8. Closes: #943991. + * debian/control: Added python3-sphinx-bootstrap-theme to Build-Depends. + + -- Ondřej Nový Fri, 18 Oct 2019 16:03:41 +0200 + behave (1.2.5-3) unstable; urgency=medium * Team upload. diff -Nru behave-1.2.5/debian/control behave-1.2.6/debian/control --- behave-1.2.5/debian/control 2019-09-13 14:45:20.0 +0200 +++ behave-1.2.6/debian/control 2019-10-18 16:03:41.0 +0200 @@ -13,8 +13,9 @@ python3-parse-type, python3-setuptools, python3-six, - python3-sphinx -Standards-Version: 4.4.0 + python3-sphinx, + python3-sphinx-bootstrap-theme +Standards-Version: 4.4.1 Homepage: https://github.com/behave/behave Vcs-Git: https://salsa.debian.org/python-team/modules/behave.git Vcs-Browser: https://salsa.debian.org/python-team/modules/behave diff -Nru behave-1.2.5/debian/patches/0001-docs-disable-use-of-sphincontrib.cheeseshop.patch behave-1.2.6/debian/patches/0001-docs-disable-use-of-sphincontrib.cheeseshop.patch --- behave-1.2.5/debian/patches/0001-docs-disable-use-of-sphincontrib.cheeseshop.patch 2019-09-13 14:27:54.0 +0200 +++ behave-1.2.6/debian/patches/0001-docs-disable-use-of-sphincontrib.cheeseshop.patch 1970-01-01 01:00:00.0 +0100 @@ -1,23 +0,0 @@ -From ed6df9cf0e8522ada8e3eda1d69dfbebc972f271 Mon Sep 17 00:00:00 2001 -From: Vincent Bernat -Date: Tue, 13 Jun 2017 07:38:03 +0200 -Subject: docs: disable use of sphincontrib.cheeseshop - -Not available in Debian - docs/conf.py | 2 +- - 1 file changed, 1 insertion(+), 1 deletion(-) - -diff --git a/docs/conf.py b/docs/conf.py -index e108e30138f4..781eff883837 100644 a/docs/conf.py -+++ b/docs/conf.py -@@ -30,7 +30,7 @@ extensions = [ - "sphinx.ext.autodoc", - "sphinx.ext.extlinks", - # -- PYTHON2 SUPPORT ONLY: --"sphinxcontrib.cheeseshop", -+# "sphinxcontrib.cheeseshop", - ] - # if six.PY2: - # # -- PYTHON2 ONLY: Not ported to python3, yet. diff -Nru behave-1.2.5/debian/patches/0002-Python-3.6-compatibility-patch-re.LOCALE-removed.patch behave-1.2.6/debian/patches/0002-Python-3.6-compatibility-patch-re.LOCALE-removed.patch --- behave-1.2.5/debian/patches/0002-Python-3.6-compatibility-patch-re.LOCALE-removed.patch 2019-09-13 14:27:54.0 +0200 +++ behave-1.2.6/debian/patches/0002-Python-3.6-compatibility-patch-re.LOCALE-removed.patch 1970-01-01 01:00:00.0 +0100 @@ -1,25 +0,0 @@ -From 6c303a1255e86e7c6d8a9f9b958ea83a7db5db70 Mon Sep 17 00:00:00 2001 -From: Vincent Bernat -Date: Sat, 5 Aug 2017 12:44:17 +0200 -Subject: Python 3.6 compatibility patch (re.LOCALE removed) - - behave/configuration.py | 4 +++- - 1 file changed, 3 insertions(+), 1 deletion(-) - -diff --git a/behave/configuration.py b/behave/configuration.py -index a2563dfbf081..134004c1c950 100644 a/behave/configuration.py -+++ b/behave/configuration.py -@@ -661,8 +661,10 @@ class Configuration(object): - :param names: List of name parts or regular expressions (as text). - :return: Compiled regular expression to use. - """ -+# -- NOTE: re.LOCALE is removed in Python 3.6
Bug#949066: lintian: testsuite failures on arm*
Hello, > I have been working with the dpkg maintainers on a solution, which > will not happen anytime soon. The underlying problem is that > dpkg-buildpackage issues a build error when there is simply nothing to > do. > > Fixing that is complicated because source packages nowadays permit the > building of undeclared artifacts. There is no longer a way to tell > from a source package if a build should be attempted. Either way, I > will triage your bug later today. > > Thank you for your patience and for your help in trying to make > Lintian better for everyone. > wow I though the solution was "easy" thanks for keeping it running and rocking! feel free to take your time, I was making sure this bug was not "disappeared" :) I'm not sure if src:file migration to testing is stalled by this bug... grep-excuses file file (1:5.38-3 to 1:5.38-4) Maintainer: Christoph Biedl 7 days old (needed 5 days) Migration status for file (1:5.38-3 to 1:5.38-4): Waiting for test results, another package or too young (no action required now - check later) Issues preventing migration: autopkgtest for binutils: amd64: Test in progress (will not be considered a regression), arm64: Test in progress autopkgtest for lintian/2.46.0: amd64: Pass, arm64: Reference test in progress, but real test failed already Additional info: Piuparts tested OK - https://piuparts.debian.org/sid/source/f/file.html 7 days old (needed 5 days) G.
Bug#949765: ITP: babeltrace2 -- A trace manipulation toolkit
Package: wnpp Severity: wishlist Owner: Michael Jeanson * Package name: babeltrace2 Version : 2.0.0 Upstream Author : Jérémie Galarneau * URL : https://www.babeltrace.org/ * License : MIT Programming Lang: C Description : A trace manipulation toolkit The Babeltrace 2 project offers a library with a C API, Python 3 bindings, and a command-line tool which makes it easy for mere mortals to view, convert, transform, and analyze traces. Babeltrace 2 is also the reference parser implementation of the Common Trace Format (CTF), a versatile trace format followed by various tracers and tools such as LTTng and barectf. This package is required because the API and the basename of the library has changed since babeltrace1, current dependencies like gdb and ceph will need to be ported to this new API and both package will have to be co-installable for a while.
Bug#935070: [lintian] Tags are too similar
Hi Thorsten, On Fri, Jan 24, 2020 at 6:50 AM Thorsten Glaser wrote: > > - latest-debian-changelog-entry-reuses-existing-version checks that > the version without the epoch is never reused, for the archive and > snapshots to be consistent (as the epoch is not used in filenames) > > - latest-debian-changelog-entry-without-new-version checks that the > upload does not have a smaller (or equal) version number to the > previous upload except in backports, to ensure that it’ll be newer > and nobody forgot a version increment before uploading As you point out, the former strips the epoch before comparing. It seemed to include the latter (and both tags had the same severity). > PS: Personally I’m not negatively affected by removal of the latter, > it was always annoying for local backports, but it might have >saved someone else from a brown paper bag upload… Did you see a d/changelog that triggered the latter but not the former? Kind regards Felix Lechner
Bug#949764: ksh: ksh/2020.0.0-3 will not uninstall cleanly (piuparts error)
Source: ksh Version: 2020.0.0-3 Severity: serious https://piuparts.debian.org/sid/fail/ksh_2020.0.0-3.log 0m14.4s DEBUG: Modified(user, group, mode, size, target): /etc/shells expected(root, root, - 100644, 73, None) != found(root, root, - 100644, 100, None) 0m14.4s ERROR: FAIL: After purging files have been modified: /etc/shellsnot owned 0m14.4s ERROR: FAIL: Installation and purging test. This often indicates that the handling of /etc/shells has bugs. Please take a look into it. -- Best, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#949763: python-azure: please consider uploading a new version
Source: python-azure Version: 20181112+git-3 Severity: wishlist Blocks: 930413 Dear Maintainer(s), Please consider uploading the latest version of python-azure. It is needed for the upload of azure-cli. If time is lacking, I'm happy to do an NMU. Thank you! -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#949066: lintian: testsuite failures on arm*
Hi Gianfranco, On Fri, Jan 24, 2020 at 8:39 AM Gianfranco Costamagna wrote: > > Felix gentle ping please? > (in Ubuntu I disabled that test BTW and the result package autopkgtestsuite > was green on all archs) The release took place solely to facilitate upgrading lintian.d.o, which has been down for months. Details are in #949398; your bug is mentioned there. I have been working with the dpkg maintainers on a solution, which will not happen anytime soon. The underlying problem is that dpkg-buildpackage issues a build error when there is simply nothing to do. Fixing that is complicated because source packages nowadays permit the building of undeclared artifacts. There is no longer a way to tell from a source package if a build should be attempted. Either way, I will triage your bug later today. Thank you for your patience and for your help in trying to make Lintian better for everyone. Kind regards Felix
Bug#949690: debian-policy: "service unit should have the same name as the package" seems too strong
> "Sean" == Sean Whitton writes: Sean> Encouragement is still normative, so if we're going to encourage it, Sean> it would be better to say /when/ it's encouraged and when it's not. I think it should be encouraged when there is not a good reason to do otherwise. I think the most common reason not to do otherwise (the only reason I can think of that is likely to be common) is to preserve upstream's service unit name.
Bug#944203: dpkg: error processing package wireguard (--configure):
Hi Bhagwan-- On Tue 2019-11-05 15:32:13 -0500, Bhagwan Jha wrote: > 1. Linux parrot 5.2.0-2parrot1-amd64 #1 SMP Debian 5.2.9-2parrot1 > (2019-08-25) x86_64 GNU/Linux > 2. > No LSB modules are available. > Distributor ID: Parrot > Description: Parrot GNU/Linux 4.7 > Release: 4.7 > Codename: sid I don't know anything about "Parrot", but the errors you're seeing are segfaults within gcc: > DKMS make.log for wireguard-0.0.20191012 for kernel 5.2.0-2parrot1-amd64 > (x86_64) > Tue 05 Nov 2019 02:44:06 PM EST > make: Entering directory '/usr/src/linux-headers-5.2.0-2parrot1-amd64' > CC [M] /var/lib/dkms/wireguard/0.0.20191012/build/main.o > CC [M] /var/lib/dkms/wireguard/0.0.20191012/build/noise.o > gcc-8: internal compiler error: Segmentation fault signal terminated program > cc1 > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. It looks very likely to me to be a bug in your gcc installation, but given that this is Parrot and not debian, i recommend reporting the bug to Parrot directly. I'm closing this bug in the debian BTS with this e-mail, but if you think it applies to debian as well, feel free to re-open it. It looks to me like this is ultimately a gcc issue, though, not a wireguard issue. Regards, --dkg signature.asc Description: PGP signature
Bug#949762: Please update hypothesis package to >= 5.1
Package: python3-hypothesis Version: 4.36.2-1 Severity: wishlist Dear maintainer, The hypothesis package is going to be used in many astronomical Python packages to improve testing efficiency. They are going to require at least version 5.1, as documented as a dependency in the last version of pytest-astropy, which I would loke to upload ASAP. Could you update the hypothesis package to the latest version, or at least to a 5.1 release? Thank you very much Best Ole
Bug#949066: lintian: testsuite failures on arm*
hello, On Fri, 17 Jan 2020 09:29:57 +0100 Gianfranco Costamagna wrote: > Hello, > > > > > A list of the test packages that failed to build on arm* would be helpful. > > sure, you can grab all the test results from here > http://autopkgtest.ubuntu.com/packages/lintian > > (you can use 2.45.0ubuntu1 as reference to 2.45.0, the only difference is > this patch > http://launchpadlibrarian.net/460879291/lintian_2.45.0_2.45.0ubuntu1.diff.gz > please apply it!) > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949065 so 2.47.0 didn't hit the fix for this bug... Felix gentle ping please? (in Ubuntu I disabled that test BTW and the result package autopkgtestsuite was green on all archs) G.
Bug#916178: roger-router-cli: missing dependency on cups
control: tags -1 -wontfixcontrol: reassign -1 src:roger-router >I'm not going to engage in reassign combat, but my understanding is that the >following code from roger-router-cli.postinst _assumes_ that a local CUPS >daemon is available (as no -h is specified): you can do it, as said before, I wasn't really sure about the reassign either(I know such packages can have a working subset of functionalities and having an additional dependency is sometimes not the right thing to do!) >if which lpadmin >/dev/null >then > lpadmin -p "Roger-Router-Fax" -E -v roger-cups:/ -P >/usr/share/roger/roger-fax.ppd> >fi> > the postinst of roger-router-cli depends on a running, local, cups-daemon, >it has to grow a dependency on the daemon itself, and cups-client will not >grow that dependency. > >I'm tagging this bug as wontfix in CUPS, feel free to remove that tag when >reassigning back to roger-router-cli. thanks for the explanation! I'm not an user of roger-router myself, I just tried to fix RC bugs, but I'll be happy to see an upload or to upload it if youhave a patch :) otherwise, I think people will just need to install the cups dependency theirselves(or I can just add that dependency and live happy, but I have the feeling that the postinst/postrm can be tweaked to ignore the missing dependency?) Gianfranco
Bug#949690: debian-policy: "service unit should have the same name as the package" seems too strong
Hello, On Fri 24 Jan 2020 at 10:47AM -05, Sam Hartman wrote: > I think should -> encouraged would go a lot of the way. > Especially with a sentence along the lines of > "Often, preserving an upstream's choice of service unit name is more > important than having a service unit match a package's name." Encouragement is still normative, so if we're going to encourage it, it would be better to say /when/ it's encouraged and when it's not. -- Sean Whitton signature.asc Description: PGP signature
Bug#870641:
i said "i could not find kde data, tried kde-full, kde-standard, kde-plasma-desktop". seems it is plasma-desktop, and it has 10% installs, 6% uses.
Bug#949761: gpgconf: make socketdir configurable to users
Package: gpgconf Version: 2.2.19-1 Severity: important gpg2 and gpg-agent (used by gnupg (1.x) as well) now uses GPG_AGENT_INFO=/run/user/2339/gnupg/S.gpg-agent:0:1 but the directory /run/user/2339 is removed on logout by elogind even if processes are still running. Unfortunately, this means gpg-agent kills itself when that happens, e.g. when X crashes (Debian #912325) while, at the same time, I’m logged in over ssh and working, e.g. in GNU screen. This causes gnupg to completely fail (it asks for the password, then tells me it cannot sign, breaking e.g. signed git commits). Furthermore, I’d prefer to move it to a location more easily accessible in chroots, such as /dev/shm/ (see Debian #949698 where I’m already keeping my SSH agent information etc). I’ve not found any elogind option to not remove that directory on logout (as opposed to reboot which given it appears to be a tmpfs is granted) and also suspect systemd behaves the same. -- System Information: Debian Release: bullseye/sid APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable'), (100, 'experimental') Architecture: x32 (x86_64) Foreign Architectures: i386, amd64 Kernel: Linux 5.4.0-3-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) Versions of packages gpgconf depends on: ii libassuan0 2.5.3-7 ii libc6 2.29-9 ii libgcrypt201.8.5-3 ii libgpg-error0 1.36-7 ii libreadline8 8.0-3 gpgconf recommends no packages. gpgconf suggests no packages. -- no debconf information
Bug#945133: gcc-9: __has_attribute(ifunc) false positive on hurd and kfreebsd
Hi Samuel, I forwarded the bug to the GCC tracker and they said that your interpretation of the docs is correct. I doubt whether they are willing to change the behaviour, but we'll see. Best, Fabian
Bug#949757: python-packaging: test failures due to wrong arch check
Control: reassign -1 dh-python On 24.01.20 16:43, Adrian Bunk wrote: > Source: python-packaging > Version: 19.2-1 > Severity: serious > Tags: ftbfs > > https://buildd.debian.org/status/fetch.php?pkg=python-packaging=all=20.0-1=1578410735=0 > > ... >> assert linux_platform == "linux_x86_64" > E AssertionError: assert 'linux_amd64' == 'linux_x86_64' > E - linux_amd64 > E + linux_x86_64 > ... > > > Seems to be related to #938969. No, it's a bug in dh-python.
Bug#949760: Another GIMP crash with floating point exception on image save.
Package: gimp Version: 2.10.8-2 I am using Debian 10 (buster), kernel 4.19.0-6-amd64 x86_64 bits. Running gimp within firejail (firejail - version 0.9.58.2). After merging down approximately 10 layers to create an image consisting of only 2 layers, the image was saved using File...Save. At the conclusion of the save, the program crashed. Upon restart it was observed that the image was properly saved suggesting that the crash occurred after the image file was written. Bug trace info follows: ``` GNU Image Manipulation Program version 2.10.8 git-describe: GIMP_2_10_6-294-ga967e8d2c2 C compiler: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 8.2.0-13' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-8 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 8.2.0 (Debian 8.2.0-13) using GEGL version 0.4.12 (compiled against version 0.4.12) using GLib version 2.58.3 (compiled against version 2.58.1) using GdkPixbuf version 2.38.1 (compiled against version 2.38.0) using GTK+ version 2.24.32 (compiled against version 2.24.32) using Pango version 1.42.3 (compiled against version 1.42.3) using Fontconfig version 2.13.1 (compiled against version 2.13.1) using Cairo version 1.16.0 (compiled against version 1.16.0) ``` > fatal error: Floating point exception Stack trace: ``` /lib/libgimpbase-2.0.so.0(gimp_stack_trace_print+0x397)[0x7f625afdde27] gimp(+0xd14a0)[0x55f3b32264a0] gimp(+0xd18d8)[0x55f3b32268d8] gimp(+0xd2037)[0x55f3b3227037] /lib/x86_64-linux-gnu/libpthread.so.0(+0x12730)[0x7f625a2e5730] gimp(+0x44397f)[0x55f3b359897f] gimp(+0x443c28)[0x55f3b3598c28] /lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x158)[0x7f625a4c9dd8] /lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x4e1c8)[0x7f625a4ca1c8] /lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_loop_run+0xb2)[0x7f625a4ca4c2] gimp(app_run+0x357)[0x55f3b3225cb7] gimp(main+0x395)[0x55f3b32255b5] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb)[0x7f625a13409b] gimp(_start+0x2a)[0x55f3b322573a] ``` System info (inxi -F) follows: System: Host: upstairs Kernel: 4.19.0-6-amd64 x86_64 bits: 64 Desktop: Budgie 10.5 Distro: Debian GNU/Linux 10 (buster) Machine: Type: Desktop Mobo: Gigabyte model: GA-870A-UD3 v: x.x serial: BIOS: Award v: F2 date: 06/07/2010 CPU: Topology: 6-Core model: AMD Phenom II X6 1075T bits: 64 type: MCP L2 cache: 3072 KiB Speed: 804 MHz min/max: 800/3000 MHz Core speeds (MHz): 1: 804 2: 804 3: 809 4: 1607 5: 1215 6: 1011 Graphics: Device-1: NVIDIA GM107 [GeForce GTX 750 Ti] driver: nouveau v: kernel Display: x11 server: X.Org 1.20.4 driver: nouveau resolution: 1680x1050~60Hz, 1680x1050~60Hz OpenGL: renderer: NV117 v: 4.3 Mesa 18.3.6 Audio: Device-1: Advanced Micro Devices [AMD/ATI] SBx00 Azalia driver: snd_hda_intel Device-2: NVIDIA driver: snd_hda_intel Sound Server: ALSA v: k4.19.0-6-amd64 Network: Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169 IF: enp6s0 state: up speed: 1000 Mbps duplex: full mac: 1c:6f:65:4c:8c:8d Drives: Local Storage: total: 4.22 TiB used: 2.92 TiB (69.2%) ID-1: /dev/sda vendor: Western Digital model: WD30EZRZ-00GXCB0 size: 2.73 TiB ID-2: /dev/sdb vendor: Samsung model: HD103SJ size: 931.51 GiB ID-3: /dev/sdc vendor: OCZ model: ARC100 size: 223.57 GiB ID-4: /dev/sdd vendor: Western Digital model: WD2000JB-00KFA0 size: 186.31 GiB ID-5: /dev/sde vendor: Western Digital model: WD2000JB-00GVC0 size: 186.31 GiB Partition: ID-1: / size: 45.59 GiB used: 15.11 GiB (33.1%) fs: ext4 dev: /dev/sdc2 ID-2: /home size: 564.68 GiB used: 454.24 GiB (80.4%) fs: ext4 dev: /dev/sdb8 ID-3: swap-1 size: 12.01 GiB used: 0 KiB (0.0%) fs: swap dev: /dev/sdb6 ID-4: swap-2 size: 3.90 GiB used: 37.8 MiB
Bug#949759: bootcd: Missing build dependencies on python3-docutils and shellia
Source: bootcd Version: 6.00 Severity: serious Tags: ftbfs https://buildd.debian.org/status/fetch.php?pkg=bootcd=all=6.00=1576857218=0 ... debian/rules build-indep make[1]: Entering directory '/<>' make[1]: rst2man: Command not found make[1]: *** [Makefile:51: bootcdwrite.1] Error 127
Bug#945133: gcc-9: __has_attribute(ifunc) false positive on hurd and kfreebsd
forwarded 945133 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93419
Bug#949690: debian-policy: "service unit should have the same name as the package" seems too strong
> "Russ" == Russ Allbery writes: Russ> Ah, hm, yes, that's a good point that I didn't notice when copying that Russ> Policy recommendation over from the recommendations on init scripts. Russ> The obvious concern here is that multiple packages could use the same Russ> service name, and making the service name match the package name reduces Russ> that risk considerably. But I think I agree that staying consistent with Russ> upstream is more important than adopting that policy in a strong sense. Russ> Do you have a suggestion for alternative wording? I think we still need Russ> to say something about matching the name of the init script if any, and if Russ> upstream doesn't provide a service unit, it seems reasonable to use the Russ> name of the package (but maybe that should be encouraged rather than Russ> recommended?). I think should -> encouraged would go a lot of the way. Especially with a sentence along the lines of "Often, preserving an upstream's choice of service unit name is more important than having a service unit match a package's name."
Bug#949758: archmage: Missing build dependencies on python3-sgmllib3k and python3-chm
Source: archmage Version: 1:0.4.1-1 Severity: serious Tags: ftbfs https://buildd.debian.org/status/fetch.php?pkg=archmage=all=1%3A0.4.1-1=1577227085=0 ... ERRORS _ ERROR collecting .pybuild/cpython3_3.8/build/tests/test_openclose.py _ ImportError while importing test module '/<>/.pybuild/cpython3_3.8/build/tests/test_openclose.py'. Hint: make sure your test modules/packages have valid Python names. Traceback: tests/test_openclose.py:1: in import sys, archmage.cli, pathlib, tempfile, errno, shutil, contextlib archmage/cli.py:57: in from archmage.CHM import CHMFile, Action archmage/CHM.py:34: in from archmage.CHMParser import SitemapFile, PageLister, ImageCatcher, TOCCounter#, HeadersCounter archmage/CHMParser.py:24: in import sgmllib, urllib.request, urllib.error, urllib.parse E ModuleNotFoundError: No module named 'sgmllib' ...
Bug#949757: python-packaging: test failures due to wrong arch check
Source: python-packaging Version: 19.2-1 Severity: serious Tags: ftbfs https://buildd.debian.org/status/fetch.php?pkg=python-packaging=all=20.0-1=1578410735=0 ... > assert linux_platform == "linux_x86_64" E AssertionError: assert 'linux_amd64' == 'linux_x86_64' E - linux_amd64 E + linux_x86_64 ... Seems to be related to #938969.
Bug#949756: staticsite FTBFS: FAIL: test_site (tests.test_page_filter.TestPageFilter)
Source: staticsite Version: 1.4.1-1 Severity: serious Tags: ftbfs https://buildd.debian.org/status/fetch.php?pkg=staticsite=all=1.4.1-1=1578410781=0 ... == FAIL: test_site (tests.test_page_filter.TestPageFilter) -- Traceback (most recent call last): File "/<>/.pybuild/cpython3_3.8/build/tests/test_page_filter.py", line 22, in test_site self.assertEqual(select(site, path="blog/*"), [ AssertionError: Lists differ: ['/blog/post2', '/blog/post1'] != ['/blog/post1', '/blog/post2'] First differing element 0: '/blog/post2' '/blog/post1' - ['/blog/post2', '/blog/post1'] + ['/blog/post1', '/blog/post2'] -- Ran 55 tests in 3.425s FAILED (failures=1)
Bug#912325: glamor0: GL error: GL_OUT_OF_MEMORY in glBufferData, GL_INVALID_OPERATION, X server crashes
On 2020-01-24 2:45 p.m., Thorsten Glaser wrote: > Package: xserver-xorg-core > Version: 2:1.20.7-2 > Followup-For: Bug #912325 > Control: affects 912325 xserver-xorg-video-nouveau > Control: forcemerge 912325 943893 > Control: retitle 912325 xserver-xorg-core: SIGSEGV with glamor0: GL error: > GL_OUT_OF_MEMORY with xserver-xorg-video-nouveau > > This issue is still pertinent, although reportbug suggested #943893 > to me which points out that this might be due to nouveau, which is, > indeed, the driver in use on this particular system. > > What can I do, besides switch to the proprietary driver? Perhaps with > fbdev or modesetting? (That would probably lose me OpenGL performance?) You're probably using the modesetting driver already, since the Xorg nouveau driver doesn't support glamor. The fundamental problem is in the kernel and/or Mesa nouveau drivers. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer
Bug#949755: totem: Time slider gets inactive after long press
Package: totem Version: 3.30.0-4 Severity: normal Dear Maintainer, The following procedure leeds to a bug: * Click on the time slider for around 2-3 seconds while playing back a file (tested with mp3, mp4) until the bar gets broader * If one does not wait until the bar gets broader the bug will not appear * outcome: the dot on the slider is inactive. The time is displayed correctly, one can scroll through the time. * expected: the dot on the slider is still active -- System Information: Debian Release: 10.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-6-amd64 (SMP w/8 CPU cores) Kernel taint flags: 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 /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages totem depends on: ii grilo-plugins-0.3 0.3.8-2 ii gsettings-desktop-schemas 3.28.1-1 ii gstreamer1.0-clutter-3.03.0.26-2 ii gstreamer1.0-plugins-base 1.14.4-2 ii gstreamer1.0-plugins-good 1.14.4-1 ii gstreamer1.0-x 1.14.4-2 ii libc6 2.28-10 ii libcairo2 1.16.0-4 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libglib2.0-02.58.3-2+deb10u2 ii libgstreamer-plugins-base1.0-0 1.14.4-2 ii libgstreamer1.0-0 1.14.4-1 ii libgtk-3-0 3.24.5-1 ii libnautilus-extension1a 3.30.5-2 ii libpango-1.0-0 1.42.4-7~deb10u1 ii libpangocairo-1.0-0 1.42.4-7~deb10u1 ii libtotem-plparser18 3.26.2-1 ii libtotem0 3.30.0-4 ii libx11-62:1.6.7-1 ii totem-common3.30.0-4 Versions of packages totem recommends: ii gstreamer1.0-libav 1.15.0.1+git20180723+db823502-2 ii gstreamer1.0-plugins-bad 1.14.4-1+b1 ii gstreamer1.0-plugins-ugly 1.14.4-1 ii gstreamer1.0-pulseaudio1.14.4-1 ii totem-plugins 3.30.0-4 Versions of packages totem suggests: pn gnome-codec-install -- no debconf information
