Bug#958191: patch
Control: tag -1 patch I've opened a merge request [1] addressing this. [1] https://salsa.debian.org/debian/dracut/-/merge_requests/1
Bug#943981: Proposal: Switch to cgroupv2 by default
I verified that * commenting out lxc.init.cmd and * putting lxc.mount.auto = cgroup:rw:force AT THE LAST LINE of /var/lib/lxc/autopkgtest-unstable-amd64/confiig allowed successfull autopkgtest of systemd on a host both with unified and hybrid hierarchy, WITHOUT changing /var/lib/lxc/autopkgtest-unstable-amd64/confiig. A problem is that putting lxc.mount.auto = cgroup:rw:force in /etc/lxc/default.conf will not work, because the content of /etc/lxc/default.conf is overwritten by lxc.include = /usr/share/lxc/config/debian.conf loaded later in autopkgtest-unstable-amd64/confiig. On the other hand > lxc.mount.auto = cgroup:rw:force proc:mixed sys:mixed > in /usr/share/lxc/config/common.conf. should work. Ryutaroh
Bug#937144: Bug#937769: getting python-linecache2/python-traceback2 fixes into testing (FAO traceback2, funcsigs nipype and numba maintainers).
On Tue, Apr 21, 2020 at 11:20:16PM +0200, Thomas Goirand wrote: > You can remove all of the python-oslo* from the list. The versions in > Experimental, which are the next version of OpenStack, are fixed. In 2 > weeks of time, I'll upload all what I staged in Experimental to Sid > (maybe 150 packages?) and that's going to fix it all. Will the new OpenStack version also fix this issue? #955116 python-murano-pkg-check: FTBFS with Sphinx 2.4: AttributeError: 'Sphinx' object has no attribute 'info' -- Valentin
Bug#958441: debtags: Please add Cobol language tag (devel::lang:cobol)
Package: debtags Severity: wishlist While tagging the gnucobol package, I discovered there is no tag for the cobol language. I propose to add a tag devel::lang:cobol for this purpose. Perhaps also add implemented-in::cobol for completeness, to match other programming languages? -- Happy hacking Petter Reinholdtsen
Bug#945816: O: gnucobol -- COBOL compiler
[Al Stone] > Petter, if you'd rather adopt it, let me know. Otherwise, assuming > it is in reasonably decent shape to start with, which it seems to > be, I'll adopt it. Please go ahead and adopt it. I do not really have capacity for more packages. :) -- Happy hacking Petter Reinholdtsen
Bug#958440: ITP: packetsender -- Network utility for sending and receiving TCP, UDP, SSL packets
Package: wnpp Severity: wishlist Owner: Joao Eriberto Mota Filho * Package name: packetsender Version : 6.2.6~pre Upstream Author : Dan Nagle * URL : https://packetsender.com/ * License : GPL-2+ Programming Lang: C++ Description : Network utility for sending and receiving TCP, UDP, SSL packets Packet Sender is a utility to allow sending and receiving TCP, UDP, and SSL (encrypted TCP) packets. It supports IPv4 and IPv6 and provides a GUI for final users. . Some features: * Can act as client/server to send and receive. * The payload can be ASCII or hex. * Command line for automation and scripting. * Packet sender cloud. . Some uses: * Controlling network-based devices in ways beyond their original apps. * Test automation (using its command line tool and/or hotkeys). * Testing network APIs (using the built-in TCP, UDP, SSL clients). * Malware analysis (using the built-in UDP, TCP, SSL servers). * Troubleshooting secure connections (using SSL ). * Testing network connectivity/firewalls (by having 2 Packet Senders talk to each other). * Stress-testing a device (using intense network generator tool). * Tech support (by sending customers a portable Packet Sender with pre-defined settings and packets). * Sharing/Saving/Collaboration using the Packet Sender Cloud service. . Packet Sender is useful for network security, network teaching, pentesters and testing firewall systems.
Bug#926560: Idea: plain English speaking output mode
This idea goes beyond the scope of units. We are not going to attempt to implement natural language parsing or output. This wishlist idea can be closed. On Sun, Apr 07, 2019 at 02:59:34AM +0800, Dan Jacobson wrote: > X-Debbugs-Cc: adri...@gnu.org > Package: units > Version: 2.18-1 > Severity: wishlist > > I have an idea. > > The units program is great, but it still makes no sense to the man on > the street when talking over the telephone, etc. > > Therefore it should also have the ability to output plain English > [Spanish, etc.] sentences like: > > "One hectare is equivalent to one hundred million square centimeters." > > This would also be great for accessibility for people who need screen > readers, etc. > > Not only should units be able to output such sentences, it should also > be able to read them back in and parse them too. > > (Anyway, currently I did > $ units ha cm^2 > * 1e+08 > / 1e-08 > > $ units --verbose ha cm^2 > ha = 1e+08 cm^2 > ha = (1 / 1e-08) cm^2 > > $ units hundred\ million > Definition: 1e+08 > > to indeed confirm my above sentence was correct.)
Bug#958439: recommends python(3)-qwt-qt5 which has never existed
Package: gnuradio Version: 3.7.11-3 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, GNU Radio currently recommends python3-qwt-qt5—and recommended python-qwt-qt5 before that—but these packages have never existed as best as I can tell. It had the '3' appended at [1], but going to Qt 5 made the '5' commute [2] - - python-qwt5-qt4, + python-qwt-qt5, The former was removed last year [3] and though I don't know its purpose, maybe python3-pyqt5.qwt - Python version of the Qwt6 technical widget library (Python3) is its successor? [1] https://salsa.debian.org/bottoms/pkg-gnuradio/-/commit/f99bae4917f4?expanded=1#58ef006ab62b83b4bec5d81fe5b32c3b4c2d1cc2_85_91 [2] https://salsa.debian.org/bottoms/pkg-gnuradio/-/commit/6fe9dfaf7302#58ef006ab62b83b4bec5d81fe5b32c3b4c2d1cc2_81_80 [3] https://tracker.debian.org/news/1064774/ - -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (2, 'unstable'), (1, 'testing-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.5.0-1-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_WARN, TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnuradio depends on: ii libboost-program-options1.67.0 1.67.0-17 ii libboost-system1.67.0 1.67.0-17 ii libboost-thread1.67.0 1.67.0-17 ii libc6 2.30-4 ii libcanberra-gtk-module 0.30-7 ii libcanberra-gtk3-module 0.30-7 ii libcodec2-0.9 0.9.2-2 ii libgcc-s1 10-20200411-1 ii libgnuradio-analog3.8.1 3.8.1.0-1 ii libgnuradio-audio3.8.1 3.8.1.0-1 ii libgnuradio-blocks3.8.1 3.8.1.0-1 ii libgnuradio-channels3.8.1 3.8.1.0-1 ii libgnuradio-digital3.8.13.8.1.0-1 ii libgnuradio-dtv3.8.13.8.1.0-1 ii libgnuradio-fec3.8.13.8.1.0-1 ii libgnuradio-fft3.8.13.8.1.0-1 ii libgnuradio-filter3.8.1 3.8.1.0-1 ii libgnuradio-pmt3.8.13.8.1.0-1 ii libgnuradio-qtgui3.8.1 3.8.1.0-1 ii libgnuradio-runtime3.8.13.8.1.0-1 ii libgnuradio-trellis3.8.13.8.1.0-1 ii libgnuradio-uhd3.8.13.8.1.0-1 ii libgnuradio-video-sdl3.8.1 3.8.1.0-1 ii libgnuradio-vocoder3.8.13.8.1.0-1 ii libgnuradio-wavelet3.8.13.8.1.0-1 ii libgnuradio-zeromq3.8.1 3.8.1.0-1 ii liblog4cpp5v5 1.1.3-1 ii libpython3.83.8.2-1+b1 ii libqt5core5a5.12.5+dfsg-9 ii libqt5widgets5 5.12.5+dfsg-9 ii libstdc++6 10-20200411-1 ii libuhd3.15.03.15.0.0-2+b1 ii libvolk2-bin2.2.1-2 ii python3 3.8.2-3 ii python3-click 7.0-3 ii python3-click-plugins 1.1.1-2 ii python3-gi 3.36.0-1+b1 ii python3-gi-cairo3.36.0-1+b1 ii python3-lxml4.5.0-1+b1 ii python3-mako1.1.2+ds1-1 ii python3-numpy 1:1.17.4-5 ii python3-opengl 3.1.5+dfsg-1 ii python3-pyqt5 5.14.2+dfsg-1+b1 ii python3-pyqtgraph 0.11.0~rc0-1 ii python3-sip 4.19.22+dfsg-1+b1 ii python3-yaml5.3.1-1+b1 ii python3-zmq 18.1.1-3+b1 Versions of packages gnuradio recommends: ii gnuradio-dev3.8.1.0-1 ii python3-matplotlib 3.1.2-2 pn python3-networkx pn python3-qwt-qt5 ii python3-scipy 1.3.3-3+b1 ii rtl-sdr 0.6.0-3 ii uhd-host3.15.0.0-2+b1 Versions of packages gnuradio suggests: ii gr-fosphor 3.8~2.2d4fe78-1+b2 ii gr-osmosdr 0.2.0-2+b1 - -- no debconf information -BEGIN PGP SIGNATURE- iHUEARYIAB0WIQT287WtmxUhmhucNnhyvHFIwKstpwUCXp+mjQAKCRByvHFIwKst pxcrAQDkiYb8W8/sbtVA01Gp28sQHS2sVCVX/1UtPVKu0kceCgD+LP6BaV7v3aWd FyxXsjoyd4qhPmlyO8n95P7MG1s2IwM= =GrKs -END PGP SIGNATURE-
Bug#958436: cfengine3: New cfengine3 upstream LTS versions are available
Package: cfengine3 Version: 3.12.1-2 Severity: wishlist The upstream version of cfengine community edition currently has two long-term support (LTS) versions: 3.12.4 and the newer 3.15.1. If Debian needs to stay on the 3.12 LTS branch, upgrading from 3.12.1 to 3.12.4 would at least sync up with that current LTS branch. However, if would be great if 3.15.1 LTS was available in sid in order to start testing policies with some of the new features and for eventual inclusion into bullseye. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (990, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.5.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.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 cfengine3 depends on: ii e2fsprogs 1.45.6-1 ii libacl1 2.2.53-6 ii libc6 2.30-4 ii liblmdb0 0.9.24-1 ii libpam0g 1.3.1-5 ii libpcre3 2:8.39-12+b1 ii libpromises3 3.12.1-2 ii libssl1.1 1.1.1f-1 ii libvirt0 6.0.0-6 ii libxml2 2.9.10+dfsg-5 ii lsb-base 11.1.0 Versions of packages cfengine3 recommends: pn python cfengine3 suggests no packages. -- Configuration Files: /etc/default/cfengine3 changed [not included] -- no debconf information
Bug#958438: nmu: ukui-interface_1.0.0-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu ukui-interface_1.0.0-1 . amd64 . unstable . -m "source-only rebuild after NEW queue" This is a regular binNMU to clean up maintainer-built binary package after going through the NEW queue. -- Regards, Boyuan Yang
Bug#958435: RFS: runescape/0.8-1 [RC] -- Multiplayer online game set in a fantasy world
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "runescape" * Package name: runescape Version : 0.8-1 Upstream Author : Jagex Games Ltd. * URL : https://oldschool.runescape.com * License : BSD-2-Clause * Vcs : https://salsa.debian.org/games-team/runescape Section : non-free/games It builds those binary packages: runescape - Multiplayer online game set in a fantasy world To access further information about this package, please visit the following URL: https://mentors.debian.net/package/runescape Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/non-free/r/runescape/runescape_0.8-1.dsc Changes since the last upload: * New upstream release. (Closes: #953487, #956275, #956276) * debian/control: + Added in Depends: kdialog | zenity, p7zip-full. + Long description with more details improved. * Added debian/docs. * debian/tests/control: Added in Depends: kdialog | zenity, p7zip-full. Regards, -- Carlos Donizete Froes [a.k.a coringao]
Bug#943981: Proposal: Switch to cgroupv2 by default
> It's a bit unfortunate, that when you boot your system with the unified > hierarchy, you need to explicitly configure > "lxc.init.cmd = /sbin/init systemd.unified_cgroup_hierarchy=1" or hope > the host systemd instance has been built with unified hierarchy as default. > That means, once we flip the default in unstable/testing, creating and > running a buster container will require > "lxc.init.cmd = /sbin/init systemd.unified_cgroup_hierarchy=1" Alternatively, we can also use "lxc.mount.auto = cgroup:rw:force". The default is "cgroup:mixed". This trick was told in the upstream: https://github.com/lxc/lxc/issues/3183#issuecomment-560163709 (this github issue was opened by you). By reading lxc.container.conf(5) man page, "cgroup:rw" seemed insecure to me on hosts with the hybrid hierarchy. But, comparison of /proc/mounts in containers with "cgroup:rw:force" and "cgroup:mixed" on the hybrid hierarchy on the host Linux, the effects of "cgroup:rw:force" and "cgroup:mixed" look the same (*), while "cgroup:rw:force" is more friendly on host with the unified hierarchy. (*) Is it really correct?? One way to sort out the situation is that changing the line lxc.mount.auto = cgroup:mixed proc:mixed sys:mixed to lxc.mount.auto = cgroup:rw:force proc:mixed sys:mixed in /usr/share/lxc/config/common.conf. Then we almost achieve > Would be nice if lxc could do that automatically. We could send a wishlist but report to the Debian lxc package, as it still lives in the experimental. We can do some experiment now... Best regards, Ryutaroh
Bug#952746: please build again for 32bit archs, plus add some minor patches
Package: src:gnat-gps Followup-For: Bug #952746 > Please build again for 32bit archs, maybe limited to those where it can be > built > with 64bit kernels in Debian. I feel that manually maintaining an up-to-date list of 32-bits architectures implemented by 64-bits buildds is not worth the while. Probably noone uses a graphical IDE on a 32-bits machine nowadays. The probability decreases with arbitrary restrictions like "Debian build daemon happens to have 64 bits". Full discussion at #913371. > Seems to build fine on armhf. The bug has never affected armhf. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913371#5 > - limit the parallel build on 32bit archs This has already been tried. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913371#25 > - Don't insist on gdb-minimal Please read #700151, #765482 and #659166. Why would gnat-gps Recommend gdb while it is unable to interact with it? > [work-around for #913546 ftbfs when built with -O3 on ppc64el Committed. Thanks.
Bug#958434: scribus suggests scribus-ng-doc; scribus*-doc do not correspond
Source: scribus Version: 1.5.1+dfsg-2 Severity: normal Control: affects -1 src:scribus-doc -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, scribus suggests scribus-ng-doc. This doesn't seem right and the matching 1.5.* version is only in experimental. scribus-doc isn't 1.5.* however. Seeing that the documentation is non-free I'm no longer pursuing it, but I would appreciate knowing whether this is deliberate. - -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (2, 'unstable'), (1, 'testing-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.5.0-1-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_WARN, TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -BEGIN PGP SIGNATURE- iHUEARYIAB0WIQT287WtmxUhmhucNnhyvHFIwKstpwUCXp+HhwAKCRByvHFIwKst p+itAP4zXeWhKpcKRI9wvPcDKBR4NDNjehgLkGvFvAB+ZzpXNQEAlvDjmadnXJd9 kvqMxRLcIjQ3j4hHHfrIMqkgXraoDwg= =N5A3 -END PGP SIGNATURE-
Bug#958433: thunderbird: wrong date format
Package: thunderbird
Version: 1:68.7.0-1~deb10u1
Severity: normal
Tags: l10n upstream
Hi Carsten,
after upgrading thunderbird from 52.9.1-1~deb9u1 to
68.7.0-1~deb10u1, the date format broke, both in the list view
and in the first line of a reply ("On 2020-04-21, sb. wrote:").
Format used to be ISO-8601 -mm-dd and now it is dd/mm/.
I played with the locales, esp. LC_TIME, but without success.
Note, that under Edit -> Preferences -> Advanced, below
"Date and Time Formatting", I can choose between
English (United States) and English (Denmark). However, the
latter is already selected. Btw. I have no idea where the first
one comes from, because I did not configure en_US*.
If this is really a bug, I would also be happy about any hack or
workaround, at least for the replies.
Many thanks for your awesome work on thunderbird packaging!
-- System Information:
Debian Release: 10.3
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-8-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_DK.utf8, LC_CTYPE=en_DK.utf8 (charmap=UTF-8) (ignored: LC_ALL
set to en_DK.utf8), LANGUAGE=en_DK.utf8 (charmap=UTF-8) (ignored: LC_ALL set to
en_DK.utf8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages thunderbird depends on:
ii debianutils 4.8.6.1
ii fontconfig2.13.1-2
ii libatk1.0-0 2.30.0-2
ii libc6 2.28-10
ii libcairo-gobject2 1.16.0-4
ii libcairo2 1.16.0-4
ii libdbus-1-3 1.12.16-1
ii libdbus-glib-1-2 0.110-4
ii libevent-2.1-62.1.8-stable-4
ii libffi6 3.2.1-9
ii libfontconfig12.13.1-2
ii libfreetype6 2.9.1-3+deb10u1
ii libgcc1 1:8.3.0-6
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 libgtk2.0-0 2.24.32-3
ii libjsoncpp1 1.7.4-3
ii libpango-1.0-01.42.4-7~deb10u1
ii libstartup-notification0 0.12-6
ii libstdc++68.3.0-6
ii libvpx5 1.7.0-3+deb10u1
ii libx11-6 2:1.6.7-1
ii libx11-xcb1 2:1.6.7-1
ii libxcb-shm0 1.13.1-2
ii libxcb1 1.13.1-2
ii libxext6 2:1.3.3-1+b2
ii libxrender1 1:0.9.10-1
ii libxt61:1.1.5-1+b3
ii psmisc23.2-1
ii x11-utils 7.7+4
ii zlib1g1:1.2.11.dfsg-1
Versions of packages thunderbird recommends:
ii hunspell-en-gb [hunspell-dictionary] 1:6.2.0-1
ii hunspell-en-us [hunspell-dictionary] 1:2018.04.16-1
ii lightning 1:68.7.0-1~deb10u1
Versions of packages thunderbird suggests:
ii apparmor 2.13.2-10
ii fonts-lyx 2.3.2-1
ii libgssapi-krb5-2 1.17-3
-- no debconf information
Bug#958364: Subject: RFS: libtpms/0.8.0~dev1-1 [ITP] -- TPM emulation library
Control: tags -1 -moreinfo
Hi Boyuan,
Thank you for your kind advice. I have fixed all issues according to
your advice and uploaded it to mentors.debian.org again [1].
[1] https://mentors.debian.net/package/libtpms
Would you check and sponsor it? If there are things I have missed,
please let me know.
Best regards,
Seunghun
On Wed, Apr 22, 2020 at 4:33 AM Boyuan Yang wrote:
>
> Control: tags -1 +moreinfo
>
> Hi Seunghun,
>
> Thanks for working on libtpms packaging in Debian and taking over maintenance.
> I sponsored the previous upload at
> https://ftp-master.debian.org/new/libtpms_0.7.0-1.html .
>
> After looking into your packaging, I think there are some issues as listed
> below. Please consider solving them and remove the "moreinfo" tag afterwards.
>
> * This one is critical: With new package, *NEVER* override dh_usrlocal in
> debian/rules file. Debian package should not ship files under /usr/local/. If
> there are special reasons about handling /usr/local/, I'd be happy to know it.
>
> * Please consider using "include /usr/share/dpkg/architecture.mk" instead of
> manual invocation of dpkg-architecture to get the value of DEB_HOST_MULTIARCH
> variable in debian/rules file.
>
> * The "--with autoreconf" parameter is useless now since it is the default for
> debhelper compatibility level 12.
>
> * Please strip all old changelogs entries from debian/changelog; those old
> parts are not part of Debian.
>
> * This one is also critical: Please do not list ${misc:Pre-Depends} in the
> Depends: field of libtpms0. Normally this variable substitution is not needed
> now; if you really needed, please use "Pre-Depends: ${misc:Pre-Depends}"
> instead.
>
> * With your current debian/*.install files, there are absolutely no necessity
> to build-depends on dh-exec. Please remove such dependency and remove
> corresponding shebang in *.install files.
>
> Let me know after you finish all those tweaks or if you have any questions.
>
> --
> Regards,
> Boyuan Yang
>
> 在 2020-04-21星期二的 07:55 +0900，Seunghun Han写道：
> > Package: sponsorship-requests
> > Severity: wishlist
> >
> > Dear mentors,
> >
> > I am looking for a sponsor for my package "libtpms"
> >
> > * Package name: libtpms
> >Version : 0.8.0~dev1-1
> >Upstream Author : Stefan Berger
> > * URL : https://github.com/stefanberger/libtpms
> > * License : BSD-3-clause
> > * Vcs : https://salsa.debian.org/kkamagui-guest/libtpms
> >Section : libs
> >
> > It builds those binary packages:
> >
> > libtpms0 - TPM emulation library
> > libtpms-dev - libtpms header files and man pages
> >
> > To access further information about this package, please visit the
> > following URL:
> >
> > https://mentors.debian.net/package/libtpms
> >
> > Alternatively, one can download the package with dget using this command:
> >
> > dget -x
> > https://mentors.debian.net/debian/pool/main/libt/libtpms/libtpms_0.8.0~dev1-1.dsc
> >
> > Changes since the last upload:
> >
> >* New maintainer (Closes: #958071)
> >* Updated standards version to 4.5.0 in debian/control
> >* Updated debhelper version to 12 in debian/control
> >* Added Rules-Requires-Root to debian/control
> >* Added Vcs-Browser and Vcs-Git to debian/control
> >* Removed autotools-dev and dh-autoreconf from debian/control
> >* Removed autotools-dev and parallel option from debian/rules
> >* Converted debian/copyright to dep5-copyright format
> >* Added debian/watch file
> >* Added debian/libtpms.symbols file
> >* Added debian/upstream/metadata file
> >* Changed section of man pages from 1 to 3
> >* Fixed typos and a long line warning in man pages
> >* Set date of man pages to last changelog entry
> >
> > Regards,
> >
> > --
> > Seunghun Han
> >
Bug#700151: merge 700151 765482
Package: src:gnat-gps Followup-For: Bug #700151 Control: unblock -1 by 659166 Control: retitle -1 don't recommend just gdb-minimal Control: merge -1 765482 Hello. Last time someone has checked… if gdb-minimal is installed, the debugger in gnat-gps runs fine if gdb is installed, the debugger in gnat-gps does not work so I consider that * Recommends: gdb-minimal is correct * Recommends: gdb is incorrect Bug #659166 (cannot run debugger from gnat-gps) is fixed (by the gdb-minimal work-around). It cannot block this one or be merged anymore. However, it is referenced here because it contains clues for a proper solution.
Bug#957968: xaos: ftbfs with GCC-10
Control: tags -1 + pending Control: forwarded -1 https://github.com/xaos-project/XaoS/pull/146 Fixed in git: https://salsa.debian.org/games-team/xaos/-/commit/1435643674cc7de0269deb214cadea5aac4be5e9 signature.asc Description: PGP signature
Bug#958432: RFS: libgadu/1:1.12.2-5 [QA] -- Gadu-Gadu protocol library
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "libgadu" * Package name: libgadu Version : 1:1.12.2-5 Upstream Author : * URL : http://toxygen.net/libgadu/ * License : LGPL-2.1 * Vcs : https://salsa.debian.org/debian/libgadu Section : libs It builds those binary packages: libgadu3 - Gadu-Gadu protocol library - runtime files libgadu-dev - Gadu-Gadu protocol library - development files libgadu-doc - Gadu-Gadu protocol library - documentation To access further information about this package, please visit the following URL: https://mentors.debian.net/package/libgadu Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/libg/libgadu/libgadu_1.12.2-5.dsc Changes since the last upload: * QA upload. * Fix FTBFS with gcc-10. (Closes: #957441) * Use debhelper-commit. - Update compat level to 12. - Remove dependency on dh-autoreconf - Remove autoreconf and parallel from rules. - Adjust doc location. * Exclude md5 from doc package. * Update Standards-Version to 4.5.0 * Mark Vcs to salsa. - Remove old gbp.conf -- Regards Sudip
Bug#958431: gkrellmd: CIDR match in allow_host not working for IPv6 connections
Package: gkrellmd Version: 2.3.10-2+b1 Severity: normal Tags: ipv6 Dear Maintainer, * What led up to the situation? Connection via IPv6 to a gkrellmd server * What exactly did you do (or not do) that was effective (or ineffective)? allow-host line in /etc/gkrellmd.conf with CIDR specification e.g. "allow-host 2001::::/48" * What was the outcome of this action? client connection refused with message "Connection not allowed from 2001:::1::::" * What outcome did you expect instead? The connection should have been allowed. I have debugged this, and it is because the binary has been built without INET6 defined in the build system. The code is there to do the match (server/main.c lines 389-419), just not compiled in. Please recompile with INET6 defined, however the build system does that. Many thanks -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.5.0-1-amd64 (SMP w/16 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, 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 Versions of packages gkrellmd depends on: ii adduser 3.118 ii libc6 2.28-10 ii libglib2.0-0 2.58.3-2+deb10u2 ii libsensors5 1:3.5.0-3 gkrellmd recommends no packages. gkrellmd suggests no packages.
Bug#958430: Vagrant libvirt image debian/buster64 version 10.3.0 grub error
Package: cloud.debian.org Severity: grave Justification: renders package unusable Dear Maintainer, The libvirt image debian/buster64 version 10.3.0 fails to boot an gives grub error below. No files seems to be available under /boot Booting from Hard Disk... error: file `/boot/grub/i386-pc/normal.mod' not found. Entering rescue mode... grub rescue> ls (hd0,msdos1)/boot grub rescue> Thanks, Pascal
Bug#957234: freegish: ftbfs with GCC-10
Control: tags -1 + pending Fixed in git: https://salsa.debian.org/games-team/freegish/-/commit/b606d829d84e707e8a51888141803eac1b1a4521 signature.asc Description: PGP signature
Bug#957048: blastem: FTBFS with gcc-10: multiple definition of vdp_regs
Control: tags -1 + pending Fixed in git: https://salsa.debian.org/games-team/blastem/-/commit/411e51e7c969bc23ae5f4b79bf12efaf18f64bbd signature.asc Description: PGP signature
Bug#958410: lintian: please warn about about duplicated debhelper build-deps
[I renamed this bug away from "nag" as that is not how we wish Lintian to be viewed] Hi Mattia, > Build-Depends: autoconf-archive, > - debhelper (>= 11), > + debhelper (>= 12), > + debhelper-compat (= 12), > libbz2-dev, > libtar-dev, Interesting, I would have thought debhelper would FTBFS this with: dh: warning: Please specify the debhelper compat level exactly once. dh: warning: * debian/compat requests compat 12. dh: warning: * debian/control requests compat 12 via "debhelper-compat (= 12)" dh: warning: dh: warning: Hint: If you just added a build-dependency on debhelper-compat, then please remember to remove debian/compat dh: warning: dh: error: debhelper compat level specified both in debian/compat and via build-dependency on debhelper-compat Alternatively, if the build-profile means that the *debhelper-compat* dependency is ignored and there is no debian/compat, would it not mean that it would FTBFS with a "no debian/compat file"? Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#956085: libmicrohttpd: new upstream version available
On Sun 2020-04-19 10:42:33 +0200, Bertrand Marc wrote: > As a general rule concerning your changes, I would prefer not mixing > packaging style and trailing whitespaces changes with bug fixes. I agree with that; the individual git commits should indeed separate those things. The canonicalization of whitespace and line-wrapping that i did in that series is intended to make the specific functional changes easier to read. > But if you'd like to co-maintain the package, we could also implement > your wrap-and-sort choices of course. I'd be happy to help co-maintain, but if i do that, there are some conventions that i think collectively make it easier to handle shared development: - I note that you preferred wrap-and-sort -as over wrap-and-sort -ast. But -t is useful because it makes every line identical, so that a diff that appends to a list looks the same as a diff that inserts an element elsewhere in the list. - I prefer to use gbp pq-style patch queues in debian/patches (using the standard "git format-patch" format). Compared to DEP-3 patches, which are a debian-specific format, pq-style patches integrate better into common uses of git, both for upstream and for other downstreams that also use git. Also, it is easy/comfortable to use "gbp pq" to tweak and maintain them. - I'd prefer to rely on DEP-14-style branch naming -- i would be happy to do the branch rename shuffle for the repository and to add a debian/gbp.conf if you're ok with that. And two more changes that would only likely apply going forward (to new upstream releases): - I find it really useful to have debian packaging git branch connected to the upstream git branches -- that is, the "upstream/latest" branch is an overlay that inherits from upstream git tags, connected with gbp's "upstream-vcs-tag" feature. And debian packaging represents a series of commits branching from there. This approach gives git a better understanding of how packaging and upstream work intersects, and can make it easier to interact with upstream in their preferred development environment. - I tend to prefer to have gbp import-orig filter out most or all of the generated files from the tarball (in particular, the files that we aim to regenerate with modern debhelper's default autoreconf steps). The technique i use would only apply going forward, and of course the stashed pristine-tar orig tarballs are *not* filtered out, so we would still work with whatever tarballs are distributed by upstream. i can also provide an updated debian/gbp.conf to do that, if you're interested. You can see examples of these approaches in recent versions of https://salsa.debian.org/debian/libgpg-error if you want. If none of the above sounds horrible to you, feel free to add me to the Maintainers: or Uploaders: field. Please let me know if you do! > Concerning the new version, I am aware of the issue with parallel > building. Actually, I was the one signalling the issue [1]. i saw that, thanks! I was just trying to pull in the fixes that upstream proposed to make the relevant tests run serially rather than in parallel. > However, I am still puzzled by another testing issue: on my box, > test_upgrade_tls and test_upgrade_large_tls fail randomly when built > with git-buildpackage and cowbuilder, but not with debuild and > dpkg-buildpackage. Therefore I suspect the use of chroots, but I did > not manage to locate properly the issue. I also submit the problem > upstream, without success yet [2]. Your help would be much welcome on > this one. Interesting, i'm not seeing the failure on my side for 0.9.70-1 with either git-buildpackage or cowbuilder based on the current master branch in salsa, though maybe i just haven't run a build repeatedly enough to hit whatever corner case you're seeing? fwiw, i think it's worth going ahead and uploading 0.9.70-1 of the package even if you see intermittent failures on some local cowbuilder instances. Failure logs produced by debian build daemons are very handy artifacts for upstream debugging. Thanks a lot for your work on libmicrohttpd in debian! --dkg signature.asc Description: PGP signature
Bug#860015: /usr/bin/gitk: 3: exec: wish: not found
reassign 860015 tk 8.6.0+9 found 860015 tk/8.6.9+1 retitle 860015 tk: missing /usr/bin/wish symlink after upgrade quit Frederic wrote: > After an upgrade from jessie -> stretch, I got this error message > > /usr/bin/gitk: 3: exec: wish: not found Anders Boström wrote: > I got this problem after an upgrade to buster. > > Solution in my case was: > > # apt reinstall tk > > And then the missing link was restored: > > eckert:~# ll /usr/bin/wish > lrwxrwxrwx 1 root root 7 feb 23 2019 /usr/bin/wish -> wish8.6 > eckert:~# Thanks, Jonathan
Bug#958429: ITP: golang-github-zenhack-go.notmuch -- Go language bindings for notmuch mail
Package: wnpp Severity: wishlist Owner: Ben Fiedler * Package name: golang-github-zenhack-go.notmuch Version : 0.0~git20190821.5a19619-1 Upstream Author : Ian Denhardt * URL : https://github.com/zenhack/go.notmuch * License : GPL-3+ Programming Lang: Go Description : Go language bindings for notmuch mail Go binding for notmuch mail (http://notmuchmail.org/). . Licensed under the GPLv3 or later (like notmuch itself). DevelopmentRunning tests The project uses make to setup and download additional assets for the tests. . Run make test to run the tests. Pre PR checks Next to the tests, you should also run gofmt on the sourcecode. Running make fmtcheck checks for formatting issues. . To run both tests and format checks, use make ci. This is a dependency of aerc when compiling with notmuch support
Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1
On Sun, Apr 12, 2020 at 12:18:35PM +0200, Aurelien Jarno wrote: > > Significant performance impact has also been observed in less contrived > > cases (MariaDB and Postgres), but I don't have a repro to share. > > But indeed what counts is number on real workloads. It would be nice to > get numbers when those software are run against a rebuilt glibc. As > those software are using a lot of atomics directly, it would be also > interesting to have numbers with those software also rebuilt to use > those new instructions. Agreed. I don't have specific examples of real world impact at the moment. AIUI, the most significant impact comes in the usage of atomics in pthread_mutex_lock(). When there are multiple threads contending for a lock, one thread will (approximately) always obtain the lock, while the others will starve. With atomics support in place, the probability of obtaining the lock is roughly evenly distributed among all the threads. So any workload in which multiple threads may contend for a lock should be a candidate to demonstrate this problem in the real world. > It would also be nice to have numbers to see the impact on non-ARMv8.1 > CPU on real workloads. As pointed out by Florian, and if the impact is > negligible, it might be a good idea to enable -moutline-atomics > globally at the GCC level so that all software can benefit from it, and > instead of only glibc. That could be either upstream or only in Debian, > that's probably a separate discussion. Otherwise we will likely end up > using this non-default GCC option on all packages that runs faster with > it. Agreed. > To be honest from a glibc maintenance point of view it's something I > would like to avoid. We haven't been actively trying to remove the > remaining optimized libraries (on i386, hurd and alpha), but we have > tried to avoid adding new ones. The problem is not building a second > optimized glibc, but rather providing a safe upgrade as the optimized > and the non-optimized package have to be at the same version or one of > them has to be disabled. This has caused many system breakages overall. Understood, that makes sense. I wonder if it's worth it to investigate techniques to improve the situation around optimized libraries. Do you have any thoughts on what such an improvement might look like? > Also note that the mechanism allowing a safe upgrade *does* incur a > runtime overhead as every binary now has to test for the presence of > /etc/ld.so.nohwcap to detect a possible upgrade of the glibc in > progress. That's why we have disabled it on architecture not providing > an optimized library [1]. Thanks for the pointer, it's interesting to see data on that. This also suggests that it might be worthwhile to investigate a better mechanism for identifying the availability of hardware features. > > I've tested both options and found them to be acceptable on v8.1a (Neoverse > > N1) and v8a (Cortex A72) CPUs. I can provide bulk test run data of the > > various different configuration permutations if you'd like to see additional > > data. > > As said above I think we would need more numbers on real workload to > take a decision. Don't get me wrong I do not oppose on improving atomics > on ARMv8.1, but I would like that we chose the best option. Also if we > go with the -moutline-atomics option, I believe it rather has to be a > ARM porters decision than a glibc maintainers decision (hence the Cc:). I'll see what I can come up with. Do the arm porters have any opinions on this matter? noah
Bug#945816: O: gnucobol -- COBOL compiler
On 21 Apr 2020 08:23, Petter Reinholdtsen wrote: > [Ludwin Janvier] > > I intend to orphan the gnucobol package. > > Hi. I really enjoyed finding GNU Cobol in Debian, and hope it will stay > here for a long time. Unfortunately I do not have the capacity to > maintain it myself in Debian. > > Can you tell something about the problems with maintaining this package, > or what a future maintainer should keep in mind? > > I visited what I believe is the official IRC channel for the project, > irc://irc.oftc.net/#gnucobol, and there were no-one there, which I found > worrying. > -- > Happy hacking > Petter Reinholdtsen For somewhat nostalgic reasons on my part, I'm looking at this package and thinking about adopting it. It looks like the package has not been touched in some time, but upstream still seems to be active (commits within the last day, for example). Petter, if you'd rather adopt it, let me know. Otherwise, assuming it is in reasonably decent shape to start with, which it seems to be, I'll adopt it. -- Ciao, al -- Al Stone Debian Developer E-mail: a...@ahs3.nethttp://www.debian.org a...@debian.org --
Bug#91815: Patch to add memusage and memusagestat
Hi, On 2020-04-21 20:58, Stephen Kitt wrote: > Control: tag -1 + patch > > Hi, Thanks for trying to fix one of the oldest glibc bugs ;-) > The attached patch adds memusage and memusagestat to the libc-bin package. > This does mean that the latter becomes dependent on libgd3, so it might be > better to add a new memusage package; I can take care of that if the > maintainers think it’s better. I am not sure we want to add a new dependency for libc-bin, I am sure people running embedded systems won't appreciate. Any reason for not shipping it in libc-dev-bin instead? For me that looks more like a tool to be used for "development". At least the memusagestat is similar to the mtrace one that is in libc-dev-bin. We also have to make sure that this new build-dependency doesn't break bootstrapping. I have added Helmut in Cc so that he can have a look. Thanks, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Bug#937093: [PATCH 0/1] preparatory changes for 1.17.0
This change can be used for the current 1.16.1 version and will be needed for building 1.17.0-rc1, involving python3. Bastian Germann (1): Call make generate instead of shell script debian/rules | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.26.2
Bug#937093: [PATCH 1/1] Call make generate instead of shell script
mupdf 1.17.0-rc1 switches the .py files from py2 to py3 but does not use the right interpreter in shell files. There is different means to generate the .h files, so use that. --- debian/rules | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/debian/rules b/debian/rules index 92533dae..e59bf92c 100755 --- a/debian/rules +++ b/debian/rules @@ -49,7 +49,7 @@ endif override_dh_auto_build: -mkdir source/pdf/cmaps - sh scripts/runcmapdump.sh + $(MAKE) generate dh_auto_build -- $(BUILD_FLAGS) override_dh_auto_install: -- 2.26.2
Bug#958428: RFS: fdkaac/1.0.0-1 [RC] -- command line encoder frontend for libfdk-aac
Package: sponsorship-requests Severity: important Control: block 955248 by -1 Dear mentors, I am looking for a sponsor for my package "fdkaac" * Package name: fdkaac Version : 1.0.0-1 Upstream Author : nu774 * URL : https://github.com/nu774/fdkaac * License : Zlib * Vcs : https://git.ieval.ro/?p=fdkaac.git Section : sound It builds those binary packages: fdkaac - command line encoder frontend for libfdk-aac To access further information about this package, please visit the following URL: https://mentors.debian.net/package/fdkaac Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/contrib/f/fdkaac/fdkaac_1.0.0-1.dsc Changes since the last upload: * New upstream version. Thanks Håvard Flaget Aasen. for noticing. (Closes: #955248) * Bump Standards-Version to 4.0.1 (no changes required). Yes, this is still an ancient standards version, but it's slightly less ancient. - Marius Gavrilescu
Bug#955248: fdkaac: diff for NMU version 1.0.0-0.1
Håvard Flaget Aasen writes: > Control: tags 955248 + patch > Control: tags 955248 + pending > > > Dear maintainer, > I've prepared an NMU for fdkaac (versioned as 1.0.0-0.1) and uploaded it > to mentors. Please feel free to tell me if I should delete it. Dear Håvard, Thanks for preparing a package. I've updated the upstream version to 1.0.0 in my git repository and uploaded a package to mentors. You can now delete the NMU from mentors. -- Marius Gavrilescu
Bug#958139: ITP: vim-gitgutter -- A Vim plugin which shows a git diff in the sign column
On Tue, Apr 21, 2020 at 11:01:00AM +0200, Raphael Medaer wrote: > Hi James, > > I did the changes you suggested > (https://salsa.debian.org/rmedaer/vim-gitgutter > /-/commit/8e9bd0944c7a9edb91dc7056996c8d16446a93fd) > The vim plugin is "optional". It means that users will have to add `packadd > gitgutter` in their vimrc. Should I document that somewhere ? If gitgutter is unintrusive by default and respects the normal conventions to disable the plugin (i.e., "let g:loaded_gitgutter = 1" in the vimrc will stop it from doing anything), then it may be better to just enable it by default. Then there aren't any instructions required after installing the package. Is there a particular reason it isn't enabled for neovim? > I also created a project in vim-team group (https://salsa.debian.org/vim-team/ > vim-gitgutter) however I don't have permissions to create branches. > Could you change my role for this project ? You're maintainer for the repo. Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Bug#945236: mirror submission for mirror.infomaniak.com
On 4/21/20 11:00 PM, Julien Cristau wrote:
> On Tue, Apr 21, 2020 at 10:56:52PM +0200, Thomas Goirand wrote:
>> On 4/20/20 4:36 PM, Julien Cristau wrote:
>>> You might need to set MIRRORNAME in the ftpsync config to the name you
>>> wish to have appear in the mirror list.
>>
>> Is it mandatory that it matches? This would need some reconfiguration on
>> our side, if it does. Please let me know so that I can act on this if
>> you require it.
>>
> Yes, we need the trace file to exist at
> http://{mirrorname}/debian/project/trace/{mirrorname} for our tools
> (e.g. https://mirror-master.debian.org/status/mirror-status.html) to
> work.
Ok, I'll make that match and write in this bug when fixed then
(probably, I'll do that tomorrow). Thanks for the info.
Cheers,
Thomas Goirand (zigo)
Bug#937144: Bug#937769: getting python-linecache2/python-traceback2 fixes into testing (FAO traceback2, funcsigs nipype and numba maintainers).
Hi Thomas (2020.04.21_21:20:16_+) > > But that still leaves the question of what to do about the dependency of > > pytest on pypy-funcsigs ? should pypy modules be removed from pytest and > > it's reverse-dependencies in the same way that regular python2 modules > > were? how feasible is that? are pypy-* packages only useful with python2 > > pypy or are they also useful with python3 pypy? Pretty much, yes. pypy itself (the python 2.7 pypy) will continue to exist for the foreseeable future, to support building pypy3. But we don't need to ship modules for it. I'd be pretty happy if we had working virtualenv, and nothing else. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#925755: Fixed in newer release of libopenshot / libopenshot-audio
On Tue, 21 Apr 2020 15:04:59 -0400 John Scott wrote: > > libopenshot-audio builds with Clang without any modifications. Using this > OpenShot (again with Clang) gets a bit farther: > /usr/include/libopenshot-audio/JuceLibraryCode/modules/juce_audio_basics/../juce_core/unit_tests/juce_UnitTest.h:73:17: note: candidate found by name lookup is 'juce::UnitTest' > class JUCE_API UnitTest > ^ > /<>/tests/Cache_Tests.cpp:50:2: error: reference to 'UnitTest' is ambiguous > > I've seen this is fixed in a commit upstream, and I think cherrypicking it > helped, but the -audio Debian package uses the Juce embedded code copies > instead of the ones in juce-modules-source as best as I can tell. What version of libopenshot is that result from? The Clang namespacing was fixed with the merge of 2a1fe80[1] on 2019-10-29, and would be included in both libopenshot-0.2.4 and libopenshot-0.2.5. That's a merge commit and it touches a bunch of files, but basically all of our headers now qualify juce symbols with the juce:: namespace prefix, and the test sources now #define DONT_SET_USING_JUCE_NAMESPACE which prevents JUCE from exporting its symbols into the global namespace. AFAICT that's the only way to prevent UnitTest++ and JUCE from clashing over ambiguous 'UnitTest' symbols. But all this should have been solved months ago. > I'm uneasy about this and hope that a new release of OpenShot made with the > practices described in /usr/share/doc/juce-modules-source/README.Debian will > make an elegant solution. Is there a copy of that file online somewhere? It's not part of the JUCE distribution as far as I can tell, and it's definitely not located at that path on my Fedora machine. [1]: https://github.com/OpenShot/libopenshot/commit/2a1fe80
Bug#958427: libsrtp2: FTBFS on x32: bogus printf with time_t, then segfaults [regression]
Source: libsrtp2
Version: 2.3.0-3
Severity: important
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
2.3.0-4 FTBFS:
https://buildd.debian.org/status/fetch.php?pkg=libsrtp2=x32=2.3.0-4=1586231427=0
First a warning shows bad code:
[…]
test/rtp_decoder.c: In function 'rtp_decoder_handle_pkt':
test/rtp_decoder.c:768:26: warning: format '%ld' expects argument of type 'long
int', but argument 3 has type '__time_t' {aka 'long long int'} [-Wformat=]
768 | fprintf(stdout, "%02ld:%02ld.%06ld\n", delta.tv_sec / 60,
delta.tv_sec % 60,
| ^ ~
| | |
| long int __time_t {aka
long long int}
| %02lld
test/rtp_decoder.c:768:32: warning: format '%ld' expects argument of type 'long
int', but argument 4 has type '__time_t' {aka 'long long int'} [-Wformat=]
768 | fprintf(stdout, "%02ld:%02ld.%06ld\n", delta.tv_sec / 60,
delta.tv_sec % 60,
|^
~
||
|
|long int
__time_t {aka long long int}
|%02lld
[…]
The code in question must be fixed like this:
- fprintf(stdout, "%02ld:%02ld.%06ld\n", delta.tv_sec / 60, delta.tv_sec %
60,
+ fprintf(stdout, "%02ld:%02d.%06ld\n", (long)(delta.tv_sec / 60),
(int)(delta.tv_sec % 60),
Then, it segfaults:
[…]
Build done. Please run '/usr/bin/make runtest' to run self tests.
make[1]: Leaving directory '/<>'
touch debian/stamp-makefile-build
/usr/bin/make -C . runtest LD_LIBRARY_PATH=":/<>"
make[1]: Entering directory '/<>'
Build done. Please run '/usr/bin/make runtest' to run self tests.
running libsrtp2 test applications...
crypto/test/cipher_driver -v
make[1]: *** [Makefile:47: runtest] Segmentation fault
[…]
2.3.0-3 built fine, so this is a recent regression.
-- System Information:
Debian Release: bullseye/sid
APT prefers unreleased
APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable'),
(100, 'experimental')
Architecture: x32 (x86_64)
Foreign Architectures: i386, amd64
Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)
Bug#937144: Bug#937769: getting python-linecache2/python-traceback2 fixes into testing (FAO traceback2, funcsigs nipype and numba maintainers).
On 4/20/20 2:51 PM, peter green wrote: > On 20/04/2020 08:57, Thomas Goirand wrote: >>> Option 1: fix all four packages to be python 2 free. >>> >>> Option 2: Remove python2 stuff from traceback2, python-funcsigs and >>> numba. Break the dependencies of nipype in sid. >>> >>> Option 3: Remove python2 stuff from traceback2, modify python-funcsigs >>> so it still builds the python2 package but does not run tests with >>> python 2. >> Funcsigs is a backport of the PEP 362 function signature features from >> Python 3.3's inspect module. > Thanks for the info. >> Python 2 has never been removed from this >> package. Though instead, we shall remove this source package entirely >> from Debian. > # Broken Depends: > nipype: python-nipype > pytest: pypy-pytest > python-logfury: python3-logfury > python-oslo.utils: python3-oslo.utils > > # Broken Build-Depends: > beaker: python3-funcsigs > kombu: python3-funcsigs > nipype: python-funcsigs > pagure: python3-funcsigs > pytest: pypy-funcsigs > python-oslo.log: python3-funcsigs > python-oslo.utils: python3-funcsigs (>= 0.4) > ripe-atlas-cousteau: python3-funcsigs You can remove all of the python-oslo* from the list. The versions in Experimental, which are the next version of OpenStack, are fixed. In 2 weeks of time, I'll upload all what I staged in Experimental to Sid (maybe 150 packages?) and that's going to fix it all. For the others, probably I should start filling bugs... > If what you say is correct then it sounds like the python3-funcsigs > revese depedencies could be dealt with fairly easily. > > But that still leaves the question of what to do about the dependency of > pytest on pypy-funcsigs ? should pypy modules be removed from pytest and > it's reverse-dependencies in the same way that regular python2 modules > were? how feasible is that? are pypy-* packages only useful with python2 > pypy or are they also useful with python3 pypy? I really don't know about pypy. Probably the pypy-pytest should indeed go away, as the initial plan was to switch to pypy3. Maybe tumbleweed (Stefano Rivera) would be able to answer. I'm adding him as Cc. >> Traceback2 *already* has Python 2 support removed in Sid. I uploaded >> this on the 21st of march, pressured by its potential autoremoval. > > Sorry it seems I got my package names mixed up when writing the list of > options. I said traceback2 where I meant unittest2. So, if I'm following correctly, what you seem to propose, is to remove Python 2 from unittest2. If that's the case, then I agree with such a plan. I just didn't dare to do it yet. Though in fact, I already worked on that, but stopped, also because unittest2 FTBFS when I try building it on my laptop. So I've pushed it in its normal Git repo [1] under a py2-removal branch. If anyone has some time available to look at it, that'd be nice (I currently don't...). Cheers, Thomas Goirand (zigo) [1] https://salsa.debian.org/python-team/modules/unittest2/
Bug#953522: W: Possible missing firmware /lib/firmware/rtl_nic/rtl8125a-3.fw, rtl8168fp-3.fw for module r8169
Package: firmware-realtek Version: 20190717-2 Followup-For: Bug #953522 Control: forcemerge 947356 953522 Control: retitle 947356 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8125a-3.fw, rtl8168fp-3.fw for module r8169 The message is now: update-initramfs: Generating /boot/initrd.img-5.5.0-2-amd64 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8125a-3.fw for module r8169 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168fp-3.fw for module r8169 -- System Information: Debian Release: bullseye/sid APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable'), (100, 'experimental') Architecture: x32 (x86_64) Foreign Architectures: i386, amd64 Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) firmware-realtek depends on no packages. firmware-realtek recommends no packages. Versions of packages firmware-realtek suggests: ii initramfs-tools 0.136 -- no debconf information
Bug#945236: mirror submission for mirror.infomaniak.com
On Tue, Apr 21, 2020 at 10:56:52PM +0200, Thomas Goirand wrote:
> On 4/20/20 4:36 PM, Julien Cristau wrote:
> > You might need to set MIRRORNAME in the ftpsync config to the name you
> > wish to have appear in the mirror list.
>
> Is it mandatory that it matches? This would need some reconfiguration on
> our side, if it does. Please let me know so that I can act on this if
> you require it.
>
Yes, we need the trace file to exist at
http://{mirrorname}/debian/project/trace/{mirrorname} for our tools
(e.g. https://mirror-master.debian.org/status/mirror-status.html) to
work.
Cheers,
Julien
Bug#945236: mirror submission for mirror.infomaniak.com
On 4/20/20 4:36 PM, Julien Cristau wrote: > Control: tag -1 moreinfo > > On Thu, Nov 21, 2019 at 04:09:03PM +, Thomas Goirand wrote: >> Site: mirror.infomaniak.com > > Hi, > > while checking this for inclusion our tools found that: > > o trace file: > I notice there is no tracefile matching your site name > mirror.infomaniak.com in > http://mirror.infomaniak.com/debian/project/trace/ > > Please use our ftpsync script to mirror Debian. That's what I use. I even wrote a puppet module packaged in Debian for it, which installs and configures the ftpsync package (see the Debian package puppet-module-debian-archvsync). The trace correctly lists: "ver1-debmirror-1.infomaniak.ch" That's the hostname of the machine, however, this doesn't match the public IP address, which resolves using mirror1.infomaniak.com. Is this a problem? You'll notice this on our 2nd mirror too: http://mirror2.infomaniak.com/debian/project/trace/_traces Also note that, as discussed earlier, you only want to list: mirror1.infomaniak.com mirror2.infomaniak.com rather than the alias that resolve to both: mirror.infomaniak.com as server 2 does ftpsync to the first one (they don't use a shared storage, so mirror2 is updated only after mirror1 is synced). > It should produce the trace files we require, and do the mirroring in a way > that ensures the mirror is in a consistent state even during updates. > > http://mirror.infomaniak.com/debian/project/ftpsync/ftpsync-current.tar.gz > > You might need to set MIRRORNAME in the ftpsync config to the name you > wish to have appear in the mirror list. Is it mandatory that it matches? This would need some reconfiguration on our side, if it does. Please let me know so that I can act on this if you require it. Cheers, Thomas Goirand (zigo)
Bug#958426: ITP: golang-github-containers-common -- Location for shared common files in github.com/containers repos.
Package: wnpp Severity: wishlist Owner: Reinhard Tartler * Package name: golang-github-containers-common Version : 0.8.1-1 Upstream Author : Containers * URL : https://github.com/containers/common * License : Apache-2.0 Programming Lang: Go Description : Location for shared common files in github.com/containers repos. This package contains shared common files and common go code to manage those files in github.com/containers repos. containers/common Location for shared common files and common go code to manage those files in github.com/containers repos. . The common files to one or more projects in the containers group will be kept in this repository. It will be up to the individual projects to include the files from this repository.
Bug#956092: [ftpmas...@ftp-master.debian.org: r-bioc-rgadem_2.34.1-1_amd64.changes REJECTED]
Hi, Charles Plessy is sorting out this licensing issue with upstream. Kind regards Andreas. - Forwarded message from Scott Kitterman - Date: Tue, 07 Apr 2020 21:00:10 + From: Scott Kitterman To: Andreas Tille , Debian R Packages Maintainers Subject: r-bioc-rgadem_2.34.1-1_amd64.changes REJECTED This is going to have to go in non-free as is. See src/evalue_meme.*: /*Copyright (c) 1994-2006 The Regents of the University of */ /*California. All Rights Reserved. */ /**/ /*Permission to use, copy, modify, and distribute any part */ /*of this software for educational, research and non-profit */ /*purposes, without fee, and without a written agreement is */ /*hereby granted, provided that the above copyright notice, */ /*this paragraph and the following three paragraphs appear in */ /*all copies. */ /**/ /*Those desiring to incorporate this software into commercial */ /*products or use for commercial purposes should contact the */ /*Technology Transfer Office, University of California, San */ /*Diego, 9500 Gilman Drive, La Jolla, California, 92093-0910, */ /*Phone: (858) 534-5815. ... The no commercial use clause fails DFSG. Packages which depend on this package but are otherwise FOSS will have to be uploaded to contrib. Scott K === Please feel free to respond to this email if you don't understand why your files were rejected, or if you upload new files which address our concerns. ___ R-pkg-team mailing list r-pkg-t...@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/r-pkg-team - End forwarded message - -- http://fam-tille.de
Bug#834724:
Bug#958425: /bin/gzexe: gzexe stub broken (wrong skip=)
Package: gzip Version: 1.9-3 Severity: normal File: /bin/gzexe Tags: upstream Dear Maintainer, skip= is wrong since 5 lines were added (case $TMPDIR ... esac) Introduced by v1.8-52-g63aa226 Fixed by v1.10-5-g38ae6a4 So both 1.9 (stable) and 1.10 (testing/unstable) are buggy. -- System Information: Debian Release: 10.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-0.bpo.3-amd64 (SMP w/12 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=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 gzip depends on: ii dpkg 1.19.7 ii install-info 6.5.0.dfsg.1-4+b1 ii libc6 2.28-10 gzip recommends no packages. Versions of packages gzip suggests: ii less 487-0.1+b1 -- no debconf information
Bug#943981: Proposal: Switch to cgroupv2 by default
Am 21.04.20 um 15:40 schrieb Ryutaroh Matsumoto: > My guess is that /var/lib/lxc/autopkgtest-sid/config needs > lxc.init.cmd = /sbin/init systemd.unified_cgroup_hierarchy=1 Indeed. While I updated /etc/lxc/default.conf, it seems "autopkgtest-build-lxc debian sid" did not update the existing /var/lib/lxc/autopkgtest-sid/config. Once I destroyed the container and created it anew, it worked. It's a bit unfortunate, that when you boot your system with the unified hierarchy, you need to explicitly configure "lxc.init.cmd = /sbin/init systemd.unified_cgroup_hierarchy=1" or hope the host systemd instance has been built with unified hierarchy as default. That means, once we flip the default in unstable/testing, creating and running a buster container will require "lxc.init.cmd = /sbin/init systemd.unified_cgroup_hierarchy=1" Would be nice if lxc could do that automatically. Or is there maybe a while to update lxc-templates to influence that? signature.asc Description: OpenPGP digital signature
Bug#955715: adios: FTBFS (error: could not find mpi library for Fortran)
Control: severity -1 serious The transition has started, raising the severity accordingly. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#943981: Proposal: Switch to cgroupv2 by default
Am 21.04.20 um 22:21 schrieb Michael Biebl: > Or is there maybe a while to update lxc-templates to influence that? ... a way to signature.asc Description: OpenPGP digital signature
Bug#958424: php-defaults breaks php-sabredav autopkgtest: Trying to access array offset on value of type bool
Source: php-defaults, php-sabredav Control: found -1 php-defaults/75 Control: found -1 php-sabredav/1.8.12-8 Severity: serious Tags: sid bullseye X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: breaks needs-update Dear maintainer(s), With a recent upload of php-defaults the autopkgtest of php-sabredav fails in testing when that autopkgtest is run with the binary packages of php-defaults from unstable. It passes when run with only packages from testing. In tabular form: passfail php-defaults from testing75 php-sabredav from testing1.8.12-8 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of php-defaults to testing [1]. Due to the nature of this issue, I filed this bug report against both packages. Can you please investigate the situation and reassign the bug to the right package? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=php-defaults https://ci.debian.net/data/autopkgtest/testing/amd64/p/php-sabredav/5082295/log.gz There were 2 errors: 1) Sabre\DAV\Auth\Backend\AbstractDigestTest::testAuthenticateNoHeaders Trying to access array offset on value of type bool /usr/share/php/Sabre/HTTP/DigestAuth.php:125 /usr/share/php/Sabre/DAV/Auth/Backend/AbstractDigest.php:61 /tmp/autopkgtest-lxc.r33sttz0/downtmp/build.m2T/src/tests/Sabre/DAV/Auth/Backend/AbstractDigestTest.php:22 2) Sabre\HTTP\DigestAuthTest::testInvalidDigest2 Trying to access array offset on value of type bool /usr/share/php/Sabre/HTTP/DigestAuth.php:136 /usr/share/php/Sabre/HTTP/DigestAuth.php:100 /tmp/autopkgtest-lxc.r33sttz0/downtmp/build.m2T/src/tests/Sabre/HTTP/DigestAuthTest.php:164 signature.asc Description: OpenPGP digital signature
Bug#958423: php-defaults breaks php-codecoverage autopkgtest: Class 'DOMDocument' not found
Source: php-defaults, php-codecoverage Control: found -1 php-defaults/75 Control: found -1 php-codecoverage/7.0.10+dfsg-1 Severity: serious Tags: sid bullseye X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: breaks needs-update Dear maintainer(s), With a recent upload of php-defaults the autopkgtest of php-codecoverage fails in testing when that autopkgtest is run with the binary packages of php-defaults from unstable. It passes when run with only packages from testing. In tabular form: passfail php-defaults from testing75 php-codecoverage from testing7.0.10+dfsg-1 all others from testingfrom testing I copied some of the output at the bottom of this report. The autopkgtest passes in unstable, so it seems that php-defaults needs to migrate together with some other package at the same time, but there's no package relation in place to force that. I reported a similar error message in bug #953727, but that was re-assigned to xdebug. Currently this regression is blocking the migration of php-defaults to testing [1]. Due to the nature of this issue, I filed this bug report against both packages. Can you please investigate the situation and reassign the bug to the right package? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=php-defaults https://ci.debian.net/data/autopkgtest/testing/amd64/p/php-codecoverage/5030079/log.gz autopkgtest [14:13:53]: test command1: mkdir --parents vendor ; cp debian/autoload.php vendor ; phpunit autopkgtest [14:13:53]: test command1: [--- Class 'DOMDocument' not found autopkgtest [14:13:54]: test command1: ---] signature.asc Description: OpenPGP digital signature
Bug#956842: printrun: FTBFS with python 3.8
Hi, I need that package too, but it won't install right now. Please consider fixing it.
Bug#958296: openvpn 2.4.9 seems to fail loading/reading client certificates
Am 21.04.20 um 21:41 schrieb Jonas Andradas: Hi, > > Anyway, if you want me to try a patched test-build, I would be > happy to > > (and preferred, as I can do that quickly, but would take a bit > more time > > to prepare a build environment to build the package myself). > > A patched build can be retrieved here: > > > https://people.debian.org/~berni/openvpn/openvpn_2.4.9-2~1.gbp727e40_amd64.deb > > > I have downloaded and tested the patch, with the following results > regarding the value of "MinProtocol" in /etc/ssl/openssl.cnf: > > - MinProtocol = TLSv1 -- WORKS > - MinProtocol = TLSv1.0 -- WORKS (was not working before the patch) > - MinProtocol = TLSv1.2 -- WORKS (Debian default) Cewl, I'll upload 2.4.9-2 shortly. @Jonas: Thanks for testing @Arne: Thanks for debugging and patching. Bernhard
Bug#958173: buster-pu: package lxc-templates/3.0.3-1
Le mardi 21 avril 2020 à 21:21:28+0200, Andreas Beckmann a écrit : > > Stripping all useless commits, here is the Debdiff I get. > > > > Note that the version isn't 3.0.4-3~deb10u1 as 3.0.4-3 contains only > > packaging changes that I didn't include. > > > > Should you wish me to release 3.0.4-3~deb10u1, we would have to make an > > empty changelog for 3.0.4-3 over which I could do the changelog entry to > > release into buster. > > A version generally used in this case would be 3.0.4-0+deb10u1 with the > changelog entries squashed together. It's no longer a plain "rebuild", > but a new upstream release + selected cherry-picked bugfixes without > inappropriate packaging changes. > (mariadb and postgresql are prominent users of this scheme.) Thanks, here is a debdiff that should fit then. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. diff -Nru lxc-templates-3.0.3/configure lxc-templates-3.0.4/configure --- lxc-templates-3.0.3/configure 2018-11-23 01:48:22.0 +0100 +++ lxc-templates-3.0.4/configure 2019-06-22 00:57:26.0 +0200 @@ -1,6 +1,6 @@ #! /bin/sh # Guess values for system-dependent variables and create Makefiles. -# Generated by GNU Autoconf 2.69 for lxc-templates 3.0.3. +# Generated by GNU Autoconf 2.69 for lxc-templates 3.0.4. # # # Copyright (C) 1992-1996, 1998-2012 Free Software Foundation, Inc. @@ -577,8 +577,8 @@ # Identity of this package. PACKAGE_NAME='lxc-templates' PACKAGE_TARNAME='lxc-templates' -PACKAGE_VERSION='3.0.3' -PACKAGE_STRING='lxc-templates 3.0.3' +PACKAGE_VERSION='3.0.4' +PACKAGE_STRING='lxc-templates 3.0.4' PACKAGE_BUGREPORT='' PACKAGE_URL='' @@ -1321,7 +1321,7 @@ # Omit some internal or obsolete options to make the list less imposing. # This message is too long to be a string in the A/UX 3.1 sh. cat <<_ACEOF -\`configure' configures lxc-templates 3.0.3 to adapt to many kinds of systems. +\`configure' configures lxc-templates 3.0.4 to adapt to many kinds of systems. Usage: $0 [OPTION]... [VAR=VALUE]... @@ -1392,7 +1392,7 @@ if test -n "$ac_init_help"; then case $ac_init_help in - short | recursive ) echo "Configuration of lxc-templates 3.0.3:";; + short | recursive ) echo "Configuration of lxc-templates 3.0.4:";; esac cat <<\_ACEOF @@ -1500,7 +1500,7 @@ test -n "$ac_init_help" && exit $ac_status if $ac_init_version; then cat <<\_ACEOF -lxc-templates configure 3.0.3 +lxc-templates configure 3.0.4 generated by GNU Autoconf 2.69 Copyright (C) 2012 Free Software Foundation, Inc. @@ -1752,7 +1752,7 @@ This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. -It was created by lxc-templates $as_me 3.0.3, which was +It was created by lxc-templates $as_me 3.0.4, which was generated by GNU Autoconf 2.69. Invocation command line was $ $0 $@ @@ -2615,7 +2615,7 @@ # Define the identity of the package. PACKAGE='lxc-templates' - VERSION='3.0.3' + VERSION='3.0.4' cat >>confdefs.h <<_ACEOF @@ -6134,7 +6134,7 @@ # report actual input values of CONFIG_FILES etc. instead of their # values after options handling. ac_log=" -This file was extended by lxc-templates $as_me 3.0.3, which was +This file was extended by lxc-templates $as_me 3.0.4, which was generated by GNU Autoconf 2.69. Invocation command line was CONFIG_FILES= $CONFIG_FILES @@ -6195,7 +6195,7 @@ cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1 ac_cs_config="`$as_echo "$ac_configure_args" | sed 's/^ //; s/[\\""\`\$]/&/g'`" ac_cs_version="\\ -lxc-templates config.status 3.0.3 +lxc-templates config.status 3.0.4 configured by $0, generated by GNU Autoconf 2.69, with options \\"\$ac_cs_config\\" diff -Nru lxc-templates-3.0.3/configure.ac lxc-templates-3.0.4/configure.ac --- lxc-templates-3.0.3/configure.ac2018-11-23 01:48:17.0 +0100 +++ lxc-templates-3.0.4/configure.ac2019-06-22 00:57:21.0 +0200 @@ -1,7 +1,7 @@ # -*- Autoconf -*- # Process this file with autoconf to produce a configure script. -AC_INIT([lxc-templates], [3.0.3]) +AC_INIT([lxc-templates], [3.0.4]) AM_INIT_AUTOMAKE # We need pkg-config diff -Nru lxc-templates-3.0.3/debian/changelog lxc-templates-3.0.4/debian/changelog --- lxc-templates-3.0.3/debian/changelog2018-12-04 08:47:01.0 +0100 +++ lxc-templates-3.0.4/debian/changelog2020-04-21 21:54:06.0 +0200 @@ -1,3 +1,12 @@ +lxc-templates (3.0.4-0+deb10u1) buster; urgency=medium + + * New upstream release 3.0.4 + * d/lxc-templates.lintian-overrides: Disable warning for access to dpkg DB + * d/p/0001: [lxc-debian] Handle languages that are only UTF-8 encoded +(Closes: #950840) + + -- Pierre-Elliott Bécue Tue, 21 Apr 2020 21:54:06 +0200 + lxc-templates (3.0.3-1) unstable; urgency=medium * d/control:
Bug#943981: Proposal: Switch to cgroupv2 by default
Control: unblock -1 by 934372 Since the severity of 934372 became minor, I believe that 934372 does not block this bug. Ryutaroh
Bug#958421: node-cli-boxes breaks node-boxen autopkgtest: TypeError: Invalid border style: single-double
Source: node-cli-boxes, node-boxen
Control: found -1 node-cli-boxes/2.2.0-2
Control: found -1 node-boxen/1.3.0-1
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update
Dear maintainer(s),
With a recent upload of node-cli-boxes the autopkgtest of node-boxen
fails in testing when that autopkgtest is run with the binary packages
of node-cli-boxes from unstable. It passes when run with only packages
from testing. In tabular form:
passfail
node-cli-boxes from testing2.2.0-2
node-boxen from testing1.3.0-1
all others from testingfrom testing
I copied some of the output at the bottom of this report. As the
autopkgtest succeeds in unstable and node-boxen is blocked by the
migration of node-cli-boxen, I strongly believe that a *versioned*
(test) dependency and/or breaks is missing somewhere. If node-cli-boxes
really breaks node-boxen 1.3.0-1, it should add a versioned breaks.
After that, the migration software will test the combination from
unstable for the migration.
Currently this regression is blocking the migration of node-cli-boxes to
testing [1]. Due to the nature of this issue, I filed this bug report
against both packages. Can you please investigate the situation and
reassign the bug to the right package?
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[1] https://qa.debian.org/excuses.php?package=node-cli-boxes
https://ci.debian.net/data/autopkgtest/testing/amd64/n/node-boxen/5068858/log.gz
/usr/share/nodejs/boxen/index.js:48
throw new TypeError(`Invalid border style:
${borderStyle}`);
^
TypeError: Invalid border style: single-double
at getBorderChars (/usr/share/nodejs/boxen/index.js:48:10)
at module.exports (/usr/share/nodejs/boxen/index.js:86:16)
at Test.t
(/tmp/autopkgtest-lxc.ytsynf20/downtmp/autopkgtest_tmp/smokeAc3ms5/test.js:196:13)
at Test.bound [as _cb] (/usr/lib/nodejs/tape/lib/test.js:87:32)
at Test.run (/usr/lib/nodejs/tape/lib/test.js:106:10)
at Test.bound [as run] (/usr/lib/nodejs/tape/lib/test.js:87:32)
at Immediate.next (/usr/lib/nodejs/tape/lib/results.js:71:15)
at runCallback (timers.js:705:18)
at tryOnImmediate (timers.js:676:5)
at processImmediate (timers.js:658:5)
signature.asc
Description: OpenPGP digital signature
Bug#910573: New upstream version 3.28
It seems like all the required packages are in Debian now. I'd love to see this an update of latexila to gnome-latex in Debian too! I tried to do this myself on my local machine, but completely failed somewhere in the renaming process. On Mon, 08 Oct 2018 10:45:38 +0200 Tanguy Ortolo < tanguy+deb...@ortolo.eu> wrote: > Package: latexila > Severity: wishlist > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > For myself, and to track dependencies to other packages: there is a new > version of LaTeXila available, now renamed GNOME LaTeX 3.28. It has > updated dependencies which will require some work on other packages. > > - -- System Information: > Debian Release: 8.11 > APT prefers oldstable > APT policy: (990, 'oldstable'), (500, 'stable-updates'), (500, 'oldstable-updates'), (500, 'stable') > Architecture: amd64 (x86_64) > > Kernel: Linux 4.9.0-6-amd64 (SMP w/4 CPU cores) > Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > -BEGIN PGP SIGNATURE- > > iQJMBAEBCgA2FiEEC1QNJk2lrQnjLj0t6vLNUcUAaBkFAlu7GS4YHHRhbmd1eStk > ZWJpYW5Ab3J0b2xvLmV1AAoJEOryzVHFAGgZ4TMQAIKExRfRr/4MYghHZbvtLM6r > TJiDigWF3Pe3pSOyhFn0kF30SUaOTON7GVIYTzjT43Uq3dAta3XN9ENUULOxr7uw > W32du+ANCAlEF4SLPN8T5OyINgSRMBjED8DedcBRdtHV049sBxzp9lKc2zB3AIy7 > RLONb58X7euySFHXiJDTecib3pL6XHu5FgkAlgUL0wQc3+UcPWmiZVGl3PN9VOLM > uKtWUm5e0dCI5OAs+fY8b7KRhm5ZUD7tshhtr+o+cfdHelPlu6jW7QDZR762V4dB > 3RSoaunKM0rpUjl6nGqV7GBS8rhUoBFrHBQ5ZIgC/PQtfBn2fXwxt1chheDdTpGz > sj50hSs2myp/0mCGJpMUfUAgk1QaX8p2SeKTTDKqr1rR0LwSvpPaY0eARnVtB3hN > fd5h6r9L+jIT3pXfFd9ljnInlBoZdTqpoNEANO5s3Bdld8rYDUrfeWjYk0Vi5hsD > fLGtiOCBDMYgiZ8Ouu9BW2HCe6lM9kxRS6nW0bKZynyUuXIslO/47UTHO/7mVi2s > Oa8JsXVxlg9lCZhPJtdBaw3VRWikyWyV8M+yhJKN5eoOLO1VjfVR8X+NWg7Rcm4A > 2bHcO/iMc7q5/JRz2OKWvGQd3+e24+LRVgcUJV8mYMhyf3R5zPcVHvLNln5LPqZ4 > k4XisyUqwDKA9ytGHj6t > =0U5y > -END PGP SIGNATURE- > > -- Rann Bar-On Senior Lecturer Dept of Mathematics Duke University Pronouns: he/him/his
Bug#956374: transition: poco
Control: tag -1 + confirmed Control: forwarded -1 https://release.debian.org/transitions/html/auto-poco.html On 2020-04-10 14:38:11, Jochen Sprickerhof wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > Hi Release team, > > I would like to transition to the new poco version from experimental. > All reverse dependencies build with it and I don't expect other > problems. Please go ahead. Cheers -- Sebastian Ramacher
Bug#958418: thunderbird: Clicking links does no longer work
Package: thunderbird Version: 1:68.7.0-1 Severity: important Whenever I click on a hyperlink, like inside a message, or even at the "Mozilla"-Link of the "Help > About Thunderbird" dialog, the link will not be opened by my browser. Instead, "Verifying the feed..." gets displayed at the taskbar, immediately followd by "https://mozilla.org/ is not a valid feed." It seems that Thunderbird handles all links as if they were feeds. Error Console (Ctrl+Shift+J) dump: > ML Parsing Error: syntax error > Location: https://www.mozilla.org/en-US/ > Line Number 5, Column 1: en-US:5:1 > 2020-04-21 21:36:50 Feeds INFOFeedParser.parseFeed: - XML Parsing > Error: syntax error > Location: https://www.mozilla.org/en-US/ > Line Number 5, Column 1: > > ^ > > 2020-04-21 21:36:50 Feeds WARNdownloaded: updates disabled due to > error, check the url - https://www.mozilla.org/ > > 2020-04-21 21:36:50 Feeds INFOdownloaded: Subscribe: Feeds -> > https://www.mozilla.org/ is not a valid feed. Not being able to open links by clicking on them but being forced to copy them over into the browser is a major usability issue. I am able to reproduce this bug with a fresh profile. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (50, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-4-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=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 thunderbird depends on: ii debianutils 4.9.1 ii fontconfig2.13.1-2+b1 ii libatk1.0-0 2.36.0-2 ii libc6 2.30-4 ii libcairo-gobject2 1.16.0-4 ii libcairo2 1.16.0-4 ii libdbus-1-3 1.12.16-2 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-2+b1 ii libfreetype6 2.10.1-2 ii libgcc-s1 10-20200411-1 ii libgdk-pixbuf2.0-02.40.0+dfsg-4 ii libglib2.0-0 2.64.1-1 ii libgtk-3-03.24.18-1 ii libgtk2.0-0 2.24.32-4 ii libicu63 63.2-3 ii libjsoncpp1 1.7.4-3.1 ii libnspr4 2:4.25-1 ii libnss3 2:3.51-1 ii libpango-1.0-01.44.7-3 ii libsqlite3-0 3.31.1-4 ii libstartup-notification0 0.12-6 ii libstdc++610-20200411-1 ii libvpx6 1.8.2-1 ii libx11-6 2:1.6.9-2 ii libx11-xcb1 2:1.6.9-2 ii libxcb-shm0 1.14-2 ii libxcb1 1.14-2 ii libxext6 2:1.3.3-1+b2 ii libxrender1 1:0.9.10-1 ii libxt61:1.1.5-1+b3 ii psmisc23.3-1 ii x11-utils 7.7+5 ii zlib1g1:1.2.11.dfsg-2 Versions of packages thunderbird recommends: ii hunspell-de-de [hunspell-dictionary] 20161207-7 ii hunspell-en-us [hunspell-dictionary] 1:2019.10.06-1 ii lightning 1:68.7.0-1 Versions of packages thunderbird suggests: ii apparmor 2.13.4-1+b1 pn fonts-lyx ii libgssapi-krb5-2 1.17-7 -- no debconf information
Bug#958419: swi-prolog breaks eye autopkgtest: Failed 7/15 subtests
Source: swi-prolog, eye Control: found -1 swi-prolog/8.1.28+dfsg-1 Control: found -1 eye/19.0928.2249~ds-1 Severity: serious Tags: sid bullseye X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: breaks needs-update Dear maintainer(s), With a recent upload of swi-prolog the autopkgtest of eye fails in testing when that autopkgtest is run with the binary packages of swi-prolog from unstable. It passes when run with only packages from testing. In tabular form: passfail swi-prolog from testing8.1.28+dfsg-1 eyefrom testing19.0928.2249~ds-1 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of swi-prolog to testing [1]. Due to the nature of this issue, I filed this bug report against both packages. Can you please investigate the situation and reassign the bug to the right package? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=swi-prolog https://ci.debian.net/data/autopkgtest/testing/amd64/e/eye/5057663/log.gz autopkgtest [05:57:12]: test command1: prove debian/tests/*.t autopkgtest [05:57:12]: test command1: [--- # Failed test 'Process terminated without a signal' # at debian/tests/eye.pvm.t line 9. # got: '6' # expected: '0' # Failed test 'bare command, stderr' # at debian/tests/eye.pvm.t line 11. # '[FATAL ERROR: at Sun Apr 19 05:57:12 2020 # /usr/bin/eye.pvm: incompatible version (file: 66, Prolog: 67)] # ' # doesn't match '(?^:Usage: eye.pvm)' # Failed test 'Process terminated without a signal' # at debian/tests/eye.pvm.t line 13. # got: '6' # expected: '0' # Failed test 'help, stderr' # at debian/tests/eye.pvm.t line 15. # '[FATAL ERROR: at Sun Apr 19 05:57:12 2020 # /usr/bin/eye.pvm: incompatible version (file: 66, Prolog: 67)] # ' # doesn't match '(?^:Usage: eye.pvm)' # Failed test 'Process terminated without a signal' # at debian/tests/eye.pvm.t line 17. # got: '6' # expected: '0' # Failed test 'help, stderr' # at debian/tests/eye.pvm.t line 18. # '' # doesn't match '(?^:r:because)' # Failed test 'help, stderr' # at debian/tests/eye.pvm.t line 19. # '[FATAL ERROR: at Sun Apr 19 05:57:12 2020 # /usr/bin/eye.pvm: incompatible version (file: 66, Prolog: 67)] # ' # doesn't match '(?^s:starting .*\nGET .*\nnetworking .*\nreasoning)' # Looks like you failed 7 tests of 15. debian/tests/eye.pvm.t .. Dubious, test returned 7 (wstat 1792, 0x700) Failed 7/15 subtests Test Summary Report --- debian/tests/eye.pvm.t (Wstat: 1792 Tests: 15 Failed: 7) Failed tests: 2, 5, 7, 10, 12, 14-15 Non-zero exit status: 7 Files=1, Tests=15, 0 wallclock secs ( 0.03 usr 0.00 sys + 0.06 cusr 0.01 csys = 0.10 CPU) Result: FAIL autopkgtest [05:57:13]: test command1: ---] signature.asc Description: OpenPGP digital signature
Bug#958420: ITP: ruby-jekyll-asciidoc -- Jekyll plugin to convert AsciiDoc source files to HTML pages
Package: wnpp Severity: wishlist Owner: Daniel Leidert -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: ruby-jekyll-asciidoc Version : 3.0.0 Upstream Author : Dan Allen, Paul Rayner, and the Asciidoctor Project * URL : https://github.com/asciidoctor/jekyll-asciidoc * License : MIT Programming Lang: Ruby Description : Jekyll plugin to convert AsciiDoc source files to HTML pages This plugin converts eligible AsciiDoc files located inside the source directory to HTML pages in the generated site. It consists of three plugins: . (1) a Converter to convert AsciiDoc source files to the HTML pages, (2) a Generator to promote AsciiDoc attributes to page variables, and (3) Liquid filters. . Any AsciiDoc attribute defined in the document header whose name begins with 'page-' gets promoted to a page variable. The value is then processed as YAML data. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAl6fTm8ACgkQS80FZ8KW 0F31IhAAuf9gn0nwehU7XIshNq3uEVs5zIuZv7Yz+nbSQR+mKww6t0KAu5GHgcZH DUi9Yp6mklRdG37UKvmvOdBkvtuS0DZyPxwRS4E1WNRVp3DJoieCK3QpoVOuxHMR AkQq0FzF4WrkDz+x5SW9dhwm0UHslFJdYr5PEiQBhkONflSJm0sz+uzHMToa+Itw foXEUE1KWnpIqHx+1bJR/Ze2BvtzKm/9J5ARHtvXwuTyFkfJV33ZC7gUpKS68FKT V9yN0uSwAH8LU/h/yKlXdPj0Oj/+bX7g5gKzxAiL5pHOOoqN3xNXkACP7D6EvEme 4hNT0VWZJHEO93tMp+8CASbZISKSUFDh3SyXzUZlfQXTEfXZlBZH4ZHXUGxQTjae hvfdx3LY4Zo56GGDmVX5/RFqGlRT4I0qEShKNkoiVYU7/q4nj6lHLql2brc0Fww3 CrtG+8Nhir4etMnfVUUepDXcx9zVdyzDhZCBFMy5I7VZv0V35IXjmtmP6JLORkMU heEf0O0EonRsBAtbpV2yAJDbo3j1grLb0hTQWnefHIf53Vy3r3dO+I7eUT6NIKEA fFb78sF8NHttP6BlmPx+htakZU2/bPxQvrK132xbOWqDq/13qzKM+H7QbZdlGMpm 4fRgQHYfPZYqeSAUZR57eyxLV/IgdODBqmmuLNZ3EH9w61wOg28= =ABaN -END PGP SIGNATURE-
Bug#955807: transition: netcdf
Control: tags -1 + confirmed On 2020-04-05 08:26:10, Bas Couwenberg wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > Control: forwarded -1 > https://release.debian.org/transitions/html/auto-netcdf.html > Control: block -1 by 955715 955749 955806 > > NetCDF bumped it SONAME requiring a transition. > > Most rdeps built successfully except adios, oasis3 & metview as > summarized below. > > > Transition: netcdf > > libnetcdf15 (1:4.7.3-1+b1) -> libnetcdf18 (1:4.7.4-1~exp2) > > The status of the most recent rebuilds is as follows. > > adios (1.13.1-21)FTBFS (#955715) > cmor (3.5.0-3) OK > coda (2.21-4) SKIP (B-D only) > dx (1:4.4.4-12) OK > eccodes(2.17.0-1) OK > exodusii (6.02.dfsg.1-8)OK > gdal (3.0.4+dfsg-1) OK > gerris (20131206+dfsg-19) SKIP (B-D only) > grace (1:5.1.25-7) OK > grads (3:2.2.1-2)OK > gri(2.12.26-1)SKIP (B-D only) > kst(2.0.8-3) SKIP (B-D only) > labplot(2.7.0-1) OK > libminc(2.4.03-2) OK > libpdl-netcdf-perl (4.20-6) OK > nco(4.9.1-1) OK > ncview (2.1.8+ds-3) OK > netcdf-cxx (4.3.1-2) OK > netcdf-cxx-legacy (4.2-11) OK > netcdf-fortran (4.5.2+ds-1) OK > netcdf4-python (1.5.3-1) OK > octave-netcdf (1.0.13-1) OK > r-cran-ncdf4 (1.17-1) OK > r-cran-rnetcdf (2.1-1-1) OK > ruby-netcdf(0.7.2-3) OK > v-sim (3.7.2-8) OK > > cdftools (3.0.2-4) SKIP (B-D only) > deal.ii(9.1.1-9) SKIP (B-D only) > emoslib(2:4.5.9-3)SKIP (B-D only) > etsf-io(1.0.4-4) SKIP (B-D only) > ferret-vis (7.5.0-2) OK > gmt(6.0.0+dfsg-1) OK > gnudatalanguage(0.9.9-12) OK > grass (7.8.2-1) OK > harp (1.9.2-1) OK > minc-tools (2.3.00+dfsg-3)OK > ncl(6.6.2-1) OK > oasis3 (3.mct+dfsg.121022-14) FTBFS (#955749) > paraview (5.7.0-4) SKIP (B-D only) > python-escript (5.5-5)SKIP (B-D only) > vtk6 (6.3.0+dfsg2-5)OK > vtk7 (7.1.1+dfsg2-2)OK > > lammps (20191120+dfsg1-2) OK > odb-api(0.18.1-10)SKIP (B-D only) > pyferret (7.5.0-5) OK > qgis (3.10.4+dfsg-1)OK > > magics++ (4.3.0-1) OK > > cdo(1.9.9~rc2-1) OK > metview(5.8.1-2) FTBFS (#955806) Please go ahead. Cheers -- Sebastian Ramacher
Bug#958141: buster-pu: package xdg-utils/1.1.3-1
On Tue, Apr 21, 2020 at 07:07:59PM +0100, Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Sat, 2020-04-18 at 23:53 +0300, Nicholas Guriev wrote: > > There are a number of bugs fixed in the 1.1.3-2 version of the xdg- > > utils package that now is available in testing and unstable archives. > > It would be good to have the fixes in buster also. > > > > If you think these changes are okay for stable update, please > > consider to sponsor upload to stable-proposed-updates. > > The Release Team don't generally sponsor uploads to stable, but feel > free to go ahead and get it uploaded. I can upload that. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#958296: openvpn 2.4.9 seems to fail loading/reading client certificates
Hello Bernhard, On Tue, Apr 21, 2020 at 5:06 PM Bernhard Schmidt wrote: > Hi Jonas, > > > Anyway, if you want me to try a patched test-build, I would be happy to > > (and preferred, as I can do that quickly, but would take a bit more time > > to prepare a build environment to build the package myself). > > A patched build can be retrieved here: > > > https://people.debian.org/~berni/openvpn/openvpn_2.4.9-2~1.gbp727e40_amd64.deb > > I have downloaded and tested the patch, with the following results regarding the value of "MinProtocol" in /etc/ssl/openssl.cnf: - MinProtocol = TLSv1 -- WORKS - MinProtocol = TLSv1.0 -- WORKS (was not working before the patch) - MinProtocol = TLSv1.2 -- WORKS (Debian default) > Bernhard > Best Regards, Jonas.
Bug#918727: [Pkg-openssl-devel] Bug#918727: Bug#918727: openssl.cnf incompatible with libssl1.0.2, libssl1.0.0
On Tue, Apr 21, 2020 at 09:18:05PM +0200, Sebastian Andrzej Siewior wrote: > On 2020-04-15 13:38:23 [+0200], Kurt Roeckx wrote: > > On Wed, Apr 15, 2020 at 12:19:24PM +0100, Simon McVittie wrote: > > > > > > I think setting defaults in the shared library itself would be more > > > robust, and if a configuration file to override that is necessary, > > > > This is also the route that Ubuntu took, because it's possible to > > install the library without the openssl package. I think we should > > do this too. > > > > It causes various issues with the test suite because SHA1 is used > > for various tests. But I think that has been fixed in master, or has a > > pull request. > > > > I would like to drop SHA1 support in testing/unstable anyway, so I > > think we should merge those patches once they've all been merged. > > Ehm. I read this a few times but I have no idea what we are going to do. > Could you please enlighten me? It's about building with -DOPENSSL_TLS_SECURITY_LEVEL=2, and something like the patch I've used before to set the default TLS version, instead of having both in openssl.cfg. Setting it in the config file should override the build time defaults. Building with that set will cause testsuite errors. Some of those are because SHA1 is being used. In the master branch, things are changing so that SHA1 isn't allowed at security level 1 anymore. For the next release, if we're not shipping 3.0, I would like to at least change that. Kurt
Bug#958370: golang-github-dgrijalva-jwt-go-v3: Remove this package from archive
Hi Nobuhiro, On Tue, Apr 21, 2020 at 11:09 AM Shengjing Zhu wrote: [...] > src:golang-github-dgrijalva-jwt-go/3.2.0-1 has been uploaded to archive > for a long time. It's time to retire this > golang-github-dgrijalva-jwt-go-v3 package. > > The following packages have direct build-depends on > golang-github-dgrijalva-jwt-go-v3-dev: > > # build-rdeps --old golang-github-dgrijalva-jwt-go-v3-dev > goval-dictionary > vuls Now only src:goval-dictionary and src:vuls have build-depends on golang-github-dgrijalva-jwt-go-v3-dev. Actually they both don't need this library, just removing golang-github-dgrijalva-jwt-go-v3-dev from d/control is enough. So my question is, since they are both in unstable and experimental, Can I just upload the version in experimental to unstable? Thanks. -- Shengjing Zhu
Bug#958364: Subject: RFS: libtpms/0.8.0~dev1-1 [ITP] -- TPM emulation library
Control: tags -1 +moreinfo
Hi Seunghun,
Thanks for working on libtpms packaging in Debian and taking over maintenance.
I sponsored the previous upload at
https://ftp-master.debian.org/new/libtpms_0.7.0-1.html .
After looking into your packaging, I think there are some issues as listed
below. Please consider solving them and remove the "moreinfo" tag afterwards.
* This one is critical: With new package, *NEVER* override dh_usrlocal in
debian/rules file. Debian package should not ship files under /usr/local/. If
there are special reasons about handling /usr/local/, I'd be happy to know it.
* Please consider using "include /usr/share/dpkg/architecture.mk" instead of
manual invocation of dpkg-architecture to get the value of DEB_HOST_MULTIARCH
variable in debian/rules file.
* The "--with autoreconf" parameter is useless now since it is the default for
debhelper compatibility level 12.
* Please strip all old changelogs entries from debian/changelog; those old
parts are not part of Debian.
* This one is also critical: Please do not list ${misc:Pre-Depends} in the
Depends: field of libtpms0. Normally this variable substitution is not needed
now; if you really needed, please use "Pre-Depends: ${misc:Pre-Depends}"
instead.
* With your current debian/*.install files, there are absolutely no necessity
to build-depends on dh-exec. Please remove such dependency and remove
corresponding shebang in *.install files.
Let me know after you finish all those tweaks or if you have any questions.
--
Regards,
Boyuan Yang
在 2020-04-21星期二的 07:55 +0900，Seunghun Han写道：
> Package: sponsorship-requests
> Severity: wishlist
>
> Dear mentors,
>
> I am looking for a sponsor for my package "libtpms"
>
> * Package name: libtpms
>Version : 0.8.0~dev1-1
>Upstream Author : Stefan Berger
> * URL : https://github.com/stefanberger/libtpms
> * License : BSD-3-clause
> * Vcs : https://salsa.debian.org/kkamagui-guest/libtpms
>Section : libs
>
> It builds those binary packages:
>
> libtpms0 - TPM emulation library
> libtpms-dev - libtpms header files and man pages
>
> To access further information about this package, please visit the
> following URL:
>
> https://mentors.debian.net/package/libtpms
>
> Alternatively, one can download the package with dget using this command:
>
> dget -x
> https://mentors.debian.net/debian/pool/main/libt/libtpms/libtpms_0.8.0~dev1-1.dsc
>
> Changes since the last upload:
>
>* New maintainer (Closes: #958071)
>* Updated standards version to 4.5.0 in debian/control
>* Updated debhelper version to 12 in debian/control
>* Added Rules-Requires-Root to debian/control
>* Added Vcs-Browser and Vcs-Git to debian/control
>* Removed autotools-dev and dh-autoreconf from debian/control
>* Removed autotools-dev and parallel option from debian/rules
>* Converted debian/copyright to dep5-copyright format
>* Added debian/watch file
>* Added debian/libtpms.symbols file
>* Added debian/upstream/metadata file
>* Changed section of man pages from 1 to 3
>* Fixed typos and a long line warning in man pages
>* Set date of man pages to last changelog entry
>
> Regards,
>
> --
> Seunghun Han
>
signature.asc
Description: This is a digitally signed message part
Bug#955629: transition: pdal
Control: tags -1 + confirmed On 2020-04-03 18:09:21, Bas Couwenberg wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > Control: forwarded -1 > https://release.debian.org/transitions/html/auto-pdal.html > Control: block -1 by 955598 > > PDAL bumped its SONAME requiring a transition. > > All packages except python-pdal rebuilt successfully as summarized below. > > python-pdal won't be updated for PDAL 2.1, its removal from the archive > has been requested in #955598. > > I would like to do this after the hdf5 transition, as soon as the mpich > blocker is resolved. > > > Transition: pdal > > libpdal-base9 (2.0.1+ds-1+b2) -> libpdal-base10 (2.1.0+ds-1~exp1) > libpdal-util9 (2.0.1+ds-1+b2) -> libpdal-util10 (2.1.0+ds-1~exp1) > > The status of the most recent rebuilds is as follows. > > cloudcompare (2.10.3-4) OK > grass(7.8.2-1)OK > paraview (5.7.0-4)OK > python-pdal (2.2.2+ds-1) FTBFS python-pdal was removed and hdf5 is done, so please go ahead. Cheers -- Sebastian Ramacher
Bug#958173: buster-pu: package lxc-templates/3.0.3-1
> Stripping all useless commits, here is the Debdiff I get. > > Note that the version isn't 3.0.4-3~deb10u1 as 3.0.4-3 contains only > packaging changes that I didn't include. > > Should you wish me to release 3.0.4-3~deb10u1, we would have to make an > empty changelog for 3.0.4-3 over which I could do the changelog entry to > release into buster. A version generally used in this case would be 3.0.4-0+deb10u1 with the changelog entries squashed together. It's no longer a plain "rebuild", but a new upstream release + selected cherry-picked bugfixes without inappropriate packaging changes. (mariadb and postgresql are prominent users of this scheme.) Andreas (not a member of the release team)
Bug#918727: [Pkg-openssl-devel] Bug#918727: Bug#918727: openssl.cnf incompatible with libssl1.0.2, libssl1.0.0
On 2020-04-15 13:38:23 [+0200], Kurt Roeckx wrote: > On Wed, Apr 15, 2020 at 12:19:24PM +0100, Simon McVittie wrote: > > > > I think setting defaults in the shared library itself would be more > > robust, and if a configuration file to override that is necessary, > > This is also the route that Ubuntu took, because it's possible to > install the library without the openssl package. I think we should > do this too. > > It causes various issues with the test suite because SHA1 is used > for various tests. But I think that has been fixed in master, or has a > pull request. > > I would like to drop SHA1 support in testing/unstable anyway, so I > think we should merge those patches once they've all been merged. Ehm. I read this a few times but I have no idea what we are going to do. Could you please enlighten me? > > Kurt Sebastian
Bug#958417: new upstream version available
Package: mtail Severity: normal There's a new version of mtail available upstream. They're at rc35 at the time of writing and we're at rc24. The diff with the current debian head introduces the following new dependencies: 1. contrib.go.opencensus.io/exporter/jaeger 2. github.com/golang/groupcache/ 3. github.com/prometheus/common 4. go.opencensus.io/trace 5. go.opencensus.io/zpages 6. golang.org/x/sys/unix 2 and 3 are already packaged. I'm not sure about 6, i would assume so as well but i can't find it. there is *some* opencensus stuff packaged in debian (`golang-go.opencensus`) but i'm not sure it covers this. In any case, it would be great to see an update of mtail in Debian, and maybe it would fix all those pesky FTBFS bug reports.. -- System Information: Debian Release: 10.3 APT prefers stable-debug APT policy: (500, 'stable-debug'), (500, 'stable'), (1, 'experimental'), (1, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-8-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE=fr_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mtail depends on: ii adduser 3.118 ii daemon 0.6.4-1+b2 ii init-system-helpers 1.56+nmu1 ii libc62.28-10 ii tzdata 2019c-0+deb10u1 mtail recommends no packages. mtail suggests no packages.
Bug#958416: src:olive-editor: fails to migrate to testing for too long
Source: olive-editor Version: 2019-1 Severity: serious Control: close -1 20200210-1 Tags: sid bullseye User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 950564 Dear maintainer(s), As recently announced [1], the Release Team now considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing. Your package src:olive-editor in its current version in unstable has been trying to migrate for 60 days [2]. Hence, I am filing this bug. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bullseye, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=olive-editor signature.asc Description: OpenPGP digital signature
Bug#925754: Fixed in newer release of libopenshot / libopenshot-audio
Control: block 925754 by 925755 Control: notforwarded 925754 Control: forwarded 925755 https://github.com/OpenShot/libopenshot-audio/issues/33 Hi, > On Wed, 29 Jan 2020 10:08:55 +0100 Matthias Klose wrote: > > libopenshot-audio 0.1.8 still fails to build > > Quite right, sorry. libopenshot-audio-0.1.8 fixed building with GCC *less > than* 9, > but GCC9 coming along broke it again. > > On Fedora / RPM Fusion we were building with commit 7001b68[1], > which was at the time an unreleased commit on the development branch. > > However, since then both 0.1.9 and 0.2.0 have been released, > including fixes to build with GCC 9 and 10 respectively, IIRC. > (I know 0.2.0 builds with GCC 10 for sure, since I've done it myself.) > > Current releases: > > libopenshot-audio-0.2.0: > https://github.com/OpenShot/libopenshot-audio/archive/v0.2.0.tar.gz > > libopenshot-0.2.5: > https://github.com/OpenShot/libopenshot/archive/v0.2.5.tar.gz > > OpenShot 2.5.1 (openshot-qt): > https://github.com/OpenShot/openshot-qt/archive/v2.5.1.tar.gz > > > [1]: > https://github.com/OpenShot/libopenshot-audio/commit/7001b68787c0881a44bcafba98cccae509a31644 libopenshot-audio builds with Clang without any modifications. Using this OpenShot (again with Clang) gets a bit farther: /usr/include/libopenshot-audio/JuceLibraryCode/modules/juce_audio_basics/../juce_core/unit_tests/juce_UnitTest.h:73:17: note: candidate found by name lookup is 'juce::UnitTest' class JUCE_API UnitTest ^ /<>/tests/Cache_Tests.cpp:50:2: error: reference to 'UnitTest' is ambiguous I've seen this is fixed in a commit upstream, and I think cherrypicking it helped, but the -audio Debian package uses the Juce embedded code copies instead of the ones in juce-modules-source as best as I can tell. I'm uneasy about this and hope that a new release of OpenShot made with the practices described in /usr/share/doc/juce-modules-source/README.Debian will make an elegant solution. signature.asc Description: This is a digitally signed message part.
Bug#956305: varnish: CVE-2019-20637
Hi Sylvain, On Tue, Apr 21, 2020 at 07:23:40PM +0200, Sylvain Beucler wrote: > I didn't check whether the "undetermined" state would work for a lower > suite, thanks. I'll mark it as "postponed" or "ignored" instead -- but > hopefully I'll get some info :) Ack (regarding postponed or ignored), and agree the latter on getting more information from upstream would be the best outcome. Thank you so far, Regards, Salvatore
Bug#958414: Latest equivs version 2.3.0 breaks mk-build-deps
Package: equivs Version: 2.3.0 I noticed my builds started failing today with error message: Step 4/7 : RUN DEBIAN_FRONTEND=noninteractive mk-build-deps -r -i control -t 'apt-get -y -o Debug::pkgProblemResolver=yes --no-install-recommends' ---> Running in 912092c7ebbd dpkg-buildpackage: info: source package mariadb-10.5-build-deps dpkg-buildpackage: info: source version 1.0 dpkg-buildpackage: info: source distribution unstable dpkg-buildpackage: info: source changed by root dpkg-source --before-build . dpkg-buildpackage: info: host architecture amd64 dpkg-checkbuilddeps: error: Unmet build dependencies: build-essential:native dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting dpkg-buildpackage: warning: (Use -d flag to override.) Error in the build process: exit status 3 dpkg: error: cannot access archive 'mariadb-10.5-build-deps_1.0_amd64.deb': No such file or directory mk-build-deps: dpkg --unpack failed The command '/bin/sh -c DEBIAN_FRONTEND=noninteractive mk-build-deps -r -i control -t 'apt-get -y -o Debug::pkgProblemResolver=yes --no-install-recommends'' returned a non-zero code: 2 I am pretty sure this is related to the recent equivs 2.3.0 release, but I have not figured out the details yet. Run the attached Dockerfile to reproduce. - Otto Dockerfile.mariadb-10.5-debian-sid-build-env Description: Binary data
Bug#958415: src:mir-core: fails to migrate to testing for too long
Source: mir-core Version: 1.0.1-2 Severity: serious Control: close -1 1.0.2-1 Tags: sid bullseye User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), As recently announced [1], the Release Team now considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing. Your package src:mir-core in its current version in unstable has been trying to migrate for 60 days [2]. Hence, I am filing this bug. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bullseye, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=mir-core signature.asc Description: OpenPGP digital signature
Bug#91815: Patch to add memusage and memusagestat
Control: tag -1 + patch Hi, The attached patch adds memusage and memusagestat to the libc-bin package. This does mean that the latter becomes dependent on libgd3, so it might be better to add a new memusage package; I can take care of that if the maintainers think it’s better. Regards, Stephen From c2bc49abc1dfba93609544378f3f65dec1b98a7c Mon Sep 17 00:00:00 2001 From: Stephen Kitt Date: Tue, 21 Apr 2020 20:55:53 +0200 Subject: [PATCH] Build and package memusage* This builds memusage and memusagestat in the libc pass, and ships them in libc-bin. This involves adding a build-dependency on libgd-dev (outside stage1) and libc-bin acquires a runtime dependency on the corresponding library package. Closes: #91815 Signed-off-by: Stephen Kitt --- debian/control.in/main | 4 +++- debian/debhelper.in/libc-bin.install | 2 ++ debian/debhelper.in/libc-bin.lintian-overrides | 2 ++ debian/rules.d/build.mk| 6 +- 4 files changed, 12 insertions(+), 2 deletions(-) diff --git a/debian/control.in/main b/debian/control.in/main index 659267bd..3ff82664 100644 --- a/debian/control.in/main +++ b/debian/control.in/main @@ -12,7 +12,8 @@ Build-Depends: gettext, dpkg (>= 1.18.7), dpkg-dev (>= 1.17.14), xz-utils, file, g++-9, g++-9-multilib [amd64 i386 kfreebsd-amd64 mips mipsel mipsn32 mipsn32el mips64 mips64el mipsr6 mipsr6el mipsn32r6 mipsn32r6el mips64r6 mips64r6el powerpc ppc64 s390x sparc sparc64 x32] , python3:native, libidn2-0 (>= 2.0.5~) , - libc-bin (>= @GLIBC_VERSION@) + libc-bin (>= @GLIBC_VERSION@) , + libgd-dev Build-Depends-Indep: perl, po-debconf (>= 1.0) Maintainer: GNU Libc Maintainers Uploaders: Clint Adams , Aurelien Jarno , Adam Conrad , Samuel Thibault @@ -39,6 +40,7 @@ Description: GNU C Library: Binaries * iconv, iconvconfig: convert between character encodings * ldd, ldconfig: print/configure shared library dependencies * locale, localedef: show/generate locale definitions + * memusage, memusagestat: measure memory usage * tzselect, zdump, zic: select/dump/compile time zones Package: libc-dev-bin diff --git a/debian/debhelper.in/libc-bin.install b/debian/debhelper.in/libc-bin.install index dfab166b..a76d191f 100644 --- a/debian/debhelper.in/libc-bin.install +++ b/debian/debhelper.in/libc-bin.install @@ -12,6 +12,8 @@ debian/tmp-libc/usr/bin/iconv usr/bin debian/tmp-libc/usr/bin/ldd usr/bin debian/tmp-libc/usr/bin/localedef usr/bin debian/tmp-libc/usr/bin/locale usr/bin +debian/tmp-libc/usr/bin/memusage usr/bin +debian/tmp-libc/usr/bin/memusagestat usr/bin debian/tmp-libc/usr/bin/pldd usr/bin debian/tmp-libc/usr/bin/tzselect usr/bin debian/tmp-libc/usr/lib/pt_chown usr/lib diff --git a/debian/debhelper.in/libc-bin.lintian-overrides b/debian/debhelper.in/libc-bin.lintian-overrides index 01eb456c..ba411883 100644 --- a/debian/debhelper.in/libc-bin.lintian-overrides +++ b/debian/debhelper.in/libc-bin.lintian-overrides @@ -17,6 +17,8 @@ libc-bin: binary-without-manpage usr/bin/iconv libc-bin: binary-without-manpage usr/bin/ldd libc-bin: binary-without-manpage usr/bin/locale libc-bin: binary-without-manpage usr/bin/localedef +libc-bin: binary-without-manpage usr/bin/memusage +libc-bin: binary-without-manpage usr/bin/memusagestat libc-bin: binary-without-manpage usr/bin/pldd libc-bin: binary-without-manpage usr/bin/zdump libc-bin: binary-without-manpage usr/sbin/iconvconfig diff --git a/debian/rules.d/build.mk b/debian/rules.d/build.mk index 0d03116a..3f664316 100644 --- a/debian/rules.d/build.mk +++ b/debian/rules.d/build.mk @@ -37,7 +37,11 @@ $(stamp)configure_%: $(stamp)config_sub_guess $(stamp)patch $(KERNEL_HEADER_DIR) echo "BASH := /bin/bash" >> $(DEB_BUILDDIR)/configparms echo "KSH := /bin/bash" >> $(DEB_BUILDDIR)/configparms echo "SHELL := /bin/bash" >> $(DEB_BUILDDIR)/configparms - echo "LIBGD = no" >> $(DEB_BUILDDIR)/configparms + if [ "$(curpass)" = "libc" ]; then \ + echo "LIBGD = yes" >> $(DEB_BUILDDIR)/configparms; \ + else \ + echo "LIBGD = no" >> $(DEB_BUILDDIR)/configparms; \ + fi echo "bindir = $(bindir)" >> $(DEB_BUILDDIR)/configparms echo "datadir = $(datadir)" >> $(DEB_BUILDDIR)/configparms echo "complocaledir = $(complocaledir)" >> $(DEB_BUILDDIR)/configparms -- 2.20.1 pgpomuaYeRPJt.pgp Description: OpenPGP digital signature
Bug#900448: chipmunk: please upload pending changes from VCS, or remove from Debian
On Wed, May 30, 2018 at 11:22:08PM +0100, Simon McVittie wrote: > src:chipmunk has had pending changes in git since 2014 which have > not been uploaded. If someone is still maintaining it, please > review and upload those changes, which can now be found in: > https://salsa.debian.org/games-team/chipmunk I’ve taken care of this. Regards, Stephen signature.asc Description: PGP signature
Bug#954716: buster-pu: package suricata/1:4.1.2-2
Control: tags -1 -moreinfo +confirmed On Mon, 2020-04-13 at 14:24 +0200, Sascha Steinbiss wrote: > fixed 951181 1:5.0.2-1 > thanks > > Hi Adam, > > > > When you talk about bug metadata, are you just referring to a > > > missing > > > 'fixed' tag for #951181 along the lines of: > > > > > >fixed 951181 1:5.0.2-1 > > > > > > If so, I would be happy to provide that. > > > > Yes, exactly that. Sorry if it seems insignificant, but it provides > > a > > much clearer view of what the state is across the suites. > > Sure, no problem. Done! Thanks. Please go ahead. Regards, Adam
Bug#956801: buster-pu: package megatools/1.10.2-1+deb10u1
Control: tags -1 + confirmed On Wed, 2020-04-15 at 13:57 +0200, Alberto Garcia wrote: > megatools can be used (among other things) to download files from the > Mega cloud storage service. > > Files can be downloaded using a link that contains a file handle and > an encryption key. > > The format of these links has changed recently and megatools 1.10.2 > doesn't recognize them. > Please go ahead. (With the changelog fixed as you noted.) Regards, Adam
Bug#956805: stretch-pu: package megatools/1.9.98-1+deb9u1
Control: tags -1 + confirmed On Wed, 2020-04-15 at 14:43 +0200, Alberto Garcia wrote: > megatools can be used (among other things) to download files from the > Mega cloud storage service. > > Files can be downloaded using a link that contains a file handle and > an encryption key. > > The format of these links has changed recently and megatools 1.9.98 > doesn't recognize them. > Please go ahead. Regards, Adam
Bug#954050: RFS: persist-el/0.4+dfsg-1 [ITP] -- persist variables between Emacs Sessions
Hi Nicholas, I just uploaded persist-el. Thank you and sorry for the delay. This was my first sponsorship and I also had to setup a new laptop. I'm just waiting for the confirmation mail for the upload. There are a few nitpicks and I'd be grateful if you could track them, e.g. in bugs.d.o after the package enters the archive: - It's a pity that we can not include the info file due to the license. Could you ask upstream to consider another license? - As long as the doc is not included, I think you don't need to build depend on texinfo. - If upstream also uses Git, I prefer to track upstreams master branch as upstream branch in the packaging repo. You could still merge their branch in your existing repo or restart the repo? - Lintian also had two nitpicks, see below. I'm guilty of the "wrong" section myself for elpa-editorconfig. What is the teams stand on this? Cheers, Thomas I: persist-el source: public-upstream-key-not-minimal upstream/signing-key.asc has 1 extra signature(s) for keyid 066DAFCB81E42C40 N: N:The package contains a public upstream signing key with extra N:signatures. The signatures are unnecessary and take up space in the N:archive. N: N:Please export the upstream key again with the command: N: N: $ gpg --armor --export --export-options export-minimal,export-clean N: N:and use that key instead of the key currently in the source package. N: N:Refer to the uscan(1) manual page for details. N: N:Severity: info N: N:Check: debian/upstream/signing-key N: I: elpa-persist: wrong-section-according-to-package-name elpa-persist => lisp N: N:This package has a name suggesting that it belongs to a section other N:than the one it is currently categorized in. N: N:Severity: info N: N:Check: fields/section N: > Nicholas D Steeves hat am 11. April 2020 12:31 > geschrieben: > > > Hi Thomas and Sébastien, > > #947017 "ITP: org-drill" is blocked by this RFS (#954050) for a > required dependency (persist-el). Please sponsor at your earliest > convenience to we
Bug#956535: buster-pu: package php-horde-data/2.1.4-5+deb10u1
On Tue, Apr 21, 2020 at 06:55:41PM +0100, Adam D. Barratt wrote: > On Sun, 2020-04-19 at 16:39 -0400, Roberto C.Sánchez wrote: > > Hi Mathieu & Adam, > > > > On Wed, Apr 15, 2020 at 03:07:00PM +0200, Mathieu Parent (Debian) > > wrote: > > > > > > Thanks Roberto! > > > > > > Hello Salvatore, > > > > > > > Mathieu, but are you still planning to request removals? > > > > > > Done as #956808. > > > > > Given that the removal has been requested, I'll not prepare new > > uploads for unstable. Adam, could you weigh in on whether I may > > proceed with the uploads (all six) or whether I need to wait for the > > removal to take place? > > On the assumption that the removal won't take too long, please go > ahead. > Thanks. I have uploaded to ftp-master. However, I did notice one peculiarity. I had this near the end of the output: ** Uploading php-horde-data_2.1.4.orig.tar.gz Upload permissions error You either don't have the rights to upload a file, or, if this is on ftp-master, you may have tried to overwrite a file already on the server. Continuing anyway in case you want to recover from an incomplete upload. No file was uploaded, however. ** That is interesting because I noticed that one of the packages, php-horde-data, had the same upstream version, 2.1.4, for both stretch and buster. Since this was the first stable update for both, I built them each with -sa to include the .orig.tar.gz. I guess it will be evident soon whether that is a problem when I receive the receipt message from dak, but I thought to bring it up just in case. Regards, -Roberto -- Roberto C. Sánchez
Bug#956861: buster-pu: package debian-edu-config/2.10.65+deb10u5
Control: tags -1 + confirmed On Thu, 2020-04-16 at 02:41 +0200, Holger Levsen wrote: > debian-edu-config (2.10.65+deb10u5) buster; urgency=medium > > [ Wolfgang Schweer ] > * Add policies files for Firefox-ESR and Thunderbird to fix the > TLS/SSL setup. > This makes sure that the Debian-Edu_rootCA.crt file gets > installed as > trusted certificate for Firefox-ESR and Thunderbird. (Already > fixed in > Bullseye.) > - Add share/firefox-esr/distribution/policies.json (Closes: > #944450). > - Add lib/thunderbird/distribution/policies.json (Closes: > #955978). > - Adjust Makefile accordingly. > Please go ahead; thanks. Regards, Adam
Bug#956913: buster-pu: package nvidia-graphics-drivers/418.113-1
Control: tags -1 + confirmed On Thu, 2020-04-16 at 19:10 +0200, Andreas Beckmann wrote: > I'd like to update the non-free nvidia-graphics-drivers in buster > from 418.74-1 to 418.113-1. > Assuming that the control shuffling doesn't result in any new packages, please go ahead. Regards, Adam
Bug#956929: stretch-pu: package nvidia-graphics-drivers/390.132-1
Control: tags -1 + confirmed On Thu, 2020-04-16 at 22:05 +0200, Andreas Beckmann wrote: > I'd like to update the non-free nvidia-graphics-drivers in stretch > from 390.116-1 to 390.132-1. > Assuming that the control shuffling doesn't result in any new packages, please go ahead. Regards, Adam
Bug#956913: buster-pu: package nvidia-graphics-drivers/418.113-1
Control: tags -1 + confirmed On Thu, 2020-04-16 at 19:10 +0200, Andreas Beckmann wrote: > I'd like to update the non-free nvidia-graphics-drivers in buster > from 418.74-1 to 418.113-1. > Please go ahead. Regards, Adam
Bug#958141: buster-pu: package xdg-utils/1.1.3-1
Control: tags -1 + confirmed On Sat, 2020-04-18 at 23:53 +0300, Nicholas Guriev wrote: > There are a number of bugs fixed in the 1.1.3-2 version of the xdg- > utils package that now is available in testing and unstable archives. > It would be good to have the fixes in buster also. > > If you think these changes are okay for stable update, please > consider to sponsor upload to stable-proposed-updates. The Release Team don't generally sponsor uploads to stable, but feel free to go ahead and get it uploaded. Regards, Adam
Bug#958413: debian-janitor | Misses to add the document start "---" for YAML document debian/upstream/metadata (#101)
Package: lintian-brush Severity: minor (reported at https://salsa.debian.org/jelmer/debian-janitor/-/issues/101) On Tue, Apr 21, 2020 at 12:12:14PM +, Daniel Leidert wrote: > I saw several occasions where janitor added the debian/upstream/metadata > file. But all those are missing to add the starting `---`. Even if this is > not required and will produce "just" a warning by `yamllint` it would be nice > to add it to have valid YAML.
Bug#958412: RFS: bbrun/1.6-8 [QA] -- tool for the blackbox/fluxbox window managers that runs commands
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "bbrun" * Package name: bbrun Version : 1.6-8 Upstream Author : Josh King * URL : http://www.darkops.net/bbrun/ * License : GPL-2.0+ * Vcs : https://salsa.debian.org/debian/bbrun Section : x11 It builds those binary packages: bbrun - tool for the blackbox/fluxbox window managers that runs commands To access further information about this package, please visit the following URL: https://mentors.debian.net/package/bbrun Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/b/bbrun/bbrun_1.6-8.dsc Changes since the last upload: * QA upload. * Fix FTBFS with GCC-10. (Closes: #957033) * Update Standards-Version to 4.5.0 * Use debhelper-compat. - Update compat level to 12. * Simplify debian/rules. - Add debian/mapages file. * Mark Vcs link to salsa. -- Regards Sudip
Bug#953376: [Pkg-mailman-hackers] Bug#953376: Mailman 2 will be removed from Debian
On Tue, April 21, 2020 18:02, Andrew Hodgson wrote: > Thijs Kinkhorst wrote: >>On Sun, March 8, 2020 20:01, Scott Kitterman wrote: >>> Package: src:mailman >>> Version: 1:2.1.29-1 >>> Severity: serious >>> Justification: Policy 2.2.1 >>> >>> This package Depends/Build-Depends on python-dnspython which is an NBS >>> cruft package. Please update your package to use python3-dnspython, >>> which is still provided (if the package will be ported to python3). > >>Mailman 2.1.x is Python 2 only. > >>Upstream has explicitly indicated there will be no effort to port it to >> Python 3: >>https://mail.python.org/pipermail/mailman-users/2019-April/084333.html > >>So it seems the time has come to remove Mailman 2 from Debian, and let >> people migrate to Mailman 3. > > I thought this may be the case. I was looking at the possibility of > whether I could build 2.1.30 even if it was to go in backports until the > eventual removal of the package on the next Debian version, but would this > removal cause problems for this? This is indeed not possible, because Backports requires package versions to come from testing and mailman is already no longer in testing. Continued support for any mailman 2.x packages needs to be outside of the Debian archive since Debian will have removed Python 2 both from stable and testing/unstable starting from the next release. Cheers, Thijs Cheers, Thijs
Bug#958399: buster-pu: package jekyll/3.8.3+dfsg-4
Control: tags -1 + confirmed On Tue, 2020-04-21 at 16:01 +0200, Daniel Leidert wrote: > The ruby-i18n package is broken in Buster. I've uploaded a fixed > package to buster-p-u (#958395). This will fix the gemspec issue in > Buster. > Unfortunately jekyll requires ruby-i18n (>= 0.7, << 1.0) and might be > broken by this upload. > So this is a fixed version of jekyll which requires the i18n gem > >=0.7 and <<2. > Actually jekyll works just fine with this i18n version, so only the > .gemspec needed patching. Please go ahead. Regards, Adam
Bug#956535: buster-pu: package php-horde-data/2.1.4-5+deb10u1
On Sun, 2020-04-19 at 16:39 -0400, Roberto C.Sánchez wrote: > Hi Mathieu & Adam, > > On Wed, Apr 15, 2020 at 03:07:00PM +0200, Mathieu Parent (Debian) > wrote: > > > > Thanks Roberto! > > > > Hello Salvatore, > > > > > Mathieu, but are you still planning to request removals? > > > > Done as #956808. > > > Given that the removal has been requested, I'll not prepare new > uploads for unstable. Adam, could you weigh in on whether I may > proceed with the uploads (all six) or whether I need to wait for the > removal to take place? On the assumption that the removal won't take too long, please go ahead. Regards, Adam
Bug#958286: pavucontrol: Missing escaping of & in device names
]] Felipe Sateler > Could you share the output of `pactl list sinks`? It appears the problem is > not really in the device description. Sink #11 State: IDLE Name: bluez_sink.EC_66_D1_XX_XX_XX.headset_head_unit Description: Bowers & Wilkins PX Driver: module-bluez5-device.c Sample Specification: s16le 1ch 8000Hz Channel Map: mono Owner Module: 31 Mute: no Volume: mono: 37987 / 58% balance 0.00 Base Volume: 65536 / 100% Monitor Source: bluez_sink.EC_66_D1_XX_XX_XX.headset_head_unit.monitor Latency: 24995 usec, configured 28000 usec Flags: HARDWARE HW_VOLUME_CTRL LATENCY Properties: bluetooth.protocol = "headset_head_unit" device.intended_roles = "phone" device.description = "Bowers & Wilkins PX" device.string = "EC:66:D1:XX:XX:XX" device.api = "bluez" device.class = "sound" device.bus = "bluetooth" device.form_factor = "headphone" bluez.path = "/org/bluez/hci0/dev_EC_66_D1_XX_XX_XX" bluez.class = "0x240418" bluez.alias = "Bowers & Wilkins PX" device.icon_name = "audio-headphones-bluetooth" Ports: headphone-output: Hovudtelefonar (priority: 0, available) Active Port: headphone-output Formats: pcm (replaced the last three parts of the bluetooth address with XX, I doubt that's the problem.) -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Bug#956305: varnish: CVE-2019-20637
I didn't check whether the "undetermined" state would work for a lower suite, thanks. I'll mark it as "postponed" or "ignored" instead -- but hopefully I'll get some info :)
Bug#958411: ITP: golang-github-cloudflare-tableflip -- Graceful process restarts in Go
Package: wnpp Severity: wishlist Owner: Pirate Praveen * Package name : golang-github-cloudflare-tableflip Version : 0.0~git20190329.8392f16-1 Upstream Author : Cloudflare * URL : https://github.com/cloudflare/tableflip * License : BSD-3-clause Programming Lang: Go Description : Graceful process restarts in Go It is sometimes useful to update the running code and / or configuration of a network service, without disrupting existing connections. Usually, this is achieved by starting a new process, somehow transferring clients to it and then exiting the old process. . There are many ways to implement graceful upgrades. They vary wildly in the trade-offs they make, and how much control they afford the user. This library has the following goals: - No old code keeps running after a successful upgrade - The new process has a grace period for performing initialisation - Crashing during initialisation is OK - Only a single upgrade is ever run in parallel Build dependency of gitaly.
Bug#958410: lintian: nag about duplicated debhelper build-deps
Package: lintian Severity: wishlist please consider tagging these cases: Build-Depends: autoconf-archive, - debhelper (>= 11), + debhelper (>= 12), + debhelper-compat (= 12), libbz2-dev, libtar-dev, Having both debhelper and debhelper-compat there is only needed when the version of debhelper is >> the version of debhelper-compat, not when it's ==. Or when it has extra restrictions (build profiles, etc). -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#950271: netperfmeter: can't start netperfmeter (passive) without DCCP
Control: retitle -1 Please provide a backported netperfmeter for Buster Hi Zac, On Thu, Jan 30, 2020 at 03:07:08PM -0500, Zachary Wolff wrote: > I've had some contact with the maintainer. > He advised netperfmeter 1.2.3 is quite old. > Debian testing and unstable have much newer versions and shouldn't have > this problem. > > netperfmeter is not in buster-backports at the moment. > > Can we get a newer version of netperfmeter added to buster or > buster-backports? Thanks for filing this; as you say, the bug is already fixed in Bullseye, but rather than closing it, I’ve changed it to a request for a backport to Buster. I can help backport this if necessary. Regards, Stephen signature.asc Description: PGP signature
Bug#956305: varnish: CVE-2019-20637
Hi, On Tue, Apr 21, 2020 at 05:22:15PM +0200, Sylvain Beucler wrote: > I contacted upstream a few days ago: > https://varnish-cache.org/lists/pipermail/varnish-misc/2020-April/026854.html > No answer yet. > > I'll probably ping the security contact (individual maintainers) in a > bit and search some more on my own. > > Failing that I'll mark the issue undetermined for 4.x. Actually please do not mark it as undetermined in lower suites, it is meant for a broader higher level view on a CVE. undetermined is used (and this seldomly) when there is need to track a newly arised CVE where it seem sufficiently clear that it affects a specific source package but not real initial triage could be done (or other example, not sufficient information is available to start doing so), but having the advantage to have the CVE already popping up e.g. for debsecan. Other cases are when there is still not much information in general avialble like for some CVEs arising from Apple, claiming affectness of libxml2 but there is simply no information avialble what the issue is about. Now, usually if for a specific lower suite we are not able to determine it's not-affected source status, then we err on the 'safe' side and keep it affected. But it you want to have it out of your radar, mark it with the substate of no-dsa 'ignored' to not further look at the issue. Hope this helps, Regards, Salvatore
