Bug#982776: mpdtoys: mpfade does not work for a stopped MPD server with PulseAudio output
Hi, On Sun, 14 Feb 2021 05:21:46 -0500 Asher Gordon wrote: > Package: mpdtoys > Version: 0.25.0 > Severity: normal > Tags: patch > X-Debbugs-Cc: Asher Gordon > > Dear Maintainer, > > I have configured my MPD daemon to output through PulseAudio (the PA > server is running as my local user). After doing so, when the daemon is > stopped (no song playing or paused), the volume displays as 'n/a' in > 'mpc status' and is returned as undef by the 'volume' method of the > Audio::MPD::Common::Status class in the Audio::MPD Perl library. I'm not > sure why this is--possibly due to a limitation in the PulseAudio > interface--but it breaks mpfade when the MPD daemon is stopped. mpfade > thinks the volume was changed manually, even though it wasn't, and thus > exits erroneously. > > Here is the exact message: > > $ mpfade 0.5 100 > fading up from 0 to 100 over 30 seconds > manual volume change, aborting fade up > > I've written a patch to fix this problem. Unfortunately, it's a bit of a > hack, but it should work. I took the liberty of adding a > debian/changelog entry in my name, but of course, feel free to put my > name in brackets and change the name at the bottom. The patch is as > follows: Please contact the mpdtoys upstream author directly. Since mpdtoys package is not being actively monitored in Debian, forwarding your patch to upstream will gain more possibility in having your fix merged. Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#1075988: intlfonts: Please package new version 1.4.2
Source: intlfonts Version: 1.2.1-10.1 Severity: normal A new upstream release of intlfonts is now available at https://ftp.gnu.org/gnu/intlfonts/intlfonts-1.4.2.tar.gz . Please consider packaging it in Debian. Thanks, Boyuan Yang
Bug#1076401: RM: cvs-buildpackage -- RoQA; Orphaned; Unmaintained; Useless
Package: ftp.debian.org Control: affects -1 + src:cvs-buildpackage X-Debbugs-Cc: cvs-buildpack...@packages.debian.org devscri...@packages.debian.org User: ftp.debian@packages.debian.org Usertags: remove Severity: normal Dear Debian FTP Masters, I believe it is now the time to drop package cvs-buildpackage from Debian development archive. * This package was orphaned back in 2008. * No meaningful source code changes have taken place after 2008. * The CVS VCS packaging workflow is long gone, and no Debian packages in Sid uses it. [1] * There are no reverse dependencies or reverse build-dependencies. Package devscript has a suggestion on it but it is harmless (package maintainers CC-ed). Thanks, Boyuan Yang [1] https://trends.debian.net/vcs-hosting_unstable-packages.csv signature.asc Description: This is a digitally signed message part
Bug#1008610: gthumb-dev: gthumb-3.11.pc refers to non-existant header folder /usr/include/gthumb-3.11
Control: fixed 1008610 3:3.12.2-1 This bug is fixed in Debian Testing and Unstable. Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#755494: libmpd: diff for NMU version 11.8.90+git20130319-0.1
X-Debbugs-CC: m...@emillon.org Hi Etienne, On Mon, 21 Jul 2014 13:16:23 +0200 Etienne Millon wrote: > Package: libmpd > Version: 0.20.0-1.1 > Severity: normal > Tags: patch pending > > Dear maintainer, > > I've prepared an NMU for libmpd (versioned as > 11.8.90+git20130319-0.1). As you are in the low threshold NMU list, > I'm looking to upload it without delay. Sorry for the large diff, this > is a new upstream version (reason is explained in #749055). > > A source package can be found here while I am contacting sponsors: > > http://mentors.debian.net/debian/pool/main/libm/libmpd/libmpd_11.8.90+git20130319-0.1.dsc > > It also seems that you are MIA; if that is confirmed I can adopt the > package and freshen the packaging: hardening, watch file, S-V, remove > quilt, etc. I checked upstream homepage and could not find any link to the git development repo. Instead, I could only find a released tarball of v11.8.17, but it seems still earlier than the v11.8.90 you provided. Do you have any idea about where I could find the upstream git repo that matches the snapshot you provided? Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#1031836: nvi: refuses to start with read-only rootfs (/var/tmp)
Control: severity 1031836 wishlist Hi, 在 2023-02-23星期四的 23:31 +0100，наб写道： > Package: nvi > Version: 1.81.6-16 > Severity: normal > > Dear Maintainer, > > -- >8 -- > # vi /etc/snmp/snmpd.conf > ex/vi: Error: /var/tmp/vi.recover: Read-only file system > ex/vi: Modifications not recoverable if the session fails > ex/vi: Error: /var/tmp/vi.recover/vi.pL7kw0: No such file or directory > -- >8 -- > > This is fatal. /No one/ can edit /anything/, it seems, > until /var/tmp is made writable (be it by remounting / rw, > or, indeed mounting tmpfs on /var/tmp). > > This should be a non-fatal warning. According to FHS and Linux common practice [1][2], /var/tmp/ should be world-writable in a sane environment. Supporting a non-standard environment should be in wishlist. You are welcome to provide a patch to Debian or forward the patch to upstream. Please note that the upstream of nvi may not be active now [3], but giving it a try is always harmless. Thanks, Boyuan Yang [1] https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch05s15.html [2] https://www.redhat.com/en/blog/polyinstantiating-tmp-and-vartmp-directories [3] likely to be https://repo.or.cz/nvi.git signature.asc Description: This is a digitally signed message part
Bug#755494: libmpd: diff for NMU version 11.8.90+git20130319-0.1
X-Debbugs-CC: m...@emillon.org Hi Etienne, On Tue, 31 Jan 2023 15:04:29 -0500 Boyuan Yang wrote: > X-Debbugs-CC: m...@emillon.org > > Hi Etienne, > > On Mon, 21 Jul 2014 13:16:23 +0200 Etienne Millon wrote: > > Package: libmpd > > Version: 0.20.0-1.1 > > Severity: normal > > Tags: patch pending > > > > Dear maintainer, > > > > I've prepared an NMU for libmpd (versioned as > > 11.8.90+git20130319-0.1). As you are in the low threshold NMU list, > > I'm looking to upload it without delay. Sorry for the large diff, this > > is a new upstream version (reason is explained in #749055). > > > > A source package can be found here while I am contacting sponsors: > > > > > http://mentors.debian.net/debian/pool/main/libm/libmpd/libmpd_11.8.90+git20130319-0.1.dsc > > > > It also seems that you are MIA; if that is confirmed I can adopt the > > package and freshen the packaging: hardening, watch file, S-V, remove > > quilt, etc. > > I checked upstream homepage and could not find any link to the git > development repo. Instead, I could only find a released tarball of v11.8.17, > but it seems still earlier than the v11.8.90 you provided. Do you have any > idea about where I could find the upstream git repo that matches the > snapshot you provided? Just to let you know, Debian now has libmpd 11.8.17 packaged. You may find its details at https://tracker.debian.org/pkg/libmpd . If any newer version is needed, please let me know. Best, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#1033020: a2ps: v4.15+ shall switch to upstream-provided a2ps-lpr-wrapper
Package: a2ps Severity: normal Version: 1:4.15.1-1~exp1 Upstream of a2ps is now providing a sane a2ps-lpr-wrapper, see https://lists.gnu.org/archive/html/bug-a2ps/2023-03/msg3.html . The new packaging shall use this wrapper instead of the one provided in debian/ directory. Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#1050672: granite-7: FTBFS: error: Argument 1: Cannot convert from `unowned uint8[]' to `unowned string'
has been deprecated since 4.10 > > 95 | label.get_style_context ().add_class > > (Granite.STYLE_CLASS_H4_LABEL); > > | ^~~ > > > > ../lib/Widgets/SwitchModelButton.vala:53.49-53.83: warning: > > `Gtk.Widget.get_style_context' has been deprecated since 4.10 > > 53 | unowned var description_style_context = > > description_label.get_style_context (); > > | > > ^~~ > > ../lib/Widgets/SwitchModelButton.vala:53.21-53.45: warning: > > `Gtk.StyleContext' has been deprecated since 4.10 > > 53 | unowned var description_style_context = > > description_label.get_style_context (); > > | ^ > > > > ../lib/Widgets/Utils.vala:269.38-269.45: error: Argument 1: Cannot convert > > from `unowned uint8[]' to `unowned string' > > 269 | css_provider.load_from_data (css.data); > > | ^~~~ > > ../lib/Widgets/Utils.vala:269.9-269.46: error: 1 missing arguments for > > `void Gtk.CssProvider.load_from_data (string, ssize_t)' > > 269 | css_provider.load_from_data (css.data); > > | ^~ > > ../lib/Widgets/Utils.vala:272.9-272.24: warning: `Gtk.StyleContext' has > > been deprecated since 4.10 > > 272 | Gtk.StyleContext.add_provider_for_display > > (Gdk.Display.get_default (), css_provider, priority); > > | ^~~~ > > > > ../lib/Widgets/ValidatedEntry.vala:65.54-65.70: warning: > > `Gtk.Widget.get_style_context' has been deprecated since 4.10 > > 65 | unowned Gtk.StyleContext style_context = > > get_style_context (); > > | > > ^ > > ../lib/Widgets/ValidatedEntry.vala:65.38-65.50: warning: `Gtk.StyleContext' > > has been deprecated since 4.10 > > 65 | unowned Gtk.StyleContext style_context = > > get_style_context (); > > | ^ > > > > Compilation failed: 2 error(s), 13 warning(s) > > ninja: build stopped: subcommand failed. > > dh_auto_build: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 ninja -j12 > > -v returned exit code 1 > > make: *** [debian/rules:12: binary-arch] Error 25 > > dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit > > status 2 > > A full build log on riscv64 is also available: > https://buildd.debian.org/status/package.php?p=granite-7&suite=sid The behavior of Gtk.CssProvider.load_from_data changed unexpectedly in Vala 0.56.11. This change will be reverted in Vala 0.56.13. To solve the FTBFS bug of src:granite-7, a backported patch on current Vala 0.56.12-1 is needed, or a rebuild is needed after Vala 0.56.13 is packaged. Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#1051865: override: python3-fswrap:python/optional
Package: ftp.debian.org Control: affects -1 + src:python-fswrap X-Debbugs-Cc: python-fsw...@packages.debian.org User: ftp.debian@packages.debian.org Usertags: override Severity: normal Dear Debian FTP Masters, Currently, binary package python3-fswrap is of Priority: extra. == -> % apt-cache show python3-fswrap Package: python3-fswrap Source: python-fswrap Version: 1.0.1-3 Installed-Size: 40 Maintainer: Debian QA Group Architecture: all Depends: python3:any, python3-distutils Description-en: unified object oriented interface to file system objects (Python 3) File system operations in Python are distributed across modules: os, os.path, fnmatch, shutil and distutils. This module attempts to make the right choices for common operations to provide a single interface. . This package is for Python 3. Description-md5: 0c8e04b86160f0dcf956bcc6e269c9ae Homepage: https://github.com/hyde/fswrap Section: python Priority: extra Filename: pool/main/p/python-fswrap/python3-fswrap_1.0.1-3_all.deb Size: 8636 MD5sum: 8ccc2076919b8c091a211283568f3c2b SHA256: 9b2f19e80ae1af9641ea56072f8a9cbfa6dad6d6b6dffd5620ee6b2770d8d225 As in https://www.debian.org/doc/debian-policy/ch-archive.html#priorities , Priority: extra is now deprecated. Such priority is also not explicitly specified in its debian/control file. As a result, please revert such deprecated priority back to python/optional. Since this package is orphaned, I believe no confirmation from the package maintainer will be needed. Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#532755: gthumb: import dialog box should not close after importing photos
Control: close -1 On Thu, 11 Jun 2009 11:44:53 +0100 Julian Gilbey wrote: > Package: gthumb > Version: 3:2.10.11-1 > Severity: wishlist > > I imported 2 photos from a camera, and wanted to import further ones > from the same camera. Unfortunately, after clicking "Import" and > importing the first two, the dialog box then closed and I had to > reopen it - including reading all the photographs off the camera from > scratch - in order to import the next photos. It would be much better > if there was a "Done" button or the like offered after importing > photos, allowing for the possibility of importing more than one batch. According to upstream comment at http://bugzilla.gnome.org/show_bug.cgi?id=585450 , upstream is clear that this feature will not be implemented. Debian alone is unable to accommodate the feature request. Closing this bug report accordingly. If you have further feature requests, please contact gthumb upstream directly at https://gitlab.gnome.org/GNOME/gthumb/-/issues . Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#607646: gthumb: weird German localization string
Control: tags -1 +wontfix Control: close -1 Hi, On Mon, 20 Dec 2010 17:04:41 +0100 Amselmann wrote: > Package: gthumb > Version: 3:2.11.5-4 > Severity: minor > Tags: l10n > > Currently the string "Delete the imported files from the source" is not very > well translated into German. Now it is "Aus dieser Quell importierte Bilder > dort löschen" but it should better be something like "Lösche die importierten > Bilder vom Quellmedium". Please check the current translation at https://gitlab.gnome.org/GNOME/gthumb/-/blob/master/po/de.po . From current point of view, the translation has already been updated. If you have any comments, please contact GThumb upstream at https://gitlab.gnome.org/GNOME/gthumb/-/issues . Since this bug report is no longer applicable, I am closing this bug report. Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#1000006: parser: depends on obsolete pcre3 library
X-Debbugs-CC: ya...@gnu.org
On Thu, 18 Nov 2021 11:49:06 + Matthew Vernon wrote:
> Source: parser
> Severity: important
> User: matthew-pcre...@debian.org
> Usertags: obsolete-pcre3
>
> Dear maintainer,
>
> Your package still depends on the old, obsolete PCRE3[0] libraries
> (i.e. libpcre3-dev). This has been end of life for a while now, and
> upstream do not intend to fix any further bugs in it. Accordingly, I
> would like to remove the pcre3 libraries from Debian, preferably in
> time for the release of Bookworm.
>
> The newer PCRE2 library was first released in 2015, and has been in
> Debian since stretch. Upstream's documentation for PCRE2 is available
> here: https://pcre.org/current/doc/html/
>
> Many large projects that use PCRE have made the switch now (e.g. git,
> php); it does involve some work, but we are now at the stage where
> PCRE3 should not be used, particularly if it might ever be exposed to
> untrusted input.
>
> This mass bug filing was discussed on debian-devel@ in
> https://lists.debian.org/debian-devel/2021/11/msg00176.html
>
> Regards,
>
> Matthew [0] Historical reasons mean that old PCRE is packaged as
> pcre3 in Debian
I am aware of the work at https://bugs.debian.org/1057281 , but
unfortunately I am unable to review the patch at the moment. In order
to prevent the loss of the proposed patch, I am including it as an email
attachment here.
Thanks,
Boyuan Yang
Description: Port to PCRE2.
Bug-Debian: https://bugs.debian.org/106
Author: Yavor Doganov
Forwarded: mailto:mail...@parser.ru
Last-Update: 2023-11-29
---
--- parser-3.4.6.orig/configure.ac
+++ parser-3.4.6/configure.ac
@@ -184,20 +184,20 @@
PCRE_INCLUDES="-I$PCRE/include"
PCRE_LIBS="$PCRE/lib/libpcre.la"
- if test -f $PCRE/include/pcre.h -a -f $PCRE_LIBS; then
+ if test -f $PCRE/include/pcre2.h -a -f $PCRE_LIBS; then
PCRE_OK="yes"
else
- PCRE_LIBS="-L$PCRE/lib -lpcre"
+ PCRE_LIBS="-L$PCRE/lib -lpcre2-8"
fi
if test "$PCRE" = "yes"; then
PCRE=""
- PCRE_LIBS="-lpcre"
+ PCRE_LIBS="-lpcre2-8"
PCRE_INCLUDES=""
AC_MSG_WARN([--with-pcre value was not specified, hoping linker would find it])
fi
],[
- PCRE_LIBS="-lpcre"
+ PCRE_LIBS="-lpcre2-8"
PCRE_INCLUDES=""
AC_MSG_WARN([--with-pcre was not specified, hoping linker would find it])
])
@@ -206,16 +206,21 @@
AC_MSG_CHECKING(for prce)
SAVE_LIBS=$LIBS
LIBS="$LIBS $PCRE_LIBS $PCRE_INCLUDES"
- AC_TRY_LINK([ #include ],[ const char *v=pcre_version(); ],
- AC_MSG_RESULT(yes)
+ AC_LINK_IFELSE(
+ [AC_LANG_PROGRAM([[#define PCRE2_CODE_UNIT_WIDTH 8
+ #include ]],
+ [[uint32_t ov=16;
+ pcre2_match_data *md;
+ md=pcre2_match_data_create(ov, NULL);]])],
+ [AC_MSG_RESULT([yes])]
,
- AC_MSG_RESULT(no)
+ [AC_MSG_RESULT([no])
if test -z "$PCRE"; then
AC_MSG_ERROR(please specify path to PCRE: --with-pcre=DIR)
else
AC_MSG_ERROR($PCRE does not seem to be valid PCRE installation directory)
fi
- )
+ ])
LIBS=$SAVE_LIBS
fi
--- parser-3.4.6.orig/src/include/pa_charset.h
+++ parser-3.4.6/src/include/pa_charset.h
@@ -16,7 +16,8 @@
#include "pa_hash.h"
#include "pa_array.h"
-#include "pcre.h"
+#define PCRE2_CODE_UNIT_WIDTH 8
+#include
// we are using some pcre_internal.h stuff as well
#include "../lib/pcre/pa_pcre_internal.h"
--- parser-3.4.6.orig/src/lib/pcre/pa_pcre_valid_utf8.c
+++ parser-3.4.6/src/lib/pcre/pa_pcre_valid_utf8.c
@@ -6,7 +6,8 @@
and semantics are as close as possible to those of the Perl 5 language.
Written by Philip Hazel
- Copyright (c) 1997-2012 University of Cambridge
+ Original API code Copyright (c) 1997-2012 University of Cambridge
+ New API code Copyright (c) 2016-2020 University of Cambridge
-
Redistribution and use in source and binary forms, with or without
@@ -38,112 +39,134 @@
*/
-/* This module contains an internal function for validating UTF-8 character
-strings. */
-
-#include "pcre.h"
+/* This module contains an internal function for validating UTF character
+strings. This file is also #included by the pcre2test program, which uses
+macros to change names from _pcre2_xxx to , thereby avoiding name clashes
+with the library. In this case, PCRE2_PCRE2TEST is defined. */
+
+#define SUPPORT_UNICODE
+#define PCRE2_CODE_UNIT_WIDTH 8
+#include
#include "pa_pcre_internal.h"
+static const uint8_t utf8_table4[] = {
+ 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
+ 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
+ 2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,
+ 3,3,3,3,3,3,3,3,4,4,4,4,5,5,5,5 };
+
Bug#861365: xmlto: Please do not suggest transitional dummy pkg xmltex
Package: xmlto Version: 0.0.28-1 Severity: wishlist Hello all, The package xmlto suggests the following transitional dummy package(s): * xmltex, which is provided by texlive-htmlxml now Please update the suggestion list and suggest real packages in next QA/adopted upload. Thanks! -- System Information: Debian Release: 9.0 APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages xmlto depends on: ii debianutils4.8.1 ii docbook-xml4.5-8 ii docbook-xsl1.79.1+dfsg-2 ii libc6 2.24-10 ii libxml2-utils 2.9.4+dfsg1-2.2 ii sgml-base 1.29 ii xsltproc 1.1.29-2.1 Versions of packages xmlto recommends: ii dblatex 0.3.9-1 ii fop 1:2.1-5 ii libpaper-utils 1.1.24+nmu5 ii zip 3.0-11+b1 Versions of packages xmlto suggests: ii texlive-htmlxml [xmltex] 2016.20170123-5 ii w3m 0.5.3-34 -- no debconf information
Bug#861370: xmlto: Please update d/watch to avoid fedorahosted.org
Package: xmlto Version: 0.0.28-1 Severity: minor Fedorahosted.org has shut down. New upstream tarball list page: https://releases.pagure.org/xmlto/ Please update d/watch file accordingly. -- System Information: Debian Release: 9.0 APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages xmlto depends on: ii debianutils4.8.1 ii docbook-xml4.5-8 ii docbook-xsl1.79.1+dfsg-2 ii libc6 2.24-10 ii libxml2-utils 2.9.4+dfsg1-2.2 ii sgml-base 1.29 ii xsltproc 1.1.29-2.1 Versions of packages xmlto recommends: ii dblatex 0.3.9-1 ii fop 1:2.1-5 ii libpaper-utils 1.1.24+nmu5 ii zip 3.0-11+b1 Versions of packages xmlto suggests: ii texlive-htmlxml [xmltex] 2016.20170123-5 ii w3m 0.5.3-34 -- no debconf information
Bug#859554: pidgin-openfetion: Please migrate to openssl1.1 in buster
X-Debbugs-CC: a...@debian.org sebast...@breakpoint.cc 在 2017年10月12日星期四 CST 下午11:44:37，Sebastian Andrzej Siewior 写道： > Hi, > > this is a remainder about the openssl transition [0]. We really want to > remove libssl1.0-dev from unstable for Buster. I will raise the severity > of this bug to serious in a month. Please react before that happens. > > [0] https://bugs.debian.org/871056#55 > > Sebastian Pidgin-openfetion was hosted on code.google.com, which was obsoleted long ago without upstream activity. Pidgin-openfetion package in Debian is also orphaned. For QA purpose, I suggest we remove this package from Debian Archive. If there's no other doubt, I will file RM request after this bug becomes RC. CC-ing original upstream author, original package maintainer in Debian and Debian Chinese Team. Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part.
Bug#943472: launchy: Rename icons cache folder to .weby-icon-cache or similar
Hi Pavel, Just FYI, The package launchy has been removed from Debian Testing/Sid due to the lack of maintenance and the inactivity of upstream. As a result, this bug is unlikely to be solved unless someone steps in and reintroduce launchy into Debian. The current old version in Debian stable will be left untouched. Best, Boyuan Yang 在 2019-10-25五的 11:01 +0200，Pavel Reznicek写道： > Package: launchy > Version: 2.5-4 > Severity: wishlist > > Dear Maintainer, > > would it be possible to patch the package so that the application is > storing its icons cache into a hidden directory, instead of ~/weby-icon- > cache ? It is a bit distracting when such an obviously temp direcotry is > always being recreated in my home dir. The patch should be trivial: just > change launchy-2.5/plugins/weby/weby.cpp at line 95, e.g. to ~/.weby-icon- > cache. > > Thank you, > Pavel > > > -- System Information: > Debian Release: bullseye/sid > APT prefers testing > APT policy: (840, 'testing'), (740, 'unstable'), (738, 'experimental'), > (540, 'proposed-updates'), (540, 'stable'), (500, 'oldstable-proposed- > updates'), (500, 'oldoldstable'), (500, 'oldstable') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 5.2.0-3-amd64 (SMP w/8 CPU cores) > Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE > Locale: LANG=en_US.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8) (ignored: > LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: > LC_ALL set to en_US.UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages launchy depends on: > ii libc6 2.29-2 > ii libgcc1 1:9.2.1-8 > ii libqt4-network 4:4.8.7+dfsg-19 > ii libqtcore4 4:4.8.7+dfsg-19 > ii libqtgui4 4:4.8.7+dfsg-19 > ii libstdc++6 9.2.1-8 > ii libx11-62:1.6.8-1 > > launchy recommends no packages. > > Versions of packages launchy suggests: > ii launchy-plugins 2.5-4 > ii launchy-skins2.5-4 > > -- no debconf information > signature.asc Description: This is a digitally signed message part
Bug#915602: Please upgrade to a newer snapshot/version
X-Debbugs-CC: jo...@jones.dk bi...@debian.org mckins...@debian.org
Hi all,
A new snapshot of gnulib is currently in Experimental. I have rebuilt all
reverse dependencies and so far only libtool would FTBFS. Actually sollya is
also failing to build but that was due to a separate issue (
https://bugs.debian.org/947720).
I only enabled a very small portion of testsuites in the new upload. The full
test ("megatest" for all) would take really long time (several hours on my
workstation) and eventually fail. We need more work to get the package into
better shape.
Thanks,
Boyuan Yang
On Thu, 10 Oct 2019 11:01:41 -0400 Boyuan Yang wrote:
> X-Debbugs-CC: jo...@jones.dk bi...@debian.org
>
> I have played around and prepared a new packaging release in the
experimental
> branch based on the codebase on Oct 2019:
> https://salsa.debian.org/debian/gnulib/tree/experimental
>
> The issue is that newer gnulib requires newer gettext (>= 0.20) to work,
which
> is not yet available in Debian. Though it's possible to patch the source
code
> and loosen the version requirement, I haven't really test what will happen.
>
> Best,
> Boyuan Yang
>
> On Fri, 07 Dec 2018 17:41:30 +0100 Jonas Smedegaard wrote:
> > Control: tag -1 help
> >
> > Hi Laurent,
> >
> > Quoting Laurent Bigonville (2018-12-05 09:29:03)
> > > Current version is quite old (2014) and some other packages seems to
> > > require a newer version (see enchant bug #861141)
> > >
> > > Would it be possible to upgrade to a newer version?
> >
> > Yes, gnulib is too old for recent enchant - in fact that is the very
> > reason I wanted to pour some love on gnulib.
> >
> > Unfortunately gnulib packaging is in a bad shape: It comes with a
> > testsuite but that is skipped - I am quite worried that a major upgrade
> > may introduce new bugs, and therefore want to first get the testsuite
> > enabled, learn which parts of the testsuite succeeds for the old 2014
> > release, and only then upgrade to have a reasonable judgement if the
> > upgrade is sane to introduce to Debian unstable.
signature.asc
Description: This is a digitally signed message part
Bug#943994: python3-zeitgeist not compatible with python3
X-Debbugs-CC: bi...@debian.org Hi Laurent, On Sat, 2 Nov 2019 10:40:39 +0100 Laurent Bigonville wrote: > On Sat, 02 Nov 2019 10:31:36 +0100 Laurent Bigonville > wrote: > [...] > > > > Looks like it's not compatible with python3. > > > > Looking at the debian changelog, I personally removed that package back > in March 2018 because it was not compatible, not sure why it was > reintroduced: > > zeitgeist (1.0.1-0.2) unstable; urgency=medium > >* Non-maintainer upload. >* Drop python3-zeitgeist package as the binding is not compatible with > python3, for python3, GIR binding should be used instead. Reintroduce the > python2 binding for now as we still have one rdependency (Closes: #891615) >* Avoid installing files in /usr/lib/zeitgeist/zeitgeist/, move them one > level up to /usr/lib/zeitgeist/ instead >* Do not make the metapackge pull python-zeitgeist, this is not needed for > normal operations > > -- Laurent Bigonville Sun, 11 Mar 2018 19:54:01 +0100 > > An idea? No idea why. Looks like we need to have python3-zeitgeist removed eventually. However before that, I'm going for a workaround: Upload an experimental version with higher version string, e.g., 1.0.2+py3-0. After that, upload 1.0.2-3 onto Sid with python3-zeitgeist removed. This would keep binary package python3-zeitgeist in development repositories so that we do not need to go through NEW queue for another time if we really need that in the future. -- Regards, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#962020: docbook-xsl: Please package new upstream release (1.79.2)
Source: docbook-xsl Version: 1.79.1+dfsg-2 Severity: important Dear Debian docbook-xsl maintainer, The docbook-xsl project is now hosted on GitHub with new release 1.79.2: * https://github.com/docbook/xslt10-stylesheets This also solves the problem of providing split source (ns and nons). Please consider packaging it. -- Regards, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#962924: meanwhile: Please switch to new upstream (on GitHub)
Source: meanwhile Version: 1.0.2-9 Severity: important Tags: sid bullseye The new upstream is at https://github.com/obriencj/meanwhile with some new releases. -- Regards, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#859554: RM: pidgin-openfetion -- RoQA; Service provider stopped; RC-buggy; Upstream dead; Orphaned
Package: ftp.debian.org Severity: normal X-Debbugs-CC: chinese-develop...@lists.alioth.debian.org levin...@gmail.com Hello all, I believe it's time to remove package pidgin-openfetion from Debian archive. Reasons: * Upstream dead for more than 5 years; * Popcon declining; * Package orphaned already; * RC-buggy (openssl 1.1 migration; see also Bug#859554) * As a plugin library to provide IM integration into pidgin, its service provider, China Mobile, has stopped the old fetion service and heads to a new one focusing on enterprise use with different web API. This effectively made the library useless. CC-ing chinese-developers list (original package maintainer on-list) and original library author. Regards, Boyuan Yang signature.asc Description: This is a digitally signed message part.
Bug#892886: launchy: Please switch upstream and package the new version
Source: launchy Version: 2.5-4 Severity: normal This is a placeholder report to remind the newcomers that original launchy upstream has dead. There is a new upstream (fork project) available on GitHub: https://github.com/OpenNingia/Launchy Anyone interested in launchy in Debian should switch the upstream and try to package the new version. -- Regards, Boyuan Yang -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'buildd-unstable'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#903049: awffull: Please do not suggest transitional dummy pkg ttf-dejavu
Package: awffull Severity: minor Version: 3.10.2-5 User: 073p...@gmail.com Usertags: fonts-transitional-dummy-pkg-migration Dear maintainer, Your package awffull depends on the following transitional dummy packages: * ttf-dejavu, which should be fonts-dejavu now Please update your dependency list and depend on real package in the next upload. Thanks! -- Regards, Boyuan Yang
Bug#771630: anacron: Please add ProtectSystem=yes to systemd service file
Control: tag -1 + wontfix I guess we cannot do that for the same reason as Bug #771629. -- Thanks, Boyuan Yang On Sun, 30 Nov 2014 22:51:28 -0500 Micah Anderson wrote: > Package: anacron > Version: 2.3-22 > Severity: wishlist > > Dear Maintainer, > > *** Reporter, please consider answering these questions, where appropriate *** > >* What led up to the situation? >* What exactly did you do (or not do) that was effective (or > ineffective)? >* What was the outcome of this action? >* What outcome did you expect instead? > > *** End of the template - remove these template lines *** > > > Hello, > > If you add the option ProtectSystem=yes to the service file, then the > daemon will not have the ability to write to /usr. > > There is no reason why it needs to write there, so enabling this > option should not cause any problems. > > This option is one of the systemd security features for systemd > service files that was detailed in a talk[0] given by Lennart which > details various security features you can enable in your package's > service files. > > micah > > [0] http://ftp.nluug.nl/video/nluug/2014-11-20_nj14/zaal-2/5_Lennart_Poettering_-_Systemd.webm > > -- System Information: > Debian Release: jessie/sid > APT prefers unstable > APT policy: (500, 'unstable') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) > Locale: LANG=en_US.utf8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > > Versions of packages anacron depends on: > ii debianutils 4.4+b1 > ii init-system-helpers 1.22 > ii libc62.19-13 > ii lsb-base 4.1+Debian13+nmu1 > > Versions of packages anacron recommends: > ii cron [cron-daemon] 3.0pl1-127 > ii rsyslog [system-log-daemon] 8.4.2-1 > > Versions of packages anacron suggests: > ii postfix [mail-transport-agent] 2.11.3-1 > ii powermgmt-base 1.31+nmu1 > > -- no debconf information signature.asc Description: This is a digitally signed message part
Bug#864213: fixed in anacron 2.3-26
Hi Michael, (see below...) Michael Biebl 于2018年11月12日周一 上午7:44写道： > > > Hi > > On Mon, 12 Nov 2018 00:18:54 +0000 Boyuan Yang wrote: > > > anacron (2.3-26) unstable; urgency=medium > > . > >* QA upload. > >* debian/60-anacron.rules: > > + Add new udev rule to trigger anacron when external power supply > >is online. (Closes: #864213). > > Please don't do that, i.e. starting potentially long running tasks from > a udev rules file. > This is explicitly documented as not supported: > https://manpages.debian.org/unstable/udev/udev.7.en.html > > == > This can only be used for very short-running foreground tasks. Running > an event process for a long period of time may block all further events > for this or a dependent device. > Starting daemons or other long-running processes is not appropriate for > udev; the forked processes, detached or not, will be unconditionally > killed after the event handling has finished. > == > > As we nowadays trigger cron hourly, I would guess the original issue is > no longer valid anyways, as the chance that cron is executed is now much > higher. > > Please consider dropping the udev rule again. Current implementation is to call invoke-rc.d, which is non-blocking and will return immediately. Thus I believe we should not drop it. Hourly trigger via cron is really not enough since cron job for anacron still won't run when AC power supply is not present. I will look into other suggestions later. Thanks, Boyuan Yang
Bug#743448: fixed in anacron 2.3-25
Hi Michael, (see below..) Michael Biebl 于2018年11月12日周一 上午7:51写道： > > On Sun, 11 Nov 2018 18:19:56 + Boyuan Yang wrote: > > + Add /etc/default/anacron file as EnvironmentFile. > > As systemd maintainer, I have to say, that I don't particularly like > this change. EnvironmentFile is a bit of a kludge, the documented and > preferred mechanism is to use a drop-in config snippet. > You'll need that anyway, since the ConditionACPower can not be > overridden this way. > > I would prefer a simple note in /etc/default/anacron instead, which says > that this file is only read by the sysv init script and for systemd you > should use a drop-in config instead. The key is that I added ANACRON_ARGS to the environment file besides ConditionACPower so that users may add custom arguments. For example, -s for serialisation. In such circumstance the EnvironmentFile is needed anyway. I already added related notes in both /etc/default/anacron and systemd service file about sysvinit and drop-in config in anacron 2.3-25. -- Thank, Boyuan Yang
Bug#930693: ksh: previous versions have the info
Control: severity -1 important Control: fixed -1 2020.0.0~alpha1-1~exp1 在 2019-06-18二的 17:30 -0400，Greg Wooledge写道： > Having ksh removed from buster is definitely not my preferred outcome. > Getting one line added to the copyright file would be ideal, but if > that's not allowed, then I can live with "fixed after buster". Doing so accordingly. Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Upload of zbar 0.23-1 is breaking rev-dependencies
Hello all, Recent upload of zbar 0.23-1 [1] has broken some reverse dependencies that is using python-zbar and python-zbarpygtk: % LANG=C apt rdepends python-zbar python-zbar Reverse Depends: Depends: python-zbar-dbgsym (= 0.22-1) Suggests: gnunet Suggests: gnunet Depends: sdaps Depends: python-qrtools Recommends: monkeysign % LANG=C apt rdepends python-zbarpygtk python-zbarpygtk Reverse Depends: Breaks: python-zbar (<< 0.10+doc) Depends: python-zbarpygtk-dbgsym (= 0.22-1) Replaces: python3-zbar (<< 0.10+doc) Breaks: python3-zbar (<< 0.10+doc) Replaces: python-zbar (<< 0.10+doc) Recommends: monkeysign % LANG=C apt rdepends python-qrtools python-qrtools Reverse Depends: Depends: qtqr Please be aware of this issue and migrate your packages away from python-zbar (as well as python2) if possible. Thanks, Boyuan Yang [1] https://tracker.debian.org/news/1047357/accepted-zbar-023-1-source-amd64-into-unstable-unstable/ signature.asc Description: This is a digitally signed message part
Bug#932865: python-qrtools: not installable: depends on python2 version of zbar
Control: tags -1 + fixed-upstream X-Debbugs-CC: paul...@debian.org Upstream has merged python3 migration code. We should consider packaging it. Thanks, Boyuan Yang On Fri, 13 Sep 2019 02:34:44 +0800 "Ying-Chun Liu (PaulLiu)" < paul...@debian.org> wrote: > Hi all, > > > Unfortunately, I'm still using this app. Or not me cause I can use > command line, > > but I must keep this app running otherwise I'll be in trouble. > > So I propose a merge request to the upstream that ports this app to python3. > > > https://code.launchpad.net/~paulliu/qr-tools/python3/+merge/372711 > > Will do NMU for a patch maintained inside Debian if the upstream is > really dead and don't want to accept or discuss my patch. > > If the upstream accepts my patch then we can upgrade to latest upstream. > > > Yours, > Paul signature.asc Description: This is a digitally signed message part
Bug#699288: Segmentation fault in "kill %string"
1000
getegid() = 1000
prlimit64(0, RLIMIT_STACK, NULL, {rlim_cur=8192*1024,
rlim_max=RLIM64_INFINITY}) = 0
prlimit64(0, RLIMIT_NPROC, NULL, {rlim_cur=63565, rlim_max=63565}) = 0
openat(AT_FDCWD, "/proc/sys/kernel/ngroups_max", O_RDONLY) = 3
read(3, "65536\n", 31) = 6
close(3)= 0
umask(000) = 022
umask(022) = 000
fcntl(0, F_GETFL) = 0x2 (flags O_RDWR)
stat("/dev/null", {st_mode=S_IFCHR|0666, st_rdev=makedev(0x1, 0x3), ...}) = 0
ioctl(0, TCGETS, {B38400 opost isig icanon echo ...}) = 0
lseek(0, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
fstat(0, {st_mode=S_IFCHR|0600, st_rdev=makedev(0x88, 0x1), ...}) = 0
fstat(0, {st_mode=S_IFCHR|0600, st_rdev=makedev(0x88, 0x1), ...}) = 0
stat("/dev/null", {st_mode=S_IFCHR|0666, st_rdev=makedev(0x1, 0x3), ...}) = 0
fstat(0, {st_mode=S_IFCHR|0600, st_rdev=makedev(0x88, 0x1), ...}) = 0
fcntl(1, F_GETFL) = 0x2 (flags O_RDWR)
ioctl(1, TCGETS, {B38400 opost isig icanon echo ...}) = 0
lseek(1, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
fstat(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(0x88, 0x1), ...}) = 0
fstat(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(0x88, 0x1), ...}) = 0
brk(NULL) = 0x560e5b333000
mmap(NULL, 98304, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f703458b000
rt_sigaction(SIGSEGV, {sa_handler=0x560e59af8020, sa_mask=[],
sa_flags=SA_RESTORER|SA_INTERRUPT, sa_restorer=0x7f70345df100},
{sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER|SA_INTERRUPT,
sa_restorer=0x7f70345df100}, 8) = 0
rt_sigaction(SIGSEGV, {sa_handler=SIG_DFL, sa_mask=[],
sa_flags=SA_RESTORER|SA_INTERRUPT, sa_restorer=0x7f70345df100},
{sa_handler=0x560e59af8020, sa_mask=[], sa_flags=SA_RESTORER|SA_INTERRUPT,
sa_restorer=0x7f70345df100}, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [SEGV], NULL, 8) = 0
mmap(NULL, 98304, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f7034573000
rt_sigaction(SIGSEGV, {sa_handler=0x560e59af8020, sa_mask=[],
sa_flags=SA_RESTORER|SA_INTERRUPT, sa_restorer=0x7f70345df100},
{sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER|SA_INTERRUPT,
sa_restorer=0x7f70345df100}, 8) = 0
rt_sigaction(SIGSEGV, {sa_handler=SIG_DFL, sa_mask=[],
sa_flags=SA_RESTORER|SA_INTERRUPT, sa_restorer=0x7f70345df100},
{sa_handler=0x560e59af8020, sa_mask=[], sa_flags=SA_RESTORER|SA_INTERRUPT,
sa_restorer=0x7f70345df100}, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [SEGV], NULL, 8) = 0
fstat(2, {st_mode=S_IFCHR|0600, st_rdev=makedev(0x88, 0x1), ...}) = 0
ioctl(2, TCGETS, {B38400 opost isig icanon echo ...}) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
readlink("/proc/self/exe", "/usr/bin/ksh93", 4097) = 14
brk(0x560e5b354000) = 0x560e5b354000
openat(AT_FDCWD, "/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=3246832, ...}) = 0
mmap(NULL, 3246832, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f703425a000
close(3)= 0
stat("/home/hosiet", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat(".", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
rt_sigaction(SIGCHLD, {sa_handler=0x560e59a453f0, sa_mask=[],
sa_flags=SA_RESTORER|SA_INTERRUPT, sa_restorer=0x7f70345df100},
{sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x10} ---
+++ killed by SIGSEGV +++
[1]6850 segmentation fault LANG=C strace ksh -c "kill %a"
Thanks,
Boyuan Yang
signature.asc
Description: This is a digitally signed message part
Bug#938884: python-zeitgeist (binary) removal blocked by gtk-doc
I'm not going to adopt zeitgeist anytime soon; please feel free to fix bugs in zeitgeist or push new versions via QA upload. Best, Boyuan Yang Simon McVittie 于2019年10月8日周二 上午4:41写道： > > On Sun, 22 Sep 2019 at 17:15:55 +0200, Andreas Henriksson wrote: > > Once the two applications using python-zeitgeist stops doing that, > > disabling the use of python2 use in zeitgeist build is still not > > super trivial. The reason is that zeitgeist needs python(3)-rdflib > > to generate the onthologies and the configure.ac uses the AM_PATH_PYTHON > > macro that will find python2 before python3. > > It should be possible to add PYTHON=/usr/bin/python3 > to the (dh_auto_)configure command-line (preferred), or > export it as an environment variable (as was done in 1.0.1-0.1, see > <https://salsa.debian.org/debian/zeitgeist/commit/597b81b56bf70b489b87a40487fc4488efdf3f62>; > this is less preferred than adding it to the configure command line). > This means the new version of gtk-doc isn't required. > > I see Boyuan Yang has imported zeitgeist into > <https://salsa.debian.org/debian/zeitgeist/> and started to update it > to version 1.0.2. Are you intending to adopt this package? (If not, > https://salsa.debian.org/debian/zeitgeist/ seems like a good place to > prepare QA uploads.) > > smcv
Bug#915602: Please upgrade to a newer snapshot/version
X-Debbugs-CC: jo...@jones.dk bi...@debian.org I have played around and prepared a new packaging release in the experimental branch based on the codebase on Oct 2019: https://salsa.debian.org/debian/gnulib/tree/experimental The issue is that newer gnulib requires newer gettext (>= 0.20) to work, which is not yet available in Debian. Though it's possible to patch the source code and loosen the version requirement, I haven't really test what will happen. Best, Boyuan Yang On Fri, 07 Dec 2018 17:41:30 +0100 Jonas Smedegaard wrote: > Control: tag -1 help > > Hi Laurent, > > Quoting Laurent Bigonville (2018-12-05 09:29:03) > > Current version is quite old (2014) and some other packages seems to > > require a newer version (see enchant bug #861141) > > > > Would it be possible to upgrade to a newer version? > > Yes, gnulib is too old for recent enchant - in fact that is the very > reason I wanted to pour some love on gnulib. > > Unfortunately gnulib packaging is in a bad shape: It comes with a > testsuite but that is skipped - I am quite worried that a major upgrade > may introduce new bugs, and therefore want to first get the testsuite > enabled, learn which parts of the testsuite succeeds for the old 2014 > release, and only then upgrade to have a reasonable judgement if the > upgrade is sane to introduce to Debian unstable. > > > - Jonas > > -- > * Jonas Smedegaard - idealist & Internet-arkitekt > * Tlf.: +45 40843136 Website: http://dr.jones.dk/ > > [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: This is a digitally signed message part
Bug#966366: json-c: Please package new release (0.15)
Source: json-c Version: 0.14+dfsg-1 Tags: sid Severity: normal X-Debbugs-CC: babelou...@debian.org Dear new Debian json-c maintainer, It seems that the json-c upstream has just released v0.15: https://github.com/json-c/json-c/releases Please consider packaging this new release. I know that it sounds subtle to request upgrading to a new version just when the v0.14 enters unstable, but I am really looking forward to keep up with the pace of upstream. Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#806861: libidl: upgrade libidl-2-0_0.8.14-3_amd64.deb and "Errors were encountered while processing"
Version: 0.8.14-4 Control: found -1 0.8.14-3 Control: fixed -1 0.8.14-4 This bug is fixed in the latest upload. See also #806204, #806253. Thanks, Boyuan Yang On Wed, 02 Dec 2015 15:03:51 +0330 Mohsen Pahlevanzadeh wrote: > Package: libidl > Severity: important > > Dear Maintainer, > > When I dist-upgrade my distro, I got the following error : > / > dpkg: error processing archive > /var/cache/apt/archives/libidl-2-0_0.8.14-3_amd64.deb (--unpack): > trying to overwrite '/usr/lib/x86_64-linux-gnu/libIDL-2.so.0.0.0', which is >also in package libidl0:amd64 0.8.14-1 > Processing triggers for libc-bin (2.19-22) ... > Errors were encountered while processing: > /var/cache/apt/archives/libidl-2-0_0.8.14-3_amd64.deb > E: Sub-process /usr/bin/dpkg returned an error code (1) signature.asc Description: This is a digitally signed message part
Bug#940621: libmeanwhile1: Login verification down or unavailable on 1.0.2-9+b1
Control: found -1 1.0.2-9+b1 Control: fixed -1 1.0.2-9 Hi, 在 2021-02-26星期五的 10:47 +0100，Adrien CLERC写道： > On Fri, 26 Feb 2021 09:23:03 +0100 Adrien CLERC > wrote: > > > > Boyuan Yang, can you reintroduce -fno-tree-vrp in CFLAGS please? I > can't > > > connect to Sametime right now. > > I did a lot of tests, and it seems that only "export > DEB_CFLAGS_MAINT_APPEND=-O0" fix this issue. > > Applying manual optimizations from O1 or O2 didn't trigger the issue, > but unfortunately, some flags don't exist (see > https://gcc.gnu.org/wiki/FAQ#optimization-options) > > And applying "-O0 -O1" trigger the issue. If you have more thing in > mind, please tell me, I am able to test it. But I'll stick to -O0 for > my > local installation Since the hard freeze is approaching, I will go with the conservative way and upload meanwhile/1.1.1-2 with the following line: export DEB_CFLAGS_MAINT_APPEND=-O0 -fno-tree-vrp Please test whether the built package fixes the bug once you have access to meanwhile/1.1.1-2 in Debian Sid. Let me know if it needs further fix. -- Thanks, Boyuan Yang
Bug#983492: alien incorrectly generates debian/rules
Control: severity -1 grave Since this bug was introduced by me (sorry!) and it breaks the entire rpm2deb conversion, I will handle this and make the fix into Debian 11. -- Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#987153: Typo in anacron log message: "ststus" should be "status"
Control: tags -1 +pending 在 2021-04-18星期日的 09:53 -0400，Jonathan Kamens写道： > Package: anacron > Version: 2.3-30 > Tags: patch > > There is a typo in the log message generated by anacron when it can't > send email. It says "ststus" when it should say "status". Patch committed into git packaging repo. -- Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#969409: sendfile: weekly cron job should use mktemp instead of tempfile
Control: severity -1 grave Since tempfile has been removed from debianutils, bumping the severity of this bug to grave. I have prepared initial fix in https://salsa.debian.org/debian/sendfile , but we still need more work to make another QA upload. Thanks, Boyuan Yang On Wed, 2 Sep 2020 10:40:07 +0200 Laurent Bonnaud wrote: > > Package: sendfile > Version: 2.1b.20080616-6 > Severity: normal > > > Dear Maintainer, > > each week I receive an e-mail with the following content: > > /etc/cron.weekly/sendfile: > WARNING: tempfile is deprecated; consider using mktemp instead. > > Could you please update /etc/cron.weekly/sendfile to use mktemp instead of tempfile? > > > -- System Information: > Debian Release: bullseye/sid > APT prefers unstable-debug > APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.8.0-trunk-amd64 (SMP w/2 CPU threads) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages sendfile depends on: > ii libc6 2.31-3 > ii libdpkg-perl 1.20.5 > ii libreadline8 8.1~alpha1-1 > ii openbsd-inetd [inet-superserver] 0.20160825-5 > ii perl 5.30.3-4 > ii update-inetd 4.50 > > -- > Laurent. > > signature.asc Description: This is a digitally signed message part
Bug#1000238: Fwd: Re: dnsproxy: Packaging licensing incompatible with upstream
Also forward my previous email to public Debian BTS: see below. Thanks, Boyuan Yang 在 2021-11-19星期五的 22:09 -0500，Boyuan Yang写道： > Hi, > > 在 2021-11-19星期五的 23:02 -0300，Marcos Talau写道： > > Package: dnsproxy > > Version: 1.17-1 > > Severity: normal > > X-Debbugs-Cc: mar...@talau.info > > > > The current packaging licensing (GPL-2) is incompatible with upstream > > licensing (MIT). It is a hampering condition to submit patches from > > Debian to upstream. > > > > I am adopting the package and I intend to change the packaging licensing > > to MIT. > > > > I will wait 15 days to know if anyone has any objections. > > No problem from my side. Please consider all my previous QA work to be > released under a permissive license. Canonically: > > I hereby release all my previous contribution to dnsproxy packaging in > Debian > (debian/ dir from dnsproxy/1.16-1, dnsproxy/1.17-1, and git commit a735bbf0, > 9ae0769c, de379f25, cd237bd6, 29d56e4e, 9ae2292f, and 44f63635 > under https://salsa.debian.org/debian/dnsproxy ) into the Public Domain. In > case where this is not possible, I release all aforementioned contribution > under CC0-1.0 license ( > https://creativecommons.org/publicdomain/zero/1.0/legalcode ). > signature.asc Description: This is a digitally signed message part
Bug#999907: libglobalarrays-dev,libga-dev: both ship /usr/lib/x86_64-linux-gnu/libga.a
X-Debbugs-CC: mba...@debian.org debichem-de...@lists.alioth.debian.org Hi, My personal preference would be implementing mutual conflict. Michael: Please let me know whether this works for you. I can make an NMU to implement mutual conflic for src:ga if you find it necessary. -- Thanks, Boyuan Yang On Thu, 18 Nov 2021 11:20:50 +0100 Andreas Beckmann wrote: > Package: libglobalarrays-dev,libga-dev > Severity: serious > Tags: sid bookworm > User: trei...@debian.org > Usertags: edos-file-overwrite > Control: found -1 5.7.2-2 > Control: found -1 1:2.4.7-5 > > Hi, > > automatic installation tests of packages that share a file and at the > same time do not conflict by their package dependency relationships has > detected the following problem: > > Preparing to unpack .../libga-dev_1%3a2.4.7-5_amd64.deb ... > Unpacking libga-dev:amd64 (1:2.4.7-5) ... > dpkg: error processing archive /var/cache/apt/archives/libga- dev_1%3a2.4.7-5_amd64.deb (--unpack): > trying to overwrite '/usr/lib/x86_64-linux-gnu/libga.a', which is also in package libglobalarrays-dev 5.7.2-2 > dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) > Errors were encountered while processing: > /var/cache/apt/archives/libga-dev_1%3a2.4.7-5_amd64.deb > > This is a serious bug as it makes installation fail, and violates > sections 7.6.1 and 10.1 of the policy. An optimal solution would > consist in only one of the packages installing that file, and renaming > or removing the file in the other package. Depending on the > circumstances you might also consider Replace relations or file > diversions. If the conflicting situation cannot be resolved then, as a > last resort, the two packages have to declare a mutual > Conflict. Please take into account that Replaces, Conflicts and > diversions should only be used when packages provide different > implementations for the same functionality. > > Here is a list of files that are known to be shared by both packages > (according to the Contents file for sid/amd64, which may be > slightly out of sync): > > /usr/lib/x86_64-linux-gnu/libga.a > > This bug is assigned to both packages. If you, the maintainers of > the two packages in question, have agreed on which of the packages will > resolve the problem please reassign the bug to that package. You may > also register in the BTS that the other package is affected by the bug. > > > libglobalarrays-dev does have one reverse build-dependency: nwchem. > libga-dev does have none. > > PS: for more information about the detection of file overwrite errors > of this kind see https://qa.debian.org/dose/file-overwrites.html signature.asc Description: This is a digitally signed message part
Bug#954554: python-asynctest: FTBFS, maybe-RM
X-Debbugs-CC: jo...@jones.dk andrew.shad...@collabora.co.uk Hi, I just checked the condition in Debian Sid, and it looks like no package still depends or build-depends on package python3-asynctest. As a result, I am going to submit a RM bug to have this package removed soon. Thanks, Boyuan Yang On Mon, 29 Jun 2020 20:38:29 +0100 "Rebecca N. Palmer" wrote: > Is the above intended as a proposal to remove asynctest? > > The rdeps in Debian are hypercorn, python-aioresponses, and (for > autopkgtest only) python-fakeredis. > > hypercorn upstream have stopped using it: > https://gitlab.com/pgjones/hypercorn/-/commit/80e2ad5db107c42d42471ea64764d2b42202349c > > The other two still list it in upstream requirements*. In the case of > aioresponses, this has been reported as a bug, with no reply as yet: > https://github.com/pnuckowski/aioresponses/issues/162 > > Skipping the affected tests is probably an option, though obviously a > non-ideal one. signature.asc Description: This is a digitally signed message part
Bug#966223: Cannot install without wiping other packages
X-Debbugs-CC: jida...@jidanni.org
Control: tags 966223 +unreproducible
Control: notfound 966223 1.10.1-2
Control: close 966223
Hi,
Obviously it was a temporary issue during Transition. Test shows that the
coinstallability issue does not exist in current Debian Stable, Debian Testing
or Debian Sid.
Thanks,
Boyuan Yang
On Sat, 25 Jul 2020 05:51:34 +0800 =?utf-8?B?56mN5Li55bC8?= Dan Jacobson
wrote:
> Package: unar
> Version: 1.10.1-2+b6
>
> With sid:
> # aptitude install unar
> The following NEW packages will be installed:
> unar{b} (D: gnustep-base-runtime, D: libgnustep-base1.27, D: libobjc4)
> 0 packages upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
> Need to get 0 B/1,274 kB of archives. After unpacking 6,124 kB will be used.
> The following packages have unmet dependencies:
> unar : Depends: gnustep-base-runtime (>= 1.27.0) but it is not installable
> Depends: libgnustep-base1.27 (>= 1.27.0) but it is not installable
> Depends: libobjc4 (>= 4.2.1) but it is not installable
> The following actions will resolve these dependencies:
>
> Keep the following packages at their current version:
> 1) unar [Not Installed]
>
>
>
> Accept this solution? [Y/n/q/?] n
> The following actions will resolve these dependencies:
>
> Remove the following packages:
> 1) guile-2.2-libs [2.2.7+1-5.1 (now, unstable)]
> 2) libgc1 [1:8.0.4-1 (now, unstable)]
> 3) libmailutils6 [1:3.9-3.1 (now, unstable)]
> 4) libmu-dbm6 [1:3.9-3.1 (now, unstable)]
> 5) mailutils [1:3.9-3.1 (now, unstable)]
> 6) w3m [0.5.3-38+b1 (now, unstable)]
> 7) w3m-el-snapshot [1.4.632+0.20200702.0409.dca01f9-1 (now, unstable)]
>
> Install the following packages:
> 8) gnustep-base-common [1.27.0-3 (unstable)]
> 9) gnustep-base-runtime [1.27.0-3 (unstable)]
> 10) gnustep-common [2.8.0-1 (unstable)]
> 11) libgc1c2 [1:7.6.4-0.4 (unstable)]
> 12) libgnustep-base1.27 [1.27.0-3 (unstable)]
> 13) libobjc4 [10.1.0-6 (unstable)]
>
>
signature.asc
Description: This is a digitally signed message part
Bug#974972: Reopening Debian bug 974972
reopen 974972 tags 972972 +sid found 974972 1.10.1-4 thanks With recent autopkgtest regression of unar/1.10.7+ds1-1 on armhf and s390x, I believe more work is needed to have the new version correctly packaged in Debian. Reopening this bug for now to provide unar/1.10.1 in Debian Testing and Debian Sid again before further regression investigation. Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#1008569: unar: diff for NMU version 1.10.1-3
Hi all, 在 2022-04-29星期五的 08:20 +0200，Paul Gevers写道： > Dear Boyuan, > > On 25-04-2022 20:44, Sudip Mukherjee wrote: > > > +unar (1.10.1-3) unstable; urgency=medium > > > + > > > + * QA upload. > > > + * Orphan the package (take over package maintenance) via > > > + ITS process. (Closes: #1008569) > > > > I maybe wrong but I was wondering if this is correct. > > > > Section 5.12 in Debian's Developers Reference [1] clearly says: > > Note that the process is only intended for actively taking over > > maintainership. Do not start a package salvaging process when you > > do not intend to maintain the package for a prolonged time. If you > > only want to fix certain things, but not take over the package, you > > must use the NMU process, even if the package would be eligible for > > salvaging. > > > > And, in this case you salavaged the package with the intention to > > orphan it not to maintain it. > > Today I received the 'Work-needing packages report' [1] that notified me > that there are three reverse dependencies of unar. Two are maintained by > me and the a11y team (I didn't realize that when I say the message by > Sudip). The third is maintained by you. It appears to me that you > "salvaged" unar because of that (I could be wrong, please let me know). > I think it would have helped (at least I would have read the message > from Sudip with more sympathy for you) if you would have made that clear > in your original ITS message and/or in a follow-up message to Sudip. > > Do you think it would be a good idea if you co-maintain this package > with the a11y team? That way, you don't need to take the sole ownership > (which you apparently didn't want) but can still easily keep an eye on > it (and continue the work to package 1.10.7). > > Paul > > [1] > https://lists.debian.org/msgid-search/e1nkesg-00066x...@quantz.debian.org Thank you all for the information and offering. Unar is an important package not only because of high popcon and reverse dependencies (including packages in a11y team, KDE's ark, and package bookworm I maintain), it is also the sole sane solution in the Linux world to correctly handle zip files with national encodings AFAIK (especially since unzip-iconv patch never made itself into Debian). That is the basic motivation for me to refresh this package. That being said, having this package team-maintained would be a good idea, better than "maintaining package via QA uploads". I would be happy to co- maintain it under the a11y team, and will reflect team maintenance in the next upload when current icu71 transition is properly dealt. For now my perference is to keep the git packaging repo under salsa.debian.org/debian/ namespace, but please let me know if you have other suggestions. Refreshing this package is expected to be bumpy due to Objective-C source code, non-standard build system, and porting issues ([2][3]). It's likely that I will be seriously using porterbox for the very first time. Any technical suggestions, or even extra hands, would be helpful. Thanks, Boyuan Yang [2] https://ci.debian.net/data/autopkgtest/testing/armhf/u/unar/21226476/log.gz [3] https://bugs.debian.org/746198 signature.asc Description: This is a digitally signed message part
Bug#1010819: python-svg.path: autopkgtest regression
Control: tags -1 +confirmed Control: forwarded -1 https://github.com/regebro/svg.path/issues/86 On Tue, 10 May 2022 21:41:18 +0200 Paul Gevers wrote: > Source: python-svg.path > Version: 6.0-1 > Severity: serious > X-Debbugs-CC: by...@debian.org > User: debian...@lists.debian.org > Usertags: regression > > == > FAIL: /tmp/autopkgtest-lxc.by0_p364/downtmp/build.x5A/src/README.rst > Doctest: README.rst > -- > Traceback (most recent call last): > File "/usr/lib/python3.9/doctest.py", line 2205, in runTest > raise self.failureException(self.format_failure(new.getvalue())) > AssertionError: Failed doctest test for README.rst > File > "/tmp/autopkgtest-lxc.by0_p364/downtmp/build.x5A/src/README.rst", line 0 > > -- > File "/tmp/autopkgtest-lxc.by0_p364/downtmp/build.x5A/src/README.rst", > line 85, in README.rst > Failed example: > path.d() > Expected: > 'M 200,100 L 300,100 Q 200,200 200,300' > Got: > 'L 300,100 Q 200,200 200,300' Seems like a regression introduced after upstream 5.1 release. Forwarded as https://github.com/regebro/svg.path/issues/86 . Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#1078404: sdcv: FTBFS: gunicode.h:809:34: error
Control: severity -1 normal Since the build now has -fpermissive enabled, downgrading this bug to severity normal. Eventually it needs to be solved upstream. Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#1087538: RM: pdm-pep517 -- ROM; Unused; Superceded by pdm-backend; Dead Upstream
Package: ftp.debian.org Control: affects -1 + src:pdm-pep517 X-Debbugs-Cc: pdm-pep...@packages.debian.org User: ftp.debian@packages.debian.org Usertags: remove Severity: normal Dear Debian FTP Masters, Please remove source package pdm-pep517 from Debian Unstable as seen at https://tracker.debian.org/pkg/pdm-pep517 . It is a legacy version of src:pdm-backend, and now all packages that use src:pdm-pep517 has migrated to src:pdm-backend. I believe we can drop src:pdm-pep517 and its built binary packages from Debian Unstable. Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#1094954: RM: nixnote2 -- RoQA; Orphaned; Depends on obsolete QtWebkit
Package: ftp.debian.org Control: affects -1 + src:nixnote2 X-Debbugs-Cc: nixno...@packages.debian.org User: ftp.debian@packages.debian.org Usertags: remove Severity: normal Dear Debian FTP Masters, Please remove package nixnote2 ( https://tracker.debian.org/pkg/nixnote2 ) from Debian Sid. It has been orphaned for a year, depends on the obsolete QtWebkit that is scheduled for removal [1], and has a basically inactive upstream that has no plan of migrating away from QtWebkit. Thanks, Boyuan Yang [1] https://bugs.debian.org/1069574 OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1075889: goldendict-ng: Ignores QT_QPA_PLATFORM=wayland, starts with xcb
Control: tags -1 +wontfix +help On Sun, 07 Jul 2024 11:27:33 +0300 Vladimir K wrote: > Package: goldendict-ng > Version: 24.05.13-4 > Severity: normal > > Dear Maintainer, goldendict-ng (and also goldendict) ignores environment > variables > pointing to wayland and starts with xcb. > > $ env | grep wayland > CLUTTER_BACKEND=wayland > XDG_SESSION_TYPE=wayland > >MEMORY_PRESSURE_WATCH=/sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/session.slice/wayland-wm@sway.desktop.service/memory.pressure > WAYLAND_DISPLAY=wayland-1 > WINIT_UNIX_BACKEND=wayland > QT_QPA_PLATFORM=wayland > SDL_VIDEODRIVER=wayland > GDK_BACKEND=wayland > > When starting with unset DISPLAY (to exclude xwayland): > > $ goldendict > qt.qpa.xcb: could not connect to display > qt.qpa.plugin: From 6.5.0, xcb-cursor0 or libxcb-cursor0 is needed to >load the Qt xcb platform plugin. > qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even >though it was found. > This application failed to start because no Qt platform plugin could be >initialized. Reinstalling the application may fix this problem. > > Available platform plugins are: wayland-egl, wayland, linuxfb, minimal, >offscreen, vkkhrdisplay, xcb, eglfs, minimalegl. > > Aborted > > It only starts natively when explicitly run with an argument: > > $ goldendict -platform wayland Your setup is explicitly not supported by goldendict-ng. According to https://xiaoyifang.github.io/goldendict-ng/topic_wayland/ , the goldendict-ng upstream is looking for help on the best way forward or wayland support. Please consider sending your help upstream. Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#1102709: libutf8.h-dev and libutfcpp-dev have an undeclared file conflict on /usr/include/utf8
Hi, 在 5/15/2025 9:46 AM, Bastian Germann 写道: X-Debbugs-CC: by...@debian.org Hi Boyuan, You have introduced the /usr/include/utf8 link in libutfcpp-dev, which was after libutf8.h-dev already had that directory. Your changelog entry says: * debian/libutfcpp-dev.maintscript, debian/libutfcpp-dev.links: Add compat symlink to avoid breaking build-dependencies after upstream moved header file paths. Do you remember which packages were affected? It has been a while and I don't remember it, sorry. Going through reverse-build-dep list with rebuilds might be the best way of finding out. Thanks, Boyuan OpenPGP_signature.asc Description: OpenPGP digital signature
