Bug#968438: Should this really be RC?
On 2020-08-20 22:44, Lisandro Damián Nicanor Pérez Meyer wrote: severity 968438 normal thanks The problem might also come from previous configuration, both a fellow co maintainer and I tried to create annotations and they worked. Yes, they are now presented as a toolbar, but they are there. And moreover the buttons do what they are intended to do. ... All in all this is at most a normal bug which might be triggered by previous configs (I'm still speculating), but definitely a normal bug. Drew: please try the above, you might be able to solve the issue for other people too. Inspecting config files, there's .config/okularrc but there's also .config/okularpartrc I find I can reproduce (and eliminate) the bug by removing the second config file .config/okularpartrc Removing it, the functions operate as labelled. Reinstating it, the functions break as reported. So removing .config/okularpartrc works around the bug. Drew
Bug#646683: Kann ich Ihnen vertrauen?
Hallo, ich bin Omar Ali, ich bin Banker hier in Dubai. Ich habe Sie bezüglich eines Kontos eines Staatsbürgers Ihres Landes kontaktiert. Dieser Mann starb vor 12 Jahren und erwähnte niemanden, der sein bei unserer Bank hinterlegtes Geld geerbt hatte. Die Bank erlaubte mir, den nächsten Verwandten mit einem verstorbenen Kunden zu finden, aber ich fand ihn nicht. Dieses Konto wird beschlagnahmt, wenn niemand erklärt, dass das Bankkonto der nächste Angehörige ist. Ich habe mich daher entschlossen, Sie zum gegenseitigen Nutzen zu kontaktieren. Ich warte auf Ihre Antwort für weitere Details. Respektvoll, Omar Ali
Bug#968762: matchbox-desktop FTCBFS: configures for the build architecture
Source: matchbox-desktop Version: 2.2+git20200512-1 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs matchbox-desktop fails to cross build from source, because it does not pass --host to ./configure. The easiest way of doing so - using dh_auto_configure - mkaes matchbox-desktop cross buildable. Please consider applying the attached patch. Helmut diff --minimal -Nru matchbox-desktop-2.2+git20200512/debian/changelog matchbox-desktop-2.2+git20200512/debian/changelog --- matchbox-desktop-2.2+git20200512/debian/changelog 2020-06-15 17:49:49.0 +0200 +++ matchbox-desktop-2.2+git20200512/debian/changelog 2020-08-21 06:59:10.0 +0200 @@ -1,3 +1,10 @@ +matchbox-desktop (2.2+git20200512-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Let dh_auto_configure pass --host to ./configure. (Closes: #-1) + + -- Helmut Grohne Fri, 21 Aug 2020 06:59:10 +0200 + matchbox-desktop (2.2+git20200512-1) unstable; urgency=medium * New upstream release from Yocto Project git. diff --minimal -Nru matchbox-desktop-2.2+git20200512/debian/rules matchbox-desktop-2.2+git20200512/debian/rules --- matchbox-desktop-2.2+git20200512/debian/rules 2020-06-15 17:49:49.0 +0200 +++ matchbox-desktop-2.2+git20200512/debian/rules 2020-08-21 06:59:09.0 +0200 @@ -6,4 +6,4 @@ dh $@ override_dh_auto_configure: - ./configure --prefix=/usr --enable-startup-notification --sysconfdir=/etc + dh_auto_configure -- --enable-startup-notification
Bug#966649: Request for feedback on upload_history re-implementation
Hi Lucas! I'm rereading this, and I have a follow-up question. It looks to me, based on reading the bug carefully, that /srv/ udd.debian.org/email-archives/debian-devel-changes/debian-devel-changes.current on ullmann successfully receives any new emails to debian-devel-changes. Is that accurate? If so, excellent -- I can incorporate that into my design. If not, then I can talk to DSA to discuss what might be best (polling lists.debian.org over HTTPS once per 2 min vs. fixing that file). Cheers! Asheesh.
Bug#968708: debug-me: /quit in control window does not end debug-me session
Package: debug-me Version: 1.20190926-2 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I tried the version in buster and the one in testing, and in neither case does the session ends. This seems like a potential security issue, since a naive user may assume they have terminated a session when they have not. - -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.7.0-2-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages debug-me depends on: ii libc6 2.31-3 ii libffi7 3.3-4 ii libgmp10 2:6.2.0+dfsg-6 ii zlib1g1:1.2.11.dfsg-2 Versions of packages debug-me recommends: ii debian-keyring 2020.06.24 ii gnupg 2.2.20-1 debug-me suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAl8+fYMACgkQA0U5G1Wq FSEpyA/+MPD62dQ/vAWqYWMJREKA7jY5hCbVTw8GOV8+woui010jlNXutgMj5I2z QDL/isumjwy2Zut6u++QXQd/8+xv1BnOWZH03WBmQKGQQUeP2YZ+pQS03S4xxiNK d6xQoUEkGdZzDsaD0iexQo1Nt4s6AePMh8xjllJJKBtJh6jMcRmYHT/aBelItJBw 0P9fUUoug4bc4oiWMtYCVxh08r+a2Z37zxSbL8ce1sCcYtYvMROUzN1ZZuahTRsv WI2Kf2F45mUhJUUIgbDyVQFKEj21UJybEgZHRtgOiIA6PTQl+if3mp+TyC71eoSH HFL6PigouIVlgTVFrm49pxHSJZUTs3KYTc5LbFvpD3+Q2Lh/YrDpg/hf/brnwlPm KQUnQvhKvgQ3CSFFrl4jmCwTGXPdw6KCF2yoe9voP6QHH4t0QP7mSF4O5ZAVI3uy Qz1wsL63OzH2gzSpGF+ljafyaO8mTb7pkinsV9kJgBLF0Mrru/ZheZ2vNqG5qv5F I3UA0IGfxECriSR+1mFo1Ol7avFyFFM1jyumYi0R7tNOpIUJi2P75LBGh5qzvDqj P537fOJeNls2YwZLmHJ50pqRETEUITCiWGnRUV071U0U4JH+20tBsW0ppCyoaHHy xVp+LrOI6onsZW04OxCFvXlLZIK7gmzc0zve0Y7c/I2rZiPymvs= =0D8M -END PGP SIGNATURE-
Bug#968709: libcmark-gfm-dev: Missing header files
Package: libcmark-gfm-dev Version: 0.28.3.gfm.19-3 Severity: grave Justification: renders package unusable Dear maintainer, The libcmark-gfm-dev package does not provide the header files for cmark-gfm. This renders the package unusable as it cannot be used for compilation against the cmark-gfm library. Best, -- Ilias
Bug#908654: thunderbird: Drop dependency on libgtk2
Control: tag 908654 + pending Control: tag 967771 + upstream Hi, Carsten Schoenert (2020-08-19): > If it applies on d/experimental and you get a successful build with a > fully working binary package I've nothing against you push your > contribution directly to salsa afterwards. Thank you for the quick feedback. I confirm it builds and works for basic usage (read email over IMAP, send email over SMTP, played quite a bit with the new OpenPGP support), so I've pushed the proposed patch to the debian/experimental branch. Regarding "fully working", for a program the size of Thunderbird, I would need you to set clearer expectations before I can pretend my testing meets them: I certainly did not test every single feature :) Note that this does not entirely solve #967771 yet: while the runtime dependency is gone, the build-dependency is still there. I confirm the upstream build system requires it ⇒ tagging accordingly.
Bug#968720: RM: get-flash-videos -- ROM; Abandoned upstream, broken for many use cases
Package: ftp.debian.org Severity: normal Hi, as I wrote on https://bugs.debian.org/960838 3 months ago: Upstream has been inactive for 2 years. This kind of software needs constant updating to remain useful, as indicated by #750872 and the pile of non-handled upstream bug reports that report breakage on website X or Y. Given this, it's not surprise to me that popcon has been steadily decreasing since 2015. In contrast, youtube-dl is actively maintained and its popcon steadily increasing. Judging by the package descriptions, youtube-dl claims to support vastly more websites, including most of those that get-flash-videos itself claims to support. So at first glance, I don't think we're serving our users well by including get-flash-videos in the distribution. I'd rather see them not have to wonder and choose, and instead directly find the best maintained piece of software. On top of this,get-flash-videos is the only reverse-dependency of libdata-amf-perl, which causes trouble (#845812). Thanks in advance, cheers!
Bug#957219: foremost: diff for NMU version 1.5.7-9.1
Glad to help! Em qui., 20 de ago. de 2020 às 12:24, Raúl Benencia escreveu: > > Hi Joao, > > This is perfect. Thanks for taking care of it. > > On Wed, Aug 19, 2020 at 03:52:30PM -0300, Joao Eriberto Mota Filho wrote: > > Control: tags 957219 + patch > > Control: tags 957219 + pending > > > > Dear maintainer, > > > > I've prepared an NMU for foremost (versioned as 1.5.7-9.1) and > > uploaded it to DELAYED/2. Please feel free to tell me if I > > should cancel or delay it longer. > > > > Regards. > > > > diff -Nru foremost-1.5.7/debian/changelog foremost-1.5.7/debian/changelog > > --- foremost-1.5.7/debian/changelog 2019-06-12 12:08:06.0 -0300 > > +++ foremost-1.5.7/debian/changelog 2020-08-19 15:38:47.0 -0300 > > @@ -1,3 +1,11 @@ > > +foremost (1.5.7-9.1) unstable; urgency=medium > > + > > + * Non-maintainer upload. > > + * debian/rules: added DEB_CFLAGS_MAINT_APPEND variable as a workaround > > to fix > > +a FTBFS with GCC-10. (Closes: #957219) > > + > > + -- Joao Eriberto Mota Filho Wed, 19 Aug 2020 > > 15:38:47 -0300 > > + > > foremost (1.5.7-9) unstable; urgency=medium > > > >* Fix extra byte at the tail of recovered zip files if -t all is > > diff -Nru foremost-1.5.7/debian/rules foremost-1.5.7/debian/rules > > --- foremost-1.5.7/debian/rules 2018-06-11 02:27:20.0 -0300 > > +++ foremost-1.5.7/debian/rules 2020-08-19 15:38:47.0 -0300 > > @@ -5,6 +5,9 @@ > > #export DH_VERBOSE=1 > > export DEB_BUILD_MAINT_OPTIONS=hardening=+all > > > > +# Workaround for #957219 > > +export DEB_CFLAGS_MAINT_APPEND = -fcommon > > + > > %: > > dh $@ > >
Bug#845812: libdata-amf-perl: uses deprecated Any::Moose
Hi, I've requested removal: #968722
Bug#968728: RFS: w1retap/1.4.4-4 [RC] -- Data logger for 1-Wire weather sensors
Package: sponsorship-requests Severity: important Dear mentors, As my existing sponsor seems very busy I am looking for a new sponsor for my package "w1retap": * Package name: w1retap Version : 1.4.4-4 Upstream Author : Jonathan Hudson * URL : http://www.zen35309.zen.co.uk/wx/tech.html * License : Expat-Dallas-Semiconductor-Corporation and Expat-University-of-Newcastle-upon-Tyne and GPL-2+, GPL-2+, Expat-Dallas-Semiconductor-Corporation and GPL-2+, Expat * Vcs : https://salsa.debian.org/thomasdstewart-guest/w1retap Section : electronics It builds those binary packages: w1retap-sqlite - Data logger for 1-Wire weather sensors (SQLite plugin) w1retap-pgsql - Data logger for 1-Wire weather sensors (PostgreSQL plugin) w1retap-odbc - Data logger for 1-Wire weather sensors (ODBC plugin) w1retap-mongo - Data logger for 1-Wire weather sensors (MongoDB plugin) w1retap-mysql - Data logger for 1-Wire weather sensors (MySQL plugin) w1retap-doc - Data logger for 1-Wire weather sensors (docs) w1retap - Data logger for 1-Wire weather sensors To access further information about this package, please visit the following URL: https://mentors.debian.net/package/w1retap/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/w/w1retap/w1retap_1.4.4-4.dsc Changes since the last upload: w1retap (1.4.4-4) unstable; urgency=medium . * Refresh dquilt patches * Rename fix-w1pgsql-snprintf-timet.patch to fix-timet.patch * Add timet fixes for w1file, w1pgsql, w1util and w1xml * Update patch descriptions * Fix lintian autotools-pkg-config-macro-not-cross-compilation-safe * Add fix-autotools-libxml2.patch (Closes: #949511) * Fix gcc-10 build errors (Closes: #957921) * Fix owerr spelling * Replace build dependency asciidoc with asciidoc-base * Update standards from 3.9.8 to 4.5.0 * Fix lintian init.d-script-should-always-start-service * Upgrade debhelper compat from 10 to 13 * Add Vcs-Git and Vcs-Browser fields to control file * Fix lintian skip-systemd-native-flag-missing-pre-depends * Add Rules-Requires-Root to control * Added salsa-ci.yml * Fix man page spelling * Add Documentation key to service * Add systemd service hardening-features * Make copyright format URL https * Update lintian-overrides * Add some autopkgtest tests * Remove training whitespace from changelog * Fix lintian debian-rules-uses-as-needed-linker-flag * Fix lintian upstream-metadata-file-is-missing Kind Regards -- Tom
Bug#968727: squid-deb-proxy-client: Should detect being called from a chroot and return no proxy.
Package: squid-deb-proxy-client Version: 0.8.15 Severity: wishlist Hi! Currently if squid-deb-proxy-client is installed in a chroot al successive calls to apt install will try to use it and fail because avahi will not be working. It would be really cool if the script could detect this and simply return no proxy. If this feature seems sensible I might try to create a patch. Of course I'll be happy to consider other alternative solutions. Kind regards, Lisandro. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'buildd-unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64, armhf Kernel: Linux 5.7.0-2-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8), LANGUAGE=es_AR:es Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages squid-deb-proxy-client depends on: ii apt 2.1.10 ii avahi-utils 0.8-3 ii python3 3.8.2-3 squid-deb-proxy-client recommends no packages. squid-deb-proxy-client suggests no packages. -- no debconf information
Bug#968712: sysctl.conf: IPv6 accept_redirect not honored
Package: procps Version: 2:3.3.15-2 Severity: important Tags: ipv6 security Dear maintainers, on a fresh Debian stable (or sid) install, with a PC with one or more (wired) LAN interfaces, I can see following behaviour: a) In /etc/sysctl.conf, set net.ipv6.conf.all.accept_redirects = 0 net.ipv6.conf.default.accept_redirects = 0 b) Reboot c) Check the values in /proc - some interfaces are still 1 (some real interfaces, not just loopback). While nowadays, it's not a "big" security risk for most people, this still is an undesireable security problem, and might hint for a larger problem around sysctl settings in IPv6. For IPv4, everything seems to work fine (except loopback stays 1 there too, but that's expected I think). Thank you -- System Information: Debian Release: 10.5 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-10-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages procps depends on: ii init-system-helpers 1.56+nmu1 ii libc62.28-10 ii libncurses6 6.1+20181013-2+deb10u2 ii libncursesw6 6.1+20181013-2+deb10u2 ii libprocps7 2:3.3.15-2 ii libtinfo66.1+20181013-2+deb10u2 ii lsb-base 10.2019051400 Versions of packages procps recommends: pn psmisc procps suggests no packages. -- no debconf information
Bug#968713: tiger complains about unknown nsfs filesystem
Package: tiger Version: 1:3.2.4~rc1-2 Severity: normal Dear Maintainer, tiger complains about finding an unknown filesystem: --CONFIG-- [con010c] Filesystem 'nsfs' used by 'nsfs' is not recognised as a valid filesystem nsfs is the "Name Space File System" used by the setns() system call. It is used by snap and docker among others. -- System Information: Debian Release: 10.5 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.5.0-0.bpo.2-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr:en_US (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages tiger depends on: ii binutils 2.31.1-16 ii bsdmainutils 11.1.2+b1 ii debconf [debconf-2.0] 1.5.71 ii libc6 2.28-10 ii net-tools 1.60+git20180626.aebd88e-1 ii ucf3.0038+nmu1 Versions of packages tiger recommends: ii chkrootkit 0.52-3+b10 ii exim4-daemon-light [mail-transport-agent] 4.92-8+deb10u4 ii john 1.8.0-2+b1 pn tripwire | aide Versions of packages tiger suggests: ii lsof 4.91+dfsg-1 pn lynis -- debconf information excluded
Bug#968387: apparmor: Broken printing and printer autodiscovery
Package: apparmor Version: 2.13.2-10 Followup-For: Bug #968387 With the printer found and printing not functional: # tail /var/log/cups/error_log E [20/Aug/2020:16:33:13 +0200] Unable to open listen socket for address [v1.::1]:631 - Permission denied. E [20/Aug/2020:16:33:13 +0200] Unable to open listen socket for address 127.0.0.1:631 - Permission denied. E [20/Aug/2020:16:35:26 +0200] [Job 34] Job stopped because the scheduler could not create the side-channel pipes. # journalctl -kaf --no-hostname | grep -w 'apparmor="DENIED"' ago 20 16:35:49 kernel: audit: type=1400 audit(1597934149.904:2054): apparmor="DENIED" operation="create" profile="/usr/sbin/cups-browsed" pid=825 comm="cups-browsed" family="unix" sock_type="stream" protocol=0 requested_mask="create" denied_mask="create" addr=none I cannot recreate the other case where the printer was not found at all. This is not related to lxc (this machine has no containers yet) except that it recommends apparmor.
Bug#960838: get-flash-videos: Abandoned upstream, broken for many use cases ⇒ consider removing
Hi, intrig...@debian.org (2020-05-17): > I propose we remove both packages from the archive. I've requested removal of get-flash-videos: #968720
Bug#968726: RM: libmousex-foreign-perl -- ROM; deprecated Any::Moose, inactive upstream
Package: ftp.debian.org Severity: normal Hi, with my Debian Perl group hat on, I'm trying to decrease the amount of packages that depend on Any::Moose, which is deprecated since 5 years. For more context, see https://bugs.debian.org/960909 The upstream maintainers never commented on the corresponding upstream bug report which was filed 6 years ago. Last upstream release commit was in 2014. This is a leaf package and popcon is tiny. Finally, the Mouse ecosystem is essentially on life-support as the community has been adopting alternate OO frameworks. Thanks!
Bug#968673: libboost-all-dev: Can't use boost 1.71 with C++20 (gcc 10)
În ziua de miercuri, 19 august 2020, la 20:09:43 EEST, Giovanni Mascellani a
scris:
> Hi,
>
> Il 19/08/20 16:41, BogDan Vatra ha scritto:
> > I tried to use boost with C++ 20 (gcc 10), and I got the following errors.
> > I also tried boost 1.73 (from conan.io) and everything compiles.
>
> Thanks for the report. Could you please provide a test program that
> fails compilation and its compilation command line?
>
> Thanks, Giovanni.
Hi,
There you go:
$ cat main.cpp
#include
int main()
{
return 0;
}
$ g++ -std=c++2a main.cpp
Cheers,
BogDan.
Bug#968710: dh_strip: build-ID-based debug symbols have file conflicts for duplicate private shared libraries
Package: debhelper Version: 13.2 Severity: normal File: /usr/bin/dh_strip Since compat level 9, debhelper uses build-ID-based detached debug symbols, which are normally A Good Thing. However, if two packages contain the same private shared library or loadable module, and it's 100% reproducible, it can end up with the same build-ID, causing those packages' detached debug symbols to collide. One place where this legitimately happens is gnome-documents and gnome-books, which both contain a copy of the libgd "copylib" (not to be confused with the libgd2 graphics library, which is unrelated). libgd is not API-stable, so a system-wide shared copy is undesirable (and is not required by Debian Policy §4.13, because it is "explicitly intended to be used in this way"). Normally the copy bundled with a dependent project would be statically linked into the dependent project, but gnome-documents and gnome-books are written in JavaScript and use GObject-Introspection to call into libgd, which means it has to be built as a shared library. Each app installs its copy into a separate private library directory, which works fine. At the moment gnome-documents and gnome-books happen to have identical libgd source code, although this is by no means guaranteed in future releases. They are built into binaries that differ, but the build-ID is identical (presumably the code they contain doesn't differ in any way that matters for debugging), so -documents-dbgsym and -books-dbgsym have an undeclared conflict and cannot be co-installed. For now I'm probably going to work around this by disabling the automatic debug symbols packages. Another place where I've seen this happen is that openarena and openarena-server both ship the "game rules" for OpenArena, qagame*.so, which is a dlopen()'d loadable module. This is duplication, but I don't really want to bloat the Packages file by separating out an openarena-common package to save 800K of installed size, particularly when that's insignificant next to the 400M+ game data. I worked around this by building a separate server-side qagame*.so with a different version number string (0.8.8+dfsg-4/Debian/server vs. 0.8.8+dfsg-4/Debian) and otherwise identical contents. Possible solutions: * perturb the build-ID somehow, similar to my workaround with the (user-facing) version number string in openarena-server; * in dh_strip, make it possible to go back to path-based filenames in /usr/lib/debug; * in dpkg, extend the reference-counting for identical files in Multi-Arch: same packages to cover any identical file; * deploy detached debug symbols in a way that is not dpkg-based Any ideas? Thanks, smcv
Bug#962226: libdr-tarantool-perl build-depends on obsolete package
retitle 962226 RM: libdr-tarantool-perl -- ROM; obsolete reassign 962226 ftp.debian.org severity normal I'd like to request removal of libdr-tarantool-perl. This package was part of tarantool-lts and was uploaded for those who were moving to new tarantool in order for them to be able to use the package with the old one for a few years. It hasn't been being actual for already two or three years. Please delete it. 04.06.2020, 21:45, "peter green" : > Source: libdr-tarantool-perl > Version: 0.45-2 > Severity: serious > Tags: bullseye, sid > > libdr-tarantool-perl build-depends on > > tarantool-lts | tarantool (<< 1.6) > > tarantool-lts has been removed from Debian and tarantool is now at version > 1.9.1.26.g63eb81e3c-1.1
Bug#966302: RFS: dukpy [ITP]
Hi, I'm looking for a sponsor for the package: * dukpy (#966302) The package is on: https://salsa.debian.org/med-team/dukpy The package is the last dependency of benten[1,2]. [1] https://github.com/rabix/benten [2] https://bugs.debian.org/963743 The package has 4 lintian-overrides, which is for ignoring the minified JavaScript source-is-missing.The package does have autopkgtest and passed well. Please consider to review and sponsor this. Any kind of suggestions are appreciated. Thank you! Sincerely, Sao I Kuan saoik...@gmail.com
Bug#907576: . push. dream --A Software Digital Radio Mondiale
Re: GMiller > OK I see here in gittutorial. Is GMIller a good name to push my branch > (instead of master)? Clone the repo to your account on salsa and push it there first. Christoph
Bug#968714: extractpdfmark FTBFS with poppler 0.85
Package: extractpdfmark Version: 1.1.0-1 Severity: serious Tags: patch extractpdfmark FTBFS with poppler 0.85 destname.cc:85:62: error: no matching function for call to ‘PDFDoc::findPage(int&, int&)’ 85 | pagenum = doc->findPage (page_ref.num, page_ref.gen); Doing a bit of poking around in poppler's git repository I deduced that the call should be changed to pagenum = doc->findPage(page_ref); I have whipped up a patch and uploaded it to raspbian, a debdiff should appear soon at https://debdiffs.raspbian.org/main/e/extractpdfmark I may or may not NMU this in Debian later.
Bug#968719: popplerkit.framework FTBFS with poppler 0.85
Package: popplerkit.framework Version: 0.0.20051227svn-8 Severity: serious Tags: bullseye sid patch popplerkit.framework FTBFS with poppler 0.85 because globalParams is now a std::unique_ptr https://github.com/freedesktop/poppler/commit/759d190581f8ff069ecee9155313a8e69a2ca9c6 I have whipped up a patch adjusting popplerkit.framework in the same way the code in poppler itself was adjusted. I have uploaded said patch to raspbian, a debdiff should appear soon at https://debdiffs.raspbian.org/main/p/popplerkit.framework
Bug#968703: python3 and python crashes if a specific .inputrc exists
Package: python3 Version: 3.8.2-3 Severity: important X-Debbugs-Cc: j.arunm...@protonmail.com Dear Maintainer, Content of .inputrc : ``` # Based on Brendan Miller's initial bash .inputrc # INSTALL # to install, rename this file to just ".inputrc" # place this file in your home dir. e.g. ~/.inputrc # restart your terminal. Then, bash's keybinding for editing # should be like ErgoEmacs. # If no key works, try replace all \e to \M-. That's means change Esc to Meta key. set editing-mode emacs "\M-j": backward-char "\M-l": forward-char "\M-u": backward-word "\C-M-b": backward-word "\M-o": forward-word "\C-M-f": forward-word "\M-g": kill-line "\": kill-line "\M-e": backward-kill-word "\M-r": kill-word "\M-f": delete-char "\C-z": undo "\": kill-region "\M-c": copy-region-as-kill "\": yank "\C-v": yank "\C-f": forward-search-history "\M-:": reverse-search-history ``` With .inputrc of above content in HOME, both python and python3 crash by segmentation fault on interactive session. The same happens if any python script takes input from user. This was thought to be an Ergoemacs issue and a bug report was filed in their repository. But the repository maintainers suggested reporting it to readline or / and python package maintainers. Clearing the contents of .inputrc or renaming the file to some trivial name, fixes the issue. Affected usage : 1. Interactive sessions of python and python3 2. Scripts that take input from user. (`python3 myScript.py`) 3. Scripts that process a file and drop to interactive shell. (`python3 -i myScript.py`) Example observation : ``` j_arun_mani@mysys:~$ python3 Python 3.8.5 (default, Aug 2 2020, 15:09:07) [GCC 10.2.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> Segmentation fault ``` Please inform me if any other additional details are required. Thanks ^_^ -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.7.0-2-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3 depends on: ii libpython3-stdlib 3.8.2-3 ii python3-minimal3.8.2-3 ii python3.8 3.8.5-2 python3 recommends no packages. Versions of packages python3 suggests: pn python3-doc pn python3-tk ii python3-venv 3.8.2-3 -- no debconf information
Bug#968706: ITP: ayatana-indicator-sound -- Ayatana Indicator for managing system sound
Package: wnpp Severity: wishlist Owner: Mike Gabriel * Package name: ayatana-indicator-sound Version : 0.8.0 Upstream Author : Mike Gabriel * URL : https://github.com/ArcticaProject/ayatana-indicator-sound * License : GPL-3 Programming Lang: C / C++ / Vala Description : Ayatana Indicator for managing system sound This Ayatana Indicator is designed to be placed on the right side of a panel and give the user easy control over the system's sound settings. . Ayatana Indicator Sound provides easy control of the PulseAudio sound daemon, and integrates well with media players that support the Mpris protocol. . This package will be maintained under the umbrella of the Ayatana Packagers Team.
Bug#968717: debug-me-server: does not email logs
Package: debug-me-server Version: 1.20181208-2 Severity: normal I know there's a newer version, but all my servers run stable. I don't know exactly how sendmail is being invoked, but it is failing Aug 20 11:02:25 fethera debug-me[11600]: sendmail: fatal: open /etc/postfix/main.cf: Permission denied Aug 20 11:02:25 fethera postfix/sendmail[11623]: fatal: open /etc/postfix/main.cf: Permission denied FWIW, I verified that the user _debug-me can read that file. -- System Information: Debian Release: 10.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-9-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages debug-me-server depends on: ii adduser 3.118 ii debug-me1.20181208-2 ii lsb-base10.2019051400 ii postfix [mail-transport-agent] 3.4.10-0+deb10u1 debug-me-server recommends no packages. debug-me-server suggests no packages. -- Configuration Files: /etc/default/debug-me changed: DAEMON_PARAMS="--from-email da...@tethera.net --server /var/log/debug-me/ --delete-old-logs" -- no debconf information
Bug#968365: /usr/bin/freshclam: Ignores DatabaseCustomURL unless --update-db=custom is specified
Hi Sebastian, Sebastian wrote: > It sounds like you want to use PrivateMirror. But then you don't have > same path so it probably won't work. I don't know. > > You have > DatabaseMirror = "update.dfn-cert.de" so I replaced DatabaseMirror by PrivateMirror which results in: ``` -> ^remote_cvdhead: file not found: http://update.dfn-cert.de/daily.cvd ``` When specifiying the update-db parameter the paths specified in DatabaseCustomURL are used. > If you could verify the part with PrivateMirror then I/you could open a > bug with upstream asking what the recommended way is to use a private > mirror with a different hierarchy. In case there is nothing further to add, I would like to file an upstream bug report. I'll document relevant changes here. > This is what you intend to do I guess. Indeed, I would like to place the databases somewhere other than document root. Cheers, Stephan -- Stephan Jänecke (PKI-Team + IT-Services) Mail: jaene...@dfn-cert.dePhone: +49 40 808077-709 DFN-CERT Services GmbH, https://www.dfn-cert.de/, Phone +49 40 808077-555 Sitz / Register: Hamburg, AG Hamburg, HRB 88805, Ust-IdNr.: DE 232129737 Nagelsweg 41, 20097 Hamburg, Germany. CEO: Dr. Klaus-Peter Kossakowski smime.p7s Description: S/MIME cryptographic signature
Bug#968718: ITP: wims-lti -- gateway server that links LMSs to WIMS servers, using LTI
Package: wnpp Severity: wishlist Owner: Georges Khaznadar X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: wims-lti Version : 0.4.3 Upstream Author : Quentin Coumes * URL : https://github.com/PremierLangage/wims-lti * License : GPL-3+ Programming Lang: Python3 Description : gateway server that links LMSs to WIMS servers, using LTI WIMS-LTI is a gateway server that links LMSs to WIMS servers, using LTI. . A single instance of WIMS-LTI can handle a lot of LMS and WIMS servers. . WIMS-LTI allows : . - To create a WIMS class associated to a LMS' course. - To create students corresponding to that course in the WIMS class. - Students to connect to the WIMS server from a LMS. - Teachers to connect to the WIMS class as supervisor or as student from a LMS. - To send the grades of students back to the LMS (automatically and manually). . The documentation is available on readthedocs: https://wims-lti.readthedocs.io/. - This package is interesting for sysadmins which want to deploy easily wims and moodle learning management systems for their schools, and establish useful links between features of both systems. As a member of the association Wimsedu (www.wimsedu.info), I commit myself to maintain this package, as it is also useful for my effort of system administration, in the school where I am employed.
Bug#957219: foremost: diff for NMU version 1.5.7-9.1
Hi Joao, This is perfect. Thanks for taking care of it. On Wed, Aug 19, 2020 at 03:52:30PM -0300, Joao Eriberto Mota Filho wrote: > Control: tags 957219 + patch > Control: tags 957219 + pending > > Dear maintainer, > > I've prepared an NMU for foremost (versioned as 1.5.7-9.1) and > uploaded it to DELAYED/2. Please feel free to tell me if I > should cancel or delay it longer. > > Regards. > > diff -Nru foremost-1.5.7/debian/changelog foremost-1.5.7/debian/changelog > --- foremost-1.5.7/debian/changelog 2019-06-12 12:08:06.0 -0300 > +++ foremost-1.5.7/debian/changelog 2020-08-19 15:38:47.0 -0300 > @@ -1,3 +1,11 @@ > +foremost (1.5.7-9.1) unstable; urgency=medium > + > + * Non-maintainer upload. > + * debian/rules: added DEB_CFLAGS_MAINT_APPEND variable as a workaround to > fix > +a FTBFS with GCC-10. (Closes: #957219) > + > + -- Joao Eriberto Mota Filho Wed, 19 Aug 2020 > 15:38:47 -0300 > + > foremost (1.5.7-9) unstable; urgency=medium > >* Fix extra byte at the tail of recovered zip files if -t all is > diff -Nru foremost-1.5.7/debian/rules foremost-1.5.7/debian/rules > --- foremost-1.5.7/debian/rules 2018-06-11 02:27:20.0 -0300 > +++ foremost-1.5.7/debian/rules 2020-08-19 15:38:47.0 -0300 > @@ -5,6 +5,9 @@ > #export DH_VERBOSE=1 > export DEB_BUILD_MAINT_OPTIONS=hardening=+all > > +# Workaround for #957219 > +export DEB_CFLAGS_MAINT_APPEND = -fcommon > + > %: > dh $@ > signature.asc Description: PGP signature
Bug#968724: ipe-tools FTBFS with poppler 0.85
Package: ipe-tools Severity: serious Version: 1:7.2.7.2-4 Tags: patch ipe-tools fails to build with poppler 0.85, there are multiple issues. I whipped up a patch and uploaded it to raspbian, A debdiff should appear soon at https://debdiffs.raspbian.org/main/i/ipe-tools I notice it looks like at least some of these issues may also have been fixed upstream. Sadly I only noticed this after I prepared my patch.
Bug#968725: RM: libpoe-loop-event-perl -- ROM; RC-buggy, inactive upstream, low popcon
Package: ftp.debian.org Severity: normal Hi, this package causes trouble, due to occasional test failures, on all sorts of automated build/test infrastructures: https://bugs.debian.org/846667 Upstream seems to be inactive for many years, popcon is very low, it's a leaf package, and it seems nobody complained that we did not ship this package in Buster. Thanks in advance!
Bug#966922: libnitrokey: FTBFS: dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols file: see diff output below
Hey Scott, could you update the package? Since this is marked as RC bug, libnitrokey and all depending packages are kicked out of testing. Best, Jan On Mon, 03 Aug 2020 13:54:57 + Scott Kitterman wrote: > This is probably a result of a new GCC version. C++ symbols can be painful > to manage. This will be trivial to update the next time I update the package. > > Scott K > > On August 3, 2020 9:15:16 AM UTC, Szczepan Zalega | Nitrokey > wrote: > >On 8/3/20 10:41 AM, Lucas Nussbaum wrote: > >> (optional=templinst|arch=!amd64 !arm64 !x32) > >> (optional=templinst) > > > >Hi! > > > >As far as I see the problem comes from the listing format difference, > >not the actual symbol change. > > > >E.g.: > >``` > >- (optional=templinst|arch=!amd64 !arm64 > >!x32)_ZN8nitrokey5proto17ResponseDissectorILNS0_9CommandIDE65ERKNS0_14DeviceResponseILS2_65ENS0_12EmptyPayload24status_translate_commandB5cxx11Ei@Base > >3.5 > >+ > >(optional=templinst)_ZN8nitrokey5proto17ResponseDissectorILNS0_9CommandIDE65ERKNS0_14DeviceResponseILS2_65ENS0_12EmptyPayload24status_translate_commandB5cxx11Ei@Base > >3.5 > >``` > > signature.asc Description: OpenPGP digital signature
Bug#968438: Should this really be RC?
severity 968438 normal thanks The problem might also come from previous configuration, both a fellow co maintainer and I tried to create annotations and they worked. Yes, they are now presented as a toolbar, but they are there. And moreover the buttons do what they are intended to do. I would recommend backing up your current okular configuration and removing it, then opening okular again and trying. If that makes a change you might want to consider attaching your configuration to the upstream bug. All in all this is at most a normal bug which might be triggered by previous configs (I'm still speculating), but definitely a normal bug. Drew: please try the above, you might be able to solve the issue for other people too. Thanks!
Bug#968716: ITP: shasta -- nanopore whole genome assembly (binaries and scripts)
Package: wnpp Severity: wishlist Subject: ITP: shasta -- nanopore whole genome assembly (binaries and scripts) Package: wnpp Owner: Shayan Doust Severity: wishlist * Package name: shasta Version : 0.5.1 Upstream Author : Chan Zuckerberg Initiative * URL : https://github.com/chanzuckerberg/shasta * License : Expat Programming Lang: C++ Description : nanopore whole genome assembly (binaries and scripts) De novo assembly from Oxford Nanopore reads. The goal of the Shasta long read assembler is to rapidly produce accurate assembled sequence using as input DNA reads generated by Oxford Nanopore flow cells. . Computational methods used by the Shasta assembler include: . * Using a run-length representation of the read sequence. This makes the assembly process more resilient to errors in homopolymer repeat counts, which are the most common type of errors in Oxford Nanopore reads. . * Using in some phases of the computation a representation of the read sequence based on markers, a fixed subset of short k-mers (k ≈ 10). . Shasta assembly quality is comparable or better than assembly quality achieved by other long read assemblers. . This package contains the executable binaries (tools) and accommodating scripts. Remark: This package is maintained by Debian Med Packaging Team at https://salsa.debian.org/med-team/shasta
Bug#968722: RM: libdata-amf-perl -- ROM; uses deprecated Any::Moose
Package: ftp.debian.org Severity: normal Hi, with my Debian Perl group hat on, I'm trying to decrease the amount of packages that depend on Any::Moose, which is deprecated since 5 years. For more context, see https://bugs.debian.org/960909 The only reverse dependency in the archive is get-flash-videos, for which I've filed a RM bug already (#960838). No upstream release since 10 years and popcon is steadily decreasing. Thanks in advance, cheers!
Bug#845811: libwww-nicovideo-download-perl: uses deprecated Any::Moose
Hi, intrigeri (2020-05-17): > That's still the case. Add to this: no upstream release since 10 > years, very low popcon. > > I propose we remove this package if upstream does not answer within > 3 months. > > also, note that we have nicovideo-dl in the archive: updated last year > upstream, Python 3, 6 times more votes in popcon. > > This increases my confidence that removing > libwww-nicovideo-download-perl is OK. Upstream did not reply so I've requested removal: #968721
Bug#968723: buster-pu: package incron/0.5.12-1+deb10u1
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
Hi,
I'd like to upload incron/0.5.12-1+deb10u1 to buster to fix #930526.
Incron creates a lot zombies processes and make the whole system
unstable.
The fix is pretty trivial (one line) and the patch has been taken from
upstream:
https://github.com/ar-/incron/pull/42/commits/196975d26fd04176a1c877fa3c404efd8103c9c2
Also see https://bugzilla.redhat.com/show_bug.cgi?id=1656939 and
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930526 for further
information.
The debdiff is attached.
Thanks,
diff -Nru incron-0.5.12/debian/changelog incron-0.5.12/debian/changelog
--- incron-0.5.12/debian/changelog 2019-02-19 02:44:46.0 +
+++ incron-0.5.12/debian/changelog 2019-12-02 22:20:07.0 +
@@ -1,3 +1,9 @@
+incron (0.5.12-1+deb10u1) buster; urgency=medium
+
+ * Add a patch to fix cleanup of zombie processes (Closes: #930526)
+
+ -- Emmanuel Bouthenot Mon, 02 Dec 2019 22:20:07 +
+
incron (0.5.12-1) unstable; urgency=medium
* New upstream release (Closes: #860199)
diff -Nru incron-0.5.12/debian/patches/02_prevent_zombies.patch
incron-0.5.12/debian/patches/02_prevent_zombies.patch
--- incron-0.5.12/debian/patches/02_prevent_zombies.patch 1970-01-01
00:00:00.0 +
+++ incron-0.5.12/debian/patches/02_prevent_zombies.patch 2019-11-22
13:48:34.0 +
@@ -0,0 +1,28 @@
+Description: Prevent zombies
+Author: Mikhail Teterin (UnitedMarsupials on
github)
+Forwarded: no
+Last-Update: 2019-11-12
+Origin: https://github.com/ar-/incron/pull/42 ->
https://github.com/ar-/incron/pull/42/commits/196975d26fd04176a1c877fa3c404efd8103c9c2
+Bug-Debian: https://bugs.debian.org/930526
+
+From 196975d26fd04176a1c877fa3c404efd8103c9c2 Mon Sep 17 00:00:00 2001
+From: Mikhail T
+Date: Mon, 30 Oct 2017 14:15:03 -0400
+Subject: [PATCH 2/2] Rework the zombie prevention
+
+---
+ icd-main.cpp | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/icd-main.cpp b/icd-main.cpp
+index aef4d70..1e4d07f 100644
+--- a/icd-main.cpp
b/icd-main.cpp
+@@ -104,6 +104,7 @@ void on_signal(int signo)
+ g_fFinish = true;
+ break;
+ case SIGCHLD:
++ do {} while (waitpid((pid_t)-1, 0, WNOHANG) > 0); /* Prevent zombies */
+ // first empty pipe (to prevent internal buffer overflow)
+ do {} while (read(g_cldPipe[0], g_cldPipeBuf, CHILD_PIPE_BUF_LEN) > 0);
+
diff -Nru incron-0.5.12/debian/patches/series
incron-0.5.12/debian/patches/series
--- incron-0.5.12/debian/patches/series 2019-02-19 02:44:46.0 +
+++ incron-0.5.12/debian/patches/series 2019-11-22 13:48:34.0 +
@@ -1 +1,2 @@
01_manpages_typos
+02_prevent_zombies.patch
Bug#960855: libmousex-foreign-perl: uses deprecated Any::Moose
intrigeri (2020-05-19): > I'll file the RM bug at some point after 2020-07-19, unless > someone objects. Done: #968726
Bug#968711: sysctl.conf: Insufficient/misleading content
Package: procps Version: 2:3.3.15-2 Severity: normal Tags: ipv6 Dear maintainers, please consider changing the following things in the shipped sysctl.conf file. All of these things could easily be done by the user, but many users don't know enough about these things to recognize problems, and new installs should not have useless defaults. a) IPv4+6 accept_redirects Current file content: # Do not accept ICMP redirects (prevent MITM attacks) #net.ipv4.conf.all.accept_redirects = 0 #net.ipv6.conf.all.accept_redirects = 0 According to kernel documentation and source, for normal situations with forwarding=0: The IPv4 setting "all" is separate from the interface settings, and redirects are accepted if at least one of them is 1. (For IPv6, it seems all is ignored and just the interface setting is valid.) Therefore, both cases should not only set "all" (at least if uncommented), but "default" too. b) IPv4 source route Current file content: # Do not accept IP source route packets (we are not a router) #net.ipv4.conf.all.accept_source_route = 0 According to kernel documentation and source: The all-value is already 0 by default (this can be practically seen in a fresh Debian install too) And source routing gets only enabled if "both" the all value and the interface value are 1, so effectively it is disabled everywhere. Therefore, I suggest removing this commented part from sysctl.conf And btw. source routing is not specific to routers. c) IPv6 source route Current file content: #net.ipv6.conf.all.accept_source_route = 0 Again according to the docs etc., this is a very different setting from the IPv4 one. After what happened around the IPv6 "RH0" routing headers (which are not supported at all in Kernel anymore, and that's good), the possible setting values now are >= 0 for enabling something that is not a security problem, and <0 for disabling it completely. Default (for "all" and all interfaces) is 0, meaning securely enabled. Therefore, the sysctl.conf setting (if uncommented) would not unaccept anything like it says, and it can be removed too as it is default. And if not removed, it should set "default" too instead of just "all". Always see https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt etc. Thank you -- System Information: Debian Release: 10.5 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-10-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages procps depends on: ii init-system-helpers 1.56+nmu1 ii libc62.28-10 ii libncurses6 6.1+20181013-2+deb10u2 ii libncursesw6 6.1+20181013-2+deb10u2 ii libprocps7 2:3.3.15-2 ii libtinfo66.1+20181013-2+deb10u2 ii lsb-base 10.2019051400 Versions of packages procps recommends: pn psmisc procps suggests no packages. -- no debconf information
Bug#968721: RM: libwww-nicovideo-download-perl -- ROM; Uses deprecated Any::Moose, inactive upstream, better alternative in Debian
Package: ftp.debian.org Severity: normal Hi, with my Debian Perl group hat on, I'm trying to decrease the amount of packages that depend on Any::Moose, which is deprecated since 5 years. For more context, see https://bugs.debian.org/960909 There's been no upstream release of libwww-nicovideo-download-perl since 10 years. We also have nicovideo-dl in the archive, which seems to provide the same functionality as libwww-nicovideo-download-perl, but was updated upstream last year, is written in Python 3, and has 6 times more votes in popcon.
Bug#846667: Requested removal
Hi, I've requested removal: #968725
Bug#968731: netgen: copyright and licensing issues
Source: netgen Version: 6.2.2006+dfsg-1 Severity: serious Justification: Policy 2.3, 4.5, 12.5 X-Debbugs-CC: ftpmas...@debian.org Hello, During review in NEW I discovered the following problems with this package's copyright file: cmake\cmake_modules\FindMETIS.cmake is BSD licensed. Also the autogen files do not have their licenses given in d/copyright. libsrc/core/concurrentqueue.h has a different license, not in d/copyright. Looks like general/mystring.*pp might have a different copyright holder. libsrc/general/gzstream.* and libsrc/occ have different copyright holders and maybe licenses; situation is unclear. mkinstalldirs missing copyright & license. ng/fonts.hpp -- is this really the source code for the font? ng/ngappinit.cpp says it's a modification from a different package; what is its copyright and license? -- Sean Whitton signature.asc Description: PGP signature
Bug#907576: . push. dream --A Software Digital Radio Mondiale
OK I see here in gittutorial. Is GMIller a good name to push my branch (instead of master)? I'm guessing the other problem is that I don't have the Salsa public key. If correct I will have to get it somehow. garie Sent with [ProtonMail](https://protonmail.com) Secure Email.
Bug#961772: fossil FTCBFS: attempts to run a host tool to check for sqlite3
Oops, just saw this. Thanks for the patch. It's really an upstream issue, so I'm going to forward it there. If they don't want to merge this functionality, I'll maintain it in a Debian patch. Cheers, --Barak.
Bug#968734: chiark-tcl: FTBFS with optimization level -O3 and gcc-10 on s390x
Hi. Thanks for the report.
Gianfranco Costamagna writes ("Bug#968734: chiark-tcl: FTBFS with optimization
level -O3 and gcc-10 on s390x"):
> Hello, In Ubuntu the package FTBFS on s390x, because of -O3, and some non
> initialized variables.
How odd.
> This makes no sense, because the variables are passed by reference
> to the functions, but gcc is probably not smart enough to detect it.
I think it is more likely that it can see into blockcipher_prep, but
not follow the control flow. Perhaps, for example, it doesn't know
that cht_staticerr always returns nonzero, and it thinks that those
error paths in blockcipher_prep might end up using the values in the
caller.
Instead of your suggestion, if you can easily do so, can you try
this ?
Regards,
Ian.
>From 020f536563e566c6a17eeb790d2a5e56141e2b74 Mon Sep 17 00:00:00 2001
From: Ian Jackson
Date: Thu, 20 Aug 2020 19:18:14 +0100
Subject: [PATCH] blockcipher_prep: Initialise out parameters to placate gcc
These are all set on the success exit path but GCC is not clever
enough to see this.
Closes: #968734
Signed-off-by: Ian Jackson
---
crypto/crypto.c | 8
1 file changed, 8 insertions(+)
diff --git a/crypto/crypto.c b/crypto/crypto.c
index aee2556..6efea24 100644
--- a/crypto/crypto.c
+++ b/crypto/crypto.c
@@ -252,6 +252,14 @@ static int blockcipher_prep(Tcl_Interp *ip, Tcl_Obj
*key_obj,
int rc;
CiphKeyValue *key;
+ /* placate gcc, see Debian #968734 */
+ *key_r= 0;
+ *sched_r= 0;
+ *iv_r= 0;
+ *iv_lenbytes_r= 0;
+ *buffers_r= 0;
+ *nblocks_r= 0;
+
if (data_len % alg->blocksize)
return cht_staticerr(ip, "block cipher input not whole number of blocks",
"HBYTES BLOCKCIPHER LENGTH");
--
2.20.1
Bug#968745: prometheus-homeplug-exporter: [INTL:nl] Dutch translation of debconf messages
Package: prometheus-homeplug-exporter Severity: wishlist Tags: l10n patch Dear Maintainer, Please find attached the Dutch translation of prometheus-homeplug- exporter debconf messages. It has been submitted for review to the debian-l10n-dutch mailing list. Please add it to your next package revision. It should be put as debian/po/nl.po in your package build tree. -- Met vriendelijke groet, Frans Spiesschaert nl.po.gz Description: application/gzip
Bug#968744: dpkg: [INTL:nl] Dutch po file for the dpkg package
Package: dpkg Severity: wishlist Tags: l10n patch Dear Maintainer, Please find attached the updated Dutch po file for the dpkg package. It has been submitted for review to the debian-l10n-dutch mailing list. Please add it to your next package revision. It should be put as "po/nl.po" in your package build tree. -- Kind regards, Frans Spiesschaert nl.po.gz Description: application/gzip
Bug#968729: haskell-gi-pango FTBFS parse error on input ‘HarfBuzz.FeatureT.feature_t’
Source: haskell-gi-pango
Version: 1.0.22-1
Severity: serious
Tags: ftbfs
The most recent binnmus of haskell-gi-pango in sid failed with
GI/Pango/Objects/Font.hs:670:9: error:
parse error on input ‘HarfBuzz.FeatureT.feature_t’
|
670 | Ptr HarfBuzz.FeatureT.feature_t -> -- features : TCArray False (-1) 2 (TInterface
(Name {namespace = "HarfBuzz", name = "feature_t"}))
| ^^^
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:147: build-ghc-stamp] Error 1
dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit
status 2
I also saw the same error in raspbian bullseye-staging and on the reproducible
builds tests for bullseye.
Bug#968733: openbsd-inetd: 0.20160825-4
Package: openbsd-inetd Version: 0.20160825-4+b1 Severity: normal User: debian-gl...@lists.debian.org Usertags: rpc-removal Dear maintainer, The glibc SunRPC implementation has been marked obsolete for some time. It will get removed from glibc in version 2.32 that has been released a few weeks ago. The TI RPC implementation should be used instead, which also brings new features (IPv6, Kerberos support, ...). Fortunately it is relatively easy to add support for the TI RPC implementation in openbsd-inetd. Please find a patch below to do that. It can already be applied, even if the glibc SunRPC implementation is still present. Regards, Aurelien --- openbsd-inetd-0.20160825/debian/control +++ openbsd-inetd-0.20160825/debian/control @@ -3,7 +3,7 @@ Priority: optional Maintainer: Marco d'Itri Build-Depends: debhelper-compat (= 12), - pkg-config, libbsd-dev (>= 0.6.0), libwrap0-dev, libevent-dev, libsystemd-dev + pkg-config, libbsd-dev (>= 0.6.0), libwrap0-dev, libevent-dev, libsystemd-dev, libtirpc-dev Standards-Version: 4.3.0.2 Rules-Requires-Root: no Vcs-Git: https://salsa.debian.org/md/openbsd-inetd.git --- openbsd-inetd-0.20160825/debian/patches/series +++ openbsd-inetd-0.20160825/debian/patches/series @@ -15,3 +15,4 @@ monotonic_clock write_pidfile sd_daemon +tirpc --- openbsd-inetd-0.20160825/debian/patches/tirpc +++ openbsd-inetd-0.20160825/debian/patches/tirpc @@ -0,0 +1,15 @@ +Use the TI RPC implementation instead of the glibc SunRPC implementation +that has been removed in glibc version 2.32. + +--- a/Makefile.debian b/Makefile.debian +@@ -4,6 +4,9 @@ CFLAGS ?= -g -O2 + DEFS := -DLIBWRAP + LIBS := -lwrap + ++DEFS += $(shell $(PKG_CONFIG) --cflags libtirpc) ++LIBS += $(shell $(PKG_CONFIG) --libs libtirpc) ++ + DEFS += $(shell $(PKG_CONFIG) --cflags libbsd-overlay) + LIBS += $(shell $(PKG_CONFIG) --libs libbsd-overlay) +
Bug#968735: libdap: Please switch to TI RPC implementation
Source: libdap Version: 3.20.6-3 Severity: wishlist User: debian-gl...@lists.debian.org Usertags: rpc-remova Dear maintainer, The glibc SunRPC implementation has been marked obsolete for some time. It will get removed from glibc in version 2.32 that has been released a few weeks ago. The TI RPC implementation should be used instead, which also brings new features (IPv6, Kerberos support, ...). Fortunately libdap already supports using the TI RPC implementation and will automatically use it if found. Therefore all that you have to do is to add a build-depend on libtirpc-dev. Thanks, Aurelien
Bug#968737: gnudatalanguage: Please switch to TI RPC implementation
Source: gnudatalanguage Version: 0.9.9-12 Severity: wishlist User: debian-gl...@lists.debian.org Usertags: rpc-remova Dear maintainer, The glibc SunRPC implementation has been marked obsolete for some time. It will get removed from glibc in version 2.32 that has been released a few weeks ago. The TI RPC implementation should be used instead, which also brings new features (IPv6, Kerberos support, ...). Fortunately gnudatalanguage already supports using the TI RPC implementation and will automatically use it if found. Therefore all that you have to do is to add a build-depend on libtirpc-dev. Thanks, Aurelien
Bug#968568: ipp-usb: Should depend on avahi-daemon
Control: tags -1 +pending Le lundi, 17 août 2020, 19.47:05 h CEST Brian Potkin a écrit : > An installation of ipp-usb is crippled when the device is not discoverable > on the the loopback interface. avahi-daemon is needed to expose it on any > interface. Oh, clearly this is a bug, as there's a Wants= , the Dependency is a must. > I also wonder whether ipp-usb.service should have > > Wants=avahi-daemon.service > > replaced by > > Requires=avahi-daemon.service That's somewhat of an upstream question. I don't think it really has a concrete difference, or does it? > There is a precedent in #82745. What bug is this ? :-) -- OdyX signature.asc Description: This is a digitally signed message part.
Bug#968741: linux: trace with B550I AORUS PRO AX and AMD Ryzen 5 PRO 4650G
Source: linux Severity: normal X-Debbugs-Cc: florian.laro...@gmail.com Dear Maintainer, compiling the current Debian source with a linux-5.8.2 kernel gives the following trace on a B550I AORUS PRO AX with an AMD Ryzen 5 PRO 4650G: [3.974191] [ cut here ] [3.974265] WARNING: CPU: 9 PID: 175 at drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dcn21/rn_clk_mgr.c:654 rn_clk_mgr_constru ct+0x11e/0x390 [amdgpu] [3.974268] Modules linked in: hid_generic(E) usbhid(E) hid(E) amdgpu(E+) gpu_sched(E) i2c_algo_bit(E) ttm(E) drm_kms_helper(E) ce c(E) ahci(E) libahci(E) nvme(E) xhci_pci(E) nvme_core(E) crc32_pclmul(E) xhci_hcd(E) r8169(E) t10_pi(E) crc32c_intel(E) realtek(E) li bata(E) crc_t10dif(E) drm(E) i2c_piix4(E) crct10dif_generic(E) mfd_core(E) crct10dif_pclmul(E) libphy(E) usbcore(E) crct10dif_common( E) scsi_mod(E) usb_common(E) wmi(E) video(E) gpio_amdpt(E) gpio_generic(E) button(E) [3.974284] CPU: 9 PID: 175 Comm: systemd-udevd Tainted: GE 5.8.0-trunk-amd64 #1 Debian 5.8.2-1 [3.974285] Hardware name: Gigabyte Technology Co., Ltd. B550I AORUS PRO AX/B550I AORUS PRO AX, BIOS F2a 06/16/2020 [3.974348] RIP: 0010:rn_clk_mgr_construct+0x11e/0x390 [amdgpu] [3.974351] Code: 00 00 00 41 8b 8c c4 80 00 00 00 41 89 c1 89 c7 85 c9 74 10 41 8b 94 c4 84 00 00 00 85 d2 0f 85 87 01 00 00 48 8 3 e8 01 73 d9 <0f> 0b 83 7b 20 01 74 0c 81 bd e8 00 00 00 ff 14 37 00 7f 27 48 8b [3.974353] RSP: 0018:a98a8068f850 EFLAGS: 00010297 [3.974355] RAX: RBX: 9a36d7eb2540 RCX: 0640 [3.974356] RDX: RSI: a98a8068f878 RDI: [3.974357] RBP: 9a3625cf9800 R08: R09: [3.974358] R10: 7fc9117f R11: 9a36d7d51000 R12: a98a8068f878 [3.974359] R13: 9a36d7eb2cc0 R14: 9a36bccc R15: 9a36d7eb2540 [3.974361] FS: 7f53ebac18c0() GS:9a371f24() knlGS: [3.974362] CS: 0010 DS: ES: CR0: 80050033 [3.974363] CR2: 7f53ebaaaee0 CR3: 0003d7f38000 CR4: 00340ee0 [3.974365] Call Trace: [3.974427] dc_clk_mgr_create+0x179/0x1a0 [amdgpu] [3.974488] dc_create+0x238/0x700 [amdgpu] [3.974493] ? _cond_resched+0x16/0x40 [3.974554] amdgpu_dm_init.isra.0+0x15b/0x1c0 [amdgpu] [3.974614] dm_hw_init+0xe/0x20 [amdgpu] [3.974676] amdgpu_device_init.cold+0x17a7/0x192b [amdgpu] [3.974722] amdgpu_driver_load_kms+0x5c/0x220 [amdgpu] [3.974766] amdgpu_pci_probe+0x15f/0x1f0 [amdgpu] [3.974770] local_pci_probe+0x42/0x80 [3.974772] ? _cond_resched+0x16/0x40 [3.974773] pci_device_probe+0xfa/0x1b0 [3.974776] really_probe+0x160/0x400 [3.974777] driver_probe_device+0xe1/0x150 [3.974779] device_driver_attach+0xa1/0xb0 [3.974780] __driver_attach+0x8a/0x150 [3.974781] ? device_driver_attach+0xb0/0xb0 [3.974782] ? device_driver_attach+0xb0/0xb0 [3.974784] bus_for_each_dev+0x78/0xc0 [3.974786] bus_add_driver+0x12b/0x1e0 [3.974787] driver_register+0x8b/0xe0 [3.974789] ? 0xc0a6b000 [3.974791] do_one_initcall+0x46/0x200 [3.974792] ? _cond_resched+0x16/0x40 [3.974794] ? kmem_cache_alloc_trace+0x192/0x220 [3.974796] ? do_init_module+0x23/0x250 [3.974798] do_init_module+0x5c/0x250 [3.974799] __do_sys_finit_module+0xac/0x110 [3.974802] do_syscall_64+0x4d/0xc0 [3.974804] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [3.974805] RIP: 0033:0x7f53ebf6ba79 [3.974807] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d e7 53 0c 00 f7 d8 64 89 01 48 [3.974809] RSP: 002b:7ffde26b8228 EFLAGS: 0246 ORIG_RAX: 0139 [3.974811] RAX: ffda RBX: 55c5cb205da0 RCX: 7f53ebf6ba79 [3.974812] RDX: RSI: 7f53ec0f6e4d RDI: 0012 [3.974813] RBP: 0002 R08: R09: 55c5cb205fb8 [3.974814] R10: 0012 R11: 0246 R12: 7f53ec0f6e4d [3.974815] R13: R14: 55c5cb206e20 R15: 55c5cb205da0 [3.974817] ---[ end trace 071eac41bffe7f9b ]--- best regards, Florian La Roche -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.8.0-trunk-amd64 (SMP w/12 CPU threads) Kernel taint flags: TAINT_WARN, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#968736: xinetd: Please switch to TI RPC implementation
Source: xinetd Version: 1:2.3.15.3-1 Severity: wishlist User: debian-gl...@lists.debian.org Usertags: rpc-remova Dear maintainer, The glibc SunRPC implementation has been marked obsolete for some time. It will get removed from glibc in version 2.32 that has been released a few weeks ago. The TI RPC implementation should be used instead, which also brings new features (IPv6, Kerberos support, ...). Fortunately xinetd already supports using the TI RPC implementation and will automatically use it if found. Therefore all that you have to do is to add a build-depend on libtirpc-dev. Thanks, Aurelien
Bug#968441: partman-auto: Default /boot partition size is too small
Control: unarchive 893886 Control: forcemerge 893886 -1 On Sat, 2020-08-15 at 12:56 +0200, Pablo R wrote: > Package: partman-auto > Severity: normal > > Dear Maintainer, > > I recently assisted a friend in her installation of Debian over the > phone. > Going through manual partitionning over the phone would be too > bothersome so I told her to use the automated partitionning option > that uses a whole disk with LVM and encryption. > > Everything went well except that a few weeks later my friend's > computer would not boot: apparently, a kernel update had gone wrong > because the /boot partition was full. > Of course my friend did not see the problem during the update because > she did not know she had to pay attention to that. > > I had the same problem myself a bit more than 10 years ago, and since > then I always do partitioning manually during installs so I did not > know until then that too small /boot partition was still a thing. > > The default should probably be like 1GB or even 2GB to be safe :). [...] This is fixed in the current version of partman-auto, though not (yet) in stable. Ben. -- Ben Hutchings Logic doesn't apply to the real world. - Marvin Minsky signature.asc Description: This is a digitally signed message part
Bug#904013: clamav-freshclam: it breaks also logcheck integration
Package: clamav-freshclam
Version: 0.102.4+dfsg-0+deb10u1
Followup-For: Bug #904013
Dear Maintainer,
logging the timestamp inside the message break also the logcheck rules.
For example the first logcheck (ignore.d.server) rule states:
^\w{3} [ :0-9]{11} [._[:alnum:]-]+ freshclam\[[0-9]+\]: ClamAV update process
started at .*$
But the message written in the logs is:
Aug 20 18:26:53 mail freshclam[15525]: Thu Aug 20 18:26:53 2020 -> ClamAV
update process started at Thu Aug 20 18:26:53 2020
As you can see, the timestamp written after the process id is NOT matched by
the logcheck rule.
You can solve the issue by altering all the rules, inserting a regexp to match
the timestamp as follows:
^\w{3} [ :0-9]{11} [._[:alnum:]-]+ freshclam\[[0-9]+\]: \w{3} \w{3} [ :0-9]{16}
-> ClamAV update process started at .*$
But the best thing, imho is to avoid printing the timestamp inside the message,
since rsyslog already writes the timestamp at the beginning of the log record.
Thanks,
Luca
-- Package-specific info:
--- configuration ---
Checking configuration files in /etc/clamav
Config file: clamd.conf
---
AlertExceedsMax disabled
PreludeEnable disabled
PreludeAnalyzerName = "ClamAV"
LogFile = "/var/log/clamav/clamav.log"
LogFileUnlock disabled
LogFileMaxSize = "4294967295"
LogTime = "yes"
LogClean disabled
LogSyslog disabled
LogFacility = "LOG_LOCAL6"
LogVerbose disabled
LogRotate = "yes"
ExtendedDetectionInfo = "yes"
PidFile disabled
TemporaryDirectory disabled
DatabaseDirectory = "/var/lib/clamav"
OfficialDatabaseOnly disabled
LocalSocket = "/var/run/clamav/clamd.ctl"
LocalSocketGroup = "clamav"
LocalSocketMode = "666"
FixStaleSocket = "yes"
TCPSocket disabled
TCPAddr disabled
MaxConnectionQueueLength = "15"
StreamMaxLength = "26214400"
StreamMinPort = "1024"
StreamMaxPort = "2048"
MaxThreads = "12"
ReadTimeout = "180"
CommandReadTimeout = "5"
SendBufTimeout = "200"
MaxQueue = "100"
IdleTimeout = "30"
ExcludePath disabled
MaxDirectoryRecursion = "15"
FollowDirectorySymlinks disabled
FollowFileSymlinks disabled
CrossFilesystems = "yes"
SelfCheck = "3600"
DisableCache disabled
VirusEvent disabled
ExitOnOOM disabled
AllowAllMatchScan = "yes"
Foreground disabled
Debug disabled
LeaveTemporaryFiles disabled
User = "clamav"
Bytecode = "yes"
BytecodeSecurity = "TrustSigned"
BytecodeTimeout = "6"
BytecodeUnsigned disabled
BytecodeMode = "Auto"
DetectPUA disabled
ExcludePUA disabled
IncludePUA disabled
ScanPE = "yes"
ScanELF = "yes"
ScanMail = "yes"
ScanPartialMessages disabled
PhishingSignatures = "yes"
PhishingScanURLs = "yes"
HeuristicAlerts = "yes"
HeuristicScanPrecedence disabled
StructuredDataDetection disabled
StructuredMinCreditCardCount = "3"
StructuredMinSSNCount = "3"
StructuredSSNFormatNormal = "yes"
StructuredSSNFormatStripped disabled
ScanHTML = "yes"
ScanOLE2 = "yes"
AlertBrokenExecutables disabled
AlertEncrypted disabled
AlertEncryptedArchive disabled
AlertEncryptedDoc disabled
AlertOLE2Macros disabled
AlertPhishingSSLMismatch disabled
AlertPhishingCloak disabled
AlertPartitionIntersection disabled
ScanPDF = "yes"
ScanSWF = "yes"
ScanXMLDOCS = "yes"
ScanHWP3 = "yes"
ScanArchive = "yes"
ForceToDisk disabled
MaxScanTime = "12"
MaxScanSize = "104857600"
MaxFileSize = "26214400"
MaxRecursion = "16"
MaxFiles = "1"
MaxEmbeddedPE = "10485760"
MaxHTMLNormalize = "10485760"
MaxHTMLNoTags = "2097152"
MaxScriptNormalize = "5242880"
MaxZipTypeRcg = "1048576"
MaxPartitions = "50"
MaxIconsPE = "100"
MaxRecHWP3 = "16"
PCREMatchLimit = "1"
PCRERecMatchLimit = "5000"
PCREMaxFileSize = "26214400"
OnAccessMountPath disabled
OnAccessIncludePath disabled
OnAccessExcludePath disabled
OnAccessExcludeRootUID disabled
OnAccessExcludeUID disabled
OnAccessExcludeUname disabled
OnAccessMaxFileSize = "5242880"
OnAccessDisableDDD disabled
OnAccessPrevention disabled
OnAccessExtraScanning disabled
OnAccessCurlTimeout = "5000"
OnAccessMaxThreads = "5"
OnAccessRetryAttempts disabled
OnAccessDenyOnError disabled
DevACOnly disabled
DevACDepth disabled
DevPerformance disabled
DevLiblog disabled
DisableCertCheck disabled
AlgorithmicDetection = "yes"
BlockMax disabled
PhishingAlwaysBlockSSLMismatch disabled
PhishingAlwaysBlockCloak disabled
PartitionIntersection disabled
OLE2BlockMacros disabled
ArchiveBlockEncrypted disabled
Config file: freshclam.conf
---
LogFileMaxSize = "4294967295"
LogTime = "yes"
LogSyslog disabled
LogFacility = "LOG_LOCAL6"
LogVerbose disabled
LogRotate = "yes"
PidFile disabled
DatabaseDirectory = "/var/lib/clamav"
Foreground disabled
Debug disabled
UpdateLogFile = "/var/log/clamav/freshclam.log"
DatabaseOwner = "clamav"
Checks = "24"
DNSDatabaseInfo = "current.cvd.clamav.net"
DatabaseMirror = "db.local.clamav.net", "database.clamav.net"
PrivateMirror disabled
MaxAttempts = "5"
ScriptedUpdates = "yes"
TestDatabases = "yes"
CompressLocalDatabase disabled
ExtraDatabase disabled
ExcludeDatabase disabled
DatabaseCustomURL disabled
HTTPProxyServer disabled
Bug#968740: CVE-2020-15106 CVE-2020-15112 CVE-2020-15113 CVE-2020-15114 CVE-2020-15115
Package: etcd Severity: grave Tags: security X-Debbugs-Cc: Debian Security Team Multiple issues were reported against etcd: CVE-2020-15115: https://github.com/etcd-io/etcd/security/advisories/GHSA-4993-m7g5-r9hh CVE-2020-15114: https://github.com/etcd-io/etcd/security/advisories/GHSA-2xhq-gv6c-p224 CVE-2020-15113: https://github.com/etcd-io/etcd/security/advisories/GHSA-chh6-ppwq-jh92 CVE-2020-15112: https://github.com/etcd-io/etcd/security/advisories/GHSA-m332-53r6-2w93 CVE-2020-15106: https://github.com/etcd-io/etcd/security/advisories/GHSA-p4g4-wgrh-qrg2
Bug#957872: tetrinet: diff for NMU version 0.11+CVS20070911-2.1
Control: tags 957872 + pending
Dear maintainer,
I've prepared an NMU for tetrinet (versioned as 0.11+CVS20070911-2.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should cancel it.
--
Regards
Sudip
diff -Nru tetrinet-0.11+CVS20070911/debian/changelog
tetrinet-0.11+CVS20070911/debian/changelog
--- tetrinet-0.11+CVS20070911/debian/changelog 2016-01-06 22:46:33.0
+
+++ tetrinet-0.11+CVS20070911/debian/changelog 2020-08-20 21:21:38.0
+0100
@@ -1,3 +1,11 @@
+tetrinet (0.11+CVS20070911-2.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix ftbfs with GCC-10. (Closes: #957872)
+- Thanks to Reiner Herrmann.
+
+ -- Sudip Mukherjee Thu, 20 Aug 2020 21:21:38
+0100
+
tetrinet (0.11+CVS20070911-2) unstable; urgency=medium
* Switch to source format 3.0 (quilt).
diff -Nru tetrinet-0.11+CVS20070911/debian/patches/gcc10.patch
tetrinet-0.11+CVS20070911/debian/patches/gcc10.patch
--- tetrinet-0.11+CVS20070911/debian/patches/gcc10.patch1970-01-01
01:00:00.0 +0100
+++ tetrinet-0.11+CVS20070911/debian/patches/gcc10.patch2020-08-20
21:19:08.0 +0100
@@ -0,0 +1,25 @@
+Author: Reiner Herrmann
+Description: Fix FTBFS with GCC 10
+Bug-Debian: https://bugs.debian.org/957872
+
+--- a/tetris.c
b/tetris.c
+@@ -32,6 +32,7 @@
+ signed char specials[MAX_SPECIALS] = {-1}; /* Special block inventory */
+ int next_piece; /* Next piece to fall */
+
++PieceData piecedata[7][4];
+ static struct timeval timeout;/* Time of next action */
+ int current_piece;/* Current piece number */
+ int current_rotation; /* Current rotation value */
+--- a/tetris.h
b/tetris.h
+@@ -50,7 +50,7 @@
+ char shape[4][4]; /* Shape data for the piece */
+ } PieceData;
+
+-PieceData piecedata[7][4];
++extern PieceData piecedata[7][4];
+
+ extern int current_piece, current_rotation;
+
diff -Nru tetrinet-0.11+CVS20070911/debian/patches/series
tetrinet-0.11+CVS20070911/debian/patches/series
--- tetrinet-0.11+CVS20070911/debian/patches/series 1970-01-01
01:00:00.0 +0100
+++ tetrinet-0.11+CVS20070911/debian/patches/series 2020-08-20
21:19:08.0 +0100
@@ -0,0 +1 @@
+gcc10.patch
Bug#966302: RFS: dukpy [ITP]
Hi Sao, thanks a lot for your work on this package. On Thu, Aug 20, 2020 at 11:16:27PM +0900, Sao I Kuan wrote: > I'm looking for a sponsor for the package: > * dukpy (#966302) > > The package is on: > https://salsa.debian.org/med-team/dukpy > > The package is the last dependency of benten[1,2]. > > [1] https://github.com/rabix/benten > [2] https://bugs.debian.org/963743 > > The package has 4 lintian-overrides, which is for ignoring the > minified JavaScript source-is-missing.The package does have > autopkgtest and passed well. > > Please consider to review and sponsor this. Any kind of suggestions > are appreciated. Unfortunately that package is not that simple due to the included JS. For instance dukpy/jsmodules/typescriptServices.js should be removed from package source and rather linked against /usr/share/nodejs/typescript/lib/typescriptServices.js from package node-typescript which should be added to Depends (and may be Build- / Test-Depends). Also there are more copyright notices needed for instance for react.js. If I were you I would check the copyright files of packages like $ apt-file search react.js | grep '/react.js$' node-auto-bind: /usr/share/nodejs/auto-bind/react.js node-babel-types: /usr/share/nodejs/babel-types/lib/react.js node-babel-types: /usr/share/nodejs/babel-types/src/react.js omnidb-common: /usr/lib/python3/dist-packages/OmniDB_app/static/OmniDB_app/js/explain/react.js wordpress: /usr/share/wordpress/wp-includes/js/dist/vendor/react.js I admit I'm a bit scared about all those code copies but well, this might be a second order problem for the moment. Please simply try grep -Ri copyright to find possibly other files in the source tree to find missing source paragraphs. Sorry for the bad news that this package is not that simple. Thanks for your work again anyway Andreas. -- http://fam-tille.de
Bug#968732: nfswatch still partially uses SunRPC implementation
Package: nfswatch Version: 4.99.11-7 Severity: normal Tags: patch User: debian-gl...@lists.debian.org Usertags: rpc-removal Dear maintainer, Thanks for switching nfswatch from the glibc SunRPC implementation to the TI RPC one. It appears however that it doesn't build with the SunRPC headers removed due to a small typo in the debian/rules file. The patch below fixes that. Regards, Aurelien --- nfswatch-4.99.11/debian/rules +++ nfswatch-4.99.11/debian/rules @@ -3,7 +3,7 @@ # Variable name for injection further CFLAGS into build # is not optimally chosen as it relates to rpm builds export RPM_OPT_FLAGS+=$(shell dpkg-buildflags --get CFLAGS) -export RPM_OPT_FLAGS+=$(pkg-config --cflags libtirpc) +export RPM_OPT_FLAGS+=$(shell pkg-config --cflags libtirpc) %: dh $@
Bug#968738: lwjgl: please update to version 3 for libgdx
Source: lwjgl Severity: normal Control: block 968471 -1 libgdx requires v3 which is a major version and complete rewrite https://github.com/LWJGL/lwjgl3 I checked v2 rdepends in buster and it's only recommended by a metapackage. dak rm also shows "No dependency problem found." It seems to have been included as a dependency of jMonkey Engine which itself never made it: https://bugs.debian.org/587947 -- System Information: Debian Release: 10.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-10-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled signature.asc Description: PGP signature
Bug#968739: igv will not run
Package: igv
Version: 2.4.17+dfsg-1
Severity: grave
Justification: renders package unusable
Dear Maintainer,
The IGV package seems not to work. It throws a NoSuchMethodError exception
on startup with the following trace:
$ igv
log4j: reset attribute= "false".
log4j: Threshold ="null".
log4j: Retreiving an instance of org.apache.log4j.Logger.
log4j: Setting [org.broad.igv] additivity to [true].
log4j: Level value for org.broad.igv is [INFO].
log4j: org.broad.igv level set to INFO
log4j: Class name: [org.apache.log4j.ConsoleAppender]
log4j: Parsing layout of class: "org.apache.log4j.PatternLayout"
log4j: Setting property [conversionPattern] to [%d{-MM-dd HH:mm:ss} %-5p
%c{1}:%L - %m%n].
log4j: Adding appender named [console] to category [org.broad.igv].
2020-08-20 13:59:59 INFO DirectoryManager:179 - IGV Directory:
/home/bredelings/igv
2020-08-20 13:59:59 INFO Main:155 - Startup IGV Version user not_set
2020-08-20 13:59:59 INFO Main:156 - Java 11.0.8
2020-08-20 13:59:59 INFO DirectoryManager:84 - Fetching user directory...
2020-08-20 13:59:59 INFO Main:157 - Default User Directory: /home/bredelings
2020-08-20 13:59:59 INFO Main:158 - OS: Linux
2020-08-20 13:59:59 INFO Main:208 - Unknown version: user
2020-08-20 14:00:00 ERROR DefaultExceptionHandler:49 - Unhandled exception
java.lang.NoSuchMethodError: 'void
htsjdk.tribble.util.ParsingUtils.registerHelperClass(java.lang.Class)'
at org.broad.igv.util.HttpUtils.(HttpUtils.java:104)
at org.broad.igv.util.HttpUtils.getInstance(HttpUtils.java:97)
at org.broad.igv.ui.Main.open(Main.java:279)
at org.broad.igv.ui.Main$1.run(Main.java:110)
at
java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:313)
at
java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:770)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:721)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:715)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at
java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85)
at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:740)
at
java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
at
java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
at
java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
at
java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
at
java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
at
java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)
2020-08-20 14:00:01 INFO ShutdownThread:46 - Shutting down
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (2000, 'unstable'), (1999, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.7.0-2-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages igv depends on:
ii default-jre 2:1.11-72
ii junit44.12-8
ii libbatik-java 1.12-1.1
ii libbcprov-java1.65-1
ii libcofoja-java1.3-4
ii libcommons-io-java2.6-2
ii libcommons-logging-java 1.2-2
ii libcommons-math-java 2.2-7
ii libcommons-net-java 3.6-1
ii libgoogle-gson-java 2.8.6-1
ii libguava-java 29.0-5
ii libhtsjdk-java2.22.0+dfsg-1
ii libhttpclient-java4.5.11-1
ii libhttpcore-java 4.4.13-1
ii libjama-java 1.0.3-1
ii libjargs-java 1.0.0-5
ii libjaxb-api-java 2.3.1-1
ii libjaxp1.3-java 1.3.05-5
ii libjcommon-java 1.0.23-1
ii libjfreechart-java1.0.19-2
ii libjgrapht0.8-java0.8.3-5
ii libjhdf5-java 2.11.0+dfsg-4
ii libjide-oss-java 3.7.6+dfsg-1
ii liblog4j1.2-java 1.2.17-9
ii liblog4j2-java2.11.2-1
ii libpicard-java2.22.8+dfsg-1
ii libswing-layout-java 1.0.4-4
ii libxml-commons-external-java 1.4.01-5
Versions of packages igv recommends:
ii libmariadb-java 2.5.3-1
igv suggests no packages.
-- no debconf information
Bug#968742: diffoscope build-depends on package that is not in testing.
Package: diffoscope Version: 156 Severity: serious Diffoscope has been removed from testing and cannot re-enter because it build-depends on gnumeric, which has been kicked out of testing due to a python2 dependency. Since this build-dependency only appears to be used for testing I would suggest dropping it until/unless gnumeric is fixed.
Bug#968192: xkb-data: bepo_afnor missing eszett character
I spotted some more errors for caracter infinity and e as exposant see
patch attached (new patch also include previous patch)
Le 10/08/2020 à 15:08, Jean-Louis Biasini a écrit :
> Package: xkb-data
> Version: 2.29-2
> Severity: normal
> Tags: patch
>
> Dear Maintainer,
>
> the french bepo variant afnor contains an error which prevent the user from
> typing german eszett caracter ß (code ssharp)
>
> The error is easily spotable in /usr/share/X11/xkb/symbols/fr since the
> same
> mapping already exist and is correctly mapped on other variant of the
> bepo (see patch).
>
> thanks for your work,
>
> jean-louis
>
> -- System Information:
> Debian Release: bullseye/sid
> APT prefers stable-updates
> APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable'),
> (90, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 5.7.0-2-amd64 (SMP w/8 CPU threads)
> Kernel taint flags: TAINT_USER
> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE
> not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> -- no debconf information
>
--- /usr/share/X11/xkb/symbols/fr.orig 2020-08-20 18:04:04.463969291 +0300
+++ /usr/share/X11/xkb/symbols/fr.new 2020-08-20 18:04:34.700255994 +0300
@@ -627,7 +627,7 @@
key { type[group1] = "FOUR_LEVEL_SEMIALPHABETIC", [ egrave, Egrave, dead_grave, grave ] }; // è È ` `
key { type[group1] = "FOUR_LEVEL", [ dead_circumflex, exclam, exclamdown, U2620 ] }; // ^ ! ¡ ☠
key { type[group1] = "FOUR_LEVEL_SEMIALPHABETIC", [ v, V, dead_caron, U2622 ] }; // v V ˇ ☢
- key { type[group1] = "FOUR_LEVEL_SEMIALPHABETIC", [ d, D, UFDD7, U2623 ] }; // d D ∞ ☣
+ key { type[group1] = "FOUR_LEVEL_SEMIALPHABETIC", [ d, D, U221E, U2623 ] }; // d D ∞ ☣
key { type[group1] = "FOUR_LEVEL_SEMIALPHABETIC", [ l, L, dead_stroke, sterling ] }; // l L / £
key { type[group1] = "FOUR_LEVEL_SEMIALPHABETIC", [ j, J, U262E, U262F ] }; // j J ☮ ☯
key { type[group1] = "FOUR_LEVEL_SEMIALPHABETIC", [ z, Z, UFDD8, U2619 ] }; // z Z ― ☙
@@ -639,8 +639,8 @@
key { type[group1] = "FOUR_LEVEL_SEMIALPHABETIC", [ e, E, EuroSign, dead_currency ] }; // e E € ¤
key { type[group1] = "FOUR_LEVEL", [ comma, semicolon, apostrophe, dead_belowcomma ] }; // , ; ' ,
key { type[group1] = "FOUR_LEVEL_SEMIALPHABETIC", [ c, C, dead_cedilla, copyright ] }; // c C ¸ ©
- key { type[group1] = "FOUR_LEVEL_SEMIALPHABETIC", [ t, T, UFDD5, trademark ] }; // t T ᵉ ™
- key { type[group1] = "FOUR_LEVEL_SEMIALPHABETIC", [ s, S, UFDD4, U017F ] }; // s S ß ſ
+ key { type[group1] = "FOUR_LEVEL_SEMIALPHABETIC", [ t, T, U1D49, trademark ] }; // t T ᵉ ™
+ key { type[group1] = "FOUR_LEVEL_SEMIALPHABETIC", [ s, S, ssharp, U017F ] }; // s S ß ſ
key { type[group1] = "FOUR_LEVEL_SEMIALPHABETIC", [ r, R, dead_breve, registered ] }; // r R ˘ ®
key { type[group1] = "FOUR_LEVEL_SEMIALPHABETIC", [ n, N, dead_tilde, U2693 ] }; // n N ~ ⚓
key { type[group1] = "FOUR_LEVEL_SEMIALPHABETIC", [ m, M, dead_macron, U26FD ] }; // m M ¯ ⛽
Bug#968748: src:goxel: fails to migrate to testing for too long: FTBFS on several archs
Source: goxel Version: 0.8.1-1 Severity: serious Control: close -1 0.10.6-1 Tags: sid bullseye User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 964403 Dear maintainer(s), As recently announced [1], the Release Team now considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing. Your package src:goxel in its current version in unstable has been trying to migrate for 61 days [2]. Hence, I am filing this bug. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bullseye, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=goxel signature.asc Description: OpenPGP digital signature
Bug#968746: ITP: libgraphics-tiff-perl -- Perl extension for the libtiff library
Package: wnpp Severity: wishlist Owner: Jeffrey Ratcliffe X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: libgraphics-tiff-perl Version : 6 Upstream Author : Jeffrey Ratcliffe * URL : https://metacpan.org/release/Graphics-TIFF * License : Artistic or GPL-1+ Programming Lang: Perl, C Description : Perl extension for the libtiff library The Graphics::TIFF module allows a Perl developer to access TIFF images. Find out more about libtiff at http://www.libtiff.org. . Perl bindings for the libtiff library. This module allows you to access TIFF images in a Perlish and object-oriented way, freeing you from the casting and memory management in C, yet remaining very close in spirit to original API. I will be maintaining this package under the umbrella of the Perl team. It is a dependency of PDF::Builder, which I will also be packaging.
Bug#957764: rmlint: diff for NMU version 2.9.0-2.1
Control: tags 957764 + patch
Control: tags 957764 + pending
Dear maintainer,
I've prepared an NMU for rmlint (versioned as 2.9.0-2.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should cancel it.
--
Regards
Sudip
diff -Nru rmlint-2.9.0/debian/changelog rmlint-2.9.0/debian/changelog
--- rmlint-2.9.0/debian/changelog 2019-12-31 22:27:25.0 +
+++ rmlint-2.9.0/debian/changelog 2020-08-20 20:43:54.0 +0100
@@ -1,3 +1,11 @@
+rmlint (2.9.0-2.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix ftbfs with GCC-10. (Closes: #957764)
+- Use upstream patch, thanks to Reiner Herrmann.
+
+ -- Sudip Mukherjee Thu, 20 Aug 2020 20:43:54
+0100
+
rmlint (2.9.0-2) unstable; urgency=medium
* Replace glib-2_62.patch with upstream implementation, which
diff -Nru
rmlint-2.9.0/debian/patches/0001-fix-link-error-on-compilers-with-fno-common-enabled.patch
rmlint-2.9.0/debian/patches/0001-fix-link-error-on-compilers-with-fno-common-enabled.patch
---
rmlint-2.9.0/debian/patches/0001-fix-link-error-on-compilers-with-fno-common-enabled.patch
1970-01-01 01:00:00.0 +0100
+++
rmlint-2.9.0/debian/patches/0001-fix-link-error-on-compilers-with-fno-common-enabled.patch
2020-08-20 19:57:16.0 +0100
@@ -0,0 +1,96 @@
+From df26dc408e78c27b8119ad06b9998fd07d6c659f Mon Sep 17 00:00:00 2001
+From: Chris Pahl
+Date: Sun, 2 Feb 2020 13:38:53 +0100
+Subject: [PATCH] fix link error on compilers with -fno-common enabled
+
+---
+
+upstream link:
https://github.com/sahib/rmlint/commit/df26dc408e78c27b8119ad06b9998fd07d6c659f
+
+ lib/config.h.in | 62 ++---
+ 1 file changed, 33 insertions(+), 29 deletions(-)
+
+diff --git a/lib/config.h.in b/lib/config.h.in
+index 44d7e5d9..d9fdeabd 100644
+--- a/lib/config.h.in
b/lib/config.h.in
+@@ -121,9 +121,13 @@
+ # define N_(String) gettext_noop (String)
+ #endif
+
+-GMutex RM_LOG_MTX;
++static inline GMutex* rm_log_get_mutex(void) {{
++static GMutex RM_LOG_MTX;
++return _LOG_MTX;
++}}
+
+-#define RM_LOG_INIT g_mutex_init(_LOG_MTX);
++#define RM_LOG_INIT \
++g_mutex_init(rm_log_get_mutex());
+
+ typedef guint64 RmOff;
+
+@@ -150,33 +154,33 @@ typedef guint64 RmOff;
+
+ ///
+
+-#define rm_log_error_line(...) \
+-g_mutex_lock(_LOG_MTX); \
+-rm_log_error_prefix()\
+-rm_log_error(__VA_ARGS__); \
+-rm_log_error("\n"); \
+-g_mutex_unlock(_LOG_MTX); \
+-
+-#define rm_log_warning_line(...) \
+-g_mutex_lock(_LOG_MTX); \
+-rm_log_warning_prefix() \
+-rm_log_warning(__VA_ARGS__); \
+-rm_log_warning("\n");\
+-g_mutex_unlock(_LOG_MTX); \
+-
+-#define rm_log_info_line(...)\
+-g_mutex_lock(_LOG_MTX); \
+-rm_log_info_prefix() \
+-rm_log_warning(__VA_ARGS__); \
+-rm_log_warning("\n");\
+-g_mutex_unlock(_LOG_MTX); \
+-
+-#define rm_log_debug_line(...) \
+-g_mutex_lock(_LOG_MTX); \
+-rm_log_debug_prefix()\
+-rm_log_debug(__VA_ARGS__); \
+-rm_log_debug("\n"); \
+-g_mutex_unlock(_LOG_MTX); \
++#define rm_log_error_line(...) \
++g_mutex_lock(rm_log_get_mutex());\
++rm_log_error_prefix()\
++rm_log_error(__VA_ARGS__); \
++rm_log_error("\n"); \
++g_mutex_unlock(rm_log_get_mutex()); \
++
++#define rm_log_warning_line(...) \
++g_mutex_lock(rm_log_get_mutex());\
++rm_log_warning_prefix() \
++rm_log_warning(__VA_ARGS__); \
++rm_log_warning("\n");\
++g_mutex_unlock(rm_log_get_mutex()); \
++
++#define rm_log_info_line(...)\
++g_mutex_lock(rm_log_get_mutex());\
++rm_log_info_prefix() \
++rm_log_warning(__VA_ARGS__); \
++rm_log_warning("\n");\
++g_mutex_unlock(rm_log_get_mutex()); \
++
++#define rm_log_debug_line(...) \
++g_mutex_lock(rm_log_get_mutex());\
++rm_log_debug_prefix()\
++rm_log_debug(__VA_ARGS__); \
++rm_log_debug("\n"); \
++g_mutex_unlock(rm_log_get_mutex()); \
+
+ /* Domain for reporting errors. Needed by GOptions */
+ #define RM_ERROR_QUARK (g_quark_from_static_string("rmlint"))
+--
+2.20.1
+
diff -Nru rmlint-2.9.0/debian/patches/series rmlint-2.9.0/debian/patches/series
--- rmlint-2.9.0/debian/patches/series 2019-12-31 10:07:39.0 +
+++ rmlint-2.9.0/debian/patches/series 2020-08-20 19:57:16.0 +0100
@@ -6,3 +6,4 @@
xattr-fixes.patch
python3.8.patch
glib-2_62.patch
+0001-fix-link-error-on-compilers-with-fno-common-enabled.patch
Bug#957118: curseofwar: diff for NMU version 1.1.8-3.1
Control: tags 957118 + patch
Control: tags 957118 + pending
Dear maintainer,
I've prepared an NMU for curseofwar (versioned as 1.1.8-3.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should cancel it.
--
Regards
Sudip
diff -Nru curseofwar-1.1.8/debian/changelog curseofwar-1.1.8/debian/changelog
--- curseofwar-1.1.8/debian/changelog 2013-07-28 07:08:52.0 +0100
+++ curseofwar-1.1.8/debian/changelog 2020-08-20 21:07:49.0 +0100
@@ -1,3 +1,11 @@
+curseofwar (1.1.8-3.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix ftbfs with GCC-10. (Closes: #957118)
+- Use upstream patch, thanks to Reiner Herrmann.
+
+ -- Sudip Mukherjee Thu, 20 Aug 2020 21:07:49
+0100
+
curseofwar (1.1.8-3) unstable; urgency=low
* Initial release (Closes: #717348)
diff -Nru
curseofwar-1.1.8/debian/patches/0001-made-dirs-extern-to-compile-as-C-code-with-cmake.patch
curseofwar-1.1.8/debian/patches/0001-made-dirs-extern-to-compile-as-C-code-with-cmake.patch
---
curseofwar-1.1.8/debian/patches/0001-made-dirs-extern-to-compile-as-C-code-with-cmake.patch
1970-01-01 01:00:00.0 +0100
+++
curseofwar-1.1.8/debian/patches/0001-made-dirs-extern-to-compile-as-C-code-with-cmake.patch
2020-08-20 21:04:23.0 +0100
@@ -0,0 +1,28 @@
+From 21d071c221bc0a1a3e67f9e346f1495664d66480 Mon Sep 17 00:00:00 2001
+From: Alexey Nikolaev
+Date: Thu, 1 Aug 2013 17:25:45 -0400
+Subject: [PATCH] made dirs extern to compile as C++ code with cmake
+
+---
+
+upstream link:
https://github.com/a-nikolaev/curseofwar/commit/21d071c221bc0a1a3e67f9e346f1495664d66480
+
+ grid.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/grid.h b/grid.h
+index f3951a5..a63c342 100644
+--- a/grid.h
b/grid.h
+@@ -98,7 +98,7 @@ struct loc {
+ };
+
+ /* There are 6 possible directions to move from a tile. Hexagonal geometry. */
+-const struct loc dirs[DIRECTIONS];
++extern const struct loc dirs[DIRECTIONS];
+
+ /* struct grid
+ *
+--
+2.20.1
+
diff -Nru curseofwar-1.1.8/debian/patches/series
curseofwar-1.1.8/debian/patches/series
--- curseofwar-1.1.8/debian/patches/series 1970-01-01 01:00:00.0
+0100
+++ curseofwar-1.1.8/debian/patches/series 2020-08-20 21:04:02.0
+0100
@@ -0,0 +1 @@
+0001-made-dirs-extern-to-compile-as-C-code-with-cmake.patch
Bug#968751: ITP: firewalk -- active network reconnaissance security tool
Package: wnpp Severity: wishlist Owner: David da Silva Polverari * Package name: firewalk Version : 5.0 Upstream Author : Mike D. Schiffman David E. Goldsmith * URL : http://packetfactory.openwall.net/projects/firewalk/ * License : BSD Programming Lang: C Description : active network reconnaissance security tool Firewalk is an active reconnaissance network security tool that attempts to determine what layer 4 protocols a given IP forwarding device will pass. This package is relevant in network security assessments. It works in a similar way to traceroute, but with extended functionality that helps in assessing the configuration of package filtering devices. I plan to maintain this package inside the Debian Security Tools Packaging Team (pkg-security), and I will need a sponsor for my package.
Bug#966923: meson: diff for NMU version 0.55.0-2.1
Control: tags 966923 + patch
Control: tags 966923 + pending
Control: tags 968704 + pending
Dear maintainer,
I'm sponsoring an NMU for meson (versioned as 0.55.0-2.1) and uploaded
it without delay, after Marco spoke to Martin. Hopefully this doesn't
cause you too much trouble - the skip bug is blocking our work on
updating GNOME to 3.38 so we need this fixed at least in unstable.
Regards,
--
Iain Lane [ i...@orangesquash.org.uk ]
Debian Developer [ la...@debian.org ]
Ubuntu Developer [ la...@ubuntu.com ]
diff -Nru meson-0.55.0/debian/changelog meson-0.55.0/debian/changelog
--- meson-0.55.0/debian/changelog 2020-07-16 17:19:52.0 +0100
+++ meson-0.55.0/debian/changelog 2020-08-20 18:10:34.0 +0100
@@ -1,3 +1,11 @@
+meson (0.55.0-2.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Don't consider skipped tests as failures. Closes: #966923
+ * Fix test with setuptools 49. Closes: #968704
+
+ -- Marco Trevisan (Treviño) Thu, 20 Aug 2020 18:10:34 +0100
+
meson (0.55.0-2) unstable; urgency=medium
* Fix crossbuild test from Gianfranco Costamagna. Closes: #963546
diff -Nru meson-0.55.0/debian/patches/3-mtest_TestResult_SKIP_is_not_a_failure.patch meson-0.55.0/debian/patches/3-mtest_TestResult_SKIP_is_not_a_failure.patch
--- meson-0.55.0/debian/patches/3-mtest_TestResult_SKIP_is_not_a_failure.patch 1970-01-01 01:00:00.0 +0100
+++ meson-0.55.0/debian/patches/3-mtest_TestResult_SKIP_is_not_a_failure.patch 2020-08-20 18:10:31.0 +0100
@@ -0,0 +1,125 @@
+From 998ee63e9596d8b3315ddce3d6f4612fec3588ef Mon Sep 17 00:00:00 2001
+From: Simon McVittie
+Date: Mon, 3 Aug 2020 13:31:42 +0100
+Subject: [PATCH] mtest: TestResult.SKIP is not a failure
+
+If some but not all tests in a run were skipped, then the overall result
+is given by whether there were any failures among the non-skipped tests.
+
+Resolves: https://github.com/mesonbuild/meson/issues/7515
+Signed-off-by: Simon McVittie
+
+Bug-Upstream: https://github.com/mesonbuild/meson/issues/7515
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966923
+Origin: https://github.com/mesonbuild/meson/pull/7525
+Applied-Upstream: 0.56.0
+---
+ mesonbuild/mtest.py | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/mesonbuild/mtest.py b/mesonbuild/mtest.py
+index 0d8169218f..817550e666 100644
+--- a/mesonbuild/mtest.py
b/mesonbuild/mtest.py
+@@ -489,7 +489,7 @@ def make_tap(cls, test: 'TestSerialisation', test_env: T.Dict[str, str],
+ failed = True
+ elif isinstance(i, TAPParser.Test):
+ results.append(i.result)
+-if i.result not in {TestResult.OK, TestResult.EXPECTEDFAIL}:
++if i.result not in {TestResult.OK, TestResult.EXPECTEDFAIL, TestResult.SKIP}:
+ failed = True
+ elif isinstance(i, TAPParser.Error):
+ results.append(TestResult.ERROR)
+
+diff --git a/test cases/common/213 tap tests/cat.c b/test cases/common/213 tap tests/cat.c
+new file mode 100644
+index 00..4b92010ade
+--- /dev/null
b/test cases/common/213 tap tests/cat.c
+@@ -0,0 +1,26 @@
++#include
++#include
++
++int main(int argc, char **argv) {
++char buf[1024];
++size_t len;
++FILE *fh;
++
++if (argc != 2) {
++fprintf(stderr, "Incorrect number of arguments, got %i\n", argc);
++return 1;
++}
++fh = fopen(argv[1], "r");
++if (fh == NULL) {
++fprintf(stderr, "Opening %s: errno=%i\n", argv[1], errno);
++return 1;
++}
++do {
++len = fread(buf, 1, sizeof(buf), fh);
++if (len > 0) {
++fwrite(buf, 1, len, stdout);
++}
++} while (len > 0);
++fclose(fh);
++return 0;
++}
+diff --git a/test cases/common/213 tap tests/issue7515.txt b/test cases/common/213 tap tests/issue7515.txt
+new file mode 100644
+index 00..ca8563778d
+--- /dev/null
b/test cases/common/213 tap tests/issue7515.txt
+@@ -0,0 +1,27 @@
++1..26
++ok 1 Gtk overrides UI template sets up internal and public template children
++ok 2 Gtk overrides UI template sets up public template children with the correct widgets
++ok 3 Gtk overrides UI template sets up internal template children with the correct widgets
++ok 4 Gtk overrides UI template connects template callbacks to the correct handler
++ok 5 Gtk overrides UI template binds template callbacks to the correct object
++ok 6 Gtk overrides UI template from resource sets up internal and public template children
++ok 7 Gtk overrides UI template from resource sets up public template children with the correct widgets
++ok 8 Gtk overrides UI template from resource sets up internal template children with the correct widgets
++ok 9 Gtk overrides UI template from resource connects template callbacks to the correct handler
++ok 10 Gtk overrides UI template from resource
Bug#968365: /usr/bin/freshclam: Ignores DatabaseCustomURL unless --update-db=custom is specified
On 2020-08-20 17:25:01 [+0200], Stephan Jänecke wrote: > Hi Sebastian, Hi Stephan, > In case there is nothing further to add, I would like to file an > upstream bug report. I'll document relevant changes here. Okay. It is https://bugzilla.clamav.net/. Sebastian
Bug#968245: [Pkg-pascal-devel] Bug#968245: Bug#968245: fpc: autopkgtest failure.
On 20/08/2020 06:50, Graham Inggs wrote: For what it's worth, I tried building fpc including your debdiff and running the autopkgtests in an Ubuntu PPA. They passed on amd64, Thanks for confirming (my local setup is far from the same as the test infrastructure) and failed on arm64 [1] and armhf [2]. Not surprising since I had only updated the expected failures for amd64. I'm running tests on i386 now, if they aren't alarmingly bad i'll update the remaining expected failures lists (i386 based on my local tests, arm32* and arm64 based on your results) and upload to Debian. Unfortunately, fpc has not been bootstrapped on ppc64el in Ubuntu yet. We don't currently have a list of expected failures for ppc64el anyway. Once fpc is otherwise in a good state i'll pop a mail to Adam Conrad asking him to bootstrap it for ppc64el Ubuntu. * The expected failure lists seem to be stored by fpc architecture not upstream architecture so afaict armel and armhf would use the same expected failure list. I doubt anyone is actually running the autopkgtest on armel though.
Bug#968715: xfpt: Invalid write in dot_process
Package: xfpt Version: 0.10-1 Severity: normal Dear Maintainer, running xfpt with the attached file leads to an invalid write, causing a segfault. This is the output of Valgrind (valgrind xfpt -o /dev/null ./01_invalid_write): [...] ==82== Invalid write of size 4 ==82==at 0x10BEA4: dot_process (dot.c:890) ==82==by 0x10A4DC: main (xfpt.c:172) ==82== Address 0x112000 is not stack'd, malloc'd or (recently) free'd [...] -- Regards, Luca Borzacchiello -- System Information: Debian Release: 10.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-42-generic (SMP w/12 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages xfpt depends on: ii libc6 2.28-10 xfpt recommends no packages. xfpt suggests no packages. -- no debconf information 01_invalid_write Description: Binary data
Bug#968747: vim-gtk3: vim (when linked to vim-gtk3 or vim-nox) fails to start due to undefined symbol
Package: vim-gtk3 Version: 2:8.2.0716-3 Severity: grave Justification: renders package unusable After dist-upgrading Debian testing to bullseye/sid, vim/ex/gvim/etc. no longer started: vim: symbol lookup error: /usr/lib/x86_64-linux-gnu/libpython3.8.so.1.0: undefined symbol: XML_SetHashSalt A check shows that this only affects vim.gtk3 and vim.nox; vim.basic works fine. -- Package-specific info: --- real paths of main Vim binaries --- /usr/bin/vi is /usr/bin/vim.gtk3 /usr/bin/vim is /usr/bin/vim.gtk3 /usr/bin/gvim is /usr/bin/vim.gtk3 -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.7.0-2-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages vim-gtk3 depends on: ii libacl1 2.2.53-8 ii libc62.31-3 ii libcairo21.16.0-4 ii libcanberra0 0.30-7 ii libgdk-pixbuf2.0-0 2.40.0+dfsg-5 ii libglib2.0-0 2.64.4-1 ii libgpm2 1.20.7-6 ii libgtk-3-0 3.24.22-1 ii libice6 2:1.0.9-2 ii liblua5.2-0 5.2.4-1.1+b3 ii libpango-1.0-0 1.46.0-2 ii libpangocairo-1.0-0 1.46.0-2 ii libperl5.30 5.30.3-4 ii libpython3.8 3.8.5-2 ii libruby2.7 2.7.1-3 ii libselinux1 3.1-2 ii libsm6 2:1.2.3-1 ii libtcl8.68.6.10+dfsg-1 ii libtinfo66.2-1 ii libx11-6 2:1.6.10-3 ii libxt6 1:1.1.5-1+b3 ii vim-common 2:8.2.0716-3 ii vim-gui-common 2:8.2.0716-3 ii vim-runtime 2:8.2.0716-3 vim-gtk3 recommends no packages. Versions of packages vim-gtk3 suggests: ii cscope15.9-1 ii fonts-dejavu 2.37-2 ii gnome-icon-theme 3.12.0-3 ii vim-doc 2:8.2.0716-3 -- no debconf information
Bug#968265: g++: asymptote fails to compile on m68k
Control: tags -1 - fixed-upstream On 8/12/20 8:05 AM, Hilmar Preusse wrote: > Dear Maintainer, > Remove tag. H. -- sigfault #206401 http://counter.li.org signature.asc Description: OpenPGP digital signature
Bug#968734: chiark-tcl: FTBFS with optimization level -O3 and gcc-10 on s390x
Source: chiark-tcl
Version: 1.3.4
tags: patch
Hello, In Ubuntu the package FTBFS on s390x, because of -O3, and some non
initialized variables.
This makes no sense, because the variables are passed by reference to the
functions, but
gcc is probably not smart enough to detect it.
the following patch fixes the issue by initializing the variables.
locutus@Unimatrix05-Bionic:/tmp $ debdiff chiark-tcl_1.3.4.dsc
chiark-tcl_1.3.4ubuntu2.dsc
diff -Nru chiark-tcl-1.3.4/crypto/crypto.c
chiark-tcl-1.3.4ubuntu2/crypto/crypto.c
--- chiark-tcl-1.3.4/crypto/crypto.c2020-08-17 19:09:07.0 +0200
+++ chiark-tcl-1.3.4ubuntu2/crypto/crypto.c 2020-08-20 08:44:23.0
+0200
@@ -316,13 +316,13 @@
HBytes_Value iv, HBytes_Value *result) {
const BlockCipherOp *op= (const void*)cd;
int encrypt= op->encrypt;
- int rc, iv_lenbytes;
- const CiphKeyValue *key;
+ int rc, iv_lenbytes = 0;
+ const CiphKeyValue *key = NULL;
const char *failure;
- const Byte *ivbuf;
- Byte *buffers;
- const void *sched;
- int nblocks;
+ const Byte *ivbuf = 0;
+ Byte *buffers = NULL;
+ const void *sched = NULL;
+ int nblocks = 0;
if (!mode->encrypt)
return cht_staticerr(ip, "mode does not support encrypt/decrypt", 0);
@@ -352,10 +352,10 @@
HBytes_Value iv, HBytes_Value *result) {
const CiphKeyValue *key;
const char *failure;
- const Byte *ivbuf;
- Byte *buffers;
- const void *sched;
- int nblocks, iv_lenbytes;
+ const Byte *ivbuf = 0;
+ Byte *buffers = NULL;
+ const void *sched = NULL;
+ int nblocks = 0, iv_lenbytes = 0;
int rc;
if (!mode->mac)
diff -Nru chiark-tcl-1.3.4/debian/changelog
chiark-tcl-1.3.4ubuntu2/debian/changelog
--- chiark-tcl-1.3.4/debian/changelog 2020-08-17 19:09:07.0 +0200
+++ chiark-tcl-1.3.4ubuntu2/debian/changelog2020-08-20 08:44:23.0
+0200
@@ -1,3 +1,10 @@
+chiark-tcl (1.3.5) unstable; urgency=medium
+
+ * Initialize some variables on crypto.c to make -Werror=maybe-uninitialized
+stop erroring out on s390x with -O3 (Closes: #-1)
+
+ -- Gianfranco Costamagna Thu, 20 Aug 2020
08:44:23 +0200
+
chiark-tcl (1.3.4) unstable; urgency=medium
* debian/tests/control: Update to libnettle8. Fixes DEP-8 failure.
this is an example of failure log:
s390x-linux-gnu-gcc -g -Wall -Wmissing-prototypes -Wstrict-prototypes -Werror
-O2 -Wno-pointer-sign -fno-strict-aliasing -fPIC -I../hbytes/
-I/usr/include/tcl8.6 -I../base -DTCL_MEM_DEBUG -MMD -o algtables.o -c
algtables.c
s390x-linux-gnu-gcc -g -Wall -Wmissing-prototypes -Wstrict-prototypes -Werror
-O2 -Wno-pointer-sign -fno-strict-aliasing -fPIC -I../hbytes/
-I/usr/include/tcl8.6 -I../base -DTCL_MEM_DEBUG -MMD -o bcmode.o -c bcmode.c
s390x-linux-gnu-gcc -g -Wall -Wmissing-prototypes -Wstrict-prototypes -Werror
-O2 -Wno-pointer-sign -fno-strict-aliasing -fPIC -I../hbytes/
-I/usr/include/tcl8.6 -I../base -DTCL_MEM_DEBUG -MMD -o crypto.o -c crypto.c
crypto.c: In function ???cht_do_blockcipherop_e???:
crypto.c:344:3: error: ???iv_lenbytes??? may be used uninitialized in this
function [-Werror=maybe-uninitialized]
344 | cht_hb_array(result, ivbuf, iv_lenbytes);
| ^~~~
crypto.c:338:30: error: ???ivbuf??? may be used uninitialized in this function
[-Werror=maybe-uninitialized]
338 | (encrypt ? mode->encrypt : mode->decrypt)
| ~^~~~
339 | (cht_hb_data(v.hb), nblocks, ivbuf, buffers, alg, encrypt, sched);
| ~
crypto.c:338:30: error: ???buffers??? may be used uninitialized in this
function [-Werror=maybe-uninitialized]
crypto.c:338:30: error: ???sched??? may be used uninitialized in this function
[-Werror=maybe-uninitialized]
crypto.c:338:30: error: ???nblocks??? may be used uninitialized in this
function [-Werror=maybe-uninitialized]
crypto.c: In function ???cht_do_blockcipherop_mac???:
crypto.c:371:12: error: ???nblocks??? may be used uninitialized in this
function [-Werror=maybe-uninitialized]
371 | failure= mode->mac(cht_hb_data(), nblocks, ivbuf, buffers, alg,
sched);
|
^
crypto.c:371:12: error: ???sched??? may be used uninitialized in this function
[-Werror=maybe-uninitialized]
crypto.c:371:12: error: ???buffers??? may be used uninitialized in this
function [-Werror=maybe-uninitialized]
crypto.c:371:12: error: ???ivbuf??? may be used uninitialized in this function
[-Werror=maybe-uninitialized]
cc1: all warnings being treated as errors
make[2]: *** [../base/final.make:23: crypto.o] Error 1
make[2]: Leaving directory '/<>/crypto'
make[1]: *** [Makefile:15: all] Error 2
make[1]: Leaving directory '/<>'
make: *** [debian/rules:50: build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit
status 2
G.
Bug#968682: mkdocs: dh_mkdocs skips jQuery
Hi Christian! On Wed, Aug 19, 2020 at 09:20:57PM +0200, Christian Kastner wrote: > When building src:tpot, I'm getting an embedded-javascript-library > warning for jquery-2.1.1.min.js, copied from mkdocs. > > W: python-tpot-doc: embedded-javascript-library > usr/share/doc/python3-tpot/docs/js/jquery-2.1.1.min.js please use libjs-jquery > > This is odd, because dh_mkdocs seems to process all other libraries > correctly. For example, modernizr-2.8.3.min.js gets turned into a > symlink, and the correct substvar gets added for the libjs-modernizr > dependency. Thanks for the report. Apparently it broke when jquery files were moved from libjs-jquery to node-jquery (see #940975). It is fixed in git now, and will be in the next upload. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#957657: packeth: diff for NMU version 1.6.5-2.1
Control: tags 957657 + patch Control: tags 957657 + pending Dear maintainer, I've prepared an NMU for packeth (versioned as 1.6.5-2.1) and uploaded it to DELAYED/2. Please feel free to tell me if I should cancel or delay it longer. Regards. diff -Nru packeth-1.6.5/debian/changelog packeth-1.6.5/debian/changelog --- packeth-1.6.5/debian/changelog 2011-09-13 10:10:02.0 -0300 +++ packeth-1.6.5/debian/changelog 2020-08-20 15:05:18.0 -0300 @@ -1,3 +1,11 @@ +packeth (1.6.5-2.1) unstable; urgency=medium + + * Non-maintainer upload. + * debian/rules: added -fcommon to CFLAGS as a workaround +to fix a FTBFS with GCC-10. (Closes: #957657) + + -- Joao Eriberto Mota Filho Thu, 20 Aug 2020 15:05:18 -0300 + packeth (1.6.5-2) unstable; urgency=low * Fix FTBFS because of wrong link order, thanks to Colin Watson diff -Nru packeth-1.6.5/debian/rules packeth-1.6.5/debian/rules --- packeth-1.6.5/debian/rules 2011-09-13 10:10:02.0 -0300 +++ packeth-1.6.5/debian/rules 2020-08-20 15:05:18.0 -0300 @@ -4,7 +4,7 @@ # Uncomment this to turn on verbose mode. #export DH_VERBOSE=1 -export CFLAGS = -Wall -g -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations +export CFLAGS = -Wall -g -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -fcommon export LDFLAGS = -Wl,-z,defs -Wl,--as-needed override_dh_auto_install:
Bug#968749: src:cfengine3: fails to migrate to testing for too long: unresolved RC bug
Source: cfengine3 Version: 3.12.1-2 Severity: serious Control: close -1 3.15.2-2 Tags: sid bullseye User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 963341 Dear maintainer(s), As recently announced [1], the Release Team now considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing. Your package src:cfengine3 in its current version in unstable has been trying to migrate for 61 days [2]. Hence, I am filing this bug. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bullseye, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=cfengine3 signature.asc Description: OpenPGP digital signature
Bug#968750: src:dulwich: fails to migrate to testing for too long: FTBFS
Source: dulwich Version: 0.20.2-1 Severity: serious Control: close -1 0.20.5-1 Tags: sid bullseye User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 956876 Dear maintainer(s), As recently announced [1], the Release Team now considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing. Your package src:dulwich in its current version in unstable has been trying to migrate for 60 days [2]. Hence, I am filing this bug. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bullseye, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=dulwich signature.asc Description: OpenPGP digital signature
Bug#968696: konsole: editing profile settings creates new profiles
Package: konsole Version: 4:18.04.0-1 Severity: normal Dear Maintainer, On a fresh install of Debian Buster, when settings for the current profile are edited, konsole creates new profiles. To reproduce: launch konsole go to profile settings change options such as terminal size, font, font size, scrollback lines, cursor shape What happens: for each setting changed, konsole creates a brand new profile. after changing multiple settings konsole had created 9 new profiles. What should happen: konsole should only change the settings for the profile chosen, not create new profiles -- System Information: Debian Release: 10.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-10-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages konsole depends on: ii kio 5.54.1-1 ii konsole-kpart 4:18.04.0-1 ii libc6 2.28-10 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 libkf5globalaccel55.54.0-1 ii libkf5i18n5 5.54.0-1 ii libkf5iconthemes5 5.54.0-1 ii libkf5kiowidgets5 5.54.1-1 ii libkf5notifyconfig5 5.54.0-1 ii libkf5widgetsaddons5 5.54.0-1 ii libkf5windowsystem5 5.54.0-1 ii libkf5xmlgui5 5.54.0-1 ii libqt5core5a 5.11.3+dfsg1-1+deb10u3 ii libqt5gui55.11.3+dfsg1-1+deb10u3 ii libqt5widgets55.11.3+dfsg1-1+deb10u3 ii libstdc++68.3.0-6 konsole recommends no packages. konsole suggests no packages. -- no debconf information
Bug#968697: systemsettings: Advanced Power Management -> Pause media players when suspending setting is ignored
Package: systemsettings Version: 4:5.14.5-1.1 Severity: normal Dear Maintainer, In Advanced Power Management Settings -> Advanced Settings the option "Pause media players when suspending" is ignored. Pause media players option is enabled by default. When it is disabled and the screen switches off according to the energy saving setting, media player still pauses. What should happen: when "Pause media players" option is unselected and the screen switches off media players should not be paused. -- System Information: Debian Release: 10.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-10-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages systemsettings depends on: ii kio 5.54.1-1 ii kpackagetool5 5.54.0-1 ii libc6 2.28-10 ii libkf5activities5 5.54.0-1 ii libkf5activitiesstats15.54.0-1 ii libkf5auth5 5.54.0-2 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 libkf5declarative55.54.0-1 ii libkf5i18n5 5.54.0-1 ii libkf5iconthemes5 5.54.0-1 ii libkf5itemviews5 5.54.0-1 ii libkf5kcmutils5 5.54.0-1 ii libkf5khtml5 5.54.0-1 ii libkf5kiowidgets5 5.54.1-1 ii libkf5package55.54.0-1 ii libkf5quickaddons55.54.0-1 ii libkf5service-bin 5.54.0-1 ii libkf5service55.54.0-1 ii libkf5widgetsaddons5 5.54.0-1 ii libkf5windowsystem5 5.54.0-1 ii libkf5xmlgui5 5.54.0-1 ii libkworkspace5-5 4:5.14.5.1-1 ii libqt5core5a 5.11.3+dfsg1-1+deb10u3 ii libqt5dbus5 5.11.3+dfsg1-1+deb10u3 ii libqt5gui55.11.3+dfsg1-1+deb10u3 ii libqt5qml55.11.3-4 ii libqt5quick5 5.11.3-4 ii libqt5quickwidgets5 5.11.3-4 ii libqt5widgets55.11.3+dfsg1-1+deb10u3 ii libstdc++68.3.0-6 ii qml-module-org-kde-kcm5.54.0-1 ii qml-module-org-kde-kirigami2 5.54.0-1 ii qml-module-qtquick-controls 5.11.3-2 ii qml-module-qtquick-layouts5.11.3-4 ii qml-module-qtquick2 5.11.3-4 systemsettings recommends no packages. systemsettings suggests no packages. -- no debconf information
Bug#968649: closed by Sebastian Ramacher (Bug#968649: fixed in breathe 4.20.0-1)
On 2020-08-20 15:51, Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report which was filed against the src:breathe package: #968649: breathe 4.19 incompatible with sphinx 3.2.1 It has been closed by Debian FTP Masters (reply to Sebastian Ramacher ). Thanks Sebastian! Drew
Bug#763171: Can we please close this one?
It affects Iceweasel 31, was fixed in Iceweasel 32 and asks for a backport from that version. It would be great to close it, as it shows up on all firefox-esr bug listings. Thanks :-) Sebastian
Bug#968698: libreoffice-calc: Scrolling a spreadsheet leaves a trail of "Row ..." tooltips
Package: libreoffice-calc Version: 1:7.0.1~rc1-1+b1 Severity: minor Dear Maintainer, I'm not sure exactly when this started happening, but at some point leading up to version 7 of LibreOffice, I started noticing that scrolling a spreadsheet document (even an empty one, and regardless of whether I use the scroll wheel or the scrollbar) it leaves a trail of "Row ..." tooltips along the right side of the window. (See attached image.) I have not noticed this in earlier versions (though I rarely use spreadsheets so who knows?), and I'm not aware of making any changes to the default settings. Checking/unchecking the "Use hardware acceleration" checkbox doesn't seem to make any differences. I also tried renaming my ~/.config/libreoffice/4/user folder, which I assume should reset any settings I might have made, but that didn't make any difference either. I gave the official upstreams LibreOffice packages a quick try, and I didn't see the problem there. I'm using Xfce as my desktop. I did notice that the problem seems to go away if I enable display compositing, so maybe that's a clue? But I don't know which other program I could try to see if it is a recurring bug with Xfce. Torbjörn Andersson -- Package-specific info: -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.7.0-2-amd64 (SMP w/4 CPU threads) Locale: LANG=en_DK.utf8, LC_CTYPE=en_DK.utf8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libreoffice-calc depends on: ii coinor-libcoinmp1v5 1.8.3-3 ii libc62.31-3 ii libetonyek-0.1-1 0.1.9-3 ii libgcc-s110.2.0-5 ii libicu67 67.1-4 ii libmwaw-0.3-30.3.16-1 ii libodfgen-0.1-1 0.1.7-1 ii liborcus-0.15-0 0.15.4-3 ii liborcus-parser-0.15-0 0.15.4-3 ii libreoffice-base-core1:7.0.1~rc1-1+b1 ii libreoffice-common 1:7.0.1~rc1-1 ii libreoffice-core 1:7.0.1~rc1-1+b1 ii librevenge-0.0-0 0.0.4-6+b1 ii libstaroffice-0.0-0 0.0.7-1 ii libstdc++6 10.2.0-5 ii libuno-cppu3 1:7.0.1~rc1-1+b1 ii libuno-cppuhelpergcc3-3 1:7.0.1~rc1-1+b1 ii libuno-sal3 1:7.0.1~rc1-1+b1 ii libuno-salhelpergcc3-3 1:7.0.1~rc1-1+b1 ii libwps-0.4-4 0.4.11-1 ii libxml2 2.9.10+dfsg-5+b1 ii lp-solve 5.5.2.5-2 ii ucf 3.0043 ii uno-libs-private 1:7.0.1~rc1-1+b1 libreoffice-calc recommends no packages. Versions of packages libreoffice-calc suggests: ii mesa-opencl-icd 20.1.5-1 ii ocl-icd-libopencl1 2.2.12-4 Versions of packages libreoffice-core depends on: ii fontconfig 2.13.1-4.2 ii fonts-opensymbol2:102.11+LibO7.0.1~rc1-1 ii libboost-locale1.71.0 1.71.0-6+b2 ii libc6 2.31-3 ii libcairo2 1.16.0-4 ii libclucene-contribs1v5 2.3.3.4+dfsg-1+b1 ii libclucene-core1v5 2.3.3.4+dfsg-1+b1 ii libcmis-0.5-5v5 0.5.2-2+b1 ii libcups22.3.3-2 ii libcurl3-gnutls 7.68.0-1+b1 ii libdbus-1-3 1.12.20-1 ii libdconf1 0.36.0-1 ii libeot0 0.01-5+b1 ii libepoxy0 1.5.4-1 ii libexpat1 2.2.9-1 ii libexttextcat-2.0-0 3.4.5-1 ii libfontconfig1 2.13.1-4.2 ii libfreetype62.10.2+dfsg-3 ii libgcc-s1 10.2.0-5 ii libglib2.0-02.64.4-1 ii libgpgmepp6 1.14.0-1 ii libgraphite2-3 1.3.14-1 ii libgstreamer-plugins-base1.0-0 1.16.2-4 ii libgstreamer1.0-0 1.16.2-2 ii libharfbuzz-icu02.6.7-1 ii libharfbuzz0b 2.6.7-1 ii libhunspell-1.7-0 1.7.0-3 ii libhyphen0 2.8.8-7 ii libice6 2:1.0.9-2 ii libicu6767.1-4 ii libjpeg62-turbo 1:2.0.5-1.1 ii liblcms2-2 2.9-4+b1 ii libldap-2.4-2 2.4.50+dfsg-1+b1 ii libmythes-1.2-0 2:1.2.4-3+b1 ii libneon27-gnutls0.31.2-1 ii libnspr42:4.27-1 ii libnss3 2:3.55-1 ii libnumbertext-1.0-0 1.0.6-1 ii liborcus-0.15-0 0.15.4-3 ii liborcus-parser-0.15-0 0.15.4-3 ii libpng16-16 1.6.37-2 ii libpoppler950.85.0-2 ii libqrcodegencpp11.5.0-2 ii libraptor2-02.0.14-1+b1 ii librdf0 1.0.17-1.1+b1 ii libreoffice-common
Bug#968695: plasma-workspace: krunner does not honor search settings until after relogin
Package: plasma-workspace Version: 4:5.14.5.1-1 Severity: normal Dear Maintainer, On a fresh install of Debian Buster, when krunner search settings are changed, krunner does not honor the settings until after logging out and logging back in. To reproduce: open krunner via Alt-Space change search options (by default all options are selected, my choice was to unselect all except 'Applications' and 'Power' use krunner to try to start an app krunner will show results from search types that have been unselected -- System Information: Debian Release: 10.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-10-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages plasma-workspace depends on: ii dbus-user-session [default-dbus-session-bus] 1.12.20-0+deb10u1 ii dbus-x11 [dbus-session-bus] 1.12.20-0+deb10u1 ii drkonqi 5.14.5-1 ii frameworkintegration 5.54.0-1 ii gdb-minimal [gdb] 8.2.1-2+b3 ii iso-codes 4.2-1 ii kactivitymanagerd 5.14.5-1 ii kded5 5.54.0-1 ii kinit 5.54.0-1 ii kio 5.54.1-1 ii kpackagetool5 5.54.0-1 ii kwin-common 4:5.14.5-1 ii libappstreamqt2 0.12.5-1 ii libc6 2.28-10 ii libcolorcorrect5 4:5.14.5.1-1 ii libgcc1 1:8.3.0-6 ii libgps23 3.17-7 ii libice6 2:1.0.9-2 ii libkf5activities5 5.54.0-1 ii libkf5auth5 5.54.0-2 ii libkf5baloo5 5.54.0-1 ii libkf5bookmarks5 5.54.0-1 ii libkf5calendarevents5 5.54.0-1 ii libkf5completion5 5.54.0-1 ii libkf5config-bin 5.54.0-1+deb10u1 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 libkf5declarative55.54.0-1 ii libkf5globalaccel-bin 5.54.0-1 ii libkf5globalaccel55.54.0-1 ii libkf5guiaddons5 5.54.0-1 ii libkf5holidays5 1:5.54.0-1 ii libkf5i18n5 5.54.0-1 ii libkf5iconthemes5 5.54.0-1 ii libkf5idletime5 5.54.0-1 ii libkf5itemviews5 5.54.0-1 ii libkf5jobwidgets5 5.54.0-1 ii libkf5js5 5.54.0-1 ii libkf5jsembed55.54.0-1 ii libkf5kdelibs4support55.54.0-1 ii libkf5kiocore55.54.1-1 ii libkf5kiofilewidgets5 5.54.1-1 ii libkf5kiogui5 5.54.1-1 ii libkf5kiowidgets5 5.54.1-1 ii libkf5networkmanagerqt6 5.54.0-1 ii libkf5newstuff5 5.54.0-2 ii libkf5notifications5 5.54.0-1 ii libkf5notifyconfig5 5.54.0-1 ii libkf5package55.54.0-1 ii libkf5plasma5 5.54.0-1 ii libkf5plasmaquick55.54.0-1 ii libkf5prison5 5.54.0-1+b2 ii libkf5quickaddons55.54.0-1 ii libkf5runner5 5.54.0-1 ii libkf5service-bin 5.54.0-1 ii libkf5service55.54.0-1 ii libkf5solid5 5.54.0-1 ii libkf5texteditor5 5.54.0-1 ii libkf5textwidgets55.54.0-1 ii libkf5wallet-bin 5.54.0-1 ii libkf5wallet5 5.54.0-1 ii libkf5waylandclient5
Bug#967487: libubootenv: Cannot build libubootenv with dpkg-buildpackage
Hi,
Hi,
2020年8月17日(月) 17:15 Gylstorff Quirin :
On 8/12/20 4:29 AM, Nobuhiro Iwamatsu wrote:
Hi,
Thanks for your report.
2020年8月4日(火) 19:50 Gylstorff Quirin :
Package: libubootenv-tool
Version: 0.2-1
Severity: serious
Tags: patch ftbfs
Justification: fails to build from source
Dear Maintainer,
I tried to build libubootenv-tool with dpkg-buildpackage and the following
error
did occur:
```
-- Detecting C compile features - done
CMake Error at src/CMakeLists.txt:29 (install):
install TARGETS given no RUNTIME DESTINATION for executable target
"fw_printenv".
CMake Error at src/CMakeLists.txt:30 (install):
install TARGETS given no RUNTIME DESTINATION for executable target
"fw_setenv".
```
Hmm, I checked this on unstable but didn't reproduce it.
I attached a build log.
Could you tell me the environment you have confirmed?
Sure, I tried to build it on stable(Debian 10.5) with cmake version 3.13.4.
Attached is the complete log.
This package is not provided in stable, so the bug severity will not
be set in serious. I change to important.
Could you check this patch in unstable environment as well?
If everything is okay, I will apply.
I tested it with pbuilder on sid an it builds for me. Attached is the log.
Kind regards
Quirin
Kind regards
Quirin
Best regards,
Nobuhiro
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
dh clean
dh_clean
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building libubootenv using existing ./libubootenv_0.2.orig.tar.gz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: building libubootenv in libubootenv_0.2-1.debian.tar.xz
dpkg-source: info: building libubootenv in libubootenv_0.2-1.dsc
[0mI: Generating source changes file for original dsc[0m
dpkg-genchanges: info: including full source code in upload
dpkg-source: info: unapplying 0004-Add-the-static-library-for-installation.patch
dpkg-source: info: unapplying 0003-Change-name-of-the-output-static-library-to-libuboot.patch
dpkg-source: info: unapplying 0002-Add-support-GNUInstallDirs.patch
dpkg-source: info: unapplying 0001-Unifies-the-functionality-provided-by-CMake-to-lower.patch
[0;34mD: cmdline: build --buildresult /var/cache/pbuilder/debian-sid-amd64/result/ --debbuildopts --debbuildopts ../libubootenv_0.2-1.dsc[0m
[1;33mW: cgroups are not available on the host, not using them.[0m
[0mI: pbuilder: network access will be disabled during build[0m
[0mI: Current time: Wed Aug 19 16:23:55 CEST 2020[0m
[0mI: pbuilder-time-stamp: 1597847035[0m
[0mI: Building the build Environment[0m
[0mI: extracting base tarball [/var/cache/pbuilder/debian-sid-amd64-base.tgz][0m
[0mI: copying local configuration[0m
[1;33mW: hookdir /var/cache/pbuilder/hook.d/ does not exist, skipping[0m
[0mI: mounting /proc filesystem[0m
[0mI: mounting /sys filesystem[0m
[0mI: creating /{dev,run}/shm[0m
[0mI: mounting /dev/pts filesystem[0m
[0mI: redirecting /dev/ptmx to /dev/pts/ptmx[0m
[0mI: policy-rc.d already exists[0m
[0;34mD: no hooks of type H found -- ignoring[0m
[0mI: Obtaining the cached apt archive contents[0m
[0mI: Copying source file[0m
[0mI: copying [../libubootenv_0.2-1.dsc][0m
[0mI: copying [../libubootenv_0.2.orig.tar.gz][0m
[0mI: copying [../libubootenv_0.2-1.debian.tar.xz][0m
[0mI: Extracting source[0m
dpkg-source: warning: extracting unsigned source package (libubootenv_0.2-1.dsc)
dpkg-source: info: extracting libubootenv in libubootenv-0.2
dpkg-source: info: unpacking libubootenv_0.2.orig.tar.gz
dpkg-source: info: unpacking libubootenv_0.2-1.debian.tar.xz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: applying 0001-Unifies-the-functionality-provided-by-CMake-to-lower.patch
dpkg-source: info: applying 0002-Add-support-GNUInstallDirs.patch
dpkg-source: info: applying 0003-Change-name-of-the-output-static-library-to-libuboot.patch
dpkg-source: info: applying 0004-Add-the-static-library-for-installation.patch
[0mI: using fakeroot in build.[0m
[0mI: Installing the build-deps[0m
[0;34mD: no hooks of type D found -- ignoring[0m
-> Attempting to satisfy build-dependencies
-> Creating pbuilder-satisfydepends-dummy package
Package: pbuilder-satisfydepends-dummy
Version: 0.invalid.0
Architecture: amd64
Maintainer: Debian Pbuilder Team
Description: Dummy package to satisfy dependencies with aptitude - created by pbuilder
This package was created automatically by pbuilder to satisfy the
build-dependencies of the package being currently built.
Depends: debhelper (>= 11), cmake, zlib1g-dev, graphviz, doxygen
dpkg-deb: building package 'pbuilder-satisfydepends-dummy' in '/tmp/satisfydepends-aptitude/pbuilder-satisfydepends-dummy.deb'.
Selecting previously unselected package pbuilder-satisfydepends-dummy.
(Reading database ... 12389 files and directories currently installed.)
Preparing to unpack
Bug#967487: libubootenv: Cannot build libubootenv with dpkg-buildpackage
Hi,
...
This package is not provided in stable, so the bug severity will not
be set in serious. I change to important.
Could you check this patch in unstable environment as well?
If everything is okay, I will apply.
I tested it with pbuilder on sid an it builds for me. Attached is the log.
Kind regards
Quirin
Kind regards
Quirin
Best regards,
Nobuhiro
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
dh clean
dh_clean
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building libubootenv using existing ./libubootenv_0.2.orig.tar.gz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: building libubootenv in libubootenv_0.2-1.debian.tar.xz
dpkg-source: info: building libubootenv in libubootenv_0.2-1.dsc
[0mI: Generating source changes file for original dsc[0m
dpkg-genchanges: info: including full source code in upload
dpkg-source: info: unapplying 0004-Add-the-static-library-for-installation.patch
dpkg-source: info: unapplying 0003-Change-name-of-the-output-static-library-to-libuboot.patch
dpkg-source: info: unapplying 0002-Add-support-GNUInstallDirs.patch
dpkg-source: info: unapplying 0001-Unifies-the-functionality-provided-by-CMake-to-lower.patch
[0;34mD: cmdline: build --buildresult /var/cache/pbuilder/debian-sid-amd64/result/ --debbuildopts --debbuildopts ../libubootenv_0.2-1.dsc[0m
[1;33mW: cgroups are not available on the host, not using them.[0m
[0mI: pbuilder: network access will be disabled during build[0m
[0mI: Current time: Wed Aug 19 16:23:55 CEST 2020[0m
[0mI: pbuilder-time-stamp: 1597847035[0m
[0mI: Building the build Environment[0m
[0mI: extracting base tarball [/var/cache/pbuilder/debian-sid-amd64-base.tgz][0m
[0mI: copying local configuration[0m
[1;33mW: hookdir /var/cache/pbuilder/hook.d/ does not exist, skipping[0m
[0mI: mounting /proc filesystem[0m
[0mI: mounting /sys filesystem[0m
[0mI: creating /{dev,run}/shm[0m
[0mI: mounting /dev/pts filesystem[0m
[0mI: redirecting /dev/ptmx to /dev/pts/ptmx[0m
[0mI: policy-rc.d already exists[0m
[0;34mD: no hooks of type H found -- ignoring[0m
[0mI: Obtaining the cached apt archive contents[0m
[0mI: Copying source file[0m
[0mI: copying [../libubootenv_0.2-1.dsc][0m
[0mI: copying [../libubootenv_0.2.orig.tar.gz][0m
[0mI: copying [../libubootenv_0.2-1.debian.tar.xz][0m
[0mI: Extracting source[0m
dpkg-source: warning: extracting unsigned source package (libubootenv_0.2-1.dsc)
dpkg-source: info: extracting libubootenv in libubootenv-0.2
dpkg-source: info: unpacking libubootenv_0.2.orig.tar.gz
dpkg-source: info: unpacking libubootenv_0.2-1.debian.tar.xz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: applying 0001-Unifies-the-functionality-provided-by-CMake-to-lower.patch
dpkg-source: info: applying 0002-Add-support-GNUInstallDirs.patch
dpkg-source: info: applying 0003-Change-name-of-the-output-static-library-to-libuboot.patch
dpkg-source: info: applying 0004-Add-the-static-library-for-installation.patch
[0mI: using fakeroot in build.[0m
[0mI: Installing the build-deps[0m
[0;34mD: no hooks of type D found -- ignoring[0m
-> Attempting to satisfy build-dependencies
-> Creating pbuilder-satisfydepends-dummy package
Package: pbuilder-satisfydepends-dummy
Version: 0.invalid.0
Architecture: amd64
Maintainer: Debian Pbuilder Team
Description: Dummy package to satisfy dependencies with aptitude - created by pbuilder
This package was created automatically by pbuilder to satisfy the
build-dependencies of the package being currently built.
Depends: debhelper (>= 11), cmake, zlib1g-dev, graphviz, doxygen
dpkg-deb: building package 'pbuilder-satisfydepends-dummy' in '/tmp/satisfydepends-aptitude/pbuilder-satisfydepends-dummy.deb'.
Selecting previously unselected package pbuilder-satisfydepends-dummy.
(Reading database ... 12389 files and directories currently installed.)
Preparing to unpack .../pbuilder-satisfydepends-dummy.deb ...
Unpacking pbuilder-satisfydepends-dummy (0.invalid.0) ...
dpkg: pbuilder-satisfydepends-dummy: dependency problems, but configuring anyway as you requested:
pbuilder-satisfydepends-dummy depends on debhelper (>= 11); however:
Package debhelper is not installed.
pbuilder-satisfydepends-dummy depends on cmake; however:
Package cmake is not installed.
pbuilder-satisfydepends-dummy depends on zlib1g-dev; however:
Package zlib1g-dev is not installed.
pbuilder-satisfydepends-dummy depends on graphviz; however:
Package graphviz is not installed.
pbuilder-satisfydepends-dummy depends on doxygen; however:
Package doxygen is not installed.
Setting up pbuilder-satisfydepends-dummy (0.invalid.0) ...
Reading package lists...
Building dependency tree...
Reading state information...
Initializing package states...
Writing extended state information...
Building tag database...
pbuilder-satisfydepends-dummy is already installed at the
Bug#966649: Request for feedback on upload_history re-implementation
Hi Asheesh, I'm currently testing your code from the git repository. Interestingly it also respects future ;-) : ... Computed upload history for 2020-05 Computed upload history for 2020-06 Computed upload history for 2020-07 Computed upload history for 2020-08 Computed upload history for 2020-09 Computed upload history for 2020-10 Computed upload history for 2020-11 Computed upload history for 2020-12 Computed upload history for 2021-01 Computed upload history for 2021-02 Computed upload history for 2021-03 Computed upload history for 2021-04 Computed upload history for 2021-05 Computed upload history for 2021-06 Computed upload history for 2021-07 Computed upload history for 2021-08 Computed upload history for 2021-09 Computed upload history for 2021-10 Computed upload history for 2021-11 Computed upload history for 2021-12 >From the first look the result looks sensible: sqlite> select * from upload_history where maintainer like '%debian-med-packaging%' limit 2 ; e1jawxz-000605...@ries.debian.org|1199391582|gnumed-client|0.2.8.1-1|Andreas Tille |Andreas Tille|ti...@debian.org|Debian-Med Packaging Team |Debian-Med Packaging Team|debian-med-packag...@lists.alioth.debian.org|0| gnumed-client (0.2.8.1-1) unstable; urgency=low . * New upstream version e1japsm-0006xr...@ries.debian.org|1199462003|probcons|1.12-4|Charles Plessy |Charles Plessy|charles-debian-nos...@plessy.org|Debian-Med Packaging Team |Debian-Med Packaging Team|debian-med-packag...@lists.alioth.debian.org|0| probcons (1.12-4) unstable; urgency=low . - Allowed upload by Debian Maintainers. - Checked the compliance with Policy 3.7.3 * debian/patches: - swiched to quilt - added a fix to build with GCC 4.3 (Closes: #455625) * debian/rules: - modify Main-RNA.cc so that it uses Defaults-RNA.h (Closes: #458926) * debian/copyright: - converted to machine-readable format. . [ David Paleino ] * debian/probcons.1, debian/probcons-RNA.1, debian/pc-compare.1, debian/pc-makegnuplot.1, debian/pc-project.1 added - these have been statically built. * debian/control: - B-D updated - added myself to Uploaders * debian/rules: - manpages statically built - minor changes But I guess you consider this table partly a debugging state. I do not see a good reason to store the full changelog paragraph otherwise. You also are storing message_id. That's OK from a data consumption point of view but I do not see any real usage for this field at the moment. I would love to see the same table structure as in UDD: source | version | date | changed_by | changed_by_name | changed_by_email | maintainer | maintainer_name | maintainer_email | nmu | signed_by | signed_by_name | signed_by_email | key_id | distribution | file | fingerprint What I'm missing is signed_by* . No idea what key_id means - never used this. Distribution might be good to have as well, no idea what file might have contained. Fingerprint seems also sensible since it could be a link to the carnivore table. Regarding the decision to parse the web archives rather than mboxes: I don't know what is better. I agree that accessing public data is an advantage but if it is at the expense of more complex code I would rather stick to the mbox parsing. BTW, formerly the data went at least back to 2000. Here is the graph for pkg-perl: http://blends.debian.net/liststats/uploaders_pkg-perl.png Currently you encode date as integer in sqlite so I need to think about how to translate this. For my target query I want to do for my talk it would be comfortable to have date or datetime values. So far for my review. Thanks a lot for your work on this. Its really appreciated! Kind regards Andreas. On Wed, Aug 19, 2020 at 11:03:40PM -0700, Asheesh Laroia wrote: > Hi Andreas & Lucas & all, > > Lucas -- I'm making progress on re-implementing this. I'd love your input > by email or IRC about my approach, but if you're busy, feel free to ignore > this and I'll mention you again when I submit a patch. > > Andreas -- The codebase at > https://github.com/paulproteus/debian-devel-changes-history-extractor can > be run on your system and generate a "upload_history" table. Would you be > willing to try it out and let me know if it meets your needs? > > The README at the URL above has some information about how to use it. > > https://drive.google.com/drive/folders/1hF_zuc_03m3a_VwOO5hpjp5vETNjVxMx?usp=sharing > is a Google Drive folder (owned by me) which contains an > upload_history.sqlite file you can use. This would allow you to query the > current database without using the code to create it. (Feel free to also > use the code to create your own DB.) > > I'm happy to discuss by IRC or private email or BTS email what you would > need next. I do hope to resolve the issues listed in the bug tracker on > GitHub, but I haven't yet, and feedback will help me prioritize. > > Per the info in the README, I'd
Bug#933110: pkg-components: No upstream maintainer ⇒ unsuitable for Bullseye
On Fri, 26 Jul 2019 at 16:29:23 -0300, intrig...@debian.org wrote: > The Debian Perl group has, somewhat unwillingly, inherited the role of > upstream maintainer for this native package, when its original author > stopped taking care of it. We don't feel we're in a good position to > wear this hat and would rather not to. > > Therefore, we decided at the pkg-perl BoF today at DebConf that we > don't want this package to be included in Bullseye, unless someone > else steps up and becomes its upstream maintainer. It's been over a year and this doesn't seem to have happened. > I'll file bugs against all reverse-dependencies to alert their > maintainer about this situation. Should the bugs against rdeps be escalated to serious at this point, potentially triggering autoremovals? smcv
Bug#968699: /usr/bin/mutool: Remove short syntax from man page, this has never been implemented
Package: mupdf-tools
Version: 1.14.0+ds1-4
Severity: normal
File: /usr/bin/mutool
See patch. Thanks
-- System Information:
Debian Release: 10.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500,
'proposed-updates-debug'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.6.0-0.bpo.2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages mupdf-tools depends on:
ii libc62.28-10
ii libfreetype6 2.9.1-3+deb10u1
ii libharfbuzz0b2.3.1-1
ii libjbig2dec0 0.16-1
ii libjpeg62-turbo 1:1.5.2-2+b1
ii libopenjp2-7 2.3.0-2+deb10u1
ii libssl1.11.1.1d-0+deb10u3
ii zlib1g 1:1.2.11.dfsg-1
mupdf-tools recommends no packages.
mupdf-tools suggests no packages.
-- no debconf information
>From e4b3d41e1bfbf45d70fffdfe47372e7a559c9397 Mon Sep 17 00:00:00 2001
From: Mathieu Malaterre
Date: Thu, 20 Aug 2020 10:33:26 +0200
Subject: [PATCH] Remove short syntax from man page, this has never been
implemented.
Code is simply:
static void show(char *sel)
{
if (!strcmp(sel, "trailer"))
showtrailer();
else if (!strcmp(sel, "xref"))
showxref();
else if (!strcmp(sel, "pages"))
showpages();
else if (!strcmp(sel, "grep"))
showgrep();
else if (!strcmp(sel, "outline"))
showoutline();
else if (!strcmp(sel, "js"))
showjs();
else if (!strcmp(sel, "form"))
showform();
else
showpathroot(sel);
}
Signed-off-by: Mathieu Malaterre
---
docs/man/mutool.1 | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/docs/man/mutool.1 b/docs/man/mutool.1
index 2d9c01724..bbb44a574 100644
--- a/docs/man/mutool.1
+++ b/docs/man/mutool.1
@@ -337,22 +337,22 @@ Print streams in their original encoded (or compressed)
form.
.PP
Specify objects by number, or use one of the following special names:
.TP
-.B 'xref' or 'x'
+.B 'xref'
Print the cross reference table.
.TP
-.B 'trailer' or 't'
+.B 'trailer'
Print the trailer dictionary.
.TP
-.B 'encrypt' or 'e'
+.B 'encrypt'
Print the encryption dictionary.
.TP
-.B 'pagetree' or 'p'
+.B 'pagetree'
List the object numbers for every page.
.TP
-.B 'grep' or 'g'
+.B 'grep'
Print all the objects in the file in a compact one-line format suitable for
piping to grep.
.TP
-.B 'outline' or 'o'
+.B 'outline'
Print the outline (table of contents).
.SH RUN
--
2.20.1
Bug#968606: vte: Racy NULL-ptr segfault in vte::terminal::update_repeat_timeout()
On Tue, Aug 18, 2020 at 08:42:23PM +0100, Simon McVittie wrote: > > 1) Can the Debian CNA assign a CVE number to this issue? It is technically a > > vulnerability, and a CVE might convince the upstream developer towards more > > collaborative attitude. > > CVE IDs are a mechanism for tracking known security vulnerabilities > so that sysadmins and users can know which packages need updating or > avoiding. They are not a weapon to beat maintainers with; please don't > treat them as that. Exactly. > (Procedurally, I don't think the Debian CNA is allowed to assign CVE > numbers to vulnerabilities that are already known outside Debian.) Indeed. (Plus the use of the Debian CNA has also shifted to only apply to Debian-specific tooling (like dpkg/apt) or Debian-specific security issues) Cheers, Moritz
Bug#968718: ITP: wims-lti -- gateway server that links LMSs to WIMS servers, using LTI
On 2020-08-20 17:22 +0200, Georges Khaznadar wrote: > * Package name: wims-lti > Description : gateway server that links LMSs to WIMS servers, using LTI > > WIMS-LTI is a gateway server that links LMSs to WIMS servers, using LTI. > . > A single instance of WIMS-LTI can handle a lot of LMS and WIMS servers. > . > WIMS-LTI allows : > . > - To create a WIMS class associated to a LMS' course. > - To create students corresponding to that course in the WIMS class. > - Students to connect to the WIMS server from a LMS. > - Teachers to connect to the WIMS class as supervisor or as student > from a LMS. > - To send the grades of students back to the LMS (automatically and > manually). This description needs to say what WIMS, LMS and LTI stand for. Despite using the terms repeatedly, at no point are they expanded. A package description must be understandable by someone who has never heard of LMS and WIMS (whatever they are). Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#963659: pybind11: FTBFS with Sphinx 3.1: File "/usr/lib/python3/dist-packages/sphinx/domains/c.py", line 3093, in object_type / raise NotImplementedError())
Still failing with breathe 4.20.0-1 (and sphinx 3.2.1-1, pybind11 2.5.0-4).
Bug#870331: marked as done (installation-reports: Fails to install grub in the MBR of second device via menu item)
Aim stop On 21.08.20 05:04, Debian Bug Tracking System wrote: Your message dated Fri, 21 Aug 2020 04:58:02 +0200 with message-id <20200821045802.07acb7c9ded347064600d...@mailbox.org> and subject line Re: Mass-closing old installation-report bugs --- round 5 has caused the Debian Bug report #870331, regarding installation-reports: Fails to install grub in the MBR of second device via menu item to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.)
Bug#968761: mailutils: not binnmu safe.
Package: mailutils
Version: 1:3.9-3.2
Tags: patch
I run a derivative called raspbian and I noticed that mailutils was getting
repeatedly
binnmu'd by our autobinnmuer because the binary packages were not installable.
I don't know what exactly triggered the first binnmu (our autobinnmuer does
suffer from
some false-positives) but the repeated binnmus were being caused by the package
not
being binnmu safe, so after the first binnmu libmailutils6 was not installable.
Specifically the dependencies on libmu-dbm6 (= ${source:Version}) should
instead be
dependencies on libmu-dbm6 (= ${binary:Version}). Please consider changing them
in
your next upload.
Bug#924179: Info received (Bug#924179: marked as done (Package: installation-reports))
But not over 300 emails in 10 minutes, that's too much, sorry, that doesn't work. Then I say stop have been tracking it for a long time but haven't followed 300 emails in such a short time Thanks On 21.08.20 05:33, Debian Bug Tracking System wrote: Thank you for the additional information you have supplied regarding this Bug report. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has been sent to the package maintainer(s): Debian Install Team If you wish to submit further information on this problem, please send it to 924...@bugs.debian.org. Please do not send mail to ow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system.
Bug#966649: Request for feedback on upload_history re-implementation
On Thu, Aug 20, 2020, 05:45 Lucas Nussbaum wrote: > Hi Asheesh, > Hi! :) > > I think that the changes compared to the current table structure should > be minimized, to avoid rewrite all tools that use this data. > Improvements are welcomed of course, but please don't make changes if > there's no good reason for them. > Good call. I'll prioritize that. > Did you confirm with DSA that parsing the online list archives is the > preferred way to go? I fear that we will hit some HTTP rate limiting at > some point and will have to reconsider the implementation. > I haven't yet! I can do so. I will try to optimize the current approach first since I'm enthusiastic about it, but good call on checking with DSA. > How optimized is your code for running every few minutes? Ideally we > would like near-real-time updates of this data, we will require polling > the list archives (previously, email was received directly on > ullmann.debian.org via a special email address) > It's a good question. Let me update you about that once I've optimized further. I think I can get down to one HTTP call at start when nothing changes (mailing list index page) and down to 2 (index page plus message page) if there is a change. Running every 2 min (say) would mean 24*30 = 720 requests per day, which seems well below any rate limit I can think of, but obviously 0 unnecessary requests is nicer. It's a good topic to discuss with DSA, and I can do that. Even if the inbound email is used for fresh data, historic data needs to come from somewhere. I think the email archives on the web are a good place to import those, based on my preference to develop in a context that doesn't require any special setup. Hope you're doing well! Asheesh. >
Bug#924179: marked as done (Package: installation-reports)
Am 21.08.2020 05:06, schrieb Debian Bug Tracking System: Your message dated Fri, 21 Aug 2020 04:58:02 +0200 with message-id <20200821045802.07acb7c9ded347064600d...@mailbox.org> and subject line Re: Mass-closing old installation-report bugs --- round 5 has caused the Debian Bug report #924179, regarding Package: installation-reports to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) Pleas stopp aim not mor 5 Minuts are 100 Emails aim not good stop
