Bug#795052: sleuthkit: Uses embedded copy of libexif-0.6.20
* Michael Prokop [Fri Jan 31, 2020 at 04:17:54PM +0100]: > * Eriberto Mota [Wed Nov 30, 2016 at 09:33:44AM -0200]: > > 2015-08-09 20:58 GMT-03:00 Scott Kitterman : > > > Although not a must in Debian policy, the preference is to not use > > > embedded > > > copies of libraries. sleuthkit-4.1.3/framework/modules/c_LibExifModule > > > has > > > an embedded copy of libexif-0.6.20 that is used during package build. It > > > would be better to use the system libexif. [...] > FYI: I've forwarded this to upstream (especially since > c_LibExifModule is quite outdated), it's tracked at > https://github.com/sleuthkit/sleuthkit/issues/1807 Upstream removed the embedded libexif from sleuthkit, so with the next upload of it we could close this bug report. regards -mika- signature.asc Description: Digital signature
Bug#951453: RFS: pysolfc/2.6.4-3 -- collection of more than 1000 solitaire card games
Hi, thanks for your contribution, this should be in unstable by tonight. cheers, Hugo -- Hugo Lefeuvre (hle)|www.owl.eu.com RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C signature.asc Description: PGP signature
Bug#951365: autopkgtest: blocks TL due to warnings of unknown specials
Hi Stuart, thanks for answering. > Thanks for reporting that the autopkgtest fails; ci.d.n is not currently > testing packages in unstable and so I'd not seen that this was a problem yet. Hmmm, but this is the reason why texlive-base is blocked, according to https://qa.debian.org/excuses.php?package=texlive-base Migration status for texlive-base (2019.20191208-4 to 2019.20200218-1): BLOCKED: Rejected/violates migration policy/introduces a regression > Teaching pyxplot about these new specials is the right thing to do here. The Well, in principle, but the package seems abandon from upstream, do you want to implement these new things? > autopkgtests aren't broken, they are correctly catching that pyxplot is > generating lots of nasty warnings that the user should not see. > > I'll take a look at this soon; it's easy enough to make the header special a I have asked the LaTeX team whether one can disable the loading of the l3backend-X.pro files, which could easily be integrated into the source code (that I checked already in the source code of pyxplot). Best Norbert -- PREINING Norbert https://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#951630: libsemanage1: FTBFS due to clean failure when you build it twice
Package: libsemanage1 Version: 3.0-1 Severity: normal This patch allows you to build it again after it's already been built once. Note that src/Makefile is probably buggy in that it won't remove the *.so files when you run "make -C src clean". --- libsemanage-3.0/debian/rules2019-12-12 10:47:10.0 + +++ ../libsemanage-3.0/debian/rules 2020-02-19 06:35:06.577127195 + @@ -58,6 +58,9 @@ endif override_dh_auto_clean: + make -C tests clean + make -C src clean + rm src/*.so ifneq ($(filter python3-semanage,$(DOPACKAGES)),) set -e; for version in $(PY3VERSIONS); do \ $(MAKE) clean PYTHON=python$$version; \ -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-8-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Enforcing - Policy name: default Versions of packages libsemanage1 depends on: ii libaudit1 1:2.8.5-2+b1 ii libbz2-1.0 1.0.8-2 ii libc6 2.29-10 ii libselinux1 3.0-1 ii libsemanage-common 3.0-1 ii libsepol1 3.0-1 libsemanage1 recommends no packages. libsemanage1 suggests no packages. -- no debconf information
Bug#951625: kde: Switch Displays not working
Control: reassign -1 kde-plasma-desktop On Mi, 19 feb 20, 08:59:40, Shankar wrote: > Package: kde > Version: kde-plasma-desktop > Severity: normal > > Dear Maintainer, > > I am using KDE on a Debian mixed testing/buster system. Until recently, > plugging / unplugging the HDMI cable, or pressing Fn+F8(display) on my laptop > keyboard, would pop up the switch displays pop up and allow me to choose how > to use an external monitor. > > Recently this has stopped happening. Instead Debian assumes that i want to > stretch the display across both monitors (which is not what I want to do). I > have to force mirroring of displays using 'xrandr' in my .profile, choose my > external monitor as the Primary Screen from Displays, and then manually > restart plasmashell in order to get a full desktop. > > The shortcut combination in Global Shortcuts (Meta+P) also has no effect. I > tried changing the shortcut to another combination, still no effect. > > Thank you for all your hard work! > > > *** Reporter, please consider answering these questions, where appropriate *** > >* What led up to the situation? >* What exactly did you do (or not do) that was effective (or > ineffective)? >* What was the outcome of this action? >* What outcome did you expect instead? > > *** End of the template - remove these template lines *** > > > -- System Information: > Debian Release: bullseye/sid > APT prefers testing > APT policy: (900, 'testing'), (500, 'stable-updates'), (500, 'stable') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.3.0-3-amd64 (SMP w/2 CPU cores) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE= > (charmap=UTF-8) > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Bug#950684: Debian Bug #950684
severity 950684 serious Thanks Hello, I set the severity to serious. CU Jörg -- New: GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB 30EE 09F8 9F3C 8CA1 D25D GPG key (long) : 09F89F3C8CA1D25D GPG Key: 8CA1D25D CAcert Key S/N : 0E:D4:56 Old pgp Key: BE581B6E (revoked since 2014-12-31). Jörg Frings-Fürst D-54470 Lieser git: https://jff.email/cgit/ Threema: SYR8SJXB Wire: @joergfringsfuerst Skype:joergpenguin Ring: jff Telegram: @joergfringsfuerst My wish list: - Please send me a picture from the nature at your home. signature.asc Description: This is a digitally signed message part
Bug#951572: buster-pu: package uml-utilities/20070815.2-1
Control: tag -1 +patch Sorry to have missed to attach the debdiff. On Tue, 2020-02-18 at 13:49 +0530, Ritesh Raj Sarraf wrote: > Package: release.debian.org > Severity: normal > Tags: buster > User: release.debian@packages.debian.org > Usertags: pu > > The port-helper binary shipped with the uml-utilities package was > installed to a non-standard path creating problems for the uml tool > to > find the helper binary. Details are mentioned in DBUG: 928924 > > This change simply picks up the latest package version from Unstable. > > Note: the uml-utilities package is upstream maintained in the Debian > salsa repository itself. Because there's no effective upstream for > uml-utilities and all distributions that care of this pacakge > maintain > their respective forks. > > Some time ago, there was intent from Mattia Dongli, the previous > co-maintainer for UML, to take upstream maintenance for uml- > utilities. > But since he retired from the Debian project, he's also been dormant > on > the UML side. So far, I've been taking care of uml-utilities > (upstream) maintenance. > > > Please let me know if the diff is okay and I'll then push it to > proposed-updates > > > -- System Information: > Debian Release: bullseye/sid > APT prefers testing > APT policy: (900, 'testing'), (500, 'unstable'), (500, 'stable'), > (1, 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 5.4.0-4-amd64 (SMP w/8 CPU cores) > Kernel taint flags: TAINT_USER > Locale: LANG=en_IN.UTF-8, LC_CTYPE=en_IN.UTF-8 (charmap=UTF-8), > LANGUAGE=en_US (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System diff -Nru uml-utilities-20070815.2/debian/changelog uml-utilities-20070815.3/debian/changelog --- uml-utilities-20070815.2/debian/changelog 2018-12-27 19:31:55.0 +0530 +++ uml-utilities-20070815.3/debian/changelog 2020-02-18 13:39:00.0 +0530 @@ -1,3 +1,18 @@ +uml-utilities (20070815.3-1+deb10u4) buster; urgency=medium + + * Fix long standing issue of port-helper binary not found by the uml +linux binary package + + -- Ritesh Raj Sarraf Tue, 18 Feb 2020 13:39:00 +0530 + +uml-utilities (20070815.3-1) unstable; urgency=medium + + [ New Maintenance Release ] + * Drop Mattia Dongili from Uploaders list (Closes: #933155) + * Use standard path for libray installation. (Closes: #928924) + + -- Ritesh Raj Sarraf Thu, 09 Jan 2020 16:50:07 +0530 + uml-utilities (20070815.2-1) unstable; urgency=medium [ New Maintenance Release ] diff -Nru uml-utilities-20070815.2/debian/control uml-utilities-20070815.3/debian/control --- uml-utilities-20070815.2/debian/control 2018-06-12 09:54:57.0 +0530 +++ uml-utilities-20070815.3/debian/control 2020-01-09 16:43:49.0 +0530 @@ -2,7 +2,7 @@ Section: otherosfs Priority: extra Maintainer: User Mode Linux Maintainers -Uploaders: Mattia Dongili , Ritesh Raj Sarraf +Uploaders: Ritesh Raj Sarraf Build-Depends: debhelper (>> 9.0.0), libreadline-dev, docbook-to-man, libfuse-dev Standards-Version: 3.9.8 Homepage: http://user-mode-linux.sourceforge.net/ diff -Nru uml-utilities-20070815.2/Makefile uml-utilities-20070815.3/Makefile --- uml-utilities-20070815.2/Makefile 2018-12-27 19:24:38.0 +0530 +++ uml-utilities-20070815.3/Makefile 2020-01-06 22:32:02.0 +0530 @@ -5,12 +5,7 @@ UMLVER = $(shell date +%Y%m%d) TARBALL = uml_utilities_$(UMLVER).tar.bz2 BIN_DIR = /usr/bin - -ifeq ($(shell uname -m),x86_64) -LIB_DIR = /usr/lib64/uml -else LIB_DIR = /usr/lib/uml -endif CFLAGS = -g -Wall #CFLAGS = -g -O2 -Wall signature.asc Description: This is a digitally signed message part
Bug#943238: sshuttle: Python2 removal in sid/bullseye
For reference, upgrading this to Python 3 should be simple. sshuttle works fine with Python <= 3.7. BUT: sshuttle is currently incompatible with Python 3.8. See https://github.com/sshuttle/sshuttle/issues/381 Help fixing this appreciated. I don't have a lot of time right now, and this looks like it could be non-trivial to fix. -- Brian May
Bug#951584: found the cause, still need better error logging
In the file /etc/spamassassin/v320.pre the following line was commented out: loadplugin Mail::SpamAssassin::Plugin::Bayes That was what caused the following error: ERROR: the Bayes learn function returned an error, please re-run with -D for more information at /usr/bin/sa-learn line 500. The sa-learn program needs to output better error messages. -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/
Bug#951365: autopkgtest: blocks TL due to warnings of unknown specials
Hi Norbert Thanks for reporting that the autopkgtest fails; ci.d.n is not currently testing packages in unstable and so I'd not seen that this was a problem yet. > The whole point of this bug report is that the warning shipped out is > innocent, but blocks TeX Live packages, and thus are to be honest a > PITA. > > Please either disable these broken autopkgtests, or fix the package to > not emit warnings on these specials. Teaching pyxplot about these new specials is the right thing to do here. The autopkgtests aren't broken, they are correctly catching that pyxplot is generating lots of nasty warnings that the user should not see. I'll take a look at this soon; it's easy enough to make the header special a noop. regards Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#951629: RFS: timeshift/19.01+ds-2.1 [NMU] [RC] -- System restore utility
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "timeshift" * Package name: timeshift Version : 19.01+ds-2.1 Upstream Author : teejee2008(Tony George) * URL : http://teejeetech.blogspot.in/ * License : GPL-3+ * Vcs : https://salsa.debian.org/yanhao-guest/timeshift Section : utils It builds those binary packages: timeshift - System restore utility To access further information about this package, please visit the following URL: https://mentors.debian.net/package/timeshift Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/t/timeshift/timeshift_19.01+ds-2.1.dsc Changes since the last upload: * Non-maintainer upload * Apply upstream fix for bug #948130 Regards, -- Steve Meliza
Bug#951628: RFS: rumur/2020.02.17-1 -- model checker for the Murphi language
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "rumur" * Package name: rumur Version : 2020.02.17-1 Upstream Author : Matthew Fernandez * URL : https://github.com/Smattr/rumur * License : Unlicense * Vcs : https://github.com/Smattr/rumur.git Section : devel It builds those binary packages: rumur - model checker for the Murphi language To access further information about this package, please visit the following URL: https://mentors.debian.net/package/rumur Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/r/rumur/rumur_2020.02.17-1.dsc Changes since the last upload: * New upstream release. . * The installed binary that was previously called rumur-ast-dump is now called murphi2xml, due to an upstream change. . * Update autopkgtest tests to now reference murphi2xml instead of rumur-ast-dump. . * The build test suite now runs single threaded, due to an upstream change, partially addressing #951497. . * Correct watch file to only scan for upstream releases, instead of also matching Debian tags. Regards, Matthew
Bug#951627: isc-dhcp-server: Can't stop the daemon
Package: isc-dhcp-server Version: 4.4.1-2.1 Severity: important In a fairly default configuration with systemd I can't stop the daemon in a normal manner (this happens on Buster as well as Unstable). # /etc/init.d/isc-dhcp-server stop Stopping isc-dhcp-server (via systemctl): isc-dhcp-server.service. (sysadm_t:s0-s0:c0.c1023)root@unstable:/var/log# ps aux|grep dhcp root 841 0.0 1.1 13520 9316 ?Ss 04:27 0:00 /usr/sbin/dhcpd -4 -q -cf /etc/dhcp/dhcpd.conf # ls -l /run/dhcpd.pid -rw-r--r--. 1 root root 4 Feb 19 04:27 /run/dhcpd.pid To stop it properly (so it can be restarted again) I have to manually kill the process and rm the pid file. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-8-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: default Versions of packages isc-dhcp-server depends on: ii debconf [debconf-2.0] 1.5.73 ii debianutils4.9.1 ii libc6 2.29-10 ii libdns-export1107 1:9.11.14+dfsg-3 ii libirs-export161 1:9.11.14+dfsg-3 ii libisc-export1104 1:9.11.14+dfsg-3 ii lsb-base 11.1.0 Versions of packages isc-dhcp-server recommends: ii isc-dhcp-common 4.4.1-2.1 ii policycoreutils 3.0-1 Versions of packages isc-dhcp-server suggests: pn isc-dhcp-server-ldap pn policykit-1 -- Configuration Files: /etc/dhcp/dhcpd.conf changed [not included] -- debconf information excluded
Bug#918720: /var/lib/dhcp/dhcpd6.leases
Also you need to do the same thing for /var/lib/dhcp/dhcpd6.leases -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/
Bug#918720: What's the situation with this?
Yes using touch to create the file looks like the correct solution to this problem. Probably should unconditionally create the file with touch as there's no reason not to have it. Maybe use install so you can easily set the correct permissions on the file. -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/
Bug#944553: midori deletes my files
Control: tags -1 + more-info On Monday, November 11 2019, pete wrote: > Dear Maintainer, > >I have some problems with MIME associations (browsers such as midori and > epiphany try to download local htm files instead of opening them), and I > encountered > this bug while solving these problems. >I ran mimeopen -d tmpa_crtoef.htm, selected midori and launched it. Same > thing > happens if I run midori tmpa_crtoef.htm. >midori tried to download this file, did not open it, and this file > disappeared. I > had to copy this file to the current directory and set chattr +i on it to > prevent > midori from deleting it. Epiphany also tries to download the file instead of > opening it, but it remains in place. Please do not delete my files! Thanks. Thanks for the report. It's not clear from your description whether tmpa_crtoef.htm is the only file that triggers this behaviour, or if this happens with any file when you try opening it with Midori. I gave it a quick try with a simple file here and could not reproduce the issue: $ cat 1.htm $ midori 1.htm $ ls 1.htm 1.htm Can you provide more details, please? For example, can you reproduce this with any HTML file, or just with a specific one? If the latter, can you provide this file? Thanks, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/ signature.asc Description: PGP signature
Bug#951626: pdbg: copyright issues
Source: pdbg Version: 2.0-1 Hello, I found some issues with d/copyright when reviewing this package in NEW. ccan/list/* does not have copyright years specified -- copyright is always something time-limited. However, not a licence violation, as no copyright assertions in the source. Copyright years for IBM should include 2013-2014, 2017-2018. Gibson's copyright on libfdt/* should be 2006, 2012 not 2006-2012. It would be best to list the names of the authors of ccan/* in the Copyright: field for that directory, but since the code is public domain, it's not required. -- Sean Whitton signature.asc Description: PGP signature
Bug#949914: propellor ftbfs in unstable in a binNMU
control: tag -1 + moreinfo control: severity -1 important Hello Matthias, On Mon 27 Jan 2020 at 01:13AM +01, Matthias Klose wrote: > Package: src:propellor > Version: 5.10.1-1 > Severity: serious > Tags: sid bullseye > > uninstallable build dependencies: > > propellor build-depends on: > - libghc-type-errors-dev:amd64 > libghc-type-errors-dev depends on missing: > - libghc-first-class-families-dev-0.5.0.0-6bce0:amd64 I can't reproduce this. I seem to be able to rebuild the source package in sid, using `sbuild --no-arch-all` (my attempt to emulate a binNMU). Could you say more about how you ran into this problem, please? -- Sean Whitton signature.asc Description: PGP signature
Bug#951625: kde: Switch Displays not working
Package: kde Version: kde-plasma-desktop Severity: normal Dear Maintainer, I am using KDE on a Debian mixed testing/buster system. Until recently, plugging / unplugging the HDMI cable, or pressing Fn+F8(display) on my laptop keyboard, would pop up the switch displays pop up and allow me to choose how to use an external monitor. Recently this has stopped happening. Instead Debian assumes that i want to stretch the display across both monitors (which is not what I want to do). I have to force mirroring of displays using 'xrandr' in my .profile, choose my external monitor as the Primary Screen from Displays, and then manually restart plasmashell in order to get a full desktop. The shortcut combination in Global Shortcuts (Meta+P) also has no effect. I tried changing the shortcut to another combination, still no effect. Thank you for all your hard work! *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (900, 'testing'), (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#948947: gnome-builder: fails to run built application
Found the solution! Manually starting xdg-document-portal works; explained here https://github.com/flatpak/flatpak/issues/1359#issuecomment-455280209 systemctl start --user xdg-document-portal Checking the service status, I noticed it was not running on fresh login. The current workaround is to manually start it.
Bug#950104: Bug#951046: ibus: Numpad not working in GDM lockscreen when ibus installed in Stretch
Control: reopen 950104 Oops, I'm sorry. It was a typo.
Bug#951428: Re: RFS: ukui-sidebar/1.0.0-1 [ITP] -- parallels toolbox for UKUI
Hi, Boyuan, I will rename the desktop file in the new version of ukui-sidebar, thanks a lot for the sponsorship, :) Regards, handsome_feng 在2020年02月19 01时43分，"Boyuan Yang"写道： Hi, On Sun, 16 Feb 2020 21:57:56 +0800 handsome_feng wrote: > Package: sponsorship-requests > Severity: wishlist > > Dear mentors, > > I am looking for a sponsor for my package "ukui-sidebar" > > * Package name: ukui-sidebar >Version : 1.0.0-1 Uploaded, thanks. One more thing: please consider renaming the "sidebar.desktop" file -- this name is too generic. A better choice would be "ukui-sidebar.desktop". -- Thanks, Boyuan Yang
Bug#951623: [swig] error on ruby 2.7
Package: swig Severity: normal --- Please enter the report below this line. --- I had an error on mecab package building for ruby 2.7. https://buildd.debian.org/status/fetch.php?pkg=mecab=amd64=0.996-9%2Bb1=1582046522=0 It is caused by ambiguous definition of rb_define_virtual_variable. It had already reported on the upstream, may be the following link is workaround. https://github.com/swig/swig/issues/1689#issuecomment-569448002
Bug#951624: webdis, build-depends on removed package
Source: webdis Version: 0.1.4+dfsg-1 Severity: serious Tags: bullseye, sid webdis build-depends on the python-msgpack binary package, which is no longer built by the python-msgpack source package. It is still present in unstable as a cruft package, but is completely gone from testing.
Bug#951622: featherpad is unable to open a .txt file and says file not found while pluma is able to and even cat does.
Package: featherpad
Version: 0.12.1-1
Severity: normal
Dear Maintainer,
I had made a .txt file which is/was visible with other editors and
even cat but featherpad claims to say the file is not found. I am
attaching the .txt file as well as the fp.conf which is in ~/.config/
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (900, 'testing'), (500, 'testing-debug'), (100,
'unstable-debug'), (100, 'experimental'), (100, 'unstable'), (50,
'experimental-debug')
Architecture: amd64 (x86_64)
Kernel: Linux 5.4.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE=en_IN:en
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages featherpad depends on:
ii libc62.29-10
ii libgcc-s1 [libgcc1] 10-20200211-1
ii libgcc1 1:10-20200211-1
ii libhunspell-1.7-01.7.0-2+b1
ii libqt5core5a 5.12.5+dfsg-8
ii libqt5gui5 5.12.5+dfsg-8
ii libqt5network5 5.12.5+dfsg-8
ii libqt5printsupport5 5.12.5+dfsg-8
ii libqt5svg5 5.12.5-2
ii libqt5widgets5 5.12.5+dfsg-8
ii libqt5x11extras5 5.12.5-1
ii libstdc++6 10-20200211-1
ii libx11-6 2:1.6.8-1
Versions of packages featherpad recommends:
ii featherpad-l10n 0.12.1-1
ii libglib2.0-bin 2.62.4-2
featherpad suggests no packages.
-- no debconf information
--
Regards,
Shirish Agarwal शिरीष अग्रवाल
My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C
General
Unique ID:
6513718343436012467748006650727696220 (0x4E67F1BFAE94B21E88429D1492D075C)
Complete name: Chicken Girls S01E06 (Stronger in
Numbers) 720p WEB X264 Solar.mkv
Format : Matroska
Format version : Version 4
File size: 215 MiB
Duration : 16 min 52 s
Overall bit rate : 1 780 kb/s
Encoded date : UTC 2020-01-30 12:46:55
Writing application : mkvmerge v43.0.0 ('The
Quartermaster') 64-bit
Writing library : libebml v1.3.10 + libmatroska v1.5.2
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L3.1
Format settings : CABAC / 5 Ref Frames
Format settings, CABAC : Yes
Format settings, Reference frames: 5 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 16 min 52 s
Bit rate : 1 649 kb/s
Width: 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth: 8 bits
Scan type: Progressive
Bits/(Pixel*Frame) : 0.075
Stream size : 199 MiB (93%)
Default : Yes
Forced : No
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709
Audio
ID : 2
Format : AAC LC
Format/Info : Advanced Audio Codec Low Complexity
Codec ID : A_AAC-2
Duration : 16 min 52 s
Bit rate : 128 kb/s
Channel(s) : 2 channels
Channel layout : L R
Sampling rate: 48.0 kHz
Frame rate : 46.875 FPS (1024 SPF)
Compression mode : Lossy
Stream size : 15.5 MiB (7%)
Title: English
Language : English
Default : Yes
Forced : No
Text
ID : 3
Format : UTF-8
Codec ID : S_TEXT/UTF8
Codec ID/Info: UTF-8 Plain Text
Duration : 16
Bug#951621: ITP: xow - Linux driver for the Xbox One wireless dongle
Package: wnpp Owner: "Samuel Henrique" Severity: wishlist User: samuel...@debian.org * Package name: xow * URL : https://github.com/medusalix/xow * License : GPL-2+ and Custom_LIcense Programming Lang: C Description : xow is a Linux user mode driver for the Xbox One wireless dongle. It communicates with the dongle via libusb and provides joystick input through the uinput kernel module. The input mapping is based on existing kernel drivers like xpad. This package will go into the non-free section as there's a blob for the Mediatek chipset: firmware.bin For more info about the blob, see issue at: https://github.com/medusalix/xow/issues/15 This blob is licensed under a custom license from Mediatek, as also described in the issue. -- Samuel Henrique
Bug#951577: Bubblewrap upstream-as-root test fails with libcap2 1:2.31-1 and later
Control: forwarded -1 https://github.com/containers/bubblewrap/issues/353 On 18.02.20 23:59, Christian Kastner wrote: > I therefore believe that bubblewrap's test suite must be updated, so > reassigning to bubblewrap. FYI, I just checked GitHub (which I should have checked first...) and there's already an issue opened for bubblewrap.
Bug#951577: Bubblewrap upstream-as-root test fails with libcap2 1:2.31-1 and later
Control: reassign -1 bubblewrap On 18.02.20 11:49, Lukasz Zemczak wrote: > Package: libcap2 > Version: 1:2.32-1 > > The bubblewrap upstream-as-root test started failing after libcap2 > 1:2.31-1 got synced from Debian. The same failure can be seen with > 1:2.32-1. I have reproduced the issue locally on focal - when using > the focal-proposed version, the aforementioned test fails, where with > the release version (after reverting libcap2 to 1:2.27-1) it passes. > > It seems to fail here already: > bwrap --bind / / --tmpfs /tmp --as-pid-1 --cap-drop CAP_KILL > --cap-drop CAP_FOWNER --unshare-pid capsh --print > assert_not_file_has_content caps.test '^Current: =.*cap_kill' > > It looks like the requested caps did not get dropped, as the logs show > that both cap_kill and cap_fowner are still there. This is only for > the upstream-as-root test, i.e. executing tests/test-run.sh as root.> > This might be an issue with bubblewrap, but seeing that it all works > fine with the release version, it all feels like an unintended > regression. I believe that this is just a side effect of how changes to how libcap prints capabilities, probably caused by this commit [1]. I just tested this on a bullseye system with 2.27 (for brevity, I replaced all other capabilities with "..."): root@bullseye:~# capsh --print Current: = cap_chown,...,cap_audit_read+ep Bounding set =cap_chown,...,cap_audit_read Compare this to a sid system with 2.32: root@sid:~# capsh --print Current: =ep Bounding set =cap_chown,...,cap_audit_read The difference is in agreement with the commit message of [1], and according to the most recent cap_from_text(3), reads as "set all capabilities in the effective (e) and inherited (p) sets". Now note the output of your failed command: > bwrap --bind / / --tmpfs /tmp --as-pid-1 --cap-drop CAP_KILL > --cap-drop CAP_FOWNER --unshare-pid capsh --print > assert_not_file_has_content caps.test '^Current: =.*cap_kill' with 2.27, Current: = cap_chown,xxx,cap_audit_read+eip where xxx are all capabilities except the dropped CAP_KILL and CAP_FOWNER, and with 2.32, Current: =eip cap_fowner,cap_kill-eip which, according to the most recent cap_from_text(3), reads as "start with all capabilities, and remove cap_fowner,cap_kill". So exactly what the test seems to attempt. I therefore believe that bubblewrap's test suite must be updated, so reassigning to bubblewrap. [1] https://git.kernel.org/pub/scm/libs/libcap/libcap.git/commit/?id=afef3ef1c62613e1cac12a2bbec6017f7d5e033e Regards, Christian
Bug#562727:
שלחתי לך דואר לפני מספר ימים אך אין תגובה, אנא השב לי
Bug#951280: fixed in ncbi-blast+ 2.9.0-4
A release inbuster-backports would be fine for me. Whatever it is ok now that I have rebuilt it from source applying the same change in the debian/rules file. Finally it is working. Thanks again, Patrice On Mon, 17 Feb 2020 20:46:32 -0500 u...@debian.org (Aaron M. Ucko) wrote: > That's a fair request. From a technical perspective, it should be > straightforward (the same change should work there), but I'll need to > get official approval from the Release Team. There's also a version of > ncbi-blast+ in buster-backports that I should be able to fix more > readily, but I can understand if you'd rather leave backports alone. > > Thanks for asking, and sorry you ran into trouble here. > > -- Aaron > > Patrice Duroux writes: > > > Hi, > > > > Thanks for the work. > > But is there any plan to solve it for ncbi-blast+ in Buster for which the bug > > report was addressed initially? > > Do I have to mix Buster / Sid on my system? > > > > Thanks, > > Patrice > > > > On Mon, 17 Feb 2020 01:50:53 + Debian FTP Masters < > > ftpmas...@ftp-master.debian.org> wrote: > >> Source: ncbi-blast+ > >> Source-Version: 2.9.0-4 > >> Done: u...@debian.org (Aaron M. Ucko) > >> > >> We believe that the bug you reported is fixed in the latest version of > >> ncbi-blast+, which is due to be installed in the Debian FTP archive. > >> > >> A summary of the changes between this version and the previous one is > >> attached. > >> > >> Thank you for reporting the bug, which will now be closed. If you > >> have further comments please address them to 951...@bugs.debian.org, > >> and the maintainer will reopen the bug report if appropriate. > >> > >> Debian distribution maintenance software > >> pp. > >> Aaron M. Ucko (supplier of updated ncbi-blast+ package) > >> > >> (This message was generated automatically at their request; if you > >> believe that there is a problem with it please contact the archive > >> administrators by mailing ftpmas...@ftp-master.debian.org) > >> > >> > >> -BEGIN PGP SIGNED MESSAGE- > >> Hash: SHA256 > >> > >> Format: 1.8 > >> Date: Sun, 16 Feb 2020 20:16:33 -0500 > >> Source: ncbi-blast+ > >> Architecture: source > >> Version: 2.9.0-4 > >> Distribution: unstable > >> Urgency: high > >> Maintainer: Debian Med Packaging Team < > > debian-med-packag...@lists.alioth.debian.org> > >> Changed-By: Aaron M. Ucko
Bug#888705: abseil-cpp packaging
On Tuesday, February 18, 2020, at 9:01 PM +0100, László Böszörményi (GCS) wrote: > There's a compatibility page[1] what Abseil is and isn't. It states > the following things. > "We do not promise any ABI compatibility — we intend for Abseil to be > built from source, hopefully from head. The internal layout of our > types may change at any point, without notice." > As I read waiting for LTS releases might be late (its head commit > version advised to be used). I guess other Google applications other > libraries commonly wants newer Abseil releases than LTS ones. I think that’s accurate. The culture at Google emphasizes continuous integration from head rather than coding against releases. However, this isn’t just about Google applications. There are other F/OSS projects that want to take an Abseil dependency and aren’t ready to commit to that sort of development model – see, for instance, https://github.com/darktable-org/rawspeed/issues/122 (“Stop reinventing the wheel”), in which Darktable investigates taking an Abseil dependency and decides to wait until the LTS story is fully hammered out. The Abseil team understands that the F/OSS world expects stable ABIs; they’re going to break ABI all over the place at head, but they’re not going to go out of their way to break it within an LTS release. > "Not all Abseil libraries are suitable for dynamic loading. Some > libraries have startup/initialization requirements and may not be > suitable for dynamic loading. We will try to be clear about which > libraries are OK for dynamic loading. However we don’t generally > deploy code in this fashion, mistakes are possible, [...]". > That is, even shared libraries can be built, those are not guaranteed to work. I don’t think we should shy away from providing functionality just because upstream doesn’t guarantee it to work. It’s true that the Abseil developers don’t test Abseil as .so’s, but testing exists in Debian for a reason. If Debian ships an Abseil .so, and bugs appear in testing, we can work with upstream to fix them or patch them ourselves if upstream is nonresponsive. I did discuss the initialization issues with an Abseiler today; he doesn’t know the full story, but he knows somebody within Abseil is working on making initialization more lazy (and therefore more .so-compatible). If you’re interested, I can discuss that with them at our next meeting and let you know what the story is. > I think there should be a compatibility matrix or test if the latest > LTS release is enough for most Google applications or those need newer > versions (no new API added for recent application development). Agreed – there should definitely be some testing involved. For what it’s worth, the next LTS is likely to be cut from head before the end of the week. For a little while afterward, at least, nobody should need anything newer than what’s in the LTS. On Sunday, February 16, 2020, at 10:48 PM +0100, László Böszörményi (GCS) wrote: >>> @Benjamin: may you ask its developers to use the system gtest libraries >>> if only ABSL_RUN_TESTS set to ON? On Monday, February 17, 2020, at 8:21 PM -0500, Benjamin Barenblat wrote: >> Absolutely. I’ll bring it up with them at work tomorrow (today was a US >> holiday). I spoke with an Abseiler today about this. He believes that Abseil definitely needs to support that, but there’s still some consensus-building that needs to happen within the team before we can guarantee that upstream will take a patch for it. I have a preliminary version of such a patch, and I’ll try to get it finished and sent in the next day or two; that way, even if upstream lags taking it, we can import it and get the support we need.
Bug#888705: abseil-cpp packaging
On Tuesday, February 18, 2020, at 9:25 AM +0100, Olaf van der Spek wrote: > What about the C++ std version? Abseil / C++14 isn't the same as Abseil / > C++17. This is true on two levels: 1. By default, Abseil detects what standard version you’re building with and conditionally defines its types to be type aliases when appropriate. For instance, in C++11, `absl::make_unique` is an actual function; in C++14 and later, `absl::make_unique` is an alias for `std::make_unique`. The next LTS release will have a CMake toggle you can set to disable this behavior, I think it would be most user-friendly for us to set it. It’s less efficient to ship an Abseil in which `absl::make_unique` is always an actual function, but I think it’s better than shipping an Abseil that can only be used with one version of the C++ standard. 2. Abseil may use some language features that changed semantics in C++17 and are therefore ABI-incompatible with translation units compiled against a different standard. I spoke with an Abseil developer about this today, and he believes it’s not likely to be an issue. Abseil does not plumb the depths of the C++ language spec (except possibly the template engine), so provided (1) is resolved, it’s entirely possible that a binary Abseil will work everywhere. We won’t really know until we package it and let it soak in testing for a while.
Bug#948576: Update - tested with 5.5.4
Hi everybody, I have rebased my patch on 5.5.4-1~exp1 from the packaging master branch. While at it I have also cleaned it up removing any options that were implicitly selected, leaving only those that really need to be enabled manually. Boot tested, everything that worked before still does, namely the standalone ethernet port, USB, microSD and eMMC. Please consider enabling these config options - The device-tree for the Honeycomb Workstation has been merged with 5.6-rc1 and it would be great to have Debian work as pieces start landing upstream. Yours sincerely Josua Mayer >From 17590120f8352874ba1b7c686c3c3fd46c0c Mon Sep 17 00:00:00 2001 From: Josua Mayer Date: Tue, 18 Feb 2020 21:36:40 +0100 Subject: [PATCH] enable support for the Honeycomb arm64 workstation This enables support for the Layerscape architecture in general, as well as - drivers for the Soc listed in (fsl-lx2160a.dtsi) - drivers for peripherals listed in (fsl-lx2160a-cex7.dtsi) . Signed-off-by: Josua Mayer --- debian/config/arm64/config | 47 ++ 1 file changed, 47 insertions(+) diff --git a/debian/config/arm64/config b/debian/config/arm64/config index a2638cf1307a..0796f1fd3f59 100644 --- a/debian/config/arm64/config +++ b/debian/config/arm64/config @@ -56,6 +56,7 @@ CONFIG_KVM=y CONFIG_ARCH_SUNXI=y CONFIG_ARCH_BCM2835=y CONFIG_ARCH_HISI=y +CONFIG_ARCH_LAYERSCAPE=y CONFIG_ARCH_MESON=y CONFIG_ARCH_MVEBU=y CONFIG_ARCH_QCOM=y @@ -100,6 +101,7 @@ CONFIG_ANDROID=y CONFIG_SATA_AHCI_PLATFORM=m CONFIG_AHCI_CEVA=m CONFIG_AHCI_MVEBU=m +CONFIG_AHCI_QORIQ=m CONFIG_AHCI_TEGRA=m CONFIG_AHCI_XGENE=m CONFIG_SATA_AHCI_SEATTLE=m @@ -117,6 +119,11 @@ CONFIG_HISILICON_LPC=y CONFIG_QCOM_EBI2=y CONFIG_TEGRA_ACONNECT=y +## +## file: drivers/bus/fsl-mc/Kconfig +## +CONFIG_FSL_MC_BUS=y + ## ## file: drivers/char/hw_random/Kconfig ## @@ -182,6 +189,7 @@ CONFIG_SUN8I_DE2_CCU=y CONFIG_CPU_FREQ_DEFAULT_GOV_SCHEDUTIL=y ## end choice CONFIG_CPUFREQ_DT=m +CONFIG_QORIQ_CPUFREQ=m ## ## file: drivers/cpufreq/Kconfig.arm @@ -203,6 +211,11 @@ CONFIG_CRYPTO_DEV_QCE=m CONFIG_CRYPTO_DEV_QCOM_RNG=m CONFIG_CRYPTO_DEV_SAFEXCEL=m +## +## file: drivers/crypto/caam/Kconfig +## +CONFIG_CRYPTO_DEV_FSL_DPAA2_CAAM=m + ## ## file: drivers/crypto/cavium/cpt/Kconfig ## @@ -249,6 +262,7 @@ CONFIG_QCOM_HIDMA=m ## file: drivers/edac/Kconfig ## CONFIG_EDAC=y +CONFIG_EDAC_LAYERSCAPE=m CONFIG_EDAC_THUNDERX=m CONFIG_EDAC_XGENE=m @@ -278,6 +292,7 @@ CONFIG_GPIO_ZYNQ=m CONFIG_GPIO_PCA953X=y CONFIG_GPIO_PCA953X_IRQ=y CONFIG_GPIO_MAX77620=y +CONFIG_GPIO_MPC8XXX=y ## ## file: drivers/gpu/drm/Kconfig @@ -388,6 +403,7 @@ CONFIG_I2C_HID=m ## ## file: drivers/hwmon/Kconfig ## +CONFIG_SENSORS_LM90=m CONFIG_SENSORS_XGENE=m ## @@ -406,6 +422,7 @@ CONFIG_I2C=y CONFIG_I2C_BCM2835=m CONFIG_I2C_DESIGNWARE_PLATFORM=m CONFIG_I2C_GPIO=m +CONFIG_I2C_IMX=m CONFIG_I2C_MESON=m CONFIG_I2C_MV64XXX=m CONFIG_I2C_PXA=m @@ -418,6 +435,11 @@ CONFIG_I2C_XLP9XX=m CONFIG_I2C_CROS_EC_TUNNEL=m CONFIG_I2C_XGENE_SLIMPRO=m +## +## file: drivers/i2c/muxes/Kconfig +## +CONFIG_I2C_MUX_PCA954x=m + ## ## file: drivers/iio/accel/Kconfig ## @@ -560,6 +582,7 @@ CONFIG_MMC_QCOM_DML=y CONFIG_MMC_SDHCI_ACPI=m CONFIG_MMC_SDHCI_PLTFM=m CONFIG_MMC_SDHCI_OF_ARASAN=m +CONFIG_MMC_SDHCI_OF_ESDHC=m CONFIG_MMC_SDHCI_TEGRA=m CONFIG_MMC_SDHCI_F_SDH30=m CONFIG_MMC_SDHCI_IPROC=m @@ -666,6 +689,18 @@ CONFIG_NET_VENDOR_DLINK=y CONFIG_SUNDANCE=m # CONFIG_SUNDANCE_MMIO is not set +## +## file: drivers/net/ethernet/freescale/Kconfig +## +CONFIG_FSL_XGMAC_MDIO=m +CONFIG_NET_VENDOR_FREESCALE=y + +## +## file: drivers/net/ethernet/freescale/dpaa2/Kconfig +## +CONFIG_FSL_DPAA2_ETH=m +CONFIG_FSL_DPAA2_PTP_CLOCK=m + ## ## file: drivers/net/ethernet/hisilicon/Kconfig ## @@ -967,6 +1002,11 @@ CONFIG_AXP288_FUEL_GAUGE=m CONFIG_CHARGER_QCOM_SMBB=m CONFIG_CHARGER_CROS_USBPD=m +## +## file: drivers/ptp/Kconfig +## +CONFIG_PTP_1588_CLOCK_QORIQ=m + ## ## file: drivers/pwm/Kconfig ## @@ -1030,6 +1070,7 @@ CONFIG_RTC_DRV_ARMADA38X=m CONFIG_RTC_DRV_PM8XXX=m CONFIG_RTC_DRV_TEGRA=y CONFIG_RTC_DRV_XGENE=y +CONFIG_RTC_DRV_PCF2127=m ## ## file: drivers/scsi/Kconfig @@ -1042,6 +1083,11 @@ CONFIG_SCSI_DMX3191D=m CONFIG_SCSI_HISI_SAS=m CONFIG_SCSI_HISI_SAS_PCI=m +## +## file: drivers/soc/fsl/Kconfig +## +CONFIG_FSL_MC_DPIO=m + ## ## file: drivers/soc/bcm/Kconfig ## @@ -1075,6 +1121,7 @@ CONFIG_SPI_ARMADA_3700=m CONFIG_SPI_BCM2835=m CONFIG_SPI_BCM2835AUX=m CONFIG_SPI_MESON_SPIFC=m +CONFIG_SPI_NXP_FLEXSPI=m CONFIG_SPI_ROCKCHIP=m CONFIG_SPI_QUP=m CONFIG_SPI_TEGRA114=m -- 2.25.0
Bug#856179: ITP: polybar -- fast and easy-to-use status bar
Control: owner -1 ! On Mon, 27 Jan 2020 at 13:41, Jason Pleau wrote: > > I pushed what I had here: https://gitlab.com/jpleau/polybar/ > > It's not targetting debian (simply because I'm using ubuntu these > days). Feel free to take whatever you find useful Thanks for that Jason, I pushed the current state of the packaging to salsa. I will be doing the upload the the NEW queue soon, I just want to do some extra checks and tests to confirm everything is ok. Regards, -- Samuel Henrique
Bug#951208: fuse3's backwards compatibilty (Re: Bug#951208: Impossible to mount over nonempty directories)
I've used non-empty mountpoints a few times, mostly when mounting a directory onto itself, but I have no idea how popular that use case really is. Mounting to a new empty location is probably always possible, but it's sometimes quite undesirable or inconvenient: - Sometimes I want to enforce certain rules on a directory and hide the original directory to prevent confusion and misuse. - Sometimes I want to quickly test something on an existing directory, and a program I want to use might be configured or even hard-coded to use that specific directory. So I think this is worth fixing. Here's my current understanding (I was a bit confused in my initial response): - The scope: bindfs seems to work fine with libfuse2 and fuse3 EXCEPT for `nonempty`. The test suite, which tests most other features, passes on Debian 10 with fuse3 installed. - The bug: libfuse2 checks that the destination is empty or `nonempty` is given. Then it invokes fusermount (symlinked to fusermount3), which doesn't accept `nonempty`. - bindfs cannot be compiled against libfuse3. That would require significant code changes. So it seems backwards compatibility between fusermount3 and libfuse2 was intended, and this is a bug there. If so, here are the "easy" fixes I can think of: 1. patch fusermount3 to accept and ignore `nonempty` (perhaps only when invoked through a symlink named fusermount?) or 2. patch libfuse2 to stop requiring `nonempty` (or passing it to fusermount when it's symlinked to fusermount3?) or 3. instead of symlinking fusermount -> fusermount3, make it a wrapper script that drops `nonempty` from any option list like `-o option1,nonempty,option2,...` If someone who knows FUSE better can point out something simple I can do in bindfs code instead, I'd be happy to write a short patch. But there may be other FUSE 2 filesystems designed to "wrap" an existing directory that also have this bug, so I think fixing this at the FUSE layer is better. On Tue, 18 Feb 2020 at 15:12, Eugene V. Lyubimkin wrote: > Hello, > > Martin Pärtel kirjoitti 17.2.2020 klo 10.49: > > I'm unfortunately unlikely to have time to port bindfs to FUSE 3 in the > near future :( > > > > The easiest distro-level workaround in terms of "least code required" > would probably be to patch fuse3's fusermount to > > allow and ignore `nonempty` (and maybe print a deprecation warning). Or > some hacks could probably be invented to direct > > FUSE 2 filesystems to use FUSE 2 helpers. It's up to the Debian > maintainers whether they want the maintenance burder of > > either of these workarounds. > > CC'ing FUSE's maintainer for extra input if any. > > > From the discussion above I gather that bindfs is still (with limitations) > usable with fuse3. If true, then I wouldn't > like to block users of fuse3 from using bindfs via strict Depends. I could > add Suggests or Recommends on fuse2, > though. > > How common of a use case is to use bindfs with a non-empty mount point? I > never mounted filesystems like that myself, so > I don't know if it's a minor nuisance with an easy workaround, or a > significant limitation making some use case > unachievable. > > > Regards, > -- > Eugene V. Lyubimkin aka JackYF > C++ GNU/Linux userspace developer, Debian Developer > >
Bug#908117: RFP: yq -- yq is a lightweight and portable command-line YAML processor The aim of the project is to be the jq or sed of yaml files.
Hi guys, I see this thread in ITP status. However, I wonder if this is still in process of being packaged. I've been maintaining the deb packages for such yq tool at my ppa (https://launchpad.net/~rmescandon/+archive/ubuntu/ppa/) but I wanted to step forward a little bit more by polishing and formatting everything that is needed for having yq into the debian upstream. Could it be possible for me to take this ITP thread and give it a go? @ChangZhuo, @Varac: What do you think? Can I take the handover? Thanks in advance
Bug#951620: clips: fails to migrate to testing for too long
Source: clips Version: 6.24-3.2 Severity: serious Control: fixed -1 6.30-4 Tags: sid bullseye User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), As recently announced [1], the Release Team now considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug. Your package src:clips in its current version in unstable has been trying to migrate for 834 days. Hence, I am filing this bug. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html signature.asc Description: OpenPGP digital signature
Bug#951619: avahi: New upstream release (0.8)
Source: avahi Version: 0.7-5 Severity: wishlist Hello, There's a new upstream release of avahi available now, see: https://alioth-lists.debian.net/pipermail/pkg-utopia-maintainers/2020-February/027450.html I've updated my previous work on python3 conversion of avahi from the previous upstream snapshot to the new 0.8 release (and rebased it on top of the 0.7-5 changes that has gone into the official packaging repo since). My work is available at: https://salsa.debian.org/ah/avahi Please note that this is only build-tested. I've likely done some mistake somewhere so would be great if someone could review this before merging it into the utopia-team repo. Regards, Andreas Henriksson
Bug#948855: buster-pu: package iputils/3:20180629-2
Control: tags -1 + confirmed On Wed, 2020-02-12 at 14:13 -0500, Noah Meyerhans wrote: > Control: tags -1 -moreinfo > > On Tue, Jan 28, 2020 at 10:11:23PM +, Adam D. Barratt wrote: > > > > > I'd like to fix > > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947921 in > > > > > buster. Ping has some issues coping with explicitly > > > > > specified > > > > > source interfaces when pinging DNS names and DNS returns > > > > > multiple > > > > > addresses via getaddrinfo(). Please see the commit messages > > > > > and > > > > > the bug report for in-depth explanation of what's going on. > > > > > > > > The metadata for that bug report suggests that it affects the > > > > iputils package in unstable, and is not currently fixed there. > > > > Is > > > > that correct? > > > > > > That's correct. Upstream has not yet made a release containing > > > the > > > fix, nor have I backported it to the version currently in testing > > > (there are enough changes to make that nontrivial). I am making > > > my > > > request based on the patch author's report that it does, indeed, > > > fix > > > the problem in buster, and the fact that the fix has been > > > accepted > > > upstream. > > > > > > If you'd prefer, we can wait until the next buster point release, > > > by > > > which time we'll presumably have more testing of these patches. > > > > In general our workflow is for patches to be applied to unstable > > first > > where appropriate, so that sounds like the best approach; thanks > > for > > confirming. > > iputils with the applied fixes is now in sid and bullseye. I'd like > to get this into the next buster update. > Thanks; please go ahead. Regards, Adam
Bug#950056: Breaking change in python 3.7/3.8 to be reverted
On Tue, 28 Jan 2020 20:20:51 +0200 Adrian Bunk wrote: > Source: python-bleach > Version: 3.1.0-2 > Severity: serious > Tags: ftbfs > Forwarded: https://github.com/mozilla/bleach/issues/503 > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/python-bleach.html > > ... We'll see this issue again once python3.9 is a supported version, so I'll leave this open, but lower the severity once the breaking change is reverted in python3.8. Scott K signature.asc Description: This is a digitally signed message part.
Bug#950666: [Pkg-javascript-devel] Bug#950666: node-terser FTBFS: test failures
Hi On Wed, 05 Feb 2020 13:41:37 +0100 Jonas Smedegaard wrote: > control: tags -1 +confirmed > control: retitle -1 node-terser FTBFS: fails 7 tests in "bin/uglifyjs" and "bin/uglifyjs with input file globs" > > Quoting Adrian Bunk (2020-02-04 16:29:34) > > Source: node-terser > > Version: 4.1.2-4 > > Severity: serious > > Tags: ftbfs > > > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/node-terser.html > > > > ... > > 231 passing (47s) > > 4 pending > > 7 failing > > > > 1) bin/uglifyjs (2) > > Should dump AST as JSON: > > Uncaught Command failed: "/usr/bin/node" bin/uglifyjs test/input/global_defs/simple.js -mco ast > > ERROR: ENOENT: no such file or directory, open 'ast' > > at Object.openSync (fs.js:443:3) > > at Object.readFileSync (fs.js:343:35) > > at read_file (/build/1st/node-terser-4.1.2/bin/uglifyjs:353:19) > > at /build/1st/node-terser-4.1.2/bin/uglifyjs:176:37 > > at Array.forEach () > > at Object. (/build/1st/node-terser-4.1.2/bin/uglifyjs:175:28) > > at Module._compile (internal/modules/cjs/loader.js:778:30) > > at Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10) > > at Module.load (internal/modules/cjs/loader.js:653:32) > > at tryModuleLoad (internal/modules/cjs/loader.js:593:12) > > > > Error: Command failed: "/usr/bin/node" bin/uglifyjs test/input/global_defs/simple.js -mco ast > > ERROR: ENOENT: no such file or directory, open 'ast' > > at Object.openSync (fs.js:443:3) > > at Object.readFileSync (fs.js:343:35) > > at read_file (bin/uglifyjs:353:19) > > at /build/1st/node-terser-4.1.2/bin/uglifyjs:176:37 > > at Array.forEach () > > at Object. (bin/uglifyjs:175:28) > > at Module._compile (internal/modules/cjs/loader.js:778:30) > > at Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10) > > at Module.load (internal/modules/cjs/loader.js:653:32) > > at tryModuleLoad (internal/modules/cjs/loader.js:593:12) > > > > at ChildProcess.exithandler (child_process.js:294:12) > > at maybeClose (internal/child_process.js:982:16) > > at Process.ChildProcess._handle.onexit (internal/child_process.js:259:5) > > ... > > Thanks for reporting! > > Tag as confirmed (corresponds with local cowbuilder build). > > Update bug title to disambiguate from similar but possibly different > issue discussed in JavaScript team (not yet formally reported). I have fixed it to build along with passing autopkgtests and there are no lintian warnings + errors as well. Also fixed the other bug #950733 associated with the package.(I tried emulating your changes in node-uglify here). I have pushed the changes to my local fork here[1]. Needs review and sponsorship. [1]: https://salsa.debian.org/gi-boi-guest/node-terser/ Thanks and regards, Nilesh > > - Jonas > > -- > * Jonas Smedegaard - idealist & Internet-arkitekt signature.asc Description: OpenPGP digital signature
Bug#949029: Processed: reassign 949029 to python3.8
Revert is being done upstream for python 3.8.2: https://bugs.python.org/msg361815 Since it appears this is going to be solved in python3.8, I'm going to reassign again. Please don't reassign back, there's no point. There's another open bug against ptyhon-bleach for this. Scott K signature.asc Description: This is a digitally signed message part.
Bug#950765: nvidia-settings-legacy-340xx 340.108-1~deb10u1 flagged for acceptance
package release.debian.org tags 950765 = buster pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian buster. Thanks for your contribution! Upload details == Package: nvidia-settings-legacy-340xx Version: 340.108-1~deb10u1 Explanation: new upstream release
Bug#951618: kid3-core should depend on libqt5multimedia5-plugins instead of libqt5multimedia5
Package: kid3 libqt5multimedia5 is not enough for kid3-qt to play music files. I had to manually install libqt5multimedia5-plugins because it has the GStreamer plugin to play music files.
Bug#951487: The autopkgtests are failing with 0.53.1
On Mon, Feb 17, 2020 at 1:15 PM Sebastien Bacher wrote: > The autopkgtests are failing with the current version > https://ci.debian.net/data/autopkgtest/testing/amd64/m/meson/4301958/log.gz This should be fixed in 0.53.2 that should be released shortly (was going to be today but probably won't be).
Bug#950684: systemd: upgrade fails in a chroot where /var/log/ owner is not root:root
Control: reassign -1 sbuild Am 18.02.2020 um 21:52 schrieb Jörg Frings-Fürst: > Hi, > > I have the same issue: > > > Build a new chroot with: > > sudo sbuild-createchroot --include=eatmydata,ccache,gnupg > --make-sbuild-tarball=/var/cache/chroot/sid1-amd64-sbuild.tar.gz sid `mktemp > -d` http://deb.debian.org/debian > > > The I build simple-scan/3.34.4-1 > > [quote] > Selecting previously unselected package sbuild-build-depends-dose3-dummy. > Preparing to unpack > .../8-sbuild-build-depends-dose3-dummy_0.invalid.0_amd64.deb ... > Unpacking sbuild-build-depends-dose3-dummy (0.invalid.0) ... > Setting up systemd (244.3-1) ... > Detected unsafe path transition / → /var during canonicalization of > /var/log/journal. > Detected unsafe path transition / → /var during canonicalization of > /var/log/journal. > Detected unsafe path transition / → /var during canonicalization of > /var/log/journal. > Detected unsafe path transition / → /var during canonicalization of > /var/log/journal. That's a slightly different issue. Here / and /var have different permissions. In the original bug report it was /var and /var/log > dpkg: error processing package systemd (--configure): > installed systemd package post-installation script subprocess returned error > exit status 73 > [/quote] > > The same parts from build simple-scan/ > [qoute] > Setting up libcryptsetup12:amd64 (2:2.2.2-1) ... > Setting up systemd (244-3) ... > Created symlink /etc/systemd/system/getty.target.wants/getty@tty1.service → > /lib/systemd/system/getty@.service. > Created symlink /etc/systemd/system/multi-user.target.wants/remote-fs.target > → /lib/systemd/system/remote-fs.target. > Created symlink /etc/systemd/system/dbus-org.freedesktop.timesync1.service → > /lib/systemd/system/systemd-timesyncd.service. > Created symlink > /etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service → > /lib/systemd/system/systemd-timesyncd.service. > Initializing machine ID from random generator. > [/quote] If you can still reproduce this with a current version of sbuild, let's reassign the bug then. If I understood Johannes correctly, /var (and /) is not supposed to be owned by sbuild or have otherwise messed up permissions. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#950684: systemd: upgrade fails in a chroot where /var/log/ owner is not root:root
Hi, I have the same issue: Build a new chroot with: sudo sbuild-createchroot --include=eatmydata,ccache,gnupg --make-sbuild-tarball=/var/cache/chroot/sid1-amd64-sbuild.tar.gz sid `mktemp -d` http://deb.debian.org/debian The I build simple-scan/3.34.4-1 [quote] Selecting previously unselected package sbuild-build-depends-dose3-dummy. Preparing to unpack .../8-sbuild-build-depends-dose3-dummy_0.invalid.0_amd64.deb ... Unpacking sbuild-build-depends-dose3-dummy (0.invalid.0) ... Setting up systemd (244.3-1) ... Detected unsafe path transition / → /var during canonicalization of /var/log/journal. Detected unsafe path transition / → /var during canonicalization of /var/log/journal. Detected unsafe path transition / → /var during canonicalization of /var/log/journal. Detected unsafe path transition / → /var during canonicalization of /var/log/journal. dpkg: error processing package systemd (--configure): installed systemd package post-installation script subprocess returned error exit status 73 [/quote] The same parts from build simple-scan/ [qoute] Setting up libcryptsetup12:amd64 (2:2.2.2-1) ... Setting up systemd (244-3) ... Created symlink /etc/systemd/system/getty.target.wants/getty@tty1.service → /lib/systemd/system/getty@.service. Created symlink /etc/systemd/system/multi-user.target.wants/remote-fs.target → /lib/systemd/system/remote-fs.target. Created symlink /etc/systemd/system/dbus-org.freedesktop.timesync1.service → /lib/systemd/system/systemd-timesyncd.service. Created symlink /etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service → /lib/systemd/system/systemd-timesyncd.service. Initializing machine ID from random generator. [/quote] -- New: GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB 30EE 09F8 9F3C 8CA1 D25D GPG key (long) : 09F89F3C8CA1D25D GPG Key: 8CA1D25D CAcert Key S/N : 0E:D4:56 Old pgp Key: BE581B6E (revoked since 2014-12-31). Jörg Frings-Fürst D-54470 Lieser git: https://jff.email/cgit/ Threema: SYR8SJXB Wire: @joergfringsfuerst Skype:joergpenguin Ring: jff Telegram: @joergfringsfuerst My wish list: - Please send me a picture from the nature at your home. signature.asc Description: This is a digitally signed message part
Bug#951617: RM: getlive -- RoQA; Upstream Dead; Not Working Anymore
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove Dear FTP Masters, As described in https://bugs.debian.org/950452 , the upstream of package getlive no longer maintains it since 2014 due to hotmail live's contstantly breaking changes. As a result, package getlive has been broken since then. I believe we should have it removed from Debian archive since it is really useless now. -- Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#951616: ITP: python-libais -- Library for decoding maritime Automatic Identification System messages
Package: wnpp Severity: wishlist Owner: Adam Cecile * Package name: python-libais Version : 0.17+git.20190917.master.e464cf8 Upstream Author : Kurt Schwehr * URL : https://github.com/schwehr/libais * License : Apache-2.0 / BSD-3-Clause Programming Lang: C++ / Python Description : Library for decoding maritime Automatic Identification System messages There are two interfaces to libais, one high-level iterator based one and a low-level fast C++ only one. . To use the low-level C++ interface directly, you need to handle multi-line messages and padding yourself. I intend to maintain this package within the DPMT.
Bug#951367: [PATCH] don't pass an empty arg to wget when --verbose is applied (Closes: #951367)
If NVSWITCH is empty, the old code was running wget '' …
But this causes wget to fail to fetch the empty URL, which means the
return code ends up being non-zero. This breaks sbuild-createchroot,
which apparently always passes --verbose to debootstrap.
This error was introduced in 14f0b7aafb4d568b027baeecee08cfac6c4f874d,
so is relatively recent.
---
functions | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/functions b/functions
index a3c93e9..d6725f7 100644
--- a/functions
+++ b/functions
@@ -93,7 +93,7 @@ wgetprogress () {
ret=$({ { wget $@ 2>&1 >/dev/null || echo $? >&2; } |
"$PKGDETAILS" "WGET%" "$PROGRESS_NOW" "$PROGRESS_NEXT" "$PROGRESS_END" >&3; }
2>&1)
: ${ret:=0}
else
- wget "$NVSWITCH" "$@"
+ wget $NVSWITCH "$@"
ret=$?
fi
return $ret
--
2.25.0
Bug#951615: geoipupdate: when geoipupdare runs it fails to update databases from cron or command line
Package: geoipupdate Version: 3.1.1-1 Severity: normal Dear Maintainer, when geoipupdate runs it fails to update databases: sudo /usr/bin/geoipupdate -v geoipupdate 3.1.1 Opened License file /etc/GeoIP.conf Insert edition_id GeoLite2-Country Insert edition_id GeoLite2-City Read in license key /etc/GeoIP.conf Number of edition IDs 2 url: https://updates.maxmind.com/app/update_getfilename?product_id=GeoLite2-Country md5hex_digest: edb82339b28f9b51ce528dc438cf6098 url: https://updates.maxmind.com/geoip/databases/GeoLite2-Country/update?db_md5=edb82339b28f9b51ce528dc438cf6098 Your account ID or license key is invalid url: https://updates.maxmind.com/app/update_getfilename?product_id=GeoLite2-City md5hex_digest: 10b66842fd51336ae7c4f34c058deb46 url: https://updates.maxmind.com/geoip/databases/GeoLite2-City/update?db_md5=10b66842fd51336ae7c4f34c058deb46 Your account ID or license key is invalid *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: 10.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-8-amd64 (SMP w/1 CPU core) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages geoipupdate depends on: ii libc62.28-10 ii libcurl3-gnutls 7.64.0-4 ii zlib1g 1:1.2.11.dfsg-1 geoipupdate recommends no packages. Versions of packages geoipupdate suggests: pn geoip-bin pn mmdb-bin -- no debconf information
Bug#951614: dpkg: Fix typos in translation strings around --compare-versions
Package: dpkg Version: 1.19.7 X-Debbugs-CC: guil...@debian.org Dear dpkg developers, A report was received that there are several typos lying around the translated strings of --compare-versions. The string was either translated as --compare- vesions (lack of "r") or --compare-version (lack of "s"). I am attaching a patch to fix this issue. This should be applied in git HEAD (master branch). Please let me know if more information is needed. -- Best Regards, Boyuan Yang From b707f76757e78edfb5530a304ac0523bd4cf1f2f Mon Sep 17 00:00:00 2001 From: Boyuan Yang Date: Tue, 18 Feb 2020 15:23:10 -0500 Subject: [PATCH] po/*.po: Fix translation of --compare-versions In cs.po, zh_CN.po and zh_TW.po, some translated strings contain typo for the --compare-versions string. This commit fixes those typos. Originally reported at: https://lists.debian.org/debian-l10n-chinese/2020/02/msg0.html Signed-off-by: Boyuan Yang --- po/cs.po| 2 +- po/zh_CN.po | 6 +++--- po/zh_TW.po | 2 +- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/po/cs.po b/po/cs.po index 0d4907a72..b2a12ec12 100644 --- a/po/cs.po +++ b/po/cs.po @@ -3205,7 +3205,7 @@ msgstr "verze „%s“ má špatnou syntaxi" #: src/enquiry.c msgid "" "--compare-versions takes three arguments: " -msgstr "--compare-version vyžaduje tři parametry: " +msgstr "--compare-versions vyžaduje tři parametry: " #: src/enquiry.c msgid "--compare-versions bad relation" diff --git a/po/zh_CN.po b/po/zh_CN.po index f06841dc9..39134380c 100644 --- a/po/zh_CN.po +++ b/po/zh_CN.po @@ -3082,7 +3082,7 @@ msgstr "版本号 '%s' 语法错误" msgid "" "--compare-versions takes three arguments: " msgstr "" -"--compare-version 需要三个参数，它们分别是：<版本号> <比较关系> <版本号>" +"--compare-versions 需要三个参数，它们分别是：<版本号> <比较关系> <版本号>" #: src/enquiry.c msgid "--compare-versions bad relation" @@ -3446,7 +3446,7 @@ msgstr "" " --print-foreign-architectures显示已启用的异质体系结构。\n" " --assert-<特性> 对指定特性启用断言支持。\n" " --validate-<属性> <字符串> 验证一个 <属性>的 <字符串>。\n" -" --compare-vesions <关系> 比较版本号 - 见下。\n" +" --compare-versions <关系> 比较版本号 - 见下。\n" " --force-help 显示本强制选项的帮助信息。\n" " -Dh|--debug=help 显示有关出错调试的帮助信息。\n" "\n" @@ -3574,7 +3574,7 @@ msgid "" "syntax).\n" "\n" msgstr "" -"可供--compare-version 使用的比较运算符有：\n" +"可供--compare-versions 使用的比较运算符有：\n" " lt le eq ne ge gt(如果版本号为空，那么就认为它先于任意版本号)；\n" " lt-nl le-nl ge-nl gt-nl (如果版本号为空，那么就认为它后于任意版本号)；\n" " < << <= = >= >> >(仅仅是为了与主控文件的语法兼容)。\n" diff --git a/po/zh_TW.po b/po/zh_TW.po index 8317ad255..c16289fb0 100644 --- a/po/zh_TW.po +++ b/po/zh_TW.po @@ -3169,7 +3169,7 @@ msgstr "「%s」版本號的語法不正確" #: src/enquiry.c msgid "" "--compare-versions takes three arguments: " -msgstr "--compare-version 需有三個參數：<版本號> <比較關係> <版本號>" +msgstr "--compare-versions 需有三個參數：<版本號> <比較關係> <版本號>" #: src/enquiry.c msgid "--compare-versions bad relation" -- 2.25.0 signature.asc Description: This is a digitally signed message part
Bug#888705: abseil-cpp packaging
Hi all, I have dropped almost all static (*.a)-files from libraries, which I maintain(ed). The main reason is the easier security fixes if any appear in the library. One need then basically rebuild the so-files. With statically linked code the security fixes are much harder: one need to rebuild all build-depends. Some more info [1]. ABI-breakage between LTS-releases is not a big deal. We should just change the SO-name of the library and force transition-process. [1] https://wiki.debian.org/StaticLinking#downsides Regards Anton Am Di., 18. Feb. 2020 um 02:46 Uhr schrieb Benjamin Barenblat : > > On Sunday, February 16, 2020, at 10:48 PM +0100, László Böszörményi (GCS) > wrote: > > In my reading abseil is _not_ guaranteed to have ABI compatibility at > > all times. That's why it meant to be a static library collection only. > > Forcing it to build shared libraries and have other packages than > > libabseil-cpp-dev is no sense I think. > > Abseil does reserve the right to break ABI at any time, and I can’t > speak to their future plans. But I think ABI breakages are unlikely to > occur in practice within an LTS release. If we wait and then package an > LTS release, I it’ll be completely reasonable to ship .so’s and .a’s. > > Relatedly, I think we should only package LTS Abseil for Debian. If > someone finds a CVE in Abseil, the Abseil team are going to want to > backport the fix to LTS releases; they’re not going to want to backport > it everywhere else. > > > @Benjamin: may you ask its developers to use the system gtest libraries > > if only ABSL_RUN_TESTS set to ON? > > Absolutely. I’ll bring it up with them at work tomorrow (today was a US > holiday).
Bug#951539: ITP: bruteforce-wallet -- Try to find a password of a encrypted wallet file
Hi Sam Hartman, The description looks like this: Description: Try to find the password of an encrypted wallet file bruteforce-wallet try to find the password of an encrypted Peercoin (or Bitcoin, Litecoin, etc...) wallet file. It can be used in two ways: . - Try all possible passwords given a charset. - Try all passwords in a file (dictionary). . bruteforce-wallet have the following features: . - You can specify the number of threads to use when cracking a file. - Sending a USR1 signal to a running bruteforce-wallet process makes it print progress and continue. - There are an exhaustive mode and a dictionary mode. . In the exhaustive mode the program tries to decrypt one of the ecrypted addresses in the wallet by trying all the possible passwords. It is especially useful if you know something about the password (i.e. you forgot a part of your password but still remember most of it). Finding the password of a wallet without knowing anything about it would take way too much time (unless the password is really short and/or weak). There are some command line options to specify: . - The minimum password length to try. - The maximum password length to try. - The beginning of the password. - The end of the password. - The character set to use (among the characters of the current locale). . In dictionary mode the program tries to decrypt one of the encrypted addresses in the wallet by trying all the passwords contained in a file. The file must have one password per line. . This package is useful for finding the password for a Peercoin encrypted wallet file (or Bitcoin, Litecoin, etc ...) (i.e. wallet.dat). -- Francisco Vilmar Cardoso Ruviaro 4096R: 1B8C F656 EF3B 8447 2F48 F0E7 82FB F706 0B2F 7D00
Bug#951612: libhtml-strip-perl: unsatisfiable cross Build-Depends
Source: libhtml-strip-perl Version: 2.10-1 Tags: patch User: debian-cr...@lists.debian.org Usertags: cross-satisfiability libhtml-strip-perl cannot be cross built from source, because its Build-Depends are not satisfiable. The perl dependency should be replaced with perl-xs-dev as it builds a perl extension module. All of the perl modules are only required for testing and can thus be annotated with . I verified that a nocheck build produces the exact same binary package as a regular build. Please consider applying the attached patch. Helmut diff --minimal -Nru libhtml-strip-perl-2.10/debian/changelog libhtml-strip-perl-2.10/debian/changelog --- libhtml-strip-perl-2.10/debian/changelog2016-06-29 21:41:43.0 +0200 +++ libhtml-strip-perl-2.10/debian/changelog2020-02-18 20:42:20.0 +0100 @@ -1,3 +1,12 @@ +libhtml-strip-perl (2.10-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: (Closes: #-1) ++ Build-Depends: perl-xs-dev. ++ Annotate test dependencies with . + + -- Helmut Grohne Tue, 18 Feb 2020 20:42:20 +0100 + libhtml-strip-perl (2.10-1) unstable; urgency=medium * Team upload. diff --minimal -Nru libhtml-strip-perl-2.10/debian/control libhtml-strip-perl-2.10/debian/control --- libhtml-strip-perl-2.10/debian/control 2016-06-29 21:41:43.0 +0200 +++ libhtml-strip-perl-2.10/debian/control 2020-02-18 20:42:20.0 +0100 @@ -4,9 +4,9 @@ Section: perl Priority: optional Build-Depends: debhelper (>= 9.20120312~), - perl, - libhtml-parser-perl, - libtest-exception-perl + perl-xs-dev, + libhtml-parser-perl , + libtest-exception-perl Standards-Version: 3.9.8 Vcs-Browser: https://anonscm.debian.org/cgit/pkg-perl/packages/libhtml-strip-perl.git Vcs-Git: https://anonscm.debian.org/git/pkg-perl/packages/libhtml-strip-perl.git
Bug#951613: libhtml-parser-perl unsatisfiable cross Build-Depends
Source: libhtml-parser-perl Version: 3.72-3 Tags: patch User: debian-cr...@lists.debian.org Usertags: cross-satisfiability libhtml-parser-perl cannot be cross built from source, because its Build-Depends are not satisfiable. The perl dependency should be replaced with perl-xs-dev as it builds a perl extension module. All of the perl modules are only required for testing and can thus be annotated with . I verified that a nocheck build produces the exact same binary package as a regular build. Please consider applying the attached patch. Helmut diff --minimal -Nru libhtml-parser-perl-3.72/debian/changelog libhtml-parser-perl-3.72/debian/changelog --- libhtml-parser-perl-3.72/debian/changelog 2016-11-21 19:31:20.0 +0100 +++ libhtml-parser-perl-3.72/debian/changelog 2020-02-18 20:29:27.0 +0100 @@ -1,3 +1,12 @@ +libhtml-parser-perl (3.72-3.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: (Closes: #-1) ++ Build-Depends: perl-xs-dev. ++ Annotate test dependencies with . + + -- Helmut Grohne Tue, 18 Feb 2020 20:29:27 +0100 + libhtml-parser-perl (3.72-3) unstable; urgency=medium * Team upload. diff --minimal -Nru libhtml-parser-perl-3.72/debian/control libhtml-parser-perl-3.72/debian/control --- libhtml-parser-perl-3.72/debian/control 2016-11-21 19:31:20.0 +0100 +++ libhtml-parser-perl-3.72/debian/control 2020-02-18 20:29:27.0 +0100 @@ -7,12 +7,12 @@ Section: perl Testsuite: autopkgtest-pkg-perl Priority: optional -Build-Depends: perl, +Build-Depends: perl-xs-dev, debhelper (>= 9.20120312), - libhtml-tagset-perl, - libhttp-message-perl, - libtest-pod-perl, - liburi-perl + libhtml-tagset-perl , + libhttp-message-perl , + libtest-pod-perl , + liburi-perl Standards-Version: 3.9.8 Vcs-Browser: https://anonscm.debian.org/cgit/pkg-perl/packages/libhtml-parser-perl.git Vcs-Git: https://anonscm.debian.org/git/pkg-perl/packages/libhtml-parser-perl.git
Bug#888705: abseil-cpp packaging
On Tue, Feb 18, 2020 at 2:31 AM Benjamin Barenblat wrote: > On Sunday, February 16, 2020, at 10:48 PM +0100, László Böszörményi (GCS) > wrote: > > In my reading abseil is _not_ guaranteed to have ABI compatibility at > > all times. That's why it meant to be a static library collection only. > > Forcing it to build shared libraries and have other packages than > > libabseil-cpp-dev is no sense I think. > > Abseil does reserve the right to break ABI at any time, and I can’t > speak to their future plans. But I think ABI breakages are unlikely to > occur in practice within an LTS release. If we wait and then package an > LTS release, I it’ll be completely reasonable to ship .so’s and .a’s. There's a compatibility page[1] what Abseil is and isn't. It states the following things. "We do not promise any ABI compatibility — we intend for Abseil to be built from source, hopefully from head. The internal layout of our types may change at any point, without notice." As I read waiting for LTS releases might be late (its head commit version advised to be used). I guess other Google applications other libraries commonly wants newer Abseil releases than LTS ones. "Not all Abseil libraries are suitable for dynamic loading. Some libraries have startup/initialization requirements and may not be suitable for dynamic loading. We will try to be clear about which libraries are OK for dynamic loading. However we don’t generally deploy code in this fashion, mistakes are possible, [...]". That is, even shared libraries can be built, those are not guaranteed to work. "We will not break API compatibility. If we must, we will ship a tool to automate the upgrade to a preferred API." Seems to suggest using the head (latest commit) freely and link with the static libraries of the applications. > Relatedly, I think we should only package LTS Abseil for Debian. If > someone finds a CVE in Abseil, the Abseil team are going to want to > backport the fix to LTS releases; they’re not going to want to backport > it everywhere else. I think there should be a compatibility matrix or test if the latest LTS release is enough for most Google applications or those need newer versions (no new API added for recent application development). Even if I agree that LTS releases are better for long time use cases and from security point of view. > > @Benjamin: may you ask its developers to use the system gtest libraries > > if only ABSL_RUN_TESTS set to ON? > > Absolutely. I’ll bring it up with them at work tomorrow (today was a US > holiday). Thanks. Please keep us posted how it goes. Regards, Laszlo/GCS [1] https://abseil.io/about/compatibility
Bug#951589: flashrom: Update to version 1.2
With the new stuff I think you need to actually split it into 3 distinct binary packages in debian/ : flashrom libflashrom libflashrom-dev Also I think you need to explicitly build with meson rather than autotools to get it to make the pkgconfig file IIRC. From: Gürkan Myczko Sent: Tuesday, February 18, 2020 9:09 AM To: Limonciello, Mario; 951...@bugs.debian.org Cc: Debian Bug Tracking System Subject: Re: Bug#951589: flashrom: Update to version 1.2 [EXTERNAL EMAIL] Hi If you dont mind with 1.2-2 waiting for the update atm http://phd-sid.ethz.ch/debian/flashrom/2020/ Gürkan On Feb 18, 2020, at 15:51, Mario Limonciello mailto:mario.limoncie...@dell.com>> wrote: Package: flashrom Severity: wishlist Tags: upstream Dear Maintainer, Can you please upgrade to the recently released version 1.2? This package now supports a library for other applications to compile against it. As part of upgrading to 1.2, can you please introduce new binary packages for that library and pkgconfig/headers too? I would like to compile fwupd against it to introduce flashrom support for fwupd in Debian. -- System Information: Debian Release: bullseye/sid APT prefers focal APT policy: (500, 'focal') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-12-generic (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages flashrom depends on: ii libc6 2.30-0ubuntu3 ii libftdi1-21.4-2build1 ii libpci3 1:3.6.4-1 ii libusb-0.1-4 2:0.1.12-32 ii libusb-1.0-0 2:1.0.23-2build1 flashrom recommends no packages. flashrom suggests no packages.
Bug#951523: dolphin: installing dolphin on xfce is missing a kde component for file transfer
As said, you only need the plasma-workspace package, not plasma-desktop. Removing packages after installing plasma-desktop will not lead to a different conclusion, because plasma-workspace contains the binary you seem to need. On 18 February 2020 19:45:29 CET, Schrotty wrote: >Hi, > >yes, as I wrote in my original post, that will "fix" the problem of the >missing dialog. But it pulls so much ridiculous dependencies which are >taking 1GB of diskspace. > >I first tried to add package after package to see which one solves the >problem, without select the big "base" package. But I did not manage. > >In a 2nd attempt I went the opposite way: Installing the plasma-desktop >monster and starting to remove packages. So far I have eliminated the >following packages: >- plasma-discover >- plasma-framework >- plasma-desktop-data >- plasma-pa > > >Mrs. Spammy and Mrs Schrotty >schr...@coole-files.de > >On 2/18/20 7:29 PM, Jonah Brüchert wrote: >> [disclaimer: I'm not the package maintainer] >> >> Hi, >> >> kuiserver is part of the plasma-workspace package, installing it >could >> probably fix the problem. >> >>> Package: dolphin >>> Version: 4:18.08.0-1 >>> Severity: normal >>> >>> Dear Maintainer, >>> >>> Installing dolpin using xfce as desktop environment on debian 10.3. >>> >>> Copying files do NOT show the file transfer dialog. So you never >know >>> when it is done. This is particular bad when copying to a slow USB >>> stick. As the stick might be removed before the transfer is >finished, >>> corrupting the file system >>> It seems the problem has been also detected already with Manjaro: >>> >https://forum.manjaro.org/t/bug-kde-applications-do-not-pull-in-kuiserver-which-now-is-in-plasma-workspace/69675 >>> >>> >>> Unfortunatlly there is no kuiserver package in debian. >>> Installing the complete plasma-desktop as a workaround pulls in a >lot >>> of dependencies filling 1GB of diskspace. Thus only adding this as a >>> dependency might not be the best idea. But I could not figure out >>> which packet is acctually needed. >>> >>> >>> >>> -- System Information: >>> Debian Release: 10.3 >>> APT prefers stable-updates >>> APT policy: (500, 'stable-updates'), (500, 'stable') >>> Architecture: amd64 (x86_64) >>> >>> Kernel: Linux 5.4.0-0.bpo.3-amd64 (SMP w/4 CPU cores) >>> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE >>> Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), >>> LANGUAGE=en_US:en (charmap=UTF-8) >>> Shell: /bin/sh linked to /usr/bin/dash >>> Init: systemd (via /run/systemd/system) >>> LSM: AppArmor: enabled >>> >>> Versions of packages dolphin depends on: >>> ii baloo-kf5 5.54.0-1 >>> ii kinit 5.54.0-1 >>> ii kio 5.54.1-1 >>> ii libc6 2.28-10 >>> ii libdolphinvcs5 4:18.08.0-1 >>> ii libkf5baloo5 5.54.0-1 >>> ii libkf5baloowidgets5 4:18.08.1-1 >>> ii libkf5bookmarks5 5.54.0-1 >>> ii libkf5codecs5 5.54.0-1 >>> ii libkf5completion5 5.54.0-1 >>> ii libkf5configcore5 5.54.0-1+deb10u1 >>> ii libkf5configgui5 5.54.0-1+deb10u1 >>> ii libkf5configwidgets5 5.54.0-1 >>> ii libkf5coreaddons5 5.54.0-1 >>> ii libkf5crash5 5.54.0-1 >>> ii libkf5dbusaddons5 5.54.0-1 >>> ii libkf5filemetadata3 5.54.0-1 >>> ii libkf5i18n5 5.54.0-1 >>> ii libkf5iconthemes5 5.54.0-1 >>> ii libkf5itemviews5 5.54.0-1 >>> ii libkf5jobwidgets5 5.54.0-1 >>> ii libkf5kcmutils5 5.54.0-1 >>> ii libkf5kiocore5 5.54.1-1 >>> ii libkf5kiofilewidgets5 5.54.1-1 >>> ii libkf5kiowidgets5 5.54.1-1 >>> ii libkf5newstuff5 5.54.0-2 >>> ii libkf5notifications5 5.54.0-1 >>> ii libkf5parts5 5.54.0-1 >>> ii libkf5service-bin 5.54.0-1 >>> ii libkf5service5 5.54.0-1 >>> ii libkf5solid5 5.54.0-1 >>> ii libkf5textwidgets5 5.54.0-1 >>> ii libkf5widgetsaddons5 5.54.0-1 >>> ii libkf5xmlgui5 5.54.0-1 >>> ii libphonon4qt5-4 4:4.10.2-1 >>> ii libqt5core5a 5.11.3+dfsg1-1+deb10u3 >>> ii libqt5dbus5 5.11.3+dfsg1-1+deb10u3 >>> ii libqt5gui5 5.11.3+dfsg1-1+deb10u3 >>> ii libqt5widgets5 5.11.3+dfsg1-1+deb10u3 >>> ii libqt5xml5 5.11.3+dfsg1-1+deb10u3 >>> ii libstdc++6 8.3.0-6 >>> ii phonon4qt5 4:4.10.2-1 >>> >>> Versions of packages dolphin recommends: >>> ii kimageformat-plugins 5.54.0-1 >>> ii kio-extras 4:18.08.3-1 >>> ii ruby 1:2.5.1 >>> >>> Versions of packages dolphin suggests: >>> pn dolphin-plugins >>> >>> -- no debconf information >>> >>
Bug#951611: python-django-modelcluster: autopkgtest failure: No module named 'django_modelcluster'
Source: python-django-modelcluster Version: 5.0.1-1 X-Debbugs-CC: debian...@lists.debian.org Severity: serious User: debian...@lists.debian.org Usertags: fails-always Dear maintainers, Your new package python-django-modelcluster has an autopkgtest, great. However, it fails. I copied some of the output at the bottom of this report. You're using autodep8 to trigger the test, but it seems your package naming and Python module name aren't aligned for autodep8. autodep8 recently acquired a new feature that enables you to tell autode8 what the real module name is that should be tested [1]. Currently this regression is blocking the migration to testing [2]. 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://manpages.debian.org/unstable/autodep8/autodep8.1.en.html#PYTHON_PACKAGES [2] https://qa.debian.org/excuses.php?package=python-django-modelcluster https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-django-modelcluster/4070428/log.gz autopkgtest [03:13:18]: test autodep8-python3: set -e ; for py in $(py3versions -r 2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; echo "Testing with $py:" ; $py -c "import django_modelcluster; print(django_modelcluster)" ; done autopkgtest [03:13:18]: test autodep8-python3: [--- Testing with python3.8: Traceback (most recent call last): File "", line 1, in ModuleNotFoundError: No module named 'django_modelcluster' signature.asc Description: OpenPGP digital signature
Bug#951610: linux-image-5.4.0-4-amd64: Does not prompt for cryptsetup password
Package: src:linux Version: 5.4.19-1 Severity: important Hi! Starting with -4 the system fails to boot from encrypted harddrive. switchng back to -3 kernel and everything works fine again. Setup is unencrypted /boot (ext) and / (and other things) via lvm2 inside a cryptsetup volume type:LUKS1 cipher: aes-xts-plain64 keysize: 512 bits key location: dm-crypt device: /dev/nvme0n1p2 sector size: 512 offset: 4096 sectors size:992397312 sectors mode:read/write I can try and see if I get linux to output any usefull messages if that helps. Thanks! Christoph -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information sys_vendor: LENOVO product_name: 20HGS0A600 product_version: ThinkPad T470s chassis_vendor: LENOVO chassis_version: None bios_vendor: LENOVO bios_version: N1WET56W (1.35 ) board_vendor: LENOVO board_name: 20HGS0A600 board_version: Not Defined ** PCI devices: 00:00.0 Host bridge [0600]: Intel Corporation Xeon E3-1200 v6/7th Gen Core Processor Host Bridge/DRAM Registers [8086:5904] (rev 02) Subsystem: Lenovo Xeon E3-1200 v6/7th Gen Core Processor Host Bridge/DRAM Registers [17aa:224b] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: skl_uncore 00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 620 [8086:5916] (rev 02) (prog-if 00 [VGA controller]) Subsystem: Lenovo HD Graphics 620 [17aa:224b] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: i915 Kernel modules: i915 00:14.0 USB controller [0c03]: Intel Corporation Sunrise Point-LP USB 3.0 xHCI Controller [8086:9d2f] (rev 21) (prog-if 30 [XHCI]) Subsystem: Lenovo Sunrise Point-LP USB 3.0 xHCI Controller [17aa:224b] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Kernel driver in use: xhci_hcd Kernel modules: xhci_pci 00:14.2 Signal processing controller [1180]: Intel Corporation Sunrise Point-LP Thermal subsystem [8086:9d31] (rev 21) Subsystem: Lenovo Sunrise Point-LP Thermal subsystem [17aa:224b] Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: intel_pch_thermal Kernel modules: intel_pch_thermal 00:15.0 Signal processing controller [1180]: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #0 [8086:9d60] (rev 21) Subsystem: Lenovo Sunrise Point-LP Serial IO I2C Controller [17aa:224b] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: intel-lpss Kernel modules: intel_lpss_pci 00:16.0 Communication controller [0780]: Intel Corporation Sunrise Point-LP CSME HECI #1 [8086:9d3a] (rev 21) Subsystem: Lenovo Sunrise Point-LP CSME HECI [17aa:224b] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: mei_me Kernel modules: mei_me 00:1c.0 PCI bridge [0604]: Intel Corporation Sunrise Point-LP PCI Express Root Port [8086:9d10] (rev f1) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:1c.2 PCI bridge [0604]: Intel Corporation Sunrise Point-LP PCI Express Root Port [8086:9d12] (rev f1) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:1d.0 PCI bridge [0604]: Intel Corporation Sunrise Point-LP PCI Express Root Port #9 [8086:9d18] (rev f1) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast
Bug#948775: RFS: ukui-interface/1.0.0-1 [ITP] -- Provides the interface for system configuration
Hi, Le 13/01/2020 à 09:54, handsome_feng a écrit : > Package: sponsorship-requests > Severity: wishlist > > Dear mentors, > > I am looking for a sponsor for my package "ukui-interface" > > * Package name: ukui-interface >Version : 1.0.0-1 >Upstream Author : liuhao > * URL : https://github.com/ukui/ukui-interface > * License : GPL-3.0+ > * Vcs : https://github.com/ukui/ukui-interface >Section : libs > > It builds those binary packages: > > libprint0 - print module > libprint-dev - print interface > libgsettings0 - application settings module > libgsettings-dev - application settings interface > backgroundserver - background settings service process > libbackgroundclient0 - background settings module > libbackgroundclient-dev - background settings interfaces > libdatesetting0 - date settings module > libdatesetting-dev - date settings interfaces > libdefaultprograms0 - default programs settings module > libdefaultprograms-dev - default programs settings interfaces > desktopserver - desktop settings service process > libdesktopclient0 - desktop settings module > libdesktopclient-dev - desktop settings interfaces > fontserver - font settings service process > libfontclient0 - font settings module > libfontclient-dev - font settings interfaces > interfaceserver - interface settings service process > libinterfaceclient0 - interface settings module > libinterfaceclient-dev - interface settings interfaces > keyboardserver - keyboard settings service process > libkeyboardclient0 - keyboard settings module > libkeyboardclient-dev - keyboard settings interfaces > marcogeneralserver - marcogeneral settings service process > libmarcogeneralclient0 - marcogeneral settings module > libmarcogeneralclient-dev - marcogeneral settings interfaces > mouseserver - mouse settings service process > libmouseclient0 - mouse settings module > libmouseclient-dev - mouse settings interfaces > libnetwork0 - network settings module > libnetwork-dev - network settings interfaces > powerserver - power settings service process > libpowerclient0 - power settings module > libpowerclient-dev - power settings interfaces > screensaverserver - screensaver settings service process > libscreensaverclient0 - screensaver settings module > libscreensaverclient-dev - screensaver settings interfaces > sessionserver - session settings service process > libsessionclient0 - session settings module > libsessionclient-dev - session settings interfaces > libsubversion0 - Subversion check module > libsubversion-dev - Subversion check interfaces > libsysinfo0 - system information gettings module > libsysinfo-dev - system information gettings interfaces > touchpadserver - touchpad settings service process > libtouchpadclient0 - touchpad settings module > libtouchpadclient-dev - touchpad settings interfaces > libusersetting0 - user settings module > libusersetting-dev - user settings interfaces > xkbgeneralserver - xkbgeneral settings service process > libxkbgeneralclient0 - xkbgeneral settings module > libxkbgeneralclient-dev - xkbgeneral settings interfaces > Please note that I'm speaking without knowing the packaged application. You should probably add a prefix to packages names to avoid cluttering the package namespace. For example: libprint0=> libukui-print0 backgroundserver => ukui-backgroundserver Same for the underlying binaries if they don't have "ukui" in their name. The rationale is to avoid too generic names that could already exist or better suitted to more common tools. For example, "libsubversion0" would better be the name of a package for SVN implementation (actually, the subversion source package use the name of libsvn1 for its binary library package). Also, maybe add a meta package that depends on all these package with Depends, Recommends or Suggests as appropriate so someone that want ukui only have to select one package instead of all parts of it. (This package would be an equivalent to, say, kde-standard for KDE). -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F signature.asc Description: OpenPGP digital signature
Bug#951609: ITP: azure-data-lake-store-python -- Azure Data Lake Store Filesystem Library for Python
Package: wnpp Severity: wishlist Owner: "Luca Boccassi" X-Debbugs-CC: debian-de...@lists.debian.org Control: block 949763 by -1 * Package name: azure-data-lake-store-python Version : 0.0.48 Upstream Author : Microsoft Corporation * URL : https://github.com/Azure/azure-data-lake-store-python * License : MIT * Programming Lang: Python * Description : Azure Data Lake Store Filesystem Library for Python A pure-python interface to the Azure Data-lake Storage system, providing pythonic file-system and file objects, seamless transition between Windows and POSIX remote paths, high-performance up- and down- loader. It is required as a new dependency of the new version of python-azure. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#951608: switchconf: Please make another source-only upload to allow testing migration
Source: switchconf Version: 0.0.16-1 Severity: serious Justification: out-of-sync unstable-to-testing Dear switchconf maintainer, The last upload of package switchconf was not a source-only upload. As a result, the most recent upload will not migrate to Testing. According to the policy of Release Team on Feb. 2020 [1], packages that are out-of-sync between testing and unstable for more than 60 days are considered to be having a Release-Critical bug. Please make another source-only upload to solve this issue. For more information, please see https://wiki.debian.org/SourceOnlyUpload . [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html -- Regards, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#951605: php-swiftmailer: include an autoload.php file
Package: php-swiftmailer Version: 5.4.2-1.1 Severity: wishlist Tags: patch Dear Maintainer, Please consider including an autoload.php file in the package. Many PHP library packages contain a file named autoload.php defining an autoloader for the library's classes and its dependencies. Outside of Debian packaging, this is often similarly handled with Composer's "vendor/autoload.php" file. Swiftmailer already ships an autoloader, albeit with the hard-to-guess name "swift_required.php". This makes it harder to use the library because it requires knowledge of its internal implementation. Outside of Debian, this file is hidden behind Composer. I propose to offer autoloading through the more typically named autoload.php. It could be accomplished by a simple symlink, like so: --- /dev/null 2020-02-18 12:53:50.73999 +0100 +++ debian/links2020-02-18 17:31:06.373473127 +0100 @@ -0,0 +1 @@ +/usr/share/php/Swift/swift_required.php /usr/share/php/Swift/autoload.php Regards, Robin
Bug#951603: php-nesbot-carbon: new major upstream version available
Package: php-nesbot-carbon Severity: important Control: block 951159 by -1 Dear Maintainer, Please consider updating to a newer upstream version (2.x). The only reverse dependency, php-illuminate-support, supports 2.x already at its current version. Newer upstream versions of that package will require it. I've set a higher severity because this is blocking one of my ITPs. Regards, Robin
Bug#951607: peony: FTBFS on many architectures (mishandling of symbols)
Source: peony Version: 2.0.0-1 Severity: grave X-Debbugs-CC: jianfen...@ubuntukylin.com Hi handsome_feng, As you can see in https://buildd.debian.org/status/package.php?p=peony , there's some mishandling of symbols as indicated in the build log. Please consider fixing them. Thanks! -- Best, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#934366: libreoffice-calc hangs when formatting empty or date cells in Hungarian Buster
Hi! In the latest version 1:6.4.1~rc1-2~bpo10+1 I get a Fatal Error when trying to format an empty or date cell with this message: "locale::facet::_S_create_c_locale name not valid". After pressing OK, calc exits. Thanks! On Sat, 10 Aug 2019 14:07:52 +0200 Kovacs Lajos wrote: > Hi, > > I only get some Gdk-WARNINGs in the terminal: > > (soffice:2606): Gdk-WARNING **: 14:05:07.220: gdk_window_set_icon_list: > icons too large > > Thanks! > > > On Sat, Aug 10, 2019 at 11:54 AM Rene Engelhard wrote: > > > Hi, > > > > On Sat, Aug 10, 2019 at 11:24:20AM +0200, Rene Engelhard wrote: > > > Are they using external liblangtag? > > > (though the only locale-related patch I see in LOs code for liblangtag > > > is to support ca_ES@valencia) > > > > Looking at their .spec file > > ( > > https://src.fedoraproject.org/rpms/libreoffice/blob/f30/f/libreoffice.spec > > ), > > yes. > > > > Hmm. > > > > Regards, > > > > Rene > > > > >
Bug#950716: transition: ruby2.7
On Tue, 18 Feb 2020 at 14:39, Lucas Kanashiro wrote: > Could you please start the rebuild process of the first level > of dependencies reported in the transition page? All packages in level 1, and packages only build-depending on ruby-defaults in level 2, scheduled.
Bug#946648: Bug#945920: fixed in chromium 79.0.3945.130-1
x@xxL:~$ chromium-browser Using PPAPI flash. ../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:(tg)kill() failure ../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:(tg)kill() failure [31074:7:0218/192244.240822:ERROR:command_buffer_proxy_impl.cc(125)] ContextResult::kTransientFailure: Failed to send GpuChannelMsg_CreateCommandBuffer. ../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:(tg)kill() failure ../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:(tg)kill() failure ../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:(tg)kill() failure [31310:1:0218/192324.194197:ERROR:child_process_sandbox_support_impl_linux.cc(79)] FontService unique font name matching request did not receive a response. [31310:1:0218/192324.194529:ERROR:child_process_sandbox_support_impl_linux.cc(79)] FontService unique font name matching request did not receive a response. [31310:1:0218/192324.195145:ERROR:child_process_sandbox_support_impl_linux.cc(79)] FontService unique font name matching request did not receive a response. [31310:1:0218/192324.195635:ERROR:child_process_sandbox_support_impl_linux.cc(79)] FontService unique font name matching request did not receive a response. [31310:1:0218/192324.363100:ERROR:command_buffer_proxy_impl.cc(125)] ContextResult::kTransientFailure: Failed to send GpuChannelMsg_CreateCommandBuffer. [31310:1:0218/192324.995429:ERROR:child_process_sandbox_support_impl_linux.cc(79)] FontService unique font name matching request did not receive a response. ../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:(tg)kill() failure [31406:31406:0218/192336.726429:ERROR:gpu_channel_manager.cc(459)] ContextResult::kFatalFailure: Failed to create shared context for virtualization. ../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:(tg)kill() failure [31435:31435:0218/192348.557044:ERROR:gpu_channel_manager.cc(459)] ContextResult::kFatalFailure: Failed to create shared context for virtualization. [31310:1:0218/192349.169034:ERROR:child_process_sandbox_support_impl_linux.cc(79)] FontService unique font name matching request did not receive a response. [31310:1:0218/192349.169431:ERROR:child_process_sandbox_support_impl_linux.cc(79)] FontService unique font name matching request did not receive a response. [31310:1:0218/192353.767793:ERROR:child_process_sandbox_support_impl_linux.cc(79)] FontService unique font name matching request did not receive a response. [31310:1:0218/192353.768100:ERROR:child_process_sandbox_support_impl_linux.cc(79)] FontService unique font name matching request did not receive a response. ../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:(tg)kill() failure [31459:31459:0218/192359.333213:ERROR:gpu_channel_manager.cc(459)] ContextResult::kFatalFailure: Failed to create shared context for virtualization. ../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:(tg)kill() failure [31014:31036:0218/192411.617036:FATAL:gpu_data_manager_impl_private.cc(1034)] The display compositor is frequently crashing. Goodbye. Trappe pour point d'arrêt et de trace (core dumped)
Bug#951604: gnome-subtitle: Please package the new upstream release (1.6)
Source: gnome-subtitles Severity: normal Version: 1.4.2-1 X-Debbugs-CC: ti...@debian.org mee...@debian.org Dear gnome-subtitle maintainers, The upstream of gnome-subtitle has release v1.6 according to http://gnomesubtitles.org/gnome-subtitles-release-1.6 . Please consider packaging it in Debian. Thanks! -- Best, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#951606: RM: ignition-math2 -- ROM; obsolete
Package: ftp.debian.org Severity: normal Please remove ignition-math2 from unstable ignition-math4 is in Debian and upstream current version is 6.x series Nothing depends on it. Thanks.
Bug#951523: dolphin: installing dolphin on xfce is missing a kde component for file transfer
Hi, yes, as I wrote in my original post, that will "fix" the problem of the missing dialog. But it pulls so much ridiculous dependencies which are taking 1GB of diskspace. I first tried to add package after package to see which one solves the problem, without select the big "base" package. But I did not manage. In a 2nd attempt I went the opposite way: Installing the plasma-desktop monster and starting to remove packages. So far I have eliminated the following packages: - plasma-discover - plasma-framework - plasma-desktop-data - plasma-pa Mrs. Spammy and Mrs Schrotty schr...@coole-files.de On 2/18/20 7:29 PM, Jonah Brüchert wrote: > [disclaimer: I'm not the package maintainer] > > Hi, > > kuiserver is part of the plasma-workspace package, installing it could > probably fix the problem. > >> Package: dolphin >> Version: 4:18.08.0-1 >> Severity: normal >> >> Dear Maintainer, >> >> Installing dolpin using xfce as desktop environment on debian 10.3. >> >> Copying files do NOT show the file transfer dialog. So you never know >> when it is done. This is particular bad when copying to a slow USB >> stick. As the stick might be removed before the transfer is finished, >> corrupting the file system >> It seems the problem has been also detected already with Manjaro: >> https://forum.manjaro.org/t/bug-kde-applications-do-not-pull-in-kuiserver-which-now-is-in-plasma-workspace/69675 >> >> >> Unfortunatlly there is no kuiserver package in debian. >> Installing the complete plasma-desktop as a workaround pulls in a lot >> of dependencies filling 1GB of diskspace. Thus only adding this as a >> dependency might not be the best idea. But I could not figure out >> which packet is acctually needed. >> >> >> >> -- System Information: >> Debian Release: 10.3 >> APT prefers stable-updates >> APT policy: (500, 'stable-updates'), (500, 'stable') >> Architecture: amd64 (x86_64) >> >> Kernel: Linux 5.4.0-0.bpo.3-amd64 (SMP w/4 CPU cores) >> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE >> Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), >> LANGUAGE=en_US:en (charmap=UTF-8) >> Shell: /bin/sh linked to /usr/bin/dash >> Init: systemd (via /run/systemd/system) >> LSM: AppArmor: enabled >> >> Versions of packages dolphin depends on: >> ii baloo-kf5 5.54.0-1 >> ii kinit 5.54.0-1 >> ii kio 5.54.1-1 >> ii libc6 2.28-10 >> ii libdolphinvcs5 4:18.08.0-1 >> ii libkf5baloo5 5.54.0-1 >> ii libkf5baloowidgets5 4:18.08.1-1 >> ii libkf5bookmarks5 5.54.0-1 >> ii libkf5codecs5 5.54.0-1 >> ii libkf5completion5 5.54.0-1 >> ii libkf5configcore5 5.54.0-1+deb10u1 >> ii libkf5configgui5 5.54.0-1+deb10u1 >> ii libkf5configwidgets5 5.54.0-1 >> ii libkf5coreaddons5 5.54.0-1 >> ii libkf5crash5 5.54.0-1 >> ii libkf5dbusaddons5 5.54.0-1 >> ii libkf5filemetadata3 5.54.0-1 >> ii libkf5i18n5 5.54.0-1 >> ii libkf5iconthemes5 5.54.0-1 >> ii libkf5itemviews5 5.54.0-1 >> ii libkf5jobwidgets5 5.54.0-1 >> ii libkf5kcmutils5 5.54.0-1 >> ii libkf5kiocore5 5.54.1-1 >> ii libkf5kiofilewidgets5 5.54.1-1 >> ii libkf5kiowidgets5 5.54.1-1 >> ii libkf5newstuff5 5.54.0-2 >> ii libkf5notifications5 5.54.0-1 >> ii libkf5parts5 5.54.0-1 >> ii libkf5service-bin 5.54.0-1 >> ii libkf5service5 5.54.0-1 >> ii libkf5solid5 5.54.0-1 >> ii libkf5textwidgets5 5.54.0-1 >> ii libkf5widgetsaddons5 5.54.0-1 >> ii libkf5xmlgui5 5.54.0-1 >> ii libphonon4qt5-4 4:4.10.2-1 >> ii libqt5core5a 5.11.3+dfsg1-1+deb10u3 >> ii libqt5dbus5 5.11.3+dfsg1-1+deb10u3 >> ii libqt5gui5 5.11.3+dfsg1-1+deb10u3 >> ii libqt5widgets5 5.11.3+dfsg1-1+deb10u3 >> ii libqt5xml5 5.11.3+dfsg1-1+deb10u3 >> ii libstdc++6 8.3.0-6 >> ii phonon4qt5 4:4.10.2-1 >> >> Versions of packages dolphin recommends: >> ii kimageformat-plugins 5.54.0-1 >> ii kio-extras 4:18.08.3-1 >> ii ruby 1:2.5.1 >> >> Versions of packages dolphin suggests: >> pn dolphin-plugins >> >> -- no debconf information >> >
Bug#951602: manuskript: Please package the new upstream release
Source: manuskript Version: 0.10.0-1 Severity: important X-Debbugs-CC: mir...@debian.org Dear manuskript maintainer, The upstream of your package manuskript has release a new release v0.11. This new version contains the migration to python3, which is quite important since Debian is on its way of removing python2 completely from the archive. Please consider packaging the new version and migrate to python3. Thanks! -- Best, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#951601: RFS: coinor-cgl/0.60.3+repack1-1 [QA] -- COIN-OR Cut Generation Library
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "coinor-cgl" * Package name: coinor-cgl Version : 0.60.3+repack1-1 Upstream Author : [fill in name and email of upstream] * URL : https://projects.coin-or.org/Cgl * License : EPL-1 * Vcs : https://salsa.debian.org/science-team/coinor-cgl Section : science It builds those binary packages: coinor-libcgl1 - COIN-OR Cut Generation Library coinor-libcgl-dev - COIN-OR Cut Generation Library (developer files) coinor-libcgl-doc - COIN-OR Cut Generation Library (documentation) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/coinor-cgl Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/c/coinor-cgl/coinor-cgl_0.60.3+repack1-1.dsc Changes since the last upload: * QA upload. * New upstream version 0.60.3+repack1 * Update Standards-Version to 4.5.0 * Changes to include BuildTools in source, needed to use autoreconf during build. - Change URI in d/watch - Update Files-Excluded in d/copyright - Change path in d/coinor-libcgl-doc.examples - Change path in d/tests/check1 - Change to autoreconf in d/rules * Update version on runtime and build-dependencies. * Compress Makefile in examples folder Regards,
Bug#951523: dolphin: installing dolphin on xfce is missing a kde component for file transfer
[disclaimer: I'm not the package maintainer] Hi, kuiserver is part of the plasma-workspace package, installing it could probably fix the problem. Package: dolphin Version: 4:18.08.0-1 Severity: normal Dear Maintainer, Installing dolpin using xfce as desktop environment on debian 10.3. Copying files do NOT show the file transfer dialog. So you never know when it is done. This is particular bad when copying to a slow USB stick. As the stick might be removed before the transfer is finished, corrupting the file system It seems the problem has been also detected already with Manjaro: https://forum.manjaro.org/t/bug-kde-applications-do-not-pull-in-kuiserver-which-now-is-in-plasma-workspace/69675 Unfortunatlly there is no kuiserver package in debian. Installing the complete plasma-desktop as a workaround pulls in a lot of dependencies filling 1GB of diskspace. Thus only adding this as a dependency might not be the best idea. But I could not figure out which packet is acctually needed. -- System Information: Debian Release: 10.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-0.bpo.3-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dolphin depends on: ii baloo-kf5 5.54.0-1 ii kinit 5.54.0-1 ii kio5.54.1-1 ii libc6 2.28-10 ii libdolphinvcs5 4:18.08.0-1 ii libkf5baloo5 5.54.0-1 ii libkf5baloowidgets54:18.08.1-1 ii libkf5bookmarks5 5.54.0-1 ii libkf5codecs5 5.54.0-1 ii libkf5completion5 5.54.0-1 ii libkf5configcore5 5.54.0-1+deb10u1 ii libkf5configgui5 5.54.0-1+deb10u1 ii libkf5configwidgets5 5.54.0-1 ii libkf5coreaddons5 5.54.0-1 ii libkf5crash5 5.54.0-1 ii libkf5dbusaddons5 5.54.0-1 ii libkf5filemetadata35.54.0-1 ii libkf5i18n55.54.0-1 ii libkf5iconthemes5 5.54.0-1 ii libkf5itemviews5 5.54.0-1 ii libkf5jobwidgets5 5.54.0-1 ii libkf5kcmutils55.54.0-1 ii libkf5kiocore5 5.54.1-1 ii libkf5kiofilewidgets5 5.54.1-1 ii libkf5kiowidgets5 5.54.1-1 ii libkf5newstuff55.54.0-2 ii libkf5notifications5 5.54.0-1 ii libkf5parts5 5.54.0-1 ii libkf5service-bin 5.54.0-1 ii libkf5service5 5.54.0-1 ii libkf5solid5 5.54.0-1 ii libkf5textwidgets5 5.54.0-1 ii libkf5widgetsaddons5 5.54.0-1 ii libkf5xmlgui5 5.54.0-1 ii libphonon4qt5-44:4.10.2-1 ii libqt5core5a 5.11.3+dfsg1-1+deb10u3 ii libqt5dbus55.11.3+dfsg1-1+deb10u3 ii libqt5gui5 5.11.3+dfsg1-1+deb10u3 ii libqt5widgets5 5.11.3+dfsg1-1+deb10u3 ii libqt5xml5 5.11.3+dfsg1-1+deb10u3 ii libstdc++6 8.3.0-6 ii phonon4qt5 4:4.10.2-1 Versions of packages dolphin recommends: ii kimageformat-plugins 5.54.0-1 ii kio-extras4:18.08.3-1 ii ruby 1:2.5.1 Versions of packages dolphin suggests: pn dolphin-plugins -- no debconf information
Bug#951599: ITP: clipman -- simple clipboard manager for Wayland
Package: wnpp Severity: wishlist Owner: Alexandre Viau * Package name: clipman Version : 1.2.0+git20200212.d898c27-1 Upstream Author : yory8 * URL : https://github.com/yory8/clipman * License : MIT Programming Lang: Go Description : simple clipboard manager for Wayland Cheers, -- Alexandre Viau av...@debian.org
Bug#951600: "debian/rules build" fails to call defined build-indep target, causing FTBFS
Source: zoneminder Version: 1.32.3-2 User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu focal ubuntu-patch Severity: serious Justification: policy violation in behaviour of build target causing FTBFS Tags: patch Hi, In Ubuntu this package FTBFS. The reason seems to be that the build-indep target isn't running when sbuild invokes "debian/rules build", causing a later dh_install against the zoneminder-doc package to fail because files produced by that target don't exist. As far as I understand, the cause is that debhelper's dh sequencer doesn't itself call the build-indep target when invoked via "debian/rules build". So when using debhelper, a "build-indep" rule appears to be wrong, and override_dh_auto_build-indep needs to be used to override the appropriate behaviour instead. Here is the patch: diff -Nru zoneminder-1.32.3/debian/rules zoneminder-1.32.3/debian/rules --- zoneminder-1.32.3/debian/rules 2018-11-07 23:11:36.0 + +++ zoneminder-1.32.3/debian/rules 2020-02-18 15:21:25.0 + @@ -34,8 +34,9 @@ dh_clean $(MANPAGES1) $(RM) -r docs/_build docs/installationguide web/api/app/Plugin/Crud -build-indep: +override_dh_auto_build-indep: $(MAKE) -C docs html + dh_auto_build MANPAGES1 = \ dbuild/scripts/zmupdate.pl.1\ signature.asc Description: PGP signature
Bug#948789: [racket-dev] build failures for 7.5 on debian armhf
David Bremner writes:
> Matthew Flatt writes:
>
>> At Fri, 17 Jan 2020 09:43:15 -0400, David Bremner wrote:
>>> Matthew Flatt writes:
>>> > At Fri, 17 Jan 2020 08:31:22 -0400, David Bremner wrote:
>>> >> => 0xb6ea3254 <+8>: stmdb sp!, {r4, r5, r6, r7, r8, r9, r10, r11,
>>> >> lr}
>>> >>0xb6ea3258 <+12>:add r3, pc
>>> >
>>> > That certainly looks like a valid ARM instruction. Maybe the processor
>>> > is expecting Thumb instructions. What does `print $cpsr` report?
>>>
>>> (gdb) print $cpsr
>>> $3 = 196656
>>
>> Since bit 5 is set, I think that means the processor was expecting
>> Thumb instructions, which at least explains the error.
>>
>> To confirm that it's some bad jump or mismanagement of the mode by the
>> Racket JIT, does changing "racket/src/lightning/arm/asm.h" to disable
>> Thumb support allow the build to work?
>
> I'm not very sure I'm doing the right thing, but With the following
> change, I get the same build failure.
>
> % diff -u asm.h~ asm.h
> --- asm.h~ 2019-12-30 19:12:36.0 +
> +++ asm.h 2020-01-17 16:06:45.964573092 +
> @@ -2299,4 +2299,7 @@
> #define THUMB2_CLZ 0xfab0f080
> #define T2_CLZ(rd,rm) thumb2_orrr(THUMB2_CLZ,rd,rm,rm)
>
> +# undef JIT_ARM_THUMB
> +# define JIT_ARM_THUMB 0
> +
> #endif /* __lightning_asm_h */
Can you try to define that earlier?
https://github.com/racket/racket/blob/5377d00c90480e73e0863203d35d7a1dc373195d/racket/src/racket/src/lightning/arm/asm.h#L150
Remove lines 150-152 and do the same:
#undef JIT_ARM_THUMB
#define JIT_ARM_THUMB 0
It looks like this header file assumes all armv7 have thumb2 support which is
why its
generating that instruction. (line 132)
--
Paulo Matos
Bug#951004: libmath-prime-util-gmp-perl: Patch for FTBFS with gmp 6.2.0: test failure
On Tue, 18 Feb 2020 18:26:09 +0100, Marco Bodrato wrote: > > I tried to convert it into the following unified patch: > > Does this look correct? > Perfect. Thanks for the confirmation! I added the information to the upstream ticket, and I'll upload the package with the patch shortly to debian/unstable. Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- NP: Beatles signature.asc Description: Digital Signature
Bug#951598: restore the tmpfs(5) manpage
Package: manpages Version: 4.16-2 Severity: normal In #847998 we removed the tmpfs(5) manpage because it conflicted with the initscripts. But now, we have systems that are installed, by default, without that package, which means we don't have a tmpfs(5) manpage at all! That's quite unfortunate, and I believe it should be fixed. In #847998 it was agreed that the conflict should be somehow resolved. I filed a bug against initscripts (#951596) so that they just remove their version of the manpage. My argument is that initscripts can use the normal tmpfs(5) syntax (from fstab, not /etc/default) now so there doesn't need to be special configuration for that. And if there should be, I believe it is reasonable that it sits in a different manpage, since we can definitely use tmpfs without any init system at all: it's part of the kernel, after all. (Well, Linux needs *some* init system, but the point I'm making here is that you can use tmpfs(5) with init=/bin/sh.) So I'm opening this bug in manpages so we restore this manpage, but it shouldn't be done until initscripts removes theirs, naturally. -- System Information: Debian Release: 10.3 APT prefers stable-debug APT policy: (500, 'stable-debug'), (500, 'stable'), (1, 'experimental'), (1, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-8-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE=fr_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled manpages depends on no packages. manpages recommends no packages. Versions of packages manpages suggests: ii man-db [man-browser] 2.8.5-2 -- no debconf information
Bug#951597: RFA: approx -- caching proxy server for Debian archive files
Package: wnpp Severity: normal I request an adopter for the approx package. I no longer use approx myself (I just use a Squid proxy now) and I haven't done much OCaml coding recently, so it's time to move on. I haven't done an upload since the move from alioth to salsa, and it seems I no longer have permission to do so, so an adopter should probably set the "Maintainer" to the OCaml team and remove the "Uploaders" field. The package description is: Approx is an HTTP-based proxy server for Debian-style package archives. It fetches files from remote repositories on demand, and caches them for local use. . Approx saves time and network bandwidth if you need to install or upgrade .deb packages for a number of machines on a local network. Each package is downloaded from a remote site only once, regardless of how many local clients install it. The approx cache typically requires a few gigabytes of disk space. . Approx also simplifies the administration of client machines: repository locations need only be changed in approx's configuration file, not in every client's /etc/apt/sources.list file. . Approx can be used as a replacement for apt-proxy, with no need to modify clients' /etc/apt/sources.list files, or as an alternative to apt-cacher.
Bug#937009: mercurial: Python2 removal in sid/bullseye
On Thu, Oct 31, 2019 at 02:25:22PM +0100, Matthias Klose wrote: > Julian, you added the py2keep tag. Reading the upstream mail for the 5.2 > release, it looks like the release will happen next month. So why keeping > it as Python2 version for the bullseye release? Before switching in sid I'd want to: - be able to use the python3 version myself - give extensions some time to figure out their own switch - ideally not regress significant functionality; e.g. python-subversion is still not available for python3 I don't know what that means in terms of timeframe, it may or may not happen in time for bullseye, but I'm also not in a rush and I'd rather not break stuff by switching too early. Cheers, Julien
Bug#951596: tmpfs(5) manpage conflicts with upstream tmpfs(5)
Package: initscripts Severity: normal In the initscripts package, we ship a tmpfs(5) manpage that documents how the (sysv) init systems handles and configures tmpfs. Historically, this was done because we had a /etc/init.d/tmpfs thing that would create the tmpfs on the fly. But now we can specify the tmpfs as any other filesystem in /etc/fstab and, from what I understand, sysvinit will handle that just fine. But there *is* an "upstream" (as in "official manpages") manpage for tmpfs(5) that has its own documentation of the filesystem and how to configure it in /etc/fstab. When a system does not have initscripts installed (e.g. any Debian system with the default configuration since stretch at least), the tmpfs(5) manpage is simply unavailable because of this conflict. How about we put this one to rest and revert back to the upstream documentation? It would for both new and old and will make all our lives much easier. :) The corrolary to this would be to reintroduce the tmpfs(5) manpage in the manpages package, which was removed in #847998. A. -- System Information: Debian Release: 10.3 APT prefers stable-debug APT policy: (500, 'stable-debug'), (500, 'stable'), (1, 'experimental'), (1, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-8-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE=fr_CA.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 initscripts depends on: ii coreutils 8.30-3 ii debianutils 4.8.6.1 ii lsb-base10.2019051400 ii mount 2.33.1-0.1 pn sysv-rc | file-rc | openrc ii sysvinit-utils 2.93-8 Versions of packages initscripts recommends: ii e2fsprogs 1.44.5-1+deb10u3 ii psmisc 23.2-1 initscripts suggests no packages.
Bug#951004: libmath-prime-util-gmp-perl: Patch for FTBFS with gmp 6.2.0: test failure
Ciao, Il 2020-02-18 16:49 gregor herrmann ha scritto: Il 2020-02-18 12:39 Marco Bodrato ha scritto: > A proposed patch: I tried to convert it into the following unified patch: Does this look correct? Perfect. (The package builds and passes all tests with the above patch.) Great! Ĝis, m -- http://bodrato.it/papers/
Bug#908577: closed by Debian FTP Masters (reply to Anthony Fok ) (Bug#908577: fixed in autokey 0.95.9-1)
Great, thanks Anthony for taking care. signature.asc Description: This is a digitally signed message part
Bug#951595: isc-dhcp-client: disallowing ipv6 in sysctl breaks dhcp address renewal
Sorry,typo: unsetting ipv6 (/etc/sysctl.conf -> net.ipv6.conf.all.disable_ipv6 = 1 net.ipv6.conf.default.disable_ipv6 = d net.ipv6.conf.lo.disable_ipv6 = 1) On Tue, 18 Feb 2020, 18:03 Cosimo Simeone, < cosimo.simeone+debian...@gmail.com> wrote: > Package: isc-dhcp-client > Version: 4.4.1-2 > Severity: normal > Tags: ipv6 > > Dear Maintainer, > >* What led up to the situation? i disabled ipv6 networking in > /etc/sysctl.conf, and since then dhcp ip renewal fails with error relater > to RFC-3442 >* What exactly did you do (or not do) that was effective (or > ineffective)? Disable ipv6 networking >* What was the outcome of this action? dhcp ip renewal fails with error > relater to RFC-3442; lost of networking >* What outcome did you expect instead? well.. networking to work.. :-) > > Longer desciption: > unsetting ipv6 (/etc/sysctl.conf -> net.ipv6.conf.all.disable_ipv6 = 0 > net.ipv6.conf.default.disable_ipv6 = 0 net.ipv6.conf.lo.disable_ipv6 = 0) > generates dhcp 3442 non zero exit error. > Disabling 3442 (dhclient.conf, removing request > rfc3442-classless-static-routes) raises RTNETLINK answers: Permission denied > > > > -- System Information: > Debian Release: 10.3 > APT prefers stable-updates > APT policy: (500, 'stable-updates'), (500, 'stable') > Architecture: amd64 (x86_64) > > Kernel: Linux 4.19.0-8-amd64 (SMP w/1 CPU core) > 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 /usr/bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages isc-dhcp-client depends on: > ii debianutils4.8.6.1 > ii iproute2 4.20.0-2 > ii libc6 2.28-10 > ii libdns-export1104 1:9.11.5.P4+dfsg-5.1 > ii libisc-export1100 1:9.11.5.P4+dfsg-5.1 > > Versions of packages isc-dhcp-client recommends: > ii isc-dhcp-common 4.4.1-2 > > Versions of packages isc-dhcp-client suggests: > pn avahi-autoipd > pn isc-dhcp-client-ddns > pn resolvconf > > -- Configuration Files: > /etc/dhcp/dhclient.conf changed: > send host-name = gethostname(); > request subnet-mask, broadcast-address, time-offset, routers, > domain-name, domain-name-servers, domain-search, host-name, > dhcp6.name-servers, dhcp6.domain-search, dhcp6.fqdn, > dhcp6.sntp-servers, > netbios-name-servers, netbios-scope, interface-mtu, > rfc3442-classless-static-routes, ntp-servers; > > > -- no debconf information >
Bug#937009: (no subject)
On Thu, Feb 06, 2020 at 09:44:03PM +0100, Christoph Mathys wrote: > Any idea when this package will switch to python3? I cannot drop python2 > support from mercurial-keyring until mercurial switches to python3. I don't have a timeline yet. Is there a particular reason you need to drop python2 support from mercurial-keyring soon? Cheers, Julien
Bug#950772: Patch: swupdate: FTBFS during separate arch/indep builds
Hi Bastian, On 18.02.20 01:36, Bastian Germann wrote: > Hi, > > I have created a merge request at > https://salsa.debian.org/debian/swupdate/merge_requests/2 which fixes > the issue. Please consider merging and uploading to sid. > Thanks for this - anyway, debian package was officially pushed by SZ Lin and Nobuhiro (both in CC), I have no write access to that repo. Stefano -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de =
Bug#907576: Bug#915386. libfdk-aac-dev: New upstream version 2.0.0 available, Re: Bug#907576. ITP: dream --A Software Digital Radio Mondiale Receiver
Hello: Completion of Dream Bug#907576 requires the newer codec of libfdk-aac-dev 2.0.0, which has also been requested by Bug#915386 (latest at Github is 2.0.1). Dream cannot function properly with the current 1.6 codec in Debian. Note also that libfdk-aac-dev is part of a larger source code package fdk-aac. Is anyone working to complete 915386? I am willing to try to package it (ie, ITP), subject to my limited experience in Debian. This probably involves uploading the larger package fdk-aac. Suggestions or help is welcome. Thank You, Garie Miller -- Take back your privacy. Switch to www.StartMail.com
Bug#951595: isc-dhcp-client: disallowing ipv6 in sysctl breaks dhcp address renewal
Package: isc-dhcp-client Version: 4.4.1-2 Severity: normal Tags: ipv6 Dear Maintainer, * What led up to the situation? i disabled ipv6 networking in /etc/sysctl.conf, and since then dhcp ip renewal fails with error relater to RFC-3442 * What exactly did you do (or not do) that was effective (or ineffective)? Disable ipv6 networking * What was the outcome of this action? dhcp ip renewal fails with error relater to RFC-3442; lost of networking * What outcome did you expect instead? well.. networking to work.. :-) Longer desciption: unsetting ipv6 (/etc/sysctl.conf -> net.ipv6.conf.all.disable_ipv6 = 0 net.ipv6.conf.default.disable_ipv6 = 0 net.ipv6.conf.lo.disable_ipv6 = 0) generates dhcp 3442 non zero exit error. Disabling 3442 (dhclient.conf, removing request rfc3442-classless-static-routes) raises RTNETLINK answers: Permission denied -- System Information: Debian Release: 10.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-8-amd64 (SMP w/1 CPU core) 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 /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages isc-dhcp-client depends on: ii debianutils4.8.6.1 ii iproute2 4.20.0-2 ii libc6 2.28-10 ii libdns-export1104 1:9.11.5.P4+dfsg-5.1 ii libisc-export1100 1:9.11.5.P4+dfsg-5.1 Versions of packages isc-dhcp-client recommends: ii isc-dhcp-common 4.4.1-2 Versions of packages isc-dhcp-client suggests: pn avahi-autoipd pn isc-dhcp-client-ddns pn resolvconf -- Configuration Files: /etc/dhcp/dhclient.conf changed: send host-name = gethostname(); request subnet-mask, broadcast-address, time-offset, routers, domain-name, domain-name-servers, domain-search, host-name, dhcp6.name-servers, dhcp6.domain-search, dhcp6.fqdn, dhcp6.sntp-servers, netbios-name-servers, netbios-scope, interface-mtu, rfc3442-classless-static-routes, ntp-servers; -- no debconf information
Bug#951594: test with lintian get error 512
Package: lintian Version: 2.52.0 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello, running lintian over pdbuild on simple-scan 3.34.4 runs into error 512: [quote] +++ lintian output +++ su: warning: cannot change directory to /nonexistent: No such file or directory Use of uninitialized value in pattern match (m//) at /usr/share/perl/5.30/Text/Balanced.pm line 132. Use of uninitialized value $delimited in subtraction (-) at /usr/share/lintian/collection/src-orig-index line 212. Use of uninitialized value $delimited in substr at /usr/share/lintian/collection/src-orig-index line 212. substr outside of string at /usr/share/lintian/collection/src-orig-index line 212. Use of uninitialized value in concatenation (.) or string at /usr/share/lintian/collection/src-orig-index line 212. Cannot parse tar output for /tmp/temp-lintian-lab-6LMpvowKon/pool/s/simple- scan/simple-scan_3.34.4-1_source/src-orig-index.db: drwxr-xr-x bob/bob 0 2020-02-13 20:16:03.5978043 "simple-scan-3.34.4/" at /usr/share/lintian/collection/src-orig-index line 221. warning: collection src-orig-index failed for source package simple-scan, skipping check error: 512 +++ end of lintian output +++ I: user script /var/cache/pbuilder/build//154490/tmp/hooks/B90lintian finished [/quote] If you need more infos please ask me. CU Jörg - -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (300, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-3-amd64 (SMP w/6 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian depends on: ii binutils 2.34-2 ii bzip21.0.8-2 ii diffstat 1.63-1 ii dpkg 1.19.7 ii dpkg-dev 1.19.7 ii file 1:5.38-4 ii gettext 0.19.8.1-10 ii gpg 2.2.19-1 ii intltool-debian 0.35.0+20060710.5 ii libapt-pkg-perl 0.1.36+b2 ii libarchive-zip-perl 1.67-1 ii libberkeleydb-perl 0.62-1+b1 ii libcapture-tiny-perl 0.48-1 ii libcgi-pm-perl 4.46-1 ii libclass-accessor-perl 0.51-1 ii libclass-xsaccessor-perl 1.19-3+b3 ii libclone-perl0.43-2 ii libdpkg-perl 1.19.7 ii libemail-valid-perl 1.202-1 ii libfile-basedir-perl 0.08-1 ii libfile-find-rule-perl 0.34-1 ii libfont-ttf-perl 1.06-1 ii libio-async-loop-epoll-perl 0.20-1 ii libio-async-perl 0.75-1 ii libipc-run-perl 20180523.0-2 ii libjson-perl 4.02000-2 ii liblist-compare-perl 0.53-1 ii liblist-moreutils-perl 0.416-1+b5 ii libmldbm-perl2.05-2 ii libmoo-perl 2.003006-1 ii libmoox-aliases-perl 0.001006-1 ii libnamespace-clean-perl 0.27-1 ii libpath-tiny-perl0.108-1 ii libtext-levenshtein-perl 0.13-1 ii libtimedate-perl 2.3100-1 ii libtry-tiny-perl 0.30-1 ii libtype-tiny-perl1.008001-2 ii liburi-perl 1.76-2 ii libxml-libxml-perl 2.0134+dfsg-1+b1 ii libyaml-libyaml-perl 0.80+repack-2+b1 ii man-db 2.9.0-2 ii patchutils 0.3.4-2+b1 ii perl [libdigest-sha-perl]5.30.0-9 ii t1utils 1.41-3 ii xz-utils 5.2.4-1+b1 Versions of packages lintian recommends: ii libperlio-gzip-perl 0.19-1+b6 Versions of packages lintian suggests: pn binutils-multiarch ii libhtml-parser-perl3.72-3+b4 ii libtext-template-perl 1.58-1 - -- debconf-show failed -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEY+AHX8jUOrs1qzDuCfifPIyh0l0FAl5MDd0ACgkQCfifPIyh 0l3xDg//Ts97NDhKsZfKHSs9WTDexx3prY/kyT9yC7tPD+OJ7rkRzpJozdWbGPZJ UvlwRI5YpGiNIHp5Vf75TKac/jWcoAhelPGpC08+qi5zN3ojzFZ3C+b6VcYryPaW 9KwDJkc1Cew8C4ZmrT7aUcAJgE9GX+M9aB1p31pBEmyLbKygGV1hKIsLL6WmLCvT VHvPEH+FEuAjsqFYcIfJ9EwM4KvWlTIckRqVtaVZx78t6S0wogDUsVyw0qTjXaIx 2MtnVfJ/oC1Bq9rWIOA1mg0naiGS0PBuMVdlAed3GKZAmyVot/gm5un8RyNVLWXp vuRe/YYY/Ipc1C6IrAbE/6vbfqqVet/mGdCsgQKuqAx07tRdRWNPFhxf2+ghnUyS LTVgVgS3QNOdAyeg6SYohi0Nl+F9+RhzIDxBcLWB0BIB5uEWstoz2hJn+/mYx85Y 4ZDPyqRYOzanK+eJ6/bB/yIH7hGYDgdx0RQg6eBU+UvO2vFPOFUsiRFAxzveDPaa Ejaq2UTjXPtSTWVA+x4st3MkW5TOYDt38cHoLYQaprU8i74Ch9QwqSvLUJRGsffa IRB4Xy0ygIVx4phtX8OKklyIXCM+bgla5DtSnLeIK5+8ZErj3Qg491qkeBX3kRlQ n3TMuVPR+Z5YiDnuK+A1ta+tIC3cDZIzM+gup1lRXgD9L8KqZK4= =z/Ny -END PGP SIGNATURE-
Bug#949331: marked as done (fwknop-server: consider building with nfq support)
I have reverted this in 2.6.10-7. Building with NFQ support disables PCAP support. I'm not sure it's possible to have both. Is there any advantage to migrating users to NFQ? Francois -- https://fmarier.org/ signature.asc Description: PGP signature
Bug#907576: Bug#915386. libfdk-aac-dev: New upstream version 2.0.0 available, Re: Bug#907576. ITP: dream --A Software Digital Radio Mondiale Receiver
Dear Jonas: Yes. Dream Bug #907576 requires the newer codec of libfdk-aac-dev 2.0.0 which was also requested by Bug#915386. Without it Dream cannot function per current standards. OK. I will file at Bug#915386. Thank You, Garie Miller -- Take back your privacy. Switch to www.StartMail.com
Bug#946465: bumping bug report because of buggy auto-removals
As I mentioned in a previous mail to debian-release the dependency tracking in auto-removals seems to be buggy, this has resulted in britney trying and failing to remove rust-rand. This in turn blocks any attempt to migrate the new (and fixed) rust-rand. I am bumping this bug report to get the broken auto-removals out of the way so that britney attempts to migrate rust-rand to testing (and either it succeeds, in which case great, or we at least find out what is blocking it).
Bug#950341: kubectx: kubernetes has been requested to be removed
Hi, On Fri, 31 Jan 2020 16:01:19 +0100 Andreas Beckmann wrote: > the kubernetes package has been requested to be removed (#950247), but > kubectx still build-depends on it. > > Please find a solution. Just adding my two cents, as I'm the one who originally reported the RM bug against kubernetes. I originally filed the RM bug, because I didn't see how the kubernetes package adds any value for users. In the worst case someone might use it and be surprised by the bugginess and old age of the package or even get hit by its abundant security issues. However, I have no particular technical problem with the package, so it would be fine by me if kubernetes stays in unstable just to satisfy the dependency for kubectx until a better solution is found. I just noticed that there are also RM bugs for dependencies of kubernetes (#902180) and apparently they actually do have a good reason to remove the package, so there actually seems to be a need to find a solution for this soon. Unfortunately, right now, I don't see a better solution than removing kubectx from unstable. Regards Sven signature.asc Description: OpenPGP digital signature
Bug#756305: Blog post moved (Was: Finally closing ITP not to be fulfilled)
A small update for anyone arriving here hunting a current Drupal package. It seems the mentioned blog post has moved to: https://gwolf.org/debian/drupal/2016/12/26/giving-up-on-the-drupal-8-debianization.html As mentioned in it, the repository with debian packaging for Drupal 8 no longer exists. -- /Martin Due to excessive BTS scraped spam, my sender email is not monitored. I am however subscribed to this bug report, and can be reached privately on the email address with userpart "fix-199392", and the same domain as the one this email is sent from, but with "noreply" replaced by "please". (Don't make the address known to the spammers, please. Do use Bcc if including me in a publicly archived thread!)
Bug#951004: libmath-prime-util-gmp-perl: Patch for FTBFS with gmp 6.2.0: test failure
On Tue, 18 Feb 2020 16:19:05 +0100, Marco Bodrato wrote:
> Il 2020-02-18 12:39 Marco Bodrato ha scritto:
> > A proposed patch:
> Looking at it twice, it is probably better to propose a cleaner patch, that
> can be adopted also upstream:
Thanks for your help!
I have to admit that I haven't seen a non-unified patch in ages, and
unfortunately it doesn't apply [0].
I tried to convert it into the following unified patch:
#v+
--- a/squfof126.c
+++ b/squfof126.c
@@ -43,15 +43,12 @@
return v;
}
static INLINE void mpz_set64(mpz_t n, SQUFOF_TYPE v) {
- if (v == 0) {
-mpz_set_ui(n,0);
- } else if (GMP_LIMB_BITS < 64 || sizeof(mp_limb_t) < sizeof(SQUFOF_TYPE)) {
+ if (v > ULONG_MAX) {
mpz_set_ui(n, (uint32_t)(v >> 32));
mpz_mul_2exp(n, n, 32);
mpz_add_ui(n, n, (uint32_t)v);
} else {
-n->_mp_d[0] = v;
-n->_mp_size = 1;
+mpz_set_ui(n, v);
}
}
#v-
Does this look correct? And/or could you try to 1) produce a patch
with "diff -u" and 2) send it as an attachment so it doesn't get
mangled?
(The package builds and passes all tests with the above patch.)
Cheers,
gregor
[0]
% patch --dry-run --verbose -p0 < ~/tmp/perl/gmp.patch
Hmm...patch: malformed patch at line 11: {
--
.''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org
: :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06
`. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
`- NP: Element Of Crime: Narzissen und Kakteen
signature.asc
Description: Digital Signature
Bug#950247: RM: kubernetes -- RoQA; Unmaintained and RC buggy
Am Fri, 31 Jan 2020 14:21:48 +0200 schrieb Juhani Numminen : > Please also consider any packages that depend on kubernetes, i.e. > kubectx. Should it be removed then as well? Is kubectx maintainer > aware of the plan to remove kubernetes? Hi Juhani, Yes, I forgot to consider the reverse dependencies of kubernetes. My apologies. I will contact the maintainer of kubectx and ask what they think about this and how they would like to go forward. Regards Sven pgpM2aZ25XpFk.pgp Description: Digitale Signatur von OpenPGP
Bug#951046: ibus: Numpad not working in GDM lockscreen when ibus installed in Stretch
This is not related to an accessibility option since there is the direct workaround I described. However I should have indeed tested on a "stock" Stretch, we have a custom one but not that much so I saw no connection... Anyway this bug can be closed then, I can't reproduce either on stock Stretch. We found no explication but a solid workaround : org.gnome.desktop.input-sources xkb-options set as ['numpad:mac']. Sorry for your time, have a nice day
