Bug#955193: alot: warnings with Python 3.8: SyntaxWarning: "is" with a literal
Package: alot Version: 0.9-2 Severity: normal Usertags: warnings When I upgraded to Python 3.8 I got these warnings about alot during the upgrade saying that the code should use "==" instead of "is": Setting up python3 (3.8.2-2) ... running python rtupdate hooks for python3.8... /usr/share/alot/alot/commands/envelope.py:762: SyntaxWarning: "is" with a literal. Did you mean "=="? if self.action is "txt2html": /usr/share/alot/alot/commands/envelope.py:768: SyntaxWarning: "is" with a literal. Did you mean "=="? elif self.action is "html2txt": /usr/share/alot/alot/widgets/ansi.py:84: SyntaxWarning: "is" with a literal. Did you mean "=="? if code is 0: -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE=en_AU:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages alot depends on: ii python3 3.8.2-2 ii python3-configobj 5.0.6-3 ii python3-gpg 1.13.1-6 ii python3-magic 2:0.4.15-3 ii python3-notmuch 0.29.3-1 ii python3-twisted 18.9.0-8 ii python3-urwid 2.0.1-2+b2 ii python3-urwidtrees 1.0.1.1-2 Versions of packages alot recommends: ii links2.20.2-1+b1 ii notmuch 0.29.3-1+b2 ii w3m 0.5.3-37+b1 Versions of packages alot suggests: pn alot-doc -- no debconf information -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#954195: New error
Hi, The previous error seems to have been fixed. However, a new error shows up now. Traceback (most recent call last): File "/usr/lib/python3/dist-packages/gnomemusic/scrobbler.py", line 81, in _new_client_callback manager.call_is_supported_provider( AttributeError: 'NoneType' object has no attribute 'call_is_supported_provider' Also, to answer your previous question, yes, I've the latest version of gobject-introspection and python3-gi from testing. Thanks
Bug#944228: stretch-pu: package phpmyadmin/4:4.6.6-4+deb9u1
Hi Adam. On Tue, 28 Jan 2020 08:35:54 + "Adam D. Barratt" wrote: > Control: tags -1 + confirmed > Thanks. Please go ahead. For some reason, this upload never happened. However, now, the maintainer, William (CCed here) has prepared these CVE fixes + some new CVEs on top of this, too. All of these CVE(s) have been fixed in unstable (and in Jessie, too). Please let me know if we have an ack from your side to upload the fix for all the CVEs in Stretch? Attaching the debdiff. Best, Utkarsh debdiff Description: Binary data
Bug#954420: confirming the same at my end
Dear Maintainer,
Getting the same message at my end as well -
/usr/bin/debdelta-upgrade:5386: DeprecationWarning: isAlive() is
deprecated, use is_alive() instead
while patching_thread.isAlive() or ('a' in DEB_POLICY and no_delta):
--
Regards,
Shirish Agarwal शिरीष अग्रवाल
My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C
Bug#953569:
On Sat, 2020-03-21 at 00:01 -0600, Jason A. Donenfeld wrote: > Hi again, > > It looks like you didn't actually take these patches from the updated > tree I sent you, but rather used the outdated .zip I had posted prior. > Please try again using the tree I linked earlier: > > https://git.zx2c4.com/wireguard-linux/log/?h=backport-5.5.y I've applied all the changes from there. I should be uploading an updated Debian package over the weekend. Thanks for your patience. Ben. -- Ben Hutchings This sentence contradicts itself - no actually it doesn't. signature.asc Description: This is a digitally signed message part
Bug#955192: cinnamon: Ctrl and capslock switch does not persist through reboots.
Package: cinnamon Version: 4.4.8-2 Severity: normal Dear Maintainer, Since... I THINK 3 weeks ago at max, definitely since upgrading from Buster, Cinnamon's option to swap ctrl and capslock has to be reset after every reboot. Process to do this: * Run "cinnamon-settings keyboard" * Go to "Layouts" tab * Push "Options" in the lower right corner * Open the "Ctrl position" drop-down * Check "Swap Ctrl and Caps Lock" This works fine, until the next reboot. After that reboot, the "Swap Ctrl and Caps Lock" check-box is still checked, but the keys aren't actually swapped until I un-check and re-check it. It's happened on several computers by now, so, let me know if there's anything I can do to help. Regards, Simon -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-4-amd64 (SMP w/16 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages cinnamon depends on: ii cinnamon-common 4.4.8-2 ii cinnamon-control-center 4.4.0-2 ii cinnamon-desktop-data4.4.1-3 ii cinnamon-screensaver 4.4.1-3 ii cinnamon-session 4.4.1-1 ii cinnamon-settings-daemon 4.4.0-3 ii cjs 4.4.0-4 ii cups-pk-helper 0.2.6-1+b1 ii dconf-gsettings-backend [gsettings-backend] 0.36.0-1 ii gir1.2-accountsservice-1.0 0.6.55-1 ii gir1.2-caribou-1.0 0.4.21-7 ii gir1.2-clutter-1.0 1.26.4+dfsg-1 ii gir1.2-cmenu-3.0 4.4.0-2 ii gir1.2-cogl-1.0 1.22.6-1 ii gir1.2-cvc-1.0 4.4.1-3 ii gir1.2-gdkpixbuf-2.0 2.40.0+dfsg-3 ii gir1.2-gkbd-3.0 3.26.1-1 ii gir1.2-glib-2.0 1.62.0-5 ii gir1.2-gnomedesktop-3.0 3.34.2-2 ii gir1.2-gtk-3.0 3.24.14-1 ii gir1.2-gtkclutter-1.01.8.4-4 ii gir1.2-keybinder-3.0 0.3.2-1+b1 ii gir1.2-meta-muffin-0.0 4.4.2-3 ii gir1.2-nemo-3.0 4.4.2-2 ii gir1.2-nm-1.01.22.8-1 ii gir1.2-nma-1.0 1.8.24-1 ii gir1.2-notify-0.70.7.9-1 ii gir1.2-pango-1.0 1.42.4-8 ii gir1.2-polkit-1.00.105-26 ii gir1.2-soup-2.4 2.70.0-1 ii gir1.2-timezonemap-1.0 0.4.6-2 ii gir1.2-upowerglib-1.00.99.11-1 ii gir1.2-xapp-1.0 1.6.10-2 ii gkbd-capplet 3.26.1-1 ii gnome-backgrounds3.36.0-1 ii gnome-themes-extra 3.28-1 ii gsettings-desktop-schemas3.36.0-1 ii iso-flags-png-320x2401.0.2-1 ii libatk-bridge2.0-0 2.34.1-3 ii libatk1.0-0 2.34.1-1 ii libc62.30-2 ii libcairo21.16.0-4 ii libcinnamon-desktop4 4.4.1-3 ii libcinnamon-menu-3-0 4.4.0-2 ii libcjs0 4.4.0-4 ii libcroco30.6.13-1 ii libgdk-pixbuf2.0-0 2.40.0+dfsg-3 ii libgirepository-1.0-11.62.0-5 ii libgl1 1.3.1-1 ii libglib2.0-0 2.64.1-1 ii libglib2.0-bin 2.64.1-1 ii libgstreamer1.0-01.16.2-2 ii libgtk-3-0 3.24.14-1 ii libmuffin0 4.4.2-3 ii libpango-1.0-0 1.42.4-8 ii libpangocairo-1.0-0 1.42.4-8 ii libstartup-notification0 0.12-6 ii libx11-6 2:1.6.9-2 ii libxfixes3 1:5.0.3-1 ii libxml2 2.9.10+dfsg-4 ii mesa-utils 8.4.0-1+b1 ii muffin 4.4.2-3 ii nemo 4.4.2-2 ii network-manager-gnome1.8.24-1 ii policykit-1-gnome0.105-7 ii python3
Bug#955191: RFS: bubblemail/0.5-1 [ITP] -- Extensible mail notification service
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "bubblemail" * Package name: bubblemail Version : 0.5-1 Upstream Author : Razer * URL : https://framagit.org/razer/bubblemail * License : GPL-2.0+ * Vcs : https://git.launchpad.net/bubblemail Section : mail It builds those binary packages: bubblemail - Extensible mail notification service To access further information about this package, please visit the following URL: https://mentors.debian.net/package/bubblemail Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/b/bubblemail/bubblemail_0.5-1.dsc Changes since the last upload: * Initial release. (Closes: #955188) * original source package automatically created by stdeb 0.8.5 Comaintainer in Uploaders is CC'd on this message; they do not have upload rights either and any uploads from them will also go through Sponsors, however I'm taking lead on the Debian package. Regards, -- Thomas Ward
Bug#954662: obantoo: Obantoo includes an outdated BLZ.txt
On Sun, Mar 22, 2020 at 01:49:06PM +0100, Thomas Weber wrote:
> Source: obantoo
> Severity: normal
>
> The current version of BLZ.txt in the package dates from 2015, which
> means that checks for new BLZs and IBANs based on them will fail (e.g.
> 59020400). While the Deutsche Bundesbank makes available updated BLZ.txt
> files for free on their website, obantoo uses the extended version
> ("erweiterte Bankleitzahlendatei"), which is only available with an
> account on their Extranet[1]. I have applied for an account, but have
> not yet received an answer. However, a recent version of BLZ.txt has
> been added by the Hibiscus author and can be extracted from [2].
>
> I prepared a patch based on [2], but the resulting diff is 6 MB in size
> - which is suboptimal. I do not have a really good proposal on how to
> move forward here, but given that an updated BLZ.txt is published every
> quarter, it seems suboptimal to put it into the JAR file:
> 1) This makes it unneccessarily difficult to find the file and replace
> it with a local version.
> 2) It requires a new release of the software when it reality there
> were no code changes and only a data update.
>
> [1]
> https://www.bundesbank.de/de/aufgaben/unbarer-zahlungsverkehr/serviceangebot/bankleitzahlen/bankleitzahlen-602638
> [2] https://github.com/willuhn/hibiscus/raw/master/lib/obantoo-bin-2.1.12.jar
Hi Thomas,
It sounds like you are proposing creating a separate "obantoo-data"
package that is updated regularly.
Fortunately there is only place in the source code that references the
data file [3] (and then a few further lines down for the CSV file for
Austria [4]), and it wouldn't be too difficult to write a patch to
source these files from the file system. If we decide to go this path,
we'll want to exclude the data files from the obantoo sources when we
repack the source archive. (Otherwise we would end up with a large diff
to represent the deletions.)
Does that sound like a reasonable solution? I can help with patch for
obantoo if that's helpful.
Cheers,
tony
[3]
https://salsa.debian.org/java-team/obantoo/-/blob/master/src/de/jost_net/OBanToo/SEPA/BankenDaten/Banken.java#L30
[4]
https://salsa.debian.org/java-team/obantoo/-/blob/master/src/de/jost_net/OBanToo/SEPA/BankenDaten/Banken.java#L47
signature.asc
Description: PGP signature
Bug#955190: ITP: python-mpv - python interface to the awesome mpv media player
Package: wnpp Severity: wishlist Owner: Louis-Philippe Véronneau * Package name: python-mpv Version : 1.0 Upstream Author : Sebastian Götte * URL : https://github.com/jaseg/python-mpv * License : AGPLv3 Programming Lang: Python Description : Python interface to the awesome mpv media player This package provides python-mpv library, a ctypes-based python interface to the mpv media player. It gives you more or less full control of all features of the player, just as the lua interface does. I plan to maintain this package in the DPMT. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ signature.asc Description: OpenPGP digital signature
Bug#955000: [Python-modules-team] Bug#955000: azure-cli: Autopkgtest failure in unstable
> I'm really not familiar with humanfriendly - could you at least give us > a hint on what backward incompatible changes were made? the upgrade was rather huge, we went form 4.18 to 8.1 so there could be several changes. You may want to have a look at the upstream changelog, available at: https://humanfriendly.readthedocs.io/en/latest/changelog.html#release-8-1-2020-03-06 > More generally, how are API breaks dealt with with Python modules? it varies greatly depending on the module: some issue DeprecationWarnings before removing functionalities, others are a more "bohemians" and make changes as they see fit without paying much attention (not saying this is the case). Probably it's safe to say you may want to contact azure-cli upstream and make them aware their software doesnt work with the latest humanfriently package. Regards, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Bug#943027: fretsonfire: Python2 removal in sid/bullseye
> > I agree. It's unreasonable to block this removal further. fretsonfire > > is not a standalone package, but a part of a long chain of packages > > affected by the Py2 removal and this can't wait longer. > > I completely disagree here. Fretsonfire is one package affected by the > Py2 removal but certainly not the only one. If it was the only one, then > there would be absolutely no question because the Py2 removal is more > important than a single package. But it is not the only one. There is > still a lot of time left, we are still in the middle of the release cycle. if everybody would behave like that, we're end up with 3400 packages still depending on python2.. there is time, yes, but it's less than you may think. Do you realize Moritz replied to a message i sent on Feb 1, which is 2 months ago: did something happened in between on the side of porting fretsonfire to python3? did you do *anything* to port it? how much more are we supposed to wait for that to magically happen? > What really saddens me is that people who either don't contribute or > very little to Debian Games try to force their agenda one year before we > freeze for Bullseye. I find that unacceptable to be honest. It's a slap > in the face for contributors who have already ported several games to > Python 3 and to be honest, it's a reason for me to quit this team > altogether if you remove fretsonfire one year before the freeze. if you want to quit, it's your choice obviously, but i'm not sure rage-quitting ever worked. You're part of a distribution, and weather you like it or not, every package as a "weight" in it, currently fretsonfire is preventing progress in the direction the distribution has decided to go, which is to remove python2. i wasnt aware that being part of the games team was a requirement to tell you that fretsonfire is not good enough to be kept in Debian in its current form, i thought being a DD was a good enough quality already, and you already had 2 DDs telling you that. more on a personal note, this package forces me to keep 2 packages i maintain in debian, which i would be happily get RM'ed - how long should i wait for you to start porting fretonfire? > > If anyone ports it to Py3 until Bullseye freeze, even better. Failing > > that, it's still available on Flathub for every future Debian user: > > https://www.flathub.org/apps/details/net.sourceforge.fretsonfire > > Sure, maybe we should just direct all of our users to flathub for all > our non-essential and non-important packages. Let's focus on the Linux > kernel, systemd, and some GNU tools only, that's the universal operating > system for you kids. you may want to watch your tone, it's becoming inappropriate and definitely unhelpful. Regards. -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Bug#954902: libgl1-mesa-dri: file iris_drv_video.so is missing
Sorry, I'm not quite sure what to check. Thanks. On Thu, 2020-03-26 at 13:35 +0200, Timo Aaltonen wrote: > On 25.3.2020 12.21, Timo Aaltonen wrote: > > On 25.3.2020 5.45, Jean-Francois Pirus wrote: > > > Sorry, I ran reportbug on another machine. > > > > You most likely don't want to use the old vaapi driver, but > > intel-media-va-driver... > > > > This is not a bug for mesa but maybe libva or intel-vaapi-driver. > > This shouldn't happen on a wayland session, could you check? > > Apparently there's a gap between wayland and xorg, the mapping on > xorg > should be done on xserver..
Bug#955189: bugs.debian.org: the Tab key get stuck and repeat after it was pressed and released
Package: bugs.debian.org Severity: minor Dear Maintainer, the Tab key get stuck and repeat after it was pressed and released. This bug appears rarely (approximately 0.2% - 0.5% happenings after each Tab pressing and releasing). The bug appears at KDE Plasma (I didn't tested any other instead of KDE) at different PCs and laptops there I install Debian. The bug appears right away I install Debian (from netinst CD or USB) without any additional software. The bug appears at any application where I type a text. The Tab stops stucking and repeating after I press and release Tab again, (but the bug repeats later again after another press the Tab, for example, after Alt+Tab). Other keys work normally. -- System Information: Debian Release: 10.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-8-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#936114: alabaster: diff for NMU version 0.7.8-1.1
Control: tags 936114 + patch
Dear maintainer,
I've prepared an NMU for alabaster (versioned as 0.7.8-1.1). The diff
is attached to this message.
Regards.
diff -Nru alabaster-0.7.8/debian/changelog alabaster-0.7.8/debian/changelog
--- alabaster-0.7.8/debian/changelog 2016-06-11 23:18:17.0 -0400
+++ alabaster-0.7.8/debian/changelog 2020-03-27 23:22:09.0 -0400
@@ -1,3 +1,10 @@
+alabaster (0.7.8-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Drop python2 support; Closes: #936114
+
+ -- Sandro Tosi Fri, 27 Mar 2020 23:22:09 -0400
+
alabaster (0.7.8-1) unstable; urgency=medium
* Imported Upstream version 0.7.8
diff -Nru alabaster-0.7.8/debian/control alabaster-0.7.8/debian/control
--- alabaster-0.7.8/debian/control 2016-06-10 00:02:21.0 -0400
+++ alabaster-0.7.8/debian/control 2020-03-27 23:21:44.0 -0400
@@ -4,30 +4,12 @@
Maintainer: Jeremy T. Bouse
Build-Depends: debhelper (>=9),
dh-python,
- python-all,
- python-setuptools,
python3-all,
python3-setuptools
Standards-Version: 3.9.8
Homepage: https://github.com/bitprophet/alabaster
Vcs-Git: https://github.com/jbouse-debian/alabaster.git
Vcs-Browser: https://github.com/jbouse-debian/alabaster
-X-Python-Version: >= 2.6
-X-Python3-Version: >= 3.2
-
-Package: python-alabaster
-Architecture: all
-Depends: ${misc:Depends},
- ${python:Depends},
- ${shlibs:Depends}
-Suggests: python-sphinx
-Provides: ${python:Provides}
-Description: Configurable sidebar-enabled Sphinx theme (Python 2)
- This theme is a modified "Kr" Sphinx theme from @kennethreitz (especially
- as used in his Requests project), which was itself originally based on
- @mitsuhiko's theme used for Flask & related projects.
- .
- This is the Python 2 version of the package.
Package: python3-alabaster
Architecture: all
diff -Nru alabaster-0.7.8/debian/python-alabaster.lintian-overrides alabaster-0.7.8/debian/python-alabaster.lintian-overrides
--- alabaster-0.7.8/debian/python-alabaster.lintian-overrides 2015-03-12 21:23:58.0 -0400
+++ alabaster-0.7.8/debian/python-alabaster.lintian-overrides 1969-12-31 19:00:00.0 -0500
@@ -1,3 +0,0 @@
-# Override this error as the Google Analytics is part of a layout template
-# that is only included when configured to do so.
-python-alabaster: privacy-breach-google-adsense usr/lib/python2.7/dist-packages/alabaster/layout.html
diff -Nru alabaster-0.7.8/debian/rules alabaster-0.7.8/debian/rules
--- alabaster-0.7.8/debian/rules 2015-03-12 21:23:58.0 -0400
+++ alabaster-0.7.8/debian/rules 2020-03-27 23:21:59.0 -0400
@@ -5,7 +5,7 @@
# main packaging script based on dh7 syntax
%:
- dh $@ --with python2,python3 --buildsystem=pybuild
+ dh $@ --with python3 --buildsystem=pybuild
# To support python2.7 and python3, there are 2 ways to package:
# * packaging with --buildsystem=pybuild (jessie and later)
Bug#955188: ITP: bubblemail -- An extensible mail notification service
Package: wnpp Severity: wishlist Owner: Thomas Ward Package name : bubblemail Version : 0.5 Upstream Author : Razer URL : https://bubblemail.free.fr/ License : GPL-2 Programming Lang: Python Description : An extensible mail notification service Bubblemail is a D-Bus service providing a list of the new and unread user's mail from local mailboxes, pop, imap, and gnome online accounts. It includes a libnotify frontend to create notifications and can be used by other frontends as well. Please also include as much relevant information as possible. For example, consider answering the following questions: - why is this package useful/relevant? is it a dependency for another package? do you use it? if there are other packages providing similar functionality, how does it compare? It provides email notifications without the need to have a whole mail application open, and it replaces `mailnag` in functionality. This is also a logical replacement for `mailnag` due to mailnag being 'dead' upstream. I, Thomas Ward, do not use this, but multiple others do, and this has the support of the co-maintainer in this matter. - how do you plan to maintain it? Myself and the co-maintainer (Erich Eickmeyer ) on this package will both maintain the package. We will also cordinate with Mentors to get uploads put into the repository as well as needed. Packaging will be kept in VCS on Launchpad - https://git.launchpad.net/bubblemail - which we will specify in the VCS field in the package as well. Debian packaging begins in the debian/ branch for now.
Bug#954415: hundreds of wrong binary-is-wrong-architecture warnings
On Wed, 25 Mar 2020 07:11:02 -0700 Felix Lechner wrote:
> Hi,
Hello,
>
> On Sat, Mar 21, 2020 at 4:51 AM Matthias Klose wrote:
> >
> > I don't know when that was introduced, but you see some hundred of
those in the
> > gcc-N packages:
>
> The tag was introduced when the sole Lintian check provided by the
> xdeb package became part of Lintian. Given recent changes, it was too
> cumbersome to keep filing bug reports [1] and merge requests [2] for
> dependent packages. The relevant commit was:
>
>
https://salsa.debian.org/lintian/lintian/-/commit/25013ff8173883796e00f4bc58a89f2a09839727
>
This is the problem:
$self->tag('binary-is-wrong-architecture', $file)
if ( $architecture =~ /^arm[el|hf]$/
&& $file->file_info !~ /ARM,(?: EABI5)? version 1 \(SYSV\)/)
|| ( $architecture eq 'i386'
&& $file->file_info !~ /x86-64, version 1 \(SYSV\)/)
If architecture is i386 (OK, mine is), but file info DOESN'T indicate
x86-64 (yes, 386 binaries don't), we tag the package. That can't be
right; I don't want x86-64 files on a 386 system. And I want 386
binaries instead. Please fix that.
As an aside, why is that test even necessary? The next line (... !~
$pattern) should work fine for i386.
Regards
Jiri Palecek
Bug#955152: git-rebase ignores or squashes GIT_REFLOG_ACTION
Hi,
Ian Jackson wrote[1]:
> [ some git-debrebase invocation etc. ]
> + git reflog
> + egrep 'debrebase new-upstream.*checkout'
> + rc=1
>
> I have looked at the log and repro'd the bug.
>
> git-debrebase (which lives in src:dgit but does not depend on dgit)
> must invoke git-rebase. It sets GIT_REFLOG_ACTION so that the reflog
> is comprehensible to the user. In previous versions of git this works
> as expected. In 2.26.0-1 it does not.
>
> This is easy to reproduce by running
> GIT_REFLOG_ACTION='zeeks!' git rebase --onto
> with arguments implying a nontrivial rebase.
>
> The test suite in src:dgit, which is the checks that its
> GIT_REFLOG_ACTION manipulation is effective, and it is this test which
> has now failed and which is blocking the migration of git.
>
> git-rebrebase in sid produces quite different looking reflog entries.
> I guess the code for generating the messages has changed and that
> git-rebase is now *setting* GIT_REFLOG_ACTION (or the equivalent
> internal variable) rather than adding to it.
>
> ISTM that to preserve the documented semantics, it is basically always
> wrong of anything to unconditionally set GIT_REFLOG_ACTION. In
> src:dgit I have a small bit of code to arrange to always *add* to
> GIT_REFLOG_ACTION, if it is already set. There might be several
> precise ways to add to GIT_REFLOG_ACTION but the failing test case
> here should be happy with any reasonable choice.
Thanks for reporting.
The main relevant change is that "git rebase" switched its default
backend from "apply" to "merge". This makes it more robust by using
three-way merges in a similar way to "git cherry-pick". The "merge"
backend was historically already used for interactive rebases.
I believe some reflog behavior changes were noticed in
commit 980b482d28482c307648c3abbcb16ae60843c7ae
Author: Elijah Newren
Date: Sat Feb 15 21:36:37 2020 +
rebase tests: mark tests specific to the am-backend with --am
but we didn't investigate at the time (shame on me). Anyway, we have
a chance to improve things now.
My first thought is to look at when rebase prepares its msg, in
builtin/rebase.c#set_reflog_action:
if (!is_merge(options))
return;
env = getenv(GIT_REFLOG_ACTION_ENVIRONMENT);
if (env && strcmp("rebase", env))
return; /* only override it if it is "rebase" */
strbuf_addf(&buf, "rebase (%s)", options->action);
setenv(GIT_REFLOG_ACTION_ENVIRONMENT, buf.buf, 1);
strbuf_release(&buf);
In the --am case, is_merge is false and this code isn't run. But in
our case, GIT_REFLOG_ACTION is not rebase, so this code still
shouldn't be run.
My next thought is to look at when this function was changed:
commit c2417d3af7574adc1fb14f7df31b862aa9551e2e
Author: Elijah Newren
Date: Sat Feb 15 21:36:36 2020 +
rebase: drop '-i' from the reflog for interactive-based rebases
If I am reading
commit 13a5a9f0fdcf36270dcc2dcb7752c281bbea06f1
Author: Johannes Schindelin
Date: Thu Nov 29 11:09:21 2018 -0800
rebase: fix GIT_REFLOG_ACTION regression
correctly, then dgit requires that to be '-i' for interactive rebases.
Are we sure that that's not the issue here?
Thanks,
Jonathan
[1] https://bugs.debian.org/955152
Bug#955186: pbuilder: please have --login run the default login shell, when not bash
Daniel Shahaf wrote on Sat, Mar 28, 2020 at 01:50:38 +:
> Please execute the passwd(5)-specified login shell by default.
>
> The following works for me, but please review.
>
Need to set $SHELL too. Revised patch:
[[[
diff --git a/pbuilder b/pbuilder
index ccd7cc0..3067656 100755
--- a/pbuilder
+++ b/pbuilder
@@ -74,7 +74,8 @@ case "$1" in
fi
executehooks "F"
-(${CHROOTEXEC} bash -c 'exec -a -bash bash')
+loginshell=$(${CHROOTEXEC} getent passwd root | cut -d: -f7)
+(${CHROOTEXEC} bash -c 'export SHELL="$1"; exec -a "-$1" "$1"' .
"${loginshell}")
RET=$?
save_aptcache
]]]
Thanks,
Daniel
Bug#955187: man/man8/*: Fix misuse of a two-fonts macro
Package: man-db Version: 2.9.1-1 Severity: minor Tags: patch Dear Maintainer, >From f7e38ad54ffef567932e8a068697103822788871 Mon Sep 17 00:00:00 2001 >From: Bjarni Ingi Gislason >Date: Sat, 28 Mar 2020 01:43:02 + >Subject: [PATCH] man/man8/*: Fix misuse of two-fonts macros Correct the misuse of a two-fonts macro, which function is to 1) use the first font for each odd numbered argument and the second font for all others. 2) join (output) the arguments without an intervening space. ### Output is from: test-groff -b -e -mandoc -T utf8 -rF0 -t -w w -z [ "test-groff" is a developmental version of "groff" ] :37 (macro BR): only 1 argument, but more are expected :72 (macro BR): only 1 argument, but more are expected :139 (macro BR): only 1 argument, but more are expected Signed-off-by: Bjarni Ingi Gislason --- man/man8/accessdb.man8 | 2 +- man/man8/catman.man8 | 2 +- man/man8/mandb.man8| 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/man/man8/accessdb.man8 b/man/man8/accessdb.man8 index 5b7489ce..9777c607 100644 --- a/man/man8/accessdb.man8 +++ b/man/man8/accessdb.man8 @@ -34,7 +34,7 @@ Print debugging information. .if !'po4a'hide' .BR \-? ", " \-\-help Print a help message and exit. .TP -.if !'po4a'hide' .BR \-\-usage +.if !'po4a'hide' .B \-\-usage Print a short usage message and exit. .TP .if !'po4a'hide' .BR \-V ", " \-\-version diff --git a/man/man8/catman.man8 b/man/man8/catman.man8 index 087c97b2..38e2c78d 100644 --- a/man/man8/catman.man8 +++ b/man/man8/catman.man8 @@ -69,7 +69,7 @@ Use this user configuration file rather than the default of .if !'po4a'hide' .BR \-? ", " \-\-help Print a help message and exit. .TP -.if !'po4a'hide' .BR \-\-usage +.if !'po4a'hide' .B \-\-usage Print a short usage message and exit. .TP .if !'po4a'hide' .BR \-V ", " \-\-version diff --git a/man/man8/mandb.man8 b/man/man8/mandb.man8 index 84ab3e69..847583c4 100644 --- a/man/man8/mandb.man8 +++ b/man/man8/mandb.man8 @@ -136,7 +136,7 @@ Use this user configuration file rather than the default of .if !'po4a'hide' .BR \-? ", " \-\-help Show the usage message, then exit. .TP -.if !'po4a'hide' .BR \-\-usage +.if !'po4a'hide' .B \-\-usage Print a short usage message and exit. .TP .if !'po4a'hide' .BR \-V ", " \-\-version -- 2.25.1 -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.4.19-1 (SMP w/2 CPU cores) Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), LANGUAGE=is_IS.iso88591 (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages man-db depends on: ii bsdmainutils 11.1.2+b1 ii debconf [debconf-2.0] 1.5.73 ii dpkg 1.19.7 ii groff-base 1.22.4-4 ii libc6 2.30-2 ii libgdbm6 1.18.1-5 ii libpipeline1 1.5.2-2 ii libseccomp22.4.3-1 ii zlib1g 1:1.2.11.dfsg-2 man-db recommends no packages. Versions of packages man-db suggests: pn apparmor ii elinks [www-browser] 0.13.1-1 ii firefox-esr [www-browser] 68.6.0esr-1 ii groff 1.22.4-4 ii less 551-1 ii lynx [www-browser] 2.9.0dev.5-1 ii w3m [www-browser] 0.5.3-37+b1 -- debconf information excluded -- Bjarni I. Gislason
Bug#955186: pbuilder: please have --login run the default login shell, when not bash
Package: pbuilder
Version: 0.230.4
Severity: wishlist
Tags: upstream patch
Dear Maintainer,
«pbuilder --login» is implemented as follows:
58 --login|login|l)
⋮
76 executehooks "F"
77 (${CHROOTEXEC} bash -c 'exec -a -bash bash')
78 RET=$?
This launches bash even if the chroot's /etc/passwd specifies another
shell.
Please execute the passwd(5)-specified login shell by default.
The following works for me, but please review.
[[[
diff --git a/pbuilder b/pbuilder
index ccd7cc0..3067656 100755
--- a/pbuilder
+++ b/pbuilder
@@ -74,7 +74,8 @@ case "$1" in
fi
executehooks "F"
-(${CHROOTEXEC} bash -c 'exec -a -bash bash')
+loginshell=$(${CHROOTEXEC} getent passwd root | cut -d: -f7)
+(${CHROOTEXEC} bash -c 'exec -a "-$1" "$1"' . "${loginshell}")
RET=$?
save_aptcache
]]]
Cheers,
Daniel
P.S. For completeness, my use-case: I have an F hook that chsh's to zsh
because I'd like --login sessions to use zsh by default.
Bug#954142: mypaint: does not start
Package: mypaint Followup-For: Bug #954142 Dear Maintainer, As you said, the python3 update to 3.8.2 works for me respect this Mypaint issue. Now it is not required the symbolic link, and Mypaint works flawless. Thanks. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 5.4.0-4-686-pae (SMP w/2 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=es_ES.utf8, LC_CTYPE=es_ES.utf8 (charmap=UTF-8), LANGUAGE=es_ES.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mypaint depends on: ii gir1.2-gtk-3.0 3.24.14-1 ii libc6 2.30-2 ii libgcc-s1 10-20200324-1 ii libgdk-pixbuf2.0-0 2.40.0+dfsg-3 ii libglib2.0-02.64.1-1 ii libgomp110-20200324-1 ii liblcms2-2 2.9-4+b1 ii libmypaint-1.5-11.5.1-1 ii libpng16-16 1.6.37-2 ii libstdc++6 10-20200324-1 ii mypaint-brushes 2.0.2+ds1-1 ii mypaint-data2.0.0-1 ii python3 3.8.2-2 ii python3-gi 3.34.0-6 ii python3-gi-cairo3.34.0-6 ii python3-numpy 1:1.17.4-5 Versions of packages mypaint recommends: ii mypaint-data-extras 2.0.0-1 ii shared-mime-info 1.10-1 mypaint suggests no packages. -- no debconf information
Bug#954657: closed by Debian FTP Masters (Bug#954657: Removed package(s) from unstable)
Control: reopen -1 Dear FTP Masters, Could you please remove the s390x, mipsel and mips64el binaries for libkodiplatform-dev and all binaries of libkodiplatform16, too? Thanks, Balint Debian Bug Tracking System ezt írta (időpont: 2020. márc. 22., V, 16:15): > > This is an automatic notification regarding your Bug report > which was filed against the ftp.debian.org package: > > #954657: RM: kodi [s390x, mipsel, mips64el] -- RoM; NBS > > It has been closed by Debian FTP Masters . > > Their explanation is attached below along with your original report. > If this explanation is unsatisfactory and you have not received a > better one in a separate message then please contact Debian FTP Masters > by > replying to this email. > > > -- > 954657: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954657 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems > > > > -- Forwarded message -- > From: Debian FTP Masters > To: 954657-cl...@bugs.debian.org > Cc: xbmc-pvr-add...@packages.debian.org > Bcc: > Date: Sun, 22 Mar 2020 15:11:50 + > Subject: Bug#954657: Removed package(s) from unstable > We believe that the bug you reported is now fixed; the following > package(s) have been removed from unstable: > > xbmc-pvr-argustv | 13.0+git20140512+g91cc731+dfsg1-3 | mipsel, s390x > xbmc-pvr-argustv | 13.0+git20140512+g91cc731+dfsg1-3+b1 | mips64el > xbmc-pvr-dvbviewer | 13.0+git20140512+g91cc731+dfsg1-3 | mipsel, s390x > xbmc-pvr-dvbviewer | 13.0+git20140512+g91cc731+dfsg1-3+b1 | mips64el > xbmc-pvr-iptvsimple | 13.0+git20140512+g91cc731+dfsg1-3 | mipsel, s390x > xbmc-pvr-iptvsimple | 13.0+git20140512+g91cc731+dfsg1-3+b1 | mips64el > xbmc-pvr-mediaportal-tvserver | 13.0+git20140512+g91cc731+dfsg1-3 | mipsel, > s390x > xbmc-pvr-mediaportal-tvserver | 13.0+git20140512+g91cc731+dfsg1-3+b1 | > mips64el > xbmc-pvr-mythtv-cmyth | 13.0+git20140512+g91cc731+dfsg1-3 | mipsel, s390x > xbmc-pvr-mythtv-cmyth | 13.0+git20140512+g91cc731+dfsg1-3+b1 | mips64el > xbmc-pvr-nextpvr | 13.0+git20140512+g91cc731+dfsg1-3 | mipsel, s390x > xbmc-pvr-nextpvr | 13.0+git20140512+g91cc731+dfsg1-3+b1 | mips64el > xbmc-pvr-njoy | 13.0+git20140512+g91cc731+dfsg1-3 | mipsel, s390x > xbmc-pvr-njoy | 13.0+git20140512+g91cc731+dfsg1-3+b1 | mips64el > xbmc-pvr-tvheadend-hts | 13.0+git20140512+g91cc731+dfsg1-3 | mipsel, s390x > xbmc-pvr-tvheadend-hts | 13.0+git20140512+g91cc731+dfsg1-3+b1 | mips64el > xbmc-pvr-vdr-vnsi | 13.0+git20140512+g91cc731+dfsg1-3 | mipsel, s390x > xbmc-pvr-vdr-vnsi | 13.0+git20140512+g91cc731+dfsg1-3+b1 | mips64el > xbmc-pvr-vuplus | 13.0+git20140512+g91cc731+dfsg1-3 | mipsel, s390x > xbmc-pvr-vuplus | 13.0+git20140512+g91cc731+dfsg1-3+b1 | mips64el > xbmc-pvr-wmc | 13.0+git20140512+g91cc731+dfsg1-3 | mipsel, s390x > xbmc-pvr-wmc | 13.0+git20140512+g91cc731+dfsg1-3+b1 | mips64el > > --- Reason --- > RoM; ANAIS > -- > > Note that the package(s) have simply been removed from the tag > database and may (or may not) still be in the pool; this is not a bug. > The package(s) will be physically removed automatically when no suite > references them (and in the case of source, when no binary references > it). Please also remember that the changes have been done on the > master archive and will not propagate to any mirrors until the next > dinstall run at the earliest. > > Packages are usually not removed from testing by hand. Testing tracks > unstable and will automatically remove packages which were removed > from unstable when removing them from testing causes no dependency > problems. The release team can force a removal from testing if it is > really needed, please contact them if this should be the case. > > Bugs which have been reported against this package are not automatically > removed from the Bug Tracking System. Please check all open bugs and > close them or re-assign them to another package if the removed package > was superseded by another one. > > The version of this package that was in Debian prior to this removal > can still be found using http://snapshot.debian.org/. > > Thank you for reporting the bug, which will now be closed. If you > have further comments please address them to 954...@bugs.debian.org. > > The full log for this bug can be viewed at https://bugs.debian.org/954657 > > This message was generated automatically; if you believe that there is > a problem with it please contact the archive administrators by mailing > ftpmas...@ftp-master.debian.org. > > Debian distribution maintenance software > pp. > Scott Kitterman (the ftpmaster behind the curtain) > > > -- Forwarded message -- > From: "Bálint Réczey" > To: Debian Bug Tracking System > Cc: > Bcc: > Date: Sun, 22 Mar 2020 12:52:39 +0100 > Subject: RM: kodi [s390x, mipsel, mips64el] -- RoM; NBS > Package: ftp.debian.org > Severity: normal > > Please remove s390x and mips* binary packages of kodi and reverse > dependencies
Bug#922103: column man page: most options need examples to make them understandable
retitle 922103 column man page: most options need examples to make them understandable thanks OK, I am making progress at understanding -s: $ echo axbxc|column -t -s x a b c So it is talking about INPUT columns. The man page should mention it. Anyway, most of the options mentioned on the man page need minimal examples with output to make clear what they do.
Bug#950112: gplaycli: 502 Bad Gateway, does not work at all
Control: tags -1 + fixed-upstream On Tue, 28 Jan 2020 23:50:24 +0100 Thorsten Glaser wrote: > After installation, gplaycli --help works (but please do add > a manual page), but nothing else: The error is now different: $ gplaycli -d com.skype.raider [ERROR] Unknown error: New version of protocol release. Update gplaycli and check https://github.com/matlink/gplaycli There is a new upstream release that fixes this and the other errors, please update to version 3.29: https://github.com/matlink/gplaycli/releases/tag/3.29 I also think that you should ask for removal of the package from Debian earlier Debian releases, since it is very broken there now. https://www.debian.org/doc/manuals/developers-reference/developer-duties.en.html#maintain-packages-in-stable $ rmadison gplaycli debian: gplaycli | 0.2.1-1 | oldstable | source, all gplaycli | 3.25+ds-1~bpo9+1 | stretch-backports | source, all gplaycli | 3.25+ds-1| stable| source, all gplaycli | 3.27+dfsg-1 | unstable | source, all You can request removal from stretch and buster by doing this: * run: `reportbug release.debian.org` * select: 5 rm Stable/Testing removal requests * enter the version: buster 3.25+ds-1, stretch 0.2.1-1 * enter No specific architectures * enter an explanation: Google Play API changes broke the tool * send the bug report Repeat these steps for each of stretch and buster. For the stretch-backports suite I think you would need to send a mail to the backports mailing list asking for it to be removed. https://backports.debian.org/Contribute/ -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#955185: manuals: Fix a misuse of two-fonts macros
Package: man-db Version: 2.9.1-1 Severity: minor Tags: patch Dear Maintainer, >From 3ad15490cfb9db6d574c4aba07fec174b6b21b26 Mon Sep 17 00:00:00 2001 >From: Bjarni Ingi Gislason >Date: Sat, 28 Mar 2020 00:54:26 + >Subject: [PATCH] man/man1/*: Fix misuse of two-fonts marcros Correct the misuse of a two-fonts macro, which function is to 1) use the first font for each odd numbered argument and the second font for all others. 2) join (output) the arguments without an intervening space. ### Output is from: test-groff -b -e -mandoc -T utf8 -rF0 -t -w w -z [ "test-groff" is a developmental version of "groff" ] :90 (macro BR): only 1 argument, but more are expected :79 (macro IR): only 1 argument, but more are expected :60 (macro IR): only 1 argument, but more are expected :181 (macro BR): only 1 argument, but more are expected :41 (macro BR): only 1 argument, but more are expected Signed-off-by: Bjarni Ingi Gislason --- man/man1/lexgrog.man1| 2 +- man/man1/man-recode.man1 | 2 +- man/man1/man.man1| 2 +- man/man1/whatis.man1 | 2 +- man/man1/zsoelim.man1| 2 +- 5 files changed, 5 insertions(+), 5 deletions(-) diff --git a/man/man1/lexgrog.man1 b/man/man1/lexgrog.man1 index 30172a7f..18821686 100644 --- a/man/man1/lexgrog.man1 +++ b/man/man1/lexgrog.man1 @@ -87,7 +87,7 @@ Override the guessed character set for the page to .if !'po4a'hide' .BR \-? ", " \-\-help Print a help message and exit. .TP -.if !'po4a'hide' .BR \-\-usage +.if !'po4a'hide' .B \-\-usage Print a short usage message and exit. .TP .if !'po4a'hide' .BR \-V ", " \-\-version diff --git a/man/man1/man-recode.man1 b/man/man1/man-recode.man1 index 0705a570..e4ac8b82 100644 --- a/man/man1/man-recode.man1 +++ b/man/man1/man-recode.man1 @@ -57,7 +57,7 @@ Convert manual pages to .TP \fB\-\-suffix=\fIsuffix\fR Form each output file name by appending -.IR suffix +.I suffix to the input file name, after removing any compression extension. .TP .if !'po4a'hide' .B \-\-in\-place diff --git a/man/man1/man.man1 b/man/man1/man.man1 index 3e313aa6..be5ba8ce 100644 --- a/man/man1/man.man1 +++ b/man/man1/man.man1 @@ -76,7 +76,7 @@ to look only in that .I section of the manual. The default action is to search in all of the available -.IR sections +.I sections following a pre-defined order (see .BR DEFAULTS ), and to show only the first diff --git a/man/man1/whatis.man1 b/man/man1/whatis.man1 index 45c58c4e..2d18a2b3 100644 --- a/man/man1/whatis.man1 +++ b/man/man1/whatis.man1 @@ -178,7 +178,7 @@ Use this user configuration file rather than the default of .if !'po4a'hide' .BR \-? ", " \-\-help Print a help message and exit. .TP -.if !'po4a'hide' .BR \-\-usage +.if !'po4a'hide' .B \-\-usage Print a short usage message and exit. .TP .if !'po4a'hide' .BR \-V ", " \-\-version diff --git a/man/man1/zsoelim.man1 b/man/man1/zsoelim.man1 index 826b8321..4dca335e 100644 --- a/man/man1/zsoelim.man1 +++ b/man/man1/zsoelim.man1 @@ -38,7 +38,7 @@ where .I .ext can be one of .BR .gz , -.BR .Z +.B .Z or .BR .z . Other extension types may be supported depending upon compile time options. -- 2.25.1 -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.4.19-1 (SMP w/2 CPU cores) Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), LANGUAGE=is_IS.iso88591 (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages man-db depends on: ii bsdmainutils 11.1.2+b1 ii debconf [debconf-2.0] 1.5.73 ii dpkg 1.19.7 ii groff-base 1.22.4-4 ii libc6 2.30-2 ii libgdbm6 1.18.1-5 ii libpipeline1 1.5.2-2 ii libseccomp22.4.3-1 ii zlib1g 1:1.2.11.dfsg-2 man-db recommends no packages. Versions of packages man-db suggests: pn apparmor ii elinks [www-browser] 0.13.1-1 ii firefox-esr [www-browser] 68.6.0esr-1 ii groff 1.22.4-4 ii less 551-1 ii lynx [www-browser] 2.9.0dev.5-1 ii w3m [www-browser] 0.5.3-37+b1 -- debconf information excluded -- Bjarni I. Gislason
Bug#951696: certbot: Incompatibility with python3-urllib3=1.25.8-1
Hello Harlan,
thanks for forwarding this!
On Fri, Mar 27, 2020 at 11:43:36AM -0400, Harlan Lieberman-Berg wrote:
> reassign 951696 requests
> retitle 951696 requests: incompatibility between requests == 2.22.0-2
> and urllib3 == 1.25.8-1
> tag 951696 +unreproducible
> affects 951696 certbot python3-urllib3
> thanks
>
> I've looked over this several times over the last few months, and I
> can't reproduce the problem on any of my test systems. However,
> looking at the code, if this bug exists, it's definitely between
> requests and urllib3, not in certbot itself.
>
> Sending it over to the requests folks, in the hopes that they've seen
> this somewhere else and can reproduce it.
Unfortunately I never seen something like this but I will investigate.
I would exclude requests involvement for now, it seems more on urllib3 side,
but let's see (anyway no need to move this now, since I maintain also urllib3).
I strictly follow upstream for compatibility versions, so I'm more
inclined to ithink to an urllib3 bug.
I looked at the differences of urllib3.util.url.parse_url in 1.25.8-1 and
1.24.1-1: upstream moved to a more "ask forgiveness" approach, and we can see
a try/except block from line 360 to line 391.
The except is:
except (ValueError, AttributeError):
return six.raise_from(LocationParseError(source_url), None)
So although Python 3 can chain exceptions since None is passed to
six.raise_from, every exceptions of kind ValueError or AttributeError are
masked as the LocationParseError we see in the traceback that Alexandre posted.
This can hide a possible root cause and I would look at this first.
@Alexandre since it seems tricky to reproduce, meanwhile I setup a test
environment, please can you try to unmask the exception above?
You need only to edit the lines above (lines 391 and 392 of
/usr/lib/python3/dist-packages/urllib3/util/url.py) into:
except (ValueError, AttributeError) as exp:
return six.raise_from(LocationParseError(source_url), exp)
This way you should get also the traceback of another exception that is
eventually raised.
Or you can just rethrow `exp`: choose the way you prefer.
From the exception we get now it's not possible to understand what is
happening. The source_url mentioned in the first report is parsed fine in my
system with urllib3 1.25.8-1:
❯ python3 -c "from urllib3.util.url import parse_url;
print(repr(parse_url('https://acme-v02.api.letsencrypt.org/directory')))"
Url(scheme='https', auth=None, host='acme-v02.api.letsencrypt.org', port=None,
path='/directory', query=None, fragment=None)
So maybe there is something hidden somewhere.
Regards,
--
Daniele Tricoli 'eriol'
https://mornie.org
signature.asc
Description: PGP signature
Bug#953676: gedit: Bug appears to be fixed
Package: gedit Followup-For: Bug #953676 Dear Maintainer, Updated to 3.36.1 today External tool works fine now This bug can be closed :) Regards, Keyikedalube -- Package-specific info: -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IN.UTF-8, LC_CTYPE=en_IN.UTF-8 (charmap=UTF-8), LANGUAGE=en_IN.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 gedit depends on: ii gedit-common 3.36.1-1 ii gir1.2-glib-2.01.62.0-5+b1 ii gir1.2-gtk-3.0 3.24.14-1 ii gir1.2-gtksource-4 4.6.0-1 ii gir1.2-pango-1.0 1.42.4-8 ii gir1.2-peas-1.01.26.0-2 ii gsettings-desktop-schemas 3.36.0-1 ii iso-codes 4.4-1 ii libamtk-5-05.0.2-1 ii libatk1.0-02.34.1-1 ii libc6 2.30-4 ii libcairo2 1.16.0-4 ii libgdk-pixbuf2.0-0 2.40.0+dfsg-3 ii libgirepository-1.0-1 1.62.0-5+b1 ii libglib2.0-0 2.64.1-1 ii libgspell-1-2 1.8.3-1 ii libgtk-3-0 3.24.14-1 ii libgtksourceview-4-0 4.6.0-1 ii libpango-1.0-0 1.42.4-8 ii libpeas-1.0-0 1.26.0-2 ii libtepl-4-04.4.0-1 ii libx11-6 2:1.6.9-2 ii python33.8.2-2 ii python3-gi 3.36.0-1 ii python3-gi-cairo 3.36.0-1 ii python3.8 3.8.2-1 Versions of packages gedit recommends: ii yelp3.34.0-1 ii zenity 3.32.0-5 Versions of packages gedit suggests: pn gedit-plugins -- no debconf information
Bug#955184: RFS: gramophone2/0.8.13a-3.1 [NMU, RC] -- GRAMophone II is an algorithmic music generator
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "gramophone2" * Package name: gramophone2 Version : 0.8.13a-3.1 Upstream Author : Giovanni Ferranti * URL : http://gramophone2.sourceforge.net/ * License : GPL-2.0+ * Vcs : None Section : sound It builds those binary packages: gramophone2 - GRAMophone II is an algorithmic music generator To access further information about this package, please visit the following URL: https://mentors.debian.net/package/gramophone2 Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/g/gramophone2/gramophone2_0.8.13a-3.1.dsc Changes since the last upload: * Non-maintainer upload. * Fix ftbfs with GCC. (Closes: #925704) -- Regards Sudip
Bug#925704: gramophone2: diff for NMU version 0.8.13a-3.1
Control: tags 925704 + patch Control: tags 925704 + pending Dear maintainer, I've prepared an NMU for gramophone2 (versioned as 0.8.13a-3.1) and uploaded it to mentors for sponsoring. Please feel free to tell me if I should remove it. -- Regards Sudip diff -Nru gramophone2-0.8.13a/debian/changelog gramophone2-0.8.13a/debian/changelog --- gramophone2-0.8.13a/debian/changelog2014-01-28 22:35:12.0 + +++ gramophone2-0.8.13a/debian/changelog2020-03-28 00:24:28.0 + @@ -1,3 +1,10 @@ +gramophone2 (0.8.13a-3.1) unstable; urgency=medium + + * Non-maintainer upload. + * Fix ftbfs with GCC. (Closes: #925704) + + -- Sudip Mukherjee Sat, 28 Mar 2020 00:24:28 + + gramophone2 (0.8.13a-3) unstable; urgency=medium * switched to quilt patch system, migrated all the existing patches. diff -Nru gramophone2-0.8.13a/debian/patches/fix_gcc.patch gramophone2-0.8.13a/debian/patches/fix_gcc.patch --- gramophone2-0.8.13a/debian/patches/fix_gcc.patch1970-01-01 01:00:00.0 +0100 +++ gramophone2-0.8.13a/debian/patches/fix_gcc.patch2020-03-28 00:23:54.0 + @@ -0,0 +1,27 @@ +Description: Fix FTBFS with GCC + +Author: Sudip Mukherjee + +--- + +--- gramophone2-0.8.13a.orig/Makefile gramophone2-0.8.13a/Makefile +@@ -1,7 +1,8 @@ + CC=gcc + #CFLAGS+=-O2 + #Decomment this line if you use Linux: +-CFLAGS+=-O2 -lm ++CFLAGS+=-O2 ++LIBS+=-lm + + DESTDIR=/usr/local + +@@ -9,7 +10,7 @@ default: GRAMophone.tab.c + $(CC) $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) -o gramophone2 GRAMophone.c\ + grammyVM.c init.c midicode.c\ + midifile.c expcode.c debug.c errors.c\ +- hash.c GRAMophone.tab.c ++ hash.c GRAMophone.tab.c $(LIBS) + + GRAMophone.tab.c: lex.yy.c + bison -d GRAMophone.y diff -Nru gramophone2-0.8.13a/debian/patches/series gramophone2-0.8.13a/debian/patches/series --- gramophone2-0.8.13a/debian/patches/series 2014-01-28 10:48:24.0 + +++ gramophone2-0.8.13a/debian/patches/series 2020-03-28 00:24:24.0 + @@ -1,3 +1,4 @@ Makefile.diff GRAMophone.y.diff grammyVM.c.diff +fix_gcc.patch
Bug#955182: The homepage given is not available nor accessible anymore.
Package: python3-l20n Version: 4.0.0~a1-5 Severity: normal Dear Maintainer, The homepage given when you use aptitude show python3-l20n doesn't exist and isn't accessible anymore. I tried the following - $ curl http://l20n.org/ curl: (6) Could not resolve host: l20n.org $ curl https://l20n.org/ curl: (6) Could not resolve host: l20n.org As can be seen the l20n.org is no longer there. Please fix and share the correct hyperlink. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (900, 'testing'), (500, 'testing-debug'), (100, 'unstable-debug'), (100, 'experimental'), (100, 'unstable'), (50, 'experimental-debug') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE=en_IN:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-l20n depends on: ii python3 3.8.2-2 ii python3-six 1.14.0-2 python3-l20n recommends no packages. python3-l20n suggests no packages. -- no debconf information -- Regards, Shirish Agarwal शिरीष अग्रवाल My quotes in this email licensed under CC 3.0 http://creativecommons.org/licenses/by-nc/3.0/ http://flossexperiences.wordpress.com E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C
Bug#955183: column's minimal output separation is hardwired at 2
Package: bsdmainutils Version: 11.1.2+b1 Starting with: Los_Angeles: Tue Jan 21 06:00 PM 2020 Chicago: Tue Jan 21 06:00 PM 2020 Taipei: Tue Jan 21 06:00 PM 2020 We pipe it through column -t: Los_Angeles: Tue Jan 21 06:00 PM 2020 Chicago: Tue Jan 21 06:00 PM 2020 Taipei: Tue Jan 21 06:00 PM 2020 What we simply really want is: Los_Angeles: Tue Jan 21 06:00 PM 2020 Chicago: Tue Jan 21 06:00 PM 2020 Taipei: Tue Jan 21 06:00 PM 2020 The only way to get it is via: column -t | perl -pwle 's/\S\K / /g;' because for some reason column(1)'s minimal output separation is hardwired at two spaces, with no variable to make it e.g., 1. P.S., no value of -c helps.
Bug#953883: Please backport version 20 for buster
Chris Lamb wrote: > I will backport this to buster once this migrates to bullseye. I have now done so. Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org 🍥 chris-lamb.co.uk `-
Bug#954287: libfiu: FTBFS on amd64/unstable: Segmentation fault (core dumped)
Hi Alberto, > libfiu now fails to build from source in unstable/amd64: > > […] > > ./wrap-python 3 ./test-set_prng_seed.py > LD_LIBRARY_PATH=../../libfiu/ > LD_PRELOAD="../../preload/run/fiu_run_preload.so > ../../preload/posix/fiu_posix_preload.so" ./tests/open.bin > LD_LIBRARY_PATH=../../libfiu/ > LD_PRELOAD="../../preload/run/fiu_run_preload.so > ../../preload/posix/fiu_posix_preload.so" ./tests/fread.bin > rm tests/open.bin tests/fread.bin./wrap-python 3 ./test-fiu_ctrl.py >tests/open64.bin tests/strdup.bin tests/pread.bin tests/pread64.bin > tests/malloc.bin./wrap-python 3 ./test-basic.py >tests/mmap.bin tests/fprintf.bin tests/kill.bin tests/fopen.bin > make[4]: Leaving directory '/tmp/buildd/libfiu-1.00/tests/generated' > ./wrap-python 3 ./test-onetime.py > ./wrap-python 3 ./test-set_prng_seed-env.py > make[3]: *** [Makefile:96: py-run-test-failinfo_refcount] > Segmentation fault (core dumped) > make[3]: *** Waiting for unfinished jobs > make[4]: Leaving directory '/tmp/buildd/libfiu-1.00/tests/utils' > rm test-enable_stack test-ferror test-enable_stack_by_name > make[3]: Leaving directory '/tmp/buildd/libfiu-1.00/tests' > make[2]: *** [Makefile:58: test] Error 2 > make[2]: Leaving directory '/tmp/buildd/libfiu-1.00' > dh_auto_test: error: make -j9 test V=1 LC_ALL=C returned exit code 2 > make[1]: *** [debian/rules:33: override_dh_auto_test] Error 25 > make[1]: Leaving directory '/tmp/buildd/libfiu-1.00' > make: *** [debian/rules:13: binary] Error 2 > dpkg-buildpackage: error: debian/rules binary subprocess returned > exit status 2 > > […] > > I suspect this to be Python 3.8 related. Alberto, any ideas? :) The > full build log is attached if it helps. Wondering if you got this? I just got a mail that libfiu will be "autoremoved" from testing soon. Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org 🍥 chris-lamb.co.uk `-
Bug#955181: Subject: adequate reports broken symlink for libjs-sprintf-js
Package: libjs-sprintf-js Version: 1.1.2+ds1-1 Severity: normal User : debian...@lists.debian.org Usertags : broken-symlink adequate Dear Maintainer, I was installing some binaries when I came across the following - libjs-sprintf-js: broken-symlink /usr/share/doc/libjs-sprintf-js/examples/angular.min.js -> ../../../javascript/angular.js/angular.min.js $ cd /usr/share/doc/javascript bash: cd: /usr/share/doc/javascript: No such file or directory I did try a few combinations but none of the combinations worked. Please fix the same. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (900, 'testing'), (500, 'testing-debug'), (100, 'unstable-debug'), (100, 'experimental'), (100, 'unstable'), (50, 'experimental-debug') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE=en_IN:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled libjs-sprintf-js depends on no packages. Versions of packages libjs-sprintf-js recommends: ii javascript-common 11 Versions of packages libjs-sprintf-js suggests: pn libjs-angularjs -- no debconf information -- Regards, Shirish Agarwal शिरीष अग्रवाल My quotes in this email licensed under CC 3.0 http://creativecommons.org/licenses/by-nc/3.0/ http://flossexperiences.wordpress.com E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C
Bug#955180: recommonmark: please package newer version 0.5 or 0.6 to be able to use it as a sphinx extension
Source: recommonmark
Version: 0.4.0+ds-6
Severity: normal
Dear Maintainer,
When building docs using the currently in experimental sphinx 2.4.3
and recommonmark, a warning is issued by Sphinx:
```
RemovedInSphinx30Warning: The config variable "source_parsers" is
deprecated. Please update your extension for the parser and remove the
setting.
```
Currently, with recommonmark 0.4, the only way to use it is apparently to
have this in conf.py (I'm not a Sphinx expert :)):
```
from recommonmark.parser import CommonMarkParser
source_parsers = {
'.md': CommonMarkParser,
}
source_suffix = ['.rst', '.md']
```
To be able to use recommonmark as an extension as it is documented by
upstream [0], recommonmark 0.5.0 must be used. Earlier versions like 0.4
does not implement the setup() in __init__.py function required to be an
extension.
=> So for this reason, please can you package a more recent version of
recommonmark ? (Maybe there is a particular reason for it being stuck at
version 0.4 ?)
[0] https://recommonmark.readthedocs.io/en/latest/#getting-started
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.4.0-3-amd64 (SMP w/10 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8),
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Bug#955175: byacc.1: Fix usage of two-fonts macros
On Fri, Mar 27, 2020 at 10:34:41PM +, Bjarni Ingi Gislason wrote: > Package: byacc > Version: 20140715-1+b1 That's very old -- I see that Debian's package is about 5 years out of date (which makes any bug reports pointless). -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Bug#885282: gameclock: Depends on unmaintained pygtk
On 2020-03-27 22:44:31, Moritz Mühlenhoff wrote: > On Sat, Jan 06, 2018 at 01:01:28PM -0500, Antoine Beaupré wrote: >> Control: forwarded -1 https://gitlab.com/anarcat/gameclock/issues/1 >> >> Understood. > > Hi Antoine, > let's remove gameclock from the archive for now? When ported it > can still be reintroduced, but currently it's among the last > handful of packages blocking the pygtk removal. Yes, please proceed, thanks. a. -- For every complex problem, there is an answer that is clear, simple - and wrong. - H.L. Mencken
Bug#955179: RM: securepass-tools -- RoQA; Depends on Python 2, project abandoned
Package: ftp.debian.org Severity: normal Please remove securepass-tools. It depends on Python 2 and SecurePass was shutdown in the mean time, so upstream vanished: http://www.gippa.net/securepass-eol Cheers, Moritz
Bug#949694: tasksel: Please drop all kde-l10n packages
Hi, Lisandro Damián Nicanor Pérez Meyer wrote: > Hi! > > On Sun, 15 Mar 2020 at 03:57, Holger Wansing wrote: > > > > Hi, > > > > Wolfgang Schweer wrote: > > > Package: tasksel > > > Version: 3.58 > > > Severity: normal > > > > > > Hi, > > > > > > all kde-l10n packages are no longer available. They have been removed > > > from unstable and testing some time ago, see: > > > https://tracker.debian.org/pkg/kde-l10n > > > > > > See also the related bug: > > > https://bugs.debian.org/935665 > > > > > > (As far as I can tell, translations are now contained in the > > > libkf5i18n-data package, which is installed as a kde dependency.) > > > > Hmm, libkf5i18n-data was already existing in buster, and it has nearly the > > same filesize in sid compared to buster, so it seems that it does not > > contain > > additional translations which have been dropped from kde-l10n-* > > > > kde-l10n-* packages contain masses of .mo files, which I cannot find > > anymore in unstable. Where have all those translations gone? > > > > CC'ing kde people for advise. > > If I remember correctly (I'm more with the Qt side of things) most of > the translations are part of the applications themselves since > Plasma/KF 5. libkf5i18n-data should clearly stay. Ok, so I will drop all the kde-l10n-* packages from the tasks shortly. Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#955178: RM: go2 -- RoQA; Depends on Python 2, unmaintained, dead upstream, RC-buggy
Package: ftp.debian.org Severity: normal Please remove go2. It's dead upstream (no activity after 2013), depends on Python 2 and the last maintainer upload was in 2012. It also has open RC bugs (935204, 928324) Cheers, Moritz
Bug#955176: LGPL license missing
Package: syrthes Version: 4.3.5+20200129-dfsg1-1~exp1 Severity: serious thanks Dear Maintainer, please add the missing LGPL licenses of some header files to your debian/copyright. Thanks! Thorsten
Bug#955177: RM: python-nids -- RoQA; Depends on Python 2, dead upstream, no reverse deps
Package: ftp.debian.org Severity: normal Please remove python-nids. It depends on Python 2, is dead upstream, there are no reverse deps and the last maintainer upload was in 2010. Cheers, Moritz
Bug#947351: package cloud-init
On Wed, Mar 25, 2020 at 11:24:07PM +0100, Arnaud MORIN wrote: >Of course I can do some tests. >Is the package available somewhere? OK, please grab and test the .deb from https://people.debian.org/~noahm/cloud-init/ Note that currently the package is named as though it's going to be uploaded to buster-backports. The hope is to get it in through stable-updates, in which case it'll be rebuilt with a different name. The sources are signed with my public key. The .deb has the following sha256sum 37699358fc376793f9f72e0e6ff80006f814b043cacdafedbef051599780b3f0 cloud-init_20.1-2~bpo10+1_all.deb Any feedback on this is welcome. Please let me know what specific features you test (e.g. user creation, cloud-config package installation, shell scripts, etc) and the details of the platform on which you're testing. Thanks noah signature.asc Description: PGP signature
Bug#937940: python-nemu: Python2 removal in sid/bullseye
On Fri, Aug 30, 2019 at 07:42:40AM +, Matthias Klose wrote: > Package: src:python-nemu > Version: 0.3.1-1 > Severity: normal > Tags: sid bullseye > User: debian-pyt...@lists.debian.org > Usertags: py2removal > > Python2 becomes end-of-live upstream, and Debian aims to remove > Python2 from the distribution, as discussed in > https://lists.debian.org/debian-python/2019/07/msg00080.html Hi Martina, given that you're also the upstream of python-nemu, are you planning to port it to Python 3 or should it be removed? Cheers, Moritz
Bug#955174: nautilus-nextcloud: nextcloud submenu not shown for files with french accents in their name
Package: nautilus-nextcloud Version: 2.5.1-3+deb10u1 Severity: normal Tags: upstream Dear Maintainer, in nautilus, right clicking on a file synchronized with nextcloud client does not show any "nextcloud" submenu if that file name contains accented characters, while if it does not the "nextcloud" submenu is properly shown. Thanks for taking care of that report (unfortunately I could not test the testing and unstable nautilus-nextcloud packages to see if this is fixed, since I'm only using Debian stable on my work computer). Regards Denis -- System Information: Debian Release: 10.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-8-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages nautilus-nextcloud depends on: ii nautilus 3.30.5-2 ii nextcloud-desktop 2.5.1-3+deb10u1 ii nextcloud-desktop-common 2.5.1-3+deb10u1 ii python-nautilus 1.2.2-2 nautilus-nextcloud recommends no packages. Versions of packages nautilus-nextcloud suggests: pn nautilus-script-manager -- no debconf information
Bug#955152: git-rebase ignores or squashes GIT_REFLOG_ACTION
reassign 955152 git
found 955152 + 1:2.26.0-1
notfound 955152 + 1:2.25.1-1 1:2.11.0-3+deb9u5
retitle 955152 git-rebase ignores or squashes GIT_REFLOG_ACTION
user debian...@lists.debian.org
usertags 955152 - needs-update
thanks
Hi all. Thanks to Paul for actually filing this bug.
tl;dr: I think this is a regression in src:git and that the test case
in src:dgit is correct and will pass once the git regression is gone.
Paul Gevers writes ("Bug#955152: git breaks dgit autopkgtest: gdr-newupstream
test failed"):
>passfail
> gitfrom testing1:2.26.0-1
> dgit from testing9.10
> all others from testingfrom testing
...
> I copied some of the output at the bottom of this report. Unfortunately
> I couldn't spot where the real error is reported.
Sorry that the test output is not as readable as it could be. I have
a patch to improve this but it would still not be very easy to see
since it's not clear from the log why the test is grepping as it does.
The real error, causing the test failure, is this:
[ some git-debrebase invocation etc. ]
+ git reflog
+ egrep 'debrebase new-upstream.*checkout'
+ rc=1
I have looked at the log and repro'd the bug.
git-debrebase (which lives in src:dgit but does not depend on dgit)
must invoke git-rebase. It sets GIT_REFLOG_ACTION so that the reflog
is comprehensible to the user. In previous versions of git this works
as expected. In 2.26.0-1 it does not.
This is easy to reproduce by running
GIT_REFLOG_ACTION='zeeks!' git rebase --onto
with arguments implying a nontrivial rebase.
The test suite in src:dgit, which is the checks that its
GIT_REFLOG_ACTION manipulation is effective, and it is this test which
has now failed and which is blocking the migration of git.
git-rebrebase in sid produces quite different looking reflog entries.
I guess the code for generating the messages has changed and that
git-rebase is now *setting* GIT_REFLOG_ACTION (or the equivalent
internal variable) rather than adding to it.
ISTM that to preserve the documented semantics, it is basically always
wrong of anything to unconditionally set GIT_REFLOG_ACTION. In
src:dgit I have a small bit of code to arrange to always *add* to
GIT_REFLOG_ACTION, if it is already set. There might be several
precise ways to add to GIT_REFLOG_ACTION but the failing test case
here should be happy with any reasonable choice.
So I think all will be well when there is a version of git in sid
which does not have this (new) bug.
> Currently this regression is blocking the migration of git 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?
I hope what I have done with the bug (i) has the right syntax and did
what I hoped and (ii) meets with everyone's approval.
Regards,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#955060: streamlink: FTBFS with Sphinx 2.4: dh_sphinxdoc: error: debian/python3-streamlink-doc/usr/share/doc/python3-streamlink/html/_static/js/modernizr.min.js is missing
Hi, Le 27/03/2020 à 15:52, Lucas Nussbaum a écrit : > Hi, > > streamlink fails to build with Sphinx 2.4, currently available in > experimental. Thanks Lucas for your notification about that failure. > [snip] >> dh_sphinxdoc: error: >> debian/python3-streamlink-doc/usr/share/doc/python3-streamlink/html/_static/js/modernizr.min.js >> is missing >> make: *** [debian/rules:14: binary] Error 25 > I've found that the error comes from dh_sphinxdoc which does a new sanity check and check that all scripts referenced by `search.html` exists within the package. The missing script is in a
Bug#955175: byacc.1: Fix usage of two-fonts macros
Package: byacc
Version: 20140715-1+b1
Severity: minor
Tags: patch
Dear Maintainer,
Correct the misuse of a two-fonts macro, which function is to
1) use the first font for each odd numbered argument and the second
font for all others.
2) join the arguments without an intervening space.
###
Output is from: test-groff -b -e -mandoc -T utf8 -rF0 -t -w w -z
[ "test-groff" is a developmental version of "groff" ]
Input file is .//usr/share/man/man1/byacc.1.gz
:47 (macro IR): only 1 argument, but more are
expected
:56 (macro IR): only 1 argument, but more are
expected
:58 (macro IR): only 1 argument, but more are
expected
:65 (macro BR): only 1 argument, but more are
expected
:74 (macro BR): only 1 argument, but more are
expected
:79 (macro BR): only 1 argument, but more are
expected
:118 (macro IR): only 1 argument, but more are
expected
:120 (macro BR): only 1 argument, but more are
expected
:132 (macro IR): only 1 argument, but more are
expected
:134 (macro IR): only 1 argument, but more are
expected
:176 (macro IR): only 1 argument, but more are
expected
###
Patch:
--- byacc.1 2020-03-27 22:21:02.0 +
+++ byacc.1.new 2020-03-27 22:23:27.0 +
@@ -44,7 +44,7 @@ The parsers consist of a set of LALR(1)
written in the C programming language.
.B Yacc
normally writes the parse tables and the driver routine to the file
-.IR y.tab.c.
+.IR y.tab.c .
.PP
The following options are available:
.TP 5
@@ -53,16 +53,16 @@ The
.B \-b
option changes the prefix prepended to the output file names to
the string denoted by
-.IR file_prefix.
+.IR file_prefix .
The default prefix is the character
-.IR y.
+.IR y .
.TP
.B \-B
create a backtracking parser (compile-type configuration for \fBbtyacc\fP).
.TP
.B \-d
The \fB-d\fR option causes the header file
-.BR y.tab.h
+.B y.tab.h
to be written.
It contains #define's for the token identifiers.
.TP
@@ -71,12 +71,12 @@ The
.B \-g
option causes a graphical description of the generated LALR(1) parser to
be written to the file
-.BR y.dot
+.B y.dot
in graphviz format, ready to be processed by dot(1).
.TP
.B \-i
The \fB-i\fR option causes a supplementary header file
-.BR y.tab.i
+.B y.tab.i
to be written.
It contains extern declarations
and supplementary #define's as needed to map the conventional \fIyacc\fP
@@ -115,9 +115,9 @@ The
.B \-p
option changes the prefix prepended to yacc-generated symbols to
the string denoted by
-.IR symbol_prefix.
+.IR symbol_prefix .
The default prefix is the string
-.BR yy.
+.BR yy .
.TP
.B \-P
create a reentrant parser, e.g., \*(``%pure-parser\*(''.
@@ -129,9 +129,9 @@ option causes
.B yacc
to produce separate files for code and tables.
The code file is named
-.IR y.code.c,
+.IR y.code.c ,
and the tables file is named
-.IR y.tab.c.
+.IR y.tab.c .
The prefix \*(``\fIy.\fP\*('' can be overridden using the \fB\-b\fP option.
.TP
.B \-s
@@ -173,7 +173,7 @@ The
.B \-v
option causes a human-readable description of the generated parser to
be written to the file
-.IR y.output.
+.IR y.output .
.TP
.B \-V
print the version number to the standard output.
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.4.19-1 (SMP w/2 CPU cores)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1),
LANGUAGE=is_IS.iso88591 (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages byacc depends on:
ii libc6 2.30-2
byacc recommends no packages.
byacc suggests no packages.
-- no debconf information
--
Bjarni I. Gislason
Bug#955144: libclang-dev: package could not be installed
It was the first time I reported a bug, as far as I remember. Anyway, there seems to be some kind of "conflict" between the version which would be installed of libgcc-8-dev and the already installed one of libgcc-s1. Do you agree? Thanks On Fri, Mar 27, 2020 at 7:24 PM Sylvestre Ledru wrote: > Yeah, I think this is a problem with gcc-8. I had that too on some system. > > S > > Le 27/03/2020 à 23:22, Mauricio Calvao a écrit : > > Dear Sylvestre, > > > > Let me be quite explicit about what is happening here within my Debian > > sid(uction) KDE desktop machine. > > > > > yeah, please more explicit in the future with your bugs ;) > > > S > > > -- ### Prof. Mauricio Ortiz Calvao Federal University of Rio de Janeiro Institute of Physics, P O Box 68528 CEP 21941-972 Rio de Janeiro, RJ Brazil Email: o...@if.ufrj.br Phone: (55)(21)39387483 Homepage: http://www.if.ufrj.br/~orca ###
Bug#955144: libclang-dev: package could not be installed
Yeah, I think this is a problem with gcc-8. I had that too on some system. S Le 27/03/2020 à 23:22, Mauricio Calvao a écrit : Dear Sylvestre, Let me be quite explicit about what is happening here within my Debian sid(uction) KDE desktop machine. yeah, please more explicit in the future with your bugs ;) S
Bug#955144: libclang-dev: package could not be installed
Dear Sylvestre, Let me be quite explicit about what is happening here within my Debian sid(uction) KDE desktop machine. When, always as root of course, I issue the command: apt install libclang-dev I get the output: Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libclang-dev : Depends: libclang-9-dev (>= 9~) but it is not going to be installed Then, when I try: apt install libclang-9-dev I get: Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libclang-9-dev : Depends: libstdc++-8-dev but it is not going to be installed Depends: libgcc-8-dev but it is not going to be installed Depends: libobjc-8-dev but it is not going to be installed E: Unable to correct problems, you have held broken packages. Then when I try, for instance: apt install libstdc++-8-dev I get: Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libstdc++-8-dev : Depends: libgcc-8-dev (= 8.4.0-2) but it is not going to be installed E: Unable to correct problems, you have held broken packages. Finally, when I try: apt install libgcc-8-dev I get: Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libgcc-8-dev : Depends: libgcc-s1 (>= 1:8.4.0-2) but 10-20200324-1 is to be installed E: Unable to correct problems, you have held broken packages. Isn't this a bug with these packages somehow? Thanks On Fri, Mar 27, 2020 at 5:48 PM Sylvestre Ledru wrote: > Hello, > > > Le 27/03/2020 à 19:37, Mauricio Calvao a écrit : > > Package: libclang-dev > > Version: 1:9.0-49.1 > > Severity: grave > > > > Dear Maintainer, > > > > > > * What led up to the situation? > > I think the problem showed up after I did a recent full-upgrade of > my operating system > > * What exactly did you do (or not do) that was effective (or > > ineffective)? > > I first tried installing RStudio deb package from their site and > was unsuccessful, with a message claiming that libclang-dev was not found. > Then I tried to install it manually > > > Please report this bug to RStudio. > > Works fine : > > sudo apt install libclang-dev -t unstable > Reading package lists... Done > Building dependency tree > Reading state information... Done > The following additional packages will be installed: > libclang-9-dev (1:9.0.1-10) > The following NEW packages will be installed: > libclang-9-dev (1:9.0.1-10) > libclang-dev (1:9.0-49.1) > 0 upgraded, 2 newly installed, 0 to remove and 407 not upgraded. > Need to get 16.1 MB of archives. > After this operation, 151 MB of additional disk space will be used. > Do you want to continue? [Y/n] > > Thanks > > Sylvestre > > > > -- ### Prof. Mauricio Ortiz Calvao Federal University of Rio de Janeiro Institute of Physics, P O Box 68528 CEP 21941-972 Rio de Janeiro, RJ Brazil Email: o...@if.ufrj.br Phone: (55)(21)39387483 Homepage: http://www.if.ufrj.br/~orca ###
Bug#953832: ImportError: /lib/x86_64-linux-gnu/libjemalloc.so.2: cannot allocate memory in static TLS block
Hi Faidon, Do you need some help ? Do you think reporting this upstream can help ? Also, I am not really used to report bug or help in bug triage. So, tell me if I am doing something wrong. Regards, Jean-Marc https://6jf.be/keys/ED863AD1.txt pgp4u_NAgJZM2.pgp Description: PGP signature
Bug#943027: fretsonfire: Python2 removal in sid/bullseye
Am 27.03.20 um 22:41 schrieb Moritz Mühlenhoff: [...] > I agree. It's unreasonable to block this removal further. fretsonfire > is not a standalone package, but a part of a long chain of packages > affected by the Py2 removal and this can't wait longer. I completely disagree here. Fretsonfire is one package affected by the Py2 removal but certainly not the only one. If it was the only one, then there would be absolutely no question because the Py2 removal is more important than a single package. But it is not the only one. There is still a lot of time left, we are still in the middle of the release cycle. What really saddens me is that people who either don't contribute or very little to Debian Games try to force their agenda one year before we freeze for Bullseye. I find that unacceptable to be honest. It's a slap in the face for contributors who have already ported several games to Python 3 and to be honest, it's a reason for me to quit this team altogether if you remove fretsonfire one year before the freeze. > If anyone ports it to Py3 until Bullseye freeze, even better. Failing > that, it's still available on Flathub for every future Debian user: > https://www.flathub.org/apps/details/net.sourceforge.fretsonfire Sure, maybe we should just direct all of our users to flathub for all our non-essential and non-important packages. Let's focus on the Linux kernel, systemd, and some GNU tools only, that's the universal operating system for you kids. signature.asc Description: OpenPGP digital signature
Bug#951144: libpam-cap: PAM unable to dlopen(pam_cap.so): /lib/security/pam_cap.so: cannot open shared object file
I haven't seen this anymore after Feb. 23. So I assume it was some temporary glitch indeed.
Bug#885265: Bug#936299: chirp: Python2 removal in sid/bullseye
On Fri, Mar 27, 2020 at 10:59:35PM +0100, Christoph Berg wrote: > Re: Moritz Mühlenhoff 2020-03-27 > <20200327215634.GA1565432@pisco.westfalen.local> > > On Sun, Oct 13, 2019 at 07:16:47PM +, Chris Knadle wrote: > > > There has been some discussion about #936299 on the upstream mailing > > > list, and > > > there have been a few upstream commits starting to port the code to > > > Python3. > > > > > > http://intrepid.danplanet.com/pipermail/chirp_devel/2019-August/005580.html > > > > Has there been any further development? Otherwise let's remove chirp > > from the archive until it gets ported, it's currently among the last > > handful of packages blocking the pygtk removal. > > There's a py3 branch in upstream Hg that's activish. I haven't tried > it yet, but it looks promising. I'll give it a try over the weekend > and report back here. Great, thanks! Cheers, Moritz
Bug#885265: Bug#936299: chirp: Python2 removal in sid/bullseye
Re: Moritz Mühlenhoff 2020-03-27 <20200327215634.GA1565432@pisco.westfalen.local> > On Sun, Oct 13, 2019 at 07:16:47PM +, Chris Knadle wrote: > > There has been some discussion about #936299 on the upstream mailing list, > > and > > there have been a few upstream commits starting to port the code to Python3. > > > > http://intrepid.danplanet.com/pipermail/chirp_devel/2019-August/005580.html > > Has there been any further development? Otherwise let's remove chirp > from the archive until it gets ported, it's currently among the last > handful of packages blocking the pygtk removal. There's a py3 branch in upstream Hg that's activish. I haven't tried it yet, but it looks promising. I'll give it a try over the weekend and report back here. Christoph
Bug#885265: Bug#936299: chirp: Python2 removal in sid/bullseye
On Sun, Oct 13, 2019 at 07:16:47PM +, Chris Knadle wrote: > There has been some discussion about #936299 on the upstream mailing list, and > there have been a few upstream commits starting to port the code to Python3. > > http://intrepid.danplanet.com/pipermail/chirp_devel/2019-August/005580.html Has there been any further development? Otherwise let's remove chirp from the archive until it gets ported, it's currently among the last handful of packages blocking the pygtk removal. Cheers, Moritz
Bug#955173: ganeti: Wrong ownership of /var/log/ganeti/meta-daemon.log after upgrade 2.15->2.16
Package: ganeti Version: 2.16.0-5 Severity: normal Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Ganeti cluster running Deb9/ganeti-2.15 was upgraded to first Deb10/ganeti-2.15 and then to Deb10/ganeti-2.16. After upgrade, starting VMs gives an error message. * What exactly did you do (or not do) that was effective (or ineffective)? # gnt-instance add --no-install -o debootstrap+default --no-ip-check --no-wait-for-sync -t drbd -B memory=1024,vcpus=1 -s 20G testcrap.DOMAIN Fri Mar 27 22:31:25 2020 - INFO: No-installation mode selected, disabling startup Fri Mar 27 22:31:25 2020 - INFO: Selected nodes for instance testcrap.DOMAIN via iallocator hail: fxxx.DOMAIN, pxxx.DOMAIN Fri Mar 27 22:31:26 2020 * creating instance disks... Fri Mar 27 22:31:32 2020 adding instance testcrap.DOMAIN to cluster config Fri Mar 27 22:31:32 2020 adding disks to cluster config Fri Mar 27 22:31:32 2020 * checking mirrors status Fri Mar 27 22:31:32 2020 - INFO: - device disk/0: 2.70% done, 37s remaining (estimated) Fri Mar 27 22:31:32 2020 * checking mirrors status Fri Mar 27 22:31:32 2020 - INFO: - device disk/0: 4.10% done, 23s remaining (estimated) Fri Mar 27 22:31:33 2020 Could not update metadata for instance 'testcrap.DOMAIN': Error while executing backend function: Failed to start metadata daemon # The problem seems to be wrong ownership of a log file: -rw-r- 1 root gnt-daemons 0 Mar 1 06:25 /var/log/ganeti/meta-daemon.log This seems to fix it: # gnt-cluster command chown gnt-metad /var/log/ganeti/meta-daemon.log Another test: # gnt-instance add --no-install -o debootstrap+default --no-ip-check --no-wait-for-sync -t drbd -B memory=1024,vcpus=1 -s 20G testcrap.DOMAIN Fri Mar 27 22:40:08 2020 - INFO: No-installation mode selected, disabling startup Fri Mar 27 22:40:26 2020 - INFO: Selected nodes for instance testcrap.DOMAIN via iallocator hail: fxxx.DOMAIN, pxxx.DOMAIN Fri Mar 27 22:40:27 2020 * creating instance disks... Fri Mar 27 22:40:33 2020 adding instance testcrap.DOMAIN to cluster config Fri Mar 27 22:40:33 2020 adding disks to cluster config Fri Mar 27 22:40:33 2020 * checking mirrors status Fri Mar 27 22:40:33 2020 - INFO: - device disk/0: 2.40% done, 42s remaining (estimated) Fri Mar 27 22:40:33 2020 * checking mirrors status Fri Mar 27 22:40:33 2020 - INFO: - device disk/0: 3.50% done, 27s remaining (estimated) # Maybe make sure that the log file is owned by the right user after upgrade, and/or at logrotate time..? * What was the outcome of this action? At least error messages, not sure about malfunctions * What outcome did you expect instead? No error messages *** End of the template - remove these template lines *** -- Package-specific info: Version symlinks: /etc/ganeti/share -> /usr/share/ganeti/2.16 /etc/ganeti/lib -> /usr/lib/ganeti/2.16 Cluster config version: 2.16.0 Address family: IPv4 Enabled hypervisors: kvm kvm hypervisor parameters: acpi=True boot_order=disk cpu_cores=0 cpu_mask=all cpu_sockets=0 cpu_threads=0 cpu_type=host disk_aio=threads disk_cache=default disk_discard=default disk_type=paravirtual kernel_args=ro keymap=sv kvm_extra=-device virtio-rng-pci,bus=pci.0,addr=0x1e,max-bytes=1024,period=1000 kvm_path=/usr/bin/kvm kvm_pci_reservations=12 migration_bandwidth=800 migration_downtime=30 migration_mode=live migration_port=8102 nic_type=paravirtual reboot_behavior=reboot root_path=/dev/vda1 scsi_controller_type=lsi security_model=none serial_console=True serial_speed=38400 spice_ip_version=0 spice_playback_compression=True spice_tls_ciphers=HIGH:-DES:-3DES:-EXPORT:-DH spice_use_tls=False spice_use_vdagent=True use_chroot=False use_guest_agent=False use_localtime=False user_shutdown=False vhost_net=True virtio_net_queues=1 vnc_bind_address=127.0.0.1 vnc_tls=False vnc_x509_verify=False vnet_hdr=True -- System Information: Debian Release: 10.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-8-amd64 (SMP w/24 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 /bin/bash Init: systemd (via /run/systemd/system) Versions of packages ganeti depends on: ii adduser 3.118 ii ganeti-2.16 2.16.0-5 ii ganeti-haskell-2.16 2.16.0-5 ii ganeti-htools-2.16 2.16.0-5 ii lsb-base 10.2019051400 ii python 2.7.16-1 Versions of packages ganeti recommends: ii drbd-utils 9.5.0-1 ii fdisk2.33.1-0.1 ii ganeti-instance-debootstrap 0.16-6 ii ndisc6 1.0.4-1 ii qemu-kvm 1:3.1+dfsg-8+deb10u4 Versions of packages ganeti suggests: pn blktap-dkms pn g
Bug#955172: python3-l20n: SyntaxWarning: "is" with a literal
Package: python3-l20n Version: 4.0.0~a1-5 Hello, on running python rtupdate hooks, a Python script in python3-l20n spits out a warning: /usr/lib/python3/dist-packages/l20n/format/parser.py:79: SyntaxWarning: "is not" with a literal. Did you mean "!="? if self._index is not 0 and \ Regards, Gabriele Stilli
Bug#954698: serf: FTBFS: 1) test_ssltunnel_basic_auth_server_has_keepalive_off: test/test_context.c:2138: expected <0> but was <120199>
Hi Justin, Most likely, this is due to the new openssl version in unstable. Lucas On 27/03/20 at 17:15 -0400, Justin Erenkrantz wrote: > James, > > I finally got a Debian sid environment up. However, I'm seeing a different > sets of test failures right now against vanilla serf 1.4.x and trunk (which > works with the scons/python3 in sid without a patch AFAICT) - this is with > 1.4.x branch: > > --- > > == Running the unit tests == > > ...F..F..FFF.F. > > There were 6 failures: > > 1) test_ssl_handshake_nosslv2: test/test_ssl.c:589: Serf does not disable > SSLv2, but it should! > > 2) test_ssl_missing_client_certificate: test/test_ssl.c:1925: expected > <120172> but was <120171> > > 3) test_ssl_server_cert_with_cn_nul_byte: test/test_util.c:551: expected > <0> but was <120199> > > 4) test_ssl_server_cert_with_san_nul_byte: test/test_util.c:551: expected > <0> but was <120199> > > 5) test_ssl_server_cert_with_cnsan_nul_byte: test/test_util.c:551: expected > <0> but was <120199> > > 6) test_ssl_renegotiate: test/test_ssl.c:1881: expected <0> but was <120199> > > > !!!FAILURES!!! > > Runs: 127 Passes: 121 Fails: 6 > --- > > I'll try to dig into this more over the weekend, but I wonder if I'm seeing > something different than you (or the builder) are...I'll also try to pull > in your patch set against vanilla 1.3.x to see if I can match the reported > error. > > Cheers. -- justin > > On Wed, Mar 25, 2020 at 8:17 PM James McCoy wrote: > > > On Wed, Mar 25, 2020 at 08:57:14AM -0400, Justin Erenkrantz wrote: > > > James, > > > > > > Thanks for the bug report. For reference, the upstream OpenSSL commit > > looks to > > > be: > > > > > > https://github.com/openssl/openssl/commit/ > > > d924dbf4ae127c68463bcbece04b6e06abc58928 > > > > > > I strongly suspect that the patch on our side (against 1.3.x) is > > something akin > > > to below. I'm having trouble getting a test environment up with the > > latest > > > OpenSSL to reproduce, so if anyone can test in the interim, that'd be > > > appreciated. > > > > Latest Debian sid has everything ready to test, although you'll need the > > patch I'm carrying to build since SCons is using Python 3. That reminds > > me, I was supposed to send that to the list awhile back. > > > > > If not, I'll try again as time (and kiddo) permit. > > > > Unfortunately, that didn't have any effect. > > > > Cheers, > > -- > > James > > GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB > >
Bug#955170: solfege: SyntaxWarning: "is" with a literal
Package: solfege Version: 3.23.4-7 on running python rtupdate hooks, a Python script in solfege spits out these warnings: /usr/share/solfege/solfege/mpd/lexer.py:166: SyntaxWarning: "is" with a literal. Did you mean "=="? if notelen is 0: /usr/share/solfege/solfege/mpd/lexer.py:186: SyntaxWarning: "is" with a literal. Did you mean "=="? if skiplen is 0: Regards, Gabriele Stilli
Bug#955171: RM: idjc -- RoQA; Depends on pygtk2
Package: ftp.debian.org Severity: normal Please remove idjc. It depends on pygtk, which is going away. There is a little movement upstream to port it, so when/if that materialises at some point, idjc can be reintroduced. Cheers, Moritz
Bug#955000: [Python-modules-team] Bug#955000: azure-cli: Autopkgtest failure in unstable
On Fri, 2020-03-27 at 15:30 -0400, Sandro Tosi wrote: > > Thanks for the report. Downgrading python3-humanfriendly to > > buster's > > version fixes the issue, so it looks like a backward-incompatible > > change in the new version. > > > > Reference to the class using it: > > > > https://salsa.debian.org/python-team/modules/azure-cli/-/blob/debian/sid/src/azure-cli-core/azure/cli/core/commands/progress.py#L104 > > > > Test: > > > > https://salsa.debian.org/python-team/modules/azure-cli/-/blob/debian/sid/src/azure-cli-core/azure/cli/core/tests/test_progress.py#L54 > > > > Reassigning so the python3-humanfriendly maitainer can have a look. > > what kind of looks should we have? most likely azure-cli-core should > get updated to deal with the new humanfriendly behavior no? I'm really not familiar with humanfriendly - could you at least give us a hint on what backward incompatible changes were made? More generally, how are API breaks dealt with with Python modules? Thanks! -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#955169: mma: SyntaxWarning: "is" with a literal
Package: mma Version: 20.02-1 Hello, on running python rtupdate hooks, a Python script in mma spits out a warning: /usr/share/mma/MMA/pat.py:1204: SyntaxWarning: "is" with a literal. Did you mean "=="? if self.vtype is 'PLECTRUM': Regards, Gabriele Stilli
Bug#885353: mirage: Python2 removal in sid/bullseye
On Fri, Jan 03, 2020 at 02:42:22AM -0500, Thomas Ross wrote: > I've started to port Mirage to Python 3 + PyGObject here: > https://gitlab.com/thomasross/mirage/tree/python3 What's the status? If this isn't complete, could we upload that to experimental and remove mirage from unstable (which avoids a roundtrip through the NEW queue), mirage is among the last handful of packages blocking the pygtk removal at this points. Cheers, Moritz
Bug#885282: gameclock: Depends on unmaintained pygtk
On Sat, Jan 06, 2018 at 01:01:28PM -0500, Antoine Beaupré wrote: > Control: forwarded -1 https://gitlab.com/anarcat/gameclock/issues/1 > > Understood. Hi Antoine, let's remove gameclock from the archive for now? When ported it can still be reintroduced, but currently it's among the last handful of packages blocking the pygtk removal. Cheers, Moritz
Bug#955168: hplip-data: SyntaxWarning: "is" with a literal
Package: hplip-data Version: 3.20.3+dfsg0-1 Hello, on config, some Python scripts in hplip-data spit out these warnings: /usr/share/hplip/base/utils.py:2060: SyntaxWarning: "is" with a literal. Did you mean "=="? if weburl is "" or weburl is None: /usr/share/hplip/check-plugin.py:116: SyntaxWarning: "is" with a literal. Did you mean "=="? if log_level is 'debug': /usr/share/hplip/check.py:685: SyntaxWarning: "is not" with a literal. Did you mean "!="? if 'getfacl' not in g and '' is not g and 'file' not in g: /usr/share/hplip/installer/core_install.py:2037: SyntaxWarning: "is" with a literal. Did you mean "=="? if home_dir is "": /usr/share/hplip/ui5/devmgr_ext.py:15: SyntaxWarning: "is not" with a literal. Did you mean "!="? if self.latest_available_version is not "": /usr/share/hplip/ui5/devmgr_ext.py:37: SyntaxWarning: "is not" with a literal. Did you mean "!="? if self.latest_available_version is not "": Regards, Gabriele Stilli
Bug#954698: serf: FTBFS: 1) test_ssltunnel_basic_auth_server_has_keepalive_off: test/test_context.c:2138: expected <0> but was <120199>
Ah, yes, I didn’t re-run the cert creation...so, that might be why those tests are failing. I just tried to run the cert creation script and it seems that pyOpenSSL’s interfaces have changed. But, the test that the Debian builder flagged didn’t fail... So, I will start from your package and patches and work my way back towards upstream. Cheers. — justin On Fri, Mar 27, 2020 at 5:27 PM James McCoy wrote: > On Fri, Mar 27, 2020 at 05:15:24PM -0400, Justin Erenkrantz wrote: > > James, > > > > I finally got a Debian sid environment up. However, I'm seeing a > different > > sets of test failures right now against vanilla serf 1.4.x and trunk > (which > > works with the scons/python3 in sid without a patch AFAICT) - this is > with > > 1.4.x branch: > > I haven't tested what happens with 1.4.x, since there hasn't been a > release yet. > > Are the test certs expired? I automatically run > test/certs/create_certs.py as part of the build process to ensure that > doesn't happen. > > Cheers, > -- > James > GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB >
Bug#955167: r-cran-sf: autopkgtest regression
Source: r-cran-sf
Version: 0.9-0+dfsg-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
Hi Maintainer
Since the upload of 0.9-0+dfsg-1, r-cran-sf fails its own autopkgtests
[1], which passed previously. I've copied what I hope is the relevant
part of the log below.
Regards
Graham
[1] https://ci.debian.net/packages/r/r-cran-sf/unstable/amd64/
> demo(meuse, ask = FALSE, echo = FALSE)
> meuse = spTransform(meuse, CRS("+proj=longlat +ellps=WGS84 +no_defs"))
Error in spTransform(meuse, CRS("+proj=longlat +ellps=WGS84 +no_defs")) :
package rgdal is required for spTransform methods
Calls: spTransform -> spTransform
Execution halted
autopkgtest [06:45:58]: test run-unit-test: ---]
autopkgtest [06:45:59]: test run-unit-test: - - - - - - - - - -
results - - - - - - - - - -
run-unit-testFAIL non-zero exit status 1
Bug#943027: fretsonfire: Python2 removal in sid/bullseye
On Sat, Feb 01, 2020 at 11:59:33AM -0500, Sandro Tosi wrote: > > Am 01.02.20 um 17:06 schrieb Steve Cotton: > > > On Sat, Feb 01, 2020 at 04:06:56PM +0100, Markus Koschany wrote: > > >> Please don't remove any games from Debian because of the Python 2 > > >> removal and try to port the games to Python 3 instead. For instance > > who should port these games? the upstream maintaintainers? maybe but > what if they are not developing the game anymore? the debian > maintainers? i dont think that's appropriate to ask that, as then even > more burden will fall on them (both keeping the package up to > standards *and* maintain the py3k port). so whos left? it appears > nobody. I agree. It's unreasonable to block this removal further. fretsonfire is not a standalone package, but a part of a long chain of packages affected by the Py2 removal and this can't wait longer. If anyone ports it to Py3 until Bullseye freeze, even better. Failing that, it's still available on Flathub for every future Debian user: https://www.flathub.org/apps/details/net.sourceforge.fretsonfire Cheers, Moritz
Bug#955165: ITS: taglib
Source: taglib Severity: important Version: 1.11.1+dfsg.1-0.3 X-Debbugs-CC: mo...@debian.org Hi Modestas, After looking into a package you maintain in Debian (taglib, https://tracker.debian.org/pkg/taglib), I found that this package received no update since 2013 and is not in good shape. As a result, I am filing an ITS (Intent to Salvage) request against your package according to section 5.12 in Debian Developers' Reference. [1] Please let me know if you are still willing to maintain this package. According to the criteria listed at [2], I will upload a Non-maintainer Upload (NMU) of taglib onto DELAYED/7 after 21 days (Apr. 17, 2020) to continue with the package salvaging. If it's necessary to pause the ITS process, please let me know immediately by replying this bug report. Thank you for your previous work on taglib and looking forward to your reply. [1] https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging [2] https://wiki.debian.org/PackageSalvaging -- Best Regards, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#955166: FTBFS with gcc-9: undefined reference to bsd_getopt, etc.
Package: src:kfreebsd-10
Version: 10.3~svn300087-5
Severity: serious
Tags: patch
kfreebsd-10 FTBFS with gcc-9 due to:
| gcc-9 -D_GNU_SOURCE -isystem /usr/include/freebsd
-I/home/build/kfreebsd-10-10.3~svn300087/flavor-10.3-0-amd64/sys/modules/aic7xxx/aicasm
-I../../../dev/aic7xxx/aicasm -std=gnu99 -fstack-protector -Wno-pointer-sign
-Wno-missing-prototypes -ldb -lbsd -o aicasm aicasm.o aicasm_symbol.o
aicasm_gram.o aicasm_macro_gram.o aicasm_scan.o aicasm_macro_scan.o -ll
| /usr/bin/ld: aicasm.o: in function `main':
| aicasm.c:(.text+0x4a1): undefined reference to `bsd_getopt'
| /usr/bin/ld: aicasm_symbol.o: in function `symtable_open':
| aicasm_symbol.c:(.text+0x220): undefined reference to `__db185_open'
| collect2: error: ld returned 1 exit status
| *** [aicasm] Error code 1
The linker invocation now adds the "--as-needed" parameter by default,
before -ldb and -lbsd, and furthermore those libraries were linked in
before the object files which use their functions:
| /usr/lib/gcc/x86_64-kfreebsd-gnu/9/collect2 -plugin
/usr/lib/gcc/x86_64-kfreebsd-gnu/9/liblto_plugin.so
-plugin-opt=/usr/lib/gcc/x86_64-kfreebsd-gnu/9/lto-wrapper
-plugin-opt=-fresolution=/tmp/ccgJKsnR.res -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --build-id
--eh-frame-hdr -m elf_x86_64_fbsd --hash-style=gnu --as-needed -dynamic-linker
/lib/ld-kfreebsd-x86-64.so.1 -pie -o aicasm
/usr/lib/gcc/x86_64-kfreebsd-gnu/9/../../../x86_64-kfreebsd-gnu/Scrt1.o
/usr/lib/gcc/x86_64-kfreebsd-gnu/9/../../../x86_64-kfreebsd-gnu/crti.o
/usr/lib/gcc/x86_64-kfreebsd-gnu/9/crtbeginS.o
-L/usr/lib/gcc/x86_64-kfreebsd-gnu/9
-L/usr/lib/gcc/x86_64-kfreebsd-gnu/9/../../../x86_64-kfreebsd-gnu
-L/usr/lib/gcc/x86_64-kfreebsd-gnu/9/../../../../lib -L/lib/x86_64-kfreebsd-gnu
-L/lib/../lib -L/usr/lib/x86_64-kfreebsd-gnu -L/usr/lib/../lib
-L/usr/lib/gcc/x86_64-kfreebsd-gnu/9/../../.. -ldb -lbsd a
icasm.o aicasm_symbol.o aicasm_gram.o aicasm_macro_gram.o aicasm_scan.o
aicasm_macro_scan.o -ll -lgcc --push-state --as-needed -lgcc_s --pop-state -lc
-lgcc --push-state --as-needed -lgcc_s --pop-state
/usr/lib/gcc/x86_64-kfreebsd-gnu/9/crtendS.o
/usr/lib/gcc/x86_64-kfreebsd-gnu/9/../../../x86_64-kfreebsd-gnu/crtn.o
As a result, those libraries would not be linked in at all. Object
files aicasm.o, aicasm_symbol.o subsequently cannot find find the
required functions.
I've fixed this by using LDADD within the Makefile, instead of
LDFLAGS within our debian/rules, to add the library dependencies.
Now the library dependencies are added after the object files,
as they should be.
-- System Information:
Debian Release: 8.0
APT prefers stable-kfreebsd-proposed-updates
APT policy: (500, 'stable-kfreebsd-proposed-updates'), (500,
'stable-kfreebsd')
Architecture: kfreebsd-amd64 (x86_64)
Kernel: kFreeBSD 10.1-0-amd64
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Date: Fri, 27 Mar 2020 21:26:21 +
From: Steven Chamberlain
Subject: Add extra libs required to build aicasm
--- a/sys/dev/aic7xxx/aicasm/Makefile
+++ b/sys/dev/aic7xxx/aicasm/Makefile
@@ -14,7 +14,7 @@ GENHDRS= aicasm_gram.h aicasm_macro_gram
SRCS= ${GENHDRS} ${CSRCS} ${YSRCS} ${LSRCS}
CLEANFILES+= ${GENHDRS} ${YSRCS:R:C/(.*)/\1.output/g}
DPADD= ${LIBL}
-LDADD= -ll
+LDADD= -ldb -lbsd -ll
WARNS?=0
# Correct path for kernel builds
Bug#955164: ITP: r-bioc-rgsepd -- GNU R gene set enrichment / projection displays
Package: wnpp Severity: wishlist Subject: ITP: r-bioc-rgsepd -- GNU R gene set enrichment / projection displays Package: wnpp Owner: Andreas Tille Severity: wishlist * Package name: r-bioc-rgsepd Version : 1.18.0 Upstream Author : Karl Stamm * URL : https://bioconductor.org/packages/rgsepd/ * License : GPL-3 Programming Lang: GNU R Description : GNU R gene set enrichment / projection displays R/GSEPD is a bioinformatics package for R to help disambiguate transcriptome samples (a matrix of RNA-Seq counts at transcript IDs) by automating differential expression (with DESeq2), then gene set enrichment (with GOSeq), and finally a N-dimensional projection to quantify in which ways each sample is like either treatment group. Remark: This package is maintained by Debian R Packages Maintainers at https://salsa.debian.org/r-pkg-team/r-bioc-rgsepd
Bug#938488: fixed in singularity 1.0a1-1
On Thu, Dec 19, 2019 at 01:19:33PM +, Kari Pahula wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Format: 1.8 > Date: Thu, 19 Dec 2019 14:57:15 +0200 > Source: singularity > Binary: singularity > Architecture: source all > Version: 1.0a1-1 > Distribution: experimental > Urgency: medium > Maintainer: Kari Pahula > Changed-By: Kari Pahula > Description: > singularity - game where one becomes the singularity > Closes: 490572 570923 718447 904225 912519 938488 946381 > Changes: > singularity (1.0a1-1) experimental; urgency=medium > . >* New upstream release (Closes: #946381) > * Savegame handling has been rewritten (Closes: #490572, #904225) > * Better unicode handling of savegame names (Closes: #718447) > * Python3 support (Closes: #912519, #938488) > * Could not repeat real_cpu bug, presumably fixed (Closes: #570923) >* Switch packaging from cdbs to dh >* Standards-Version 4.4.1 and dh compat 12 >* Remove menu file >* Removed patches Hi Kari, What's the status, is this ready to get uploaded to unstable? Cheers, Moritz
Bug#936459: dvcs-autosync: Python2 removal in sid/bullseye
On Fri, Aug 30, 2019 at 07:16:06AM +, Matthias Klose wrote: > Package: src:dvcs-autosync > Version: 0.5+nmu1 > Severity: normal > Tags: sid bullseye > User: debian-pyt...@lists.debian.org > Usertags: py2removal > > Python2 becomes end-of-live upstream, and Debian aims to remove > Python2 from the distribution, as discussed in > https://lists.debian.org/debian-python/2019/07/msg00080.html Hi Rene, the debian/ directory in your repository on github seems to have fixed this, can you upload this to archive? Cheers, Moritz
Bug#955163: RM: openalpr -- RoQA; RC-buggy, unmaintained
Package: ftp.debian.org Severity: normal Please remove openalpr. The maintainer upload was in 2016 and it fails to build from source for over a year now (922588) Cheers, Moritz
Bug#954698: serf: FTBFS: 1) test_ssltunnel_basic_auth_server_has_keepalive_off: test/test_context.c:2138: expected <0> but was <120199>
On Fri, Mar 27, 2020 at 05:15:24PM -0400, Justin Erenkrantz wrote: > James, > > I finally got a Debian sid environment up. However, I'm seeing a different > sets of test failures right now against vanilla serf 1.4.x and trunk (which > works with the scons/python3 in sid without a patch AFAICT) - this is with > 1.4.x branch: I haven't tested what happens with 1.4.x, since there hasn't been a release yet. Are the test certs expired? I automatically run test/certs/create_certs.py as part of the build process to ensure that doesn't happen. Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Bug#955162: RM: python-mhash -- RoQA; Depends on Python 2, dead upstream, unmaintained
Package: ftp.debian.org Severity: normal Please remove python-mhash. It's dead upstream, depends on Python 2, there are no reverse deps and the last maintainer upload was in 2009. Cheers, Moritz
Bug#955161: RM: python-poster -- RoQA; Depends on Python 2, dead upstream, unmaintained, no rev deps
Package: ftp.debian.org Severity: normal Please remove python-poster. It depends on Python 2, is dead upstream, the last maintainer upload was in 2011 and there are no reverse deps. Cheers, Moritz
Bug#955160: RM: calabash -- RoQA; Depends on Python 2, dead upstream, unmaintained, no rev deps
Package: ftp.debian.org Severity: normal Please remove calabash. It depends on Python 2, is dead upstream (last release in 2011), the last maintainer upload was in 2014 and there are no reverse deps. Cheers, Moritz
Bug#955159: RM: freevial -- RoQA; Depends on Python 2, dead upstream, unmaintained
Package: ftp.debian.org Severity: normal Please remove freevial. It depends on Python 2, is dead upstream and the last maintainer upload was in 2011. Cheers, Moritz
Bug#954698: serf: FTBFS: 1) test_ssltunnel_basic_auth_server_has_keepalive_off: test/test_context.c:2138: expected <0> but was <120199>
James, I finally got a Debian sid environment up. However, I'm seeing a different sets of test failures right now against vanilla serf 1.4.x and trunk (which works with the scons/python3 in sid without a patch AFAICT) - this is with 1.4.x branch: --- == Running the unit tests == ...F..F..FFF.F. There were 6 failures: 1) test_ssl_handshake_nosslv2: test/test_ssl.c:589: Serf does not disable SSLv2, but it should! 2) test_ssl_missing_client_certificate: test/test_ssl.c:1925: expected <120172> but was <120171> 3) test_ssl_server_cert_with_cn_nul_byte: test/test_util.c:551: expected <0> but was <120199> 4) test_ssl_server_cert_with_san_nul_byte: test/test_util.c:551: expected <0> but was <120199> 5) test_ssl_server_cert_with_cnsan_nul_byte: test/test_util.c:551: expected <0> but was <120199> 6) test_ssl_renegotiate: test/test_ssl.c:1881: expected <0> but was <120199> !!!FAILURES!!! Runs: 127 Passes: 121 Fails: 6 --- I'll try to dig into this more over the weekend, but I wonder if I'm seeing something different than you (or the builder) are...I'll also try to pull in your patch set against vanilla 1.3.x to see if I can match the reported error. Cheers. -- justin On Wed, Mar 25, 2020 at 8:17 PM James McCoy wrote: > On Wed, Mar 25, 2020 at 08:57:14AM -0400, Justin Erenkrantz wrote: > > James, > > > > Thanks for the bug report. For reference, the upstream OpenSSL commit > looks to > > be: > > > > https://github.com/openssl/openssl/commit/ > > d924dbf4ae127c68463bcbece04b6e06abc58928 > > > > I strongly suspect that the patch on our side (against 1.3.x) is > something akin > > to below. I'm having trouble getting a test environment up with the > latest > > OpenSSL to reproduce, so if anyone can test in the interim, that'd be > > appreciated. > > Latest Debian sid has everything ready to test, although you'll need the > patch I'm carrying to build since SCons is using Python 3. That reminds > me, I was supposed to send that to the list awhile back. > > > If not, I'll try again as time (and kiddo) permit. > > Unfortunately, that didn't have any effect. > > Cheers, > -- > James > GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB >
Bug#955158: golang-github-facebookgo-stack: autopkgtest regression on arm64
Source: golang-github-facebookgo-stack Version: 0.0~git20160209.0.7517733-7 X-Debbugs-CC: debian...@lists.debian.org Severity: serious User: debian...@lists.debian.org Usertags: regression Dear maintainer(s), With a recent upload of golang-github-facebookgo-stack the autopkgtest of golang-github-facebookgo-stack fails in testing on arm64 when that autopkgtest is run with the binary packages of golang-github-facebookgo-stack from unstable. It passes when run with only packages from testing. In tabular form: pass fail golang-github-facebookgo-stack from testing 0.0~git20160209.0.7517733-7 all others from testing from testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration to testing [1]. Can you please investigate the situation and fix it? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=golang-github-facebookgo-stack https://ci.debian.net/data/autopkgtest/testing/arm64/g/golang-github-facebookgo-stack/4698099/log.gz autopkgtest [20:54:48]: test dh-golang-autopkgtest: [--- [info] Testing github.com/facebookgo/stack... [info] Source code installed by binary package, overriding dh_auto_configure... dh build --buildsystem=golang --with=golang dh_update_autotools_config -O--buildsystem=golang dh_autoreconf -O--buildsystem=golang debian/rules override_dh_auto_configure make[1]: Entering directory '/tmp/autopkgtest-lxc.ozdby7yo/downtmp/autopkgtest_tmp' mkdir -p "obj-aarch64-linux-gnu" cp -a /usr/share/gocode/src "obj-aarch64-linux-gnu" make[1]: Leaving directory '/tmp/autopkgtest-lxc.ozdby7yo/downtmp/autopkgtest_tmp' dh_auto_build -O--buildsystem=golang cd obj-aarch64-linux-gnu && go install -trimpath -v -p 32 github.com/facebookgo/stack internal/cpu runtime/internal/sys internal/race unicode/utf8 math/bits unicode sync/atomic runtime/internal/atomic runtime/internal/math internal/bytealg internal/testlog math runtime internal/reflectlite sync errors sort io internal/oserror strconv syscall bytes strings reflect internal/syscall/unix time internal/poll internal/fmtsort os fmt path/filepath github.com/facebookgo/stack dh_auto_test -O--buildsystem=golang cd obj-aarch64-linux-gnu && go test -vet=off -v -p 32 github.com/facebookgo/stack === RUN TestCallers TestCallers: stack_test.go:93: did not find expected match "stack_test.go:16 +TestCallers$" on line 1 in: github.com/facebookgo/stack/stack_test.go:12 indirect1 github.com/facebookgo/stack/stack_test.go:16 indirect2 github.com/facebookgo/stack/stack_test.go:20 indirect3 github.com/facebookgo/stack/stack_test.go:24 TestCallers /usr/lib/go-1.14/src/testing/testing.go:992 tRunner /usr/lib/go-1.14/src/runtime/asm_arm64.s:1148 goexit --- FAIL: TestCallers (0.00s) === RUN TestCallersMulti --- PASS: TestCallersMulti (0.00s) === RUN TestCallersMultiWithTwo --- PASS: TestCallersMultiWithTwo (0.00s) === RUN TestCallersWithStruct TestCallersWithStruct: stack_test.go:93: did not find expected match "stack_test.go:62 +TestCallersWithStruct$" on line 1 in: github.com/facebookgo/stack/stack_test.go:58 typ.indirect1 github.com/facebookgo/stack/stack_test.go:62 typ.indirect2 github.com/facebookgo/stack/stack_test.go:66 typ.indirect3 github.com/facebookgo/stack/stack_test.go:71 TestCallersWithStruct /usr/lib/go-1.14/src/testing/testing.go:992 tRunner /usr/lib/go-1.14/src/runtime/asm_arm64.s:1148 goexit --- FAIL: TestCallersWithStruct (0.00s) === RUN TestCaller --- PASS: TestCaller (0.00s) FAIL FAILgithub.com/facebookgo/stack 0.003s FAIL dh_auto_test: error: cd obj-aarch64-linux-gnu && go test -vet=off -v -p 32 github.com/facebookgo/stack returned exit code 1 make: *** [debian/rules:4: build] Error 25 autopkgtest [20:54:56]: test dh-golang-autopkgtest: ---] signature.asc Description: OpenPGP digital signature
Bug#955156: python3-openshot: Installation broken
Package: python3-openshot Version: 0.2.2+dfsg1-1 Severity: grave Justification: renders package unusable After the transition to Python 3.8 one is no longer able to install Openshot: $ sudo apt install python3-openshot Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: python3-openshot : Depends: python3 (< 3.8) but 3.8.2-2 is to be installed E: Unable to correct problems, you have held broken packages. Note that I am running testing but the same should apply to sid. -- 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 python3-openshot depends on: ii libavutil56 7:4.2.2-1+b1 ii libc62.30-2 ii libgcc-s1 [libgcc1] 10-20200324-1 ii libgcc1 1:10-20200324-1 ii libjsoncpp1 1.7.4-3.1 pn libopenshot-audio6 pn libopenshot16 pn libpython3.7 ii libqt5core5a 5.12.5+dfsg-9 ii libstdc++6 10-20200324-1 ii python3 3.8.2-2 python3-openshot recommends no packages. python3-openshot suggests no packages.
Bug#955157: upx-ucl: autopkgtest regression: basic-check Segmentation fault
Source: upx-ucl
Version: 3.96-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
Dear maintainer(s),
With a recent upload of upx-ucl the autopkgtest of upx-ucl fails in
testing when that autopkgtest is run with the binary packages of upx-ucl
from unstable. It passes when run with only packages from testing. In
tabular form:
passfail
upx-uclfrom testing3.96-1
versioned deps [0] from testingfrom unstable
all others from testingfrom testing
I copied some of the output at the bottom of this report.
Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[1] https://qa.debian.org/excuses.php?package=upx-ucl
https://ci.debian.net/data/autopkgtest/testing/amd64/u/upx-ucl/4693222/log.gz
autopkgtest [18:38:05]: test basic-check: [---
+ cp /bin/ls /tmp/tmp.Wq2JAZbAI0
+ upx-ucl ./ls
Ultimate Packer for eXecutables
Copyright (C) 1996 - 2020
UPX 3.96Markus Oberhumer, Laszlo Molnar & John Reiser Jan 23rd
2020
File size Ratio Format Name
-- --- ---
138848 -> 67100 48.33% linux/arm64 ls
Packed 1 file.
+ ./ls -al
Segmentation fault
autopkgtest [18:38:05]: test basic-check: ---]
signature.asc
Description: OpenPGP digital signature
Bug#955155: pocketsphinx FTCBFS: uses the build architecture pkg-config
Source: pocketsphinx
Version: 0.8+5prealpha+1-11
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
pocketsphinx fails to cross build from source. One reason is that it
uses the build architecture pkg-config via AC_CHECK_PROG. The attached
patch replaces the use with PKG_PROG_PKG_CONFIG.
Another reason is that configure.ac decides that during cross
compilation, it should skip the gstreamer stuff (search for
AM_CONDITIONAL and BUILD_GST). Thus dh_install complains about missing
files. I think this upstream choice is unfortunate. I think upstream
should leave that choice to users (e.g. using an AC_ARG_WITH). Thus
users could enable it despite cross compilation. Do you think that would
work with upstream? It could look like:
AC_ARG_WITH(gstreamer, AS_HELP_STRING([--with-gstreamer],[Enable GStreamer
plugin, autodetect unless cross building]))
AS_IF([test "x$with_gstreamer" != xno],[
PKG_CHECK_MODULES(GStreamer, ..., HAVE_GST=yes, HAVE_GST=no)
AS_IF([test "x$with_gstreamer" = xyes && test "$HAVE_GST" = no],[
AC_MSG_ERROR(["gstreamer not found])])
])
AM_CONDITIONAL(BUILD_GST, test "x$with_gstreamer" != xno && test "$HAVE_GST" =
yes && { test "x$with_gstreamer" = yes || test "$cross_compiling" = no; })
Even after enabling BUILD_GST, the cross build fails, because
dh_gstscancodecs does not work during cross building (even though the
plugin was successfully cross built). We don't presently have a solution
to this.
Please consider applying the attached patch to fix the pkg-config issue.
Please consider talking to upstream and propose the --with-gstreamer
switch to allow cross building the gstreamer plugin and unconditionally
pass --with-gstreamer to the build if that was successful. Please close
this bug even if pocketsphinx fails in dh_gstscancodecs.
Helmut
--- pocketsphinx-0.8+5prealpha+1.orig/configure.ac
+++ pocketsphinx-0.8+5prealpha+1/configure.ac
@@ -18,7 +18,7 @@
dnl
dnl Check for pkgconfig
dnl
-AC_CHECK_PROG(HAVE_PKGCONFIG, pkg-config, yes, no)
+PKG_PROG_PKG_CONFIG
dnl
dnl Check for Doxygen, and build dox if present
@@ -117,7 +118,7 @@
if test x$sphinxbase = x || test x$sphinxbase = xauto; then
sphinxbase=
- if test "x$HAVE_PKGCONFIG" = "xno"; then
+ if test "x$PKG_CONFIG" = "x"; then
SPHINXBASE_CFLAGS = "-I/usr/include/sphinxbase -I/usr/local/include/sphinxbase"
SPHINXBASE_LIBS = "-lsphinxbase"
SPHINXBASE_PREFIX="/usr/local"
@@ -128,7 +128,7 @@
Make sure that you have installed it and that the
PKG_CONFIG_PATH environment variable is set correctly, if
it was installed in a non-standard prefix.])])
- SPHINXBASE_PREFIX=`pkg-config --variable=prefix sphinxbase`
+ SPHINXBASE_PREFIX=`$PKG_CONFIG --variable=prefix sphinxbase`
fi
LIBS="$LIBS $SPHINXBASE_LIBS"
Bug#955152: git breaks dgit autopkgtest: gdr-newupstream test failed
Source: git, dgit Control: found -1 git/1:2.26.0-1 Control: found -1 dgit/9.10 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 git the autopkgtest of dgit fails in testing when that autopkgtest is run with the binary packages of git from unstable. It passes when run with only packages from testing. In tabular form: passfail gitfrom testing1:2.26.0-1 dgit from testing9.10 all others from testingfrom testing I copied some of the output at the bottom of this report. Unfortunately I couldn't spot where the real error is reported. Currently this regression is blocking the migration of git 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=git https://ci.debian.net/data/autopkgtest/testing/amd64/d/dgit/4693444/log.gz TEST FAILED cwd: /tmp/autopkgtest-lxc.i0ld8_lz/downtmp/autopkgtest_tmp/example funcs: t-report-failure main lines: 7 0 files: tests/lib /tmp/autopkgtest-lxc.i0ld8_lz/downtmp/build.QKl/src/tests/tests/gdr-newupstream gzip: warning: GZIP environment variable is deprecated; use an alias or script 81.5% autopkgtest [12:39:07]: test gdr-newupstream: ---] signature.asc Description: OpenPGP digital signature
Bug#955153: arno-iptables-firewall: manual page is outdated
Package: arno-iptables-firewall Version: 2.1.0-1 Severity: minor Dear Maintainer, the present manual page is fairy outdated. It does not reflect the recent version of AIF well. Especially the descriptions regarding syslogd and plugins are not appropriate any more. Please update the manual page, or get it updated. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-4-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages arno-iptables-firewall depends on: ii debconf [debconf-2.0] 1.5.73 ii iproute2 5.5.0-1 ii iptables 1.8.4-3 ii kmod 27-2 ii procps 2:3.3.16-4 Versions of packages arno-iptables-firewall recommends: ii curl 7.68.0-1 ii dnsutils 1:9.11.16+dfsg-2 ii rsyslog 8.2002.0-2 arno-iptables-firewall suggests no packages. -- debconf information excluded
Bug#955154: libsepol FTBFS with gcc-10/-fno-commons
Source: libsepol Version: 3.0-1 Severity: important Tags: ftbfs patch upstream fixed-upstream User: helm...@debian.org Usertags: rebootstrap libsepol fails to build from source when enabling -fno-commons as is done by gcc-10. In order to fix the issue, two commits are needed: https://github.com/SELinuxProject/selinux/commit/a96e8c59ecac84096d870b42701a504791a8cc8c https://github.com/SELinuxProject/selinux/commit/3d32fc24d6aff360a538c63dad08ca5c957551b0 Please consider updating libsepol to a version including them or cherry-picking them into the current version. The relevant commits apply without issues to 3.0-1. This bug will become severity serious once gcc-10 becomes the default compiler. Helmut
Bug#954652: Opening new tab or window from terminal opened with -x opens the same application again
Hi, Thanks for this report! Upstream gnome-terminal 3.36.1 fixes this issue. Now you only need to wait for Debian to ship this version, which hopefully won't take long. e. On Sun, Mar 22, 2020 at 10:44 PM Egmont Koblinger wrote: > > Upstream: https://gitlab.gnome.org/GNOME/gnome-terminal/issues/236
Bug#955144: libclang-dev: package could not be installed
Hello, Le 27/03/2020 à 19:37, Mauricio Calvao a écrit : Package: libclang-dev Version: 1:9.0-49.1 Severity: grave Dear Maintainer, * What led up to the situation? I think the problem showed up after I did a recent full-upgrade of my operating system * What exactly did you do (or not do) that was effective (or ineffective)? I first tried installing RStudio deb package from their site and was unsuccessful, with a message claiming that libclang-dev was not found. Then I tried to install it manually Please report this bug to RStudio. Works fine : sudo apt install libclang-dev -t unstable Reading package lists... Done Building dependency tree Reading state information... Done The following additional packages will be installed: libclang-9-dev (1:9.0.1-10) The following NEW packages will be installed: libclang-9-dev (1:9.0.1-10) libclang-dev (1:9.0-49.1) 0 upgraded, 2 newly installed, 0 to remove and 407 not upgraded. Need to get 16.1 MB of archives. After this operation, 151 MB of additional disk space will be used. Do you want to continue? [Y/n] Thanks Sylvestre
Bug#955150: RFP: purple-matrix -- libpurple protocol plugin for the Matrix protocol
Quoting David Seaward (2020-03-27 20:35:34) > Package: wnpp > Severity: wishlist > > * Package name: purple-matrix > Version : 0.0.0 (ideally through to commit 1d23385) > Upstream Author : Matrix.org team > * URL : https://matrix.org/docs/projects/client/purple-matrix > * License : GPL-2.0-or-later > Programming Lang: C > Description : libpurple protocol plugin for the Matrix protocol > > This is a plugin for libpurple which adds the ability to communicate with > matrix.org homeservers to any libpurple-based clients (such as Pidgin). Exists already for 3+ years: https://tracker.debian.org/pkg/purple-matrix ...if I am not mistaken. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#955151: rust-bumpalo: RUSTSEC-2020-0006:Flaw in `realloc` allows reading unknown memory
Source: rust-bumpalo Version: 3.1.2-1 Severity: grave Tags: security upstream Justification: user security hole Forwarded: https://github.com/fitzgen/bumpalo/issues/69 Hi Please see https://rustsec.org/advisories/RUSTSEC-2020-0006.html and the upstream issue at https://github.com/fitzgen/bumpalo/issues/69 . Regards, Salvatore
Bug#955150: RFP: purple-matrix -- libpurple protocol plugin for the Matrix protocol
Package: wnpp Severity: wishlist * Package name: purple-matrix Version : 0.0.0 (ideally through to commit 1d23385) Upstream Author : Matrix.org team * URL : https://matrix.org/docs/projects/client/purple-matrix * License : GPL-2.0-or-later Programming Lang: C Description : libpurple protocol plugin for the Matrix protocol This is a plugin for libpurple which adds the ability to communicate with matrix.org homeservers to any libpurple-based clients (such as Pidgin).
Bug#173713:
*Hallo mein Freund. Ich habe Ihnen diese E-Mail vor einem Monat gesendet, bin mir aber nicht sicher, ob Sie sie erhalten. Ich habe wichtige Informationen in Bezug auf einen Fonds von 13.580.000,00 USD für Sie, da Sie mit meinem verstorbenen Kunden denselben Nachnamen haben und ich möchte, dass wir zusammenarbeiten, um den Fonds aus rechtlichen Gründen zu unserem beiderseitigen Vorteil in Anspruch zu nehmen. Dies ist nur eine kurze Information, antworten Sie für weitere Details. Ich entschuldige mich für die Fehler, ich spreche und schreibe tatsächlich auf Englisch, ich habe einen Online-Übersetzer benutzt. Mit freundlichen Grüßen, Fürsprecher Adomako James*
Bug#955000: [Python-modules-team] Bug#955000: azure-cli: Autopkgtest failure in unstable
> Thanks for the report. Downgrading python3-humanfriendly to buster's > version fixes the issue, so it looks like a backward-incompatible > change in the new version. > > Reference to the class using it: > > https://salsa.debian.org/python-team/modules/azure-cli/-/blob/debian/sid/src/azure-cli-core/azure/cli/core/commands/progress.py#L104 > > Test: > > https://salsa.debian.org/python-team/modules/azure-cli/-/blob/debian/sid/src/azure-cli-core/azure/cli/core/tests/test_progress.py#L54 > > Reassigning so the python3-humanfriendly maitainer can have a look. what kind of looks should we have? most likely azure-cli-core should get updated to deal with the new humanfriendly behavior no? -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Bug#938614: Unlikely to be ported
On Fri, Mar 27, 2020 at 07:45:20PM +0100, Moritz Mühlenhoff wrote: > On Mon, Nov 11, 2019 at 12:44:45PM +, Jelmer Vernooij wrote: > > FWIW it looks unlikely that upstream will migrate to Python 3 in the > > near future; see e.g. > > https://github.com/syncthing/syncthing-gtk/pull/475 > > Let's remove it for now, then? This blocks a number of Py2 removals > at this point. That sounds reasonable to me, if this is blocking other packages now. I was hoping for movement upstream, but that does not seem to be happening. Happy for you to file a removal request, or I can do it when I have a free moment this weekend. Cheers, Jelmer -- Jelmer Vernooij PGP Key: https://www.jelmer.uk/D729A457.asc signature.asc Description: PGP signature
Bug#718949: #718949 -- libdata-uuid-perl: CVE-2013-4184: symlink attacks vulnerability
Quoting Damyan Ivanov (2017-11-03 14:32:01) > Control: tag -1 patch > > I have a (rather crude) patch that removes save/retrieval of > state/node info to files. The test suite seems to pass. > > Not sure whether we shall seek to remove libdata-uuid-perl instead. > There are libuuid-perl and libossp-uuid-perl which seem like suitable > replacement. > > DAK check shows three affected packages: > > # Broken Depends: > libcatmandu-perl: libcatmandu-perl Unversioned, so satisfied by libossp-uuid-perl > libkiokudb-perl: libkiokudb-perl > zoneminder: zoneminder [amd64 arm64 armel armhf i386 kfreebsd-amd64 > kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x] Unversioned, so satisfied by libossp-uuid-perl So it seems to me it is only really libkiokudb-perl we need to worry about. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#955149: python3-pydocstyle: pydocstyle.config Deprecation warning during 'from collections import Set'
Package: python3-pydocstyle Version: 2.1.1-1 Severity: minor Tags: upstream Dear Maintainer, This package emits a DeprecationWarning during an import. The issue is known upstream and has been fixed in this commit: https://github.com/PyCQA/pydocstyle/pull/324/commits/5f216c27f09fa95647fa5496d5ed056772e009a5 Would you be willing to apply that commit here? To reproduce: python3 -Walways -c 'import pydocstyle.config' Output: /usr/lib/python3/dist-packages/pydocstyle/config.py:6: DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated since Python 3.3, and in 3.9 it will stop working from collections import Set, namedtuple Cheers, Shane -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.15.0-91-generic (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages python3-pydocstyle depends on: ii python3 3.8.2-2 ii python3-six 1.14.0-2 ii python3-snowballstemmer 2.0.0-1 python3-pydocstyle recommends no packages. python3-pydocstyle suggests no packages. -- no debconf information
Bug#718949: #718949 -- libdata-uuid-perl: CVE-2013-4184: symlink attacks vulnerability
While packaging a new upstream version, I was inclined to raise the severity of this bug to RC to start the removal of libdata-uuid-perl. However, it is still a reverse dependency of many dists on cpan, and the suggested replacements have a different API. So I didn't. I didn't forward the patch either: looking at the NOTE paragraph in README, not writing state information to files "will maximize the chances of generating duplicate UUIDs". Umpf.
