Bug#589430: mutt uses ncurses even in non-interactive mode
Control: tag -1 +moreinfo On Sat, Jul 17, 2010 at 08:04:54PM +0200, Piotr Lewandowski wrote: > Package: mutt > Version: 1.5.20-9 > Severity: normal > > Hello, > > mutt uses ncurses even if there is no such need, i.e.: > > - with '-p' option, > - with '-Z' option if there is no new mail, > - in compose mode when editor is started right away. > > After mutt exits user is left with cleaned screen and default color > palette on some terminals[1], which is pretty annoying. > > [1] http://bugs.debian.org/589429 Hi Piotr, this used to be an issue in the past, where mutt did not handle terminals correctly (and I also had issues as well), and reset their colors due to the way ncurses was called. Personally I haven't seen this issue in a long time, are you still seeing it? Thanks!
Bug#698267: mutt: [PATCH] To/CC/Bc fields are stripped during editing (RFC 2822)
Control: tag -1 +pending This is in git now, it will come with 1.14.4-4.
Bug#633993: Makes new connection to the SMTP server for every mail, even when sending several in one action
Control: severity -1 wishlist On Fri, Jul 15, 2011 at 11:40:34AM -0700, Josh Triplett wrote: > Package: mutt > Version: 1.5.21-5 > Severity: normal > > I selected an entire thread, and used ;b to bounce it to someone. mutt > made a new connection to the SMTP server for each mail it bounced, > incurring the full latency of a connection to my SMTP server each time. > mutt should have made a single connection to the SMTP server to send all > the mails. > Setting it to wishlist rather than bug (it seems to be the existing behavior for a long time). I will look into it anyway, it just makes it easier for me to classify it.
Bug#618607: mutt: loses IMAP message flags when the server terminates idle connection
Control: tag -1 +moreinfo Many things in the imap source code in mutt where changed in the meantime, can you check if it is still reproducible and provide us with a muttdebug log if possible (please remove your password in that case). Thanks!
Bug#954249: Resolved
Control: severity -1 important Control: retitle -1 command-not-found: crashes without `apt update`: local variable 'cnf' referenced before assignment Control: forcemerge 954249 962154 On Wed, 3 Jun 2020 15:51:43 -0600 Allan Herrera wrote: > sudo apt-get update& apt-get upgrade -yqq > sudo update-command-not-found > > *Problem Solved, I expect this will be useful* Since this issue is only due to a missing `apt update`, it isn't a grave issue but only an important usability issue. BTW, you have reported a duplicate bug. When reporting bugs, please check the existing bug reports before reporting a new bug: https://bugs.debian.org/954249 https://bugs.debian.org/962154 -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#962640: RFS: zmat/0.9.8 [RFS] -- a portable C-library and Octave toolbox for data compression
On 6/21/20 12:16 AM, Boyuan Yang wrote:
After all the previous reviews and changes and base on the current
version you provide at https://mentors.debian.net/package/zmat, I think
there are several minor issues plus one last major issue. I opted to
make fixes on minor issues and list the diff here. Please consider
applying the diff.
hi Boyuan
thank you so much for the detailed feedback - should have updated you in
this thread -
Rafael Laboissière (CCed) from the Debian octave group has been helping
me finalizing the package (among a few others), and it is now updated at
https://salsa.debian.org/pkg-octave-team/zmat
the discussion thread can be found at
https://lists.debian.org/debian-octave/2020/06/threads.html#0
your feedback #1/2 have been fixed by Rafael, and I will fix #3 below.
also thanks for the log - Rafael also told me the building had failed,
but it worked ok on my machine (my debhelper-compat is 12, he was using
13), see my log
https://lists.debian.org/debian-octave/2020/06/msg00020.html
your attached log is very helpful, it appears that the "*b**uild-arch*"
target was not executed (which calls *build-static* to create libzmat.a
and *build-mex* to create zipmat.mex), see
https://salsa.debian.org/pkg-octave-team/zmat/-/blob/master/debian/rules#L9
are you aware any support change w.r.t. *build-arch *in compat level 13?
or if you see any issue with my rules? (still pretty new to the rules file).
much appreciated
Qianqian
Key points:
1. The suite name in debian/changelog file will need to be set from
UNRELEASED to unstable when it's ready for upload.
2. There is no need to explicitly list out Depends: debhelper when
Depends: debhelper-compat exists since debhelper will provide package
"debhelper-compat".
3. There is no need to explicitly list out library dependency for your
libraries. Explicitly listing them out is tedious and error-prone.
Those library names will be automatically derived and generated by
dh_shlibdeps(1) during the build process and emerge from the
${shlibs:Depends} substitution marker.
diff --git a/debian/changelog b/debian/changelog
index 4beb2b1..6cd6b7c 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,4 +1,4 @@
-zmat (0.9.8-1) UNRELEASED; urgency=medium
+zmat (0.9.8-1) unstable; urgency=medium
* Initial release. (Closes: #962603)
diff --git a/debian/control b/debian/control
index 8004473..754dcca 100644
--- a/debian/control
+++ b/debian/control
@@ -3,13 +3,13 @@ Maintainer: Qianqian Fang
Section: libs
Priority: optional
Standards-Version: 4.5.0
-Build-Depends: debhelper (>= 8.1.3~), debhelper-compat (= 12), liblz4-
dev, zlib1g-dev, dh-octave
+Build-Depends: debhelper-compat (= 12), liblz4-dev, zlib1g-dev, dh-
octave
Homepage: https://github.com/fangq/zmat
Package: libzmat1
Architecture: any
Multi-Arch: same
-Depends: zlib1g, liblz4-1, ${shlibs:Depends}, ${misc:Depends}
+Depends: ${shlibs:Depends}, ${misc:Depends}
Provides: libzmat1
Description: compression library - runtime
ZMat is a portable C library to enable easy-to-use data compression
@@ -35,7 +35,7 @@ Package: octave-zmat
Section: science
Architecture: any
Multi-Arch: same
-Depends: zlib1g, liblz4-1, ${shlibs:Depends}, ${octave:Depends},
${misc:Depends}
+Depends: ${shlibs:Depends}, ${octave:Depends}, ${misc:Depends}
Description: in-memory data compression for Octave
ZMat is a portable mex function to enable
zlib/gzip/lzma/lzip/lz4/lz4hc
based data compression/decompression and base64 encoding/decoding
support
However, that is not enough: the major issue is that your package
current fails to build from source within a clean chroot environment. I
have attached the full buildlog in the attachment. It seems that the
error comes from the missing lib/libzmat.a library. I'm curious about
how you planned to generate the static library. It seems that the
Makefile does not contain related instructions. There are several
STATIC keywords in CMakeLists.txt but you did not list cmake in the
build-dependency (so cmake won't be available during building) and did
not invoke cmake anywhere in debian/rules as well. Please consider
fixing this issue.
Bug#963233: ITP: golang-github-dgryski-go-metro -- Go translation of MetroHash
Package: wnpp Severity: wishlist Owner: Guobang Bi * Package name: golang-github-dgryski-go-metro Version : 0.0~git20180109.280f606-1 Upstream Author : Damian Gryski * URL : https://github.com/dgryski/go-metro * License : Expat Programming Lang: Go Description : Go translation of MetroHash This package is a mechanical translation of the reference C++ code for MetroHash. dependency of v2ray(>= 4.25.0) signature.asc Description: OpenPGP digital signature
Bug#963232: iceweasel: seccomp sandbox violation: syscall 332 (__NR_statx) on amd64
Package: firefox-esr Version: 68.9.0esr-1 Severity: minor Getting lots of these messages in the terminal I start iceweasel from: (firefox-esr:11732): dbind-WARNING **: 06:16:15.445: AT-SPI: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not provided by any .service files ###!!! [Child][RunMessage] Error: Channel closing: too late to send/recv, messages will be lost (firefox-esr:11732): dbind-WARNING **: 06:16:17.113: AT-SPI: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not provided by any .service files (firefox-esr:11732): GLib-GObject-WARNING **: 06:16:47.693: ../../../gobject/gsignal.c:3599: signal name 'selection_changed' is invalid for instance '0x7feba445db30' of type 'MaiAtkType319' (firefox-esr:11732): GLib-GObject-WARNING **: 06:18:56.396: ../../../gobject/gsignal.c:3599: signal name 'selection_changed' is invalid for instance '0x7feba31b6bf0' of type 'MaiAtkType13b' […] (firefox-esr:11732): GLib-GObject-WARNING **: 06:21:13.527: ../../../gobject/gsignal.c:3599: signal name 'selection_changed' is invalid for instance '0x7feba81f9b30' of type 'MaiAtkType13b' Sandbox: seccomp sandbox violation: pid 11809, tid 11969, syscall 332, args 0 0 0 4095 0 262144. (firefox-esr:11732): GLib-GObject-WARNING **: 06:22:50.816: ../../../gobject/gsignal.c:3599: signal name 'selection_changed' is invalid for instance '0x7feba445db30' of type 'MaiAtkType319' (firefox-esr:11732): GLib-GObject-WARNING **: 06:23:30.312: ../../../gobject/gsignal.c:3599: signal name 'selection_changed' is invalid for instance '0x7feba6563530' of type 'MaiAtkType13b' (firefox-esr:11732): GLib-GObject-WARNING **: 06:23:31.106: ../../../gobject/gsignal.c:3599: signal name 'selection_changed' is invalid for instance '0x7feba4850f50' of type 'MaiAtkType13b' Sandbox: seccomp sandbox violation: pid 11892, tid 12032, syscall 332, args 0 0 0 4095 0 262144. IPDL protocol error: Handler returned error code! ###!!! [Parent][DispatchAsyncMessage] Error: PLayerTransaction::Msg_ReleaseLayer Processing error: message was deserialized, but the handler returned false (indicating failure) -- Package-specific info: -- Addons package information -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'oldstable-updates'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.6.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) Versions of packages firefox-esr depends on: ii debianutils 4.11 ii fontconfig2.13.1-4.2 ii libasound21.2.2-2.2 ii libatk1.0-0 2.36.0-2 ii libc6 2.30-8 ii libcairo-gobject2 1.16.0-4 ii libcairo2 1.16.0-4 ii libdbus-1-3 1.12.18-1 ii libdbus-glib-1-2 0.110-5 ii libevent-2.1-72.1.11-stable-1 ii libffi7 3.3-4 ii libfontconfig12.13.1-4.2 ii libfreetype6 2.10.1-2 ii libgcc-s1 10.1.0-3 ii libgdk-pixbuf2.0-02.40.0+dfsg-5 ii libglib2.0-0 2.64.3-1 ii libgtk-3-03.24.20-1 ii libjsoncpp1 1.7.4-3.1 ii libnspr4 2:4.25-1 ii libnss3 2:3.53-1 ii libpango-1.0-01.44.7-4 ii libsqlite3-0 3.32.3-1 ii libstartup-notification0 0.12-6 ii libstdc++610.1.0-3 ii libx11-6 2:1.6.9-2+b1 ii libx11-xcb1 2:1.6.9-2+b1 ii libxcb-shm0 1.14-2 ii libxcb1 1.14-2 ii libxcomposite11:0.4.5-1 ii libxdamage1 1:1.1.5-2 ii libxext6 2:1.3.3-1+b2 ii libxfixes31:5.0.3-2 ii libxrender1 1:0.9.10-1 ii libxt61:1.1.5-1+b3 ii procps2:3.3.16-5 ii zlib1g1:1.2.11.dfsg-2 Versions of packages firefox-esr recommends: ii libavcodec57 7:3.2.14-1~deb9u1 ii libavcodec58 7:4.3-2 Versions of packages firefox-esr suggests: ii fonts-lmodern 2.004.5-6 ii fonts-stix [otf-stix] 1.1.1-4 ii libcanberra0 0.30-7 ii libgssapi-krb5-2 1.17-10 ii libgtk2.0-02.24.32-4 pn pulseaudio -- no debconf information
Bug#963230: RFS: octave-iso2mesh/1.9.5 [RFS] -- a 3D surface and volumetric mesh generator for MATLAB/Octave
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "octave-iso2mesh": * Package name : octave-iso2mesh Version : 1.9.5 Upstream Author : Qianqian Fang (fangqq at gmail.com) * URL : https://iso2mesh.sf.net * License : GPLv2+ * Vcs : https://github.com/fangq/is2mesh Section : science It builds those binary packages: octave-iso2mesh - a 3D surface and volumetric mesh generator for Octave iso2mesh-demos - demo script and sample data for iso2mesh To access further information about this package, please visit the following URL: https://mentors.debian.net/package/octave-iso2mesh Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/o/octave-iso2mesh/octave-iso2mesh_1.9.5-1.dsc Changes since the last upload: * Initial release (Closes: #962608) -- Qianqian Fang Sat, 13 Jun 2020 15:20:58 -0400 Regards,
Bug#963177: calendar: trying to overwrite '/etc/calendar/default', which is also in package bsdmainutils 12.1.1
Hi Josh, I figured you might be interested in this, too, as IIRC the original patch was from you: * Thorsten Glaser [200621 02:04]: > Selecting previously unselected package calendar. > (Reading database ... 406194 files and directories currently installed.) > Preparing to unpack .../calendar_12.1.1_x32.deb ... > Unpacking calendar (12.1.1) ... > dpkg: error processing archive > /var/cache/apt/archives/calendar_12.1.1_x32.deb (--unpack): > trying to overwrite '/etc/calendar/default', which is also in package > bsdmainutils 12.1.1 > dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) > Errors were encountered while processing: > /var/cache/apt/archives/calendar_12.1.1_x32.deb > E: Sub-process /usr/bin/dpkg returned an error code (1) Chris
Bug#963229: nmu: bsdmainutils_12.1.1
Package: release.debian.org User: release.debian@packages.debian.org Usertags: binnmu Severity: normal Hello, bsdmainutils 12.1.1 had to pass through NEW, please schedule a binNMU to get rid of the amd64 binaries. nmu bsdmainutils_12.1.1 . ANY . -m 'Rebuild on buildd network' Thanks, Chris
Bug#963228: nmu: openscap_1.2.17-0.1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu This is a binNMU request after having a non-source-only upload due to NEW queue. nmu openscap_1.2.17-0.1 . amd64 . unstable . -m "Rebuild on buildd" -- Regards, Boyuan Yang
Bug#963227: quilt: column dependency
Package: quilt Hi, I've noticed your package depends on bsdmainutils, maybe for column(1). If so, you probably want to change that dependency to bsdextrautils. Chris
Bug#963226: hollywood: update deps for hexdump
Package: hollywood Hi, I've noticed your package depends on bsdmainutils; possibly because it wants "hexdump" to be available. If so, please check if you need to switch dependencies from bsdmainutils to bsdextrautils. Chris
Bug#960390: x86_64: No serial port output
Hi Steve, Here's an updated patch to enable serial console in grub when using debian-installer on an EFI based system. Sorry it took longer than anticipated - got pulled into some other things. The patch has been updated based on your feedback (and some experimentation). Notably, this version does not touch other configuration but uses the "--append" option of terminal_output/terminal_input to add serial port support. I've tested this on Qemu and it solves the problem I was hitting. If the changes look OK, do consider including the patch to get wider coverage / testing in more scenarios. Thanks, Punit 0001-x86-grub-efi-Enable-serial-console.patch Description: Binary data
Bug#963225: ITP: prince-of-persia -- SDL port of the classic Prince of Persia game
Package: wnpp Severity: wishlist Owner: Kees Cook * Package name: prince-of-persia Version : 1.20 Upstream Author : Dávid Nagy * URL : https://github.com/NagyD/SDLPoP * License : GPL-3+ Programming Lang: C Description : SDL port of the classic Prince of Persia game Prince of Persia is a fantasy cinematic platformer designed and implemented by Jordan Mechner for the Apple II in 1989. Taking place in ancient Persia, players control an unnamed protagonist who must venture through a series of dungeons to defeat the Grand Vizier Jaffar and save an imprisoned princess. - why is this package useful/relevant? There is a active community of people dedicated to preserving and improving this classic video game. - is it a dependency for another package? No, it is a game, and only depends on SDL2. - do you use it? Yes. - if there are other packages providing similar functionality, how does it compare? This is one of a kind. :) - how do you plan to maintain it? I intend to be a single maintainer. I am an upstream contributor. - are you looking for co-maintainers? I am not actively looking, but I wouldn't turn down help. :) - do you need a sponsor? Nope.
Bug#791928: st: diff for NMU version 1.9-3.2
Control: tags 791928 + pending
Dear maintainer,
I've prepared an NMU for st (versioned as 1.9-3.2) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.
Regards,
Boyuan Yang
diff -Nru st-1.9/debian/changelog st-1.9/debian/changelog
--- st-1.9/debian/changelog 2020-06-20 19:32:55.0 -0400
+++ st-1.9/debian/changelog 2020-06-20 19:31:02.0 -0400
@@ -1,3 +1,17 @@
+st (1.9-3.2) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * debian/patches: Add patch to fix FTBFS on AArch64.
+(Closes: #791928)
+ * debian/patches: Migrate from CDBS simplepatch to "3.0 (quilt)"
patch
+handling.
+ * debian/control:
++ Properly place Homepage field to have information properly
identified
+ by the package tracking system.
+ * debian/source/format: Use "3.0 (quilt)" source format.
+
+ -- Boyuan Yang Sat, 20 Jun 2020 19:31:02 -0400
+
st (1.9-3.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru st-1.9/debian/control st-1.9/debian/control
--- st-1.9/debian/control 2020-06-20 19:32:55.0 -0400
+++ st-1.9/debian/control 2020-06-20 19:20:22.0 -0400
@@ -4,6 +4,7 @@
Maintainer: Wesley W. Terpstra (Debian)
Build-Depends: debhelper (>= 7.0.0), cdbs (>= 0.4.52), autotools-dev
Standards-Version: 3.8.3.0
+Homepage: http://state-threads.sourceforge.net/
Package: libst-dev
Section: libdevel
@@ -11,7 +12,6 @@
Depends: libst1 (= ${binary:Version}), ${misc:Depends}, libc6-dev
Recommends: pkg-config
Conflicts: sox (<= 12.17.2-1), sox-dev
-Homepage: http://state-threads.sourceforge.net/
Description: State Threads Library - Development files
The State Threads library has an interface similar to POSIX threads.
.
@@ -29,7 +29,6 @@
Section: libs
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
-Homepage: http://state-threads.sourceforge.net/
Description: State Threads Library
The State Threads library has an interface similar to POSIX threads.
.
diff -Nru st-1.9/debian/patches/791928_arm64_support.patch st-
1.9/debian/patches/791928_arm64_support.patch
--- st-1.9/debian/patches/791928_arm64_support.patch1969-12-31
19:00:00.0 -0500
+++ st-1.9/debian/patches/791928_arm64_support.patch2020-06-20
19:21:17.0 -0400
@@ -0,0 +1,23 @@
+Bug-Debian: https://bugs.debian.org/791928
+Forwarded: no
+
+---
+diff -urN st-1.9-/md.h st-1.9/md.h
+--- st-1.9-/md.h 2015-09-28 22:40:31.42000 +
st-1.9/md.h2015-09-28 23:14:01.93000 +
+@@ -427,6 +427,15 @@
+ #error "ARM/Linux pre-glibc2 not supported yet"
+ #endif /* defined(__GLIBC__) && __GLIBC__ >= 2 */
+
++#elif defined(__aarch64__)
++#define MD_STACK_GROWS_DOWN
++
++#if defined(__GLIBC__) && __GLIBC__ >= 2
++#define MD_GET_SP(_t) (_t)->context[0].__jmpbuf[11]
++#else
++#error "ARM64/Linux pre-glibc2 not supported yet"
++#endif /* defined(__GLIBC__) && __GLIBC__ >= 2 */
++
+ #elif defined(__s390__)
+ #define MD_STACK_GROWS_DOWN
+
diff -Nru st-1.9/debian/patches/series st-1.9/debian/patches/series
--- st-1.9/debian/patches/series1969-12-31 19:00:00.0
-0500
+++ st-1.9/debian/patches/series2020-06-20 19:29:23.0
-0400
@@ -0,0 +1,3 @@
+00-kfreebsd.patch
+01-private-symbols.patch
+791928_arm64_support.patch
diff -Nru st-1.9/debian/rules st-1.9/debian/rules
--- st-1.9/debian/rules 2020-06-20 19:32:55.0 -0400
+++ st-1.9/debian/rules 2020-06-20 19:31:01.0 -0400
@@ -2,7 +2,6 @@
include /usr/share/cdbs/1/rules/debhelper.mk
include /usr/share/cdbs/1/class/makefile.mk
-include /usr/share/cdbs/1/rules/simple-patchsys.mk
DEB_MAKE_FLAGS = CC=gcc LD=gcc EXTRA_CFLAGS="$(CFLAGS) $(CPPFLAGS)"
LDFLAGS="-shared -Wl,-soname=libst.so.1 -Wl,-z -Wl,noexecstack"
DEB_MAKE_INVOKE = $(DEB_MAKE_ENVVARS) $(MAKE) $(DEB_MAKE_FLAGS)
diff -Nru st-1.9/debian/source/format st-1.9/debian/source/format
--- st-1.9/debian/source/format 1969-12-31 19:00:00.0 -0500
+++ st-1.9/debian/source/format 2020-06-20 19:20:32.0 -0400
@@ -0,0 +1 @@
+3.0 (quilt)
signature.asc
Description: This is a digitally signed message part
Bug#859652: mutt: Crashes when trying to display (or fetch) a specific S/MIME-signed message
Control: tag -1 - moreinfo Control: fixed -1 1.10.1-2.1+deb10u2 ControL: fixed -1 1.14.4-1 Hi Antonio, Antonio Radici wrote: > > > > > for the first time since upgrading to Stretch a few months ago, mutt > > > > > crashed when I pressed enter on mail -- both when viewing locally as > > > > > well as via IMAP). Starting up mutt again and trying to display that > > > > > mail again crashes again, i.e. it seems to be reproducible. [...] > getting back to you some years later, I was wondering if this bug is > still present. Is it reproducible in sid? I checked Buster first: Both, mutt and neomutt in Buster do not crash on that mail anymore. I then checked on Sid. No crashes (And yes, I still had a mailbox named "crashes-mutt" with a single mail in it — dating about half an hour before my bug report. :-) So feel free to close the bug report. Not sure if you also want to track this bug for neomutt, too. The versions I tried are: * Buster: 20180716+dfsg.1-1 * Sid: 20191207+dfsg.1-1.1 (and I noticed that I should update that Sid box again... ;-) Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#963224: nmu: pulseeffects_4.7.1-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu pulseeffects_4.7.1-2 . ANY . unstable . -m "rebuild with meson that has bug 960877 fixed" pulseeffects is currently statically linked with Boost due to #960877.
Bug#963220: ELPA: pspp-mode.el installed in package pspp 1.2.0-5 via dh_elpa cannot be installed
Hi Friedrich, Friedrich Beckmann writes: > Hi Nicholas, > > thanks for looking into the problem! > You're welcome :-) Sorry I won't be able to look into it in-depth for the near-future, but here are some hints: >> Am 20.06.2020 um 22:22 schrieb Nicholas D Steeves : >> Friedrich Beckmann writes: >> >> Installed with dpkg/apt? > > Installed with apt. > [snip] >>> In the current emacs version in testing 1:26.3+1-2 >>> I cannot install the package. When I run >>> >>> M-x package-list-packages >>> >>> I see: >>> ... >>> zones 2019.7.13 available Zones of text - like multiple >>> regions >>> ztree 1.0.5 available Text mode directory tree >>> poker 0.2 installed Texas hold 'em poker >>> psgml 1.3.4 installed SGML-editing mode with parsing >>> support >>> dh-elpa2.0.4 external package.el style packages for >>> Debian >>> pspp-mode 1.0 external Major mode for editing PSPP >>> files >> >>* if you click on pspp-mode I think you'll find >> Status: External in >> ‘/usr/share/emacs/site-lisp/elpa-src/pspp-mode-1.0/pspp-mode.el’ > > I see: > Status: External in ‘/usr/share/emacs/site-lisp/elpa/pspp-mode-1.0/’ > (unsigned). > >>* "Status: External" means it has been installed. >>* What does M-x locate-library psp-mode return? > > M-x locate-library pspp-mode returns: > > Library is file /usr/share/emacs/site-lisp/pspp/pspp-mode.el > This combination of facts makes me wonder if something is wrong with pspp's ELPA/packages.el metadata. >>> There are only the dh-elpa and the pspp-mode package listed as „external“. >>> When >>> I type „i“ to install pspp-mode, then this does not work. >> >> Haven't you already installed it with 'apt install pspp‘? > > Yes, I have and I expected that I can activate the pspp-mode simply > with "M-x pspp-mode“, but that is not possible. I have to do > > M-x load-library pspp-mode.el (loading from > /usr/share/emacs/site-lisp/pspp/pspp-mode.el) > > and then I can do > > M-x pspp-mode > > to switch the mode. As far as I remember the only requirement for that > would be to have just the pspp-mode.el file in that path, no? > See above. IIRC, clicking on pspp-mode should return the path to the library's file and not the library's load-path. >>> This works for the „available“ packages. So listing works, the info is >>> shown but I cannot use the package. It seems that nobody else uses >>> dh-elpa right? >> >> Plenty of people use dh-elpa :-) At this point it's unclear what you're >> reporting. Maybe it's one of these?: >> >> 1. pspp regression after converting to dh-elpa >> * normal bug, against in pspp package > > Maybe I use dh-elpa in wrong way in the pspp debian package setup. > I remember that it worked some time ago but today it does not. > The first thing to try is a rebuild of the package using an up-to-date sid (meaning up-to-date dh-elpa). On the Emacsen Team we occasionally rebuild all packages built with ancient dh-elpa versions, but given the two recent uploads I don't think this is the problem. It's also recommended to use a bin:elpa-pspp or bin:elpa-pspp-mode package. Legacy all-in-one non-Emacs packages containing an Emacs mode are less well tested, and it's possible you found found a bug in this. >> 2. request to install Debian packages from the 'package-list-packages' >> interface. >> * wishlist bug in src:emacs (in a desktop-general sense) to add >> Debian package management to packages.el > > No, I expect that I can activate the pspp-mode right after installation > of the pspp package via apt. > Agreed, that's how it should work. [snip] > As far as I remember the dh-elpa procedure worked some time ago but now > it is at least unexpected behaviour. I expect that I can use the > pspp-mode after the installation of the pspp package directly. But > this does not happen. Maybe I use the dh-elpa package in a wrong way > during the preparation of the pspp debian package. [snip] > The pspp debian package is here: > > https://salsa.debian.org/science-team/pspp/-/tree/master/debian Well, no commits mention dh-elpa, and the changelog entry doesn't mention it either...which makes me suspect there may be other problems. > Maybe I use emacs in a wrong way. Maybe emacs is broken with external > packages. Really? This is a bit hyperbolic ;-) > Thanks for your detailed questions! I hope I could clarify the > things. It would really help if somebody with more experience with > emacs and dh-elpa could have a look at this. Sorry I can't be of more help at this time; I'm at a point where I have to avoid taking on additional responsibilities. Other hints are enabling DH_VERBOSE and checking the build log for anything elpa-related, and also seeing if the dh-elpa managed byte-compilation detects the correct ELPA/packages.el name and version during package installation. And of course man
Bug#851557: maven-repo-helper: Fails to parse
This issue also occurs with jakarta-activation 2.0:
SEVERE: An error occured when processing the pom file ./activation/pom.xml
javax.xml.stream.XMLStreamException: ParseError at [row,col]:[76,17]
Message:
http://www.w3.org/TR/1999/REC-xml-names-19990114#ElementPrefixUnbound?Xlint:all
at
java.xml/com.sun.org.apache.xerces.internal.impl.XMLStreamReaderImpl.next(XMLStreamReaderImpl.java:652)
at org.debian.maven.repo.POMReader.readPom(POMReader.java:82)
at org.debian.maven.repo.POMReader.readPom(POMReader.java:57)
at
org.debian.maven.repo.POMTransformer.keepPomVersion(POMTransformer.java:171)
at
org.debian.maven.repo.POMTransformer$2.handlePOM(POMTransformer.java:162)
at org.debian.maven.repo.ListOfPOMs.foreachPoms(ListOfPOMs.java:102)
at
org.debian.maven.repo.POMTransformer.keepPomVersions(POMTransformer.java:159)
at org.debian.maven.repo.POMTransformer.main(POMTransformer.java:770)
I tried disabling namespace awareness in POMReader with:
protected final XMLInputFactory factory = XMLInputFactory.newInstance();
{
factory.setProperty(XMLInputFactory.IS_NAMESPACE_AWARE, Boolean.FALSE);
}
But this doesn't work, the parser then throws an exception on namespace
declarations.
The solution is probably to switch to the same XML parser used by Maven (xpp3?).
Bug#963223: libjulia-openblas64: file conflict with libjulia1: /usr/lib/x86_64-linux-gnu/julia/libopenblas64_.so{,.0}
Package: libjulia-openblas64 Version: 0.3.9+ds-2 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package failed to install because it tries to overwrite other packages files. >From the attached log (scroll to the bottom...): Preparing to unpack .../libjulia-openblas64_0.3.9+ds-2_amd64.deb ... Unpacking libjulia-openblas64:amd64 (0.3.9+ds-2) ... dpkg: error processing archive /var/cache/apt/archives/libjulia-openblas64_0.3.9+ds-2_amd64.deb (--unpack): trying to overwrite '/usr/lib/x86_64-linux-gnu/julia/libopenblas64_.so', which is also in package libjulia1 1.4.1+dfsg-1 Errors were encountered while processing: /var/cache/apt/archives/libjulia-openblas64_0.3.9+ds-2_amd64.deb cheers, Andreas libjulia1=1.4.1+dfsg-1_libjulia-openblas64=0.3.9+ds-2.log.gz Description: application/gzip
Bug#963067: mitmproxy 5.1.1 new update not usable!
Dear Python3 application packagers team, Please re-open the bug because Mitmproxy update 5.1.1 does not, in fact, work, so far as I can see it cannot even work on a debian 'unstable' chroot due to internal dependencies as provided. Despite 'patching out zstandard' done by packager, mitmproxy contains some internal dependency on zstandard and so won't start. There is also a python3-cryptography internal dependency that isn't satisfied. Both of the following internal dependency-errors may appear, for example:- pkg_resources.DistributionNotFound: The 'zstandard<0.14,>=0.11' distribution was not found and is required by mitmproxy pkg_resources.DistributionNotFound: The 'cryptography<3.0,>=2.9' distribution was not found and is required by mitmproxy I'm fairly sure the right thing to do is to complete debian bugs #963181 #963114, getting zstandard available and cryptography updated, then rebuild 5.1.1 package with:- 1) debian python3-zstandard dependency added 2) patch-out-zstandard change reverted 3) debian python3-cryptography dependency bumped to need at least 2.9 Hope that helps. --Simon p.s. not convinced the dependency bump on other parts are necessarily correct, e.g. urwid 2.1.0 ... be helpful if package is backportable with not so many other packages.
Bug#963220: ELPA: pspp-mode.el installed in package pspp 1.2.0-5 via dh_elpa cannot be installed
Hi Nicholas, thanks for looking into the problem! > Am 20.06.2020 um 22:22 schrieb Nicholas D Steeves : > > Control: tag -1 moreinfo > > Hi, > > Lev, I've CCed you with a question at the bottom (the question is #3). > > Friedrich Beckmann writes: > >> Package: dh-elpa >> Version: 2.0.3 >> >> Hi, >> >> i run some tests on debian testing. I installed the recently build >> pspp 1.2.0-5 package which uses dh-elpa to install pspp-mode.el >> for emacs. > > Installed with dpkg/apt? Installed with apt. > >> In the current emacs version in testing 1:26.3+1-2 >> I cannot install the package. When I run >> >> M-x package-list-packages >> >> I see: >> ... >> zones 2019.7.13 available Zones of text - like multiple >> regions >> ztree 1.0.5 available Text mode directory tree >> poker 0.2 installed Texas hold 'em poker >> psgml 1.3.4 installed SGML-editing mode with parsing >> support >> dh-elpa2.0.4 external package.el style packages for >> Debian >> pspp-mode 1.0 external Major mode for editing PSPP >> files > >* if you click on pspp-mode I think you'll find > Status: External in > ‘/usr/share/emacs/site-lisp/elpa-src/pspp-mode-1.0/pspp-mode.el’ I see: Status: External in ‘/usr/share/emacs/site-lisp/elpa/pspp-mode-1.0/’ (unsigned). >* "Status: External" means it has been installed. >* What does M-x locate-library psp-mode return? M-x locate-library pspp-mode returns: Library is file /usr/share/emacs/site-lisp/pspp/pspp-mode.el >> There are only the dh-elpa and the pspp-mode package listed as „external“. >> When >> I type „i“ to install pspp-mode, then this does not work. > > Haven't you already installed it with 'apt install pspp‘? Yes, I have and I expected that I can activate the pspp-mode simply with "M-x pspp-mode“, but that is not possible. I have to do M-x load-library pspp-mode.el (loading from /usr/share/emacs/site-lisp/pspp/pspp-mode.el) and then I can do M-x pspp-mode to switch the mode. As far as I remember the only requirement for that would be to have just the pspp-mode.el file in that path, no? >> This works for the „available“ packages. So listing works, the info is >> shown but I cannot use the package. It seems that nobody else uses >> dh-elpa right? > > Plenty of people use dh-elpa :-) At this point it's unclear what you're > reporting. Maybe it's one of these?: > > 1. pspp regression after converting to dh-elpa > * normal bug, against in pspp package Maybe I use dh-elpa in wrong way in the pspp debian package setup. I remember that it worked some time ago but today it does not. > 2. request to install Debian packages from the 'package-list-packages' > interface. > * wishlist bug in src:emacs (in a desktop-general sense) to add > Debian package management to packages.el No, I expect that I can activate the pspp-mode right after installation of the pspp package via apt. > 3. request for information about how to install elpa-foo packages using > apt from inside emacs. Lev, I seem to remember that you maintain one > or two packages that can do this. No, I do not want to run apt from within emacs. > 4. something else As far as I remember the dh-elpa procedure worked some time ago but now it is at least unexpected behaviour. I expect that I can use the pspp-mode after the installation of the pspp package directly. But this does not happen. Maybe I use the dh-elpa package in a wrong way during the preparation of the pspp debian package. Maybe I use emacs in a wrong way. Maybe emacs is broken with external packages. The pspp debian package is here: https://salsa.debian.org/science-team/pspp/-/tree/master/debian Thanks for your detailed questions! I hope I could clarify the things. It would really help if somebody with more experience with emacs and dh-elpa could have a look at this. > Cheers, > Nicholas
Bug#949196: libzypp: diff for NMU version 17.7.0-1.1
Hi, Am Samstag, 20. Juni 2020 schrieb Giovanni Mascellani: > Control: tags 949196 + patch > Control: tags 949196 + pending > > Dear maintainer, > > I've prepared an NMU for libzypp (versioned as 17.7.0-1.1) and > uploaded it to DELAYED/02. Please feel free to tell me if I > should delay it longer. > > Regards. Thanks for patching libzypp. Your NMU is ok, I will include your .debdiff on its VCS. In fact, I am considering orphaning libzypp and zypper in Debian. Do you have interest in taking over? Greets, Mike -- Gesendet von meinem Fairphone (powered by SailfishOS)
Bug#963222: readline: manpage has , but pc -I requires
Package: libreadline-dev Version: 8.0-4 The manpage indicates the correct #include is #include , but pkg-config produces a -I line for #include . I'd guess one of them is incorrect, and since the upstream info pages also mention the former, I'd guess the pkg-config specification is incorrect, i.e. perhaps it should output -I/usr/include instead. >From "man readline" SYNOPSIS #include #include #include >From "pkg-config readline --cflags": $ pkg-config readline --cflags -I/usr/include/readline -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 And we have: $ find /usr/include/readline* /usr/include/readline /usr/include/readline/rltypedefs.h /usr/include/readline/rlstdc.h /usr/include/readline/chardefs.h /usr/include/readline/tilde.h /usr/include/readline/keymaps.h /usr/include/readline/readline.h /usr/include/readline/history.h /usr/include/readline/rlconf.h Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Bug#962982: jigdo 0.7.3-5+deb10u1 flagged for acceptance
package release.debian.org tags 962982 = buster pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian buster. Thanks for your contribution! Upload details == Package: jigdo Version: 0.7.3-5+deb10u1 Explanation: fix HTTPS support in jigdo-lite and jigdo-mirror
Bug#963220: ELPA: pspp-mode.el installed in package pspp 1.2.0-5 via dh_elpa cannot be installed
Control: tag -1 moreinfo Hi, Lev, I've CCed you with a question at the bottom (the question is #3). Friedrich Beckmann writes: > Package: dh-elpa > Version: 2.0.3 > > Hi, > > i run some tests on debian testing. I installed the recently build > pspp 1.2.0-5 package which uses dh-elpa to install pspp-mode.el > for emacs. Installed with dpkg/apt? > In the current emacs version in testing 1:26.3+1-2 > I cannot install the package. When I run > > M-x package-list-packages > > I see: > ... > zones 2019.7.13 available Zones of text - like multiple > regions > ztree 1.0.5 available Text mode directory tree > poker 0.2 installed Texas hold 'em poker > psgml 1.3.4 installed SGML-editing mode with parsing > support > dh-elpa2.0.4 external package.el style packages for > Debian > pspp-mode 1.0 external Major mode for editing PSPP > files * if you click on pspp-mode I think you'll find Status: External in ‘/usr/share/emacs/site-lisp/elpa-src/pspp-mode-1.0/pspp-mode.el' * "Status: External" means it has been installed. * What does M-x locate-library psp-mode return? > There are only the dh-elpa and the pspp-mode package listed as „external“. > When > I type „i“ to install pspp-mode, then this does not work. Haven't you already installed it with 'apt install pspp'? > This works for the „available“ packages. So listing works, the info is > shown but I cannot use the package. It seems that nobody else uses > dh-elpa right? Plenty of people use dh-elpa :-) At this point it's unclear what you're reporting. Maybe it's one of these?: 1. pspp regression after converting to dh-elpa * normal bug, against in pspp package 2. request to install Debian packages from the 'package-list-packages' interface. * wishlist bug in src:emacs (in a desktop-general sense) to add Debian package management to packages.el 3. request for information about how to install elpa-foo packages using apt from inside emacs. Lev, I seem to remember that you maintain one or two packages that can do this. 4. something else Cheers, Nicholas signature.asc Description: PGP signature
Bug#958953: cups 2.2.1-8+deb9u6 flagged for acceptance
package release.debian.org tags 958953 = stretch pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian stretch. Thanks for your contribution! Upload details == Package: cups Version: 2.2.1-8+deb9u6 Explanation: fix heap buffer overflow [CVE-2020-3898] and "the `ippReadIO` function may under-read an extension field" [CVE-2019-8842]
Bug#963221: usbguard-applet-qt: Unable to launch usbguard-applet-qt under Wayland session
Package: usbguard-applet-qt Version: 0.7.4+ds-1 Severity: important Dear Maintainer, usbguard-applet-qt fails to launch when running under a wayland display session. Launching it via terminal yields: "Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway." I try to follow up by running: QT_QPA_PLATFORM=wayland usbguard-applet-qt But it also fails to launch with: "QSocketNotifier: Can only be used with threads started with QThread Using Wayland-EGL" The program does not launch at all by the GUI icon. -- System Information: Debian Release: 10.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: ppc64el (ppc64le) Kernel: Linux 4.19.0-9-powerpc64le (SMP w/16 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages usbguard-applet-qt depends on: ii libc6 2.28-10 ii libgcc1 1:8.3.0-6 ii libqt5core5a5.11.3+dfsg1-1+deb10u3 ii libqt5gui5 5.11.3+dfsg1-1+deb10u3 ii libqt5svg5 5.11.3-2 ii libqt5widgets5 5.11.3+dfsg1-1+deb10u3 ii libstdc++6 8.3.0-6 ii libusbguard00.7.4+ds-1 ii usbguard0.7.4+ds-1 usbguard-applet-qt recommends no packages. usbguard-applet-qt suggests no packages. -- debconf-show failed
Bug#963220: ELPA: pspp-mode.el installed in package pspp 1.2.0-5 via dh_elpa cannot be installed
Package: dh-elpa Version: 2.0.3 Hi, i run some tests on debian testing. I installed the recently build pspp 1.2.0-5 package which uses dh-elpa to install pspp-mode.el for emacs. In the current emacs version in testing 1:26.3+1-2 I cannot install the package. When I run M-x package-list-packages I see: ... zones 2019.7.13 available Zones of text - like multiple regions ztree 1.0.5 available Text mode directory tree poker 0.2 installed Texas hold 'em poker psgml 1.3.4 installed SGML-editing mode with parsing support dh-elpa2.0.4 external package.el style packages for Debian pspp-mode 1.0 external Major mode for editing PSPP files ada-mode 4.0 built-in major-mode for editing Ada sources ... There are only the dh-elpa and the pspp-mode package listed as „external“. When I type „i“ to install pspp-mode, then this does not work. This works for the „available“ packages. So listing works, the info is shown but I cannot use the package. It seems that nobody else uses dh-elpa right? Friedrich
Bug#962068: stretch-pu: package dbus/1.10.30-0+deb9u1
Control: tags -1 + confirmed d-i On Tue, 2020-06-02 at 21:30 +0100, Simon McVittie wrote: > dbus 1.10.30 fixes a local denial of service vulnerability for which > the Security Team have indicated they do not intend to issue a DSA > (the same one as 1.12.18). > > If possible I would like to continue to fix dbus issues in stretch > via new upstream releases; this one only contains the CVE fix, plus > its regression test and the usual Autotools noise. I suspect this will be the last such update before stretch moves to LTS, but that seems fair. This will need the usual KiBi ack, so tagging and CCing. Regards, Adam
Bug#962067: buster-pu: package dbus/1.12.18-0+deb10u1
Control: tags -1 + confirmed d-i On Tue, 2020-06-02 at 21:22 +0100, Simon McVittie wrote: > dbus 1.12.18 fixes a local denial of service vulnerability for which > the Security Team have indicated they do not intend to issue a DSA. > > If possible I would like to use upstream 1.12.x versions of dbus for > buster (security and) stable updates, similar to the policy used in > stretch and jessie. This branch includes security fixes and selected > non-intrusive bug fixes (and unfortunately also the usual Autotools > noise). > That sounds OK to me, but will need the usual KiBi-ack due to the udeb. Regards, Adam
Bug#963219: stlink-gui: Failed to load UI file: stlink-gui.ui
Package: stlink-gui Version: 1.6.1+ds-1 Severity: important Dear Maintainer, The GUI doesn't show up, may be wrong path to the ui file. In my system is '/usr/share/stlink/stlink-gui.ui'. stlink-tools is installed and working fine in the terminal. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.6.0-2-amd64 (SMP w/4 CPU cores) 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 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages stlink-gui depends on: ii libc6 2.30-8 ii libglib2.0-0 2.64.3-1 ii libgtk-3-03.24.20-1 ii libstlink11.6.1+ds-1 ii stlink-tools 1.6.1+ds-1 stlink-gui recommends no packages. stlink-gui suggests no packages. -- no debconf information
Bug#948650: stretch-pu: package nginx/1.10.3-1+deb9u3
On Mon, 2020-03-30 at 22:05 +0100, Adam D. Barratt wrote: > On Mon, 2020-01-20 at 22:43 +, Adam D. Barratt wrote: > > Control: tags -1 + confirmed > > > > On Sat, 2020-01-11 at 12:19 +0200, Christos Trochalakis wrote: > > > I'd like to upload nginx 1.10.3-1+deb9u4, addressing the non- > > > critical > > > CVE-2019-20372. > > > > Please go ahead, thanks. > > Ping? As a note, we're now planning for the final point release for stretch before it moves to LTS. Is this update still something of interest? Regards, Adam
Bug#930374: stretch-pu: package node-url-parse/1.0.5-2+deb9u1
On Sat, 2020-04-25 at 20:28 +0100, Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Tue, 2019-06-11 at 18:32 +0200, Xavier Guimard wrote: > > node-url-parse does not parse correctly hostname which leads to > > multiple vulnerabilities such as SSRF, Open Redirect, Bypass > > Authentication Protocol,... (#906058, CVE-2018-3774) > > > > I imported upstream patch in debian/patches/CVE-2018-3774.patch. > > This > > is the only changes enabled on installed files. Since this package > > didn't launch upstream test, I added also some build dependencies > > and > > installed some little required test dependencies in > > debian/tests/test_modules, and of course modify debian/rules. > > > > If you prefer to have only the security change without test, I just > > can just this commit with a debian/changelog entry: > > https://salsa.debian.org/js-team/node-url-parse/commit/e4204c37 > > > > Apologies for the long delay. Please go ahead. As a note, we're now planning for the final point release for stretch before it moves to LTS. Regards, Adam
Bug#941617: stretch-pu: package publicsuffix/20190925.1705-0+deb9u1
On Mon, 2020-03-30 at 22:03 +0100, Adam D. Barratt wrote: > Hi, > > On Tue, 2020-01-28 at 08:33 +, Adam D. Barratt wrote: > > Control: tags -1 + confirmed > > > > On 2019-10-02 22:29, Daniel Kahn Gillmor wrote: > > > > Apologies for the delay in getting back to you on this, but please > > feel free to upload. > > Gentle ping. As a note, we're now planning for the final point release for stretch before it moves to LTS. Is this update still something of interest? Regards, Adam
Bug#922579: FTBFS against opencv 4.0.1 (exp)
Hi, thanks Giovanni. I realized that after my message. Unfortunatly I can't find the time to fix the bug. Anyway, as far as I know, a 'legacy' version of FreeTure is no longer maintained. Feel free to remove it from Debian if nobody else step in. Sorry. Best, Chiara - Original Message - > From: "Giovanni Mascellani" > To: "922579" <922...@bugs.debian.org> > Sent: Friday, June 19, 2020 7:02:23 PM > Subject: Bug#922579: FTBFS against opencv 4.0.1 (exp) > Control: block 962950 by -1 > > On Tue, 23 Apr 2019 14:13:22 + (GMT) Chiara Marmo > wrote: >> Hi, >> >> sorry, I'm a bit confused about this bug. >> >> This is a problem with opencv4 in experimental distribution, right? >> Not with power pc architecture... > > No, the same thing definitely happens on amd64 as well. I tried adding a > "-I/usr/include/opencv4" to the compiler command line to see if the same > code worked with OpenCV 4, but apparently it does not. It is probably > necessary to manually port the code to the new version. > > Giovanni. > -- > Giovanni Mascellani > Postdoc researcher - Université Libre de Bruxelles -- Chiara Marmo Ingénieur de Recherche GEOPS - Paris Sud-11 Bât 509 Tel: +33 (0)1 69 15 49 03
Bug#963218: ITP: libpll-2 -- Phylogenetic Likelihood Library 2
Package: wnpp Severity: wishlist Subject: ITP: libpll-2 -- Phylogenetic Likelihood Library 2 Package: wnpp Owner: Shayan Doust Severity: wishlist * Package name: libpll-2 Version : 0.3.2 Upstream Author : Tomas Flouri * URL : https://github.com/xflouris/libpll-2 * License : AGPL-3+ Programming Lang: C Description : Phylogenetic Likelihood Library 2 PLL is a highly optimised, parallelised software library to ease the development of new software tools dealing with phylogenetic inference. . Among the function included in PLL are parsing multiple sequence alignments (MSA) from PHYLIP and FASTA files, reading Newick trees, performing topological moves such as SPR and NNI, model optimisation, likelihood evaluation and partitioned analysis by assigning different substitution models to each partition of the MSA. PLL fully implements the GTR nucleotide substitution model for DNA data and a number of models for aminoacid data. . libpll-2 is the new official fork of libpll. It implements site repeats to speed up computations. . This package contains the dynamic library. Remark: This package is maintained by Debian Med Packaging Team at https://salsa.debian.org/med-team/libpll-2
Bug#950165: uvloop FTBFS: tests/test_sockets.py hangs
Hi, On Wed, 29 Jan 2020 20:12:54 +0200 Adrian Bunk wrote: > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/uvloop.html > > ... > = test session starts > == > platform linux -- Python 3.8.1, pytest-4.6.9, py-1.8.0, pluggy-0.13.0 > rootdir: /build/1st/uvloop-0.14.0+ds1 > collected 423 items > > tests/test_aiohttp.py > tests/test_base.py > .s..s > tests/test_context.py s.. > tests/test_cython.py . > tests/test_dealloc.py . > tests/test_dns.py s.. > tests/test_executors.py > tests/test_process.py > .. > tests/test_process_spawning.py . > tests/test_regr1.py . > tests/test_signals.py s... > tests/test_sockets.py ...s.Wed Jan 29 17:44:02 UTC 2020 - > pbuilder was killed by timeout after 18h. > > > > My guess (that could be wrong) is that this might be related > to reuse_address no longer supported in Python 3.8.1: > https://bugs.python.org/issue37228 > The upstream issue: https://github.com/MagicStack/uvloop/issues/318 Piotr, I am going to upload this fix/workaround to DELAYED/5: https://salsa.debian.org/python-team/modules/uvloop/-/commit/302a7e8f5a2869e13d0550cd37e7a8f480e79869 Please shout if you object :) Hopefully it won’t be needed with the next upstream version when it’s released. -- Cheers, Andrej
Bug#963205: libmpg123-dev no longer multiarch installable
Am Sat, 20 Jun 2020 15:03:32 +0200 schrieb Christian Klein : > A diff of the header files reveals that the i386 and amd64 versions are now > different: > -#define syn123_resample_total syn123_resample_total_32 > -#define syn123_resample_intotal syn123_resample_intotal_32 > +#define syn123_resample_total syn123_resample_total_64 > +#define syn123_resample_intotal syn123_resample_intotal_64 > I guess the problem was introduced by upstream. Indeed. I am upstream and I confirm that I wrote this. But I did not intend to break multiarch … I just didn't think about it. This is a fallback for _FILE_OFFSET_BITS not being defined by the client application. The fallback is to define off_t as long, basically, which differs on 32 or 64 bit arch. Well one could drop the fallback and return an error that the client application needs to define _FILE_OFFSET_BITS … but then, there is no good solution when you got off_t sometimes as 32 bit and sometimes as 64 bit on the same platform, depending on a switch. The largefile (off_t) stuff in libsyn123 is simpler than all the hoops libmpg123 goes through, with implementing dual mode and wrappery in the library. Here, the library works with fixed 64 or 32 bits and the header shall choose the implementation that matches the client offset size. It has the side effect of the fallback being different. You could argue that I should have just used int64_t externally, but the unspecific off_t is the natural type for file/stream offsets … at least I'd like to pretend that it is:-/ Same reason I use size_t for memory sizes. Is it big trouble to separate the syn123 header into multiarch subdirs to fix debian again? Would you rather have some switch in the same header about native off_t/long size? Alrighty then, Thomas
Bug#962234: stretch-pu: package perl/5.24.1-3+deb9u7
On Mon, Jun 15, 2020 at 08:46:03PM +0100, Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Thu, 2020-06-04 at 22:02 +0100, Dominic Hargreaves wrote: > > Upstream released fixes for three regexp-related security issues > > on Monday: > > > > https://metacpan.org/pod/release/XSAWYERX/perl-5.28.3/pod/perldelta.pod > > > > The Debian security team would like these as no-dsa, so we would like > > to provide them in a point release. The patches have been trivially > > backported from 5.28. See #962005. > > > > Please go ahead. Thanks; uploaded.
Bug#961443: buster-pu: package perl/5.28.2
Control: tags -1 - moreinfo On Thu, Jun 04, 2020 at 09:44:29AM +0100, Dominic Hargreaves wrote: > Control: tags -1 + moreinfo > > On Tue, Jun 02, 2020 at 12:14:27AM +0100, Dominic Hargreaves wrote: > > Further to the above, we now have a no-dsa security issue to push out > > to buster (and stretch, but we prefer a more traditional approach there > > because of the relative size of changes and age of the release). > > > > The security issues in question are tracked at #962005. > > > > I attach the additional diff between 5.28.2 and 5.28.3 (which was > > purely a security release) - again, excluding doc and version churn. > > > > Please do let me know if you would be okay with this approach, and > > we can get the ball rolling. > > We're no longer proposing this approach for the immediate update > pending concerns around smooth upgrades (cf #962138). We expect this > an be fixable but in the meantime I'm temporarily withdrawing the > proposal. > > Expect to see a regular point release proposal with cherry-picks > shortly (for both buster and stretch). Okay, we seem to have a stable fix for this issue (as of 5.30.3-4), so I think we can put the new version bump proposal for buster back on the table. What do you think? Cheers Dominic
Bug#963217: bind9: 9.11 min-ncache-ttl patch swaps min-max ncache ttl in non-DNSSEC path
Package: bind9
Version: 1:9.11.5.P4+dfsg-5.1+deb10u1
Severity: normal
Dear Maintainer,
We run a Debian10 recursive resolver with DNSSEC-validation disabled, and
discovered that it puts
negative answers in cache at TTL of 3hours (10800s), regardless of SOA's
MININUM field.
Example query against a problem resolver:
$ dig @127.0.0.1 nx-domain.xyz | grep SOA
xyz. 10800 IN SOA ...snip snip... 3600
# rndc dumpdb -cache
# grep nx-domain /var/cache/bind/named_dump.db
nx-domain.xyz. 10800 \-ANY ...snip...
With DNSSEC validation enabled, the negative answer is cached correctly for
3600s.
As a workaround, we set min-ncache-ttl a bit bigger than the affected
internal zone's MINIMUM, and could keep dnssec-validation no.
The min-ncache-ttl patch for 9.11 series misplaced `view->maxncachettl`
into `view->minncachettl`
position in ncache_message (patch 003_min_cache_ttl.diff lines 236 to 238,
compared to lines in validated() above). This is also present in
stretch-backports patch.
This patch was dropped from bind9 9.12 packages onward, so sid/experimental
doesn't have this bug.
Please help refresh the patch, thank you.
-- System Information:
Debian Release: 10.4
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-9-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages bind9 depends on:
ii adduser 3.118
ii bind9utils 1:9.11.5.P4+dfsg-5.1+deb10u1
ii debconf [debconf-2.0] 1.5.71
ii dns-root-data 2019031302
ii libbind9-161 1:9.11.5.P4+dfsg-5.1+deb10u1
ii libc6 2.28-10
ii libcap2 1:2.25-2
ii libcom-err2 1.44.5-1+deb10u3
ii libdns1104 1:9.11.5.P4+dfsg-5.1+deb10u1
ii libfstrm0 0.4.0-1
ii libgeoip1 1.6.12-1
ii libgssapi-krb5-2 1.17-3
ii libisc1100 1:9.11.5.P4+dfsg-5.1+deb10u1
ii libisccc161 1:9.11.5.P4+dfsg-5.1+deb10u1
ii libisccfg163 1:9.11.5.P4+dfsg-5.1+deb10u1
ii libjson-c3 0.12.1+ds-2
ii libk5crypto3 1.17-3
ii libkrb5-3 1.17-3
ii liblmdb0 0.9.22-1
ii liblwres161 1:9.11.5.P4+dfsg-5.1+deb10u1
ii libprotobuf-c1 1.3.1-1+b1
ii libssl1.1 1.1.1d-0+deb10u3
ii libxml2 2.9.4+dfsg1-7+b3
ii lsb-base 10.2019051400
ii net-tools 1.60+git20180626.aebd88e-1
ii netbase 5.6
bind9 recommends no packages.
Versions of packages bind9 suggests:
pn bind9-doc
ii dnsutils 1:9.11.5.P4+dfsg-5.1+deb10u1
pn resolvconf
pn ufw
-- Configuration Files:
/etc/bind/named.conf.options changed:
options {
directory "/var/cache/bind";
// If there is a firewall between you and nameservers you want
// to talk to, you may need to fix the firewall to allow multiple
// ports to talk. See http://www.kb.cert.org/vuls/id/800113
// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses replacing
// the all-0's placeholder.
// forwarders {
// 0.0.0.0;
// };
//
// If BIND logs error messages about the root key being expired,
// you will need to update your keys. See https://www.isc.org/bind-keys
//
dnssec-validation no;
listen-on-v6 { any; };
};
-- debconf information:
bind9/different-configuration-file:
bind9/start-as-user: bind
bind9/run-resolvconf: false
Bug#949196: libzypp: diff for NMU version 17.7.0-1.1
Hi, Il 20/06/20 19:01, Mike Gabriel ha scritto: > Thanks for patching libzypp. Your NMU is ok, I will include your > .debdiff on its VCS. In fact, I am considering orphaning libzypp and > zypper in Debian. Do you have interest in taking over? No, I have no interest. Actually, I barely know what they do: I am just doing some RC sniping. Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#951476: tar2sqfs: on error, remove confusing 'corrupt' output file
Hi, On Mon, 17 Feb 2020 19:57:52 +1100 "Trent W. Buck" wrote: > Is it reasonable to delete the output file when something goes wrong? > If so, please do. > (I'm thinking of "git clone" which works like this.) This should be fixed upstream since version 0.9.1. Greetings, David
Bug#963215: ITP: espvs -- Espeak Vocal Studio
Package: wnpp Severity: wishlist The package was developed by Dmitry Golubovsky, is MIT licenced and hosted at https://github.com/dmgolubovsky/espvs It depends on hsespeak
Bug#963216: ITP: protorhymer -- Lorem Ipsum for song lyrics
Package: wnpp Severity: wishlist The package was developed by Dmitry Golubovsky, is MIT licenced and hosted at https://github.com/dmgolubovsky/protorhymer
Bug#963213: ITP: hsespeak -- A Haskell program to generate vocals from Music XML
Package: wnpp Severity: wishlist The package was developed by Dmitry Golubovsky, is MIT licenced and hosted at https://github.com/dmgolubovsky/hsespeak
Bug#963214: FTBFS on Hurd
Source: perl Version: 5.32.0~rc1-1 Severity: important - Forwarded message from Samuel Thibault - Date: Thu, 18 Jun 2020 13:48:17 +0200 From: Samuel Thibault To: Niko Tyni Cc: debian-h...@lists.debian.org, p...@packages.debian.org Subject: Re: perl_5.32.0~rc1-1 FTBFS on hurd (experimental) Hello, Niko Tyni, le jeu. 18 juin 2020 07:34:03 +0100, a ecrit: > perl_5.32.0~rc1-1 in experimental failed to build on hurd with a > test failure: > > dist/IO/t/cachepropagate-unix .. # Failed > test 'protocol defined' > # at t/cachepropagate-unix.t line 54. > # Failed test 'protocol defined' > # at t/cachepropagate-unix.t line 109. > # Looks like you failed 2 tests of 15. > > I assume this is due to > > https://github.com/Perl/perl5/commit/6212a44b69c49a5b78d8fafd2d7618642df7b708 > > which has since collected a bunch of systems where the test is ignored: > > https://github.com/Perl/perl5/blob/blead/dist/IO/t/cachepropagate-unix.t#L44 > > Could someone please confirm that hurd needs to be added to that list? The hurd tcp/ip stack currently doesn't support SO_PROTOCOL indeed. I'm surprised that perl collects a long list of systems not supporting something not defined in posix, rather than collecting a list of systems which support it. > Patches welcome of course :) I submitted https://github.com/Perl/perl5/pull/17873 Samuel - End forwarded message -
Bug#963039: [Pkg-javascript-devel] Bug#963039: Bug#963039: node-iconv: versions of nodejs dependencies not properly documented
I think this will solve build/autopkgtest issue but not the real problem. You
should instead add a:
Breaks: nodejs (<< ${source:Version}~)
In both libnode-dev and libnodeXX
Le 20 juin 2020 14:06:47 GMT+02:00, "Jérémy Lal" a écrit :
>Le ven. 19 juin 2020 à 19:34, Paul Gevers a écrit :
>
>> Hi Jérémy and Xavier,
>>
>> On 19/06/2020 13.33, Jérémy Lal wrote:
>> > libnode68 and libnode72 can be co-installed.
>>
>> Sure.
>>
>> > /usr/bin/node is going to load the lib with the SONAME it's been built
>> for.
>>
>> Of course, like any normal binary that is linked against a library in
>> Debian.
>>
>> > So of course nodejs 12.x loads libnode72 and nodejs 10.x loads libnode68.
>> > Otherwise the SONAME bump wouldn't be major.
>> >
>> > Paul: you're right to point out that it is perfectly possible for
>> > another application
>> > to link against libnode72 without needing to install nodejs 12.
>> >
>> > Xavier: i didn't think about that beforehand, but the approach you
>> suggest
>> > will break things (maybe other packages using libv8-dev, for example).
>> >
>> > I'm not sure why node-iconv depends on nodejs.
>>
>> As my other bug, node-expat seems to have the same issue.
>>
>> > Its autopkgtests should however depend on nodejs >=
>> > where is the one built against the same libnode SONAME as
>> > node-iconv (?)
>>
>> That doesn't scale, because it's every package that has an autopkgtest
>> that depends on node-iconv that has this issue. So it's node-iconv that
>> needs to declare the right versioned relation to nodejs. It looks like
>> the binary executable already knows it, but the Debian package doesn't
>> know it yet. The internal knowledge needs to be exposed somehow.
>>
>
>Since all packages that Build-Depend: libnode-dev are concerned,
>maybe the solution is to declare:
>
>libnode-dev
>Depends: nodejs (= ${binary:Version})
>
>- downside: packages depending on libv8-dev will install nodejs (this
>shouldn't be a problem).
>- a multi-arch issue ?
>
>?
--
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma
brièveté.
Bug#860122: [Pkg-mutt-maintainers] Bug#860122: Bug#860122: mutt: SIGSEGV when saving a file to sshfs dir
tag -1 +moreinfo thanks On Mon, Jun 26, 2017 at 06:38:04PM +0200, Kim Alvefur wrote: > On Mon, Jun 26, 2017 at 06:19:30AM +, Antonio Radici wrote: > > Could you please install the debug symbols and send the stacktrace again? > > Attached. > > > More info on how to do so are here: > > https://wiki.debian.org/AutomaticDebugPackages > > Thanks, I was not aware of the separate source for debug symbols when I > initially filed the report. Hi Kim, is this still an issue in sid? (1.14.4-1)
Bug#734234: closed by Antonio Radici (mutt: smime doesn't tell you who signed the message)
> tag 734234 +wontfix > thanks > > Please check the status bar, that will show the information that you need. I'm not sure what you mean here, but openssl isn't being used for smime anymore, instead it's using gpg, and it now properly displays who signed it. The output you get now looks like: [-- Begin signature information --] Good signature from: 1.2.840.113549.1.9.1=#616C656B73616E6472612E6B6170696E6F734061737365636F64732E706C,CN=Aleksandra Kapinos,ST=pomorskie,L=Gdynia,OU=PUBiZ,O=Asseco Data Systems S.A.,C=PL aka: created: Mon 15 Jun 2020 02:58:18 PM CEST [-- End signature information --] [-- The following data is signed --] [...] Kurt
Bug#963212: lintian: False positive for no-dh-sequencer when command prefix is used
Package: lintian
Version: 2.80.0
Severity: normal
Tags: patch
Dear Maintainer,
I stumbled upon a debian/rules like this:
#!/usr/bin/make -f
%:
+dh $@ --buildsystem=octave --with=octave
for which the Lintian warning no-dh-sequencer is wrongly triggered. The
root of the problem is a regular pattern in dh-sequencer.pm that does not
take into account Makefile's command prefixes. The trivial patch
attached to this bug report fixes the problem.
Best,
Rafael Laboissière
diff --git a/checks/debian/rules/dh-sequencer.pm b/checks/debian/rules/dh-sequencer.pm
index afddfbf37..31f2ad803 100644
--- a/checks/debian/rules/dh-sequencer.pm
+++ b/checks/debian/rules/dh-sequencer.pm
@@ -53,7 +53,7 @@ sub source {
my $rule_target = qr/(?:$rule_altern|'$rule_altern'|"$rule_altern")/;
$self->tag('no-dh-sequencer')
- unless $contents =~ /^[^:]+:[^ \t]*\n\t+dh[ \t]+$rule_target/m
+ unless $contents =~ /^[^:]+:[^ \t]*\n\t+(\+|@|-)?dh[ \t]+$rule_target/m
|| $contents =~ m{^\s*include\s+/usr/share/cdbs/1/class/hlibrary.mk\s*$}m
|| $contents =~ m{\bDEB_CABAL_PACKAGE\b};
Bug#952645: webext-ublock-origin: any reason we still have a 6-month old version ?
Control: tags -1 pending Hi, Am 20.06.20 um 18:20 schrieb ydir...@free.fr: [...] > Wouldn't the "pending" tag be suitable for this bugreport ? > Apparently there is no auto-tagged when fixes enter the NEW queue, > I though it was the case. > > Best regards, Sure, if it helps. The review is just taking way too long. Normally when only binary packages change, the check is much quicker. Constructive suggestions how to make the whole process faster and more user friendly should be directed towards the ftp team though. Regards, Markus signature.asc Description: OpenPGP digital signature
Bug#962903: libreoffice: Fails to open any PDF ("This PDF file is encrypted and can't be opened.")
Hi, Am 20. Juni 2020 18:02:40 MESZ schrieb Andreas Metzler : > >FWIW, yes the /tmp/test-tmp-ametzler was just for testing. Normally I >use /dev/shm, where the problem initially appeared. Could you please >also allow this? The patch now in git is what fixes this "bug". No more work on this. If your temp files are not in something user-tmp allows ( how is /dev/shm used for temp files?) then fix whatever need to be fixed yourself. Regards Rene
Bug#859652: mutt: Crashes when trying to display (or fetch) a specific S/MIME-signed message
tag -1 +moreinfo thanks On Sun, Jun 25, 2017 at 12:48:17PM +0200, Axel Beckert wrote: > Control: found -1 1.8.3+neomutt20170609-1 > > Hi Antonio, > > Axel Beckert wrote: > > Antonio Radici wrote: > > > On Wed, Apr 05, 2017 at 04:42:51PM +0200, Axel Beckert wrote: > > > > for the first time since upgrading to Stretch a few months ago, mutt > > > > crashed when I pressed enter on mail -- both when viewing locally as > > > > well as via IMAP). Starting up mutt again and trying to display that > > > > mail again crashes again, i.e. it seems to be reproducible. > > [...] > > > could you send the mail in private assuming that this is still > > > reproducible in > > > 1.8.3+neomutt20170609-1? thanks! > > > > Will do soon. (At least in 1.8.0-1, the issue is still present.) > > 1.8.3+neomutt20170609-1 crashes as well. Will send you an mbox > containing that mail in private. > Hi Axel, getting back to you some years later, I was wondering if this bug is still present. Is it reproducible in sid?
Bug#963107: "Encrypted connection unavailable" when using pre-authenticated connection
tag -1 +pending thanks On Sat, Jun 20, 2020 at 08:19:32AM +0200, Antonio Radici wrote: > On Fri, Jun 19, 2020 at 04:04:37PM -0700, Josh Triplett wrote: > > On Thu, Jun 18, 2020 at 10:41:37PM -0700, Josh Triplett wrote: > > > Package: mutt > > > Version: 1.14.3-1 > > > Severity: important > > > > > > "important" because it makes a previously working configuration > > > unusable. > > > > > > The fix for CVE-2020-14093 makes it so that when using a > > > preauthenticated connection (using `set tunnel` to SSH to the IMAP > > > server), mutt just prints "Encrypted connection unavailable" and refuses > > > the connection. An strace shows that mutt successfully runs SSH and gets > > > the preauthenticated IMAP connection. > > > > > > I do not have any ssl-related options set. Best guess: the default > > > ssl_starttls=yes makes mutt think it should starttls over preauth, which > > > it now avoids due to the CVE. > > > > I can confirm that setting ssl_starttls=no allows preauthenticated IMAP > > connections using `set tunnel` to work again. > > > > Created issue https://gitlab.com/muttmua/mutt/-/issues/250 Fix already in git, it will come up with 1.14.4-2
Bug#952645: webext-ublock-origin: any reason we still have a 6-month old version ?
Hi Markus, > There is also little value in filing pointless bug reports against > Debian packages. Sorry, I did not meant any offense in this followup to an old bugreport. It used to be that firefox allowed user to locally install a newer version of a system-wide-installed extension, but this is apparently not the case, and I could only get install a newer version by uninstalling the deb. You'll understand I found the situation as quite self-disserving for the package. > As a Debian developer you should check tracker.debian.org or NEW. > > https://ftp-master.debian.org/new/ublock-origin_1.25.0+dfsg-1.html Wouldn't the "pending" tag be suitable for this bugreport ? Apparently there is no auto-tagged when fixes enter the NEW queue, I though it was the case. Best regards, -- Yann
Bug#839556: mutt: The default 'y' keybind no longer works in a POP mailbox.
tag 839556 +moreinfo thanks Hi, is bug reproducible with the latest version of mutt on debian (1.14.4-1)?
Bug#963211: libmu-dbm6: Tries to overwrite `libmu_dbm.so.6.0.0` from `libmailutils6`
Package: libmu-dbm6 Version: 1:3.9-2 Dear Debian folks, Trying to update my Debian Sid/unstable system, `apt full-upgrade` failed with the messages below. dpkg: Fehler beim Bearbeiten des Archivs /tmp/apt-dpkg-install-9C7NlK/00-libmu-dbm6_1%3a3.9-2_i386.deb (--unpack): Versuch, »/usr/lib/i386-linux-gnu/libmu_dbm.so.6.0.0« zu überschreiben, welches auch in Paket libmailutils6:i386 1:3.7-2.1 ist dpkg-deb: Fehler: »einfügen«-Unterprozess wurde durch Signal (Datenübergabe unterbrochen (broken pipe)) getötet It looks like some conflict needs to be added? Kind regards, Paul
Bug#963210: qa.debian.org: DDPO still using old name
Package: qa.debian.org Severity: normal Hi, In the past months, I have been gradually switching all my online identities to my new name (Martina) and uid/nick (Tina). I have changed emails, GPG keys, and finally my Debian LDAP uid. Most Debian services picked up the change, but DDPO still shows my deadname (Martín), and I don't know where it is coming from: https://qa.debian.org/developer.php?login=tina Thanks in advance for any help. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (50, 'stable'), (10, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.6.0-1-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#962903: libreoffice: Fails to open any PDF ("This PDF file is encrypted and can't be opened.")
On 2020-06-20 Rene Engelhard wrote: > Am 20.06.20 um 14:11 schrieb Rene Engelhard: > > 2575 19:27:45.464196 openat(AT_FDCWD, "/tmp/test-tmp-ametzler/Qqf3SE", > > O_RDONLY) = -1 EACCES (Permission denied) > > I wonder about that /tmp/test-tmp-ametzler. > > The apparmor rules might just allow /tmp/*, not /tmp/something/*. [...] > Based on that and the last sentence changing the status and marking this > as wontfix.# Rene, thanks for handling this very quickly, I have seen you sent a later message tagging as pending. FWIW, yes the /tmp/test-tmp-ametzler was just for testing. Normally I use /dev/shm, where the problem initially appeared. Could you please also allow this? TIA, cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Bug#963209: RFS: flpsed/0.7.3-7 [QA][RC] -- WYSIWYG pseudo PostScript editor
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "flpsed" * Package name: flpsed Version : 0.7.3-7 Upstream Author : Johannes Hofmann * URL : https://flpsed.org/flpsed.html * License : GPL-3 * Vcs : https://salsa.debian.org/debian/flpsed Section : graphics It builds those binary packages: flpsed - WYSIWYG pseudo PostScript editor flpsed-data - WYSIWYG pseudo PostScript editor - data files To access further information about this package, please visit the following URL: https://mentors.debian.net/package/flpsed Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/f/flpsed/flpsed_0.7.3-7.dsc Changes since the last upload: * QA upload. * Fix inkscape arguments to fix FTBFS. (Closes: #959654) * Update compat level to 13. -- Regards Sudip
Bug#952645: webext-ublock-origin: any reason we still have a 6-month old version ?
Am 20.06.20 um 12:32 schrieb ydir...@free.fr: > IMHO there's little value on having such a plugin packaged, if > we cannot follow the releases. > There is also little value in filing pointless bug reports against Debian packages. As a Debian developer you should check tracker.debian.org or NEW. https://ftp-master.debian.org/new/ublock-origin_1.25.0+dfsg-1.html signature.asc Description: OpenPGP digital signature
Bug#963207: RFS: zthreads/2.3.2-9 [QA] -- Object-oriented synchronization library for C++ (dev files)
Hi, I forgot to include in the changelog that this upload also closes a bug in Ubuntu, so I uploaded the package again with this fix, same revision. * Package name: zthreads Version : 2.3.2-9 Upstream Author : http://zthread.sourceforge.net/contact.html * URL : http://zthread.sourceforge.net/ * License : MIT * Vcs : https://salsa.debian.org/debian/zthreads Section : libs It builds those binary packages: libzthread-2.3-2 - Object-oriented synchronization library for C++ (dev files) libzthread-dev - Object-oriented synchronization library for C++ (runtine lib) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/zthreads Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/z/zthreads/zthreads_2.3.2-9.dsc Changes since the last upload: * QA upload. * Using new DH level format. Consequently: - debian/compat: removed. - debian/control: changed from 'debhelper' to 'debhelper-compat' in Build-Depends field and bumped level to 13. * debian/control: - Added 'Rules-Requires-Root: no' in source stanza. - Added Vcs-* fields to source stanza. - Bumped Standards-Version to 4.5.0. - Updated Priority field in source stanza to optional. - Updated short and long descriptions in both package stanzas. * debian/copyright: - Migrated to 1.0 format. - Updated all data. * debian/not-installed: added to list files that won't be installed. * debian/patches/: - All patches renamed to follow a numeric prefix system. - All patches headers updated Description, Author and Last-Update fields. - Some patches had Bug* fields added. - 080_wrong-parameter-type.patch: added to fix virtual bool add() wrong parameter type. Thanks to Thomas Merkel. (Closes: #956291, LP: #1842421) * debian/rules: - Added the DEB_BUILD_MAINT_OPTIONS variable to improve the GCC hardening. - Removed some unnecessary stuff. * debian/salsa-ci.yml: added. * debian/upstream/metadata: created. * debian/watch: bumped version to 4. Regards, -- ⢀⣴⠾⠻⢶⣦⠀ Fabio A. De Muzio Tobich ⣾⠁⢰⠒⠀⣿⡁ 9730 4066 E5AE FAC2 2683 ⢿⡄⠘⠷⠚⠋⠀ D03D 4FB3 B4D3 7EF6 3B2E ⠈⠳⣄ GPG:rsa4096/7EF63B2E pgp7LIkvISmqp.pgp Description: PGP signature
Bug#959954: pyte: diff for NMU version 0.8.0-1.1
Hi, On Sat, 20 Jun 2020 at 11:18, Adrian Bunk wrote: > I've prepared an NMU for pyte (versioned as 0.8.0-1.1) and > uploaded it to DELAYED/15. Please feel free to tell me if I > should cancel it. Thanks a lot! I have merged it in and made a normal upload. -- Cheers, Andrej
Bug#963178: /etc/cron.daily/calendar[5]: .: /etc/default/bsdmainutils: No such file or directory (was Fwd: Anacron job 'cron.daily' on tglase-nb.lan.tarent.de)
I’m getting this on my laptop as well. Incidentally, both systems did *NOT* hit #963177, and on the system which had #963177 I’m not getting this (I used dpkg -i --force-all to install there). -- Forwarded message -- From: Anacron Message-ID: <20200620054004.361de520...@tglase-nb.lan.tarent.de> Date: Sat, 20 Jun 2020 07:40:04 +0200 (CEST) Subject: Anacron job 'cron.daily' on tglase-nb.lan.tarent.de /etc/cron.daily/calendar: /etc/cron.daily/calendar[5]: .: /etc/default/bsdmainutils: No such file or directory run-parts: /etc/cron.daily/calendar exited with return code 1
Bug#949196: libzypp: diff for NMU version 17.7.0-1.1
Control: tags 949196 + patch
Control: tags 949196 + pending
Dear maintainer,
I've prepared an NMU for libzypp (versioned as 17.7.0-1.1) and
uploaded it to DELAYED/02. Please feel free to tell me if I
should delay it longer.
Regards.
--
Giovanni Mascellani
Postdoc researcher - Université Libre de Bruxelles
diff -Nru libzypp-17.7.0/debian/changelog libzypp-17.7.0/debian/changelog
--- libzypp-17.7.0/debian/changelog 2018-09-17 13:31:02.0 +0200
+++ libzypp-17.7.0/debian/changelog 2020-06-20 16:35:50.0 +0200
@@ -1,3 +1,12 @@
+libzypp (17.7.0-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Work around broken libsolv detection (closes: #949196).
+ * Fix build with Boost 1.71.
+ * Treat libxml as a C++ library.
+
+ -- Giovanni Mascellani Sat, 20 Jun 2020 16:35:50 +0200
+
libzypp (17.7.0-1) unstable; urgency=medium
* New upstream release.
diff -Nru libzypp-17.7.0/debian/patches/40e772a952ed8b0525430bca6a226e054826c662.patch libzypp-17.7.0/debian/patches/40e772a952ed8b0525430bca6a226e054826c662.patch
--- libzypp-17.7.0/debian/patches/40e772a952ed8b0525430bca6a226e054826c662.patch 1970-01-01 01:00:00.0 +0100
+++ libzypp-17.7.0/debian/patches/40e772a952ed8b0525430bca6a226e054826c662.patch 2020-06-20 16:35:50.0 +0200
@@ -0,0 +1,69 @@
+From 40e772a952ed8b0525430bca6a226e054826c662 Mon Sep 17 00:00:00 2001
+From: Adam Majer
+Date: Wed, 28 Nov 2018 16:56:15 +0100
+Subject: [PATCH] Need to explitily cast of Tribool to boolean
+
+Only explicit casts are allowed as of Boost 1.69
+---
+ zypp/RepoInfo.cc | 8
+ zypp/RepoManager.cc| 2 +-
+ zypp/repo/Applydeltarpm.cc | 2 +-
+ 3 files changed, 6 insertions(+), 6 deletions(-)
+
+diff --git a/zypp/RepoInfo.cc b/zypp/RepoInfo.cc
+index 0a3575bc8..db230c727 100644
+--- a/zypp/RepoInfo.cc
b/zypp/RepoInfo.cc
+@@ -387,11 +387,11 @@ namespace zypp
+
+
+ bool RepoInfo::repoGpgCheck() const
+- { return gpgCheck() || _pimpl->cfgRepoGpgCheck(); }
++ { return gpgCheck() || bool(_pimpl->cfgRepoGpgCheck()); }
+
+ bool RepoInfo::repoGpgCheckIsMandatory() const
+ {
+-bool ret = ( gpgCheck() && indeterminate(_pimpl->cfgRepoGpgCheck()) ) || _pimpl->cfgRepoGpgCheck();
++bool ret = ( gpgCheck() && indeterminate(_pimpl->cfgRepoGpgCheck()) ) || bool(_pimpl->cfgRepoGpgCheck());
+ if ( ret && _pimpl->internalUnsignedConfirmed() ) // relax if unsigned repo was confirmed in the past
+ ret = false;
+ return ret;
+@@ -402,10 +402,10 @@ namespace zypp
+
+
+ bool RepoInfo::pkgGpgCheck() const
+- { return _pimpl->cfgPkgGpgCheck() || ( gpgCheck() && !bool(validRepoSignature())/*enforced*/ ) ; }
++ { return bool(_pimpl->cfgPkgGpgCheck()) || ( gpgCheck() && !bool(validRepoSignature())/*enforced*/ ) ; }
+
+ bool RepoInfo::pkgGpgCheckIsMandatory() const
+- { return _pimpl->cfgPkgGpgCheck() || ( gpgCheck() && indeterminate(_pimpl->cfgPkgGpgCheck()) && !bool(validRepoSignature())/*enforced*/ ); }
++ { return bool(_pimpl->cfgPkgGpgCheck()) || ( gpgCheck() && indeterminate(_pimpl->cfgPkgGpgCheck()) && !bool(validRepoSignature())/*enforced*/ ); }
+
+ void RepoInfo::setPkgGpgCheck( TriBool value_r )
+ { _pimpl->rawPkgGpgCheck( value_r ); }
+diff --git a/zypp/RepoManager.cc b/zypp/RepoManager.cc
+index dbcf7a1b5..ad53013fe 100644
+--- a/zypp/RepoManager.cc
b/zypp/RepoManager.cc
+@@ -2243,7 +2243,7 @@ namespace zypp
+
+ // Make sure the service repo is created with the appropriate enablement
+ if ( ! indeterminate(toBeEnabled) )
+- it->setEnabled( toBeEnabled );
++ it->setEnabled( ( bool ) toBeEnabled );
+
+ DBG << "Service adds repo " << it->alias() << " " << (it->enabled()?"enabled":"disabled") << endl;
+ addRepository( *it );
+diff --git a/zypp/repo/Applydeltarpm.cc b/zypp/repo/Applydeltarpm.cc
+index 7b382be9b..0a1b8ad7e 100644
+--- a/zypp/repo/Applydeltarpm.cc
b/zypp/repo/Applydeltarpm.cc
+@@ -82,7 +82,7 @@ namespace zypp
+ else
+ WAR << "No executable " << prog << endl;
+ }
+- return _last;
++ return ( bool ) _last;
+ }
+
+ /**
diff -Nru libzypp-17.7.0/debian/patches/867c6b3190dafcd07f0ac5d8eef39268cc925141.patch libzypp-17.7.0/debian/patches/867c6b3190dafcd07f0ac5d8eef39268cc925141.patch
--- libzypp-17.7.0/debian/patches/867c6b3190dafcd07f0ac5d8eef39268cc925141.patch 1970-01-01 01:00:00.0 +0100
+++ libzypp-17.7.0/debian/patches/867c6b3190dafcd07f0ac5d8eef39268cc925141.patch 2020-06-20 16:35:50.0 +0200
@@ -0,0 +1,24 @@
+From 867c6b3190dafcd07f0ac5d8eef39268cc925141 Mon Sep 17 00:00:00 2001
+From: Adam Majer
+Date: Tue, 27 Nov 2018 15:45:43 +0100
+Subject: [PATCH] Boost.Tribool requires an explicit cast to bool
+
+operator== between boost::logic::tribool returns a tribool, which
+requires an explicit cast to bool
+---
+ zypp/TriBool.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git
Bug#963208: Grub can not be installed on AArch64 board when booted from U-Boot via EFI services
Package: debian-installer Severity: important I am trying to install Debian 'testing' on RockPro64 board. System booted from mainline U-Boot with EFI services enabled. Directly into d-i from 2020.06.15 copy of debian-testing-arm64-netinst.iso [1]. 1. https://cdimage.debian.org/cdimage/weekly-builds/arm64/iso-cd/debian-testing-arm64-netinst.iso Whole installation went fine until Grub installation: Jun 20 14:44:56 os-prober: debug: running /usr/lib/os-probes/50mounted-tests on /dev/sdb2 Jun 20 14:44:56 50mounted-tests: debug: mounted using GRUB fat filesystem driver Jun 20 14:44:56 50mounted-tests: debug: running subtest /usr/lib/os-probes/mounted/40lsb Jun 20 14:44:56 50mounted-tests: debug: running subtest /usr/lib/os-probes/mounted/90linux-distro Jun 20 14:44:56 grub-installer: info: Installing grub on 'dummy' Jun 20 14:44:57 grub-installer: info: grub-install does not support --no-floppy Jun 20 14:44:57 grub-installer: info: Running chroot /target grub-install --force "dummy" Jun 20 14:44:57 grub-installer: Installing for arm64-efi platform. Jun 20 14:45:01 grub-installer: grub-install: warning: Cannot set EFI variable Boot. Jun 20 14:45:01 grub-installer: grub-install: warning: vars_set_variable: write() failed: Invalid argument. Jun 20 14:45:01 grub-installer: grub-install: warning: _efi_set_variable_mode: ops->set_variable() failed: No such file or directory. Jun 20 14:45:01 grub-installer: grub-install: error: failed to register the EFI boot entry: No such file or directory. Jun 20 14:45:01 grub-installer: error: Running 'grub-install --force "dummy"' failed. I see Grub being present in /target/boot/efi: ~ # ls -l /target/boot/efi/ drwx--3 root root 8192 Jun 20 14:44 EFI ~ # ls -l /target/boot/efi/EFI/ drwx--2 root root 8192 Jun 20 14:45 debian ~ # ls -l /target/boot/efi/EFI/debian/ -rwx--1 root root 110 Jun 20 14:45 BOOTAA64.CSV -rwx--1 root root819152 Jun 20 14:45 fbaa64.efi -rwx--1 root root 126 Jun 20 14:45 grub.cfg -rwx--1 root root 1799536 Jun 20 14:45 grubaa64.efi -rwx--1 root root884952 Jun 20 14:45 mmaa64.efi -rwx--1 root root918872 Jun 20 14:45 shimaa64.efi ~ # But 'grub.cfg' in /target/boot/grub/ directory was not created: ~ # ls -l /target/boot/grub/ drwxr-xr-x2 root root 12288 Jun 20 14:45 arm64-efi drwxr-xr-x2 root root 4096 Jun 20 14:45 fonts -rw-r--r--1 root root 1024 Jun 20 14:45 grubenv -rw-r--r--1 root root 2395475 Jun 20 14:44 unicode.pf2 I chrooted to /target and started 'update-grub' by hand to create config file: ~ # chroot /target/ # update-grub Generating grub configuration file ... Found background image: /usr/share/images/desktop-base/desktop-grub.png Found linux image: /boot/vmlinuz-5.6.0-2-arm64 Found initrd image: /boot/initrd.img-5.6.0-2-arm64 done Then I went back to D-I and selected 'continue without boot loader' option. -- System Information: Debian Release: 10.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.6.13-300.fc32.x86_64 (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
Bug#950052: please warn for files installed into /
Hi, > please warn for files installed into / This emits against Lintian itself: W: lintian: repeated-path-segment lintian usr/share/lintian/checks/lintian/override/ N: N:The file is installed into a location that repeats the given path N:segment. An example would be /usr/lib/lib or /usr/share/myprogram/share. N: N:More often than not this is unintended. N: N: N: N:Severity: warning N: N:Check: files/hierarchy/path-segments N: W: lintian: repeated-path-segment lintian usr/share/lintian/checks/lintian/override/comments.pm W: lintian: repeated-path-segment lintian usr/share/lintian/checks/lintian/overrides.pm W: lintian: repeated-path-segment ... use --no-tag-display-limit to see all (or pipe to a file/program) This can be likely be easily fixed but, given we did not consider it would trigger against Lintian itself, it makes me consider that the severity level is too high. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#963150: /cdrom should be remounted rw before partman executes, when mapped to an ESP
On 2020.06.20 14:49, Andrei POPESCU wrote: Control: reassign -1 debian-installer On Vi, 19 iun 20, 18:36:33, Pete Batard wrote: Package: partman Severity: important Tags: d-i 'partman' is not a "real" package, reassigning accordingly. Ah yes, I found that after I opened the bug, and I have created a new one against partman-auto in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963156 Obviously, one of these should be closed so that we don't have a duplicate. Regards, /Pete
Bug#877667: firmware-realtek: please add RTL8812 firmware (rtl8812aefw.bin & rtl8812aefw_wowlan.bin)
Hello, Unfortunately 3 years later this is still not added, the device still works much worse without it, and it is still required to obtain the firmware separately to get the proper performance. The repository at the URL referenced got deleted since then, but can still accessed via: https://github.com/lwfinger/rtlwifi_new/tree/5406ea7f6f2ae1cc0da9e6f65a94c58d7d563b23/firmware/rtlwifi -- With respect, Roman
Bug#963181: python3-zstd: please package python3 zstandard library in debian
Control: reassign -1 wnpp Control: retitle -1 RFP: python3-zstd -- Python bindings to ZSTD compression library On Sb, 20 iun 20, 08:08:52, Simon Iremonger wrote: > Package: python3-zstd > Severity: wishlist > Tags: upstream > > For Python3 packaging team, > > Please package python3 zstandard (libstd) bindings in debian. > > https://pypi.org/project/zstd/ > > Zstandard is increasingly used in linux distributions packaging formats, and > is > used in upstream python3 application mitmproxy for example. > > With thanks, > > --Simon > > > > -- System Information: > Debian Release: 10.4 > APT prefers stable-updates > APT policy: (500, 'stable-updates'), (500, 'oldstable-updates'), (500, > 'stable'), (500, 'oldstable') > Architecture: amd64 (x86_64) > > Kernel: Linux 4.19.0-9-amd64 (SMP w/4 CPU cores) > Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE > Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), > LANGUAGE=en_GB:en (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled -- Looking after bugs filled against unknown packages signature.asc Description: PGP signature
Bug#963108: perl: Please include minor patch to fix FTBFS on m68k
Control: tags -1 +upstream Hi! On 6/19/20 5:54 PM, John Paul Adrian Glaubitz wrote: > On 6/19/20 8:37 AM, John Paul Adrian Glaubitz wrote: >> On 6/19/20 8:22 AM, John Paul Adrian Glaubitz wrote: >>> The attached patch fixes the problem by adding an additional 16 bits padding >>> before the opslot member which causes the alignment of opslot to be 32 bits. >> >> Attaching a patch with a better commit message for explanation. > > Third version of the patch which includes Laurent's and Geert's feedback and > which > is hopefully the version that gets merged upstream. Patch has been merged upstream [1]. Adrian > [1] > https://github.com/Perl/perl5/commit/a760468c9355bafaee57e94f13705c0ea925d9ca -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#963150: /cdrom should be remounted rw before partman executes, when mapped to an ESP
Control: reassign -1 debian-installer On Vi, 19 iun 20, 18:36:33, Pete Batard wrote: > Package: partman > Severity: important > Tags: d-i 'partman' is not a "real" package, reassigning accordingly. > THE GOAL > > > When installing Debian from the official netinst ISO in UEFI mode it may be > very convenient to do so by: > - Creating a large enough ESP (GPT or MBR) on the target installation disk > (e.g. 350 MB) > - Extracting the ISO content to said ESP and let the UEFI system proceed > from there. To boot directly from the target disk see A.2.4. Booting from hard disk in the Installation Manual. As far as I recall there was at least one image (mini.iso?) that could be written directly to the target disk with 'dd', etc. Not sure how any of these methods interact with UEFI though. > Doing so alleviates the need to use two media to complete a Debian > installation, where one can do, and, with disk capacity being plentiful > nowadays, wasting a couple hundred MB can be seen as a good tradeof if it > leads to a much easier GNU/Linux installation, especially on SoC systems > where devices and ports may be limited. > > For instance using a USB single media, with an ESP onto which the Debian 11 > netinst ISO has been extracted, is the method we are going to recommend to > proceed with a Debian installation on the Raspberry Pi 4, since there now > exists a UEFI firmware for that platform and Linux kernel 5.x has added the > networking support required for netinst (which has already been backported > to the Debian 11 5.x kernel). > > > THE PROBLEM > === > > One major roadblock with doing the above however is that, whereas partman > correctly detects the ESP and attempts to use for its intended purpose > (meaning that, after the Debian Installer has completed, EFI GRUB will be > updated to replace the netinst bootloader, therefore handling boot for the > final system), it ultimately fails to mount the ESP to /boot/efi because: > > 1. When booting from USB/HDD, the Debian installer has already mounted the > ESP to /cdrom as *read-only*. > > 2. The Linux kernel prevents a block device from being mounted more than > once *when the read/write permissions are going to be different* > > This means that, if you have an ESP with the netinst ISO content in > /dev/sda1, you will see it mounted as follows before partman launches: > > ] /dev/sda1 on /cdrom type vfat (ro,...) > > But after you partition the system (whilst telling it to keep the existing > ESP) partman will report the following error: > > ] The attempt to mount a file system with type vfat in SCSI1 (0,0,0), > ] partition #1 (sda) at /boot/efi failed. > > This effectively breaks the installation process and prevents users from > reusing the ESP. > > On the other hand, if you issue the command: > > ] mount -o remount,rw /dev/sda1 /cdrom > > prior to executing partman, then everything works as expected. > > Again, this is because /cdrom is then mounted read/write, which allows > /boot/efi (which points to the same underlying block device) to also be > mounted read/write, as required by partman for mounting ESPs as well as for > the rest of the installation process. > > In other words, the main issue is that, if an ESP is also used as the /cdrom > device, then we *must* ensure that it is mounted rw by the time partman is > invoked. > > At this stage, I must stress how critical this issue is when it comes to > ensuring that the installation of vanilla Debian on Raspberry Pi 4 can > happen with the *exact same ease* as it does on a PC. > > If we can fix this problem, then new Debian, wanting to use on a a Pi 4, > can simply create a USB drive with a small ESP, using the official netinst > ISO (as well as the the Raspberry Pi UEFI firmware) and by simply plugging > that drive on the device, they will proceed through an installation of > Debian that's about as painless as the installation of Raspbian, even as the > latter is specifically dedicated for that hardware. As such, it is highly > desirable that this issue gets fixed for the 11.0 release. > > > THE POSSIBLE SOLUTIONS > == > > I am currently seeing 3 possibilities to address the issue above. > > * OPTION #0: Ask users to switch to a shell when partman starts and issue a > 'mount -o remount,rw' command. Dismissed as option 0, since the whole point > behind opening this bug report is that asking users to toggle to a shell > during install and enter a command that they might not be familiar with is a > less than ideal solution, and one we should really strive to avoid. > > * OPTION #1: Alter the cdrom mount script > (var/lib/dpkg/info/cdrom-detect.postinst which comes from > https://packages.debian.org/bullseye/cdrom-detect) so that it tries to mount > /cdrom rw by default. This basically means editing the "linux)" case from > the script to change: > OPTIONS=ro,exec > to > OPTIONS=rw,exec > > I have tested this to produce the
Bug#772226: critcl: bashism in /bin/sh script
Control: tag -1 wontfix
On Sat, 06 Dec 2014 12:08:14 +0100 Raphael Geissert
wrote:
> I've ran checkbashisms (from the 'devscripts' package) over the whole
> archive and I found that your package has a /bin/sh script that uses a
> "bashism".
>
> checkbashisms' output:
> > possible bashism in
> > ./usr/share/tcltk/critcl-app3.1.8/tea/tclconfig/install-sh line 349
> > ($RANDOM):
> > tmpdir=${TMPDIR-/tmp}/ins$RANDOM-$$
Let me quote the relevant comment from the file:
> # Note that $RANDOM variable is not portable (e.g. dash); Use it
> # here however when possible just to lower collision chance.
> tmpdir=${TMPDIR-/tmp}/ins$RANDOM-$$
If this needs to be changed at all, it needs to be changed in automake.
--
Cheers,
Andrej
Bug#963207: RFS: zthreads/2.3.2-9 [QA] -- Object-oriented synchronization library for C++ (dev files)
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "zthreads" * Package name: zthreads Version : 2.3.2-9 Upstream Author : http://zthread.sourceforge.net/contact.html * URL : http://zthread.sourceforge.net/ * License : MIT * Vcs : https://salsa.debian.org/debian/zthreads Section : libs It builds those binary packages: libzthread-2.3-2 - Object-oriented synchronization library for C++ (dev files) libzthread-dev - Object-oriented synchronization library for C++ (runtine lib) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/zthreads Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/z/zthreads/zthreads_2.3.2-9.dsc Changes since the last upload: * QA upload. * Using new DH level format. Consequently: - debian/compat: removed. - debian/control: changed from 'debhelper' to 'debhelper-compat' in Build-Depends field and bumped level to 13. * debian/control: - Added 'Rules-Requires-Root: no' in source stanza. - Added Vcs-* fields to source stanza. - Bumped Standards-Version to 4.5.0. - Updated Priority field in source stanza to optional. - Updated short and long descriptions in both package stanzas. * debian/copyright: - Migrated to 1.0 format. - Updated all data. * debian/not-installed: added to list files that won't be installed. * debian/patches/: - All patches renamed to follow a numeric prefix system. - All patches headers updated Description, Author and Last-Update fields. - Some patches had Bug* fields added. - 080_wrong-parameter-type.patch: added to fix virtual bool add() wrong parameter type. Thanks to Thomas Merkel. (Closes: #956291) * debian/rules: - Added the DEB_BUILD_MAINT_OPTIONS variable to improve the GCC hardening. - Removed some unnecessary stuff. * debian/salsa-ci.yml: added. * debian/upstream/metadata: created. * debian/watch: bumped version to 4. Regards, -- ⢀⣴⠾⠻⢶⣦⠀ Fabio A. De Muzio Tobich ⣾⠁⢰⠒⠀⣿⡁ 9730 4066 E5AE FAC2 2683 ⢿⡄⠘⠷⠚⠋⠀ D03D 4FB3 B4D3 7EF6 3B2E ⠈⠳⣄GPG:rsa4096/7EF63B2E pgpkKYtmLSnRW.pgp Description: PGP signature
Bug#963206: /usr/bin/nm-applet: connection information window has a trasparent or black border on right and bottom side
Package: network-manager-gnome Version: 1.16.0-1 Severity: minor File: /usr/bin/nm-applet Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Just installing debian mate flavor from the stable buster release iso * What exactly did you do (or not do) that was effective (or ineffective)? I tried to change some themes * What was the outcome of this action? With some themes the trasparent space becomes black * What outcome did you expect instead? I was wishing some theming could remove the trasparent space near the window borders *** -- 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/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages network-manager-gnome depends on: ii dbus-user-session [default-dbus-session-bus] 1.12.16-1 ii dbus-x11 [dbus-session-bus] 1.12.16-1 ii libatk1.0-0 2.30.0-2 ii libayatana-appindicator3-10.5.3-4 ii libc6 2.28-10 ii libcairo2 1.16.0-4 ii libgdk-pixbuf2.0-02.38.1+dfsg-1 ii libglib2.0-0 2.58.3-2+deb10u2 ii libgtk-3-03.24.5-1 ii libjansson4 2.12-1 ii libmm-glib0 1.10.0-1 ii libnm01.24.0-1 ii libnma0 1.8.28-2 ii libnotify40.7.7-4 ii libpango-1.0-01.42.4-8~deb10u1 ii libpangocairo-1.0-0 1.42.4-8~deb10u1 ii libsecret-1-0 0.18.7-1 ii libselinux1 2.8-1+b1 ii mate-polkit [polkit-1-auth-agent] 1.20.2-1 ii network-manager 1.24.0-1 Versions of packages network-manager-gnome recommends: ii gnome-keyring 3.28.2-5 ii iso-codes 4.2-1 ii mate-notification-daemon [notification-daemon] 1.20.2-1 ii mobile-broadband-provider-info 20170903-1 ii notification-daemon 3.20.0-4 Versions of packages network-manager-gnome suggests: pn network-manager-openconnect-gnome pn network-manager-openvpn-gnome pn network-manager-pptp-gnome pn network-manager-vpnc-gnome -- no debconf information
Bug#962903: libreoffice: Fails to open any PDF ("This PDF file is encrypted and can't be opened.")
tag 962903 - wontfix
tag 962903 + patch
thanks
Hi,
Am 20.06.20 um 14:19 schrieb Rene Engelhard:
> Am 20.06.20 um 14:11 schrieb Rene Engelhard:
>> 2575 19:27:45.464196 openat(AT_FDCWD, "/tmp/test-tmp-ametzler/Qqf3SE",
>> O_RDONLY) = -1 EACCES (Permission denied)
>> I wonder about that /tmp/test-tmp-ametzler.
>>
>>
>> The apparmor rules might just allow /tmp/*, not /tmp/something/*.
>
> profile libreoffice-xpdfimport /usr/lib/libreoffice/program/xpdfimport {
> #include
>
> owner /tmp/* r, #Seems to need to read file created
> with pattern /tmp/RR
> owner /tmp/lu** rw, #makes files like
> luR.tmp/lub.tmp where R is random
> #Note, usually it's lub or luc, don't
> know why.
> [...]
Sigh. Apparently #debian-devel disagrees here and says the profile is
buggy (which I do not agree with), but thankfully the fix should be easy:
diff --git a/sysui/desktop/apparmor/program.senddoc
b/sysui/desktop/apparmor/program.senddoc
index d659ec9b98b3..797385f86ca4 100644
--- a/sysui/desktop/apparmor/program.senddoc
+++ b/sysui/desktop/apparmor/program.senddoc
@@ -17,8 +17,8 @@
profile libreoffice-senddoc INSTDIR-program/senddoc {
#include
- owner /tmp/lu** rw,#makes files like
luR.tmp/lub.tmp where R is random
- #Note, usually it's lub or luc, don't
know why.
+ #include
+
/{usr/,}bin/shrmix,
/{usr/,}bin/bash rmix,
/{usr/,}bin/dash rmix,
diff --git a/sysui/desktop/apparmor/program.soffice.bin
b/sysui/desktop/apparmor/program.soffice.bin
index 212eb7c62b15..b8c9f1b2e4b2 100644
--- a/sysui/desktop/apparmor/program.soffice.bin
+++ b/sysui/desktop/apparmor/program.soffice.bin
@@ -92,6 +92,8 @@ profile libreoffice-soffice INSTDIR-program/soffice.bin {
#include
#include
+ #include
+
#List directories for file browser
/ r,
/**/ r,
@@ -116,7 +119,6 @@ profile libreoffice-soffice
INSTDIR-program/soffice.bin {
owner @{HOME}/.config/soffice.binrc.lock rwk,
owner @{HOME}/.cache/fontconfig/**rw,
owner @{HOME}/.config/gtk-???/bookmarks r, #Make bookmarks work
- owner /tmp/psp[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]* rw,
#/tmp/psp1534203998 (printing to file)
owner /{,var/}run/user/*/dconf/user rw,
owner @{HOME}/.config/dconf/user r,
diff --git a/sysui/desktop/apparmor/program.xpdfimport
b/sysui/desktop/apparmor/program.xpdfimport
index efe10dce020d..f8bfbfe8fa49 100644
--- a/sysui/desktop/apparmor/program.xpdfimport
+++ b/sysui/desktop/apparmor/program.xpdfimport
@@ -17,9 +17,8 @@
profile libreoffice-xpdfimport INSTDIR-program/xpdfimport {
#include
- owner /tmp/* r, #Seems to need to read file created
with pattern /tmp/RR
- owner /tmp/lu** rw,#makes files like
luR.tmp/lub.tmp where R is random
- #Note, usually it's lub or luc,
don't know why.
+ #include
+
/usr/share/poppler/** r,
/usr/share/libreoffice/share/config/* r,
owner
@{HOME}/.config/libreoffice{,dev}/?/user/uno_packages/cache/log.txt rw,
(user-tmp allows /tmp/**)
Regards,
Rene
Bug#950971: Detecting false positives about i915 firmware
Hello, Am Sa., 20. Juni 2020 um 14:09 Uhr schrieb Richard Lewis : > > I also have these messages but I think they are likely false > positives. There seems to be a lot of possibly misleading information > and advice on the internet about these warnings -- would love to her > your advice on this, but i think these are mostly false positives > > * am i right in suspecting that these messages are often false positives? The kernel modules arelooked at and list all firmware blobs they might request. > * why is firmware for processors not present is being warned about? To be able to create 100% complete systems? Not sure... > * is there a way to suppress some of these warnings? (perhaps a > user-defined filter?) > * how do i tell which firmware my processor actually needs? I am using "dmesg | grep -i firmware" to check what firmware in a running system is actually loaded into the kernel. > > The longest and most plausible source i have found is [1] but it seems > to miss the point that there is no point installing firmware for a > skylake processor if you don't have one. It also recommends > downloading non-free blobs from intel which may not be the best > solution > > [1]: > https://askubuntu.com/questions/832524/possible-missing-frmware-lib-firmware-i915 > best regards, Floriian La Roche
Bug#963205: libmpg123-dev no longer multiarch installable
Package: libmpg123-dev Version: 1.26.1-1 Severity: important The i386 and amd64 versions of the dev-package are no longer co-installable. Unpacking libmpg123-dev:i386 (1.26.1-1) ... dpkg: error processing archive /tmp/apt-dpkg-install- ZpltIr/09-libmpg123-dev_1.26.1-1_i386.deb (--unpack): trying to overwrite shared '/usr/include/syn123.h', which is different from other instances of package libmpg123-dev:i386 A diff of the header files reveals that the i386 and amd64 versions are now different: $ diff -Naur 32/usr/include/syn123.h 64/usr/include/syn123.h --- 32/usr/include/syn123.h 2020-06-19 23:19:16.0 +0200 +++ 64/usr/include/syn123.h 2020-06-19 23:19:16.0 +0200 @@ -978,8 +978,8 @@ #error "Unpredicted _FILE_OFFSET_BITS value." # endif #else -#define syn123_resample_total syn123_resample_total_32 -#define syn123_resample_intotal syn123_resample_intotal_32 +#define syn123_resample_total syn123_resample_total_64 +#define syn123_resample_intotal syn123_resample_intotal_64 #endif /** Give exact output sample count for total input sample count. $ I guess the problem was introduced by upstream. This makes it impossible (or at least very hard) to build multiarch software like, for example, wine. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (999, 'unstable'), (998, 'testing'), (990, 'stable'), (500, 'unstable-debug'), (350, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.6.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#938605: svgtune: Python2 removal in sid/bullseye - reopen 938605
Old python ones are listed only as alternative dependencies to easy backports for ancient systems. https://packages.debian.org/sid/svgtune I don't think this package holds any python removal On June 20, 2020 12:49:59 AM EDT, Sandro Tosi wrote: >Control: reopen -1 > >This bug was closed, but the package has still some dependencies >towards >Python2 packages, in details: > >(binary:svgtune)Depends->python >(binary:svgtune)Depends->python-lxml > >Re-opening, so that they can be taken care of. -- Yaroslav O. Halchenko (mobile version) Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, NH, USA
Bug#963154: nmapsi4: Must not be arch:any
On Fri, Jun 19, 2020 at 02:45:37PM -0300, Joao Eriberto Mota Filho wrote: > Package: nmapsi4 > Version: 0.5~alpha2-1 > Severity: serious > Tags: ftbfs patch > Justification: fails to build from source (but built successfully in the past) > > Dear Maintainer, > > nmapsi4 fails to build from source in several architectures since 0.5~alpha2-1 > revision. > > nmapsi4 build depends of qtwebengine5-dev. Since 5.9.1+dfsg-5 revision, > released > in 30 Sep 2017, qtwebengine5-dev is only available for amd64, arm64, armhf, > i386 > and mipsel. Consequently, now nmapsi4 FTBFS in armel, mips64el, ppc64el, > s390x, > alpha, hppa, hurd-i386, ia64, m68k, powerpc, ppc64, riscv64, sh4, sparc64 and > x32. There is no FTBFS: https://buildd.debian.org/status/package.php?p=nmapsi4 There are plenty of packages in the archive whose build dependencies cannot be fulfilled on all release architectures. This is not a problem. >... > -Architecture: any > +Architecture: amd64 arm64 armhf i386 mipsel >... This would actually make things worse, since manual maintainance of such architecture lists is extra effort. Imagine qtwebengine5-dev gains support for a new architecture like riscv64. With "Architecture: any" all packages that directly or indirectly build depend on qtwebengine5-dev will automatically be built as soon as qtwebengine5-dev is available on this architecture. With an explicit architecture list bugs would have to be filed and manual uploads made for every single of these packages. > Regards, > > Eriberto cu Adrian
Bug#846296: ext4 checksum error
On 6/19/20 4:57 PM, Ralph Katz wrote: > the system now is able to run for a few weeks > between reboots before producing checksum errors Also, each reboot fails initial fsck and requires e2fsck -y As I recall, the boot screen on failed reboot displayed something like: DMAR fault status reg 2 ... garbage... run manual fsck > ralph@spike3:~$ cat /run/initramfs/fsck* > Log of fsck -C -f -a -T -t ext4 /dev/sda2 > Sat Jun 13 22:39:29 2020 > > /dev/sda2: Inode 55838449 seems to contain garbage. > > /dev/sda2: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. > (i.e., without -a or -p options) > fsck exited with status code 4 > > Sat Jun 13 22:39:34 2020 > > Log of fsck -C -f -a -T -t ext4 /dev/sda2 > Sat Jun 13 22:40:15 2020 > > /dev/sda2: Inode 55838449 seems to contain garbage. > > /dev/sda2: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. > (i.e., without -a or -p options) > fsck exited with status code 4 > > Sat Jun 13 22:40:20 2020 > > Log of fsck -C -f -a -T -t ext4 /dev/sda2 > Sat Jun 13 22:45:43 2020 > > /dev/sda2: 202311/60456960 files (1.6% non-contiguous), 14132093/241805828 > blocks > > Sat Jun 13 22:45:55 2020 > Thanks, Ralph
Bug#963204: ITP: gindex -- Gapped-spaced index with minimizer support
Package: wnpp Severity: wishlist Subject: ITP: gindex -- Gapped-spaced index with minimizer support Package: wnpp Owner: Antoni Villalonga Severity: wishlist * Package name: gindex Version : 0.0.0~git20170304.b1fb5ad Upstream Author : Ivan Sovic * URL : https://github.com/isovic/gindex * License : MIT Programming Lang: C Description : Gapped-spaced index with minimizer support A gapped-spaced index with minimizer support Remark: This package is maintained by Debian Med Packaging Team at https://salsa.debian.org/med-team/gindex
Bug#963201: flightgear: FTBFS on s390x: 10 - HIDInputUnitTests (Failed)
Source: flightgear Version: 1:2020.1.2+dfsg-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) flightgear failed to build on the s390x buildd. See https://buildd.debian.org/status/fetch.php?pkg=flightgear=s390x=1%3A2020.1.2%2Bdfsg-1=1592517578=0 Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#963200: flightgear: FTBFS on i386: 6 - FlightplanUnitTests (Failed)
Source: flightgear Version: 1:2020.1.2+dfsg-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) flightgear failed to build on the i386 buildd. See https://buildd.debian.org/status/fetch.php?pkg=flightgear=i386=1%3A2020.1.2%2Bdfsg-1=1592517255=0 Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#963202: ssh: ExitOnForwardFailure and X forwarding
Package: openssh-client Version: 1:8.3p1-1 Severity: minor Dear Maintainer, The ExitOnForwardFailure ssh(1) option is apparently not considering a failed X forwarding: | user@host:~$ /usr/bin/ssh -X otheruser@localhost -o "exitonforwardfailure yes" | X11 forwarding request failed on channel 0 | Linux host 5.6.0-2-amd64 #1 SMP Debian 5.6.14-1 (2020-05-23) x86_64 | Last login: Sat Jun 20 13:54:56 2020 from 127.0.0.1 | otheruser@host:~$ echo $DISPLAY | | otheruser@host:~$ The manpage says "if it cannot set up all requested dynamic, tunnel, local, and remote port forwardings", thus not mentioning X forwarding either way. I *think* ssh used to abort under these circumstances a long time ago, but can't be sure I remember correctly. In any case, I find the behaviour unhelpful and unintuitive. It caused me quite a bit of avoidable bug-chasing (the X client failing without a proper diagnostic didn't help, obviously). You may obviously argue "working as intended". Then please consider this a wishlist request for a "ExitOnXForwardFailure" option. (And ideally renaming of "ExitOnForwardFailure" to "ExitOnPortForwardFailure") Thank you for maintaining openssh, Jan -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (650, 'testing-debug'), (550, 'unstable-debug'), (550, 'unstable'), (10, 'experimental-debug'), (10, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.6.0-2-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages openssh-client depends on: ii adduser 3.118 ii dpkg 1.19.7 ii libc6 2.30-8 ii libedit2 3.1-20191231-1 ii libfido2-11.4.0-2 ii libgssapi-krb5-2 1.17-10 ii libselinux1 3.0-1+b3 ii libssl1.1 1.1.1g-1 ii passwd1:4.8.1-1 ii zlib1g1:1.2.11.dfsg-2 Versions of packages openssh-client recommends: ii xauth 1:1.0.10-1 Versions of packages openssh-client suggests: pn keychain pn libpam-ssh pn monkeysphere ii ssh-askpass-fullscreen [ssh-askpass] 0.3-3.1+b2 -- no debconf information signature.asc Description: PGP signature
Bug#961712: vsftpd package can't be installed when ipv6 is disabled
Hi, On Thu, 28 May 2020 11:26:09 +0200 Jean-Jacques Brucker wrote: > Source: vsftpd > Severity: critical > Tags: ipv6 > Justification: breaks the whole system > > Dear Maintainer, > > In some case (eg. embeded devices or private network), it sounds good to > desactivate ipv6. > > But when ipv6 is desactivated, for exemple with "ipv6.disable=1" into the > GRUB_CMDLINE_LINUX, > the vsftpd package can't be use, but also can't be installed, or reinstalled, > since installation fail when postinst fail to start vsftpd service. It is a widespread and imho completely acceptable solution to support IPv6 by binding to [::] (which usually binds both IPv4 and IPv6), and to do this by default. If you decide to brick your local IPv6, it is up to you to fix the config files of all the network daemons. (In this case simply enable "listen" instead of "listen_ipv6" in the config.) If you can't figure this out: don't disable IPv6 (or perhaps try to only disable IPv6 addresses on your network adapters instead of killing the address family). You already should have noticed when installing vsftpd that you need to fix this, so it is your fault the package management is in a bad state. > Fail during package install/upgrade is critical because it may leave the > system in a brocken > state (cf. "apt-get check"). If you think postinst failures breaking "apt-get check" are such a big problem I suggest you file a bug with apt. Or with debhelper. This certainly isn't a vsftpd-only issue. Lots of post-inst scripts break if the config files are broken. > To at least decrease the severity of the bug, a workaround could be to NOT > start or restart > vsftpd service during install or upgrade, or maybe better : to check ipv6 > (somewhere in /proc) > before to start or restart service in postinst. It is ridiculous to ask your completely non-standard setup to be supported out of the box. (Also I doubt such changes would ever get backported to stable, much less oldstable.) Also your chosen severity level led to this: > Version 3.0.3-12 of vsftpd is marked for autoremoval from testing on > Fri 26 Jun 2020. which is completely unreasonable. I'm going to degrade the severity to normal; although if I were the maintainer I'd probably go for "wishlist" and close it with a "wontfix" tag. regards, Stefan
Bug#963183: FREQ: Work on raw mail files
Package: dmarc-cat Version: 0.9.2-4 Severity: wishlist Dear Maintainer, It would be nice, if the complete email could just be piped to dmarc-cat. Yes, this can be acomplished by some perl wrapper script using lots of modules to extract the File from the MIME container, save it localy, extract the human readable data, save that data somewhere, delete the XML file. But wouldn't it be nice to be able to create such en entry in the sendmail aliases? dmarc-report: /usr/bin/dmarc-cat >> /var/storage/dmarc-reports -Benoît- -- 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=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8), LANGUAGE=de_CH:de (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dmarc-cat depends on: ii libassuan0 2.5.2-1 ii libc6 2.28-10 ii libgpg-error0 1.35-1 ii libgpgme11 1.12.0-6 dmarc-cat recommends no packages. dmarc-cat suggests no packages. -- no debconf information
Bug#963199: RFS: git2cl/1:2.0 git20120920-3 -- Simple tool to convert git logs to GNU ChangeLog format
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "git2cl" * Package name: git2cl Version : 1:2.0+git20120920-3 Upstream Author : [fill in name and email of upstream] * URL : https://savannah.nongnu.org/projects/git2cl * License : GPL-2+ * Vcs : https://savannah.nongnu.org/cvs/?group=git2cl Section : utils It builds those binary packages: git2cl - Simple tool to convert git logs to GNU ChangeLog format To access further information about this package, please visit the following URL: https://mentors.debian.net/package/git2cl Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/g/git2cl/git2cl_2.0+git20120920-3.dsc Changes since the last upload: * QA upload. * debian/control: - In Build-Depends field, bumped level to 13. - Bumped Standards-Version to 4.5.0. - Set Rules-Requires-Root:no. - Updated the field 'Vcs-Browser' and field 'Vcs-git' removed. - Fix Multi Arch field. * debian/copyright: updated the packaging copyright years. * debian/upstream/metadata: Created. Thank you for all the help you can give. Regards,
Bug#963198: ITP: libjson-rpc-common-perl -- transport agnostic JSON RPC helper objects
Package: wnpp Owner: gregor herrmann Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org * Package name: libjson-rpc-common-perl Version : 0.11 Upstream Author : Yuval Kogman * URL : https://metacpan.org/release/JSON-RPC-Common * License : Artistic or GPL-1+ Programming Lang: Perl Description : transport agnostic JSON RPC helper objects JSON::RPC::Common provides abstractions for JSON-RPC 1.0, 1.1 (both variations) and 2.0 (formerly 1.2) Procedure Call and Procedure Return objects (formerly known as request and result), along with error objects. It also provides marshalling objects to convert the model objects into JSON text and HTTP requests/responses. This module does not concern itself with the transport layer at all, so the JSON-RPC 1.1 and the alternative specification, which are very different on that level are implemented with the same class. The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools. signature.asc Description: Digital Signature
Bug#962903: libreoffice: Fails to open any PDF ("This PDF file is encrypted and can't be opened.")
tag 962903 - moreinfo
tag 962903 - unreproducible
retitle 962903 Fails to open any PDF ("This PDF file is encrypted and
can't be opened.") if TMPDIR is not /tmp (apparmor DENIED)
severity 962903 minor
tag 962903 + wontfix
thanks
Am 20.06.20 um 14:11 schrieb Rene Engelhard:
> 2575 19:27:45.464196 openat(AT_FDCWD, "/tmp/test-tmp-ametzler/Qqf3SE",
> O_RDONLY) = -1 EACCES (Permission denied)
> I wonder about that /tmp/test-tmp-ametzler.
>
>
> The apparmor rules might just allow /tmp/*, not /tmp/something/*.
profile libreoffice-xpdfimport /usr/lib/libreoffice/program/xpdfimport {
#include
owner /tmp/* r, #Seems to need to read file created
with pattern /tmp/RR
owner /tmp/lu** rw, #makes files like
luR.tmp/lub.tmp where R is random
#Note, usually it's lub or luc, don't
know why.
[...]
> Ah, yes:
>
> Indeed, if I set TMPDIR=/tmp/test I get that
>
> "This PDF file is encrypted and can't be opened".
>
>
> dmesg shows e.g.:
>
> "[ 692.0171072] audit: type=1400 audit(159265461.660:88): apparmor="DENIED"
> opereation="open" profile="libreoffice-xpdfimport" name="/tmp/test/4DyliY"
> pid=2661 comm="xpdfimport" requested_mask="r" denied_masj="r" fsuid=1000
> ouid=1000"
>
> And indeed, if I set that profile to complain only it works.
Based on that and the last sentence changing the status and marking this
as wontfix.#
Regards,
Rene
Bug#963197: sudo: listpw=never is broken
Package: sudo Version: 1.8.27-1+deb10u2 Severity: important Tags: upstream Dear Maintainer, * justification for Severity: (>=) important: Broken in buster (stable) (at least 1.8.27-1+deb10u2). Works in stretch (oldstable) (at least 1.8.27-1+deb10u2). Existing listpw=never functionality breaks upon stretch (oldstable) --> buster (stable) upgrade. Hopefully listpw=never fix can be cleanly backported into buster (current stable). :-) * What led up to the situation? stretch (oldstable) --> buster (stable) upgrade. Bug apparently from upstream (apparently fixed in upstream 1.8.28). $ sudo -l fails where it used to work * What exactly did you do (or not do) that was effective (or ineffective)? Not fix, but work-around, change sudoers, e.g. to include: # listpw=never bug work-around: # Defaults listpw = never Defaults listpw = any ALL ALL=(nobody:nogroup) NOPASSWD: /bin/true "" * What was the outcome of this action? fails: sudoers: Defaults listpw=never $ sudo -l Above noted work-around is effective but adds spurious additional sudo command. * What outcome did you expect instead? Should work: sudoers: Defaults listpw=never $ sudo -l * +wishlist: add listpw regression tests to Debian sudo build/test, also feed same to upstream See also / references: Apparently (but I've not verified) fixed in upstream 1.8.28: https://unix.stackexchange.com/questions/466326/listpw-default-option-not-working-with-sudo-1-8-24 https://bugzilla.sudo.ws/show_bug.cgi?id=869 https://www.sudo.ws/repos/sudo/rev/ecb89088a884 -nopass = (pwcheck == all) ? true : false; +nopass = (pwcheck == never) ? true : false; -- 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/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C), LANGUAGE=en_US.UTF-8 (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages sudo depends on: ii libaudit1 1:2.8.4-3 ii libc6 2.28-10 ii libpam-modules 1.3.1-5 ii libpam0g1.3.1-5 ii libselinux1 2.8-1+b1 ii lsb-base10.2019051400 sudo recommends no packages. sudo suggests no packages. -- Configuration Files: (not supplied, see also work-around, etc. above) -- *+Kudos: Debian is fantastic! Much appreciate all the excellent high quality work! Rare that I actually find a bug in stable - been quite a while. https://www.debian.org/intro/help :-)
Bug#962903: libreoffice: Fails to open any PDF ("This PDF file is encrypted and can't be opened.")
tag 962903 + moreinfo tag 962903 + unreproducible thanks Am 15.06.20 um 19:49 schrieb Andreas Metzler: > trying to open any PDF file in libreoffices yields the generic > PDF error page "This PDF file is encrypted and can't be opened.") Fresh testing VM. Plain Text doc just containing "Test". Exported to PDF. Opening just works. Both in LO and by command line. Did you do any special config? Something apparmor-related? Some specific TMPDIR or so? Because: > 2575 19:27:45.464196 openat(AT_FDCWD, "/tmp/test-tmp-ametzler/Qqf3SE", > O_RDONLY) = -1 EACCES (Permission denied) I wonder about that /tmp/test-tmp-ametzler. The apparmor rules might just allow /tmp/*, not /tmp/something/*. Ah, yes: Indeed, if I set TMPDIR=/tmp/test I get that "This PDF file is encrypted and can't be opened". dmesg shows e.g.: "[ 692.0171072] audit: type=1400 audit(159265461.660:88): apparmor="DENIED" opereation="open" profile="libreoffice-xpdfimport" name="/tmp/test/4DyliY" pid=2661 comm="xpdfimport" requested_mask="r" denied_masj="r" fsuid=1000 ouid=1000" And indeed, if I set that profile to complain only it works. If *you* change stuff *you* have the responsibility to change stuff so that it works with it. This is not a bug here. Regards, Rene
Bug#950971: Detecting false positives about i915 firmware
I also have these messages but I think they are likely false positives. There seems to be a lot of possibly misleading information and advice on the internet about these warnings -- would love to her your advice on this, but i think these are mostly false positives * am i right in suspecting that these messages are often false positives? * why is firmware for processors not present is being warned about? * is there a way to suppress some of these warnings? (perhaps a user-defined filter?) * how do i tell which firmware my processor actually needs? The longest and most plausible source i have found is [1] but it seems to miss the point that there is no point installing firmware for a skylake processor if you don't have one. It also recommends downloading non-free blobs from intel which may not be the best solution [1]: https://askubuntu.com/questions/832524/possible-missing-frmware-lib-firmware-i915
Bug#963039: [Pkg-javascript-devel] Bug#963039: node-iconv: versions of nodejs dependencies not properly documented
Le ven. 19 juin 2020 à 19:34, Paul Gevers a écrit :
> Hi Jérémy and Xavier,
>
> On 19/06/2020 13.33, Jérémy Lal wrote:
> > libnode68 and libnode72 can be co-installed.
>
> Sure.
>
> > /usr/bin/node is going to load the lib with the SONAME it's been built
> for.
>
> Of course, like any normal binary that is linked against a library in
> Debian.
>
> > So of course nodejs 12.x loads libnode72 and nodejs 10.x loads libnode68.
> > Otherwise the SONAME bump wouldn't be major.
> >
> > Paul: you're right to point out that it is perfectly possible for
> > another application
> > to link against libnode72 without needing to install nodejs 12.
> >
> > Xavier: i didn't think about that beforehand, but the approach you
> suggest
> > will break things (maybe other packages using libv8-dev, for example).
> >
> > I'm not sure why node-iconv depends on nodejs.
>
> As my other bug, node-expat seems to have the same issue.
>
> > Its autopkgtests should however depend on nodejs >=
> > where is the one built against the same libnode SONAME as
> > node-iconv (?)
>
> That doesn't scale, because it's every package that has an autopkgtest
> that depends on node-iconv that has this issue. So it's node-iconv that
> needs to declare the right versioned relation to nodejs. It looks like
> the binary executable already knows it, but the Debian package doesn't
> know it yet. The internal knowledge needs to be exposed somehow.
>
Since all packages that Build-Depend: libnode-dev are concerned,
maybe the solution is to declare:
libnode-dev
Depends: nodejs (= ${binary:Version})
- downside: packages depending on libv8-dev will install nodejs (this
shouldn't be a problem).
- a multi-arch issue ?
?
Bug#948706: Polite ping
Is there a recommended alternative way to implement greylisting with exim? On Wed, 3 Jun 2020 at 14:18, Eugene Berdnikov wrote: > > Hi. > > On Wed, Jun 03, 2020 at 02:01:33PM +0200, Benedikt Spranger wrote: > > Hi, > > > > are there any updates or is more help needed? > > Unfortunately, this package seems to be not maintained. > -- > Eugene Berdnikov > > -- > To unsubscribe, send mail to 948706-unsubscr...@bugs.debian.org.
Bug#963191: RFH: aufs
Hi Jan On Sat, Jun 20, 2020 at 12:14:17PM +0200, Jan Luca Naumann wrote: > At the moment aufs is nearly unmaintained since I do not have time due to > personal issues. Therefore, I would be happy if there is somebody to > co-maintain the package. Since the kernel supports overlayfs since some time now, what blocks it's removal? Bastian -- You! What PLANET is this! -- McCoy, "The City on the Edge of Forever", stardate 3134.0
