Bug#975510: ITP: deepin-wallpapers -- DDE wallpapers
On Mon, Nov 23, 2020 at 01:08:15PM +0800, hufeng wrote: > * Package name : deepin-wallpapers > Version : 1.6.14 > Upstream Author : amazingfate > * URL : https://github.com/linuxdeepin/deepin-wallpapers > License : GPL-3+ It doesn't look like GPL-3+ to me: ,--[ LICENSE ] All the source code reside in this repository are licensed under GPLv3. Photographs are licensed under 3 different licenses: 1. CC-BY-NC 3.0 for photographs in the deepin directory. 2. CC-BY-SA 3.0 for photographs in the deepin-community directory. 3. Photographs in the deepin-private directory are not permitted to use without authorization. ` I see no code in copyrightable amounts, just a short Makefile. /deepin/ is CC-BY-NC 3.0, which is non-free. /deepin-private/ tries to forbid even use (which a pure license cannot do), and bears no permission to distribute. /deepin-community/ has a good license, but I think I've seen at least one of the images elsewhere -- among default images on Windows. I can't check that right now (I won't have access to a Windows install for at least a week), so it might be just a similar photo of the same geological feature. Or they might have come from a common freely-licensed source. Also, the license grants rights to only photographs, while images in /deepin/ are non-photographic. This seems to me to be a bad use of the word rather than something intentional, though. On the other hand, some of the images are awesome! I especially like the "ghost forest" in -community, while the trees in -private have a nice pseudo-tiled look. 喵! -- ⢀⣴⠾⠻⢶⣦⠀ Latin: meow 4 characters, 4 columns, 4 bytes ⣾⠁⢠⠒⠀⣿⡁ Greek: μεου 4 characters, 4 columns, 8 bytes ⢿⡄⠘⠷⠚⠋⠀ Runes: ᛗᛖᛟᚹ 4 characters, 4 columns, 12 bytes ⠈⠳⣄ Chinese: 喵 1 character, 2 columns, 3 bytes <-- best!
Bug#975512: ruby-kubeclient: ftbfs with Passing permitted_classes with the 2nd argument of Psych.safe_load is deprecated
Package: ruby-kubelcient Version: 4.6.0-1 Severity: serious Control: forwarded -1 https://github.com/abonas/kubeclient/issues/483 ruby-kubeclient started failing debci and ftbfs recently. TestResourceQuota#test_get_from_json_v1 = 0.01 s = . KubeclientConfigTest#test_user_token = /usr/lib/ruby/vendor_ruby/kubeclient/config.rb:33: Passing permitted_classes with the 2nd argument of Psych.safe_load is deprecated. Use keyword argument like Psych.safe_load(yaml, permitted_classes: ...) instead. 0.00 s = . KubeclientConfigTest#test_external_nopath_absolute = 0.00 s = . KubeclientConfigTest#test_gcp_default_auth = /tmp/autopkgtest-lxc.0kqlxqvn/downtmp/build.PLE/src/test/test_config.rb:128: Passing permitted_classes with the 2nd argument of Psych.safe_load is deprecated. Use keyword argument like Psych.safe_load(yaml, permitted_classes: ...) instead. 0.00 s = . KubeclientConfigTest#test_gcp_default_auth_renew = /tmp/autopkgtest-lxc.0kqlxqvn/downtmp/build.PLE/src/test/test_config.rb:137: Passing permitted_classes with the 2nd argument of Psych.safe_load is deprecated. Use keyword argument like Psych.safe_load(yaml, permitted_classes: ...) instead. 0.00 s = . KubeclientConfigTest#test_user_exec = /usr/lib/ruby/vendor_ruby/kubeclient/config.rb:33: Passing permitted_classes with the 2nd argument of Psych.safe_load is deprecated. Use keyword argument like Psych.safe_load(yaml, permitted_classes: ...) instead. 0.01 s = . KubeclientConfigTest#test_user_password = /usr/lib/ruby/vendor_ruby/kubeclient/config.rb:33: Passing permitted_classes with the 2nd argument of Psych.safe_load is deprecated. Use keyword argument like Psych.safe_load(yaml, permitted_classes: ...) instead. 0.00 s = . KubeclientConfigTest#test_user_exec_nopath = 0.00 s = . KubeclientConfigTest#test_external = /usr/lib/ruby/vendor_ruby/kubeclient/config.rb:33: Passing permitted_classes with the 2nd argument of Psych.safe_load is deprecated. Use keyword argument like Psych.safe_load(yaml, permitted_classes: ...) instead. 0.00 s = F KubeclientConfigTest#test_timestamps = /usr/lib/ruby/vendor_ruby/kubeclient/config.rb:33: Passing permitted_classes with the 2nd argument of Psych.safe_load is deprecated. Use keyword argument like Psych.safe_load(yaml, permitted_classes: ...) instead. 0.00 s = . KubeclientConfigTest#test_allinone = /usr/lib/ruby/vendor_ruby/kubeclient/config.rb:33: Passing permitted_classes with the 2nd argument of Psych.safe_load is deprecated. Use keyword argument like Psych.safe_load(yaml, permitted_classes: ...) instead. 0.00 s = F KubeclientConfigTest#test_allinone_nopath = 0.00 s = F KubeclientConfigTest#test_nouser = /usr/lib/ruby/vendor_ruby/kubeclient/config.rb:33: Passing permitted_classes with the 2nd argument of Psych.safe_load is deprecated. Use keyword argument like Psych.safe_load(yaml, permitted_classes: ...) instead. 0.00 s = . Finished in 0.631563s, 240.6727 runs/s, 932.6065 assertions/s. Failure: KubeclientConfigTest#test_external [/tmp/autopkgtest-lxc.0kqlxqvn/downtmp/build.PLE/src/test/test_config.rb:199]: Expected false to be truthy. Failure: KubeclientConfigTest#test_allinone [/tmp/autopkgtest-lxc.0kqlxqvn/downtmp/build.PLE/src/test/test_config.rb:199]: Expected false to be truthy. Failure: KubeclientConfigTest#test_allinone_nopath [/tmp/autopkgtest-lxc.0kqlxqvn/downtmp/build.PLE/src/test/test_config.rb:199]: Expected false to be truthy. Full build log https://ci.debian.net/data/autopkgtest/testing/amd64/r/ruby-kubeclient/8232365/log.gz Packages that changed between the success and failure is. -openssl 1.1.1g-1 +openssl 1.1.1h-1 -ruby-bindata 2.3.5-1 +ruby-bindata 2.4.8-1 diff of all packages (some are nmus) between pass and failure is attached. Forwarded upstream at https://github.com/abonas/kubeclient/issues/483 --- ruby-kubeclient.gem2deb-test-runner-packages.pass 2020-11-23 12:40:37.258566503 +0530 +++ ruby-kubeclient.gem2deb-test-runner-packages 2020-11-23 12:38:37.801909584 +0530 @@ -2,7 +2,7 @@ gem2deb-test-runner 1.4 libruby2.7 2.7.2-3 libyaml-0-2 0.2.2-1 -openssl 1.1.1g-1 +openssl 1.1.1h-1 publicsuffix 20200729.1725-1 rake 13.0.1-4 ruby 1:2.7+1 @@ -10,21 +10,21 @@ ruby-activesupport 2:6.0.3.4+dfsg-1 ruby-addressable 2.7.0-1 ruby-aes-key-wrap 1.0.1-1 -ruby-atomic 1.1.16-3 +ruby-atomic 1.1.16-3+b1 ruby-attr-required 1.0.0-2 -ruby-bindata 2.3.5-1 +ruby-bindata 2.4.8-1 ruby-concurrent 1.1.6+dfsg-3 ruby-crack 0.4.4-1 ruby-domain-name 0.5.20160216-2 ruby-faraday 0.17.3-1 -ruby-ffi 1.12.2+dfsg-2+b2 +ruby-ffi 1.12.2+dfsg-2+b3 ruby-ffi-compiler 1.0.1-4 ruby-googleauth 0.13.0-3 ruby-hashdiff 1.0.0-1 ruby-http 4.4.1-4 ruby-http-cookie 1.0.3-1 ruby-http-form-data 2.2.0-1 -ruby-http-parser 1.2.1-4 +ruby-http-parser 1.2.1-4+b1 ruby-httpclient 2.8.3-2 ruby-i18n 1.8.5-1 ruby-json-jwt 1.11.0-1 @@ -61,7 +61,7 @@ ruby-to-regexp 0.2.1-2 ruby-tzinfo 1.2.6-1 ruby-unf 0.1.4-2 -ruby-unf-ext 0.0.7.6-1+b2 +ruby-unf-ext 0
Bug#975115: [Pkg-mozext-maintainers] Bug#975115: webext-dav4tbsync and webext-tbsync out of sync
I've just noticed this message in the debug log for tbsync about the provider failing to load: ** Mon Nov 23 2020 17:43:57 GMT+1100 (AEDT) ** [Initializing module] : ** Mon Nov 23 2020 17:43:57 GMT+1100 (AEDT) ** [TbSync init] : Done ** Mon Nov 23 2020 17:43:57 GMT+1100 (AEDT) ** [EventLog] : FAILED to load provider API version mismatch, TbSync@Beta 2.4 vs dav@2.4
Bug#975511: segfaults on s390x
Package: clustalo Version: 1.2.4-6 Hi, as initially found and discussed on Launchpad/Ubuntu [1] there is a segfault of clustalo on s390x. So far it didn't hit you on your s390x builds [2] but it seems pretty reliable for us already and on a rebuild in Debian unstable I've hit it as well. It is triggered by the new self-test after build in 1.2.4-6. The underlying root cause was identified in [3] which I also reported to upstream and the Debian Med Team as mail. We now have three options: - wait for upstreams stance on the suggested change - switch optimization to -O0 on s390x which avoids the issue for now - apply the suggested patch without upstream commenting on it This is up to you to decide what you prefer and I last week already opened an MR for it [4]. [1]: https://bugs.launchpad.net/ubuntu/+source/clustalo/+bug/1903817 [2]: https://buildd.debian.org/status/architecture.php?a=s390x&suite=sid [3]: https://bugs.launchpad.net/ubuntu/+source/clustalo/+bug/1903817/comments/15 [4]: https://salsa.debian.org/med-team/clustalo/-/merge_requests/1 -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd
Bug#930725: Let me provide a debdiff right away
On Fri, Nov 20, 2020 at 11:34 PM gustavo panizzo wrote: ... > I've just uploaded numad 0.5+20150602-6 which Thank you!
Bug#974715: gnome-maps: Search returns no results
On Sun, 2020-11-15 at 10:09 +, Philip Wyett wrote: > On Sat, 2020-11-14 at 14:10 +0530, John Doe wrote: > > Package: gnome-maps > > Version: 3.30.3.1-0+deb10u1 > > Severity: normal > > > > Dear Maintainer, > > > > Steps - > > 1. Open gnome-maps > > 2. Type something in the search bar (I've tried POI names that I > > know > > exist, as > > well as common terms like "hospital") > > 3. Press Enter > > > > A popup appears with a spinner, and always ends with "No results > > found." > > > > > > > > -- System Information: > > Debian Release: 10.6 > > APT prefers stable-updates > > APT policy: (500, 'stable-updates'), (500, 'stable') > > Architecture: amd64 (x86_64) > > > > Kernel: Linux 4.19.0-12-amd64 (SMP w/4 CPU cores) > > 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 gnome-maps depends on: > > ii dconf-gsettings-backend [gsettings-backend] 0.30.1-2 > > ii geoclue-2.0 2.5.2-1 > > ii gir1.2-champlain-0.120.12.16-3 > > ii gir1.2-clutter-1.0 1.26.2+dfsg-10 > > ii gir1.2-cogl-1.0 1.22.2-6 > > ii gir1.2-gdkpixbuf-2.0 2.38.1+dfsg-1 > > ii gir1.2-geoclue-2.0 2.5.2-1 > > ii gir1.2-geocodeglib-1.0 3.26.1-1 > > ii gir1.2-gfbgraph-0.2 0.2.3-3 > > ii gir1.2-glib-2.0 1.58.3-2 > > ii gir1.2-goa-1.0 3.30.1-2 > > ii gir1.2-gtk-3.0 3.24.5-1 > > ii gir1.2-gtkchamplain-0.12 0.12.16-3 > > ii gir1.2-gtkclutter-1.01.8.4-4 > > ii gir1.2-gweather-3.0 3.28.2-2 > > ii gir1.2-rest-0.7 0.8.1-1 > > ii gir1.2-secret-1 0.18.7-1 > > ii gir1.2-soup-2.4 2.64.2-2 > > ii gir1.2-webkit2-4.0 2.28.4-1~deb10u1 > > ii gjs 1.54.3-1 > > ii libc62.28-10 > > ii libchamplain-0.12-0 0.12.16-3 > > ii libfolks25 0.11.4-1+b2 > > ii libgee-0.8-2 0.20.1-2 > > ii libgeocode-glib0 3.26.1-1 > > ii libglib2.0-0 2.58.3-2+deb10u2 > > ii libglib2.0-bin 2.58.3-2+deb10u2 > > ii librest-0.7-00.8.1-1 > > ii libxml2 2.9.4+dfsg1-7+b3 > > > > gnome-maps recommends no packages. > > > > gnome-maps suggests no packages. > > > > -- no debconf information > > > > Hi, > > This looks like possibly a reoccurrence of #956017 [1] (see message > 20 > [2]). The server https://nominatim.gnome.org/ seems to be down. > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956017 > [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956017#20 > > Regards > > Phil > Hi all, As of this morning, the issue seems to have been resolved and searches are resulting in populated results and not the "No results found.". Regards Phil -- *** Playing the game for the games own sake. *** WWW: https://kathenas.org Twitter: @kathenasorg IRC: kathenas GPG: 724AA9B52F024C8B signature.asc Description: This is a digitally signed message part
Bug#975115: [Pkg-mozext-maintainers] Bug#975115: webext-dav4tbsync and webext-tbsync out of sync
Hello, Can you provide a screenshot of the window with that message. Please provide another screenshot of Options - Add-Ons where I can see the status of that packages. I can't reproduce this problem. Regards Mechtilde Am 22.11.20 um 23:44 schrieb Carl Suster: > Package: webext-dav4tbsync > Version: 1.23-1 > Followup-For: Bug #975115 > > I'm also having problems with this on sid. When I open the thunderbird addon > manager, I see tbsync, dav4tbsync, and eas4tbsync all installed and enabled. > All of these come from the debian packages. However, when I open the tbsync > config window it claims that dav4tbsync is not installed. There is no such > problem with eas4tbsync (webext-eas4tbsync 1.20-1), which works fine. -- Mechtilde Stehmann ## Debian Developer ## PGP encryption welcome ## F0E3 7F3D C87A 4998 2899 39E7 F287 7BBA 141A AD7F OpenPGP_signature Description: OpenPGP digital signature
Bug#974982: transition: krb5
On Sat, 21 Nov 2020 01:51:27 + Paul Wise wrote: > We are using libapache2-mod-auth-kerb at my workplace, I've raised an > issue about taking over modauthkerb upstream or just switching to > another module We have decided to switch to the gssapi module. I would recommend that libapache2-mod-auth-kerb gets orphaned and the maintainer reported to the MIA folks. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#599884: some more things to fix
Hi Tobias, > Did I miss some mail? Its not ready, is is? No, I only completely forgot, that the package is not ready, and if someone wants to work on it, go ahead. I lack resources to do so. > Could not find any RFS, Is has lintian errors [1] the bug [2] is not an ITP, > but has been. I guess you dropped the ITP? That is correct. > [1] exerpt from https://mentors.debian.net/package/speed-dreams/: > Package has lintian errors > speed-dreams > E custom-library-search-path > W national-encoding > W non-multi-arch-lib-dir > W shared-library-lacks-prerequisites > W duplicate-font-file > W truetype-font-prohibits-installable-embedding > > Would be cool to have a few more words to understand the context or your > intentions. > Otherwise ones time gets easily wasted. Sorry, fixing that now. > -- > tobi > signature.asc Description: OpenPGP digital signature
Bug#973252: Bug 973252
Hi, For that you have to install linux-image-5.9.0-3-amd64 from unstable. It will go into testing automatically in some time, like 2 weeks. On Thu, 19 Nov 2020 09:33:03 -0500 Cubed wrote: > Good morning. > > I was notified today that this bug had been resolved. As someone somewhat > new to TV in over the last year I'm curious where I can obtain this updated > kernel. I am in Bullseye testing and have updated to the 5.9.6.1. The > resolution email states that there is a stable 5.9.7 and I was curious > where to obtain that to resolve my issue by taking advantage of the big > closure. > > Thank you > > Jonathan
Bug#975502: nedit: Shortcuts broken if .motifbind file exists
Package: nedit Version: 1:5.7-2 Severity: important Nedit input handling fails dramatically if a ~/.motifbind file exists. To reproduce the behavior, create this ~/.motifbind file: osfCut : Ctrlx osfCopy : Ctrlc osfPaste: Ctrlv Issue xmbind and launch Nedit. Verify that the characters x, c and v cannot be inputed anymore, instead they trigger the cut, copy and paste clipboard actions. Furthermore, dialogs and menu items cannot be navigated with arrow keys. Multiple additional nasty side-effects probably exist. Note that .motifbind is a file to remap general purpose keys in Motif applications (e.g. Xmgrace and Xpdf), so deleting the file should not be a solution. -- System Information: Debian Release: 10.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-12-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages nedit depends on: ii libc6 2.28-10 ii libx11-6 2:1.6.7-1+deb10u1 ii libxm42.3.8-2 ii libxt61:1.1.5-1+b3 Versions of packages nedit recommends: ii xfonts-100dpi 1:1.0.4+nmu1 ii xfonts-75dpi 1:1.0.4+nmu1 Versions of packages nedit suggests: pn csh -- no debconf information
Bug#975510: ITP: deepin-wallpapers -- DDE wallpapers
Package: wnpp Severity: wishlist Owner: Hu Feng X-Debbugs-Cc: debian-de...@lists.debian.org * Package name : deepin-wallpapers Version : 1.6.14 Upstream Author : amazingfate * URL : https://github.com/linuxdeepin/deepin-wallpapers License : GPL-3+ Programming Lang: Makefile Description : DDE wallpapers When users are ready to set their own desktop background, Deepin Wallpaper provides many beautiful background pictures for users to choose. . It is part of Deepin software and DDE (Deepin Desktop Environment). I intend to co-maintain this package inside pkg-deepin group.
Bug#975509: ITP: nbdime -- Jupyter Notebook Diff and Merge tools
Package: wnpp Severity: wishlist Owner: Joseph Nahmias * Package name: nbdime Version : 2.1.0 Upstream Author : Jupyter Development Team * URL : https://nbdime.readthedocs.io/ * License : BSD Programming Lang: Python Description : Jupyter Notebook Diff and Merge tools nbdime provides tools for diffing and merging of Jupyter Notebooks. . * nbdiff - compare notebooks in a terminal-friendly way * nbmerge - three-way merge of notebooks with automatic conflict resolution * nbdiff-web - shows you a rich rendered diff of notebooks * nbmerge-web - gives you a web-based three-way merge tool for notebooks * nbshow - present a single notebook in a terminal-friendly way
Bug#975508: ITP: node-yaml -- Nodejs parser and stringifier for YAML standard
Package: wnpp Severity: wishlist Owner: Xavier Guimard X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: node-yaml Version : 1.10.0 Upstream Author : Eemeli Aro * URL : https://github.com/eemeli/yaml * License : ISC Programming Lang: JavaScript Description : Nodejs parser and stringifier for YAML standard yaml is a JavaScript parser and stringifier for YAML, a human friendly data serialization standard. It supports both parsing and stringifying data using all versions of YAML, along with all common data schemas. As a particularly distinguishing feature, yaml fully supports reading and writing comments and blank lines in YAML documents. This is a (optional) dependency of many packages like npm, node-coffee-loader, node-tap,... It's not easy to replace it by node-js-yaml since API and behavior are really different. node-yaml will be maintained under JS Team umbrella
Bug#975507: ansible/buster-backports incompatible with systemd/buster-backups (https://github.com/ansible/ansible/pull/68211)
Package: ansible
Version: 2.9.6+dfsg-1~bpo10+1
Severity: minor
Is it possible to get https://github.com/ansible/ansible/pull/68211 fixed in
ansible/buster-backports?
I ran into this today:
FAILED! => {"changed": false,
"msg": "Malformed output discovered from systemd
list-unit-files: alsa-restore.servicestatic
enabled "}
AFAICT this is the problem change (from systemd NEWS):
CHANGES WITH 245:
* "systemctl list-unit-files" has been updated to show a new column
with the suggested enablement state based on the vendor preset files
for the respective units.
You can see the difference between buster-backports and buster:
bash5$ systemctl --version
systemd 245 (245.7-1~bpo10+1)
+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP
+GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2
default-hierarchy=hybrid
bash5$ list-unit-files --no-pager --type service --all | head -2
UNIT FILE STATE VENDOR PRESET
alsa-restore.servicestatic enabled
bash5$ systemctl --version
systemd 241 (241)
+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP
+GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2
default-hierarchy=hybrid
bash5$ systemctl list-unit-files --no-pager --type service --all | head -2
UNIT FILE STATE
accounts-daemon.serviceenabled
The code that needs to change is here:
https://github.com/ansible/ansible/blob/devel/lib/ansible/modules/service_facts.py#L221
https://github.com/ansible/ansible/pull/68211
-- System Information:
Debian Release: 10.6
APT prefers stable
APT policy: (990, 'stable'), (500, 'stable-updates'), (500,
'proposed-updates')
Architecture: amd64 (x86_64)
Kernel: Linux 5.6.0-0.bpo.2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE=en_AU:en
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages ansible depends on:
ii openssh-client1:7.9p1-10+deb10u2
ii python3 3.7.3-1
ii python3-crypto2.6.1-9+b1
ii python3-cryptography 2.6.1-3+deb10u2
ii python3-distutils 3.7.3-1
ii python3-dnspython 1.16.0-1
ii python3-httplib2 0.11.3-2
ii python3-jinja22.10-2
ii python3-netaddr 0.7.19-1
ii python3-paramiko 2.6.0-1~bpo10+1
ii python3-yaml 3.13-2
Versions of packages ansible recommends:
ii python3-argcomplete 1.8.1-1
ii python3-jmespath 0.10.0-1
ii python3-kerberos 1.1.14-2
ii python3-libcloud 2.4.0-1
ii python3-selinux 2.8-1+b1
ii python3-winrm0.3.0-2
ii python3-xmltodict0.11.0-2
Versions of packages ansible suggests:
pn cowsay
pn sshpass
-- debconf-show failed
Bug#974428: in.telnetd crashes on running Nessus security scan
Thanks for acknowledging the Bug report and identifying a fix.Like to know, when netkit-telnet package deb with the bug fix be released.Please let me know , in case someone is aware of the release plan.Thanks in advance.
Bug#975506: reportbug: Left mouse button stops working (do nothing)
Package: reportbug Version: 7.5.3~deb10u1 Severity: normal Left mouse button suddenly stops working. xinput reports that it can read button state but the button do nothing. There is known work around to switch to other console and back. -- Package-specific info: ** Environment settings: INTERFACE="gtk" ** /home/vadim/.reportbugrc: reportbug_version "7.5.3~deb10u1" mode advanced ui gtk realname "gvaduha" email "gvad...@gmail.com" no-cc list-cc-me smtphost reportbug.debian.org -- System Information: Debian Release: 10.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-12-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE=en_IN:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages reportbug depends on: ii apt1.8.2.1 ii python33.7.3-1 ii python3-reportbug 7.5.3~deb10u1 ii sensible-utils 0.0.12 reportbug recommends no packages. Versions of packages reportbug suggests: pn claws-mail pn debconf-utils ii debsums 2.2.3 pn dlocate pn emacs-bin-common ii file1:5.35-4+deb10u1 ii gnupg 2.2.12-1+deb10u1 pn postfix | exim4 | mail-transport-agent pn python3-urwid pn reportbug-gtk ii xdg-utils 1.1.3-1+deb10u1 Versions of packages python3-reportbug depends on: ii apt1.8.2.1 ii file 1:5.35-4+deb10u1 ii python33.7.3-1 ii python3-apt1.8.4.1 ii python3-debian 0.1.35 ii python3-debianbts 2.8.2 ii python3-requests 2.21.0-1 ii sensible-utils 0.0.12 python3-reportbug suggests no packages. -- no debconf information
Bug#975470: python-meshplex: autopkgtest regression on 32 bit archs: TypeError: Cannot cast array data from dtype('int64') to dtype('int32') according to the rule 'safe'
Control: forwarded 975470 https://github.com/nschloe/meshplex/issues/90 Yeah, issue #90 already raised upstream. Drew
Bug#975505: Please package v3.0.5 or newer
Source: mathjax Severity: normal Dear MathJax maintainers, Debian's MathJax is out of date (2.7.9), and I've noticed that some packages have had to start to resort to bundling a 3.x release. Please package v3.0.5 or newer. Thank you, Nicholas
Bug#563204: Recommends is really too strong for os-prober
Commenting since the report still exists in the bug DB... I've found `os-prober` often produces many false positive OS installation detections. As such I really find recommends too strong, simply including during installation and then merely suggests would be better. If someone removes it, likely that is due to not needing it and the choice should be honored. Worse, on VM systems searching for additional OS installations is a major security risk due to potential for finding VMs instead of host. If one of those manages to boot on bare hardware, everything is compromised. Producing messages during updates though is reasonable. Just don't be too pushy, even keeping recommends packages from being reinstalled requires a careful eye. Mostly documenting some people *really* don't want os-prober, even though we are likely the minority. -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+sig...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
Bug#975504: obs-studio: reproducible builds: Embeds date in appdata.xml file
On 2020-11-22, Vagrant Cascadian wrote:
> A date string that defaults to the current date is embedded in
> /usr/share/metainfo/com.obsproject.Studio.appdata.xml, causing builds on
> different days to not build reproducibly.
>
>
> https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/diffoscope-results/obs-studio.html
> 21 21
>
>
> This can be fixed by setting a value from the configure target that uses
> SOURCE_DATE_EPOCH:
>
> https://reproducible-builds.org/docs/source-date-epoch/
>
> The attached patch does this.
>
>
> Alternately, it may be worth exploring patching
> UI/xdg-data/CMakeLists.txt to support SOURCE_DATE_EPOCH and get the
> support merged upstream.
In case you prefer that approach, the attached patch implements
it... though needs more work to be cross-platform as it relies on
specific features of GNU date. The source-date-epoch link above
documents some of that.
live well,
vagrant
From b18355ee4991bb1a1c1160f35d7abe2f18175cfc Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian
Date: Mon, 23 Nov 2020 02:59:54 +
Subject: [PATCH 3/3] UI/xdg-data/CMakeLists.txt: Set APPDATA_RELEASE_DATE from
SOURCE_DATE_EPOCH environment variable to ensure reproducible builds.
https://reproducible-builds.org/docs/source-date-epoch/
---
UI/xdg-data/CMakeLists.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/UI/xdg-data/CMakeLists.txt b/UI/xdg-data/CMakeLists.txt
index 9acd14e..1883902 100644
--- a/UI/xdg-data/CMakeLists.txt
+++ b/UI/xdg-data/CMakeLists.txt
@@ -4,6 +4,9 @@ if(NOT DEFINED APPDATA_RELEASE_DATE)
OUTPUT_VARIABLE APPDATA_RELEASE_DATE
WORKING_DIRECTORY "${CMAKE_SOURCE_DIR}"
OUTPUT_STRIP_TRAILING_WHITESPACE)
+ elseif(DEFINED SOURCE_DATE_EPOCH)
+ execute_process(COMMAND date --utc --date="@${SOURCE_DATE_EPOCH}" +"%Y-%m-%d"
+ OUTPUT_VARIABLE APPDATA_RELEASE_DATE)
else()
file(TIMESTAMP "${CMAKE_SOURCE_DIR}/CMakeLists.txt" APPDATA_RELEASE_DATE "%Y-%m-%d")
endif()
--
2.29.2
signature.asc
Description: PGP signature
Bug#974178: python3-biom-format: debci tests fail: Object of type bytes is not JSON serializable
Control: fixed 974178 2.1.10-1 On 2020-11-22 04:03, Nilesh Patra wrote: Hi, debci seems happy now. https://ci.debian.net/packages/p/python-biom-format/unstable/amd64/ https://ci.debian.net/data/autopkgtest/unstable/amd64/p/python-biom-format/8336917/log.gz Should this bug be closed now? Please let me know/do so if you feel this is done. (I can close it myself in a few days when there are more logs) Tests are passing fine, looks like 2.1.10-1 has fixed it up. Close the bug whenever you're ready. Drew
Bug#947431: xerces-c: CVE-2018-1311: use-after-free vulnerability processing external DTD
Yes, this seems reasonable. I'll prepare an upload to unstable prior to the freeze. But it likely won't be for a couple of weeks due to my current workload. Since I assume one of your concerns is for LTS, feel free to do the LTS upload. Or, if you'd rather, I can make an attempt at that in a couple of weeks as well. Best regards, Bill
Bug#975504: obs-studio: reproducible builds: Embeds date in appdata.xml file
Source: obs-studio
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
A date string that defaults to the current date is embedded in
/usr/share/metainfo/com.obsproject.Studio.appdata.xml, causing builds on
different days to not build reproducibly.
https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/diffoscope-results/obs-studio.html
21 21
This can be fixed by setting a value from the configure target that uses
SOURCE_DATE_EPOCH:
https://reproducible-builds.org/docs/source-date-epoch/
The attached patch does this.
Alternately, it may be worth exploring patching
UI/xdg-data/CMakeLists.txt to support SOURCE_DATE_EPOCH and get the
support merged upstream.
Thanks for maintaining obs-studio!
live well,
vagrant
From afafba3e2105ca188e1a2b14398d65014b5fc370 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian
Date: Mon, 23 Nov 2020 01:58:40 +
Subject: [PATCH] debian/rules: Set APPDATA_RELEASE_DATE using the
SOURCE_DATE_EPOCH variable to avoid embedding the current date in the
/usr/share/metainfo/com.obsproject.Studio.appdata.xml file.
https://reproducible-builds.org/docs/source-date-epoch/
---
debian/rules | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/debian/rules b/debian/rules
index 80a4ae9..e0b1c17 100755
--- a/debian/rules
+++ b/debian/rules
@@ -16,7 +16,8 @@ override_dh_auto_configure:
-DUNIX_STRUCTURE=TRUE \
-DDISABLE_UPDATE_MODULE=TRUE \
-DBUILD_CAPTIONS=ON \
- -DOBS_VERSION_OVERRIDE=${DEB_VERSION}
+ -DOBS_VERSION_OVERRIDE=${DEB_VERSION} \
+ -DAPPDATA_RELEASE_DATE=$(shell date --utc --date=@$${SOURCE_DATE_EPOCH} +'%Y-%m-%d') \
execute_after_dh_auto_build:
rst2man debian/obs.rst > debian/obs.1
--
2.20.1
signature.asc
Description: PGP signature
Bug#975503: debian/rules hardcodes Python version; FTBFS on buster
Package: gammastep Version: 2.0.2-3 Thanks for packaging gammastep! I was trying to build the package on buster, but it failed with: /usr/bin/mkdir -p '/home/tbm/debian/gammastep-2.0.2/debian/gammastep/usr/lib/python3.7/site-packages/gammastep_indicator' ^^^ ... mv debian/gammastep/usr/lib/python3.8/site-packages/gammastep_indicator debian/gammastep/usr/lib/python3/dist-packages/ mv: cannot stat 'debian/gammastep/usr/lib/python3.8/site-packages/gammastep_indicator': No such file or directory ^^^ The problem is that debian/rules hard-codes the Python version. I'm don't know anything about Python packaging in Debian, but I guess it would be best not to hard-code specific versions (since that will also fail when sid moves to 3.9). -- Martin Michlmayr https://www.cyrius.com/
Bug#975374: [Pkg-sugar-devel] Bug#975374: sugar-calculate-activity: reproducible builds: Embeds build path in .desktop file
Upstream bug https://github.com/sugarlabs/sugar-toolkit-gtk3/issues/453 sugar-toolkit-gtk3 does not provide DESTDIR support yet, and cdbs passes DEB_DESTDIR as PREFIX.
Bug#975373: [Pkg-sugar-devel] Bug#975373: sugar-read-activity: reproducible builds: Embeds build path in .desktop files
Upstream bug https://github.com/sugarlabs/sugar-toolkit-gtk3/issues/453 sugar-toolkit-gtk3 does not provide DESTDIR support yet, and cdbs passes DEB_DESTDIR as PREFIX.
Bug#972709: Wishlist/RFC: Change to CONFIG_PREEMPT_NONE in linux-image-cloud-*
On Sun, Nov 22, 2020 at 03:53:32PM -0800, Flavio Veloso Soares wrote: > Unfortunately, I couldn't find many comprehensive benchmarks of kernel > CONFIG_PREEMPT* options. The one at > > [1]https://www.codeblueprint.co.uk/2019/12/23/linux-preemption-latency-throughput.html > seems to be very thorough, > > [...] > > Not particularly. I'm used to latency benchmarks showing e.g. average, > 90th percentile, 99th percentile, as well as worst. I don't think Ben was talking about specific benchmarks. The web page you cites lacks basic measurements one would expect to see from *any* meaningful performance benchmark. Comparing maximum latency is fine, but it's not really relevant by itself. If a configuration change improves the worst case (100th percentile) but negatively impacts the 50th percentile, is that a change worth making? Maybe. But without having that data at all, the benchmark really isn't worth much at all. It's totally reasonable for us to consider making this change, but we should have comprehensive data about the impact of doing so. What impact does the change have on different classes of workloads? e.g. high tps, CPU-bound, IO-bound, etc. It's entirely possible that the proposed change improves performance under certain workloads, but negatively impacts others. Without knowing the impact in more in more detail, which would allow us to evaluate the tradeoffs, I don't think there's a compelling reason to make a change. noah
Bug#975209: FTBFS: src/v2ray.com/core/transport/internet/quic/conn.go:11:2: cannot find package "github.com/lucas-clemente/quic-go"
control: reassign -1 golang-v2ray-core-dev 4.31.0+ds-1~exp1 golang-v2ray-core-dev should depend on golang-github-lucas-clemente-quic-go-dev
Bug#975501: FTBFS: undefined reference to symbol 'SSL_get_verify_callback@@OPENSSL_1_1_0'
Package: dpaste Version: 0.4.0-1 Severity: serious Justification: ftbfs X-Debbugs-Cc: z...@debian.org Dear Maintainer, When rebuild your package, it FTBFS g++ -std=c++17 -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -std=c++17 -Wl,-z,relro -Wl,-z,now -o dpaste dpaste-main.o libdpaste.a -lopendht -lnettle -lgnutls -largon2 -lhttp_parser -lpthread -lglibmm-2.4 -lgobject-2.0 -lglib-2.0 -lsigc-2.0 -Llib/x86_64-linux-gnu -lcurlpp -Wl,-z,relro -lcurl -lb64 -lgpgmepp -L/usr/lib/x86_64-linux-gnu -lgpgme -lassuan -lgpg-error /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libopendht.a(http.cpp.o): undefined reference to symbol 'SSL_get_verify_callback@@OPENSSL_1_1_0' /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libssl.so.1.1: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status
Bug#975490: u-boot-sunxi: Booting the system got stuck after "Starting kernel ..."
Control: found 975490 2020.10+dfsg-1+b1
Bug#975462: choqok: Wrong homepage
Hi! On Sun, 22 Nov 2020 at 12:39, Davide Prina wrote: > > Package: choqok > Version: 1.7.0-1 > Severity: normal > > I have see that the homepage > http://choqok.gnufolks.org/ > do not respond anymore > > I think that the new homepage is: > https://choqok.kde.org/ Thanks, fixed in the repo! -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/
Bug#975462: choqok: Wrong homepage
Control: tag -1 pending Hi! On Sun, 22 Nov 2020 at 12:39, Davide Prina wrote: > > Package: choqok > Version: 1.7.0-1 > Severity: normal > > I have see that the homepage > http://choqok.gnufolks.org/ > do not respond anymore > > I think that the new homepage is: > https://choqok.kde.org/ Thanks Davide! I have just fixed it in the repo. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/
Bug#975446: libzeep: FTBFS against boost_1.74
Hi, The bug report is for libzeep version 5, but the logs show that an attempt was made to compile version 3. I'm quite sure that building libzeep version 5 with boost 1.74 will succeed, since I've been using it myself for several weeks now. regards, -maarten Op 22-11-2020 om 13:28 schreef Anton Gladky: Package: libzeep Version: 5.0.2-3 Severity: important Tags: ftbfs User: team+bo...@tracker.debian.org Usertags: boost174 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear maintainer, it was discovered that your package failed to build against boost_1.74. Logs can be found here [1]. Most relevant part is probably this: dpkg-source: info: using options from libzeep-3.0.5/debian/source/options: --extend-diff-ignore=(^|/)(.vscode/.*|msvc|\.gitignore|\.travis\.yml|tests|zeep-test.*|webapp-test.cpp|doc/bin)$ fakeroot debian/rules clean dh clean dh_auto_clean make -j4 clean make[1]: Entering directory '/<>' rm -rf obj/* libzeep.a libzeep.so* zeep-test libzeep-3.0.5 libzeep-3.0.5.tgz cd doc; bjam clean Unable to load B2: could not find 'boost-build.jam' - --- Attempted search from '/<>/doc' up to the root at '/usr/bin/b2' Please consult the documentation at 'https://boostorg.github.io/build/'. make[1]: *** [makefile:122: clean] Error 1 make[1]: Leaving directory '/<>' dh_auto_clean: error: make -j4 clean returned exit code 2 make: *** [debian/rules:8: clean] Error 25 It is planned to push boost_1.74 as the default version in Debian/Bullseye. [1] http://qa-logs.debian.net/2020/10/27-boost/boost/libzeep_3.0.5-2_unstable_boost.log Best regards Anton - -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-1-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -BEGIN PGP SIGNATURE- iQJFBAEBCgAvFiEEu71F6oGKuG/2fnKF0+Fzg8+n/wYFAl+6WXURHGdsYWRrQGRl Ymlhbi5vcmcACgkQ0+Fzg8+n/wYXFQ/6AobGTBmLGOayKBafvfY7JKMuOvQUt/CN 3x0Q1q9JKT3PrAiDupOILvGpU7kLVwXm+Xj7Y6jmOFmQXAIiejQINB5S3SMm3OW/ GJb2MkcbeAr/1gKnoRiXWGauFjBXT+RfHwKCB0qCRxaCcgd6wqN/sur9LiK1o9Jb yAxYOhsAuqU3zrmGbJ6H9WGzRsOAFjhWRDu9vvq9+XWwhCZ1msETk8J+ube6dI3G uYpkUgEUxf6dSLYAFki2vKtSX6TonmFwJ9Zn3uMer1OlTwOPGFfeKFP+Hvgd+Fx5 lwbGAh6RkoxM+9a+q+MSnIyhVoqMSYKWGbazen1SbJiQSR2tf8INYpryjd9wTYbK aFlazYitywFTlq4I9cu+vDuHzLP6/rV480+v6ZRKgNLO8ciNu3i/vB/a8G23cdAu Bite4zw/29R5ekDUIvZcLLUSTVYfArKd1gMeRbVQFx9Y/AcFBC1/eZwqeiQFKmZv c1PwFhB9bl54jDqS/mb7c85uhzt2LEbEeLrzo69TaUxjo1/1vQCvZa2FMn5uZgBF aQwH4QSlL8Qh1zd3DW6DpQUzC4hg9TWFH/xIulFfuS46i2vD6UUDZYO/lBsw9Bod a5Sgqn6aeKSZs2StgSOf8HFF067rSOYbC3oaDO9/7xBmNe8FHjYLV27mFr6+Sotu OObqY7WdDP4= =ljID -END PGP SIGNATURE- -- Maarten L. Hekkelman http://www.hekkelman.com/
Bug#975500: ITP: python-ansicolors -- Add ANSI colors and decorations to your strings.
Package: wnpp Severity: wishlist Owner: nicoo X-Debbugs-Cc: debian-de...@lists.debian.org, Debian Python Team Control: block 975497 by -1 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: python-ansicolors Version : 1.1.8 Upstream Author : Jonathan Eunice * URL : http://github.com/jonathaneunice/colors/ * License : ISC Programming Lang: Python Description : Add ANSI colors and decorations to your strings. A Python library to add ANSI colors and decorations to strings. ansicolors is a build dependency of multiplex (ITP #975497) -BEGIN PGP SIGNATURE- iQJFBAEBCgAvFiEEU7EqA8ZVHYoLJhPE5vmO4pLV7MsFAl+6/BgRHG5pY29vQGRl Ymlhbi5vcmcACgkQ5vmO4pLV7Mt8chAAqKrmM3kjqFpclsuYvJyKWIs86CyjYMaF OVpEs1COYH9rzLApJq/bJk3FJMXMmSEe8vYzGf/CJEyTlx0hUJOYc2/4yVdCziNJ 0c5/Ql/niVL7aCroBkszLvuTV5lSjgwN65L0pTp2iBtqolby2FX1t/TWpaRitDo4 MKfezQsptKduT8HMbo4VVyms9Bl9E+RzOuCc3+SOvF0/dRv9Y/AyqsX8XIaxrWja LQlUk3dBBUuUxEnAxIbENg43crZA3gUuGd8d89WT0c/k9jMYHWfj70VOQsV/onFJ V2IpvFKnnmmI+WB5FMQK7z5CKizsyWyZ/vm/c5EVWhSfyTk+akymASS/ECIgKYhq ojSIWUtv+jtk3amPHPeVEiPcVF2dJ17JgmCgSk50+zXeZyJt5tdqayhrlig2z3TC m12LOHqEnLJA3Yd4pji2MzMeg91gu1YkLwRFgQFprszCU1d8by1N+2RJTO0xjfIe vCExQgIeEfzpuvGKp9Y/d88h+E2nwcrfNtdx/nRkzHgoDZJoqxuiJCxF1xaxM7CU wUMLjNOkepKSTmbI2T2yli4WzVsY5AfQr+RSTNUTIWCpRcZI9i0Q5H5eZBe86uXw YCcatRfelZr0VGN/TCaNnHjyc39e584V6Ubfhx3IxU2U5pztm/8V8/A/rdcsBtqH mFNN6ZG8F04= =NLWN -END PGP SIGNATURE-
Bug#975499: ITP: python-easy-ansi -- terminal framework for colors, cursor control movements, and line/box drawing
Package: wnpp Severity: wishlist Owner: nicoo X-Debbugs-Cc: debian-de...@lists.debian.org, Debian Python Team Control: block 975497 by -1 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: python-easy-ansi Version : 0.3 Upstream Author : Joey Rockhold * URL : https://gitlab.com/joeysbytes/easy-ansi * License : MIT Programming Lang: Python Description : terminal framework for colors, cursor control movements, and line/box drawing Easy ANSI is a terminal framework API to give you an easy way to use colors, cursor control movements, and line/box drawing. It is not meant as a replacement to more full-featured frameworks (such as curses or urwid), but as a tool to quickly create nice-looking screens in your terminal window. You can even create animations with the cursor controls. easy-ansi is a dependency of multiplex (ITP #975497) -BEGIN PGP SIGNATURE- iQJFBAEBCgAvFiEEU7EqA8ZVHYoLJhPE5vmO4pLV7MsFAl+6+xURHG5pY29vQGRl Ymlhbi5vcmcACgkQ5vmO4pLV7Murqg/+Np2vUc4gysQLzLck2SoaaVQ5O0U2i2E9 WyR82JGdT4UjKAaLea88XccWvRYOT4MP3WgsIZxYKx72+MX4Q4D/qZ6nHpPdjvW9 W1lmnV/ZA9FZsxDLsxvLNP6NtloPuApPe/oEHoEHsWWGRO3GjNOACOCnbHXBOW7B uKr+Qp4NC9mz49AmzXqHJjFQpdQanZZKFW3CMRr1mHq4O/N4qZYtmww02s7qt+hM CEqKhjc/ODzXxWPibt8NLW+uCPno72VPuUvKUxftcrxc6np2mICJlty8R49JT9RW MKaHGNgd6vV5P1gUyK90mOO0+kAjVM8BGU1LY9c/TC6xbA7djw5Ku54aX8/2NUHG pUMX1cT5VcIROSglKvuz5TibmdvrTSB1gBHfURUy9moKTcIoUJx12w8Dap6o2kxF n1dpf1r+IsBEpELpmImGxPM7bE9fzCTu/Hx+5AKhzBP+vSOjYnUmfVAwMLWzaJmu AnX0HhbO5TJ3L77hQGyEyd3r4fixgE5rCYAyrHiVBfjCpGxpxRBxKev3Wdi7S6pi d+nwP78yDMZY1vC6RecYzaGUnOEhegMoL15BJ/PzJSGbmOcXgpRWHwPQGoCw1khV 6efrAd0dBpQDuQ3zhk1G05ubmfRbG7QV99dDZVjNzEJ+pX3QMuYo3+p10sHK3ahT hSh/NvsuvVg= =s5y4 -END PGP SIGNATURE-
Bug#972709: Wishlist/RFC: Change to CONFIG_PREEMPT_NONE in linux-image-cloud-*
On 2020-11-22 2:28 p.m., Ben Hutchings wrote: On Sun, 2020-11-22 at 13:45 -0800, Flavio Veloso Soares wrote: [Resending: just noticed that the reply I sent on Oct 23 didn't include b.d.o] I don't think the article is about the same thing we're talking here. CONFIG_PREEMPT* options control the compromise between latency and throughput of *system calls* and *scheduling of CPU cycles spent in kernel mode*, not network traffic. The latency of requests to services on a server is affected by both scheduler and network latency. [...] "Services" is a too broad term. Which kind of service are you talking about? For the record, I'm talking about latency of kernel system calls specifically, which happens to be what CONFIG_PREEMPT* controls. Unfortunately, I couldn't find many comprehensive benchmarks of kernel CONFIG_PREEMPT* options. The one at https://www.codeblueprint.co.uk/2019/12/23/linux-preemption-latency-throughput.html seems to be very thorough, [...] Not particularly. I'm used to latency benchmarks showing e.g. average, 90th percentile, 99th percentile, as well as worst. Ben. Are those benchmarks public? Can you provide links to them? -- FVS
Bug#975498: ITP: python-aiostream -- Generator-based operators for asynchronous iteration
Package: wnpp Severity: wishlist Owner: nicoo X-Debbugs-Cc: debian-de...@lists.debian.org, Debian Python Team Control: block 975497 by -1 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: python-aiostream Version : 0.4.1 Upstream Author : Vincent Michel * URL : https://github.com/vxgmichel/aiostream * License : GPLv3 Programming Lang: Python Description : Generator-based operators for asynchronous iteration aiostream provides a collection of stream operators that can be combined to create asynchronous pipelines of operations. It can be seen as an asynchronous version of itertools, although some aspects are slightly different. Essentially, all the provided operators return a unified interface called a stream. A stream is an enhanced asynchronous iterable. aiostream is a dependency of multiplex (ITP #975497) -BEGIN PGP SIGNATURE- iQJFBAEBCgAvFiEEU7EqA8ZVHYoLJhPE5vmO4pLV7MsFAl+6+e4RHG5pY29vQGRl Ymlhbi5vcmcACgkQ5vmO4pLV7MsVCA//bVHfhooj83gcDiIxSRM0J1sBYooyKVTT tJMzrR8dDT3zMZoLzRRue/H+hZHYUyS/ruWSUKb/KFJgepkN2NYmQ2J9CwrjQvdw XT7KucxxDKNdUoQbZGRYjo6fVOapSqZPGfQGjTFwPLG4vnWMfu8ijxhumG+R/RmG cOmfF/Q+T9TSeaWXz2ze38qfysoYW2jXY/BHe0kX7FVTJXJBdAq4Rm3Xfgzo9f3D NSeCzV9TjZtfmSkhPOwziVcuY6jsyChxQL+QeRR0P7HZYEhOnrrCCEma9WtYKH7d xSEhE283FMz9Qd5qUeqOWQmNeKTKokYzBabyNXuQQdwAXUKx9PwgU0J+TmD6+gBQ YlUFe0XjtdM/vHKixseGb1Xtm5nlihCr8ep1HrTcw9A/Mhbrhwr+gnh1HjZcQ52S EimhV9die9x+9bFW0UfbO1ecyMeUHd+JH5/ldSwZzZUGDnHlF2ofHesBdhQCOV97 7KFV6Wx3dAJCpxpAY4KICzO7qc8ixKtvwWW+wqap1eKeyXZK3mqTo0+0jy/eUyRG yfLHrxs4DWUQA0W38dM0N0amWBvxUke+GFFjPtLTjl3I+rzjncBqmKmgleQuoYje V7MlI5lLCSH85+URWLoqKhGkj3i0VQuaoS8WmVVBKlDoYW0OiPDMjMPQO+TeXWDn StZ8TGDyc2M= =IOGl -END PGP SIGNATURE-
Bug#975497: ITP: multiplex -- View output of multiple processes, in parallel.
Package: wnpp Severity: wishlist Owner: nicoo X-Debbugs-Cc: debian-de...@lists.debian.org, Debian Python Team -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: multiplex Version : 0.5.1 Upstream Author : Dan Kilman * URL : https://github.com/dankilman/multiplex * License : MIT Programming Lang: Python Description : View output of multiple processes, in parallel. View output of multiple processes, in parallel, in the console, with an interactive TUI. Also usable programatically, as a Python library. -BEGIN PGP SIGNATURE- iQJFBAEBCgAvFiEEU7EqA8ZVHYoLJhPE5vmO4pLV7MsFAl+676QRHG5pY29vQGRl Ymlhbi5vcmcACgkQ5vmO4pLV7MsTFA//R19TtK/qdaoypVG3N0vSThN/lFr+bCBJ PSFYGKu/vm8U9vqQkMmUnaNPe4Wl0D8H1Q/M8IIHiHuZOFstX1l4AqSsbL643uA0 Kyb0I/Az9sIGx0H/MSYuQRoWb1GsAqJEzz5ljgWawZZ2Zf10jLIKNN1ifNNA5w4i lYvVGzytxRlzTmayUOi7sI+N5hjoYeQUOVOzoFsHLsIqrzHpFBgWNrcfFGinHGrJ Qu+oLG3D5O5d3A0dPEqzIOUqjv6jFMjhYazTqA/pFmiLSFNGg8t9c3PQKWx0ifWu Il26QZvrbEs1GHy1C2BGqJzLTR9WRm26BfHOMpOd/nEXoAB6jrZeb8nS7w2lspBn jeCuR3Siz72Y4/YLon3wcUF96XPVpola5pB65Uzf4Zq1tocEmSAsKwXJYFCBMEDu oKIkrfElCE23boAdBv0uIErnUSmSY4fJa6YVk3c2skNRZZx33ldpJi81aVUexnOQ DrVV0iPGRQd6JZHodoqz22LwGOm/LZUvHVapKt/kxoYH1XstEH3tnaAE3xtmXRed dXQdKQjZGT4dgDt9wiZEcutMgamlFRLQhhE2PAzDBOGfYkpsqVQ/oDCg2/2jmXVw P3q5MtRs9ZWZcPUbDZr+CDMl+aojO4MUOrgYysxmLY3ooyyhdHNMBK5gGM2hRGjl DAaAB4pUEoE= =0T9h -END PGP SIGNATURE-
Bug#973326: double-conversion: Misbuild with -O3: DoubleToStringConverter::DoubleToStringConverter() constructor dropped from exported symbols
NMU diff attached. Christoph No differences were encountered between the control files diff -Nru double-conversion-3.1.5/debian/changelog double-conversion-3.1.5/debian/changelog --- double-conversion-3.1.5/debian/changelog 2020-10-17 14:20:08.0 +0200 +++ double-conversion-3.1.5/debian/changelog 2020-11-23 01:01:25.0 +0100 @@ -1,3 +1,13 @@ +double-conversion (3.1.5-6.1) unstable; urgency=medium + + * Non-maintainer upload. + * Compile with -O2 to prevent symbols disappearing with built with -O3. +Patch by Steve Langasek. (Closes: #973326) + * The same symbol is missing on *-kfreebsd even with -O2, mark it as +missing. + + -- Christoph Berg Mon, 23 Nov 2020 01:01:25 +0100 + double-conversion (3.1.5-6) unstable; urgency=medium [ Steve Langasek ] diff -Nru double-conversion-3.1.5/debian/libdouble-conversion3.symbols double-conversion-3.1.5/debian/libdouble-conversion3.symbols --- double-conversion-3.1.5/debian/libdouble-conversion3.symbols 2020-10-17 14:17:29.0 +0200 +++ double-conversion-3.1.5/debian/libdouble-conversion3.symbols 2020-11-23 01:01:25.0 +0100 @@ -1,7 +1,6 @@ libdouble-conversion.so.3 libdouble-conversion3 #MINVER# * Build-Depends-Package: libdouble-conversion-dev - (c++)"double_conversion::DoubleToStringConverter::DoubleToStringConverter(int, char const*, char const*, char, int, int, int, int)@Base" 3.1.5 - (c++)"double_conversion::DoubleToStringConverter::DoubleToStringConverter(int, char const*, char const*, char, int, int, int, int)@Base" 3.1.5 + (c++|arch=!kfreebsd-amd64 !kfreebsd-i386)"double_conversion::DoubleToStringConverter::DoubleToStringConverter(int, char const*, char const*, char, int, int, int, int)@Base" 3.1.5 (c++)"double_conversion::BignumDtoa(double, double_conversion::BignumDtoaMode, int, double_conversion::Vector, int*, int*)@Base" 2.0.0 (c++)"double_conversion::FastFixedDtoa(double, int, double_conversion::Vector, int*, int*)@Base" 2.0.0 (c++)"double_conversion::PowersOfTenCache::kMaxDecimalExponent@Base" 2.0.0 diff -Nru double-conversion-3.1.5/debian/rules double-conversion-3.1.5/debian/rules --- double-conversion-3.1.5/debian/rules 2020-01-11 07:27:54.0 +0100 +++ double-conversion-3.1.5/debian/rules 2020-11-23 01:01:25.0 +0100 @@ -2,6 +2,8 @@ export DEB_BUILD_MAINT_OPTIONS = hardening=+all export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed +export DEB_CXXFLAGS_MAINT_APPEND += -O2 +export DEB_CXXFLAGS_MAINT_STRIP += -O3 # Get compilation flags from dpkg-buildflags DPKG_EXPORT_BUILDFLAGS = 1
Bug#975115: webext-dav4tbsync and webext-tbsync out of sync
Package: webext-dav4tbsync Version: 1.23-1 Followup-For: Bug #975115 I'm also having problems with this on sid. When I open the thunderbird addon manager, I see tbsync, dav4tbsync, and eas4tbsync all installed and enabled. All of these come from the debian packages. However, when I open the tbsync config window it claims that dav4tbsync is not installed. There is no such problem with eas4tbsync (webext-eas4tbsync 1.20-1), which works fine. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages webext-dav4tbsync depends on: ii thunderbird1:78.5.0-1 ii webext-tbsync 2.18-2 webext-dav4tbsync recommends no packages. webext-dav4tbsync suggests no packages. -- no debconf information
Bug#704802: plperl crashes immediately on kfreebsd
Re: Peter Eisentraut > Creating a plperl function on kfreebsd (amd64) immediately crashes the > PostgreSQL server in the plperl.so module. You can see this either by > running the built-in regression tests (should probably be done during > the build anyway) or by running the tests from > t/020_create_sql_remove.t in the postgresql-common package. > > Everything else works, including all the other procedural languages > (Python, Tcl). > > I can also reproduce this problem with PostgreSQL Git master, so it's > not specific to the packaging. The actual problem might be somewhere > down the stack (libperl etc.). The failure mode has shifted since 2013. Now it looks like this: postgres=# create extension plperl; server closed the connection unexpectedly ... and the PostgreSQL server log then says: /build/postgresql-13-u7Fppv/postgresql-13-13.1/build/../src/pl/plperl/Util.c: loadable library and perl binaries are mismatched (got handshake key 0xe500080, needed 0xe580080) Christoph
Bug#975496: O: hercules -- System/370, ESA/390 and z/Architecture Emulator
Package: wnpp Severity: normal I intend to orphan the hercules package. It's an s390(x) emulator and the package itself is in fairly good shape overall. It's mostly that I have no use for it for several years now. (And mostly I do not want to feel responsible for it anymore.) Upstream has been trying for years to get a 4.0 release together[0], but the last commit for that was back in 2019. The website also moved around a bunch of times. So it's unclear at this point how maintained it is, if at all. qemu also offers a usable s390x emulator. I'd say that hercules is a lot more true to the original hardware, especially if you need to emulate the platform for something else than Linux. Or if you want to emulate an ancient System/360 or System/370. The package's description is: > Hercules is an open source software implementation of the mainframe > System/370 > and ESA/390 architectures, in addition to the new 64-bit z/Architecture. > . > This means that your PC can emulate an IBM mainframe processor. The > mainframe can range from a 360 to a z900 - running in "System/370" > mode, "ESA/390" mode, or "z/Architecture" mode. Hercules executes > S/370, ESA/390, and z/Architecture instructions and channel > programs. It emulates mainframe I/O devices by using PC devices. For > example, 3390 DASD devices are emulated by large files on your hard > disk, and local 3270 screens are emulated by tn3270 sessions. > . > Hercules implements only the raw S/370, ESA/390, and z/Architecture > instruction set; it does not provide any operating system facilities. This > means that you need to provide an operating system or standalone program > which > Hercules can load from an emulated disk or tape device. You will have to use > a > free software operating system such as Linux, write the operating system or > standalone program yourself, obtain a license from IBM to run one of their > operating systems on your PC, or use IBM programs and operating systems which > have been placed in the public domain. > . > Virtual networking can be accomplished using the TUN/TAP driver in > host Linux kernel. [0] https://github.com/hercules-390/hyperion signature.asc Description: OpenPGP digital signature
Bug#975490: u-boot-sunxi: Booting the system got stuck after "Starting kernel ..."
Control: version 975490 2020.10+dfsg-1+b1 Thanks for the bug report... On 2020-11-22, Benedikt Spranger wrote: > after a fresh install of Debian "bullseye" the first reboot got stuck > after "Starting kernel ..." > > It turend out that booting the system got always stuck using the a > "normal" u-boot boot sequence. Using extlinux or FIT-Images is not > affected. > > boot.scr : FAIL > extlinux : OK > FIT-Image: OK > > Since the Debian Installer provides neither extlinux configuration nor > build a FIT-Image the system is unusable after the reboot from the > installer. Very surprising that extlinux would work but boot.scr would not; they almost certainly use the same load addresses... This symptom is sometimes related to the kernel or device tree or initramfs overwriting the load address of one of the other values. Can you get to a u-boot prompt and: printenv fdt_addr_r kernel_addr_r ramdisk_addr_r Could you downgrade to the 2020.10+dfsg-1 version from snapshot.debian.org and see if that has the same issue? > I got into the same situation during an update on an other system to > bullseye. What other board? > Bootlog: > ---8<--- > U-Boot SPL 2020.10+dfsg-1+b1 (Nov 19 2020 - 03:18:11 +) > DRAM: 1024 MiB > Trying to boot from MMC2 > NOTICE: BL31: v2.3(): > NOTICE: BL31: Built : 05:17:48, Oct 18 2020 > NOTICE: BL31: Detected Allwinner A64/H64/R18 SoC (1689) > NOTICE: BL31: Found U-Boot DTB at 0x4093968, model: Olimex > A64-Olinuxino-eMMC INFO:ARM GICv2 driver initialized > INFO:Configuring SPC Controller > INFO:PMIC: Probing AXP803 on RSB > INFO:PMIC: Enabling DRIVEVBUS > INFO:PMIC: dcdc1 voltage: 3.300V > INFO:PMIC: dcdc5 voltage: 1.360V > INFO:PMIC: dcdc6 voltage: 1.100V > INFO:PMIC: dldo1 voltage: 3.300V > INFO:PMIC: dldo2 voltage: 3.300V > INFO:PMIC: dldo3 voltage: 2.800V > INFO:PMIC: dldo4 voltage: 3.300V > INFO:PMIC: fldo1 voltage: 1.200V > INFO:PMIC: Enabling DC SW > INFO:BL31: Platform setup done > INFO:BL31: Initializing runtime services > INFO:BL31: cortex_a53: CPU workaround for 843419 was applied > INFO:BL31: cortex_a53: CPU workaround for 855873 was applied > NOTICE: PSCI: System suspend is unavailable > INFO:BL31: Preparing for EL3 exit to normal world > INFO:Entry point address = 0x4a00 > INFO:SPSR = 0x3c9 > alloc space exhausted > > > U-Boot 2020.10+dfsg-1+b1 (Nov 19 2020 - 03:18:11 +) Allwinner > Technology > > CPU: Allwinner A64 (SUN50I) > Model: Olimex A64-Olinuxino-eMMC > DRAM: 1 GiB > MMC: mmc@1c0f000: 0, mmc@1c1: 2, mmc@1c11000: 1 > Loading Environment from FAT... Unable to use mmc 1:1... In:serial > Out: serial > Err: serial > Net: phy interface7 > eth0: ethernet@1c3 > starting USB... > Bus usb@1c1a000: USB EHCI 1.00 > Bus usb@1c1a400: USB OHCI 1.0 > Bus usb@1c1b000: USB EHCI 1.00 > Bus usb@1c1b400: USB OHCI 1.0 > scanning bus usb@1c1a000 for devices... 1 USB Device(s) found > scanning bus usb@1c1a400 for devices... 1 USB Device(s) found > scanning bus usb@1c1b000 for devices... 1 USB Device(s) found > scanning bus usb@1c1b400 for devices... 1 USB Device(s) found >scanning usb for storage devices... 0 Storage Device(s) found > Hit any key to stop autoboot: 0 > switch to partitions #0, OK > mmc1(part 0) is current device > Scanning mmc 1:1... > Found U-Boot script /boot.scr > 2225 bytes read in 2 ms (1.1 MiB/s) > ## Executing script at 4fc0 > 22744944 bytes read in 1003 ms (21.6 MiB/s) > 28403 bytes read in 5 ms (5.4 MiB/s) > 30071341 bytes read in 1326 ms (21.6 MiB/s) > Booting Debian 5.9.0-2-arm64 from mmc 1:1... > Moving Image from 0x4008 to 0x4020, end=4185 > ## Flattened Device Tree blob at 4fa0 >Booting using the fdt blob at 0x4fa0 > EHCI failed to shut down host controller. >Loading Ramdisk to 48352000, end 49fffa2d ... OK >Loading Device Tree to 48348000, end 48351ef2 ... OK > > Starting kernel ... I wish flash-kernel were more verbose about which files it is loading... are there other similar variants to this board that require a different device-tree and is the boot.scr loading the correct one? Maybe add some debugging into the boot.scr used in /etc/flash-kernel/ I'll test on a few of my systems to see if I can reproduce the issue. live well, vagrant signature.asc Description: PGP signature
Bug#972709: Wishlist/RFC: Change to CONFIG_PREEMPT_NONE in linux-image-cloud-*
On Sun, 2020-11-22 at 13:45 -0800, Flavio Veloso Soares wrote: > [Resending: just noticed that the reply I sent on Oct 23 didn't include > b.d.o] > > I don't think the article is about the same thing we're talking here. > CONFIG_PREEMPT* options control the compromise between latency and > throughput of *system calls* and *scheduling of CPU cycles spent in > kernel mode*, not network traffic. The latency of requests to services on a server is affected by both scheduler and network latency. [...] > Unfortunately, I couldn't find many comprehensive benchmarks of kernel > CONFIG_PREEMPT* options. The one at > https://www.codeblueprint.co.uk/2019/12/23/linux-preemption-latency-throughput.html > > seems to be very thorough, [...] Not particularly. I'm used to latency benchmarks showing e.g. average, 90th percentile, 99th percentile, as well as worst. Ben. -- Ben Hutchings If at first you don't succeed, you're doing about average. signature.asc Description: This is a digitally signed message part
Bug#973695: buster-pu: package ublock-origin/1.22.2+dfsg-1~deb10u1
Am Sonntag, den 22.11.2020, 18:37 + schrieb Adam D. Barratt: [...] > Assuming that's the only required change, please go ahead. Thanks. Reverting the debhelper bump to 12 was the only packaging change. I have uploaded ublock-origin 1.30.0 a few minutes ago. Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#972709: Wishlist/RFC: Change to CONFIG_PREEMPT_NONE in linux-image-cloud-*
[Resending: just noticed that the reply I sent on Oct 23 didn't include
b.d.o]
I don't think the article is about the same thing we're talking here.
CONFIG_PREEMPT* options control the compromise between latency and
throughput of *system calls* and *scheduling of CPU cycles spent in
kernel mode*, not network traffic. Granted, networking is affected by
the setting too, but intuition tells me that a nonpreemptible system
call -- meaning, one that finish all processing until it ends, or blocks
on I/O -- could even *decrease* network latency, not increase.
Unfortunately, I couldn't find many comprehensive benchmarks of kernel
CONFIG_PREEMPT* options. The one at
https://www.codeblueprint.co.uk/2019/12/23/linux-preemption-latency-throughput.html
seems to be very thorough, and shows that the difference of latency
between CONFIG_PREEMPT_VOLUNTARY and CONFIG_PREEMPT_NONE is actually
nonexistent, while no-preemption provides noticeable more throughput.
This unsurprising conclusion alone tells that CONFIG_PREEMPT_NONE is a
better choice for servers.
However, there's more. No benchmark touches the subject of overhead
context switches and burstable CPU cycles "credit" system used in many
(most?) cloud environments, which happens to be the target of *-cloud
kernels. With voluntary preemption, all those cycles used in overhead
context switches are not only wasted, but they still count against
instance CPU "credits", and that reduces overall computing power
available to the instance. This is like double-paying for something you
don't need.
On 2020-10-23 6:04 p.m., Ben Hutchings wrote:
On Thu, 2020-10-22 at 13:43 -0700, Flavio Veloso wrote:
Package: linux-image-cloud-amd64
Version: 4.19+105+deb10u7
Severity: wishlist
Since cloud images are mostly run for server workloads in headless
environments accessed via network only, it would be better if
"linux-image-cloud-*" kernels were compiled with CONFIG_PREEMPT_NONE=y
("No Forced Preemption (Server)").
Currently those packages use CONFIG_PREEMPT_VOLUNTARY=y ("Voluntary
Kernel Preemption (Desktop)")
CONFIG_PREEMPT_NONE description from kernel help:
[...]
I know what it says, but I think the notion that latency is less
important on servers is outdated.
It's well known that people give up quickly on web pages that are slow
to load:
Bug#971587: Subject: RFS: amavisd-milter/1.7.1-2 -- amavisd-new interface for milter-capable MTAs
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "amavisd-milter": * Package name: amavisd-milter Version : 1.7.1-2 Upstream Author : Petr Rehor * URL : https://github.com/prehor/amavisd-milter * License : BSD-3-clause, BSD-like, ISC * Vcs : * https://salsa.debian.org/haraldj-guest/amavisd-milter Section : mail It builds those binary packages: amavisd-milter - amavisd-new interface for milter-capable MTAs To access further information about this package, please visit the following URL: https://mentors.debian.net/package/amavisd-milter/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/a/amavisd-milter/amavisd-milter_1.7.1-2.dsc Last upload missed the source tar and the complete changelog for the package. The package is not lintian clean as I want to make it as easy as possible to backport them. Changes since the last upload: amavisd-milter (1.7.1-2) unstable; urgency=low . * debian/control: - Lower debhelper-compat dependency to 12 to ease backporting (thanks to Marcel Evenson). - Add a pre-dependency on init-system-helpers for usage of --skip-systemd-native invoke-rc.d flag, found by lintian (and again thanks to Marcel Evenson). - Create patch to fix two typos in documentation found by lintian. * debian/copyright: - Adapt copyright years. . amavisd-milter (1.7.1-1) UNRELEASED; urgency=low . * New upstream version (thanks to Marcel Evenson). * debian/changelog: - Trim trailing whitespace found by lintian. * debian/control: - Bump Standards to 4.5.0 demanded by lintian (no changes needed). - Remove debian/compat file in favour of debhelper-compat dependency found by lintian. - Bump debhelper-compat dependency to 13 found by lintian. * debian/upstream/metadata: - Add metadata as demanded by lintian. . amavisd-milter (1.7.0-1) UNRELEASED; urgency=low . * New upstream version (LP: #1691707, Closes: #854180) * debian/amavisd-milter.init: - Remove the loop to wait for MILTERSOCKET when MILTERSOCKETTYPE=pipe as upstream has fixed this in amavisd-milter itself. - Remove background option from start-stop-daemon line. * debian/patches: - Adapt pidfile-location patch to apply again. - Remove obsolete manpage-locations patch. - Add new manpage-users patch. * debian/amavisd-milter.docs: - Remove due to removed upstream files. * debian/clean: - Add file amavisd-milter/amavisd-milter.8. * debian/control: - Add pandoc to build dependencies (thanks to Marcel Evenson). . amavisd-milter (1.6.1-1) UNRELEASED; urgency=low . * New upstream version (LP: #1584180, Closes: #854039) * debian/changelog: - Fix spelling errors found by lintian. * debian/README.Debian: - Fix spelling error found by lintian. * debian/control: - Add lsb-base dependency demanded by lintian. - Bump debhelper dependency for dbgsym migration. - Remove dbg package. - Adapt dependencies for compat level 12. - Change VCS-fields to salsa.debian.org found by lintian. - Change priority to optional found by lintian. - Make dependency on dpkg-dev unversioned (fulfilled even in oldstable). - Declare Rules-Requires-Root: no. - Bump Standards to 4.3.0 (no changes needed). - Remove unversioned dependency on dpkg-dev demanded by lintian (it's already pulled in by the build-essential package). - Remove dependency on libmilter1.0.1 (fulfilled even in oldstable). - Change homepage address to new github page. * debian/patches: - Remove LDFLAGS patches incorporated upstream. - Refresh remaining patches. * debian/rules: - Adapt rules for migration from dbg to dbgsym package. - Adapt rules for migration to compat level 12 (remove --with autotools_dev line found by lintian). - Remove dh_installinit override (default since compat level 10). - Add CFLAGS and export all build flags. - Make verbose output the default. - Minimize auto_configure override to the needed parameters. * debian/compat: - Bump compat level to 12. * debian/copyright: - Use HTTPS format URI for copyright found by lintian. - Changed BSD to BSD-3-clause license demanded by lintian. * debian/amavisd-milter.init: - Remove superfluous colons. - Apply a patch from Matus Uhlar to set a default MILTERSOCKET variable (Closes: #879065). - Relocate chown commands to also apply on existing directories. - Add a loop to wait for MILTERSOCKET when MILTERSOCKETTYPE=pipe (LP: #1691707, Closes: #854180). - Start daemon with start-stop-daemon background option to fix startpar be stuck. * debian/watch: - Use version 4
Bug#975493: gitlab: Gitlab install script not working
On 2020, നവംബർ 23 1:56:21 AM IST, David L wrote: >Package: gitlab >Version: 13.3.9-1+fto10+1 >Severity: important > >Hi, > >Gitlab are not installing. > >I doesn't know the reason, but when I try to install it through apt-get >upgrade (following debian/gitlab page for upgrading), that's not working. > > >client_loop: send disconnect: Broken pipe >(that's the last line, an SSH console disconnection). > >These process tooks about 5 hours to do the error. I think the last try I've >started at about 14h or 15h (i do not remember) and problems appears at about >19h. That's my third try. > >On ps, the process running all the time are: > /usr/bin/ruby /usr/bin/rake tmp:cache:clear assets:precompile > >These process tools almost all of one core (100% CPU) at first, and all memory >(I've seen it with more than 10Gb of memory on a machine with 8Gb) Looks like a known issue with sassc. >On Syslog i've found: > >Nov 22 19:12:07 * gitaly[22539]: time="2020-11-22T19:12:07+01:00" >level=warning msg="gitaly-ruby worker health check failed" error="rpc error: >code = DeadlineExceeded desc = Deadline Exceeded" worker.name=gitaly-ruby.0 >Nov 22 19:12:24 * gitaly[22539]: time="2020-11-22T19:12:23+01:00" >level=warning msg="gitaly-ruby worker health check failed" error="rpc error: >code = DeadlineExceeded desc = context deadline exceeded" >worker.name=gitaly-ruby.0 > >I can do any new try to give more data but I doesn't have any more now. You have to use an older version of libsass. It is documented in https://wiki.debian.org/gitlab -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#975219: [Debichem-devel] Bug#975219: elkcode: FTBFS: internal compiler error: in lookup_field_for_decl, at tree-nested.c:288
* Lucas Nussbaum: > Hi Michael, > > On 22/11/20 at 15:32 +0100, Michael Banck wrote: >> Hi Lucas, >> >> That looks like an ICE, shouldn't that be filed with gfortran? > > Usually my logic is: if there's only one similar failure, I file a bug > against the affected package, rather than against the toolchain package > or the library, because it might be something very strange with the > package that is causing the toolchain to misbehave. ICEs are still consider GCC bugs (by upstream, maybe not by Debian), as long as they are reproducible and not the result of faulty hardware.
Bug#975495: ITP: gping -- Ping, but with a graph.
Package: wnpp Severity: wishlist Owner: nicoo X-Debbugs-Cc: debian-de...@lists.debian.org, Debian Rust Maintainers -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: gping Version : 0.1.7 Upstream Author : Tom Forbes * URL : https://github.com/orf/gping * License : MIT Programming Lang: Rust Description : Ping, but with a graph. Continuously runs a ping against a specified host, plotting a latency chart in the terminal in realtime. -BEGIN PGP SIGNATURE- iQJFBAEBCgAvFiEEU7EqA8ZVHYoLJhPE5vmO4pLV7MsFAl+63x8RHG5pY29vQGRl Ymlhbi5vcmcACgkQ5vmO4pLV7Msikg/+JCYTd9HTHJqMQvQPrLEr2RaWLKW8uWym Ksnv3ZMhFsU6Q5bDK5ISsvJWkjr7pNpTsiBnnX+wUm+d3+0jmPbifKPMAY/bdJ72 nfsdm4HWBoZ/EyYdGVB1g839W8QFRJ19EuXACVlpsaTeaUnMwnYiJhezHXkLL99e ySgrpHkAHWjbclEW3QPA18fvj3I3vqss5ftSCnd576cYpnm0+GK2xymOn3v+4Op0 PpU2g5yZCSlDOF6RLQ+VfOdL0LaeCPaYQRe544Uw6Y8Ax7qvqzSgfrE2lFjgoiFv 3ROwvWZU4jfs6kEW5gNd1Cjmhb9N+FAzzQduQA2hPYa/IQG4nhnGeks6xmyWOCvC 9pw4MJmqC/g3jPdS3+673HPF72dhEqHRFFq982AeUI0oSKIvA4Ie2dQt/k22zqej 5gCeR/0zAaREul4J+r3J73c4pFobsDecJcdNTlMLzvZ2DcG/hogDdWWqB8uY8nXF 8qqkj1c9DmLqmm8GR+MGvieK2dvABOdUoDjjeMQxZXvaZobBfNtBuZ1ka5PUTOud pQkSaE9rFItdI9Q3SG7Ia8TyZt/0WZER2Dy9cg+IrIhtGk85GK8el3qPiM6am/iQ ZDwCCYr5nmUmdlwxuiacQ0mTb/HryJj8Gs4lJT2vpUiaWlzmXr3BDPU90Af9OwFR f4v38/lr9lc= =pLbK -END PGP SIGNATURE-
Bug#975481: Use libmariadb-dev instead of legacy libmariadbclient-dev
> How is this a normal bug? Please a bit more care when reporting bugs. > > Either it's a wish or libmariadbclient-dev is supposed to be removed > soonish at which it would be at least important. The package libmariadbclient-dev will be removed from Debian at some point but I don't know the schedule yet. .. > is not used as it's inside an ifeq "$(MYSQL_FLAVOUR)" "mariadb" > and MYSQL_FLAVOUR is set to default in rules (aka use > default-libmysqlclient-dev). Ok, then I guess LibreOffice in Debian is not affected directly. .. > So you want me to change > libmariadbclient-dev-compat to libmariadb-dev-compat? Can do that, but as > said there won't be any real effect here :) Yes. It does not hurt either, right?
Bug#863326: Upstream links changed
Hi, after prompting from Arch Linux, I've recovered the source code for pngtools from a backup and placed it on github at https://github.com/mikalstill/pngtools. I'd be happy enough to accept patches and bug reports there, and will do my best to service them -- noting that this code is nearly 20 years old. I'm not sure what the correct Debian process is for such things, so I am just replying to this bug. Cheers, Michael
Bug#975494: vdirsyncer: broken with python 3.9
Package: vdirsyncer Version: 0.16.7-2 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 vdirsyncer worked fine until yesterday, today it failed. What has changed? python 3.8 -> python 3.9. % python3.8 /usr/bin/vdirsyncer sync && echo $? Syncing / Syncing / 0 % python3.9 /usr/bin/vdirsyncer sync && echo $? Syncing / Syncing / error: Unknown error occured for /: 'xml.etree.ElementTree.Element' object has no attribute 'getiterator' error: Use `-vdebug` to see the full traceback. error: Unknown error occured for /: 'xml.etree.ElementTree.Element' object has no attribute 'getiterator' error: Use `-vdebug` to see the full traceback. error: 2 out of 4 tasks failed. With -vdebug I see lot's of xml, and then at the end: debug: debug: /gregoa/home/22289030-6ADE-4142-811B-D5D4FCA55F29.ics debug: debug: debug: debug: text/calendar; component=vevent debug: "19f650ff8e93d96b195b4b7310c84d40" debug: debug:HTTP/1.1 200 OK debug: debug: debug: debug: Already normalized: '' error: Unknown error occured for /: 'xml.etree.ElementTree.Element' object has no attribute 'getiterator' error: Use `-vdebug` to see the full traceback. debug: File "/usr/lib/python3/dist-packages/vdirsyncer/cli/tasks.py", line 64, in sync_collection debug: sync.sync( debug: File "/usr/lib/python3/dist-packages/vdirsyncer/sync/__init__.py", line 136, in sync debug: b_nonempty = b_info.prepare_new_status() debug: File "/usr/lib/python3/dist-packages/vdirsyncer/sync/__init__.py", line 45, in prepare_new_status debug: for href, etag in self.storage.list(): debug: File "/usr/lib/python3/dist-packages/vdirsyncer/storage/dav.py", line 795, in list debug: for x in DAVStorage.list(self): debug: File "/usr/lib/python3/dist-packages/vdirsyncer/storage/dav.py", line 637, in list debug: for href, etag, _prop in rv: debug: File "/usr/lib/python3/dist-packages/vdirsyncer/storage/dav.py", line 593, in _parse_prop_responses debug: props = _merge_xml(props) debug: File "/usr/lib/python3/dist-packages/vdirsyncer/storage/dav.py", line 125, in _merge_xml debug: rv.extend(item.getiterator()) error: 2 out of 4 tasks failed. Cheers, gregor - -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'unstable-debug'), (500, 'oldoldstable'), (500, 'experimental'), (500, 'testing'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-1-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=de_AT.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/bash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages vdirsyncer depends on: ii python33.9.0-3 ii python3-atomicwrites 1.4.0-1 ii python3-click 7.1.2-1 ii python3-click-log 0.2.1-2 ii python3-click-threading0.4.4-2 ii python3-requests 2.24.0+dfsg-1 ii python3-requests-toolbelt 0.8.0-1.1 vdirsyncer recommends no packages. Versions of packages vdirsyncer suggests: pn python3-requests-oauthlib pn vdirsyncer-doc - -- no debconf information -BEGIN PGP SIGNATURE- iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAl+61iZfFIAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ qgbYYA/5ATiLs2LGF4CYE22iLqW7e7Ct45ZuuslWt6H87PiHLF4blNsGcZ4eDINg 3aaGrBYaaLJToY1xwaMeu4ak1TXhFoTq842/7hPHtkBmaqCFfuqg2AzPqle/qFBu ordDxf4EFRIp+xqYdhwhOU/J4BPx4+ADRlpGwUZpxassrQG6Szaa02oEW9cqs1c1 iPNgWZmBPDnUpYFUv7cKAZBHhVBYCgphcGSl+/t6I7GGHiBLALIDYMyW8mw2UmyL muh5CIk6ZeKonfn1ViWYZgObU3fjZu6a+GO5QWY6OX6Jw2LYm1MXgSnOXyVifhdL vjGKj9Bhm9tBSs4/3AT2ns5Amx8yrIA5Mp7FMQDfX/hQit49BFbXB8Z3WTnSK66m y2LPu0pJGgNTaXKrkI7ImFqgMneTE3UwezZqkGxZ9Dc/GOIFnQlJy9l3N5Lv03Tt OtbRP/08OYBSgAgSDUQZ6+Pzdip291+1zcAeMGJNtNd8G5zJfQtGrWan8t0jW9xl G0iR+D3f4ZFutEwPNgNbFuv/4zVmUZV5ys3TG2QMn046QXuklO+Z+daO2W75vF91 XZ1As6qHgtBEgUM46lYk1VV73iL/pBl3T1z9rUuOBck4/7oIojHBUKlj1RNCuIYK R/9p928ygegP/B6k1KdKHurur02x/WB/bLqm3g4ubNarP0yrgWA= =wqvb -END PGP SIGNATURE-
Bug#912975: xen-hypervisor-4.8-amd64: Dom0 crashes randomly without logs on Debian Stretch with Xen 4.8.4
Hi, This bug was reported against Xen 4.8 (which is out of support and out of security support now) and there has not been any activity for over almost two years. I'm cleaning up old open bugs, and I will close the issue now. If you found a solution to this problem, please let us know, so the information is added in the bug report for anyone else who might run into the same situation. If the problem still persists with Xen 4.11 in Debian stable, please reply and reopen. Thanks, Hans
Bug#934786: xen-system-amd64: xen host crashes when calling "npm run build" in a vm (reproducible)
Hi Mario, On 8/14/19 11:00 PM, mario wrote: > Package: xen-system-amd64 > Version: 4.8.5+shim4.10.2+xsa282-1+deb9u11 > Severity: important > > hello everyone, > > we have a vm with kernel 4.9.0-5-amd64 running dabian oldstable > if we run an "npm run build" on one of the virtual machines, the whole > xen-host system will restart (reset) > there is no message, neither in the kernel nor in the syslog. > > if we update the kernel of the virtual machine to 4.9.0-9-amd64, the problem > is no longer there and the build runs without errors. > > the kernel of the hosts system doesn't matter, even the latest 4.9.0-9-amd64 > doesn't help. > > we have a second server (with different hardware) also here i can crash the > complete xen-server from the vm with all vms that are running. > > the whole thing works reproducible by starting "npm run build" on this > special vm > > any idea how we can narrow that down and provide more information??? Interesting. Do you know if it's Xen crashing, or the dom0 Linux kernel? The Xen wiki has some hints about debugging: https://wiki.xen.org/wiki/Debugging_Xen The first thing I would recommend is getting the server serial port working properly so that you can see Xen messages there. This bug was reported against Xen 4.8 (which is out of support and out of security support now). I would highly recommend to first upgrade to Xen 4.11 in current Debian stable and see if you can still reproduce this problem. If you no longer have this problem, or found a solution, please let know. If there's no activity, I will close this issue in about a month. Thanks, Hans
Bug#973701: network-manager: systemctl restart ModemManager.service wipes /etc/resolve.conf (almost) clean
On Sun, 22 Nov 2020, Matteo F. Vescovi wrote: > On 2020-11-04 at 21:09 (+01), Cristian Ionescu-Idbohrn wrote: > > [...] > > > IMO, my remarks and comments are all _but_ snide and stupid. The > > problem here, as I see it, is this maintainer's _arrogant_ attitude. > > Michael, sorry to say, but Cristian is right: > > I see no snide and stupid comments to the bug report and I'm > actually affected by this weird behaviour since a week or so, I must > admit. Yes, I'm not alone. I noticed this odd behaviour months ago but did not report it, as I expected that kind of _arrogant_ reaction. > I'm still digging in to find the culprit (possibly, a particular > version of NM or MM that introduced the issue) For me, it does not appear ModemManager has anything to do with this, but I can't rule that out. > but I need some more tests with alternative setups to fully > understand the situation (seems like systems with both Wi-Fi and > WWAN are affected). I can reproduce this in another way too. My laptop has both a wifi and a wired chip. When I stick in the cable, the same problem occurs: I loose the DNS configuration in /etc/resolv.conf. I can add that manually, but that should _not_ be expected. Another peculiar behaviour is that if I poweroff connected to the wifi and startup wired connected, I end up having to disconnect the cable and connect it back again to be able to get things (sort of) working again. In both cases (wired/wireless) I rely on the router's DHCP to provide the proper DNS configuration. That may need another bug report, if anyone else is able to reproduce. Cheers, -- Cristian
Bug#975481: Use libmariadb-dev instead of legacy libmariadbclient-dev
severity 975481 wishlist tag 975481 + moreinfo thanks Am 22.11.20 um 19:15 schrieb Otto Kekäläinen: > Package: libreoffice How is this a normal bug? Please a bit more care when reporting bugs. Either it's a wish or libmariadbclient-dev is supposed to be removed soonish at which it would be at least important. > I noticed the source package has references to libmariadbclient-dev: > https://salsa.debian.org/search?search=libmariadbclient-dev&project_id=1012&group_id=2250 changelog is of a total obsolete version. Note the "bump build-dependency on icu to >= 52 (see" and opencollada which isn't a thing anymore even in buster. The first rules part ifneq (,$(filter mariadb, $(SYSTEM_STUFF))) # deducted from default-libmysqlclient-dev Depends BUILD_DEPS += , libmariadbclient-dev-compat endif MARIADBCONFIG=/usr/bin/mariadb_config is not used as it's inside an ifeq "$(MYSQL_FLAVOUR)" "mariadb" and MYSQL_FLAVOUR is set to default in rules (aka use default-libmysqlclient-dev). The second rules part ifeq "$(MYSQL_FLAVOUR)" "mysql" perl -pi -e "s/(Build-Conflicts: .*)/\1,libmariadbclient-dev,/" debian/control endif ifneq (nocheck,$(findstring nocheck,$(DEB_BUILD_OPTIONS))) is (as you see in the snippet) only used with MYSQL_FLAVOUR=mysql (which won't ever be set, will only bet set ever if it's "real" MySQL to be used) Don't just grep for stuff but check what packages actually do. > This is a deprecated package and you should instead use > libmariadb-dev[1] or libmariadb-dev-compat if you need to build > something old that does not find the correct soname otherwise. Now to the real part. So you want me to change libmariadbclient-dev-compat to libmariadb-dev-compat? Can do that, but as said there won't be any real effect here :) Or do you also want to change the (effective) default-libmysqlclient-dev build-dep, too? That should probably also work? The resulting libreoffice-sdbc-mysql at least ends up with a dependency on libmariadb3 anyway. Note LO used mysql_config so needs to compat thingies.[1] Regards, Rene
Bug#975446: libzeep: FTBFS against boost_1.74
Hi Marteen, there are really some misunderstandings with version numbers. Anyway, I have just tried to build 5.0.2-3 and it still fails to build: mkdir -p obj cd doc; /usr/bin/bjam /bin/bash /root/mod2/libzeep-5.0.2/libtool --silent --tag=CXX --mode=compile g++ -std=c++17 -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -fdebug-prefix-map=/root/mod2/libzeep-5.0.2=. -fstack-protector-strong -Wformat -Werror=format-security -pthread -I/usr/include -Wall -Wno-multichar -I include -O3 -DNDEBUG -MT obj/connection.lo -MD -MP -MF obj/connection.d -c -o obj/connection.lo lib-http/src/connection.cpp /bin/bash /root/mod2/libzeep-5.0.2/libtool --silent --tag=CXX --mode=compile g++ -std=c++17 -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -fdebug-prefix-map=/root/mod2/libzeep-5.0.2=. -fstack-protector-strong -Wformat -Werror=format-security -pthread -I/usr/include -Wall -Wno-multichar -I include -O3 -DNDEBUG -MT obj/controller.lo -MD -MP -MF obj/controller.d -c -o obj/controller.lo lib-http/src/controller.cpp /bin/bash /root/mod2/libzeep-5.0.2/libtool --silent --tag=CXX --mode=compile g++ -std=c++17 -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -fdebug-prefix-map=/root/mod2/libzeep-5.0.2=. -fstack-protector-strong -Wformat -Werror=format-security -pthread -I/usr/include -Wall -Wno-multichar -I include -O3 -DNDEBUG -MT obj/controller-rsrc.lo -MD -MP -MF obj/controller-rsrc.d -c -o obj/controller-rsrc.lo lib-http/src/controller-rsrc.cpp Unable to load B2: could not find 'boost-build.jam' --- Attempted search from '/root/mod2/libzeep-5.0.2/doc' up to the root at '/usr/bin/b2' Please consult the documentation at 'https://boostorg.github.io/build/'. Could you please have a look? Thanks Anton Am So., 22. Nov. 2020 um 21:22 Uhr schrieb Maarten L. Hekkelman : > > Hi, > > The bug report is for libzeep version 5, but the logs show that an attempt > was made to compile version 3. I'm quite sure that building libzeep version 5 > with boost 1.74 will succeed, since I've been using it myself for several > weeks now. > > regards, -maarten > > Op 22-11-2020 om 13:28 schreef Anton Gladky: > > Package: libzeep > Version: 5.0.2-3 > Severity: important > Tags: ftbfs > User: team+bo...@tracker.debian.org > Usertags: boost174 > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Dear maintainer, > > it was discovered that your package failed to build > against boost_1.74. Logs can be found here [1]. Most relevant > part is probably this: > > dpkg-source: info: using options from libzeep-3.0.5/debian/source/options: > --extend-diff-ignore=(^|/)(.vscode/.*|msvc|\.gitignore|\.travis\.yml|tests|zeep-test.*|webapp-test.cpp|doc/bin)$ > fakeroot debian/rules clean > dh clean >dh_auto_clean > make -j4 clean > make[1]: Entering directory '/<>' > rm -rf obj/* libzeep.a libzeep.so* zeep-test libzeep-3.0.5 libzeep-3.0.5.tgz > cd doc; bjam clean > Unable to load B2: could not find 'boost-build.jam' > - --- > Attempted search from '/<>/doc' up to the root at '/usr/bin/b2' > Please consult the documentation at 'https://boostorg.github.io/build/'. > > make[1]: *** [makefile:122: clean] Error 1 > make[1]: Leaving directory '/<>' > dh_auto_clean: error: make -j4 clean returned exit code 2 > make: *** [debian/rules:8: clean] Error 25 > > > > It is planned to push boost_1.74 as the default version in Debian/Bullseye. > > [1] > http://qa-logs.debian.net/2020/10/27-boost/boost/libzeep_3.0.5-2_unstable_boost.log > > Best regards > > Anton > > - -- System Information: > Debian Release: bullseye/sid > APT prefers testing > APT policy: (500, 'testing') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 5.9.0-1-amd64 (SMP w/8 CPU threads) > Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not > set > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > -BEGIN PGP SIGNATURE- > > iQJFBAEBCgAvFiEEu71F6oGKuG/2fnKF0+Fzg8+n/wYFAl+6WXURHGdsYWRrQGRl > Ymlhbi5vcmcACgkQ0+Fzg8+n/wYXFQ/6AobGTBmLGOayKBafvfY7JKMuOvQUt/CN > 3x0Q1q9JKT3PrAiDupOILvGpU7kLVwXm+Xj7Y6jmOFmQXAIiejQINB5S3SMm3OW/ > GJb2MkcbeAr/1gKnoRiXWGauFjBXT+RfHwKCB0qCRxaCcgd6wqN/sur9LiK1o9Jb > yAxYOhsAuqU3zrmGbJ6H9WGzRsOAFjhWRDu9vvq9+XWwhCZ1msETk8J+ube6dI3G > uYpkUgEUxf6dSLYAFki2vKtSX6TonmFwJ9Zn3uMer1OlTwOPGFfeKFP+Hvgd+Fx5 > lwbGAh6RkoxM+9a+q+MSnIyhVoqMSYKWGbazen1SbJiQSR2tf8INYpryjd9wTYbK > aFlazYitywFTlq4I9cu+vDuHzLP6/rV480+v6ZRKgNLO8ciNu3i/vB/a8G23cdAu > Bite4zw/29R5ekDUIvZcLLUSTVYfArKd1gMeRbVQFx9Y/AcFBC1/eZwqeiQFKmZv > c1PwFhB9bl54jDqS/mb7c85uhzt2LEbEeLrzo69TaUxjo1/1vQCvZa2FMn5uZgBF > aQwH4QSlL8Qh1zd3DW6DpQUzC4hg9TWFH/xIulFfuS46i2vD6UUDZYO/lBsw9Bod > a5Sgqn6aeKSZs2StgSOf8HFF067rSOYbC3oaDO9/7xBmNe8FHjYLV27mFr6+Sotu > OObqY7WdDP4= > =ljID > -END PGP SIGNATURE- > > > > -- > Maarten L. Hekkelman > http://www.hekkelman.
Bug#911428: New Customer Request...
- This mail is in HTML. Some elements may be ommited in plain text. - Hello, Kindly confirm if you can ship to Australia and New Zealand. Thanks CEO Dr Henrik Rawlings © 2020 Henrik Group Ltd. All Rights Reserved. sent from my iPad
Bug#975493: gitlab: Gitlab install script not working
Package: gitlab Version: 13.3.9-1+fto10+1 Severity: important Hi, Gitlab are not installing. I doesn't know the reason, but when I try to install it through apt-get upgrade (following debian/gitlab page for upgrading), that's not working. The log are the following: Precompiling assets... fatal: not a git repository (or any of the parent directories): .git fatal: not a git repository (or any of the parent directories): .git Attention: used pure ruby version of MurmurHash3 /usr/share/gitlab/lib/gitlab.rb:38: warning: already initialized constant Gitlab::COM_URL /usr/share/gitlab/lib/gitlab.rb:38: warning: previous definition of COM_URL was here /usr/share/gitlab/lib/gitlab.rb:39: warning: already initialized constant Gitlab::STAGING_COM_URL /usr/share/gitlab/lib/gitlab.rb:39: warning: previous definition of STAGING_COM_URL was here /usr/share/gitlab/lib/gitlab.rb:40: warning: already initialized constant Gitlab::APP_DIRS_PATTERN /usr/share/gitlab/lib/gitlab.rb:40: warning: previous definition of APP_DIRS_PATTERN was here /usr/share/gitlab/lib/gitlab.rb:41: warning: already initialized constant Gitlab::SUBDOMAIN_REGEX /usr/share/gitlab/lib/gitlab.rb:41: warning: previous definition of SUBDOMAIN_REGEX was here /usr/share/gitlab/lib/gitlab.rb:42: warning: already initialized constant Gitlab::VERSION /usr/share/gitlab/lib/gitlab.rb:42: warning: previous definition of VERSION was here /usr/share/gitlab/lib/gitlab.rb:43: warning: already initialized constant Gitlab::INSTALLATION_TYPE /usr/share/gitlab/lib/gitlab.rb:43: warning: previous definition of INSTALLATION_TYPE was here /usr/share/gitlab/lib/gitlab.rb:44: warning: already initialized constant Gitlab::HTTP_PROXY_ENV_VARS /usr/share/gitlab/lib/gitlab.rb:44: warning: previous definition of HTTP_PROXY_ENV_VARS was here yarn install v1.22.4 [1/4] Resolving packages... success Already up-to-date. $ node ./scripts/frontend/postinstall.js success Dependency postinstall check passed. Done in 0.74s. WARNING on line 297, column 11 of /usr/share/gitlab/app/assets/stylesheets/framework/common.scss: Compound selectors may no longer be extended. Consider `@extend .card, .card-body` instead. See http://bit.ly/ExtendCompound for details. WARNING on line 208, column 13 of /usr/share/gitlab/app/assets/stylesheets/framework/filters.scss: Compound selectors may no longer be extended. Consider `@extend .form-control, :hover` instead. See http://bit.ly/ExtendCompound for details. DEPRECATION WARNING on line 88 of /usr/share/gitlab/app/assets/stylesheets/framework/gitlab_theme.scss: The operation `#292961 plus 33` is deprecated and will be an error in future versions. Consider using Sass's color functions instead. https://sass-lang.com/documentation/Sass/Script/Functions.html#other_color_functions DEPRECATION WARNING on line 88 of /usr/share/gitlab/app/assets/stylesheets/framework/gitlab_theme.scss: The operation `#4b4ba3 plus 33` is deprecated and will be an error in future versions. Consider using Sass's color functions instead. https://sass-lang.com/documentation/Sass/Script/Functions.html#other_color_functions DEPRECATION WARNING on line 88 of /usr/share/gitlab/app/assets/stylesheets/framework/gitlab_theme.scss: The operation `#1a3652 plus 33` is deprecated and will be an error in future versions. Consider using Sass's color functions instead. https://sass-lang.com/documentation/Sass/Script/Functions.html#other_color_functions DEPRECATION WARNING on line 88 of /usr/share/gitlab/app/assets/stylesheets/framework/gitlab_theme.scss: The operation `#2261a1 plus 33` is deprecated and will be an error in future versions. Consider using Sass's color functions instead. https://sass-lang.com/documentation/Sass/Script/Functions.html#other_color_functions DEPRECATION WARNING on line 88 of /usr/share/gitlab/app/assets/stylesheets/framework/gitlab_theme.scss: The operation `#0d4524 plus 33` is deprecated and will be an error in future versions. Consider using Sass's color functions instead. https://sass-lang.com/documentation/Sass/Script/Functions.html#other_color_functions DEPRECATION WARNING on line 88 of /usr/share/gitlab/app/assets/stylesheets/framework/gitlab_theme.scss: The operation `#156b39 plus 33` is deprecated and will be an error in future versions. Consider using Sass's color functions instead. https://sass-lang.com/documentation/Sass/Script/Functions.html#other_color_functions DEPRECATION WARNING on line 88 of /usr/share/gitlab/app/assets/stylesheets/framework/gitlab_theme.scss: The operation `#691a16 plus 33` is deprecated and will be an error in future versions. Consider using Sass's color functions instead. https://sass-lang.com/documentation/Sass/Script/Functions.html#other_color_functions DEPRECATION WARNING on line 88 of /usr/share/gitlab/app/assets/stylesheets/framework/gitlab_theme.scss: The operation `#a62e21 plus 33` is deprecated and will be an error in future versions. Consider using Sass's color functions instead. htt
Bug#975492: scummvm: FTBFS on big-endian platforms
Package: scummvm Version: 2.2.0+dfsg1-1 Severity: serious Tags: upstream Justification: ftbfs Dear Maintainer, On big-endian platforms, test/engines/ultima/ultima8/misc/memset_n.h fails because the memset_n functions assume they're running on a little-endian platform. On a big-endian platform, the value written to memory will depend on the alignment: if the value is aligned, it will be written as expected (MSB first), but if it's not aligned, it will be written in a mixture of little- and big-endian. The tests always use the host memory order. Regards, Stephen -- System Information: Debian Release: 10.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 'stable'), (100, 'unstable-debug'), (100, 'testing-debug'), (100, 'unstable'), (100, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 4.19.0-12-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages scummvm depends on: ii libasound2 1.1.8-1 ii libc62.28-10 ii libfaad2 2.8.8-3 ii libflac8 1.3.2-3 ii libfluidsynth1 1.1.11-1 ii libfreetype6 2.9.1-3+deb10u2 ii libgcc1 1:8.3.0-6 ii libjpeg62-turbo 1:1.5.2-2+b1 ii libmad0 0.15.1b-10 ii libmpeg2-4 0.5.1-8 ii libogg0 1.3.2-1+b1 ii libpng16-16 1.6.36-6 ii libsdl2-2.0-02.0.9+dfsg1-1 ii libsndio7.0 1.5.0-3 ii libstdc++6 8.3.0-6 ii libtheora0 1.1.1+dfsg.1-15 ii libvorbis0a 1.3.6-2 ii libvorbisfile3 1.3.6-2 ii scummvm-data 2.0.0+dfsg-2 ii zlib1g 1:1.2.11.dfsg-1 scummvm recommends no packages. Versions of packages scummvm suggests: ii beneath-a-steel-sky 0.0372-7 ii drascula1.0+ds3-1 ii flight-of-the-amazon-queen 1.0.0-8 ii fluidsynth 1.1.11-1 ii lure-of-the-temptress 1.1+ds2-3 ii timidity2.14.0-8 -- no debconf information
Bug#968518: clevis: "clevis decrypt" does not work in initrd
Control: tags 968518 confirmed pending Nicolas Bourdaud wrote... > This is of course not a proper fix. I think the fix should be done > either in initramfs-tools init-* scripts either in systemd/udev itself. > In my case, I can say for sure the clevis-decrypt worked in July. I > don't know which package update has broken the symlink for the clevis > initramfs script. Folks, thanks for the patience, also for the in-depth analysis. I'm fairly certain this is yet another fallout from changes done in systemd, see https://bugs.debian.org/967546 for some details and flames. So this needs to be changed in clevis - I'll check whether the proposed changes will do the trick, then do an upload, upstream is already at 15. Christoph signature.asc Description: PGP signature
Bug#975491: mozc: New upstream release available: 2.26
Source: mozc Version: 2.23.2815.102+dfsg-10 Severity: wishlist Dear Maintainer, The upstream repository has recently become active again, according to https://github.com/google/mozc/commits/master the lastest release is 2.26, it would be nice to upgrade the Debian package to that release. It's not clear exactly what changed compared to the release currently i Debian since there was a huge code dump in https://github.com/google/mozc/commit/a1dcadabd3a1c604e8beff1e45830c1d9adfce84 Thank you, Guillaume -- System Information: Debian Release: bullseye/sid APT prefers groovy-updates APT policy: (500, 'groovy-updates'), (500, 'groovy-security'), (500, 'groovy'), (100, 'groovy-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.8.0-29-generic (SMP w/16 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#973701: network-manager: systemctl restart ModemManager.service wipes /etc/resolve.conf (almost) clean
Hi! On 2020-11-04 at 21:09 (+01), Cristian Ionescu-Idbohrn wrote: [...] > IMO, my remarks and comments are all _but_ snide and stupid. The > problem here, as I see it, is this maintainer's _arrogant_ attitude. Michael, sorry to say, but Cristian is right: I see no snide and stupid comments to the bug report and I'm actually affected by this weird behaviour since a week or so, I must admit. I'm still digging in to find the culprit (possibly, a particular version of NM or MM that introduced the issue) but I need some more tests with alternative setups to fully understand the situation (seems like systems with both Wi-Fi and WWAN are affected). I'm gonna let you know my findings in the real hope to fix the problem as soon as possible, as it's quite annoying. Cheers. -- Matteo F. Vescovi || Debian Developer GnuPG KeyID: 4096R/0x8062398983B2CF7A signature.asc Description: PGP signature
Bug#918917: Please add Firefox to the favorites
Op 22-11-2020 om 17:53 schreef Fabio Fantoni: And really, there is no Firefox in the favorites, so there is something wrong. Maybe the problem is that it's "firefox-esr" and not "firefox" ? Is correct, it set firefox.desktop, firefox-esr have firefox-esr.desktop instead. @Norbert @Maxy: what do you think is the better do? I think would be good have default favorite working in both debian stable/testing (with only firefox-esr) and ubuntu and derivates (with only firefox) Maybe it's an idea to add them both? There is no firefox-esr in Ubuntu, so I guess it will show no icon like now in Debian. With regards, Paul van der Vlis -- Paul van der Vlis Linux systeembeheer Groningen https://www.vandervlis.nl/
Bug#918917: Please add Firefox to the favorites
Op 22-11-2020 om 17:53 schreef Fabio Fantoni: cinnamon-desktop-environment actually have gnome-terminal as default Hmm, you are right. But the menu does not show it. Maybe because of: OnlyShowIn=GNOME;Unity; in /usr/share/applications/org.gnome.Terminal.desktop So maybe better to use another terminal? you can install any of the 22 terminal that provide xfce4-terminal (and remove gnome-terminal if already instealled) without broke/remove cinnamon-desktop-environment metapackage if you want I need a good terminal to do that ;-) With regards, Paul -- Paul van der Vlis Linux systeembeheer Groningen https://www.vandervlis.nl/
Bug#966693: veloren installer
On the assumption that it's easier to package, perhaps consider getting airshipper into contrib. I don't think it's worth its own RFP at this point though: * Package name: airshipper Version : 0.4.0 * URL : https://github.com/Songtronix/Airshipper signature.asc Description: PGP signature
Bug#975490: u-boot-sunxi: Booting the system got stuck after "Starting kernel ..."
Package: u-boot-sunxi Severity: critical Dear Maintainer, after a fresh install of Debian "bullseye" the first reboot got stuck after "Starting kernel ..." It turend out that booting the system got always stuck using the a "normal" u-boot boot sequence. Using extlinux or FIT-Images is not affected. boot.scr : FAIL extlinux : OK FIT-Image: OK Since the Debian Installer provides neither extlinux configuration nor build a FIT-Image the system is unusable after the reboot from the installer. I got into the same situation during an update on an other system to bullseye. Bootlog: ---8<--- U-Boot SPL 2020.10+dfsg-1+b1 (Nov 19 2020 - 03:18:11 +) DRAM: 1024 MiB Trying to boot from MMC2 NOTICE: BL31: v2.3(): NOTICE: BL31: Built : 05:17:48, Oct 18 2020 NOTICE: BL31: Detected Allwinner A64/H64/R18 SoC (1689) NOTICE: BL31: Found U-Boot DTB at 0x4093968, model: Olimex A64-Olinuxino-eMMC INFO:ARM GICv2 driver initialized INFO:Configuring SPC Controller INFO:PMIC: Probing AXP803 on RSB INFO:PMIC: Enabling DRIVEVBUS INFO:PMIC: dcdc1 voltage: 3.300V INFO:PMIC: dcdc5 voltage: 1.360V INFO:PMIC: dcdc6 voltage: 1.100V INFO:PMIC: dldo1 voltage: 3.300V INFO:PMIC: dldo2 voltage: 3.300V INFO:PMIC: dldo3 voltage: 2.800V INFO:PMIC: dldo4 voltage: 3.300V INFO:PMIC: fldo1 voltage: 1.200V INFO:PMIC: Enabling DC SW INFO:BL31: Platform setup done INFO:BL31: Initializing runtime services INFO:BL31: cortex_a53: CPU workaround for 843419 was applied INFO:BL31: cortex_a53: CPU workaround for 855873 was applied NOTICE: PSCI: System suspend is unavailable INFO:BL31: Preparing for EL3 exit to normal world INFO:Entry point address = 0x4a00 INFO:SPSR = 0x3c9 alloc space exhausted U-Boot 2020.10+dfsg-1+b1 (Nov 19 2020 - 03:18:11 +) Allwinner Technology CPU: Allwinner A64 (SUN50I) Model: Olimex A64-Olinuxino-eMMC DRAM: 1 GiB MMC: mmc@1c0f000: 0, mmc@1c1: 2, mmc@1c11000: 1 Loading Environment from FAT... Unable to use mmc 1:1... In:serial Out: serial Err: serial Net: phy interface7 eth0: ethernet@1c3 starting USB... Bus usb@1c1a000: USB EHCI 1.00 Bus usb@1c1a400: USB OHCI 1.0 Bus usb@1c1b000: USB EHCI 1.00 Bus usb@1c1b400: USB OHCI 1.0 scanning bus usb@1c1a000 for devices... 1 USB Device(s) found scanning bus usb@1c1a400 for devices... 1 USB Device(s) found scanning bus usb@1c1b000 for devices... 1 USB Device(s) found scanning bus usb@1c1b400 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc1(part 0) is current device Scanning mmc 1:1... Found U-Boot script /boot.scr 2225 bytes read in 2 ms (1.1 MiB/s) ## Executing script at 4fc0 22744944 bytes read in 1003 ms (21.6 MiB/s) 28403 bytes read in 5 ms (5.4 MiB/s) 30071341 bytes read in 1326 ms (21.6 MiB/s) Booting Debian 5.9.0-2-arm64 from mmc 1:1... Moving Image from 0x4008 to 0x4020, end=4185 ## Flattened Device Tree blob at 4fa0 Booting using the fdt blob at 0x4fa0 EHCI failed to shut down host controller. Loading Ramdisk to 48352000, end 49fffa2d ... OK Loading Device Tree to 48348000, end 48351ef2 ... OK Starting kernel ... ---8<--- Regards Benedikt Spranger
Bug#975460: fontforge: FTBFS on i386 [patch]
BTW the macro was DEB_HOST_MULTIARCH, as you already know
G.
On Sun, 22 Nov 2020 19:47:34 +0100 Gianfranco Costamagna
wrote:
> looks like fixed already in git:
> https://salsa.debian.org/fonts-team/fontforge/commit/c52b395bda57c305
>
> Closing.
>
> G.
>
> On Sun, 22 Nov 2020 16:23:54 +0100 Gianfranco Costamagna
> wrote:
> > Source: fontforge
> > Version: 1:20201107~dfsg-1
> > Severity: serious
> > tags: patch
> >
> >
> > Hello, to fix the build failure I think debian/libfontforge4.install should
> > contain this line:
> > usr/lib/${DEB_BUILD_MULTIARCH}
> >
> > Full patch:
> >
> > --- fontforge-20201107~dfsg/debian/changelog2020-11-18
> > 09:42:18.0 +0100
> > +++ fontforge-20201107~dfsg/debian/changelog2020-11-22
> > 15:24:41.0 +0100
> > @@ -1,3 +1,9 @@
> > +fontforge (1:20201107~dfsg-1.1) UNRELEASED; urgency=medium
> > +
> > + * Fix i386 build (Closes: #-1)
> > +
> > + -- Gianfranco Costamagna Sun, 22 Nov 2020
> > 15:24:41 +0100
> > +
> > fontforge (1:20201107~dfsg-1) unstable; urgency=medium
> >
> >[ Jonas Smedegaard ]
> > diff -Nru fontforge-20201107~dfsg/debian/libfontforge4.install
> > fontforge-20201107~dfsg/debian/libfontforge4.install
> > --- fontforge-20201107~dfsg/debian/libfontforge4.install2020-11-17
> > 10:15:18.0 +0100
> > +++ fontforge-20201107~dfsg/debian/libfontforge4.install2020-11-22
> > 15:24:40.0 +0100
> > @@ -1 +1 @@
> > -usr/lib/${DEB_HOST_GNU_TYPE}
> > +usr/lib/${DEB_BUILD_MULTIARCH}
> >
> >
>
>
Bug#835596: [debian-mysql] Bug#835596: Bug#835596: [mariadb-10.0] Please ship support-files/mysqld_multi.server.sh
Hi, Am 22.11.20 um 17:22 schrieb Otto Kekäläinen: > And if you find out there are no code changes needed, maybe submit an > addition to the README's so the next users have an easier time > figuring out how to properly run multi-instnances? sorry, I'm not using this szenario anymore. So I don't have any system to test. Sorry, Jan.
Bug#972149: buster-pu: package net-snmp/5.7.3+dfsg-5+deb10u1
Control: tags -1 + confirmed On Tue, 2020-10-13 at 21:30 +1100, Craig Small wrote: > The security release in deb10u1 made EXTEND-MIB read-only > to close a security hole (CVE-2020-15862/Bug #9651166) > However this meant the cacheTime and execType could not be > changed which caused problems with some SNMP managers or setups. > > [ Impact ] > The cachetime and execType cannot be set anywhere as these > parameters appear in net-snmp 5.8 which is in sid but not > buster. +net-snmp (5.7.3+dfsg-5+deb10u2) buster-security; urgency=high The distribution wants to simply be "buster" for a stable upload. + * snmpd: Add cacheTime and execType flags to EXTEND-MIB. +Previous security release made EXTEND-MIB read-only which meant +it was not possible to set the timeout of the cache. This patch +allows administrator to set the value in the snmpd.conf file. s/administrator/&s/ (or "the administrator", I guess). Bearing the above in mind, please go ahead. Regards, Adam
Bug#975489: Add Aqtion USB to 5Gbe driver (aqc111.ko) to linux-image
Package: linux-image Version: 5.8.0-1amd64 Hello, Driver for Marvel/Aquantia AQtion USB to 5GbE Controller (aqc111) is not included in Debian kernel package. It is included in linux kernel since nov. 2018 (https://github.com/torvalds/linux/blob/v5.9/drivers/net/usb/aqc111.c) Could you please add it to the Debian kernel package (as module aqc111.ko) ? Thanks, Best Regards
Bug#975289: Acknowledgement (systemd: always reporting unit file has "changed on disk" when override.conf is present)
This looks a lot like https://github.com/systemd/systemd/issues/17312 which apparently was fixed by https://github.com/systemd/systemd/pull/16885 Can this PR be applied to the debian systemd package in unstable? Or do I need to wait until 247 is officially released?
Bug#975488: lammps FTBFS: error: format not a string literal and no format arguments
Source: lammps Version: 20200303+dfsg1-3 Severity: serious Tags: ftbfs https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/lammps.html ... /usr/bin/c++ -DFFT_FFTW3 -DFFT_FFTW_THREADS -DLAMMPS_GZIP -DLAMMPS_JPEG -DLAMMPS_MEMALIGN=64 -DLAMMPS_PNG -DLAMMPS_SMALLBIG -DLAMMPS_VTK -DLMP_HAS_NETCDF -DLMP_KIM_CURL -DLMP_MPIIO -DLMP_PYTHON -DLMP_USER_OMP -DNC_64BIT_DATA=0x0020 -DvtkDomainsChemistry_AUTOINIT="1(vtkDomainsChemistryOpenGL2)" -DvtkFiltersCore_AUTOINIT="1(vtkFiltersParallelDIY2)" -DvtkFiltersFlowPaths_AUTOINIT="1(vtkFiltersParallelFlowPaths)" -DvtkIOExodus_AUTOINIT="1(vtkIOParallelExodus)" -DvtkIOGeometry_AUTOINIT="1(vtkIOMPIParallel)" -DvtkIOImage_AUTOINIT="1(vtkIOMPIImage)" -DvtkIOParallel_AUTOINIT="1(vtkIOMPIParallel)" -DvtkIOSQL_AUTOINIT="2(vtkIOMySQL,vtkIOPostgreSQL)" -DvtkRenderingContext2D_AUTOINIT="1(vtkRenderingContextOpenGL2)" -DvtkRenderingCore_AUTOINIT="3(vtkInteractionStyle,vtkRenderingFreeType,vtkRenderingOpenGL2)" -DvtkRenderingFreeType_AUTOINIT="2(vtkRenderingFreeTypeFontConfig,vtkRenderingMatplotlib)" -DvtkRenderingLICOpenGL2_AUTOINIT="1(vtkRenderingParallelLIC)" -DvtkRenderingOpenGL2_AUTOINIT="1(vtkRenderingGL2PSOpenGL2)" -DvtkRenderingVolume_AUTOINIT="1(vtkRenderingVolumeOpenGL2)" -I/build/lammps-20200303+dfsg1/src -I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi -I/usr/lib/x86_64-linux-gnu/openmpi/include -I/usr/include/python3.9 -I/usr/include/voro++ -I/usr/include/eigen3 -I/usr/include/vtk-7.1 -I/usr/include/freetype2 -I/usr/include/python3.8 -I/usr/include/hdf5/openmpi -I/usr/include/jsoncpp -I/usr/include/libxml2 -I/usr/include/tcl -I/usr/include/kim-api -I/usr/lib/x86_64-linux-gnu/kim-api/mod -I/build/lammps-20200303+dfsg1/src/ASPHERE -I/build/lammps-20200303+dfsg1/src/BODY -I/build/lammps-20200303+dfsg1/src/CLASS2 -I/build/lammps-20200303+dfsg1/src/COLLOID -I/build/lammps-20200303+dfsg1/src/COMPRESS -I/build/lammps-20200303+dfsg1/src/CORESHELL -I/build/lammps-20200303+dfsg1/src/DIPOLE -I/build/lammps-20200303+dfsg1/src/GRANULAR -I/build/lammps-20200303+dfsg1/src/KSPACE -I/build/lammps-20200303+dfsg1/src/MANYBODY -I/build/lammps-20200303+dfsg1/src/MC -I/build/lammps-20200303+dfsg1/src/MISC -I/build/lammps-20200303+dfsg1/src/MOLECULE -I/build/lammps-20200303+dfsg1/src/PERI -I/build/lammps-20200303+dfsg1/src/POEMS -I/build/lammps-20200303+dfsg1/src/QEQ -I/build/lammps-20200303+dfsg1/src/REPLICA -I/build/lammps-20200303+dfsg1/src/RIGID -I/build/lammps-20200303+dfsg1/src/SHOCK -I/build/lammps-20200303+dfsg1/src/SNAP -I/build/lammps-20200303+dfsg1/src/SRD -I/build/lammps-20200303+dfsg1/src/KIM -I/build/lammps-20200303+dfsg1/src/PYTHON -I/build/lammps-20200303+dfsg1/src/MPIIO -I/build/lammps-20200303+dfsg1/src/VORONOI -I/build/lammps-20200303+dfsg1/src/USER-ATC -I/build/lammps-20200303+dfsg1/src/USER-AWPMD -I/build/lammps-20200303+dfsg1/src/USER-BOCS -I/build/lammps-20200303+dfsg1/src/USER-CGDNA -I/build/lammps-20200303+dfsg1/src/USER-MESO -I/build/lammps-20200303+dfsg1/src/USER-CGSDK -I/build/lammps-20200303+dfsg1/src/USER-DIFFRACTION -I/build/lammps-20200303+dfsg1/src/USER-DPD -I/build/lammps-20200303+dfsg1/src/USER-DRUDE -I/build/lammps-20200303+dfsg1/src/USER-EFF -I/build/lammps-20200303+dfsg1/src/USER-FEP -I/build/lammps-20200303+dfsg1/src/USER-H5MD -I/build/lammps-20200303+dfsg1/src/USER-LB -I/build/lammps-20200303+dfsg1/src/USER-MANIFOLD -I/build/lammps-20200303+dfsg1/src/USER-MEAMC -I/build/lammps-20200303+dfsg1/src/USER-MGPT -I/build/lammps-20200303+dfsg1/src/USER-MISC -I/build/lammps-20200303+dfsg1/src/USER-MOFFF -I/build/lammps-20200303+dfsg1/src/USER-MOLFILE -I/build/lammps-20200303+dfsg1/src/USER-NETCDF -I/build/lammps-20200303+dfsg1/src/USER-PHONON -I/build/lammps-20200303+dfsg1/src/USER-QTB -I/build/lammps-20200303+dfsg1/src/USER-SMD -I/build/lammps-20200303+dfsg1/src/USER-SMTBQ -I/build/lammps-20200303+dfsg1/src/USER-SPH -I/build/lammps-20200303+dfsg1/src/USER-TALLY -I/build/lammps-20200303+dfsg1/src/USER-UEF -I/build/lammps-20200303+dfsg1/src/USER-VTK -I/build/lammps-20200303+dfsg1/lib/poems -I/usr/include/hdf5/serial -I/build/lammps-20200303+dfsg1/src/USER-OMP -I/build/lammps-20200303+dfsg1/src/OPT -I/build/lammps-20200303+dfsg1/src/GPU -I/build/lammps-20200303+dfsg1/debian/build/styles -g -O2 -fdebug-prefix-map=/build/lammps-20200303+dfsg1=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -o CMakeFiles/poems.dir/build/lammps-20200303+dfsg1/lib/poems/joint.cpp.o -c /build/lammps-20200303+dfsg1/lib/poems/joint.cpp In file included from /build/lammps-20200303+dfsg1/lib/awpmd/systems/interact/TCP/wpmd.h:149, from /build/lammps-20200303+dfsg1/lib/awpmd/systems/interact/TCP/wpmd_split.h:65, from /build/lammps-20200303+dfsg1/lib/awpmd/systems/interact/TCP/wpmd_split.cpp:1: /build/lammps-20200303+dfsg1/lib/awpmd/ivutils/include/pairhash.h: In function 'int fileout(FILE*, const matrix_t&,
Bug#972832: dialog: can't change menu border lines
On Thu, Oct 29, 2020 at 05:42:05PM +0100, ennio wrote: > * Thomas Dickey [281020, 20:09]: ... > Ok, I'm enclosing the test-menu file 'p_menu.sh' and a shortned > '.dialogrc' used for my many tests. I tried with a full .dialogrc file > as well with the same identical results... ... > # -- > > # Run-time configuration file for dialog > # > # Automatically generated by "dialog --create-rc " > # > # > # Types of values: > # > # Number - > # String - "string" > # Boolean- > # Attribute - (foreground,background,highlight?) > # > > > # Shadow dialog boxes? This also turns on color. > use_shadow = Off > > # Turn color support ON or OFF > use_colors = ON > > # Screen color - NB: il secondo colore determina il background > screen_color = (CYAN,BLACK,ON) > > # Dialog box color > dialog_color = (BLACK,BLACK,ON) > #okok(CYAN,BLACK,ON) > > # Dialog box title color > title_color = (RED,BLACK,ON) > > # Dialog box border color - NB: interessa le righe super., infer. e a sx > border_color = (CYAN,BLACK,ON) > > # Menu box color > menubox_color = (cyan,black,on) > > # Menu box border color -> influenza angolo basso dx -> se si commenta, > # sballano i colori ma le righe restano lì > menubox_border_color = (CYAN,BLACK,ON) > > # Item color -> influenza la descrizione dgli item, a destra > item_color = (CYAN,BLACK,ON) > > # Selected item color > item_selected_color = (white,red,on) > > # Tag color -> influenza la parte sx degli item > tag_color = (cyan,black,on) > > # Selected tag color > tag_selected_color = (YELLOW,BLUE,ON) > > # Tag key color > tag_key_color = (RED,WHITE,OFF) > > # Selected tag key color > tag_key_selected_color = (white,red,on) > > # Up arrow color > uarrow_color = (GREEN,WHITE,ON) > > # Down arrow color > darrow_color = (GREEN,WHITE,ON) > > # Item help-text color > itemhelp_color = (WHITE,BLACK,OFF) > The basic problem is that there are color combinations which aren't set. Referring to samples/debian.rc, these at the end of the file are the missing settings that deal with the border colors: # Dialog box border2 color border2_color = dialog_color # Input box border2 color inputbox_border2_color = dialog_color # Search box border2 color searchbox_border2_color = dialog_color # Menu box border2 color menubox_border2_color = dialog_color In particular, the last one is what your configuration needs. Offhand, I believe those were introduced here: 2011/10/18 + add color table entries for secondary borders, i.e., the ones that are normally drawn with the dialog's text-colors (Debian #641168). -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Bug#973695: buster-pu: package ublock-origin/1.22.2+dfsg-1~deb10u1
Control: tags -1 + confirmed On Tue, 2020-11-03 at 13:02 +0100, Markus Koschany wrote: > I would like to update the Firefox/Chromium addon ublock-origin in > Buster. We have had several bug reports in the past about sandboxing > problems in regard to ublock-origin like #946808, #954097, #923001, > etc. As a consequence we build the separate browser-specific versions > for Firefox and Chromium again. The new version would also update > various blocklists and filters and improve the user experience. The debdiff between 1.22.2 and 1.30.0 is predictably huge - "311 files changed, 82663 insertions(+), 61606 deletions(-)". Looking over the packaging changes, at least the debhelper bump will need to be reverted, as buster has debhelper 12. Assuming that's the only required change, please go ahead. > Since ublock-origin is merely an addon there is no risk to break > other unrelated packages. I have tested version 1.30.0+dfsg in Buster > for both Firefox and Chromium and the addon works as expected. > > As outlined above this update introduces two new binary packages > webext-ublock-origin-firefox and webext-ublock-origin-chromium. If > approved, I assume the upload must include the binary packages and > cannot be source only, correct ? That's correct, yes, as the upload will hit bin-NEW. Regards, Adam
Bug#975487: tiled: No opt-in for information sharing on first startup (update check/what's new)
Package: tiled Version: 1.4.3-1 Severity: normal Forwarded: https://github.com/mapeditor/tiled/issues/2939 X-Debbugs-Cc: onit...@gmail.com Dear Maintainer, When starting Tiled for the first time on a new system, the two options "Display news in status bar" and "Highlight new version in status bar" are enabled by default. When turned on, these two options cause Tiled to contact online services to obtain the respective information. However: User aren't informed about the fact, and neither are they on what personal information is shared and with whom. This may a potential violation of GDPR, CCPA or other data protection laws. It doesn't look like there is an official policy for dealing with privacy issues in Debian packages, but I've seen complaints in other packages that had to be addressed. Additionally, the update check is not that useful when applications are installed via package manager and not manually downloaded. Please consider disabling the two checks by default for Debian packaging. I also forwarded the issue to the upstream but tracker: https://github.com/mapeditor/tiled/issues/2939 Thanks! -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (900, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (300, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-2-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_USER Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages tiled depends on: ii libc6 2.31-4 ii libgcc-s1 10.2.0-16 ii libqt5core5a5.15.1+dfsg-2 ii libqt5gui5 5.15.1+dfsg-2 ii libqt5network5 5.15.1+dfsg-2 ii libqt5qml5 5.15.1+dfsg-3 ii libqt5widgets5 5.15.1+dfsg-2 ii libstdc++6 10.2.0-16 ii libtiled1 1.4.2-1 tiled recommends no packages. tiled suggests no packages. -- no debconf information
Bug#284002: [PATCH] mdoc: Update operating system release numbers
On Mon, Nov 23, 2020 at 03:02:49AM +1100, G. Branden Robinson wrote: > At 2020-11-22T16:08:56+0100, Ingo Schwarze wrote: > > Sure. I dislike the concept of mdoc.local for more than one reason, > > but probably it is good enough for this purposes if there is no > > better way in Debian. If mdoc.local gets automatically updated > > during system updates, the proposed string also seems fine. If it > > is considered a user config file and does *not* get updated > > automatically, then something like just "Debian GNU/Linux" might > > be even better. > > Hahaha. This is Debian...it's _both_ automatically updated during system > updates _and_ considered a user config file! > > https://www.debian.org/doc/debian-policy/ap-pkg-conffiles.html > > "conffiles" have been a dpkg feature for something like 25 years now. > Every Debian sysadmin is familiar with the dpkg conffile prompt. :D [...] > I suspect most people don't touch mdoc.local, so it will be > automatically updated for them. > > Colin, what do you think? Putting this in mdoc.local would more or less work, but if I had to do this then I'd lean slightly towards just patching mdoc itself to say the right thing for the operating system. However, if that were the recommendation for distributors then it would seem likely to result in a lack of consistency. Maybe it's worth having a little bit of explicit support in upstream groff for what distributors are supposed to do? I'd suggest that groff's configure could gain a --with-os-name option whose argument becomes the default value of .Os; it can carry on defaulting to "BSD", or the output of uname(3), or whatever else as you see fit. That would (gently) encourage distributors to set this in a systematic way. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#968368: ifenslave: Option bond-master fails to add interface to bond
Good news! I fixed my setup and found a solution without patching ifenslave scripts. This was a local configuration issue, automation applied an old configuration ( from stable release). According to ifenslave git history, team refactored code since 2.9, removed ifenslave binary and switched to iproute2 for low level work. In my case, fix is - remove all configuration entries for slave devices and mention them only in the "slaves" config option. Without it, network-scripts try to configure interfaces with ifup and never hit the point to add interfaces to the bond device. For more info I added debug output. нд, 22 лист. 2020 о 11:02 Vova Samodid пише: > Unfortunately, patch does not work for me. > I have to install ifenslave 2.9 from stable release. > > -- > > Rgds., > > Vova Samodid > -- Rgds., Vova Samodid # dpkg -l | grep ifens ii ifenslave 2.11 all configure network interfaces for parallel routing (bonding) # ifup -v bond0 ifup: parsing file /etc/network/interfaces.d/bond0 ifup: parsing file /etc/network/interfaces.d/eno3 ifup: parsing file /etc/network/interfaces.d/eno4 ifup: configuring interface bond0=bond0 (inet) /bin/run-parts --exit-on-error --verbose /etc/network/if-pre-up.d run-parts: executing /etc/network/if-pre-up.d/bridge run-parts: executing /etc/network/if-pre-up.d/ethtool run-parts: executing /etc/network/if-pre-up.d/ifenslave + [ inet = meta ] + IF_BOND_SLAVES=eno3 eno4 + [ -n ] + [ -n eno3 eno4 ] + BOND_MASTER=bond0 + BOND_SLAVES=eno3 eno4 + setup_master_device bond0 + add_master + [ -f /sys/class/net/bond0/bonding/slaves ] + ip link add dev bond0 type bond + early_setup_master + sysfs fail_over_mac + [ -n ] + return 0 + setup_master + sysfs use_carrier + [ -n ] + return 0 + sysfs num_grat_arp + [ -n ] + return 0 + sysfs num_unsol_na + [ -n ] + return 0 + sysfs_add arp_ip_target + sysfs arp_interval + [ -n ] + return 0 + sysfs miimon 100 + [ -n 100 ] + echo 100 + return 0 + sysfs downdelay 200 + [ -n 200 ] + echo 200 + return 0 + sysfs updelay 200 + [ -n 200 ] + echo 200 + return 0 + sysfs_change_down ad_select + [ -n ] + sysfs_change_down mode 802.3ad + [ -n 802.3ad ] + grep -sq \<802.3ad\> /sys/class/net/bond0/bonding/mode + ip link show bond0 + grep -sq [<,]UP[,>] + sysfs mode 802.3ad + [ -n 802.3ad ] + echo 802.3ad + return 0 + sysfs_change_down xmit_hash_policy layer3+4 + [ -n layer3+4 ] + grep -sq \ /sys/class/net/bond0/bonding/xmit_hash_policy + ip link show bond0 + grep -sq [<,]UP[,>] + sysfs xmit_hash_policy layer3+4 + [ -n layer3+4 ] + echo layer3+4 + return 0 + sysfs_change_down tlb_dynamic_lb + [ -n ] + sysfs packets_per_slave + [ -n ] + return 0 + sysfs arp_validate + [ -n ] + return 0 + sysfs_change_down lacp_rate + [ -n ] + [ -n ] + enslave_slaves + [ 1 = 1 ] + v=-v + export IFENSLAVE_ENV_NAME=IFUPDOWN_eno3 + printenv IFUPDOWN_eno3 + IFUPDOWN_IFACE= + unset IFENSLAVE_ENV_NAME + ifquery --state eno3 + [ -n ] + ifquery -l eno3 eno3 + ifup -v eno3 ifup: parsing file /etc/network/interfaces.d/bond0 ifup: parsing file /etc/network/interfaces.d/eno3 ifup: parsing file /etc/network/interfaces.d/eno4 ifup: configuring interface eno3=eno3 (inet) /bin/run-parts --exit-on-error --verbose /etc/network/if-pre-up.d run-parts: executing /etc/network/if-pre-up.d/bridge run-parts: executing /etc/network/if-pre-up.d/ethtool run-parts: executing /etc/network/if-pre-up.d/ifenslave + [ inet = meta ] + IF_BOND_SLAVES= + [ -n ] + [ -n ] + [ -n ] + exit 0 run-parts: executing /etc/network/if-pre-up.d/vlan /sbin/ip link set dev eno3 up 2>/dev/null || true /bin/run-parts --exit-on-error --verbose /etc/network/if-up.d run-parts: executing /etc/network/if-up.d/ethtool run-parts: executing /etc/network/if-up.d/ifenslave + [ inet = meta ] + [ ] run-parts: executing /etc/network/if-up.d/ip + export IFENSLAVE_ENV_NAME=IFUPDOWN_eno4 + printenv IFUPDOWN_eno4 + IFUPDOWN_IFACE= + unset IFENSLAVE_ENV_NAME + ifquery --state eno4 + [ -n ] + ifquery -l eno4 eno4 + ifup -v eno4 ifup: parsing file /etc/network/interfaces.d/bond0 ifup: parsing file /etc/network/interfaces.d/eno3 ifup: parsing file /etc/network/interfaces.d/eno4 ifup: configuring interface eno4=eno4 (inet) /bin/run-parts --exit-on-error --verbose /etc/network/if-pre-up.d run-parts: executing /etc/network/if-pre-up.d/bridge run-parts: executing /etc/network/if-pre-up.d/ethtool run-parts: executing /etc/network/if-pre-up.d/ifenslave + [ inet = meta ] + IF_BOND_SLAVES= + [ -n ] + [ -n ] + [ -n ] + exit 0 run-parts: executing /etc/network/if-pre-up.d/vlan /sbin/ip link set dev eno4 up 2>/dev/null || true /bin/run-parts --exit-on-error --verbose /etc/network/if-up.d run-parts: executing /etc/network/if-up.d/ethtool run-parts: executing /etc/network/if-up.d/ifenslave + [ inet = meta ] + [ ] run-parts: executing /etc/network/if-up.d/ip + setup_primary + sysfs primary_reselect + [ -n ] + return 0 + exit 0 run-parts: executing /etc/network/if-pre
Bug#975284: reopen, issue not fixed
Control: reopen -1
looking at the build log at
https://buildd.debian.org/status/fetch.php?pkg=calibre&arch=amd64&ver=5.5.0%2Bdfsg-2&stamp=1606054693&raw=0
[...]
find debian/tmp -type f | xargs sed -i '1 { /^#!.*python/
s_^.*$_#!/usr/bin/python3.9_ }'
why?
[...]
make[1]: Leaving directory '/<>'
dh_python3 -a -O--buildsystem=makefile
E: dh_python3 dh_python3:176: no package to act on (python3-foo or one with
${python3:Depends} in Depends)
something goes wrong
Depends: libc6 (>= 2.29), libespeak-ng1 (>= 1.50+dfsg), libfontconfig1 (>=
2.12.6), libfreetype6 (>= 2.6), libgcc-s1 (>= 3.0), libglib2.0-0 (>= 2.12.0),
libhunspell-1.7-0, libhyphen0 (>= 2.8.7), libicu67 (>= 67.1-1~), libmtp9 (>=
1.1.5), libpodofo0.9.6 (>= 0.9.6+dfsg), libpython3.9 (>= 3.9.0~b4), libqt5core5a
(>= 5.15.1), libqt5dbus5 (>= 5.12), libqt5gui5 (>= 5.14.1) | libqt5gui5-gles (>=
5.14.1), libqt5widgets5 (>= 5.12), libstdc++6 (>= 5.2), libusb-1.0-0 (>=
2:1.0.9), qtbase-abi-5-15-1, python3-pyqt5.sip, python3
no python3:Depends dependency generated, and the 'python3' dependency is not
good enough
the calibre-bin package needs to end up with a dependency:
python3 (>= 3.9), python3 (<< 3.10)
Bug#970725: cups-client: lpoptions fails to get printer options
found 970725 2.3.3op1-106-ga72b0140e-1 thanks It is not too surprising to still find the described behaviour in the experimental version of cups-client as it contains the patch "Make lpoptions list a printer's options correctly also when CUPS is running on an alternative port". Is it possible to reinstate what CUPS Issue #5045 was intended to fix and provide? Sometimes, I am inclined to submit reports that are not in fact bugs; I usually discover this myself. I would appreciate knowing whether this bug too should be closed. Cheers, Brian.
Bug#955277: buster-pu: package mini-buildd/1.0.36
Control: tags -1 -moreinfo +confirmed Hi, Apologies for having somehow missed your earlier reply. On Tue, 2020-04-28 at 08:51 +0200, Stephan Sürken wrote: > Hi Adam, > > thanks for yor answer. > > On Sun, 2020-04-26 at 15:34 +0100, Adam D. Barratt wrote: > (...) > > > We'd need to see diffs for a proposed upload before OKing anything > > here. > > Sure; just was somewhat confused how to proceed in the 1st place ;). > > I have now (correctly) flagged the bug as fixed in 1.0.37. > > The proposed update will only address this > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951641 > > very bug (see attached diff). Please go ahead. Regards, Adam
Bug#975486: rust-libz-sys: autopkgtest failure: src/zlib/adler32.c: No such file or directory
Source: rust-libz-sys
Version: 1.1.2-2
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: fails-always
Dear maintainer(s),
You recently added an autopkgtest to your package rust-libz-sys, great.
However, it fails. Currently this failure is blocking the migration to
testing [1]. Can you please investigate the situation and fix it?
I copied some of the output at the bottom of this report.
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=rust-libz-sys
https://ci.debian.net/data/autopkgtest/testing/amd64/r/rust-libz-sys/7592938/log.gz
Running
`/tmp/tmp.GylevYz9Se/target/debug/build/libz-sys-4d7f2bd81492bad5/build-script-build`
[libz-sys 1.1.2] cargo:rerun-if-env-changed=LIBZ_SYS_STATIC
[libz-sys 1.1.2] cargo:rerun-if-changed=build.rs
[libz-sys 1.1.2] TARGET = Some("x86_64-unknown-linux-gnu")
[libz-sys 1.1.2] OPT_LEVEL = Some("0")
[libz-sys 1.1.2] HOST = Some("x86_64-unknown-linux-gnu")
[libz-sys 1.1.2] CC_x86_64-unknown-linux-gnu = None
[libz-sys 1.1.2] CC_x86_64_unknown_linux_gnu = None
[libz-sys 1.1.2] HOST_CC = None
[libz-sys 1.1.2] CC = None
[libz-sys 1.1.2] CFLAGS_x86_64-unknown-linux-gnu = None
[libz-sys 1.1.2] CFLAGS_x86_64_unknown_linux_gnu = None
[libz-sys 1.1.2] HOST_CFLAGS = None
[libz-sys 1.1.2] CFLAGS = Some("-g -O2
-fdebug-prefix-map=/usr/share/cargo/registry/libz-sys-1.1.2=.
-fstack-protector-strong -Wformat -Werror=format-security")
[libz-sys 1.1.2] CRATE_CC_NO_DEFAULTS = None
[libz-sys 1.1.2] DEBUG = Some("true")
[libz-sys 1.1.2] CARGO_CFG_TARGET_FEATURE = Some("fxsr,sse,sse2")
[libz-sys 1.1.2] running: "cc" "-O0" "-ffunction-sections"
"-fdata-sections" "-fPIC" "-g" "-fno-omit-frame-pointer" "-m64" "-g"
"-O2" "-fdebug-prefix-map=/usr/share/cargo/registry/libz-sys-1.1.2=."
"-fstack-protector-strong" "-Wformat" "-Werror=format-security" "-I"
"src/zlib" "-fvisibility=hidden" "-DSTDC" "-D_LARGEFILE64_SOURCE"
"-D_POSIX_SOURCE" "-o"
"/tmp/tmp.GylevYz9Se/target/x86_64-unknown-linux-gnu/debug/build/libz-sys-a4a1831fc0ceaac9/out/build/src/zlib/adler32.o"
"-c" "src/zlib/adler32.c"
[libz-sys 1.1.2] cargo:warning=cc: error: src/zlib/adler32.c: No such
file or directory
[libz-sys 1.1.2] cargo:warning=cc: fatal error: no input files
[libz-sys 1.1.2] cargo:warning=compilation terminated.
[libz-sys 1.1.2] exit code: 1
[libz-sys 1.1.2]
[libz-sys 1.1.2]
[libz-sys 1.1.2] error occurred: Command "cc" "-O0"
"-ffunction-sections" "-fdata-sections" "-fPIC" "-g"
"-fno-omit-frame-pointer" "-m64" "-g" "-O2"
"-fdebug-prefix-map=/usr/share/cargo/registry/libz-sys-1.1.2=."
"-fstack-protector-strong" "-Wformat" "-Werror=format-security" "-I"
"src/zlib" "-fvisibility=hidden" "-DSTDC" "-D_LARGEFILE64_SOURCE"
"-D_POSIX_SOURCE" "-o"
"/tmp/tmp.GylevYz9Se/target/x86_64-unknown-linux-gnu/debug/build/libz-sys-a4a1831fc0ceaac9/out/build/src/zlib/adler32.o"
"-c" "src/zlib/adler32.c" with args "cc" did not execute successfully
(status code exit code: 1).
[libz-sys 1.1.2]
[libz-sys 1.1.2]
error: failed to run custom build command for `libz-sys v1.1.2
(/usr/share/cargo/registry/libz-sys-1.1.2)`
Caused by:
process didn't exit successfully:
`/tmp/tmp.GylevYz9Se/target/debug/build/libz-sys-4d7f2bd81492bad5/build-script-build`
(exit code: 1)
--- stdout
cargo:rerun-if-env-changed=LIBZ_SYS_STATIC
cargo:rerun-if-changed=build.rs
TARGET = Some("x86_64-unknown-linux-gnu")
OPT_LEVEL = Some("0")
HOST = Some("x86_64-unknown-linux-gnu")
CC_x86_64-unknown-linux-gnu = None
CC_x86_64_unknown_linux_gnu = None
HOST_CC = None
CC = None
CFLAGS_x86_64-unknown-linux-gnu = None
CFLAGS_x86_64_unknown_linux_gnu = None
HOST_CFLAGS = None
CFLAGS = Some("-g -O2
-fdebug-prefix-map=/usr/share/cargo/registry/libz-sys-1.1.2=.
-fstack-protector-strong -Wformat -Werror=format-security")
CRATE_CC_NO_DEFAULTS = None
DEBUG = Some("true")
CARGO_CFG_TARGET_FEATURE = Some("fxsr,sse,sse2")
running: "cc" "-O0" "-ffunction-sections" "-fdata-sections" "-fPIC" "-g"
"-fno-omit-frame-pointer" "-m64" "-g" "-O2"
"-fdebug-prefix-map=/usr/share/cargo/registry/libz-sys-1.1.2=."
"-fstack-protector-strong" "-Wformat" "-Werror=format-security" "-I"
"src/zlib" "-fvisibility=hidden" "-DSTDC" "-D_LARGEFILE64_SOURCE"
"-D_POSIX_SOURCE" "-o"
"/tmp/tmp.GylevYz9Se/target/x86_64-unknown-linux-gnu/debug/build/libz-sys-a4a1831fc0ceaac9/out/build/src/zlib/adler32.o"
"-c" "src/zlib/adler32.c"
cargo:warning=cc: error: src/zlib/adler32.c: No such file or directory
cargo:warning=cc: fatal error: no input files
cargo:warning=compilation terminated.
exit code: 1
--- stderr
error occurred: Command "cc" "-O0" "-ffunction-sections"
"-fdata-sections" "-fPIC" "-g" "-fno-omit-frame-pointer" "-m64" "-g"
"-O2" "-fdebug-prefix-map=/usr/share/cargo/registry/libz-sys-1.1.2=."
"-fstack-protector-strong" "-Wformat" "-Werror=format-security" "-I"
"src/zlib" "-fvisibility=hidden" "-DSTDC" "-D_LARGEFILE64
Bug#975485: Use libmariadb-dev instead of legacy libmariadbclient-dev
Package: ddnet Hello! I noticed the source package has references to libmariadbclient-dev: https://salsa.debian.org/search?search=libmariadbclient-dev&project_id=12775&group_id=2006 This is a deprecated package and you should instead use libmariadb-dev[1] or libmariadb-dev-compat if you need to build something old that does not find the correct soname otherwise. Those lines are probably more relevant upstream, but I was not able to easily find where the upstream sources are so filing this now in Debian. Thanks! 1: https://packages.debian.org/search?keywords=libmariadb-dev
Bug#963340: (no subject)
Control: tags -1 -moreinfo +confirmed On Thu, 2020-11-12 at 22:28 +0100, gustavo panizzo wrote: > can you comment if the attached patch [1] is acceptable for inclusion > in the next stable update? > > It addresses #961589, #963012 and the flushing rules logic [2]? Please go ahead. Regards, Adam
Bug#975484: rust-dbus: autopkgtest regression: build failed: expected `str`, found struct `std::ffi::CStr`
Source: rust-dbus
Version: 0.9.0-2
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
Dear maintainer(s),
With a recent upload of rust-dbus the autopkgtest of rust-dbus fails in
testing when that autopkgtest is run with the binary packages of
rust-dbus from unstable. It passes when run with only packages from
testing. In tabular form:
passfail
rust-dbus from testing0.9.0-2
all others from testingfrom testing
I copied some of the output at the bottom of this report.
Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?
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=rust-dbus
https://ci.debian.net/data/autopkgtest/testing/amd64/r/rust-dbus/8343716/log.gz
Running `CARGO_MANIFEST_DIR=/usr/share/cargo/registry/dbus-0.9.0
LD_LIBRARY_PATH='/tmp/tmp.mOh7cBiqA2/target/debug/deps:/usr/lib'
CARGO=/usr/bin/cargo CARGO_PKG_VERSION_MINOR=9 CARGO_PKG_VERSION_PATCH=0
CARGO_PKG_DESCRIPTION='Bindings to D-Bus, which is a bus commonly used
on Linux for inter-process communication.' CARGO_PKG_HOMEPAGE=
CARGO_PKG_REPOSITORY='https://github.com/diwic/dbus-rs'
CARGO_PKG_VERSION_MAJOR=0 CARGO_PKG_VERSION=0.9.0 CARGO_PKG_NAME=dbus
CARGO_PKG_AUTHORS='David Henningsson '
CARGO_PKG_VERSION_PRE= rustc --crate-name dbus --edition=2018 src/lib.rs
--error-format=json --json=diagnostic-rendered-ansi --emit=dep-info,link
-C debuginfo=2 --test --cfg 'feature="no-string-validation"' -C
metadata=78a9c65232eb4ced -C extra-filename=-78a9c65232eb4ced --out-dir
/tmp/tmp.mOh7cBiqA2/target/x86_64-unknown-linux-gnu/debug/deps --target
x86_64-unknown-linux-gnu -C
incremental=/tmp/tmp.mOh7cBiqA2/target/x86_64-unknown-linux-gnu/debug/incremental
-L
dependency=/tmp/tmp.mOh7cBiqA2/target/x86_64-unknown-linux-gnu/debug/deps
-L dependency=/tmp/tmp.mOh7cBiqA2/target/debug/deps --extern
libc=/tmp/tmp.mOh7cBiqA2/target/x86_64-unknown-linux-gnu/debug/deps/liblibc-4745c4b1773b68fd.rlib
--extern
libdbus_sys=/tmp/tmp.mOh7cBiqA2/target/x86_64-unknown-linux-gnu/debug/deps/liblibdbus_sys-be39e730af80d440.rlib
--extern
tempfile=/tmp/tmp.mOh7cBiqA2/target/x86_64-unknown-linux-gnu/debug/deps/libtempfile-d85e26fb23f42f7b.rlib
-C debuginfo=2 --cap-lints warn -C linker=x86_64-linux-gnu-gcc -C
link-arg=-Wl,-z,relro --remap-path-prefix
/usr/share/cargo/registry/dbus-0.9.0=/usr/share/cargo/registry/dbus-0.9.0
-L native=/usr/lib/x86_64-linux-gnu`
error[E0308]: mismatched types
--> src/strings.rs:230:51
|
230 | assert_eq!(p2, Ok(Path(Cow::Borrowed(unsafe {
CStr::from_ptr(b"##invalid##\0".as_ptr() as *const c_char) };
|
^^ expected
`str`, found struct `std::ffi::CStr`
|
= note: expected reference `&str`
found reference `&std::ffi::CStr`
error: aborting due to previous error
For more information about this error, try `rustc --explain E0308`.
error: could not compile `dbus`.
Caused by:
process didn't exit successfully:
`CARGO_MANIFEST_DIR=/usr/share/cargo/registry/dbus-0.9.0
LD_LIBRARY_PATH='/tmp/tmp.mOh7cBiqA2/target/debug/deps:/usr/lib'
CARGO=/usr/bin/cargo CARGO_PKG_VERSION_MINOR=9 CARGO_PKG_VERSION_PATCH=0
CARGO_PKG_DESCRIPTION='Bindings to D-Bus, which is a bus commonly used
on Linux for inter-process communication.' CARGO_PKG_HOMEPAGE=
CARGO_PKG_REPOSITORY='https://github.com/diwic/dbus-rs'
CARGO_PKG_VERSION_MAJOR=0 CARGO_PKG_VERSION=0.9.0 CARGO_PKG_NAME=dbus
CARGO_PKG_AUTHORS='David Henningsson '
CARGO_PKG_VERSION_PRE= rustc --crate-name dbus --edition=2018 src/lib.rs
--error-format=json --json=diagnostic-rendered-ansi --emit=dep-info,link
-C debuginfo=2 --test --cfg 'feature="no-string-validation"' -C
metadata=78a9c65232eb4ced -C extra-filename=-78a9c65232eb4ced --out-dir
/tmp/tmp.mOh7cBiqA2/target/x86_64-unknown-linux-gnu/debug/deps --target
x86_64-unknown-linux-gnu -C
incremental=/tmp/tmp.mOh7cBiqA2/target/x86_64-unknown-linux-gnu/debug/incremental
-L
dependency=/tmp/tmp.mOh7cBiqA2/target/x86_64-unknown-linux-gnu/debug/deps
-L dependency=/tmp/tmp.mOh7cBiqA2/target/debug/deps --extern
libc=/tmp/tmp.mOh7cBiqA2/target/x86_64-unknown-linux-gnu/debug/deps/liblibc-4745c4b1773b68fd.rlib
--extern
libdbus_sys=/tmp/tmp.mOh7cBiqA2/target/x86_64-unknown-linux-gnu/debug/deps/liblibdbus_sys-be39e730af80d440.rlib
--extern
tempfile=/tmp/tmp.mOh7cBiqA2/target/x86_64-unknown-linux-gnu/debug/deps/libtempfile-d85e26fb23f42f7b.rlib
-C debuginfo=2 --cap-lints warn -C linker=x86_64-linux-gnu-gcc -C
link-arg=-Wl,-z,relro --remap-path-prefix
/usr/share/cargo/registry/dbus-0.9.0=/usr/share/cargo/registry/dbus-0.9.0
-L native=/usr/lib/x86_64-linux-gnu` (exit code: 1)
warning: build failed, waiting for other jobs to finish...
error: buil
Bug#975483: Use libmariadb-dev-compat instead of legacy libmariadbclient-dev-compat
Package: sope Hello! I noticed the source package has references to libmariadbclient-dev: https://salsa.debian.org/search?search=libmariadbclient-dev&project_id=19493&group_id=2 This is a deprecated package and you should instead use libmariadb-dev[1] or libmariadb-dev-compat if you need to build something old that does not find the correct soname otherwise. Thanks! 1: https://packages.debian.org/search?keywords=libmariadb-dev
Bug#975482: Use libmariadb-dev instead of legacy libmariadbclient-dev
Package: r-cran-rdflib Hello! I noticed the source package has references to libmariadbclient-dev: https://salsa.debian.org/search?search=libmariadbclient-dev&project_id=26139&group_id=2429 This is a deprecated package and you should instead use libmariadb-dev[1] or libmariadb-dev-compat if you need to build something old that does not find the correct soname otherwise. I am not sure if those Dockerfiles are relevant in Debian, but filing this just in case. Thanks! 1: https://packages.debian.org/search?keywords=libmariadb-dev
Bug#975481: Use libmariadb-dev instead of legacy libmariadbclient-dev
Package: libreoffice Hello! I noticed the source package has references to libmariadbclient-dev: https://salsa.debian.org/search?search=libmariadbclient-dev&project_id=1012&group_id=2250 This is a deprecated package and you should instead use libmariadb-dev[1] or libmariadb-dev-compat if you need to build something old that does not find the correct soname otherwise. Thanks! 1: https://packages.debian.org/search?keywords=libmariadb-dev
Bug#975476: Acknowledgement (SUM function sometimes includes cells outside the range)
Control: severity -1 normal Control: retitle -1 No error reported for self-referential formula Sorry, this is actually the result of a typo I couldn't see. The sum is of A1:A298, so it does include itself. But I think it's a bug that self-referential formulae are not detected as an error. LibreOffice Calc does report an error for this. Ben. -- Ben Hutchings If at first you don't succeed, you're doing about average. signature.asc Description: This is a digitally signed message part
Bug#975477: Use libmariadb-dev instead of legacy libmariadbclient-dev
Package: net-snmp Hello! I noticed the source package has references to libmariadbclient-dev: https://salsa.debian.org/search?search=libmariadbclient-dev&project_id=18243&group_id=2 This is a deprecated package and you should instead use libmariadb-dev[1] or libmariadb-dev-compat if you need to build something old that does not find the correct soname otherwise. I am not sure if those ci/* files are relevant in Debian, but filing this just in case. Thanks! 1: https://packages.debian.org/search?keywords=libmariadb-dev
Bug#975480: rust-bzip2-sys: autopkgtest failure: crate directory not found: /usr/share/cargo/registry/bzip2-sys-0.1.9+1.0.8
Source: rust-bzip2-sys Version: 0.1.9-1 X-Debbugs-CC: debian...@lists.debian.org Severity: serious User: debian...@lists.debian.org Usertags: fails-always Dear maintainer(s), You recently added an autopkgtest to your package rust-bzip2-sys, great. However, it fails. Currently this failure is blocking the migration to testing [1]. Can you please investigate the situation and fix it? I copied some of the output at the bottom of this report. 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=rust-bzip2-sys https://ci.debian.net/data/autopkgtest/testing/amd64/r/rust-bzip2-sys/7500282/log.gz autopkgtest [09:47:16]: test librust-bzip2-sys-dev: /usr/share/cargo/bin/cargo-auto-test bzip2-sys 0.1.9+1.0.8 --all-targets --no-default-features autopkgtest [09:47:16]: test librust-bzip2-sys-dev: [--- crate directory not found: /usr/share/cargo/registry/bzip2-sys-0.1.9+1.0.8 autopkgtest [09:47:16]: test librust-bzip2-sys-dev: ---] signature.asc Description: OpenPGP digital signature
Bug#971392: buster-pu: package tigervnc/1.9.0+dfsg-3+deb10u3
Control: tags -1 + confirmed On Tue, 2020-09-29 at 21:32 +0200, Joachim Falk wrote: > Security fix for CVE-2020-26117 as detailed in bug #971272. > Please go ahead; sorry for the delay. Regards, Adam
Bug#975479: rust-rpassword: autopkgtest regression: thread 'piped_password' panicked
Source: rust-rpassword
Version: 5.0.0-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
Dear maintainer(s),
With a recent upload of rust-rpassword the autopkgtest of rust-rpassword
fails in testing when that autopkgtest is run with the binary packages
of rust-rpassword from unstable. It passes when run with only packages
from testing. In tabular form:
passfail
rust-rpassword from testing5.0.0-1
all others from testingfrom testing
I copied some of the output at the bottom of this report.
Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?
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=rust-rpassword
https://ci.debian.net/data/autopkgtest/testing/amd64/r/rust-rpassword/8347228/log.gz
running 1 test
test piped_password ... FAILED
failures:
piped_password stdout
stdout:
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
thread 'piped_password' panicked at 'assertion failed:
stdout.ends_with("Password: secret\n")', tests/piped.rs:34:5
stack backtrace:
0: std::panicking::begin_panic
at /usr/src/rustc-1.47.0/library/std/src/panicking.rs:497
1: piped::piped_password
at ./tests/piped.rs:34
2: piped::piped_password::{{closure}}
at ./tests/piped.rs:8
3: core::ops::function::FnOnce::call_once
at /usr/src/rustc-1.47.0/library/core/src/ops/function.rs:227
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a
verbose backtrace.
failures:
piped_password
test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0
filtered out
error: test failed, to rerun pass '--test piped'
autopkgtest [06:11:35]: test librust-rpassword-dev: ---]
signature.asc
Description: OpenPGP digital signature
Bug#975478: Use libmariadb-dev instead of legacy libmariadbclient-dev
Package: puppet-module-puppetlabs-mysql Hello! I noticed the source package has references to libmariadbclient-dev: https://salsa.debian.org/search?search=libmariadbclient-dev&project_id=6453&group_id=2572 This is a deprecated package and you should instead use libmariadb-dev[1] or libmariadb-dev-compat if you need to build something old that does not find the correct soname otherwise. I am not sure if the params.pp is relevant in Debian, but filing this just in case. Thanks! 1: https://packages.debian.org/search?keywords=libmariadb-dev
Bug#973342: buster-pu: package libdbi-perl/1.642-1+deb10u2
Control: tags -1 + confirmed On Thu, 2020-10-29 at 07:43 +0100, Xavier Guimard wrote: > libdbi-perl is still vulnerable to CVE-2014-10401: DBD::File drivers > can open files from folders other than those specifically passed via > the f_dir attribute. + * lib/DBD/File.pm: fix CVE-2014-10401 (Closes: #972180) That bug report claims to be related to CVE-2014-1040*2*, which is the result of an incomplete initial fix for CVE-2014-10401. That seems worth clarifying, but in any case please go ahead. Regards, Adam
Bug#975476: SUM function sometimes includes cells outside the range
Package: gnumeric Version: 1.12.48-1+b1 Severity: serious In certain circumstances, that I haven't yet identified precisely, a cell containing the SUM function applied to a range of values above it appears to be recalculated including its own previous value! This results in the sum increasing on every recalculation. You should be able to see this in the attached sheet. A99 contains the formula =SUM(A1:A98) and is initially shown with a value of 4950. If you fill in the value 1 in A98, the sum changes to 9901. Ben. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-2-amd64 (SMP w/2 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnumeric depends on: ii debconf [debconf-2.0] 1.5.74 ii gnumeric-common1.12.48-1 ii gsfonts1:8.11+urwcyr1.0.7~pre44-4.4 ii libatk1.0-02.36.0-2 ii libc6 2.31-4 ii libcairo2 1.16.0-4 ii libgdk-pixbuf2.0-0 2.40.0+dfsg-5 ii libglib2.0-0 2.66.2-1 ii libgoffice-0.10-10 0.10.48-1 ii libgsf-1-114 1.14.47-1 ii libgtk-3-0 3.24.23-2 ii libpango-1.0-0 1.46.2-3 ii libpangocairo-1.0-01.46.2-3 ii libxml22.9.10+dfsg-6.2 ii procps 2:3.3.16-5 ii pxlib1 0.6.8-1+b1 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages gnumeric recommends: ii evince3.38.0-2 ii gnumeric-doc 1.12.48-1 ii lp-solve 5.5.2.5-2 Versions of packages gnumeric suggests: ii fonts-liberation1:1.07.4-11 pn gnumeric-plugins-extra pn libgsf-1-dev -- debconf information: gnumeric/existing-process-title: gnumeric/existing-process: false sum-bug.gnumeric Description: application/gzip
Bug#975219: [Debichem-devel] Bug#975219: elkcode: FTBFS: internal compiler error: in lookup_field_for_decl, at tree-nested.c:288
Hi Michael, On 22/11/20 at 15:32 +0100, Michael Banck wrote: > Hi Lucas, > > That looks like an ICE, shouldn't that be filed with gfortran? Usually my logic is: if there's only one similar failure, I file a bug against the affected package, rather than against the toolchain package or the library, because it might be something very strange with the package that is causing the toolchain to misbehave. (In that case, that was the only ICE; and I also notified doko about it on IRC) Lucas
Bug#975475: package takes much more space
Package: dxvk-wine64-development Version: 1.7.2+ds1-2 For some reason, the new version consumes much more storage space: dxvk-wine32-development:i386+268 MB 1.7.2+ds1-11.7.2+ds1-2 dxvk-wine64-development +287 MB 1.7.2+ds1-11.7.2+ds1-2 while the changelog doesn't give a hint on what would take that much space
